7,612
edits
Changes
Jump to navigation
Jump to search
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.
==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:PatentAndAssignmentER2Erdplus-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==
* 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. * address 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 address 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 firm"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===== * city patent_no (varchar(255)) city unique identifier for the patent from the UPSTO office, can contain letters hence varchar* parent_doc_status (varchar(255)) status of the firmparent 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.)* state parent_doc_country (varchar(255)) state 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 firmxpaths, 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 firmpatent 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
