JP2004355291A - 検索サーバ装置及び情報提供システム - Google Patents

Abstract

【課題】携帯電話端末装置の能力に応じた適切な検索結果を提供することができ、操作性の向上に寄与する。
【解決手段】クローリング部２１はＨＴＴＰリクエスト中の拡張ヘッダを適宜変化させて情報提供サーバ１０Ａ，１０Ｂが提供する曲データのクローリングを行ってＤＢ２２に登録する。携帯電話端末装置４０から検索条件及び当該携帯電話端末装置４０の能力を示す情報が提供されると、検索サービス提供部２４は、検索条件及び能力を示す情報に応じた曲データについての検索結果を提供する。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、携帯電話端末装置の能力に応じた適切な検索結果を提供する検索サーバ装置及び情報提供システムに関する。
【０００２】
【従来の技術】
着信待機時の着信音あるいは着信メロディ（所謂着信メロディ）のデータをネットワーク経由でＨＴＴＰサーバ等の情報提供サーバ装置から取得して、ユーザの好みに応じたカスタマイズが可能な携帯電話端末装置が知られている。
【０００３】
ところが、携帯電話端末装置の表示画面は、パーソナル・コンピュータ等の汎用の情報処理装置と比較して、サイズ的な制約が大きく、画素数が限られている。このため、着信メロディとして提供されるデータが増加してくると、例えばカテゴリ別，アーティスト別，曲別等といったように、どうしても段階的に選択を行うようにする必要が生じ、選択の手間が増えてしまう。
【０００４】
このため、インターネット等のネットワーク経由で提供されている情報検索サービスをこのようなデータの検索に使うことが考えられる。
【０００５】
インターネット等のネットワーク経由で提供されている情報検索サービスでは、予め、検索ロボットと言われるクローリング処理部によって、ＨＴＴＰサーバのアドレスを走査し、得られたデータ中のキーワードを検索し、キーワードが存在するアドレスを、キーワード毎にデータベースに登録しておく。
【０００６】
このクローリング処理とは非同期に、ユーザが操作する端末装置からキーワードが入力されると、検索部がデータベース中からキーワードに該当するアドレスを検索し、これらのアドレスを含む検索結果を生成して端末装置に提供する（例えば特許文献１及び非特許文献１参照。）。
【０００７】
【特許文献１】
特開２０００−７６２６４号（第６−７頁、第１図、第２図）
【非特許文献１】
ＳＥＯ ＪＡＰＡＮ、“検索エンジンって何？”、２００３年、［ｏｎｌｉｎｅ］、ＳＥＯ ＪＰＡＮ、［平成１５年５月２７日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｓｅｏｊａｐａｎ．ｊｐ／ｓｅａｒｃｈ−ｅｎｇｉｎｅｓ／ｓｅａｒｃｈ−ｅｎｇｉｎｅ．ｈｔｍｌ＞
【０００８】
【発明が解決しようとする課題】
ところで、携帯電話端末装置の音声表示能力は、例えばある端末では着信メロディの同時発声数が４であり、他の端末では１６であるといったように、装置のコスト，設計方針等に応じて異なる場合がある。
【０００９】
上述のような従来のネットワークで提供されている情報検索サービスでは、端末の音声表示能力は考慮されておらず、着信メロディ向けの検索サービスとしてそのまま適用しただけでは、キーワードに合致した着信メロディのデータのアドレスを、携帯電話端末装置で再生できるか否かに関わらず提供してしまう。このため、例えばユーザが検索結果中のデータが自分の携帯電話端末装置で再生可能か逐一確認する必要がある。
【００１０】
また、画像データの取得あるいはＷｅｂページの検索等においても、従来の情報検索サービスでは、携帯電話端末装置の表示能力を考慮していないため、検索結果中のデータが表示可能か否かは、実際にデータを取得するまで解らない。
【００１１】
このため、ユーザには無駄な操作負担をかけてしまい、ネットワークに無用なトラフィックによる負荷をかける一因になっていた。
【００１２】
本発明は、上述のような課題に鑑みてなされたものであり、端末装置の能力に応じた適切な検索結果を提供することができ、操作性の向上に寄与することができる検索サーバ装置及び情報提供システムを提供することを目的とする。
【００１３】
【課題を解決するための手段】
上述の問題を解決するために、本発明に係る検索サーバ装置は、情報要求命令中のアドレス情報とデータの形式に対応する情報（形式情報）に応じたデータを提供し得る提供サーバ装置が提供するデータについての検索サービスを提供する検索サーバ装置であって、形式情報を変化させて提供サーバ装置からのデータの有無を確認するクローリング手段と、提供サーバ装置が提供し得るデータのアドレスと形式情報とを対応付けて保持する保持手段と、端末装置から供給される検索条件と当該端末装置の能力に応じた形式情報に対応するデータのアドレスを保持手段から抽出する抽出手段と、抽出手段が抽出したアドレスを含む検索結果を端末装置に提供する提供手段とを備えることを特徴とする。
【００１４】
また、本発明に係る情報提供システムは、情報要求命令中のアドレス情報とデータの形式に対応する情報（形式情報）に応じたデータを提供し得る提供サーバ装置と、提供サーバ装置が提供するデータについての検索サービスを提供する検索サーバ装置とを有する情報提供システムであって、検索サーバ装置が、形式情報を変化させて提供サーバ装置からのデータの有無を確認するクローリング手段と，提供サーバ装置が提供し得るデータのアドレスと形式情報とを対応付けて保持する保持手段と，端末装置から供給される検索条件と当該端末装置の能力に応じた形式情報に対応するデータのアドレスを保持手段から抽出する抽出手段と，抽出手段が抽出したアドレスを含む検索結果を端末装置に提供する提供手段とを備えることを特徴とする。
【００１５】
【発明の実施の形態】
本発明は、例えば移動体通信網を介して携帯電話端末装置に着信メロディＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）サービス，検索サービス等のサービスを提供する情報提供システムに適用することができる。
【００１６】
（構成）
本発明の一実施形態に係る情報提供システムは、例えば図１に示すように、インターネット等のネットワーク１経由で着信メロディ等の音声データ，待受画面等の画像データ等の提供を行う情報提供サーバ群１００と、情報提供サーバ群１００が提供するデータに関する検索サービスを提供する検索サーバ２０と、この検索サーバ２０が提供するサービスを移動体通信網３０経由で利用する携帯電話端末装置４０とを備えている。
【００１７】
情報提供サーバ群１００は、例えば複数の情報提供サーバ１０Ａ，１０Ｂ，…から構成されている。各情報提供サーバ１０Ａ（１０Ｂ）は、当該情報提供サーバが提供する情報を格納する情報格納部１１と、情報格納部１１に格納されている情報をネットワーク１経由で提供するＨＴＴＰサーバ１２とを備えている。情報提供サーバ１０Ａ，１０Ｂが提供する情報は音声データに限られるものではないが、説明の便宜上、以下、いわゆる着信メロディの曲データを例に説明する。情報格納部１１には、例えば着信メロディの曲データ等の情報を曲毎に格納する曲データ格納領域１１ａ，１１ｂ，…が設けられている。各曲データ格納領域１１ａ，１１ｂ，…には、同一の曲に対して携帯電話端末装置４０の再生能力に対応する１つないし複数のデータ形式の曲データが格納されている。例えば図１中の情報提供サーバ１０Ａの曲データ格納領域１１ａには、曲ＡＡＡに対応する６４音，１６音，４音（これらの数は同時発生数を示している。）の曲データが格納されている状態を示している。
【００１８】
ＨＴＴＰサーバ１２に対するアクセス要求中には、例えばＨＴＴＰリクエスト中の拡張ヘッダとして、携帯電話端末装置４０の音声表示能力を示す情報（例えば“ｓｏｕｎｄｓ：＃＃”［＃＃は音声表示能力を示す数字］）が含まれており、ＨＴＴＰサーバ１２は、この情報に応じて、携帯電話端末装置４０等から要求された曲データ等のデータ形式を認識することができるようになっている。
【００１９】
検索サーバ２０は、情報提供サーバ群１０が提供するデータのアドレス，データ種別を取得するクローリング部２１と、クローリング部２１によって得られたアドレス，データ種別を管理するデータベース（ＤＢ）２２と、携帯電話端末装置４０の仕様を保持する端末能力保持部２３と、携帯電話端末装置４０からの要求に応じてＤＢ２２から条件に該当するデータのアドレス等を提供する検索サービス提供部２４とを備えている。
【００２０】
移動体通信網３０は、携帯電話端末装置４０との間の通信チャネルの割り当て等の処理を行う回線交換機３１と、データ通信用のパケットの交換等の処理を行うパケット交換機３２と、携帯電話端末装置４０との間で無線通信を行う基地局装置（ＢＳ：Ｂａｓｅ Ｓｔａｔｉｏｎ）３３ａ，３３ｂ，…，３３ｎと、ＢＳ３３ａ〜３３ｎの管理を行うＢＳＣ３４とを備えている。
【００２１】
携帯電話端末装置４０は、移動体通信網３０を介して通話サービス，メールサービス等を利用できる他、情報提供サーバ１１，１２が提供するデータ提供サービス及び検索サーバ２０が提供する検索サービスを利用することができるようになっている。この携帯電話端末装置４０は、高周波信号の処理を行う高周波（ＲＦ：Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）部４１と、ＭＰＵ４２と、メモリ４３と、ユーザからの指示等を入力する操作キー４４と、ユーザに対する表示を行う表示部４５と、音声信号の符号化／復号化を行う音声ＣＯＤＥＣ４６と、ＭＩＣ４７と、スピーカ４８とを備えている。
【００２２】
ＭＰＵ４２は、例えばメモリ４３に保持されている制御プログラムを実行することにより、移動体通信網３０を介した通信の制御を行う通信制御部５０，電子メールの送受信を行う電子メールクライアント６０，上述の情報提供サービス及び検索サービスの利用時の表示等を表示するＷｅｂブラウザ７０として機能する。また、メモリ４３内には、着信メロディ等の音声データを保持する音声データ保持部４３ａと、待ち受け画面等の画像データを保持する画像データ保持部４３ｂとが設けられている。
【００２３】
上述の情報提供サーバ１０Ａ，１０Ｂ，…のＨＴＴＰサーバ１２は、例えば図２に示すように、ネットワーク１経由で供給された携帯電話端末装置４０等からの要求を解析する要求解析部１２ａと、提供する情報を示すアドレスを有するインデックスデータを保持するインデックス保持部１２ｂと、要求解析部１２ａからの指示に応じて情報格納部１１から情報を取得するコンテンツ取得部１２ｃと、コンテンツ取得部１２ｃが取得した情報から携帯電話端末装置４０等に対する応答をネットワーク１経由で送出する応答部１２ｄとを備えている。
【００２４】
インデックス保持部１２ｂに保持されているインデックスデータは、例えば図３に示すように、情報（例えば曲データ）の選択を階層的に行い得るように、階層的に分類されて構成されている。このインデックスデータは、例えばＨＴＭＬ形式，ＸＭＬ形式等のページ記述データで構成されており、例えば上位のインデックスのページ記述データ中に下位のインデックスのアドレス（ＵＲＬ等）を示すリンクを記述することによって、階層的的なリンク構造が形成されるように構成されている。
【００２５】
このような階層構成のインデックスにより、ユーザは、まず、例えば総合インデックスからカテゴリを選択し、次にカテゴリ別のインデックスからアーティストを選択し、アーティスト別のインデックスから曲を選択することによって、階層的に曲データの選択を行うことができるようになっている。
【００２６】
ところで、カテゴリ，アーティスト，曲データ等の数が増えてくると、各階層のインデックス中の選択肢が増加してしまう。この結果、各階層のインデックス中の項目が増加し、例えばユーザがスクロールして全体を確認するといった必要が生じ、目的の曲を探すまでの手間が増加してしまう。このため、例えば階層構造を細分化することも考えられるが、階層の選択回数が増えてしまうので、ユーザの手間はあまり減少しない。
【００２７】
このため、この情報提供システムでは、検索サーバ２０によって、情報提供サーバ１０Ａ，１０Ｂ，…が提供する情報についての検索サービスを提供している。さらに、この情報提供サービスでは、携帯電話端末装置４０の能力に応じた適切な検索結果を提供できるようになっている。
【００２８】
（クローリング動作）
クローリング部２１は、例えばＨＴＴＰサーバ１２が提供しているインデックスデータのリンク構造を辿って、ＨＴＴＰサーバ１２が提供する情報（この場合は曲データ）のアドレス（ＵＲＬ）を取得する。曲データ格納領域１１ａ内に格納されている個々の曲データは、例えば図４に示すように、ヘッダ部２０１と、データ部（楽曲データ）２０２とから構成されており、ヘッダ部２０１内には、曲名とアーティスト名等が格納されている。クローリング部２１は、ヘッダ部２０１内の曲名，アーティスト名等を、当該曲データのアドレスに対応させてＤＢ２２に格納する。
【００２９】
また、クローリング部２１は、例えば図５に示すように、取得した曲データのアドレスに対して、端末能力保持部２３に保持されている端末の能力を示す拡張ヘッダ中の情報を適宜変更してアクセスを繰り返し（Ｓ１０１，Ｓ１０３，Ｓ１０５，Ｓ１０７）、各拡張ヘッダに対応する応答から当該アドレスの曲データの種類を特定し、ＤＢ２２に登録する。
【００３０】
具体的には、個々の曲データ格納領域に格納されている曲データは、例えば６４音の曲データのファイル名の末尾が「６４」，３２音の曲データのファイル名の末尾が「３２」，１６音の曲データのファイル名の末尾が「１６」，４音の曲データのファイル名の末尾が「４」といったように、データ形式に応じたファイル名で管理されている。
【００３１】
要求解析部１２ａは、クローリング部２１から供給されたＨＴＴＰリクエスト中のアドレス（ファイル名）から当該アドレスに対応する曲データ格納領域１１ａを選択し、選択した曲データ格納領域１１ａにＨＴＴＰリクエスト中の拡張ヘッダ中の情報に対応するファイル名の末尾を有する曲データの読み出しを指示する。拡張ヘッダに対応する曲データが格納されている場合には、曲データがコンテンツ取得部１２ｃに読み出されるため、応答部１２ｄは、ＨＴＴＰリクエストが成功した旨を示す応答メッセージ（ＨＴＴＰ／１．１ ２００ ＯＫ）と読み出された曲データとをクローリング部２１に送信する（Ｓ１０２，Ｓ１０４，Ｓ１０８）。拡張ヘッダに対応する曲データが曲データ格納領域１１ａに格納されていない場合には、コンテンツ取得部１２ｃに対する読み出しは行われず、応答部１２ｄは、ＨＴＴＰリクエストが失敗した旨を示す応答メッセージ（ＨＴＴＰ／１．１ ４０４ Ｎｏｔ Ｆｏｕｎｄ）をクローリング部２１に送信する（Ｓ１０６）。
【００３２】
クローリング部２１は、上述のように、得られた曲データ中のアーティスト名，曲名を抽出し、例えば図６に示すように、アーティスト，曲名と、上述の拡張ヘッダに対応する端末属性（音数）及びアドレスとを関連付けてＤＢ２２に記録する。これにより、ＤＢ２２には、例えば図６に示すように、ＨＴＴＰリクエストが成功した際の拡張ヘッダに対応する曲データは追加されるが、ＨＴＴＰリクエストが失敗した際の拡張ヘッダに対応する記録は追加されない。なお、この図６は、図１中の曲データ格納領域１１ａに対してクローリングを行った際のＤＢ２２の状態を示しており、曲データ格納領域１１ａに格納されている曲ＡＡＡの６４音，１６音，４音の曲データについては端末属性及び曲データ格納領域１１ａのアドレスが追加されているが、曲データ格納領域１１ａには３２音の曲データは存在しないため、３２音の曲データについての端末属性及びアドレスは追加されていない状態を示している。
【００３３】
（検索サービス）
上述のようなクローリング動作と非同期に、検索サービス提供部２４は、携帯電話端末装置４０のＷｅｂブラウザ７０等に対して検索サービスを提供している。
【００３４】
ユーザから検索サービスの利用が指示されると、Ｗｅｂブラウザ７０は、検索サービス提供部２４に対して、検索条件の入力用のデータを要求する。これに応じて、検索サービス提供部２４から例えばＨＴＴＰ形式のデータが供給されると、Ｗｅｂブラウザ７０は、例えば図７に示すように、検索語入力画面を表示部４５の表示画面に表示させる。ユーザが、検索条件（例えばアーティスト名「ＡＡ」）を入力して検索を指示すると、Ｗｅｂブラウザ７０は、検索サービス提供部２４に検索条件を示す文字と当該携帯電話端末装置４０の音声表示能力に対応した情報を含む拡張ヘッダを含むＨＴＴＰリクエストを送信する（Ｓ２０１）。この例は、携帯電話端末装置４０の音声表示能力が３２音である場合（ｓｏｕｎｄｓ：３２）について示している。
【００３５】
検索サービス提供部２４は、例えばＨＴＴＰサーバから構成されており、Ｗｅｂブラウザ７０から供給されたＨＴＴＰリクエスト中の検索条件を示す文字と拡張ヘッダに対応する曲データに対応する情報をＤＢ２２から取得し、取得したデータ中のアドレスに対するリンク情報，曲名（ＡＡＢ，ＡＡＣ），アーティスト名（ＡＡ）を含む応答メッセージ（検索結果）を生成し、Ｗｅｂブラウザ７０宛てに送信する（Ｓ２０２）。この検索結果は、例えばＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で構成されており、Ｗｅｂブラウザ７０は検索結果に応じた検索結果一覧画面を表示する。上述の図１及び図２に示す例では、曲データ格納領域１１ａに携帯電話端末装置４０の音声表示能力（３２音）に対応する曲ＡＡＡの曲データがなく、図６に示すように、ＤＢ２２には曲ＡＡＡに対応する３２音の曲データについての情報が含まれていない。このため、検索サービス提供部２４が提供する検索結果には図７に示すように、曲ＡＡＡが含まれていない状態になる。
【００３６】
ところで、音声表示能力が６４音の携帯電話端末装置４０から、同様にアーティスト名「ＡＡ」を検索条件として、検索を要求した場合には、例えば図８に示すように、検索サービス提供部２４に供給するＨＴＴＰリクエスト中の拡張ヘッダに携帯電話端末装置４０の音声表示能力が６４音であることを示す情報（ｓｏｕｎｄｓ：６４）が含まれている（Ｓ３０１）。上述の図１及び図２に示す例では、曲データ格納領域１１ａに曲ＡＡＡに対応する６４音の曲データがあるため、図６に示すように、ＤＢ２２に曲ＡＡＡに対応する６４音の曲データについての情報が登録されている。このため、検索サービス提供部２４が提供する検索結果には図８に示すように、曲ＡＡＡが含まれている状態になる（Ｓ３０２）。
【００３７】
このような検索結果を確認したユーザが曲を選択すると、Ｗｅｂブラウザ７０は、選択された曲に対応するリンク情報に応じて、対応する情報提供サーバ１０Ａにユーザが選択した曲に対応する曲データの提供を要求する（Ｓ３０３）。この要求（ＨＴＴＰリクエスト）には、拡張ヘッダに携帯電話端末装置４０の音声表示能力が６４音であることを示す情報（ｓｏｕｎｄｓ：６４）が含まれており、情報提供サーバ１０ＡのＨＴＴＰサーバ１２は対応する６４音の曲データを携帯電話端末装置４０に供給する（Ｓ３０４）。
【００３８】
（効果）
携帯電話端末装置の能力を考慮しない場合には、検索結果に当該携帯電話端末装置で利用できない情報が含まれてしまい、ユーザが逐一リンクを辿って利用可能か判断する必要がある。
【００３９】
この情報提供システムでは、上述のように、検索サービス提供部２４が、携帯電話端末装置４０の音声表示能力に対応する曲データのみを検索結果として供給することができるため、携帯電話端末装置４０で再生できる曲データを取得するまでのユーザの操作回数を低減させることができる。これにより、検索結果に応じた無駄な操作の発生を低減させて、操作性の向上に寄与することができる。
【００４０】
また、携帯電話端末装置で利用できない曲データにアクセスする可能性を低減させることができるため、無用なトラフィックの低減，通信料金の節約に寄与することができる。
【００４１】
（変形例）
上述の実施形態では、情報提供サーバ１０Ａ，１０Ｂ，…が着信メロディの曲データを提供する場合について説明したが、情報提供サーバ１０Ａ，１０Ｂ，…が提供する情報はこれに限定されるものではなく、例えば画像データ，スクリプト言語で記述されたプログラム等でもよい。
【００４２】
画像データである場合、携帯電話端末装置４０が拡張ヘッダ中で指定する情報は、例えば表示部４５の画面サイズ・表示可能色数あるいはカメラ機能有無・メモリカード機能有無・受信可能ファイル種別・受信可能ファイルサイズ・受信データ圧縮可否・国情報等等とすることができる。また、プログラムである場合には、プログラムの実行環境の有無，実行環境のバージョン，メモリ容量等の情報を拡張ヘッダ中で指定することができる。
【００４３】
また、上述の着信メロディの曲データのフォーマットは、上述の例に限定されるものではなく、例えば音源に依存した形式であってもよく、この場合は、拡張ヘッダ中で、携帯電話端末装置４０に搭載されている音源の種別を示す情報，同時発声数等の情報を指定することができる。
【００４４】
情報提供サーバ１０Ａ，１０Ｂはこれらの拡張ヘッダ中で指定される情報に対応する形式の画像データ，プログラム等を提供し得るように構成しておき、クローリング部２１が拡張ヘッダ中の情報を適宜変化させながらクローリングを行なうように構成すれば、上述と同様の作用効果を得ることができる。
【００４５】
例えばＨＴＴＰサーバ１２に画像データを要求する場合は、ＨＴＴＰリクエスト中の拡張ヘッダとして携帯電話端末の画像表示能力を示す情報（例えば“ｄｉｓｐｌａｙ＿ｓｉｚｅ：＃＃＃＃［＃＃＃＃は表示部４５の表示領域の画素数を示す文字列］”や“ｄｉｓｐｌａｙ＿ｃｏｌｏｒ：＃＃＃＃［＃＃＃＃は表示部４５の表示可能色数を示す数字］”）が含まれている。ＨＴＴＰサーバ１２は、拡張ヘッダ中のこれらの情報により、要求された画像データの形式を認識することができ、要求された形式に対応する応答メッセージを送信する。すなわち、要求された形式に対応する画像データが情報格納部１１に格納されている場合には、ＨＴＴＰサーバ１２はＨＴＴＰリクエストが成功した旨を示すメッセージと要求された形式の画像データを送信し、要求に対応する画像データが存在しない場合にはその旨を示す応答メッセージを送信する。
【００４６】
例えば拡張ヘッダに“ｄｉｓｐｌａｙ＿ｓｉｚｅ：２４０＊３２０”という情報が含まれていれば表示部４５の表示領域の画素数が横２４０ドット×縦３２０ドットであることを示しており、“ｄｉｓｐｌａｙ＿ｃｏｌｏｒ：４０９６”という情報が含まれていれば表示部４５の表示可能色数が４０９６色であることを示している。
【００４７】
クローリング部２１は、クローリングを行う際に、これらの拡張ヘッダ中の情報を適宜変更してアクセスを繰り返し、ＨＴＴＰサーバ１２の応答から当該ＨＴＴＰサーバ１２が提供し得る画像データの形式を、例えば当該画像中の画像データ等の文字情報等から抽出したキーワード，アドレス等に対応させてＤＢ２２に記憶する。
【００４８】
検索時には、検索サービス提供部２４は、携帯電話端末装置４０からの検索条件等を含むＨＴＴＰリクエスト中の拡張ヘッダの情報に対応する形式の画像データのアドレスをＤＢ２２から抽出して携帯電話端末装置４０に対する応答メッセージを形成し、携帯電話端末装置４０に送信する。
【００４９】
これにより、上述の着信メロディの曲データと同様に、携帯電話端末装置４０側の能力に応じた情報に対応する検索結果を供給することができる。
【００５０】
【発明の効果】
本発明では、クローリング手段が形式情報を変化させて提供サーバ装置からのデータの有無を確認し、この結果を提供サーバ装置が提供し得るデータのアドレスと形式情報とを対応付けて保持手段に保持している。端末装置から検索条件と当該端末装置の能力に応じた形式情報が供給されると、検索条件抽出手段は、検索条件と形式情報に対応するデータのアドレスを保持手段から抽出し、提供手段が、抽出されたアドレスを含む検索結果を端末装置に提供する。
【００５１】
これにより、端末装置の能力に応じたアドレスを検索結果として提供することができる。従って、端末装置の能力に応じた適切な検索結果を提供することができ、端末装置で利用できないデータのアドレスを含む検索結果に応じた無駄な操作の発生を低減させて、操作性の向上に寄与することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る情報提供システムの構成を示す図である。
【図２】前記情報提供システムを構成する情報提供サーバの詳細な構成例を示す図である。
【図３】前記情報提供サーバのインデックス保持部に保持されているインデックスデータの構造例を示す図である。
【図４】前記情報提供サーバが提供する情報のフォーマットの例を示す図である。
【図５】前記情報提供システムを構成する検索サーバのクローリング部によるクローリング動作の例を示すシーケンス図である。
【図６】前記クローリング動作によってＤＢに格納されるコンテンツテーブルの例を示す図である。
【図７】前記検索サーバによる検索サービスにおける動作の例を示すシーケンス図である。
【図８】前記検索サービスにおける動作の例を示すシーケンス図である。
【符号の説明】
１…ネットワーク、１００…情報提供サーバ群、１０Ａ，１０Ｂ…情報提供サーバ、１１…情報格納部、１１ａ，１１ｂ…曲データ格納領域、１２…ＨＴＴＰサーバ、１２ａ…要求解析部、１２ｂ…インデックス保持部、１２ｃ…コンテンツ取得部、１２ｄ…応答部、２０…検索サーバ、２１…クローリング部、２２…ＤＢ、２３…端末能力保持部、２４…検索サービス提供部、３０…移動体通信網、４０…携帯電話端末装置、７０…Ｗｅｂブラウザ

