JP5143980B2 - Intellectual property protocols that define data exchange rules and formats for general-purpose intellectual property data objects, and systems, methods, and program products related thereto - Google Patents

Description

この方針は、データを使用したアプリケーションがサポートし得る正規化のレベルを有すること、およびデータが本発明者らが供給し得る正規化の最高のレベルを有することを確実にする。
【００５６】
（Ｃ．ＣＰＭＬ ＤＴＤはＩＳＯ規格コードおよびタグに読みやすい慣用の命名方法を使用する）
上記セクション（ｂ）における例に示されるように、可能なかぎり規格が使用される。例えば、「ＵＳ」はアメリカに対するＩＳＯ規格コードであり、「ＣＡ」はカリフォルニアに対するＩＳＯ規格コードである。
【００５７】
タグ用の慣用の命名方法は、比較的読みやすく、且つ長い名前を含むのが好ましい。その名前が占めるディスクスペースは画像の記憶装置と比較すると大したことはない。読みやすい名前を有することは、人間が文書を操作することを可能にする。読みやすい名前はＣＰＭＬ ＤＴＤを第三者に説明することを容易にする。
【００５８】
（Ｄ．ＥＱＶフォーマットはＩＰＡＭサーバにてＣＰＭＬ ＤＴＤと交換され得る）
好ましくは、ＩＰＡＭサーバ１０５はＸＭＬ知的財産文書を電子文書として受け取る。
【００５９】
ＸＭＬ知的財産文書は、特許相当テキストファイルが格納されていたのと同様に格納され、そして特許相当テキストファイルがＩＰＡＭサーバ１０５に配達されたのと同様にＩＰＡＭサーバ１０５に配達される。ＩＰＡＭサーバ１０５に対する変化には次のものが含まれる。
【００６０】
＊ＩＰＡＭサーバ１０５は、ＥＱＶフォーマットに相当するフォーマットとしてＸＭＬを認識しなければならず、そして要求時にはＸＭＬ知的財産文書を返送しなければならない。
【００６１】
＊ＩＰＡＭサーバ１０５は、特定の知的財産文書用ＸＭＬを要求する新しいコマンドを有する。
【００６２】
＊ドメインは、ＥＱＶフォーマットの文書を渡すためのデータパスを有していたのと同様に、ＸＭＬフォーマットの文書を渡すための新たなるデータパスを有する。あるいは、ユーザインターフェースの二重操作の手間を省くために、および注釈下位システムのいくらかの複雑性を省くために、それをＩＰＡＭサーバ１０５のユーザインターフェースに渡す前に、ドメインはＸＭＬフォーマットの文書をＥＱＶフォーマットのファイルに変換し得る。
【００６３】
＊ＩＰＡＭサーバ１０５のユーザインターフェースは、文書を適切に表示する。
【００６４】
＊全注釈下位システムは、画像文書またはＥＱＶ文書よりは、ＸＭＬ文書にて注釈をつけることを取り扱い得る。
【００６５】
本発明は以下のタスクを達成するツールを含む。すなわち、すべての入力データをＸＭＬに翻訳するタスク、特定の文書のための異なるデータを１つのＸＭＬ文書に併合するタスク、変更およびバージョン文書を追跡するタスク、一組の文書のＸＭＬからインデックスおよびデータベースフラットファイルを作成するタスク、ならびにＸＭＬフォーマット文書を下位互換性ＥＱＶフォーマット文書へと変換するタスクを含む。
【００６６】
（Ｅ．ＣＰＭＬ ＤＴＤは、オリジナル文書にて存在する化学物質、表および数学的情報などを含む実用的な量の情報を保持する）
オリジナルの構造化データは後の使用のために、そのデータを「避けること」（例えば、処理命令においてそれにコメントする、またはそれを包むこと）によって保持され得るが、「避けること」自体はさらなる処理を促進するものではない。その情報を処理するためには、処理中のソフトウェアが理解する意味論的コンテキストにその情報が入れられなくてはならない。処理中のソフトウェアにすべてのオリジナルフォーマットを理解させるよりは、オリジナルフォーマットが１つのフォーマットに翻訳されるべきである。
【００６７】
（Ｆ．ＣＰＭＬ ＤＴＤは、ＸＭＬインターフェースを介してグループおよび注釈にアクセスするためのＩＰＡＭサーバインターフェースを含む）
本発明のＸＭＬおよびＣＰＭＬ ＤＴＤはまた、ＩＰＡＭサーバ１０５のための出力フォーマットとして有用である。ＸＭＬはプラットフォームに依存しない構造化コンテンツフォーマットを提供する。グループ、文書および注釈は、ＩＰＡＭサーバ１０５により出力され得る。
【００６８】
注釈は、いくつかのオプションのフラッグおよび注釈セグメントを含む。注釈セグメントは、「開始」アンカー（ｓｔａｒｔ ａｎｃｈｏｒ）、「終了」アンカー（ｅｎｄ ａｎｃｈｏｒ）、および注釈にはめ込まれ得または注釈により示され得る、所定のコンテンツを有する。注釈はまたグループまたは所有者を参照し得る。可能なＸＭＬフォーマットを以下に示す。
【００６９】
【表２】

グループは、注釈、文書、およびその他のグループを含む。グループは親を参照する。注釈は参照されるか、またはグループ内に直接埋め込まれ得る。可能なＸＭＬフォーマットを以下に示す。
【００７０】
【表３】

本発明のＣＰＭＬ ＤＴＤは、このデータに「それ自体の生命」を与える。例えば、ある人は注釈を同僚に送信し得、そして同僚は（電子メールリーダーに適切なＸＭＬプラグインを有した）電子メールリーダーを用いそれを見得る。同僚がグループコンテキストを所望する場合、その同僚はＷｏｒｋＢｅｎｃｈに要求を送信する「グループ」リンクに従う。
【００７１】
（Ｇ．ＣＰＭＬ ＤＴＤは、第３者のコンテンツマネ−ジャーのための１組のＸＭＬインターフェースを含み、これによりユーザが後にＩＰＡＭを介してそのコンテンツマネ−ジャーを使用できるようにする）
ＸＭＬはサードパーティのサーチエンジンおよび文書サーバにフックするためのバックエンドインターフェースとして使用され得る。ＩＰＡＭサーバ１０５は、中央検索サーバにアクセスするためにインターフェースを使用する必要がある。そのインターフェースはＸＭＬ内にあり、且つ比較的汎用である場合、プラットフォームに依存しない規格を提供する。
【００７２】
（Ｈ．ＣＰＭＬ ＤＴＤはクレーム構造サポートを提供する）
ＣＰＭＬ ＤＴＤの実施形態は、構造化クレーム情報を有する。クレーム構造は、（１）クレーム番号、（２）独立クレーム情報、（３）オプションの従属節を有するプリアンブル、および（４）多くの要素を有する本文を有する。ＣＰＭＬ ＤＴＤは上記にリストした様々な量の構造をサポートする。ＣＰＭＬ ＤＴＤの１例を、図７Ａ〜７Ｃを参照して次に検討する。
【００７３】
（ＩＶ．本発明の１実施形態に基づくＣＰＭＬ ＤＴＤの例）
ＣＰＭＬ ＤＴＤ７０２の１例は、図７Ａ〜７Ｃに示される。本発明の１実施形態によると、ＣＰＭＬ ＤＴＤ７０２の目標は、ＩＰＡＭサーバデータベースおよびインデックス中にあるテキスト構造および文献のタグを含むことである。ＣＰＭＬ ＤＴＤ７０２と、ＩＰＡＭサーバデータベースおよびインデックス中のデータとがどのように関連するかは、図１０Ｇ〜１０Ｉを参照して下に記載する。本発明は、ＣＰＭＬ ＤＴＤ７０２に限定されない。図７Ａ〜７Ｃの例は、説明の目的のみに提供され、そしてそれに限られない。他のＤＴＤは、本明細書に含まれる教示に基づく場合、当業者には明らかである。
【００７４】
ＣＰＭＬ文書において、特許の情報とセクションはＣＰＭＬ ＤＴＤ７０２のそれぞれのタグに格納される。
【００７５】
ＣＰＭＬ ＤＴＤ７０２は、以下に記載される。
【００７６】
ＣＰＭＬ ＤＴＤ７０２の例の理解を補助するために、表１〜表３を含む次の３つの表が提供される。表１は、ＤＴＤにおける要素構造を指定するためのいくつかの通常のシンボルをその説明と共に示す。
【００７７】
【表４】

次の表２は、ＤＴＤにおけるいくつかの一般的な属性タイプを、その説明と共に示す。
【００７８】
【表５】

最後の表である表３は、属性のデフォルト値をその説明と共に示す。
【００７９】
【表６】

