(57)【特許請求の範囲】
【請求項１】
知的財産データオブジェクトについてのデータ交換の標準化を実施するシステムであって、該システムは、
少なくとも１つの知的財産プロトコルを格納した格納手段であって、該少なくとも１つの知的財産プロトコルが、知的財産データオブジェクトのタイプについての少なくとも１つのルールおよびフォーマットのデータ交換セットを定義する、格納手段と、
該知的財産データオブジェクトを該システム内へと受信する入力手段であって、入力される該知的財産データオブジェクトのフォーマットは、該格納手段内へのエントリーのために正規化されている、入力手段と、
通信回線によって該入力手段に接続された少なくとも１つの処理手段であって、該少なくとも１つの処理手段は、該入力手段において受信された該タイプの知的財産データオブジェクトが該知的財産プロトコルに従うかどうかを判定する、少なくも１つの処理手段と、
該知的財産データオブジェクトからの情報を提示する出力手段であって、該知的財産データオブジェクトからの該情報は、出力データタイプ定義（ＤＴＤ）フォーマットに従ってフォーマットされ、前記ＤＴＤは、正規化されていないデータのためのセクションおよび正規化されたデータのためのセクションを有し、該知的財産データオブジェクトからの情報は、正規化されていないフォーマット中に格納された後、正規化されたフォーマット中に繰り返し格納される、出力手段と
を備える、システム。
【請求項２】
前記知的財産データオブジェクトの前記タイプは、特許、特許出願、商標、商標出願、著作権、企業秘密、ライセンス協定、合弁会社設立契約から構成される群から選択される、請求項１に記載のシステム。
【請求項３】
前記格納手段は、ハイパーテキストリファレンスをサポートする、請求項１に記載のシステム。
【請求項４】
前記プロトコル内のオブジェクトは、少なくとも１つの拡張されたマークアップ言語（ＸＭＬ）ＤＴＤに従う、請求項１に記載のシステム。
【請求項５】
前記ＤＴＤは、前記知的財産データオブジェクトの構造化文献データの結合を含む、請求項４に記載のシステム。
【発明の詳細な説明】
【０００１】
（発明の背景）
（発明の分野）
本発明は、一般にデータ処理用のツールに関し、さらに詳細には書類のような汎用知的財産データオブジェクトに対するデータ交換規則およびフォーマットを規定するための知的財産プロトコルに関する。
【０００２】
（関連技術）
知的財産書類は（米国およびその他の外国での）特許、（米国、ＰＣＴおよびその他の外国での）特許出願、（米国およびその他の外国での）商標、（米国およびその他の外国での）商標出願、著作権、企業秘密、ライセンス協定、合弁会社設立契約、または知的財産権を含むデータオブジェクトの任意の他のタイプを含み得る。知的財産書類の効率の良い管理は、１つ以上のこれらの知的財産書類および／またはシステムならびにそれらに関連するプロセスを表すデータを交換する構造化された方法を必要とする。これらのプロセスは、ライセンストラッキング（ｌｉｃｅｎｓｅ  ｔｒａｃｋｉｎｇ）；監査および支払（ａｕｄｉｔ  ａｎｄ  ｐａｙｍｅｎｔ）；特許および商標の実務および仕事の流れ；特許および商標の年金の支払いトラッキングおよび報告；知的財産メタデータの報告および視覚化（ｖｉｓｕａｌｉｚａｔｉｏｎ）；特許出願および商標出願の電子データによる提出（ｅｌｅｃｔｒｏｎｉｃ  ｓｕｂｍｉｓｓｉｏｎ）等を含む。本発明以前には、データを交換する構造化された方法は存在しなかった。
【０００３】
知的財産書類を取り扱う（または知的財産の分野に含まれる）個人および／または産業は多くの異なるプレイヤーからなる。例えば、１プレイヤーは米国特許商標庁であり、別のプレイヤーはヨーロッパ特許庁、別のプレイヤーは統合業務マネージャ、さらに別のプレイヤーは特許出願人、さらに別のプレイヤーは特許または商標の実施権許諾者等である。これらのプレイヤーは、互いに独立してる場合があるが、目的を容易にするために共に協働しなければならない場合がある。例えば、特許出願人は米国特許商標庁とやり取りし、それにより自分の特許出願および／または商標出願の手続きを遂行する必要がある。２以上のプレイヤーが目的を容易にするために協働する場合に、プレイヤーが１以上の知的財産データオブジェクトまたは知的財産書類の電子データバージョンを用いるのは利点がある。しかし、知的財産データオブジェクトのデータ交換規則およびフォーマットがないためにこれは起こらない場合が多い。知的財産データオブジェクトのデータ交換規則およびフォーマットの標準的な規定がない場合、プレイヤーの共通の目的を進行するのは妨げられることが多い。
【０００４】
知的財産の分野でのプレイヤー間の協力は妨げられる。というのも、プレイヤーが知的財産書類に対して異なるフォーマットを使用する場合が多いからである。今日、産業がコンピュータ化され、知的財産の分野の多くの異なるプレイヤーがインターネットを使用するので、知的財産書類の異なるフォーマットの使用により、異なるプレイヤー間の電子データの知的財産（ｅｌｅｃｔｒｏｎｉｃ  ｉｎｔｅｌｌｅｃｔｕａｌ  ａｓｓｅｔ）書類の効率の良い交換が妨げられる。
【０００５】
それゆえ、必要なのは、汎用知的財産書類についてのデータ交換規則およびフォーマットを規定し、それにより電子データの知的財産データオブジェクトを交換する有効性および効率性を高める知的財産プロトコルである。加えて、プロトコルは、十分に柔軟性があり、様々な仕事のプロセスに対する知的財産取引データを管理するような他のタイプの機能（しかしこの機能に限定されるわけではない）を可能とするために十分な機能を有するべきである。本発明は、知的財産メタデータに対する標準を規定し、個別の知的財産ソフトウェアシステムと統合業務（ＥＰＲ）システムの間でデータを交換するための有効で、効率の良い方法を提供する。
【０００６】
（発明の要旨）
本発明は、汎用知的財産データオブジェクトに対するデータ交換規則およびフォーマットを規定するための知的財産プロトコル、および知的財産プロトコルに関連するシステム、方法、ならびにコンピュータプログラム製品に関する。本発明は、汎用知的財産書類に対するデータ交換規則およびフォーマットを規定して、エンジンとして機能する知的財産プロトコルシステムを含む。本発明はまた、知的財産プロトコルシステムにアクセスするためにグラフィカルユーザインターフェースを本発明のユーザに好適に提供するフロントエンドシステムを含む。本発明はまた、知的財産書類（および知的財産書類に関連する情報）、１以上の知的財産プロトコルの実施形態等を収集したものを格納する知的財産データベースを含み得る。知的財産プロトコルシステムは、以下で説明するように知的財産権財産マネージャ（ＩＰＡＭ）サーバ１０５とインタラクトする。
【０００７】
本発明のさらなる特徴および利点は、本発明の様々な実施形態の構造および作用と同様に、添付図面を参照して以下で詳細に説明される。図面において、同じ参照番号は、通常、同一の、機能的に同じの、および／または構造的に同じ要素を示す。最初に要素が現れる図面は、対応する参照番号の中で最も左の数字によって表示される。
【０００８】
本発明は、添付される図面を参照して説明される。
【０００９】
（好適な実施形態の詳細な説明）
（Ｉ．発明の概要）
本発明は、知的財産文書のデータおよびフォーマットの規定を可能にし、それにより異なるシステム間の電子知的財産文書の効率的交換を促進する知的財産プロトコルを含む。本発明は、図１に示し、以下に詳細に記載されるように、インテレクチュアルプロパティアセットマネージャ（Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ａｓｓｅｔ Ｍａｎａｇｅｒ）（ＩＰＡＭ）サーバ１０５、知的財産プロトコルシステム１１０、フロントエンドシステム１１３、および知的財産データベース１３５を意図する。
【００１０】
（ＩＩ．システムアーキテクチャ）
（Ａ．システムアーキテクチャの概要）
図１は、本発明の動作環境の一例を示すブロック図である。図１の例の動作環境は、説明のためだけに示され、本発明を限定しないことが理解される必要がある。本明細書に記載される動作環境の他の実施形態は、本明細書に含まれる教示に基づいて当業者に明らかであり、本発明は、このような他の実施形態に向けられる。図１は、ＩＰＡＭサーバ１０５、知的財産プロトコルシステム１１０、フロントエンドシステム１１３、知的財産データベース１３５、広域インターネット１２０または他の通信媒体、政府機関１１５、１つ以上の知的財産文書ライセンサ１２５、および／または１つ以上のＥＰＲシステム１４０を含む環境の一例を示す。
【００１１】
図３を参照して以下に記載されるように、ＩＰＡＭサーバ１０５、知的財産プロトコルシステム１１０、フロントエンドシステム１１３、および知的財産データベース１３５は、ハードウェア、ソフトウェア、またはその組合せを使用して実施され得、そして１つ以上のコンピュータシステム、または１つ以上の処理システムにおいて実施され得る。知的財産プロトコルシステム１１０は、次に記載される。
【００１２】
知的財産プロトコルシステム１１０は、知的財産文書の標準化において本発明のためのエンジンとして動作する。知的財産プロトコルシステム１１０は、ＩＰＡＭサーバ１０５および知的財産データベース１３５に接続される。知的財産プロトコルシステム１１０は、またフロントエンドシステム１１３を介してインターネット１２０にも接続される。ユーザからの要求は、フロントエンドシステム１１３を介して知的財産プロトコルシステム１１０に対して行われ得る。本発明によって提供される様々な機能は、データ源に依存していない。図１に示される本発明の実施形態は、ＩＰＡＭサーバ１０５、知的財産プロトコルシステム１１０、フロントエンドシステム１１３、および知的財産データベース１３５を別々の機能成分として説明するが、いくつか（または全て）の成分は、以下に記載されるように、各成分の機能が本発明内になお存在する限り、結合され得る。ＩＰＡＭサーバ１０５は、次に記載される。
【００１３】
便宜上、ＩＰＡＭサーバ１０５は、本明細書では簡潔に述べる、しかし本発明はこの簡潔な記載に限定されない。簡潔に述べると、ＩＰＡＭサーバ１０５は、コンテキストデータ処理を扱う。ＩＰＡＭサーバ１０５は、１つ以上のコンテキストを規定し選択するために使用され得る。各コンテキストは、１つ以上の属性およびその属性を満たす複数のデータオブジェクトを含む。選択されたコンテキストに含まれるデータオブジェクトのリストが表示され得る。選択されたコンテキスト中のデータオブジェクトの少なくともいくつかは、処理され得る。そのような処理は、データオブジェクト間の関係を表すための階層的および／または方向づけられた非輪状グラフデータ構造を生成することを含む。これらのデータ構造は、次に、双曲線ツリーを含むがこれに限られない様々な周知の技術で表示され得る。そのような階層的または方向づけられた非輪状グラフ構造の例は、クレームツリー、引用ツリー、およびデータオブジェクトファミリーを含み、これらは、双曲線ツリーを使用して表示され得る。
【００１４】
一実施形態において、コンテキストはグループである。他の実施形態において、コンテキストは各々、データオブジェクトタイプと関連する。この後者の実施形態において、コンテキストは、それぞれのデータオブジェクトタイプのデータオブジェクトを含む。
【００１５】
ＩＰＡＭサーバ１０５は、さらに注釈の生成をサポートする。ＩＰＡＭサーバ１０５は、文書注釈、グループ注釈、データオブジェクトタイプ注釈、ケース注釈、およびエンタプライズ注釈を含む複数の注釈タイプをサポートする。ＩＰＡＭサーバ１０５は、また形式に基づいた注釈もサポートする。
【００１６】
一実施形態において、ＩＰＡＭサーバ１０５は、ＩＰＡＭサーバ１０５に結合されるプラグインマネージャを有する。図１に示されるシステムは、またプラグインマネージャに結合された少なくとも１つのプラグイン、およびプラグインに結合された少なくとも１つの外部データ処理成分をも含み得る。一実施形態において、外部データ処理成分は、少なくともグラフを使用してデータを表示する。別の実施形態において、外部データ処理成分は、少なくともマップを使用してデータを表示する。プラグインマネージャは、第１のアプリケーションプログラミングインターフェース（ＡＰＩ）を有し、そして各外部データ処理成分は、第２のＡＰＩを有する。プラグインは、プラグインマネージャから外部データ処理成分へ、そして第２のＡＰＩに適合するフォーマットへ、メッセージを変換し、外部データ処理成分からプラグインマネージャへ、そして第１のＡＰＩに適合するフォーマットへメッセージを変換する。
【００１７】
ＩＰＡＭサーバ１０５の実施形態は、特許均等物テキストファイル（ＥＱＶ）を処理し、表示し、そしてそうでなければ特許均等物テキストファイルで動作し得る。（ＩＰＡＭサーバ１０５の他の実施形態は、他のデータタイプで動作する。）特許均等物テキストファイルは、米国特許第５，６２３，６８１号に記載されており、その全体をここに参考のため援用する。特許均等物テキストファイルは、特許均等物テキストファイル中のテキストと特許イメージファイル中の画像との間の均等性関係を確立する均等性情報を含む。例えば、この均等性情報は、特許均等物テキストファイルが、特許イメージファイルと同一のページネーション（行の切れ目、欄の切れ目、ページの切れ目）を有して表示されることを可能にするページネーション情報を含み得る。一実施形態において、ページネーションモジュールは、特許テキストファイル中の特許テキストと特許イメージファイルとを比較し、均等性情報を検出することによって、特許均等物テキストファイルを生成する。この均等性情報は、次に特許テキストと共に、特許均等物テキストファイル中に埋め込まれる。ページネーションモジュールは、ページネーション動作を自動的に実行し得るが、いくつかの場合に、何らかの手動介入が要求される。従って、オペレータは、時にページネーションモジュールによって実行されるページネーションプロセスに関与する場合がある。本発明のフロントエンドシステム１１３は、次に記載される。
【００１８】
フロントエンドシステム１１３は、ウェブサーバとして動作し得る。ウェブサーバは、知的財産プロトコルシステム１１０にアクセスしたいユーザにＧＵＩを提供する。当該分野で周知のように、ウェブサーバは、遠隔ブラウザからハイパーテキスト転送プロトコル（ＨＴＴＰ）要求に応答して、ウェブページを送信する、ウェブサイトで動作するサーバプロセスである。オプションのファイアウォール（図示せず）は、知的財産プロトコルシステム１１０と広域インターネット１２０との間の接続および切断としての役目をする。概して、当該分野で周知のファイアウォールは、特別安全警戒ソフトウェアを有する専用ゲートウェイマシンである。ファイアウォールは、典型的には、例えば、インターネット１２０の接続およびダイアルイン回線にサービスするために使用され、そしてファイアウォールの後ろに隠れた、より緩く管理されたマシーングループを、外部の侵入から守る。本発明の知的財産データベース１３５は、次に記載される。
【００１９】
知的財産データベース１３５は、本発明によって使用される知的財産プロトコル、知的財産文書、およびそのプロセスなどの現在の実施形態を表すデータの収集を格納する。この点で、一実施形態において、知的財産データベース１３５に格納されるデータは、リレイショナルデータベースとして格納され得る。リレイショナルデータベースにおいて、データは、関連テーブルの形で格納される。リレイショナルデータベース管理システム（ＤＢＭＳ）は、関連テーブル中のデータを操作するために使用される。リレイショナルデータベースは、強力である、なぜならどのようにデータがデータベースと関連するか、またはどのようにデータがデータベースから抽出されるかに関する仮定をほとんど必要としないからである。結果として、同じデータベースが、多くの異なる方法で見られ得る。リレイショナルシステムの重要な特徴は、１つのデータベースが、いくつかのテーブルを越えて広がり得ることである。このことは、各データベースがそれぞれ１つのテーブルでに収まっているフラットファイルデータベースと異なる。
【００２０】
知的財産データベース１３５によって使用されるこのタイプのデータベースの別の実施形態は、ハイパーテキストとして公知のデータベースデザインである。ハイパーテキストデータベースにおいては、テキストであるか、画像であるか、フィルムであるかにかかわらず、任意のオブジェクトが他の任意のオブジェクトにリンクされ得る。ハイパーテキストデータベースは、大量の全く異なる情報をまとめるために特に有用である。しかしハイパーテキストデータベースは概して、数値解析用には設計されていない。
【００２１】
本発明の知的財産データベース１３５は、またオープンデータベースコネクティビティ（ＯＤＢＣ）などの標準データベースアクセス方法を使用しても実施され得る。ＯＤＢＣの目標は、いずれのＤＢＭＳがデータを処理しているかにかかわらず、いかなるアプリケーションからのいずれのデータにもアクセスすることを可能にすることである。ＯＤＢＣは、アプリケーションとＤＢＭＳとの間にデータベースドライバと呼ばれる中間層を挿入することによって、これを管理する。この層の目的は、アプリケーションのデータ照会をＤＢＭＳが理解するコマンドに変換することである。これが作動するためには、アプリケーションおよびＤＢＭＳ両方が、ＯＤＢＣ準拠でなければならない。すなわちアプリケーションは、ＯＤＢＣのコマンドを発行する能力がなければならないし、ＤＢＭＳは、そのコマンドに応答する能力がなければならない。ＩＰＡＭサーバ１０５のエンジンおよび知的財産プロトコルシステム１１０の機能、ならびに知的財産データベース１３５に格納されたデータは両方とも、以下でさらに詳細に述べる。広域インターネット１２０は、次に記載される。
【００２２】
広域インターネット１２０は、インターネット１２０のユーザ（たとえば、知的財産ドメイン内のプレイヤ）が遠隔でアクセスすること、および知的財産プロトコルシステム１１０を（フロントエンドシステム１１３を介して）使用することを可能にする複数の外部ワークステーション（例えば、図１の実施形態に示されるように、政府機関１１５、知的財産文書ライセンサ１２５、およびＥＲＰシステム１４０）を含む。本発明は、（トランスミッションコントロールプロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）を介して）インターネット１２０以外の、非同期ダイアルアップおよび非同期リースラインを含むがこれらに限られない通信方法を介して、これらの外部ワークステーションと通信し得ることに留意されたい。非同期ダイアルアップ、非同期リースライン、およびＴＣＰ／ＩＰ通信は、当該分野に周知の用語である。政府機関１１５および知的財産文書ライセンサ１２５については、次で述べる。
【００２３】
政府機関１１５は、米国特許商標庁、外国の特許商標局、および知的財産ドメインにある政府機関を含む。知的財産文書ライセンサ１２５は、知的財産文書の使用を認可する企業体または個人を含む。ＥＲＰ（エンタプライズリソースプラニング）システム１４０は、次に記載される。
【００２４】
ＥＲＰシステム１４０は、計画、製造、営業およびマーケティングを含むビジネスの多くの面を統合する。ＥＲＰの方法がより普及してきたために、ソフトウェアアプリケーションが出現し、事業経営者がＥＲＰを実施するのを助けてきた。しばしばＥＲＰは、知的財産文書および全く異なる知的財産ソフトウェアシステムで電子知的財産文書を送信し受信する必要性を含む。
【００２５】
図２は、本発明の一実施形態によるネットワークによって好適に接続される知的財産プロトコルシステム１１０の機能またはモジュールのブロック図である。図２の特定の知的財産プロトコルシステムは、説明のためだけに示されており、本発明を限定しないことを理解すべきである。本明細書に記載された機能を実行するための他の実施形態は、本明細書に含まれる教示に基づいて当業者に明らかであり、本発明はそのような他の実施形態に関する。当業者に明らかなように、知的財産プロトコルシステム１１０の「内側の」機能のすべては、好適にはネットワーク２２０などの通信媒体を介して接続され、そして通信する。
【００２６】
図２に示されるネットワーク２２０のトポロジは、バストポロジと呼ばれる。ネットワークのトポロジは概して、システム内の機能（すなわち、コンピュータ）の幾何学的配置である。他の通常のタイプのネットワークトポロジは、スタートポロジ、およびリングトポロジを含む。本発明は、バストポロジを組み込んだ状態で図２に示されるが、本発明は、他のトポロジにも等しく適用され得る。
【００２７】
知的財産プロトコルシステム１１０は、知的財産プロトコル機能２０５、知的財産データおよび処理交換機能２１０、プレゼンテーション機能２１５、および管理機能２３０を含む。本発明は、これらの機能に限定されない。図２に示される知的財産プロトコルシステム１１０の機能は、以下に、本発明の知的財産プロトコルの実施形態の記載の後、セクションＶＩＩＩ中で詳細に記載される。
【００２８】
（Ｂ．本発明の実施形態例）
本発明（すなわち、ＩＰＡＭサーバ１０５、知的財産プロトコルシステム１１０、フロントエンドシステム１１３、知的財産データベース１３５、またはこれらのすべての部分）は、ハードウェア、ソフトウェア、またはこれらの組合せを使用して実施され得、１つ以上のコンピュータシステムまたは他の処理システムにおいて実施され得る。実際、一実施形態において、本発明は、本明細書に記載された機能を実行し得る１つ以上のコンピュータシステムに関する。コンピュータシステム３００の一実施例が、図３に示される。コンピュータシステム３００は、プロセッサ３０３などの１つ以上のプロセッサを含む。プロセッサ３０３は、通信バス３０２に接続される。ソフトウェアの様々な実施形態が、この一例としてのコンピュータシステムに関して記載される。この記載を読了後、他のコンピュータシステムおよび／またはコンピュータアーキテクチャを使用して本発明を実施する方法は、当業者にとって明らかである。
【００２９】
コンピュータシステム３００は、好適にはランダムアクセスメモリ（ＲＡＭ）である主メモリ３０５をも含み、また２次メモリ３１０も含み得る。２次メモリ３１０は、例えば、ハードディスクドライブ３１２および／またはフロッピー（登録商標）ディスクドライブ、磁気テープドライブ、光ディスクドライブ等を表すリムーバブル格納ドライブ３１４、を含み得る。リムーバブル格納ドライブ３１４は、周知の方法で、リムーバブル格納ユニット３１８から読み込み、および／またはリムーバブル格納ユニット３１８へ書き込む。リムーバブル格納ユニット３１８は、フロッピー（登録商標）ディスク、磁気テープ、光ディスクなどを表し、これらは、リムーバブル格納ドライブ３１４によって読み込まれ、そしてリムーバブル格納ドライブ３１４へ書き込まれる。理解されるように、リムーバブル格納ユニット３１８は、コンピュータソフトウェアおよび／またはデータを格納したコンピュータ使用可能格納媒体を含む。
【００３０】
別の実施形態において、２次メモリ３１０は、コンピュータプログラムまたは他のコマンドがコンピュータシステム３００にロードすることを可能にする他の同様の手段を含み得る。そのような手段は、例えば、リムーバブル格納ユニット３２２およびインターフェース３２０を含み得る。そのような例は、プログラムカートリッジおよびカートリッジインターフェース（ビデオゲームデバイスに見られるものなど）、リムーバブルメモリチップおよび付属ソケット（ＥＰＲＯＭ、またはＰＲＯＭなど）、ならびにソフトウェアとデータがリムーバブル格納ユニット３２２からコンピュータシステム３００へ送信されることを可能にする他のリムーバブル格納ユニット３２２およびコンピュータインターフェース３２０を、含み得る。
【００３１】
コンピュータシステム３００はまた、通信インターフェース３２４をも含み得る。通信インターフェース３２４は、ソフトウェアおよびデータがコンピュータシステム３００と外部デバイスとの間で送信されることを可能にする。通信インターフェース３２４の例は、モデム、ネットワークインターフェース（イーサネット（登録商標）カードなど）、通信ポート、ＰＣＭＣＩＡスロットおよびカードなどを、含み得る。通信インターフェース３２４を介して送信されるソフトウェアおよびデータは、通信インターフェース３２４によって受信され得る電子、電磁、光、または他の信号であり得る信号３２８の形式にある。これらの信号３２８は、通信路（すなわち、チャンネル）３２６を介して通信インターフェース３２４へ提供される。このチャンネル３２６は、信号３２８を搬送し、そしてワイヤまたはケーブル、光ファイバー、電話回線、携帯電話リンク、ＲＦリンク、および他の通信チャンネルを使用して実施され得る。
【００３２】
本明細書において、用語「コンピュータプログラム製品」は、リムーバブル格納ユニット３１８、３２２、および／または信号３２８を指す。これらのコンピュータプログラム製品は、ソフトウェアおよび／またはデータをコンピュータシステム３００へ提供する手段である。本発明は、そのようなコンピュータプログラム製品へ向けられている。
【００３３】
コンピュータプログラム（コンピュータ制御論理とも呼ばれる）は、主メモリ３０５および／または２次メモリ３１０中に、ならびに／あるいはコンピュータプログラム製品中に格納される。コンピュータプログラムはまた、通信インターフェース３２４を介して受信され得る。そのようなコンピュータプログラムは、実行されると、コンピュータシステム３００が本明細書で説明するように本発明の特徴を実行することを可能にする。特に、コンピュータプログラムは、実行されると、プロセッサ３０３が、本発明の特徴を実行することを可能にする。従って、そのようなコンピュータプログラムは、コンピュータシステム３００のコントローラを表す。
【００３４】
ソフトウェアを使用して本発明が実施される一実施形態において、ソフトウェアは、リムーバブル格納ドライブ３１４、ハードドライブ３１２、または通信インターフェース３２４を使用して、コンピュータプログラム製品中に格納され、そしてコンピュータシステム３００へローディングされ得る。制御論理（ソフトウェア）は、プロセッサ３０３によって実行されると、プロセッサ３０３に本明細書に記載のように本発明の機能を実行させる。
【００３５】
別の実施形態において、本発明は、例えば、特定用途向け集積回路（ＡＳＩＣ）などのハードウェア成分を使用して、主にハードウェア内で実施される。本明細書に記載される機能を実行するためのハードウェア状態マシンの実施形態は、当業者に明らかである。
【００３６】
さらに別の実施形態において、本発明は、ハードウェアおよびソフトウェア両方の組合せを使用して実施される。
【００３７】
本発明の知的財産プロトコルの一実施形態は、次に記載される。
【００３８】
（ＩＩＩ．本発明の一実施形態によるＣＰＭＬ  ＤＴＤ）
上記のように、知的財産データベース１３５は、本発明の知的財産プロトコルの１つ以上の実施形態に準拠したデータオブジェクトを格納する。本発明の１実施形態では、汎用知的財産プロトコルが、拡張されたマークアップ言語（ＸＭＬ）に準拠する包括的特許マークアップ言語（ＣＰＭＬ）の文書タイプ定義（ＤＴＤ）として実施される。ここで、ＣＰＭＬ  ＤＴＤに準拠する文書は、ＣＰＭＬ文書、または時には汎用知的財産文書（上記）と呼ばれる。これらの名前が示すように、本発明のＣＰＭＬ  ＤＴＤは非常に強力であり、且つ多くの機能のために使用され得る。このことは、以下に図４を参照して記載される。
【００３９】
本質的に、ＣＰＭＬ  ＤＴＤは知的財産管理のためのデータ規則およびフォーマットを指定するＸＭＬ知的財産プロトコルである。これは、例えばＵＳＰＴＯ職員録仕様（Ｒｅｄ  Ｂｏｏｋ  ｓｐｅｃｉｆｉｃａｔｉｏｎ）および文書提示に関するＣＭＬとは非常に違う。いくつかの実施形態においては、ＣＰＭＬ  ＤＴＤはそのアプリケーション内にこれらのＤＴＤを含む。ＤＴＤおよびＸＭＬの双方は当該および関連技術分野において周知であるが、以下にＤＴＤとＸＭＬを簡単に概観する。
【００４０】
上で検討したように、実行時のコンピュータプログラムによって、コンピュータ３００（図３）が本明細書において検討されるような本発明の機能を実行することが可能となる。１実施形態では、本発明はアクティブなサーバページ、ＸＭＬおよび格納されたプロシージャを使用して実施される。ＸＭＬは提示マークアップ言語であり、且つデータ記述言語として使用される。ＸＭＬは、ＳＧＭＬの機能縮小版（ｐａｒｅｄ−ｄｏｗｎ  ｖｅｒｓｉｏｎ）であり、且つ特にウェブ文書のために設計されている。ＸＭＬによって、設計者は自分自身のカスタマイズされた固有のタグを作成し、ＨＴＭＬでは利用可能でない機能を提供することが可能となる。例えば、各々が一つの送信先のみを参照し得るＨＴＭＬリンクに対し、ＸＭＬは複数文書を指し示すリンクをサポートする。
【００４１】
タグは、文書または文書の一部分がどのようにフォーマットされるべきであるかを指定する文書内に挿入される、コマンドまたはマーカーである。タグはテキストファイルとして文書を格納するフォーマット仕様によって使用される。これは、ＳＧＭＬおよびＨＴＭＬを含む。したがって、本発明の１実施形態では、設計者は知的財産プロトコル機能２０５の機能の各々をタグとして実施する。
【００４２】
ＳＧＭＬおよびＸＭＬ文書と関連するファイルタイプは、文書タイプ定義またはＤＴＤと呼ばれる。ＤＴＤは、タグが文書を提示するアプリケーションによりどのように解釈されるべきであるかを定義するファイルタイプである。ウェブページがウェブブラウザによりどのように表示されるべきかを定義するＨＴＭＬ仕様は、ＤＴＤの一例である。本質的には、本発明向けＤＴＤは、知的財産文書が特定の規格に準拠する知的財産ドメインにおいて当業者間での契約を表示する。本発明のＣＰＭＬ  ＤＴＤは、次に図４を参照してより詳細に記載する。
【００４３】
図４は、本発明の実施形態による、包括的特許マークアップ言語（ＣＰＭＬ）ＤＴＤ４０２を概念的に示す。ＣＰＭＬ  ＤＴＤ４０２は、複数個の他のＤＴＤを含む。あるいは、図４に示されるＣＰＭＬ  ＤＴＤ４０２のコンポーネントは、１つ以上の別々のＤＴＤとして共にグループ化され得る。好ましくは、図４のＤＴＤはＸＭＬに準拠するが、本発明はこの実施形態に限定されない。
【００４４】
ＣＰＭＬ  ＤＴＤ４０２は、１つ以上の特許ＤＴＤ４０３を含む。これらの特許ＤＴＤ４０３は特許文書を表す。図５に示されるように、特許ＤＴＤ４０３は、ＵＳＰＴＯ職員録ＤＴＤ５０４（ＵＳＰＴＯにより出版されたＵＳＰＴＯ職員録の仕様（１９９８年３月付け）に記載されており、その全体は本明細書中に参考として援用される）および／またはＰＣＴまたはＥＰＯ  ＤＴＤ５０６などの他の特許庁の特許ＤＴＤを含むか、または表し得る。特許ＤＴＤ４０３はまた、特許相当テキストファイル（ＥＱＶ）５０２（上記）に含まれる情報を含むか、または表し得る。
【００４５】
ＣＰＭＬ  ＤＴＤ４０２は、商標、企業秘密、著作権、概念文書などのその他のＩＰ（知的所有権）をサポート、および表すためにＤＴＤ４０４を含む。
【００４６】
ＣＰＭＬ  ＤＴＤ４０２は、ＵＳＰＴＯおよび／またはその他の特許庁の手続きを表すためにＤＴＤ４０６を含む。
【００４７】
ＣＰＭＬ  ＤＴＤ４０２は、特許のライセンシング、追跡、監査、支払いなどを表しおよびサポートするためにＤＴＤ４０８を含む。
【００４８】
ＣＰＭＬ  ＤＴＤ４０２は、任意のタイプの事務処理作業を表しおよびサポートするためにＤＴＤ４１０を含む。
【００４９】
ＣＰＭＬ  ＤＴＤ４０２は、注釈および注釈の交換を表しならびにサポートするためにＤＴＤ４１２を含む。
【００５０】
ＣＰＭＬ  ＤＴＤ４０２は、報告および報告作業を表しおよびサポートするためにＤＴＤ４１４を含む。
【００５１】
ＣＰＭＬ  ＤＴＤ４０２は、図４に示される機能に限定されない。図４の例は、説明の目的のみのために提供される。
【００５２】
図６は、知的財産のドメインにおいて二人の当事者または二人のクライアント間で交換され得る、種々のタイプのＣＰＭＬ知的財産文書（ＣＰＭＬ  ＤＴＤ４０２に準拠する）を示す。次に、本発明のＣＰＭＬ  ＤＴＤの様々な特徴を記載する。
【００５３】
（Ａ．ＣＰＭＬ  ＤＴＤはＩＰＡＭサーバの実施形態により認識および供給される構造化文書データの結合である）
ＣＰＭＬ  ＤＴＤ仕様は、ＩＰＡＭサーバ１０５の実施形態により使用される構造化文献のデータの結合を含む。実施形態において、このデータはＩＰ＿ＤＯＣＵＭＥＮＴテーブルのサブテーブル、ＩＰＡＭサーバデータベース内のサテライト（ｓａｔｅｌｌｉｔｅ）、および検索データベース（インデックス）内にある要約を含む。これによって、ＩＰＡＭサーバ１０５が、もっぱらＸＭＬから必要なデータを抽出し得ることを確実にし、インデックスおよびデータベースフラットファイル生産供給（ｄａｔａｂａｓｅ  ｆｌａｔｆｉｌｅｓ  Ｐｒｏｄｕｃｔｉｏｎ  ｓｕｐｐｌｉｅｓ）さえない場合でもこのことがあり得る。
【００５４】
（Ｂ．ＣＰＭＬ  ＤＴＤが追加構造をサポートする）
入力データの正規化が様々であるとき、ＣＰＭＬ  ＤＴＤは正規化されていないデータのためのセクションを有し、そして必要に応じて正規化されたフォーマット中にデータを繰り返す。正規化されたバージョンは任意である。例えば、
【００５５】
【表１】
0005143980.tif 000002
この方針は、データを使用したアプリケーションがサポートし得る正規化のレベルを有すること、およびデータが本発明者らが供給し得る正規化の最高のレベルを有することを確実にする。
【００５６】
（Ｃ．ＣＰＭＬ  ＤＴＤはＩＳＯ規格コードおよびタグに読みやすい慣用の命名方法を使用する）
上記セクション（ｂ）における例に示されるように、可能なかぎり規格が使用される。例えば、「ＵＳ」はアメリカに対するＩＳＯ規格コードであり、「ＣＡ」はカリフォルニアに対するＩＳＯ規格コードである。
【００５７】
タグ用の慣用の命名方法は、比較的読みやすく、且つ長い名前を含むのが好ましい。その名前が占めるディスクスペースは画像の記憶装置と比較すると大したことはない。読みやすい名前を有することは、人間が文書を操作することを可能にする。読みやすい名前はＣＰＭＬ  ＤＴＤを第三者に説明することを容易にする。
【００５８】
（Ｄ．ＥＱＶフォーマットはＩＰＡＭサーバにてＣＰＭＬ  ＤＴＤと交換され得る）
好ましくは、ＩＰＡＭサーバ１０５はＸＭＬ知的財産文書を電子文書として受け取る。
【００５９】
ＸＭＬ知的財産文書は、特許相当テキストファイルが格納されていたのと同様に格納され、そして特許相当テキストファイルがＩＰＡＭサーバ１０５に配達されたのと同様にＩＰＡＭサーバ１０５に配達される。ＩＰＡＭサーバ１０５に対する変化には次のものが含まれる。
【００６０】
＊ＩＰＡＭサーバ１０５は、ＥＱＶフォーマットに相当するフォーマットとしてＸＭＬを認識しなければならず、そして要求時にはＸＭＬ知的財産文書を返送しなければならない。
【００６１】
＊ＩＰＡＭサーバ１０５は、特定の知的財産文書用ＸＭＬを要求する新しいコマンドを有する。
【００６２】
＊ドメインは、ＥＱＶフォーマットの文書を渡すためのデータパスを有していたのと同様に、ＸＭＬフォーマットの文書を渡すための新たなるデータパスを有する。あるいは、ユーザインターフェースの二重操作の手間を省くために、および注釈下位システムのいくらかの複雑性を省くために、それをＩＰＡＭサーバ１０５のユーザインターフェースに渡す前に、ドメインはＸＭＬフォーマットの文書をＥＱＶフォーマットのファイルに変換し得る。
【００６３】
＊ＩＰＡＭサーバ１０５のユーザインターフェースは、文書を適切に表示する。
【００６４】
＊全注釈下位システムは、画像文書またはＥＱＶ文書よりは、ＸＭＬ文書にて注釈をつけることを取り扱い得る。
【００６５】
本発明は以下のタスクを達成するツールを含む。すなわち、すべての入力データをＸＭＬに翻訳するタスク、特定の文書のための異なるデータを１つのＸＭＬ文書に併合するタスク、変更およびバージョン文書を追跡するタスク、一組の文書のＸＭＬからインデックスおよびデータベースフラットファイルを作成するタスク、ならびにＸＭＬフォーマット文書を下位互換性ＥＱＶフォーマット文書へと変換するタスクを含む。
【００６６】
（Ｅ．ＣＰＭＬ  ＤＴＤは、オリジナル文書にて存在する化学物質、表および数学的情報などを含む実用的な量の情報を保持する）
オリジナルの構造化データは後の使用のために、そのデータを「避けること」（例えば、処理命令においてそれにコメントする、またはそれを包むこと）によって保持され得るが、「避けること」自体はさらなる処理を促進するものではない。その情報を処理するためには、処理中のソフトウェアが理解する意味論的コンテキストにその情報が入れられなくてはならない。処理中のソフトウェアにすべてのオリジナルフォーマットを理解させるよりは、オリジナルフォーマットが１つのフォーマットに翻訳されるべきである。
【００６７】
（Ｆ．ＣＰＭＬ  ＤＴＤは、ＸＭＬインターフェースを介してグループおよび注釈にアクセスするためのＩＰＡＭサーバインターフェースを含む）
本発明のＸＭＬおよびＣＰＭＬ  ＤＴＤはまた、ＩＰＡＭサーバ１０５のための出力フォーマットとして有用である。ＸＭＬはプラットフォームに依存しない構造化コンテンツフォーマットを提供する。グループ、文書および注釈は、ＩＰＡＭサーバ１０５により出力され得る。
【００６８】
注釈は、いくつかのオプションのフラッグおよび注釈セグメントを含む。注釈セグメントは、「開始」アンカー（ｓｔａｒｔ  ａｎｃｈｏｒ）、「終了」アンカー（ｅｎｄ  ａｎｃｈｏｒ）、および注釈にはめ込まれ得または注釈により示され得る、所定のコンテンツを有する。注釈はまたグループまたは所有者を参照し得る。可能なＸＭＬフォーマットを以下に示す。
【００６９】
【表２】
0005143980.tif 000003
グループは、注釈、文書、およびその他のグループを含む。グループは親を参照する。注釈は参照されるか、またはグループ内に直接埋め込まれ得る。可能なＸＭＬフォーマットを以下に示す。
【００７０】
【表３】
0005143980.tif 000004
本発明のＣＰＭＬ  ＤＴＤは、このデータに「それ自体の生命」を与える。例えば、ある人は注釈を同僚に送信し得、そして同僚は（電子メールリーダーに適切なＸＭＬプラグインを有した）電子メールリーダーを用いそれを見得る。同僚がグループコンテキストを所望する場合、その同僚はＷｏｒｋＢｅｎｃｈに要求を送信する「グループ」リンクに従う。
【００７１】
（Ｇ．ＣＰＭＬ  ＤＴＤは、第３者のコンテンツマネ−ジャーのための１組のＸＭＬインターフェースを含み、これによりユーザが後にＩＰＡＭを介してそのコンテンツマネ−ジャーを使用できるようにする）
ＸＭＬはサードパーティのサーチエンジンおよび文書サーバにフックするためのバックエンドインターフェースとして使用され得る。ＩＰＡＭサーバ１０５は、中央検索サーバにアクセスするためにインターフェースを使用する必要がある。そのインターフェースはＸＭＬ内にあり、且つ比較的汎用である場合、プラットフォームに依存しない規格を提供する。
【００７２】
（Ｈ．ＣＰＭＬ  ＤＴＤはクレーム構造サポートを提供する）
ＣＰＭＬ  ＤＴＤの実施形態は、構造化クレーム情報を有する。クレーム構造は、（１）クレーム番号、（２）独立クレーム情報、（３）オプションの従属節を有するプリアンブル、および（４）多くの要素を有する本文を有する。ＣＰＭＬ  ＤＴＤは上記にリストした様々な量の構造をサポートする。ＣＰＭＬ  ＤＴＤの１例を、図７Ａ〜７Ｃを参照して次に検討する。
【００７３】
（ＩＶ．本発明の１実施形態に基づくＣＰＭＬ  ＤＴＤの例）
ＣＰＭＬ  ＤＴＤ７０２の１例は、図７Ａ〜７Ｃに示される。本発明の１実施形態によると、ＣＰＭＬ  ＤＴＤ７０２の目標は、ＩＰＡＭサーバデータベースおよびインデックス中にあるテキスト構造および文献のタグを含むことである。ＣＰＭＬ  ＤＴＤ７０２と、ＩＰＡＭサーバデータベースおよびインデックス中のデータとがどのように関連するかは、図１０Ｇ〜１０Ｉを参照して下に記載する。本発明は、ＣＰＭＬ  ＤＴＤ７０２に限定されない。図７Ａ〜７Ｃの例は、説明の目的のみに提供され、そしてそれに限られない。他のＤＴＤは、本明細書に含まれる教示に基づく場合、当業者には明らかである。
【００７４】
ＣＰＭＬ文書において、特許の情報とセクションはＣＰＭＬ  ＤＴＤ７０２のそれぞれのタグに格納される。
【００７５】
ＣＰＭＬ  ＤＴＤ７０２は、以下に記載される。
【００７６】
ＣＰＭＬ  ＤＴＤ７０２の例の理解を補助するために、表１〜表３を含む次の３つの表が提供される。表１は、ＤＴＤにおける要素構造を指定するためのいくつかの通常のシンボルをその説明と共に示す。
【００７７】
【表４】
0005143980.tif 000005
次の表２は、ＤＴＤにおけるいくつかの一般的な属性タイプを、その説明と共に示す。
【００７８】
【表５】
0005143980.tif 000006
最後の表である表３は、属性のデフォルト値をその説明と共に示す。
【００７９】
【表６】
0005143980.tif 000007
ＣＰＭＬ  ＤＴＤ７０２の例は、好ましくは各々の文書の明確な部分のための、別個のセクションを含む。図７Ａを参照し、ラベル７０３は、ＣＰＭＬ  ＤＴＤ７０２を作成するために共にグループ化された、要素リスト（ＥＬＥＭＥＮＴ）を示す。上の表１からは、括弧が要素をグループ化することが分かる。したがって、「ｐａｔｅｎｔ」を構成する要素またはセクションは、「Ｂｉｂｌｉｏｇｒａｐｈｙ」、「Ａｂｓｔｒａｃｔ」、「ＵｎｓｔｒｕｃｔｕｒｅｄＢｉｂｌｉｏｇｒａｐｈｙ」、「ＢｒｉｅｆＳｕｍｍａｒｙＯｆＩｎｖｅｎｔｉｏｎ」、「ＤｅｓｃｒｉｐｔｉｏｎＯｆＤｒａｗｉｎｇｓ」、「ＤｅｓｃｒｉｐｔｉｏｎＯｆＩｎｖｅｎｔｉｏｎ」および「Ｃｌａｉｍｓ」を含む。表１から分かるように、コンマがこれらの要素の各々を離すため、指定されたシーケンスにて現れるためには要素が必要である。したがって、「Ｂｉｂｌｉｏｇｒａｐｈｙ」要素は、最初に現れる必要がある。この順序の次のものは、「Ａｂｓｔｒａｃｔ」要素である。ＣＰＭＬ  ＤＴＤ７０２は、「ａｂｓｔｒａｃｔ」要素が「Ｂｉｂｌｉｏｇｒａｐｈｙ」要素から区別されることを表す。本発明の別の実施形態では、「Ａｂｓｔｒａｃｔ」要素が「Ｂｉｂｌｉｏｇｒａｐｈｙ」要素の内側にあり得る。「Ｂｉｂｌｉｏｇｒａｐｈｙ」要素または「Ａｂｓｔｒａｃｔ」要素の後にはシンボルがないため、これらの要素は一度のみ現れる。
【００８０】
この順序の次の３つ要素（「ＵｎｓｔｒｕｃｔｕｒｅｄＢｉｂｌｉｏｇｒａｐｈｙ」、「ＢｒｉｅｆＳｕｍｍａｒｙＯｆＩｎｖｅｎｔｉｏｎ」および「ＤｅｓｃｒｉｐｔｉｏｎＯｆＤｒａｗｉｎｇｓ」）がそれぞれ疑問符で終わることに留意されたい。表１から、このことは、これらの要素のそれぞれが、必要に応じて一度現れるのみであり得るということを示している。この順序の次のものは、一度現れる必要のある「ＤｅｓｃｒｉｐｔｉｏｎＯｆＩｎｖｅｎｔｉｏｎ」である。４つの先行する要素またはセクションは、特許のテキストセクションであると考えられる。図７Ａ〜７Ｃの実施形態が４つのテキストセクションを示しながらも、５、１０、または任意の数に容易になり得ることに留意されたい。
【００８１】
最後に、一度現れなくてはならない必須の「クレーム」要素がある。
【００８２】
また、図７Ａを参照すると、ラベル７０４は、一般的に各属性のための値と関連する、属性リスト（ＡＴＴＬＩＳＴ）を示す。図示される属性は、「ＭａｊｏｒＶｅｒ」、「ＭｉｎｏｒＶｅｒ」、および「ＧＵＩＤ」を含む。例えば、属性「ＭａｊｏｒＶｅｒ」は値０、１、２などを有し得るが、リストされた値の一つを有さなければならない。＃ＲＥＱＵＩＲＥＤ（表３）は、属性「ＭａｊｏｒＶｅｒ」が要素のすべてのインスタンスにおいて一つの値を有さなければならないということをパーサに示す属性デフォルトである。この属性を含まない場合、パーシングエラーが生じる。属性「ＭｉｎｏｒＶｅｒ」は「ＭａｊｏｒＶｅｒ」と同様の方法で定義される。属性「ＧＵＩＤ」は（表２用ＩＤによって示される）要素を識別する一意の値を有さなければならない。かさねて、＃ＲＥＱＵＩＲＥＤは「ＧＵＩＤ」が要素のすべてのインスタンスにおける値を有さなければならないことを示す。
【００８３】
ラベル７０５は、正規化されたタグのリストを示す。本発明のこの実施形態では、正規化されたタグは多くの場所で現れる共通のセットのタグである。これらの正規化されたタグが現れるとき、所定のデータの正規化を約束する。正規化されたタグは、日付（Ｄａｔｅ）、出版組織（ＰｕｂＯｒｇ）、文書の種類（Ｋｉｎｄ）、数（Ｎｕｍ）、および国（Ｃｎｔｒｙ）のためのタグを含む。特に、Ｄａｔｅは常にＹＹＹＹＭＭＤＤの形であり、ＰｕｂＯｒｇは、ＷＩＰＯ規格３において見られるタグが許されるのみで、Ｋｉｎｄは指定の慣用の命名方法に従い、Ｎｕｍは常に純粋に数字であり、ＣｎｔｒｙはＩＳＯ指定の国が許されるのみである。
【００８４】
ラベル７０６は共通タグおよびエンティティのリストを示す。本発明のこの実施形態では、共通タグは１箇所より多く現れるが、正規化されない。この要素はＣＰＭＬ  ＤＴＤ７０２においてパラグラフなどの、テキストのためのフォーマットを指定する。
【００８５】
ラベル７０７は、特許文献タグのリストを示す。この実施形態は、文献タグの異なる分類をサポートする。すなわち、識別子により文書を識別するために役立つ識別子、その他の文書に対する参照、法的項目、分類，その他の雑多な情報である。これらの文献分類は次のように組織される。
【００８６】
文献データ
識別子（すなわち、この文書を他のものから区別するのに役立つデータ）
タイトル
公開および審査機関（ＥＰＯ、ＵＳＰＴＯ等）
文書の種類（出願、特許、再発行）
公開番号（文書固有の番号）
出願番号
要約（典型的または表示的な図と共に、またはなしで）
その他の文書に対する参照
引用文献
審査官引用の引用文献（通常調査報告引用文献のサブセット）
出願人引用の引用文献（典型的には固有の文書にて埋め込まれる）
特許ファミリー
特許出願
関連する出願
関連する譲渡された特許
パリ条約にて優先権を移行する外国出願
優先権主張出願
優先権主張日
優先権主張国
特許協力条約下における優先権を移行するＰＣＴ国際特許出願
法的項目
発明者
譲受人
発明者または譲受人の法的代理（誰、どの会社など）
特許審査官
指定国
関連日（提出出願日、公開日、あれば発行または譲渡日、および再発行
日）
文書の分類
国内
国際（国際特許分類、通常ＩＰＣの版が同じくリストされる）
これらの範疇は利便性の目的にのみ使用される。本発明はこの例に限られない。
【００８７】
ＣＰＭＬ  ＤＴＤのいくつかの実施形態は、これら文献のフィールドのすべてを有し得、他のＤＴＤ実施形態はそのフィールドの下位セットを有し得る。図７Ａ〜７Ｃの例においては、文献タグは、以下のように組織される。すなわち、一般情報７０７、識別子７０８、他の文書への参照７０９、法的項目７１０（すなわち、譲受人の権利を独占にまで強化するデータ）、分類７１１、およびその他の雑多な情報７１２である。
【００８８】
ラベル７０７を参照すると、一般情報に関連する文献タグが図示される。上記の表１から、括弧が要素をグループ化することが分かる。表１からはまた、コンマがこれらの要素それぞれを区別するため、要素が指定の順序において現れる必要があることが分かる。したがって、一般情報に関連する文献タグを構成する要素またはセクションは以下のようである。
【００８９】
Ｔｉｔｌｅ：一度のみ現れなくてはならない
ＰｕｂＮｏ：タイトルの後に一度のみ現れなくてはならない
ＡｐｐＮｏ：ＰｕｂＮｏの後に一度のみ現れなくてはならない
ＰａｔｅｎｔＲｅｆ＊：任意の数のＰａｔｅｎｔＲｅｆが連続で現れ得る、ゼロでもよい
ＦｉｌｉｎｇＤａｔｅ：連続で現れなくてはならない、そして一度のみ現れなくてはならない
ＩｓｓｕｅＤａｔｅ？：それがある場合はＦｉｌｉｎｇＤａｔｅの後に一度のみ現れなくてはならないがオプションである
ＰｕｂｌｉｃａｔｉｏｎＤａｔｅ？：それがある場合は連続で一度のみ現れなくてはならないが、オプションである
ＣａｌｃｕｌａｔｅｄＥｘｐｉｒａｔｉｏｎＤａｔｅ？：それがある場合は連続で一度のみ現れなくてはならないが、オプションである
Ａｓｓｉｇｎｅｅ＊：任意の数の指定代理人が連続で現れ得る、ゼロでもよい
Ｉｎｖｅｎｔｏｒ＊：任意の数の発明者が連続で現れ得る、ゼロでもよい
Ｐｒｉｏｒｉｔｙ＊：本特許が優先権を主張している任意の数の参考文献が連続で現われ得る、ゼロでもよい
ＤｅｓｉｇｎａｔｅｄＳｔａｔｅｓ：連続で現れなくてはならない、且つ一度のみ現れなくてはならない
ＩＰＣ＊：任意の数のＩＰＣが連続で現われ得る、ゼロでもよい
ＵＳＣｌａｓｓｉｆｉｃａｔｉｏｎ＊：ＵＳ分類の任意の数が連続で現われ得る、ゼロでもよい
ＰｕｂｌｉｃａｔｉｏｎＬａｎｇｕａｇｅ：連続で現れなくてはならない、且つ一度のみ現れなくてはならない
ＮｕｍＣｌａｉｍｓ？：それがある場合はＰｕｂｌｉｃａｔｉｏｎＬａｎｇｕａｇｅ後に一度のみ現れなくてはならないが、オプションである
ＮｕｍＤｒａｗｉｎｇＰａｇｅｓ？：それがある場合は連続で一度のみ現れなくてはならないが、オプションである
ＮｕｍＦｉｇｕｒｅｓ？：それがある場合は連続で一度のみ現れなくてはならないが、オプションである
ＮｕｍＳｐｅｃＰａｇｅｓ？：それがある場合は連続で一度のみ現れなくてはならないが、オプションである
これらの要素のそれぞれがさらに定義されることに留意されたい。例えば、Ｔｉｔｌｅ、ＰｕｂＮｏおよびＡｐｐＮｏは、ラベル７０８により示されるようにさらに定義される。例えば、ＰｕｂＮｏは、正規化されたタグ、すなわち順にＰｕｂＯｒｇ、Ｋｉｎｄ、およびＮｕｍ（ラベル７０５に関し上記される）を含む必要がある。
【００９０】
ＰａｔｅｎｔＲｅｆは、ラベル７０９により示されるようにさらに定義される。ＦｉｌｉｎｇＤａｔｅ、  ＩｓｓｕｅＤａｔｅ、  ＰｕｂｌｉｃａｔｉｏｎＤａｔｅ、  ＣａｌｃｕｌａｔｅｄＥｘｐｉｒａｔｉｏｎＤａｔｅ、  Ａｓｓｉｇｎｅｅ、  Ｉｎｖｅｎｔｏｒ、  ＰｒｉｏｒｉｔｙおよびＤｅｓｉｇｎａｔｅｄＳｔａｔｅｓは、各々ラベル７１０により示されるようにさらに定義される。
【００９１】
ＩＰＣおよびＵＳＣｌａｓｓｉｆｉｃａｔｉｏｎは、ラベル７１１により示されるようにさらに定義される。ラベル７１１を参照すると、ＩＰＣは、セクション、クラス、下位クラス、グループおよび下位グループの正規化されたタグを含む必要がある。ＵＳＣｌａｓｓｉｆｉｃａｔｉｏｎは、ＵＳＣｌａｓｓ、ＵＳＳｕｂｃｌａｓｓおよびＵＳＳｕｆｆｉｘの正規化されたタグを含む必要がある。
【００９２】
最後に、ＰｕｂｌｉｃａｔｉｏｎＬａｎｇｕａｇｅ、ＮｕｍＣｌａｉｍｓ、ＮｕｍＤｒａｗｉｎｇＰａｇｅｓ、ＮｕｍＦｉｇｕｒｅｓおよびＮｕｍＳｐｅｃＰａｇｅｓはラベル７１２により示されるようにさらに定義される。
【００９３】
そのセクションまたは要素要約がＣＰＭＬ  ＤＴＤ７０２において次である。要約要素はラベル７１３により示される。
【００９４】
要約セクションの後、ラベル７１４によって示される、構造化されない文献セクションが続く。７１４によってラベル付けされた構造化されない文献は、構造化されないフォーマットの所定の特許のすべての文献情報のテキスト表示を含む。この情報は、特許を与えることをサポートするために提供される。なぜなら文献情報すべてが構造化されたフォーマットに（ＣＰＭＬ  ＤＴＤ７０２をサポートする文書に）格納されるわけではない可能性があるからである。
【００９５】
上記教示に基づき、当業者は、本発明のセクションの簡単な要約がラベル７１５により示されること、図面セクションの簡単な説明がラベル７１６により示されること、発明セクションの詳細な記載がラベル７１７により示されること、およびクレームのセクションがラベル７１８により示されることを含むＣＰＭＬ  ＤＴＤ７０２の残り部分を理解する。
【００９６】
（Ｖ．例示的ＣＰＭＬ知的財産文書−米国特許）
図８Ａ〜図８Ｃは、米国特許に関する例示的ＣＰＭＬ知的財産文書を示す。図８Ａ〜８ＣのＣＰＭＬ知的財産文書は、図７Ａ〜７ＣのＣＰＭＬ  ＤＴＤ  ７０２に対応する。
【００９７】
（ＶＩ．例示的ＣＰＭＬ文書〜欧州特許）
図７Ａ〜７ＣのＣＰＭＬ  ＤＴＤ  ７０２は、米国特許だけではなく、全ての種類の特許知的財産文書をサポートする。例えば、図９Ａ〜９Ｃは、ＥＰ出願に関する例示的ＣＰＭＬ知的財産文書を示す。図９Ａ〜９ＣのＣＰＭＬ知的財産文書は、図７Ａ〜７ＣのＣＰＭＬ  ＤＴＤ  ７０２に対応する。
【００９８】
（ＶＩＩ．ＣＰＭＬ  ＤＴＤおよび他の特許ＤＴＤと例示的データベースインプリメンテーションとの間の対応）
図１０Ａ〜１０Ｉは、ＣＰＭＬ  ＤＴＤ  ７０２と他の特許関連ＤＴＤ（例えば、米国特許庁および欧州特許庁の特許関連ＤＴＤ）との間のマッピングを示す。図１０Ａ〜１０Ｉの配置を図１０Ｊ中に示す。
【００９９】
ＵＳＰＴＯの「Ｒｅｄ  Ｂｏｏｋ」ＤＴＤおよび「Ｇｒｅｅｎ  Ｂｏｏｋ」ＤＴＤはそれぞれ、縦列（ｃｏｌｕｍｎ）１００４および１００６によって表される。ＥＰＯ／ＰＣＴのＤＴＤは、縦列１００８、１０１０および１０１２によって表される。１つの実施形態によるＣＰＭＬ  ＤＴＤ  ７０２は、縦列１０１４、１０１６および１０１８によって表される。
【０１００】
図１０Ａ〜１０Ｉはまた、ＣＰＭＬ  ＤＴＤ  ７０２とＩＰＡＭサーバデータベースのフィールドとの間のマッピングも示し、これにより、ＣＰＭＬ知的財産文書からのデータをデータベースに格納する方法と、データベースを用いてＣＰＭＬ知的財産文書をポピュレートする方法とが示される。
【０１０１】
（ＶＩＩＩ．本発明の知的財産プロトコルシステムの機能の詳細な説明）
知的財産プロトコルシステム１１０の機能について、図２を参照して上記にて紹介した。知的財産プロトコルシステム１１０の機能としては、知的財産プロトコル機能２０５、知的財産データ／交換（ｅｘｃｈａｎｇｅ）処理機能２１０、提示（ｐｒｅｓｅｎｔａｔｉｏｎ）機能２１５および管理機能２３０がある。これらの機能はそれぞれ、１つ以上の機能を含み得る。
【０１０２】
（Ａ．知的財産プロトコル機能）
ＣＰＭＬ  ＤＴＤ  ７０２は、知的財産プロトコル機能２０５により行なわれる以下の機能に関するフォーマットおよび規則をサポートする：
特許および商標の手続きならびにワークフロー
特許出願および商標出願の電子提出
特許管理費および商標管理費の支払いの追跡および報告
ライセンス追跡
ライセンス監査
ライセンス支払い
知的財産メタ（Ｍｅｔａ）データ管理は、政府発行のメタデータ、ダーウェント（Ｄｅｒｗｅｎｔ）データおよび他の第３者、ＣＭＬデータ、ユーザ定義による知的財産メタデータ等を含む（但し、他のＤＴＤも含み得る）。
【０１０３】
ＥＲＰシステムとの知的財産データトランザクションデータ交換
ドケットシステム、ライセンシングシステム等
知的財産メタデータの報告および視覚化
知的財産メタデータと他の関連企業データおよび事業データとの関連付け
ＣＰＭＬ文書のＴＩＢＣＯデータ交換ワイヤフォーマット通信層等への直接的提示
新規特許情報によるクライアントまたはプレーヤの自動更新
次に、本発明の知的財産データおよび交換処理機能２１０について説明する。
【０１０４】
（Ｂ．知的財産データおよび交換処理機能）
（ＸＭＬに適合する）本発明のＸＭＬおよびＣＰＭＬ  ＤＴＤ  ７０２の強力な局面は、様々な種類のトランザクション用のデータ交換規則およびフォーマットを定義する能力である。例えば、図６を参照されたい。多くのｅコマースデータ交換構想があり、例えば、ＳＥＴ、ＪＥＰＩ、ＣｏｍｍｅｒｃｅＮｅｔ、Ｃｙｂｅｒ  Ｃａｓｈ、Ｍｉｌｌｉｃｅｎｔ、ＯＦＸ、ＸＭＬ／ＥＤＩ等がある。上記の全てのスーパーセットであるＳＧＭＬベースの構想は、Ｏｐｅｎ  Ｆｉｎａｎｃｉａｌ  Ｅｘｃｈａｎｇｅプロトコル（ＯＦＸ）である。
【０１０５】
ＯＦＸは、ＳＧＭＬベースの構想であり、電子商取引技術の共存および共同利用を可能にする。ＯＦＸは、インターネット上に広く広がる小売業基盤の発展へと続く道筋を円滑にすることを目的とする。ＯＦＸは、以下の活動に関するフォーマットをサポートし、規則を定める：
販売の申し出
購入合意
支払い
物品の移動およびサービス
配達
受取り
問題解決
ＣＰＭＬ  ＤＴＤ  ７０２は、知的財産データおよび交換処理機能２１０によって行なわれる機能に関するフォーマットおよび規則をサポートする。
【０１０６】
（Ｃ．提示機能）
本発明の提示機能２１５は、ユーザへの任意の出力のフォーマットを指定する責任を負う。本発明の実施形態において、提示機能２１５は、カスケードスタイルのシートを用いて、ＣＰＭＬ知的財産文書の出力をフォーマットする。カスケードスタイルのシートまたは一般的なスタイルシートについては、当該分野（単数または複数）で周知であるため、以下に簡単な概略のみを述べる。
【０１０７】
スタイルシートは一般的には、文書のレイアウトを規定するファイルまたはフォームである。スタイルシートに記入が行なわれる際、ページサイズ、マージンおよびフォント等のパラメータが指定される。同じスタイルシートを多くの文書に用いることが可能であるため、スタイルシートは有用である。例えば、あるスタイルシートを特許用に規定し、別のスタイルシートを特許手続き用に規定し、さらに別のスタイルシートを商標用に規定するといった具合である。スタイルシートはテンプレートとも呼ばれる。
【０１０８】
より詳細には、カスケードスタイルのシートは、フォーマット情報を文書本分から切り離して、そのフォーマット情報を、ＳＴＹＬＥ構成要素（ｅｌｅｍｅｎｔ）または別個の文書中に別個に格納することができる。さらに、インライン（ｉｎ−ｌｉｎｅ）スタイリングの場合に、ＳＴＹＬＥ属性を用いて、特定の構成要素に関するフォーマット情報を示すことも可能である。「カスケード」とは、複数のスタイルシートとインラインスタイリングとを組み合わせてマスターテンプレートを作成するタスクを簡略化し、必要に応じて改変を施す能力を指す。カスケードスタイルのシートでは文書構造をフレームワークとして用い、次いで、カスケードスタイルのシートにフォーマット情報が注釈として付加され、シートの表示（または印刷、読取りあるいは何らかの方法による表示）が、アプリケーション（典型的には、ウェブブラウザ）によって行なわれる。
【０１０９】
（Ｄ．管理機能）
管理機能２３０は、特に、管理担当者が、ＩＰＡＭサーバ１０５、知的プロトコルシステム１１０および／または知的財産データベース１３５へのユーザのアクセス権の有無を制御することを可能にする。
【０１１０】
（ＩＸ．一般的なシステムオペレーション）
以下において、知的財産プロトコルシステム１１０によって提供される機能モジュールおよび特徴をユーザがナビゲートする様態について説明する。（フロントエンドシステム１１３を介する）知的財産プロトコルシステム１１０は、インターネットを通じたワールドワイドウェブページを介して（すなわち、オンラインサービスを通じて）デスクトップコンピュータ上のユーザにより直接アクセス可能であるか、または、イントラネットを介してもアクセス可能である。別の実施形態において、（フロントエンドシステム１１３を介する）知的財産プロトコルシステム１１０は、電話サービス等を介してもアクセス可能である。本明細書中で説明する制御フローは例示目的のみのために示されている点が理解されるべきである。本発明の知的財産プロトコルシステム１１０は、ユーザが上記以外の様式でもシステム１１０をナビゲートすることを可能にするための十分な柔軟性および適合性を有する。
【０１１１】
図１１は、知的財産プロトコルシステム１１０の機能の高レベルオペレーションの一例を示す。他の高レベルオペレーションについては、図１４および１５を参照して後述する。図１１を参照して、フローチャート１１００は、工程１１０２から開始する。工程１１０２において、知的財産プロトコル機能２０５は、（フロントエンドシステム１１３を介して）ＣＰＭＬ知的財産文書を受け取る。次いで、制御は工程１１０４へと進む。
【０１１２】
工程１１０４において、知的財産プロトコル機能２０５は、受信した知的財産文書を、ＣＰＭＬ  ＤＴＤ  ７０２（図７Ａ〜７Ｃ）で書かれた適切なＤＴＤを用いて処理する。ここで、ＣＰＭＬ  ＤＴＤ  ７０２を用いて、パージングを行い、所望のデータを知的財産文書から抽出する。次いで、制御は工程１１０６へと進む。
【０１１３】
工程１１０６において、提示機能２１５が呼び出され、これにより、情報をフォーマットし、知的財産文書中に表示する。上述したように、本発明の１つの実施形態において、カスケードスタイルのシートを用いて、提示機能２１５の出力をフォーマットすることが可能である。この時点で、フローチャート１１００が終了する。
【０１１４】
フローチャート１１００の工程１１０４について、図１２を参照してさらに説明する。図１２を参照して、制御は工程１２０２から開始する。工程１２０２において、知的財産プロトコル機能２０５は、知的財産文書中のデータのうち再フォーマットが必要な箇所を判定する。知的財産文書中のデータのうち再フォーマットが必要な箇所が有る場合、知的データおよび交換処理機能２１０が呼び出され、これにより、データの再フォーマットが行なわれる。次いで、制御は工程１２０４へと進む。
【０１１５】
工程１２０４において、受け取られた知的財産文書の種類の詳細に基づいて、プロトコル機能２０５は、ＣＰＭＬ  ＤＴＤ  ７０２を参照して、（ＣＰＭＬ  ＤＴＤ  ７０２が複数のＤＴＤを含むと仮定した場合に）ＣＰＭＬ  ＤＴＤ  ７０２中のＤＴＤのうち使用するＤＴＤを判定する。次いで、制御は工程１２０６へと進む。
【０１１６】
工程１２０６において、プロトコル機能２０５は、ＣＰＭＬ  ＤＴＤ  ７０２を参照して、情報をパージングし、知的財産文書から情報を抽出する。次いで、制御は工程１２０８へと進む。
【０１１７】
工程１２０８において、知的財産文書がＣＰＭＬ  ＤＴＤ  ７０２に適合するか否かを判定する。知的財産文書がＣＰＭＬ  ＤＴＤ  ７０２に適合する場合、制御は工程１１０６（図１１）へと進む。知的財産文書がＣＰＭＬ  ＤＴＤ  ７０２に適合しない場合、制御は工程１２１０へと進む。
【０１１８】
工程１２１０において、プロトコル機能は、パージングエラーを（フロントエンドサーバ１１３を介して）ユーザに表示する。この時点で、図１２は終了する。
【０１１９】
フローチャート１１００の工程１１０６について、図１３を参照してさらに説明する。図１３を参照して、制御は工程１３０２から開始する。工程１３０２において、提示機能２１５は、リクエストされた情報をユーザに提供するためにＩＰＡＭサーバ１０５（図１）を呼び出す必要が有るか否かを判定する。次いで、制御は工程１３０４へと進む。
【０１２０】
工程１３０４において、提示機能２１５は、抽出されたデータおよび／またはＩＰＡＭサーバ１０５から受け取った任意のデータをカスケードスタイルのシートと共に用いて、ユーザに所望の出力を生成する。（異なる一式の情報の表示および／または実行中のタスクにとって有効なフォーマットに情報を表示または交換するために）実行中のタスクに応じて、様々なスタイルシートを選択および使用することが可能である。ユーザが所望する出力にデータの再フォーマットが必要な場合、データおよび交換処理機能２１０が呼び出され、これにより、当該データが正しいフォームでフォーマットされる。この時点で、図１３は終了する。
【０１２１】
上述したように、図１１は、知的財産プロトコルシステム１１０の機能の高レベルオペレーションの一例を示す。図１４および１５は、知的財産プロトコルシステム１１０の機能の高レベルオペレーションの別の例を示し、これについて次に説明する。ＣＰＭＬ  ＤＴＤ  ７０２は、複数のトランザクションをサポートする。例えば、ＣＰＭＬ  ＤＴＤ  ７０２の実施形態は、クライアント情報の自動更新をサポートする。本発明のこの機能を図１４中に示すフローチャート１４０２に示し、対応するイベント追跡図１５０２を図１５に示す。図１４を参照して、制御は工程１４０４から開始する。
【０１２２】
工程１４０４において、ホスト１５０４は、特許情報および特許関連情報をＣＰＭＬ文書１５０８を介してクライアント１５０６に提供する。ＣＰＭＬ文書１５０８は、米国特許第５，８３２，２２９号の表示物である。ＣＰＭＬ文書１５０８は、この特許に関する情報（例えば、図７Ａ〜７Ｃ中に示される情報）を含む。ＣＰＭＬ文書１５０８はまたバージョン情報も含み、現在説明している実施形態において、このバージョン情報はＣＰＭＬ  ＤＴＤの一部となっている。図１５の実施例において、バージョンはＶ１である。このバージョン情報を用いて、情報に変更が有った場合に後述するようにクライアント１５０６を更新する。次いで、制御は工程１４０６へと進む。
【０１２３】
工程１４０６において、特許情報および／または特許関連情報が変更される。例えば、特許の再分類、譲受人の変更、発明エンティティ（ｉｎｖｅｎｔｉｖｅ  ｅｎｔｉｔｙ）の変更、発行後の文書の追加等が行われ得る。これらの変更を、図１５中に１５１２として示す。次いで、制御は工程１４０８へと進む。
【０１２４】
工程１４０８において、ホスト１５０４におけるＩＰＡＭデータベースに改変を加えて、これらの変更１５１２を反映する。ホスト１５０４は、様々なソース（例えば、Ｃａｓｓｉｓ、ＵＳＰＴＯ公報等）から変更１５１２を受け取り得る。新規バージョン番号（Ｖ２）が米国特許第５，８３２，２２９号に割り当てられる。次いで、制御は工程１４１０へと進む。
【０１２５】
工程１４１０において、クライアント１５０６を、新規バージョン番号Ｖ２に関連する新規／変更情報で自動更新する。この自動更新工程は、例えば、クライアント１５０６において表示された文書のバージョン番号をチェックすることによりインプリメントされ得る。このチェック工程において、クライアント１５０６がバージョンＶ１の米国特許第５，８３２，２２９号を有することが示される。ホスト１５０４は、現在のバージョンの文書がＶ２であることを知る。従って、ホスト１５０４は、Ｖ２の米国特許第５，８３２，２２９号をＣＰＭＬ文書１５１４としてクライアントに送る。クライアント１５０６において、この新規ＣＰＭＬ文書１５１４を用いて、そのバージョンの米国特許第５，８３２，２２９号を自動更新する。この時点で、図１４中のフローチャート１４０２が終了する。
【０１２６】
（Ｘ．ＸＭＬ文書および非ＸＭＬ文書からのデータの入力）
上述したように、ＩＰＡＭサーバ１０５は、ＸＭＬ文書および非ＸＭＬ（例えば、ＥＱＶ）文書と動作可能である。これは、例えば、図１６中に図示されている。
【０１２７】
ＸＭＬサーバ１６１０は、ＸＭＬ入力１６０２（例えば、ＸＭＬ文書）を受け取る。ＸＭＬサーバ１６１０は、ＸＭＬ入力１６０２から構造化情報を自動抽出し、その構造化情報をＩＰＡＭ／会社データベース１６１２中に格納する。現在、ＥＸＣＥＬＯＮ等のＸＭＬサーバが市販されている。このようなＸＭＬサーバのうち任意のものが、本発明と共に使用可能である。
【０１２８】
本発明は、非ＸＭＬデータとも機能可能である。パーサー１６０６は、非ＸＭＬ文書であり得る非ＸＭＬ入力１６０４を受け取る。この非ＸＭＬ入力１６０４を、特定の様式でフォーマットする。パーサー１６０６は、プログラミング解析またはオンザフライ解析のいずれかを用いて、非ＸＭＬ入力１６０４のフォーマットを知る。パーサー１６０６は、非ＸＭＬ入力１６０４から情報を抽出し、ＸＭＬ文書またはデータを生成する。ＸＭＬ文書が生成されると、そのＸＭＬ文書は処理対象としてＸＭＬサーバ１６１０へと送られる。データが生成されると、そのデータは、ＩＰＡＭ／会社データベース１６１２中に格納される。
【０１２９】
（ＸＩ．電子文書の取り寄せおよびＤＴＤのダウンロード）
上述したように、ＣＰＭＬ  ＤＴＤ  ７０２（図７Ａ〜７Ｃ）は、電子データ交換／転送およびＩＰ関連トランザクションをサポートする。例えば、図６を参照されたい。本発明は、例えば、電子文書の取り寄せおよびプロトコルＤＴＤのダウンロードをサポートする（但し、これに限定されない）。この工程の一例を図１７Ａ〜１７Ｃに示す。このＤＴＤを用いて、文書を電子的に取り寄せ、その取り寄せを追跡し、取り寄せを遂行（ｆｉｌｌ  ｏｕｔ）することが可能である。図１７Ａ〜１７ＣのＤＴＤは、ＣＰＭＬ  ＤＴＤ  ７０２の一部であり得、または、ＣＰＭＬ  ＤＴＤ  ７０２とは区別され得る。
【０１３０】
（ＸＩＩ．本発明の知的財産プロトコルの別の実施形態−ＳＰＭＬ（ＳｍａｒｔＰａｔｅｎｔｓマークアップ言語））
本発明は、別の特許マークアップ言語の実施形態に関する。そのような別の実施形態はＳＰＭＬ（ＳｍａｒｔＰａｔｅｎｔｓマークアップ言語）と呼ばれる。
【０１３１】
ＣＰＭＬ文書のフォーマットはＣＰＭＬ  ＤＴＤ  ７０２によって特定される（図７Ａ〜７Ｃ）。対照的に、ＳＰＭＬ文書のフォーマットはＳＰＭＬで特定される処理（すなわち、ＳＰＭＬを処理するコンピュータプログラム）によって特定される。端効果は、通常同じである。
【０１３２】
ＤＴＤで特定される文書から処理で特定される文書への変換、および逆の変換は、本明細書中に含まれる教示に基づく関連分野の当業者には明らかである。例えば、ＳＰＭＬの処理からＤＴＤへの変換は、本明細書中に含まれる教示に基づく（単数または複数）の関連分野の当業者には明らかである。ＳＰＭＬファイルの一般的なフォーマットは文書ヘッダ、文献データ、およびフォーマットされた文書テキストを含む。本発明のＳＰＭＬの詳細部を議論する前に、ＳＰＭＬに使用されるモジュールの実施形態を説明する。
【０１３３】
図１８は、本発明のＳＰＭＬのために使用されるモデル１８００の実施形態の１例を示す。モデル１８００におけるオブジェクトはコンテナまたはリーフ（ｌｅａｆ）のどちらかと呼ばれる。コンテナはリーフを含み得、またはコンテナはさらにコンテナを含み得る。それゆえ、各コンテナは、コンテナに含まれ得るオブジェクト（例えば、コンテナまたはリーフ）のタイプを限定または抑制する。図１８を参照とすると、コンテナは文書１８０８、Ｓｅｃｔｉｏｎ  １８１０、Ｐａｒａｇｒａｐｈ  １８１２およびＬｉｎｅ  １８１４からなる。リーフは、文書複合要素（Ｃｏｍｐｏｓｉｔｅ）１８０１、Ｔｅｘｔ  １８０２、ＰａｇｅＢｒｅａｋ  １８０４、ＶｅｒｔＳｐａｃｅ  １８０６、ＢｉｂＩｔｅｍ  １８１６、ＢｉｂＬｉｓｔＯｆ  １８１８、Ｂｉｂｓｅｃｔｉｏｎ  １８２０、ＢｉｂＤａｔｅ  １８２２、ＢｉｂＮｕｍｂｅｒ  １８２４、およびＢｉｂＴｅｘｔ  １８２６からなる。各々のコンテナおよびリーフをどのように定義するかが以下で議論される。
【０１３４】
上述されたように、ＳＰＭＬファイルの汎用フォーマットは、例えば、文書ヘッダー、文献データ、およびフォーマットされた文書テキストを含む。再度、図１８を参照すると、文書１８０８は文書ヘッダーをモデルとするように使用される。ＢｉｂＩｔｅｍ  １８１６、ＢｉｂＬｉｓｔＯｆ  １８１８、Ｂｉｂｓｅｃｔｉｏｎ  １８２０、ＢｉｂＤａｔｅ  １８２２、ＢｉｂＮｕｍｂｅｒ  １８２４、およびＢｉｂＴｅｘｔ  １８２６は、文献データをモデルとするように使用される。最後に、Ｓｅｃｔｉｏｎ  １８１０、Ｐａｒａｇｒａｐｈ  １８１２、Ｌｉｎｅ  １８１４、Ｔｅｘｔ  １８０２、ＰａｇｅＢｒｅａｋ  １８０４、ＶｅｒｔＳｐａｃｅ  １８０６は、フォーマットされた文書テキストをモデルとするように使用される。これらの各々は以下で詳細に議論される。
【０１３５】
本発明はこれらの要素に限定されないことを留意する。本明細書で説明される上記の要素および構成は例示する目的のためのみに提供される。他の要素および構成は、本明細書中の教示されるものを基礎とする分野の当業者には明らかである。
【０１３６】
（Ａ．  ＳＰＭＬファイルの文書ヘッダー）
文書の第１行目は文書タイプがＳＰＭＬであることを示すタグである。このタグは：特許のデフォルトの文書タイプに対しては「ｓｐＤｏｃ」である。
【０１３７】
文書ヘッダーの第２行目はファイルに含まれるＳＰＭＬの主なバージョン番号である。
【０１３８】
文書ヘッダーの第３行目はファイルに含まれるＳＰＭＬのマイナ（ｍｉｎｏｒ）バージョン番号である。主なバージョン番号およびマイナバージョン番号は、正確なＳＭＰＬパーサにおいてスワップするために文書ビルダー（ｂｕｉｌｄｅｒ）の中で使用され得る。後で未加工のＳＰＭＬを手動で編集することが望ましい場合、チェックサムおよびファイルサイズはヘッダーに加えられない。
【０１３９】
（Ｂ．ＳＰＭＬファイルの文献データ）
文献データセクションは、次の項目を含み得るが、これらに限定されない：（ＢｉｂＴｅｘｔ  １８２６に関連する）テキストのストリング、（ＢｉｂＮｕｍｂｅｒ  １８２４に関連する）整数、（ＢｉｂＤａｔｅ  １８２２に関連する）データ、（Ｂｉｂｓｅｃｔｉｏｎ  １８２０に関連する）フォーマットされたテキストのセクション、および（ＢｉｂＬｉｓｔＯｆ  １８１８に関連する）上述された文献項目の任意のリスト。これらの要素の各々は以下でより詳細に説明される。
【０１４０】
（１．ＢｉｂＴｅｘｔ）
ＢｉｂＴｅｘｔ  １８２６におけるデータのフォーマットは以下の通りである：
Ｔ９，Ｉｎｖｅｎｔｏｒ  Ｌａｓｔ  Ｎａｍｅ，１，Ｓｍｉｔｈ
第１のコンマで区切られるフィールドはタグであり、次の情報を含む：
１）「Ｔ」によりその行はＢｉｂＴｅｘｔ項目を含んでいると識別される。
【０１４１】
２）タグに続く番号は、それがどんなテキスト項目の種類であるかを示すタイプＩＤである。これらのタイプは、既知特許テキスト要素にマッピングされ（例えば、「１」のテキストタイプＩＤは、特許番号であるテキスト項目であり、「９」のテキストタイプＩＤは、発明者の名前であるテキスト項目である）、ユーザ定義文献テキスト項目は固有なタイプＩＤに与えられる。
【０１４２】
第２のコンマで区切られるフィールドは名前であり、次の情報を含む：
１）テキスト項目に与えられる名前（例えば、「特許番号」または「発明者の姓」）。このフィールドは、既知の特許のタイプ（その情報はタイプＩＤから判定され得る）に関してはたいてい空白であることが多く、ユーザが文献テキスト項目を定義するためのデータを含む。
【０１４３】
第３のコンマで区切られるフィールドはスタイルインデックスであり、次の情報を含む：
１）テキスト項目を表示する場合に使用されるスタイルのインデックス（例えば、テキスト項目を示す「１」のスタイルインデックスは通常の９ポイントのＴｉｍｅｓ  Ｒｏｍａｎで表示されることになる）。
【０１４４】
第４のコンマで区切られるフィールドはデータであり、次の情報を含む：
１）実テキストデータ（ａｃｔｕａｌ  ｔｅｘｔ  ｄａｔａ）を含むストリング。
【０１４５】
（２．ＢｉｂＮｕｍｂｅｒ）
ＢｉｂＮｕｍｂｅｒ  １８２４におけるデータのファーマットは以下の通りである：
Ｎ５，Ｎｕｍｂｅｒ  ｏｆ  ｃｌａｉｍｓ，１６．
第１のコンマで区切られるフィールドはタグであり、次の情報を含む：
１）「Ｎ」により行がＢｉｂＮｕｍｂｅｒを含んでいることが識別される。
【０１４６】
２）タグに続く番号は、それがどんな数項目の種類であるかを示すタイプＩＤである。これらのタイプは、既知の特許ナンバー要素にマッピングされ（例えば、「５」の数タイプＩＤは、特許が有する請求項の数である数項目である）、ユーザ定義文献数項目は固有なタイプＩＤに与えられる。
【０１４７】
第２のコンマで区切られるフィールドは名前であり、次の情報を含む：
１）数項目に与えられる名前（例えば、「請求項の数」）。このフィールドは、定義された文献テキスト項目に対してたいてい空白であることが多い。
【０１４８】
第３のコンマで区切られるフィールドはデータであり、次の情報を含む：
１）データである整数値。
【０１４９】
（３．ＢｉｂＤａｔｅ）
ＢｉｂＤａｔｅ  １８２２におけるデータのフォーマットは以下の通りである：
Ｄ１，Ａｐｐｌｉｃａｔｉｏｎ  ｄａｔｅ，７  １１  １９８５．
第１のコンマで区切られるフィールドはタグであり、次の情報を含む：
１）「Ｄ」により行がＢｉｂＤａｔｅを含んでいることが識別される。
【０１５０】
２）タグに続く数は、それがどんなデータ項目の種類であるかを示すタイプＩＤである。これらのタイプは、既知の特許日付要素にマッピングされ（例えば、「１」のデータタイプＩＤは、特許の出願日であるデータ項目である）、ユーザ定義文献数項目は固有なタイプＩＤに与えられる。
【０１５１】
第２のコンマで区切られるフィールドは名前であり、次の情報を含む：
１）データ項目に与えられる名前（例えば、「出願日」）。このフィールドは、既知の特許タイプ（その情報はタイプＩＤから判定され得る）に対してたいてい空白であることが多く、ユーザが文献テキスト項目を定義するためのデータを含む。
【０１５２】
第３のコンマで区切られるフィールドはデータであり、次の情報を含む：
１）スペースにより区切られた、月、日および年。
【０１５３】
（４．ＢｉｂＳｅｃｔｉｏｎ）
Ｓｅｃｔｉｏｎ項目（例えば、ＢｉｂＳｅｃｔｉｏｎ  １８２０）内のデータのフォーマットは、文書テキストのフォーマットされたテキストセクションに類似する。２つの場所内で同じ情報を保持する困難を回避するために、顕著な違いのみがここに与えれられる。文献セクションについてのタグは、「Ｓ」ではなく「Ｂ」である。
【０１５４】
（５．  ＢｉｂＬｉｓｔＯｆ）
ＢｉｂＬｉｓｔＯｆ  １８１８項目内のデータフォーマットは以下である：
Ｌ１，  ＢｉｂｌｉｏｇｒａｐｈｉｃＤａｔａ
ｂｉｂ  項目（他のリストを含む）
〜
第１のコンマで区切られるフィールドはタグであり、以下の情報を含む：
１）「Ｌ」は、ＢｉｂＬｉｓｔＯｆを始めるものとして行を識別する。
【０１５５】
２）タグに続く数は、そのＢｉｂＬｉｓｔＯｆがどんな種類のリスト項目であるかを知らせるタイプＩＤである。これらのタイプは、公知の特許リスト要素（例えば、「２」のリストタイプＩＤは、発明者リスト項目のリストであり。「３」のタイプＩＤは、ファーストネームについてのＢｉｂＴｅｘｔ項目およびラストネームについての別の項目のような発明者を構成する全ての項目のリストである）にマッピングされ、ユーザ定義文献リスト項目は、一意なタイプＩＤを与えられる。「１」のリストタイプＩＤがすべての文書が有する必要があるリストの特定のタイプであり、これは文書が有するすべての他の文献項目を含むリストであることに留意されたい。
【０１５６】
第２のコンマで区切られるフィールドは、Ｎａｍｅ（名前）であり、以下の情報を含む：
１）リスト項目に与えられる名前（例えば、「文献データ」、「発明者リスト」または、「発明者項目」）。このフィールドは、既知の特許のタイプについてほとんどの場合空であり、（情報はタイプＩＤから判定され得る）、ユーザ定義文献テキスト項目についてのデータを含む。
【０１５７】
ＢｉｂＬｉｓｔＯｆ  １８１８内のデータの最後の部分は終了タグである：
１）リストは入れ子にされ得るので、終了タグはリストの終了をマークするために必要とされる。この終了タグは１つの行の単独の「〜」である。終了タグは、最も最近のリストの終了をマークする。例えば以下である：
Ｌ１，文献データ
Ｌ２，発明者リスト
〜  ／／これは発明者リストを終了する
〜  ／／これは文献データリストを終了する
（Ｃ．ＳＰＭＬファイルのフォーマットされた文書テキストデータ）
フォーマットされた文書テキストデータセクションは、以下の項目（しかし、これに限定されない）を含み得る：１つ以上の（セクション１８１０に関する）段落を含むセクション、１つ以上の（段落１８１２に関する）行を含む段落、１つ以上の（行１８１４に関する）テキストシーケンスを含む行、１つ以上の（行１８０２に関する）文字を含むテキストシーケンス、（ＰａｇｅＢｒｅａｋ  １８０４に関する）改ページ、（ＶｅｒｔＳｐａｃｅ  １８０６に関する）縦スペース、および（図１８に示されない）特殊文字。これらのそれぞれは、下記に、より詳細に記載される。
【０１５８】
（１．Ｓｅｃｔｉｏｎ）
Ｓｅｃｔｉｏｎ  １８１０におけるデータフォーマットは以下である：
Ｓ１，文書の第１のセクション
段落データ
第１のコンマで区切られるフィールドは、タグであり、以下の情報を含む：
１）「Ｓ」は、Ｓｅｃｔｉｏｎを始めるものとして行を識別する。
【０１５９】
２）タグに続く数は、そのＳｅｃｔｉｏｎがどんな種類のセクションであるかを知らせるタイプＩＤである。これらのタイプは、公知の特許セクションにマッピングされ、ユーザ定義セクション項目は、一意なタイプＩＤを与えられる。
【０１６０】
第２の共通の区切られるフィールドは、名前であり、以下の情報を含む：
１）セクションに与えられる名前（例えば、「発明の要旨」）。このフィールドは、既知の特許のタイプについてほとんどの場合、空であり（情報はタイプＩＤから判定され得る）、ユーザ定義文献テキスト項目についてのデータを含む。
【０１６１】
２）セクションは入れ子にされ得ないので、終了タグは必要ない。
【０１６２】
（２．Ｐａｒａｇｒａｐｈ）
Ｐａｒａｇｒａｐｈ  １８１２におけるデータフォーマットは以下である：
Ｐ１
ラインデータ
第１のコンマで区切られるフィールドは、タグであり、以下の情報を含む：
１）「Ｐ」は段落を始めるものとして行を識別する。
【０１６３】
２）タグに続く数は、段落が表示される場合、ユーザにどんな種類の字下げであるかを知らせるタイプＩＤである。これらのタイプは、既知の特許識別スタイルにマッピングされ、ユーザ定義セクション項目は、一意なタイプＩＤを与えられる。ユーザ定義字下げスタイルは、ほとんどの場合、この文書のヘッダに定義される。
【０１６４】
３）セクションは、入れ子にされ得ないので終了タグは必要ない。
【０１６５】
（３．Ｌｉｎｅ）
Ｌｉｎｅ  １８１４におけるデータのフォーマットは、単に、ファイル内の１つの行のテキストの行を構成する、テキスト項目である。
【０１６６】
＜テキストデータ＞＜テキストデータ＞＜テキストデータ＞
ＳＰＭＬファイル自身内の行が、行が始まり、終了する場合のマーカーであるので、開始タグまたは終了タグが必要ない。
【０１６７】
（４．Ｔｅｘｔ）
Ｔｅｘｔ  １８０２におけるデータフォーマットは以下である：
＜Ｔ０，これはいくつかのテキストのサンプルである＞
第１のコンマで区切られるフィールドは、タグであり、以下の情報を含む：
１）「＜Ｔ」は、テキストを開始するものとして行を識別する。
【０１６８】
２）タグに続く数は、テキストがどのように表示されるかどうかを知らせるタイプＩＤである。これらのタイプは、既知の特許テキストスタイルにマッピングされ、ユーザ定義スタイルは、一意なタイプＩＤを与えられる。ユーザ定義テキストスタイル（例えば、ボールド  イタリック  １５ポイント  Ａｒｉａｌ）は、ほとんどの場合、文書のヘッダに定義される。
【０１６９】
第２のコンマで区切られるフィールドは、データであり、以下の情報を含む：
１）実際のテキストデータを含むストリング
２）データのストリングの終了がタグ「＞」によりマークされる。文字「＞」がテキストデータの一部である必要がある場合、特別の文字（「〜＞〜」）として表されるべきである。
【０１７０】
（５．ＰａｇｅＢｒｅａｋ）
ＰａｇｅＢｒｅａｋ  １８０４におけるデータフォーマットは以下である：
＜Ｇ＞
改ページを表すために、さらなる情報は必要ない。
【０１７１】
（６．ＶｅｒｔＳｐａｃｅ）
ＶｅｒｔＳｐａｃｅ  １８０６におけるデータのフォーマットは以下である：
＜Ｖ高さ＞
これは２つの部分を含む：
１）これが縦スペースタグであることを特定するための「Ｖ」
２）高さを指定する数。１つの高さの単位がテキストの行の半分の高さに等しい。
【０１７２】
（７．ＳｐｅｃｉａｌＣｈａｒ）
テキスト配列の特殊文字に関するフォーマットは以下である：
〜ＤＥＬＴＡ〜
特殊文字のネームフィールドは「〜」によって囲まれ、以下の情報を含む：
１）特殊文字ネームを特殊文字コードにマッピングするアレイに対するルックアップ値を含むストリング。
【０１７３】
実施形態に従う本発明のフォーマットされた文書テキストの例示のフォーマットは、以下のとおりである：
Ｓ１，文書の第１セクション
Ｐ１
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
Ｐ１
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
＜Ｔ０，これは＞＜Ｔ１，サンプルである＞＜Ｔ０，いくつかの＞＜Ｔ２，様式の変更を有するテキスト。＞
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
Ｐ５
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
＜Ｔ０，これは、テキスト配列の中央にある特殊文字〜ＤＥＬＴＡ〜のサンプルである。＞
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
Ｓ４，文書の第２セクション
Ｐ２
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
Ｐ１
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
＜Ｔ０，これは＞＜Ｔ１，サンプルである＞＜Ｔ０，いくつかの＞＜Ｔ２，テキスト。＞
＜Ｔ０，これはいくつかのテキストのサンプルである。＞
（Ｄ．本発明のストリーミング機構）
ストリーミングは、定常の連続的なストリームとして処理され得るようにデータを送信する技術である。大部分のユーザ（またはクライアント）が大量のマルチメディアファイルを迅速にダウンロードするための十分な速さのアクセスを有していないので、ストリーミング技術はインターネット１２０（図１）の発達とともに益々重要になってきている。ストリーミングを用いると、クライアントブラウザまたはプラグインは、全ファイルが送信される前にそのデータを表示することを開始することができる。
【０１７４】
仕事に対するストリーミングについては、データを受信するクライアント側はそのデータを収集し、そしてそれを定常ストリームとしてそのデータを処理し、それを音声または画像へ変換しているアプリケーションへ送信することができる必要がある。このことは、ストリーミング中のクライアントが要求したより迅速にデータを受信した場合、バッファに過剰なデータをセーブする必要があるということを意味する。しかし、データが十分に迅速に来ない場合、データの提示はスムーズではない。本発明は、提示機能２１５（図２）と関連して使用される２つの異なるストリーミング技術を提供する。
【０１７５】
上記のように、本発明の提示機能２１５はユーザに対する任意の出力のフォーマットを特定することを担う。本発明の実施形態では、提示機能２１５はＳＰＭＬ知的財産文書の出力をフォーマットするためにカスケーディング型シートを使用する。カスケーディング型シートは、ＣＬＡＳＳ属性を提供する。開発者らは、コンテンツの分類を反映するために、まさにフォーマットではないこのＣＬＡＳＳ属性を使用し得る。本発明はカスケーディング型シートのＣＬＡＳＳ属性とストリーミング技術とを合わせ、以下を含む２つのストリーミング機構を提供する：テンプレートベースストリーミング機構およびビジテーションベースストリーミング機構。これらの２つの機構は、メモリ中に入り、次いでそこから出てくるＳＰＭＬファイルを取得する方法をアドレス処理する。テンプレートベースストリーミング機構は、図１９を参照して最初に説明される。次に、本発明のビジテーションベースストリーミング機構は、図２０を参照して説明される。
【０１７６】
図１９を参照すると、ＤｏｃＣｏｍｐｏｎｅｎｔＳｔｒｅａｍｅｒ  １９０２はＤｏｃＣｏｍｐｏｎｅｎｔ  １９０４のクラスへのアダプタとして作用し（図１８もまた参照）、その結果ストリーミングの挙動はＤｏｃＣｏｍｐｏｎｅｎｔ  １９０４のクラスの外へ移動し、そしてＤｏｃＣｏｍｐｏｎｅｎｔＳｔｒｅａｍｅｒ  １９０２のクラスの中へ入る。これにより、ＤｏｃＣｏｍｐｏｎｅｎｔ  １９０４は、そのＤｏｃＣｏｍｐｏｎｅｎｔ  １９０４を適合させるように使用されるＤｏｃＣｏｍｐｏｎｅｎｔＳｔｒｅａｍｅｒ  １９０２のタイプに基づくいくつかの異なる方法でストリーミングされることが可能となる。サンプルコードは以下のとおりである。
【０１７７】
ＤｏｃＣｏｍｐｏｎｅｎｔＳｔｒｅａｍｅｒストリーマ（ＤｏｃＣｏｍｐｏｎｅｎｔ）；
コート（ｃｏｕｔ）＜＜ストリーマ；
本発明のテンプレートベースストリーミング機構について、マクロが所望の異なるタイプのストリーミング毎に記載され得る。このストリーミングは、記載される必要がある文書要素のタイプ毎についてアダプタストリーマのように作用する。
【０１７８】
図２０を参照すると、本発明のビジテーションベースストリーミング機構がここで記載される。ＳｔｒｅａｍｉｎｇＶｉｓｉｔｏｒ  ２００２のクラスはＤｏｃＣｏｍｐｏｎｅｎｔ  ２００４のクラスの仮想的な方法によって受け入れられる（図１８もまた参照）。このことにより、ビジターがＤｏｃＣｏｍｐｏｎｅｎｔ  ２００４を誘導されたタイプに充てる必要なしで正確な情報をストリーミングすることが可能となる。すべてのストリーミング挙動はＤｏｃＣｏｍｐｏｎｅｎｔ  ２００４のクラスの外へ移動し、そしてＳｔｒｅａｍｉｎｇＶｉｓｉｔｏｒ  ２００２のクラスの中へ入る。このことにより、ＤｏｃＣｏｍｐｏｎｅｎｔ  ２００４が使用されるビジターのタイプに基づいたいくつかの異なる方法でストリーミングされることが可能となる。サンプルコードは以下のとおりである：
ＳｔｒｅａｍｉｎｇＶｉｓｉｔｏｒビジター（コート）；
ｃｏｍｐｏｎｅｎｔ．Ａｃｃｅｐｔ（ビジター）；
（Ｅ．本発明のアダプタクラス）
本発明の実施形態のＳＰＭＬ文書は、アダプタクラスの使用によって異なる役割に適合され得る。アダプタクラスの使用は多くの利益を提供し、これは以下を含む：ＳＰＭＬ文書を有する作業の種々の方法が含まれることが可能である；種々のインターフェイスが他の既存のインターフェイスに影響することなく本発明に加えることができる；膨れ上がった文書インターフェイスを防止する；ならびに、クライアントコードが、ＳＰＭＬ文書が果たす役割およびＳＰＭＬ文書が使用され得る方法を選択することが可能である。図２１は、同じＳＰＭＬ文書で異なるように働くために、アプリケーションが種々のアダプタを使用し得る方法の要約図を示す。
【０１７９】
図２１を参照すると、アプリケーション２１０２はアダプタ２１０６を使用して一つの方法でＳＰＭＬ文書２１１２とともに働き、そしてアダプタ２１０８を使用して異なる方法で同じＳＰＭＬ文書とともに働く。アプリケーション２１０４はアダプタ２１１０を使用してさらに異なる方法でアプリケーション２１０２と同じＳＰＭＬ文書２１１２とともに働く。同じＳＰＭＬ文書とともに異なるように働くために、どのようなアプリケーションが種々のアダプタを使用し得るかを示す具体的な図を次で説明する。
【０１８０】
図２２は、同じＳＰＭＬ文書とともに異なるように働くために、どのようなアプリケーションが種々のアダプタを使用し得るかを示す例示的の具体的な図である。図２２において、ＰａｇＴｏｏｌ  ２２０２、ＰａｇｉｎａｔｏｒＩＤ  ２２０４、ＤｏｃｕｍｅｎｔＲｅｐｏｓｉｔｏｒｙ  ２２０６、ＩｍａｇｅＲｅｓｐｏｓｉｔｏｒｙ  ２２０８、Ｐａｇｉｎａｔｏｒ  ２２１０、Ｄｏｃｕｍｅｎｔ  ２２１２、Ｃａｎｏｎｉｍａｇｅ  ２２１４およびＳｔａｔｉｓｔｉｃ  ２２１６が示される。ＰａｇＴｏｏｌ  ２２０２は、ページネータがない時のドメインについてファサード（ｆａｃａｄｅ）として作用する。ＰａｇｉｎａｔｏｒＩＤは、ページネータを識別する。ＩＤはログインし、どんなスタティクス（ｓｔａｔｉｃｓ）を誰が発生させたかを決定するために使用される。ＤｏｃｕｍｅｎｔＲｅｐｏｓｉｔｏｒｙ  ２２０６は、ＳＰＭＬファイルまたは文書が見つけられ得る位置を識別する。ＩｍａｇｅＲｅｓｐｏｓｉｔｏｒｙ  ２２０８は、ＣＡＮファイルが見つけられ得る位置を識別する。Ｓｔａｔｉｓｔｉｃ  ２２１６は、ページネータがログオン、ログオフし、ファイルを開け、ファイルをセーブし、またはファイルのページ付けを完了する時に関する情報を含む。Ｃａｎｏｎｉｍａｇｅ  ２２１４は、フォーマット情報の基礎として作用する画像データを表す。Ｄｏｃｕｍｅｎｔ  ２２１２は、フォーマット情報を有するテキストデータを含む。これはＣａｎｏｎｉｍａｇｅ  ２２１４のテキスト版である。最終的に、Ｐａｇｉｎａｔｏｒ  ２２１０は文書のフォーマット情報を変更する。Ｐａｇｉｎａｔｏｒ  ２２１０は、ページ破損および行破損を挿入および／または削除し、図参照を編集し、そしてビブ（ｂｉｂ）ページの数を編集することができる。
【０１８１】
（ＸＩＩＩ．結論）
本発明の種々の実施形態を上記で説明してきたが、それらは例示の目的で示されたのであって、限定ではないことが理解されるべきである。形式および詳細における種々の変更が本発明の意図および範囲から逸脱することなく本明細書中でなされ得ることが関連分野の当業者に明らかである。このことは、後世に発展し得る関連分野の技術および条件の点において真実である。従って、本発明は、上記の例示の実施形態のいずれによっても限定されるべきではなく、特許請求の範囲およびそれらの均等物によってのみ規定されるべきである。
【図面の簡単な説明】
【図１】  図１は、本発明の実施形態に従う動作環境を表すブロック図である。
【図２】  図２は、本発明の実施形態に従うネットワークによって接続される本発明の機能またはモジュールのブロック図である。
【図３】  図３は、本発明の実施形態に従って、本発明を実施するために好適に使用されるコンピュータシステムのブロック図である。
【図４】  図４は、本発明の実施形態に従う例示的なＣＰＭＬ  ＤＴＤを示すブロック図である。
【図５】  図５は、本発明の実施形態に従う例示的な特許ＤＴＤを示すブロック図である。
【図６】  図６は、本発明の実施形態に従って、クライアント間で伝送され得るＣＰＭＬ知的財産書類のいくつかのタイプを例示するフロー図である。
【図７Ａ】  図７Ａは、本発明の実施形態に従う例示的なＣＰＭＬ  ＤＴＤを示す。
【図７Ｂ】  図７Ｂは、本発明の実施形態に従う例示的なＣＰＭＬ  ＤＴＤを示す。
【図７Ｃ】  図７Ｃは、本発明の実施形態に従う例示的なＣＰＭＬ  ＤＴＤを示す。
【図７Ｄ】  図７Ｄは、本発明の実施形態に従う例示的なＣＰＭＬ  ＤＴＤを示す。
【図７Ｅ】  図７Ｅは、本発明の実施形態に従う例示的なＣＰＭＬ  ＤＴＤを示す。
【図８Ａ】  図８Ａは、本発明の実施形態に従う米国特許に対する例示的なＣＰＭＬ知的財産書類を示す。
【図８Ｂ】  図８Ｂは、本発明の実施形態に従う米国特許に対する例示的なＣＰＭＬ知的財産書類を示す。
【図８Ｃ】  図８Ｃは、本発明の実施形態に従う米国特許に対する例示的なＣＰＭＬ知的財産書類を示す。
【図８Ｄ】  図８Ｄは、本発明の実施形態に従う米国特許に対する例示的なＣＰＭＬ知的財産書類を示す。
【図８Ｅ】  図８Ｅは、本発明の実施形態に従う米国特許に対する例示的なＣＰＭＬ知的財産書類を示す。
【図８Ｆ】  図８Ｆは、本発明の実施形態に従う米国特許に対する例示的なＣＰＭＬ知的財産書類を示す。
【図９Ａ】  図９Ａは、本発明の実施形態に従うヨーロッパ特許出願に対する例示的なＣＭＰＬ知的財産書類を示す。
【図９Ｂ】  図９Ｂは、本発明の実施形態に従うヨーロッパ特許出願に対する例示的なＣＭＰＬ知的財産書類を示す。
【図９Ｃ】  図９Ｃは、本発明の実施形態に従うヨーロッパ特許出願に対する例示的なＣＭＰＬ知的財産書類を示す。
【図９Ｄ】  図９Ｄは、本発明の実施形態に従うヨーロッパ特許出願に対する例示的なＣＭＰＬ知的財産書類を示す。
【図９Ｅ】  図９Ｅは、本発明の実施形態に従うヨーロッパ特許出願に対する例示的なＣＭＰＬ知的財産書類を示す。
【図９Ｆ】  図９Ｆは、本発明の実施形態に従うヨーロッパ特許出願に対する例示的なＣＭＰＬ知的財産書類を示す。
【図９Ｇ】  図９Ｇは、本発明の実施形態に従うヨーロッパ特許出願に対する例示的なＣＭＰＬ知的財産書類を示す。
【図１０Ａ】  図１０Ａは、本発明の実施形態に従うＣＰＭＬ  ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｂ】  図１０Ｂは、本発明の実施形態に従うＣＰＭＬ  ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｃ】  図１０Ｃは、本発明の実施形態に従うＣＰＭＬ  ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｄ】  図１０Ｄは、本発明の実施形態に従うＣＰＭＬ  ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｅ】  図１０Ｅは、本発明の実施形態に従うＣＰＭＬ  ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｆ】  図１０Ｆは、本発明の実施形態に従うＣＰＭＬ  ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｇ】  図１０Ｇは、本発明の実施形態に従うＣＰＭＬ  ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｈ】  図１０Ｈは、本発明の実施形態に従うＣＰＭＬ  ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｉ】  図１０Ｉは、本発明の実施形態に従うＣＰＭＬ  ＤＴＤと他の特許に関連するＤＴＤとの間のマッピングを例示する。
【図１０Ｊ】  図１０Ｊは、本発明の実施形態に従う図１０Ａ〜１０Ｉの位置付けを例示する。
【図１１】  図１１は、本発明の実施形態に従う知的財産プロトコルシステムの機能をハイレベルで動作してる１例を示す。
【図１２】  図１２は、本発明の実施形態に従う図１１のステップをさらに詳細に示す。
【図１３】  図１３は、本発明の実施形態に従う図１１のステップをさらに詳細に示す。
【図１４】  図１４は、本発明の実施形態に従うクライアントの情報の自動更新を例示する。
【図１５】  図１５は、本発明の実施形態に従う図１４に対応する平行トレース図である。
【図１６】  図１６は、本発明の実施形態に従って、どのようにＩＰＡＭサーバがＸＭＬ書類および非ＸＭＬ書類（例えば、ＥＱＶ）書類と共に動作するかを示す。
【図１７Ａ】  図１７Ａは、本発明がどのように本発明の実施形態に従う電子データ書類の順序およびダウンロードプロトコルＤＴＤを支援するかを例示する。
【図１７Ｂ】  図１７Ｂは、本発明がどのように本発明の実施形態に従う電子データ書類の順序およびダウンロードプロトコルＤＴＤを支援するかを例示する。
【図１７Ｃ】  図１７Ｃは、本発明がどのように本発明の実施形態に従う電子データ書類の順序およびダウンロードプロトコルＤＴＤを支援するかを例示する。
【図１８Ａ】  図１８Ａは、本発明の実施形態に従って本発明のＳＰＭＬに使用されるモデルを例示する。
【図１８Ｂ】  図１８Ａは、本発明の実施形態に従って本発明のＳＰＭＬに使用されるモデルを例示する。
【図１９】  図１９は、本発明の実施形態に従う本発明のテンプレートベースのストリーミング機構を例示する。
【図２０】  図２０は、本発明の実施形態に従う本発明の訪問（ｖｉｓｉｔａｔｉｏｎ）ベースのストリーミング機構を例示する。
【図２１】  図２１は、本発明の実施形態に従って、出願人（ａｐｐｌｉｃａｔｉｏｎ）がどのように異なるアダプタを使用して本発明の同じＳＰＭＬ書類を異なって処理し得るかについての模式図を示す。
【図２２】  図２２は、本発明の実施形態に従って、出願人（ａｐｐｌｉｃａｔｉｏｎ）がどのように異なるアダプタを使用して本発明の同じＳＰＭＬ書類を異なって処理し得るかについての具体的な図を示す。
【図１】
0005143980.tif 000008
【図２】
0005143980.tif 000009
【図３】
0005143980.tif 000010
【図４】
0005143980.tif 000011
【図５】
0005143980.tif 000012
【図６】
0005143980.tif 000013
【図７Ａ】
0005143980.tif 000014
【図７Ｂ】
0005143980.tif 000015
【図７Ｃ】
0005143980.tif 000016
【図７Ｄ】
0005143980.tif 000017
【図７Ｅ】
0005143980.tif 000018
【図８Ａ】
0005143980.tif 000019
【図８Ｂ】
0005143980.tif 000020
【図８Ｃ】
0005143980.tif 000021
【図８Ｄ】
0005143980.tif 000022
【図８Ｅ】
0005143980.tif 000023
【図８Ｆ】
0005143980.tif 000024
【図９Ａ】
0005143980.tif 000025
【図９Ｂ】
0005143980.tif 000026
【図９Ｃ】
0005143980.tif 000027
【図９Ｄ】
0005143980.tif 000028
【図９Ｅ】
0005143980.tif 000029
【図９Ｆ】
0005143980.tif 000030
【図９Ｇ】
0005143980.tif 000031
【図１０Ａ】
0005143980.tif 000032
【図１０Ｂ】
0005143980.tif 000033
【図１０Ｃ】
0005143980.tif 000034
【図１０Ｄ】
0005143980.tif 000035
【図１０Ｅ】
0005143980.tif 000036
【図１０Ｆ】
0005143980.tif 000037
【図１０Ｇ】
0005143980.tif 000038
【図１０Ｈ】
0005143980.tif 000039
【図１０Ｉ】
0005143980.tif 000040
【図１０Ｊ】
0005143980.tif 000041
【図１１】
0005143980.tif 000042
【図１２】
0005143980.tif 000043
【図１３】
0005143980.tif 000044
【図１４】
0005143980.tif 000045
【図１５】
0005143980.tif 000046
【図１６】
0005143980.tif 000047
【図１７Ａ】
0005143980.tif 000048
【図１７Ｂ】
0005143980.tif 000049
【図１７Ｃ】
0005143980.tif 000050
【図１８Ａ】
0005143980.tif 000051
【図１８Ｂ】
0005143980.tif 000052
【図１９】
0005143980.tif 000053
【図２０】
0005143980.tif 000054
【図２１】
0005143980.tif 000055
【図２２】
0005143980.tif 000056