JP5294885B2 - サービス中継装置、サービス中継方法、この方法を実行するためのプログラム - Google Patents

Description

本発明は、ユーザが利用するWeb上のサービスに連携する他のWeb上のサービスを提供する技術に関する。

近年、様々なサービスがWebを介して提供されている。これまで、パッケージ製品として提供されていた情報システムもWeb上のサービスとして提供されるようになってきている。そのWeb上でサービスを提供する一例として、Webアプリケーション（以下、Webアプリ）があり、多くはクライアントからのリクエストを受けて、その結果をHTML (HyperText Markup Language)形式でクライアントに返す。このHTMLには、スクリプト言語であるJavaScriptを埋め込むことも可能であり、Webアプリにクライアント側でも動作する機能を加えることができる。

このWebアプリを利用するために、プロキシを利用することがある。ここでのプロキシとは、クライアントとWebアプリの間でリクエストやレスポンスを中継する機能のことである。このプロキシにより、Webアプリが提供するコンテンツのフィルタリングや、利用履歴の取得ができる。また、Webアプリとクライアントの間で交換する情報であるリクエストやレスポンスの書き換えもできる。

WebアプリのようなWeb上のサービスは、様々な組織・団体・個人により提供される。クライアントは、公開されたWeb上のサービスを使うことができる。しかし、クライアントは、単一のサービスだけを利用しているわけではない。クライアントは、「あるサービスを利用した結果得られた出力を他のサービスの入力として利用する」というように、二つのサービスを連携させて利用することがある。ここで、以降、前者のサービスを連携元サービス、後者のサービスを連携先サービスと表現する。しかし、クライアントは、サービスを連携させるために複数の作業を手動で行わなければならない。これらの手間を省き、サービス同士を連携させて利用するのを容易にするには特別な技術が必要である。

サービス同士を連携させるには、連携元サービスを利用した結果として出力されたデータがどの連携先サービスに入力されているかを定義する必要がある。そこで、特定のWebアプリの出力を次に利用されるWebアプリの入力に挿入する技術として、特許文献１に記載の技術がある。

特許文献１に記載の技術では、Webアプリをサービスとし、クライアントが連携元サービスの出力と連携先サービスの入力の対応をサービス間の連携情報として定義する。クライアントは、このようなサービス間の連携情報を用いて、あるサービスと他のサービスとを連携させて利用している。

特開2006-178887号公報

しかしながら、特許文献１に記載の技術は、クライアント自らサービス間の連携情報を定義する必要があり、クライアントの負担が高いという問題点がある。

そこで、本発明では、上記の問題点に着目し、クライアントに負担をかけずに、クライアントが利用しているWebサービスと連携するWebサービスを提示できる技術を提供することを目的とする。

上記問題点を解決するための発明は、サービスを提供するサービス提供部と、サービスの提供を受けるクライアント部との間の入出力を中継する以下のサービス中継装置やサービス中継プログラムである。

このサービス中継装置は、
前記クライアント部からの入力情報を受け付けて、該入力情報をサービス提供部に渡す
と共に、該入力情報を受け付けた前記サービス提供部からの出力情報を受け付けて、該出
力情報を該クライアント部に渡す中継手段と、
前記中継手段が前記クライアント部から受け付けた入力情報であって、リファラＵＲＬ、当該入力情報を受け付けたリクエスト取得時刻、及び当該入力情報に含まれる文字列の情報であるリクエスト文字列情報を含む入力情報と、該中継手段が前記サービス提供部から受け付けた該入力情報に対する出力情報であって、当該出力情報を受け付けた時刻であるレスポンス取得時刻及び当該出力情報に含まれる文字列の情報であるレスポンス文字列情報を含む出力情報と、を前記クライアントからの入力順を示すｉｄ毎に連携付けて、入出力情報として収集する入出力情報収集手段と、
前記入出力情報収集手段により、前記入出力情報が記憶される入出力情報記憶手段と、
前記入出力情報記憶手段に記憶されている複数の前記入出力情報毎に、当該入出力情報の入力情報と他の入出力情報の出力情報との一致性を、予め定められたルールに従って調べて、該一致性があれば、該入力情報と該他の入出力情報とを連携付けるサービス連携情報を作成するサービス連携付け手段であって、前記レスポンス取得時刻が、前記ｉｄの値が所定の値の入出力情報である連携先サービス情報のリクエスト取得時刻より前の時刻の入出力情報を複数の前記入出力情報から抽出し、当該抽出された入出力情報のレスポンス文字列情報に前記連携先サービス情報のリクエスト文字列情報が含まれている場合に、前記連携先サービス情報のリファラＵＲＬと前記抽出された入出力情報のリファラＵＲＬとを連携づけるサービス連携付け手段と、
前記サービス連携付け手段により、前記サービス連携情報が記憶されるサービス連携情
報記憶手段と、
前記中継手段が前記サービス提供部からの出力情報を受け付けると、前記サービス連携
情報記憶手段に記憶されている前記サービス連携情報のうちで、該出力情報を連携付けて
いるサービス連携情報がある場合には、該サービス連携情報に基づいて該出力情報に連携
する連携サービス情報を取得し、該出力情報に該連携サービス情報を添付して、前記中継
手段により、該連携サービス情報が添付された該出力情報を前記クライアント部に渡させ
る連携サービス情報添付手段と、
を備えている。

また、サービス中継プログラムは、
サービスの提供を受けるクライアント部からの入力情報を受け付けて、該入力情報をサービスを提供するサービス提供部に渡す手順と、
前記入力情報を受け付けた前記サービス提供部からの出力情報を受け付ける手順と、
前記クライアント部から受け付けた入力情報であって、リファラＵＲＬ、当該入力情報を受け付けたリクエスト取得時刻、及び当該入力情報に含まれる文字列の情報であるリクエスト文字列情報を含む入力情報と、前記サービス提供部から受け付けた出力情報であって、当該出力情報を受け付けた時刻であるレスポンス取得時刻及び当該出力情報に含まれる文字列の情報であるレスポンス文字列情報を含む出力情報とを連携付けて入出力情報として、コンピュータの記憶手段に記憶する手順と、
前記記憶手段に記憶されている一以上の前記入出力情報毎に、当該入出力情報の入力情報と他の入出力情報の出力情報との一致性を、予め定められたルールに従って調べて、該一致性があれば、該入力情報と該他の入出力情報とを連携付けるサービス連携情報であって、前記レスポンス取得時刻が、前記ｉｄの値が所定の値の入出力情報である連携先サービス情報のリクエスト取得時刻より前の時刻の入出力情報を複数の前記入出力情報から抽出し、当該抽出された入出力情報のレスポンス文字列情報に前記連携先サービス情報のリクエスト文字列情報が含まれている場合に、前記連携先サービス情報のリファラＵＲＬと前記抽出された入出力情報のリファラＵＲＬとを連携づけるサービス連携情報を作成し、該サービス連携情報を前記記憶手段に記憶する手順と、
前記サービス提供部からの出力情報を受け付けると、前記記憶手段に記憶されている１以上の前記サービス連携情報のうちで、該出力情報を連携付けているサービス連携情報がある場合には、該サービス連携情報に基づいて該出力情報に連携する連携サービス情報を取得する手順と、
前記出力情報に前記取得した連携サービス情報を添付して、該連携サービス情報が添付された該出力情報を前記クライアント部に渡す手順と、
を前記コンピュータに実行させることを特徴とする。

以上の発明では、クライアント部とサービス提供部との間での入出力情報に基づいて、サービス同士を連携付けるサービス連携情報を作成し、このサービス連携情報に基づいて、サービス提供部からの出力情報に対する連携サービス情報を取得し、この連携サービス情報を出力情報に添付している。したがって、本発明によれば、クライアント自らサービス同士の連携情報を定義することなく、あるサービス情報（出力情報）に連携するサービス情報（連携サービス情報）を提供することができる。

以下、図面を参照しながら、本発明に係る実施形態について説明する。

「第一実施形態」
以下、本発明に係る第一実施形態について、図１〜図１１を用いて説明する。

図１に示すように、本実施形態の中継装置１００は、クライアント端末２００とサービス提供サーバ３００との間で動作する。サービス提供サーバ３００は、Webアプリ３０１の実行により、HTMLやXMLなどの構造化文書で表現されたWebページをサービスとして、クライアントに提供する。

中継装置１００は、クライアント端末２００からのリクエストをサーバ３００へ転送すると共に、サーバ３００からのレスポンスをクライアント端末２００へ転送する。この中継装置１００は、コンピュータであり、各種演算処理を実行するＣＰＵ１１０と、ハードディスクドライブ装置等の記憶装置１２０と、ＣＰＵ１１０のワークエリア等になるメモリ１３０と、ネットワークＮａを介してサーバ３００と通信するための通信装置１４０ａと、ネットワークＮｂを介してクライアント端末２００と通信するための通信装置１４０ｂと、を備えている。なお、ここでは、サーバ側とクライアント側とのそれぞれに通信装置１４０ａ，１４０ｂを設けているが、一つの通信装置でサーバ３００及びクライアント端末２００と通信するようにしてもよいことは言うまでもない。

ＣＰＵ１１０は、機能的に、クライアント端末２００からのリクエスト情報を通信装置１４０ｂを介して受け取るリクエスト受信部１１１と、このリクエスト情報を通信装置１４０ａを介してサーバ３００へ転送するリクエスト転送部１１２と、サーバ３００からのレスポンス情報を通信装置１４０ａを介して受け取るレスポンス受信部１１３と、このレスポンス情報を通信装置１４０ｂを介してクライアント端末２００へ転送するレスポンス転送部１１４と、リクエスト受信部１１１が受け取ったリクエスト情報を入力情報として収集すると共に、レスポンス受信部１１３が受け取ったレスポンス情報を出力情報として収集する入出力情報収集部１１５と、入出力情報収集部１１５が収集した複数の入出力情報に基づいてサーバ３００が提供するサービス同士の連携付けを行うサービス連携付け部１１６と、レスポンス受信部１１３が受け付けたレスポンス情報に、サービス連携付け部１１６で連携付けられたサービス情報を添付する連携サービス情報添付部１１７と、を有している。なお、これらの機能部１１１〜１１７は、いずれも、記憶装置１２０に格納されているプログラム１２９をＣＰＵ１１０が実行することで機能する。

記憶装置１２０は、前述のプログラム１２９が格納されている他、入出力情報収集部１２１が収集した入出力情報が格納される入出力情報テーブル１２１と、サービス連携付け部１１６により連携付けられたサービス同士の連携情報が格納されるサービス連携情報テーブル１２２とが設けられている。

次に、以上で説明した中継装置１００の概略動作について、図２に示すシーケンス図に従って説明する。

まず、クライアント端末２００は、サービスの提供元であるサーバ３００に対してリクエスト情報を送信する（Ｓ１）。中継装置１００のリクエスト受信部１１１は、通信装置１４０ｂを介して、このリクエスト情報を受け取り、これを入出力情報収集部１１５に転送する。入出力情報収集部１１５は、このリクエスト情報を入力情報とし、この入力情報の一部を入出力情報テーブル１２１に保存する（Ｓ２）。なお、この入力情報保存処理（Ｓ２）に関しては、後程詳細に説明する。

