JP5520856B2 - 携帯用計算デバイスへの無線通信媒体を介するコンテンツ送達のためのシステムおよび方法 - Google Patents

Description

（関連出願の相互参照）
本出願は、米国特許法第１１９条により、２００１年３月２３日に出願され、「ＳＹＳＴＥＭＳ ＡＮＤ ＭＥＴＨＯＤＳ ＦＯＲ ＣＯＮＴＥＮＴ ＤＥＬＩＶＥＲＹ ＯＶＥＲ Ａ ＷＩＲＥＬＥＳＳ ＣＯＭＭＵＮＩＣＡＴＩＯＮ ＭＥＤＩＵＭ ＴＯ Ａ ＰＯＲＴＡＢＬＥ ＣＯＭＰＵＴＩＮＧ ＤＥＶＩＣＥ」と称された米国特許出願第６０／２７８，１３７号の優先権を主張する。同出願は、本明細書中で参照として援用される。

（発明の背景）
（発明の分野）
本発明は、概して、ドキュメントの無線コンテンツ送達に関し、より詳細には、無線デバイス上で再構築され、かつ、読み出されることによって要求されるドキュメントコンテンツを統括することに関する。

（従来技術の説明）
コンピュータの使用が急速に広まったために、電子ドキュメントが比較的容易にコンピュータ間で格納かつ通信される。フルデスクトップシステムおよびラップトップシステムは、インターネット等の様々な通信媒体を介してこれらのドキュメントを容易に転送する。

しかし、無線通信媒体によってこれらのドキュメントを利用し、移動無線デバイスを利用することも望まれる。これは、全体として一連の異なる問題を提示する。なぜなら、利用可能な帯域幅は、４〜４８ｋｂｐｓのオーダーであり得、短期間では、５６ｋｂｐｓよりも増えるようには期待されない。

通常、無線デバイスは、バッテリーの寿命を最大化し、同時に重量およびデバイスの物理的なサイズを最小化するように試みる。通常、そのデバイスはまた、遅いプロセッサおよび最小量のメモリを含む。同時に、デバイスは、異なる、一般的に制限された、オぺレーティングシステム、スクリーン解像度および制限されたグラフィックレンダリング能力を有する。広く多様なフォーマットを有する大きなドキュメントは、従って、これらのデバイスをそれらの標準フォーマットで用いるためにはかなり不適切または不可能である。

このように、無線デバイスがドキュメントのサイズまたはドキュメントに関係なく電子ドキュメントへのアクセスを有することを可能とするシステムを提供することが望まれる。

（本発明の要旨）
本発明は、共通のマークアップ言語を用いてドキュメントオブジェクトモデルの電子ドキュメントを解析、統括および格納するシステムを提供する。ドキュメントオブジェクトモデルは、サーバに格納され、コンテンツは、ユニバーサルコンテンツストリームフォーマットで無線デバイスに送達される。ドキュメントオブジェクトモデルおよび無線デバイスに対応するリーダを有するユニバーサルコンテンツストリームを利用することによって、電子ドキュメントは、基本的なコンテンツおよび無線伝送に必要なフォーマット情報のみに減少される。

上記の関連する利点を達成することによって、本発明は、添付の図面で示されたフォームで具現化され得る。しかし、図面は、例として示すのみであり、本発明の範囲を逸脱することなく示された明細書の構成に変更があってもよいことは、事実として注目すべきである。

様々な他の機能、特徴および本発明の付属の利点は、これらが添付の図面と共に説明された場合に完全に認識される。この図面において、同様な参照文字は、いくつかのビュー全体で、同じまたは類似の部分を示す。

図１は、データ処理システムまたはサーバを示す。ここで、情報は、インターネットを介するクライアントの無線デバイスと通信するために用いられる。 図２は、図１によって示されたデータ処理システムおよび無線デバイスのブロックダイアグラムを示す。 図３は、本発明のの個々の処理モジュールを詳述する図１のサーバに常駐する本発明のブロックダイアグラムである。 図４は、本発明に提出されたドキュメントのデータパッケージングを示す。 図５は、サーバ上のデータ処理システムによって処理された提出要求の処理フローを示すフローチャートである。 図６は、サーバデータ処理システムのサーバ通信バス（ＳＣＢ）モジュールによって処理された入来リクエストの処理フローを詳述するフローチャートである。 図７は、光学的文字認識（ＯＣＲ）、画像拡張およびベクトル変換に対するラスター（Ｒ２Ｖ）用の外部処理を呼び出す前処理モジュールの処理フローを詳述するフローチャートである。 図８は、ドキュメントオブジェクトモデル（ＯＤＭ）を構築する際のドキュメントアナトミー（ａｎａｔｏｍｙ）を構成するために用いられるデータ処理システムアナトミゼーションモジュールをの処理フローを詳述するフローチャートである。 図９は、提出されたドキュメントのコンテンツにインデックス付けするインデックシングモジュールの処理フローを詳述するフローチャートである。 図１０は、無線／有線クライアントへの該当するコンテンツの抜粋を送達する本発明のトランスセラプションの処理フローを詳述するフローチャートである。 図１１は、個々のデータ処理モジュールを詳述する無線デバイスまたはクライアント上に常駐する本発明を示すブロックダイアグラムである。 図１２は、ユニバーサルコンテンツストリーム（ＵＣＳ）の形式におけるトランスセラプトされたデータを受信する無線デバイス上に常駐する本発明の処理フローを詳述するフローチャートである。 図１３は、ロードされた構造化ドキュメントまたは非構造化ドキュメント、あるいは、データストリームを有する本発明の処理エンジンのアーキテクチャを示す図である。 図１４は、ロードされたドキュメントに対する構成されたドキュメントオブジェクトモデル（ＤＯＭ）の本発明における親および子のオブジェクトの関係を示す図である。 図１５は、本発明が用いられ得るサンプルの非構造化ドキュメント図である。 図１６は、本発明が用いられ得るサンプルの構造化ドキュメントの図である。 図１７は、ロードされた構造化ドキュメントに対して本発明によって利用される構成されたドキュメントオブジェクトモデル（ＤＯＭ）の図である。 図１８は、テキストコンテンツ用の本発明のドキュメントオブジェクトモデルを示す図である。 図１９Ａは、テキストコンテンツのパラグラフを構成する際の本発明のドキュメントを示す図である。 図１９Ｂは、図１９Ａにおけるパラグラフコマンドを示す構成である。 図２０は、スプレッドシート（ｓｐｒｅａｄｓｅｅｔ）ドキュメントタイプで通常見られるテーブルデータを含むロードされたドキュメント用のドキュメントオブジェクトモデルを示す図である。 図２１Ａは、それぞれ構造化および非構造化ドキュメント用のユニバーサルコンテンツストリームデータ構造の形式での本発明から無線／有線デバイスへのトランスセラプト応答のコマンドコンテンツを詳述する表である。 図２１Ａは、それぞれ構造化および非構造化ドキュメント用のユニバーサルコンテンツストリームデータ構造の形式での本発明から無線／有線デバイスへのトランスセラプト応答のコマンドコンテンツを詳述する表である。 図２１Ａは、それぞれ構造化および非構造化ドキュメント用のユニバーサルコンテンツストリームデータ構造の形式での本発明から無線／有線デバイスへのトランスセラプト応答のコマンドコンテンツを詳述する表である。 図２１Ａは、それぞれ構造化および非構造化ドキュメント用のユニバーサルコンテンツストリームデータ構造の形式での本発明から無線／有線デバイスへのトランスセラプト応答のコマンドコンテンツを詳述する表である。 図２１Ａは、それぞれ構造化および非構造化ドキュメント用のユニバーサルコンテンツストリームデータ構造の形式での本発明から無線／有線デバイスへのトランスセラプト応答のコマンドコンテンツを詳述する表である。 図２１Ａは、それぞれ構造化および非構造化ドキュメント用のユニバーサルコンテンツストリームデータ構造の形式での本発明から無線／有線デバイスへのトランスセラプト応答のコマンドコンテンツを詳述する表である。 図２２は、本発明の通信フォーマット用のレイアウトの一実施形態である。

（発明の詳細な説明）
本発明が利用され得る１つ以上の無線デバイスまたはクライアント１２と通信するデータ処理システムまたはサーバ１０が図１に示される。データ処理システム１０は、通常、中央処理ユニット、内部マス格納装置およびランダムアクセスメモリ等の従来のコンポーネントを含む。これらは、本発明で利用される。データ処理システム１０への連絡、および、データ処理システム１０からの連絡は、通常、従来の態様では、ファイアフォール／プロキシサーバ１２として周知の安全なソフトウェアまたはハードウェア処理システム／ユニットを介して往来し、本発明が開発されるネットワークへの認証され、かつ、有効なアクセスを保証する。データ処理システムまたはサーバ１０で実行する本発明は、通常、インターネット１６を介して上りデータを受信し、無線デバイスまたはクライアントに常駐する本発明の一部へと下りデータを伝送する。本発明の現在の実施形態は、データ処理システム１０として、ＤＥＬＬ、ＣＯＭＰＡＱ、ＳＵＮまたは他のＷｉｎｄｏｗｓ（Ｒ）オぺレーティングシステム リリース ＮＴ ４／２０００／ＸＰ以上、または、Ｓｕｎ Ｓｏｌａｒｉｓ オぺレーティングシステム リリース ８以上で動作するサーバハードウェアの他の認識されている製造業者を利用し得る。

図２は、データ処理システムまたはサーバ１０、および、無線デバイスまたはクライアント１２をより詳細な概略を示す。サーバ１０は、中央処理ユニット（ＣＰＵ）２０、ランダムアクセスメモリ（ＲＡＭ）２２および内部マス格納デバイス２４を含み、全ては、バス２６で周知のデータチャネルによって相互接続されている。データ処理システム１０は、インターネット１６を介して無線デバイスクライアント１２と通信する。無線デバイスクライアント１２処理システムは、小さなフットプリントデバイス（例えば、Ｍｏｔｏｒｏｌａ Ｄｒａｇｏｎ Ｂａｌｌ ＣＰＵまたはＩｎｔｅｌ ＳｔｒｏｎｇＡＲＭ ＣＰＵ）として設計された中央処理ユニット（ＣＰＵ）２８を含む。この中央処理ユニット（ＣＰＵ）２８は、小さなフットプリント無線デバイスオぺレーティングシステム（例えば、Ｐａｌｍ ＯＳまたはＰｏｃｋｅｔＰＣ ＯＳ）を格納する読み出し専用メモリ（ＲＡＭ）３０と、内部フラッシュラムメモリ格納装置３２と接続され、無線ラジオ／モデム３４を利用してインターネット１６と通信する。これら全ては、データバス３６を用いて共に接続されている。

