(Gut reaction - this is going to be a free for all. The software patent haters and the patent system is broken crowd will be in a frenzy.)
The meetings are being presented as "roundtable events" that will provide a forum for an informal and interactive discussion of topics related to patents that are particularly relevant to the software community.
(Interactive? Let's hope that stakeholders aren't, well, holding any stakes.)
USPTO seeks to improve the quality of software related patents that use functional language seeking comments on, "How to improve the claim boundaries that define the scope of patent protection for claims that use functional language."
The vertigo-inducing Federal Register announcement went further inviting attendees to make oral presentations on the advantages and disadvantages of applicants employing the following practices when preparing patent applications as they relate to software claims.
1) "Expressly identifying clauses within particular claim limitations for which the inventor intends to invoke 35 U.S.C. 112(f) and pointing out where in the specification corresponding structures, materials, or acts are disclosed that are linked to the identified 35 U.S.C. 112(f) claim limitations; and
2) Using textual and graphical notation systems known in the art to disclose algorithms in support of computer-implemented claim limitations such as C-like pseudo-code or XML-like schemas for textual notation and Unified Modeling Language (UML) for graphical notations.
Ok, so the first one is generally linking the claims to the spec so that you can't have a claim for a "a method to buy stuff over the internet" without having language in the description that explains exactly what the invention does. Legalese aside, this seems to be a way to rein in the patent argot language stylists who have very large vocabularies and know all the overly broad words in the English language or make up new ones when needed to make the boundaries on what exactly the invention IS fuzzy. The tighter mapping, which seems to have disappeared for under a cloud of patent argot both software patents and its, cousin the business method patent, might help both the examiners and the rest of us trying to figure out what inventions ARE.
(The Zipcar folks were talking about their sophisticated computer implemented "personal mobility" proprietary business models earlier today when announcing Zipcar's merger with Avis. - Note to patent prosecution language architects - renting a car (or maybe a bike share) is now a personal mobility business method when it uses a sophisticated computer implemented method - the reservation system. "A computer assisted method of using the Avis cars that sit unrented on the weekend to fill the personal mobility access requests from personal mobility orderers when there is higher than normal requests for personal mobility on Saturdays")
But Wait!!
The use of "textual and graphic notation systems" to disclose computer implemented claim limitations.
Before you click off to read something less mind numbing, consider the following. Maybe USPTO is going to try to manage the growth of software patents and the patent generating digital invention shops who patent ideas and not things simply by making the patent applications for these inventions much harder or, in some cases, absolutely impossible to file.
(Perhaps this is David Kappos parting gift.)
First, what is a textual and graphical notation system? One ordinarily skilled in the art will know, but for everyone else a quick tutorial.
According to the good folks at Wikipedia, "C-like pseudo code is generally an informal high-level description of the operating principle of a computer program or other algorithm. It uses the structural conventions of a programming language, but is intended for human reading rather than machine reading. Pseudocode typically omits details that are not essential for human understanding of the algorithm, such as variable declarations, system-specific code and some subroutines. The programming language is augmented with natural language description details, where convenient, or with compact mathematical notation. The purpose of using pseudocode is that it is easier for people to understand than conventional programming language code, and that it is an efficient and environment-independent description of the key principles of an algorithm. It is commonly used ... in planning of computer program development, for sketching out the structure of the program before the actual coding takes place."
(Emphasis added)
Usually pseudo-code acts as the glue between the business people who are defining requirements and the programmers who need to understand all the rules and processes before turning the requirements into software magic. (If you would like to see some samples, just search for pseudo-code in your favorite search engine.)
XML and Unified Modeling Languages are more high level versions of the same. Tags and text. Human readable representations of the processes.
If USPTO adopts this type of annotation, the inventor would need to write out in pseudo computer lingo or XML or UML exactly what the invention is doing, what the inventor is claiming. If you are a serious developer of digital business methods or digital software inventions, you have to do this anyway as you seek to reduce the invention to practice. Real software needs to be built just like any other invention.
(The folks at the Electronic Frontier Foundation and Mark Cuban must be doing their Uber Happy Dance on this one.)
This raises some very interesting possibilities. Consider some of these.
The Return of the Trade Secret Regime -- Serious players are unlikely to not want to "teach" the honorable competition exactly how they programmed your giant automated package sorting-bar code reading extravaganza that lets you unload a lot of planes, sort all the packages using cool lasers and 3D barcodes, and then get all the packages back on the right plane or truck or bicycle to get them to the customer by the next day invention or their single action ordering system invention. So back to trade secrets and copyright protection we go. A lot of these players didn't want to do patents anyway but felt compelled to go down that path because their competition was. Reverting to a trade secret approach protects their proprietary methods just like in the good old days. It also has the added benefit of making it much harder for the guys in China to steal innovations and market share. (That is if they have a good cyber security regime but I digress.) Not bad.
There are likely to be lots of folks who will want to prevent publication of the pseudocode/XML/UML prior to granting the patent as well especially in light of how easy it would be to let someone clone the invention while the patent was being prosecuted. But this is for the policy wonks to deal with.
The White Board Only Idea Factory Is Dead -- Organizations that sit around and invent things but don't actually build them let along commercialize them would have to get really deep into the weeds to build a compliant patent application, it will take more people more time, and more money. It would also make getting software patents something not for the faint hearted. The added requirement for using notation to document processes is not something you do over the weekend. But in light of overly broad language and fuzzy definitions, it might be interesting.
Invention vs. Vocabulary -- Requiring a code-based roadmap between the claim and the spec so that you can determine what's really going on will in and of itself limit the scope of the software patent.
Consider the world of "in-situ advertising" (aka product placement) in things like video games. While it may not totally eliminate writing stuff like this, it might help:
"A method for providing intelligent advertisement placement in a motion picture, comprising: retrieving personalized data associated with a viewer; comparing the personalized data with a plurality of attributes, each attribute associated with an advertisement image, to determine an attribute that is most consistent with the personalized data; retrieving an advertisement image associated with the attribute that is most consistent with the personalized data; and imposing the retrieved advertisement image on a sequence of image frames of a motion picture."
Followed by some general, broad, fuzzy lingo in the spec like,
"In the multi-media object management system, the production of the Master Program that is used to create the Multi-Media Program typically results in the presence of a plurality of Objects within the Master Program. The multi-media object management system defines a plurality of Multi-Media Object Locations within the Master Program as components of the Multi-Media Program and creates Object Management Data that is used to control the population of these spatial and temporal Multi-Media Object Locations with Objects. These Multi-Media Object Locations can receive animation, audio, moving Objects, stationary Objects, and any other dynamic data. The Multi-Media Object Locations are an integral part of the Multi-Media Program, and their content can be manipulated by referencing a specified Multi-Media Object Location and populating that specified Multi-Media Object Location with a predetermined rendition from the Objects stored in the database. Thus, the image of a beverage can in a Multi-Media Program is populated by any of a number of specific brands of beverages by importing a predetermined representation of the desired brand of beverage into the pre-defined Multi-Media Object Location that is an integral part of the Multi-Media Program. The multi-media object management system enables dynamic product placement in the delivery of a program to a recipient."The inventor or team of inventors would need to explain how the multi-media objects are organized in the database, what the Master Program is and what it actually does, how the program determines which object to pull and under what circumstances, how the digital gizmo moves around the network before the soda ad hits your video game. They would need to write a lot of complex pseudocode or use modeling language to explain how this invention works and what it does, a lot of "if/thens" will be required. And a lot of time, and a lot of really thinking through how these inventions will operate in the real world.
(Not to worry it will take at least five years for the Patent Modeling Language Standards Coalition meetings to agree on a standard which will then be overtaken by… technology.)
More Likely to Be Economically Important Technology Option -- This patent notation approach would make it more likely that an inventor willing to go through making this kind of disclosure has something novel and is more likely to commercialize a product or at least be moving in that direction. Independent inventors and start-ups might benefit by being able to show potential investors or customers how their product will actually work even if the notation requirement is burdensome. (Patent applications for small organizations are burdensome anyway.) It would make it harder for the white board patent shops that get a patent and wait for someone else to commercialize the "idea" and stop by for a visit to collect their royalties.
The Running Away With The Circus Prevention Plan -- As if patent examiners don't have enough to do, they now will need to read lots and lots of code and fit that into the time allocated to each patent application for examination. (We can assume that if you are examining software patents you should know how to read code.) But it's unclear how this new requirement will operate in the real world. Will this reduce pendency? Will the examiners have less but better quality applications to plow through?
But code reading can be boring and dull especially if it's done badly. In light of that, USPTO might need to make sure that none of the teleworking on in-house examiners have access to internet sites or publications seeking people who want to run away with the circus. Depending on who you ask, some of the examiners are very experienced in life in the circus and might find the ability to travel the world as part of their job inviting. A day of code reading might make hanging with the elephants and professional clowns a more compelling and fun career option.
The Programmer and Simultaneous Translator Careers - Now in addition to the gaggle of patent attorneys, claim constructors, drawing drafters, proof readers, and patent prosecution paperwork and fee coordinators, inventors wanting software patents would need to hire a programmer and simultaneous translator type who can both speak patent (generally the patent attorney variety rather than the more generic, "the patent system is broken" variety) and coding - pseudo-C, XML, or UML for the explaining the underlying invention. In theory, these folks should already be at hand, if you are trying to patent a software invention you should have software people. Finding someone talented enough (and patient enough) to do this ought to be interesting considering the sentiment frequently made clear in the "software patents suck" blog-o-sphere that the software people who are most likely to be able to create and use such textual and graphical notation systems, especially the open software types, HATE PATENTS.
Now things are getting interesting - this just might work.
USPTO has put forward a very interesting proposition - extremely difficult and complex to implement but interesting none the less.
If USPTO can avoid the Software Partnership meeting becoming a free for all for the patent hating crowd and if the serious patent people looking to rein in ridiculously broad software and business methods patents can stay focused on the implementation details of making such requirements a reality, this might just have legs.
Must See TV
The meeting, which is also being webcast, will probably a mind-numbing, Powerpoint rich, head-banger but as they say in the entertainment world, must see TV.