入出力情報収集部１１５は、入力情報の保存後、入力情報であるリクエスト情報をリクエスト転送部１１２に転送する。リクエスト転送部１１２は、通信装置１４０ａを介して、このリクエスト情報をサーバ３００へ転送する（Ｓ３）。

サーバ３００は、このリクエスト情報を受信すると、このリクエスト情報に応じたWebアプリ３０１を実行して、このリクエストに対するレスポンスを得て（Ｓ４）、レスポンス情報を中継装置１００に送信する（Ｓ５）。

中継装置１００のレスポンス受付部１１３は、通信装置１４０ａを介して、サーバ３００からのレスポンス情報を受け取り、これを入出力情報収集部１１５に転送する。入出力情報収集部１１５は、このレスポンス情報を出力情報とし、この出力情報の一部を、前述の入力情報中の情報と連携付けて、入出力情報テーブル１２１に保存する（Ｓ６）。なお、この出力情報保存処理（Ｓ６）に関しても、後程詳細に説明する。

中継装置１００のサービス連携付け部１１６は、入出力情報テーブル１２１にこれまでに保存された複数の入出力情報を用いて、サービス相互の連携付けを行って、サービス連携情報を作成し、これをサービス連携情報テーブル１２２に保存する（Ｓ７）。なお、ここでのサービス連携付け処理（Ｓ７）は、他の処理と同期している必要はない。例えば、クライアント端末２００とサーバ３００との間での情報の中継が多い時間帯では、入出力情報の収集だけを行い、中継が少ない時間帯に、このサービス連携付け処理（Ｓ６）を行ってもよい。また、このサービス連携付け処理（Ｓ７）に関しても、後程詳細に説明する。

次に、連携サービス情報添付部１１７は、レスポンス受信部１１３からのレスポンス情報を連携付けているサービス連携情報をサービス連携情報テーブル１２２から検索する。そして、検索により取得したサービス連携情報に基づいて、レスポンス情報に連携する連携サービス情報を取得し、これをレスポンス情報に付加して、これをレスポンス転送部１１４に渡す（Ｓ８）。なお、この連携サービス情報添付処理（Ｓ８）に関しても、後程詳細に説明する。

レスポンス転送部１１４は、連携サービス情報が付加されたレスポンス情報をクライアント端末２００に送信する（Ｓ９）。以上で、一連の処理が終了する。

次に、前述の入力情報保存処理（Ｓ２）及び出力情報保存処理（Ｓ６）での詳細処理内容について説明する。

入力情報保存処理（Ｓ２）では、入出力情報収集部１１５が、サーバ３００に対する入力情報であるリクエスト情報から、リファラURL、リクエスト先URL、リクエストparam情報を抽出する。

ここで、リファラURLは、フォームやリンクを利用してリクエストを送信した場合のリンク元となるWebページのURLである。リクエスト先URLは、フォームやリンクを利用してリクエストを送信する場合の送信先のURLである。また、Webブラウザのアドレスバーに直接アドレスを記入した場合は、その入力したアドレスがリクエスト先URLとなる。以上のリファラURLとリクエスト先URLの情報は、リクエスト情報の送信パケットのヘッダから抽出する。リクエストparamは、リクエスト情報の本体とも言えるデータで、クライアントがクライアント端末３００に入力したデータ、言い換えるとパラメータである。このパラメータは、GETのメソッドを利用した場合には、リクエスト情報中、リクエスト先URLの「?」マーク以下に格納されている。また、POSTのメソッドを利用した場合には、リクエスト情報中、ボディとして規定された部分に格納されている。さらに、リクエストparamは「リクエスト変数名=リクエスト値」の形式で表現され、複数のパラメータがある場合には「&」で区切って表現される。

入出力情報収集部１１５は、以上の情報の他、リクエスト取得時刻も取得する。このリクエスト取得時刻は、中継装置１００がクライアント端末３００からのリクエスト情報を中継した時刻である。

そして、入出力情報収集部１１５は、以上のように抽出したリファラURL、リクエスト先URL、リクエスト取得時刻、リクエストparam情報を、図３に示す入出力情報テーブル１２１中の、リファラURL領域１２１ｂ、リクエスト先URL領域１２１ｃ、リクエスト取得時刻領域１２１ｅ、リクエストparam領域１２１ｇに格納する。

出力情報保存処理（Ｓ６）では、入出力情報収集部１１５が、サーバ３００からの出力情報であるレスポンス情報から、レスポンスURL、レスポンス取得時刻、レスポンスボディを抽出する。

ここで、レスポンスURLは、リクエスト先URLにリクエストを送信した後に受け取るWebページのURLのことである。もし、リクエストを転送するようなリダイレクト処理がなければ、リクエスト先URLとレスポンスURLは一致する。また、レスポンスボディは、レスポンス情報のうち、クライアント端末３００が実際に表示するデータである。

入出力情報収集部１１５は、以上の情報の他、レスポンス取得時刻も取得する。このレスポンス取得時刻は、中継装置１００がサーバ３００からレスポンス情報を中継した時刻である。

そして、入出力情報収集部１１５は、以上のように抽出したレスポンスURL、レスポンス取得時刻、レスポンスボディを、図３に示す入出力情報テーブル１２１中の、レスポンスURL領域１２１ｄ、レスポンス取得時刻領域１２１ｆ、レスポンスボディ領域１２１ｈに格納する。この際、レスポンス情報から抽出した情報は、入出力情報テーブル１２１中、このレスポンス情報に対するリクエスト情報の情報を格納した行と同じ行に格納される。すなわち、ステップ２〜ステップ６の一連の処理により、入出力情報テーブル１２１の１つの行が埋まる。

ここで、「ユーザが横浜駅から展示場Ｘに行くために路線検索をしたいが、展示場Ｘの最寄駅がわからない。」というシナリオを考える。

この場合、クライアント端末２００は、図１１に示すように、最寄駅検索サービス１０にアクセスして、最寄駅検索結果情報１５を得る。展示場Ｘに対する最寄駅の候補としては、国際展示場正門や有明などが提示される。そして、クライアント端末２００の操作者であるユーザは、国際展示場正門が最寄駅で利用しやすいと判断し、路線検索サービス２０にアクセスして、出発駅に横浜を入力し、到着駅に国際展示場正門を入力する。以上の操作により、ユーザは当初の目的である路線検索結果情報２５を得る。

以上のシナリオでは、ユーザは、クライアント端末２００に、URLとして「http://example。com/moyori」を打ち込んで、最寄駅検索サービス１０の利用をリクエストする。中継装置１００の入出力情報収集部１１５は、このリクエスト情報から、リファラURL、リクエスト先URL、リクエスト取得時刻、リクエストparam情報を取得する。そして、図３に示す入出力情報テーブルのid領域１２１ａに、「1」を格納し、この行のリファラURL領域１２１ｂに「不明」、リクエスト先URL領域１２１ｃに「http://example。com/moyori」、リクエスト取得時刻領域１２１ｅに「2008-07-07 10:00:00」、リクエストparam領域１２１ｇに「なし」を格納する。

このリクエストに対して、サーバ３００からは、図１１に示す最寄駅検索受付情報１１を含むレスポンス情報が返ってくる。なお、図１１中では、最寄駅検索受付情報１１の表示画面中に、「展示場Ｘ」が表示されているが、この段階で、「展示場Ｘ」は表示されていない。中継装置１００の入出力情報収集部１１５は、このレスポンス情報から、レスポンスURL、レスポンス取得時刻、レスポンスボディを取得する。そして、図３に示す入出力情報テーブル１２１のid領域１２１ａが「1」の行であって、レスポンスURL領域１２１ｄに「http://example。com/moyori」、レスポンス取得時刻領域１２１ｆに「2008-07-07 10:00:10」、レスポンスボディ領域１２１ｈにHTML文書である「<html>…<form>…</html>」を格納する。

ユーザは、最寄駅検索受付情報１１（図１１）を見ながら、この情報１１中の施設名・住所の入力フォームに「展示場Ｘ」を入力してから、submitボタンをクリックする。クライアント端末３００は、以上の処理により、サーバ３００へリクエストを送信する。中継装置１００の入出力情報収集部１１５は、このリクエスト情報から、リファラURL、リクエスト先URL、リクエスト取得時刻、リクエストparam情報を取得する。そして、図３に示す入出力情報テーブルのid領域１２１ａに、「2」を格納し、この行のリファラURL領域１２１ｂに「http://example。com/moyori」、リクエスト先URL領域１２１ｃに「http://example。com/moyori/where」、リクエスト取得時刻領域１２１ｅに「2008-07-07 10:00:45」、リクエストparam領域１２１ｇに「where=展示場Ｘ」を格納する。

このリクエストに対して、サーバ３００からは、図１１に示す最寄駅検索結果情報１５を含むレスポンス情報が返ってくる。中継装置１００の入出力情報収集部１１５は、このレスポンス情報から、レスポンスURL、レスポンス取得時刻、レスポンスボディを取得する。そして、図３に示す入出力情報テーブル１２１のid領域１２１ａが「2」の行であって、レスポンスURL領域１２１ｄに「http://example。com/moyori/result」、レスポンス取得時刻領域１２１ｆに「2008-07-07 10:01:00」、レスポンスボディ領域１２１ｈにHTML文書である「<html><body>…国際展示場正門…</html>」を格納する。

ユーザは、最寄駅検索サービス２０（図１１）により、「展示場Ｘ」の最寄駅の候補として、レスポンスパラメータとしての「国際展示場正門」及び「有明」を得ると、前述のシナリオ通り、「横浜」から最寄駅へ行くための路線の検索を行う。なお、レスポンスパラメータとは、レスポンスボディ中でリクエストパラメータに対する応答結果を示す部分で、レスポンスボディ中のテンプレート部分を除く部分である。

そこで、ユーザは、クライアント端末２００に、URLとして「http://example.com/rosen」を打ち込んで、路線検索サービス２０の利用をリクエストする。中継装置１００の入出力情報収集部１１５は、このリクエスト情報から、リファラURL、リクエスト先URL、リクエスト取得時刻、リクエストparam情報を取得する。そして、図３に示す入出力情報テーブルのid領域１２１ａに、「3」を格納し、この行のリファラURL領域１２１ｂに「不明」、リクエスト先URL領域１２１ｃに「http://example.com/rosen」、リクエスト取得時刻領域１２１ｅに「2008-07-07 10:03:00」、リクエストparam領域１２１ｇに「なし」を格納する。

このリクエストに対して、サーバ３００からは、図１１に示す路線検索受付情報２１を含むレスポンス情報が返ってくる。なお、図１１中では、路線検索受付情報２１の表示画面中に、「横浜」「国際展示場正門」が表示されているが、この段階で、これらは表示されていない。中継装置１００の入出力情報収集部１１５は、このレスポンス情報から、レスポンスURL、レスポンス取得時刻、レスポンスボディを取得する。そして、図３に示す入出力情報テーブル１２１のid領域１２１ａが「3」の行であって、レスポンスURL領域１２１ｄに「http://example.com/rosen」、レスポンス取得時刻領域１２１ｆに「2008-07-07 10:03:30」、レスポンスボディ領域１２１ｈにHTML文書である「<html>…<form>…</html>」を格納する。

