Today's Date: October 30, 2014 Search | Home | Contact | Services | Patent Attorney | Patent Search | Provisional Patent Application | Patent Application | Software Patent | Confidentiality Agreements

Bringing Digital Government to the Patent Office

Written by Tom Brow
Software Developer, Entrepreneur, Inventor
Developer of the iEFS Mobile App
Posted: March 6, 2013 @ 3:11 pm
Tell A Friend!

One year ago, the USPTO Museum packed away 30 man-sized, glowing iPhones. It was the last day of an exhibit commemorating the life and inventions of Steve Jobs, and the oversized mock-smartphones were displaying trademarks and patents in his name. But is it as easy to view those patents on your ordinary, pocket-sized iPhone? Or file a patent application from an iPad?

The USPTO is one of many federal agencies struggling to comply with the mandates of the White House Digital Government Strategy for 2013 – namely, that digital information and services must be available “anywhere, anytime, on any device”. Meeting the government standard will entail not just polishing USPTO.gov for use on smartphones and tablets, but also a substantial overhaul of the way the agency exposes data to patent practitioners and the public.

You can’t take it with you

The Digital Government Strategy is motivated in part by the staggering success of smartphones and tablets in the US market. The document forecasts that mobile devices will surpass desktop PCs as the predominant mode of Internet access by 2015, and notes that near half of American adults already own smartphones. Despite this trend, the president notes in his introductory memorandum, online government services often neglect to accommodate mobile devices.

USPTO.gov, in particular, is mostly indifferent to mobile web browsers. Pages are not specially formatted for the small screen, and are navigated only through a good deal of zooming and panning. iPhone and Android users are familiar with this routine, having been forced through it by many other public- and private-sector websites.

The circumstances are worse for USPTO.gov’s most dedicated visitors: the attorneys and agents who prosecute patents electronically through the site. In order to file an application or view outgoing correspondence online, the practitioner must authenticate using a private certificate and password. The process relies on an antiquated browser plugin, Java, that has not been welcomed into the new operating systems that power modern smartphones and tablets. As a result, mobile prosecution is possible only through a traditional operating system running on a laptop or netbook.

To rectify the situation, the PTO will need to break its dependence on browser plugins and on the proprietary authentication system it has licensed from Entrust. Rather than license another proprietary system, the agency should follow WIPO’s example and adopt a standard certificate format compatible with modern browsers’ built-in authentication capabilities.

The PTO may eventually provide an alternate site formatted for mobile devices. However, the Digital Government Strategy discourages that approach as a duplication of effort, and encourages agencies to target all devices with a single site by embracing responsive web design.

There’s not an app for that

The void left by mobile-inaccessible websites is often filled by mobile apps that can be installed on the device. Such apps require the website’s underlying data to be available in a machine-readable format. In recognition of this fact, the Digital Government Strategy directs every federal agency to open a machine-readable API to the public.

To its credit, the PTO can boast a public API that predates the government mandate by years. In 2010, the agency partnered with Google to offer bulk downloads of patent applications and grants, including some machine-readable data. However, Google’s monolithic archive files, many weighing in at more than 7 gigabytes, are an impractical data source for a mobile app – perhaps why the Digital Government Strategy specifically disqualifies “simply publishing snapshots of government information” as an acceptable API. Instead, patents and their accompanying data should be downloadable on an individual basis.

If the PTO does elect to provide fine-grained access to its data, it will still have wide discretion in choosing which data to expose. The Strategy directs agencies to select the data of highest value to their customers, where the definition of “customers” is also left to the discretion of the individual agency. Said discretion can produce uninspiring results; the Department of Defense chose to share the data of its obscure Lock Performance Management System.

If the PTO regards patent practitioners as its primary customers, then its APIs should expose all data necessary, and through a sufficiently sophisticated interface, for a third-party app to replicate the features of Public PAIR and E-Patent Reference. The PTO could exceed the government requirement by also providing an authenticated API to facilitate privileged actions such as filing patent applications.

Conclusion

The presidential memorandum introducing the Digital Government Strategy set a deadline of August 21, 2012 for agencies to post a public progress report. The date came and went with no report from the PTO and most other agencies. Time still remains, though, for the PTO to meet the Strategy’s final deadline – May 23rd, 2013 – for implementing the API requirement and mobile usability guidelines. The Department of Labor developer site is already public and is a fine example for the PTO to follow.

