JP2004510253A

JP2004510253A - 能力が限られたデバイス上で用いるための電子文書の区分処理

Info

Publication number: JP2004510253A
Application number: JP2002531030A
Authority: JP
Inventors: ロメロ，リチャード・ディー; バーガー，アダム・エル
Original assignee: エイゼル・テクノロジーズ・インコーポレーテッド
Priority date: 2000-09-27
Filing date: 2001-09-27
Publication date: 2004-04-02
Also published as: CA2423611A1; KR100855997B1; WO2002027520A9; CA2423695A1; WO2002027516A9; KR20030060899A; CA2423611C; AU2001294884A1; AU2001294881A1; JP2004510251A; EP1320806A1; KR20080067022A; EP1320806A4; KR20030045086A; WO2002027520A1; KR100903528B1; EP1330723A4; WO2002027516A1; EP1330723A1

Abstract

クライアント・デバイス（１０）上での表示のために、クライアント（１０）に提供される文書（１２）を含む機械読み取り可能ファイルを受信し、ファイルにおける文書（１２）の各々の編成は、情報の階層として表現されており、情報の階層からサブ文書（１）を導出することを含む方法。サブ文書（１）の各々は、ハイパーテキスト送信プロトコルを用いてそれをクライアントに別個に提供可能とするフォーマットで表現されており、サブ文書（１）の少なくとも１つは、それをサブ文書（１）の別の１つにリンクすることを可能にする情報を含む。

Description

