Patent Portfolio Searching with Patseer – Best Practices for using USPTO Reassignments data and Corporate Tree
Share:
When building a set of all records held by a company, a searcher is faced with multiple challenges such as non-standardized Assignee names, Missing data on current ownership of records, Patents held by subsidiary companies or holding entities whose names are entirely different form the operating name and finally Blank Assignees (Unassigned applications). Simply searching for a company name and expecting that you will get the complete portfolio of a company almost never happens.
Assignee Normalization
In PatSeer we have standardized the Top 3000 patent holding companies and continue to extend the standardization to include more companies. Standardizing the original assignee name. So when you search in ASN field in PatSeer, you are actually searching in both the Original Assignee (ASNO) and the Normalized Assignee (ASNN) names.
Integrating USPTO Reassignments data and calculating Current Assignee
Each week we update PatSeer with US Reassignment data and the latest Assignee is captured in the Current Assignee (CASN) field. For all those records where Reassignment information is not available, CASN holds the original normalized names. These are also fields such as REAS (Reassignment Assignees) which captures all the Assignee present in the assignment history of the record.
Locating Probable Assignee for Unassigned Records
In case both Original and Reassignment data is missing, we run a Probable Assignee algorithm to locate the Assignee for the record. The most popular way for this is to look up the simple/extended (INPADOC) family for the record. In addition to this we also predict the assignee based on other internal rules. Assignees located by this method are also stored in CASN field itself a PCA flag (Probable Current Assignee) lets you know that the CASN has been predicted for the record by the system.
In addition to the above processes, two separate tools have been provided to aid your searching. These are Find Matching Assignee Names and Corporate Tree. Find Matching Assignee allows you to browse the index of all matching names present in our Index and helps you include them in your search. So if you are searching for “Warner Lambert Co” , if you simply look up “Warner Lam” in the Find Matching tool you will see names such as “Warner Lamber Co” , “Warner Lampert Pharma” and “Warner lambrecht” which would have been missed out.
Looking up Corporate Tree gives you a bunch of subsidiary names as shown in the image below.
However you should not include all the subsidiaries in your search as company M&A data and patent ownership can be two different things. A company ABC can buy the physical assets of XYZ while the patent of XYZ may not be part of the transaction. So simply assuming that patents held by all subsidiaries of a company is also owned by the parent can lead to wrong results. Its best to take the subsidiary information to the stakeholders of the project to decide on which ones to include in the search. You can also looking up each subsidiary online in context of your project and make a decision of whether to include or not.
So this brings us back to the topic of the blog, i.e., What are the best practices when doing an Assignee Search?
Let’s put this in a sequence of steps for a case study on forming a search for Google’s current portfolio.
Step I: Decide on which companies to include from the Corporate Tree
Since this is an example and we don’t actually have a context, so we look up the Google’s Corporate Tree and let’s assume we want to include DoubleClick Inc and Motorola Mobility only.
Step II: Form your search string for each name.
We look up the Find Matching Assignee for portions of the above name and narrow on the following refined search string:
“GOOGE INC” OR “GOOGIE INC” OR GOOGLE OR “GOOGOLE INC” OR DOUBLECLICK OR MOTOROLA MOBIL*
Motorola Mobil* has been truncated as in the Find Matching Assignee showed up names such as Motorola Mobiliti Ink.
Step III: Choose the Search field
Searching in various Assignee fields (that we spoke about above) gave the following result counts:
| Field | Description | Results (Individual Publications. Not Families) |
| ASNO | Original Assignee | 14491 Records |
| ASNN | Normalized Assignee | 14503 Records |
| ASN | ASNN + ASNO | 14503 Records |
| CASN | Current Assignee | 32066 Records |
| RASN | US Reassignment history | 19009 Records |
| CAAN | CASN + ASN | 32105 Records |
| RAAN | RASN + ASN | 27824 Records |
| CAAN or RASN | ASN + CASN + RASN | 32236 Records |
Some key observations we can see are:
- Only 14503 records showed up if we searched in basic ASN field. But more than double or 32066 records resulted by searching the CASN (Current Assignee) field.
- Looking up purely within the Reassignment database gives only 19009 records which have any of the names in the search string and including these with the ASN field in the RAAN search gave only 27824 record.
- So how is the RAAN count less than the CASN count if the current Assignee itself was picked up from the Reassignment data? The reason is the Probable Assignee calculation. As CASN also includes Probable Assignee calculations, you can see that there were 4281 records without any Assignee name and also with no reassignment history for which Probable Assignee Calculation was done. These would have been missed without such a calculation in place.
So should we use the last one (CASN or RASN) simply because it has the highest count? Including RASN may not be always correct as patents could also have been sold by Google or Motorola Mobility to another company and so are no longer held by them. To check this we can simply do a RASN AND NOT CASN query for the same search string which resulted in 158 records. On investigating these records we see that records held by Google and Motorola Mobility earlier but now are owned by Intel, HTC and others.
So as our current project deals with only the current ownership, CASN fields gives the accurate result, but depending on your project needs you can choose the search field appropriately.
