JP6116247B2 - 視覚的要素をブロック分割し、識別し、インデクスを付けて、ドキュメントを検索するためのシステムおよび方法 - Google Patents

Description

本開示は、データソースを検索するための方法およびシステムに広く関係するものである。より具体的には、本開示は、検索者の要求にあわせてコンピュータ検索をカスタマイズする方法に関するものである。また、本開示は、当該検索によって発見された情報の本質および範囲を容易に理解できるように、検索結果を表示する方法にも関係する。

〔関連出願の相互参照〕
本出願は、「視覚的要素をブロック分割し、識別し、インデクスを付けて、ドキュメントを検索するためのシステムおよび方法」と題されて２００９年１０月２日に出願された６１／２４７,９７３号の、米国特許仮出願の利益を享受するものであり、その内容は参照によって本明細書に組み込まれる。

〔背景技術〕
このセクションにおける記載は、本願の開示に関係した背景となる情報を開示しているに過ぎず、従来技術を構成しない。

近年の情報化時代においては、ローカルコンピュータにある膨大な量のデータ、およびイントラネットやインターネットとして公知の世界的なコンピュータネットワークに存在するほとんど無限量のデータに、ユーザはアクセスしている。

所望の情報を発見するために、ユーザは、おなじみで、さまざまな形態があり、技術的に公知の検索エンジンを利用することが通常である。プログラムに組み込まれた検索エンジンがあり、プログラムに展開された１つのドキュメントに含まれる情報を発見するために、それらはたいてい利用される。一般的なドキュメント検索エンジンの一例には、マイクロソフト（登録商標）ノートパッドファインド（Notepad Find）や、マイクロソフト（登録商標）アウトルック（登録商標）サーチが含まれる。一方、デスクトップ検索エンジンにより、ユーザはローカルコンピュータにある情報を発見できる。一般的なデスクトップ検索エンジンの一例には、マイクロソフト（登録商標）ウィンドウズ（登録商標）ＸＰ検索や、Ｍａｃ（登録商標）ＯＳファインダーなどが含まれる。ウェブ検索エンジンにより、ユーザはインターネット（またはイントラネット）にある情報を発見できる。一般的なウェブ検索エンジンには、グーグル（登録商標）、Ｂｉｎｇ（登録商標）、およびＹａｈｏｏ（登録商標）が含まれる。ローカルおよびリモートのデータソースの両方を検索するハイブリッドな検索エンジンもある。

所望のトピックに関する情報を探すユーザは、検索エンジンを利用するために、当該トピックに関係したキーワードまたはフレーズで構成される検索クエリを、当該検索エンジンの検索インターフェースに入力することが通常である。当該検索が１つのドキュメントに対して実行される場合、当該検索エンジンは当該ドキュメントにおいてマッチした部分をハイライト表示する。当該検索が複数のドキュメントに対して実行される場合、当該検索エンジンは、検索キーワードを含む関係するドキュメントにリンクが張られた優先順位付きリストとともに、レポートを表示する。それぞれの結果には、テキストの短い要約も含まれる。当該要約は、当該検索クエリに係るキーワードを含むドキュメントに含まれるテキストの一部、または複数の部分である。

既存の検索エンジンは多くの機能を備えているが、依然として不足が生じている。ウェブ検索エンジンによる通常のインターネット検索は、無関係のデータを膨大な量だけ発見する。結果から選別を行ってユーザの要求に関係する比較的少数のウェブページを発見するために、一部ユーザに無視できない時間と労力とを強いている。

検索エンジンが大量に無関係の結果を返す理由は、キーワードによってインデクスを付け、検索をする方法それ自体が適切でないからである。例えば、「インド」について興味を持っているユーザが、「首都／ニューデリー」のように「キー／値」のペアに検索結果を指定し、絞り込むことは、既存の検索エンジンには不可能である。

既存の検索エンジンの他の欠点は、興味を持っているトピックに関連するキーワードを知らないユーザには、それらは役に立たないという点である。例えば、ユーザが「ジュラシック・パーク」に類似した映画を探したい場合、キーワード「ジュラシック・パーク」および「類似」による検索は、当該検索エンジンは「ジュラシック・パーク」に加えて「類似」という単語を含むページを返すため、役に立たない。

既存の検索エンジンのさらに他の欠点は、発見された結果の本質と種類とをユーザが容易に理解できるように、結果を提示することに失敗していることである。

イントラネット、エクストラネット、ローカルエリアネットワーク、個別のコンピュータ、そして１つのドキュメントを検索するシステムにも、たいてい同様の欠点がある。

上記欠点を鑑みれば、興味のあるトピックに関係する有用な情報を、データソースから検索するための効果的な方法が必要である。

当該開示のいくつかの側面について基本的な理解をもたらすために、以下で単純な開示の要約を提示する。当該要約は、当該開示を広範囲に概説するものではない。当該開示に係る特徴を規定しようとしたり、当該開示の範囲を詳細に説明しようとしたりするものでもない。その唯一の目的は、後述するより詳細な説明のための前置きとして、単純化された形態で当該開示に係るいくつかのコンセプトを提示することである。

以下で述べられる開示は、インターネット、エクストラネット、巨大な／小さなネットワーク、個別のコンピュータシステム、および個別のプログラム／ドキュメント／ファイルにある情報を、データソースから検索することに等しく適用可能である。したがって、本稿における開示および以下で与えられる実施の一例は、インターネット検索を用いて説明されるが、これは当該開示の実施および効用の一例であると理解されるものであり、当該実施の範囲に対するいかなる制限を意味するものでもない。反対に、以下の開示は、インターネット、ワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、個別のコンピュータシステム、および個別のプログラム／ドキュメント／ファイルのようなシステムにも好適に適用可能と理解されるべきである。

以下で説明される開示は、ＨＴＴＰ、ＨＴＴＰＳ、ＦＴＰ、Ｆｉｌｅ、ＴＣＰ／ＩＰ、およびＰＯＰ３などの（しかしこれに限定されない）、データを通信するまたは送信することを目的とするいかなるプロトコル、および、開発された技術または将来開発される技術に等しく適用可能である。したがって、本稿における開示および以下で与えられる実施の一例は、ＨＴＴＰおよびＴＣＰ／ＩＰを用いて説明されることがあるが、これは当該開示の実施および効用の一例であると理解されるものである。反対に、以下の開示は、いかなる種類のローカルまたはネットワークプロトコル、およびデータを送信する、および／または、受信することを目的とする技術的に公知の、または将来に開発される技術にも好適に適用可能と理解されるべきである。

以下で説明される開示は、ＨＴＭＬ、ＤＨＴＭＬ、ＸＭＬ、ＳＧＭＬ、ＰＤＦ、Ｅメール、マイクロソフト（登録商標）ワードドキュメント、マイクロソフト（登録商標）パワーポイントドキュメント、ニュースグループの投稿、マルチメディアオブジェクト、グラフィクスインターチェンジフォーマットイメージ、および／または、ショックウェーブフラッシュファイルなどの（しかしこれに限定されない）、テキストおよび付随的なプレゼンテーションセマンティクス（presentation semantics、ルックアンドフィールに関する指令）を含む任意のドキュメントに対するリンクを検索し、その結果を返すことに等しく適用可能である。上記プレゼンテーションセマンティクスは、ＣＳＳのような（しかしこれに限定されない）、技術的に公知の、または将来に開発される言語において、暗黙的に、または明示的に指定されてもよい。明示的に指定されている場合、ドキュメントのプレゼンテーションセマンティクスはデータとともに同じファイルに含まれていてもよいし、外部ファイルにおいて指定されてもよいし、または両者の組み合わせであってもよい。したがって、我々の開示および以下で与えられる実施の一例は、ＨＴＭＬおよびＣＳＳを用いて説明されることがあるが、これは当該開示の実施および効用の一例と理解されるものであり、当該実施の範囲に対するいかなる制限を意味するものでもない。反対に、以下の開示は、いかなるドキュメント、ファイル、または、テキスト、オーディオおよびビデオオブジェクト、イメージ、および他のマルチメディアオブジェクトを、付随的なプレゼンテーションセマンティクスの指令とともに含む、技術的に公知の、または将来に開発されるユニットに組み立てられたファイルの組み合わせにも、好適に適用可能と理解されるべきである。

本開示は、データソースから情報を検索する方法およびシステムに広く関係するものである。より具体的には、視覚に基づいて（vision-based）識別し、抽出し、そしてセグメント、またはパラグラフにマッチしたドキュメントの一部、表、リスト、メニュー、固定幅テキスト、キー／値、グラフ／チャート、質問／回答、タイムライン、および表示インターフェース上でドキュメントを見つめる際に人間が行う方法に類似するインタラクティブ（以下では「視覚的要素」と称する）の種類にインデクスを付ける方法に関係する。

本開示の１つの側面において、人間はモニターや紙などの表示インターフェースに描画されたドキュメントの一部から、視覚的要素の種類（visual element types）のドキュメントに含まれる視覚的要素を識別する、および／または、抽出する。また、本開示の他の側面において、システムはブロックおよびプロファイルを活用して、視覚的要素の種類のドキュメントに含まれる視覚的要素を自動的に識別する、および／または、抽出する。また、本開示のさらに他の側面において、視覚的要素の上記識別および抽出に人間とシステムとの組み合わせが使われてもよい。

ブロックは、ドキュメントのロジカルユニット（logical unit）である。プロファイルは、マッチしたブロックを識別し、それがドキュメントの一部として表示インターフェースに描画されたとき、当該ブロックを視覚的に見ることによって人間が当該ブロックを識別するように、視覚的要素の種類を識別するように設計されたルールの集合である。

本開示のさらなる目的は、発見された視覚的要素にインデクスを付け、ランク付けをすることである。

本開示のさらなる目的は、１つまたは複数の視覚的要素の種類に結果を限定することによって、トピックに関連した情報を検索するインターフェースを、ユーザに提供することである。当該検索インターフェースは、検索クエリとしてフレーズを入力しているユーザに提案を行う。また、当該結果のレポートにおいてさらなる提案を行う。

本開示のさらなる目的は、水平リスト、および／または、垂直リストとして、および／または、格子において、ユーザ検索クエリに対する応答において、優先順位つき検索結果を表示することである。

本開示のさらなる目的は、それぞれの検索結果に対するパラグラフテキストとして概要を表示することである。当該概要は、当該検索クエリのキーワードを含むドキュメントに含まれるテキストの一部、または複数の部分である。本開示の他の側面において、検索結果は、元のドキュメントにおいて発見されたものと同一の視覚的タイプ（visual type）で示される。すなわち、表の視覚的タイプの概要は、元のドキュメントで発見された表である。さらに他の側面において、当該結果の概要は、元のドキュメントにおいて発見されたものと同一の視覚的タイプおよびプレゼンテーションセマンティクスによって示される。

本開示のさらなる目的は、視覚的要素の種類をさらに含む検索クエリを用いてユーザにより検索が実行された場合、結果レポートに広告を表示することである。本開示の他の側面において、マーケティング担当者は、視覚的要素の種類をさらに含む検索クエリによる結果レポートの広告スペースに入札する。本開示のさらに他の側面において、ドキュメントの著者またはドキュメントの所有者は、インデクスを付けられ、検索結果の一部に含まれたドキュメントの視覚的要素に対して料金を支払う。

本開示の一実施の形態に係る検索エンジンシステムの一例を示すブロック図である。 図１に示した検索エンジン計算機器の一例を示すブロック図である。 ドキュメントのソースコンテンツデータの一例を示す図である。 図３に示したソースコンテンツデータのプレゼンテーションセマンティクスの一例を示す図である。 図３に示したソースコンテンツデータのメタデータの一例を示す図である。 ブロックを識別する基準データの一例を示す図である。 ブロックを識別する基準データの一例を示す図である。 図３に示したソースコンテンツデータを表示機器に表示した一例を示す図である。 図２のブロック分割およびインデクス付けロジックによって実現されるブロック境界を示す図８の表示を示す図である。 図２のブロック分割およびインデクス付けロジックによって実現されるブロック境界の一例を示す図である。 図２のブロック分割およびインデクス付けロジックによって実現されるブロック境界の一例を示す図である。 図１１のブロックの結合を示す図である。 各フォントファミリ、フォントサイズ、およびフォントウェイトの組み合わせに対する重要値を示す表の一部である。 図２のブロック分割およびインデクス付けロジックによって実現されるブロック境界の一例を示す図である。 「リスト」の種類の視覚的要素を含むソースコンテンツデータの一例を示す図である。 「固定幅テキスト」の種類の視覚的要素を含むソースコンテンツデータの一例を示す図である。 図１６のソースコンテンツデータに対するプレゼンテーションセマンティクスのデータの一例を示す図である。 「リスト」の種類の視覚的要素を含むソースコンテンツデータの一例を示す図である。 図１８のソースコンテンツデータに対するプレゼンテーションセマンティクスのデータの一例を示す図である。 「リスト」の種類の視覚的要素を含むソースコンテンツデータの一例を示す図である。 「パラグラフ」の種類の視覚的要素を含むソースコンテンツデータの一例を示す図である。 図２１のソースコンテンツデータに対するプレゼンテーションセマンティクスのデータの一例を示す図である。 「表」の種類の視覚的要素を含むソースコンテンツデータの一例を示す図である。 図２３のソースコンテンツデータに対するプレゼンテーションセマンティクスのデータの一例を示す図である。 「表」の種類の視覚的要素を含むソースコンテンツデータの一例を示す図である。 図２５のソースコンテンツデータに対するプレゼンテーションセマンティクスのデータの一例を示す図である。 「キー／値」の種類の視覚的要素を含むソースコンテンツデータの一例を示す図である。 図２７のソースコンテンツデータに対するプレゼンテーションセマンティクスのデータの一例を示す図である。 「質問／答え」の種類の視覚的要素を含むソースコンテンツデータの一例を示す図である。 「メニュー」の種類の視覚的要素を含むソースコンテンツデータの一例を示す図である。 図３０のソースコンテンツデータに対するプレゼンテーションセマンティクスのデータの一例を示す図である。 「固定幅テキスト」の種類の視覚的要素を含むソースコンテンツデータの一例を示す図である。 図３２のソースコンテンツデータに対するプレゼンテーションセマンティクスのデータの一例を示す図である。 「タイムライン」の種類の視覚的要素を含むソースコンテンツデータの一例を示す図である。 「グラフ／チャート」の種類の視覚的要素を含むソースコンテンツデータの一例を示す図である。 「インタラクティブ」の種類の視覚的要素を含むソースコンテンツデータの一例を示す図である。 本開示の一実施の形態に係るソースコンテンツデータの一例を示す図である。 図２に示されるブロック分割およびインデクス付けロジックのアーキテクチャおよび機能性の一例を示すフローチャートである。 図１の検索エンジンシステムによってユーザに提示されるグラフィカルユーザインターフェース（ＧＵＩ）の一例である。 図１の検索エンジンシステムによってユーザに提示されるＧＵＩの他の一例である。 ユーザが図１の検索エンジンシステムに検索クエリを入力するにつれて、キーワード提案を当該ユーザに提示するＧＵＩの一例を示す図である。 「リスト」の種類の視覚的要素に対するユーザ検索の応答として、図１の検索エンジンシステムによってユーザに提示される結果レポートの一例である。 「リスト」の種類の視覚的要素に対するユーザ検索の応答として、図１の検索エンジンシステムによってユーザに提示される結果レポートの他の一例である。 「リスト」および「表」の種類の視覚的要素に対するユーザ検索の応答として、図１の検索エンジンシステムによってユーザに提示される結果レポートの一例である。

