splitting up the PASAT and ePave tasks in filing a patent application

Most people who e-file US patent applications probably do the XML tagging (that is, the PASAT work), the conversion to Annex F XML tags (that is, the XPort work), and the project submission (that is, the ePave work) on the same computer with the same person performing each task. This article points out that it is possible to allocate these tasks to two (or three) computers and to two (or three) people. This could be handy for any of several reasons:

It may well develop that some tool other than PASAT will come to be available for use in US e-filings. For example the WIPO XML editor may turn out to be adaptable for use with US e-filings. There are also rumors that the USPTO will soon be releasing a new XML editing tool which could be used instead of PASAT. The steps described below will likely be helpful in working out which files are the important ones to create with such a new or different tool so that the specification will be accepted by ePave.

Here are the things to do if you wish to split up the tasks, and some factors that might influence how to split up the tasks.

One person does the PASAT work, a second person does the XPort and ePave work. One reason you might choose to split up the tasks this way is that often XPort will run without problems. That means it is a good candidate for allocating to the second person so as to save the first person from having to do the XPort steps. Another reason you might choose to split things up this way is that you only need to transfer a few files from the first person to the second person. A potential drawback to splitting things up this way is that XPort might announce errors in which case the first person needs to return to the computer to try to figure out what to do in PASAT (or with the TIF images) to keep XPort happy.

The first person (the one doing the PASAT work) needs to make a new folder which will contain the PASAT files. Then, using PASAT, the first person creates the application XML file. (Meanwhile the second person can be doing most of the ePave work such as typing in inventor names, inventor addresses, etc.) By the time the first person is done the folder will contain files such as the following:

application.err
application.s4t
application.s4w
application.xml
fig1.tif
fig6.tif
figs2-3.tif
figs4-5.tif
specif.xsl
u-specif.dtd

The files which I have shown in italics are the files that must be provided to the second person. We did this by emailing the files. This approach has the drawback that the receiving email program may rename them. (If you email a file to someone that has a name identical to a file that someone previously emailed to that person, then the email program is forced to modify the file name so that it is no longer identical. For example, Eudora will add a numerical digit such as "1" to the end of the file name.) The second person then should copy the files into a new folder. This is the folder that will be used as an input to XPort to create the "trans.XML" file which is then given to ePave to be attached to the project.

Instead of emailing the files, it would be more elegant to use a shared folder on a common file server over a network.

Note that the figures must be in the same folder as the XML file.

Note that there is no need to send the S4W, S4T, or ERR files.

Note that specif.xsl and u-specif.dtd must be provided even though they are always exactly the same for every filing.

The second person then runs XPort, and can then attach the "trans.XML" file to the ePave project for filing.

The second person needs to watch out for the usual problems, for example if the title as provided in the XML file is capitalized differently than the title as typed into the first ePave screen, then ePave will refuse to validate the project. For a utility application the second person will not, of course, be able to type in the number of total and independent claims until the first person has finalized the claims.

One person does the PASAT work and the XPort work, a second person does the ePave work. One reason you might choose to split up the tasks this way is that sometimes XPort will announce errors, in which case it is necessary to go back to PASAT (or to the TIF images) to try to figure out what to change to make XPort happy. A drawback to splitting up the tasks this way is that the number of files to be forwarded from the first person to the second person is much larger, two dozen or so.

The first person (the one doing the PASAT work) needs to make a new folder which will contain the PASAT files. Then, using PASAT, the first person creates the application XML file. (Meanwhile the second person can be doing most of the ePave work such as typing in inventor names, inventor addresses, etc.) The first person then runs XPort. By the time the first person is done the folder will contain files such as the following:

 specification.err
 specification.s4t
 specification.s4w
 specification.xml
 specif.xsl
 u-specif.dtd
 specification-trans.xml
 sheet1.tif
 application-body.dtd
 isoamsa.ent
 isoamsb.ent
 isoamsc.ent
 isoamsn.ent
 isoamso.ent
 isoamsr.ent
 isobox.ent
 isocyr1.ent
 isocyr2.ent
 isodia.ent
 isogrk1.ent
 isogrk2.ent
 isogrk3.ent
 isogrk4.ent
 isolat1.ent
 isolat2.ent
 isomfrk.ent
 isomopf.ent
 isomscr.ent
 isonum.ent
 isopub.ent
 isotech.ent
 mathml2-qname-1.mod
 mathml2.dtd
 mmlalias.ent
 mmlextra.ent
 soextblx.dtd
 us-application-body.xsl
 wipo.ent

The files which I have shown in italics are the files that must be provided to the second person. We did this by emailing the files to the second person, which has the drawback that I was not able to send the files all in a single email; the email program would only do a few attachments at a time. This has the further drawback, as mentioned above, that the receiving email program may rename them. (If you email a file to someone that has a name identical to a file that someone previously emailed to that person, then the email program is forced to modify the file name so that it is no longer identical. For example, Eudora will add a numerical digit such as "1" to the end of the file name.)

The second person then should copy the files into a new folder. This is the folder that will be used as an input to XPort to create the "trans.XML" file which is then given to ePave to be attached to the project.

Instead of emailing the files, it would be more elegant to use a shared folder on a common file server over a network.

Note that the figures must be in the same folder as the XML file.

Note that the thirty files shown in blue above must be provided even though they are always exactly the same for every filing.

Note that it is not necessary to provide the specification.xml file, only the specification-trans.xml file.

Note that there is no need to send the S4W, S4T, or ERR files.

I believe it is not necessary to send the specif.xsl or u-specif.dtd as ePave probably does not need them.

The second person can then attach the "trans.XML" file to the ePave project for filing.

The second person needs to watch out for the usual problems, for example if the title as provided in the XML file is capitalized differently than the title as typed into the first ePave screen, then ePave will refuse to validate the project. For a utility application the second person will not, of course, be able to type in the number of total and independent claims until the first person has finalized the claims.

A suggestion. It is probably advantageous to practice this splitting-up process a few times on applications that do not have time pressure. That way, when you face some application that needs to be filed shortly before midnight Eastern Time, you will already have become familiar with the process.