Claims (2)

1. 情報要求命令中のアドレス情報とデータの形式に対応する情報（形式情報）に応じたデータを提供し得る提供サーバ装置が提供するデータについての検索サービスを提供する検索サーバ装置であって、
   前記形式情報を変化させて提供サーバ装置からのデータの有無を確認するクローリング手段と、
   前記提供サーバ装置が提供し得るデータのアドレスと前記形式情報とを対応付けて保持する保持手段と、
   端末装置から供給される検索条件と当該端末装置の能力に応じた形式情報に対応するデータのアドレスを前記保持手段から抽出する抽出手段と、
   該抽出手段が抽出したアドレスを含む検索結果を前記端末装置に提供する提供手段と
   を備えることを特徴とする検索サーバ装置。
2. 情報要求命令中のアドレス情報とデータの形式に対応する情報（形式情報）に応じたデータを提供し得る提供サーバ装置と、
   該提供サーバ装置が提供するデータについての検索サービスを提供する検索サーバ装置とを有する情報提供システムであって、
   前記検索サーバ装置が、
   前記形式情報を変化させて提供サーバ装置からのデータの有無を確認するクローリング手段と、
   前記提供サーバ装置が提供し得るデータのアドレスと前記形式情報とを対応付けて保持する保持手段と、
   端末装置から供給される検索条件と当該端末装置の能力に応じた形式情報に対応するデータのアドレスを前記保持手段から抽出する抽出手段と、
   該抽出手段が抽出したアドレスを含む検索結果を前記端末装置に提供する提供手段と
   を備えることを特徴とする情報提供システム。

Images