ユーザは、路線検索受付情報２１（図１１）を見ながら、この情報２１中の出発入力フォームに「横浜」を入力し、到着入力フォームに「国際展示場正門」を入力してから、submitボタンをクリックする。クライアント端末３００は、以上の処理により、サーバ３００へリクエストを送信する。中継装置１００の入出力情報収集部１１５は、このリクエスト情報から、リファラURL、リクエスト先URL、リクエスト取得時刻、リクエストparam情報を取得する。そして、図３に示す入出力情報テーブルのid領域１２１ａに、「4」を格納し、この行のリファラURL領域１２１ｂに「http://example.com/rosen」、リクエスト先URL領域１２１ｃに「http://example.com/rosen/kensaku」、リクエスト取得時刻領域１２１ｅに「2008-07-07 10:05:00」、リクエストparam領域１２１ｇに「from=横浜&to=国際展示場正門」を格納する。

このリクエストに対して、サーバ３００からは、図１１に示す路線検索結果情報２５を含むレスポンス情報が返ってくる。中継装置１００の入出力情報収集部１１５は、このレスポンス情報から、レスポンスURL、レスポンス取得時刻、レスポンスボディを取得する。そして、図３に示す入出力情報テーブル１２１のid領域１２１ａが「4」の行であって、レスポンスURL領域１２１ｄに「http://example。com/rosen/result」、レスポンス取得時刻領域１２１ｆに「2008-07-07 10:05:05」、レスポンスボディ領域１２１ｈにHTML文書である「<html><body>…新橋…</html>」を格納する。

以上のように、ユーザが最寄駅検索サービス１０と路線検索サービス２０の２つのサービスを利用することにより、図３に示す入出力情報テーブル１２１が完成する。

次に、前述のサービス連携付け処理（Ｓ７）での詳細処理内容について、図４に示すフローチャートに従って説明する。

サービス連携付け部１１６は、入出力情報テーブル１２１に新たな行が追加されると、この行の入出力情報を取得し、この行の入出力情報で規定されるサービスを連携先サービス情報として取得する（Ｓ７０１）。例えば、図３に示す入出力情報テーブル１２１のid＝4の行の入出力情報を取得し、この行で規定されるサービスを連携先サービス情報とする。そして、サービス連携付け部１１６は、以下のステップ７０２，７０３の処理で、連携先サービス情報に対する連携元サービス情報の候補を特定する。

サービス連携付け部１１６は、ステップ７０１で取得した連携先サービス情報にリファラURLが存在するか確認する（Ｓ７０２）。リファラURLが存在しなければ、連携先サービス以前に利用されたサービスを辿ることができないので、サービスを連携付けることができないとして処理を終了する。リファラURLが存在すれば連携先サービス以前に利用されたサービスを辿ることができるので、処理を続行する。例えば、図３に示す入出力情報テーブル１２１のid＝4の行の入出力情報には、リファラURLが存在するので、処理を続行する。

次に、サービス連携付け部１１６は、連携先サービスの入力情報（リクエスト情報）に連携する他のサービスの出力情報（レスポンス情報）が存在するかを確認する（Ｓ７０３）。

ここで、このステップ７０３での処理について、図５に示すフローチャートに従って説明する。

サービス連携付け部１１６は、レスポンス取得時刻が連携先サービス情報のリクエスト取得時刻より以前で、かつε時間以内に当該中継装置１００が取得した他のサービスの入出力情報を、入出力情報テーブル１２１から全て取得する（Ｓ７３１）。このε時間は、十分に小さいことを意味し、中継装置１００の管理者が与えるパラメータ値である。仮に、εの値を１時間にすれば、過去１時間以内にユーザが利用したサービスが検索対象となる。

次に、サービス連携付け部１１６は、連携先サービス情報のリクエストparamのリクエスト値が、ステップ７３１で取得した入出力情報のレスポンスボディ内に含まれているか検索する（Ｓ７３２）。

この際に、構造化文書の特徴を用いて、タグで囲まれた文字列やコメント以外の文字列などのWebページに表示される情報を検索対象とする。そうすることで、ユーザに見える情報だけを対象に検索することができる。また、検索には部分一致も許す。結果として一致するレスポンスがあれば、連携先サービス情報と連携する出力情報が存在するとして（Ｓ７３３）、図４のステップ７０４に進む。また、一致するレスポンスがなければ、連携先サービス情報と連携する出力情報は存在しないと判断して（Ｓ７３４）、処理を終了する。

ここで、同じレスポンスボディ内に一致する箇所が複数ある場合もある。その場合には、文字列の一致する割合や構造化文書の特徴を用いて優先順位を付け、最も優先順位が高い文字列を選びだす。具体的な優先順位付けの方法として、例えば、連携先サービス情報のリクエストparamのリクエスト値が「国際展示場正門」のとき、他のサービスの出力情報中に「国際展示場」及び「国際展示場正門」が存在する場合には、一致する文字列が多い「国際展示場正門」を優先する。また、構造化文書の特徴を用いて、タグにより強調表示や文字を大きくし表示している文字列を優先してもよい。さらに、一致する文字列を含むレスポンスボディが複数ある場合もある。複数ある場合には、連携先サービス情報のリクエスト取得時刻と検索の対象となるサービスのレスポンス取得時刻の差がより少ないものを優先する。例えば、サービスの利用時刻が近い順にn個、連携サービスの候補として選ぶ。このnはサービス連携中継装置１００の提供者が事前に設定する値である。また、ステップ704以降のサービス連携付け処理を行う際の、サービスの連携強さを計算する場合にも利用することができる。

例えば、ステップ７０２では、ステップ７０１で取得したid＝4の行の入出力情報（連携先サービス情報）にリファラURLが存在するか確認する。この場合、この入出力情報には、「http://example.com/rosen」というリファラURLが存在する。そして、ステップ７０３に進み、図５中のステップ７３１で、連携先サービス情報のリクエスト取得時刻「2008-07-07 10:05:00」より以前のレスポンス取得時刻を持つ他のサービスの入出力情報を入出力情報テーブル１２１から抽出する。この場合、「id = 1」「id = 2」「id = 3」の入出力情報が抽出される。次に、連携先サービスのリクエストparamのリクエスト値「横浜」「国際展示場正門」が、ステップ７３１で抽出したいずれかの入出力情報のレスポンスボディ内に含まれているか検索する（Ｓ７３２）。この場合、「id = 2」の入出力情報中のレスポンスボディ内に「国際展示場正門」が含まれているので、この「id = 2」の入出力情報で規定されるサービスは連携元サービスの候補であると判断する。

連携元サービス候補の特定が終了すると（Ｓ７０３）、以下のステップ７０４〜ステップ７１０の処理で、連携先サービス情報と、この連携元サービス候補の情報とのサービス連携付けを行う。

サービス連携付け部１１６は、まず、連携先サービス情報からリファラURLを抽出し、これを図７に示すサービス連携情報テーブル１２２の連携先サービスURL領域１２２ｂに格納する（Ｓ７０４）。この場合、連携先サービス情報（id = 4）のリファラURL「http://example.com/rosen」を連携先サービスURL領域１２２ｂに格納する。

次に、連携先サービス情報のリファラURLがリクエスト先URLになっている入出力情報を入出力情報テーブル１２１から探し出し、そのレスポンスボディと対象サービスのリクエスト先URL情報とリクエストparamのリクエスト変数名から、連携先サービス情報のリクエストparamを入力した位置のXPathを抽出し、このXPathを、図７に示すサービス連携情報テーブル１２２の連携先サービスXPath領域１２２ｃに格納する（Ｓ７０５）。この場合、連携先サービス情報（id = 4）のリファラURL「http://example.com/rosen」がリクエスト先URLになっている「id = 3」の入出力情報を探し出し、この入出力情報のレスポンスボディ中のどの位置に、連携先サービス情報（id = 4）のリクエストparamに含まれる「to=国際展示場正門」のリクエスト変数名が定義されているXPath「/html/body/div[2]/form/input[@name=’to’］」を抽出する。そして、これを、図７に示すサービス連携情報テーブル１２２の連携先サービスXPath領域１２２ｃに格納する。これは、図１１に示す路線検索結果２５をレスポンスボディとする連携先サービス（id = 4）に対して、「id = 3」の入出力情報に含まれている路線検索受付情報２１における入力フォーム２２の位置を取得することを意味する。

ここで、リクエスト先URLとリクエストparamのリクエスト変数を用いるのは、例えば、HTMLのformを用いた場合に、以下の情報をXPathとして抽出できるからである。
(1) リクエストURLからページ内のどのformを利用しているかがわかる。
(2) リクエストparamのリクエスト変数名からform内のどのname属性がついたinputタグを利用しているかがわかる。

次に、サービス連携付け部１１６は、ステップ７０３で取得した連携元サービス候補情報（id = 2）からレスポンスURL「http://example.com/moyori/result」を抽出し、これを図７に示すサービス連携情報テーブル１２２の連携元出力URL領域２１２ｄに格納する（Ｓ７０６）。さらに、連携元サービス候補のレスポンスボディ内で、連携先サービスのリクエストparamの文字列と一致した文字列の位置をXPath「/html/body/div[3]/table/li[1]」として抽出し、これを図７に示すサービス連携情報テーブル１２２の連携元出力XPath領域１２２eに格納する（Ｓ７０７）。これは、図１１に示す最寄駅線検索結果１５をレスポンスボディとする連携元サービス（id = 2）において、連携先サービス（id = 4）のリクエストparamの文字列と一致した文字列「国際展示場正門」が示されている位置、つまりレスポンスパラメータの位置１６を取得することを意味する。

以上のステップ７０４〜ステップ７０７の処理で、連携先サービス情報にどのサービス情報の結果が利用されているかが連携付けられる。言い換えると、どのサービスの結果が連携先サービス情報の入力として利用されているかがわかるようになる。

次に、以下のステップ７０８〜ステップ７１０の処理で、連携先サービス情報の入力がどのサービス情報の入力の結果得られたものであるかを連携付ける。

ステップ７０８で、サービス連携付け部１１６は、ステップ７０３で取得した連携元サービス情報にリファラURLが存在するか確認する。リファラURLが存在すれば、連携元サービス情報はそのリファラURLで示されるページに対する入力の結果得られたものと判断し、次のステップ７０９に進む。一方、リファラURLが存在しなければ、ステップ７１１に進む。この場合、連携元サービス情報（id = 2）には、リファラURLが存在するので、ステップ７０９に進む。

サービス連携付け部１１６は、ステップ７０８で、連携元サービス情報にリファラURLが存在すると判断した場合、そのリファラURLを連携先サービス情報に連携する入力ページとみなし、これを図７に示すサービス連携情報テーブル１２２の連携元入力URL領域１２２ｆに格納する（Ｓ７０９）。この場合、連携元サービス情報（id = 2）のリファラURL「http://example.com/moyori」を、図７に示すサービス連携情報テーブル１２２の連携元入力URL領域１２２ｆに格納する。