データ処理システム１０は、好ましくは、Ｃ＋＋およびＪＡＶＡ（Ｒ）等の典型的なプログラミング言語を利用するオぺレーティングシステムによって提供された機能を用いて実行するように書かれたデータ命令を利用可能なオぺレーティングシステムを伴うことによって本発明の本実施形態の機能を実行かつ行うように構成される。

図３は、本発明に関して、本発明のサーバ側処理モジュールに対する処理フローのブロックダイアグラムを示す。定義によるモジュールは、オプションまたは必須の個々のデータ処理である。これらは、他のモジュールと結合され、本発明のデータ処理システム１０を形成する。構造化または非構造化電子ドキュメント、あるいは、データストリーム４０は、無線または有線クライアント側１２から提出され、バイナリデータとしてネットワークからサーバ１０に入る。クライアント提出ハンドラ４２は、クライアントリクエストを受信し、これが有効なリクエストであることを検証し、サーバ通信バス４４を介してクライアントリクエストに基づいて適切なルーティングコマンドによって受信されたデータを通過させる。クライアント提出ハンドラ４２は、ルーティングコマンドを読み出し、ルーティングコマンドによって示された必要な順序で、必要な処理モジュールに受信されたデータを送信する。第１のルーティングコマンドが前処理モジュール（ＰＰＭ）４６に対するリクエストである場合、受信データは、ドキュメントまたはデータ最適化のために通過される。ドキュメントタイプがイメージを描くテキストの内容を含み、絵を表すバイナリイメージ、または、線または円の描画要素を用いて図を描く走査要素を含む走査された要素である場合、前処理モジュール４６の主な目的は、本発明による利用のためのドキュメントの質を改善することである。

イメージを描くテキストのコンテンツを含むスキャンされたドキュメントに対して、視覚的文字認識（ＯＣＲ）として公知の技術は、本発明によって処理用にテキストの文字を抽出する目的に用いられる。任意のＯＣＲスタイルソフトウェアパッケージ（例えば、ＳｃａｎＳｏｆｔ ＣｏｒｐｏｒａｔｉｏｎによるＯｍｎｉＰａｇｅ）がこの目的に対して本発明に適用され得る。絵を示すイメージに対して、本発明は、イメージの質（例えば、シャープにする、ぼかす、ガウスぼかし、モーションぼかし、輝度、明暗、ガンマ修正、変換、色相および彩度、ヒストグラム平均化、エンボス加工、モザイク、メジアン、アベレージ）を改善するための周知のイメージアルゴリズムを適用してもよい。線または円描画要素を用いて絵を描くスキャンされたドキュメントに対して、ラスター トゥー ベクトル（Ｒ２Ｖ）ソフトウェアは、描画要素を抽出し、かつ、スキャンされた図からの情報を位置付ける目的のために用いられ、本発明の無線／有線クライアントにあるベクトル描画データとして提出されたイメージを再構築する。任意のＲ２Ｖスタイルのソフトウェアパッケージ（例えば、ＳｏｆｔＴｅｌｅｃからのＶＰ ＨｙｂｒｉｄＣＡＤ）がこの目的のために本発明によって利用され得る。

サーバ通信バス４４は、次いで、アナトマイゼーション（Ａｎａｔｏｍｉｚａｔｉｏｎ）モジュール（ＡＭ）４８上にデータ４０をルーティングする。このアナトマイゼーションモジュール（ＡＭ）４８は、ドキュメントのアナトミー（ａｎａｔｏｍｙ）を構築する責任を負い、図１７に記載されたドキュメントオブジェクトモデル（ＤＯＭ）を形成し（ｐｏｐｕｌａｔｅ）、従属するプロセスがＳＣＢ４４を用いて、ドキュメント処理モジュール（ＣＰＭ）５０にデータをルーティングする。このドキュメント処理モジュール（ＣＰＭ）５０では、図１３に記載されたエンジンは、ディスティラー（ｄｉｓｔｉｌｌｅｒ）モジュールを用いて構造化または非構造化ドキュメントをロードする。ＳＣＢ４４のルーティングコマンドがＤＰＭ５０によってパース（ｐａｒｓｅ）されるドキュメントデータを維持する（保存する）コマンドを含む場合、ドキュメントデータは、ドキュメントデータベース（ＤＤＢ）５２に保存される。ドキュメントデータベース５２は、データベース（例えば、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎからのＭｉｃｒｏｓｏｆｔ ＳＱＬサーバ）を共通して参照する通常のソフトウェアパッケージに対するコレクタである。ＤＰＭ５０によってドキュメントの処理が首尾良く完了すると、ＳＣＢ４４は、アナトミゼーションモジュール４８に逆にコマンドを発して、ドキュメントオブジェクトモデルは、ドキュメントのコンテンツおよびアナトミーによって更新される。インデックス付けリクエストがＳＣＢ４４のコマンドスタックの一部である場合、インデックス付けモジュール（ＩＳＭ）５４が呼び出され、ドキュメントのアナトミゼーションモジュール４８から利用可能なテキストコンテンツは、周知のソフトウェア製品（例えば、ＭｉｃｒｏｓｏｆｔからのＩｎｄｅｘｉｎｇ Ｓｅｒｖｅｒ）を用いてインデックス付けされる。ドキュメントオブジェクトモジュールに関連する参照による結果は、インデックス付けサーバデータベース５６に格納される。

ＩＳＭ５４によって完了すると、ＳＣＢ４４コマンドスタックは、トランスセラプト（Ｔｒａｎｓｃｅｒｐｔ）モジュール（ＴＭ）５８（Ｔｒａｎｓｃｅｒｐｔ＝ｔｒａｎｓｍｉｔ（伝送する） ｅｘｃｅｒｐｔ（抜粋する））を呼び出し、コンテンツの最初の抜粋は、アナトミゼーションモジュール４８を呼び出して、ドキュメントオブジェクトモジュールで利用可能なコンテンツに基づいてドキュメントのコンテンツまたは要旨の最初のテーブルを要求することによって伝送のために準備される。ＡＭ４８によるトランスセラプトをリターンすると、最初のトランスセラプトのコピーは、繰り返してアクセスする目的のためにトランスセラプトキャッシュ（ＴＣ）６０に置かれる。ＳＣＢ４４が予測キャッシングモジュール６２のリクエストを含む場合、ＡＭ４８は、ドキュメントからの関連するコンテンツデータのための将来のクライアントリクエストを予測するためにクライアントセッション期間繰り返して呼び出される。予測キャッシングモジュール６２は、次いで、クライアントセッション期間に、トランスセラプトモジュール５８からのトランスセラプト結果によってトランスセラプトキャッシュ６０を形成する（ｐｏｐｕｌａｔｅ）。初期のトランスセラプトは、次いで、ＴＭ５８から完了すると、ＳＣＢ４４を介してトランスセラプトハンドラ−６４にリターンされる。トランスセラプトハンドラ−６４では、リターンデータ用の正しいクライアントデバイス１２が識別され、トランスセラプトは、ネットワーク１６に送られ、無線／有線クライアント１２に戻される。

クライアント提出ハンドラー４２が以前に提出されたドキュメントからより多くのコンテンツのためのクライアントリクエストを受信する場合、クライアント提出ハンドラー４２は、サーバ通信バス４４を介するリクエストを通過させる。サーバ通信バス４４は、順に、そのリクエストをトランスセラプトモジュール５８に渡す。トランスセラプトモジュール５８は、次いで、トランスセラプトキャッシュ６０を調査して、予測キャッシングモジュール６２によって生成されたトランスセラプトが伝達のために利用可能であるかどうかを観察する。利用可能ではない場合、アナトミゼーションモジュール４８が呼び出され、新規のトランスセラプトは、システム１０のためのドキュメント提出用に記述された手順を追跡するように準備される。完了すると、トランスセラプトは、トランスセラプトキャッシュ６０に置かれ、トランスセラプト６４は、再び呼び出され、初期のドキュメント提出として記載されたように、クライアント無線／有線デバイス１２にトランスセラプトを送達する。

図４は、本発明によって刊行するために提出されたドキュメントまたはコンテンツリクエスト７０のパッケージングを示す。ＣＭＬベースのメタデータ記述７２は、パッケージングのカプセルであり、適切なサーバコマンド（例えば、（ｐｕｂｌｉｓｈ）刊行する（ｑｕｅｒｙ）またはクエリする）、情報（例えば、デバイスタイプ、デバイススクリーンサイズ、自由格納スペース、推定された帯域幅転送速度等）を提供する要求デバイス１２の無線デバイスの性質、および、ドキュメント７０の情報（例えば、ドキュメント名、ドキュメントの日付、ドキュメントタイプまたは任意の他の捕捉情報）を含む。元のドキュメントまたはコンテンツリクエスト７０の固有のドキュメントＩＤ７４は、ドキュメント提出リクエストの他の一部を作る。固有のドキュメントＩＤがリクエストの一部として送られる場合、その固有のドキュメントＩＤは、ドキュメントが既に発行され、サーバがトランスセラプトキャッシュ６０を参照して、固有のドキュメントＩＤに基づくドキュメントデータベース５２からのドキュメント取り出していることを示す。