本開示は、ドキュメントを検索してインデクスを付けるシステムおよび方法に関するものである。本開示の一実施の形態に係るシステムは、ネットワークにおけるドキュメント（またはウェブページ）の場所を探すクローラ（crawler）を用いる。ドキュメントが発見されると、所定のルールに基づいて、当該システムは発見された各ドキュメントをブロックに分割する。さらに、所定のルールに基づいて、当該システムは各ドキュメントに含まれる視覚的要素（visual elements）を探す。例えば、所定のルールに基づいて、当該システムはドキュメントに含まれる表（tables）、パラグラフ（paragraphs）、タイトル（titles）、リスト（lists）、および固定幅テキスト（fixed width text）を探す。視覚的要素の判定は、当該ドキュメントのソースコンテンツ（source content）、当該ドキュメントのプレゼンテーションセマンティクス（presentation semantics）、および当該ドキュメントに関連するメタデータ（metadata）を解析することによってなされる。上記視覚的要素が発見されると、それらにインデクスが付けられる。これにより、ユーザは視覚的要素を含むドキュメントを検索できる。

図１は、本開示の典型的な一実施の形態に係るウェブ検索エンジン１００を示す。システム１００は、ウェブサーバ１０１、検索エンジンサーバ１０２、およびクライアント１０３を含む。ウェブサーバ１０１、検索エンジンサーバ１０２、およびクライアント１０３は、ネットワーク１０４を介して互いに通信する。

ネットワーク１０４は、技術的に公知の、または将来に開発される任意のタイプのネットワークを含む。すなわち、ネットワーク１０４は、イーサネット（登録商標）、ローカルエリアネットワーク（ＬＡＮ）、またはワイドエリアネットワーク（ＷＡＮ）であってよく、例えばインターネットや複数のネットワークの組み合わせでよい。

典型的な検索エンジンサーバ１０２においては、ウェブドキュメント、一般的にＨＴＭＬウェブページおよびそれらに関連したカスケーディングスタイルシート（ＣＳＳ）のプレゼンテーションファイルをクローラロジック１０５が取得し、それらをドキュメントおよびプレゼンテーションデータ１０８に蓄積する。クローラロジック１０５は、クロールされたドキュメントにおいて、自身が行き当たったドキュメントへのすべてのリンクを追跡するオートメーション化されたブラウザである。各リンクは、ウェブサーバ１０１に提供されるウェブページ１１１を特定する。簡単のために、１つのウェブサーバ１０１によって提供されるウェブページ１１１が１つだけ、図１に示されている。しかし、ウェブサーバ１０１は複数のドキュメントを提供できるし、クローラロジック１０５は、当該ウェブサーバがネットワーク１０４と通信可能に接続されている限り、リンクによって特定され、ウェブサーバによって提供される任意のドキュメントを取得できる。ウェブページ１１１は、ウェブページまたはドキュメントであってもよいことに注意する。

また、クローラロジック１０５は、当該ドキュメントを特定するリンク、当該ドキュメントがクロールされた日時、当該ドキュメントのサイズなど、ドキュメントに関係する追加の情報を、ドキュメントおよびプレゼンテーションデータ１０９に蓄積してもよいことに注意する。

さらに、検索されたドキュメントおよびそれらに付随するプレゼンテーションファイルが、ブロック分割およびインデクス付けロジック１０６に、すでに好適に利用可能である場合、クローラロジック１０５を必要としないことに注意する。

検索エンジンサーバ１０２は、ブロック分割およびインデクス付けロジック１０６をさらに含む。ブロック分割およびインデクス付けロジック１０６は、ドキュメントおよびプレゼンテーションデータ１０８にあるドキュメントを、それらに付随するプレゼンテーションファイルとともに解析する。ブロック分割およびインデクス付けロジック１０６は、各ドキュメントに対して、当該ドキュメントをロジカルユニット（以下「ブロック」と称する）に分割し、プロファイルを活用して各ブロックの一部である視覚的要素を識別する。ブロック分割およびインデクス付けロジック１０６は、インデクスデータ１０９にある識別された視覚的要素のインデクスをさらに生成する。ブロック分割およびインデクス付けロジック１０６について、図３から図３８を参照してさらに説明する。

インデクスが生成されてインデクスデータ１０９に格納されると、クライアント計算機器１０３で動作するクライアントロジック１１２を介して、ユーザ１１３は検索クエリを入力できる。ここで、検索クエリは、ユーザが収集に興味を持っている情報の種類を識別可能な１つまたは複数の視覚的要素の種類とキーワードとで構成される。クライアントロジック１１２によってユーザ１１３に示される、ユーザ検索クエリを受け取る典型的なインターフェースについて、図３９から図４４を参照してさらに説明する。

クライアントロジック１１２は、例えばインターネットブラウザを含む。しかし、本開示の他の実施の形態においては、ユーザ１１３に対するインターフェースであって、検索エンジンロジック１０７と通信する他の種類のクライアントロジック１１２が使われてもよい。クライアントロジック１１２は、ネットワーク１０４を介して、ユーザ検索クエリを検索エンジンサーバ１０２に送信する。上記ユーザ検索クエリを受信すると、ユーザの検索クエリに含まれる視覚的要素の種類によって絞り込まれた当該ユーザ検索クエリとマッチする用語を、それが含むか否かを判定するために、検索エンジンロジック１０７はインデクスデータストア１０９を走査する。含むと判定される場合、検索エンジンロジック１０７は、特定された視覚的要素の種類に含まれる全てまたは一部のキーワードを含むすべてのドキュメントの優先順位つきリストを編集し、当該リストをクライアントロジック１０６に返す。クライアントロジック１０６は、当該結果をユーザ１１３に向けてウィンドウに表示する。

他の実施の形態において、検索エンジンロジック１０７は、上記ユーザ検索クエリを受信すると、当該ユーザ検索クエリに含まれる視覚的要素の種類によって検索結果を絞り込むことに代えて、ユーザ検索クエリにおいて特定されたように、当該視覚的要素の種類に発見されたキーワードを含むドキュメントに、より大きな関連性または高いランクを割り当ててもよい。したがって、２つのウェブサイト（またはドキュメント）がユーザ検索クエリに含まれるキーワードとマッチする単語を含み、当該ユーザ検索クエリにおいて特定される種類の視覚的要素に含まれるキーワードを当該ウェブページの１つが含む場合、他のすべては等しく、ユーザによって特定される種類の当該視覚的要素に当該キーワードを含むウェブページは、検索結果において高いランク付けがなされ、当該検索クエリに対する応答としてユーザに送信される。したがって、検索結果は、与えられたウェブページがキーワードにマッチする単語を含むか否か、そしてそれはどの程度あるかに基づくだけでなく、マッチした単語が使われた文脈にも基づく（例えば、マッチした単語が特定された種類の視覚的要素において使われているか否か）。

他の実施の形態において、検索エンジンロジック１０７は、上記ユーザ検索クエリの応答となる検索結果とともに、広告データ１１０からの広告を含んでもよい。

図２は、本開示の一実施の形態に係る検索エンジンサーバ１０２の一例を示す。検索エンジンサーバ１０２は適当な計算環境の一例に過ぎず、本開示の実施または機能性の範囲を限定しようとするものではない。

検索エンジンサーバ１０２は、バス２０６、演算ユニット２０１、メモリ２０２、ネットワーク機器２０３、入力機器２０４、および出力機器２０５を含む。バス２０６は、
計算機器２００の各コンポーネント間で通信を可能にするパスを含んでよい。

メモリ２０２には、クローラロジック１０５、ブロック分割およびインデクス付けロジック１０６、検索エンジンロジック１０７、ドキュメントおよびプレゼンテーションデータ１０８、インデクスデータ１０９、および広告データ１１０が格納されている。これらのコンポーネントは、ソフトウェア、ハードウェア、ファームウェア、または、ハードウェア、ソフトウェア、またはファームウェアの組み合わせによって実装される。一実施の形態において、クローラロジック１０５、ブロック分割およびインデクス付けロジック１０６、検索エンジンロジック１０７、ドキュメントおよびプレゼンテーションデータ１０８、インデクスデータ１０９、および広告データ１１０は、メモリ２０２に格納されたソフトウェアとして示される。

メモリ２０２は、技術的に公知の、または将来に開発される、揮発性および不揮発性のメモリを含む、いかなる種類の、電気的にデータを保持するコンピュータメモリ、および／または、論理回路であってよい。ここで、メモリ２０２は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、フラッシュメモリ、ハードディスク、フロッピー（登録商標）ディスク、または磁気テープおよび光ディスクなどの任意の磁気記録機器（magnetic computer storage device）を含む。

演算ユニット２０１は、メモリ２０２に格納されたタスクや命令を解釈し、または実行する演算ハードウェアを含む。演算ユニット２０１は、マイクロプロセッサ、デジタルプロセッサ、または命令を駆動、および／または、実行するために設計されたその他の回路であってよいことに注意する。

ネットワーク機器２０３は、技術的に公知の、または将来に開発される、ネットワーク１０４（図１）を介して通信する任意のネットワーク機器（例えばモデム）であってよい。ここで、検索エンジンサーバ１０２（図１）は、ネットワーク機器２０３を介してネットワーク１０４（図１）上で、ウェブサーバ１０１（図１）およびクライアント計算機器１０３（図１）と通信する。

入力機器２０４は、技術的に公知の、または将来に開発される、ユーザ１１４（図１）からデータを受信する任意の入力機器である。例えば、入力機器２０４は、キーボード、マウス、タッチスクリーン、シリアルポート、スキャナ、カメラ、またはマイクロフォンであってよい。

出力機器２０５は、技術的に公知の、または将来に開発される、ユーザ１１４（図１）にデータを表示する任意の出力機器であってよい。例えば、出力機器２０５は、液晶ディスプレイ（ＬＣＤ）、またはその他の種類のビデオディスプレイ装置、スピーカ、またはプリンタであってよい。

本開示は、検索エンジンサーバ１０２（図１）のタスクまたは命令が通信可能にネットワークに接続された複数の計算機器によって実現されるような、分散型の計算環境で実現されてもよいことに注意する。

また、検索エンジンサーバ１０２の各コンポーネントは、ソフトウェア、ハードウェア、ファームウェア、または、これらの任意の組み合わせによって実装されることに注意する。検索エンジンサーバ１０２の一例においては、図１に示されるように、すべてのコンポーネントはソフトウェアによって実装され、メモリ２０２に格納される。

図３から図１４は、ブロック分割およびインデクス付けロジック１０６によってドキュメントがブロックに分割されることを示す。ブロック分割およびインデクス付けロジック１０６は、当該ドキュメントに含まれる視覚的要素を発見するシステムの機能をさらに高める。

前述したように、ブロックはドキュメントのロジカルユニットである。ブロックについて考える１つの方法は、以下のとおりである。すなわち、文字が単語を作り、単語がセンテンスを作り、センテンスがブロックを作り、ブロックがより大きなブロックを作り、ドキュメントそれ自体が最も大きいブロックである。ドキュメントの種類によって、改行、マークアップ、プレゼンテーションセマンティクス、および／または、対応付けられたデータは、ブロックを識別する上で役に立つ。

前述したように、ブロックが内側にブロックを含むように、ブロックはネスト（入れ子）されてよい。ブロックを内包するブロックを親ブロック（parent blocks）と称し、内側のブロックを子ブロック（child blocks）と称する。親ブロックは、子ブロック全体を常に含む。ネストにより、ブロックは複数の親ブロックを有することがあることに注意する。子ブロックをもたないブロックは特別な種類のブロックであり、ブロックアイテム（block items）と称される。ドキュメント全体は、ロジカルユニットでありブロックでもあるため、ルートブロック（root block）と称される。ルートブロックを除くすべてのブロックは、親ブロックをもつ。

ブロックのネストの経過を追うために、各ブロックにはレベルが割り当てられる。同一の数の親ブロックをもつ２つのブロックは同一のレベルとなり、異なる数の親ブロックを持つ２つのブロックは異なるレベルとなるように、ブロックレベルが割り当てられる。本開示の一実施の形態において、ブロックのレベルはその親ブロックの数と等しい。ルートブロックのレベルはゼロである。

クローラロジック１０５（図１）が、ドキュメントおよびプレゼンテーションデータ１０８（図１）に、ドキュメントに関係する任意のプレゼンテーションファイルとともに、当該ドキュメントをダウンロードすると、ブロック分割およびインデクス付けロジック１０６（図１）は、そのプレゼンテーションセマンティクスとともに、当該ドキュメントのソースコンテンツを解析し、初期メタデータを生成する。メタデータは、ここでその語が使われるとおり、収集され、導出され、または計算された、当該ドキュメントに関連する任意の情報を含むように、広く解釈されるものである。ここで、メタデータは、マークアップ、マークアップアトリビュート（markup attributes）、暗黙的および明示的なプレゼンテーションセマンティクス、当該ドキュメントが表示装置に表示される場合のテキストの位置データ、コメント、テキストがブロックまたはブロックアイテムの場合の当該テキストそれ自体に関する追加的に計算された値、平均フォントサイズなど、および以前に識別された／計算されたメタデータから追加的に計算された値を含む。上記メタデータは一例であって、他の実施の形態においては他の種類のメタデータが使われてもよい。

初期メタデータは、ブロック分割およびインデクス付けロジック１０６（図１）の実行を通して、より多くのメタデータによって増やされてよいことに注意する。また、ドキュメントの異なるセグメントは、異なるメタデータを有してよいことに注意する。さらに、生成されたメタデータの量および種類は、１つのドキュメントの種類から他のドキュメントのタイプに変化してもよいことに注意する。

図３は、クローラロジック１０５（図１）によってダウンロードされ、ドキュメントおよびプレゼンテーションデータ１０８（図１）に格納されたＨＴＭＬドキュメント３００の一例の一部のソースコンテンツ３０１を示す。ソースコンテンツ３０１は、＜ＤＩＶ＞要素３０２と＜ＤＩＶ＞要素３０３とを含む。２つの空＜ＢＲ＞要素および３０５は、＜ＤＩＶ＞要素３０３の中にネストされている。ソースコンテンツ３０１は、マークアップコンテンツおよびテキストコンテンツから成ることに注意する。

図４は、ＨＴＭＬドキュメント３００（図３）のために、クローラロジック１０５（図１）によってダウンロードされ、ドキュメントおよびプレゼンテーションデータ１０８（図１）に格納された、典型的なプレゼンテーションセマンティクス４００のプレゼンテーションセマンティクスの部分４０１を示す。プレゼンテーションセマンティクス４０１は、ソースコンテンツ３０１（図３）に関係する。

図５は、＜ＤＩＶ＞要素３０３（図３）に対して、ブロック分割およびインデクス付けロジック１０６（図１）によって生成されたメタデータ５００の一部を示す。メタデータ５００は、複数のメタデータ属性（metadata properties）５０１−５１２を含む。各メタデータ属性は、キー／値のペアから成る。メタデータ属性５０１および５０２は、＜ＤＩＶ＞要素３０３（図３）のマークアップから導出される。メタデータ属性５０３は、明示的なプレゼンテーションセマンティクス４０１（図４）から導出される。メタデータ属性５０４、５０５、および５０６は、ドキュメント３００（図３）の暗示的なプレゼンテーションセマンティクスから導出される。メタデータ属性５０７から５１０は、ドキュメント３００（図３）の表示から推測される。メタデータ属性５０７および５０８は、ユーザに見えるように、＜ＤＩＶ＞要素３０３（図３）の中にあるテキストコンテンツが始まる、表示インターフェースにおける開始位置を特定する。メタデータ属性５０９および５１０は、＜ＤＩＶ＞要素３０３（図３）の中にあるテキストコンテンツのユーザに見えるように、表示インターフェースにおける幅および高さをそれぞれ特定する。メタデータを計算するためのドキュメントの表示は、仮想表示インターフェースにおけるメモリ２０２（図２）で行われてもよい。

