Attachment 26 - DCB 2019-01 (15).docx

D a t a C a p t u r e B u l l e t i n

Number 2019-17 July 18, 2019

WHEN THE HAGUE.IR_PUB DOCUMENT IS THE SOURCE AND IT SHOWS A SYMBOL IN PLACE OF A LETTER IN A NAME IN

THE APPLICANTS DATA OR

THE INVENTORS DATA

The information in this bulletin will be included in the 2020 revision of

DATA ENTRY MANUAL FOR NON-UTILITY PATENT DOCUMENTS,

OTHER THAN PATENT APPLICATION PUBLICATIONS.

***This bulletin is effective immediately.***

See DATA ENTRY MANUAL FOR NON-UTILITY PATENT DOCUMENTS, OTHER THAN PATENT APPLICATION PUBLICATIONS, Section I. DESIGN PATENT, Columns, Applicant Data, For the processing of an international design application under the Hague Agreement (series code 35), Data Source & Pre-Capture Verification.

The information under the headings applicant who is not an inventor and inventor-applicant

— down to, but not including, the heading Grant Yellow and Grant Red (Hague application) — is superseded by what follows.

· applicant who is not an inventor

When the applicant is not an inventor:

Assignee/obligated assignee/proprietary party*: must be identified as the applicant either in the WIPO publication of the international registration or in a signed and marked-up application data sheet (ADS) legal representative of deceased/incapacitated inventor: may be identified as an applicant in the WIPO publication, in a substitute statement, or in a signed and marked-up (ADS)

As shown below under PaDaCap contractor’s verification of “proprietary party” petition, the PaDaCap contractor is required to verify that the proprietary party has filed a proper petition and that the petition has been granted.

The “legal representative”—under 35 U.S.C. 117, which see below—is the person (such as heir, executor, or administrator) who acts on behalf of a deceased or legally incapacitated inventor. However, the legal representative may be an institution, in which case the institution itself, not the person who signs the ADS or OATH (substitute statement) on the institution’s behalf, is the legal representative.

· With three exceptions, the INID (71) Applicant data source for the name and residence of an applicant who is not an inventor is, in the following hierarchical order:

1. the latest signed and marked-up ADS that corrects, updates, or changes its Applicant Information section in accordance with U.S. rules

2. WIPO International Publication Data (HAGUE.IR_PUB)

The three exceptions:

· On a substitute statement (OATH) executed by a legal representative on behalf of a deceased or legally incapacitated inventor, the PERSON EXECUTING THIS SUBSTITUTE STATEMENT section will be the source for the name and residence of the legal representative, unless the legal representative later assigned the invention to an applicant added under 37 CFR 1.46(c). Such a legal representative will be printed in the (71) Applicant data whether or not that legal representative is identified as an applicant in the WIPO International Publication Data (HAGUE.IR_PUB) or in the Applicant Information section of an ADS.

· Changes or corrections concerning applicant data annotated as entered on document HAGUE.ART.16 or HAGUE.R.22 will also be a complementary source unless superseded by a subsequent correction, e.g., via a later filed signed and marked-up ADS. After IPLA annotates the Article 16/Rule 22 document to indicate entry of the correction to applicant name and/or residence, IPLA requests that its filing receipt contractor send out a corrected APP.FILE.REC. If there is an entered Article 16/Rule 22 document or a proper ADS making a change to the applicant data and such change is not shown on the BIB or later-dated APP.FILE.REC, the PaDaCap contractor will make any necessary PALM updates to the applicant name and residence (city + U.S. state, city + non-U.S. country) and will send out a corrected APP.FILE.REC.

