A long-felt need in the TEAS system

The TEAS system is the system that trademark practitioners use to generate documents to be reviewed and e-signed by clients.  A typical form to be reviewed and signed by a client might be a new trademark application or a six-year renewal or a ten-year renewal.  There is a sort of design flaw in the TEAS system that represents a long-felt need for correction.  This blog article describes the design flaw and describes two possible ways to address the design flaw. 

I will first provide a bit of background about the TEAS system.  Regular users of the TEAS system will be very familiar with this background.  The idea is that the trademark practitioner selects a particular form in the TEAS system, and then completes many dozens of fields in the form.  This is a very complicated process and can take anywhere from ten minutes to almost an hour, depending on the particular form involved and the details of the client’s situation.  Often there is a need to upload one or more files for use as specimens of use or as a drawing of a logo mark.  If the form being completed is a “plus” trademark application, there will be a need for dozens or even hundreds of mouse clicks for a successful surfing adventure through the ID Manual to accumulate a desired list of goods and services.

Eventually the practitioner will have arrived at a nearly completed document that is ready for review by the client.  The practitioner then does a last half a dozen mouse clicks that results in the receipt of an email message that contains an extremely long URL.  The URL is a link that points to a place in the TEAS system.  The idea here is that the practitioner then somehow communicates the URL to the client.  The client launches the link in a web browser.  This opens a web page in the TEAS system that displays the document for the client.  The client is then able to review the document.  The client can scroll down to the bottom of the document and can e-sign it.

If the client e-signs the document, then what happens is that the TEAS system sends an email message back to the trademark practitioner.  This email message contains yet another extremely long URL.  That URL is also a link that points to a place in the TEAS system.  The idea here is that the practitioner clicks on this link in a web browser.  This opens a web page in the TEAS system that displays the (electronically e-signed) document for the practitioner.  The practitioner is then able to e-file the document at the USPTO, which sometimes also involves paying a government fee to the USPTO.  The result will hopefully be the successful e-filing of some important document at the USPTO, such as a new trademark application or a renewal of a trademark registration.

Which brings us to what I call “the fourteen-day limit”.  The designers of the TEAS system made it so that each of these URLs that provides a link to a saved form is a URL that remains functional for 14 days.  So for example the practitioner can send the link to the client for review, and the client can sit on it for 13 days and then review the document and e-sign it, and that will work.  Then as mentioned above an email gets sent to the practitioner to let the practitioner know that the client e-signed the document, and the email contains a second link.  That link also remains functional for 14 days.  This means the practitioner could sit on it for 13 days and then click to e-file it (and pay the government fees if applicable).  Thus the entire communications cycle might drag on for 26 days or a little more.

The disaster that can strike comes when the USPTO decides to make software changes to the TEAS system.  For example, tomorrow, Saturday, December 18, 2021 is a date upon which the USPTO is going to make some software changes to the TEAS system.  One of the things that happens when the USPTO does this is that all of the links for the in-progress TEAS forms get discarded.  This means that every in-progress e-filing project gets lost.  Let me describe this in practical terms:

  • Suppose a practitioner had sent a document to a client for review and possible e-signing at any time on or after about 8 AM on Sunday, December 5.  Normally, the client would expect to be able to carry out the review and the e-signing any time up to and including the afternoon of Saturday, December 18.  But because the USPTO discards the in-progress links, the client would find that the link no longer works.  The practitioner would need to generate the document all over again.  As mentioned above, this might take minutes or even hours to do.
  • Suppose a client had carried out a review of a document (which might take quite some time) and had concluded that the document could be signed.  And then suppose the client then e-signed the document, perhaps on Sunday, December 5.  Normally, the practitioner would expect to be able to carry out the e-filing and the payment of fees any time up to and including the afternoon of Saturday, December 18.  But because the USPTO discards the in-progress links, the practitioner would find that the link no longer works.  The practitioner would need to generate the document all over again.  As mentioned above, this might take minutes or even hours to do.  And then the client would have to carry out the review all over again, and would then need to do the e-signing all over again.  

There is a procedure by which the practitioner can generate and can “save” a data file (called “an OBJ file”) at the time of generating a document that is to be sent to a client.  The OBJ file can be used at a later time to regenerate the document for later editing and perhaps to send to the client again.  But generating and saving this OBJ file requires extra steps and consumes extra time.  The practitioner has to select some location for storage of the data file so that the data file can be located again, perhaps by other office personnel, at a later time.  It is up to the practitioner to decide whether or not to go to this extra trouble in particular cases.  It might be thought that this optional step of saving an OBJ file, if consistently carried out by all filers, would sufficiently protect against the problem of the USPTO discarding all of the in-progress forms when it updates software.  But often the OBJ file is unusable after the software change.

