FAQ

Table of Contents

1. Why "Plumage"?
2. Why can't I retrieve by international registration number?
3. Why can't I retrieve by U.S. reference number?
4. Why Python? Why C#? Why not [insert language here]?
5. Why XSLT?
6. Plumage is great! Can I make a donation to show my gratitude?

1. Why "Plumage"?

The Oppedahl Patent Law Firm makes available for free a wonderful tool, called "Feathers", for tracking trademark data through the PTO's former Trademark Application and Registration Retrieval (TARR) site. (Get it? TARR and Feathers?) The PTO has retired TARR itself in favor of the new Trademark Status and Document Retrieval (TSDR) system that Plumage accesses.

For now, the PTO continues to maintain the TARR interface (but only the interface, not TARR itself) as a front-end to access TSDR (primarily, I think, because so many of the PTO's clients depend on Feathers), but its days are probably numbered. I wrote Plumage in order to facilitate updating Feathers to use TSDR. The name "Plumage" is an homage to Feathers, with Carl Oppedahl's blessing.

My friend Paul gets credit for suggesting the name.

2. Why can't I retrieve by international registration number?

Some Feathers users may note that Feathers allows tracking by international registration (IR) number, and Plumage does not.

I looked into this, and determined that there's no dependable way to track an application through TSDR by IR number, primarily because there is no one-to-one mapping between an IR number and a single corresponding application. Consider, for example, IR no. 0836006. This international registration corresponds to seven different U.S. applications and registrations:

• Ser. no. 72/176,613, reg. no. 791,851;
• Ser. no. 72/176,614, reg. no. 773,006;
• Ser. no. 72/176,615, reg. no. 791,952;
• Ser. no. 72/176,772, reg. no. 773,318;
• Ser. no. 78/367,491, reg. no. 3,064,375;
• Ser. no. 78/367,492, reg. no. 3,121,530; and
• Ser. no. 78/367,495, reg. no. 3,064,376.

All of these applications and registrations are equally representative of IR no. 0836006 and each has an equal claim to being the application/registration represented by it. But each has a completely different set of TSDR status data. As a design decision, I decided that, rather than select one application over all the rest, I would simply not support retrieval by IR number at this time. I figure the typical user wishing to track a particular application will enter the IR number into TSDR directly to get the application number, which could then be used with Plumage.

I considered, and am still considering, adding a "helper method" that would provide an IR-based API. I could allow Plumage to accept an IR number, and return a list of application numbers, and the calling program could then interrogate each of those applications. In the interest of producing a working API, though, I decided to shelve that for now, and maybe add it as an additional feature in the future. If this is something that interests you, please let me know.

3. Why can't I retrieve by U.S. reference number?

TSDR allows a user to retrieve application status by U.S. reference number. Plumage does not support this for two reasons.

First, my initial goal was to support the same access that Feathers does. Feathers does not support lookup by U.S. reference number, so I didn't see a need to, either.

Second, lookup by U.S. reference number introduces the same ambiguity that lookup by international registration numbers, as discussed in question #2 above. For example, U.S. reference number Z1231384 correponds to the same seven applications as IR no. 0836006.

As with IR numbers, I could always add a helper app that could return a list of application numbers, if that would be useful. Let me know.

4. Why Python? Why C#? Why not [insert language here]?

From the start, I wanted Plumage to be something that would be usable by a future version of Feathers. Feathers is written in VisualBasic. VisualBasic has been supplanted by VisualBasic .NET, and I figured that any update of Feathers to support TSDR would likely be in that language. Because of the .NET architecture, any .NET language could be used (see Basic examples to see examples in C#, VisualBasic and C++), and I simply like C# the best. It feels like Java without Java's warts to me.

My primary language is Python, so it was natural for me to prototype in it, and rather than discard it, I decided to keep it. In fact, when I use Plumage myself, the Python implementation is the one I use.

As far as "Why not [insert language here]?" goes, the primary reason is usually because I do not know the language and/or had no use for an implementation in that language, but there's usually no reason why that language couldn't be used. If you're interested in doing so, please, go for it (the XML parsing is language-agnostic, see question #5 below, so porting to a new language is easier than you might think), or let me know and I might give it a try just for the fun and challenge. But there are three languages, or categories of language, that are worth discussing:

• Java. It's coming. I want a Java implementation, because I'd like to write an Android app that uses Plumage.

• Javascript. Not planned at this time, although it seems like a useful implementation. So why not?

  In a word, XSS. Javascript executes in a browser, and in order to get the TSDR data, would need to call out to the PTO from within the browser, something that is referred to as cross-site scripting (XSS). Because XSS can, in some cases, introduce security vulnerabilities, it is disallowed by default. It is possible for a server to indicate that it permits XSS calls, through a feature known as cross-origin resource sharing (CORS), but the PTO does not implement it on TSDR. There are some workarounds, but most of them are pretty unsatisfactory, and frankly, if the PTO doesn't want cross-site access to TSDR, I'm not inclined to try to circumvent that.

  That being said... My understanding is that the mobile frameworks Apache Cordova and PhoneGap, on which Cordova is based, do not enforce the XSS restriction, precisely to allow browser-based mobile apps that process data from other systems, as Plumage does. I may look into producing a Javasvript implementation for use in this way.

• Any Apple-only languages. I don't have any Apple devices, so I'm not able to code and test for IOS or any other Apple operating systems. Nothing against Apple, if I had one I'd probably give it a try, but I don't.

5. Why XSLT?

Plumage works by applying an XSLT transform to the PTO-supplied XML file, converting it to a simple comma-separated value (CSV) format, which is then converted to a native data format appropriate to the language implementation. So why use XSLT? Why not go directly against the XML? There are several reasons I opted to implement it this way.

First, it increases portability. The XML extract logic is entirely done by XSLT, which will be identical regardless of the language used. This makes it a lot easier to roll another implementation in a new language. In most of my development, I didn't use any programming language at all, I just used MSXSL to run the XSLT transforms against the XML files.

Second, it adds flexibility and agility. If I decide to add a new field, modifying the XSLT to add the field will be pretty straightforward. Furthermore, once that's done, each Plumage implementation will have the new capability. If the PTO starts using ST.96 instead of ST.66, the XSLT already understands both formats. If the PTO adds additional data in the XML, it will be relatively easy to modify the XSLT to extract it, with no new logic in the actual code. In May 2016, when the PTO switched from ST.96 1_D3 to ST.96 2.2.1, it took me less than an hour to completely rework the XSLT and get both the Python and .net varieties of Plumage to work correctly, with no changes to the Python or C# source code.

Finally, it's customizable. If there is a field you want out of the XML that I didn't think to extract, you can create your own XSLT file, maybe a tweak of one of the files supplied with Plumage, and add the necessary lines to extract it. Because Plumage allows user-specified XSLT to override the default transforms supplied, there is no requirement for Plumage itself to be updated if you need additional fields. The actual code logic in Plumage is completely agnostic of the field names and values in the XML files; that knowledge is all in the XSLT files. XSLT converts the XML to a key-pair CSV, and the program logic transforms the CSV to a native format, without any knowledge of the data in the XML file. If I were not using XSLT, adding support for a new field would entail writing new code to extract that field.

The only downsides to using XSLT are: 1) in Python, you need to install lxml, because Python 2.x does not have native XSLT support; and 2) XSLT syntax is a little bit arcane, if you're not used to it.

6. Plumage is great! Can I make a donation to show my gratitude?

Short answer: no, but thank you.

Long answer: I don't really expect people to want to pay for this, and it wasn't my intention in the first place, but I'm putting the answer here, just in case.

Accepting monetary contributions would probably have the opposite effect of encouraging development. I have approval from my employer to have released this code under an open source license, but if I tried to make money off of it, even voluntary contributions, I would arguably have a conflict of interest. If you use Plumage and like it, the best thing you could do is let me know. I frankly think this project is a little bit arcane, and don't expect anything to be developed with it; but I'd be quite chuffed to see it got some actual use out in the real world.

If you must send money to someone, please pick a charity you consider worthwhile and let me know. That will warm my heart, too. If you want suggestions, my two favorite charities are: (1) The American Cancer Society; and (2) The San Jose Public Library Foundation.