メタデータ属性５１１および５１２は、ブロック分割およびインデクス付けロジック１０６（図１）による計算から導出され、図６から図１２を参照して説明されるブロック識別処理の後、＜ＤＩＶ＞要素３０３に対する既存のメタデータに拡張される。上記＜ＤＩＶ＞要素３０３（図３）は、上記ブロック識別処理の間に、ブロック分割およびインデクス付けロジック１０６（図１）によって、ブロックとして識別されると仮定する。この情報は、メタデータ属性５１１に保存される。また、計算されたブロックのレベルは、メタデータ属性５１２に保存される。

ドキュメントのソースコンテンツおよびプレゼンテーションセマンティクスからメタデータを初期計算した後、ブロック分割およびインデクス付けロジック１０６（図１）によって実行される次のステップは、ブロックの識別である。当該ドキュメントのセグメントがブロックか否かを決定するために、ブロック分割およびインデクス付けロジック１０６（図１）は、少なくとも１つのブロック識別基準（block identifying criterion）の集合に対して、当該ドキュメントのセグメントがすべての基準に合致しているか否かを確認する。当該基準集合に含まれる各基準は、真か偽かを評価するメタデータ属性のルールである。ブロック識別基準の集合は、ブロックセグメントだけが当該基準集合におけるすべての基準を真と評価するように設計されている。

ブロック識別基準の集合に含まれる基準を作り出す１つの方法は、ドキュメントを視覚的に見て当該ドキュメントにあるブロックを識別し、当該ドキュメントのコンテンツのメタデータを生成し、ブロックとして視覚的に識別されたセグメントを特徴付けるそれら特定のメタデータ属性を識別および正規化することである。

ブロック識別基準の集合が複数存在する場合があり、ドキュメントのセグメントが少なくとも１つのブロック識別基準の集合を満たす場合、当該ドキュメントのセグメントはブロックであることに注意する。

図６は、ブロック識別基準の集合６００の一例を示す。基準集合６００は、唯一の基準６０１を含む。メタデータ属性のキーを伴うセグメントは「display」であり、対応するメタデータ属性の値は、基準６０１が真であることを評価する「block」である。＜ＤＩＶ＞要素３０３（図３）は、基準６０１、すなわち基準集合６００を満足するメタデータ属性５０５（図５）を含むことに注意する。＜ＤＩＶ＞要素３０３（図３）は、少なくとも１つの基準集合を満足するため、ブロックである。

図７は、ブロック識別基準の集合７００の他の一例を示す。基準集合７００は、２つの基準７０１と７０２とを含む。基準７０１は、キー「start-tag」と対応するメタデータ属性の値「br.」とを有するメタデータ属性があることを要求する。基準７０２は、キーdisplayと対応するメタデータ値がないようなメタデータ属性がないことを要求する。＜ＢＲ＞要素３０４（図３）および３０５（図３）のメタデータは、上記基準集合７００の両基準を満たす。したがって、空＜ＢＲ／＞要素もブロックである。

図８は、ソースコンテンツ３０１によって識別され、表示インターフェースにおいてユーザが見るような、ドキュメント３００（図３）の一部８０１の図である。ソースコンテンツ３０１（図３）はマークアップコンテンツおよびテキストコンテンツから成るが、当該ドキュメントが表示インターフェースに表示された場合、ユーザは上記テキストコンテンツのみを見る。

図９は、ソースコンテンツ３０１（図３）によって特定されるドキュメント３００（図３）の一部に含まれるすべてのブロックを示す図である。ブロック識別基準の集合をとおして、ブロック分割およびインデクス付けロジック１０６（図１）によって識別されるブロック９０１から９０６を明示するため、実線のボックスが図９において使われている。ブロックアイテム９０２はブロック９０１の子ブロックであることに注意する。さらに、ブロック９０４はブロック９０３の直系の子ブロックであるのに対して、ブロック９０５はブロック９０３の子ブロックであるが、ブロック９０３の直系の子ブロックではないことに注意する。

本開示の一実施の形態において、ドキュメントにあるすべてのテキストセグメントは、ブロックアイテムに属する。それが同一のブロックアイテムである必要は必ずしもない。また、１つ以上のブロックアイテムに属するテキストセグメントはない。ブロックアイテム９０２の中のテキストは、１つの部分および唯一のブロックアイテム９０２であるようなこれらの条件を満たす。しかし、ブロックの一部であるが、いかなるブロックアイテムの一部でもないテキストセグメント９０７から９１１の島が存在することに注意する。これらのテキストセグメントの島は、ブロック分割およびインデクス付けロジック１０６（図１）によってブロックアイテムとして明示される。テキストセグメント９０７は、ブロック９０３である親ブロックをもつブロックアイテムとして明示される。同様に、残りのテキストセグメント９０８から９１１は、ブロックアイテムとして明示される。ブロックアイテムもブロックであることに注意する。

他の実施の形態において、ブロックアイテムとして明示されるテキストセグメントが少しあるか、まったくないことがあることに注意する。

ここで、ブロック分割およびインデクス付けロジック１０６（図１）は、ドキュメント全体をブロックにセグメント化し、識別されたブロックのリストが用意される。次に、ブロック分割およびインデクス付けロジック１０６（図１）は、当該ブロックリストに含まれるブロックに対して、一連の処理を実行する。

ブロック分割およびインデクス付けロジック１０６（図１）によって実行される第１のブロック処理は、上記ブロックリストからすべての空ブロックを識別し、削除することである。この目的を達成するために、ブロック分割およびインデクス付けロジック１０６（図１）は、上記ブロックリストにあるすべての識別されたブロックに対し、ブロックのレベルの降順に繰り返し、各ブロックに対して当該ブロックが空であることを確認する。当該ブロックが空と判定される場合、当該ブロックは上記ブロックリストから削除される。当該ブロックに関連するものが表示インターフェースに表示されない、または描画されない場合、そのブロックは空とみなされる。空のブロックは、空ブロック識別基準の集合によって識別される。空ブロックとして識別されるために、少なくとも１つの空ブロック識別基準の集合に含まれるすべての基準を、ブロックは満たす必要がある。表示が無しに等しく、視認性が非表示に等しく、表示エリアが０に等しく、オーバーフローが非表示に等しく、またはブロックの中に視認可能なテキストや境界線がないようなメタデータ属性は、空ボックスと識別する助けになり、空ブロック識別基準の集合における基準の候補である。

空ブロックを識別する方法は、ドキュメントを処理し、結果と表示されたドキュメントを視覚的に見ることとを比較することによって達成される。ブロックがスクリーンに表示されず、空ブロックとして当該ブロックにフラグを立てることにプログラムが失敗した場合、ブロック分割およびインデクス付けロジック１０６（図１）に包含される必要のある空ブロックを識別する一般化されたメタデータ属性の組み合わせが存在する。一方、ブロック分割およびインデクス付けロジック１０６（図１）が空ブロックとしてブロックにフラグを立て、当該ドキュメントが表示インターフェースに表示された場合に当該ブロックのいくつかの部分が見えたとき、空ブロックを識別する目的で使わない、または使うべきではない場合、空としてブロックにフラグを立てる一般化したメタデータ属性の集合が存在する。

前述したように、ブロック分割およびインデクス付けロジックは、ソースコンテンツ３０１（図３）にあるブロック９０１から９１１（図９）を識別する。図８におけるソースコンテンツ３０１（図３）の表示から推測されるように、ブロック９０５および９０６の一部は表示インターフェースに表示されず、ブロック９０５および９０６は空ブロックである。両ブロックは可視テキストおよび可視境界線をもたないため、ブロック分割およびインデクス付けロジック１０６（図１）は、ブロック９０５および９０６を空ブロックとして識別し、上記ブロックリストからこれらを削除する。ブロック９０５および９０６を削除することにより、ブロック９０４は、５つの子ブロックアイテムの代わりに、３つの子ブロックアイテム９０８、９０９、および９１０をもつことになることに注意する。

ブロック分割およびインデクス付けロジック１０６（図１）によって実行される次の処理は、ブロックアイテムが重複しているか否かを確認することである。それは各ブロックアイテムによって占められる四角の領域として、位置メタデータから既知である。２つまたはそれ以上のブロックアイテムが互いに重複している場合、すべての重複ブロックアイテムは、上記ブロックリストから削除されてよい。

他の実施の形態において、他のブロックによって重複されているブロックのみが、上記ブロックリストから削除されてよい。さらに他の実施の形態において、他の非透過のブロックによって重複されているブロックのみが、上記ブロックリストから削除されてよい。

ブロック分割およびインデクス付けロジック１０６（図１）によって実行される次のブロック処理は、中間のブロックを識別し、上記ブロックリストから削除することである。直系に１つだけ子ブロックを含む場合、当該ブロックは中間ブロックとみなされる。

図１０は、ユーザが見るようなドキュメントの一部（正確な縮尺ではない）を示す図であり、ブロック分割およびインデクス付けロジック１０６（図１）によって識別されるブロックを明示するために、当該図ではボックスを重ね合わせている。セグメントは４つのブロック１００１から１００４を含む。ブロック１００１のレベルは２であり、ブロック１００２のレベルは３であり、ブロック１００３および１００４のレベルは４であるとする。ブロック分割およびインデクス付けロジック１０６（図１）は、ブロック１００１が直系の子ブロック１００２を１つだけ含むと計算する。したがって、ブロック１００１は中間ブロックであるため、上記ブロックリストから削除される。中間ブロック１００１の子ブロック１００２、１００３、および１００４は、ブロック１００１の子ブロックとなり、直系の親ブロック（図示せず）。また、中間ブロック１００１にあるすべてのブロックのレベルは再計算され、ブロック１００２のレベルが２となり、ブロック１００３および１００４のレベルが３となる。

表の行のブロック、ヘッダーブロック、フッターブロック、およびキャプションブロックのようなその他のブロックは、中間ブロックとみなされてもよい。

ブロック分割およびインデクス付けロジック１０６（図１）によって実行される次の処理は、条件を満たしたブロックを結合し、より大きなブロックにすることである。ユーザが見て単一のロジカルユニットを認識した場合、表示されたドキュメントのセグメントを見ると、ブロック分割およびインデクス付けロジック１０６（図１）は同一のドキュメントのセグメントの１つ以上のブロックを識別するが、２つまたはそれ以上の識別されたブロックは、結合して単一のブロックにする候補となる。

図１１は、表示されたドキュメントの一部（正確な縮尺ではない）であり、ブロック分割およびインデクス付けロジック１０６（図１）は、図１１において重ね合わされたボックスによって表される３つのブロック１１０１、１１０２、および１１０３を識別するとさらに仮定する。ブロック分割およびインデクス付けロジック１０６（図１）は３つのブロックを識別するが、ドキュメントを見ているユーザは１つのロジカルユニットを識別するだけである。ブロック１１０２は日付から始まり、タイムラインの視覚的要素の一部であり、ブロック１１０３は日付から始まっていないため、これらのブロックは結合される。ブロック１１０２および１１０３が単一のブロック１２０１（図１２）に結合されると、ブロック１１０１は中間ブロックとしての条件を満たすため、削除される。これにより、親ブロックとブロック１２０１（図１２）のレベルとが再計算される。図１２は、識別されたブロックを示すために重ね合わされたボックスとともに、条件を満たしたブロックが結合された後の、図１１のドキュメントの同じ部分を示す。結合の結果、３つのブロック１１０１、１１０２、および１１０３が削除され、１つのブロック１２０１が上記ブロックリストに追加される。

結合する条件を満たしたブロックを決定するためには、メタデータに加えて、ブロックデータの解析、隣接するブロックデータの解析が必要になる。

ブロック分割およびインデクス付けロジック１０６（図１）によって実行される次の処理は、上記ブロックリストに含まれる各ブロックアイテムに対して、フォントのメタデータ属性のブロックアイテムフォントファミリ（block-item-font-family）、ブロックアイテムフォントサイズ（block-item-font-size）、およびブロックアイテムフォントウェイト（block-item-font-weight）を計算することである。ブロックアイテムの異なるテキストセグメントが、異なるフォント文字（フォントファミリ、フォントサイズ、およびフォントウェイト）を含む場合、ブロックアイテムにおけるすべてのテキストの代表のフォント文字を計算することは有用である。ブロックアイテムに含まれるすべてのテキストに対して、ブロックアイテムフォントファミリは、代表のフォントファミリであり、ブロックアイテムフォントサイズは、代表のフォントサイズであり、ブロックアイテムフォントウェイトは、代表のフォントウェイトである。

ブロックアイテムの代表フォントのメタデータ属性を計算するために、３つ組の集合が用意され、１つは単語のフォントファミリのメタデータ属性値、フォントサイズのメタデータ属性値、およびフォントウェイトのメタデータ属性値を含むブロックアイテムのテキストに含まれるそれぞれの可視単語である。最も頻繁（統計値のモード）に生じる３つ組のフォントファミリ、フォントサイズ、およびフォントウェイトは、それぞれブロックアイテムフォントファミリ、ブロックアイテムフォントサイズ、およびブロックアイテムフォントウェイトのメタデータ属性値である。ブロックアイテムに含まれる異なる３つ組の総数は有用であり、当該ブロックアイテムの他のメタデータ属性のブロックアイテムバリアンス（block-item-variance）に格納されてよい。

わずか数語しか含まないテキストを含むブロックアイテムに対しては、最頻の三つ組みを使う代わりに、最も大きいフォントサイズ、最も大きいフォントウェイト、または最も大きい重要値（importance value）をもつ三つ組が、フォントのメタデータ属性の計算に使われてよい。三つ組の重要値は、図１３を参照して説明される。また、他の実施の形態において、非表示の単語だけでなく、下付き単語、特定のフォントファミリ（例えばWebdings）に属する単語は、ブロックアイテムのフォントのメタデータ属性の計算において考慮されなくともよい。さらに他の実施の形態においては、ブロックのフォントのメタデータ属性の計算において、三つ組は単語の代わりに文字に対して用意される、または統計値のモードの代わりに統計値の平均が使われる。

図１３に示すように、ブロック分割およびインデクス付けロジック１０６（図１）は、追加のメタデータ属性のブロックアイテムインポータンス（block-item-importance）をさらに計算してよく、これはブロックアイテムにのみ適用可能である。ブロックアイテムのブロックアイテムインポータンスは、ドキュメントの残りの部分に関して、当該ブロックアイテムの重要度とみなされる。ブロックアイテムのブロックアイテムインポータンスのメタデータ属性は、ブロックのブロックアイテムフォントファミリ、ブロックアイテムフォントサイズ、およびブロックアイテムフォントウェイトの機能である。一般に、ブロックアイテムフォントサイズ、またはブロックアイテムフォントウェイトが大きいほど、他のすべてが等しければ、ブロックアイテムインポータンスも大きい。