図５は、データ処理システムサーバ１０への無線クライアント１２提出要求のためのフローチャートプロセス８０を示す。データを有する入来要求８２が到着する。プロセス８０の第１のステップは、入来要求８２が新規の刊行要求８４であるかどうかを構築することである。入来要求が固有のドキュメントＩＤ７４を有する場合、入来要求は、新規の刊行要求ではなく（いいえ）、ドキュメントは、既にサーバデータ処理システム１０に常駐しており、従って、トランスセラプト処理ステップ９６が直接行われる。元のドキュメントが提出される場合、メタデータ７２は、前処理８６を実行するクライアント要求が存在するかどうかを参照するように処理され、前処理モジュール４６は、ステップ８８で呼び出される。そうではない場合、アナトミゼーション処理９０が実行される。アナトミゼーション処理モジュール４８からの処理が完了すると、メタデータ７２は、アナトマイズされたコンテンツに対してインデックス付け９２を実行するクライアント要求が存在するかどうかを参照するように処理されう。これがトゥルー（ｔｒｕｅ）である場合、インデックス処理モジュール５４が呼び出され、コンテンツは、ステップ９４でインデックス付けされる。ステップ９２および／またはステップ９４が完了すると、トランスセラプトモジュール５８は、初期のコンテンツの結果を要求している無線クライアント１２に戻して送達する目的のためにステップ９６で呼び出される。

図６は、サーバ通信バス４４（ＳＣＢ）のサーバ側のデータ処理システム１０のデータフローを示すフローチャート１００である。入来要求および／またはデータは、ＳＣＢによる受信され１０２、ＳＣＢは、入来要求がＳＣＢ４４にとって有効な要求１０４であるかどうかを決定するように見る。要求が有効である場合（はい）、コマンドおよび関連データは、ＳＣＢによって取り出される１０６。関連データは、元のドキュメントまたは元のドキュメントに固有のＩＤである。ＳＣＢコマンドが未解決（ｐｅｎｄｉｎｇ）であるので、データは、適切な処理モジュールにルーティングされる１０８。このモジュールにおいて、ＳＣＢコマンドの任意の１つまたは組み合わせは、システムモジュール（ドキュメント処理モジュール５０、アナトミゼーションモジュール４８、前処理モジュール４６、インデックス付けモジュール、トランスセラプトモジュール５８）のうちの任意を含むサーバ側のデータ処理システム１０によって実行される。それぞれのデータ処理システムモジュール４６、４８、５０、５４、５８によって処理するデータに対してＳＣＢ４４が同期リクエスト要求と非同期リクエスト要求との両方を処理するように設計されるので、ＳＣＢ４４がステップ１１０で処理されるさらなるコマンドおよびデータが存在するかどうかをチェックする場合、要求は、完了してもよいし、しなくてもよい。より多くのコマンドまたはデータが存在する場合（はい）、コマンドスタックが空になるまで、処理は、ステップ１０６で開始し続ける。それ以上のデータまたはコマンドがステップ１１０で止まっていない場合、ＳＣＢ４４は、ステップ１１２のサーバ側データ処理モジュールから要求している無線／有線クライアント１２への適切な応答および結果のデータをリターンする。有効なコマンドがステップ１０４でＳＣＢによって検出されない場合（いいえ）、適切な失敗コードがステップ１１２で割り当てられ、結果のリターンまたは応答は、要求している無線または有線クライアント１２に送られる。

図７は、前処理モジュール７６のためのサーバ側のデータ処理システムを説明するフローチャートを示す。上りデータ１２２がＳＣＢ４４で受信される。有効ステップ１２４は、上りデータ１２２は、有効な前処理コマンドかどうかを参照するように実行される。コマンドが有効な前処理コマンドとして認識されない場合（いいえ）、結果のエラーコードは、ステップ１２６でＥ＿ＦＡＩＬに設定され、エラーコードは、ステップ１２８でＳＣＢの下りデータとしてリターンされる。コマンドが有効な処理コマンド（はい）であることをステップ１２４が決定する場合、ステップ１３０は、前処理コマンドによって提出されたドキュメントタイプが有効なサポートされたドキュメントであるかどうかを参照することをチェックする。答えが否定である場合（いいえ）、ステップ１２６は、再び結果のエラーコードをＥ＿ＦＡＩＬに設定して、エラーコードは、ステップ１２８でＳＣＢで下りデータとしてリターンされる。これがステップ１３０で有効なドキュメントタイプである（はい）と決定される場合、処理モジュール４６は、ステップ１３２で呼び出される。うまくいったステップ１３０の一部として決定されたドキュメントタイプに基づいて、適切な前処理サブモジュール１３４、１３６または１３８が呼び出される。ステップ１３４は、（通常ＯＣＲと呼ばれる）光学的文字認識を実行して、走査されたドキュメントをテキストのコンテクストに変換する。本発明は、Ｓｃａｎｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎによるＯｍｎｉＰａｇｅ等のソフトウェアベンダーからＯＣＲ用に販売されているソフトウェアを用いるように設計されている。

ステップ１３６は、ステップ１３０で決定された有効なドキュメントタイプが保存された形式（例えば、ＢＭＰ（ビットマップ）またはＪＰＥＧ（Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（共同写真専門化グループ）））でイメージまたは写真データである場合に、ステップ１３２によって呼び出される。これらの形式では、周知の数学の公式が用いられ得、画像写真データの視覚的な局面（例えば、シャープにする、ぼかす、ガウスぼかし、モーションぼかし、輝度、明暗、ガンマ修正、変換、色相および彩度、ヒストグラム平均化、エンボス加工、モザイク、メジアン、アベレージ）を改善し得る。ステップ１３８は、ステップ１３２で決定された有効なドキュメントタイプがスキャンされた絵であり、ラインまたは円の描画要素を用いて絵画を描く場合に、ステップ１３２によって呼び出される。ステップ１３８は、次いで、絵の要素を抽出して、走査された絵画からの情報を位置付けるために、販売されているラスターツーベクトル（Ｒ２Ｖ）ソフトウェアを用いて、無線／有線クライアント１２のベクトル描画データとして提出された画像を再構成または再生成する。ＳｏｆｔＴｅｌｅｃによるＶＰ ＨｙｂｒｉｄＣＡＤ等の任意のＲ２Ｖスタイルソフトウェアパッケージは、この目的のために本発明によって利用され得る。ステップ１３２によって任意のサブプロセス１３４、１３６、１３８が完了すると、ステップ１４０は、プロセスが成功したと決定されるかどうかをチェックする。ステップ１４０が成功である場合（はい）、前処理されたデータは、ステップ１２８でＳＣＢに逆にリターンされる。ステップ１３２からの結果が成功ではないとステップ１４０が決定する場合（いいえ）、結果のエラーコードがステップ１２６においてＥ＿ＦＡＩＬに設定され、エラーコードは、ステップ１２８においてＳＣＢに対する下りデータとしてリターンされる。

図８は、アナトミゼーション処理４８のためのサーバ側データ処理システム１０の処理フローを示すフローチャート１５０である。ＳＣＢからの上りデータは、ステップ１５２において受信され、ステップ１５４へと渡される。ステップ１５４において、ドキュメントデータが有効であるかどうかが決定される。ドキュメントデータが有効ではない場合（いいえ）、ステップ１５６は、Ｅ＿ＦＡＩＬに結果のエラーコードを設定し、ＤＯＭへのポインタは、ゼロまたはＮＩＬに等しく設定され、ステップ１５８においてエラーコードをＳＣＢの下りデータとしてリターンする。ドキュメントデータがステップ１５４において有効である（はい）と決定された場合、受信されたドキュメントデータは、ステップ１６０においてパーシングされ、次いで、ドキュメントオブジェクトモデル（ＤＯＭ）は、ステップ１６２において構築される。ＤＯＭがステップ１６２によって構成された後、ステップ１６４は、構築されたＤＯＭを維持または格納するためのコマンド要求が存在するかどうかをチェックする。ステップ１６４がトゥルーである（はい）場合、ＤＯＭデータは、ステップ１６８まで継続している前にステップ１６６においてドキュメントデータベース５２に格納される。ステップ１６４がフォルス（ｆａｌｓｅ）である（いいえ）場合、ステップ１６８は、デコレータを適用するコマンドが存在するかどうかを参照することをチェックする。デコレータは、ステップ１６２によって構築されたドキュメントオブジェクトモデルを横断して、コンテンツまたはナビゲーション情報（例えば、コンテンツテーブル（ＴＯＣ）、ブックマーク、ハイパーリンク、ファインドテキスト（Ｆｉｎｄ Ｔｅｘｔ）等）を抽出するコマンドである。ステップ１６８が適用するデコレータコマンドを全く有さない（いいえ）場合、ステップ１７０は、結果のコードをＳ＿ＯＫに設定し、ステップ１５８において下りデータをリターンする前にＤＯＭポインタを設定する。デコレータが適用される（はい）ことをステップ１６８が決定する場合、ステップ１７２が呼び出され、デコレータは、ステップ１６２で構築されたＤＯＭを横断する。ステップ１７２が完了すると、結果のコードは、Ｓ＿ＯＫに設定され、ＤＯＭポインタは、ステップ１５８で下りデータをリターンする前にステップ１７２において設定される。

図９は、サーバ側のデータ処理システム１０のためのインデックス付け処理５４のフローチャート１８０を示す。ＳＣＢ４４からの上りデータがステップ１８２に到着する。ステップ１８４は、データにインデックス付けするリクエストがあるかどうかをチェックする。ステップ１８４が偽（いいえ）と判定されると、ステップ１８６は、結果コードをＥ＿ＦＡＩＬに設定して、その結果は、ステップ１８８でＳＣＢに下りデータとしてリターンされる。ステップ１８４が真（はい）であると、システムは、ステップ１９０でドキュメントオブジェクトモデル（ＤＯＭ）をトラバース開始する。ステップ１９２で、単一のＤＯＭエレメントのコンテンツが取り出され、システム１０は、ステップ１９４でインデックスを構築開始する。ステップ１９４で、システムは、Ｍｉｃｒｏｓｏｆｔインデックス付けサーバ等の購入可能なソフトウェアインデックス付けパッケージを通常用いる。取り出されたＤＯＭエレメントのコンテンツがステップ１９４でインデックス付けされた後、ステップ１９６は、ＤＯＭトラバーサルが完了するかどうかを観察するようにチェックする。答えがいいえであると、ステップ１９２および１９４は、ＤＯＭトラバーサルがステップ１９６で完了する（はい）であるまで再び処理される。インデックスは、次いでステップ１９８でインデックスデータベース５６に格納され、結果のコードは、その結果がステップ１８８でＳＣＢへの下りデータとしてリターンされるまで、ステップ２００でＳ＿ＯＫに設定される。インデックスＤＢ５６は、ステップ１９８で利用され、ＭＳ ＳＱＬサーバまたはＯｒａｃｌｅ等の任意の販売用データベース商品であり得る。

