A few thoughts and guesses in response to the survey

Having read the responses to the survey, I have spent some time trying to figure out what might lead more people to e-file more US patent applications.

If we were asking about a conventional consumer product we would ask "what is the value proposition for the consumer?" We would ask, what is it that must be explained to the consumer that will prompt the consumer to purchase the product? What will make them select that product rather than some competing product?

What happens if we apply the language of "value proposition" to the filing of US patent applications? The two competing products are paper filings and e-filings.

One practitioner having a client that requires e-filing charges a fixed $600 surcharge to other professional fees for e-filing rather than paper filing. The practitioner feels that on average, the $600 charge does not cover the actual additional internal cost of the e-filing. Stated differently, even a $600 USPTO fee discount might well not prompt e-filings generally for this practitioner.

Many users describe the paper-versus-e-filing decision as a no-brainer. Why should they shift from paper filing to e-filing if it takes longer and costs more money and risks loss of substantive client rights if something goes wrong?

The survey results suggest that fear of loss of substantive client rights is, for many would-be e-filers, a reason not to e-file. Many would-be filers fear that in the XML conversion process, something might get deleted or changed that could not be fixed later. To the extent this is so, it is difficult to imagine what would overcome that fear in any short period of time. Some commenters trace their fear directly to PASAT, and introducing a different XML editor might well help with this fear. Probably what it would take is a year or more of highly visible comments from happy users of a different XML editor.

The survey results also suggest that for many users, simple time and cost issues prompt them to file on paper rather then electronically. They report that it simply takes more time and costs more money to e-file, and they cannot pass that cost on to the client. As such it is a simple business decision to file on paper. What is difficult to tease out from the survey comments is the extent to which this is a PASAT issue and the extent to which it is an XML-conversion issue. Stated differently, if there were a different XML editor that proved to be free from the problems that PASAT has, would this narrow the time-and-cost gap so that more filings would be done electronically?

What could be done to shift this value proposition for would-be e-filers?

Should the USPTO try to penetrate the user's workflow? At present, most US e-filers have a patent application workflow in which only the last couple of steps (XML conversion and submission) take place within USPTO software. The dozen or so previous steps of the workflow do not take place within USPTO software, but instead take place in other software (e.g. standard word processors, scissors and tape). For many practitioners it is commonplace that a to-be-filed paper application (especially one with formulas, circuit diagrams, and chemical structures) will be the result of activity with scissors and tape, or corresponding steps in Acrobat or some other image handling application. Importantly, the filer uses non-USPTO software to get the application "exactly as they want it". In the case of a paper filing, this application is simply printed and photocopied and sent by Express Mail to the Patent Office.

For such filers, if they are going to e-file, they take the application that is "exactly as they want it" and then they use USPTO software to convert the application to XML. For most users this is PASAT, while for those who are in the ABX pilot it is ABX. For PCT filers who are in the PCT-SAFE pilot project, it is the PCT-SAFE editor. The conversion process begins only after the application is "exactly as they want it" and every minute of the conversion process necessarily comes after the application was "exactly as they want it." The timeline works against e-filing; if the application must be e-filed by midnight and if XML conversion is estimated to take an hour, then the filer must somehow arrive at "exactly as they want it" by 11 PM. In contrast if the application is going to be paper-filed, the filer can keep improving and touching up the application until shortly before midnight.

It cannot be over-emphasized how important this time sequence is: first the filer gets the application "exactly as they want it", and only after that does the filer for the first time run the USPTO software to commence the XML conversion.

One approach that has been suggested is to attempt to grow ABX (or some other application) so that it could be offered as a cradle-to-grave workflow application to be used by filers. On this model, of the fourteen or so steps involved in preparing and filing a patent application, USPTO software would be used not only in the last two steps (XML conversion and submission) but would penetrate upwards (or backwards in time) to some or all of the earlier steps in the practitioner's workflow. Perhaps the entire application-drafting process, from initial drafting to client review to finalizing the application, would take place within software provided by the USPTO. To what extent can we guess whether would-be e-filers would use such software? To what extent can we guess whether the availability of such software would lead to a meaningfully higher percentage of e-filing?

