JP2004510251A - 電子ドキュメントの構成可能な変換方法 - Google Patents

Abstract

デジタルドキュメントのオリジナルバージョンのテキストの一部を変更して、テキストがオリジナルドキュメントのテキストよりも短いデジタルドキュメントの改訂バージョンを作成する段階と、通信チャネル（１４）上で、チャネル（１４）に接続された装置（１０）から、デジタルドキュメントを求める要求を受信する段階と、要求に応答して通信チャネル（１４）上で改訂バージョンを送信する段階とを含む方法。

Description

【０００１】
この特許出願は、共に引用によって本明細書に組み入れられる、２０００年１０月１０日に出願された米国暫定出願第６０／２３８，４２４号と２０００年９月２７日に出願された米国暫定出願第６０／２３５，５５１号の出願日の利益を有する。
【０００２】
背景
本発明は、電子ドキュメントのセグメント化、変換、および表示に関する。
【０００３】
対角方向の大きさが１０インチよりも大きい表示画面を有するデスクトップ・コンピュータまたはラップトップ・コンピュータを用い、通信速度が少なくとも２８．８ｋｂｐｓの、インタネットとの接続を用いて、ウェブ・ページ、テキスト・ファイル、ｅメール、エンタープライズ（企業独自の）データなどの電子ドキュメントにアクセスすることが多い。電子ドキュメントは通常、このような装置に送信され、このような装置上でレンダリングされるように構成されている。
【０００４】
携帯電話、ハンドヘルド装置（ＰＤＡ）、ポケットベル、セットトップ・ボックス、ダッシュボード取付け式マイクロブラウザのようなインタネットによってイネーブルされる装置は、画面サイズが比較的小さく、（たとえば、対角方向で２インチまたは３インチ）、無線ネットワーク上で通信速度が比較的遅く、メモリが小さいことが多い。このような装置には、サイズが一定の限界を超えたドキュメントの一部をレンダリングできない装置や、ドキュメントを規定された長さの後で打ち切る装置がある。このような装置を使用した場合、（多くのテキスト・パラグラフ、複雑な画像を含み、場合によっては豊富なメディア・コンテンツを含むことが多い）電子ドキュメントにアクセスすることは非現実的であるかまたは不可能である。
【０００５】
自動コンテンツ変換システムは、本来大型画面装置に送信され大型画面装置上でレンダリングされるように構成された電子ドキュメントを、携帯電話のようなディスプレイが小さくより機能の劣る装置に送信しこのような装置上でレンダリングするのに適したバージョンに変換する。たとえば、エイイング・マ、イルジャ・ベドナー、グレース・チャン、アラン・クチンスキーおよびホンジャン・ザン（Ｗｅｉ−Ｙｉｎｇ Ｍａ、Ｉｌｊａ Ｂｅｄｎｅｒ、Ｇｒａｃｅ Ｃｈａｎｇ、Ａｌｌａｎ Ｋｕｃｈｉｎｓｋｙ、およびＨｏｎｇｊｉａｎｇ Ｚｈａｎｇ）著「ＳＰＩＥマルチメディア・コンピューティングおよびネットワーキング２０００の均質ネットワーク環境における適応的コンテンツ供給の枠組み（Ａ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ａｄａｐｔｉｖｅ Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ ｉｎ Ｈｅｔｅｒｏｇｅｎｅｏｕｓ Ｎｅｔｗｏｒｋ Ｅｎｖｉｒｏｎｍｅｎｔｓ ｏｆ ＳＰＩＥ Ｍｕｌｔｉｍｅｄｉａ Ｃｏｍｐｕｔｉｎｇ ａｎｄ Ｎｅｔｗｏｒｋｉｎｇ ２０００）」カリフォルニア州サンホセ、２０００年１月を参照されたい。
【０００６】
概要
一般に、本発明は、一局面では、デジタルドキュメントのオリジナルバージョンのテキストの一部を変更して、テキストがオリジナルドキュメントのテキストよりも短いデジタルドキュメントの改訂バージョンを作成する段階と、通信チャネル上で、チャネルに接続された装置から、デジタルドキュメントを求める要求を受信する段階と、要求に応答して通信チャネル上で改訂バージョンを送信する段階とを含む方法を特徴とする。
【０００７】
本発明の実現態様は、以下の特徴のうちの１つまたは複数を含む。変更段階は、たとえば画像圧縮、再サンプリング、カラーから白黒への変換によって、オリジナルドキュメントに含まれる画像のサイズをレンダリングする段階を含む。テキストの一部を変更する段階は、複数の変更段階を選択的にテキストに適用する段階を含む。変更段階の一部としてテキストに適用すべき変換は、装置に関連付けられる好みに基づいて選択される。好みは、装置の固有の識別子に基づいて装置に関連付けされる。好みは、ドキュメントを求める要求が出される前に記憶される。好みは、サーバに関連するデータベースに記憶される。好みは、装置のインタフェースを通じてユーザによって示される。好みは、デジタルドキュメントを求める要求が出される装置以外の装置のインタフェースを通じてユーザによって示される。好みは、サーバから与えられるフォーム上に示される。好みは、サーバが、ドキュメントを求める要求を受信することのできる装置の各種類ごとに記憶される。好みは、サーバが、ドキュメントを求める要求を受信することのできる装置の各種類ごとに記憶される。好みは、クッキー・メカニズムを用いて装置上に記憶される。変更段階は、装置の種類に依存する。装置の種類を識別する情報が装置から受信される。変更段階は、プロキシ・サーバまたはオリジン・サーバで実行される。この装置は、ドキュメント全体を一度を表示するようには構成されていない装置を含む。この装置は、パーソナル・デジタル・アシスタンス、ハンドヘルド装置、または携帯装置を含む。変更段階は、日付圧縮、語省略、またはオリジナルドキュメントに含まれる画像の画像縮小を含む。デジタルドキュメントはウェブ・ページを含む。この方法は、デジタルドキュメントをサブドキュメントにセグメント化する段階と、要求に応答して一部のセグメントを送信する段階とを含む。
【０００８】
一般に、本発明は、他の態様では、全ウェブ・ページを表示するようには構成されていないクライアント装置によって要求された全ウェブ・ページに対して実行すべき好ましい変更、すなわち、ドキュメントをクライアント装置上で表示するのにより適したドキュメントにする好ましい変更に関してそれぞれの異なるクライアント装置に関連付けされた好みを定義するデータベースを維持する段階を含むことを特徴とする。
【０００９】
一般に、本発明は、他の態様では、全ドキュメントを表示するように構成されていないクライアント装置によって要求された全ドキュメントに対して実行すべき好ましい変更に関する好みについての情報をクライアント装置から得る段階と、データベースにおいて好みをクライアント装置に関連付ける段階とを含む方法を特徴とする。一般に、本発明は、他の態様では、全ウェブ・ページを表示するようには構成されていない種類のクライアント装置に与えるべきウェブ・ページのコンテンツを作成する段階と、全ウェブ・ページをクライアント装置上で表示するのに適したページにするように全ウェブ・ページに対して行うべき変換に関する情報を記憶する段階とを含む方法を特徴とする。記憶された情報は、これらの種類の装置の各々をこの種類の装置によって要求された全ウェブ・ページに施すべき変換に関連付ける情報である。
【００１０】
他の利点および特徴は、以下の説明および特許請求の範囲から明らかになろう。
【００１１】
本発明の様々な実現態様では、電子ドキュメントは、小型のディスプレイおよび／または小型のメモリを有するユーザ装置上に表示できるように低帯域幅通信チャネルを通じて与えられる前に、セグメント化され変換される。まずセグメント化機能について論じ、次いで変換機能について論じる。
【００１２】
セグメント化
図１に示されている高レベルでは、インタネット対応装置１０（たとえば、ＷＡＰ対応携帯電話（ＷＡＰ−ｅｎａｂｌｅｄ ｍｏｂｉｌｅ ｐｈｏｎｅ））のユーザが電子ドキュメント１２（たとえば、ウェブ・ページや、ｅメールや、テキスト・ファイルや、独自のフォーマットまたはマークアップ言語のドキュメント）を要求すると、ＵＲＬで表されたユーザの要求は最終的にプロキシ・サーバ１４に送信される。プロキシ・サーバは次いで、ＵＲＬを用いてオリジン・サーバ１６由来のドキュメントを要求する。オリジン・サーバとは、ドキュメントに責任を負うインタネット上のコンピュータである。プロキシ・サーバは、オリジン・サーバからウェブ・ページの形でドキュメントを受信した後、ドキュメントをサブドキュメントに分解（セグメント化）する。プロキシ・サーバは、これらのサブドキュメント１のうちの最初のドキュメントをクライアントにウェブ・ページとして送信する。ドキュメントのセグメント化は、プロキシ・サーバで行う必要はなく、後述のように、ネットワーク内の他の場所で行うことができる。
【００１３】
図２に示されているように、プロキシ・サーバによってクライアントに供給される各サブドキュメント２０は、一連のサブドキュメント内の（必要に応じて）次のサブドキュメントおよび前のサブドキュメントへのハイパーリンク２２、２４を含んでいる。ユーザがサブドキュメントからのフォワード・ポインティング（またはバックワード・ポインティング）ハイパーリンクを選択した場合、この要求はプロキシ・サーバに送信され、プロキシ・サーバは、次の（または前の）サブドキュメントで応答する。
【００１４】
図３に示されているように、セグメント化プロセスの第１の段階では、クライアント装置の最大許容ドキュメント・サイズが求められる（３０）。クライアント・サーバ通信がＲＦＣ２６１６（Ｒ． Ｆｉｅｌｄｉｎｇら、ＲＦＣ２６１６： Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ−ＨＴＴＰ／１．１、１９９９年６月、＊＊ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／Ｐｒｏｔｏｃｏｌｓ／ｒｆｃ２６１６／ｒｆｃ２６１６．ｔｘｔ＊＊．）に記載されたＨＴＴＰプロトコル標準に従う通信である場合、クライアントはそれ自体に関する情報を、ＨＴＴＰ要求で送信されるヘッダ情報内でプロキシ・サーバに宣伝する。サーバは、たとえばＵＳＥＲ−ＡＧＥＮＴフィールドの値を用いて、クライアント装置上にインストールされたマイクロブラウザの種類を判定し、この情報から、すべての既知の装置の最大ドキュメント・サイズをリストしたテーブルを参照することによって最大ドキュメント・サイズを決定する。
【００１５】
オリジナルドキュメントの長さをＮで示す。長さは（マークアップを含む）バイト単位のドキュメントのサイズによって測定することができる。クライアントによるドキュメントの最大許容長をＭと示す。クライアントによって課されるＭの最大長を重視する任意のセグメント化アルゴリズムでは、長さＮのドキュメントから少なくともセイル（ｃｅｉｌ）（Ｎ／Ｍ）のセグメントを生成しなければならない。
【００１６】
セグメント化プロセスの次の段階では、入力されたドキュメントがＸＭＬ、すなわち、タグがドキュメント上の階層木構造を示すマークアップ言語に変換される（３２）。このような木構造の例を図４に示す。ＨＴＭＬを含む多数の異なるソース・フォーマットからＸＭＬへの変換は、既存のソフトウェア・パッケージを用いて行うことができる。図４に示されているように、第３の段階では、ＸＭＬ木４０を、各々の長さがＭ以下であるセグメントに分割する（３４）手順が適用される。木の葉４２はオリジナルドキュメントの要素、すなわちテキスト・ブロック、画像などを表す。木の内部の節４４は、構造情報およびマークアップ情報を表し、マーカはパラグラフ、テーブル、ハイパーリンクされたテキスト、太字テキストの領域などを示す。セグメント化タスクを達成する１つの方法は、アグロメラティブ下降形葉クラスタ化アルゴリズムを使用することである。葉クラスタ化手法ではまず、（図４に示されているように）各葉がそれ自体のセグメントに配置され、次いで併合すべき隣接するセグメント対がなくなるまで各セグメントが反復的に併合される。図５は、２回の併合が行われ、併合されたセグメント５０、５２が残った後の同じ木を示している。
【００１７】
各併合演算において、セグメントの数が１つ少ない新しい修正された木が生成される。各段階ですべての隣接するセグメント対が検討され、併合候補に関して定義されているスコアリング関数に従って最適な対が併合される。スコアリング関数の例について以下に説明する。アルゴリズムが終了したときに、最終的なセグメントはオリジナルＸＭＬ木の各パーティションを表す。
【００１８】
スコアリング関数
スコアリング関数の一例では、より低いスコアがより望ましい併合を表す。（この場合、併合の「スコア」を併合を行うコストとみなすことができる。）この例では、セグメントｘとセグメントｙを併合するスコアは以下の量に関係している。
【００１９】
１．セグメントのサイズ：スコアリング関数ではより大きなセグメントよりもより小さなセグメントの併合が好ましい。｜ｘ｜がセグメントｘ中のバイトの数を示すものとする。他のすべてが等しいとすると、｜ｘ｜＝１００、｜ｙ｜＝１５０、および｜ｚ｜＝２５である場合、適切なスコアリング関数ではスコア（ｘ，ｚ）＜スコア（ｙ，ｚ）＜スコア（ｘ，ｙ）となる。実際には、この基準の効果は、結果として得られるパーティションのサイズのバランスがとられることである。
【００２０】
２．各セグメントの親近性：他のすべてが等しいとすると、セグメントｘおよびｙは、共通の親を有する場合、親の親（またはそれ以上離れた祖先）節を通じてのみ関係付けされている場合よりも望ましい併合を構成する。この２つのセグメントが離れた祖先を通じてのみ関係付けされていることは、これらのセグメント化が互いに同じ種類であることの証拠としては、より近い祖先を通じて関係付けされている場合よりも弱い。
【００２１】
３．併合によって必要とされる節の複製：内部節は、セグメントを適切に形成されたドキュメントに変換する際に複製しなければならないことがある。もちろん、オリジナルドキュメントをサブドキュメントに区分する際、結果として得られるサブドキュメントの冗長性を最小限に抑えることが望ましい。
【００２２】
木においてセグメントｘからセグメントｙまで移動しなければならない節の最小数をｄ（ｘ，ｙ）によって定義し、セグメントｘとセグメントｙを併合することによって必要とされる節複製の量をｒ（ｘ，ｙ）によって定義する。その場合、一般的なスコアリング関数候補は次式のようになる。
スコア（ｘ，ｙ）＝Ａ（｜ｘ｜＋｜ｙ｜）＋Ｂ（ｄｘ，ｙ）＋Ｃ（ｒｘ，ｙ）
上式で、ＡおよびＢおよびＣはユーザによって設定できる関数（たとえば、実数係数）である。
【００２３】
たとえば、以下のようになる。
アルゴリズム１：ＸＭＬドキュメントのアグロメラティブ・セグメント化
入力：　Ｄ：ＸＭＬドキュメント
Ｍ：最大許容ドキュメント長
出力：Ｄ^１：各々のサイズがＭ以下であるセイル（Ｎ／Ｍ）以上の葉を有するＸＭＬドキュメント
１．Ｄ中の各葉をそれ自体のセグメントに割り当てる。
２．Ｄ中のセグメントｘ_１、ｘ_２のすべての隣接する対にスコア（ｘ_１，ｘ_２）でスコア付けする。
３．ｘ，ｙを、スコア（ｘ，ｙ）が最小限であるセグメント対とする。
４．ｘとｙを併合するとサイズ＞Ｍのセグメントが作成される場合は終了する。
５．セグメントｘとセグメントｙを併合する。
６．段階１に進む。
【００２４】
セグメント併合候補にスコア付けするのに他の方法を用いることができる。
【００２５】
上述のアルゴリズムでは、セグメント化の方法を決定する際にドキュメントの実際の字句コンテンツを考慮していない。他の例では、各セグメントに含まれる語の種類を考慮し、ブレークによって情報の流れが乱されることがないような位置を優先する基準が使用される。これを達成するために、システムは、併合を考慮しながら２つのセグメントに含まれる語を調べ、それらの語が同じ話題に関する語であるかどうかを判定しなければならない。このような「テキスト・セグメント化」問題は、たとえば、Ｍ．Ｈｅａｒｓｔ著「テキスト・タイリング：テキストのマルチパラグラフ・サブトピック・パッセージへのセグメント化（ＴｅｘｔＴｉｌｉｎｇ： Ｓｅｇｍｅｎｔｉｎｇ ｔｅｘｔ ｉｎｔｏ ｍｕｌｔｉ−ｐａｒａｇｒａｐｈ ｓｕｂｔｏｐｉｃ ｐａｓｓａｇｅｓ）」に記載されたような自動コンピュータ・プログラムによって対処される。テキスト・タイリングは、テキスト・ソース内にディバイダを配置するのに最適な位置を求めるように構成されたアルゴリズムである。
【００２６】
図３に戻ると、次の段階では、最終的な木の各セグメントが個々の適切に形成されたＸＭＬドキュメントに変換される（３６）。これを行うには節を複製する必要がある。たとえば、図５では、葉Ｂと葉Ｆの併合には、シブリングＦとＧを分離する効果がある。このことは、木の右側の第１のセグメントおよび第２のセグメントを適切に形成されたセグメントに変換する際に、各ドキュメントが節Ｃのインスタンスを含まなければならないことを意味する。言い換えれば、節は、１組の結果として得られるサブドキュメントにおいて複写される。複写の欠点は、節ＦおよびＧが共通の親によって関係付けされているのではなく、共通の親の親によって関係付けされている場合にはより深刻であった。というのは、親節と親の親節との両方を両方のセグメントにおいて複製する必要があるからである。
【００２７】
プロキシ・サーバは、ソース・ドキュメントのセグメント化を計算した後、個々のサブドキュメントをキャッシュまたはデータベースに記憶し（３８）、ユーザとの将来の対話を容易にする。ユーザが第１のサブドキュメント上のハイパーリンクに従って配列中の次のサブドキュメントにアクセスすると、要求はプロキシ・サーバに転送され、プロキシ・サーバは、現在そのキャッシュに記憶されている適切なサブドキュメントで応答する（３９）。
【００２８】
プロキシ・サーバに多数の異なるクライアントからの要求を処理する責任がある場合、プロキシ・サーバは、各クライアントの状態を維持し（４１）、クライアントがどのドキュメントにアクセスしているかと、そのドキュメントを構成しているサブドキュメントとを追跡する。前述のように、プロキシ・サーバは、ＨＴＴＰヘッダ情報を用いて、この場合はクライアント装置の固有の識別情報（たとえば、ＩＰアドレスや、携帯電話の電話番号）を判定し、この符号を、状態を各ユーザに関連付けるプロキシ・サーバの内部データベースにおけるキーとして使用することができる。このようなデータベースの抜粋例を以下に示す。

