There have been several reports on the EFS-Web listserv that EFS-Web is puking on its own PDF forms. The chief trouble area is the Application Data Sheet form. The user carefully creates a computer-readable ADS and uploads it to EFS-Web. EFS-Web then pukes on the form, stating (falsely) that it is not really a PDF file.
The workaround is to print the ADS to PDF using CutePDF. Then that PDF file can be uploaded to EFS-Web. EFS-Web will gripe that it is not an official USPTO form but will at least permit the e-filing task to be completed.
In the old days I would have characterized this as a Big Problem because in the old days, EFS-Web actually auto-loaded the bibliogaphic data into Palm (and from there into PAIR). But (as I blogged here) USPTO has been gradually chipping away at this and now almost none of the bib data gets auto-loaded. So you might just as well upload a CutePDF version into EFS-Web.
Thanks for posting. This seems to be an ongoing issue with most PTO fillable forms. I’m hopeful the Commissioner and CIO are working on these and other issues, e.g.. using 21st century technology would be a good start.
I have not had this issue. I do know that if you don’t save a PDF using a “real” version of Adobe Acrobat (reader or pro) — and not a non-Adobe program — that you can get this type of error.
One error that we have seen, though, is that with the new ADS, the PTO does not pull the address information from inventors, even though it’s entered (one other person made a comment on another post to this blog saying the same thing).
Which of course leads to a notice of missing parts . . . .
I’m wondering if the problem is that we’re including periods in the address field (“123 Main St.”). We have to file a few applications this week, and will try omitting the periods and see if that does the truck.