(57)【要約】【課題】資源へのアクセス権限の柔軟な管理を可能とする。【解決手段】情報処理装置１０は、第１装置３から、ユーザ９が利用可能な資源の利用権限を示すチケット６の取得要求を受信すると、資源を示す利用可能資源情報１１ａに基づいて、資源の利用に関するコマンドを示すコマンド情報６ａを含むチケット６を生成する。そして情報処理装置１０は、チケット６を第１装置３に送信する。その後、情報処理装置１０は、第１装置３を介してチケット６を取得した第２装置４からチケット６を受信すると、チケット６に含まれるコマンド情報６ａに示されるコマンドを実行する。【選択図】図１
2019113981.tif 000002
【特許請求の範囲】
【請求項１】
ユーザが利用可能な資源を示す利用可能資源情報を記憶する記憶部と、
第１装置から、前記資源の利用権限を示すチケットの取得要求を受信すると、前記利用可能資源情報に基づいて、前記資源の利用に関するコマンドを示すコマンド情報を含む前記チケットを生成し、前記チケットを前記第１装置に送信し、前記第１装置を介して前記チケットを取得した第２装置から前記チケットを受信すると、前記チケットに含まれる前記コマンド情報に示される前記コマンドを実行する処理部と、
を有する情報処理装置。
【請求項２】
前記記憶部は、前記ユーザに関連する個人データを、前記ユーザが利用可能な前記資源として記憶しており、
前記処理部は、前記第１装置から前記取得要求を受信すると、前記記憶部からの前記個人データの取得コマンドを示す前記コマンド情報を含む前記チケットを生成し、前記チケットを前記第１装置に送信し、前記第２装置から前記チケットを受信すると、前記取得コマンドに基づいて前記個人データを前記記憶部から取得し、取得した前記個人データを前記第２装置に送信する、
請求項１記載の情報処理装置。
【請求項３】
前記ユーザが利用可能な前記資源は、前記情報処理装置に接続された機器であり、
前記処理部は、前記第１装置から前記取得要求を受信すると、前記機器の制御を命令する制御コマンドを示す前記コマンド情報を含む前記チケットを生成し、前記チケットを前記第１装置に送信し、前記第２装置から前記チケットを受信すると、前記制御コマンドに基づいて前記機器を制御する、
請求項１記載の情報処理装置。
【請求項４】
前記利用可能資源情報には、前記ユーザが使用可能な部屋が示されており、
前記機器は、前記部屋への入室用のドアの施錠および解錠を行う施錠装置であり、
前記処理部は、前記機器に対して解錠を指示する前記制御コマンドを示す前記コマンド情報を含む前記チケットを生成する、
請求項３記載の情報処理装置。
【請求項５】
前記処理部は、前記第１装置から前記取得要求を受信すると、前記コマンド情報を暗号化し、暗号化された前記コマンド情報を含む前記チケットを生成し、前記チケットを前記第１装置に送信し、前記第２装置から前記チケットを受信すると、前記チケット内の暗号化された前記コマンド情報を復号し、復号された前記コマンド情報に示される前記コマンドを実行する、
請求項１ないし４のいずれかに記載の情報処理装置。
【請求項６】
前記処理部は、前記第１装置から前記取得要求を受信すると、前記チケットを利用可能な前記第２装置を示す識別子を含む前記チケットを生成し、前記チケットを前記第１装置に送信し、前記チケットを受信した場合、前記チケットの送信元が前記識別子に対応する前記第２装置であることを認証後、前記コマンドを実行する、
請求項１ないし５のいずれかに記載の情報処理装置。
【請求項７】
前記処理部は、前記第１装置から前記取得要求を受信すると、前記コマンドに対応するコマンドＩＤを前記コマンド情報として含む前記チケットを生成し、前記チケットを前記第１装置に送信し、前記第２装置から前記チケットを受信すると、前記チケットに含まれる前記コマンドＩＤに対応する前記コマンドを実行する、
請求項１ないし６のいずれかに記載の情報処理装置。
【請求項８】
コンピュータが、
第１装置から、ユーザが利用可能な資源の利用権限を示すチケットの取得要求を受信すると、前記資源を示す利用可能資源情報に基づいて、前記資源の利用に関するコマンドを示すコマンド情報を含む前記チケットを生成し、
前記チケットを前記第１装置に送信し、
前記第１装置を介して前記チケットを取得した第２装置から前記チケットを受信すると、前記チケットに含まれる前記コマンド情報に示される前記コマンドを実行する、
情報処理方法。
【請求項９】
コンピュータに、
第１装置から、ユーザが利用可能な資源の利用権限を示すチケットの取得要求を受信すると、前記資源を示す利用可能資源情報に基づいて、前記資源の利用に関するコマンドを示すコマンド情報を含む前記チケットを生成し、
前記チケットを前記第１装置に送信し、
前記第１装置を介して前記チケットを取得した第２装置から前記チケットを受信すると、前記チケットに含まれる前記コマンド情報に示される前記コマンドを実行する、
処理を実行させる情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法、および情報処理プログラムに関する。
【背景技術】
【０００２】
コンピュータシステムでは、様々な資源を用いてサービスが提供される。サービスの提供に用いられる資源には、データまたはプログラムなどのソフトウェア資源や、コンピュータで制御される様々な機器が含まれる。
【０００３】
例えばＩｏＴ（Internet of Things）関連技術の発展により、現在、コンピュータに限らず、様々なもの（ＩｏＴデバイス）をインターネットに接続することが可能となっている。ＩｏＴデバイス自身およびＩｏＴから取得したデータも、サービス提供に利用される資源である。
【０００４】
ＩｏＴデバイスは、データの収集に利用できる。例えばサービスプロバイダが、クラウドコンピューティングシステム（以下、クラウドシステムと呼ぶ）により、多数のＩｏＴデバイスから、各ＩｏＴデバイスを所持しているユーザに関するデータを収集する。サービスプロバイダは、収集したデータのデータマイニングを行うことで、様々な知識を得ることができる。
【０００５】
ＩｏＴデバイスから収集されたデータには、そのＩｏＴデバイスを所持しているユーザの行動の特徴を表すデータが含まれる。そのため、あるユーザが使用するＩｏＴデバイスから収集されたデータは、収集したサービスプロバイダが利用するだけではなく、そのデータを提供したユーザ自身も利用を希望する場合があり得る。例えば、ユーザがＩｏＴデバイスを介して特定のサービスプロバイダに提供したデータを、そのユーザの意思により他のサービスプロバイダに提供することで、ユーザが適切なサービスの提供（例えばサービス利用料の割り引き）を受けることができる場合がある。この場合、例えばデータを所持するサービスプロバイダから他のサービスプロバイダに、該当データへのアクセス権限が渡され、他のサービスプロバイダは、アクセス権限に基づいてデータにアクセスする。
【０００６】
任意のデータへのアクセス権限に関する技術としては、例えばＯＡｕｔｈがある。また、顧客が認可した範囲で認可トークンを共有できるように制御を行う権限委譲システムも考えられている。アクセス資格の無効化、譲渡、分割、変更などの操作を行えるようにするアクセス権管理装置も考えられている。さらに、ネットワーク上の利用権を動的に利用者に提供できないなどの利用権に関する問題を解決するための資源管理システムも考えられている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１３−１４５５０５号公報
【特許文献２】特開２００４−０３２２２０号公報
【特許文献３】特開２００３−１６２４６４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、サーバで管理される資源へのアクセス権限に関する従来の技術では、アクセス権限を管理できる資源の単位が固定的であり、柔軟性に欠ける。
１つの側面では、本発明は、資源へのアクセス権限の柔軟な管理を可能とすることを目的とする。
【課題を解決するための手段】
【０００９】
１つの案では、以下に示す記憶部と処理部とを有する情報処理装置が提供される。
記憶部は、ユーザが利用可能な資源を示す利用可能資源情報を記憶する。処理部は、第１装置から、資源の利用権限を示すチケットの取得要求を受信すると、利用可能資源情報に基づいて、資源の利用に関するコマンドを示すコマンド情報を含むチケットを生成する。そして処理部は、チケットを第１装置に送信する。その後、処理部は、第１装置を介してチケットを取得した第２装置からチケットを受信すると、チケットに含まれるコマンド情報に示されるコマンドを実行する。
【発明の効果】
【００１０】
１態様によれば、資源へのアクセス権限の柔軟な管理が可能となる。
【図面の簡単な説明】
【００１１】
【図１】第１の実施の形態に係る装置の機能構成例を示す図である。
【図２】第２の実施の形態のシステム構成例を示す図である。
【図３】サーバのハードウェアの一構成例を示す図である。
【図４】各装置の機能を示すブロック図である。
【図５】レンタル契約処理と運転データ収集処理との処理手順を示すシーケンス図である。
【図６】契約データの例を示す図である。
【図７】運転データの一例を示す図である。
【図８】自動車保険サービス用のサーバへのアクセスチケットの提供処理の手順の一例を示すシーケンス図である。
【図９】レンタカーサービス用のサーバからのアクセスチケットの取得処理の手順の一例を示すシーケンス図である。
【図１０】アクセスチケット要求の一例を示す図である。
【図１１】テンプレートを用いたアクセスチケットの生成例を示す図である。
【図１２】アクセスチケットを用いた保険料見積もり処理の手順の一例を示すシーケンス図である。
【図１３】第３の実施の形態におけるシステムの一例を示す図である。
【図１４】第４の実施の形態におけるシステムの一例を示す図である。
【図１５】運転データ受信用ＵＲＬ取得処理の手順の一例を示すシーケンス図である。
【図１６】第４の実施の形態における運転データの取得処理の手順の一例を示すシーケンス図である。
【図１７】第５の実施の形態におけるシステムの一例を示す図である。
【図１８】第６の実施の形態におけるシステムの一例を示す図である。
【図１９】フライト予約情報記憶部の一例を示す図である。
【図２０】ホテル予約情報記憶部の一例を示す図である。
【図２１】フライト予約情報のアクセスチケットに含まれるスクリプトの一例を示す図である。
【図２２】ホテル予約情報のアクセスチケットに含まれるスクリプトの一例を示す図である。
【図２３】第７の実施の形態におけるシステムの一例を示す図である。
【図２４】部屋のドアを解錠するためのスクリプトの一例を示す図である。
【図２５】第８の実施の形態におけるユーザ登録処理の一例を示す図である。
【図２６】第８の実施の形態におけるアクセスチケットの利用状況を示す図である。
【図２７】アクセスチケットの利用者の制限機能を有するシステムの一例を示す図である。
【図２８】サービスＩＤを含むアクセスチケット要求の一例を示す図である。
【図２９】サービスＩＤを含むアクセスチケットの一例を示す図である。
【図３０】第８の実施の形態におけるアクセスチケットを用いた保険料見積もり処理の手順の一例を示すシーケンス図である。
【図３１】第９の実施の形態におけるシステムの一例を示す図である。
【図３２】スクリプトＩＤを含むアクセスチケットの一例を示す図である。
【図３３】第９の実施の形態におけるアクセスチケットを用いた保険料見積もり処理の手順の一例を示すシーケンス図である。
【発明を実施するための形態】
【００１２】
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
［第１の実施の形態］
まず、第１の実施の形態について説明する。
【００１３】
図１は、第１の実施の形態に係る装置の機能構成例を示す図である。ネットワーク８には、情報処理装置１０、第１装置３、および第２装置４が接続されている。
情報処理装置１０は、ユーザ９が利用可能な資源を管理する。例えば情報処理装置１０は、レンタカーとして貸し出される自動車１，２に搭載されたＩｏＴデバイス１ａ，２ａから、自動車１，２の状態に関するデータを定期的に収集する。自動車１，２の状態に関するデータは、例えば自動車１，２の位置、速度、加速度などのデータである。自動車１が、所定の期間だけユーザ９に貸し出されていた場合、その期間に自動車１から収集されたデータは、ユーザ９に関連する個人データ７であり、ユーザ９が利用可能な資源でもある。
【００１４】
情報処理装置１０は、ユーザ９が利用可能な資源へのアクセス権限を管理するために、記憶部１１と処理部１２とを有する。記憶部１１は、例えば情報処理装置１０が有するメモリ、またはストレージ装置である。処理部１２は、例えば情報処理装置１０が有するプロセッサ、または演算回路である。
【００１５】
記憶部１１は、ユーザ９が利用可能な資源を示す利用可能資源情報１１ａを記憶する。例えば自動車１がユーザ９に貸し出されていた期間内に、自動車１に搭載されたＩｏＴデバイス１ａから収集したデータが、ユーザの利用可能資源であることが、利用可能資源情報１１ａに示される。また記憶部１１は、ＩｏＴデバイス１ａ，２ａから収集したデータ（取得データ１１ｂ，１１ｃ）を記憶する。
【００１６】
処理部１２は、第１装置３から、ユーザが利用可能な資源の利用権限を示すチケット６の取得要求５を受信すると、利用可能資源情報１１ａに基づいて、資源の利用に関するコマンドを示すコマンド情報６ａを含むチケット６を生成する。コマンド情報６ａは、例えば１以上のコマンドを含むスクリプトである。またコマンド情報６ａは、コマンドに対応付けられた識別子（コマンドＩＤ）であってもよい。資源の利用に関するコマンドは、例えば、記憶部１１からのユーザ９の個人データ７の取得を命令する取得コマンドである。処理部１２は、生成したチケット６を、第１装置３に送信する。
【００１７】
その後、処理部１２は、第１装置３を介してチケット６を取得した第２装置４からチケット６を受信すると、チケット６に含まれるコマンド情報６ａに示されるコマンドを実行する。例えばコマンド情報６ａがスクリプトであれば、処理部１２は、スクリプト内に記述されたコマンドを実行する。またコマンド情報６ａがコマンドＩＤであれば、処理部１２は、そのコマンドＩＤに対応するコマンドを実行する。例えばコマンド情報６ａに示されるコマンドが、ユーザ９の個人データ７の取得コマンドであれば、処理部１２は、記憶部１１からユーザ９の個人データ７を取得する。そして処理部１２は、取得した個人データ７を第２装置４に送信する。
【００１８】
第１装置３は、ユーザ９の指示に従って、情報処理装置１０からチケット６を取得し、ユーザ９が利用可能な資源の使用を許諾する相手（第２装置４）にチケット６を転送する。第１装置３は、例えばユーザ９が使用する端末装置である。
【００１９】
第２装置４は、チケット６を受信すると、そのチケット６を情報処理装置１０に送信し、チケット６内のコマンド情報６ａに示されるコマンドを情報処理装置１０に実行させる。コマンド情報６ａに示されるコマンドが、ユーザ９の個人データ７の取得コマンドであれば、第２装置４は、コマンドの実行結果として、情報処理装置１０から個人データ７を受信する。第２装置４は、受信した個人データ７を利用して、ユーザ９に対するサービスの提供を行う。
【００２０】
このようなシステムによれば、チケット６に基づいて第２装置４に対して利用権限を与える資源を、コマンドによって指定できるため、ユーザ９からの要望に応じた柔軟な権限管理が可能である。すなわち、処理部１２に実行させるコマンドがデータの取得コマンドの場合、引数の指定によって、取得するデータを任意に指定することができる。そのため、情報処理装置１０にコマンドを実行させれば、特定の検索条件を満たすデータのみを記憶部１１から取得することが可能である。例えば処理部１２は、ユーザ９からの指示に応じ、ユーザ９のすべての個人データではなく、ユーザ９が指定した一部の個人データのみを取得するコマンドを示すコマンド情報６ａを、チケット６に含めることができる。
【００２１】
なお、ユーザが利用可能な資源は、情報処理装置１０にネットワーク８を介して接続された機器であってもよい。その場合、処理部１２は、第１装置３から取得要求を受信すると、機器の制御を命令するコマンド（制御コマンド）を示すコマンド情報を含むチケットを生成し、そのチケットを第１装置３に送信する。また処理部１２は、第１装置３に送信したチケットを第２装置４から受信すると、受信したチケットに含まれるコマンド情報に示されるコマンドに基づいて、機器を制御する。
【００２２】
例えば遠隔制御によって、ドアを解錠する場合を想定する。この場合、利用可能資源情報１１ａには、ユーザ９が使用可能な部屋が示される。制御対象の機器は、部屋への入室用のドアの施錠および解錠を行う施錠装置である。処理部１２は、機器に対して解錠を指示するコマンドを示すコマンド情報を含むチケットを生成する。例えば第１装置３を所持するユーザ９が部屋の貸し出しを行っていた場合、チケットを取得したユーザ９は、第１装置３により、部屋の貸し出し相手が所持する第２装置４へ、ドアを解錠するためのチケットを送信する。これにより、貸し出し相手が部屋に入室できるようにすることができる。
【００２３】
このようにチケット６を用いることで、情報処理装置１０で管理する資源を、第２装置４から利用することができ、非常に便利である。その一方、チケット６が不正利用されると、情報処理装置１０で管理する資源が危険にさらされる。
【００２４】
例えばチケット６発行後に、チケット６に含まれるコマンド情報６ａが書き換えられた場合、記憶部１１内のユーザ９の個人データ７以外のデータにアクセスされる危険性がある。そこで、処理部１２は、取得要求を受信すると、コマンド情報６ａを暗号化し、暗号化されたコマンド情報６ａを含むチケット６を生成してもよい。この場合、処理部１２は、チケット６を受信すると、チケット６内の暗号化されたコマンド情報６ａを復号し、復号されたコマンド情報６ａに示されるコマンドを実行する。これにより、記憶部１１に格納されたデータに対する不正なアクセスを抑止することができる。
【００２５】
チケット６を利用できる装置を制限することも可能である。例えば処理部１２は、取得要求を受信すると、チケット６を利用可能な第２装置４を示す識別子を含むチケット６を生成し、そのチケット６を第１装置３に送信する。さらに処理部１２は、チケット６を受信した場合、チケット６の送信元が識別子に対応する第２装置４であることを認証後、コマンドを実行する。処理部１２は、正しく認証できなければ、コマンドの実行を抑止する。これにより処理部１２は、チケット６が、予め指定した装置から送られてきた場合にのみコマンドを実行することができ、チケット６の目的外の使用を抑止できる。
【００２６】
実行するコマンドの漏洩により、記憶部１１内のデータベース構造が解析されることを抑止するために、コマンド情報６ａとして、コマンドＩＤのみをチケット６に含めることもできる。この場合、処理部１２は、取得要求５を受信すると、コマンドに対応するコマンドＩＤをコマンド情報６ａとして含むチケット６を生成し、そのチケット６を第１装置３に送信する。さらに処理部１２は、第２装置４から、コマンドＩＤを含むチケット６を受信すると、そのチケット６に含まれるコマンドＩＤに対応するコマンドを実行する。これにより、コマンドが情報処理装置１０外に開示されることはなくなり、チケット６に基づいて、記憶部１１内のデータベース構造が解析されることを抑止できる。
【００２７】
［第２の実施の形態］
次に第２の実施の形態について説明する。第２の実施の形態は、あるサービスプロバイダが、クラウドシステムによりＩｏＴデバイスから収集したデータを、ＩｏＴデバイスを所持するユーザが、他のサービスプロバイダに提供できるようにするものである。
【００２８】
ここで、第２の実施の形態の詳細を説明する前に、ＩｏＴデバイスを用いて収集したデータの利用の重要性について説明する。
消費者のインターネット上での検索履歴や商品の購入履歴などのパーソナルデータの活用が進んでいる。例えばパーソナルデータに基づいて、その消費者の関心事や消費の動向を把握して、その消費者が興味を示しそうな商品を提示することができる。それに加えて、ＩｏＴと呼ばれるムーブメントが起こり、インターネットに接続されたコンピュータにより、様々なカメラやセンサから、より多くのパーソナルデータを集めることができるようになっている。一方で、収集されたデータは、あるユーザの情報であり、データを収集したサービスプロバイダだけでなくそのユーザにも利用する権利があるとも考えられる。そこで、ユーザからの指示に応じて、あるサービスプロバイダが収集したデータを他のサービスプロバイダに提供することを可能にするシステムが求められている。
【００２９】
例えば、最近では、自動車に搭載したＩｏＴデバイスから収集した運転データを分析して、その自動車の所有者の保険料を算出する自動車保険が存在する。このような保険は、テレマティクス保険と呼ばれている。テレマティクス保険をレンタカーまたはシェアードカーサービスの運転者にも適用しようと考えた場合には、車の運転データをすべて提供するのではなく、あるユーザの運転データのみを、レンタカーまたはシェアードカーサービスの提供者から自動車保険サービスの提供業者に提供することが求められる。
【００３０】
サービスを提供するサーバ間でユーザの許可に基づいてデータへのアクセスを実現する仕組みとしてＯＡｕｔｈがある。ＯＡｕｔｈでは、事前に信頼関係を持つサーバ間でのみ、あるサーバから他のサーバ内のデータへのアクセスが可能である。さらにＯＡｕｔｈでは、ユーザがデータを受け取るサーバにアクセスした上で、ユーザ認証を行い、そのサーバに与えるアクセス権限の範囲をユーザが確認し許可する。テレマティクス保険の例であれば、サービスブローカを通じて複数の自動車保険サービスに見積もりを行いたい場合には、ユーザは、複数の自動車保険サービスそれぞれに対応する複数のサーバそれぞれにアクセスして、アクセスの許可を与えることになる。これでは、ユーザの手間が大きい。なお、サービスブローカが運転データを取得して、運転データを複数の自動車保険サービスそれぞれに対応する複数のサーバに送る方法も考えられる。ただし、この場合、データを利用しないサービスブローカが運転データを扱うことになる。運転データを取り扱う者が増えるほど、その運転データが外部に流出する可能性が高くなり、運転データが危険にさらされる。
【００３１】
また、データを暗号化して、それを復号できる鍵を含めたライセンスを発行することで、データへのアクセスをライセンスの持ち主のみに限定することで制御することが考えられる。この方式ではデータの権限を与えるタイミングとデータのアクセスのタイミングを同期させなくてもよい。しかし、サービスの運用中に収集するデータの追加や削除がされ、提供可能なデータが変わることも考えられる。データを暗号化して提供する場合、データが変わるごとに、外部に開示するデータの暗号化もやり直すこととなり、処理が煩雑となる。
【００３２】
以下、レンタカーサービスの提供業者が保持する運転データを、ユーザの判断で、テレマティクス保険の自動車保険サービスの提供業者に容易に引き渡すことを可能とするシステムについて説明する。
【００３３】
図２は、第２の実施の形態のシステム構成例を示す図である。レンタカーサービスの提供業者が有するサーバ１００と自動車保険サービスの提供業者が有するサーバ２００とは、ネットワーク２０で接続されている。レンタカーサービスによって貸し出される自動車３０には、ＩｏＴデバイス３１が搭載されている。
【００３４】
ＩｏＴデバイス３１は、自動車３０の運転状況を記録した運転データを生成する。例えばＩｏＴデバイス３１は、自動車３０の位置、速度、加速度などの時間変化を、運転データとして、内部の記憶装置に記録する。ＩｏＴデバイス３１は、ネットワーク２０に無線通信網を介して接続されている。そしてＩｏＴデバイス３１は、運転データをサーバ１００に送信する。ＩｏＴデバイス３１として、例えばカーナビゲーションシステムを利用することができる。
【００３５】
テレマティクス保険への加入を検討しているユーザ３２は、端末装置３００を所持している。端末装置３００は、例えばスマートフォンなどの移動体端末装置である。また端末装置３００は、パーソナルコンピュータであってもよい。端末装置３００は、有線、または無線によりネットワーク２０に接続されている。端末装置３００は、ネットワーク２０を介して、サーバ１００，２００と通信することができる。
【００３６】
図３は、サーバのハードウェアの一構成例を示す図である。サーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。
【００３７】
メモリ１０２は、サーバ１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に利用する各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。
【００３８】
バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。
【００３９】
ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。
【００４０】
グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、有機ＥＬ（Electro Luminescence）を用いた表示装置や液晶表示装置などがある。
【００４１】
入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
【００４２】
光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。
【００４３】
機器接続インタフェース１０７は、サーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。
【００４４】
ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。
【００４５】
以上のようなハードウェア構成によって、第２の実施の形態におけるサーバ１００の処理機能を実現することができる。なお、サーバ２００と端末装置３００も、サーバ１００と同様のハードウェアによって実現することができる。端末装置３００が移動体端末装置の場合には、端末装置３００には、図３に示したハードウェアに加え、電波を用いた無線通信インタフェースが含まれる。ＩｏＴデバイス３１は、サーバ１００と同様のハードウェア構成に加え、電波を用いた無線通信インタフェース、衛星測位システム用の受信機、加速度センサなどを有する。さらに、第１の実施の形態に示した情報処理装置１０も、図３に示したサーバ１００と同様のハードウェアにより実現することができる。
【００４６】
サーバ１００，２００および端末装置３００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。サーバ１００，２００および端末装置３００それぞれに実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、サーバ１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またサーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
【００４７】
次に、ユーザ３２が、レンタカーサービスにより提供された自動車３０を運転したときの運転データに基づいてテレマティクス保険による保険料の見積もりを行うために、各装置が有する機能について説明する。
【００４８】
図４は、各装置の機能を示すブロック図である。レンタカーサービス用のサーバ１００は、データベース１１０、契約管理部１２０、運転データ取得部１３０、アクセスチケット生成部１４０、およびアクセスチケット実行部１５０を有する。
【００４９】
データベース１１０は、ユーザ３２の自動車３０の利用履歴や、ユーザ３２が自動車３０を運転したときの運転データ４１を記憶する。運転データ４１は、ユーザ３２が自動車３０を運転している間に定期的に計測された自動車３０の状態を示す測定値（自動車状態測定値）の集合である。自動車状態測定値には、測定時刻における自動車３０の速度などの情報が含まれており、複数の自動車状態測定値それぞれに示される速度などの情報に基づいて、ユーザ３２の運転傾向が解析できる。データベース１１０としては、例えばメモリ１０２またはストレージ装置１０３の記憶領域の一部が使用される。図４の例では、データベース１１０には、運転データ管理テーブル１１１とユーザ管理テーブル１１２とが格納されている。運転データ管理テーブル１１１は、運転データ４１を管理するためのデータテーブルである。運転データ管理テーブル１１１には、自動車３０の識別子（自動車ＩＤ）に対応付けて、その自動車３０の場所、速度、日時が設定されている。ユーザ管理テーブル１１２は、レンタカーサービスを利用するユーザ３２を管理するためのデータテーブルである。ユーザ管理テーブル１１２には、ユーザ３２の識別子（ユーザＩＤ）に対応付けて、ユーザ３２が使用した自動車３０の自動車ＩＤ、レンタル期間が設定されている。
【００５０】
契約管理部１２０は、ユーザ３２との間で自動車３０のレンタル契約の締結処理を行う。例えば契約管理部１２０は、ユーザ３２が所持する端末装置３００からのレンタル契約の要求に応じてレンタル契約を確定する。契約管理部１２０は、自動車３０がユーザ３２に対して貸与されることが確定すると、ユーザ管理テーブル１１２に、レンタル契約の内容を示すレコードを登録する。
【００５１】
運転データ取得部１３０は、自動車３０から、ユーザ３２が自動車３０を運転した期間の運転データ４１を取得する。運転データ４１には、例えば、所定時間ごとに測定した自動車３０の場所（緯度、経度）、速度、および測定した日時が含まれる。運転データ取得部１３０は、取得した運転データ４１を、運転データ管理テーブル１１１に格納する。
【００５２】
アクセスチケット生成部１４０は、端末装置３００からのアクセスチケット要求に応じて、ユーザ３２が自動車３０を使用した期間の運転データ４１へのアクセスを許可するためのアクセスチケット４２を生成する。アクセスチケット４２には、データベース１１０からの、ユーザ３２が自動車３０を使用した期間の運転データ４１の取得処理を示すスクリプト（１以上のコマンド列）が含まれる。アクセスチケット生成部１４０は、生成したアクセスチケット４２を端末装置３００に送信する。
【００５３】
アクセスチケット実行部１５０は、自動車保険サービス用のサーバ２００からアクセスチケット４２を受信すると、そのアクセスチケット４２に含まれるスクリプトを実行することにより、データベース１１０から運転データ４１を取得する。アクセスチケット実行部１５０は、取得した運転データ４１を、サーバ２００に送信する。
【００５４】
自動車保険サービス用のサーバ２００は、保険料見積もり部２１０を有する。保険料見積もり部２１０は、運転データ４１に基づいて、ユーザ３２に対して提供する自動車保険の保険料を算出する。例えば保険料見積もり部２１０は、ユーザ３２が使用する端末装置３００から、次回のレンタカー使用時の保険料の見積もり依頼を取得すると、端末装置３００に対してアクセスチケット要求を送信する。保険料見積もり部２１０は、アクセスチケット４２を端末装置３００から取得すると、そのアクセスチケットをサーバ１００に送信する。さらに保険料見積もり部２１０は、サーバ１００から運転データ４１を取得すると、その運転データ４１に基づき保険料を計算する。保険料見積もり部２１０は、計算した保険料を、見積もり結果として端末装置３００に送信する。
【００５５】
なお、図４に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図４に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。
【００５６】
以下、図４に示すシステムによる保険料見積もり処理の手順を、処理の順番に沿って説明する。
まず、レンタル契約処理と運転データ収集処理について説明する。
【００５７】
図５は、レンタル契約処理と運転データ収集処理との処理手順を示すシーケンス図である。まず、ユーザ３２は、端末装置３００のアクセスチケット管理部３１０を使って、レンタカーサービス用のサーバ１００にアクセスする。そしてユーザ３２は、端末装置３００に、ユーザ３２のユーザＩＤとパスワードの組などの認証情報を入力する。すると、アクセスチケット管理部３１０は、レンタカーサービス用のサーバ１００に対して、認証情報を含むユーザ認証要求を送信する（ステップＳ１０１）。
【００５８】
サーバ１００内の契約管理部１２０は、ユーザ認証要求に応じて、ユーザ認証を行う（ステップＳ１０２）。例えば契約管理部１２０は、ユーザ認証要求に含まれる認証情報が、予めサーバ１００に登録されているユーザ情報（ユーザＩＤとパスワードとの組）のいずれかと一致するか否かを判断する。いずれかのユーザ情報と一致した場合、契約管理部１２０は、端末装置３００を使用しているユーザ３２が、一致したユーザ情報に対応する正当なユーザであると判断する。契約管理部１２０は、正当なユーザであると判断した場合、ユーザ認証が成功したことを、端末装置３００に通知する。
【００５９】
アクセスチケット管理部３１０は、ユーザ認証に成功すると、サービス契約申し込みを示す契約データを、サーバ１００に送信する（ステップＳ１０３）。例えばアクセスチケット管理部３１０は、Ｗｅｂブラウザを介して、自動車３０の選択やレンタル期間など指定し、契約データを送信する。
【００６０】
図６は、契約データの例を示す図である。契約データ４３には、ユーザ３２のユーザＩＤ「ｕｓｅｒ０００１」、自動車３０の自動車ＩＤ「ｃａｒ０００１」、使用開始日時「２０１７−０５−０１Ｔ１２：００：００」、使用終了日時「２０１７−０５−０１Ｔ１４：００：００」が含まれる。
【００６１】
以下、図５の説明に戻る。
サーバ１００内の契約管理部１２０は、認証したユーザからの契約データ４３を受信し、指定された自動車３０が指定された期間に貸与可能であれば、サービス契約を確定する（ステップＳ１０４）。次に契約管理部１２０は、契約データ４３を、データベース１１０に格納する（ステップＳ１０５）。例えば契約管理部１２０は、契約データ４３に示される情報を含むレコードを、ユーザ管理テーブル１１２に登録する。
【００６２】
このようにして、レンタル契約処理が行われ、ユーザ３２は、自動車３０をレンタル期間中使用する。ユーザ３２が自動車３０を使用すると、自動車３０に搭載されたセンサ及び通信装置により、自動車状態（場所、速度、時刻）が測定される。
【００６３】
ＩｏＴデバイス３１は、定期的に、その時刻における自動車状態（場所、速度、時刻）を測定し、自動車状態測定値を取得する（ステップＳ１１１）。そして、ＩｏＴデバイス３１は、自動車状態測定値を、サーバ１００に送信する（ステップＳ１１２）。
【００６４】
サーバ１００では、運転データ取得部１３０が、自動車状態測定値を受信する（ステップＳ１１３）。運転データ取得部１３０は、取得した自動車状態測定値を、データベース１１０に格納する（ステップＳ１１４）。例えば、運転データ取得部１３０は、取得した自動車状態測定値に自動車３０の自動車ＩＤを付与した情報を、１つのレコードとして、運転データ管理テーブル１１１に登録する。
【００６５】
このような、自動車状態測定値の蓄積が、ユーザ３２が自動車３０を使用している期間（レンタル期間）の間繰り返され、その間に蓄積された自動車状態測定値の集合が、ユーザ３２の運転データ４１となる。
【００６６】
図７は、運転データの一例を示す図である。運転データ４１には、測定した時刻ごとの自動車状態測定値が含まれる。各自動車状態測定値には、自動車３０の自動車ＩＤ、測定した日時、および速度の情報が含まれる。
【００６７】
その後、ユーザ３２は、再度レンタカーを借りるとき、利用時の自動車保険に加入するために、端末装置３００のアクセスチケット管理部３１０を用いて、自動車保険サービス用のサーバ２００にアクセスする。サーバ２００の自動車保険は運転データを提供することで、自動車保険の保険料を変えることをユーザに通知して、アクセスチケット４２の提供を促す。通知を受けたユーザ３２は、端末装置３００のアクセスチケット管理部３１０を用いて、レンタカーサービス用のサーバ１００にアクセスし、アクセスチケット４２を取得する。そして、ユーザ３２は、端末装置３００のアクセスチケット管理部３１０を用いて、アクセスチケット４２を、自動車保険サービス用のサーバ２００に送信する。
【００６８】
以下、図８〜図１１を参照して、レンタカーサービス用のサーバ１００からのアクセスチケット４２の取得処理ついて詳細に説明する。
図８は、自動車保険サービス用のサーバへのアクセスチケットの提供処理の手順の一例を示すシーケンス図である。
【００６９】
端末装置３００のアクセスチケット管理部３１０は、保険料見積もり要求を、自動車保険サービス用のサーバ２００に送信する（ステップＳ１２１）。サーバ２００では、保険料見積もり部２１０が、保険料見積もり要求を受信する（ステップＳ１２２）。保険料見積もり要求を受信した保険料見積もり部２１０は、運転データ４１についてのアクセスチケット要求を、端末装置３００に送信する（ステップＳ１２３）。端末装置３００のアクセスチケット管理部３１０は、アクセスチケット要求を受信する（ステップＳ１２４）。このとき、まだアクセスチケット４２を取得していなければ、アクセスチケット管理部３１０は、アクセスチケット４２を取得する。
【００７０】
図９は、レンタカーサービス用のサーバからのアクセスチケットの取得処理の手順の一例を示すシーケンス図である。
端末装置３００のアクセスチケット管理部３１０は、ユーザ３２から入力された認証情報（ユーザ３２のユーザＩＤとパスワード）を含むユーザ認証要求を、レンタカーサービス用のサーバ１００に送信する（ステップＳ１３１）。サーバ１００のアクセスチケット生成部１４０は、ユーザ認証要求に示される認証情報により、ユーザ認証を行う（ステップＳ１３２）。ユーザ認証が成功すると、アクセスチケット生成部１４０は、端末装置３００に対して、ログインしたことを示す情報を送信する。このようにしてユーザ３２は、サーバ１００にログインする。
【００７１】
サーバ１００にログインしたユーザ３２は、アクセスチケット管理部３１０に対して、アクセスチケット要求の送信を指示する。例えばアクセスチケット管理部３１０は、サーバ１００から、ユーザ３２がレンタカーサービスを使った履歴を示す履歴情報を取得し、履歴情報を表示する。ユーザ３２は、表示された履歴情報から、自身が取得したい運転データの期間を選択する。するとアクセスチケット管理部３１０は、サーバ１００に対して、選択された期間を指定したアクセスチケット要求を送信する（ステップＳ１３３）。
【００７２】
図１０は、アクセスチケット要求の一例を示す図である。アクセスチケット要求４０には、ユーザ３２が使用した自動車３０の自動車ＩＤ、取得する運転データの期間指定におけるその期間の開始日時と終了日時とが含まれる。
【００７３】
以下、図９の説明に戻る。
レンタカーサービス用のサーバ１００のアクセスチケット生成部１４０は、アクセスチケット要求を受信する（ステップＳ１３４）。次にアクセスチケット生成部１４０は、データベース１１０から、指定された期間におけるユーザ３２の運転データ４１を取得するためのスクリプトを生成する（ステップＳ１３５）。この際、アクセスチケット生成部１４０は、不正な要求を防ぐために、指定された期間に、運転データ４１の採取元の自動車３０をユーザ３２が利用していたことを確認してもよい。例えばアクセスチケット生成部１４０は、ユーザ認証によりユーザ３２のユーザＩＤを認識しているため、そのユーザＩＤと、自動車３０の自動車ＩＤとに基づいて、ユーザ管理テーブル１１２を検索する。アクセスチケット生成部１４０は、アクセスチケット要求に示された期間が、検索結果として得られたレコードに示されるレンタル期間内であれば、自動車３０が指定された期間にユーザ３２に貸与されていたと判断する。
【００７４】
スクリプトを生成した後、アクセスチケット生成部１４０は、暗号化用の鍵を生成し、その鍵によりスクリプトを暗号化する（ステップＳ１３６）。アクセスチケット生成部１４０は、暗号化に用いた鍵を、メモリ１０２またはストレージ装置１０３に格納する。暗号化に用いた鍵は、スクリプトの復号にも用いられる。
【００７５】
次に、アクセスチケット生成部１４０は、暗号化したスクリプトをペイロードに含むアクセスチケット４２を生成する（ステップＳ１３７）。そしてアクセスチケット生成部１４０は、生成したアクセスチケット４２を端末装置３００に送信する（ステップＳ１３８）。端末装置３００では、アクセスチケット管理部３１０が、アクセスチケット４２を受信する（ステップＳ１３９）。
【００７６】
このようにして、ユーザ３２は、任意の期間の運転データ４１についてのアクセスチケット４２を取得することができる。なお、アクセスチケット生成部１４０は、例えばテンプレートを用いてアクセスチケット４２を生成することができる。
【００７７】
図１１は、テンプレートを用いたアクセスチケットの生成例を示す図である。例えばサーバ１００は、ストレージ装置１０３内に、アクセスチケット４２作成用のテンプレート４４を記憶する。テンプレート４４には、自動車３０の自動車ＩＤ、運転データの取得対象期間の開始日時と終了日時とを示す値を、仮の値とした、運転データの取得を指示するスクリプトが示されている。アクセスチケット生成部１４０は、テンプレート４４の仮の値を、アクセスチケット要求に示された値に置き換えることで、アクセスチケット要求に応じたスクリプト４５を生成する。図１１の例では、テンプレート４４内の、「ＣＡＲＩＤ」、「ＤＡＴＥ１」、「ＤＡＴＥ２」と記述している項目が、それぞれ自動車の自動車ＩＤ、取得対象期間の開始日時、取得対象期間の終了日時に置き換えられる。
【００７８】
図１１に示すスクリプト４５は、ＪａｖａＳｃｒｉｐｔ（登録商標）で記述して、ＭｙＳＱＬで管理されたデータベースにアクセスする例である。なお、スクリプト４５をＪａｖａＳｃｒｉｐｔ（登録商標）以外の言語で記述してもよい。スクリプト４５には、レンタカーサービス用のサーバ１００内のデータベース１１０の運転データ管理テーブル１１１に保存されたデータを取得する処理が記述されている。スクリプト４５では、取得の条件として、自動車ＩＤ「ｃａｒ０００１」と期間「２０１７／５／１  １０：００−１２：００」とが指定されている。
【００７９】
スクリプト４５を生成後、アクセスチケット生成部１４０は、ヘッダとペイロードとを含むアクセスチケット４２を生成する。ヘッダには、例えばサーバ１００内のアクセスチケット実行部１５０を示すＵＲＬ（Uniform Resource Locator）が含まれる。またヘッダには、アクセスチケット４２の有効期間の開始日時と終了日時とが含まれる。アクセスチケット４２のペイロードには、暗号化されたスクリプト４５が設定される。
【００８０】
このようにして、テンプレート４４を用いて、容易にアクセスチケット４２を生成することができる。なお、アクセスチケット４２を用いた運転データ４１の取得先の指定方法は、ＵＲＬに限定するものではない。
【００８１】
アクセスチケットを取得した端末装置３００は、自動車保険サービス用のサーバ２００へ、アクセスチケット４２を提供する。サーバ２００は、アクセスチケット４２を用いて、レンタカーサービス用のサーバ１００からユーザ３２の運転データ４１を取得し、その運転データ４１に基づいて保険料を見積もる。
【００８２】
図１２は、アクセスチケットを用いた保険料見積もり処理の手順の一例を示すシーケンス図である。端末装置３００のアクセスチケット管理部３１０は、自動車保険サービス用のサーバ２００からのアクセスチケット要求（図１０参照）に対する応答として、サーバ１００から取得したアクセスチケット４２をサーバ２００に送信する（ステップＳ１４１）。サーバ２００の保険料見積もり部２１０は、アクセスチケット４２を受信する（ステップＳ１４２）。
【００８３】
アクセスチケット４２を受信した保険料見積もり部２１０は、アクセスチケット４２のヘッダにより、運転データ４１の取得先（ＵＲＬ）を確認する(ステップＳ１４３）。保険料見積もり部２１０は、運転データ４１の取得先となっているサーバ１００内のアクセスチケット実行部１５０に対して、アクセスチケット４２を送信する（ステップＳ１４４）。
【００８４】
アクセスチケット実行部１５０は、アクセスチケット４２を受信する（ステップＳ１４５）。アクセスチケット実行部１５０は、受信したアクセスチケット４２のペイロード内に設定されている暗号データを、メモリ１０２またはストレージ装置１０３に格納しておいた鍵を用いて復号する（ステップＳ１４６）。復号により、運転データ４１を取得するための命令文が記述されたスクリプト４５（図１１参照）が生成される。アクセスチケット実行部１５０は、復号されたスクリプト４５を実行する（ステップＳ１４７）。アクセスチケット実行部１５０は、スクリプト４５を実行したことで、データベース１１０からユーザ３２の運転データ４１を取得することができる。アクセスチケット実行部１５０は、取得した運転データ４１をサーバ２００に送信する（ステップＳ１４８）。
【００８５】
サーバ２００の保険料見積もり部２１０は、運転データ４１を受信する（ステップＳ１４９）。保険料見積もり部２１０は、受信した運転データ４１に基づいて、レンタカーをユーザ３２が運転した場合の事故などに関する保険料を計算する（ステップＳ１５０）。例えば保険料見積もり部２１０は、ユーザ３２が慎重な運転を行う傾向にあることが、運転データ４１から判別できた場合、保険料を安く見積もる。また、保険料見積もり部２１０は、ユーザ３２が乱暴な運転を行う傾向にあることが、運転データ４１から判別できた場合、保険料を高く見積もる。ユーザ３２の運転傾向は、例えば、急加速の有無や、制限速度の遵守度合いなどから判断される。
【００８６】
保険料を算出した保険料見積もり部２１０は、保険料の計算結果を端末装置３００に送信する（ステップＳ１５１）。端末装置３００のアクセスチケット管理部３１０は、保険料の見積もり結果を受信し、保険料をモニタに表示する（ステップＳ１５２）。
【００８７】
このようにして、アクセスチケット４２を用いて、ユーザ３２の運転データ４１に対するアクセス権限を、自動車保険サービス用のサーバ２００に与えることができる。アクセスチケット４２には、アクセス権限の範囲がスクリプトにより詳細に設定できる。例えばＳＱＬ文を用いてアクセスを許可するデータを限定することができる。その結果、柔軟性の高いアクセス権限管理が可能となる。
【００８８】
また、アクセスチケット４２内のスクリプトを暗号化しているため、スクリプトにより取得される運転データの安全性が保たれている。すなわち、アクセスチケット４２内のスクリプトはそれを、アクセスチケット４２を発行したサーバ１００が実行するコマンドであるため、スクリプトを第三者に見られてもデータの漏洩にはつながらない。しかし、コマンドの中に、ＳＱＬの情報が含まれているため、データベース１１０の内部構造が把握されることや、ＳＱＬの中にＩＤ情報などが含まれることで、ハッキングのヒントになることがあり得る。そのため、スクリプトを暗号化することで、不正な第三者にハッキングのヒントとなる情報が漏れることを抑止でき、その結果、データベース１１０内のデータの安全性が向上する。
【００８９】
しかも、暗号化および復号の鍵は、サーバ１００のみが有していればよい。そのため、鍵が漏洩することにより、暗号化されたスクリプトが不正に復号される危険性も少ない。
なお、アクセスチケット４２の生成時にスクリプトを暗号化するのではなく、サーバ間の通信を暗号化してもよい。例えば、Ｗｅｂサービスで多く利用されているＨＴＴＰＳ（Hypertext Transfer Protocol Secure）により、サーバ間の通信を暗号化することができる。
【００９０】
［第３の実施の形態］
次に第３の実施の形態について説明する。第３の実施の形態は、保険サービスブローカを介して、複数の自動車保険サービス提供業者に、ユーザ３２の運転データ４１へのアクセス権限を与えるものである。
【００９１】
図１３は、第３の実施の形態におけるシステムの一例を示す図である。第３の実施の形態における第２の実施の形態との違いは、ユーザ３２が直接自動車保険サービス用のサーバ２００にアクセスする代わりに、保険サービスブローカが用意したサーバ４００を使う点である。
【００９２】
ユーザ３２は、保険料見積もりの際に、端末装置３００を用いて保険サービスブローカ用のサーバ４００にアクセスする。端末装置３００からサーバ４００へ、次回のレンタル用の保険料見積もりを依頼する。保険料見積もりの依頼は、サーバ４００内の保険料見積もり代理依頼部４１０で受信される。保険料見積もり代理依頼部４１０は、端末装置３００に対して、アクセスチケット要求を送信する。端末装置３００は、アクセスチケット要求に応じて、レンタカーサービス用のサーバ１００からアクセスチケット４２を取得する。アクセスチケット４２の取得処理の詳細は、第２の実施の形態と同様である。
【００９３】
端末装置３００は、取得したアクセスチケット４２を、保険サービスブローカ用のサーバ４００に送信する。そしてサーバ４００の保険料見積もり代理依頼部４１０は、複数の自動車保険サービス提供業者それぞれのサーバ２００ａ，２００ｂ，・・・にアクセスチケット４２ａ，４２ｂ，・・・を送信する。
【００９４】
アクセスチケット４２ａを受信したサーバ２００ａは、レンタカーサービス用のサーバ１００にアクセスチケット４２ａを送信し、サーバ１００から運転データ４１を取得する。自動車保険サービス用の他のサーバ２００ｂ，・・・も同様に、取得したアクセスチケット４２ｂをサーバ１００に送信することで、運転データ４１を取得する。サーバ２００ａ，２００ｂ，・・・は、運転データ４１に基づいて、サーバ２００ａ，２００ｂ，・・・それぞれを管理している自動車保険サービス提供企業内での基準に従って、保険料を算出する。サーバ２００ａ，２００ｂ，・・・は、算出した保険料を、見積もり結果４６ａ，４６ｂ，・・・として保険サービスブローカのサーバ４００に送信する。
【００９５】
サーバ４００では、保険料見積もり代理依頼部４１０が、複数のサーバ２００ａ，２００ｂ，・・・から送られた見積もり結果４６ａ，４６ｂ，・・・を受信し、その見積もり結果４６ａ，４６ｂ，・・・を纏めて端末装置３００に送信する。
【００９６】
保険サービスブローカのサーバ４００を介在させたことにより、複数の自動車保険サービス企業に同時に見積もりを依頼して、それぞれの見積もり結果４６ａ，４６ｂ，・・・を得るのが容易となる。ユーザ３２は、複数の見積もり結果４６ａ，４６ｂ，・・・から、自身の望むサービスを選択することができる。
【００９７】
［第４の実施の形態］
次に第４の実施の形態について説明する。第４の実施の形態は、アクセスチケットのヘッダにＵＲＬを書き込まずに、運転データ受信用のアクセス先を判別できるようにしたものである。
【００９８】
図１４は、第４の実施の形態におけるシステムの一例を示す図である。サーバ１００における処理は、アクセスチケット４７のヘッダに、アクセスチケット実行部１５０を示すＵＲＬを記述しない点が、第２の実施の形態と異なる。第４の実施の形態では、アクセスチケット生成部１４０は、アクセスチケット４７のヘッダに、ユーザ３２に対して提供したサービスの識別子（サービスＩＤ）を設定する。
【００９９】
また、第４の実施の形態のシステムでは、レンタカーサービス用のサーバ１００からの運転データの取得処理を代行するプラットフォームサービスを実行するサーバ５００が設けられる。サーバ５００は、運転データ受信用ＵＲＬ記憶部５１０と運転データ代理取得部５２０とを有する。運転データ受信用ＵＲＬ記憶部５１０は、サービスＩＤに対応付けて、サービスＩＤに示されたサービス時に取得された運転データ４１の取得先を示すＵＲＬを記憶する。
【０１００】
自動車保険サービス用のサーバ２００の保険料見積もり部２１０は、第２の実施の形態と同様の手順で、端末装置３００からアクセスチケット４７を取得する。保険料見積もり部２１０は、取得したアクセスチケット４７をサーバ５００に送信する。サーバ５００では、運転データ代理取得部５２０が、運転データ受信用ＵＲＬ記憶部５１０を参照し、アクセスチケット４７に示されるサービスＩＤに対応する運転データ受信用ＵＲＬを取得する。そして運転データ代理取得部５２０は、取得したＵＲＬ宛てにアクセスチケット４７を送信することで、運転データ４１を取得する。運転データ代理取得部５２０は、取得した運転データ４１を、自動車保険サービス用のサーバ２００に送信する。
【０１０１】
なお、ユーザ３２の運転データの代理取得を行うための事前準備として、サーバ５００の運転データ代理取得部５２０は、レンタカーサービス用のサーバ１００から、運転データ受信用ＵＲＬを取得する。
【０１０２】
図１５は、運転データ受信用ＵＲＬ取得処理の手順の一例を示すシーケンス図である。例えばサーバ５００には、ユーザ３２の認証情報（ユーザＩＤとパスワード）が予め登録されているものとする。そして、運転データ代理取得部５２０は、ユーザ３２の認証情報をサーバ１００に送信する（ステップＳ１５１）。サーバ１００のアクセスチケット実行部１５０は、認証情報により、ユーザ３２のアカウントでのアクセスを認証する（ステップＳ１５２）。そしてアクセスチケット実行部１５０は、ユーザ３２に提供したサービスのサービスＩＤと、アクセスチケット実行部１５０自身を示す運転データ受信用ＵＲＬとの組を、サーバ５００に送信する（ステップＳ１５３）。サーバ５００の運転データ代理取得部５２０は、サービスＩＤと運転データ受信用ＵＲＬとの組を受信する（ステップＳ１５４）。そして、運転データ代理取得部５２０は、運転データ受信用ＵＲＬ記憶部５１０に、サービスＩＤと運転データ受信用ＵＲＬとの組を格納する（ステップＳ１５５）。例えば運転データ受信用ＵＲＬ記憶部５１０には、ＵＲＬ管理テーブル５１１が格納されている。運転データ代理取得部５２０は、受信したサービスＩＤと運転データ受信用ＵＲＬとの組を含む新たなレコードを、ＵＲＬ管理テーブル５１１に追加する。
【０１０３】
次に、プラットフォームサービス用のサーバ５００を介した運転データの取得処理の手順について説明する。
図１６は、第４の実施の形態における運転データの取得処理の手順の一例を示すシーケンス図である。自動車保険サービス用のサーバ２００の保険料見積もり部２１０は、端末装置３００からアクセスチケット４７を受信すると、サーバ５００に対するアクセスチケット送信ＡＰＩ（Application Programming Interface）の呼び出しを行う（ステップＳ１６１）。アクセスチケット送信ＡＰＩ呼び出しには、アクセスチケット４７が含まれる。サーバ５００の運転データ代理取得部５２０は、保険料見積もり部２１０からのアクセスチケット送信ＡＰＩ呼び出しを受信する（ステップＳ１６２）。運転データ代理取得部５２０は、アクセスチケット送信ＡＰＩ呼び出しに含まれるアクセスチケット４７のヘッダからサービスＩＤを取得し、そのサービスＩＤに対応するＵＲＬを、アクセスチケット受信ＵＲＬ記憶部５１０から取得する（ステップＳ１６３）。運転データ代理取得部５２０は、取得したＵＲＬ宛てに、アクセスチケット４７を送信する。送信されたアクセスチケット４７は、サーバ１００のアクセスチケット実行部１５０が受信する（ステップＳ１６５）。
【０１０４】
サーバ１００のアクセスチケット実行部１５０は、アクセスチケット４７のペイロード内の暗号データを復号し、スクリプトを生成する（ステップＳ１６６）。アクセスチケット実行部１５０は、生成したスクリプトを実行する（ステップＳ１６７）。スクリプトの実行により、運転データ４１が取得される。そしてアクセスチケット実行部１５０は、サーバ５００に対して、データ送信用ＡＰＩの呼び出しを行う（ステップＳ１６８）。データ送信用ＡＰＩの呼び出しには、運転データ４１が含まれる。
【０１０５】
サーバ５００内の運転データ代理取得部５２０は、データ送信用ＡＰＩ呼び出しに含まれる運転データ４１を受信する（ステップＳ１６９）。運転データ代理取得部５２０は、受信した運転データをサーバ２００に送信する（ステップＳ１７０）。サーバ２００の保険料見積もり部２１０は、運転データ４１を受信する（ステップＳ１７１）。
【０１０６】
このようにして、アクセスチケット４７内にアクセスチケット実行部１５０を示すＵＲＬを含めなくても、サーバ２００は、端末装置３００から取得したアクセスチケット４７をアクセスチケット実行部１５０に渡し、運転データ４１を取得することができる。
【０１０７】
［第５の実施の形態］
次に第５の実施の形態について説明する。第５の実施の形態は、ユーザのアクセスチケットを管理するプラットフォームを設けたものである。
【０１０８】
図１７は、第５の実施の形態におけるシステムの一例を示す図である。図１７の例では、ユーザ３２は、複数のレンタカーサービス提供企業から、レンタカーを借りた経験があり、各レンタカーサービス提供企業のサーバ１００ａ，１００ｂ，・・・は、ユーザ３２の運転データを保持している。
【０１０９】
プラットフォームサービスを行う企業のサーバ６００は、ネットワークを介して、レンタカーサービス用のサーバ１００ａ，１００ｂ，・・・や端末装置３００に接続されている。サーバ６００は、ユーザ別のアクセスチケット記憶部６１０，６２０、およびアクセスチケット管理代行部６３０を有している。
【０１１０】
アクセスチケット記憶部６１０は、ユーザ３２のデータへのアクセス権限を示すアクセスチケット４８ａ，４８ｂ，・・・・を記憶する。同様に、アクセスチケット記憶部６２０は、図示していないユーザのデータへのアクセス権限を示すアクセスチケットを記憶する。
【０１１１】
アクセスチケット管理代行部６３０は、アクセスチケットをユーザごとに管理する。例えばレンタカーサービス用の各サーバ１００ａ，１００ｂ，・・・は、ユーザ３２の運転データを収集した後、プラットフォームサービス用のサーバ６００に対して、運転データへのアクセス権限を示すアクセスチケット４８ａ，４８ｂ，・・・を送信する。例えば、サーバ１００ａ，１００ｂ，・・・、ユーザ３２に対するレンタカーのレンタル期間を過ぎた時点で、アクセスチケットを送信する。
【０１１２】
サーバ６００では、アクセスチケット管理代行部６３０がアクセスチケット４８ａ，４８ｂ，・・・を受信する。アクセスチケット管理代行部６３０は、受信したアクセスチケット４８ａ，４８ｂ，・・・を、ユーザ３２に対応するアクセスチケット記憶部６１０に格納する。例えばアクセスチケット管理代行部６３０は、ユーザＩＤを引数とするようなＡＰＩの実行機能を有する。この場合、サーバ１００ａ，１００ｂ，・・・は、ユーザＩＤを引数とするＡＰＩの呼び出しを行う。アクセスチケット管理代行部６３０は、ＡＰＩの呼び出しを受けて、ＡＰＩの呼び出しにおける引数で示されたユーザＩＤに対応するアクセスチケット記憶部に、アクセスチケットを格納する。また、アクセスチケット管理代行部６３０は、端末装置３００からのアクセスチケット要求に応じて、端末装置３００にアクセスチケット４８ａ，４８ｂ，・・・を送信する。
【０１１３】
端末装置３００内のアクセスチケット管理部３１０は、サーバ６００にアクセスし、自身の運転データへのアクセス権限を示すアクセスチケット４８ａ，４８ｂ，・・・を取得する。そしてアクセスチケット管理部３１０は、保険料見積もりの際に、自動車保険サービス用のサーバ２００にアクセスチケット４８ａ，４８ｂ，・・・を送信する。なおアクセスチケット４８ａ，４８ｂ，・・・のヘッダには、運転データ取得先を示すＵＲＬが含まれているものとする。サーバ２００内の保険料見積もり部２１０は、アクセスチケット４８ａ，４８ｂ，・・・それぞれを、ヘッダに示されるＵＲＬに送信する。複数のサーバ１００ａ，１００ｂ，・・・それぞれからは、ユーザ３２の運転データ４９ａ，４９ｂ，・・・がサーバ２００に送信される。サーバ２００内の保険料見積もり部２１０は、運転データ４９ａ，４９ｂ，・・・に基づいてユーザ３２の運転の傾向を判断し、保険料を算出する。そして保険料見積もり部２１０は、保険料の見積もり結果を、端末装置３００に送信する。
【０１１４】
このように、複数のサービスに関するアクセスチケットを、プラットフォームサービス用のサーバ６００に管理させることで、複数のレンタカーサービスにおける運転データの取得が容易となる。
【０１１５】
なお、プラットフォームサービスでは、ユーザが希望するときにアクセスチケットを提供できるようになっていればよい。図１７の例では、サーバ６００上で管理する方法を記述しているが、例えばアクセスチケットを端末装置３００内のアプリケーションソフトウェアで管理してもよい。その場合、ユーザ３２は、保険料の見積もりの際のアクセスチケット要求に対して、端末装置３００内に保存されたアクセスチケットの中から、送信するアクセスチケットを選択する。端末装置３００は、ユーザが選択したアクセスチケットを、自動車保険サービス用のサーバ２００に送信する。
【０１１６】
また、アクセスチケットをユーザ３２が選択するためには、選択の根拠となる情報があると便利である。そこでサーバ１００ａ，１００ｂ，・・・は、アクセスチケットに、そのアクセスチケットの内容に関する情報を付与しておいてもよい。この場合、端末装置３００は、ユーザ３２からのアクセスチケットの選択を受け付ける際に、各アクセスチケットの内容に関する情報を表示する。これにより、ユーザ３２の希望通りのアクセスチケットを選択するのが容易となる。アクセスチケットの内容に関する情報は、例えば、サービス名、レンタカーであれば、レンタル期間、車の名称などである。この情報は、例えば、アクセスチケットのヘッダに含めることができる。また端末装置３００が、アクセスチケットの内容に関する情報を、アクセスチケットとは別に、サーバ１００ａ，１００ｂ，・・・、またはサーバ６００から取得してもよい。
【０１１７】
［第６の実施の形態］
次に第６の実施の形態について説明する。第６の実施の形態は、海外ツアーサービスにおいて、アクセスチケットを用いたデータへのアクセス権限を管理するものである。第６の実施の形態では、ユーザ３２がツアーに参加する場合に、アクセスチケットを用いて、飛行機やホテルの予約データに対するアクセス権限を、旅行代理店やオプショナルツアーの企画会社に与える。
【０１１８】
図１８は、第６の実施の形態におけるシステムの一例を示す図である。第６の実施の形態では、複数のサーバ７１０，７２０，７３０，７４０と端末装置３００とが連携して処理を行う。
【０１１９】
サーバ７１０は、航空会社が管理するフライトサービス用のサーバコンピュータである。サーバ７１０は、フライト予約情報記憶部７１１、予約受付部７１２、アクセスチケット生成部７１３、およびアクセスチケット実行部７１４を有する。フライト予約情報記憶部７１１は、飛行機の座席の予約内容を示す情報（フライト予約情報）を記憶する。予約受付部７１２は、飛行機の座席予約を受け付ける。アクセスチケット生成部７１３は、フライト予約情報へのアクセス権限を示すアクセスチケット５１を生成する。アクセスチケット実行部７１４は、アクセスチケット５１に含まれるスクリプトを実行することで、フライト予約情報記憶部７１１から、ユーザ３２のフライト予約情報５３を取得する。
【０１２０】
図１９は、フライト予約情報記憶部の一例を示す図である。フライト予約情報記憶部７１１には、例えばフライト予約管理テーブル７１１ａが格納されている。フライト予約管理テーブル７１１ａには、フライト予約ごとに、ユーザＩＤ、ツアーＩＤ、フライトＩＤ、出発地、目的地、出発時刻、および到着時刻などを含むレコードが登録されている。
【０１２１】
以下、図１８の説明に戻る。
サーバ７２０は、ホテル運営会社が管理するホテルサービス用のサーバコンピュータである。サーバ７２０は、ホテル予約情報記憶部７２１、予約受付部７２２、アクセスチケット生成部７２３、およびアクセスチケット実行部７２４を有する。ホテル予約情報記憶部７２１は、ホテルの予約内容を示す情報（ホテル予約情報）を記憶する。予約受付部７２２は、ホテルの予約を受け付ける。アクセスチケット生成部７２３は、ホテル予約情報へのアクセス権限を示すアクセスチケット５２を生成する。アクセスチケット実行部７２４は、アクセスチケット５２に含まれるスクリプトを実行することで、ホテル予約情報記憶部７２１から、ユーザ３２のホテル予約情報５４を取得する。
【０１２２】
図２０は、ホテル予約情報記憶部の一例を示す図である。ホテル予約情報記憶部７２１には、例えばホテル予約管理テーブル７２１ａが格納されている。ホテル予約管理テーブル７２１ａには、ホテル予約ごとに、ユーザＩＤ、ツアーＩＤ、ホテル名、ホテルの場所、チェックイン日、及びチェックアウト日などを含むレコードが登録されている。
【０１２３】
以下、図１８の説明に戻る。
サーバ７３０は、ツアー企画会社が管理するツアーサービス用のサーバコンピュータである。サーバ７３０は、アクセスチケット記憶部７３１とツアー予約管理部７３２とを有する。アクセスチケット記憶部７３１は、各顧客のアクセスチケット５１，５２を記憶する。ツアー予約管理部７３２は、ユーザ３２からのツアー参加申し込みに応じて、飛行機の座席の予約や、宿泊先となるホテルの予約処理を行う。またツアー予約管理部７３２は、アクセスチケット代理取得処理も行う。
【０１２４】
サーバ７４０は、オプショナルツアーを企画する会社が管理するオプショナルツアーサービス用のサーバコンピュータである。サーバ７４０は、オプショナルツアー予約管理部７４１を有する。オプショナルツアー予約管理部７４１は、ユーザ３２のフライト予約情報５３やホテル予約情報５４に基づいて、ユーザ３２が参加可能なオプショナルツアーを判断し、そのオプショナルツアーをユーザ３２に提示する。
【０１２５】
ユーザ３２は、例えば端末装置３００を用いてツアーサービス用のサーバ７３０にアクセスし、ツアーの予約申し込みを行う。サーバ７３０内のツアー予約管理部７３２は、端末装置３００からのツアー予約申し込みに応じて、フライトサービス用のサーバ７１０に対して、飛行機の座席の予約（フライト予約）を要求する。サーバ７１０内の予約受付部７１２は、フライト予約の要求に応じて、ユーザ３２のための飛行機の座席を予約する。さらに予約受付部７１２は、フライト予約情報記憶部７１１に、フライト予約情報を格納する。フライト予約が完了すると、アクセスチケット生成部７１３は、フライト予約情報へのアクセス権限を示すアクセスチケット５１を生成し、サーバ７３０に送信する。アクセスチケット５１には、ユーザ３２のフライト予約情報を取得するための命令が記述されたスクリプトが含まれる。
【０１２６】
図２１は、フライト予約情報のアクセスチケットに含まれるスクリプトの一例を示す図である。スクリプト５１ａには、例えば、ツアーＩＤとユーザＩＤとを指定してフライト予約情報を取得するＳＱＬ文（SELECT * FROM flight_data WHERE tourid = ‘tour0001’ AND userid = ‘user0001’;）が含まれる。
【０１２７】
以下、図１８の説明に戻る。
さらに、ツアー予約管理部７３２は、端末装置３００からのツアー予約申し込みに応じて、ホテルサービス用のサーバ７２０に対して、ホテルの部屋の予約（ホテル予約）を要求する。サーバ７２０内の予約受付部７２２は、ホテル予約の要求に応じて、ユーザ３２が宿泊するホテルの部屋を予約する。さらに予約受付部７２２は、ホテル予約情報記憶部７２１に、ホテル予約情報を格納する。ホテル予約が完了すると、アクセスチケット生成部７２３は、ホテル予約情報へのアクセス権限を示すアクセスチケット５２を生成し、サーバ７３０に送信する。アクセスチケット５２には、ユーザ３２のホテル予約情報を取得するための命令が記述されたスクリプトが含まれる。
【０１２８】
図２２は、ホテル予約情報のアクセスチケットに含まれるスクリプトの一例を示す図である。スクリプト５２ａには、例えば、ツアーＩＤとユーザＩＤとを指定してホテル予約情報を取得するＳＱＬ文（SELECT * FROM hotel_data WHERE tourid = ‘tour0001’ AND userid = ‘user0001’;）が含まれる。
【０１２９】
以下、図１８の説明に戻る。
サーバ７３０では、サーバ７１０，７２０から送られたアクセスチケット５１，５２を、ツアー予約管理部７３２が受信する。ツアー予約管理部７３２は、受信したアクセスチケット５１，５２を、アクセスチケット記憶部７３１に格納する。
【０１３０】
ここで、ユーザ３２は、旅行先においてオプショナルツアーに参加することを検討しているものとする。その場合、ユーザ３２は、ツアー予約申し込みを行った後、端末装置３００を用いて、オプショナルツアーサービス用のサーバ７４０にアクセスする。そしてユーザ３２は、端末装置３００に、参加可能なオプショナルツアーの表示指示を入力する。すると端末装置３００のアクセスチケット管理部３１０は、サーバ７４０に対して、オプショナルツアー提案要求を送信する。
【０１３１】
端末装置３００が送信したオプショナルツアー提案要求は、サーバ７４０のオプショナルツアー予約管理部７４１が受信する。オプショナルツアー予約管理部７４１は、オプショナルツアー提案要求を受信すると、端末装置３００に対して、アクセスチケット要求を送信する。
【０１３２】
端末装置３００では、アクセスチケット管理部３１０がアクセスチケット要求を受信する。するとアクセスチケット管理部３１０は、サーバ７３０に対してアクセスチケット要求を送信する。サーバ７３０のツアー予約管理部７３２は、端末装置３００からのアクセスチケット要求に応じて、ユーザ３２が予約したツアーに関するアクセスチケット５１，５２をアクセスチケット記憶部７３１から取得する。そしてツアー予約管理部７３２は、取得したアクセスチケット５１，５２を、端末装置３００に送信する。
【０１３３】
端末装置３００のアクセスチケット管理部３１０は、サーバ７３０から送られたアクセスチケット５１，５２を受信する。そしてアクセスチケット管理部３１０は、アクセスチケット５１，５２をサーバ７４０に送信する。
【０１３４】
オプショナルツアーサービス用のサーバ７４０では、オプショナルツアー予約管理部７４１が、アクセスチケット５１，５２を受信する。そしてオプショナルツアー予約管理部７４１は、アクセスチケット５１を、フライトサービス用のサーバ７１０に送信する。サーバ７１０では、アクセスチケット実行部７１４がアクセスチケット５１を受信する。アクセスチケット実行部７１４は、アクセスチケット５１のペイロードに含まれるスクリプト５１ａ（図２１参照）を実行する。その結果、アクセスチケット実行部７１４は、フライト予約情報記憶部７１１から、ユーザ３２のフライト予約情報５３を取得する。アクセスチケット実行部７１４は、取得したフライト予約情報５３をサーバ７４０に送信する。
【０１３５】
またオプショナルツアー予約管理部７４１は、アクセスチケット５２を、ホテルサービス用のサーバ７２０に送信する。サーバ７２０では、アクセスチケット実行部７２４がアクセスチケット５２を受信する。アクセスチケット実行部７２４は、アクセスチケット５２のペイロードに含まれるスクリプト５２ａ（図２２参照）を実行する。その結果、アクセスチケット実行部７２４は、ホテル予約情報記憶部７２１から、ユーザ３２のホテル予約情報５４を取得する。アクセスチケット実行部７２４は、取得したホテル予約情報５４をサーバ７４０に送信する。
【０１３６】
サーバ７４０内のオプショナルツアー予約管理部７４１は、サーバ７１０から送られたフライト予約情報５３を受信する。またオプショナルツアー予約管理部７４１は、サーバ７２０から送られたホテル予約情報５４を受信する。オプショナルツアー予約管理部７４１は、フライト予約情報５３とホテル予約情報５４とに基づいて、ユーザ３２の大まかなツアースケジュールを把握する。そしてオプショナルツアー予約管理部７４１は、予め用意されたオプショナルツアーリストの中から、ユーザ３２のツアースケジュールに基づいて、ユーザ３２が参加可能なオプショナルツアーを抽出する。オプショナルツアー予約管理部７４１は、抽出したオプショナルツアーに関する情報を、オプショナルツアー提案情報として、端末装置３００に送信する。
【０１３７】
端末装置３００のアクセスチケット管理部３１０は、オプショナルツアー提案情報に示されるオプショナルツアーの情報をモニタに表示する。ユーザ３２は、表示されたオプショナルツアーの情報に基づいて、参加するオプショナルツアーを選択し、そのオプショナルツアーの申し込みを行う。
【０１３８】
このようにして、ユーザ３２は、オプショナルツアーサービス用のサーバ７４０にアクセスチケット５１，５２を渡すだけで、自身が参加するツアーに適したオプショナルツアーの提案を受けることができる。これにより、オプショナルツアーの選択が容易となる。
【０１３９】
なお図１８の例では、端末装置３００は、サーバ７３０からアクセスチケット５１，５２を取得しているが、サーバ７１０，７２０それぞれからアクセスチケット５１，５２を取得することもできる。
【０１４０】
［第７の実施の形態］
次に第７の実施の形態について説明する。第２〜第６の実施の形態ではデータベースに保存されたデータへのアクセス権限を取り扱ったが、データ以外の資源へのアクセス権限を、アクセスチケットで管理することも可能である。そこで、第７の実施の形態では、アクセスチケットのペイロードに含ませたスクリプトにより、デバイスを制御する。
【０１４１】
図２３は、第７の実施の形態におけるシステムの一例を示す図である。第７の実施の形態では、複数のサーバ８１０，８２０と端末装置３００とが連携して処理を行う。
サーバ８１０は、ホテルを運営する企業により管理されている、ホテルサービス用のサーバコンピュータである。サーバ８１０は、ホテル予約情報記憶部８１１、予約受付部８１２、アクセスチケット生成部８１３、およびアクセスチケット実行部８１４を有する。
【０１４２】
ホテル予約情報記憶部８１１は、ホテルの部屋の予約情報を記憶する。例えばホテル予約情報記憶部８１１は、予約したユーザ３２の識別子（ユーザＩＤ）に対応付けて、宿泊するホテルのホテル名、予約した部屋の部屋番号、宿泊期間などの情報を、予約情報として記憶する。
【０１４３】
予約受付部８１２は、ホテルの部屋の予約を受け付け、予約情報をホテル予約情報記憶部８１１に格納する。アクセスチケット生成部８１３は、ホテル予約情報に基づいて、ユーザ３２が予約した部屋のドア８１６を解錠するためのアクセスチケット６１を生成する。アクセスチケット実行部８１４は、ドア８１６の電子ロック部８１５に接続されている。電子ロック部８１５は、ドア８１６の施錠・解錠を電子的に行う装置である。アクセスチケット実行部８１４は、アクセスチケット６１を受け取ると、アクセスチケット６１に含まれるスクリプトを実行することにより、電子ロック部８１５に解錠指示を送信する。電子ロック部８１５は、解錠指示に従って、ドア８１６を解錠する。
【０１４４】
図２４は、部屋のドアを解錠するためのスクリプトの一例を示す図である。図２４に示すスクリプト６１ａが、アクセスチケット６１のペイロードに格納される。スクリプト６１ａの最初の２行は、アクセスチケット６１の使用可能期間を示している。１行目が使用開始日時を示し、２行目が使用終了日時を示す。以下の命令文が、使用可能期間内であれば、鍵を解錠する命令文である。
if (now >= begindate&& now < enddate) { 
WoT.discover({devid: “dev0001”}).subscribe(
thing => {
thing.invokeAction(“unlock”);
この命令文を実行すると、ＩＤが「ｄｅｖ０００１」であるデバイスを発見しようとするＡＰＩが呼び出され、その結果として、デバイスのインスタンスである「thing」が得られる。そして、インスタンスに対して「unlock」のActionが実行される。その結果、ドア８１６の鍵が開く。
【０１４５】
以下、図２３の説明に戻る。
サーバ８２０は、ホテル予約代行サービスを行う企業により管理されている、ホテル予約代行サービス用のサーバコンピュータである。サーバ８２０は、ホテル予約管理部８２１を有する。ホテル予約管理部８２１は、ユーザ３２が使用する端末装置３００からの、宿泊するホテルの指定に応じて、該当ホテルのサーバ８１０にアクセスし、部屋を予約する。ホテル予約管理部８２１は、予約した部屋の鍵を解錠するためのアクセスチケット６１をサーバ８１０から受け取り、そのアクセスチケット６１を端末装置３００に送信する。
【０１４６】
端末装置３００は、アクセスチケット管理部３１０に加え、アクセスチケット記憶部３２０を有している。アクセスチケット記憶部３２０は、アクセスチケット６１を記憶する。アクセスチケット管理部３１０は、ユーザ３２からの入力に応じて、宿泊ホテル指定をサーバ８２０に送信し、アクセスチケット６１を取得する。アクセスチケット管理部３１０は、取得したアクセスチケット６１を、アクセスチケット記憶部３２０に格納する。またアクセスチケット管理部３１０は、ユーザ３２からの指示に基づいて、アクセスチケット６１をアクセスチケット記憶部３２０から読み出し、サーバ８１０に送信する。
【０１４７】
このようなシステムにおいて、ユーザ３２は、まず端末装置３００を操作し、宿泊するホテルを選択する。すると端末装置３００のアクセスチケット管理部３１０から、サーバ８２０に宿泊ホテルの指定が送信される。サーバ８２０のホテル予約管理部８２１は、指定されたホテルのサーバ８１０へ予約要求を送信する。サーバ８１０では、予約受付部８１２が予約を受け付け、予約内容をホテル予約情報記憶部８１１に格納する。するとアクセスチケット生成部８１３がアクセスチケット６１を生成し、サーバ８２０に送信する。アクセスチケット６１を受信したホテル予約管理部８２１は、そのアクセスチケット６１を端末装置３００に送信する。端末装置３００では、アクセスチケット管理部３１０が、アクセスチケット６１をアクセスチケット記憶部３２０に格納する。これで、ホテルの部屋の予約が完了する。
【０１４８】
宿泊当日になり、ユーザ３２がホテルに到着すると、ユーザ３２は、宿泊する部屋の前で端末装置３００を操作し、ドア８１６の解錠指示の入力を行う。すると端末装置３００は、アクセスチケット６１をサーバ８１０に送信する。サーバ８１０のアクセスチケット実行部８１４は、アクセスチケット６１に含まれるスクリプト６１ａを実行する。実行した日時がアクセスチケット６１の使用可能期間内であれば、アクセスチケット実行部８１４から電子ロック部８１５に、解錠の指示が送信される。その結果、ドア８１６が解錠される。
【０１４９】
このように第７の実施の形態では、アクセスチケット６１により、データを取得するのではなく、デバイスＩＤをもとにデバイスを制御するためのオブジェクトが取得される。そして、サーバ８１０が、そのオブジェクトが持つＡＰＩを呼び出すことで、実際にデバイスが制御される。すなわち、第７の実施の形態におけるアクセスチケット６１は、データの参照のアクセス権限を示しているのではなく、電子ロック部８１５の解錠制御をする権限を示している。
【０１５０】
このようにして、アクセスチケット６１によりドア８１６を解錠できることで、ユーザ３２は、ホテルのフロントなどでの鍵の受け取りを行わずにすむ。例えば、一般の民家の部屋を旅行者に貸し出す場合、ホテルのフロントのような行き届いたサービスを行うのは難しい。そこで図２４に示したシステムで、部屋の鍵を解錠するためのアクセスチケット６１を予め旅行者に送信するようにすれば、部屋の鍵の受け渡しの手間が軽減される。
【０１５１】
［第８の実施の形態］
次に第８の実施の形態について説明する。第８の実施の形態は、アクセスチケットの利用者を制限できるようにしたものである。
【０１５２】
第２〜第７の実施の形態では、アクセスチケットをサーバに送信することで、送信者がだれであっても、アクセスチケットに含まれるスクリプトが認証なしで実行される。これは、利便性の上で利点ではあるが、アクセスチケットを無制限にコピーされると、システムの信頼性の低下を招く。そこで第８の実施の形態では、アクセスチケットの送信を指示したユーザの認証を行うことで、アクセスチケットの利用者を制限する。
【０１５３】
アクセスチケットの利用者は、プラットフォームとして用意されたサーバで管理する。そこで、利用者を管理するために、予めプラットフォームとして機能するサーバに、ユーザ登録が行われる。
【０１５４】
図２５は、第８の実施の形態におけるユーザ登録処理の一例を示す図である。例えばアクセスチケットの発行元であるサーバ８３０から、そのサーバ８３０の管理者の認証情報（サービスＩＤとパスワード）と、ネットワーク上でサーバ８３０を特定するためのＵＲＬとが、プラットフォームとして機能するサーバ８５０に送信される。サーバ８５０は、サーバ８３０から送られた情報を、内部の認証情報記憶部８５１に登録する。
【０１５５】
またアクセスチケットを使用する可能性のあるサーバ８４０から、そのサーバ８４０の管理者の認証情報（サービスＩＤとパスワード）と、ネットワーク上でサーバ８４０を特定するためのＵＲＬとが、サーバ８５０に送信される。サーバ８５０は、サーバ８４０から送られた情報を、内部の認証情報記憶部８５１に登録する。
【０１５６】
図２６は、第８の実施の形態におけるアクセスチケットの利用状況を示す図である。ユーザ３２は、第２の実施の形態と同様にして、サーバ８３０からアクセスチケット６２を取得する。この際、サーバ８３０は、アクセスチケット６２のヘッダに、アクセスチケットを利用してよいサービスのサービスＩＤを付加する。図２６の例では、サーバ８４０に対応するサービスＩＤ（ｉｄ２）が付加される。
【０１５７】
また、図２７に示すように、サーバ８５０に、通信ログ記憶部８５２を設けることもできる。サーバ８５０は、他のサーバ８３０，８４０と通信した履歴（通信内容を示す情報）を、通信ログ記憶部８５２に記録する。通信履歴を通信ログ記憶部８５２に記録することで、アクセスチケットや、アクセスチケットによって取得したデータがどのように移動したかを把握することができる。アクセスチケットとデータとの送受信状況を把握することで、情報漏洩が起こった場合の調査が容易となる。
【０１５８】
なお、ヘッダが改ざんされることを防ぐために、サーバ８３０は、アクセスチケット６２に対して、サーバ８３０の署名を付加してもよい。また、サーバ８４０は、サービスＩＤをヘッダではなくペイロードに含めてもよい。
【０１５９】
さらに、アクセスチケット６２のヘッダに付加するサービスＩＤは、サーバ８３０ではなく、端末装置３００が付与してもよい。その場合には、端末装置３００が、アクセスチケット６２に署名を付加する。端末装置３００が署名を付加した場合、サーバ８３０による署名の正当性の検証用に、端末装置３００は、サーバ８３０に証明書を送信する。サーバ８３０は、証明書を保存し、その証明書に基づいて、サーバ８５０から送られたアクセスチケット６２の正当性を検証する。
【０１６０】
図２６に示したようなサービスＩＤによるアクセスチケットの利用者の制限機能は、第２〜第７の実施の形態のいずれかのシステムに実装することができる。以下、レンタカーの運転データを、特定の自動車保険サービス提供会社が運用するサーバでのみ取得できるようにしたシステムの例を説明する。
【０１６１】
図２７は、アクセスチケットの利用者の制限機能を有するシステムの一例を示す図である。図２７の例では、サーバ８３０は、レンタカーサービス用のサーバコンピュータである。サーバ８４０は、自動車保険サービス用のサーバコンピュータである。サーバ８５０は、プラットフォームサービス用のサーバコンピュータである。
【０１６２】
サーバ８３０は、データベース８３１、契約管理部８３２、運転データ取得部８３３、アクセスチケット生成部８３４、およびアクセスチケット実行部８３５を有する。サーバ８３０内の各要素は、図４に示した第２の実施の形態のサーバ１００における同名の要素と同じ機能を有する。なお、アクセスチケット生成部８３４は、さらに、アクセスチケット６２に、そのアクセスチケット６２を使用できるサーバを示すサービスＩＤを付加することができる。
【０１６３】
サーバ８４０は、保険料見積もり部８４１を有する。保険料見積もり部８４１は、図４に示した第２の実施の形態のサーバ２００における同名の要素と同じ機能を有すると共に、アクセス要求にサービスＩＤを追加する機能を有する。すなわち、サーバ８４０は、アクセスチケット６２を端末装置３００に要求する際に、自身のサービスＩＤを端末装置３００に通知する。端末装置３００は、サーバ８４０のサービスＩＤを付与したアクセスチケット要求をサーバ１００に送信する。
【０１６４】
図２８は、サービスＩＤを含むアクセスチケット要求の一例を示す図である。図２８に示すように、アクセスチケット要求６３には、アクセスチケットを利用するユーザのＩＤとして、サービスＩＤ（“userid”:“service2”）が設定されている。またアクセスチケット要求６３には、アクセス可能期間の開始日時（“startdatetime”:”2017-05-01T12:00:00”）と終了日時（“enddatetime”:”2017-05-01T14:00:00”）とが示されている。
【０１６５】
アクセスチケット要求６３を受信したサーバ８３０は、アクセスチケット要求６３に示されたサービスＩＤおよびアクセス可能期間を示す情報をヘッダに含むアクセスチケット６２を生成し、そのアクセスチケット６２を端末装置３００に送信する。
【０１６６】
図２９は、サービスＩＤを含むアクセスチケットの一例を示す図である。図２９に示すアクセスチケット６２には、アクセスチケットを利用するユーザのＩＤとして、サービスＩＤ（“userid”:“service2”）が設定されている。なおアクセスチケット６２のペイロード内のデータは暗号化されている。
【０１６７】
以下、図２７に示したシステムにおけるアクセスチケットを用いた保険料見積もり処理について説明する。
図３０は、第８の実施の形態におけるアクセスチケットを用いた保険料見積もり処理の手順の一例を示すシーケンス図である。
【０１６８】
端末装置３００のアクセスチケット管理部３１０は、自動車保険サービス用のサーバ８４０に、サービスＩＤ付きのアクセスチケット６２を送信する（ステップＳ２０１）。サーバ８４０の保険料見積もり部８４１は、アクセスチケット６２を受信する（ステップＳ２０２）。次に保険料見積もり部８４１は、アクセスチケット６２のヘッダに基づいて、運転データの取得先のＵＲＬを確認する（ステップＳ２０３）。そして保険料見積もり部８４１は、プラットフォームサービス用のサーバ８５０へ、認証情報とアクセスチケット６２とを送信する（ステップＳ２０４）。例えば保険料見積もり部８４１は、プラットフォーム用のサーバ８５０のＡＰＩを呼び出して、アクセスチケット６２を送信する。この際、保険料見積もり部８４１は、例えばアクセスチケットの取得先を、ステップＳ２０３で確認したＵＲＬで指定する。
【０１６９】
サーバ８５０の運転データ代理取得部８５３は、サーバ８４０の認証情報に基づいて、サーバ８４０の認証を行うと共に、アクセスチケット６２を受信する（ステップＳ２０５）。運転データ代理取得部８５３は、サーバ８４０のサービスＩＤを示す利用サービス情報とアクセスチケットとをレンタカーサービス用のサーバ８３０に送信する（ステップＳ２０６）。そして運転データ代理取得部８５３は、転送したアクセスチケット６２に関する情報を、通信ログ記憶部８５２に格納する（ステップＳ２０７）。
【０１７０】
サーバ８３０内のアクセスチケット実行部８３５は、アクセスチケット６２を受信する（ステップＳ２０８）。次にアクセスチケット実行部８３５は、ペイロード内の暗号データを復号する（ステップＳ２０９）。この際、アクセスチケット実行部８３５は、アクセスチケット６２のヘッダに示されているサービスＩＤと、利用サービス情報に含まれるサービスＩＤとが一致することを確認する。そしてアクセスチケット実行部８３５は、サービスＩＤが一致すると、アクセスチケット６２のペイロード内の暗号データを復号する。そしてアクセスチケット実行部８３５は、復号によって得られたスクリプトを実行する（ステップＳ２１０）。スクリプトの実行により、運転データ４１が得られる。アクセスチケット実行部８３５は、サーバ８４０のサービスＩＤを付与した運転データ４１を、サーバ８５０に送信する（ステップＳ２１１）。
【０１７１】
サーバ８５０の運転データ代理取得部８５３は、サービスＩＤを付与した運転データ４１を受信する（ステップＳ２１２）。その後、運転データ代理取得部８５３は、サーバ８３０から受信した運転データ４１に付与されたサービスＩＤによって、受信したデータがサーバ８４０への運転データ４１であることを認識し、その運転データ４１をサーバ８４０に送信する（ステップＳ２１３）。そして運転データ代理取得部８５３は、転送した運転データ４１に関する情報を、通信ログ記憶部８５２に格納する（ステップＳ２１４）。
【０１７２】
サーバ８４０の保険料見積もり部８４１は、運転データ４１を受信する（ステップＳ２１５）。保険料見積もり部８４１は、運転データ４１に基づいて、ユーザ３２の保険料を計算する（ステップＳ２１６）。そして保険料見積もり部８４１は、計算した保険料を示す見積もり結果を端末装置３００に送信する（ステップＳ２１７）。端末装置３００では、アクセスチケット管理部３１０が、見積もり結果を受信し、見積もり結果に示される保険料をモニタに表示する（ステップＳ２１８）。
【０１７３】
このようにして、サービスＩＤによって、アクセスチケット６２を利用できるサーバを制限することができる。これにより、ユーザ３２の個人情報である運転データ４１が不正に利用されることを抑止することができる。
【０１７４】
なお上記の例では、プラットフォームサービス用のサーバ８５０によって、サーバ８４０の認証処理を行っているが、レンタカーサービス用のサーバ８３０が認証処理を行ってもよい。
【０１７５】
［第９の実施の形態］
次に第９の実施の形態について説明する。第９の実施の形態は、ペイロードにはインデックスのみを書いておき、コマンド自身は別の場所で管理するものである。例えばアクセスチケットを発行するサーバが、コマンドを識別するコマンドＩＤとコマンドとを対応付けて保持する。
【０１７６】
図３１は、第９の実施の形態におけるシステムの一例を示す図である。図３１の例では、サーバ８６０は、レンタカーサービス用のサーバコンピュータである。サーバ８７０は、自動車保険サービス用のサーバコンピュータである。
【０１７７】
サーバ８６０は、データベース８６１、契約管理部８６２、運転データ取得部８６３、アクセスチケット生成部８６４、アクセスチケット実行部８６５、およびスクリプト記憶部８６６を有する。データベース８６１、契約管理部８６２、および運転データ取得部８６３は、図４に示した第２の実施の形態のサーバ１００における同名の要素と同じ機能を有する。
【０１７８】
アクセスチケット生成部８６４は、アクセスチケット要求を受信すると、データベース８６１内の運転データ４１を取得するためのスクリプトにスクリプトＩＤを付与して、スクリプト記憶部８６６に格納する。そしてアクセスチケット生成部８６４は、ペイロードにスクリプトＩＤを含むアクセスチケット６４を生成する。
【０１７９】
アクセスチケット実行部８６５は、アクセスチケット６４を受信すると、アクセスチケット６４に含まれるスクリプトＩＤに対応するスクリプトを、スクリプト記憶部８６６から取得する。次にアクセスチケット実行部８６５は、スクリプト記憶部８６６から取得したスクリプトを実行することで、データベース８６１から運転データ４１を取得する。そして次にアクセスチケット実行部８６５は、アクセスチケット６４の送信元のサーバ８７０に、運転データ４１を送信する。
【０１８０】
スクリプト記憶部８６６は、スクリプトＩＤとスクリプトとの組を記憶する。
自動車保険サービス用のサーバ８７０は、保険料見積もり部８７１を有する。保険料見積もり８７１は、図４に示した第２の実施の形態のサーバ２００における同名の要素と同じ機能を有する。
【０１８１】
図３２は、スクリプトＩＤを含むアクセスチケットの一例を示す図である。アクセスチケット６４のペイロードには、スクリプトＩＤ（"0x12345678"）のみが設定されている。
以下、図３１に示したシステムにおけるアクセスチケットを用いた保険料見積もり処理について説明する。
【０１８２】
図３３は、第９の実施の形態におけるアクセスチケットを用いた保険料見積もり処理の手順の一例を示すシーケンス図である。
端末装置３００のアクセスチケット管理部３１０は、自動車保険サービス用のサーバ８７０に、スクリプトＩＤ付きのアクセスチケット６４を送信する（ステップＳ３０１）。サーバ８７０の保険料見積もり部８７１は、アクセスチケット６４を受信する（ステップＳ３０２）。次に保険料見積もり部８７１は、アクセスチケット６４のヘッダに基づいて、運転データの取得先のＵＲＬを確認する（ステップＳ３０３）。そして保険料見積もり部８７１は、レンタカーサービス用のサーバ８６０へ、アクセスチケット６４を送信する（ステップＳ３０４）。
【０１８３】
サーバ８６０内のアクセスチケット実行部８６５は、アクセスチケット６４を受信する（ステップＳ３０５）。次にアクセスチケット実行部８６５は、ペイロード内のスクリプトＩＤに対応するスクリプトを、スクリプト記憶部８６６から取得する（ステップＳ３０６）。そしてアクセスチケット実行部８６５は、取得したスクリプトを実行する（ステップＳ３０７）。スクリプトの実行により、運転データ４１が得られる。アクセスチケット実行部８６５は、運転データ４１をサーバ８７０に送信する（ステップＳ３０８）。
【０１８４】
サーバ８７０の保険料見積もり部８７１は、運転データ４１を受信する（ステップＳ３０９）。保険料見積もり部８７１は、運転データ４１に基づいて、ユーザ３２の保険料を計算する（ステップＳ３１０）。そして保険料見積もり部８７１は、計算した保険料を示す見積もり結果を端末装置３００に送信する（ステップＳ３１１）。端末装置３００では、アクセスチケット管理部３１０が、見積もり結果を受信し、見積もり結果に示される保険料をモニタに表示する（ステップＳ３１２）。
【０１８５】
このようにして、ユーザ３２の運転データ４１を取得するスクリプトをサーバ８６０の外部に出さずに、サーバ８７０からのアクセスチケット６４に応じて、そのスクリプトを実行することができる。スクリプトをサーバ８６０の外部に出さないことで、スクリプトの内容が不正に書き換えられることを抑止できる。
【０１８６】
［その他の実施の形態］
アクセスチケットの受け渡しを、プラットフォームが用意するＡＰＩ経由で行ってもよい。アクセスチケットを送信するサーバ（例えば自動車保険サービス用のサーバ）はＡＰＩの引数として送信先のサーバ（例えばレンタカーサービス用のサーバ）のサービスＩＤを指定する。プラットフォーム用のサーバは、サービスＩＤに対応するＵＲＬを取得して、そのＵＲＬに対してアクセスチケットを送信する。これにより、アクセスチケットが不正にコピーされて利用されることを抑止できる。
【０１８７】
また、アクセスチケットの利用回数を制限することで、不正利用を抑止することもできる。例えばアクセスチケットを発行するサーバ（例えばレンタカーサービス用のサーバ）は、アクセスチケットのヘッダにアクセスチケットごとに異なるＩＤを付加すると共に、ＩＤごとの利用可能回数を記憶する。そして、そのサーバは、アクセスチケットを受信したときに、付加されたＩＤを確認し、ＩＤごとのアクセスチケット利用回数をカウントし、利用可能回数を超えた場合には、データを送信しない。
【０１８８】
また、アクセスチケットを利用するサーバ（例えば自動車保険サービス用のサーバ）は、アクセスチケットの発行元のサーバ（例えばレンタカーサービス用のサーバ）に、アクセスチケットと共に暗号鍵を送信してもよい。この場合、アクセスチケットの発行元のサーバは、アクセスチケットに基づいて取得したデータを、暗号鍵で暗号化して、アクセスチケットを利用するサーバに送信する。アクセスチケットを利用するサーバは、受信したデータを復号後、そのデータを用いたサービスを実行する。これにより、ユーザ３２の個人データの安全性を高めることができる。
【０１８９】
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。
【符号の説明】
【０１９０】
１，２  自動車
１ａ，２ａ  ＩｏＴデバイス
３  第１装置
４  第２装置
５  取得要求
６  チケット
６ａ  コマンド情報
７  個人データ
８  ネットワーク
９  ユーザ
１０  情報処理装置
１１  記憶部
１１ａ  利用可能資源情報
１１ｂ，１１ｃ  取得データ
１２  処理部
【図１】
2019113981.tif 000003
【図２】
2019113981.tif 000004
【図３】
2019113981.tif 000005
【図４】
2019113981.tif 000006
【図５】
2019113981.tif 000007
【図６】
2019113981.tif 000008
【図７】
2019113981.tif 000009
【図８】
2019113981.tif 000010
【図９】
2019113981.tif 000011
【図１０】
2019113981.tif 000012
【図１１】
2019113981.tif 000013
【図１２】
2019113981.tif 000014
【図１３】
2019113981.tif 000015
【図１４】
2019113981.tif 000016
【図１５】
2019113981.tif 000017
【図１６】
2019113981.tif 000018
【図１７】
2019113981.tif 000019
【図１８】
2019113981.tif 000020
【図１９】
2019113981.tif 000021
【図２０】
2019113981.tif 000022
【図２１】
2019113981.tif 000023
【図２２】
2019113981.tif 000024
【図２３】
2019113981.tif 000025
【図２４】
2019113981.tif 000026
【図２５】
2019113981.tif 000027
【図２６】
2019113981.tif 000028
【図２７】
2019113981.tif 000029
【図２８】
2019113981.tif 000030
【図２９】
2019113981.tif 000031
【図３０】
2019113981.tif 000032
【図３１】
2019113981.tif 000033
【図３２】
2019113981.tif 000034
【図３３】
2019113981.tif 000035