"明細書に記載の発明。このように、無線デバイスがドキュメントのサイズまたはドキュメントに関係なく電子ドキュメントへのアクセスを有することを可能とするシステムを提供することが望まれる。本発明の要旨本発明は、共通のマークアップ言語を用いてドキュメントオブジェクトモデルの電子ドキュメントを解析、統括および格納するシステムを提供する。ドキュメントオブジェクトモデルは、サーバに格納され、コンテンツは、ユニバーサルコンテンツストリームフォーマットで無線デバイスに送達される。ドキュメントオブジェクトモデルおよび無線デバイスに対応するリーダを有するユニバーサルコンテンツストリームを利用することによって、電子ドキュメントは、基本的なコンテンツおよび無線伝送に必要なフォーマット情報のみに減少される。上記の関連する利点を達成することによって、本発明は、添付の図面で示されたフォームで具現化され得る。しかし、図面は、例として示すのみであり、本発明の範囲を逸脱することなく示された明細書の構成に変更があってもよいことは、事実として注目すべきである。様々な他の機能、特徴および本発明の付属の利点は、これらが添付の図面と共に説明された場合に完全に認識される。この図面において、同様な参照文字は、いくつかのビュー全体で、同じまたは類似の部分を示す。発明の詳細な説明本発明が利用され得る1つ以上の無線デバイスまたはクライアント12と通信するデータ処理システムまたはサーバ10が図1に示される。データ処理システム10は、通常、中央処理ユニット、内部マス格納装置およびランダムアクセスメモリ等の従来のコンポーネントを含む。これらは、本発明で利用される。データ処理システム10への連絡、および、データ処理システム10からの連絡は、通常、従来の態様では、ファイアフォール/プロキシサーバ12として周知の安全なソフトウェアまたはハードウェア処理システム/ユニットを介して往来し、本発明が開発されるネットワークへの認証され、かつ、有効なアクセスを保証する。データ処理システムまたはサーバ10で実行する本発明は、通常、インターネット16を介して上りデータを受信し、無線デバイスまたはクライアントに常駐する本発明の一部へと下りデータを伝送する。本発明の現在の実施形態は、データ処理システム10として、DELL、COMPAQ、SUNまたは他のWindowsRオぺレーティングシステムリリースNT4/2000/XP以上、または、SunSolarisオぺレーティングシステムリリース8以上で動作するサーバハードウェアの他の認識されている製造業者を利用し得る。図2は、データ処理システムまたはサーバ10、および、無線デバイスまたはクライアント12をより詳細な概略を示す。サーバ10は、中央処理ユニットCPU20、ランダムアクセスメモリRAM22および内部マス格納デバイス24を含み、全ては、バス26で周知のデータチャネルによって相互接続されている。データ処理システム10は、インターネット16を介して無線デバイスクライアント12と通信する。無線デバイスクライアント12処理システムは、小さなフットプリントデバイス例えば、MotorolaDragonBallCPUまたはIntelStrongARMCPUとして設計された中央処理ユニットCPU28を含む。この中央処理ユニットCPU28は、小さなフットプリント無線デバイスオぺレーティングシステム例えば、PalmOSまたはPocketPCOSを格納する読み出し専用メモリRAM30と、内部フラッシュラムメモリ格納装置32と接続され、無線ラジオ/モデム34を利用してインターネット16と通信する。これら全ては、データバス36を用いて共に接続されている。データ処理システム10は、好ましくは、CおよびJAVAR等の典型的なプログラミング言語を利用するオぺレーティングシステムによって提供された機能を用いて実行するように書かれたデータ命令を利用可能なオぺレーティングシステムを伴うことによって本発明の本実施形態の機能を実行かつ行うように構成される。図3は、本発明に関して、本発明のサーバ側処理モジュールに対する処理フローのブロックダイアグラムを示す。定義によるモジュールは、オプションまたは必須の個々のデータ処理である。これらは、他のモジュールと結合され、本発明のデータ処理システム10を形成する。構造化または非構造化電子ドキュメント、あるいは、データストリーム40は、無線または有線クライアント側12から提出され、バイナリデータとしてネットワークからサーバ10に入る。クライアント提出ハンドラ42は、クライアントリクエストを受信し、これが有効なリクエストであることを検証し、サーバ通信バス44を介してクライアントリクエストに基づいて適切なルーティングコマンドによって受信されたデータを通過させる。クライアント提出ハンドラ42は、ルーティングコマンドを読み出し、ルーティングコマンドによって示された必要な順序で、必要な処理モジュールに受信されたデータを送信する。第1のルーティングコマンドが前処理モジュールPPM46に対するリクエストである場合、受信データは、ドキュメントまたはデータ最適化のために通過される。ドキュメントタイプがイメージを描くテキストの内容を含み、絵を表すバイナリイメージ、または、線または円の描画要素を用いて図を描く走査要素を含む走査された要素である場合、前処理モジュール46の主な目的は、本発明による利用のためのドキュメントの質を改善することである。イメージを描くテキストのコンテンツを含むスキャンされたドキュメントに対して、視覚的文字認識OCRとして公知の技術は、本発明によって処理用にテキストの文字を抽出する目的に用いられる。任意のOCRスタイルソフトウェアパッケージ例えば、ScanSoftCorporationによるOmniPageがこの目的に対して本発明に適用され得る。絵を示すイメージに対して、本発明は、イメージの質例えば、シャープにする、ぼかす、ガウスぼかし、モーションぼかし、輝度、明暗、ガンマ修正、変換、色相および彩度、ヒストグラム平均化、エンボス加工、モザイク、メジアン、アベレージを改善するための周知のイメージアルゴリズムを適用してもよい。線または円描画要素を用いて絵を描くスキャンされたドキュメントに対して、ラスタートゥーベクトルR2Vソフトウェアは、描画要素を抽出し、かつ、スキャンされた図からの情報を位置付ける目的のために用いられ、本発明の無線/有線クライアントにあるベクトル描画データとして提出されたイメージを再構築する。任意のR2Vスタイルのソフトウェアパッケージ例えば、SoftTelecからのVPHybridCADがこの目的のために本発明によって利用され得る。サーバ通信バス44は、次いで、アナトマイゼーションAnatomizationモジュールAM48上にデータ40をルーティングする。このアナトマイゼーションモジュールAM48は、ドキュメントのアナトミーanatomyを構築する責任を負い、図17に記載されたドキュメントオブジェクトモデルDOMを形成しpopulate、従属するプロセスがSCB44を用いて、ドキュメント処理モジュールCPM50にデータをルーティングする。このドキュメント処理モジュールCPM50では、図13に記載されたエンジンは、ディスティラーdistillerモジュールを用いて構造化または非構造化ドキュメントをロードする。SCB44のルーティングコマンドがDPM50によってパースparseされるドキュメントデータを維持する保存するコマンドを含む場合、ドキュメントデータは、ドキュメントデータベースDDB52に保存される。ドキュメントデータベース52は、データベース例えば、MicrosoftCorporationからのMicrosoftSQLサーバを共通して参照する通常のソフトウェアパッケージに対するコレクタである。DPM50によってドキュメントの処理が首尾良く完了すると、SCB44は、アナトミゼーションモジュール48に逆にコマンドを発して、ドキュメントオブジェクトモデルは、ドキュメントのコンテンツおよびアナトミーによって更新される。インデックス付けリクエストがSCB44のコマンドスタックの一部である場合、インデックス付けモジュールISM54が呼び出され、ドキュメントのアナトミゼーションモジュール48から利用可能なテキストコンテンツは、周知のソフトウェア製品例えば、MicrosoftからのIndexingServerを用いてインデックス付けされる。ドキュメントオブジェクトモジュールに関連する参照による結果は、インデックス付けサーバデータベース56に格納される。ISM54によって完了すると、SCB44コマンドスタックは、トランスセラプトTranscerptモジュールTM58Transcerpt=transmit伝送するexcerpt抜粋するを呼び出し、コンテンツの最初の抜粋は、アナトミゼーションモジュール48を呼び出して、ドキュメントオブジェクトモジュールで利用可能なコンテンツに基づいてドキュメントのコンテンツまたは要旨の最初のテーブルを要求することによって伝送のために準備される。AM48によるトランスセラプトをリターンすると、最初のトランスセラプトのコピーは、繰り返してアクセスする目的のためにトランスセラプトキャッシュTC60に置かれる。SCB44が予測キャッシングモジュール62のリクエストを含む場合、AM48は、ドキュメントからの関連するコンテンツデータのための将来のクライアントリクエストを予測するためにクライアントセッション期間繰り返して呼び出される。予測キャッシングモジュール62は、次いで、クライアントセッション期間に、トランスセラプトモジュール58からのトランスセラプト結果によってトランスセラプトキャッシュ60を形成するpopulate。初期のトランスセラプトは、次いで、TM58から完了すると、SCB44を介してトランスセラプトハンドラ-64にリターンされる。トランスセラプトハンドラ-64では、リターンデータ用の正しいクライアントデバイス12が識別され、トランスセラプトは、ネットワーク16に送られ、無線/有線クライアント12に戻される。クライアント提出ハンドラー42が以前に提出されたドキュメントからより多くのコンテンツのためのクライアントリクエストを受信する場合、クライアント提出ハンドラー42は、サーバ通信バス44を介するリクエストを通過させる。サーバ通信バス44は、順に、そのリクエストをトランスセラプトモジュール58に渡す。トランスセラプトモジュール58は、次いで、トランスセラプトキャッシュ60を調査して、予測キャッシングモジュール62によって生成されたトランスセラプトが伝達のために利用可能であるかどうかを観察する。利用可能ではない場合、アナトミゼーションモジュール48が呼び出され、新規のトランスセラプトは、システム10のためのドキュメント提出用に記述された手順を追跡するように準備される。完了すると、トランスセラプトは、トランスセラプトキャッシュ60に置かれ、トランスセラプト64は、再び呼び出され、初期のドキュメント提出として記載されたように、クライアント無線/有線デバイス12にトランスセラプトを送達する。図4は、本発明によって刊行するために提出されたドキュメントまたはコンテンツリクエスト70のパッケージングを示す。CMLベースのメタデータ記述72は、パッケージングのカプセルであり、適切なサーバコマンド例えば、publish刊行するqueryまたはクエリする、情報例えば、デバイスタイプ、デバイススクリーンサイズ、自由格納スペース、推定された帯域幅転送速度等を提供する要求デバイス12の無線デバイスの性質、および、ドキュメント70の情報例えば、ドキュメント名、ドキュメントの日付、ドキュメントタイプまたは任意の他の捕捉情報を含む。元のドキュメントまたはコンテンツリクエスト70の固有のドキュメントID74は、ドキュメント提出リクエストの他の一部を作る。固有のドキュメントIDがリクエストの一部として送られる場合、その固有のドキュメントIDは、ドキュメントが既に発行され、サーバがトランスセラプトキャッシュ60を参照して、固有のドキュメントIDに基づくドキュメントデータベース52からのドキュメント取り出していることを示す。図5は、データ処理システムサーバ10への無線クライアント12提出要求のためのフローチャートプロセス80を示す。データを有する入来要求82が到着する。プロセス80の第1のステップは、入来要求82が新規の刊行要求84であるかどうかを構築することである。入来要求が固有のドキュメントID74を有する場合、入来要求は、新規の刊行要求ではなくいいえ、ドキュメントは、既にサーバデータ処理システム10に常駐しており、従って、トランスセラプト処理ステップ96が直接行われる。元のドキュメントが提出される場合、メタデータ72は、前処理86を実行するクライアント要求が存在するかどうかを参照するように処理され、前処理モジュール46は、ステップ88で呼び出される。そうではない場合、アナトミゼーション処理90が実行される。アナトミゼーション処理モジュール48からの処理が完了すると、メタデータ72は、アナトマイズされたコンテンツに対してインデックス付け92を実行するクライアント要求が存在するかどうかを参照するように処理されう。これがトゥルーtrueである場合、インデックス処理モジュール54が呼び出され、コンテンツは、ステップ94でインデックス付けされる。ステップ92および/またはステップ94が完了すると、トランスセラプトモジュール58は、初期のコンテンツの結果を要求している無線クライアント12に戻して送達する目的のためにステップ96で呼び出される。図6は、サーバ通信バス44SCBのサーバ側のデータ処理システム10のデータフローを示すフローチャート100である。入来要求および/またはデータは、SCBによる受信され102、SCBは、入来要求がSCB44にとって有効な要求104であるかどうかを決定するように見る。要求が有効である場合はい、コマンドおよび関連データは、SCBによって取り出される106。関連データは、元のドキュメントまたは元のドキュメントに固有のIDである。SCBコマンドが未解決pendingであるので、データは、適切な処理モジュールにルーティングされる108。このモジュールにおいて、SCBコマンドの任意の1つまたは組み合わせは、システムモジュールドキュメント処理モジュール50、アナトミゼーションモジュール48、前処理モジュール46、インデックス付けモジュール、トランスセラプトモジュール58のうちの任意を含むサーバ側のデータ処理システム10によって実行される。それぞれのデータ処理システムモジュール46、48、50、54、58によって処理するデータに対してSCB44が同期リクエスト要求と非同期リクエスト要求との両方を処理するように設計されるので、SCB44がステップ110で処理されるさらなるコマンドおよびデータが存在するかどうかをチェックする場合、要求は、完了してもよいし、しなくてもよい。より多くのコマンドまたはデータが存在する場合はい、コマンドスタックが空になるまで、処理は、ステップ106で開始し続ける。それ以上のデータまたはコマンドがステップ110で止まっていない場合、SCB44は、ステップ112のサーバ側データ処理モジュールから要求している無線/有線クライアント12への適切な応答および結果のデータをリターンする。有効なコマンドがステップ104でSCBによって検出されない場合いいえ、適切な失敗コードがステップ112で割り当てられ、結果のリターンまたは応答は、要求している無線または有線クライアント12に送られる。図7は、前処理モジュール76のためのサーバ側のデータ処理システムを説明するフローチャートを示す。上りデータ122がSCB44で受信される。有効ステップ124は、上りデータ122は、有効な前処理コマンドかどうかを参照するように実行される。コマンドが有効な前処理コマンドとして認識されない場合いいえ、結果のエラーコードは、ステップ126でE_FAILに設定され、エラーコードは、ステップ128でSCBの下りデータとしてリターンされる。コマンドが有効な処理コマンドはいであることをステップ124が決定する場合、ステップ130は、前処理コマンドによって提出されたドキュメントタイプが有効なサポートされたドキュメントであるかどうかを参照することをチェックする。答えが否定である場合いいえ、ステップ126は、再び結果のエラーコードをE_FAILに設定して、エラーコードは、ステップ128でSCBで下りデータとしてリターンされる。これがステップ130で有効なドキュメントタイプであるはいと決定される場合、処理モジュール46は、ステップ132で呼び出される。うまくいったステップ130の一部として決定されたドキュメントタイプに基づいて、適切な前処理サブモジュール134、136または138が呼び出される。ステップ134は、通常OCRと呼ばれる光学的文字認識を実行して、走査されたドキュメントをテキストのコンテクストに変換する。本発明は、ScansoftCorporationによるOmniPage等のソフトウェアベンダーからOCR用に販売されているソフトウェアを用いるように設計されている。ステップ136は、ステップ130で決定された有効なドキュメントタイプが保存された形式例えば、BMPビットマップまたはJPEGJointPhotographicExpertsGroup共同写真専門化グループでイメージまたは写真データである場合に、ステップ132によって呼び出される。これらの形式では、周知の数学の公式が用いられ得、画像写真データの視覚的な局面例えば、シャープにする、ぼかす、ガウスぼかし、モーションぼかし、輝度、明暗、ガンマ修正、変換、色相および彩度、ヒストグラム平均化、エンボス加工、モザイク、メジアン、アベレージを改善し得る。ステップ138は、ステップ132で決定された有効なドキュメントタイプがスキャンされた絵であり、ラインまたは円の描画要素を用いて絵画を描く場合に、ステップ132によって呼び出される。ステップ138は、次いで、絵の要素を抽出して、走査された絵画からの情報を位置付けるために、販売されているラスターツーベクトルR2Vソフトウェアを用いて、無線/有線クライアント12のベクトル描画データとして提出された画像を再構成または再生成する。SoftTelecによるVPHybridCAD等の任意のR2Vスタイルソフトウェアパッケージは、この目的のために本発明によって利用され得る。ステップ132によって任意のサブプロセス134、136、138が完了すると、ステップ140は、プロセスが成功したと決定されるかどうかをチェックする。ステップ140が成功である場合はい、前処理されたデータは、ステップ128でSCBに逆にリターンされる。ステップ132からの結果が成功ではないとステップ140が決定する場合いいえ、結果のエラーコードがステップ126においてE_FAILに設定され、エラーコードは、ステップ128においてSCBに対する下りデータとしてリターンされる。図8は、アナトミゼーション処理48のためのサーバ側データ処理システム10の処理フローを示すフローチャート150である。SCBからの上りデータは、ステップ152において受信され、ステップ154へと渡される。ステップ154において、ドキュメントデータが有効であるかどうかが決定される。ドキュメントデータが有効ではない場合いいえ、ステップ156は、E_FAILに結果のエラーコードを設定し、DOMへのポインタは、ゼロまたはNILに等しく設定され、ステップ158においてエラーコードをSCBの下りデータとしてリターンする。ドキュメントデータがステップ154において有効であるはいと決定された場合、受信されたドキュメントデータは、ステップ160においてパーシングされ、次いで、ドキュメントオブジェクトモデルDOMは、ステップ162において構築される。DOMがステップ162によって構成された後、ステップ164は、構築されたDOMを維持または格納するためのコマンド要求が存在するかどうかをチェックする。ステップ164がトゥルーであるはい場合、DOMデータは、ステップ168まで継続している前にステップ166においてドキュメントデータベース52に格納される。ステップ164がフォルスfalseであるいいえ場合、ステップ168は、デコレータを適用するコマンドが存在するかどうかを参照することをチェックする。デコレータは、ステップ162によって構築されたドキュメントオブジェクトモデルを横断して、コンテンツまたはナビゲーション情報例えば、コンテンツテーブルTOC、ブックマーク、ハイパーリンク、ファインドテキストFindText等を抽出するコマンドである。ステップ168が適用するデコレータコマンドを全く有さないいいえ場合、ステップ170は、結果のコードをS_OKに設定し、ステップ158において下りデータをリターンする前にDOMポインタを設定する。デコレータが適用されるはいことをステップ168が決定する場合、ステップ172が呼び出され、デコレータは、ステップ162で構築されたDOMを横断する。ステップ172が完了すると、結果のコードは、S_OKに設定され、DOMポインタは、ステップ158で下りデータをリターンする前にステップ172において設定される。図9は、サーバ側のデータ処理システム10のためのインデックス付け処理54のフローチャート180を示す。SCB44からの上りデータがステップ182に到着する。ステップ184は、データにインデックス付けするリクエストがあるかどうかをチェックする。ステップ184が偽いいえと判定されると、ステップ186は、結果コードをE_FAILに設定して、その結果は、ステップ188でSCBに下りデータとしてリターンされる。ステップ184が真はいであると、システムは、ステップ190でドキュメントオブジェクトモデルDOMをトラバース開始する。ステップ192で、単一のDOMエレメントのコンテンツが取り出され、システム10は、ステップ194でインデックスを構築開始する。ステップ194で、システムは、Microsoftインデックス付けサーバ等の購入可能なソフトウェアインデックス付けパッケージを通常用いる。取り出されたDOMエレメントのコンテンツがステップ194でインデックス付けされた後、ステップ196は、DOMトラバーサルが完了するかどうかを観察するようにチェックする。答えがいいえであると、ステップ192および194は、DOMトラバーサルがステップ196で完了するはいであるまで再び処理される。インデックスは、次いでステップ198でインデックスデータベース56に格納され、結果のコードは、その結果がステップ188でSCBへの下りデータとしてリターンされるまで、ステップ200でS_OKに設定される。インデックスDB56は、ステップ198で利用され、MSSQLサーバまたはOracle等の任意の販売用データベース商品であり得る。図10は、サーバ側のデータ処理システム10用のトランスセラプションモジュール58のプロセスフローチャート210である。上りデータは、SCBからステップ212に到着して、チェックされ、この上りデータがトランスセラプトリクエストかどうかをステップ214で調べられる。それがトランスセラプトリクエストではない場合いいえ、ステップ216は、結果のコードをE_FAILに設定して、下りデータとしてその結果をステップ218のSCBに戻す。データがトランスセラプトリクエストであるはいと、ステップ214が判定する場合、ドキュメントオブジェクトモデルのIDを得るためにステップ220が呼び出される。DOMIDは、トランスセラプトキャッシュ60か、ドキュメントデータベース52のいずれかから正しいドキュメントを識別するために用いられる。ステップ222は、データがキャッシュ60で利用可能かどうかを調べるためにチェックする。答えがはいである場合、ステップ224は、トランスセラプトキャッシュ60からデータを得て、ステップ226は、その結果をS_OKに設定して、ステップ218で下りデータをSCBにリターンする。キャッシュにデータが無い場合いいえ、ステップ222は、メモリでロードされたDOMがあるか、および、メモリでロードされたDOMがDOMIDにマッチしているかどうかを調べる。システム10がキャッシングを用いているので、システム10は、特定数のドキュメント例えば、最後に処理された32個のドキュメントのためのDOMおよびDOMIDを保持し、DOMIDがキャッシュにあるDOMコンテンツのいくつかとマッチする場合、DOMが既にキャッシュに無いのなら、DOMIDがメモリに戻され、それは、処理された最後のドキュメントであったことを意味する。ステップ228におけるテストは、メモリにDOMが存在しない、または、DOMIDがマッチしないいいえDOMがキャッシュにないことを意味することを判定する場合、ステップ230が呼び出され、ステップ232に進む前にドキュメントデータベース52からDOMを取り出す。システム10は、DOMがデータベースに保存されるか、DOMを最初に生成するために用いられる元のドキュメントを再処理せずすぐに取り出すためにファイリング可能にする。メモリにDOMがあり、ドキュメントIDがマッチするはいことをステップ228が判定する場合、ステップ232は、トランスセラプトを得るために呼び出される。ステップ234は、上りデータとしてステップ212でSCBから受信したSDBコマンドが予想したキャッシングフラッグセットを有するかどうかを検証するために観察する。フラッグが設定される場合はい、ステップ236は、ステップ238に進む前に非同期の予想キャッシングプロセス62を開始する。フラッグが設定されないことをステップ234が判定する場合いいえ、ステップ238が呼び出され、ステップ232で呼び出されたトランスセラプトデータは、キャッシュ60に託される。ステップ240は、次いで、コミットが完了したかどうかを調べるために繰り返してテストし、テスト結果が否となる場合にステップ238に戻る。ステップ240がコミット完了のために真をリターンする場合、ステップ224が呼び出され、トランスセラプトデータは、キャッシュから取り出される。ステップ226は、結果をS_OKに設定して、ステップ218で下りデータをSCBにリターンする。図11は、無線デバイスまたはパーソナルデジタルアシスタントPDAに常駐する本発明の無線クライアント処理システムの詳細図250である。リーダ252は、関数を無線PDA/デバイスオぺレーティングシステム270に呼び出す複数の別々のソフトウェア関数エレメントおよびライブラリ254~266を含むソフトウェアアプリケーションである。オぺレーティングシステム270は、オぺレーティングシステム270を形成する複数の別々のソフトウェア関数を含む。無線PDA/デバイス用の周知のオぺレーティングシステムOSは、PalmCorporationのPalmOS、MicrosoftCorporationのWindowsRCE、SunCorporationのJ2ME、SymbianのEPOCおよびQualcommのBREWである。本発明のクライアント側のソフトウェア関数は、通常UCSと呼ばれる、定義されたユニバーサルコンテンツストリームを読み出すように設定されている。リーダ252は、テキスト、ベクトルおよびイメージベースのデータをデバイス12にレンダリングするように用いられるグラフィック命令のセットを提供するグラフィック関数ライブラリ266を有する。これを達成するために、ライブラリ266は、デバイスOS270からの利用可能なグラフィックオペレーションを用いる。コア関数ライブラリ264は、メモリアクセスおよびハンドリング272、ファイル入力/出力および/またはデータベースアクセス274、およびインターネット16からデータを取り出すための無線データアクセス276用にデバイスOS270から導かれた関数のセットを提供する。次いで、リーダ252は、ビューモード254、256、258および260で定義されたグラフィックユーザインタフェースGUIを提供可能なコア関数ライブラリ264およびグラフィック関数ライブラリ266を呼び出すアプリケーションコマンドレイヤー262を有する。UCSからロードされたデータに基づいて、イメージビュー254は、イメージまたは画像に基づくデータを表示し、シートビュー256は、スプレッドシートスタイルグリッドのスプレッドシートデータを表示し、ドキュメントビュー258は、リッチrichかつ直感にテキストのコンテンツを表示し、ファイルビュー260は、デバイス12にUCSファイルをロードかつ保存するためにユーザインタフェースを表示する。リーダ252において層状に設計されているので、コア関数ライブラリ264およびグラフィック関数ライブラリ266のみが、クライアント側の処理システムが置かれる無線/pdaデバイス12の各々において異なる。これにより、本発明がPalmOS、WindowsRCE、J2ME、EPOCおよびBREW等ここで、2大プログラミング言語は、プログラミングの分野における当業者において周知のJavaRおよびCであるの異なるオぺレーティングシステムに素早く移動またはポートされることが可能となる。USCバイナリファイルは、インターネット16を介してサーバ側のデータ処理システム10からデバイス12に送達され、無線クライアントリーダ252は、コア関数ライブラリ264において無線データアクセスロード276用の関数を用いることによってこのデータを取り出す。コア関数ライブラリ264では、順に、無線デバイスPDA/デバイスOS270のリモートHTTP/TCP/IPアクセス276用にライブラリを呼び出す。図12は、無線PDA/デバイス12に常駐するクライアント側の処理アプリケーションの詳細なフローチャート280である。ステップ282において、インボックスInboxアプリケーション等のデバイス12上の別のアプリケーションにより起動されるか、ユーザがリーダ用のアプリケーションアイコンを選択して、そのアプリケーションを呼び出すかのいずれかによって、リーダ252が呼び出される。ステップ284において、渡されたユニバーサルコンテンツストリームUCSは、必要があれば、ローカルまたはリモートであることを検証される。ローカルである場合、UCSは、既にデバイス12に格納されており、ステップ286は、ファイルまたはデータベース288からローカルUCSストリームを読み出す。UCSがステップ287でリモートであるデバイス12に常駐していないと判定される場合、ステップ290は、リモートUCSストリームを読み出すために呼び出される。次いで、ステップ292は、インターネット16を用いてサーバ側のデータ処理システム10に常駐するリモートUCSを得る。ステップ286か290かのいずれかが完了すると、取り出されたデータがパースparseされるステップ294まで実行が続く。次いで、ステップ296は、データをデバイスメモリにロードして、ステップ298は、リモートまたはローカルUCSデータのパーシングが完了するかどうかを調べるためにテストする。ステップ298がローカルデータ用に完了しない場合いいえ、ステップ294は、ステップ298がローカルUCSファイル用に真であるはいまで、繰り返して呼び出される。リモートUCSパーシング用のステップ298が、完了しない場合いいえ、クライアントへの任意のさらなるトランスセラプト用にサーバ10に以前として常駐していると記述された任意のUCSデータのために、ステップ300は、リモートリンクリストを生成する。次いで、ステップ302は、リモートリンクによってUCSメモリを更新して、リモートパーシングステップ298が完了するはいまでステップ294へと続く。UCSデータがパースされ、メモリにロードされた後、ステップ304は、UCSデータのビュータイプまたはビュータイプの組み合わせを決定する。呼び出されたイメージビュー254、ドキュメントビュー258またはシートビューモード256のいずれかのビュータイプに応じて、UCSデータは、ステップ306で表示される、または、レンダリングされる。ステップ306でUCSデータを表示した後、クライアントデータ処理アプリケーションは、ステップ308でユーザの入力を待機する。ユーザがメニューオプション、またはトラック/スクロールホイール、スタイラスstylusまたはキーパッドを用いてロードされたドキュメント内でナビゲートする場合、ステップ308は、ユーザが脱出オプションを選択することによってリーダ252を終了させるまで、繰り返して呼び出され、ステップ310は、モバイルリーダを脱出して、ステップ282の前の呼び出しアプリケーションにリターンする。ユーザがさらなるUCSデータのためにステップ308でより多くのリクエストを選択するまたは呼び出す場合、ステップ290は、ユーザがステップ308でアプリケーションを終了させるまで、上述されたような同じ以下のプロセスフローで再び呼び出され、ステップ310は、モバイルリーダを脱出して、そのステップの前に呼び出しアプリケーションにリターンする。図13は、ドキュメント処理モジュール50のためにロードされた仮定のドキュメントと共にドキュメントエンジン構造を示す図320である。ドキュメントエンジンの構成は、以下のモジュールエンジンモジュール322、ディスティラーモジュール324とロードされたドキュメント326とデコレータモジュール図示せずとのセットとしてカテゴリー化された各コンポーネントの集合である。ディスティラーモジュール324の機能は、主に、異なるドキュメントタイプを取り扱うことである。このモジュールのセットは、特に公知のドキュメントフォーマットをパースし、ドキュメント構造を構築し、所望の場合、ドキュメント構造を公知のドキュメントフォーマットに戻すことに固執する役目を有する。新規のディスティラーモジュール324が動作時間に追加され、または、取り除かれて、柔軟な環境のために必要なものを収容するという意味で、ディスティラーモジュール324のセットは開かれている。エンジンモジュール322の機能は、主に、動作しているディスティラーモジュール324、所望の場合、ロードされたドキュメント326をホストして、これらのために均一の環境を提供することである。クライアントのために共通の挙動を提供する例えば、ドキュメントをローディングすることことも用いられる。複数のドキュメント構造モジュールは、ロードされたドキュメントの構築しているピースである。これらのピースは、ロードされたドキュメントを示し、他の全てのノードを含むドキュメントノード328、ある程度の詳細なドキュメントを有するコンテンツを示すコンテンツノード330、他のノード用のコンテナを示すコンテナノードの対332、334、テキストコンテンツを示すテキストコンポーネント336、イメージコンテンツを示すイメージコンポーネント338、ベクトルコンテンツを示すベクトルコンポーネント340、および、スプレッドシート等のテーブルデータを示すテーブルコンポーネント342を含む。ドキュメント構造326は、ツリー状の構造ノードを共有する可能性を有するので、より適切な記述は、グラフ状であるである。この事実によって、固執したドキュメント構造によって制約されることなく所望の任意の態様でユーザがドキュメントを実用的に構築することを可能にする。各ノードが子供および/親に対する方法の様な集合をインプリメントするという事実によってこのことが達成される。レンダリングの様な挙動は、それ自体ノードに取りつけられ得るか、外部のコンポーネントとして提供され得るかである。このことは、ドキュメント構造の標準的なイタレータiteratorのセットの存在によって容易にされる。意図する動作に必要なこと速度、大きさ、配置等を考慮することによって、内部の挙動と外部の挙動との間で選択が成され得る。デコレータモジュールの機能図13に示されないは、主に、ドキュメント構造に対して選択されてカスタマイズされたドキュメントの動作を実行することである。コンテンツ、ブックマークまたはハイパーリンクのリスト、検索動作等のテーブルを抽出することが例として含まれる。ここでは、トランスセラプション技術が用いられる。これらは、それぞれ独自のフレームワークを有する分離したモジュールであり、これらのモジュールは、他のエンジンコンポーネントと完全に独立して動作する。実際、エンジンは、インストールされているデコレータモジュール無しで動作し得る。これらは、さらなる機能を加える。デコレータモジュールフレームワークは、それ自体でコンポーネントであるデコレータマネージャ、および、特定の動作を実行するインストールされたモジュールのセットで構成される。各モジュールは、フレームワークに統合して、デコレータマネージャによって認識されるために、予め決定された方法で登録する必要がある。デコレータは、ドキュメントオブジェクトモデルDOMをナビゲートする単一の目的のためにソフトウェア開発の分野で当業者によって共通して参照されるコンポーネントであり、特定のコンテンツおよび/またはナビゲート情報を取り出す。言い換えると、デコレータコンポーネントがコマンドを構成することが記述され得る。いかに多くのデコレータがDOMをナビゲートするために用いられ得るかということに対して制限はない。通常のデコレータコマンドは、ドキュメントのブックマークを取り出し、ドキュメントのハイパーリンクを取りだし、ドキュメントのコンテンツテーブルを取り出し、TOCが利用可能ではない場合にドキュメントの要旨を構築し、特定のページを取り出し、ドキュメント内のテキストコンテンツを検索し、特定のフォントスタイルまたは情報を取り出し、ドキュメント内のイメージまたはイラストレーションを取り出す。図14は、ドキュメントエンジン320内の親ノード352および子供ノード354の関係350を示す。親352と子供354との間の実際のリンクは、2つの間のポインタよりも若干複雑である。それらの間において、リンクの属性を保持する役割を果たす、いわゆるスペシフィアーspecifier356オブジェクトが存在する。関連している親または子のオブジェクトIDSに対する情報は、通常リンクの属性によるものである。このことは、グラフ状の構造であり、単一の親が多数の子供を有し得、1つの子供も多数の親オブジェクトを有し得るためである。構造化または非構造化電子ドキュメントの形式か、絵またはイラストレーション等のグラフィックイメージ、および、ベクトル形式かAからBへの線を描く方法に関する記述として周知の形式で示された描画データによって通常表されたテキストおよび非テキストのコンテンツを具現化するデータストリームの形式で入力を提供することが、本発明の動作である。電子ドキュメントは、ビジネスまたは個人的な通信レター、製品情報および製品の説明書、部品のマニュアル、会社または個人の経営情報等が最良として記述されているが、これらに制限されない。図15および16は、それぞれ構造化ドキュメントおよび非構造化ドキュメントを表す。図15は、通常の非構造化ドキュメント360がいかに見え得るかを示す。非構造化によって、ドキュメントが最小のナビゲーション情報および構造化エレメント例えば、ヘッダ、フッタ、テーブルおよびフォントスタイルを有することが意図される。これらを使用することによって、発明のクライアント側のデータ処理システム250に戻って部分的なドキュメントコンテンツを送達し、再構築する目的のために、このようなフォーマットおよびナビゲーション情報を直接抽出することができる。サーバ側10データ処理能力は、従って、非構造化ドキュメントデータを解析することによって、ナビゲーションおよび再構築情報等を構築するために用いられる必要がある。フォントサイズ、フォントタイプ、フォントスタイル、および、フォントポジショニングの変化を検出することによって解析が行われる。これを解析することによって、全てのテキストコンテンツエレメント362は、以下の基準によってヘッダとしてマークされる。用いられる最大のフォントサイズ=14、フォントスタイル=Bold、フォントタイプ=Arial。これは、テキストパラグラフ定義364によって強化される。テキストパラグラフ定義364は、全て、フォントサイズ=10、フォントスタイルは無く、フォントタイプ=Timesである。この情報に基づいてヘッダ362を識別化することによって、本発明は、非構造化ドキュメントに対しては存在しないコンテンツテーブルの形式でナビゲーションのヘルプを構築可能である。組み込まれたイメージ366は、画像挿入ポイント座標x,yおよび全てのピクセルにおける幅および高さ情報を有する。次いで、本発明のシステム10は、イメージ366をクライアント側のアプリケーション処理システム12にレンダリングする場合に、イメージ366へリンクを提供し得、マークされたエレメント368は、テキストパラグラフ364内のフォントスタイルの変化が原因となって、ヘッダとしてもマークされるが、エレメント368がテキストパラグラフ364内に位置すると、他のヘッダ362よりも低い重要度でランク付けされる。エレメント368がナビゲーションの重要さを有していると判断されるので、コンテンツテーブルの形式でナビゲーションエイドaideを形成する場合に、エレメント368は、次いで、サーバ側10のアプリケーション処理によって用いられる。同様に、タイプ370および372のエレメントは、本発明のサーバ側の処理能力によって検出される。なぜなら、これらのエレメントのフォント位置が緊密であり、加えて、フォントスタイルBoldおよびItalic、および、スペーシング用のタブTAB文字を使用しているからである。これら全ては、このセクションがドキュメント360に対して重要であり、テーブルコンテンツを構成する際にこのセクションがナビゲーションエイドポイントとしてマークされ得ることを示している。最終的に、ページエレメント374は、ドキュメントページ1にある全ての非構造化コンテンツに対する公知のナビゲーションインデックス参照と関連するページ番号の記述を定義する。図16は、テーブルコンテンツの形式のドキュメントナビゲーション構造を識別する目的で、および、クライアント側の処理アプリケーション12でコンテンツの抜粋を再構成することを意図してコンテンツの抜粋を定義する目的でサーバ側データ処理システム10によって処理され得る非構造化ドキュメント380を示す。コンテンツテーブルTOC382は、構造化ドキュメントに存在するエレメントとして定義される。ヘッディング1およびヘッディング2として参照されるコンテンツエレメント384および386がパラグラフヘッダ388として定義され、ドキュメント自体によってTOCエンティティ382の構築のときにナビゲーションエレメントとして用いられる。従って、サーバ側のデータ処理アプリケーション10は、非構造化ドキュメントのために必要とされる処理を必要とすることなく、これらのエレメントを直接抽出することができる。さらに、システム10は、構造化ドキュメントをパースして、ブックマーク1へのハイパーリンク390を識別する。ハイパーリンクは、構造化ドキュメント内のオブジェクトまたはエンティティ間のナビゲーションリンクである。この構造化ドキュメントは、それらが接続され、関連していること、および、ハイパーリンクと相互作用することによって、ユーザがドキュメントの異なる部分にナビゲートできることを示す。システム10は、ハイパーリンクエンティティ390の記録を作り、その記録をナビゲーションのために用いる。ブックマークエンティティ392は、構造化ドキュメント380自体内に定義されている別のエレメントである。この構造化ドキュメント自体は、ナビゲーションアンカーanchorポイントを提供し、システム10は、ナビゲーションハイパーリンクエンティティ390の実行を可能にする目的のためにこのナビゲーションアンカーポイントを記録する。ハイパーリンクエンティティ392、394、396は、外部のハイパーリンクであることによってハイパーリンクエンティティ390とは全く異なる。外部ハイパーリンクは、他のコンテンツ、または、外部アプリケーション、または、構造化ドキュメント380自体に定義されるプロセスに対するリンクオブジェクトとして定義される。1つのハイパーリンク392は、ウェブサイトアドレスwww.arizan.com、または、www.air2web.comへの第2のハイパーリンク394へと示すアドレスによってインターネットブラウザを立ち上げ、一方で、リンク396は、salesarizan.comへと設定されたToアドレスによってeメールアプリケーションプログラムを立ち上げる。サーバ側のデータ処理システム10は、構造化ドキュメントを処理する一方で、ナビゲーションまたは可能なアプリケーションを立ち上げる目的で、本発明を用いるソフトウェアアプリケーションのために構築されたドキュメントオブジェクトモデルにこれらのエレメントを記録する。構造化ドキュメント380のイメージエレメント398は、イメージ/ピクチャに対する情報、位置x,yおよび幅、高さ情報を提供する。システム10の発明は、DOMに記録し、従って、視覚的にかつ内容としても正しいコンテキストで無線デバイス12にあるこのエレメントを再構成する能力をクライアントコンポーネント12に与える。構造化ドキュメント380によって定義されたテーブルエレメント400は、テーブル状の態様で表示かつ組織化されたコンテンツを含む。本発明のサーバ側のデータ処理機能は、この情報を読み出し、ドキュメントエンジンテーブルコンポーネントを利用してDOMを構築する際にそれをマッピングする。このドキュメントエンジンテーブルコンポーネントによって、本発明のクライアント側の処理システムは、無線デバイス/pda12にテーブル状の構造でDOMを再構築可能である。構造化ドキュメントのグラフエレメント402は、バーチャート等のグラフタイプフォーマットの情報を含み、MicrosoftCorporationによるMSWordのようなワードプロセッサ等の構造化ドキュメントを読み出すアプリケーションによってチャートを描く際に、テーブルエレメント400に提供されたデータにリンクする。サーバ側のデータ処理能力は、無線デバイス/pda12においてクライアント側のデータ処理システムにグラフを再構築させることを意図して構造化ドキュメントを処理する際に、グラフリンクおよびレンダリング情報を取り出し、記録する。ヘッダエレメント404は、構造化ドキュメントにある各ページに対するページヘッダ情報を定義して、一方で、フッタエレメント406は、構造化ドキュメント380の各一ページに対して再利用されるページフッタ情報を定義する。サーバ側のデータ処理能力は、エレメント404および406を記録し、適切なエンティティをDOMに構築する。ページエンティティ408も、ナビゲーションインデックスを提供し、一方で、構造化ドキュメント380をナビゲートする。なぜなら、各ページエンティティは、最初のページで開始し、最後のページで終わるページ範囲内の各ページをユーザが参照可能とする連続的なエントリであるからである。図16によって表された構造化ドキュメントも、メタデータ410を参照するドキュメントに関する非視覚的な記述情報を埋め込んでいる。本発明のサーバ側のデータ処理能力は、この情報を抽出可能であり、それをDOMに格納可能である。このDOMでは、その情報は、後に、システムに10によって用いられ得、ドキュメント情報構造化ドキュメントに格納されたメタデータによって定義された、ドキュメント名、著者、日付、生成時間等を提供し得る。図17は、本発明のサーバ側のデータ処理システム10によって構築されたドキュメントオブジェクトモデル420を示す。イラストレーション420は、ロードされたドキュメントの一般的な構造422を示す。DOMのエントリポイントは、コンテンツノード424である。複数のコンテナ426の各々は、異なるタイプの多数のコンポーネントを有し得る。本発明のサーバ側のデータ処理アプリケーションは、定義された4つのコンポーネントタイプを有する。それらは、テーブルコンポーネント430、テキストコンポーネント431、イメージコンポーネント432およびベクトルコンポーネント図示せずである。各コンポーネントも、参照コマンドの形式で、同じコンテナ426、または、異なるコンテナの下で他のコンポーネントによって参照され得る。図18は、ドキュメントオブジェクトモデルDOM420を構築した後、および、図16によって示された構造化ドキュメント380をロードした後にサーバ側のデータ処理システム10によって用いられたテキストコンポーネント430を示す。各テキストコンポーネント430は、1つ以上のセクションコマンド440を有し得、任意の標準的な構造化または非構造化ドキュメントとして通常見られるために、複数のパラグラフ442は、1つの単一セクション440に含まれ得る。パラグラフオブジェクト442は、定義された1つの属性444を有する。この1つの属性444は、コンテンツハイパーリンクのテーブルに対する参照である。ハイパーリンクスタートオブジェクト446自体は、その属性オブジェクト448によって定義される。この属性オブジェクト448は、ハイパーリンクIDおよびリンクの送信先を記述する。それから、テキストセグメントオブジェクト450は、テキストオブジェクト450に対するテキストコンテンツ自体を保持する記述属性452を有する。パラグラフオブジェクト442の最後に、ハイパーリンクエンドオブジェクト454は、ハイパーリンクペアIDを含む属性オブジェクト456によって構築される。図19Aは、ロードされた構造化ドキュメント380のドキュメントオブジェクトモデル460、および、サーバ側のデータ処理システムによって用いられたパラグラフに対するDOM構成を示す。パラグラフオブジェクト462は、パラグラフ462の関連するスタイルおよびテキストのコンテンツを記述する属性オブジェクト464を有する。フォントオブジェクト466は、フォントコマンドを含み、関連する属性オブジェクト468は、フォント記述およびフォントスタイル情報を含む。パラグラフオブジェクト462にリンクされた次のコマンドオブジェクトは、ブックマークオブジェクト470、および、その記述属性オブジェクト472である。この記述属性オブジェクト472は、ブックマークIDを含む。次に、パラグラフオブジェクト462は、テキストオブジェクト474にリンクされ、このテキストオブジェクト474は、テキストコンテンツ自体の価値を有する属性オブジェクト476に関連する。図19Bは、従って、図19Aによって開始されたDOMパラグラフ構成460の続きである。パラグラフオブジェクト462にリンクされた次のコマンドオブジェクトは、テキストコマンドオブジェクト478、および、テキスト値を含む関連する属性オブジェクト480である。次は、新規のフォントコマンドオブジェクト482であり、関連する属性オブジェクト484は、フォントタイプおよびスタイルの定義を含む。次いで、パラグラフオブジェクト462にリンクされた以下のオブジェクトは、それぞれ、テキストコマンドオブジェクトおよびフォントコマンドオブジェクト、および、関連する属性486~496であり、パラグラフ構成が参照コマンドオブジェクト498、および、その参照値を含む関連属性オブジェクト500で終わる。図20は、ドキュメントオブジェクトモデルDOMを構築した後、および、図16によって示された構造化ドキュメント380をローディングした後にサーバ側のデータ処理システム10によって用いられたテーブルコンポーネント428を示す。各テーブルコンポーネント428は、多数の列オブジェクト510、512を有し得る。ここで、1つ以上のセルが含まれてもよい。図20は、サンプル構造化ドキュメント380にあるサンプルテーブルの最初の列を示す。テーブル列コマンドオブジェクト510は、セルコマンドオブジェクト514にリンクする。このセルコマンドオブジェクト514は、セルのテキストコンテンツ値を含む関連する属性オブジェクト516を有する。さらなるセルコマンドオブジェクト518、520、522および524は、次いで、これ以上のデータが列として利用可能ではなくなるまで、テーブル列コマンドオブジェクト510にリンクされる。図21A~21Fは、インターネット16を介してデータを無線で送達することに対して効果的かつ最適化された方法でデータを送信して、クライアント側のデータ処理システム12によって処理されるために、本発明で用いられたユニバーサルコンテンツストリームUCSの形式で出力されたコンテンツにおけるサーバ側のデータ処理システム10の記述を示す。図21A~図21Fは、2つのテーブルを有する。各テーブルは、図16および15でそれぞれ表される構造化ドキュメント380および非構造化ドキュメント360を生成するコマンドを示すUCSデータファイルを出力する際のサーバ側の処理能力を示す。図22を参照して、UCSフォーマット530のレイアウトが示される。UCSユニバーサルコンテンツストリームフォーマット530は、サーバ10とクライアント技術またはデバイス12との間のメカニズムおよびデータ送信層を提供する。このフォーマットの主な目的は、利用可能なバンド幅域、最適な方法で送信されている必要とされる視覚的イメージのみを可能とすることである。フォーマット530は、グラフィックイメージ/ピクチャ、2D/3D描画、ならびに、ワードプロセッサおよびスプレッドシートのコンテンツ等の様々なテキストデータの転送を支援する。UCSは、トランスセラプト技術および任意の利用可能なバンド帯を利用するトランスセラプトコマンドおよびデータ転送に加えて、情報送信のために様々な異なる標準フォーマットを含み得る。UCS内に最適な標準フォーマットを埋め込むことは、トランスセラプトサポートを必要としないクライアント技術を容易に統合することへとつながる。イメージ/ラスターデータ等のフォーマットに対して、JPEG2000等の現在の/将来の基準は、サーバ10からクライアント12へのデータロスのない圧縮に対して十分なサポートを提供する。サーバ10と他のクライアントとの両方によってアクセスされ得る業界基準フォーマットの例は、以下の4つのタイプである。テキスト、メタデータおよびコンテンツ情報用のXMLベクトル情報用のSVGイメージ用のJPEG2000OpenGL3D表示他の基準フォーマットまたは専有フォーマットは、コンポーネントベースのサーバ10のプラグ可能plugableおよびスケール可能scalableなアーキテクチャによって容易に追加されるか、取り除かれるかされ得る。UCSフォーマット530は、オプションの業界基準フォーマットと共にUCSフォーマット530を作る3つの異なるデータ層を含む。この3つの専有層は、TCL層、UCSテキストコンテンツ層534、および、UCSイメージまたはベクトルデータ層536である。TCLトランスセラプトコマンド言語層532は、サーバ10とクライアント12との間の双方向通信のためのデータチャネルを提供する。クライアント12は、リクエストをサーバ側のクライアントハンドラに送信し、逆に、トランスセラプトデータストリームで応答を受信する。TCLは、以下のタイプのコマンドを取り扱う。すなわち、視覚的イメージ用のトランスセラプトリクエスト、VQビューおよびクエリコマンド、ディレクトリ情報、刊行されたドキュメントの検索/取り出し、および、任意の必要とされた第3パーティ情報同期である。TCL言語自体は、また、容易に適応するために、および、さらに拡張するために、XMLを利用して構築される。UCSベクトルストリーム536は、高度に最適化されたベクトルフォーマットであり、貧弱なクライアントソフトウェアにベクトル描画能力を提供する。これにより、この貧弱なクライアントソフトウェアは、小さなPDAデバイスまたはハンドヘルドデバイスに対してさえもより高度で精密なベクトル表示を提供することができる。ベクトルストリーム転送およびレンダリングは、TCL層532を通して制御される。このTCL層532は、トランスセラプトハンドラが、クライアント12によって要求されたクリップされたビュー可能な領域に対してベクトル表示を生成し、そのリクエストを生成した制限されたクライアント表示領域のために、そのベクトル表示を最適な方法でレンダリングするのみであることを保証する。UCSフォーマット530は、新規の専有層またはフォーマットが容易に追加され得る様態で設計される。イメージ、ベクトルおよびテキストのトランスセラプションのために用いられたフォーマットのうちのいくつかも、第3パーティによって統合される必要があるならば、取り換えられるか、追加されてもよい。ユニバーサルコンテンツストリームUCS530は、バイナリファイルフォーマット規格である。この規格は、元のドキュメントコンテンツこのドキュメントコンテンツは、テキストコンテンツ、イメージデータ、ベクトルデータおよび処理されたドキュメントのためのナビゲーション情報を含むが、これらに制限されないの送達を可能にする。UCSフォーマットは、利用可能なバンド帯域を考慮すると、無線デバイス12の現在の制限を克服する際に非常に効果的である。今日一般的に、このバンド帯域は、理論的にはさらに高速にすることができるが、9.6から通常48までの範囲である。UCSは、様々な方法で制限された帯域幅の問題を取り扱う。UCSフォーマット530によって、元のドキュメントファイルサイズは、90まで減少可能となるが、クライアント側の処理能力を用いて無線デバイスにあるドキュメントを再構築するための全ての本質的なコンテンツおよび必要なフォーマット情報を保持している。このサイズの減少は、元のドキュメントアプリケーションによって用いられる本質的ではないフォーマット情報例えば、デスクトップコンピュータ上でリッチ表示されたMSWordを取り去ることによって達成される。本質的ではないフォーマット情報は、異なるフォントスタイル、フォントカラー、および、改訂情報等を用いることであり得る。これらは、通常、無線デバイス12上に値を有していない。なぜなら、デバイススクリーンは、モノクロームまたはグレースケールであり得、そのデバイスは、通常、1つのフォントタイプのみであるからである。UCSファイルフォーマットはまた、クライアント側で大きさをさらに減少するために、サーバ側でUCSファイルを圧縮して、解凍することを可能にする。圧縮には、LZW等の圧縮技術形式で共通に利用可能な技術が利用され得る。さらに、伝送用のコンテンツを除いたトランスセラプトを生成する際のサーバ側の処理能力によって、繰り返しのプロセスでサーバからクライアントへの個々の伝送に対して複数のUCSファイルの生成を可能にする。このプロセスでは、無線デバイスに送信された生じたUCSファイルは、ユーザからの特定のコンテンツクエリに対する結果である。サーバからのコンテンツを要求する、無線デバイスでのユーザからの繰り返しクエリプロセスは、例えば、デバイスに送達される各10個のUCSファイルを送達することにつながり得る。UCSファイルフォーマットは、一貫したビューイングまたは読み出しを通して元のドキュメントがメモリにある各ファイルによって再構成され得るように、これらの各UCSファイルがどのように共にリンクするかに関する情報を含む。UCSフォーマットはまた、ドキュメントオブジェクトモデルDOMIdを含み、サーバ10の処理能力が要求しているデバイス12へ正しいDOM情報を送達可能であることを保証する。さらに、UCSファイルフォーマットはまた、クライアントがドキュメント内からより多くのコンテンツを要求することを可能にするインターネットハイパーリンクを含む。コマンドコードはまた、UCSフォーマットに組み込まれ得、サーバ側のデータ処理能力によって特定の処理の実行を容易にし得る。これは、通常、特定のコンテンツに対するリクエスト例えば、DOM等内に格納されたナビゲーション情報のルックアップである。用語の定義1.アナトミゼーション-全てのコンテンツおよびナビゲーションドキュメント階層構造を含む均一のドキュメントオブジェクトモデルを構築する目的で、構造化または非構造化ドキュメント、あるいは、データソースをparsingパーシングするおよび解析する特定の技術プロセス。2.ブックマーク-ドキュメント内にある位置Xから位置へのナビゲーション参照に関連するナビゲーションリンク。3.DOM-ドキュメントオブジェクトモデルDOM、すなわち、ワールドワイドウェブコンソーシアムによって開発されているプログラミングインタフェース規格であり、オブジェクトとしてXMLベースのドキュメントを生成かつ構造化する方法を定義する。4.外部ファイル-関連する外部データ、または、元のドキュメントの外部にあるドキュメントファイルに対する参照。5.外部オブジェクト-元のドキュメントの外部にある関連する外部データオブジェクトに対する参照。6.フォントカラー-フォントの色。7.フォント位置-レンダリングx,yピクセルまたは文字の位置情報。8.フォントサイズ-フォント文字のサイズをポイントで示すフォントの大きさ。9.フォントスタイル-普通、イタリック、ボールド、下線等のフォントのスタイル。10.フォントタイプ-ドキュメントで用いられるフォントタイプの名前例えば、タイムズローマン。11.フッタ-コンテンツを含むドキュメントにあるそれぞれのまたは全てのページの底部にある脚注。12.ヘッダ-コンテンツを含むドキュメントにあるそれぞれのまたは全てのページの上部にあるヘッダ。13.ハイパーリンク-ブックマークまたは外部データ、あるいは、コンテンツソースを参照するドキュメントコンテンツの外部または内部にあるナビゲーションリンク。14.ページ-定型ページまたはプリンタページの中断ページの文字によって通常分離されたコンテンツ情報を含むドキュメントにあるそれぞれのage年代を定義するもの。15.パラグラフ-中断ラインによって分離された結合性のある本体でグループ化されたテキスト線の集合。16.予測キャッシング-無線/有線デバイスへの必要とされた送達/伝送の前にサーバにある該当または関連するコンテンツをキャッシュして、帯域幅およびネットワーク待ち時間を最小化するように設計された特定の技術プロセス。17.コンテンツテーブル-ドキュメントコンテンツのナビゲーションを通知して、支援するためにドキュメントコンテンツに階層構造のナビゲーション構造を提示するもの。18.タイトルスタイル-ヘッディング1、ヘッディング2、ヘッディング3のようにテーブルコンテンツの構成を考慮した上でのドキュメントの中央生成アプリケーションにおける予め定義されたスタイル。19.トランスセラプション-要求されたコンテンツの抜粋のみを送達して、これをクライアントに伝送する特定の技術プロセス。20.USC-最小化されたデータサイズのために最適化されたコンテンツデータフォーマットするユニバーサルコンテンツストリームであって、無線/有線デバイスへの送達のためのコンテンツの文脈、ナビゲーションおよび提示の情報を保存する。21.XML-共通の情報フォーマットを生成する柔軟な方法であり、ワールドワイドウェブ、イントラネットおよびその他にあるフォーマットとデータとの両方を共有する拡張マークアップ言語。"