(57)【要約】【課題】アプリケーションを用いたサービスをより簡易に提供する電子媒体等を提供する。【解決手段】各端末３０、４０との入出力部１１０と、入出力部１００を介して要求を受け、アクセス先を選択するアプリケーション選択部１２０と、アプリケーション選択部１２０の選択により、第１アプリケーションの処理を実行するアプリケーション管理部１３０と、アプリケーション選択部１２０の選択により、第２端末４０との間で通信を行い、第２アプリケーションの処理のためのサービスデータを第２端末４０に提供する。【選択図】図１
2007249544.tif 000002
【特許請求の範囲】
【請求項１】
外部装置との入出力部と、
前記外部装置からの要求を前記入出力部を介して受け、第１アプリケーションを管理する第１管理部、または第２アプリケーションの処理のためのサービスデータを管理する第２管理部へのアクセス先を選択する選択部と、
前記選択部により選択されたアクセス先が前記第１管理部の場合、前記管理した第１アプリケーションの処理を実行する前記第１管理部と、
前記選択部により選択されたアクセス先が前記第２管理部の場合、前記外部端末との間で通信を行い、前記管理したサービスデータを当該外部端末に提供する前記第２管理部と、
を含む電子媒体。
【請求項２】
前記外部装置からの要求は、前記第１アプリケーションまたは前記第２アプリケーションのいずれかを選択するための選択コマンドで行われ、
前記選択部は、
前記選択コマンドが前記第１アプリケーションを示す場合は、前記第１管理部へのアクセス先を選択する第１選択部と、前記選択コマンドが第２アプリケーションを示す場合は、前記第２管理部へのアクセスを選択する第２選択部と、
をさらに含む請求項１に記載の電子媒体。
【請求項３】
前記第２選択部は、前記第１選択部における選択がされなかった場合に、第２管理部へのアクセスを選択する、
請求項２に記載の電子媒体。
【請求項４】
前記選択コマンドには、前記第１管理部または前記第２管理部の選択手順が示されており、
前記第２選択部は、前記外部装置から要求された選択コマンドに示された選択手順に従い、前記第２管理部へのアクセスを選択する、
請求項２に記載の電子媒体。
【請求項５】
前記入出力部、前記選択部、前記第１管理部および前記第２管理部は、クレジットカード、ポイントカードまたはデビットカードの少なくともいずれかに搭載されている、請求項１ないし請求項４のいずれか１項に記載の電子媒体。
【請求項６】
外部装置とデータの入出力を行う入出力部と、
前記入出力部からの前記データに対して第１処理を行う第１のアプリケーションを管理する第１管理部と、
前記入出力部からの、識別子を有する前記データに対して、前記第１処理とは異なる第２処理を行う第２のアプリケーションを管理する第２管理部と、
前記入出力部からの前記データに基づき、前記第１管理部または前記第２管理部のいずれかを選択する選択部と、
を含む電子媒体。
【請求項７】
前記識別子は、あらかじめ設定され、かつ前記第１のアプリケーションの提供者と提携している提携者のＩＤである、請求項６に記載の電子媒体。
【請求項８】
前記選択部は、
前記入出力部からの前記データが前記識別子を有し、かつ当該識別子に対応する前記第２のアプリケーションが前記第２管理部に管理されている場合、前記第２管理部を選択し、
前記第２管理部に管理されている当該第２のアプリケーションによる前記第２処理を実行させる、請求項７に記載の電子媒体。
【請求項９】
請求項１ないし請求項５のいずれか１項に記載の電子媒体を含むことを特徴とする情報端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションプログラムを記録した電子媒体に関するものである。
【背景技術】
【０００２】
近年、個人的な情報を自由に持ち運ぶことが可能なデータキャリアとして、電子媒体が用いられている。電子媒体の種類には、紙製のカードやエンボスカード、磁気ストライプカード、ICカード等、様々なものがある。特にICカードは、セキュリティに対する社会的な意識が高まる中、強固なセキュリティを備えた電子媒体として注目されており、磁気カードからICカードへの移行が急速に進められている。
そして、このようなカードの用途が多岐に及んでいる。例えば、認証カード、クレジットカード、ポイントカードなどがある。そのため、カードには、カードの所有者を認証するための鍵や個人情報、現金化、ポイント換金のためのサービスに必要なデータが蓄積され、カードユーザが、カードを加盟店に提示したり、端末に通したりすることによって、あらかじめ契約されているサービスがカードユーザに提供される。
【０００３】
このようなカードは、多くの場合、カードユーザと契約を直接結んだサービス提供者が提供するサービスのために使用される。しかし、そのサービス提供者が他社とも提携している時に、カードユーザは、その提携先の会社が提供するサービスも享受することが可能な場合もある。つまり、カードに副次的な特典が付くこともある。
【０００４】
この場合、副次的なサービスを提供するアプリケーションプログラム(以下アプリケーションという)をICカードに複数搭載するようにしてもよい。このようにすると、個々のアプリケーションで使用される共通のデータを共有したり、アプリケーション間で連携してデータをやり取りしたりすることによって、カードユーザは、１枚のICカードを用い、直接契約を結んでいないサービス提供者の提携先のサービスを受けることが可能となる。
また、副次的なサービスを提供するアプリケーションをICカードに搭載せずに、サービス提供者によって搭載されたアプリケーションのデータ領域に対して、サービス提携者からのアクセスを許可してもよい。
【０００５】
従来、このようなICカードとして、次のようなものが知られていた。すなわち、ICカードには、種類の異なるサービス（サービス提供者、その提携者のものを含む）を提供するためのアプリケーションが記録され、個別領域と共通領域の各データ領域がある。共通領域は、さまざまな種類のサービス用端末（例えば、カード加盟店の端末）からのアクセスが許可されるように構成されている。そして、共通領域にアクセスしたサービス用端末からの要求に応じて、特定の種類のアプリケーションが起動し、データを提供する。このように構成することにより、ICカードは、種類の異なるサービス用端末に対してデータを提供し、カードユーザに対し、種類の異なるサービスを提供することが可能となっている（例えば、特許文献１参照）。
【０００６】
図１２はICカードの記録情報を示す図である。記録情報は、ＯＳ(Operation System)６０１、共通領域６０２、個別領域６０３およびカードフォーマットブロック６０４で構成されている。共通領域６０２に配置されるアプリケーションは、カード発行先のサービス提供者とその提携先との契約内容によって、その利用が制限される。個別領域６０３に配置されるアプリケーションは、サービス提供者のみがアクセス権限を持つ。
【０００７】
さらに具体的に説明する。図１３は、上記共通領域と個別領域の各々に配置されたアプリケーションへのアクセス方法を示す図である。ここでは、Ａ社のサービスを提供するためのアプリケーションが共通領域および個別領域の各々に登録されているものとする。そして、例えば、個別領域と共通領域の双方に同じサービスを提供するためのアプリケーションが配置される場合、そのアプリケーションの実ブロックが共通領域６０２に配置され、個別領域６０３の該当ブロックには、実ブロックへのリンクが張られる。これにより、対応するアプリケーションが実行されることになる。
また、Ａ社の端末装置は、共通領域へアクセスするための共通鍵ＫＩＦと、個別領域へアクセスするための個別鍵Ａとを管理しているので、双方の領域にアクセス可能になっている。他方、Ａ社以外の端末装置は、それぞれ、共通領域へアクセスするための共通鍵ＫＩＦのみを管理しているので、共通領域へのアクセスのみが可能になっている。
【０００８】
【特許文献１】特開２００１−３２５５８０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、特許文献１に記載したICカードでは、例えば図１３のＡ社が他社との間でデータのやり取りを行う場合、Ａ社は、他社の外部端末が共通領域にアクセスするためのＩＦ(InterFace)および鍵を設ける必要がある。そして、Ａ社以外の外部端末は、アプリケーションとのやり取りを可能にするための通信プロトコルやアクセスするための鍵を共有する必要がある。
また、共通鍵を用いて共通領域に搭載済みのアプリケーションへのアクセスを可能にすることで（図１３参照）、例えば、上記アプリケーションの共有者の一人がそのサービスを終了するたびに、そのサービス終了者からの当該アプリケーションへのアクセスができないように、共通鍵を更新しなければならない問題がある。
【００１０】
さらに、サービス提携者がICカードにアプリケーションを搭載させ、そのICカードを一時的に利用する場合であっても、そのサービス提携者は、そのICカードの発行スキームに則ってアプリケーションをICカードに搭載させる必要があった。
【００１１】
そこで、本発明は、このような状況下においてなされたもので、その目的は、電子媒体によるサービスをより簡易に行うことである。
【課題を解決するための手段】
【００１２】
上記目的を達成するために、本発明は、外部装置との入出力部と、上記外部装置からの要求を上記入出力部を介して受け、第１アプリケーションを管理する第１管理部、または第２アプリケーションの処理のためのサービスデータを管理する第２管理部へのアクセス先を選択する選択部と、上記選択部により選択されたアクセス先が上記第１管理部の場合、上記管理した第１アプリケーションの処理を実行する上記第１管理部と、上記選択部により選択されたアクセス先が上記第２管理部の場合、上記外部端末との間で通信を行い、上記管理したサービスデータを当該外部端末に提供する上記第２管理部と、を含む。
【発明の効果】
【００１３】
本発明によれば、電子媒体によるサービスをより簡易に行うことができる。
【発明を実施するための最良の形態】
【００１４】
（実施の形態１）
実施の形態１は、電子媒体によるサービスを行うサービス提供者（クレジット会社など）と業務提携している提携者（ファーストフード店など）も、その電子媒体を用いて、独自のサービスを副次的に行うことが可能になる場合のものである。
図１は本発明の実施の形態１における電子媒体を含むシステム全体の構成例を示す図である。ここでは、サービス提供者（Ａ社ともいう）が、電子媒体（例えば、セキュアストレージ等）１０の発行者と契約を結んでいるので、電子媒体１０のユーザが、その電子媒体１０を用いて、Ａ社の第１サービス（例えば、クレジット決済等）を受けられるものとする。また、Ａ社が、サービス提携者（Ｂ社ともいう）と業務提携しているので、電子媒体１０には、Ｂ社の第２サービス（例えば、フードの無料サービス）の特典が付けられるものとする。
しかし、Ｂ社は、電子媒体１０の発行者と契約を結んでいないため、電子媒体１０には、第２サービスを提供するための第２アプリケーションが記録されず、Ａ社の第１サービスを提供するための第１アプリケーションのみが記録されるようになっているものとする。
【００１５】
例えば、第１サービスがクレジット決済のサービスである場合、第２サービスとしては次のようなものがある。すなわち、クレジット決済の利用額が所定の額になったときに、特定の加盟店（例えば、ファーストフード店等）でフードの無料サービスを所定の期間内に受けられるというものである。
【００１６】
図１において、電子媒体１０が、発行サーバ２０、第１端末（端末装置）３０および第２端末（端末装置）４０の各々との間でデータ通信が可能になっている。データ通信は、非接触あるいは接触のいずれの方式であってもよい。２台の端末３０、４０は、電子媒体１０との間で非接触または接触の状態で通信を行うことが可能なものである。各端末３０、４０としては、例えば、パーソナルコンピュータ（電子媒体１０のリーダや入力装置、記憶装置、処理装置を含む）、ＰＯＳ(Point Of Sales)端末等がある。
本実施の形態では、第１端末３０は、第１サービスを提供する加盟店（例えば、デパート等）に設置され、第２端末４０は、第２サービスを提供する加盟店（例えば、ファーストフード店等）に設置されているものとする。
そして、第１端末３０は、インターネット等の通信ネットワーク８２を介して、Ａ社のコンピュータシステム６０に接続されている。このコンピュータシステム６０は、複数のサーバを含んで構成され、第１サービスを提供するための第１アプリケーション等を管理したり送信したりするようになっている。また、第２端末４０も、インターネット等の通信ネットワーク８３を介して、Ｂ社のコンピュータシステム７０に接続されている。コンピュータシステム７０は、複数のサーバを含んで構成され、第２サービスを提供するための第２アプリケーション等を管理するようになっている。
【００１７】
なお、本実施の形態では、第１端末３０とコンピュータシステム６０との間は、通信ネットワーク８２を通して通信可能な構成にしているが、例えば、オフラインとしてもよい。第２端末４０とコンピュータシステム７０との間も同様である。
発行サーバ２０は、電子媒体１０を発行するためのサーバであり、この発行サーバ２０も、インターネット等の通信ネットワーク８１を介して、コンピュータシステム５０に接続されている。コンピュータシステム５０は、例えば、複数のサーバを含んで構築されている。
【００１８】
電子媒体１０は、例えば、スマートカードモジュールを搭載したセキュアカード、セキュアストレージ、セキュアチップ等である。本実施の形態においては、電子媒体１０は、例えば、クレジットカードの単体で利用できるものとして説明するが、例えば、ポイントカード、デビットカード等で利用できるようにしてもよい。なお、電子媒体１０は、携帯電話等の情報端末（記憶装置、処理装置を含む）に着脱可能なようにしてもよいし、情報端末にあらかじめ装着してあってもよい。
【００１９】
電子媒体１０は、図１に示すように、入出力部１１０、アプリケーション選択部１２０（以下、選択部１２０という）、アプリケーション管理部（第１管理部）１３０、および共通領域管理部（第２管理部）１４０を有する。以下、これらの構成例を詳細に説明する。
【００２０】
入出力部１１０は、発行サーバ２０、第１端末３０または第２端末４０との間で、所定の情報（コマンド等）の授受を行う。
【００２１】
選択部１２０は、第１端末３０または第２端末４０からの後記するコマンド（選択コマンドともいう）に応じて、アプリケーション管理部１３０または共通領域管理部１４０のいずれかをアクセス先として選択する。具体的には、選択部１２０は、アプリケーション検証部（第１選択部）１２１と共通領域検証部（第２選択部）１２２とを有する。アプリケーション検証部１２１は、第１端末３０または第２端末４０からのコマンドに対応するアプリケーションが、管理部１３０に搭載されているかどうかを検証する。
共通領域検証部１２２は、アプリケーション検証部１２１における上記検証の結果、上記コマンドに対応するアプリケーションが搭載されていなかった場合に、そのアプリケーションが共通領域管理部１４０内にあるかどうかを検証する。なお、本実施の形態では、アプリケーション検証部１２１および共通領域検証部１２２の各々を選択部ということもある。
【００２２】
アプリケーション管理部１３０は、例えば、コンピュータシステム６０からダウンロードされた第１アプリケーション１３２を管理する。第１アプリケーション１３２は、第１サービスを提供するためのものであり、例えば、クレジット決済等を実現するためのものが該当する。具体的には、アプリケーション管理部１３０は、第１アプリケーション１３２の処理に必要なサービスデータ（例えば、パスワード等）を格納する第１データエリア１３１を有する。
【００２３】
共通領域管理部１４０は、第２データエリア１４１と仮想アプリ部１４２とを有する。仮想アプリ部１４２は、第２端末４０との間でデータの送受を行うために、第２アプリケーションが存在するかのように処理する。つまり、本実施の形態では、共通領域管理部１４０において、第２アプリケーションが管理されるようになっている。これは、上記Ｂ社が電子媒体１０の発行者と契約を結んでいないために、共通領域管理部１４０を含む電子媒体１０には、第２アプリケーションが格納されないようになっているからである。この点は、本発明の特徴点であり、後記する。第２アプリケーションは、例えば、フードの無料サービスを提供するためのものであり、例えば、第２端末４０上で実行されることとなる。
第２データエリア１４１は、第２アプリケーションを処理するためのサービスデータ（例えば、サービスチケット等）を格納する。図１では、１つの第２データエリア１４１が記載されているが、実際には、複数の第２データエリアが存在するものとする。
【００２４】
なお、選択部１２０（各検証部１２１、１２２を含む）、アプリケーション管理部１３０（第１データエリア１３１を含む）および共通領域管理部１４０（第２データエリア１４１、仮想アプリ部１４２を含む）は、例えば、ＣＰＵやメモリ、ＬＳＩチップのＲＯＭもしくはＥＥＰＲＯＭを含んで構成されている。そして、これらの各部１２０、１３０、１４０の機能は、上記ＣＰＵが、ＬＳＩチップのＲＯＭあるいはＥＥＰＲＯＭに格納されたプログラム（ソフトモジュール）を実行することによって、実現される。
【００２５】
次に、電子媒体１０のユーザが、その電子媒体１０を用いて、第２サービスを受ける場合の処理手順の概要について図２に基づいて説明する。ここでは、ユーザが、電子媒体１０を用いて、第１サービス（クレジットサービス）による決済を行う。そして、その利用額が所定額（例えば５０００円）に達するたびに、ユーザが、電子媒体１０を用いて、所定の加盟店（ファーストフード店）にて第２サービスを受けることができる場合について説明する。第２サービスは、例えば、所定の期間内に利用することが可能なフード無料サービスであり、この場合、ユーザは、第２サービスを受けるためのサービスチケット（電子チケット）を取得して電子媒体１０に登録しておく必要がある。以下、詳述する。
【００２６】
まず、ユーザが、例えば、電子媒体１０を搭載した情報端末を用いて、発行サーバ２０にアクセスし、所定の処理（パスワードの入力等）を行う。すると、発行サーバ２０が、電子媒体１０（情報端末）に対し、第１サービスを提供するための第１アプリケーション１３２をダウンロードする（ステップＳ１０１）。この場合、発行サーバ２０には、Ａ社と発行者との契約により、あらかじめ第１アプリケーション１３２が登録されている。この第１アプリケーション１３２は、サービス提供者ＩＤ（提供者ＩＤともいう）が対応づけられている。提供者ＩＤは、サービス提供者を識別するための識別情報であり、アプリケーションの識別子として用いられる。
なお、本実施の形態では、発行サーバ２０が、第１アプリケーション１３２をダウンロードする場合について説明したが、ダウンロード元のサーバは、これに限られない。例えば、発行者以外の者が管理するサーバ等であってもよい。
【００２７】
続いて、ユーザが、例えば、クレジット決済するために、電子媒体１０を第１端末３０に近づけた場合、電子媒体１０では、アプリケーション管理部１３０の第１アプリケーション１３２が起動し、第１アプリケーション１３２と第１端末３０との間でデータ通信（接触あるいは非接触）を行い、電子媒体１０が、所定のクレジット決済処理（第１データエリア１３１からパスワード等の読み出し等）を行う（ステップＳ１０２）。
【００２８】
そして、上記クレジット決済処理が完了した後、電子媒体１０のアプリケーション管理部１３０が、第１端末３０から、第２サービスの提供を受けるためのサービスチケット等を取得する（ステップＳ１０３）。具体的には、まず、電子媒体１０の入出力部１１０が、上記サービスチケットのほか、共通鍵とセッション鍵を生成するためのアルゴリズムとを入力する。共通鍵は、電子媒体１０と第２端末４０との間で通信が行われる際に、セキュアチャネルや認証等の場面で利用されるものである。
次に、選択部１２０が、上記サービスチケットと上記共通鍵と上記アルゴリズムとをアプリケーション管理部１３０に渡す。そして、アプリケーション管理部１３０が、第１アプリケーション１３２の処理に従い、上記サービスチケットと上記共通鍵と上記アルゴリズムとを第１データエリア１３１に保存する。
【００２９】
ここで、上記サービスチケットの構成例を図３に示す。この例では、サービスチケットは、サービス提携者ＩＤ３０１、サービス提携者名３０２、有効期限３０３、サービスＩＤ３０４、サービスメニューＩＤ３０５、利用可能店舗ＩＤ３０６およびハッシュを含んでいる。サービス提携者ＩＤ（提携者ＩＤともいう）３０１には、サービス提携者を識別するためのＩＤが示され、提携者名３０２には、そのサービス提携者名が示される。
有効期限３０３には、当該サービスチケットの有効期限が示される。サービスＩＤ３０４には、サービスの内容（例えばフード無料等）が示され、サービスメニューＩＤ３０５には、サービスの対象を特定するためのＩＤが示される。利用可能店舗ＩＤ３０６には、当該サービスチケットの利用が可能な店舗を識別するためのＩＤが示されている。なお、第１端末３０や第２端末４０には、店舗ＩＤがあらかじめ割り当てられているものとする。
ハッシュ３０７は、当該サービスチケットが改ざんされていないことを証明するためのものであり、上記データ３０１〜３０６のメッセージダイジェストとなっている。
【００３０】
なお、第１データエリア１３１に保存されたサービスチケットが正当なものであるかどうかの検証を行うために、次のような処理を行ってもよい。すなわち、電子媒体１０が、第１アプリケーション１３２の処理に従い、第１端末３０を通して、コンピュータシステム６０に対し、サービスチケットの正当性の成否をリクエストする。これにより、例えば、コンピュータシステム６０が、リクエストされたサービスチケットの発行履歴（提供者ＩＤ、発行日時等）を確認し、発行履歴の内容に応じて、そのサービスチケットの成否を通知する。
【００３１】
図２に戻って、ステップＳ１０４において、共通領域管理部１４０が、第１データエリア１３１の上記サービスチケット、上記共通鍵および上記アルゴリズムを取得し、そのサービスチケットから、サービス提携者ＩＤ（図６参照）を抽出する。具体的には、アプリケーション管理部１３０が、第１アプリケーション１３２の処理に従い、第１データエリア１３１に保存されている上記サービスチケットと上記共通鍵と上記アルゴリズムとを共通領域管理部１４０に渡す。そして、共通領域管理部１４０が、上記サービスチケットから、サービス提携者ＩＤを抽出する。
【００３２】
次に、共通領域管理部１４０が、上記サービスチケット、上記共通鍵、上記アルゴリズムおよび提携者ＩＤを第２データエリア１４１に保存する（ステップＳ１０５）。
【００３３】
その後、ユーザが、第２サービスの提供をする加盟店（ファーストフード店）に赴き、その加盟店の第２端末４０に対し、電子媒体１０をかざす。そうすると、電子媒体１０と第２端末４０とが通信を行い、電子媒体１０が、第２端末４０から、第１アプリケーションまたは第２アプリケーションのいずれかを特定するアプリケーションの選択コマンドを受信する（ステップＳ１０６）。具体的には、第２端末４０は、まず、電子媒体１０との通信において、提携者ＩＤをアプリケーションの識別子として上記選択コマンドに代入する。そして、第２端末４０は、上記代入した選択コマンドを電子媒体１０に送信する。この送信により、電子媒体１０が、その選択コマンドを入力する。
【００３４】
ここで、上記選択コマンド等の構成例を図４に示す。この例では、ＣＬＡ（クラス）２０１、ＩＮＳ（命令コード）２０２、Ｐ１（パラメータ）２０３、Ｐ２（パラメータ）２０３、Ｌｃ（データ長）２０５、ファイル選択アドレス（データ部）２０６およびＬｅ（応答データ長）を含んで構成されている。これらは、ＩＳＯ／ＩＥＣ７８１６−４に規定されているので、詳細な説明は省略する。
本実施の形態では、例えば、ＩＮＳ２０２に「Ａ４」がセットされている場合、アプリケーション検証部１２１は、選択コマンドであると判断し、ファイル選択アドレス２０６に代入されているデータを取得することになる。なお、ＩＮＳ２０２に「Ａ４」以外の値がセットされている場合、当該コマンドが、選択コマンド以外の他のコマンド（認証コマンド、取得コマンド等）を示すことになる。
【００３５】
図２に戻って、ステップＳ１０７において、電子媒体１０では、選択部１２０が、入出力部１１０を介して、第２端末４０からの選択コマンドを取得する。
【００３６】
ステップＳ１０８では、アプリケーション検証部１２１は、上記選択コマンドに示されたアプリケーションがアプリケーション管理部１３０に存在するかを検証する。具体的には、アプリケーション検証部１２１は、まず、上記選択コマンドに代入された提携者ＩＤを特定する。続いて、アプリケーション検証部１２１は、その提携者ＩＤをアプリケーションの識別子として持つアプリケーションが存在するかをアプリケーション管理部１３０に問い合わせる。そして、アプリケーション検証部１２１は、例えば、アプリケーション管理部１３０から、当該アプリケーションが存在しない旨のメッセージを受ける。
その後、アプリケーション検証部１２１における検証の結果、当該アプリケーションがアプリケーション管理部１３０に存在しないことが確認されると、アプリケーション検証部１２１が、共通領域検証部１２２に上記選択コマンドを渡す（ステップＳ１０９）。
【００３７】
ステップＳ１１０では、共通領域検証部１２２は、アプリケーション検証部１２１から渡された選択コマンドに含まれる提携者ＩＤ（サービスデータ）が、共通領域管理部１４０に存在するかを検証する。具体的には、共通領域検証部１２２は、まず、上記選択コマンドに代入された提携者ＩＤを特定する。続いて、共通領域検証部１２２は、その提携者ＩＤが存在するかを共通領域管理部１４０に問い合わせる。問い合わせを受けた共通領域管理部１４０は、上記提携者ＩＤが第２データエリア１４１に保存されているかどうかを確認する。そして、共通領域検証部１２２は、共通領域管理部１４０から、上記問い合わせの結果を受ける。
【００３８】
ステップＳ１１１では、共通領域検証部１２２が、上記検証により、提携者ＩＤが存在するかどうかを判断する。例えば、上記問い合わせの結果として、提携者ＩＤ（サービスデータ）が第２データエリア１４１に存在する旨のメッセージが示された場合、共通領域検証部１２２は、提携者ＩＤが存在すると判断する。
そして、ステップＳ１１１における判断の結果、提携者ＩＤが存在しない場合（ステップＳ１１１のＮｏ）、共通領域検証部１２２は、第２端末４０に対し、アプリケーションの選択失敗を示すステータス情報を含む応答データを送信する（ステップＳ１１２）。
【００３９】
他方、提携者ＩＤが存在すると判断された場合（ステップＳ１１１のＹｅｓ）、共通領域検証部１２０は、仮想アプリ部１４２をアプリケーションとして選択する（ステップＳ１１３）。なお、仮想アプリ部１４２は、電子媒体１０に組み込まれたアプリケーションの全体処理に従って動作してもよい。あるいは、仮想アプリ部１４２は、ライブラリ、ネイティブアプリケーション、モジュール等のプログラムに従って動作してもよい。
例えば、仮想アプリ部１４２がアプリケーションの処理に従って機能する場合、共通領域検証部１２２は、仮想アプリ部１４２を機能させるアプリケーションの識別子を選択することになる。また、仮想アプリ部１４２を機能させるアプリケーションの識別子が割り当てられていない場合、共通領域検証部１２２は、仮想アプリ部１４２を呼び出す。
【００４０】
ステップＳ１１４では、仮想アプリ部１４２は、乱数を発生させて、共通領域検証部１２２に渡す。
ステップＳ１１５では、共通領域検証部１２２は、第２端末４０に対し、アプリケーションの選択成功を示すステータス情報と上記乱数とを含む応答データを送信する。当該送信を受け、第２端末４０は、上記乱数も取得した場合、電子媒体１０の仮想アプリ部１４２との間で認証を行う（認証処理は図６参照）。これは、第２端末４０が、電子媒体１０から、サービスチケット等を取得することになるので、その権限を証明するためである。
【００４１】
なお、電子媒体１０の仮想アプリ部１４２と第２端末４０との間で通信が行われている場合、選択部１２０は、選択コマンドを新たに入力しない限り、後記するコマンド（認証コマンド、取得コマンド、終了コマンドの３種類）やその他のコマンドをすべて仮想アプリ部１４２にフォワーディングする。ここで、第２端末４０は、仮想アプリ部１４２との通信プロトコルとして、上記３種類のコマンドを認識できるようにしておく必要がある。
【００４２】
次に、上記ステップＳ１０２（図２参照）の詳細例について図５に基づいて説明する。ここでは、ユーザが、８０００円の商品を購入する際に、電子媒体１０の第１サービスを利用してクレジット決済する場合について説明する。
まず、ユーザが、ある加盟店のレジで、電子媒体１０を店員に提示し、その店員がその電子媒体１０を第１端末３０に接続したものとする。そうすると、電子媒体１０の入出力部１１０が、第１端末３０から、第１アプリケーション１３２を選択するための選択コマンドを受信する（ステップＳ２０１）。この場合、第１端末３０は、電子媒体１０から、第１アプリケーション１３２に対応つけられているアプリケーションの識別子を電子媒体１０に送信する。
【００４３】
ステップＳ２０２において、選択部１２０が、入出力部１１０から上記選択コマンドを受け取り、アプリケーション検証部１２１が、その選択コマンドを取得する。
ステップＳ２０３において、アプリケーション検証部１２１は、取得した選択コマンドに応じて、アクセス先を特定する。具体的には、アプリケーション検証部１２１は、まず、選択コマンドに含まれているアプリケーション識別子を特定し、それをアプリケーションの識別子とする第１アプリケーション１３２をアクセス先に選ぶ。
【００４４】
ステップＳ２０４において、アプリケーション検証部１２１は、特定したアクセス先の第１アプリケーション１３１がアプリケーション管理部１３０内に存在するかどうかを検証する。具体的には、アプリケーション検証部１２１は、アプリケーション管理部１３０に対し、第１アプリケーション１３１が存在するかどうかを問い合わせる。この問い合わせの結果、例えば、アプリケーション管理部１３０が、第１アプリケーション１３１の存否を確認し、アプリケーション管理部１３０は、アプリケーション検証部１２１に対し、上記存否の確認結果を示すメッセージを送る。
【００４５】
ステップＳ２０４における上記検証により、アプリケーション検証部１２１が、第１アプリケーション１３２が存在すると判断した場合（ステップＳ２０５のＹｅｓ）、アプリケーション管理部１３０は、第１アプリケーション１３２を選択する（ステップＳ２０６）。
【００４６】
ステップＳ２０７において、アプリケーション検証部１２１は、第１アプリケーション１３２の選択成功を示すステータス情報を含む応答データを、入出力部１１０を介して、第１端末３０に送信する。その後、ステップＳ２０８において、アプリケーション管理部１３０が、第１アプリケーション１３２の処理に従って、第１端末３０との間で通信を行い、所定のクレジット決済処理（パスワードの送信等）を行った後、上記通信を終了する（ステップＳ２０９）。
【００４７】
他方、ステップＳ２０４における上記検証により、アプリケーション検証部１２１が、第１アプリケーション１３２が存在しないと判断した場合（ステップＳ２０５のＮｏ）、アプリケーション検証部１２１は、第１アプリケーション１３２の選択失敗を示すステータス情報を含む応答データを、入出力部１１０を介して、第１端末３０に送信する（ステップＳ２１０）。
【００４８】
次に、図２のステップＳ１１５後の処理について図６に基づいて説明する。ここでは、第２端末４０と電子媒体１０の仮想アプリ部１４２との間で認証を行う場合の処理例について説明する。
ステップＳ４０１において、第２端末４０は、電子媒体１０（仮想アプリ部１４２）から、ステータス情報（アプリケーションの選択成功）と乱数とを取得する。
ステップＳ４０２において、第２端末４０は、あらかじめ保存していた共通鍵で乱数を暗号化する。この共通鍵は、図２のステップＳ１０５で電子媒体１０の第２データエリア１４１に保存されている共通鍵と同じものである。
ステップＳ４０３において、第２端末４０は、暗号化した乱数データを認証コマンドとともに電子媒体１０に送信する。
【００４９】
上記送信を受け、電子媒体１０では、仮想アプリ部１４２が、入出力部１１０および選択部１２０を介して、乱数データと認証コマンドとを取得する（ステップＳ４０４）。この認証コマンドは、第２端末４０と電子媒体１０の仮想アプリ部１４２との間で認証を行うためのものである。
ステップＳ４０５において、仮想アプリ部１４２が、上記認証コマンドに従い、乱数データを復号する。この復号は、第２データエリアに保存されている共通鍵（図２のＳ１０５参照）を用いて行う。
ステップＳ４０６において、仮想アプリ部１４２は、復号した乱数が、第２端末４０に送信した乱数（図２のステップＳ１１５参照）と一致するかどうかを検証する。その結果、一致しなかった場合（ステップＳ４０７のＮｏ）、仮想アプリ部１４２は、認証失敗を示すステータス情報を含む応答データを生成して、第２端末４０に対して送信する（ステップＳ４０８）。
【００５０】
他方、ステップＳ４０６における検証の結果、一致した場合（ステップＳ４０７のＹｅｓ）、仮想アプリ部１４２は、認証成功を示すステータス情報を含む応答データを生成して、第２端末４０に送信する（ステップＳ４０９）。
【００５１】
その後、ステップＳ４１０において、仮想アプリ部１４２および第２端末４０の各々は、あらかじめ保持しているアルゴリズム（セッション鍵の生成用）に従って、共通鍵および乱数から、セッション鍵を生成する。そして、仮想アプリ部１４２と第２端末４０との間では、生成されたセッション鍵を用いて、セキュアチャネルが設定される。このようにして、仮想アプリ部１４２は、正当な権限を持つ第２端末４０に対してのみ、通信を行う。このため、本実施の形態では、第２端末４０以外の端末と電子媒体１０との間で通信を行うことができない。
【００５２】
このようにして、その後、第２端末４０は、仮想アプリ部１４２から、第２データエリアに保存されているサービスチケットを取得することとなる。この処理例を図７に示す。
【００５３】
図７は第２端末４０が電子媒体１０の仮想アプリ部１４２からサービスチケットを取得する場合の処理例を示す図である。
ステップＳ５０１において、第２端末４０が、サービスチケットの取得コマンド（構成例は図４参照）を電子媒体１０に対して送信する。このとき、第２端末４０は、自己の店舗ＩＤも電子媒体１０に送信する。
【００５４】
ステップＳ５０２において、電子媒体１０の仮想アプリ部１４２は、上記取得コマンドを受信し、その取得コマンドに従い、第２データエリア１４１に保存されているサービスチケットの提携者ＩＤが一致する全てのサービスチケットを取得する。
ステップＳ５０３において、仮想アプリ部１４２は、取得したサービスチケットの中から、有効期限等の条件を満たすサービスチケットを選定し、それらを全て第２端末４０に送信する。ここで選定されたサービスチケットは、例えば、有効期限（図３の有効期限３０３の値を参照）内のもののほか、第２端末４０に割り当てられている店舗ＩＤ（図３の利用可能店舗ＩＤの値を参照）を含むものである。
【００５５】
ステップＳ５０４において、第２端末４０は、電子媒体１０の仮想アプリ部１４２から送信されたサービスチケットを受信する。そして、第２端末４０は、当該サービスチケットのサービスＩＤから、そのサービス内容を特定（選択）して、例えば、ディスプレイ（タッチパネル機能付き）に表示する。なお、第２端末４０は、サービスＩＤとサービス内容との対応関係をあらかじめ格納しているものとする。
【００５６】
この表示例を図８に示す。この表示例では、サービス一覧４０３がディスプレイ４０２に表示されている。サービス一覧４０３には、例えば、サービスＩＤとサービス内容とが対応づけられている。なお、図８では、リーダライタ４０１が電子媒体１０と非接触（または接触）の状態で通信するようになっている。
ユーザは、サービス一覧４０３の中から、特定のサービスＩＤを選択する。この選択は、例えば、ディスプレイへのタッチ操作により実現される。
これにより、第２端末４０は、選択されたサービスＩＤのサービス（サービス内容）を選択することとなる（図７のステップＳ５０５）。
【００５７】
図７のステップＳ５０６において、第２端末４０は、選択したサービスのサービスチケットのＭＡＣ（メッセージ認証符号）を検証する。具体的には、第２端末４０は、当該サービスチケット含まれているハッシュ３０７（図３参照）を検証する。これにより、サービスチケットが改ざんされていないかを調べることが可能となる。
上記検証の結果、サービスチケットが改ざんされていない場合、第２端末４０は、電子媒体１０に対し、当該サービスチケットと共に終了コマンドを送信する（ステップＳ５０７）。終了コマンドは、第２端末４０との通信の終了処理を行うためのコマンドである（終了コマンドの構成例は図３参照）。
【００５８】
ステップＳ５０８において、電子媒体１０の仮想アプリ部１４２が、第２端末４０から、サービスチケットと共に終了コマンドを取得する。そして、仮想アプリ部１４２が、終了コマンドに従い、当該取得したサービスチケットと一致するサービスチケットを第２データエリア１４１から消去する。
ステップＳ５０９において、仮想アプリ部１４２が、終了コマンドに従い、第２端末４０との通信処理を終了する。そして、ステップＳ５１０において、仮想アプリ部１４２が、終了コマンドに従い、共通領域検証部１２０に対し、第２端末４０との通信が終了した旨の通知を行う。
ステップＳ５１１において、共通領域検証部１２２が、仮想アプリ部１４２の選択を解除する。そして、ステップＳ５１２において、選択部１２０が、アプリケーションへのアクセス先をデフォルト（例えば、アプリケーション管理部１３１）に設定する。
【００５９】
なお、ステップＳ５０４の処理後、ユーザが、サービス一覧４０３（図８参照）の中から、特定のサービスＩＤを選択しない場合、例えば、店員が、第２端末４０を操作し、所定の終了操作を行う。そうすると、第２端末４０は、終了コマンドを電子媒体１０に送信し、上記ステップＳ５０９以降の処理が行われることとなる。
【００６０】
［選択部での他の検証例］
次に、選択部１２０での他の検証例（アプリケーションのアクセス先を規定した選択手順例）について図９に基づいて説明する。
実施の形態１では、アプリケーション検証部１２１、共通領域検証部１２２の順にアプリケーションの有無を検証して特定する場合（図２のＳ１０８、Ｓ１１０に相当）について説明したが、図４に示された選択コマンドのＰ１（パラメータ）２０３の値に応じて、選択部１２０での検証が実行されるようにしてもよい。このときの選択コマンドのＰ１（パラメータ）２０３の値（図４参照）と、検証の内容との対応関係を図９に示す。なお、この対応関係は、選択部１２０があらかじめ管理しておく。
【００６１】
図９では、Ｐ１（パラメータ）２０３の値（図４参照）と、検証の内容との対応関係が示されている。この例では、アプリケーション管理部１３０のみ検証する場合、共通領域管理部１４０のみ検証する場合、および、双方の管理部１３０、１４０を検証する場合の３つのパターンが示されている。
例えば、図４に示したＰ１（パラメータ）２０３のｂ３が「１」の場合、アプリケーション検証部１２１が、アプリケーション管理部１３０のみ検証することになる。
また、図４に示したＰ１（パラメータ）２０３のｂ８が「１」の場合、共通領域検証部１２２が、共通領域管理部１４０のみ検証することとなる。このようにすると、共通領域検証部１２２が、第２端末４０からの選択コマンドに示された選択手順に従い、共通領域管理部１４０へのアクセスを選択することができる。
さらに、図４に示したＰ１（パラメータ）２０３のｂ３およびｂ８がともに「１」の場合、まず、アプリケーション検証部１２１が、アプリケーション管理部１３０を検証する。そして、その結果、アプリケーション管理部１３０に、選択コマンドに示されたファイル選択アドレスと一致する識別子を持つアプリケーションが記録されていない場合、共通領域検証部１２２が、共通領域管理部１４０を検証することとなる。
なお、図２に示したように、アプリケーション検証部１２１、共通領域検証部１２２が順に検証する場合、図９の内容に従って図４に示した選択コマンドのＰ１は、「８４」に設定しなければならない。
【００６２】
なお、実施の形態１では、電子媒体１０には第２アプリケーションが記録されないので、第２端末４０は、共通領域管理部１４０のみを検証するように、選択コマンドのＰ１（第１パラメータ）を設定するようにしてもよい。
また、選択コマンドのＰ１はパラメータの場合で説明したが、コードを設定するようにしてもよい。さらに、選択コマンドのＰ１のみの値に応じて上記検証の内容をあらかじめ規定する場合について説明したが、選択コマンドのＰ２の値のみを用いても検証の内容を規定してもよい。あるいは、選択コマンドのＰ１およびＰ２の組み合わせにより検証の内容を規定するようにしてもよい。
【００６３】
以上のように、電子媒体１０は、各端末３０、４０からの要求（選択コマンド）を入出力部１１０を介して受け、アプリケーション管理部１３０または共通領域管理部１４０へのアクセス先を選択する選択部１２０（１２１、１２２を含む）を有する。また、電子媒体１０は、選択部１２０（アプリケーション検証部１２１）の選択により、第１アプリケーションの処理を実行するアプリケーション管理部１３０と、選択部１２０（共通領域検証部１２２）の選択により、第２端末４０との間で通信を行い、第１アプリケーションの処理のためのサービスデータを第２端末４０に提供する共通領域管理部１４０とを含む。このため、第２端末４０からの要求に応じて、共通領域管理部１４０が、上記サービスデータを第２端末４０に送信したり、アプリケーション管理部１３０が第１アプリケーションの処理を実行したりすることとなる。したがって、第２アプリケーションを電子媒体１０に搭載することなく、第１アプリケーションおよび第２アプリケーションの双方の処理を実行することが可能となる。
よって、電子媒体１０の発行スキームに対応させることなく、様々なサービスの提供を行うことができる。例えば、電子媒体１０（搭載のアプリケーション）によるサービスを用いて行っているサービス提供者と一時的に業務提携するサービス提携者であっても、その電子媒体１０にアプリケーションを新たに搭載することなく、電子媒体１０によるサービスを行うことができる。
【００６４】
また、実施の形態１によると、電子媒体１０は、アプリケーション管理部１３０と共通領域管理部１４０とを含むので、第１アプリケーションおよび第２アプリケーションの処理のための各サービスデータが別々に管理される。また、選択部１２０が、それぞれの管理部１３０、１４０へのアクセスをアプリケーション（第１、第２）ごとに行う。このため、第２端末４０は、第１端末３０と電子媒体１０との間の通信プロトコルと同じプロトコルを用いて電子媒体１０にアクセスする必要がない。さらに、このように構成することにより、第２端末４０は、第１端末３０の通信プロトコルとは関係なく、電子媒体１０との間の通信プロトコルに従って、共通鍵等による認証を行うことが可能となる。よって、電子媒体１０によるサービス（ここでは第２アプリケーションのためのもの）を簡易に提供することができる。
【００６５】
（実施の形態２）
実施の形態２は、複数のサービス提供者（クレジット会社など）が１つの電子媒体を共有してサービスを提供する場合であっても、前述した提携者が、実施の形態１の場合と同様に、その電子媒体を用いて、独自のサービスを副次的に行うことが可能になる場合のものである。
図１０は本発明の実施の形態２における電子媒体を含むシステム全体の構成例を示す図である。なお、実施の形態１と同一部分については、実施の形態１と同一の符号（用語を含む）を付し、重複説明を省略する。
実施の形態２では、電子媒体の発行者が、Ａ社のほかにもＢ社とも契約を結んでいるものとする。このため、電子媒体１０Ａには、第１アプリケーションのほかにも、Ｂ社の第２アプリケーションも記録されている点が、実施の形態１の場合と異なる。
図１０に示すように、電子媒体１０Ａは、アプリケーション管理部１３０を有し、この管理部１３０が、第３データエリア１３３および第２アプリケーション１３４をさらに有する。第３データエリア１３３は、第２アプリケーション１３４の処理に必要なデータを格納する。
その他の電子媒体１０Ａを含むシステム全体の構成は、図１の場合と同様である。
【００６６】
次に、電子媒体１０Ａのユーザが、その電子媒体１０Ａを用いて、第２サービスを受ける場合の処理手順の概要について図１１に基づいて説明する。ここでは、４つのステップＳ２０１〜Ｓ２０４を図２に付加した点が、図２の場合と異なるので、この点を中心に説明する。
ステップＳ２０１において、例えば、第２アプリケーション１３４がアプリケーション管理部１３０に管理されていなかった場合、アプリケーション検証部１２１は、当該アプリケーションが存在しないと判断し（ステップＳ２０１のＮｏ）、ステップＳ１１０以降の処理が行われる。
他方、第２アプリケーション１３４がアプリケーション管理部１３０に管理されている場合（第２アプリケーション１３４のダウンロード済み等の場合）、アプリケーション検証部１２１は、当該アプリケーションが存在すると判断し（ステップＳ２０１のＹｅｓ）、ステップＳ２０２に進む。なお、この場合、アプリケーション管理部１３０に管理されている第２アプリケーション１３４には、提携者ＩＤがアプリケーションの識別子として一部割り当てられている。
【００６７】
ステップＳ２０２において、アプリケーション検証部１２１は、例えば、選択コマンドのＰ２（図４参照）の値を確認する。本実施の形態においては、確認されたＰ２に、図１０に示したように、検証の内容を表す値が設定されているものとする。
【００６８】
そして、アプリケーション検証部５１２は、上記選択コマンドのＰ２（図４参照）の値の確認により、例えば、アプリケーション管理部１３０を検証して、第２アプリケーション１３４を選択する（ステップＳ２０３のＹｅｓ）。次に、ステップＳ２０４において、アプリケーション検証部５１２は、上記選択コマンドで示された第２アプリケーション１３４の選択成功を示すステータス情報を含む応答データを第２端末４０に送信する。
その後、第２端末４０と第２アプリケーション１３４との間で、所定のプロトコルに従って通信を行う。
【００６９】
他方、ステップＳ２０２における確認の結果、選択コマンドのＰ２（図４参照）が共通領域管理部１４０の検証を示していた場合、アプリケーション検証部５１２は、第２アプリケーション１３４を選択することなく（ステップＳ２０３のＮｏ）、ステップＳ１１０に進む。これにより、アプリケーション検証部５１２が、共通領域検証部１２２に選択コマンドを渡すこととなり（ステップＳ１１０）、図２の場合と同様、ステップＳ１１１以降の処理が行われる。このようにしても、実施の形態１と同様の効果が得られる。
【００７０】
なお、各実施の形態１、２において、第２サービスは、フードの無料サービスを一例としてあげたが、これに限定されない。例えば、サービスの提携内容によってさまざまな内容としてもよい。
また、電子媒体１０、１０Ａは、ＬＳＩ(Large Scale Integration)で実現するようにしてもよい。さらに、各部１２０、１３０、１４０をそれぞれ１チップ化してもよいし、その一部あるいは全部を１チップ化してもよい。なお、ここではＬＳＩで説明したが、これは、集積度に応じ、ＩＣ(Integrated Circuit)、システムＬＳＩ、スーパＬＳＩ、ウルトラＬＳＩと呼称されることもある。
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路もしくは汎用プロセサで実現してもよい。ＬＳＩ製造後にプログラムすることが可能なＦＰＧＡ(Field Programmable Gate Array)を適用してもよい。あるいは、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを適用してもよい。
更に、半導体技術の進歩あるいは派生する別技術によりＬＳＩに置き換わる集積回路化の技術が開発されれば、当然、その技術を用いて、上記各部１２０、１３０、１４０の集積化を行うようにしてもよい。また、バイオ技術の適応等が可能性としてあり得る。ＬＳＩによる集積化により、電子媒体の小型化をさらに実現することができる。
【産業上の利用可能性】
【００７１】
本発明は、未搭載のアプリケーションの処理のためのサービスデータを搭載し、また、外部端末との通信によりそのサービスデータをその外部端末に送信する。このため、ICカード等の電子媒体を提示することにより享受できるサービスの拡大に貢献する。
【図面の簡単な説明】
【００７２】
【図１】本発明の実施の形態１における電子媒体を含むシステム全体の構成例を示す図である。
【図２】図１の電子媒体による第２サービスを受ける場合の処理手順の概要を示す図である。
【図３】サービスチケットの構成例を示す図である。
【図４】選択コマンド等の構成例を示す図である。
【図５】図２のステップＳ１０２の詳細例を示す図である。
【図６】図２のステップＳ１１５後の処理を示す図である。
【図７】第２端末が電子媒体の仮想アプリ部からサービスチケットを取得する場合の処理例を示す図である。
【図８】図１の第２端末の表示例を示す図である。
【図９】アプリケーションのアクセス先を規定した選択手順例を示す図である。
【図１０】本発明の実施の形態２における電子媒体を含むシステム全体の構成例を示す図である。
【図１１】図１０の電子媒体による第２サービスを受ける場合の処理手順を示す図である。
【図１２】従来におけるICカードの記録情報を示す図である。
【図１３】従来における個別領域と共通領域へアクセス方法を示す図である。
【符号の説明】
【００７３】
１０、１０Ａ    電子媒体
３０    第１端末
４０    第２端末
１１０    入出力部
１２０    アプリケーション選択部
１２１    アプリケーション検証部
１２２    共通領域検証部
１３０    アプリケーション管理部
１４０    共通領域管理部
【図１】
2007249544.tif 000003
【図２】
2007249544.tif 000004
【図３】
2007249544.tif 000005
【図４】
2007249544.tif 000006
【図５】
2007249544.tif 000007
【図６】
2007249544.tif 000008
【図７】
2007249544.tif 000009
【図８】
2007249544.tif 000010
【図９】
2007249544.tif 000011
【図１０】
2007249544.tif 000012
【図１１】
2007249544.tif 000013
【図１２】
2007249544.tif 000014
【図１３】
2007249544.tif 000015