**Trademark Daily XML Process**

**Frequently Asked Questions (FAQ)**

**May 20,2003**

## Inquiries/Responses

**March 18, 2003 (Including March 5, 2003) Inquiries:**

[ASSIGN data:]{.underline}

In the old ASSIGN segment format the element \"data effective date of
deed (DEEX)\" is found in the USPTO file in positions 35-42. We don\'t
find this same element in the XML data (or DTD received on the data file
or the proposed DTD.). Has this element been suppressed from the new
format? If it is present in the new format, what is its equivalent name?

**This data has not been eliminated; if it exists it will appear in the
element \<conveyance-text\> following the Brief Code Description. See
Example #1 in [Attachment
#1](http://www.uspto.gov/web/offices/ac/ido/oeip/sgml/st32/trademark/TDXFFAQ3ATTACHMENT1.doc).**

Also in the old format (ASSIGN) we have the element (ASGN) entry-number
found in the USPTO file in positions 49-51. In the correspondence table,
this is equivalent to the xml tag \"entry_num \". However, we don\'t
find any examples of this element in the data that we have received, nor
do we find it explicitly described as a valid element in the DTD that
arrives with the weekly data. Can you give us a status of this element?
(We currently receive and process this data element and would like to
have an equivalent, as we are not changing the overall design of our
database.)

**In response to the above inquiry we will provide the following:**

**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\>**

\~\~\~\~\~\~

**A TWTF entry number between 400 to 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\>**

\~\~\~\~\~\~

And on the ELEMENT DTD, we find the elements/tags \"formerly
statement\", \"dba-aka-ta-statement\" and \"composed-of-statement\".
However, we have found no examples of these data tags in the daily
updates that we are receiving. Are these populated fields? (We currently
do not process the equivalent tags for these elements in the old
format.)

**Yes, these fields are populated. I have copied an example (in some
cases two) of each from the files. See Examples #2 through #8 in
[Attachment
#1](http://www.uspto.gov/web/offices/ac/ido/oeip/sgml/st32/trademark/TDXFFAQ3ATTACHMENT1.doc).
Little known facts: In 1995 we stopped capturing DBA/AKA/TA or composed
OF for assignors/conveying parties and only capture this information for
records recorded after May 9, 1995** **for assignee/receiving parties.
In 1995 we stopped capturing Formerly statements for assignees/receiving
parties. The filer of the assignment is NOT required to provide this
information. So if an assignment is filed that contains a DBA/AKA/TA or
composed of statement for a conveying party or a formerly statement for
a receiving party the information is not entered into the Assignment
Historical Database. However, if the user provides a formerly statement
for the conveying party and/or a Composed Of or DBA/AKA/TA the
information is entered appropriately. An assignment can only contain one
statement for either DBA/AKA/TA per party name, so if for some strange
reason an assignment had one dba and one ta for the same party only one
would be captured.**

**[TTAB data:]{.underline}**

As you know we are continuing to receive the \"old weekly format\" for
trademark updates, each Tuesday by FTP. In this \"old\" format, we are
looking up the TTAB entry codes in a table (Table 3, version update
September 30, 1998). Example, in this document below we look up code
\"124\" in the table, find the type \"N\", and voila:

1/136664 USMARK - (C) Questel.Orbit

SN -- 78200982

MARK- SOFTNESS YOU CAN SEE

TTAB- Cancellation N92041532 Pending 2003-01-30 Filing date: 2003-01-16

Defendant: APN :75157864, RGN:2184705

Mark: SOFTNESS YOU CAN SEE

Owner: SCOTT PAPER LIMITED

1900 MINNESOTA COURT, SUITE 125 CAX

MISSISSAUGA, ONTARIO L5N 3-C9

Corresp.addr: SCOTT PAPER LIMITED 1900 MINNESOTA COURT, SUITE 125

CAX MISSISSAUGA, ONTARIO, L5N 3C9

2003-01-30 (128 N) PENDING, INSTITUTED

2003-01-30 (707 E) NOTICE AND TRIAL DATES SENT ;ANSWER DUE

2003-01-16 (124 N) FILED AND FEE

Meanwhile, we are working on our new programs to process the xml format.
And in this example in the ttab xml file from 20030210 (where it is not
necessary to reference a separate table) we find that the tag code (124)
and the tag type-code (T) don\'t match the \'N\' that we would find in
the table for the same document:

in the file of 20030210:

\<prosecution-entry\>

\<identifier\>1\</identifier\>

\<code\>124\</code\>

\<type-code\>T\</type-code\> \-\-\--\> normally (referred in table doc)
, it\'s N

\<date\>19990401\</date\>

\<history-text\>FILED AND FEE\</history-text\>

We have found similar discrepancies between old format TTAB type entries
and the new format XML data for TTAB codes 107, 128, 144, 338, 643, 707,
and 900. Is our look up table wrong? or is the xml input data wrong? If
it is the look-up table, can you please send me the current version and
history of when this version was applied?

**A new TTAB Entry Code table with the above mentioned entry codes is
provided within the TTAB XML Documentation.**

\~\~\~\~\~\~

**April 1, 2003 Inquiries:**

1\) We have examined the XML files that we have in our possession and
have not been able to confirm the routine inclusion of Party-Type 30
anytime within the month that follows the date of issue of the
registered mark.