ＣＰＭＬ ＤＴＤ７０２の例は、好ましくは各々の文書の明確な部分のための、別個のセクションを含む。図７Ａを参照し、ラベル７０３は、ＣＰＭＬ ＤＴＤ７０２を作成するために共にグループ化された、要素リスト（ＥＬＥＭＥＮＴ）を示す。上の表１からは、括弧が要素をグループ化することが分かる。したがって、「ｐａｔｅｎｔ」を構成する要素またはセクションは、「Ｂｉｂｌｉｏｇｒａｐｈｙ」、「Ａｂｓｔｒａｃｔ」、「ＵｎｓｔｒｕｃｔｕｒｅｄＢｉｂｌｉｏｇｒａｐｈｙ」、「ＢｒｉｅｆＳｕｍｍａｒｙＯｆＩｎｖｅｎｔｉｏｎ」、「ＤｅｓｃｒｉｐｔｉｏｎＯｆＤｒａｗｉｎｇｓ」、「ＤｅｓｃｒｉｐｔｉｏｎＯｆＩｎｖｅｎｔｉｏｎ」および「Ｃｌａｉｍｓ」を含む。表１から分かるように、コンマがこれらの要素の各々を離すため、指定されたシーケンスにて現れるためには要素が必要である。したがって、「Ｂｉｂｌｉｏｇｒａｐｈｙ」要素は、最初に現れる必要がある。この順序の次のものは、「Ａｂｓｔｒａｃｔ」要素である。ＣＰＭＬ ＤＴＤ７０２は、「ａｂｓｔｒａｃｔ」要素が「Ｂｉｂｌｉｏｇｒａｐｈｙ」要素から区別されることを表す。本発明の別の実施形態では、「Ａｂｓｔｒａｃｔ」要素が「Ｂｉｂｌｉｏｇｒａｐｈｙ」要素の内側にあり得る。「Ｂｉｂｌｉｏｇｒａｐｈｙ」要素または「Ａｂｓｔｒａｃｔ」要素の後にはシンボルがないため、これらの要素は一度のみ現れる。
【００８０】
この順序の次の３つ要素（「ＵｎｓｔｒｕｃｔｕｒｅｄＢｉｂｌｉｏｇｒａｐｈｙ」、「ＢｒｉｅｆＳｕｍｍａｒｙＯｆＩｎｖｅｎｔｉｏｎ」および「ＤｅｓｃｒｉｐｔｉｏｎＯｆＤｒａｗｉｎｇｓ」）がそれぞれ疑問符で終わることに留意されたい。表１から、このことは、これらの要素のそれぞれが、必要に応じて一度現れるのみであり得るということを示している。この順序の次のものは、一度現れる必要のある「ＤｅｓｃｒｉｐｔｉｏｎＯｆＩｎｖｅｎｔｉｏｎ」である。４つの先行する要素またはセクションは、特許のテキストセクションであると考えられる。図７Ａ〜７Ｃの実施形態が４つのテキストセクションを示しながらも、５、１０、または任意の数に容易になり得ることに留意されたい。
【００８１】
最後に、一度現れなくてはならない必須の「クレーム」要素がある。
【００８２】
また、図７Ａを参照すると、ラベル７０４は、一般的に各属性のための値と関連する、属性リスト（ＡＴＴＬＩＳＴ）を示す。図示される属性は、「ＭａｊｏｒＶｅｒ」、「ＭｉｎｏｒＶｅｒ」、および「ＧＵＩＤ」を含む。例えば、属性「ＭａｊｏｒＶｅｒ」は値０、１、２などを有し得るが、リストされた値の一つを有さなければならない。＃ＲＥＱＵＩＲＥＤ（表３）は、属性「ＭａｊｏｒＶｅｒ」が要素のすべてのインスタンスにおいて一つの値を有さなければならないということをパーサに示す属性デフォルトである。この属性を含まない場合、パーシングエラーが生じる。属性「ＭｉｎｏｒＶｅｒ」は「ＭａｊｏｒＶｅｒ」と同様の方法で定義される。属性「ＧＵＩＤ」は（表２用ＩＤによって示される）要素を識別する一意の値を有さなければならない。かさねて、＃ＲＥＱＵＩＲＥＤは「ＧＵＩＤ」が要素のすべてのインスタンスにおける値を有さなければならないことを示す。
【００８３】
ラベル７０５は、正規化されたタグのリストを示す。本発明のこの実施形態では、正規化されたタグは多くの場所で現れる共通のセットのタグである。これらの正規化されたタグが現れるとき、所定のデータの正規化を約束する。正規化されたタグは、日付（Ｄａｔｅ）、出版組織（ＰｕｂＯｒｇ）、文書の種類（Ｋｉｎｄ）、数（Ｎｕｍ）、および国（Ｃｎｔｒｙ）のためのタグを含む。特に、Ｄａｔｅは常にＹＹＹＹＭＭＤＤの形であり、ＰｕｂＯｒｇは、ＷＩＰＯ規格３において見られるタグが許されるのみで、Ｋｉｎｄは指定の慣用の命名方法に従い、Ｎｕｍは常に純粋に数字であり、ＣｎｔｒｙはＩＳＯ指定の国が許されるのみである。
【００８４】
ラベル７０６は共通タグおよびエンティティのリストを示す。本発明のこの実施形態では、共通タグは１箇所より多く現れるが、正規化されない。この要素はＣＰＭＬ ＤＴＤ７０２においてパラグラフなどの、テキストのためのフォーマットを指定する。
【００８５】
ラベル７０７は、特許文献タグのリストを示す。この実施形態は、文献タグの異なる分類をサポートする。すなわち、識別子により文書を識別するために役立つ識別子、その他の文書に対する参照、法的項目、分類，その他の雑多な情報である。これらの文献分類は次のように組織される。
【００８６】
文献データ
識別子（すなわち、この文書を他のものから区別するのに役立つデータ）
タイトル
公開および審査機関（ＥＰＯ、ＵＳＰＴＯ等）
文書の種類（出願、特許、再発行）
公開番号（文書固有の番号）
出願番号
要約（典型的または表示的な図と共に、またはなしで）
その他の文書に対する参照
引用文献
審査官引用の引用文献（通常調査報告引用文献のサブセット）
出願人引用の引用文献（典型的には固有の文書にて埋め込まれる）
特許ファミリー
特許出願
関連する出願
関連する譲渡された特許
パリ条約にて優先権を移行する外国出願
優先権主張出願
優先権主張日
優先権主張国
特許協力条約下における優先権を移行するＰＣＴ国際特許出願
法的項目
発明者
譲受人
発明者または譲受人の法的代理（誰、どの会社など）
特許審査官
指定国
関連日（提出出願日、公開日、あれば発行または譲渡日、および再発行
日）
文書の分類
国内
国際（国際特許分類、通常ＩＰＣの版が同じくリストされる）
これらの範疇は利便性の目的にのみ使用される。本発明はこの例に限られない。
【００８７】
ＣＰＭＬ ＤＴＤのいくつかの実施形態は、これら文献のフィールドのすべてを有し得、他のＤＴＤ実施形態はそのフィールドの下位セットを有し得る。図７Ａ〜７Ｃの例においては、文献タグは、以下のように組織される。すなわち、一般情報７０７、識別子７０８、他の文書への参照７０９、法的項目７１０（すなわち、譲受人の権利を独占にまで強化するデータ）、分類７１１、およびその他の雑多な情報７１２である。
【００８８】
ラベル７０７を参照すると、一般情報に関連する文献タグが図示される。上記の表１から、括弧が要素をグループ化することが分かる。表１からはまた、コンマがこれらの要素それぞれを区別するため、要素が指定の順序において現れる必要があることが分かる。したがって、一般情報に関連する文献タグを構成する要素またはセクションは以下のようである。
【００８９】
Ｔｉｔｌｅ：一度のみ現れなくてはならない
ＰｕｂＮｏ：タイトルの後に一度のみ現れなくてはならない
ＡｐｐＮｏ：ＰｕｂＮｏの後に一度のみ現れなくてはならない
ＰａｔｅｎｔＲｅｆ＊：任意の数のＰａｔｅｎｔＲｅｆが連続で現れ得る、ゼロでもよい
ＦｉｌｉｎｇＤａｔｅ：連続で現れなくてはならない、そして一度のみ現れなくてはならない
ＩｓｓｕｅＤａｔｅ？：それがある場合はＦｉｌｉｎｇＤａｔｅの後に一度のみ現れなくてはならないがオプションである
ＰｕｂｌｉｃａｔｉｏｎＤａｔｅ？：それがある場合は連続で一度のみ現れなくてはならないが、オプションである
ＣａｌｃｕｌａｔｅｄＥｘｐｉｒａｔｉｏｎＤａｔｅ？：それがある場合は連続で一度のみ現れなくてはならないが、オプションである
Ａｓｓｉｇｎｅｅ＊：任意の数の指定代理人が連続で現れ得る、ゼロでもよい
Ｉｎｖｅｎｔｏｒ＊：任意の数の発明者が連続で現れ得る、ゼロでもよい
Ｐｒｉｏｒｉｔｙ＊：本特許が優先権を主張している任意の数の参考文献が連続で現われ得る、ゼロでもよい
ＤｅｓｉｇｎａｔｅｄＳｔａｔｅｓ：連続で現れなくてはならない、且つ一度のみ現れなくてはならない
ＩＰＣ＊：任意の数のＩＰＣが連続で現われ得る、ゼロでもよい
ＵＳＣｌａｓｓｉｆｉｃａｔｉｏｎ＊：ＵＳ分類の任意の数が連続で現われ得る、ゼロでもよい
ＰｕｂｌｉｃａｔｉｏｎＬａｎｇｕａｇｅ：連続で現れなくてはならない、且つ一度のみ現れなくてはならない
ＮｕｍＣｌａｉｍｓ？：それがある場合はＰｕｂｌｉｃａｔｉｏｎＬａｎｇｕａｇｅ後に一度のみ現れなくてはならないが、オプションである
ＮｕｍＤｒａｗｉｎｇＰａｇｅｓ？：それがある場合は連続で一度のみ現れなくてはならないが、オプションである
ＮｕｍＦｉｇｕｒｅｓ？：それがある場合は連続で一度のみ現れなくてはならないが、オプションである
ＮｕｍＳｐｅｃＰａｇｅｓ？：それがある場合は連続で一度のみ現れなくてはならないが、オプションである
これらの要素のそれぞれがさらに定義されることに留意されたい。例えば、Ｔｉｔｌｅ、ＰｕｂＮｏおよびＡｐｐＮｏは、ラベル７０８により示されるようにさらに定義される。例えば、ＰｕｂＮｏは、正規化されたタグ、すなわち順にＰｕｂＯｒｇ、Ｋｉｎｄ、およびＮｕｍ（ラベル７０５に関し上記される）を含む必要がある。
【００９０】
ＰａｔｅｎｔＲｅｆは、ラベル７０９により示されるようにさらに定義される。ＦｉｌｉｎｇＤａｔｅ、 ＩｓｓｕｅＤａｔｅ、 ＰｕｂｌｉｃａｔｉｏｎＤａｔｅ、 ＣａｌｃｕｌａｔｅｄＥｘｐｉｒａｔｉｏｎＤａｔｅ、 Ａｓｓｉｇｎｅｅ、 Ｉｎｖｅｎｔｏｒ、 ＰｒｉｏｒｉｔｙおよびＤｅｓｉｇｎａｔｅｄＳｔａｔｅｓは、各々ラベル７１０により示されるようにさらに定義される。
【００９１】
ＩＰＣおよびＵＳＣｌａｓｓｉｆｉｃａｔｉｏｎは、ラベル７１１により示されるようにさらに定義される。ラベル７１１を参照すると、ＩＰＣは、セクション、クラス、下位クラス、グループおよび下位グループの正規化されたタグを含む必要がある。ＵＳＣｌａｓｓｉｆｉｃａｔｉｏｎは、ＵＳＣｌａｓｓ、ＵＳＳｕｂｃｌａｓｓおよびＵＳＳｕｆｆｉｘの正規化されたタグを含む必要がある。
【００９２】
最後に、ＰｕｂｌｉｃａｔｉｏｎＬａｎｇｕａｇｅ、ＮｕｍＣｌａｉｍｓ、ＮｕｍＤｒａｗｉｎｇＰａｇｅｓ、ＮｕｍＦｉｇｕｒｅｓおよびＮｕｍＳｐｅｃＰａｇｅｓはラベル７１２により示されるようにさらに定義される。
【００９３】
そのセクションまたは要素要約がＣＰＭＬ ＤＴＤ７０２において次である。要約要素はラベル７１３により示される。
【００９４】
要約セクションの後、ラベル７１４によって示される、構造化されない文献セクションが続く。７１４によってラベル付けされた構造化されない文献は、構造化されないフォーマットの所定の特許のすべての文献情報のテキスト表示を含む。この情報は、特許を与えることをサポートするために提供される。なぜなら文献情報すべてが構造化されたフォーマットに（ＣＰＭＬ ＤＴＤ７０２をサポートする文書に）格納されるわけではない可能性があるからである。
【００９５】
上記教示に基づき、当業者は、本発明のセクションの簡単な要約がラベル７１５により示されること、図面セクションの簡単な説明がラベル７１６により示されること、発明セクションの詳細な記載がラベル７１７により示されること、およびクレームのセクションがラベル７１８により示されることを含むＣＰＭＬ ＤＴＤ７０２の残り部分を理解する。
【００９６】
（Ｖ．例示的ＣＰＭＬ知的財産文書−米国特許）
図８Ａ〜図８Ｃは、米国特許に関する例示的ＣＰＭＬ知的財産文書を示す。図８Ａ〜８ＣのＣＰＭＬ知的財産文書は、図７Ａ〜７ＣのＣＰＭＬ ＤＴＤ ７０２に対応する。
【００９７】
（ＶＩ．例示的ＣＰＭＬ文書〜欧州特許）
図７Ａ〜７ＣのＣＰＭＬ ＤＴＤ ７０２は、米国特許だけではなく、全ての種類の特許知的財産文書をサポートする。例えば、図９Ａ〜９Ｃは、ＥＰ出願に関する例示的ＣＰＭＬ知的財産文書を示す。図９Ａ〜９ＣのＣＰＭＬ知的財産文書は、図７Ａ〜７ＣのＣＰＭＬ ＤＴＤ ７０２に対応する。
【００９８】
（ＶＩＩ．ＣＰＭＬ ＤＴＤおよび他の特許ＤＴＤと例示的データベースインプリメンテーションとの間の対応）
図１０Ａ〜１０Ｉは、ＣＰＭＬ ＤＴＤ ７０２と他の特許関連ＤＴＤ（例えば、米国特許庁および欧州特許庁の特許関連ＤＴＤ）との間のマッピングを示す。図１０Ａ〜１０Ｉの配置を図１０Ｊ中に示す。
【００９９】
ＵＳＰＴＯの「Ｒｅｄ Ｂｏｏｋ」ＤＴＤおよび「Ｇｒｅｅｎ Ｂｏｏｋ」ＤＴＤはそれぞれ、縦列（ｃｏｌｕｍｎ）１００４および１００６によって表される。ＥＰＯ／ＰＣＴのＤＴＤは、縦列１００８、１０１０および１０１２によって表される。１つの実施形態によるＣＰＭＬ ＤＴＤ ７０２は、縦列１０１４、１０１６および１０１８によって表される。
【０１００】
図１０Ａ〜１０Ｉはまた、ＣＰＭＬ ＤＴＤ ７０２とＩＰＡＭサーバデータベースのフィールドとの間のマッピングも示し、これにより、ＣＰＭＬ知的財産文書からのデータをデータベースに格納する方法と、データベースを用いてＣＰＭＬ知的財産文書をポピュレートする方法とが示される。
【０１０１】
（ＶＩＩＩ．本発明の知的財産プロトコルシステムの機能の詳細な説明）
知的財産プロトコルシステム１１０の機能について、図２を参照して上記にて紹介した。知的財産プロトコルシステム１１０の機能としては、知的財産プロトコル機能２０５、知的財産データ／交換（ｅｘｃｈａｎｇｅ）処理機能２１０、提示（ｐｒｅｓｅｎｔａｔｉｏｎ）機能２１５および管理機能２３０がある。これらの機能はそれぞれ、１つ以上の機能を含み得る。
【０１０２】
（Ａ．知的財産プロトコル機能）
ＣＰＭＬ ＤＴＤ ７０２は、知的財産プロトコル機能２０５により行なわれる以下の機能に関するフォーマットおよび規則をサポートする：
特許および商標の手続きならびにワークフロー
特許出願および商標出願の電子提出
特許管理費および商標管理費の支払いの追跡および報告
ライセンス追跡
ライセンス監査
ライセンス支払い
知的財産メタ（Ｍｅｔａ）データ管理は、政府発行のメタデータ、ダーウェント（Ｄｅｒｗｅｎｔ）データおよび他の第３者、ＣＭＬデータ、ユーザ定義による知的財産メタデータ等を含む（但し、他のＤＴＤも含み得る）。
【０１０３】
ＥＲＰシステムとの知的財産データトランザクションデータ交換
ドケットシステム、ライセンシングシステム等
知的財産メタデータの報告および視覚化
知的財産メタデータと他の関連企業データおよび事業データとの関連付け
ＣＰＭＬ文書のＴＩＢＣＯデータ交換ワイヤフォーマット通信層等への直接的提示
新規特許情報によるクライアントまたはプレーヤの自動更新
次に、本発明の知的財産データおよび交換処理機能２１０について説明する。
【０１０４】
（Ｂ．知的財産データおよび交換処理機能）
（ＸＭＬに適合する）本発明のＸＭＬおよびＣＰＭＬ ＤＴＤ ７０２の強力な局面は、様々な種類のトランザクション用のデータ交換規則およびフォーマットを定義する能力である。例えば、図６を参照されたい。多くのｅコマースデータ交換構想があり、例えば、ＳＥＴ、ＪＥＰＩ、ＣｏｍｍｅｒｃｅＮｅｔ、Ｃｙｂｅｒ Ｃａｓｈ、Ｍｉｌｌｉｃｅｎｔ、ＯＦＸ、ＸＭＬ／ＥＤＩ等がある。上記の全てのスーパーセットであるＳＧＭＬベースの構想は、Ｏｐｅｎ Ｆｉｎａｎｃｉａｌ Ｅｘｃｈａｎｇｅプロトコル（ＯＦＸ）である。
【０１０５】
ＯＦＸは、ＳＧＭＬベースの構想であり、電子商取引技術の共存および共同利用を可能にする。ＯＦＸは、インターネット上に広く広がる小売業基盤の発展へと続く道筋を円滑にすることを目的とする。ＯＦＸは、以下の活動に関するフォーマットをサポートし、規則を定める：
販売の申し出
購入合意
支払い
物品の移動およびサービス
配達
受取り
問題解決
ＣＰＭＬ ＤＴＤ ７０２は、知的財産データおよび交換処理機能２１０によって行なわれる機能に関するフォーマットおよび規則をサポートする。
【０１０６】
（Ｃ．提示機能）
本発明の提示機能２１５は、ユーザへの任意の出力のフォーマットを指定する責任を負う。本発明の実施形態において、提示機能２１５は、カスケードスタイルのシートを用いて、ＣＰＭＬ知的財産文書の出力をフォーマットする。カスケードスタイルのシートまたは一般的なスタイルシートについては、当該分野（単数または複数）で周知であるため、以下に簡単な概略のみを述べる。
【０１０７】
スタイルシートは一般的には、文書のレイアウトを規定するファイルまたはフォームである。スタイルシートに記入が行なわれる際、ページサイズ、マージンおよびフォント等のパラメータが指定される。同じスタイルシートを多くの文書に用いることが可能であるため、スタイルシートは有用である。例えば、あるスタイルシートを特許用に規定し、別のスタイルシートを特許手続き用に規定し、さらに別のスタイルシートを商標用に規定するといった具合である。スタイルシートはテンプレートとも呼ばれる。
【０１０８】
より詳細には、カスケードスタイルのシートは、フォーマット情報を文書本分から切り離して、そのフォーマット情報を、ＳＴＹＬＥ構成要素（ｅｌｅｍｅｎｔ）または別個の文書中に別個に格納することができる。さらに、インライン（ｉｎ−ｌｉｎｅ）スタイリングの場合に、ＳＴＹＬＥ属性を用いて、特定の構成要素に関するフォーマット情報を示すことも可能である。「カスケード」とは、複数のスタイルシートとインラインスタイリングとを組み合わせてマスターテンプレートを作成するタスクを簡略化し、必要に応じて改変を施す能力を指す。カスケードスタイルのシートでは文書構造をフレームワークとして用い、次いで、カスケードスタイルのシートにフォーマット情報が注釈として付加され、シートの表示（または印刷、読取りあるいは何らかの方法による表示）が、アプリケーション（典型的には、ウェブブラウザ）によって行なわれる。
【０１０９】
（Ｄ．管理機能）
管理機能２３０は、特に、管理担当者が、ＩＰＡＭサーバ１０５、知的プロトコルシステム１１０および／または知的財産データベース１３５へのユーザのアクセス権の有無を制御することを可能にする。
【０１１０】
（ＩＸ．一般的なシステムオペレーション）
以下において、知的財産プロトコルシステム１１０によって提供される機能モジュールおよび特徴をユーザがナビゲートする様態について説明する。（フロントエンドシステム１１３を介する）知的財産プロトコルシステム１１０は、インターネットを通じたワールドワイドウェブページを介して（すなわち、オンラインサービスを通じて）デスクトップコンピュータ上のユーザにより直接アクセス可能であるか、または、イントラネットを介してもアクセス可能である。別の実施形態において、（フロントエンドシステム１１３を介する）知的財産プロトコルシステム１１０は、電話サービス等を介してもアクセス可能である。本明細書中で説明する制御フローは例示目的のみのために示されている点が理解されるべきである。本発明の知的財産プロトコルシステム１１０は、ユーザが上記以外の様式でもシステム１１０をナビゲートすることを可能にするための十分な柔軟性および適合性を有する。
【０１１１】
図１１は、知的財産プロトコルシステム１１０の機能の高レベルオペレーションの一例を示す。他の高レベルオペレーションについては、図１４および１５を参照して後述する。図１１を参照して、フローチャート１１００は、工程１１０２から開始する。工程１１０２において、知的財産プロトコル機能２０５は、（フロントエンドシステム１１３を介して）ＣＰＭＬ知的財産文書を受け取る。次いで、制御は工程１１０４へと進む。
【０１１２】
工程１１０４において、知的財産プロトコル機能２０５は、受信した知的財産文書を、ＣＰＭＬ ＤＴＤ ７０２（図７Ａ〜７Ｃ）で書かれた適切なＤＴＤを用いて処理する。ここで、ＣＰＭＬ ＤＴＤ ７０２を用いて、パージングを行い、所望のデータを知的財産文書から抽出する。次いで、制御は工程１１０６へと進む。
【０１１３】
工程１１０６において、提示機能２１５が呼び出され、これにより、情報をフォーマットし、知的財産文書中に表示する。上述したように、本発明の１つの実施形態において、カスケードスタイルのシートを用いて、提示機能２１５の出力をフォーマットすることが可能である。この時点で、フローチャート１１００が終了する。
【０１１４】
フローチャート１１００の工程１１０４について、図１２を参照してさらに説明する。図１２を参照して、制御は工程１２０２から開始する。工程１２０２において、知的財産プロトコル機能２０５は、知的財産文書中のデータのうち再フォーマットが必要な箇所を判定する。知的財産文書中のデータのうち再フォーマットが必要な箇所が有る場合、知的データおよび交換処理機能２１０が呼び出され、これにより、データの再フォーマットが行なわれる。次いで、制御は工程１２０４へと進む。
【０１１５】
工程１２０４において、受け取られた知的財産文書の種類の詳細に基づいて、プロトコル機能２０５は、ＣＰＭＬ ＤＴＤ ７０２を参照して、（ＣＰＭＬ ＤＴＤ ７０２が複数のＤＴＤを含むと仮定した場合に）ＣＰＭＬ ＤＴＤ ７０２中のＤＴＤのうち使用するＤＴＤを判定する。次いで、制御は工程１２０６へと進む。
【０１１６】
工程１２０６において、プロトコル機能２０５は、ＣＰＭＬ ＤＴＤ ７０２を参照して、情報をパージングし、知的財産文書から情報を抽出する。次いで、制御は工程１２０８へと進む。
【０１１７】
工程１２０８において、知的財産文書がＣＰＭＬ ＤＴＤ ７０２に適合するか否かを判定する。知的財産文書がＣＰＭＬ ＤＴＤ ７０２に適合する場合、制御は工程１１０６（図１１）へと進む。知的財産文書がＣＰＭＬ ＤＴＤ ７０２に適合しない場合、制御は工程１２１０へと進む。
【０１１８】
工程１２１０において、プロトコル機能は、パージングエラーを（フロントエンドサーバ１１３を介して）ユーザに表示する。この時点で、図１２は終了する。
【０１１９】
フローチャート１１００の工程１１０６について、図１３を参照してさらに説明する。図１３を参照して、制御は工程１３０２から開始する。工程１３０２において、提示機能２１５は、リクエストされた情報をユーザに提供するためにＩＰＡＭサーバ１０５（図１）を呼び出す必要が有るか否かを判定する。次いで、制御は工程１３０４へと進む。
【０１２０】
工程１３０４において、提示機能２１５は、抽出されたデータおよび／またはＩＰＡＭサーバ１０５から受け取った任意のデータをカスケードスタイルのシートと共に用いて、ユーザに所望の出力を生成する。（異なる一式の情報の表示および／または実行中のタスクにとって有効なフォーマットに情報を表示または交換するために）実行中のタスクに応じて、様々なスタイルシートを選択および使用することが可能である。ユーザが所望する出力にデータの再フォーマットが必要な場合、データおよび交換処理機能２１０が呼び出され、これにより、当該データが正しいフォームでフォーマットされる。この時点で、図１３は終了する。
【０１２１】
上述したように、図１１は、知的財産プロトコルシステム１１０の機能の高レベルオペレーションの一例を示す。図１４および１５は、知的財産プロトコルシステム１１０の機能の高レベルオペレーションの別の例を示し、これについて次に説明する。ＣＰＭＬ ＤＴＤ ７０２は、複数のトランザクションをサポートする。例えば、ＣＰＭＬ ＤＴＤ ７０２の実施形態は、クライアント情報の自動更新をサポートする。本発明のこの機能を図１４中に示すフローチャート１４０２に示し、対応するイベント追跡図１５０２を図１５に示す。図１４を参照して、制御は工程１４０４から開始する。
【０１２２】
工程１４０４において、ホスト１５０４は、特許情報および特許関連情報をＣＰＭＬ文書１５０８を介してクライアント１５０６に提供する。ＣＰＭＬ文書１５０８は、米国特許第５，８３２，２２９号の表示物である。ＣＰＭＬ文書１５０８は、この特許に関する情報（例えば、図７Ａ〜７Ｃ中に示される情報）を含む。ＣＰＭＬ文書１５０８はまたバージョン情報も含み、現在説明している実施形態において、このバージョン情報はＣＰＭＬ ＤＴＤの一部となっている。図１５の実施例において、バージョンはＶ１である。このバージョン情報を用いて、情報に変更が有った場合に後述するようにクライアント１５０６を更新する。次いで、制御は工程１４０６へと進む。
【０１２３】
工程１４０６において、特許情報および／または特許関連情報が変更される。例えば、特許の再分類、譲受人の変更、発明エンティティ（ｉｎｖｅｎｔｉｖｅ ｅｎｔｉｔｙ）の変更、発行後の文書の追加等が行われ得る。これらの変更を、図１５中に１５１２として示す。次いで、制御は工程１４０８へと進む。
【０１２４】
工程１４０８において、ホスト１５０４におけるＩＰＡＭデータベースに改変を加えて、これらの変更１５１２を反映する。ホスト１５０４は、様々なソース（例えば、Ｃａｓｓｉｓ、ＵＳＰＴＯ公報等）から変更１５１２を受け取り得る。新規バージョン番号（Ｖ２）が米国特許第５，８３２，２２９号に割り当てられる。次いで、制御は工程１４１０へと進む。
【０１２５】
工程１４１０において、クライアント１５０６を、新規バージョン番号Ｖ２に関連する新規／変更情報で自動更新する。この自動更新工程は、例えば、クライアント１５０６において表示された文書のバージョン番号をチェックすることによりインプリメントされ得る。このチェック工程において、クライアント１５０６がバージョンＶ１の米国特許第５，８３２，２２９号を有することが示される。ホスト１５０４は、現在のバージョンの文書がＶ２であることを知る。従って、ホスト１５０４は、Ｖ２の米国特許第５，８３２，２２９号をＣＰＭＬ文書１５１４としてクライアントに送る。クライアント１５０６において、この新規ＣＰＭＬ文書１５１４を用いて、そのバージョンの米国特許第５，８３２，２２９号を自動更新する。この時点で、図１４中のフローチャート１４０２が終了する。
【０１２６】
（Ｘ．ＸＭＬ文書および非ＸＭＬ文書からのデータの入力）
上述したように、ＩＰＡＭサーバ１０５は、ＸＭＬ文書および非ＸＭＬ（例えば、ＥＱＶ）文書と動作可能である。これは、例えば、図１６中に図示されている。
【０１２７】
ＸＭＬサーバ１６１０は、ＸＭＬ入力１６０２（例えば、ＸＭＬ文書）を受け取る。ＸＭＬサーバ１６１０は、ＸＭＬ入力１６０２から構造化情報を自動抽出し、その構造化情報をＩＰＡＭ／会社データベース１６１２中に格納する。現在、ＥＸＣＥＬＯＮ等のＸＭＬサーバが市販されている。このようなＸＭＬサーバのうち任意のものが、本発明と共に使用可能である。
【０１２８】
本発明は、非ＸＭＬデータとも機能可能である。パーサー１６０６は、非ＸＭＬ文書であり得る非ＸＭＬ入力１６０４を受け取る。この非ＸＭＬ入力１６０４を、特定の様式でフォーマットする。パーサー１６０６は、プログラミング解析またはオンザフライ解析のいずれかを用いて、非ＸＭＬ入力１６０４のフォーマットを知る。パーサー１６０６は、非ＸＭＬ入力１６０４から情報を抽出し、ＸＭＬ文書またはデータを生成する。ＸＭＬ文書が生成されると、そのＸＭＬ文書は処理対象としてＸＭＬサーバ１６１０へと送られる。データが生成されると、そのデータは、ＩＰＡＭ／会社データベース１６１２中に格納される。
【０１２９】
（ＸＩ．電子文書の取り寄せおよびＤＴＤのダウンロード）
上述したように、ＣＰＭＬ ＤＴＤ ７０２（図７Ａ〜７Ｃ）は、電子データ交換／転送およびＩＰ関連トランザクションをサポートする。例えば、図６を参照されたい。本発明は、例えば、電子文書の取り寄せおよびプロトコルＤＴＤのダウンロードをサポートする（但し、これに限定されない）。この工程の一例を図１７Ａ〜１７Ｃに示す。このＤＴＤを用いて、文書を電子的に取り寄せ、その取り寄せを追跡し、取り寄せを遂行（ｆｉｌｌ ｏｕｔ）することが可能である。図１７Ａ〜１７ＣのＤＴＤは、ＣＰＭＬ ＤＴＤ ７０２の一部であり得、または、ＣＰＭＬ ＤＴＤ ７０２とは区別され得る。
【０１３０】
（ＸＩＩ．本発明の知的財産プロトコルの別の実施形態−ＳＰＭＬ（ＳｍａｒｔＰａｔｅｎｔｓマークアップ言語））
本発明は、別の特許マークアップ言語の実施形態に関する。そのような別の実施形態はＳＰＭＬ（ＳｍａｒｔＰａｔｅｎｔｓマークアップ言語）と呼ばれる。
【０１３１】
ＣＰＭＬ文書のフォーマットはＣＰＭＬ ＤＴＤ ７０２によって特定される（図７Ａ〜７Ｃ）。対照的に、ＳＰＭＬ文書のフォーマットはＳＰＭＬで特定される処理（すなわち、ＳＰＭＬを処理するコンピュータプログラム）によって特定される。端効果は、通常同じである。
【０１３２】
ＤＴＤで特定される文書から処理で特定される文書への変換、および逆の変換は、本明細書中に含まれる教示に基づく関連分野の当業者には明らかである。例えば、ＳＰＭＬの処理からＤＴＤへの変換は、本明細書中に含まれる教示に基づく（単数または複数）の関連分野の当業者には明らかである。ＳＰＭＬファイルの一般的なフォーマットは文書ヘッダ、文献データ、およびフォーマットされた文書テキストを含む。本発明のＳＰＭＬの詳細部を議論する前に、ＳＰＭＬに使用されるモジュールの実施形態を説明する。
【０１３３】
図１８は、本発明のＳＰＭＬのために使用されるモデル１８００の実施形態の１例を示す。モデル１８００におけるオブジェクトはコンテナまたはリーフ（ｌｅａｆ）のどちらかと呼ばれる。コンテナはリーフを含み得、またはコンテナはさらにコンテナを含み得る。それゆえ、各コンテナは、コンテナに含まれ得るオブジェクト（例えば、コンテナまたはリーフ）のタイプを限定または抑制する。図１８を参照とすると、コンテナは文書１８０８、Ｓｅｃｔｉｏｎ １８１０、Ｐａｒａｇｒａｐｈ １８１２およびＬｉｎｅ １８１４からなる。リーフは、文書複合要素（Ｃｏｍｐｏｓｉｔｅ）１８０１、Ｔｅｘｔ １８０２、ＰａｇｅＢｒｅａｋ １８０４、ＶｅｒｔＳｐａｃｅ １８０６、ＢｉｂＩｔｅｍ １８１６、ＢｉｂＬｉｓｔＯｆ １８１８、Ｂｉｂｓｅｃｔｉｏｎ １８２０、ＢｉｂＤａｔｅ １８２２、ＢｉｂＮｕｍｂｅｒ １８２４、およびＢｉｂＴｅｘｔ １８２６からなる。各々のコンテナおよびリーフをどのように定義するかが以下で議論される。
【０１３４】
上述されたように、ＳＰＭＬファイルの汎用フォーマットは、例えば、文書ヘッダー、文献データ、およびフォーマットされた文書テキストを含む。再度、図１８を参照すると、文書１８０８は文書ヘッダーをモデルとするように使用される。ＢｉｂＩｔｅｍ １８１６、ＢｉｂＬｉｓｔＯｆ １８１８、Ｂｉｂｓｅｃｔｉｏｎ １８２０、ＢｉｂＤａｔｅ １８２２、ＢｉｂＮｕｍｂｅｒ １８２４、およびＢｉｂＴｅｘｔ １８２６は、文献データをモデルとするように使用される。最後に、Ｓｅｃｔｉｏｎ １８１０、Ｐａｒａｇｒａｐｈ １８１２、Ｌｉｎｅ １８１４、Ｔｅｘｔ １８０２、ＰａｇｅＢｒｅａｋ １８０４、ＶｅｒｔＳｐａｃｅ １８０６は、フォーマットされた文書テキストをモデルとするように使用される。これらの各々は以下で詳細に議論される。
【０１３５】
本発明はこれらの要素に限定されないことを留意する。本明細書で説明される上記の要素および構成は例示する目的のためのみに提供される。他の要素および構成は、本明細書中の教示されるものを基礎とする分野の当業者には明らかである。
【０１３６】
（Ａ． ＳＰＭＬファイルの文書ヘッダー）
文書の第１行目は文書タイプがＳＰＭＬであることを示すタグである。このタグは：特許のデフォルトの文書タイプに対しては「ｓｐＤｏｃ」である。
【０１３７】
文書ヘッダーの第２行目はファイルに含まれるＳＰＭＬの主なバージョン番号である。
【０１３８】
文書ヘッダーの第３行目はファイルに含まれるＳＰＭＬのマイナ（ｍｉｎｏｒ）バージョン番号である。主なバージョン番号およびマイナバージョン番号は、正確なＳＭＰＬパーサにおいてスワップするために文書ビルダー（ｂｕｉｌｄｅｒ）の中で使用され得る。後で未加工のＳＰＭＬを手動で編集することが望ましい場合、チェックサムおよびファイルサイズはヘッダーに加えられない。
【０１３９】
（Ｂ．ＳＰＭＬファイルの文献データ）
文献データセクションは、次の項目を含み得るが、これらに限定されない：（ＢｉｂＴｅｘｔ １８２６に関連する）テキストのストリング、（ＢｉｂＮｕｍｂｅｒ １８２４に関連する）整数、（ＢｉｂＤａｔｅ １８２２に関連する）データ、（Ｂｉｂｓｅｃｔｉｏｎ １８２０に関連する）フォーマットされたテキストのセクション、および（ＢｉｂＬｉｓｔＯｆ １８１８に関連する）上述された文献項目の任意のリスト。これらの要素の各々は以下でより詳細に説明される。
【０１４０】
（１．ＢｉｂＴｅｘｔ）
ＢｉｂＴｅｘｔ １８２６におけるデータのフォーマットは以下の通りである：
Ｔ９，Ｉｎｖｅｎｔｏｒ Ｌａｓｔ Ｎａｍｅ，１，Ｓｍｉｔｈ
第１のコンマで区切られるフィールドはタグであり、次の情報を含む：
１）「Ｔ」によりその行はＢｉｂＴｅｘｔ項目を含んでいると識別される。
【０１４１】
２）タグに続く番号は、それがどんなテキスト項目の種類であるかを示すタイプＩＤである。これらのタイプは、既知特許テキスト要素にマッピングされ（例えば、「１」のテキストタイプＩＤは、特許番号であるテキスト項目であり、「９」のテキストタイプＩＤは、発明者の名前であるテキスト項目である）、ユーザ定義文献テキスト項目は固有なタイプＩＤに与えられる。
【０１４２】
第２のコンマで区切られるフィールドは名前であり、次の情報を含む：
１）テキスト項目に与えられる名前（例えば、「特許番号」または「発明者の姓」）。このフィールドは、既知の特許のタイプ（その情報はタイプＩＤから判定され得る）に関してはたいてい空白であることが多く、ユーザが文献テキスト項目を定義するためのデータを含む。
【０１４３】
第３のコンマで区切られるフィールドはスタイルインデックスであり、次の情報を含む：
１）テキスト項目を表示する場合に使用されるスタイルのインデックス（例えば、テキスト項目を示す「１」のスタイルインデックスは通常の９ポイントのＴｉｍｅｓ Ｒｏｍａｎで表示されることになる）。
【０１４４】
第４のコンマで区切られるフィールドはデータであり、次の情報を含む：
１）実テキストデータ（ａｃｔｕａｌ ｔｅｘｔ ｄａｔａ）を含むストリング。
【０１４５】
（２．ＢｉｂＮｕｍｂｅｒ）
ＢｉｂＮｕｍｂｅｒ １８２４におけるデータのファーマットは以下の通りである：
Ｎ５，Ｎｕｍｂｅｒ ｏｆ ｃｌａｉｍｓ，１６．
第１のコンマで区切られるフィールドはタグであり、次の情報を含む：
１）「Ｎ」により行がＢｉｂＮｕｍｂｅｒを含んでいることが識別される。
【０１４６】
２）タグに続く番号は、それがどんな数項目の種類であるかを示すタイプＩＤである。これらのタイプは、既知の特許ナンバー要素にマッピングされ（例えば、「５」の数タイプＩＤは、特許が有する請求項の数である数項目である）、ユーザ定義文献数項目は固有なタイプＩＤに与えられる。
【０１４７】
第２のコンマで区切られるフィールドは名前であり、次の情報を含む：
１）数項目に与えられる名前（例えば、「請求項の数」）。このフィールドは、定義された文献テキスト項目に対してたいてい空白であることが多い。
【０１４８】
第３のコンマで区切られるフィールドはデータであり、次の情報を含む：
１）データである整数値。
【０１４９】
（３．ＢｉｂＤａｔｅ）
ＢｉｂＤａｔｅ １８２２におけるデータのフォーマットは以下の通りである：
Ｄ１，Ａｐｐｌｉｃａｔｉｏｎ ｄａｔｅ，７ １１ １９８５．
第１のコンマで区切られるフィールドはタグであり、次の情報を含む：
１）「Ｄ」により行がＢｉｂＤａｔｅを含んでいることが識別される。
【０１５０】
２）タグに続く数は、それがどんなデータ項目の種類であるかを示すタイプＩＤである。これらのタイプは、既知の特許日付要素にマッピングされ（例えば、「１」のデータタイプＩＤは、特許の出願日であるデータ項目である）、ユーザ定義文献数項目は固有なタイプＩＤに与えられる。
【０１５１】
第２のコンマで区切られるフィールドは名前であり、次の情報を含む：
１）データ項目に与えられる名前（例えば、「出願日」）。このフィールドは、既知の特許タイプ（その情報はタイプＩＤから判定され得る）に対してたいてい空白であることが多く、ユーザが文献テキスト項目を定義するためのデータを含む。
【０１５２】
第３のコンマで区切られるフィールドはデータであり、次の情報を含む：
１）スペースにより区切られた、月、日および年。
【０１５３】
（４．ＢｉｂＳｅｃｔｉｏｎ）
Ｓｅｃｔｉｏｎ項目（例えば、ＢｉｂＳｅｃｔｉｏｎ １８２０）内のデータのフォーマットは、文書テキストのフォーマットされたテキストセクションに類似する。２つの場所内で同じ情報を保持する困難を回避するために、顕著な違いのみがここに与えれられる。文献セクションについてのタグは、「Ｓ」ではなく「Ｂ」である。
【０１５４】
（５． ＢｉｂＬｉｓｔＯｆ）
ＢｉｂＬｉｓｔＯｆ １８１８項目内のデータフォーマットは以下である：
Ｌ１， ＢｉｂｌｉｏｇｒａｐｈｉｃＤａｔａ
ｂｉｂ 項目（他のリストを含む）
〜
第１のコンマで区切られるフィールドはタグであり、以下の情報を含む：
１）「Ｌ」は、ＢｉｂＬｉｓｔＯｆを始めるものとして行を識別する。
【０１５５】
２）タグに続く数は、そのＢｉｂＬｉｓｔＯｆがどんな種類のリスト項目であるかを知らせるタイプＩＤである。これらのタイプは、公知の特許リスト要素（例えば、「２」のリストタイプＩＤは、発明者リスト項目のリストであり。「３」のタイプＩＤは、ファーストネームについてのＢｉｂＴｅｘｔ項目およびラストネームについての別の項目のような発明者を構成する全ての項目のリストである）にマッピングされ、ユーザ定義文献リスト項目は、一意なタイプＩＤを与えられる。「１」のリストタイプＩＤがすべての文書が有する必要があるリストの特定のタイプであり、これは文書が有するすべての他の文献項目を含むリストであることに留意されたい。
【０１５６】
第２のコンマで区切られるフィールドは、Ｎａｍｅ（名前）であり、以下の情報を含む：
１）リスト項目に与えられる名前（例えば、「文献データ」、「発明者リスト」または、「発明者項目」）。このフィールドは、既知の特許のタイプについてほとんどの場合空であり、（情報はタイプＩＤから判定され得る）、ユーザ定義文献テキスト項目についてのデータを含む。
【０１５７】
ＢｉｂＬｉｓｔＯｆ １８１８内のデータの最後の部分は終了タグである：
１）リストは入れ子にされ得るので、終了タグはリストの終了をマークするために必要とされる。この終了タグは１つの行の単独の「〜」である。終了タグは、最も最近のリストの終了をマークする。例えば以下である：
Ｌ１，文献データ
Ｌ２，発明者リスト
〜 ／／これは発明者リストを終了する
〜 ／／これは文献データリストを終了する
（Ｃ．ＳＰＭＬファイルのフォーマットされた文書テキストデータ）
フォーマットされた文書テキストデータセクションは、以下の項目（しかし、これに限定されない）を含み得る：１つ以上の（セクション１８１０に関する）段落を含むセクション、１つ以上の（段落１８１２に関する）行を含む段落、１つ以上の（行１８１４に関する）テキストシーケンスを含む行、１つ以上の（行１８０２に関する）文字を含むテキストシーケンス、（ＰａｇｅＢｒｅａｋ １８０４に関する）改ページ、（ＶｅｒｔＳｐａｃｅ １８０６に関する）縦スペース、および（図１８に示されない）特殊文字。これらのそれぞれは、下記に、より詳細に記載される。
【０１５８】
（１．Ｓｅｃｔｉｏｎ）
Ｓｅｃｔｉｏｎ １８１０におけるデータフォーマットは以下である：
Ｓ１，文書の第１のセクション
段落データ
第１のコンマで区切られるフィールドは、タグであり、以下の情報を含む：
１）「Ｓ」は、Ｓｅｃｔｉｏｎを始めるものとして行を識別する。
【０１５９】
２）タグに続く数は、そのＳｅｃｔｉｏｎがどんな種類のセクションであるかを知らせるタイプＩＤである。これらのタイプは、公知の特許セクションにマッピングされ、ユーザ定義セクション項目は、一意なタイプＩＤを与えられる。
【０１６０】
第２の共通の区切られるフィールドは、名前であり、以下の情報を含む：
１）セクションに与えられる名前（例えば、「発明の要旨」）。このフィールドは、既知の特許のタイプについてほとんどの場合、空であり（情報はタイプＩＤから判定され得る）、ユーザ定義文献テキスト項目についてのデータを含む。
【０１６１】
２）セクションは入れ子にされ得ないので、終了タグは必要ない。
【０１６２】
（２．Ｐａｒａｇｒａｐｈ）
Ｐａｒａｇｒａｐｈ １８１２におけるデータフォーマットは以下である：
Ｐ１
ラインデータ
第１のコンマで区切られるフィールドは、タグであり、以下の情報を含む：
１）「Ｐ」は段落を始めるものとして行を識別する。
【０１６３】
２）タグに続く数は、段落が表示される場合、ユーザにどんな種類の字下げであるかを知らせるタイプＩＤである。これらのタイプは、既知の特許識別スタイルにマッピングされ、ユーザ定義セクション項目は、一意なタイプＩＤを与えられる。ユーザ定義字下げスタイルは、ほとんどの場合、この文書のヘッダに定義される。
【０１６４】
３）セクションは、入れ子にされ得ないので終了タグは必要ない。
【０１６５】
（３．Ｌｉｎｅ）
Ｌｉｎｅ １８１４におけるデータのフォーマットは、単に、ファイル内の１つの行のテキストの行を構成する、テキスト項目である。
【０１６６】
＜テキストデータ＞＜テキストデータ＞＜テキストデータ＞
ＳＰＭＬファイル自身内の行が、行が始まり、終了する場合のマーカーであるので、開始タグまたは終了タグが必要ない。
【０１６７】
（４．Ｔｅｘｔ）
Ｔｅｘｔ １８０２におけるデータフォーマットは以下である：
＜Ｔ０，これはいくつかのテキストのサンプルである＞
第１のコンマで区切られるフィールドは、タグであり、以下の情報を含む：
１）「＜Ｔ」は、テキストを開始するものとして行を識別する。
【０１６８】
２）タグに続く数は、テキストがどのように表示されるかどうかを知らせるタイプＩＤである。これらのタイプは、既知の特許テキストスタイルにマッピングされ、ユーザ定義スタイルは、一意なタイプＩＤを与えられる。ユーザ定義テキストスタイル（例えば、ボールド イタリック １５ポイント Ａｒｉａｌ）は、ほとんどの場合、文書のヘッダに定義される。
【０１６９】
第２のコンマで区切られるフィールドは、データであり、以下の情報を含む：
１）実際のテキストデータを含むストリング
２）データのストリングの終了がタグ「＞」によりマークされる。文字「＞」がテキストデータの一部である必要がある場合、特別の文字（「〜＞〜」）として表されるべきである。
【０１７０】
（５．ＰａｇｅＢｒｅａｋ）
ＰａｇｅＢｒｅａｋ １８０４におけるデータフォーマットは以下である：
＜Ｇ＞
改ページを表すために、さらなる情報は必要ない。
【０１７１】
（６．ＶｅｒｔＳｐａｃｅ）
ＶｅｒｔＳｐａｃｅ １８０６におけるデータのフォーマットは以下である：
＜Ｖ高さ＞
これは２つの部分を含む：
１）これが縦スペースタグであることを特定するための「Ｖ」
２）高さを指定する数。１つの高さの単位がテキストの行の半分の高さに等しい。
【０１７２】
（７．ＳｐｅｃｉａｌＣｈａｒ）
テキスト配列の特殊文字に関するフォーマットは以下である：
〜ＤＥＬＴＡ〜
特殊文字のネームフィールドは「〜」によって囲まれ、以下の情報を含む：
１）特殊文字ネームを特殊文字コードにマッピングするアレイに対するルックアップ値を含むストリング。
【０１７３】
実施形態に従う本発明のフォーマットされた文書テキストの例示のフォーマットは、以下のとおりである：
Ｓ１，文書の第１セクション
Ｐ１
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
Ｐ１
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
＜Ｔ０，これは＞＜Ｔ１，サンプルである＞＜Ｔ０，いくつかの＞＜Ｔ２，様式の変更を有するテキスト。＞
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
Ｐ５
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
＜Ｔ０，これは、テキスト配列の中央にある特殊文字〜ＤＥＬＴＡ〜のサンプルである。＞
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
Ｓ４，文書の第２セクション
Ｐ２
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
Ｐ１
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
＜Ｔ０，これは＞＜Ｔ１，サンプルである＞＜Ｔ０，いくつかの＞＜Ｔ２，テキスト。＞
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
（Ｄ．本発明のストリーミング機構）
ストリーミングは、定常の連続的なストリームとして処理され得るようにデータを送信する技術である。大部分のユーザ（またはクライアント）が大量のマルチメディアファイルを迅速にダウンロードするための十分な速さのアクセスを有していないので、ストリーミング技術はインターネット１２０（図１）の発達とともに益々重要になってきている。ストリーミングを用いると、クライアントブラウザまたはプラグインは、全ファイルが送信される前にそのデータを表示することを開始することができる。
【０１７４】
仕事に対するストリーミングについては、データを受信するクライアント側はそのデータを収集し、そしてそれを定常ストリームとしてそのデータを処理し、それを音声または画像へ変換しているアプリケーションへ送信することができる必要がある。このことは、ストリーミング中のクライアントが要求したより迅速にデータを受信した場合、バッファに過剰なデータをセーブする必要があるということを意味する。しかし、データが十分に迅速に来ない場合、データの提示はスムーズではない。本発明は、提示機能２１５（図２）と関連して使用される２つの異なるストリーミング技術を提供する。
【０１７５】
上記のように、本発明の提示機能２１５はユーザに対する任意の出力のフォーマットを特定することを担う。本発明の実施形態では、提示機能２１５はＳＰＭＬ知的財産文書の出力をフォーマットするためにカスケーディング型シートを使用する。カスケーディング型シートは、ＣＬＡＳＳ属性を提供する。開発者らは、コンテンツの分類を反映するために、まさにフォーマットではないこのＣＬＡＳＳ属性を使用し得る。本発明はカスケーディング型シートのＣＬＡＳＳ属性とストリーミング技術とを合わせ、以下を含む２つのストリーミング機構を提供する：テンプレートベースストリーミング機構およびビジテーションベースストリーミング機構。これらの２つの機構は、メモリ中に入り、次いでそこから出てくるＳＰＭＬファイルを取得する方法をアドレス処理する。テンプレートベースストリーミング機構は、図１９を参照して最初に説明される。次に、本発明のビジテーションベースストリーミング機構は、図２０を参照して説明される。
【０１７６】
図１９を参照すると、ＤｏｃＣｏｍｐｏｎｅｎｔＳｔｒｅａｍｅｒ １９０２はＤｏｃＣｏｍｐｏｎｅｎｔ １９０４のクラスへのアダプタとして作用し（図１８もまた参照）、その結果ストリーミングの挙動はＤｏｃＣｏｍｐｏｎｅｎｔ １９０４のクラスの外へ移動し、そしてＤｏｃＣｏｍｐｏｎｅｎｔＳｔｒｅａｍｅｒ １９０２のクラスの中へ入る。これにより、ＤｏｃＣｏｍｐｏｎｅｎｔ １９０４は、そのＤｏｃＣｏｍｐｏｎｅｎｔ １９０４を適合させるように使用されるＤｏｃＣｏｍｐｏｎｅｎｔＳｔｒｅａｍｅｒ １９０２のタイプに基づくいくつかの異なる方法でストリーミングされることが可能となる。サンプルコードは以下のとおりである。
【０１７７】
ＤｏｃＣｏｍｐｏｎｅｎｔＳｔｒｅａｍｅｒストリーマ（ＤｏｃＣｏｍｐｏｎｅｎｔ）；
コート（ｃｏｕｔ）＜＜ストリーマ；
本発明のテンプレートベースストリーミング機構について、マクロが所望の異なるタイプのストリーミング毎に記載され得る。このストリーミングは、記載される必要がある文書要素のタイプ毎についてアダプタストリーマのように作用する。
【０１７８】
図２０を参照すると、本発明のビジテーションベースストリーミング機構がここで記載される。ＳｔｒｅａｍｉｎｇＶｉｓｉｔｏｒ ２００２のクラスはＤｏｃＣｏｍｐｏｎｅｎｔ ２００４のクラスの仮想的な方法によって受け入れられる（図１８もまた参照）。このことにより、ビジターがＤｏｃＣｏｍｐｏｎｅｎｔ ２００４を誘導されたタイプに充てる必要なしで正確な情報をストリーミングすることが可能となる。すべてのストリーミング挙動はＤｏｃＣｏｍｐｏｎｅｎｔ ２００４のクラスの外へ移動し、そしてＳｔｒｅａｍｉｎｇＶｉｓｉｔｏｒ ２００２のクラスの中へ入る。このことにより、ＤｏｃＣｏｍｐｏｎｅｎｔ ２００４が使用されるビジターのタイプに基づいたいくつかの異なる方法でストリーミングされることが可能となる。サンプルコードは以下のとおりである：
ＳｔｒｅａｍｉｎｇＶｉｓｉｔｏｒビジター（コート）；
ｃｏｍｐｏｎｅｎｔ．Ａｃｃｅｐｔ（ビジター）；
（Ｅ．本発明のアダプタクラス）
本発明の実施形態のＳＰＭＬ文書は、アダプタクラスの使用によって異なる役割に適合され得る。アダプタクラスの使用は多くの利益を提供し、これは以下を含む：ＳＰＭＬ文書を有する作業の種々の方法が含まれることが可能である；種々のインターフェイスが他の既存のインターフェイスに影響することなく本発明に加えることができる；膨れ上がった文書インターフェイスを防止する；ならびに、クライアントコードが、ＳＰＭＬ文書が果たす役割およびＳＰＭＬ文書が使用され得る方法を選択することが可能である。図２１は、同じＳＰＭＬ文書で異なるように働くために、アプリケーションが種々のアダプタを使用し得る方法の要約図を示す。
【０１７９】
図２１を参照すると、アプリケーション２１０２はアダプタ２１０６を使用して一つの方法でＳＰＭＬ文書２１１２とともに働き、そしてアダプタ２１０８を使用して異なる方法で同じＳＰＭＬ文書とともに働く。アプリケーション２１０４はアダプタ２１１０を使用してさらに異なる方法でアプリケーション２１０２と同じＳＰＭＬ文書２１１２とともに働く。同じＳＰＭＬ文書とともに異なるように働くために、どのようなアプリケーションが種々のアダプタを使用し得るかを示す具体的な図を次で説明する。
【０１８０】
図２２は、同じＳＰＭＬ文書とともに異なるように働くために、どのようなアプリケーションが種々のアダプタを使用し得るかを示す例示的の具体的な図である。図２２において、ＰａｇＴｏｏｌ ２２０２、ＰａｇｉｎａｔｏｒＩＤ ２２０４、ＤｏｃｕｍｅｎｔＲｅｐｏｓｉｔｏｒｙ ２２０６、ＩｍａｇｅＲｅｓｐｏｓｉｔｏｒｙ ２２０８、Ｐａｇｉｎａｔｏｒ ２２１０、Ｄｏｃｕｍｅｎｔ ２２１２、Ｃａｎｏｎｉｍａｇｅ ２２１４およびＳｔａｔｉｓｔｉｃ ２２１６が示される。ＰａｇＴｏｏｌ ２２０２は、ページネータがない時のドメインについてファサード（ｆａｃａｄｅ）として作用する。ＰａｇｉｎａｔｏｒＩＤは、ページネータを識別する。ＩＤはログインし、どんなスタティクス（ｓｔａｔｉｃｓ）を誰が発生させたかを決定するために使用される。ＤｏｃｕｍｅｎｔＲｅｐｏｓｉｔｏｒｙ ２２０６は、ＳＰＭＬファイルまたは文書が見つけられ得る位置を識別する。ＩｍａｇｅＲｅｓｐｏｓｉｔｏｒｙ ２２０８は、ＣＡＮファイルが見つけられ得る位置を識別する。Ｓｔａｔｉｓｔｉｃ ２２１６は、ページネータがログオン、ログオフし、ファイルを開け、ファイルをセーブし、またはファイルのページ付けを完了する時に関する情報を含む。Ｃａｎｏｎｉｍａｇｅ ２２１４は、フォーマット情報の基礎として作用する画像データを表す。Ｄｏｃｕｍｅｎｔ ２２１２は、フォーマット情報を有するテキストデータを含む。これはＣａｎｏｎｉｍａｇｅ ２２１４のテキスト版である。最終的に、Ｐａｇｉｎａｔｏｒ ２２１０は文書のフォーマット情報を変更する。Ｐａｇｉｎａｔｏｒ ２２１０は、ページ破損および行破損を挿入および／または削除し、図参照を編集し、そしてビブ（ｂｉｂ）ページの数を編集することができる。
【０１８１】
（ＸＩＩＩ．結論）
本発明の種々の実施形態を上記で説明してきたが、それらは例示の目的で示されたのであって、限定ではないことが理解されるべきである。形式および詳細における種々の変更が本発明の意図および範囲から逸脱することなく本明細書中でなされ得ることが関連分野の当業者に明らかである。このことは、後世に発展し得る関連分野の技術および条件の点において真実である。従って、本発明は、上記の例示の実施形態のいずれによっても限定されるべきではなく、特許請求の範囲およびそれらの均等物によってのみ規定されるべきである。
【図面の簡単な説明】
【図１】 図１は、本発明の実施形態に従う動作環境を表すブロック図である。
【図２】 図２は、本発明の実施形態に従うネットワークによって接続される本発明の機能またはモジュールのブロック図である。
【図３】 図３は、本発明の実施形態に従って、本発明を実施するために好適に使用されるコンピュータシステムのブロック図である。
【図４】 図４は、本発明の実施形態に従う例示的なＣＰＭＬ ＤＴＤを示すブロック図である。
【図５】 図５は、本発明の実施形態に従う例示的な特許ＤＴＤを示すブロック図である。
【図６】 図６は、本発明の実施形態に従って、クライアント間で伝送され得るＣＰＭＬ知的財産書類のいくつかのタイプを例示するフロー図である。
【図７Ａ】 図７Ａは、本発明の実施形態に従う例示的なＣＰＭＬ ＤＴＤを示す。
【図７Ｂ】 図７Ｂは、本発明の実施形態に従う例示的なＣＰＭＬ ＤＴＤを示す。
【図７Ｃ】 図７Ｃは、本発明の実施形態に従う例示的なＣＰＭＬ ＤＴＤを示す。
【図７Ｄ】 図７Ｄは、本発明の実施形態に従う例示的なＣＰＭＬ ＤＴＤを示す。
【図７Ｅ】 図７Ｅは、本発明の実施形態に従う例示的なＣＰＭＬ ＤＴＤを示す。
【図８Ａ】 図８Ａは、本発明の実施形態に従う米国特許に対する例示的なＣＰＭＬ知的財産書類を示す。
【図８Ｂ】 図８Ｂは、本発明の実施形態に従う米国特許に対する例示的なＣＰＭＬ知的財産書類を示す。
【図８Ｃ】 図８Ｃは、本発明の実施形態に従う米国特許に対する例示的なＣＰＭＬ知的財産書類を示す。
【図８Ｄ】 図８Ｄは、本発明の実施形態に従う米国特許に対する例示的なＣＰＭＬ知的財産書類を示す。
【図８Ｅ】 図８Ｅは、本発明の実施形態に従う米国特許に対する例示的なＣＰＭＬ知的財産書類を示す。
【図８Ｆ】 図８Ｆは、本発明の実施形態に従う米国特許に対する例示的なＣＰＭＬ知的財産書類を示す。
【図９Ａ】 図９Ａは、本発明の実施形態に従うヨーロッパ特許出願に対する例示的なＣＭＰＬ知的財産書類を示す。
【図９Ｂ】 図９Ｂは、本発明の実施形態に従うヨーロッパ特許出願に対する例示的なＣＭＰＬ知的財産書類を示す。
【図９Ｃ】 図９Ｃは、本発明の実施形態に従うヨーロッパ特許出願に対する例示的なＣＭＰＬ知的財産書類を示す。
【図９Ｄ】 図９Ｄは、本発明の実施形態に従うヨーロッパ特許出願に対する例示的なＣＭＰＬ知的財産書類を示す。
【図９Ｅ】 図９Ｅは、本発明の実施形態に従うヨーロッパ特許出願に対する例示的なＣＭＰＬ知的財産書類を示す。
【図９Ｆ】 図９Ｆは、本発明の実施形態に従うヨーロッパ特許出願に対する例示的なＣＭＰＬ知的財産書類を示す。
【図９Ｇ】 図９Ｇは、本発明の実施形態に従うヨーロッパ特許出願に対する例示的なＣＭＰＬ知的財産書類を示す。
【図１０Ａ】 図１０Ａは、本発明の実施形態に従うＣＰＭＬ ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｂ】 図１０Ｂは、本発明の実施形態に従うＣＰＭＬ ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｃ】 図１０Ｃは、本発明の実施形態に従うＣＰＭＬ ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｄ】 図１０Ｄは、本発明の実施形態に従うＣＰＭＬ ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｅ】 図１０Ｅは、本発明の実施形態に従うＣＰＭＬ ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｆ】 図１０Ｆは、本発明の実施形態に従うＣＰＭＬ ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｇ】 図１０Ｇは、本発明の実施形態に従うＣＰＭＬ ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｈ】 図１０Ｈは、本発明の実施形態に従うＣＰＭＬ ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｉ】 図１０Ｉは、本発明の実施形態に従うＣＰＭＬ ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｊ】 図１０Ｊは、本発明の実施形態に従う図１０Ａ〜１０Ｉの位置付けを例示する。
【図１１】 図１１は、本発明の実施形態に従う知的財産プロトコルシステムの機能をハイレベルで動作してる１例を示す。
【図１２】 図１２は、本発明の実施形態に従う図１１のステップをさらに詳細に示す。
【図１３】 図１３は、本発明の実施形態に従う図１１のステップをさらに詳細に示す。
【図１４】 図１４は、本発明の実施形態に従うクライアントの情報の自動更新を例示する。
【図１５】 図１５は、本発明の実施形態に従う図１４に対応する平行トレース図である。
【図１６】 図１６は、本発明の実施形態に従って、どのようにＩＰＡＭサーバがＸＭＬ書類および非ＸＭＬ書類（例えば、ＥＱＶ）書類と共に動作するかを示す。
【図１７Ａ】 図１７Ａは、本発明がどのように本発明の実施形態に従う電子データ書類の順序およびダウンロードプロトコルＤＴＤを支援するかを例示する。
【図１７Ｂ】 図１７Ｂは、本発明がどのように本発明の実施形態に従う電子データ書類の順序およびダウンロードプロトコルＤＴＤを支援するかを例示する。
【図１７Ｃ】 図１７Ｃは、本発明がどのように本発明の実施形態に従う電子データ書類の順序およびダウンロードプロトコルＤＴＤを支援するかを例示する。
【図１８Ａ】 図１８Ａは、本発明の実施形態に従って本発明のＳＰＭＬに使用されるモデルを例示する。
【図１８Ｂ】 図１８Ａは、本発明の実施形態に従って本発明のＳＰＭＬに使用されるモデルを例示する。
【図１９】 図１９は、本発明の実施形態に従う本発明のテンプレートベースのストリーミング機構を例示する。
【図２０】 図２０は、本発明の実施形態に従う本発明の訪問（ｖｉｓｉｔａｔｉｏｎ）ベースのストリーミング機構を例示する。
【図２１】 図２１は、本発明の実施形態に従って、出願人（ａｐｐｌｉｃａｔｉｏｎ）がどのように異なるアダプタを使用して本発明の同じＳＰＭＬ書類を異なって処理し得るかについての模式図を示す。
【図２２】 図２２は、本発明の実施形態に従って、出願人（ａｐｐｌｉｃａｔｉｏｎ）がどのように異なるアダプタを使用して本発明の同じＳＰＭＬ書類を異なって処理し得るかについての具体的な図を示す。[0001]
(Background of the Invention)
(Field of Invention)
The present invention relates generally to data processing tools, and more particularly to an intellectual property protocol for defining data exchange rules and formats for general purpose intellectual property data objects such as documents.
[0002]
(Related technology)
Intellectual property documents include patents (in the US and other foreign countries), patent applications (in the US, PCT and other foreign countries), trademarks (in the US and other foreign countries), and (in the US and other foreign countries) It may include trademark applications, copyrights, trade secrets, license agreements, joint venture establishment agreements, or any other type of data object including intellectual property rights. Efficient management of intellectual property documents requires a structured way of exchanging data representing one or more of these intellectual property documents and / or systems and their associated processes. These processes include: license tracking; audit and payment; patent and trademark practices and workflow; patent and trademark pension payment tracking and reporting; intellectual property metadata reporting and Visualization; including electronic submission of patent applications and trademark applications. Prior to the present invention, there was no structured way to exchange data.
[0003]
Individuals and / or industries that handle intellectual property documents (or are included in the field of intellectual property) consist of many different players. For example, one player is the US Patent and Trademark Office, another player is the European Patent Office, another player is the integrated operations manager, another player is the patent applicant, and another player is the patent or trademark licensee. Etc. These players may be independent of each other, but may have to work together to facilitate the purpose. For example, a patent applicant needs to interact with the United States Patent and Trademark Office, thereby completing his patent application and / or trademark application procedures. It is advantageous for players to use electronic data versions of one or more intellectual property data objects or intellectual property documents when two or more players work together to facilitate the purpose. However, this often does not happen due to the lack of data exchange rules and formats for intellectual property data objects. In the absence of standard rules for data exchange rules and formats for intellectual property data objects, it is often impeded to proceed with a player's common objectives.
[0004]
Cooperation between players in the field of intellectual property is impeded. This is because players often use different formats for intellectual property documents. Today, because the industry is computerized and many different players in the field of intellectual property use the Internet, the use of different formats of intellectual property documents makes electronic data intellectual property between different players. ) Prevent efficient exchange of documents.
[0005]
Therefore, what is needed is an intellectual property protocol that defines data exchange rules and formats for general purpose intellectual property documents, thereby increasing the effectiveness and efficiency of exchanging intellectual property data objects in electronic data. In addition, the protocol is flexible enough to allow other types of functions (but not limited to) such as managing intellectual property transaction data for various work processes. In order to have enough function. The present invention provides a standard for intellectual property metadata and provides an effective and efficient method for exchanging data between individual intellectual property software systems and integrated business (EPR) systems.
[0006]
(Summary of the Invention)
The present invention relates to an intellectual property protocol for defining data exchange rules and formats for general purpose intellectual property data objects, and systems, methods and computer program products associated with the intellectual property protocol. The present invention includes an intellectual property protocol system that functions as an engine by defining data exchange rules and formats for general purpose intellectual property documents. The present invention also includes a front-end system that suitably provides a graphical user interface to the user of the present invention for accessing the intellectual property protocol system. The present invention may also include an intellectual property database storing a collection of intellectual property documents (and information related to intellectual property documents), one or more embodiments of intellectual property protocols, and the like. The intellectual property protocol system interacts with an intellectual property right manager (IPAM) server 105 as described below.
[0007]
Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, are described in detail below with reference to the accompanying drawings. In the drawings, like reference numbers generally indicate identical, functionally similar, and / or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit in the corresponding reference number.
[0008]
The present invention will be described with reference to the accompanying drawings.
[0009]
(Detailed description of preferred embodiments)
(I. Summary of the Invention)
The present invention includes an intellectual property protocol that enables the definition of data and format of intellectual property documents, thereby facilitating efficient exchange of electronic intellectual property documents between different systems. The present invention is shown in FIG. 1 and will be described in detail below with an Intelligent Property Asset Manager (IPAM) server 105, an intellectual property protocol system 110, a front-end system 113, and The intellectual property database 135 is intended.
[0010]
(II. System architecture)
(A. Overview of system architecture)
FIG. 1 is a block diagram showing an example of the operating environment of the present invention. It should be understood that the operating environment of the example of FIG. 1 is shown for illustrative purposes only and does not limit the invention. Other embodiments of the operating environment described herein will be apparent to those skilled in the art based on the teachings contained herein, and the invention is directed to such other embodiments. FIG. 1 illustrates an IPAM server 105, an intellectual property protocol system 110, a front end system 113, an intellectual property database 135, a wide area Internet 120 or other communication medium, a government agency 115, one or more intellectual property document licensors 125, 6 illustrates an example environment that includes and / or one or more EPR systems 140.
[0011]
As described below with reference to FIG. 3, IPAM server 105, intellectual property protocol system 110, front end system 113, and intellectual property database 135 may be implemented using hardware, software, or a combination thereof. And can be implemented in one or more computer systems or one or more processing systems. The intellectual property protocol system 110 is described next.
[0012]
The intellectual property protocol system 110 operates as an engine for the present invention in the standardization of intellectual property documents. The intellectual property protocol system 110 is connected to the IPAM server 105 and the intellectual property database 135. The intellectual property protocol system 110 is also connected to the Internet 120 via the front end system 113. A request from a user can be made to the intellectual property protocol system 110 via the front-end system 113. The various functions provided by the present invention are independent of the data source. Although the embodiment of the present invention shown in FIG. 1 describes the IPAM server 105, the intellectual property protocol system 110, the front end system 113, and the intellectual property database 135 as separate functional components, some (or all) These components can be combined as long as the function of each component still exists within the present invention, as described below. The IPAM server 105 will be described next.
[0013]
For convenience, the IPAM server 105 is briefly described herein, but the invention is not limited to this brief description. In brief, the IPAM server 105 handles context data processing. The IPAM server 105 can be used to define and select one or more contexts. Each context includes one or more attributes and a plurality of data objects that satisfy the attributes. A list of data objects included in the selected context may be displayed. At least some of the data objects in the selected context may be processed. Such processing includes generating a hierarchical and / or oriented non-annular graph data structure to represent relationships between data objects. These data structures can then be displayed in a variety of well-known techniques, including but not limited to hyperbolic trees. Examples of such hierarchical or oriented acyclic graph structures include claim trees, citation trees, and data object families, which can be displayed using a hyperbolic tree.
[0014]
In one embodiment, the context is a group. In other embodiments, each context is associated with a data object type. In this latter embodiment, the context includes data objects of the respective data object type.
[0015]
The IPAM server 105 further supports annotation generation. The IPAM server 105 supports multiple annotation types including document annotation, group annotation, data object type annotation, case annotation, and enterprise annotation. The IPAM server 105 also supports annotations based on format.
[0016]
In one embodiment, the IPAM server 105 has a plug-in manager that is coupled to the IPAM server 105. The system shown in FIG. 1 may also include at least one plug-in coupled to the plug-in manager and at least one external data processing component coupled to the plug-in. In one embodiment, the external data processing component displays the data using at least a graph. In another embodiment, the external data processing component displays data using at least a map. The plug-in manager has a first application programming interface (API) and each external data processing component has a second API. The plug-in converts the message from the plug-in manager to the external data processing component, and to a format compatible with the second API, from the external data processing component to the plug-in manager, and into a format compatible with the first API. Translate the message.
[0017]
Embodiments of the IPAM server 105 may process and display a patent equivalent text file (EQV) and otherwise operate with a patent equivalent text file. (Other embodiments of the IPAM server 105 work with other data types.) Patent equivalent text files are described in US Pat. No. 5,623,681, which is hereby incorporated by reference in its entirety. Incorporate. The patent equivalent text file includes equivalence information that establishes an equivalence relationship between the text in the patent equivalent text file and the image in the patent image file. For example, this equivalence information allows pagination that allows a patent equivalent text file to be displayed with the same pagination (line breaks, column breaks, page breaks) as the patent image file. Information can be included. In one embodiment, the pagination module generates a patent equivalent text file by comparing patent text in a patent text file with a patent image file and detecting equivalence information. This uniformity information is then embedded in the patent equivalent text file along with the patent text. The pagination module may automatically perform pagination operations, but in some cases some manual intervention is required. Thus, an operator may be involved in a pagination process that is sometimes performed by a pagination module. The front end system 113 of the present invention will be described next.
[0018]
The front-end system 113 can operate as a web server. The web server provides a GUI to users who wish to access the intellectual property protocol system 110. As is well known in the art, a web server is a server process running on a website that sends web pages in response to hypertext transfer protocol (HTTP) requests from a remote browser. An optional firewall (not shown) serves as a connection and disconnection between the intellectual property protocol system 110 and the wide area Internet 120. In general, firewalls well known in the art are dedicated gateway machines with special security alert software. Firewalls are typically used, for example, to service Internet 120 connections and dial-in lines, and protect the more loosely managed machine groups hidden behind firewalls from outside intrusions. The intellectual property database 135 of the present invention is described next.
[0019]
Intellectual property database 135 stores a collection of data representing current embodiments, such as intellectual property protocols, intellectual property documents, and processes used by the present invention. In this regard, in one embodiment, the data stored in the intellectual property database 135 can be stored as a relational database. In a relational database, data is stored in the form of related tables. A relational database management system (DBMS) is used to manipulate data in related tables. Relational databases are powerful because they require few assumptions about how the data is associated with the database or how the data is extracted from the database. As a result, the same database can be viewed in many different ways. An important feature of relational systems is that a single database can extend beyond several tables. This is different from a flat file database in which each database is contained in one table.
[0020]
Another embodiment of this type of database used by the intellectual property database 135 is a database design known as hypertext. In a hypertext database, any object can be linked to any other object, whether it is text, an image, or a film. Hypertext databases are particularly useful for collecting large amounts of completely different information. However, hypertext databases are generally not designed for numerical analysis.
[0021]
The intellectual property database 135 of the present invention can also be implemented using standard database access methods such as Open Database Connectivity (OBBC). The goal of ODBC is to allow access to any data from any application, regardless of which DBMS is processing the data. ODBC manages this by inserting an intermediate layer called a database driver between the application and the DBMS. The purpose of this layer is to translate application data queries into commands that the DBMS understands. In order for this to work, both the application and the DBMS must be ODBC compliant. That is, the application must be capable of issuing an ODBC command, and the DBMS must be capable of responding to the command. Both the IPAM server 105 engine and intellectual property protocol system 110 functions, as well as the data stored in the intellectual property database 135, are described in further detail below. The wide area Internet 120 is described next.
[0022]
Wide area Internet 120 allows users of Internet 120 (eg, players in an intellectual property domain) to remotely access and use intellectual property protocol system 110 (via front-end system 113). A plurality of external workstations (eg, a government agency 115, an intellectual property document licensor 125, and an ERP system 140, as shown in the embodiment of FIG. 1). The present invention provides these external workstations via communication methods other than the Internet 120 (via Transmission Control Protocol / Internet Protocol (TCP / IP)), including but not limited to asynchronous dial-up and asynchronous lease lines. Note that it can communicate with. Asynchronous dialup, asynchronous lease line, and TCP / IP communication are terms well known in the art. The government agency 115 and the intellectual property document licensor 125 will be described below.
[0023]
Government agencies 115 include the US Patent and Trademark Office, foreign patent and trademark offices, and government agencies in the intellectual property domain. Intellectual property document licensor 125 includes business entities or individuals who authorize the use of intellectual property documents. An ERP (Enterprise Resource Planning) system 140 is described next.
[0024]
The ERP system 140 integrates many aspects of the business including planning, manufacturing, sales and marketing. As ERP methods have become more prevalent, software applications have emerged and have helped business managers implement ERP. Often ERP includes the need to send and receive electronic intellectual property documents with intellectual property documents and entirely different intellectual property software systems.
[0025]
FIG. 2 is a block diagram of the functions or modules of the intellectual property protocol system 110 that are preferably connected by a network according to one embodiment of the invention. It should be understood that the particular intellectual property protocol system of FIG. 2 is shown for illustrative purposes only and does not limit the invention. Other embodiments for performing the functions described herein will be apparent to those skilled in the art based on the teachings contained herein, and the invention is directed to such other embodiments. As will be apparent to those skilled in the art, all of the “inside” functions of intellectual property protocol system 110 are preferably connected and communicated via a communication medium such as network 220.
[0026]
The topology of the network 220 shown in FIG. 2 is called a bus topology. The topology of a network is generally the geometry of functions (ie, computers) within the system. Other common types of network topologies include star topologies and ring topologies. Although the present invention is shown in FIG. 2 with a bus topology incorporated, the present invention is equally applicable to other topologies.
[0027]
The intellectual property protocol system 110 includes an intellectual property protocol function 205, an intellectual property data and processing exchange function 210, a presentation function 215, and a management function 230. The present invention is not limited to these functions. The functionality of the intellectual property protocol system 110 shown in FIG. 2 is described in detail below in Section VIII after the description of the intellectual property protocol embodiment of the present invention.
[0028]
(B. Embodiment of the present invention)
The present invention (ie, IPAM server 105, intellectual property protocol system 110, front end system 113, intellectual property database 135, or all parts thereof) is implemented using hardware, software, or a combination thereof. Can be implemented in one or more computer systems or other processing systems. Indeed, in one embodiment, the present invention relates to one or more computer systems that can perform the functions described herein. One embodiment of a computer system 300 is shown in FIG. Computer system 300 includes one or more processors, such as processor 303. The processor 303 is connected to the communication bus 302. Various embodiments of the software are described with respect to this exemplary computer system. After reading this description, it will be apparent to a person skilled in the art how to implement the invention using other computer systems and / or computer architectures.
[0029]
Computer system 300 also includes a main memory 305, preferably random access memory (RAM), and may also include a secondary memory 310. Secondary memory 310 may include, for example, a hard disk drive 312 and / or a removable storage drive 314 representing a floppy disk drive, magnetic tape drive, optical disk drive, and the like. The removable storage drive 314 reads from and / or writes to the removable storage unit 318 in a well-known manner. The removable storage unit 318 represents a floppy disk, magnetic tape, optical disk, etc., which are read by the removable storage drive 314 and written to the removable storage drive 314. As will be appreciated, the removable storage unit 318 includes a computer usable storage medium that stores computer software and / or data.
[0030]
In another embodiment, secondary memory 310 may include other similar means that allow computer programs or other commands to be loaded into computer system 300. Such means may include, for example, a removable storage unit 322 and an interface 320. Examples of such are program cartridges and cartridge interfaces (such as those found in video game devices), removable memory chips and attached sockets (such as EPROM or PROM), and software and data from the removable storage unit 322 to the computer system 300. Other removable storage units 322 and computer interface 320 that can be transmitted may be included.
[0031]
Computer system 300 may also include a communication interface 324. Communication interface 324 allows software and data to be transmitted between computer system 300 and external devices. Examples of communication interface 324 may include a modem, a network interface (such as an Ethernet card), a communication port, a PCMCIA slot, a card, and the like. Software and data transmitted over the communication interface 324 are in the form of signals 328 that can be electronic, electromagnetic, optical, or other signals that can be received by the communication interface 324. These signals 328 are provided to the communication interface 324 via a communication path (ie, channel) 326. This channel 326 carries signal 328 and may be implemented using wires or cables, optical fibers, telephone lines, cell phone links, RF links, and other communication channels.
[0032]
As used herein, the term “computer program product” refers to the removable storage units 318, 322 and / or the signal 328. These computer program products are means for providing software and / or data to the computer system 300. The present invention is directed to such a computer program product.
[0033]
Computer programs (also called computer control logic) are stored in main memory 305 and / or secondary memory 310 and / or in computer program products. Computer programs may also be received via communication interface 324. Such a computer program, when executed, enables the computer system 300 to perform the features of the present invention as described herein. In particular, the computer program, when executed, enables the processor 303 to perform the features of the present invention. Accordingly, such a computer program represents a controller of computer system 300.
[0034]
In one embodiment in which the invention is implemented using software, the software is stored in a computer program product using the removable storage drive 314, the hard drive 312, or the communication interface 324, and to the computer system 300. Can be loaded. Control logic (software), when executed by the processor 303, causes the processor 303 to perform the functions of the present invention as described herein.
[0035]
In another embodiment, the invention is implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs). Embodiments of a hardware state machine for performing the functions described herein will be apparent to those skilled in the art.
[0036]
In yet another embodiment, the present invention is implemented using a combination of both hardware and software.
[0037]
One embodiment of the intellectual property protocol of the present invention is described next.
[0038]
(III. CPML DTD according to one embodiment of the invention)
As described above, the intellectual property database 135 stores data objects that conform to one or more embodiments of the intellectual property protocol of the present invention. In one embodiment of the invention, the generic intellectual property protocol is implemented as a comprehensive patent markup language (CPML) document type definition (DTD) that is compliant with the extended markup language (XML). Here, a document conforming to the CPML DTD is called a CPML document, or sometimes a general-purpose intellectual property document (above). As these names indicate, the CPML DTD of the present invention is very powerful and can be used for many functions. This is described below with reference to FIG.
[0039]
In essence, CPML DTD is an XML intellectual property protocol that specifies data rules and formats for intellectual property management. This is very different from, for example, CML for USPTO staff specification (Red Book specification) and document presentation. In some embodiments, the CPML DTD includes these DTDs in its application. Both DTD and XML are well known in the art and related arts, but a brief overview of DTD and XML is given below.
[0040]
As discussed above, the computer program at run time allows the computer 300 (FIG. 3) to perform the functions of the present invention as discussed herein. In one embodiment, the present invention is implemented using active server pages, XML and stored procedures. XML is a presentation markup language and is used as a data description language. XML is a pared-down version of SGML and is specifically designed for web documents. XML allows designers to create their own customized unique tags and provide functions not available in HTML. For example, XML supports links that point to multiple documents, whereas HTML links can each refer to only one destination.
[0041]
A tag is a command or marker that is inserted into a document that specifies how the document or part of the document should be formatted. Tags are used by format specifications that store documents as text files. This includes SGML and HTML. Thus, in one embodiment of the present invention, the designer implements each of the intellectual property protocol function 205 functions as tags.
[0042]
The file types associated with SGML and XML documents are called document type definitions or DTDs. DTD is a file type that defines how tags should be interpreted by the application that presents the document. The HTML specification that defines how a web page should be displayed by a web browser is an example of a DTD. In essence, the DTD for the present invention displays contracts between those skilled in the art in an intellectual property domain in which the intellectual property document conforms to a specific standard. The CPML DTD of the present invention will now be described in more detail with reference to FIG.
[0043]
FIG. 4 conceptually illustrates a comprehensive patent markup language (CPML) DTD 402 according to an embodiment of the present invention. CPML DTD 402 includes a plurality of other DTDs. Alternatively, the components of the CPML DTD 402 shown in FIG. 4 may be grouped together as one or more separate DTDs. Preferably, the DTD of FIG. 4 conforms to XML, but the present invention is not limited to this embodiment.
[0044]
CPML DTD 402 includes one or more patents DTD 403. These patents DTD403 represent patent documents. As shown in FIG. 5, patent DTD 403 is described in USPTO staff record DTD504 (USPTO staff record specification published by USPTO, dated March 1998), the entirety of which is incorporated herein by reference. Incorporated) and / or may include or represent other patent office patent DTDs such as PCT or EPO DTD506. Patent DTD 403 may also include or represent information contained in Patent Equivalent Text File (EQV) 502 (above).
[0045]
CPML DTD 402 includes DTD 404 to support and represent other IP (Intellectual Property Rights) such as trademarks, trade secrets, copyrights, conceptual documents, and the like.
[0046]
CPML DTD 402 includes DTD 406 to represent USPTO and / or other patent office procedures.
[0047]
CPML DTD 402 includes DTD 408 to represent and support patent licensing, tracking, auditing, payments, and the like.
[0048]
CPML DTD 402 includes DTD 410 to represent and support any type of paperwork.
[0049]
CPML DTD 402 includes DTD 412 to represent and support annotations and annotation exchanges.
[0050]
CPML DTD 402 includes DTD 414 to represent and support reporting and reporting work.
[0051]
CPML DTD 402 is not limited to the functions shown in FIG. The example of FIG. 4 is provided for illustrative purposes only.
[0052]
FIG. 6 illustrates various types of CPML intellectual property documents (conforming to CPML DTD 402) that can be exchanged between two parties or two clients in the intellectual property domain. Next, various features of the CPML DTD of the present invention will be described.
[0053]
(A. CPML DTD is a combination of structured document data recognized and supplied by an IPAM server embodiment)
The CPML DTD specification includes a combination of structured literature data used by embodiments of the IPAM server 105. In an embodiment, this data includes a sub-table of the IP_DOCUMENT table, a satellite in the IPAM server database, and a summary in the search database (index). This ensures that the IPAM server 105 can exclusively extract the necessary data from the XML, and this may be the case even if there is no index and database flatfiles production supplies.
[0054]
(B. CPML DTD supports additional structures)
When the normalization of input data varies, the CPML DTD has a section for unnormalized data and repeats the data in a normalized format as necessary. The normalized version is arbitrary. For example,
[0055]
[Table 1]