· When the HAGUE.IR_PUB is the source and it shows a symbol in place of a letter in a name in the APPLICANTS data: The information on the HAGUE.IR_PUB is based on XML publication data that the USPTO receives from WIPO. When this data enters PALM, it is possible for the character set used by PALM to have difficulty with a given letter in the applicant’s personal name or the name of the applicant’s city of residence, causing the HAGUE.IR_PUB sheet to show the name with a symbol, such as #, in place of the letter. In such cases, at any point in the processing of the application, the USPTO may go to the WIPO website to see if the published WIPO document shows a letter in place of the symbol, and may update PALM and produce a corrected APP.FILE.REC that changes the symbol to a letter. When the HAGUE.IR_PUB shows a symbol in the name, the PaDaCap contractor will look to see if the latest APP.FILE.REC has corrected the name to show a letter in place of the symbol, and will use the corrected APP.FILE.REC as the source for the printing of the name. In either Initial Data Capture or Final Data Capture, if the HAGUE.IR_PUB shows the name with a symbol, and if PALM has not been updated and there is no corrected APP.FILE.REC showing a letter in place of the symbol, the PaDaCap contractor will go to https://www.wipo.int/designdb/en/ and will search by international registration (DM) number to see how the published WIPO document shows the name. If the published WIPO document shows the name with a letter instead of a symbol, the PaDaCap contractor will update PALM by changing the symbol to the correct letter, will send out a corrected APP.FILE.REC, and will use the corrected APP.FILE.REC as the source for printing the name on the patent. NOTE: If the WIPO site shows the letter with a diacritical mark and if PALM can accommodate that diacritical mark, the letter printed on the patent will show the diacritical mark. If PALM cannot accommodate the diacritical mark, the letter printed on the patent will not show the diacritical mark.

For capturing applicant data from Form PTO/AIA/14, Application Data Sheet 37 CFR 1.76, and from a substitute statement (OATH) executed by a legal representative, see DATA ENTRY MANUAL FOR UTILITY PATENTS, 7A. Applicant Data.

· inventor-applicant

Each inventor who is also an applicant will be identified on the patent front page in both INID (71) Applicant data and INID (72) Inventor data.

Unless corrected, inventorship in an international design application designating the United States is the inventorship set forth in the WIPO publication of the international registration. See 37 CFR 1.48(f): “The inventorship of an international design application designating the United States is the creator or creators set forth in the publication of the international registration under Hague Agreement Article 10(3). Any correction of inventorship must be pursuant to §1.48.” Inventors that are applicants are identified as applicants and separately as inventors in the WIPO published international registration (and consequently in the WIPO International Publication Data document (HAGUE.IR_PUB) in IFW).

Correction of inventorship in a Hague application may be made pursuant to 37 CFR 1.48 by submitting a signed and marked up ADS. As with utility applications, where only inventors (or the legal representative of a deceased inventor) are applicants, changes in inventorship under Rule 1.48 can effectively result in a change in the applicant. The procedures set forth in the “inventor-applicant” section of the DATA ENTRY MANUAL FOR UTILITY PATENTS, 7A. Applicant Data with respect to the processing of a signed and marked-up ADS submitted with a Rule 1.48 request generally apply to Hague applications. Thus, for example, where the inventors and the applicants are the same persons indicated in HAGUE.IR_PUB, and a signed and marked-up ADS is later submitted with a Rule 1.48 request adding an inventor in the Inventor Information section of the ADS (and leaving the Applicant Information section blank), the added inventor should be identified as an applicant in INID (71) Applicant data.

Subject to two exceptions, with respect to the name and residence of the inventor-applicant:

· If there is no signed and marked-up ADS, the APPLICANTS field of document HAGUE.IR_PUB is the source for INID (71) Applicant data and the INVENTORS field of HAGUE.IR_PUB is the source for INID (72) Inventor data. For example, the HAGUE.IR_PUB shows this:

The city name printed at (71) Applicant should be Founex Vd, while the city name printed at (72) Inventor should be Founex.

· Otherwise, the PaDaCap contractor’s data source for the INID (71) Applicant data and the INID (72) Inventor data will be the later-filed signed ADS that has been marked up to show the changes to the inventor information, in which case that later signed, marked-up ADS will be the source.