本開示の一実施の形態において、ブロック分割およびインデクス付けロジック１０６（図１）は、各フォントファミリ、フォントサイズ、およびフォントウェイトの３つ組の組み合わせに対して、重要値をあらかじめ決めたルックアップテーブルが利用可能である。図１３は、ルックアップテーブル１３００の一部を示す。３つ組１３０１は「Ａｒｉａｌ」のフォントファミリ、「８」のフォントサイズ、および「７００」のフォントウェイトを含み、その重要値１３０２は１.１である。したがって、ブロックアイテムフォントファミリの値が「Ａｒｉａｌ」、ブロックアイテムフォントサイズの値が「８」、ブロックアイテムフォントウェイトの値が「７００」であるようなブロックアイテムに対して、ブロックアイテムインポータンスは１.１である。

他の実施の形態において、上記ルックアップテーブルにおける重要値は、ブロックアイテムインポータンスに対する範囲値となる１つの数ではなく、下限値と上限値をもつ範囲であってよい。

他の実施の形態において、ブロック分割およびインデクス付けロジック１０６は、ブロックを複数のブロックにさらに分割する、あるいはブロックをさらに結合してより大きなブロックにするといった追加のブロック処理を実行してもよいことに注意する。ブロック分割およびインデクス付けロジック１０６（図１）によるドキュメントのブロック分割と、表示されたドキュメントを見て、ユーザ自らが行うドキュメントのロジカルユニット分割とが同じ結果とならない場合、上記処理が必要となる。ブロックアイテムインポータンスの値が低い一連のブロックが、ブロックアイテムインポータンスの値が高い複数のブロックに続くようなパターンに、直系の子ブロックが続いた場合、ブロックを複数のブロックに分割する具体例が必要となることがある。

すべてのブロック処理が完了すると、ブロック分割およびインデクス付けロジック１０６（図１）によって実行される次の処理は、ブロックアイテムではない上記ブロックリストに含まれる各ブロックのタイトルブロックアイテムの識別である。ブロックのタイトルブロックアイテムは、たいてい当該ブロックの上部に配置されており、高いフォントサイズまたは高いフォントウェイト、あるいは当該ブロックの子ブロックの残りの部分とは異なるフォントファミリか、またはセンタリング、または背景色が使われている。

本開示の一実施の形態において、ブロックの直系の子ブロックアイテムが直系の親ブロックのタイトルブロックとして明示されるために、当該直系の子ブロックは、親ブロックの最初の３つのブロックの中に配置される、および／または、センタリングされている、および／または、直系のブロックの残りの部分とは異なる前景色または背景色が使われている、および／または、より大きなブロックアイテムフォントサイズおよび／または他のすべての子ブロックアイテム（直系のブロックである必要は必ずしもない）より大きなブロックアイテムフォントウェイトおよび／またはブロックアイテムフォントサイズおよび／またはブロックアイテムインポータンスを有する必要がある。

他の一実施の形態は、ブロックのタイトルブロックアイテムの識別において、他のメタデータ条件を用いることに注意する。また、ドキュメントを視覚的に見るユーザとブロック分割およびインデクス付けロジック１０６（図１）とは、ブロックの同じタイトルブロックアイテムを識別しなければならないことに注意する。ブロック分割およびインデクス付けロジック１０６（図１）がブロックの誤ったタイトルブロックを識別した場合、またはブロックの正しいタイトルブロックの識別に失敗した場合、タイトルブロックアイテムの識別における上記メタデータ条件は、改訂されなければならない。

図１４は、ユーザが見るようなドキュメントの一部（正確な縮尺ではない）を示す図であり、ブロック分割およびインデクス付けロジック１０６（図１）によって識別されるブロックを明示するために、当該図ではボックスを重ね合わせている。ブロックアイテムフォントサイズおよびブロックアイテムインポータンスのメタデータ属性値は、ブロック１４０１に含まれるすべての子ブロックアイテムに対してすでに計算されているとする。また、ブロックアイテム１４０２は、ブロックアイテムフォントサイズおよびブロックアイテムインポータンスのメタデータ属性値が、ブロック１４０１のすべての子ブロックアイテムの中で最も大きいとする。さらに、ブロックアイテム１４０２はブロック１４０１の最初の３つのブロックの中に配置されている。したがって、ブロックアイテム１４０２は、ブロック１４０１のタイトルブロックである。同様に、ブロックアイテム１４０４は、ブロック１４０３のすべての子ブロックアイテムの中で、ブロックアイテムフォントサイズおよびブロックアイテムインポータンス値が最も大きく、ブロック１４０３のすべての子ブロックの中で最初に配置されている。したがって、ブロックアイテム１４０４はブロック１４０３のタイトルブロックである。タイトルブロックとして要求される条件を満足するブロック１４０６の直系の子ブロックアイテムは存在しない。したがって、ブロック１４０６にはタイトルブロックがない。

ブロック１４０６はリスト視覚的要素と識別されるとする。このことをここでさらに説明する。そして、ブロック１４０５はリスト視覚的要素のタイトルとして識別されると仮定する。当該視覚的要素がブロック１４０３の一部であり、ブロックアイテム１４０４がそのタイトルブロックであるため、ブロックアイテム１４０４も当該リスト視覚的要素のタイトルとみなされる。さらに、ブロック１４０３はブロック１４０１の一部であり、ブロック１４０２はそのタイトルブロックであるため、ブロック１４０２もリスト視覚的要素のタイトルとみなされる。本開示の一実施の形態において、視覚的要素は唯一のタイトルをもつ。タイトル１４０５は視覚的要素の３つの識別されたタイトルに最も近いため、リスト視覚的要素のタイトルとみなされる。他の実施の形態において、視覚的要素は複数のタイトルをもってよく、３つの識別されたタイトルのすべては、視覚的要素のタイトルとみなされる。

タイトルブロックが識別されると、ブロック分割およびインデクス付けロジック１０６（図１）によって実行される次のステップは、視覚的要素の識別およびインデクス付けである。視覚的要素には２つの種類がある。すなわち、インライン視覚的要素およびブロック視覚的要素である。インライン視覚的要素は、ブロックアイテムの一部におよぶ。一方、ブロック視覚的要素は１つまたは複数のブロックにおよぶ。典型的には、インライン視覚的要素は、ブロックアイテムのセンテンスで発見される。

異なる視覚的要素の決定および配置を、図１５から図３７をさらに参照して説明する。
特に、ドキュメントをブロックに区分けすることは、ドキュメントの視覚的要素を配置する処理においてさらなる助けとなる。ブロック分割およびインデクス付けロジック１０６（図１）によって識別されたブロックを示すために、図１５から図３７においては、長方形の点線で描かれたボックスがソースコンテンツに重ね合わされている。図１５から図３７をさらに参照して後述するように、ブロック分割およびインデクス付けロジック１０６（図１）は、ブロック視覚的要素のプロファイルとインライン視覚的要素とのデータおよびメタデータのルールにより、ソースコンテンツに含まれる視覚的要素を識別してインデクスを付ける。

インライン視覚的要素を識別するために、ブロック分割およびインデクス付けロジック１０６（図１）は上記ブロックリストに含まれるすべてのブロックアイテムに対して繰り返す。各ブロックアイテムに対して、ブロック分割およびインデクス付けロジック１０６は、センテンスを識別し、データおよびメタデータのルールにより各センテンスの中から視覚的要素を発見する。ブロック分割およびインデクス付けロジック１０６（図１）は、インデクスデータ１０９（図１）における視覚的要素タイトル（visual element title）および視覚的要素の特徴（visual element characteristics）とともに、発見されたそれぞれの視覚的要素に対してさらにインデクスを生成する。

データおよびメタデータのルールの集合は、視覚的要素を識別するだけでなく、当該視覚的要素の種類、当該視覚的要素のタイトル、および他の視覚的要素の特別な特徴も識別することに注意する。また、グループを識別するいくつかのインライン視覚的要素があり、センテンスまたはセンテンスの一部が少なくとも上記集合の１つである場合、当該センテンスまたはセンテンスの一部は、インライン視覚的要素であることにも注意する。

図１５に関して、表示インターフェースにドキュメントのソースコンテンツ１５０１が表示されているのを見たユーザは、ブロック１５０２の第２のセンテンスにおいて、リスト視覚的要素を識別する。一般化されたデータおよびメタデータのルールの集合は、人間のユーザのように、リスト視覚的要素としてブロック１５０２における第２のセンテンス（「ａｒｅ」を含み、その後に「：」が続き、「，」によって区切られた一連の単語が続き、単語「ａｎｄ」と、さらに「，」によって区切られていない単語の集合が続くようなセンテンスを含む）を識別する。フレーズ「ａｒｅ：」の前のセンテンスの一部は、視覚的要素のタイトルとして識別される。さらに、フレーズ「ａｒｅ：」に続く「，」または「ａｎｄ」で区切られたそれぞれの単語は、リストアイテムとして識別される。人間のユーザは、タイトルおよびリストアイテムとして、センテンスの同じ部分を識別することに注意する。

前述した一般化されたデータおよびメタデータのルールは、すべてのインラインリスト視覚的要素（inline list visual elements）を識別しなくともよいことに注意する。ドキュメントを見る人間のユーザは、インラインリスト視覚的要素を識別し、前述したデータおよびメタデータのルールの集合が当該インラインリスト視覚的要素を識別しない場合、異なるフォーマットのインライン視覚的要素を識別するために、データおよびメタデータのルールの新しい集合が、ブロック分割およびインデクス付けロジック１０６（図１）に必要とされる。したがって、それぞれのインライン視覚的要素の種類に対して、データおよびメタデータのルールの集合がいくつか存在してよく、センテンスまたはセンテンスの一部は、当該集合が識別するために定義された視覚的要素の種類として識別される集合を少なくとも１つ満足しなければならない。

図１６は、ソースコンテンツ１６０１を示し、図１７は、ソースコンテンツ１６０１に適用可能なプレゼンテーションセマンティクスを示す。ソースコンテンツ１６０１において識別されるインライン視覚的要素は、固定幅のテキスト視覚的要素である。「text-decoration」という１つの語は、固定幅のテキストを示す「courier」の前に現れている。したがって、上記１つの語は視覚的要素を構成する。表示されたときセグメント１６０１を見るユーザも、１つの語「text-decoration」を固定幅のテキストと識別することに注意する。

ドキュメントに含まれるブロック視覚的要素を識別するために、ブロック分割およびインデクス付けロジック１０６（図１）は、上記ブロックリストにおいて最高のレベルをもつブロック（ブロックアイテムではない）から始め、その子ブロックのすべてをもつブロック全体がプロファイル（すなわち、視覚的要素を判定するルールの集合）にマッチするか否かを判定する。ブロック全体がプロファイルにマッチする場合、タイトルおよび視覚的要素の特徴とともに、ブロック全体を含む結果の視覚的要素は、インデクスを付けられ、インデクスデータ１０９（図９）に格納される。そして、当該ブロックは、上記ブロックリストから削除される。ブロック全体がプロファイルにマッチしない場合でも、子ブロックの部分集合がプロファイルにマッチしさえすれば、タイトルと視覚的要素の特徴とともに子ブロックの部分集合を構成する視覚的要素は、インデクスを付けられ、インデクスデータ１０９（図９）に格納される。そして、マッチした子ブロックの部分集合は、上記ブロックリストから削除される。子ブロックの部分集合がプロファイルにマッチしない場合ですら、子ブロックとともにブロック全体が消され、上記ブロックリストから削除される。ブロックを消した結果、ブロックリストに含まれるブロックのすべてが再度チェックされる。任意のブロックが任意のブロック処理に対して適格である場合、当該ブロック処理が実行される。このことはここでさらに説明され、例えば、空のブロックを削除する、中間ブロックを除く、ブロック結合、またはブロック分割を含む。最高のレベルをもつ新しいブロック（ブロックアイテムではない）は、上記ブロックリストから選択され、プロファイルにマッチするブロックがなくなるまで処理は繰り返される。

プロファイルは、特定の種類のブロック視覚的要素を識別し、ルールの集合を構成する。プロファイルに含まれる各ルールは、２つの部分から成る。最初の部分は、１つまたは複数のブロックを識別する。２つ目の部分は当該識別されたブロックの１つまたは複数のデータ、および／または、メタデータ属性を評価する。例えば、プロファイルのルールは、メタデータ属性のテーブルカラムインデクス（table-column-index）値が１となるすべての子ブロックにおいて、同一のテキストコンテンツをもたねばならず、境界線のメタデータ属性値が０であってはならないとするものであってよい。１つまたは複数のブロックが少なくとも１つのプロファイルのすべてのルールを満足する場合、ブロックの集合は、当該プロファイルが識別するように設計された視覚的要素の種類として識別されてよい。

プロファイルは、他の視覚的要素の特徴とともに、当該視覚的要素のタイトルを識別してよい。当該プロファイルによってタイトルが識別されない場合、視覚的要素が識別された親ブロックの１つは、当該視覚的要素のタイトルとみなされてよい。

図１８および図１９によれば、ドキュメントのソースコンテンツ１８００が表示されたとき（図示せず）、人間のユーザによって識別される視覚的要素は、リスト視覚的要素である。リスト視覚的要素を決定するためのプロファイルは、表の最初の列ブロックアイテムがすべて同じ非アルファベット、３文字以下の長さの非数の文字であるような２つの列をもつ表を構成するブロックを探す。ブロック１８０２およびその子ブロックアイテム１８０３から１８０８は、そうしたプロファイルの条件を満たすため、ブロック１８０２全体はリスト視覚的要素である。リスト視覚的要素に先行するブロックアイテム１８０１は、「list of」のフレーズからなるため、ブロック分割およびインデクス付けロジック１０６は、当該先行するブロックアイテムを識別されたリスト視覚的要素のタイトルとして識別する。

ブロック分割およびインデクス付けロジック１０６（図１）は、メタデータを準備する間、ブロック１８０２全体に広がる＜ＴＡＢＬＥ＞要素のテーブルメタデータ属性を計算することに注意する。これらテーブルメタデータ属性は、３の値をもつ「table-rows」属性と、２の値をもつ「table-column」属性とを含む。また、ブロックアイテム１８０３から１８０８に広がる＜ＴＤ＞要素のそれぞれに対して、ブロック分割およびインデクス付けロジック１０６は、テーブルセルメタデータ属性を計算する。ブロック１８０５全体に広がる＜ＴＤ＞属性に対して、「table-cell-row-index」メタデータ属性は、２の値をもつ行インデクスを識別する。また「table-cell-column-index」メタデータ属性は、１の値をもつ列インデクスを識別する。リストとしてブロック１８０２を識別するプロファイルは、これらの表および表のセルメタデータ属性を利用してよい。

プロファイルは、リスト視覚的要素の特徴をさらに識別する。「table-cell-column-index」の値が２に等しいブロックアイテム１８０４、１８０６、および１８０８は、リストアイテムとして識別される。プロファイルは、ブロックアイテム１８０３のテキストから推測されるスターマークをもつリストをさらに識別する。

プレゼンテーションセマンティクス１９００は、リスト視覚的要素として識別された視覚的要素をさらに確実にする境界線なしに描画される＜ＴＡＢＬＥ＞要素を含むブロック１８０２を識別する。

図２０によれば、ドキュメントのソースコンテンツ２０００が描画されたとき、人間によって識別される視覚的要素も、リスト視覚的要素である。リスト視覚的要素を決定するプロファイルは、順番のないリスト（unordered list）と、子ブロックのテキストコンテンツの中に組み込まれた文字「−」または「：」のない少なくとも２つの子ブロックアイテムとからなるブロックを探す。そのようなプロファイルは、ブロック２００２をリスト視覚的要素として識別する。また、ブロック２００２に先行するブロックアイテム２００１は、ブロックアイテム２００３−２００６のブロックアイテムインポータンスのメタデータ属性値よりも高いブロックアイテムインポータンスのメタデータ属性値をもち、複数の単語を含むただ１つのセンテンスから構成される。したがって、ブロックアイテム２００１はリスト視覚的要素のタイトルとして識別される。

