JP6750349B2 - 情報処理システム、情報処理装置、情報処理プログラム及び情報処理方法 - Google Patents

Description

本発明は、情報処理システム、情報処理装置、情報処理プログラム及び情報処理方法に関する。

近年では、コンピュータネットワーク等の普及により、端末装置（クライアント）等が、ネットワークを介して他の情報処理装置（サーバ）が提供するサービスを利用するシステムが一般的になっている。

このシステムでは、サーバは、一定の期間リソースが使用されない場合には、リソースを解放することが知られている。また、このシステムでは、端末装置は、サーバとの無線通信が切断されると、切断後の接続の際に、自機にリソースが存在するか否かを確認し、存在する場合はリソースを再利用し、存在しなければサーバとの接続処理を行うことが知られている。

特開２００９−２９４９１５号公報 特開２００４−３２０６９４号公報

上述した従来の技術では、例えばサーバと端末装置との無線通信が頻繁に切断される状況では、端末装置からサーバへの再接続も頻繁に行われることになる。したがって、従来の技術では、端末装置は、再接続を行う度にリソースの存在を確認するリソース確認処理を実行することになり、処理の負荷を増大させる虞がある。

開示の技術は、リソース確認処理による負荷の増大を抑制することが可能な情報処理システム、情報処理装置、情報処理プログラム及び情報処理方法を提供することを目的としている。

一様態によれば、サーバと端末装置とを有する情報処理システムであって、前記サーバは、前記サーバにおける前記サーバと前記端末装置との接続の状態を示す第一の接続状態を管理するサーバ側状態監視処理部と、前記第一の接続状態と、前記端末装置において管理される第二の接続状態と、を同期させた結果に基づいて、前記サーバにより確保されたサーバ側リソースの解放又は再利用を行うサーバ側制御部と、を有し、前記端末装置は、前記端末装置における前記サーバと前記端末装置との接続の状態を示す前記第二の接続状態を管理する端末側状態監視処理部と、前記第二の接続状態と、前記第一の接続状態と、を同期させた結果に基づいて、前記端末装置により確保された端末側リソースの解放又は再利用を行う端末側制御部と、を有する。

上記各部は、上記各部を実現する処理部、上記各部を手順としてコンピュータにより実行させる方法、プログラムを記憶したコンピュータ読み取り可能な記憶媒体とすることもできる。

リソース確認処理による負荷の増大を抑制できる。

第一の実施形態の情報処理システムの概要を説明する図である。 リソースの再利用の動作を説明する図である。 リソースの解放の動作を説明する図である。 サーバのハードウェア構成の一例を示す図である。 第一の実施形態のサーバの接続状態保存データベースの一例を示す図である。 第一の実施形態のサーバのサービス利用情報データベースの一例を示す図である。 第一の実施形態の端末装置の接続状態テーブルの一例を示す図である。 第一の実施形態のアプリ利用情報テーブルの一例を示す図である。 第一の実施形態の情報処理システムの有する各装置の機能を説明する図である。 第一の実施形態のサーバのサービス登録部の処理を説明するフローチャートである。 第一の実施形態のサーバのサービス中継部の処理を説明するフローチャートである。 第一の実施形態のサーバのサービス制御部の処理を説明するフローチャートである。 第一の実施形態のサーバのサーバ状態同期部の処理を説明する第一のフローチャートである。 第一の実施形態のサーバのサーバ状態同期部の処理を説明する第二のフローチャートである。 第一の実施形態の端末装置のアプリ登録部の処理を説明するフローチャートである。 第一の実施形態の端末装置のアプリ制御部の処理を説明するフローチャートである。 第一の実施形態の端末装置の有する端末状態同期部の処理を説明するフローチャートである。 第二の実施形態の情報処理システムの有する各装置の機能を説明する図である。 第二の実施形態の接続状態保存データベースの一例を示す図である。 第二の実施形態のサービス利用情報データベースの一例を示す図である。 第二の実施形態のアプリ利用情報テーブルの一例を示す図である。 第二の実施形態のサーバのサービス登録部の処理を説明するフローチャートである。 第二の実施形態のサーバのサービス中継部の処理を説明するフローチャートである。 第二の実施形態のサーバのサーバ状態同期部の処理を説明するフローチャートである。 第二の実施形態のサーバのアプリ制御部の処理を説明するフローチャートである。 第二の実施形態の端末装置の端末状態同期部の処理を説明するフローチャートである。 第三の実施形態の情報処理システムのシステム構成の一例を示す図である。

（第一の実施形態）
以下に図面を参照して、第一の実施形態について説明する。図１は、第一の実施形態の情報処理システムの概要を説明する図である。

本実施形態の情報処理システム１００は、サーバ２００と、端末装置３００−１、３００−２、・・・、３００−Ｎを有する。以下の説明では、端末装置３００−１、３００−２、・・・、３００−Ｎのそれぞれを区別しない場合には、単に端末装置３００と呼ぶ。

本実施形態の情報処理システム１００において、サーバ２００と、端末装置３００とは、アクセスポイント２０を介して無線通信を行い、サーバ２００は、端末装置３００の各種の要求に応じたサービスを提供する。

図１に示す情報処理システム１００は、複数の端末装置３００のディスプレイに表示された画面の画像を、プロジェクタ等により１つの投影領域１０内に投影させるシステムの例を示している。

投影領域１０において、画像１１、１２は、端末装置３００−１のディスプレイに表示された画像が投影されたものであり、画像１３は、端末装置３００−２のディスプレイに表示された画像が投影されたものである。また、画像１４は、端末装置３００−Ｎのディスプレイに表示された画像が投影されたものである。

これらの画像は、端末装置３００−１、３００−２、・・・、３００−Ｎのそれぞれが、画像データをサーバ２００に送信し、サーバ２００がこの画像データをプロジェクタによって投影させることで、投影領域１０に投影される。

ところで、図１に示す情報処理システム１００では、サーバ２００と端末装置３００との通信はリアルタイムで行われるものであるが、環境によっては無線通信の接続が頻繁に切断される可能性がある。

そこで、本実施形態では、サーバ２００と端末装置３００のそれぞれに、サーバ２００と端末装置３００との接続の状態を示す情報を管理する状態監視処理部を設け、サーバ２００と端末装置３００のそれぞれにおいて、接続の状態を示す情報を同期させる。そして、本実施形態では、接続の状態を示す情報を同期させた後に、サーバ２００及び端末装置３００にリソースを解放又は再利用させる。

そのため、本実施形態の情報処理システム１００では、サーバ２００及び端末装置３００は、それぞれの状態監視処理部によりリソースの解放を指示された場合にのみ、リソースの解放を行えば良い。

よって、本実施形態によれば、サーバ２００及び端末装置３００は、リソースが確保されているか否かを確認するための処理か不要となる。言い換えれば、本実施形態によれば、端末装置３００とサーバ２００との通信が切断された後の接続の際に、端末装置３００はサービスの提供を受けるためのリソースが確保されているか否かを確認する処理（リソース確認処理）を行わなくても良い。したがって、本実施形態によれば、リソース確認処理による負荷の増大を抑制することができる。

尚、以下の説明では、サーバ２００における端末装置３００にサービスを提供するためのリソースをサービス側リソースと呼ぶ。また、以下の説明では、端末装置３００のアプリケーションがサービスの提供を受けるために利用するリソースを端末側リソースと呼ぶ。

また、本実施形態におけるリソースとは、ソフトウェアやハードウェアを動作させるのに必要な演算処理装置の処理速度やメモリ容量、ハードディスクの容量等を意味する。

本実施形態のサーバ２００は、状態監視処理部２１０、接続状態保存データベース２２０、サービス利用情報データベース２３０を有する。状態監視処理部２１０は、サーバ２００と端末装置３００との状態を監視した結果に応じて端末装置３００にサービスを提供するためのリソースの解放のタイミングを制御する。

接続状態保存データベース２２０は、サーバ２００と各端末装置３００との接続の状態を示す情報（接続状態情報）が格納される。サービス利用情報データベース２３０は、各端末装置３００のアプリケーションに提供されるサービスに関する情報が格納される。

本実施形態の端末装置３００は、状態監視処理部３１０、接続状態テーブル３２０、アプリ利用情報テーブル３３０を有する。状態監視処理部３１０は、端末装置３００と、サーバ２００との状態を監視した結果に応じて、端末装置３００のアプリケーションがサービスの提供を受けるために利用するリソースの解放のタイミングを制御する。

接続状態テーブル３２０は、端末装置３００と、サーバ２００との接続の状態を示す接続状態情報が格納される。アプリ利用情報テーブル３３０は、端末装置３００にインストールされたアプリケーションによるサービスの利用に関する情報が格納される。

以下に、図２及び図３を参照し、本実施形態のサーバ２００及び端末装置３００におけるサービス側リソースと端末側リソースの再利用と解放について説明する。

図２は、リソースの再利用の動作を説明する図である。図２（Ａ）は、サーバ２００と端末装置３００のそれぞれにおいて、接続状態情報がオンラインである場合を示している。図２（Ｂ）は、サーバ２００の接続状態情報はオンラインであり、端末装置３００の接続状態情報が一時的にオフラインとなる場合を示している。

尚、本実施形態では、サーバ２００と端末装置３００とが無線通信により接続されている状態とは別に、後述するハートビートにより接続を確認できている状態を、接続状態情報がオンラインである、と表現する。また、サーバ２００と端末装置３００との接続が確認できなくなった状態を、接続状態情報がオフラインである、と表現する。

本実施形態の端末装置３００は、サーバ２００と接続されている状態において、自機とサーバ２００との接続が有効であることを示すために、定期的に信号を送信する。以下の説明では、この信号をハートビートと呼ぶ。本実施形態の端末装置３００は、ハートビートと共に、接続状態情報をサーバ２００へ送信するものとした。

本実施形態のサーバ２００は、端末装置３００から接続状態情報を受け付けると、端末装置３００からの接続状態情報がオンラインで自機の接続状態情報がオフラインのときのみオフラインを端末装置３００へ送信し、それ以外はオンラインを端末装置３００に送信する。また、本実施形態のサーバ２００は、所定の期間ハートビートを受信しない場合、端末装置３００との通信が切断されたものとして、自機の接続状態情報をオフラインとし、サービス側リソースを解放させる。

