PRODUCTS   
Products and Services > Trademark Daily XML Files - Weekly Status Report
U.S. Patent and Trademark Office
Information Products Division
Data Dissemination
Trademark Daily XML Migration

September 24, 2004

Trademark Daily XML Files - Weekly Status Report

The following is a status update for all inquiries.

Inquiries can be made to: Ed Johnson at Ed.Johnson@uspto.gov - (703) 306-2621 or Jazmin Rexrode at Jazmin.Rexrode@uspto.gov - (703) 306-2626 or sent to OEIP@uspto.gov.

*The format of the Weekly Status Report will appear as follows:
1. Each inquiry is given a USPTO Control # for tracking purposes.
2. The summary portion of “Status of Inquiries” will be “grouped” by the current status.
3. The detail portion of the report will be in sequence Control # (for easier reference).

~~~

Any inquiries that require additional research and/or response are considered outstanding inquiries and will appear in red, bold and italicized.

Inquiries that have been resolved will have the resolution in black, bold, italicized and underlined.

~~~

For Your Information – FYI:

09/24/2004:

Control #96:

Servers and other hardware are being moved to the USPTO Data Center in Crystal City in preparation of the subsequent move to the Alexandria Campus.

The majority of the equipment maintained by OEIP is used to produce the CASSIS line of products and the equipment that is used to disseminate the daily trademark files is being replaced.

Phase 1: September 20, 2004 - Hardware used to produce CASSIS products was successfully moved.

Phase 2: September 23, 2004 - Hardware used to produce USAApp and USAPat products was successfully moved.

Phase 3: September 29, 2004 - Hardware used to produce NTAF products

Phase 4: October 2004 - New hardware to support the Data File Delivery (DFD) FTP system has been ordered and will be installed and configured in the USPTO Data Center in Crystal City.

04/16/2004:

"The U.S. Patent and Trademark Office is processing paper Madrid filings within a week of receipt and electronic applications within hours. Information is generally viewable on the USPTO website within 24 hours of the completion of Trademark processing. In addition to the work done on Madrid filings at the USPTO, there is also processing at the International Bureau of WIPO. Thus, in certain circumstances pendency is influenced by any backlogs that might develop at WIPO."

~~~

08/13/2004:

Requirements and Proposed Schedule for the updated Trademark Daily Applications product – Control #61

Requirements:

  1. The updated Trademark Daily Application product will include all data fields provided in the current product. Reference the Trademark Applications Daily XML DTD Element Documentation (v.12) located on the TDXF DTD's, Documentation, and Sample Data page.
  2. Provide all MADRID PROTOCOL INFORMATION (including Madrid History and Multiple transactions) for applications going to the International Bureau (IB).
  3. Provide all MADRID PROTOCOL INFORMATION for applications received from the International Bureau (IB).
  4. Provide status code changes on a daily basis that are now only provided in the Monthly Status file.
  5. Provide the Date In Location and the Law Office Assigned in addition to the <law-office-assigned-location-code> field that is currently provided.
  6. Provide the Abandonment-Date and Mis-Assigned Numbers.This information is currently only available in the Monthly Contractor Reports.
  7. Provide 2-character WIPO Standard ST. 3 country codes in the <nationality> field and the <country> field of the <case-file-owner>.
    Note: The data in the Correspondent Address is free form text and will remain that way.

Proposed Schedule:

NOTE: Once the updated Daily Application product is accepted and placed into production, the Monthly Status File and the Monthly Contractor Reports will be discontinued in a timely manner.

~~~

Availability of Files:

09/24/2004:

All files for the week ending September 24, 2004 were available on time.

Control #92 - All (3) Trademark Daily XML Files (TDXF) dated 09/16/2004 were missing.

apb040916.zip (Applications) was available by close of business on 9/20/04.
asb040916.zip (Assignments) was available by close of business on 9/17/04.
tt040916.zip (TTAB) was available by close of business on 9/17/04.