This policy ensures that the application using the data has a level of normalization that can be supported and that the data has the highest level of normalization that we can supply.
[0056]
(C. CPML DTD uses an easy-to-read convention of naming for ISO standard codes and tags)
Standards are used whenever possible, as shown in the example in section (b) above. For example, “US” is an ISO standard code for the United States, and “CA” is an ISO standard code for California.
[0057]
Conventional naming methods for tags are relatively readable and preferably include long names. The disk space occupied by the name is not much compared to the image storage device. Having a readable name allows a human to manipulate the document. A legible name makes it easy to explain the CPML DTD to a third party.
[0058]
(D. EQV format can be exchanged with CPML DTD at IPAM server)
Preferably, the IPAM server 105 receives the XML intellectual property document as an electronic document.
[0059]
The XML intellectual property document is stored in the same way that the patent equivalent text file is stored, and is delivered to the IPAM server 105 in the same way that the patent equivalent text file is delivered to the IPAM server 105. Changes to the IPAM server 105 include:
[0060]
* The IPAM server 105 must recognize XML as a format corresponding to the EQV format, and return an XML intellectual property document when requested.
[0061]
* The IPAM server 105 has a new command requesting a specific intellectual property document XML.
[0062]
* The domain has a new data path for passing XML format documents, just as it had a data path for passing EQV format documents. Alternatively, in order to save the user interface duplication and to eliminate some complexity of the annotation subsystem, the domain sends the XML formatted document to EQV before passing it to the IPAM server 105 user interface. Can be converted to a formatted file.
[0063]
* The user interface of the IPAM server 105 displays the document appropriately.
[0064]
* All annotation subsystems can handle annotating in XML documents rather than image or EQV documents.
[0065]
The present invention includes tools that accomplish the following tasks: The task of translating all input data into XML, the task of merging different data for a specific document into one XML document, the task of tracking changes and version documents, the set of XML to index and database Includes the task of creating a flat file, as well as the task of converting an XML format document into a backward compatible EQV format document.
[0066]
(E. CPML DTD maintains a practical amount of information including chemicals, tables and mathematical information present in the original document)
The original structured data can be retained for later use by “avoiding” the data (eg, commenting on or wrapping it in a processing instruction), but “avoiding” itself is further processed. It does not promote. In order to process that information, it must be placed in a semantic context understood by the software being processed. Rather than having the software being processed understand all the original formats, the original format should be translated into one format.
[0067]
(F. CPML DTD includes an IPAM server interface for accessing groups and annotations via the XML interface)
The XML and CPML DTDs of the present invention are also useful as output formats for the IPAM server 105. XML provides a platform-independent structured content format. Groups, documents and annotations can be output by the IPAM server 105.
[0068]
An annotation includes several optional flags and annotation segments. An annotation segment has a “start” anchor, an “end anchor”, and predetermined content that may be embedded in or indicated by the annotation. An annotation may also refer to a group or owner. A possible XML format is shown below.
[0069]
[Table 2]

