| Products and Services > Red Book ICE: Frequently Asked Questions |
|
|
|
Red Book ICE Frequently Asked Questions Updated February 1, 2007 with changes highlighted in yellow.
Definitions
TWSWG
Trilateral/WIPO Standards Working Group
Trilateral
European Patent Office + Japan Patent Office + USPTO
WIPO
World Intellectual Property Organization
PCT
Patent Cooperation Treaty (administered by WIPO)
ICE
International Common Elements
RB
Red Book (XML markup for US published patent documents)
GRB
Grant Red Book (XML markup for US patent grant publications)
ARB
Application Red Book (XML markup for US patent application publications)
The International Common Elements (ICE) are the elements used in the DTD’s contained in Appendix 2 of Annex F of Part 7 of the PCT’s Administrative Instructions. The Trilateral Offices have agreed to use the Annex F DTDs as the basis for electronic filing of national applications and for publishing patent applications and patent grants. Using a single format specification for electronic filing and publication is expected to benefit applicants and Offices by significantly reducing the cost and time of processing as compared to paper applications.
Q
The segments in the old USPTO input file called GOVT - Government Interest, PARN - Parent Case Data, and BSUM - Brief Summary do not appear to be specifically tagged in the new DTDs and sample data. Will we no longer receive the GOVT, PARN, and BSUM fields?
I have noticed while scanning the fulltext, that some records have the processing instructions and some do not. Additionally, the DTD has no mention of either the <header> processing instructions, or other embedded processing instruction I have found, such as <?insert> and <?delete>. Can you please provide the type of records where <header> processing instructions are provided? i.e., were they added starting with a certain publication date, or are they present for grants only, etc. Can you please provide a thorough list of all processing instructions used in the ICE XML format, with a description of their attributes? For those records without <header> processing instructions, how do you recommend sections of the <description>, such as Brief Summary and Detailed description, to be isolated?
A
For each section of the description, the <header> element will be populated with whatever section titles the applicant provided. Processing instructions are now used to identify the borders of sub-document elements (see Processing Instructions in Red Book ICE DTDs for details).
There is no provision in DTD syntax to document processing instructions, so you should not expect to see anything in the Red Book DTD's about processing instructions. By their nature, processing instructions inserted by the USPTO are system specific, that is, they do not have a publicly negotiated interpretation. Each customer is free to process them in any way they like, or discard them. They have no bearing on the meaning of the grant or application in which they appear.
Processing instructions to mark sections (subdocuments) were first introduced in published applications, and later in grants. They should now be appearing in both. Sorry, I don’t have the data necessary to provide an exact start date for either applications or grants.
For ICE Red Book documents that do not have processing instructions for subdocuments, you may wish to identify text in the production instance (Red Book ST.32) that appears immediately after the ST.32 tag marking that section, and search for that same text in the corresponding ICE instance. This workaround will fail at the end of the parallel run, that is, starting in 2005 January, since only one version will then be available. At that time you will have to rely on the content of any <heading> tags that are present, processing instructions, or other clues in the text.
Q
Will the sequences be within the xml files or will all sequences (and not only very large sequence files) be given in supplemental files?
… in the new ICE grant sample from 040106, the sequence listings are in a separate xml file. This file does not include the associated grant serial number. By checking the PTO site, we know that in the case below, the sequence number should be attached to the US document that follows the sequence listing rather than the document that precedes it. Can you please include the associated document number in the header of the sequence file? Can you please clarify the rules for managing separate sequence listing files?
A
With the start of the parallel run, all sequence listings are treated as external entities. An element has been added to the DTD for sequence listings to indicate the document with which it was published. In the text-only version of the Red Book products, the sequence listing will be inserted immediately following the document with which it was published, rather than preceding it, provided it is not a mega sequence. Mega sequences are delivered in a separate tar file on the same DLT as the rest of an issue, but are not included in the text-only version.
Q
What about the sequence listings of biosequence patents? Is the WIPO ST.25 still applied or will the format be changed? Will the old format be cancelled?
A
Sequence listings in Red Book ICE will be just as they are in the current versions of Red Book.
Q
In earlier drafts, <related-publication> contains an unstructured form of the document ID.
A
The new content model permits either #PCDATA or <document-id>, that is, a fully structured document identification.
Q
A mathematical structure (<maths>) no longer supports multiple math content models.
A
That is correct. However, separate TIFF and *.nb files will be created for each of the equations marked up in a single MathML instance. Creating separate MathML instances for equations that appear in sequence would require a significant labor investment, while separating the TIFF and .nb files can be done entirely by machine.
Q
Why have all ISO entities have been converted to Unicode formatted entities?
A
Primarily to ease rendering in IE6. IE6 is preferred for the Red Book Viewer because it is the most widely used browser that supports full rendering from XML.
Q
The Grant Red Book Term of grant (B472) has an optional disclaimer date (B473), but it is required within the ICE disclaimer content model.
A
The TWSWG agreed to modify the content model so that disclaimer date is optional. The USPTO has implemented the change in the production versions of RB ICE.
Q
B650 data within PARENT-US has no equivalent mapping within the ICE parent/child relationships.
A
A new element <parent-PCT-document> was added to <parent-doc>.
Q
Why are there no reexaminations in Red Book?
A
The TWSWG has not concluded its discussions of how to tag insertions and deletions. Supporting insertions and deletions will likely affect every element in all the Annex F Appendix 2 DTDs. For reissue documents, insertions and deletions are indicated with XML processing instructions until such time as the TWSWG discussions have concluded.
Q
Element figref is no longer allowed in table entry.
A
The content model for table cells has been revised to include figref, so the element <crossref> will no longer be used for that purpose as of approximately April 15, 2004.
Q
Within ICE, the unstructured <text> element no longer permits highlighting.
A
In ICE, <text> and <dtext> do not and will not support highlighting. Where necessary, workarounds will be employed and documented.
Q
The claim header that exists in ST32 Red Book is being dropped in ICE Red Book.
A
There is no equivalent mapping. A solution has been proposed and will be implemented when agreed and when the production schedule permits. This FAQ will be updated at that time.
Q
Can you please give details on how the USPTO is going to actually send citation information as opposed to how it is described in the DTD?
A
We have updated our strategy for markup of non-patent literature. Red Book documents will use <othercit> within <nplcit>, which has been modified to support highlighting. The citation will be transcribed as it was provided by the applicant, with the same minor editing that we have done in the past, and the only tagging will be for bold, underline, or italic, as needed, to present the citation as it was in previous versions of Red Book. See also FAQ 65.
Q
What is the <npl> element <relevant-claims>.
A
These are the claims to which the cited publication contributes some understanding.
Q
Can you please explain in some detail the types and attributes of the claims data?
A
Note that the overall structure of the claims content model is very similar to our current published documents. The attribute “num” is used by many elements where it is customary to number a series in sequence; in this case, it would be the sequence number of the claim. Some industrial property offices will use this attribute for the claim number. The USPTO will continue its current practice, that is, the claim number proper is part of the content of the element, as given by the applicant. The attribute “num” might or might not be the same as the claim number.
Q
What is <industrial-applicability>?
Have the former redbook/greenbook fields <RELAPPS>/PARN, <GOVINT>/GOVT, <DETDESC>/DETD and <BRFSUM>/BSUM been suppressed in the ICE format and replaced by a catch-all <description> tag? If so, how can I reliably identify the former components that have been subsumed in <description>?
Can the USPTO create ICE elements that correspond to these former greenbook/redbook st. 32. elements as it has done for DRWD <description-of-drawing>?
A
The Administrative Instructions of the PCT provide some standard section titles for patent applications, for which explicit elements have been provided in the <description>, since it is derived from the <application-body> DTD, which was designed expressly for PCT applications. Other such sections include <technical-field>, <background-art>, <disclosure>, <description-of-drawings>, <best-mode>, <mode-for-invention>. Most of these will not be used in publication by the USPTO, unless they were populated by the applicant in an electronic application and the published document uses the XML from the electronic filing (a condition rarely met at the time of writing). Instead, the <heading> of a <p> will be populated with the section titles provided by the applicant. The USPTO normally does not modify the section titles provided by the applicant, even though the MPEP offers some suggestions. If section titles are entirely absent, then <heading> will be populated with the suggested text from the MPEP by the data-capture contractor. Since industrial property offices around the world do not at present agree on section titles, only those mentioned in the PCT administrative instructions have explicit markup, a condition which is very unlikely to change.
Q
What is <figure-to-be-published>?
A
This element will contain the number of the figure published on the front page of a patent grant or in the corresponding entry in the Official Gazette: Patents. Equivalent to B597US.
Q
What is <office-of-filing>?
A
This element is for the industrial property office where the application in which priority is claimed was filed. See <priority-claim>.
Q
What is <designated-states-as-inventor>?
A
In most of the rest of the world, the applicant might or might not be the inventor. If the application was filed by a group of individuals, under the PCT, should they choose to do so, they have the option of rotating the role of inventor among them for each of the states they have designated for filing. For the US, the applicant and the inventor are (almost) always the same individual(s). The USPTO will not populate this element. See question 37 below for further information.
Q
Does the element <us-provisional-application> (B680US) in <us-related-documents> reliably replace the provisional information that historically was found only in the old greenbook fields "CASE", "BSUM" or other natural language/text field?
A
That is the intention. If you find that the information is not reliable, please tell us which documents are in error so that they can be corrected. In general, the information on the front page of a patent grant will reflect the chain of related applications as stored in the USPTO’s PALM data base, rather than what the applicant has stated in the disclosure. Consequently, there may be differences between what the applicant states in the disclosure and what appears on the front page of the document. If there is an error, it may be in the statement in the disclosure, or on the front page, so when you report a suspected error, please provide corroborating documentation.
Q
What is the “id” attribute used for?
A
Almost every element has been given an optional attribute of “id”. Some other elements have the optional attribute “id-ref”. These two attributes are exploited by hypertext engines to link two parts of the document instance. That is, clicking on the object with the id-ref attribute takes you to the object with the corresponding value in its id attribute. Any number of id-ref or id-refs can point to the same id. The value of the id has no significance; the only requirement placed upon it is that it must be unique in the document instance. These id and id-ref pairs are placed in the published document to facilitate navigation through the document when it is rendered in a browser window.
Q
Why does the first sentence [of the sample document] begin with id="P-00002" and not id="P-00001"?
A
ID attribute values indicate nothing whatever about the sequence in the document instance of the object to which they are attached. The value of the num attribute, on the other hand, does tell you something about the intended sequence of the object at the time of rendering. For example, the paragraph with num=”2” should come before the paragraph with num=”3”. The table with num=”35” would be somewhere ahead of the table with num=”36”, but not necessarily immediately ahead of it, since there may be intervening paragraphs or other objects.
That paragraph or other ID’s appear to be sequential is an artifact of the technique used to generate them and must not be relied upon for object sequencing. The only reliable feature of ID values is that they are unique in the document instance.
As it happens, the first paragraph in a published application or grant is always the abstract, so, usually, the first paragraph of the description is the second paragraph in the document instance.
Q
Are the two ICE supplemental DTD's (mathml2.dtd and soextblx.dtd) the same as used for Redbook st. 32. xml (calsxml.dtd and mathml.dtd)? If not, can you please provide a correspondence between these DTD's?
A
The DTD’s are substantially the same, but there may be differences of which we are not aware. The USPTO cannot provide any assistance with the use or understanding of these DTD’s. They are industry-standard DTD’s for which abundant information is available in the marketplace. For Red Book documents, MathML markup is generated automatically by Wolfram Research’s Mathematica software, which is used by the data capture contractor to generate the TIFF images included with the instance. The data-capture contractor produces table markup.
Q
It appears that many tags, although included in the DTD, will not be populated for US publications. Can you please provide me with the list of these tags so that I can ignore them?
A
The HTML documentation indicates which elements will not be used or populated by the USPTO. See the links on the Red Book ICE Information page.
Q
What will the valid 'status' values be for the 'live' data in the tag: <us-patent-grant lang="EN" dtd-version="3.0" status="SAMPLE-DATA" id="us-patent- grant" country="US">. For us-patent-application?
A
The Trilateral Offices have agreed not to impose any restrictions on the permitted values of the status attribute, which appears on several elements in several PCT DTD’s.
Q
Can you provide sample records with <us-term-of-grant> data that includes subtags <text> and, <lapse-of-patent>, or, is it the case where these subtags will never be populated for US data?
A
The elements <text> and < lapse-of-patent> will not be populated by the USPTO on a published patent grant.
Q
What is the unit on the <length-of-grant> and <us-term-extension> values? e.g., in the samples below, is it days, month, years, etc.?
A
<length-of-grant> is in years and <us-term-extension> is either "5 years", or the number of days (as an integer) if the extension is less than five years.
Q
I cannot find any samples where the disclaimer date field is populated. Why is this? Can you provide samples?
A
The next round of sample data will include this data, if it is present in any of the documents.
Q
It appears in the sample below that the disclaimer text is incomplete, and the <length-of-grant> or <us-term-extension> value should be appended to the text. How do you know when to do this, and what tag needs appended?
<us-term-of-grant>
<length-of-grant>14</length-of-grant>
<disclaimer>
<date/>
<text>Subject to any disclaimer, the term of this patent is extended or adjusted under 35 U.S.C. 154(b) by </text>
</disclaimer>
</us-term-of-grant>
<us-term-of-grant>
<us-term-extension>98</us-term-extension>
</us-term-of-grant>A
TBD
Q
Can you provide sample records with <classification-ipc> data that includes subtags <additional-info>, <linked-indexing-code-group>, <unlinked-indexing-code> and <text>?
A
No. The USPTO will not populate these elements since our current business practice does not capture any of this data.
Q
Can you provide sample records with <classification-national> data that includes subtags <additional-info>, <linked-indexing-code-group>, <unlinked-indexing-code> and <text>? Or, is it the case where these tags will never be populated for US data?
A
These tags have no meaning within the US Patent Classification; hence, they will not be populated by the USPTO.
Q
The ICE DTD comments say the tag <us-divisional-reissue> corresponds to ST. 32 B631. Shouldn't that be old tag <B641US>?
A
The documentation will be corrected to show that <us-divisional-reissue> is equivalent to B641US.
Q
According to the comments the ICE tags <document-corrected, type-of-correction, text?> correspond to ST 32 tags <B665> and <B667> . Were these two tags used in the Redbook XML data? Are they new? They do not appear in Grant Red Book schema documentation. Can you point me to any examples if they exist?
A
B665 and B667 are in WIPO Standard ST.32. In previous versions of Red Book, these elements were not populated and not in the DTD’s. For documents with a kind code of A9 or B9, the USPTO will populate <document-corrected> and <type-of-correction>.
Q
I do not find equivalent ICE tags for the old tags <B610>, <B645US>, or <B646US>. Have these elements been discontinued by the USPTO? If not, what are the equivalent ICE tags?
A
B610 is equivalent to the element <addition>, which is in the content model of <us-related-documents>.
B645US is equivalent to the element <us-reexamination-reissue-merger>, which is in the content model of <us-related-documents>.
B646US is equivalent to the element <reexamination>, which is in the content model of <us-related-documents>.
Q
What precisely will be contained in <claims-only-available>?
What’s the difference between <unexamined-without-grant> and <unexamined-no-grant> and do these and the others like them represent new content?
A
These elements will not be populated by the USPTO. They represent publishing practice for PCT applications.
Q
What is <electronic-signature>? A
This element is used to capture an electronic equivalent to a hand-written signature when filing an application on-line or through other electronic means.
Q
What is the difference/significance of the ICE tag <parties> <applicants> <applicant sequence> <designations=”US-only”> <addressbook+> as it relates to what seems to be identical/similar content associated with the ICE tag <inventors (inventor | deceased inventor) +> as described in the DTD? In the examples that I have examined (where the US is designated) I find only the former with "applicant-inventor" type attribute app-type="applicant-inventor" but not the later unless there is a deceased inventor. Would <inventor> only appear in the ICE document when there is a deceased inventor?
In the unfortunate event that there are two sets of legal representatives and associated deceased inventors for a granted patent, is the applicant sequence number (as seen in US06672541) always a reliable link between the "applicant" and the "associated deceased inventor"?
A
Under the PCT, the inventor and applicant might be different persons, and often are. For the US, the applicant is always the inventor, unless the inventor was deceased or otherwise unable to sign the application. For the vast majority of US applications, <applicant> will be populated with the attribute <… app-type=“applicant/inventor” …>. If the inventor was unable to sign, <applicant … app-type=”applicant” …> will be populated with the name of the person who filed on behalf of the inventor, and the <deceased-inventor> element will be populated with the inventor name. The <deceased-inventor> and the corresponding applicant will have the same numeric value in the <… sequence=”n” …> attribute. For the <applicant>, the sequence number represents the order in which the applicants were named on the application; for the <deceased inventor>, the sequence number indicates the applicant acting on behalf of that inventor. The fact that an inventor name appears in the <deceased-inventor> element cannot be taken as evidence of the inventor’s death; it means only that the inventor was unable to sign the application for whatever reason. See also FAQ 50.
Q
“In the legacy Red Book format, the deceased inventor information also includes the name & address of the deceased inventor's legal representative. I do not find this information in the sample document "06587069" that is included in the CD-ROM example set. Has USPTO discontinued this information in the ICE format?
2/4 USPAT - (C) USPTO- image
CPIM Questel-Orbit
AN - 06587069
PN - US6587069 B2 20030701
IN - Ringwald, Rand; Newcastle WA [US]
- Brandao, Ruy L.; Ft. Lauderdale FL [US]
- Brandao, Ruy C.; Redmond WA [US]
- Jones, James B.; Carnation WA [US]
- Pham, Dang [deceased]; late of Issaquah WA [US]; Nguyen, Lien, legal representative <== NOT FOUND IN THE SAMPLE
<applicant sequence="005" app-type="appli
<addressbook lang="EN"> <last-name>Pham</last-name>
<first-name>Dang</first-name>
<address>
<street/>
<city>late of Issaquah</city>
<state>WA</state>
<postcode/>
<country>US</country>
</address>
<inventors>
<deceased-inventor sequence="005">
<last-name>Pham</last-name>
<first-name>Dang</first-name>
</deceased-inventor>
</inventors>”“There is no country provided in the inventor group on ICE. Is it possible to have a country provided for each inventor?”
A
The address for the applicant/inventor, where there is an assignment at time of issue, is merely the inventor’s city and state of residence (or city and country, if outside the US); a full address is given if there is no assignment. In the case where the applicant is acting on behalf of a so-called deceased inventor, at least the residence of the inventor will be provided in a new element <us-bibliographic-data-grant>/<us-deceased-inventor>/<addressbook>. Note that <us-deceased-inventor> has a sequence attribute that associates it with the corresponding inventor contained in the <deceased-inventor> element of <parties> (there might be more than one). Some care was taken not to modify the <parties> element to include this information since it is widely used in PCT AI Part 7 Annex F DTD’s and by the Trilateral Offices.
Q
What are the ICE equivalents for the Redbook XML citation (B561) sub-elements for inventor name, US (or IPC) classification code and cited-by-examiner indicator? I do not find them in the DTD and this content is missing from the sample documents, see USH0002074 below. Will this content be discontinued after January 1, 2004?
In at least several cases, the new feed has "country" and "patent citation number" as extra data but is missing the "name" and the "national classification of citation" data.
A
The DTD’s have been modified to accommodate classification information within cited patent references. The international common element for <citation> now includes elements for national, IPC, and IPC-R classifications, so the US-specific elements are no longer needed as of 2004 October.
Q
What is the valid data content that may be found in the sub element <category>? Is this where "cited-by-examiner" or "cited-by-whomever" is going to go?
A
Yes, the USPTO will use this element to indicate that the documents were cited by the examiner, or cited by others.
Q
Can we please have a composite list of all previous data content elements that will be discontinued in the new format?
A
It is our intention that all of the data published in the current RB files will also be published in the RB ICE files. If you suspect that we have not succeeded, please provide an example of the old content, the element(s) it was contained in, and the document number.
Q
Can you point me to sample data that includes examples of the <references-cited> sub elements <date-search-completed?>, <date-search-mailed?>, <place-of-search>, <search-report-publication?> and <searcher?> Do these sub-elements have equivalents in the Redbook xml DTD?
A
In us-references-cited, these elements are not populated at the present time.
Q
What is sub-element "<utility-model-basis> (<B670>)?
A
The element cites the document on which a utility model is based. This element will not be populated by the USPTO. Documentation for the DTDs to the contrary will be corrected.
Q
What are elements <abst-problem> and <abst-solution (p+) ?
A
These are suggested section headings from the PCT Administrative Instructions. They will not be populated by the USPTO.
Q
There is reference to a gene sequence DTD. Where is it?
A
The DTD has now been published at Sequence Listing DTD for Red Book ICE.
Q
The sample data contained missing headings, such as brief description.
A
See also FAQ 1. All the information is present, but titles, such as brief description, will be in a <heading> element.
Q
In at least several cases, the new feed has "PARA ID" and text content missing from the claims data.
A
In RB ICE, paragraphs are not used in claims. Instead, the element < claim-text> is used, since the content model for claims is slightly, but importantly, different from a paragraph. <claim-text> is nested to indicate the logical relationship of claim steps, where present. The ID attribute is still present, but the element name PARA is no longer present.
Q
The address book has the option that the data can split out the individual elements of a name or address, or the inventor name and address can be put together in a free text format. This is also true of the assignee name and address and correspondence (attorney) name and address. Can the number of records that use the text or name element be kept as low as possible?
There is an option in the DTD to supply all the biblio data as a text string i.e not separating out the individual elements. This is a catch all and would require manual intervention to put the data in the correct fields. We need the number of documents that use the option to be a minimum (ideally none of the records) Can you please comment on this?
A
In fact, the USPTO will always publish patent grants and patent applications with all names and addresses and all other bibliographic information fully structured, with one exception. We will not use the unstructured text option for publishing, nor will we permit electronic applications to use this option. It is present primarily to accommodate legacy data from other industrial property offices. The one exception is for citations of non-patent literature, where the <othercit> element in <nplcit> is used, rather than the structured elements <article>, <book>, or <online>. The cost of CORRECTLY populating those structures exceeds the value that would be gained.
Q
How is the person who initiated a reexamination request identified in ICE? A
Continuity data (<us-related-documents>) <reexamination> markup in ICE does not identify who requested the reexamination.
Q
I am having difficulty interpreting the information in the tag <Legal-Representative> [<agent> in ICE]. On the Patent Office site, one patent (PP14502) has the legal representative listed as one of the inventors, but another patent (PP14505) does NOT. The XML file shows essentially the same information for the two patents. Can you please clarify this point for me -- Is the legal representative supposed to be included in the list of inventors or not?
A
For the documents you cite, the information may have been captured incorrectly in one or the other case. In general, an applicant who was not the inventor is tagged as an <applicant> with the attribute “app-type = applicant”, while the (incapacitated or deceased) inventor is tagged as a <deceased-inventor>, using a shared sequence attribute value to link the two together. The normal case for US applications is that the applicant is (in fact, must be) the inventor and is tagged as an <applicant> with the attribute “app-type = applicant-inventor”. See also FAQ 37.
Q
Some character entities in Red Book seem to be missing in ICE.
A
34 entity characters are now mapped to ASCII characters in ICE.
ST32 ENTITY ASCII Character
DiacriticalGrave `
hat ^
tab (\t)
apos '
ast *
bsol \
colon :
comma ,
commat @
dollar $
equals =
excl !
grave `
jmath j
lbrace {
lbrack [
lcub {
lowbar _
lpar (
lsqb [
midast *
num #
percnt %
period .
plus +
quest ?
quot "
rbrace }
rbrack ]
rcub }
rpar )
rsqb ]
semi ;
sol /
Q
What is the equivalent of <PSTA> in ICE?
A
<parent-status> Please report documents where you believe this element has been erroneously omitted.
Q
The ICE dtd V 3.0 dated 2003-12-08 draws an equivalence between INID 65, ST32 B650 and <related-publication>. The Schema also dated 2003-12-08 draws an equivalence between INID 65, ST32 B690US and <related-publication>. Which is correct?
A
Both are correct. Both types of prior publication are placed in <related-publication>.
Q
In the actual Red Book XML format for US06672162 issued Jan. 6, 2004 the related pct application number PCTJP00/00543 was delivered attached to the element B650. According to the ICE dtd comments, B650 should correspond directly to <related-publication>. So I was not expecting to find PCTJP00/00543 in the <division> element which corresponds to B620 in the legacy version. As we have slightly different post processing treatments for B620 (divisionals) & B650 (relateds), can you please tell me which is in error? The legacy version? or the ICE format version? If both are correct (!) can you please provide LOTS of extremely detailed clarification about the contents of those two ICE elements and how they do *not* directly correspond to B620 & B650.
A
In GRB v2.5, <B650> is part of the <PARENT-US> content model, and nowhere else. Consequently, it appears subordinate to <B610>, <B620>, and several others. In the case you cite, PCTJP00/00543 is “related” to a parent of 6,672,162, and should have been mapped to <parent-pct-document> within <parent-doc> of <relation> subordinate to <division>, since 6,672,162 is a division of the parent. If it had been a prior publication of 6,672,162, it would be properly mapped to <related-publication>. A correction to the program logic will be investigated and this Q/A will then be revised.
Q
Why use the following processing instructions? (examples from ipg040316.zip)
<?img id="EMI-00001" he="392.68mm" wi="287.10mm" file="US06705336-20040316-P00001.TIF" alt="embedded image" img-content="drawing" img-format="tif" ?>
<?img id="CUSTOM-CHARACTER-00009" he="3.13mm" wi="2.79mm" file="US06705247-20040316-P00001.TIF" alt="custom character" img-content="character" img-format="tif" ?>
When the element 'img' exists and is being used. (example from ipg040316.zip)
<img id="EMI-D00001" he="218.12mm" wi="172.47mm" file="US06705336-20040316-D00001.TIF" alt="embedded image" img-content="drawing" img-format="tif"/>
A
In some content models in the RB DTDs, the <img> element is not permitted. If an applicant uses an unknown character or places an image in those content models, we use processing instructions as a workaround. The Red Book Viewer has been modified to render images included via processing instructions. For more details about processing instructions, see question 1 above.
Q
From reviewing the documentation, it seems that <orgname> and <role> may be used directly by <assignee> or by <assignee>.<addressbook>. Is it possible for USPTO to change the use of <assignee> or <assignee>.<addressbook> so that one or the other choice is applied consistently to the sub elements <orgname> and <role>?
A
The content model of <assignee> permits either a structured name, or <addressbook>, which also includes a structured name. Consequently, <orgname> and <role> might be direct children of <assignee> or indirect children through <addressbook>. There is no policy we could put in place that would eliminate one or the other alternative. Therefore, you should be prepared to process both cases.
Q
In previous changes to the ICE DTD, an element <us-cited-patents><us-classification> was added that contained classification codes for cited patents. These class codes can either be US classification or International classification. In the legacy format, this data was delivered in the elements PNC and PIC respectively. As our treatment and output of these two types of classification are quite different, can you please tell me how to differentiate between the two when processing the ICE format?
A
In the v4.0 of Patent Grant Red Book and Patent Application Red Book, the content model of <references-cited> has been changed substantially and now includes <classification-national> and <classification-ipc>, to distinguish the two types of classifications.
Q
In our ongoing tests comparing our program outputs from the legacy and ICE formats we have discovered that the unstructured field of search data found in B583US in the legacy format is missing from the ICE format <field-of-search> element.
In continuing our parallel ICE tests from issue November 9, 2004, we have found that 48 documents in that issue are missing field of search information. We take this information from <field-of-search><main-classification>with <additional-info> for output to our field FLD. The data is present in the legacy format for issue November 9, 2004.
A
When the only field-of-search data consisted of a range of classifications (B583US), it was systematically ignored due to a conversion error. The problem has now been corrected.
Q
“We have a major issue to resolve. The paragraph tagging in the new XML doesn't allow us to determine if data is in fact a new paragraph or just an indentation of the current paragraph. Since BRS is limited in the number of paragraphs (storage units) permitted for one document, we will be rejecting many more documents than we have in the past unless the data provides us a means to identify indented text as belonging to a single logical paragraph versus the start of another logical paragraph.”
“In ICE, I see no provision for marking up structured "hanging paragraphs" in the DTD anywhere in the patent specification, other than the claims. For example: US 6,729,366 B2, issued May 4, 2004, to Tanaka et al., assignors to Toyo Jidoki Co., Ltd., paragraph ID's P-00017 to P-00031, which, in the printed patent, begin at the bottom of column 2 of the specification. In Red Book, the LVL attribute of the PARA element tells me how to format the paragraphs. I see no special mark-up in the ICE version of this patent that would allow me to type-set this series of paragraphs utilizing the appropriate hanging paragraph style. This very obvious markup requirement of patent documents of the U.S., EPO, WIPO, and so on, cannot have been overlooked. Can you please explain what is SUPPOSED to happen here, so that I may write some software to meet the obstacles set by the new format? I found 1974 out of 3770 patents issued on May 4, 2004 are affected by this defect (over 52% of the issue).”
“Will the ICE DTD change due to the recent developments regarding nesting of claims and processing of paragraphs, and if so, when is a new DTD version expected to publish? Will the ICE format for past publications from March 16th, 2004-present be re-created with the fix for the nesting of claims and processing of paragraphs?”
“Published Applications now have paragraph numbers enclosed in brackets for all the paragraphs in the main body of the Application. Examining the week of December 2, 2004 Red Book ICE for Applications, we note that somewhat more than 8,000 of these paragraph numbers are completely missing. That a data loss of this magnitude can occur gives us concern that the quality assurance and pre-release testing at USPTO has serious inadequacies.”
A
In previous versions of Red Book, this information was encoded in the LVL attribute of the PARA element. In ICE, the <p> element has no such attribute. Consequently, with the introduction of Patent Application Red Book and Patent Grant Red Book v4.0, paragraphs that are broken into multiple lines (for whatever reason), will be treated as unordered lists rather than as a series of paragraphs. In some cases, the <br> element may be used to produce a visual separation of content at rendering while preserving paragraph boundaries. This represents a significant change in the manner in which the data is captured by our contractor, even though no DTD changes are required. It is not possible to reissue test data distributed prior to implementing the solution, because the data was not captured in a manner that can be reliably interpreted by machine for this purpose. There may be some unexpected results from the way in which the solution is implemented. Please be patient with us and report any problems you encounter. This table is a description of the logic followed in translating paragraph levels into unordered lists. Please send your comments or questions to ed.johnson@uspto.gov.
In the decision table, you will note that in some cases a complex work unit, such as a chemical equation, is followed by a <br> tag rather than initiating a list with one list item. In the ST.32 version of Red Book, such broken sentences are marked with a particular LVL attribute that generates a paragraph number in Application Yellow Book (facsimile images of published applications). The <br> element has no num attribute in which to store the corresponding paragraph number. Consequently, the paragraph number that appears in Yellow Book is skipped in ICE; nevertheless, no content is lost.
In some cases, implementation of lists to encode sub-paragraphs results in a list tag with a num attribute that is repeated in the first subordinate list item that does have content. This is done to preserve the correspondence of paragraph numbers in ICE with those in Yellow Book. Elements with no content that have a num attribute should be suppressed at rendering, as does the Red Book Viewer.
We have interpreted a sentence interrupted by a complex work unit as a single paragraph with no sub-paragraphs. Where there are multiple indented sub-paragraphs, we have used lists and numbered the list items to support navigation through the document and easy reference to what can be a very long paragraph. These policies are not without their drawbacks. Suggestions that would improve on them without requiring any modification to the DTD are welcome.
Q
Are the following valid entity values?
𝒥
𝔍
If so, what is the ASCII translation? They show up a lot in the ICE XML. I thought UNICODE hex values were two bytes (4 chars). Can you please explain?
A
The two character entities have the following explanation. As you can see, there is only an approximate value available in ASCII.
The number of bytes in the encoding varies with the encoding used. The UTF-8 encoding that we use can have anywhere from one to six bytes per character. The number of characters in the character entity (&#...) that appears in the instance when you view it in a text editor tells you nothing about the number of bytes in the encoding, since different encodings are available for the same character entity.
Q
Instead of using appropriate character references, you are frequently using a kind of undeclared notation involving curly braces. For example, instead of utilizing '½' or '½ or '½' ICE has the phrase '{fraction (1/2)}.' In (Old) Red Book, when there was a REAL curly brace in the text, a character reference was used, such as '{' or '}', and so, software could simply replace this undocumented, non-XML markup, and replace it with character references or appropriate XML markup before proceeding. This is also done whenever the character '^' occurs in a patent; instead of writing '^', ICE writes the phrase '{circumflex over ( )}'.
Especially in chemical patents, which often embed the character '{' in a chemical name, this can be extremely confusing for software.
A
Those of you accustomed to the now deceased Green Book format will recognize {fraction (1/2)} as a left-over pre-standards method for preserving content that would otherwise be completely lost in the text file. We have attempted to replace this practice with true Unicode characters wherever possible, but there may be omissions. When you find them, let us know and we will tighten the processing to overcome the problem. Until such time as the data is captured from the start in Unicode, however, you may from time to time find examples of this obsolete (but indispensable in its day) technology.
Q
We are well on the way to finalising our programs for switching to ICE, but a question has just come up from the team. Generally, the formats for Applications and Grants look the same (so we can use one program instead of two), but there is a difference in how classifications are reported. For example:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE us-patent-application SYSTEM "us-patent-application-v20-2004-03-04.dtd
<classification-ipc>
<edition>07</edition>
<main-classification>E03D009/08</main-classification>
</classification-ipc>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE us-patent-grant SYSTEM "us-patent-grant-v30-2004-03-04.dtd" [ ]>
<classification-ipc>
<edition>7</edition>
<main-classification>A61G 7008</main-classification>
<further-classification>A61G 7005</further-classification>
<further-classification>A61G 1500</further-classification>
<further-classification>A61G 1304</further-classification>
<further-classification>A61G 1306</further-classification>
</classification-ipc>You can see that in the application we have something like E03D00908 whilst in the grant it is A61G 7008. Is this difference in formats intentional and will it continue like this?
A
The difference in format is an historical artifact, which we have corrected. You should now see the same format in Patent Application Red Book and Patent Grant Red Book for international classifications.
Q
I've noticed that, on the ICE formats, the exemplary claim numbers are sometimes missing. I always thought that all patents need at least 1 such claim. Should I assume that in all these cases, the exemplary claim is simply the first claim?
A
Yes, there is always an exemplary claim, otherwise known as the "O.G. Print Claim." The examiner selects it—or them, since there can be more than one. If the examiner fails to select a print claim, the data capture contractor is instructed to treat Claim 1 as the print claim. Regardless, the exemplary claim number should always be present in the XML, and we have corrected the problem.
Q
When rendering Red Book documents in MS Internet Explorer, some users get this message, and others do not. What is the cause of this error message, and what can be done to correct it?
A
Red Book DTDs incorporate the MathML DTD by reference. MathML makes use of a namespace declaration that some versions of Microsoft’s MSXML parser object to (MSXML v3sp4, and later). Prior to MS Windows XP sp2, it was possible to overcome the problem by ensuring that MSXML v3sp3 or earlier was being used. With Windows XP sp2, that is no longer possible since MSXML is now in the core of the OS and cannot be replaced by an older version. To avoid the error, it is necessary to include in the Red Book DTDs an entity declaration that overrides an entity declaration that is in the MathML DTD. All the DTDs in the current release of the Red Book Viewer have been so modified. If you wish to modify the Red Book DTDs yourself, do the following:
Replace <!ENTITY % MATHML.xmlns "">
With <!ENTITY % MATHML.xmlns.attrib "">
Q
“Where have non-patent literature citations gone?”
“Red Book ICE does not provide adequate markup of citations in Other References. We do not see Italics, Boldface, Superscript, Subscript, etc -- they are all missing.”
A
Beginning with the parallel run (October 12, 2004, issue), non-patent literature citations will be placed in <bibliographic-data>/<references-cited>/<citation>/<nplcit>/<othercit>. Previously, such citations were placed in <bibliographic-data>/<references-cited>/<cited-others>/<nplcit>/<text> and later in <bibliographic-data>/<references-cited>/<citation>/<nplcit>/<text>. <othercit> now permits highlighting of text consistent with past US practice in rendering citations.
Before the DTD was changed to permit highlighting in <othercit>, highlighting was stripped before populating the element. Unfortunately, when highlighting was permitted, the code to strip the highlighting was not turned off. As of this writing, that code has been turned off, so you will see the customary highlighting starting with the December 14, 2004, issue. See also FAQ 13.
Q
If the USPTO permanently adopts the policy of using the PCT filing date in the <application-reference><date> element, then can you
please create a separate <application-reference><371-date> element for the actual (if not legal) US application filing date?
A
The date on which a PCT application enters the national stage at the USPTO is not the filing date of the application; the filing date is the date on which the PCT application was first filed. Consequently, <application-reference>/<date> shows the filing date of the PCT application, not the date on which it entered the national stage at the USPTO. For patent grant publications, the date that the application entered the national stage is contained in <us-bibliographic-data-grant>/<pct-or-regional-filing-data>/<us-371c124-date>. For patent application publications, the <us-371c124-date> element is not populated, since there is no legal need for it at the time the application is published.
Q
Effective with issue November 30, 2004, ST32 Red Book is populating the B680US status information in the dtxt field of the doc element as shown below:
<B680US>
<DOC>
<DNUM><PDAT>60/423232</PDAT></DNUM>
<DATE><PDAT>20021101</PDAT></DATE>
<KIND><PDAT>00</PDAT></KIND>
<DTXT><STEXT><PDAT>abandoned</PDAT></STEXT></DTXT>
</DOC>
</B680US>However the corresponding ICE element <us-provisional-application> only has a content model of <document-id> (country , doc-number , kind? , name? , date?), which does not include a status or descriptive text field.
A
Red Book DTD’s have been updated to include a new element <us-provisional-application-status> for this purpose.
Q
We find that the Field of Search element is sporadically missing from Red Book ICE. We can't seem to find any pattern to this failure. For example, US Patent 6820562 in the issue of November 23, 2004, is missing its field of search. There are at least 50 other instances in the same week.
A
In those cases where the only field of search information was a range of classifications, the data was in B863US instead of B581 or B582, and was therefore missed in the conversion to ICE. That has been corrected as of the December 14, 2004, issue.
Q
In about 134 of the docs from the November 11, 2004, issue delivered in the parallel ICE format version I find the description of the drawings to be appended to the <summary of the invention description> data element, sometimes with or some times without a "separator" tag <?summary-of-invention description = "Summary of Invention" end = "tail"?> , and not in the <brief description of the drawings> data element as expected. Can you please ask your technical guys to investigate and make any corrections that they deem appropriate? See US 20040221253 and US20040222256 as examples. If no corrections seem indicated to your guys, can you please give me some hints on how I can reliably identify & extract out this data from the <summary of...> element, e.g. is the heading always the same or can that vary?
A
Regrettably, indication of the subdocument describing drawings in Application Red Book uses processing instructions (see FAQ 1), while Grant Red Book has been using the ICE tag <description-of-drawings>. In the case of applications, errors can occur in the conversion to ICE. Grant Red Book will be revised to include a processing instruction for the description of drawings while preserving the use of <description-of-drawings> until further notice. At some future date Application Red Book and/or Grant Red Book will be revised again to ensure that the same method of marking the drawing description subdocument is used in both cases. Comments on the preferred method are welcome. Send to Ed Johnson .
Q
I see the October 28, 2004, revision of the DTDs is available but as of today, both grants and applications are still referencing September 27, 2004. What's up?
A
The revision date of a DTD does not correspond to its introduction into production. Once revised, it is sent to the contractor with whom we then negotiate an implementation date. The implementation date is always at least two weeks in the future, since the contractor processes data in advance of the issue date, and there may be other factors requiring additional ramp-up time.
Q
[What are the ST.36 equivalents of the following elements in Red Book?]
us-chemistry
us-math
us-sir-flag
us-application-series-code
us-issued-on-continued-prosecution-application
rule-47-flag
us-botanic
us-exemplary-claim
us-microform-quantity
us-term-extension
latin-name
variety
us-divisional-reissue
us-reexamination-reissue-merger
us-provisional-application
us-publication-of-continued-prosecution-application
us-appendix-data
object-reference
object-description
object-id
object-contents
us-publication-filing-type
us-original-publication-voluntary
us-original-publication-redacted
us-original-publication-amended
us-republication-corrected
us-republication-redacted
us-republication-amendedA
ST.36 describes a method for creating office-specific elements where there is no equivalent in ST.36 that supports the needs of the office. All the elements in this list fall into that category. Unfortunately, several of them lack the “us-” prefix that the standard calls for. This is an oversight that will be corrected at some future date.
Q
I need to get the patents-cited and the non-patent-literature-cited. It seems I can get this in three possible ways:
... <references-cited> <citation> <patcit>
... <references-cited> <citation> <nplcit>
... <references-cited> <citation> <corresponding-docs> <nplcit>
A
The USPTO does not populate <corresponding-docs>, so you need not look there, only in the other two. The element <corresponding-docs> has significance for search reports under the PCT, which shares the element <citation>.
Q How has the International Patent Classification in both applications and grants changed as of February 8, 2005? A The appearance of the International Patent Classification (IPC) in the Patent Grant Data/XML v4.0 (ICE) beginning February 8, 2005, and in the Patent Application Data/XML v4.0 (ICE) beginning February 10, 2005 changes as follows:
-Position 1 - Section - 1-character alphabetic (uppercase)
-Position 2-3 - Class - 2-character numeric
-Position 4 - Subclass - 1-character alphabetic (uppercase)
-Position 5-7 - Group - 3-character numeric, right justified with leading zeros.
-Position 8 - 1-character containing a constant of a forward slash "/".
-Position 9-13 - Subgroup - 2 to 5 characters numeric with an implied decimal point following the second position. A minimum of 2 positions is required with a leading zero if necessary.
The appearance of the International Patent Classification (IPC) prior to February 8, 2005.
-Position 1 - Section - 1-character alphabetic
(uppercase)
-Position 2-3 - Class - 2-character numeric
-Position 4 - Subclass - 1-character alphabetic
(uppercase)
-Position 5-7 - Group - 3-character numeric, right justified with leading spaces .
-Position 8 -14 - Subgroup - A maximun of 7 alphanumeric characters
March 18, 200574 Q What DTD changes to Red Book are planned for January 2006? A Please Note: This replaces the FAQ 74 contents dated June 10, 2005.
January 2006 DTD Changes
The following changes to Red Book are planned for the first week of 2006.
Changes for both Application Red Book and Grant Red Book:
Legend of Near and Fear Designer Symbols:
Connectors
Ordered connector-----Specifies that the attached sibling objects must occur in sequence within a document instance.
Selection Connector-----Specifies that one (and only one) of the attached sibling objects is to appear within a document instance.
Occurrence Indicators
One (occurrence indicator)-----The object is required; there must be one (and only one) occurrence of the object at this point in a document instance.
Zero or one (occurrence indicator)-----The object is optional, but if present, can appear only once.
One or more (occurrence indicator)-----The object must appear at least once and could appear any number of times. Drag this icon to an object in the tree to change its occurrence type.
Zero or more (occurrence indicator)-----The object may be omitted or may occur any number of times at this point in a document instance.
Terminals
Processable Character Data, or PCDATA
No Content, EMPTY
Tilde-----Indicates that the element has associated attributes.
Indicates that the content model is the same as a previous element.
a. Remove classification-ipc element from us-patent-bibliographic-data. The USPTO will cease publishing IPC on patent grants with the last issue of 2005 and will publish only IPC Reform classifications as of 2006 January.
Reformed IPCs for Red Book ICE (Patent Applications and Patent Grants) on or after January 2006:
<ipc-version-indicator><date>
-8-position numeric date in the format YYYYMMDD.
<classification-level>
-1-position alphabetic (uppercase) containing a constant “A” defining “advanced level”.
<section>
-1-position alphabetic (uppercase) – possible value can be “A through H”.
<class>
-2-position numeric.
<subclass>
-1-position alphabetic (uppercase) – possible value can be “A through Z”.
<main-group>
-2 to 4 positions numeric.
<subgroup>
-2 to 6 positions numeric.
<symbol-position>
-1-position alphabetic (uppercase) – will contain “F” defining “first” for the sole or first “invention information” IPC, and will contain “L” defining “later” for any second and succeeding “invention information” IPC and for any “non-invention information” IPC.
<classification-value>
-1-position alphabetic (uppercase) – will contain “I” defining “invention information” or will contain “N” defining “non-invention information”.<action-date><date>
-8-position numeric date in the format YYYYMMDD. This date will be the date of publication for patent applications and the issue date for patent grants.
<generating-office>
-2-position alphabetic (uppercase) – United States documents will contain “US”.
<classification-status>
-1-position alphabetic (uppercase) – will contain “B” defining “Basic or Original”.<classification-data-source>
-1-position alphabetic (uppercase) – will contain “H” defining “Human-Generated”.
A future source can be “M” defining “Machine-Generated” and “G” defining
“Generated via Software”.EXAMPLE of Reformed IPCs for Red Book ICE (Patent Applications and Patent Grants) on or after January 2006:
<classifications-ipcr>
<classification-ipcr>
<ipc-version-indicator>
<date>20060101</date>
</ipc-version-indicator>
<classification-level>A</classification-level>
<section>B</section>
<class>28</class>
<subclass>B</subclass>
<main-group>5</main-group>
<subgroup>00</subgroup>
<symbol-position>F</symbol-position>
<classification-value>I</classification-value>
<action-date>
<date>YYYYMMDD</date>
NOTE: The action date will be the date of publication for patent applications and the issue date for patent grants.
</action-date>
<generating-office>
<country>US</country>
</generating-office>
<classification-status>B</classification-status>
<classification-data-source>H</classification-data-source>
</classification-ipcr>
<classification-ipcr>
<ipc-version-indicator>
<date>20070401</date>
</ipc-version-indicator>
<classification-level>A</classification-level>
<section>B</section>
<class>28</class>
<subclass>B</subclass>
<main-group>1</main-group>
<subgroup>29</subgroup>
<symbol-position>L</symbol-position>
<classification-value>I</classification-value>
<action-date>
<date>YYYYDDMM</date>
NOTE: The action date will be the date of publication for patent applications and the issue date for patent grants. </action-date>
<generating-office>
<country>US</country>
</generating-office>
<classification-status>B</classification-status>
<classification-data-source>H</classification-data-source>
</classification-ipcr>
</classifications-ipcr>Reformed IPCs for the us-field-of-classification-search element in Grant Red Book ICE on or after January 2006:
Please Note:
The <us-field-of-classification-search> element will always be present.
----- If the examiner did do a classification search, the element will contain one or more <classification-national> records and/or one <us-classifications-ipcr> record.
----- If the examiner did not do a classification search, the element will contain a single <classification-national> record in which the content of the <main-classification> will be "None."A single <us-classifications-ipcr> record will be present for all of the IPCs in the Grant Red Book ICE <us-field-of-classification-search> element in a U.S. Patent or SIR issuing on or after January 3, 2006.
Please Note: This element requires the need for a content that permits ranges of IPCR classifications as recorded by the patent examiner. Thus <us-classifications-ipcr> has unstructured content, as does the <main-classification> of <classification-national>.
The <us-classifications-ipcr> Grant Red Book content will reflect the format present in the Patent Grant Yellow Book/IPC Field of Classification Search:
*In the <us-classifications-ipcr> record there will be a space between the subclass and the main group. Example: G06K 15/00
*The main group will not contain leading zeros.
*The subgroup will show a minimum of two digits.
*No trailing zero will be present as the 3rd, 4th, 5th, or 6th digit of the subgroup.
*In an IPC range the separator will be a hyphen, and the IPC main group will be repeated after the hyphen. Example: G06K 15/10-15/40
*If multiple IPCs are present, a semicolon and space will be present between IPCs. Example: G06K 15/00; B25C 1/14; G06K 15/10-15/40
EXAMPLE of Reformed IPC in Field of Search in Grant Red Book ICE for patents granted on or after January 3, 2006:
<us-field-of-classification-search>
<us-classification-ipcr>G06K 15/00; B25C 1/14; G06K 15/10-15/40
</us-classification-ipcr>
<classification-national>
<country>US</country>
<main-classification->24/326</main-classification>
</classification-national>
</us-field-of-classification-search>b. Add a new element us-field-of-classification-search. This new element reflects the need for a content model that permits ranges of IPCR classifications as recorded by the examiner. Thus us-classifications-ipcr has unstructured content, as does main-classification of classification-national.
c. Add a new element to the content model for Red Book to make a place for the claim lead-in text. At present, there is no place in Red Book ICE to capture “What I claim is:” and similar text. In patent grants, the text provided by the applicant is used, or a standard heading is used when the applicant does not provide any text. In patent applications, the text provided by the applicant is used, if any, otherwise nothing is provided. Therefore, this element is required in Grant Red Book and optional in Application Red Book.
d. Add two elements that support the US use of a table to display a URL reference to its electronic publishing site for sequence listings and other mega content (PSIPS). The current content models permit only #PCDATA.
e. Add optional id attribute to table entry in the OASIS/CALS table DTD. This is accomplished in the Red Book DTD through an ENTITY declaration. This ID attribute on a table cell will permit the use of the <crossref> element within a cell to reference another cell, which will restore table footnotes.
<!--override OASIS Exchange <entry> model -->
<!ENTITY % tbl.entry.mdl "(#PCDATA | b | i | u | sup | sub | smallcaps | br
| patcit | nplcit | bio-deposit | crossref | figref | img
| dl | ul | ol | chemistry | maths)* ">
<!ENTITY % tbl.entry.att id ID #IMPLIED>f. The USPTO has created a nationalized version of the WIPO Standard ST.36 table-external DTD to accommodate the practice of publishing supplementary files for both chemistry and mathematics. The change to the DTD permits these additional external entities where a large external table includes chemistry or mathematics in its cells.
g. Change comment on <us-divisional-reissue> to correct INID code from B631 to B641US.
h. Change comment on <us-371c124-date> to read “PCT Section 371(c)(1)(2)(4) date. ST.32 equivalency = B864US”.
Changes for Application Red Book only:
i. Make <us-publication-filing-type> optional. These filing types do not apply to applications which have merely aged to 18 months, at which time they are published. The filing types apply only to applications filed expressly for the purpose of publication. Consequently, for applications that have not been so filed, the element will not be present, where in the past, the default value of “voluntary” was used incorrectly.
September 16, 2005
75 Q MathML contains invalid line end characters in Red Book (Patent Grants and Patent Applications) A The data capture environment was not able to eliminate private use characters within the Red Book Grant Issue of August 16, 2005 and the Red Book Application issue of August 18, 2005 20050818 as scheduled .
The proposal to retain the original entity form assuming that the entity was defined within the entity files included within the ICE DTDs.Below is a summary of the private use characters detected in the target Application and Grant deliveries:
Application Week 20050818 Private Use/Problem Character Summary ICE Markup Original MathML Form Comments  &AutoLeftMatch; In the MathML entities but not in the ICE MathML2 entities.  &AutoRightMatch; In the MathML entities but not in the ICE MathML2 entities.  &LeftBracketingBar; In the MathML entities but not in the ICE MathML2 entities.  &LeftDoubleBracketingBar; In the MathML entities but not in the ICE MathML2 entities.  &RightBracketingBar; In the MathML entities but not in the ICE MathML2 entities.  &RightDoubleBracketingBar; In the MathML entities but not in the ICE MathML2 entities.  &IndentingNewLine; In the MathML entities but not in the ICE MathML2 entities.   "Stigma" character that can be associated with ϛ Carriage Return 
 Could retain the 
 entity