図１０は、サーバ側のデータ処理システム１０用のトランスセラプションモジュール５８のプロセスフローチャート２１０である。上りデータは、ＳＣＢからステップ２１２に到着して、チェックされ、この上りデータがトランスセラプトリクエストかどうかをステップ２１４で調べられる。それがトランスセラプトリクエストではない場合（いいえ）、ステップ２１６は、結果のコードをＥ＿ＦＡＩＬに設定して、下りデータとしてその結果をステップ２１８のＳＣＢに戻す。データがトランスセラプトリクエストである（はい）と、ステップ２１４が判定する場合、ドキュメントオブジェクトモデルのＩＤを得るためにステップ２２０が呼び出される。ＤＯＭ ＩＤは、トランスセラプトキャッシュ６０か、ドキュメントデータベース５２のいずれかから正しいドキュメントを識別するために用いられる。ステップ２２２は、データがキャッシュ６０で利用可能かどうかを調べるためにチェックする。答えがはいである場合、ステップ２２４は、トランスセラプトキャッシュ６０からデータを得て、ステップ２２６は、その結果をＳ＿ＯＫに設定して、ステップ２１８で下りデータをＳＣＢにリターンする。キャッシュにデータが無い場合（いいえ）、ステップ２２２は、メモリでロードされたＤＯＭがあるか、および、メモリでロードされたＤＯＭがＤＯＭ ＩＤにマッチしているかどうかを調べる。

システム１０がキャッシングを用いているので、システム１０は、特定数のドキュメント（例えば、最後に処理された３２個のドキュメント）のためのＤＯＭおよびＤＯＭ ＩＤを保持し、ＤＯＭ ＩＤがキャッシュにあるＤＯＭコンテンツのいくつかとマッチする場合、ＤＯＭが既にキャッシュに無いのなら、ＤＯＭ ＩＤがメモリに戻され、それは、処理された最後のドキュメントであったことを意味する。ステップ２２８におけるテストは、メモリにＤＯＭが存在しない、または、ＤＯＭ ＩＤがマッチしない（いいえ）（ＤＯＭがキャッシュにないことを意味する）ことを判定する場合、ステップ２３０が呼び出され、ステップ２３２に進む前にドキュメントデータベース５２からＤＯＭを取り出す。システム１０は、ＤＯＭがデータベースに保存されるか、ＤＯＭを最初に生成するために用いられる元のドキュメントを再処理せずすぐに取り出すためにファイリング可能にする。メモリにＤＯＭがあり、ドキュメントＩＤがマッチする（はい）ことをステップ２２８が判定する場合、ステップ２３２は、トランスセラプトを得るために呼び出される。ステップ２３４は、上りデータとしてステップ２１２でＳＣＢから受信したＳＤＢコマンドが予想したキャッシングフラッグセットを有するかどうかを検証するために観察する。フラッグが設定される場合（はい）、ステップ２３６は、ステップ２３８に進む前に非同期の予想キャッシングプロセス６２を開始する。フラッグが設定されないことをステップ２３４が判定する場合（いいえ）、ステップ２３８が呼び出され、ステップ２３２で呼び出されたトランスセラプトデータは、キャッシュ６０に託される。ステップ２４０は、次いで、コミットが完了したかどうかを調べるために繰り返してテストし、テスト結果が否となる場合にステップ２３８に戻る。ステップ２４０がコミット完了のために真をリターンする場合、ステップ２２４が呼び出され、トランスセラプトデータは、キャッシュから取り出される。ステップ２２６は、結果をＳ＿ＯＫに設定して、ステップ２１８で下りデータをＳＣＢにリターンする。

図１１は、無線デバイスまたはパーソナルデジタルアシスタント（ＰＤＡ）に常駐する本発明の無線クライアント処理システムの詳細図２５０である。リーダ２５２は、関数を無線ＰＤＡ／デバイスオぺレーティングシステム２７０に呼び出す複数の別々のソフトウェア関数エレメントおよびライブラリ２５４〜２６６を含むソフトウェアアプリケーションである。オぺレーティングシステム２７０は、オぺレーティングシステム２７０を形成する複数の別々のソフトウェア関数を含む。無線ＰＤＡ／デバイス用の周知のオぺレーティングシステム（ＯＳ）は、Ｐａｌｍ ＣｏｒｐｏｒａｔｉｏｎのＰａｌｍ ＯＳ、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎのＷｉｎｄｏｗｓ（Ｒ） ＣＥ、Ｓｕｎ ＣｏｒｐｏｒａｔｉｏｎのＪ２ＭＥ、ＳｙｍｂｉａｎのＥＰＯＣおよびＱｕａｌｃｏｍｍのＢＲＥＷである。本発明のクライアント側のソフトウェア関数は、通常ＵＣＳと呼ばれる、定義されたユニバーサルコンテンツストリームを読み出すように設定されている。リーダ２５２は、テキスト、ベクトルおよびイメージベースのデータをデバイス１２にレンダリングするように用いられるグラフィック命令のセットを提供するグラフィック関数ライブラリ２６６を有する。これを達成するために、ライブラリ２６６は、デバイスＯＳ２７０からの利用可能なグラフィックオペレーションを用いる。コア関数ライブラリ２６４は、メモリアクセスおよびハンドリング２７２、ファイル入力／出力および／またはデータベースアクセス２７４、およびインターネット１６からデータを取り出すための無線データアクセス２７６用にデバイスＯＳ２７０から導かれた関数のセットを提供する。次いで、リーダ２５２は、ビューモード２５４、２５６、２５８および２６０で定義されたグラフィックユーザインタフェースＧＵＩを提供可能なコア関数ライブラリ２６４およびグラフィック関数ライブラリ２６６を呼び出すアプリケーションコマンドレイヤー２６２を有する。

ＵＣＳからロードされたデータに基づいて、イメージビュー２５４は、イメージまたは画像に基づくデータを表示し、シートビュー２５６は、スプレッドシートスタイルグリッドのスプレッドシートデータを表示し、ドキュメントビュー２５８は、リッチ（ｒｉｃｈ）かつ直感にテキストのコンテンツを表示し、ファイルビュー２６０は、デバイス１２にＵＣＳファイルをロードかつ保存するためにユーザインタフェースを表示する。リーダ２５２において層状に設計されているので、コア関数ライブラリ２６４およびグラフィック関数ライブラリ２６６のみが、クライアント側の処理システムが置かれる無線／ｐｄａデバイス１２の各々において異なる。これにより、本発明がＰａｌｍ ＯＳ、Ｗｉｎｄｏｗｓ（Ｒ） ＣＥ、Ｊ２ＭＥ、ＥＰＯＣおよびＢＲＥＷ等（ここで、２大プログラミング言語は、プログラミングの分野における当業者において周知のＪａｖａ（Ｒ）およびＣ＋＋である）の異なるオぺレーティングシステムに素早く移動またはポートされることが可能となる。ＵＳＣバイナリファイルは、インターネット１６を介してサーバ側のデータ処理システム１０からデバイス１２に送達され、無線クライアントリーダ２５２は、コア関数ライブラリ２６４において無線データアクセス（ロード）２７６用の関数を用いることによってこのデータを取り出す。コア関数ライブラリ２６４では、順に、無線デバイスＰＤＡ／デバイスＯＳ２７０のリモートＨＴＴＰ／ＴＣＰ／ＩＰアクセス２７６用にライブラリを呼び出す。

図１２は、無線ＰＤＡ／デバイス１２に常駐するクライアント側の処理アプリケーションの詳細なフローチャート２８０である。ステップ２８２において、インボックス（Ｉｎｂｏｘ）アプリケーション等のデバイス１２上の別のアプリケーションにより起動されるか、ユーザがリーダ用のアプリケーションアイコンを選択して、そのアプリケーションを呼び出すかのいずれかによって、リーダ２５２が呼び出される。ステップ２８４において、渡されたユニバーサルコンテンツストリーム（ＵＣＳ）は、必要があれば、ローカルまたはリモートであることを検証される。ローカルである場合、ＵＣＳは、既にデバイス１２に格納されており、ステップ２８６は、ファイルまたはデータベース２８８からローカルＵＣＳストリームを読み出す。ＵＣＳがステップ２８７でリモートである（デバイス１２に常駐していない）と判定される場合、ステップ２９０は、リモートＵＣＳストリームを読み出すために呼び出される。次いで、ステップ２９２は、インターネット１６を用いてサーバ側のデータ処理システム１０に常駐するリモートＵＣＳを得る。ステップ２８６か２９０かのいずれかが完了すると、取り出されたデータがパース（ｐａｒｓｅ）されるステップ２９４まで実行が続く。次いで、ステップ２９６は、データをデバイスメモリにロードして、ステップ２９８は、リモートまたはローカルＵＣＳデータのパーシングが完了するかどうかを調べるためにテストする。ステップ２９８がローカルデータ用に完了しない場合（いいえ）、ステップ２９４は、ステップ２９８がローカルＵＣＳファイル用に真である（はい）まで、繰り返して呼び出される。リモートＵＣＳパーシング用のステップ２９８が、完了しない場合（いいえ）、クライアントへの任意のさらなるトランスセラプト用にサーバ１０に以前として常駐していると記述された任意のＵＣＳデータのために、ステップ３００は、リモートリンクリストを生成する。次いで、ステップ３０２は、リモートリンクによってＵＣＳメモリを更新して、リモートパーシングステップ２９８が完了する（はい）までステップ２９４へと続く。