また、本実施形態の端末装置３００は、サーバ２００に対して所定の期間ハートビートが送信できない場合、サーバ２００との通信が切断されたものとして、自機の接続状態情報をオフラインとし、端末側リソースを解放させる。

言い換えれば、本実施形態のサーバ２００と端末装置３００のそれぞれは、ハートビートの送受信が行われない期間が所定の期間より短い場合には、通信が有効であるものとし、それぞれの接続状態情報をオンラインに維持する。

図２（Ａ）では、サーバ２００と端末装置３００とが接続されている。よって、端末装置３００は、ハートビートと共に、オンラインの接続状態情報をサーバ２００へ送信する（ステップＳ２１）。

サーバ２００は、この接続状態情報を受けて、サーバ２００の接続状態情報を端末装置３００へ返す（ステップＳ２２）。このとき、サーバ２００の接続状態情報もオンラインであり、サーバ２００の接続状態情報と、端末装置３００の接続状態情報とは同期している。

したがって、図２（Ａ）の状態では、サーバ２００により提供されるサービスは、サービス側リソースの利用を中断されることがなく、端末装置３００のアプリケーションもサービスの提供を受けるための端末側リソースの利用を中断されることがない。言い換えれば、サーバ２００はサービス側リソースを利用し続け、端末装置３００は端末側リソースを利用し続けることができる。

図２（Ｂ）では、サーバ２００と端末装置３００との無線接続が、タイミングｔ１からタイミングｔ２までの期間Ｔａにおいて切断されている。したがって、期間Ｔａの間は、端末装置３００からサーバ２００に対してハートビートが送信されない。

図２（Ｂ）において、端末装置３００は、タイミングｔ２においてサーバ２００との通信が可能となったとき、接続状態情報をサーバ２００へ送信する（ステップＳ２３）。

このとき、期間Ｔａは、サーバ２００が端末装置３００との通信が切断されたと判断する所定の期間よりも短い期間とした。したがって、端末装置３００は、自機の接続状態情報をオンラインに維持しており、オンラインの接続状態情報をサーバ２００へ送信する。

このため、図２（Ｂ）において、期間Ｔａの間、サーバ２００は、端末装置３００との通信が接続されているものとして、接続状態情報をオンラインに維持している。したがって、サーバ２００は、端末装置３００からの接続状態情報を受けて、オンラインの接続状態情報を端末装置３００へ送信する（ステップＳ２４）。

端末装置３００の接続状態情報は、無線通信の接続とは別に管理されるものなので、無線接続が切断されていた期間Ｔａにおいても、オンラインを維持している。

したがって、図２（Ｂ）の状態では、サーバ２００により提供されるサービスは、サービス側リソースの利用を中断されることがなく、端末装置３００のアプリケーションもサービスの提供を受けるための端末側リソースの利用を中断されることがない。

言い換えれば、図２（Ｂ）では、サーバ２００と端末装置３００の通信が一時的に切断されているが、端末装置３００のアプリケーションは、切断後の通信が回復した後も、切断前に確保した端末側リソースを再利用する。よって、図２（Ｂ）の例では、端末装置３００は、通信の切断が回復した後のリソース確認処理を行う必要がなく、リソース確認処理による負荷の増大が抑制される。

図３は、リソースの解放の動作を説明する図である。図３（Ａ）は、端末装置３００の接続状態情報がオンラインであり、サーバ２００の接続状態情報がオフラインのときに、端末装置３００からサーバ２００へ接続状態情報が送信された場合を示す。

図３（Ａ）において、端末装置３００は、オンラインの接続状態情報をサーバ２００へ送信する（ステップＳ３１）。サーバ２００は、この接続状態情報を受けたとき、サービスに対してサービス側リソースの解放指示が行われた後であり（ステップＳ３２）、接続状態情報がオフラインとなっている。したがって、サーバ２００は、オフラインの接続状態情報を端末装置３００へ返す（ステップＳ３３）。

サーバ２００が自機の接続状態情報をオフラインとし、サービス側リソースの解放指示を行う場合とは、例えば、所定の期間端末装置３００から接続状態情報を受信しなかった場合等である。この場合、サーバ２００は、端末装置３００との通信が切断されたものとし、自機の接続状態情報をオンラインからオフラインとして、サービス側リソースを解放する。

端末装置３００は、サーバ２００からオフラインの接続状態情報を受けて、アプリケーションに対して端末側リソースの解放指示を行う（ステップＳ３４）。アプリケーションは、この解放指示を受けて、サービスの提供を受けるための端末側リソースを解放する。ここで、サーバ２００と端末装置３００のそれぞれの接続状態情報はオフラインであり、接続状態が同期する。

端末装置３００は、接続状態情報をオフラインとしてサーバ２００の接続状態情報と同期させる処理が完了すると、サーバ２００に対してオフラインの接続状態情報を送信する（ステップＳ３５）。

サーバ２００は、端末装置３００において、接続状態情報がオフラインとされたことを受けて、接続状態情報をオフラインからオンラインとし、オンラインの接続状態情報を端末装置３００へ返す（ステップＳ３６）。

端末装置３００は、サーバ２００からオンラインの接続状態情報を受けて、オフラインの接続状態情報をオンラインとし、アプリケーションに端末側リソースを確保させる（ステップＳ３７）。言い換えれば、端末装置３００は、アプリケーションに対し、サービスへの再接続を指示する。つまり、端末装置３００は、アプリケーションに対し、サービスの提供を要求させる。

このとき、サーバ２００と端末装置３００のそれぞれの接続状態情報はオンラインとなっており、両者の接続状態情報が同期する。サーバ２００と端末装置３００において接続状態情報が同期すると、端末装置３００のアプリケーションは、サービスに対してサービスの提供を要求する（ステップＳ３８）。

図３（Ｂ）は、端末装置３００の接続状態情報がオフラインであり、サーバ２００の接続状態情報がオンラインのときに、端末装置３００からサーバ２００へ接続状態情報が送信された場合を示す。

図３（Ｂ）の例では、端末装置３００において、接続状態情報がオフラインとされ、端末側リソースの解放指示が行われている（ステップＳ４１）。

この状態で、サーバ２００と端末装置３００との通信が開始されると、端末装置３００は、オフラインの接続状態情報をサーバ２００へ送信する（ステップＳ４２）。サーバ２００は、この接続状態情報を受けて、自機の接続状態情報をオンラインからオフラインとし、サービスに対してサービス側リソースの解放指示を行う（ステップＳ４３）。

ここで、サーバ２００と端末装置３００のそれぞれの接続状態情報はオフラインであり、接続状態が同期する。

サーバ２００は、接続状態情報が端末装置３００と同期すると、自機の接続状態情報をオフラインからオンラインとし、端末装置３００に対してオンラインの接続状態情報を送信する（ステップＳ４４）。

端末装置３００は、オンラインの接続状態情報を受けて、自機の接続状態情報をオフラインからオンラインとして、アプリケーションに端末側リソースを確保させる（ステップＳ４５）。

このとき、サーバ２００と端末装置３００のそれぞれの接続状態情報はオンラインとなっており、接続状態が同期する。サーバ２００と端末装置３００において接続状態が同期すると、端末装置３００のアプリケーションは、サービスに対してサービスの提供を要求する（ステップＳ４６）。

図３（Ｃ）は、サーバ２００の接続状態情報と、端末装置３００の接続状態情報との両方がオフラインであるときに、端末装置３００からサーバ２００へ接続状態情報が送信された場合を示す。

図３（Ｃ）の例では、サーバ２００において、接続状態情報がオフラインとされ、サービス側リソースの解放指示が行われている（ステップＳ５１）。また、端末装置３００において、接続状態情報がオフラインとされ、端末側リソースの解放指示が行われている（ステップＳ５２）。

この状態で、サーバ２００と端末装置３００との通信が開始されると、端末装置３００は、オフラインの接続状態情報をサーバ２００へ送信する（ステップＳ５３）。ここで、サーバ２００と端末装置３００のそれぞれの接続状態情報はオフラインであり、接続状態が同期する。

よって、サーバ２００は、この接続状態情報を受けて、自機の接続状態情報をオフラインからオンラインとし、端末装置３００に対してオンラインの接続状態情報を送信する（ステップＳ５４）。

端末装置３００は、オンラインの接続状態情報を受けて、自機の接続状態情報をオフラインからオンラインとして、アプリケーションに端末側リソースを確保させる（ステップＳ５５）。

このとき、サーバ２００と端末装置３００のそれぞれの接続状態情報はオンラインとなっており、接続状態が同期する。サーバ２００と端末装置３００において接続状態が同期すると、端末装置３００のアプリケーションは、サービスに対してサービスの提供を要求する（ステップＳ５６）。

図３（Ｃ）のＳ５３以降の処理は、図３（Ａ）のＳ３５以降の処理と同じである。

以上が、本実施形態の情報処理システム１００におけるサーバ２００の状態監視処理部２１０と、端末装置３００の状態監視処理部３１０の動作である。

図２及び図３からわかるように、本実施形態の情報処理システム１００では、サーバ２００と端末装置３００の両方の接続状態情報がオンラインで同期している場合には、サービス側リソース及び端末側リソースを解放させず、継続して利用する。

また、本実施形態の情報処理システム１００では、サーバ２００と端末装置３００の接続状態情報が同期していない場合には、それぞれの接続状態情報を一度オフラインで同期させ、サービス側リソースと端末側リソースを解放させる。そして、情報処理システム１００は、その後にサーバ２００と端末装置３００の接続状態情報をオンラインで同期させ、サービス側リソースと端末側リソースのそれぞれを確保させる。

また、本実施形態の情報処理システム１００では、サーバ２００と端末装置３００の両方の接続状態情報がオフラインで同期している場合には、サーバ２００と端末装置３００の接続状態情報をオンラインで同期させ、サービス側リソースと端末側リソースのそれぞれを確保させる。