Of course if the USPTO people who make decisions about discarding all of the in-progress links were to notify all of the practitioners 28 days in advance, then during the 28-day period, a practitioner could know to badger the client to carry out the reviewing and e-signing without delay.  And the practitioner could know to avoid going on vacation during the 14-day period for e-filing and payment of government fees, or could make arrangements to watch closely even during vacation time for the incoming link so that the e-filing and payment of fees could be done during the vacation and without delay.

The observed behavior of the USPTO people is, however, to provide very little advance notice of the discarding of all of the in-progress links.  The discard that will happen tomorrow, December 18 was first communicated to users only four days in advance, on December 14.  Regrettably the scheduled discard was not communicated directly to practitioners (even though the USPTO does know the email addresses of the practitioners from past TEAS filings).  Instead the scheduled discard is only communicated in two oblique ways.

One oblique way that the planned discard of all in-progress links got communicated was on a “status” page.  The idea I guess is that all users would be expected to go and check the contents of that “status” page, perhaps daily, to see if by some chance anything new had been posted there since the previous day.

The other oblique way that the planned discard of all in-progress links got communicated was on a banner message that one might notice if one were to start doing a new TEAS filing on or after December 14.  The idea I guess is that a user who had started a first filing before December 14 might also by some chance also start some second filing after December 14, and would then learn that the first filing was in great jeopardy.  

This is a bad design flaw.  What should not happen is that a customer finds out “the hard way” that a filing that started, say, on December 10 is going to get flushed down the toilet on December 18.  And the way they find out is by trying to click on the link on, say, December 19 and the link does not work.  So far as the filer knew, the link should have kept working until about December 24.  But instead, the link got flushed down the toilet on December 18 because of the decision that USPTO personnel made on December 14 that they would flush all of the links down the toilet on December 18.

Maybe you can see where I am going with this.

First, a truly user-friendly way to handle this would be to go to the trouble to preserve the links from before a software update to keep the links working even after the software update.  I guess this is too much to ask.  So, failing this, we turn to what a user-friendly Office would do for example on December 14.  When the USPTO people made the decision on December 14 that four days later all of the in-progress links would get flushed down the toilet … why not send a courtesy email to the filers whose email addresses are embedded inside those links that are at risk?  Let them know that their links are going to stop working much sooner than the expiration of the normal 14 days!

This is the sort of thing that computers are supposed to be good at.

And let’s suppose the date is December 15.  This is the day after the USPTO made their decision that they are going to flush all the in-progress links down the toilet on December 18.  So very prominently at the screen where the user first enters information into the first fields, why not put a big red banner there that says something like:

You know you will only have two days to get all of this completely done, right?  (The number “two” being updated in real time to whatever the correct number is depending on the dates involved.)

That is also the sort of thing computers are supposed to be good at.