**The daily transactions are extracted to the XML files each night and
become available through our FTP site at 2:00 a.m. the subsequent day.
Currently the daily transactions that appear in the Official Gazette
each Tuesday are extracted on Monday night. Party-Type 30 transactions
are processed during the business day each Tuesday and are associated
with a Tuesday issue date. Therefore they are never extracted and
included in the daily XML file. To resolve this discrepancy the
transactions appearing in the Official Gazette will be extracted on
Tuesday night and be available on our FTP site at 2:00 a.m. each
Wednesday morning. This will take effect the week beginning May 12,
2003.**

2\) We have also made a thorough study regarding the inclusion of the
622 status on the monthly status tape and have found none. We have come
to understand that the only PTO product that includes this information
is one of the Contractor\'s Reports. Since that report will be
eliminated as part of the transition to the XML formatted files, that
information will not be available.

3\) We also found that a number of statuses that were listed in the
specification do not, for one reason or another, actually appear
consistently (or at all) on either of the daily or the monthly files.
This problem, which heavily affects updates to post-allowance statuses,
has long existed on the weekly files. Apparently, the daily file
operates using a similar extract logic and has many of the shortcomings
of its predecessor.

**To answer 2) and 3) above - The process to create the monthly status
file will be changed to include all statuses such as 622 that are
currently not included.**

\~\~\~\~\~\~

**April 9, 2003 Inquiries:**

After analyzing the most recent Trademark Daily XML TTAB 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 PART record, are being
mapped to their appropriate fields located in the \<proceeding-address\>
(address-information) tag. Based on your responses to some of our
previous inquiries, we understand the following to be true:

The \<proceeding-address\> (address-information) tag\--where
\<type-code\> equals \"O\" for Owner information\--will contain the
content of the TWTF/PART record ADDR-1, ADDR-2, CITY, STE/CTRY and
ZIP-CD fields.

When the ADDR-1 field has a value, and the ADDR-2 field does no have a
value, the content of the ADDR-1 field is correctly being mapped to the
\<address-1\> field (which is part of the \<proceeding-address\> field)
where the \<type-code\> field is equal to \"O\". We have no issues with
this. Here is an example of this scenario:

For the Proceeding Number 91150011, which can be found in yesterday\'s
(April 8, 2003) TWTF file, there are two PART records.

Here are the values of the ADDR-1 field and the ADDR-2 field for the
PART record where the NAM-1 field is equal to \"COLE, SCOTT\":

Field Value

ADDR-1 P.O. BOX 1357 ADDR-2

Here are the values of the ADDR-1 field and the ADDR-2 field for the
PART record where the NAM-1 field is equal to \"G & M CREATIONS INC.\":

Field Value

ADDR-1 8925 HEATHERMORE BLVD. \# T2 ADDR-2