Grant Issue 20050816 Private Use/Problem Character Summary ICE Markup Original MathML Form Comments  &AutoLeftMatch; In the MathML entities but not in the ICE MathML2 entities.  &AutoRightMatch; In the MathML entities but not in the ICE MathML2 entities.  &LeftBracketingBar; In the MathML entities but not in the ICE MathML2 entities.  &LeftDoubleBracketingBar; In the MathML entities but not in the ICE MathML2 entities.  &RightBracketingBar; In the MathML entities but not in the ICE MathML2 entities.  &RightDoubleBracketingBar; In the MathML entities but not in the ICE MathML2 entities.  &IndentingNewLine; In the MathML entities but not in the ICE MathML2 entities.  &LeftSkeleton; In the MathML entities but not in the ICE MathML2 entities. Carriage Return 
 Could retain the 
 entity A conversation has been initiated with Wolfram Research on addressing the private use character problems within the MathML data exported from Mathematica.
August 12, 2005
76 Q What is the USPTO Data Products Price Schedule for Calendar Year 2006? A Here is the 2006 Calendar Year USPTO Data Products Price Schedule.
September 16, 2005
77 Q Why do the paragraph numbers in the Patent Application Data/XML (a.k.a. Red Book) not always match the paragraph numbers in the Patents Application Image/TIFF (a.k.a. Yellow Book)? A Background:
The discrepancy began with the implementation of paragraph lists into Patent Application Data/XML (Red Book ICE ST. 36).
Resolution:
Beginning January 2006, paragraph numbering between Patent Application Data/XML (Red Book) and Patent Application Image/TIFF (Yellow Book) were synchronized.
Note: This resolution was not included in retrospective data files prior to January 2006.
January 23, 2007
78 Q What is v4.2 ICE and what is changing? A Patent Grant Data/XML v4.2 ICE and Patent Application Data/XML v4.2 ICE
Beginning Thursday, February 1, 2007 there will be an 8 week parallel process (February 1, 2007 through March 29, 2007) for both patent grants and patent published applications.
This parallel process will include the new Red Book ICE DTD version 4.2 and the current production Red Book ICE DTD version 4.1. The weekly output from the new Red Book ICE DTD version 4.2 process will be created the day after the issue date of the production process (Red Book ICE DTD version 4.1) and be disseminated on DVD-ROM via FedEx.
In both Patent Grants and Patent Published Applications, the changes are limited to:
1). The Red Book ICE dtd file name has changed and the version date has changed as noted below:
Patent Grants:
<!DOCTYPE us-patent-grant SYSTEM " us-patent-grant-v42-2006-08-23.dtd " [ ]>
<us-patent-grant lang="EN" dtd-version=" v4.2 2006-08-23 " file="US07137000-20061114.XML" status="PRODUCTION" id="us-patent-grant" country="US" date-produced="yyyymmdd" date-publ="yyyymmdd">Patent Published Applications:
<!DOCTYPE us-patent-application SYSTEM " us-patent-application-v42-2006-08-23.dtd " [ ]>
<us-patent-application lang="EN" dtd-version=" v4.2 2006-08-23 " file="US20060260000A1-20061116.XML" status="PRODUCTION" id="us-patent-application" country="US" date-produced="yyyymmdd" date-publ="yyyymmdd">2). Red Book ICE elements sub (subscript) and sup (superscript) have been added to elements b (bold), i (italic), and u (underline). This results in a reduction in markup since the bold/italic/underline tags no longer need to be closed and reopened to activate the superscript/subscript outside of the highlight tags (Note: This change applies to both Patent Grants and Patent Published Applications).
Example in v4.1:
<i>e=v{square root over (a< /i>< sup ><i >2</ i></ sup ><i >+b< /i>< sup ><i >2</ i></ sup ><i >)}/</i>
Example in v4.2:
<i>e=v{square root over (a<sup>2</sup>+b<sup>2</sup>)}/</i>
3). Added new overscore element o to elements b (bold) , i (italic), u (underline), claim-text, crossref, dd (definition description), dt (definition term), figref, heading, invention-title, li (list item), othercit, p (paragraph), smallcaps, sub, sub2, sup, sup2 and us-claim-statement. This replaces the descriptive text markup (Note: This change applies to both Patent Grants and Patent Published Applications).Example in v4.1:
diameter {overscore ( d )} <sub>z </sub>in
Example in v4.2:diameter <o ostyle="single"> d </o> <sub>z </sub>in
4). The non-lengthy sequence listing file naming conventions have been modified to conform to existing naming conventions. Within the Red Book ICE Patent Grants and Patent Published Application zip files non-lengthy sequence listings are included as a 2nd xml file and that file name has changed.
Patent Grants:
Example in v4.1:
US07136759-20061114-SEQLST.XML
Example in 4.2:US07136760-20061114-S00001.XML
Patent Published Application:
Example in v4.1:
US20060254503A1-20061116-SEQLST.XML
Example in v4.2:US20060254503A1-20061116-S00001.XML
5). The lengthy sequence listing file naming conventions have also changed. Lengthy sequence listings are not included within the Red Book ICE Patent Grant and Patent Published Application zip files. Instead there is a placeholder table within the primary xml document that references a USPTO web site to access the lengthy sequence listing data, and the full lengthy sequence listing is included within the weekly delivery supplemental folder. Within the supplemental folder the sequence listing file is no longer a single zip file. Beginning with the Red Book ICE v4.2 a separate folder for the lengthy sequence listing data is created and the data appears as un-compressed text within the folder.
Patent Grants:
Example in v4.1:
20061114-SUPP\UTIL07135\US07135290-20061114-SUPP. ZIP containing file US07135290-20061114- SEQLST.SEQ
Example in v4.2:
20061114-SUPP\UTIL07135\US07135290-20061114-SUPP.ZIP\US07135290-20061114- S00001.TXT
Patent Published Applications:
Example in v4.1:
20061116-SUPP\UTIL0257\US20060257420A1-20061116-SUPP containing file US20060257420A1-20061116- SEQLST.SEQ
Example in v4.2:20061116-SUPP\UTIL0257\US20060257420A1-20061116-SUPP.ZIP containing file US20060257420A1-20061116- S00001.TXT
6). Landscape drawing identification has been added to the image element (img) using attribute orientation. This is not a DTD change - the attribute is now being populated for landscape images in Red Book ICE DTD v4.2 for Patent Grants. This attribute will be populated for Patent Published Applications in the very near future.
Example in v4.1: <img id="EMI-D00007" he="143.09mm" wi="122.26mm" file="US20070006380A1-20070111-D00007.TIF" alt="embedded image" img-content="drawing" img-format="tif"/>
Example in v4.2: <img id="EMI-D00007" he="143.09mm" wi="122.26mm" orientation="landscape" file="US20070006380A1-20070111-D00007.TIF" alt="embedded image" img-content="drawing" img-format="tif"/>
7). In both Red Book ICE for Patent Grants and Patent Published Applications, the open-index/manifest reporting has changed to include a full inventory of the patent grants or patent published applications zip file content, and to include lengthy table data (xml, TIF, and text).
The Red Book ICE DTD version 4.2 for Patent Published Applications will include TIF and text Lengthy Tables beginning in the 1 st calendar quarter of 2007. The Red Book ICE DTD version 4.2 for Patent Grant s will include Lengthy Tables data sometime after the 1 st calendar quarter of 2007, with the exact issue date to be announced. All lengthy table data will be included within the weekly delivery supplemental folder in a format similar to the lengthy sequence listing delivery.
20061116-SUPP
+---DTDS
| DTDS.zip
|
+---UTIL0257
| \---US20060257971A1-20061116-SUPP
| US20060257971A1-20061116-S00001.TXT <-- lengthy sequence listing example
|
\---UTIL0260
+---US20060260017A1-20061116-SUPP
| US20060260017A1-20061116-S00001.TXT <-- lengthy sequence listing example
|
+---US20060260018A1-20061116-SUPP
| \---US20060260018A1-20061116-T00001 <-- lengthy table TIFF example
| US20060260018A1-20061116-T00001-0001.TIF
| US20060260018A1-20061116-T00001-0002.TIF
| ...
| US20060260018A1-20061116-T00001-0220.TIF
| US20060260018A1-20061116-T00001-0221.TIF
|
+---US20060260019A1-20061116-SUPP
| | US20060260019A1-20061116-S00001.TXT <-- lengthy sequence listing example
| |
| +---US20060260019A1-20061116-T00001 <-- lengthy table TIFF example
| | US20060260019A1-20061116-T00001-0001.TIF
| | US20060260019A1-20061116-T00001-0002.TIF
| | ...
| | US20060260019A1-20061116-T00001-0160.TIF
| | US20060260019A1-20061116-T00001-0161.TIF
| |
| \---US20060260019A1-20061116-T00002 <-- lengthy table TIFF example
| US20060260019A1-20061116-T00002-0001.TIF
| US20060260019A1-20061116-T00002-0002.TIF
| ...
| US20060260019A1-20061116-T00002-0073.TIF
| US20060260019A1-20061116-T00002-0074.TIF
|
\---US20060260020A1-20061116-SUPP
US20060260020A1-20061116-S00001.TXT <-- lengthy sequence listing example
US20060260020A1-20061116-T00001.TXT <-- lengthy table CD/text example
US20060260020A1-20061116-T00002.TXT <-- lengthy table CD/text example
...
US20060260020A1-20061116-T00006.TXT <-- lengthy table CD/text example
US20060260020A1-20061116-T00007.TXT <-- lengthy table CD/text exampleGrant Lengthy Sequence listing example:
20061114-SUPP
+---DTDS
| DTDS.zip
|
\---UTIL07135
+---US07135290-20061114-SUPP
| US07135290-20061114-S00001.TXT <-- lengthy sequence listing example
|
+---US07135334-20061114-SUPP
| US07135334-20061114-S00001.TXT <-- lengthy sequence listing example
|
+---US07135549-20061114-SUPP
| US07135549-20061114-S00001.TXT <-- lengthy sequence listing example
|
\---US07135560-20061114-SUPP
US07135560-20061114-S00001.TXT <-- lengthy sequence listing exampleFebruary 1, 2007
Some content linked to on this page may require a plug-in for Office Software Application Viewers and ZIP file Utility.
|
|
|