【０００１】
この特許出願は、２０００年１０月１０日に出願された米国仮特許出願第６０／２３８，４２４号、および２０００年９月２７日に出願された第６０／２３５，５５１号の出願日の利益を有する。その内容は、この言及により本願にも含まれるものとする。
（背景）
本発明は、電子文書の区分処理、変形、および視認に関する。
【０００２】
人がウェブ・ページ、テキスト・ファイル、電子メール、および企業（私有会社）のデータにアクセスする際、多くの場合用いるデスクトップ・コンピュータは、そのディスプレイ画面が対角線方向で１０インチよりも大きく、少なくとも２８．８ｋｂｐｓの通信レートを有するインターネットへの接続を用いる。通例では、電子文書はこのようなデバイスに送信し、その上でレンダリングするように設計されている。
【０００３】
移動電話、手持ちデバイス（ＰＤＡ）、ページャ、セット・トップ・ボックス、およびダッシュボードに取り付けたマイクロブラウザのような、インターネットが可能なデバイスは、多くの場合、画面サイズが小さめで（例えば、対角線方向で２または３インチ程度）、ワイヤレス・ネットワーク上での通信レートが比較的低く、メモリも少ない。これらのデバイスの一部は、文書のサイズが一定の限度を超えると、そのいずれの部分もレンダリングすることができなくなり、一方別のデバイスでは、規定の長さの後文書を切り捨ててしまう場合もある。電子文書（多くの場合、テキストの多くの節、複雑な画像、およびリッチ・メディア・コンテンツ（ｒｉｃｈｍｅｄｉａｃｏｎｔｅｎｔ）をも含む）にアクセスすることは、これらのデバイスを用いた場合、扱い難かったり、あるいは不可能なこともあり得る。
【０００４】
自動コンテンツ変換システムは、元々は大型画面のデバイスに送信しその上でレンダリングするように設計された電子文書を、移動電話のような、ディスプレイが小さく能力が劣るデバイスに送信しその上でレンダリングするように変換する。例えば、Ｗｅｉ−ＹｉｎｇＭａ，ＩｌｊａＢｅｄｎｅｒ，ＧｒａｃｅＣｈａｎｇ，ＡｌｌａｎＫｕｃｈｉｎｓｋｙおよびＨｏｎｇＪｉａｎｇＺｈａｎｇのＡＦｒａｍｅｗｏｒｋｆｏｒＡｄａｐｔｉｖｅＣｏｎｔｅｎｔＤｅｌｉｖｅｒｙｉｎＨｅｒｅｔｏｇｅｎｅｏｕｓＮｅｔｗｏｒｋＥｎｖｉｒｏｎｍｅｎｔｓ（異質ネットワーク環境における適応的コンテンツ配信のための枠組み）ｏｆＳＰＩＥＭｕｌｔｉｍｅｄｉａＣｏｍｐｕｔｉｎｇａｎｄＮｅｔｗｏｒｋｉｎｇ２０００．ＳａｎＪｏｓｅ，ＣＡ，２０００年１月を参照のこと。
（摘要）
一般に、一形態では、本発明は、クライアントに提供しクライアント・デバイス上に表示するための文書を含む機械読み取り可能ファイルを受信するステップであって、ファイル内の文書の各々の編成が情報の階層で表現されている、ステップと、情報の階層からサブ文書を導出するステップであって、サブ文書の各々を、ハイパーテキスト送信プロトコルを用いてクライアントに別個に提供することを可能にするフォーマットで表現し、サブ文書の少なくとも１つが、当該サブ文書をサブ文書の別の１つにリンクすることを可能にする情報を含む、ステップとを含む方法を特徴とする。
【０００５】
本発明の実現例は、１つ以上の以下の特徴を含むことができる。前述の言語は拡張可能マークアップ言語（ＸＭＬ）である。前述の導出するステップは、階層を調べ、セグメントからサブ文書を組み立てることから成り、サブ文書の少なくとも一部が、各々、１つよりも多いセグメントから組み立てられる。この組み立ては、サブ文書のそれぞれのサイズのバランスを取るように作用するアルゴリズム、または階層において共通の親を有するセグメントから、サブ文書の各々を組み立てることを優先するように作用するアルゴリズム、または階層におけるノードの複製を必要としないセグメントから、サブ文書の各々を組み立てることを優先するように作用するアルゴリズムに従う。前述のファイルは、当該ファイルに関連する原始サーバから受信する。前述のファイルは、文書のセグメントを階層状に編成しない言語で表現され、サブ文書を導出するステップは、最初に、文書のセグメントを階層状に編成する言語にファイルを変換することを含む。クライアントによる要求に応じて、サブ文書を個別にクライアントに提供する。ハイパーテキスト送信プロトコルを用いてサブ文書をクライアントに提供する。クライアントは、サブ文書の別のものにリンクすることを当該クライアントに可能にする情報の内容に基づいて、サブ文書を要求する。
【０００６】
文書の一部を識別し、文書の残りからは分離して表示する。この一部が現れるはずのサブ文書をクライアント・デバイスに提供する場合、グラフィカル・デバイスを埋め込み、これをユーザが起動すると、別個に表示すべき文書の一部を含むサブ文書を検索することができる。
【０００７】
一般に、別の形態では、本発明は、クライアントに提供するために記憶媒体上に保持された機械読み取り可能文書であって、この文書が１組のサブ文書として編成されており、サブ文書の各々が、当該サブ文書をサブ文書の別のものにリンクすることを可能にする情報を含み、サブ文書の各々が、文書の階層的表現の一部である、文書のセグメントの集合体であり、サブ文書がほぼ同じサイズである、機械読み取り可能文書を特徴とする。本発明の実現例は、１つ以上の以下の特徴を含むことができる。サブ文書をリンクすることを可能にする情報は、ＵＲＬを含む。階層的表現は、拡張可能マークアップ言語（ＸＭＬ）を含む。
【０００８】
一般に、別の形態では、本発明は、クライアントから、クライアント・デバイス上に表示する文書の要求を受信するステップと、要求文書の全て未満を表すサブ文書を別個にクライアントに提供するステップであって、各サブ文書がそれを少なくとも１つの別のサブ文書にリンクする情報を含む、ステップと、クライアントから、他のサブ文書へのリンクの呼び出しを受信するステップと、クライアント・デバイスに別のサブ文書を別個に提供するステップとを特徴とする。
【０００９】
本発明の実現例は、１つ以上の以下の特徴を含むことができる。ハイパーテキスト送信プロトコルを用いてサブ文書をクライアントに提供する。サブ文書は、本質的に同じ長さである。サブ文書は、クライアント・デバイス上において、更に切り捨てることなく、表示可能な長さを有する。
【００１０】
一般に、別の形態では、本発明は、クライアント・デバイスにおいて、クライアント・デバイス上に表示するために、大きな文書のサブ文書をサーバから受信するステップと、サブ文書をクライアント・デバイス上に表示するステップと、クライアント・デバイスにおいて、大きな文書の別のサブ文書を表示させるユーザの要求を受信するステップと、サーバから、別のサブ文書をクライアント・デバイスにおいて別個に受信するステップと、別の文書をクライアント・デバイス上に表示するステップとを含み、サブ文書が実質的に同じ長さである方法を特徴とする。
【００１１】
本発明の実現例は、１つ以上の以下の特徴を含むことができる。各サブ文書の全てをクライアント・デバイス上で一度に表示するか、あるいは各サブ文書の全て未満をクライアント・デバイス上で一度に表示する。一般に、別の形態では、本発明は、クライアント・デバイス上で文書のサブ文書を表示するステップと、サブ文書と共にアイコンを表示するステップと、アイコンの起動に応答して、サーバから文書の別のサブ文書を取り込み、該別のサブ文書をクライアント・デバイス上に表示するステップとを含み、サブ文書の各々が文書全体未満であり、サブ文書がほぼ同じサイズである方法を特徴とする。
【００１２】
本発明の実現例は、１つ以上の以下の特徴を含むことができる。文書を構成する一連のサブ文書において、現在表示されているサブ文書の位置の指標を与える。この指標は、一連におけるサブ文書の総数と、一連における現在表示中の文書の位置とを含む。クライアント・デバイスからの文書の要求時において、文書からサブ文書を導出する。クライアント・デバイスの特性に基づいた方法で、サブ文書を導出する。クライアント・デバイスの特性は、クライアントが要求と共に提供する。この特性は、クライアント・デバイスの表示能力、およびクライアント・デバイスのメモリ制約を含む。クライアントがサーバからの文書を要求する前に、文書からサブ文書を導出する。異なる原始サーバからの異なる文書について、サブ文書を導出する。ワイヤレス通信ゲートウェイにおいて文書からサブ文書を導出する。
【００１３】
一般に、別の形態では、本発明は、クライアント・デバイス上での表示のためにクライアントに提供する文書を含む機械読み取り可能ファイルを受信し、ファイルからサブ文書を導出するように構成されたネットワーク・サーバを備え、サブ文書の各々が、ハイパーテキスト送信プロトコルを用いてクライアントに別個に供給可能にするフォーマットで表現されており、サブ文書の少なくとも１つは、それをサブ文書の別の１つにリンクすることを可能にする情報を含む、装置を特徴とする。
【００１４】
一般に、別の形態では、本発明は、クライアント・デバイス上での表示のためにクライアントに提供する文書を含む機械読み取り可能ファイルを受信する手段と、ファイルからサブ文書を導出する手段であって、サブ文書の各々が、ハイパーテキスト送信プロトコルを用いてクライアントに別個に供給可能にするフォーマットで表現されており、サブ文書の少なくとも１つは、それをサブ文書の別の１つにリンクすることを可能にする情報を含む、手段とを備えている装置を特徴とする。
【００１５】
一般に、別の形態では、本発明は、機械読み取り可能媒体上に格納され、クライアント・デバイス上での表示のためにクライアントに提供する文書を含む機械読み取り可能ファイルを受信し、ファイルからサブ文書を導出し、サブ文書の各々が、ハイパーテキスト送信プロトコルを用いてクライアントに別個に供給可能にするフォーマットで表現されており、サブ文書の少なくとも１つが、当該１つをサブ文書の別の１つにリンクすることを可能にする情報を含むように機械を構成可能な機械読み取り可能プログラムを特徴とする。
【００１６】
その他の利点および特徴は、以下の説明および特許請求の範囲から明らかとなろう。
（説明）
本発明の種々の実現例では、電子文書を区分し変換した後に、低帯域幅通信チャネルを通じて提供し、小型ディスプレイおよび／または小容量メモリを有するユーザ・デバイス上で視認する。最初に区分機構について論じ、次いで変換機構について論ずる。
（区分化）
図１に示すように、高いレベルにおいて、インターネットが可能なデバイス１０（例えば、ＷＡＰが可能な移動電話）のユーザが電子文書１２（例えば、ウェブ・ページ、電子メール、テキスト・ファイル、あるいは固有フォーマットまたはマークアップ言語の文書）を要求すると、ＵＲＬで表現されたユーザの要求が最終的にプロキシ・サーバ１４に至る。すると、プロキシ・サーバはそのＵＲＬを用いて原始サーバ（ｏｒｉｇｉｎｓｅｒｖｅｒ）１６から文書を要求する。原始サーバとは、文書を担当するインターネット上のコンピュータである。ウェブ・ページの形態で原始サーバから文書を受信した後、プロキシ・サーバは文書をサブ文書に分解（区分化）する。プロキシ・サーバは、これらサブ文書１の最初のものをウェブ・ページとしてクライアントに送信する。文書の区分化は、プロキシ・サーバ内で行う必要はなく、ネットワーク内の別の場所で行うこともできる。これについては、以下で説明する。
【００１７】
図２に示すように、プロキシ・サーバからクライアントに配信されたサブ文書２０の各々は、一連の中の次および前のサブ文書（各々、適用可能な場合）へのハイパーリンク２２、２４を含む。ハイパーリンクは、ユーザに表示される。ユーザがあるサブ文書から前方指示（または後方指示）ハイパーリンクを選択すると、この要求はプロキシ・サーバに送信され、プロキシ・サーバはこれに応答して、次の（または前の）サブ文書を送る。
【００１８】
図３に示すように、区分プロセスの最初のステップは、クライアント・デバイスに許される最大文書サイズを決定する（３０）ことである。クライアント−サーバ通信が、ＲＦＣ２６１６（Ｒ．Ｆｉｅｌｄｉｎｇｅｔａｌ．，ＲＦＣ２６１６：ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ − ＨＴＴＰ／１．１，１９９９年６月。＊＊ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／Ｐｒｏｔｏｃｏｌｓ／ｒｆｃ２６１６／ｒｆｃ２６１６．ｔｘｔ＊＊）に記載されているＨＴＴＰプロトコル規格に準拠する場合、クライアントは、ＨＴＴＰ要求の中で送られるヘッダ情報内で、それ自体に関する情報をプロキシ・サーバに知らせる。サーバは、例えば、ＵＳＥＲ−ＡＧＥＮＴフィールドの値を用いて、クライアント・デバイス上にインストールされているマイクロブラウザの種類を判定することができ、この情報から、公知のあらゆるデバイスの最大文書サイズを纏めた表を参照することによって、最大文書サイズを判定することができる。
【００１９】
元の文書の長さをＮで示すことにする。長さは、文書のサイズ（マークアップを含む）によって、バイト単位で計測することができる。クライアントが許す文書の最大許容長をＭで示すことにする。クライアントが指定する最大長Ｍを基準とする区分アルゴリズムは、いずれも、長さＮの文書から少なくとも最大個数（Ｎ／Ｍ）への区分を行わなければならない。
【００２０】
区分プロセスの次のステップは、入力文書をＸＭＬに変換する（３２）ことである。ＸＭＬとはマークアップ言語であり、そのタグが文書上の階層ツリー構造を暗示する。このようなツリー構造の一例を図４に示す。ＨＴＭＬを含む多くの異なるソース・フォーマットからＸＭＬへの変換は、既存のソフトウエア・パッケージを用いることによって行うことができる。
【００２１】
図４に示すように、第３ステップは、ＸＭＬツリー４０をセグメントに分割する（３４）手順を適用することである。各セグメントの長さはＭ以下である。ツリーのリーフ（ｌｅａｆ）４２は、元の文書−テキスト・ブロック、画像などのエレメントを表す。ツリーの内部ノード４４は、構造およびマークアップ情報−説を示すマーカ、テーブル、ハイパーリンク・テキスト、太字テキストの領域などを表す。区分タスクを遂行する１つの方策は、塊状ボトム−アップ・リーフ−クラスタリング・アルゴリズムを用いることである。リーフ・クラスタリング手法は、開始すると、それ自体のセグメント（図４に示す）内に各リーフを置き、次いで融合すべき隣接するセグメント対が存在しなくなるまで、繰り返しセグメントを融合する。図５は、２回の融合を行った後の同じツリーを示し、融合したセグメント５０、５２が残っている。
【００２２】
融合動作を行う毎に、セグメント数が減って、新たに修正されたツリーが得られる。各ステップは、全ての隣接するセグメント対を考慮し、候補融合に対して規定したスコア関数に応じて最適である対を融合する。スコア関数の一例について以下で説明する。このアルゴリズムが終了すると、最終的なセグメントは、元のＸＭＬツリーの区分を表す。
（スコア関数）
スコア関数の一例では、スコアが低い程、一層望ましい融合を表す。（この文脈では、融合の「スコア」を融合を行うコストと考えることができる。）この例では、セグメントｘおよびｙを融合するスコアを、次の量に関係付ける。
１．セグメントのサイズ：スコア関数は、大きなセグメントよりも、小さいセグメントを融合することを当然優先する。｜ｘ｜がセグメントｘ内のバイト数を示すとする。全てが等しいとすると、｜ｘ｜＝１００、｜ｙ｜＝１５０、および｜ｚ｜＝２５の場合、優れたスコア関数ではスコア（ｘ，ｙ）＜スコア（ｙ，ｚ）＜スコア（ｘ，ｙ）となる。この判断基準の効果は、実際には、得られるセグメントのサイズのバランスを取ることである。
２．セグメントの系統的近接度：全てが等しいとすると、セグメントｘおよびｙが共通の親ｚを有する場合、これらは、祖父（または更に遠い祖先）ノードのみを通じて関係する場合よりも、望ましい融合を構成する。離れた祖先のみを通じた２つのセグメントの関係は、これらのセグメントを一緒にすることの論拠としては、近い祖先を通じた関係よりも説得力が乏しい。
３．融合が必要とするノードの複製：セグメントを、明確に形成した文書に変換する場合、内部ノードを複製しなければならない場合がある。勿論、元の文書のサブ文書に区分化する際、得られるサブ文書における冗長性を極力少なくする。
【００２３】
ｄ（ｘ，ｙ）は、セグメントｘからセグメントｙまでツリーを移動する場合に通過しなければならない最少数のノードを示し、ｒ（ｘ，ｙ）は、セグメントｘおよびｙを融合することによって必要となるノード複製の数を示す。すると、一般的な候補スコア関数は、
【００２４】
【数１】