Groups include annotations, documents, and other groups. The group refers to the parent. Annotations can be referenced or embedded directly within a group. A possible XML format is shown below.
[0070]
[Table 3]

The CPML DTD of the present invention gives this data “its own life”. For example, a person may send an annotation to a colleague and the colleague may view it using an email reader (with an appropriate XML plug-in for the email reader). If a coworker wants a group context, the coworker follows a “group” link that sends a request to WorkBench.
[0071]
(G. CPML DTD includes a set of XML interfaces for third-party content managers, thereby allowing users to use the content manager later via IPAM)
XML can be used as a back-end interface to hook into third party search engines and document servers. The IPAM server 105 needs to use an interface to access the central search server. If the interface is in XML and is relatively generic, it provides a platform independent standard.
[0072]
(H.CPML DTD provides claims structure support)
The CPML DTD embodiment has structured claim information. The claim structure has (1) a claim number, (2) independent claim information, (3) a preamble with optional subordinate clauses, and (4) a body with many elements. CPML DTD supports various amounts of structures listed above. One example of a CPML DTD will now be discussed with reference to FIGS.
[0073]
IV. Example of CPML DTD according to one embodiment of the invention
One example of a CPML DTD 702 is shown in FIGS. According to one embodiment of the present invention, the goal of CPML DTD 702 is to include text structures and bibliographic tags in the IPAM server database and index. How the CPML DTD 702 relates to the data in the IPAM server database and index is described below with reference to FIGS. The present invention is not limited to CPML DTD702. The examples of FIGS. 7A-7C are provided for illustrative purposes only and are not limited thereto. Other DTDs will be apparent to those skilled in the art based on the teachings contained herein.
[0074]
In the CPML document, patent information and sections are stored in respective tags of CPML DTD 702.
[0075]
CPML DTD 702 is described below.
[0076]
To assist in understanding the CPML DTD 702 example, the following three tables are provided, including Tables 1-3. Table 1 shows some common symbols along with their descriptions for specifying the element structure in DTD.
[0077]
[Table 4]

