7,612
edits
Changes
Jump to navigation
Jump to search
* orgname, (varchar(255)) name of the organization owning the patent (if applicable - organization may go by multiple orgnames) * city (varchar(255)) city, of the assignee* country (varchar(255)) country, patentnumber, of the assignee* state (varchar(255)) state, of assignee* residence, (varchar(255)) mailing address of assignee if they receive mail at a different address than the one listed above* size_of_firm (varchar(255)) size of firmthe organization, large, small, or micro - relates to how much the fee they pay for the patent is
Redesign Assignment and Patent Database (view source)
Revision as of 13:41, 21 September 2020
, 13:41, 21 September 2020no edit summary
{{Project|Has project output=Data|Has sponsor=McNair ProjectsCenter
|Has title=Redesign Assignment and Patent Database
|Has owner=Shelby Bice,
|Is dependent on=Reproducible Patent Data,
}}
'''Final Notes''' This is more or less the finalized design for the patent database. Oliver Chang's code (see Reproducible Patent Data, which is his project page) more or less fits the design, though there are some differences and expect differences in variable names. In the future the code should be altered so that the name of variables match up and each table that is listed here exists in the database. The tables for the extra variables that exist for reissue, design, and plant patents have been added, and the instructions for adding tables can be found on Reproducible Patent Data. These three tables should fit the schema seen here, but as stated previously the schema in the code DOES NOT fit the schema here exactly and should be altered in the future to fit this schema.
'''For Oliver:''' Unfortunately I did not get to finish making the schema in your code fit the schema that is outlined here. For whoever works on this next, whether that be you or another intern, please note that the variable in the schema in the code do not match up exactly with the schema outlined here, except for perhaps the Reissues, Plants, and Designs tables in the Patent database (called patentsj in the code, I believe, but you can create a database with any name of course).
This is an extension of the work I did last semester under "Redesigning Patent Database". Instead of simply reconfiguring the existing database, this project encompasses and full redesign and creation of a new Patent database and a new Assignment database that will be joined together.
Reference for definitions of fields in the two databases: https://www.oecd.org/sti/sci-tech/37569498.pdf
Paper on how to extract paper from XML files, parse it, and put it into a database: https://funginstitute.berkeley.edu/wp-content/uploads/2014/06/patentprocessor.pdf
'''Particularly useful, because it provides solutions for cleaning location and firm data'''
==ER Diagram for Assignment and Patent Databases==
Note: this matches the design below but may not match the exact database (nor the code that creates the schema of the database currently. In the future these should be made to sync up.
[[File:Erdplus-diagram (3).png]]
Attributes for each table are listed below with descriptions - because of how many attributes there are, I decided the ER diagram would be better suited as an overview of the tables rather than trying to show all the attributes on the diagram.
If you would like to edit the diagram, you can find the ER diagram you can go to https://erdplus.com/ and click "Open Diagram File" under the "Diagram" dropdown, then navigate to E:/McNair/Project/Redesigning Patent Database/New Patent Database Project/ERDiagramforPatentandAssignmentDatabases.erdplus. You should be able to edit the file then.
==Assignment Database Structure==
* state (varchar(255)) state of assignee
* country var(char(255)) country of assignee
* postal_code (varchar(255))post code of the assignee
===ASSIGNOR===
Not-repeated (with exception of primary/foreign key):
* rf_id (bigint) reel frame number
* next_transaction (bigint) rf_id of next transactionthat occurred after this transaction (traced by asignee/assignor)
* num_conveyance (int) number in order of conveyance by date
* acknowledgment_date (date) date that the assignor acknowledged the transaction
* execution_date (date) date that the transactiontook place
* conveyance_type (varchar(255)) the USPTO paper determined a couple of different conveyance types and also outlined how to determine based on the conveyance text in the xml file which conveyance type is relevant to the transaction. The conveyance types are:
** assignment
The foreign key that connects every table is patent_number, which uniquely identifies every patent in the PATENT table and is included in every table.
Full list of tables: patent, assignee, citation, fee, claims, histpatent, lawyers, inventors
Update: These tables, as of October 26, are being updated and changed as I determine what data can actually be retrieved from the XML files based on the xpaths that we have determined (you can see these xpaths on the "Equivalent XPath and APS Queries" project page.
===PATENT===
All columns (variables):
* patent_number (varchar(255)) unique identifier for the patent from the UPSTO office, can contain letters hence varchar
* patent_type (varchar(255)) the type of patent, like utility* patent_kind (varchar(2)) the kind of patent, a letter and a number* title (varchar(255)) the title of the patent* grantdate (date) date that patent was officially grantedincluding the year
* prioritydate (date) date used to established novelty of an invention in regards to other inventions (source: http://www.bios.net/daisy/patentlens/2343.html)
* prioritycountry (varchar(255)) country where patent is first filed
* patent_country (varchar(255)) country in which this patent was published* prioritypatentnumber (varchar(255)) placeholder patent number if the patent is published before it is fully approved- also referred to as priority claims number* cpcsubclass (varchar(255)) cooperative patent classification subclass
* cpcsubgroup (varchar(255)) cooperative patent classification subgroup
* cpcmaingroup (varchar(255)) cooperative patent classification main group* cpctotal (varchar(255)) concatenated version of cpcmaingroup, cpcsubgroup, cpcsubclass* pctpatentnumber (varchar(255)) international patent number (according to Patent Cooperation Treaty)also known as PCT Document Number* appnum(varchar(255)) application number* grantyear , probably also the filing number - the format is a two digit series code followed by a six digit serial number (intsource: https://www.uspto.gov/patents-application-process/filing-online/info-application-number) year the patent was granted* appdate (date) date that the application was filed, including year - probably also the filing date* ipcrsubclass (varchar(255)) International patent classification subclass* appyear ipcrmaingroup (varchar(int255)) year that the application was filedInternational patent classification main group* nber ipcrsubgroup (varchar(255)) International patent classification according to the National Bureau of Economic Research subgroup* ipcrtotal (varchar(NBER255)) Patent Citations Data Fileconcatenated version ipcrsubgroup, ipcrsubclass, ipcrmaincroup * uspc national_classification (varchar(255)) - probably uspc, which is United States patent classificationPatent Classification* uspc_sub natioanl_classification_country (varchar(255)) - should be United States * num_claims (int) number of claims (things that the inventor wishes to protect with this patent classification ) Discrepancies: These fields were previously a a part of the table, but we do not currently have xpaths for them:app_year - the year the application was filedgrant_year - the year the patent was granteduspc - United States Patent Classification (might be the same as national_classification)uspcsub - United States Patent subgroup
===ASSIGNEE===
Purpose: Represent the person the patent is was currently assigned to at publication according to the patent information (the information in the Assignment database is more complete)
Each entry represents: the assignee for a patent in PATENT
* address (varchar(255)) address of assignee
* postcode (varchar(255)) postcode of assignee
===CITATION===
Primary key: patent_number AND cited_patent_number (because a patent might cite multiple patents, so both variables are needed for the primary key)
All columns (variables): * patent_number(varchar(255)) unique identifier for the patent from the UPSTO office, can contain letters hence varchar* cited_patent_number(varchar(255)) unique identifier from the UPSTO office for the patent being cited* description (varchar(255)) description of the citation* citation_date (date) unclear what this date is supposed to represent from the DTD, but according to the paper that is the second link in the top section, it is the "date of cited document"* citation_kind (varchar(255)) type of cited document* citation_county (varchaar(255)) country of origin for the cited patent * citation_name (varchar(255)) appears to be the names to whom the cited patent are assigned to Note: There are other fields available for this table, such as document number, but this seems like it might be a repeat of the document number for the citing patent
===FEE===
Primary key: patent_number
All columns: * patent_number(varchar(255)) unique identifier for the patent from the UPSTO office, can contain letters hence varchar * four, (boolean) payment of maintenance fee 4th year* eight, (boolean) payment of maintenance fee 8th year* twelve, (boolean) payment of maintenance fee 12th year* fee_date, (date) date that fee is paid on* fee_code(varchar(255)) code for type of fee to pay
===CLAIMS===
Each entry represents: sequence of historical data about an individual patent in PATENT
Primary key: patent_number
* patent_number (varchar(255)) unique identifier for the patent from the UPSTO office, can contain letters hence varchar
* pubno (varchar(255)) patent publication number
* pubdate (date) date patent was issued
* dispdate (date) disposal date for the application
* distype (varchar(3)) application status of the patent - ABN for patent term adjustment, ISS for issued, or PEN for pending
* exp_dt (date) expiration date of patent
* pta (int) length of patent term adjustment (which extends the amount of time the patent is allowed to be in force) in number of days
===INVENTORS===
Purpose: Represent the inventor for each of patents in the PATENT table
Each entry represents: information about an inventor for a specific patent
Primary Key: patent_number (and name, if there can be multiple inventors for a single patent)
* patent_number (varchar(255)) unique identifier for the patent from the UPSTO office, can contain letters hence varchar
* sequence (varchar(255)) appears to be a sequence of numbers that uniquely identify the inventor?
* name (varchar(255)) concatenated string of the first and last name of the inventor
* organme (varchar(255)) name of the organization the inventor works for
* state (varchar(255)) - state in which the inventor resided
* address (varchar(255)) - address at which the inventor resided
* country (varchar(255)) country in which the inventor resided
* city (varchar(255)) city in which the inventor resided
===LAWYERS===
Purpose: Represent the lawyers who worked on each of the patents in the PATENT table
Each entry represents: information about a lawyer for a specific patent
Primary Key: patent_number (there doesn't appear to be more than one lawyer entry for each patent)
* patent_number (varchar(255)) unique identifier for the patent from the UPSTO office, can contain letters hence varchar
* sequence (varchar(255)) appears to be a sequence of numbers that unique identify the lawyer?
* org_name (varchar(255)) the name of the firm that did arbitration for the patent
===Unique Attributes Tables===
There are several attributes that have been identified and are unique, applying to only one kind of patent. Instead of adding all these fields to the main patent table, which will introduce a lot of NULL entries because three out of four patents will not have any particular attribute. Therefore, I have created three new tables to store these unique attributes - one for each type of patent with unique attributes.
For each table, the primary key is the patent_number, which connects a row to a row in the main patent table.
TODO: Figure out best way to generate these tables, finish description of attributes for each table.
* Note that I did include some unique attributes for Utility patents as seen below in the "Finding New Paths Unique to Plant, Reissue, and/or Design Patents" section, but for now (11/3/2017) I'm not going to create a separate table for those fields. Most of them seem to be repeated in Reissue, and the other fields, while interesting, are perhaps not very useful.
====PLANT====
=====Fields=====
* patent_no (varchar(255)) unique identifier for the patent from the UPSTO office, can contain letters hence varchar
* latin_name (varchar(255)) latin name for the plant
* us_botanical_variety(varchar(255)) denotes what variety of plant it is - for example, a rose has several different varieties
====REISSUE====
In the following table, you'll notice lots of fields related to three different kinds of "documents" - a "parent document", a "child document", and a "parent grant document". It is not immediately clear what these three documents represent for a reissue patent. After some research, I think I have determined that these "documents" are, but please know that I do not have definitive proof as there is little available information about these "documents" in regards to a reissue patent.
It is possible that the "parent document" is the parent patent application - that is, the first patent application filed in regards to an invention. That would explain why reissue patents also has several fields related to a "child document" - a "child document" could be a child application, which is filed while a parent application is still pending. So in this case, a "child document" of a reissue patent would be an application regarding the same patent that was filed while the reissue application was still pending. A "child document" is either a continuation, disclosure, or continuation-in-part application ([http://www.patenttrademarkblog.com/parent-and-child-patent-applications/ source]).
Based on this logic, I think that the difference between a "parent document" and a "parent grant document" depends on whether the parent patent application has been granted. If the parent patent application is still pending (meaning the patent has not yet been granted yet) then I believe the reissue patent will store information about the parent patent under "parent document". However, if the parent patent application has been granted, then the information will be stored under "parent grant document". This seems like the most logical explanation, especially considered the path to any field related to "parent grant document" contains "parent document" as with the example below:
us-patent-grant/us-bibliographic-data-grant/us-related-documents/reissue/relation/parent-doc/parent-grant-document/document-id/date
Therefore, a particular reissue patent will probably only have the fields filled for either the "parent document" or "parent grant document" if I am right about what they represent.
=====Fields=====
* patent_no (varchar(255)) unique identifier for the patent from the UPSTO office, can contain letters hence varchar
* parent_doc_status (varchar(255)) status of the parent application. Probably related to whether the patent application is pending or not
* parent_doc_number (int) probably application number for the parent document
* parent_doc_id (varchar(255)) it is unclear how this is different from parent document number. In the xpaths, the path will be something like ./parent_doc/document-id/doc-number, so it's possible it's not actually different from the document number and rather just a broader category.
* parent_doc_kind (varchar(255)) this may actually denote what the "parent document" is - or may refer to it's purpose (i.e. reissue, continuation, continuation-in-part, etc.)
* parent_doc_country (varchar(255)) the country of origin of the parent document
* parent_doc_date (date) probably the date the parent document was filed
* parent_grant_doc_number (int) probably application number for the parent grant document
* parent_grant_doc_id (varchar(255)) it is unclear how this is different from parent grant document number. In the xpaths, the path will be something like ./parent_doc/parent-grant-doc/document-id/doc-number, so it's possible it's not actually different from the document number and rather just a broader category.
* parent_grant_doc_kind (varchar(255)) this may actually denote what the "parent grant document" is, or may refer to it's purpose (i.e. reissue, continuation, continuation-in-part, etc.)
* parent_grant_doc_country (varchar(255)) the country of origin of the parent grant document
* parent_grant_doc_date (date) probably the date the parent grant document was filed
* child_doc_number (varchar(255)) probably the application number of the child application
* child_doc_id (varchar(255)) it is unclear how this is different from child document number. In the xpaths, the path will be something like ./child_doc/document-id/doc-number, so it's possible it's not actually different from the document number and rather just a broader category.
* child_doc_country (varchar(255)) country of origin of the child application
====DESIGN====
=====Fields=====
* patent_no (varchar(255)) unique identifier for the patent from the UPSTO office, can contain letters hence varchar
* length_of_grant (int) length of grant, most likely in years
* hague_registration_date (date) filing date of international patent application
* hague_filing_date (date) not necessarily the same as the filing date of the international patent application, this is the date that the International Bureau receives all necessary elements for the international patent application
* hague_registration_pub_date (date) datethat the International Bureau publishes the international patent application
* hague_international_registration_number (varchar(255)) international registration number
* edition (varchar(255)) possibly the edition of the Classification Locarno which determined main_classification
* main_classification (varchar(255)) classification for what type of design the patent is for
==Connecting Patent database and Assignment database==
Also in the paper, they mentioned the Assignments on the Web for Patents (AOTW-P), a searchable database of individual USPTO assignment records keyed on reel-frame identification, patent number, and assignor or assignee name (https://assignment.uspto.gov/patent/index.html#/patent/search). Obviously it would not be possible to individually use this tool to query all the patent numbers, but if it would be possible to write a script to somehow query each patent number using the rf_id and parse the response, this could potentially be useful to check the patent numbers, but might not be any more accurate than what will already be in DOCUMENT_INFO.
==Finding New Fields Unique to Plant, Reissue, and/or Design Patents==
Based on Oliver's script which searched all xpaths and compared which were unique to particular types, we see that the following attributes are unique to each type of patents other than utility patents. These attributes vary by the XML version, which changed over time. Therefore, the lists below are a superset of the attributes that are unique to each of the patents types listed below across all XML versions.
When I am done finding the supersets, we will determine how to integrate these attributes into the design for the patent table.
'''There appears to be a fifth patent type in the results from Oliver's script, and there are attributes that are unique to Utility patents, though they do not appear particularly useful'''
===Plant Patents===
* US Claim Statement (XML45) - unclear what this represents
* Latin Name (XML44)
* US Botanical Variety (XML44)
===Reissue Patents===
* Parent Status (XML45)
* Parent Document (XML44) - seems to be either a normal document or a parent grant document (or both), both contain the following fields
** Date
** Document number
** Country
** Document ID
** Kind (XML42)
* Child Document (XML44)
** Document ID
** Document Number
** Country (XML43)
Note about fields related to the parent document and/or parent grant document:
The structure of the above fields related to a reissue patent is very odd and varies by XML version. For example, for most of the XML version, parent grant document falls under parent document and has it's own document number, date, country, document ID, kind, etc. The parent doc field falls under relation, which falls under reissue.
However, in XML41, parent document falls under relation and a new category - US Reexamination Reissue Merger. The information pertaining to the child documentation also fall under both relation and US Reexamination Reissue Merger. It's possible that during the time period this XML version represents, there were two types of reissue patents - some reexamination related to a merger and a standard reissue. With discrepancies like these, we'll have to determine in the end we want to stick with the fields as they are designed above (in which cases the information about a parent doc or parent grant document is stored the same whether it is a reissue or an Reexamination Reissue, or if these two classifications are different enough to warrant duplicate fields in the table.
===Design Patents===
* length of grant (XML45)
* Hague Agreement Data (XML45) - allows people to file design patents in 66 countries with one application
** International Registration Date
** International Filing Date
** International Registration Publication Date
** International Registration Number
* Classification Locarno (XML40)
** Edition
** Main Classification
Please note that the lists above are meant to represent unique types that should be added to the patent database. This does not mean that every XML version contains all these fields, or that every version contains the same path to these fields. That will have to be determined separately. The XML number next to some of the items is meant to represent the latest XML version where the field was seen.
Thought I was mainly looking at unique fields in plant, reissue, and design patents, I noticed the following field on unique paths for utility patents in XML41
* US Related Documents
** Substitution
*** Relation
**** Parent Document
***** Docuemnt ID
***** Document Number
***** Country
***** Date
***** Kind
***** Parent Status
**** Child Document
***** Document Number
***** Document ID
***** Country
** Continuation/Continuation in Part
*** Relation
**** Child Doc
***** Date
***** Kind
** Division
*** Relation
**** Child Document
***** Kind
This appears to resemble the information about reissue patents. Additionally, a couple of fields appear under the information about bibliographic data that might be useful:
* US Deceased Inventor (XML41)
** Post Code
** Address
* US Provisional Application Status (XML41)
==Paths for the New Fields Related to Plant Reissue, and/or Design Patents==
===Plant Patents===
XML 4.4, 4.3, 4.1, and 4.0
parent node: us-patent-grant/us-bibliographic-data-grant/us-botanic
fields: latin-name, variety
XML 4.5
parent node: us-patent-grant/us-claim-statement/
field: i
XML 4.2
parent node: us-patent-grant/us-bibliographic-data-grant/us-botanic
fields: latin-name, variety
parent node: us-patent-grant/us-claim-statement/
field: i
===Reissue Patents===
XML 4.5
parent node: us-patent-grant/us-bibliographic-data-grant/us-related-documents/reissue/relation/parent-doc/
fields: parent-status
XML 4.4
parent node: us-patent-grant/us-bibliographic-data-grant/us-related-documents/continuing-reissue/relation/
fields: parent-doc/parent-grant-document/document-id/date
parent-doc/document-id/country
parent-doc/parent-grant-document/document-id/country
child-doc/document-id/country
child-doc/document-id/doc-number
parent-doc/document-id/doc-number
parent-doc/parent-grant-document/document-id/doc-number
parent-doc/document-id/date
(everything in XML 4.3 except parent-status)
XML 4.3
parent node: us-patent-grant/us-bibliographic-data-grant/us-related-documents/reissue/relation/
fields: child-doc/document-id/doc-number
parent-doc/parent-grant-document/document-id/date
parent-doc/parent-status
parent-doc/document-id/date
parent-doc/document-id/country
parent-doc/document-id/doc-number
parent-doc/parent-grant-document/document-id/country
child-doc/document-id/country
parent-doc/parent-grant-document/document-id/doc-number
XML 4.1
parent node: us-patent-grant/us-bibliographic-data-grant/us-related-documents/reissue/relation/
fields:
child-doc/document-id/doc-number
child-doc/document-id/country
parent-doc/parent-status
parent-doc/document-id/kind
parent-doc/document-id/country
parent-doc/document-id/doc-number
parent-doc/document-id/date
parent-doc/parent-grant-document/document-id/kind
parent-doc/parent-grant-document/document-id/country
parent-doc/parent-grant-document/document-id/date
parent-doc/parent-grant-document/document-id/doc-number
other parent node: us-patent-grant/us-bibliographic-data-grant/us-related-documents/us-reexamination-reissue-merger/relation/
fields:
child-doc/document-id/doc-number
child-doc/document-id/country
parent-doc/document-id/date
parent-doc/document-id/doc-number
parent-doc/document-id/country
parent-doc/parent-grant-document/document-id/kind
parent-doc/parent-grant-document/document-id/country
parent-doc/parent-grant-document/document-id/date
parent-doc/parent-grant-document/document-id/doc-number
XML 4.0 and XML 4.2
parent node: us-patent-grant/us-bibliographic-data-grant/us-related-documents/reissue/relation/
fields: parent-doc/document-id/kind
parent-doc/document-id/doc-number
parent-doc/parent-grant-document/document-id/kind
parent-doc/parent-grant-document/document-id/country
child-doc/document-id/country
parent-doc/parent-grant-document/document-id/doc-number
child-doc/document-id/doc-number
parent-doc/parent-grant-document/document-id/date
parent-doc/parent-status
parent-doc/document-id/country
parent-doc/document-id/date
===Design Patents===
XML 4.5
parent node: us-patent-grant/us-bibliographic-data-grant/
fields: hague-agreement-data/international-registration-date/date
hague-agreement-data/international-registration-publication-date/date
us-term-of-grant/length-of-grant
hague-agreement-data/international-registration-number
hague-agreement-data/international-filing-date/date
XML 4.1, 4.3, and 4.4
parent node: us-patent-grant/us-bibliographic-data-grant/us-term-of-grant/
fields: length-of-grant
XML 4.0
parent node: us-patent-grant/us-bibliographic-data-grant/
fields: us-term-of-grant/length-of-grant
classification-locarno/edition
classification-locarno/main-classification