【００２９】
多くのクライアント装置は、ＸＭＬで書かれたドキュメントを処理することができず、テキスト、ＨＴＭＬ、ＨＤＭＬのような他のマークアップ言語で書かれたドキュメントしか処理できない。ＸＭＬサブドキュメントの他のフォーマットへの変換（４３）は、プロキシ・サーバにおいて任意の利用可能なトランスレータによって行うことができる。
【００３０】
アグロメラティブ・セグメント化アルゴリズム（上記のアルゴリズム１）は、ユーザが最初にドキュメントを要求するときに、ソース・ドキュメント当たりに一度のみ実行される。ユーザが、ソース・ドキュメントを構成する各サブドキュメントにアクセスする際に、プロキシ・サーバの計算負荷は最小限に抑えられ、必要なのは、適切なすでに記憶されているサブドキュメントを供給することだけである。
【００３１】
ドキュメントがサブドキュメントにセグメント化されると、単にそれらのサブドキュメントのオリジナルドキュメントにおける順序で供給すること以外の様々な方法でサブドキュメントを使用することが可能になる。
【００３２】
たとえば、図１７に示されているように、オリジナルＨＴＭＬドキュメント１００はフォーム１０２を含んでよい。ユーザのページとの対話を実際的なものにするには、フォームをページの残りの部分から分離し、１つのサブドキュメント内のリンクで置き換えると有用である。次いで、ユーザは自分のローカル装置上でこのリンクを呼び出し、フォームをユーザに供給させることができる。ユーザがこのフォームを見ずかつ使用しないことを望む場合、このフォームを得ることなしに、引き続き前述のように他のサブドキュメントにアクセスする。
【００３３】
このために、ドキュメントを、ドキュメントの本体の一部を表すサブドキュメント１０４、１０６、および１０８と、フォーム１０２の一部を表すサブドキュメント１１０、１１２とにセグメント化することができる。１つのサブドキュメント１０６は、フォームとのリンク１１６を表すアイコン１１４を含んでいる。他のリンク１１８、１２０、および１２２によって、前述のように各サブドキュメントにアクセスすることができる。
【００３４】
変換
ユーザに供給されるサブドキュメントのコンテンツは、データによって表される情報を使用不能にすることなしに送信し表示しなければならないデータの量を少なくするように自動的に変換することができる。ユーザは、変換の所望の結果に関するユーザの好みを表すことによって電子ドキュメントのこの自動変換をカスタマイズすることができる。ユーザの好みは、後で、要求されたドキュメントの自動的なカズタマイズされた変換において使用できるように記憶される。
【００３５】
たとえば、ユーザは、サイズが制限されたディスプレイ上にドキュメントを表示する際にオリジナルドキュメント内の各語を短縮することを望む場合がある。語を短縮すると混乱が生じると考え、短縮を使用しないときに得られるより長いドキュメントを受け入れることを望むユーザもいる。これらの好みを表し記憶して、後で行われる実際のドキュメントの変換を制御するのに用いることができる。
【００３６】
まず、ドキュメントを変換する各段階について論じ、次にユーザに好みを示させるプロセスについて論じる。
【００３７】
ドキュメントの変換
図１および６に示されているように、装置１０のユーザ６が（たとえば、装置上で実行されているブラウザにＵＲＬを入力したり、すでにブラウザに記憶されているブックマークを選択したり、すでにブラウザにロードされているハイパーテキスト・ドキュメントからリンクを選択したりすることによって）ドキュメント１２を要求する（１１）と、プロキシ・サーバはこの要求を受信し（１８）、オリジン・サーバからドキュメントを取り出す（２０）。
【００３８】
プロキシ・コンピュータは、オリジン・サーバからドキュメントを受信した後、クライアントの好みのデータベース２６を参照して（２４）、要求を行っているユーザの装置８に関する変換プロセスに適切なパラメータを判定する。プロキシ・コンピュータは次いで、ドキュメントに変換を施し（２８）、ドキュメントをクライアント装置に送信し（３０）クライアント装置上でレンダリングする（３２）ことができるように調整する。
【００３９】
クライアント装置がそれ自体に関する情報をプロキシ・サーバに宣伝するＨＴＴＰヘッダは、以下の関連する２つの情報を含んでよい。
【００４０】
１．装置の固有の識別子：たとえば、Ｐｈｏｎｅ．ｃｏｍによって配信されるマイクロブラウザを備える無線インタネット装置の場合、ＨＴＴＰヘッダ可変Ｘ−ＵＰ−ＳＵＢＮＯは装置の固有の識別子に結合される。
【００４１】
２．装置の種類：たとえば、ＨＴＴＰヘッダ可変ＵＳＥＲ−ＡＧＥＮＴは、装置上にインストールされたブラウザ・ソフトウェアの種類を記述したストリングに結合される。
【００４２】
ドキュメントの変換が行われるとき、プロキシ・コンピュータはすでに固有ＩＤを得ており、これを、データベースにおいて、ユーザに関連する１組の好みを参照するためのキーとして用いることができる。
【００４３】
図７は、仮想データベース２４内の行の例を示している。各行４０では、装置がその電話番号によって識別される。行は、ユーザの好み（図７の場合は４つの異なる好み）を、識別された装置に関連付ける。この場合、（たとえば、携帯電話の）電話番号は、データベース内のレコード用のキーとして働く固有のＩＤである。
【００４４】
プロキシ・コンピュータは、データベースを参照してこのユーザに適切な好み値を判定した後、これらの値を用いてプロキシ・コンピュータの変換プロセスを導くことができる。したがって、図１および４に示されているように、変換プロセスへの入力は（たとえば、ＨＴＭＬの）ソース・ドキュメントおよび１組のユーザ好み値（図６におけるデータベース内の１行）である。図８に示されているように、ドキュメント変換は、オリジナルドキュメントを小型ディスプレイ装置上でレンダリングするのにより適した形式に変換する際の、日付圧縮５２、語省略５４、画像縮小５５などの一連の動作を含む。あらゆる段階で、ターゲット装置に関する好みは、変換動作を構成するのに用いられる。たとえば、クライアント特有の好みは、語省略を抑制することか、または指定されたサイズを超えた画像にのみ画像縮小５５を適用することを示すことができる。
【００４５】
画像は、縮小するだけでなく、そのサイズを小さくする他の種類の変換を受けることもできる。たとえば、画像を圧縮することも、ダウンサンプリングすることも、カラーから白黒に変換することもできる。
【００４６】
ユーザ構成可能パラメータの例には以下のものが含まれる。
【００４７】
省略
ドキュメントを表示するのに必要な空間を減らすために、語を省略することができる。長い語を打ち切ったり、共通の接尾辞を省略したり（「ｎａｔｉｏｎａｌ」が「ｎａｔ’ｌ」になる）、母音を削除したり、サウンデックス（Ｓｏｕｎｄｅｘ）アルゴリズム（Ｍａｒｇａｒｅｔ Ｋ． ＯｄｅｌｌおよびＲｏｂｅｒｔ Ｃ． Ｒｕｓｓｅｌｌ、米国特許第１，２６１，１６７号（１９１８年）および第１，４３５，６６３号（１９２２年））のようないくらかより高度な手順を使用することなど、多数の語圧縮方法がある。対応するユーザ構成可能パラメータは、ユーザが省略をイネーブルすることを望んでいるか、それともディスエーブルすることを望んでいるかを示すブール値である。省略をイネーブルすると、結果として得られるドキュメントの長さが短くなるが、ドキュメントの意味が曖昧になることがある。
【００４８】
画像の縮小
多くの小型画面携帯装置は、ビットマップされた画像をレンダリングすることはできない。可能である場合でも、大きな画像をレンダリングするには長い送信時間が表示である。ビットマップされた画像を低解像度画面上でレンダリングすると画質が低下する可能性が高い。このため、ユーザは、ビットマップ画像をユーザの装置上でレンダリングするかどうかと、どの種類のビットマップ画像をレンダリングするかを調節することができる。この場合の対応するユーザ構成可能パラメータはたとえば、ブール値（レンダリングするかしないか）またはソース画像の画素単位の最大許容サイズである。
【００４９】
エンティティ圧縮
変換システムは、自然言語パーサを用いてある種のストリングを検出してより短い形式に書き直すことができる。たとえば、パーサは日付を検出し、たとえば、「１９８４年１２月１２日」が「１２／１２／８４」になり、「２月４日」が「２／４」になり、「８月の７日」が「８／７」になるようにより短い形式に書き直すことができる。
【００５０】
対応するユーザ選択可能パラメータ値は、ブール値（圧縮するかしないか）であってよく、あるいは圧縮しない、月／日／年フォーマットに圧縮する、日／月／年フォーマットに圧縮するの３つの値のうちの１つをとることができる。
【００５１】
同様に、変換システムは、（たとえば）「ｓｅｖｅｎｔｅｅｎ」が「１７」になり、「１０ギガバイト」が「１０ＧＢ」になるように数量を解析し圧縮することができる。様々な種類のドキュメントについて他の様々な変換を構成することができる。
【００５２】
装置ごとの好みの指定および記憶
次に、装置ユーザの好みを得てこれらの好みを特定のクライアント装置に関連付ける方法の２つの例について論じる。
【００５３】
小型ディスプレイ装置からの好みの入力
ユーザは、インタネット・アクセスに使用する小型ディスプレイ装置と同じディスプレイ装置を用いてプロキシ・コンピュータにアクセスすることによって好みを入力し維持することができる。図９に示されているように、プロキシ・コンピュータは小型ディスプレイ装置のユーザがその好みに従って検索し記入することができるハイパーテキスト・フォーム６０を記憶することができる。プロキシ・コンピュータは、クライアント装置からＨＴＴＰ要求６２を受信すると、クライアント装置固有の識別子を（ＨＴＴＰプロトコルを用いて）自動的に得る。次いで、プロキシ・コンピュータは、１組の好みを含むフォーム６４をユーザに送信する。クライアント装置がすでにデータベース内に関連するエントリを有している場合、各パラメータの現在の値をフォーム内に表示することができる。それ以外の場合、デフォルト値が表示される。ユーザは、このフォーム上のパラメータを適当に変更し、次いでフォーム６６をプロキシ・コンピュータに送り返すことができ、プロキシ・コンピュータは更新済みの値をデータベース内の、クライアント装置に関連するレコードに記憶する。
【００５４】
従来のコンピュータからの好みの入力
あるいは、ユーザはデスクトップ・コンピュータまたはラップトップ・コンピュータ上で従来のウェブ・ブラウザを用いて同じＵＲＬにアクセスすることができる。プロキシ・コンピュータは、好みを関連付けるのはどの装置かをＨＴＴＰヘッダ情報から自動的に判定することはできない。ユーザは、ユーザが好みを設定したい装置の固有の識別子、たとえば電話番号を明示的に指定しなければならない。
【００５５】
図１０は、従来のＨＴＭＬベースのデスクトップ・ウェブ・ブラウザ上に表示されるフォームの一例を示している。図１１は、４行携帯電話ディスプレイ上に表示される対応するページの第１の画面を示している（ユーザが残りのオプションを見るにはスクロール・ダウンしなければならない）。
【００５６】
種類ごとの好みの指定および記憶
前の節では、ユーザは、リモートに記憶されているドキュメントに小型画面装置を用いてアクセスする人であり、（変換を実行する）プロキシ・コンピュータはユーザの装置とインタネット全体とを仲介する。
【００５７】
構成可能な変換が有用な他の設定では、個人または機関が、それが生成したドキュメントの小型ディスプレイ装置上での表示を制御することができる。このために、データを記憶し送信する責任を負うオリジン・サーバは（ウェブ・サーバ・ソフトウェア用のモジュールまたは「プラグイン」を用いて）自動コンテンツ変換ソフトウェアを備えることができる。その場合、オリジン・サーバ・ホストは変換ソフトウェアを必要に応じて構成し制御することができる。
【００５８】
オリジン・サーバは、特定の種類のクライアント装置に関するドキュメントをこのサーバから検索する任意のユーザのために変換を１度構成する能力を、コンテンツの著者に与えることもできる。言い換えれば、変換をカスタマイズする能力をエンド・ユーザに与えるのではなく、コンテンツを作成した人または機関にこの能力を与えることができる。この方法は、コンテンツ・プロバイダが、小型ディスプレイ装置上でのコンテンツ・プロバイダのコンテンツの表示を厳しく管理することを望んでいるときには適切である。
【００５９】
オリジン・サーバは、ユーザ（個々の装置）の好みのデータベースを記憶するのではなく、装置の各種類ごとの変換に関する１組のパラメータ値のみを記憶する。
【００６０】
したがって、ユーザからオリジン・サーバへの情報の流れは以下のとおりである。
１．ユーザはオリジン・サーバにドキュメントを要求する。
２．オリジン・サーバは、要求と、要求を行っているクライアント装置の種類に関する情報とを受信する。
３．オリジン・サーバは、要求されたドキュメントを処理する際にこの装置に適切な変換パラメータを参照する。
４．オリジン・サーバは、変換されたドキュメントをクライアント装置に供給する。
【００６１】
段階３に使用されるデータベース内のエントリの一例を以下に示す。