となり、ここで、Ａ，ＢおよびＣは、ユーザが設定可能な関数（例えば、実係数）である。
【００２５】
例えば、

１．Ｄにおける各リーフにそれ自体のセグメントを割り当てる。
【００２６】
２．スコア（ｘ_１，ｘ_２）によって、Ｄにおけるあらゆる隣接セグメント対ｘ_１，ｘ_２のスコアを付ける。
【００２７】
３．ｘ、ｙを、スコア（ｘ，ｙ）が最少となるセグメント対とする。
【００２８】
４．ｘおよびｙを融合してサイズがＭよりも大きいセグメントが生じた場合、終了する。
【００２９】
５．セグメントｘおよびｙを融合する。
【００３０】
６．ステップ１に進む。
【００３１】
候補セグメント融合にスコアを付けるには、別の方策も使用可能である。
【００３２】
ここに記載したアルゴリズムは、いかに区分化するか決定する際に、文書の実際の語彙内容（ｌｅｘｉｃａｌｃｏｎｔｅｎｔ）を考慮していない。他の例では、各セグメント内に含まれる単語のアイデンティティを考慮し、分断（ｂｒｅａｋ）が情報を流れを壊さないと思われる場所を優先する。これを遂行するには、システムは、融合を考慮している２つのセグメントに含まれる単語を検査し、これらが同じトピックに関連するか否か判定を行わなければならない。このような「テキスト区分化」問題は、例えば、Ｍ．Ｈｅａｒｓｔ，ＴｅｘｔＴｉｌｉｎｇ：Ｓｅｇｍｅｎｔｉｎｇｔｅｘｔｉｎｔｏｍｕｌｔｉ−ｐａｒａｇｒａｐｈｓｕｂｔｏｐｉｃｐａｓｓａｇｅ（テキストの多節副論題句への区分化）ＣｏｍｐｕｔａｔｉｏｎａｌＬｉｎｇｕｉｓｔｉｃｓ２３（１）３３−６５，１９９７に記載されているような、自動コンピュータ・プログラムによって対処する。ＴｅｘｔＴｉｌｉｎｇは、テキスト・ソース内にデバイダを置く最適な場所を求めるように設計されたアルゴリズムである。
【００３３】
図３を参照すると、次のステップは、最終ツリーのセグメントを、個々の明確に形成されたＸＭＬ文書に変換する（３６）ことである。これを行うには、ノードの複製が必要となる場合がある。例えば、図５では、リーフＢおよびＦを融合すると、子孫ＦおよびＧを分離する効果がある。これが意味するのは、右側のツリーの第１および第２セグメントを明確に形成された文書に変換する場合、各文書はノードＣのインスタンスを含まなければならないということである。言い換えると、ノードＣは、１組のその結果として生じるサブ文書において複製される。ノードＦおよびＧが共通の親によってではなく、共通の祖父によって関係付けられている場合、複製の欠点は一層重大となる。何故なら、その場合、親ノードおよび祖父ノードの双方を双方のセグメントにおいて複製しなければならないからである。
【００３４】
ソース文書に対して区分化を計算した後、プロキシ・サーバは個々のサブ文書をキャッシュまたはデータベースに格納し（３８）、ユーザとの今後の相互作用を促進する。ユーザが第１サブ文書上のハイパーリンクにしたがって、シーケンス内の次のサブ文書にアクセスした場合、この要求はプロキシ・サーバに転送され、プロキシ・サーバはこれに応答して（３９）、現在そのキャッシュに格納されている適切なサブ文書を送る。プロキシ・サーバが、多くの異なるクライアントからの要求を処理する役割を担っている場合、プロキシ・サーバはクライアント毎に状態を維持し（４１）、クライアントが考察している文書はどれか追跡し、そして当該文書を構成するサブ文書を追跡する。以前と同様、プロキシ・サーバは、ＨＴＴＰヘッダ情報を用い、このときは、クライアント・デバイスの一意の識別（例えば、ＩＰアドレス、または移動電話の場合には電話番号）を判定し、このコードをその内部データベースにおけるキーとして用いる。データベースは、状態を各ユーザと関連付ける。このようなデータベースからのサンプル抜粋は以下のようになる。
【００３５】
【表１】

