(57)【要約】【課題】ICチップが搭載される電子機器にデータを管理させることをアプリケーションの提供事業者が容易に行うことができるようにする。【解決手段】サービス発行端末１１から送信されたサービス発行コマンドを受信したとき、ICカード２のサービス発行機能２１においてはコマンドパラメータとして送信されてきた識別子に対応するサービスデータ構造を表す情報と処理シーケンスを記述したプログラムがサービス定義データベース２３から取得される。サービス定義データベース２３にはそれぞれのアプリケーションに必要なサービスのデータ構造を表す情報と処理シーケンスを記述したプログラムが格納されている。サービス発行機能２１においては、ICカード内部処理が実行され、所定のアプリケーションの提供を受けるのに用いられるデータを管理するサービスデータ構造がファイルシステム２２に用意される。本発明はICチップを搭載した機器に適用することができる。【選択図】図３
2008033529.tif 000002
【特許請求の範囲】
【請求項１】
コマンドが送信されてくることに応じて処理を行うICチップが搭載される電子機器において、
処理シーケンスを記述したプログラムと、処理シーケンスに従って行われるそれぞれの処理によって読み書きされるデータの構造を表す情報とを、提供事業者によって提供されるアプリケーションに対応付けて記憶する記憶手段と、
外部の端末から送信されてきたコマンドに付加される識別子により識別されるアプリケーションに対応付けて記憶されている前記プログラムとデータの構造を表す前記情報とを前記記憶手段から取得し、取得した前記プログラムに記述される処理シーケンスに従った処理によって読み書きの対象になるデータを、前記記憶手段から取得した前記情報によって表される構造を有するデータとして管理する管理手段と
を備える電子機器。
【請求項２】
所定のアプリケーションの提供をユーザが受けるときに利用されるものとして用意されるリーダライタからコマンドが送信されてくることに応じて、前記記憶手段から取得した前記プログラムに記述される処理シーケンスに従った処理を行い、前記記憶手段から取得した前記情報によって構造が表されるデータの読み書きを制御する制御手段をさらに備える
請求項１に記載の電子機器。
【請求項３】
前記管理手段は、前記記憶手段から取得したそれぞれの前記プログラムに記述される処理シーケンスに対して権限鍵を設定し、
前記制御手段は、前記リーダライタからコマンドが送信されてくることに応じて所定の処理シーケンスに従った処理を行う場合、処理を行う前に、前記所定の処理シーケンスに対して設定されている権限鍵を用いて、前記リーダライタとの間で相互認証を行う
請求項２に記載の電子機器。
【請求項４】
前記管理手段は、読み書きの対象になるデータを構成する、内容の異なるそれぞれのデータに対して権限鍵を設定し、
前記制御手段は、前記リーダライタからコマンドが送信されてくることに応じて所定の処理シーケンスに従った処理を行う場合、処理を行う前に、前記所定の処理シーケンスに従った処理によって読み書きの対象になるデータに対して設定されている権限鍵を用いて、前記リーダライタとの間で相互認証を行う
請求項２に記載の電子機器。
【請求項５】
処理シーケンスを記述したプログラムと、処理シーケンスに従って行われるそれぞれの処理によって読み書きされるデータの構造を表す情報とを、提供事業者によって提供されるアプリケーションに対応付けて記憶する記憶手段を備え、コマンドが送信されてくることに応じて処理を行うICチップが搭載される電子機器の情報処理方法において、
外部の端末から送信されてきたコマンドに付加される識別子により識別されるアプリケーションに対応付けて記憶されている前記プログラムとデータの構造を表す前記情報とを前記記憶手段から取得し、
取得した前記プログラムに記述される処理シーケンスに従った処理によって読み書きの対象になるデータを、前記記憶手段から取得した前記情報によって表される構造を有するデータとして管理する
ステップを含む情報処理方法。
【請求項６】
処理シーケンスを記述したプログラムと、処理シーケンスに従って行われるそれぞれの処理によって読み書きされるデータの構造を表す情報とを、提供事業者によって提供されるアプリケーションに対応付けて記憶する記憶手段とを備え、コマンドが送信されてくることに応じて処理を行うICチップが搭載される電子機器の情報処理を制御するコンピュータに実行させるプログラムにおいて、
外部の端末から送信されてきたコマンドに付加される識別子により識別されるアプリケーションに対応付けて記憶されている前記プログラムとデータの構造を表す前記情報とを前記記憶手段から取得し、
取得した前記プログラムに記述される処理シーケンスに従った処理によって読み書きの対象になるデータを、前記記憶手段から取得した前記情報によって表される構造を有するデータとして管理する
ステップを含むプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子機器、情報処理方法、およびプログラムに関し、特に、ICチップが搭載される電子機器にデータを管理させることをアプリケーションの提供事業者が容易に行うことができるようにした電子機器、情報処理方法、およびプログラムに関する。
【背景技術】
【０００２】
従来のICカードに対するサービスの発行は、例えば、ICカードに埋め込まれたICチップがFeliCa（商標）であり、搭載されるOS(Operating System)がFeliCa OSのようなアプリケーション汎用型OSである場合は、発行側の端末からICカード（ICチップ）に対して複数の発行用コマンドが送信され、それらがICカードにおいて実行されることによって行われる。
【０００３】
ここで、サービスとは、ICカードのファイルシステムにおいて、電子マネーのデータそのものなどの、データの実体を管理する範囲をいう。例えば、Windows（登録商標）でいうファイルがこれに相当する。あるサービスにおいて管理されるデータにアクセスするためには、サービスに対して必要に応じて割り当てられている権限鍵と同じ鍵が、アクセスを行おうとする端末側に用意されている必要がある。
【０００４】
サービスの発行とは、サービスを定義する情報や、電子マネーのデータそのものなどであるユーザデータを記憶するメモリの領域を確保し、それらの情報をメモリに格納することによって、ICカードのファイルシステムに新たなサービスを作成することをいう。
【０００５】
ICカードにおいてサービス発行コマンドが実行されることにより、OSごとに定義された所定のデータ構造の種類、ユーザデータへのアクセス方法、および、アクセスを行う際の認証に用いられる権限鍵を設定することが可能なユーザデータの単位の組み合わせによって１つのデータ構造が表現され、これにより、対応するアプリケーションの実現が可能となる。
【０００６】
アプリケーションとは、事業者（アプリケーション事業者）が提供するサービスのことをいい、プリペイド電子マネーアプリケーション、クレジットアプリケーション、チケットアプリケーションなどがある。ICカードのユーザは、自分のICカードをサービス発行用の端末の所定の位置に設けられるリーダ／ライタにかざすなどして、提供を受けようとするアプリケーションに対応するサービスの発行を受けることにより、その後、サービスの発行を受けたICカードを利用して、アプリケーションの提供を受けることができる。
【０００７】
また、従来、サービスの発行を受けた後のアプリケーションの運用のときに用いられるコマンド（リーダ／ライタからICカードに送信されるコマンド）は、認証用コマンド、読み出し用コマンド、書き込み用コマンドなどの、ICカードが行う処理単位（機能単位）で定義されるようになされている。
【０００８】
従って、あるアプリケーションが、ICカードの認証、ICカードからのデータの読み出し、ICカードに対するデータの書き込みのそれぞれの処理によって実現される場合、アプリケーション事業者は、アプリケーションの提供を受けるときにユーザにより利用される端末からICカードに対して機能単位でコマンドが送信されるように設計、準備する必要があり、ICカードOSは、リーダ／ライタから機能単位で送信されてくるそれぞれのコマンドを解釈し、それぞれのコマンドに応じた処理を行う必要がある。
【０００９】
一方、ICチップに搭載されるOSがMULTOS（商標）やJava（登録商標） Cardなどのプラットフォーム型OSである場合、アプリケーション事業者が用意したサービス発行用のプログラムがICカードにダウンロードされ、それが実行されることによってサービスの発行が行われる。サービス発行用のプログラムにおいては、アプリケーションの実現に必要になるサービスのデータ構造、鍵の管理方法などがアプリケーション事業者により定義されている。
【００１０】
また、このようにしてサービスの発行が行われた後、アプリケーションの運用のためのプログラムがICカードにダウンロードされ、それが実行されることによってアプリケーションが実現されるようになされている。
【００１１】
図１は、アプリケーション汎用型OSが搭載されたICカードを対象にした従来のサービス発行方式について説明する図である。
【００１２】
図１に示されるように、サービスの発行はサービス発行システム１により行われる。サービス発行システム１は例えばアプリケーション事業者が用意するシステムであり、サービス発行端末１１とサービス定義データベース１２から構成される。サービス発行端末１１の筐体の所定の位置にはリーダ／ライタ１１Ａが設けられる。サービス発行システム１は１つの装置から構成されるようにしてもよいし、複数の装置から構成されるようにしてもよい。
【００１３】
ICカード２は、所定のアプリケーションの提供を受けようとするユーザが有する非接触ICカードであり、ICカード２においてはサービス発行機能２１とファイルシステム２２が実現される。サービス発行機能２１は所定のプログラムがICチップにより実行されることによって実現される機能であり、サービス発行端末１１から送信されてきたサービス発行コマンドを解釈し、サービスの発行を行う。ファイルシステム２２はICチップのメモリに格納されるデータを管理するファイルシステムである。サービスの発行を受けるとき、ICカード２はサービス発行端末１１のリーダ／ライタ１１Ａにかざされる。
【００１４】
リーダ／ライタ１１ＡにICカード２がかざされたとき、サービス発行端末１１は、図１に示されるように、プロセスＰ１として、ICカード２に発行するサービス発行コマンドに付加するコマンドパラメータをサービス定義データベース１２に問い合わせる。
【００１５】
サービス発行端末１１からの問い合わせを受けたとき、サービス定義データベース１２は、プロセスＰ２として、発行するサービスの種類に応じたデータ構造やユーザデータへのアクセス方法などを指定するコマンドパラメータを応答する。
【００１６】
サービス定義データベース１２からの応答を受けたとき、サービス発行端末１１は、プロセスＰ３として、サービス定義データベース１２に問い合わせることによって得られた情報をコマンドパラメータとして付加したサービス発行コマンドをICカード２に送信する。サービス発行コマンドとコマンドパラメータの送信はリーダ／ライタ１１Ａを介して行われる。
【００１７】
サービス発行端末１１から送信されてきたサービス発行コマンドとコマンドパラメータを受信したとき、ICカード２のサービス発行機能２１は、サービス発行コマンドを解釈し、プロセスＰ４としてICカード内部処理を実行する。ここでのICカード内部処理により、サービス発行コマンドとともにサービス発行端末１１から送信されてきたコマンドパラメータに基づいてサービス定義情報２２Ａが生成される。サービス発行機能２１は、サービス定義情報２２Ａに従ってファイルシステム２２上にサービスデータ構造をマッピングし、これにより、サービスの発行を行う。
【００１８】
サービスの発行が終了したとき、サービス発行機能２１は、プロセスＰ５として、サービスの発行が終了したことを表す情報をサービス発行端末１１に送信する。
【００１９】
従来のサービスの発行は以上のようにして行われる。所望するサービスデータ構造を定義するサービス定義情報の生成にあたっては、それを、プロセスＰ３とＰ５の１回のやり取りでは実現することができない場合がある。その場合、プロセスＰ３とＰ５のやりとりが複数回繰り返される。
【００２０】
図２は、アプリケーション運用時にリーダ／ライタとICカード２の間で決済シーケンスに従って行われる従来の処理について説明するフローチャートである。アプリケーション運用時にリーダ／ライタとICカード２の間で行われる処理を規定する処理シーケンスとして、決済シーケンスの他に、電子マネーの残高を増やすチャージシーケンス、PIN(Personal Identification Number)による認証を行うPINシーケンスなどがある。
【００２１】
図２の処理は、図１に示されるようにしてサービスの発行を受けたICカード２が、アプリケーションの提供を受けるときにユーザにより利用されるものとして用意される端末のリーダ／ライタにかざされたときに行われる。
【００２２】
ステップＳ１において、リーダ／ライタは、Pollingコマンドを送信することによって、通信相手となるICカード２の探索、捕捉を行う。
【００２３】
ステップＳ２１において、ICカード２は、リーダ／ライタから送信されてきたPollingコマンドを受信し、ステップＳ２２に進み、それに応答する。
【００２４】
ICカード２からの応答が送信されてきたとき、ステップＳ２において、リーダ／ライタはそれを受信し、ステップＳ３に進み、相互認証コマンドを送信することによってICカード２との間で相互認証を行う。
【００２５】
ステップＳ２３において、ICカード２は、リーダ／ライタから送信されてきた相互認証コマンドを受信し、ステップＳ２４に進み、相互認証に用いる所定の情報をメモリから読み出し、読み出した情報をリーダ／ライタに送信する。
【００２６】
相互認証に用いる情報がICカード２から送信されてきたとき、ステップＳ４において、リーダ／ライタはそれを受信する。
【００２７】
ステップＳ５において、リーダ／ライタは、決済しようとする金額が決済実行条件を満たしているか否かを確認し、決済実行条件を満たしていることを確認した場合、ステップＳ６に進む。例えば、決済額の上限が決済実行条件として設定されていることもあり、この場合、上限の金額より少ない金額の決済だけが可能とされる。
【００２８】
ステップＳ６において、リーダ／ライタは、現在時刻がサービスの有効期限内であるか否かを確認するために、サービス有効期限を表す情報の格納位置を表す識別子をコマンドパラメータとして付加したReadコマンド（読み出し用コマンド）をICカード２に送信する。
【００２９】
ICカード２に発行されたサービスには有効期限を設定することができるようになされており、サービス定義情報により定義されるサービスデータ構造の一部の情報により、サービスの有効期限が表される。サービスデータ構造を構成するそれぞれの情報がメモリのどの位置に格納されるのかはサービスの発行時にサービス定義情報により定義されており、読み出しの対象となるそれぞれの情報の格納位置が、Readコマンドのコマンドパラメータとしてリーダ／ライタから送信されてくる識別子により特定される。
【００３０】
ステップＳ２５において、ICカード２は、リーダ／ライタから送信されてきたReadコマンドを受信し、Readコマンドのコマンドパラメータとして送信されてきた識別子により特定される格納位置から、サービスの有効期限を表す情報を読み出す。ICカード２は、ステップＳ２６に進み、読み出したサービスの有効期限を表す情報をリーダ／ライタに送信する。
【００３１】
有効期限を表す情報がICカード２から送信されてきたとき、ステップＳ７において、リーダ／ライタはそれを受信する。
【００３２】
ステップＳ８において、リーダ／ライタは、現在時刻が、サービス有効期限内の時刻であるか否かをICカード２から送信されてきた情報に基づいて確認し、有効期限内であることを確認した場合、ステップＳ９に進む。
【００３３】
ステップＳ９において、リーダ／ライタは、ICカード２に記憶されている電子マネーの残高を確認するために、残高を表す情報の格納位置を表す識別子をコマンドパラメータとして付加したReadコマンドをICカード２に送信する。
【００３４】
ステップＳ２７において、ICカード２は、リーダ／ライタから送信されてきたReadコマンドを受信し、Readコマンドのコマンドパラメータとして送信されてきた識別子により特定される格納位置から、電子マネーの残高を表す情報を読み出す。ICカード２は、ステップＳ２８に進み、読み出した残高を表す情報をリーダ／ライタに送信する。
【００３５】
電子マネーの残高を表す情報がICカード２から送信されてきたとき、ステップＳ１０において、リーダ／ライタはそれを受信する。
【００３６】
ステップＳ１１において、リーダ／ライタは、ICカード２に記憶されている電子マネーの残高が決済額以上の額であるか否かを確認し、決済額以上の額であることを確認した場合、ステップＳ１２に進む。
【００３７】
ステップＳ１２において、リーダ／ライタは、決済額と、残高の格納位置を表す識別子とをコマンドパラメータとして付加したWriteコマンド（書き込み用コマンド）をICカード２に送信する。
【００３８】
ステップＳ２９において、ICカード２は、リーダ／ライタから送信されてきたWriteコマンドを受信し、ステップＳ３０に進み、決済処理を行う。決済処理においては、Writeコマンドのコマンドパラメータとして送信されてきた識別子により格納位置が特定される電子マネーの現在の残高が、残高から決済額を差し引いた額によって上書きされる。
【００３９】
残高の上書きが成功したとき、ICカード２は、ステップＳ３１において、決済処理が成功したことを表す情報である成功レスポンスをリーダ／ライタに送信する。
【００４０】
成功レスポンスがICカード２から送信されてきたとき、ステップＳ１３において、リーダ／ライタはそれを受信する。
【００４１】
ステップＳ１４において、リーダ／ライタは、アクセスログの値と、アクセスログの格納位置を表す識別子とをコマンドパラメータとして付加したWriteコマンドをICカード２に送信する。
【００４２】
ステップＳ３２において、ICカード２は、リーダ／ライタから送信されてきたWriteコマンドを受信し、ステップＳ３３に進み、アクセスログの書き出し処理を行う。アクセスログの書き出し処理においては、Writeコマンドのコマンドパラメータとして送信されてきた識別子により特定される格納位置に、アクセスログの値が書き込まれる。
【００４３】
アクセスログの値の書き込みが成功したとき、ICカード２は、ステップＳ３４において、アクセスログの書き出し処理が成功したことを表す情報である成功レスポンスをリーダ／ライタに送信する。
【００４４】
成功レスポンスがICカード２から送信されてきたとき、ステップＳ１５において、リーダ／ライタはそれを受信し、これにより、決済シーケンスに従った一連の処理が終了される。
【００４５】
図１を参照して説明したように、サービスの発行は複数のコマンドを用いて行われることがある。また、図２を参照して説明したように、アプリケーションを実現するための１つの処理シーケンスに従った処理は、ICカードの機能単位に定義された複数のコマンドを用いて行われる。
【００４６】
特許文献１には、複数のカードアプリケーション間の連携処理の処理内容と連携処理の実行条件が記述された連携クーポンに基づいて、カードアプリケーション間の連携処理を行う技術が開示されている。特許文献２には、モバイル端末と非接触ICカードを組み合わせた電子鍵システムが開示されている。
【特許文献１】特開２００５−３１６９９２号公報
【特許文献２】特開２００５−２８５０５６号公報
【発明の開示】
【発明が解決しようとする課題】
【００４７】
以上のように、従来のICカードを対象にしてアプリケーションを運用するためには、それぞれのアプリケーション事業者が、サービスの発行時のファイルシステムへのユーザデータの格納方法（データ構造）、および、運用時にユーザデータにアクセスするための処理シーケンスを考案し、運用システムの設計を行う必要がある。
【００４８】
具体的には、ファイルシステムのどの位置に格納される情報がサービスの有効期限を表す情報であり、どの位置に格納される情報が電子マネーの残高を表す情報であるといったように、アプリケーション事業者毎に、サービスのデータ構造を定義する必要がある。また、１回の決済を実現するために、どのタイミングでサービスの有効期限の確認を行い、どのタイミングで残高の確認を行うといったように、アプリケーション事業者毎に、一連の決済の流れを設計する必要がある。
【００４９】
従って、それぞれのアプリケーション事業者が独自に定義したサービスデータ構造に従ってユーザデータが管理されていることから、あるアプリケーション事業者が定義したサービスデータ構造によれば安定したシステムを提供することができるが、他のアプリケーション事業者が定義したサービスデータ構造によれば安定したシステムを提供することができないといったように、複数のアプリケーション事業者を通じて、一貫したセキュリティの確保やシステムの品質の確保が困難であった。
【００５０】
また、図２を参照して説明したような決済シーケンスにおいては、残高をICカードから一度読み出し、その残高が、減額しようとする決済額以上であることをリーダ／ライタ側で判定した後に、減額用のWriteコマンドを送信するといった運用がなされており、リーダ／ライタからICカードに対して複数のコマンドを発行する必要があった。
【００５１】
また、従来のFeliCa OSのコマンドによるICカードからのデータの読み出しでは、１回の読み出しによって読み出すことのできるデータが固定長のデータとされていることから、例えば残高を表す情報が、その固定長よりデータ量の少ない情報である場合、残高を表す情報のみを読み出すことができず、残高を表す情報が含まれるデータブロックと同じデータブロックに含まれる不要な情報（キャッシュバック用データやトランザクション管理用の実行IDなど）も同時に読み出されてしまう。
【００５２】
特に、ICカードとリーダ／ライタ間の通信は無線であり、有線の通信と較べて伝送の不安定性や拡散性（漏洩性）があるため、データの伝送回数は極力減らし、必要最小限のデータのみを伝送したいという要求がある。
【００５３】
従来のFeliCa OSにおいては、権限鍵についても、固定長のデータブロックに対してそれを割り当て、アクセス権限を設定することはできたが、残高を表す情報だけ、あるいは有効期限を表す情報だけといったように、処理シーケンスによって規定されるそれぞれの処理で用いられる情報単位で分けてアクセス権限を設定することができなかった。また、ある１つのデータに対して、例えば、それを増額する権限と減額する権限といった形で、利用形態で分けてアクセス権限を設定することができなかった。
【００５４】
本発明はこのような状況に鑑みてなされたものであり、ICチップが搭載される電子機器にデータを管理させることをアプリケーションの提供事業者が容易に行うことができるようにするものである。
【課題を解決するための手段】
【００５５】
本発明の一側面の電子機器は、コマンドが送信されてくることに応じて処理を行うICチップが搭載される電子機器において、処理シーケンスを記述したプログラムと、処理シーケンスに従って行われるそれぞれの処理によって読み書きされるデータの構造を表す情報とを、提供事業者によって提供されるアプリケーションに対応付けて記憶する記憶手段と、外部の端末から送信されてきたコマンドに付加される識別子により識別されるアプリケーションに対応付けて記憶されている前記プログラムとデータの構造を表す前記情報とを前記記憶手段から取得し、取得した前記プログラムに記述される処理シーケンスに従った処理によって読み書きの対象になるデータを、前記記憶手段から取得した前記情報によって表される構造を有するデータとして管理する管理手段とを備える。
【００５６】
所定のアプリケーションの提供をユーザが受けるときに利用されるものとして用意されるリーダライタからコマンドが送信されてくることに応じて、前記記憶手段から取得した前記プログラムに記述される処理シーケンスに従った処理を行い、前記記憶手段から取得した前記情報によって構造が表されるデータの読み書きを制御する制御手段をさらに設けることができる。
【００５７】
前記管理手段には、前記記憶手段から取得したそれぞれの前記プログラムに記述される処理シーケンスに対して権限鍵を設定させ、前記制御手段には、前記リーダライタからコマンドが送信されてくることに応じて所定の処理シーケンスに従った処理を行う場合、処理を行う前に、前記所定の処理シーケンスに対して設定されている権限鍵を用いて、前記リーダライタとの間で相互認証を行わせることができる。
【００５８】
前記管理手段には、読み書きの対象になるデータを構成する、内容の異なるそれぞれのデータに対して権限鍵を設定させ、前記制御手段には、前記リーダライタからコマンドが送信されてくることに応じて所定の処理シーケンスに従った処理を行う場合、処理を行う前に、前記所定の処理シーケンスに従った処理によって読み書きの対象になるデータに対して設定されている権限鍵を用いて、前記リーダライタとの間で相互認証を行わせることができる。
【００５９】
本発明の一側面の情報処理方法またはプログラムは、外部の端末から送信されてきたコマンドに付加される識別子により識別されるアプリケーションに対応付けて記憶されているプログラムとデータの構造を表す情報とを記憶手段から取得し、取得した前記プログラムに記述される処理シーケンスに従った処理によって読み書きの対象になるデータを、前記記憶手段から取得した前記情報によって表される構造を有するデータとして管理するステップを含む。
【００６０】
本発明の一側面においては、外部の端末から送信されてきたコマンドに付加される識別子により識別されるアプリケーションに対応付けて記憶されているプログラムとデータの構造を表す情報とが記憶手段から取得され、取得された前記プログラムに記述される処理シーケンスに従った処理によって読み書きの対象になるデータが、前記記憶手段から取得された前記情報によって表される構造を有するデータとして管理される。
【発明の効果】
【００６１】
本発明の一側面によれば、ICチップが搭載される電子機器にデータを管理させることをアプリケーションの提供事業者は容易に行うことができる。
【発明を実施するための最良の形態】
【００６２】
以下に本発明の実施の形態を説明するが、本発明の構成要件と、明細書又は図面に記載の実施の形態との対応関係を例示すると、次のようになる。この記載は、本発明をサポートする実施の形態が、明細書又は図面に記載されていることを確認するためのものである。従って、明細書又は図面中には記載されているが、本発明の構成要件に対応する実施の形態として、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その構成要件に対応するものではないことを意味するものではない。逆に、実施の形態が発明に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その構成要件以外には対応しないものであることを意味するものでもない。
【００６３】
本発明の一側面の電子機器（例えば、図３のICカード２）は、コマンドが送信されてくることに応じて処理を行うICチップが搭載される電子機器において、処理シーケンスを記述したプログラムと、処理シーケンスに従って行われるそれぞれの処理によって読み書きされるデータの構造を表す情報とを、提供事業者によって提供されるアプリケーションに対応付けて記憶する記憶手段（例えば、図３のサービス定義データベース２３）と、外部の端末から送信されてきたコマンドに付加される識別子により識別されるアプリケーションに対応付けて記憶されている前記プログラムとデータの構造を表す前記情報とを前記記憶手段から取得し、取得した前記プログラムに記述される処理シーケンスに従った処理によって読み書きの対象になるデータを、前記記憶手段から取得した前記情報によって表される構造を有するデータとして管理する管理手段（例えば、図３のサービス発行機能２１）とを備える。
【００６４】
この電子機器には、所定のアプリケーションの提供をユーザが受けるときに利用されるものとして用意されるリーダライタからコマンドが送信されてくることに応じて、前記記憶手段から取得した前記プログラムに記述される処理シーケンスに従った処理を行い、前記記憶手段から取得した前記情報によって構造が表されるデータの読み書きを制御する制御手段（例えば、図７のプリペイド電子マネーオブジェクト５１）をさらに設けることができる。
【００６５】
本発明の一側面の情報処理方法またはプログラムは、外部の端末から送信されてきたコマンドに付加される識別子により識別されるアプリケーションに対応付けて記憶されているプログラムとデータの構造を表す情報とを記憶手段から取得し、取得したプログラムに記述される処理シーケンスに従った処理によって読み書きの対象になるデータを、前記記憶手段から取得した前記情報によって表される構造を有するデータとして管理するステップ（例えば、図５のステップＳ５４）を含む。
【００６６】
以下、本発明の実施の形態について図を参照して説明する。
【００６７】
図３は、本発明の一実施形態に係る情報処理システムにおけるサービスの発行方式について説明する図である。図１と同じ構成には同じ符号を付してある。
【００６８】
図３に示されるように、サービスの発行はサービス発行システム１によって行われる。サービス発行システム１はアプリケーション事業者が用意するシステムであり、サービス発行端末１１から構成される。サービス発行端末１１の筐体の所定の位置にはリーダ／ライタ１１Ａが設けられる。サービス発行システム１は１つの装置から構成されるようにしてもよいし、複数の装置から構成されるようにしてもよい。
【００６９】
ICカード２は、所定のアプリケーションの提供を受けようとするユーザが有する非接触ICカードであり、ICカード２においてはサービス発行機能２１とファイルシステム２２が実現される他に、サービス定義データベース２３が用意される。すなわち、図１の例においてはサービス発行システム１側の構成として設けられていたサービス定義データベースが、図３の例においてはICカード２側の構成として内包する形で設けられている。
【００７０】
サービス発行機能２１はICカード２に埋め込まれているICチップにより所定のプログラムが実行されることによって実現される機能であり、サービス発行端末１１から送信されてきたサービス発行コマンドを解釈し、サービスの発行を行う。ファイルシステム２２はICチップのメモリに格納されるデータを管理するファイルシステムである。サービスの発行を受けるとき、ICカード２はサービス発行端末１１のリーダ／ライタ１１Ａにかざされる。
【００７１】
リーダ／ライタ１１ＡにICカード２がかざされたとき、サービス発行端末１１は、図３に示されるように、プロセスＰ１１として、ICカード２の内部に実装されるサービス発行機能２１に対してサービス発行コマンドを送信する。サービス発行端末１１から送信されるサービス発行コマンドには、プリペイド電子マネーアプリケーション、チケットアプリケーションなどの、ICカード２のユーザが提供を受けようとするアプリケーションの種類を表す識別子がコマンドパラメータとして付加される。
【００７２】
サービス発行端末１１から送信されてきたサービス発行コマンドとコマンドパラメータを受信したとき、ICカード２のサービス発行機能２１は、サービス発行コマンドを解釈し、コマンドパラメータとして送信されてきた識別子に対応する、サービスデータ構造を表す情報と処理シーケンスを記述したプログラムを、サービス定義データベース２３にプロセスＰ１２として問い合わせる。サービス定義データベース２３には、アプリケーションの識別子に対応させた形で、それぞれのアプリケーションに必要になるサービスのデータ構造を表す情報と処理シーケンスを記述したプログラムが格納されている。
【００７３】
例えば、サービス定義データベース２３には、アプリケーションの契約番号であるサービスID、アプリケーションの提供を受けることが可能な期間、区間、場所、回数などによる制約条件、プリペイド電子マネーアプリケーションで用いられる電子マネーの残高などのサービスバリュー、権利を行使する際の条件である決済実行条件、アクセスログなどの区分によって意味づけされたサービスデータ構造を表す情報が格納されている。
【００７４】
また、サービス定義データベース２３には、処理シーケンスを記述したプログラムとして、サービス利用シーケンス、チャージシーケンス、決済単位書き込みシーケンス、決済シーケンス、決済制約確認シーケンス、決済単位確認シーケンス、残高確認シーケンス、履歴照会シーケンス、PINシーケンス、設定値変更シーケンスなどのそれぞれの処理シーケンスを記述したプログラムが格納される。それぞれのプログラムが実行されることにより、その目的にあわせて、１つまたは複数のデータの読み出し、データの書き込み、データを用いた演算、データの比較、処理履歴の記憶、処理の正当性の確認、電子署名の書き出しなどを組み合わせた一連の処理がICカード２において実現される。
【００７５】
サービス発行機能２１からの問い合わせを受けたとき、サービス定義データベース２３は、プロセスＰ１３として、問い合わせのあったサービスデータ構造を表す情報と処理シーケンスを記述したプログラムをサービス発行機能２１に応答する。
【００７６】
サービス定義データベース２３からの応答を受けたとき、サービス発行機能２１は、プロセスＰ１４としてICカード内部処理を実行する。ここでのICカード内部処理により、サービス定義データベース２３から送信されてきたサービスデータ構造を表す情報と処理シーケンスを記述したプログラムに基づいてサービス定義情報２２Ａが生成される。サービス発行機能２１は、サービス定義情報２２Ａに従ってファイルシステム２２上にサービスデータ構造をマッピングし、これにより、サービスの発行を行う。
【００７７】
サービスの発行が終了したとき、サービス発行機能２１は、プロセスＰ１５として、サービスの発行が終了したことを表す情報をサービス発行端末１１に送信する。サービスの発行は以上のようにして行われる。
【００７８】
図４は、サービス定義データベース２３に記憶される、アプリケーション毎のデータ構造を表す情報の例を示す図である。
【００７９】
図４の例においては、横方向にアプリケーションの種類が示され、縦方向にサービス定義項目が示されている。アプリケーションの種類が決まると、それぞれのサービス定義項目の有無と、サービス定義項目が「あり」の場合は、具体的にどのような定義となるかが定まる。「選択可」とされているものは、そのサービス定義項目の有無（サービス定義項目を用いた機能の有無）をアプリケーション事業者が任意に選択できることを示している。
【００８０】
例えば、図４に示されるプリペイド電子マネーアプリケーションについては、サービス定義項目である「サービスバリュー」は「残高」、「サービスバリューの制約」は「０以上上限値」、「決済シーケンス」は「減算」、「決済実行条件」は「上限」、「チャージシーケンス」は「あり」、「決済単位書き込みシーケンス」は「なし」、「格納可能な決済単位数」は「１」、「期間制約」は「対サービスデータ構造」、「処理履歴記録」は「あり」、「PINシーケンス」は「選択可」とされている。
【００８１】
「サービスバリュー」が「残高」であることは、プリペイド電子マネーアプリケーションに必要なサービスデータ構造全体のうちの「サービスバリュー」に割り当てられた格納位置には電子マネーの残高を表す情報が格納されることを表し、「サービスバリューの制約」が「０以上上限値」であることは、サービスデータ構造全体のうちの「サービスバリューの制約」に割り当てられた格納位置には０以上の、残高として記録可能な金額の上限を表す情報が格納されることを表す。このような、どの格納位置にどの情報が格納されるのかを表す情報が組み合わされることによって、プリペイド電子マネーアプリケーションに必要な１つのサービスデータ構造が定義される。
【００８２】
「決済シーケンス」が「減算」であることは、プリペイド電子マネーアプリケーションの決済シーケンスにおいては残高の減算が行われることを表し、「決済実行条件」が「上限」であることは、サービスデータ構造全体のうちの「決済実行条件」に割り当てられた格納位置には１回の決済シーケンスで決済可能な金額の上限を表す情報が格納されることを表す。
【００８３】
「チャージシーケンス」が「あり」であることは、プリペイド電子マネーアプリケーションを実現する処理シーケンスにチャージシーケンスが含まれることを表し、「決済単位書き込みシーケンス」が「なし」であることは、プリペイド電子マネーアプリケーションを実現する処理シーケンスに決済単位書き込みシーケンスが含まれないことを表す。
【００８４】
「格納可能な決済単位数」が「１」であることは、プリペイド電子マネーアプリケーションを実現する決済シーケンスにおいては１つの単位の決済（残高の減額）を行うことができることを表し、「期間制約」が「対サービスデータ構造」であることは、サービスデータ構造全体のうちの「期間制約」に割り当てられた格納位置にはサービスデータ構造の有効期限を表す情報が格納されることを表す。
【００８５】
「処理履歴記録」が「あり」であることは、プリペイド電子マネーアプリケーションを実現する、ある処理シーケンスに従って処理が行われた後に処理の履歴（アクセスログ）を記録することを表し、「PINシーケンス」が「選択可」であることは、プリペイド電子マネーアプリケーションを実現する処理シーケンスに、PINによる認証であるPINシーケンスを含めることをアプリケーション事業者が選択することができることを表す。
【００８６】
プリペイド電子マネーアプリケーションの識別子が送信されてくることによってサービス発行機能２１から問い合わせが行われたとき、サービス定義データベース２３においては、サービス定義項目が「あり」として設定されているチャージシーケンスを記述したプログラム、PINシーケンスを記述したプログラムなどが読み出され、サービス発行機能２１に対して提供される。
【００８７】
また、「サービスバリュー」が「残高」であること、「サービスバリューの制約」が「０以上上限値」であること、「決済実行条件」が「上限」であることなどの、それぞれの格納位置に格納される情報の内容を表す情報がサービスデータ構造を表す情報として提供される。
【００８８】
同様に、図４に示されるチケットアプリケーションについては、サービス定義項目である「サービスバリュー」は「枚数」、「サービスバリューの制約」は「０以上上限値」、「決済シーケンス」は「減算」、「決済実行条件」は「上限／下限／単位」、「チャージシーケンス」は「なし」、「決済単位書き込みシーケンス」は「あり」、「格納可能な決済単位数」は「複数」、「期間制約」は「対決済単位」、「処理履歴記録」は「あり」、「PINシーケンス」は「選択可」とされている。
【００８９】
「サービスバリュー」が「枚数」であることは、チケットアプリケーションのサービスデータ構造全体のうちの「サービスバリュー」に割り当てられた格納位置には電子的なチケットの残り枚数を表す情報が格納されることを表し、「サービスバリューの制約」が「０以上上限値」であることは、サービスデータ構造全体のうちの「サービスバリューの制約」に割り当てられた格納位置には０以上の、残り枚数として記録可能な電子的なチケットの枚数の上限を表す情報が書き込まれることを表す。このような、どの格納位置にどの情報が格納されるのかを表す情報が組み合わされることによって、チケットアプリケーションに必要な１つのサービスデータ構造が定義される。
【００９０】
「決済シーケンス」が「減算」であることは、チケットアプリケーションの決済シーケンスにおいては電子的なチケットの残り枚数の減算が行われることを表し、「決済実行条件」が「上限／下限／単位」であることは、サービスデータ構造全体のうちの「決済実行条件」に割り当てられた格納位置には１回の決済シーケンスで決済可能なチケットの上限／下限／単位のいずれかを表す情報が書き込まれることを表す。
【００９１】
「チャージシーケンス」が「なし」であることは、チケットアプリケーションを実現する処理シーケンスにチャージシーケンスが含まれないことを表し、「決済単位書き込みシーケンス」が「あり」であることは、チケットアプリケーションを実現する処理シーケンスに決済単位書き込みシーケンスが含まれ、後述する決済単位が複数ある場合に、それぞれの決済単位を対象として決済シーケンス（チケットの残り枚数の減算）を行うことができることを表す。
【００９２】
「格納可能な決済単位数」が「複数」であることは、チケットアプリケーションに必要な１つのサービスデータ構造に複数の決済単位を格納させることができることを表し、「期間制約」が「対決済単位」であることは、サービスデータ構造全体のうちの「期間制約」に割り当てられた格納位置には決済単位の有効期限を表す情報が書き込まれることを表す。
【００９３】
「処理履歴記録」が「あり」であることは、チケットアプリケーションを実現する、ある処理シーケンスに従って処理が行われた後に処理の履歴を記録することを表し、「PINシーケンス」が「選択可」であることは、チケットアプリケーションを実現する処理シーケンスにPINシーケンスを含めることをアプリケーション事業者が選択することができることを表す。
【００９４】
チャージアプリケーションの識別子が送信されてくることによってサービス発行機能２１から問い合わせが行われたとき、サービス定義データベース２３においては、決済単位書き込みシーケンスを記述したプログラム、PINシーケンスを記述したプログラムなどが読み出され、サービス発行機能２１に対して提供される。
【００９５】
また、「サービスバリュー」が「枚数」であること、「サービスバリューの制約」が「０以上上限値」であること、「決済実行条件」が「上限／下限／単位」であることなどの、それぞれの格納位置に格納される情報の内容を表す情報がサービスデータ構造を表す情報として提供される。
【００９６】
他のアプリケーションの識別子がサービス発行機能２１から送信されてきたときも同様に、図４に示されるサービス定義項目の設定が「あり」として設定されている処理シーケンスを記述したプログラム、サービスデータ構造を表す情報がサービス定義データベース２３から読み出され、サービス発行機能２１に提供される。
【００９７】
このように、図３の情報処理システムにおいては、サービス発行システム１から送信されてきた識別子により特定されるアプリケーションに必要な情報がサービス定義データベース２３から読み出され、サービスの発行がICカード２内で行われるようになされている。
【００９８】
サービスの発行に必要になる情報が格納されたサービス定義データベース２３がICカード２に用意されているから、アプリケーションに必要な情報をICカード２に書き込むことによってサービスを発行（活性化）する際に、サービスの発行に必要になる情報をサービス発行システム１側からICカード２側に送信する必要がなく、サービスの発行に際してサービス発行システム１とICカード２間で送受信されるデータを最小限の量のデータに抑えることができ、データの送受信の回数を減らすこともできる。
【００９９】
また、サービスの発行に際してサービス発行システム１側からICカード２側に送信される情報はアプリケーションの識別子がコマンドパラメータとして付加されたサービス発行コマンドだけであるから、処理シーケンスを記述したどのプログラムを送信するのか、あるいは、サービスデータ構造を表すどの情報を送信するのかといったことを、アプリケーション事業者が独自に設計し、サービス発行システム１に準備する必要がなく、それらにかかるコストを削減することができる。
【０１００】
ここで、図５のフローチャートを参照して、サービス発行時にリーダ／ライタ１１ＡとICカード２の間で行われる処理について説明する。
【０１０１】
リーダ／ライタ１１ＡにICカード２がかざされたとき、ステップＳ４１において、リーダ／ライタ１１Ａは、アプリケーションの種類を表す識別子をコマンドパラメータとして付加したサービス発行コマンドをICカード２に送信する。
【０１０２】
ステップＳ５１において、ICカード２のサービス発行機能２１は、リーダ／ライタ１１Ａから送信されてきたサービス発行コマンドを受信し、ステップＳ５２に進む。
【０１０３】
ステップＳ５２において、サービス発行機能２１はサービス発行コマンドを解釈することによって、コマンドパラメータとして送信されてきた識別子に対応する、サービスデータ構造を表す情報と処理シーケンスを記述したプログラムをサービス定義データベース２３に問い合わせる。
【０１０４】
ステップＳ５３において、サービス定義データベース２３は、サービス発行機能２１からの問い合わせに対する応答として、問い合わせのあったサービスデータ構造を表す情報と処理シーケンスを記述したプログラムをサービス発行機能２１に送信する。
【０１０５】
ステップＳ５４において、サービス発行機能２１は、サービス定義データベース２３から送信されてきたサービスデータ構造を表す情報と処理シーケンスを記述したプログラムに基づいてサービス定義情報２２Ａを生成し、生成したサービス定義情報２２Ａに従ってサービスデータ構造をファイルシステム２２にマッピングすることによってサービスの発行を行う。
【０１０６】
ステップＳ５５において、サービス発行機能２１は、サービスの発行が終了したことを表す情報をリーダ／ライタ１１Ａに送信する。
【０１０７】
サービス発行機能２１から送信された情報は、ステップＳ４２においてリーダ／ライタ１１Ａにより受信され、処理が終了される。
【０１０８】
図６は、ICカード２のファイルシステム２２にマッピングされたサービスデータ構造の例を示す図である。
【０１０９】
図５に示されるような処理が繰り返されることによって、ICカード２のファイルシステム２２には、複数のアプリケーションの提供を受けるのに必要なサービスデータ構造がそれぞれマッピングされる。図６の例においては、サービスデータ構造３１乃至３３の３つのサービスデータ構造が示されている。
【０１１０】
図６のサービスデータ構造３１はプリペイド電子マネー（ストアードバリュー型電子マネー）アプリケーションの提供を受けるのに必要なサービスデータ構造であり、サービスデータ構造３２はチケットアプリケーションの提供を受けるのに必要なサービスデータ構造である。サービスデータ構造３３は所定のアプリケーションの提供を受けるのに必要なサービスデータ構造である。サービスデータ構造３１乃至３３のそれぞれには、識別子としてのサービスIDが設定されている。
【０１１１】
また、図６の例においては、サービスデータ構造３１には権限鍵Ｋ1が設定され、サービスデータ構造３２には権限鍵Ｋ2が設定されている。また、サービスデータ構造３３には権限鍵Ｋ3が設定されている。従って、例えば、プリペイド電子マネーアプリケーションの運用に用いられるリーダ／ライタ（リーダ／ライタが設けられた端末）には権限鍵Ｋ1に対応する鍵が用意されている必要があり、チケットアプリケーションの運用に用いられるリーダ／ライタには権限鍵Ｋ2に対応する鍵が用意されている必要がある。
【０１１２】
プリペイド電子マネーアプリケーションの提供を受けようとしてユーザがリーダ／ライタにICカード２をかざしたとき、リーダ／ライタにおいては権限鍵Ｋ2に対応する鍵が用いられ、ICカード２においては権限鍵Ｋ2が用いられて、いわゆるチャレンジアンドレスポンスによる相互認証がリーダ／ライタとICカード２の間で行われる。相互認証が成功したとき、サービスデータ構造３１により管理されるデータへのアクセス（データの読み出し、書き込み）が可能とされる。
【０１１３】
このように、ICカード２においては、サービスデータ構造毎に権限鍵を設定することができる。なお、図６の例においては、３種類のサービスデータ構造を示しているがその数は任意である。また、権限鍵の設定の有無についても任意である。
【０１１４】
次に、以上のようにしてサービスが発行されたICカード２を対象にしたアプリケーションの運用について説明する。
【０１１５】
図７は、アプリケーション運用時の基本的なシステム構成となるICカード２とリーダ／ライタ４１を示す図である。
【０１１６】
図７の例においては、ICカード２にはプリペイド電子マネーオブジェクト５１、チケットオブジェクト５２、およびサービスオブジェクト５３が実装されている。プリペイド電子マネーオブジェクト５１は、プリペイド電子マネーアプリケーションの発行時にサービス定義データベース２３から読み出され、取得されたプログラムに記述された処理シーケンスによって規定される処理と、サービスデータ構造３１により管理されるデータの読み書きを制御し、チケットオブジェクト５２は、チケットアプリケーションの発行時にサービス定義データベース２３から読み出され、取得されたプログラムに記述された処理シーケンスによって規定される処理と、サービスデータ構造３２により管理されるデータの読み書きを制御する。サービスオブジェクト５３は、所定のアプリケーションの発行時にサービス定義データベース２３から読み出され、取得されたプログラムに記述された処理シーケンスによって規定される処理と、サービスデータ構造３３により管理されるデータの読み書きを制御する。
【０１１７】
プリペイド電子マネーオブジェクト５１、チケットオブジェクト５２、およびサービスオブジェクト５３のそれぞれは、リーダ／ライタ４１から送信されてきたコマンドを解釈し、所定の処理シーケンスに従って処理を行う。
【０１１８】
リーダ／ライタ４１は、例えば、プリペイド電子マネーアプリケーションの運用に用いられる端末に設けられる。リーダ／ライタ４１は、ICカード２がかざされたとき、ICカード２に対して所定のコマンドを発行し、プリペイド電子マネーアプリケーションの各種の機能をICカード２において実現させる。プリペイド電子マネーアプリケーションの機能としては、例えば、電子マネーのチャージ、ICカード２に記憶されている電子マネーを使った決済、ICカード２に記憶されている電子マネーの残高の確認、ICカード２に記憶されている電子マネーを使った決済の履歴の確認、PINを用いたユーザ認証、ICカード２に記憶されている各種の値の変更などがある。
【０１１９】
このような各種の機能は、例えば図２を参照して説明したように複数回のコマンドのやりとりによって実現されるのではなく、１回のコマンドのやりとりで実現されるようになされている。
【０１２０】
例えば、ICカード２に記憶されている電子マネーを使った決済を行う場合、決済コマンドがリーダ／ライタ４１から送信され、それに応じて、プリペイド電子マネーオブジェクト５１により決済シーケンスに従って処理が行われることによって、電子マネーを使った決済がICカード２において実現される。プリペイド電子マネーアプリケーションに必要なサービスの発行時、ICカード２においては、決済実行条件の確認、サービス有効期限の確認、残高の確認、残高の減額などの、一連の決済シーケンスを記述したプログラムがプリペイド電子マネーアプリケーションの決済機能を実現するプログラムとしてサービス定義データベース２３から読み出されている。
【０１２１】
このように、一連の処理を１つのコマンドだけでICカード２において実現させることができるため、同じ一連の処理を複数のコマンドによって実現させる場合に較べて、アプリケーション事業者の負担を軽減することができる。すなわち、アプリケーション事業者は、決済を実現させるにしても、決済実行条件の確認、サービス有効期限の確認、残高の確認、残高の減額などのそれぞれの処理をどのタイミングで行うかなどを設計したり、それぞれの処理を行わせるためのコマンドを定義したりする必要がなく、単に、決済コマンドだけがICカード２に発行されるようにしておくだけで済む。すなわち、システムの設計工数を大幅に削減することができ、コストを削減することができる。また、ICカード２とリーダ／ライタ間の通信トランザクションにおいて送受信されるデータの量を抑えることが可能となる。
【０１２２】
また、後述するように、アプリケーション事業者はそれぞれの処理シーケンスに対して権限鍵を割り当てることができる。従って、処理シーケンス毎に権限を分解して設定することが可能となり、１つの権限鍵が漏洩した際のセキュリティ・リスクを軽減することができる。例えば、１つの権限鍵によって全ての処理シーケンスの権限が管理される場合、その１つの権限鍵が漏洩することによって全ての処理シーケンスが悪用されてしまうおそれがあるが、処理シーケンス毎に権限鍵を割り当てることができ、権限鍵によって認証が成功した処理シーケンスだけを運用側が利用することができるようにすることにより、１つの権限鍵が漏洩したとしても、そのように全ての処理シーケンスが悪用されるといったことを防ぐことができる。
【０１２３】
図８は、図６のサービスデータ構造３１の例を示す図である。
【０１２４】
図８に示されるように、サービスデータ構造３１は、基本的に、サービスID領域６１、処理シーケンス領域６２乃至６７、および、サービスデータ構造内部の具体的なデータ（ユーザデータ）が格納される領域であるデータ格納領域６８乃至７０に分類される。
【０１２５】
サービスID領域６１は、アプリケーションの契約番号としてICカード２のユーザに割り当てられた番号に対応する値（情報）が格納される領域であり、１つのアプリケーション事業者のアプリケーション（図８の例ではプリペイド電子マネーアプリケーション）内で一意の値が採番される。これにより、リーダ／ライタ４１が発行するコマンドによってサービスデータ構造３１が識別される。
【０１２６】
処理シーケンス領域６２乃至６７は、リーダ／ライタ４１から呼び出しが可能な処理ステップの集合を識別する値（処理シーケンスを記述したプログラム）が格納される領域である。処理シーケンスは、データ格納領域６８乃至７０のうちの１つまたは複数の領域に格納されているデータの読み出し、データの書き込み、データを用いた演算、データの比較、処理履歴の記憶、処理の正当性の確認、電子署名の書き出しなどの処理から構成されるステップをまとめて定義した処理関数として定義されており、それぞれの処理関数に基づく処理が、リーダ／ライタ４１から発行されるコマンドによって実行されるようになされている。
【０１２７】
図８の例においては、処理シーケンス領域６２乃至６７には、チャージシーケンス、決済シーケンス、残高確認シーケンス、履歴照会シーケンス、PINシーケンス、設定値変更シーケンスのそれぞれの処理シーケンスを記述したプログラムが格納されている。
【０１２８】
チャージシーケンスは、データ格納領域６９を構成する残高領域８３に対する値のチャージを行うための処理ステップを規定し、決済シーケンスは、残高領域８３に格納されている値により表される残高の減額（電子マネーの利用）を行うための処理ステップを規定する。
【０１２９】
残高確認シーケンスは、残高領域８３に格納されている値により表される残高の確認を行うための処理ステップを規定し、履歴照会シーケンスは、データ格納領域７０に格納されている情報により表されるアクセスログの確認を行うための処理ステップを規定する。PINシーケンスは、サービスデータ構造３１により管理されるデータに対して、PINによるアクセス制限を行う処理ステップ、および、アクセス制限を解除する処理ステップを規定し、設定値変更シーケンスは、データ格納領域６８乃至７０に格納されている値のうち、運用時に変更が可能とされている設定値を変更するための処理ステップを規定する。
【０１３０】
また、図８の例においては、処理シーケンス領域６２乃至６７に格納されているプログラムに記述されるそれぞれの処理シーケンスには権限鍵Ｋ11乃至Ｋ16が設定されており、処理シーケンスを実行するためには、設定されているそれぞれの権限鍵Ｋ11乃至Ｋ16を用いた相互認証が成功していることが前提とされている。
【０１３１】
データ格納領域６８は、サービスデータ構造３１全体の有効期限を表す情報が格納される領域である。
【０１３２】
データ格納領域６９は、決済単位に関する各種の情報が格納される領域であり、決済実行条件領域８１、領域８２、残高領域８３、残高制約領域８４、領域８５、PIN用データ領域８６、および任意データ領域８７から構成される。
【０１３３】
決済実行条件領域８１は、決済を行う際の制約条件を表す情報が格納される領域である。決済の条件として、例えば、「決済時に減額する値（残高）の範囲が１円以上、２００００円以下であること」といった、決済額の範囲を表す情報などが領域８２に格納される。
【０１３４】
残高領域８３は、電子マネーの残高を表す情報が格納される領域であり、残高制約領域８４は、残高に対する制約条件を表す情報が格納される領域である。残高の条件として、例えば、「残高は０円以上、５００００円以下であること」といった、残高の範囲を表す情報などが領域８５に格納される。
【０１３５】
PIN用データ領域８６は、PIN認証の際に用いられるPINに関する情報が格納される領域であり、任意データ領域８７は、アプリケーション事業者が任意に設定可能なデータが格納される領域である。
【０１３６】
データ格納領域７０は、アクセスログに関する情報が格納される領域であり、アクセスログ設定値領域９１、領域９２、領域９３、およびアクセスログ記録領域９４から構成される。
【０１３７】
アクセスログ設定値領域９１は、アクセスログ記録領域９４に関する設定値が格納される領域である。アクセスログ記録領域９４に関する設定値として、「決済シーケンスにおいてアクセスログを記録する」といった、アクセスログの記録単位を表す情報などが領域９２に格納される。また、アクセスログ記録領域９４に関する設定値として、「アクセスログを４件まで保存する」といった、記録件数を表す情報などが領域９３に格納される。
【０１３８】
アクセスログ記録領域９４は、アクセスログがFIFO(First In First Out)方式で記録される領域である。
【０１３９】
このように、ICカード２においては、内容毎に領域が割り当てられ、データが管理される。従って、他の不要なデータを読み出すことなく、処理で必要になるデータだけを読み出すことが可能となる。例えば、固定長のブロックに分けてデータが管理され、データの読み出しも１つのブロックに格納されているデータ毎に行われる場合、その固定長よりデータ量の少ないデータを読み出したときには、処理に必要のない余計なデータも読み出されることになるが、そのようなことを防ぐことができる。
【０１４０】
ここで、図９のフローチャートを参照して、ICカード２とリーダ／ライタ４１の間で決済シーケンスに従って行われる処理について説明する。
【０１４１】
リーダ／ライタ４１により行われるステップＳ６１乃至Ｓ６４の処理、ICカード２により行われるステップＳ７１乃至Ｓ７４の処理は、それぞれ、図２のステップＳ１乃至Ｓ４の処理、ステップＳ２１乃至Ｓ２４の処理と同様の処理である。
【０１４２】
すなわち、ステップＳ６１において、リーダ／ライタ４１は、Pollingコマンドを送信することによって通信相手となるICカード２の探索、捕捉を行う。
【０１４３】
ステップＳ７１において、ICカード２は、リーダ／ライタ４１から送信されてきたPollingコマンドを受信し、ステップＳ７２に進み、それに応答する。
【０１４４】
ICカード２からの応答が送信されてきたとき、ステップＳ６２において、リーダ／ライタ４１はそれを受信し、ステップＳ６３に進み、相互認証コマンドを送信することによってICカード２との間で相互認証を行う。
【０１４５】
ステップＳ７３において、ICカード２は、リーダ／ライタ４１から送信されてきた相互認証コマンドを受信し、ステップＳ７４に進み、認証に用いる所定の情報をメモリから読み出し、読み出した情報をリーダ／ライタ４１に送信する。
【０１４６】
相互認証に用いる情報がICカード２から送信されてきたとき、ステップＳ６４において、リーダ／ライタ４１はそれを受信する。
【０１４７】
ステップＳ６５において、リーダ／ライタは、決済シーケンス呼出しコマンドをICカード２に送信する。ここで送信される決済シーケンス呼出しコマンドには、現在時刻、決済額、サービスIDを表す情報がコマンドパラメータとして付加される。
【０１４８】
ステップＳ７５において、ICカード２のプリペイド電子マネーオブジェクト５１は、リーダ／ライタ４１から送信されてきた決済シーケンス呼出しコマンドを受信し、コマンドパラメータとして送信されてきたサービスIDにより特定されるサービスデータ構造３１の処理シーケンス領域６３に格納されているプログラムを実行することによって決済シーケンスを呼び出す。これ以降の処理は、呼び出された決済シーケンスに従って行われる。
【０１４９】
ステップＳ７６において、プリペイド電子マネーオブジェクト５１は決済実行条件の確認を行う。例えば、リーダ／ライタ４１からコマンドパラメータとして送信されてきた決済額が、領域８２に格納される情報により表される決済額の範囲内の額であるか否かが確認され、その範囲内の額であることが確認された場合、処理はステップＳ７７に進む。
【０１５０】
ステップＳ７７において、プリペイド電子マネーオブジェクト５１はサービスデータ構造の有効期限の確認を行う。例えば、リーダ／ライタ４１からコマンドパラメータとして送信されてきた現在時刻が、データ格納領域６８に格納される値により表されるサービスデータ構造３１の有効期限内の時刻であるか否かが確認され、有効期限内の時刻であることが確認された場合、処理はステップＳ７８に進む。
【０１５１】
ステップＳ７８において、プリペイド電子マネーオブジェクト５１は電子マネーの残高の確認を行う。例えば、残高領域８３に格納される情報により表される残高が確認された後、処理はステップＳ７９に進む。
【０１５２】
ステップＳ７９において、プリペイド電子マネーオブジェクト５１は決済処理を行う。例えば、残高領域８３に格納されている情報により表される電子マネーの残高が、現在の残高から決済額を差し引いた額によって上書きされる。決済額を表す情報も、コマンドパラメータとしてリーダ／ライタ４１から送信されてきている。
【０１５３】
ステップＳ８０において、プリペイド電子マネーオブジェクト５１はアクセスログの書き出し処理を行う。例えば、アクセスログ記録領域９４の所定の領域に、今回の決済処理のログを表す値が書き込まれる。
【０１５４】
アクセスログの値の書き込みが成功したとき、プリペイド電子マネーオブジェクト５１は、ステップＳ８１において、アクセスログの書き出し処理が成功したことを表す情報である成功レスポンスをリーダ／ライタ４１に送信する。
【０１５５】
成功レスポンスがICカード２から送信されてきたとき、ステップＳ６６において、リーダ／ライタ４１はそれを受信し、これにより、決済シーケンスに従った一連の処理が終了する。
【０１５６】
このように、ICカード２においては、リーダ／ライタから１つのコマンドが送信されてくることに応じて処理シーケンスが呼び出され、処理シーケンスに従って処理が進められる。
【０１５７】
次に、図１０、図１１のフローチャートを参照して、決済シーケンスに従って行われるICカード２の一連の処理について詳細に説明する。
【０１５８】
この処理は、ICカード２がリーダ／ライタ４１にかざされ、相互認証コマンドがリーダ／ライタ４１から送信されてきたときに開始される。相互認証コマンドが送信されてきたとき、ICカード２とリーダ／ライタ４１の間では、ICカード２のサービスデータ構造３１に割り当てられている権限鍵Ｋ1と、それに対応する鍵としてリーダ／ライタ４１に割り当てられている権限鍵を用いた相互認証が行われる。
【０１５９】
ステップＳ９１において、ICカード２のプリペイド電子マネーオブジェクト５１は、リーダ／ライタ４１との間で行われていた相互認証が完了したか否かを判定し、相互認証が失敗したことなどから、相互認証が完了していないと判定した場合、ステップＳ９２に進む。
【０１６０】
ステップＳ９２において、プリペイド電子マネーオブジェクト５１は無応答処理を行い、処理を終了させる。
【０１６１】
一方、ステップＳ９１において、相互認証が完了したと判定した場合、ステップＳ９３に進み、プリペイド電子マネーオブジェクト５１は、リーダ／ライタ４１から送信されてきた決済シーケンス呼出しコマンドに付加されているコマンドパラメータを取り出す。例えば、現在時刻、決済額を表す情報が取り出される。
【０１６２】
ステップＳ９４において、プリペイド電子マネーオブジェクト５１は、リーダ／ライタ４１からコマンドパラメータとして送信されてきた決済額が、領域８２に格納される情報により表される決済額の範囲内の額であるか否かを確認することによって決済実行条件を満たしているか否かを判定する。
【０１６３】
プリペイド電子マネーオブジェクト５１は、ステップＳ９４において、決済実行条件を満たしていないと判定した場合、ステップＳ９５に進み、エラー処理を行った後、処理を終了させる。例えば、決済実行条件を満たしていないことがリーダ／ライタ４１に通知され、そのことをユーザに通知するメッセージがリーダ／ライタ４１において表示される。
【０１６４】
一方、ステップＳ９４において、決済実行条件を満たしていると判定した場合、ステップＳ９６に進み、プリペイド電子マネーオブジェクト５１は、リーダ／ライタ４１からコマンドパラメータとして送信されてきた現在時刻が、データ格納領域６８に格納される値により表されるサービスデータ構造３１の有効期限内の時刻であるか否かを判定する。
【０１６５】
プリペイド電子マネーオブジェクト５１は、ステップＳ９６において、現在時刻がサービスデータ構造３１の有効期限内の時刻ではないと判定した場合、ステップＳ９５に進み、エラー処理を行った後、処理を終了させる。例えば、有効期限を過ぎていることがリーダ／ライタ４１に通知され、そのことをユーザに通知するメッセージがリーダ／ライタ４１において表示される。
【０１６６】
一方、ステップＳ９６において、現在時刻がサービスデータ構造３１の有効期限内の時刻であると判定した場合、ステップＳ９７に進み、プリペイド電子マネーオブジェクト５１は、残高領域８３に格納される情報により表される残高を確認し、残高から決済額を減算した額が、残高制約領域８４に格納される情報により表される残高の制約条件の範囲内の額であり、制約条件としての値（額）の範囲と値の種類を満たしているか否かを判定する。
【０１６７】
ステップＳ９７において、プリペイド電子マネーオブジェクト５１は、残高から決済額を減算した額が、制約条件の値の範囲と値の種類を満たしていないと判定した場合、ステップＳ９５に進み、エラー処理を行った後、処理を終了させる。例えば、残高の制約条件を満たしていないことがリーダ／ライタ４１に通知され、そのことをユーザに通知するメッセージがリーダ／ライタ４１において表示される。
【０１６８】
一方、ステップＳ９７において、残高から決済額を減算した額が、制約条件の値の範囲と値の種類を満たしていると判定した場合、プリペイド電子マネーオブジェクト５１は、ステップＳ９８に進み、残高領域８３に格納されている情報により表される電子マネーの残高を、現在の残高から決済額を差し引いた額によって上書きし、決済を行う。
【０１６９】
ステップＳ９９において、プリペイド電子マネーオブジェクト５１は、領域９２に格納されている情報に基づいて、アクセスログの記録単位が決済シーケンスであるとして指定されているか否かを判定し、そのような指定がされていないと判定した場合、処理を終了させる。
【０１７０】
一方、プリペイド電子マネーオブジェクト５１は、ステップＳ９９において、アクセスログの記録単位が決済シーケンスとして指定されていると判定した場合、ステップＳ１００に進み、今回の決済の内容を表す値をアクセスログとしてアクセスログ記録領域９４に記録する。
【０１７１】
アクセスログの値の書き込みが成功したとき、ステップＳ１０１において、プリペイド電子マネーオブジェクト５１は、アクセスログの書き出し処理が成功したことを表す情報である成功レスポンスをリーダ／ライタ４１に送信し、処理を終了させる。
【０１７２】
従来はリーダ／ライタ４１側で行っていた決済実行条件の確認、サービス有効期限の確認、書き換える残高の算出などの処理を以上のようにしてICカード２側で行うようにすることにより、ICカード２とリーダ／ライタ４１の間で行われる情報の受け渡しの回数を最小限の回数に抑えることができる。無線通信においてはデータの拡散性（漏洩性）が問題となり、データの送受信をできるだけ抑えるようにすることが求められるところ、このことについても優位性を得ることが可能となる。
【０１７３】
また、ICカード２とリーダ／ライタ４１の間で行われる通信は無線であるから、通信伝送路にノイズが混入することなどにより正しいパケットをICカード２が受信できないことが発生することがあり、それが発生した場合、リーダ／ライタ４１は、コマンド毎にリトライ（再送要求）処理を行う必要があるが、その発生確率を減らすことができる。
【０１７４】
さらに、決済シーケンスなどの一連の処理が複数のコマンドによってICカード２において実現される場合、リーダ／ライタ４１が発生する磁界の到達範囲からICカード２が一連の処理の途中で離脱し、ICカード２の電力が途絶えてしまったときなどには、ICカード２が磁界の到達範囲に次に入ったときなどの所定のタイミングで、処理の途中の状態からの復帰処理（ロールバック処理）をリーダ／ライタ４１は行う必要があるが、そのようなことの発生確率を減らすこともできる。
【０１７５】
図１２は、サービスデータ構造３１の他の例を示す図である。
【０１７６】
図１２に示されるサービスデータ構造３１は、残高領域８３に格納される残高を表す情報に対して更新権限鍵Ｋ21が設定され、それが領域１０１に格納されている点を除いて図８に示されるサービスデータ構造３１と同じである。
【０１７７】
このようなサービスデータ構造を対象とした場合、残高の更新を伴うシーケンスである決済シーケンスやチャージシーケンスにおいては、残高の更新が行われる前、ICカード２とリーダ／ライタ４１の間では、更新権限鍵Ｋ21と、更新権限鍵Ｋ21に対応する鍵としてリーダ／ライタ４１に割り当てられた権限鍵を用いた相互認証が行われ、相互認証が成功したときに、残高領域８３に格納されている情報の更新が可能とされる。
【０１７８】
このように、サービスデータ構造や処理シーケンスに対してだけでなく、１つの領域に格納されているデータに対しても権限鍵を設定することが可能である。また、データの読み出しのための鍵、図１２の更新権限鍵Ｋ21のようなデータの書き込みのための鍵といったように、目的に応じた権限鍵を設定することができる。従って、領域毎、目的毎に権限鍵を分けて設定することによって、１つの権限鍵が漏洩した際のセキュリティリスクを軽減することができる。
【０１７９】
図１３は、図６のサービスデータ構造３２の例を示す図である。上述したように、サービスデータ構造３２は、チケットアプリケーションに必要なデータを管理するサービスデータ構造であり、チケットオブジェクト５２により管理される。
【０１８０】
図１３に示されるように、サービスデータ構造３２は、基本的に、サービスID領域１１１、処理シーケンス領域１１２乃至１１８、および、サービスデータ構造内部の具体的なデータが格納される領域であるデータ格納領域１１９乃至１２１に分類される。
【０１８１】
サービスID領域１１１は、アプリケーションの契約番号としてICカード２のユーザに割り当てられた番号に対応する値が格納される領域であり、１つのアプリケーション事業者のアプリケーション（図１３の例ではチケットアプリケーション）内で一意の値が採番される。これにより、リーダ／ライタ４１が発行するコマンドによってサービスデータ構造３２が識別される。
【０１８２】
処理シーケンス領域１１２乃至１１８は、リーダ／ライタ４１から呼び出しが可能な処理ステップの集合を識別する値（処理シーケンスを記述したプログラム）が格納される領域である。
【０１８３】
図１３の例においては、処理シーケンス領域１１２乃至１１８には、決済単位書き込みシーケンス、決済実行条件確認シーケンス、決済シーケンス、決済単位確認シーケンス、履歴照会シーケンス、PINシーケンス、設定値変更シーケンスのそれぞれの処理シーケンスを記述したプログラムが格納されている。
【０１８４】
決済単位書き込みシーケンスは、データ格納領域１２０の枚数領域１３６に格納されている値のチャージ（枚数を増やすこと）を行うための処理ステップを規定する。ここで、実現するアプリケーションがチケットアプリケーションである場合、決済とは、ICカード２のユーザがアプリケーションの提供を受けることの対価として、コンサートのチケット、交通機関を利用するためのチケットなどの電子的なチケットの残り枚数を減らすことをいう。
【０１８５】
決済実行条件確認シーケンスは、決済実行条件の確認を行うための処理ステップを規定し、決済シーケンスは、枚数領域１３６に格納されている値により表されるチケットの減算（チケットの利用）を行うための処理ステップを規定する。
【０１８６】
決済単位確認シーケンスは、決済がどのような情報を１単位として行われるのかを確認するための処理ステップを規定し、履歴照会シーケンスは、データ格納領域１２１に格納されている情報により表されるアクセスログの確認を行うための処理ステップを規定する。PINシーケンスは、サービスデータ構造３２により管理されるデータに対して、PINによるアクセス制限を行う処理ステップ、および、アクセス制限を解除する処理ステップを規定し、設定値変更シーケンスは、データ格納領域１１９乃至１２１に格納されている値のうち、運用時に変更が可能とされている設定値を変更するための処理ステップを規定する。
【０１８７】
また、図１３の例においては、処理シーケンス領域１１２乃至１１８に格納されているプログラムに記述されるそれぞれの処理シーケンスには権限鍵Ｋ31乃至Ｋ37が設定されており、処理シーケンスを実行するためには、設定されているそれぞれの権限鍵Ｋ31乃至Ｋ37を用いた相互認証が成功していることが前提とされている。
【０１８８】
データ格納領域１１９は、サービスデータ構造３２全体の有効期限を表す情報が格納される領域である。
【０１８９】
データ格納領域１２０は、決済に関する各種の情報が格納される領域であり、決済実行条件領域１３１、領域１３２、領域１３３、領域１３４、領域１３５、枚数領域１３６、枚数制約領域１３７、領域１３８、PIN用データ領域１３９、および任意データ領域１４０から構成される。
【０１９０】
決済実行条件領域１３１は、決済を行う際の制約条件を表す情報が格納される領域である。決済の条件として、例えば、チケットの有効期限を表す情報が領域１３２に、チケットの有効場所（劇場、端末など）を表す情報が領域１３３に、「１回の決済で電子的なチケットを３枚分の減算する」といったような、何枚単位でチケットを消費するかの決済単位を表す情報が領域１３４に、任意の情報が領域１３５にそれぞれ格納される。
【０１９１】
枚数領域１３６は、電子的なチケットの残り枚数を表す情報が格納される領域であり、枚数制約領域１３７は、電子的なチケットの残り枚数に対する制約条件を表す情報が格納される。枚数に対する制約条件として、例えば、「チケットの残り枚数は０枚以上、１０枚以下であること」といった、枚数の範囲を表す情報などが領域１３８に格納される。
【０１９２】
PIN用データ領域１３９は、PIN認証の際に用いられるPINに関する情報が格納される領域であり、任意データ領域１４０は、アプリケーション事業者が任意に設定可能なデータが格納される領域である。
【０１９３】
データ格納領域１２１は、アクセスログに関する情報が格納される領域であり、アクセスログ設定値領域１５１、領域１５２、領域１５３、およびアクセスログ記録領域１５４から構成される。データ格納領域１２１の構成は、図８のデータ格納領域７０の構成と同じである。
【０１９４】
すなわち、アクセスログ設定値領域１５１の領域１５２は、アクセスログの記録単位を表す情報が格納される領域であり、領域１５３は、記録件数を表す情報などが格納される領域である。アクセスログ記録領域１５４は、アクセスログがFIFO方式で記録される領域である。
【０１９５】
図１４は、図６のサービスデータ構造３２の他の例を示す図である。
【０１９６】
図１４の例においては、図１３のデータ格納領域１２０には１つだけ示されている決済単位が５つ示されている。図１４に示される決済単位は、コンサートの電子的なチケットを表す情報、交通機関の電子的なチケットを表す情報といったようにそれぞれ異なるアプリケーションの提供を受けるときに使われるものである。決済シーケンスでは、リーダ／ライタ４１から送信されてきたコマンドパラメータによって、対象となる決済単位が特定され、決済が行われる。
【０１９７】
このように、「格納可能な決済単位数」のサービス定義項目が「複数」（図４）として設定されているチケットアプリケーションにおいては、複数の決済単位を１つのサービスデータ構造３２によって管理させるようにすることも可能である。
【０１９８】
以上においては、主に、プリペイド電子マネーアプリケーションとチケットアプリケーションを実現する場合のサービスデータ構造について説明したが、同様のサービスデータ構造を、各種の権利を表す情報を管理する際に用いることもできる。例えば、鉄道定期券、鉄道乗車券、ポイントカード、スタンプカード、クーポン券、劇場鑑賞券、回数券、電子マネー、クレジットカード、キャッシュカード、デビットカード、社員証、保証書、ドアの鍵、本人確認証明書、アクセスコントロールカード等により表される権利を管理することに適用することができる。
【０１９９】
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、プログラム記録媒体からインストールされる。
【０２００】
図１５は、上述した一連の処理をプログラムにより実行するパーソナルコンピュータの構成の例を示すブロック図である。
【０２０１】
CPU(Central Processing Unit)２０１は、ROM(Read Only Memory)２０２、または記憶部２０８に記憶されているプログラムに従って各種の処理を実行する。RAM(Random Access Memory)２０３には、CPU２０１が実行するプログラムやデータなどが適宜記憶される。これらのCPU２０１、ROM２０２、およびRAM２０３は、バス２０４により相互に接続されている。
【０２０２】
CPU２０１にはまた、バス２０４を介して入出力インタフェース２０５が接続されている。入出力インタフェース２０５には、キーボード、マウス、マイクロホンなどよりなる入力部２０６、ディスプレイ、スピーカなどよりなる出力部２０７が接続されている。CPU２０１は、入力部２０６から入力される指令に対応して各種の処理を実行する。そして、CPU２０１は、処理の結果を出力部２０７に出力する。
【０２０３】
入出力インタフェース２０５に接続されている記憶部２０８は、例えばハードディスクからなり、CPU２０１が実行するプログラムや各種のデータを記憶する。通信部２０９は、インターネットやローカルエリアネットワークなどのネットワークを介して外部の装置と通信する。
【０２０４】
入出力インタフェース２０５に接続されているドライブ２１０は、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア２１１が装着されたとき、それらを駆動し、そこに記録されているプログラムやデータなどを取得する。取得されたプログラムやデータは、必要に応じて記憶部２０８に転送され、記憶される。
【０２０５】
コンピュータにインストールされ、コンピュータによって実行可能な状態とされるプログラムを格納するプログラム記録媒体は、図１５に示すように、磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM(Compact Disc-Read Only Memory)，DVD(Digital Versatile Disc)を含む）、光磁気ディスク、もしくは半導体メモリなどよりなるパッケージメディアであるリムーバブルメディア２１１、または、プログラムが一時的もしくは永続的に格納されるROM２０２や、記憶部２０８を構成するハードディスクなどにより構成される。プログラム記録媒体へのプログラムの格納は、必要に応じてルータ、モデムなどのインタフェースである通信部２０９を介して、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の通信媒体を利用して行われる。
【０２０６】
なお、本明細書において、プログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【図面の簡単な説明】
【０２０７】
【図１】従来のサービス発行方式について説明する図である。
【図２】従来のICカードとリーダ／ライタの間で行われる処理について説明するフローチャートである。
【図３】本発明の一実施形態に係る情報処理システムにおけるサービスの発行方式について説明する図である。
【図４】アプリケーション毎のデータ構造を表す情報の例を示す図である。
【図５】サービス発行時に行われる処理について説明するフローチャートである。
【図６】サービスデータ構造の例を示す図である。
【図７】アプリケーション運用時の基本的なシステム構成の例を示す図である。
【図８】図６のサービスデータ構造３１の例を示す図である。
【図９】ICカードとリーダ／ライタの間で行われる処理について説明するフローチャートである。
【図１０】決済シーケンスに従って行われるICカードの処理について説明するフローチャートである。
【図１１】決済シーケンスに従って行われるICカードの処理について説明する、図１０に続くフローチャートである。
【図１２】図６のサービスデータ構造３１の他の例を示す図である。
【図１３】図６のサービスデータ構造３２の例を示す図である。
【図１４】図６のサービスデータ構造３２の他の例を示す図である。
【図１５】パーソナルコンピュータの構成例を示すブロック図である。
【符号の説明】
【０２０８】
１  サービス発行システム，  ２  ICカード，  １１  サービス発行端末，  ２１  サービス発行機能，  ２２  ファイルシステム，  ２３  サービス定義データベース，  ４１  リーダ／ライタ，  ５１  プリペイド電子マネーオブジェクト，  ５２  チケットオブジェクト，  ５３  サービスオブジェクト
【図１】
2008033529.tif 000003
【図２】
2008033529.tif 000004
【図３】
2008033529.tif 000005
【図４】
2008033529.tif 000006
【図５】
2008033529.tif 000007
【図６】
2008033529.tif 000008
【図７】
2008033529.tif 000009
【図８】
2008033529.tif 000010
【図９】
2008033529.tif 000011
【図１０】
2008033529.tif 000012
【図１１】
2008033529.tif 000013
【図１２】
2008033529.tif 000014
【図１３】
2008033529.tif 000015
【図１４】
2008033529.tif 000016
【図１５】
2008033529.tif 000017