【００６２】
前節では、エンド・ユーザが、単一の装置に関連付けるべき好みを指定し記憶する方法について説明した。この節では、コンテンツ作成者がそのオリジン・サーバから供給されたドキュメントの変換を構成する方法について説明した。これらの２つの方法は互換性を有する。エンド・ユーザがオリジン・サーバＹにドキュメントＸを要求するものと仮定する。さらに、エンド・ユーザが自分の変換に対する１組の好みを登録しており、このオリジン・サーバから供給されるドキュメントに対する別個の１組の好みがオリジン・サーバ上に存在するものと仮定する。ドキュメントは、まずオリジン・サーバ内の好みに従って変換され、次いでエンド・ユーザの好みに従って変換される。この方法では、場合によってはエンド・ユーザの好みを考慮することはできない。たとえば、エンド・ユーザは語省略を望んでいないが、オリジン・サーバの好みにおいて語を省略することが指定されている場合、エンド・ユーザは自分の好みにかかわらず、省略された語を含むドキュメントを受信する。
【００６３】
クライアント装置上への好みの記憶
好みを装置に関連付ける他の方法では、ＨＴＴＰ「クッキー」状態メカニズム（Ｄ．ＫｒｉｓｔｏｌおよびＬ．Ｍｏｎｔｕｌｌｉ． ＲＦＣ２１０９：ＨＴＴＰ状態管理機構（ＲＦＣ２１０９：ＨＴＴＰ Ｓｔａｔｅ Ｍａｎａｇｅｍｅｎｔ Ｍｅｃｈａｎｉｓｍ）（１９９７年）＊＊ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／Ｐｒｏｔｏｃｏｌｓ／ｒｆｃ２１０９／ｒｆｃ２１０９．ｔｘｔ＊＊）が使用される。この場合、好み情報は、クライアント装置に対してリモートなデータベース上には記憶されず、装置自体上に記憶される。この設定での装置当たり好み情報の流れは以下のとおりである。
【００６４】
１．小型ディスプレイ装置のユーザが好みフォーム・ドキュメントを求める要求をプロキシ・コンピュータに送信する。フォーム・ドキュメントがプロキシ・コンピュータから装置に送信される。
【００６５】
２．ユーザが自分の好みを記入し、記入したフォームをプロキシ・コンピュータに送り返す。
【００６６】
３．プロキシ・コンピュータが、確認ドキュメントで応答し、また、クライアント装置へのＨＴＴＰヘッダ情報において、ユーザの好みを含むクッキーを送信する。たとえば、クッキーは以下のようになる。
Ｓｅｔ−Ｃｏｏｋｉｅ：ＰＲＥＦＳ＝”ａｂｂｒｅｖｓ：ｙｅｓ ｉｍａｇｅｓ：ｎｏ ｄａｔｅｓ：ｙｅｓ．．．”；ｐａｔｈ＝／；ｅｘｐｉｒｅｓ＝０４−Ｓｅｐ−０１２３：１２：４０ ＧＭＴ
【００６７】
４．クライアント装置がこのクッキーを持続状態として記憶する。
【００６８】
５．クライアント装置のユーザが引き続きプロキシ・コンピュータにドキュメントを要求する際、装置も、記憶された好みを含む以下のようなクッキーをプロキシ・コンピュータに送信する。
Ｃｏｏｋｉｅ：ＰＲＥＦＳ＝”ａｂｂｒｅｖｓ：ｙｅｓ ｉｍａｇｅｓ：ｎｏ ｄａｔｅｓ：ｙｅｓ．．．”；
【００６９】
６．プロキシ・コンピュータは、このクライアントの好みを備えており、要求されたドキュメントを変換する際にこれらの好みを適用する。クッキーが満了したかまたは消去されたためにクライアント装置がクッキーを送信しなかった場合、プロキシ・コンピュータはデフォルト変換を適用する。
【００７０】
アプリケーション
図１２に示されているように、無線装置５０と「有線」インタネット５３との通信は通常、有線と無線を仲介するゲートウェイ５２を通じて行われる。たとえば、ＷＡＰ可能装置のユーザによるドキュメントを求める要求は無線ゲートウェイに送信され、無線ゲートウェイは、要求されたドキュメントに（ＤＮＳプロトコルに従って）責任を負う（インタネット上の）オリジン・サーバ５４に要求を転送する。要求されたドキュメントが特にこのクライアント装置向けに構成されており、装置によって受け入れられるマークアップ言語で書かれており、すなわち、場合によってはＨＴＭＬ、より多くの場合にはＷＭＬや、ＨＤＭＬや、独自の言語のような他のマークアップ言語で書かれている場合、コンテンツ変換は不要である。様々な無線データ装置はそれぞれの異なる機能を有するので、コンテンツ作成者は、各ターゲット・マークアップ言語だけでなくあらゆる可能なターゲット装置について別個のバージョンを作成する必要がある。コンテンツ・プロバイダはまた、クライアント装置の種類を検出し、そのクライアント向けに最適にフォーマットされたドキュメントを作成するにはどうすべきかを理解する必要がある。図１３に示されているように、自動コンテンツ変換システム７０は、ドキュメント７２の圧縮、および特定のターゲット装置上で表示するのに最適なフォーマットへの再構築を自動的に行うことができる。このため、コンテンツ作成者は、様々なターゲット装置特有のコンテンツの判定ではなくコンテンツの作成に集中することができる。
【００７１】
コンテンツ変換システムは、古いクライアント装置以外からの要求を捕捉し、要求されたドキュメントをターゲット装置７８上で表示できるようにカスタマイズし、変換されたドキュメント７４をクライアントに送信する。コンテンツ変換システムは、ユーザの好み７６および装置仕様６４を用いてドキュメント変換プロセスを導く。要求されたページ７２が特に、要求を行ったクライアント装置向けに構成されている場合、コンテンツ変換は不要である。しかし、ドキュメントを無線装置向けに構成するのは簡単なことではない。ドキュメントは、装置によって受け入れられるマークアップ言語で書かなければならず、すなわち、場合によってはＨＴＭＬ、より多くの場合にはＷＭＬや、ＨＤＭＬや、独自の言語のような他のマークアップ言語で書かなければならない。数百の異なる無線データ装置はそれぞれ異なる機能６４を有するので、コンテンツ作成者は各ターゲット・マークアップ言語だけでなくあらゆる可能なターゲット装置について別個のバージョンを作成することが予想される。コンテンツ・プロバイダはまた、クライアント装置の種類を検出し、そのクライアント向けに最適にフォーマットされたドキュメントを作成するにはどうすべきかを理解する必要がある。
【００７２】
ドキュメント７２を特定のターゲット装置上で最適に表示するための圧縮およびフォーマット変換を自動的に行うシステム７０を用いることによって、コンテンツ作成者は、様々なターゲット装置特有のコンテンツの判定ではなく、コンテンツ作成者の本来の任務、すなわち、コンテンツの作成に集中することができる。コンテンツ変換システムは、インストールされると、古いクライアント装置以外からの要求を捕捉し、要求されたドキュメントをターゲット装置上で表示できるようにカスタマイズし、変換されたドキュメントをクライアントに送信する。コンテンツ変換システムは、大きなドキュメント全体を処理することのできない装置への大きなドキュメントの供給を、自動ドキュメント・セグメント化を用いて計画することができる。
【００７３】
コア・コンテンツ変換構成要素８１は前述のセグメント化プロセスを含んでよい。ＸＭＬキャッシュ・オブジェクト８４には、セグメント化プロセスに関するユーザごとのサブドキュメントが記憶される。
【００７４】
コンテンツ変換は、サーバ側の技術であり、当然のごとく、クライアント−オリジン・サーバ・チャネル内の様々な位置、すなわち、無線ゲートウェイから、オリジナルコンテンツを保持するオリジン・サーバまでのあらゆる位置で行うことができる。以下の表に、コンテンツ変換を適用できる場所のいくつかを示す。