10 Replies to “A long-felt need in the TEAS system”

  1. Very important because the US Patent and Trademark Office is destroying the work of practitioners without reasonable notice. This destruction can also infect the relationship between the practitioner and their clients. Clients are not happy to receive dead links about important matters.

  2. Unfortunately, usually when the PTO makes changes the .obj files that you can save your work in stop working, too.
    Notice their current warning: “File all saved forms and e-signature forms by 7:59 a.m. ET on Saturday, December 18. If you don’t file these forms by that time, you will have to start the process again with new forms.” Another poor design.

    1. Richard’s comment is important enough to warrant an edit to the blog post. The saved OBJ files are often unusable after a TEAS system update, so there is no other option than to start from scratch.

  3. Two good suggestions (last 2 paragraphs). I guess that the TEAS links expire after eg 14 days standard, because after some TEAS changes the past data won’t properly populate all the required data fields, new and old. For example, a form saved before client email and practitioner bar state and number were required.

  4. I agree wholeheartedly, Carl.

    The more or less constant invalidation of .OBJ files also makes it pretty much impossible to save a template for a client who is a frequent filer.

    Dumb question, more a comp sci question than a TM one: is there any particular reason WHY the OBJ files should stop working every time they update TEAS? The forms that we see rarely change much, if at all, when the system is updated. If the OBJ files are for the most part just information that goes into particular fields, why is it so hard to keep them working properly? From my (admittedly uninformed) perspective, this seems like the equivalent of Microsoft updating Word with a small patch and then telling you Word won’t work with any pre-patch .docx files.

    1. It looks like the OBJ files are a serialized instance of some class that represents a form in TEAS. Whenever that class’s code (or the code of any serializable class an instance of which is used in that class) is changed, even slightly, the class signature is changed and when it goes to read in the serialized data, it throws an error because the data is an instance of the old class, which the new code doesn’t know anything about. When I run the Unix file utility on an old OBJ file I had lying around, it appears to be Java serialization data, and using a utility that translates serialization data into human-readable form indicates that it was an instance of the gov.uspto.teas.apps.postreg.model.PostRegFormValidator class. This isn’t a great design decision for exportable data, but it was probably an easy solution at the time it was developed.

  5. agree with you about the need for advance notice to avoid the results you describe. I have a paralegal preparing my applications for me (based on my directions), so I myself don’t have to redo applications that are lost this way, but I end up paying extra for him to redo them when this happens.

  6. As with much of the PTO’s software systems like TEAS, the invalidation of in-progress links and the saved .OBJ files are the results of design decisions that almost certainly were never disclosed to practitioners during the development process. Who among us would have agreed with a design decision that meant “every time we change the software, any work in progress has to be thrown out”? Indeed, I suspect that the developers themselves may never have considered the consequences of their design decision that created such a fragile way of saving the progress of completing a TEAS form.

    Rather, I suspect that if the concept of saving work in progress was ever discussed with practitioners it was done at the high level of “Would you like to be able to save your work before completing a form?” “Why, yes, of course.” At which point the system architect made the decision that what they needed was a way to efficiently save the state of the form completion procedure. That saved state could then be reloaded back into the system and the form completion procedure could complete. The developers may even have been praised for a clever solution to the “save my work” problem. Which it was, until the unintended consequence of further development occurred and someone discovered, “Oh! That state we saved before changing the code doesn’t work any longer.” And someone else probably said, “Well, maybe no one will ever notice because no one will need to save their progress for long enough to matter. And it’s too late to design another state-saving technique now.”

    However, if the PTO had asked any practitioners, they would have explained that in reality clients drag their feet on signing things and take their time in providing acceptable specimens. Other things can happen that may halt work in progress for extended periods of time. And practitioners would have told the designers that a form of saving work in progress that was so fragile would not only cause a minor annoyance but would potentially require large amounts of work to redo. Data might have to be collected again. All the effort that was put into ensuring the form was correct has to be done over. Annoyed clients will object to discovering that what their attorney sent them doesn’t work. And even after all that, there’s no way to be sure that what is redone matches what was originally done, without some form of reverse engineering an undocumented binary file format. And the problem is exacerbated by the PTO’s tendency to make changes to the software on short notice.

    All because of a terrible design decision that probably looked clever at the time, but has now cost hours and hours of time for both attorneys and clients. A different design decision that leaned toward robustness and practitioner efficiency instead of reloading efficiency would have avoided that loss of work. Something as simple as saving the contents of every form field into an XML file might have been better. An alternate solution might have been less efficient and would almost certainly have required more detailed checking of the saved data before reloading it into the forms to avoid errors or even exploits like the recent log4j problem caused by carefully crafted malicious data. But that’s what computers are good at doing. (As a side note, I wouldn’t guarantee that the current design couldn’t be reverse engineered and some malicious data injected into the OBJ file that would cause problems for TEAS. So I hope the PTO systems are already doing that kind of data checking, instead of just assuming everything in an OBJ file is safe.)

  7. I wonder if we could get any leverage by using the USPTO’s DOCX arguments against it, namely, by urging the USPTO to scrap the OBJ files for a “standard” like XML. If the patent side is expected to adopt a “standard” for the USPTO’s benefit which is purportedly used by other offices, why can’t the USPTO adopt a standard that other offices are using?

    Adding to the Xmas wish list, the USPTO would provide information regarding the nature of the periodic updates so that an old XML file could be edited to make it current and usable. Most likely, any system changes would not affect client-specific data, so the XML edits could be done in far less time than a complete re-entry through TEAS.

  8. A further comment is based on something Kevin Grierson pointed out in the e-trademarks listserv. The design decision for the OBJ file only works for saving a work-in-progress, and cannot be used for a template, because it contains too much application-specific information. Imagine an attorney with a client that files lots of trademark applications or has lots of trademark maintenance filings that need doing. A different design that allowed creating a template that could be used to pre-fill a lot of client-specific and attorney-specific data would be a big timesaver and could avoid the need to retype (and potentially mistype) the same information over and over again. Consider the kinds of templates that systems like ETAS/EPAS allows creating. just as an example.

    Again, someone made the design decision (even by omission) that templates were not important, but efficient restarting of work in progress was. And now we’re stuck with a highly sub-optimal TEAS system.

Leave a Reply

Your email address will not be published. Required fields are marked *