ブロック分割およびインデクス付けロジック１０６（図１）は、メタデータを準備する間、ブロック２００２全体に広がる＜ＵＬ＞要素のテーブルメタデータ属性を計算することに注意する。リストメタデータ属性は、＜ＵＬ＞要素の中に４つの＜ＬＩ＞要素をもつことにより、４の値をもつリストアイテム（list-item）メタデータ属性を含む。また、ブロックアイテム２００３から２００６全体に広がる＜ＬＩ＞要素のそれぞれに対して、ブロック分割およびインデクス付けロジック１０６は、リストアイテムメタデータ属性を計算する。ブロック２００５全体に広がる＜ＬＩ＞要素に対して、インデクスを識別するリストアイテムインデクス（list-item-index）メタデータ属性値は３である。ブロック２００２をリストとして識別するプロファイルは、表および表のセルメタデータ属性を利用する。

プロファイルは、リスト視覚的要素の特徴をさらに識別する。ブロックアイテム２００３から２００６のそれぞれは、ブロックアイテムに含まれる＜ＬＩ＞要素のそれぞれにリストアイテムインデクスメタデータ属性があることから、リストアイテムとして識別される。また、ブロック２００２全体に広がる＜ＵＬ＞要素の暗黙的なプレゼンテーションセマンティクスから推測されるメタデータにより、プロファイルは実線の丸印をもつリストと識別する。

前述した２つのプロファイルに関して、ブロックがリスト視覚的要素か否かを決定するプロファイルのルールは、網羅的なものではなく、ブロックがリスト視覚的要素か否かを決定するにあたり、ブロック分割およびインデクス付けロジック１０６（図１）によって、追加のプロファイルのルールが考えられることに注意する。

また、２つのプロファイルがリスト視覚的要素を識別するために提示されるが、描画されたドキュメントを見るユーザが、ドキュメントのセグメントにあるリストを認識し、２つのプロファイルのいずれもが当該セグメントをリスト視覚的要素として認識しない場合、プロファイルを識別するより多くのリスト視覚的要素が必要となることにも注意する。

図２１および図２２によれば、プレゼンテーションセマンティクス２２００にしたがってドキュメントのソースコンテンツ２１００が描画されたとき、人間のユーザによって識別される視覚的要素は、パラグラフ視覚的要素（paragraph visual element）である。パラグラフ視覚的要素を判定するプロファイルは、少なくとも３つのセンテンス、および／または、少なくとも２００の単語を含むブロックを探す。そうしたプロファイルは、ブロック２１０１をパラグラフ視覚的要素として識別する。プロファイルによって識別されるタイトルがないため、ブロック２１０１の親ブロック（図示せず）の１つまたはすべてのタイトルブロックは、パラグラフ視覚的要素のタイトルとしてみなされる。

パラグラフ視覚的要素を識別するプロファイルは、タイトルだけでなく、サイズ、当該パラグラフ視覚的要素に含まれるセンテンスの数、および他のパラグラフの特徴も識別してよいことに注意する。

ブロックがパラグラフ視覚的要素か否かを決定する前述したプロファイルのルールは、網羅的なものではなく、ブロックがパラグラフ視覚的要素か否かを決定するにあたり、ブロック分割およびインデクス付けロジック１０６（図１）によって、追加のプロファイルのルールが考えられることに注意する。

また、１つのプロファイルがパラグラフ視覚的要素を識別するために提示されるが、描画されたドキュメントを見るユーザが、ドキュメントのセグメントにあるパラグラフを認識し、プロファイが当該セグメントをパラグラフ視覚的要素として認識しない場合、プロファイルを識別するより多くのパラグラフ視覚的要素が必要となることにも注意する。

図２３および図２４によれば、プレゼンテーションセマンティクス２４００にしたがってドキュメントのソースコンテンツ２３００が描画されたとき、人間のユーザによって識別される視覚的要素は、表視覚的要素（table visual element）である。表を識別するプロファイルは、表のブロックの最初の列が同一のテキストとならないような表を構成するブロックを探す。また、表の最初の列ブロックの少なくとも１つが、５文字よりより長いテキストコンテンツをもち、当該表のテキストコンテンツの最初の列ブロックの少なくとも１つが、句読点（punctuation character）で終了しない。そうしたプロファイルルールは、ブロック２３０２を表紙各要素として識別する。また、ブロック２３０２に先行するブロック２３０１は、「following table:」のテキストを含むブロック２３０１の最後のセンテンスを、識別された表視覚的要素のタイトルとする「following table:」というテキストで終了する。ブロックアイテム２３０３および２３０４は、ブロック２３０２の他の子ブロックアイテムよりも高いブロックアイテムインポータンスのメタデータ属性値のメタデータ属性値をもち、当該ブロックは最初の行および当該ブロックのマークアップタグが＜ＴＨ＞であるため、これらのブロックは表ヘッダと識別される。

＜ＴＤ＞要素が各ブロックの全体に広がっているため、プロファイルは、ブロック２３０５から２３１０をテーブルセルとして識別することに注意する。また、当該プロファイルは、表視覚的要素を３行２列と識別してもよい。

図２５および図２６によれば、プレゼンテーションセマンティクス２６００にしたがってドキュメントのソースコンテンツ２５００が描画されたとき、人間のユーザによって識別される視覚的要素は、表視覚的要素である。表を識別するプロファイルは、プレゼンテーションセマンティクスが「display」となるブロックを「table」として探し、プレゼンテーションセマンティクスが「display」となる可視境界および子ブロックを、可視境界および１つ以上の行および１つ以上の列に広がるテーブルセルブロックを有する「table-cell」として探す。そうしたプロファイルは、ブロック２５０２を表視覚的要素として識別する。ブロック２３０１（図２３）と同様に、ブロック２５０１の最後のセンテンスは、識別された表視覚的要素のタイトルとして識別される。ブロック２５０３および２５０４は最初の行の一部であり、ブロック２５０２のすべての他のブロックよりも高いブロックアイテムインポータンスを有するため、当該ブロックはヘッダーブロックとして識別される。明示的なメタデータ属性の表示値テーブルセル（metadata property display value table-cell）をもつため、ブロック２５０５から２５１０はテーブルセルとして識別される。

前述した２つのプロファイルに関して、ブロックが表視覚的要素か否かを決定するプロファイルのルールは、網羅的なものではなく、ブロックが表視覚的要素か否かを決定するにあたり、ブロック分割およびインデクス付けロジック１０６（図１）によって、追加のプロファイルのルールが考えられることに注意する。

また、２つのプロファイルが表視覚的要素を識別するために提示されるが、描画されたドキュメントを見るユーザが、ドキュメントのセグメントにある表を認識し、２つのプロファイルのいずれもが当該セグメントを表視覚的要素として認識しない場合、プロファイルを識別するより多くの表視覚的要素が必要となることにも注意する。

図２７および図２８によれば、プレゼンテーションセマンティクス２８００にしたがってドキュメントのソースコンテンツ２７００が描画されたとき、人間のユーザによって識別される視覚的要素は、キー／値視覚的要素である。キー／値視覚的要素を判定するプロファイルは、最初の行におけるブロックを除き、最初の列ブロックのテキストコンテンツのそれぞれがコロンで終了するような、２つの列をもつ表ブロックを探す。また、最初の行におけるブロックが、２つの列にまたがる。そうしたプロファイルは、ブロック２７０１をキー／値視覚的要素と識別し、最初の行ブロック２７０２を識別されたキー／値視覚的要素のタイトルと識別する。さらに、プロファイルによって、第１の列ブロック２７０３、２７０５、および２７０７はキーとして識別され、第２の列ブロック２７０４、２７０６、および２７０８は当該キーの値として識別される。

前述したプロファイルに関して、ブロックがキー／値視覚的要素か否かを決定するプロファイルのルールは、網羅的なものではなく、ブロックがキー／値視覚的要素か否かを決定するにあたり、ブロック分割およびインデクス付けロジック１０６（図１）によって、追加のプロファイルのルールが考えられることに注意する。

また、１つのプロファイルがキー／値視覚的要素を識別するために提示されるが、描画されたドキュメントを見るユーザが、ドキュメントのセグメントにあるキー／値属性を認識し、プロファイルが当該セグメントをキー／値視覚的要素として認識しない場合、プロファイルを識別するより多くのキー／値視覚的要素が必要となることにも注意する。

図２９によれば、ドキュメントのソースコンテンツ２９００が描画されたとき、人間のユーザによって識別される視覚的要素は、質問／回答視覚的要素（question/answer visual element）である。質問／回答視覚的要素を判定するプロファイルは、文字列「Q:」から始まり、文字列「？」で終了するテキストコンテンツを含み、タグ＜Ｐ＞のブロックが続くブロックを探すように設計されている。そうしたプロファイルは、ブロック２９０１および２９０２を質問／回答視覚的要素として識別する。また、文字列「Q:」から始まり、文字列「？」で終了するテキストコンテンツを含むブロック２９０１は、質問として識別され、ブロック２９０１に続くブロック２９０２は回答として識別される。

前述したプロファイルに関して、ブロックがキー／値視覚的要素か否かを決定するプロファイルのルールは、網羅的なものではなく、ブロックがキー／値視覚的要素か否かを決定するにあたり、ブロック分割およびインデクス付けロジック１０６（図１）によって、追加のプロファイルのルールが考えられることに注意する。

また、１つのプロファイルがキー／値視覚的要素を識別するために提示されるが、描画されたドキュメントを見るユーザが、ドキュメントのセグメントにあるキー／値属性を認識し、プロファイルが当該セグメントをキー／値視覚的要素として認識しない場合、プロファイルを識別するより多くのキー／値視覚的要素が必要となることにも注意する。

図３０および図３１によれば、プレゼンテーションセマンティクス３１００にしたがってドキュメントのソースコンテンツ３０００が描画されたとき、人間のユーザによって識別される視覚的要素は、メニュー視覚的要素（menu visual element）である。メニュー視覚的要素を判定するプロファイルは、インラインに表示された子リストアイテムブロックをもつ順番のないリストブロックとハイパーリンクとを探すように設計されており、さらに当該順番のないリストは当該ドキュメントの上部２０パーセントの領域に配置されている。そうしたプロファイルは、ブロック３００１をメニュー視覚的要素として識別する。リストアイテムブロック要素３００２から３００５のそれぞれは、識別されたメニュー視覚アイテムのメニューアイテムとしてさらに識別される。

前述したプロファイルに関して、ブロックがメニュー視覚的要素か否かを決定するプロファイルのルールは、網羅的なものではなく、ブロックがメニュー視覚的要素か否かを決定するにあたり、ブロック分割およびインデクス付けロジック１０６（図１）によって、追加のプロファイルのルールが考えられることに注意する。

また、１つのプロファイルがメニュー視覚的要素を識別するために提示されるが、描画されたドキュメントを見るユーザが、ドキュメントのセグメントにあるメニューを認識し、プロファイルが当該セグメントをメニュー視覚的要素として認識しない場合、プロファイルを識別するより多くのメニュー視覚的要素が必要となることにも注意する。

図３２および図３３によれば、プレゼンテーションセマンティクス３１００にしたがってドキュメントのソースコンテンツ３０００が描画されたとき、人間のユーザによって識別される視覚的要素は、固定幅テキスト視覚的要素（fixed width text visual element）である。ドキュメントが固定幅テキスト視覚的要素を含むか否かを判定するプロファイルは、最初の行におけるブロックを除いて、ブロックアイテムフォントファミリのメタデータ属性値が一定幅の文字のフォントファミリに等しいような、すべてのブロックをもつテーブルブロックを探す。そうしたプロファイルは、ブロック３２０１を固定幅テキスト視覚的要素として識別する。また、最初の行ブロック３２０２は、ブロックアイテムインポータンス値が最高であり、残りの行とはプレゼンテーションセマンティクスが異なる。したがって、ブロック３２０２は、識別された固定幅テキスト視覚的要素のタイトルとして識別される。

前述したプロファイルに関して、ブロックが固定幅テキスト視覚的要素か否かを決定するプロファイルのルールは、網羅的なものではなく、ブロックが固定幅テキスト視覚的要素か否かを決定するにあたり、ブロック分割およびインデクス付けロジック１０６（図１）によって、追加のプロファイルのルールが考えられることに注意する。

また、１つのプロファイルが固定幅テキスト視覚的要素を識別するために提示されるが、描画されたドキュメントを見るユーザが、ドキュメントのセグメントにある固定幅テキストを認識し、プロファイルが当該セグメントを固定幅テキスト視覚的要素として認識しない場合、プロファイルを識別するより多くの固定幅テキスト視覚的要素が必要となることにも注意する。

図３４によれば、ドキュメントのソースコンテンツ３４００が描画されたとき、人間のユーザによって識別される視覚的要素は、タイムライン視覚的要素（timeline visual element）である。タイムライン視覚的要素を識別するプロファイルは、年から始まり「−」または「：」が続くすべてのブロックをもつ順番のないリストブロックを探す。そうしたプロファイルは、ブロック３４０２をタイムライン視覚的要素として識別する。また、ブロック３４０２のすぐ上に配置されたブロックは、「timeline」という語を含む１つのセンテンスを有する。したがって、ブロック３４０１は、当該タイムライン視覚的要素のタイトルとして識別される。また、順番のないリストアイテム３４０３から３４０７は、タイムラインイベントとして識別される。

前述したプロファイルに関して、ブロックがタイムライン視覚的要素か否かを決定するプロファイルのルールは、網羅的なものではなく、ブロックがタイムライン視覚的要素か否かを決定するにあたり、ブロック分割およびインデクス付けロジック１０６（図１）によって、追加のプロファイルのルールが考えられることに注意する。

また、１つのプロファイルがタイムライン視覚的要素を識別するために提示されるが、描画されたドキュメントを見るユーザが、ドキュメントのセグメントにあるタイムラインを認識し、プロファイルが当該セグメントをタイムライン視覚的要素として認識しない場合、プロファイルを識別するより多くのタイムライン視覚的要素が必要となることにも注意する。

図３５によれば、ドキュメントのソースコンテンツ３５００が描画されたとき、人間のユーザによって識別される視覚的要素は、グラフ／チャート視覚的要素（graph/chart visual element）である。グラフ／チャート視覚的要素を識別するプロファイルは、１つの画像および「chart」という語を含む代替テキストをもつブロックを探し、すぐ上に配置されたブロックは「chart」という語を含む１つのセンテンスをもつ。そうしたプロファイルは、ブロック３５０２をグラフ／チャート視覚的要素として識別する。１つのセンテンスブロック３５０１は、識別されたグラフ／チャート視覚的要素のタイトルとして識別される。

前述したプロファイルに関して、ブロックがグラフ／チャート視覚的要素か否かを決定するプロファイルのルールは、網羅的なものではなく、ブロックがグラフ／チャート視覚的要素か否かを決定するにあたり、ブロック分割およびインデクス付けロジック１０６（図１）によって、追加のプロファイルのルールが考えられることに注意する。

また、１つのプロファイルがグラフ／チャート視覚的要素を識別するために提示されるが、描画されたドキュメントを見るユーザが、ドキュメントのセグメントにあるグラフ／チャートを認識し、プロファイルが当該セグメントをグラフ／チャート視覚的要素として認識しない場合、プロファイルを識別するより多くのグラフ／チャート視覚的要素が必要となることにも注意する。