次に、サービス連携付け部１１６は、連携元サービス情報のリファラURLがリクエスト先URLとして格納されている直近の入出力情報を入出力情報テーブルから探し出す。ここでも、検索対象は、サービスのリクエスト取得時刻に対してレスポンス取得時刻が近いサービスを優先する。そして、この入出力情報のレスポンスボディと連携サービスのリクエスト先URL情報とリクエストparamから、リクエストを入力した位置のXPathを抽出し、これを図７に示すサービス連携情報テーブル１２２の連携元入力XPath領域ｇに格納する（Ｓ７１０）。この場合、連携元サービス（id = 2）のリファラURL「http://example.com/moyori」が、リクエスト先URLになっている「id = 1」の入出力情報を取得する。そして、この「id = 1」の入出力情報のレスポンスボディ等から、連携元サービス（id = 2）のリクエストparam「where=展示場X」のリクエスト変数名である「where」が「id = 1」のサービスのレスポンスボディのどの位置で定義されているかを抽出する。すると「展示場ｘ」と入力した場所のXPathが例えば、「/html/body/div[1]/form/input[@name=’where’]」のように取得できる。このXPathを、図７に示すサービス連携情報テーブル１２２の連携元入力XPath領域１２２ｇに格納する。これは、図１１に示す最寄駅検索受付情報１１における入力フォーム１２の位置を取得することを意味する。

以上のステップ７０８〜ステップ７１０の処理により、連携先サービスの入力がどのサービスの入力の結果得られたものであるかがわかるようになる。

次に、サービス連携付け部１１６は、連携先サービス情報と連携元サービス情報との連携強さを求める（Ｓ７１１）。連携強さを求めるため、ステップ７０３で利用した時間εや連携元サービスの候補数nを利用してもよい。この時間εと候補数nは、サービス連携付け部１１６が持つ。これらの変数の値は、中継装置１００の管理者が設定する。

時間εを利用する場合、例えば、以下の式で、連携強さＳを求める。

Ｓ＝(ε-レスポンス取得時刻とリクエスト取得時刻の差分)/ε
この式では、サービスの利用時刻が近いほど連携強さＳが大きくなる。

また、候補数ｎを利用する場合、ｎ個の候補のそれぞれに、サービス利用時刻が近い順に、1からnまでの連携サービス検出順位を付けて、以下の式で連携強さＳを求める。

この式では、連携元サービスとして検出された順番が早いほど連携強さＳが大きくなる。

Ｓ＝（n+1-連携サービス検出順位）/n
ところで、ある連携先サービスに対して、連携元サービスを抽出した後、この連携先サービスと同一のサービスに対して、連携元サービスを抽出したところ、この連携元サービスが先に抽出した連携元サービスと同じになる場合がある。

そこで、サービス連携付け部１１６は、以上のステップ７０２〜ステップ７１１で、サービス連携情報テーブル１２２の１行に格納したサービス連携情報と、連携強さを除いて、同一のサービス連携情報が他の行に存在するかを検索する（Ｓ７１２）。同じサービス連携情報があれば、このサービス連携情報中の連携強さを、ステップ７１１で求めた対象サービス連携情報の連携強さに加えて、この値を、サービス連携情報テーブル１２２中であって、対象連携サービスの行の連携強さ領域１２２ｈに格納する。また、同じサービス連携情報が無ければ、ステップ７１１で求めた対象サービス連携情報の連携強さを、そのまま、サービス連携情報テーブル１２２中であって、対象連携サービスの行の連携強さ領域１２２ｈに格納する。これにより、サービス連携情報として利用される頻度の高いサービス連携情報中の連携強さが増す。

次に、前述の連携サービス情報添付処理（Ｓ８）での詳細処理内容について、図８に示すフローチャートに従って説明する。

連携サービス情報添付部１１７は、入出力情報収集部１１５を介して、レスポンス受信部１１３からレスポンス情報を受け付けると、サービス連携情報テーブル１２２から、このレスポンス情報に含まれているレスポンスURLを含む全てのサービス連携情報を抽出する（Ｓ８０１）
次に、連携サービス情報添付部１１７は、ステップ８０１で抽出したサービス連携情報のうち、連携強さの最も大きものを一つ取得して（Ｓ８０２）、以下のステップ８０３〜ステップ８０７の処理を実行する。

連携サービス情報添付部１１７は、先に取得した一つのサービス連携情報について、以下の二つの条件(ａ)(ｂ)について判断する（Ｓ８０３）。

(ａ)レスポンスURLは、サービス連携情報中の連携先サービスURLと一致するか。

(ｂ)レスポンスURLは、サービス連携情報中の連携元出力URLと一致するか。

ステップ８０３の判断で、(a)、(b)の両方の条件がNoなら、何ら処理をせずに、ステップ８０７に進む。

ステップ８０３の判断で、(a)の条件がYes、(b)の条件がNoなら、レスポンス情報は、連携先サービスの情報であることから、連携サービス情報添付部１１７は、レスポンス情報に、この連携先サービスより以前に利用する連携元サービスの情報を添付する（Ｓ８０４）。

具体的に、このステップ８０４で、連携サービス情報添付部１１７は、まず、ステップ８０２に取得したサービス連携情報から、連携元入力URLを取得し、このURLで規定されるサービス情報を連携元サービス情報として取得する。次に、ステップ８０２に取得したサービス連携情報から、連携先サービスXPathと連携元入力XPathとを抽出し、連携先サービスXPathと連携元入力XPathとを関係付ける。そして、レスポンス情報に、連携元サービス情報と、連携先サービスXPathと連携元入力XPathとを関係付けた属性情報と、を添付する。

例えば、図１１を用いて前述したように、ユーザが、クライアント端末２００にURLとして「http://example。com/rosen」を打ち込んで、路線検索サービス２０の利用をリクエストした場合について考える。

この際、サーバ３００は、このリクエストに対して、路線検索受付情報２１を含むレスポンス情報を返す。このレスポンス情報に含まれるレスポンスURLは、前述したように、「http://example。com/rosen」である。そこで、連携サービス情報添付部１１７は、サービス連携情報テーブル１２２から、このレスポンスURLを含むサービス連携情報を取得する（Ｓ８０１）。この場合、図６中で、「id = 1」のサービス連携情報を取得する。次に、連携サービス情報添付部１１７は、前述の条件(ａ)(ｂ)について判断する（Ｓ８０３）。この場合、レスポンスURLは、サービス連携情報（id = 1）中の連携先サービスURLと一致し、連携元出力URLと一致しないため、このレスポンス情報は、連携先サービスの情報であると判断し、連携元サービスの情報等を取得するため、ステップ８０４に進む。

このステップ８０４で、連携サービス情報添付部１１７は、サービス連携情報（id = 1）中の連携元入力URL「http://example。com/moyori」を取得し、この連携元入力URLで規定されるサービス情報を連携元サービス情報として取得する。この連携元入力URLに基づいて得られる連携元サービス情報は、図１１に示す最寄駅検索受付情報１１を含む情報である。したがって、このレスポンス情報に連携元サービス情報を添付して、これをクライアント端末２００に渡すと、クライアント端末には、図９に示すように、サーバ３００からのレスポンス情報に含まれる路線検索受付情報２１と共に、最寄駅検索受付情報１１が出力されるようにjavaScriptを埋め込む。さらに、連携サービス情報添付部１１７は、ステップ８０４で、サービス連携情報（id = 1）から、連携先サービスXPathと連携元入力XPathとを抽出し、連携先サービスXPathと連携元入力XPathとを関係付けた属性情報を、JavaScriptにより前述のレスポンス情報に付加する。ここで、連携先サービスXPathは、路線検索受付情報２１中の入力フォーム２２の位置であり、連携元入力XPathは、最寄駅検索受付情報１１中の入力フォーム１２の位置であるから、クライアント端末２００には、図９に示すように、路線検索受付情報２１中の入力フォーム２２と最寄駅検索受付情報１１中の入力フォーム１２とが、関係するように出力される。さらに、この関係付けの属性情報により、クライアント端末２００では、例えば、路線検索受付情報２１中の入力フォーム２２に、1）文字入力しようとすると、カーソルが最寄駅検索受付情報１１中の入力フォーム１２内に移動する、2）この入力フォーム１２が点灯してここへの入力を促す、さらに、3）最寄駅検索受付情報１１中の入力フォーム１２にリクエストパラメータ（展示場X）が入力され、その結果で得られるレスポンスパラメータ（国際展示場正門）を路線検索受付情報２１中の入力フォーム２２に入力する、等の処理が成される。

再び、図８に示すフローチャートの説明に戻る。

ステップ８０３の判断で、(a)の条件がNo、（ｂ）の条件がYesなら、レスポンス情報は、連携元サービスの情報であることから、連携サービス情報添付部１１７は、このレスポンス情報に、この連携元サービスより以降に利用する連携先サービスの情報を添付してから（Ｓ８０５）、ステップ８０７に進む。

具体的に、このステップ８０５で、連携サービス情報添付部１１７は、まず、ステップ８０２に取得したサービス連携情報から、連携先サービスURLを取得し、このURLで規定されるサービス情報を連携先サービス情報として取得する。次に、ステップ８０２に取得したサービス連携情報から、連携元出力XPathと連携先サービスXPathとを抽出し、連携元出力XPathと連携先サービスXPathとを関係付ける。そして、レスポンス情報に、連携先サービス情報と、連携元出力XPathと連携先サービスXPathとを関係付けた属性情報と、を添付する。

例えば、図１１を用いて前述したように、ユーザが、クライアント端末２００にURLとして「http://example.com/moyori」を打ち込んで、最寄駅検索サービス１０を利用して、検索を実行した場合について考える。

この際、サーバ３００は、この検索リクエストに対して、最寄駅検索結果情報１５を含むレスポンス情報を返す。このレスポンス情報に含まれるレスポンスURLは、前述したように、「http://example.com/moyori/result」である。そこで、連携サービス情報添付部１１７は、サービス連携情報テーブル１２２から、このレスポンスURLを含むサービス連携情報を取得する（Ｓ８０１）。この場合も、図６中で、「id = 1」のサービス連携情報を取得する。次に、連携サービス情報添付部１１７は、前述の条件(ａ)(ｂ)について判断する（Ｓ８０３）。この場合、レスポンスURLは、サービス連携情報（id = 1）中の連携先サービスURLと一致せず、連携元出力URLと一致するため、このレスポンス情報は、連携元サービスの情報であると判断し、連携先サービスの情報等を取得するため、ステップ８０５に進む。