The two exceptions:

· Any entered Rule 22 correction document (document code HAGUE.R.22) or entered Article 16 recording document (document code HAGUE.ART.16) correcting or changing inventor and/or applicant data should be taken into account with respect to INID (71) Applicant data and/or INID (72) Inventor data, as applicable, unless such document has been superseded by a later correction, e.g., via a subsequently filed signed and marked-up ADS. After IPLA annotates the Rule 22/Article 16/ document to indicate entry of the correction to the inventor and/or applicant data, IPLA requests that its filing receipt contractor send out a corrected APP.FILE.REC. If there is an entered Article 16/Rule 22 document or a proper ADS making a change to the inventor and/or applicant data and such change is not shown on the BIB or later-dated APP.FILE.REC, the PaDaCap contractor will make any necessary PALM updates to the inventor and/or applicant name and residence (city + U.S. state, city + non-U.S. country) and will send out a corrected APP.FILE.REC.

· When the HAGUE.IR_PUB is the source and it shows a symbol in place of a letter in a name in the APPLICANTS data: The information on the HAGUE.IR_PUB is based on XML publication data that the USPTO receives from WIPO. When this data enters PALM, it is possible for the character set used by PALM to have difficulty with a given letter in the applicant’s personal name or the name of the applicant’s city of residence, causing the HAGUE.IR_PUB sheet to show the name with a symbol, such as #, in place of the letter. In such cases, at any point in the processing of the application, the USPTO may go to the WIPO website to see if the published WIPO document shows a letter in place of the symbol, and may update PALM and produce a corrected APP.FILE.REC that changes the symbol to a letter. When the HAGUE.IR_PUB shows a symbol in the name, the PaDaCap contractor will look to see if the latest APP.FILE.REC has corrected the name to show a letter in place of the symbol, and will use the corrected APP.FILE.REC as the source for the printing of the name. For example:

HAGUE.IR_PUB 04/07/2017

APP.FILE.REC 05/17/2017

BIB 03/30/2018 (at allowance)

APP.FILE.REC 06/29/2018

In either Initial Data Capture or Final Data Capture, if the HAGUE.IR_PUB shows the name with a symbol, and if PALM has not been updated and there is no corrected APP.FILE.REC showing a letter in place of the symbol, the PaDaCap contractor will go to https://www.wipo.int/designdb/en/ and will search by international registration (DM) number to see how the published WIPO document shows the name. If the published WIPO document shows the name with a letter instead of a symbol, the PaDaCap contractor will update PALM by changing the symbol to the correct letter, will send out a corrected APP.FILE.REC, and will use the corrected APP.FILE.REC as the source for printing the name on the patent. NOTE: If the WIPO site shows the letter with a diacritical mark and if PALM can accommodate that diacritical mark, the letter printed on the patent will show the diacritical mark. If PALM cannot accommodate the diacritical mark, the letter printed on the patent will not show the diacritical mark.

See DATA ENTRY MANUAL FOR NON-UTILITY PATENT DOCUMENTS, OTHER THAN PATENT APPLICATION PUBLICATIONS, Section I. DESIGN PATENT, Columns, Inventor Data, For the processing of an international design application under the Hague Agreement (series code 35), Data Source & Pre-Capture Verification.

The information beginning “In Hague applications as in all other” and continuing to, but not including, the heading When to review OATH for compliance (Hague application) is superseded by what follows.

In Hague applications as in all other applications, the PaDaCap contractor will compare the inventor data as shown in the verified source with what is shown on the latest BIB or APP.FILE.REC and when necessary will update PALM and generate a corrected APP.FILE.REC.

The source for the inventor name and residence (city, state, US; or city, non-US country) will be the following, in order of hierarchy:

1. the latest signed and marked-up ADS that corrects, updates, or changes its Inventor Information section in accordance with U.S. rules

2. WIPO International Publication Data (HAGUE.IR_PUB)

