(57)【要約】  モバイルデバイスのネットワーク探索プラットフォームを提供する際に、特定の加入者、モバイルデバイス、及び／又は探索コンテキスト（日付、時刻、ロケーション、プロファイル等）に探索の結果を合わせるように探索プラットフォームを適合させることができる。コンテンツが、関連付けられるメタ情報を伴うように規定することによって、且つ、上記メタ情報のフォーマットを理解するローカルユーザエージェントを設けることによって、探索エンジンは、ディープインデックスのコンテンツデータベースを組み立てることができる。その結果、不要なコンテンツの配信の機会を最小にしながら、加入者に最も適したコンテンツアイテムを表す探索結果を提示することができる。【選択図】図１
2009523284.tif 000002
【特許請求の範囲】
【請求項１】
無線電気通信接続上の複数のコンテンツアイテムを含むコンテンツストア（１５０）のインデックス（１２０）から探索結果を生成する方法であって、各コンテンツアイテムは、該コンテンツアイテムに関連付けられる対応するメタ情報を有し、該メタ情報は、デバイス、加入者、及びコンテキスト固有の情報のうちの少なくとも１つを備えており、該方法は、
モバイルデバイス（１３０）を使用するユーザから探索要求メッセージを受信するステップであって、該探索要求メッセージはユーザ探索用語を含む、ステップ、
前記モバイルデバイス（１３０）、ユーザ加入、及びネットワーク能力を表すコンテキストデータを取得するステップ、
前記ユーザ探索用語に従って前記コンテンツストアインデックス（１２０）の探索を開始するステップ、
前記ユーザ探索用語のうちの少なくとも１つに関して、前記コンテンツストアインデックス（１２０）に１つ又は２つ以上の相関するインデックスエントリーが存在するか否かを判断するステップ、並びに
相関が存在する場合に、探索結果を生成するステップであって、前記探索の前記結果は、前記コンテキストデータに従ってランク付けされた相関するコンテンツアイテムへのそれぞれのリンクを含む、ステップ、
を含む、方法。
【請求項２】
請求項１に記載の方法であって、コンテキスト基準及びユーザプロファイルに基づいてフィルタリングするステップをさらに含む、方法。
【請求項３】
請求項２に記載の方法において、前記ユーザプロファイルは、前記電気通信接続を確立する際に取得される情報から自動的且つ動的に生成される、方法。
【請求項４】
請求項２又は３に記載の方法において、前記ユーザプロファイルのうちの少なくとも一部は、前記電気通信接続の期間中に前記ユーザによって手動で提供される、方法。
【請求項５】
請求項４に記載の方法において、前記ユーザロケーションは、前記電気通信接続の期間中に前記ユーザによって手動で入力される、方法。
【請求項６】
請求項１〜５のいずれか１項に記載の方法において、前記探索の前記結果は、ユーザが、現在、前記コンテンツをトランスポートするのに適切なベアラ技術にアクセスしているか否かを反映するように合わせられる、方法。
【請求項７】
請求項１〜６のいずれか１項に記載の方法において、各コンテンツアイテムは、追加メタ情報を運ぶことが必要とされ、該追加メタ情報によって、前記コンテンツインデックスは、前記メタ情報に加えて前記追加メタ情報のインデックスを提供する、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モバイルデバイスの探索プラットフォームに関する。特に、本発明は、特定の加入者、モバイルデバイス、及び／又は探索コンテキスト（日付、時刻、ロケーション、プロファイル等）に探索結果を合わせるようになっている探索プラットフォームに関する。
【背景技術】
【０００２】
探索エンジンは、コンピューティングネットワークに記憶されているコンテンツのリッチエクスペリエンスの中心になってきている。ディレクトリポータルと共に、探索エンジンはインターネット（特に、ウェブ）の効果的な使用を容易にする。
【０００３】
しかしながら、探索エンジンは、それ自体の課題を提示する。多くの場合、探索要求は、探索結果に、適度に評価できるものよりもはるかに多くの探索「ヒット」を生じさせる。探索エンジンの大多数は、ブラウズ可能な結果の個数を、より管理可能な数に制限し、最も関連のあるヒットを特定してそれらのヒットをそれ以外で類似したヒットの前にランク付けしようとする。この問題は、多くの場合、モバイル環境では一層ひどくなる。モバイル環境では、典型的には、ブラウズ可能なスクリーン面積がはるかに小さく、料金請求モデル（charging model）は、データの各バイトのダウンロードが、ユーザに対する瞬時コストを表すだけでなく、対応するダウンロード遅延も表すことを意味する可能性がある。
【０００４】
潜在的な探索ヒットの膨大な量を管理する１つの従来の方法は、探索結果をフィルタリングしてからレンダリングし、それによって、端末ユーザに提示されるヒット数を削減することである。この技法は、モバイル環境に特有のものではない。
【０００５】
モバイル探索サービスをモバイル端末に設けることに対するもう１つの課題は、モバイルアリーナ（mobile arena）において異なるデバイス、オペレーティングシステム、及び標準規格が急増したことである。１つのデバイスでブラウズ可能なコンテンツは、別のデバイスでは使用できない可能性があるが、このことは、そのコンテンツがダウンロードされるまで端末ユーザには明らかでない場合があり、ユーザエクスペリエンスを乏しくすることにつながり、ダウンロード時にさらなる試みを思いとどまらせる。
【０００６】
これらの問題に対処しようとして、提示フォーマット（presentation format）標準規格が、特に、より制限の多いモバイルデバイスの表示スクリーンにおける提示を念頭に置いて開発されてきた。このような１つの標準規格であるワイヤレスアクセスプロトコル（ＷＡＰ）は、モバイルデバイスにブラウズ可能コンテンツを提供するときに、モバイルネットワークオペレータによって広く採用されてきた。このプロトコルは、関連付けられるコンテンツフォーマットであるワイヤレスマークアップ言語（ＷＭＬ）を有する。ＷＭＬ仕様は、ＸＭＬに基づいている。
【０００７】
ＷＭＬ文書（「ｄｅｃｋ」）は、ＨＴＭＬ（ハイパーテキストマークアップ言語）文書とほぼ同じ方法でウェブサーバに記憶される。モバイル端末は、ＷＡＰゲートウェイを介してＷＭＬのｄｅｃｋにアクセスする。ＷＡＰゲートウェイは、ＷＭＬコンテンツとのインターフェースを提供し、さらにはワールドワイドウェブとのインターフェースも提供する。
【０００８】
モバイル端末での提示用に当初フォーマットされていなかったウェブページを、このような端末（たとえば、携帯電話及び携帯情報端末ＰＤＡ）での表示に適したフォーマットに「トランスコード」又は処理することが既知である。このトランスコードプロセスは端末から隠蔽されており、ネットワークオペレータがトランスコードプロセスを阻止していない場合には、トランスコードプロセスによって、端末は、ＰＣブラウザアプリケーションが、ＵＲＬ（ユニバーサルリソースロケータ）を使用してＨＴＭＬコンテンツにアクセスするのと同じ方法で、トランスコードされているページにアクセスすることが可能になる。（より進んだ処理能力を有する）選択された端末は、プロセッサをより多く使用するフォーマットであるＸＨＴＭＬ及び／又はＨＴＭＬを実際にはサポートするため、トランスコードが常に必要であるとは限らない。
【０００９】
明らかに、モバイル環境では、ユーザ（及びユーザのデバイス）の能力及びプロファイルをより正確に反映する探索結果を生成することの重要性が最優先である。
モバイル探索機能を設ける際の最初の既知のステップは、探索結果をユーザに提示する前に、デバイスがＷＭＬ又はＸＨＴＭＬをサポートするか否かに基づいてコンテンツをフィルタリングすることである。
【００１０】
より最近では、デバイス固有の探索能力を提供する試みが行われている。このような探索能力は、デバイスのコンテンツとの正確な整合性に依拠しているため、その有効性が限られている。従来のデバイス固有の探索ツールは、いずれのコンテンツがいずれのデバイスに適しているのかの最新の記録を維持することが難しいという一部の理由から、決して包括的なものではない。さらに、従来のデバイス固有の探索ツールは、各コンテンツプロバイダからの個々のコンテンツフィード（content feed）を統合しなければならず、これは、多くの場合、多大な労力を必要とする。
【００１１】
また、（モバイル探索結果ページ上にリストするための広告資金提供を受け取る場合、又は、供給者若しくはその関係者から提供されるネットワーク内からのコンテンツを取得するようにユーザに勧める場合に起こり得るように）或る「ヒット」を、ポリシーの問題としてランキングを「ブースト（boost）」することによって、その「本来」の順序外にランク付けすることを認めることが知られている。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
したがって、既存のモバイル探索プラットフォームの上述した限界を克服することが、本発明の目的である。
【課題を解決するための手段】
【００１３】
本発明の一態様によれば、無線電気通信接続上の複数のコンテンツアイテムを含むコンテンツストアのインデックスから探索結果を生成する方法であって、各コンテンツアイテムは、そのコンテンツアイテムに関連付けられる対応するメタ情報を有し、メタ情報は、デバイス、加入者、及びコンテキスト固有の情報のうちの少なくとも１つを備え、当該方法は、
モバイルデバイスを使用するユーザから探索要求メッセージを受信するステップであって、探索要求メッセージはユーザ探索用語を含む、ステップ、
モバイルデバイス、ユーザ加入、及びネットワーク能力を表すコンテキストデータを取得するステップ、
ユーザ探索用語に従ってコンテンツストアインデックスの探索を開始するステップ、
ユーザ探索用語のうちの少なくとも１つに関して、コンテンツストアインデックスに１つ又は２つ以上の相関するインデックスエントリーが存在するか否かを判断するステップ、並びに
相関が存在する場合に、探索結果を生成するステップであって、探索の結果は、コンテキストデータに従ってランク付けされた相関するコンテンツアイテムへのそれぞれのリンクを含む、ステップ、
を含む、方法が提供される。
【００１４】
この方法は、デバイス固有の基準に基づいてフィルタリングすることに加えて、たとえば、ネットワーク能力（たとえば、ベアラ技術は、ＧＰＲＳ、ＥＤＧＥ、ＵＭＴＳ／３Ｇ、又はＨＳＤＰＡ等であるか？  現在のネットワーク負荷ステータスはどうであるか？）及びユーザプロファイル（自動的且つ動的に生成されるのか、又は、ユーザによって手動で生成されるのか）といったコンテキスト基準に基づいてフィルタリングするステップを含むことができる。
【００１５】
ユーザプロファイルは、ロケーションの表示を含むことができる。このロケーション情報は、加入者が手動で入力することもできるし、代替的に、たとえば、セルＩＤ又は全地球測位衛星（ＧＰＳ）情報を使用する自動ロケーションメカニズムを通じて取得することもできる。ＧＰＳ技法及びセルＩＤ技法の双方は、当該技術分野で既知であり、本文脈では説明しない。
【００１６】
したがって、本発明は、ディープリンクのデバイス固有探索に、カテゴリー化された結果表示を提供する。あらゆる探索要求の探索用語入力だけでなく、ユーザ情報、加入情報、デバイス情報を利用することによって、モバイル探索エクスペリエンスの有効性が、大幅に高められる。
【００１７】
本明細書で説明するようなモバイル探索は、デバイス、ユーザ、及びネットワーク能力の詳細なコンテキストプロファイルに基づく探索結果を返すことによって、Ｇｏｏｇｌｅ及びＹａｈｏｏ等の探索エンジンからのユーザエクスペリエンスを改善する。モバイルユーザには、ユーザ固有のデバイス及び状況にとって一般に最適でないコンテンツ、多くの場合、有料のダウンロード可能なデジタルコンテンツはもはや提示されない。
【００１８】
探索結果は、ユーザが、コンテンツを受信するために正しいモバイルネットワークカバレージエリア（たとえば、３Ｇ）に存在するか否かを反映するように好都合に合わせられる。
【００１９】
「オンネット」のコンテンツは、そのコンテンツに関してディープ情報を示す追加のメタタグを運ぶことが必要とされ、たとえば、コンテンツが特定のデバイス向けであるか否か、カラーディスプレイ用のみであるか否か、有料チャネルの加入者向けのみであるか否か、又は、実際に「成人向け」のみであるか否かを示す追加メタタグを運ぶことが必要とされる。クローラエージェントは、自身のインデックスを付されたデータベース（コンテンツストアインデックス）を生成すると、対応する「知的な」探索エンジンが利用するためのより豊富なデータベースを提供する。その後、結果は、最も関連のあるコンテンツ／結果が、より高い重み付けを与えられるようにランク付けされる。
【００２０】
次に、本発明をより良く理解するために、例として、添付の図面を参照して実施形態を説明する。
【発明を実施するための最良の形態】
【００２１】
図１は、モバイル探索プラットフォーム１００、１１０、１２０を含む一般的なモバイルポータルシステムのアーキテクチャを示している。このプラットフォームのコンポーネントのオペレーションを次に説明する。
【００２２】
コンテンツは、１つ又は２つ以上のコンテンツストア１５０に記憶されている。各コンテンツアイテムは、そのコンテンツアイテムの属性の範囲を記述する関連メタ情報を有する。これを行う１つの標準化されている方法は、ＲＤＦ（Resource Descriptor Framework）（資源記述子フレームワーク）メタデータの使用を規定することである。ＲＤＦは、ワールドワイドウェブ資源及びそれらの資源固有のメタデータ（たとえば、タイトル、作者、作成日付、最後の変更の日付、著作権、ライセンス等）の情報、並びに、ネットワーク上で識別することができる「オブジェクト」を記述する言語として定義されているＷ３Ｃ標準規格である。
【００２３】
Ｗ３Ｃメタデータアクティビティのウェブページは、ＲＤＦを以下のように説明している。すなわち、資源記述フレームワーク（Resource Description Framework）（ＲＤＦ）は、「メタデータのより一般的な処理法を提供する」と説明している。
【００２４】
ＲＤＦは、宣言型言語であり、ＸＭＬを使用して、ウェブのアイテムのプロパティ及び関係に関してのメタデータを命令文の形で表すための標準的な方法を提供する。このようなアイテムは、資源として既知であり、ウェブアドレスを有するものであるならば、ほとんどあらゆるものとすることができる。これは、メタデータを、ウェブページ、グラフィック、オーディオファイル、映画クリップ等に関連付けることができることを意味している。
【００２５】
ＲＤＦは、独立したコミュニティが、そのコミュニティ固有のニーズに適する語彙を開発することができ、且つ、他のコミュニティと語彙を共有することができるフレームワークを提供する。語彙を共有するには、用語の意味が詳細にスペルアウトされなければならない。これらの語彙セットを記述したものは、ＲＤＦスキーマと呼ばれる。
【００２６】
スキーマは、一組のプロパティの意味、特性、及び関係を定義し、これは、可能性のある値に対する制約及び他のスキーマからのプロパティの継承を含むことができる。ＲＤＦ言語によって、メタデータを含む各文書は、各語彙にウェブアドレスを割り当てることによっていずれの語彙が使用されているのかを明確にすることが可能になる。要約すると、ＲＤＦは拡張性を有する。
【００２７】
図１に示す実施形態では、ＲＤＦスキーマは、着信音、ゲーム、映像、音楽等のモバイルコンテンツに関してのメタ情報を記述するように定義されている。メタ情報は、特定のコンテンツアイテムが所与のクラスのモバイルデバイスに適しているか否かの表示を含むことができる。
【００２８】
図１で使用される探索インデックスは、リモートの外部パートナによってホスティングされる。探索インデックス１２０のリモートサイトからコンテンツストア１５０をクロールすることによって探索インデックス１２０をポピュレートするのではなく、出願人は、以下のものを提供するユーザエージェントに基づいた「内部探索クローラ」１６０を開発した。
【００２９】
異なる頻度でクロールされたコンテンツストアの異なるセクションを有する能力
探索クロールの進行を監視するより優れた能力
ＲＤＦメタデータの改良されたサポート
複数のコンテンツアイテムに関する情報を含む単一のＲＤＦメタデータファイルのサポート
その結果、内部探索クローラ１６０は、関連のある探索結果の改善された品質及び個数を配信する。
【００３０】
内部探索クローラ１６０の導入を容易にするには、パートナコンテンツプロバイダ（いわゆる、パートナマークアップ言語、すなわちＰＭＬ）及びＲＤＦファイルシンタックスによって実行されるメタタグ付けの詳細な要件における、或る軽微ではあるが本質的な相違が必要とされてきた。特に、内部クローラ１６０が基づいているユーザエージェントには、すべての対応するＲＤＦファイルに加えて、すべてのハンドセットのすべてのコンテンツへのアクセスが与えられる。
【００３１】
内部クローラ１６０は、マルチエントリーＲＤＦファイルが現れる場合には、それらをパースするように構成され、コンテンツプロバイダ１４０に、それらのＲＤＦ作成ロジックを変更してこれを利用する機会を与える。
【００３２】
参照ページのＵＲＬがＲＤＦファイル内に組み込まれたＵＲＬと一致する場合に、結果が単一の探索インデックスエントリーにマージされ、それによって、コンテンツ発見能力が改善されることを確実にするロジックが、内部探索クローラユーザエージェント１６０に導入される。
【００３３】
ユーザエージェントは、ＲＤＦへのmeta-refの相対リンク、及び、ＲＤＦファイル自体の相対リンクを使用するように構成することができる。
使いやすくするために、コンテンツ用に生成されたＲＤＦファイルに関して、或る制限を規定することができる。たとえば、
ｒｄｆ「about」属性は、フォーマット<rdf:Description about="some/link">で提示しなければならず、フォーマット<rdf:Description rdf:about="some/link">で提示してはならない。
【００３４】
ＲＤＦファイルは、dc:description属性を含まなければならない。
ＲＤＦファイルは、サフィックス「.xml」を有しなければならない（許容されたクエリ文字列：たとえば、/showrdf.xml?id=1234）。
【００３５】
ＲＤＦファイルは、タイプtext/xmlとして送信しなければならない。
内部クローラの実行
内部クローラ１６０は、ウェブサーバ自体を特定した後、ウェブサーバへページを要求する。このページは構成ファイルのエントリーポイントとして指定される。ページが取得されると、内部クローラ１６０は、サードパーティが供給したページと共に、コンテンツに関してのＲＤＦメタ情報のコンテンツを読み出して処理し、タイトル、テキスト、リンク、及び他のすべての関連情報を抽出する。このプロダクト（product）は、すでに従ってきたリンクのリストの記述を維持しながら、現在のページで発見された新しいリンクに従う。構成ファイルは、パターン（すなわち、文字列）を使用して限られたサイトナビゲーションを可能にする構成可能フィルタも有する。このプロダクトがページをクロールするごとに、取得された有効な情報はローカルデータベース（図２の２１０）に記憶される。
【００３６】
所与のモバイル電気通信ネットワークオペレータのネットワーク内の異なる地理的領域は、多くの場合、対応する運用会社が受け持つ。各運用会社は、端末アプリケーションを介したコンテンツの提供をハンドリングするソフトウェアスタックのローカルバージョンをインストールすることを選択することができる。ビスポーク（bespoke）内部クローラを、各運用会社のサービス配信プラットフォーム（又は「コアスタック」）で実施することができる。
【００３７】
各内部クローラシステムは、各運用会社に適切なソフトウェアスタック内で動作するように構成することができるため、従来の外部に設けられたクローラシステムを上回る中間速度の利点がある。
【００３８】
クロールはアセンブリレイヤで行われ、これは、内部クローラ１６０用にコンテンツをレンダリングする必要がないことを意味する
到来するクロール要求は、インターネット待ち時間に影響されない
サードパーティではなくネットワークサービスプロバイダ（又は運用会社）の制御下にある内部クローラ１６０を有することによって、異なる時間及び頻度で動作する複数のクローラタスクを設定することができ、各ローカルオペレータは、何が起こっているのかをリアルタイムで見ることが可能になる。その結果、頻繁に変化するコンテンツ（たとえば、ニュース記事）を、比較的静的なコンテンツ（たとえば、着信音）よりも高い頻度でクロールすることができ、新しいクローラ又は変更された既存のクローラの開始ポイントを、コンテンツプロバイダからの要求に応答してはるかに素早く追加することができ、またクローラの進行を監視してデバッグするための設備を、コンテンツアイテムがインデックスを付されるのを妨げる問題を特定して修正するように高度化することができる。
【００３９】
図３は、内部クローラアプリケーション１６０のソフトウェア階層を示している。この内部クローラアプリケーション１６０によって、クロールタスクの頻度及びタイミングをスケジューリングすることができる。変化する個数のエージェントの個々のインスタンス（「スレッド」）は、任意の所与のタスクの処理を行うことができる。各クロールセッションは、複数の異なるタスクを順に規定することができる。
【００４０】
内部クローラ１６０は、単一のコンテンツを参照する複数の小さなＲＤＦメタデータファイルと共に機能するように設計されているだけでなく（ＦＡＳＴ（登録商標）が提供している従来のFAST-SEARCHクローラから既知である配置）、コンテンツの複数のアイテムを参照する大きなＲＤＦメタデータファイル（「マルチエントリーＲＤＦファイル」）と共に機能するようにも設計されている。その結果、コンテンツの詳細をデータベース１５０に記憶するコンテンツプロバイダ１４０にとって、大きなＲＤＦファイルが、データベース１５０内に、すべてのコンテンツの詳細と共に作成（又は、サーバ側ロジックによってオンザフライで作成されるようにプログラミング）される場合、それらの大きなＲＤＦファイルの情報は、そのプロバイダからさらなるページをクロールする必要なく、インデックス１２０に直接挿入される。さらに、サードパーティコンテンツプロバイダ１４０からのコンテンツは、探索結果においてはるかに見やすくなり、ユーザトラフィック及び利益の増加が促進される。
【００４１】
探索プラットフォームのオペレーション、特に、探索コンテンツプッシュエンジン（ＳＣＰＳ）１８０のオペレーションを図２に示す。ＳＣＰエンジン１８０は、ＸＭＬライタ（XMLwriter）機能、アップローダ（Uploaeder）機能、及びクリーナ機能を含む多数の実行機能を有する。これらの機能を以下に説明する。
ＸＭＬライタの実行
各単一のクロールタスクは、ローカルデータベース２１０（たとえば、Ｏｒａｃｌｅ（登録商標）データベース）をクロール情報でポピュレートする。これらは、外部探索エンジン１１０によってホスティングされたリモート探索インデックス１２０にアップロードするために、ＸＭＬデータに変換する必要がある。ＸＭＬライタは、データベースに記憶されているタスクデータ（すなわち、クロール情報）を取り出し、それらのタスクデータを、リモートインデックスデータベース１２０の仕様に従って、カスタマイズされたＸＭＬファイルに変換する。
アップローダの実行
ＸＭＬライタによって生成されたＸＭＬファイルは、文書としてリモート探索インデックス１２０にアップロードされ、同じ文書の旧バージョンに取って代わるか、又は、旧バージョンが存在しない場合には新しい文書を挿入する。その後、このデータはモバイルインターフェース１３０を通じて閲覧することができる。
クリーナの実行
クリーナは、リモート探索インデックスへの接続を確立し、適切な構成ファイルに現れる設定によって定義された特定の特徴を有する一組の文書を削除する。古くなった文書の削除から、特定のフィールド値を有するすべての文書の削除まで、いくつかの異なるクリーニングタイプがサポートされている。
【００４２】
モバイル探索ポータル１００のオペレーションは、おそらく、加入者がポータル１００を介してコンテンツを探索することを選択する例示の使用ケースを考慮するとき、最も良く理解される。
【００４３】
ポータル１００は、探索インターフェース１３０を加入者のモバイルデバイスに提示する。これによって、加入者は探索基準を指定することが可能になる。この場合に、加入者はワード又はフレーズを入力するものと仮定する。
【００４４】
探索インターフェース１３０は、さらなるオプションをさらに提供することができる。好都合に、コンテンツタイプに基づいて探索を制限するオプションが存在し得る。また、すべてのコンテンツタイプが探索されることを必要とするオプションが存在し得る。コンテンツタイプ制限オプションが採用されていないとき、加入者はすべての利用可能なコンテンツを探索したいものと仮定することができる。一方、加入者がコンテンツタイプを選択する場合、ポータル１００は、加入者が探索を開始することを可能にする。
【００４５】
システムは、加入者から探索要求を受け取り、そのポータル要求を処理する。まず、加入者は認証される。加入者が認証されると、要求が認可される。
認証プロセスにおいて、コンテキスト情報が取得される。このコンテキスト情報は、ユーザの加入者プロファイルに関する情報（たとえば、言語の嗜好、安全探索基準、クレジットレベル等）及び認証プロセスでモバイル端末によって配信される情報（たとえば、加入者のデバイスタイプ）を含む。
【００４６】
次に、ポータルシステム１００は、探索が有効であることを確実にするために、サブミットされた探索基準をチェックする（たとえば、探索基準は、少なくとも２つの認識された文字を含む）。次に、システムは、探索基準を、コンテキスト情報及びコンテンツタイプ（選択されていた場合）と共に探索エンジン１１０へ送信する。
【００４７】
探索エンジン１１０は、有効な探索基準を処理して、ランク付けされたデバイス固有の探索結果を生成する。
次に、ポータルシステムのコアスタック１３２は、デバイス固有の探索結果を探索エンジン１１０から受け取り、加入者のディスプレイに提示するために、それらの探索結果をレンダリングする。
【００４８】
コアスタック（又はサービス配信プラットフォーム）１３２は、サードパーティ統合コンポーネント（３ＰＩ）２３０、コンテンツ（又は共通）アセンブリエンジン（ＣＡＥ）２４０、及びコンテンツレンダリングエンジン（ＣＲＥ）２５０を含む。これらのコンポーネントは、図１及び図２の双方に示されているが、図２にしか参照符号は与えられていない。
【００４９】
３ＰＩ２３０は、コンテンツ自体に加えて、コンテンツプロバイダ２２０、２２２、２２４によって提供されるパートナマークアップ言語（ＰＭＬ）ファイルのＲＤＦタグ情報を受け取る。３ＰＩ２３０は、コンテンツアイテムに対応するＲＤＦタグ情報を抽出し、抽出された情報をオペレータマークアップ言語（本出願人の場合には、ボーダフォンコンテンツマークアップ言語（Vodafone Content Markup Language）、すなわちＶＣＭＬ）の「フラグメント」として供給する。
【００５０】
次に、オペレータマークアップ言語のフラグメントは、より高いレベルであるレンダリングレイヤへ配信するために、アセンブリレイヤで組み立てられる。アセンブリレイヤの機能は、ＣＡＥ２４０によって提供される。ＣＡＥ２４０は、ユーザからの入力要求を解釈して、コンテンツソースから情報（すなわち、ＶＣＭＬフラグメントの抽出されたＲＤＦタグ情報）を取得し、応答を構成するピースを単一のコンテンツ文書（この例では、ＶＣＭＬ「ページ」）に組み立てるソフトウェアコンポーネントである。次に、ＣＡＥ２４０は、組み立てられたコンテンツをレンダリングレイヤへ送る。
【００５１】
ＣＡＥ２４０の一般的なアーキテクチャを図４に示す。このいわゆるＭＶＣ（モデル／ビュー／コントローラ）アーキテクチャ内では、ビジネスロジッククラス及びビジネスロジックビーンがモデルを備え、ＪＳＰファイル及びカスタムタグがビューを備え、アクションがコントローラを備える。ビジネスロジックは、いくつかのレイヤ、すなわち、サービスオブジェクト及びマネージャオブジェクトにさらに分割することができる。サービスオブジェクトは、ビジネスロジックのコアであり、マネージャオブジェクトの上に位置する。マネージャオブジェクトは、パーシステンス等のより低いレベルの機能、すなわち、探索ポータルの場合には、外部探索サーバへの接続をカプセル化する。
【００５２】
アクションの重要な例は、SubmitSearchAction（探索アクションサブミット）である。このSubmitSearchActionは、要求からユーザのクエリを抽出し、そのクエリの有効性を確認し、探索を行うビジネスロジックをコールすることを担当する。このアクションを補完するために、本ＣＡＥは、SearchService（探索サービス）及びSearchManager（探索マネージャ）を提供する。SearchServiceは、このようなことを内部結果のブーストとして可能にする、探索エンジンの実施態様から独立したビジネスロジックを担当する。SearchManagerは、シンタックス的に正しいクエリの生成すること、及び探索エンジン結果オブジェクトを、高位レイヤによる消費のために一般的な値のオブジェクトに変換すること等、実施された探索エンジンに固有のビジネスロジックを担当する。
【００５３】
コンテンツレンダリングレイヤは、探索結果オブジェクトを受け取り、マークアップ言語をパースし、結果オブジェクトを表示に適したフォーマットで配信する。ユーザデバイスの認証時に抽出された情報を使用して、ＣＲＥ２５０は、エンドユーザのデバイスを認識し、デバイスの属性を使用して、ＣＡＥ２４０から得られた画像及びテキスト等の資源を、特定のデバイスに適切なサイズ及びフォーマットに変換する。また、ＣＲＥ２５０は、ユーザデバイスとサービス配信プラットフォームの残りの部分との間の接続を管理し、特に、ユーザ要求を抽出する探索インターフェース１３０の提供を管理する。
【００５４】
コアスタック１３２には、代替的なスペリング応答を探索結果と共に生成するスペリング推論エンジン（図示せず）を提供することができる。これは、ミススペリングの一般的なエキスペリエンスに対処し、「最も可能性のある」代替的な探索用語を提案する。
【００５５】
要求の認可を加入者プロファイルに対して強調することによって、ポータル１００は、年齢別に分類されたコンテンツ及び／又は年齢制限のあるコンテンツに対応する結果をフィルタリング除去することができる。
【００５６】
或るコンテンツアイテムは、関連付けられる瞬時値を有するため、ポータル１００は、返されたコンテンツアイテムへのリンク内でサービスＩＤタグ（すなわち、料金請求タグ（charging tag））を検出するように構成されている。サービスＩＤが探索エンジン１１０によって返されたアイテム内に含まれており、且つ加入者がそのコンテンツをダウンロードすることを選択する場合、料金は加入者のアカウントから差し引かれる。
【００５７】
サービスＩＤが探索エンジン１１０によって返されたアイテム内に含まれていない場合、ポータルはアイテムを探索結果デッキに表示する。デッキは、入力された探索基準、表示される探索基準に一致した結果の総数、及びハイパーリンクとしての各探索結果を、各探索結果のティーザ広告（teaser）の記載と共に示す。探索結果は、コンテンツタイプによってグルーピングされて表示することができる。探索結果は、サービスプロバイダによってホスティングされているコンテンツ（「オンネット」）と、プロバイダによって管理されないウェブサーバでホスティングされているコンテンツ（「オフネット」）とを区別することができる。結果デッキは、各グループの結果の総数を別個のアイテムとして表示することによって、この分類を示すことができる。
【００５８】
好都合に、探索結果は関連性に従って順序付けられた各グループ内に表示される。したがって、システムは、所定のしきい値以上の関連性ランキングを有する結果を表示するように構成することができる。「オンネット」探索結果は、同様の「オフネット」結果よりも上に個々に「ブースト」することもできるし、「オンネット」グループとして、対応する「オフネット」グループよりも上に提示することもできる。料金がコンテンツのダウンロードに関連付けられている場合、探索結果デッキは、そのことを、たとえばアイコンで視覚的に示すことができる。
【００５９】
上記で概説した探索プロセスは、「探索ヒント」機構によって補完することができる。この「探索ヒント」機構によって、加入者は、適した結果用語、ワイルドカードシンボルに関してのガイダンスを要求することができる。
【００６０】
探索プロセスを絞るために、加入者はワード探索をコンテンツタイプ制限で修飾することができる。より一般的に言えば、探索要求のコンテキストに基づく探索プロセス、いわゆるコンテキスト探索に加入者を案内することができる。加入者は、コンテキスト探索ハイパーリンクからコンテンツを探索することを選択する。システムは、事前に選択されたコンテキスト（たとえば、コンテンツタイプ）を有する探索ダイアログページを返す。コンテンツタイプの例は、着信音、ゲーム、映像、及び音楽である。また、システムは、加入者が、さらなるコンテキスト探索基準を指定することを可能にすることができる。
【００６１】
事前に満たされた探索ダイアログページを使用して、加入者は、自身のコンテキスト探索用のワード又はフレーズを入力する。システムは、定義されたコンテキスト（コンテンツタイプ）内で探索を開始することによって、このコンテキスト探索をハンドリングする。
【００６２】
コンテキストによる探索と同様に、加入者は、別個の「コンテンツチャネル」（ニュース放送フィード又はチャート音楽／ビデオコンテンツチャネル等）内で探索することができる。加入者は、サードパーティがブローカ業務を行うパートナページからチャネル探索オプションを選択する。システムは、加入者がチャネル探索基準を指定することを可能にし、事前に満たされた探索ダイアログページを返す。探索ダイアログページは、この場合、選択された所定のチャネルで事前に満たされている。この場合も、加入者は、事前に満たされた探索ダイアログページを使用してチャネル探索のワード又はフレーズを入力し、システムは、加入者の選択されたチャネル内で対応する探索を開始することによって、このダイアログページにおける探索用語の入力に応答する。
【００６３】
サービスＩＤ情報は、探索タスクの結果をさらに精緻化するのに使用することができる。多くの場合、探索タスクの生の結果はサービスＩＤ情報を含む。サービスＩＤ情報が探索エンジンによって返されたコンテンツアイテムに存在する場合、システムは、価格設定データ等のサービス関連情報の要求を、図示しない適切なサービスアプリケーション（料金請求／価格設定アプリケーション）へ送信することができる。この要求は、コンテンツアイテムのサービスＩＤ情報を含むように構成される。システムは、対応する応答をサービスアプリケーションから受信する。次に、システムによって表示される情報を、探索結果のコンテンツアイテムに対応するサービス関連情報を反映するように合わせることができる。したがって、コンテンツアイテムが加入を必要とする場合には、コンテンツアイテムへのリンクを選択することによって、実際のコンテンツへの直接リンクの代わりにコンテンツ加入要求ページが得られる。
【００６４】
システムは、入力された探索基準が無効であると判断すると、適したエラーメッセージを返すように構成することができる。
さらに、システムは、探索エンジンから「結果が見つからない」との応答を受信すると、結果が見つからなかったことを加入者に知らせるメッセージを表示するように構成することができる。空の結果の原因はスペルミスの場合がある。加えて、「結果無し」の応答の発生は、更新ハンドリングメカニズムのトリガとすることができる。「結果無し」の応答が受信されるたびに、このメカニズムは、要求のコンテキストをチェックすることができ、或る状況において（たとえば、加入者によって使用されているデバイス又はファームウェアが認識されていない）、更新チェックを提案又はトリガすることができる。その結果、このような「結果無し」の応答の発生を低減することができる。
【００６５】
好都合に、システムにはスペリングエンジンを提供することができ、その結果、「結果が見つからない」との応答が代替的なスペリングを含む場合に、システムは、探索ハイパーリンクとして表示される代替的なスペリングを有する代替的なスペリングメッセージを表示する。
【００６６】
スペリングエンジンは、結果が見つかったときも同様に良好に使用することができる。システムは、代替的なスペリングが見つかったことを加入者に知らせるメッセージを表示することができ、代替的なスペリングは探索ハイパーリンクとして表示することができる。さらに、モバイルハンドセットを使用して正確なテキストを入力することの困難さを考慮して、ユーザは、自身がタイプした探索基準を検証するように、スペリングエンジンのアプリケーションに積極的に要求することができる。
【００６７】
探索エンジンの応答が、所定のタイムアウト期間内に受信されない場合、システムは、通信障害イベントをログ記録し、エラーメッセージを表示する。
探索エンジンが利用不能であると判断された場合も、同様の結果となる。この場合も、システムは、通信障害イベントをログ記録し、適切なエラーメッセージを表示する。
【００６８】
このように、モバイル探索プラットフォームは、以下のことを考慮して、探索結果を知的にフィルタリングする。
デバイスの特徴（たとえば、フルトラック音楽対応電話）、デバイスのタイプ（たとえば、ワイドスクリーンを有するアドバンスト電話）、デバイス名、及びデバイスにインストールされたファームウェア
その時点のベアラネットワーク能力（たとえば、ネットワークがアナログであるのか、又はデジタルであるのか、ＧＰＲＳ（２．５Ｇ）であるのか、ＥＤＧＥであるのか、又は３Ｇであるのか）
ユーザプロファイル（たとえば、子供、１８＋等）
コンテンツへのユーザ加入
明らかに、製造者が主張するデバイス能力と、デバイスの検証された経験的な能力との間には、不一致が存在する場合がある。製造者の仕様を使用して、所与のデバイスが、特定のコンテンツアイテムと組にされたときに満足のいく結果を与えるか否かを判断することに優先して、経験的な能力のデータベースに焦点を当てることができる。
【００６９】
上述した知的クロール解決法は、独自のコンテンツフォーマット（出願人の場合、ボーダフォンコンテンツマークアップ言語ＶＣＭＬ）及びモバイルＲＤＦ（資源記述フレームワーク）タグ付け方式の双方を使用してモバイルコンテンツのクロールを提供する。知的クローラは、コンテンツを、デバイス固有の特徴、ネットワーク適合性、ユーザプロファイル適合性、加入、コンテンツのカテゴリー、コンテンツのランキングブースト値等のそのコンテンツのメタ情報に自動的に関連付ける。これによって、探索結果をレンダリングすることが簡単になるが、それにもかかわらず、ユーザの個人コンテキストに関連付けられるものとなる。
【図面の簡単な説明】
【００７０】
【図１】本発明によるモバイル探索プラットフォームを含む一般的なモバイルポータルのアーキテクチャを示す図である。
【図２】図１のモバイル探索プラットフォームのオペレーションをより詳細に示す図である。
【図３】クローラ機能の階層的構造を示す図である。
【図４】モバイル探索ポータルのコンテンツアセンブリエンジン（ＣＡＥ）部の一般的なＭＶＣ（モデル／ビュー／コントローラ）アーキテクチャを示す図である。
【図１】
2009523284.tif 000003
【図２】
2009523284.tif 000004
【図３】
2009523284.tif 000005
【図４】
2009523284.tif 000006
【国際調査報告】
2009523284.tif 000007
2009523284.tif 000008
2009523284.tif 000009