【００３６】
多くのクライアント・デバイスは、ＸＭＬで書かれた分書を処理することができず、テキスト、ＨＴＭＬ、ＷＭＬまたはＨＤＭＬのような別のマークアップ言語で書かれた文書を処理できるに過ぎない。ＸＭＬサブ文書の別のフォーマットへの変換（４３）は、プロキシ・サーバにおいて入手可能ないずれかの変換器によって行うことができる。
【００３７】
塊状区分アルゴリズム（前述のアルゴリズム１）は、ユーザが最初に文書を要求したときに、ソース文書毎に１回だけ実行される。ユーザがソース文書を構成するサブ文書を考察するので、プロキシ・サーバに対する計算上の負担は最少で済み、必要なことは、適切な既に格納されているサブ文書を配信することだけである。
【００３８】
一旦文書のサブ文書への区分化が行われれば、元の文書にでてきた順にサブ文書を単純に提供する以外にも、種々の方法でこれを用いることが可能となる。
【００３９】
例えば、図１７に示すように、元のＨＴＬＭ文書１００は、フォーム１０２を含むことができる。ユーザのページとの双方向処理を感知可能とするために、このフォームをページの残りから分離し、サブ文書の１つにあるリンクとこれを置き換えると有用な場合がある。すると、ユーザは、彼のローカル・デバイス上でリンクを呼び出し、フォームを彼に提示することができる。彼がこのフォームを見たり用いることを好まない場合、このフォームを得ることすらせずに、先に論じたように、その他のサブ文書を閲覧（ｎａｖｉｇａｔｅ）するように進むことができる。この目的のために、文書をサブ文書１０４、１０６、および１０８に区分することができ、これらは文書本体の一部、およびフォーム１０２の部分を表すサブ文書１１０、１１２を表す。サブ文書１０６の１つは、フォームへのリンク１１６を表すアイコン１１４を含む。他のリンク１１８、１２０、および１２２は、先に説明したように、サブ文書間での閲覧を可能にする。
（変換）
ユーザ・デバイスに提供されたサブ文書のコンテンツは、データが表す情報を使用不能にすることなく、通信し表示しなければならないデータ量を減少させるように、自動的に変換することができる。ユーザは、電子文書のこの自動変換をカスタム化することができ、その際、変換の所望の結果に関する彼らの基本設定を表現する。彼らの基本設定は格納され、後に要求文書の自動カスタム化変換において用いられる。
【００４０】
例えば、あるユーザが、大きさが制限されているディスプレイ上で文書を視認する場合に、元の文書中の単語を省略させたい場合がある。他のユーザは、単語の省略が紛らわしく、省略を用いない場合に得られる長い文書を受け入れたい場合もある。これらの基本設定を表現し格納し、次いで実際の文書変換において後に制御するために用いることができる。
【００４１】
最初に文書を変換するステップについて論じ、次いでユーザの基本設定を要求するプロセスについて論ずる。
（文書変換）
図１および図６に示したように、そして先に説明したように、デバイス１０のユーザ６が文書１２を要求すると（１１）（例えば、ＵＲＬをデバイス上で実行中のブラウザに入力し、ブラウザに既に格納されているブックマークから選択するか、またはブラウザ内に既にロードされているハイパーテキスト文書からリンクを選択することによって）、プロキシ・サーバは要求を受信し（１８）、原始サーバから文書を取り込む（２０）。原始サーバから文書を受信した後、プロキシ・サーバはクライアントの基本設定のデータベース２６を参照し（２４）、要求を出したユーザに対して、デバイス８のための変換プロセスに適したパラメータを決定する。次に、プロキシ・コンピュータは、文書に変換を適用し（２８）、クライアント・デバイスへの送信（３０）、およびその上でのレンダリング（３２）のためにそれを修正する（ｔａｉｌｏｒ）。
【００４２】
クライアント・デバイスは、ＨＴＴＰヘッダ内において、それ自体の情報をプロキシ・サーバに知らせるが、ＨＴＴＰヘッダは２つの関連する情報片を含むことができる。
１．デバイスの一意の識別子：例えば、Ｐｈｏｎｅ．ｃｏｍが頒布するマイクロブラウザを装備したワイヤレス・インターネット・デバイスでは、ＨＴＴＰヘッダの可変Ｘ−ＵＰ−ＳＵＢＮＯがデバイスの一意の識別子に結び付けられている。
２．デバイス種別：例えば、ＨＴＴＰヘッダの変数ＵＳＥＲ−ＡＧＥＮＴは、デバイス上にインストールされているブラウザ・ソフトウエアの種類を記述する文字列に結び付けられている。
【００４３】
文書変換を行うとき、プロキシ・コンピュータは既に一意のＩＤを取得してあり、これをキーとして用いて、データベースにおいてユーザに伴う１組の基本設定を調べる。
【００４４】
図７は、仮想データベース２４における行の一例を示す。各行４０は、デバイスの電話番号でデバイスを識別する。行は、ユーザの基本設定（図７の場合４つの異なる基本設定）を、識別したデバイスと関連付ける。この場合、電話番号（例えば、移動電話の）が一意のＩＤであり、データベース内のレコードに対するキーとして作用する。
【００４５】
データベースを調べてこのユーザに適した基本設定の値を判定した後、プロキシ・コンピュータはこれらの値を用いてその変換プロセスを導くことができる。つまり、図１および図４に示すように、変換プロセスへの入力は、ソース文書（例えば、ＨＴＭＬ形式）および１組のユーザの基本設定の値（図６からのデータベースにおける１行）である。
【００４６】
図８に示すように、文書の変換は、日付圧縮５２、単語の略語化５４、および画像抑制５５のような一連の動作を含み、ディスプレイが小さいデバイス上でレンダリングするのに一層適した形式に元の文書を変換する。各ステップにおいて、ターゲット・デバイスに対する基本設定を用いて、変換動作を構成する。例えば、クライアントに特定的な基本設定は、単語の略語化を抑制すること、または画像抑制５５を、指定サイズを超えた画像のみに適用することを示す可能性がある。
【００４７】
抑制することに加えて、画像にその他の種類の変換を行い、そのサイズを縮小することもできる。例えば、画像を圧縮し、ダウンサンプルし、またはカラーから白黒に変換することもできる。
【００４８】
ユーザ構成可能パラメータの一例は次を含む。
略語化（Ａｂｂｒｅｖｉａｔｉｏｎｓ）
文書を表示するために必要な空間を縮小するには、単語を略語化するとよい。単語を圧縮するには数々の方策があり、長い単語の切り捨て、共通する接尾辞の省略（”ｎａｔｉｏｎａｌ”を ”ｎａｔ’ｌ”にする）、母音の除去、またはＳｏｕｎｄｅｘアルゴリズム（ＭａｒｇａｒｅｔＫ．ＯｄｅｌｌおよびＲｏｂｅｒｔＣ．Ｒｕｓｓｅｌｌ，米国特許第１，２６１，１６７号（１９１８）および第１，４３５，６６３号（１９２２））のような、いくらか洗練性を高めた手順を用いる。対応するユーザ構成可能パラメータは、ユーザが略語化を許したいかまたは禁じたいかを示すブール値である。略語化を許すことによって、得られる文書の長さは減少するが、文書の意味が不明になる場合もある。
画像の抑制（Ｓｕｐｐｒｅｓｓｉｏｎｏｆｉｍａｇｅｓ）
画面が小さい移動デバイスの多くは、ビットマップ画像をレンダリングすることができない。可能な場合でも、大きな画像をレンダリングするには、長大な送信時間が必要となる場合がある。ビットマップ画像は、低解像度の画面上でレンダリングすると、画質が低下する可能性がある。これらの理由のために、ユーザはどのビットマップ画像を彼らのデバイス上でレンダリングするか否か制御することができる。この場合の対応するユーザ構成可能パラメータは、例えば、ブール値（レンダリングするか、またはレンダリングしない）、またはソース画像に対する画像の最大容認可能サイズとすることができる。
実体圧縮（Ｅｎｔｉｔｙｃｏｍｐｒｅｓｓｉｏｎ）
変換システムは、自然言語パーザを用いて、あるクラスの文字列を検出し、短縮化した形式に書き換えることができる。例えば、パーザは日付を検出し、短縮化形式に書き換えることができるので、例えば、「Ｄｅｃｅｍｂｅｒ１２，１９８４」は「１２／１２／８４」となり、「Ｆｅｂｒｕａｒｙ４」は「２／４」となり、「ｔｈｅｓｅｖｅｎｔｈｏｆＡｕｇｕｓｔ」は「８／７」となる。対応するユーザ選択可能パラメータ値は、ブール値（圧縮または非圧縮）、あるいは、３つの値、圧縮せず、月／日／年フォーマットに圧縮、または日／月／年フォーマットに圧縮、から１つを取ることができる。
【００４９】
同様に、変換システムは、数値量を解析し圧縮することができるので、（例えば）「ｓｅｖｅｎｔｅｅｎ」は「１７」となり、「ｔｅｎｇｉｇａｂｙｔｅｓ」は「１０ＧＢ」となる。多種多様の文書には、その他の多種多様の変換も考案可能である。
（デバイス単位の基本設定の指定および格納）
次に、デバイスのユーザから基本設定を取得し、これらの基本設定を具体的なクライアント・デバイスに関連付ける方法について、２つの例を挙げて説明する。
小型ディスプレイ・デバイスからの基本設定の入力
ユーザは、インターネット・アクセスに用いる同じ小型ディスプレイ・デバイスを用いて、プロキシ・コンピュータを訪問することによって、基本設定を入力し維持することができる。図９に示すように、プロキシ・コンピュータは、小型ディスプレイ・デバイスのユーザが検索し、彼らの基本設定に応じて記入したハイパーテキストフォームを格納する（６０）ことができる。クライアント・デバイスからＨＴＴＰ要求を受信すると（６２）、プロキシ・コンピュータは自動的にクライアント・デバイスの一意の識別子を取得する（ＨＴＴＰプロトコルを用いて）。次いで、プロキシ・コンピュータは、１組の基本設定を含むフォームをユーザに送信する（６４）。クライアント・デバイスが既にデータベース内に関連するエントリを有する場合、各パラメータの現在値をそのフォーム内に表示することができる。それ以外の場合、デフォルト値を表示する。ユーザは、このフォーム上で、相応しいと見なした場合、パラメータを変更し、次いでこのフォームをプロキシ・コンピュータに返送し（６６）、プロキシ・コンピュータは、更新した値をデータベース内の、当該クライアント・デバイスと関連付けたレコードに格納する。
従来のコンピュータからの基本設定の入力
あるいは、ユーザは、デスクトップまたはラップトップ・コンピュータ上で従来のウェブ・ブラウザを用いて同じＵＲＬを訪問することができる。プロキシ・コンピュータは、ＨＴＴＰヘッダ情報から、どのデバイスと基本設定を関連付けるか自動的に判断することができない。ユーザは、明示的に、基本設定を設定したいデバイスの一意の識別子、例えば、電話番号を指定しなければならない。図１０は、従来のＨＴＭＬを用いたデスクトップ・ウェブ・ブラウザ上で見られるフォームの一例を示す。図１１は、対応のページの最初の画面を示し、これは４ラインの移動電話ディスプレイ上で見られる（ユーザは、オプションの残りを見るためには、スクロールして表示を下げなければならない）。
（種別毎の基本設定の指定および格納）
前述の説明では、ユーザは、小型画面デバイスを用いて、遠隔地に格納されている文書にアクセスする人であり、プロキシ・コンピュータ（変換を行う）は、ユーザのデバイスとインターネットとの間で全体的に仲介を行う。
【００５０】
構成可能な変換が有用な別の設定は、個人または機関が、小型表示デバイス上において、それが生成した文書の外観を制御することである。このために、データの格納および送信を担当する原始サーバには、自動コンテンツ変換ソフトウエアを装備することができる（ウェブ・サーバ・ソフトウエアのモジュールまたは「プラグ・イン」を用いる）。すると、原始サーバ・ホストは、望み通りに変換ソフトウエアを構成し制御することが可能となる。
【００５１】
また、原始サーバは、一旦いずれかのユーザがそのサーバから特定の種別のクライアント・デバイスのために文書を検索したなら、変換を構成する能力をコンテンツの著作者に提供することもできる。言い換えると、エンド・ユーザに変換をカスタム化する能力を提供する代わりに、コンテンツを作成した人または機関にこの能力を提供することができる。この状況は、コンテンツ提供業者が小型表示デバイス上における彼らのコンテンツの表示に対して厳格な制御を望む場合に該当する。ユーザ（個々のデバイス）の基本設定のデータベースを格納するのではなく、原始サーバは、デバイスの種別毎に、変換に対して１組のパラメータのみを格納する。したがって、ユーザから原始サーバへの情報の流れは、次のようになる。
１．ユーザが原始サーバからの文書を要求する。
２．原始サーバは、要求、およびこの要求を行ったクライアント・デバイスの種別に関する情報を受信する。
３．原始サーバは、要求された文書の処理において、当該デバイスに適した変換パラメータを調べる。
４．原始サーバは変換した文書をクライアント・デバイスに配信する。
【００５２】
ステップ３に用いるデータベースにおけるエントリの一例を以下に示す。
【００５３】
【表２】