ＵＣＳデータがパースされ、メモリにロードされた後、ステップ３０４は、ＵＣＳデータのビュータイプまたはビュータイプの組み合わせを決定する。呼び出されたイメージビュー２５４、ドキュメントビュー２５８またはシートビューモード２５６のいずれかのビュータイプに応じて、ＵＣＳデータは、ステップ３０６で表示される、または、レンダリングされる。ステップ３０６でＵＣＳデータを表示した後、クライアントデータ処理アプリケーションは、ステップ３０８でユーザの入力を待機する。ユーザがメニューオプション、またはトラック／スクロールホイール、スタイラス（ｓｔｙｌｕｓ）またはキーパッドを用いてロードされたドキュメント内でナビゲートする場合、ステップ３０８は、ユーザが脱出オプションを選択することによってリーダ２５２を終了させるまで、繰り返して呼び出され、ステップ３１０は、モバイルリーダを脱出して、ステップ２８２の前の呼び出しアプリケーションにリターンする。ユーザがさらなるＵＣＳデータのためにステップ３０８でより多くのリクエストを選択するまたは呼び出す場合、ステップ２９０は、ユーザがステップ３０８でアプリケーションを終了させるまで、上述されたような同じ以下のプロセスフローで再び呼び出され、ステップ３１０は、モバイルリーダを脱出して、そのステップの前に呼び出しアプリケーションにリターンする。

図１３は、ドキュメント処理モジュール５０のためにロードされた仮定のドキュメントと共にドキュメントエンジン構造を示す図３２０である。ドキュメントエンジンの構成は、以下のモジュール（エンジンモジュール３２２、ディスティラーモジュール３２４とロードされたドキュメント３２６とデコレータモジュール（図示せず）とのセット）としてカテゴリー化された各コンポーネントの集合である。ディスティラーモジュール３２４の機能は、主に、異なるドキュメントタイプを取り扱うことである。このモジュールのセットは、特に公知のドキュメントフォーマットをパースし、ドキュメント構造を構築し、所望の場合、ドキュメント構造を公知のドキュメントフォーマットに戻すことに固執する役目を有する。新規のディスティラーモジュール３２４が動作時間に追加され、または、取り除かれて、柔軟な環境のために必要なものを収容するという意味で、ディスティラーモジュール３２４のセットは開かれている。エンジンモジュール３２２の機能は、主に、動作しているディスティラーモジュール３２４、所望の場合、ロードされたドキュメント３２６をホストして、これらのために均一の環境を提供することである。クライアントのために共通の挙動を提供する（例えば、ドキュメントをローディングすること）ことも用いられる。複数のドキュメント構造モジュールは、ロードされたドキュメントの構築しているピースである。これらのピースは、（ロードされたドキュメントを示し、他の全てのノードを含む）ドキュメントノード３２８、（ある程度の詳細なドキュメントを有するコンテンツを示す）コンテンツノード３３０、（他のノード用のコンテナを示す）コンテナノードの対３３２、３３４、（テキストコンテンツを示す）テキストコンポーネント３３６、（イメージコンテンツを示す）イメージコンポーネント３３８、（ベクトルコンテンツを示す）ベクトルコンポーネント３４０、および、（スプレッドシート等のテーブルデータを示す）テーブルコンポーネント３４２を含む。ドキュメント構造３２６は、ツリー状の構造（ノードを共有する可能性を有するので、より適切な記述は、グラフ状である）である。この事実によって、固執したドキュメント構造によって制約されることなく所望の任意の態様でユーザがドキュメントを実用的に構築することを可能にする。

各ノードが（子供および／親に対する）方法の様な集合をインプリメントするという事実によってこのことが達成される。レンダリングの様な挙動は、それ自体ノードに取りつけられ得るか、外部のコンポーネントとして提供され得るかである。このことは、ドキュメント構造の標準的なイタレータ（ｉｔｅｒａｔｏｒ）のセットの存在によって容易にされる。意図する動作に必要なこと（速度、大きさ、配置等）を考慮することによって、内部の挙動と外部の挙動との間で選択が成され得る。デコレータモジュールの機能（図１３に示されない）は、主に、ドキュメント構造に対して選択されてカスタマイズされたドキュメントの動作を実行することである。コンテンツ、ブックマークまたはハイパーリンクのリスト、検索動作等のテーブルを抽出することが例として含まれる。ここでは、トランスセラプション技術が用いられる。これらは、それぞれ独自のフレームワークを有する分離したモジュールであり、これらのモジュールは、他のエンジンコンポーネントと完全に独立して動作する。実際、エンジンは、インストールされているデコレータモジュール無しで動作し得る。これらは、さらなる機能を加える。デコレータモジュールフレームワークは、（それ自体でコンポーネントである）デコレータマネージャ、および、特定の動作を実行するインストールされたモジュールのセットで構成される。各モジュールは、フレームワークに統合して、デコレータマネージャによって認識されるために、予め決定された方法で登録する必要がある。デコレータは、ドキュメントオブジェクトモデル（ＤＯＭ）をナビゲートする単一の目的のためにソフトウェア開発の分野で当業者によって共通して参照されるコンポーネントであり、特定のコンテンツおよび／またはナビゲート情報を取り出す。言い換えると、デコレータコンポーネントがコマンドを構成することが記述され得る。いかに多くのデコレータがＤＯＭをナビゲートするために用いられ得るかということに対して制限はない。通常のデコレータ（コマンド）は、ドキュメントのブックマークを取り出し、ドキュメントのハイパーリンクを取りだし、ドキュメントのコンテンツテーブルを取り出し、ＴＯＣが利用可能ではない場合にドキュメントの要旨を構築し、特定のページを取り出し、ドキュメント内のテキストコンテンツを検索し、特定のフォントスタイルまたは情報を取り出し、ドキュメント内のイメージまたはイラストレーションを取り出す。

図１４は、ドキュメントエンジン３２０内の親ノード３５２および子供ノード３５４の関係３５０を示す。親３５２と子供３５４との間の実際のリンクは、２つの間のポインタよりも若干複雑である。それらの間において、リンクの属性を保持する役割を果たす、いわゆるスペシフィアー（ｓｐｅｃｉｆｉｅｒ）３５６オブジェクトが存在する。関連している親または子のオブジェクトＩＤＳに対する情報は、通常リンクの属性によるものである。このことは、グラフ状の構造であり、単一の親が多数の子供を有し得、１つの子供も多数の親オブジェクトを有し得るためである。
構造化または非構造化電子ドキュメントの形式か、絵またはイラストレーション等のグラフィックイメージ、および、ベクトル形式かＡからＢへの線を描く方法に関する記述として周知の形式で示された描画データによって通常表されたテキストおよび非テキストのコンテンツを具現化するデータストリームの形式で入力を提供することが、本発明の動作である。電子ドキュメントは、ビジネスまたは個人的な通信レター、製品情報および製品の説明書、部品のマニュアル、会社または個人の経営情報等が最良として記述されているが、これらに制限されない。図１５および１６は、それぞれ構造化ドキュメントおよび非構造化ドキュメントを表す。

図１５は、通常の非構造化ドキュメント３６０がいかに見え得るかを示す。非構造化によって、ドキュメントが最小のナビゲーション情報および構造化エレメント（例えば、ヘッダ、フッタ、テーブルおよびフォントスタイル）を有することが意図される。これらを使用することによって、発明のクライアント側のデータ処理システム２５０に戻って部分的なドキュメントコンテンツを送達し、再構築する目的のために、このようなフォーマットおよびナビゲーション情報を直接抽出することができる。サーバ側１０データ処理能力は、従って、非構造化ドキュメントデータを解析することによって、ナビゲーションおよび再構築情報等を構築するために用いられる必要がある。

フォントサイズ、フォントタイプ、フォントスタイル、および、フォントポジショニングの変化を検出することによって解析が行われる。これを解析することによって、全てのテキストコンテンツエレメント３６２は、以下の基準によってヘッダとしてマークされる。用いられる最大のフォントサイズ＝１４、フォントスタイル＝Ｂｏｌｄ、フォントタイプ＝Ａｒｉａｌ。これは、テキストパラグラフ定義３６４によって強化される。テキストパラグラフ定義３６４は、全て、フォントサイズ＝１０、フォントスタイルは無く、フォントタイプ＝Ｔｉｍｅｓである。この情報に基づいてヘッダ３６２を識別化することによって、本発明は、非構造化ドキュメントに対しては存在しないコンテンツテーブルの形式でナビゲーションのヘルプを構築可能である。組み込まれたイメージ３６６は、画像挿入ポイント座標ｘ，ｙおよび全てのピクセルにおける幅および高さ情報を有する。次いで、本発明のシステム１０は、イメージ３６６をクライアント側のアプリケーション処理システム１２にレンダリングする場合に、イメージ３６６へリンクを提供し得、マークされたエレメント３６８は、テキストパラグラフ３６４内のフォントスタイルの変化が原因となって、ヘッダとしてもマークされるが、エレメント３６８がテキストパラグラフ３６４内に位置すると、他のヘッダ３６２よりも低い重要度でランク付けされる。エレメント３６８がナビゲーションの重要さを有していると判断されるので、コンテンツテーブルの形式でナビゲーションエイド（ａｉｄｅ）を形成する場合に、エレメント３６８は、次いで、サーバ側１０のアプリケーション処理によって用いられる。同様に、タイプ３７０および３７２のエレメントは、本発明のサーバ側の処理能力によって検出される。なぜなら、これらのエレメントのフォント位置が緊密であり、加えて、フォントスタイルＢｏｌｄおよびＩｔａｌｉｃ、および、スペーシング用のタブ（ＴＡＢ）文字を使用しているからである。これら全ては、このセクションがドキュメント３６０に対して重要であり、テーブルコンテンツを構成する際にこのセクションがナビゲーションエイドポイントとしてマークされ得ることを示している。最終的に、ページエレメント３７４は、ドキュメントページ１にある全ての非構造化コンテンツに対する公知のナビゲーションインデックス参照と関連するページ番号の記述を定義する。