Table 2 below shows some common attribute types in DTD along with their descriptions.
[0078]
[Table 5]

Table 3, the last table, shows the default values of the attributes along with their descriptions.
[0079]
[Table 6]

The CPML DTD 702 example preferably includes a separate section for a distinct portion of each document. Referring to FIG. 7A, label 703 shows an element list (ELEMENT) grouped together to create a CPML DTD 702. From Table 1 above, it can be seen that parentheses group elements. Thus, the elements or sections that make up “patent” include “Bibiography”, “Abstract”, “Unstructured Bibography”, “BriefSummaryOfInvention”, “DescriptionOfDrawings”, “des”, “des”, and “des”. As can be seen from Table 1, since a comma separates each of these elements, an element is required to appear in the specified sequence. Therefore, the “Bibiography” element must appear first. The next in this order is the “Abstract” element. CPML DTD 702 represents that the “abstract” element is distinguished from the “Biography” element. In another embodiment of the present invention, the “Abstract” element may be inside the “Bibiography” element. Since there are no symbols after the “Biography” or “Abstract” element, these elements appear only once.
[0080]
Note that the next three elements of this order (“UnstructuredBiography”, “BriefSummaryOfInvention” and “DescriptionDescriptionOfDrawings”) each end with a question mark. From Table 1, this indicates that each of these elements can only appear once as needed. The next in this order is “DescriptionOfInvention” that needs to appear once. The four preceding elements or sections are considered to be patent text sections. Note that the embodiment of FIGS. 7A-7C can be facilitated to 5, 10, or any number, while showing four text sections.
[0081]
Finally, there is a mandatory "claim" element that must appear once.
[0082]
Referring also to FIG. 7A, label 704 shows an attribute list (ATTLIST) that is typically associated with a value for each attribute. The illustrated attributes include “MajorVer”, “MinorVer”, and “GUID”. For example, the attribute “MajorVer” may have the values 0, 1, 2, etc., but must have one of the listed values. #REQUIRED (Table 3) is an attribute default that indicates to the parser that the attribute “MajorVer” must have a value in all instances of the element. If this attribute is not included, a parsing error occurs. The attribute “MinorVer” is defined in the same manner as “MajorVer”. The attribute “GUID” must have a unique value that identifies the element (indicated by the ID for Table 2). Again, #REQUIRED indicates that “GUID” must have a value in all instances of the element.
[0083]
Label 705 indicates a list of normalized tags. In this embodiment of the invention, the normalized tags are a common set of tags that appear in many places. When these normalized tags appear, we promise to normalize certain data. Normalized tags include tags for date (Date), publishing organization (PubOrg), document type (Kind), number (Num), and country (Cntry). In particular, Date is always in the form YYYYMMDD, PubOrg only allows tags found in WIPO Standard 3, Kind follows the specified convention of naming, Num is always purely numeric, and Cntry is an ISO designation. Only the country is allowed.
[0084]
Label 706 shows a list of common tags and entities. In this embodiment of the invention, common tags appear more than once, but are not normalized. This element specifies the format for the text, such as a paragraph in CPML DTD702.
[0085]
A label 707 indicates a list of patent document tags. This embodiment supports different classifications of literature tags. That is, an identifier useful for identifying a document by an identifier, a reference to another document, a legal item, a classification, and other miscellaneous information. These literature classifications are organized as follows.
[0086]
Literature data
Identifier (ie, data that helps distinguish this document from others)
title
Opening and examination organizations (EPO, USPTO, etc.)
Document type (application, patent, reissue)
Public number (document-specific number)
application number
Summary (with or without typical or indicative figures)
References to other documents
Cited references
Citations cited by examiners (subsets of citations from regular search reports)
Cited references cited by the applicant (typically embedded in unique documents)
Patent family
Patent application
Related applications
Related assigned patents
Foreign applications whose priority is transferred under the Paris Convention
Priority application
Priority claim date
Priority country
PCT international patent applications that transfer priority under the Patent Cooperation Treaty
Legal item
Inventor
Assignee
Legal representative of the inventor or assignee (who, which company, etc.)
Patent examiner
Designated country
Relevant date (submission date, publication date, issuance or transfer date if any, and reissue)
Day)
Document classification
Domestic
International (International Patent Classification, usually IPC editions are also listed)
These categories are used for convenience purposes only. The present invention is not limited to this example.
[0087]
Some embodiments of the CPML DTD may have all of these literature fields, and other DTD embodiments may have a subset of the fields. In the example of FIGS. 7A-7C, the literature tags are organized as follows. That is, general information 707, identifier 708, reference 709 to other documents, legal item 710 (ie, data that strengthens the assignee's rights to monopoly), classification 711, and other miscellaneous information 712.
[0088]
Referring to label 707, a document tag related to general information is illustrated. From Table 1 above, it can be seen that parentheses group elements. It can also be seen from Table 1 that the elements need to appear in a specified order because the comma distinguishes each of these elements. Thus, the elements or sections that make up a literature tag related to general information are as follows:
[0089]
Title: Must appear only once
PubNo: Must appear only once after the title
AppNo: Must appear only once after PubNo
PatentRef *: any number of PatentRef can appear in succession, may be zero
FilingDate: must appear continuously and must appear only once
IssueDate? : If present, it should appear only once after FilingDate, but is optional
PublicationDate? : If it is present, it must appear once in a row, but is optional
CalculatedExpirationDate? : If it is present, it must appear once in a row, but is optional
Assignee *: any number of designated agents may appear in succession, may be zero
Inventor *: any number of inventors can appear in succession, may be zero
Priority *: any number of references to which this patent claims priority may appear consecutively, may be zero
DesignatedStates: must appear continuously and must appear only once
IPC *: any number of IPCs may appear in succession, may be zero
USClassification *: any number of US classifications may appear in succession, may be zero
PublicationLanguage: must appear continuously and must appear only once
NumClaims? : If present, should appear only once after PublicationLanguage, but is optional
NumDrawingPages? : If it is present, it must appear once in a row, but is optional
NumFigures? : If it is present, it must appear once in a row, but is optional
NumSpecPages? : If it is present, it must appear once in a row, but is optional
Note that each of these elements is further defined. For example, Title, PubNo, and AppNo are further defined as indicated by label 708. For example, PubNo needs to include normalized tags, ie, PubOrg, Kind, and Num (described above with respect to label 705) in order.
[0090]
PatentRef is further defined as indicated by label 709. FilingDate, IssueDate, PublicationDate, CalculatedExpirationDate, Assignee, Inventor, Priority, and DesignatedStates are each further defined as indicated by label 710.
[0091]
IPC and USClassification are further defined as indicated by label 711. Referring to label 711, the IPC needs to include normalized tags for sections, classes, subclasses, groups and subgroups. The USClassification needs to include normalized tags for USClass, USSubclass and USSuffix.
[0092]
Finally, PublicationLanguage, NumClaims, NumDrawingPages, NumFigures and NumSpecPages are further defined as indicated by label 712.
[0093]
That section or element summary is next in CPML DTD 702. The summary element is indicated by label 713.
[0094]
The summary section is followed by an unstructured literature section, indicated by label 714. The unstructured document labeled by 714 includes a text representation of all document information for a given patent in an unstructured format. This information is provided to support granting a patent. This is because not all document information may be stored in a structured format (in a document that supports CPML DTD 702).
[0095]
Based on the above teachings, those skilled in the art will recognize that a brief summary of a section of the invention is indicated by label 715, a brief description of the drawing section is indicated by label 716, and a detailed description of the invention section is indicated by label 717. And the rest of CPML DTD 702, including that the claims section is indicated by label 718.
[0096]
(V. Exemplary CPML Intellectual Property Document-US Patent)
8A-8C illustrate exemplary CPML intellectual property documents relating to US patents. The CPML intellectual property documents of FIGS. 8A-8C correspond to the CPML DTD 702 of FIGS. 7A-7C.
[0097]
(VI. Exemplary CPML document-European patent)
The CPML DTD 702 of FIGS. 7A-7C supports all types of patent intellectual property documents, not just US patents. For example, FIGS. 9A-9C illustrate an exemplary CPML intellectual property document for an EP application. The CPML intellectual property documents of FIGS. 9A-9C correspond to the CPML DTD 702 of FIGS. 7A-7C.
[0098]
(VII. Correspondence between CPML DTD and other patent DTDs and exemplary database implementations)
FIGS. 10A-101 show a mapping between CPML DTD 702 and other patent related DTDs (eg, patent related DTDs of the US and European Patent Offices). The arrangement of FIGS. 10A to 10I is shown in FIG. 10J.
[0099]
The USPTO “Red Book” DTD and “Green Book” DTD are represented by columns 1004 and 1006, respectively. The EPO / PCT DTD is represented by columns 1008, 1010 and 1012. CPML DTD 702 according to one embodiment is represented by columns 1014, 1016 and 1018.
[0100]
FIGS. 10A-10I also illustrate the mapping between CPML DTD 702 and the fields of the IPAM server database, which allows a method for storing data from a CPML intellectual property document in the database and the CPML intellectual property using the database. It shows how to populate property documents.
[0101]
(VIII. Detailed Description of Functions of Intellectual Property Protocol System of the Present Invention)
The functions of the intellectual property protocol system 110 have been introduced above with reference to FIG. The intellectual property protocol system 110 includes an intellectual property protocol function 205, an intellectual property data / exchange processing function 210, a presentation function 215, and a management function 230. Each of these functions may include one or more functions.
[0102]
(A. Intellectual property protocol function)
CPML DTD 702 supports formats and rules for the following functions performed by intellectual property protocol function 205:
Patent and trademark procedures and workflow
Electronic submission of patent and trademark applications
Track and report payments for patent and trademark management fees
License tracking
License audit
License payment
Intellectual Property Meta Data Management includes government-issued metadata, Derwent data and other third parties, CML data, user-defined intellectual property metadata, etc. (except for other DTDs) Can be included).
[0103]
Intellectual property data transaction data exchange with ERP system
Docket system, licensing system, etc.
Intellectual property metadata reporting and visualization
Linking intellectual property metadata with other related company data and business data
Direct presentation of CPML document to TIBCO data exchange wire format communication layer, etc.
Automatic client or player update with new patent information
Next, the intellectual property data and exchange processing function 210 of the present invention will be described.
[0104]
(B. Intellectual property data and exchange processing function)
A powerful aspect of the XML and CPML DTD 702 of the present invention (compatible with XML) is the ability to define data exchange rules and formats for various types of transactions. For example, see FIG. There are many e-commerce data exchange concepts such as SET, JEPI, CommerceNet, Cyber Cash, Millicent, OFX, XML / EDI, and the like. The SGML-based concept, which is a superset of all the above, is the Open Final Exchange Protocol (OFX).
[0105]
OFX is an SGML-based concept that enables coexistence and joint use of electronic commerce technology. OFX aims to smooth the path to the development of a retail base that is widely spread on the Internet. OFX supports the format and rules for the following activities:
Offer for sale
Purchase agreement
payment
Goods movement and services
delivery
Receipt
problem solving
CPML DTD 702 supports formats and rules for functions performed by intellectual property data and exchange processing function 210.
[0106]
(C. Presentation function)
The present presentation function 215 is responsible for specifying the format of any output to the user. In an embodiment of the present invention, the presentation function 215 formats the output of a CPML intellectual property document using a cascading style sheet. Since cascading style sheets or general style sheets are well known in the field (s), only a brief overview is given below.
[0107]
A style sheet is generally a file or form that defines the layout of a document. When filling in the style sheet, parameters such as page size, margin and font are specified. Style sheets are useful because the same style sheet can be used for many documents. For example, one style sheet is defined for patents, another style sheet is defined for patent procedures, and another style sheet is defined for trademarks. A style sheet is also called a template.
[0108]
More specifically, a cascading style sheet can separate the format information from the main document and store the format information separately in a STYLE element or in a separate document. Furthermore, in the case of in-line styling, it is also possible to indicate format information regarding a specific component using the STYLE attribute. “Cascade” refers to the ability to combine a plurality of style sheets and inline styling to simplify the task of creating a master template and make modifications as needed. Cascading style sheets use the document structure as a framework, then formatting information is annotated to the cascading style sheet, and the display (or printing, reading, or display in some way) of the sheet is applied to the application (typically Web browser).
[0109]
(D. Management function)
The management function 230 specifically allows an administrator to control whether the user has access to the IPAM server 105, the intelligent protocol system 110 and / or the intellectual property database 135.
[0110]
(IX. General system operation)
In the following, the manner in which the user navigates the functional modules and features provided by the intellectual property protocol system 110 will be described. The intellectual property protocol system 110 (via the front-end system 113) can be directly accessed by the user on the desktop computer via a world wide web page over the Internet (ie, through an online service) or via an intranet. Even accessible. In another embodiment, the intellectual property protocol system 110 (via the front end system 113) can also be accessed via a telephone service or the like. It should be understood that the control flow described herein is shown for illustrative purposes only. The intellectual property protocol system 110 of the present invention has sufficient flexibility and adaptability to allow the user to navigate the system 110 in other ways.
[0111]
FIG. 11 shows an example of a high level operation of the functionality of the intellectual property protocol system 110. Other high level operations will be described later with reference to FIGS. Referring to FIG. 11, flowchart 1100 begins at step 1102. In step 1102, the intellectual property protocol function 205 receives the CPML intellectual property document (via the front end system 113). Control then proceeds to step 1104.
[0112]
In step 1104, the intellectual property protocol function 205 processes the received intellectual property document using the appropriate DTD written in CPML DTD 702 (FIGS. 7A-7C). Here, parsing is performed using CPML DTD 702 to extract desired data from the intellectual property document. Control then proceeds to step 1106.
[0113]
In step 1106, the presentation function 215 is invoked, which formats the information and displays it in the intellectual property document. As described above, in one embodiment of the present invention, the output of the presentation function 215 can be formatted using a cascading style sheet. At this point, the flowchart 1100 ends.
[0114]
Step 1104 of flowchart 1100 will be further described with reference to FIG. Referring to FIG. 12, control begins at step 1202. In step 1202, the intellectual property protocol function 205 determines a portion of the data in the intellectual property document that needs to be reformatted. If there is a portion that needs to be reformatted in the data in the intellectual property document, the intelligent data and exchange processing function 210 is called, thereby reformatting the data. Control then proceeds to step 1204.
[0115]
At step 1204, based on the details of the type of intellectual property document received, the protocol function 205 refers to CPML DTD 702 and assumes that CPML DTD 702 includes multiple DTDs. Among the DTDs in 702, the DTD to be used is determined. Control then proceeds to step 1206.
[0116]
In step 1206, the protocol function 205 refers to the CPML DTD 702, parses the information, and extracts the information from the intellectual property document. Control then proceeds to step 1208.
[0117]
In step 1208, it is determined whether the intellectual property document conforms to CPML DTD 702. If the intellectual property document conforms to CPML DTD 702, control proceeds to step 1106 (FIG. 11). If the intellectual property document does not conform to CPML DTD 702, control proceeds to step 1210.
[0118]
In step 1210, the protocol function displays a parsing error to the user (via front end server 113). At this point, FIG. 12 ends.
[0119]
Step 1106 of flowchart 1100 will be further described with reference to FIG. Referring to FIG. 13, control begins at step 1302. In step 1302, the presentation function 215 determines whether it is necessary to call the IPAM server 105 (FIG. 1) to provide the requested information to the user. Control then proceeds to step 1304.
[0120]
In step 1304, the presentation function 215 uses the extracted data and / or any data received from the IPAM server 105 with a cascading style sheet to generate the desired output to the user. Different style sheets can be selected and used depending on the task being executed (to display or exchange information in a different set of information and / or a format that is valid for the task being executed) . If the data needs to be reformatted for the output desired by the user, the data and exchange processing function 210 is invoked, which formats the data in the correct form. At this point, FIG. 13 ends.
[0121]
As described above, FIG. 11 illustrates an example of a high level operation of the intellectual property protocol system 110 functionality. FIGS. 14 and 15 show another example of high-level operation of the functionality of the intellectual property protocol system 110, which will now be described. CPML DTD 702 supports multiple transactions. For example, embodiments of CPML DTD 702 support automatic updating of client information. This functionality of the present invention is shown in the flowchart 1402 shown in FIG. 14, and the corresponding event tracking diagram 1502 is shown in FIG. Referring to FIG. 14, control begins at step 1404.
[0122]
In step 1404, the host 1504 provides patent information and patent related information to the client 1506 via the CPML document 1508. CPML document 1508 is the display of US Pat. No. 5,832,229. CPML document 1508 includes information regarding this patent (eg, the information shown in FIGS. 7A-7C). The CPML document 1508 also includes version information, which in the presently described embodiment is part of the CPML DTD. In the example of FIG. 15, the version is V1. Using this version information, if there is a change in the information, the client 1506 is updated as will be described later. Control then proceeds to step 1406.
[0123]
In step 1406, patent information and / or patent related information is changed. For example, reclassification of patents, change of assignee, change of inventive entity, addition of documents after issuance, etc. can be performed. These changes are shown as 1512 in FIG. Control then proceeds to step 1408.
[0124]
In step 1408, the IPAM database at host 1504 is modified to reflect these changes 1512. Host 1504 may receive changes 1512 from various sources (eg, Cassis, USPTO publication, etc.). A new version number (V2) is assigned to US Pat. No. 5,832,229. Control then proceeds to step 1410.
[0125]
In step 1410, the client 1506 is automatically updated with the new / change information associated with the new version number V2. This automatic update process can be implemented, for example, by checking the version number of the document displayed on the client 1506. In this checking process, it is shown that client 1506 has version V1 of US Pat. No. 5,832,229. Host 1504 knows that the current version of the document is V2. Accordingly, host 1504 sends V2 US Pat. No. 5,832,229 as a CPML document 1514 to the client. Client 1506 uses this new CPML document 1514 to automatically update that version of US Pat. No. 5,832,229. At this point, the flowchart 1402 in FIG. 14 ends.
[0126]
(Input of data from X.XML document and non-XML document)
As described above, the IPAM server 105 can operate with XML documents and non-XML (eg, EQV) documents. This is illustrated, for example, in FIG.
[0127]
The XML server 1610 receives an XML input 1602 (eg, an XML document). The XML server 1610 automatically extracts structured information from the XML input 1602 and stores the structured information in the IPAM / company database 1612. Currently, XML servers such as EXCELON are commercially available. Any such XML server can be used with the present invention.
[0128]
The present invention can also work with non-XML data. Parser 1606 receives non-XML input 1604, which can be a non-XML document. This non-XML input 1604 is formatted in a specific manner. The parser 1606 knows the format of the non-XML input 1604 using either programming analysis or on-the-fly analysis. The parser 1606 extracts information from the non-XML input 1604 and generates an XML document or data. When the XML document is generated, the XML document is sent to the XML server 1610 as a processing target. Once the data is generated, it is stored in the IPAM / company database 1612.
[0129]
(XI. Order electronic documents and download DTD)
As described above, CPML DTD 702 (FIGS. 7A-7C) supports electronic data exchange / transfer and IP related transactions. For example, see FIG. The present invention, for example, supports (but is not limited to) electronic document retrieval and protocol DTD download. An example of this process is shown in FIGS. Using this DTD, it is possible to retrieve a document electronically, track the receipt, and fill out the document. The DTDs of FIGS. 17A-17C can be part of the CPML DTD 702 or can be distinguished from the CPML DTD 702.
[0130]
(XII. Another Embodiment of the Intellectual Property Protocol of the Present Invention—SPML (Smart Patents Markup Language))
The present invention relates to another patent markup language embodiment. Another such embodiment is called SPML (Smart Patents Markup Language).
[0131]
The format of the CPML document is specified by CPML DTD 702 (FIGS. 7A-7C). In contrast, the format of an SPML document is specified by a process specified by SPML (ie, a computer program that processes SPML). The end effect is usually the same.
[0132]
Conversion from DTD specified documents to processing specified documents and vice versa will be apparent to those skilled in the relevant art based on the teachings contained herein. For example, the conversion of SPML processing to DTD will be apparent to those skilled in the relevant art (s) based on the teachings contained herein. The general format of an SPML file includes a document header, bibliographic data, and formatted document text. Before discussing the details of the SPML of the present invention, embodiments of modules used in SPML will be described.
[0133]
FIG. 18 shows an example of an embodiment of a model 1800 used for the SPML of the present invention. Objects in the model 1800 are called either containers or leaves. The container can include a leaf, or the container can further include a container. Thus, each container limits or constrains the types of objects (eg, containers or leaves) that can be included in the container. Referring to FIG. 18, the container includes a document 1808, a Section 1810, a Paragraph 1812, and a Line 1814. The leaf is composed of a document composite element (Composite) 1801, Text 1802, Page Break 1804, VertSpace 1806, BibItem 1816, BibListOf 1818, Bibsection 1820, BibDate 1822, BibNumber 1824, and Bib 18T. How to define each container and leaf is discussed below.
[0134]
As described above, the general format of the SPML file includes, for example, a document header, literature data, and formatted document text. Referring again to FIG. 18, document 1808 is used to model the document header. BibItem 1816, BibListOf 1818, Bibsection 1820, BibDate 1822, BibNumber 1824, and BibText 1826 are used to model literature data. Finally, Section 1810, Paragraph 1812, Line 1814, Text 1802, Page Break 1804, and VertSpace 1806 are used to model formatted document text. Each of these is discussed in detail below.
[0135]
Note that the invention is not limited to these elements. The above-described elements and configurations described herein are provided for purposes of illustration only. Other elements and configurations will be apparent to those skilled in the art based on what is taught herein.
[0136]
(A. Document header of SPML file)
The first line of the document is a tag indicating that the document type is SPML. This tag is: “spDoc” for the patent's default document type.
[0137]
The second line of the document header is the main version number of SPML included in the file.
[0138]
The third line of the document header is a minor version number of SPML included in the file. The main version number and the minor version number can be used in the document builder to swap in the correct SMPL parser. If it is desired to manually edit the raw SPML later, the checksum and file size are not added to the header.
[0139]
(B. Document data of SPML file)
The bibliographic data section may include, but is not limited to: a string of text (related to BibText 1826), an integer (related to BibNumber 1824), data (related to BibDate 1822), (Bibsection 1820) A section of formatted text (related to) and an optional list of literature items mentioned above (related to BibListOf 1818). Each of these elements is described in more detail below.
[0140]
(1. BibText)
The format of data in Bib Text 1826 is as follows:
T9, Inventor Last Name, 1, Smith
The field separated by the first comma is a tag and contains the following information:
1) “T” identifies the row as containing a BibText entry.
[0141]
2) The number following the tag is a type ID indicating what kind of text item it is. These types are mapped to known patent text elements (for example, a text type ID of “1” is a text item that is a patent number, and a text type ID of “9” is a text item that is the name of the inventor. The user-defined bibliographic text item is given a unique type ID.
[0142]
The field separated by the second comma is the name and contains the following information:
1) The name given to the text item (eg “patent number” or “inventor's last name”). This field is often blank for known patent types (whose information can be determined from the type ID) and contains data for the user to define a bibliographic text item.
[0143]
The third comma delimited field is the style index and contains the following information:
1) Style index used when displaying a text item (for example, a style index of “1” indicating a text item will be displayed in the usual 9-point Times Roman).
[0144]
The fourth comma-delimited field is data and contains the following information:
1) A string containing actual text data.
[0145]
(2. BibNumber)
The format of the data in BibNumber 1824 is as follows:
N5, Number of claims, 16.
The field separated by the first comma is a tag and contains the following information:
1) “N” identifies that the row contains a BibNumber.
[0146]
2) The number following the tag is a type ID indicating what kind of item it is. These types are mapped to known patent number elements (eg, a number type ID of “5” is a number item that is the number of claims the patent has), and the user-defined document number item is a unique type ID. Given to.
[0147]
The field separated by the second comma is the name and contains the following information:
1) Name given to a number item (eg, “number of claims”). This field is often blank for defined bibliographic text items.
[0148]
The third comma delimited field is data and contains the following information:
1) An integer value that is data.
[0149]
(3. BibDate)
The format of the data in BibDate 1822 is as follows:
D1, Application date, 7 11 1985.
The field separated by the first comma is a tag and contains the following information:
1) “D” identifies the row as containing BibDate.
[0150]
2) The number following the tag is a type ID indicating what kind of data item it is. These types are mapped to known patent date elements (eg, a data type ID of “1” is a data item that is the filing date of the patent), and a user-defined document count item is given a unique type ID. .
[0151]
The field separated by the second comma is the name and contains the following information:
1) The name given to the data item (eg, “application date”). This field is often blank for known patent types (whose information can be determined from the type ID) and contains data for the user to define a literature text item.
[0152]
The third comma delimited field is data and contains the following information:
1) Month, day and year, separated by spaces.
[0153]
(4. BibSection)
The format of the data in the Section item (eg, BibSection 1820) is similar to the formatted text section of the document text. Only significant differences are given here to avoid the difficulty of keeping the same information in the two places. The tag for the literature section is “B” instead of “S”.
[0154]
(5. BibListOf)
The data format in the BibListOf 1818 entry is as follows:
L1, BibliographicData
bib items (including other lists)
~
The field separated by the first comma is a tag and contains the following information:
1) “L” identifies the row as starting BibListOf.
[0155]
2) The number following the tag is a type ID that indicates what kind of list item the BibListOf is. These types are known patent list elements (eg, a list type ID of “2” is a list of inventor list items. A type ID of “3” is a BibText item for the first name and a last name for the last name. Is a list of all items that make up the inventor, such as another item), and the user-defined document list item is given a unique type ID. Note that a list type ID of “1” is a specific type of list that all documents need to have, which is a list that includes all other literature items that the document has.
[0156]
The field separated by the second comma is Name and contains the following information:
1) A name given to a list item (for example, “document data”, “inventor list” or “inventor item”). This field is empty in most cases for known patent types (information can be determined from the type ID) and contains data for user-defined bibliographic text items.
[0157]
The last part of the data in BibListOf 1818 is the end tag:
1) Since lists can be nested, an end tag is required to mark the end of the list. This end tag is a single “˜” in one row. The end tag marks the end of the most recent list. For example:
L1, literature data
L2, Inventor list
~ // This ends the inventor list
~ // This ends the literature data list
(C. SPML file formatted document text data)
The formatted document text data section may include (but is not limited to) the following: a section that includes one or more paragraphs (with respect to section 1810), and one or more lines (with respect to paragraph 1812). Paragraph, a line containing one or more text sequences (for line 1814), a text sequence containing one or more characters (for line 1802), a page break (for PageBreak 1804), a vertical space (for VertSpace 1806), and ( Special characters (not shown in FIG. 18). Each of these is described in more detail below.
[0158]
(1. Section)
The data format in Section 1810 is as follows:
S1, the first section of the document
Paragraph data
The field separated by the first comma is a tag and contains the following information:
1) “S” identifies a row as starting a Section.
[0159]
2) The number following the tag is a type ID that informs what kind of section the Section is. These types are mapped to known patent sections and user-defined section items are given a unique type ID.
[0160]
The second common delimited field is the name and contains the following information:
1) The name given to the section (eg, “Summary of Invention”). This field is almost always empty for known patent types (information can be determined from the type ID) and contains data about user-defined bibliographic text items.
[0161]
2) End tags are not required because sections cannot be nested.
[0162]
(2. Paragraph)
The data format in Paragraph 1812 is as follows:
P1
Line data
The field separated by the first comma is a tag and contains the following information:
1) “P” identifies a line as starting paragraph.
[0163]
2) The number following the tag is a type ID that tells the user what kind of indentation when the paragraph is displayed. These types are mapped to known patent identification styles and user-defined section items are given a unique type ID. User-defined indentation styles are most often defined in the header of this document.
[0164]
3) End tags are not required because sections cannot be nested.
[0165]
(3. Line)
The format of the data in Line 1814 is simply a text item that constitutes one line of text in the file.
[0166]
<Text data><Textdata><Textdata>
Since the line in the SPML file itself is a marker when the line begins and ends, no start or end tag is required.
[0167]
(4. Text)
The data format in Text 1802 is:
<T0, this is a sample of some text>
The field separated by the first comma is a tag and contains the following information:
1) “<T” identifies a line as starting text.
[0168]
2) The number following the tag is a type ID that tells how the text will be displayed. These types are mapped to known patent text styles, and user-defined styles are given unique type IDs. User-defined text styles (eg, bold italic 15-point Arial) are most often defined in the document header.
[0169]
The field separated by the second comma is data and contains the following information:
1) A string containing actual text data
2) The end of the string of data is marked with the tag “>”. If the character “>” needs to be part of the text data, it should be represented as a special character (“˜> ˜”).
[0170]
(5. Page Break)
The data format in Page Break 1804 is as follows:
<G>
No further information is needed to represent a page break.
[0171]
(6. VertSpace)
The format of the data in VertSpace 1806 is as follows:
<V height>
This includes two parts:
1) "V" to specify that this is a vertical space tag
2) A number that specifies the height. One height unit equals half the height of a line of text.
[0172]
(7. SpecialChar)
The format for special characters in text arrays is:
~ DELTA ~
The special character name field is surrounded by "~" and contains the following information:
1) A string containing a lookup value for an array that maps special character names to special character codes.
[0173]
An exemplary format of the formatted document text of the present invention according to an embodiment is as follows:
S1, the first section of the document
P1
<T0, which is a sample of some text. >
<T0, which is a sample of some text. >
<T0, which is a sample of some text. >
P1
<T0, which is a sample of some text. >
<T0, this is><T1, is a sample><T0,some><T2, text with style changes. >
<T0, which is a sample of some text. >
P5
<T0, which is a sample of some text. >
<T0, which is a sample of special characters ~ DELTA ~ in the center of the text array. >
<T0, which is a sample of some text. >
<T0, which is a sample of some text. >
S4, second section of the document
P2
<T0, which is a sample of some text. >
<T0, which is a sample of some text. >
P1
<T0, which is a sample of some text. >
<T0, this is><T1, is a sample><T0,some><T2, text. >
<T0, which is a sample of some text. >
(D. Streaming mechanism of the present invention)
Streaming is a technique for transmitting data so that it can be processed as a steady, continuous stream. Streaming technology becomes increasingly important with the development of the Internet 120 (FIG. 1) because most users (or clients) do not have fast enough access to quickly download large numbers of multimedia files. It is coming. With streaming, a client browser or plug-in can begin displaying its data before the entire file has been sent.
[0174]
For streaming to work, the client side that receives the data needs to be able to collect the data and process it as a steady stream and send it to the application that is converting it to audio or video. is there. This means that if data is received more quickly than requested by the streaming client, excess data needs to be saved in the buffer. However, if the data does not come quickly enough, the presentation of the data is not smooth. The present invention provides two different streaming techniques used in conjunction with the presentation function 215 (FIG. 2).
[0175]
As described above, the presenting function 215 of the present invention is responsible for identifying the format of any output to the user. In an embodiment of the present invention, the presentation function 215 uses a cascading sheet to format the output of the SPML intellectual property document. A cascading sheet provides a CLASS attribute. Developers can use this CLASS attribute, not just the format, to reflect the classification of content. The present invention combines the cascading sheet CLASS attribute and streaming technology to provide two streaming mechanisms including: a template-based streaming mechanism and a visitation-based streaming mechanism. These two mechanisms address how to get the SPML file that goes into memory and then exits from it. The template based streaming mechanism is first described with reference to FIG. Next, the visit-based streaming mechanism of the present invention will be described with reference to FIG.
[0176]
Referring to FIG. 19, DocComponentStreamer 1902 acts as an adapter to the class of DocComponent 1904 (see also FIG. 18), so that streaming behavior moves out of the class of DocComponent 1904, and within the class of DocComponentStreamer 1902 Enter. This allows DocComponent 1904 to be streamed in several different ways based on the type of DocComponentStreamer 1902 used to adapt that DocComponent 1904. The sample code is as follows.
[0177]
DocComponentStreamer streamer (DocComponent);
Coat (cout) <<streamer;
For the template-based streaming mechanism of the present invention, a macro can be described for each different type of streaming desired. This streaming acts like an adapter streamer for each type of document element that needs to be described.
[0178]
Referring to FIG. 20, the visit-based streaming mechanism of the present invention will now be described. The StreamingVisitor 2002 class is accepted by the virtual method of the DocComponent 2004 class (see also FIG. 18). This allows the visitor to stream accurate information without having to dedicate DocComponent 2004 to the derived type. All streaming behavior moves out of the DocComponent 2004 class and enters the StreamingVisitor 2002 class. This allows DocComponent 2004 to be streamed in several different ways based on the type of visitor used. Sample code is as follows:
Streaming Visitor visitor (coat);
component. Accept (visitor);
(E. Adapter class of the present invention)
The SPML document of an embodiment of the present invention can be adapted to different roles by using adapter classes. The use of adapter classes provides a number of benefits, including the following: various ways of working with SPML documents can be included; various interfaces without affecting other existing interfaces It is possible to add to the present invention; prevent bloated document interfaces; and it is possible for the client code to select the role that the SPML document plays and how the SPML document can be used. FIG. 21 shows a summary diagram of how an application can use different adapters to work differently on the same SPML document.
[0179]
Referring to FIG. 21, application 2102 works with SPML document 2112 in one way using adapter 2106 and works with the same SPML document in a different way using adapter 2108. Application 2104 works with the same SPML document 2112 as application 2102 in a different manner using adapter 2110. A specific diagram illustrating what applications can use different adapters to work differently with the same SPML document is described below.
[0180]
FIG. 22 is an exemplary illustration showing what applications may use different adapters to work differently with the same SPML document. In FIG. 22, PagTool 2202, PaginatorID 2204, DocumentRepository 2206, ImageResponse 2208, Paginator 2210, Document 2212, Canonical 2214, and Static 2216 are shown. PagTool 2202 acts as a facade for the domain when there is no pagenator. The PaginatorID identifies a page generator. The ID is used to log in and determine who generated what statics. DocumentRepository 2206 identifies the location where the SPML file or document can be found. ImageRepository 2208 identifies the location where the CAN file can be found. Statistic 2216 contains information regarding when the pagination is logged on, off, opening a file, saving a file, or completing file pagination. Canonimage 2214 represents image data that serves as the basis for the format information. Document 2212 includes text data having format information. This is a text version of Canonimage 2214. Finally, the Paginator 2210 changes the format information of the document. The Paginator 2210 can insert and / or delete page and line corruption, edit diagram references, and edit the number of bib pages.
[0181]
(XIII. Conclusion)
While various embodiments of the invention have been described above, it should be understood that they have been presented for purposes of illustration and not limitation. It will be apparent to those skilled in the relevant art that various changes in form and detail may be made herein without departing from the spirit and scope of the invention. This is true in terms of technologies and conditions in related fields that can develop into future generations. Thus, the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating an operating environment in accordance with an embodiment of the present invention.
FIG. 2 is a block diagram of the functions or modules of the present invention connected by a network according to an embodiment of the present invention.
FIG. 3 is a block diagram of a computer system that is preferably used to implement the present invention in accordance with an embodiment of the present invention.
FIG. 4 is a block diagram illustrating an exemplary CPML DTD according to an embodiment of the present invention.
FIG. 5 is a block diagram illustrating an exemplary patent DTD according to an embodiment of the present invention.
FIG. 6 is a flow diagram illustrating several types of CPML intellectual property documents that may be transmitted between clients in accordance with an embodiment of the present invention.
FIG. 7A shows an exemplary CPML DTD according to an embodiment of the present invention.
FIG. 7B shows an exemplary CPML DTD according to an embodiment of the present invention.
FIG. 7C shows an exemplary CPML DTD according to an embodiment of the present invention.
FIG. 7D shows an exemplary CPML DTD according to an embodiment of the present invention.
FIG. 7E shows an exemplary CPML DTD according to an embodiment of the present invention.
FIG. 8A illustrates an exemplary CPML intellectual property document for a US patent in accordance with an embodiment of the present invention.
FIG. 8B shows an exemplary CPML intellectual property document for a US patent in accordance with an embodiment of the present invention.
FIG. 8C illustrates an exemplary CPML intellectual property document for a US patent in accordance with an embodiment of the present invention.
FIG. 8D shows an exemplary CPML intellectual property document for a US patent in accordance with an embodiment of the present invention.
FIG. 8E shows an exemplary CPML intellectual property document for a US patent in accordance with an embodiment of the present invention.
FIG. 8F illustrates an exemplary CPML intellectual property document for a US patent in accordance with an embodiment of the present invention.
FIG. 9A shows an exemplary CMPL intellectual property document for a European patent application in accordance with an embodiment of the present invention.
FIG. 9B shows an exemplary CMPL intellectual property document for a European patent application in accordance with an embodiment of the present invention.
FIG. 9C shows an exemplary CMPL intellectual property document for a European patent application in accordance with an embodiment of the present invention.
FIG. 9D shows an exemplary CMPL intellectual property document for a European patent application according to an embodiment of the present invention.
FIG. 9E illustrates an exemplary CMPL intellectual property document for a European patent application in accordance with an embodiment of the present invention.
FIG. 9F shows an exemplary CMPL intellectual property document for a European patent application in accordance with an embodiment of the present invention.
FIG. 9G shows an exemplary CMPL intellectual property document for a European patent application in accordance with an embodiment of the present invention.
FIG. 10A illustrates a mapping between CPML DTDs and DTDs associated with other patents in accordance with an embodiment of the present invention.
FIG. 10B illustrates a mapping between CPML DTDs and other patent-related DTDs according to embodiments of the invention.
FIG. 10C illustrates a mapping between a CPML DTD and other patent-related DTDs according to an embodiment of the present invention.
FIG. 10D illustrates a mapping between CPML DTDs and DTDs associated with other patents according to embodiments of the invention.
FIG. 10E illustrates a mapping between CPML DTDs and other patent-related DTDs according to an embodiment of the present invention.
FIG. 10F illustrates a mapping between CPML DTDs and other patent-related DTDs according to an embodiment of the present invention.
FIG. 10G illustrates a mapping between CPML DTDs and DTDs associated with other patents in accordance with an embodiment of the present invention.
FIG. 10H illustrates a mapping between CPML DTDs and DTDs associated with other patents in accordance with an embodiment of the present invention.
FIG. 10I illustrates a mapping between CPML DTDs and other patent-related DTDs according to an embodiment of the present invention.
FIG. 10J illustrates the positioning of FIGS. 10A-10I in accordance with an embodiment of the present invention.
FIG. 11 shows an example in which the functions of the intellectual property protocol system according to the embodiment of the present invention are operating at a high level.
FIG. 12 shows in more detail the steps of FIG. 11 according to an embodiment of the present invention.
FIG. 13 shows in more detail the steps of FIG. 11 according to an embodiment of the present invention.
FIG. 14 illustrates automatic updating of client information according to an embodiment of the present invention.
FIG. 15 is a parallel trace diagram corresponding to FIG. 14 in accordance with an embodiment of the present invention.
FIG. 16 illustrates how an IPAM server operates with XML and non-XML documents (eg, EQV) documents according to an embodiment of the present invention.
FIG. 17A illustrates how the present invention supports electronic data document ordering and download protocol DTD according to embodiments of the present invention.
FIG. 17B illustrates how the present invention supports an electronic data document order and download protocol DTD according to an embodiment of the present invention.
FIG. 17C illustrates how the present invention supports an electronic data document order and download protocol DTD according to an embodiment of the present invention.
FIG. 18A illustrates a model used for the SPML of the present invention in accordance with an embodiment of the present invention.
FIG. 18A illustrates a model used for the SPML of the present invention in accordance with an embodiment of the present invention.
FIG. 19 illustrates the template-based streaming mechanism of the present invention according to an embodiment of the present invention.
FIG. 20 illustrates the visit-based streaming mechanism of the present invention according to an embodiment of the present invention.
FIG. 21 shows a schematic diagram of how an application can use different adapters to process the same SPML document of the present invention differently, in accordance with an embodiment of the present invention.
FIG. 22 shows a specific diagram of how an application can use different adapters to process the same SPML document of the present invention differently according to embodiments of the present invention. Show.