【００７５】
図１４は、５つのサブドキュメントに分割された入力ドキュメント例（フルサイズのウェブ・ページ）を示している。図１５は、オリジナルページの「Ｂｒｏｎｘ−Ｗｈｉｔｅｓｔｏｎｅ Ｂｒｉｄｇｅ」の部分の中央に対応する第４のサブドキュメント７２の底部を示している。「ｐｒｅｖ（前）」７４および「ｎｅｘｔ（次）」７６として示されているハイパーリンク（アイコン）は、呼び出されると、ユーザに対してそれぞれ第３のサブドキュメントおよび第５のサブドキュメントを表示する。図１６は、第４のサブドキュメントが終了した部分から開始する第５のサブドキュメントの開始部分を示している。ユーザは必要に応じてサブドキュメントをスクロールすることができる。図のいくつかの実現態様では、アイコン７４、７６が表示されるのは、ユーザがサブドキュメントの開始部分または終了部分までスクロールしたときだけである。他の例では、アイコンを常に表示することができる。
【００７６】
図１５および１６では、オリジナル中の数および語が省略されており（「ｏｎｅ」が「１」に、「ａｎｄ」が「＆」になっている）、曜日が短縮されている。
【００７７】
各サブドキュメントの表示は、オリジナルドキュメントの見出し７９の表示も含んでいる。この見出しは、オリジナルドキュメントからサブドキュメントが作成されるときにサブドキュメントに含められる。この表示は、サブドキュメント８７の総数と、オリジナルドキュメントを構成する一連のサブドキュメント中の現在のサブドキュメントの位置８９との表示も含んでいる。
【００７８】
他の実現態様も特許請求範囲の範囲内である。
【００７９】
たとえば、ユーザ・インタフェースにおいて、ターゲット装置上でレンダリングされた各サブドキュメントの底部には、サブドキュメントが、オリジナルドキュメントを構成する１組のサブドキュメントのどこに位置するかを示すグラフィカル・ステータス・バーを含んでよい。たとえば、ｏｏｘｏｏｏｏは、「これは７つのサブドキュメントのうちの３番目のサブドキュメントである」を意味することができる。さらに、ステ−タス・バー中の各ｏをそのサブドキュメントにハイパーリンクすることができ、ユーザはドキュメント中のそれぞれの異なるサブドキュメントにランダムにアクセスすることができる。これはサブドキュメントごとに順序正しく進むよりも効率的である。
【図面の簡単な説明】
【図１】ドキュメント変換・提供システムを示す図である。
【図２】ドキュメントを示す図である。
【図３】流れ図である。
【図４および図５】ドキュメント階層を示す図である。
【図６】ドキュメント変換プロセスを示す図である。
【図７】データベースを示す図である。
【図８】ドキュメント変換システムを示す図である。
【図９】好みを表すプロセスを示す図である。
【図１０】好みフォームを示す図である。
【図１１および図１２】好みフォームを示す図である。
【図１３】無線／有線通信システムを示す図である。
【図１４】ウェブ・ページを示す図である。
【図１５および図１６】ウェブ・ページの一部の小形画面表示を示す図である。
【図１７】サブドキュメントを別々に使用できるように分離する段階を示す図である。