Corrections concerning inventor data annotated as entered on document HAGUE.R.22 will also be a complementary source unless superseded by a subsequent correction, e.g., via a later filed signed and marked-up ADS. After IPLA annotates the Rule 22 document to indicate entry of the correction to the inventor data, IPLA requests that its filing receipt contractor send out a corrected APP.FILE.REC. If there is an entered Rule 22 document or a proper ADS making a change to the inventor data and such change is not shown on the BIB or later-dated APP.FILE.REC, the PaDaCap contractor will make any necessary PALM updates to the inventor name and residence (city + U.S. state, city + non-U.S. country) and will send out a corrected APP.FILE.REC.

Since the HAGUE.IR_PUB does not always show the inventor’s given name first and does not consistently use all-caps to identify the inventor’s family name, the PaDaCap contractor may obtain clarification by looking at the OATH. (When only one name element is shown in all-caps on the HAGUE.IR_PUB, it is presumed to be the family name.)

If the HAGUE.IR_PUB does not show the inventor name(s)—such as in the following example, caused by a system glitch—the PaDaCap contractor should get the inventor name(s) from the APP.FILE.REC:

HAGUE.IR_PUB

APP.FILE.REC

When the HAGUE.IR_PUB is the source and it shows a symbol in place of a letter in a name in the INVENTORS data: The information on the HAGUE.IR_PUB is based on XML publication data that the USPTO receives from WIPO. When this data enters PALM, it is possible for the character set used by PALM to have difficulty with a given letter in the inventor’s personal name or the name of the inventor’s city of residence, causing the HAGUE.IR_PUB sheet to show the name with a symbol, such as #, in place of the letter. In such cases, at any point in the processing of the application, the USPTO may go to the WIPO website to see if the published WIPO document shows a letter in place of the symbol, and may update PALM and produce a corrected APP.FILE.REC that changes the symbol to a letter. When the HAGUE.IR_PUB shows a symbol in the name, the PaDaCap contractor will look to see if the latest APP.FILE.REC has corrected the name to show a letter in place of the symbol, and will use the corrected APP.FILE.REC as the source for the printing of the name. In either Initial Data Capture or Final Data Capture, if the HAGUE.IR_PUB shows the name with a symbol, and if PALM has not been updated and there is no corrected APP.FILE.REC showing a letter in place of the symbol, the PaDaCap contractor will go to https://www.wipo.int/designdb/en/ and will search by international registration (DM) number to see how the published WIPO document shows the name. If the published WIPO document shows the name with a letter instead of a symbol, the PaDaCap contractor will update PALM by changing the symbol to the correct letter, will send out a corrected APP.FILE.REC, and will use the corrected APP.FILE.REC as the source for printing the name on the patent. NOTE: If the WIPO site shows the letter with a diacritical mark and if PALM can accommodate that diacritical mark, the letter printed on the patent will show the diacritical mark. If PALM cannot accommodate the diacritical mark, the letter printed on the patent will not show the diacritical mark.

In a Hague application, the USPTO should not object to non-compliance with the inventor data requirements. For example, if the inventor data source is the HAGUE.IR_PUB and that document shows the inventor without complete residence information, the PaDaCap contractor will not send a Notice to File Corrected Application Papers to obtain the missing residence information. If the needed residence information is available on another document within the application (for example, ADS or OATH), such document may be used as the source for the residence. If an inventor’s complete residence information is not provided in the Hague application, no residence will be printed for the inventor.

The inventor in a Hague application must be an individual human being. If an entity such as a company is identified as the inventor—for example:

—the PaDaCap contractor will initiate a printer RUSH. Such error should have been corrected prior to allowance. After receiving the RUSH, the Technology Center will be expected to withdraw the application from issue in order to have the inventorship corrected.

DCB No. 2019-17 Office of Data Management Page 1 of 9 image3.png image4.png image5.png image6.png image7.png image8.png image9.png image10.png image1.png image2.png