したがって、本実施形態によれば、サーバ２００と端末装置３００のそれぞれにおいて、サービス側リソースや端末側リソースが確保されているか否かを確認するリソース確認処理を行わずに、リソースの利用の継続（再利用）や、リソースの解放及び確保を行う。このために本実施形態によれば、サーバ２００と端末装置３００の接続の状態に関わらず、リソース確認処理を行う必要がなく、リソース確認処理を実行することによる負荷の増大を抑制できる。

また、本実施形態の情報処理システム１００では、以上のようにサービス側リソースと端末側リソースを管理するため、例えばサーバ２００と端末装置３００の一時的な通信の切断が生じても、投影領域内１０に対する画像の投影を継続できる。したがって、本実施形態によれば、一時的な通信の切断が頻繁に発生した場合でも、投影された画像が通信の切断に応じて頻繁に更新される、といった事態を回避できる。

また、本実施形態の情報処理システム１００では、端末装置３００からサーバ２００に対して所定の期間接続状態情報が送信されない場合には、サーバ２００は自機の接続状態情報をオフラインとし、サービス側リソースを解放させる。よって、本実施形態の情報処理システム１００によれば、端末装置３００との一時的でない通信の切断が生じた場合には、サービス側リソースを解放し、投影領域１０から、通信が切断された端末装置３００から受信した画像を消去することができる。

尚、本実施形態の情報処理システム１００は、端末装置３００の画面に表示された画像を投影領域１０に投影させるものとしたが、これに限定されない。本実施形態は、サーバ２００と端末装置３００とが常時無線通信で接続された状態でサービスの授受を行うものであれば、どのような形態であっても適用できる。

以下に、本実施形態のサーバ２００と端末装置３００について説明する。図４は、サーバのハードウェア構成の一例を示す図である。

本実施形態のサーバ２００は、例えばデスクトップやノート型のコンピュータであり、それぞれバスＢで相互に接続されている入力装置２１、出力装置２２、ドライブ装置２３、補助記憶装置２４、メモリ装置２５、演算処理装置２６及びインターフェース装置２７を含む。

入力装置２１は、各種の情報を入力するためものであり、例えばキーボードやマウス等で実現される。出力装置２２は、各種の情報を出力するためのものであり、例えばディスプレイ等により実現される。インターフェース装置２７は、モデム、ＬＡＮカード等を含み、ネットワークに接続する為に用いられる。

情報処理プログラムは、サーバ２００を制御する各種プログラムの少なくとも一部である。情報処理プログラムは例えば記憶媒体２８の配布やネットワークからのダウンロードなどによって提供される。情報処理プログラムを記録した記憶媒体２８は、ＣＤ−ＲＯＭ、フレキシブルディスク、光磁気ディスク等の様に情報を光学的、電気的或いは磁気的に記録する記憶媒体、ＲＯＭ、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等、様々なタイプの記憶媒体を用いることができる。

また、情報処理プログラムは、情報処理プログラムを記録した記憶媒体２８がドライブ装置２３にセットされると、記憶媒体２８からドライブ装置２３を介して補助記憶装置２４にインストールされる。ネットワークからダウンロードされた情報処理プログラムは、インターフェース装置２７を介して補助記憶装置２４にインストールされる。

補助記憶装置２４は、インストールされた情報処理プログラムを格納すると共に、必要なファイル、データ等を格納する。メモリ装置２５は、コンピュータの起動時に補助記憶装置２４から情報処理プログラムを読み出して格納する。そして、演算処理装置２６はメモリ装置２５に格納された情報処理プログラムに従って、後述するような各種処理を実現している。

また、本実施形態のサーバ２００は、例えばタブレット型のコンピュータ等であっても良い。その場合、入力装置２１と出力装置２２の代わりに、表示機能を有するタッチパネル等の表示操作装置を有していても良い。尚、本実施形態の端末装置３００は、例えばスマートフォンや一般のタブレット型のコンピュータ等であり、そのハードウェア構成は、図４に示すサーバ２００と同様であるから、説明を省略する。

次に、図５乃至図８を参照し、本実施形態のサーバ２００の有する各データベースと、端末装置３００が有する各テーブルについて説明する。

図５は、第一の実施形態のサーバの接続状態保存データベースの一例を示す図である。本実施形態の接続状態保存データベース２２０は、予めサーバ２００に設けられている。本実施形態の接続状態保存データベース２２０は、情報の項目として、端末ＩＤ、接続状態、オフライン判定時間を有する。

項目「端末ＩＤ」の値は、端末装置３００を特定するための識別子である。項目「端末ＩＤ」の値は、予め端末装置３００に付与されている。

項目「接続状態」の値は、サーバ２００と端末装置３００との接続状態を示す。本実施形態では、項目「接続状態」の値がオンラインである場合、サーバ２００と、対応する端末ＩＤで特定される端末装置３００との通信が接続された状態を示す。また、項目「接続状態」の値がオフラインである場合、サーバ２００と、対応する端末ＩＤで特定される端末装置３００との通信が切断された状態を示す。

項目「オフライン判定時間」の値は、サーバ２００が端末装置３００との通信が切断されたと判定する期間を示す。例えば、項目「オフライン判定時間」の値が１秒であった場合、サーバ２００は、端末装置３００からハートビートを１秒間受信しなかった場合に、端末装置３００との通信が切断されたと判定する。

本実施形態の接続状態保存データベース２２０では、サーバ２００が端末装置３００から接続状態情報を受信すると、オフライン判定時間のカウントダウン（減算）を開始する。そして、サーバ２００は、端末装置３００から次に接続状態情報を受信したとき、オフライン判定時間のカウントダウンを停止し、オフライン判定時間を予め決められた期間（図５では１秒）に戻す。

言い換えれば、サーバ２００は、端末装置３００から接続状態情報を受信すると、接続状態保存データベース２２０において端末装置３００の端末ＩＤと対応するオフライン判定時間をリセットして初期値に戻し、カウントダウンを開始する。

本実施形態のサーバ２００は、オフライン判定時間のカウントダウンが開始され、オフライン判定時間の値が０以下となったとき、端末装置３００との通信が切断されたと判定する。

図６は、第一の実施形態のサーバのサービス利用情報データベースの一例を示す図である。本実施形態のサービス利用情報データベース２３０は、情報の項目として、サービスＩＤ、サービス通知先、端末ＩＤリストを有し、項目「サービスＩＤ」にその他の項目が対応付けられている。以下の説明では、項目「サービスＩＤ」の値と、その他の項目の値とを含む情報をサービス利用情報と呼ぶ。

項目「サービスＩＤ」の値は、サーバ２００が端末装置３００へ提供するサービスを特定するための識別子である。項目「サービス通知先」の値は、例えばＲＥＳＴ ＡＰＩ（REpresentational State Transfer Application Programming Interface）のＵＲＬ（Uniform Resource Locator）等である。

ＲＥＳＴ ＡＰＩとは、Ｗｅｂシステムを外部から利用するためのプログラムの呼び出し規約（ＡＰＩ）の種類の一つで、ＲＥＳＴと呼ばれる設計原則に従って策定されたものを示す。ＲＥＳＴ ＡＰＩのＵＲＬは、例えば対応するサービスＩＤで特定されるサービスを提供するためのリソースを表現している。

項目「端末ＩＤリスト」の値は、対応するサービスＩＤにより特定されるサービスの提供を受けるアプリケーションを有する端末装置３００の端末ＩＤのリストを示す。

図６の例では、例えばサービスＩＤ「１００１」であるサービスは、端末ＩＤ「００１」の端末装置３００と、端末ＩＤ「００２」の端末装置３００とにより利用されている。端末ＩＤ「００１」および端末ＩＤ「００２」の端末装置３００から、サービスＩＤ「１００１」のサービスへ接続したときに、サービスＩＤ「１００１」のサービスから、サーバ２００に対して、リソース解放要求を行うためのＵＲＬであるサービス通知先を含めてサービス利用情報を登録する。

この場合、サーバ２００は、例えば、端末ＩＤ「００１」の端末装置３００の接続状態がオフラインとなったときに、端末ＩＤ「００１」の利用しているサービスであるサービスＩＤ「１００１」とサービスＩＤ「１００２」について、それぞれ、ＵＲＬ「ｈｔｔｐ：／／ａａａ．ｂｂｂ」、ＵＲＬ「ｈｔｔｐ：／／ｃｃｃ．ｄｄｄ」へアクセスし、端末ＩＤ「００１」の使用しているリソースを解放する。

図７は、第一の実施形態の端末装置の接続状態テーブルの一例を示す図である。本実施形態の接続状態テーブル３２０は、端末装置３００の端末ＩＤに、サーバ２００と端末装置３００との接続状態を示す接続状態情報が対応付けられている。

図７の例では、端末ＩＤ「００１」の端末装置３００は、接続状態情報が「オンライン」であり、サーバ２００と接続された状態であることがわかる。接続状態テーブル３２０において、接続状態情報は、端末装置３００とサーバ２００との接続状態に応じてオンライン／オフラインが切り替えられる。

図８は、第一の実施形態のアプリ利用情報テーブルの一例を示す図である。本実施形態のアプリ利用情報テーブル３３０は、情報の項目として、アプリＩＤ、通知先、サービスＩＤリストを有し、項目「アプリＩＤ」と、その他の項目とが対応付けられている。以下の説明では、項目「アプリＩＤ」の値と、その他の項目の値とを含む情報をアプリ利用情報と呼ぶ。

項目「アプリＩＤ」の値は、端末装置３００にインストールされているアプリケーションを特定する識別子を示す。

項目「通知先」の値は、対応するアプリケーションに対する指示の仕方を示す。例えば、アプリＩＤで特定されるアプリケーションが、マークアップ言語の規格であるＨＴＭＬ５で記述されていた場合には、アプリケーションに対してコールバックにより指示が行われる。

また、例えば、アプリＩＤで特定されるアプリケーションが、Ｊａｖａ（登録商標）を搭載したＡｎｄｒｏｉｄアプリケーションである場合には、ｉｎｔｅｎｔ情報により、アプリケーションに対する指示が行われる。

尚、アプリケーションに対する指示とは、例えば端末側リソースの解放指示や、サービスに対してサービス利用要求を行わせる指示等である。