【００５４】
前の章では、エンド・ユーザが基本設定を指定して格納し、単一のデバイスと関連付ける方法について説明した。この章では、コンテンツ作成者が彼らの原始サーバから配信された文書の変換を構成する方法について説明する。これら２つの状況は、互いに両立可能なものではない。エンド・ユーザが原始サーバＹからの文書Ｘを要求すると想定する。また、エンド・ユーザが彼の変換に対して１組の基本設定を登録してあり、原始サーバ上には、当該原始サーバから配信される文書に対して、別の１組の基本設定が存在すると想定する。最初に、原始サーバにおいて基本設定に応じて文書が変換され、次いでエンド・ユーザの基本設定にしたがって変換される。この状況では、エンド・ユーザの基本設定が尊重されないこともときとしてあり得る。例えば、エンド・ユーザが単語の略語化を望まないが、原始サーバに対する基本設定が単語を略語化することを指定した場合、エンド・ユーザは、彼の基本設定には拘わらず、略語化した単語を含む文書を受信することになる。
（クライアント・デバイス上における基本設定の格納）
基本設定をデバイスと関連付ける代わりの方策は、ＨＴＴＰ「クッキー」状態機構を用いることである（Ｄ．ＫｒｉｓｔｏｌおよびＬ．Ｍｏｎｔｕｌｌｉ，ＲＦＣ２１０９：ＨＴＴＰＳｔａｔｅＭａｎａｇｅｍｅｎｔＭｅｃｈａｎｉｓｍ（ＨＴＴＰ状態管理機構）（１９９７）。＊＊ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／Ｐｒｏｔｏｃｏｌｓ／ｒｆｃ２１０９／ｒｆｃ２１０９．ｔｘｔ＊＊）。この場合、基本設定情報は、クライアント・デバイスから離れたデータベース上に格納されるのではなく、デバイス自体に格納される。この設定のデバイス単位の基本設定情報の流れは次の通りである。
１．小型表示デバイスのユーザが、プロキシ・コンピュータに、基本設定のフォーム文書の要求を提出する。フォーム文書は、プロキシ・コンピュータからデバイスに送信される。
２．ユーザは彼の基本設定を書き込み、書き込んだフォームをプロキシ・コンピュータに返送する。
３．プロキシ・コンピュータは、応答して確認文書を送り、更に、ＨＴＴＰヘッダ情報内で、ユーザの基本設定を含むクッキーも送信する。例えば、クッキーとは次のようにすることもできる。
【００５５】
Ｓｅｔ−Ｃｏｏｋｉｅ：ＰＲＥＦＳ＝”ａｂｂｒｅｖｓ：ｙｅｓｉｍａｇｅｓ：ｎｏｄａｔｅｓ：ｙｅｓ．．．”；ｐａｔｈ＝／；ｅｘｐｉｒｅｓ＝０４−Ｓｅｐ−０１２３：１２：４０ＧＭＴ
４．クライアント・デバイスはこのクッキーを永続的状態として格納する。
５．クライアント・デバイスのユーザが後にプロキシ・コンピュータからの文書を要求するとき、デバイスは、格納されている基本設定を含むクッキーもプロキシ・コンピュータに送信する。
【００５６】
Ｃｏｏｋｉｅ：ＰＲＥＦＳ＝”ａｂｂｒｅｖｓ：ｙｅｓｉｍａｇｅｓ：ｎｏｄａｔｅｓ：ｙｅｓ．．．”；
６．このクライアントに対する基本設定を受けて、プロキシ・コンピュータは要求された文書を変換する際に、これらの基本設定を適用する。クッキーの期限が切れていたかまたは消去されていたためにクライアント・デバイスがクッキーを送信しなかった場合、プロキシ・コンピュータはデフォルトの変換を適用する。
（応用）
図１２に示すように、ワイヤレス・デバイス５０と「有線」インターネット５３との間の通信は、ゲートウェイ５２を介して行われるのが通例である。ゲートウェイ５２は、有線およびワイヤレス世界の間を仲介する。例えば、ＷＡＰ可能デバイスのユーザによる文書要求が、ワイヤレス・ゲートウェイに送信されると、ワイヤレス・ゲートウェイは、要求された文書を担当する（ＤＮＳプロトコルに応じて）原始サーバ５４（インターネット上）に要求を転送する。
【００５７】
要求された文書が、具体的にクライアント・デバイスのために設計されており、当該デバイスによって受け入れられるマークアップ言語で書かれている場合、コンテンツの変換は不要である。マークアップ言語は、ＨＴＭＬの場合もあるが、ＷＭＬ、ＨＤＭＬのようなマークアップ言語、あるいは固有言語の方が多い。個々のワイヤレス・データ・デバイスの能力は異なるので、コンテンツ作成者は、各ターゲット・マークアップ言語だけでなく、可能なあらゆるターゲット・デバイスにも、別個のバージョンを作成しなければならない。コンテンツ提供業者は、クライアント・デバイスの検出法、および当該クライアントに対して最適にフォーマットした文書を作成する方法も把握する必要がある。
【００５８】
図１３に示すように、自動コンテンツ変換システム７０は、特定のターゲット・デバイス上のディスプレイに適したフォーマットに、文書７２を自動的に圧縮しフォーマットし直すことができる。これによって、コンテンツ作成者が自由となり、コンテンツを種々のターゲット・デバイス用に作り替えることなく、コンテンツの執筆に集中することができる。コンテンツ変換システムは、従来とは異なるクライアント・デバイスからの要求を傍受し、ターゲット・デバイス７８上のディスプレイ用に、要求された文書をカスタム化し、変換した文書７４をクライアントに送信する。コンテンツ変換システムは、ユーザ基本設定７６およびデバイスの仕様６４を用いて、文書変換プロセスを導く。
【００５９】
要求されたページ７２が、要求を行ったクライアント・デバイスのために特定的に設計されていた場合、コンテンツ変換は不要となる。しかし、ワイヤレス・デバイス用に文書を設計するのは単純なことではない。文書は、それらデバイスが受け入れるマークアップ言語で書かれていなければならない。これは、ＨＴＭＬの場合もあるが、ＷＭＬ、ＨＤＭＬ、または企業固有の言語というような、その他のマークアップ言語であることの方が多い。何百もの異なるワイヤレス・データ・デバイスの能力６４はそれぞれ異なるので、コンテンツ作成者は、各ターゲット・マークアップ言語だけでなく、可能なあらゆるターゲット・デバイス用に別個のバージョンを作成しなければならないという予想（ｐｒｏｓｐｅｃｔ）に直面する。また、コンテンツ提供業者も、クライアント・デバイスの種別を検出する方法を把握し、当該クライアント用に最適にフォーマットした文書を作成する必要がある。
【００６０】
システム７０を用いることによって、特定のターゲット・デバイス上における最適な表示のために文書を自動的に圧縮し再フォーマットするので、コンテンツ作成者は、彼らの中核的力量−コンテンツを書く力量−に自由に集中し、種々のターゲット・デバイスのためにコンテンツを書き改める（ｒｅｔａｒｇｅｔ）必要はなくなる。一旦インストールされれば、コンテンツ変換システムは、標準とは異なる（ｎｏｎ−ｔｒａｄｉｔｉｏｎａｌ）クライアント・デバイスからの要求を傍受し、要求された文書をターゲット・デバイス上での表示のためにカスタム化し、変換した文書をクライアントに送信する。コンテンツ変換システムは、自動文書区分化を用いて、大きな文書全体を処理できないデバイスに対しては、大きな文書の配信を段階的に処理する。
【００６１】
コア・コンテンツ変換コンポーネント８１は、先に説明した区分プロセスを含むことができる。ＸＭＬキャッシュ・オブジェクト８４は、ユーザ単位のサブ文書を区分プロセスのために格納する場所である。
【００６２】
コンテンツ変換は、サーバ側の技術であり、当然クライアント−原始サーバ・チャネルにおける種々の場所、ワイヤレス・ゲートウェイから元の文書を保持する原始サーバまでのあらゆる場所に展開することができる。以下の表に、コンテンツ変換を適用可能な場所をいくつか纏めた。
【００６３】
【表３】

