U.S. Patent and Trademark Office Information Products Division Data Dissemination Trademark Daily XML Migration |
June 13, 2003
Weekly Status Report regarding the Trademark Daily XML Files
This is the initial weekly status report regarding the Trademark Daily XML Files.
Each Friday at the close of business a report will be provided that gives an updated status on the Trademark Daily XML Files. This weekly report will list all inquiries received each week and will give the latest status on outstanding items and responses to inquiries. A “No Change” announcement will be present if appropriate.
Inquiries can be made to: Ed Johnson at Ed.Johnson@uspto.gov - (703) 306-2621 or Marva Dubar at Marva.Dubar@uspto.gov - (703) 305-1669 or sent to OEIP@uspto.gov.
The following are responses to all inquiries received since May 23, 2003, listed by date of receipt. If any of the associated DTD’s need to be updated as a result of the response to an inquiry, an announcement will be provided stating effective date of the change. Any inquiries that require additional research and/or response are considered outstanding items and will appear in red and italicized. Their status will be updated in the next weekly report.
~~~Inquiry - 5/21/2003
1. The use of the <data-available-code> tag in all 3 Trademark Daily XML DTD's.
If a daily file exists for a given day the <data-available-code> tag within the dtd will not be present. If a daily file does not exist for a given day the <data-available-code> tag within the dtd will be present and contain the value "N".2. The Assignments DTD:
Reference this DTD as PUBLIC \"-//USPTO//DTD TRADEMARK_ASSIGNMENTS V0.2 2003-05-19//EN\"<!--
has been changed to:
Reference this DTD as PUBLIC "-//USPTO//DTD TRADEMARK_ASSIGNMENTS V0.2 2003-05-19//EN"-->
~~~
Inquiry - 5/23/2003
Problems exist over the use of the 'Section Sign' character inside the TTAB xml dated May 15, 2003. I did an UNIX command "od -hc" to dump the contents of the file so I could see what you are sending it as (247) which is causing the SAX parser to error. I think the character should be §.
We must look into the use of an entity declaration standard.
~~~
Inquiry - 5/23/2003
1. Will the TWTF format delivery be discontinued on June 24th?
The previously announced TWTF discontinuation date of June 24, 2003 is hereby cancelled. The TWTF will continue until the daily XML product meets our quality standards.
2. Will the monthly status file which will still exist after the conversion to XML be converted to an XML format? If so, when will the specification be delivered for the monthly format?
The monthly status file will be converted to XML. Because of the current work load to accommodate the Madrid Protocol no date to convert this process to XML has been announced.
3. Is there an event code list that the TARR system uses to translate event codes into literals as it appears the conversion TARR uses is different from the specification we received?
Reference Attachment #1 - TARR Event Codes/Literals.
4. When is the improved monthly status process going to be completed?
Upon completion of the Madrid Protocol.
5. Will a correction file be delivered which will correct all of the missed status updates from prior to when the corrected monthly status process is complete?
I have been informed that a retrospective file could be difficult to create. We will look into the possibility of a retrospective annual status file.
6. Will a complete XML "annual file" be delivered for conversion of all records to an XML format?
Once the Trademark Daily XML DTD's meet our quality standards the retrospective annual files will be available in XML.
7. We have discovered ~130 records for which the status and status date received from a TWTF update is more current than a status and status date received from a daily XML update. This means the record was not updated by a daily XML record but a status and status date change occurred in a TWTF file. Please investigate why this occurred.
An investigation showed that the date of transaction and update cycles were not extracting all data. Correction procedures are being looked into.
~~~
While processing the "tt030519.zip" xml data there were three proceedings that occurred twice.
Proceeding Nos: 76186764, 76033943, 76065114
The XML process uses the serial number as the proceeding number for Ex Parte (EXP) and Extension of Time (EXT). To ensure that the proceedings are unique each proceeding will be extracted and provided in the daily file using the <proceeding-entry> (<number>, <status-code> and <status-update-date>) tags.
~~~
Inquiry - 5/26/2003
Applications XML
No character encoding was defined for this file.
<?xml version = '1.0'?>
should be
<?xml version="1.0" encoding="UTF-8"?>
The applications xml file is corrected to include the prolog statement as in its DTD--<?xml version="1.0" encoding="UTF-8"?>
~~~
Proceedings XML
Mandatory child elements for 'proceeding-address' expected (it seems you are pumping out blank records)
The mandatory status of the <identifier> tags in the TTAB DTD <party>, <property>, <proceeding-address>, and <prosecution-entry> elements to be changed to optional.
Unexpected child element 'charge-to-location-code' (columns out of sequence as defined by DTD)
The sequence of the <proceeding-entry> (charge-to-location-code) element in the TTAB xml to be corrected.
~~~
Inquiry - 6/03/2003
We have been noticing in many older records that the <published-for-opposition-date> is zero filled; however previously we did receive a published date for the record. During your conversion or change to XML feeds have you lost this date?Using the latest file ap030602.zip here are two Serial Numbers 72406756 and 71444772 (in this file there were only about 6 records where the published date was missing).
In our research of this question, we found that the XML feed did not lose the <published-for-opposition-date> values. The Trademark Weekly Text File also has zero filled date values for the given serial numbers. This matter is being investigated further.
~~~
Inquiry - 6/04/20031. In response to a question relating to the apparent elimination of the (ASGN) Entry-Number, we were told on May 20, 2003 that:
A TWTF entry number between 0 to 399 that represented conveying party information will now be contained within XML Tags <assignors> </assignors>.
and that
A TWTF entry number between 400 to 599 that represented receiving party information will now be contained within XML Tags <assignees> </assignees>.
This response ignores the fact that the there were previously three "types" of entries. According to the TWTF specifications
A three-position numeric entry number that will identify the sequence of each entry of the same type. If the entry number is from 001 through 399 this is an assignor type record. Entry numbers 400 through 599 are used for mergers and name changes. If the entry number is greater than 599 this is an assignee type record.
Since there is now no way to represent this third distinction, apparently, this intermediate "merged into" information will be lost. It seems like another step backwards for the XML subscribers.
In response to the above inquiry we are providing the following information correcting the response on May 20, 2003:
1. A TWTF entry number between 0 to 399 that represented conveying party information will now be contained within XML Tags <assignors> </assignors>.
4 assignor examples follow:<assignors><assignor><person-or-organization-name>BORDEN CHEMICAL INVESTMENTS, INC.</person-or-organization-name><execution-date>20020923</execution-date><legal-entity-text>CORPORATION</legal-entity-text><nationality>DELAWARE</nationality></assignor>
<assignor><person-or-organization-name>B D S TWO, INC.</person-or-organization-name><execution-date>20020923</execution-date><legal-entity-text>CORPORATION</legal-entity-text><nationality>DELAWARE</nationality></assignor>
<assignor><person-or-organization-name>BFE CORP.</person-or-organization-name><execution-date>20020923</execution-date><legal-entity-text>CORPORATION</legal-entity-text><nationality>DELAWARE</nationality></assignor>
<assignor><person-or-organization-name>BORDEN CHEMICAL FOUNDRY, INC.</person-or-organization-name><execution-date>20020923</execution-date><legal-entity-text>CORPORATION</legal-entity-text><nationality>DELAWARE</nationality></assignor>
</assignors>2. A TWTF entry number between 400 to 599 that represented mergers and name changes for conveying party and receiving party information will now be contained within the appropriate XML Tags <assignees> </assignees> and <assignors> </assignors>.
The following is an example of a merger:
<assignment-entry><assignment><reel-no>2036</reel-no><frame-no>75</frame-no><purge-indicator>N</purge-indicator><date-recorded>20000217</date-recorded><page-count>52</page-count><correspondent><person-or-organization-name>WOLF, GREENFIELD & SACKS, P.C.</person-or-organization-name><address-1>DOUGLAS R. WOLF</address-1><address-2>600 ATLANTIC AVENUE</address-2><address-3>BOSTON, MA 02210</address-3></correspondent><conveyance-text>MERGER: EFFECTIVE 02-01-00</conveyance-text></assignment><assignors><assignor><person-or-organization-name>IMPERIAL TOBACCO LIMITED</person-or-organization-name><execution-date>20000201</execution-date><legal-entity-text>CORPORATION</legal-entity text><nationality>CANADA</nationality></assignor></assignors><assignees><assignee><person-or-organization-name>IMASCO LIMITED</person-or-organization-name><formerly-statement></formerly-statement><address-2>600 DE MASIONNEUVE BOULEVARD WEST, 20TH FLOOR</address-2><city>MONTREAL, QUEBEC</city><country-name>CANADA</country-name><legal-entity-text>CORPORATION</legal-entity-text><nationality>CANADA</nationality></assignee></assignees>
3. A TWTF entry number greater than 599 that represented receiving party information will now be contained within XML Tags <assignees> </assignees>.
3 assignee examples follow:<assignees><assignee><person-or-organization-name>FLEET CAPITAL CORPORATION, AS AGENT</person-or-organization-name><address-1>1 SOUTH WACKER DRIVE, SUITE 1400</address-1><formerly-statement></formerly-statement><city>CHICAGO</city><state>ILLINOIS</state><postcode>60606</postcode><legal-entity-text>CORPORATION</legal-entity-text><nationality>RHODE ISLAND</nationality></assignee>
<assignee><person-or-organization-name>FLEET CAPITAL CANADA CORPORATION, AS CANADIAN AGENT</person-or-organization-name><address-1>ONE SOUTH WACKER DRIVE, SUITE 1400</address-1><formerly-statement></formerly-statement><city>CHICAGO</city><state>ILLINOIS</state><postcode>60606</postcode><legal-entity-text>UNKNOWN</legal-entity-text></assignee>
<assignee><person-or-organization-name>FLEET NATIONAL BANK, LONDON U.K. BRANCH</person-or-organization-name><address-1>ONE SOUTH WACKER DRIVE, SUITE 1400</address-1><dba-aka-ta-statement>TA FLEETBOSTON FINANCIAL, AS UK AGENT</dba-aka-ta-statement><formerly-statement></formerly-statement><city>CHICAGO</city><state>ILLINOIS</state><postcode>60606</postcode><legal-entity-text>UNKNOWN</legal-entity-text></assignee></assignees>
~~~
Documentation
Our review of the "Trademark Trial and Appeal Board XML DTD Element Mapping Documentation [v .8]" (the most recent version that we are aware of) has found the following problems:XML Elements - At least four elements that are included in the DTD and in the files that we have received -- <code-type>, <data-available-code>, <day-in-location>, and < int-attorney-number> are not listed as XML Elements and are completely excluded from this document.
TWTF Elements - Despite the use of the word "mapping" in the title, there is none. Most of the items/terminology in the "TWTF Elements" bear no relation to the TWTF document whatsoever. The TWTF includes none of the following terms or equivalent data elements or many others -- Proceeding Information, Proceeding Entry, Proceeding Type, Role, or Country. What appears in the second column of that document is merely an explanation of the XML tag.
Descriptions -- This column contains the only explanatory information in the document. Unhappily much of it is incorrect or incomplete, making it generally unreliable.
- <status-text> is described as the literal that corresponds to the <status-code>. It is, in fact, nothing of the sort, but rather a variety of notes and notations like the following:
A IS 124817
ADDRESS NOT CHANGED; NEED REV & P/A
cl 9, 45, 41, 35
CONSOL W/91125739 & 91152596. NOT PARENT.
EXHIBIT IS ATTACHED TO THIS PAPER AS EXHIBIT A.
EXHIBITS
GRANTED UNTIL 01/26/03
HOLD 30
KL
PARENT
PLEASE PREPARE COMMISSIONER'S ORDER
READY FOR FINAL DECISION
SERVICE BY PUB- The stated maximum length of data bears no resemblance to the data that actually appears. For example <name> data that is described as "250 position" field is truncated at 40 characters.
- The <country> codes in use are not the 2 position WIPO Standard ST.3 codes that were previously furnished us, but the 3 position FIPS codes that have always been used in the TWTF.
- The definition for <orgname> includes two elements (appearing below in bold type) that simply do not exist.
- Organization and orgname are overflow fields for the Party Name. Instead of saying Party Name Line 1, Party Name Line 2 and Party Name Line 3, we use Name, Company, and Organization to help our users divide/organize party names the (sic) are extremely long.
The documentation for TTAB will be properly updated and will also include the proper mapping back to the TWTF process.
~~~
Other -- As several subscribers have pointed out over the past year, many of the type codes that are associated with the prosecution history <code> entries are incorrect. The response of May 20, 2003, indicated that new codes were "provided within the TTAB XML Documentation. " We have been unable to locate that documentation or the new table. Could you please tell us where to look?
Reference Table 1 – TTAB ENTRY-CODE in the Trademark-TTAB-v0.8-xml-dtd-elements.doc includes the TTAB event codes. This document is also at the following link: http://www.uspto.gov/web/offices/ac/ido/oeip/sgml/st32/trademark/announcement7.html
~~~Data Problems -- Some unknown problem has corrupted the address information of all (or most) non-US plaintiffs. Somehow the 3 character country codes are being added to the end of the street address <address-1> entries. In addition, in some situations a bogus state code has been added.
<name>GIVAUDAN SA</name>
<address-1>5, Chemin de la Parfumerie CHX</address-1>
<city>1214 Vernier</city>
<type-code>O</type-code>
<address-1>96 DUNCRUE STREET IEX</address-1>
<city>BELFAST</city>
<state>SC</state>
<postcode>BT3 9AR</postcode>
<name>Mediplast AB</name>
<address-1>Box 9504 SEX</address-1>
<city>200 39 MALMO</city>Despite the answer that relating to the address information in TTAB records, the simple fact is that the information is a mess. Element names bear little relationship to the data actually contained. was given to the long question of April 9,
- <address-1> information appears in the <name> element
<name>608-1661 Portage Avenue</name>
<address-1>WINNIPEG</address-1>
<city>MBC</city>
<postcode>R3J 3T7</postcode>- <orgname> information overflow and true <address-1> information are mixed together
<name>RAYMOND I GERALDSON, JR.</name>
<orgname>PATTISHALL MCAULIFFE NEWBURY HILLIARD</orgname>
<address-1>& GERALDSON 311 S WACKER DR STE 5000</address-1>
<city>CHICAGO</city>
<state>IL</state>
<postcode>60606</postcode>- <address-1> often includes <city> , <state> and <postcode> info as well.
<name>CORY M. AMRON</name>
<orgname>VORYS SATER SEYMOUR AND PEASE LLP</orgname>
<address-1>1828 L STREET NW, 11TH FLOOR WASHINGTON, DC 20036</address-1>
- <orgname> info can be <name> overflow or other matter. Sometimes when it is name overflow words are split across fields.
<identifier>301226</identifier>
<type-code>O</type-code>
<name>Capital Markets Company, Naamloze Vennoo</name>
<orgname>tschap, The</orgname>
<address-1>26 10 Antwerpen-Wihijk BEX</address-1>- <city> information appears in the <Address-1> field and
<name>41 Lesmill Road</name>
<address-1>NORTH YORK, ONTARIO</address-1>
<city>CAX</city>
<postcode>M3B 2T3</postcode>- Corrupted <city> entries overflow into <state>
<name>ANTHONY D CIPOLLONE</name>
<address-1>ONE ESSEX STREET</address-1>
<city>HACKENSACK NEW JERS</city>
<state>EY</state>All TTAB data problems concerning tags and data content of addresses have been investigated and resolved.
~~~
Inquiry - 6/05/2003
We recently find two new design codes
02.13.33 and 27.17.07 which was not in our old design code list
App. No. 76-471152, 78-244519, 78-243142
76-512538, 76-395307, 78-243423.
We would like to get a copy of the updated US design Codes
in order to update our database.
The USPTO Design Search Code Manual is located at: http://tess2.uspto.gov/Please Note: After an investigation of design codes 02.13.33 and
27.17.07
it was determined that these are not valid design search codes.
02.13.33
was corrected to 02.01.33 and 27.17.07 was corrected to 26.17.07 for
applications specified.~~~
Series code “90” started to appear in the daily XML Assignment files. See references below:
1. <action-key-code>DA</action-key-code>
<transaction-date>20030602</transaction-date>
<assignment>
<reel-no>2660</reel-no>
<frame-no>0653</frame-no>
<last-update-date>20030602</last-update-date><property>
<serial-no>90428771</serial-no>
<registration-no>0428771</registration-no>
</property>2. <assignment-entry>
<action-key-code>DA</action-key-code>
<transaction-date>20030603</transaction-date>
<assignment>
<reel-no>2561</reel-no>
<frame-no>0920</frame-no>
<last-update-date>20030603</last-update-date><property>
<serial-no>90370940</serial-no>
<registration-no>0370940</registration-no>
</property>3. <property>
<serial-no>90413800</serial-no>
<registration-no>0413800</registration-no>
</property>4. <assignment-entry>
<action-key-code>DA</action-key-code>
<transaction-date>20030603</transaction-date>
<assignment>
<reel-no>2661</reel-no>
<frame-no>0981</frame-no>
<last-update-date>20030603</last-update-date><property>
<serial-no>90206394</serial-no>
<registration-no>0206394</registration-no>
</property>9 followed by the registration number is a pseudo serial number. This occurs when the registration number (given by the customer) does not exist in the TRAM application data. The assignment database requires a serial number; therefore a pseudo serial number is created.
~~~
We have been analyzing the most recent set of daily XML files, and have
found the following problem in address field mapping. From initial
observations, it seems to be consistent for all Assignees when both the
Address-1 and the Address-2 fields have values.
Please investigate :
After analyzing the most recent Trademark Daily XML Assignment DTD related
data files, we have some issues with the way the ADDR-1 field and the
ADDR-2 field, which are both located in the TWTF ASGN record, are being
mapped to their appropriate fields located in the <assignee> (assignees)
tag.
We understand that the content of the ADDR-1 field should be mapped to the
<address-1> field (which is part of the <assignee> field), while the
content of the ADDR-2 field should be mapped to the <address-2> field
(which is also part of the <assignee> field). But this does not seem to be
the case when both the ADDR-1 and the ADDR-2 fields have values. When both
of these fields have values, it looks like the ADDR-1 field is being
incorrectly mapped to the <address-2> field, while ADDR-2 field is being
incorrectly mapped to the <address-1> field. Here are some examples of
this issue:
a. For the Assignment record where the Reel Number is 2658 and the Frame
Number is 0663, which can be found in Tuesday's (June 3) TWTF file, there
is one assignee related ASGN record. Here are the values of the ADDR-1
field and the ADDR-2 field for this ASGN record where the NAME-1 field is
equal to "EMRYS TECHNOLOGIES, LTD.":For the ASGN record described above, the value of the ADDR-1 field was
Field Value ADDR-1 SUITE 350 ADDR-2 100 N. CENTRAL EXPY.
incorrectly mapped to the <address-2> field (which is part of the
<assignee> field), while the value of the ADDR-2 field was incorrectly
mapped to the <address-1> field (which is also part of the <assignee>
field). This was verified in the Assignment data file called AS030529.xml
that contains the most up-to-date version of this Assignment record (which
appeared in last Tuesday's TWTF file).
b. For the Assignment record where the Reel Number is 2658 and the Frame
Number is 0731, which can be found in Tuesday's (June 3) TWTF file, there
is one assignee related ASGN record. Here are the values of the ADDR-1
field and the ADDR-2 field for this ASGN record where the NAME-1 field is
equal to "FOSTER PRODUCTS CORPORATION":
Field Value ADDR-1 WLB Law - Trademarks ADDR-2 1200 Willow Lake Boulevard For the ASGN record described above, the value of the ADDR-1 field was
incorrectly mapped to the <address-2> field (which is part of the
<assignee> field), while the value of the ADDR-2 field was incorrectly
mapped to the <address-1> field (which is also part of the <assignee>
field). This was verified in the Assignment data file called AS030529.xml
that contains the most up-to-date version of this Assignment record (which
appeared in last Tuesday's TWTF file).c. For the Assignment record where the Reel Number is 2659 and the Frame
Number is 0007, which can be found in Tuesday's (June 3) TWTF file, there
is one assignee related ASGN record. Here are the values of the ADDR-1
field and the ADDR-2 field for this ASGN record where the NAME-1 field is
equal to "IMAGEWEAR APPAREL CORP.":
Field Value ADDR-1 3411 SILVERSIDE ROAD ADDR-2 201 BAYNARD BUILDING
For the ASGN record described above, the value of the ADDR-1 field was
incorrectly mapped to the <address-2> field (which is part of the
<assignee> field), while the value of the ADDR-2 field was incorrectly
mapped to the <address-1> field (which is also part of the <assignee>
field). This was verified in the Assignment data file called AS030529.xml
that contains the most up-to-date version of this Assignment record (which
appeared in last Tuesday's TWTF file).The above inquiry is being investigated and a resolution will be forthcoming.
~~~
The Trademark Daily XML Process Documentation for Trademark Assignments XML DTD points to the old version (0.1) and not the current (0.2) version. Here is the page with the bad link http://www.uspto.gov/web/offices/ac/ido/oeip/sgml/st32/trademark/announcement7.html
The Trademark Assignments XML DTD to be updated with the correct Assignments DTD version number.
~~~
I have found and error in an assignment. The property serial number is not valid (to the best of my knowledge) as shown below<property>
<serial-no>24752836</serial-no>
<registration-no>
</registration-no>
</property>This is the header information for that entry (I have modified your xml format a little to suit so don't do any dtd compares)
<assignment-entry>
<action-key-code>DA</action-key-code>
<transaction-date>20030603</transaction-date>
<assignment>
<reel-no>2561</reel-no>
<frame-no>0920</frame-no>
<last-update-date>20030603</last-update-date>
The client provided the incorrect serial number. However to correct this the client will have to file a corrected assignment.
~~~
Inquiry - 6/06/2003
An issue has recently come to our attention. It appears the Supplemental
Register Flag is not getting set in the weekly file nor in the daily XML
feed.
If you take a look at the following Serial Number 72101593 in the weekly
file received on June 3rd and the daily file ap030603 -- you'll see that the
flag is not turned on. But when we look in the OG from 1962 it was
published in the Supplemental Register.
This matter is being investigated further.
~~~
In reviewing the country codes for each of the 3 XML files and discovered the following
*Trademark-Applications XML
Uses 3 digit code from TWTF file
*Trademark-Assignments XML
Uses no codes at all, they expand all codes (Spelling out countries)
*Trademark-Proceedings XML
Uses officially designated country as prescribed by the World Intellectual Property Organization
(WIPO) Standard ST.3
This difference has been presented to management and a decision to adhere to the WIPO Standard ST. 3 should be implemented with the Madrid Protocol.
~~~Inquiry - 6/09/2003
After analyzing the most recent Trademark Daily XML TTAB DTD related data
files, we found the following issues:
1. The <filing-date> field (which is part of the <proceeding-entry> tag)
does not always have the correct value. Here are some examples of this
issue:
a. For the Proceeding Number 92042024, which can be found in last Tuesday's
(June 3) TWTF file, the value of the DT-FIL field (which is located in the
TWTF TTAB record) is "20030310". In the TTAB data file called
TT030529.xml, which contains the most up-to-date version of this TTAB
Proceeding, the value of the <filing-date> field is "20030529". This is
incorrect since this Proceeding was filed on March 10th, 2003.
b. For the Proceeding Number 92042025, which can be found in last Tuesday's
(June 3) TWTF file, the value of the DT-FIL field (which is located in the
TWTF TTAB record) is "20030430". In the TTAB data file called
TT030529.xml, which contains the most up-to-date version of this TTAB
Proceeding, the value of the <filing-date> field is "20030529". This is
incorrect since this Proceeding was filed on April 30th, 2003.
c. For the Proceeding Number 92042026, which can be found in last Tuesday's
(June 3) TWTF file, the value of the DT-FIL field (which is located in the
TWTF TTAB record) is "20030424". In the TTAB data file called
TT030529.xml, which contains the most up-to-date version of this TTAB
Proceeding, the value of the <filing-date> field is "20030529". This is
incorrect since this Proceeding was filed on April 24th, 2003.
2. The <status-update-date> field (which is part of the <proceeding-entry>
tag) does not always have the most up-to-date value after the value of the
<status-code> field (which is also part of the <proceeding-entry> tag)
changes. Here are some examples of this issue:
a. For the Proceeding Number 91154190, which can be found in last Tuesday's
(June 3) TWTF file, the value of the DT-STAT field (which is located in the
TWTF TTAB record) is "20030529" and the value of the STAT field (which is
also located in the TWTF TTAB record) is "9" (Terminated). In the TTAB
data file called TT030528.xml, the value of the <status-update-date> field
is "20030103" and the value of the <status-code> field is "2" (Pending) for
this TTAB Proceeding. In the TTAB data file called TT030529.xml, which
contains the most up-to-date version of this TTAB Proceeding, the value of
the <status-code> field is changed to "9" (Terminated), but the value of
the <status-update-date> field remains the same ("20030103") for some
reason. Instead, this field should have the value "20030529" just like in
last Tuesday's (June 3) TWTF file.
b. For the Proceeding Number 91154593, which can be found in last Tuesday's
(June 3) TWTF file, the value of the DT-STAT field (which is located in the
TWTF TTAB record) is "20030529" and the value of the STAT field (which is
also located in the TWTF TTAB record) is "9" (Terminated). In the TTAB
data file called TT030528.xml, the value of the <status-update-date> field
is "20030122" and the value of the <status-code> field is "2" (Pending) for
this TTAB Proceeding. In the TTAB data file called TT030529.xml, which
contains the most up-to-date version of this TTAB Proceeding, the value of
the <status-code> field is changed to "9" (Terminated), but the value of
the <status-update-date> field remains the same ("20030122") for some
reason. Instead, this field should have the value "20030529" just like in
last Tuesday's (June 3) TWTF file.This inquiry is being investigated and proper corrections will be applied.
If you have any questions or need additional
information please contact one of the following individuals:
Ed Johnson | Marva Dubar |
Information Products Division | Information Dissemination |
Data Dissemination Branch | Systems Division |
(703) 306-2621 | (703) 305-1669 |
(703) 306-2737 Fax | (703) 308-5164 Fax |
Ed.Johnson@uspto.gov | Marva.Dubar@uspto.gov |
HOME | INDEX | SEARCH | SYSTEM STATUS | BUSINESS CENTER | NEWS&NOTICES | CONTACT US | PRIVACY STATEMENT |