リアルタイム集約検索の方法及びプログラム
【課題】
インターネットで商品やレストラン、旅行情報などを検索する際、利用者がよりよい情報を取得するためには、複数の検索サイトやWebサービスにそれぞれアクセスし、それぞれのサイト上で目的とする情報を得るためのカテゴリやキーワードを指定することで、検索結果を収集、比較する必要がある。
【解決手段】
利用者からのリクエストを受信した検索処理サーバは、利用者からのリクエスト情報に関連した、商品や飲食店などの特定のジャンル情報を返す、複数のレスポンスサーバのそれぞれに、該リクエストを送り、該レスポンスサーバからのレスポンスを受信したのちに、これらの情報に対してマージやソートなどの処理を施し、ユーザに返す。
インターネットで商品やレストラン、旅行情報などを検索する際、利用者がよりよい情報を取得するためには、複数の検索サイトやWebサービスにそれぞれアクセスし、それぞれのサイト上で目的とする情報を得るためのカテゴリやキーワードを指定することで、検索結果を収集、比較する必要がある。
【解決手段】
利用者からのリクエストを受信した検索処理サーバは、利用者からのリクエスト情報に関連した、商品や飲食店などの特定のジャンル情報を返す、複数のレスポンスサーバのそれぞれに、該リクエストを送り、該レスポンスサーバからのレスポンスを受信したのちに、これらの情報に対してマージやソートなどの処理を施し、ユーザに返す。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットの利用に関し、特にウェブサイトを検索する技術やその為のコンピュータプログラムに関するものである。
【背景技術】
【０００２】
近年インターネットの普及に伴い、膨大な情報がインターネットを介して入手可能となっている。そのような膨大な情報の中から利用者が目的の情報を収集する手段として、一般的に認知されているのがポータルを代表とした検索サイトや検索エンジンである。
【０００３】
また、各々のジャンルや分類に特化した情報検索、例えばインターネット上の仮想店舗で販売されている商品を、利用者がクライアント端末を操作して購入できるオンラインショッピングや、商品の価格や評価といったレビュー、格付けを提供する情報サイトも実現化されている。
その他、複数のオンラインショップで取り扱われている多彩な商品を、統括して管理・販売するショッピングモール的なサービスも提供されており、また、同じように同種・同系のサービスを提供するショッピングモールも複数存在している。
【０００４】
それ以外でも、地域情報を取得するための地図検索サイトや飲食店情報提供サイトといった、さまざまなジャンルの情報を扱うWebサイトが開設されてきており、同一のジャンルの情報を扱うWebサイトも複数存在している。
【０００５】
一方、近年インターネット上ではオープンソースの普及に伴い、多くのサイトがWebAPIを公開し始めている。企業や個人がインターネット上で新しいWebサイトやサービスを提供する際、全ての機能を自前で開発するのではなく、部分的な機能については、公開されているWebAPIの機能を取り入れ、あたかも自身のWebサイトが所有している機能であるかのようなマッシュアップと呼ばれる手法を用いてWebサイトを構築する例が増えている。
【０００６】
独創性のアイデアにより生み出したマッシュアップの技法を競い合う、Webサイト構築のコンテストもここ数年開催されている（例えば、非特許文献１）。また、広報テキスト検索（非特許文献２）でマッシュアップについて検索すると、様々なマッシュアップを利用した技術が既に公開されている。
【非特許文献１】"MA6 (MASHUP AWARDS 6) on CREYLE"、［online］、［平成２２年８月２２日検索］、インターネット＜ＵＲＬ：http://mashupaward.jp/ ＞
【非特許文献２】"広報テキスト検索"、［online］、［平成２２年８月２２日検索］、インターネット＜ＵＲＬ：http://www7.ipdl.inpit.go.jp/Tokujitu/tjkta.ipdl?N0000=108 ＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
前述のとおり、利用者がインターネット上で目的の情報を検索する際には、例えば、検索エンジンを有するWebサイトや、レストラン情報や旅行情報といった特定のジャンルに特化したWebサイト、また、様々なマッシュアップを利用して構築されたWebサイトや、それに類する機能やサービスなどの外部サーバを利用することが一般的である。
【０００８】
しかし、昨今は同種・同系の情報の検索サービスを提供するWebサイトが別々に複数存在する。例えばショッピングモールサイトでも日本国内に代表的なサイトが複数あり、利用者がリクエストしたキーワードやカテゴリに関連する検索に際し、各サイトにおける検索結果が異なることもある。このため、利用者は複数の選択肢から結果を取得して比較検討したい場合、従来の手法では同種・同系の複数の検索Webサイトにアクセスし、場合によってはブラウザ上で画面を切り替えて情報を比較、検討後、そこから更に、例えば、目的とするショッピングサイトにアクセスする必要があるため、目的とする情報に到達するまでに労力を要するということが課題である。そして、従来のマッシュアップは、複数のジャンルの異なるWebサイトからそれぞれ異なる情報を取得して組み合わせることにより、利用者のニーズに応えようとするものであり、このような課題の解決を意図しているものではない。
【０００９】
また、同種のジャンルの情報を結合、表示させるための従来の方法の一例として、情報提供元となる各サイトから情報を収集し、独自に管理するデータベースに一旦情報を蓄積し、利用者から要求があった場合に、要求があった時点で最新の蓄積した情報を提供するといった方法が考えられる。この方式では、提供元のサイトの情報に変更があった場合、独自に管理するデータベースへ反映させるためのタイムラグが発生するため、タイムラグが長くなるほど、提供元と同じ情報を提供しにくくなるというデメリットがある。
【００１０】
具体的には、ある商品検索サイトでの検索結果画面に表示された商品と、その商品情報の提供元のサイト上での商品が同一のものであるにも関わらず、各々の価格や商品概要といった情報が異なっていることがある。これは、情報提供元の商品情報がデータベースに登録された後、商品情報提供元サイトがその商品情報に変更を加えたにも関わらず、商品検索サイトのデータベースに変更が反映されなかったためである。
【００１１】
一例としては、販売サイト（情報提供元）が、ある期間限定でセール価格として「\100」で販売している商品が、利用者が検索結果画面から得た時間帯では価格がセール前の「\500」の表示だったため、検索結果としては購買候補から外れてしまうという問題が生じ、利用者側、販売サイト側の双方にとって好ましくない結果が生じるという課題がある。
【００１２】
そこで、本発明は、上記の課題を解決するために、利用者がリクエストしたキーワードやカテゴリに対して、複数のサイトからリアルタイムに検索結果を取得し、利用者の要求に従って、結合、並び替えなどの処理が施されたレスポンスを返すことにより、利用者が統合的且つ効率的に情報を収集し、比較検討することを可能とする方法、プログラム、装置を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記の目的を達成するために、本発明の方法またはプログラムは、利用者のリクエストを受信する第１の受信ステップと、前記第１のリクエストに関連した特定のジャンルの情報を返す複数のレスポンスサーバ（外部サーバ）のそれぞれに、第２のリクエストを送信する第２リクエスト送信ステップ、複数の前記レスポンスサーバのそれぞれから、前記第２のリクエストに対する応答情報を含む第２のレスポンスを受信する第２レスポンス受信ステップ、複数の前記第２のレスポンスを受信した後に複数の前記応答情報に対して特定の処理を施し、結果情報を生成する結果情報生成ステップ、前記結果情報を含む前記第１のリクエストに対応する第１のレスポンスを送信する応答ステップ、を備えることを特徴とする（請求項１）。
【００１４】
この構成によって、利用者が統合的且つ効率的に検索結果を比較検討することができる。また、リアルタイムに最新の情報の取得が可能であり、取得した検索結果にタイムラグが生ずることがない。さらに、独自の検索対象情報を格納するためのデータベースを用意する必要がなく、手動や自動のいかんに関わらず、データ収集、蓄積する仕組みを構築するプロセスが不要となるという効果がある。
【００１５】
また、前記第１のリクエストに含まれるカテゴリを特定するための識別子を、複数の前記レスポンスサーバのそれぞれに対応する識別子に変換するための対応表を備え、
前記第２リクエスト送信ステップは、前記対応表に基づいて前記第１のリクエストをそれぞれの前記レスポンスサーバに対応する、前記第２のリクエストに変換した後に、リアルタイムに送信することを特徴とする（請求項２）。
【００１６】
各レスポンスサーバへのカテゴリを指定することで、各レスポンスサーバ内でカテゴリ分類されたものを取得することができるため、意図しない情報が検索結果に含まれることを回避し、利用者にとっても信頼性の高い情報を取得することができる。
【発明の効果】
【００１７】
本発明によれば、利用者が指定したキーワードやカテゴリを、複数の外部サーバのそれぞれの形式や内容に変換して複数Webサイトに一斉にHTTPリクエストを送り、それぞれのリアルタイムな検索結果をXMLレスポンスとして得、それらを統合、再配置して利用者に提示することにより、利用者が統合的且つ効率的に検索結果を比較検討することが可能になり、1回の操作で複数のサイトを検索した場合より、円滑且つ利便性の高い結果が得られることが期待できる。
【００１８】
また、利用者にとってタイムラグのなく、信頼性の高い情報を取得することができる。さらに、運用者にとっても、検索情報を格納するためのデータベースなどの高価な設備を必要とせず、また、データベースの更新といったメンテナンスが不要であり、運用コストの低いシステムが構築できる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施例における全体の構成概要を示す図。
【図２】実施例における、検索処理サーバのTOPページを示す図。
【図３】実施例における、利用者が商品検索を実施する際のイメージを示す図。
【図４】実施例における、利用者からのリクエストよりHTTPリクエストを送信する構成概要を示す図。
【図５】実施例における、キーワードを各WebAPIに含めて送るサンプルを示す図。
【図６】実施例における、該外部サーバからのレスポンスのサンプルを示す図。
【図７】実施例における、キーワードによる商品検索結果画面を示す図。
【図８】実施例における、TOPページからジャンル検索に遷移する手順を示す図。
【図９】実施例における、カテゴリによる商品検索結果画面を示す図。
【図１０】実施例における、ID情報を各外部サーバに対応する値に変換するカテゴリ変換表を示す図。
【図１１】実施例における、各外部サーバに対応したリクエストURLを作成している事を示す図。
【発明を実施するための形態】
【００２０】
本発明は、前述したWebAPIと呼ばれる技術やマッシュアップと呼ばれる手法によって成り立つものである。以下に、本発明の実施例について図面を参照して説明する。ただし、この実施の形態に記載されている内容はあくまでも例示であり、この発明の範囲をそれらのみに限定する趣旨のものではない。
【００２１】
本発明において、商品やレストラン情報などを検索しようとする利用者は、検索処理サーバから提供されたTOP画面を介して、検索対象に関する特定条件を含む検索リクエストを検索処理サーバに対して送る。検索処理サーバは、受信した検索リクエストを解析し、WebAPIの送信先である外部サーバのそれぞれに対し、該外部サーバが提供するWebAPIに応じた形式に該検索リクエストを変換し、複数の外部サーバにそれぞれ送信する。各外部サーバは、受信した上記の変換後の検索リクエストを処理して、検索処理サーバにレスポンスを送り、検索処理サーバは複数のレスポンスを受信して解析し、その結果を利用者に送信する。
【００２２】
上記の特定条件は、ジャンル、カテゴリ、キーワードなど、利用者が複数の外部サーバからの結果を比較し、検討したいと考える所望の条件である。また、TOP画面は少なくとも検索キーワードを入力するためのテキストボックスや、リクエストを送信するトリガーとなる実行ボタンやリンクを有することが好ましい。以下に、具体的な例を挙げて、本発明における処理の流れを説明する。
【実施例】
【００２３】
（実施例１）
ここでは例として、利用者がインターネットショッピングによって商品を購入する際に、購入を希望する商品を検索するまでの流れを説明する。商品は、具体的な例としてここでは、“はさみ”とする。
【００２４】
“はさみ”を購入したい利用者は、まずは、PCのWebブラウザを操作して、検索処理サーバにアクセスすると、検索処理サーバは例えば図２のようなTOP画面を利用者のWebブラウザに提供する。（図2参照）
【００２５】
次に、利用者は、TOP画面上のテキストボックスに、キーボードやタッチパネルなどの入力手段を用いてキーワードを“はさみ”と入力し、商品検索ボタンをクリックする（図3参照）。該クリックを契機として、Webブラウザは指定されたキーワードを含むHTTPリクエストを検索処理サーバに送信する。
【００２６】
検索処理サーバは、上記のHTTPリクエストを受信すると、検索処理サーバに登録されている各外部サーバに対してHTTPリクエストを送るために該リクエストを解析し、各外部サーバが提供するWebAPIを用いて、個別にHTTPリクエストを送信する(図4参照)。本例においては、検索処理サーバは、外部サーバY、外部サーバR、外部サーバAの３つが登録されているため、キーワード“はさみ”を各WebAPIに含めて送ることになる。（図5参照）
【００２７】
なお、検索処理サーバが複数の外部サーバに個別のリクエストを送るにあたっては、各外部サーバに順次送っても良い。あるいは、マルチスレッドなどの並列処理により一斉に送っても良く、この場合には、全ての外部サーバからの情報を得る時間を短縮することができるという効果がある。また、何らかの原因により外部サーバからの応答が得られず、HTTPリクエストのタイムアウト時間を待つようなことになっても、順次に送るよりも実行時間を短縮できる。
【００２８】
各外部サーバは、上記の検索処理サーバから送られた個別リクエストを受信すると、自己が備える検索エンジンを用いて受信したHTTPリクエスト内の“はさみ”を用いて商品の情報を検索し、その検索結果として値段を含む情報を、その要求元である検索処理サーバに対してXMLレスポンスを送る。（図6参照）
【００２９】
検索処理サーバは、これらの複数のレスポンスを全て受信すると、これらのレスポンス情報を解析し、それらの全ての情報を、例えば値段が安い順、高い順、人気の高い順、各サイトが提供するおすすめ順、といった利用者が希望する条件でソートして結果情報を作成し、利用者に該結果情報を含むレスポンスを送る。なお、全て受信してから解析を始めても良いし、各外部サーバから受信する度に処理を開始しても良い。（図7参照）
【００３０】
これによって、利用者は、結果情報を見て、複数サイトで得られる情報を一括で取得し、それらを容易に見比べることができる。
【００３１】
（実施例２）
上記のはさみを購入する例においては、利用者はTOP画面上でキーワードを指定する例を記載したが、キーワードを指定する代わりに、商品のカテゴリを指定しても良い。
【００３２】
カテゴリを指定することのメリットは、キーワード検索の時より、より信頼性の高い検索結果を得られるためである。キーワードのみによる検索を行う場合は、商品名や商品説明などに含まれる文言から、部分一致で取得されるため、余分な情報まで紛れ込む可能性が高くなる。具体的な例として、キーワードとして「はさみ」を指定した場合、検索結果に例えば「はさみ焼き」という単語が商品情報に含まれている商品も検索結果に含まれることになる。この場合、利用者は「はさみ」のみを検索結果として望んでいるのに対して、余分な情報まで紛れ込んでしまうことになる。カテゴリを指定することで、余分な情報が紛れ込むのを防ぐことができる。
【００３３】
このカテゴリとは、検索処理サーバが予め分類しているものであり、検索処理サーバが利用者のアクセスに応じて表示されるTOP画面上に配置されたボタンあるいはリンクなどをクリックすることで商品検索画面へ遷移する（図8参照）。
【００３４】
商品検索画面にはカテゴリが記載されており、そこで利用者は“はさみ”を検索する方法として、ここでは“事務用品”->“卓上アクセサリ”->“はさみ”の順番でカテゴリをクリックして画面を遷移させていく。（図9参照）
【００３５】
この“はさみ”の検索のための画面の遷移に伴う、カテゴリをクリックする一連の操作を契機に、利用者のWebブラウザが解釈し、上記と同様にカテゴリ情報を含むHTTPリクエストを検索処理サーバに送ることになる。
【００３６】
ここで、HTTPリクエストには、カテゴリに対応するID情報が含まれている。そして、検索処理サーバは、このHTTPリクエストを受信すると、各外部サーバに対する個別HTTPリクエストに変換するにあたって、ID情報を各Webサーバに対応する値に変換する必要がある。（図10参照）
【００３７】
これは、外部サーバの運用元はそれぞれ独自に情報をカテゴライズしており、外部サーバ間で統一されたものではないためである。すなわち、図10に例示するように、”はさみ“という商品カテゴリは、外部サーバYでは（切断用品）「１１１１」であり、外部サーバRでは（ハサミ＆カッター）「２２２２」であり、外部サーバA（ハサミ）では「３３３３」であり、それぞれ異なっている。この違いのため、各外部サーバのカテゴリIDに対応した検索処理サーバにおけるユニークのIDを定義しておき、利用者が”はさみ“のカテゴリを指定した場合、予め検索処理サーバ内部で定義されている、”はさみ“に対応するカテゴリID「１２３４」が指定され、各外部サーバに対応した「１１１１」、「２２２２」、「３３３３」に変換される。
【００３８】
このIDの変換は、利用者のリクエストを元に、検索処理サーバのカテゴリに対応するIDを、各外部サーバのカテゴリに対応するIDに変換するためのカテゴリ変換表を用いて変換する（図11参照）。すなわち、検索処理サーバは、受信したリクエスト中のカテゴリID「１２３４」を、カテゴリ変換表を参照することにより、外部サーバYに対しては「１１１１」、外部サーバRに対しては「２２２２」、そして、外部サーバAに対しては「３３３３」というように変換し、それぞれのWebAPIの仕様に従って送信する。
【００３９】
ここで、各外部サーバから提供されているWebAPIは、送信URLが異なることは当然のこととして、検索条件と指定されるリクエストパラメータの名前や値が異なる場合も考えられるので、この点も留意する必要がある。
【００４０】
例えば、外部サーバYでは、カテゴリを指定するためのリクエストパラメータ名は「category_id」であり、外部サーバRでは「genreId」であり、外部サーバAでは「BrowseNode」である場合、外部サーバYでは、category_id=１１１１、外部サーバRではgenreId=２２２２、外部サーバAではBrowseNode=３３３３をそれぞれの外部サーバへのリクエストパラメータとして付加し、HTTPリクエストを送信する。（図11参照）
【００４１】
カテゴリ変換表は、検索処理サーバが起動すると同時にHDDなどの記憶装置からリードして、メモリ上に展開しておくことで、変換処理を迅速に行う。なお、リクエストを受信する度にファイルやデータベースからカテゴリ変換表の情報を取得しても良い。
【技術分野】
【０００１】
本発明は、インターネットの利用に関し、特にウェブサイトを検索する技術やその為のコンピュータプログラムに関するものである。
【背景技術】
【０００２】
近年インターネットの普及に伴い、膨大な情報がインターネットを介して入手可能となっている。そのような膨大な情報の中から利用者が目的の情報を収集する手段として、一般的に認知されているのがポータルを代表とした検索サイトや検索エンジンである。
【０００３】
また、各々のジャンルや分類に特化した情報検索、例えばインターネット上の仮想店舗で販売されている商品を、利用者がクライアント端末を操作して購入できるオンラインショッピングや、商品の価格や評価といったレビュー、格付けを提供する情報サイトも実現化されている。
その他、複数のオンラインショップで取り扱われている多彩な商品を、統括して管理・販売するショッピングモール的なサービスも提供されており、また、同じように同種・同系のサービスを提供するショッピングモールも複数存在している。
【０００４】
それ以外でも、地域情報を取得するための地図検索サイトや飲食店情報提供サイトといった、さまざまなジャンルの情報を扱うWebサイトが開設されてきており、同一のジャンルの情報を扱うWebサイトも複数存在している。
【０００５】
一方、近年インターネット上ではオープンソースの普及に伴い、多くのサイトがWebAPIを公開し始めている。企業や個人がインターネット上で新しいWebサイトやサービスを提供する際、全ての機能を自前で開発するのではなく、部分的な機能については、公開されているWebAPIの機能を取り入れ、あたかも自身のWebサイトが所有している機能であるかのようなマッシュアップと呼ばれる手法を用いてWebサイトを構築する例が増えている。
【０００６】
独創性のアイデアにより生み出したマッシュアップの技法を競い合う、Webサイト構築のコンテストもここ数年開催されている（例えば、非特許文献１）。また、広報テキスト検索（非特許文献２）でマッシュアップについて検索すると、様々なマッシュアップを利用した技術が既に公開されている。
【非特許文献１】"MA6 (MASHUP AWARDS 6) on CREYLE"、［online］、［平成２２年８月２２日検索］、インターネット＜ＵＲＬ：http://mashupaward.jp/ ＞
【非特許文献２】"広報テキスト検索"、［online］、［平成２２年８月２２日検索］、インターネット＜ＵＲＬ：http://www7.ipdl.inpit.go.jp/Tokujitu/tjkta.ipdl?N0000=108 ＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
前述のとおり、利用者がインターネット上で目的の情報を検索する際には、例えば、検索エンジンを有するWebサイトや、レストラン情報や旅行情報といった特定のジャンルに特化したWebサイト、また、様々なマッシュアップを利用して構築されたWebサイトや、それに類する機能やサービスなどの外部サーバを利用することが一般的である。
【０００８】
しかし、昨今は同種・同系の情報の検索サービスを提供するWebサイトが別々に複数存在する。例えばショッピングモールサイトでも日本国内に代表的なサイトが複数あり、利用者がリクエストしたキーワードやカテゴリに関連する検索に際し、各サイトにおける検索結果が異なることもある。このため、利用者は複数の選択肢から結果を取得して比較検討したい場合、従来の手法では同種・同系の複数の検索Webサイトにアクセスし、場合によってはブラウザ上で画面を切り替えて情報を比較、検討後、そこから更に、例えば、目的とするショッピングサイトにアクセスする必要があるため、目的とする情報に到達するまでに労力を要するということが課題である。そして、従来のマッシュアップは、複数のジャンルの異なるWebサイトからそれぞれ異なる情報を取得して組み合わせることにより、利用者のニーズに応えようとするものであり、このような課題の解決を意図しているものではない。
【０００９】
また、同種のジャンルの情報を結合、表示させるための従来の方法の一例として、情報提供元となる各サイトから情報を収集し、独自に管理するデータベースに一旦情報を蓄積し、利用者から要求があった場合に、要求があった時点で最新の蓄積した情報を提供するといった方法が考えられる。この方式では、提供元のサイトの情報に変更があった場合、独自に管理するデータベースへ反映させるためのタイムラグが発生するため、タイムラグが長くなるほど、提供元と同じ情報を提供しにくくなるというデメリットがある。
【００１０】
具体的には、ある商品検索サイトでの検索結果画面に表示された商品と、その商品情報の提供元のサイト上での商品が同一のものであるにも関わらず、各々の価格や商品概要といった情報が異なっていることがある。これは、情報提供元の商品情報がデータベースに登録された後、商品情報提供元サイトがその商品情報に変更を加えたにも関わらず、商品検索サイトのデータベースに変更が反映されなかったためである。
【００１１】
一例としては、販売サイト（情報提供元）が、ある期間限定でセール価格として「\100」で販売している商品が、利用者が検索結果画面から得た時間帯では価格がセール前の「\500」の表示だったため、検索結果としては購買候補から外れてしまうという問題が生じ、利用者側、販売サイト側の双方にとって好ましくない結果が生じるという課題がある。
【００１２】
そこで、本発明は、上記の課題を解決するために、利用者がリクエストしたキーワードやカテゴリに対して、複数のサイトからリアルタイムに検索結果を取得し、利用者の要求に従って、結合、並び替えなどの処理が施されたレスポンスを返すことにより、利用者が統合的且つ効率的に情報を収集し、比較検討することを可能とする方法、プログラム、装置を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記の目的を達成するために、本発明の方法またはプログラムは、利用者のリクエストを受信する第１の受信ステップと、前記第１のリクエストに関連した特定のジャンルの情報を返す複数のレスポンスサーバ（外部サーバ）のそれぞれに、第２のリクエストを送信する第２リクエスト送信ステップ、複数の前記レスポンスサーバのそれぞれから、前記第２のリクエストに対する応答情報を含む第２のレスポンスを受信する第２レスポンス受信ステップ、複数の前記第２のレスポンスを受信した後に複数の前記応答情報に対して特定の処理を施し、結果情報を生成する結果情報生成ステップ、前記結果情報を含む前記第１のリクエストに対応する第１のレスポンスを送信する応答ステップ、を備えることを特徴とする（請求項１）。
【００１４】
この構成によって、利用者が統合的且つ効率的に検索結果を比較検討することができる。また、リアルタイムに最新の情報の取得が可能であり、取得した検索結果にタイムラグが生ずることがない。さらに、独自の検索対象情報を格納するためのデータベースを用意する必要がなく、手動や自動のいかんに関わらず、データ収集、蓄積する仕組みを構築するプロセスが不要となるという効果がある。
【００１５】
また、前記第１のリクエストに含まれるカテゴリを特定するための識別子を、複数の前記レスポンスサーバのそれぞれに対応する識別子に変換するための対応表を備え、
前記第２リクエスト送信ステップは、前記対応表に基づいて前記第１のリクエストをそれぞれの前記レスポンスサーバに対応する、前記第２のリクエストに変換した後に、リアルタイムに送信することを特徴とする（請求項２）。
【００１６】
各レスポンスサーバへのカテゴリを指定することで、各レスポンスサーバ内でカテゴリ分類されたものを取得することができるため、意図しない情報が検索結果に含まれることを回避し、利用者にとっても信頼性の高い情報を取得することができる。
【発明の効果】
【００１７】
本発明によれば、利用者が指定したキーワードやカテゴリを、複数の外部サーバのそれぞれの形式や内容に変換して複数Webサイトに一斉にHTTPリクエストを送り、それぞれのリアルタイムな検索結果をXMLレスポンスとして得、それらを統合、再配置して利用者に提示することにより、利用者が統合的且つ効率的に検索結果を比較検討することが可能になり、1回の操作で複数のサイトを検索した場合より、円滑且つ利便性の高い結果が得られることが期待できる。
【００１８】
また、利用者にとってタイムラグのなく、信頼性の高い情報を取得することができる。さらに、運用者にとっても、検索情報を格納するためのデータベースなどの高価な設備を必要とせず、また、データベースの更新といったメンテナンスが不要であり、運用コストの低いシステムが構築できる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施例における全体の構成概要を示す図。
【図２】実施例における、検索処理サーバのTOPページを示す図。
【図３】実施例における、利用者が商品検索を実施する際のイメージを示す図。
【図４】実施例における、利用者からのリクエストよりHTTPリクエストを送信する構成概要を示す図。
【図５】実施例における、キーワードを各WebAPIに含めて送るサンプルを示す図。
【図６】実施例における、該外部サーバからのレスポンスのサンプルを示す図。
【図７】実施例における、キーワードによる商品検索結果画面を示す図。
【図８】実施例における、TOPページからジャンル検索に遷移する手順を示す図。
【図９】実施例における、カテゴリによる商品検索結果画面を示す図。
【図１０】実施例における、ID情報を各外部サーバに対応する値に変換するカテゴリ変換表を示す図。
【図１１】実施例における、各外部サーバに対応したリクエストURLを作成している事を示す図。
【発明を実施するための形態】
【００２０】
本発明は、前述したWebAPIと呼ばれる技術やマッシュアップと呼ばれる手法によって成り立つものである。以下に、本発明の実施例について図面を参照して説明する。ただし、この実施の形態に記載されている内容はあくまでも例示であり、この発明の範囲をそれらのみに限定する趣旨のものではない。
【００２１】
本発明において、商品やレストラン情報などを検索しようとする利用者は、検索処理サーバから提供されたTOP画面を介して、検索対象に関する特定条件を含む検索リクエストを検索処理サーバに対して送る。検索処理サーバは、受信した検索リクエストを解析し、WebAPIの送信先である外部サーバのそれぞれに対し、該外部サーバが提供するWebAPIに応じた形式に該検索リクエストを変換し、複数の外部サーバにそれぞれ送信する。各外部サーバは、受信した上記の変換後の検索リクエストを処理して、検索処理サーバにレスポンスを送り、検索処理サーバは複数のレスポンスを受信して解析し、その結果を利用者に送信する。
【００２２】
上記の特定条件は、ジャンル、カテゴリ、キーワードなど、利用者が複数の外部サーバからの結果を比較し、検討したいと考える所望の条件である。また、TOP画面は少なくとも検索キーワードを入力するためのテキストボックスや、リクエストを送信するトリガーとなる実行ボタンやリンクを有することが好ましい。以下に、具体的な例を挙げて、本発明における処理の流れを説明する。
【実施例】
【００２３】
（実施例１）
ここでは例として、利用者がインターネットショッピングによって商品を購入する際に、購入を希望する商品を検索するまでの流れを説明する。商品は、具体的な例としてここでは、“はさみ”とする。
【００２４】
“はさみ”を購入したい利用者は、まずは、PCのWebブラウザを操作して、検索処理サーバにアクセスすると、検索処理サーバは例えば図２のようなTOP画面を利用者のWebブラウザに提供する。（図2参照）
【００２５】
次に、利用者は、TOP画面上のテキストボックスに、キーボードやタッチパネルなどの入力手段を用いてキーワードを“はさみ”と入力し、商品検索ボタンをクリックする（図3参照）。該クリックを契機として、Webブラウザは指定されたキーワードを含むHTTPリクエストを検索処理サーバに送信する。
【００２６】
検索処理サーバは、上記のHTTPリクエストを受信すると、検索処理サーバに登録されている各外部サーバに対してHTTPリクエストを送るために該リクエストを解析し、各外部サーバが提供するWebAPIを用いて、個別にHTTPリクエストを送信する(図4参照)。本例においては、検索処理サーバは、外部サーバY、外部サーバR、外部サーバAの３つが登録されているため、キーワード“はさみ”を各WebAPIに含めて送ることになる。（図5参照）
【００２７】
なお、検索処理サーバが複数の外部サーバに個別のリクエストを送るにあたっては、各外部サーバに順次送っても良い。あるいは、マルチスレッドなどの並列処理により一斉に送っても良く、この場合には、全ての外部サーバからの情報を得る時間を短縮することができるという効果がある。また、何らかの原因により外部サーバからの応答が得られず、HTTPリクエストのタイムアウト時間を待つようなことになっても、順次に送るよりも実行時間を短縮できる。
【００２８】
各外部サーバは、上記の検索処理サーバから送られた個別リクエストを受信すると、自己が備える検索エンジンを用いて受信したHTTPリクエスト内の“はさみ”を用いて商品の情報を検索し、その検索結果として値段を含む情報を、その要求元である検索処理サーバに対してXMLレスポンスを送る。（図6参照）
【００２９】
検索処理サーバは、これらの複数のレスポンスを全て受信すると、これらのレスポンス情報を解析し、それらの全ての情報を、例えば値段が安い順、高い順、人気の高い順、各サイトが提供するおすすめ順、といった利用者が希望する条件でソートして結果情報を作成し、利用者に該結果情報を含むレスポンスを送る。なお、全て受信してから解析を始めても良いし、各外部サーバから受信する度に処理を開始しても良い。（図7参照）
【００３０】
これによって、利用者は、結果情報を見て、複数サイトで得られる情報を一括で取得し、それらを容易に見比べることができる。
【００３１】
（実施例２）
上記のはさみを購入する例においては、利用者はTOP画面上でキーワードを指定する例を記載したが、キーワードを指定する代わりに、商品のカテゴリを指定しても良い。
【００３２】
カテゴリを指定することのメリットは、キーワード検索の時より、より信頼性の高い検索結果を得られるためである。キーワードのみによる検索を行う場合は、商品名や商品説明などに含まれる文言から、部分一致で取得されるため、余分な情報まで紛れ込む可能性が高くなる。具体的な例として、キーワードとして「はさみ」を指定した場合、検索結果に例えば「はさみ焼き」という単語が商品情報に含まれている商品も検索結果に含まれることになる。この場合、利用者は「はさみ」のみを検索結果として望んでいるのに対して、余分な情報まで紛れ込んでしまうことになる。カテゴリを指定することで、余分な情報が紛れ込むのを防ぐことができる。
【００３３】
このカテゴリとは、検索処理サーバが予め分類しているものであり、検索処理サーバが利用者のアクセスに応じて表示されるTOP画面上に配置されたボタンあるいはリンクなどをクリックすることで商品検索画面へ遷移する（図8参照）。
【００３４】
商品検索画面にはカテゴリが記載されており、そこで利用者は“はさみ”を検索する方法として、ここでは“事務用品”->“卓上アクセサリ”->“はさみ”の順番でカテゴリをクリックして画面を遷移させていく。（図9参照）
【００３５】
この“はさみ”の検索のための画面の遷移に伴う、カテゴリをクリックする一連の操作を契機に、利用者のWebブラウザが解釈し、上記と同様にカテゴリ情報を含むHTTPリクエストを検索処理サーバに送ることになる。
【００３６】
ここで、HTTPリクエストには、カテゴリに対応するID情報が含まれている。そして、検索処理サーバは、このHTTPリクエストを受信すると、各外部サーバに対する個別HTTPリクエストに変換するにあたって、ID情報を各Webサーバに対応する値に変換する必要がある。（図10参照）
【００３７】
これは、外部サーバの運用元はそれぞれ独自に情報をカテゴライズしており、外部サーバ間で統一されたものではないためである。すなわち、図10に例示するように、”はさみ“という商品カテゴリは、外部サーバYでは（切断用品）「１１１１」であり、外部サーバRでは（ハサミ＆カッター）「２２２２」であり、外部サーバA（ハサミ）では「３３３３」であり、それぞれ異なっている。この違いのため、各外部サーバのカテゴリIDに対応した検索処理サーバにおけるユニークのIDを定義しておき、利用者が”はさみ“のカテゴリを指定した場合、予め検索処理サーバ内部で定義されている、”はさみ“に対応するカテゴリID「１２３４」が指定され、各外部サーバに対応した「１１１１」、「２２２２」、「３３３３」に変換される。
【００３８】
このIDの変換は、利用者のリクエストを元に、検索処理サーバのカテゴリに対応するIDを、各外部サーバのカテゴリに対応するIDに変換するためのカテゴリ変換表を用いて変換する（図11参照）。すなわち、検索処理サーバは、受信したリクエスト中のカテゴリID「１２３４」を、カテゴリ変換表を参照することにより、外部サーバYに対しては「１１１１」、外部サーバRに対しては「２２２２」、そして、外部サーバAに対しては「３３３３」というように変換し、それぞれのWebAPIの仕様に従って送信する。
【００３９】
ここで、各外部サーバから提供されているWebAPIは、送信URLが異なることは当然のこととして、検索条件と指定されるリクエストパラメータの名前や値が異なる場合も考えられるので、この点も留意する必要がある。
【００４０】
例えば、外部サーバYでは、カテゴリを指定するためのリクエストパラメータ名は「category_id」であり、外部サーバRでは「genreId」であり、外部サーバAでは「BrowseNode」である場合、外部サーバYでは、category_id=１１１１、外部サーバRではgenreId=２２２２、外部サーバAではBrowseNode=３３３３をそれぞれの外部サーバへのリクエストパラメータとして付加し、HTTPリクエストを送信する。（図11参照）
【００４１】
カテゴリ変換表は、検索処理サーバが起動すると同時にHDDなどの記憶装置からリードして、メモリ上に展開しておくことで、変換処理を迅速に行う。なお、リクエストを受信する度にファイルやデータベースからカテゴリ変換表の情報を取得しても良い。
【特許請求の範囲】
【請求項１】
第１のリクエストを受信する受信ステップと、前記第１のリクエストに関連した特定のジャンルの情報を返す複数のレスポンスサーバのそれぞれに、第２のリクエストを送信する第２リクエスト送信ステップ、複数の前記レスポンスサーバのそれぞれから、前記第２のリクエストに対する応答情報を含む第２のレスポンスを受信する第２レスポンス受信ステップ、複数の前記第２のレスポンスを受信した後に複数の前記応答情報に対して特定の処理を施し、結果情報を生成する結果情報生成ステップ、前記結果情報を含む前記第１のリクエストに対応する第１のレスポンスを送信する応答ステップ、を備えることを特徴とする方法。
【請求項２】
前記第１のリクエストに含まれるカテゴリを特定するための識別子を、複数の前記レスポンスサーバのそれぞれに対応する識別子に変換するための対応表を備え、前記第２リクエスト送信ステップは、前記対応表に基づいて前記第１のリクエストをそれぞれの前記レスポンスサーバに対応する、前記第２のリクエストに変換した後に、リアルタイムに送信することを特徴とする方法。
【請求項３】
コンピュータに、請求項１または請求項２に記載の各ステップを実行させるように機能させることを特徴とするプログラム。
【請求項１】
第１のリクエストを受信する受信ステップと、前記第１のリクエストに関連した特定のジャンルの情報を返す複数のレスポンスサーバのそれぞれに、第２のリクエストを送信する第２リクエスト送信ステップ、複数の前記レスポンスサーバのそれぞれから、前記第２のリクエストに対する応答情報を含む第２のレスポンスを受信する第２レスポンス受信ステップ、複数の前記第２のレスポンスを受信した後に複数の前記応答情報に対して特定の処理を施し、結果情報を生成する結果情報生成ステップ、前記結果情報を含む前記第１のリクエストに対応する第１のレスポンスを送信する応答ステップ、を備えることを特徴とする方法。
【請求項２】
前記第１のリクエストに含まれるカテゴリを特定するための識別子を、複数の前記レスポンスサーバのそれぞれに対応する識別子に変換するための対応表を備え、前記第２リクエスト送信ステップは、前記対応表に基づいて前記第１のリクエストをそれぞれの前記レスポンスサーバに対応する、前記第２のリクエストに変換した後に、リアルタイムに送信することを特徴とする方法。
【請求項３】
コンピュータに、請求項１または請求項２に記載の各ステップを実行させるように機能させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１２−４８３３４（Ｐ２０１２−４８３３４Ａ）
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願番号】特願２０１０−１８７８３８（Ｐ２０１０−１８７８３８）
【出願日】平成２２年８月２５日（２０１０．８．２５）
【出願人】（７１０００９４３８）
【Ｆターム（参考）】
【公開日】平成２４年３月８日（２０１２．３．８）
【国際特許分類】
【出願日】平成２２年８月２５日（２０１０．８．２５）
【出願人】（７１０００９４３８）
【Ｆターム（参考）】
[ Back to top ]