項目「サービスＩＤリスト」の値は、対応するアプリＩＤで特定されるアプリケーションにより利用されるサービスの識別子のリストを示す。

図８では、例えばアプリＩＤ「１１」は、サービスＩＤ「１００１」のサービスと、サービスＩＤ「１００２」のサービスとを利用していることがわかる。

次に、図９を参照し、本実施形態の情報処理システム１００の有するサーバ２００と端末装置３００について説明する。

図９は、第一の実施形態の情報処理システムの有する各装置の機能を説明する図である。始めに、サーバ２００の機能について説明する。

本実施形態のサーバ２００は、状態監視処理部２１０、接続状態保存データベース２２０、サービス利用情報データベース２３０、サービス２４０を有する。

状態監視処理部２１０は、サービス登録部２１１、サービス中継部２１２、サービス制御部２１３、サーバ状態同期部２１４を有する。

サーバ状態同期部２１４は、接続状態保存データベース２２０における接続状態情報を、端末装置３００における接続状態情報と同期させる。サーバ状態同期部２１４の処理の詳細は後述する。

サービス登録部２１１は、サービスが端末装置３００から利用される際に、サービス利用情報データベース２３０において、端末装置３００の端末ＩＤの登録を行う。

サービス中継部２１２は、後述する端末装置３００のアプリケーション３５０からサービス２４０に対してサービスの利用要求を受けて、この利用要求をサービス２４０へ渡す。サービス２４０は、アプリケーション３５０に対し、要求に応じた各種のサービスを提供する。

サービス制御部２１３は、サービス利用情報データベース２３０を参照し、サービス２４０に対する制御を行う。具体的には、サービス制御部２１３は、例えはサービス側リソースの解放指示を行う。

次に、端末装置３００の機能について説明する。本実施形態の端末装置３００は、状態監視処理部３１０、接続状態テーブル３２０、アプリ利用情報テーブル３３０、接続状態監視部３４０、アプリケーション３５０を有する。

本実施形態の状態監視処理部３１０は、アプリ登録部３１１、アプリ制御部３１２、端末状態同期部３１３を有する。

アプリ登録部３１１は、アプリ利用情報テーブル３３０に対してアプリケーション３５０の登録を行う。

アプリ制御部３１２は、アプリ利用情報テーブル３３０を参照し、アプリケーション３５０に対する制御を行う。具体的には、アプリ制御部３１２は、例えは端末側リソースの解放指示を行う。

端末状態同期部３１３は、接続状態監視部３４０に基づき、通信が可能かどうかを判断する。また、端末状態同期部３１３は、接続状態テーブル３２０における接続状態情報を、サーバ２００における接続状態情報と同期させる。端末状態同期部３１３の処理の詳細は後述する。

本実施形態の接続状態監視部３４０は、端末装置３００が通信可能な状態かどうかを監視し、通信可能になったときと不能になったときに、端末状態同期部３１３へ通知する。言い換えれば、接続状態監視部３４０は、端末装置３００とサーバ２００との通信が可能であるか否かを監視している。より具体的には、接続状態監視部３４０は、端末装置３００がアクセスポイント２０にアクセスし、ＩＰ（Internet Protocol）アドレスを取得したか否かを監視している。

アプリケーション３５０は、例えば端末装置３００の操作等に応じてサービス２４０に対するサービスの利用要求を行う。このとき、アプリケーション３５０は、サービスの利用要求に端末装置３００の端末ＩＤを付与するものとした。

次に、本実施形態のサーバ２００及び端末装置３００の処理について説明する。始めに、サーバ２００の状態監視処理部２１０の有する各部の処理について説明する。

図１０は、第一の実施形態のサーバのサービス登録部の処理を説明するフローチャートである。

本実施形態のサービス登録部２１１は、端末装置３００のアプリケーション３５０から利用要求を受けたサービス２４０から、項目「サービスＩＤ」、「サービス通知先」、「端末ＩＤリスト」を含むサービス利用情報を送信されて動作する。まず、サービスからのサービス利用情報を取得する（ステップＳ１００１）。尚、アプリケーション３５０が正常にサービス２４０の利用を終了する場合は、「端末ＩＤリスト」からサービス利用終了した端末ＩＤを削除したサービス利用情報が、サービス２４０よりサービス登録部２１１に送信される。サービス２４０を利用する端末３００が一台もなくなった場合は、「端末ＩＤリスト」が空のサービス利用情報がサービス２４０からサービス登録部２１１に送信される。

続いて、サービス登録部２１１は、取得したサービス利用情報における項目「端末ＩＤリスト」の値が空であるか否かを判定する（ステップＳ１００２）。

ステップＳ１００２において、該当する値が空であった場合、サービス登録部２１１は、サービス利用情報データベース２３０から、取得したサービス利用情報を削除し（ステップＳ１００３）、処理を終了する。本実施形態のサービス登録部２１１は、利用要求を受けたサービス２４０が終了する場合等にも端末リストＩＤの値を空としたサービス利用情報を登録することで、終了するサービスのサービス利用情報を削除している。

ステップＳ１００２において、該当する値が空でない場合、サービス登録部２１１は、サービス利用情報データベース２３０に、取得したサービス利用情報を保存し（ステップＳ１００４）、処理を終了する。

本実施形態のサービス登録部２１１は、以上のようにして、サービス利用情報データベース２３０にサービス利用情報を格納する。

次に、図１１を参照して本実施形態の状態監視処理部２１０のサービス中継部２１２の処理について説明する。図１１は、第一の実施形態のサーバのサービス中継部の処理を説明するフローチャートである。

本実施形態のサービス中継部２１２は、端末装置３００のアプリケーション３５０からのサービスの利用要求を受けて、利用要求に付与された端末装置３００の端末ＩＤを抽出する（ステップＳ１１０１）。続いてサービス中継部２１２は、接続状態保存データベース２２０を参照し、抽出した端末ＩＤと対応する接続状態情報を取得する（ステップＳ１１０２）。

続いてサービス中継部２１２は、取得した接続状態情報がオンラインであるか否かを判定する（ステップＳ１１０３）。ステップＳ１１０３において、接続状態情報がオンラインでない場合、サービス中継部２１２は、利用要求をサービス２４０へ中継せずに処理を終了する。

ステップＳ１１０３において、接続状態情報がオンラインである場合、サービス中継部２１２は、利用要求をサービス２４０へ中継し（ステップＳ１１０４）、処理を終了する。

このように、本実施形態では、サーバ２００において接続状態情報がオンラインとなっていない場合には、サービス中継部２１２はサービスの利用要求を中継しない。したがって、本実施形態によれば、サーバ２００においてサービス側リソースが解放された状態において、アプリケーション３５０からサービス２４０に対してサービスの利用要求が行われる、といった矛盾した動作の発生を回避できる。

次に、図１２を参照して本実施形態の状態監視処理部２１０のサービス制御部２１３の処理について説明する。図１２は、第一の実施形態のサーバのサービス制御部の処理を説明するフローチャートである。

本実施形態のサービス制御部２１３は、サーバ状態同期部２１４から端末ＩＤの通知を受けると、接続状態保存データベース２２０を参照し、通知された端末ＩＤの接続状態情報を取得する（ステップＳ１２０１）。続いて、サービス制御部２１３は、接続状態情報がオフラインであるか否かを判定する（ステップＳ１２０２）。

ステップＳ１２０２において、オフラインでない場合、つまり接続状態情報がオンラインであった場合、サービス制御部２１３は処理を終了する。

ステップＳ１２０２において、オフラインであった場合、サービス制御部２１３は、サービス利用情報データベース２３０を参照し、通知された端末ＩＤと対応するサービスＩＤとサービス通知先を抽出する（ステップＳ１２０３）。続いてサービス制御部２１３は、抽出したサービスＩＤにより特定されるサービスに対し、リソースの解放を通知し（ステップＳ１２０４）、処理を終了する。

以上のように、本実施形態のサービス制御部２１３は、通知された端末ＩＤの接続状態情報がオフラインであった場合に、端末ＩＤと対応するサービス２４０に、サービス側リソースを解放させる。

次に、図１３を参照して本実施形態の状態監視処理部２１０のサーバ状態同期部２１４の処理について説明する。図１３は、第一の実施形態のサーバのサーバ状態同期部の処理を説明する第一のフローチャートである。尚、図１３の処理は、所定間隔毎に繰り返し行われる。ここでの所定間隔は、接続状態保存データベース２２０におけるオフライン判定時間よりも短い間隔である。

本実施形態のサーバ状態同期部２１４は、端末装置３００の端末状態同期部３１３から通知を受けたか否かを判定する（ステップＳ１３０１）。言い換えれば、サーバ状態同期部２１４は、端末状態同期部３１３から接続状態情報を受けたか否かを判定する。

ステップＳ１３０１において、通知を受けない場合、サーバ状態同期部２１４は後述するステップＳ１３１１へ進む。

ステップＳ１３０１において、通知を受けた場合、サーバ状態同期部２１４は、通知（接続状態情報）がオンラインであるか否かを判定する（ステップＳ１３０２）。尚、サーバ状態同期部２１４は、通知と共に、通知を行った端末装置３００の端末ＩＤを受け取る。

ステップＳ１３０２において、オンラインでない場合、つまり接続状態情報がオフラインである場合、サーバ状態同期部２１４は後述するステップＳ１３０６へ進む。

ステップＳ１３０２において、オンラインであった場合、サーバ状態同期部２１４は、接続状態保存データベース２２０より、接続状態情報と共に受け取った端末ＩＤと対応する接続状態情報を取得する（ステップＳ１３０３）。

続いて、サーバ状態同期部２１４は、端末装置３００に対し、ステップＳ１３０３で取得した接続状態情報を返す（ステップＳ１３０４）。次に、サーバ状態同期部２１４は、接続状態保存データベース２２０において、受け取った端末ＩＤと対応するオフライン判定時間をリセットし（ステップＳ１３０５）、処理を終了する。言い換えれば、サーバ状態同期部２１４は、ステップＳ１３０５において、端末装置３００と対応する端末ＩＤのオフライン判定時間を初期値に戻し、処理を終了する。