【００６４】
図１４は、５つのサブ文書に分割した入力文書（フルサイズのウェブ・ページ）の一例を示す。図１５は、元のページの”Ｂｒｏｎｘ−ＷｈｉｔｅｓｔｏｎｅＢｒｉｄｇｅ”部分の中央に対応する、４番目のサブ文書７２の最下位部分を示す。「ｐｒｅｖ」７４および「ｎｅｘｔ」７６で示すハイパーリンク（アイコン）を起動すると、ユーザはそれぞれ３番目または５番目のサブ文書に移動する。図１６は、５番目のサブ文書７８の先頭を示す。これは４番目が終わったところから始まる。ユーザは、必要に応じて、サブ文書中をスクロールすることができる。実現例によっては、ユーザがサブ文書の先頭または終端までスクロールしたときに、図示のように、アイコン７４、７６のみを表示する。別の例では、アイコンを常時表示することも可能である。
【００６５】
図１５および図１６では、原紙における数や単語を略語化し（「ｏｎｅ」は「１」、「ａｎｄ」は「＆」になっている）、曜日も短縮してある。
【００６６】
各サブ文書の表示は、元の文書の見出し７９の表示も含む。この見出しは、サブ文書が元の文書から作成されるときに、サブ文書に含まれる。また、表示は、サブ文書の総数８７、および元の文書を構成する一連のサブ文書における現サブ文書の位置８９も含む。
【００６７】
別の実現例も、特許請求の範囲に該当することとする。
【００６８】
例えば、ユーザ・インターフェースにおいて、ターゲット・デバイス上に広げた各サブ文書の最下位部分は、当該サブ文書が、元の文書を構成する１組のサブ文書のどこに当たるかを示すグラフィカル・ステータス・バーを含むことができる。例えば、ｏｏｘｏｏｏｏは、「これは７枚のサブ文書の内３番目である」ということを意味する。更に、このステータス・バーにおけるｏの各々を当該サブ文書にハイパーリンクし、ユーザが文書内の異なるサブ文書にランダムにアクセスできるようにすることも可能である。これは、サブ文書毎に順に進めるよりも一層効率的とすることができる。
【図面の簡単な説明】
【図１】
図１は、文書変換および提供システムを示す。
【図２】
図２は文書を示す。
【図３】
図３はフロー図を示す。
【図４】
図４は文書階層を示す。
【図５】
図５は文書階層を示す。
【図６】
図６は、文書変換プロセスを示す。
【図７】
図７は、データベースを示す。
【図８】
図８は、文書変換システムを示す。
【図９】
図９は、基本設定を表現するプロセスを示す。
【図１０】
図１０は基本設定の形態を示す。
【図１１】
図１１は、基本設定の形態を示す。
【図１２】
図１２は、無線／ワイヤレス通信システムを示す。
【図１３】
図１３は、文書変換システムを示す。
【図１４】
図１４は、ウェブ・ページを示す。
【図１５】
図１５は、ウェブ・ページの一部の小型画面表示を示す。
【図１６】
図１６は、ウェブ・ページの一部の小型画面表示を示す。
【図１７】
図１７は、個別使用のためのサブ文書の分離を示す。

