知財求人 - 知財ポータルサイト「IP Force」
特許7284396情報処理装置、データアクセス制御プログラム及びデータアクセス制御システム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-05-23
(45)【発行日】2023-05-31
(54)【発明の名称】情報処理装置、データアクセス制御プログラム及びデータアクセス制御システム
(51)【国際特許分類】
G06F 21/60 20130101AFI20230524BHJP
G06F 21/62 20130101ALI20230524BHJP
G06Q 30/0207 20230101ALI20230524BHJP
【ＦＩ】
G06F21/60 340
G06F21/62 345
G06Q30/0207 372
【請求項の数】
7
(21)【出願番号】P 2019091155
(22)【出願日】2019-05-14
(65)【公開番号】P2020187515
(43)【公開日】2020-11-19
【審査請求日】2022-02-08
(73)【特許権者】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(74)【代理人】
【識別番号】100087480
【弁理士】
【氏名又は名称】片山 修平
(72)【発明者】
【氏名】伊藤 栄信
(72)【発明者】
【氏名】坂本 拓也
(72)【発明者】
【氏名】中村 洋介
(72)【発明者】
【氏名】二村 和明
【審査官】吉田 歩
(56)【参考文献】
【文献】特開２００９－３０１２１１（ＪＰ，Ａ）
【文献】特開２００７－２３２６１０（ＪＰ，Ａ）
【文献】特開２０１５－２０１１１１（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ ２１／６０
Ｇ０６Ｆ ２１／６２
Ｇ０６Ｑ ３０／０２０７
(57)【特許請求の範囲】
【請求項1】
ユーザが他者による利用に同意したデータに対してアクセス可能なプログラムを内包するアクセスチケット、前記データを送信する送信条件、及び前記データの送信先の情報、を含むデータアクセス用パラメータを前記送信先の外部装置から受信する受信部と、前記送信先の情報に対応する通知オブジェクトであって、前記送信先に送信したデータをセットし、該データに応じた処理を前記送信先に実行させるための通知オブジェクトを生成し、前記送信先に返信する返信部と、
前記送信条件を満たしたときに、前記アクセスチケットのプログラムを実行してデータを取得し、取得した前記データを前記送信先に送信する送信部と、
を備える情報処理装置。
【請求項2】
前記データアクセス用パラメータは、暗号鍵を含み、前記送信部は、取得した前記データを前記暗号鍵で暗号化して送信する、ことを特徴とする請求項１に記載の情報処理装置。
【請求項3】
前記送信部は、予め定められている終了条件を満たすまで、前記送信条件を満たすか否かを繰り返し判定することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項4】
前記データを受信した前記外部装置からの要求に応じて、前記ユーザが利用する装置に対して前記外部装置に関する情報を提供する提供部、を更に備える請求項１～３のいずれか一項に記載の情報処理装置。
【請求項5】
前記データは、前記ユーザが利用する車の走行に関するデータであり、前記外部装置は、前記車が走行する予定のルートに基づいて特定された店舗の情報処理装置であり、
前記提供部は、前記店舗における前記ユーザの購買意欲を増進させる情報を前記ユーザが利用する装置に提供する、ことを特徴とする請求項４に記載の情報処理装置。
【請求項6】
ユーザが他者による利用に同意したデータに対してアクセス可能なプログラムを内包するアクセスチケット、前記データを送信する送信条件、及び前記データの送信先の情報、を含むデータアクセス用パラメータを前記送信先の外部装置から受信し、前記送信先の情報に対応する通知オブジェクトであって、前記送信先に送信したデータをセットし、該データに応じた処理を前記送信先に実行させるための通知オブジェクトを生成し、前記送信先に返信し、
前記送信条件を満たしたときに、前記アクセスチケットのプログラムを実行してデータを取得し、取得した前記データを前記送信先に送信する、
処理をコンピュータに実行させるためのデータアクセス制御プログラム。
【請求項7】
情報処理装置と外部装置とを備え、前記情報処理装置が有するユーザが他者による利用に同意したデータに対するアクセスを制御するデータアクセス制御システムであって、前記情報処理装置は、
前記データに対してアクセス可能なプログラムを内包するアクセスチケット、前記データを送信する送信条件、及び前記データの送信先の情報、を含むデータアクセス用パラメータを前記送信先の外部装置から受信する受信部と、
前記送信先の情報に対応する通知オブジェクトを生成し、前記送信先に返信する返信部と、
前記送信条件を満たしたときに、前記アクセスチケットのプログラムを実行してデータを取得し、取得した前記データを前記送信先に送信する送信部と、
を備え、
前記外部装置は、前記情報処理装置から送信されてきた前記データを、前記情報処理装置から返信されてきた前記通知オブジェクトにセットし、前記通知オブジェクトにセットした前記データに応じた処理を実行する、
データアクセス制御システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置、データアクセス制御プログラム及びデータアクセス制御システムに関する。
【背景技術】
【0002】
コンピュータシステムでは、様々な資源を用いてサービスが提供される。サービスの提供に用いられる資源には、データまたはプログラムなどのソフトウェア資源や、コンピュータで制御される様々な機器が含まれる。
【0003】
例えばＩｏＴ（Internet of Things）関連技術の発展により、現在、コンピュータに限らず、様々なもの（ＩｏＴデバイス）をインターネットに接続することが可能となっている。ＩｏＴデバイス自身およびＩｏＴから取得したデータも、サービス提供に利用される資源である。
【0004】
ＩｏＴデバイスは、データの収集に利用できる。例えばサービスプロバイダが、クラウドコンピューティングシステムにより、多数のＩｏＴデバイスから、各ＩｏＴデバイスを所持しているユーザに関するデータを収集する。サービスプロバイダは、収集したデータのデータマイニングを行うことで、様々な知識を得ることができる。
【0005】
ＩｏＴデバイスから収集されたデータには、そのＩｏＴデバイスを所持しているユーザの行動の特徴を表すデータが含まれる。そのため、あるユーザが使用するＩｏＴデバイスから収集されたデータは、収集したサービスプロバイダが利用するだけではなく、そのデータを提供したユーザ自身も利用を希望する場合があり得る。例えば、ユーザがＩｏＴデバイスを介して特定のサービスプロバイダ（例えばレンタカー会社のサーバ）に提供したデータを、そのユーザの意思により他のサービスプロバイダ（例えば店舗のサーバ）に提供することで、ユーザが適切なサービスの提供（例えばサービス利用料の割り引き）を受けることができる場合がある。この場合、例えばデータを所持するサービスプロバイダから他のサービスプロバイダに、該当データへのアクセス権限が渡され、他のサービスプロバイダは、アクセス権限に基づいてデータにアクセスする。
【0006】
任意のデータへのアクセス権限に関する技術としては、例えばＯＡｕｔｈがある。また、顧客が認可した範囲で認可トークンを共有できるように制御を行う権限委譲システムも考えられている。アクセス資格の無効化、譲渡、分割、変更などの操作を行えるようにするアクセス権管理装置も考えられている。さらに、ネットワーク上の利用権を動的に利用者に提供できないなどの利用権に関する問題を解決するための資源管理システムも考えられている。
【先行技術文献】
【特許文献】
【0007】
【文献】特開２００３－６１６０号公報
【文献】特開平１１－３２８２５４号公報
【文献】特開２００３－２４２１２４号公報
【発明の概要】
【発明が解決しようとする課題】
【0008】
しかしながら、従来は、ユーザがＩｏＴデバイスを介して特定のサービスプロバイダに提供したデータを、そのユーザの意思により他のサービスプロバイダに提供する際の技術が十分に確立されていなかった。このため、ある条件を満たしたタイミングで、特定のサービスプロバイダが取得したデータを他のサービスプロバイダに提供する、ということを簡易に実現することができなかった。
【0009】
１つの側面では、本発明は、データが送信条件を満たした適切なタイミングで、ユーザが他者からの利用に同意しているデータを外部装置に送信することが可能な情報処理装置、データアクセス制御プログラム及びデータアクセス制御システムを提供することを目的とする。
【課題を解決するための手段】
【0010】
一つの態様では、情報処理装置は、ユーザが他者による利用に同意したデータに対してアクセス可能なプログラムを内包するアクセスチケット、前記データを送信する送信条件、及び前記データの送信先の情報、を含むデータアクセス用パラメータを前記送信先の外部装置から受信する受信部と、前記送信先の情報に対応する通知オブジェクトであって、前記送信先に送信したデータをセットし、該データに応じた処理を前記送信先に実行させるための通知オブジェクトを生成し、前記送信先に返信する返信部と、前記送信条件を満たしたときに、前記アクセスチケットのプログラムを実行してデータを取得し、取得した前記データを前記送信先に送信する送信部と、を備えている。
【発明の効果】
【0011】
データが送信条件を満たした適切なタイミングで、ユーザが他者からの利用に同意しているデータを外部装置に送信することができる。
【図面の簡単な説明】
【0012】
【図1】一実施形態に係るデータアクセス制御システムの構成を概略的に示す図である。
【図3】ユーザ端末のハードウェア構成を示す図である。
【図4】レンタカー会社サーバの機能ブロック図である。
【図5】店舗サーバの機能ブロック図である。
【図7】チケットブローカーサーバの機能ブロック図である。
【図10】レンタカー利用手続きの一連の画面遷移例を示す図である。
【図11】リコメンド情報用チケット発行画面の具体例を示す図である。
【図13】データ取得用プログラムの例を示す図である。
【図14】レンタカー会社サーバによるチケット生成・返信処理を示すフローチャートである。
【図15】チケット登録画面の具体例を示す図である。
【図16】チケットブローカーサーバによるチケット登録処理を示すフローチャートである。
【図17】店舗サーバがチケットを取得する際のチケットブローカーサーバの処理を示すフローチャートである。
【図18】チケットブローカーサーバが有する店舗情報ＤＢの一例を示す図である。
【図19】店舗サーバがチケットを返信する処理を示すフローチャートである。
【図20】割引情報を送信するコールバック関数の例を示す図である。
【図21】チケット処理要求の例を示す図である。
【図22】チケット処理要求を受信したレンタカー会社サーバの処理を示すフローチャートである。
【図23】レンタカー会社サーバが有するチケットＤＢの一例を示す図である。
【図24】レンタカー会社サーバが有する通知オブジェクトＤＢの一例を示す図である。
【図25】チケット処理応答の例を示す図である。
【図26】レンタカー会社サーバによる運転情報監視処理を示すフローチャートである。
【図27】コールバックＵＲＩでデータを受信した店舗サーバの処理を示すフローチャートである。
【図28】ナビ表示チケットの例を示す図である。
【図29】ナビゲーション画面の一例を示す図である。
【発明を実施するための形態】
【0013】
【0014】
図１のデータアクセス制御システム１００は、レンタカーサービスを利用するユーザが、自身が運転するレンタカーの運転情報を運転ルート上の店舗にチケット形式で提供し、店舗から有用なサービスを受けることを可能にするシステムである。
【0015】
データアクセス制御システム１００は、図１に示すように、情報処理装置としてのレンタカー会社サーバ１０と、外部装置としての店舗サーバ２０と、ユーザが利用する装置としての車載装置３０と、ユーザ端末４０と、仲介装置としてのチケットブローカーサーバ５０と、を備える。データアクセス制御システム１００に含まれる各装置は、インターネットなどのネットワーク８０に接続されている。
【0016】
レンタカー会社サーバ１０は、レンタカーから運転情報（データ）を収集したり、収集したデータに基づく情報をレンタカー内の車載装置３０に提供する。また、レンタカー会社サーバ１０は、店舗サーバ２０からレンタカーへの情報送信をＷｅｂサービス形式で提供している。
【0017】
店舗サーバ２０は、チケットブローカーサーバ５０を通じてユーザから入手したチケットをレンタカー会社サーバ１０に送信する。また、店舗サーバ２０は、レンタカー会社サーバ１０から受信した情報に基づいて、ユーザが運転するレンタカーの車載装置３０に自身の店舗情報を送信するよう、レンタカー会社サーバ１０に依頼する。
【0018】
車載装置３０は、レンタカーに搭載されたナビゲーションシステムと、レンタカーに関する各種情報を検出するセンサ類と、を有している。
【0019】
ユーザ端末４０は、スマートフォンやタブレットなどのユーザが利用可能な端末である。本実施形態では、ユーザ端末４０は、レンタカーの利用手続きなどに用いられる。
【0020】
チケットブローカーサーバ５０は、ユーザ端末４０がレンタカー会社サーバ１０から取得したチケットを収集し、ユーザからチケットを入手したい店舗へのチケットの配布を仲介するサーバである。なお、本実施形態では、ユーザはチケットブローカーサーバ５０経由で店舗サーバ２０にチケットを配布することとしているが、ユーザ自身がユーザ端末４０から店舗サーバ２０に対して直接チケットを送付することとしてもよい。
【0021】
（レンタカー会社サーバ１０について）
図２（ａ）には、レンタカー会社サーバ１０のハードウェア構成が示されている。図２（ａ）に示すように、レンタカー会社サーバ１０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。これらレンタカー会社サーバ１０の構成各部は、バス９８に接続されている。レンタカー会社サーバ１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（データアクセス制御プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（データアクセス制御プログラムを含む）をＣＰＵ９０が実行することにより、図４に示す各部の機能が実現される。なお、図４には、ＨＤＤ９６等に格納されている各種ＤＢ（database）も図示されている。各種ＤＢの具体的なデータ構造等については後述する。なお、図４の各部の機能は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。なお、図４の各部の詳細については後述する。
図２（ａ）には、レンタカー会社サーバ１０のハードウェア構成が示されている。図２（ａ）に示すように、レンタカー会社サーバ１０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。これらレンタカー会社サーバ１０の構成各部は、バス９８に接続されている。レンタカー会社サーバ１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（データアクセス制御プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（データアクセス制御プログラムを含む）をＣＰＵ９０が実行することにより、図４に示す各部の機能が実現される。なお、図４には、ＨＤＤ９６等に格納されている各種ＤＢ（database）も図示されている。各種ＤＢの具体的なデータ構造等については後述する。なお、図４の各部の機能は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。なお、図４の各部の詳細については後述する。
【0022】
図４には、レンタカー会社サーバ１０の機能ブロック図が示されている。図４に示すように、レンタカー会社サーバ１０では、ＣＰＵ９０がプログラムを実行することにより、受信部としての通信処理部１０２、要求解析部１０４、チケット生成部１０６、チケット処理部１０８、チケット管理部１１０、イベント監視部１１４、提供部としてのメッセージ処理部１１６、運転情報管理部１１８、情報管理部１２０、鍵管理部１２２、送信データ生成部１２４、送信先管理部１２６、として機能する。
【0023】
通信処理部１０２は、ネットワークインタフェース９７を用い、ネットワーク８０経由で、車載装置３０、ユーザ端末４０、店舗サーバ２０及びチケットブローカーサーバ５０との間でデータの送受信を行う。
【0024】
要求解析部１０４は、通信処理部１０２が受信したデータを解析し、データの内容（要求内容）に応じてチケット生成部１０６、チケット処理部１０８、メッセージ処理部１１６にデータを送信する。
【0025】
チケット生成部１０６は、ユーザ端末４０からのチケット発行要求に応じたチケットをチケット管理部１１０を介して生成し、生成したチケットを送信データ生成部１２４に送信する。
【0026】
チケット処理部１０８は、店舗サーバ２０から受信したチケットの内容を解析し、返信するデータ型が通常データの場合は運転情報管理部１１８に対してチケットに記録されたプログラムを実行するよう依頼し、その結果を送信データ生成部１２４に送信する。一方、返信するデータ型がプロミス型の場合は、イベント監視部１１４に通知条件を渡して通知オブジェクトの生成を依頼し、その結果として生成された通知オブジェクトを送信データ生成部１２４に送信する。さらに、返信するデータ型がチケット型の場合はチケット生成部１０６に新たなチケット生成を依頼し、その結果として生成されたチケットを送信データ生成部１２４に送信する。
【0027】
チケット管理部１１０は、要求に応じてチケットの生成、保存、検索、削除の処理を実行する。チケット管理部１１０は、チケットＤＢ１５２（図２３参照）において、チケットの情報を管理している。なお、チケットＤＢ１５２の詳細については後述する。
【0028】
イベント監視部１１４は、チケット処理部１０８から受け取った通知条件を通知条件ＤＢ１５４に保存する。そして、イベント監視部１１４は、運転情報管理部１１８が運転情報ＤＢ１５６において管理する運転情報の更新データを常に監視して、通知条件にマッチした場合、マッチしたデータと送信先情報を送信データ生成部１２４に送る。ここで、通知条件ＤＢ１５４は、チケットの識別情報（後述するticketid）に対応付けて通知条件文字列を格納するデータベースである。また、運転情報ＤＢ１５６は、車載装置３０のセンサ類から得られた運転情報を車載装置３０の識別情報と対応付けて格納するデータベースである。
【0029】
メッセージ処理部１１６は、店舗サーバ２０から送信されてきたメッセージ送信要求を受信したときに、要求内容に応じたメッセージを生成し、指定された宛先のレンタカーの車載装置３０にメッセージを送信する。
【0030】
運転情報管理部１１８はレンタル中のレンタカーの車載装置３０からリアルタイムで送信されてくるデータ（運転情報）を運転情報ＤＢ１５６に保存したり、検索したりする。
【0031】
情報管理部１２０は、サービス情報ＤＢ１５８において、ユーザによって申し込まれた個々のレンタカーサービスの詳細情報を管理する。ここで、サービス情報ＤＢ１５８には、レンタカー利用手続きのトランザクションＩＤに対応付けて、レンタカーサービスの各種情報が格納されている。また、情報管理部１２０は、車情報ＤＢ１６０において、レンタカーの識別番号や後述するcartokenなどの静的な情報を管理する。また、情報管理部１２０は、ユーザ情報ＤＢ１６２において、レンタカー会社に対して登録されたユーザの情報（例えば、ユーザＩＤ、氏名、住所など）を管理する。
【0032】
鍵管理部１２２は、チケットや送信データの暗号化に必要な暗号鍵の生成・保存といった管理を行う。鍵管理部１２２では、暗号鍵ＤＢ１６４において、暗号鍵の管理を実行する。
【0033】
送信データ生成部１２４は、取得したデータに応じて、送信データを生成し、通信処理部１０２を介して指定された送信先に対して送信データを送信する。
【0034】
送信先管理部１２６は、通知オブジェクトの発行をするとともに、通知オブジェクトＤＢ１６６において通知オブジェクトの保存、削除といった管理を行う。なお、通知オブジェクトＤＢ１６６は、図２４に示すようなデータベースであるが、その詳細については後述する。また、送信先管理部１２６は、送信データの送信先に対応した暗号鍵を鍵管理部１２２から取得し、送信データ生成部１２４に送信する。
【0035】
（店舗サーバ２０について）
店舗サーバ２０は、レンタカー会社サーバ１０と同様、図２（ａ）に示すようなハードウェア構成を有する。店舗サーバ２０においては、ＣＰＵ９０がプログラムを実行することにより、図５に示す各部の機能が実現されている。
店舗サーバ２０は、レンタカー会社サーバ１０と同様、図２（ａ）に示すようなハードウェア構成を有する。店舗サーバ２０においては、ＣＰＵ９０がプログラムを実行することにより、図５に示す各部の機能が実現されている。
【0036】
図５に示すように、店舗サーバ２０は、通信処理部２０２、要求解析部２０４、チケット処理部２０６、通知データ処理部２０８、通知オブジェクト管理部２１０、要求生成部２１２、通知条件管理部２１４、チケット管理部２１６、鍵管理部２１８、コールバック管理部２２０の機能を有する。
【0037】
通信処理部２０２は、ネットワークインタフェース９７を用い、ネットワーク８０経由でレンタカー会社サーバ１０やチケットブローカーサーバ５０との間でデータ送受信を行う。
【0038】
要求解析部２０４は、通信処理部２０２が受信したデータを解析し、受信したデータがチケットの場合は、チケット処理部２０６に処理を渡す。一方、受信したデータがコールバック（callback）ＵＲＩ（Uniform Resource Identifier）経由のデータの場合は、要求解析部２０４は、通知データ処理部２０８に処理を渡す。
【0039】
チケット処理部２０６は、受信したチケットに含まれるコンテンツを取得し、そのコンテンツが通常のデータの場合はデータに応じたサービス処理を行う。一方、チケットに含まれるコンテンツが通知オブジェクトの場合は通知オブジェクト管理部２１０に通知オブジェクトを渡し、コールバックの監視を有効化する。また、チケットに含まれるコンテンツが新たなチケットの場合は、要求生成部２１２にそのチケットを渡して、レンタカー会社サーバ１０に送信する。
【0040】
通知データ処理部２０８は、コールバックＵＲＩに対応した通知オブジェクトからデータを取得し、データに応じたサービス処理を行う。
【0041】
通知オブジェクト管理部２１０は、チケットに含まれる通知オブジェクトをコールバックＵＲＩと関連付けて通知オブジェクトＤＢ２５２に格納する。なお、通知オブジェクトＤＢ２５２は、通知オブジェクトＤＢ１６６と同様のデータベースである。
【0042】
要求生成部２１２は、チケットブローカーサーバ５０へのチケット取得要求を生成したり、取得したチケットに通知条件管理部２１４で生成した通知条件を付加してレンタカー会社サーバ１０へのチケット送信要求を生成する。
【0043】
通知条件管理部２１４は、レンタカー会社サーバ１０へ送信するチケットの通知条件を生成し、通知条件ＤＢ２５４において管理する。なお、通知条件ＤＢ２５４は、チケットＩＤに対応付けて通知条件文字列を格納するデータベースである。また、通知条件管理部２１４は、コールバック管理部２２０に対して、運転情報が通知条件と合致した場合にメッセージを送信するコールバック関数の生成を依頼する。
【0044】
チケット管理部２１６は、チケットブローカーサーバ５０又はユーザ端末４０から取得したチケットをチケットＤＢ２５６に保存し、管理する。なお、チケットＤＢ２５６は、チケットＤＢ１５２（図２３）と同様である。
【0045】
鍵管理部２１８は、レンタカー会社サーバ１０からコールバックＵＲＩへのデータ送信を行う通信路の暗号鍵を生成し、暗号鍵ＤＢ２５８に保存して、管理する。
【0046】
コールバック管理部２２０は、通知条件管理部２１４からの依頼に応じてコールバック関数を生成し、コールバック関数ＤＢ２６０に保存し、管理する。なお、コールバック関数ＤＢ２６０は、コールバックＵＲＩに対応付けてコールバック関数を管理するデータベースである。
【0047】
（車載装置３０について）
図２（ｂ）には、車載装置３０のハードウェア構成が示されている。図２（ｂ）に示すように、車載装置３０は、ＣＰＵ１９０、ＲＯＭ１９２、ＲＡＭ１９４、記憶部（ＨＤＤ）１９６、ネットワークインタフェース１９７、可搬型記憶媒体用ドライブ１９９、表示部１９３、入力部１９５、位置センサ１８８ａ、速度センサ１８８ｂ、アクセル操作量センサ１８８ｃ、ブレーキ操作量センサ１８８ｄ等を備えている。これら車載装置３０の構成各部は、バス１９８に接続されている。車載装置３０では、ＲＯＭ１９２あるいはＨＤＤ１９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ１９９が可搬型記憶媒体１９１から読み取ったプログラムをＣＰＵ１９０が実行することにより、図６（ａ）に示す各部の機能が実現される。
図２（ｂ）には、車載装置３０のハードウェア構成が示されている。図２（ｂ）に示すように、車載装置３０は、ＣＰＵ１９０、ＲＯＭ１９２、ＲＡＭ１９４、記憶部（ＨＤＤ）１９６、ネットワークインタフェース１９７、可搬型記憶媒体用ドライブ１９９、表示部１９３、入力部１９５、位置センサ１８８ａ、速度センサ１８８ｂ、アクセル操作量センサ１８８ｃ、ブレーキ操作量センサ１８８ｄ等を備えている。これら車載装置３０の構成各部は、バス１９８に接続されている。車載装置３０では、ＲＯＭ１９２あるいはＨＤＤ１９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ１９９が可搬型記憶媒体１９１から読み取ったプログラムをＣＰＵ１９０が実行することにより、図６（ａ）に示す各部の機能が実現される。
【0048】
車載装置３０は、ＣＰＵ１９０がプログラムを実行することにより、図６（ａ）に示す、通信処理部３０２、データ送信部３０４、画面入力部３０６、データ処理部３０８、画面表示部３１０、センサデータ取得部３１２、として機能する。
【0049】
通信処理部３０２は、ネットワークインタフェース１９７を用い、ネットワーク８０経由でレンタカー会社サーバ１０との間でデータ送受信を行う。
【0050】
データ送信部３０４は、車載装置３０が有するセンサ１８８ａ～１８８ｄからセンサデータ取得部３１２が取得した値、または、画面入力部３０６が入力を受け付けたユーザからの要求を、通信処理部３０２を介してレンタカー会社サーバ１０に送信する。
【0051】
画面入力部３０６は、タッチパネルやキーボードのようなデータ入力手段であり、入力されたデータをデータ送信部３０４に渡す。
【0052】
データ処理部３０８は、通信処理部３０２が受信したデータを解析し、画面表示部３１０に渡す。
【0053】
画面表示部３１０は、データ処理部３０８から渡されたデータを表示部１９３上に表示可能な形式に変換してユーザが視認可能な形で表示部１９３上に表示する。
【0054】
（ユーザ端末４０について）
ユーザ端末４０は、図３に示すようなハードウェア構成を有する。すなわち、図３に示すように、ユーザ端末４０は、ＣＰＵ２９０、ＲＯＭ２９２、ＲＡＭ２９４、記憶部（ＨＤＤ）２９６、ネットワークインタフェース２９７、可搬型記憶媒体用ドライブ２９９、表示部２９３、入力部２９５等を備えている。これらユーザ端末４０の構成各部は、バス２９８に接続されている。ユーザ端末４０では、ＲＯＭ２９２あるいはＨＤＤ２９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ２９９が可搬型記憶媒体２９１から読み取ったプログラムをＣＰＵ２９０が実行することにより、図６（ｂ）に示す各部の機能が実現される。
ユーザ端末４０は、図３に示すようなハードウェア構成を有する。すなわち、図３に示すように、ユーザ端末４０は、ＣＰＵ２９０、ＲＯＭ２９２、ＲＡＭ２９４、記憶部（ＨＤＤ）２９６、ネットワークインタフェース２９７、可搬型記憶媒体用ドライブ２９９、表示部２９３、入力部２９５等を備えている。これらユーザ端末４０の構成各部は、バス２９８に接続されている。ユーザ端末４０では、ＲＯＭ２９２あるいはＨＤＤ２９６に格納されているプログラム、或いは可搬型記憶媒体用ドライブ２９９が可搬型記憶媒体２９１から読み取ったプログラムをＣＰＵ２９０が実行することにより、図６（ｂ）に示す各部の機能が実現される。
【0055】
図６（ｂ）に示すように、ユーザ端末４０は、ＣＰＵ２９０がプログラムを実行することにより、通信処理部４０２、データ送信部４０４、画面入力部４０６、データ処理部４０８、画面表示部４１０、としての機能を有する。
【0056】
なお、通信処理部４０２、データ送信部４０４、画面入力部４０６、データ処理部４０８、画面表示部４１０は、前述したユーザ端末４０の対応する各部３０２、３０４、３０６、３０８、３１０と同様の機能を有している。
【0057】
（チケットブローカーサーバ５０について）
チケットブローカーサーバ５０は、前述したレンタカー会社サーバ１０や店舗サーバ２０と同様のハードウェア構成（図２（ａ）参照）を有している。
チケットブローカーサーバ５０は、前述したレンタカー会社サーバ１０や店舗サーバ２０と同様のハードウェア構成（図２（ａ）参照）を有している。
【0058】
チケットブローカーサーバ５０では、ＣＰＵ９０がプログラムを実行することにより、図７に示す、通信処理部５０２、要求解析部５０４、チケット管理部５０６、店舗情報管理部５０８、チケット送信部５１０、として機能する。
【0059】
通信処理部５０２は、ネットワークインタフェース９７を用い、ネットワーク８０を介して、他のサーバや装置との間でデータの送受信を行う。
【0060】
要求解析部５０４は、通信処理部５０２が受信したデータを解析し、受信したデータがチケット格納要求であればチケットをチケット管理部５０６に渡す。一方、受信したデータがチケット取得要求であれば、要求解析部５０４は、要求内容に合致したチケットを検索する命令をチケット管理部５０６に送り、チケット管理部５０６は検索されたチケットをチケット送信部５１０に渡す。
【0061】
チケット管理部５０６は受信したチケットをチケットＤＢ５５２に格納して管理するとともに、店舗情報管理部５０８が店舗情報ＤＢ５５４から検索した店舗に対して送信するチケットをチケットＤＢ５５２において検索する。なお、チケットＤＢ５５２は、チケットＤＢ１５２（図２３）と同様である。
【0062】
店舗情報管理部５０８は、店舗情報ＤＢ５５４において、チケットを取得することが可能な店舗のリストおよび店舗情報を管理する。なお、店舗情報ＤＢ５５４は、図１８に示すようなデータベースであるが、その詳細については後述する。
【0063】
チケット送信部５１０は、チケット配布条件にマッチした店舗サーバ２０に対して、通信処理部５０２を介してチケットを送信する。
【0064】
（データアクセス制御システム１００において実行される処理の概要）
図８（ａ）～図９（ｂ）には、本実施形態における処理の概要が示されている。以下、図８（ａ）～図９（ｂ）に沿って処理の概要について説明する。
図８（ａ）～図９（ｂ）には、本実施形態における処理の概要が示されている。以下、図８（ａ）～図９（ｂ）に沿って処理の概要について説明する。
【0065】
【0066】
ユーザがユーザ端末４０にレンタカー利用手続き画面を表示し、入力を行う。これにより、図８（ａ）のように、（１）ユーザ端末４０は、レンタカー会社サーバ１０に対してレンタカー利用手続き画面に入力された情報を送信することで、レンタカー利用手続きを行う。また、ユーザがユーザ端末４０にチケット発行画面を表示し、入力を行うと、（２）ユーザ端末４０は、レンタカー会社サーバ１０に対してチケット発行要求を行う。
【0067】
これに対し、（３）レンタカー会社サーバ１０は、チケット発行要求に応じてチケットを生成し、（４）生成したチケットをユーザ端末４０に対して返信する。
【0068】
【0069】
図８（ｂ）のやり取りにおいては、（１）ユーザ端末４０が、受信したチケットの登録要求をチケットブローカーサーバ５０に対して送信する。これに対し、（２）チケットブローカーサーバ５０は、チケット登録を行う。そして、（３）チケットブローカーサーバ５０は、ユーザ端末４０に対してチケット登録完了を通知する。
【0070】
【0071】
図９（ａ）の処理においては、ユーザが車載装置３０のナビを用いてルート検索を行い、ルートが確定すると、（１）車載装置３０は、レンタカー会社サーバ１０に対してルート情報を送信する。次いで、（２）レンタカー会社サーバ１０は、チケットブローカーサーバ５０に対して、ルート情報とチケット配布要求を送信する。次いで、（３）チケットブローカーサーバ５０は、ルート上（ルート近傍）の店舗を検索する。次いで、（４）チケットブローカーサーバ５０は、検索された店舗の店舗サーバ２０に対して、受信したルートを走行する予定のユーザのチケットを送信する。
【0072】
【0073】
図９（ｂ）の処理においては、店舗サーバ２０がチケットを受信すると、（１）店舗サーバ２０は、チケットに通知条件を付加する。また、（２）店舗サーバ２０は、通知条件が付加されたチケットの処理要求をレンタカー会社サーバ１０に送信する。（３）レンタカー会社サーバ１０は、チケットの処理要求を受信すると、通知条件を登録したり、オブジェクトＩＤを生成し、保存したりする。そして、（４）レンタカー会社サーバ１０は、生成したオブジェクトＩＤを含む返信データを店舗サーバ２０に送信する。（５）返信データを受信した店舗サーバ２０は、オブジェクトＩＤを保存して、以降、コールバック呼び出し待ち状態となる。
【0074】
その後、（６）レンタカー会社サーバ１０は、受信した通知条件を満たすまで待機し、通知条件を満たすと、店舗サーバ２０に対して通知を行う。
【0075】
（７）通知を受けた店舗サーバ２０は、通知を受信すると、レンタカー会社サーバ１０に対してメッセージ（例えば店舗の割引情報など）の転送要求を行う。これに対し、（８）レンタカー会社サーバ１０は、転送要求を受け付けたメッセージを表示するように、車載装置３０に対して表示要求を出力する。そして、（９）車載装置３０は、表示要求に応じて、ナビ画面上にメッセージを表示する。
【0076】
以上の処理により、レンタカーを借りたユーザは、自己の運転情報をレンタカー会社に提供することで、車載装置３０（ナビ画面）に、適切なタイミングで有用なメッセージ（割引情報など）を表示することができる。
【0077】
【0078】
なお、処理の前提として、各サーバは下記のＷｅｂサービス・インターフェースを有するものとする。
【0079】
＜レンタカー会社サーバ１０＞
（ａ）レンタカー利用手続き画面：http://rentacar.example.com/rentacar
（ｂ）チケット発行受付：http://rentacar.example.com/createTicket
（ｃ）チケット処理受付：http://rentacar.example.com/processTicket
（ｄ）メッセージ転送受付：http://rentacar.example.com/transferMessage
（ｅ）運転データ受信受付：http://rentacar.example.com/uploadDriveData
（ａ）レンタカー利用手続き画面：http://rentacar.example.com/rentacar
（ｂ）チケット発行受付：http://rentacar.example.com/createTicket
（ｃ）チケット処理受付：http://rentacar.example.com/processTicket
（ｄ）メッセージ転送受付：http://rentacar.example.com/transferMessage
（ｅ）運転データ受信受付：http://rentacar.example.com/uploadDriveData
【0080】
＜店舗サーバ２０＞
（ａ）チケット取得受付：http://shop1.example.com/getTicket
（ｂ）データ受信用コールバック：
http://shop1.example.com/callback550e8400d42397e88a76b32c
(なお、「callback」以降の文字列はチケットごとに異なる値とする)
（ａ）チケット取得受付：http://shop1.example.com/getTicket
（ｂ）データ受信用コールバック：
http://shop1.example.com/callback550e8400d42397e88a76b32c
(なお、「callback」以降の文字列はチケットごとに異なる値とする)
【0081】
＜車載装置３０＞
（ａ）メッセージ表示受付：http://car0001.example.com/displayMessage
（ａ）メッセージ表示受付：http://car0001.example.com/displayMessage
【0082】
＜チケットブローカーサーバ５０＞
（ａ）チケット登録受付：http://ticketbroker.example.com/registerTicket
（ｂ）チケット配布受付：http://ticketbroker.example.com/deliverTicket
（ａ）チケット登録受付：http://ticketbroker.example.com/registerTicket
（ｂ）チケット配布受付：http://ticketbroker.example.com/deliverTicket
【0083】
（チケットの生成処理（図８（ａ）の処理））
レンタカーの利用者は自身が利用するユーザ端末４０のＷｅｂブラウザでレンタカー利用手続き画面(http://rentacar.example.com/rentacar)にアクセスし、レンタカーの利用手続きを行う。
レンタカーの利用者は自身が利用するユーザ端末４０のＷｅｂブラウザでレンタカー利用手続き画面(http://rentacar.example.com/rentacar)にアクセスし、レンタカーの利用手続きを行う。
【0084】
図１０には、レンタカー利用手続きの一連の画面遷移例が示されている。ユーザは、自身のユーザＩＤを用いてレンタカー会社サーバ１０にログインし、レンタカー利用手続き画面（Ｇ１）に必要な情報を入力してレンタカー利用手続きを行う。そして、レンタカー利用手続きが完了すると、レンタカー会社サーバ１０は、ユーザ端末４０に対して、リコメンド情報を受信するためのチケットを発行するかを確認する画面（図１０のリコメンド情報用チケット発行画面（Ｇ２））を表示する。なお、本実施形態においては、ナビ画面においてルート設定を行ったユーザが、ルート上（近傍）の店舗に運転情報を提供することを許可する（チケットを発行する）ことで、店舗からリコメンド情報（割引サービス等の情報）を得ることができるようになっている。
【0085】
図１１には、リコメンド情報用チケット発行画面Ｇ２の具体例が示されている。図１１の画面においては、どのような状況になった場合にリコメンド情報を通知してもらうか（通知条件）を選択することができるようになっている。ユーザは、画面上で通知条件を選択した後に「チケット発行する」ボタンを押すか、通知条件を選択せずに「チケット発行しない」ボタンを押す。
【0086】
ユーザが「チケット発行する」ボタンを押すと、ユーザ端末４０からレンタカー会社サーバ１０のチケット発行受付ＡＰＩ（http://rentacar.example.com/createTicket）にチケット発行要求が送信される。図１２（ａ）はチケット発行要求の例である。
【0087】
図１２（ａ）の例では、チケット発行要求のデータはＪＳＯＮ（JavaScript（登録商標） Object Notation）形式で記述されている。このうち、“userid”は、レンタカー利用手続きにログインしているユーザＩＤであり、“credential”は、レンタカー利用手続きを行ったトランザクションＩＤをユーザの秘密鍵で署名したデータである。また、“type”は、チケットが返すコンテンツのデータ型を表し、通常のデータの場合は“plain”、通知型のデータの場合は“promise”、チケット型のデータの場合は“ticket”となる。“data”はこのチケットで取得したいデータの名前、“duration”、“condition”は、通知型データの場合に必要なプロパティである。“duration”はデータの取得期間を表し、図１２（ａ）の場合、通知時から５分前までのデータを送信することが記述されている。“condition”には指定可能な通知条件が記述でき、図１２（ａ）の場合、目的地までの距離（to_destination）と加減速量（acceleration_level）が記述されている。
【0088】
このチケット発行要求に対して、レンタカー会社サーバ１０のチケット生成部１０６は、チケット管理部１１０に指示を出して、図１２（ｂ）に示すようなアクセスチケットを生成し、送信データ生成部１２４と通信処理部１０２を介してユーザ端末４０に返信する。なお、チケット管理部１１０は、生成したアクセスチケットをチケットＤＢ１５２に保存する。
【0089】
図１２（ｂ）のアクセスチケットにおいて、“header”には、“url”、“ticketid”、“start”、“end”、“metadata”、“description”が記述される。このうち、“url”には、発行されたチケットを利用する際の送付先として、チケット処理受付ＡＰＩのＵＲＬ(http://rentacar.example.com/processTicket)が記述される。“ticketid”は、チケットを示す一意な識別子を意味する。“start”と“end”は、チケットの有効期間を意味し、“start”の時刻から“end”の時刻までがチケットの有効期間となる。“metadata”は、データ取得間隔を意味し、図１２（ｂ）の例では、５分間隔でデータをチェックすることが記述されている。 “description”は、取得対象のデータ名が記述される。
【0090】
また、図１２（ｂ）のアクセスチケットにおいて、“payload”には、暗号化されたデータ取得用プログラムが記述される。また、“condition”には、指定可能な通知条件が記述される。図１２（ｂ）の例では、“condition”には、目的地までの距離(to_destination)と加減速量(acceleration_level)が記述されている。“signature”は、チケットデータのハッシュ値に発行者（レンタカーサービス）が署名したデータであり、チケットデータの改ざん検出に使用する。
【0091】
【0092】
図１３は、データ取得先のデータベースがＭｙＳＱＬで構成されており、ＳＱＬ文でデータ検索が可能な場合の例を示している。図１３の例では車ＩＤが“car0001”であるレンタカーの運転情報データ(drivedata)を５分間分取得するというプログラムが記述されている。なお、データベースや検索プログラム言語はＭｙＳＱＬやＳＱＬ文に限定されない。
【0093】
ここで、ユーザ端末４０からのチケット発行要求を受信したレンタカー会社サーバ１０がチケットを生成して返信するまでの具体的な処理について図１４のフローチャートに沿って、詳細に説明する。
【0094】
レンタカー会社サーバ１０の通信処理部１０２でチケット発行要求を受信すると（Ｓ１０：肯定）、受信した通信内容を要求解析部１０４で解析する（Ｓ１２）。要求解析部１０４は、チケット発行要求であることを認識すると、チケット生成部１０６に処理を渡す。
【0095】
チケット生成部１０６は、情報管理部１２０にチケット発行要求に含まれる“userid”と“credential”の値を渡し、正当なユーザからの要求かどうかの確認依頼を行う。情報管理部１２０は、ユーザの公開鍵で“credential”の内容を復号し、そこから得られるトランザクションＩＤがサービス情報ＤＢ１５８に保存されている内容と一致するか検証する（Ｓ１４）。この検証の結果、トランザクションＩＤがサービス情報ＤＢ１５８に保存されている内容と一致すれば正当なユーザからの要求であるとみなして、確認ＯＫをチケット生成部１０６に返す。
【0096】
次いで、チケット生成部１０６は、チケット発行要求に含まれる“type”、“data”、“duration”、“conditionの値をチケット管理部１１０に渡してチケットの発行を依頼する。チケット管理部１１０は渡された値に従ってデータ取得用プログラム、暗号鍵、チケットＩＤを生成し、暗号鍵で暗号化したプログラムを含むチケットを生成してチケット生成部１０６に返す（Ｓ１６）。チケット生成部１０６は生成されたチケットを送信データ生成部１２４に渡し、送信データ生成部１２４は、チケットを含む返信データを作成して通信処理部１０２経由でユーザ端末４０に返信する（Ｓ１８）。
【0097】
（チケットブローカーサーバ５０へのチケット登録（図８（ｂ）の処理））
次に、チケットブローカーサーバ５０へのチケット登録処理について説明する。
次に、チケットブローカーサーバ５０へのチケット登録処理について説明する。
【0098】
図１１のチケット発行画面への入力に応じて、レンタカー会社サーバ１０において発行されたチケットをユーザ端末４０のブラウザが受信すると、ユーザ端末４０は、ストレージ（ＨＤＤ２９６等）にチケットを保存する。そして、チケット発行画面は、図１５に示すようなチケット登録画面（図１０の画面Ｇ３）に遷移する。図１５のチケット登録画面には、受信したチケットに記述されていた内容（どのような運転情報が店舗に提供されるか）が表示されるため、ユーザは、提供する情報に同意した場合に、「チケットを登録する」ボタンを押す。ユーザが「チケットを登録する」ボタンを押すと、ユーザ端末４０は、チケットブローカーサーバ５０のチケット登録受付ＡＰＩ（http://ticketbroker.example.com/registerTicket）にチケットを含むチケット登録要求を送信する。
【0099】
チケットブローカーサーバ５０においては、図１６のフローチャートに沿った処理が実行される。すなわち、通信処理部５０２がチケット登録要求を受信すると（Ｓ２０：肯定）、要求解析部５０４が、登録要求に含まれるチケット情報を抽出してチケット管理部５０６を介してチケットをチケットＤＢ５５２に保存する（Ｓ２２）。チケットＤＢ５５２に対するチケットの保存に成功すると、チケット管理部５０６は、チケット登録完了の返信データを作成し（Ｓ２４）、通信処理部５０２を介してユーザ端末４０に返信する（Ｓ２６）。
【0100】
【0101】
（チケットの取得（図９（ａ）の処理））
次に、店舗サーバ２０がユーザ端末４０に対して発行されたチケットを取得する処理について説明する。
次に、店舗サーバ２０がユーザ端末４０に対して発行されたチケットを取得する処理について説明する。
【0102】
ユーザがレンタカーを借り、レンタカー内の車載装置３０（ナビ画面）上で目的地までのルート設定を行うと、車載装置３０からレンタカー会社サーバ１０に対してルート情報が送信される。
【0103】
一方、ルート情報を受信したレンタカー会社サーバ１０は、チケットブローカーサーバ５０のチケット配布受付ＡＰＩ（http://ticketbroker.example.com/deliverTicket）にルート情報を含むチケット配布要求を送信する。
【0104】
図１７には、このときのチケットブローカーサーバ５０の処理がフローチャートにて示されている。チケットブローカーサーバ５０では、通信処理部５０２がチケット配布要求を受信すると（Ｓ３０：肯定）、要求解析部５０４において要求データからルート情報を抽出する（Ｓ３２）。そして、要求解析部５０４は、店舗情報管理部５０８に対して抽出したルート上から一定の範囲内にある店舗のアクセス先（チケット受付ＵＲＬ）の一覧取得を要求する。
【0105】
店舗情報管理部５０８は、店舗情報ＤＢ５５４から該当する店舗を検索して、検索された店舗のチケット受付ＵＲＬの一覧を作成し、チケット管理部５０６に送る（Ｓ３４）。その後、チケット管理部５０６は、取得した一覧に記載されている全てのチケット受付ＵＲＬに対して、ルート設定を行ったユーザのチケットを送信する（Ｓ３６）。
【0106】
ここで、店舗情報ＤＢ５５４には、チケットの配布先候補となる店舗の情報があらかじめ保存されており、店舗情報管理部５０８を介して店舗情報が検索できる状態になっている。図１８には、店舗情報ＤＢ５５４の一例が示されている。この店舗情報ＤＢ５５４には、「店舗ＩＤ」に対応付けて、「店舗名」、「位置情報」、「チケット受付ＵＲＬ」、「店舗種別」の情報が格納されている。「店舗名」は、店舗の名称であり、「位置情報」は店舗の所在地のＧＰＳ情報（緯度、経度）である。「チケット受付ＵＲＬ」は、店舗サーバ２０がチケットを受け付ける際のＵＲＬであり、発行されたチケットの送信先として利用される。また、「店舗種別」は、店舗の種類を示す情報である。
【0107】
一方、店舗サーバ２０では、通信処理部２０２においてチケットを受信すると、要求解析部２０４において受信したチケットを抽出し、チケット管理部２１６に送る。チケット管理部２１６では、チケットＤＢ２５６にチケットを保存して、管理する。
【0108】
なお、上記においては、チケットブローカーサーバ５０は提供するデータに依存しないようレンタカー会社サーバ１０と別のサーバとして説明しているが、レンタカー会社サーバ１０がチケットブローカーサーバ５０と一体化していてもよい。すなわち、チケットブローカーサーバ５０を省略して、レンタカー会社サーバ１０にチケットブローカーサーバ５０の機能を持たせることとしてもよい。このようにすることで、チケットの利用範囲がレンタカー会社サーバ１０に限定されるため、よりプライバシーに配慮したサービスを提供することができる。
【0109】
【0110】
チケットブローカーサーバ５０からチケットを受信した店舗サーバ２０においては、要求解析部２０４がレンタカー会社サーバ１０へのチケット送信準備を開始する（Ｓ４０）。
【0111】
なお、チケット送信準備は、オペレータが管理画面上で所定の入力をした段階で開始することとしてもよいし、チケット受信後にあらかじめ設定された条件を満たした場合（例えば所定時間経過した場合）に自動的に開始してもよい。チケット送信準備を開始すると、要求生成部２１２は、通知条件管理部２１４に条件追加処理を依頼する。
【0112】
ここで、オペレータが管理画面上で入力をした段階でチケット送信準備を開始する場合、通知条件管理部２１４はチケットに付加する条件入力画面を管理画面上に表示する。そして、通知条件管理部２１４は、オペレータが入力した条件の値をもとに通知条件文字列を生成して、通知条件ＤＢ２５４に登録する。一方、自動的にチケット送信準備を開始する場合、オペレータが設定画面あらかじめ設定した条件の値を通知条件ＤＢ２５４から検索し、その値を元に通知条件文字列を生成する。
【0113】
例えば、図１２（ｂ）のアクセスチケットに対して設定可能な条件は目的地までの距離(to_destination)と加減速量(acceleration_level)なので、５ｋｍ手前に近づく、または、加減速の度合いが中程度になった場合に通知が欲しい場合であれば、{“to_destination”:{“distance”:”5km”,“from”:”35.6684415＼,139.600784”},“acceleration_level”:”3”}といった通知条件文字列を生成する。ここでfromの値は店舗自身のＧＰＳ位置データ（緯度、経度）である。
【0114】
次いで、通知条件管理部２１４が、コールバック管理部２２０に対してコールバック用ＵＲＬの生成を依頼する。依頼を受けたコールバック管理部２２０は、取得した運転情報を解析して、あらかじめ設定した条件に合えばメッセージを送信するコールバック関数と、そのコールバック関数呼び出し先ＵＲＬを生成する（Ｓ４２）。
【0115】
図２０には、割引情報のメッセージを送信するコールバック関数の例が示されている。図２０においては、２行目のパラメータにコールバック関数呼び出し先ＵＲＬが記述されている。また、図２０のコールバック関数は、２行目のＵＲＬに送信されたＪＳＯＮ形式の運転情報を解析し、通知条件にマッチすればｓｈｏｐ１から「限定ランチ１０％引き」というメッセージの送信依頼をレンタカー会社サーバ１０に送信する、というものである。なお、メッセージは、割引情報以外の情報、例えば、空席状況などを伝えるものであってもよい。
【0116】
なお、図２０の例では、送信するメッセージが予め決まっている例を示しているが、メッセージは運転情報を受信したときに動的に作成してもよい。この場合、オペレータの端末に通知画面を出して、その場でメッセージを入力させるような処理をコールバック関数に記述してもよい。
【0117】
次いで、通知条件管理部２１４は、チケット管理部２１６に対して、当該チケットでデータ返信時に利用するセッション鍵（通信暗号鍵）の生成を依頼する。依頼を受けたチケット管理部２１６は、鍵管理部２１８経由で暗号鍵を生成して通知条件管理部２１４に返す（Ｓ４４）。なお、鍵管理部２１８は、生成した暗号鍵を暗号鍵ＤＢ２５８に格納する。
【0118】
次いで、通知条件管理部２１４は、先に生成した通知条件文字列とコールバック関数呼び出し先ＵＲＬ、セッション鍵を要求生成部２１２に返す。これを受け、要求生成部２１２は、チケット処理要求を生成してレンタカー会社サーバ１０のチケット処理受付ＡＰＩ（http://rentacar.example.com/processTicket）に送信する。
【0119】
図２１には、チケット処理要求の例が示されている。図２１のチケット処理要求のうち、“ticket”にはチケットをｂａｓｅ６４エンコードした文字列が入り、“notify“、“callback”、“sessionKey”には、通知条件管理部２１４が生成した値がそれぞれ入る。
【0120】
【0121】
レンタカー会社サーバ１０では、通信処理部１０２がチケット処理要求を受信すると（Ｓ５０：肯定）、受信したチケット処理要求を要求解析部１０４に送る。要求解析部１０４は、チケット処理要求から、チケットデータ、通知条件文字列、コールバック関数呼び出し先ＵＲＬ、セッション鍵を抽出してチケット処理部１０８に渡す（Ｓ５２）。チケット処理部１０８は、デコードしたチケットデータから“ticketid”の値を取り出し、チケット管理部１１０に渡し、当該“ticketid”のチケットがチケットＤＢ１５２に登録されているかどうか確認する（Ｓ５４）。
【0122】
図２３には、チケット管理部１１０で管理しているチケットＤＢ１５２の一例が示されている。チケットＤＢ１５２の「ticketid」のフィールドには、チケットの識別情報が格納され、「発行者」のフィールドには、発行者の識別情報が格納される。また、「type」のフィールドには、チケットの種別の情報が格納され、「暗号鍵」のフィールドには暗号鍵の情報が格納され、「ハッシュ値」のフィールドには、チケットのハッシュ値の情報が格納される。また、「有効期限」のフィールドには、チケットの有効期限となる年月日時の情報が格納される。
【0123】
チケット管理部１１０は、チケットＤＢ１５２にチケット処理要求から取り出した“ticketid”が存在していれば、その“ticketid”に対応する「type」の値をチケット処理部１０８に返す。そして、チケット処理部１０８は、「type」の値に応じた処理を実行する（Ｓ５６）。
【0124】
ここで、「type」の値が“plain”の場合には、チケット処理部１０８は、チケットのペイロードをチケット管理部１１０に送る。このとき、チケット管理部１１０はチケットＤＢ１５２から取り出した暗号鍵でペイロードを復号してチケットのプログラムを実行し、実行結果をチケット処理部１０８に返す。そして、チケット処理部１０８は、受信した実行結果を送信データ生成部１２４に渡す。その後は、送信データ生成部１２４が、チケットの実行結果を含む返信データを作成して、通信処理部１０２を介して店舗サーバ２０に返信データを送信する。
【0125】
一方、「type」の値が“promise”の場合、チケット処理部１０８は、ticketidと紐づけて通知条件をイベント監視部１１４に渡し、コールバック先（コールバック関数呼び出し先ＵＲＬ）とセッション鍵を送信先管理部１２６に送る。この場合、イベント監視部１１４は、ticketidと対応付けて通知条件を通知条件ＤＢ１５４に登録する。また、送信先管理部１２６は、通知オブジェクト(オブジェクトＩＤ)を生成し、コールバック先（コールバック関数呼び出し先ＵＲＬ）とセッション鍵を紐づけて通知オブジェクトＤＢ１６６に登録した後、チケット処理部１０８にオブジェクトＩＤを返す。ここで、通知オブジェクトＤＢ１６６には、図２４に示すように、「チケットＩＤ」に対応付けて、「オブジェクトＩＤ」と「コールバックＵＲＬ」（コールバック関数呼び出し先ＵＲＬ）と、「セッション鍵」とが対応付けて格納されている。その後、チケット処理部１０８は、オブジェクトＩＤを送信データ生成部１２４に送り、送信データ生成部１２４はオブジェクトＩＤを含む返信データ（図２５参照）を作成する。そして、チケット処理部１０８は通信処理部１０２を介して店舗サーバ２０に返信データを送信する。
【0126】
次に、レンタカー会社サーバ１０からオブジェクトＩＤを含む返信データを受信した店舗サーバ２０の処理について説明する。
【0127】
店舗サーバ２０では、チケット処理要求に対する返信データ（オブジェクトＩＤを含む）を受信した通信処理部２０２が、要求解析部２０４に返信データを渡す。
【0128】
要求解析部２０４は、返信データからオブジェクトＩＤとチケットＩＤを抽出して両者を紐づけ、通知オブジェクト管理部２１０に対して、通知オブジェクトＤＢ１６６に保存するよう依頼する。通知オブジェクト管理部２１０は、これらのデータを通知オブジェクトＤＢ１６６に保存して処理を完了すると、以降、コールバック呼び出し待ち状態になる。
【0129】
（チケットコンテンツの送信（図９（ｂ）の（６）～（７）の処理））
車載装置３０は、センサ１８８ａ～１８８ｄで取得した情報をデータ送信部３０４で送信用のデータ形式に加工して定期的、またはリアルタイムにレンタカー会社サーバ１０の運転情報受信受付ＡＰＩ（http://rentacar.example.com/uploadDriveData）に送信する。なお、車載装置３０からの運転情報の送信はインターネットなどのネットワーク８０を介さず、メーカーの専用ネットワークを利用してメーカーが運営するデータベースに蓄積される場合もある。この場合には、レンタカー会社サーバ１０からメーカーのデータベースに一定の間隔でアクセスして、データを取得することとしてもよい。
車載装置３０は、センサ１８８ａ～１８８ｄで取得した情報をデータ送信部３０４で送信用のデータ形式に加工して定期的、またはリアルタイムにレンタカー会社サーバ１０の運転情報受信受付ＡＰＩ（http://rentacar.example.com/uploadDriveData）に送信する。なお、車載装置３０からの運転情報の送信はインターネットなどのネットワーク８０を介さず、メーカーの専用ネットワークを利用してメーカーが運営するデータベースに蓄積される場合もある。この場合には、レンタカー会社サーバ１０からメーカーのデータベースに一定の間隔でアクセスして、データを取得することとしてもよい。
【0130】
これに対し、レンタカー会社サーバ１０においては、通信処理部１０２が運転情報を受信すると、要求解析部１０４に運転情報を送る。そして、要求解析部１０４は、運転情報管理部１１８に対して運転情報を送信し、運転情報ＤＢ１５６に格納させる。
【0131】
図２６には、レンタカー会社サーバ１０による、運転情報を監視する処理がフローチャートにて示されている。
【0132】
図２６に示すように、イベント監視部１１４は、運転情報管理部１１８の運転情報ＤＢ１５６の更新を常に監視している（Ｓ６０）。この場合、イベント監視部１１４は、運転情報ＤＢ１５６において更新されている車のデータへのアクセスを必要とするチケットをチケット管理部１１０から取得して、チケットのプログラムを運転情報ＤＢ１５６に対して実行する。
【0133】
そして、イベント監視部１１４は、チケットのプログラムの実行により運転情報ＤＢ１５６から得られたデータに対して、当該チケットの通知条件に合致しているかどうかをチェックする（Ｓ６２）。例えば、通知条件が、図２１で示した{“to_destination”:{“distance”:”5km”,“from”:”35.6684415＼,139.600784”},“acceleration_level”:”3”}という通知条件であったとする。この場合、イベント監視部１１４は、運転情報に含まれる位置データとfromの値から距離を算出し、その結果が５ｋｍより小さい場合に通知条件に合致したと判断する。あるいは、イベント監視部１１４は、運転情報に含まれる速度、アクセル操作量、ブレーキ操作量の変動幅が一定時間で一定数値を一定回数超えた（すなわち急加減速操作が頻繁に起こるようになり疲れてきたことを意味する）場合に、通知条件に合致したと判断する。
【0134】
イベント監視部１１４は、通知条件に合致した場合（Ｓ６４：肯定）に、その運転情報とチケットＩＤを送信データ生成部１２４に送る。そして、送信データ生成部１２４は、送信先管理部１２６を介して通知オブジェクトＤＢ１６６から通知チケットＩＤに対応する通知オブジェクトデータを抽出して、運転情報を暗号鍵で暗号化した送信データを生成する。その後、送信データ生成部１２４は、生成した送信データを通信処理部１０２を介してコールバック関数呼び出し先ＵＲＬ（コールバックＵＲＩ）に送信する（Ｓ６６）。なお、ステップＳ６４の判断が否定された場合、すなわち通知条件に合致しなかった場合には、イベント監視部１１４は、ステップＳ６０に戻る。
【0135】
次に、コールバックＵＲＩでデータを受信した店舗サーバ２０の処理について、図２７のフローチャートに沿って説明する。
【0136】
店舗サーバ２０においては、通信処理部２０２がコールバックＵＲＩ宛の送信データを受信すると（Ｓ７０：肯定）、要求解析部２０４に送信データを渡す。また、要求解析部２０４は、コールバック管理部２２０が管理するコールバック関数ＤＢ２６０からコールバックＵＲＩに対応するコールバック関数を抽出して受信データとともに通知データ処理部２０８に処理を渡す。そして、通知データ処理部２０８は、通知オブジェクト管理部２１０に問い合わせて、コールバックＵＲＩに対応したオブジェクトＩＤを抽出する（Ｓ７２）。
【0137】
次いで、通知データ処理部２０８は、オブジェクトＩＤに紐づけられたチケットＩＤを鍵管理部２１８に渡して該当する暗号鍵を取得し、受信したデータを復号する。そして、復号したデータとオブジェクトＩＤをコールバック管理部２２０に渡して実行する。
【0138】
図２０のコールバック関数の場合、受信した運転データからレンタカーが店舗に近づいたことがわかるので、コールバック管理部２２０は、“限定ランチ１０％引き“というメッセージを作成する。また、コールバック管理部２２０は、要求生成部２１２及び通信処理部２０２を介して、レンタカー会社サーバ１０にメッセージ転送要求を送信する（Ｓ７４）。
【0139】
なお、上記例では、メッセージ転送要求はメッセージの文面とナビ画面に表示する画像イメージだけを送ることとしているが、これに限られるものではない。例えば、ナビ画面へのアクセス権や車の情報（例えば現在位置など）を利用したメッセージ送信を行いたい場合には、レンタカー会社サーバ１０のデータベースへアクセスするためのメッセージ転送用のチケット（ナビ表示チケット）を事前にユーザから取得しておき、当該チケットを一緒に送信してもよい。なお、メッセージ転送用のチケットは事前にユーザから取得して店舗サーバ２０で保存しておいてもよい。また、最初のデータ取得用のチケットの中にメッセージ転送用チケットを埋め込んでチケットを作成しておき、レンタカー会社サーバ１０が通知データと一緒にメッセージ転送用チケットを送信してもよい。
【0140】
（メッセージ表示（図９の（８）、（９）の処理））
以下、受信したメッセージ転送要求にナビ表示チケットが含まれる場合の、レンタカー会社サーバ１０の処理について述べる。
以下、受信したメッセージ転送要求にナビ表示チケットが含まれる場合の、レンタカー会社サーバ１０の処理について述べる。
【0141】
図２８は、ナビ表示チケットの一例を示す図である。図２７のナビ表示チケットは、レンタカーの車載装置３０（ナビ画面）に表示を出すアクセス権（cartoken）を取得するチケットであり、“payload”に当該レンタカーのcartokenデータを取得するプログラムが入っている。このチケットはレンタカーを借りたユーザがレンタカー申込をしたときに生成依頼して店舗サーバ２０に事前に渡しているものとし、メッセージ転送要求とともに店舗サーバ２０から送信される。
【0142】
レンタカー会社サーバ１０の通信処理部１０２は、メッセージ転送要求を受信すると、要求解析部１０４に渡す。そして、要求解析部１０４は、要求内容からメッセージ（postData）とチケットを抽出し、それぞれのデータをメッセージ処理部１１６とチケット処理部１０８に渡す。メッセージ処理部１１６はメッセージのデータからメッセージ文を生成して送信データ生成部１２４に送る。一方、チケット処理部１０８は上述したチケット処理と同様の手順で情報管理部１２０が管理する車情報ＤＢ１６０のデータから当該レンタカーのcartokenを取得して送信データ生成部１２４に送る。送信データ生成部１２４は渡されたデータを含むメッセージ表示要求を生成して通信処理部１０２経由で車載装置３０のメッセージ表示受付API(http://car0001.example.com/displayMessage)に送信する。
【0143】
一方、メッセージ表示要求を受信した車載装置３０の通信処理部３０２はデータ処理部３０８に要求内容を渡す。データ処理部３０８は要求内容からcartokenとメッセージ内容を抽出し、cartokenが正しいことを検証すると画面表示部３１０にメッセージ内容を表示する。図２９は、図２０の割引情報メッセージに対応したナビ画面上に表示されたメッセージの表示例である。送信されたメッセージとＱＲコード（登録商標）が地図上の店舗の位置に表示され、画面上の「店を予約する」ボタンを押すと、店の予約サイトにアクセスして予約をすることができる。
【0144】
（チケット消滅について）
ところで、レンタカー会社サーバ１０のチケット管理部１１０は定期的にチケットＤＢ１５２の内容をチェックしており、有効期限が過ぎたエントリがあれば、削除する。したがって、削除したエントリに対応するチケットを受信した場合には、チケットＤＢ１５２に該当するチケットがないため、チケット管理部１１０は、チケットの処理を行わずに、無効である旨のエラー情報を店舗サーバ２０に返信する。
ところで、レンタカー会社サーバ１０のチケット管理部１１０は定期的にチケットＤＢ１５２の内容をチェックしており、有効期限が過ぎたエントリがあれば、削除する。したがって、削除したエントリに対応するチケットを受信した場合には、チケットＤＢ１５２に該当するチケットがないため、チケット管理部１１０は、チケットの処理を行わずに、無効である旨のエラー情報を店舗サーバ２０に返信する。
【0145】
図３０（ａ）、図３０（ｂ）は、データ提供側サーバ１０００とデータ取得側サーバ２０００の処理の概要を、第１フェーズと第２フェーズの２つのフェーズに分けて模式的に示す図である。データ提供側サーバ１０００は、上述したレンタカー会社サーバ１０に相当し、データ取得側サーバ２０００１は、上述した店舗サーバ２０に相当する。
【0146】
第１フェーズでは、図３０（ａ）に示すように、データ取得側サーバ２０００が、データアクセス用のチケットとリクエストパラメータを含むチケット処理要求（データアクセス用パラメータ）をデータ提供側サーバ１０００に送信する。ここで、リクエストパラメータには、前述した通知条件と通知手段情報（コールバックＵＲＩ）が含まれる。また、データ提供側サーバ１０００は、イベントハンドラー１００２（図４のイベント監視部１１４に相当）に受信した通知条件をセットする。そして、通知オブジェクト生成部１００４（図４の送信先管理部１２６に相当）が、コールバックＵＲＩに対応したプログラムを含む通知オブジェクトを生成し、生成した通知オブジェクトを含む返信データをデータ取得側サーバ２０００に返信する。そして、データ取得側サーバ２０００では、通知受信用の通知オブジェクトをイベントリスナー２００２（図５の通知オブジェクト管理部２１０に相当）にセットする。
【0147】
一方、第２フェーズでは、図３０（ｂ）に示すように、データ提供側サーバ１０００のイベントハンドラー１００２は、通知条件に合致したことを検出すると、チケットのプログラムを実行してデータを取得する。そして、データ提供側サーバ１０００は、データ取得側サーバ２０００から提供された通知手段（コールバックＵＲＩ）へのアクセスにより、取得したデータを送信する。このとき、データ提供側サーバ１０００は、チケットに含まれていたセッション鍵とともにデータを送信する。データ取得側サーバ２０００では、セッション鍵が正しいことを検証した後、データを通知オブジェクトにセットする。そして、データ取得側サーバ２０００のイベントリスナー２００２は、通知があったことを検知すると、通知オブジェクトからデータを取得する。
【0148】
なお、第２フェーズは、予め設定された期限まで、又は終了条件が成立するまで処理を継続する。
【0149】
図３０（ａ）、図３０（ｂ）のようにすることで、通知処理をチケットの認可手順に含めているため、一度の認可処理で非同期のデータ受信が可能になる。なお、通知の安全性は、データ提供側サーバ１０００にだけコールバックＵＲＩを許可することで保証する。
【0150】
また、チケット内にパラメータ処理のプログラムを含めることで、チケットとパラメータの関連付けを改竄できないようにしている。
【0151】
これまでの説明から明らかなように、本実施形態では、送信先管理部１２６と、送信データ生成部１２４とを含んで、通知オブジェクトを含む返信データを店舗サーバ２０に返信する返信部としての機能が実現されている。また、本実施形態では、イベント監視部１１４と、送信データ生成部１２４とを含んで、通知条件を満たしたときに運転情報を店舗サーバ２０に送信する送信部としての機能が実現されている。
【0152】
以上詳細に説明したように、本実施形態によると、レンタカー会社サーバ１０の通信処理部１０２は、ユーザが他者による利用に同意したデータのアクセスチケット、通知条件、コールバックＵＲＩ、を含むチケット処理要求を店舗サーバ２０から受信する。また、送信先管理部１２６は、コールバックＵＲＩに対応する通知オブジェクトを生成し、送信データ生成部１２４は、通知オブジェクトを含む返信データを店舗サーバ２０に送信する。そして、イベント監視部１１４の監視の下、運転情報が通知条件を満たしたときに、送信データ生成部１２４は、通知条件を満たした運転情報を含む送信データを生成し、通信処理部１０２を介して店舗サーバ２０のコールバックＵＲＩに送信データを送信する。これにより、本実施形態では、店舗サーバ２０から一度チケット処理要求を受信すれば、通知条件を満たした適切なタイミングで、送信データを店舗サーバ２０に送信することができる。また、レンタカー会社サーバ１０にのみコールバックＵＲＩを通知しているので、送信データの安全性を確保することができる。
【0153】
したがって、店舗サーバ２０では、通知条件を満たしたタイミングで、ユーザが利用する車載装置３０に店舗に誘導する情報（購買意欲を増進させる情報）を送信することができる。これにより、ユーザに対し、店舗の有用な情報を適切なタイミングで提供することができる。また、店舗にユーザが来店する可能性が高まるため、店舗にとっても有益である。すなわち、ユーザの状態に合わせた適切なリコメンドが可能になり、ユーザと店舗のマッチングの精度を向上することができる。また、レンタカー会社は、運転情報を店舗に提供することで、店舗からマージン（手数料）を得ることができる。
【0154】
また、本実施形態では、チケット処理要求に暗号鍵（セッション鍵）が含まれており、送信データ生成部１２４は、暗号鍵で暗号化した運転情報を送信データに含めて店舗サーバ２０に送信する（Ｓ６６）。これにより、運転情報の秘匿化を図ることができる。
【0155】
また、イベント監視部１１４は、有効期限が終わるまで又は予め定められている終了条件を満足するまで、運転情報が通知条件を満たすか否かを監視する。これにより、予め定めた範囲で、店舗に必要な運転情報を提供することができる。
【0156】
なお、上記実施形態では、レンタカー会社と店舗とユーザの三者間でデータアクセス制御システムを利用する場合について説明したが、これに限られるものではない。情報を提供する者、情報を収集する者、収集された情報を用いて情報を提供する者に対して別の情報を提供する者、の関係にある三者であれば、職種、業種等は問わない。
【0157】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記憶媒体（ただし、搬送波は除く）に記録しておくことができる。
【0158】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記憶媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【0159】
プログラムを実行するコンピュータは、例えば、可搬型記憶媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記憶媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【0160】
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【0161】
なお、以上の実施形態の説明に関して、更に以下の付記を開示する。
（付記１） ユーザが他者による利用に同意したデータに対してアクセス可能なプログラムを内包するアクセスチケット、前記データを送信する送信条件、及び前記データの送信先の情報、を含むデータアクセス用パラメータを前記送信先の外部装置から受信する受信部と、
前記送信先の情報に対応する通知オブジェクトを生成し、前記送信先に返信する返信部と、
前記送信条件を満たしたときに、前記アクセスチケットのプログラムを実行してデータを取得し、取得した前記データを前記通知オブジェクトにセットするために、取得した前記データを前記送信先に送信する送信部と、
を備える情報処理装置。
（付記２） 前記データアクセス用パラメータは、暗号鍵を含み、
前記送信部は、取得した前記データを前記暗号鍵で暗号化して送信する、ことを特徴とする付記１に記載の情報処理装置。
（付記３） 前記送信部は、予め定められている終了条件を満たすまで、前記送信条件を満たすか否かを繰り返し判定することを特徴とする付記１又は２に記載の情報処理装置。
（付記４） 前記データを受信した前記外部装置からの要求に応じて、前記ユーザが利用する装置に対して前記外部装置に関する情報を提供する提供部、を更に備える付記１～３のいずれかに記載の情報処理装置。
（付記５） 前記データは、前記ユーザが利用する車の走行に関するデータであり、
前記外部装置は、前記車が走行する予定のルートに基づいて特定された店舗の情報処理装置であり、
前記提供部は、前記店舗における前記ユーザの購買意欲を増進させる情報を前記ユーザが利用する装置に提供する、ことを特徴とする付記４に記載の情報処理装置。
（付記６） ユーザが他者による利用に同意したデータに対してアクセス可能なプログラムを内包するアクセスチケット、前記データを送信する送信条件、及び前記データの送信先の情報、を含むデータアクセス用パラメータを前記送信先の外部装置から受信し、
前記送信先の情報に対応する通知オブジェクトを生成し、前記送信先に返信し、
前記送信条件を満たしたときに、前記アクセスチケットのプログラムを実行してデータを取得し、取得した前記データを前記通知オブジェクトにセットするために、取得した前記データを前記送信先に送信する、
処理をコンピュータに実行させるためのデータアクセス制御プログラム。
（付記７） 前記データアクセス用パラメータは、暗号鍵を含み、
前記送信する処理では、取得した前記データを前記暗号鍵で暗号化して送信する、ことを特徴とする付記６に記載のデータアクセス制御プログラム。
（付記８） 前記送信する処理では、予め定められている終了条件を満たすまで、前記送信条件を満たすか否かを繰り返し判定することを特徴とする付記６又は７に記載のデータアクセス制御プログラム。
（付記９） 前記データを受信した前記外部装置からの要求に応じて、前記ユーザが利用する装置に対して前記外部装置に関する情報を提供する、処理を前記コンピュータに更に実行させる付記６～８のいずれかに記載のデータアクセス制御プログラム。
（付記１０） 情報処理装置と外部装置とを備え、前記情報処理装置が有するユーザが他者による利用に同意したデータに対するアクセスを制御するデータアクセス制御システムであって、
前記情報処理装置は、
前記データに対してアクセス可能なプログラムを内包するアクセスチケット、前記データを送信する送信条件、及び前記データの送信先の情報、を含むデータアクセス用パラメータを前記送信先の外部装置から受信する受信部と、
前記送信先の情報に対応する通知オブジェクトを生成し、前記送信先に返信する返信部と、
前記送信条件を満たしたときに、前記アクセスチケットのプログラムを実行してデータを取得し、取得した前記データを前記通知オブジェクトにセットするために、取得した前記データを前記送信先に送信する送信部と、
を備える、データアクセス制御システム。
（付記１１） 前記情報処理装置から発行されたアクセスチケットを有するユーザ端末から前記アクセスチケットを取得し、前記外部装置に受け渡す仲介装置を更に備える付記１０に記載のデータアクセス制御システム。
（付記１） ユーザが他者による利用に同意したデータに対してアクセス可能なプログラムを内包するアクセスチケット、前記データを送信する送信条件、及び前記データの送信先の情報、を含むデータアクセス用パラメータを前記送信先の外部装置から受信する受信部と、
前記送信先の情報に対応する通知オブジェクトを生成し、前記送信先に返信する返信部と、
前記送信条件を満たしたときに、前記アクセスチケットのプログラムを実行してデータを取得し、取得した前記データを前記通知オブジェクトにセットするために、取得した前記データを前記送信先に送信する送信部と、
を備える情報処理装置。
（付記２） 前記データアクセス用パラメータは、暗号鍵を含み、
前記送信部は、取得した前記データを前記暗号鍵で暗号化して送信する、ことを特徴とする付記１に記載の情報処理装置。
（付記３） 前記送信部は、予め定められている終了条件を満たすまで、前記送信条件を満たすか否かを繰り返し判定することを特徴とする付記１又は２に記載の情報処理装置。
（付記４） 前記データを受信した前記外部装置からの要求に応じて、前記ユーザが利用する装置に対して前記外部装置に関する情報を提供する提供部、を更に備える付記１～３のいずれかに記載の情報処理装置。
（付記５） 前記データは、前記ユーザが利用する車の走行に関するデータであり、
前記外部装置は、前記車が走行する予定のルートに基づいて特定された店舗の情報処理装置であり、
前記提供部は、前記店舗における前記ユーザの購買意欲を増進させる情報を前記ユーザが利用する装置に提供する、ことを特徴とする付記４に記載の情報処理装置。
（付記６） ユーザが他者による利用に同意したデータに対してアクセス可能なプログラムを内包するアクセスチケット、前記データを送信する送信条件、及び前記データの送信先の情報、を含むデータアクセス用パラメータを前記送信先の外部装置から受信し、
前記送信先の情報に対応する通知オブジェクトを生成し、前記送信先に返信し、
前記送信条件を満たしたときに、前記アクセスチケットのプログラムを実行してデータを取得し、取得した前記データを前記通知オブジェクトにセットするために、取得した前記データを前記送信先に送信する、
処理をコンピュータに実行させるためのデータアクセス制御プログラム。
（付記７） 前記データアクセス用パラメータは、暗号鍵を含み、
前記送信する処理では、取得した前記データを前記暗号鍵で暗号化して送信する、ことを特徴とする付記６に記載のデータアクセス制御プログラム。
（付記８） 前記送信する処理では、予め定められている終了条件を満たすまで、前記送信条件を満たすか否かを繰り返し判定することを特徴とする付記６又は７に記載のデータアクセス制御プログラム。
（付記９） 前記データを受信した前記外部装置からの要求に応じて、前記ユーザが利用する装置に対して前記外部装置に関する情報を提供する、処理を前記コンピュータに更に実行させる付記６～８のいずれかに記載のデータアクセス制御プログラム。
（付記１０） 情報処理装置と外部装置とを備え、前記情報処理装置が有するユーザが他者による利用に同意したデータに対するアクセスを制御するデータアクセス制御システムであって、
前記情報処理装置は、
前記データに対してアクセス可能なプログラムを内包するアクセスチケット、前記データを送信する送信条件、及び前記データの送信先の情報、を含むデータアクセス用パラメータを前記送信先の外部装置から受信する受信部と、
前記送信先の情報に対応する通知オブジェクトを生成し、前記送信先に返信する返信部と、
前記送信条件を満たしたときに、前記アクセスチケットのプログラムを実行してデータを取得し、取得した前記データを前記通知オブジェクトにセットするために、取得した前記データを前記送信先に送信する送信部と、
を備える、データアクセス制御システム。
（付記１１） 前記情報処理装置から発行されたアクセスチケットを有するユーザ端末から前記アクセスチケットを取得し、前記外部装置に受け渡す仲介装置を更に備える付記１０に記載のデータアクセス制御システム。
【符号の説明】
【0162】
１０ レンタカー会社サーバ（情報処理装置）
２０ 店舗サーバ（外部装置）
３０ 車載装置（ユーザが利用する装置）
４０ ユーザ端末
５０ チケットブローカーサーバ（仲介装置）
１００ データアクセス制御システム
１０２ 通信処理部（受信部）
１１４ イベント監視部（送信部の一部）
１１６ メッセージ処理部（提供部）
１２４ 送信データ生成部（返信部の一部、送信部の一部）
１２６ 送信先管理部（返信部の一部）
２０ 店舗サーバ（外部装置）
３０ 車載装置（ユーザが利用する装置）
４０ ユーザ端末
５０ チケットブローカーサーバ（仲介装置）
１００ データアクセス制御システム
１０２ 通信処理部（受信部）
１１４ イベント監視部（送信部の一部）
１１６ メッセージ処理部（提供部）
１２４ 送信データ生成部（返信部の一部、送信部の一部）
１２６ 送信先管理部（返信部の一部）
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】