説明

電子媒体およびそれを含む情報端末

【課題】アプリケーションを用いたサービスをより簡易に提供する電子媒体等を提供する。
【解決手段】各端末30、40との入出力部110と、入出力部100を介して要求を受け、アクセス先を選択するアプリケーション選択部120と、アプリケーション選択部120の選択により、第1アプリケーションの処理を実行するアプリケーション管理部130と、アプリケーション選択部120の選択により、第2端末40との間で通信を行い、第2アプリケーションの処理のためのサービスデータを第2端末40に提供する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、アプリケーションプログラムを記録した電子媒体に関するものである。
【背景技術】
【0002】
近年、個人的な情報を自由に持ち運ぶことが可能なデータキャリアとして、電子媒体が用いられている。電子媒体の種類には、紙製のカードやエンボスカード、磁気ストライプカード、ICカード等、様々なものがある。特にICカードは、セキュリティに対する社会的な意識が高まる中、強固なセキュリティを備えた電子媒体として注目されており、磁気カードからICカードへの移行が急速に進められている。
そして、このようなカードの用途が多岐に及んでいる。例えば、認証カード、クレジットカード、ポイントカードなどがある。そのため、カードには、カードの所有者を認証するための鍵や個人情報、現金化、ポイント換金のためのサービスに必要なデータが蓄積され、カードユーザが、カードを加盟店に提示したり、端末に通したりすることによって、あらかじめ契約されているサービスがカードユーザに提供される。
【0003】
このようなカードは、多くの場合、カードユーザと契約を直接結んだサービス提供者が提供するサービスのために使用される。しかし、そのサービス提供者が他社とも提携している時に、カードユーザは、その提携先の会社が提供するサービスも享受することが可能な場合もある。つまり、カードに副次的な特典が付くこともある。
【0004】
この場合、副次的なサービスを提供するアプリケーションプログラム(以下アプリケーションという)をICカードに複数搭載するようにしてもよい。このようにすると、個々のアプリケーションで使用される共通のデータを共有したり、アプリケーション間で連携してデータをやり取りしたりすることによって、カードユーザは、1枚のICカードを用い、直接契約を結んでいないサービス提供者の提携先のサービスを受けることが可能となる。
また、副次的なサービスを提供するアプリケーションをICカードに搭載せずに、サービス提供者によって搭載されたアプリケーションのデータ領域に対して、サービス提携者からのアクセスを許可してもよい。
【0005】
従来、このようなICカードとして、次のようなものが知られていた。すなわち、ICカードには、種類の異なるサービス(サービス提供者、その提携者のものを含む)を提供するためのアプリケーションが記録され、個別領域と共通領域の各データ領域がある。共通領域は、さまざまな種類のサービス用端末(例えば、カード加盟店の端末)からのアクセスが許可されるように構成されている。そして、共通領域にアクセスしたサービス用端末からの要求に応じて、特定の種類のアプリケーションが起動し、データを提供する。このように構成することにより、ICカードは、種類の異なるサービス用端末に対してデータを提供し、カードユーザに対し、種類の異なるサービスを提供することが可能となっている(例えば、特許文献1参照)。
【0006】
図12はICカードの記録情報を示す図である。記録情報は、OS(Operation System)601、共通領域602、個別領域603およびカードフォーマットブロック604で構成されている。共通領域602に配置されるアプリケーションは、カード発行先のサービス提供者とその提携先との契約内容によって、その利用が制限される。個別領域603に配置されるアプリケーションは、サービス提供者のみがアクセス権限を持つ。
【0007】
さらに具体的に説明する。図13は、上記共通領域と個別領域の各々に配置されたアプリケーションへのアクセス方法を示す図である。ここでは、A社のサービスを提供するためのアプリケーションが共通領域および個別領域の各々に登録されているものとする。そして、例えば、個別領域と共通領域の双方に同じサービスを提供するためのアプリケーションが配置される場合、そのアプリケーションの実ブロックが共通領域602に配置され、個別領域603の該当ブロックには、実ブロックへのリンクが張られる。これにより、対応するアプリケーションが実行されることになる。
また、A社の端末装置は、共通領域へアクセスするための共通鍵KIFと、個別領域へアクセスするための個別鍵Aとを管理しているので、双方の領域にアクセス可能になっている。他方、A社以外の端末装置は、それぞれ、共通領域へアクセスするための共通鍵KIFのみを管理しているので、共通領域へのアクセスのみが可能になっている。
【0008】
【特許文献1】特開2001−325580号公報
【発明の開示】
【発明が解決しようとする課題】
【0009】
しかしながら、特許文献1に記載したICカードでは、例えば図13のA社が他社との間でデータのやり取りを行う場合、A社は、他社の外部端末が共通領域にアクセスするためのIF(InterFace)および鍵を設ける必要がある。そして、A社以外の外部端末は、アプリケーションとのやり取りを可能にするための通信プロトコルやアクセスするための鍵を共有する必要がある。
また、共通鍵を用いて共通領域に搭載済みのアプリケーションへのアクセスを可能にすることで(図13参照)、例えば、上記アプリケーションの共有者の一人がそのサービスを終了するたびに、そのサービス終了者からの当該アプリケーションへのアクセスができないように、共通鍵を更新しなければならない問題がある。
【0010】
さらに、サービス提携者がICカードにアプリケーションを搭載させ、そのICカードを一時的に利用する場合であっても、そのサービス提携者は、そのICカードの発行スキームに則ってアプリケーションをICカードに搭載させる必要があった。
【0011】
そこで、本発明は、このような状況下においてなされたもので、その目的は、電子媒体によるサービスをより簡易に行うことである。
【課題を解決するための手段】
【0012】
上記目的を達成するために、本発明は、外部装置との入出力部と、上記外部装置からの要求を上記入出力部を介して受け、第1アプリケーションを管理する第1管理部、または第2アプリケーションの処理のためのサービスデータを管理する第2管理部へのアクセス先を選択する選択部と、上記選択部により選択されたアクセス先が上記第1管理部の場合、上記管理した第1アプリケーションの処理を実行する上記第1管理部と、上記選択部により選択されたアクセス先が上記第2管理部の場合、上記外部端末との間で通信を行い、上記管理したサービスデータを当該外部端末に提供する上記第2管理部と、を含む。
【発明の効果】
【0013】
本発明によれば、電子媒体によるサービスをより簡易に行うことができる。
【発明を実施するための最良の形態】
【0014】
(実施の形態1)
実施の形態1は、電子媒体によるサービスを行うサービス提供者(クレジット会社など)と業務提携している提携者(ファーストフード店など)も、その電子媒体を用いて、独自のサービスを副次的に行うことが可能になる場合のものである。
図1は本発明の実施の形態1における電子媒体を含むシステム全体の構成例を示す図である。ここでは、サービス提供者(A社ともいう)が、電子媒体(例えば、セキュアストレージ等)10の発行者と契約を結んでいるので、電子媒体10のユーザが、その電子媒体10を用いて、A社の第1サービス(例えば、クレジット決済等)を受けられるものとする。また、A社が、サービス提携者(B社ともいう)と業務提携しているので、電子媒体10には、B社の第2サービス(例えば、フードの無料サービス)の特典が付けられるものとする。
しかし、B社は、電子媒体10の発行者と契約を結んでいないため、電子媒体10には、第2サービスを提供するための第2アプリケーションが記録されず、A社の第1サービスを提供するための第1アプリケーションのみが記録されるようになっているものとする。
【0015】
例えば、第1サービスがクレジット決済のサービスである場合、第2サービスとしては次のようなものがある。すなわち、クレジット決済の利用額が所定の額になったときに、特定の加盟店(例えば、ファーストフード店等)でフードの無料サービスを所定の期間内に受けられるというものである。
【0016】
図1において、電子媒体10が、発行サーバ20、第1端末(端末装置)30および第2端末(端末装置)40の各々との間でデータ通信が可能になっている。データ通信は、非接触あるいは接触のいずれの方式であってもよい。2台の端末30、40は、電子媒体10との間で非接触または接触の状態で通信を行うことが可能なものである。各端末30、40としては、例えば、パーソナルコンピュータ(電子媒体10のリーダや入力装置、記憶装置、処理装置を含む)、POS(Point Of Sales)端末等がある。
本実施の形態では、第1端末30は、第1サービスを提供する加盟店(例えば、デパート等)に設置され、第2端末40は、第2サービスを提供する加盟店(例えば、ファーストフード店等)に設置されているものとする。
そして、第1端末30は、インターネット等の通信ネットワーク82を介して、A社のコンピュータシステム60に接続されている。このコンピュータシステム60は、複数のサーバを含んで構成され、第1サービスを提供するための第1アプリケーション等を管理したり送信したりするようになっている。また、第2端末40も、インターネット等の通信ネットワーク83を介して、B社のコンピュータシステム70に接続されている。コンピュータシステム70は、複数のサーバを含んで構成され、第2サービスを提供するための第2アプリケーション等を管理するようになっている。
【0017】
なお、本実施の形態では、第1端末30とコンピュータシステム60との間は、通信ネットワーク82を通して通信可能な構成にしているが、例えば、オフラインとしてもよい。第2端末40とコンピュータシステム70との間も同様である。
発行サーバ20は、電子媒体10を発行するためのサーバであり、この発行サーバ20も、インターネット等の通信ネットワーク81を介して、コンピュータシステム50に接続されている。コンピュータシステム50は、例えば、複数のサーバを含んで構築されている。
【0018】
電子媒体10は、例えば、スマートカードモジュールを搭載したセキュアカード、セキュアストレージ、セキュアチップ等である。本実施の形態においては、電子媒体10は、例えば、クレジットカードの単体で利用できるものとして説明するが、例えば、ポイントカード、デビットカード等で利用できるようにしてもよい。なお、電子媒体10は、携帯電話等の情報端末(記憶装置、処理装置を含む)に着脱可能なようにしてもよいし、情報端末にあらかじめ装着してあってもよい。
【0019】
電子媒体10は、図1に示すように、入出力部110、アプリケーション選択部120(以下、選択部120という)、アプリケーション管理部(第1管理部)130、および共通領域管理部(第2管理部)140を有する。以下、これらの構成例を詳細に説明する。
【0020】
入出力部110は、発行サーバ20、第1端末30または第2端末40との間で、所定の情報(コマンド等)の授受を行う。
【0021】
選択部120は、第1端末30または第2端末40からの後記するコマンド(選択コマンドともいう)に応じて、アプリケーション管理部130または共通領域管理部140のいずれかをアクセス先として選択する。具体的には、選択部120は、アプリケーション検証部(第1選択部)121と共通領域検証部(第2選択部)122とを有する。アプリケーション検証部121は、第1端末30または第2端末40からのコマンドに対応するアプリケーションが、管理部130に搭載されているかどうかを検証する。
共通領域検証部122は、アプリケーション検証部121における上記検証の結果、上記コマンドに対応するアプリケーションが搭載されていなかった場合に、そのアプリケーションが共通領域管理部140内にあるかどうかを検証する。なお、本実施の形態では、アプリケーション検証部121および共通領域検証部122の各々を選択部ということもある。
【0022】
アプリケーション管理部130は、例えば、コンピュータシステム60からダウンロードされた第1アプリケーション132を管理する。第1アプリケーション132は、第1サービスを提供するためのものであり、例えば、クレジット決済等を実現するためのものが該当する。具体的には、アプリケーション管理部130は、第1アプリケーション132の処理に必要なサービスデータ(例えば、パスワード等)を格納する第1データエリア131を有する。
【0023】
共通領域管理部140は、第2データエリア141と仮想アプリ部142とを有する。仮想アプリ部142は、第2端末40との間でデータの送受を行うために、第2アプリケーションが存在するかのように処理する。つまり、本実施の形態では、共通領域管理部140において、第2アプリケーションが管理されるようになっている。これは、上記B社が電子媒体10の発行者と契約を結んでいないために、共通領域管理部140を含む電子媒体10には、第2アプリケーションが格納されないようになっているからである。この点は、本発明の特徴点であり、後記する。第2アプリケーションは、例えば、フードの無料サービスを提供するためのものであり、例えば、第2端末40上で実行されることとなる。
第2データエリア141は、第2アプリケーションを処理するためのサービスデータ(例えば、サービスチケット等)を格納する。図1では、1つの第2データエリア141が記載されているが、実際には、複数の第2データエリアが存在するものとする。
【0024】
なお、選択部120(各検証部121、122を含む)、アプリケーション管理部130(第1データエリア131を含む)および共通領域管理部140(第2データエリア141、仮想アプリ部142を含む)は、例えば、CPUやメモリ、LSIチップのROMもしくはEEPROMを含んで構成されている。そして、これらの各部120、130、140の機能は、上記CPUが、LSIチップのROMあるいはEEPROMに格納されたプログラム(ソフトモジュール)を実行することによって、実現される。
【0025】
次に、電子媒体10のユーザが、その電子媒体10を用いて、第2サービスを受ける場合の処理手順の概要について図2に基づいて説明する。ここでは、ユーザが、電子媒体10を用いて、第1サービス(クレジットサービス)による決済を行う。そして、その利用額が所定額(例えば5000円)に達するたびに、ユーザが、電子媒体10を用いて、所定の加盟店(ファーストフード店)にて第2サービスを受けることができる場合について説明する。第2サービスは、例えば、所定の期間内に利用することが可能なフード無料サービスであり、この場合、ユーザは、第2サービスを受けるためのサービスチケット(電子チケット)を取得して電子媒体10に登録しておく必要がある。以下、詳述する。
【0026】
まず、ユーザが、例えば、電子媒体10を搭載した情報端末を用いて、発行サーバ20にアクセスし、所定の処理(パスワードの入力等)を行う。すると、発行サーバ20が、電子媒体10(情報端末)に対し、第1サービスを提供するための第1アプリケーション132をダウンロードする(ステップS101)。この場合、発行サーバ20には、A社と発行者との契約により、あらかじめ第1アプリケーション132が登録されている。この第1アプリケーション132は、サービス提供者ID(提供者IDともいう)が対応づけられている。提供者IDは、サービス提供者を識別するための識別情報であり、アプリケーションの識別子として用いられる。
なお、本実施の形態では、発行サーバ20が、第1アプリケーション132をダウンロードする場合について説明したが、ダウンロード元のサーバは、これに限られない。例えば、発行者以外の者が管理するサーバ等であってもよい。
【0027】
続いて、ユーザが、例えば、クレジット決済するために、電子媒体10を第1端末30に近づけた場合、電子媒体10では、アプリケーション管理部130の第1アプリケーション132が起動し、第1アプリケーション132と第1端末30との間でデータ通信(接触あるいは非接触)を行い、電子媒体10が、所定のクレジット決済処理(第1データエリア131からパスワード等の読み出し等)を行う(ステップS102)。
【0028】
そして、上記クレジット決済処理が完了した後、電子媒体10のアプリケーション管理部130が、第1端末30から、第2サービスの提供を受けるためのサービスチケット等を取得する(ステップS103)。具体的には、まず、電子媒体10の入出力部110が、上記サービスチケットのほか、共通鍵とセッション鍵を生成するためのアルゴリズムとを入力する。共通鍵は、電子媒体10と第2端末40との間で通信が行われる際に、セキュアチャネルや認証等の場面で利用されるものである。
次に、選択部120が、上記サービスチケットと上記共通鍵と上記アルゴリズムとをアプリケーション管理部130に渡す。そして、アプリケーション管理部130が、第1アプリケーション132の処理に従い、上記サービスチケットと上記共通鍵と上記アルゴリズムとを第1データエリア131に保存する。
【0029】
ここで、上記サービスチケットの構成例を図3に示す。この例では、サービスチケットは、サービス提携者ID301、サービス提携者名302、有効期限303、サービスID304、サービスメニューID305、利用可能店舗ID306およびハッシュを含んでいる。サービス提携者ID(提携者IDともいう)301には、サービス提携者を識別するためのIDが示され、提携者名302には、そのサービス提携者名が示される。
有効期限303には、当該サービスチケットの有効期限が示される。サービスID304には、サービスの内容(例えばフード無料等)が示され、サービスメニューID305には、サービスの対象を特定するためのIDが示される。利用可能店舗ID306には、当該サービスチケットの利用が可能な店舗を識別するためのIDが示されている。なお、第1端末30や第2端末40には、店舗IDがあらかじめ割り当てられているものとする。
ハッシュ307は、当該サービスチケットが改ざんされていないことを証明するためのものであり、上記データ301〜306のメッセージダイジェストとなっている。
【0030】
なお、第1データエリア131に保存されたサービスチケットが正当なものであるかどうかの検証を行うために、次のような処理を行ってもよい。すなわち、電子媒体10が、第1アプリケーション132の処理に従い、第1端末30を通して、コンピュータシステム60に対し、サービスチケットの正当性の成否をリクエストする。これにより、例えば、コンピュータシステム60が、リクエストされたサービスチケットの発行履歴(提供者ID、発行日時等)を確認し、発行履歴の内容に応じて、そのサービスチケットの成否を通知する。
【0031】
図2に戻って、ステップS104において、共通領域管理部140が、第1データエリア131の上記サービスチケット、上記共通鍵および上記アルゴリズムを取得し、そのサービスチケットから、サービス提携者ID(図6参照)を抽出する。具体的には、アプリケーション管理部130が、第1アプリケーション132の処理に従い、第1データエリア131に保存されている上記サービスチケットと上記共通鍵と上記アルゴリズムとを共通領域管理部140に渡す。そして、共通領域管理部140が、上記サービスチケットから、サービス提携者IDを抽出する。
【0032】
次に、共通領域管理部140が、上記サービスチケット、上記共通鍵、上記アルゴリズムおよび提携者IDを第2データエリア141に保存する(ステップS105)。
【0033】
その後、ユーザが、第2サービスの提供をする加盟店(ファーストフード店)に赴き、その加盟店の第2端末40に対し、電子媒体10をかざす。そうすると、電子媒体10と第2端末40とが通信を行い、電子媒体10が、第2端末40から、第1アプリケーションまたは第2アプリケーションのいずれかを特定するアプリケーションの選択コマンドを受信する(ステップS106)。具体的には、第2端末40は、まず、電子媒体10との通信において、提携者IDをアプリケーションの識別子として上記選択コマンドに代入する。そして、第2端末40は、上記代入した選択コマンドを電子媒体10に送信する。この送信により、電子媒体10が、その選択コマンドを入力する。
【0034】
ここで、上記選択コマンド等の構成例を図4に示す。この例では、CLA(クラス)201、INS(命令コード)202、P1(パラメータ)203、P2(パラメータ)203、Lc(データ長)205、ファイル選択アドレス(データ部)206およびLe(応答データ長)を含んで構成されている。これらは、ISO/IEC7816−4に規定されているので、詳細な説明は省略する。
本実施の形態では、例えば、INS202に「A4」がセットされている場合、アプリケーション検証部121は、選択コマンドであると判断し、ファイル選択アドレス206に代入されているデータを取得することになる。なお、INS202に「A4」以外の値がセットされている場合、当該コマンドが、選択コマンド以外の他のコマンド(認証コマンド、取得コマンド等)を示すことになる。
【0035】
図2に戻って、ステップS107において、電子媒体10では、選択部120が、入出力部110を介して、第2端末40からの選択コマンドを取得する。
【0036】
ステップS108では、アプリケーション検証部121は、上記選択コマンドに示されたアプリケーションがアプリケーション管理部130に存在するかを検証する。具体的には、アプリケーション検証部121は、まず、上記選択コマンドに代入された提携者IDを特定する。続いて、アプリケーション検証部121は、その提携者IDをアプリケーションの識別子として持つアプリケーションが存在するかをアプリケーション管理部130に問い合わせる。そして、アプリケーション検証部121は、例えば、アプリケーション管理部130から、当該アプリケーションが存在しない旨のメッセージを受ける。
その後、アプリケーション検証部121における検証の結果、当該アプリケーションがアプリケーション管理部130に存在しないことが確認されると、アプリケーション検証部121が、共通領域検証部122に上記選択コマンドを渡す(ステップS109)。
【0037】
ステップS110では、共通領域検証部122は、アプリケーション検証部121から渡された選択コマンドに含まれる提携者ID(サービスデータ)が、共通領域管理部140に存在するかを検証する。具体的には、共通領域検証部122は、まず、上記選択コマンドに代入された提携者IDを特定する。続いて、共通領域検証部122は、その提携者IDが存在するかを共通領域管理部140に問い合わせる。問い合わせを受けた共通領域管理部140は、上記提携者IDが第2データエリア141に保存されているかどうかを確認する。そして、共通領域検証部122は、共通領域管理部140から、上記問い合わせの結果を受ける。
【0038】
ステップS111では、共通領域検証部122が、上記検証により、提携者IDが存在するかどうかを判断する。例えば、上記問い合わせの結果として、提携者ID(サービスデータ)が第2データエリア141に存在する旨のメッセージが示された場合、共通領域検証部122は、提携者IDが存在すると判断する。
そして、ステップS111における判断の結果、提携者IDが存在しない場合(ステップS111のNo)、共通領域検証部122は、第2端末40に対し、アプリケーションの選択失敗を示すステータス情報を含む応答データを送信する(ステップS112)。
【0039】
他方、提携者IDが存在すると判断された場合(ステップS111のYes)、共通領域検証部120は、仮想アプリ部142をアプリケーションとして選択する(ステップS113)。なお、仮想アプリ部142は、電子媒体10に組み込まれたアプリケーションの全体処理に従って動作してもよい。あるいは、仮想アプリ部142は、ライブラリ、ネイティブアプリケーション、モジュール等のプログラムに従って動作してもよい。
例えば、仮想アプリ部142がアプリケーションの処理に従って機能する場合、共通領域検証部122は、仮想アプリ部142を機能させるアプリケーションの識別子を選択することになる。また、仮想アプリ部142を機能させるアプリケーションの識別子が割り当てられていない場合、共通領域検証部122は、仮想アプリ部142を呼び出す。
【0040】
ステップS114では、仮想アプリ部142は、乱数を発生させて、共通領域検証部122に渡す。
ステップS115では、共通領域検証部122は、第2端末40に対し、アプリケーションの選択成功を示すステータス情報と上記乱数とを含む応答データを送信する。当該送信を受け、第2端末40は、上記乱数も取得した場合、電子媒体10の仮想アプリ部142との間で認証を行う(認証処理は図6参照)。これは、第2端末40が、電子媒体10から、サービスチケット等を取得することになるので、その権限を証明するためである。
【0041】
なお、電子媒体10の仮想アプリ部142と第2端末40との間で通信が行われている場合、選択部120は、選択コマンドを新たに入力しない限り、後記するコマンド(認証コマンド、取得コマンド、終了コマンドの3種類)やその他のコマンドをすべて仮想アプリ部142にフォワーディングする。ここで、第2端末40は、仮想アプリ部142との通信プロトコルとして、上記3種類のコマンドを認識できるようにしておく必要がある。
【0042】
次に、上記ステップS102(図2参照)の詳細例について図5に基づいて説明する。ここでは、ユーザが、8000円の商品を購入する際に、電子媒体10の第1サービスを利用してクレジット決済する場合について説明する。
まず、ユーザが、ある加盟店のレジで、電子媒体10を店員に提示し、その店員がその電子媒体10を第1端末30に接続したものとする。そうすると、電子媒体10の入出力部110が、第1端末30から、第1アプリケーション132を選択するための選択コマンドを受信する(ステップS201)。この場合、第1端末30は、電子媒体10から、第1アプリケーション132に対応つけられているアプリケーションの識別子を電子媒体10に送信する。
【0043】
ステップS202において、選択部120が、入出力部110から上記選択コマンドを受け取り、アプリケーション検証部121が、その選択コマンドを取得する。
ステップS203において、アプリケーション検証部121は、取得した選択コマンドに応じて、アクセス先を特定する。具体的には、アプリケーション検証部121は、まず、選択コマンドに含まれているアプリケーション識別子を特定し、それをアプリケーションの識別子とする第1アプリケーション132をアクセス先に選ぶ。
【0044】
ステップS204において、アプリケーション検証部121は、特定したアクセス先の第1アプリケーション131がアプリケーション管理部130内に存在するかどうかを検証する。具体的には、アプリケーション検証部121は、アプリケーション管理部130に対し、第1アプリケーション131が存在するかどうかを問い合わせる。この問い合わせの結果、例えば、アプリケーション管理部130が、第1アプリケーション131の存否を確認し、アプリケーション管理部130は、アプリケーション検証部121に対し、上記存否の確認結果を示すメッセージを送る。
【0045】
ステップS204における上記検証により、アプリケーション検証部121が、第1アプリケーション132が存在すると判断した場合(ステップS205のYes)、アプリケーション管理部130は、第1アプリケーション132を選択する(ステップS206)。
【0046】
ステップS207において、アプリケーション検証部121は、第1アプリケーション132の選択成功を示すステータス情報を含む応答データを、入出力部110を介して、第1端末30に送信する。その後、ステップS208において、アプリケーション管理部130が、第1アプリケーション132の処理に従って、第1端末30との間で通信を行い、所定のクレジット決済処理(パスワードの送信等)を行った後、上記通信を終了する(ステップS209)。
【0047】
他方、ステップS204における上記検証により、アプリケーション検証部121が、第1アプリケーション132が存在しないと判断した場合(ステップS205のNo)、アプリケーション検証部121は、第1アプリケーション132の選択失敗を示すステータス情報を含む応答データを、入出力部110を介して、第1端末30に送信する(ステップS210)。
【0048】
次に、図2のステップS115後の処理について図6に基づいて説明する。ここでは、第2端末40と電子媒体10の仮想アプリ部142との間で認証を行う場合の処理例について説明する。
ステップS401において、第2端末40は、電子媒体10(仮想アプリ部142)から、ステータス情報(アプリケーションの選択成功)と乱数とを取得する。
ステップS402において、第2端末40は、あらかじめ保存していた共通鍵で乱数を暗号化する。この共通鍵は、図2のステップS105で電子媒体10の第2データエリア141に保存されている共通鍵と同じものである。
ステップS403において、第2端末40は、暗号化した乱数データを認証コマンドとともに電子媒体10に送信する。
【0049】
上記送信を受け、電子媒体10では、仮想アプリ部142が、入出力部110および選択部120を介して、乱数データと認証コマンドとを取得する(ステップS404)。この認証コマンドは、第2端末40と電子媒体10の仮想アプリ部142との間で認証を行うためのものである。
ステップS405において、仮想アプリ部142が、上記認証コマンドに従い、乱数データを復号する。この復号は、第2データエリアに保存されている共通鍵(図2のS105参照)を用いて行う。
ステップS406において、仮想アプリ部142は、復号した乱数が、第2端末40に送信した乱数(図2のステップS115参照)と一致するかどうかを検証する。その結果、一致しなかった場合(ステップS407のNo)、仮想アプリ部142は、認証失敗を示すステータス情報を含む応答データを生成して、第2端末40に対して送信する(ステップS408)。
【0050】
他方、ステップS406における検証の結果、一致した場合(ステップS407のYes)、仮想アプリ部142は、認証成功を示すステータス情報を含む応答データを生成して、第2端末40に送信する(ステップS409)。
【0051】
その後、ステップS410において、仮想アプリ部142および第2端末40の各々は、あらかじめ保持しているアルゴリズム(セッション鍵の生成用)に従って、共通鍵および乱数から、セッション鍵を生成する。そして、仮想アプリ部142と第2端末40との間では、生成されたセッション鍵を用いて、セキュアチャネルが設定される。このようにして、仮想アプリ部142は、正当な権限を持つ第2端末40に対してのみ、通信を行う。このため、本実施の形態では、第2端末40以外の端末と電子媒体10との間で通信を行うことができない。
【0052】
このようにして、その後、第2端末40は、仮想アプリ部142から、第2データエリアに保存されているサービスチケットを取得することとなる。この処理例を図7に示す。
【0053】
図7は第2端末40が電子媒体10の仮想アプリ部142からサービスチケットを取得する場合の処理例を示す図である。
ステップS501において、第2端末40が、サービスチケットの取得コマンド(構成例は図4参照)を電子媒体10に対して送信する。このとき、第2端末40は、自己の店舗IDも電子媒体10に送信する。
【0054】
ステップS502において、電子媒体10の仮想アプリ部142は、上記取得コマンドを受信し、その取得コマンドに従い、第2データエリア141に保存されているサービスチケットの提携者IDが一致する全てのサービスチケットを取得する。
ステップS503において、仮想アプリ部142は、取得したサービスチケットの中から、有効期限等の条件を満たすサービスチケットを選定し、それらを全て第2端末40に送信する。ここで選定されたサービスチケットは、例えば、有効期限(図3の有効期限303の値を参照)内のもののほか、第2端末40に割り当てられている店舗ID(図3の利用可能店舗IDの値を参照)を含むものである。
【0055】
ステップS504において、第2端末40は、電子媒体10の仮想アプリ部142から送信されたサービスチケットを受信する。そして、第2端末40は、当該サービスチケットのサービスIDから、そのサービス内容を特定(選択)して、例えば、ディスプレイ(タッチパネル機能付き)に表示する。なお、第2端末40は、サービスIDとサービス内容との対応関係をあらかじめ格納しているものとする。
【0056】
この表示例を図8に示す。この表示例では、サービス一覧403がディスプレイ402に表示されている。サービス一覧403には、例えば、サービスIDとサービス内容とが対応づけられている。なお、図8では、リーダライタ401が電子媒体10と非接触(または接触)の状態で通信するようになっている。
ユーザは、サービス一覧403の中から、特定のサービスIDを選択する。この選択は、例えば、ディスプレイへのタッチ操作により実現される。
これにより、第2端末40は、選択されたサービスIDのサービス(サービス内容)を選択することとなる(図7のステップS505)。
【0057】
図7のステップS506において、第2端末40は、選択したサービスのサービスチケットのMAC(メッセージ認証符号)を検証する。具体的には、第2端末40は、当該サービスチケット含まれているハッシュ307(図3参照)を検証する。これにより、サービスチケットが改ざんされていないかを調べることが可能となる。
上記検証の結果、サービスチケットが改ざんされていない場合、第2端末40は、電子媒体10に対し、当該サービスチケットと共に終了コマンドを送信する(ステップS507)。終了コマンドは、第2端末40との通信の終了処理を行うためのコマンドである(終了コマンドの構成例は図3参照)。
【0058】
ステップS508において、電子媒体10の仮想アプリ部142が、第2端末40から、サービスチケットと共に終了コマンドを取得する。そして、仮想アプリ部142が、終了コマンドに従い、当該取得したサービスチケットと一致するサービスチケットを第2データエリア141から消去する。
ステップS509において、仮想アプリ部142が、終了コマンドに従い、第2端末40との通信処理を終了する。そして、ステップS510において、仮想アプリ部142が、終了コマンドに従い、共通領域検証部120に対し、第2端末40との通信が終了した旨の通知を行う。
ステップS511において、共通領域検証部122が、仮想アプリ部142の選択を解除する。そして、ステップS512において、選択部120が、アプリケーションへのアクセス先をデフォルト(例えば、アプリケーション管理部131)に設定する。
【0059】
なお、ステップS504の処理後、ユーザが、サービス一覧403(図8参照)の中から、特定のサービスIDを選択しない場合、例えば、店員が、第2端末40を操作し、所定の終了操作を行う。そうすると、第2端末40は、終了コマンドを電子媒体10に送信し、上記ステップS509以降の処理が行われることとなる。
【0060】
[選択部での他の検証例]
次に、選択部120での他の検証例(アプリケーションのアクセス先を規定した選択手順例)について図9に基づいて説明する。
実施の形態1では、アプリケーション検証部121、共通領域検証部122の順にアプリケーションの有無を検証して特定する場合(図2のS108、S110に相当)について説明したが、図4に示された選択コマンドのP1(パラメータ)203の値に応じて、選択部120での検証が実行されるようにしてもよい。このときの選択コマンドのP1(パラメータ)203の値(図4参照)と、検証の内容との対応関係を図9に示す。なお、この対応関係は、選択部120があらかじめ管理しておく。
【0061】
図9では、P1(パラメータ)203の値(図4参照)と、検証の内容との対応関係が示されている。この例では、アプリケーション管理部130のみ検証する場合、共通領域管理部140のみ検証する場合、および、双方の管理部130、140を検証する場合の3つのパターンが示されている。
例えば、図4に示したP1(パラメータ)203のb3が「1」の場合、アプリケーション検証部121が、アプリケーション管理部130のみ検証することになる。
また、図4に示したP1(パラメータ)203のb8が「1」の場合、共通領域検証部122が、共通領域管理部140のみ検証することとなる。このようにすると、共通領域検証部122が、第2端末40からの選択コマンドに示された選択手順に従い、共通領域管理部140へのアクセスを選択することができる。
さらに、図4に示したP1(パラメータ)203のb3およびb8がともに「1」の場合、まず、アプリケーション検証部121が、アプリケーション管理部130を検証する。そして、その結果、アプリケーション管理部130に、選択コマンドに示されたファイル選択アドレスと一致する識別子を持つアプリケーションが記録されていない場合、共通領域検証部122が、共通領域管理部140を検証することとなる。
なお、図2に示したように、アプリケーション検証部121、共通領域検証部122が順に検証する場合、図9の内容に従って図4に示した選択コマンドのP1は、「84」に設定しなければならない。
【0062】
なお、実施の形態1では、電子媒体10には第2アプリケーションが記録されないので、第2端末40は、共通領域管理部140のみを検証するように、選択コマンドのP1(第1パラメータ)を設定するようにしてもよい。
また、選択コマンドのP1はパラメータの場合で説明したが、コードを設定するようにしてもよい。さらに、選択コマンドのP1のみの値に応じて上記検証の内容をあらかじめ規定する場合について説明したが、選択コマンドのP2の値のみを用いても検証の内容を規定してもよい。あるいは、選択コマンドのP1およびP2の組み合わせにより検証の内容を規定するようにしてもよい。
【0063】
以上のように、電子媒体10は、各端末30、40からの要求(選択コマンド)を入出力部110を介して受け、アプリケーション管理部130または共通領域管理部140へのアクセス先を選択する選択部120(121、122を含む)を有する。また、電子媒体10は、選択部120(アプリケーション検証部121)の選択により、第1アプリケーションの処理を実行するアプリケーション管理部130と、選択部120(共通領域検証部122)の選択により、第2端末40との間で通信を行い、第1アプリケーションの処理のためのサービスデータを第2端末40に提供する共通領域管理部140とを含む。このため、第2端末40からの要求に応じて、共通領域管理部140が、上記サービスデータを第2端末40に送信したり、アプリケーション管理部130が第1アプリケーションの処理を実行したりすることとなる。したがって、第2アプリケーションを電子媒体10に搭載することなく、第1アプリケーションおよび第2アプリケーションの双方の処理を実行することが可能となる。
よって、電子媒体10の発行スキームに対応させることなく、様々なサービスの提供を行うことができる。例えば、電子媒体10(搭載のアプリケーション)によるサービスを用いて行っているサービス提供者と一時的に業務提携するサービス提携者であっても、その電子媒体10にアプリケーションを新たに搭載することなく、電子媒体10によるサービスを行うことができる。
【0064】
また、実施の形態1によると、電子媒体10は、アプリケーション管理部130と共通領域管理部140とを含むので、第1アプリケーションおよび第2アプリケーションの処理のための各サービスデータが別々に管理される。また、選択部120が、それぞれの管理部130、140へのアクセスをアプリケーション(第1、第2)ごとに行う。このため、第2端末40は、第1端末30と電子媒体10との間の通信プロトコルと同じプロトコルを用いて電子媒体10にアクセスする必要がない。さらに、このように構成することにより、第2端末40は、第1端末30の通信プロトコルとは関係なく、電子媒体10との間の通信プロトコルに従って、共通鍵等による認証を行うことが可能となる。よって、電子媒体10によるサービス(ここでは第2アプリケーションのためのもの)を簡易に提供することができる。
【0065】
(実施の形態2)
実施の形態2は、複数のサービス提供者(クレジット会社など)が1つの電子媒体を共有してサービスを提供する場合であっても、前述した提携者が、実施の形態1の場合と同様に、その電子媒体を用いて、独自のサービスを副次的に行うことが可能になる場合のものである。
図10は本発明の実施の形態2における電子媒体を含むシステム全体の構成例を示す図である。なお、実施の形態1と同一部分については、実施の形態1と同一の符号(用語を含む)を付し、重複説明を省略する。
実施の形態2では、電子媒体の発行者が、A社のほかにもB社とも契約を結んでいるものとする。このため、電子媒体10Aには、第1アプリケーションのほかにも、B社の第2アプリケーションも記録されている点が、実施の形態1の場合と異なる。
図10に示すように、電子媒体10Aは、アプリケーション管理部130を有し、この管理部130が、第3データエリア133および第2アプリケーション134をさらに有する。第3データエリア133は、第2アプリケーション134の処理に必要なデータを格納する。
その他の電子媒体10Aを含むシステム全体の構成は、図1の場合と同様である。
【0066】
次に、電子媒体10Aのユーザが、その電子媒体10Aを用いて、第2サービスを受ける場合の処理手順の概要について図11に基づいて説明する。ここでは、4つのステップS201〜S204を図2に付加した点が、図2の場合と異なるので、この点を中心に説明する。
ステップS201において、例えば、第2アプリケーション134がアプリケーション管理部130に管理されていなかった場合、アプリケーション検証部121は、当該アプリケーションが存在しないと判断し(ステップS201のNo)、ステップS110以降の処理が行われる。
他方、第2アプリケーション134がアプリケーション管理部130に管理されている場合(第2アプリケーション134のダウンロード済み等の場合)、アプリケーション検証部121は、当該アプリケーションが存在すると判断し(ステップS201のYes)、ステップS202に進む。なお、この場合、アプリケーション管理部130に管理されている第2アプリケーション134には、提携者IDがアプリケーションの識別子として一部割り当てられている。
【0067】
ステップS202において、アプリケーション検証部121は、例えば、選択コマンドのP2(図4参照)の値を確認する。本実施の形態においては、確認されたP2に、図10に示したように、検証の内容を表す値が設定されているものとする。
【0068】
そして、アプリケーション検証部512は、上記選択コマンドのP2(図4参照)の値の確認により、例えば、アプリケーション管理部130を検証して、第2アプリケーション134を選択する(ステップS203のYes)。次に、ステップS204において、アプリケーション検証部512は、上記選択コマンドで示された第2アプリケーション134の選択成功を示すステータス情報を含む応答データを第2端末40に送信する。
その後、第2端末40と第2アプリケーション134との間で、所定のプロトコルに従って通信を行う。
【0069】
他方、ステップS202における確認の結果、選択コマンドのP2(図4参照)が共通領域管理部140の検証を示していた場合、アプリケーション検証部512は、第2アプリケーション134を選択することなく(ステップS203のNo)、ステップS110に進む。これにより、アプリケーション検証部512が、共通領域検証部122に選択コマンドを渡すこととなり(ステップS110)、図2の場合と同様、ステップS111以降の処理が行われる。このようにしても、実施の形態1と同様の効果が得られる。
【0070】
なお、各実施の形態1、2において、第2サービスは、フードの無料サービスを一例としてあげたが、これに限定されない。例えば、サービスの提携内容によってさまざまな内容としてもよい。
また、電子媒体10、10Aは、LSI(Large Scale Integration)で実現するようにしてもよい。さらに、各部120、130、140をそれぞれ1チップ化してもよいし、その一部あるいは全部を1チップ化してもよい。なお、ここではLSIで説明したが、これは、集積度に応じ、IC(Integrated Circuit)、システムLSI、スーパLSI、ウルトラLSIと呼称されることもある。
また、集積回路化の手法はLSIに限るものではなく、専用回路もしくは汎用プロセサで実現してもよい。LSI製造後にプログラムすることが可能なFPGA(Field Programmable Gate Array)を適用してもよい。あるいは、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを適用してもよい。
更に、半導体技術の進歩あるいは派生する別技術によりLSIに置き換わる集積回路化の技術が開発されれば、当然、その技術を用いて、上記各部120、130、140の集積化を行うようにしてもよい。また、バイオ技術の適応等が可能性としてあり得る。LSIによる集積化により、電子媒体の小型化をさらに実現することができる。
【産業上の利用可能性】
【0071】
本発明は、未搭載のアプリケーションの処理のためのサービスデータを搭載し、また、外部端末との通信によりそのサービスデータをその外部端末に送信する。このため、ICカード等の電子媒体を提示することにより享受できるサービスの拡大に貢献する。
【図面の簡単な説明】
【0072】
【図1】本発明の実施の形態1における電子媒体を含むシステム全体の構成例を示す図である。
【図2】図1の電子媒体による第2サービスを受ける場合の処理手順の概要を示す図である。
【図3】サービスチケットの構成例を示す図である。
【図4】選択コマンド等の構成例を示す図である。
【図5】図2のステップS102の詳細例を示す図である。
【図6】図2のステップS115後の処理を示す図である。
【図7】第2端末が電子媒体の仮想アプリ部からサービスチケットを取得する場合の処理例を示す図である。
【図8】図1の第2端末の表示例を示す図である。
【図9】アプリケーションのアクセス先を規定した選択手順例を示す図である。
【図10】本発明の実施の形態2における電子媒体を含むシステム全体の構成例を示す図である。
【図11】図10の電子媒体による第2サービスを受ける場合の処理手順を示す図である。
【図12】従来におけるICカードの記録情報を示す図である。
【図13】従来における個別領域と共通領域へアクセス方法を示す図である。
【符号の説明】
【0073】
10、10A 電子媒体
30 第1端末
40 第2端末
110 入出力部
120 アプリケーション選択部
121 アプリケーション検証部
122 共通領域検証部
130 アプリケーション管理部
140 共通領域管理部