One thing that can be observed is that practitioners have done exactly this with PASAT. I, for example, have done so several times. Sometimes I prepare the application in PASAT, export XML and HTML, post the HTML to a password-protected web page, and send the URL to the client for review. After the client's changes are incorporated into the PASAT document, I re-export the XML and the HTML and send the XML to the Patent Office using ePave. A chief risk with this workflow is forgetting to re-export the XML after the last edits have been made. In such an event, the XML sent to the Patent Office is missing the last changes. This could result in an irrevocable loss of a client's substantive rights.

The user comments relating to risk suggest that some users would react negatively to the notion of using USPTO software that penetrates further into the workflow. For some users, they would much prefer to use known and trusted software to get the application "exactly as they want it" and would prefer not to use USPTO software for anything exceeding the bare minimum fraction of their workflow.

Importantly, anybody who is preparing a patent application and who is considering e-filing it is always keeping in mind that there needs to be an "exit path" if the e-filing does not go well. Stated differently, the user wants to be confident at any point in the work flow of being able to "pull the plug" on e-filing and to do a paper filing instead. Ideally this means getting the application "exactly as they want it" using non-USPTO software, and printing it out so that the print copy can be used for a last-minute paper filing if things go wrong with e-filing. That way, nothing that might go wrong with the USPTO software will threaten the reliability and confidence in the paper filing. This need to be able at a moment's notice to "pull the plug" on a proposed e-filing and do it on paper instead runs counter to the idea of having USPTO software penetrating further back into the workflow.

If the USPTO were to pursue a strategy of developing software that is intended to penetrate further into the workflow process, there are potential difficulties. One potential difficulty is that workflow differs from one patent firm to the next. Another is that even for a particular patent firm, the workflow differs from one client of the firm to another. Patent firms use various ways to generate patent specifications -- some use Microsoft Word, but many others use WordPerfect. At Oppedahl & Larson LLP we use both from time to time. It would also be unrealistic to think that all or nearly all patent specifications are created wholly within any particular word processor. For example, many patent specifications are created partly using a word processor and partly using scissors and tape (to insert figures, diagrams, etc.). It is, I suggest, unrealistic to think that any single cradle-to-grave workflow application, even if ideally designed to serve some particular small segment of patent filers, would come to be embraced by a majority of patent filers, because most patent filers would find it poorly suited to their particular workflow needs.

For all the above reasons, I speculate that efforts to penetrate (with USPTO-provided software) further into the workflow of patent firms in the patent application drafting process would be unlikely to be embraced. I speculate that to the extent that lines of code get written, and to the extent that money gets spent, to try to penetrate further into patent firm workflow will be money not generating a return, and will be lines of code that merely add to the risk of software bugs.

Omnivorous XML convertor? One approach that has been suggested is to attempt to grow ABX (or some other application) so that it could be offered as a highly reliable application that is "omnivorous", namely that it could take any well-formed Microsoft Word document and make it into an Annex-F compliant XML patent application body. The idea here is that we would give up on trying to get drafters to use USPTO-provided software for application drafting. Instead USPTO would accomodate the drafters who prefer to use non-USPTO software (here, Microsoft Word). These drafters would use Microsoft Word to prepare the patent application "exactly as they want it". The final Microsoft Word file would be saved and printed out, and the printout would be usable as the "exit path" filing document for a paper filing in the event of difficulty with e-filing.

The further idea is that the USPTO would provide an "omnivorous XML convertor" ("OC"). This piece of software would receive as its input a Microsoft Word file and would yield a content-identical XML file (or family of files). The filer would then be able to file the XML file using ePave and achieve an identical protection of rights for the client as if the paper printout had been paper-filed.