このステップ８０５で、連携サービス情報添付部１１７は、サービス連携情報（id = 1）中の連携先サービスURL「http://example.com/rosen」を取得し、この連携先サービスURLで規定されるサービス情報を連携先サービス情報として取得する。この連携先サービスURLに基づいて得られる連携先サービス情報は、図１１に示す路線検索受付情報２１を含む情報である。したがって、このレスポンス情報に連携先サービス情報を添付して、これをクライアント端末２００に渡すと、クライアント端末２００には、図１０に示すように、サーバ３００からのレスポンス情報に含まれる最寄駅検索結果情報１５と共に、路線検索受付情報２１が出力されるようにjavaScriptを埋め込む。さらに、連携サービス情報添付部１１７は、ステップ８０５で、サービス連携情報（id = 1）から、連携元出力XPathと連携先サービスXPathとを抽出し、連携元出力XPathと連携先サービスXPathとを関係付けた属性情報を、JavaScriptにより前述のレスポンス情報に付加する。ここで、連携元出力XPathは、最寄駅検索結果情報１５中の文字列「国際展示場正門」が示されている位置１６であり、連携先サービスXPathは、路線検索受付情報２１の入力フォーム２２の位置であるから、クライアント端末２００には、図１０に示すように、最寄駅検索結果情報１５中の文字列「国際展示場正門」が示されている位置（レスポンスパラメータの位置）１６と最寄駅検索受付情報１１中の入力フォーム２２とが、関係するように出力される。さらに、この関係付けの属性情報により、クライアント端末２００では、例えば、最寄駅検索受付情報１１中の入力フォーム２２にカーソルを配置する、又は、この入力フォーム２２に、連携元出力XPathの位置に示されている文字列「国際展示場正門」を配置する等の処理が成される。

なお、図９,１０において、レスポンス情報２１,１５に添付する連携サービス情報１１,２１は、それぞれ一つずつであるが、複数の連携サービス情報が検索され、これらが添付されることもある。このような場合、クライアント端末２００に、各連携サービス情報を単に並べて表示させるようにしてもよいし、また、連携サービス情報毎にタブ１４，２４を設けて、このタブ１４，２４がクリックされることで、タブ１４，２４に関係付けられている連携サービス情報を表示させるようにしてもよい。

再び、図８に示すフローチャートの説明に戻る。

ステップ８０３の判断で、(a)、（ｂ）の両方の条件がYesなら、レスポンス情報は、連携元サービスの情報であると共に、連携先サービスの情報でもあることから、連携サービス情報添付部１１７は、レスポンス情報に、連携先サービスとしてのレスポンス情報より以前に利用する連携元サービスの情報、及び連携元サービスとしてのレスポンス情報より以降に利用する連携先サービスの情報を、このレスポンス情報に添付してから（Ｓ８０６）、ステップ８０７に進む。

ここで、連携サービス情報添付部１１７が、レスポンス情報に連携元サービスの情報を添付する方法、及び、レスポンス情報に連携先サービスの情報を添付する方法は、以上のステップ８０４，８０５で説明した方法とおなじである。

ステップ８０７では、連携サービス情報添付部１１７は、ステップ８０１において抽出したサービス連携情報が残っているか否かを判断する。サービス連携情報が残っていれば、ステップ８０２に戻り、連携サービス情報添付部１１７は、残っているサービス連携情報のうちから、連携強さの最も大きものを一つ取得して、以上で説明したステップ８０３〜ステップ８０７の処理を実行する。

また、連携サービス情報添付部１１７は、ステップ８０７において、ステップ８０１で抽出したサービス連携情報が残っていないと判断すると、ステップ８０４〜８０６の処理で、レスポンス情報に連携サービス情報を添付していれば、この連携サービス情報に対して連携する連携サービス情報を、さらに添付するか否かを判断する（Ｓ８０８）。この判断は、クライアント端末３００から連携サービス情報に更なる連携サービス情報を添付するか否かの指示を予め受けておき、又は、中継装置１００の管理者が連携サービス情報に更なる連携サービス情報を添付するか否かを予め設定しておき、この指示や設定に従って行われる。

連携サービス情報添付部１１７は、連携サービス情報に対して連携する連携サービス情報を、さらに添付すると判断した場合には、ステップ８０４〜８０６の処理で、レスポンス情報に添付した連携サービス情報を新たなレスポンス情報としてから（Ｓ８０９）、ステップ８０１に戻る。このステップ８０１では、サービス連携情報テーブル１２２から、この新たなレスポンス情報に含まれているレスポンスURLを含む全てのサービス連携情報を抽出し、前述と同様に、ステップ８０２に進む。このように、ステップ８０９,８０１では、連携先サービス情報の検索キー（レスポンスURL）を変更して、連携先サービス情報を再検索する。この際、連携先サービス情報の検索の無限ループを避けるために、一度検索キーになったことのある連携先サービス情報のレスポンスURLを再び検索キーにしない。この検索キーの変更回数や変更条件は、中継装置１００の提供者が設定する。例えば、検索キーの変更回数を「０回」にしておけば、連携先サービス情報に、さらに連携するサービス情報を検索しない。つまり、ステップ８０８の判断では必ずNoになる。一方、変更条件を例えば「検索キーの候補がなくなるまで検索キーを変更する」にすれば、検索された連携サービスをさらに連携サービス情報の検索キーにして、新たな連携サービス候補の情報が見つからなくなるまで検索する。

また、連携サービス情報添付部１１７は、ステップ８０８で、連携サービス情報に対して連携する連携サービス情報を、さらに添付しないと判断した場合には、ステップ８０８で、レスポンス情報のみ、又は連携サービス情報が添付されたレスポンス情報をレスポンス転送部１１４に渡して、連携サービス情報添付処理（Ｓ８）を終了する。

以上のように、本実施形態では、中継装置１００がサービス同士の連携情報を定義し、この定義に基づいて、ユーザが利用しているサービスと連携するサービスを提供しているので、連携するサービスの提供する際のユーザの負担をなくすことができる。

また、本実施形態では、レスポンス情報に対して連携するものであれば、連携元サービス情報でも、連携先サービス情報でも添付されるので、ユーザに対してより多くの連携サービス情報を提示することができる。

「第二実施形態」
以下、本発明に係る第二実施形態について、図１２及び図１３を用いて説明する。

本実施形態は、クライアント端末２００で、コピー＆ペーストを実行すると、このコピー＆ペーストの情報を利用して、サービス連携情報を作成する機能を、第一実施形態の中継装置１００に追加したものである。

従って、本実施形態の中継装置１００ａは、図１２に示すように、ハードウェアー構成が第一実施形態と同一である。

本実施形態の中継装置１００ａは、機能構成として、第一実施形態の中継装置１００の機能構成の他に、クライアント端末２００に送るレスポンス情報に、コピーイベント及びペーストイベントを検出してこれを中継装置１００ａに通知するプログラムであるイベント検出器を添付するイベント検出器添付部１１８と、クライアント端末２００からイベント情報を受信するイベント情報受信部１１９と、を有している。これらの機能部１１８，１１９も他の機能部と同様に、記憶装置１２０ａに格納されているプログラム１２９ａをＣＰＵ１１０ａが実行することで機能する。

本実施形態の記憶装置１２０ａには、第一実施形態における各種テーブル１２１，１２２に加えて、イベント情報受信部１１９が受信したイベント情報が格納されるイベント情報テーブル１２３が設けられている。

本実施形態の中継装置１００ａも、第一実施形態の中継装置１００の機能部を有している関係で、第一実施形態の中継装置１００と同様に、図２、図４及び図５を用いて説明した動作と同じ動作を行う。さらに、本実施形態の中継装置１００ａは、クライアント端末２００で、コピー＆ペーストイベントが発生すると、このコピー＆ペーストイベントに基づくサービス連携付け処理が追加実行される。

以下、本実施形態における、コピー＆ペーストイベントに基づくサービス連携付け処理について、図１３に示すフローチャートに従って説明する。

中継装置１００ａのイベント情報受信部１１９は、クライアント端末２００からのイベント情報の受信を待つ（Ｓ７５１）。

なお、クライアント端末２００は、中継装置１００ａへのイベント情報の送信に先立ち、この中継装置１００ａから受信したプログラムであるイベント検出器を有している。このイベント検出器は、コピーイベント及びペーストイベントを検出して、イベント情報を作成し、これを中継装置１００ａへ送る。イベント情報は、イベントがコピーであるかペーストであるかの情報と、コピーデータ又はペーストデータと、コピー元サービス情報内でのデータのコピー位置XPath又はペースト先サービス情報内でのデータのペースト位置XPathと、コピー元サービスのURL又はペースト先サービスのURLと、を含んでいる。

イベント情報受信部１１９は、イベント情報を受信すると、このイベント情報がコピーイベント情報であるかペーストイベント情報であるかを判断する（Ｓ７５２）。受信したイベント情報がコピーイベントである場合には、このコピーイベント情報と共に、このコピーイベント情報の受信時刻をイベント情報テーブル１２３に格納してから（Ｓ７５３）、ステップ７５１に戻り、ペーストイベント情報の受信を待つ。また、受信したイベント情報がペーストイベント情報である場合には、このペーストイベント情報をサービス連携付け部１１６に渡す。

サービス連携付け部１１６は、ペーストイベント情報をイベント情報受信部１１９から受け取ると、このペーストイベント情報を受け取る前の所定時間に、ペーストイベント情報に含まれているペーストデータと同じデータをコピーデータとするコピーイベント情報が、イベント情報テーブル１２３内に存在するか否かを判断する（Ｓ７５４）。当該コピーイベント情報が存在しなければ、ステップ７５１に戻り、当該コピーイベント情報が存在すれば、ステップ７５５に進む。例えば、中継装置１００ａを経由しないサービス情報からコピーしたデータは、中継装置１００ａに送られてこないため、このデータの情報は、イベント情報テーブル１２３内に存在しない。この場合、コピー元サービスとコピー先サービスとを連携付けることができないため、ステップ７５１に戻る。

サービス連携付け部１１６は、受信したペーストイベント情報に対応するコピーイベント情報がイベント情報テーブル１２３内に存在すれば、このコピーイベント情報に対応する入出力情報が入出力情報テーブル１２１中に存在するか否かを判断する（Ｓ７５５）。ここでは、コピーイベント情報中に含まれているコピー元サービスのURLがレスポンスURLであり、且つコピーイベント情報中に含まれているコピーデータがレスポンスボディ内に存在する入出力情報を検索する。

コピーイベント情報に対応する入出力情報が入出力情報テーブル１２１になければ、サービス間の連携付けができないため、ステップ７５１に戻る。また、コピーイベント情報に対応する入出力情報が入出力情報テーブル１２１にあれば、コピー元サービスを連携元サービスとし、ペースト先サービスを連携先サービスとして、以下のステップ７５６〜ステップ７６２で、サービス同士の連携付けを行う。

サービス連携付け部１１６は、まず、ペーストイベント情報から、ペースト先サービスのURLと、ペースト位置XPathとを抽出し、これらをそれぞれ、図６に示すサービス連携情報テーブル１２２の連携先サービスURL領域１２２ｂ、連携先サービスXPath領域１２２ｃに格納する（Ｓ７５６，７５７）。

