(57)【要約】【課題】より適切に利用可能なアプリケーションをユーザに提示することを目的とする。【解決手段】サーバ装置が実行するサービスと連携して処理を行うクライアント装置であって、サービスの種類の指定を受け付ける指定受付手段と、指定された種類のサービスに対して設定されたサービス種別負荷と、過去にクライアント装置の指示によりアプリケーションを実行した時のサーバ装置の負荷であるクライアント別負荷と、サーバ装置が受容可能な受容負荷と、に基づいて、指定されたサービスの種類に対応するアプリケーションの中から、サーバ装置が実行可能なアプリケーションを特定する特定手段と、特定手段により特定されたアプリケーションの一覧画面を表示する表示手段とを備える。【選択図】図１
2015032251.tif 000002
【特許請求の範囲】
【請求項１】
サーバ装置が実行するサービスと連携して処理を行うクライアント装置であって、
サービスの種類の指定を受け付ける指定受付手段と、
指定された前記種類の前記サービスに対して設定されたサービス種別負荷と、過去に前記クライアント装置の指示によりアプリケーションを実行した時の前記サーバ装置の負荷であるクライアント別負荷と、前記サーバ装置が受容可能な受容負荷と、に基づいて、指定された前記サービスの種類に対応するアプリケーションの中から、前記サーバ装置が実行可能な前記アプリケーションを特定する特定手段と、
前記特定手段により特定された前記アプリケーションの一覧画面を表示する表示手段と
を備えるクライアント装置。
【請求項２】
前記サーバ装置から、前記サービス種別負荷と、前記クライアント別負荷と、前記受容負荷と、を受信する受信手段をさらに備え、
前記特定手段は、前記受信手段が受信した前記サービス種別負荷と、前記クライアント別負荷と、前記受容負荷と、に基づいて、前記アプリケーションを特定する請求項１に記載のクライアント装置。
【請求項３】
前記特定手段は、前記サービス種別負荷と、時間帯毎の前記クライアント別負荷と、時間帯毎の前記受容負荷と、に基づいて、前記アプリケーションと、前記アプリケーションの実行可能な時間帯と、を特定し、
前記表示手段は、前記アプリケーションと、前記時間帯と、を示す前記一覧画面を表示する請求項１又は２に記載のクライアント装置。
【請求項４】
前記特定手段は、前記指定受付手段が指定を受け付けた受付タイミングを基準として定まる基準タイミングにおいて実行可能な前記アプリケーションを特定し、実行可能なアプリケーションが存在しない場合に、前記基準タイミング以降のタイミングにおいて実行可能な前記アプリケーションと、前記アプリケーションの実行可能な時間帯と、を特定する請求項３に記載のクライアント装置。
【請求項５】
サービスの種類と、実行希望時間と、が指定されたサービス実行の予約情報を受け付ける予約受付手段と、
前記指定受付手段が指定を受け付けた受付タイミングが前記実行希望時間として指定された前記予約情報が格納されているか否かを判定する判定手段と
をさらに備え、
前記表示手段は、前記予約情報が格納されている場合に、前記予約情報に示される前記サービスの種類に対応する前記アプリケーションを含む前記一覧画面を表示する請求項１乃至４何れか１項に記載のクライアント装置。
【請求項６】
クライアント装置において実行されるサービスに連携したサービスを実行するサーバ装置であって、
サービスに対応するアプリケーションを実行する実行手段と、
前記クライアント装置からの実行指示に従い前記実行手段が実行したアプリケーションに対応するサービスの種類と、前記実行指示の送信元の前記クライアント装置と、を示す実行履歴を記憶手段に格納する履歴管理手段と、
前記実行履歴と、前記実行履歴に示される前記サービスの前記種類に対して設定されたサービス種別負荷と、に基づいて、各クライアント装置からの前記実行指示に基づいて、前記サービスに対応するアプリケーションを実行した場合の前記サーバ装置の負荷であるクライアント別負荷を予測するクライアント別負荷予測手段と、
前記実行履歴と、前記実行履歴に示される前記サービスの前記種類に対して設定されたサービス種別負荷と、に基づいて、前記サーバ装置が受容可能な受容負荷を予測する受容負荷予測手段と、
前記サービス種別負荷と、前記クライアント別負荷と、前記受容負荷と、を前記クライアント装置に送信する送信手段と
を備えるサーバ装置。
【請求項７】
前記クライアント装置から、前記サービスの前記種類と、前記サービスの実行希望時間と、が指定されたサービス実行の予約情報を受信する受信手段をさらに備え、
前記クライアント別負荷予測手段は、前記予約情報と、前記サービス種別負荷と、前記実行履歴と、に基づいて、前記クライアント別負荷を予測し、
前記受容負荷予測手段は、前記予約情報と、前記サービス種別負荷と、前記実行履歴と、に基づいて、前記受容負荷を予測する請求項６に記載のサーバ装置。
【請求項８】
サーバ装置と、前記サーバ装置において実行されるサービスと連携して処理を行うクライアント装置とを備えるシステムであって、
前記サーバ装置は、
前記サービスの種類毎に設定されたサービス種別負荷と、各クライアント装置からの実行指示に基づいて、前記サーバ装置が前記サービスに対応するアプリケーションを実行した場合の前記サーバ装置の負荷であるクライアント別負荷と、前記サーバ装置が受容可能な受容負荷と、を送信する送信手段を備え、
前記クライアント装置は、
サービスの種類の指定を受け付ける指定受付手段と、
前記サービス種別負荷と、前記クライアント別負荷と、前記受容負荷と、を受信する受信手段と、
前記サービス種別負荷と、前記クライアント別負荷と、前記受容負荷と、に基づいて、指定された前記サービスの種類に対応するアプリケーションの中から、前記サーバ装置が実行可能な前記アプリケーションを特定する特定手段と、
前記特定手段により特定された前記アプリケーションの一覧画面を表示する表示手段と
を備えるシステム。
【請求項９】
サーバ装置が実行するサービスと連携して処理を行うクライアント装置が実行する情報処理方法あって、
サービスの種類の指定を受け付ける指定受付ステップと、
指定された前記種類の前記サービスに対して設定されたサービス種別負荷と、過去に前記クライアント装置の指示によりアプリケーションを実行した時の前記サーバ装置の負荷であるクライアント別負荷と、前記サーバ装置が受容可能な受容負荷と、に基づいて、指定された前記サービスの種類に対応するアプリケーションの中から、前記サーバ装置が実行可能な前記アプリケーションを特定する特定ステップと、
前記特定ステップにおいて特定された前記アプリケーションの一覧画面を表示する表示ステップと
を含む情報処理方法。
【請求項１０】
クライアント装置において実行されるサービスに連携したサービスを実行するサーバ装置が実行する情報処理方法であって、
サービスに対応するアプリケーションを実行する実行ステップと、
前記クライアント装置からの実行指示に従い前記実行ステップにおいて実行されたアプリケーションに対応するサービスの種類と、前記実行指示の送信元の前記クライアント装置と、を示す実行履歴を記憶手段に格納する履歴管理ステップと、
前記実行履歴と、前記実行履歴に示される前記サービスの前記種類に対して設定されたサービス種別負荷と、に基づいて、各クライアント装置からの前記実行指示に基づいて、前記サービスに対応するアプリケーションを実行した場合の前記サーバ装置の負荷であるクライアント別負荷を予測するクライアント別負荷予測ステップと、
前記実行履歴と、前記実行履歴に示される前記サービスの前記種類に対して設定されたサービス種別負荷と、に基づいて、前記サーバ装置が受容可能な受容負荷を予測する受容負荷予測ステップと、
前記サービス種別負荷と、前記クライアント別負荷と、前記受容負荷と、を前記クライアント装置に送信する送信ステップと
を含む情報処理方法。
【請求項１１】
サーバ装置と、前記サーバ装置において実行されるサービスと連携して処理を行うクライアント装置とを備えるシステムが実行する情報処理方法であって、
前記サーバ装置が、前記サービスの種類毎に設定されたサービス種別負荷と、各クライアント装置からの実行指示に基づいて、前記サーバ装置が前記サービスに対応するアプリケーションを実行した場合の前記サーバ装置の負荷であるクライアント別負荷と、前記サーバ装置が受容可能な受容負荷と、を送信する送信ステップと、
前記クライアント装置が、サービスの種類の指定を受け付ける指定受付ステップと、
前記クライアント装置が、前記サービス種別負荷と、前記クライアント別負荷と、前記受容負荷と、を受信する受信ステップと、
前記クライアント装置が、前記サービス種別負荷と、前記クライアント別負荷と、前記受容負荷と、に基づいて、指定された前記サービスの種類に対応するアプリケーションの中から、前記サーバ装置が実行可能な前記アプリケーションを特定する特定ステップと、
前記クライアント装置が、前記特定ステップにおいて特定された前記アプリケーションの一覧画面を表示する表示ステップと
を含む情報処理方法。
【請求項１２】
サーバ装置が実行するサービスと連携して処理を行うコンピュータを、
サービスの種類の指定を受け付ける指定受付手段と、
指定された前記種類の前記サービスに対して設定されたサービス種別負荷と、過去に前記コンピュータの指示によりアプリケーションを実行した時の前記サーバ装置の負荷であるクライアント別負荷と、前記サーバ装置が受容可能な受容負荷と、に基づいて、指定された前記サービスの種類に対応するアプリケーションの中から、前記サーバ装置が実行可能な前記アプリケーションを特定する特定手段と、
前記特定手段により特定された前記アプリケーションの一覧画面を表示する表示手段と
として機能させるためのプログラム。
【請求項１３】
クライアント装置において実行されるサービスに連携したサービスを実行するコンピュータを、
サービスに対応するアプリケーションを実行する実行手段と、
前記クライアント装置からの実行指示に従い前記実行手段が実行したアプリケーションに対応するサービスの種類と、前記実行指示の送信元の前記クライアント装置と、を示す実行履歴を記憶手段に格納する履歴管理手段と、
前記実行履歴と、前記実行履歴に示される前記サービスの前記種類に対して設定されたサービス種別負荷と、に基づいて、各クライアント装置からの前記実行指示に基づいて、前記サービスに対応するアプリケーションを実行した場合の前記コンピュータの負荷であるクライアント別負荷を予測するクライアント別負荷予測手段と、
前記実行履歴と、前記実行履歴に示される前記サービスの前記種類に対して設定されたサービス種別負荷と、に基づいて、前記コンピュータが受容可能な受容負荷を予測する受容負荷予測手段と、
前記サービス種別負荷と、前記クライアント別負荷と、前記受容負荷と、を前記クライアント装置に送信する送信手段と
して機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアント装置、サーバ装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
近年、クライアントからサーバへ接続し、サーバ上のアプリケーションを実行する仕組みが普及している。また、Ｗｅｂ  Ｉｎｔｅｎｔｓ（ｈｔｔｐ：／／ｗｅｂｉｎｔｅｎｔｓ．ｏｒｇ／）のようなＷｅｂアプリケーション連携機能も登場してきた。この連携機能では、あるＷｅｂアプリケーションが他のＷｅｂアプリケーションと機能連携する場合、ブラウザに事前登録された同一種類のＷｅｂアプリケーションがピッカーで提示される。そして、一覧表示されたＷｅｂアプリケーションのうち、ユーザにより選択されたＷｅｂアプリケーションとの機能連携が実現される。
Ｗｅｂ  Ｉｎｔｅｎｔｓの種類を判別するためには、アクションとＭＩＭＥタイプという二つの識別子が用いられる。また、ピッカーとは、利用可能なＷｅｂアプリケーションを一覧で表示し、ユーザがＷｅｂアプリケーションの選択を行うインタフェースである。
【０００３】
このＷｅｂ  Ｉｎｔｅｎｔｓは、異なる装置の機能をシームレスに利用する装置連携技術としても利用することが可能である。装置連携の例として、デジタルカメラから携帯電話の画像編集機能を呼び出す例が挙げられる。一般的に、デジタルカメラの性能は低く、画像編集アプリケーションをデジタルカメラ上で起動することは難しい。しかし、Ｗｅｂ  Ｉｎｔｅｎｔｓを用いることで、デジタルカメラから携帯電話上の画像編集アプリケーションを呼び出し、利用することができる。
装置連携においては、多くのリクエストを処理するクラウドサーバと異なり、連携する装置のリソースは限られたものである。このため、携帯電話やデジタルカメラ等、リソースの限られた装置の機能を他の装置が利用する場合は、装置の負荷状況を考慮したリクエストを行う必要がある。装置の負荷を考慮する技術としては、例えば、Ｗｅｂサーバのようにサーバの状態や動作等に応じてＨＴＴＰステータスコードをクライアントに送信する仕組みが知られている。また、特許文献１には、装置間で装置の能力に関するケイパビリティ情報を交換する技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−２７９０４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来技術では、リクエストを送信しない限り相手装置の状況が分からなかった。このため、相手装置においてあるアプリケーションが利用できない状況においても、このアプリケーションの実行リクエストが送信される場合がある。このようなケースでは、実行リクエストの送信元及び送信先の装置において、無駄な負荷が生じてしまう。特に、リソースの限られた携帯電話やデジタルカメラ等の装置では大きな負荷となり、問題となる。
また、ユーザが利用する装置においてアプリケーションの選択を行うことができたにも関わらず、相手装置において、アプリケーションが実行できないという事態が発生するのは、ユーザの利便性の観点からも好ましくない。
【０００６】
本発明はこのような問題点に鑑みなされたもので、より適切に利用可能なアプリケーションをユーザに提示することのできる仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００７】
そこで、本発明は、サーバ装置が実行するサービスと連携して処理を行うクライアント装置であって、サービスの種類の指定を受け付ける指定受付手段と、指定された前記種類の前記サービスに対して設定されたサービス種別負荷と、過去に前記クライアント装置の指示によりアプリケーションを実行した時の前記サーバ装置の負荷であるクライアント別負荷と、前記サーバ装置が受容可能な受容負荷と、に基づいて、指定された前記サービスの種類に対応するアプリケーションの中から、前記サーバ装置が実行可能な前記アプリケーションを特定する特定手段と、前記特定手段により特定された前記アプリケーションの一覧画面を表示する表示手段とを備える。
【発明の効果】
【０００８】
本発明によれば、より適切に利用可能なアプリケーションをユーザに提示することができる。
【図面の簡単な説明】
【０００９】
【図１】連携システムを示す図である。
【図２】装置を示す図である。
【図３】クライアント部を示す図である。
【図４】アプリケーションリストの一例を示す図である。
【図５】サーバ部を示す図である。
【図６】実行履歴の一例を示す図である。
【図７】対照表の一例を示す図である。
【図８】インストールリストの一例を示す図である。
【図９】負荷リストの一例を示す図である。
【図１０】負荷設定画面の一例を示す図である。
【図１１】連携処理を示すフローチャートである。
【図１２】連携処理を説明するための図である。
【図１３】受容度リスト生成処理を示すフローチャートである。
【図１４】ＳＱＬ文の一例を示す図である。
【図１５】中間テーブルの一例を示す図である。
【図１６】受容度リストの一例を示す図である。
【図１７】ＸＭＬ形式の受容度リスト及び負荷リストの一例を示す図である。
【図１８】ファイルのディレクトリ構成の一例を示す図である。
【図１９】連携処理を説明するための図である。
【図２０】実行リクエスト送信処理を示すフローチャートである。
【図２１】ピッカー画面の表示例を示す図である。
【図２２】実行リクエスト送信処理を示すフローチャートである。
【図２３】ピッカー画面の表示例を示す図である。
【図２４】サーバ部を示す図である。
【図２５】予約テーブルの一例を示す図である。
【図２６】予約処理を示すシーケンス図である。
【図２７】予約処理において表示される画面例を示す図である。
【図２８】ＪａｖａＳｃｒｉｐｔ（登録商標）コードの一例を示す図である。
【図２９】予約情報の一例を示す図である。
【図３０】受容度リスト生成処理を示すフローチャートである。
【図３１】実行リクエスト送信処理を示すフローチャートである。
【発明を実施するための形態】
【００１０】
以下、本発明の実施形態について図面に基づいて説明する。
（第１の実施形態）
図１は、第１の実施形態にかかる情報処理を実行する連携システムを示す図である。連携システムは、携帯電話１０１と、デジタルカメラ１０２と、ＰＣ１０３とを有している。なお、携帯電話１０１と、デジタルカメラ１０２と、ＰＣ１０３とを適宜、装置１０１〜１０３と称することとする。各装置１０１〜１０３は、ＬＡＮやＷＡＮ等のネットワーク１０に接続している。なお、連携システムが備える装置の数や種類は、実施形態に限定されるものではない。
連携システムにおいては、各装置に搭載されたアプリケーションを他の装置が利用することにより、連携した機能を実現する。装置１０１〜１０３は、いずれもサーバ部１２０と、クライアント部１１０とを備えている。なお、本実施形態においては、各装置１０１〜１０３がサーバ部１２０と、クライアント部１１０とを備えるものとするが、これに限定されるものではない。すなわち、連携システムが備える装置は、サーバ部１２０及びクライアント部１１０のうち少なくとも一方を備えていればよい。なお、各装置は、サーバ部１２０が機能する場合には、サーバ装置として動作し、クライアント部１１０が機能する場合には、クライアント装置として動作するものとする。
【００１１】
各装置１０１〜１０３は、それぞれネットワーク１０上で他の装置を一意に識別できるものとする。具体的には、各装置１０１〜１０３には、装置の識別情報として、グローバル固定アドレスが割り振られているものとする。本実施形態においては、携帯電話１０１には、"ｍｏｂｉｌｅｐｈｏｎｅ．ｅｘａｍｐｌｅ．ｏｒｇ"のホスト名が割り振られているものとする。また、デジタルカメラ１０２には、"ｃａｍｅｒａ．ｅｘａｍｐｌｅ．ｏｒｇ"、ＰＣ１０３には、"ｐｃ．ｅｘａｍｐｌｅ．ｏｒｇ"のホスト名が割り振られているものとする。
サーバ部１２０には、各種サービスを実現するためのアプリケーションがインストールされている。サーバ部１２０は、インストールされているアプリケーションを実行する。クライアント部１１０は、サーバ部１２０に対し、アプリケーションの実行等を指示する。例えば、アプリケーション"Ｄｒａｗｅｒ"や"ＰｈｏｔｏＥｄｉｔｏｒ"は、画像編集のサービスを実現するためのアプリケーションである。
【００１２】
本実施形態においては、携帯電話１０１には、画像編集のアプリケーション"ＰｈｏｔｏＣｒｅａｔｅｒ"がインストールされているものとする。また、デジタルカメラ１０２には、画像編集のアプリケーション"Ｄｒａｗｅｒ"がインストールされているものとする。また、ＰＣ１０３には、画像編集のアプリケーション"ＰｈｏｔｏＥｄｉｔｏｒ"、動画編集のアプリケーション"ＭｏｖｉｅＥｄｉｔｏｒ"等がインストールされているものとする。各装置１０１〜１０３にインストールされたアプリケーションは、各装置１０１〜１０３のサーバ部１２０上で動作する。
【００１３】
図２は、各装置１０１〜１０３を示す図である。ＣＰＵ２０１は、システム制御部であり、装置全体を制御する。ＲＯＭ２０２は、ＣＰＵ２０１の制御プログラムや各種固定データを格納する。ＲＡＭ２０３は、ＳＲＡＭ、ＤＲＡＭ等である。ＲＡＭ２０３は、プログラム制御変数等を格納する。ＲＡＭ２０３はまた、各種設定パラメータ、各種ワーク用バッファを格納する。記憶部２０４は、ハードディスク等である。記憶部２０４は、画像データ等各種メディアファイルを格納する。
操作部２０５は、ボタンやタッチパネルであり、オペレータからの各種入力操作を受け付ける。通信部２０６は、ネットワーク１０に接続するためのインタフェースである。撮像部２０７は、カメラによって動画像を撮影するためのものである。時刻取得部２０８は、ＵＴＣ時刻を取得する。
【００１４】
なお、後述する携帯電話１０１の機能や処理は、携帯電話１０１のＣＰＵ２０１がＲＯＭ２０２又は記憶部２０４に格納されているプログラムを読み出し、このプログラムを実行することにより実現されるものである。デジタルカメラ１０２及びＰＣ１０３の機能や処理についても同様である。
より具体的には、各装置のクライアント部１１０の機能や処理は、クライアント部１１０を備える装置のＣＰＵ２０１がＲＯＭ２０２又は記憶部２０４に格納されているプログラムを読み出し、このプログラムを実行することにより実現されるものである。各装置のサーバ部１２０の機能や処理についても同様である。
【００１５】
図３は、クライアント部１１０を示す図である。以下、クライアント部１１０について説明する場合、対象とするクライアント部１１０と同一装置内のサーバ部１２０を自装置のサーバ部１２０と称することとする。また、対象とするクライアント部１１０を有する装置と異なる装置内のサーバ部１２０を他装置のサーバ部１２０と称することとする。
リクエスト送信部３０１は、各種リクエストを自装置又は他装置のサーバ部１２０に送信する。リクエストとしては、アプリケーション実行のリクエスト、リスト発行のリクエスト、負荷設定のリクエストがある。ここで、リスト発行のリクエストとは、クライアント部１１０を備える装置において実行されるアプリケーションと連携可能なアプリケーションのリスト（一覧）の送信要求である。また、負荷設定のリクエストとは、クライアント部１１０と同一装置内のサーバ部１２０においてサービスが実行された際の、同一装置内のサーバ部１２０の負荷の値の設定要求である。本実施形態においては、サーバ部１２０は、ユーザから入力されたサービス毎の負荷の値を、サーバ部１２０の負荷の値として設定することができるものとする。
【００１６】
リスト受信部３０２は、自装置又は他装置のサーバ部１２０から、サーバ部１２０の負荷リスト及び受容度リストを受信し、これらのリストを記憶部２０４に格納する。ここで、負荷リストとは、サーバ部１２０が実現するサービスと、サービスに対応するアプリケーションの実行時のサーバ部１２０の負荷とを示す情報である。受容度リストは、サーバ部１２０が受容可能な負荷の値を示す情報である。なお、負荷リスト及び受容度リストについては後に詳述する。
クライアントデータベース（クライアントＤＢ）３０３は、アプリケーションリスト３１０を格納している。アプリケーションリスト３１０は、クライアント部１１０が利用可能なアプリケーションのリストである。
【００１７】
リクエスト可否判定部３０４は、受容度リストと、負荷リストと、アプリケーションリストと、に基づいて、クライアント部１１０がアプリケーションを利用できるか否かを判定する。リクエスト可否判定部３０４はまた、クライアント部１１０が利用できると判定したアプリケーションの一覧画面をピッカーに表示する。
なお、「クライアント部１１０がアプリケーションを利用できる」とは、クライアント部１１０が機能連携として、あるサーバ部１２０に対しアプリケーションの実行を指示し、サーバ部１２０が指示されたアプリケーションを実行できることを意味する。
【００１８】
図４は、アプリケーションリスト３１０の一例を示す図である。アプリケーションリスト３１０は、クライアント部１１０が利用可能なアプリケーションを記録したアプリケーションの一覧情報である。ａｐｐｎａｍｅ列には、アプリケーション名が格納されている。ａｃｔｉｏｎ列には、アプリケーションに対応するＷｅｂ  Ｉｎｔｅｎｔｓのアクション名が格納されている。ｔｙｐｅ列には、アプリケーションに対応するＷｅｂ  ＩｎｔｅｎｔｓのＭＩＭＥタイプが格納されている。ｕｒｌ列には、アプリケーションのＵＲＬが格納されている。クライアント部１１０は、このＵＲＬにアクセスして、アプリケーションの実行を指示する。
【００１９】
図５は、サーバ部１２０を示す図である。以下、サーバ部１２０について説明する場合、対象とするサーバ部１２０と同一装置内のクライアント部１１０を自装置のクライアント部１１０と称することとする。また、対象とするサーバ部１２０を有する装置と異なる装置内のクライアント部１１０を他装置のクライアント部１１０と称することとする。
リクエスト受信部５０１は、自装置又は他装置のクライアント部１１０から各種リクエストを受信する。実行部５０２は、自装置にインストールされているアプリケーションを実行する。サーバＤＢ５０５は、実行履歴５１１と、対照表５１２と、インストールリスト５１３と、負荷リスト５１４とを格納している。サーバＤＢ５０５に格納されている情報については図６〜図９を参照しつつ、後に詳述する。
【００２０】
実行履歴管理部５０３は、実行部５０２によるアプリケーション実行履歴を示すレコードをサーバＤＢ５０５の実行履歴５１１に格納する。リスト生成部５０４は、実行履歴５１１と、負荷リスト５１４とに基づいて、受容度リストを生成する。リスト送信部５０６は、受容度リストと、負荷リストと、を自装置又は他装置のクライアント部１１０に送信する。負荷設定部５０７は、ユーザによって指定され、クライアント部１１０を介して受け付けた設定指示に従い、各サービスの負荷の値を、負荷リスト５１４に設定する。
図６は、実行履歴５１１の一例を示す図である。なお、本実施形態においては、実行履歴のサーバＤＢ５０５上のテーブル名を"ｅｘｅｃｌｏｇ"とする。実行履歴の各行には、実行部５０２による１つのアプリケーションの実行にかかるレコードが格納されている。ｓｔａｒｔ＿ｔｉｍｅ列には、クライアント部１１０から取得したアプリケーションの実行リクエストに基づいて、アプリケーションが起動した時刻が格納される。ｅｎｄ＿ｔｉｍｅ列には、アプリケーションの実行が終了した時刻が格納される。ｃｌｉｅｎｔ列には、アプリケーションの実行リクエストを送信したクライアント部１１０の識別子（ホスト名）が格納される。ｅｘｅｃａｐｐ列には、アプリケーション名が格納される。
【００２１】
図７は、対照表５１２の一例を示す図である。対照表５１２は、Ｗｅｂ  Ｉｎｔｅｎｔｓの内容を示すユーザが解りやすい表示名と、Ｗｅｂ  ＩｎｔｅｎｔｓのアクションとＭＩＭＥタイプとの関係を示す情報である。例えば、アクションｅｄｉｔ、ＭＩＭＥタイプｉｍａｇｅ／＊のＷｅｂ  Ｉｎｔｅｎｔｓは、「画像編集」の表示名に対応付けられている。本実施形態においては、対照表５１２のサーバＤＢ５０５上のテーブル名を"ｍａｔｃｈｉｎｇｔａｂｌｅ"とする。ｄｉｓｐｌａｙｎａｍｅ列には、表示列が格納されている。ａｃｔｉｏｎ列には、Ｗｅｂ  Ｉｎｔｅｎｔｓのアクションが格納されている。ｔｙｐｅ列には、Ｗｅｂ  ＩｎｔｅｎｔｓのＭＩＭＥタイプが格納されている。
図８は、インストールリスト５１３の一例を示す図である。インストールリスト５１３は、自装置にインストールされたアプリケーションの一覧である。本実施形態においては、インストールリストのサーバＤＢ５０５上のテーブル名を"ｉｎｓｔａｌｌｅｄｌｉｓｔ"とする。ａｐｐｎａｍｅ列には、アプリケーション名が格納されている。ａｃｔｉｏｎ列には、Ｗｅｂ  Ｉｎｔｅｎｔｓのアクションが格納されている。ｔｙｐｅ列には、Ｗｅｂ  ＩｎｔｅｎｔｓのＭＩＭＥタイプが格納されている。ｄｉｒｎａｍｅ列には、アプリケーションがインストールされたディレクトリ名が格納されている。
【００２２】
図９は、負荷リスト５１４の一例を示す図である。負荷リスト５１４は、アプリケーションが自装置のサーバ部１２０に与える負荷をＷｅｂ  Ｉｎｔｅｎｔｓの種類毎に示す情報である。本実施形態においては、負荷リスト５１４のサーバＤＢ５０５上のテーブル名を"ｌｏａｄｌｉｓｔ"とする。ａｃｔｉｏｎ列には、Ｗｅｂ  Ｉｎｔｅｎｔｓのアクションが格納されている。ｔｙｐｅ列には、Ｗｅｂ  ＩｎｔｅｎｔｓのＭＩＭＥタイプが格納されている。ｌｏａｄｓｃｏｒｅ列には、Ｗｅｂ  Ｉｎｔｅｎｔｓの負荷が格納されている。なお、負荷の取り得る値の範囲は予め定められているものとする。本実施形態においては、負荷の取り得る値は０〜５の範囲の値とする。
ここで、ｌｏａｄｓｃｏｒｅ列の値は、サーバ部１２０のサービスの種類（ａｃｔｉｏｎ，ＭＩＮＥタイプ）毎に設定されたサービス種別負荷の一例である。
【００２３】
図１０は、表示部２０９に表示される負荷設定画面の一例を示す図である。サーバ部１２０の管理者等は、サーバ部１２０が受けるＷｅｂ  Ｉｎｔｅｎｔｓの負荷を設定することができる。例えば、管理者の操作によりサーバ部１２０が自装置のブラウザから、"ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／ｃｏｎｆｉｇ／ｌｏａｄ／ｉｎｄｅｘ．ｐｈｐ"にアクセスすると、負荷設定画面１０００が表示される。
管理者等は、負荷設定画面１０００において、Ｗｅｂ  ＩｎｔｅｎｔｓのアクションとＭＩＭＥタイプに応じて、０〜５の範囲で負荷の設定入力を行うことができる。なお、負荷設定画面１０００には、対照表５１２において、Ｗｅｂ  ＩｎｔｅｎｔｓのアクションとＭＩＭＥタイプとに対応付けられた"ｄｉｒｎａｍｅ"がサービス名として表示されている。負荷設定画面１０００における負荷の設定が完了すると、負荷設定部５０７は、設定された値を負荷リスト５１４に格納する。
【００２４】
図１１は、連携システムにより実行される、連携処理を示すフローチャートである。図１１を参照しつつ連携処理の概要について説明する。Ｓ１１０１において、サーバ部１２０は、実行履歴５１１を作成する。具体的には、サーバ部１２０は、実行部５０２がアプリケーションを実行する（実行処理）度に、実行履歴５１１にレコードを格納する（履歴管理処理）。また、Ｓ１１０２において、サーバ部１２０は、負荷リスト５１４を作成する。なお、Ｓ１１０１及びＳ１１０２の処理は、次に説明するＳ１１０３以降の処理の実行前に行われていればよく、その実行タイミングは、特に限定されるものではない。
Ｓ１１０３において、クライアント部１１０は、例えば初期状態等、自装置の記憶部２０４に負荷リスト及び受容リストが格納されていない場合には、サーバ部１２０に対し、リスト発行リクエストを送信する。サーバ部１２０は、リスト発行リクエストを受信すると、Ｓ１１０４において、受容度リストを生成する。そして、サーバ部１２０は、作成した受容度リストと、サーバＤＢ５０５に格納されている負荷リストをクライアント部１１０に送信する。
【００２５】
クライアント部１１０は、Ｓ１１０５において、受容度リストと負荷リストとを受信し、受信した受容度リストと負荷リストとを記憶部２０４に格納する。そして、クライアント部１１０は、Ｗｅｂ  Ｉｎｔｅｎｔｓ発行時に、Ｓ１１０６において、受容度リストを解析し、アプリケーションが利用可能か否かを判定する。次に、Ｓ１１０７において、クライアント部１１０は、利用可能なアプリケーションをピッカーに表示する。
次に、Ｓ１１０８において、クライアント部１１０は、アプリケーションの実行リクエストをサーバ部１２０に送信する。そして、クライアント部１１０は、Ｗｅｂ  Ｉｎｔｅｎｔｓのレスポンスが戻るタイミングで、自身の記憶部２０４に格納されている受容度リストと負荷リストとを更新する。なお、図１１を参照しつつ説明した連携処理は、一定時間経過する度に実行されるものとする。なお、本実施形態にかかる連携システムは、１週間毎に、連携処理を実行する。
【００２６】
次に、Ｓ１１０３〜Ｓ１１０５の処理について詳述する。図１２に示すように、クライアント部１１０は、サーバ部１２０に対しリストの発行リクエストを送信する。ここでは、携帯電話１０１のクライアント部１１０から、ＰＣ１０３のサーバ部１２０に対し、リスト発行リクエストが送信される場合について説明する。
携帯電話１０１は、"ｈｔｔｐ：／／ｐｃ．ｅｘａｍｐｌｅ．ｏｒｇ／ｌｉｓｔ？ｓｔａｒｔ＝［ＡＣ＿ＡＧＯ］＆ｔｅｒｍ＝［ＡＣ＿ＴＥＲＭ］＆ｉｎｔｅｒｖａｌ＝［ＡＣ＿ＩＮＴＥＲＶＡＬ］"にアクセスする。すなわち、携帯電話１０１は、ＰＣ１０３へＧＥＴメソッドでＨＴＴＰリクエストを送信する。
【００２７】
このとき、パラメータは、"（ＡＣ＿ＡＧＯ  ＞＝  ＡＣ＿ＴＥＲＭ）  ＆＆  （ＡＣ＿ＴＥＲＭ  ＞＝  ＡＣ＿ＩＮＴＥＲＶＡＬ）"を満たすものとする。なお、このとき送信されるリクエストは、「現在時刻のＡＣ＿ＡＧＯ秒前からＡＣ＿ＴＥＲＭ秒分を元に、ＡＣ＿ＩＮＴＥＲＶＡＬ秒間隔の受容度リストを生成する」ことを意味するリクエストである。
ＰＣ１０３のサーバ部１２０は、リスト発行リクエストを受信すると、受容度リストを生成する。そして、ＰＣ１０３は、リスト発行リクエストに対するレスポンスとして負荷リストと、受容度リストとを携帯電話１０１に送信する。
【００２８】
図１３は、サーバ部１２０による、受容度リスト生成処理を示すフローチャートである。受容度リスト生成処理は、図１１を参照しつつ説明したＳ１１０４の処理に相当する処理である。Ｓ１３０１において、サーバ部１２０のリクエスト受信部５０１は、リスト発行リクエストを受信すると、リスト生成部５０４による受容度リスト生成処理が開始する。以下の処理は、リスト生成部５０４が行う処理となる。Ｓ１３０２〜Ｓ１３０８は、受容度リストを生成するための中間テーブルを生成する処理である。
まず、Ｓ１３０２において、サーバ部１２０は、リスト発行リクエストの送信元のクライアント部１１０の識別子を変数ｃｌｉｅｎｔに格納する。サーバ部１２０は、具体的には、ホスト名をクライアント部１１０の識別子として変数ｃｌｉｅｎｔに格納する。例えば、図１２に示すように、リスト発行リクエストの送信元が携帯電話１０１のクライアント部１１０である場合には、変数ｃｌｉｅｎｔの値は"ｍｏｂｉｌｅｐｈｏｎｅ"となる。
【００２９】
さらに、Ｓ１３０３において、サーバ部１２０は、処理時点での現在日時をＵＮＩＸＴＩＭＥで取得し、変数ｃｕｒｒｅｎｔに格納する。さらに、Ｓ１３０４において、サーバ部１２０は、受容度の最大値を変数ａｃｃｅｐｔ＿ｍａｘに格納する。なお、本実施形態においては、受容度の最大値は、"５"とする。なお、受容度の最大値は、操作部２０５への操作により、ユーザにより設定されるものとする。操作部２０５が受け付けた最大値は、クライアント部１１０により、記憶部２０４に格納される。
次に、Ｓ１３０５において、サーバ部１２０は、ＧＥＴメソッドのパラメータ解析処理を行う。サーバ部１２０はまず、変数ｌｉｓｔ＿ｓｔａｒｔに"ｃｕｒｒｅｎｔ  −  ＡＣ＿ＡＧＯ"の値を格納する。すなわち、変数ｌｉｓｔ＿ｓｔａｒｔの値は、実行履歴から抽出するデータの開始時刻となる。
【００３０】
次に、Ｓ１３０６において、サーバ部１２０は、変数ｌｉｓｔ＿ｅｎｄに"ｌｉｓｔ＿ｓｔａｒｔ  ＋  ＡＣ＿ＴＥＲＭ"の値を格納する。すなわち、変数ｌｉｓｔ＿ｅｎｄの値は、実行履歴から抽出するデータの終了時刻となる。
次に、Ｓ１３０７において、サーバ部１２０は、変数ｌｉｓｔ＿ｉｎｔｅｒｖａｌにＡＣ＿ＩＮＴＥＲＶＡＬの値を格納する。以上で、ＧＥＴメソッドのパラメータ解析処理が終了する。
【００３１】
次に、Ｓ１３０８において、サーバ部１２０は、ＳＱＬ文を実行することにより、中間テーブルを生成する。ここで、中間テーブルは、変数リストを生成する際に参照されるテーブルである。
図１４は、ＳＱＬ文の一例を示す図である。なお、ＳＱＬ文は、サーバ部１２０を有する装置の記憶部２０４等に予め格納されているものとする。図１４に示すＳＱＬ文（ＳＱＬ０１）は、実行履歴５１１に格納されているレコードのうち、ｌｉｓｔ＿ｓｔａｒｔからｌｉｓｔ＿ｅｎｄの範囲内の履歴を抽出し、実行したアプリケーションに対応するＷｅｂ  Ｉｎｔｅｎｔｓの負荷を表示する処理を示している。
【００３２】
図１５は、ＳＱＬ文により生成された中間テーブルの一例を示す図である。図１５には、６月８日４：００：００に、リクエストを処理した場合に得られる中間テーブル（ＴＢ０１）を示している。なお、リクエストは、"ＡＣ＿ＡＧＯ  ＝  １３３９０９５６００"、"ＡＣ＿ＴＥＲＭ  ＝  ８６４００"、"ＡＣ＿ＩＮＴＥＲＶＡＬ  ＝  １７９９"であるものとする。ここで、ＡＣ＿ＡＧＯは"一週間"、ＡＣ＿ＴＥＲＭは"２４時間"、ＡＣ＿ＩＮＴＥＲＶＡＬは"２９分５９秒"を表している。
図１３に戻り、Ｓ１３０９において、サーバ部１２０は、受容度リストを格納する空テーブルｔｍｐ＿ｔａｂｌｅを用意する。ここで、ｔｍｐ＿ｔａｂｌｅは、ｓｔａｒｔ列と、ｅｎｄ列と、ｍｙｌｏａｄ列と、ａｃｃｅｐｔ列を有するものとする。次に、Ｓ１３１０において、サーバ部１２０は、変数ｔｍｐ＿ｓｔａｒｔにｌｉｓｔ＿ｓｔａｒｔの値を格納する。
【００３３】
以降、Ｓ１３１１〜Ｓ１３１８の処理は、受容度リストを生成するためのループ処理である。ループ処理において、サーバ部１２０は、中間テーブル（ＴＢＬ０１）を解析し、受容度リストを生成する。まず、Ｓ１３１１において、サーバ部１２０は、"ｔｍｐ＿ｓｔａｒｔ  ＜＝  ｌｉｓｔ＿ｅｎｄ"の判定を行う。サーバ部１２０は、真と判断した場合（Ｓ１３１１でＹＥＳ）、処理をＳ１３１２へ進める。サーバ部１２０は、偽と判定した場合（Ｓ１３１１でＮＯ）、受容度リストが完成したと判断し、ループ処理を終了し、処理をＳ１３１９へ進める。
Ｓ１３１２において、サーバ部１２０は、中間テーブル（ＴＢＬ０１）から、探索する時間帯に該当し、且つ"ＴＢＬ０１．ｃｌｉｅｎｔ  ＝＝  ｃｌｉｅｎｔ"となる行のＴＢＬ０１．ｌｏａｄｓｃｏｒｅの最大値を取得する。そして、サーバ部１２０は、取得した最大値を、変数ａに格納する。すなわち、サーバ部１２０は、リスト発行リクエストの送信元のクライアント部１１０からの指示に従い実行されたアプリケーションの負荷を取得する。なお、サーバ部１２０は、"ｔｍｐ＿ｓｔａｒｔからｔｍｐ＿ｓｔａｒｔ  ＋  ｌｉｓｔ＿ｉｎｔｅｒｖａｌ"の時間帯を探索対象とする。
【００３４】
次に、Ｓ１３１３において、サーバ部１２０は、ＴＢＬ０１から、探索する時間帯に該当し、且つ"ＴＢＬ０１．ｃｌｉｅｎｔ！  ＝  ｃｌｉｅｎｔ"となる行のＴＢＬ０１．ｌｏａｄｓｃｏｒｅの最大値を取得する。そして、サーバ部１２０は、取得した最大値を、変数ｂに格納する。ここでは、サーバ部１２０は、リスト発行リクエストの発行元のクライアント部１１０以外のクライアント部１１０からの指示に従い実行されたプリケーションの負荷を取得する。なお、Ｓ１３１３においても、サーバ部１２０は、"ｔｍｐ＿ｓｔａｒｔからｔｍｐ＿ｓｔａｒｔ  ＋  ｌｉｓｔ＿ｉｎｔｅｒｖａｌ"の時間帯を探索対象とする。
次に、Ｓ１３１４において、サーバ部１２０は、"ａ  ＋  ｂ  ＞  ａｃｃｅｐｔ＿ｍａｘ"の判定を行う。サーバ部１２０は、真と判定した場合（Ｓ１３１４でＹＥＳ）、処理をＳ１３１５へ進める。サーバ部１２０は、偽と判定した場合（Ｓ１３１４でＮＯ）、処理をＳ１３１６へ進める。
【００３５】
Ｓ１３１５において、サーバ部１２０は、変数ｂの値を、"ａ  ＋  ｂ  ＝  ａｃｃｅｐｔ＿ｍａｘ"の関係を満たす値に変更する。具体的には、サーバ部１２０は、"ｂ  ＝  ａｃｃｅｐｔ＿ｍａｘ  −ａ"を実行する。
次に、Ｓ１３１６において、サーバ部１２０は、変数ｃに"ａｃｃｅｐｔ＿ｍａｘ  −  （ａ  ＋  ｂ）"の値を格納する。すなわち、変数ｃの値は、"ｔｍｐ＿ｓｔａｒｔからｔｍｐ＿ｓｔａｒｔ  ＋  ｌｉｓｔ＿ｉｎｔｅｒｖａｌ"の時間帯において、サーバ部１２０が受容可能な負荷の値（受容度）となる。次に、Ｓ１３１７において、サーバ部１２０は、受容度リスト（ｔｍｐ＿ｔａｂｌｅ）に時間帯と、ｍｙｌｏａｄと、ａｃｃｅｐｔとを格納する。
【００３６】
図１６は、受容度リストの一例を示す図である。本実施形態においては、受容度リストのサーバＤＢ５０５上のテーブル名を"ｔｍｐ＿ｔａｂｌｅ"とする。受容度リストは、ｓｔａｒｔ列と、ｅｎｄ列と、ｍｙｌｏａｄ列と、ａｃｃｅｐｔ列とを有している。サーバ部１２０は、Ｓ１３１７において、ｓｔａｒｔ列と、ｅｎｄ列に、それぞれ時間帯の開始時刻と終了時刻を格納する。さらに、サーバ部１２０は、ｍｙｌｏａｄ列に変数ａの値を格納する。さらに、サーバ部１２０は、ａｃｃｅｐｔ列に変数ｃの値を格納する。
このように、ｍｙｌｏａｄ列は、リスト発行リクエストの送信元のクライアント部１１０による指示に従いサーバ部１２０がアプリケーションを実行した際の負荷の値を格納している。すなわち、ｍｙｌｏａｄ列の値は、送信元のクライアント部１１０の指示による、サーバ部１２０の過去のアプリケーション実行時の負荷、すなわちクライアント別負荷の一例である。
また、ａｃｃｅｐｔ列は、対応する時間帯において、サーバ部１２０が受容可能な負荷の値を格納している。すなわち、ａｃｃｅｐｔ列の値は、サーバ部１２０が対応する時間帯において受容可能な受容負荷の一例である。すなわち、受容度リストは、クライアント別負荷及び受容負荷の値を含むリストである。
【００３７】
クライアント部１１０は、Ｓ１３１２〜Ｓ１３１７の処理において、実行履歴５１１と、負荷リスト５１４に示されるサービス種別負荷とに基づいて、クライアント別負荷を予測する。また、クライアント部１１０は、Ｓ１３１２〜Ｓ１３１７の処理において、実行履歴５１１と、負荷リスト５１４に示されるサービス種別負荷とに基づいて、受容負荷を予測する。すなわち、Ｓ１３１２〜Ｓ１３１７の処理は、クライアント別負荷予測処理及び受容負荷予測処理の一例である。
なお、"ｔｍｐ＿ｓｔａｒｔ"に"＄＿ＧＥＴ［'ＡＣ＿ＡＧＯ'］"を加算しているのは、過去の日時を、処理実行時点における現在の日時に変換して出力するためである。
【００３８】
次に、Ｓ１３１８において、サーバ部１２０は、"ｔｍｐ＿ｓｔａｒｔ  ＋＝  ｌｉｓｔ＿ｉｎｔｅｒｖａｌ  ＋  １"を実行する。次に、Ｓ１３１９において、サーバ部１２０は、上記処理により完成した受容度リストと、サーバＤＢ５０５に格納されている負荷リスト５１４を、ＸＭＬ形式で、リスト発行リクエストの送信元のクライアント部１１０に送信する。
ここで、Ｓ１３１９において送信される負荷リストは、サービス種別負荷（ｌｏａｄｓｃｏｒｅ）を含んでいる。また、Ｓ１３１９において送信される受容負荷リストは、クライアント別負荷（ｍｙｓｃ）と、受容負荷（ａｃｃｅｐｔ）とを含んでいる。すなわち、Ｓ１３１９の処理は、送信処理の一例である。
【００３９】
図１７（ａ）は、ＸＭＬ形式の受容度リストの一例を示す図である。図１７（ｂ）は、ＸＭＬ形式の負荷リストの一例を示す図である。図１７（ａ）に示す１７０３と１７０７の行のｓｔａｒｔとｅｎｄの値は、それぞれ図１６に示す受容度リストのｓｔａｒｔ列の値と、ｅｎｄ列の値をＵＮＩＸＴＩＭＥに変換したものである。
クライアント部１１０においては、リスト受信部３０２が受容度リスト及び負荷リストを受信する（受信処理）。そして、リスト受信部３０２は、受信した受容度リストをａｃｃｅｐｔ．ｘｍｌ、負荷リストをｌｏａｄ．ｘｍｌとしてファイルに保存する。ファイルの保存場所のディレクトリ構成の一例を図１８に示す。リスト受信部３０２は、ｌｉｓｔディレクトリ以下にサーバ別のディレクトリを作成し、その下にａｃｃｅｐｔ．ｘｍｌとｌｏａｄ．ｘｍｌを保存する。
【００４０】
次に、図１９を参照しつつ、Ｓ１１０６〜Ｓ１１０８の処理について詳述する。図１９（ａ）は、Ｓ１１０６〜Ｓ１１０８のプログラムの実行画面の表示例を示す図である。このプログラムは、Ｗｅｂ  Ｉｎｔｅｎｔｓで画像編集アプリを呼び出し、実行画面に表示される画像データ１９０２の編集を行うものである。
例えば、このプログラムは、携帯電話１０１のサーバ部１２０において、実行されるものとする。ユーザにより、実行画面中の「画像編集アプリ起動」のボタン１９０１が選択されたとする。この場合、クライアント部１１０は、画像編集のサービスの種類（画像編集）の指定とともに、プログラムの実行指示を受け付ける（指定受付処理）。そして、クライアント部１１０は、"ｈｔｔｐ：／／ｌｏｃａｌｈｏｓｔ／ａｐｐｓ／ｓａｍｐｌｅ"にアクセスすることで、このプログラムを実行することができる。
【００４１】
図１９（ｂ）は、プログラムのソースコードの一部を示す図である。ＪａｖａＳｃｒｉｐｔやＨＴＭＬ、Ｗｅｂ  Ｉｎｔｅｎｔｓについての説明は省略する。「画像編集アプリ起動」のボタン１９０１がクリックされると、クライアント部１１０（ＣＰＵ２０１）は、１９１５から１９１８の行において定義されたｏｎＰｉｃｔｕｒｅＥｄｉｔＢｕｔｔｏｎＣｌｉｃｋメソッドを呼び出す。ｏｎＰｉｃｔｕｒｅＥｄｉｔＢｕｔｔｏｎＣｌｉｃｋメソッドは、Ｗｅｂ  Ｉｎｔｅｎｔｓの発行処理を行う処理である。
クライアント部１１０は、ｏｎＰｉｃｔｕｒｅＥｄｉｔＢｕｔｔｏｎＣｌｉｃｋメソッドにより、１９１６の行を実行することにより、Ｉｎｔｅｎｔオブジェクトを生成する。クライアント部１１０は、Ｉｎｔｅｎｔオブジェクト生成のコンストラクタの引数として、Ｗｅｂ  ＩｎｔｅｎｔｓのアクションとＭＩＭＥタイプを渡している。画像編集のサービスのＷｅｂ  Ｉｎｔｅｎｔｓが発行される場合、アクションは"ｅｄｉｔ"、ＭＩＭＥタイプは"ｉｍａｇｅ／＊"となる。
【００４２】
そして、クライアント部１１０は、１９１７の行において、ｓｔａｒｔＡｃｔｉｖｉｔｙメソッドを呼び出し、Ｗｅｂ  Ｉｎｔｅｎｔｓの発行を行う。クライアント部１１０は、ｓｔａｒｔＡｃｔｉｖｉｔｙの引数として、１９１６の行で生成したＩｎｔｅｎｔオブジェクトと成功コールバックのメソッドを渡す。成功コールバックのメソッドは、１９１９〜１９２１の行において定義されたｓｕｃｃｅｓｓＣａｌｌｂａｃｋメソッドである。続いて、１９１７の行においてｓｔａｒｔＡｃｔｉｖｉｔｙメソッドが呼び出された後の処理について説明する。
【００４３】
図２０は、クライアント部１１０による、実行リクエスト送信処理を示すフローチャートである。なお、ここでは、ＸＭＬの操作はＸＰａｔｈを用いて示すものとする。クライアント部１１０は、１９１７の行において、ｓｔａｒｔＡｃｔｉｖｉｔｙメソッドを呼び出した後、実行リクエスト送信処理を開始する。なお、実行リクエスト送信処理は、リクエスト可否判定部３０４により実行される。
Ｓ２００１において、クライアント部１１０は、クライアントＤＢ３０３のアプリケーションリスト３１０から、Ｗｅｂ  Ｉｎｔｅｎｔｓの種類（サービスの種類）に対応するアプリケーションを抽出する。そして、クライアント部１１０は、抽出したアプリケーションを配列ａｐｐｓに格納する。次に、Ｓ２００２において、クライアント部１１０は、変数ＡＣＴＩＯＮをＷｅｂ  Ｉｎｔｅｎｔｓのアクションで初期化する。例えば、図１９（ｂ）に示す例においては、"ＡＣＴＩＯＮ  ＝  ｅｄｉｔ"となる。
【００４４】
次に、Ｓ２００３において、クライアント部１１０は、変数ＴＹＰＥをＷｅｂ  ＩｎｔｅｎｔｓのＭＩＭＥタイプで初期化する。例えば、図１９（ｂ）に示す例においては、"ＡＣＴＩＯＮ  ＝  ｉｍａｇｅ／＊"となる。次に、Ｓ２００４において、クライアント部１１０は、処理時点における現在時刻をＵＮＩＸＴＩＭＥで取得し、変数ＣＵＲＲＥＮＴに格納する。次に、Ｓ２００５において、クライアント部１１０は、ループ用変数ｉを０で初期化する。
続く、Ｓ２００６〜Ｓ２０１５の処理は、受容度リストを解析し、アプリケーションの利用可否を判定するループ処理である。Ｓ２００６において、クライアント部１１０は、"ｉ  ＜  ｓｉｚｅｏｆ（ａｐｐｓ）"の判定を行う。ここで、ｓｉｚｅｏｆ（ａｐｐｓ）は、配列ａｐｐｓに格納されているアプリケーションの数である。
【００４５】
クライアント部１１０は、Ｓ２００６で真と判断した場合（Ｓ２００６でＹＥＳ）、処理をＳ２００７へ進める。一方、クライアント部１１０は、Ｓ２００６で偽と判断した場合（Ｓ２００６でＮＯ）、受容度リストの解析処理を終了し、処理をＳ２０１６へ進める。
Ｓ２００７において、クライアント部１１０は、配列ａｐｐｓから１つのアプリケーションを処理対象として取り出す。そして、クライアント部１１０は、処理対象のアプリケーションが動作するサーバ部１２０の負荷リスト（ｌｏａｄ．ｘｍｌ）を用意する。次に、Ｓ２００８において、クライアント部１１０は、用意したｌｏａｄ．ｘｍｌの"／ｉｎｔｅｎｔｓ／ｉｎｔｅｎｔ／ｌｏａｄｓｃｏｒｅ［ａｃｔｉｏｎ＝'ＡＣＴＩＯＮ'  ａｎｄ  ｔｙｐｅ＝'ＴＹＰＥ'］"の値を変数ｂａｓｅに格納する。すなわち、変数ｂａｓｅは、サービスの種類毎に設定されたサービス種別負荷である。
【００４６】
次に、Ｓ２００９において、クライアント部１１０は、アプリケーションが動作するサーバ部１２０の受容度リスト（ａｃｃｅｐｔ．ｘｍｌ）を用意する。なお、負荷リスト及び受容度リストは、図１１を参照しつつ説明した連携処理（Ｓ１１０５）において、クライアント部１１０を有する装置の記憶部２０４に格納されている。
次に、Ｓ２０１０において、クライアント部１１０は、用意したａｃｃｅｐｔ．ｘｍｌの"／ｉｔｅｍｓ／ｉｔｅｍ／ｍｙｌｏａｄ［ｉｔｅｍ／＠ｓｔａｒｔ＜＝ＣＵＲＲＥＮＴ  ａｎｄ  ＠ｅｎｄ＞＝ＣＵＲＲＥＮＴ］"の値を変数ｍｙｓｃに格納する。すなわち、変数ｍｙｓｃは、クライアント部１１０の指示による、サーバ部１２０の過去のアプリケーション実行時の負荷、すなわちクライアント別負荷である。
【００４７】
次に、Ｓ２０１１において、クライアント部１１０は、"ｂａｓｅ  ＞  ｍｙｓｃ"の判定を行う。Ｓ２０１１の処理は、クライアント部１１０がこれからリクエストするアプリケーションの実行による負荷と、過去にこのクライアント部１１０からのリクエストによりアプリケーションが実行された際の負荷とを比較する処理である。
クライアント部１１０は、Ｓ２０１１において、真と判定した場合（Ｓ２０１１でＹＥＳ）、処理をＳ２０１４へ進める。一方、クライアント部１１０は、Ｓ２０１１において、偽と判定した場合（Ｓ２０１１でＮＯ）、処理をＳ２０１２へ進める。
【００４８】
Ｓ２０１２において、クライアント部１１０は、"／ｉｔｅｍｓ／ｉｔｅｍ／ｓｃｏｒｅ［ｉｔｅｍ／＠ｓｔａｒｔ＜＝ＣＵＲＲＥＮＴ  ａｎｄ  ＠ｅｎｄ＞＝ＣＵＲＲＥＮＴ］"の値を変数ｓｃに格納する。すなわち、変数ｓｃは、処理実行時点の時間帯における、サーバ部１２０の受容負荷である。
次に、Ｓ２０１３において、クライアント部１１０は、"ｂａｓｅ  ＜  ｓｃ"の判定を行う。Ｓ２０１３の処理は、クライアント部１１０がこれからリクエストするアプリケーションの負荷（ｂａｓｅ）と、サーバ部１２０の処理実行時点における受容負荷（ｓｃ）とを比較する処理である。
クライアント部１１０は、Ｓ２０１３において真と判定した場合には（Ｓ２０１３でＹＥＳ）、処理をＳ２０１４へ進める。一方、Ｓ１１０は、Ｓ２０１３において、偽と判定した場合には（Ｓ２０１３でＮＯ）、処理をＳ２０１５へ進める。
【００４９】
Ｓ２０１４において、クライアント部１１０は、処理対象のアプリケーションをサーバ部１２０が実行（受容）できると判断し、処理対象のアプリケーションの情報をピッカーに登録する。すなわち、クライアント部１１０は、クライアント別負荷がサービス種別負荷よりも小さい場合に、サーバ部１２０が受容できると判断する。また、クライアント部１１０は、クライアント別負荷がサービス種別負荷以上である場合であっても、受容負荷がサービス種別負荷よりも大きい場合には、サーバ部１２０が受容できると判断する。
そして、クライアント部１１０は、サーバ部１２０が受容できると判断した場合には、処理対象のアプリケーションを、サーバ部１２０が実行可能なアプリケーションとして特定する。
なお、クライアント部１１０は、サーバ部１２０が受容できると判断されなかった場合には、処理対象のアプリケーションは利用不可能と判断する。そして、クライアント部１１０は、利用不可能と判断されたアプリケーションについては、ピッカーへの登録を行わない。
ここで、Ｓ２０１１〜Ｓ２０１４の処理は、指定されたサービスの種類に対応するアプリケーションであって、サーバ部１２０が実行可能なアプリケーションを特定する特定処理の一例である。
【００５０】
次に、Ｓ２０１５において、クライアント部１１０は、"ｉ＋＋"を実行し、処理をＳ２００６へ進める。クライアント部１１０は、Ｓ２００６において、偽と判定した場合（Ｓ２００６でＮＯ）、受容度リストを解析するループ処理を終了し、処理をＳ２０１６へ進める。Ｓ２０１６において、クライアント部１１０は、ピッカー画面を表示する。ここで、ピッカー画面は、Ｓ２０１４において登録されたアプリケーションの一覧画面の一例である。また、Ｓ２０１６の処理は、表示処理の一例である。
【００５１】
図２１は、ピッカー画面の表示例を示す図である。図２１には、携帯電話１０１がＰＣ１０３に、２０１２年６月８日５：００のタイミングにおいて、図１９に示す画面においてＷｅｂ  Ｉｎｔｅｎｔｓを発行した場合のピッカー画面２１０１を示している。なお、クライアント部１１０は、図１７に示す受容度リスト及び負荷リストを用いて処理を行ったものとする。
例えば、図２０のＳ２００１において、図４に示すアプリケーションリスト３１０から"Ｄｒａｗｅｒ"と"ＰｈｏｔｏＣｒｅａｔｏｒ"と、"ＰｈｏｔｏＥｄｉｔｏｒ"が抽出されたとする。さらに、Ｓ２０１１〜Ｓ２０１４の処理において、"ＰｈｏｔｏＥｄｉｔｏｒ"のアプリケーションが除外されたとする。この場合、図２１に示すように、ピッカー画面２１０１には、"Ｄｒａｗｅｒ"と"ＰｈｏｔｏＣｒｅａｔｏｒ"のアプリケーション２１０２，２１０３が表示される。
【００５２】
図２０に戻り、Ｓ２０１７において、クライアント部１１０は、ピッカー画面２１０１において、ユーザによるアプリケーションの選択入力を受け付けたか否かを判定する。クライアント部１１０は、選択入力を受け付けた場合には（Ｓ２０１７でＹＥＳ）、処理をＳ２０１８へ進める。一方、Ｓ１１０は、選択入力を受け付けない場合には（Ｓ２０１７でＮＯ）、処理を終了する。
Ｓ２０１８において、クライアント部１１０は、選択されたアプリケーションの実行リクエストを、アプリケーションを搭載するサーバ部１２０を有する装置に送信する。例えば、図２１のピッカー画面２１０１において、"ＰｈｏｔｏＣｒｅａｔｏｒ"２１０３が選択されたとする。この場合、携帯電話１０１のクライアント部１１０は、"ｈｔｔｐ：／／ｃａｍｅｒａ．ｅｘａｍｐｌｅ．ｏｒｇ／ａｐｐ／ｐｈｏｔｏｃｒｅａｔｏｒ"にアクセスする。これに対し、デジタルカメラ１０２のサーバ部１２０は、携帯電話１０１から受信した実行リクエストにかかるアプリケーションを実行する。
【００５３】
次に、Ｓ２０１９において、クライアント部１１０は、アプリケーションの実行が終了すると、成功コールバックを呼び出す。成功コールバックは、例えば、図１９（ｂ）に示すプログラムの１９１９行のｓｕｃｃｅｓｓＣａｌｌｂａｃｋメソッドである。そして、Ｓ２０２０において、クライアント部１１０は、成功コールバックが呼ばれるタイミングで、アプリケーションが動作しているサーバ部１２０から再度受容度リストと負荷リストを受信する。そして、クライアント部１１０は、自身が有する受容度リストと負荷リストを、受信した受容度リストと負荷リストに更新する。以上で、実行リクエスト送信処理が完了する。
【００５４】
以上のように、本実施形態にかかる連携システムにおいては、クライアント部１１０は、サービス種別負荷と、クライアント別負荷と、受容負荷とに基づいて、連携して実行可能なアプリケーションを選択する。これにより、連携システムは、より適切に利用可能なアプリケーションを特定し、これをユーザに提示することができる。
【００５５】
なお、本実施形態にかかるクライアント部１１０は、サーバ部１２０から負荷リスト及び受容度リストを受信することとしたが、負荷リスト及び受容度リストの取得元はこれに限定されるものではなく、他の装置から取得することとしてもよい。
【００５６】
（第２の実施形態）
次に、第２の実施形態にかかる連携システムについて説明する。第２の実施形態にかかる連携システムでは、クライアント部１１０は、処理時点において利用不可能と判断したアプリケーションを利用可能になる時刻を予測し、これをピッカーに表示する。
以下、第２の実施形態にかかる連携システムについて、第１の実施形態にかかる連携システムと異なる部分について説明する。なお、第２の実施形態にかかる連携システムが備える各装置の構成は、第１の実施形態にかかる連携システムの各装置の構成と同様である。
【００５７】
図２２は、クライアント部１１０による、実行リクエスト送信処理を示すフローチャートである。ここでは、第１の実施形態にかかる実行リクエスト送信処理（図２０）と異なる処理について説明する。なお、第１の実施形態にかかる実行リクエスト送信処理中の処理ステップと同じ処理ステップには、同一番号を付している。
Ｓ２００６において、クライアント部１１０は、真と判定した場合（Ｓ２００６でＹＥＳ）、処理をＳ２２０１へ進める。Ｓ２００６において、クライアント部１１０は、偽と判定した場合（Ｓ２００６でＮＯ）、処理をＳ２０１６へ進める。なお、Ｓ２０１６以降の処理は、図２０に示すＳ２０１６以降の処理と同様である。
【００５８】
Ｓ２００１において、クライアント部１１０は、変数ＮＥＸＴに変数ＣＵＲＲＥＮＴの値を格納し、処理をＳ２００７へ進める。そして、クライアント部１１０は、Ｓ２００７〜Ｓ２００９の処理の後、処理をＳ２２０２へ進める。Ｓ２２０２において、クライアント部１１０は、Ｓ２００９で用意したａｃｃｅｐｔ．ｘｍｌに対して処理を行う。具体的には、クライアント部１１０は、"／ｉｔｅｍｓ／ｉｔｅｍ／ｍｙｌｏａｄ［ｉｔｅｍ／＠ｓｔａｒｔ＜＝ＮＥＸＴ  ａｎｄ  ＠ｅｎｄ＞＝ＮＥＸＴ］"の値を変数ｍｙｓｃに格納する。そして、クライアント部１１０は、処理をＳ２０１１へ進める。
Ｓ２０１１において、クライアント部１１０は、偽と判定した場合（Ｓ２０１１でＮＯ）、処理をＳ２２０３へ進める。Ｓ２０１１において、クライアント部１１０は、真と判定した場合（Ｓ２０１１でＹＥＳ）、処理をＳ２２０６へ進める。
【００５９】
Ｓ２２０３において、クライアント部１１０は、"／ｉｔｅｍｓ／ｉｔｅｍ／ｓｃｏｒｅ［ｉｔｅｍ／＠ｓｔａｒｔ＜＝ＮＥＸＴ  ａｎｄ  ＠ｅｎｄ＞＝ＮＥＸＴ］"の値を変数ｓｃに格納し、処理をＳ２０１３へ進める。Ｓ２０１３において、クライアント部１１０は、偽と判定した場合には（Ｓ２０１３でＮＯ）、処理をＳ２２０４へ進める。Ｓ２０１３において、クライアント部１１０は、真と判定した場合には（Ｓ２０１３でＹＥＳ）、処理をＳ２２０６へ進める。
Ｓ２２０４において、クライアント部１１０は、"ＮＥＸＴ  ＋＝  ＡＣ＿ＩＮＴＥＲＶＡＬ"を行う。これは、探索する時刻（時間帯）を進める処理である。次に、Ｓ２２０５において、クライアント部１１０は、"ＮＥＸＴ−ＣＵＲＲＥＮＴ"が一定時間以上の場合には（Ｓ２２０５でＹＥＳ）、処理をＳ２０１５へ進める。Ｓ２２０５において、クライアント部１１０は、"ＮＥＸＴ−ＣＵＲＲＥＮＴ"が一定時間未満の場合には（Ｓ２２０５でＮＯ）、処理をＳ２２０２へ進める。
ここで、"ＮＥＸＴ−ＣＵＲＲＥＮＴ"は、処理時点の現在時刻と、探索する時刻の差である。例として、差が６時間以上で探索を打ち切る場合、"ＮＥＸＴ−ＣＵＲＲＥＮＴ"の値は２１６００となる。なお、一定時間の値は任意であり、予め記憶部２０４に格納されているものとする。
【００６０】
Ｓ２０１１又はＳ２０１３において真と判定された場合には、ＮＥＸＴの時刻にアプリケーションが利用可能になる。そこで、Ｓ２２０６において、クライアント部１１０は、"ＮＥＸＴ  ＝＝  ＣＵＲＲＥＮＴ"の判定を行う。クライアント部１１０は、真と判断した場合は（Ｓ２２０６でＹＥＳ）、すなわちＮＥＸＴの値が処理時点の現在時刻である場合には、処理をＳ２０１４へ進め、アプリケーション情報をピッカーに登録する。
なお、処理時点の現在時刻は、基準タイミングの一例である。すなわち、本実施形態においては、サービスの種類の指定とともにプログラムの実行指示を受け付け、指定を受け付けたことにより実行されたＳ２００４の処理時点の時刻を基準タイミングとする。すなわち、基準タイミングは、サービスの種類の指定を受け付けた受付タイミングを基準として定まるタイミングである。
なお他の例としては、サービスの種類の指定と共に受け付けたプログラムの実行指示に従って開始される一連の処理の実行時間内の任意のタイミングが基準タイミングとして設定されていてもよい。また、他の例としては、プログラムの実行指示の受付タイミングから一定時間の範囲内の任意のタイミングが基準タイミングとして設定されていてもよい。
【００６１】
Ｓ２２０６において、クライアント部１１０は、偽と判定した場合（Ｓ２２０６でＮＯ）、すなわち、ＮＥＸＴの値が処理時点よりも未来の時刻である場合には、処理をＳ２２０７へ進める。Ｓ２２０７において、クライアント部１１０は、"ＮＥＸＴ−ＣＵＲＲＥＮＴ"の値をアプリケーション情報に登録し、Ｓ２２０８において、ピッカーに登録する。ここで、"ＮＥＸＴ−ＣＵＲＲＥＮＴ"の値は、処理対象のアプリケーションが何分後に利用可能となるかを示す情報である。
なお、Ｓ２２０７の処理と、Ｓ２２０７に続くＳ２０１４の処理は、処理時点の現在時刻、すなわち基準タイミング以降のタイミングにおいて実行可能なアプリケーションと、アプリケーションの実行可能な時間帯とを特定する特定処理の一例である。
このように、第２の実施形態にかかるクライアント部１１０は、時間帯毎のクライアント別負荷と、時間帯毎の受容負荷とに基づいて、アプリケーションの実行可能な時間帯を特定し、これをピッカーに登録する。
【００６２】
図２３は、利用可能な時刻を示すピッカー画面の表示例を示す図である。図２３には、携帯電話１０１がＰＣ１０３に、２０１２年６月８日５：００のタイミングにおいて、図１９に示す画面において、Ｗｅｂ  Ｉｎｔｅｎｔｓを発行した場合のピッカー画面２３０１を示している。なお、クライアント部１１０は、図１７に示す受容度リスト及び負荷リストを用いて処理を行ったものとする。
"ＰｈｏｔｏＥｄｉｔｏｒ"のアプリケーションは、処理時点の現在時刻においては利用不可能と判定されたものの、６０分後に利用可能と判定されたとする。この場合には、"ＰｈｏｔｏＥｄｉｔｏｒ"のアプリケーション２３０４とともに、"６０分後に利用可能"というメッセージが表示される。
【００６３】
このように、第２の実施形態にかかる連携システムにおいては、より適切に利用可能なアプリケーションを特定し、これをユーザに提示することができ、さらに後に利用可能となるアプリケーションについてもユーザに提示することができる。
【００６４】
（第３の実施形態）
次に、第３の実施形態にかかる連携システムについて説明する。第３の実施形態にかかる連携システムにおいては、ユーザは、クライアント部を介して、事前にサーバ部に対し、アプリケーションの予約を行うことができる。そして、サーバ部は、予約に係る実行希望時間に、確実にアプリケーションを実行することができる。以下、第３の実施形態にかかる連携システムについて、第１の実施形態にかかる連携システム異なる部分について説明する。
図２４は、第３の実施形態にかかるサーバ部１２１を示す図である。第３の実施形態にかかるサーバ部１２１は、第１の実施形態にかかるサーバ部１２０の構成に加えて、さらに予約部２４０１を備えている。また、サーバＤＢ５０５は、実行履歴５１１、対照表５１２、インストールリスト５１３、負荷リスト５１４に加えて、予約テーブル２４０２を格納している。予約部２４０１は、クライアント部１１０からの予約を受け付け、予約内容を示す予約情報を、予約テーブル２４０２に格納する。ここで、予約情報は、サービスの種類と、サービスの実行希望時間とが指定されたサービス実行の予約を示す情報である。
【００６５】
図２５は、予約テーブル２４０２の一例を示す図である。なお、本実施形態においては、予約テーブル２４０２のサーバＤＢ５０５上のテーブル名を"ｒｅｓｅｒｖｅｔａｂｌｅ"とする。予約テーブル２４０２は、ｓｔａｒｔ＿ｔｉｍｅ列と、ｅｎｄ＿ｔｉｍｅ列と、ｃｌｉｅｎｔ列と、ａｃｔｉｏｎ列と、ｔｙｐｅ列とを有している。
ｓｔａｒｔ＿ｔｉｍｅ列には、アプリケーションの利用を開始する時刻が格納される。ｅｎｄ＿ｔｉｍｅ列には、アプリケーションの利用を終了する時刻が格納される。すなわち、ｓｔａｒｔ＿ｔｉｍｅ列及びｅｎｄ＿ｔｉｍｅ列には、実行希望時間が格納される。ｃｌｉｅｎｔ列には、予約を行ったクライアント部１１０のクライアント名が格納される。
ａｃｔｉｏｎ列には、アプリケーションに対応するＷｅｂ  Ｉｎｔｅｎｔｓのアクションが格納される。ｔｙｐｅ列には、アプリケーションに対応するＷｅｂ  ＩｎｔｅｎｔｓのＭＩＭＥタイプが格納される。すなわち、ａｃｔｉｏｎ列及びｔｙｐｅ列には、サービスの種類が格納される。
【００６６】
図２６は、連携システムによる、予約処理を示すシーケンス図である。ユーザは、自身が利用する装置（携帯電話１０１、デジタルカメラ１０２又はＰＣ１０３）の表示部２０９に表示された予約画面において、予約情報を入力することができる。ユーザが利用する装置のクライアント部１１０は、サーバ部１２１の予約画面にアクセスすることにより、サーバ部１２１の予約画面をユーザが利用する装置の表示部２０９に表示する。
図２７（ａ）は、予約画面の一例を示す図である。図２７（ａ）には、クライアント部１１０が、"ｈｔｔｐ：／／ｐｃ．ｅｘａｍｐｌｅ．ｏｒｇ／ｒｅｓｅｒｖｅ．ｈｔｍｌ"にアクセスして表示したＰＣ１０３の予約画面２７０１を示している。予約画面２７０１において、ユーザは、アプリケーションの利用日、アプリケーションの実行を希望する開始時刻及び終了時刻（実行希望時間）、アプリケーションタイプ（サービスの種類）を入力する。そして、ユーザが予約ボタン２７０２をクリックすると、予約処理が開始する。
【００６７】
図２６に戻り、Ｓ２６０１において、クライアント部１１０は、予約画面に入力された予約情報を受け付ける（予約受付処理）。次に、Ｓ２６０２において、クライアント部１１０は、予約情報をサーバ部１２１に送信する。なお、送信先のサーバ部１２１は、予約画面表示時にアクセスした装置が備えるサーバ部１２１である。
サーバ部１２１は、予約情報を受信すると（受信処理）、Ｓ２６０３以降の処理を開始する。なお、Ｓ２６０３以降のサーバ部１２１の処理は、予約部２４０１により実行される。Ｓ２６０３において、サーバ部１２１は、予約情報の送信元のクライアント部１１０の識別子を取得し、これを変数ｃｌｉｅｎｔに格納する。次に、Ｓ２６０４において、サーバ部１２１は、予約を行う時間帯に、既に予約が存在するか判定する。サーバ部１２１は、予約が存在すると判定した場合には（Ｓ２６０４でＹＥＳ）、処理をＳ２６０５へ進める。一方、サーバ部１２１は、予約が存在しないと判断した場合は（Ｓ２６０４でＮＯ）、処理をＳ２６０８へ進める。
【００６８】
Ｓ２６０５において、サーバ部１２１は、確認された予約が変数ｃｌｉｅｎｔに登録されたクライアント部１１０による予約か否かを判定する。サーバ部１２１は、変数ｃｌｉｅｎｔに登録されたクライアント部１１０による予約ではないと判定した場合（Ｓ２６０５でＮＯ）、処理を２６０６へ進める。Ｓ２６０６において、サーバ部１２１は、予約対象のＷｅｂ  Ｉｎｔｅｎｔｓの負荷に、予約済みのＷｅｂ  Ｉｎｔｅｎｔｓの負荷を加算した値を変数ｓａに格納する。次に、Ｓ２６０７において、サーバ部１２１は、変数ｓａの値が受容度の最大値以下であるか否かを判定する。サーバ部１２１は、変数ｓａの値が受容度の最大値以下であると判定した場合（Ｓ２６０７でＹＥＳ）、処理をＳ２６０８へ進める。
サーバ部１２１は、変数ｓａの値が受容度の最大値よりも大きいと判定した場合（Ｓ２６０７でＮＯ）、予約はできないと判断し、処理をＳ２６１０へ進める。Ｓ２６１０において、サーバ部１２１は、クライアント部１１０にエラー通知を送信する。クライアント部１１０は、エラー通知を受信すると、Ｓ２６１２において、エラー画面を表示する。図２７（ｂ）は、エラー画面の一例を示す図である。エラー画面には、予約ができない旨の情報が表示される。
【００６９】
図２６に戻り、Ｓ２６０７において、サーバ部１２１は、変数ｓａの値が受容度の最大値以下であると判定した場合（Ｓ２６０７でＹＥＳ）、処理をＳ２６０８へ進める。Ｓ２６０８において、サーバ部１２１は、予約テーブル２４０２に予約情報を登録し、処理をＳ２６０９へ進める。また、Ｓ２６０５において、サーバ部１２１は、ｃｌｉｅｎｔの予約であると判定した場合は（Ｓ２６０５でＹＥＳ）、処理をＳ２６１１へ進める。Ｓ２６１１において、サーバ部１２１は、予約テーブル２４０２に予約情報を上書きし、Ｓ２６０８において、予約テーブルに予約情報を登録する。
Ｓ２６０９において、サーバ部１２１は、予約情報をクライアント部１１０のローカルストレージ（記憶部２０４）に格納する処理を行う。具体的には、クライアント部１１０は、ＪａｖａＳｃｒｉｐｔコードのｒｅｇｉｓｔＲｅｓｅｒｖａｔｉｏｎメソッドの呼び出しを行う。図２８は、ＪａｖａＳｃｒｉｐｔコードの一例を示す図である。
【００７０】
クライアント部１１０は、ｒｅｇｉｓｔＲｅｓｅｒｖａｔｉｏｎメソッドにより、予約情報をクライアント部１１０のローカルストレージに格納する。なお、ＪａｖａＳｃｒｉｐｔコードの２８０４の行は、予約情報を変数ｈｃａｌｄａｔａに格納する処理を示している。
なお、変数ｈｃａｌｄａｔａに格納される予約情報は、ＭｉｃｒｏｆｏｒｍａｔｓのｈＣａｌｅｎｄａｒの書式で表される。変数ｈｃａｌｄａｔａの内容を図２９に示す。図２９に示す２９０４，２９０５の行は、予約するＷｅｂ  ＩｎｔｅｎｔｓのアクションとＭＩＭＥタイプを示している。２９０６，２９０７の行は、予約開始日時を示している。２９０８，２９０９の行は、予約終了日時を示している。
【００７１】
クライアント部１１０は、図２８の２８０５の行の実行により、キーを"ｉｎｔｅｎｔＲｅｓｅｒｖｅ"、値を図２９に示す予約情報として、ローカルストレージに記録する。例えば、ローカルストレージに、ＨＴＭＬ５のＷｅｂＳｔｒｏｇｅを用いるものとする。ローカルストレージへの記録が完了すると、クライアント部１１０は、２８０８の行を実行し、図２６のＳ２６１２において、予約完了画面を表示する。図２７（ｃ）は、予約完了画面の表示例を示す図である。予約完了画面には、予約が完了した旨の情報が表示される。
【００７２】
図３０は、第３の実施形態にかかるサーバ部１２１による、受容度リスト生成処理を示すフローチャートである。なお、図３０には、第１の実施形態にかかる受容度リスト生成処理と異なる処理ステップを示している。なお、図３０において、第１の実施形態にかかる受容度リスト生成処理の処理ステップと同じ処理ステップには、同じ番号を付している。
サーバ部１２１は、Ｓ１３１１において、偽と判定した場合（Ｓ１３１１でＮＯ）、処理をＳ３００１へ進める。Ｓ３００１において、サーバ部１２１は、ｔｍｐ＿ｔａｂｌｅのカバーする時間を実行希望時間とする予約情報が存在するか否かを判定する。サーバ部１２１は、予約情報が存在すると判定した場合（Ｓ３００１でＹＥＳ）、処理をＳ３００２へ進める。サーバ部１２１は、予約情報が存在しないと判定した場合（Ｓ３００１でＮＯ）、処理をＳ１３１９へ進める。
【００７３】
Ｓ３００２において、サーバ部１２１は、予約情報にかかるサービスの負荷を変数ｄに格納する。次に、Ｓ３００３において、予約情報の送信元のクライアント部１１０が、リスト発行リクエストを発行したクライアント部１１０と同じであるか否かを判定する。サーバ部１２１は、同じであると判定した場合には（Ｓ３００３でＹＥＳ）、処理をＳ３００４へ進める。一方、サーバ部１２１は、同じではないと判定した場合には（Ｓ３００３でＮＯ）、処理をＳ３００５へ進める。
Ｓ３００４において、サーバ部１２１は、ｔｍｐ＿ｔａｂｌｅ．ｍｙｌｏａｄに変数ｄの値を格納し、処理をＳ３００５へ進める。Ｓ３００５において、サーバ部１２１は、ｔｍｐ＿ｔａｂｌｅ．ａｃｃｅｐｔに"ａｃｃｅｐｔ＿ｍａｘ  −  ｄ"の値を格納し、処理をＳ１３１９へ進める。
このように、サーバ部１２１は、予約情報と、サービス種別負荷と、実行履歴とに基づいて、クライアント別負荷を特定し、また受容負荷を特定する。
【００７４】
図３１は、クライアント部１１０による、実行リクエスト送信処理を示すフローチャートである。クライアント部１１０は、Ｓ２００６で真と判断した場合（Ｓ２００６でＹＥＳ）、処理をＳ３１０１へ進める。
Ｓ３１０１において、クライアント部１１０は、処理対象のアプリケーションを実行するサーバ部１２０の予約テーブルにおいて、処理対象のアプリケーションに対応するサービスに係る予約情報が存在するか否かを判定する。具体的には、Ｓ３１０１において、クライアント部１１０は、サーバ部１２０のホストに対応するローカルストレージに、図２９に示すような予約情報が存在するか否かを判定する。
【００７５】
クライアント部１１０は、予約情報が存在すると判定した場合には（Ｓ３１０１でＹＥＳ）、処理をＳ３１０２へ進める。クライアント部１１０は、予約情報が存在しないと判定した場合には（Ｓ３１０１でＮＯ）、処理をＳ２００７へ進める。
Ｓ３１０２において、クライアント部１１０は、ローカルストレージの値をパースする。そして、クライアント部１１０は、処理時点における現在時刻が予約情報に含まれる実行希望時間の範囲内であり、かつ、Ｗｅｂ  ＩｎｔｅｎｔｓのアクションとＭＩＭＥタイプが一致するか否か、すなわち予約情報を満たすか否かを判定する。クライアント部１１０は、予約情報を満たすと判定した場合には（Ｓ３１０２でＹＥＳ）、処理をＳ２０１４へ進める。クライアント部１１０は、予約情報を満たさないと判定した場合には（Ｓ３１０２でＮＯ）、処理をＳ２００７へ進める。
ここで、Ｓ３１０２の処理は、リスト発行リクエストを受け付けた時点（ＣＵＲＲＥＮＴ）が実行希望時間として指定された予約情報が予約テーブル２４０２に格納されているか否かを判定する判定処理の一例である。
【００７６】
以上の処理により、第３の実施形態にかかる連携システムにおいては、事前登録された予約情報に係るアプリケーションを確実に実行することができる。また、連携システムは、より適切に利用可能なアプリケーションを特定し、これをユーザに提示することができる。
【００７７】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給する。そして、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００７８】
以上、上述した各実施形態によれば、より適切に利用可能なアプリケーションをユーザに提示することができる。
【００７９】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００８０】
１０１  携帯端末、１０２  デジタルカメラ、１０３  ＰＣ、１１０  クライアント部、１２０，１２１  サーバ部、３０１  リクエスト送信部、３０２  リスト受信部、３０３  クライアントＤＢ、３０４  リスト可否判定部、５０１  リクエスト受信部、５０２  実行部、５０３  実行履歴管理部、５０４  リスト生成部、５０５  サーバＤＢ、５０６  リスト送信部、５０７  負荷設定部
【図１】
2015032251.tif 000003
【図２】
2015032251.tif 000004
【図３】
2015032251.tif 000005
【図４】
2015032251.tif 000006
【図５】
2015032251.tif 000007
【図６】
2015032251.tif 000008
【図７】
2015032251.tif 000009
【図８】
2015032251.tif 000010
【図９】
2015032251.tif 000011
【図１０】
2015032251.tif 000012
【図１１】
2015032251.tif 000013
【図１２】
2015032251.tif 000014
【図１３】
2015032251.tif 000015
【図１４】
2015032251.tif 000016
【図１５】
2015032251.tif 000017
【図１６】
2015032251.tif 000018
【図１７】
2015032251.tif 000019
【図１８】
2015032251.tif 000020
【図１９】
2015032251.tif 000021
【図２０】
2015032251.tif 000022
【図２１】
2015032251.tif 000023
【図２２】
2015032251.tif 000024
【図２３】
2015032251.tif 000025
【図２４】
2015032251.tif 000026
【図２５】
2015032251.tif 000027
【図２６】
2015032251.tif 000028
【図２７】
2015032251.tif 000029
【図２８】
2015032251.tif 000030
【図２９】
2015032251.tif 000031
【図３０】
2015032251.tif 000032
【図３１】
2015032251.tif 000033