What are the prospects for such a convertor? It would be widely adopted only if (a) it performed flawlessly, and (b) it took very little time, probably on the order of minutes rather than tens of minutes. If practitioners came to know that it never lost anything and did not really need to have its output proofread, then people would embrace it and use it.

But these are big "ifs", both objectively and subjectively. Let us take first the subjective "ifs". Any software released at the present time will be viewed by filers against the backdrop of PASAT. Of course this places an unfair burden upon the developer of present-day software but nothing can be done about it. Every filer who has used PASAT has seen unexplained and undocumented behaviors leading to lost and dropped matter, for example the problem of losing the first word of each paragraph or the first word after a page break. One issued patent (fortunately, a continuation that incorporates a parent by reference) is missing its entire background and summary of invention due to some defect in PASAT.

This means that few filers would simply "trust" an OC (no matter how carefully it is designed) by e-filing its XML output, at least not at first. Instead, the filer would run the OC and then laboriously check the XML output, word by word and line by line, against the source document. This tedious process could take hours for a complex patent application, and these hours would cut into time the filer could have spent touching up and fine-tuning the patent application. This would require the filer to halt the actual application-drafting-and-revising process several hours prior to the e-filing deadline (9PM in California, etc.). This tedious process would also cost money due to the time required.

Turning now to the objective "ifs". Is it a realistic goal to try to design an OC? Perhaps programmers who have spent a lot of time in the bowels of Microsoft Word can answer this question with some confidence. I cannot. I know that Microsoft Word comes in many flavors and versions. There is Word for the Macintosh and Word for Windows. Word for Windows comes in over a dozen varieties. It turns out to make a big difference which "service packs" or "service releases" have been applied to a particular instance of Word. For example PASAT will work with certain versions of Word only if certain "service releases" have been installed.

Overlaid upon this is the staggering feature-richness of Word. Users have a seemingly infinite number of features that can be employed in authoring a Word document. Fonts, character sets, point sizes all can be varied through millions of permutations. Headers and footers can be included in documents. Tables can be used. Embedded (OLE) objects can live within Word files that may have come from any of a wide range of sources including Excel and Access. Macros can make a Word file into a living and breathing organism that changes every time the file is opened. Change-tracking codes can be hidden in the document, as can information about the author and the platform upon which the authoring took place. Microsoft has defined APIs permitting third parties to graft their own software onto Word to suit various ends. Many US filers have such third-party add-ons in their Microsoft Word, for example for document management and for generation of PDF output.

The would-be designer of an OC faces a nearly impossible task in a goal of receiving an arbitrary Word file and making it into an Annex-F-compliant application body. The designer could attempt to devise a "black list" of codes and objects that are to be automatically deleted from the Word file (e.g. forbidden fonts, the use of color, the use of HTML, headers, footers, footnotes, endnotes, certain embedded object types) prior to the XML conversion. Alternatively the designer could attempt to devise a "white list" of codes and objects that are to be permitted to pass to the XML-conversion engine, with everything else in the Word file to be discarded. But crucially, the use of either a white list or a black list puts the would-be e-filer in the position of wondering whether some crucial subject matter in the Word file will end up omitted from the XML file, resulting in a loss of substantive rights for the client.