Acting PTO director Teresa Rea has inherited an agency that is still preoccupied with implementing the America Invents Act. But the Text2PTO initiative begun last year is evidence that the agency is also investing in data infrastructure and improving the site for practitioners. The PTO graduated many years ago from what President Obama called an “embarrassing” electronic system, and this year has the opportunity to unveil an exemplary one.


About the Author

Tom Brow is a software developer, entrepreneur, inventor, and former patent firm employee. His mobile app, iEFS, helps patent attorneys and agents do their work from anywhere. He holds a BS in Computer Science from Stanford University.

7 comments
Leave a comment »

  1. It is unclear just what the author is suggesting. Is he suggesting that some system, such as Entrust, be substituted for the present system implemented in Java on PC’s and Macs? If so, that would violate one of the unwritten principles of computer technology, that no change in a standard should invalidate a currently working program or system. (I served on an ANSI language standards committee for years and this was Rule 1.) If the author is merely suggesting that a means for mobile device users be added to the present system, that is a different argument from the one he appears to make. Consider his gratuitous slap at Java as “antiquated”. Java has in its favor one powerful aspect – it works.

    Notice that the author may have a horse in this race. He needs to explain how he, personally, would benefit from the suggested changes, if at all.

  2. It seems to me that there are several fundamental changes the USPTO needs to make before worrying about mobile apps. My wish list includes:

    1. Accept file names with spaces in them for EFS.
    2. Preserve PDF color images so that said images are not substantially degraded by conversion to low resolution B/W TIFF. This is especially important for NPL submissions.
    3. Accept standard PDF format that does not have font embedding. This is also very important for NPL submissions.
    4. OCR PAIR so that documents can be searched.

    Anything else to add?

  3. II think I must be getting too old. My first thought was what comes next after the iPad and iPhone? After the USPTO spends a gazillion dollars and beaucoup years time getting secure, government approved software allowing me to efile applications with my iPhone, how long will I be using my iPhone?

  4. Hi tifoso,

    Entrust is the private company that provides the USPTO’s present, Java-based authentication system. I am advocating that that system be replaced with one like WIPO’s, which does not depend on the Java browser plugin. This substitution would strictly increase compatibility; any PC or Mac that can access USPTO’s system can also access WIPO’s system, but the reverse is not true.

    I describe the Java browser plugin as antiquated for two reasons. Firstly, every new mobile operating system in the last decade — iOS, Android, BlackBerry, Windows Phone, and Palm’s webOS — has elected not to support the plugin. Secondly, the plugin contains such significant security flaws that the Department of Homeland Security has advised all users to disable it on their computers. Recent security breaches at Apple and Facebook were due to employees ignoring that advice. (Note that none of the above applies to Java in general, only the browser plugin.)

    The product that I sell, iEFS, is a technical workaround that enables using USPTO’s present system on iOS devices. If USPTO were to implement the suggestions I make in this article, they would obviate the need for a workaround. I developed iEFS because I do not expect USPTO to do that in the immediate future.

    However, the measures I propose in this article would benefit software developers as a class. You raise a good point, that it is important to disclose that interest.

  5. Tom –

    What about users who do not use mobile apps? Will the implementation of a mobile app accepting system run in parallel to or be a replacement of the current system? IOW, if someone wants to use a PC, will anything change for that user?

    Tifoso

  6. Hi Tifoso,

    My opinion is that USPTO.gov can and should be made to work on mobile devices without disturbing the experience for existing users on Macs and PCs. The technologies recommended by the White House — machine-readable APIs and responsive web design — are suited to providing a mobile-friendly system “in parallel” rather than substantially replacing the existing system.

    The Entrust authentication subsystem is an exception; it will probably be replaced wholesale due to the issues surrounding Java that I mentioned before. There will be one certain disruption to existing users: they will be issued new certificates to replace their existing, proprietary-format ones. They will need to follow some steps to install the new certificates in their browsers. However, this is a one-time inconvenience and is comparable (in my opinion) to regular inconveniences associated with the Entrust system.

    All that said, Mark raises a good point that there are known, unaddressed problems in the existing system. It’s hard to argue that expanding compatibility to mobile devices won’t distract resources from solving those problems.

  7. While we’re at it, can we eliminate the need for Captcha on public PAIR? :-)