図１６は、テーブルコンテンツの形式のドキュメントナビゲーション構造を識別する目的で、および、クライアント側の処理アプリケーション１２でコンテンツの抜粋を再構成することを意図してコンテンツの抜粋を定義する目的でサーバ側データ処理システム１０によって処理され得る非構造化ドキュメント３８０を示す。コンテンツテーブル（ＴＯＣ）３８２は、構造化ドキュメントに存在するエレメントとして定義される。ヘッディング１およびヘッディング２として参照されるコンテンツエレメント３８４および３８６がパラグラフヘッダ３８８として定義され、ドキュメント自体によってＴＯＣエンティティ３８２の構築のときにナビゲーションエレメントとして用いられる。従って、サーバ側のデータ処理アプリケーション１０は、非構造化ドキュメントのために必要とされる処理を必要とすることなく、これらのエレメントを直接抽出することができる。さらに、システム１０は、構造化ドキュメントをパースして、ブックマーク１へのハイパーリンク３９０を識別する。ハイパーリンクは、構造化ドキュメント内のオブジェクトまたはエンティティ間のナビゲーションリンクである。この構造化ドキュメントは、それらが接続され、関連していること、および、ハイパーリンクと相互作用することによって、ユーザがドキュメントの異なる部分にナビゲートできることを示す。システム１０は、ハイパーリンクエンティティ３９０の記録を作り、その記録をナビゲーションのために用いる。ブックマークエンティティ３９２は、構造化ドキュメント３８０自体内に定義されている別のエレメントである。この構造化ドキュメント自体は、ナビゲーションアンカー（ａｎｃｈｏｒ）ポイントを提供し、システム１０は、ナビゲーションハイパーリンクエンティティ３９０の実行を可能にする目的のためにこのナビゲーションアンカーポイントを記録する。ハイパーリンクエンティティ３９２、３９４、３９６は、外部のハイパーリンクであることによってハイパーリンクエンティティ３９０とは全く異なる。外部ハイパーリンクは、他のコンテンツ、または、外部アプリケーション、または、構造化ドキュメント３８０自体に定義されるプロセスに対するリンクオブジェクトとして定義される。

１つのハイパーリンク３９２は、ウェブサイトアドレスｗｗｗ．ａｒｉｚａｎ．ｃｏｍ、または、ｗｗｗ．ａｉｒ２ｗｅｂ．ｃｏｍへの第２のハイパーリンク３９４へと示すアドレスによってインターネットブラウザを立ち上げ、一方で、リンク３９６は、ｓａｌｅｓ＠ａｒｉｚａｎ．ｃｏｍへと設定された「Ｔｏ」アドレスによってｅメールアプリケーションプログラムを立ち上げる。サーバ側のデータ処理システム１０は、構造化ドキュメントを処理する一方で、ナビゲーションまたは可能なアプリケーションを立ち上げる目的で、本発明を用いるソフトウェアアプリケーションのために構築されたドキュメントオブジェクトモデルにこれらのエレメントを記録する。構造化ドキュメント３８０のイメージエレメント３９８は、イメージ／ピクチャに対する情報、位置ｘ，ｙおよび幅、高さ情報を提供する。システム１０の発明は、ＤＯＭに記録し、従って、視覚的にかつ内容としても正しいコンテキストで無線デバイス１２にあるこのエレメントを再構成する能力をクライアントコンポーネント１２に与える。構造化ドキュメント３８０によって定義されたテーブルエレメント４００は、テーブル状の態様で表示かつ組織化されたコンテンツを含む。本発明のサーバ側のデータ処理機能は、この情報を読み出し、ドキュメントエンジンテーブルコンポーネントを利用してＤＯＭを構築する際にそれをマッピングする。このドキュメントエンジンテーブルコンポーネントによって、本発明のクライアント側の処理システムは、無線デバイス／ｐｄａ１２にテーブル状の構造でＤＯＭを再構築可能である。

構造化ドキュメントのグラフエレメント４０２は、バーチャート等のグラフタイプフォーマットの情報を含み、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎによるＭＳ Ｗｏｒｄのようなワードプロセッサ等の構造化ドキュメントを読み出すアプリケーションによってチャートを描く際に、テーブルエレメント４００に提供されたデータにリンクする。サーバ側のデータ処理能力は、無線デバイス／ｐｄａ １２においてクライアント側のデータ処理システムにグラフを再構築させることを意図して構造化ドキュメントを処理する
際に、グラフリンクおよびレンダリング情報を取り出し、記録する。ヘッダエレメント４０４は、構造化ドキュメントにある各ページに対するページヘッダ情報を定義して、一方で、フッタエレメント４０６は、構造化ドキュメント３８０の各一ページに対して再利用されるページフッタ情報を定義する。サーバ側のデータ処理能力は、エレメント４０４および４０６を記録し、適切なエンティティをＤＯＭに構築する。ページエンティティ４０８も、ナビゲーションインデックスを提供し、一方で、構造化ドキュメント３８０をナビゲートする。なぜなら、各ページエンティティは、最初のページで開始し、最後のページで終わるページ範囲内の各ページをユーザが参照可能とする連続的なエントリであるからである。図１６によって表された構造化ドキュメントも、メタデータ４１０を参照するドキュメントに関する非視覚的な記述情報を埋め込んでいる。本発明のサーバ側のデータ処理能力は、この情報を抽出可能であり、それをＤＯＭに格納可能である。このＤＯＭでは、その情報は、後に、システムに１０によって用いられ得、ドキュメント情報（構造化ドキュメントに格納されたメタデータによって定義された、ドキュメント名、著者、日付、生成時間等）を提供し得る。

図１７は、本発明のサーバ側のデータ処理システム１０によって構築されたドキュメントオブジェクトモデル４２０を示す。イラストレーション４２０は、ロードされたドキュメントの一般的な構造４２２を示す。ＤＯＭのエントリポイントは、コンテンツノード４２４である。複数のコンテナ４２６の各々は、異なるタイプの多数のコンポーネントを有し得る。本発明のサーバ側のデータ処理アプリケーションは、定義された４つのコンポーネントタイプを有する。それらは、テーブルコンポーネント４３０、テキストコンポーネント４３１、イメージコンポーネント４３２およびベクトルコンポーネント（図示せず）である。各コンポーネントも、参照コマンドの形式で、同じコンテナ４２６、または、異なるコンテナの下で他のコンポーネントによって参照され得る。

図１８は、ドキュメントオブジェクトモデル（ＤＯＭ）４２０を構築した後、および、図１６によって示された構造化ドキュメント３８０をロードした後にサーバ側のデータ処理システム１０によって用いられたテキストコンポーネント４３０を示す。各テキストコンポーネント４３０は、１つ以上のセクションコマンド４４０を有し得、任意の標準的な構造化または非構造化ドキュメントとして通常見られるために、複数のパラグラフ４４２は、１つの単一セクション４４０に含まれ得る。パラグラフオブジェクト４４２は、定義された１つの属性４４４を有する。この１つの属性４４４は、コンテンツハイパーリンクのテーブルに対する参照である。ハイパーリンクスタートオブジェクト４４６自体は、その属性オブジェクト４４８によって定義される。この属性オブジェクト４４８は、ハイパーリンクＩＤおよびリンクの送信先を記述する。それから、テキストセグメントオブジェクト４５０は、テキストオブジェクト４５０に対するテキストコンテンツ自体を保持する記述属性４５２を有する。パラグラフオブジェクト４４２の最後に、ハイパーリンクエンドオブジェクト４５４は、ハイパーリンクペアＩＤを含む属性オブジェクト４５６によって構築される。

図１９Ａは、ロードされた構造化ドキュメント３８０のドキュメントオブジェクトモデル４６０、および、サーバ側のデータ処理システムによって用いられたパラグラフに対するＤＯＭ構成を示す。パラグラフオブジェクト４６２は、パラグラフ４６２の関連するスタイルおよびテキストのコンテンツを記述する属性オブジェクト４６４を有する。フォントオブジェクト４６６は、フォントコマンドを含み、関連する属性オブジェクト４６８は、フォント記述およびフォントスタイル情報を含む。パラグラフオブジェクト４６２にリンクされた次のコマンドオブジェクトは、ブックマークオブジェクト４７０、および、その記述属性オブジェクト４７２である。この記述属性オブジェクト４７２は、ブックマークＩＤを含む。次に、パラグラフオブジェクト４６２は、テキストオブジェクト４７４にリンクされ、このテキストオブジェクト４７４は、テキストコンテンツ自体の価値を有する属性オブジェクト４７６に関連する。図１９Ｂは、従って、図１９Ａによって開始されたＤＯＭパラグラフ構成４６０の続きである。パラグラフオブジェクト４６２にリンクされた次のコマンドオブジェクトは、テキストコマンドオブジェクト４７８、および、テキスト値を含む関連する属性オブジェクト４８０である。次は、新規のフォントコマンドオブジェクト４８２であり、関連する属性オブジェクト４８４は、フォントタイプおよびスタイルの定義を含む。次いで、パラグラフオブジェクト４６２にリンクされた以下のオブジェクトは、それぞれ、テキストコマンドオブジェクトおよびフォントコマンドオブジェクト、および、関連する属性４８６〜４９６であり、パラグラフ構成が参照コマンドオブジェクト４９８、および、その参照値を含む関連属性オブジェクト５００で終わる。

図２０は、ドキュメントオブジェクトモデル（ＤＯＭ）を構築した後、および、図１６によって示された構造化ドキュメント３８０をローディングした後にサーバ側のデータ処理システム１０によって用いられたテーブルコンポーネント４２８を示す。各テーブルコンポーネント４２８は、多数の列オブジェクト５１０、５１２を有し得る。ここで、１つ以上のセルが含まれてもよい。図２０は、サンプル構造化ドキュメント３８０にあるサンプルテーブルの最初の列を示す。テーブル列コマンドオブジェクト５１０は、セルコマンドオブジェクト５１４にリンクする。このセルコマンドオブジェクト５１４は、セルのテキストコンテンツ値を含む関連する属性オブジェクト５１６を有する。さらなるセルコマンドオブジェクト５１８、５２０、５２２および５２４は、次いで、これ以上のデータが列として利用可能ではなくなるまで、テーブル列コマンドオブジェクト５１０にリンクされる。

図２１Ａ〜２１Ｆは、インターネット１６を介してデータを無線で送達することに対して効果的かつ最適化された方法でデータを送信して、クライアント側のデータ処理システム１２によって処理されるために、本発明で用いられたユニバーサルコンテンツストリーム（ＵＣＳ）の形式で出力されたコンテンツにおけるサーバ側のデータ処理システム１０の記述を示す。図２１Ａ〜図２１Ｆは、２つのテーブルを有する。各テーブルは、図１６および１５でそれぞれ表される構造化ドキュメント３８０および非構造化ドキュメント３６０を生成するコマンドを示すＵＣＳデータファイルを出力する際のサーバ側の処理能力を示す。