Actual experience with ABX and typical Word files from clients (inventors' disclosures) has provided vivid illustrations of the magnitude of this task. Observed difficulties include problems with headers and footers as well as seemingly overlapping images on a page.

For the reasons discussed above, I speculate that an effort to design an OC would be unlikely to achieve its goals, due in large part to the undocumented internal workings of Word.

A thin client. If the pessemistic speculations above regarding a cradle-to-grave workflow application and an omnivorous XML convertor are justified, what application is actually worth attempting to develop? My best guess is that the most helpful application at the present time would have the following characteristics:

• Functions as native XML editor
• Rock-steady stability
• Flawless creation of correctly formed XML
• Full compliance with Annex F
• Full support for submission by any submission engine
• Accepting of images from Windows paste buffer

Let me discuss these characteristics in some detail.

Functions as native XML editor. The application would be no more and no less than an XML editor, authoring XML code in real time. The stored file would at all times be XML, and not S4W or DOC. The application would have multiple view such as "tags on", "tags off", and "XML source". The application would block any attempt by the user to insert, say, a tag in a place that is illegal with respect to the DTD. The application would block any attempt to insert, say, a character that is illegal with respect to the character sets defined in the DTD. Any character needing to be quoted (e.g. <, >, &) would be quoted automatically.

Rock-steady stability. The application would never crash. Users would never lose work that had been typed in due to a crash. The design and coding would have zero tolerance for crashes and zero tolerance for loss of data entered by users. This probably requires eliminating almost any dependence upon DLLs found elsewhere in the Windows environment since there is no assurance any DLL will stay the same for any period of time. Automatic Windows updates and installations by third parties can lead to unpredictable DLL changes.

Flawless creation of correctly formed XML. The application, as mentioned above, would never create badly formed XML on its own, and would never permit a user to do so. If the cursor is in a place where a particular tag is not permitted, then that tag would be "grayed out" in the relevant toolbar.

Full compliance with Annex F. The application would, in real time, constantly check any proposed input against the DTD. As a design goal, there would be zero tolerance for any circumstance under which the XML code generated would later be rejected by ePave. A top-to-bottom inventory must be made of all correctness checks made by the ePave server and the ePave client, and all such checks must be made within the XML editing application so that there are never any rejections by ePave.

Full support for submission by any submission engine. The designer of the application must devote all needed resources to make sure that the XML files will be smoothly received by all submission engines that the user is likely to use. At a minimum this is the USPTO's ePave and WIPO's PCT-SAFE. The application is not ready for release to users until it has been thoroughly tested with both of these submission engines.

Accepting of images from Windows paste buffer. The user should be able to use Windows copy and paste (control-c and control-v) to paste images into the application body.

What more can be said about this application beyond the six system requirements just discussed? The most important thing that can be said is that any other optional feature that has any chance, however remote, of negatively affecting the stability and correctness of the function of the application should be omitted from the application. This includes "cradle-to-grave" features as well as "omnivorous convertor" features. The application should be as "thin" as is humanly possible consistent with just barely providing the feature set needed for authoring XML application bodies. Only by keeping it simple is there a realistic goal of coming up with an application that users can trust. And trust by users is the most important quality of any software that is intended to wean users away from paper filings.

This is not to suggest that the USPTO should only develop a thin client, and should hold back from developing "cradle-to-grave" applications and/or "omnivorous XML converter" applications. This is only to suggest that a trustworthy and reliable thin client is needed from some source, and that no other development activity should be permitted to slow down or interfere with the development of a trustworthy and reliable thin client.

Full support for other XML authoring tools. WIPO is beta-testing its PCT-SAFE XML editor for creating application bodies. Patent practitioners are varied in their preferences and tastes and it is very much to be expected that some of them may come to prefer PCT-SAFE to any of the other XML authoring tools, for any of a variety of reasons. Since the overall USPTO goal is to increase e-filings, and since some users are likely to find themselves comfortable authoring in PCT-SAFE, then it is very important for the USPTO to do whatever is needed to fully support PCT-SAFE with ePave. This does not mean the USPTO should be supporting PCT-SAFE as an application or answering questions about how to use it. But it means the USPTO should do everything in its power to facilitate acceptance by ePave of XML files created by PCT-SAFE. This includes allocating support personnel to work with US filers who are familiar with PCT-SAFE to work out whatever needs to be worked out to permit such cross-platform filings. It is urged in the strongest terms that USPTO allocate full-time personnel and resources to support of cross-platform XML authoring tools, including but not limited to the PCT-SAFE XML authoring tool.

Support for PDF filings. Many users report being apprehensive about the XML conversion process. These users worry that if something important got lost in the conversion, substantive client rights could be irretrievably lost. No users, however, have expressed such apprehension regarding PDF filings. Users have a warm and fuzzy feeling about PDF files. They know how to create them, and they know how to print them. They know how to view them later. They know that they can send the PDF file to anybody, anywhere, and when it is printed out it will look just like the user's printout. The point seems so simple to make that it is easy to overlook its importance: users do not worry that important stuff would get lost in the creation of a PDF file. If I use a word processing program to create a patent application that is "exactly the way I want it", I can print it to a PDF file and it will not cross my mind to wonder whether the PDF, later printed out by someone else, would somehow differ from being "exactly the way I want it."

Even if I use scissors and tape to create a patent application (e.g. with images and formulas taped onto the page) I can create a PDF file using a scanner, and again I do not need to worry that important stuff would be lost. It does not cross my mind to wonder whether the PDF file, later printed by someone else, would differ from what I created with my scissors and tape. It is very easy, with a quick visual scan, to check for missing pages (stuck together in the scanner) or skewed pages, and after this quick visual scan I can be confident the PDF file contains what it was intended to contain.

XML conversion, and the attendant word-by-word proofreading that is required to make sure it matches the document that is "exactly the way I want it", can take hours for a complex patent application. This represents a loss of hours that could have been spent making the patent application better. Many users would feel it is better to file on paper if those same hours can thus be spent making the application better.

But think of a PDF conversion. It requires little or no time (as compared with XML conversion time). For most filers it may well require no proofreading at all. If the user has printed out the application and is confident that the application is "exactly the way I want it", the user can print a PDF and may well be equally confident, without even looking at the PDF file, that it is "exactly the way I want it." This means that if the e-filing deadline is 9PM (as it is in California), the user can keep making the application better up until a few minutes before 9PM, then print to PDF, and file the PDF.

Consider how the "value proposition" table above might be completed by a filer for a PDF-filing environment.

What may be seen from this table is an interesting conclusion. Nearly everybody paper-files because it is so easy and fast and familiar and free from worries. PDF e-filing is almost identically easy and fast and familiar. It adds few if any worries. And it permits the filer to obtain the serial number right away. It might sometimes save a late-night trip to the airport post office. The "value proposition" for PDF e-filing is very nearly the same as, and in some ways is more attractive than, a paper filing.

A few comments regarding PDF e-filing are in order. I do not suggest the USPTO start taking the entirety of a patent application in PDF form. I feel strongly the filer should be asked to provide all of the bibliographic and front-page-of-patent information that ePave now requires. I also feel strongly the filer should be asked to provide the abstract in text form, so as to help with creation of what will later be the front page of the patent. Finally, I feel the filer should be asked to provide several distinct PDF files, rather than a single omnibus PDF file. A separate PDF file should be provided for the claims, for the drawing sheets, for the abstract, and for the balance of the specification. Thus in a case with drawings, four PDF files would be provided. Other cases would be composed of three PDF files. Fully XML-coded files should be created by the submission engine (ePave) just as they are now, for fee transmittal, application data, and the like.

Readers who are familiar with PCT-EASY and PCT-SAVE will see these requirements in those applications. Even if the patent specification is provided on paper (as with PCT-EASY) or in three or four PDF files (as with PCT-SAFE), the user is required to provide the rest of the information in text form.

Users have enthusiastically embraced ePave for any and all submissions that do not require PASAT, namely for Information Disclosure Statements and for recordation of assignments. They have shown their willingness to obtain crypto certificates and their willingness to learn to use ePave. This enthusiastic embracing of ePave, together with a PDF submission option, might well lead to greater numbers of e-filings of US patent applications.

In response it has been noted that the European Patent Office (EPO) permits PDF filings and yet even now only a few percent of EPO filings are e-filings. (Of the EPO e-filings, about three-quarters are PDFs.) It is not easy to know the extent to which this is a predictor of what would happen if PDF filings were made possible in the USPTO. Certainly anecdotal comments from US patent filers suggests that e-filing would increase if PDF filings were made possible.

Use filing date to encourage rather than discourage e-filings by those who are in time zones that are west of Virginia. At present, a filer in California who e-files receives a filing date that is three hours worse than a paper-filed filing date. This discourages e-filing. If the USPTO is going to have a system in which the e-filed filing date is different from the paper-filing date (and it is not clear why this should be so) then common sense suggests the USPTO ought to make the e-filing date better than the paper-filing date.

The experience of the Trademark Office may be instructive. The Trademark Office no longer permits the use of Express Mail to obtain a filing date that is the same as the mailing date. The e-filing percentage for US trademark applications is now quite high, well over 50%. Some of this may be due to the filing-date incentive, namely that most trademark e-filings get a filing date that is at least a day earlier than the paper filing date.

One way to give an incentive for patent e-filing would be to take away Rule 10, namely, to end the use of Express Mail to obtain a filing date that is the same as the mailing date. My guess is that this would be unworkable until such time as the software provided for patent e-filing were (a) to prove to be bug-free and reliable and (b) to be trusted by filers as being bug-free and reliable.

Another way to give an incentive for patent e-filing would be to provide a filing date based on the time in Alaska. The difference between the paper-filing fiing date and the e-filing filing date would thus favor e-filing rather than favoring paper filing.

In response it has been noted that there is no "cottage industry" of service bureaus in Hawaii, receiving faxed patent applications from points east for Express Mail filing in Hawaii. It is not easy to know the extent to which this is a predictor of what would happen if the filing date were to favor rather than disfavor e-filings. Anecdotal comments from US patent filers suggests that e-filing would increase if this change were made.

Other possible incentives to increase e-filings. A variety of other possible incentives for e-filing have been proposed. These include:

• Filing-fee incentives. A few commenters indicated a filing-fee incentive would make a difference to them. Other commenters have said that even making the filing fee zero for e-filed applications would not suffice to motivate them to e-file, due to the increased internal cost to e-file or due to fear of liability to a client if the e-filing were to omit some essential subject matter.
• Eliminate paper filing. If paper filing were simply eliminated, then e-filing would instantly reach 100%. My feeling on this proposal is the same as for the elimination of Rule 10, namely that this would be unworkable until such time as the software provided for patent e-filing were (a) to prove to be bug-free and reliable and (b) to be trusted by filers as being bug-free and reliable.

Other ways to try to increase e-filings. Other approaches to try to increase e-filings include:

• Direct outreach. USPTO reaches out directly to filers to encourage them to e-file. There has, in fact, been quite a lot of outreach. Every registered practitioner has received at least two courier-delivered CD-ROMs with USPTO e-filing software within the past three years. It seems unlikely that any registered practitioner is unaware that it is possible to e-file US patent applications or that the USPTO would like to encourage such e-filings.
• Outreach through professional associations. It is possible to imagine outreach to practitioners through professional associations such as AIPLA, for example through the AIPLA's E-Commerce Committee.
• Outreach through Internet discussion groups. Each time that some concrete advance is made in the e-filing process, that advance could be promoted to practitioners through list servers such as the Patents-L and EFS discussion groups. Examples of such advances could be:
  • availability of PDF filing
  • proven compatability of PCT-SAFE with ePave
  • successful rollout of ABX
• Cross-promotion through PAIR and ePave. The widespread acceptance and popularity of private-side PAIR has led a large fraction of US patent practitioners to obtain cryptographic certificates and customer numbers. Of course any would-be e-filer needs to have a cryptographic certificate and customer number. Any and all feature enhancements and improvements to PAIR will thus naturally nudge practitioners toward e-filing. Likewise, practitioners have enthusiastically embraced ePave for e-filing of IDSs and assignments. Any and all feature enhancements to ePave (e.g. allowing entry into the US national stage) will thus naturally nudge practitioners toward use of other features of ePave such as patent e-filing.

See also a comparison of the USPTO and WIPO e-filing systems.