図３６によれば、ドキュメントのソースコンテンツ３６００が描画されたとき、人間のユーザによって識別される視覚的要素は、インタラクティブ視覚的要素（interactive visual element）である。インタラクティブ視覚的要素を識別するプロファイルは、単一のオブジェクトを含むブロックを探し、すぐ上に配置されたブロックアイテムは「interactive」という語を含む１つのセンテンスをもつ。そうしたプロファイルは、ブロック３６０２をインタラクティブ視覚的要素として識別する。１つのセンテンスブロック３６０１は、識別されたインタラクティブ視覚的要素のタイトルとして識別される。

前述したプロファイルに関して、ブロックがインタラクティブ視覚的要素か否かを決定するプロファイルのルールは、網羅的なものではなく、ブロックがインタラクティブ視覚的要素か否かを決定するにあたり、ブロック分割およびインデクス付けロジック１０６（図１）によって、追加のプロファイルのルールが考えられることに注意する。

また、１つのプロファイルがインタラクティブ視覚的要素を識別するために提示されるが、描画されたドキュメントを見るユーザが、ドキュメントのセグメントにあるインタラクティブオブジェクトを認識し、プロファイルが当該セグメントをインタラクティブ視覚的要素として認識しない場合、プロファイルを識別するより多くのインタラクティブ視覚的要素が必要となることにも注意する。

図３７は、ブロック分割およびインデクス付けロジック１０６（図１）がブロックタイムライン視覚的要素を識別するために、ドキュメントの著者が提供したヒントとなるソースコンテンツ３７００を示す。ヒントＶＳＥタイムライン（hint vse-timeline）３７０８は、タイムライン視覚的要素を含むブロック３７０８の全体を指し示す＜ＤＩＶ＞要素を識別する。ヒントＶＳＥタイムライン３７０９は、ブロック３７０２を指し示す＜Ｈ２＞要素として、タイムライン視覚的要素のタイトルを識別する。ヒントＶＳＥイベント（hint vse-event）３７１０は、タイムラインイベントとして、ブロック３７０３にまたがる＜ＬＩ＞要素を識別する。同様に、ヒントＶＳＥイベント３７０４から３７０７は、タイムラインイベントとして、ブロック３７０４から３７０７にまたがるそれぞれの＜ＬＩ＞要素を識別する。

ヒントは、あらかじめ定義されたもの、および当該ドキュメントの著者から検索エンジンサーバ１０２（図１）によって特定される適切な使用方法であることに注意する。また、一実施の形態においては、クラスアトリビュート（class attributes）はヒントとして利用されるが、他の実施の形態においては、リソースデスクリプションフレームワーク（Resource Description Framework；ＲＦＤ）、リソースデスクリプションフレームワークインアトリビュート（Resource Description Framework in attributes；ＲＦＤａ）、および／または、マイクロフォーマットなどのように、開発された、または将来開発される他の方法を用いて特定されてもよい。

所定のヒントも、パラグラフ、表、リスト、メニュー、グラフ／チャート、固定幅テキスト、インタラクティブ、キー／値、および質問／回答視覚的要素の種類のために、検索エンジンサーバ１０２（図１）によって特定され、ドキュメントの著者にドキュメントに含まれる視覚的要素を識別することに利用可能となってもよいことに注意する。また、タイトルを識別することに加えて、所定のヒントは検索エンジンサーバ１０２（図１）によって特定され、ドキュメントの著者に視覚的要素の特徴を識別することに利用可能となってもよいことに注意する。

一実施の形態において、ヒントが存在する場合、ブロック分割およびインデクス付けロジック１０６（図１）が視覚的要素、および／または、視覚的要素の特徴を正しく識別したか否かを検証するためだけに、それらは利用されてよいことに注意する。他の実施の形態においては、視覚的要素、および／または、視覚的要素の特徴を識別するプロファイルの代用としてヒントは使われてよい。さらに他の実施の形態においては、視覚的要素、および／または、視覚的要素の特徴を識別するプロファイルとともに、ヒントは使われてよい。

図１に示され、本稿をとおして説明されたブロック分割およびインデクス付けロジック１０６の高次の構造および機能の一例を示すフローチャートである。ステップ３８００において、ブロック分割およびインデクス付けロジック１０６（図１）は、処理するドキュメントの候補を識別する。ステップ３８０１において、ブロック分割およびインデクス付けロジック１０６（図１）は、ドキュメントの予備的なメタデータを生成し、当該ドキュメントのコンテンツを分割する。ステップ３８０２において、当該予備的なメタデータを用いて、当該ドキュメントは、ブロックと呼ばれるロジカルユニットに分割され、前述したルールを識別するブロックによりブロックリストが準備される。ステップ３８０３において、ブロック分割およびインデクス付けロジック１０６（図１）は、条件を満たしたブロックに対してブロック処理を実行する。ブロック処理は、上記ブロックリストにブロックを追加する、ブロックを削除する、または修正する。ステップ３８０４において、ブロック分割およびインデクス付けロジック１０６（図１）は、各ブロックに対して、どれがブロックリストタイトル（もしあれば）のブロックアイテムでないかを識別する。ステップ３８０５において、上記ブロックリストにあるそれぞれのブロックアイテムは、データと前述したメタデータルールを用いて、インライン視覚的要素に関するものかを検査される。インライン視覚的要素が発見された場合、それはインデクス付けされる。ステップ３８０６において、上記ブロックリストにあるそれぞれのブロックアイテムは、前述したプロファイルを用いて、ブロック視覚的要素に関するものかを検査される。ブロック視覚的要素が発見された場合、それはインデクス付けされる。

ステップ３８０２から３８０６の各ステップは、ステップ３８０１において生成されたメタデータを増補するメタデータを、さらに生成してよいことに注意する。

他の実施の形態において、ドキュメントをブロックに分割し、視覚的要素の識別に役立つブロック処理を実行する間に、ブロックを識別することなくソースコンテンツのセグメントに、データおよびメタデータのルールを適用することによって、視覚的要素は識別されてよいことに注意する。

クローラロジック１０５によって発見されたドキュメントが、分割されたブロックとなり、識別され、インデクス付けされた当該ドキュメントの視覚的要素となると、当該ドキュメントは視覚的要素で検索される。

図３９は、本開示の一実施の形態において使われるグラフィカルユーザインターフェース（ＧＵＩ）の一例を示す。上記ＧＵＩはクライアントロジック１１２（図１）によって、ユーザ１１３（図１）に表示される。または、それは検索エンジンロジック１０７（図１）によって、ユーザ１１４（図１）に表示される。

ＧＵＩ３９００は複数のボタン３９０１−３９１０を含み、それぞれのボタンは実行される検索の種類に対応している。また、ＧＵＩ３９００は、ユーザ１１３または１１４が検索したいキーワードを入力するためのテキストフィールド３９１１と、検索の開始を選択するための「検索」ボタン３９１２とを備える。

図示のように、ボタン３９０１−３９１０は、検索する異なる視覚的要素の種類に対応している。ユーザは、対応するボタン３９０１−３９１０を選択することによって、１つまたは複数の視覚的要素の種類を選択し、ユーザはテキストフィールド３９１１にキーワードを入力し、そしてユーザは「検索」ボタン３９１２を選択する。

ユーザがテキストフィールド３９１１に入力されたキーワードで検索し、「パラグラフ」の結果を得ることを所望する場合、ユーザはボタン３９０１を選択する。ユーザがテキストフィールド３９１１に入力されたキーワードで検索し、「表」の結果を得ることを所望する場合、ユーザはボタン３９０２を選択する。ユーザがテキストフィールド３９１１に入力されたキーワードで検索し、「リスト」の結果を得ることを所望する場合、ユーザはボタン３９０３を選択する。ユーザがテキストフィールド３９１１に入力されたキーワードで検索し、「メニュー」の結果を得ることを所望する場合、ユーザはボタン３９０４を選択する。ユーザがテキストフィールド３９１１に入力されたキーワードで検索し、「グラフ」の結果を得ることを所望する場合、ユーザはボタン３９０５を選択する。ユーザがテキストフィールド３９１１に入力されたキーワードで検索し、「チャート」の結果を得ることを所望する場合、ユーザはボタン３９０５を選択する。ユーザがテキストフィールド３９１１に入力されたキーワードで検索し、「固定幅テキスト」の結果を得ることを所望する場合、ユーザはボタン３９０６を選択する。ユーザがテキストフィールド３９１１に入力されたキーワードで検索し、「インタラクティブデータ」の結果を得ることを所望する場合、ユーザはボタン３９０７を選択する。ユーザがテキストフィールド３９１１に入力されたキーワードで検索し、「キー／値」の結果を得ることを所望する場合、ユーザはボタン３９０８を選択する。ユーザがテキストフィールド３９１１に入力されたキーワードで検索し、「質問／回答」の結果を得ることを所望する場合、ユーザはボタン３９０９を選択する。そして、ユーザがテキストフィールド３９１１に入力されたキーワードで検索し、「タイムライン」の結果を得ることを所望する場合、ユーザはボタン３９１０を選択する。

検索エンジンロジック１０７（図１）は、オペレータおよびモディファイアの使用をさらにサポートする。オペレータは、検索エンジンロジック１０７（図１）によって特定される構文の中で、あらかじめ定義された制御文字（codeword）であり、テキストフィールド３９１１に入力されるが、検索エンジンロジック１０７（図１）にはキーワードとしては解釈されない。本開示の一実施の形態において、上記オペレータの制御文字は大文字と小文字とを区別せず、構文の中に入力される。当該オペレータにおいて、制御文字は常に「：」が続き、検索キーワードが続く。

「diabetes」を検索して「パラグラフ」の結果を得るためには、「パラグラフ」の結果を得るための制御文字が、検索エンジンロジック１０７（図１）によって「p」と定義されていると仮定すると、ユーザは「p:diabetes」または「P:diabetes」をテキストフィールド３９１１に入力し、「検索」プッシュボタン３９１２を選択する。同様に、他の視覚的要素は他の制御文字をもつ。また、「diabetes」を検索して「パラグラフ」または「表」の結果を得るためには、「パラグラフ」の結果を得るための制御文字が「p」、「表」の結果を得るための制御文字が「tb」と、検索エンジンロジック１０７（図１）によって定義されていると仮定すると、ユーザは「p||tb:diabetes」または「tb||p:diabetes」をテキストフィールド３９１１に入力し、「検索」プッシュボタン３９１２を選択する。ここで、構文中の「||」は「or」を表すモディファイアである。

「or」モディファイアは、キーワードの一部として使うこともできる。例えば、「cars」または「vans」を検索して「パラグラフ」の結果を得るためには、ユーザは「p:cars||vans」をテキストフィールド３９１１に入力し、「検索」プッシュボタン３９１２を選択する。代わりに、ユーザは「cars||vans」をテキストフィールド３９１１に入力し、「パラグラフ」の結果のためのボタン３９０１を選択し、「検索」プッシュボタン３９１２を選択してもよい。

「not」モディファイアは、特定の結果を排除するために使われる。例えば、動物の「jaguar」に関して「表」の結果を得て、車の「jaguar」の結果を得ないようにするために、ユーザは「tb:jaguar ~car」をテキストフィールド３９１１に入力し、「検索」プッシュボタン３９１２を選択する。代わりに、ユーザは「jaguar ~car」をテキストフィールド３９１１に入力し、「表」の結果のためのボタン３９０２を選択し、「検索」プッシュボタン３９１２を選択してもよい。

所定のオペレータ「comp」によって、ユーザはすべての視覚的要素を一度に検索できる。これにより、すべてのボタン３９０１−３９１０を選択することを省略できる。「diabetes」を検索してすべての視覚的要素の種類の結果を得るためには、ユーザは「comp:diabetes」または「COMP:diabetes」をテキストフィールド３９１１に入力し、「検索」プッシュボタンを選択する。

所定のオペレータ「site」によって、ユーザは検索結果をある位置またはドメインに限定できる。「diabetes」を検索して「表」の結果を、ＢＢＣ（登録商標）ニュースのドメインのみから得るためには、ユーザは「site:news.bbc.co.uk tb:diabetes」または「tb:diabetes site:news.bbc.co.uk」をテキストフィールド３９１１に入力し、「検索」プッシュボタン３９１２を選択する。代わりに、ユーザは「site:news.bbc.co.uk diabetes」または「diabetes site:news.bbc.co.uk」をテキストフィールド３９１１に入力し、「表」の結果のためのボタン３９０２を選択し、「検索」プッシュボタン３９１２を選択してもよい。

ユーザが所望すれば、当該ユーザは、検索クエリの一部として視覚的要素の特徴を特定できる。これは、ＧＵＩコンポーネントまたはオペレータのいずれかをとおしてなされ、絞り込む、または視覚的要素の特徴に合致する視覚的要素を含むドキュメントに高い関係性を付与する。

「パラグラフ」の結果を検索する場合、キーワードがタイトルの一部でなければならない、あるいは「パラグラフ」の結果が少なくとも、または、等しく、または、せいぜい所定の長さでなければならないことを、ユーザは指定する。

「表」の結果を検索する場合、キーワードがタイトルの一部、表のヘッダまたは表のキャプションの一部、または表のセルの一部でなければならない、あるいは「表」の結果が少なくとも、または、等しく、または、せいぜい所定の数の行または列でなければならないことを、ユーザは指定する。

「リスト」の結果を検索する場合、キーワードがタイトルの一部、またはリストキャプションの一部でなければならない、あるいは「リスト」の結果が少なくとも、または、等しく、または、せいぜい所定の数のリストアイテムでなければならないことを、ユーザは指定する。

「メニュー」の結果を検索する場合、水平または垂直に表示された「メニュー」の結果に興味をもつことを、ユーザは指定する。

「グラフ／チャート」の結果を検索する場合、キーワードがタイトルの一部、またはキャプションの一部でなければならない、または「グラフ／チャート」の結果がヒストグラム、ハリーグラフまたはホフマングラフ、またはバーチャート、またはカラムチャート、またはラインチャート、またはステップラインチャート、またはスプラインエリアチャート、レンジカラムチャート、ストックチャート、またはドーナツチャート、またはバブルチャート、またはローソク型チャート、またはパイチャートであることを、ユーザは指定する。

「固定幅テキスト」の結果を検索する場合、キーワードがタイトルの一部でなければならないことを、または「固定幅テキスト」の結果が少なくとも、または、等しく、または、せいぜい所定の長さでなければならないことを、ユーザは指定する。

「キー／値」の結果を検索する場合、キーワードがタイトルの一部、または「キー」の一部、または「値」の一部でなければならないことを、または「キー／値」の結果が少なくとも、または、等しく、または、せいぜい所定の数のキー／値アイテムでなければならないことを、ユーザは指定する。

「質問／回答」の結果を検索する場合、キーワードがタイトルの一部、または「質問」の一部、または「回答」の一部でなければならないことを、ユーザは指定する。

「タイムライン」の結果を検索する場合、キーワードがタイトルの一部、またはタイムラインイベントの一部でなければならないことを、ユーザは指定する。

図４０は、ＧＵＩ３９００と同様の方法で駆動するＧＵＩ４０００を示す。しかし、視覚的要素の種類のそれぞれに対応するボタン３９０１−３９１０（図３９）の代わりに、ＧＵＩ４０００は選択チェックボックス４００１−４０１０を備えた。処理の間に、ユーザ１１３または１１４（図１）は、１つまたは複数のチェックボックス４００１−４０１０を選択し、テキストフィールド４０１１にキーワードを入力し、そして「検索」プッシュボタン４０１２を選択する。

