情報処理装置
【課題】ユーザの介在が必要なＷｅｂサイトのＷｅｂＡＰＩ化を容易に行なう。
【解決手段】駅名入力画面で所望の乗車駅名と下車駅名が入力されると、旅費精算アプリは、乗車駅から下車駅までの経路探索をスクレイピングサーバ１に要求する。スクレイピングサーバ１のＷｅｂＡＰＩ提供処理部１３は、乗車駅および下車駅の候補が示される駅名選択ＨＴＭＬページデータを経路探索Ｗｅｂサイトから取得して、Ｗｅｂブラウザにより駅名選択画面を表示させる。駅名選択画面から意図する駅名が選択されると、ＵＩ提供処理部１４は、乗車駅から下車駅までの経路が示される経路一覧ＨＴＭＬページを経路探索Ｗｅｂサイトから取得してＷｅｂブラウザにより表示させる。また、スクレイピング実行部１６は、経路一覧ＨＴＭＬページをもとに、ＸＭＬ形式の経路一覧ＸＭＬデータを生成して、旅費精算アプリに返す。
【解決手段】駅名入力画面で所望の乗車駅名と下車駅名が入力されると、旅費精算アプリは、乗車駅から下車駅までの経路探索をスクレイピングサーバ１に要求する。スクレイピングサーバ１のＷｅｂＡＰＩ提供処理部１３は、乗車駅および下車駅の候補が示される駅名選択ＨＴＭＬページデータを経路探索Ｗｅｂサイトから取得して、Ｗｅｂブラウザにより駅名選択画面を表示させる。駅名選択画面から意図する駅名が選択されると、ＵＩ提供処理部１４は、乗車駅から下車駅までの経路が示される経路一覧ＨＴＭＬページを経路探索Ｗｅｂサイトから取得してＷｅｂブラウザにより表示させる。また、スクレイピング実行部１６は、経路一覧ＨＴＭＬページをもとに、ＸＭＬ形式の経路一覧ＸＭＬデータを生成して、旅費精算アプリに返す。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ端末装置からのリクエストにしたがってＷｅｂアプリケーションのサービスを提供する情報処理装置に関する。
【背景技術】
【０００２】
従来、Ｗｅｂサイトの機能をシステム向けにＡＰＩ（アプリケーションプログラミングインタフェース：Application Programming Interface）として提供する技術（以下、ＷｅｂＡＰＩと称する）や、複数のＷｅｂサイトの機能やＷｅｂＡＰＩを組み合わせて新たなサービスを提供する技術（マッシュアップなどと呼ばれる）が成熟してきた。
【０００３】
前述した、Ｗｅｂサイトの機能を提供する技術としては、例えば特許文献１に開示されるように、複数のＷｅｂアプリケーションを実行する場合に、汎用Ｗｅｂブラウザを用いて、前段の処理結果を後段のＷｅｂアプリケーションに引き継ぐものがある。
【０００４】
また、Ｗｅｂサイトの機能を提供する他の技術としては、例えば、Ｗｅｂサイト提供者自らシステム向けにＡＰＩを提供する技術が挙げられ、また、Ｗｅｂサイト画面からデータを抜き出してシステム向けのＡＰＩ化を行なうスクレイピング（scraping）ライブラリや環境が挙げられ、また、システム向けＡＰＩを組み合わせて新たなサービスを構築するマッシュアップ環境が挙げられる。
【０００５】
ところで、Ｗｅｂサイトが提供するサービスには、利用時にユーザの介在を必要とするものもある。例として、ＷｅｂＡＰＩが、オンライン書店での検索を行なってユーザの好む本の情報を取得する事や、経路探索用のＷｅｂサイトがユーザからの選択にしたがって適切な乗車駅／下車駅を特定して経路を探索する事が挙げられる。
【０００６】
このように、ＷｅｂサイトをスクレイピングしてＷｅｂＡＰＩ化を行なう際には、ＷｅｂＡＰＩの実行時にユーザが介在する仕組みを考慮する必要がある。以下、この仕組みについて経路探索Ｗｅｂサイトを例として説明を行なう。
【０００７】
図１０は、従来の経路探索Ｗｅｂサイトの画面表示例を示す図である。
図１０に示した経路探索Ｗｅｂサイトでは、駅名入力画面にてユーザがユーザ端末装置を用いて乗車駅名と下車駅名を入力して画面上の検索ボタンを押すと、経路一覧画面にて乗車駅から下車駅までの乗り換え経路が提示される。
【０００８】
ただし駅名入力画面で入力した駅名に曖昧性があると、この駅名入力画面が駅名選択画面に遷移し、ユーザが意図する駅名を選択するよう促す。
【０００９】
図１０に示した例では、駅名入力画面で入力された「府中」という駅名に対して「府中（東京）」、「府中（広島）」、「府中（徳島）」などが駅名選択画面に表示される。ユーザはこの駅名一覧から意図する駅を選択することで、適切な経路を経路一覧画面で得ることになる。
このような、ユーザの介在を必要とするＷｅｂサイトをＷｅｂＡＰＩ化するためには、従来では以下に示す２つの手法が挙げられる。
第１の手法は細分化である。この細分化とは、ユーザの介在を必要としない細かい単位の複数個のＷｅｂＡＰＩを用意し、それらをマッシュアップする側であるユーザ側のアプリケーションで組合せて使う事である。
【００１０】
第２の手法は自動化である。この自動化とは、ユーザの介在が不要となる様に、ユーザが従来介在していた部分の処理の実行を自動化する事である。
【００１１】
図１１は、従来のＷｅｂＡＰＩの利用形態の第１の例を示す図である。
図１１に示した手法は、前述した細分化の手法（第１の手法）であり、ＷｅｂＡＰＩとして、駅名一覧取得ＡＰＩおよび経路探索ＡＰＩを用いる。
【００１２】
駅名一覧取得ＡＰＩは、ユーザ端末装置側のアプリケーションプログラム（以下、アプリケーションと称する）である旅費精算アプリケーション（以下、旅費精算アプリと称する）を介した文字列を入力として、その文字列にマッチする駅名一覧を経路探索Ｗｅｂサイトから駅名候補として取得して旅費精算アプリに返す。
【００１３】
また、経路探索ＡＰＩは、前述した駅名一覧から旅費精算アプリを介して選択された乗車駅名と下車駅名、つまり乗車駅と下車駅をそれぞれ一意に特定できる情報を入力として、これらの乗車駅から下車駅までの乗り換え経路を経路探索Ｗｅｂサイトから取得して旅費精算アプリに返す。
【００１４】
図１２は、従来のＷｅｂＡＰＩの利用形態の第２の例を示す図である。
図１２に示した手法は、前述した自動化の手法（第２の手法）であり、ＷｅｂＡＰＩとして経路探索ＡＰＩを用いる。
【００１５】
この経路探索ＷｅｂＡＰＩは、ユーザ端末装置側の旅費精算アプリを介して入力された乗車駅と下車駅のそれぞれの文字列にマッチした駅名一覧を経路探索Ｗｅｂサイトから取得する。そして、経路探索ＷｅｂＡＰＩは、この駅名一覧からユーザが意図する駅を推測することで自動的に選択し、この選択した乗車駅から下車駅までの乗り換え経路を経路探索Ｗｅｂサイトから取得して旅費精算アプリに返す。
【先行技術文献】
【特許文献】
【００１６】
【特許文献１】特開２００６−１７８８８７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１７】
前述したように、ユーザの介在を必要とするＷｅｂサイトをＷｅｂＡＰＩ化するための細分化の方法では、ＷｅｂＡＰＩは、機能が細切れのサブルーチンＷｅｂＡＰＩ群に分かれて提供されるため、システムでの利用方法が複雑になる。
【００１８】
図１１に示した例では、経路探索のためのＡＰＩの他に、駅名一覧取得のためのＡＰＩという本質的ではないＡＰＩが別途必要となってしまう。
また、この細分化の手法では、ユーザが介在するためのユーザインタフェース（以下、ＵＩと称する）をマッシュアップアプリ側のＵＩとして別途開発しなければならない。図１１に示した例では、駅名一覧から駅を一つ選択するためのＵＩが別途必要になる。
【００１９】
また、前述した自動化の手法では、ユーザの介在を要していた処理を自動化するためのロジックがサーバ側に必要となる。図１１に示した例では、ユーザの介在部分、つまり駅名一覧におけるユーザが意図する駅名はユーザの現在位置や嗜好など様々な要因に関係しているので、駅名一覧からユーザの意図する駅をサーバ側で適切に推測することは容易ではない。
【００２０】
また、サーバ側でユーザの意図する駅名の推測を誤るとユーザの意図に沿えなくなる可能性がある。例えば、「駅名一覧の中から一番上の駅を選択する」というような単純な規則では、必ずしもユーザの意図にそぐわない可能性がある。
【００２１】
以上説明したように、従来技術における、ユーザの介在を必要とするＷｅｂサイトをＷｅｂＡＰＩ化するため技術では、ＷｅｂＡＰＩの複雑化に伴って、これを用いるためのシステムが複雑になったり、ユーザの意図に沿えない処理を行なったりしてしまうといった課題がある。
【００２２】
そこで、本発明の目的は、ユーザの介在が必要なＷｅｂサイトのＷｅｂＡＰＩ化を容易に行なうことが可能になる情報処理装置を提供することにある。
【課題を解決するための手段】
【００２３】
すなわち、本発明に係わる情報処理装置は、ユーザ側の端末装置で実行されるユーザ側アプリケーションからのリクエストがなされた場合に、Ｗｅｂサーバにより構築されるＷｅｂサイトへのアクセスを行なうことで、前記リクエストを受けて、データ加工手段による処理結果を返却値データとして前記ユーザ側アプリケーションに出力するアプリケーションプログラミングインタフェース手段と、前記ユーザ側アプリケーションからのリクエストにしたがって前記アプリケーションプログラミングインタフェース手段により前記Ｗｅｂサイトから取得した中間値データを保持するデータ保持手段と、前記中間値データを前記ユーザ側アプリケーションを介さずに前記端末装置に表示する表示手段と、前記表示手段による表示結果に対する入力を受け付ける入力手段と、前記入力手段による入力結果にしたがって、前記データ保持手段により保持される前記中間値データをもとに前記Ｗｅｂサイトへのアクセスを行なうことで、当該Ｗｅｂサイトへのさらなるアクセスを要しないデータを取得するデータ取得手段とを備え、前記データ加工手段は、前記データ取得手段により取得したデータの形式を前記ユーザ側アプリケーションによる処理に適合する形式に加工することを特徴とする。
【発明の効果】
【００２４】
本発明によれば、ユーザの介在が必要なＷｅｂサイトのＷｅｂＡＰＩ化を容易に行なうことができる。
【図面の簡単な説明】
【００２５】
【図１】本発明の実施形態における情報処理システムの構成例を示す図。
【図２】本発明の実施形態における情報処理システムのスクレイピングサーバの構成例を示すブロック図。
【図３】本発明の実施形態における情報処理システムのユーザ端末装置の構成例を示すブロック図。
【図４】本発明の実施形態における情報処理システムのスクレイピングサーバの機能を示す図。
【図５】本発明の実施形態における情報処理システムのスクレイピングサーバのリクエスト管理テーブルの構成例を表形式で示す図。
【図６】本発明の実施形態における情報処理システムのスクレイピングサーバのスクレイピングルールテーブルの構成例を表形式で示す図。
【図７】本発明の実施形態における情報処理システムのＷｅｂサーバが提供する経路探索サイトの画面遷移例を示す図。
【図８】本発明の実施形態における情報処理システムによる処理動作の概要を示す図。
【図９】本発明の実施形態における情報処理システムによる処理動作の一例を示すシーケンス図。
【図１０】従来の経路探索Ｗｅｂサイトの画面表示例を示す図。
【図１１】従来のＷｅｂＡＰＩの利用形態の第１の例を示す図。
【図１２】従来のＷｅｂＡＰＩの利用形態の第２の例を示す図。
【発明を実施するための形態】
【００２６】
以下図面により本発明の実施形態について説明する。
図１は、本発明の実施形態における情報処理システムの構成例を示す図である。
図１に示すように、本発明の実施形態における情報処理システムは、スクレイピングサーバ１、Ｗｅｂサーバ２およびユーザ端末装置３を有する。
【００２７】
スクレイピングサーバ１およびＷｅｂサーバ２はネットワークを介して接続される。Ｗｅｂサーバ２およびユーザ端末装置３は図１に示したようなローカル接続もしくはネットワーク経由で接続される。
【００２８】
スクレイピングサーバ１は、ユーザの介在を必要とするＷｅｂＡＰＩを提供し、さらに当該ＷｅｂＡＰＩの実行にユーザが介在するためのＵＩを提供する。
Ｗｅｂサーバ２は、ユーザからのリクエストに応じたＷｅｂアプリケーションのサービス提供のためのＷｅｂサイトが構築されるサーバである。
また、ユーザ端末装置３は、例えばパーソナルコンピュータであり、Ｗｅｂアプリケーションのサービスを利用するためのアプリケーションを格納し、これを実行する。図１ではユーザ端末装置３は１台のみ図示しているが、この台数は限定されない。
【００２９】
スクレイピングサーバ１は、ユーザ端末装置３側のアプリケーションからの一回のＷｅｂＡＰＩの呼び出しを起点とし、この呼び出しに続けてバックエンドで発生する、Ｗｅｂサーバ２側のＷｅｂサイトへの複数回のアクセスを管理し、これら一連のＷｅｂサイトアクセスの最終結果から必要なデータを抜き出した値をＷｅｂＡＰＩの返却値データとしてアプリケーションに返す。
【００３０】
その際、スクレイピングサーバ１は、一連のＷｅｂサイトアクセスにユーザが直接介在できるように、ＷｅｂサイトのＵＩを元にユーザ向けＵＩをユーザ端末装置３側に提供する。これにより、ユーザ端末装置３側のアプリケーションからの一回のＷｅｂＡＰＩ呼出／応答と、ＷｅｂサイトのＵＩを用いたユーザの介在とを非同期に連携して実行する。
【００３１】
図２は、本発明の実施形態における情報処理システムのスクレイピングサーバの構成例を示すブロック図である。
図２に示すように、スクレイピングサーバ１は、装置全体の処理動作を司る制御部１１、記憶装置１２、ＷｅｂＡＰＩ提供処理部１３、ＵＩ提供処理部１４、リクエスト管理部１５、スクレイピング実行部１６および通信インタフェース１７を備え、それぞれがバス１８を介して接続される。
【００３２】
記憶装置１２は、ハードディスクドライブや不揮発性メモリなどの記憶媒体であり、ＷｅｂＡＰＩ提供処理部１３、ＵＩ提供処理部１４、リクエスト管理部１５、スクレイピング実行部１６による処理動作のためのプログラムを記憶する他、リクエスト管理テーブル格納部２１およびスクレイピングルールテーブル格納部２２を有する。
【００３３】
ＷｅｂＡＰＩ提供処理部１３は、ユーザ端末装置３側のアプリケーションからのＷｅｂＡＰＩへのリクエストを受け付けるシステム向けインタフェース（アプリケーションプログラミングインタフェース手段）として機能する。例えば、ＷｅｂＡＰＩ提供処理部１３は、ＵＲＬ形式のリクエストをＨＴＴＰプロトコルで受け付け、ＸＭＬ形式の返却値データをリクエスト元に返す。ただし、リクエストの入出力はＵＲＬ形式やＸＭＬ形式に限定されない。
【００３４】
ＵＩ提供処理部１４は、ＷｅｂＡＰＩの実行にユーザが介在するためのＵＩとして機能する（データ加工手段の一例）。例えば、ＵＩ提供処理部１４は、ユーザ端末装置３側のＷｅｂブラウザ上にＨＴＭＬページを表示する事でユーザに情報を提示したり、ユーザ端末装置３により入力された情報を得たりする。ただし、ＵＩの実現形態はＷｅｂブラウザに限定されない。
【００３５】
リクエスト管理部１５は、ユーザ端末装置３側のアプリケーションからのＷｅｂＡＰＩへのリクエストによって開始されたＷｅｂサイトアクセスの状態をリクエストごとに区分して管理する。リクエスト管理部１５を介して、アプリケーションからの一回のＷｅｂＡＰＩ呼び出しを起点として、その後、ユーザによる複数回のＷｅｂサイトアクセスが発生する場合がある。
【００３６】
また、リクエスト管理部１５は、ユーザの介在が必要なＷｅｂページであるＨＴＭＬページと、ユーザの介在によってＷｅｂサーバ２側のＷｅｂサイトから得られた最終的な返却値とを記憶装置１２に保持する処理を行なう。
【００３７】
スクレイピング実行部１６は、Ｗｅｂサイトから返却されたＷｅｂページを所定のルールにしたがって加工する。このルールは後述するスクレイピングルールテーブルで定義される。
通信インタフェース１７は、Ｗｅｂサーバ２やユーザ端末装置３との間の入出力を行なう。
【００３８】
スクレイピングサーバ１は、ハードウェア構成、またはハードウェア構成とソフトウェア構成との組合せにより実現可能である。後者の場合、ソフトウェア構成は、予めコンピュータ読み取り可能な記憶媒体またはネットワークから得られたプログラムがコンピュータにインストールされることにより、スクレイピングサーバ１としての各機能が実現される。
【００３９】
図３は、本発明の実施形態における情報処理システムのユーザ端末装置の構成例を示すブロック図である。
図３に示すように、ユーザ端末装置３は、装置全体の処理動作を司る制御部３１、記憶装置３２、キーボードやマウスなどの入力装置３３、液晶ディスプレイなどの表示装置３４および通信インタフェース３５を備え、それぞれがバス３６を介して接続される。
記憶装置３２は、ハードディスクドライブや不揮発性メモリなどの記憶媒体であり、アプリケーションを格納するアプリケーション格納部４１やＷｅｂブラウザを格納するＷｅｂブラウザ格納部４２を有する。
【００４０】
図４は、本発明の実施形態における情報処理システムのスクレイピングサーバの機能を示す図である。
図４に示すように、本実施形態では、ユーザ側への提供対象のサービスは経路探索であり、ユーザ端末装置３側のマッシュアップアプリとして旅費精算アプリを用い、Ｗｅｂサーバ２側のＷｅｂサイトとして経路探索Ｗｅｂサイトを用いる。また、ユーザ端末装置３では、ＷｅｂＡＰＩ実行時にユーザが介在するためＵＩとして、マッシュアップアプリとは別個のＷｅｂブラウザを用いる。
【００４１】
図５は、本発明の実施形態における情報処理システムのスクレイピングサーバのリクエスト管理テーブルの構成例を表形式で示す図である。
図６は、本発明の実施形態における情報処理システムのスクレイピングサーバのスクレイピングルールテーブルの構成例を表形式で示す図である。
図７は、本発明の実施形態における情報処理システムのＷｅｂサーバが提供する経路探索サイトの画面遷移例を示す図である。
スクレイピングサーバ１の記憶装置１２のリクエスト管理テーブル格納部２１には、図５に示した形式のリクエスト管理テーブルが格納される。このリクエスト管理テーブルは、ユーザ端末装置３側のアプリケーションからのＷｅｂＡＰＩへのリクエストによって開始されたＷｅｂサイトアクセスの状態をリクエスト管理部１５により管理するための情報を記憶するテーブルである。
【００４２】
また、スクレイピングサーバ１の記憶装置１２のスクレイピングルールテーブル格納部２２には、図６に示した形式のスクレイピングルールテーブルが格納される。このテーブルは、スクレイピング実行部１６による、Ｗｅｂサイトから返却されたデータの加工方法を定義するためのテーブルである。
【００４３】
図７に示すように、経路探索Ｗｅｂサイトの状態は、「状態０」、「状態１」および「状態２」に区分される。
この「状態０」はＷｅｂブラウザの画面の初期状態であり、乗車駅名と下車駅名を入力する駅名入力画面を指す。また、「状態１」は駅名選択画面を指し、「状態２」は経路一覧画面を指す。
【００４４】
本実施形態では、「状態０」である駅名入力画面にてユーザ端末装置３により乗車駅「府中」と下車駅「横浜」とを入力して画面上の検索ボタンを押すと、ユーザが意図する駅名を選択するための「状態１」に遷移する。
【００４５】
図７に示した例では、「状態０」の駅名入力画面にて入力された「府中」という駅名に対して「府中（東京）」、「府中（広島）」、「府中（徳島）」といった選択肢が駅名選択画面に提示される。また、「状態０」の駅名入力画面にて入力された「横浜」という駅名に対して「横浜」、「陸奥横浜」といった選択肢が駅名選択画面に提示される。
【００４６】
この駅名選択画面上でユーザが意図する駅名を選択すると、「状態２」に遷移して乗車駅から下車駅までの経路が表示されることになる。図７に示した例では、駅名選択画面上で乗車駅名として「府中（東京）」が選択されて、下車駅名として「横浜」が選択されたことにより、途中駅である「新宿」を含む経路が経路一覧画面に表示される。
【００４７】
図５に示すように、リクエスト管理テーブルは、リクエストごとに「リクエストＩＤ」、「状態」、「最初の画面」および「返却値」を保持する。
リクエスト管理テーブル上の「リクエストＩＤ」は、ユーザ端末装置３側からのＷｅｂＡＰＩへのリクエストを一意に識別するためのデータである。つまり、リクエストＩＤ（リクエスト識別情報）が、リクエスト管理テーブルで各リクエストに対して付与されることになる（リクエスト識別情報付与手段の一例）。
【００４８】
リクエスト管理テーブル上の「状態」は、前述したリクエストに伴うＷｅｂサイトアクセスの状態を示す。図５に示したリクエスト管理テーブルは前述した経路探索に適合したテーブルであり、このテーブル上の「状態」が取り得る値は、図７に示した状態遷移例における駅名入力画面である「状態１」、経路一覧画面である「状態２」、および「終了」である。
【００４９】
リクエスト管理テーブル上の「最初の画面」は、ユーザの介在が必要な最初のＷｅｂページの画面の種別を示す。本実施形態では、この画面にはスクレイピング実行部１６によって前述したリクエストＩＤが埋め込まれ、当該画面がスクレイピングサーバ１の記憶装置１２に保存される。
【００５０】
また、リクエスト管理テーブル上の「返却値」は、ＷｅｂＡＰＩの返却値としてアプリケーションに返す返却値データである。この返却値データは、ユーザ端末装置３によるＷｅｂページ操作を経て得られた最終的なＷｅｂページから、スクレイピング実行部１６によって必要なデータを抜き取ることで作成され、スクレイピングサーバ１の記憶装置１２に保存される。
また、図６に示すように、スクレイピングルールテーブル上のルールは、ユーザ向けルールとＷｅｂＡＰＩ向けルールとに区分され、図７に示した状態遷移の各状態に対して、前述したユーザ向けルールとＷｅｂＡＰＩ向けルールとがそれぞれ対応付けられる。ルールの定義方法には例えばXSLTやXQueryといった既存の言語を用いることができる。
【００５１】
スクレイピングルールテーブル上のＷｅｂＡＰＩ向けルールとは、ユーザの介在によってＷｅｂサイトから最終的に得られたＷｅｂページからアプリケーションへの出力に必要なデータを抜き取ることで返却値データを作成するためのルールである。
【００５２】
図６に示したテーブルは前述した経路探索に適合したテーブルであり、「状態２」に対応するＷｅｂＡＰＩ向けルールとしてルール１「システム向けに、経路一覧画面から経路データを抜き出し、ＸＭＬ形式に変換する」が定義され、「状態１」に対応するユーザ向けルールとしてルール２「ユーザ向けに、駅名選択画面にリクエストＩＤを埋め込む」が定義され、「状態２」に対応するユーザ向けルールとしてルール３「ユーザ向けに、経路一覧画面を読みやすく変更する」が定義される。
【００５３】
次に、以上示した構成の情報処理システムの動作について説明する。
図８は、本発明の実施形態における情報処理システムによる処理動作の概要を示す図である。
図９は、本発明の実施形態における情報処理システムによる処理動作の一例を示すシーケンス図である。
図８および図９は、経路探索のためのメッセージの流れを具体的に示すものである。ここでは、本発明の理解を容易にするために、図８と図９にて同じメッセージシーケンスを異なる表現形式で示している。図８は、図４にメッセージの流れを重ねた図である。
【００５４】
この情報処理システムは、ユーザ端末装置３側の旅費精算アプリを用いてユーザが乗車駅名と下車駅名を入力すると経路探索ＷｅｂＡＰＩを呼び出し、移動経路を補完する。
本実施形態では説明を単純にするため移動経路だけを考慮するが、移動経路だけでなく交通費を補完するなど様々な応用も考えられる。
【００５５】
以下、経路探索のためのメッセージの流れを順に説明する。
まず、ユーザ端末装置３の入力装置３３への所定の操作がなされると、記憶装置１２のアプリケーション格納部４１に格納される旅費精算アプリが起動する。この旅費精算アプリはＷｅｂブラウザを起動して駅名入力画面を表示装置３４に表示させる（表示手段の一例）。
【００５６】
この駅名入力画面で、ユーザが入力装置３３により所望の乗車駅名および下車駅名を入力すると、旅費精算アプリは、スクレイピングサーバ１のＷｅｂＡＰＩ提供処理部１３を介して経路探索ＷｅｂＡＰＩを呼び出す。ここでは、乗車駅名として「府中」が入力されて、下車駅名として「横浜」が入力されたとする。
【００５７】
この際、旅費精算アプリは、「リクエストＩＤ」を発行し、このリクエストＩＤおよび前述した「乗車駅」、「下車駅」を引数としてＷｅｂＡＰＩ提供処理部１３に渡すことで経路探索を要求する（ステップＳ１）。
リクエストＩＤは、ＡＰＩの呼び出しを一意に識別するためのデータである。本実施形態では、呼び出し側であるユーザ端末装置３でＵＵＩＤ（Universally Unique Identifier）を作成してスクレイピングサーバ１側に渡している。このリクエストＩＤはスクレイピングサーバ１側で発行して呼び出し側に提示するようにしてもよい。
【００５８】
ＷｅｂＡＰＩ提供処理部１３は、旅費精算アプリから渡された「乗車駅」、「下車駅」および「リクエストＩＤ」をもとに、乗車駅から下車駅までの経路を取得するために、Ｗｅｂサーバ２側の経路探索Ｗｅｂサイトへの経路探索のためのアクセスを行なう（ステップＳ２）。
【００５９】
経路探索Ｗｅｂサイトは、旅費精算アプリから渡された「乗車駅」および「下車駅」の駅名候補が示されて当該駅名候補の識別番号が含まれるページデータである駅名選択ＨＴＭＬページデータをＷｅｂＡＰＩ提供処理部１３に返す。
【００６０】
ＷｅｂＡＰＩ提供処理部１３は、駅名選択ＨＴＭＬページデータを経路探索Ｗｅｂサイトから取得すると、この駅名選択ＨＴＭＬページデータの解析（加工）をスクレイピング実行部１６に依頼する（ステップＳ３）。
【００６１】
この駅名選択ＨＴＭＬページデータの状態は、図６に示したスプレイピングルールテーブル上の「状態１」に該当する。この場合、スクレイピング実行部１６は、ステップＳ３の処理による依頼を受けると、図６に示したスプレイピングルールテーブル上の「状態１」に対応するユーザ向けルールの「ルール２」にしたがって、駅名選択ＨＴＭＬページデータに対し、ステップＳ１の処理により旅費精算アプリから渡されたリクエストＩＤを埋め込むことで、「リクエストＩＤ入り駅名選択ＨＴＭＬページ」を作成する。
【００６２】
このようにリクエストＩＤをページデータに埋め込むことにより、この後のユーザの介在によるＷｅｂサイトへの一連のアクセスが前述した最初のＷｅｂＡＰＩ呼び出しに対応付けられる。よって、異なるユーザのそれぞれが用いるユーザ端末装置３からのリクエストがなされた場合でも、それぞれのリクエストについてのスクレイピングサーバ１による経路探索処理を行なうことができる。
【００６３】
ＷｅｂＡＰＩ提供処理部１３は、スクレイピング実行部１６による加工後のデータである「リクエストＩＤ入り駅名選択ＨＴＭＬページ」の保存をリクエスト管理部１５に依頼する（ステップＳ４）。すると、リクエスト管理部１５は、この「リクエストＩＤ入り駅名選択ＨＴＭＬページ」を記憶装置１２に保存する。
【００６４】
また、ステップＳ１の処理後、ユーザ端末装置３側の旅費精算アプリは、駅名選択画面を起動するために、リクエストＩＤを含むＵＲＬを引数として、ＷｅｂＡＰＩ実行時にユーザが介在するための駅名選択ＵＩであるＷｅｂブラウザを起動する（ステップＳ５）。
【００６５】
すると、このＷｅｂブラウザは、スクレイピングサーバ１のＵＩ提供処理部１４に対して、ステップＳ１の処理で説明したリクエストＩＤをキーとして、このリクエストＩＤを含むＵＲＬ、つまり駅名選択画面用のＵＲＬの取得をスクレイピングサーバ１のＵＩ提供処理部１４に依頼する（ステップＳ６）。
【００６６】
ＵＩ提供処理部１４は、ＷｅｂブラウザからのリクエストＩＤをキーとして、リクエスト管理部１５に対し、記憶装置１２に保存される「リクエストＩＤ入り駅名選択ＨＴＭＬページ」の取得を依頼する（ステップＳ７）。
【００６７】
リクエスト管理部１５は、この依頼にしたがって、記憶装置１２に保存されるリクエストＩＤ入り駅名選択ＨＴＭＬページのうち、ＵＩ提供処理部１４からのリクエストＩＤに対応するページを取得する。このページは、ＵＩ提供処理部１４を介し、リクエスト元のユーザ端末装置３側のＷｅｂブラウザにより駅名選択画面として表示装置３４に表示される（表示手段の一例）。
【００６８】
ユーザは、Ｗｅｂブラウザ上の駅名選択画面に表示される乗車駅名および下車駅名の候補のうち、意図する駅名を入力装置３３への操作により選択する（ステップＳ８）。ここでは、乗車駅名として「府中（東京）」が選択され、下車駅名として「横浜」が選択されたとする。
【００６９】
すると、Ｗｅｂブラウザは、ステップＳ１の処理で説明したリクエストＩＤに加え、駅名選択画面で選択された駅名をＵＩ提供処理部１４に送信する（ステップＳ９）。
ＵＩ提供処理部１４は、ＷｅｂブラウザからのリクエストＩＤ、選択済みの乗車駅名と下車駅名を受信すると、当該選択済みの乗車駅名及び下車駅名をキーとして、Ｗｅｂサーバ２側の経路探索Ｗｅｂサイトへの経路探索のためのアクセスを行ない（ステップＳ１０）、この経路探索Ｗｅｂサイトから、前述した乗車駅から下車駅までの経路が示される経路一覧ＨＴＭＬページを取得する。
【００７０】
この経路一覧ＨＴＭＬページは、経路一覧ＨＴＭＬページを経路探索Ｗｅｂサイトからの最終的なデータ、つまり前述したリクエストにしたがって経路探索Ｗｅｂサイトへのさらなるアクセスを要しないデータであり、前述したリクエストＩＤが含まれる。ここでは、乗車駅「府中（東京）」から下車駅「横浜」までの途中駅を含む「府中（東京）→新宿→横浜」が経路として示されるとする。
【００７１】
そして、ＵＩ提供処理部１４は、経路探索Ｗｅｂサイトから取得した経路一覧ＨＴＭＬページの解析、つまりデータ加工をスクレイピング実行部１６に依頼する（ステップＳ１１）。
【００７２】
経路一覧ＨＴＭＬページが生成された状態は、図６に示すスクレイピングテーブルの「状態２」に該当する。よって、スクレイピング実行部１６は、ＵＩ提供処理部１４からの依頼に従って、スクレイピングルールテーブル格納部２２に格納される図６に示すスクレイピングルールのうち、「状態２」に対応するＷｅｂＡＰＩ向けルールである「システム向けに、経路一覧画面から経路データを抜き出し、ＸＭＬ形式に変換する」にしたがって、前述した経路一覧ＨＴＭＬページから旅費精算アプリに必要な経路データを抜き取り、旅費精算アプリによる処理に適合した形式であるＸＭＬ形式の経路一覧ＸＭＬデータを生成する。スクレイピング実行部１６は、この生成した経路一覧ＸＭＬデータをＵＩ提供処理部１４に出力する。
【００７３】
また、スクレイピング実行部１６は、スクレイピングルールテーブル格納部２２に格納される図６に示すスクレイピングルールのうち、「状態２」に対応するユーザ向けルールである「ユーザ向けに、経路一覧画面を読みやすく変更する」にしたがって、経路一覧ＨＴＭＬページにおける文字のフォントやレイアウトをＷｅｂブラウザでの表示に適合した形式に変更してＵＩ提供処理部１４に出力する。
【００７４】
ＵＩ提供処理部１４は、スクレイピング実行部１６からの経路一覧ＸＭＬデータを入力すると、この経路一覧ＸＭＬデータの保存をリクエスト管理部１５に依頼する（ステップＳ１２）。リクエスト管理部１５は、この依頼にしたがって経路一覧ＸＭＬデータを記憶装置１２に保存する。
【００７５】
ＵＩ提供処理部１４は、ステップＳ１２の処理後、ユーザの介在を必要とする一連の作業が完了したことをＷｅｂＡＰＩ提供処理部１３に通知する（ステップＳ１３）。そして、ＵＩ提供処理部１４は、前述したようにスクレイピング実行部１６から出力された経路一覧ＨＴＭＬページを入力してユーザ端末装置３側のＷｅｂブラウザにより経路一覧画面を表示させる。
【００７６】
ＷｅｂＡＰＩ提供処理部１３は、リクエストＩＤに対応する経路一覧ＸＭＬデータの取得をリクエスト管理部１５からに依頼する（ステップＳ１４）。
リクエスト管理部１５は、ＷｅｂＡＰＩ提供処理部１３からの依頼に従って、記憶装置１２に保存される経路一覧ＸＭＬデータのうち、ＵＩ提供処理部１４からのリクエストＩＤに対応する経路一覧ＸＭＬデータを取得して、ＷｅｂＡＰＩ提供処理部１３に返す。
ＷｅｂＡＰＩ提供処理部１３は、この経路一覧ＸＭＬデータを旅費精算アプリに返却する。旅費精算アプリは、この経路一覧ＸＭＬデータで示される経路の旅費を計算する。
【００７７】
以上のように、本発明の実施形態における情報処理システムでは、スクレイピングサーバ１が、一回のＷｅｂＡＰＩ呼び出しを起点とし、そのバックエンドで続いて発生する複数回のＷｅｂサイトアクセスを管理し、一連の複数Ｗｅｂサイトアクセスの最終結果からデータを抜き出してＷｅｂＡＰＩ返却値として返す。このシステムは、その際、一連のＷｅｂサイトアクセスにユーザが直接介在できるように、ＷｅｂサイトのＵＩを元にユーザ向けＵＩを提供する。
【００７８】
よって、一回のＷｅｂＡＰＩ呼出／応答と、ＷｅｂサイトのＵＩを用いたユーザの介在とを非同期に連携して実行できる。また、ユーザの介在が必要なＷｅｂサイトをスクレイピングの対象とした場合、ＷｅｂＡＰＩをシンプルな入出力として定義できる。
【００７９】
また、このように、ユーザの介在が必要なＷｅｂＡＰＩの実行において、ＷｅｂＡＰＩを呼び出すアプリケーションを介さずに、別の手段を使ってユーザを介在させることにより、ＷｅｂＡＰＩを呼び出すユーザ端末装置３側のアプリケーションからは、ユーザによる複数回のＷｅｂサイトアクセスという“ユーザの介在”は隠蔽されることになる。
【００８０】
さらに、ＷｅｂＡＰＩを利用したマッシュアップアプリケーションの開発時には、ユーザが介在するためのＵＩとして既存Ｗｅｂサイトを流用することができる。ＷｅｂＡＰＩを利用するマッシュアップアプリケーション側では、ユーザが介在するためのＵＩを別途用意する必要はない。つまり、ＷｅｂＡＰＩやマッシュアップアプリケーションの開発が容易になる。
【００８１】
なお、この発明は前記実施形態そのままに限定されるものではなく実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を省略してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【００８２】
なお、上記実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。
【００８３】
また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。
【００８４】
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が上記実施形態を実現するための各処理の一部を実行しても良い。
【００８５】
さらに、本発明における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。
【００８６】
また、記憶媒体は１つに限らず、複数の媒体から上記実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。
【００８７】
尚、本発明におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。
【００８８】
また、本発明におけるコンピュータとは、パーソナルコンピュータに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
【符号の説明】
【００８９】
１…スクレイピングサーバ、２…Ｗｅｂサーバ、３…ユーザ端末装置、１１，３１…制御部、１２，３２…記憶装置、１３…ＷｅｂＡＰＩ提供処理部、１４…ＵＩ（ユーザインタフェース）提供処理部、１５…リクエスト管理部、１６…スクレイピング実行部、１７，３５…通信インタフェース、１８，３６…バス、２１…リクエスト管理テーブル格納部、２２…スクレイピングルールテーブル格納部、３３…入力装置、３４…表示装置、４１…アプリケーション格納部、４２…Ｗｅｂブラウザ格納部。
【技術分野】
【０００１】
本発明は、ユーザ端末装置からのリクエストにしたがってＷｅｂアプリケーションのサービスを提供する情報処理装置に関する。
【背景技術】
【０００２】
従来、Ｗｅｂサイトの機能をシステム向けにＡＰＩ（アプリケーションプログラミングインタフェース：Application Programming Interface）として提供する技術（以下、ＷｅｂＡＰＩと称する）や、複数のＷｅｂサイトの機能やＷｅｂＡＰＩを組み合わせて新たなサービスを提供する技術（マッシュアップなどと呼ばれる）が成熟してきた。
【０００３】
前述した、Ｗｅｂサイトの機能を提供する技術としては、例えば特許文献１に開示されるように、複数のＷｅｂアプリケーションを実行する場合に、汎用Ｗｅｂブラウザを用いて、前段の処理結果を後段のＷｅｂアプリケーションに引き継ぐものがある。
【０００４】
また、Ｗｅｂサイトの機能を提供する他の技術としては、例えば、Ｗｅｂサイト提供者自らシステム向けにＡＰＩを提供する技術が挙げられ、また、Ｗｅｂサイト画面からデータを抜き出してシステム向けのＡＰＩ化を行なうスクレイピング（scraping）ライブラリや環境が挙げられ、また、システム向けＡＰＩを組み合わせて新たなサービスを構築するマッシュアップ環境が挙げられる。
【０００５】
ところで、Ｗｅｂサイトが提供するサービスには、利用時にユーザの介在を必要とするものもある。例として、ＷｅｂＡＰＩが、オンライン書店での検索を行なってユーザの好む本の情報を取得する事や、経路探索用のＷｅｂサイトがユーザからの選択にしたがって適切な乗車駅／下車駅を特定して経路を探索する事が挙げられる。
【０００６】
このように、ＷｅｂサイトをスクレイピングしてＷｅｂＡＰＩ化を行なう際には、ＷｅｂＡＰＩの実行時にユーザが介在する仕組みを考慮する必要がある。以下、この仕組みについて経路探索Ｗｅｂサイトを例として説明を行なう。
【０００７】
図１０は、従来の経路探索Ｗｅｂサイトの画面表示例を示す図である。
図１０に示した経路探索Ｗｅｂサイトでは、駅名入力画面にてユーザがユーザ端末装置を用いて乗車駅名と下車駅名を入力して画面上の検索ボタンを押すと、経路一覧画面にて乗車駅から下車駅までの乗り換え経路が提示される。
【０００８】
ただし駅名入力画面で入力した駅名に曖昧性があると、この駅名入力画面が駅名選択画面に遷移し、ユーザが意図する駅名を選択するよう促す。
【０００９】
図１０に示した例では、駅名入力画面で入力された「府中」という駅名に対して「府中（東京）」、「府中（広島）」、「府中（徳島）」などが駅名選択画面に表示される。ユーザはこの駅名一覧から意図する駅を選択することで、適切な経路を経路一覧画面で得ることになる。
このような、ユーザの介在を必要とするＷｅｂサイトをＷｅｂＡＰＩ化するためには、従来では以下に示す２つの手法が挙げられる。
第１の手法は細分化である。この細分化とは、ユーザの介在を必要としない細かい単位の複数個のＷｅｂＡＰＩを用意し、それらをマッシュアップする側であるユーザ側のアプリケーションで組合せて使う事である。
【００１０】
第２の手法は自動化である。この自動化とは、ユーザの介在が不要となる様に、ユーザが従来介在していた部分の処理の実行を自動化する事である。
【００１１】
図１１は、従来のＷｅｂＡＰＩの利用形態の第１の例を示す図である。
図１１に示した手法は、前述した細分化の手法（第１の手法）であり、ＷｅｂＡＰＩとして、駅名一覧取得ＡＰＩおよび経路探索ＡＰＩを用いる。
【００１２】
駅名一覧取得ＡＰＩは、ユーザ端末装置側のアプリケーションプログラム（以下、アプリケーションと称する）である旅費精算アプリケーション（以下、旅費精算アプリと称する）を介した文字列を入力として、その文字列にマッチする駅名一覧を経路探索Ｗｅｂサイトから駅名候補として取得して旅費精算アプリに返す。
【００１３】
また、経路探索ＡＰＩは、前述した駅名一覧から旅費精算アプリを介して選択された乗車駅名と下車駅名、つまり乗車駅と下車駅をそれぞれ一意に特定できる情報を入力として、これらの乗車駅から下車駅までの乗り換え経路を経路探索Ｗｅｂサイトから取得して旅費精算アプリに返す。
【００１４】
図１２は、従来のＷｅｂＡＰＩの利用形態の第２の例を示す図である。
図１２に示した手法は、前述した自動化の手法（第２の手法）であり、ＷｅｂＡＰＩとして経路探索ＡＰＩを用いる。
【００１５】
この経路探索ＷｅｂＡＰＩは、ユーザ端末装置側の旅費精算アプリを介して入力された乗車駅と下車駅のそれぞれの文字列にマッチした駅名一覧を経路探索Ｗｅｂサイトから取得する。そして、経路探索ＷｅｂＡＰＩは、この駅名一覧からユーザが意図する駅を推測することで自動的に選択し、この選択した乗車駅から下車駅までの乗り換え経路を経路探索Ｗｅｂサイトから取得して旅費精算アプリに返す。
【先行技術文献】
【特許文献】
【００１６】
【特許文献１】特開２００６−１７８８８７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１７】
前述したように、ユーザの介在を必要とするＷｅｂサイトをＷｅｂＡＰＩ化するための細分化の方法では、ＷｅｂＡＰＩは、機能が細切れのサブルーチンＷｅｂＡＰＩ群に分かれて提供されるため、システムでの利用方法が複雑になる。
【００１８】
図１１に示した例では、経路探索のためのＡＰＩの他に、駅名一覧取得のためのＡＰＩという本質的ではないＡＰＩが別途必要となってしまう。
また、この細分化の手法では、ユーザが介在するためのユーザインタフェース（以下、ＵＩと称する）をマッシュアップアプリ側のＵＩとして別途開発しなければならない。図１１に示した例では、駅名一覧から駅を一つ選択するためのＵＩが別途必要になる。
【００１９】
また、前述した自動化の手法では、ユーザの介在を要していた処理を自動化するためのロジックがサーバ側に必要となる。図１１に示した例では、ユーザの介在部分、つまり駅名一覧におけるユーザが意図する駅名はユーザの現在位置や嗜好など様々な要因に関係しているので、駅名一覧からユーザの意図する駅をサーバ側で適切に推測することは容易ではない。
【００２０】
また、サーバ側でユーザの意図する駅名の推測を誤るとユーザの意図に沿えなくなる可能性がある。例えば、「駅名一覧の中から一番上の駅を選択する」というような単純な規則では、必ずしもユーザの意図にそぐわない可能性がある。
【００２１】
以上説明したように、従来技術における、ユーザの介在を必要とするＷｅｂサイトをＷｅｂＡＰＩ化するため技術では、ＷｅｂＡＰＩの複雑化に伴って、これを用いるためのシステムが複雑になったり、ユーザの意図に沿えない処理を行なったりしてしまうといった課題がある。
【００２２】
そこで、本発明の目的は、ユーザの介在が必要なＷｅｂサイトのＷｅｂＡＰＩ化を容易に行なうことが可能になる情報処理装置を提供することにある。
【課題を解決するための手段】
【００２３】
すなわち、本発明に係わる情報処理装置は、ユーザ側の端末装置で実行されるユーザ側アプリケーションからのリクエストがなされた場合に、Ｗｅｂサーバにより構築されるＷｅｂサイトへのアクセスを行なうことで、前記リクエストを受けて、データ加工手段による処理結果を返却値データとして前記ユーザ側アプリケーションに出力するアプリケーションプログラミングインタフェース手段と、前記ユーザ側アプリケーションからのリクエストにしたがって前記アプリケーションプログラミングインタフェース手段により前記Ｗｅｂサイトから取得した中間値データを保持するデータ保持手段と、前記中間値データを前記ユーザ側アプリケーションを介さずに前記端末装置に表示する表示手段と、前記表示手段による表示結果に対する入力を受け付ける入力手段と、前記入力手段による入力結果にしたがって、前記データ保持手段により保持される前記中間値データをもとに前記Ｗｅｂサイトへのアクセスを行なうことで、当該Ｗｅｂサイトへのさらなるアクセスを要しないデータを取得するデータ取得手段とを備え、前記データ加工手段は、前記データ取得手段により取得したデータの形式を前記ユーザ側アプリケーションによる処理に適合する形式に加工することを特徴とする。
【発明の効果】
【００２４】
本発明によれば、ユーザの介在が必要なＷｅｂサイトのＷｅｂＡＰＩ化を容易に行なうことができる。
【図面の簡単な説明】
【００２５】
【図１】本発明の実施形態における情報処理システムの構成例を示す図。
【図２】本発明の実施形態における情報処理システムのスクレイピングサーバの構成例を示すブロック図。
【図３】本発明の実施形態における情報処理システムのユーザ端末装置の構成例を示すブロック図。
【図４】本発明の実施形態における情報処理システムのスクレイピングサーバの機能を示す図。
【図５】本発明の実施形態における情報処理システムのスクレイピングサーバのリクエスト管理テーブルの構成例を表形式で示す図。
【図６】本発明の実施形態における情報処理システムのスクレイピングサーバのスクレイピングルールテーブルの構成例を表形式で示す図。
【図７】本発明の実施形態における情報処理システムのＷｅｂサーバが提供する経路探索サイトの画面遷移例を示す図。
【図８】本発明の実施形態における情報処理システムによる処理動作の概要を示す図。
【図９】本発明の実施形態における情報処理システムによる処理動作の一例を示すシーケンス図。
【図１０】従来の経路探索Ｗｅｂサイトの画面表示例を示す図。
【図１１】従来のＷｅｂＡＰＩの利用形態の第１の例を示す図。
【図１２】従来のＷｅｂＡＰＩの利用形態の第２の例を示す図。
【発明を実施するための形態】
【００２６】
以下図面により本発明の実施形態について説明する。
図１は、本発明の実施形態における情報処理システムの構成例を示す図である。
図１に示すように、本発明の実施形態における情報処理システムは、スクレイピングサーバ１、Ｗｅｂサーバ２およびユーザ端末装置３を有する。
【００２７】
スクレイピングサーバ１およびＷｅｂサーバ２はネットワークを介して接続される。Ｗｅｂサーバ２およびユーザ端末装置３は図１に示したようなローカル接続もしくはネットワーク経由で接続される。
【００２８】
スクレイピングサーバ１は、ユーザの介在を必要とするＷｅｂＡＰＩを提供し、さらに当該ＷｅｂＡＰＩの実行にユーザが介在するためのＵＩを提供する。
Ｗｅｂサーバ２は、ユーザからのリクエストに応じたＷｅｂアプリケーションのサービス提供のためのＷｅｂサイトが構築されるサーバである。
また、ユーザ端末装置３は、例えばパーソナルコンピュータであり、Ｗｅｂアプリケーションのサービスを利用するためのアプリケーションを格納し、これを実行する。図１ではユーザ端末装置３は１台のみ図示しているが、この台数は限定されない。
【００２９】
スクレイピングサーバ１は、ユーザ端末装置３側のアプリケーションからの一回のＷｅｂＡＰＩの呼び出しを起点とし、この呼び出しに続けてバックエンドで発生する、Ｗｅｂサーバ２側のＷｅｂサイトへの複数回のアクセスを管理し、これら一連のＷｅｂサイトアクセスの最終結果から必要なデータを抜き出した値をＷｅｂＡＰＩの返却値データとしてアプリケーションに返す。
【００３０】
その際、スクレイピングサーバ１は、一連のＷｅｂサイトアクセスにユーザが直接介在できるように、ＷｅｂサイトのＵＩを元にユーザ向けＵＩをユーザ端末装置３側に提供する。これにより、ユーザ端末装置３側のアプリケーションからの一回のＷｅｂＡＰＩ呼出／応答と、ＷｅｂサイトのＵＩを用いたユーザの介在とを非同期に連携して実行する。
【００３１】
図２は、本発明の実施形態における情報処理システムのスクレイピングサーバの構成例を示すブロック図である。
図２に示すように、スクレイピングサーバ１は、装置全体の処理動作を司る制御部１１、記憶装置１２、ＷｅｂＡＰＩ提供処理部１３、ＵＩ提供処理部１４、リクエスト管理部１５、スクレイピング実行部１６および通信インタフェース１７を備え、それぞれがバス１８を介して接続される。
【００３２】
記憶装置１２は、ハードディスクドライブや不揮発性メモリなどの記憶媒体であり、ＷｅｂＡＰＩ提供処理部１３、ＵＩ提供処理部１４、リクエスト管理部１５、スクレイピング実行部１６による処理動作のためのプログラムを記憶する他、リクエスト管理テーブル格納部２１およびスクレイピングルールテーブル格納部２２を有する。
【００３３】
ＷｅｂＡＰＩ提供処理部１３は、ユーザ端末装置３側のアプリケーションからのＷｅｂＡＰＩへのリクエストを受け付けるシステム向けインタフェース（アプリケーションプログラミングインタフェース手段）として機能する。例えば、ＷｅｂＡＰＩ提供処理部１３は、ＵＲＬ形式のリクエストをＨＴＴＰプロトコルで受け付け、ＸＭＬ形式の返却値データをリクエスト元に返す。ただし、リクエストの入出力はＵＲＬ形式やＸＭＬ形式に限定されない。
【００３４】
ＵＩ提供処理部１４は、ＷｅｂＡＰＩの実行にユーザが介在するためのＵＩとして機能する（データ加工手段の一例）。例えば、ＵＩ提供処理部１４は、ユーザ端末装置３側のＷｅｂブラウザ上にＨＴＭＬページを表示する事でユーザに情報を提示したり、ユーザ端末装置３により入力された情報を得たりする。ただし、ＵＩの実現形態はＷｅｂブラウザに限定されない。
【００３５】
リクエスト管理部１５は、ユーザ端末装置３側のアプリケーションからのＷｅｂＡＰＩへのリクエストによって開始されたＷｅｂサイトアクセスの状態をリクエストごとに区分して管理する。リクエスト管理部１５を介して、アプリケーションからの一回のＷｅｂＡＰＩ呼び出しを起点として、その後、ユーザによる複数回のＷｅｂサイトアクセスが発生する場合がある。
【００３６】
また、リクエスト管理部１５は、ユーザの介在が必要なＷｅｂページであるＨＴＭＬページと、ユーザの介在によってＷｅｂサーバ２側のＷｅｂサイトから得られた最終的な返却値とを記憶装置１２に保持する処理を行なう。
【００３７】
スクレイピング実行部１６は、Ｗｅｂサイトから返却されたＷｅｂページを所定のルールにしたがって加工する。このルールは後述するスクレイピングルールテーブルで定義される。
通信インタフェース１７は、Ｗｅｂサーバ２やユーザ端末装置３との間の入出力を行なう。
【００３８】
スクレイピングサーバ１は、ハードウェア構成、またはハードウェア構成とソフトウェア構成との組合せにより実現可能である。後者の場合、ソフトウェア構成は、予めコンピュータ読み取り可能な記憶媒体またはネットワークから得られたプログラムがコンピュータにインストールされることにより、スクレイピングサーバ１としての各機能が実現される。
【００３９】
図３は、本発明の実施形態における情報処理システムのユーザ端末装置の構成例を示すブロック図である。
図３に示すように、ユーザ端末装置３は、装置全体の処理動作を司る制御部３１、記憶装置３２、キーボードやマウスなどの入力装置３３、液晶ディスプレイなどの表示装置３４および通信インタフェース３５を備え、それぞれがバス３６を介して接続される。
記憶装置３２は、ハードディスクドライブや不揮発性メモリなどの記憶媒体であり、アプリケーションを格納するアプリケーション格納部４１やＷｅｂブラウザを格納するＷｅｂブラウザ格納部４２を有する。
【００４０】
図４は、本発明の実施形態における情報処理システムのスクレイピングサーバの機能を示す図である。
図４に示すように、本実施形態では、ユーザ側への提供対象のサービスは経路探索であり、ユーザ端末装置３側のマッシュアップアプリとして旅費精算アプリを用い、Ｗｅｂサーバ２側のＷｅｂサイトとして経路探索Ｗｅｂサイトを用いる。また、ユーザ端末装置３では、ＷｅｂＡＰＩ実行時にユーザが介在するためＵＩとして、マッシュアップアプリとは別個のＷｅｂブラウザを用いる。
【００４１】
図５は、本発明の実施形態における情報処理システムのスクレイピングサーバのリクエスト管理テーブルの構成例を表形式で示す図である。
図６は、本発明の実施形態における情報処理システムのスクレイピングサーバのスクレイピングルールテーブルの構成例を表形式で示す図である。
図７は、本発明の実施形態における情報処理システムのＷｅｂサーバが提供する経路探索サイトの画面遷移例を示す図である。
スクレイピングサーバ１の記憶装置１２のリクエスト管理テーブル格納部２１には、図５に示した形式のリクエスト管理テーブルが格納される。このリクエスト管理テーブルは、ユーザ端末装置３側のアプリケーションからのＷｅｂＡＰＩへのリクエストによって開始されたＷｅｂサイトアクセスの状態をリクエスト管理部１５により管理するための情報を記憶するテーブルである。
【００４２】
また、スクレイピングサーバ１の記憶装置１２のスクレイピングルールテーブル格納部２２には、図６に示した形式のスクレイピングルールテーブルが格納される。このテーブルは、スクレイピング実行部１６による、Ｗｅｂサイトから返却されたデータの加工方法を定義するためのテーブルである。
【００４３】
図７に示すように、経路探索Ｗｅｂサイトの状態は、「状態０」、「状態１」および「状態２」に区分される。
この「状態０」はＷｅｂブラウザの画面の初期状態であり、乗車駅名と下車駅名を入力する駅名入力画面を指す。また、「状態１」は駅名選択画面を指し、「状態２」は経路一覧画面を指す。
【００４４】
本実施形態では、「状態０」である駅名入力画面にてユーザ端末装置３により乗車駅「府中」と下車駅「横浜」とを入力して画面上の検索ボタンを押すと、ユーザが意図する駅名を選択するための「状態１」に遷移する。
【００４５】
図７に示した例では、「状態０」の駅名入力画面にて入力された「府中」という駅名に対して「府中（東京）」、「府中（広島）」、「府中（徳島）」といった選択肢が駅名選択画面に提示される。また、「状態０」の駅名入力画面にて入力された「横浜」という駅名に対して「横浜」、「陸奥横浜」といった選択肢が駅名選択画面に提示される。
【００４６】
この駅名選択画面上でユーザが意図する駅名を選択すると、「状態２」に遷移して乗車駅から下車駅までの経路が表示されることになる。図７に示した例では、駅名選択画面上で乗車駅名として「府中（東京）」が選択されて、下車駅名として「横浜」が選択されたことにより、途中駅である「新宿」を含む経路が経路一覧画面に表示される。
【００４７】
図５に示すように、リクエスト管理テーブルは、リクエストごとに「リクエストＩＤ」、「状態」、「最初の画面」および「返却値」を保持する。
リクエスト管理テーブル上の「リクエストＩＤ」は、ユーザ端末装置３側からのＷｅｂＡＰＩへのリクエストを一意に識別するためのデータである。つまり、リクエストＩＤ（リクエスト識別情報）が、リクエスト管理テーブルで各リクエストに対して付与されることになる（リクエスト識別情報付与手段の一例）。
【００４８】
リクエスト管理テーブル上の「状態」は、前述したリクエストに伴うＷｅｂサイトアクセスの状態を示す。図５に示したリクエスト管理テーブルは前述した経路探索に適合したテーブルであり、このテーブル上の「状態」が取り得る値は、図７に示した状態遷移例における駅名入力画面である「状態１」、経路一覧画面である「状態２」、および「終了」である。
【００４９】
リクエスト管理テーブル上の「最初の画面」は、ユーザの介在が必要な最初のＷｅｂページの画面の種別を示す。本実施形態では、この画面にはスクレイピング実行部１６によって前述したリクエストＩＤが埋め込まれ、当該画面がスクレイピングサーバ１の記憶装置１２に保存される。
【００５０】
また、リクエスト管理テーブル上の「返却値」は、ＷｅｂＡＰＩの返却値としてアプリケーションに返す返却値データである。この返却値データは、ユーザ端末装置３によるＷｅｂページ操作を経て得られた最終的なＷｅｂページから、スクレイピング実行部１６によって必要なデータを抜き取ることで作成され、スクレイピングサーバ１の記憶装置１２に保存される。
また、図６に示すように、スクレイピングルールテーブル上のルールは、ユーザ向けルールとＷｅｂＡＰＩ向けルールとに区分され、図７に示した状態遷移の各状態に対して、前述したユーザ向けルールとＷｅｂＡＰＩ向けルールとがそれぞれ対応付けられる。ルールの定義方法には例えばXSLTやXQueryといった既存の言語を用いることができる。
【００５１】
スクレイピングルールテーブル上のＷｅｂＡＰＩ向けルールとは、ユーザの介在によってＷｅｂサイトから最終的に得られたＷｅｂページからアプリケーションへの出力に必要なデータを抜き取ることで返却値データを作成するためのルールである。
【００５２】
図６に示したテーブルは前述した経路探索に適合したテーブルであり、「状態２」に対応するＷｅｂＡＰＩ向けルールとしてルール１「システム向けに、経路一覧画面から経路データを抜き出し、ＸＭＬ形式に変換する」が定義され、「状態１」に対応するユーザ向けルールとしてルール２「ユーザ向けに、駅名選択画面にリクエストＩＤを埋め込む」が定義され、「状態２」に対応するユーザ向けルールとしてルール３「ユーザ向けに、経路一覧画面を読みやすく変更する」が定義される。
【００５３】
次に、以上示した構成の情報処理システムの動作について説明する。
図８は、本発明の実施形態における情報処理システムによる処理動作の概要を示す図である。
図９は、本発明の実施形態における情報処理システムによる処理動作の一例を示すシーケンス図である。
図８および図９は、経路探索のためのメッセージの流れを具体的に示すものである。ここでは、本発明の理解を容易にするために、図８と図９にて同じメッセージシーケンスを異なる表現形式で示している。図８は、図４にメッセージの流れを重ねた図である。
【００５４】
この情報処理システムは、ユーザ端末装置３側の旅費精算アプリを用いてユーザが乗車駅名と下車駅名を入力すると経路探索ＷｅｂＡＰＩを呼び出し、移動経路を補完する。
本実施形態では説明を単純にするため移動経路だけを考慮するが、移動経路だけでなく交通費を補完するなど様々な応用も考えられる。
【００５５】
以下、経路探索のためのメッセージの流れを順に説明する。
まず、ユーザ端末装置３の入力装置３３への所定の操作がなされると、記憶装置１２のアプリケーション格納部４１に格納される旅費精算アプリが起動する。この旅費精算アプリはＷｅｂブラウザを起動して駅名入力画面を表示装置３４に表示させる（表示手段の一例）。
【００５６】
この駅名入力画面で、ユーザが入力装置３３により所望の乗車駅名および下車駅名を入力すると、旅費精算アプリは、スクレイピングサーバ１のＷｅｂＡＰＩ提供処理部１３を介して経路探索ＷｅｂＡＰＩを呼び出す。ここでは、乗車駅名として「府中」が入力されて、下車駅名として「横浜」が入力されたとする。
【００５７】
この際、旅費精算アプリは、「リクエストＩＤ」を発行し、このリクエストＩＤおよび前述した「乗車駅」、「下車駅」を引数としてＷｅｂＡＰＩ提供処理部１３に渡すことで経路探索を要求する（ステップＳ１）。
リクエストＩＤは、ＡＰＩの呼び出しを一意に識別するためのデータである。本実施形態では、呼び出し側であるユーザ端末装置３でＵＵＩＤ（Universally Unique Identifier）を作成してスクレイピングサーバ１側に渡している。このリクエストＩＤはスクレイピングサーバ１側で発行して呼び出し側に提示するようにしてもよい。
【００５８】
ＷｅｂＡＰＩ提供処理部１３は、旅費精算アプリから渡された「乗車駅」、「下車駅」および「リクエストＩＤ」をもとに、乗車駅から下車駅までの経路を取得するために、Ｗｅｂサーバ２側の経路探索Ｗｅｂサイトへの経路探索のためのアクセスを行なう（ステップＳ２）。
【００５９】
経路探索Ｗｅｂサイトは、旅費精算アプリから渡された「乗車駅」および「下車駅」の駅名候補が示されて当該駅名候補の識別番号が含まれるページデータである駅名選択ＨＴＭＬページデータをＷｅｂＡＰＩ提供処理部１３に返す。
【００６０】
ＷｅｂＡＰＩ提供処理部１３は、駅名選択ＨＴＭＬページデータを経路探索Ｗｅｂサイトから取得すると、この駅名選択ＨＴＭＬページデータの解析（加工）をスクレイピング実行部１６に依頼する（ステップＳ３）。
【００６１】
この駅名選択ＨＴＭＬページデータの状態は、図６に示したスプレイピングルールテーブル上の「状態１」に該当する。この場合、スクレイピング実行部１６は、ステップＳ３の処理による依頼を受けると、図６に示したスプレイピングルールテーブル上の「状態１」に対応するユーザ向けルールの「ルール２」にしたがって、駅名選択ＨＴＭＬページデータに対し、ステップＳ１の処理により旅費精算アプリから渡されたリクエストＩＤを埋め込むことで、「リクエストＩＤ入り駅名選択ＨＴＭＬページ」を作成する。
【００６２】
このようにリクエストＩＤをページデータに埋め込むことにより、この後のユーザの介在によるＷｅｂサイトへの一連のアクセスが前述した最初のＷｅｂＡＰＩ呼び出しに対応付けられる。よって、異なるユーザのそれぞれが用いるユーザ端末装置３からのリクエストがなされた場合でも、それぞれのリクエストについてのスクレイピングサーバ１による経路探索処理を行なうことができる。
【００６３】
ＷｅｂＡＰＩ提供処理部１３は、スクレイピング実行部１６による加工後のデータである「リクエストＩＤ入り駅名選択ＨＴＭＬページ」の保存をリクエスト管理部１５に依頼する（ステップＳ４）。すると、リクエスト管理部１５は、この「リクエストＩＤ入り駅名選択ＨＴＭＬページ」を記憶装置１２に保存する。
【００６４】
また、ステップＳ１の処理後、ユーザ端末装置３側の旅費精算アプリは、駅名選択画面を起動するために、リクエストＩＤを含むＵＲＬを引数として、ＷｅｂＡＰＩ実行時にユーザが介在するための駅名選択ＵＩであるＷｅｂブラウザを起動する（ステップＳ５）。
【００６５】
すると、このＷｅｂブラウザは、スクレイピングサーバ１のＵＩ提供処理部１４に対して、ステップＳ１の処理で説明したリクエストＩＤをキーとして、このリクエストＩＤを含むＵＲＬ、つまり駅名選択画面用のＵＲＬの取得をスクレイピングサーバ１のＵＩ提供処理部１４に依頼する（ステップＳ６）。
【００６６】
ＵＩ提供処理部１４は、ＷｅｂブラウザからのリクエストＩＤをキーとして、リクエスト管理部１５に対し、記憶装置１２に保存される「リクエストＩＤ入り駅名選択ＨＴＭＬページ」の取得を依頼する（ステップＳ７）。
【００６７】
リクエスト管理部１５は、この依頼にしたがって、記憶装置１２に保存されるリクエストＩＤ入り駅名選択ＨＴＭＬページのうち、ＵＩ提供処理部１４からのリクエストＩＤに対応するページを取得する。このページは、ＵＩ提供処理部１４を介し、リクエスト元のユーザ端末装置３側のＷｅｂブラウザにより駅名選択画面として表示装置３４に表示される（表示手段の一例）。
【００６８】
ユーザは、Ｗｅｂブラウザ上の駅名選択画面に表示される乗車駅名および下車駅名の候補のうち、意図する駅名を入力装置３３への操作により選択する（ステップＳ８）。ここでは、乗車駅名として「府中（東京）」が選択され、下車駅名として「横浜」が選択されたとする。
【００６９】
すると、Ｗｅｂブラウザは、ステップＳ１の処理で説明したリクエストＩＤに加え、駅名選択画面で選択された駅名をＵＩ提供処理部１４に送信する（ステップＳ９）。
ＵＩ提供処理部１４は、ＷｅｂブラウザからのリクエストＩＤ、選択済みの乗車駅名と下車駅名を受信すると、当該選択済みの乗車駅名及び下車駅名をキーとして、Ｗｅｂサーバ２側の経路探索Ｗｅｂサイトへの経路探索のためのアクセスを行ない（ステップＳ１０）、この経路探索Ｗｅｂサイトから、前述した乗車駅から下車駅までの経路が示される経路一覧ＨＴＭＬページを取得する。
【００７０】
この経路一覧ＨＴＭＬページは、経路一覧ＨＴＭＬページを経路探索Ｗｅｂサイトからの最終的なデータ、つまり前述したリクエストにしたがって経路探索Ｗｅｂサイトへのさらなるアクセスを要しないデータであり、前述したリクエストＩＤが含まれる。ここでは、乗車駅「府中（東京）」から下車駅「横浜」までの途中駅を含む「府中（東京）→新宿→横浜」が経路として示されるとする。
【００７１】
そして、ＵＩ提供処理部１４は、経路探索Ｗｅｂサイトから取得した経路一覧ＨＴＭＬページの解析、つまりデータ加工をスクレイピング実行部１６に依頼する（ステップＳ１１）。
【００７２】
経路一覧ＨＴＭＬページが生成された状態は、図６に示すスクレイピングテーブルの「状態２」に該当する。よって、スクレイピング実行部１６は、ＵＩ提供処理部１４からの依頼に従って、スクレイピングルールテーブル格納部２２に格納される図６に示すスクレイピングルールのうち、「状態２」に対応するＷｅｂＡＰＩ向けルールである「システム向けに、経路一覧画面から経路データを抜き出し、ＸＭＬ形式に変換する」にしたがって、前述した経路一覧ＨＴＭＬページから旅費精算アプリに必要な経路データを抜き取り、旅費精算アプリによる処理に適合した形式であるＸＭＬ形式の経路一覧ＸＭＬデータを生成する。スクレイピング実行部１６は、この生成した経路一覧ＸＭＬデータをＵＩ提供処理部１４に出力する。
【００７３】
また、スクレイピング実行部１６は、スクレイピングルールテーブル格納部２２に格納される図６に示すスクレイピングルールのうち、「状態２」に対応するユーザ向けルールである「ユーザ向けに、経路一覧画面を読みやすく変更する」にしたがって、経路一覧ＨＴＭＬページにおける文字のフォントやレイアウトをＷｅｂブラウザでの表示に適合した形式に変更してＵＩ提供処理部１４に出力する。
【００７４】
ＵＩ提供処理部１４は、スクレイピング実行部１６からの経路一覧ＸＭＬデータを入力すると、この経路一覧ＸＭＬデータの保存をリクエスト管理部１５に依頼する（ステップＳ１２）。リクエスト管理部１５は、この依頼にしたがって経路一覧ＸＭＬデータを記憶装置１２に保存する。
【００７５】
ＵＩ提供処理部１４は、ステップＳ１２の処理後、ユーザの介在を必要とする一連の作業が完了したことをＷｅｂＡＰＩ提供処理部１３に通知する（ステップＳ１３）。そして、ＵＩ提供処理部１４は、前述したようにスクレイピング実行部１６から出力された経路一覧ＨＴＭＬページを入力してユーザ端末装置３側のＷｅｂブラウザにより経路一覧画面を表示させる。
【００７６】
ＷｅｂＡＰＩ提供処理部１３は、リクエストＩＤに対応する経路一覧ＸＭＬデータの取得をリクエスト管理部１５からに依頼する（ステップＳ１４）。
リクエスト管理部１５は、ＷｅｂＡＰＩ提供処理部１３からの依頼に従って、記憶装置１２に保存される経路一覧ＸＭＬデータのうち、ＵＩ提供処理部１４からのリクエストＩＤに対応する経路一覧ＸＭＬデータを取得して、ＷｅｂＡＰＩ提供処理部１３に返す。
ＷｅｂＡＰＩ提供処理部１３は、この経路一覧ＸＭＬデータを旅費精算アプリに返却する。旅費精算アプリは、この経路一覧ＸＭＬデータで示される経路の旅費を計算する。
【００７７】
以上のように、本発明の実施形態における情報処理システムでは、スクレイピングサーバ１が、一回のＷｅｂＡＰＩ呼び出しを起点とし、そのバックエンドで続いて発生する複数回のＷｅｂサイトアクセスを管理し、一連の複数Ｗｅｂサイトアクセスの最終結果からデータを抜き出してＷｅｂＡＰＩ返却値として返す。このシステムは、その際、一連のＷｅｂサイトアクセスにユーザが直接介在できるように、ＷｅｂサイトのＵＩを元にユーザ向けＵＩを提供する。
【００７８】
よって、一回のＷｅｂＡＰＩ呼出／応答と、ＷｅｂサイトのＵＩを用いたユーザの介在とを非同期に連携して実行できる。また、ユーザの介在が必要なＷｅｂサイトをスクレイピングの対象とした場合、ＷｅｂＡＰＩをシンプルな入出力として定義できる。
【００７９】
また、このように、ユーザの介在が必要なＷｅｂＡＰＩの実行において、ＷｅｂＡＰＩを呼び出すアプリケーションを介さずに、別の手段を使ってユーザを介在させることにより、ＷｅｂＡＰＩを呼び出すユーザ端末装置３側のアプリケーションからは、ユーザによる複数回のＷｅｂサイトアクセスという“ユーザの介在”は隠蔽されることになる。
【００８０】
さらに、ＷｅｂＡＰＩを利用したマッシュアップアプリケーションの開発時には、ユーザが介在するためのＵＩとして既存Ｗｅｂサイトを流用することができる。ＷｅｂＡＰＩを利用するマッシュアップアプリケーション側では、ユーザが介在するためのＵＩを別途用意する必要はない。つまり、ＷｅｂＡＰＩやマッシュアップアプリケーションの開発が容易になる。
【００８１】
なお、この発明は前記実施形態そのままに限定されるものではなく実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を省略してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【００８２】
なお、上記実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。
【００８３】
また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。
【００８４】
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が上記実施形態を実現するための各処理の一部を実行しても良い。
【００８５】
さらに、本発明における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。
【００８６】
また、記憶媒体は１つに限らず、複数の媒体から上記実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。
【００８７】
尚、本発明におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。
【００８８】
また、本発明におけるコンピュータとは、パーソナルコンピュータに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
【符号の説明】
【００８９】
１…スクレイピングサーバ、２…Ｗｅｂサーバ、３…ユーザ端末装置、１１，３１…制御部、１２，３２…記憶装置、１３…ＷｅｂＡＰＩ提供処理部、１４…ＵＩ（ユーザインタフェース）提供処理部、１５…リクエスト管理部、１６…スクレイピング実行部、１７，３５…通信インタフェース、１８，３６…バス、２１…リクエスト管理テーブル格納部、２２…スクレイピングルールテーブル格納部、３３…入力装置、３４…表示装置、４１…アプリケーション格納部、４２…Ｗｅｂブラウザ格納部。
【特許請求の範囲】
【請求項１】
ユーザ側の端末装置で実行されるユーザ側アプリケーションからのリクエストがなされた場合に、Ｗｅｂサーバにより構築されるＷｅｂサイトへのアクセスを行なうことで、前記リクエストを受けて、データ加工手段による処理結果を返却値データとして前記ユーザ側アプリケーションに出力するアプリケーションプログラミングインタフェース手段と、
前記ユーザ側アプリケーションからのリクエストにしたがって前記アプリケーションプログラミングインタフェース手段により前記Ｗｅｂサイトから取得した中間値データを保持するデータ保持手段と、
前記中間値データを前記ユーザ側アプリケーションを介さずに前記端末装置に表示する表示手段と、
前記表示手段による表示結果に対する入力を受け付ける入力手段と、
前記入力手段による入力結果にしたがって、前記データ保持手段により保持される前記中間値データをもとに前記Ｗｅｂサイトへのアクセスを行なうことで、当該Ｗｅｂサイトへのさらなるアクセスを要しないデータを取得するデータ取得手段と
を備え、
前記データ加工手段は、前記データ取得手段により取得したデータの形式を前記ユーザ側アプリケーションによる処理に適合する形式に加工する
ことを特徴とする情報処理装置。
【請求項２】
前記ユーザ側アプリケーションからのリクエストには、当該リクエストを識別するリクエスト識別情報が含まれ、
当該リクエストにしたがって前記アプリケーションプログラミングインタフェース手段により前記Ｗｅｂサイトから取得した中間値データに当該リクエストに対応するリクエスト識別情報を付与するリクエスト識別情報付与手段をさらに備え、
前記データ保持手段は、
前記リクエスト識別情報付与手段による処理結果を保持し、
前記入力手段による入力内容には、当該入力に関わるリクエストに対応するリクエスト識別情報が含まれ、
前記データ取得手段は、
前記入力手段による入力結果にしたがって、前記データ保持手段による保持される中間値データのうち、前記入力内容に含まれる前記リクエスト識別情報に対応する中間値データをもとに前記Ｗｅｂサイトへのアクセスを行なうことで、当該Ｗｅｂサイトへのさらなるアクセスを要しないデータを取得する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項１】
ユーザ側の端末装置で実行されるユーザ側アプリケーションからのリクエストがなされた場合に、Ｗｅｂサーバにより構築されるＷｅｂサイトへのアクセスを行なうことで、前記リクエストを受けて、データ加工手段による処理結果を返却値データとして前記ユーザ側アプリケーションに出力するアプリケーションプログラミングインタフェース手段と、
前記ユーザ側アプリケーションからのリクエストにしたがって前記アプリケーションプログラミングインタフェース手段により前記Ｗｅｂサイトから取得した中間値データを保持するデータ保持手段と、
前記中間値データを前記ユーザ側アプリケーションを介さずに前記端末装置に表示する表示手段と、
前記表示手段による表示結果に対する入力を受け付ける入力手段と、
前記入力手段による入力結果にしたがって、前記データ保持手段により保持される前記中間値データをもとに前記Ｗｅｂサイトへのアクセスを行なうことで、当該Ｗｅｂサイトへのさらなるアクセスを要しないデータを取得するデータ取得手段と
を備え、
前記データ加工手段は、前記データ取得手段により取得したデータの形式を前記ユーザ側アプリケーションによる処理に適合する形式に加工する
ことを特徴とする情報処理装置。
【請求項２】
前記ユーザ側アプリケーションからのリクエストには、当該リクエストを識別するリクエスト識別情報が含まれ、
当該リクエストにしたがって前記アプリケーションプログラミングインタフェース手段により前記Ｗｅｂサイトから取得した中間値データに当該リクエストに対応するリクエスト識別情報を付与するリクエスト識別情報付与手段をさらに備え、
前記データ保持手段は、
前記リクエスト識別情報付与手段による処理結果を保持し、
前記入力手段による入力内容には、当該入力に関わるリクエストに対応するリクエスト識別情報が含まれ、
前記データ取得手段は、
前記入力手段による入力結果にしたがって、前記データ保持手段による保持される中間値データのうち、前記入力内容に含まれる前記リクエスト識別情報に対応する中間値データをもとに前記Ｗｅｂサイトへのアクセスを行なうことで、当該Ｗｅｂサイトへのさらなるアクセスを要しないデータを取得する
ことを特徴とする請求項１に記載の情報処理装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２０１１−８１５１０（Ｐ２０１１−８１５１０Ａ）
【公開日】平成２３年４月２１日（２０１１．４．２１）
【国際特許分類】
【出願番号】特願２００９−２３１８１５（Ｐ２００９−２３１８１５）
【出願日】平成２１年１０月５日（２００９．１０．５）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
【公開日】平成２３年４月２１日（２０１１．４．２１）
【国際特許分類】
【出願日】平成２１年１０月５日（２００９．１０．５）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
[ Back to top ]