ウェブコンテンツ適合化プロセスおよびシステム
【課題】ウェブコンテンツ適合化プロセスおよびシステム
【解決手段】ウェブページコンテンツを適合させる装置及び方法について説明されている。ウェブページコンテンツをより小型の所定の表示装置において表示するために適合させることは、該コンテンツを幾つかのより小さいページにわたって分割することをしばしば要求する。該装置及び方法は、プロセスを最適化するためにコンテンツ分割プロセスと変換の実施（例えば、フォントサイズ、画像、等の縮小）を統合する手順に関連する。該手順は、ウェブページコンテンツ全体にわたって体系的に実施され、該コンテンツを反復的により小さい部分に分割することと、これらのより小さいページ上において見ることができる空白スペース量を最小にするために様々な変換を同時に実施すること、とを繰り返す。更に、好ましい実施形態は、オブジェクトに関して既に実施されている変換を追跡し、更に、これらの変換をのちにその他の類似のオブジェクトに関しても実施することによって一貫性を確保する。
【解決手段】ウェブページコンテンツを適合させる装置及び方法について説明されている。ウェブページコンテンツをより小型の所定の表示装置において表示するために適合させることは、該コンテンツを幾つかのより小さいページにわたって分割することをしばしば要求する。該装置及び方法は、プロセスを最適化するためにコンテンツ分割プロセスと変換の実施（例えば、フォントサイズ、画像、等の縮小）を統合する手順に関連する。該手順は、ウェブページコンテンツ全体にわたって体系的に実施され、該コンテンツを反復的により小さい部分に分割することと、これらのより小さいページ上において見ることができる空白スペース量を最小にするために様々な変換を同時に実施すること、とを繰り返す。更に、好ましい実施形態は、オブジェクトに関して既に実施されている変換を追跡し、更に、これらの変換をのちにその他の類似のオブジェクトに関しても実施することによって一貫性を確保する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブページコンテンツを複数のより小さいウェブページに分割することによって所定の表示装置において表示できるように適合させる装置およびシステムに関するものである。
【背景技術】
【０００２】
ウェブコンテンツを異なった種類のデバイスに引き渡すことは、コンテンツソースについて理解して該コンテンツソースをデバイス特性に適合する形で異なった種類のデバイス（デスクトップＰＣ、ＰＤＡ、及び携帯電話、等）に引き渡すことができるように該ウェブコンテンツを理解、再構築及び個別適合化するプロセスである。従来の技術（例えば、Current Technologies for Device Independent, Mark H Butler, HP Labs Technical Report HPL-2001-83 4 April 2001）（デバイスに依存しないための現在の技術、マークＨバトラー、HP研究所技術報告書ＨＰＬ−２００１−８３ ２００１年４月４日を参照）では、現在知られている方法は以下の3つである。
【０００３】
第１の方法では、ウェブ開発者／著者は、ウェブコンテンツ開発段階において、ウェブページ開発ソフトを用いて、コンテンツが異なった種類のデバイスに適合するように手作業で適合させることができる。この方法によって、単一のコンテンツソースの異なったバージョン(HTML/CSS、ＷＭＬ、ＸＭＬ／ＸＳＬ、等)をデバイスの能力に基づいて作り出すことができる。この手法は、ウェブコンテンツを異なった種類のデバイスに引き渡す上で最も原始的な方法であり、大量のバージョンが要求される場合はウェブ開発者／著者にとって時間のかかる面倒な仕事である。
【０００４】
第１の方法よりも自動的である第２の手法は、エンドユーザーがHTTP要求を通じてURIリンクを提出時に速やかに適合化作業を行うプロキシサーバーを通じての、プロキシに基づくトランスコーディング手法を用いる。この手法は、プロキシサーバーに計算が集中しており、その結果システム応答時間が低速になる。更に、適合されたウェブコンテンツの原ウェブ開発者／著者が介在しておらず、国によっては法律上および著作権上の問題が発生するおそれがある。
【０００５】
第３の既知の方法は、適合化システムソフトをクライアント側にインストールすることによってクライアントに基づく（エンドユーザーデバイス）適合化手法を用いる方法である。クライアントに基づく適合化システムは、要求を受けたウェブサーバーによって戻された結果を受け取り後速やかにウェブコンテンツを適合化させる。この手法は、クライアント側に計算が集中しており、その結果クライアントの処理性能を費やして低下させることになる。この場合も、適合されたウェブコンテンツの原ウェブ開発者／著者が介在しておらず、法律上および著作権上の問題が同様に発生するおそれがある。更に、この手法は、計算能力に限界がある小型のモバイルデバイスには利用することができない。
【０００６】
適合化の一環として、PDA及びWAP電話、等のクライアント表示装置は小型であることに鑑みて１つのウェブコンテンツページを複数のより小さいページに分割することが必要になることがある（コンテンツ分割と呼ばれる）。例えば、ＰＣウェブページ（８００ｘ６００画素、等）のコンテンツを読み取り可能な形でより小型の表示装置（２４０ｘ３２０画素のＰＤＡ、等）に提供する場合は、空白スペース量を最小限にすることを試みつつ該コンテンツが最も少ない数のより小さいページ内に納まるように適合させるのが望ましい。
【０００７】
従来の既知のコンテンツ分割方法は、"System, Method and Computer Program Product for Page Rendering Utilizing Transcoding"（トランスコーディングを利用したページ提供のためのシステム、方法及びコンピュータプログラム製品）という題名の米国特許出願Ｎｏ．０９／９４２，０５１（ＵＳ２００３／００５０９３１ Ａ１として発行）において説明されている方法を含む。この文書は、ウェブコンテンツを複数のページに分割することによって異なった種類の閲覧装置上において表示できるように適合させることができるシステムについて説明している。該システムは、最初に、ウェブコンテンツを使用し、ＸＭＬを用いて階層ツリー構造を構築し、次に、（閲覧装置によってサポートされているテキストフォントに変更し、さらに冗長な情報を変数への参照に置き換えることによって）該階層ツリー構造を閲覧装置において表示できるようにフォーマット化する。次に、フォーマット化された構造を閲覧装置に出力するために複数のページに分割する。しかしながら、該手法は、コンテンツを分割してクライアント表示装置に適合させるという目標は達成させる一方で、空白スペース量を最小限に抑えるという望ましい目標は達成させない。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
従って、ウェブページコンテンツを所定の表示装置において表示するために適合させさらに従来の技術の欠点（特に、コンテンツとともに表示される空白スペース量を最小限に抑えるように試みることに関する欠点）を有していないさらなる手法を開発する必要がある。
【課題を解決するための手段】
【０００９】
本発明は、上記の要求を満たすため、所定の表示装置において表示するためにウェブページコンテンツを適合させる装置および方法を提供する。本出願明細書においては、分割と変換と結合させた統合プロセスが、コンテンツの表示サイズを適合させるために反復的な形で提供される。このことは、ページ上に現れる空白スペース量を最小にしつつ適切な数のより小さいウェブページにコンテンツを分割することを可能にする。この前後関係において、「変換」という用語は、例えば、画像のサイズの縮小／拡大／テキスト削除／コンテンツ交換、等を含むことができる。
【００１０】
本発明の第１の側面においては、ウェブページコンテンツを所定の表示装置において表示するために適合させる装置が提供されており、該装置は、該コンテンツを該表示装置において表示するために複数のより小さいウェブページに分割するための適合化手段を具備し、該適合化手段は、下記の手順を実行するように準備されている。
【００１１】
（ｉ）該コンテンツを複数のコンテンツ部分に分割し、更に、該コンテンツ部分のうちの少なくとも１つに関してステップ（ｉｉ）乃至（ｖｉ）を反復的に繰り返す。
【００１２】
（ｉｉ）該コンテンツを解析し、該コンテンツ部分のサイズが該表示装置において表示するのに適しているかどうかを決定する。
【００１３】
（ｉｉｉ）該コンテンツ部分のサイズが該表示装置において表示するのに適していない場合は、複数の変換を該コンテンツ部分に関して実施する。
【００１４】
（ｉｖ）変換されたコンテンツを解析し、変換されたコンテンツ部分のサイズが該表示装置において表示するのに適しているかどうかを決定する。
【００１５】
（ｖ）変換されたコンテンツ部分のサイズが該評価装置において表示するのに適していない場合は、該コンテンツ部分を複数のさらなるコンテンツ部分に分割する。
【００１６】
本発明の第２の側面においては、ウェブページコンテンツを所定の表示装置において表示するために適合させる方法が提供されており、該方法は、下記のステップを実行することによって、該コンテンツを該表示装置において表示するために複数のより小さいウェブページに分割することを具備する。
【００１７】
（ｉ）該コンテンツを複数のコンテンツ部分に分割し、更に、該コンテンツ部分のうちの少なくとも１つに関してステップ（ｉｉ）乃至（ｖｉ）を反復的に繰り返す。
【００１８】
（ｉｉ）該コンテンツを解析し、該コンテンツ部分のサイズが該表示装置において表示するのに適しているかどうかを決定する。
【００１９】
（ｉｉｉ）該コンテンツ部分のサイズが該表示装置において表示するのに適していない場合は、少なくとも１つの変換を該コンテンツ部分に関して実施する。
【００２０】
（ｉｖ）変換されたコンテンツを解析し、変換されたコンテンツ部分のサイズが該表示装置において表示するのに適しているかどうかを決定する。
【００２１】
（ｖ）変換されたコンテンツ部分のサイズが該表示装置において表示するのに適していない場合は、該コンテンツ部分を複数のさらなるコンテンツ部分に分割する。
【００２２】
本発明の第３の側面においては、コンピュータシステムによって実行時に該コンピュータシステムに上記の方法を実施させるように配備された1つのコンピュータプログラム又は一組のプログラムが提供されている。該1つの又は複数のプログラムは、該コンピュータプログラム又は該一組のプログラムのうちの少なくとも１つに対応するデータを組み込んだ変調搬送信号（例えば、インターネット等のネットワーク上で搬送される信号）によって具体化することができる。
【００２３】
更に、さらにもう１つの側面においては、本発明は、第３の側面に従った１つのコンピュータプログラム又は一組のコンピュータプログラムのうちの少なくとも１つを格納する、コンピュータによって読み取り可能な記憶媒体も提供する。該コンピュータによって読み取り可能な媒体は、コンピュータによって読み取り可能なあらゆる磁気記憶媒体、光学記憶媒体、磁気光学記憶媒体、ソリッドステート記憶媒体、又はその他の記憶媒体であることができる。
【００２４】
上述されておりさらに付随の請求項によって説明されている本発明の側面、および本出願明細書および付随の請求項において説明されているあらゆる好ましい特長は、当業者にとって明確であるあらゆる適切な組合せで組み合わせることができる。
【００２５】
例示することのみを目的として示されている本発明の実施形態に関する以下の説明及び添付図面を参照することによって、本発明のさらなる特長及び利点が明確になる。尚、これらの図においては、同一のものについては図面全体に渡って同一の参照番号を付けることとする。
【発明を実施するための最良の形態】
【００２６】
図１乃至６を参照しつつ本発明の１つの実施形態について説明する。
【００２７】
図１は、本発明の実施形態によって提供されるシステムのシステムブロック図である。このシステムは、次に説明する８つの副構成要素を具備する。システムの全動作については後述される。
【００２８】
第１に、クライアント能力発見モジュール１２が提供される。このモジュールの目的は、エンドユーザーのデバイスの特性、例えば、デバイスの型及びデバイスの能力（サポートされている画面の大きさ／解像度、処理能力、等）を発見することであり、このため、このモジュールは、エンドユーザーの表示装置の能力に関連する情報を該表示装置から受け取る。クライアント能力発見モジュール１２は、エンドユーザーのデバイス情報を決定モジュール１４に渡す。
【００２９】
決定モジュール１４は、適合化システムによって事前に検出されたか又は予め定義されている既存のクライアント能力プロフィール識別子を含む。クライアント能力プロフィール識別子は、表示装置の表示特性に関連する情報の集合である。使用時には、決定モジュール１４は、最初に、発見モジュールによって送られた情報に基づくエンドユーザーのデバイスの特性・能力（ＣＣ）範囲と、既存の能力プロフィールを比較する。クライアントの能力が既存のプロフィールとマッチしている場合は、該マッチしているプロフィールのプロフィール識別子がコンテンツキャッシュ１０に送られる。コンテンツキャッシュ１０には、予め生成された適合化ウェブコンテンツの異なった種類のバージョンが保存されている。受け取られたＣＣの組が既存のＣＣ範囲とマッチしない（即ち、現在要求中のデバイスの能力とマッチする既存のＣＣプロフィールが存在しない）場合は、適合化モジュール１６がトリガーされる。更に、適合化モジュール１６は、エンドユーザーからの特定の要求がない場合でも、原ウェブコンテンツの異なった種類のバージョンを生成するために手作業でトリガーすることもできる。
【００３０】
適合化モジュール１６は、どのような方法でトリガーされた場合でも、要求されたウェブコンテンツのｈｔｔｐヘッダーを検討するように動作し、更に、コンテンツ解析モジュール２０を制御し、要求されたウェブコンテンツをウェブコンテンツソース保存領域２２から検索するようにさらに動作する。次に、コンテンツ解析モジュール２０は、コンテンツソース保存領域２２から得られた指示されたウェブコンテンツを解析するように動作し、該ウェブコンテンツの特性に関連する１つの範囲のパラメータを、適合化モジュール１６への入力値として適合化モジュール１６に戻す。適合化モジュール１６において受け取られたコンテンツ解析モジュール２０からの入力パラメータは、ウェブコンテンツ保存領域２２に保存されている原ウェブコンテンツから得られた要求されているウェブコンテンツの適合化を適合化モジュール１６が行うことを可能にする。従って、適合化モジュール１６の出力は、最初に要求されたウェブコンテンツの適合化バージョンであり、この適合化バージョンは、ウェブコンテンツを要求中の表示装置のディスプレイの一組の１つ以上の特性である一組のクライアント能力（ｃｃ）情報とともに、ｈｔｍｌ等の該当するマークアップ言語でキャッシュ１０に送られる。尚、該表示特性情報は、上述されているクライアント能力発見モジュール１２によって決定された情報である。
【００３１】
上記のモジュールに加えて、既述のように、原ウェブコンテンツの異なった適合化バージョンを保存するように動作するコンテンツキャッシュ１０も提供される。幾つかの実施形態においては、キャッシュ１０は、異なったクライアント表示装置の表示特性に関連する情報の集合であるクライアント能力特性も保存することもできる。更に、適合化対象の原ウェブコンテンツが保存されるコンテンツソース２２、及び、コンテンツ解析モジュール２０の制御下で動作し、コンテンツソース保存領域２２から受け取った原ウェブコンテンツを解析前に整理するコンテンツ整理モジュール１８も提供される。更に加えて、コンテンツキャッシュからの適合化済みウェブコンテンツのプレビューを提供するフロントエンドシステムであるにすぎないカスタム化モジュール２４も提供される。カスタム化モジュール２４は、著者が適合化されたコンテンツをプレビューしてさらにカスタム化することを可能にするオフラインモジュールである。
【００３２】
本発明の実施形態によって提供される様々なシステムモジュールについて説明後は、図２乃至６を参照しつつこれらのモジュールの動作についてさらに詳細に説明する。
【００３３】
本発明によって提供される装置は、ウェブサーバー、等として動作するコンピュータシステムにおいて具体化するのが最も有望である。代替として、該装置は、別個のコンピュータシステムにおいて具体化することができる複数のコンピュータシステムコンポーネント（図１参照）において具体化することができる。好ましいことに、これらのコンピュータシステムのうちの１つは、その他のコンピュータシステムに関するウェブサーバーとして動作する。該装置がどのような形で具体化された場合においても、該コンピュータシステムは、単なるサーバーとして動作するだけでなく、ウェブコンテンツの著者がウェブコンテンツを開発すること及びその見直しを行うことも可能にする。更に、該コンピュータシステムは、異なった種類の所定の表示装置のために原ウェブコンテンツの異なったバージョンを生成するようにも動作する。
【００３４】
上記の機能に鑑みて、以下の３つの異なったシステム動作モードが存在する。
【００３５】
第１のモード−システムは、ネットワークを通じて受け取られているユーザーのウェブコンテンツ要求に対応するように動作する。
【００３６】
第２のモード−システムは、ユーザーからのウェブコンテンツ要求を受け取る前に、該ウェブコンテンツの適合化されたバージョンを異なった種類の所定の表示装置のために生成するように動作する。
【００３７】
第３のモード−さらなる適合化されたバージョンを提供するためのウェブコンテンツ適合化を、ユーザー要求に対応して速やかに実施することができる。
【００３８】
以下ではこれらの動作モードの各々について説明する。
【００３９】
最初に上記の動作モードのうちの第２の動作モードに関して、ユーザーによる要求前に原ウェブコンテンツの異なったバージョンを生成するためにシステムを使用中であると想定する。例えば、このモードは、ウェブサイト開発中に使用し、異なった種類の所定の表示装置に合わせて各々が特別に適合化されていて各々が異なった表示特性を有する（原ソースウェブコンテンツ）のバージョンを生成することができる。
【００４０】
従って、該モードにおいて実施される第１ステップは、複数の組の予め定義された所定表示装置表示特性プロフィールが生成され、各組は、一意のＩＤを有しており更に各々の特性が１つの範囲の値をとる一組の１つ以上の表示特性に対応している。例えば、第１のクライアント能力プロフィールの組は、ｃｌｉｅｎｔ＿ｔｙｐｅ ｓｃｒｅｅｎ＿ｒｅｓｏｌｕｔｉｏｎ、及びｃｏｕｌｏｒ＿ｄｅｐｔｈという名前のフィールドを有することができる。第１のプロフィールＩＤであるＣＣ１は、１つの例として、ｃｌｉｅｎｔ＿ｔｙｐｅフィールドにおいて“ＰＣ”値、ｓｃｒｅｅｎ＿ｒｅｓｏｌｕｔｉｏｎフィールドにおいて“８００ｘ６００”又は“１０２４ｘ７６８”、ｃｏｌｏｕｒ＿ｄｅｐｔｈフィールドにおいて“１６ビット”を有することができる。さらにもう１つの例として、ＩＤ“ＣＣ２”を有するさらなるクライアントプロフィールの組は、ｃｌｉｅｎｔ＿ｔｙｐｅフィールドにおいて“ＰＤＡ”値、ｓｃｒｅｅｎ＿ｒｅｓｏｌｕｔｉｏｎフィールドにおいて値“２００ｘ３００”、ｃｏｌｏｕｒ＿ｄｅｐｔｈフィールドにおいて“３２ビット”を有することができる。上記の例は、プロフィールの組の生成に貢献できる情報の種類の例を単に示しただけであってこれらの例に限定するものではないこと、及び、デバイスの特性と能力の様々な組合せを有する１つの集合を形成することによって多数の異なったプロフィールを簡単に生成可能であることが理解されることになるであろう。いったん生成されたクライアント能力プロフィールの組は、図２に示されているプロフィールサーバー２６に保存される。プロフィールサーバー２６は、デバイスプロフィールを物理的に保存するように動作する単なるデータベースシステムであるにすぎない。プロフィールサーバー２６は、要求中のユーザーの表示装置特性と保存されているクライアント能力プロフィールの組の比較を決定モジュール１４が行うことを可能にするために決定モジュール１４によってアクセス可能である。
【００４１】
システムは、前述された動作モードにおいて所定の表示装置の特性と値の組合せを各々が有する複数のクライアントプロフィールの組を生成後は、プロフィールサーバー２６内に保存されているクライアント能力プロフィールの組の各々に関する原ソースウェブコンテンツの適合化バージョンを生成するように動作する。この生成は、適合化モジュール１６をトリガーして原ソースウェブコンテンツを適合させて各クライアント能力プロフィールの組とマッチさせることによって実施される。適合化モジュール１６は、通常は各クライアント能力プロフィールの組ごとに別々にトリガーされ、このため、いずれの１つのトリガー時においても、単一のクライアント能力プロフィールの組に対応する単一のウェブコンテンツ適合化バージョンが生成される。以下では、トリガー時における適合化モジュール１６の詳細な動作について説明する。
【００４２】
適合化モジュール１６によって実施される第１のステップは、適合化対象となる原ソースウェブコンテンツの詳細をコンテンツ解析モジュール２０に渡すことによってコンテンツ解析モジュール２０をトリガーすることである。次に、コンテンツ解析モジュール２０は、（開発者／著者によって作られたすべてのウェブコンテンツソースを保存する）コンテンツソース保存領域２２から原コンテンツソースを検索し、検索したコンテンツソースをｘＨＴＭＬファイルに変換するためにコンテンツ整理モジュール１８に渡す。コンテンツ整理モジュール１８の機能は、マークアップ言語（ウェブコンテンツ）の構造を整理してｘＨＴＭＬ構造フォーマットに変換することである。ｘＨＴＭＬフォーマットは、コンテンツ解析モジュール２０が解析タスクを実施するための整理整頓された構造を提供する。コンテンツ整理モジュール１８は、優先権主張日においてhttp://tidy.sourceforge.net/から入手可能な第三者ソフト（ＴＩＤＹ、等）を用いることによって確保することができる。従って、ここでは、コンテンツ整理モジュール１８の動作についてさらに詳細に説明することはしない。コンテンツ整理モジュール１８は、整理されたｘＨＴＭＬファイルをコンテンツ解析モジュール２０に戻す。
【００４３】
コンテンツ解析モジュール２０は、整理されたウェブコンテンツを受け取り後は、以下のタスクを示されている順序で実施する。
【００４４】
ｉ）該ウェブコンテンツ内の表示オブジェクトの合計の画素と文字及び個々の画素と文字を計算する
ｉｉ）該ウェブコンテンツ内の個々のオブジェクトの機能を検出する（通常はウェブページ内におけるタグである） 例えば、オブジェクトは、スタイルタグ、構造タグ又は表示タグを持つことができる。
【００４５】
ｉｉｉ）構造上の挙動（オブジェクトタグからの情報）に基づいて単一オブジェクトを分類する
ｉｖ）表示オブジェクト表示パターンをマッチングし、これらのパターンを１つにまとめて１つのグループを形成させる（パターンマッチングアルゴリズムを用いる）
これらの4つのタスクは、次のような詳細を有する各々の専用アルゴリズムによって実施される。
【００４６】
第１のタスクに関して、このタスクを実施する目的は、表示オブジェクト（テキスト、画像、等）の画素／サイズを計算することである。このタスクを実施するアルゴリズムは、最初に表示オブジェクトの型を検出する。次に、該アルゴリズムは、異なった型の表示オブジェクトに関して異なった解析ロジックを適用する。例えば、表示オブジェクトがテキストオブジェクトである場合は、該アルゴリズムは、長さ、フォントのスタイル及びサイズを入手し、これらの入力項目に基づいて画素を計算する。表示オブジェクトが画像／アプレット／オブジェクトである場合は、該アルゴリズムは、該オブジェクトの幅と高さに基づいて総画素数を計算する。その他の表示オブジェクトに関しては、該アルゴリズムは、該オブジェクトのパラメータ内において設定された幅、高さ及び／又は幅／高さの各属性に基づいて総画素数を計算する（該パラメータがＨＴＭＬコンテンツにおいて指定されている場合）。このアルゴリズムによって実施される正確なステップを図３に示し、以下において説明する。
【００４７】
図３において、ステップ３．２においてアルゴリズムによって実施される第１のステップは、整理されたウェブコンテンツ内の個々の表示オブジェクトを検出する。次に、ステップ３．４において、検出された表示オブジェクトがテキストであるかどうかを決定するための評価が行われる。この評価が肯定応答を返した場合（即ち、検出された表示オブジェクトがテキストであることが決定された場合）は、ステップ３．６において、表示オブジェクト内のすべてのテキストストリングの長さが入手される。次に、ステップ３．８において、すべてのテキストストリングに関してテキストタグが生成され、ステップ３．１０において、ステップ３．６で決定されたテキストストリング内の文字数が該テキストタグの属性として設定される。
【００４８】
次に、ステップ３．１２において、すべてのテキストストリングのフォントとスタイルが決定され、次にステップ３．１４において、すべてのテキストストリングのサイズも決定される。ステップ３．１６において、この情報を用いて、フォント、スタイル性、及びサイズの各属性に基づくテキストストリングの高さ及び幅が計算され、これらの計算された高さ値及び幅値は、ステップ３．１８において各ストリングに関するテキストタグのさらなる属性として設定される。これで、テキストであると決定された特定の表示オブジェクトに関するプロセスはステップ３．５０において終了し、該プロセスは、ウェブコンテンツ内の次の表示オブジェクトを検出するためにステップ３．２において再開する。すべての表示オブジェクトがアルゴリズムによって処理された時点で、該アルゴリズムは繰り返されない。
【００４９】
再度ステップ３．４において、検出された表示オブジェクトがテキストでないことが決定された場合は、検出された表示オブジェクトが画像、アプレット、又はオブジェクトであるかどうかを決定するための第２のプロセスがステップ３．２０において実施される。この評価が肯定応答を返した場合（即ち、表示オブジェクトが画像、アプレット、又はオブジェクトである場合）は、処理は、ステップ３．２２に進み、ステップ３．２２においてさらなる評価が実施され、画像、アプレット、又はオブジェクトの幅が指定されているかどうかが決定される。該幅が指定されている場合は、処理は、ステップ３．２４に進む。該幅が指定されていない場合は、処理は、ステップ３．２８に進み、ステップ３．２８において、該オブジェクトの原幅が決定され、その後に同じくステップ３．２４に処理が進む。
【００５０】
ステップ３．２４において、検出された画像、アプレット又はオブジェクトの高さが指定されているかどうかを決定するためのさらなる評価が実施される。この評価が肯定応答を返した場合は、処理は、ステップ３．２６に進む。反対に、ステップ３．２４の評価が否定応答を返した場合は、処理は、ステップ３．３０に進み、ステップ３．３０において、該オブジェクトの原高さが決定される。次に、処理は、ステップ３．３０からステップ３．２６に処理が進む。
【００５１】
ステップ３．２６において、前述されたステップによって決定された画像、アプレット、又はオブジェクトの幅属性及び高さ属性が、ウェブコンテンツ内のオブジェクトタグの幅属性及び高さ属性として設定される。該設定後、該特定の表示オブジェクトの処理は、ステップ３．５０において終了する。この場合も、さらなるオブジェクトを処理する必要がある場合は、処理は、ステップ３．２において再開する。
【００５２】
再度ステップ３．２０において、実施された評価の結果、検出された表示オブジェクトが画像、アプレット、又はオブジェクトでないことが決定された場合は、処理は、ステップ３．３２に進み、ステップ３．３２において、検出された表示オブジェクトの幅及び高さが指定されているかどうかに関する評価が実施される。該幅及び高さが指定されている場合は、処理は、ステップ３．３４に進み、ステップ３．３４において、該指定された幅及び高さが、検出された表示オブジェクトに関する各制御タグのスタイル属性内のパラメータとして設定される。これで、該処理は、ステップ３．５０において終了し、前述のように必要な場合は繰り返すことができる。
【００５３】
ステップ３．３２において、幅及び高さのいずれも指定されていないと決定された場合は、処理は、ステップ３．３６に進んでさらなる評価が実施される。ステップ３．３６においては、検出された表示オブジェクトのサイズが指定されているかどうかが決定される。該サイズが指定されている場合は、処理は、ステップ３．３４に進み、ステップ３．３４において、該サイズは、該オブジェクトに関する各制御の型のスタイル属性内のパラメータとして設定される。その後、処理は、同じくステップ３．５０に進み、ステップ３．５０において終了する。しかしながら、処理すべきさらなる表示オブジェクトが存在する場合は処理を繰り返すことができる。
【００５４】
最後に、ステップ３．３６における評価が否定応答を返した場合は、検出された表示オブジェクトの値が指定されているかどうかを決定するための最終評価がステップ３．３８において実施され、該値が指定されている場合は、該指定値は、ステップ３．３４において、該オブジェクトに関する各制御の型のスタイル属性内のパラメータとして設定される。反対に、該値が指定されていない場合は、処理は、ステップ３．４０に進み、ステップ３．４０において、各制御のディフォルトの幅及び高さがメモリから検索され、ステップ３．３４においてこれらの値がディフォルト値として設定される。
【００５５】
以上のように、このアルゴリズムは、整理されたウェブコンテンツ内の各表示オブジェクトに関して、サイズパラメータ（例えば、テキストストリングの長さ、又は画像の幅と高さ、等）を決定するように動作する。この情報は、後述されている適合化プロセスにおいて用いることができる。
【００５６】
第２のタスクに関して、以下において説明するように、該タスクを実施するためのさらなるアルゴリズムが提供される。
【００５７】
第２のタスクを実施するアルゴリズムは、最初に、マークアップ言語の観点から単一オブジェクトの機能カテゴリを予め定義する。単一オブジェクト（Ｏ）は、マークアップ言語内に埋め込まれた要素であり、表示スタイル、静的スタイル、動的スタイル、構造上のスタイル、等の自己のプロパティを有する。
【００５８】
本出願明細書では、下記の予定義カテゴリを定義している。
【００５９】
情報（Ｉ）
情報タイトル（Ｔ）
制御（Ｃ）
装飾（Ｄ）
交換可能ナビゲータ（ＲＮ）
交換不能ナビゲータ（ＵＮ）
交換可能ナビゲータタイトル（ＲＮＴ）
交換不能ナビゲータタイトル（ＵＮＴ）
これらの機能カテゴリの定義は以下のとおりである。
【００６０】
情報（Ｉ）−情報としての表示コンテンツを提供するオブジェクトであり、重要でかつ交換不能である。このオブジェクトは、テキスト、画像、映像、音声又はあらゆるオブジェクト（ＪＡＶＡ（登録商標）アプレットフィルタ、等）ファイルであることができる。
【００６１】
情報タイトル（Ｔ）−情報オブジェクトについて記述するオブジェクトであり、情報プロパティを有するテキストヘッダー又は画像であることができる。
【００６２】
制御（Ｃ）−ユーザーとの対話を目的とするオブジェクトであり、ボタン（ラジオボタン又はサブミットボタン）、入力テキストエリア、書式、ドロップダウンメニュー、チェックボックス、リストボックス、等である。
【００６３】
装飾（Ｄ）−情報上の役割は果たさず、視覚効果向上専用のオブジェクト。このオブジェクトは、画像又はテキストであることができる。
【００６４】
交換可能ナビゲータ（ＲＮ）−ナビゲータは、ＵＲＩリンクオブジェクトである。交換可能ナビゲータは、代替テキストに代えることができるナビゲータオブジェクトである。交換可能ナビゲータは、代替テキストを備えた画像でなければならない。
【００６５】
交換不能ナビゲータ（ＵＮ）−前述したように、ナビゲータは、ＵＲＩリンクオブジェクトである。このため、交換不能ナビゲータは、代替テキストに代えることができないナビゲータオブジェクトである。交換不能ナビゲータは、代替テキストのないテキスト又は画像であることができる。
【００６６】
交換可能ナビゲータタイトル（ＲＮＴ）−交換可能ナビゲータタイトルは、ナビゲータオブジェクトについて記述する情報用ＵＲＬリンクオブジェクトである。交換可能ナビゲータタイトルは、代替テキストに代えることができる。交換可能ナビゲータタイトルは、代替テキストを備えた画像でなければならない。
【００６７】
交換不能ナビゲータタイトル（ＵＮＴ）−交換不能ナビゲータタイトルは、ナビゲータオブジェクトについて記述する情報用ＵＲＬリンクオブジェクトである。交換不能ナビゲータタイトルは、代替テキストに代えることができない。交換不能ナビゲータタイトルは、代替テキストのないテキスト又は画像であることができる。
【００６８】
上記のような予め定義された機能カテゴリを提供することによって、アルゴリズムは、マークアップ言語（ＨＴＭＬ、等）内に埋め込まれた単一オブジェクトのプロパティを解析する走査・比較メカニズムを開始させる。該解析の推論は、図４に示されている決定ツリー（走査・比較ロジックシーケンス）に基づいて行われる。
【００６９】
アルゴリズムは、最初に、ウェブコンテンツマークアップ言語を上から下に走査する。走査プロセスが開始されると、マークアップ言語のすべての単一オブジェクトが探索されて検出され、予め定義された機能カテゴリと比較される。この比較プロセスは、マークアップ言語の最後まで実行される。
【００７０】
走査ループ内において、アルゴリズムは、単一オブジェクトを探索し、該オブジェクトが有するプロパティに基づいて機能を決定する。アルゴリズムは、第１の単一オブジェクト（Ｏｎ）が特定の機能カテゴリに属することが認定された後に、単一オブジェクトＯｎのプロパティの比較を停止して次の単一オブジェクト（Ｏｎ＋１）を探索する。
【００７１】
図４において、アルゴリズムによって適用される決定ツリープロセスは次のとおりである。即ち、アルゴリズムは、最初に単一オブジェクトを探索する。単一オブジェクト４０が検出された時点で、アルゴリズムは、ステップ４．２において、該検出された単一オブジェクトはハイパーリンクプロパティが埋め込まれているかどうかを検査する。
【００７２】
該単一オブジェクトがハイパーリンクプロパティを有する場合は、ステップ４．４において検査が行われ、該単一オブジェクトに関する代替テキストが存在するかどうかを確かめることによって該オブジェクトが交換可能であるかどうかを決定する。（ステップ４．６における決定に従って）このオブジェクトに関する代替テキスト及びタイトルプロパティが存在する場合は、このオブジェクトは、交換可能ナビゲータタイトル（ＲＮＴ）４８として分類される。このオブジェクトに関する代替テキストは存在するがタイトルプロパティは存在しない場合は、アルゴリズムは、このオブジェクトを代替可能ナビゲータ（ＲＮ）４６として分類する。
【００７３】
このオブジェクトに関する代替テキストが存在せずタイトルプロパティが存在する場合は、アルゴリズムは、このオブジェクトを交換不能ナビゲータタイトル（ＵＮＴ）５２として分類する。このオブジェクトに関する代替テキストが存在せずさらにタイトルプロパティも存在しない場合は、アルゴリズムは、このオブジェクトを交換不能ナビゲータ（ＵＲＮ）５０として分類する。この区別は、ステップ４．１６において評価が行われる。ＲＮＴ及びＵＮＴのタイトルプロパティは、下記の条件に基づいて決定される。
【００７４】
タイトルヘッダープロパティを有する
表示オブジェクトである
URIハイパーリンク（画像又はテキスト）でなければならない
隣接する表示オブジェクトと比較して異なったスタイルを有する
ステップ４．２、４．４、４．６、及び４．１６においてオブジェクトとハイパーリンクプロパティを比較後において、該オブジェクトが依然として分類されていない場合は、本発明は、検査ロジックの対象を非ハイパーリンクプロパティにする。ユーザー側対話プロパティが次の比較対象になる。単一オブジェクトがユーザー側対話プロパティを有するかどうかを決定する要因は、単一オブジェクトが、ボタン（ラジオボタン又はサブミットボタン）、入力テキストエリア、書式、ドロップダウンメニュー、チェックボックス、又はリストボックスのうちのいずれか１つであるかどうかであり、この旨の評価がステップ４．８において行われる。
【００７５】
単一オブジェクトがユーザー側対話プロパティを有することがステップ４．８において検出された場合は、該単一オブジェクトは、制御（Ｃ）４２として分類される。該単一オブジェクトがユーザー側対話プロパティを有することがステップ４．８において検出されない場合は、アルゴリズムは、ステップ４．１０において、映像プロパティ、クラスオブジェクトプロパティ又は音声プロパティを有するオブジェクトであるかどうかをさらに比較する。該プロパティを有するオブジェクトである場合は、この単一オブジェクトは、情報（Ｉ）機能カテゴリ４４の中に含められる。
【００７６】
該単一オブジェクトがまだ分類されていない場合は、アルゴリズムは、ステップ４．１２において、該単一オブジェクトが有していた装飾プロパティが存在するかどうかを決定することによって該単一オブジェクトをさらに検査する。装飾プロパティに関する決定は、以下の基準に基づいて行われる。
【００７７】
単一オブジェクトのサイズ−単一オブジェクトのサイズは、装飾プロパティのサイズを最も良く表している実験値から導き出される。
【００７８】
現在の単一オブジェクト（Ｏｎ）と次の単一オブジェクト（Ｏｎ＋１）との間における記号、ライン及びセパレータの存在
オブジェクトのサイズ（幅及び高さ）は、実験値（主観値）に基づいたサイズである。発明者は、１００のウェブページを対象にした実験的試験を行い、これらの試験結果では、画素サイズの幅が＜＝２０、高さが＜＝２０である画像は装飾オブジェクトである傾向があることが示された。
【００７９】
現在の単一オブジェクトが上記の条件を満たしている場合は、装飾（Ｄ）機能５４として分類される。単一オブジェクト内で装飾プロパティが見つからない場合は、本発明は、ステップ４．１４において、情報タイトルプロパティの有無をさらに検査する。
【００８０】
ステップ４．１４において、単一オブジェクトが装飾プロパティを有していないことが決定された時点で、情報機能又は情報タイトル機能として分類される。単一オブジェクトは、以下の判定基準を満たしている場合のみに情報タイトル（ＩＴ）５８として認定される。
【００８１】
タイトルヘッダープロパティを有する
表示オブジェクトである
テキスト又は画像のみであることができる
隣接する表示オブジェクトと比較して異なったスタイルを有する
単一オブジェクトがタイトルプロパティを有していないと決定された場合は、情報（Ｉ）機能５６として分類される。
【００８２】
従って、上記から明らかになるように、このアルゴリズムによって実施された走査プロセス及び比較メカニズムに基づき、整理されたウェブコンテンツ内のすべての単一オブジェクトは、マークアップ言語内における役割を表すための割り当てられた特定機能を含み、従って、コンテンツ解析モジュール２０によって実施された第２のタスクを実行する。
【００８３】
第３のタスクに関して、コンテンツ解析モジュール内にはこのタスクを実行するためのさらなるアルゴリズムが提供されている。この第３のアルゴリズムの目的は、コンテンツを位置決定情報に基づいてクラスタに分類することである。この情報を表しているのは構造タグである。我々が認識して選択した構造タグは以下のとおりである。
【００８４】
＜ＴＡＢＬＥ＞、＜ＦＯＲＭ＞、＜ＦＲＡＭＥＳＥＴ＞、＜ＤＩＶ＞、＜ＵＬ＞、＜ＯＬ＞、＜ＤＬ＞、＜Ｐ＞、＜ＰＲＥ＞、＜ＡＤＤＲＥＳＳ＞、＜ＢＬＯＣＫＱＵＯＴＥ＞、＜Ｈｎ＞、＜ＨＲ＞、＜ＣＥＮＴＥＲ＞、＜ＭＥＮＵ＞、＜ＤＩＲ＞、＜ＴＤ＞及び＜ＮＯＳＣＲＩＰＴ＞
これらの構造タグをオブジェクトクスタリング用のタグとして選択した理由は、オブジェクトをクライアントブラウザー上において表示時にこれらのオブジェクトをビジュアル的に１つにまとめることができるためである。
【００８５】
このタスクを実行するアルゴリズムの動作は単純である。即ち、ウェブコンテンツを構文解析し、上記のタグのうちのいずれかがオブジェクト内に存在するかどうかに基づいてオブジェクトを選択して分類するだけである。
【００８６】
第４のタスク（即ち、表示オブジェクト表示パターンをマッチングし、これらのパターンを分類して１つのグループにまとめるタスク）に関して、次に説明するパターンマッチングアルゴリズムが提供される。
【００８７】
ウェブページは、幾つかのコンテンツチャンク（ｃｈｕｎｋ）を具備すると考えることができる。これらのチャンクは、該当する特定エリア又はタスクに関連するマルチメディアオブジェクトの集合である。基本オブジェクトは、単一のマルチメディア要素（例えば、画像又はテキスト本体）を含むオブジェクトであると定義し、複合オブジェクトは、幾つかの一定の機能をまとめて遂行する一組のオブジェクト（基本オブジェクト又は複合オブジェクト）であると定義すると、１つのチャンクはそれ自体が高位の複合オブジェクトである。ウェブページを幾つかのより小さいページに分割時に理解可能であるためには、コンテンツチャンクが破壊されていないことが重要である。従って、コンテンツを適合させる前に、ページを構成するマルチメディアオブジェクトを可能性のあるチャンクグループに分類する必要がある。
【００８８】
マイクロソフト・リサーチ社のヤン及びチャンは、２００１年に開催された第６回国際ドキュメント解析・認識会議（ＩＣＤＡＲ２００１）において発表したYang, Y. and Zhang, H.J. "HTML Page Analysis Based on Visual Cues"（ビジュアルキューに基づくＨＴＭＬページ解析）の中で、これらのコンテンツチャンクの所在位置を突き止めるシステムについて説明している。以下では、該システムに類似するシステムについて概説する。両システムとも、ＨＴＭＬタグを使用し、マルチメディアオブジェクトの最初の分類を行って可能な複合オブジェクトグループにまとめ、その後にパターンマッチングを実施してさらに可能な分類を見つけ出す。これらのシステム間の相違点は、様々なオブジェクトの類似性を決定するために用いられる距離基準及びパターンマッチングアルゴリズムである。
【００８９】
最初のオブジェクト分類
マルチメディアオブジェクトの最初の分類を行って可能な複合オブジェクトにまとめる前に、HTMLドキュメントの構文解析が行われてｘＨＴＭＬツリーが構築され、ＨＴＭＬタグのクリーンアップ及び処理しやすい構造の形成が行われる。該ｘＨＴＭＬツリーでは、ＨＴＭＬタグが節部（ノード部）に、マルチメディアオブジェクトが葉の部分に存在している。
【００９０】
次のステップは、葉がマルチメディアオブジェクトを含みノードが複合オブジェクト（このため、可能なコンテンツチャンク）を示しているグループツリーを、ウェブページ全体を示す最上ノードまで構築することを含む。ｘＨＴＭＬツリーは、コンテンツ内における自然の区切りと関係する予め定義された一組のＨＴＭＬタグ（主に、＜ｔａｂｌｅ＞、＜ｔｄ＞、＜ｆｏｒｍ＞、＜ｃｅｎｔｅｒ＞及び＜ｈ＞、等のブロックレベルのタグ）の真上に＜ｇ＞タグを最初に挿入することによってグループツリーに変換される。次に、一組のトークン（各型のマルチメディアオブジェクトごとに１つ）が、組になった属性（例えば、テキストストリング内の文字数、又は画像の幅と高さ）とともに定義される。次に、グループツリー内の葉部のマルチメディアオブジェクトから上方に向かってトークンが渡され、葉及び＜ｇ＞タグを含むノード以外のすべてのノードが削除される。トークンは、上方に渡されるときにノードと関係する属性を蓄積させ、１つのノードが２つ以上の子を有する場合は、すべての子が該ノードと関係する属性を受け取る。幾つかのフォーマット化タグ（＜ｔｒ＞、等）は、マルチメディア要素上にどのような属性も置かず、さらに、予め定義された組内のタグとは異なり通常は新しいコンテンツチャンクを示していないため無視される。＜ｇ＞タグノードが２つ以上の子を有する場合は、これらのトークンは、左から右に配置されている子ノードの順序と同じ順序で線形リスト内に配置される。
【００９１】
様々なブロックレベルのタグと関連するオブジェクト（テーブル、セル、等）に可能なグループとしてのラベルを付けることによって、グループツリーは、複合オブジェクト（そしてその結果としてのコンテンツチャンク）の大部分を既に組み入れている。この技術は、常に正確なわけではないが、＜ｇ＞タグはどのようなコンテンツチャンクも分割しないと想定している。しかしながら、フォーマット化オブジェクトのコンテンツにラベルを付けることは、類似のマルチメディアオブジェクトの配置を繰り返すことを通じて黙示されているコンテンツチャンクどおしを区別するわけではない。従って、グループツリーがいったん導き出された時点で、各＜ｇ＞ノードの子ノードに属するトークンリスト上においてパターンマッチングが行われる。
【００９２】
パターンマッチング
パターンマッチングプロセスにおける第１のステップは、各々の子ノード内のトークンリストのうちのどのトークンリストが類似しているかを決定することである。各トークンは、該トークンと関係する一組の属性を有することに注意すること。各属性は、型と値の対、例えば（フォント、１４ｐｔ）及び（幅、１００）を含む。これらの値は、ストリング又は整数であることができる。属性型が関係する値を本質的に有していない場合は、この値は、ヌルストリング、例えば（ボールド，）に設定される。トークンを比較時に、いずれかの特定のトークンが該トークンと関係する属性を有していない場合は、該トークンは、属性の組が空でないようにするために特別のヌル属性（ ，）が割り当てられる。
【数１】
【００９３】
トークンリストの比較は、動的時間ワープ（動的ブログミングアルゴリズム）によって実施され（表１参照）、整合経路は、（最小トークンの長さに比例する）所定の数の場所を超えて対角線から外れることが許容されておらず、更に、非対角の動きに関する罰則も組み入れている。整合経路に沿った類似性基準の和がしきい値よりも大きい場合は、２つのトークンリストは、同一であることを理由に、又は長さと組成の点が少々異なっているにすぎない場合に、類似しているとみなされる。
【表１】
【００９４】
パターン検出時には、より低い三角マトリクス（対角要素がないもの）が最初に構築され、子ノード（トークンリスト）のうちのいずれが互いに類似しているかが詳述される。次に、すべての可能なパターンを検討することによって、最大数の子ノードを網羅した類似ノードの繰り返しシーケンスである有意トークンパターンが見つけ出される。この有意トークンパターンは、各新グループの始まりを示している。
【００９５】
意味のない有意トークンパターンが出現するのを防止するために以下のような幾つかの制限条件が適用される。
【００９６】
該パターンは、長さが少なくとも２つの子ノードでなければならない
該パターンは、少なくとも２回繰り返されなければならない
同じパターンのインスタンスが重複しないこと
これらの有意トークンは、グループ（又はコンテンツチャンク）の始まりを示しているため、これらのグループ間で重複しないようにしさらに妥当な類似性を確保しながら後続する子ノードをこれらのグループ内に加えることによって、これらのグループ自体が拡大される。
【００９７】
上記の結果、コンテンツ解析モジュール２０によって実行された４つのタスクが終了することになる。これらのタスクを実行後は、システムは、検索されたウェブページコンテンツに基づいてＸＭＬツリーを構築していることになる。このツリーは、ウェブコンテンツに関する様々な追加情報を含み、現時点では、適合化モジュールに引き渡すのに適したフォーマットになっている。このプロセスによって提供されている情報は、下記の項目に関連する情報である。
【００９８】
ｉ）適合化中に分離されることが想定されていない分割不能なグループ（即ち、上記の「チャンク」）
ｉｉ）グループ及び単一オブジェクトの機能（無視又は削除できるかどうかを示す）
ｉｉｉ）コンテンツソースの総表示画素数及び文字数（コンテンツをより小さいページに分割すべきかどうか/どのように分割するかを決定時に適合化モジュールによって用いられる）
ｉｖ）コンテンツソースの原構造情報及び原スタイル情報 ここでの構造は、コンテンツのレイアウトを意味する。構造情報は、コンテンツの配備方法及び位置決め方法に関するコードを含む。スタイルは、コンテンツのオブジェクト（テキスト又は画像、等）の幅、高さ、色、フォント属性（フォントの種類と大きさ）、等を意味する。
【００９９】
このプロセスによって生成されたＸＭＬツリーのフォーマットは、現時点においては、別個のウェブページ上において表示するためにコンテンツのどの箇所を分割することが許容されているかを識別する識別子（＜ｇ＞タグと呼ばれる）を含む。＜ｇ＞タグは、前述されているように、コンテンツ内における自然の区切り（例えば、＜ｔａｂｌｅ＞、＜ｔｄ＞、＜ｆｏｒｍ＞、等のブロックレベルタグ）及びひとつにまとめて表示すべきである該当コンテンツグループの両方に基づいて複数の＜ｇ＞タグが挿入されている。階層ツリーフォーマットでは、これらの＜ｇ＞タグがツリーの分割可能な箇所を示す幾つかのノードを形成していて、従って最下位の＜ｇ＞タグ（即ち、葉に最も近い＜ｇ＞タグ）はそれよりも下方ではコンテンツ分割が許容されていないノード（即ち、異なったウェブページにわたって広げることができない分割不能なコンテンツグループ）であることを意味している。
【０１００】
ＸＭＬツリーの追加の側面として、ＸＭＬツリーは、第２の型の識別子を含む。これらの識別子は、個々のコンテンツオブジェクト（即ち、画像又はテキスト本体等の単一マルチメディア要素）又は複合オブジェクト（一定の機能をいっしょに果たす一組のオブジェクト）のいずれかのオブジェクトと関連するラベルである。類似しているオブジェクト、例えば、型が同じでありさらにスタイル属性とその他の特性（画像サイズ又はテキスト文字数、等）のリストが類似しているオブジェクトは、同じ識別子タグが付けられる。（後述する）適合化プロセス中は、これらのラベルは、類似するオブジェクトをウェブページ上で表示するために処理中にこれらのオブジェクトが同じに取り扱われる（例えば、すべての類似画像／テキストボックスが同じ率で縮小される）ようにするために用いられる。
【０１０１】
既述されているように、コンテンツ解析モジュール２０は、現時点において、解析結果（ＸＭＬツリーの結果）を適合化モジュール１６に引き渡す。次に、適合化モジュール１６は、プロフィールサーバー２６から入手可能な（そしてこの動作モードで予め生成された）すべてのクライアント能力デバイスプロフィールを検索する。次に、適合化モジュール１６は、入手可能なプロフィールに基づいて異なったウェブコンテンツバージョンを生成するアルゴリズムを実行するループをトリガーする。実施されるループ数は、入手可能なプロフィール数に依存する。基本的には、各クライアント能力プロフィールごとにコンテンツ適合化バージョンが生成される。
【０１０２】
コンテンツを適合させるためにＸＭＬツリー上で動作するアルゴリズムは、図５及び６の流れ図に示されている。図５は、コンテンツが表示装置に関する現在のプロフィール範囲内に納まるかどうを検査するアルゴリズムを示している。このアルゴリズムは、幾つかの段階を循環的に実施し、コンテンツがページ（即ち、表示装置）に適合するかどうかを毎回検査する。適合しない場合は、該アルゴリズムは、幾つかの変換を実施してコンテンツのサイズを漸進的に縮小する。図５のアルゴリズムは、図６に示されているアルゴリズムの全段階のうちの１つだけを形成しており、（必要な場合に）コンテンツを分割して複数の異なったページ上に置くようにさらに動作する。
【０１０３】
最初に図６のアルゴリズムに関して、このアルゴリズムの目的は、コンテンツが大きすぎるため所定の表示装置の単一ページ上に表示できない場合は該コンテンツをより小さいページに分割しその一方でこれらのページ上に存在する空白スペース量を最小限にすることである。該アルゴリズムは、該分割を行うために、ＸＭＬツリー構造内の＜ｇ＞タグを使用する。該アルゴリズムは、最上位の＜ｇ＞ノードを出発点としてツリー全体にわたってノードからノード（＜ｇ＞ラベルが貼付されたノード）へ移動する。該アルゴリズムは、各ノードにおいて、下方のサブツリー内のコンテンツが表示装置に適合するかどうかを計算し、マルチメディアオブジェクトの変換（フォントサイズ／画像サイズの縮小、等）を適宜行う。現在の＜ｇ＞ノードの下方のコンテンツが表示装置に適合しない場合は、該アルゴリズムは、下方の子＜ｇ＞ノードに移動し、ウェブページ全体が複数のより小さいウェブページとして出力されるまでこれらの子＜ｇ＞ノードの各々に関する再計算を実施する（必要な場合はさらに分割する）。
【０１０４】
さらに詳細に説明すると、図６において、該アルゴリズムによって実行されるステップは次のとおりである。２箇所の一時的保存領域（スタック“Ｑ”及び“Ｔ”）は、処理中にこれらのノードを一時的に保存するために用いられる。第３の保存領域であるアレイ“Ｔｒａｎｓ”は、ウェブページ内の様々なオブジェクトに関して実施される変換（フォントサイズ又は画像サイズの縮小、等）に関連するデータを保存するために用いられる。
【０１０５】
適合化アルゴリズムは、ステップＳ６．１から開始する。最初に、該アルゴリズムは、最上位の＜ｇ＞ノードをツリーから取り出してスタックＱの中に入れる（ステップＳ６．２）。該アルゴリズムは、一時的スタックＴがクリアされていることも確認する（ステップＳ６．３）。次に、該アルゴリズムは、ステップＳ６．４に移動し、ステップＳ６．４において、以下においてさらに詳細に説明されている関数ｆｉｔｓ＿ｐａｇｅ（Ｔ，Ｔｒａｎｓ）を呼び出し、Ｔ内に現在保存されている＜ｇ＞ノードがクライアントディスプレイ内に納まるかどうかを検査し、マルチメディアオブジェクトに関する変換を適宜実施する。しかしながら、この時点ではスタックＴは空であるため、ｆｉｔｓ＿ｐａｇｅ（Ｔ，Ｔｒａｎｓ）はＴＲＵＥを戻す。処理は、ステップＳ６．５に進み、ステップＳ６．５において、関数ａｒｅ＿ｓｉｂｌｉｎｇｓ（Ｔ）を用いて、スタックＴ内のすべてのノードが同じ親を有するかどうかを検査する。同じくＴは空であるため、該関数はＴＲＵＥを戻して処理をステップＳ６．６に進ませ、ステップＳ６．６において、スタックＱ内にノードが残っているかどうかを検査する。Ｑ内にはノードが存在するため（最上位の＜ｇ＞ノードは現在はＱ内にある）、処理はステップＳ６．７に進み、ステップＳ６．７において、スタックＱの最上位からスタックＴ上にノードを移動させ、処理は、ステップＳ６．４に戻る。
【０１０６】
この時点では、ツリーの最上位＜ｇ＞ノードはスタックＴ内にあり、このため、ステップＳ６．４は、関数ｆｉｔｓ＿ｐａｇｅ（Ｔ，Ｔｒａｎｓ）を用いて、このノード（即ち、その下方にある全サブツリーのウェブコンテンツ）がクライアントデバイスのディスプレイ内に納まるかどうかを検査し、オブジェクトに関する変換を適宜実施する。このステップは、図５に示されているアルゴリズムを含む。この段階においては、該アルゴリズムは、（スタックＴ内に現在保存されているノードは最上位ノードであるため）ウェブページコンテンツ全体が表示装置内に納まるかどうかを検査中である。コンテンツが表示装置内に納まることができる大きさである場合は、該アルゴリズムは、ステップＳ６．５を通ってステップＳ６．６に進んで終了する。スタックＱ内にはノードが残っていないため、プロセスは、ステップＳ６．１５に飛び越し、ステップＳ６．１５において、（関数ｒｅｎｄｅｒ（Ｔ，Ｔｒａｎｓ）の呼び出しを用いて）ツリー全体を出力して終了する。
【０１０７】
しかしながら、ウェブページコンテンツ全体が表示装置内に納まらない場合は、ステップＳ６．４の答えはいいえ（Ｎ）であり、処理は、ステップＳ６．８に進み、ステップＳ６．８において、最上位ノードをスタックＴから取り除いてノードＮとして保存する。次に、ステップＳ６．９において、スタックＴには依然としてノードがないため、処理は、ステップＳ６．１０に進み、ステップＳ６．１０において、ノードＮが葉であるかどうかを検査する。この段階では（ノードＮは最上位＜ｇ＞ノードであるため）答えはいいえ（Ｎ）であり、このため、処理は、ステップＳ６．１１に進み、ステップＳ６．１１において、ノードＮのすべての直接的な子＜ｇ＞ノードを処理するためにスタックＱ上に置く。次に、ステップＳ６．１２は、処理すべきノードがスタックＱ内に存在するかどうかを検査する。この段階では、ＸＭＬツリーの最上位ノードのすべての直接的子＜ｇ＞ノードがスタックＱ内にあり、このため、処理は、ステップＳ６．３に戻り、一時的スタックＴをクリアする。
【０１０８】
次に、処理は、ステップＳ６．４、Ｓ６．５、Ｓ６．６及びＳ６．７内を進み、直接的子ノードのうちの第１の子ノードをスタックＱからスタックＴに移動させる。ウェブコンテンツのうちでクライアント表示装置内に納まる大きさである（即ち、ステップＳ６．４がＴＲＵＥを戻す）のはこの部分（即ち、この子ノードの下方のサブツリー内のコンテンツ）である。この場合は、処理は、ステップＳ６．４、Ｓ６．５、Ｓ６．６及びＳ６．７内を再び通り、スタックＱの第２の子ノードをスタックＴに加える。このプロセスは、無期限に繰り返され、ウェブコンテンツのうちのこの結合部分（即ち、スタックＴに加えられた全ノード部分）が依然としてクライアントディスプレイ内に納まるかどうかを毎回検査する。いずれかの時点においてソースコンテンツ（即ち、Ｔ内のノードリストによって表されている現在のコンテンツ部分）がディスプレイに適合しない（即ち、ステップ６．４における答えがいいえである）場合は、処理はステップＳ６．８に進み、ステップＳ６．８において、スタックＴに加えられた最後のノード（該スタックにおいて最高位のノード）がスタックＴから取り除かれてノードＮとして保存される。次に、ステップＳ６．９は、スタックＴ内にノートがまだ残っているかどうかを検査し、残っている場合は、処理はステップＳ６．１３に進み、ステップＳ６．１３において、ノードＮは、のちに処理するために、最初の保存領域（即ちスタックＱ）に戻される。次に、関数ｒｅｎｄｅｒ（Ｔ，Ｔｒａｎｓ）の呼び出しを用いて、ＸＭＬツリーの１つのセクション（即ち、現在スタックＴ内にあるノードによって表されているコンテンツ）が、適合化されたより小さいページのうちの１つとして出力される。該アルゴリズムは、ステップＳ６．１２に進み、処理するためのノードがスタックＱ内に残っているかどうかを決定する。処理するためのノードがスタックＱ内に残っている場合は、ステップＳ６．３に戻る。
【０１０９】
該アルゴリズムは、図６に示されている全ステップを実行後、ツリー全体にわたって処理を繰り返し、コンテンツを変換してディスプレイに適合させることが可能であるかどうかを（関数ｆｉｔｓ＿ｐａｇｅ（Ｔ，Ｔｒａｎｓ）を用いて）確認し、適合させることができない場合は、該コンテンツをさらに小さく分割する。この分割は、該アルゴリズム内において次のプロセスによって達成される。即ち、ノード下方のコンテンツが表示装置内に納まることができないごとに、ステップＳ６．１１において、その直接的子＜ｇ＞ノードがのちに処理するために別個に保存領域（スタックＱ内の待ち行列）内に加えられる。このプロセスは、コンテンツをより小さい部分に分割し、このため、サブツリーを個々に検査して該コンテンツがクライアントデバイス上に表示するのに適したサイズであるかどうかを確認することができる。次に、ディスプレイに適合するあらゆるコンテンツ部分に関して、ディスプレイ内における空白スペース量を最小限にするために、これらのコンテンツ部分を該コンテンツのその他の部分と結合させることが試みられる（即ち、ステップＳ６．７）。しかしながら、異なったコンテンツ部分のこの結合は、対象ノードが兄弟である（即ち、ツリー内において同じ親＜ｇ＞ノードを有する）場合にしか行われない。このようにして、適合化アルゴリズムは、最上位の＜ｇ＞ノードから最下位の＜ｇ＞ノードの葉（さらなるコンテンツ分割が許容されている最下位の葉）までツリー全体にわたって進行する。
【０１１０】
ＸＭＬツリー内におけるウェブコンテンツ構成が階層ツリー構成であるおかげで、及び、適合化アルゴリズムによって実行されるステップの順序のおかげで、コンテンツ表示時に最上部から最下部に及び左から右に進む順序が維持される。更に、単一ページ上には（同じレベルのグループの）全体的な関連した複合オブジェクトのみが表示されることになる。
【０１１１】
更に、該アルゴリズムは、すべてのより小さいページを通じて類似オブジェクトの表示の一貫性を確保する。この確保は、オブジェクトに関して既に実施されている変換のリストを該オブジェクトと関係するオブジェクトラベル（類似するオブジェクトを示す前述の第２の型の識別タグ）とともに維持する保存領域（例えば、Ｔｒａｎｓと呼ばれるアレイ）を用いることによって達成される。コンテンツの各部分に関して、該アルゴリズムは、類似するオブジェクトに関して実施されている変換が首尾一貫していることを確認するために、アレイＴｒａｎｓを検査してこれらのオブジェクトに対して既に変更が加えられているかどうかを確認する。アレイＴｒａｎｓは、関数ｆｉｔｓ＿ｐａｇｅ（）がコンテンツ部分に関して新たな変換を成功裡に行なってページサイズ内に納まるごとに処理中に動的に更新される。
【０１１２】
上記の適合化アルゴリズムに関する説明全体を通じて、処理中に一時的にノードを保存するために用いられる２つの保存領域（スタック“Ｑ”及び“Ｔ”）を挙げていることを理解すべきである。該アルゴリズムの機能上、これらの保存領域は、これらのノードと関係する適切なコンテンツ部分を保有するとみなすことができる。この場合、これらの保存領域自体は、実際には、メモリの別の部分内におけるコンテンツの保存場所を指し示す単なるメモリアドレスリストとして実装されるにすぎないにもかかわらずこのようにみなすことができる。
【０１１３】
ウェブページを適合させるための適合化アルゴリズム（疑似ジャバコード）の典型的実施形態を以下に示した。
【表２】
【０１１４】
以下の関数がＳｐｌｉｔＰａｇｅ（）によって使用される。
【０１１５】
ｉｓ ｌｅａｆ（Ｎ）
一時的ノードＮが葉である場合にＴＲＵＥを戻す
ａｒｅ ｓｉｂｌｉｎｇｓ（Ｔ）
スタックＴ内のノードが同じ親＜ｇ＞ノードを共有している（又は、Ｔが単一ノードを含むか又は空である）場合にＴＲＵＥを戻す
ｆｉｔｓ ｐａｇｅ（Ｔ，Ｔｒａｎｓ）
スタックＴ内のノード（即ち、これらのノードの下方のすべてのサブツリーのコンテンツ）が表示装置内に納まる上で十分に小さいかどうかを決定する 最初に、スタックＴがＴｒａｎｓ内のノードと同じ識別子ラベルを有するノードを含む場合は、関係する変換がこれらのオブジェクトに関して実施される。これでコンテンツがページに適合する場合は、ｆｉｔｓ ｐａｇｅ（Ｔ，Ｔｒａｎｓ）がＴＲＵＥを戻す。
【０１１６】
しかしながら、コンテンツが依然としてページに適合しない場合は、いくつかの異なった変換をコンテンツに関して実施することができ、これらの変換は、図５に示されている。これらの追加のオブジェクト変換のうちのいずれかを実施した結果コンテンツが表示装置に適合することになった場合は、これらの変換は、該当するオブジェクトラベルとともにアレイＴｒａｎｓに追加され、ｆｉｔｓ ｐａｇｅ（Ｔ，Ｔｒａｎｓ）がＴＲＵＥを戻す。
【０１１７】
代替として、可能であるすべての追加変換を実施後も依然としてソースコンテンツが表示装置に適合しない場合は、ｆｉｔｓ ｐａｇｅ（Ｔ，Ｔｒａｎｓ）はＦＡＬＳＥを戻す。
【０１１８】
関数ｆｉｔｓ ｐａｇｅ（Ｔ，Ｔｒａｎｓ）は、スタックＴが空である場合もＴＲＵＥを戻す。
【０１１９】
ｒｅｎｄｅｒ（Ｎ，Ｔｒａｎｓ）、ｒｅｎｄｅｒ（Ｔ，Ｔｒａｎｓ）
コンテンツの一部分（即ち、ＸＭＬツリーの１つ以上のノードによって表されているコンテンツ）を、適合化されたより小さいページの１つとして出力するために使用する。該関数は、ノードＮとアレイＴｒａｎｓの入力パラメータ、又はスタックＴとアレイＴｒａｎｓの入力パラメータのいずれかを有する。Ｔｒａｎｓは、今日までに提供されているオブジェクト識別子ラベル、及びこれらの識別子ラベルに関係する変換とパラメータを含むため、Ｎ又はＴがＴｒａｎｓ内のラベルと同じラベルを有するオブジェクトを含む場合は、該当する変換がこれらのオブジェクトに関して実施される。残りのオブジェクトは適宜変換され（即ち、空白スペース量を最小限に抑えながら所定の表示装置に適合させ）、これらのラベル及び変換がＴｒａｎｓに加えられる。最後に、Ｔｒａｎｓが該関数によって戻される。
【０１２０】
上述されているように、関数呼び出しｆｉｔｓ＿ｐａｇｅ（Ｔ，Ｔｒａｎｓ）中において、コンテンツがプロフィール範囲（所定の表示装置、等）に適合しない場合は、幾つかの異なった変換を該コンテンツに関して実施することができ、ここでは、図５を参照しつつこれらの変換についてさらに
詳細に説明する。この機能を果たすアルゴリズムは、以下の検査を行う。
【０１２１】
ｉ）ソースコンテンツのすべての画素及び文字をプロフィール範囲内に納めることができるかどうかを検査する
ｉｉ）空白スペース及びラインを取り除いた後にソースコンテンツをプロフィール範囲内に納めることができるかどうかを検査する
ｉｉｉ）表示オブジェクトのプロパティの削除、サイズ変更、要約、及び変更によってソースコンテンツがプロフィール内に納まるかどうかを検査する
これらの検査は、８つの可能な変換によって具体化される。これらの変換は順に実施されるが、各変換を実施後に、所定の表示装置に関するクライアント能力プロフィールを参照することによって、その時点までに変換されたコンテンツを該表示装置上に表示できるかどうかを決定するための評価が行われる。表示可能であると決定された場合は、追加の変換は実施されない。表示不能であると決定された場合は、すべての８つの変換が実施される。
【０１２２】
順に利用可能な変換は以下のとおりである。
【０１２３】
第１の変換： フォントの縮小 “ｖｅｒｄａｎａ”をフォントファミリーとして原フォントをより小さいフォントサイズに変換する
第２の変換： 画像の縮小 画像オブジェクトを１０％だけ縮小し、最適のサイズ又は５０％になるまで繰り返す
第３の変換： 制御オブジェクトの縮小 変換した結果該オブジェクトの最適なサイズよりも大きい場合に、デフォルトの画面の大きさとクライアントデバイスの比に基づいてオブジェクトを縮小する
第４の変換： スペースの削除 段落間の不要なスペースを取り除く
第５の変換： ラインの削除 第４の変換と同じ目的である
第６の変換： 装飾画像の削除 装飾プロパティを有する画像をオブジェクトのサイズに基づいて削除する
第７の変換： 装飾テキストの削除： 装飾として機能する冗長なテキストを取り除く（これらのテキストが特殊文字である場合）
第８の変換： 画像の入れ替え： 画像に代わる代替テキストが存在する場合は、アルゴリズムは、該代替テキストのサイズと画像自体を比較し、短いほうが適合結果として選択される。
【０１２４】
図５は、変換アルゴリズムをより詳細に示した図であり、特に、実施可能な８種類の変換を示した図である。図５において、同図によって提供されている手順は、ステップ５．１において開始され、２つのカウンタが初期設定される。より具体的には、第１のカウンタｉがｉ＝１に初期設定され、第２のカウンタｒがｒ＝０に初期設定される。
【０１２５】
次に、処理はステップ５．２に進み、ステップ５．２において、ウェブコンテンツが所定の表示装置のディスプレイ内に納まるかどうかを決定するための評価が行われる。この評価は、該コンテンツの特徴と、プロフィールサーバー２６のクライアント能力プロフィール内において提供されているクライアントデバイス表示能力特性と比較することによって実施される。特定の適合化されたバージョンを生成する場合は、ステップ５．２において、クライアント能力プロフィールのうちで、適合化アルゴリズムの現在のインスタンス化によって適合化バージョンが生成中である単一のクライアント能力プロフィールと対照する評価が常に実施される。
【０１２６】
ウェブコンテンツが所定の表示装置のディスプレイ内に納まることがステップ５．２における評価によって示され、変換を実施する必要がない場合は、変換アルゴリズムは、ステップ５．３において終了し、関数ｆｉｔｓ＿ｐａｇｅ（）に関してＴＲＵＥを戻す。
【０１２７】
反対に、ウェブコンテンツが所定の表示装置のディスプレイ内に納まらないことがステップ５．２における評価によって示された場合は、処理はステップ５．４に進み、ステップ５．４において、カウンタｉ＝１であるかどうかを決定するための評価が行われる。ここで、アルゴリズムがステップ５．１において初めて開始されたときにはカウンタｉは１に初期設定されるということを思い出されることになり、従って、ステップ５．４における評価は肯定応答を返し、処理はステップ５．６に進む。ステップ５．６においては、フォント縮小を目的とする第１の変換が開始され、ステップ５．８及び５．１０の形になる。
【０１２８】
ステップ５．８において、適合させるウェブコンテンツ内の全テキストに関するフォントサイズが１に設定される。但し、その他の実施形態においては、その他の値を選択することができる。次に、ステップ５．１０において、ウェブコンテンツ内の全テキストに関するフォントの種類が“ｖｅｒｄａｎａ”に設定される。これらのステップは、ウェブコンテンツ内のすべてのテキストオブジェクトのサイズを大幅に縮小する結果になる。処理は、これらのステップ後はステップ５．１２に進み、ステップ５．１２において、カウンタｉの値が１だけ増やされる。次に、処理は、ステップ５．２の評価に戻り、ステップ５．２において、変換されたウェブコンテンツが今度は所定の表示装置のディスプレイ内に納まるかどうかを決定するための評価が行われる。ステップ５．２における該評価が肯定応答を返した場合、即ち、現時点においてウェブコンテンツを所定の表示装置において表示可能である場合は、プロセスは、ステップ５．３に進んで終了する。反対に、さらなる変換を実施する必要がある場合は、処理は、ステップ５．４に進み、ステップ５．４において、カウンタｉ＝１であるかどうかに関する評価が行われる。カウンタｉはステップ５．１２において値が増やされて現在は２になっているため否定値が返され、処理はステップ５．１４における評価に進み、ステップ５．１４において、カウンタｉが２であるかどうかに関する評価を行う。ここでは、肯定値が返され、処理は、ステップ５．１６に進む。
【０１２９】
ステップ５．１６において、画像縮小変換が開始される。画像縮小変換では、最初にステップ５．１８において、該画像に関して可能な最大縮小値が入手される。この最大縮小値は、ハードコード値（例えば５０％）である。次に、ステップ５．２０において、最大縮小値がカウンタｒの値の１０倍よりも大きいかどうかに関する評価が行われる。ここで、ステップ５．１においてカウンタｒの値がゼロに初期設定されたことが思い出されることになり、従って、最初の循環時点では、ステップ５．２０における評価は、肯定応答を返す。次に、処理はステップ５．２２に進み、ステップ５．２２において、ウェブコンテンツ内の画像が１０％だけ縮小される。次に、処理は、ステップ５．２４に進み、ステップ５．２４において、カウンタｒの値が１だけ増やされ、ステップ５．２６に進む。ステップ５．２６において、ｒ＝５であるかどうかに関する評価が行われる。最初の循環時点においては、ｒはステップ５．２４において値が増やされていて１になっており、従って、ステップ５．２６の評価は否定値を返す。この場合は、処理は、直接ステップ５．２に戻り、ステップ５．２において、変換されたコンテンツが所定の表示装置のディスプレイ内に納まるかどうかに関する評価が実施される。変換されたコンテンツが所定の表示装置のディスプレイ内に納まる場合は、処理は、ステップ５．３において終了する。変換されたコンテンツが所定の表示装置のディスプレイ内に納まらない場合は、処理は、ステップ５．４を介してステップ５．１４に進み、ステップ５．１４においては、カウンタｉはまだ数が加えられていないため、肯定応答結果が返され、ステップ５．１８、５．２０、５．２２、５．２４及び５．２６の画像縮小変換が再度実施される。
【０１３０】
図５から明らかなように、画像縮小変換は最高５回実施することができ、各繰り返しにおいて画像縮小変換を実施するごとに画像のサイズがさらに１０％だけ縮小され、他方、利用可能な最大画像縮小値がｒの現在値の１０倍よりも大きくない場合は、利用可能な最大縮小値分だけ縮小される。しかしながら、いずれの場合においても、変換は、カウンタｒ＝５になるまで５回反復的に実施される。カウンタｒ＝５の時点で、ステップ５．６の評価が肯定応答を返し、処理は、ステップ５．１２に進み、ステップ５．１２において、カウンタｉの値が増やされる。処理は、ステップ５．１２からは常にステップ５．２戻り、ステップ５．２において、現時点ではコンテンツが所定の表示装置のディスプレイ内に納まるかどうかに関する評価が行われる。既に実施済みの変換が十分である場合は、この評価は、肯定値を返し、処理は、ステップ５．３において終了する。既に実施済みの変換が十分でなく、さらなる変換が必要な場合は、処理は、ステップ５．４を介して更に今回は（現在はｉ＝３であるため）ステップ５．１５も介してステップ５．３０に進む。
【０１３１】
ステップ５．３０において、カウンタｉが３であるかどうかに関する評価が行われ、カウンタｉが３である場合は、処理は、ステップ５．３２に進み、ステップ５．３２において、制御オブジェクト縮小変換が開始され、ステップ５．３４に進む。
【０１３２】
ステップ５．３４において、ウェブコンテンツに関するデフォルトの画面サイズと所定の表示装置の実際の画面サイズの比が得られる。ステップ５．３６において、この比に基づき、この比をデフォルトサイズに当てはめることによって、各制御オブジェクトのサイズが計算される。次に、ステップ５．３８において、各制御オブジェクトに関する計算されたサイズが各オブジェクトに関する最小許容サイズよりも小さいかどうかに関する評価が行われる。該計算されたサイズが該最小許容サイズよりも小さくない場合は、処理は、ステップ５．４２に進み、ステップ５．４２において、計算された比に基づいて制御オブジェクトのサイズを縮小することができる。しかしながら、該計算されたサイズが各制御オブジェクトの該最小許容サイズよりも小さい場合は、処理は、ステップ５．４０に進み、ステップ５．４０において、ウェブコンテンツ内の制御オブジェクトのサイズが最小許容サイズに基づいて縮小される。該最小許容サイズは、事前に決定される。
【０１３３】
ステップ５．４０又はステップ５．４２の後は、処理は、ステップ５．１２に進み、ステップ５．１２において、カウンタｉの値が増やされる。次に、ステップ５．２に進み、ステップ５．２において、変換されたコンテンツが所定の表示装置のディスプレイ内に納まるかどうかに関する評価が行なわれる。
【０１３４】
ステップ５．２の評価が否定応答を返すと想定した場合、カウンタｉの値は現在は４であり、従って、処理は、ステップ５．４、５．１４及び５．３０を介してステップ５．４４に進み、ステップ５．４４において、ｉ＝４であるという評価が肯定値を返す。この結果は、処理をステップ５．４６に進め、ステップ５．４６において、スペース削除変換が開始される。
【０１３５】
この変換は、ウェブコンテンツ内のオブジェクトタグを検討すること、及び特定のタグを有するオブジェクト及び／又はその他の一定条件を満たしているオブジェクトを削除することに関連する。従って、ステップ５．４８において、タグ＜ＢＲ＞を有していて、タグ＜ＴＤ＞と＜ＤＩＶ＞を持つオブジェクトの最初の子と最後の子であるオブジェクト、が取り除かれる。次に、ステップ５．５０において、タグ＜ＢＲ＞を有していて、タグ＜Ｔａｂｌｅ＞を有するオブジェクトの兄弟であるオブジェクト、も削除される。次に、ステップ５．５２において、ウェブコンテンツ表示オブジェクト内のすべての連続した空白スペースが単一のスペースに減らされ、それに応じて、ステップ５．５４において、ウェブコンテンツ表示オブジェクト内のすべての連続した区切り部分が１つに減らされる。最後に、ステップ５．５６において、＜ｔａｂｌｅ＞オブジェクトのセルパディング及びセルスペーシング値がゼロに減らされる。このスペース削除変換結果、ウェブコンテンツ内の空白スペースが絶対最小値に縮小される。
【０１３６】
ステップ５．５６の後は、処理はステップ５．１２に進み、ステップ５．１２において、カウンタｉの値が５に増やされる。次に、ステップ５．２における評価が実施され、変換されたコンテンツが現在は所定の表示装置のディスプレイ内に納まるかどうかが決定される。変換されたコンテンツが所定の表示装置のディスプレイ内に納まる場合は、処理は５．３において終了する。変換されたコンテンツが所定の表示装置のディスプレイ内に納まらない場合は、処理は、ステップ５．４、ステップ５．１４、ステップ５．３０及びステップ５．４４を介してステップ５．５８に進み、ステップ５．５８において、ｉ＝５であるという評価が肯定応答を返す。その後は、ステップ５．６０において、ライン削除変換が実施され、ステップ５．６２において、＜ＨＲ＞タグを有するすべての表示オブジェクトが削除される。この機能は、本質的に、以前に実施された第４変換と同じ機能、即ち、空白スペースを減らす機能を有する。
【０１３７】
ステップ５．６２の後は、処理は、再度ステップ５．１２に戻り、ステップ５．１２において、カウンタｉの値が増やされる。次に、ステップ５．２の評価が再度実施され、処理は、該評価が否定的な結果を出すと想定し、ステップ５．４、５．１４、５．３０、５．４４、及び５．５８を介してステップ５．６４に進む。ステップ５．６４における評価は、ｉが６に増やされているため肯定的な結果を出す。
【０１３８】
従って、ステップ５．６４の後は、処理は、ステップ５．６６に進み、ステップ５．６６において、装飾テキスト削除変換が開始される。この変換は、ステップ５．６８において実施され、ステップ５．６８においては、装飾目的の機能であることがコンテンツ解析モジュール３０によって検出されたテキストがウェブコンテンツから削除される。
【０１３９】
ステップ５．６８の後は、処理は、ステップ５．１２に戻り、ステップ５．１２において、カウンタｉの値が増やされる。次に、ステップ５．２における評価に戻り、変換されたコンテンツが現在は所定の表示装置のディスプレイ内に納まるかどうかに関する評価が行なわれる。処理は、変換されたコンテンツが所定の表示装置のディスプレイ内に納まらないと想定し、ステップ５．４、５．１４、５．３０、５．４４、５．５８、及び５．６４の各々の評価を行ってステップ５．７０に進み、ステップ５．７０において、現在はカウンタｉが７の値を有しているため、肯定的な結果が戻される。このことは、処理をステップ５．７２に進ませ、ステップ５．７２において、装飾画像削除変換が開始される。ステップ５．７４において、装飾オブジェクト機能を有することがコンテンツ解析モジュール２０によって検出された画像又はオブジェクトが削除される。以上のように、ウェブコンテンツの真の意味コンテンツに貢献しない画像が削除される。
【０１４０】
ステップ５．７４の後は、処理は、再び５．１２に戻り、ステップ５．１２において、カウンタｉの値が増やされる。その後は、変換されたコンテンツがこの時点では所定の表示装置のディスプレイ内に納まるかどうかに関するステップ５．２の評価が行なわれる。処理は、この評価が否定値を返すと想定し、ステップ５．４、ステップ５．１４、ステップ５．３０、ステップ５．４４、ステップ５．５８、ステップ５．６４、及びステップ５．７０の各々の評価を経てステップ５．７６に進む。ステップ５．７６においては、現時点ではｉが８であるかどうかに関する評価が行なわれる。この評価は肯定的な結果を戻すため、処理は、ステップ５．７８に進み、ステップ５．７８において、画像交換変換が開始される。この画像交換変換は、ステップ５．８０において開始され、各画像表示オブジェクトに関して、画像が代替テキストを有するかどうかに関する評価が行なわれる。画像が代替テキストを有する場合は、処理は、ステップ５．８２に進み、ステップ５．８２において、画像に関する代替テキストの全体的な画素サイズが画像自体よりも小さいかどうかに関するさらなる評価が行なわれる。該画素サイズが画像自体よりも小さい場合のみに、画像が代替テキストに代えられる。明確なことであるが、代替テキストが画像よりも大きいスペースを占めることになるのでは、該画像を代替テキストに代えてもほとんど意味がない。ステップ５．８４において交換後は、処理は、ステップ５．１２に戻る。同様に、ステップ５．８０及びステップ５．８２の評価のうちのいずれかの評価が否定値を戻した場合、即ち、画像が代替テキストを有していない場合、又は、代替テキストが既存の画像サイズよりも小さくない場合は、処理は同じくステップ５．１２に戻る。ここでは、処理がステップ５．１２に戻ってカウンタｉの値が増やされる前に、図５において示されている画像変換が実施されることに注目すべきである。更に、ウェブコンテンツ内の複数のオブジェクトを対象にしたこの処理は、次の変換を実施することを可能にするカウンタｉの値が増えされる前にウェブコンテンツ内のすべての該当オブジェクトに関して各変換が実施されるという点で、前述されている変換の各々に関して実施される。
【０１４１】
ステップ５．１２において、再度カウンタｉの値が増やされ、従って、この事例においては現時点では値９を有する。このため、処理がステップ５．２における評価に戻った時点では、ｉが８よりも大きいという代替評価条件が満たされており、このための変換アルゴリズムは終了しなければならない。
【０１４２】
上記の説明から、変換アルゴリズムは、ウェブコンテンツ内の表示オブジェクトに関して各変換を実施し、更に各変換を実施後は、変換されたウェブコンテンツは所定の表示装置のディスプレイ上において表示できるかどうかに関する評価を行うように動作することがわかることになる。変換されたウェブコンテンツが所定の表示装置のディスプレイ上において表示できる場合は、これ以上の変換は実施されず、ＴＲＵＥをｆｉｔｓ＿ｐａｇｅ（）に戻す。
【０１４３】
適合化プロセスが完了後、即ち、図６の適合化アルゴリズムが終了後は、特定のクライアント能力プロフィールに関して異なったウェブコンテンツバージョンが生成されていることになる。しかしながら、複数のクライアント能力プロフィールが存在するため、各クライアント能力プロフィールに関する適合化されたウェブコンテンツバージョンを生成するためにこれらのアルゴリズムを繰り返し実行しなければならない。その後は（即ち、全バージョンを生成後は）、適合化モジュールは、生成されたバージョンに関するプロフィールＩＤをクライアント能力プロフィールに基づいて生成し、これらの適合化されたバージョン及びＩＤをコンテンツキャッシュに保存する。これらのプロフィールＩＤと物理的な適合されたコンテンツの論理的関係は、データベース構造相互参照リンクの形をしている。これで、これらの適合されたコンテンツバージョンは、検索可能な状態であってエンドユーザーの要求に応じて引き渡すことが可能な状態になっている。
【０１４４】
本発明の実施形態に準拠したシステムは、上述されている動作モードにおいて、ユーザーが要求する前に原ウェブコンテンツの多数の適合化バージョン（即ち、既知の及び指定された特性を有する特定の所定の表示装置に関する各々のバージョン）を生成するように動作する。
【０１４５】
しかしながら、上述されているように、該システムは、ウェブサーバーとして動作することもできる。次にこの動作モードについて説明する。
【０１４６】
システムがウェブサーバーとして動作していてインターネットに接続されていると想定すると、該サーバーは、ウェブコンテンツに関するｈｔｔｐ要求をエンドユーザーデバイス１から受け取る。このｈｔｔｐ要求は、最初にクライアント能力発見モジュール１２に引き渡され、クライアント能力発見モジュール１２は、エンドユーザーデバイス１の一組の表示特性（例えば、画面のサイズ、色の深さ、ブラウザーの種類、ネットワーク接続、等）を決定するように動作する。
【０１４７】
クライアント能力発見モジュール１２は、Ｍ３Ｉによって提言されている基準等の既存の基準に基づいてデバイス能力を検出する（前述されておりさらに本出願明細書において参照することによって本出願明細書に組み入れられているCurrent Technologies for Device Independent, Mark H Butler, HP Labs Technical Report HPL-2001-83 4 April 2001）（デバイスに依存しないための現在の技術、マークＨバトラー、HP研究所技術報告書ＨＰＬ−２００１−８３ ２００１年４月４日）を参照すること。該報告書の該当する内容は、本発明を完全に理解する上で必要である。現時点においては、ほとんどのインターネットブラウザーの場合は、ウェブサーバーに送られる最初の要求の中にエンドユーザー情報（ブラウザーの種類とバージョン、ＩＰアドレス、画面解像度、等）が含まれている。エンドユーザーのデバイスは、エンドユーザーがウェブサーバーを通じてＵＲＬを入力した時点でサーバーとの通信を始める。クライアント能力発見モジュール１２は、エンドユーザーデバイス情報を入手するために、エンドユーザーから送られたクライアント能力情報を単純なＪａｖａｓｃｒｉｐｔ（登録商標）によって検索し、Ｊａｖａサーブレットプログラムを通じて該情報をサーバーに渡す。「クライアントプロフィール」と呼ばれるＪａｖａ（登録商標）Ｓｅｒｖｌｅｔを通じてエンドユーザーデバイス情報を入手してサーバーに引き渡すＪａｖａｓｃｒｉｐｔ（登録商標）のサンプルを以下に示した。
【表３】
【０１４８】
クライアント能力発見モジュール１２は、エンドユーザーデバイス１のクライアント特性の組を決定後、決定した特性の組を決定モジュール１４に引き渡し、決定モジュール１４は、エンドユーザーデバイス特性を、プロフィールサーバー２６内に保存されているクライアント能力プロフィールの組と比較するように動作する。決定モジュール１４がエンドユーザーデバイス特性の組をクライアント能力プロフィールのうちの１つとマッチさせることができた場合は、決定モジュール１４は、エンドユーザーデバイス特性にマッチしたクライアント能力プロフィールのプロフィールＩＤをインデックスとして使用して、適合化されたコンテンツの異なったバージョンを保存するコンテンツキャッシュ１０にアクセスする。次に、該プロフィールＩＤにインデキシングされたウェブコンテンツの適合化バージョンが、コンテンツキャッシュ１０から検索され、ネットワークを通じてエンドユーザーデバイス１に提供される。以上のように、この動作モードにおいては、該システムは、ウェブコンテンツの適合化バージョンのうちでエンドユーザーデバイスに送るべき予め生成された適合化バージョンを決定するために、エンドユーザーデバイス表示特性を一組の予め定義されたデバイス特性とマッチングさせることができる。
【０１４９】
上述されているように、該システムは、さらなる動作モードも提供し、該動作モードでは、前述されている動作モードによって提供された動作を結合させる。ここでは、エンドユーザーデバイス１がウェブコンテンツ要求を行うと、前述されているようにクライアント能力発見モジュール１２が動作して該デバイスの表示特性を決定し、決定された表示特性が決定モジュール１４に渡される。決定モジュール１４は、エンドユーザーデバイス１の能力を、プロフィールサーバー２６に保存されているクライアント能力とマッチさせることを試み、マッチさせることができた場合は、ウェブコンテンツの該当する適合化バージョンがコンテンツキャッシュ１０から検索され、ネットワークを通じてエンドユーザーデバイス１に渡される。マッチさせることができない場合は、決定モジュール１４は、クライアント能力発見モジュール１２によって決定された特性に関連するエンドユーザーデバイス１の詳細を適合化モジュール１６に渡すことによって適合化モジュール１６を動作させる。適合化モジュール１６は、プロフィールサーバー２６に保存されてエンドユーザーデバイス１の能力に対応する新しいクライアント能力プロフィールを生成し、更に、エンドユーザーデバイス１専用に適合化された新たな適合化ウェブコンテンツバージョンを生成するためにウェブコンテンツの適合化バージョンを予め生成時には、前述されている方法とまったく同じ方法で動作を開始させる。即ち、適合化モジュール１６は、コンテンツ解析モジュール２０を動作させ、コンテンツ解析モジュール２０は、ウェブコンテンツを解析し、適合化モジュールがエンドユーザーデバイス１専用の新たな適合化されたウェブコンテンツバージョンを生成するために適合化アルゴリズムを実行することを可能にする。次に、適合化されたウェブコンテンツは、決定モジュールに戻され、決定モジュールは、ネットワークを通じて該適合化ウェブコンテンツをエンドユーザーデバイス１に送る。更に、新たな適合化ウェブコンテンツは、エンドユーザーデバイス１と類似のエンドユーザーデバイスが将来要求した場合に使用できるようにするためにコンテンツキャッシュ１０にも保存される。従って、このさらなる動作モードにおいては、適合化されたウェブコンテンツの新たなバージョンを、ユーザーの要求に応じて動的に生成することができ、更に、ユーザーによる将来の要求に対応するために保存される。
【０１５０】
該システムは、上述されている動作モードに加えて、カスタム化モジュール２４も提供する。このカスタム化モジュールは、単に、コンテンツキャッシュに保存されたウェブコンテンツの様々な適合化バージョンに対して改良を加えるためにウエブ著者が必要に応じてブラウズすることを可能にするフロントエンドであるにすぎない。この機能に鑑みて、カスタム化モジュール２４に関するこれ以上の説明は行わない。
【０１５１】
結論としては、該システムは、異なったウェブコンテンツバージョンをユーザーの要求に先んじて生成することができるため、ユーザーが要求時には、エンドユーザーデバイスの表示特性を予め生成されたバージョンとマッチングさせ、それによって、計算をほとんどまったく集中させずに敏速に応答を生成することができる。更に加えて、必要な場合は、ウェブコンテンツを要求している特定のエンドユーザーデバイスとマッチさせるために適合化ウェブコンテンツの新たなバージョンを動的に生成することもでき、更に、類似のエンドユーザーデバイスからの将来の要求に対応する際に使用するために保存される。
【０１５２】
本出願明細書において特に図５及び６の適合化プロセスを参照しつつ説明されている特定の実施形態における手順は、解析されたウェブコンテンツ（ＸＭＬツリー）全体を移動する反復プロセスと、コンテンツ分割と、コンテンツを必要に応じて変換して表示装置に適合するように縮小すること、が含まれていたことが理解される。しかしながら、代替実施形態も構想されており、該代替実施形態においては、最初にコンテンツ全体を可能な限りの最小サイズに縮小し、その後にコンテンツを分割し、次に該コンテンツのサイズを再度拡大させて表示サイズにする変換を行うように手順が修正される。該コンテンツを再度拡大した時点で、該コンテンツを複数のページ間でより適切に配分するために再分割することが必要になる場合がある。従って、この手順は、繰り返し分割すること及び変換することも含むことになるが、コンテンツのサイズが表示装置において表示するのに適しているかどうかを決定するステップは、受け入れられないほど大きな面積の空白スペースを表示装置において表示するかどうかを計算することを含むことができる。
【０１５３】
グルーピング／クラスタリングパターンアルゴリズムは、ウェブページ部分のオブジェクトをクラスタに分類し、これらのクラスタ間の関係を決定する。この分類及び関係は、より小さい画面を有するデバイスにおけるいくつかのより小さいコンテンツページ上にどのようにしてウェブページコンテンツを表示するかに対して影響を与える。より小さいコンテンツページの組のうちのどのページにどのクラスタを入れるべきかを決定する１つの方法は、グルーピング／クラスタリングパターンアルゴリズムを使用し、更に、以下の予め決められたパラメータ値に依存する。
【０１５４】
選択すべきクラスタ内において計算された最大許容画素数（合計）
１つの分割されたページに関する許容空白スペース（実験的に決定できる）
分割ページの許容される縦の長さ（実験的に決定できる）
分割ページの許容される横の長さ（実験的に決定できる）
第１の予め決められたサイズの表示面積を有するデバイス上において表示するように配備されたウェブページのコンテンツを、１つ以上のその他のデバイス（各々が異なった表示面積を有することができるデバイス）において表示するために複数のコンテンツページに分割する循環（繰り返し又は反復）手法を採用することによって、各デバイスにおいてコンテンツを提示するために用いられるフォーマットが相対的に一貫している。従って、原ウェブページから派生したコンテンツを含むページを示すすべてのディスプレイは、１つの一貫したフォーマットを共有することができるはずである。
【０１５５】
文脈上別の解釈が明確に要求されない限り、本出願明細書における説明全体を通じて、「具備する」、「具備している」、等の表現は、排他的または余すところなくという意味ではなく包含するという意味である、即ち、「含んでいるが、これらの項目に限定するものではない」という意味であると解釈すること。
【０１５６】
本出願明細書の要約の本文を説明の一部として以下に再掲した。
【０１５７】
ウェブページコンテンツを適合させる装置及び方法について説明されている。ウェブページコンテンツをより小型の所定の表示装置において表示するために適合させることは、該コンテンツを幾つかのより小さいページにわたって分割することをしばしば要求する。該装置及び方法は、プロセスを最適化するためにコンテンツ分割プロセスと変換（例えば、フォントサイズ、画像、等の縮小）を実施することを統合する手順に関連する。該手順は、ウェブページコンテンツ全体にわたって体系的に実施され、該コンテンツを反復的により小さい部分に分割することと、これらのより小さいページ上において見ることができる空白スペース量を最小にするために様々な変換を同時に実施すること、とを繰り返す。更に、好ましい実施形態は、オブジェクトに関して既に実施されている変換を追跡し、更に、これらの変換をのちにその他の類似のオブジェクトに関しても実施することによって一貫性を確保する。
【図面の簡単な説明】
【０１５８】
【図１】本発明の実施形態の構成要素と、これらの構成要素間における信号の流れと、を示したシステムブロック図である。
【図２】動作中の本発明の実施形態の構成要素間における情報の流れ方をより詳細に示したプロセス流れ図である。
【図３】本発明の実施形態においてウェブコンテンツ内の表示オブジェクトの特性を検出するアルゴリズムに関する流れ図である。
【図４】本発明の実施形態においてウェブコンテンツ内の表示オブジェクトの機能を検出する決定ツリーである。
【図５Ａ】本発明の実施形態におけるコンテンツ変換実施方法を示した流れ図（その１）である。
【図５Ｂ】本発明の実施形態におけるコンテンツ変換実施方法を示した流れ図（その２）である。
【図５Ｃ】本発明の実施形態におけるコンテンツ変換実施方法を示した流れ図（その３）である。
【図６】本発明の実施形態におけるコンテンツ分割プロセスの実施方法を示した流れ図である。
【技術分野】
【０００１】
本発明は、ウェブページコンテンツを複数のより小さいウェブページに分割することによって所定の表示装置において表示できるように適合させる装置およびシステムに関するものである。
【背景技術】
【０００２】
ウェブコンテンツを異なった種類のデバイスに引き渡すことは、コンテンツソースについて理解して該コンテンツソースをデバイス特性に適合する形で異なった種類のデバイス（デスクトップＰＣ、ＰＤＡ、及び携帯電話、等）に引き渡すことができるように該ウェブコンテンツを理解、再構築及び個別適合化するプロセスである。従来の技術（例えば、Current Technologies for Device Independent, Mark H Butler, HP Labs Technical Report HPL-2001-83 4 April 2001）（デバイスに依存しないための現在の技術、マークＨバトラー、HP研究所技術報告書ＨＰＬ−２００１−８３ ２００１年４月４日を参照）では、現在知られている方法は以下の3つである。
【０００３】
第１の方法では、ウェブ開発者／著者は、ウェブコンテンツ開発段階において、ウェブページ開発ソフトを用いて、コンテンツが異なった種類のデバイスに適合するように手作業で適合させることができる。この方法によって、単一のコンテンツソースの異なったバージョン(HTML/CSS、ＷＭＬ、ＸＭＬ／ＸＳＬ、等)をデバイスの能力に基づいて作り出すことができる。この手法は、ウェブコンテンツを異なった種類のデバイスに引き渡す上で最も原始的な方法であり、大量のバージョンが要求される場合はウェブ開発者／著者にとって時間のかかる面倒な仕事である。
【０００４】
第１の方法よりも自動的である第２の手法は、エンドユーザーがHTTP要求を通じてURIリンクを提出時に速やかに適合化作業を行うプロキシサーバーを通じての、プロキシに基づくトランスコーディング手法を用いる。この手法は、プロキシサーバーに計算が集中しており、その結果システム応答時間が低速になる。更に、適合されたウェブコンテンツの原ウェブ開発者／著者が介在しておらず、国によっては法律上および著作権上の問題が発生するおそれがある。
【０００５】
第３の既知の方法は、適合化システムソフトをクライアント側にインストールすることによってクライアントに基づく（エンドユーザーデバイス）適合化手法を用いる方法である。クライアントに基づく適合化システムは、要求を受けたウェブサーバーによって戻された結果を受け取り後速やかにウェブコンテンツを適合化させる。この手法は、クライアント側に計算が集中しており、その結果クライアントの処理性能を費やして低下させることになる。この場合も、適合されたウェブコンテンツの原ウェブ開発者／著者が介在しておらず、法律上および著作権上の問題が同様に発生するおそれがある。更に、この手法は、計算能力に限界がある小型のモバイルデバイスには利用することができない。
【０００６】
適合化の一環として、PDA及びWAP電話、等のクライアント表示装置は小型であることに鑑みて１つのウェブコンテンツページを複数のより小さいページに分割することが必要になることがある（コンテンツ分割と呼ばれる）。例えば、ＰＣウェブページ（８００ｘ６００画素、等）のコンテンツを読み取り可能な形でより小型の表示装置（２４０ｘ３２０画素のＰＤＡ、等）に提供する場合は、空白スペース量を最小限にすることを試みつつ該コンテンツが最も少ない数のより小さいページ内に納まるように適合させるのが望ましい。
【０００７】
従来の既知のコンテンツ分割方法は、"System, Method and Computer Program Product for Page Rendering Utilizing Transcoding"（トランスコーディングを利用したページ提供のためのシステム、方法及びコンピュータプログラム製品）という題名の米国特許出願Ｎｏ．０９／９４２，０５１（ＵＳ２００３／００５０９３１ Ａ１として発行）において説明されている方法を含む。この文書は、ウェブコンテンツを複数のページに分割することによって異なった種類の閲覧装置上において表示できるように適合させることができるシステムについて説明している。該システムは、最初に、ウェブコンテンツを使用し、ＸＭＬを用いて階層ツリー構造を構築し、次に、（閲覧装置によってサポートされているテキストフォントに変更し、さらに冗長な情報を変数への参照に置き換えることによって）該階層ツリー構造を閲覧装置において表示できるようにフォーマット化する。次に、フォーマット化された構造を閲覧装置に出力するために複数のページに分割する。しかしながら、該手法は、コンテンツを分割してクライアント表示装置に適合させるという目標は達成させる一方で、空白スペース量を最小限に抑えるという望ましい目標は達成させない。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
従って、ウェブページコンテンツを所定の表示装置において表示するために適合させさらに従来の技術の欠点（特に、コンテンツとともに表示される空白スペース量を最小限に抑えるように試みることに関する欠点）を有していないさらなる手法を開発する必要がある。
【課題を解決するための手段】
【０００９】
本発明は、上記の要求を満たすため、所定の表示装置において表示するためにウェブページコンテンツを適合させる装置および方法を提供する。本出願明細書においては、分割と変換と結合させた統合プロセスが、コンテンツの表示サイズを適合させるために反復的な形で提供される。このことは、ページ上に現れる空白スペース量を最小にしつつ適切な数のより小さいウェブページにコンテンツを分割することを可能にする。この前後関係において、「変換」という用語は、例えば、画像のサイズの縮小／拡大／テキスト削除／コンテンツ交換、等を含むことができる。
【００１０】
本発明の第１の側面においては、ウェブページコンテンツを所定の表示装置において表示するために適合させる装置が提供されており、該装置は、該コンテンツを該表示装置において表示するために複数のより小さいウェブページに分割するための適合化手段を具備し、該適合化手段は、下記の手順を実行するように準備されている。
【００１１】
（ｉ）該コンテンツを複数のコンテンツ部分に分割し、更に、該コンテンツ部分のうちの少なくとも１つに関してステップ（ｉｉ）乃至（ｖｉ）を反復的に繰り返す。
【００１２】
（ｉｉ）該コンテンツを解析し、該コンテンツ部分のサイズが該表示装置において表示するのに適しているかどうかを決定する。
【００１３】
（ｉｉｉ）該コンテンツ部分のサイズが該表示装置において表示するのに適していない場合は、複数の変換を該コンテンツ部分に関して実施する。
【００１４】
（ｉｖ）変換されたコンテンツを解析し、変換されたコンテンツ部分のサイズが該表示装置において表示するのに適しているかどうかを決定する。
【００１５】
（ｖ）変換されたコンテンツ部分のサイズが該評価装置において表示するのに適していない場合は、該コンテンツ部分を複数のさらなるコンテンツ部分に分割する。
【００１６】
本発明の第２の側面においては、ウェブページコンテンツを所定の表示装置において表示するために適合させる方法が提供されており、該方法は、下記のステップを実行することによって、該コンテンツを該表示装置において表示するために複数のより小さいウェブページに分割することを具備する。
【００１７】
（ｉ）該コンテンツを複数のコンテンツ部分に分割し、更に、該コンテンツ部分のうちの少なくとも１つに関してステップ（ｉｉ）乃至（ｖｉ）を反復的に繰り返す。
【００１８】
（ｉｉ）該コンテンツを解析し、該コンテンツ部分のサイズが該表示装置において表示するのに適しているかどうかを決定する。
【００１９】
（ｉｉｉ）該コンテンツ部分のサイズが該表示装置において表示するのに適していない場合は、少なくとも１つの変換を該コンテンツ部分に関して実施する。
【００２０】
（ｉｖ）変換されたコンテンツを解析し、変換されたコンテンツ部分のサイズが該表示装置において表示するのに適しているかどうかを決定する。
【００２１】
（ｖ）変換されたコンテンツ部分のサイズが該表示装置において表示するのに適していない場合は、該コンテンツ部分を複数のさらなるコンテンツ部分に分割する。
【００２２】
本発明の第３の側面においては、コンピュータシステムによって実行時に該コンピュータシステムに上記の方法を実施させるように配備された1つのコンピュータプログラム又は一組のプログラムが提供されている。該1つの又は複数のプログラムは、該コンピュータプログラム又は該一組のプログラムのうちの少なくとも１つに対応するデータを組み込んだ変調搬送信号（例えば、インターネット等のネットワーク上で搬送される信号）によって具体化することができる。
【００２３】
更に、さらにもう１つの側面においては、本発明は、第３の側面に従った１つのコンピュータプログラム又は一組のコンピュータプログラムのうちの少なくとも１つを格納する、コンピュータによって読み取り可能な記憶媒体も提供する。該コンピュータによって読み取り可能な媒体は、コンピュータによって読み取り可能なあらゆる磁気記憶媒体、光学記憶媒体、磁気光学記憶媒体、ソリッドステート記憶媒体、又はその他の記憶媒体であることができる。
【００２４】
上述されておりさらに付随の請求項によって説明されている本発明の側面、および本出願明細書および付随の請求項において説明されているあらゆる好ましい特長は、当業者にとって明確であるあらゆる適切な組合せで組み合わせることができる。
【００２５】
例示することのみを目的として示されている本発明の実施形態に関する以下の説明及び添付図面を参照することによって、本発明のさらなる特長及び利点が明確になる。尚、これらの図においては、同一のものについては図面全体に渡って同一の参照番号を付けることとする。
【発明を実施するための最良の形態】
【００２６】
図１乃至６を参照しつつ本発明の１つの実施形態について説明する。
【００２７】
図１は、本発明の実施形態によって提供されるシステムのシステムブロック図である。このシステムは、次に説明する８つの副構成要素を具備する。システムの全動作については後述される。
【００２８】
第１に、クライアント能力発見モジュール１２が提供される。このモジュールの目的は、エンドユーザーのデバイスの特性、例えば、デバイスの型及びデバイスの能力（サポートされている画面の大きさ／解像度、処理能力、等）を発見することであり、このため、このモジュールは、エンドユーザーの表示装置の能力に関連する情報を該表示装置から受け取る。クライアント能力発見モジュール１２は、エンドユーザーのデバイス情報を決定モジュール１４に渡す。
【００２９】
決定モジュール１４は、適合化システムによって事前に検出されたか又は予め定義されている既存のクライアント能力プロフィール識別子を含む。クライアント能力プロフィール識別子は、表示装置の表示特性に関連する情報の集合である。使用時には、決定モジュール１４は、最初に、発見モジュールによって送られた情報に基づくエンドユーザーのデバイスの特性・能力（ＣＣ）範囲と、既存の能力プロフィールを比較する。クライアントの能力が既存のプロフィールとマッチしている場合は、該マッチしているプロフィールのプロフィール識別子がコンテンツキャッシュ１０に送られる。コンテンツキャッシュ１０には、予め生成された適合化ウェブコンテンツの異なった種類のバージョンが保存されている。受け取られたＣＣの組が既存のＣＣ範囲とマッチしない（即ち、現在要求中のデバイスの能力とマッチする既存のＣＣプロフィールが存在しない）場合は、適合化モジュール１６がトリガーされる。更に、適合化モジュール１６は、エンドユーザーからの特定の要求がない場合でも、原ウェブコンテンツの異なった種類のバージョンを生成するために手作業でトリガーすることもできる。
【００３０】
適合化モジュール１６は、どのような方法でトリガーされた場合でも、要求されたウェブコンテンツのｈｔｔｐヘッダーを検討するように動作し、更に、コンテンツ解析モジュール２０を制御し、要求されたウェブコンテンツをウェブコンテンツソース保存領域２２から検索するようにさらに動作する。次に、コンテンツ解析モジュール２０は、コンテンツソース保存領域２２から得られた指示されたウェブコンテンツを解析するように動作し、該ウェブコンテンツの特性に関連する１つの範囲のパラメータを、適合化モジュール１６への入力値として適合化モジュール１６に戻す。適合化モジュール１６において受け取られたコンテンツ解析モジュール２０からの入力パラメータは、ウェブコンテンツ保存領域２２に保存されている原ウェブコンテンツから得られた要求されているウェブコンテンツの適合化を適合化モジュール１６が行うことを可能にする。従って、適合化モジュール１６の出力は、最初に要求されたウェブコンテンツの適合化バージョンであり、この適合化バージョンは、ウェブコンテンツを要求中の表示装置のディスプレイの一組の１つ以上の特性である一組のクライアント能力（ｃｃ）情報とともに、ｈｔｍｌ等の該当するマークアップ言語でキャッシュ１０に送られる。尚、該表示特性情報は、上述されているクライアント能力発見モジュール１２によって決定された情報である。
【００３１】
上記のモジュールに加えて、既述のように、原ウェブコンテンツの異なった適合化バージョンを保存するように動作するコンテンツキャッシュ１０も提供される。幾つかの実施形態においては、キャッシュ１０は、異なったクライアント表示装置の表示特性に関連する情報の集合であるクライアント能力特性も保存することもできる。更に、適合化対象の原ウェブコンテンツが保存されるコンテンツソース２２、及び、コンテンツ解析モジュール２０の制御下で動作し、コンテンツソース保存領域２２から受け取った原ウェブコンテンツを解析前に整理するコンテンツ整理モジュール１８も提供される。更に加えて、コンテンツキャッシュからの適合化済みウェブコンテンツのプレビューを提供するフロントエンドシステムであるにすぎないカスタム化モジュール２４も提供される。カスタム化モジュール２４は、著者が適合化されたコンテンツをプレビューしてさらにカスタム化することを可能にするオフラインモジュールである。
【００３２】
本発明の実施形態によって提供される様々なシステムモジュールについて説明後は、図２乃至６を参照しつつこれらのモジュールの動作についてさらに詳細に説明する。
【００３３】
本発明によって提供される装置は、ウェブサーバー、等として動作するコンピュータシステムにおいて具体化するのが最も有望である。代替として、該装置は、別個のコンピュータシステムにおいて具体化することができる複数のコンピュータシステムコンポーネント（図１参照）において具体化することができる。好ましいことに、これらのコンピュータシステムのうちの１つは、その他のコンピュータシステムに関するウェブサーバーとして動作する。該装置がどのような形で具体化された場合においても、該コンピュータシステムは、単なるサーバーとして動作するだけでなく、ウェブコンテンツの著者がウェブコンテンツを開発すること及びその見直しを行うことも可能にする。更に、該コンピュータシステムは、異なった種類の所定の表示装置のために原ウェブコンテンツの異なったバージョンを生成するようにも動作する。
【００３４】
上記の機能に鑑みて、以下の３つの異なったシステム動作モードが存在する。
【００３５】
第１のモード−システムは、ネットワークを通じて受け取られているユーザーのウェブコンテンツ要求に対応するように動作する。
【００３６】
第２のモード−システムは、ユーザーからのウェブコンテンツ要求を受け取る前に、該ウェブコンテンツの適合化されたバージョンを異なった種類の所定の表示装置のために生成するように動作する。
【００３７】
第３のモード−さらなる適合化されたバージョンを提供するためのウェブコンテンツ適合化を、ユーザー要求に対応して速やかに実施することができる。
【００３８】
以下ではこれらの動作モードの各々について説明する。
【００３９】
最初に上記の動作モードのうちの第２の動作モードに関して、ユーザーによる要求前に原ウェブコンテンツの異なったバージョンを生成するためにシステムを使用中であると想定する。例えば、このモードは、ウェブサイト開発中に使用し、異なった種類の所定の表示装置に合わせて各々が特別に適合化されていて各々が異なった表示特性を有する（原ソースウェブコンテンツ）のバージョンを生成することができる。
【００４０】
従って、該モードにおいて実施される第１ステップは、複数の組の予め定義された所定表示装置表示特性プロフィールが生成され、各組は、一意のＩＤを有しており更に各々の特性が１つの範囲の値をとる一組の１つ以上の表示特性に対応している。例えば、第１のクライアント能力プロフィールの組は、ｃｌｉｅｎｔ＿ｔｙｐｅ ｓｃｒｅｅｎ＿ｒｅｓｏｌｕｔｉｏｎ、及びｃｏｕｌｏｒ＿ｄｅｐｔｈという名前のフィールドを有することができる。第１のプロフィールＩＤであるＣＣ１は、１つの例として、ｃｌｉｅｎｔ＿ｔｙｐｅフィールドにおいて“ＰＣ”値、ｓｃｒｅｅｎ＿ｒｅｓｏｌｕｔｉｏｎフィールドにおいて“８００ｘ６００”又は“１０２４ｘ７６８”、ｃｏｌｏｕｒ＿ｄｅｐｔｈフィールドにおいて“１６ビット”を有することができる。さらにもう１つの例として、ＩＤ“ＣＣ２”を有するさらなるクライアントプロフィールの組は、ｃｌｉｅｎｔ＿ｔｙｐｅフィールドにおいて“ＰＤＡ”値、ｓｃｒｅｅｎ＿ｒｅｓｏｌｕｔｉｏｎフィールドにおいて値“２００ｘ３００”、ｃｏｌｏｕｒ＿ｄｅｐｔｈフィールドにおいて“３２ビット”を有することができる。上記の例は、プロフィールの組の生成に貢献できる情報の種類の例を単に示しただけであってこれらの例に限定するものではないこと、及び、デバイスの特性と能力の様々な組合せを有する１つの集合を形成することによって多数の異なったプロフィールを簡単に生成可能であることが理解されることになるであろう。いったん生成されたクライアント能力プロフィールの組は、図２に示されているプロフィールサーバー２６に保存される。プロフィールサーバー２６は、デバイスプロフィールを物理的に保存するように動作する単なるデータベースシステムであるにすぎない。プロフィールサーバー２６は、要求中のユーザーの表示装置特性と保存されているクライアント能力プロフィールの組の比較を決定モジュール１４が行うことを可能にするために決定モジュール１４によってアクセス可能である。
【００４１】
システムは、前述された動作モードにおいて所定の表示装置の特性と値の組合せを各々が有する複数のクライアントプロフィールの組を生成後は、プロフィールサーバー２６内に保存されているクライアント能力プロフィールの組の各々に関する原ソースウェブコンテンツの適合化バージョンを生成するように動作する。この生成は、適合化モジュール１６をトリガーして原ソースウェブコンテンツを適合させて各クライアント能力プロフィールの組とマッチさせることによって実施される。適合化モジュール１６は、通常は各クライアント能力プロフィールの組ごとに別々にトリガーされ、このため、いずれの１つのトリガー時においても、単一のクライアント能力プロフィールの組に対応する単一のウェブコンテンツ適合化バージョンが生成される。以下では、トリガー時における適合化モジュール１６の詳細な動作について説明する。
【００４２】
適合化モジュール１６によって実施される第１のステップは、適合化対象となる原ソースウェブコンテンツの詳細をコンテンツ解析モジュール２０に渡すことによってコンテンツ解析モジュール２０をトリガーすることである。次に、コンテンツ解析モジュール２０は、（開発者／著者によって作られたすべてのウェブコンテンツソースを保存する）コンテンツソース保存領域２２から原コンテンツソースを検索し、検索したコンテンツソースをｘＨＴＭＬファイルに変換するためにコンテンツ整理モジュール１８に渡す。コンテンツ整理モジュール１８の機能は、マークアップ言語（ウェブコンテンツ）の構造を整理してｘＨＴＭＬ構造フォーマットに変換することである。ｘＨＴＭＬフォーマットは、コンテンツ解析モジュール２０が解析タスクを実施するための整理整頓された構造を提供する。コンテンツ整理モジュール１８は、優先権主張日においてhttp://tidy.sourceforge.net/から入手可能な第三者ソフト（ＴＩＤＹ、等）を用いることによって確保することができる。従って、ここでは、コンテンツ整理モジュール１８の動作についてさらに詳細に説明することはしない。コンテンツ整理モジュール１８は、整理されたｘＨＴＭＬファイルをコンテンツ解析モジュール２０に戻す。
【００４３】
コンテンツ解析モジュール２０は、整理されたウェブコンテンツを受け取り後は、以下のタスクを示されている順序で実施する。
【００４４】
ｉ）該ウェブコンテンツ内の表示オブジェクトの合計の画素と文字及び個々の画素と文字を計算する
ｉｉ）該ウェブコンテンツ内の個々のオブジェクトの機能を検出する（通常はウェブページ内におけるタグである） 例えば、オブジェクトは、スタイルタグ、構造タグ又は表示タグを持つことができる。
【００４５】
ｉｉｉ）構造上の挙動（オブジェクトタグからの情報）に基づいて単一オブジェクトを分類する
ｉｖ）表示オブジェクト表示パターンをマッチングし、これらのパターンを１つにまとめて１つのグループを形成させる（パターンマッチングアルゴリズムを用いる）
これらの4つのタスクは、次のような詳細を有する各々の専用アルゴリズムによって実施される。
【００４６】
第１のタスクに関して、このタスクを実施する目的は、表示オブジェクト（テキスト、画像、等）の画素／サイズを計算することである。このタスクを実施するアルゴリズムは、最初に表示オブジェクトの型を検出する。次に、該アルゴリズムは、異なった型の表示オブジェクトに関して異なった解析ロジックを適用する。例えば、表示オブジェクトがテキストオブジェクトである場合は、該アルゴリズムは、長さ、フォントのスタイル及びサイズを入手し、これらの入力項目に基づいて画素を計算する。表示オブジェクトが画像／アプレット／オブジェクトである場合は、該アルゴリズムは、該オブジェクトの幅と高さに基づいて総画素数を計算する。その他の表示オブジェクトに関しては、該アルゴリズムは、該オブジェクトのパラメータ内において設定された幅、高さ及び／又は幅／高さの各属性に基づいて総画素数を計算する（該パラメータがＨＴＭＬコンテンツにおいて指定されている場合）。このアルゴリズムによって実施される正確なステップを図３に示し、以下において説明する。
【００４７】
図３において、ステップ３．２においてアルゴリズムによって実施される第１のステップは、整理されたウェブコンテンツ内の個々の表示オブジェクトを検出する。次に、ステップ３．４において、検出された表示オブジェクトがテキストであるかどうかを決定するための評価が行われる。この評価が肯定応答を返した場合（即ち、検出された表示オブジェクトがテキストであることが決定された場合）は、ステップ３．６において、表示オブジェクト内のすべてのテキストストリングの長さが入手される。次に、ステップ３．８において、すべてのテキストストリングに関してテキストタグが生成され、ステップ３．１０において、ステップ３．６で決定されたテキストストリング内の文字数が該テキストタグの属性として設定される。
【００４８】
次に、ステップ３．１２において、すべてのテキストストリングのフォントとスタイルが決定され、次にステップ３．１４において、すべてのテキストストリングのサイズも決定される。ステップ３．１６において、この情報を用いて、フォント、スタイル性、及びサイズの各属性に基づくテキストストリングの高さ及び幅が計算され、これらの計算された高さ値及び幅値は、ステップ３．１８において各ストリングに関するテキストタグのさらなる属性として設定される。これで、テキストであると決定された特定の表示オブジェクトに関するプロセスはステップ３．５０において終了し、該プロセスは、ウェブコンテンツ内の次の表示オブジェクトを検出するためにステップ３．２において再開する。すべての表示オブジェクトがアルゴリズムによって処理された時点で、該アルゴリズムは繰り返されない。
【００４９】
再度ステップ３．４において、検出された表示オブジェクトがテキストでないことが決定された場合は、検出された表示オブジェクトが画像、アプレット、又はオブジェクトであるかどうかを決定するための第２のプロセスがステップ３．２０において実施される。この評価が肯定応答を返した場合（即ち、表示オブジェクトが画像、アプレット、又はオブジェクトである場合）は、処理は、ステップ３．２２に進み、ステップ３．２２においてさらなる評価が実施され、画像、アプレット、又はオブジェクトの幅が指定されているかどうかが決定される。該幅が指定されている場合は、処理は、ステップ３．２４に進む。該幅が指定されていない場合は、処理は、ステップ３．２８に進み、ステップ３．２８において、該オブジェクトの原幅が決定され、その後に同じくステップ３．２４に処理が進む。
【００５０】
ステップ３．２４において、検出された画像、アプレット又はオブジェクトの高さが指定されているかどうかを決定するためのさらなる評価が実施される。この評価が肯定応答を返した場合は、処理は、ステップ３．２６に進む。反対に、ステップ３．２４の評価が否定応答を返した場合は、処理は、ステップ３．３０に進み、ステップ３．３０において、該オブジェクトの原高さが決定される。次に、処理は、ステップ３．３０からステップ３．２６に処理が進む。
【００５１】
ステップ３．２６において、前述されたステップによって決定された画像、アプレット、又はオブジェクトの幅属性及び高さ属性が、ウェブコンテンツ内のオブジェクトタグの幅属性及び高さ属性として設定される。該設定後、該特定の表示オブジェクトの処理は、ステップ３．５０において終了する。この場合も、さらなるオブジェクトを処理する必要がある場合は、処理は、ステップ３．２において再開する。
【００５２】
再度ステップ３．２０において、実施された評価の結果、検出された表示オブジェクトが画像、アプレット、又はオブジェクトでないことが決定された場合は、処理は、ステップ３．３２に進み、ステップ３．３２において、検出された表示オブジェクトの幅及び高さが指定されているかどうかに関する評価が実施される。該幅及び高さが指定されている場合は、処理は、ステップ３．３４に進み、ステップ３．３４において、該指定された幅及び高さが、検出された表示オブジェクトに関する各制御タグのスタイル属性内のパラメータとして設定される。これで、該処理は、ステップ３．５０において終了し、前述のように必要な場合は繰り返すことができる。
【００５３】
ステップ３．３２において、幅及び高さのいずれも指定されていないと決定された場合は、処理は、ステップ３．３６に進んでさらなる評価が実施される。ステップ３．３６においては、検出された表示オブジェクトのサイズが指定されているかどうかが決定される。該サイズが指定されている場合は、処理は、ステップ３．３４に進み、ステップ３．３４において、該サイズは、該オブジェクトに関する各制御の型のスタイル属性内のパラメータとして設定される。その後、処理は、同じくステップ３．５０に進み、ステップ３．５０において終了する。しかしながら、処理すべきさらなる表示オブジェクトが存在する場合は処理を繰り返すことができる。
【００５４】
最後に、ステップ３．３６における評価が否定応答を返した場合は、検出された表示オブジェクトの値が指定されているかどうかを決定するための最終評価がステップ３．３８において実施され、該値が指定されている場合は、該指定値は、ステップ３．３４において、該オブジェクトに関する各制御の型のスタイル属性内のパラメータとして設定される。反対に、該値が指定されていない場合は、処理は、ステップ３．４０に進み、ステップ３．４０において、各制御のディフォルトの幅及び高さがメモリから検索され、ステップ３．３４においてこれらの値がディフォルト値として設定される。
【００５５】
以上のように、このアルゴリズムは、整理されたウェブコンテンツ内の各表示オブジェクトに関して、サイズパラメータ（例えば、テキストストリングの長さ、又は画像の幅と高さ、等）を決定するように動作する。この情報は、後述されている適合化プロセスにおいて用いることができる。
【００５６】
第２のタスクに関して、以下において説明するように、該タスクを実施するためのさらなるアルゴリズムが提供される。
【００５７】
第２のタスクを実施するアルゴリズムは、最初に、マークアップ言語の観点から単一オブジェクトの機能カテゴリを予め定義する。単一オブジェクト（Ｏ）は、マークアップ言語内に埋め込まれた要素であり、表示スタイル、静的スタイル、動的スタイル、構造上のスタイル、等の自己のプロパティを有する。
【００５８】
本出願明細書では、下記の予定義カテゴリを定義している。
【００５９】
情報（Ｉ）
情報タイトル（Ｔ）
制御（Ｃ）
装飾（Ｄ）
交換可能ナビゲータ（ＲＮ）
交換不能ナビゲータ（ＵＮ）
交換可能ナビゲータタイトル（ＲＮＴ）
交換不能ナビゲータタイトル（ＵＮＴ）
これらの機能カテゴリの定義は以下のとおりである。
【００６０】
情報（Ｉ）−情報としての表示コンテンツを提供するオブジェクトであり、重要でかつ交換不能である。このオブジェクトは、テキスト、画像、映像、音声又はあらゆるオブジェクト（ＪＡＶＡ（登録商標）アプレットフィルタ、等）ファイルであることができる。
【００６１】
情報タイトル（Ｔ）−情報オブジェクトについて記述するオブジェクトであり、情報プロパティを有するテキストヘッダー又は画像であることができる。
【００６２】
制御（Ｃ）−ユーザーとの対話を目的とするオブジェクトであり、ボタン（ラジオボタン又はサブミットボタン）、入力テキストエリア、書式、ドロップダウンメニュー、チェックボックス、リストボックス、等である。
【００６３】
装飾（Ｄ）−情報上の役割は果たさず、視覚効果向上専用のオブジェクト。このオブジェクトは、画像又はテキストであることができる。
【００６４】
交換可能ナビゲータ（ＲＮ）−ナビゲータは、ＵＲＩリンクオブジェクトである。交換可能ナビゲータは、代替テキストに代えることができるナビゲータオブジェクトである。交換可能ナビゲータは、代替テキストを備えた画像でなければならない。
【００６５】
交換不能ナビゲータ（ＵＮ）−前述したように、ナビゲータは、ＵＲＩリンクオブジェクトである。このため、交換不能ナビゲータは、代替テキストに代えることができないナビゲータオブジェクトである。交換不能ナビゲータは、代替テキストのないテキスト又は画像であることができる。
【００６６】
交換可能ナビゲータタイトル（ＲＮＴ）−交換可能ナビゲータタイトルは、ナビゲータオブジェクトについて記述する情報用ＵＲＬリンクオブジェクトである。交換可能ナビゲータタイトルは、代替テキストに代えることができる。交換可能ナビゲータタイトルは、代替テキストを備えた画像でなければならない。
【００６７】
交換不能ナビゲータタイトル（ＵＮＴ）−交換不能ナビゲータタイトルは、ナビゲータオブジェクトについて記述する情報用ＵＲＬリンクオブジェクトである。交換不能ナビゲータタイトルは、代替テキストに代えることができない。交換不能ナビゲータタイトルは、代替テキストのないテキスト又は画像であることができる。
【００６８】
上記のような予め定義された機能カテゴリを提供することによって、アルゴリズムは、マークアップ言語（ＨＴＭＬ、等）内に埋め込まれた単一オブジェクトのプロパティを解析する走査・比較メカニズムを開始させる。該解析の推論は、図４に示されている決定ツリー（走査・比較ロジックシーケンス）に基づいて行われる。
【００６９】
アルゴリズムは、最初に、ウェブコンテンツマークアップ言語を上から下に走査する。走査プロセスが開始されると、マークアップ言語のすべての単一オブジェクトが探索されて検出され、予め定義された機能カテゴリと比較される。この比較プロセスは、マークアップ言語の最後まで実行される。
【００７０】
走査ループ内において、アルゴリズムは、単一オブジェクトを探索し、該オブジェクトが有するプロパティに基づいて機能を決定する。アルゴリズムは、第１の単一オブジェクト（Ｏｎ）が特定の機能カテゴリに属することが認定された後に、単一オブジェクトＯｎのプロパティの比較を停止して次の単一オブジェクト（Ｏｎ＋１）を探索する。
【００７１】
図４において、アルゴリズムによって適用される決定ツリープロセスは次のとおりである。即ち、アルゴリズムは、最初に単一オブジェクトを探索する。単一オブジェクト４０が検出された時点で、アルゴリズムは、ステップ４．２において、該検出された単一オブジェクトはハイパーリンクプロパティが埋め込まれているかどうかを検査する。
【００７２】
該単一オブジェクトがハイパーリンクプロパティを有する場合は、ステップ４．４において検査が行われ、該単一オブジェクトに関する代替テキストが存在するかどうかを確かめることによって該オブジェクトが交換可能であるかどうかを決定する。（ステップ４．６における決定に従って）このオブジェクトに関する代替テキスト及びタイトルプロパティが存在する場合は、このオブジェクトは、交換可能ナビゲータタイトル（ＲＮＴ）４８として分類される。このオブジェクトに関する代替テキストは存在するがタイトルプロパティは存在しない場合は、アルゴリズムは、このオブジェクトを代替可能ナビゲータ（ＲＮ）４６として分類する。
【００７３】
このオブジェクトに関する代替テキストが存在せずタイトルプロパティが存在する場合は、アルゴリズムは、このオブジェクトを交換不能ナビゲータタイトル（ＵＮＴ）５２として分類する。このオブジェクトに関する代替テキストが存在せずさらにタイトルプロパティも存在しない場合は、アルゴリズムは、このオブジェクトを交換不能ナビゲータ（ＵＲＮ）５０として分類する。この区別は、ステップ４．１６において評価が行われる。ＲＮＴ及びＵＮＴのタイトルプロパティは、下記の条件に基づいて決定される。
【００７４】
タイトルヘッダープロパティを有する
表示オブジェクトである
URIハイパーリンク（画像又はテキスト）でなければならない
隣接する表示オブジェクトと比較して異なったスタイルを有する
ステップ４．２、４．４、４．６、及び４．１６においてオブジェクトとハイパーリンクプロパティを比較後において、該オブジェクトが依然として分類されていない場合は、本発明は、検査ロジックの対象を非ハイパーリンクプロパティにする。ユーザー側対話プロパティが次の比較対象になる。単一オブジェクトがユーザー側対話プロパティを有するかどうかを決定する要因は、単一オブジェクトが、ボタン（ラジオボタン又はサブミットボタン）、入力テキストエリア、書式、ドロップダウンメニュー、チェックボックス、又はリストボックスのうちのいずれか１つであるかどうかであり、この旨の評価がステップ４．８において行われる。
【００７５】
単一オブジェクトがユーザー側対話プロパティを有することがステップ４．８において検出された場合は、該単一オブジェクトは、制御（Ｃ）４２として分類される。該単一オブジェクトがユーザー側対話プロパティを有することがステップ４．８において検出されない場合は、アルゴリズムは、ステップ４．１０において、映像プロパティ、クラスオブジェクトプロパティ又は音声プロパティを有するオブジェクトであるかどうかをさらに比較する。該プロパティを有するオブジェクトである場合は、この単一オブジェクトは、情報（Ｉ）機能カテゴリ４４の中に含められる。
【００７６】
該単一オブジェクトがまだ分類されていない場合は、アルゴリズムは、ステップ４．１２において、該単一オブジェクトが有していた装飾プロパティが存在するかどうかを決定することによって該単一オブジェクトをさらに検査する。装飾プロパティに関する決定は、以下の基準に基づいて行われる。
【００７７】
単一オブジェクトのサイズ−単一オブジェクトのサイズは、装飾プロパティのサイズを最も良く表している実験値から導き出される。
【００７８】
現在の単一オブジェクト（Ｏｎ）と次の単一オブジェクト（Ｏｎ＋１）との間における記号、ライン及びセパレータの存在
オブジェクトのサイズ（幅及び高さ）は、実験値（主観値）に基づいたサイズである。発明者は、１００のウェブページを対象にした実験的試験を行い、これらの試験結果では、画素サイズの幅が＜＝２０、高さが＜＝２０である画像は装飾オブジェクトである傾向があることが示された。
【００７９】
現在の単一オブジェクトが上記の条件を満たしている場合は、装飾（Ｄ）機能５４として分類される。単一オブジェクト内で装飾プロパティが見つからない場合は、本発明は、ステップ４．１４において、情報タイトルプロパティの有無をさらに検査する。
【００８０】
ステップ４．１４において、単一オブジェクトが装飾プロパティを有していないことが決定された時点で、情報機能又は情報タイトル機能として分類される。単一オブジェクトは、以下の判定基準を満たしている場合のみに情報タイトル（ＩＴ）５８として認定される。
【００８１】
タイトルヘッダープロパティを有する
表示オブジェクトである
テキスト又は画像のみであることができる
隣接する表示オブジェクトと比較して異なったスタイルを有する
単一オブジェクトがタイトルプロパティを有していないと決定された場合は、情報（Ｉ）機能５６として分類される。
【００８２】
従って、上記から明らかになるように、このアルゴリズムによって実施された走査プロセス及び比較メカニズムに基づき、整理されたウェブコンテンツ内のすべての単一オブジェクトは、マークアップ言語内における役割を表すための割り当てられた特定機能を含み、従って、コンテンツ解析モジュール２０によって実施された第２のタスクを実行する。
【００８３】
第３のタスクに関して、コンテンツ解析モジュール内にはこのタスクを実行するためのさらなるアルゴリズムが提供されている。この第３のアルゴリズムの目的は、コンテンツを位置決定情報に基づいてクラスタに分類することである。この情報を表しているのは構造タグである。我々が認識して選択した構造タグは以下のとおりである。
【００８４】
＜ＴＡＢＬＥ＞、＜ＦＯＲＭ＞、＜ＦＲＡＭＥＳＥＴ＞、＜ＤＩＶ＞、＜ＵＬ＞、＜ＯＬ＞、＜ＤＬ＞、＜Ｐ＞、＜ＰＲＥ＞、＜ＡＤＤＲＥＳＳ＞、＜ＢＬＯＣＫＱＵＯＴＥ＞、＜Ｈｎ＞、＜ＨＲ＞、＜ＣＥＮＴＥＲ＞、＜ＭＥＮＵ＞、＜ＤＩＲ＞、＜ＴＤ＞及び＜ＮＯＳＣＲＩＰＴ＞
これらの構造タグをオブジェクトクスタリング用のタグとして選択した理由は、オブジェクトをクライアントブラウザー上において表示時にこれらのオブジェクトをビジュアル的に１つにまとめることができるためである。
【００８５】
このタスクを実行するアルゴリズムの動作は単純である。即ち、ウェブコンテンツを構文解析し、上記のタグのうちのいずれかがオブジェクト内に存在するかどうかに基づいてオブジェクトを選択して分類するだけである。
【００８６】
第４のタスク（即ち、表示オブジェクト表示パターンをマッチングし、これらのパターンを分類して１つのグループにまとめるタスク）に関して、次に説明するパターンマッチングアルゴリズムが提供される。
【００８７】
ウェブページは、幾つかのコンテンツチャンク（ｃｈｕｎｋ）を具備すると考えることができる。これらのチャンクは、該当する特定エリア又はタスクに関連するマルチメディアオブジェクトの集合である。基本オブジェクトは、単一のマルチメディア要素（例えば、画像又はテキスト本体）を含むオブジェクトであると定義し、複合オブジェクトは、幾つかの一定の機能をまとめて遂行する一組のオブジェクト（基本オブジェクト又は複合オブジェクト）であると定義すると、１つのチャンクはそれ自体が高位の複合オブジェクトである。ウェブページを幾つかのより小さいページに分割時に理解可能であるためには、コンテンツチャンクが破壊されていないことが重要である。従って、コンテンツを適合させる前に、ページを構成するマルチメディアオブジェクトを可能性のあるチャンクグループに分類する必要がある。
【００８８】
マイクロソフト・リサーチ社のヤン及びチャンは、２００１年に開催された第６回国際ドキュメント解析・認識会議（ＩＣＤＡＲ２００１）において発表したYang, Y. and Zhang, H.J. "HTML Page Analysis Based on Visual Cues"（ビジュアルキューに基づくＨＴＭＬページ解析）の中で、これらのコンテンツチャンクの所在位置を突き止めるシステムについて説明している。以下では、該システムに類似するシステムについて概説する。両システムとも、ＨＴＭＬタグを使用し、マルチメディアオブジェクトの最初の分類を行って可能な複合オブジェクトグループにまとめ、その後にパターンマッチングを実施してさらに可能な分類を見つけ出す。これらのシステム間の相違点は、様々なオブジェクトの類似性を決定するために用いられる距離基準及びパターンマッチングアルゴリズムである。
【００８９】
最初のオブジェクト分類
マルチメディアオブジェクトの最初の分類を行って可能な複合オブジェクトにまとめる前に、HTMLドキュメントの構文解析が行われてｘＨＴＭＬツリーが構築され、ＨＴＭＬタグのクリーンアップ及び処理しやすい構造の形成が行われる。該ｘＨＴＭＬツリーでは、ＨＴＭＬタグが節部（ノード部）に、マルチメディアオブジェクトが葉の部分に存在している。
【００９０】
次のステップは、葉がマルチメディアオブジェクトを含みノードが複合オブジェクト（このため、可能なコンテンツチャンク）を示しているグループツリーを、ウェブページ全体を示す最上ノードまで構築することを含む。ｘＨＴＭＬツリーは、コンテンツ内における自然の区切りと関係する予め定義された一組のＨＴＭＬタグ（主に、＜ｔａｂｌｅ＞、＜ｔｄ＞、＜ｆｏｒｍ＞、＜ｃｅｎｔｅｒ＞及び＜ｈ＞、等のブロックレベルのタグ）の真上に＜ｇ＞タグを最初に挿入することによってグループツリーに変換される。次に、一組のトークン（各型のマルチメディアオブジェクトごとに１つ）が、組になった属性（例えば、テキストストリング内の文字数、又は画像の幅と高さ）とともに定義される。次に、グループツリー内の葉部のマルチメディアオブジェクトから上方に向かってトークンが渡され、葉及び＜ｇ＞タグを含むノード以外のすべてのノードが削除される。トークンは、上方に渡されるときにノードと関係する属性を蓄積させ、１つのノードが２つ以上の子を有する場合は、すべての子が該ノードと関係する属性を受け取る。幾つかのフォーマット化タグ（＜ｔｒ＞、等）は、マルチメディア要素上にどのような属性も置かず、さらに、予め定義された組内のタグとは異なり通常は新しいコンテンツチャンクを示していないため無視される。＜ｇ＞タグノードが２つ以上の子を有する場合は、これらのトークンは、左から右に配置されている子ノードの順序と同じ順序で線形リスト内に配置される。
【００９１】
様々なブロックレベルのタグと関連するオブジェクト（テーブル、セル、等）に可能なグループとしてのラベルを付けることによって、グループツリーは、複合オブジェクト（そしてその結果としてのコンテンツチャンク）の大部分を既に組み入れている。この技術は、常に正確なわけではないが、＜ｇ＞タグはどのようなコンテンツチャンクも分割しないと想定している。しかしながら、フォーマット化オブジェクトのコンテンツにラベルを付けることは、類似のマルチメディアオブジェクトの配置を繰り返すことを通じて黙示されているコンテンツチャンクどおしを区別するわけではない。従って、グループツリーがいったん導き出された時点で、各＜ｇ＞ノードの子ノードに属するトークンリスト上においてパターンマッチングが行われる。
【００９２】
パターンマッチング
パターンマッチングプロセスにおける第１のステップは、各々の子ノード内のトークンリストのうちのどのトークンリストが類似しているかを決定することである。各トークンは、該トークンと関係する一組の属性を有することに注意すること。各属性は、型と値の対、例えば（フォント、１４ｐｔ）及び（幅、１００）を含む。これらの値は、ストリング又は整数であることができる。属性型が関係する値を本質的に有していない場合は、この値は、ヌルストリング、例えば（ボールド，）に設定される。トークンを比較時に、いずれかの特定のトークンが該トークンと関係する属性を有していない場合は、該トークンは、属性の組が空でないようにするために特別のヌル属性（ ，）が割り当てられる。
【数１】
【００９３】
トークンリストの比較は、動的時間ワープ（動的ブログミングアルゴリズム）によって実施され（表１参照）、整合経路は、（最小トークンの長さに比例する）所定の数の場所を超えて対角線から外れることが許容されておらず、更に、非対角の動きに関する罰則も組み入れている。整合経路に沿った類似性基準の和がしきい値よりも大きい場合は、２つのトークンリストは、同一であることを理由に、又は長さと組成の点が少々異なっているにすぎない場合に、類似しているとみなされる。
【表１】
【００９４】
パターン検出時には、より低い三角マトリクス（対角要素がないもの）が最初に構築され、子ノード（トークンリスト）のうちのいずれが互いに類似しているかが詳述される。次に、すべての可能なパターンを検討することによって、最大数の子ノードを網羅した類似ノードの繰り返しシーケンスである有意トークンパターンが見つけ出される。この有意トークンパターンは、各新グループの始まりを示している。
【００９５】
意味のない有意トークンパターンが出現するのを防止するために以下のような幾つかの制限条件が適用される。
【００９６】
該パターンは、長さが少なくとも２つの子ノードでなければならない
該パターンは、少なくとも２回繰り返されなければならない
同じパターンのインスタンスが重複しないこと
これらの有意トークンは、グループ（又はコンテンツチャンク）の始まりを示しているため、これらのグループ間で重複しないようにしさらに妥当な類似性を確保しながら後続する子ノードをこれらのグループ内に加えることによって、これらのグループ自体が拡大される。
【００９７】
上記の結果、コンテンツ解析モジュール２０によって実行された４つのタスクが終了することになる。これらのタスクを実行後は、システムは、検索されたウェブページコンテンツに基づいてＸＭＬツリーを構築していることになる。このツリーは、ウェブコンテンツに関する様々な追加情報を含み、現時点では、適合化モジュールに引き渡すのに適したフォーマットになっている。このプロセスによって提供されている情報は、下記の項目に関連する情報である。
【００９８】
ｉ）適合化中に分離されることが想定されていない分割不能なグループ（即ち、上記の「チャンク」）
ｉｉ）グループ及び単一オブジェクトの機能（無視又は削除できるかどうかを示す）
ｉｉｉ）コンテンツソースの総表示画素数及び文字数（コンテンツをより小さいページに分割すべきかどうか/どのように分割するかを決定時に適合化モジュールによって用いられる）
ｉｖ）コンテンツソースの原構造情報及び原スタイル情報 ここでの構造は、コンテンツのレイアウトを意味する。構造情報は、コンテンツの配備方法及び位置決め方法に関するコードを含む。スタイルは、コンテンツのオブジェクト（テキスト又は画像、等）の幅、高さ、色、フォント属性（フォントの種類と大きさ）、等を意味する。
【００９９】
このプロセスによって生成されたＸＭＬツリーのフォーマットは、現時点においては、別個のウェブページ上において表示するためにコンテンツのどの箇所を分割することが許容されているかを識別する識別子（＜ｇ＞タグと呼ばれる）を含む。＜ｇ＞タグは、前述されているように、コンテンツ内における自然の区切り（例えば、＜ｔａｂｌｅ＞、＜ｔｄ＞、＜ｆｏｒｍ＞、等のブロックレベルタグ）及びひとつにまとめて表示すべきである該当コンテンツグループの両方に基づいて複数の＜ｇ＞タグが挿入されている。階層ツリーフォーマットでは、これらの＜ｇ＞タグがツリーの分割可能な箇所を示す幾つかのノードを形成していて、従って最下位の＜ｇ＞タグ（即ち、葉に最も近い＜ｇ＞タグ）はそれよりも下方ではコンテンツ分割が許容されていないノード（即ち、異なったウェブページにわたって広げることができない分割不能なコンテンツグループ）であることを意味している。
【０１００】
ＸＭＬツリーの追加の側面として、ＸＭＬツリーは、第２の型の識別子を含む。これらの識別子は、個々のコンテンツオブジェクト（即ち、画像又はテキスト本体等の単一マルチメディア要素）又は複合オブジェクト（一定の機能をいっしょに果たす一組のオブジェクト）のいずれかのオブジェクトと関連するラベルである。類似しているオブジェクト、例えば、型が同じでありさらにスタイル属性とその他の特性（画像サイズ又はテキスト文字数、等）のリストが類似しているオブジェクトは、同じ識別子タグが付けられる。（後述する）適合化プロセス中は、これらのラベルは、類似するオブジェクトをウェブページ上で表示するために処理中にこれらのオブジェクトが同じに取り扱われる（例えば、すべての類似画像／テキストボックスが同じ率で縮小される）ようにするために用いられる。
【０１０１】
既述されているように、コンテンツ解析モジュール２０は、現時点において、解析結果（ＸＭＬツリーの結果）を適合化モジュール１６に引き渡す。次に、適合化モジュール１６は、プロフィールサーバー２６から入手可能な（そしてこの動作モードで予め生成された）すべてのクライアント能力デバイスプロフィールを検索する。次に、適合化モジュール１６は、入手可能なプロフィールに基づいて異なったウェブコンテンツバージョンを生成するアルゴリズムを実行するループをトリガーする。実施されるループ数は、入手可能なプロフィール数に依存する。基本的には、各クライアント能力プロフィールごとにコンテンツ適合化バージョンが生成される。
【０１０２】
コンテンツを適合させるためにＸＭＬツリー上で動作するアルゴリズムは、図５及び６の流れ図に示されている。図５は、コンテンツが表示装置に関する現在のプロフィール範囲内に納まるかどうを検査するアルゴリズムを示している。このアルゴリズムは、幾つかの段階を循環的に実施し、コンテンツがページ（即ち、表示装置）に適合するかどうかを毎回検査する。適合しない場合は、該アルゴリズムは、幾つかの変換を実施してコンテンツのサイズを漸進的に縮小する。図５のアルゴリズムは、図６に示されているアルゴリズムの全段階のうちの１つだけを形成しており、（必要な場合に）コンテンツを分割して複数の異なったページ上に置くようにさらに動作する。
【０１０３】
最初に図６のアルゴリズムに関して、このアルゴリズムの目的は、コンテンツが大きすぎるため所定の表示装置の単一ページ上に表示できない場合は該コンテンツをより小さいページに分割しその一方でこれらのページ上に存在する空白スペース量を最小限にすることである。該アルゴリズムは、該分割を行うために、ＸＭＬツリー構造内の＜ｇ＞タグを使用する。該アルゴリズムは、最上位の＜ｇ＞ノードを出発点としてツリー全体にわたってノードからノード（＜ｇ＞ラベルが貼付されたノード）へ移動する。該アルゴリズムは、各ノードにおいて、下方のサブツリー内のコンテンツが表示装置に適合するかどうかを計算し、マルチメディアオブジェクトの変換（フォントサイズ／画像サイズの縮小、等）を適宜行う。現在の＜ｇ＞ノードの下方のコンテンツが表示装置に適合しない場合は、該アルゴリズムは、下方の子＜ｇ＞ノードに移動し、ウェブページ全体が複数のより小さいウェブページとして出力されるまでこれらの子＜ｇ＞ノードの各々に関する再計算を実施する（必要な場合はさらに分割する）。
【０１０４】
さらに詳細に説明すると、図６において、該アルゴリズムによって実行されるステップは次のとおりである。２箇所の一時的保存領域（スタック“Ｑ”及び“Ｔ”）は、処理中にこれらのノードを一時的に保存するために用いられる。第３の保存領域であるアレイ“Ｔｒａｎｓ”は、ウェブページ内の様々なオブジェクトに関して実施される変換（フォントサイズ又は画像サイズの縮小、等）に関連するデータを保存するために用いられる。
【０１０５】
適合化アルゴリズムは、ステップＳ６．１から開始する。最初に、該アルゴリズムは、最上位の＜ｇ＞ノードをツリーから取り出してスタックＱの中に入れる（ステップＳ６．２）。該アルゴリズムは、一時的スタックＴがクリアされていることも確認する（ステップＳ６．３）。次に、該アルゴリズムは、ステップＳ６．４に移動し、ステップＳ６．４において、以下においてさらに詳細に説明されている関数ｆｉｔｓ＿ｐａｇｅ（Ｔ，Ｔｒａｎｓ）を呼び出し、Ｔ内に現在保存されている＜ｇ＞ノードがクライアントディスプレイ内に納まるかどうかを検査し、マルチメディアオブジェクトに関する変換を適宜実施する。しかしながら、この時点ではスタックＴは空であるため、ｆｉｔｓ＿ｐａｇｅ（Ｔ，Ｔｒａｎｓ）はＴＲＵＥを戻す。処理は、ステップＳ６．５に進み、ステップＳ６．５において、関数ａｒｅ＿ｓｉｂｌｉｎｇｓ（Ｔ）を用いて、スタックＴ内のすべてのノードが同じ親を有するかどうかを検査する。同じくＴは空であるため、該関数はＴＲＵＥを戻して処理をステップＳ６．６に進ませ、ステップＳ６．６において、スタックＱ内にノードが残っているかどうかを検査する。Ｑ内にはノードが存在するため（最上位の＜ｇ＞ノードは現在はＱ内にある）、処理はステップＳ６．７に進み、ステップＳ６．７において、スタックＱの最上位からスタックＴ上にノードを移動させ、処理は、ステップＳ６．４に戻る。
【０１０６】
この時点では、ツリーの最上位＜ｇ＞ノードはスタックＴ内にあり、このため、ステップＳ６．４は、関数ｆｉｔｓ＿ｐａｇｅ（Ｔ，Ｔｒａｎｓ）を用いて、このノード（即ち、その下方にある全サブツリーのウェブコンテンツ）がクライアントデバイスのディスプレイ内に納まるかどうかを検査し、オブジェクトに関する変換を適宜実施する。このステップは、図５に示されているアルゴリズムを含む。この段階においては、該アルゴリズムは、（スタックＴ内に現在保存されているノードは最上位ノードであるため）ウェブページコンテンツ全体が表示装置内に納まるかどうかを検査中である。コンテンツが表示装置内に納まることができる大きさである場合は、該アルゴリズムは、ステップＳ６．５を通ってステップＳ６．６に進んで終了する。スタックＱ内にはノードが残っていないため、プロセスは、ステップＳ６．１５に飛び越し、ステップＳ６．１５において、（関数ｒｅｎｄｅｒ（Ｔ，Ｔｒａｎｓ）の呼び出しを用いて）ツリー全体を出力して終了する。
【０１０７】
しかしながら、ウェブページコンテンツ全体が表示装置内に納まらない場合は、ステップＳ６．４の答えはいいえ（Ｎ）であり、処理は、ステップＳ６．８に進み、ステップＳ６．８において、最上位ノードをスタックＴから取り除いてノードＮとして保存する。次に、ステップＳ６．９において、スタックＴには依然としてノードがないため、処理は、ステップＳ６．１０に進み、ステップＳ６．１０において、ノードＮが葉であるかどうかを検査する。この段階では（ノードＮは最上位＜ｇ＞ノードであるため）答えはいいえ（Ｎ）であり、このため、処理は、ステップＳ６．１１に進み、ステップＳ６．１１において、ノードＮのすべての直接的な子＜ｇ＞ノードを処理するためにスタックＱ上に置く。次に、ステップＳ６．１２は、処理すべきノードがスタックＱ内に存在するかどうかを検査する。この段階では、ＸＭＬツリーの最上位ノードのすべての直接的子＜ｇ＞ノードがスタックＱ内にあり、このため、処理は、ステップＳ６．３に戻り、一時的スタックＴをクリアする。
【０１０８】
次に、処理は、ステップＳ６．４、Ｓ６．５、Ｓ６．６及びＳ６．７内を進み、直接的子ノードのうちの第１の子ノードをスタックＱからスタックＴに移動させる。ウェブコンテンツのうちでクライアント表示装置内に納まる大きさである（即ち、ステップＳ６．４がＴＲＵＥを戻す）のはこの部分（即ち、この子ノードの下方のサブツリー内のコンテンツ）である。この場合は、処理は、ステップＳ６．４、Ｓ６．５、Ｓ６．６及びＳ６．７内を再び通り、スタックＱの第２の子ノードをスタックＴに加える。このプロセスは、無期限に繰り返され、ウェブコンテンツのうちのこの結合部分（即ち、スタックＴに加えられた全ノード部分）が依然としてクライアントディスプレイ内に納まるかどうかを毎回検査する。いずれかの時点においてソースコンテンツ（即ち、Ｔ内のノードリストによって表されている現在のコンテンツ部分）がディスプレイに適合しない（即ち、ステップ６．４における答えがいいえである）場合は、処理はステップＳ６．８に進み、ステップＳ６．８において、スタックＴに加えられた最後のノード（該スタックにおいて最高位のノード）がスタックＴから取り除かれてノードＮとして保存される。次に、ステップＳ６．９は、スタックＴ内にノートがまだ残っているかどうかを検査し、残っている場合は、処理はステップＳ６．１３に進み、ステップＳ６．１３において、ノードＮは、のちに処理するために、最初の保存領域（即ちスタックＱ）に戻される。次に、関数ｒｅｎｄｅｒ（Ｔ，Ｔｒａｎｓ）の呼び出しを用いて、ＸＭＬツリーの１つのセクション（即ち、現在スタックＴ内にあるノードによって表されているコンテンツ）が、適合化されたより小さいページのうちの１つとして出力される。該アルゴリズムは、ステップＳ６．１２に進み、処理するためのノードがスタックＱ内に残っているかどうかを決定する。処理するためのノードがスタックＱ内に残っている場合は、ステップＳ６．３に戻る。
【０１０９】
該アルゴリズムは、図６に示されている全ステップを実行後、ツリー全体にわたって処理を繰り返し、コンテンツを変換してディスプレイに適合させることが可能であるかどうかを（関数ｆｉｔｓ＿ｐａｇｅ（Ｔ，Ｔｒａｎｓ）を用いて）確認し、適合させることができない場合は、該コンテンツをさらに小さく分割する。この分割は、該アルゴリズム内において次のプロセスによって達成される。即ち、ノード下方のコンテンツが表示装置内に納まることができないごとに、ステップＳ６．１１において、その直接的子＜ｇ＞ノードがのちに処理するために別個に保存領域（スタックＱ内の待ち行列）内に加えられる。このプロセスは、コンテンツをより小さい部分に分割し、このため、サブツリーを個々に検査して該コンテンツがクライアントデバイス上に表示するのに適したサイズであるかどうかを確認することができる。次に、ディスプレイに適合するあらゆるコンテンツ部分に関して、ディスプレイ内における空白スペース量を最小限にするために、これらのコンテンツ部分を該コンテンツのその他の部分と結合させることが試みられる（即ち、ステップＳ６．７）。しかしながら、異なったコンテンツ部分のこの結合は、対象ノードが兄弟である（即ち、ツリー内において同じ親＜ｇ＞ノードを有する）場合にしか行われない。このようにして、適合化アルゴリズムは、最上位の＜ｇ＞ノードから最下位の＜ｇ＞ノードの葉（さらなるコンテンツ分割が許容されている最下位の葉）までツリー全体にわたって進行する。
【０１１０】
ＸＭＬツリー内におけるウェブコンテンツ構成が階層ツリー構成であるおかげで、及び、適合化アルゴリズムによって実行されるステップの順序のおかげで、コンテンツ表示時に最上部から最下部に及び左から右に進む順序が維持される。更に、単一ページ上には（同じレベルのグループの）全体的な関連した複合オブジェクトのみが表示されることになる。
【０１１１】
更に、該アルゴリズムは、すべてのより小さいページを通じて類似オブジェクトの表示の一貫性を確保する。この確保は、オブジェクトに関して既に実施されている変換のリストを該オブジェクトと関係するオブジェクトラベル（類似するオブジェクトを示す前述の第２の型の識別タグ）とともに維持する保存領域（例えば、Ｔｒａｎｓと呼ばれるアレイ）を用いることによって達成される。コンテンツの各部分に関して、該アルゴリズムは、類似するオブジェクトに関して実施されている変換が首尾一貫していることを確認するために、アレイＴｒａｎｓを検査してこれらのオブジェクトに対して既に変更が加えられているかどうかを確認する。アレイＴｒａｎｓは、関数ｆｉｔｓ＿ｐａｇｅ（）がコンテンツ部分に関して新たな変換を成功裡に行なってページサイズ内に納まるごとに処理中に動的に更新される。
【０１１２】
上記の適合化アルゴリズムに関する説明全体を通じて、処理中に一時的にノードを保存するために用いられる２つの保存領域（スタック“Ｑ”及び“Ｔ”）を挙げていることを理解すべきである。該アルゴリズムの機能上、これらの保存領域は、これらのノードと関係する適切なコンテンツ部分を保有するとみなすことができる。この場合、これらの保存領域自体は、実際には、メモリの別の部分内におけるコンテンツの保存場所を指し示す単なるメモリアドレスリストとして実装されるにすぎないにもかかわらずこのようにみなすことができる。
【０１１３】
ウェブページを適合させるための適合化アルゴリズム（疑似ジャバコード）の典型的実施形態を以下に示した。
【表２】
【０１１４】
以下の関数がＳｐｌｉｔＰａｇｅ（）によって使用される。
【０１１５】
ｉｓ ｌｅａｆ（Ｎ）
一時的ノードＮが葉である場合にＴＲＵＥを戻す
ａｒｅ ｓｉｂｌｉｎｇｓ（Ｔ）
スタックＴ内のノードが同じ親＜ｇ＞ノードを共有している（又は、Ｔが単一ノードを含むか又は空である）場合にＴＲＵＥを戻す
ｆｉｔｓ ｐａｇｅ（Ｔ，Ｔｒａｎｓ）
スタックＴ内のノード（即ち、これらのノードの下方のすべてのサブツリーのコンテンツ）が表示装置内に納まる上で十分に小さいかどうかを決定する 最初に、スタックＴがＴｒａｎｓ内のノードと同じ識別子ラベルを有するノードを含む場合は、関係する変換がこれらのオブジェクトに関して実施される。これでコンテンツがページに適合する場合は、ｆｉｔｓ ｐａｇｅ（Ｔ，Ｔｒａｎｓ）がＴＲＵＥを戻す。
【０１１６】
しかしながら、コンテンツが依然としてページに適合しない場合は、いくつかの異なった変換をコンテンツに関して実施することができ、これらの変換は、図５に示されている。これらの追加のオブジェクト変換のうちのいずれかを実施した結果コンテンツが表示装置に適合することになった場合は、これらの変換は、該当するオブジェクトラベルとともにアレイＴｒａｎｓに追加され、ｆｉｔｓ ｐａｇｅ（Ｔ，Ｔｒａｎｓ）がＴＲＵＥを戻す。
【０１１７】
代替として、可能であるすべての追加変換を実施後も依然としてソースコンテンツが表示装置に適合しない場合は、ｆｉｔｓ ｐａｇｅ（Ｔ，Ｔｒａｎｓ）はＦＡＬＳＥを戻す。
【０１１８】
関数ｆｉｔｓ ｐａｇｅ（Ｔ，Ｔｒａｎｓ）は、スタックＴが空である場合もＴＲＵＥを戻す。
【０１１９】
ｒｅｎｄｅｒ（Ｎ，Ｔｒａｎｓ）、ｒｅｎｄｅｒ（Ｔ，Ｔｒａｎｓ）
コンテンツの一部分（即ち、ＸＭＬツリーの１つ以上のノードによって表されているコンテンツ）を、適合化されたより小さいページの１つとして出力するために使用する。該関数は、ノードＮとアレイＴｒａｎｓの入力パラメータ、又はスタックＴとアレイＴｒａｎｓの入力パラメータのいずれかを有する。Ｔｒａｎｓは、今日までに提供されているオブジェクト識別子ラベル、及びこれらの識別子ラベルに関係する変換とパラメータを含むため、Ｎ又はＴがＴｒａｎｓ内のラベルと同じラベルを有するオブジェクトを含む場合は、該当する変換がこれらのオブジェクトに関して実施される。残りのオブジェクトは適宜変換され（即ち、空白スペース量を最小限に抑えながら所定の表示装置に適合させ）、これらのラベル及び変換がＴｒａｎｓに加えられる。最後に、Ｔｒａｎｓが該関数によって戻される。
【０１２０】
上述されているように、関数呼び出しｆｉｔｓ＿ｐａｇｅ（Ｔ，Ｔｒａｎｓ）中において、コンテンツがプロフィール範囲（所定の表示装置、等）に適合しない場合は、幾つかの異なった変換を該コンテンツに関して実施することができ、ここでは、図５を参照しつつこれらの変換についてさらに
詳細に説明する。この機能を果たすアルゴリズムは、以下の検査を行う。
【０１２１】
ｉ）ソースコンテンツのすべての画素及び文字をプロフィール範囲内に納めることができるかどうかを検査する
ｉｉ）空白スペース及びラインを取り除いた後にソースコンテンツをプロフィール範囲内に納めることができるかどうかを検査する
ｉｉｉ）表示オブジェクトのプロパティの削除、サイズ変更、要約、及び変更によってソースコンテンツがプロフィール内に納まるかどうかを検査する
これらの検査は、８つの可能な変換によって具体化される。これらの変換は順に実施されるが、各変換を実施後に、所定の表示装置に関するクライアント能力プロフィールを参照することによって、その時点までに変換されたコンテンツを該表示装置上に表示できるかどうかを決定するための評価が行われる。表示可能であると決定された場合は、追加の変換は実施されない。表示不能であると決定された場合は、すべての８つの変換が実施される。
【０１２２】
順に利用可能な変換は以下のとおりである。
【０１２３】
第１の変換： フォントの縮小 “ｖｅｒｄａｎａ”をフォントファミリーとして原フォントをより小さいフォントサイズに変換する
第２の変換： 画像の縮小 画像オブジェクトを１０％だけ縮小し、最適のサイズ又は５０％になるまで繰り返す
第３の変換： 制御オブジェクトの縮小 変換した結果該オブジェクトの最適なサイズよりも大きい場合に、デフォルトの画面の大きさとクライアントデバイスの比に基づいてオブジェクトを縮小する
第４の変換： スペースの削除 段落間の不要なスペースを取り除く
第５の変換： ラインの削除 第４の変換と同じ目的である
第６の変換： 装飾画像の削除 装飾プロパティを有する画像をオブジェクトのサイズに基づいて削除する
第７の変換： 装飾テキストの削除： 装飾として機能する冗長なテキストを取り除く（これらのテキストが特殊文字である場合）
第８の変換： 画像の入れ替え： 画像に代わる代替テキストが存在する場合は、アルゴリズムは、該代替テキストのサイズと画像自体を比較し、短いほうが適合結果として選択される。
【０１２４】
図５は、変換アルゴリズムをより詳細に示した図であり、特に、実施可能な８種類の変換を示した図である。図５において、同図によって提供されている手順は、ステップ５．１において開始され、２つのカウンタが初期設定される。より具体的には、第１のカウンタｉがｉ＝１に初期設定され、第２のカウンタｒがｒ＝０に初期設定される。
【０１２５】
次に、処理はステップ５．２に進み、ステップ５．２において、ウェブコンテンツが所定の表示装置のディスプレイ内に納まるかどうかを決定するための評価が行われる。この評価は、該コンテンツの特徴と、プロフィールサーバー２６のクライアント能力プロフィール内において提供されているクライアントデバイス表示能力特性と比較することによって実施される。特定の適合化されたバージョンを生成する場合は、ステップ５．２において、クライアント能力プロフィールのうちで、適合化アルゴリズムの現在のインスタンス化によって適合化バージョンが生成中である単一のクライアント能力プロフィールと対照する評価が常に実施される。
【０１２６】
ウェブコンテンツが所定の表示装置のディスプレイ内に納まることがステップ５．２における評価によって示され、変換を実施する必要がない場合は、変換アルゴリズムは、ステップ５．３において終了し、関数ｆｉｔｓ＿ｐａｇｅ（）に関してＴＲＵＥを戻す。
【０１２７】
反対に、ウェブコンテンツが所定の表示装置のディスプレイ内に納まらないことがステップ５．２における評価によって示された場合は、処理はステップ５．４に進み、ステップ５．４において、カウンタｉ＝１であるかどうかを決定するための評価が行われる。ここで、アルゴリズムがステップ５．１において初めて開始されたときにはカウンタｉは１に初期設定されるということを思い出されることになり、従って、ステップ５．４における評価は肯定応答を返し、処理はステップ５．６に進む。ステップ５．６においては、フォント縮小を目的とする第１の変換が開始され、ステップ５．８及び５．１０の形になる。
【０１２８】
ステップ５．８において、適合させるウェブコンテンツ内の全テキストに関するフォントサイズが１に設定される。但し、その他の実施形態においては、その他の値を選択することができる。次に、ステップ５．１０において、ウェブコンテンツ内の全テキストに関するフォントの種類が“ｖｅｒｄａｎａ”に設定される。これらのステップは、ウェブコンテンツ内のすべてのテキストオブジェクトのサイズを大幅に縮小する結果になる。処理は、これらのステップ後はステップ５．１２に進み、ステップ５．１２において、カウンタｉの値が１だけ増やされる。次に、処理は、ステップ５．２の評価に戻り、ステップ５．２において、変換されたウェブコンテンツが今度は所定の表示装置のディスプレイ内に納まるかどうかを決定するための評価が行われる。ステップ５．２における該評価が肯定応答を返した場合、即ち、現時点においてウェブコンテンツを所定の表示装置において表示可能である場合は、プロセスは、ステップ５．３に進んで終了する。反対に、さらなる変換を実施する必要がある場合は、処理は、ステップ５．４に進み、ステップ５．４において、カウンタｉ＝１であるかどうかに関する評価が行われる。カウンタｉはステップ５．１２において値が増やされて現在は２になっているため否定値が返され、処理はステップ５．１４における評価に進み、ステップ５．１４において、カウンタｉが２であるかどうかに関する評価を行う。ここでは、肯定値が返され、処理は、ステップ５．１６に進む。
【０１２９】
ステップ５．１６において、画像縮小変換が開始される。画像縮小変換では、最初にステップ５．１８において、該画像に関して可能な最大縮小値が入手される。この最大縮小値は、ハードコード値（例えば５０％）である。次に、ステップ５．２０において、最大縮小値がカウンタｒの値の１０倍よりも大きいかどうかに関する評価が行われる。ここで、ステップ５．１においてカウンタｒの値がゼロに初期設定されたことが思い出されることになり、従って、最初の循環時点では、ステップ５．２０における評価は、肯定応答を返す。次に、処理はステップ５．２２に進み、ステップ５．２２において、ウェブコンテンツ内の画像が１０％だけ縮小される。次に、処理は、ステップ５．２４に進み、ステップ５．２４において、カウンタｒの値が１だけ増やされ、ステップ５．２６に進む。ステップ５．２６において、ｒ＝５であるかどうかに関する評価が行われる。最初の循環時点においては、ｒはステップ５．２４において値が増やされていて１になっており、従って、ステップ５．２６の評価は否定値を返す。この場合は、処理は、直接ステップ５．２に戻り、ステップ５．２において、変換されたコンテンツが所定の表示装置のディスプレイ内に納まるかどうかに関する評価が実施される。変換されたコンテンツが所定の表示装置のディスプレイ内に納まる場合は、処理は、ステップ５．３において終了する。変換されたコンテンツが所定の表示装置のディスプレイ内に納まらない場合は、処理は、ステップ５．４を介してステップ５．１４に進み、ステップ５．１４においては、カウンタｉはまだ数が加えられていないため、肯定応答結果が返され、ステップ５．１８、５．２０、５．２２、５．２４及び５．２６の画像縮小変換が再度実施される。
【０１３０】
図５から明らかなように、画像縮小変換は最高５回実施することができ、各繰り返しにおいて画像縮小変換を実施するごとに画像のサイズがさらに１０％だけ縮小され、他方、利用可能な最大画像縮小値がｒの現在値の１０倍よりも大きくない場合は、利用可能な最大縮小値分だけ縮小される。しかしながら、いずれの場合においても、変換は、カウンタｒ＝５になるまで５回反復的に実施される。カウンタｒ＝５の時点で、ステップ５．６の評価が肯定応答を返し、処理は、ステップ５．１２に進み、ステップ５．１２において、カウンタｉの値が増やされる。処理は、ステップ５．１２からは常にステップ５．２戻り、ステップ５．２において、現時点ではコンテンツが所定の表示装置のディスプレイ内に納まるかどうかに関する評価が行われる。既に実施済みの変換が十分である場合は、この評価は、肯定値を返し、処理は、ステップ５．３において終了する。既に実施済みの変換が十分でなく、さらなる変換が必要な場合は、処理は、ステップ５．４を介して更に今回は（現在はｉ＝３であるため）ステップ５．１５も介してステップ５．３０に進む。
【０１３１】
ステップ５．３０において、カウンタｉが３であるかどうかに関する評価が行われ、カウンタｉが３である場合は、処理は、ステップ５．３２に進み、ステップ５．３２において、制御オブジェクト縮小変換が開始され、ステップ５．３４に進む。
【０１３２】
ステップ５．３４において、ウェブコンテンツに関するデフォルトの画面サイズと所定の表示装置の実際の画面サイズの比が得られる。ステップ５．３６において、この比に基づき、この比をデフォルトサイズに当てはめることによって、各制御オブジェクトのサイズが計算される。次に、ステップ５．３８において、各制御オブジェクトに関する計算されたサイズが各オブジェクトに関する最小許容サイズよりも小さいかどうかに関する評価が行われる。該計算されたサイズが該最小許容サイズよりも小さくない場合は、処理は、ステップ５．４２に進み、ステップ５．４２において、計算された比に基づいて制御オブジェクトのサイズを縮小することができる。しかしながら、該計算されたサイズが各制御オブジェクトの該最小許容サイズよりも小さい場合は、処理は、ステップ５．４０に進み、ステップ５．４０において、ウェブコンテンツ内の制御オブジェクトのサイズが最小許容サイズに基づいて縮小される。該最小許容サイズは、事前に決定される。
【０１３３】
ステップ５．４０又はステップ５．４２の後は、処理は、ステップ５．１２に進み、ステップ５．１２において、カウンタｉの値が増やされる。次に、ステップ５．２に進み、ステップ５．２において、変換されたコンテンツが所定の表示装置のディスプレイ内に納まるかどうかに関する評価が行なわれる。
【０１３４】
ステップ５．２の評価が否定応答を返すと想定した場合、カウンタｉの値は現在は４であり、従って、処理は、ステップ５．４、５．１４及び５．３０を介してステップ５．４４に進み、ステップ５．４４において、ｉ＝４であるという評価が肯定値を返す。この結果は、処理をステップ５．４６に進め、ステップ５．４６において、スペース削除変換が開始される。
【０１３５】
この変換は、ウェブコンテンツ内のオブジェクトタグを検討すること、及び特定のタグを有するオブジェクト及び／又はその他の一定条件を満たしているオブジェクトを削除することに関連する。従って、ステップ５．４８において、タグ＜ＢＲ＞を有していて、タグ＜ＴＤ＞と＜ＤＩＶ＞を持つオブジェクトの最初の子と最後の子であるオブジェクト、が取り除かれる。次に、ステップ５．５０において、タグ＜ＢＲ＞を有していて、タグ＜Ｔａｂｌｅ＞を有するオブジェクトの兄弟であるオブジェクト、も削除される。次に、ステップ５．５２において、ウェブコンテンツ表示オブジェクト内のすべての連続した空白スペースが単一のスペースに減らされ、それに応じて、ステップ５．５４において、ウェブコンテンツ表示オブジェクト内のすべての連続した区切り部分が１つに減らされる。最後に、ステップ５．５６において、＜ｔａｂｌｅ＞オブジェクトのセルパディング及びセルスペーシング値がゼロに減らされる。このスペース削除変換結果、ウェブコンテンツ内の空白スペースが絶対最小値に縮小される。
【０１３６】
ステップ５．５６の後は、処理はステップ５．１２に進み、ステップ５．１２において、カウンタｉの値が５に増やされる。次に、ステップ５．２における評価が実施され、変換されたコンテンツが現在は所定の表示装置のディスプレイ内に納まるかどうかが決定される。変換されたコンテンツが所定の表示装置のディスプレイ内に納まる場合は、処理は５．３において終了する。変換されたコンテンツが所定の表示装置のディスプレイ内に納まらない場合は、処理は、ステップ５．４、ステップ５．１４、ステップ５．３０及びステップ５．４４を介してステップ５．５８に進み、ステップ５．５８において、ｉ＝５であるという評価が肯定応答を返す。その後は、ステップ５．６０において、ライン削除変換が実施され、ステップ５．６２において、＜ＨＲ＞タグを有するすべての表示オブジェクトが削除される。この機能は、本質的に、以前に実施された第４変換と同じ機能、即ち、空白スペースを減らす機能を有する。
【０１３７】
ステップ５．６２の後は、処理は、再度ステップ５．１２に戻り、ステップ５．１２において、カウンタｉの値が増やされる。次に、ステップ５．２の評価が再度実施され、処理は、該評価が否定的な結果を出すと想定し、ステップ５．４、５．１４、５．３０、５．４４、及び５．５８を介してステップ５．６４に進む。ステップ５．６４における評価は、ｉが６に増やされているため肯定的な結果を出す。
【０１３８】
従って、ステップ５．６４の後は、処理は、ステップ５．６６に進み、ステップ５．６６において、装飾テキスト削除変換が開始される。この変換は、ステップ５．６８において実施され、ステップ５．６８においては、装飾目的の機能であることがコンテンツ解析モジュール３０によって検出されたテキストがウェブコンテンツから削除される。
【０１３９】
ステップ５．６８の後は、処理は、ステップ５．１２に戻り、ステップ５．１２において、カウンタｉの値が増やされる。次に、ステップ５．２における評価に戻り、変換されたコンテンツが現在は所定の表示装置のディスプレイ内に納まるかどうかに関する評価が行なわれる。処理は、変換されたコンテンツが所定の表示装置のディスプレイ内に納まらないと想定し、ステップ５．４、５．１４、５．３０、５．４４、５．５８、及び５．６４の各々の評価を行ってステップ５．７０に進み、ステップ５．７０において、現在はカウンタｉが７の値を有しているため、肯定的な結果が戻される。このことは、処理をステップ５．７２に進ませ、ステップ５．７２において、装飾画像削除変換が開始される。ステップ５．７４において、装飾オブジェクト機能を有することがコンテンツ解析モジュール２０によって検出された画像又はオブジェクトが削除される。以上のように、ウェブコンテンツの真の意味コンテンツに貢献しない画像が削除される。
【０１４０】
ステップ５．７４の後は、処理は、再び５．１２に戻り、ステップ５．１２において、カウンタｉの値が増やされる。その後は、変換されたコンテンツがこの時点では所定の表示装置のディスプレイ内に納まるかどうかに関するステップ５．２の評価が行なわれる。処理は、この評価が否定値を返すと想定し、ステップ５．４、ステップ５．１４、ステップ５．３０、ステップ５．４４、ステップ５．５８、ステップ５．６４、及びステップ５．７０の各々の評価を経てステップ５．７６に進む。ステップ５．７６においては、現時点ではｉが８であるかどうかに関する評価が行なわれる。この評価は肯定的な結果を戻すため、処理は、ステップ５．７８に進み、ステップ５．７８において、画像交換変換が開始される。この画像交換変換は、ステップ５．８０において開始され、各画像表示オブジェクトに関して、画像が代替テキストを有するかどうかに関する評価が行なわれる。画像が代替テキストを有する場合は、処理は、ステップ５．８２に進み、ステップ５．８２において、画像に関する代替テキストの全体的な画素サイズが画像自体よりも小さいかどうかに関するさらなる評価が行なわれる。該画素サイズが画像自体よりも小さい場合のみに、画像が代替テキストに代えられる。明確なことであるが、代替テキストが画像よりも大きいスペースを占めることになるのでは、該画像を代替テキストに代えてもほとんど意味がない。ステップ５．８４において交換後は、処理は、ステップ５．１２に戻る。同様に、ステップ５．８０及びステップ５．８２の評価のうちのいずれかの評価が否定値を戻した場合、即ち、画像が代替テキストを有していない場合、又は、代替テキストが既存の画像サイズよりも小さくない場合は、処理は同じくステップ５．１２に戻る。ここでは、処理がステップ５．１２に戻ってカウンタｉの値が増やされる前に、図５において示されている画像変換が実施されることに注目すべきである。更に、ウェブコンテンツ内の複数のオブジェクトを対象にしたこの処理は、次の変換を実施することを可能にするカウンタｉの値が増えされる前にウェブコンテンツ内のすべての該当オブジェクトに関して各変換が実施されるという点で、前述されている変換の各々に関して実施される。
【０１４１】
ステップ５．１２において、再度カウンタｉの値が増やされ、従って、この事例においては現時点では値９を有する。このため、処理がステップ５．２における評価に戻った時点では、ｉが８よりも大きいという代替評価条件が満たされており、このための変換アルゴリズムは終了しなければならない。
【０１４２】
上記の説明から、変換アルゴリズムは、ウェブコンテンツ内の表示オブジェクトに関して各変換を実施し、更に各変換を実施後は、変換されたウェブコンテンツは所定の表示装置のディスプレイ上において表示できるかどうかに関する評価を行うように動作することがわかることになる。変換されたウェブコンテンツが所定の表示装置のディスプレイ上において表示できる場合は、これ以上の変換は実施されず、ＴＲＵＥをｆｉｔｓ＿ｐａｇｅ（）に戻す。
【０１４３】
適合化プロセスが完了後、即ち、図６の適合化アルゴリズムが終了後は、特定のクライアント能力プロフィールに関して異なったウェブコンテンツバージョンが生成されていることになる。しかしながら、複数のクライアント能力プロフィールが存在するため、各クライアント能力プロフィールに関する適合化されたウェブコンテンツバージョンを生成するためにこれらのアルゴリズムを繰り返し実行しなければならない。その後は（即ち、全バージョンを生成後は）、適合化モジュールは、生成されたバージョンに関するプロフィールＩＤをクライアント能力プロフィールに基づいて生成し、これらの適合化されたバージョン及びＩＤをコンテンツキャッシュに保存する。これらのプロフィールＩＤと物理的な適合されたコンテンツの論理的関係は、データベース構造相互参照リンクの形をしている。これで、これらの適合されたコンテンツバージョンは、検索可能な状態であってエンドユーザーの要求に応じて引き渡すことが可能な状態になっている。
【０１４４】
本発明の実施形態に準拠したシステムは、上述されている動作モードにおいて、ユーザーが要求する前に原ウェブコンテンツの多数の適合化バージョン（即ち、既知の及び指定された特性を有する特定の所定の表示装置に関する各々のバージョン）を生成するように動作する。
【０１４５】
しかしながら、上述されているように、該システムは、ウェブサーバーとして動作することもできる。次にこの動作モードについて説明する。
【０１４６】
システムがウェブサーバーとして動作していてインターネットに接続されていると想定すると、該サーバーは、ウェブコンテンツに関するｈｔｔｐ要求をエンドユーザーデバイス１から受け取る。このｈｔｔｐ要求は、最初にクライアント能力発見モジュール１２に引き渡され、クライアント能力発見モジュール１２は、エンドユーザーデバイス１の一組の表示特性（例えば、画面のサイズ、色の深さ、ブラウザーの種類、ネットワーク接続、等）を決定するように動作する。
【０１４７】
クライアント能力発見モジュール１２は、Ｍ３Ｉによって提言されている基準等の既存の基準に基づいてデバイス能力を検出する（前述されておりさらに本出願明細書において参照することによって本出願明細書に組み入れられているCurrent Technologies for Device Independent, Mark H Butler, HP Labs Technical Report HPL-2001-83 4 April 2001）（デバイスに依存しないための現在の技術、マークＨバトラー、HP研究所技術報告書ＨＰＬ−２００１−８３ ２００１年４月４日）を参照すること。該報告書の該当する内容は、本発明を完全に理解する上で必要である。現時点においては、ほとんどのインターネットブラウザーの場合は、ウェブサーバーに送られる最初の要求の中にエンドユーザー情報（ブラウザーの種類とバージョン、ＩＰアドレス、画面解像度、等）が含まれている。エンドユーザーのデバイスは、エンドユーザーがウェブサーバーを通じてＵＲＬを入力した時点でサーバーとの通信を始める。クライアント能力発見モジュール１２は、エンドユーザーデバイス情報を入手するために、エンドユーザーから送られたクライアント能力情報を単純なＪａｖａｓｃｒｉｐｔ（登録商標）によって検索し、Ｊａｖａサーブレットプログラムを通じて該情報をサーバーに渡す。「クライアントプロフィール」と呼ばれるＪａｖａ（登録商標）Ｓｅｒｖｌｅｔを通じてエンドユーザーデバイス情報を入手してサーバーに引き渡すＪａｖａｓｃｒｉｐｔ（登録商標）のサンプルを以下に示した。
【表３】
【０１４８】
クライアント能力発見モジュール１２は、エンドユーザーデバイス１のクライアント特性の組を決定後、決定した特性の組を決定モジュール１４に引き渡し、決定モジュール１４は、エンドユーザーデバイス特性を、プロフィールサーバー２６内に保存されているクライアント能力プロフィールの組と比較するように動作する。決定モジュール１４がエンドユーザーデバイス特性の組をクライアント能力プロフィールのうちの１つとマッチさせることができた場合は、決定モジュール１４は、エンドユーザーデバイス特性にマッチしたクライアント能力プロフィールのプロフィールＩＤをインデックスとして使用して、適合化されたコンテンツの異なったバージョンを保存するコンテンツキャッシュ１０にアクセスする。次に、該プロフィールＩＤにインデキシングされたウェブコンテンツの適合化バージョンが、コンテンツキャッシュ１０から検索され、ネットワークを通じてエンドユーザーデバイス１に提供される。以上のように、この動作モードにおいては、該システムは、ウェブコンテンツの適合化バージョンのうちでエンドユーザーデバイスに送るべき予め生成された適合化バージョンを決定するために、エンドユーザーデバイス表示特性を一組の予め定義されたデバイス特性とマッチングさせることができる。
【０１４９】
上述されているように、該システムは、さらなる動作モードも提供し、該動作モードでは、前述されている動作モードによって提供された動作を結合させる。ここでは、エンドユーザーデバイス１がウェブコンテンツ要求を行うと、前述されているようにクライアント能力発見モジュール１２が動作して該デバイスの表示特性を決定し、決定された表示特性が決定モジュール１４に渡される。決定モジュール１４は、エンドユーザーデバイス１の能力を、プロフィールサーバー２６に保存されているクライアント能力とマッチさせることを試み、マッチさせることができた場合は、ウェブコンテンツの該当する適合化バージョンがコンテンツキャッシュ１０から検索され、ネットワークを通じてエンドユーザーデバイス１に渡される。マッチさせることができない場合は、決定モジュール１４は、クライアント能力発見モジュール１２によって決定された特性に関連するエンドユーザーデバイス１の詳細を適合化モジュール１６に渡すことによって適合化モジュール１６を動作させる。適合化モジュール１６は、プロフィールサーバー２６に保存されてエンドユーザーデバイス１の能力に対応する新しいクライアント能力プロフィールを生成し、更に、エンドユーザーデバイス１専用に適合化された新たな適合化ウェブコンテンツバージョンを生成するためにウェブコンテンツの適合化バージョンを予め生成時には、前述されている方法とまったく同じ方法で動作を開始させる。即ち、適合化モジュール１６は、コンテンツ解析モジュール２０を動作させ、コンテンツ解析モジュール２０は、ウェブコンテンツを解析し、適合化モジュールがエンドユーザーデバイス１専用の新たな適合化されたウェブコンテンツバージョンを生成するために適合化アルゴリズムを実行することを可能にする。次に、適合化されたウェブコンテンツは、決定モジュールに戻され、決定モジュールは、ネットワークを通じて該適合化ウェブコンテンツをエンドユーザーデバイス１に送る。更に、新たな適合化ウェブコンテンツは、エンドユーザーデバイス１と類似のエンドユーザーデバイスが将来要求した場合に使用できるようにするためにコンテンツキャッシュ１０にも保存される。従って、このさらなる動作モードにおいては、適合化されたウェブコンテンツの新たなバージョンを、ユーザーの要求に応じて動的に生成することができ、更に、ユーザーによる将来の要求に対応するために保存される。
【０１５０】
該システムは、上述されている動作モードに加えて、カスタム化モジュール２４も提供する。このカスタム化モジュールは、単に、コンテンツキャッシュに保存されたウェブコンテンツの様々な適合化バージョンに対して改良を加えるためにウエブ著者が必要に応じてブラウズすることを可能にするフロントエンドであるにすぎない。この機能に鑑みて、カスタム化モジュール２４に関するこれ以上の説明は行わない。
【０１５１】
結論としては、該システムは、異なったウェブコンテンツバージョンをユーザーの要求に先んじて生成することができるため、ユーザーが要求時には、エンドユーザーデバイスの表示特性を予め生成されたバージョンとマッチングさせ、それによって、計算をほとんどまったく集中させずに敏速に応答を生成することができる。更に加えて、必要な場合は、ウェブコンテンツを要求している特定のエンドユーザーデバイスとマッチさせるために適合化ウェブコンテンツの新たなバージョンを動的に生成することもでき、更に、類似のエンドユーザーデバイスからの将来の要求に対応する際に使用するために保存される。
【０１５２】
本出願明細書において特に図５及び６の適合化プロセスを参照しつつ説明されている特定の実施形態における手順は、解析されたウェブコンテンツ（ＸＭＬツリー）全体を移動する反復プロセスと、コンテンツ分割と、コンテンツを必要に応じて変換して表示装置に適合するように縮小すること、が含まれていたことが理解される。しかしながら、代替実施形態も構想されており、該代替実施形態においては、最初にコンテンツ全体を可能な限りの最小サイズに縮小し、その後にコンテンツを分割し、次に該コンテンツのサイズを再度拡大させて表示サイズにする変換を行うように手順が修正される。該コンテンツを再度拡大した時点で、該コンテンツを複数のページ間でより適切に配分するために再分割することが必要になる場合がある。従って、この手順は、繰り返し分割すること及び変換することも含むことになるが、コンテンツのサイズが表示装置において表示するのに適しているかどうかを決定するステップは、受け入れられないほど大きな面積の空白スペースを表示装置において表示するかどうかを計算することを含むことができる。
【０１５３】
グルーピング／クラスタリングパターンアルゴリズムは、ウェブページ部分のオブジェクトをクラスタに分類し、これらのクラスタ間の関係を決定する。この分類及び関係は、より小さい画面を有するデバイスにおけるいくつかのより小さいコンテンツページ上にどのようにしてウェブページコンテンツを表示するかに対して影響を与える。より小さいコンテンツページの組のうちのどのページにどのクラスタを入れるべきかを決定する１つの方法は、グルーピング／クラスタリングパターンアルゴリズムを使用し、更に、以下の予め決められたパラメータ値に依存する。
【０１５４】
選択すべきクラスタ内において計算された最大許容画素数（合計）
１つの分割されたページに関する許容空白スペース（実験的に決定できる）
分割ページの許容される縦の長さ（実験的に決定できる）
分割ページの許容される横の長さ（実験的に決定できる）
第１の予め決められたサイズの表示面積を有するデバイス上において表示するように配備されたウェブページのコンテンツを、１つ以上のその他のデバイス（各々が異なった表示面積を有することができるデバイス）において表示するために複数のコンテンツページに分割する循環（繰り返し又は反復）手法を採用することによって、各デバイスにおいてコンテンツを提示するために用いられるフォーマットが相対的に一貫している。従って、原ウェブページから派生したコンテンツを含むページを示すすべてのディスプレイは、１つの一貫したフォーマットを共有することができるはずである。
【０１５５】
文脈上別の解釈が明確に要求されない限り、本出願明細書における説明全体を通じて、「具備する」、「具備している」、等の表現は、排他的または余すところなくという意味ではなく包含するという意味である、即ち、「含んでいるが、これらの項目に限定するものではない」という意味であると解釈すること。
【０１５６】
本出願明細書の要約の本文を説明の一部として以下に再掲した。
【０１５７】
ウェブページコンテンツを適合させる装置及び方法について説明されている。ウェブページコンテンツをより小型の所定の表示装置において表示するために適合させることは、該コンテンツを幾つかのより小さいページにわたって分割することをしばしば要求する。該装置及び方法は、プロセスを最適化するためにコンテンツ分割プロセスと変換（例えば、フォントサイズ、画像、等の縮小）を実施することを統合する手順に関連する。該手順は、ウェブページコンテンツ全体にわたって体系的に実施され、該コンテンツを反復的により小さい部分に分割することと、これらのより小さいページ上において見ることができる空白スペース量を最小にするために様々な変換を同時に実施すること、とを繰り返す。更に、好ましい実施形態は、オブジェクトに関して既に実施されている変換を追跡し、更に、これらの変換をのちにその他の類似のオブジェクトに関しても実施することによって一貫性を確保する。
【図面の簡単な説明】
【０１５８】
【図１】本発明の実施形態の構成要素と、これらの構成要素間における信号の流れと、を示したシステムブロック図である。
【図２】動作中の本発明の実施形態の構成要素間における情報の流れ方をより詳細に示したプロセス流れ図である。
【図３】本発明の実施形態においてウェブコンテンツ内の表示オブジェクトの特性を検出するアルゴリズムに関する流れ図である。
【図４】本発明の実施形態においてウェブコンテンツ内の表示オブジェクトの機能を検出する決定ツリーである。
【図５Ａ】本発明の実施形態におけるコンテンツ変換実施方法を示した流れ図（その１）である。
【図５Ｂ】本発明の実施形態におけるコンテンツ変換実施方法を示した流れ図（その２）である。
【図５Ｃ】本発明の実施形態におけるコンテンツ変換実施方法を示した流れ図（その３）である。
【図６】本発明の実施形態におけるコンテンツ分割プロセスの実施方法を示した流れ図である。
【特許請求の範囲】
【請求項１】
ウェブページコンテンツを所定の表示装置において表示するために適合させる装置であって、前記コンテンツを前記表示装置において表示するために複数のより小さいウェブページに分割する適合化手段を具備し、前記適合化手段は、
（ｉ）前記コンテンツを複数のコンテンツ部分に分割し、前記コンテンツ部分のうちの少なくとも１つに関してステップ（ｉ）乃至（ｖｉ）を反復的に繰り返し、
（ｉｉ）前記コンテンツを解析して前記コンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定し、
（ｉｉｉ）前記コンテンツのサイズが前記表示装置において表示するのに適していない場合は、前記コンテンツ部分に関して少なくとも１つのコンテンツ変換を実施し、
（ｉｖ）前記変換されたコンテンツを解析して、前記変換されたコンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定し、
（ｖ）前記変換されたコンテンツ部分のサイズが前記表示装置において表示するのに適していない場合は、前記コンテンツ部分を複数のさらなるコンテンツ部分に分割する、ように構成されている装置。
【請求項２】
前記サイズが適しているかどうかを決定する解析ステップ（ｉｉ）及び（ｉｖ）は、前記コンテンツが前記表示装置において表示する上で十分に小さいかどうかを決定することを具備する、請求項１に記載の装置。
【請求項３】
前記適合化手段は、前記変換されたコンテンツ部分が前記表示装置において表示する上で十分に小さいとステップ（ｉｖ）が決定した場合には、前記変換されたコンテンツ部分をさらなるコンテンツ部分と結合させて１つの結合されたコンテンツ部分を形成するように構成されている請求項１又は請求項２に記載の装置。
【請求項４】
前記適合化手段は、前記コンテンツを解析して前記結合されたコンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定し、前記結合されたコンテンツ部分のサイズが前記表示装置において表示する上で大きすぎる場合は、少なくとも１つのコンテンツ変換を前記結合されたコンテンツ部分に関して実施するように構成されている、請求項３に記載の装置。
【請求項５】
請求項３に従属し、前記適合化手段は、コンテンツ部分に関する保存領域を具備し、２つのコンテンツ部分を結合させる前記ステップは、前記保存領域から前記さらなるコンテンツ部分を選択することを具備し、
前記適合化手段は、前記コンテンツを解析することによって、前記変換された結合コンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定し、前記変換された結合コンテンツ部分のサイズが前記表示装置にとって大きすぎる場合は、前記さらなるコンテンツ部分を前記保存領域内に戻すために前記結合されたコンテンツ部分を細分するようにさらに構成されている、請求項４に記載の装置。
【請求項６】
前記適合化手段は、前記変換された結合コンテンツ部分のサイズが前記表示装置において表示する上で十分に小さい場合には、前記コンテンツ部分を第２のコンテンツ部分と結合させるようにさらに構成されている、請求項５に記載の装置。
【請求項７】
前記ウェブページコンテンツをより小さいウェブページに分割するための適切な場所を表すためにラベルが貼付された複数のノードを具備する階層ツリーフォーマットに前記ウェブページコンテンツを変換するように構成されている解析手段をさらに具備する、上記のいずれかの請求項に記載の装置。
【請求項８】
前記適合化手段は、コンテンツ部分に関する保存領域をさらに具備し、コンテンツを分割してさらに小さいコンテンツ部分を形成する前記ステップは、複数のコンテンツ部分を前記保存領域内に加えることを具備する、上記のいずれかの請求項に記載の装置。
【請求項９】
前記適合化手段は、コンテンツに関して実施済みの変換記録を、前記変換が実施されているコンテンツの型の表示とともに保存するための変換保存領域を具備する、上記のいずれかの請求項に記載の装置。
【請求項１０】
請求項３に従属し、請求項３において定義されている前記コンテンツ部分を結合させる前記ステップは、前記変換記録において示されているコンテンツと同じ型のコンテンツに関して一貫した変換を実施するために、前記変換記録に従ってコンテンツ変換を前記さらなるコンテンツ部分に関して実施することをさらに具備する、請求項９に記載の装置。
【請求項１１】
ウェブページコンテンツを所定の表示装置において表示するために適合させる方法であって、
（ｉ）前記コンテンツを複数のコンテンツ部分に分割し、前記コンテンツ部分の少なくとも１つに関してステップ（ｉｉ）乃至（ｖ）を反復的に繰り返すステップと、
（ｉｉ）前記コンテンツを解析し、前記コンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定するステップと、
（ｉｉｉ）前記コンテンツ部分のサイズが前記表示装置において表示するのに適していない場合は、少なくとも１つのコンテンツ変換を前記コンテンツ部分に関して実施するステップと、
（ｉｖ）前記変換されたコンテンツを解析し、前記変換されたコンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定するステップと、
（ｖ）前記変換されたコンテンツ部分のサイズが前記表示装置において表示するのに適していない場合は、前記コンテンツ部分を複数のさらなるコンテンツ部分に分割するステップと、を実行することによって前記コンテンツを前記表示装置において表示するためにより小さいウェブページに分割することを具備する、方法。
【請求項１２】
前記サイズが適しているかどうかを決定する解析ステップ（ｉｉ）及び（ｉｖ）は、前記コンテンツが前記表示装置において表示する上で十分に小さいかどうかを決定することを具備する、請求項１１に記載の方法。
【請求項１３】
前記変換されたコンテンツ部分が前記表示装置において表示する上で十分に小さいことをステップ（ｉｖ）が決定した場合は、前記変換されたコンテンツ部分をさらなるコンテンツ部分と結合して１つの結合されたコンテンツ部分を形成するステップをさらに具備する、請求項１１又は請求項１２に記載の方法。
【請求項１４】
前記コンテンツを解析し、前記結合されたコンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定するステップと、前記結合されたコンテンツ部分のサイズが前記表示装置にとって大きすぎる場合は、少なくとも１つのコンテンツ変換を前記結合されたコンテンツ部分に関して実施するステップと、をさらに具備する、請求項１３に記載の方法。
【請求項１５】
請求項１３に従属し、２つのコンテンツ部分を結合させる前記ステップは、前記さらなるコンテンツ部分を保存領域から選択することを具備し、前記コンテンツを解析することによって前記変換された結合コンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定するステップと、前記変換された結合コンテンツ部分が前記表示装置にとって大きすぎる場合は、前記結合されたコンテンツ部分を細分して前記さらなるコンテンツ部分を前記保存領域内に戻すステップと、をさらに具備する、請求項１４に記載の方法。
【請求項１６】
前記変換された結合コンテンツ部分のサイズが前記表示装置において表示する上で十分に小さい場合は、前記コンテンツ部分を第２のコンテンツ部分と結合させるステップをさらに具備する、請求項１５に記載の方法。
【請求項１７】
前記ウェブページコンテンツをより小さいウェブページに分割するための適切な場所を表すためにラベルが貼付された複数のノードを具備する階層ツリーフォーマットに前記ウェブページコンテンツを変換するステップをさらに具備する、請求項１１乃至請求項１６のうちのいずれかの請求項に記載の方法。
【請求項１８】
コンテンツを分割してより小さいコンテンツ部分を形成する前記ステップは、複数のコンテンツ部分を保存領域内に加えることを具備する、請求項１１乃至請求項１７のうちのいずれかの請求項に記載の方法。
【請求項１９】
コンテンツに関して実施済みの変換記録を、前記変換が実施されているコンテンツの型の表示とともに維持することをさらに具備する、請求項１１乃至請求項１８のうちのいずれかの請求項に記載の方法。
【請求項２０】
請求項１３に従属し、請求項３において定義されているコンテンツ部分を結合させるステップは、前記変換記録内において示されているコンテンツと同じ型のコンテンツに関して一貫した変換が実施されるようにするために、前記変換記録に従ったコンテンツ変換を前記さらなるコンテンツ部分に関して実施することをさらに具備する、請求項１９に記載の方法。
【請求項２１】
装備されたディスプレイがウェブページの元来の意図された表示サイズよりも小さいためウェブページコンテンツを前記ディスプレイ上の複数のページにわたって分割する必要がある表示装置において表示するために前記ウェブページコンテンツを適合させる装置であって、
前記コンテンツをより小さい部分に繰り返し分割しその一方でこれらのより小さいページ上において見ることができる空白スペース量を最小にするために様々な変換を同時に実施することによって、前記コンテンツを分割するプロセスと変換を実施することを統合するように構成されている手段を具備する、装置。
【請求項２２】
各々のより小さい部分に関して実施されている変換を追跡するように構成された手段をさらに具備し、ウェブページコンテンツのすべての類似部分に関して同じ変換を実施することによって一貫性を確保するように構成されている手段をさらに具備する、請求項２１に記載の装置。
【請求項２３】
装備されたディスプレイがウェブページの元来の意図された表示サイズよりも小さいためウェブページコンテンツを前記ディスプレイ上の複数のページにわたって分割する必要がある表示装置において表示するために前記ウェブページコンテンツを適合させる方法であって、
前記ウェブページのコンテンツを第１の予め決められたサイズを有する複数のより小さい部分に反復的に分割するステップと、
前記複数のより小さい部分に関して変換を実施するステップと、を具備し、
前記コンテンツを分割する前記ステップは、前記コンテンツを反復的により小さい部分に分割し、その一方でこれらのより小さいページ上において見ることができる空白スペース量を最小にするために様々な変換を同時に実施することによって、前記変換実施ステップと統合される方法。
【請求項２４】
各部分に関して実施された各変換を追跡するステップと、
各部分に関して実施されたすべての変換に関する情報を保存するステップと、
前記ウェブページコンテンツのあらゆる類似部分に関して同じ変換を実施するステップと、をさらに具備する請求項２３に記載の方法。
【請求項２５】
コンピュータシステムによって実行時に、請求項１１乃至２０、請求項２３又は請求項２４のうちのいずれかの請求項に記載された方法を該システムに実施させるように構成された１つのコンピュータプログラム又は一組のプログラム。
【請求項２６】
請求項２５に記載された前記コンピュータプログラム又は前記一組のプログラムのうちの少なくとも１つに対応するデータを組み込んだ変調搬送信号。
【請求項２７】
請求項２５に記載された前記コンピュータプログラム又は前記一組のプログラムのうちの少なくとも１つを格納する、コンピュータによって読み取り可能な記憶媒体。
【請求項１】
ウェブページコンテンツを所定の表示装置において表示するために適合させる装置であって、前記コンテンツを前記表示装置において表示するために複数のより小さいウェブページに分割する適合化手段を具備し、前記適合化手段は、
（ｉ）前記コンテンツを複数のコンテンツ部分に分割し、前記コンテンツ部分のうちの少なくとも１つに関してステップ（ｉ）乃至（ｖｉ）を反復的に繰り返し、
（ｉｉ）前記コンテンツを解析して前記コンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定し、
（ｉｉｉ）前記コンテンツのサイズが前記表示装置において表示するのに適していない場合は、前記コンテンツ部分に関して少なくとも１つのコンテンツ変換を実施し、
（ｉｖ）前記変換されたコンテンツを解析して、前記変換されたコンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定し、
（ｖ）前記変換されたコンテンツ部分のサイズが前記表示装置において表示するのに適していない場合は、前記コンテンツ部分を複数のさらなるコンテンツ部分に分割する、ように構成されている装置。
【請求項２】
前記サイズが適しているかどうかを決定する解析ステップ（ｉｉ）及び（ｉｖ）は、前記コンテンツが前記表示装置において表示する上で十分に小さいかどうかを決定することを具備する、請求項１に記載の装置。
【請求項３】
前記適合化手段は、前記変換されたコンテンツ部分が前記表示装置において表示する上で十分に小さいとステップ（ｉｖ）が決定した場合には、前記変換されたコンテンツ部分をさらなるコンテンツ部分と結合させて１つの結合されたコンテンツ部分を形成するように構成されている請求項１又は請求項２に記載の装置。
【請求項４】
前記適合化手段は、前記コンテンツを解析して前記結合されたコンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定し、前記結合されたコンテンツ部分のサイズが前記表示装置において表示する上で大きすぎる場合は、少なくとも１つのコンテンツ変換を前記結合されたコンテンツ部分に関して実施するように構成されている、請求項３に記載の装置。
【請求項５】
請求項３に従属し、前記適合化手段は、コンテンツ部分に関する保存領域を具備し、２つのコンテンツ部分を結合させる前記ステップは、前記保存領域から前記さらなるコンテンツ部分を選択することを具備し、
前記適合化手段は、前記コンテンツを解析することによって、前記変換された結合コンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定し、前記変換された結合コンテンツ部分のサイズが前記表示装置にとって大きすぎる場合は、前記さらなるコンテンツ部分を前記保存領域内に戻すために前記結合されたコンテンツ部分を細分するようにさらに構成されている、請求項４に記載の装置。
【請求項６】
前記適合化手段は、前記変換された結合コンテンツ部分のサイズが前記表示装置において表示する上で十分に小さい場合には、前記コンテンツ部分を第２のコンテンツ部分と結合させるようにさらに構成されている、請求項５に記載の装置。
【請求項７】
前記ウェブページコンテンツをより小さいウェブページに分割するための適切な場所を表すためにラベルが貼付された複数のノードを具備する階層ツリーフォーマットに前記ウェブページコンテンツを変換するように構成されている解析手段をさらに具備する、上記のいずれかの請求項に記載の装置。
【請求項８】
前記適合化手段は、コンテンツ部分に関する保存領域をさらに具備し、コンテンツを分割してさらに小さいコンテンツ部分を形成する前記ステップは、複数のコンテンツ部分を前記保存領域内に加えることを具備する、上記のいずれかの請求項に記載の装置。
【請求項９】
前記適合化手段は、コンテンツに関して実施済みの変換記録を、前記変換が実施されているコンテンツの型の表示とともに保存するための変換保存領域を具備する、上記のいずれかの請求項に記載の装置。
【請求項１０】
請求項３に従属し、請求項３において定義されている前記コンテンツ部分を結合させる前記ステップは、前記変換記録において示されているコンテンツと同じ型のコンテンツに関して一貫した変換を実施するために、前記変換記録に従ってコンテンツ変換を前記さらなるコンテンツ部分に関して実施することをさらに具備する、請求項９に記載の装置。
【請求項１１】
ウェブページコンテンツを所定の表示装置において表示するために適合させる方法であって、
（ｉ）前記コンテンツを複数のコンテンツ部分に分割し、前記コンテンツ部分の少なくとも１つに関してステップ（ｉｉ）乃至（ｖ）を反復的に繰り返すステップと、
（ｉｉ）前記コンテンツを解析し、前記コンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定するステップと、
（ｉｉｉ）前記コンテンツ部分のサイズが前記表示装置において表示するのに適していない場合は、少なくとも１つのコンテンツ変換を前記コンテンツ部分に関して実施するステップと、
（ｉｖ）前記変換されたコンテンツを解析し、前記変換されたコンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定するステップと、
（ｖ）前記変換されたコンテンツ部分のサイズが前記表示装置において表示するのに適していない場合は、前記コンテンツ部分を複数のさらなるコンテンツ部分に分割するステップと、を実行することによって前記コンテンツを前記表示装置において表示するためにより小さいウェブページに分割することを具備する、方法。
【請求項１２】
前記サイズが適しているかどうかを決定する解析ステップ（ｉｉ）及び（ｉｖ）は、前記コンテンツが前記表示装置において表示する上で十分に小さいかどうかを決定することを具備する、請求項１１に記載の方法。
【請求項１３】
前記変換されたコンテンツ部分が前記表示装置において表示する上で十分に小さいことをステップ（ｉｖ）が決定した場合は、前記変換されたコンテンツ部分をさらなるコンテンツ部分と結合して１つの結合されたコンテンツ部分を形成するステップをさらに具備する、請求項１１又は請求項１２に記載の方法。
【請求項１４】
前記コンテンツを解析し、前記結合されたコンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定するステップと、前記結合されたコンテンツ部分のサイズが前記表示装置にとって大きすぎる場合は、少なくとも１つのコンテンツ変換を前記結合されたコンテンツ部分に関して実施するステップと、をさらに具備する、請求項１３に記載の方法。
【請求項１５】
請求項１３に従属し、２つのコンテンツ部分を結合させる前記ステップは、前記さらなるコンテンツ部分を保存領域から選択することを具備し、前記コンテンツを解析することによって前記変換された結合コンテンツ部分のサイズが前記表示装置において表示するのに適しているかどうかを決定するステップと、前記変換された結合コンテンツ部分が前記表示装置にとって大きすぎる場合は、前記結合されたコンテンツ部分を細分して前記さらなるコンテンツ部分を前記保存領域内に戻すステップと、をさらに具備する、請求項１４に記載の方法。
【請求項１６】
前記変換された結合コンテンツ部分のサイズが前記表示装置において表示する上で十分に小さい場合は、前記コンテンツ部分を第２のコンテンツ部分と結合させるステップをさらに具備する、請求項１５に記載の方法。
【請求項１７】
前記ウェブページコンテンツをより小さいウェブページに分割するための適切な場所を表すためにラベルが貼付された複数のノードを具備する階層ツリーフォーマットに前記ウェブページコンテンツを変換するステップをさらに具備する、請求項１１乃至請求項１６のうちのいずれかの請求項に記載の方法。
【請求項１８】
コンテンツを分割してより小さいコンテンツ部分を形成する前記ステップは、複数のコンテンツ部分を保存領域内に加えることを具備する、請求項１１乃至請求項１７のうちのいずれかの請求項に記載の方法。
【請求項１９】
コンテンツに関して実施済みの変換記録を、前記変換が実施されているコンテンツの型の表示とともに維持することをさらに具備する、請求項１１乃至請求項１８のうちのいずれかの請求項に記載の方法。
【請求項２０】
請求項１３に従属し、請求項３において定義されているコンテンツ部分を結合させるステップは、前記変換記録内において示されているコンテンツと同じ型のコンテンツに関して一貫した変換が実施されるようにするために、前記変換記録に従ったコンテンツ変換を前記さらなるコンテンツ部分に関して実施することをさらに具備する、請求項１９に記載の方法。
【請求項２１】
装備されたディスプレイがウェブページの元来の意図された表示サイズよりも小さいためウェブページコンテンツを前記ディスプレイ上の複数のページにわたって分割する必要がある表示装置において表示するために前記ウェブページコンテンツを適合させる装置であって、
前記コンテンツをより小さい部分に繰り返し分割しその一方でこれらのより小さいページ上において見ることができる空白スペース量を最小にするために様々な変換を同時に実施することによって、前記コンテンツを分割するプロセスと変換を実施することを統合するように構成されている手段を具備する、装置。
【請求項２２】
各々のより小さい部分に関して実施されている変換を追跡するように構成された手段をさらに具備し、ウェブページコンテンツのすべての類似部分に関して同じ変換を実施することによって一貫性を確保するように構成されている手段をさらに具備する、請求項２１に記載の装置。
【請求項２３】
装備されたディスプレイがウェブページの元来の意図された表示サイズよりも小さいためウェブページコンテンツを前記ディスプレイ上の複数のページにわたって分割する必要がある表示装置において表示するために前記ウェブページコンテンツを適合させる方法であって、
前記ウェブページのコンテンツを第１の予め決められたサイズを有する複数のより小さい部分に反復的に分割するステップと、
前記複数のより小さい部分に関して変換を実施するステップと、を具備し、
前記コンテンツを分割する前記ステップは、前記コンテンツを反復的により小さい部分に分割し、その一方でこれらのより小さいページ上において見ることができる空白スペース量を最小にするために様々な変換を同時に実施することによって、前記変換実施ステップと統合される方法。
【請求項２４】
各部分に関して実施された各変換を追跡するステップと、
各部分に関して実施されたすべての変換に関する情報を保存するステップと、
前記ウェブページコンテンツのあらゆる類似部分に関して同じ変換を実施するステップと、をさらに具備する請求項２３に記載の方法。
【請求項２５】
コンピュータシステムによって実行時に、請求項１１乃至２０、請求項２３又は請求項２４のうちのいずれかの請求項に記載された方法を該システムに実施させるように構成された１つのコンピュータプログラム又は一組のプログラム。
【請求項２６】
請求項２５に記載された前記コンピュータプログラム又は前記一組のプログラムのうちの少なくとも１つに対応するデータを組み込んだ変調搬送信号。
【請求項２７】
請求項２５に記載された前記コンピュータプログラム又は前記一組のプログラムのうちの少なくとも１つを格納する、コンピュータによって読み取り可能な記憶媒体。
【図１】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図６】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図６】
【公表番号】特表２００７−５０９３８５（Ｐ２００７−５０９３８５Ａ）
【公表日】平成１９年４月１２日（２００７．４．１２）
【国際特許分類】
【出願番号】特願２００６−５３０５６５（Ｐ２００６−５３０５６５）
【出願日】平成１６年９月２９日（２００４．９．２９）
【国際出願番号】ＰＣＴ／ＧＢ２００４／００４１５１
【国際公開番号】ＷＯ２００５／０３３９６９
【国際公開日】平成１７年４月１４日（２００５．４．１４）
【出願人】（３９００２８５８７）ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー (104)
【氏名又は名称原語表記】ＢＲＩＴＩＳＨ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＰＵＢＬＩＣ ＬＩＭＩＴＥＤ ＣＯＭＰＡＮＹ
【Ｆターム（参考）】
【公表日】平成１９年４月１２日（２００７．４．１２）
【国際特許分類】
【出願日】平成１６年９月２９日（２００４．９．２９）
【国際出願番号】ＰＣＴ／ＧＢ２００４／００４１５１
【国際公開番号】ＷＯ２００５／０３３９６９
【国際公開日】平成１７年４月１４日（２００５．４．１４）
【出願人】（３９００２８５８７）ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー (104)
【氏名又は名称原語表記】ＢＲＩＴＩＳＨ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＰＵＢＬＩＣ ＬＩＭＩＴＥＤ ＣＯＭＰＡＮＹ
【Ｆターム（参考）】
[ Back to top ]