続いて、コピーイベント情報から、コピー元サービスのURLと、コピー位置XPathとを抽出し、これらをそれぞれ、図６に示すサービス連携情報テーブル１２２の連携元出力URL領域１２２ｄ、連携元出力XPath領域１２２ｅに格納する(Ｓ７５８，７５９）。

次に、サービス連携付け部１１６は、入出力情報テーブル１２１から、ステップ７５５で存在を確認した入出力情報、つまり、コピーイベント情報に対応する連携元サービス情報中に、リファラURLが存在するか否かを判断する（Ｓ７６０）。連携元サービス情報中にリファラURLが存在しなければ、ステップ７６３に進み、連携元サービス情報中にリファラURLが存在すれば、ステップ７６１に進む。

ステップ７６１で、サービス連携付け部１１６は、連携元サービス情報のリファラURLがリクエスト先URLとして格納されている直近の入出力情報を入出力情報テーブルから探し出し、この入出力情報のレスポンスボディと連携サービスのリクエスト先URL情報等から、リクエストの入力位置である連携元入力XPathを抽出し、これを図６に示すサービス連携情報テーブル１２２の連携元入力XPath領域ｇに格納する（Ｓ７６２）。なお、このステップ７６２の処理は、図４を用いて説明した前述のステップ７１０の処理を同じ処理である。

以上で、サービス同士の連携付けが終了する。

最後に、サービス連携付け部１１６は、連携先サービス情報と連携元サービス情報との連携強さを求め、これを図６に示すサービス連携情報テーブル１１２の連携強さ領域１２２ｈに格納して（Ｓ７６３）、サービス連携付け処理が終了する。なお、ここでの連携強さの計算では、例えば、コピーデータを構成する文字の数やHTMLのタグ情報に応じて強さが増減する式を予め準備しておき、この式を用いて連携強さを求めてもよいし、また、コピー＆ペーストイベントに基づくサービス連携付け処理では、予め定めた値を連携強さにしてもよい。

以上、本実施形態では、コピー＆ペーストイベント時においても、サービス連携情報が作成されるため、より多くのサービス連携情報を得ることができ、結果として、クライアント端末３００に多くの連携サービス情報を提供することができる。

「第三実施形態」
以下、本発明に係る第三実施形態について、図１４〜図１６を用いて説明する。

本実施形態の中継装置は、SaaS基盤で利用されるものである。ここで、SaaSとは、Software as a Serviceの略称であり、ソフトウェアの機能のうち、ユーザが必要とするものだけをサービスとして、Webを介して配布し利用できるようにしたWeb上におけるサービスの配布形態である。また、SaaS基盤とは、Webを介してサービスを配布するために、サービス提供者が提供したソフトウェアを動作させるための基盤である。

ユーザがSaaS基盤上で提供されるサービスを受けるためには、このサービスの提供者からのサービス購入等を含め、何らかの登録手続が必要である。

本実施形態では、SaaS基盤上で提供されるサービス（以下、特定サービスとする）が他のサービスと連携付けられた場合の、ユーザ及びこの特定サービスの提供者に対する利便性を上げるものである。

本実施形態の中継装置１００ｂは、図１４に示すように、ハードウェアー構成として、第一及び第二実施形態の中継装置１００,１００aに、キーボードやディスプレイ等の入出力装置１５０を追加したものである。

また、本実施形態の中継装置１００ｂは、機能構成として、第一実施形態の中継装置１００の機能構成の他に、サービス連携情報テーブル１２２中の各サービス連携情報が特定サービスの情報を連携させているか否かを判断する特定サービス連携判断部１６１と、入出力装置１５０からの指示で特定サービスの情報を連携させているサービス連携情報を入出力装置１５０で出力させるニーズ情報提供部１６２と、を有している。これらの機能部１６１，１６２も他の機能部と同様に、記憶装置１２０ｂに格納されているプログラム１２９ｂをＣＰＵ１１０ｂが実行することで機能する。

本実施形態の記憶装置１２０ｂには、第一実施形態における各種テーブル１２１，１２２に加えて、特定サービスの情報が格納されている特定サービス情報テーブル１２４と、特定サービスの情報を連携させているサービス連携情報が格納される連携利用ニーズ情報テーブル１２５とが設けられている。

特定サービス情報テーブル１２５には、特定サービスを受けるためのURLと、この特定サービスを利用可能な全ユーザの通信アドレスやログインのようなユーザ管理の機能がある場合にはユーザＩＤと、が相互に関係付けられて記憶されている。この特定サービス情報テーブル１２４に格納されるデータは、入出力装置１５０又は通信装置１４０ａを介して、特定サービスの提供元により定期的に更新される。

また、本実施形態のサービス連携情報テーブル１２２において、図６に示す各URL領域１２２ｂ，１２２ｄ、１２２ｆには、URLが格納される領域の他に、格納されているURLで特定されるサービスが特定サービスであるか否かを示すフラグ領域が設けられている。

次に、図１５に示すフローチャートに従って、特定サービス連携判断部１６１の動作について説明する。

特定サービス連携判断部１６１は、特定サービスのサーチタイミングになるまで待機し（S１５０１）、サーチタイミングになると、サービス連携情報テーブル１２２からサービス連携情報を一つ抽出する（Ｓ１５０２）。

特定サービス連携判断部１６１は、次に、ステップ１５０２で抽出したサービス連携情報中に、特定サービス情報テーブル１２４に格納されているいずれかの特定サービスのURLを含むか否かを判断する（Ｓ１５０３）。

特定サービス連携判断部１６１は、サービス連携情報中に特定サービスのURLが含まれていない場合には、この一連の処理を終了する。また、サービス連携情報中に特定サービスのURLが含まれている場合には、サービス連携情報テーブル１２２で、このサービス連携情報が格納されている行中で、このURLに関するフラグ領域にフラグを立てて、このURLが特定サービスのURLであることを示す（Ｓ１５０４）。

次に、特定サービス連携判断部１６１は、特定サービスのURLが含まれているサービス連携情報を連携利用ニーズ情報テーブル１２５に格納し、一連の処理を終了する。

次に、図１６に示すフローチャートに従って、本実施形態における連携サービス情報の添付処理について説明する。なお、同図中、図８に示す各ステップと同じ処理を行うステップに関しては、同一のステップ番号を付し、その詳細説明を省略する。

図８を用いて前述したように、連携サービス情報添付部１１７は、ステップ８０４，８０５，８０６で、レスポンス情報に連携サービス情報を添付した後、この連携サービス情報に連携するサービス情報を添付しないと判断すると（Ｓ８０８）、先に添付した連携サービス情報が特定サービス情報であるか否かを判断する（Ｓ８１１）。この判断は、ステップ８０２で取得したサービス連携情報を参照して、連携サービス情報のURLに対して、特定のサービスのURLであることを示すフラグが立てられているか否かで判断する。

連携サービス情報添付部１１７は、連携サービス情報が特定サービス情報ではないと判断すると、ステップ８１０に進み、連携サービス情報が特定サービス情報であると判断すると、ステップ８１２に進む。

連携サービス情報添付部１１７は、ステップ８１２で、特定サービス情報テーブル１２４を参照して、レスポンス情報の送付先ユーザが特定サービスを受けられるか否かを判断する（Ｓ８１２）。特定サービス情報テーブル１２５には、前述したように、特定サービスを受けるためのURLと、この特定サービスを利用可能な全ユーザの通信アドレスやログインのようなユーザ管理の機能がある場合にはユーザＩＤと、が相互に関係付けられて記憶されているため、連携サービス情報添付部１１７は、特定サービス情報テーブル１２４を参照して、連携サービス情報としての特定サービス情報に対して、レスポンス情報の送付先の通信アドレスやユーザＩＤが対応付けられているか否かで、以上の判断を行う。

連携サービス情報添付部１１７は、レスポンス情報の送付先ユーザが特定サービスを受けられると判断すると、ステップ８１０に進み、レスポンス情報の送付先ユーザが特定サービスを受けられないと判断すると、ステップ８１３に進む。

連携サービス情報添付部１１７は、ステップ８１３で、レスポンス情報に添付した連携サービス情報に、例えば、「このサービスは有料です。登録手続をして料金を支払ってください。」等のレコメンドを添付する（Ｓ８１３）。

そして、連携サービス情報添付部１１７は、連携サービス情報を添付したレスポンス情報をレスポンス転送部１１４に渡して（Ｓ８１０）、連携サービス情報の添付処理を終了する。

中継装置２００ｂにおいて、以上のような連携サービスの添付処理を行うことにより、本実施形態では、特定サービスを利用できないユーザであっても、連携サービス情報が特定サービスである場合には、ユーザが利用するクライアント端末２００には、前述のレコメンドと共に、連携サービス情報が出力される。具体的には、例えば、図９に示すように、路線検索受付情報（レスポンス情報）２１に対する最寄駅検索受付情報（連携元サービス情報）１１が、特定サービスであり、且つ、ユーザがこの特定サービスを受けられない場合には、クライアント端末２００には、路線検索受付情報（レスポンス情報）２１及び最寄駅検索受付情報（連携元サービス情報）１１と共に、この最寄駅検索受付情報１１に連携付けられて、「このサービスは有料です。登録手続をして料金を支払ってください。」等のレコメンドが表示される。

また、図１０に示すように、最寄駅検索結果情報（レスポンス情報）１５に対する路線検索受付情報（連携先サービス情報）２１が、特定サービスであり、且つ、ユーザがこの特定サービスを受けられない場合には、クライアント端末２００には、最寄駅検索結果情報（レスポンス情報）１５及び路線検索受付情報（連携先サービス情報）２１と共に、この路線検索受付情報２１に連携付けられて、前述のレコメンドが表示される。

以上のように、クライアント端末２００には、連携サービス情報が特定サービスの場合、連携サービス情報と共にレコメンドが表示されるので、このクライアント端末２００の利用者であるユーザに、この特定サービスの購入を促すことができる。なお、特定サービスを利用できないユーザが、特定サービスとしての連携サービス情報中の入力フォームに、何らかのデータを入力使用とした場合には、特定サービスの利用条件、例えば、特定サービスを利用するために必要なパスワードの入力等が求められる。

また、本実施形態では、特定サービスの提供者は、入出力装置１５０又は通信装置１４０ａを介して、ニーズ情報提供部１６２にアクセスすることで、特定サービスの情報を連携させているサービス連携情報を取得することができる。このため、サービス提供者は、この特定サービスの利用状況から、サービスのニーズ等を知り得て、新たなサービスの開発を促進させることができる。なお、ここでは、特定サービスの提供者に対して、特定サービスの情報を連携させているサービス連携情報を取得するだけに留まっているが、ニーズ情報提供部１６２は、このサービス連携情報に基づいて、レスポンス情報、及びこのレスポンス情報に連携する特定サービス情報を取得し、入出力装置１６０等により、ユーザに対して出力した態様と同じ態様で、つまり、図９及び図１０のように、レスポンス情報、及びこのレスポンス情報に連携する特定サービス情報を出力させるようにしてもよい。さらに、特定サービス情報と共にレコメンドを受け取ったユーザを示す情報も、併せて、入出力装置１６０等により、出力させるようにしてもよい。これは、連携サービス情報添付部１１７が、図１６に示すステップ８１２で、送信先ユーザは特定サービスを受けられないと判断した段階で、このユーザの通信アドレスやユーザＩＤ等を、連携利用ニーズ情報テーブル１２５に格納されているサービス連携情報に連携付けて記憶させることで、実現できる。

「第四実施形態」
以下、本発明に係る第四実施形態について、図１７を用いて説明する。

本実施形態は、クライアント端末２００ａに、第一実施形態の中継装置１００の諸機能を組み込んだものである。

本実施形態のクライアント端末２００ａは、コンピュータであり、各種演算処理を実行するＣＰＵ２１０と、ハードディスクドライブ装置等の記憶装置２２０と、ＣＰＵ２１０のワークエリア等になるメモリ２３０と、ネットワークＮを介してサーバ３００と通信するための通信装置２４０と、キーボードやディスプレイ等の入出力装置２５０と、を備えている。

ＣＰＵ２１０は、機能的に、第一実施形態の中継装置１００と同様、リクエスト受信部１１１、リクエスト転送部１１２、レスポンス受信部１１３、レスポンス転送部１１４、入出力情報収集部１１５、サービス連携付け部１１６、連携サービス情報添付部１１７とを有している。このＣＰＵ２１０は、さらに、Webサービスを受けるためのプラウザ部２１１と、外部のサービス連携情報サーバ４００とサービス連携情報の共有化を図るサービス連携情報共有化部２１２と、を有している。これらの機能部１１１〜１１７，２１１，２１２も、記憶装置２２０に格納されているプログラム２２９をＣＰＵ２１０が実行することで機能する。なお、本実施形態におけるクライアント端末２００ａのリクエスト受信部１１１及びレスポンス転送部１１２は、第一実施形態のリクエスト受信部１１１及びレスポンス転送部１１２のように、通信装置１４０ｂを介して情報の入出力を行わず、プラウザ部２１１を介して情報の入出力を行う。

記憶装置２２０には、プログラム２２９の他、第一実施形態の中継装置１００と同様、入出力情報テーブル１２１及びサービス連携情報テーブル１２２が設けられている。

本実施形態では、クライアント端末個別に、サービス連携情報、すなわち個別サービス連携情報を持つことが可能である。個別サービス連携情報を持つことで、第三者とサービス連携情報を必ずしも共有しなくてもよいことが特徴である。つまり、本実施形態により、外部に出したくない情報を持つサービスも連携させて利用することができる。

ところで、以上の各実施形態の中継装置１００，１００ａ，１００ｂは、いずれも、複数のクライアント端末２００とサーバ３００とのデータを中継することにより、複数のクライアント端末２００とサーバ３００との間の多数の入出力情報を得ることができ、その結果、多数のサービス連携情報を得ることができる。しかしながら、本実施形態のように、第一実施形態の中継装置１００の機能をクライアント端末２００ａに単に組み込んだだけでは、当該クライアント端末２００ａとサーバ３００との間の入出力情報のみしか得ることができず、その結果、サービス連携情報も多くは得られない。すなわち、個別サービス連携情報しか得られない。

そこで、本実施形態では、サービス連携情報供給化部２１２を設け、外部のサービス連携情報サーバ４００と通信することで、サービス連携情報サーバ４００が保持している複数の個別サービス情報、つまり集合サービス情報を取得できるようにしている。

サービス連携情報供給化部２１２は、サービス連携情報テーブル１２２が更新される毎に、更新された新たなサービス連携情報を、通信装置２４０を介して、サービス連携情報サーバ４００に送る。サービス連携情報サーバ４００は、サービス連携情報を受け取ると、自身が保持しているサービス連駅情報テーブル４２２に新たな行を確保し、この行に、このサービス連携情報を格納する。但し、連携強さを除いて同じ内容のサービス連携情報が既に存在する場合には、サービス連駅情報テーブル４２２に新たな行を確保することなく、既存のサービス連携情報の連携強さに、クライアント端末２００ａから送られてきたサービス連携情報の連携強さを加えるのみに留まる。

また、サービス連携情報サーバ４００は、サービス連携情報を受け取ると、自身が保持しているサービス連携情報テーブル４２２で、先にサービス連携情報をクライアント端末２００ａに送信してから、更新された又は追加されたサービス連携情報をクライアント端末２００ａに送る。クライアント端末２００ａのサービス連携情報供給化部２１２は、通信装置２４０を介して、サービス連携情報サーバ４００からサービス連携情報を受け取ると、これをサービス連携情報テーブル１２２に格納する。

連携サービス情報添付部１１７は、以上のように、サービス連携情報テーブル１２２に格納された個別サービス連携情報及び集合サービス連携情報を用いて、連携サービス情報を取得し、これをレスポンス情報に添付する。

なお、以上では、サービス連携情報テーブル１２２が更新される毎に、更新された新たなサービス連携情報を送り、サービス連携情報サーバ４００から更新された集合サービス連駅情報を受け取っているが、これを定期的に行うようにしてもよい。また、以上では、クライアント端末２００ａのサービス連携情報テーブル１２２に、サービス連携情報サーバ４００が保持している集合サービス連携情報を格納するようにしているが、これを実施せず、連携サービス情報添付部１１７が、サービス連携情報共有化部２１２を介して、サービス連携情報サーバ４００にアクセスできるようにしてもよい。

また、クライアント端末２００ａのサービス連携情報共有化部２１２は、新たなサービス連携情報をサービス連携情報サーバ４００に送る際、ユーザを識別する情報、例えば、クライアント端末２００ａの通信アドレスやユーザＩＤ等を併せて送るようにしてもよい。これにより、サービス連携情報サーバ４００側では、ユーザ毎の利用状況等を収集することができる。

また、連携サービス情報添付部１１７は、サービス連携情報を取得する際、個別サービス連携情報と集合サービス連携情報とのうち、いずれか一方を選択できる、又は両方を選択できるようにしてもよい。この場合、ユーザがクライアント端末２００ａに、どちらの情報を選択するか、又は両方の情報を選択するかを、事前に設定しておく。また、一方の情報のみが選択された場合でも、レスポンス情報と共に連携サービス情報を出力した段階で、他方の情報の選択を受け付け、この他方の情報に基づき、新たな連携サービス情報を別途出力できるようにしてもよい。

また、本実施形態は、クライアント端末２００ａに、第一実施形態の中継装置１００の諸機能を組み込んだものであるが、サービス提供サーバ３００に、第一実施形態等の中継装置の諸機能を組み込んでもよい。この場合、このサービス提供サーバ３００は、複数のクライアント端末からアクセスされるため、サービス連携情報として集合サービス連携情報を所有することになる。したがって、この場合には、本実施形態のように、サービス連携情報サーバ４００は基本的に不要になる。但し、他のサービス提供サーバとの間で、サービス連携情報を共有化したい場合には、サービス連携情報サーバ４００を設けてもよい。

本発明に係る第一実施形態の中継装置の構成図である。 本発明に係る第一実施形態のシステムのシーケンス図である。 本発明に係る第一実施形態の入出力情報テーブルのデータ構成を示す説明図である。 本発明に係る第一実施形態のサービス連携付け処理の詳細処理を示すフローチャートである。 図４におけるＳ７０２の詳細処理を示すフローチャートである。 本発明に係る第一実施形態のサービス連携情報テーブルのデータ構成を示す説明図である。 本発明に係る第一実施形態のサービス連携情報の作成方法を示す説明図である。 本発明に係る第一実施形態の連携サービス情報の添付処理の詳細処理を示すフローチャートである。 本発明に係る第一実施形態のクライアント端末での連携サービス情報の提示例（その１）を示す説明図である。 本発明に係る第一実施形態のクライアント端末での連携サービス情報の提示例（その２）を示す説明図である。 各種サービスにおける情報の相互関係を示す説明図である。 本発明に係る第二実施形態の中継装置の構成図である。 本発明に係る第二実施形態のコピー＆ペースイベント発生時のサービス連携付け処理を示すフローチャートである。 本発明に係る第三実施形態の中継装置の構成図である。 本発明に係る第三実施形態の特定サービスの連携判断処理を示すフローチャートである。 本発明に係る第三実施形態の連携サービス情報の添付処理を示すフローチャートである。 本発明に係る第四実施形態のクライアント端末の構成図である。

１００，１００ａ，１００ｂ：サービス中継装置、１１０，１１０ａ，１１０ｂ,２１０：ＣＰＵ，１１１：リクエスト受信部、１１２：リクエスト転送部、１１３：レスポンス受信部、１１４：レスポンス転送部、１１５：入出力情報収集部、１１６：サービス連携付け部、１１７：連携サービス情報添付部、１１８：イベント検出器添付部、１１９：イベント情報受信部、１２０，１２０ａ，１２０ｂ，２２０：記憶装置、１２１：入出力情報テーブル、１２２：サービス連携情報テーブル、１２３：イベント情報テーブル、１２４：特定サービス情報テーブル、１２５：連携利用ニーズ情報テーブル、１２９,１２９ａ，１２９ｂ，２２９：プログラム、１４０ａ，１４０ｂ，２４０：通信装置、１５０，２５０：入出力装置、１６１：特定サービス連携判断部、１６２：ニーズ情報提供部、２００，２００ａ：クライアント端末、２１１：ブラウザ部、２１２：サービス連携情報共有化部、３００：サービス提供サーバ、４００：サービス連携情報サーバ

Claims (12)

1. サービスを提供するサービス提供部と、サービスの提供を受けるクライアント部との間の入出力を中継するサービス中継装置において、
   前記クライアント部からの入力情報を受け付けて、該入力情報を前記サービス提供部に渡すと共に、該入力情報を受け付けた前記サービス提供部からの出力情報を受け付けて、該出力情報を該クライアント部に渡す中継手段と、
   前記中継手段が前記クライアント部から受け付けた入力情報であって、リファラＵＲＬ、当該入力情報を受け付けたリクエスト取得時刻、及び当該入力情報に含まれる文字列の情報であるリクエスト文字列情報を含む入力情報と、該中継手段が前記サービス提供部から受け付けた該入力情報に対する出力情報であって、当該出力情報を受け付けた時刻であるレスポンス取得時刻及び当該出力情報に含まれる文字列の情報であるレスポンス文字列情報を含む出力情報と、を前記クライアントからの入力順を示すｉｄ毎に連携付けて、入出力情報として収集する入出力情報収集手段と、
   前記入出力情報収集手段により、前記入出力情報が記憶される入出力情報記憶手段と、
   前記入出力情報記憶手段に記憶されている複数の前記入出力情報毎に、当該入出力情報の入力情報と他の入出力情報の出力情報との一致性を、予め定められたルールに従って調べて、該一致性があれば、該入力情報と該他の入出力情報とを連携付けるサービス連携情報を作成するサービス連携付け手段であって、前記レスポンス取得時刻が、前記ｉｄの値が所定の値の入出力情報である連携先サービス情報のリクエスト取得時刻より前の時刻の入出力情報を複数の前記入出力情報から抽出し、当該抽出された入出力情報のレスポンス文字列情報に前記連携先サービス情報のリクエスト文字列情報が含まれている場合に、前記連携先サービス情報のリファラＵＲＬと前記抽出された入出力情報のリファラＵＲＬとを連携づけるサービス連携付け手段と、
   前記サービス連携付け手段により、前記サービス連携情報が記憶されるサービス連携情報記憶手段と、
   前記中継手段が前記サービス提供部からの出力情報を受け付けると、前記サービス連携情報記憶手段に記憶されている前記サービス連携情報のうちで、該出力情報を連携付けているサービス連携情報がある場合には、該サービス連携情報に基づいて該出力情報に連携する連携サービス情報を取得し、該出力情報に該連携サービス情報を添付して、前記中継手段により、該連携サービス情報が添付された該出力情報を前記クライアント部に渡させる連携サービス情報添付手段と、
   を備えていることを特徴とするサービス中継装置。
2. 請求項１に記載のサービス中継装置において、
   前記出力情報には、該出力情報の送信元を特定するレスポンスURL（Uniform Resource Locator）を含み、
   前記サービス連携情報には、連携先に対する連携元の出力情報の送信元を特定する連携元出力URLと、該連携先の入力情報の送信先を特定する連携先サービスURLとを含み、
   前記連携サービス情報添付手段は、前記中継手段が前記サービス提供部からの出力情報を受け付けると、前記サービス連携情報記憶手段に記憶されている前記サービス連携情報のうちで、該出力情報中の前記レスポンスURLが連携元出力URLとなっているサービス連携情報がある場合には、該出力情報が連携元サービス情報であるとして、該サービス連携情報中の前記連携先サービスURLで特定される情報を連携先サービス情報として取得し、該出力情報に該連携先サービス情報を添付する、
   ことを特徴とするサービス中継装置。
3. 請求項２に記載のサービス中継装置において、
   前記サービス連携情報には、連携先に対する連携元の出力情報中のレスポンスパラメータの位置を示す連携元出力位置情報と、該連携先の入力情報中の入力フォームの位置を示す連携先入力位置情報とを含み、
   前記連携サービス情報添付手段は、前記出力情報中の前記レスポンスURLが連携元出力URLとなっている前記サービス連携情報が前記サービス連携情報記憶手段にある場合、該サービス連携情報中の連携元出力位置情報で特定される該出力情報中のレスポンスパラメータの位置と、該サービス連携情報中の前記連携先入力位置情報で特定される前記入力フォームとの位置とを関係付ける属性情報を該出力情報に添付する、
   ことを特徴とするサービス中継装置。
4. 請求項１に記載のサービス中継装置において、
   前記出力情報には、該出力情報の送信元を特定するレスポンスURL（Uniform Resource Locator）を含み、
   前記サービス連携情報には、連携先の入力情報の送信先を特定する連携先サービスURLと、該連携先に対する連携元の入力情報の送信先を特定する連携元入力URLとを含み、
   前記連携サービス情報添付手段は、前記中継手段が前記サービス提供部からの出力情報を受け付けると、前記サービス連携情報記憶手段に記憶されている前記サービス連携情報のうちで、該出力情報中の前記レスポンスURLが連携先サービスURLとなっているサービス連携情報がある場合には、該出力情報が連携先サービス情報であるとして、該サービス連携情報中の前記連携元入力URLで特定される情報を連携元サービス情報として取得し、該出力情報に該連携元サービス情報を添付する、
   ことを特徴とするサービス中継装置。
5. 請求項４に記載のサービス中継装置において、
   前記サービス連携情報には、連携先の入力情報中の入力フォームの位置を示す連携先入力位置情報と、該連携先に対する連携元の入力情報中の入力パラメータの位置を示す連携元入力位置情報と、を含み、
   前記連携サービス情報添付手段は、前記出力情報中の前記レスポンスURLが連携先サ
   ビスURLとなっている前記サービス連携情報が前記サービス連携情報記憶手段にある場合、該サービス連携情報中の前記連携先入力位置情報で特定される該出力情報中の入力フォームの位置と、該サービス連携情報中の前記連携元入力位置情報で特定される前記入力フォームとの位置とを関係付ける属性情報を該出力情報に添付する、
   ことを特徴とするサービス中継装置。
6. 請求項１から５のいずれか一項に記載のサービス中継装置において、
   前記サービス連携付け手段は、前記入出力情報記憶手段に記憶されている複数の前記入出力情報毎に、当該入出力情報の入力情報と他の入出力情報の出力情報との一致性を調べて、該一致性があれば、該入力情報と該他の入出力情報との連携強さを予め定められたルールに従って求め、該連携強さを前記サービス連携情報に含め、
   前記連携サービス情報添付手段は、前記サービス連携情報記憶手段中に、前記サービス提供部からの前記出力情報を連携付けているサービス連携情報が複数ある場合、前記出力情報を連携付けている複数の該サービス連携情報のうち、強い連携強さを含むサービス連携情報を優先的に取得し、該サービス連携情報に基づいて、該出力情報に添付する連携サービス情報を取得する、
   ことを特徴とするサービス中継装置。
7. 請求項１から６のいずれか一項に記載のサービス中継装置において、
   前記連携サービス情報添付手段は、前記出力情報に前記連携サービス情報を添付すると共に、該連携サービス情報を新たな出力情報とし、前記サービス連携情報記憶手段に記憶されている前記サービス連携情報のうちで、該新たな出力情報を連携付けているサービス連携情報がある場合には、該サービス連携情報に基づいて該新たな出力情報に連携する連携サービス情報を取得し、該新たな出力情報に該連携サービス情報を添付する、
   ことを特徴とするサービス中継装置。
8. 請求項１から７のいずれか一項に記載のサービス中継装置において、
   前記出力情報を受けた前記クライアント部で、該出力情報中に含まれている一部のデータがコピーされると該コピーを検知すると共に、該クライアント部で、コピーされた該データが他のサービスの入力情報の一部としてペーストされると該ぺーストを検知するイベント検知手段を備え、
   前記サービス連携付け手段は、前記イベント検知手段により、前記出力情報中に含まれている一部のデータのコピーが検知され、且つコピーされた該データが他のサービスの入力情報の一部としてペーストされて該ペーストが検知されると、該出力情報と該他のサービスの入力情報とを連携付けるサービス連携情報を作成し、該サービス連携情報を前記サービス連携情報記憶手段に記憶する、
   ことを特徴とするサービス中継装置。
9. 請求項１から８のいずれか一項に記載のサービス中継装置において、
   サービスの提供受けるにあたって登録処理が必要な、１以上の特定のサービスの情報が記憶される特定サービス記憶手段と、
   前記サービス連携情報記憶手段に記憶されている全ての前記サービス連携情報に関して、前記特定サービス記憶手段に記憶されている前記１以上の特定のサービスのうち、いずれかのサービスが連携付けられているか否かを判断する判断手段と、
   前記判断手段により、前記特定サービス記憶手段に記憶されているいずれかの特定のサービスが連携付けられていると判断された前記サービス連携情報を提示する特定サービス連携情報提示手段と、
   を備えていることを特徴とするサービス中継装置。
10. 請求項９に記載のサービス中継装置において、
    前記連携サービス情報添付手段は、前記出力情報に前記連携サービス情報を添付する際、該連携サービス情報が示すサービス情報が、前記判断手段により、前記特定サービス記憶手段に記憶されているいずれかの特定のサービスの情報であると判断されている場合に、該連携サービス情報に、当該連携サービス情報の利用には登録処理が必要である旨の情報を添付する、
    ことを特徴とするサービス中継装置。
11. サービスの提供を受けるクライアント部からの入力情報を受け付けて、該入力情報をサービスを提供するサービス提供部に渡す手順と、
    前記入力情報を受け付けた前記サービス提供部からの出力情報を受け付ける手順と、
    前記クライアント部から受け付けた入力情報であって、リファラＵＲＬ、当該入力情報を受け付けたリクエスト取得時刻、及び当該入力情報に含まれる文字列の情報であるリクエスト文字列情報を含む入力情報と、前記サービス提供部から受け付けた出力情報であって、当該出力情報を受け付けた時刻であるレスポンス取得時刻及び当該出力情報に含まれる文字列の情報であるレスポンス文字列情報を含む出力情報とを連携付けて入出力情報として、コンピュータの記憶手段に記憶する手順と、
    前記記憶手段に記憶されている一以上の前記入出力情報毎に、当該入出力情報の入力情報と他の入出力情報の出力情報との一致性を、予め定められたルールに従って調べて、該一致性があれば、該入力情報と該他の入出力情報とを連携付けるサービス連携情報であって、前記レスポンス取得時刻が、前記ｉｄの値が所定の値の入出力情報である連携先サービス情報のリクエスト取得時刻より前の時刻の入出力情報を複数の前記入出力情報から抽出し、当該抽出された入出力情報のレスポンス文字列情報に前記連携先サービス情報のリクエスト文字列情報が含まれている場合に、前記連携先サービス情報のリファラＵＲＬと前記抽出された入出力情報のリファラＵＲＬとを連携づけるサービス連携情報を作成し、該サービス連携情報を前記記憶手段に記憶する手順と、
    前記サービス提供部からの出力情報を受け付けると、前記記憶手段に記憶されている１以上の前記サービス連携情報のうちで、該出力情報を連携付けているサービス連携情報がある場合には、該サービス連携情報に基づいて該出力情報に連携する連携サービス情報を取得する手順と、
    前記出力情報に前記取得した連携サービス情報を添付して、該連携サービス情報が添付された該出力情報を前記クライアント部に渡す手順と、
    を前記コンピュータに実行させることを特徴とするサービス中継プログラム。
12. サービスの提供を受けるクライアント部からの入力情報を受け付けて、該入力情報をサービスを提供するサービス提供部に渡すステップと、
    前記入力情報を受け付けた前記サービス提供部からの出力情報を受け付けるステップと、
    前記クライアント部から受け付けた入力情報であって、リファラＵＲＬ、当該入力情報を受け付けたリクエスト取得時刻、及び当該入力情報に含まれる文字列の情報であるリクエスト文字列情報を含む入力情報と、前記サービス提供部から受け付けた出力情報であって、当該出力情報を受け付けた時刻であるレスポンス取得時刻及び当該出力情報に含まれる文字列の情報であるレスポンス文字列情報を含む出力情報と、を前記クライアントからの入力順を示すｉｄ毎に連携付けて入出力情報として、コンピュータの記憶手段に記憶するステップと、
    前記記憶手段に記憶されている一以上の前記入出力情報毎に、当該入出力情報の入力情報と他の入出力情報の出力情報との一致性を、予め定められたルールに従って調べて、該一致性があれば、該入力情報と該他の入出力情報とを連携付けるサービス連携情報であって、前記レスポンス取得時刻が、前記ｉｄの値が所定の値の入出力情報である連携先サービス情報のリクエスト取得時刻より前の時刻の入出力情報を複数の前記入出力情報から抽出し、当該抽出された入出力情報のレスポンス文字列情報に前記連携先サービス情報のリクエスト文字列情報が含まれている場合に、前記連携先サービス情報のリファラＵＲＬと前記抽出された入出力情報のリファラＵＲＬとを連携づけるサービス連携情報を作成し、該サービス連携情報を前記記憶手段に記憶するステップと、
    前記サービス提供部からの出力情報を受け付けると、前記記憶手段に記憶されている１以上の前記サービス連携情報のうちで、該出力情報を連携付けているサービス連携情報がある場合には、該サービス連携情報に基づいて該出力情報に連携する連携サービス情報を取得するステップと、
    前記出力情報に前記取得した連携サービス情報を添付して、該連携サービス情報が添付された該出力情報を前記クライアント部に渡すステップと、
    を前記コンピュータが実行することを特徴とするサービス中継方法。

Images