|
November 26, 2003
Trademark Daily XML Files - Weekly Status Report
New This Week:
1. There were 3 new inquiries since the last Weekly Status Report. Reference New Inquiries below.
2. The Trademark-Applications-v0.11-2003-11-20 DTD “B” version, the Trademark-Application-Documentation-v0.11 “B” version and Trademark-Application “B” version Sample Data dated 11/23/2003 are available on the TDXF DTD's, Documentation, and Sample Data page. Revision History is contained with the DTD.
Note: The Trademark-Application-Documentation-v0.11 “B” version contains Party Type Codes appearing on page 26 and Table 1 contains Trademark Status Codes.
~~~
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 is a status update on new inquiries and outstanding items.
Inquiries that were previously considered outstanding and have been resolved will have the resolution in black and bold.
Any inquiries that require additional research and/or response are considered outstanding inquiries and will appear in red and italicized.
~~~New Inquiries:
Inquiry – 11/26/2003:
serial number 78240639
<case-file-owners>
<case-file-owner>
<name-1>Larry L. Saret</name-1>
<name-2>Michael Best & Friedrich</name-2>
<name-3>Suite 1900</name-3>
******** name-3 contains part of the address ???
<party-type>70</party-type>
<address-1>401 North Michigan Avenue</address-1>
<address-2>Chicago, IL 60611</address-2>
</case-file-owner>
<case-file-owner>
<entry-number>01</entry-number>
<nationality>IL</nationality>
<name-1>A. Daigger and Company, Inc., through it</name-1>
<name-2>s ETA/Cuisenaire Division</name-2>
******* name continues name-1 on line name-2
******* when concatenating the lines we would normally combine the
lines using a space
******* however this would break up the word "through it s"
<party-type>10</party-type>
<address-1>500 Greenview Court</address-1>
<city>Vernon Hills</city>
<state>IL</state>
<postcode>60061</postcode>
<legal-entity-type-code>03</legal-entity-type-code>
</case-file-owner>
<case-file-owner>
<attorney-name>Larry L. Saret</attorney-name>
<entry-number>00</entry-number>
<party-type>00</party-type>
</case-file-owner>
</case-file-owners>
serial number 76209563
<case-file-owners>
<case-file-owner>
<name-1>HERBERT DUBNO</name-1>
<name-2>THE FIRM OF KARL F. ROSE P.C.</name-2>
<name-3>5676 RIVERDALE AVE. BOX 900</name-3>
********name-3 contains an address field
<party-type>70</party-type>
<address-1>RIVERDALE, NY 10471-0900</address-1>
</case-file-owner>
<case-file-owner>
<composed-of-statement>Dino Campi, a citizen of
Italy</composed-of-statement>
<entry-number>01</entry-number>
<nationality>ITX</nationality><name-1>AGNOPLAST DI CAMPI DOTTOR DINO E C.-S.N.</name-1>
<name-2>C.</name-2>
****** name-1 continues on line name-2
<party-type>10</party-type>
<address-1>Via Gasdotto 57</address-1>
<city>36078 Valdagno (Vicenza)</city>
<country>ITX</country>
<legal-entity-type-code>02</legal-entity-type-code>
</case-file-owner>
<case-file-owner>
<attorney-name>Herbert Dubno</attorney-name>
<domestic-representative-name>Karl F.
Ross</domestic-representative-name>
<entry-number>00</entry-number>
<party-type>00</party-type>
</case-file-owner>
</case-file-owners>1. How do we accommodate the addition of an address in the </name-3 field?
The source data uses the same tag names (name-1, name-2, name-3, address-1, address-2) for correspondence name/address and owner name/address. (Correspondence name/address is indicated by Party type = 70.)
The correspondence name/address data are stored as 5 lines, 40-character each line. The correspondence name/address data are placed into TDXF xml fields as: line-1 into name-1, line-2 into name-2, line-3 into name-3, line-4 into address-1, and line-5 into address-2. (That's why address data end up in name-3.)
The owner name/address data are stored as name-1, name-2, name-3, address-1, address-2, city, state, and zip code. The first 40 characters of an owner name is placed in name-1, second 40 characters in name-2, and third 40 characters in
name-3.
2. How do we concatenate name-1 and name-2 The way we planned on doing this was to add a space between name-1 and name-2 this does not always work as seen by the example?When concatenating owner name, do not add spaces between name-1 and name-2, and name-3.
3. Can you supply us with a list oodes that we will have to translate example "&" becomes "&"
This will be made available in the next weekly status report.
Inquiry – 11/17/2003:
The application documentation refers to an element named <standard-characters-claimed-in> inside the case-file-header but I can't seem to find it in the DTD/XML sample file you have posted on the web site.
The Trademark-Applications-v0.11 DTD, Trademark-Applications- Documentations-v0.11 and Trademark-Applications-Sample-Data-v0.11 to accommodate Trademark Daily XML “B” version including the above change is now present on the TDXF DTD's, Documentation, and Sample Data page.
~~~
Inquiry – 11/17/2003Is there a table for the international-status-code? If so can you provide this to us?
A table of Trademark Status Codes is now present in the Trademark- Applications-Documentations-v0.11 that is present on the TDXF DTD's, Documentation, and Sample Data page.
~~~
Outstanding Inquiries:Inquiry – 11/12/2003:
1. Using the Serial Number 78244966 as an example, this application has made a request for extension under Madrid Protocol to another country. Out on TARR you have the following Madrid Protocol Information:
USPTO Control Number: Z1230001
International Registration Number:
International Registration Date: (DATE NOT AVAILABLE)
Original Filing Date with USPTO: 2003-11-02
Priority Claimed: No
Date of Section 67 Priority Claim: (DATE NOT AVAILABLE)
International Registration Status: Application For
International Registration Certified
Date of International Registration Status: 2003-11-03
International Registration Renewal Date: (DATE NOT
AVAILABLE)
Date of Automatic Protection: (DATE NOT AVAILABLE)
Date International Registration Cancelled: (DATE NOT
AVAILABLE)
Date of Last Irregularity: (DATE NOT AVAILABLE)
First Refusal: NoWill we be receiving this information on an existing application/registration that has requested protection outside the U.S.? If so when and where? Will the IB Update the information that states (DATE NOT AVAILABLE) with the appropriate information? and will that then be received in the daily feeds?
There appear to be three fields listed here that are not included in the Applications DTD v0.10 -- they are USPTO Control Number, Original Filing Date with USPTO, and Date of Last Irregularity. And the last issue with this particular Serial Number, have you sent this record to WIPO yet, as it is not on the WIPO's Madrid Express database?
Available resources do not currently permit the necessary software changes at this time. Continued evaluation will be taken for possible future enhancement.
2. In the TICRs (24-hour Box) DTDs, there are several new <case-file-owner> (legal-entity-type-code) listed that have not been added to the Applications Element Table but we have seen this in our regular Daily Application feed (apYYMMDD.zip). As well there are new <case-file-statement> (type-code) that are also not included in the Applications Element Table. Also in the Base Application v2.11 DTD the <foreign-registration-file (file-name+)> is included in the Specimen Section, while all others are included in the Goods and Services Section.
In all v2.11 DTD with the exception of the Base Application DTD, within <goods-service> group the sequence-number is missing, as well the order of the various flags are different.3. In the actual TICRs feed, the 78 series JPEG images can be multiply occurring. Using the hr031110.zip file, SN78322221 has three JPEG images. Which image will be the one of record?
All inquiries concerning the 24 Hour Box remain under investigation.
4. We understand that you are working on a process to supply production related data on a daily basis. However the only Madrid related samples are the three records posted, would it be possible to receive a weekly file of
test records?The daily data will be available retrospective from November 2, 2003 as soon as some final technical issues are resolved.
~~~Inquiry – 11/12/2003:
In the Trademark-Applications "B" DTD, are there any plans to include the Country of Origin field as part of the new <international-registration> field? Or will there be some type of link between the fields that are found in the <international-registration> field and the fields related to the appropriate <foreign-application> field?
The appropriate area is investigating the possibility of receiving the Country of Origin from the International Bureau (IB).
~~~
Inquiry – 11/10/2003:There have been some additional issues found in last two sets of daily PTO XML files that we processed.
In the file AP031108.XML, in addition to a new un-documented Party Type value (Party Type 24 in SN 75938568), we found two examples of invalid <number> field values for the appropriate <prior-registration-application> field where the <relationship-type> field is equal to 1. For SN 75013069, the <number> field has the value 9980626O where the <relationship-type> field is equal to 1. For SN 74019291, the <number> field has the value 9920929T where the <relationship-type> field is equal to 1. According to the latest Trademark Applications Documentation, when the <relationship-type> field contains a value of 1 or 2, the <number> field will contain a Serial Number. Both 9980626O and 9920929T are not valid Serial Numbers.
In the file AP031109.XML, the <international-code> field with the value 001 appears twice for some reason for the same <classification> field for SN 71632775.
1. A new Party-Type table is present on page 26 of the Trademark- Applications-Documentations-v0.11 that is present on the TDXF DTD's, Documentation, and Sample Data page.
2. The file AP031108.XML contained invalid data for the data elements <relationhip-type> and <number> in Serial Number 750130609 and Serial Number 74019291. The corrected application data appeared in the daily process dated November 18, 2003.
~~~Inquiry – 11/06/2003:
In the last two days, our programs have had problems processing the daily xml data, due to un-documented party type values.
In AP031104.XML we found
Party Type 12 in SN 78134094 and
Party Type 22 in SN 76272081In AP031105.xml we found
Party Type 12 in:
1. 76108174
2. 76222858
3. 78135249
4. 78178202
and
Party Type 32 in 74367592We need to know as soon as possible if these are valid values or key entry errors. If they are valid we need to know text descriptions for each, or please direct us to the latest documentation enumerating these new values.
This was brought to the attention of the appropriate area and they acknowledged that new Party Types have been introduced and will be identified ASAP.
November 14, 2004 - A table of new Party Types has been presented for approval.
November 26, 2003 - A new Party-Type table is present on page 26 of the Trademark-Applications-Documentations-v0.11 that is present on the TDXF DTD's, Documentation, and Sample Data page.
~~~
Inquiry – 10/31/2003:
Correspondent and owner information are provided.
It is requested that the telephone number, the fax number and email address, if available information, for the correspondent and owner be provided.
This has been forwarded to the appropriate trademark area for investigation.
~~~Inquiry – 10/29/2003:
It is our understanding that we will be receiving from you after November 3rd a weekly test file of production data based on the DTD that will be frozen as of November 2nd. On January 2, 2004, we will begin receiving in the daily production feeds not only what we are receiving today; but also the inclusion of the Madrid related information based on the DTD that will be frozen as of November 2nd. Is that a true assumption? If so, then on January 2, 2004 will we be receiving all records that have been filed from November 2nd through January 1, 2004 under the Madrid agreement included in the daily January 2nd file -- or will there be a "catch-up" file sent to us with the Madrid related information filed from November 2, 2003 - January 1, 2004?
A decision was made on Thursday, October 30, 2003 that production version “B” Madrid data would be available beginning daily November 2, 2003.
The installment of these procedures have begun and will be made available and announced ASAP. The retrospective daily data back to November 2, 2003 will be made available at that time.
~~~Inquiry – 10/27/2003:
The Trademark Application “B” Sample Data dated 10/24/2003 contained unrecoverable data errors:
A corrected Trademark Application Sample Data “B” version dated 10/28/2003 has been placed on the TDXF DTD's, Documentation and Sample Data page.
The conversion of the Latin-1 character set to UTF-8 encoding caused the initial problem and is being corrected.
~~~
Inquiry – 10/27/2003Regarding the Trademark 24-Hour Box.
1. The IB v1.0 DTD does not match the sample record included.
2. The sample record file name is where the 79 series code is found, there is no reference within the sample of this number; nor a file date.
3. Do you have a Mapping Table or Element Definition for the IB v1.0 DTD elements?This inquiry has been represented to the appropriate trademark area for resolution.
~~~Inquiry – 10/21/2003
After reviewing the information sent to us over the last couple of week on the Madrid Protocol and have a couple of questions:1. It appears from the sample data you plan to have a new series 79. If this is correct, will the 79 series be used for a request for extension under protection of Madrid Protocol from the U.S. application going out; as well as a record filed with the International Bureau (IB) coming into the U.S.?
A new 79 series will be used for a request for extension for IB filings coming into the U.S.
2. In TICRs will we receive the IB generated applications prior to January 2nd?
IB generated applications should be present prior to January 2, 2004.
3. Is there a table for the international-status-code? If so can you provide this to us?
The Trademark-Applications-Documentation-V.10 “B” version has been replaced on the TDXF DTD's, Documentation and Sample Data page that includes the Madrid International-Status-Code Table.
~~~Inquiry – 10/9/2003
The TTAB daily file continues to contain illegal characters. I thought this issue would be resolved by now. Here is an excerpt from my log: 2003-10-09 02:09:14 tt031008.xml error: Parse error occurred - An invalid XML character (Unicode: 0x12) was found in the element ...
A correction is awaiting official authorization to be implemented and will not require a change to the DTD’s and should take place during the next maintenance update release.
~~~Inquiry – 9/17/2003:
All the XML files are supposed to be in UTF-8 format.
The following file TTAB tt030701.xml has ASCII value 146 twice in the following line.
ADMIN</charge-to-employee-name><status-update-date>20021008</status-update-date><status-code>9</status-code><party-information><party><identifier>260024</identifier><role-code>D</role-
code><name>PAT O'BRIEN'S BAR, INC.</name><property-information><property><identifier>245280</identifier>
The single quotes being sent to us are not in UTF-8 format.
This type of error can also be found in other TTAB xml files:
tt030515.xml
tt030711.xml
This is brought up because the TTAB files are still being produced with invalid charactersThis has been presented to the appropriate area for investigation.
~~~
Inquiry – 9/05/2003We have noted some discrepancies between the weekly text files and the daily XML files. The following is a case in point.
In the weekly text files Serial Number 78102397 (ASPEN) appeared in the TKAB section of the wt030805.txt, wt030812.txt and wt030826.txt files. (See attachment, weekly.txt, for excerpts of this record from these 3 files). The last file (wt030826.txt) shows that the TTAB status is 009(Terminated) and the decision code is 803 (Board's Decision: Dismissed w/ Prejudice).
In the daily XML files the last TTAB update for this record was in the tt030801.xml daily file with a <status-code> of 2 (pending) and a<status-update-date> of 20021223. No further TTAB updates were received for that record since that file. (See attached file, tt030801_78102397.xml, which is an excerpt from tt030801.xml file showing this record.)
It seems that this record slipped through the cracks in the daily xml updates.
We've found cases where some records are more up-to-date via the xml files, and others which are more up-to-date via the weekly text files. If a record is updated via the weekly text file, shouldn't we expect that same record in the xml files during that same week? In general, how soon after a record is updated by the PTO should we see that record in the xml daily files?
This has been presented to the appropriate area for investigation.
~~~Inquiry – 8/01/2003
The XML for the proceedings 76186764-EXT and 76186764-EXA do not match the USPTO Board Information System Index (BISX) online system (http://bisxext.uspto.gov/).
The USPTO BISX system shows 2 prosecution entries for 76186764-EXT while in the XML there are 8 <prosecution-entry> entries.
The USPTO BISX system shows 6 prosecution entries for 76186764-EXA while in the XML there are 8 <prosecution-entry> entries.
The <prosecution-history> entries for these TTAB records seem to have been merged in the XML generation.
This was determined to be an error in the software that maintains the data prior to the xml conversion. A correction will take place October 10, 2003.
NOTE: Due to additional changes the maintenance update release has been extended beyond October 10, 2003.
~~~Inquiry - 7/16/2003
Here is some more information/errors....
Processing XML File ==> xml\030620\tt030620.xml
start:: Wed Jul 16 12:05:31 EDT 2003
[Fatal Error] tt030620.xml:145:67181: An invalid XML character (Unicode: 0x12)
was found in the element content of the document.
error: Parse error occurred - An invalid XML character (Unicode: 0x12) was
found in the element content of the document.[Fatal Error] tt030621.xml:144:390195: An invalid XML character (Unicode: 0x12) was found in the element content of the document.
error: Parse error occurred - An invalid XML character (Unicode: 0x12) was found in the element content of the document.Processing XML File ==> xml\030625\tt030625.xml
start:: Wed Jul 16 12:14:58 EDT 2003
[Fatal Error] tt030625.xml:141:728318: An invalid XML character (Unicode:
0x12) was found in the element content of the document.
error: Parse error occurred - An invalid XML character (Unicode: 0x12) was
found in the element content of the document.Processing XML File ==> xml\030626\tt030626.xml
start:: Wed Jul 16 13:05:46 EDT 2003
[Fatal Error] tt030626.xml:143:292294: An invalid XML character (Unicode:
0x12) was found in the element content of the document.
error: Parse error occurred - An invalid XML character (Unicode: 0x12) was
found in the element content of the document.
All of the characters 0 through 31 and character 127 are nonprinting control
characters. With the exception of characters 09, 10, and 13, (Ox09,
Ox0A, and Ox0D) the others may NOT appear anywhere in an XML document.A correction is awaiting official authorization to be implemented and will not require a change to the DTD’s and should take place during the next maintenance update release.
~~~Inquiry - 7/14/2003
Is it possible to put in more line breaks into this file. The file is unable to be loaded into a normal text editor due to the line lengths (this is not true for the other xml files). Here is an example:
tt030701.xml, length of the longest line: 1309721, new line count: 252
A correction is awaiting official notification to be implemented.
~~~Inquiry - 7/03/2003
Poorly formatted addresses in XML
You are trying to fit unstructured data into a structured format, I propose you add an address-2 tag to hold the data in cases like this.
<proceeding-address>
<identifier>357358</identifier>
<type-code>C</type-code>
<name>DOUGLAS W SPRINKLE</name>
<orgname>GIFFORD KRASS GROH SPRINKLE ANDERSON & C</orgname> THIS
WAS CUT OFF SHOULD BE<orgname>GIFFORD KRASS GROH SPRINKLE ANDERSON & CITKOWSKI, P.C.</orgname>
<address-1>280 N OLD WOODWARD SUITE 400</address-1>
<city>BIRMINGHAM MICHIG</city>
<state>AN</state> THIS IS THE TAIL END OF THE ABOVE TAG
<postcode>48009</postcode>
</proceeding-address><proceeding-address>
<identifier>384315</identifier>
<type-code>C</type-code>
<name>EDGAR A. ZARINS</name>
<orgname>MASCO CORPORATION</orgname>
<address-1>21001 VAN BORN ROAD</address-1>
<city>TAYLOR MICHIG</city>
<state>AN</state> THIS IS THE TAIL END OF THE ABOVE TAG
<postcode>48180</postcode>
</proceeding-address><proceeding-address>
<identifier>387621</identifier>
<type-code>C</type-code>
<name>JOHN R GARBER</name>
<orgname>COOPER & DUNHAM LLP</orgname>
<address-1>1185 AVENUE OF THE AMERICAS</address-1>
<city>NEW YORK NEW YO</city>
<state>RK</state> THIS IS THE TAIL END OF THE ABOVE TAG
<postcode>10036</postcode>
</proceeding-address><proceeding-address>
<identifier>367755</identifier>
<type-code>C</type-code>
<name>STEVEN A. GIBSON</name>
<orgname>SANTORO DRIGGS WALCH KEARNEY ET AL</orgname>
<address-1>400 S FOURTH ST 3RD FL</address-1>
<city>LAS VEGAS NEVA</city>
<state>DA</state> THIS IS THE TAIL END OF THE ABOVE TAG
<postcode>89101</postcode>
</proceeding-address>You aren't validating the state code field.
<proceeding-address>
<identifier>292989</identifier>
<type-code>C</type-code>
<name>SALLY M. ABEL</name>
<orgname>FENWICK & WEST LLP</orgname>
<address-1>TWO PALO ALTO SQUARE</address-1>
<city>PALTO ALTO</city>
<state>C</state> INVALID STATE CODE
<postcode>94306</postcode>
</proceeding-address><proceeding-address>
<identifier>298457</identifier>
<type-code>C</type-code>
<name>KRISTI A. ZENTNER</name>
<orgname>FAFINSKI AND WALLRICH, P.A.</orgname>
<address-1>STE. 100 DUNNE MANSION 337 OAK GROVE STREET</address-1>
<city>MINNEAPOLIS</city>
<state>M</state> INVALID STATE CODE
<postcode>55403</postcode>
</proceeding-address>What code list are these from?
<proceeding-address>
<identifier>391698</identifier>
<type-code>C</type-code>
<name>SUSAN UPTON DOUGLASS</name>
<orgname>FROSS ZELNICK LEHRMAN & ZISSU, P.C.</orgname>
<address-1>866 UNITED NATIONS PLAZA AT FIRST AVENUE & 48TH
STREET</address-1>
<city>NEW YORK</city>
<state>N7</state> INVALID STATE CODE
<postcode>10017</postcode>
</proceeding-address><proceeding-address>
<identifier>369899</identifier>
<type-code>C</type-code>
<name>PETER L. COSTAS</name>
<orgname>PEPE & HAZARD LLP</orgname>
<address-1>225 ASYLUM STREET</address-1>
<city>HARTFORD</city>
<state>CN</state> INVALID STATE CODE
<postcode>06103</postcode>
</proceeding-address><proceeding-address>
<identifier>386393</identifier>
<type-code>C</type-code>
<name>ROLAND W. BAGGOTT III</name>
<orgname>THE BAGGOTT LAW OFFICES, L.L.C.</orgname>
<address-1>1316 CHRISTOPHER COURT</address-1>
<city>METATRIE</city>
<state>LO</state> INVALID STATE CODE
<postcode>70001-3804</postcode>
</proceeding-address>A correction has been presented to the data management area. Upon approval it will be implemented.
~~~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.
This was reported in the 6/27/2003 Status Report as being corrected. A correction is planned to take place October 10, 2003.
NOTE: Due to additional changes the maintenance update release has been extended beyond October 10, 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.The value of the <status-update-date> is in error. A correction is planned to take place October 10, 2003.
NOTE: Due to additional changes the maintenance update release has been extended beyond October 10, 2003.
~~~
Inquiry – 6/06/2003
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
Each DTD is currently maintained within the appropriate area of responsibility and uses country codes and names differently.
These differences have been presented to management and a decision to adhere to the WIPO Standard ST. 3 is being investigated.
If a decision is made to use the WIPO Standard ST. 3 changes would be required to have a separate field for the country code and a separate field for the state code.
~~~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 §.
In XML, there are only five predefined character entities, as follows:
Substituting a character entity reference for a character is REQUIRED by W3C for < and & in all cases where these characters are not markup. It's good practice to do it for the other three as well. That means, wherever these five characters are found in content or in comments, they should be replaced with the corresponding character entity.
Entity declarations will be made for other characters that are included in the trademark xml data according to the W3C Entity Reference recommendation.
Please Note: The above characters entities are awaiting official authorization to be implemented and will not require a change to the DTD’s.
~~~
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
Is there a question about what the USPTO can or cannot do that you cannot find an answer for? Send questions about USPTO programs and services to the USPTO Contact Center(UCC). You can suggest USPTO webpages or material you would like featured on this section by Email to the webmaster@uspto.gov. While we cannot promise to accommodate all requests, your suggestions will be considered and may lead to other improvements on the website.
|
|