(57)【特許請求の範囲】
【請求項１】
端末の状況を示す状況情報を端末から受信し、
サービスの種類に拘わらずサービス要求を受け付ける第１のアクセス先を示すアクセス先情報を設定したアプリケーション・ソフトウェアと、前記状況情報に対応するチケット情報とを前記端末に送信し、
前記端末が前記アプリケーション・ソフトウェアを実行することで、前記サービス要求と前記チケット情報とを前記第１のアクセス先で受信し、
前記端末から送信された前記第１のアクセス先宛ての前記サービス要求および前記チケット情報を、前記アプリケーション・ソフトウェアの種類を表す情報と共に受信した場合に、受信した情報に基づき、サービスの種類と対応する端末の状況との少なくとも一方が互いに相違しており、かつ互いにアクセス先が異なる複数のサービスのうち、前記チケット情報が示す前記端末の状況に応じたサービスのアクセス先を決定し、
前記決定したアクセス先に前記サービス要求を転送する、
処理をコンピュータに実行させるアクセス制御方法。
【請求項２】
端末の状況を示す状況情報を端末から受信し、
特定種類のサービスについてのサービス要求を受け付ける第２のアクセス先を示すアクセス先情報を設定したアプリケーション・ソフトウェアと、前記状況情報に対応するチケット情報とを前記端末に送信し、
前記端末が前記アプリケーション・ソフトウェアを実行することで、前記サービス要求と前記チケット情報とを前記第２のアクセス先で受信し、
前記端末から前記アプリケーション・ソフトウェアによる前記第２のアクセス先宛ての前記サービス要求および前記チケット情報を受信した場合に、前記特定種類のサービスのうち前記チケット情報が示す前記端末の状況に対応するサービスのアクセス先を決定し、
前記サービス要求を、前記決定したアクセス先に転送する、
処理をコンピュータに実行させるアクセス制御方法。
【請求項３】
端末の状況を示す状況情報を端末から受信し、
互いにアクセス先が異なる複数のサービスのうち、前記端末から受信した前記状況情報が示す前記端末の状況に応じたサービスのアクセス先を決定し、
前記決定したアクセス先を示すアクセス先情報をサービス要求の送信先に設定したアプリケーション・ソフトウェアと、前記状況情報に対応するチケット情報とを前記端末に送信し、
前記端末が前記アプリケーション・ソフトウェアを実行することで、前記サービス要求と前記チケット情報とを受信し、
前記端末から受信した前記サービス要求を、前記決定したアクセス先に転送する、
処理をコンピュータに実行させるアクセス制御方法。
【請求項４】
前記状況情報は、位置および所持者の属性の少なくとも一方である請求項１〜請求項３の何れか１項記載のアクセス制御方法。
【請求項５】
前記アプリケーション・ソフトウェアは、前記端末から受信した状況情報が示す前記端末の状況に応じて選択される請求項１〜請求項３の何れか１項記載のアクセス制御方法。
【請求項６】
前記端末で実行されている前記アプリケーション・ソフトウェアが前記サービス要求を送信する状況を、前記アプリケーション・ソフトウェアの種類と対応付けて検証情報として記憶しておき、
前記端末から前記サービス要求と前記チケット情報を、前記サービス要求と前記チケット情報を送信した前記アプリケーション・ソフトウェアの種類を表す情報と共に受信した場合に、前記アプリケーション・ソフトウェアの種類および前記チケット情報が示す状況を前記検証情報と照合することで、受信した前記サービス要求が適正か否かを検証する請求項１〜請求項５の何れか１項記載のアクセス制御方法。
【請求項７】
端末の状況を示す状況情報を端末から受信し、
サービス要求を送信する機能を有するアプリケーション・ソフトウェアと、前記状況情報に対応するチケット情報とを前記端末に送信し、
前記端末が前記アプリケーション・ソフトウェアを実行することで、自アプリケーションの種類を示すアプリ情報、サービスの種類を示すサービス種情報、前記チケット情報およびサービスの範囲を指定するサービス範囲情報が付加された前記サービス要求を受信し、
互いにアクセス先が異なり、かつ、提供するサービスの種類、対応する端末の状況および提供するサービスの範囲の少なくとも１つが互いに異なる複数のサービスのうち、前記端末から受信した前記サービス要求に含まれる、前記アプリ情報が示すアプリケーションの種類、前記サービス種情報が示すサービスの種類、前記チケット情報が示す前記端末の状況および前記サービス範囲情報が示すサービスの範囲に応じたサービスのアクセス先を決定し、
前記端末から送信された前記サービス要求を、前記決定したアクセス先に転送する、
処理をコンピュータに実行させるアクセス制御方法。
【請求項８】
端末の状況を示す状況情報を端末から受信し、サービスの種類に拘わらずサービス要求を受け付ける第１のアクセス先を示すアクセス先情報を設定したアプリケーション・ソフトウェアと、前記状況情報に対応するチケット情報とを前記端末に送信する、アプリ配信サーバと、
前記端末が前記アプリケーション・ソフトウェアを実行することで、前記サービス要求と前記チケット情報とを前記第１のアクセス先で受信し、前記端末から送信された前記第１のアクセス先宛ての前記サービス要求および前記チケット情報を、前記アプリケーション・ソフトウェアの種類を表す情報と共に受信した場合に、受信した情報に基づき、サービスの種類と対応する端末の状況の少なくとも一方が互いに相違しており、かつ互いにアクセス先が異なる複数のサービスのうち、前記チケット情報が示す前記端末の状況に応じたサービスのアクセス先を決定し、前記決定したアクセス先に前記サービス要求を転送する、中継サーバと、
を含むアクセス制御装置。
【請求項９】
端末の状況を示す状況情報を端末から受信し、特定種類のサービスについてのサービス要求を受け付ける第２のアクセス先を示すアクセス先情報を設定したアプリケーション・ソフトウェアと、前記状況情報に対応するチケット情報とを前記端末に送信する、アプリ配信サーバと、
前記端末が前記アプリケーション・ソフトウェアを実行することで、前記サービス要求と前記チケット情報とを前記第２のアクセス先にて受信し、前記端末から前記アプリケーション・ソフトウェアによる前記第２のアクセス先宛ての前記サービス要求および前記チケット情報を受信した場合に、前記特定種類のサービスのうち前記チケット情報が示す前記端末の状況に対応するサービスのアクセス先を決定し、前記決定したアクセス先に前記サービス要求を転送する、サービス提供サーバと、
を含むアクセス制御装置。
【請求項１０】
端末の状況を示す状況情報を端末から受信し、互いにアクセス先が異なる複数のサービスのうち、前記端末から受信した前記状況情報が示す前記端末の状況に応じたサービスのアクセス先を決定し、前記決定したアクセス先を示すアクセス先情報をサービス要求の送信先に設定したアプリケーション・ソフトウェアと、前記状況情報に対応するチケット情報とを前記端末に送信する、アプリ配信サーバと、
前記端末が前記アプリケーション・ソフトウェアを実行することで、前記サービス要求と前記チケット情報とを受信し、前記端末から受信した前記サービス要求を、前記決定したアクセス先に転送する、サービス提供サーバと、
を含むアクセス制御装置。
【請求項１１】
端末の状況を示す状況情報を端末から受信し、サービス要求を送信する機能を有するアプリケーション・ソフトウェアと、前記状況情報に対応するチケット情報とを前記端末に送信する、アプリ配信サーバと、
前記端末が前記アプリケーション・ソフトウェアを実行することで、自アプリケーションの種類を示すアプリ情報、サービスの種類を示すサービス種情報、前記チケット情報およびサービスの範囲を指定するサービス範囲情報が付加された前記サービス要求を受信し、互いにアクセス先が異なり、かつ、提供するサービスの種類、対応する端末の状況および提供するサービスの範囲の少なくとも１つが互いに異なる複数のサービスのうち、前記端末から受信した前記サービス要求に含まれる、前記アプリ情報が示すアプリケーションの種類、前記サービス種情報が示すサービスの種類、前記チケット情報が示す前記端末の状況および前記サービス範囲情報が示すサービスの範囲に応じたサービスのアクセス先を決定し、前記端末から送信された前記サービス要求を、前記決定したアクセス先に転送する、名前解決サーバと、
を含むアクセス制御装置。
【請求項１２】
端末の状況を示す状況情報を端末から受信し、
サービスの種類に拘わらずサービス要求を受け付ける第１のアクセス先を示すアクセス先情報を設定したアプリケーション・ソフトウェアと、前記状況情報に対応するチケット情報とを前記端末に送信し、
前記端末が前記アプリケーション・ソフトウェアを実行することで、前記サービス要求と前記チケット情報とを前記第１のアクセス先で受信し、前記端末から送信された前記第１のアクセス先宛ての前記サービス要求および前記チケット情報を、前記アプリケーション・ソフトウェアの種類を表す情報と共に受信した場合に、受信した情報に基づき、サービスの種類と対応する端末の状況の少なくとも一方が互いに相違しており、かつ互いにアクセス先が異なる複数のサービスのうち、前記チケット情報が示す前記端末の状況に応じたサービスのアクセス先を決定し、前記サービス要求を、前記決定したアクセス先に転送する、
処理をコンピュータに実行させるアクセス制御プログラム。
【請求項１３】
端末の状況を示す状況情報を端末から受信し、
特定種類のサービスについてのサービス要求を受け付ける第２のアクセス先を示すアクセス先情報を設定したアプリケーション・ソフトウェアと、前記状況情報に対応するチケット情報とを前記端末に送信し、
前記端末が前記アプリケーション・ソフトウェアを実行することで、前記サービス要求と前記チケット情報とを前記第２のアクセス先で受信し、前記端末から前記アプリケーション・ソフトウェアによる前記第２のアクセス先宛ての前記サービス要求および前記チケット情報を受信した場合に、前記特定種類のサービスのうち前記チケット情報が示す前記端末の状況に対応するサービスのアクセス先を決定し、前記サービス要求を、前記決定したアクセス先に転送する、
処理をコンピュータに実行させるアクセス制御プログラム。
【請求項１４】
端末の状況を示す状況情報を端末から受信し、
互いにアクセス先が異なる複数のサービスのうち、前記端末から受信した前記状況情報が示す前記端末の状況に応じたサービスのアクセス先を決定し、前記決定したアクセス先を示すアクセス先情報をサービス要求の送信先に設定したアプリケーション・ソフトウェアと、前記状況情報に対応するチケット情報とを前記端末に送信し、
前記端末が前記アプリケーション・ソフトウェアを実行することで、前記サービス要求と前記チケット情報とを受信し、前記端末から受信した前記サービス要求を、前記決定したアクセス先に転送する、
処理をコンピュータに実行させるアクセス制御プログラム。
【請求項１５】
端末の状況を示す状況情報を端末から受信し、
サービス要求を送信する機能を有するアプリケーション・ソフトウェアと、前記状況情報に対応するチケット情報とを前記端末に送信し、
前記端末が前記アプリケーション・ソフトウェアを実行することで、自アプリケーションの種類を示すアプリ情報、サービスの種類を示すサービス種情報、前記チケット情報およびサービスの範囲を指定するサービス範囲情報が付加された前記サービス要求を受信し、互いにアクセス先が異なり、かつ、提供するサービスの種類、対応する端末の状況および提供するサービスの範囲の少なくとも１つが互いに異なる複数のサービスのうち、前記端末から受信した前記サービス要求に含まれる、前記アプリ情報が示すアプリケーションの種類、前記サービス種情報が示すサービスの種類、前記チケット情報が示す前記端末の状況および前記サービス範囲情報が示すサービスの範囲に応じたサービスのアクセス先を決定し、
前記端末から送信された前記サービス要求を、前記決定したアクセス先に転送する、
処理をコンピュータに実行させるアクセス制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
開示の技術は、アクセス制御方法、アクセス制御装置およびアクセス制御プログラムに関する。
【背景技術】
【０００２】
従来、アプリケーション・ソフトウェア(以下、単に「アプリ」ともいう)に提供するサービスを切り替える技術に適用可能な技術として、ファイルサーバ装置によって提供される共有ディレクトリの設定情報の変更に関する技術が知られている。この技術では、クライアント計算機に指定される論理的な共有アドレスを、実際に共有ディレクトリが存在する物理的な共有アドレスに変換する。
【０００３】
また、従来、アプリに提供するサービスを切り替える技術に適用可能な技術として、既存の資源に所定の手続きを施した結果得られる仮想的な資源に対するアクセスを可能とする技術も知られている。この技術では、仮想的な資源に対して、その名前と実在する資源の物理的な位置と該実在する資源を取り扱うための手続きの名前とを対応付けて保持管理する。これにより、ネットワーク情報システムの複数の計算機システムの資源を仮想化してシステム全体の融通性を高めることができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−１４６２１２号公報
【特許文献２】特開平０８−１１０８８０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
端末に対し、アプリによって利用されるサービスを端末の状況(以下「端末状況」ともいう)に応じて切り替える技術としては、次の２種類の技術が考えられる。すなわち、サービスを要求される側(サーバのサービス提供プログラム)が端末状況を判断して処理(サービス内容)を切り替える第１の技術、および、サービスを要求する側(端末のアプリ)が端末状況を判断してサービスの要求先を切り替える第２の技術である。
【０００６】
第１の技術は、端末状況を判断し、判断した端末状況に応じて処理(サービス内容)を切り替える機能を、互いに異なるサービスを提供する複数種のサービス提供プログラムに各々実装する必要がある。また、第２の技術は、端末状況を判断し、判断した端末状況に応じてサービスの要求先を切り替える機能を、互いに種類の異なる複数種のアプリに各々実装する必要がある。従って、いずれの技術も構成が非常に複雑になるという課題がある。なお、前述した従来技術は端末状況に関して何ら考慮しておらず、上記の課題を解決することはできない。
【０００７】
開示の技術は、一つの側面として、提供するサービスを端末の状況に応じて切り替えることを簡易な構成で実現することが目的である。
【課題を解決するための手段】
【０００８】
開示の技術は、以下の処理をコンピュータに実行させる。すなわち、互いにアクセス先が異なる複数のサービスのうち、端末から受信した状況情報が示す前記端末の状況に応じたサービスのアクセス先を決定する。そして、設定されたアクセス先にサービス要求を送信する機能を有するアプリケーション・ソフトウェアを実行している前記端末から送信された前記サービス要求により、前記決定したアクセス先のサービスがアクセスされるように制御する。
【発明の効果】
【０００９】
開示の技術は、一つの側面として、提供するサービスを端末の状況に応じて切り替えることを簡易な構成で実現できる、という効果を有する。
【図面の簡単な説明】
【００１０】
【図１】第１実施形態に係るアクセス制御装置および端末の機能ブロック図である。
【図２】第１実施形態に係るコンピュータ・システムの概略構成図である。
【図３】状況ＩＤテーブルの一例を示す図表である。
【図４】状況チケットテーブルの一例を示す図表である。
【図５】必要チケットテーブルの一例を示す図表である。
【図６】チケット情報の一例を示す模式図である。
【図７】第１実施形態に係るアプリ管理テーブルの一例を示す図表である。
【図８】第１実施形態に係る振り分けテーブルの一例を示す図表である。
【図９】アプリ受信処理の一例を示すフローチャートである。
【図１０】第１実施形態に係るアプリ配信処理の一例を示すフローチャートである。
【図１１】サービス要求中継処理の一例を示すフローチャートである。
【図１２】第１実施形態における処理全体の流れの一例を示す模式図である。
【図１３】第２実施形態に係るアクセス制御装置および端末の機能ブロック図である。
【図１４】第２実施形態に係るコンピュータ・システムの概略構成図である。
【図１５】第２実施形態に係るアプリ管理テーブルの一例を示す図表である。
【図１６】第２実施形態に係るアプリ配信処理の一例を示すフローチャートである。
【図１７】第２実施形態に係るサービス要求受信時処理の一例を示すフローチャートである。
【図１８】第２実施形態における処理全体の流れの一例を示す模式図である。
【図１９】第３実施形態に係るアクセス制御装置および端末の機能ブロック図である。
【図２０】第３実施形態に係るコンピュータ・システムの概略構成図である。
【図２１】第３実施形態に係るアプリ配信処理の一例を示すフローチャートである。
【図２２】第３実施形態に係るサービス要求受信時処理の一例を示すフローチャートである。
【図２３】第３実施形態における処理全体の流れの一例を示す模式図である。
【図２４】第４実施形態に係るアクセス制御装置および端末の機能ブロック図である。
【図２５】第４実施形態に係るコンピュータ・システムの概略構成図である。
【図２６】第４実施形態におけるアプリ管理テーブルの一例を示す図表である。
【図２７】第４実施形態における振り分けテーブルの一例を示す図表である。
【図２８】第４実施形態に係るサービス要求受信時処理の一例を示すフローチャートである。
【図２９】第４実施形態における処理全体の流れの一例を示す模式図である。
【図３０】第４実施形態におけるアプリによるサービスの使用の流れの一例を示す模式図である。
【図３１】第４実施形態におけるアプリによるサービスの使用の流れの一例を示す模式図である。
【図３２】第４実施形態におけるアプリによるサービスの使用の流れの一例を示す模式図である。
【発明を実施するための形態】
【００１１】
以下、図面を参照して開示の技術の実施形態の一例を詳細に説明する。なお、以下では、開示の技術を、学校（以下「管理対象の学校」という)の校内における教育現場に適用した態様を説明する。
【００１２】
〔第１実施形態〕
図１には、本第１実施形態に係るアクセス制御装置１０Ａおよび複数の端末２０が示されている。アクセス制御装置１０Ａは、端末２０にアプリを配信するアプリ配信サーバ３０Ａ、端末２０からのサービス要求を中継する中継サーバ４０、および、端末２０からの要求されたサービスを提供するサービス提供サーバ５０Ａを含んでいる。なお、本実施形態ではサービス提供サーバ５０ＡによってＷｅｂサービスが提供される。
【００１３】
アプリ配信サーバ３０Ａは、第１受信部１１、第１送信部１２および記憶部１７を含んでおり、記憶部１７には状況チケットテーブル８０、必要チケットテーブル８２およびアプリ管理テーブル８４Ａが記憶されている。
【００１４】
第１受信部１１は、端末２０の状況を示す情報（以下「状況情報」という)を端末２０から受信する。端末２０から送信される状況情報には、端末２０の状況をコード化した状況ＩＤ(Identification)が含まれている。なお、端末２０から送信される状況情報には、端末２０を所持するユーザの属性を示すユーザ属性情報と、端末２０が存在する場所を示す場所情報と、も含まれている。なお、本実施形態では、ユーザ属性情報としてユーザの役割を示す情報を適用しているが、これに限定されるものではなく、ユーザの属性を示す情報であれば、ユーザの名前、ユーザの所属先等の他の情報を適用してもよい。
【００１５】
第１送信部１２は、第１受信部１１が端末２０から状況情報を受信すると、受信された状況情報に含まれる状況ＩＤが示す端末２０の状況に対応するチケット情報を状況チケットテーブル８０から取得し、状況情報送信元の端末２０へ送信する。図４に示すように、状況チケットテーブル８０は、状況ＩＤと、該状況ＩＤが示す状況の端末２０に対して付与するチケット情報(付与チケット)と、が対応付けて記憶されている。第１送信部１２は、状況チケットテーブル８０を参照し、第１受信部１１が受信した状況情報に含まれる状況ＩＤに対応するチケット情報を取得し、取得したチケット情報を状況ＩＤの送信元の端末２０に送信する。
【００１６】
なお、一例として、図４に示す状況チケットテーブル８０では、「先生用ゲート」を通過したことを示す状況ＩＤを含む状況情報を送信した端末２０に対しては、「先生」を示すチケット情報が送信されることを示している。また、「生徒用ゲート」を通過したことを示す状況ＩＤを含む状況情報を送信した端末２０に対しては、「生徒」を示すチケット情報が送信されることを示している。
【００１７】
図６には本実施形態に係るチケット情報７２の一例を示す。チケット情報７２は、「ticketID」、「ticketSort」、「ticketName」、「expire」および「verificationＵＲＬ(Uniform Resource Locators)」の５種類の情報を含む。
【００１８】
「ticketID」はチケット情報７２の識別子であり、「ticketSort」はチケット情報７２の内容や意味を示す。また、「ticketName」はチケット情報７２の名称を示す情報であり、「expire」はチケット情報７２の有効期限を示す情報である。本実施形態では、該有効期限として予め定められた起算日時からの経過期間を示す情報を適用している。さらに、「verificationＵＲＬ」は、チケット情報７２の発行元(本実施形態では、アプリ配信サーバ３０Ａ)のＵＲＩ（Uniform Resource Identifier）を示す。
【００１９】
詳細は後述するが、端末２０は、アクセス制御装置１０Ａの第１送信部１２によって送信されたチケット情報を受信して記憶部２３に記憶させる。その後、端末２０は、状況情報を送信する際に記憶部２３にチケット情報が記憶されていれば、当該チケット情報をアクセス制御装置１０Ａに送信する。
【００２０】
また、第１送信部１２は、第１受信部１１が端末２０から状況情報等を受信した場合に、必要チケットテーブル８２を参照し、受信した状況情報に含まれる状況ＩＤと対応付けられたアプリ(端末２０へ配信するアプリ)の有無を判定する。
【００２１】
図５に示すように、必要チケットテーブル８２は、状況ＩＤと、該状況ＩＤが示す状況で配信するアプリのアプリＩＤと、当該アプリＩＤのアプリの配信に必要なチケット情報を表す必要チケットと、が関連付けられて記憶されている。図５では、例えば、状況ＩＤが「教室」の状況で配信するアプリのアプリＩＤが「Ａ１００１(プロジェクタアプリ)」および「Ａ１００２(生徒用教材配信アプリ)」であることを示している。
【００２２】
また、必要チケットテーブル８２にアプリＩＤが登録されているアプリの中には、端末２０へのアプリの配信に際してチケット情報を必要とするアプリと、チケット情報を必要としないアプリと、が混在している。図５に示す例では、アプリＩＤが「Ａ１００１」のアプリがチケット情報を必要とするアプリに相当し、アプリＩＤが「Ａ１００２」のアプリがチケット情報を必要としないアプリに相当する。例えば、アプリＩＤが「Ａ１００１」のアプリは、状況ＩＤが「教室」の場合は「先生」および「教室」のチケット情報を必要とし、状況ＩＤが「理科実験室」の場合は「先生」および「理科実験室」のチケット情報を必要としていることを示している。
【００２３】
第１送信部１２は、端末２０から受信した状況情報に含まれる状況ＩＤをキーにして必要チケットテーブル８２を検索し、必要チケットテーブル８２に状況ＩＤと対応付けてアプリＩＤが登録されている場合、端末２０へ配信するアプリが有ると判定する。但し、第１送信部１２は、登録されているアプリＩＤのアプリがチケット情報を必要とするアプリの場合(必要チケットが登録されている場合)は、必要チケットとして登録されているチケット情報を端末２０から受信しているか否か判定する。そして、第１送信部１２は、必要チケットとして登録されているチケット情報を端末２０から受信している場合は、端末２０へ配信するアプリが有ると判定する。
【００２４】
第１送信部１２は、端末２０へ配信するアプリが有ると判定した場合、必要チケットテーブル８２に登録されているアプリＩＤをキーにしてアプリ管理テーブル８４Ａを検索し、端末２０へ配信するアプリをアプリ管理テーブル８４Ａから取得する。そして、第１送信部１２は、必要チケットテーブル８２から取得したアプリＩＤおよびアプリ管理テーブル８４Ａから取得したアプリを端末２０に送信する。
【００２５】
図７に示すように、アプリ管理テーブル８４Ａには、アプリＩＤとアプリ(のプログラム本体)とが対応付けて登録されている。図７に示す例では、「プロジェクタアプリ」がアプリＩＤ「Ａ１００１」と対応付けて登録され、「生徒用教材配信アプリ」がアプリＩＤ「Ａ１００２」と対応付けて登録され、「プロジェクタアプリ」がアプリＩＤ「Ａ２００１」と対応付けて登録されている。
【００２６】
また、アプリ管理テーブル８４Ａに登録されている個々のアプリ(のプログラム本体)は、アクセス制御装置１０Ａに対してサービス要求を送信するサービス要求ステップを含んでいる。本第１実施形態では、個々のアプリのサービス要求ステップに、アクセス先(サービス要求の送信先)として、中継サーバ４０のアドレス(図７に示す例では「ＵＲＬ０」：以下「特定ＵＲＬ」という)が各々設定されている。このため、個々のアプリの開発者は、開発するアプリに、端末２０の状況を検知し、検知した状況に応じてサービス要求ステップのアクセス先を切り替える機能を搭載する必要がなくなり、アプリの開発に要する工数、コストが削減される。
【００２７】
中継サーバ４０は、第２受信部１３、検証部１４、決定部１５、制御部１６および記憶部１８を含んでおり、記憶部１８には振り分けテーブル８６Ａが記憶されている。
【００２８】
本第１実施形態では、端末２０から中継サーバ４０を宛先として(アクセス先を特定ＵＲＬとして)サービス要求が送信される。第２受信部１３は端末２０から送信されたサービス要求を受信する。なお、端末２０から送信されるサービス要求にはアプリＩＤおよびチケット情報が付加されており、第２受信部１３はサービス要求に付加されているアプリＩＤおよびチケット情報も受信する。
【００２９】
検証部１４は、振り分けテーブル８６Ａを参照し、第２受信部１３が端末２０から受信したアプリＩＤおよびチケット情報の組み合わせが有効か否かを検証する。検証部１４は、アプリＩＤおよびチケット情報の組み合わせが振り分けテーブル８６Ａに記憶されている場合に、前記組み合わせが有効であり、端末２０から受信したサービス要求が正当なサービス要求であると判定する。
【００３０】
図８に示すように、振り分けテーブル８６Ａは、アプリＩＤ、振り分けチケットおよびサービスＵＲＬが対応付けて登録されている。アプリＩＤには、サービス要求を送信するアプリのアプリＩＤが登録される。振り分けチケットには、対応するアプリＩＤのアプリから送信されるサービス要求によって要求されるサービスを、端末２０の状況に応じて振り分けるためのチケット情報が登録される。端末２０から受信したサービス要求に付加されたアプリＩＤおよびチケット情報の組み合わせが振り分けテーブル８６Ａに登録されている場合、受信したサービス要求は正当なサービス要求であると判断できる。
【００３１】
また、サービスＵＲＬには、対応するアプリＩＤおよび振り分けチケットの組み合わせに応じて特定される、対応するサービスのアクセス先を示す情報が登録される。図８に示す例では、アプリＩＤが「Ａ１００１」であり、振り分けチケットが「教室」の場合に、サービスのアクセス先が「ＵＲＬα/Ｘ」であることを示している。
【００３２】
決定部１５は、検証部１４によりアプリＩＤおよびチケット情報の組み合わせが有効と判定された場合に、アプリＩＤおよびチケット情報の組み合わせに対応するサービスＵＲＬを振り分けテーブル８６Ａから取得する。そして制御部１６は、端末２０から受信したサービス要求を、決定部１５によって取得されたサービスＵＲＬへ転送する。これにより、端末２０から送信された特定ＵＲＬをアクセス先とするサービス要求(本実施形態ではＨＴＴＰリクエスト)は、サービスＵＲＬへのサービス要求としてサービス提供サーバ５０Ａで受信される。
【００３３】
サービス提供サーバ５０Ａは記憶部１９を含んでおり、記憶部１９にはサービス処理プログラム・データ５２Ａ(図１では「サービス」と表記)が複数記憶されている。サービス処理プログラム・データ５２Ａは、サービスを提供する処理を行うプログラムを少なくとも含み、当該プログラムは、実行されると図１に示すサービス処理部５２Ｂとして機能し、サービスを提供する処理を行う。また、個々のサービス処理プログラム・データ５２Ａは、提供するサービスの種類と対応する端末２０の状況の少なくとも一方が互いに相違している。
【００３４】
例えば、サービス提供サーバ５０Ａが提供可能なサービスの中にはプロジェクタの作動を制御するプロジェクタサービスが含まれているが、プロジェクタサービスを提供するサービス処理プログラム・データ５２Ａは記憶部１９に複数記憶されている。プロジェクタサービスを提供する複数のサービス処理プログラム・データ５２Ａは、プロジェクタアプリからのサービス要求により、互いに異なる場所に設置(例えば教室や理科実験室等)されたプロジェクタの作動を制御するように構成されている。そして、プロジェクタサービスを提供する複数のサービス処理プログラム・データ５２Ａは、制御対象のプロジェクタが設置された場所に位置している状況の端末に対してプロジェクタサービスを提供する。
【００３５】
なお、プロジェクタサービス以外のサービスを提供するサービス処理プログラム・データ５２Ａについても、対応する端末２０の状況が互いに異なる複数のサービス処理プログラム・データ５２Ａが記憶部１９に各々記憶されている
【００３６】
また、記憶部１９に記憶されているサービス処理プログラム・データ５２Ａは、提供するサービスの種類によっては、端末２０に配信するデータも含んでいる。例えば、生徒用教材配信アプリからのサービス要求により生徒用教材を配信する生徒用教材配信サービスを行うサービス処理プログラム・データ５２Ａは、配信対象の生徒用教材のデータを含んでいる。
【００３７】
また、記憶部１９の記憶されている個々のサービス処理プログラム・データ５２Ａには、互いに異なるサービスＵＲＬが割り当てられている。そして、サービス提供サーバ５０Ａでは、記憶部１９に記憶されている個々のサービス処理プログラム・データ５２Ａに含まれるプログラムが予め起動されて実行されている。従って、サービス提供サーバ５０Ａが、特定のサービスＵＲＬをアクセス先とするサービス要求を中継サーバ４０から受信すると、特定のサービスＵＲＬが割り当てられたサービス処理プログラム・データ５２Ａへサービス要求が受け渡される。
【００３８】
一方、本実施形態に係る複数の端末２０の各々は、送信部２１、受信部２２および記憶部２３を含み、記憶部２３には状況ＩＤテーブル８８が記憶されている。
【００３９】
送信部２１は、状況通知装置７０から受信する状況通知に基づいて状況ＩＤを特定する。本実施形態では、端末２０のユーザが、何らかの目的をもって予め定められた場所に入場する際、および該場所から退場する際に通過する位置(以下「通過位置」という)に状況通知装置７０が設けられている。端末２０のユーザは、何れかの通過位置を通過する場合に、端末２０を状況通知装置７０と通信可能な状態としておく。状況通知装置７０は、通過位置を通過する端末２０に対し、自装置が設けられた通過位置を示す場所情報と、前記通過位置を通過可能なユーザに対応するユーザ属性情報と、の少なくとも一方を含む状況通知を送信する。送信部２１は、状況ＩＤテーブル８８を参照して、状況通知装置７０から受信した状況通知に基づいて対応する状況ＩＤを特定する。
【００４０】
図３に示すように、記憶部２３に記憶されている状況ＩＤテーブル８８は、状況通知装置７０から受信する状況通知と、該状況通知に対応する状況ＩＤと、が対応けて記憶されている。図３に示す例では、「先生用の入退場門」という端末２０の状況(後述する先生用の入退場門を端末２０が通過した状況)に対応する状況通知が、「先生用ゲート」の状況ＩＤと対応付けられている。また、図３に示す例では、「生徒用の入退場門」という端末２０の状況(後述する生徒用の入退場門を端末２０が通過した状況)に対応する状況通知が、「生徒用ゲート」の状況ＩＤと対応付けられている。なお、これらの状況は、上述したユーザ属性情報に相当する。
【００４１】
また、送信部２１は、自装置の通過位置の通過が、目的とする場所へのチェックインのための通過なのか、目的とする場所からのチェックアウトのための通過なのかを示す入退場情報を生成する。なお、本実施形態において、送信部２１は、入退場情報として、同じ通過位置の通過が奇数回目の場合に「チェックイン」を示す情報を生成し、同じ通過位置の通過が偶数回目の場合に「チェックアウト」を示す情報を生成する。
【００４２】
送信部２１は、特定した状況ＩＤおよび生成した入退場情報をアクセス制御装置１０Ａに状況情報として送信する。アクセス制御装置１０Ａは、端末２０から状況情報を受信すると、受信した状況情報に含まれる入退場情報がチェックインを示す情報の場合は、受信した状況ＩＤに対応するチケット情報を該端末２０に送信する。また、アクセス制御装置１０Ａは、受信した状況情報に含まれる状況ＩＤに対応し、チケット情報を必要としないアプリがある場合、受信した入退場情報がチェックインを示す情報であれば、前記アプリおよび前記アプリのアプリＩＤを端末２０に送信する。
【００４３】
この場合、受信部２２は、アクセス制御装置１０Ａによって送信されたチケット情報、アプリおよびアプリＩＤを受信する。そして、受信部２２は、受信したチケット情報、アプリおよびアプリＩＤを記憶部２３に記憶させる。
【００４４】
一方、送信部２１は、状況通知装置７０から受信した状況通知に基づいて特定した状況ＩＤが変化した場合に、記憶部２３にチケット情報が記憶されている場合には、該チケット情報も状況情報と共にアクセス制御装置１０Ａに送信する。アクセス制御装置１０Ａは、状況情報およびチケット情報を受信すると、受信した情報に含まれる入退場情報がチェックインを示す情報である場合は、受信した状況ＩＤおよびチケット情報の組み合わせに対応するアプリおよびアプリＩＤを端末２０に送信する。
【００４５】
この場合、受信部２２は、アクセス制御装置１０Ａによって送信されたアプリおよびアプリＩＤを受信する。そして、受信部２２は、受信したアプリおよびアプリＩＤを記憶部２３に記憶させる。
【００４６】
記憶部２３に記憶されたアプリは、端末２０によって適宜実行される。先に説明したように、本実施形態に係るアプリは、アクセス制御装置１０Ａに対してサービス要求を送信するサービス要求ステップを含んでいる。このため、端末２０によってアプリのサービス要求ステップが実行されると、送信部２１は端末２０からアクセス制御装置１０Ａへサービス要求(具体的にはＨＴＴＰ(Hypertext Transfer Protocol)リクエスト）を送信する。この際、送信部２１は、対応するアプリのアプリＩＤと、この時点で記憶部２３に記憶されているチケット情報とを、サービス要求と共にアクセス制御装置１０Ａに送信する。但し、本実施形態では、個々のアプリのサービス要求ステップに、アクセス先として中継サーバ４０のアドレスが各々設定されており、上記のサービス要求は中継サーバ４０へ送信される。
【００４７】
上述したアクセス制御装置１０Ａは、図２に示すコンピュータ・システム９０Ａに含まれるサーバコンピュータ２９Ａによって実現することができる。また、上述した端末２０および状況通知装置７０は、コンピュータ・システム９０Ａに含まれる携帯型端末装置６０および複数(図２では４台のみ示す）の状況通知装置７０Ａ〜７０Ｄによって各々実現することができる。コンピュータ・システム９０Ａは、ネットワーク９２にアクセス可能とされたサーバコンピュータ２９Ａおよび複数の携帯型端末装置６０と、複数の状況通知装置７０Ａ〜７０Ｄと、を含んでいる。なお、以下では、状況通知装置７０Ａ〜７０Ｄの各々を区別なく説明する場合には、符号の末尾のＡ〜Ｄを省略して「状況通知装置７０」と記載する。
【００４８】
携帯型端末装置６０は、管理対象の学校に所属する教師および生徒に予め配布された端末である。携帯型端末装置６０は、ＣＰＵ(Central Processing Unit)６１、メモリ６２、記憶部６３、入力部６４、表示部６５、媒体読み書き装置(Ｒ／Ｗ)６６、無線通信部６７および近距離通信部６８を含んでいる。ＣＰＵ６１、メモリ６２、記憶部６３、入力部６４、表示部６５、Ｒ／Ｗ６６、無線通信部６７および近距離通信部６８はバス６９を介して互いに接続されている。Ｒ／Ｗ６６は、記録媒体９６に書き込まれている情報の読み出しおよび記録媒体９６への情報の書き込みを行う。
【００４９】
記憶部６３は、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ等によって実現できる。記憶部６３には、携帯型端末装置６０を図１に示す端末２０として機能させるためのアプリ受信処理プログラム６３Ａが記憶されている。
【００５０】
アプリ受信処理プログラム６３Ａは、アプリ受信処理プログラム６３Ａが書き込まれた記録媒体９６がＲ／Ｗ６６にセットされ、Ｒ／Ｗ６６が記録媒体９６からの該プログラム６３Ａの読み出しを行うことで、記憶部６３へ記憶される。ＣＰＵ６１は、アプリ受信処理プログラム６３Ａを記憶部６３から読み出してメモリ６２に展開し、アプリ受信処理プログラム６３Ａが有するプロセスを順次実行する。
【００５１】
アプリ受信処理プログラム６３Ａは、送信プロセス６３Ａ１および受信プロセス６３Ａ２を有する。ＣＰＵ６１は、送信プロセス６３Ａ１を実行することで、図１に示す送信部２１として動作する。また、ＣＰＵ６１は、受信プロセス６３Ａ２を実行することで、図１に示す受信部２２として動作する。これにより、アプリ受信処理プログラム６３Ａを実行した携帯型端末装置６０が図１に示す端末２０として機能することになる。
【００５２】
また、記憶部６３には、状況ＩＤテーブル記憶領域６３Ｃが設けられている。ＣＰＵ６１が、状況ＩＤテーブル記憶領域６３Ｃに記憶されたデータをメモリ６２に展開することにより、図１に示す状況ＩＤテーブル８８が作成される。
【００５３】
また、近距離通信部６８は、状況通知装置７０との間で予め定められた通信規格によって近距離通信を行う。なお、近距離通信部６８は、上記通信規格として、ＮＦＣ（Near Field Communication）を適用している。このため、携帯型端末装置６０のユーザは、上記通過位置を通過する際には、状況通知装置７０の所定の通信可能位置に端末２０をかざすことになる。なお、近距離通信部６８で適用する通信規格はＮＦＣには限らない。例えば、Bluetooth(登録商標)、ＩｒＤＡ(Infrared Data Association)(登録商標)等の他の無線通信の規格を近距離通信部６８の通信規格として適用してもよい。
【００５４】
一方、サーバコンピュータ２９Ａは、例えば、管理対象の学校の何れかの場所(例えば職員室)に設けられている。サーバコンピュータ２９Ａは、ＣＰＵ３１、メモリ３２、記憶部３９、入力部３４、表示部３５、媒体読み書き装置(Ｒ／Ｗ)３６および通信インタフェース（Ｉ／Ｆ）部３７を備えている。ＣＰＵ３１、メモリ３２、記憶部３９、入力部３４、表示部３５、Ｒ／Ｗ３６および通信Ｉ／Ｆ部３７はバス３８を介して互いに接続されている。Ｒ／Ｗ３６は、記録媒体９６に書き込まれている情報の読み出しおよび記録媒体９６への情報の書き込みを行う。
【００５５】
記憶部３９はＨＤＤやフラッシュメモリ等によって実現できる。記憶部３９には、アプリ配信サーバプログラム３３Ａ、中継サーバプログラム４３Ａおよびサービス提供サーバプログラム５２が各々記憶されている。なお、アプリ配信サーバプログラム３３Ａはサーバコンピュータ２９Ａをアプリ配信サーバ３０Ａとして機能させるためのプログラムであり、中継サーバプログラム４３Ａはサーバコンピュータ２９Ａを中継サーバ４０として機能させるためのプログラムである。また、サービス提供サーバプログラム５２はサーバコンピュータ２９Ａをサービス提供サーバ５０Ａとして機能させるためのプログラムである。
【００５６】
上記の各プログラム３３Ａ,４３Ａ,５２は、各プログラム３３Ａ,４３Ａ,５２が書き込まれた記録媒体９６がＲ／Ｗ３６にセットされ、Ｒ／Ｗ３６が記録媒体９６からの各プログラム３３Ａ,４３Ａ,５２の読み出しを行うことで、記憶部３９へ記憶される。なお、各プログラム３３Ａ,４３Ａ,５２は開示の技術に係るアクセス制御プログラムの一部の一例である。
【００５７】
ＣＰＵ３１は、アプリ配信サーバプログラム３３Ａを記憶部３９から読み出してメモリ３２に展開し、アプリ配信サーバプログラム３３Ａが有するプロセスを順次実行する。アプリ配信サーバプログラム３３Ａは、第１受信プロセス３３Ａ１および第１送信プロセス３３Ａ２を有する。ＣＰＵ３１は、第１受信プロセス３３Ａ１を実行することで、図１に示す第１受信部１１として動作する。また、ＣＰＵ３１は、第１送信プロセス３３Ａ２を実行することで、図１に示す第１送信部１２として動作する。これにより、アプリ配信サーバプログラム３３Ａを実行したサーバコンピュータ２９Ａが、図１に示すアプリ配信サーバ３０Ａとして機能することになる。
【００５８】
またＣＰＵ３１は、中継サーバプログラム４３Ａを記憶部４３から読み出してメモリ３２に展開し、中継サーバプログラム４３Ａが有するプロセスを順次実行する。中継サーバプログラム４３Ａは、第２受信プロセス４３Ａ１、検証プロセス４３Ａ２、決定プロセス４３Ａ３および制御プロセス４３Ａ４を有する。ＣＰＵ３１は、第２受信プロセス４３Ａ１を実行することで図１に示す第２受信部１３として動作する。また、ＣＰＵ３１は、検証プロセス４３Ａ２を実行することで図１に示す検証部１４として動作する。また、ＣＰＵ３１は、決定プロセス４３Ａ３を実行することで図１に示す決定部１５として動作する。さらに、ＣＰＵ３１は、制御プロセス４３Ａ４を実行することで図１に示す制御部１６として動作する。これにより、中継サーバプログラム４３Ａを実行したサーバコンピュータ２９Ａが、図１に示す中継サーバ４０として機能することになる。
【００５９】
ＣＰＵ３１は、サービス提供サーバプログラム５２を記憶部３９から読み出してメモリ３２に展開し、サービス提供サーバプログラム５２を実行する。サービス提供サーバプログラム５２には、複数のサービス処理プログラム・データ５２Ａが含まれている。これにより、サービス提供サーバプログラム５２を実行したサーバコンピュータ２９Ａが、図１に示すサービス提供サーバ５０Ａとして機能することになる。
【００６０】
また、記憶部３９には、状況チケットテーブル記憶領域３３Ｂ、必要チケットテーブル記憶領域３３Ｃ、アプリ管理テーブル記憶領域３３Ｄおよび振り分けテーブル記憶領域４３Ｂが設けられている。ＣＰＵ３１が、状況チケットテーブル記憶領域３３Ｂに記憶されたデータをメモリ３２に展開することにより、図１に示す状況チケットテーブル８０が作成される。また、ＣＰＵ３１が、必要チケットテーブル記憶領域３３Ｃに記憶されたデータをメモリ３２に展開することにより、図１に示す必要チケットテーブル８２が作成される。また、ＣＰＵ３１が、アプリ管理テーブル記憶領域３３Ｄに記憶されたデータをメモリ３２に展開することにより、図１に示すアプリ管理テーブル８４Ａが作成される。ＣＰＵ３１が、振り分けテーブル記憶領域４３Ｂに記憶されたデータをメモリ３２に展開することにより、図１に示す振り分けテーブル８６Ａが作成される。
【００６１】
一方、図２に示すように、本実施形態に係る状況通知装置７０Ａ〜７０Ｄにおける状況通知装置７０Ａは管理対象の学校の先生用の入退場門に設けられており、状況通知装置７０Ｂは管理対象の学校の生徒用の入退場門に設けられている。また、状況通知装置７０Ｃは管理対象の学校の職員室の出入口に設けられており、状況通知装置７０Ｄは後述する管理対象の教室の出入口に設けられている。
【００６２】
なお、状況通知装置７０Ａ〜７０Ｃは、通信可能位置にかざされた端末２０(携帯型端末装置６０)に対して、上述したユーザ属性情報を含む状況通知を送信する。また、状況通知装置７０Ｄは、通信可能位置にかざされた端末２０に対して、上述した場所情報を含む状況通知を送信する。具体的には、状況通知装置７０Ａおよび状況通知装置７０Ｃは、端末２０に対して「先生」の情報を含む状況通知を送信し、状況通知装置７０Ｂは、端末２０に対して「生徒」の情報を含む状況通知を送信する。また、状況通知装置７０Ｄは、端末２０に対して「教室」の情報を含む状況通知を送信する。上述したように、本実施形態に係る端末２０は、近距離通信部６８の通信規格としてＮＦＣを採用しているため、状況通知装置７０も通信規格としてＮＦＣを採用している。
【００６３】
なお、本実施形態では、携帯型端末装置６０として、表示部６５の表示面にタッチパネルが設けられた汎用のタブレットＰＣ(Personal Computer)が適用した態様を説明するが、これに限らない。携帯型端末装置６０として、ノートブック型ＰＣ等の他のコンピュータを適用してもよい。また、携帯型端末装置６０として、以上のＰＣに限らず、スマートフォン(Smartphone)を適用してもよい。
【００６４】
また、本実施形態に係るサーバコンピュータ２９Ａは、管理対象の学校の所定の部屋(本実施形態では職員室)に設置されているが、これに限定されるものではない。例えば、管理対象の学校の他の部屋や、管理対象の学校とは異なる建物内に設置されていてもよい。また、本実施形態では、サーバコンピュータ２９Ａをアプリ配信サーバ３０Ａ、中継サーバ４０およびサービス提供サーバ５０Ａとして各々機能させているが、これに限られるものではなく、各サーバを互いに異なるコンピュータによって実現してもよい。
【００６５】
次に、本第１実施形態の作用を説明する。なお、以下では、管理対象の学校に所属する教師および生徒により管理対象の学校内の所定の教室（以下、「管理対象の教室」という)において授業を実施する態様を説明する。教師および生徒は、自身に対応する入退場門から管理対象の学校の校内に入場するにあたり、自身が所持する端末２０によってアプリ受信処理プログラム６３Ａを実行させることで、図９に示すアプリ受信処理が行われる。
【００６６】
アプリ受信処理のステップ１００において、送信部２１は、何れかの状況通知装置７０からの状況通知の受信待ちを行う。また、送信部２１は、状況通知を受信した場合、受信した状況通知が、直近に得られた状況通知に対して変化しているか否かを判定し、肯定判定となった場合はステップ１０１に移行する。ステップ１０１において、送信部２１は、状況ＩＤテーブル８８を参照して、受信した状況通知から状況ＩＤを特定し、ステップ１０２に移行する。ステップ１０２において、送信部２１は、入退場情報を生成し、生成した入退場情報がチェックインを示すものか否かを判定して、肯定判定となった場合はステップ１０４に移行する。
【００６７】
ステップ１０４において、送信部２１は、チケット情報７２がメモリ６２(記憶部２３)に記憶されているか否かを判定し、肯定判定となった場合はステップ１０６に移行する。ステップ１０６において、送信部２１は、特定した状況ＩＤ、生成した入退場情報およびメモリ６２に記憶されているチケット情報７２をアプリ配信サーバ３０Ａに送信した後、ステップ１１０に移行する。
【００６８】
一方、ステップ１０４において否定判定となった場合はステップ１０８に移行し、送信部２１は、特定した状況ＩＤおよび生成した入退場情報をアプリ配信サーバ３０Ａに送信した後、ステップ１１０に移行する。
【００６９】
アプリ配信サーバ３０Ａは、何れかの端末２０から状況ＩＤ、入退場情報およびチケット情報７２、又は状況ＩＤおよび入退場情報を受信すると、受信した情報に応じたアプリ、アプリＩＤおよびチケット情報７２を送信元の端末２０に送信する。
【００７０】
そこで、ステップ１１０において、受信部２２は、アプリ配信サーバ３０Ａから送信されたアプリ、アプリＩＤおよびチケット情報７２の各情報の受信待ちを行う。ステップ１１０の判定が肯定されるとステップ１１２に移行し、受信部２２は、受信したアプリ、アプリＩＤおよびチケット情報７２をメモリ６２に記憶(登録)する。ステップ１１２の処理が終了すると、ステップ１２０に移行する。
【００７１】
一方、ステップ１０２において否定判定となった場合は、生成した入退場情報がチェックアウトを示すと見なしてステップ１１４に移行し、送信部２１は、特定した状況ＩＤおよび生成した入退場情報をアプリ配信サーバ３０Ａに送信し、ステップ１１６に移行する。
【００７２】
本実施形態に係るアプリ配信サーバ３０Ａは、端末２０からチェックアウトを示す入退場情報を受信すると、受信した情報に応じたアプリ、アプリＩＤおよびチケット情報７２のメモリ６２からの削除を指示する削除指示情報を送信元の端末２０に送信する。
【００７３】
そこで、ステップ１１６において、受信部２２は、アプリ配信サーバ３０Ａから送信された削除指示情報の受信待ちを行う。ステップ１１６の判定が肯定されるとステップ１１８に移行し、ステップ１１８において、受信部２２は、受信した削除指示情報によって示すアプリ、アプリＩＤおよびチケット情報７２をメモリ６２から削除(消去)する。ステップ１１８の処理が終了すると、ステップ１２０に移行する。
【００７４】
ステップ１２０において、受信部２２は、アプリ受信処理を終了するタイミングとして予め定められたタイミングが到来したか否かを判定し、否定判定となった場合はステップ１００に戻る一方、肯定判定となった時点でアプリ受信処理を終了する。なお、本実施形態に係るアプリ受信処理では、上記予め定められたタイミングとして、ユーザによってアプリ受信処理の終了を指示する指示入力が行われたタイミングを適用しているが、これに限るものではないことは言うまでもない。
【００７５】
一方、本実施形態に係るコンピュータ・システム９０Ａでは、サーバコンピュータ２９Ａがアプリ配信サーバプログラム３３Ａを実行することで実現されるアプリ配信サーバ３０Ａにより、図１０に示すアプリ配信処理が行われる。
【００７６】
アプリ配信処理のステップ２００において、第１受信部１１は、何れかの端末２０からの状況ＩＤ、入退場情報およびチケット情報７２か、又は状況ＩＤおよび入退場情報の受信待ちを行う。ステップ２００の判定が肯定されるとステップ２０２に移行し、ステップ２０２において、第１送信部１２は、受信した情報に含まれる入退場情報がチェックインを示すものであるか否かを判定し、肯定判定となった場合はステップ２０４に移行する。
【００７７】
ステップ２０４において、第１送信部１２は、受信した情報に含まれる状況ＩＤに対応するチケット情報７２を、状況チケットテーブル８０を参照することにより決定する。次のステップ２０６において、第１送信部１２は、決定したチケット情報７２を送信元の端末２０に送信する。
【００７８】
次のステップ２０７において、第１送信部１２は、受信した情報に含まれる状況ＩＤをキーにして必要チケットテーブル８２を検索し、状況ＩＤが示す状況で配信すべきアプリが有るか否か判定する。また、配信すべきアプリが有った場合は、当該アプリと対応付けて必要チケットテーブル８２に必要チケットが登録されているか判定し、必要チケットが登録されている場合は、必要チケットを端末２０から受信しているか否かを更に判定する。配信すべきアプリが無い場合、および、配信すべきアプリは有るものの端末２０から必要チケットを受信していない場合は、ステップ２０７の判定が否定されてステップ２１４Ａへ移行する。
【００７９】
一方、配信すべきアプリが有り、必要チケットが登録されていない場合、および、配信すべきアプリが有り、登録されている必要チケットを端末２０から受信している場合には、ステップ２０７の判定が肯定されてステップ２０８へ移行する。ステップ２０８において、第１送信部１２は、端末２０から受信した情報にチケット情報７２が含まれるか否かを判定し、肯定判定となった場合はステップ２１０に移行する。ステップ２１０において、第１送信部１２は、端末２０から受信したチケット情報７２および状況ＩＤに対応するアプリおよびアプリＩＤを、必要チケットテーブル８２およびアプリ管理テーブル８４Ａを参照することにより決定・取得する。ステップ２１０の処理を行うとステップ２１４Ａに移行する。
【００８０】
一方、ステップ２０８において否定判定となった場合、ステップ２１２に移行する。ステップ２１２において、第１送信部１２は、端末２０から受信した状況ＩＤに対応するアプリおよび該アプリのアプリＩＤを、必要チケットテーブル８２およびアプリ管理テーブル８４Ａを参照することにより決定・取得し、その後にステップ２１４Ａに移行する。
【００８１】
ステップ２１４Ａにおいて、第１送信部１２は、ステップ２１０又はステップ２１２の処理により決定・取得したアプリおよびアプリＩＤを送信元の端末２０に送信した後、ステップ２２０に移行する。
【００８２】
一方、ステップ２０２において否定判定となった場合は、受信した情報に含まれる入退場情報がチェックアウトを示すと見なしてステップ２１６に移行する。ステップ２１６において、第１送信部１２は、受信した状況ＩＤに応じた削除対象のチケット情報７２を、状況チケットテーブル８０を参照することにより決定する。また、第１送信部１２は、受信した状況ＩＤに応じた削除対象のアプリおよび該アプリのアプリＩＤを、必要チケットテーブル８２およびアプリ管理テーブル８４Ａを参照することにより決定した後、ステップ２１８に移行する。
【００８３】
ステップ２１８において、第１送信部１２は、ステップ２１６の処理によって決定した削除対象とするチケット情報７２、アプリおよびアプリＩＤの削除を指示する削除指示情報を送信元の端末２０に送信した後、ステップ２２０に移行する。
【００８４】
ステップ２２０において、第１送信部１２は、アプリ配信処理を終了するタイミングとして予め定められたタイミングが到来したか否かを判定し、否定判定となった場合はステップ２００に戻る一方、肯定判定となった時点でアプリ配信処理を終了する。なお、本実施形態では、上記予め定められたタイミングとして、ユーザによってアプリ配信処理の終了を指示する指示入力が行われたタイミングを適用しているが、これに限るものではない。
【００８５】
ところで、本実施形態に係る端末２０では、ユーザによる指示操作等に応じて、アプリ配信サーバ３０Ａから配信されてメモリ６２に記憶されたアプリが実行される。ここで本第１実施形態では、個々のアプリの中のサービス要求ステップに、アクセス先として中継サーバ４０のＵＲＬが設定されている。このため、端末２０によって実行中のアプリの中のサービス要求ステップが実行されると、送信部２１により、サービス要求が、アプリＩＤおよびチケット情報と共に中継サーバ４０へ送信される。
【００８６】
サーバコンピュータ２９Ａが中継サーバプログラム４３Ａを実行することで実現される中継サーバ４０は、図１１に示すサービス要求中継処理を行う。
【００８７】
サービス要求中継処理のステップ１５０Ａにおいて、第２受信部１３は、何れかの端末２０からサービス要求、アプリＩＤおよびチケット情報７２を受信するまで待機する。そして、第２受信部１３は、何れかの端末２０から上記の情報を受信した場合に、受信したアプリＩＤおよびチケット情報７２を検証部１４へ引き渡してステップ１５２Ａに移行する。
【００８８】
ステップ１５２Ａにおいて、検証部１４は、第２受信部１３から引き渡されたアプリＩＤとチケット情報７２の組み合わせが振り分けテーブル８６Ａに登録されているか否か、すなわち、受信したサービス要求が正当なサービス要求か否かを検証する。次のステップ１５６において、検証部１４は、受信したサービス要求が正当なサービス要求か否かを判定し、肯定判定となった場合はステップ３０６Ａに移行する。
【００８９】
ステップ３０６Ａにおいて、決定部１５は、受信したアプリＩＤとチケット情報７２の組み合わせに対応するサービスＵＲＬを振り分けテーブル８６Ａから読み出すことにより取得する。そして、次のステップ３０８において、制御部１６は、端末２０から受信したサービス要求を、決定部１５によって取得されたサービスＵＲＬへ転送する。
【００９０】
中継サーバ４０によって転送(中継)された上記のサービス要求を受信したサービス提供サーバ５０Ａでは、上記のサービスＵＲＬが割り当てられたサービス処理プログラム・データ５２Ａがアクセスされる。これにより、アクセスされたサービス処理プログラム・データ５２Ａに含まれるプログラムが実行されることで、サービス処理部５２Ｂにより、要求されたサービスを端末２０に提供する処理が行われる。
【００９１】
ここで、サービス提供サーバ５０Ａの記憶部１９に記憶されている個々のサービス処理プログラム・データ５２Ａは、提供するサービスの種類と対応する端末２０の状況の少なくとも一方が互いに相違している。サービスＵＲＬは、アプリＩＤとチケット情報７２の組み合わせから選択されるので、サービス要求を送信したアプリの種類と端末２０の現在の状況に対応するサービスを提供するサービス処理プログラム・データ５２Ａがアクセスされる。これにより、サービス処理プログラム・データ５２Ａの開発者は、端末２０の状況を検知し、検知した状況に応じて提供するサービスの内容を切り替える機能をサービス処理プログラム・データ５２Ａに搭載する必要が無くなる。従って、サービス処理プログラム・データ５２Ａの開発に要する工数、コストが削減される
【００９２】
例えば、プロジェクタサービスを提供する複数のサービス処理プログラム・データ５２Ａは、プロジェクタアプリからのサービス要求により、互いに異なる場所に設置されたプロジェクタの作動を制御するように設定される。また、プロジェクタサービスを提供する複数のサービス処理プログラム・データ５２Ａには、互いに異なるサービスＵＲＬが割り当てられる。
【００９３】
そして、例えば教室内に位置している端末２０のプロジェクタアプリからサービス要求が送信された場合は、教室内に設置されたプロジェクタの作動を制御するプロジェクタサービスを提供するサービス処理プログラム・データ５２Ａのプログラムが実行される。また、例えば理科実験室に位置している端末２０のプロジェクタアプリからサービス要求が送信された場合は、理科実験室内に設置されたプロジェクタの作動を制御するプロジェクタサービスを提供するサービス処理プログラム・データ５２Ａのプログラムが実行される。従って、個々のサービス処理プログラム・データ５２Ａに、端末２０の状況を検知し、検知した状況に応じて提供するサービスの内容を切り替える機能を搭載する必要が無くなる。
【００９４】
一方、ステップ１５６において否定判定となった場合はステップ１５８に移行し、検証部１４は、アクセス元の端末２０にエラー応答を送信し、サービス要求中継処理を終了する。この場合、端末２０からサービス要求を送信することで要求したサービスは端末２０に提供されない。また、エラー応答を受信した端末２０では、例えば、エラーが発生したことを通知するメッセージ等を表示部６５に表示する処理が行われるが、他の処理を適用してもよい。
【００９５】
次に、図１２を参照し、何れかの端末２０が何れかの場所にチェックインした際の処理全体の流れを説明する。端末２０は、何れかの場所にチェックインすると、送信部２１により、チェックインした場所に関する状況を示す状況ＩＤ、チェックインを示す入退場情報を含む状況情報をアプリ配信サーバ３０Ａに送信する。
【００９６】
アプリ配信サーバ３０Ａは、端末２０から送信された状況情報を第１受信部１１によって受信する。そして、アプリ配信サーバ３０Ａの第１送信部１２は、受信した状況情報に含まれる状況ＩＤを対応付けられたチケット情報を状況チケットテーブル８０から取得し、取得したチケット情報を端末２０に送信する。また、受信した状況ＩＤに対応し、かつチケット情報を必要としないアプリのアプリＩＤが必要チケットテーブル８２に登録されている場合がある。この場合、第１送信部１２は、必要チケットテーブル８２の登録されているアプリＩＤのアプリ本体をアプリ管理テーブル８４Ａから取得し、取得したアプリをアプリＩＤと共に端末２０に送信する。
【００９７】
端末２０は、アプリ配信サーバ３０Ａから送信されたチケット情報を受信部２２によって受信し、メモリ６２に記憶する。また、アプリ配信サーバ３０ＡからアプリおよびアプリＩＤが送信された場合、端末２０は、アプリ配信サーバ３０Ａから送信されたアプリおよびアプリＩＤを受信部２２によって受信し、メモリ６２に記憶する。
【００９８】
その後、端末２０は、新たな場所にチェックインすると、送信部２１により、チェックインした場所に関する状況を示す状況ＩＤおよびチェックインを示す入退場情報を含む状況情報と、既に登録されているチケット情報をアプリ配信サーバ３０Ａに送信する。
【００９９】
この場合、アプリ配信サーバ３０Ａは、端末２０から送信された状況ＩＤ、入退場情報を含む状況情報およびチケット情報を第１受信部１１によって受信する。そして、アプリ配信サーバ３０Ａの第１送信部１２は、受信した状況ＩＤに対応するチケット情報を状況チケットテーブル８０から取得し、取得したチケット情報を端末２０に送信する。これに応じて、端末２０は、アプリ配信サーバ３０Ａから送信されたチケット情報を受信部２２によって受信し、メモリ６２に記憶する。
【０１００】
なお、アプリ配信サーバ３０Ａにおいて、受信した状況ＩＤおよびチケット情報の組み合わせに対応するアプリのアプリＩＤが必要チケットテーブル８２に登録されている場合がある。この場合、アプリ配信サーバ３０Ａの第１送信部１２は、アプリＩＤに基づきアプリ本体をアプリ管理テーブル８４Ａから取得し、取得したアプリをアプリＩＤと共に端末２０に送信する。これに応じて、端末２０は、アプリ配信サーバ３０Ａから送信されたアプリおよびアプリＩＤを受信部２２によって受信し、メモリ６２に記憶する。
【０１０１】
その後、端末２０によってメモリ６２に記憶されたアプリは、端末２０のユーザからの指示入力等に応じて適宜実行される。前述のように、本第１実施形態では、個々のアプリの中のサービス要求ステップに、アクセス先として中継サーバ４０のＵＲＬ(図１２に示す例では「ＵＲＬ０」)が設定されている。このため、端末２０によって実行中のアプリの中のサービス要求ステップが実行されると、送信部２１により、サービス要求が、アプリＩＤおよびチケット情報７２と共に中継サーバ４０へ送信される。なお、本第１実施形態において、中継サーバ４０は第１のアクセス先の一例であり、中継サーバ４０のＵＲＬ(ＵＲＬ０)は第１のアクセス先を示すアクセス先情報の一例である。
【０１０２】
中継サーバ４０の第２受信部１３は、端末２０から送信されたサービス要求、アプリＩＤおよびチケット情報７２を受信する。中継サーバ４０の検証部１４は、端末２０から受信したアプリＩＤとチケット情報７２の組み合わせが振り分けテーブル８６Ａに登録されているか否か検証する。受信したアプリＩＤとチケット情報７２の組み合わせが振り分けテーブル８６Ａに登録されていた場合、中継サーバ４０の決定部１５は、受信したアプリＩＤとチケット情報７２の組み合わせに対応するサービスＵＲＬを振り分けテーブル８６Ａから取得する。そして、中継サーバ４０の制御部１６は、端末２０から受信したサービス要求をサービスＵＲＬへ転送する。
【０１０３】
中継サーバ４０によって転送(中継)されたサービス要求を受信したサービス提供サーバ５０Ａでは、上記のサービスＵＲＬが割り当てられたサービス処理プログラム・データ５２Ａがアクセスされる。これにより、アクセスされたサービス処理プログラム・データ５２Ａに含まれるプログラムが実行されることで、サービス処理部５２Ｂにより、要求されたサービスを端末２０に提供する処理が行われる。
【０１０４】
このように、本第１実施形態では、複数のサービス処理プログラム・データ５２Ａに互いに異なるサービスＵＲＬが割り当てられている。また、端末２０から受信したチケット情報が示す端末２０の状況に対応するサービス処理プログラム・データ５２ＡのサービスＵＲＬを決定する。そして、アプリに含まれるサービス要求ステップが端末２０で実行されることで端末２０から送信されたサービス要求を、決定したサービスＵＲＬへ転送する。これにより、端末の状況を検知してアクセス先または処理内容を切り替える機能をアプリおよびサービス処理プログラム・データ５２Ａに搭載する必要がなくなり、提供するサービスを端末の状況に応じて切り替えることを簡易な構成で実現することができる。また、アプリおよびサービス処理プログラム・データ５２Ａの開発工数およびコストも削減できる。
【０１０５】
また、本第１実施形態では、複数のサービス処理プログラム・データ５２Ａは、提供するサービスの種類と対応する端末の状況の少なくとも一方が互いに相違されている。また、サービスの種類に拘わらずサービス要求を受け付ける中継サーバ４０をサービス要求ステップにアクセス先として設定したアプリを端末２０に送信する。そして、端末２０から中継サーバ４０宛てのサービス要求、チケット情報およびアプリＩＤを受信した場合に、受信した情報に基づきサービスＵＲＬを決定する。これにより、アプリに含まれるサービス要求ステップに設定するアクセス先を一律に中継サーバに設定しておくことができ、アプリの開発負荷を更に削減できる。
【０１０６】
また、本第１実施形態では、端末２０から受信した状況情報が示す端末２０の状況に応じて選択したアプリを端末２０に送信する。これにより、端末２０のユーザが、端末２０の状況に応じてアプリを選択する手間が省け、端末２０の操作性を向上させることができる。
【０１０７】
更に、本第１実施形態では、端末２０で実行されているアプリがサービス要求を送信する状況に対応するチケット情報が、アプリのアプリＩＤと対応付けて振り分けテーブル８６Ａに登録されている。そして、端末２０からサービス要求、チケット情報およびアプリＩＤを受信した場合に、アプリＩＤとチケット情報の組み合わせを振り分けテーブル８６Ａと照合することで、受信したサービス要求が適正か否かを検証している。これにより、適正でないサービス要求を排除することができ、コンピュータ・システムとしての堅牢性を向上させることができる。
【０１０８】
〔第２実施形態〕
次に開示の技術の第２実施形態について説明する。なお、第１実施形態と同一の部分には同一の符号を付し、説明を省略する。
【０１０９】
図１３には、本第２実施形態に係るアクセス制御装置１０Ｂおよび複数の端末２０が示されている。アクセス制御装置１０Ｂは、第１実施形態で説明したアクセス制御装置１０Ａと比較して、中継サーバ４０が省略されており、互いに種類の異なるサービスを提供する処理を行う複数のサービス提供サーバ５０Ｂを含んでいる点で相違している。
【０１１０】
個々のサービス提供サーバ５０Ｂには、互いに異なるＵＲＬ(サービス種ＵＲＬ)が割り当てられている。個々のサービス提供サーバ５０Ｂの記憶部１９には、個々のサービス提供サーバ５０Ｂに対応する種類のサービスを提供するサービス処理プログラム・データ５２Ａが各々記憶されている。個々のサービス処理プログラム・データ５２Ａには、第１実施形態と同様に、互いに異なるサービスＵＲＬが割り当てられている。また、個々のサービス提供サーバ５０Ｂは、第２受信部１３、検証部１４、決定部１５、制御部１６およびサービス処理部５２Ｂを含んでいる。第２受信部１３、検証部１４、決定部１５および制御部１６の機能は第１実施形態とほぼ同じであるので、説明を省略する。
【０１１１】
また、本第２実施形態は、アプリ配信サーバ３０Ａの記憶部１７に、第１実施形態で説明したアプリ管理テーブル８４Ａに代えて、アプリ管理テーブル８４Ｂが記憶されている点でも第１実施形態と相違している。図１５に示すように、アプリ管理テーブル８４Ｂは、アプリＩＤとアプリ(のプログラム本体)とが対応付けて登録されている点はアプリ管理テーブル８４Ａと同じである。但し、アプリ管理テーブル８４Ｂに登録されている個々のアプリ(のプログラム本体)は、サービス要求ステップにおけるアクセス先として、要求するサービスの種類に対応するサービス提供サーバ５０Ｂのサービス種ＵＲＬが各々設定されている。図１５では、サービス種ＵＲＬの一例を「ＵＲＬα」「ＵＲＬβ」として示している。
【０１１２】
上述したアクセス制御装置１０Ｂは、図１４に示すコンピュータ・システム９０Ｂに含まれるサーバコンピュータ２９Ｂによって実現することができる。サーバコンピュータ２９Ｂの記憶部３９には、アプリ配信サーバプログラム３３Ａおよびサービス提供サーバプログラム５３が各々記憶されている。なお、サービス提供サーバプログラム５３はサーバコンピュータ２９Ｂをサービス提供サーバ５０Ｂとして機能させるためのプログラムである。
【０１１３】
サーバコンピュータ２９ＢのＣＰＵ３１は、サービス提供サーバプログラム５３を記憶部４３から読み出してメモリ３２に展開し、サービス提供サーバプログラム５３が有するプロセスを順次実行する。サービス提供サーバプログラム５３は、第２受信プロセス５３Ａ１、検証プロセス５３Ａ２、決定プロセス５３Ａ３および制御プロセス５３Ａ４を有し、複数のサービス処理プログラム・データ５２Ａも含んでいる。ＣＰＵ３１は、第２受信プロセス５３Ａ１を実行することで図１３に示す第２受信部１３として動作する。また、ＣＰＵ３１は、検証プロセス５３Ａ２を実行することで図１３に示す検証部１４として動作する。また、ＣＰＵ３１は、決定プロセス５３Ａ３を実行することで図１３に示す決定部１５として動作する。さらに、ＣＰＵ３１は、制御プロセス５３Ａ４を実行することで図１３に示す制御部１６として動作する。これにより、サービス提供サーバプログラム５３を実行したサーバコンピュータ２９Ｂが、図１３に示すサービス提供サーバ５０Ｂとして機能することになる。
【０１１４】
次に本第２実施形態の作用として、まず図１６を参照し、アプリ配信サーバ３０Ａで実行されるアプリ配信処理を説明する。第１実施形態で説明したアプリ配信処理(図１０)では、ステップ２１４Ａにおいて、サービス要求ステップにアクセス先として中継サーバ４０のＵＲＬを設定したアプリを端末２０に配信していた。これに対し、本第２実施形態のアプリ配信処理は、ステップ２１４Ｂにおいて、サービス要求ステップにアクセス先として、要求するサービスの種類に対応するサービス種ＵＲＬを設定したアプリを端末２０に配信する点でのみ相違している。
【０１１５】
次に、図１７を参照し、本第２実施形態のサービス提供サーバ５０Ｂで実行されるサービス要求受信時処理について、第１実施形態で説明したサービス要求中継処理(図１１)と異なる部分についてのみ説明する。第１実施形態で説明したサービス要求中継処理(図１１)では、ステップ３０８において、制御部１６が、端末２０から受信したサービス要求を、決定部１５によって取得されたサービスＵＲＬへ転送していた。
【０１１６】
本第２実施形態のサービス要求受信時処理は、上記のステップ３０８に代えて、ステップ３１０において、制御部１６が、端末２０から受信したサービス要求を、決定部１５によって取得されたサービスＵＲＬへ転送する。但し、本第２実施形態において、ステップ３１０のサービス要求の転送先は、同一のサービス提供サーバプログラム５３の記憶部１９に記憶されているサービス処理プログラム・データ５２Ａである。従って、上記のサービス要求の転送は、第１実施形態におけるＨＴＴＰリクエストの送信とは異なり、決定部１５が取得したサービスＵＲＬが割り当てられたサービス処理プログラム・データ５２Ａを呼び出す処理によって実現できる。
【０１１７】
上記のサービス要求の転送により、次のステップ３１２において、決定部１５が取得したサービスＵＲＬが割り当てられたサービス処理プログラム・データ５２Ａに含まれるプログラムが実行され、サービス処理部５２Ｂにより要求されたサービスが処理される。
【０１１８】
次に、図１８を参照し、本第２実施形態における処理全体の流れのうち、第１実施形態で説明した処理全体の流れ(図１２)と異なる部分、すなわち端末２０におけるアプリの実行以降の流れを説明する。
【０１１９】
アプリ配信サーバ３０Ａから端末２０に配信されたアプリは、一旦メモリ６２に記憶された後、端末２０のユーザからの指示入力等に応じて適宜実行される。前述のように、本第２実施形態では、個々のアプリの中のサービス要求ステップに、アクセス先として、要求するサービスの種類に対応するサービス種ＵＲＬ(図１８に示す例では「ＵＲＬα」「ＵＲＬβ」)が設定されている。このため、端末２０によって実行中のアプリの中のサービス要求ステップが実行されると、送信部２１により、サービス要求が、アプリＩＤおよびチケット情報７２と共に、要求するサービスの種類に対応するサービス提供サーバ５０Ｂへ送信される。なお、本第２実施形態において、サービス提供サーバ５０Ｂは第２のアクセス先の一例であり、サービス種ＵＲＬ(ＵＲＬα,ＵＲＬβ)は第２のアクセス先を示すアクセス先情報の一例である。
【０１２０】
サービス提供サーバ５０Ｂの第２受信部１３は、端末２０から送信されたサービス要求、アプリＩＤおよびチケット情報７２を受信する。サービス提供サーバ５０Ｂの検証部１４は、端末２０から受信したアプリＩＤとチケット情報７２の組み合わせが振り分けテーブル８６Ａに登録されているか否か検証する。アプリＩＤとチケット情報７２の組み合わせが振り分けテーブル８６Ａに登録されていた場合、サービス提供サーバ５０Ｂの決定部１５は、受信したアプリＩＤとチケット情報７２の組み合わせに対応するサービスＵＲＬを振り分けテーブル８６Ａから取得する。そして、サービス提供サーバ５０Ｂの制御部１６は、端末２０から受信したサービス要求をサービスＵＲＬへ転送する。
【０１２１】
上記のサービス要求の転送により、事前に設定されたサービス種ＵＲＬに対応する種類のサービスを提供し、かつアプリＩＤおよびチケット情報７２と対応するサービス処理プログラム・データ５２Ａがアクセスされる。これにより、アクセスされたサービス処理プログラム・データ５２Ａに含まれるプログラムが実行されることで、サービス処理部５２Ｂにより、要求されたサービスを端末２０に提供する処理が行われる。
【０１２２】
このように、本第２実施形態についても、複数のサービス処理プログラム・データ５２Ａに互いに異なるサービスＵＲＬが割り当てられている。また、端末２０から受信したチケット情報が示す端末２０の状況に対応するサービス処理プログラム・データ５２ＡのサービスＵＲＬを決定する。そして、アプリに含まれるサービス要求ステップが端末２０で実行されることで端末２０から送信されたサービス要求を、決定したサービスＵＲＬへ転送する。これにより、端末の状況を検知してアクセス先または処理内容を切り替える機能をアプリおよびサービス処理プログラム・データ５２Ａに搭載する必要がなくなり、提供するサービスを端末の状況に応じて切り替えることを簡易な構成で実現することができる。また、アプリおよびサービス処理プログラム・データ５２Ａの開発工数およびコストも削減できる。
【０１２３】
また、本第２実施形態では、複数のサービス処理プログラム・データ５２Ａは、提供するサービスの種類と対応する端末の状況の少なくとも一方が互いに相違されている。また、要求するサービスの種類に対応するサービス提供サーバ５０Ｂをサービス要求ステップにアクセス先として設定したアプリを端末２０に送信する。そして、端末２０からサービス提供サーバ５０Ｂ宛てのサービス要求、チケット情報およびアプリＩＤを受信した場合に、受信した情報に基づきサービスＵＲＬを決定する。
【０１２４】
この場合、アプリに含まれるサービス要求ステップにアクセス先としてサービス種ＵＲＬを設定する必要があるので、アクセス先を一律に中継サーバに設定できる第１実施形態と比較すると、アプリの開発負荷は増大する。但し、アプリおよび端末２０の状況が一定であっても、アプリにサービス要求ステップを複数記述し、かつ各ステップにアクセス先として設定するサービス種ＵＲＬを相違させることで、複数種のサービスの提供を受けることが可能となる。従って、アプリおよび端末２０の状況が一定の状態で、複数のサービスを利用できることで、より多様な処理を実現することができる。
【０１２５】
なお、その他の作用効果は第１実施形態と同じであるので、記載を省略する。
【０１２６】
〔第３実施形態〕
次に開示の技術の第３実施形態について説明する。なお、第２実施形態と同一の部分には同一の符号を付し、説明を省略する。
【０１２７】
図１９には、本第３実施形態に係るアクセス制御装置１０Ｃおよび複数の端末２０が示されている。アクセス制御装置１０Ｃは、第２実施形態で説明したアクセス制御装置１０Ｂと比較して、アプリ配信サーバ３０Ａに代えてアプリ配信サーバ３０Ｂが設けられている点で相違している。アプリ配信サーバ３０Ｂは、第１受信部１１、決定部１５および制御部１６を含んでおり、記憶部１７には振り分けテーブル８６Ａが記憶されている。なお、決定部１５および制御部１６の機能は第２実施形態とほぼ同じであるので、説明を省略する。
【０１２８】
また、本第３実施形態は、第２実施形態と比較して、サービス提供サーバ５０Ｂに代えて、対応するサービスの種類と対応する端末の状況の少なくとも一方が互いに異なる複数のサービス提供サーバ５０Ｃが設けられている点でも相違している。個々のサービス提供サーバ５０Ｃには、互いに異なるサービスＵＲＬが割り当てられている。個々のサービス提供サーバ５０Ｃの記憶部１９には、個々のサービス提供サーバ５０Ｃに対応する単一のサービス処理プログラム・データ５２Ａが各々記憶されている。また、個々のサービス提供サーバ５０Ｃは、第２受信部１３および検証部１４を含んでいる。
【０１２９】
また、本第３実施形態は、サービス提供サーバ５０Ｂの記憶部１９に、第１実施形態で説明した振り分けテーブル８６Ａに代えて、振り分けテーブル８６Ｂが記憶されている点でも第２実施形態と相違している。例として図２３に示すように、振り分けテーブル８６Ｂは、アプリＩＤおよび振り分けチケットが対応付けて登録されており、サービスＵＲＬが未登録となっている。
【０１３０】
上述したアクセス制御装置１０Ｃは、図２０に示すコンピュータ・システム９０Ｃに含まれるサーバコンピュータ２９Ｃによって実現することができる。サーバコンピュータ２９Ｃの記憶部３９には、アプリ配信サーバプログラム４１およびサービス提供サーバプログラム５４が各々記憶されている。
【０１３１】
サーバコンピュータ２９ＣのＣＰＵ３１は、アプリ配信サーバプログラム４１を記憶部４３から読み出してメモリ３２に展開し、アプリ配信サーバプログラム４１が有するプロセスを順次実行する。アプリ配信サーバプログラム４１は、第１受信プロセス４１Ａ１、決定プロセス４１Ａ２および制御プロセス４１Ａ３を有している。ＣＰＵ３１は、第１受信プロセス４１Ａ１を実行することで図１９に示す第１受信部１１として動作する。また、ＣＰＵ３１は、決定プロセス４１Ａ２を実行することで図１９に示す決定部１５として動作する。また、ＣＰＵ３１は、制御プロセス４１Ａ３を実行することで図１９に示す制御部１６として動作する。これにより、アプリ配信サーバプログラム４１を実行したサーバコンピュータ２９Ｃが、図１９に示すアプリ配信サーバ３０Ｂとして機能することになる。
【０１３２】
また、サーバコンピュータ２９ＣのＣＰＵ３１は、サービス提供サーバプログラム５４を記憶部４３から読み出してメモリ３２に展開し、サービス提供サーバプログラム５４が有するプロセスを順次実行する。サービス提供サーバプログラム５４は、第２受信プロセス５４Ａ１および検証プロセス５４Ａ２を有し、複数のサービス処理プログラム・データ５２Ａも含んでいる。ＣＰＵ３１は、第２受信プロセス５４Ａ１を実行することで図１９に示す第２受信部１３として動作する。また、ＣＰＵ３１は、検証プロセス５４Ａ２を実行することで図１９に示す検証部１４として動作する。これにより、サービス提供サーバプログラム５４を実行したサーバコンピュータ２９Ｃが、図１９に示すサービス提供サーバ５０Ｃとして機能することになる。
【０１３３】
次に本第３実施形態の作用として、まず図２１を参照し、アプリ配信サーバ３０Ｂで実行されるアプリ配信処理について、第２実施形態で説明したアプリ配信処理(図１６)と異なる部分のみ説明する。本第３実施形態のアプリ配信処理は、第２実施形態のアプリ配信処理のステップ２１４Ｂに代えて、以下で説明するステップ２１３,２１５,２１９の処理を行う。
【０１３４】
すなわち、ステップ２１３において、決定部１５は、端末２０から受信したアプリＩＤとチケット情報７２の組み合わせに対応するサービスＵＲＬを、アプリ配信サーバ３０Ｂの記憶部１７に記憶されている振り分けテーブル８６Ａから取得する。次のステップ２１５において、制御部１６は、まずステップ２１０又はステップ２１２で取得されたアプリから、当該アプリに含まれているサービス要求ステップを抽出する。そして、制御部１６は、アプリから抽出したサービス要求ステップに、サービス要求を送信する際のアクセス先として、決定部１５によって取得されたサービスＵＲＬを設定する。そして、次のステップ２１９において、制御部１６は、サービス要求ステップにサービスＵＲＬを設定したアプリを、アプリＩＤと共に送信元の端末２０に送信する。
【０１３５】
次に、図２２を参照し、本第３実施形態のサービス提供サーバ５０Ｃで実行されるサービス要求受信時処理について、第２実施形態で説明したサービス要求中継処理(図１７)と異なる部分についてのみ説明する。第２実施形態で説明したサービス要求中継処理(図１７)では、ステップ３０６Ａで決定部１５がサービスＵＲＬを取得し、ステップ３１０で制御部１６がサービス要求をサービスＵＲＬへ転送していた。
【０１３６】
これに対し、本第３実施形態のサービス要求受信時処理は、上記のステップ３０６Ａ,３１０に代えて、ステップ３１１において、記憶部１９に記憶されている単一のサービス処理プログラム・データ５２Ａに含まれるプログラムが実行される。これにより、端末２０から要求されたサービスが処理される。
【０１３７】
次に、図２３を参照し、本第３実施形態における処理全体の流れを説明する。アプリ配信サーバ３０Ｂは、端末２０からチェックインに相当する状況情報を受信すると、端末２０の状況に対応するチケット情報７２を端末に送信する。また、アプリ配信サーバ３０Ｂの決定部１５は、端末２０から受信したアプリＩＤとチケット情報７２の組み合わせに対応するサービスＵＲＬを振り分けテーブル８６Ａから取得する。
【０１３８】
そして、アプリ配信サーバ３０Ｂの制御部１６は、端末２０に配信するアプリの中のサービス要求ステップに、決定部１５が取得したサービスＵＲＬをアクセス先として設定し、端末２０に配信する。なお、図２３では制御部１６が設定したサービスＵＲＬを「ＵＲＬα/ｘ」「ＵＲＬβ/ｙ」と表記して示す。なお、制御部１６による上記処理は「決定したアクセス先を示すアクセス先情報をサービス要求の送信先に設定したアプリケーション・ソフトウェアを端末に送信する」ことの一例である。
【０１３９】
アプリ配信サーバ３０Ｂから端末２０に配信されたアプリは、一旦メモリ６２に記憶された後、端末２０のユーザからの指示入力等に応じて適宜実行される。本第３実施形態では、個々のアプリの中のサービス要求ステップに、アクセス先としてサービスＵＲＬが設定されている。このため、端末２０によって実行中のアプリの中のサービス要求ステップが実行されると、送信部２１により、サービス要求が、実行中のアプリおよび端末２０の状況に対応するサービスを提供するサービス提供サーバ５０Ｃへ送信される。
【０１４０】
サービス提供サーバ５０Ｃの第２受信部１３は、端末２０から送信されたサービス要求、アプリＩＤおよびチケット情報７２を受信する。サービス提供サーバ５０Ｃの検証部１４は、端末２０から受信したアプリＩＤとチケット情報７２の組み合わせが振り分けテーブル８６Ｂに登録されているか否か検証する。受信したアプリＩＤとチケット情報７２の組み合わせが振り分けテーブル８６Ｂに登録されていた場合は、サービス処理プログラム・データ５２Ａに含まれるプログラムが実行される。これにより、端末２０から要求されたサービスを端末２０に提供する処理がサービス処理部５２Ｂによって行われる。
【０１４１】
このように、本第３実施形態についても、複数のサービス処理プログラム・データ５２Ａ(サービス提供サーバ５０Ｃ)に互いに異なるサービスＵＲＬが割り当てられている。また、端末２０から受信したチケット情報が示す端末２０の状況に対応するサービス処理プログラム・データ５２ＡのサービスＵＲＬを決定する。そして、アプリに含まれるサービス要求ステップにアクセス先として決定したサービスＵＲＬを設定し、当該アプリを端末２０へ配信する。これにより、端末の状況を検知してアクセス先または処理内容を切り替える機能をアプリおよびサービス処理プログラム・データ５２Ａに搭載する必要がなくなり、提供するサービスを端末の状況に応じて切り替えることを簡易な構成で実現することができる。また、アプリおよびサービス処理プログラム・データ５２Ａの開発工数およびコストも削減できる。なお、その他の作用効果は第２実施形態と同じであるので、記載を省略する。
【０１４２】
〔第４実施形態〕
上述した各実施形態において、同一のアプリが複数の状況に関連付けられ、同時に前記複数の状況が成立し得る場合、各状況で前記アプリのインスタンス(スレッドともいう)が独立して動作するため、アプリの使い勝手が悪い場合がある。例えば、予定表を表示するアプリ(以下「予定表アプリ」という)が、「先生」の状況および「教室」の状況で各々配信されて実行され、一方が先生の予定を取得して表示し、他方が教室の予定を取得して表示する場合が挙げられる。この場合、アプリの双方のインスタンスは、何れも、先生の予定と教室の予定とを重ねて表示することはできない。なお、以下では「先生」の状況を「先生状況」といい、「教室」の状況を「教室状況」という。
【０１４３】
上記の問題は、或るアプリのインスタンスが、同一のアプリの他のインスタンスに割り当てられた共用領域を使用することができれば解決できる。例えば、教室状況に対応する予定表アプリのインスタンスが、予定表アプリのインスタンス間の共用領域に教室の予定を書き出す。一方、先生状況に対応する予定表アプリのインスタンスが共用領域から前記教室の予定を読み込めば、先生の予定に重ねて表示することが可能となる。
【０１４４】
また、異なる状況で起動された同一のアプリのインスタンス間で共用する場合とは別に、同一の状況で起動された異なるアプリのインスタンス間で共用したい場合や、更に、異なる状況で起動された異なるアプリのインスタンス間で共用したい場合も考えられる。例えば、教室状況に対応する予定表アプリのインスタンスが、教室の予定を教室状況用の共用領域に書き出し、教室状況に対応するプロジェクタアプリが、その共用領域から教室の予定を読み込んで表示する場合が挙げられる。
【０１４５】
本第４実施形態では、アプリからサービス要求が送信される際に、サービスの範囲を規定する共用キーを同時に送信させることで、インスタンス間の共用を実現する態様を説明する。なお、以下の第４実施形態において、第１実施形態と同一の部分には同一の符号を付し、説明を省略する。
【０１４６】
図２４には、第４実施形態に係るアクセス制御装置１０Ｄが示されている。図２４に示すように、第４実施形態のアクセス制御装置１０Ｄは、第１実施形態で説明したアクセス制御装置１０Ａと比較して、アプリ配信サーバ３０Ａに代えてアプリ配信サーバ３０Ｃが設けられている点で相違している。アプリ配信サーバ３０Ｃはアプリ配信サーバ３０Ａと比較して、アプリ管理テーブル８４Ａに代えてアプリ管理テーブル８４Ｃが記憶部１９に記憶されている点で相違している。
【０１４７】
図２６に示すように、アプリ管理テーブル８４Ｃは、アプリＩＤとアプリ(のプログラム本体)とが対応付けて登録されている点ではアプリ管理テーブル８４Ａと同じである。但し、アプリ管理テーブル８４Ｃに登録されている個々のアプリ(のプログラム本体)がアプリ管理テーブル８４Ａと相違している。すなわち、個々のアプリのサービス要求ステップに、要求するサービスの名称を示すサービス名と、要求するサービスの範囲を規定する共有キーが各々設定されている。本第４実施形態では、端末２０によってアプリの中のサービス要求ステップが実行されると、送信部２１により、アプリＩＤ、チケット情報７２、サービス名および共用キーを付加したサービス要求が送信される。
【０１４８】
図２６に示す例では、アプリＡの中に、"予定表サービス/*-this-*"の文字列を記述した行と、"共用ストレージサービス/*-this-*"の文字列を記述した行が含まれている。これらの各行はサービス要求ステップに相当する。また、上記文字列のうちの"予定表サービス/"または"共用ストレージサービス/"の部分がサービス名に相当する。また、上記文字列のうちの"*-this-*"の部分が共有キーに相当する。
【０１４９】
本第４実施形態において、共有キーは、区切り記号"-"で区切られた３つの変数(第１変数〜第３変数)を含んでいる。共有キーのうち、２番目の第２変数はアプリに関するサービス範囲を規定し、３番目の第３変数は端末２０の状況に関するサービス範囲を規定している。また、本第４実施形態において、共有キーの第１変数〜第３変数がとり得る値は、サービス範囲を制限しないことを表す"*"か、サービス範囲を現在の値に制限することを表す"this"である。
【０１５０】
例えば、「教室状況」の端末２０で実行されている予定表アプリから、端末２０に予定表を配信する予定表サービスに対し、共用キー"*-this-this"が付加されたサービス要求が送信された場合を考える。この場合、アプリに関するサービス範囲を規定する第２変数が"this"であるので、アプリに関するサービス範囲を現在の値、すなわち予定表アプリに制限することを意味する。また、端末２０の状況に関するサービス範囲を規定する第３変数も"this"であるので、状況に関するサービス範囲を現在の値、すなわち「教室状況」に制限することを意味する。従って、この場合、予定表サービスは、予定表アプリかつ「教室状況」をサービス範囲とするサービスとして、教室の予定を端末２０に配信するサービスを行うことになる。
【０１５１】
また、例えば「教室状況」の端末２０で実行されている予定表アプリから、端末２０に共用領域を提供する共用ストレージサービスに対し、共用キー"*-this-*"が付加されたサービス要求が送信された場合を考える。この場合、アプリに関するサービス範囲を規定する第２変数が"this"であるので、アプリに関するサービス範囲を現在の値、すなわち予定表アプリに制限することを意味する。また、端末２０の状況に関するサービス範囲を規定する第３変数は"*"であるので、状況に関するサービス範囲を制限しないことを意味する。従って、この場合、共用ストレージサービスは、予定表アプリをサービス範囲とするサービスとして、予定表アプリであれば端末２０の状況に拘わらずアクセス可能な共用領域を提供するサービスを行うことになる。
【０１５２】
なお、本第４実施形態では、１番目の第１変数については特に規定していないが、例えば端末に関するサービス範囲を規定する変数として用いてもよい。この場合、第１変数が"this"であればサービス範囲が自端末２０に制限され、第１変数が"*"であれば端末２０に関してのサービス範囲の制限が解除される。また、第１変数は、第３変数とは括りの異なる状況に関するサービス範囲を規定する変数として用いてもよい。例えば、第１変数を、管理対象の学校の屋内か屋外かを表す状況に対応させることを考える。この場合、第１変数が"this"で自端末２０が屋内に位置していれば、サービス範囲が屋内に位置している端末２０に制限され、第１変数が"this"で自端末２０が屋外に位置していれば、サービス範囲が屋外に位置している端末２０に制限される。また、第１変数が"*"であれば端末２０が屋内に位置しているか屋外に位置しているかに応じたサービス範囲の制限が解除される。
【０１５３】
なお、上述した共有キーにおいて、各変数がとり得る値を三値以上にしてもよいし、変数の数を増減させてもよい。上述した共有キーはサービス範囲情報の一例であり、サービス範囲を規定できる情報であれば、サービス範囲情報として適用可能である。
【０１５４】
個々のアプリの開発者は、開発するアプリのサービス要求ステップにサービス名と共用キーを記述しておくだけで、端末２０が所望のサービス範囲のサービスの提供を受けるようにすることができる。このため、サービス要求ステップに、所望のサービス範囲のサービスを提供するサービス処理プログラム・データ５２ＡのＵＲＬ等を記述する場合と比較して、アプリの開発に要する工数、コストが削減される。
【０１５５】
また、第４実施形態のアクセス制御装置１０Ｄは、第１実施形態で説明したアクセス制御装置１０Ａと比較して、中継サーバ４０に代えて名前解決サーバ４２が設けられている点でも相違している。名前解決サーバ４２は、中継サーバ４０と同様に、第２受信部１３、検証部１４、決定部１５、制御部１６および記憶部１８を含んでいるが、振り分けテーブル８６Ａに代えて振り分けテーブル８６Ｃが記憶部１９に記憶されている点で相違している。
【０１５６】
図２７に示すように、振り分けテーブル８６Ｃは、アプリＩＤ、振り分けチケットおよびサービスＵＲＬに加えて、サービス名および共用キーが対応付けられて記憶されている。本第４実施形態において、サービス提供サーバ５０Ａの記憶部１９に記憶されている個々のサービス処理プログラム・データ５２Ａは、提供するサービスの種類、対応する端末２０の状況およびサービス範囲の少なくとも１つが互いに相違している。そして、記憶部１９の記憶されている個々のサービス処理プログラム・データ５２Ａには、第１実施形態と同様に、互いに異なるサービスＵＲＬが割り当てられている。振り分けテーブル８６Ｃは、サービスの種類および対応する端末２０の状況が同一で、かつサービス範囲が異なるサービス処理プログラム・データ５２Ａを区別するために、サービス名および共用キーの項目が追加されている。
【０１５７】
上述したアクセス制御装置１０Ｄは、図２５に示すコンピュータ・システム９０Ｄに含まれるサーバコンピュータ２９Ｄによって実現することができる。サーバコンピュータ２９Ｄの記憶部３９には、アプリ配信サーバプログラム３３Ａ、名前解決サーバプログラム４４Ａおよびサービス提供サーバプログラム５２が各々記憶されている。なお、名前解決サーバプログラム４４Ａはサーバコンピュータ２９Ｄを名前解決サーバ４２として機能させるためのプログラムである。
【０１５８】
サーバコンピュータ２９ＤのＣＰＵ３１は、名前解決サーバプログラム４４Ａを記憶部４３から読み出してメモリ３２に展開し、名前解決サーバプログラム４４Ａが有するプロセスを順次実行する。名前解決サーバプログラム４４Ａは、第２受信プロセス４４Ａ１、検証プロセス４４Ａ２、決定プロセス４４Ａ３および制御プロセス４４Ａ４を有している。ＣＰＵ３１は、第２受信プロセス４４Ａ１を実行することで図２４に示す第２受信部１３として動作する。また、ＣＰＵ３１は、検証プロセス４４Ａ２を実行することで図２４に示す検証部１４として動作する。また、ＣＰＵ３１は、決定プロセス４４Ａ３を実行することで図２４に示す決定部１５として動作する。さらに、ＣＰＵ３１は、制御プロセス４４Ａ４を実行することで図２４に示す制御部１６として動作する。これにより、名前解決サーバプログラム４４Ａを実行したサーバコンピュータ２９Ｄが、図２４に示す名前解決サーバ４２として機能することになる。
【０１５９】
次に、本第４実施形態の作用として、まず図２８を参照し、名前解決サーバ４２によって実行されるサービス要求受信時処理について、第１実施形態で説明したサービス要求中継処理(図１１)と異なる部分を説明する。
【０１６０】
サービス要求受信時処理のステップ１５０Ｂにおいて、第２受信部１３は、アプリＩＤ、チケット情報７２、サービス名および共用キーが付加されたサービス要求を何れかの端末２０から受信するまで待機する。何れかの端末２０から上記の情報を受信した場合、第２受信部１３は、受信したアプリＩＤ、チケット情報７２、サービス名および共用キーを検証部１４へ引き渡してステップ１５２Ｂに移行する。
【０１６１】
ステップ１５２Ｂにおいて、検証部１４は、第２受信部１３から引き渡されたアプリＩＤ、チケット情報７２、サービス名および共用キーの組み合わせが振り分けテーブル８６Ｃに登録されているか否か検証する。次のステップ１５６において、検証部１４は、受信したサービス要求が正当なサービス要求か否かを判定し、肯定判定となった場合はステップ３０６Ｂに移行する。
【０１６２】
ステップ３０６Ｂにおいて、決定部１５は、受信したアプリＩＤ、チケット情報７２、サービス名および共用キーの組み合わせに対応するサービスＵＲＬを振り分けテーブル８６Ａから読み出すことにより取得する。そして、次のステップ３０８において、制御部１６は、端末２０から受信したサービス要求を、決定部１５によって取得されたサービスＵＲＬへ転送する。
【０１６３】
名前解決サーバ４２によって転送(中継)された上記のサービス要求を受信したサービス提供サーバ５０Ａでは、上記のサービスＵＲＬが割り当てられたサービス処理プログラム・データ５２Ａがアクセスされる。これにより、アクセスされたサービス処理プログラム・データ５２Ａに含まれるプログラムが実行される。そして、サービス処理部５２Ｂにより、端末２０から送信されたアプリＩＤ、チケット情報７２、サービス名および共用キーに対応するサービスを端末２０に提供する処理が行われる。
【０１６４】
次に、図２９を参照して、本第４実施形態における処理全体の流れを説明する。なお、何れかの端末２０が何れかの場所にチェックインし、アプリ配信サーバ３０Ｃからアプリが配信されるまでの各種処理の流れは、第１実施形態(図１２)と同様であるので、説明を省略する。
【０１６５】
アプリ配信サーバ３０Ｃから端末２０に配信されたアプリは、一旦メモリ６２に記憶された後、端末２０のユーザからの指示入力等に応じて適宜実行される。前述のように、本第４実施形態では、個々のアプリの中のサービス要求ステップに、アプリ名と共用キーが記述されている。このため、端末２０によってアプリの中のサービス要求ステップが実行されると、送信部２１により、アプリＩＤ、チケット情報、サービス名および共用キーを付加したサービス要求が送信される。
【０１６６】
なお、本実施形態ではサービス要求がＨＴＴＰリクエストであるので、上記のサービス要求は、プロトコル上エラーにならないアクセス先が設定されていれば、名前解決のために名前解決サーバ４２で受信される。
【０１６７】
端末２０から上記サービス要求を受信すると、名前解決サーバ４２は、検証部１４により、該サービス要求と共に受信したアプリＩＤ、チケット情報、サービス名および共用キーの組み合わせが振り分けテーブル８６Ｃに存在する場合に、検証ＯＫと判定する。検証部１４により検証ＯＫと判定されると、名前解決サーバ４２は、決定部１５により、受信したアプリＩＤ、チケット情報、サービス名および共用キーの組み合わせに対応するサービスＵＲＬを振り分けテーブル８６Ｃから取得する。そして、制御部１６は、端末２０から受信したサービス要求を取得したサービスＵＲＬへ転送する。これにより、サービス提供サーバ５０Ａにおいて、端末２０から送信されたアプリＩＤ、チケット情報７２、サービス名および共用キーに対応するサービスを端末２０に提供する処理が行われる。
【０１６８】
次に、図３０〜図３２を参照し、本第４実施形態でのアプリを介してのサービスの利用の流れの一例を説明する。
【０１６９】
図３０には、図の上側に示す第１の端末２０は、教室状況および先生状況で予定表アプリが各々配信されてインスタンスが実行され、図の下側に示す第２の端末２０は、教室状況でのみ予定表アプリが配信されてインスタンスが実行されている状況を示す。この状況としては、例えば、第１の端末２０のユーザは先生で教室内に在室しており、第２の端末２０のユーザは生徒で先生と同じ教室内に在室している状況が想定される。
【０１７０】
ここで、第１の端末２０のユーザ(先生)が、在室している教室の予定の確認を所望した場合、教室状況に対応する予定表アプリのインスタンスに対して予定表の取得を指示する。この指示により、教室状況に対応する予定表アプリのインスタンスからは、予定表アプリのアプリＩＤ、教室状況を示すチケット情報、予定表サービスのサービス名、共用キー"*-this-this"を含むサービス要求が送信される。上記の共用キーが示すサービス範囲は、「アプリ＝予定表アプリ」かつ「状況＝教室状況」である。このため、上記のサービス要求は、名前解決サーバ４２により、教室状況の端末２０の予定表アプリに対して予定表を配信するサービス、すなわち教室の予定表を配信するサービスを提供するサービス処理プログラム・データ５２Ａに転送される。そして、サービス提供サーバ５０Ａから第１の端末２０の教室状況に対応する予定表アプリのインスタンスに対して教室の予定が配信される。
【０１７１】
なお、第２の端末２０のユーザ(生徒)も、在室している教室の予定の確認を所望した場合、教室状況に対応する予定表アプリのインスタンスに対して予定表の取得を指示する。この指示により、上記と同様に、教室状況に対応する予定表アプリのインスタンスからは、予定表アプリのアプリＩＤ、教室状況を示すチケット情報、予定表サービスのサービス名、共用キー"*-this-this"を含むサービス要求が送信される。そして、このサービス要求は、名前解決サーバ４２により、教室の予定表を配信するサービスを提供する、上記と同じサービス処理プログラム・データ５２Ａに転送される。そして、サービス提供サーバ５０Ａから第１の端末２０に配信された教室の予定が、サービス提供サーバ５０Ａから第２の端末２０にも配信される。
【０１７２】
一方、第１の端末２０のユーザ(先生)が、先生自身の予定の確認を所望した場合、先生状況に対応する予定表アプリのインスタンスに対して予定表の取得を指示する。この指示により、先生状況に対応する予定表アプリのインスタンスからは、予定表アプリのアプリＩＤ、先生状況を示すチケット情報、予定表サービスのサービス名、共用キー"*-this-this"を含むサービス要求が送信される。上記の共用キーが示すサービス範囲は、「アプリ＝予定表アプリ」かつ「状況＝先生状況」である。このため、上記のサービス要求は、名前解決サーバ４２により、先生状況の端末２０の予定表アプリに対して予定表を配信するサービス、すなわち先生の予定表を配信するサービスを提供するサービス処理プログラム・データ５２Ａに転送される。そして、サービス提供サーバ５０Ａから第１の端末２０の先生状況に対応する予定表アプリのインスタンスに対して先生の予定が配信される。
【０１７３】
先に説明したように、この場合、第１の端末２０の教室状況に対応する予定表アプリのインスタンスは教室の予定のみを取得しており、第１の端末２０の先生状況に対応する予定表アプリのインスタンスは先生の予定のみを取得している。このため、予定表アプリの双方のインスタンスは、何れも、先生の予定と教室の予定とを重ねて表示することはできない。
【０１７４】
これに対し、本第４実施形態では、例えば、図３１に示すサービスの利用の流れによって上記の問題を解消できる。すなわち、第１の端末２０のユーザ(先生)は、予定表アプリの一方のインスタンス(ここでは教室状況に対応するインスタンスとする)に対して、同一アプリのインスタンス間の共用領域への教室の予定の書き出しを指示する。この指示により、教室状況に対応する予定表アプリのインスタンスからは、予定表アプリのアプリＩＤ、教室状況を示すチケット情報、共用ストレージサービスのサービス名、共用キー"*-this-*"を含むサービス要求が送信される。上記の共用キーが示すサービス範囲は、「アプリ＝予定表アプリ」かつ「状況＝制限なし」である。このため、上記のサービス要求は、名前解決サーバ４２により、予定表アプリに対して端末２０の状況に拘わらず共用領域を割り当てるサービスを提供するサービス処理プログラム・データ５２Ａに転送される。そして、サービス提供サーバ５０Ａから第１の端末２０の教室状況に対応する予定表アプリのインスタンスに対して予定表アプリのインスタンス間で共用できる共用領域が割り当てされる。これにより、教室状況に対応する予定表アプリのインスタンスは、ユーザからの指示に従い、先に取得して保持している教室の予定を、割り当てられた共用領域に書き出す処理を行う。
【０１７５】
続いて、第１の端末２０のユーザ(先生)は、予定表アプリの他方のインスタンス(ここでは先生状況に対応するインスタンス)に対して、同一アプリのインスタンス間の共用領域からの教室の予定の読み込みを指示する。この指示により、先生状況に対応する予定表アプリのインスタンスからは、予定表アプリのアプリＩＤ、先生状況を示すチケット情報、共用ストレージサービスのサービス名、共用キー"*-this-*"を含むサービス要求が送信される。上記の共用キーが示すサービス範囲は、「アプリ＝予定表アプリ」かつ「状況＝制限なし」である。このため、上記のサービス要求は、名前解決サーバ４２により、予定表アプリに対して端末２０の状況に拘わらず共用領域を割り当てるサービスを提供するサービス処理プログラム・データ５２Ａに転送される。そして、サービス提供サーバ５０Ａから第１の端末２０の先生状況に対応する予定表アプリのインスタンスに対し、教室状況に対応する予定表アプリのインスタンスと同一の共用領域が割り当てされる。これにより、先生状況に対応する予定表アプリのインスタンスは、ユーザからの指示に従い、割り当てられた共用領域に書き込まれている教室の予定を読み出す処理を行う。
【０１７６】
上述したサービスの利用の流れにより、先生状況に対応する予定表アプリのインスタンスは、先生の予定表に加えて、教室の予定表も取得できたので、先生の予定と教室の予定とを重ねて表示することが可能になる。
【０１７７】
続いて図３２を参照し、本第４実施形態において、異なるアプリのインスタンスの間で情報を送受する場合のサービスの利用の流れの一例を説明する。図３２には、端末２０において、教室状況で予定表アプリおよびプロジェクタアプリが各々配信されてインスタンスが実行されている状況を示す。なお、教室状況に対応する予定表アプリを介して教室の予定を取得する場合の処理の流れは、先に説明したので記載を省略する。ここで、教室状況に対応する予定表アプリを介して取得された教室の予定を、教室に設置したプロジェクタに投影したい場合は、図３２に示すサービスの利用の流れによって実現できる。
【０１７８】
すなわち、端末２０のユーザは、教室状況に対応する予定表アプリのインスタンスに対して、同じ教室状況のアプリのインスタンス間の共用領域への教室の予定の書き出しを指示する。この指示により、教室状況に対応する予定表アプリのインスタンスからは、予定表アプリのアプリＩＤ、教室状況を示すチケット情報、共用ストレージサービスのサービス名、共用キー"*-*-this"を含むサービス要求が送信される。上記の共用キーが示すサービス範囲は、「アプリ＝制限なし」かつ「状況＝教室状況」である。このため、上記のサービス要求は、名前解決サーバ４２により、教室状況の端末２０のアプリに対してアプリの種類に対して拘わらず共用領域を割り当てるサービスを提供するサービス処理プログラム・データ５２Ａに転送される。そして、サービス提供サーバ５０Ａから端末２０の教室状況に対応する予定表アプリのインスタンスに対して教室状況の端末２０のアプリのインスタンス間で共用できる共用領域が割り当てされる。これにより、教室状況に対応する予定表アプリのインスタンスは、ユーザからの指示に従い、先に取得して保持している教室の予定を、割り当てられた共用領域に書き出す処理を行う。
【０１７９】
続いて、第１の端末２０のユーザ(先生)は、教室状況に対応するプロジェクタアプリのインスタンスに対し、教室状況の端末２０のアプリのインスタンス間の共用領域からの教室の予定の読み込みを指示する。この指示により、教室状況に対応するプロジェクタアプリのインスタンスからは、プロジェクタアプリのアプリＩＤ、教室状況を示すチケット情報、共用ストレージサービスのサービス名、共用キー"*-*-this"を含むサービス要求が送信される。上記の共用キーが示すサービス範囲は、「アプリ＝制限なし」かつ「状況＝教室状況」である。このため、上記のサービス要求は、名前解決サーバ４２により、教室状況の端末２０のアプリに対してアプリの種類に拘わらず共用領域を割り当てるサービスを提供するサービス処理プログラム・データ５２Ａに転送される。そして、サービス提供サーバ５０Ａから端末２０の教室状況に対応するプロジェクタアプリのインスタンスに対し、教室状況に対応する予定表アプリのインスタンスと同一の共用領域が割り当てされる。これにより、教室状況に対応するプロジェクタアプリのインスタンスは、ユーザからの指示に従い、割り当てられた共用領域に書き込まれている教室の予定を読み出す処理を行う。
【０１８０】
上述したサービスの利用の流れにより、教室状況に対応するプロジェクタアプリのインスタンスは、教室の予定表を取得できたるので、教室に設置されたプロジェクタに教室の予定を投影することが可能になる。
【０１８１】
このように、本第４実施形態では、アプリ管理テーブル８４Ｃに登録されているアプリが、サービス要求の送信時に、アプリＩＤ、チケット情報７２、サービス名および共用キーを含むサービス要求を送信するように設定されている。また、サービス提供サーバ５０Ａの記憶部１９に記憶されている個々のサービス処理プログラム・データ５２Ａは、提供するサービスの種類、対応する端末２０の状況およびサービス範囲の少なくとも１つが互いに相違している。また、個々のサービス処理プログラム・データ５２Ａは、異なるサービスＵＲＬが割り当てられている。名前解決サーバ４２は、端末２０から受信したサービス要求に付加されているアプリＩＤ、チケット情報７２、サービス名および共用キーの組み合わせに対応するサービスＵＲＬを取得する。そして、名前解決サーバ４２は、端末２０から受信したサービス要求を、取得したサービスＵＲＬへ転送する。これにより、第１〜第３実施形態に記載した効果に加えて、端末２０が所望のサービス範囲のサービスの提供を受けるようにするためのアプリの開発に要する工数、コストを削減できる。また、サービス処理プログラム・データ５２Ａの開発に要する工数、コストも削減できる。
【０１８２】
なお、第４実施形態では、共有キーで指定されたサービス範囲のサービスの一例として、指定されたサービス範囲に対応する共用範囲の共用領域を割り当てるサービスを説明したが、これに限定されるものではない。例えば、指定されたサービス範囲に対応する配信範囲に情報配信を行うサービス等、様々なサービスを適用可能である。
【０１８３】
また、上記では状況情報としてユーザ属性情報および場所情報を含む情報を適用した態様を説明したが、これに限定されるものではない。例えば、状況情報として、時刻を示す情報、温度を示す情報等の他の状況を示す情報を適用してもよい。この場合、端末２０は、時刻を示す情報や温度を示す情報を含む状況通知を、状況通知装置７０から受信してもよいし、端末２０に設けられたタイマや温度センサから取得してもよい。
【０１８４】
また、上記各実施形態では、アプリ配信サーバ３０Ａ〜３０Ｃによってアプリが端末２０に配信される態様を説明したが、これに限定されるものではなく、例えばアプリは端末２０に予め記憶(インストール)されていてもよい。
【０１８５】
また、上記各実施形態では、サービス提供サーバによってサービスが提供される態様を説明したが、これに限定されるものではなく、例えば、外部のサーバからサービスが提供されるようにしてもよい。
【０１８６】
また、上記各実施形態では、開示の技術に係るアクセス制御方法を、教育現場におけるコンピュータ・システムに適用した場合を説明したが、これに限定されるものではなく、例えば、会社や、ショッピングセンタ等の他の現場に適用してもよい。この場合、上記各実施形態における管理対象の教室に代えて、会社内における会議室や、ショッピングセンタ内における各店舗を適用すればよい。また、この場合、ユーザ属性情報に部長、課長、店長といった役職を示す情報を含めてもよい。
【０１８７】
また、上記では、各プログラムが記録媒体９６からＲ／Ｗ３６を介して記憶部３９に書き込まれる態様を説明したが、これに限定されるものではない。例えば、各プログラムを対応する装置に予め記憶（インストール）しておいてもよいし、各プログラムがネットワーク９２を介して外部装置からダウンロードされるようにしてもよい。
【０１８８】
また、上記では端末２０に提供されるサービスの一例としてＷｅｂサービスを説明したが、これに限定されるものではなく、アプリからアクセス可能なサービスであれば適用可能である。
【０１８９】
本明細書に記載された全ての文献、特許出願および技術規格は、個々の文献、特許出願および技術規格が参照により取り込まれることが具体的かつ個々に記された場合と同程度に、本明細書中に参照により取り込まれる。
【０１９０】
以上の各実施形態に関し、更に以下の付記を開示する。
（付記１）
互いにアクセス先が異なる複数のサービスのうち、端末から受信した状況情報が示す前記端末の状況に応じたサービスのアクセス先を決定し、
設定されたアクセス先にサービス要求を送信する機能を有するアプリケーション・ソフトウェアを実行している前記端末から送信された前記サービス要求により、前記決定したアクセス先のサービスがアクセスされるように制御する
処理をコンピュータに実行させるアクセス制御方法。
【０１９１】
（付記２）
前記端末から送信された前記状況情報および前記サービス要求を受信した場合に、受信した前記状況情報が示す前記端末の状況に応じたサービスのアクセス先を決定し、受信した前記サービス要求を前記決定したアクセス先に転送する付記１記載のアクセス制御方法。
【０１９２】
（付記３）
前記複数のサービスは、サービスの種類と対応する端末の状況の少なくとも一方が互いに相違しており、
サービスの種類に拘わらず前記サービス要求を受け付ける第１のアクセス先を示すアクセス先情報を設定した前記アプリケーション・ソフトウェアを前記端末に送信し、
前記端末から送信された前記第１のアクセス先宛ての前記サービス要求および前記状況情報を、前記アプリケーション・ソフトウェアの種類を表す情報と共に受信した場合に、受信した情報に基づきサービスのアクセス先を決定する付記２記載のアクセス制御方法。
【０１９３】
（付記４）
前記複数のサービスは、サービスの種類と対応する端末の状況の少なくとも一方が互いに相違しており、
特定種類のサービスについての前記サービス要求を受け付ける第２のアクセス先を示すアクセス先情報を設定した前記アプリケーション・ソフトウェアを前記端末に送信し、
前記端末から前記アプリケーション・ソフトウェアによる前記第２のアクセス先宛ての前記サービス要求および前記状況情報を受信した場合に、前記特定種類のサービスのうち前記状況情報が示す前記端末の状況に対応するサービスのアクセス先を決定する付記２記載のアクセス制御方法。
【０１９４】
（付記５）
前記決定したアクセス先を示すアクセス先情報をサービス要求の送信先に設定した前記アプリケーション・ソフトウェアを前記端末に送信する付記１記載のアクセス制御方法。
【０１９５】
（付記６）
位置および所持者の属性の少なくとも一方が検出された前記端末に対して、検出された前記位置および前記属性の少なくとも一方に応じたチケット情報を送信し、
前記端末から前記状況情報として前記チケット情報を受信する付記１〜付記５の何れか１項記載のアクセス制御方法。
【０１９６】
（付記７）
前記端末から受信した状況情報が示す前記端末の状況に応じて選択した前記アプリケーション・ソフトウェアを前記端末に送信する付記３〜付記５の何れか１項記載のアクセス制御方法。
【０１９７】
（付記８）
前記端末で実行されている前記アプリケーション・ソフトウェアが前記サービス要求を送信する状況を、前記アプリケーション・ソフトウェアの種類と対応付けて検証情報として記憶しておき、
前記端末から前記サービス要求および前記状況情報を、前記サービス要求および前記状況情報を送信した前記アプリケーション・ソフトウェアの種類を表す情報と共に受信した場合に、前記アプリケーション・ソフトウェアの種類および前記状況情報が示す状況を前記検証情報と照合することで、受信した前記サービス要求が適正か否かを検証する付記１〜付記７の何れか１項記載のアクセス制御方法。
【０１９８】
（付記９）
サービスを要求する際に、自アプリケーションの種類を示すアプリ情報、サービスの種類を示すサービス種情報、端末の状況を示す状況情報およびサービスの範囲を指定するサービス範囲情報を含むサービス要求を送信するように設定されたアプリケーション・ソフトウェアを実行している前記端末から送信された前記サービス要求により、互いにアクセス先が異なり、かつ、提供するサービスの種類、対応する端末の状況および提供するサービスの範囲の少なくとも１つが互いに異なる複数のサービスのうち、前記端末から受信した前記サービス要求に含まれる、前記アプリ情報が示すアプリケーションの種類、前記サービス種情報が示すサービスの種類、前記状況情報が示す前記端末の状況および前記サービス範囲情報が示すサービスの範囲に応じたサービスのアクセス先を決定し、
前記端末から送信された前記サービス要求により、前記決定したアクセス先のサービスがアクセスされるように制御する
処理をコンピュータに実行させるアクセス制御方法。
【０１９９】
（付記１０）
互いにアクセス先が異なる複数のサービスのうち、端末から受信した状況情報が示す前記端末の状況に応じたサービスのアクセス先を決定する決定部と、
設定されたアクセス先にサービス要求を送信する機能を有するアプリケーション・ソフトウェアを実行している前記端末から送信された前記サービス要求により、前記決定したアクセス先のサービスがアクセスされるように制御する制御部と、
を含むアクセス制御装置。
【０２００】
（付記１１）
前記決定部は、前記端末から送信された前記状況情報および前記サービス要求を受信した場合に、受信した前記状況情報が示す前記端末の状況に応じたサービスのアクセス先を決定し、
前記制御部は、受信された前記サービス要求を前記決定部によって前記決定したアクセス先に転送する付記１０記載のアクセス制御装置。
【０２０１】
（付記１２）
前記複数のサービスは、サービスの種類と対応する端末の状況の少なくとも一方が互いに相違しており、
サービスの種類に拘わらず前記サービス要求を受け付ける第１のアクセス先を示すアクセス先情報を設定した前記アプリケーション・ソフトウェアを前記端末に送信する第１送信部を更に備え、
前記決定部は、前記端末から送信された前記第１のアクセス先宛ての前記サービス要求および前記状況情報を、前記アプリケーション・ソフトウェアの種類を表す情報と共に受信した場合に、受信した情報に基づきサービスのアクセス先を決定する付記１１記載のアクセス制御装置。
【０２０２】
（付記１３）
前記複数のサービスは、サービスの種類と対応する端末の状況の少なくとも一方が互いに相違しており、
特定種類のサービスについての前記サービス要求を受け付ける第２のアクセス先を示すアクセス先情報を設定した前記アプリケーション・ソフトウェアを前記端末に送信する第２送信部を更に備え、
前記決定部は、前記端末から前記アプリケーション・ソフトウェアによる前記第２のアクセス先宛ての前記サービス要求および前記状況情報を受信した場合に、前記特定種類のサービスのうち前記状況情報が示す前記端末の状況に対応するサービスのアクセス先を決定する付記１１記載のアクセス制御装置。
【０２０３】
（付記１４）
前記制御部は、前記決定したアクセス先を示すアクセス先情報をサービス要求の送信先に設定した前記アプリケーション・ソフトウェアを前記端末に送信する付記１０記載のアクセス制御装置。
【０２０４】
（付記１５）
位置および所持者の属性の少なくとも一方が検出された前記端末に対して、検出された前記位置および前記属性の少なくとも一方に応じたチケット情報を送信するチケット送信部を更に備え、
前記端末から前記状況情報として前記チケット情報を受信する付記１０〜付記１４の何れか１項記載のアクセス制御装置。
【０２０５】
（付記１６）
前記第１送信部または前記第２送信部または前記制御部は、前記端末から受信した状況情報が示す前記端末の状況に応じて選択した前記アプリケーション・ソフトウェアを前記端末に送信する付記１２〜付記１４の何れか１項記載のアクセス制御装置。
【０２０６】
（付記１７）
前記端末で実行されている前記アプリケーション・ソフトウェアが前記サービス要求を送信する状況を、前記アプリケーション・ソフトウェアの種類と対応付けて検証情報として記憶する記憶部を更に備え、
前記端末から前記サービス要求および前記状況情報を、前記サービス要求および前記状況情報を送信した前記アプリケーション・ソフトウェアの種類を表す情報と共に受信した場合に、前記アプリケーション・ソフトウェアの種類および前記状況情報が示す状況を前記検証情報と照合することで、受信した前記サービス要求が適正か否かを検証する検証部を更に備えた付記１０〜付記１６の何れか１項記載のアクセス制御装置。
【０２０７】
（付記１８）
サービスを要求する際に、自アプリケーションの種類を示すアプリ情報、サービスの種類を示すサービス種情報、端末の状況を示す状況情報およびサービスの範囲を指定するサービス範囲情報を含むサービス要求を送信するように設定されたアプリケーション・ソフトウェアを実行している前記端末から送信された前記サービス要求により、互いにアクセス先が異なり、かつ、提供するサービスの種類、対応する端末の状況および提供するサービスの範囲の少なくとも１つが互いに異なる複数のサービスのうち、前記端末から受信した前記サービス要求に含まれる、前記アプリ情報が示すアプリケーションの種類、前記サービス種情報が示すサービスの種類、前記状況情報が示す前記端末の状況および前記サービス範囲情報が示すサービスの範囲に応じたサービスのアクセス先を決定する決定部と、
前記端末から送信された前記サービス要求により、前記決定したアクセス先のサービスがアクセスされるように制御する制御部と、
を含むアクセス制御装置。
【０２０８】
（付記１９）
互いにアクセス先が異なる複数のサービスのうち、端末から受信した状況情報が示す前記端末の状況に応じたサービスのアクセス先を決定し、
設定されたアクセス先にサービス要求を送信する機能を有するアプリケーション・ソフトウェアを実行している前記端末から送信された前記サービス要求により、前記決定したアクセス先のサービスがアクセスされるように制御する
処理をコンピュータに実行させるアクセス制御プログラム。
【０２０９】
（付記２０）
前記端末から送信された前記状況情報および前記サービス要求を受信した場合に、受信した前記状況情報が示す前記端末の状況に応じたサービスのアクセス先を決定し、受信した前記サービス要求を前記決定したアクセス先に転送する付記１９記載のアクセス制御プログラム。
【０２１０】
（付記２１）
前記複数のサービスは、サービスの種類と対応する端末の状況の少なくとも一方が互いに相違しており、
サービスの種類に拘わらず前記サービス要求を受け付ける第１のアクセス先を示すアクセス先情報を設定した前記アプリケーション・ソフトウェアを前記端末に送信し、
前記端末から送信された前記第１のアクセス先宛ての前記サービス要求および前記状況情報を受信した場合に、前記サービス要求で要求されたサービスの種類および前記状況情報が示す前記端末の状況に対応するサービスのアクセス先を決定する付記２０記載のアクセス制御プログラム。
【０２１１】
（付記２２）
前記複数のサービスは、サービスの種類と対応する端末の状況の少なくとも一方が互いに相違しており、
サービスの種類に拘わらず前記サービス要求を受け付ける第１のアクセス先を示すアクセス先情報を設定した前記アプリケーション・ソフトウェアを前記端末に送信し、
前記端末から送信された前記第１のアクセス先宛ての前記サービス要求および前記状況情報を、前記アプリケーション・ソフトウェアの種類を表す情報と共に受信した場合に、受信した情報に基づきサービスのアクセス先を決定する付記２０記載のアクセス制御プログラム。
【０２１２】
（付記２３）
前記決定したアクセス先を示すアクセス先情報をサービス要求の送信先に設定した前記アプリケーション・ソフトウェアを前記端末に送信する付記１９記載のアクセス制御プログラム。
【０２１３】
（付記２４）
位置および所持者の属性の少なくとも一方が検出された前記端末に対して、検出された前記位置および前記属性の少なくとも一方に応じたチケット情報を送信し、
前記端末から前記状況情報として前記チケット情報を受信する付記１９〜付記２３の何れか１項記載のアクセス制御プログラム。
【０２１４】
（付記２５）
前記端末から受信した状況情報が示す前記端末の状況に応じて選択した前記アプリケーション・ソフトウェアを前記端末に送信する付記２１〜付記２３の何れか１項記載のアクセス制御プログラム。
【０２１５】
（付記２６）
前記端末で実行されている前記アプリケーション・ソフトウェアが前記サービス要求を送信する状況を、前記アプリケーション・ソフトウェアの種類と対応付けて検証情報として記憶しておき、
前記端末から前記サービス要求および前記状況情報を、前記サービス要求および前記状況情報を送信した前記アプリケーション・ソフトウェアの種類を表す情報と共に受信した場合に、前記アプリケーション・ソフトウェアの種類および前記状況情報が示す状況を前記検証情報と照合することで、受信した前記サービス要求が適正か否かを検証する付記１９〜付記２５の何れか１項記載のアクセス制御プログラム。
【０２１６】
（付記２７）
サービスを要求する際に、自アプリケーションの種類を示すアプリ情報、サービスの種類を示すサービス種情報、端末の状況を示す状況情報およびサービスの範囲を指定するサービス範囲情報を含むサービス要求を送信するように設定されたアプリケーション・ソフトウェアを実行している前記端末から送信された前記サービス要求により、互いにアクセス先が異なり、かつ、提供するサービスの種類、対応する端末の状況および提供するサービスの範囲の少なくとも１つが互いに異なる複数のサービスのうち、前記端末から受信した前記サービス要求に含まれる、前記アプリ情報が示すアプリケーションの種類、前記サービス種情報が示すサービスの種類、前記状況情報が示す前記端末の状況および前記サービス範囲情報が示すサービスの範囲に応じたサービスのアクセス先を決定し、
前記端末から送信された前記サービス要求により、前記決定したアクセス先のサービスがアクセスされるように制御する
処理をコンピュータに実行させるアクセス制御プログラム。
【符号の説明】
【０２１７】
１０Ａ,１０Ｂ,１０Ｃ,１０Ｄ…アクセス制御装置、１１…第１受信部、１２…第１送信部、１３…第２受信部、１４…検証部、１５…決定部、１６…制御部、２０…端末、３０Ａ,３０Ｂ,３０Ｃ…アプリ配信サーバ、３３Ａ,４１…アプリ配信サーバプログラム、４０…中継サーバ、４２…名前解決サーバ、４３Ａ…中継サーバプログラム、４４Ａ…名前解決サーバプログラム、５０Ａ,５０Ｂ,５０Ｃ…サービス提供サーバ、５２,５３,５４…サービス提供サーバプログラム、５２Ａ…サービス処理プログラム・データ、５２Ｂ…サービス処理部、７０…状況通知装置、７２…チケット情報、８２…必要チケットテーブル、８４Ａ,８４Ｂ,８４Ｃ…アプリ管理テーブル、８６Ａ,８６Ｂ,８６Ｃ…振り分けテーブル、９０Ａ,９０Ｂ,９０Ｃ,９０Ｄ…コンピュータ・システム
【図１】
0006657636.tif 000002
【図２】
0006657636.tif 000003
【図３】
0006657636.tif 000004
【図４】
0006657636.tif 000005
【図５】
0006657636.tif 000006
【図６】
0006657636.tif 000007
【図７】
0006657636.tif 000008
【図８】
0006657636.tif 000009
【図９】
0006657636.tif 000010
【図１０】
0006657636.tif 000011
【図１１】
0006657636.tif 000012
【図１２】
0006657636.tif 000013
【図１３】
0006657636.tif 000014
【図１４】
0006657636.tif 000015
【図１５】
0006657636.tif 000016
【図１６】
0006657636.tif 000017
【図１７】
0006657636.tif 000018
【図１８】
0006657636.tif 000019
【図１９】
0006657636.tif 000020
【図２０】
0006657636.tif 000021
【図２１】
0006657636.tif 000022
【図２２】
0006657636.tif 000023
【図２３】
0006657636.tif 000024
【図２４】
0006657636.tif 000025
【図２５】
0006657636.tif 000026
【図２６】
0006657636.tif 000027
【図２７】
0006657636.tif 000028
【図２８】
0006657636.tif 000029
【図２９】
0006657636.tif 000030
【図３０】
0006657636.tif 000031
【図３１】
0006657636.tif 000032
【図３２】
0006657636.tif 000033