図４１は、クライアントロジック１１２（図１）によってユーザ１１３（図１）に表示されるＧＵＩ４１００を示す。ユーザが視覚的要素の種類「リスト」を検索キーワード４１０２に入力した場合、それは提案４１０４をユーザに提示する検索エンジンロジック１０７（図１）によって、ユーザ１１４（図１）に表示される。ユーザは、視覚的要素の種類「リスト」に制限するような検索を示すボタン４１０１を押す。図４１に示すように、ボタンの押した状態を示すために、ボタン４１０１に斜め線の背景が追加されるが、当該斜め線は実際のＧＵＩ４１００の一部ではない。提案４１０４は「リスト」の選択４１０１と検索クエリキーワード４１０２とに基づき、検索クエリ４１０２がユーザによって更新されるたびに、提案４１０４は更新される。ユーザが提案ボックス４１０４からの提案を気に入った場合、彼は提案を採用し、「検索」ボタン４１０３を押下することにより、当該提案による検索を実行できる。

提案４１０４は検索クエリにおいて選択された視覚的要素の種類に依存し、視覚的要素の種類の異なる選択は、異なるキーワードの提案４１０４をもたらすことに注意する。また、他の実施の形態において、ユーザが検索キーワード４１０２を入力するたびに提案４１０４が更新されるだけでなく、ユーザが「検索」ボタン４１０３を押下する前から、ユーザが検索キーワードを入力するたびに、検索クエリの結果は一時的に更新される。

図４２は、クライアントロジック１１２（図１）によってユーザ１１３（図１）に表示されるＧＵＩ４２００を示す。ユーザが「検索」ボタン４２０３を押下し、検索キーワード「Diabetes Symptoms」４２０２を使って検索が実行された結果としての検索結果とともに、検索エンジンロジック１０７（図１）によって、それはユーザ１１４（図１）に表示される。視覚的要素の種類が「リスト」に限定された検索であることを示すボタン４２０１を、ユーザは押下する。図４２に示すように、ボタンの押した状態を示すために、ボタン４２０１に斜め線の背景が追加されるが、当該斜め線は実際のＧＵＩ４２００の一部ではない。検索結果４２０４、４２０５、および４２０６は、水平フォーマットでユーザに表示される。すなわち、交互に表示される。それぞれの検索結果４２０４、４２０５、および４２０６は、元のウェブページ１１１（図１）にリンクする見出しをもつ。概要が当該見出しに続く。概要は、検索クエリと関連する当該ウェブページの一部である。元のウェブページ１１１（図１）にあったのと同じ種類の視覚的要素に、概要は表示される。ブロック分割およびインデクス付けロジック１０６がリストを抽出してインデクスを付けたところのウェブページ１１１（図１）が、丸印のリストの単語を含んでいたため、検索結果４２０４は、丸印のリストとして「Polyuria」および「Polydipsia」を表示する。ブロック分割およびインデクス付けロジック１０６がリストを抽出してインデクスを付けたところのウェブページ１１１（図１）が、数字の箇条書きリストの単語を含んでいたため、検索結果４２０５は、数字の箇条書きリストとして「Weight Loss」と「Polydipsia」とを表示する。ブロック分割およびインデクス付けロジック１０６がリストを抽出してインデクスを付けたところのウェブページ１１１（図１）が、小文字のアルファベットの箇条書きリストの単語を含んでいたため、検索結果４２０６は、小文字のアルファベットとして「Blurred Vision」と「Weight Loss」とを表示する。ウェブページ１１１（図１）へのＵＲＩが概要に続く。ＧＵＩ４２００は、検索結果４２０４、４２０５、および４２０６の右側に広告セクション４２０８を備える。マーケティング担当者は、広告セクション４２０８に広告を表示させるための値段を付けることができる。１つのページにおさまりきらない量の結果がある場合、当該結果は複数のページに分割される。ユーザはページネーション制御４２０７を用いて、当該複数のページにアクセスできる。

図４３は、垂直に並べて配置された検索結果４３０５および４３０６の他の一例を示す。ユーザは、「前に」リンク４３０７、または「次に」リンク４３０８を用いることで、より多くの検索結果が利用できる場合はそれを見ることができる。広告セクション４３０４および４３０９は、マーケティング担当者が広告を配置するための値段を付けることができる。図４３００には示していないが、広告セクションは検索結果の上部および下部には限定されない。それらは右、左、または結果ページの任意の位置に配置できる。

図４４は、グリッドビューに配置された検索結果４４０５、４４０６、４４０７、４４０８、４４０９、および４４１０の他の一例を示す。図４４００は、キーワード「Diabetes」４４０３で検索を実行するユーザを示す。また、図４４００は、ボタン４４０１および４４０２をそれぞれ押下することによって、結果を「表」および「リスト」の視覚的要素の種類に限定するユーザを示す。図４４に示すように、ボタンの押した状態を示すために、ボタン４４０１および４４０２に斜め線の背景が追加されるが、当該斜め線は実際のＧＵＩ４４００の一部ではない。ブロック分割およびインデクス付けロジック１０６がリストを抽出してインデクスを付けたところのウェブページ１１１（図１）が、表として概要のセクションを備えていたため、検索結果４４０７は、表として当該セクションを示す。

本開示は、特定の好ましい実施の形態に関して説明してきたが、種々の変形および改変が当業者によってなされてもよく、本開示は上記変形および改変が添付されたクレームの範囲に含まれることを、明らかにしようとするものである。
〔請求項１〕
ドキュメントを処理する方法であって、
ソースコンテンツとプレゼンテーションセマンティクスとを含むドキュメントの予備的なメタデータを生成し、
前記予備的なメタデータを用いて、前記ドキュメントを１つまたは複数の識別されたブロックに分割し、
前記１つまたは複数の識別されたブロックのブロックリストを用意し、
ブロック処理を用いて、前記ブロックリストに含まれる前記１つまたは複数の識別されたブロックを処理し、
前記ブロックリストに含まれる少なくとも１つの識別されたブロックの少なくとも１つのタイトルのブロックアイテムを識別することを含むことを特徴とする方法。
〔請求項２〕
ドキュメントのソースコンテンツは、マークアップ言語にしたがって形式化されていることを特徴とする請求項１に記載の方法。
〔請求項３〕
前記ドキュメントのソースコンテンツは、平文で形式化されていることを特徴とする請求項１に記載の方法。
〔請求項４〕
前記ドキュメントのソースコンテンツは、インターフェースをとおしてアクセス可能な言語にしたがって形式化されていることを特徴とする請求項１に記載の方法。
〔請求項５〕
前記ドキュメントは、暗黙的なプレゼンテーションセマンティクスであることを特徴とする請求項１に記載の方法。
〔請求項６〕
前記ドキュメントは、リンクされたファイルに含まれる明示的なプレゼンテーションセマンティクスであることを特徴とする請求項１に記載の方法。
〔請求項７〕
前記ドキュメントは、明示的に埋め込まれたプレゼンテーションセマンティクスであることを特徴とする請求項１に記載の方法。
〔請求項８〕
前記予備的なメタデータは、前記ドキュメントのテキストコンテンツから導出可能な任意の情報であることを特徴とする請求項１に記載の方法。
〔請求項９〕
前記予備的なメタデータは、前記ドキュメントのマークアップコンテンツから導出可能な任意の情報であることを特徴とする請求項１に記載の方法。
〔請求項１０〕
前記予備的なメタデータは、前記ドキュメントの明示的な、および／または、暗示的なプレゼンテーションセマンティクスから導出可能な任意の情報であることを特徴とする請求項１に記載の方法。
〔請求項１１〕
前記予備的なメタデータは、前記ドキュメントの描画から導出可能な任意の情報であることを特徴とする請求項１に記載の方法。
〔請求項１２〕
前記予備的なメタデータは、以前に計算されたメタデータから計算される任意の情報であることを特徴とする請求項１に記載の方法。
〔請求項１３〕
前記ドキュメントは、所定のメタデータのルールを用いて、ブロックに分割されることを特徴とする請求項１に記載の方法。
〔請求項１４〕
前記ブロックは、ネストされることを特徴とする請求項１に記載の方法。
〔請求項１５〕
前記ドキュメントの全体はブロックであることを特徴とする請求項１に記載の方法。
〔請求項１６〕
子ブロックをもたないブロックは、ブロックアイテムとして識別されることを特徴とする請求項１に記載の方法。
〔請求項１７〕
前記ドキュメントのテキストコンテンツは、１つの、かつ、唯一のブロックアイテムに属することを特徴とする請求項１に記載の方法。
〔請求項１８〕
前記ブロックリストに含まれるブロックアイテムに対して、ブロックアイテムのフォントメタデータ属性は、ブロックフォントファミリ、ブロックフォントサイズ、およびブロックフォントウェイトが計算されることを特徴とする請求項１に記載の方法。
〔請求項１９〕
統計的な最頻値が、ブロックアイテムのフォントメタデータ属性の計算において用いられることを特徴とする請求項１８に記載の方法。
〔請求項２０〕
統計的な平均値が、ブロックアイテムのフォントメタデータ属性の計算において用いられることを特徴とする請求項１８に記載の方法。
〔請求項２１〕
数学的な公式が、ブロックアイテムのフォントメタデータ属性の計算において用いられることを特徴とする請求項１８に記載の方法。
〔請求項２２〕
前記ブロックリストに含まれるブロックアイテムに対して、ブロックアイテムインポータンスのメタデータ属性が計算されることを特徴とする請求項１に記載の方法。
〔請求項２３〕
ドキュメントをブロックに分割するときに生成される付加情報は、既存のメタデータに増補されることを特徴とする請求項１に記載の方法。
〔請求項２４〕
前記ブロックリストを生成することは、所定のメタデータのルールを用いて、前記ブロックリストから空のブロックを削除することをさらに含むことを特徴とする請求項１に記載の方法。
〔請求項２５〕
前記ブロックリストを生成することは、所定のメタデータのルールを用いて、重複したブロックを削除することをさらに含むことを特徴とする請求項１に記載の方法。
〔請求項２６〕
前記ブロックリストを生成することは、所定のメタデータのルールを用いて、中間的なブロックを削除することをさらに含むことを特徴とする請求項１に記載の方法。
〔請求項２７〕
前記ブロックリストを生成することは、所定のデータおよびメタデータのルールを用いて、ブロックを結合することをさらに含むことを特徴とする請求項１に記載の方法。
〔請求項２８〕
前記ブロックリストを生成することは、所定のメタデータのルールを用いて、ブロックを分割することをさらに含むことを特徴とする請求項１に記載の方法。
〔請求項２９〕
識別されたブロックのリストを用意するときに生成される付加情報は、既存のメタデータに増補されることを特徴とする請求項１に記載の方法。
〔請求項３０〕
検索クエリとの関連性にしたがって、ドキュメントを処理して識別する方法であって、
ソースコンテンツとプレゼンテーションセマンティクスとを含むドキュメントの予備的なメタデータを生成し、
前記予備的なメタデータを用いて、前記ドキュメントをブロックに分割し、
前記識別されたブロックのリストを用意し、
ブロック処理を用いて、前記ブロックのリストに含まれるブロックを処理し、
前記ブロックのリストに含まれるそれぞれのブロックに対して、タイトルのブロックを識別し、
インライン視覚的要素が含まれている場合、所定のデータおよびメタデータのルールを用いて、前記ブロックリストに含まれるブロックアイテムの少なくとも１つのインライン視覚的要素を識別し、
ブロック視覚的要素が含まれている場合、所定のプロファイルを用いて、前記ブロックリストに含まれる少なくとも１つのブロックの少なくとも１つのブロック視覚的要素を識別し、
発見された視覚的要素のインデクスを生成し、
グラフィカルユーザインターフェース（ＧＵＩ）を介して検索クエリのデータを受信し、前記検索クエリデータは、少なくとも１つの選択された視覚的要素の種類を含み、
前記検索クエリに関係すると決定されたそれぞれのドキュメントを識別して、前記検索クエリに対する応答を生成することを含むことを特徴とする方法。
〔請求項３１〕
ドキュメントのソースコンテンツは、マークアップ言語にしたがって形式化されていることを特徴とする請求項３０に記載の方法。
〔請求項３２〕
前記ドキュメントのソースコンテンツは、平文で形式化されていることを特徴とする請求項３０に記載の方法。
〔請求項３３〕
前記ドキュメントのソースコンテンツは、インターフェースをとおしてアクセス可能な言語にしたがって形式化されていることを特徴とする請求項３０に記載の方法。
〔請求項３４〕
前記ドキュメントは、暗黙的なプレゼンテーションセマンティクスであることを特徴とする請求項３０に記載の方法。
〔請求項３５〕
前記ドキュメントは、リンクされたファイルに含まれる明示的なプレゼンテーションセマンティクスであることを特徴とする請求項３０に記載の方法。
〔請求項３６〕
前記ドキュメントは、明示的に埋め込まれたプレゼンテーションセマンティクスであることを特徴とする請求項３０に記載の方法。
〔請求項３７〕
前記予備的なメタデータは、前記ドキュメントのテキストコンテンツから導出可能な任意の情報であることを特徴とする請求項３０に記載の方法。
〔請求項３８〕
前記予備的なメタデータは、前記ドキュメントのマークアップコンテンツから導出可能な任意の情報であることを特徴とする請求項３０に記載の方法。
〔請求項３９〕
前記予備的なメタデータは、前記ドキュメントの明示的な、および／または、暗示的なプレゼンテーションセマンティクスから導出可能な任意の情報であることを特徴とする請求項３０に記載の方法。
〔請求項４０〕
前記予備的なメタデータは、前記ドキュメントの描画から導出可能な任意の情報であることを特徴とする請求項３０に記載の方法。
〔請求項４１〕
前記予備的なメタデータは、以前に計算されたメタデータから計算される任意の情報であることを特徴とする請求項３０に記載の方法。
〔請求項４２〕
前記ドキュメントは、所定のメタデータのルールを用いて、ブロックに分割されることを特徴とする請求項３０に記載の方法。
〔請求項４３〕
前記ブロックは、ネストされることを特徴とする請求項３０に記載の方法。
〔請求項４４〕
前記ドキュメントの全体はブロックであることを特徴とする請求項３０に記載の方法。
〔請求項４５〕
子ブロックをもたないブロックは、ブロックアイテムとして識別されることを特徴とする請求項３０に記載の方法。
〔請求項４６〕
前記ドキュメントのテキストコンテンツは、１つの、かつ、唯一のブロックアイテムに属することを特徴とする請求項３０に記載の方法。
〔請求項４７〕
前記ブロックリストに含まれるブロックアイテムに対して、ブロックアイテムのフォントメタデータ属性は、ブロックフォントファミリ、ブロックフォントサイズ、およびブロックフォントウェイトが計算されることを特徴とする請求項３０に記載の方法。
〔請求項４８〕
統計的な最頻値が、ブロックアイテムのフォントメタデータ属性の計算において用いられることを特徴とする請求項３０に記載の方法。
〔請求項４９〕
統計的な平均値が、ブロックアイテムのフォントメタデータ属性の計算において用いられることを特徴とする請求項３０に記載の方法。
〔請求項５０〕
数学的な公式が、ブロックアイテムのフォントメタデータ属性の計算において用いられることを特徴とする請求項３０に記載の方法。
〔請求項５１〕
前記ブロックリストに含まれるブロックアイテムに対して、ブロックアイテムインポータンスのメタデータ属性が計算されることを特徴とする請求項３０に記載の方法。
〔請求項５２〕
ドキュメントをブロックに分割するときに生成される付加情報は、既存のメタデータに増補されることを特徴とする請求項３０に記載の方法。
〔請求項５３〕
前記ブロックリストを生成することは、所定のメタデータのルールを用いて、前記ブロックリストから空のブロックを削除することをさらに含むことを特徴とする請求項３０に記載の方法。
〔請求項５４〕
前記ブロックリストを生成することは、所定のメタデータのルールを用いて、重複したブロックを削除することをさらに含むことを特徴とする請求項３０に記載の方法。
〔請求項５５〕
前記ブロックリストを生成することは、所定のメタデータのルールを用いて、中間的なブロックを削除することをさらに含むことを特徴とする請求項３０に記載の方法。
〔請求項５６〕
前記ブロックリストを生成することは、所定のデータおよびメタデータのルールを用いて、ブロックを結合することをさらに含むことを特徴とする請求項３０に記載の方法。
〔請求項５７〕
前記ブロックリストを生成することは、所定のメタデータのルールを用いて、ブロックを分割することをさらに含むことを特徴とする請求項３０に記載の方法。
〔請求項５８〕
識別されたブロックのリストを用意するときに生成される付加情報は、既存のメタデータに増補されることを特徴とする請求項３０に記載の方法。
〔請求項５９〕
前記視覚的要素の種類は、リストであることを特徴とする請求項３０に記載の方法。
〔請求項６０〕
前記視覚的要素の種類は、表であることを特徴とする請求項３０に記載の方法。
〔請求項６１〕
前記視覚的要素の種類は、パラグラフであることを特徴とする請求項３０に記載の方法。
〔請求項６２〕
前記視覚的要素の種類は、メニューであることを特徴とする請求項３０に記載の方法。
〔請求項６３〕
前記視覚的要素の種類は、キー／値であることを特徴とする請求項３０に記載の方法。
〔請求項６４〕
前記視覚的要素の種類は、質問／回答であることを特徴とする請求項３０に記載の方法。
〔請求項６５〕
前記視覚的要素の種類は、固定幅テキストであることを特徴とする請求項３０に記載の方法。
〔請求項６６〕
前記視覚的要素の種類は、グラフ／チャートであることを特徴とする請求項３０に記載の方法。
〔請求項６７〕
前記視覚的要素の種類は、インタラクティブであることを特徴とする請求項３０に記載の方法。
〔請求項６８〕
前記視覚的要素の種類は、タイムラインであることを特徴とする請求項３０に記載の方法。
〔請求項６９〕
前記所定のプロファイルは、１つまたは複数の所定のブロックにおける、所定のデータおよびメタデータの集合であることを特徴とする請求項３０に記載の方法。
〔請求項７０〕
前記タイトルは、インライン視覚的要素およびブロック視覚的要素の両方のために識別されることを特徴とする請求項３０に記載の方法。
〔請求項７１〕
視覚的要素の特定の性質は、インライン視覚的要素およびブロック視覚的要素の両方のために識別されることを特徴とする請求項３０に記載の方法。
〔請求項７２〕
少なくとも１つの所定のヒントは、少なくとも１つの視覚的要素に関して、ドキュメントの著者または所有者によって、ドキュメントのソースコンテンツの中で提供されることを特徴とする請求項３０に記載の方法。
〔請求項７３〕
前記ヒントは、前記視覚的要素を識別することを特徴とする請求項７２に記載の方法。
〔請求項７４〕
前記ヒントは、前記視覚的要素の種類を識別することを特徴とする請求項７２に記載の方法。
〔請求項７５〕
前記ヒントは、前記視覚的要素のタイトルを識別することを特徴とする請求項７２に記載の方法。
〔請求項７６〕
前記ヒントは、前記視覚的要素の特徴を識別することを特徴とする請求項７２に記載の方法。
〔請求項７７〕
インライン視覚的要素およびブロック視覚的要素に用意されるインデクスは、視覚的要素のタイトルおよび視覚的要素の特別な特徴を含むことを特徴とする請求項３０に記載の方法。
〔請求項７８〕
前記ＧＵＩは、視覚的要素の種類を指定するためにユーザが選択するための、キーワードを入力するテキストボックスに隣接したトグルボタンを含むことを特徴とする請求項３０に記載の方法。
〔請求項７９〕
前記ＧＵＩは、視覚的要素の種類を指定するためにユーザが選択するための、キーワードを入力するテキストボックスに隣接したチェックボックスを含むことを特徴とする請求項３０に記載の方法。
〔請求項８０〕
前記ＧＵＩは、受信するステップにおいて検索クエリが受信されるたびに、当該検索クエリに関係したデータを表示することを特徴とする請求項３０に記載の方法。
〔請求項８１〕
前記ＧＵＩは、受信するステップにおいて検索クエリが受信されるたびに、当該検索クエリに関係した応答結果を表示することを特徴とする請求項３０に記載の方法。
〔請求項８２〕
前記検索クエリは、少なくとも１つの視覚的要素の種類を含むリクエストを含むことを特徴とする請求項３０に記載の方法。
〔請求項８３〕
前記検索クエリは、少なくとも１つの視覚的要素の特定の性質を含むリクエストを含むことを特徴とする請求項３０に記載の方法。
〔請求項８４〕
前記検索クエリは、少なくとも１つの負のモディファイアを含むリクエストを含むことを特徴とする請求項３０に記載の方法。
〔請求項８５〕
前記検索クエリは、少なくとも１つのモディファイアを含むリクエストを含むことを特徴とする請求項３０に記載の方法。
〔請求項８６〕
前記検索クエリは、少なくとも１つの制限された位置オペレータを含むリクエストを含むことを特徴とする請求項３０に記載の方法。
〔請求項８７〕
前記検索クエリは、少なくとも１つの視覚的要素の種類の識別オペレータを含むリクエストを含むことを特徴とする請求項３０に記載の方法。
〔請求項８８〕
前記検索クエリは、少なくとも１つの全包括的オペレータを含むリクエストを含むことを特徴とする請求項３０に記載の方法。
〔請求項８９〕
前記応答結果は、ユーザが要求した視覚的要素の種類で示されることを特徴とする請求項３０に記載の方法。
〔請求項９０〕
前記応答結果は、前記視覚的要素の種類で、および元のドキュメントで発見された前記視覚的要素と同一のプレゼンテーションセマンティクスで示されることを特徴とする請求項３０に記載の方法。
〔請求項９１〕
前記応答結果は、水平リストの形式で示されることを特徴とする請求項３０に記載の方法。
〔請求項９２〕
前記応答結果は、垂直リストの形式で示されることを特徴とする請求項３０に記載の方法。
〔請求項９３〕
前記応答結果は、格子の形式で示されることを特徴とする請求項３０に記載の方法。
〔請求項９４〕
前記応答を生成するステップは、広告データを表示することをさらに含むことを特徴とする請求項３０に記載の方法。
〔請求項９５〕
前記応答を生成するステップは、選択された前記視覚的要素の種類に基づいて、広告データを表示することをさらに含むことを特徴とする請求項３０に記載の方法。
〔請求項９６〕
１つまたは複数のウェブサーバと通信可能に接続されたネットワーク機器と、
前記ネットワーク機器を介して、前記１つまたは複数のウェブサーバから少なくとも１つのドキュメントを受信するように設計されたロジックとを含み、
前記ロジックは、前記ドキュメントの予備的なメタデータを生成するようにさらに設計され、
前記ドキュメントは、ドキュメントのコンテンツを含み、前記ドキュメントのコンテンツを分割し、前記予備的なメタデータを用いて１つまたは複数の識別されたブロックに分割し、１つまたは複数の識別されたブロックのリストを用意し、それぞれのブロックは、少なくとも１つのブロックアイテムを含み、
前記ロジックは、ブロック処理を用いて前記識別されたブロックを処理し、前記識別されたブロックのそれぞれに含まれるタイトルのブロックアイテムを識別するようにさらに設計されていることを特徴とする分割システム。
〔請求項９７〕
１つまたは複数のウェブサーバと通信可能に接続されたネットワーク機器と、
前記ネットワーク機器を介して、前記１つまたは複数のウェブサーバからドキュメントを検索するように設計されたロジックとを含み、
前記ロジックは、前記ドキュメントの予備的なメタデータを生成するようにさらに設計され、
前記ドキュメントは、ドキュメントのコンテンツを含み、前記ドキュメントのコンテンツを分割し、前記予備的なメタデータを用いて１つまたは複数の識別されたブロックに分割し、１つまたは複数の識別されたブロックのリストを用意し、それぞれのブロックは、少なくとも１つのブロックアイテムを含み、
前記ロジックは、ブロック処理を用いて発見されたブロックを処理し、データおよびメタデータを用いて、それぞれのブロックアイテムに含まれるインライン視覚的要素を識別するようにさらに設計されており、
前記ロジックは、プロファイルを用いて前記識別されたブロックおよびブロックアイテムのそれぞれに含まれるブロック視覚的要素を識別し、発見された視覚的要素のインデクスを生成するようにさらに設計されており、
前記ロジックは、検索クエリの一部として１つまたは複数の視覚的要素に対するリクエストをユーザから受信するようにさらに設計されており、
前記検索クエリは、視覚的要素の種類をさらに含み、当該検索クエリに対する応答をユーザに対して生成することを特徴とする検索システム。