ステップＳ１３０２において、接続状態情報がオンラインでない場合、つまりオフラインの場合、サーバ状態同期部２１４は、接続状態保存データベース２２０より、接続状態情報と共に受け取った端末ＩＤと対応する接続状態情報を取得する（ステップＳ１３０６）。

続いてサーバ状態同期部２１４は、ステップＳ１３０６で取得した接続状態情報がオンラインであるか否かを判定する（ステップＳ１３０７）。

ステップＳ１３０７において、オンラインでない場合、つまりオフラインである場合、サーバ状態同期部２１４は、接続状態保存データベース２２０における端末ＩＤの接続状態情報を、オフラインからオンラインに変更し（ステップＳ１３０８）、ステップＳ１３０３へ進む。

ステップＳ１３０７において、オンラインである場合、サーバ状態同期部２１４は、接続状態保存データベース２２０における端末ＩＤの接続状態情報を、オンラインからオフラインに変更する（ステップＳ１３０９）。続いてサーバ状態同期部２１４は、サービス制御部２１３に対して端末ＩＤを通知し（ステップＳ１３１０）、ステップＳ１３０８へ進む。尚、ここでは、サービス制御部２１３には、接続状態保存データベース２２０の接続状態情報がオフラインとされた端末ＩＤが通知される。よって、サービス制御部２１３は、サービス利用情報データベース２３０において、この端末ＩＤと対応するサービスＩＤで特定されるサービスに対し、サービス側リソースの解放指示を行うことになる（図１２参照）。

ステップＳ１３０１において、端末状態同期部３１３から接続状態情報を受信しない場合、サーバ状態同期部２１４は、処理１を実行し（ステップＳ１３１１）、処理を終了する。

以下に、図１４を参照して、状態監視処理部２１０のサーバ状態同期部２１４による処理１について説明する。図１４は、第一の実施形態のサーバのサーバ状態同期部の処理を説明する第二のフローチャートである。

本実施形態のサーバ状態同期部２１４は、ステップＳ１３０１において、接続状態情報が通知されない場合、接続状態保存データベース２２０に格納された全ての端末ＩＤと対応するオフライン判定時間に対して減算を開始する（ステップＳ１４０１）。続いて、サーバ状態同期部２１４は、オフライン判定時間が経過した端末ＩＤが存在するか否かを判定する（ステップＳ１４０２）。言い換えれば、サーバ状態同期部２１４は、オフライン判定時間の減算の結果により、オフライン判定時間が０以下となり、サーバ２００との通信が切断していると判定される端末ＩＤが存在するか否かを判定する。

ステップＳ１４０２において、該当する端末ＩＤが存在しない場合、サーバ状態同期部２１４は、処理を終了する。

ステップＳ１４０２において、該当する端末ＩＤが存在する場合、サーバ状態同期部２１４は、接続状態保存データベース２２０より、該当する端末ＩＤの接続状態情報を取得する（ステップＳ１４０３）。続いてサーバ状態同期部２１４は、取得した接続状態情報がオンラインであるか否かを判定する（ステップＳ１４０４）。

ステップＳ１４０４において、オンラインでない場合、つまりオフラインであった場合、サーバ状態同期部２１４は、後述するステップＳ１４０７へ進む。

ステップＳ１４０４において、オンラインであった場合、サーバ状態同期部２１４は、接続状態保存データベース２２０における該当する端末ＩＤの接続状態情報をオンラインからオフラインに変更する（ステップＳ１４０５）。続いてサーバ状態同期部２１４は、サービス制御部２１３に該当する端末ＩＤを通知し（ステップＳ１４０６）、ステップＳ１４０７へ進む。

尚、ステップＳ１４０６において端末ＩＤの通知を受けたサービス制御部２１３は、図１２のステップＳ１２０３以降の処理を行い、端末ＩＤが利用しているサービスに対してサービス側リソースを解放させる。

ステップＳ１４０４において、オフラインであった場合、サーバ状態同期部２１４は、オフライン判定時間が経過した端末ＩＤ全てについて、ステップＳ１４０３以降の処理を行ったか否かを判定する（ステップＳ１４０７）。つまり、サーバ状態同期部２１４は、サーバ２００と通信が切断された端末装置３００について、この端末装置３００が利用しているサービスのサービス側リソースを解放させたか否かを判定している。

ステップＳ１４０７において、全ての端末ＩＤにおいて処理を行っていない場合、サーバ状態同期部２１４は、オフライン判定時間が経過した次の端末ＩＤを取得し（ステップＳ１４０８）、ステップＳ１４０３へ戻る。

ステップＳ１４０７において、オフライン判定時間が経過した全ての端末ＩＤについて、ステップＳ１４０３以降の処理を行った場合、サーバ状態同期部２１４は、処理を終了する。

以上が、本実施形態のサーバ２００の状態監視処理部２１０の有する各部の処理である。

次に、本実施形態の端末装置３００の状態監視処理部３１０の有する各部の処理について説明する。

図１５は、第一の実施形態の端末装置のアプリ登録部の処理を説明するフローチャートである。

本実施形態の端末装置３００の状態監視処理部３１０の有するアプリ登録部３１１は、アプリケーション３５０より、サービス利用可能時と利用不可能時の通知をするためのアプリ利用情報の登録や削除を依頼され、アプリ利用情報の管理を行う。アプリ登録部３１１は、アプリケーション３５０からの依頼を受け、依頼がアプリ利用情報の登録か否かを判定する（ステップＳ１５０１）。アプリケーション３５０は、利用する全てのサービスに対するアプリ利用情報を動作開始時に登録し、アプリ終了時に削除してもよいし、サービスを利用するときに、そのサービスに対するアプリ利用情報を登録し、サービスを利用しなくなったときに、そのサービスに対するアプリ利用情報を削除してもよい。

ステップＳ１５０１において、アプリ利用情報の登録を行う場合、アプリ登録部３１１は、アプリケーション３５０からのアプリ利用情報をアプリ利用情報テーブル３３０へ保存し（ステップＳ１５０２）、処理を終了する。アプリ利用情報は、項目「アプリＩＤ」、「通知先」、「サービスＩＤリスト」を含む情報である。

ステップＳ１５０１において、アプリ利用情報の登録ではない場合、つまりアプリ利用情報の削除の場合、アプリ登録部３１１は、アプリ利用情報テーブル３３０から、アプリＩＤを含むアプリ利用情報を削除し（ステップＳ１５０３）、処理を終了する。

本実施形態では、以上のアプリ登録部３１１の処理により、アプリ利用情報テーブル３３０には、起動しているアプリケーションにより利用されるサービスのサービスＩＤが格納されるようになる。

次に、図１６を参照して本実施形態の端末装置３００の状態監視処理部３１０の有するアプリ制御部３１２の処理について説明する。図１６は、第一の実施形態の端末装置のアプリ制御部の処理を説明するフローチャートである。

本実施形態のアプリ制御部３１２は、端末状態同期部３１３から通知された接続状態情報がオンラインか否かを判定する（ステップＳ１６０１）。ステップＳ１６０１において、オンラインである場合、アプリ制御部３１２は、アプリ利用情報テーブル３３０に含まれる全てのアプリＩＤが特定するアプリケーション３５０に対し、各アプリＩＤと対応する通知先が示す方法により、オンライン通知を行い（ステップＳ１６０２）、処理を終了する。

このとき、アプリ制御部３１２は、各アプリＩＤが特定するアプリケーション３５０に対し、各アプリＩＤと対応するサービスＩＤリストを付与して、オンライン通知を行う。言い換えれば、アプリ制御部３１２は、アプリＩＤにより特定されるアプリケーション３５０に対し、サービスＩＤリストに含まれるサービスＩＤが特定するサービスの利用開始を指示する。

ステップＳ１６０１において、オンラインでない場合、サービス制御部２１３は、アプリ利用情報テーブル３３０に含まれる全てのアプリＩＤが特定するアプリケーション３５０に対し、各アプリＩＤと対応する通知先が示す方法により、端末側リソースの解放指示を行い（ステップＳ１６０３）、処理を終了する。

このとき、アプリ制御部３１２は、各アプリＩＤが特定するアプリケーション３５０に対し、各アプリＩＤと対応するサービスＩＤリストを付与して、端末側リソースの解放指示を行う。言い換えれば、アプリ制御部３１２は、アプリＩＤにより特定されるアプリケーション３５０に対し、サービスＩＤリストに含まれるサービスＩＤが特定するサービスのために使用していた端末側リソースの解放を指示する。

次に、図１７を参照して本実施形態の端末装置３００の有する状態監視処理部３１０の端末状態同期部３１３の処理について説明する。図１７は、第一の実施形態の端末装置の有する端末状態同期部の処理を説明するフローチャートである。

本実施形態の端末状態同期部３１３は、接続状態監視部３４０から、端末装置３００とサーバ２００との通信の状態を示す通知を受けたか否かを判定する（ステップＳ１７０１）。

ステップＳ１７０１において、通知を受けていない場合、端末状態同期部３１３は後述するステップＳ１７１３へ進む。

ステップＳ１７０１において、通知を受けた場合、端末状態同期部３１３は、通知が接続の開始を示す通知であるか否かを判定する（ステップＳ１７０２）。接続の開始を示す通知とは、例えば、端末装置３００がアクセスポイント２０からＩＰアドレスを取得したことを示す通知である。

ステップＳ１７０２において、通知が接続の開始を示すものでない場合、つまり、通知が接続の終了を示すものである場合、端末状態同期部３１３は、端末装置３００の有するタイマ機能において、タイマを設定し（ステップＳ１７０３）、処理を終了する。ここでタイマに設定される期間は、接続状態保存データベース２２０におけるオフライン判定時間と一致する期間である。ステップＳ１７０３でタイマに設定される期間は、端末装置３００が、端末装置３００とサーバ２００との通信が切断されたと判定するための期間である。

ステップＳ１７０２において、通知が接続の開始を示すものである場合、端末状態同期部３１３は、タイマの設定を解除する（ステップＳ１７０４）。