Claims

クライアントに提供しクライアント・デバイス上に表示するための文書を含む機械読み取り可能ファイルを受信するステップであって、前記ファイル内の文書の各々の編成が情報の階層で表現されている、ステップと、
前記情報の階層からサブ文書を導出するステップであって、前記サブ文書の各々を、ハイパーテキスト送信プロトコルを用いて前記クライアントに別個に提供することを可能にするフォーマットで表現し、前記サブ文書の少なくとも１つが、当該サブ文書を前記サブ文書の別の１つにリンクすることを可能にする情報を含む、ステップと、
から成る方法。
請求項１記載の方法において、前記言語が拡張可能マークアップ言語（ＸＭＬ）から成る、方法。
請求項１記載の方法において、前記導出するステップが、前記階層を調べ、セグメントから前記サブ文書を組み立てることから成り、前記サブ文書の少なくとも一部を、各々、１つよりも多い前記セグメントから組み立てる、方法。
請求項３記載の方法において、前記組み立てが、前記サブ文書のそれぞれのサイズのバランスを取るように作用するアルゴリズムに従う、方法。
請求項３記載の方法において、前記組み立てが、前記階層において共通の親を有するセグメントから、サブ文書の各々を組み立てることを優先するように作用するアルゴリズムに従う、方法。
請求項３記載の方法において、前記組み立てが、前記階層におけるノードの複製を必要としないセグメントから、サブ文書の各々を組み立てることを優先するように作用するアルゴリズムに従う、方法。
請求項１記載の方法において、前記ファイルに関連する原始サーバから前記ファイルを受信する、方法。
請求項７記載の方法において、前記ファイルが、前記文書のセグメントを階層状に編成しない言語で表現され、前記サブ文書を導出するステップは、最初に、前記文書のセグメントを階層状に編成する言語に、前記ファイルを変換することを含む、方法。
請求項１記載の方法であって、更に、クライアントによる要求に応じて、前記サブ文書を個別に前記クライアントに提供するステップを含む、方法。
請求項９記載の方法において、ハイパーテキスト送信プロトコルを用いて前記サブ文書をクライアントに提供する、方法。
請求項９記載の方法において、前記サブ文書の要求は、前記クライアントによって、前記サブ文書の別のものにリンクすることを当該クライアントに可能にする前記情報の内容に基づいて行われる、方法。
請求項１記載の方法であって、更に、
前記文書の一部を識別し、前記文書の残りからは分離して表示するステップを含み、
前記別個に表示する文書の一部は、前記部分が現れるはずのサブ文書から割愛され、前記別個に表示する文書の一部は、少なくとも１つの対応するサブ文書に含まれ、
前記一部が現れるはずの前記サブ文書を前記クライアント・デバイスに提供する場合、グラフィカル・デバイスを埋め込み、前記ユーザが起動して、前記別個に表示すべき文書の一部を含むサブ文書を検索可能とした、方法。
原始サーバから、クライアント・デバイス上での表示のためにクライアントに提供する文書を含む機械読み取り可能ファイルを受信するステップであって、前記ファイルが、前記文書のセグメントを階層状に編成しない言語で表現されている、ステップと、
前記文書のセグメントを階層状に編成する言語に、前記ファイルを変換するステップと、
前記階層を調べ、前記セグメントからサブ文書を組み立てるステップであって、前記サブ文書の少なくとも一部は、各々が、１つよりも多い前記セグメントから組み立てられ、前記組み立てが、（ａ）前記サブ文書のそれぞれのサイズのバランスを取る、（ｂ）前記階層において共通の親を有するセグメントから、サブ文書の各々を組み立てることを優先する、および（ｃ）前記階層におけるノードの複製を必要としないセグメントから、サブ文書の各々を組み立てるように作用するアルゴリズムに従う、ステップと、
ハイパーテキスト送信プロトコルを用いて、前記クライアントに個別に提供可能とするフォーマットで、前記サブ文書の各々を表現するステップであって、前記サブ文書の少なくとも１つが、前記サブ文書の別の１つに当該１つのサブ文書をリンクすることを可能にする情報を含む、ステップと、
前記クライアントによる要求に応じて、前記サブ文書の別のものにリンクすることを当該クライアントに可能にする前記情報の内容に基づいて、前記サブ文書を前記クライアントに個々に提供するステップであって、ハイパーテキスト送信プロトコルを用いて当該提供を行う、ステップと、
から成る方法。
クライアントに提供するために記憶媒体上に保持された機械読み取り可能文書であって、該文書が１組のサブ文書として編成されており、前記サブ文書の各々が、当該サブ文書を前記サブ文書の別のものにリンクすることを可能にする情報を含み、前記サブ文書の各々が、前記文書の階層的表現の一部である、前記文書のセグメントの集合体であり、前記サブ文書がほぼ同じサイズである、機械読み取り可能文書。
請求項１４記載の文書において、前記サブ文書をリンクすることを可能にする情報がＵＲＬから成る、文書。
請求項１４記載の方法において、前記階層的表現が拡張可能マークアップ言語（ＸＭＬ）から成る、方法。
クライアントから、クライアント・デバイス上に表示する文書の要求を受信するステップと、
前記要求文書の全て未満を表すサブ文書を別個に前記クライアントに提供するステップであって、各サブ文書がそれを少なくとも１つの別のサブ文書にリンクする情報を含む、ステップと、
前記クライアントから、前記他のサブ文書へのリンクの呼び出しを受信するステップと、
前記クライアント・デバイスに前記別のサブ文書を別個に提供するステップと、
から成る方法。
請求項１７記載の方法において、ハイパーテキスト送信プロトコルを用いて前記サブ文書を前記クライアントに提供する、方法。
請求項１７記載の方法において、前記サブ文書が本質的に同じ長さである、方法。
請求項１７記載の方法において、前記サブ文書が、前記クライアント・デバイス上において、更に切り捨てることなく、表示可能な長さを有する、方法。
クライアント・デバイスにおいて、該クライアント・デバイス上に表示するために、大きな文書のサブ文書をサーバから受信するステップと、
前記サブ文書を前記クライアント・デバイス上に表示するステップと、
前記クライアント・デバイスにおいて、前記大きな文書の別のサブ文書を表示させるユーザの要求を受信するステップと、
前記サーバから、前記別のサブ文書を前記クライアント・デバイスにおいて別個に受信するステップと、
前記別の文書を前記クライアント・デバイス上に表示するステップと、
から成り、前記サブ文書が実質的に同じ長さである、方法。
請求項２１記載の方法において、前記サブ文書をハイパーテキスト送信プロトコルで表現した、方法。
請求項２１記載の方法において、前記ユーザの要求をＵＲＬとして表現した、方法。
請求項２１記載の方法において、前記各サブ文書の全てを前記クライアント・デバイス上で一度に表示する、方法。
請求項２１記載の方法において、前記各サブ文書の全て未満を前記クライアント・デバイス上で一度に表示する、方法。
クライアント・デバイス上で文書のサブ文書を表示するステップと、
前記サブ文書と共にアイコンを表示するステップと、
前記アイコンの起動に応答して、サーバから前記文書の別のサブ文書を取り込み、該別のサブ文書を前記クライアント・デバイス上に表示するステップと、
から成り、前記サブ文書の各々が前記文書全体未満であり、前記サブ文書がほぼ同じサイズである、方法。
請求項２６記載の方法において、前記各サブ文書の一部を一度に表示する、方法。
請求項２７記載の方法であって、更に、前記文書を構成する一連のサブ文書において、現在表示されているサブ文書の位置の指標を表示するステップを含む、方法。
請求項２８記載の方法において、前記指標が、前記一連におけるサブ文書の総数と、前記一連における現在表示中の文書の位置とを含む、方法。
請求項１、１７、または２１記載の方法において、前記クライアント・デバイスからの前記文書の要求時において、前記文書から前記サブ文書を導出する、方法。
請求項３０記載の方法において、前記クライアント・デバイスの特性に基づいた方法で、前記サブ文書を導出する、方法。
請求項３１記載の方法において、前記クライアント・デバイスの特性は、前記クライアントが前記要求と共に提供する、方法。
請求項３２記載の方法において、前記特性が、前記クライアント・デバイスの表示能力を含む、方法。
請求項１、１７、または２１記載の方法において、前記クライアントが前記サーバからの前記文書を要求する前に、前記文書から前記サブ文書を導出する、方法。
請求項３４記載の方法において、異なる原始サーバからの異なる文書について、前記サブ文書を導出する、方法。
請求項１、１７、または２１記載の方法において、ワイヤレス通信ゲートウェイにおいて前記文書から前記サブ文書を導出する、方法。
クライアント・デバイス上での表示のためにクライアントに提供する文書を含む機械読み取り可能ファイルを受信し、前記ファイルからサブ文書を導出するように構成されたネットワーク・サーバを備え、前記サブ文書の各々が、ハイパーテキスト送信プロトコルを用いて前記クライアントに別個に供給可能にするフォーマットで表現されており、前記サブ文書の少なくとも１つは、それを前記サブ文書の別の１つにリンクすることを可能にする情報を含む、装置。
クライアント・デバイス上での表示のためにクライアントに提供する文書を含む機械読み取り可能ファイルを受信する手段と、
前記ファイルからサブ文書を導出する手段であって、前記サブ文書の各々が、ハイパーテキスト送信プロトコルを用いて前記クライアントに別個に供給可能にするフォーマットで表現されており、前記サブ文書の少なくとも１つは、それを前記サブ文書の別の１つにリンクすることを可能にする情報を含む、手段と、
を備えている装置。
機械読み取り可能媒体上に格納された機械読み取り可能プログラムであって、
クライアント・デバイス上での表示のためにクライアントに提供する文書を含む機械読み取り可能ファイルを受信し、
前記ファイルからサブ文書を導出し、前記サブ文書の各々が、ハイパーテキスト送信プロトコルを用いて前記クライアントに別個に供給可能にするフォーマットで表現されており、前記サブ文書の少なくとも１つが、当該１つを前記サブ文書の別の１つにリンクすることを可能にする情報を含む、
ように機械を構成可能な機械読み取り可能プログラム。
請求項７記載の方法において、前記ファイルが電子文書から成る、方法。
請求項７記載の方法において、前記ファイルが電子メールから成る、方法。
請求項７記載の方法において、前記ファイルを前記原始サーバからウェブ・ページの形態で受信する、方法。