【特許請求の範囲】
【請求項1】
外部装置との入出力部と、
前記外部装置からの要求を前記入出力部を介して受け、第1アプリケーションを管理する第1管理部、または第2アプリケーションの処理のためのサービスデータを管理する第2管理部へのアクセス先を選択する選択部と、
前記選択部により選択されたアクセス先が前記第1管理部の場合、前記管理した第1アプリケーションの処理を実行する前記第1管理部と、
前記選択部により選択されたアクセス先が前記第2管理部の場合、前記外部端末との間で通信を行い、前記管理したサービスデータを当該外部端末に提供する前記第2管理部と、
を含む電子媒体。
【請求項2】
前記外部装置からの要求は、前記第1アプリケーションまたは前記第2アプリケーションのいずれかを選択するための選択コマンドで行われ、
前記選択部は、
前記選択コマンドが前記第1アプリケーションを示す場合は、前記第1管理部へのアクセス先を選択する第1選択部と、前記選択コマンドが第2アプリケーションを示す場合は、前記第2管理部へのアクセスを選択する第2選択部と、
をさらに含む請求項1に記載の電子媒体。
【請求項3】
前記第2選択部は、前記第1選択部における選択がされなかった場合に、第2管理部へのアクセスを選択する、
請求項2に記載の電子媒体。
【請求項4】
前記選択コマンドには、前記第1管理部または前記第2管理部の選択手順が示されており、
前記第2選択部は、前記外部装置から要求された選択コマンドに示された選択手順に従い、前記第2管理部へのアクセスを選択する、
請求項2に記載の電子媒体。
【請求項5】
前記入出力部、前記選択部、前記第1管理部および前記第2管理部は、クレジットカード、ポイントカードまたはデビットカードの少なくともいずれかに搭載されている、請求項1ないし請求項4のいずれか1項に記載の電子媒体。
【請求項6】
外部装置とデータの入出力を行う入出力部と、
前記入出力部からの前記データに対して第1処理を行う第1のアプリケーションを管理する第1管理部と、
前記入出力部からの、識別子を有する前記データに対して、前記第1処理とは異なる第2処理を行う第2のアプリケーションを管理する第2管理部と、
前記入出力部からの前記データに基づき、前記第1管理部または前記第2管理部のいずれかを選択する選択部と、
を含む電子媒体。
【請求項7】
前記識別子は、あらかじめ設定され、かつ前記第1のアプリケーションの提供者と提携している提携者のIDである、請求項6に記載の電子媒体。
【請求項8】
前記選択部は、
前記入出力部からの前記データが前記識別子を有し、かつ当該識別子に対応する前記第2のアプリケーションが前記第2管理部に管理されている場合、前記第2管理部を選択し、
前記第2管理部に管理されている当該第2のアプリケーションによる前記第2処理を実行させる、請求項7に記載の電子媒体。
【請求項9】
請求項1ないし請求項5のいずれか1項に記載の電子媒体を含むことを特徴とする情報端末。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate


【公開番号】特開2007−249544(P2007−249544A)
【公開日】平成19年9月27日(2007.9.27)
【国際特許分類】
【出願番号】特願2006−71476(P2006−71476)
【出願日】平成18年3月15日(2006.3.15)
【出願人】(000005821)松下電器産業株式会社 (73,050)
【Fターム(参考)】