(57)【要約】【課題】利用者が期待する加工処理を実行した情報を提供することを課題とする。【解決手段】アグリゲーターサーバは、利用者に提供されるサービスを用いた情報の取得要求と、取得要求で取得された情報に対する加工内容とを含むサービス要求を受信し、アグリゲーションサービスを利用して、取得要求で要求された情報を取得する。アグリゲーターサーバは、サービスを提供する実行環境と分離する実行環境を生成し、取得された情報に対して、分離する実行環境を用いて加工内容にしたがった加工処理を実行し、加工処理の結果をサービス要求の要求元に提供する。【選択図】図３
2019008736.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータが、
利用者に提供されるサービスを用いた情報の取得要求と、前記取得要求で取得された情報に対する加工内容とを含むサービス要求を受信し、
前記取得要求で要求された情報を取得し、
前記サービスを提供する実行環境と分離する実行環境を生成し、
取得された前記情報に対して、分離する前記実行環境を用いて前記加工内容にしたがった加工処理を実行し、
前記加工処理の結果を前記サービス要求の要求元に提供する
処理を実行することを特徴とするサービス提供方法。
【請求項２】
前記受信する処理は、前記加工内容が記述されるスクリプトを含む前記サービス要求を受信し、
前記生成する処理は、前記サービスを提供する実行環境と分離する実行環境として、仮想化ソフトウェアを用いて論理的に独立した空間を生成し、
前記実行する処理は、前記論理的に独立した空間上で、前記スクリプトを実行することを特徴とする請求項１に記載のサービス提供方法。
【請求項３】
前記スクリプトの実行開始から実行完了までに、前記スクリプトが使用したリソース量を計測し、
前記リソース量によって料金単価を規定した料金プランにしたがって、前記スクリプトの実行に伴う請求金額を算出する処理を、前記コンピュータが実行することを特徴とする請求項２に記載のサービス提供方法。
【請求項４】
時間帯または利用者数にしたがって、前記スクリプトが使用するリソースの使用量の単価を更新し、
利用者が前記スクリプトの実行を許可する利用単価を受信し、
更新される前記リソースの使用量の単価が前記利用単価を満たすまで、前記スクリプトの実行を抑制し、更新される前記リソースの使用量の単価が前記利用単価を満たす場合に、前記スクリプトを実行する処理を、前記コンピュータが実行することを特徴とする請求項２に記載のサービス提供方法。
【請求項５】
前記スクリプトに記述されるステップ数を計測し、
前記ステップ数によって料金単価を規定した料金プランにしたがって、前記スクリプトの実行に伴う請求金額を算出する処理を、前記コンピュータが実行することを特徴とする請求項２に記載のサービス提供方法。
【請求項６】
前記利用者が生成した前記スクリプトを記憶部に保持し、
前記スクリプトを前記記憶部から読み出して、前記論理的に独立した空間上で、前記スクリプトを実行する処理を、前記コンピュータが実行することを特徴とする請求項２に記載のサービス提供方法。
【請求項７】
前記スクリプトを実行する際に、前記スクリプト内に記述されるステージゲート機能を呼び出して実行し、
前記スクリプトの実行が完了するまでの途中結果を、前記ステージゲート機能にしたがって出力する処理を、前記コンピュータが実行することを特徴とする請求項２に記載のサービス提供方法。
【請求項８】
前記利用者が前記スクリプトの実行に使用するプロセッサの実行時間を指定する指定時間を受信し、
前記スクリプトの実行が開始されると、前記スクリプトが使用した前記プロセッサの実行時間を計測し、
前記プロセッサの実行時間が前記指定時間を越えた場合、前記スクリプトが実行途中であっても、前記スクリプトの実行を強制的に終了させる処理を、前記コンピュータが実行することを特徴とする請求項２に記載のサービス提供方法。
【請求項９】
前記受信する処理は、前記サービス要求とともに、前記サービスを利用した情報取得時のエラーに対するエラー処理対応を受信し、
前記取得する処理は、前記サービスを利用した前記情報取得時にエラーが発生した場合、前記エラー処理対応にしたがった処理を実行することを特徴とする請求項１に記載のサービス提供方法。
【請求項１０】
前記サービスを利用して過去に取得された前記情報を、所定の記憶部にキャッシュ情報として保持する処理を前記コンピュータが実行し、
前記受信する処理は、前記サービス要求とともに、前記キャッシュ情報の使用を許可する、前記キャッシュ情報が取得された日時を指定する鮮度情報を受信し、
前記取得する処理は、前記キャッシュ情報が前記鮮度情報を満たす場合は、前記キャッシュ情報を前記所定の記憶部から取得し、前記キャッシュ情報が前記鮮度情報を満たさない場合は、前記サービスを利用して前記情報を取得することを特徴とする請求項１に記載のサービス提供方法。
【請求項１１】
コンピュータに、
利用者に提供されるサービスを用いた情報の取得要求と、前記取得要求で取得された情報に対する加工内容とを含むサービス要求を受信し、
前記取得要求で要求された情報を取得し、
前記サービスを提供する実行環境と分離する実行環境を生成し、
取得された前記情報に対して、分離する前記実行環境を用いて前記加工内容にしたがった加工処理を実行し、
前記加工処理の結果を前記サービス要求の要求元に提供する
処理を実行させることを特徴とするサービス提供プログラム。
【請求項１２】
利用者に提供されるサービスを用いた情報の取得要求と、前記取得要求で取得された情報に対する加工内容とを含むサービス要求を受信する受信部と、
前記取得要求で要求された情報を取得する取得部と、
前記サービスを提供する実行環境と分離する実行環境を生成する生成部と、
取得された前記情報に対して、分離する前記実行環境を用いて前記加工内容にしたがった加工処理を実行する加工部と、
前記加工処理の結果を前記サービス要求の要求元に提供する提供部と
を有することを特徴とするサービス提供装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービス提供方法、サービス提供プログラムおよびサービス提供装置に関する。
【背景技術】
【０００２】
従来から、クラウドサービスと呼ばれる、ネットワークを通じて利用するサービスが一般的に利用されている。また、ＷｅｂＡＰＩ（Application  Programming  Interface）として提供されているサービスも増えており、一般に提供されているＷｅｂＡＰＩで公開されたサービスリソースを活用することで、企業側はシステム開発コストの削減や利用者側は手軽にデータを収集して利用できる。
【０００３】
近年では、複数の企業が提供するサービスを集約し、１つのサービスとして提供するアグリゲーションサービスが増加している。例えば、旅行サービスでは、ホテルや航空券の情報を横断的に検索し動的に組み合わせて提供できるダイナミックパッケージと呼ばれるサービスが知られている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１７−４９９９３号公報
【特許文献２】特表２０１７−５０５４８３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記技術では、アグリゲーションサービスで集約される各サービスから情報を取得しても、取得された情報に対して、アグリゲーションサービスが提供する加工処理しか行うことができず、利用者が期待する情報を提供することができない。
【０００６】
具体的には、アグリゲーションサービスを提供する企業側は、利用者のすべての要望に応えるサービスを事前に開発して提供することが現実的に難しいので、利用頻度の高い加工処理だけを提供する。また、企業側は、利用者によるサービスの自由な加工処理を、サービスの安全性や運用性への影響から許可できない。
【０００７】
このため、利用者は、アグリゲーションサービスから提供された範囲でしかサービスを受けられないので、受信したデータを必要とする情報に加工することになる。例えば、アグリゲーションサービスでは独自のアルゴリズムで抽出され並び順が決定されるので、利用者は、アグリゲーションサービスで取得した情報を自分の調べたいランキングなどに並び替える。また、利用者側がＪＳＯＮ（JavaScript（登録商標）  Object  Notation）形式のフォーマットで情報を取得したいときに、アグリゲーションサービスからＸＭＬ（eXtensible  Markup  Language）形式のフォーマットで情報が提供される場合がある。この場合、利用者側が、アグリゲーションサービスから情報を取得した後に、利用者の手元で、ＸＭＬからＪＳＯＮ形式にフォーマット変換することになる。
【０００８】
一つの側面では、利用者が期待する加工処理を実行した情報を提供することができるサービス提供方法、サービス提供プログラムおよびサービス提供装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
第１の案では、サービス提供方法は、コンピュータが、利用者に提供されるサービスを用いた情報の取得要求と、前記取得要求で取得された情報に対する加工内容とを含むサービス要求を受信する処理を実行する。サービス提供方法は、コンピュータが、前記取得要求で要求された情報を取得する処理を実行する。サービス提供方法は、コンピュータが、前記サービスを提供する実行環境と分離する実行環境を生成する処理を実行する。サービス提供方法は、コンピュータが、取得された前記情報に対して、分離する前記実行環境を用いて前記加工内容にしたがった加工処理を実行し、前記加工処理の結果を前記サービス要求の要求元に提供する処理を実行する。
【発明の効果】
【００１０】
一実施形態によれば、利用者が期待する加工処理を実行した情報を提供することができる。
【図面の簡単な説明】
【００１１】
【図１】図１は、実施例１にかかるシステムの全体構成例を示す図である。
【図２】図２は、実施例１にかかるサービス提供形態を説明する図である。
【図３】図３は、実施例１にかかるアグリゲーターサーバの機能構成を示す機能ブロック図である。
【図４】図４は、利用者情報ＤＢに記憶される利用者情報の例を示す図である。
【図５】図５は、ＡＰＩ情報ＤＢに記憶されるＡＰＩ情報の例を示す図である。
【図６】図６は、使用量ＤＢに記憶される使用量の例を示す図である。
【図７】図７は、アグリゲーションサービスによる取得結果を説明する図である。
【図８】図８は、ユーザスクリプトの実行例を説明する図である。
【図９】図９は、処理シーケンスを示す図である。
【図１０】図１０は、実施例２にかかるアグリゲーターサーバの機能構成を示す機能ブロック図である。
【図１１】図１１は、料金プランＤＢに記憶される料金プランの例を示す図である。
【図１２】図１２は、リソース使用量ＤＢに記憶される使用量の例を示す図である。
【図１３】図１３は、実施例３にかかるアグリゲーターサーバの機能構成を示す機能ブロック図である。
【図１４】図１４は、リソース平均単価ＤＢに記憶される単価の遷移例を示す図である。
【図１５】図１５は、利用者が指定する利用単価の例を示す図である。
【図１６】図１６は、実施例３にかかる処理シーケンスを示す図である。
【図１７】図１７は、実施例４にかかるアグリゲーターサーバの機能構成を示す機能ブロック図である。
【図１８】図１８は、実施例４にかかる料金プランＤＢに記憶される料金プランの例を示す図である。
【図１９】図１９は、実施例４にかかる処理シーケンスを示す図である。
【図２０】図２０は、実施例５にかかる処理シーケンスを示す図である。
【図２１】図２１は、実施例６にかかる処理シーケンスを示す図である。
【図２２】図２２は、実施例７にかかる処理シーケンスを示す図である。
【図２３】図２３は、実施例８にかかる処理シーケンスを示す図である。
【図２４】図２４は、実施例９にかかる処理シーケンスを示す図である。
【図２５】図２５は、実施例１０にかかる処理シーケンスを示す図である。
【図２６】図２６は、ハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１２】
以下に、本願の開示するサービス提供方法、サービス提供プログラムおよびサービス提供装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は矛盾のない範囲内で適宜組み合わせることができる。
【実施例１】
【００１３】
［全体構成］
図１は、実施例１にかかるシステムの全体構成例を示す図である。図１に示すように、このシステムは、複数の利用者端末１と複数のＡＰＩサーバ２とアグリゲーターサーバ１０とが、ネットワークＮを介して相互に通信可能に接続される。なお、ネットワークＮには、有線や無線を問わず、インターネットなどの各種ネットワークを採用することができる。また、各装置の数などは、一例であり、図示したものに限定されない。また、ここでは、サービスの一例としてアグリゲーションサービスを例にして説明するが、これに限定されるものではなく、インターネットなどを用いた情報検索など、利用者に提供される各種サービスを採用することができる。
【００１４】
各利用者端末１はアグリゲーションサービスを利用するユーザの端末であり、例えばＷｅｂブラウザが利用できるスマートフォンやパーソナルコンピュータなどのコンピュータの一例である。各ＡＰＩサーバは、ＷｅｂＡＰＩで公開されるサービス（サービスＡＰＩ）を提供するサーバ装置の一例である。例えば、各ＡＰＩサーバ２は、ホテルや航空券などの検索サービスを提供する。
【００１５】
アグリゲーターサーバ１０は、各ＡＰＩサーバ２が提供するサービスを集約して、１つのサービスとして各利用者端末１に提供するアグリゲーションサービスを実行するサーバ装置であり、サービス提供装置の一例である。例えば、アグリゲーターサーバ１０は、各ＡＰＩサーバ２が提供するホテルや航空券などの検索サービスを横断的に検索し、検索結果を動的に組み合わせて提供するダイナミックパッケージサービスを提供する。
【００１６】
ここで、アグリゲーターサーバ１０によるアグリゲーションサービスについて説明する。図２は、実施例１にかかるサービス提供形態を説明する図である。図２に示すように、アグリゲーターサーバ１０は、利用者端末１からサービス要求を受信すると、各ＡＰＩサーバ２に対応するＷｅｂＡＰＩを読み出して各ＡＰＩサーバ２が提供するサービスを利用して、要求された検索を実行して情報を取得する。そして、アグリゲーターサーバ１０は、各ＡＰＩサーバ２から得られた情報を集約して、サービス要求元の利用者端末１に送信する。
【００１７】
［機能構成］
次に、アグリゲーターサーバ１０の機能構成について説明する。なお、各利用者端末１は、一般的なコンピュータ装置と同様の構成を有し、各ＡＰＩサーバ２は、一般的なＡＰＩサーバと同様の構成を有するので、ここでは、詳細な説明は省略する。
【００１８】
図３は、実施例１にかかるアグリゲーターサーバ１０の機能構成を示す機能ブロック図である。図３に示すように、アグリゲーターサーバ１０は、通信部１１、記憶部２０、制御部３０を有する。
【００１９】
通信部１１は、各利用者端末１や各ＡＰＩサーバ２との通信を制御する処理部であり、例えば通信インタフェースや無線インタフェースなどである。この通信部１１は、各利用者端末１から、サービス要求であるＨＴＴＰ（Hypertext  Transfer  Protocol）リクエストなどを受信する。また、通信部１１は、各ＡＰＩサーバへ情報取得要求を送信し、各種情報を取得する。また、通信部１１は、各利用者端末１へ、各種リクエストの応答を送信する。
【００２０】
記憶部２０は、データやプログラムなどを記憶する記憶装置であり、例えばメモリやハードディスクなどである。この記憶部２０は、利用者情報ＤＢ２１とＡＰＩ情報ＤＢ２２と使用量ＤＢ２３とを記憶する。
【００２１】
利用者情報ＤＢ２１は、アグリケーションサービスを利用する利用者に関する情報を記憶するデータベースである。図４は、利用者情報ＤＢ２１に記憶される利用者情報の例を示す図である。図４に示すように、利用者情報ＤＢ２１は、「ＵｓｅｒＩＤ、名前、請求先情報」を対応付けて記憶する。ここで記憶される「ＵｓｅｒＩＤ」は、利用者を識別する識別情報である。「名前」は、利用者の名前である。「請求先情報」は、利用料金を請求するための情報であり、例えばクレジットカードの番号などである。
【００２２】
図４の例では、ＵｓｅｒＩＤ「＃１」の利用者「ＸＸＸ」の請求先情報として「Ｘｘｘｘ−ｘｘｘｘ−ｘｘｘｘ」のクレジットカード番号が登録されていることを示す。なお、ここで登録される情報は、利用者の新規登録時に登録されるものであり、随時更新することができる。
【００２３】
ＡＰＩ情報ＤＢ２２は、各ＡＰＩサーバ２によって提供されるＷｅｂＡＰＩに関する情報を記憶するデータベースである。図５は、ＡＰＩ情報ＤＢ２２に記憶されるＡＰＩ情報の例を示す図である。図５に示すように、ＡＰＩ情報ＤＢ２２は、「ＡＰＩ  ＩＤ、ＵＲＩ（Uniform  Resource  Identifier）、サービス名、呼出ＡＰＩｓ」を対応付けて記憶する。
【００２４】
ここで記憶される「ＡＰＩ  ＩＤ」は、サービスＡＰＩを識別する識別子である。「ＵＲＩ」は、サービスＡＰＩの提供元を識別する情報である。「サービス名」は、ＷｅｂＡＰＩで提供されるサービスサービスの名称である。「呼出ＡＰＩｓ」は、呼出対象のＡＰＩを特定する情報である。
【００２５】
図５の例では、ＡＰＩ  ＩＤ「＃１」のサービスＡＰＩは、ＵＲＩ「http://www/aaabbbccc/com/api/v01/plans」で指定されて、「ＡＰＩａ」と「ＡＰＩｂ」とが呼び出されるＨｏｔｅｌＰｌａｎｓの取得サービスであることを示す。なお、ＨｏｔｅｌＰｌａｎｓとは、例えばホテルが提供する宿泊プランなどである。また、ここで記憶される情報は、サービスＡＰＩやアグリゲーターサーバ１０などの管理者によって更新される。
【００２６】
使用量ＤＢ２３は、利用者ごとに、アグリゲーションサービスの利用記録を記憶するデータベースである。図６は、使用量ＤＢ２３に記憶される使用量の例を示す図である。図６に示すように、使用量ＤＢ２３は、「ＵｓｅｒＩＤ、ＡＰＩ呼出回数、請求金額」を対応付けて記憶する。
【００２７】
ここで記憶される「ＵｓｅｒＩＤ」は、利用者を識別する識別情報である。「ＡＰＩ呼出回数」は、利用者がＷｅｂＡＰＩを呼び出した回数であり、アグリゲーションサービスの利用回数である。「請求金額」は、利用者に請求する、アグリゲーションサービスの利用料金である。図６の例では、ＵｓｅｒＩＤ「＃１」の利用者がＷｅｂＡＰＩを「１２０」回呼び出したので、請求金額が「１２０００」円であることを示す。なお、ここでは、請求金額は、ＡＰＩ呼出回数によって算出される例を示すが、これに限定されるものではない。
【００２８】
制御部３０は、アグリゲーターサーバ１０全体を司る処理部であり、例えばプロセッサなどである。この制御部３０は、要求処理部４０と判定部５０と集約部５１とスクリプト管理部６０と結果応答部７０を有する。なお、要求処理部４０と判定部５０と集約部５１とスクリプト管理部６０と結果応答部７０は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例などである。
【００２９】
要求処理部４０は、要求受信部４１と分配処理部４２と応答受信部４３とを有し、各ＡＰＩサーバ２から情報を取得する処理部である。具体的には、要求処理部４０は、利用者がリクエストしたサービスに対応するＡＰＩを実行して、各ＡＰＩサーバ２が提供するサービスＡＰＩを利用する。
【００３０】
要求受信部４１は、利用者端末１から、ＨＴＴＰリクエスト（以下では、単にリクエストと記載する場合がある）などのサービス要求を受信する処理部である。具体的には、要求受信部４１は、宛先情報と送信元情報とユーザスクリプトとを含むサービス要求を受信し、これらの情報を記憶部２０等に保存する。ここで、宛先情報は、利用するサービスを特定する情報であり、例えばＵＲＩなどである。送信元情報は、サービス要求を送信した利用者端末１のＩＤやアドレス情報、サービス要求を受信したポート番号などである。ユーザスクリプトは、利用者が作成したスクリプトの本体であり、例えばPythonで記述されたスクリプトである。例えば、要求受信部４１は、ＨＴＴＰによる同期通信の場合、送信元のアドレス情報とポート番号を、結果（応答）の宛先情報として記憶部２０等に保存する。
【００３１】
分配処理部４２は、利用者端末１から要求されたＷｅｂＡＰＩを利用して、各ＡＰＩサーバ２のサービスに情報の取得要求を分配する処理部である。例えば、分配処理部４２は、要求受信部４１によって取得された宛先情報からＵＲＩを読み出し、該当する呼出ＡＰＩｓ「ＡＰＩａ、ＡＰＩｂ」をＡＰＩ情報ＤＢ２２から特定する。そして、分配処理部４２は、呼出ＡＰＩｓ「ＡＰＩａ」と「ＡＰＩｂ」のそれぞれを実行して、該当するＡＰＩサーバ２に情報の取得要求を送信する。
【００３２】
応答受信部４３は、各呼出ＡＰＩからの応答を受信する処理部である。例えば、応答受信部４３は、分配処理部４２によって実行された各呼出ＡＰＩに対応するＡＰＩサーバ２から、要求内容に該当する情報を受信する。そして、応答受信部４３は、受信した情報を記憶部２０等に保存する。例えば、応答受信部４３は、ＵＲＩ「http://www/aaabbbccc/com/api/v01/plans」で要求されるＨｏｔｅｌＰｌａｎｓを、各呼出ＡＰＩに対応するＡＰＩサーバ２から取得して保存する。
【００３３】
判定部５０は、利用者端末１から受信されたサービス要求に、ユーザスクリプトが含まれるか否かを判定する処理部である。具体的には、判定部５０は、サービス要求に、ユーザスクリプトそのものが含まれているか否かを判定する。そして、判定部５０は、ユーザスクリプトが含まれている場合には、スクリプト管理部６０に処理開始を指示し、ユーザスクリプトが含まれていない場合には、集約部５１に処理開始を指示する。
【００３４】
集約部５１は、応答受信部４３によって取得された情報を集約する処理部である。具体的には、集約部５１は、判定部５０から処理開始が指示されると、記憶部２０等に記憶される、各呼出ＡＰＩによって取得された情報を読み出す。そして、集約部５１は、読み出した情報に対して、アグリゲーションサービス内で提供される処理を実行し、集約結果を生成して、記憶部２０等に保存する。
【００３５】
例えば、集約部５１は、応答受信部４３によって取得された各情報に対して、予め決められたアルゴリズムにより「値段」や「レビュー評価」などの項目でランキング付けや並び替え処理を行った集約結果を生成する。すなわち、集約部５１は、利用者が指定できるものの、あくまでアグリケーションサービスが提供するサービス範囲内であり、全利用者に共通に提供される、並び替えや情報抽出などの集約処理を実行する。
【００３６】
スクリプト管理部６０は、スクリプト解析部６１とスクリプト実行部６２と環境破棄部６３とを有し、ユーザスクリプトの実行を制御する処理部である。
【００３７】
スクリプト解析部６１は、ユーザスクリプトを解析する処理部である。具体的には、スクリプト解析部６１は、判定部５０から処理開始が指示されると、サービス要求の受信時に取得されたユーザスクリプトを一時的に保持する記憶部２０から読み出して解析する。例えば、スクリプト解析部６１は、ユーザスクリプトのステップ数、ループ数、無限ループの有無、記述エラーの有無などを検出する。
【００３８】
ここで、スクリプト解析部６１は、エラー等により、ユーザスクリプトが実行不可能と判定した場合は、利用者端末１にエラーを通知し、集約部５１に集約処理を実行させる。一方で、スクリプト解析部６１は、ユーザスクリプトが実行可能と判定した場合、スクリプト実行部６２に処理開始を指示する。
【００３９】
スクリプト実行部６２は、アグリゲーションサービスを提供する実行環境と分離した実行環境を生成し、分離した実行環境でユーザスクリプトを実行する処理部である。具体的には、スクリプト実行部６２は、仮想化ソフトウェアを用いて、論理的に独立した空間を生成する。そして、スクリプト実行部６２は、生成した独立した空間内で、ユーザスクリプトを実行し、実行結果を結果応答部７０に出力する。その後、スクリプト実行部６２は、ユーザスクリプトの実行が完了すると、実行完了を環境破棄部６３に通知する。
【００４０】
つまり、スクリプト実行部６２は、アグリゲーターサーバ１０が提供するアグリゲーションサービスに影響を及ぼさない空間内、すなわち、影響範囲をユーザスクリプトの生成者である利用者だけに限定できる空間内で、その利用者のユーザスクリプトを実行する。例えば、スクリプト実行部６２は、アグリゲーターサーバ１０内に、ＳａｎｄｂｏｘやＤｏｃｋｅｒコンテナ、ＡＷＳ  Ｌａｍｂｄａなどの独立した環境を利用者端末１ごとに生成し、その利用者端末１のユーザスクリプトをその環境内で実行する。
【００４１】
例を挙げると、スクリプト実行部６２は、利用者が実行したい処理を記述したスクリプトを自分でアグリゲーターサーバ１０に提供することで、アグリケーションサービスが提供するサービス範囲外であるフォーマット変換などの個別処理を実行する。
【００４２】
環境破棄部６３は、ユーザスクリプトの実行のために生成された環境を解放する処理部である。具体的には、環境破棄部６３は、スクリプト実行部６２から実行完了が通知されると、当該ユーザスクリプト用に生成された環境を破棄し、利用可能な状態に解放する。例えば、環境破棄部６３は、該当する仮想空間を終了して、仮想プロセッサや仮想メモリなどの解放を実行する。
【００４３】
結果応答部７０は、利用者端末１からサービス要求に対する応答を、利用者端末１に送信する処理部である。例えば、結果応答部７０は、集約部５１から集約結果が入力された場合、サービス要求に対する応答として、集約結果を送信する。そして、結果応答部７０は、スクリプト実行部６２からスクリプトの実行結果が入力された場合、サービス要求に対する応答として、実行結果を送信する。
【００４４】
また、結果応答部７０は、利用者ごとの利用記録を管理する。例えば、結果応答部７０は、分配処理部４２が読み出したＡＰＩの回数を使用量ＤＢ２３に格納するとともに、ＡＰＩの呼出回数と単価とを乗算して請求金額を算出して使用量ＤＢ２３に格納する。なお、結果応答部７０は、利用者ごとのテーブルを使用量ＤＢ２３に生成して、利用者ごとに請求金額を算出することもでき、各利用者のサービス要求ごとのテーブルを使用量ＤＢ２３に生成して、サービス要求ごとに請求金額を算出することもできる。
【００４５】
［スクリプトの実行例］
ここで、ユーザスクリプトの実行例を説明する。図７は、アグリゲーションサービスによる取得結果を説明する図である。図８は、ユーザスクリプトの実行例を説明する図である。
【００４６】
要求処理部４０は、ＡＰＩを実行することで、アグリゲーションサービスから図７の（ａ）に示す情報を取得する。この例では、ｐｒｅＲｅｓとしてＪＳＯＮデータが与えられる。図７の（ａ）に示す情報は、Ｐｙｔｈｏｎ内部データの出力例である。
【００４７】
ここで、ユーザスクリプトを実行しない場合は、結果応答部７０は、図７の（ｂ）に示す情報を利用者端末１に返却する。図７の（ｂ）に示す情報は、図７の（ａ）に示す情報を利用者端末１が閲覧可能な形式（例えば、テキスト、Ｗｅｂ画面など）に変換した例である。すなわち、結果応答部７０は、アグリゲーションサービスで得られた情報を、アグリゲーションサービスが提供する並び替えなどを行って、利用者端末１に返却する。
【００４８】
一方で、ユーザスクリプトが存在する場合は、スクリプト管理部６０は、ｐｒｅＲｅｓで得られるデータについてユーザスクリプトによる加工を行う。具体的には、図８に示すように、スクリプト管理部６０は、アグリゲーションサービスで得られた図８の（ｂ）に対して、ユーザスクリプト（図８の（ｃ））を実行して、実行結果（図８の（ｄ））を取得する。
【００４９】
この例では、ユーザスクリプトによって、アグリゲーションサービスによる取得結果「Ｈｏｔｅｌ  ＡＡＡ、Ｈｏｔｅｌ  ＢＢＢ、Ｈｏｔｅｌ  ＦＦＦ」の各データのうち、利用者が利用したことのある「Ｈｏｔｅｌ  ＡＡＡ」および「Ｈｏｔｅｌ  ＦＦＦ」のデータを除外する。そして、Ｒｅｓが示すＪＳＯＮデータが利用者に返却される。すなわち、スクリプト管理部６０は、アグリゲーションサービスでは提供されていないデータの除外処理を行って、「Ｈｏｔｅｌ  ＢＢＢ」のみのデータを利用者に返却する。
【００５０】
［処理の流れ］
図９は、処理シーケンスを示す図である。図９に示すように、利用者端末１は、ＵＲＩなどの宛先情報とアドレスなどの送信元情報とユーザスクリプトとを含むリクエストをアグリゲーターサーバ１０に送信する（Ｓ１０１とＳ１０２）。
【００５１】
アグリゲーターサーバ１０の要求処理部４０は、リクエストを受信する（Ｓ１０３）。すると、要求処理部４０は、ＡＰＩ情報ＤＢ２２を参照して、リクエストの宛先情報から呼び出し対象のＡＰＩを特定して実行し、各ＡＰＩサーバ２から該当する情報を取得する（Ｓ１０４からＳ１０７）。
【００５２】
続いて、アグリゲーターサーバ１０の判定部５０は、受信されたリクエストにユーザスクリプトが存在するか否かを判定する（Ｓ１０８）。そして、集約部５１は、ユーザスクリプトが存在しない場合（Ｓ１０８：Ｎｏ）、Ｓ１０７で取得された各取得情報を集約する（Ｓ１０９）。続いて、結果応答部７０は、ＡＰＩの呼出回数などを含む利用記録を使用量ＤＢ２３に格納し（Ｓ１１０）、集約結果を利用者端末１に応答する（Ｓ１１１とＳ１１２）。
【００５３】
一方、アグリゲーターサーバ１０のスクリプト管理部６０は、ユーザスクリプトが存在する場合（Ｓ１０８：Ｙｅｓ）、スクリプト実行環境を起動し（Ｓ１１３）、スクリプト実行環境に情報を入力する（Ｓ１１４）。例えば、スクリプト管理部６０は、独立したスクリプトの実行空間を生成し、スクリプトの実行空間内に、Ｓ１０７で取得された各取得情報とＳ１０３で受信されたユーザスクリプトとをロードする。
【００５４】
そして、スクリプト管理部６０は、スクリプト実行環境内で、Ｓ１０７で取得された各取得情報を引数として与えたユーザスクリプトを実行し（Ｓ１１５）、実行結果を結果応答部７０に出力する（Ｓ１１６）。
【００５５】
続いて、結果応答部７０は、スクリプト管理部６０から実行結果を取得し（Ｓ１１７）、ＡＰＩの呼出回数などを含む利用記録を使用量ＤＢ２３に格納し（Ｓ１１８）、リクエスト（サービス要求）に含まれる送信元情報を宛先として、実行結果を利用者端末１に応答する（Ｓ１１９とＳ１２０）。
【００５６】
また、スクリプト管理部６０は、ユーザスクリプトの実行が完了すると、スクリプトの実行環境を破棄する（Ｓ１２１）。なお、各ステップの順番は、矛盾のない範囲内で変更することができる。
【００５７】
［効果］
上述したように、アグリゲーターサーバ１０は、スクリプトの有無で処理を変更することで、サービス全体に影響を与えることなく、利用者が期待する加工処理を実行した情報を提供することができる。また、アグリゲーターサーバ１０は、利用者ごとにサービスの変更が可能となるサービスを安全に提供できる。また、利用者は、処理をスクリプトで記載してアグリゲーターサーバ１０で実行させることで、サービスから受け取る結果を自分の好みに合わせることができ、個別の加工も省略できる。
【実施例２】
【００５８】
ところで、実施例１では、ＡＰＩの呼出回数で利用者への請求金額を算出する例を説明したが、これに限定されるものではない。そこで、実施例２では、一例として、リソースの使用量で請求金額を算出する例を説明する。
【００５９】
図１０は、実施例２にかかるアグリゲーターサーバ１０の機能構成を示す機能ブロック図である。図１０に示すように、実施例２にかかるアグリゲーターサーバ１０は、実施例１と同様に、通信部１１、記憶部２０、制御部３０を有する。実施例２にかかるアグリゲーターサーバ１０が実施例１と異なる点は、料金プランＤＢ２４とリソース使用量ＤＢ２５とを有する点である。
【００６０】
料金プランＤＢ２４は、スクリプトの実行料金を含むアグリゲーションサービスの料金プランを記憶するデータベースである。図１１は、料金プランＤＢ２４に記憶される料金プランの例を示す図である。図１１に示すように、料金プランＤＢ２４は、「料金プラン、リソース使用量、単価」を対応付けて記憶する。
【００６１】
ここで記憶される「料金プラン」は、料金プランを識別する識別子である。「リソース使用量」は、料金プランの適用条件であり、ユーザスクリプトが使用した、ストレージの入出力（Ｉ／Ｏ）回数、ＣＰＵ（Central  Processing  Unit）の実行時間、メモリの使用量などである。「単価」は、料金プラン適用時の単価である。
【００６２】
図１１の例では、ストレージのＩ／Ｏが１から２０回までは、料金プラン「Ｓ＃１」の単価「０．０１２円」が適用され、ストレージのＩ／Ｏが２１から２００回までは、料金プラン「Ｓ＃２」の単価「０．０２０円」が適用されることを示す。また、ＣＰＵの実行時間が０より大きく１０ｓｅｃまでは、料金プラン「ＣＴ＃１」の単価「０．００１円」が適用され、メモリの使用量が０より大きく３００ＭＢまでは、料金プラン「Ｍ＃１」の単価「０．００００１円」が適用されることを示す。
【００６３】
リソース使用量ＤＢ２５は、各利用者端末のサービス要求ごとに、ユーザスクリプトに使用されたリソースの使用量を記憶するデータベースである。図１２は、リソース使用量ＤＢ２５に記憶される使用量の例を示す図である。図１２に示すように、リソース使用量ＤＢ２５は、「ＵｓｅｒＩＤ、要求番号、リソース使用量（ストレージＩ／Ｏ回数、ＣＰＵ実行時間（ｓｅｃ）、メモリ使用量）」を対応付けて記憶する。
【００６４】
ここで記憶される「ＵｓｅｒＩＤ」は、利用者を識別する識別子である。「要求番号」は、サービス要求を識別する識別子であり、受信順に割り振られる。「リソース使用量」の「ストレージＩ／Ｏ回数」は、サービス要求に含まれるユーザスクリプトが実行したストレージの入出力の回数である。「ＣＰＵ実行時間（ｓｅｃ）」は、サービス要求に含まれるユーザスクリプトが実行開始から実行完了までに使用したＣＰＵの実行時間である。「メモリ使用量」は、サービス要求に含まれるユーザスクリプトが実行開始から実行完了までに使用したメモリの使用量である。
【００６５】
図１２の例では、ＵｓｅｒＩＤが「＃１」の利用者の要求番号「１」のサービス要求時に、ユーザスクリプトが使用したストレージの入出力回数が「２０回」、ＣＰＵ実行時間が「３１５ｓｅｃ」、メモリの使用量が「８７６ＭＢ」であることを示す。
【００６６】
そして、スクリプト実行部６２は、ユーザスクリプトの開始から終了まで、リソース使用量（ストレージＩ／Ｏ回数、ＣＰＵ実行時間（ｓｅｃ）、メモリ使用量）を監視し、リソース使用量ＤＢ２５に格納する。
【００６７】
また、結果応答部７０は、リソース使用量ＤＢ２５の要求番号ごとに、各リソース使用量の単価を料金プランＤＢ２４から特定して、請求金額を算出する。例えば、結果応答部７０は、要求番号１の場合、ストレージについては「Ｓ＃１」を選択して「２０×０．０１２円」を算出し、ＣＰＵについては図示しない「ＣＴ＃３」を選択して「３４６×０．０３円」を算出し、メモリについては図示しない「Ｍ＃２」を選択して「８７６×０．００００２円」を算出し、これらの合計を請求金額とする。
【００６８】
なお、リソース使用量ＤＢ２５の要求番号ごとに請求金額を算出してもよく、ＵｓｅｒＩＤごとに請求金額を算出してもよい。
【００６９】
このようにすることで、アグリゲーターサーバ１０は、利用者への制約がなく計算リソースを長期間占有し続けられることで、サービス提供効率が悪化することを抑制できる。また、アグリゲーターサーバ１０は、スクリプトの実行環境のリソースであるストレージ利用のＩ／Ｏ回数やＣＰＵ実行時間が少ないほど、利用量あたりの単価が安くなるように提供することで、利用者による利用が短時間化するインセンティブを与えることができる。
【実施例３】
【００７０】
ところで、実施例２では、リソースの使用量によってサービス提供効率の悪化を抑制する例を説明したが、これに限定されるものではない。そこで、実施例３では、一例として、スクリプト実行に必要なリソース利用量のピーク時間に処理が重ならないようにすることで、サービス提供効率の悪化を抑制する例を説明する。
【００７１】
図１３は、実施例３にかかるアグリゲーターサーバ１０の機能構成を示す機能ブロック図である。図１３に示すように、実施例３にかかるアグリゲーターサーバ１０は、実施例１と同様に、通信部１１、記憶部２０、制御部３０を有する。実施例３にかかるアグリゲーターサーバ１０が実施例１と異なる点は、リソース平均単価ＤＢ２６を有する点である。
【００７２】
リソース平均単価ＤＢ２６は、時間帯や利用者数などによって更新されるリソースの平均単価を記憶するデータベースである。具体的には、リソースの平均単価は、ピーク時間帯は高く、利用者数が多いときは高く、時間帯や利用者数によって変動する。そこで、リソース平均単価ＤＢ２６は、最新のリソースの平均単価を含むリソースの平均単価の更新履歴を記憶する。なお、リソース平均単価ＤＢ２６の更新は、スクリプト管理部６０によって実行される。また、アグリゲーターサーバ１０が複数の地域等に設置されている場合には、各アグリゲーターサーバ１０の単価の平均を平均単価と設定する。アグリゲーターサーバ１０が１台の場合や単地域に設置されている場合には、そのアグリゲーターサーバ１０の単価を平均単価と設定する。
【００７３】
図１４は、リソース平均単価ＤＢ２６に記憶される単価の遷移例を示す図である。図１４に示すように、リソース平均単価ＤＢ２６は、「ストレージＩ／Ｏ回数、ＣＰＵ実行時間（ｓｅｃ）、メモリ使用量」を記憶する。ここで記憶される情報は、実施例２と同様なので、詳細な説明を省略する。図１４の例は、「ストレージＩ／Ｏ回数、ＣＰＵ実行時間（ｓｅｃ）、メモリ使用量」の単価が「０．２、０．０００９、０．００００１」から「０．１８、０．０００８、０．００００１」に変更されたことを示す。なお、最終行が最新の単価とする。
【００７４】
そして、スクリプト管理部６０は、利用者から利用者がユーザスクリプトの使用を許可するリソースの単価を受け付ける。図１５は、利用者が指定する利用単価の例を示す図である。図１５の例では、ストレージＩ／Ｏとメモリ使用量の各単価に関係なく、ＣＰＵ実行時間の単価が「０．０００９」以下のときに、ユーザスクリプトの実行を希望することを示す。したがって、スクリプト管理部６０は、この利用者のユーザスクリプトについては、リソース平均単価ＤＢ２６を監視し、「ＣＰＵ実行時間（ｓｅｃ）」の単価が「０．０００９」以下のときに実行し、それ以外は実行を抑制する。
【００７５】
図１６は、実施例３にかかる処理シーケンスを示す図である。図１６に示すように、利用者端末１は、宛先情報と送信元情報とユーザスクリプトに加えて、利用単価を含むリクエストをアグリゲーターサーバ１０に送信する（Ｓ２０１とＳ２０２）。ここでの利用単価は、図１５に示す情報である。なお、その後に実行されるＳ２０８までの処理は、実施例１と同様の処理なので、詳細な説明は省略する。
【００７６】
ここでは、実施例１と異なる処理を説明する。具体的には、アグリゲーターサーバ１０のスクリプト管理部６０は、ユーザスクリプトが存在する場合（Ｓ２０４：Ｙｅｓ）、スクリプト実行環境を起動し（Ｓ２０９）、スクリプト実行環境に情報を入力する（Ｓ２１０）。
【００７７】
そして、スクリプト管理部６０は、予め定めたスケジュール等にしたがってリソース単価を更新する（Ｓ２１１）。なお、リソース平均単価ＤＢ２６に記憶されるリソース単価は、管理者等が手動で更新することもできる。その後、スクリプト管理部６０は、最新のリソース単価とユーザが指定する利用単価とを比較する（Ｓ２１２）。
【００７８】
ここで、スクリプト管理部６０は、利用単価を満たす場合（Ｓ２１２：Ｙｅｓ）、スクリプト実行環境内で、各取得情報を引数として与えたユーザスクリプトを実行し（Ｓ２１３）、実行結果を結果応答部７０に出力する（Ｓ２１４）。
【００７９】
続いて、結果応答部７０は、スクリプト管理部６０から実行結果を取得し（Ｓ２１５）、ユーザスクリプトの実行開始から実行完了までのリソースの使用量を使用量ＤＢ２３等に格納し（Ｓ２１６）、実行結果を利用者端末１に応答する（Ｓ２１７とＳ２１８）。
【００８０】
また、スクリプト管理部６０は、ユーザスクリプトの実行が完了すると、スクリプトの実行環境を破棄する（Ｓ２１９）。
【００８１】
一方、Ｓ２１２において、スクリプト管理部６０は、利用単価を満たさない場合（Ｓ２１２：Ｎｏ）、リソース平均単価ＤＢ２６を監視し、利用単価を満たすまで、ユーザスクリプトの実行を抑制する。そして、スクリプト管理部６０は、利用単価を満たすリソース単価になった場合、Ｓ２１３以降を実行する。なお、各ステップの順番は、矛盾のない範囲内で変更することができる。
【００８２】
このようにすることで、アグリゲーターサーバ１０は、サーバーリソースに余裕が少ない時には、ユーザスクリプトの実行優先度を落とし、余裕があるときに、ユーザスクリプトを実行する。このとき、アグリゲーターサーバ１０は、優先度と利用単価をトレードオフとすることで、優先度が低い要求は利用量あたりの単価が安くなるようにサービス提供して、利用者による利用が分散するインセンティブを与えることができる。なお、利用単価は、リクエストと別のタイミングで受信することもできる。
【実施例４】
【００８３】
ところで、スクリプトが異なると処理量が異なるので、利用者は利用前にサービス実行にかかるコストを判断することが難しい。そこで、実施例４では、ユーザスクリプトの実行前に、利用者にコストを通知する例を説明する。
【００８４】
図１７は、実施例４にかかるアグリゲーターサーバ１０の機能構成を示す機能ブロック図である。図１７に示すように、実施例４にかかるアグリゲーターサーバ１０は、実施例１と同様に、通信部１１、記憶部２０、制御部３０を有する。実施例３にかかるアグリゲーターサーバ１０が実施例１と異なる点は、料金プランＤＢ２７を有する点である。
【００８５】
料金プランＤＢ２７は、ユーザスクリプトの実行に伴う請求金額の規定を記憶するデータベースである。図１８は、実施例４にかかる料金プランＤＢ２７に記憶される料金プランの例を示す図である。図１８に示すように、料金プランＤＢ２７は、「スクリプト長、請求金額」を記憶する。ここで記憶される「スクリプト長」は、実行対象のユーザスクリプトのステップ数であり、「請求金額」は、利用者に請求する金額である。なお、ステップ数に限らず、行数やループ数などを用いることもできる。
【００８６】
図１８の例では、ユーザスクリプトのステップ数が１から２００ステップまでは、１００円、ユーザスクリプトのステップ数が２０１から８００ステップまでは、１２０円であることを示す。
【００８７】
次に、実施例４における処理の流れを説明する。図１９は、実施例４にかかる処理シーケンスを示す図である。図１９に示すように、利用者端末１は、宛先情報と送信元情報とユーザスクリプトとを含むリクエストをアグリゲーターサーバ１０に送信する（Ｓ３０１とＳ３０２）。
【００８８】
続いて、アグリゲーターサーバ１０の要求処理部４０は、リクエストを受信する（Ｓ３０３）。すると、要求処理部４０は、受信されたユーザスクリプトを解析して、ユーザスクリプトのステップ数、ループ数、ｆｏｒ文やｇｏｔｏ文などを検出して（Ｓ３０４）、スクリプト長を特定する（Ｓ３０５）。なお、この処理は、スクリプト解析部６１が実行することもできる。
【００８９】
そして、要求処理部４０は、特定したスクリプト長に対応する請求金額を料金プランＤＢ２７から特定し、リクエスト（サービス要求）に含まれる送信元情報を宛先として、リダイレクトを含む通知形式で、請求金額を利用者端末１に通知する（Ｓ３０６とＳ３０７）。
【００９０】
その後、利用者端末１は、リダイレクトを含む通知に対して、「ＯＫ」などを応答すると、実施例１のＳ１０１と同様のリクエストをアグリゲーターサーバ１０に送信する（Ｓ３０８とＳ３０９）。なお、利用者端末１は、リダイレクトを含む通知に対して、「キャンセル」などを応答すると、リクエストのキャンセルをアグリゲーターサーバ１０に送信する。
【００９１】
その後の処理は、図９のＳ１０３からＳ１１２と同様なので、詳細な説明は省略し、ここでは、実施例１と異なる処理について説明する。具体的には、アグリゲーターサーバ１０のスクリプト管理部６０は、ユーザスクリプトが存在する場合には、スクリプト実行環境を起動する（Ｓ３１０）。
【００９２】
続いて、スクリプト解析部６１は、ユーザスクリプトを解析して、ステップ数、ループ数、無限ループの有無、記述エラーの有無などを検出する（Ｓ３１１）。なお、この解析は、Ｓ３０４で実行した情報を用いることもできる。
【００９３】
そして、スクリプト管理部６０は、スクリプト実行環境に情報を入力し（Ｓ３１２）、スクリプト実行環境内で、各ＡＰＩサーバ２から取得された各取得情報を引数として与えたユーザスクリプトを実行し（Ｓ３１３）、実行結果を結果応答部７０に出力する（Ｓ３１４）。このとき、スクリプト管理部６０は、ｆｏｒやｇｏｔｏといった処理が繰り返される可能性のある分岐命令を含む禁止ステップについては実行を抑制する。その後の処理は、図９のＳ１１７からＳ１２１と同様なので、詳細な説明は省略する。
【００９４】
このようにすることで、アグリゲーターサーバ１０は、ＣＰＵ実行時間ではなくスクリプトの長さに応じて課金することができ、利用者も処理実行前にコストを判断できる。このとき、アグリゲーターサーバ１０は、禁止ステップの実行をスクリプト実行環境で禁止して、スクリプト長で計算回数を計測することができる。
【実施例５】
【００９５】
ところで、スクリプトを安全に実行するためには、利用者側のプログラミング能力が求められるが、全利用者がスクリプトを安全に記述できるとも限らない。そこで、実施例５では、アグリゲーターサーバ１０がそのまま利用できるサンプルスクリプトを提供する例を説明する。
【００９６】
図２０は、実施例５にかかる処理シーケンスを示す図である。図２０に示すように、利用者端末１は、サンプルスクリプトの提供を要求するサンプルスクリプト要求をアグリゲーターサーバ１０に送信する（Ｓ４０１とＳ４０２）。ここで、サンプルリクエスト要求には、宛先情報と送信元情報とスクリプトＩＤとが含まれる。スクリプトＩＤ以外にも、実行した処理の内容や処理の効果など、スクリプトを特定できる情報を採用することができる。
【００９７】
アグリゲーターサーバ１０の要求処理部４０は、サンプルスクリプト要求を受信すると（Ｓ４０３）、該当するサンプルスクリプトをサンプルＤＢから読み出し（Ｓ４０４）、サンプルスクリプトを利用者端末１に応答する（Ｓ４０５とＳ４０６）。なお、その後の処理は、図９のＳ１０１からＳ１２１と同様なので、詳細な説明は省略する。
【００９８】
サンプルＤＢは、「スクリプトＩＤ、スクリプト名、スクリプト本体、効果」を対応付けて記憶するデータベースである。「スクリプトＩＤ」は、サンプルスクリプトを識別する識別子であり、「スクリプト名」は、サンプルスクリプトの名前である。「スクリプト本体」は、サンプルスクリプトそのものである。「効果」は、サンプルスクリプトで実行できる処理など、サンプルスクリプトの説明である。
【００９９】
このような状態において、アグリゲーターサーバ１０の要求処理部４０は、利用者端末１から受信したサンプルリクエスト要求に含まれるサンプルＩＤや処理内容（効果）などをキーにして、サンプルＤＢを検索する。そして、要求処理部４０は、該当するサンプルスクリプトが検索された場合は、検索されたサンプルスクリプトを利用者端末１に応答し、該当するサンプルスクリプトが検索できない場合は、該当するサンプルスクリプトがないことを示す通知を利用者端末１に応答する。
【０１００】
このようにすることで、アグリゲーターサーバ１０は、そのまま利用できるサンプルスクリプトを提供することで、スクリプトを安全に実行でき、エラー処理などの発生を抑制できる。また、利用者は、プログラミングなしに安全なスクリプトを実行できる。
【実施例６】
【０１０１】
実施例１−５では、利用者がユーザスクリプトを毎回送信する例を説明したが、これに限定されるものではなく、スクリプトの送信を減らすことで、送信にかかるパケット代などのコストを削減することもできる。そこで、実施例６では、アグリゲーターサーバ１０内にユーザスクリプトを登録する例を説明する。
【０１０２】
図２１は、実施例６にかかる処理シーケンスを示す図である。図２６に示すように、利用者端末１は、ユーザスクリプトの登録を要求するスクリプト登録要求をアグリゲーターサーバ１０に送信する（Ｓ５０１とＳ５０２）。ここで、スクリプト登録要求には、実施例１と同様の宛先情報と送信元情報に加えて、スクリプト名と効果とスクリプト本体などの登録情報が含まれる。
【０１０３】
そして、アグリゲーターサーバ１０の要求処理部４０は、スクリプト登録要求を受信すると（Ｓ５０３）、スクリプトＩＤを採番し、受信された登録情報に付加してライブラリＤＢに登録する（Ｓ５０４）。その後、要求処理部４０は、スクリプト登録要求に含まれる送信元情報を宛先にした登録完了通知を利用者端末１に送信する（Ｓ５０５とＳ５０６）。
【０１０４】
ここで、ライブラリＤＢについて説明する。図２１に示すように、ライブラリＤＢは、「スクリプトＩＤ、スクリプト名、スクリプト本体、効果、公開」を対応付けて記憶するデータベースである。「スクリプトＩＤ」は、スクリプトに対して付与される識別子である。「スクリプト名」は、スクリプトの名前であり、「スクリプト本体」は、スクリプトそのものであり、「効果」は、スクリプトの説明などである。「公開」は、スクリプトを一般に公開するか否かを示す情報である。
【０１０５】
例えば、要求処理部４０は、「スクリプト名（利用者作成１）、スクリプト本体、効果（利用者作成です）」を含むスクリプト登録要求を受信すると、スクリプトＩＤ「ＵＳ＃１」を採番してライブラリＤＢに登録する。このとき、要求処理部４０は、利用者作成のスクリプトであることから、利用者以外は使用できないようにするために、「非公開」にして登録する。一方、要求処理部４０は、アグリゲーター側が作成したスクリプトである場合には、全利用者が使用できるようにするために、「公開」にして登録する。なお、利用者が「公開」を指定することで、利用者作成のスクリプトであっても、一般に公開することもできる。
【０１０６】
その後の処理は、図９のＳ１０１からＳ１２１と同様なので、詳細な説明は省略する。ただし、利用者端末１は、スクリプトそのものではなく、ライブライＤＢに登録されるスクリプトＩＤを指定して、リクエストを送信する（Ｓ６０１とＳ６０２）。そして、アグリゲーターサーバ１０は、リクエストを受信すると、リクエストからスクリプトＩＤを読み出し、読み出したスクリプトＩＤに対応するスクリプトをライブラリＤＢから検索して以降の処理を実行する（Ｓ６０３）。
【０１０７】
このようにすることで、アグリゲーターサーバ１０は、アグリゲーターサーバ１０において、利用者が作成したスクリプトを登録できるライブラリを提供することができる。この結果、利用者は、あらかじめライブラリにスクリプトを登録しておき、サービス要求のときに利用するスクリプトを指定することで実行できる。また、登録したスクリプトは他の利用者に公開して共有することもできる。
【実施例７】
【０１０８】
実施例１−６では、ユーザスクリプトのデータ処理中にエラーになった場合、スクリプト実行コストはかかっているのに処理途中の結果データを得られない事象が発生することがある。そこで、実施例７では、アグリゲーターサーバ１０が処理途中のデータをストレージに保存するステージゲート機能を提供する例を説明する。
【０１０９】
図２２は、実施例７にかかる処理シーケンスを示す図である。なお、リクエストが送信されて集約結果を応答するまでの処理は、実施例１の図９のＳ１０１からＳ１１２までと同様なので、詳細な説明は省略する。ここでは、実施例１とは異なる、ユーザスクリプトが含まれる場合の処理について説明する。
【０１１０】
図２２に示すように、アグリゲーターサーバ１０のスクリプト管理部６０は、ユーザスクリプトが存在する場合、スクリプト実行環境を起動し（Ｓ７０１）、スクリプト内のステージゲート機能を呼び出し（Ｓ７０２）、スクリプト実行環境に情報を入力する（Ｓ７０３）。
【０１１１】
その後、スクリプト管理部６０は、スクリプト実行環境内で、各ＡＰＩサーバ２から取得された各取得情報を引数として与えたユーザスクリプトを実行する（Ｓ７０４）。そして、スクリプト管理部６０は、ユーザスクリプト内の所定ステップ数が終了すると（Ｓ７０５：Ｙｅｓ）、その所定ステップ数までの途中結果を処理結果ＤＢに格納する（Ｓ７０６とＳ７０７）。ここで処理結果ＤＢに格納された途中結果は、利用者端末１がアクセスできるように、公開される（Ｓ７０８）。
【０１１２】
そして、スクリプト管理部６０は、未処理のステップが存在する場合は（Ｓ７０９：Ｎｏ）、次のステップを実行して（Ｓ７１０）、Ｓ７０５以降の処理を繰り返す。一方、スクリプト管理部６０は、未処理のステップが存在せず、最後のステップが終了した場合は（Ｓ７０９：Ｙｅｓ）、スクリプト実行環境を破棄する（Ｓ７１１）。
【０１１３】
なお、実行結果の格納、利用記録の格納、実行結果の応答は、実施例１と同様なので、詳細な説明は省略する。また、アグリゲーターサーバ１０は、ステージゲート機能の利用を希望する利用者に対して、ステージゲート機能の仕様を記述したひな形のスクリプトなどを事前に配布することもできる。
【０１１４】
このようにすることで、アグリゲーターサーバ１０は、ユーザスクリプトからステージゲート機能呼び出すことで、その時点で処理が完了しているデータを保存し、処理の段階的に結果データを得ることができる。利用者にとっても、ユーザスクリプトに予期せぬ終了が発生した場合でも、途中結果を取得することができ、不要なコストを削減できる。なお、途中経過を出力するタイミングは、任意に設定変更することができる。
【実施例８】
【０１１５】
ところで、利用者が作成するスクリプト内の記述ミス等により、利用者の要求に対して無限ループが発生することがあり、このような場合には、リソース量の枯渇および利用者への課金増大の恐れがある。そこで、実施例８では、ＣＰＵの処理時間によって、ユーザスクリプトの強制終了を行う例を説明する。
【０１１６】
図２３は、実施例８にかかる処理シーケンスを示す図である。なお、ここでは、実施例７の図２２に新たな処理を付加する形式で説明するが、これに限定されるものではなく、他の実施例についても同様に適用することができる。
【０１１７】
図２３に示すように、利用者端末１は、宛先情報と送信元情報とユーザスクリプトとに加えて、要求処理時間を含むリクエストをアグリゲーターサーバ１０に送信する（Ｓ８０１とＳ８０２）。ここで、要求処理時間は、利用者が指定するＣＰＵの最大処理時間である。なお、リクエストから送信されて集約結果を応答するまでの処理は、実施例１の図９のＳ１０３からＳ１１２までと同様なので、詳細な説明は省略する。ここでは、実施例１とは異なる、ユーザスクリプトが含まれる場合の処理について説明する。
【０１１８】
また、図２３に示すように、ユーザスクリプトが存在する場合のＳ８０３からＳ８１０までの処理は、図２２のＳ７０４からＳ７１１までの処理と同様なので、詳細な説明は省略する。
【０１１９】
実施例８では、スクリプト管理部６０は、ユーザスクリプトが実行されると（Ｓ８０３）、Ｓ８０４以降の処理と並行して、ユーザスクリプトが専有するＣＰＵ処理時間の計測を開始する（Ｓ８１１）。
【０１２０】
そして、スクリプト管理部６０は、計測するＣＰＵ処理時間が利用者によって指定された要求処理時間を越えた場合に（Ｓ８１２）、処理の進捗等に関係なく、ユーザスクリプトを強制停止する（Ｓ８１３）。また、結果応答部７０は、強制終了されたときは、ＣＰＵ処理時間超過のために実行済み結果を返送するなどのメッセージを、利用者端末１に送信する。
【０１２１】
このようにすることで、アグリゲーターサーバ１０は、他のサービスと独立してスクリプト実行環境が提供されるため、無限に継続する処理の実行を許可することはできる。しかし、アグリゲーターサーバ１０は、ステージゲートを利用することで、全ての処理が完了しなくても利用者に有益なデータを提供することができる。このとき、アグリゲーターサーバ１０は、利用者から入力された要求処理時間に対して、実際に処理した時間が超えたところで実行を終了することで、計算回数が予測できない処理の実行を許可できる。
【実施例９】
【０１２２】
ところで、各ＡＰＩサーバ２からのデータ取得時にも取得エラーが発生する場合がある。例えば、アグリゲーターサーバ１０の先のどれか１つのサービスＡＰＩでタイムアウトが発生すると、利用者はサービスＡＰＩの扱いを制御できない。そこで、実施例９では、サービスＡＰＩの実行でエラーが発生したときに、利用者の要求に応じてエラー処理を実行する例を説明する。
【０１２３】
図２４は、実施例９にかかる処理シーケンスを示す図である。図２４に示すように、利用者端末１は、宛先情報と送信元情報とユーザスクリプトに加えて、エラー時の要求を含むリクエストをアグリゲーターサーバ１０に送信する（Ｓ９０１とＳ９０２）。
【０１２４】
ここで、エラー時の要求は、図２４に示すように「エラー時の要求、対応内容」などによって規定される。例えば、「エラーしたＡＰＩをリトライ」、「取得できたデータだけで処理」、「キャッシュを参考情報として処理」などが利用者によって指定される。
【０１２５】
続いて、アグリゲーターサーバ１０の要求処理部４０は、リクエストを受信する（Ｓ９０３）。すると、要求処理部４０は、ＡＰＩ情報ＤＢ２２を参照して、リクエストの宛先情報から呼び出し対象のＡＰＩを特定して実行し、各ＡＰＩサーバ２から該当する情報を取得する（Ｓ９０４からＳ９０７）。
【０１２６】
ここで、要求処理部４０は、いずれかのＡＰＩサーバ２からの情報取得時すなわちサービスＡＰＩの実行時に、エラーが発生した場合（Ｓ９０８：Ｙｅｓ）、Ｓ９０１で要求されたエラー処理を実行する（Ｓ９０９からＳ９１１）。
【０１２７】
例えば、要求処理部４０は、リトライ回数の上限を３回として、エラーしたＡＰＩをリトライして、エラーが発生したサービスＡＰＩからの情報取得を試みる。また、要求処理部４０は、正常に取得できたデータ（情報）だけで以降の処理を実行する。また、要求処理部４０は、エラーが発生したＡＰＩのキャッシュを用いて以降の処理を実行し、その旨を利用者に通知する。
【０１２８】
なお、Ｓ９０９以降の処理またはエラーがない場合（Ｓ９０８：Ｎｏ）の処理（Ｓ９１２以降）は、図９のＳ１０８以降と同様の処理なので、詳細な説明は省略する。
【０１２９】
このようにすることで、アグリゲーターサーバ１０は、利用者が要求する範囲内でアグリゲーションサービスを提供することができる。また、利用者は、エラーしたＡＰＩをリトライしてデータの再取得、タイムアウトしたＡＰＩのデータは無視して取得できたデータだけを処理、アグリゲーターサーバ１０内でキャッシュされている過去のデータを参考情報として処理する、などを選択できる。
【実施例１０】
【０１３０】
例えば、情報を配信するサービスＡＰＩが有料で提供されているときに、それを利用する回数の料金を利用者が支払う場合がある。このような場合に備えて、アグリゲーターサーバ１０が、ＡＰＩから得られたデータをサーバ内でキャッシュしておき、キャッシュデータを利用者に提供することで、コストを削減することができる。そこで、実施例１０では、キャッシュデータ利用する例を説明する。
【０１３１】
図２５は、実施例１０にかかる処理シーケンスを示す図である。図２５に示すように、利用者端末１は、宛先情報と送信元情報とユーザスクリプトに加えて、許容するデータ鮮度を含むリクエストをアグリゲーターサーバ１０に送信する（Ｓ１００１とＳ１００２）。
【０１３２】
ここで、許容するデータ鮮度は、図２４に示すように「鮮度」によって規定される。例えば、「鮮度」に「２週間」が設定されている場合は、リクエストした日時より２週間前までのキャッシュデータがある場合、キャッシュデータを利用し、リクエストした日時より２週間以上前の古いキャッシュデータしかない場合、有料であってもサービスＡＰＩから新たなデータを取得する。
【０１３３】
続いて、アグリゲーターサーバ１０の要求処理部４０は、リクエストを受信する（Ｓ１００３）。すると、要求処理部４０は、ＡＰＩ情報ＤＢ２２を参照して、リクエストの宛先情報から呼び出し対象のＡＰＩを特定する（Ｓ１００４）。
【０１３４】
そして、要求処理部４０は、ＡＰＩキャッシュＤＢを参照して、利用者が指定した鮮度を満たすキャッシュデータがキャッシュされている場合（Ｓ１００５：Ｙｅｓ）、ＡＰＩキャッシュＤＢから情報を取得する（Ｓ１００６）。一方で、要求処理部４０は、利用者が指定した鮮度を満たすキャッシュデータがキャッシュされていない場合（Ｓ１００５：Ｎｏ）、呼び出し対象のＡＰＩを特定して実行し、各ＡＰＩサーバ２から該当する情報を取得する（Ｓ１００７からＳ１０１０）。
【０１３５】
ここで、ＡＰＩキャッシュＤＢは、図２５に示すように、「ＡＰＩ  ＵＲＩ、パラメータ、取得日時、データ」を対応付けて記憶する。「ＡＰＩ  ＵＲＩ」は、サービスＡＰＩを識別する識別子である。「パラメータ」は、ＡＰＩ実行時に指定されるパラメータである。「取得日時」は、キャッシュされた日時である。「データ」は、キャッシュされたデータである。
【０１３６】
そして、要求処理部４０は、ＡＰＩキャッシュＤＢの取得日時を参照し、現時刻（２０１７年１月１日）から２週間前までに取得されたキャッシュデータが存在するか否かを判定する。そして、要求処理部４０は、対象のキャッシュデータが存在する場合、ＡＰＩキャッシュＤＢに記憶されるデータのうち、Ｓ１００４で特定された「ＡＰＩ  ＵＲＩ」と「パラメータ」とが一致するキャッシュデータを取得して、以降の処理を実行する。
【０１３７】
なお、Ｓ１０１０以降の処理は、図９のＳ１０８以降の処理と同様なので、詳細な説明は省略する。
【０１３８】
このようにすることで、アグリゲーターサーバ１０は、サービスに入力される利用者が許容するデータの鮮度と、データをキャッシュした日時を比較して許容範囲の時は、キャッシュを用いて安い料金で提供し、許容範囲外の時はＡＰＩから最新データを取得できる。したがって、アグリゲーターサーバ１０は、有料のＡＰＩ利用回数を減らして同じような要求が重なるサービスを安く提供できる。
【実施例１１】
【０１３９】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に異なる実施例を説明する。
【０１４０】
［独立空間］
上記実施例では、ユーザスクリプトの実行空間として仮想的な空間を用いる例を説明したが、これに限定されるものではない。例えば、アグリゲーターサーバ１０とは物理的に異なる別のサーバ上で、ユーザスクリプトを実行することもできる。
【０１４１】
［スクリプト］
上記実施例では、利用者が自らのスクリプトをアグリゲーターサーバ１０に送信する例を説明したが、これに限定されるものではない。例えば、アグリゲーターサーバ１０が、アグリゲーションサービスで提供する処理とは別の処理を実行するスクリプトをＷｅｂ画面などで提示して、利用者に選択させることで、アグリゲーションサービス範囲外の処理を提供することもできる。このような場合であっても、アグリゲーターサーバ１０は、上記実施例と同様、アグリゲーションサービスとは独立した空間（環境）で、選択されたスクリプトを実行する。
【０１４２】
［システム］
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０１４３】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１４４】
［ハードウェア構成］
図２６は、ハードウェア構成例を示す図である。図２６に示すように、アグリゲーターサーバ１０は、通信インタフェース１０ａ、ＨＤＤ（Hard  Disk  Drive）１０ｂ、メモリ１０ｃ、プロセッサ１０ｄを有する。
【０１４５】
通信インタフェース１０ａは、他の装置の通信を制御するネットワークインタフェースカードなどである。ＨＤＤ１０ｂは、プログラムやデータなどを記憶する記憶装置の一例である。
【０１４６】
メモリ１０ｃの一例としては、ＳＤＲＡＭ（Synchronous  Dynamic  Random  Access  Memory）等のＲＡＭ（Random  Access  Memory）、ＲＯＭ（Read  Only  Memory）、フラッシュメモリ等が挙げられる。プロセッサ１０ｄの一例としては、ＣＰＵ（Central  Processing  Unit）、ＤＳＰ（Digital  Signal  Processor）、ＦＰＧＡ（Field  Programmable  Gate  Array）、ＰＬＤ（Programmable  Logic  Device）等が挙げられる。
【０１４７】
また、アグリゲーターサーバ１０は、プログラムを読み出して実行することでサービス提供方法を実行する情報処理装置として動作する。つまり、アグリゲーターサーバ１０は、要求処理部４０と判定部５０と集約部５１とスクリプト管理部６０と結果応答部７０と同様の機能を実行するプログラムを実行する。この結果、アグリゲーターサーバ１０は、要求処理部４０と判定部５０と集約部５１とスクリプト管理部６０と結果応答部７０と同様の機能を実行するプロセスを実行することができる。なお、この他の実施例でいうプログラムは、アグリゲーターサーバ１０によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
【符号の説明】
【０１４８】
１  利用者端末
２  ＡＰＩサーバ
１０  アグリゲーターサーバ
１１  通信部
２０  記憶部
２１  利用者情報ＤＢ
２２  ＡＰＩ情報ＤＢ
２３  使用量ＤＢ
２４、２７  料金プランＤＢ
２５  リソース使用量ＤＢ
２６  リソース平均単価ＤＢ
４０  要求処理部
４１  要求受信部
４２  分配処理部
４３  応答受信部
５０  判定部
５１  集約部
６０  スクリプト管理部
６１  スクリプト解析部
６２  スクリプト実行部
６３  環境破棄部
７０  結果応答部
【図１】
2019008736.tif 000003
【図２】
2019008736.tif 000004
【図３】
2019008736.tif 000005
【図４】
2019008736.tif 000006
【図５】
2019008736.tif 000007
【図６】
2019008736.tif 000008
【図７】
2019008736.tif 000009
【図８】
2019008736.tif 000010
【図９】
2019008736.tif 000011
【図１０】
2019008736.tif 000012
【図１１】
2019008736.tif 000013
【図１２】
2019008736.tif 000014
【図１３】
2019008736.tif 000015
【図１４】
2019008736.tif 000016
【図１５】
2019008736.tif 000017
【図１６】
2019008736.tif 000018
【図１７】
2019008736.tif 000019
【図１８】
2019008736.tif 000020
【図１９】
2019008736.tif 000021
【図２０】
2019008736.tif 000022
【図２１】
2019008736.tif 000023
【図２２】
2019008736.tif 000024
【図２３】
2019008736.tif 000025
【図２４】
2019008736.tif 000026
【図２５】
2019008736.tif 000027
【図２６】
2019008736.tif 000028