Control #93 - All (3) Trademark Daily XML Files (TDXF) dated 09/17/2004 were missing.

apb040917.zip (Applications) was available by close of business on 9/20/04.
asb040917.zip (Assignments) was available by close of business on 9/20/04.
tt040917.zip (TTAB) was available by close of business on 9/20/04.

All files dated 09/16/2004 and 09/17/2004 were not provided on time because a security patch that had been installed interrupted the internal transfer of these files. This problem has been corrected.

~~~

Control #94 - The Supplemental 24 Hour Box File, hrs040914a.zip, contained 3 files with a .bak extension and were not readable.

76568446.tif.bak
76610422.tif.bak
76610423.tif.bak

For each of the above files there was a corresponding .jpg file.

These .tif.bak files are automatically created when an image is mistakenly cropped twice keeping the earlier cropped image from being overwritten. These .bak images should not have been present and corrective measures have been put in place.

~~~

Control #95 - The 24 Hour Box File, hr040915.zip, did not have any associated .xml data for the jpg images.

All of the files were 76 series code paper filed applications. 76 series code applications do not have associated xml data.

~~~

Status of Inquiries:

09/17/2004:

Closed: Control #92, Control #93, Control #94, Control #95, and #103

In Process:

Control #61 - Requirements and Proposed Schedule for the updated Trademark Daily Applications product will be updated and tracked in the FYI section above. This also includes Control #’s 84 through 91, Control #’s 97 through 102 and Control #’s 104 through 107.

~~~

Inquiry – 09/03/2004: Control #84

The following xml statement in the current xml daily files contains:
<?xml version="1.0" encoding="UTF-8" ?>

Because a DTD is included inside the XML files being disseminated the XML statement should contain:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

09/24/2004:

