One of the important listservs that all US patent practitioners should subscribe to is the PAIR listserv. This is a listserv designed, oddly enough, for users of PAIR. Earlier today, alert listserv member William B. Slate posted a screen shot from PAIR showing that the “search by customer number” menu was missing. And he’s right. It was missing. Later it returned in PAIR. William’s posting to the listserv prompted me to say a few words about how PAIR actually works and why it is actually cause for astonishment any time that PAIR actually works.The particular PAIR malfunction that William described was the absence of the “search by customer number” menu. Another frequent malfunction is the absence of the IFW tab. Why do these (and many other things) so often go wrong in PAIR?
What’s going on here is due to the underlying nature of both PAIR and EFS-Web. For us as users, PAIR and EFS-Web might look like a single system each. The real situation is that the PAIR server is a mere front end, mediating our connections with a dozen more obscure servers — servers that we as users never see directly. (It’s the same with EFS-Web.) The servers that we can’t see, that are deep within the bowels of PAIR and EFS-Web … some of them are ancient. Some of them use programming languages that are so old that the language is not taught these days in computer science school, and it is not easy to hire a programmer who still remembers how to code in that language. Some of them use code for which the source code has been lost, meaning that no more changes can be made to the code except by laborious assembly language editing. For most of the servers, the design and implementation was not carried out by USPTO personnel but was carried out by contractors, some of whom were contractors for the USPTO at the time but are no longer contractors for the USPTO.
So it is actually astonishing that anything works when you use PAIR or EFS-Web. It is astonishing when (as happens maybe 60% of the time) you can e-file something in EFS-Web and in less than an hour, you can see what you filed in PAIR. It is not such a surprise when one’s e-filed document is still invisible an hour after filing. Indeed I have sometimes e-filed a new application on a Friday evening and it is not visible in PAIR until the following Monday morning.
I’ll tell a story about the early days of PAIR that will illustrate what I am talking about, namely that hidden behind the facade of PAIR are dozens of legacy servers. When PAIR was new (this is a decade ago I guess) you could pick a patent application to look at, and usually the application information page would load fairly promptly. The page I am talking about is the page with tabs like “application data” and “transaction history” and “IFW” and “assignments” and so on.
But the problem (back in those early days of PAIR) was that sometimes you could pick a patent application to look at, and the PAIR system would freeze. You could wait and wait and wait and the application information page (with the “application data” and “transaction history” and “IFW” and “assignments” tabs) would never arrive.
When the user clicks to see information about a particular application, there is one particular engine inside of PAIR (I call it the “rendering engine”) that immediately sends requests to a bunch of other servers (that users can’t see) to ask for information about that particular application. One request goes to the IFW server. Another request goes to the server that contains the transaction history. Another request goes to the Assignments server. The rendering engine then assembles all of this information and constructs (renders) the application information page that we are all accustomed to. We can then click on the “transaction history” tab or the IFW tab or the Assignments tab, and we can see detailed information about the application that we just picked.
Anyway, as I say, in those early days of PAIR, there was this pesky problem that maybe ten percent of the time, when you picked the application you wanted to find out about, the information page would fail to load. What this means is that the rendering engine would stall and fail to do its job.
What the USPTO developers found, when they investigated this problem, was that nearly always when the rendering engine stalled, it was because the Assignments engine was taking far too long to respond to the information request. The rendering engine had been programmed to wait and only show its information page once it had gotten a response back from all of the underlying engines, and if the Assignments engine was unresponsive for a long time, this meant that the rendering engine would be unresponsive for the same amount of time (well over 60 seconds in some cases, and sometimes it would literally never respond no matter how long the user was willing to wait).
Here’s what the USPTO developers did. (And I think it was probably the least-bad thing they could have done.) They reprogrammed the rendering engine to ignore the Assignments engine. By this I mean the rendering engine would not sit and wait to hear back from the Assignments engine as a precondition for displaying the information page (the page with the many tabs). Instead, the rendering engine would go ahead and display the information page even if it had not heard anything back from the Assignments engine. And to this day, that is what the PAIR rendering engine does. It sort of sweeps under the carpet the possible problem of the Assignments engine being slow.
Why was this the right thing to do? It was the right thing to do because when you or I pick an application to look at, probably 90% of the time we aren’t interested in the Assignments information anyway. So the rendering engine might as well pretend that everything (including the Assignments information) is available, even if that is not true. The rendering engine might as well give us the page with all the tabs, because likely as not the tab that we actually want to view is not the Assignments tab anyway.
And anyway, if we do finally get around to clicking on the Assignments tab, some seconds or tens of seconds will likely have passed. And by then the Assignments engine, even if it was running slow at the time that we picked an application to look at, may still have gotten around to responding to the rendering engine. So we might not even perceive that anything took longer than it should have taken.
Another example of this is the IFW engine. Again let’s think of what happens when we pick a particular application for which we want to see information in PAIR. As I described above, the rendering engine fires off a request to each of the other servers, including the IFW engine and the Assignments engine, asking for information about the particular application that we picked. Well, sometimes the IFW engine sort of responds to the rendering engine like a deer in the headlights. It simply fails to offer up any documents for view. Most often this happens because the application is newly filed. Maybe the application was just filed in EFS-Web within the past hour or two. And maybe the document images have not yet gotten loaded properly into the IFW engine. (There is not a direct connection from EFS-Web to IFW; there are several servers that we cannot see that lie along the flow path from EFS-Web to IFW.) The result? The IFW tab is simply missing. Or, the IFW tab is there, but when you click on it, you cannot see all of the documents that you filed, but only some of the documents that you filed.)
To recap, there are lots of servers that we as users cannot see directly, hidden behind the facades of EFS-Web and PAIR. Some of them are so old that no one knows how to modify their code any more. Some of them get constipated and the only way to get them moving is to unplug them from electrical power and then plug them in again (and hope that they boot up correctly).
So as I say it is astonishing when, as happens over half of the time, EFS-Web and PAIR actually both work the way we as users would expect.