続いて端末状態同期部３１３は、接続状態テーブル３２０により、端末装置３００の接続状態情報を取得する（ステップＳ１７０５）。続いて端末状態同期部３１３は、サーバ２００のサーバ状態同期部２１４に、ステップＳ１７０５で取得した接続状態情報を送信し、サーバ状態同期部２１４から返答を受ける（ステップＳ１７０６）。

続いて端末状態同期部３１３は、サーバ状態同期部２１４から、返答として受けた接続状態情報がオフラインであるか否かを判定する（ステップＳ１７０７）。

ステップＳ１７０７においてオフラインでない場合、つまり、オンラインであった場合、端末状態同期部３１３は後述するステップＳ１７１０へ進む。

ステップＳ１７０７において、オフラインであった場合、端末状態同期部３１３は、接続状態テーブル３２０の接続状態情報をオフラインとする（ステップＳ１７０８）。続いて、端末状態同期部３１３は、アプリ制御部３１２に対し、オフラインの接続状態情報を通知し（ステップＳ１７０９）、ステップＳ１７０５へ戻る。尚、このとき、アプリ制御部３１２は、オフラインの通知を受けて、アプリケーション３５０に対して、アプリケーション３５０がサービスを利用するために使用していた端末側リソースの解放指示を行う。

ステップＳ１７０７において、オンラインであった場合、端末状態同期部３１３は、ステップＳ１７０５で接続状態テーブル３２０から取得した接続状態情報が、オフラインであるか否かを判定する（ステップＳ１７１０）。

ステップＳ１７１０において、接続状態情報がオフラインでない場合、つまりオフラインであった場合、端末状態同期部３１３は、処理を終了する。

ステップＳ１７１０において、接続状態情報がオフラインであった場合、端末状態同期部３１３は、接続状態テーブル３２０の接続状態情報をオフラインからオンラインへ変更する（ステップＳ１７１１）。続いて端末状態同期部３１３は、アプリ制御部３１２に対し、オンラインの接続状態情報を通知し（ステップＳ１７１２）、処理を終了する。尚、このとき、アプリ制御部３１２は、オンラインの通知を受けて、アプリケーション３５０に対して、サービスの利用開始を指示する。またアプリケーション３５０は、アプリ制御部３１２からオンラインの通知を受けて、サービス２４０に対する利用要求（アクセス）を行う。

このように、本実施形態では、サーバ２００における接続状態保存データベース２２０の接続状態情報と、端末装置３００の接続状態テーブル３２０とがオンラインで同期した状態において、アプリ制御部３１２に対してオンラインを通知する。

言い換えれば、本実施形態では、端末装置３００において接続の開始が通知されてから、サーバ２００側の接続状態情報がオンラインとなるまで、端末装置３００の接続状態情報をオンラインとせず、アプリ制御部３１２に対するオンラインの通知を遅延させる。

したがって、本実施形態によれば、サービス側リソースが解放された状態でアプリケーション３５０がサービス２４０にアクセスすることを抑制できる。

ステップＳ１７０１において、通知を受けていない場合、端末状態同期部３１３は、所定時間が経過したか否かを判定する（ステップＳ１７１３）。ステップＳ１７１３における所定時間とは、タイマに設定された時間である。よって、言い換えれば、ステップＳ１７１３において、端末状態同期部３１３は、オフライン判定時間が経過したか否かを判定している。

ステップＳ１７１３において、所定時間が経過していない場合、端末状態同期部３１３はステップＳ１７０１へ戻る。

ステップＳ１７１３において、所定時間が経過した場合、端末状態同期部３１３は、接続状態テーブル３２０から接続状態情報を取得する（ステップＳ１７１４）。続いて、端末状態同期部３１３は、取得した接続状態情報がオンラインか否かを判定する（ステップＳ１７１５）。

ステップＳ１７１５において、接続状態情報がオンラインでない場合、つまりオフラインの場合、端末状態同期部３１３は処理を終了する。

ステップＳ１７１５において、接続状態情報がオンラインである場合、端末状態同期部３１３は、接続状態テーブル３２０の接続状態情報をオンラインからオフラインへ変更する（ステップＳ１７１６）。続いて端末状態同期部３１３は、アプリ制御部３１２に対し、オフラインの接続状態情報を通知し（ステップＳ１７１７）、処理を終了する。尚、このとき、アプリ制御部３１２は、オフラインの通知を受けて、アプリケーション３５０に対して、サービスを利用するために使用している端末側リソースの解放指示を行う。

本実施形態では、以上に説明したサーバ２００と端末装置３００の処理により、図２（Ａ）、（Ｂ）及び図３（Ａ）、（Ｂ）、（Ｃ）に示す各動作を実現する。

したがって、本実施形態によれば、リソース確認処理による負荷の増大を抑制できる。また、本実施形態のサービス中継部２１２は、サーバ２００と端末装置３００において、それぞれの接続状態情報がオンラインで同期していない場合には、アプリケーション３５０からのサービスの利用要求を受けてもサービス２４０へ利用要求を通知しない。したがって、本実施形態によれば、サーバ２００においてサービス側リソースが確保されていない状態で、アプリケーション３５０から利用要求が通知されることにより生じる誤動作等の発生を抑制できる。

（第二の実施形態）
以下に図面を参照して第二の実施形態について説明する。第二の実施形態では、アプリケーションからサービスへの利用要求が中継されない場合に、サービスの利用不可の通知を行う点が第一の実施形態と相違する。よって、以下の第二の実施形態の説明では、第一の実施形態との相違点についてのみ説明し、第一の実施形態と同様の機能構成を有するものには、第一の実施形態の説明で用いた符号と同様の符号を付与し、その説明を省略する。

図１８は、第二の実施形態の情報処理システムの有する各装置の機能を説明する図である。

本実施形態の情報処理システム１００Ａは、サーバ２００Ａと端末装置３００Ａとを有する
本実施形態のサーバ２００Ａは、状態監視処理部２１０Ａと、接続状態保存データベース２２０Ａと、サービス利用情報データベース２３０Ａとを有する。

本実施形態の接続状態保存データベース２２０Ａと、サービス利用情報データベース２３０Ａには、サービス２４０が利用可能であるか否かを示す情報が格納される。接続状態保存データベース２２０Ａと、サービス利用情報データベース２３０Ａの詳細は後述する。

本実施形態の状態監視処理部２１０Ａは、サービス登録部２１１Ａ、サービス中継部２１２Ａ、サービス制御部２１３、サーバ状態同期部２１４Ａ、を有する。

サービス登録部２１１Ａは、サービス利用情報データベース２３０Ａにおけるサービス２４０の利用の可否を示す情報を登録する。

サービス中継部２１２Ａは、サービス２４０の利用が不可能であるとき、サービス２４０が利用不可であることを示す通知を端末装置３００Ａに送信する。以下の説明では、サービス２４０が利用不可であることを示す通知を、サービス利用不可通知と呼ぶ。

サーバ状態同期部２１４Ａは、サービス利用不可通知に基づき、接続状態保存データベース２２０Ａの情報を更新する。

本実施形態の端末装置３００Ａは、状態監視処理部３１０Ａと、接続状態テーブル３２０と、アプリ利用情報テーブル３３０Ａと、を有する。

本実施形態のアプリ利用情報テーブル３３０Ａには、サービス２４０が利用可能であるか否かを示す情報が格納される。アプリ利用情報テーブル３３０Ａの詳細は後述する。

本実施形態の状態監視処理部３１０Ａは、アプリ登録部３１１、アプリ制御部３１２Ａ、端末状態同期部３１３Ａを有する。

アプリ制御部３１２Ａは、端末状態同期部３１３Ａがサーバ２００Ａからサービス利用不可通知を受けたとき、アプリケーション３５０によるサービス利用不可とされたサービスの利用を不可とし、アプリ利用情報テーブル３３０Ａの情報を更新する。

本実施形態の端末状態同期部３１３Ａは、サーバ２００Ａから、利用不可サービスＩＤリストを受け付けると、アプリ制御部３１２Ａに利用不可サービスＩＤリストを渡す。

次に、図１９と図２０を参照し、本実施形態のサーバ２００Ａの有する各データベースについて説明する。

図１９は、第二の実施形態の接続状態保存データベースの一例を示す図である。本実施形態の接続状態保存データベース２２０Ａは、情報の項目として、端末ＩＤ、接続状態、オフライン判定時間、利用不可サービスＩＤリストを有する。

項目「利用不可サービスＩＤリスト」の値は、対応付けられた端末ＩＤで特定される端末装置３００Ａが利用することができないサービス２４０を特定する識別子を示す。

図１９の例では、端末ＩＤ「００１」の端末装置３００Ａは、サービスＩＤ「１００１」、「１００２」のサービス２４０を利用することができないことがわかる。

図２０は、第二の実施形態のサービス利用情報データベースの一例を示す図である。本実施形態のサービス利用情報データベース２３０Ａは、情報の項目として、サービスＩＤ、サービス通知先、サービス状態、端末ＩＤリストを有する。

項目「サービス状態」の値は、対応付けられたサービスＩＤで特定されるサービス２４０の利用の可否を示す。尚、本実施形態では、サービス登録部２１１Ａが、項目「サービス状態」の値が利用不可であるサービス２４０から、利用が可能となったことを示す通知を受けたとき、項目「サービス状態」の値が利用不可から利用可能へ更新される。

図２０の例では、サービスＩＤ「１００１」のサービス２４０は利用不可であり、このサービス２４０を利用する端末装置３００Ａは、端末ＩＤ「００１」、「００２」の端末装置３００Ａであることがわかる。

次に、図２１を参照し、本実施形態の端末装置３００Ａの有するアプリ利用情報テーブル３３０Ａについて説明する。

図２１は、第二の実施形態のアプリ利用情報テーブルの一例を示す図である。本実施形態のアプリ利用情報テーブル３３０Ａは、情報の項目として、アプリＩＤ、通知先、サービスＩＤリスト／サービス状態を有する。

項目「サービスＩＤリスト／サービス状態」の値は、アプリＩＤにより利用されるサービス２４０のサービスＩＤと、このサービスＩＤが特定するサービス２４０の利用可否と、を示す。