The updated daily applications requirements (Control #61) will be changed accordingly. This change will not be applied to the current production data file.

~~~

Inquiry – 09/07/2004: Control #85

Since you're in the mood to reorder element names.

Here is a suggestion for <case-file-owner>

<!ELEMENT case-file-owner(entry-number?, party-type?, nationality?,
legal-entity-type-code?, name-1?, name-2?, name-3?, address-1?, address-2?,
city?, state?, country?, postcode?, attorney-name?,
domestic-representative-name?, composed-of-statement?,
name-change-explanation*, dba-aka-text?, entity-statement?, name-overflow?)>

09/17/2004:

After taking the above suggestion the following is being further suggested:

<!ELEMENT case-file-owner (entry-number? , party-type? , nationality? , legal-entity-type-code? , entity-statement? , name, address-1? , address-2? , city? , state? , country? , postcode? , dba-aka-text? , composed-of-statement? , name-change-explanation* , attorney-name? , domestic-representative-name?)>

Note: name-1, name-2, name-3, name-overflow would be removed and replaced by: name

The party type and entry-number handle different owner names.

For instance -

Where currently:

<case-file-owner>
<entry-number>01</entry-number>
<nationality>CKX</nationality>
<name-1>Southpac Trust International, Inc. (a co</name-1>
<name-2>rporation of the Cook Islands), not indi</name-2>
<name-3>vidually, but as Trustee of the Family T</name-3>
<party-type>10</party-type>
<address-1>P.O. Box 11</address-1>
<address-2>Centrepoint</address-2>
<city>Rarotonga</city>
<country>CKX</country>
<legal-entity-type-code>99</legal-entity-type-code>
<entity-statement>TRUST</entity-statement>
<name-overflow>rust U/T/A dated December 8,
1995.</name-overflow>
</case-file-owner>

Would look like the single name:

<case-file-owner>
<entry-number>01</entry-number>
<party-type>10</party-type>
<nationality>CKX</nationality>
<legal-entity-type-code>99</legal-entity-type-code>
<entity-statement>TRUST</entity-statement>
<name>Southpac Trust International, Inc. (a corporation
of the Cook Islands), not individually, but as Trustee of
the Family Trust U/T/A dated December 8, 1995.
</name>
<address-1>P.O. Box 11</address-1>
<address-2>Centrepoint</address-2>
<city>Rarotonga</city>
<country>CK</country>
</case-file-owner>

And, if there were a second owner the <entry-number> would equal 02 and the <party-type> would still equal 10.

If there were a subsequent owner that caused a new party-type the <party-type> would increment accordingly and the <entry-number> would start anew at 01.

09/24/2004:

The above suggestion will be applied to the updated daily applications requirements (Control #61).

~~~

Inquiry – 09/08/2004: Control #86

In all records on the test file why does the attorney appear as a separate <case-file-owner> and not included with the Correspondent (party-type 70) <case-file-owner> as is present on TARR?

An example is : 72/267663

It contains the following

<case-file-owner>
<attorney-name>DARBY &amp; DARBY</attorney-name>
<entry-number>0</entry-number>
<party-type>00</party-type>
</case-file-owner>

It does not contain a valid party-type code value, yet on TARR it is included with the Correspondent party-type 70.

09/24/2004:

This continues to be reviewed and any change will be included in the updated daily applications requirements (Control #61) with proper notification.

~~~

Inquiry – 09/08/2004: Control #87

The following element is missing from the <madrid-international-filing- request> group.

International Registration Renewal Date - Reference TARR for Serial No.: 78308872

<!ELEMENT madrid-international-filing-record (entry-number,
reference-number, original-filing-date-uspto, international-
registration-number?, international-registration-date?, international-
status-code?, international-status-date?, international-renewal-date?,
irregularity-reply-by-date?, madrid-history-events?)>

The following element is missing from the <madrid-history-event> group.

number - Determine the sequence of events within the group

<!ELEMENT madrid-history-event (number, code, date, description-text)>

09/24/2004:

The above fields will be applied to the updated daily applications requirements (Control #61) and the content of the number field will be defined.

~~~

Inquiry – 09/08/2004: Control #88

The following element <Madrid-international-filing-request> should be renamed to <Madrid-international-filing-requests>. The “s” is be added to be consistent with the naming convention being used.

09/24/2004:

The above suggestion will be applied to the updated daily applications requirements (Control #61).

~~~

Inquiry – 09/13/2004: Control #89

1. One of the requirements states that the updated Trademark Daily Applications product will provide all MADRID PROTOCOL INFORMATION for applications received from the International Bureau (IB). Are there any plans to add new data elements (fields) to the <international-registration> group data element?

The data elements listed in the international-registration group are for incoming requests from the IB.

The new group madrid-international-filing-requests is for outgoing requests to the IB.

2. The sample XML file (Test-v2.0-20040902.xml) that was included in your email on September 3rd did not have any record samples that included the new <abandonment-date> data element.

Records that have abandonment dates will be provided in the next test file.

If the <abandonment-date> field does have a value for a particular record, will the <status-code> field (that is part of the <case-file-header> field) for that record always have the value "622"? - No.

And will the <status-date> field (that is part of the <case-file-header> field) always have the same value as the <abandonment-date> field if the <abandonment-date> field does have a value for a particular record? – No.

3. One of your requirements states that the updated Trademark Daily Applications product will provide 2-character WIPO Standard ST. 3 country codes in the <nationality> field and the <country> field of the <case-file-owner>. This might have been answered previously, but can you please tell us where we can find the latest version of these 2-character WIPO Standard ST. 3 country codes?

A table will be provided in the Applications Documentation that Supports the new requirements.

~~~

Inquiry – 09/13/2004: Control #90

Will there be another trademark application daily XML 2.0 sample file and DTD before October?

09/24/2004:

Updated versions of the new applications requirements DTD, Documentation and Test Data are available at: TDXF DTD's, Documentation, and Sample Data page.

~~~

Inquiry – 09/17/2004: Control #91

The correspondent will be moved from the case-file-owners section along with attorney-name and domestic-representative-name

Then add the following to the case-file-header section:

<!ELEMENT correspondent (person-or-organization-name, address-1?, address-2?, address-3?, address-4?)>
<!ELEMENT person-or-organization-name (#PCDATA)>
<!ELEMENT address-1 (#PCDATA)>
<!ELEMENT address-2 (#PCDATA)>
<!ELEMENT address-3 (#PCDATA)>
<!ELEMENT address-4 (#PCDATA)>

(placed after tag <!ELEMENT attorney-docket-number (#PCDATA)>

<!ELEMENT attorney-name (#PCDATA)>
<!ELEMENT domestic-representative-name (#PCDATA)>
<!ELEMENT correspondent (person-or-organization-name, address-1?, address-2?, address-3?, address-4?)>
<!ELEMENT person-or-organization-name (#PCDATA)>
<!ELEMENT address-1 (#PCDATA)>
<!ELEMENT address-2 (#PCDATA)>
<!ELEMENT address-3 (#PCDATA)>
<!ELEMENT address-4 (#PCDATA)>

and before tag <!ELEMENT principal-register-amended-in (#PCDATA)>

~~~

Inquiry – 09/21/2004: Control #97

The following errors appeared on the test data file:

1. The <status-date> element either contains an invalid date or is completely non-existent:

Invalid status date error: Serial Nos.: 71/069796, 71/358982, 71/617729

Missing status date element: Serial No.: 71/194337, 72/123294

This has been corrected in the test data dated and provided 09/24/2004.

2. The <correspondent> group doesn't contain the following tag <person-or-organization-name>

This is true of the entire file. All of those tags are missing and instead <address-1>, <address-2>, <address-3>, <address-4>, <address-5> are used.

The DTD will refer to five lines of address (person-or-organization-name has been changed). It cannot be guaranteed that the value found in this field contains a person or organization. The field name has been changed to address-1. Reference Control #91.

3. The <case-file-owner> contains a tag named <party-name> this should display as <name>. Please refer to control #85.

This has been corrected in the test data dated and provided 09/24/2004.

4. The <correspondent> group doesn't match what had been discussed in Control #91

The Status Report should have been updated to reflect the tag names that are being used in the DTD and the Documentation. They are not in sync at the moment. I am referring to #3 and 4 in my list above.

The DTD dated and provided 09/24/2004 has been updated accordingly.

~~~

Inquiry – 09/21/2004: Control #98

VERSION 2.0 REQUEST:

Can you remove the empty <international-registration> section that
is being sent on applications even though no data exists?

This example is from apb040920.xml daily XML

<case-file>
<serial-number>71473147</serial-number>
<registration-number>0412800</registration-number>
<transaction-date>20040920</transaction-date>
...
...
<international-registration>
<international-registration-number/>
<international-registration-date/>
<international-publication-date/>
<international-renewal-date/>
<auto-protection-date/>
<international-death-date/>
<international-status-code/>
<international-status-date/>
<priority-claimed-in/>
<priority-claimed-date/>
<first-refusal-in/>
</international-registration>

09/24/2004:

Empty optional tags will not be present in the 2.0 XML data.

~~~

Inquiry – 09/22/2004: Control #99

We've been seeing an increase in records where the Mark-Drawing-Code has been changed from a 3 (Words and Design) or a 5 (Stylized) to a 4 (Standard Character Set), yet the drawings contain undeniable design elements.

If I may paraphrase what I've read, an applicant may submit a standard character drawing if the mark does not include a design element. If the drawing includes elements that ar not in the standard character set, then the applicant is required to delete the standard character claim.

Attached , for your convenience, is a document containing 3 instances (sns 78459822, 78312468, 78246151) of cropped sections of TARR displays, showing drawings with design elements yet standard character set is claimed.

The fact that the mark drawing code was changed from 3 to 4 in all three records indicates willfulness and not accident therefore we felt it necessary to ask for an explanation of these three instances. Are these records in error or are we misunderstanding this standard character claim?

09/24/2004:

Please refer to the mark-drawing-code descriptions for applications filed prior to November 2, 2003 and applications filed on or after November 2, 2003 – Trademark-Applications-Documentation-v2.0-09242004, page 6.
~~~

Inquiry – 09/22/2004: Control #100

1. The XML application data contains the tag <employee-number> and contains a unique identifier assigned to each employee. Here is an example:

Serial No.: 75/683159

<law-office-assigned-location-code>M30</law-office-assigned-location-code>
<employee-number>66486</employee-number>

TARR displays this information as:

Law Office Assigned: LAW OFFICE 112
Attorney Assigned: WILLIAMS IRENE D

Where can we link to the employee information so we can display information similar to TARR. TARR also provides a link to the employee information but uses the NAME information to search and not the number as seen in this URL http://pair.uspto.gov/cgi-bin/final/employee_loc.pl?NAME=WILLIAMS%20IRENE

2. The element <employee-number> is flagged as optional yet it seems that even if you don't have any information you fill it with zeros.

<employee-number>00000</employee-number>

09/24/2004:

1. This has been forwarded to the Trademark Business area for a response.

2. The zero filled data was present in the database. Further investigation is required.

~~~

Inquiry – 09/23/2004: Control #101

It has been discussed that the Status Descriptions out on Tarr are
slightly different than those that are included in Table 1 Trademark Status Codes included with the latest Trademark Applications Element documentation. However, if you take a look at Serial Number 76515339, we have a USPTO Status Code of 773 (which translates to 'Interference proceeding terminated'), while TARR has 'Extension of Time to Oppose Process - Terminated'.

09/24/2004:

Application 76515339 was updated on 09/23/2004 if it is still in error we must know when the above data was present on the Daily Application XML file.

~~~

Inquiry – 09/23/2004: Control #102

In today's application file there were four records SN# 81035864, 82486816, 82486817, 82486819. These records had limited information and out on TARR they have limited information as well. They have Status Dates that are old...why are these being sent to us in the daily file?

09/24/2004:

The continuous appearance of these “8” applications has been forwarded to the Trademark Business area for a resolution.

~~~

Inquiry – 09/23/2004: Control #103

The assignment file dated 09/23/2004 had about 15 times the normal amount of records.

Due to scheduling concerns, we'd like to know the reason this file was so big and if we should expect this kind of volume on a consistent basis.

09/24/2004:

A correction was applied to numerous assignment records. This increase in the amount of transactions will not happen often. In the future we will attempt to foresee any volume increase and make a notification accordingly.

~~~

Inquiry – 09/20/2004: Control #104

In the test data a 2 digit year has surfaced, you will notice that this application has a status date that starts with '00' instead of '19':

<case-file>
<serial-number>71069796</serial-number>
<registration-number>0094274</registration-number>
<transaction-date>20040907</transaction-date>
<case-file-header>
<filing-date>19130415</filing-date>
<registration-date>19131125</registration-date>
<status-code>800</status-code>
<status-date>00950119</status-date>

09/24/2004:

This has been corrected in the test data dated and provided 09/24/2004.

~~~

Inquiry – 09/23/2004: Control #105

I have come across a country code that doesn't exist in the documentation, but exists in the sample XML file.

<case-file-owner>
<entry-number>1</entry-number>
<party-type>10</party-type>
<nationality>GB</nationality>
<legal-entity-type-code>11</legal-entity-type-code>
<party-name>FTSE International Limited</party-name>
<address-1>St, Alphage House</address-1>
<address-2>Podium Floor</address-2>
<city>London EC2Y 5DA</city>
<country>XP</country>
</case-file-owner>

I have also come across a class status code that doesn't exist in the documentation but exists in the sample file.

<classification>
<international-code-total-no>1</international-code-total-no>
<us-code-total-no>5</us-code-total-no>
<international-code>009</international-code>
<us-code>021</us-code>
<us-code>023</us-code>
<us-code>026</us-code>
<us-code>036</us-code>
<us-code>038</us-code>
<status-code>W</status-code>
<status-date>20040730</status-date>
<first-use-anywhere-date>19890330</first-use-anywhere-date>
<first-use-in-commerce-date>19890330</first-use-in-commerce-date>
<primary-code>009</primary-code>
</classification>

09/24/2004:

This has been corrected in the test data dated and provided 09/24/2004.

~~~

Inquiry – 09/23/2004: Control #106

I have found an issue with the following field:

<nationality> The <nationality> element is optional and occurs zero or one times between the <nationality> start and </nationality> end tags and contains CITIZENSHIP, a three-position alphanumeric field. The content of this field will be the State/Country code of the applicant/assignee/registrant citizenship. The country will appear as a three-character code. The state will appear as a two-character code followed by a space. (Refer to Table 2 State/Country Code List.) This field is not relevant for records with a party type of 70.
</nationality>  

The code list in Table 2 contains duplicate code values. There is no way for me to determine whether "CA" means "CANADA" or "CALIFORNIA" using table 2. I am unable to merge the US STATE codes with the WIPO COUNTRY codes because of this.

09/24/2004:

This has been corrected in the Trademark-Applications- Documentation-v2.0-09242004.

~~~

Inquiry – 09/20/2004: Control #107

We have some additional questions related to the requirements for the updated Trademark Daily Applications product.

1. The sample XML file (Test-v2.1-20040917.xml) that was included in your email on September 17th did have some record samples that included the new <abandonment-date> data element. But we found some records in this sample XML file where the <abandonment-date> field value is more recent (newer) for some reason than the <status-date> field value for the same record. Here are some examples:

<serial-number> <status-date> <abandonment-date>
73122504 00780330 19801201
73124098 00811116 19920506
73124555 00870630 19880102
73125380 00781030 19921116
73125405 00830331 19830713

Please also note that the first two digits of the <status-date> field (that is part of the <case-file-header> field) are incorrect for all of the records in this sample XML file where the Year portion of the <status-date> field is less than "2000". The first two digits of the <status-date> field for these records should be "19", and not "00" as shown in the examples above.

2. For some reason, the <status-date> field is missing for a good number of records in the sample XML file (Test-v2.1-20040917.xml) that was included in your email on September 17th. Here are some examples:

<serial-number>
73124376
73128172
73154844
76602997
78308872

3. One of your requirements states that the updated Trademark Daily Applications product will provide 2-character WIPO Standard ST. 3 country codes in the <nationality> field and the <country> field of the <case-file-owner>. We found some scenarios where a particular 2-character country code in the <nationality> field (of the <case-file-owner>) could map to more than one value. Here are some examples:
a. If the <nationality> field has the value "AL", does this value map to "ALBANIA" or "ALABAMA"?
b. If the <nationality> field has the value "AR", does this value map to "ARGENTINA" or "ARKANSAS"?
c. If the <nationality> field has the value "AZ", does this value map to "AZERBAIJAN" or "ARIZONA"?
d. If the <nationality> field has the value "CA", does this value map to "CANADA" or "CALIFORNIA"?
e. If the <nationality> field has the value "CO", does this value map to "COLOMBIA" or "COLORADO"?
f. If the <nationality> field has the value "DE", does this value map to "FED REP GERMANY" or "DELAWARE"?
g. If the <nationality> field has the value "GA", does this value map to "GABON" or "GEORGIA"?

09/24/2004:

This has been corrected in the test data dated and provided 09/24/2004.

~~~

If you have any questions or need additional information please contact one of the following individuals:

Ed Johnson Jazmin Rexrode
Office of Electronic Information Products Office of Electronic Information Products
(703) 306-2621 (703) 306-2626
(703) 306-2737 Fax (703) 306-2737 Fax
Ed.Johnson@uspto.gov Jazmin.Rexrode@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.

|HOME | SITE INDEX| SEARCH | eBUSINESS | HELP | PRIVACY POLICY