For both of the PART records described above, the value of the ADDR-1
field was properly mapped to the appropriate \<address-1\> field (which
is part of the \<proceeding-address\> field) where the \<type-code\>
field is equal to \"O\". For both of these \<proceeding-address\> fields
where the \<type-code\> field is equal to \"O\", both the \<name\> field
and the \<orgname\> field do not exist. This was verified in the TTAB
data file called tt030403.xml that contains the most up-to-date version
of this proceeding (which appeared in yesterday\'s TWTF file).

When both the ADDR-1 and the ADDR-2 fields have values, it seems that
the content of the ADDR-1 field is being mapped to the \<name\> field
(which is part of the \<proceeding-address\> field), while the content
of the ADDR-2 field is being mapped to the \<orgname\> field (which is
also part of the \<proceeding-address\> field). Here are some examples
of this:

a\. For the Proceeding Number 92040079, which can be found in
yesterday\'s (April 8, 2003) TWTF file, there are two PART records.

Here are the values of the ADDR-1 field and the ADDR-2 field for the
PART record where the NAM-1 field is equal to \"BRASWELL, A. GLENN\":

Field Value

ADDR-1 1500 OCEAN BLVD., APT. 1208 ADDR-2 250 SUMMER STREET

For the PART record described above, the value of the ADDR-1 field was
mapped to the appropriate \<name\> field (which is part of the
\<proceeding-address\> field), while the value of the ADDR-2 field was
mapped to the appropriate \<orgname\> field (which is also part of the
\<proceeding-address\> field). For this \<proceeding-address\> field
where the \<type-code\> field is equal to \"O\", the \<address-1\> field
does not exist. This was verified in the TTAB data file called
tt030403.xml that contains the most up-to-date version of this
proceeding (which appeared in yesterday\'s TWTF file).

b\. For the Proceeding Number 91150358, which can be found in
yesterday\'s (April 8, 2003) TWTF file, there are two PART records.

Here are the values of the ADDR-1 field and the ADDR-2 field for the
PART record where the NAM-1 field is equal to \"COOPERATIVE FOR AMERICAN
RELIEF EVERYWHE\":

Field Value

ADDR-1 185 PINE CREEK AVENUE ADDR-2 SUITE A

For the PART record described above, the value of the ADDR-1 field was
mapped to the appropriate \<name\> field (which is part of the
\<proceeding-address\> field), while the value of the ADDR-2 field was
mapped to the appropriate \<orgname\> field (which is also part of the
\<proceeding-address\> field). For this \<proceeding-address\> field
where the \<type-code\> field is equal to \"O\", the \<address-1\> field
does not exist.

This was verified in the TTAB data file called tt030405.xml that
contains the most up-to-date version of this proceeding (which appeared
in yesterday\'s TWTF file).

For the two examples described above where both the ADDR-1 and the
ADDR-2 fields had values, both the \<name\> field and the \<orgname\>
field were populated with these values, while the \<address-1\> field
was completely excluded from the \<proceeding-address\> field where the
\<type-code\> field is equal to \"O\". This is not very intuitive. It
does not make sense to put address related information in the \<name\>
and \<orgname\> fields. It would probably make more sense if the
\<proceeding-address\> field also had an \<address-2\> field (which
currently does not exist in the TTAB DTD). If the \<address-2\> field
did exist, then the ADDR-1 field could have always been mapped to the
\<address-1\> field, while the ADDR-2 field could have been mapped to
this new \<address-2\> field, no matter what values the ADDR-1 and the
ADDR-2 fields had.

Furthermore, we found examples where both the \<name\> field and the
\<orgname\> field (for the appropriate \<proceeding-address\> field
where the \<type-code\> field is equal to \"O\") were populated with
values, while both the ADDR-1 field and the ADDR-2 field (which are both
located in the TWTF PART record) had no values at all. This is a major
issue since these values could not be found in the appropriate TWTF PART
records. Here are some examples of this issue:

a\. For the Proceeding Number 91150221, which can be found in
yesterday\'s (April 8, 2003) TWTF file, there are two PART records:

For the PART record where the NAM-1 field is equal to \"BALLY TOTAL
FITNESS HOLDING CORP.\", both the ADDR-1 field and the ADDR-2 field had
no values. For the appropriate \<proceeding-address\> field (that
relates to this PART record) where the \<type-code\> field is equal to
\"O\", the \<name\> field, for some reason, had the value \"8700 W. BRYN
MAWR\", while the \<orgname\> field had the value \"370 WABASHA
STREET\". Both of these values could not be found in this PART record.

For the PART record where the NAM-1 field is equal to \"HOFFMAN FORGED
PRODUCTS\", both the ADDR-1 field and the ADDR-2 field had no values.
For the appropriate \<proceeding-address\> field (that relates to this
PART record) where the \<type-code\> field is equal to \"O\", the
\<name\> field, for some reason, had the value \"5470 OLD MILLINGTON
ROAD\", while the \<orgname\> field had the value \"370 WABASHA
STREET\". Both of these values could not be found in this PART record.
These findings were verified in the TTAB data file called tt030403.xml
that contains the most up-to-date version of this proceeding (which
appeared in yesterday\'s TWTF file).

b\. For the Proceeding Number 91150801, which can be found in
yesterday\'s (April 8) TWTF file, there are two PART records. For the
PART record where the NAM-1 field is equal to \"TECHNOLOGIES ADVANCES ET
MEMBRANES INDUS\", both the ADDR-1 field and the ADDR-2 field had no
values. For the appropriate \<proceeding-address\> field (that relates
to this PART record) where the \<type-code\> field is equal to \"O\",
the \<name\> field, for some reason, had the value \"Z.A. LES LAURONS
FRX\", while the \<orgname\> field had the value \"NEW DELHI-110 020\".
Both of these values could not be found in this PART record. This was
verified in the TTAB data file called tt030404.xml that contains the
most up-to-date version of this proceeding (which appeared in
yesterday\'s TWTF file).

Please look into the issues described above; especially the issue where
both the \<name\> field and the \<orgname\> field were populated with
values, while both the ADDR-1 field and the ADDR-2 field had no values
at all.

**The \<proceeding-address\> (address-information) record will contain
the content of the TWTF/PARC Correspondence information, COOR-ADDR(1)
through COOR-ADDR(5) fields. The \<proceeding-address\>
(address-information) record [will not contain]{.underline} the
TWTF/PART Owner Address information. The Trademark Application DTD will
contain the updated Owner Address information.**

**For further clarification of the Correspondence Address information,
where \<type-code\> (proceeding-address) equals \"C\" for Correspondence
information:**

• the \<name\> (proceeding-address) tag will contain the content of the
TWTF/PARC record COOR-ADDR(1) field,

• the \<orgname\> (proceeding-address) tag will contain the content of
the TWTF/PARC record COOR-ADDR(2) field,

**• the \<address-1\> (proceeding-address) tag [may]{.underline} contain
the concatenated content of the TWTF/PARC record COOR-ADDR(3) through
COOR-ADDR(5) fields; or, the \<address-1\> (proceeding-address) tag will
contain the content of the TWTF/PARC record COOR-ADDR(3) through
COOR-ADDR(5) fields parsed into the \<address-1\>, \<city\>, \<state\>,
\<country\>, and \<postcode\> ( proceeding-address) tags. See the 10
Examples of Proceeding-Address in [Attachment
#2](http://www.uspto.gov/web/offices/ac/ido/oeip/sgml/st32/trademark/TDXFFAQ3ATTACHMENT2.doc).**

\~\~\~\~\~\~

**April 17, 2003 Inquiries:**

We are doing analysis between the weekly TWTF vs. the daily XML feeds
and have run into an interesting issue. Using the TWTF of this week
(April 14, 2003) and the TTAB information of tt030405.zip; there are
many records that

have the Address information listed in a NAME or ORGNAME field tag. This
does not seem right to us. Especially of concern is number 91150359 \--
where the Defendant information appears to be correctly dispersed, while
the Plaintiff information uses the NAME and ORGNAME for address related
information. See the three examples below.

**Please reference the previous response for April 9, 2003 in bold.**

Also, could you tell us what the cut-off date for the inclusion into the
weekly TWTF is versus the daily XML feeds? We are in the process of
considering our migration plans.

**The final Trademark Weekly Text File will be created and disseminated
on Tuesday June 24, 2003.**

\~\~\~\~\~\~

**May 2, 2003 Inquires:**

There is a \<case-file\> record in the ap030423.xml data file where the
\<mark-drawing-code\> field has an incorrect value. For the
\<case-file\> record in this data file where the \<serial-number\> field
is equal to \"78148061\", the value of the \<mark-drawing-code\> field
is \"M01\". This value is invalid for this field. Please look into this
issue.

**The case file for serial number 78148061 became corrupt. This case
file is being investigated and will be corrected.**