図２２を参照して、ＵＣＳフォーマット５３０のレイアウトが示される。ＵＣＳ（ユニバーサルコンテンツストリーム）フォーマット５３０は、サーバ１０とクライアント技術またはデバイス１２との間のメカニズムおよびデータ送信層を提供する。このフォーマットの主な目的は、利用可能なバンド幅域、最適な方法で送信されている必要とされる視覚的イメージのみを可能とすることである。フォーマット５３０は、グラフィックイメージ／ピクチャ、２Ｄ／３Ｄ描画、ならびに、ワードプロセッサおよびスプレッドシートのコンテンツ等の様々なテキストデータの転送を支援する。

ＵＣＳは、トランスセラプト技術および任意の利用可能なバンド帯を利用するトランスセラプトコマンドおよびデータ転送に加えて、情報送信のために様々な異なる標準フォーマットを含み得る。ＵＣＳ内に最適な標準フォーマットを埋め込むことは、トランスセラプトサポートを必要としないクライアント技術を容易に統合することへとつながる。イメージ／ラスターデータ等のフォーマットに対して、ＪＰＥＧ２０００等の現在の／将来の基準は、サーバ１０からクライアント１２へのデータロスのない圧縮に対して十分なサポートを提供する。

サーバ１０と他のクライアントとの両方によってアクセスされ得る業界基準フォーマットの例は、以下の４つのタイプである。
・テキスト、メタデータおよびコンテンツ情報用のＸＭＬ・ベクトル情報用のＳＶＧ
・イメージ用のＪＰＥＧ２０００
・ＯｐｅｎＧＬ ３Ｄ表示
他の基準フォーマットまたは専有フォーマットは、コンポーネントベースのサーバ１０のプラグ可能（ｐｌｕｇａｂｌｅ）およびスケール可能（ｓｃａｌａｂｌｅ）なアーキテクチャによって容易に追加されるか、取り除かれるかされ得る。

ＵＣＳフォーマット５３０は、オプションの業界基準フォーマットと共にＵＣＳフォーマット５３０を作る３つの異なるデータ層を含む。この３つの専有層は、ＴＣＬ層、ＵＣＳテキストコンテンツ層５３４、および、ＵＣＳイメージまたはベクトルデータ層５３６である。

ＴＣＬ（トランスセラプトコマンド言語）層５３２は、サーバ１０とクライアント１２との間の双方向通信のためのデータチャネルを提供する。クライアント１２は、リクエストをサーバ側のクライアントハンドラに送信し、逆に、トランスセラプトデータストリームで応答を受信する。ＴＣＬは、以下のタイプのコマンドを取り扱う。すなわち、視覚的イメージ用のトランスセラプトリクエスト、ＶＱ（ビューおよびクエリ）コマンド、ディレクトリ情報、刊行されたドキュメントの検索／取り出し、および、任意の必要とされた第３パーティ情報同期である。ＴＣＬ言語自体は、また、容易に適応するために、および、さらに拡張するために、ＸＭＬを利用して構築される。

ＵＣＳベクトルストリーム５３６は、高度に最適化されたベクトルフォーマットであり、貧弱なクライアントソフトウェアにベクトル描画能力を提供する。これにより、この貧弱なクライアントソフトウェアは、小さなＰＤＡデバイスまたはハンドヘルドデバイスに対してさえもより高度で精密なベクトル表示を提供することができる。ベクトルストリーム転送およびレンダリングは、ＴＣＬ層５３２を通して制御される。このＴＣＬ層５３２は、トランスセラプトハンドラが、クライアント１２によって要求されたクリップされたビュー可能な領域に対してベクトル表示を生成し、そのリクエストを生成した制限されたクライアント表示領域のために、そのベクトル表示を最適な方法でレンダリングするのみであることを保証する。ＵＣＳフォーマット５３０は、新規の専有層またはフォーマットが容易に追加され得る様態で設計される。イメージ、ベクトルおよびテキストのトランスセラプションのために用いられたフォーマットのうちのいくつかも、第３パーティによって統合される必要があるならば、取り換えられるか、追加されてもよい。

ユニバーサルコンテンツストリーム（ＵＣＳ）５３０は、バイナリファイルフォーマット規格である。この規格は、元のドキュメントコンテンツ（このドキュメントコンテンツは、テキストコンテンツ、イメージデータ、ベクトルデータおよび処理されたドキュメントのためのナビゲーション情報を含むが、これらに制限されない）の送達を可能にする。ＵＣＳフォーマットは、利用可能なバンド帯域を考慮すると、無線デバイス１２の現在の制限を克服する際に非常に効果的である。今日一般的に、このバンド帯域は、理論的にはさらに高速にすることができるが、９．６から通常４８までの範囲である。ＵＣＳは、様々な方法で制限された帯域幅の問題を取り扱う。

ＵＣＳフォーマット５３０によって、元のドキュメントファイルサイズは、９０％まで減少可能となるが、クライアント側の処理能力を用いて無線デバイスにあるドキュメントを再構築するための全ての本質的なコンテンツおよび必要なフォーマット情報を保持している。このサイズの減少は、元のドキュメントアプリケーションによって用いられる本質的ではないフォーマット情報（例えば、デスクトップコンピュータ上でリッチ表示されたＭＳ Ｗｏｒｄ）を取り去ることによって達成される。本質的ではないフォーマット情報は、異なるフォントスタイル、フォントカラー、および、改訂情報等を用いることであり
得る。これらは、通常、無線デバイス１２上に値を有していない。なぜなら、デバイススクリーンは、モノクロームまたはグレースケールであり得、そのデバイスは、通常、１つのフォントタイプのみであるからである。ＵＣＳファイルフォーマットはまた、クライアント側で大きさをさらに減少するために、サーバ側でＵＣＳファイルを圧縮して、解凍することを可能にする。圧縮には、ＬＺＷ等の圧縮技術形式で共通に利用可能な技術が利用され得る。さらに、（伝送用のコンテンツを除いた）トランスセラプトを生成する際のサーバ側の処理能力によって、繰り返しのプロセスでサーバからクライアントへの個々の伝送に対して複数のＵＣＳファイルの生成を可能にする。このプロセスでは、無線デバイスに送信された生じたＵＣＳファイルは、ユーザからの特定のコンテンツクエリに対する結果である。サーバからのコンテンツを要求する、無線デバイスでのユーザからの繰り返しクエリプロセスは、例えば、デバイスに送達される各１０個のＵＣＳファイルを送達することにつながり得る。ＵＣＳファイルフォーマットは、一貫したビューイングまたは読み出しを通して元のドキュメントがメモリにある各ファイルによって再構成され得るように、これらの各ＵＣＳファイルがどのように共にリンクするかに関する情報を含む。ＵＣＳフォーマットはまた、ドキュメントオブジェクトモデル（ＤＯＭ）Ｉｄを含み、サーバ１０の処理能力が要求しているデバイス１２へ正しいＤＯＭ情報を送達可能であることを保証する。さらに、ＵＣＳファイルフォーマットはまた、クライアントがドキュメント内からより多くのコンテンツを要求することを可能にするインターネットハイパーリンクを含む。コマンドコードはまた、ＵＣＳフォーマットに組み込まれ得、サーバ側のデータ処理能力によって特定の処理の実行を容易にし得る。これは、通常、特定のコンテンツに対するリクエスト（例えば、ＤＯＭ等内に格納されたナビゲーション情報のルックアップ）である。

（用語の定義）
１．アナトミゼーション−全てのコンテンツおよびナビゲーションドキュメント階層構造を含む均一のドキュメントオブジェクトモデルを構築する目的で、構造化または非構造化ドキュメント、あるいは、データソースを（ｐａｒｓｉｎｇ）パーシングするおよび解析する特定の技術プロセス。
２．ブックマーク−ドキュメント内にある位置Ｘから位置＆へのナビゲーション参照に関連するナビゲーションリンク。
３．ＤＯＭ−ドキュメントオブジェクトモデル（ＤＯＭ）、すなわち、ワールドワイドウェブコンソーシアムによって開発されているプログラミングインタフェース規格であり、オブジェクトとしてＸＭＬベースのドキュメントを生成かつ構造化する方法を定義する。４．外部ファイル−関連する外部データ、または、元のドキュメントの外部にあるドキュメントファイルに対する参照。
５．外部オブジェクト−元のドキュメントの外部にある関連する外部データオブジェクトに対する参照。
６．フォントカラー−フォントの色。
７．フォント位置−レンダリングｘ，ｙピクセルまたは文字の位置情報。
８．フォントサイズ−フォント文字のサイズをポイントで示すフォントの大きさ。
９．フォントスタイル−普通、イタリック、ボールド、下線等のフォントのスタイル。
１０．フォントタイプ−ドキュメントで用いられるフォントタイプの名前（例えば、タイムズローマン）。
１１．フッタ−コンテンツを含むドキュメントにあるそれぞれのまたは全てのページの底部にある脚注。
１２．ヘッダ−コンテンツを含むドキュメントにあるそれぞれのまたは全てのページの上部にあるヘッダ。
１３．ハイパーリンク−ブックマークまたは外部データ、あるいは、コンテンツソースを参照するドキュメントコンテンツの外部または内部にあるナビゲーションリンク。
１４．ページ−定型ページまたはプリンタページの中断ページの文字によって通常分離されたコンテンツ情報を含むドキュメントにあるそれぞれの（ａｇｅ）年代を定義するもの。
１５．パラグラフ−中断ラインによって分離された結合性のある本体でグループ化されたテキスト線の集合。
１６．予測キャッシング−無線／有線デバイスへの必要とされた送達／伝送の前にサーバにある該当または関連するコンテンツをキャッシュして、帯域幅およびネットワーク待ち時間を最小化するように設計された特定の技術プロセス。
１７．コンテンツテーブル−ドキュメントコンテンツのナビゲーションを通知して、支援するためにドキュメントコンテンツに階層構造のナビゲーション構造を提示するもの。
１８．タイトルスタイル−ヘッディング１、ヘッディング２、ヘッディング３のようにテーブルコンテンツの構成を考慮した上でのドキュメントの中央生成アプリケーションにおける予め定義されたスタイル。
１９．トランスセラプション−要求されたコンテンツの抜粋のみを送達して、これをクライアントに伝送する特定の技術プロセス。
２０．ＵＳＣ−最小化されたデータサイズのために最適化されたコンテンツデータフォーマットするユニバーサルコンテンツストリームであって、無線／有線デバイスへの送達のためのコンテンツの文脈、ナビゲーションおよび提示の情報を保存する。
２１．ＸＭＬ−共通の情報フォーマットを生成する柔軟な方法であり、ワールドワイドウェブ、イントラネットおよびその他にあるフォーマットとデータとの両方を共有する拡張マークアップ言語。