図２１の例では、アプリＩＤ「１１」は、サービスＩＤ「１００１」のサービス２４０と、サービスＩＤ「１００２」のサービス２４０を利用し、サービスＩＤ「１００１」、「１００２」が特定するサービス２４０は両方とも利用不可であることがわかる。

次に、本実施形態のサーバ２００Ａと端末装置３００Ａの動作について説明する。図２２は、第二の実施形態のサーバのサービス登録部の処理を説明するフローチャートである。

図２２のステップＳ２２０１からステップＳ２２０４までの処理は、図１０のステップＳ１００１からステップＳ１００４までの処理と同様であるから、説明を省略する。

ステップＳ２２０３、２２０４に続いて、サービス登録部２１１Ａは、接続状態保存データベース２２０Ａにおいて、対象のサービスＩＤを、すべての端末ＩＤの接続状態情報の利用不可サービスＩＤリストから削除し（ステップＳ２２０５）、処理を終了する。

次に、本実施形態のサーバ２００Ａの状態監視処理部２１０Ａの有するサービス中継部２１２Ａの処理について説明する。

図２３は、第二の実施形態のサーバのサービス中継部の処理を説明するフローチャートである。

図２３のステップＳ２３０１からステップＳ２３０３までの処理は、図１１のステップＳ１１０１からステップＳ１１０３までの処理と同様であるから、説明を省略する。

ステップＳ２３０３において、接続状態情報がオンラインでない場合、サービス中継部２１２Ａは、利用要求をサービス２４０へ中継せずに処理を終了する。

ステップＳ２３０３において、接続状態情報がオンラインである場合、サービス中継部２１２Ａは、サービス利用情報データベース２３０Ａにおいて、利用要求を受けたサービスＩＤのサービス状態を取得する（ステップＳ２３０４）。

続いてサービス中継部２１２Ａは、サービス状態が利用可であるか否かを判定する（ステップＳ２３０５）。ステップＳ２３０５において、サービス状態が利用可でない場合、つまり、サービス状態が利用不可である場合、サービス中継部２１２Ａは、サービスの利用要求を中継せずに処理を終了する。

ステップＳ２３０５において、サービス状態が利用可である場合、サービス中継部２１２Ａは、サービスの利用要求をサービス２４０へ中継する（ステップＳ２３０６）。

続いてサービス中継部２１２Ａは、サービス２４０に対する中継が成功したか否かを判定する（ステップＳ２３０７）。ステップＳ２３０７において、中継が成功した場合、サービス中継部２１２Ａは、処理を終了する。

ステップＳ２３０７において、中継が失敗した場合、サービス中継部２１２Ａは、サービス利用情報データベース２３０Ａにおいて、中継に失敗したサービスのサービスＩＤのサービス状態を利用不可とする（ステップＳ２３０８）。

続いてサービス中継部２１２Ａは、サービスＩＤのサービス利用情報の端末ＩＤリストの端末ＩＤに対して、接続状態保存データベース２２０Ａにおいて、対応する利用不可サービスＩＤリストに、中継に失敗したサービスのサービスＩＤを追加し（ステップＳ２３０９）、処理を終了する。

次に、本実施形態のサーバ２００Ａの状態監視処理部２１０Ａの有するサーバ状態同期部２１４Ａの処理について説明する。

図２４は、第二の実施形態のサーバのサーバ状態同期部の処理を説明するフローチャートである。

図２４のステップＳ２４０１とステップＳ２４０２の処理は、図１３のステップＳ１３０１とステップＳ１３０２の処理と同様であるから、説明を省略する。

ステップＳ２４０２において、オンラインであった場合、サーバ状態同期部２１４Ａは、接続状態保存データベース２２０Ａより、接続状態情報と共に受け取った端末ＩＤと対応する接続状態情報と、利用不可サービスＩＤリストとを取得する（ステップＳ２４０３）。

続いて、サーバ状態同期部２１４Ａは、端末装置３００Ａに対し、ステップＳ２４０３で取得した接続状態情報と、利用不可サービスＩＤリストとを返す（ステップＳ２４０４）。

図２４のステップＳ２４０５からステップＳ２４１１までの処理は、図１３のステップＳ１３０５とステップＳ１３１１までの処理と同様であるから、説明を省略する。

次に、本実施形態の端末装置３００Ａの状態監視処理部３１０Ａの有するアプリ制御部３１２Ａの処理について説明する。

図２５は、第二の実施形態のサーバのアプリ制御部の処理を説明するフローチャートである。

本実施形態のアプリ制御部３１２Ａは、端末状態同期部３１３Ａから受けた通知の種別を示す情報を取得する（ステップＳ２５０１）。続いて、アプリ制御部３１２Ａは、種別を示す情報に基づき、通知の内容が利用不可サービスＩＤリストであるか否かを判定する（ステップＳ２５０２）。

ステップＳ２５０２において、通知が利用不可サービスＩＤリストでない場合、アプリ制御部３１２Ａは、後述するステップＳ２５０５へ進む。

ステップＳ２５０２において、通知が利用不可サービスＩＤリストであった場合、アプリ制御部３１２Ａは、アプリケーション３５０に対し、利用不可サービスＩＤリストに含まれるサービスＩＤが特定するサービスのサービス利用不可を通知する。そして、アプリ制御部３１２Ａは、利用不可とされたサービス以外のサービスを利用可能とし、アプリケーション３５０に対してサービス利用可を通知する（ステップＳ２５０３）。

尚、本実施形態では、アプリケーション３５０への通知を何度も行わないようにするために、通知された利用不可サービスリストに含まれるサービスＩＤが、アプリ利用情報テーブルのサービス状態にて可となっている場合に、サービス利用不可通知を行い、通知された利用不可サービスリストに含まれないサービスＩＤが、アプリ利用情報テーブルのサービス状態にて不可となっている場合に、サービス利用可通知を行ってもよい。

続いて、アプリ制御部３１２Ａは、アプリ利用情報テーブル３３０Ａにおいて、全てのアプリＩＤと対応するサービスＩＤリスト／サービス状態を更新し（ステップＳ２５０４）、処理を終了する。

図２５のステップＳ２５０５からステップＳ２５０７までの処理は、図１６のステップＳ１６０１からステップＳ１６０３までの処理と同様であるから、説明を省略する。

次に、図２６を参照し、本実施形態の端末装置３００Ａの状態監視処理部３１０Ａの有する端末状態同期部３１３Ａの処理について説明する。

図２６は、第二の実施形態の端末装置の端末状態同期部の処理を説明するフローチャートである。

図２６のステップＳ２６０１からステップＳ２６０６までの処理は、図１７のステップＳ１７０１からステップＳ１７０６までの処理と同様であるから、説明を省略する。

ステップＳ２６０６に続いて、端末状態同期部３１３Ａは、サーバ２００Ａからの返答に含まれる利用不可サービスＩＤリストが存在するか否かを判定する（ステップＳ２６０７）。言い換えれば、端末状態同期部３１３Ａは、サーバ２００Ａからの返答に含まれる利用不可サービスＩＤリストにサービスＩＤが存在するか否かを判定している。

ステップＳ２６０７において、利用不可サービスＩＤリストが存在しない場合、端末状態同期部３１３Ａは、後述するステップＳ２６０９へ進む。

ステップＳ２６０７において、利用不可サービスＩＤリストが存在している場合、端末状態同期部３１３Ａは、アプリ制御部３１２Ａに対して利用不可サービスＩＤリストに含まれるサービスＩＤを通知し（ステップＳ２６０８）、後述するステップＳ２６０９へ進む。

図２６のステップＳ２６０９からステップＳ２６１９までの処理は、図１７のステップＳ１７０７からステップＳ１７１７までの処理と同様であるから、説明を省略する。

以上のように、本実施形態によれば、サーバ２００Ａにおける接続状態情報と、端末装置３００Ａにおける接続状態情報との同期に合わせて、サービス２４０の利用が可能か否かを示す情報をアプリケーション３５０に通知できる。

（第三の実施形態）
以下に図面を参照して第三の実施形態について説明する。第三の実施形態では、サーバが端末装置に対して状態監視処理部を実現する状態監視アプリケーションを配信する点のみ、第一の実施形態と相違する。よって、以下の第三の実施形態の説明では、第一の実施形態と同様の機能構成を有するものには、第一の実施形態の説明で用いた符号と同様の符号を付与し、その説明を省略する。

図２７は、第三の実施形態の情報処理システムのシステム構成の一例を示す図である。本実施形態の情報処理システム１００Ｂは、サーバ２００Ｂと端末装置３００とを有する。

本実施形態のサーバ２００Ｂは、状態監視処理部２１０、接続状態保存データベース２２０、サービス利用情報データベース２３０、アプリ配信処理部２５０を有する。

本実施形態のアプリ配信処理部２５０は、例えは端末装置３００からアプリケーションの配信要求を受け付けると、状態監視アプリケーション３１０Ｂを端末装置３００に配信する。

状態監視アプリケーション３１０Ｂは、状態監視処理部３１０を実現するアプリケーションである。尚、状態監視アプリケーション３１０Ｂは、サービス２４０を利用するアプリケーション３５０を含むアプリケーションであっても良い。

本実施形態では、例えば情報処理システム１００Ｂを用いて会議等が開催される場合に、会議の開催前に参加者の端末装置３００にサーバ２００Ｂから状態監視アプリケーション３１０Ｂを配信すれば、会議において情報処理システム１００Ｂの利用が可能となる。

