Future plans

Thoughts on future releases

July 2021

The current version of Plumage is 1.4.0 (XSLT; Python; .NET). I had initially been planning a small release (which probably would have been 1.3.1) to add a few nice-to-have things, like reporting out the trademark classes associated with a particular mark, and their respective first-use dates.

In October 2020, the USPTO changed its policy to require API registration, and to place a limit on the number of TSDR requets permitted in a particular time window. This broke Plumage. V1.4.0 addressed this, but in my hurry to get a working version out out, the support wasn't done as nicely as I would have preferred.

For one thing, it bugs me that you need to first instantiate a TSDRReq objacet and then immediately call setAPIKey to set the key. You should be able to to that all in one step. There are a lot of setXXXXX methods like that, that ideally should be available at instantiation time. It never bothered me before, because normally they aren't used. But with the PTO's API key requirement, that's changed. You always need to call at least setAPIKey, so the lack of ability to do those set operationas at instantiation time is more glaring. That will likely change in the next release.

It will probably be a compatible change, so there shouldn't be any need to change code to stop using setAPIKey, but it will probably be more natural to do so as part of instantiation.

The other thing that's likely to change is the timing control. As part of its API key implementation, the PTO also imposed limitations on how many times per minute the TSDR server can be queried: 60 times per minute for XML requests; 4 times per minute for ZIP files. (For off-peak hours, these limits go up to 120 and 12 requests per minute, respectively.) The quickest way to have addressed this would have just been to insert a one-second pause (or 15-sedon pause, for ZIP requets) between requests. I slightly improved on this; I eliminate or reduce the pause to the extent that the calling program spends time doing other things between TSDR calls. For example, if the program calls TSDR, then spends a half-second processing the results, maybe updating a database somewhere, the subsequent call will be delayed only a half-second; you get "credit" for that half-second of other time spend between calls. It's not much, but if you're iterating over a long list of marks to be updated, it can add up.

You can change the wait value by using SetIntervalTime. For example, if you're fetching ZIP files, you'll want to set it to 15 seconds to comply with the tighter limit for zip files.

I'm not satisfied with this approach, though. If you are checking 40 marks, it will take at least 40 seconds. But the PTO doesn't require that. It only requires that you check less than 60 per minute. In this example, it's perfectly compliant with PTO policy to fire off those forty queries one after another, without pause, getting it done in maybe 5 seconds.

I'm mulling a couple ways to address this, but in the next release it will be a little different. For example, if you have 60 calls or fewer, they should be able to be done, by default, sequentially without any pause; if you have 61, though, that sixty-first one might be delayed. But I will allow you to have the one-second pause if you want, in case you want to not only stay within the PTO-imposed limits, but deliberately try to keep from hammering the PTO server.

I haven't yet decided what this will look like, but I hope to do so compatibly with the current approach. Not sura about that, though.