Claims (5)

A system for standardizing data exchange for intellectual property data objects, the system comprising:
Storage means storing at least one intellectual property protocol, wherein the at least one intellectual property protocol defines a data exchange set of at least one rule and format for the type of intellectual property data object Means,
Input means for receiving the intellectual property data object into the system, wherein the format of the input intellectual property data object is normalized for entry into the storage means Means,
At least one processing means connected to said input means by means of a communication line, wherein said at least one processing means determines whether said type of intellectual property data object received at said input means follows said intellectual property protocol At least one processing means for determining whether or not;
Output means for presenting information from the intellectual property data object, wherein the information from the intellectual property data object is formatted according to an output data type definition (DTD) format, the DTD being normalized; A section for no data and a section for normalized data, and information from the intellectual property data object is stored in the unnormalized format and then in the normalized format And an output means that is repeatedly stored in the system.   The type of the intellectual property data object is selected from the group consisting of patents, patent applications, trademarks, trademark applications, copyrights, trade secrets, license agreements, and joint venture establishment agreements. system.   The system of claim 1, wherein the storage means supports hypertext references.   The system of claim 1, wherein objects in the protocol are in accordance with at least one extended markup language (XML) DTD.   The system of claim 4, wherein the DTD includes a combination of structured literature data of the intellectual property data object.

Images