Claims (29)

1. 装置に関連付けられる好みに基づいて変更が実施される、デジタルドキュメントのオリジナルバージョンのテキストの部分を変更して、テキストがオリジナルドキュメントのテキストよりも短いデジタルドキュメントの改訂バージョンを作成する、段階；
   通信チャネル上で、装置から、デジタルドキュメントの要求を受信する段階；および、
   要求に応答して通信チャネル上で改訂バージョンを送信する段階
   を含む方法。
2. テキストの部分を変更する段階が、複数の変換を選択的にテキストに適用する段階を含む、請求項１記載の方法。
3. 変更段階の一部としてテキストに適用すべき変換を、装置に関連付けられる好みに基づいて選択する段階をさらに含む、請求項１記載の方法。
4. 好みが、装置の固有の識別子に基づいて装置に関連付けされる、請求項３記載の方法。
5. 好みが、ドキュメントの要求の前に記憶される、請求項３記載の方法。
6. 好みが、サーバに関連するデータベース内に記憶される、請求項３記載の方法。
7. 好みが、装置のインタフェースを通じてユーザによって示される、請求項３記載の方法。
8. 好みが、デジタルドキュメントの要求が出される装置以外の装置のインタフェースを通じてユーザによって示される、請求項３記載の方法。
9. 好みが、サーバから与えられるフォーム上に示される、請求項３記載の方法。
10. 好みが、サーバが、ドキュメントの要求を受信することのできる各装置ごとに記憶される、請求項３記載の方法。
11. 好みが、サーバが、ドキュメントの要求を受信することのできる装置の各種類ごとに記憶される、請求項３記載の方法。
12. 好みが装置上に記憶される、請求項３記載の方法。
13. 好みが、クッキー・メカニズムを用いて装置上に記憶される、請求項３記載の方法。
14. 変更段階が、装置の種類に依存する、請求項１記載の方法。
15. 装置の種類を識別する情報を装置から受信する段階も含む、請求項１４記載の方法。
16. 変更段階が、プロキシ・サーバにおいて実行される、請求項１記載の方法。
17. 変更段階が、オリジン・サーバにおいて実行される、請求項１記載の方法。
18. 装置が、ドキュメント全体を一度に表示するようには構成されていない装置を含む、請求項１記載の方法。
19. 装置が、パーソナル・デジタル・アシスタンス、ハンドヘルド装置、または電話を含む、請求項１８記載の方法。
20. 変更段階が日付圧縮を含む、請求項１記載の方法。
21. 変更段階が語省略を含む、請求項１記載の方法。
22. 変更段階が、オリジナルドキュメントに含まれる画像のサイズを縮小する段階を含む、請求項１記載の方法。
23. 縮小段階が、画像圧縮、再サンプリング、またはカラーから白黒への変換を含む、請求項２２記載の方法。
24. デジタルドキュメントがウェブ・ページを含む、請求項１記載の方法。
25. デジタルドキュメントをサブドキュメントにセグメント化する段階、および要求に応答して、全てではないセグメントを送信する段階も含む、請求項１記載の方法。
26. 変更によりクライアント装置上で表示するのにより適したドキュメントが作成される、全ウェブ・ページを表示するようには構成されていないクライアント装置によって要求された全ウェブ・ページに対して実行すべき好ましい変更に関して異なるクライアント装置に関連付けされた好みを定義するデータベースを維持する段階
    を含む方法。
27. 全ドキュメントを表示するように構成されていないクライアント装置によって要求された全ドキュメントに対して実行すべき好ましい変更に関する好みについての情報をクライアント装置から得る段階；および
    データベースにおいて好みをクライアント装置に関連付ける段階
    を含む方法。
28. 全ウェブ・ページを表示するようには構成されていない種類のクライアント装置に与えるべきウェブ・ページのコンテンツを作成する段階；および
    各種装置を該種類の装置によって要求された全ウェブ・ページに施すべき変換に関連付ける、全ウェブ・ページをクライアント装置上で表示するのに適したページにするように全ウェブ・ページに対して行うべき変換に関する情報を記憶する段階
    を含む方法。
29. デジタルドキュメントがｅメールを含む、請求項１記載の方法。

Images