(It took a couple of days, but USPTO did eventually acknowledge that it broke the XML import feature. See a followup post here.)
By way of background, for many years, since the first days of EFS-Web, it has been possible using Acrobat to import bib data from an XML file on the user’s hard drive into the Application Data Sheet (PDF) file such as Form PTO/AIA/14. The resulting PDF file could then be uploaded into EFS-Web.
Bruce Young, who is an alert member of the EFS-Web listserv, recently reported that when USPTO released version 2.1.12 of its Application Data Sheet PDF form, USPTO broke the XML import capability of the form. As Bruce explains:
Older versions of the ADS form, up to and including 2.2.11 (number in lower left corner of the form) allowed an .xml file to be imported into the form to populate it. … I use this feature because my docketing system (AppColl) can create a .xml file with all of the correct information that I have entered into that system, so I don’t have a possibility of typos once the information has been correctly entered into my docketing system.
But [the new version of the PDF form] for some reason does not allow the importation of a .xml file. The menu option for Import Data is greyed out for some reason.
The unhappy consequence of this action by USPTO, breaking the import feature, is that users are forced to hand-key bib data into the PDF form. This increases the risk of a user completing the ADS form incorrectly.
USPTO should repair this form, re-enabling the XML import feature of the form.
It is still possible to import xml into the new ADS form, just not with Adobe Acrobat Reader. You need to upgrade to Adobe Acrobat Pro. Unfortunately, it is not free.
I was using the paid-for Acrobat. I was still unable to import the XML. I wonder what is going on here?
Slightly faster than hand keying but you can save a copy of the ADS first and then import works. I did this successfully on Thursday with an .xml file create from the old ADS form. (although we do not use AppColl so results may vary)
I noticed this as well, but there is an easy fix.
When I try to import an XML into the form as downloaded from the PTO web site (using Acrobat Pro XI on my Mac), it says “this document restricts some Acrobat features . . . . ” However, it gives me the option to save a copy of the form, and then I can import XML into the saved copy.
I don’t use Appcoll, but rather using a custom docketing solution. The XML that I was generating for the old ADS wouldn’t import into the new version of the form. The schema changed, and therefore I had to rework some things to create XML that satisfied the new schema. I’m not sure if this will be a problem with Appcoll.
If for some reason the solution I’m describing above doesn’t work, I can provide a link to the copied ADS form on my server for people to download — let me know.
Please feel free to share this information on the EFS-Web listserv.
Thank you for posting. I recall seeing this message as you described, and then I tried to proceed, and somehow it did not work for me. But encouraged by your report I will try harder.
Let me know if it does not work for you, and I’ll expose the file (into which you can import XML) on my server for download.
The PTO needs to up their Adobe team. I have scripts to automatically generate all of the forms we use, and the naming conventions for the fields (“acrofields”) that the PTO programmers use are atrocious. Misspellings. Field names that are sentences in length.
Any my favorite — they added a bunch of parentheses in some field names, which are per Adobe guidelines not permitted, because parentheses are special delimiters apparently. It broke the FileMaker plug-in I use. Thankfully, the developer gave me a fix within 24 hours, but he said that in ten years of maintaining the plug-in, and after having seen hundreds of forms, he had never seen such bad form creation before (this was for the QPIDS I believe).
If someone has an .xml file format with the field names, would you be willing to share that file? I would love to be able to export certain data from our system into a form that could be imported. It would save the copy/paste step for each field.
This turns out to be easier than you might think. Just take one of your existing ADSs and export the XML from that ADS. You can then see the field names.
One note about the .xml format, FWIW. I’m not very knowledgeable about XML, but of course an XML file is just a text file. What I did was make up an ADS by adding crazy amounts of data in terms of priority information and what have you, and then exported that to see the basic structure of the text file.
It’s definitely the toughest form to generate data for, because of the dynamic nature of the form in terms of inventors and priority info.
The USPTO revised the ADS form in November 2015 to add the “Authorization or Opt-Out of Authorization to Permit Access” but did not change the form number from 2.2.12 to 2.2.13. The old ADS form 2.12.12 had been in use for at least a year. I reported the failure to change the form number, but it has not been fixed. The new ADS form 2.2.12 had several problems in addition to breaking the XML import feature. One problem is that it initially took several days for an application including the new ADS form filed via EFS-Web to appear in the image file wrapper. That problem has been fixed. Another problem is that the applicant’s name but not the address is automatically imported from the new ADS form, and the assignee’s address but not the name is automatically imported from the new ADS form. I reported that problem, but do not know if it has been fixed.
I’m glad that we’re not the only one with this problem with the new ADS form. We are getting tons of notices of missing parts because we did not specify applicant addresses, which of course are in there . . . .