開示の技術では、以下に記載する付記のような形態が考えられる。
（付記１）
サーバと端末装置とを有する情報処理システムであって、
前記サーバは、
前記サーバにおける前記サーバと前記端末装置との接続の状態を示す第一の接続状態を管理するサーバ側状態監視処理部と、
前記第一の接続状態と、前記端末装置において管理される第二の接続状態と、を同期させた結果に基づいて、前記サーバにより確保されたサーバ側リソースの解放又は再利用を行うサーバ側制御部と、を有し、
前記端末装置は、
前記端末装置における前記サーバと前記端末装置との接続の状態を示す前記第二の接続状態を管理する端末側状態監視処理部と、
前記第二の接続状態と、前記第一の接続状態と、を同期させた結果に基づいて、前記端末装置により確保された端末側リソースの解放又は再利用を行う端末側制御部と、を有する、情報処理システム。
（付記２）
前記第一の接続状態と、前記第二の接続状態と、が同期していないとき、
前記サーバ側状態監視処理部と、前記端末側状態監視処理部と、は、
前記第一の接続状態と前記第二の接続状態とを、前記サーバと前記端末装置との接続が切断された状態で各々切断を判断させた後に、前記サーバと前記端末装置とが接続された状態で同期させる、付記１記載の情報処理システム。
（付記３）
前記端末側状態監視処理部は、
前記端末装置と前記サーバとの接続が切断されてから所定時間経過した後に、前記第二の接続状態を、前記接続された状態から前記接続が切断された状態とする、付記１又は２記載の情報処理システム。
（付記４）
前記サーバ側制御部は、
前記第一の接続状態が、前記接続が切断された状態となったとき、前記サーバ側リソースの解放を行い、
前記端末側制御部は、
前記第二の接続状態が、前記接続が切断された状態となったとき、前記端末側リソースの解放を行い、前第二の接続状態が、前記接続された状態となったとき、前記端末側リソースを確保する、付記２又は３記載の情報処理システム。
（付記５）
前記端末側状態監視処理部は、
前記端末装置と前記サーバとが接続された場合、
前記サーバにおいて、前記第一の接続状態が、前記接続された状態とされたことを示す通知を受けてから、前記第二の接続状態を、前記接続された状態とする、付記２乃至４の何れか一項に記載の情報処理システム。
（付記６）
前記サーバは、
前記端末装置から、前記サーバが提供するサービスの利用要求を受けて、前記利用要求を前記サービスへ中継するサービス中継部を有し、
前記サービス中継部は、
前記第一の接続状態が、前記接続された状態である場合に、前記利用要求を前記サービスへ中継し、
前記第一の接続状態が、前記接続が切断された状態である場合に、前記利用要求を前記サービスへ中継しない、付記２乃至５の何れか一項に記載の情報処理システム。
（付記７）
前記サービス中継部は、
前記サービス中継部による前記利用要求の中継に失敗した場合に、
前記利用要求を行った前記端末装置に対し、前記サービスの利用が不可能であることを通知する、付記６記載の情報処理システム。
（付記８）
端末装置と通信を行うサーバであって、
前記サーバと前記端末装置との接続の状態を示す、第一の接続状態を管理する状態監視処理部と、
前記第一の接続状態と、前記端末装置において管理される、前記サーバと前記端末装置との接続の状態を示す第二の接続状態と、を同期させた結果に基づいて、前記サーバにおいて確保されたリソースの解放又は再利用を行う制御部と、を有するサーバ。
（付記９）
サーバと通信を行う端末装置であって、
前記サーバと前記端末装置との接続の状態を示す、第二の接続状態を管理する状態監視処理部と、
前記第二の接続状態と、前記サーバにおいて管理される、前記サーバと前記端末装置との接続の状態を示す第一の接続状態と、を同期させた結果に基づいて、前記端末装置において確保されたリソースの解放又は再利用を行う制御部と、を有する端末装置。
（付記１０）
サーバと端末装置との接続の状態を示す第一の接続状態を管理し、
前記第一の接続状態と、前記端末装置において管理される、前記サーバと前記端末装置との接続の状態を示す第二の接続状態と、を同期させた結果に基づいて、前記サーバにおいて確保されたリソースの解放又は再利用を行う、処理を前記サーバに実行させる情報処理プログラム。
（付記１１）
サーバと端末装置との接続の状態を示す第二の接続状態を管理し、
前記第二の接続状態と、前記サーバにおいて管理される、前記サーバと前記端末装置との接続の状態を示す第一の接続状態と、を同期させた結果に基づいて、前記端末装置において確保されたリソースの解放又は再利用を行う、処理を前記端末装置に実行させる情報処理プログラム。
（付記１２）
サーバと端末装置とを有する情報処理システムによる情報処理方法であって、
前記サーバが、
前記サーバにおける前記サーバと前記端末装置との接続の状態を示す第一の接続状態を管理し、
前記第一の接続状態と、前記端末装置において管理される第二の接続状態と、を同期させた結果に基づいて、前記サーバにより確保されたサーバ側リソースの解放又は再利用を行い、
前記端末装置が、
前記端末装置における前記サーバと前記端末装置との接続の状態を示す前記第二の接続状態を管理し、
前記第二の接続状態と、前記第一の接続状態と、を同期させた結果に基づいて、前記端末装置により確保された端末側リソースの解放又は再利用を行う情報処理方法。

本発明は、具体的に開示された実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

１００、１００Ａ、１００Ｂ 情報処理システム
２００、２００Ａ サーバ
２１０、２１０Ａ、３１０、３１０Ａ 状態監視処理部
２１１、２１１Ａ サービス登録部
２１２、２１２Ａ サービス中継部
２１３ サービス制御部
２１４、２１４Ａ サーバ状態同期部
２２０、２２０Ａ 接続状態保存データベース
２３０、２３０Ａ サービス利用情報データベース
２４０ サービス
２５０ アプリ配信処理部
３００、３００Ａ 端末装置
３１１ アプリ登録部
３１２、３１２Ａ アプリ制御部
３１３、３１３Ａ 端末状態同期部
３２０、３２０Ａ 接続状態テーブル
３３０、３３０Ａ アプリ利用情報テーブル
３５０ アプリケーション

Claims (10)

1. サーバと端末装置とを有する情報処理システムであって、
   前記サーバは、
   前記サーバにおける前記サーバと前記端末装置との接続の状態を示す第一の接続状態を管理するサーバ側状態監視処理部と、
   前記第一の接続状態と、前記端末装置において管理される第二の接続状態と、を同期させた結果に基づいて、前記サーバにより確保されたサーバ側リソースの解放又は再利用を行うサーバ側制御部と、を有し、
   前記端末装置は、
   前記端末装置における前記サーバと前記端末装置との接続の状態を示す前記第二の接続状態を管理する端末側状態監視処理部と、
   前記第二の接続状態と、前記第一の接続状態と、を同期させた結果に基づいて、前記端末装置により確保された端末側リソースの解放又は再利用を行う端末側制御部と、を有する、情報処理システム。
2. 前記第一の接続状態と、前記第二の接続状態と、が同期していないとき、
   前記サーバ側状態監視処理部と、前記端末側状態監視処理部と、は、
   前記第一の接続状態と前記第二の接続状態とを、前記サーバと前記端末装置との接続が切断された状態で各々切断を判断させた後に、前記サーバと前記端末装置とが接続された状態で同期させる、請求項１記載の情報処理システム。
3. 前記サーバ側制御部は、
   前記第一の接続状態が、前記接続が切断された状態となったとき、前記サーバ側リソースの解放を行い、
   前記端末側制御部は、
   前記第二の接続状態が、前記接続が切断された状態となったとき、前記端末側リソースの解放を行い、前第二の接続状態が、前記接続された状態となったとき、前記端末側リソースを確保する、請求項２記載の情報処理システム。
4. 前記端末側状態監視処理部は、
   前記端末装置と前記サーバとが接続された場合、
   前記サーバにおいて、前記第一の接続状態が、前記接続された状態とされたことを示す通知を受けてから、前記第二の接続状態を、前記接続された状態とする、請求項２又は３に記載の情報処理システム。
5. 前記サーバは、
   前記端末装置から、前記サーバが提供するサービスの利用要求を受けて、前記利用要求を前記サービスへ中継するサービス中継部を有し、
   前記サービス中継部は、
   前第一の接続状態が、前記接続された状態である場合に、前記利用要求を前記サービスへ中継し、
   前記第一の接続状態が、前記接続が切断された状態である場合に、前記利用要求を前記サービスへ中継しない、請求項２乃至４の何れか一項に記載の情報処理システム。
6. 端末装置と通信を行うサーバであって、
   前記サーバと前記端末装置との接続の状態を示す、第一の接続状態を管理する状態監視処理部と、
   前記第一の接続状態と、前記端末装置において管理される、前記サーバと前記端末装置との接続の状態を示す第二の接続状態と、を同期させた結果に基づいて、前記サーバにおいて確保されたリソースの解放又は再利用を行う制御部と、を有するサーバ。
7. サーバと通信を行う端末装置であって、
   前記サーバと前記端末装置との接続の状態を示す、第二の接続状態を管理する状態監視処理部と、
   前記第二の接続状態と、前記サーバにおいて管理される、前記サーバと前記端末装置との接続の状態を示す第一の接続状態と、を同期させた結果に基づいて、前記端末装置において確保されたリソースの解放又は再利用を行う制御部と、を有する端末装置。
8. サーバと端末装置との接続の状態を示す第一の接続状態を管理し、
   前記第一の接続状態と、前記端末装置において管理される、前記サーバと前記端末装置との接続の状態を示す第二の接続状態と、を同期させた結果に基づいて、前記サーバにおいて確保されたリソースの解放又は再利用を行う、処理を前記サーバに実行させる情報処理プログラム。
9. サーバと端末装置との接続の状態を示す第二の接続状態を管理し、
   前記第二の接続状態と、前記サーバにおいて管理される、前記サーバと前記端末装置との接続の状態を示す第一の接続状態と、を同期させた結果に基づいて、前記端末装置において確保されたリソースの解放又は再利用を行う、処理を前記端末装置に実行させる情報処理プログラム。
10. サーバと端末装置とを有する情報処理システムによる情報処理方法であって、
    前記サーバが、
    前記サーバにおける前記サーバと前記端末装置との接続の状態を示す第一の接続状態を管理し、
    前記第一の接続状態と、前記端末装置において管理される第二の接続状態と、を同期させた結果に基づいて、前記サーバにより確保されたサーバ側リソースの解放又は再利用を行い、
    前記端末装置が、
    前記端末装置における前記サーバと前記端末装置との接続の状態を示す前記第二の接続状態を管理し、
    前記第二の接続状態と、前記第一の接続状態と、を同期させた結果に基づいて、前記端末装置により確保された端末側リソースの解放又は再利用を行う情報処理方法。
    
    
    
    

Images