Claims (17)

1. 携帯用計算デバイスにコンテンツを送信する方法であって、
   該方法は、
   該携帯用計算デバイスに対して遠隔のスキャンされたドキュメントに関連付けられたコンテンツに対する要求を該携帯用計算デバイスから受信することと、
   該要求されたコンテンツに関連付けられた該スキャンされたドキュメントの１つ以上の部分を識別することと、
   該識別された１つ以上の部分の情報タイプを決定することであって、該情報タイプは、テキスト内容を表す画像、絵を表すバイナリ画像、線または円の描画要素を用いた図を表す画像のうちの１つである、ことと、
   該スキャンされたドキュメントの質を改善するために、該決定された情報タイプに従って該識別された１つ以上の部分を処理することと、
   ドキュメントオブジェクトモデル（ＤＯＭ）格納装置に格納されている該スキャンされたドキュメントの要素から、該スキャンされたドキュメントの該識別された１つ以上の部分を再構成することと、
   該携帯用計算デバイスに表示するために、該識別され再構成された１つ以上の部分をユニバーサルコンテンツストリームで該携帯用計算デバイスに伝送することであって、該ユニバーサルコンテンツストリームは、該携帯用計算デバイスにおいて該スキャンされたドキュメントを再生するために、本質的なコンテンツおよびフォーマットデータを含み、該本質的なコンテンツおよびフォーマットデータは、テキストコンテンツと、画像データと、ベクトルデータと、ナビゲーション情報とを含み、該ユニバーサルコンテンツストリームは、本質的ではないフォーマット情報を含まず、該本質的ではないフォーマット情報は、異なるフォントスタイルと改訂情報とを含む、ことと
   を包含し、
   該携帯用計算デバイスは、該スキャンされたドキュメントの該識別され再構成された１つ以上の部分を表示するためのドキュメントリーダソフトウェアアプリケーションを含み、該ドキュメントリーダソフトウェアアプリケーションは、複数のビューモードを有するグラフィックユーザインタフェースを生成し、該ドキュメントリーダソフトウェアアプリケーションは、該複数のビューモードのうちのどれが異なるタイプのデータに対して最適であるかを決定し、該最適なビューモードまたは複数のビューモードの組み合わせで該データを描画する、方法。
2. 前記ＤＯＭ格納装置に格納されている前記スキャンされたドキュメントの要素に従って該スキャンされたドキュメントの前記識別された１つ以上の部分をインデックス付けすることをさらに包含する、請求項１に記載の方法。
3. 前記スキャンされたドキュメントの１つ以上の部分を識別することは、該スキャンされたドキュメントの１つ以上の部分を識別するために、ルックアップまたはナビゲーションツリーを利用することを包含する、請求項１に記載の方法。
4. 前記スキャンされたドキュメントの１つ以上の部分を識別することは、前記要求されたコンテンツに最も関連する該スキャンされたドキュメントの部分を決定するために１つ以上の確率アルゴリズムを利用することを包含する、請求項１に記載の方法。
5. 前記識別された１つ以上の部分を再構成することは、前記携帯用計算デバイスと互換性がある所定のフォーマットで該識別された１つ以上の部分を再構成することを包含する、請求項１に記載の方法。
6. 携帯用計算デバイスにドキュメントコンテンツを無線送信する方法であって、
   該方法は、
   該ドキュメントコンテンツに対するナビゲーションリンクを構築するために、スキャンされたドキュメントの視覚的表示に基づく解析的処理によって、存在するナビゲーション要素、または、何も存在しない場所を識別することにより、構造化または非構造化された、スキャンされたドキュメントのコンテンツを解析することと、
   該コンテンツの情報タイプを決定することであって、該情報タイプは、テキスト内容を表す画像、絵を表すバイナリ画像、線または円の描画要素を用いた図を表す画像のうちの１つである、ことと、
   該スキャンされたドキュメントの質を改善するために、該決定された情報タイプに従って該コンテンツを処理することと、
   該スキャンされたドキュメントにあるコンテンツに対する要求を該携帯用計算デバイスから受信することと、
   該ナビゲーションリンクを用いて、該要求されたコンテンツを発見し、ユニバーサルコンテンツストリームで該携帯用計算デバイスに伝送することであって、該ユニバーサルコンテンツストリームは、該携帯用計算デバイスにおいて該スキャンされたドキュメントを再生するために、本質的なコンテンツおよびフォーマットデータを含み、該本質的なコンテンツおよびフォーマットデータは、テキストコンテンツと、画像データと、ベクトルデータと、ナビゲーション情報とを含み、該ユニバーサルコンテンツストリームは、本質的ではないフォーマット情報を含まず、該本質的ではないフォーマット情報は、異なるフォントスタイルと改訂情報とを含む、ことと
   該携帯用計算デバイスにおいて該コンテンツを受信して、該コンテンツを該デバイス上で再構成することと
   を包含し、
   該携帯用計算デバイスは、該スキャンされたドキュメントの該再構成されたコンテンツを表示するためのドキュメントリーダソフトウェアアプリケーションを含み、該ドキュメントリーダソフトウェアアプリケーションは、複数のビューモードを有するグラフィックユーザインタフェースを生成し、該ドキュメントリーダソフトウェアアプリケーションは、該複数のビューモードのうちのどれが異なるタイプのデータに対して最適であるかを決定し、該最適なビューモードまたは複数のビューモードの組み合わせで該データを描画する、方法。
7. 前記解析または処理されたドキュメントコンテンツの要素に従って前記構造化または非構造化された、スキャンされたドキュメントのコンテンツをインデックス付けすることをさらに包含する、請求項６に記載の方法。
8. 前記解析中にコンテンツテーブルを作成することと、前記携帯用計算デバイスが前記コンテンツを要求するために該コンテンツテーブルを利用することとを包含する、請求項６に記載の方法。
9. 前記コンテンツをドキュメントオブジェクトモデルに格納することと、該ドキュメントオブジェクトモデルから前記要求されたコンテンツを取得することとを包含する、請求項６に記載の方法。
10. 前記スキャンされたドキュメントを解析することは、該スキャンされたドキュメントをアナトミゼーション（ａｎａｔｏｍｉｚｉｎｇ）することを包含する、請求項６に記載の方法。
11. 前記スキャンされたドキュメントのコンテンツの抜粋を前記携帯用計算デバイスに伝送することを包含する、請求項６に記載の方法。
12. 前記コンテンツの要求に関連した該コンテンツの抜粋、および、以前に送られた該コンテンツの抜粋を予測キャッシングすることを包含する、請求項１１に記載の方法。
13. コンテンツを携帯用計算デバイスに送信するシステムであって、
    該システムは、
    携帯用計算デバイスと、
    該携帯用計算デバイスに対して遠隔のスキャンされたドキュメントに関連付けられたコンテンツに対する要求を該携帯用計算デバイスから受信する手段と、
    該要求されたコンテンツに関連付けられた該スキャンされたドキュメントの１つ以上の部分を識別する手段と、
    該識別された１つ以上の部分の情報タイプを決定する手段であって、該情報タイプは、テキスト内容を表す画像、絵を表すバイナリ画像、線または円の描画要素を用いた図を表す画像のうちの１つである、手段と、
    該スキャンされたドキュメントの質を改善するために、該決定された情報タイプに従って該識別された１つ以上の部分を処理する手段と、
    ドキュメントオブジェクトモデル（ＤＯＭ）格納装置に格納されている該スキャンされたドキュメントの要素から、該スキャンされたドキュメントの該識別された１つ以上の部分を再構成する手段と、
    該携帯用計算デバイス上に表示するために、該識別され再構成された１つ以上の部分をユニバーサルコンテンツストリームで該携帯用計算デバイスに伝送する手段であって、該ユニバーサルコンテンツストリームは、該携帯用計算デバイスにおいて該スキャンされたドキュメントを再生するために、本質的なコンテンツおよびフォーマットデータを含み、該本質的なコンテンツおよびフォーマットデータは、テキストコンテンツと、画像データと、ベクトルデータと、ナビゲーション情報とを含み、該ユニバーサルコンテンツストリームは、本質的ではないフォーマット情報を含まず、該本質的ではないフォーマット情報は、異なるフォントスタイルと改訂情報とを含む、手段と
    を含み、
    該携帯用計算デバイスは、該スキャンされたドキュメントの該識別され再構成された１つ以上の部分を表示するためのドキュメントリーダソフトウェアアプリケーションを含み、該ドキュメントリーダソフトウェアアプリケーションは、複数のビューモードを有するグラフィックユーザインタフェースを生成し、該ドキュメントリーダソフトウェアアプリケーションは、該複数のビューモードのうちのどれが異なるタイプのデータに対して最適であるかを決定し、該最適なビューモードまたは複数のビューモードの組み合わせで該データを描画する、システム。
14. 前記ＤＯＭ格納装置に格納されている前記スキャンされたドキュメントの要素に従って該スキャンされたドキュメントの前記識別された１つ以上の部分をインデックス付けする手段をさらに含む、請求項１３に記載のシステム。
15. 前記スキャンされたドキュメントの１つ以上の部分を識別する手段は、該スキャンされたドキュメントの１つ以上の部分を識別するためにルックアップまたはナビゲーションツリーを利用する手段を含む、請求項１３に記載のシステム。
16. 前記スキャンされたドキュメントの１つ以上の部分を識別する手段は、前記要求されたコンテンツに最も関連する該スキャンされたドキュメントの部分を決定するために１つ以上の確率アルゴリズムを利用する手段を含む、請求項１３に記載のシステム。
17. 前記識別された１つ以上の部分を再構成する手段は、前記携帯用計算デバイスと互換性がある所定のフォーマットで該識別された１つ以上の部分を再構成する手段を含む、請求項１３に記載のシステム。

Images