Claims (15)

1. 検索クエリとの関連性にしたがって、元のドキュメントを処理して識別するコンピュータが実行する方法であって、
   ソースコンテンツとプレゼンテーションセマンティクスとを含むドキュメントの予備的なメタデータを生成し、
   前記予備的なメタデータのメタデータ属性のルールであるブロック識別基準の集合を用いて、前記ドキュメントを、１つまたは複数のブロックに識別されたブロックであって、表示されたときに視覚的に識別される当該ドキュメント内の視覚的要素を含むブロックに分割し、
   識別されたブロックのリストを用意し、
   ブロック処理を用いて前記ブロックを処理し、
   前記ブロックのリストに含まれるそれぞれのブロックに対して、タイトルのブロックを識別し、
   インライン視覚的要素が含まれている場合、所定のデータおよびメタデータのルールを用いて、ブロックアイテムに含まれる少なくとも１つのインライン視覚的要素を識別し、
   ブロック視覚的要素が含まれている場合、所定のプロファイルを用いて、少なくとも１つの前記ブロックに含まれる少なくとも１つのブロック視覚的要素を識別し、
   発見された視覚的要素のインデクスを生成し、
   受信された検索クエリのデータに基づいて検索クエリを実行し、前記検索クエリのデータは、少なくとも１つの選択された視覚的要素の種類を含み、
   前記検索クエリに関係すると決定されたそれぞれのドキュメントを識別して、前記検索クエリに対する応答を生成することを含むことを特徴とする方法。
2. 前記予備的なメタデータは、ドキュメントのテキストコンテンツ、ドキュメントのマークアップコンテンツ、ドキュメントの明示的および／または暗示的なプレゼンテーションセマンティクス、ドキュメントのレンダリング、または、メタデータから導出可能な任意の情報であることを特徴とする請求項１に記載の方法。
3. 子ブロックを持たないブロックに対して、ブロックアイテムインポータンスのメタデータ属性が計算されることを特徴とする請求項１に記載の方法。
4. 前記ブロックを処理することは、所定のメタデータのルールを用いて、空のブロックを削除すること、重複したブロックを削除すること、中間的なブロックを削除すること、ブロックを結合すること、または、ブロックを分割することをさらに含むことを特徴とする請求項１に記載の方法。
5. 前記視覚的要素の種類は、リスト、表、パラグラフ、メニュー、キー／値、質問／回答、固定幅テキスト、グラフ／チャート、インタラクティブ、および、タイムラインから成る群から選択された１つであることを特徴とする請求項１に記載の方法。
6. 前記所定のプロファイルは、１つまたは複数のブロックにおける、所定のデータおよびメタデータの集合であることを特徴とする請求項１に記載の方法。
7. タイトルは、インライン視覚的要素およびブロック視覚的要素の両方のために識別されることを特徴とする請求項１に記載の方法。
8. 前記視覚的要素の種類に特有の情報は、インライン視覚的要素およびブロック視覚的要素の両方のために識別されることを特徴とする請求項１に記載の方法。
9. 少なくとも１つの所定のヒントは、少なくとも１つの視覚的要素に関して、ドキュメントの著者または所有者によって、ドキュメントのソースコンテンツの中で提供され、前記視覚的要素、前記視覚的要素の種類、前記視覚的要素のタイトル、または、前記視覚的要素の前記種類に特有の情報を識別することを特徴とする請求項１に記載の方法。
10. インライン視覚的要素およびブロック視覚的要素に用意されるインデクスは、視覚的要素のタイトルおよび前記視覚的要素の種類に特有の情報を含むことを特徴とする請求項１に記載の方法。
11. 視覚的要素の種類を指定するためにユーザが選択するための、キーワードを入力するテキストボックスに隣接したトグルボタンまたはチェックボックスが、前記コンピュータによって提供されるグラフィカルユーザインターフェース（ＧＵＩ）に含まれることを特徴とする請求項１に記載の方法。
12. 前記検索クエリは、少なくとも１つの視覚的要素の種類、前記少なくとも１つの視覚的要素の前記種類に特有の情報、少なくとも１つの「not」モディファイア、少なくとも１つのモディファイア、少なくとも１つのオペレータ「site」、少なくとも１つの視覚的要素の種類の識別オペレータ、または、少なくとも１つのオペレータ「comp」を含むリクエストを含むことを特徴とする請求項１に記載の方法。
13. 応答結果は、ユーザが要求した視覚的要素の種類で示されることを特徴とする請求項１に記載の方法。
14. 応答結果は、水平リストの形式、垂直リストの形式、または、格子の形式で示されることを特徴とする請求項１に記載の方法。
15. １つまたは複数のウェブサーバと通信可能に接続されたネットワーク機器と、
    前記ネットワーク機器を介して、前記１つまたは複数のウェブサーバから元のドキュメントを検索するように設計されたロジックとを含み、
    前記ロジックは、前記ドキュメントの予備的なメタデータを生成するようにさらに設計され、
    前記ドキュメントは、ドキュメントのコンテンツを含み、前記予備的なメタデータのメタデータ属性のルールであるブロック識別基準の集合を用いて前記ドキュメントを、１つまたは複数の識別されたブロックであって、表示されたときに視覚的に識別される当該ドキュメント内の視覚的要素を含むブロックに分割し、前記ブロックのリストを用意し、それぞれのブロックは、少なくとも１つのブロックアイテムを含み、
    前記ロジックは、ブロック処理を用いて発見された前記ブロックを処理し、インライン視覚的要素が含まれている場合、所定のデータおよびメタデータのルールを用いて、それぞれのブロックアイテムに含まれるインライン視覚的要素を識別するようにさらに設計されており、
    前記ロジックは、ブロック視覚的要素が含まれている場合、所定のプロファイルを用いて、少なくとも１つの前記ブロックに含まれるブロック視覚的要素を識別し、発見された視覚的要素のインデクスを生成するようにさらに設計されており、
    前記ロジックは、検索クエリのデータの受信に基づいて、検索クエリを実行し、当該検索クエリに対するユーザへの応答を生成するようにさらに設計されており、
    前記検索クエリは、視覚的要素の種類をさらに含むことを特徴とする検索システム。

Images