ＩＣカードシステム、ＩＣカードシステムのリカバリ方法およびサーバ
【課題】シーケンスの途中で処理が中断した場合でも、効率的なリカバリ処理を可能とする。
【解決手段】サーバ１０は、端末２０と通信する通信部１２と、ＩＣカード３０の処理シーケンスを定義するスクリプト１３と、スクリプト１３に基づきＡＰＤＵコマンドを生成し通信部１２に送信する処理制御部１１とを有する。端末２０は、サーバ１０と通信する通信部２２と、ＡＰＤＵコマンドをＩＣカード３０に送信しＡＰＤＵレスポンスを受信するリーダライタ部２４とを有し、処理制御部１１が、リカバリ処理が定義されているＡＰＤＵコマンドに対応するレスポンスを所定時間内に受信しない場合、該ＡＰＤＵコマンドに対してスクリプト１３で定義されたリカバリ処理を行い、リカバリ処理が定義されていないＡＰＤＵコマンドに対応するレスポンスを所定時間内に受信しない場合、該ＡＰＤＵコマンドをＩＣカード３０に再送する。
【解決手段】サーバ１０は、端末２０と通信する通信部１２と、ＩＣカード３０の処理シーケンスを定義するスクリプト１３と、スクリプト１３に基づきＡＰＤＵコマンドを生成し通信部１２に送信する処理制御部１１とを有する。端末２０は、サーバ１０と通信する通信部２２と、ＡＰＤＵコマンドをＩＣカード３０に送信しＡＰＤＵレスポンスを受信するリーダライタ部２４とを有し、処理制御部１１が、リカバリ処理が定義されているＡＰＤＵコマンドに対応するレスポンスを所定時間内に受信しない場合、該ＡＰＤＵコマンドに対してスクリプト１３で定義されたリカバリ処理を行い、リカバリ処理が定義されていないＡＰＤＵコマンドに対応するレスポンスを所定時間内に受信しない場合、該ＡＰＤＵコマンドをＩＣカード３０に再送する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバが端末を介してＩＣカードと通信を行うＩＣカードシステム、ＩＣカードシステムにおけるコマンドシーケンスのリカバリ方法およびこのようなＩＣカードシステムにおけるサーバに関するものである。
【背景技術】
【０００２】
ＩＣカード等のセキュアデバイスに対するコマンドシーケンスをスクリプトで定義する技術として、例えば、特許文献１には、１つのＩＣカードに複数のアプリケーションが搭載されているマルチアプリケーションシステムにおいて、サーバとＩＣカードとの間のデータの送受信の際に定義ファイルを参照することにより、単一の通信制御アプリケーションでデータ通信可能な技術が記載されている。また、特許文献２には、各種シーケンス処理の実行に必要なプログラムと、シーケンス処理に用いられるデータとを分離し、シーケンス処理の実行に必要な入力パラメータ情報等を格納した定義ファイルを設け、プログラムを変更することなく定義ファイルの内容を修正するだけでシーケンスを変更可能な技術が記載されている。
【０００３】
上述した従来技術のように、コマンドシーケンスをスクリプトで定義することにより、新たなＩＣカードの発行、あるいは、新たなカードアプリケーションへの対応がスクリプトの編集で可能となる。そのため、コマンドシーケンスをＣやＪａｖａ（登録商標）等のプログラムに埋め込む場合と比較し、新たなＩＣカードの発行、あるいは、新たなカードアプリケーションへの対応が容易であるという利点がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第３８８７２６３号
【特許文献２】特許第３８５７１９０号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＩＣカードを発行する処理、あるいは、発行済みのＩＣカードにカードアプリケーションを搭載・設定する等の処理においては、複数のコマンドをＩＣカードに対して規定されたシーケンスで実行する必要がある。シーケンスの途中で通信断等により、ＩＣカードからのレスポンスがサーバ側に届かなかった場合、そのコマンドがＩＣカードに対して実行されたのか否かを、サーバは判断することができない。ＩＣカードに対してそのコマンドが未実施の場合は、リカバリ処理において、再度、レスポンスの届かなかったコマンドからシーケンスをリトライすればよい。しかし、ＩＣカードに対してそのコマンドが実施されていた場合、コマンドの種類によっては、そのコマンドを再度実行すると、ＩＣカードが想定と異なる状態に遷移する。例えば、ＩＣカードのコマンドの「WRITE RECORD」は、同一のコマンドを１度実行した場合と２度実行した場合で、ＩＣカードが異なる状態に遷移する。それゆえ、サーバは、このようなコマンドに対しては、適切なリカバリ処理を実行する必要がある。
【０００６】
従来のスクリプト技術では、リカバリ処理を定義する方法が規定されていないため、シーケンスの途中で処理が中断した場合は、ＩＣカードを初期化してシーケンスの最初から実行する必要があった。それゆえ、ＩＣカードを発行する処理を最初からやり直したり、搭載済みのアプリケーションを削除して再度アプリケーションを搭載し、設定をやり直したりといった、時間的に非効率なリカバリ処理を行う必要があった。
【０００７】
そこで、本発明の目的は、ＩＣカードの処理シーケンスを定義するスクリプトにおいて、処理シーケンスの中断箇所に応じたリカバリ処理を定義することにより、効率的なリカバリ処理が可能なＩＣカードシステム、ＩＣカードシステムのリカバリ方法およびサーバを提供することにある。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明に係るＩＣカードシステムは、サーバが、前記サーバとネットワークにより接続されている端末を介してＩＣカードと通信を行うＩＣカードシステムであって、前記サーバは、前記端末と通信を行う通信部と、前記ＩＣカードの処理シーケンスを定義するスクリプトと、前記スクリプトに基づきＡＰＤＵコマンドを生成し、前記通信部に送信する処理制御部と、を有し、前記端末は、前記サーバと通信を行う通信部と、前記ＡＰＤＵコマンドを前記ＩＣカードに送信し、前記ＡＰＤＵコマンドに対応するＡＰＤＵレスポンスを前記ＩＣカードから受信するリーダライタ部と、を有し、前記処理制御部が、リカバリ処理が前記スクリプトで定義されている第１のＡＰＤＵコマンドに対応する第１のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第１のＡＰＤＵコマンドに対して前記スクリプトで定義されたリカバリ処理を行い、リカバリ処理が前記スクリプトで定義されていない第２のＡＰＤＵコマンドに対応する第２のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第２のＡＰＤＵコマンドを前記ＩＣカードに対して再送するように制御することを特徴とする。
【０００９】
また、上記課題を解決するため、本発明に係るＩＣカードシステムのリカバリ方法は、サーバが、前記サーバとネットワークにより接続されている端末を介してＩＣカードと通信を行うＩＣカードシステムのリカバリ方法であって、前記サーバにより、前記ＩＣカードの処理シーケンスを定義するスクリプトに基づきＡＰＤＵコマンドを生成し、前記端末に送信するステップと、前記端末により、前記サーバから受信したＡＰＤＵコマンドを前記ＩＣカードに送信し、前記ＡＰＤＵコマンドに対応するＡＰＤＵレスポンスを前記ＩＣカードから受信するステップと、前記サーバにより、リカバリ処理が前記スクリプトで定義されている第１のＡＰＤＵコマンドに対応する第１のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第１のＡＰＤＵコマンドに対して前記スクリプトで定義されたリカバリ処理を行うステップと、前記サーバにより、リカバリ処理が前記スクリプトで定義されていない第２のＡＰＤＵコマンドに対応する第２のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第２のＡＰＤＵコマンドを前記ＩＣカードに対して再送するように制御するステップと、を含むことを特徴とする。
【００１０】
また、上記課題を解決するため、本発明に係るサーバは、ネットワークにより接続されている端末を介してＩＣカードと通信を行うサーバであって、前記サーバは、前記端末と通信を行う通信部と、前記ＩＣカードの処理シーケンスを定義するスクリプトと、前記スクリプトに基づきＡＰＤＵコマンドを生成し、前記通信部に送信する処理制御部と、を有し、前記処理制御部が、リカバリ処理が前記スクリプトで定義されている第１のＡＰＤＵコマンドに対応する第１のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第１のＡＰＤＵコマンドに対して前記スクリプトで定義されたリカバリ処理を行い、リカバリ処理が前記スクリプトで定義されていない第２のＡＰＤＵコマンドに対応する第２のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第２のＡＰＤＵコマンドを前記ＩＣカードに対して再送するように制御することを特徴とする。
【発明の効果】
【００１１】
本発明では、ＩＣカードの発行、あるいは、ＩＣカード発行後のアプリケーション搭載・設定等の処理において、シーケンスの途中で処理が中断した場合でも、効率的なリカバリ処理が可能となる。また、本発明では、ＩＣカードの処理シーケンスをスクリプトで定義するため、プログラムコードで記述するよりも、可読性・メンテナンス性が高いという有利な効果をあわせて奏する。
【図面の簡単な説明】
【００１２】
【図１】ＩＣカードシステムの全体構成の一例を示す図である
【図２】ＩＣカードシステムの処理のシーケンス図である。
【図３】（ａ）はコマンドシーケンスの定義の一例を示し、（ｂ）はリカバリ処理の定義の一例を示す図である。
【発明を実施するための形態】
【００１３】
図１は本発明のＩＣカードシステムの全体構成の一例を示す図である。ＩＣカードシステム１００では、セキュアデバイス管理サーバ（以下、サーバと称する）１０は、運用者端末（以下、端末と称する）２０を介してＩＣカード３０と通信を行う。サーバ１０と端末２０とは、インターネット、ＬＡＮ等のネットワーク４０を介して接続されている。
【００１４】
サーバ１０は、処理制御部１１と、通信部１２と、スクリプト１３と、利用者パーソナライズ情報ＤＢ１４と、を有する。処理制御部１１は、処理の順番を制御する。また、処理制御部１１は、スクリプト１３を解釈し、ＩＣカード３０用のＡＰＤＵ（Application Protocol Data Unit）コマンドを生成する。また、処理制御部１１は、利用者パーソナライズ情報ＤＢ１４から利用者パーソナライズ情報を取得する。その他、処理制御部１１は、サーバ１０全体の制御を行う。通信部１２は、端末２０との通信を行う。スクリプト１３は、ＩＣカード３０用のＡＰＤＵコマンドを生成するための雛形である。利用者パーソナライズ情報ＤＢ１４は、ＩＣカード３０用のＡＰＤＵコマンドの一部に埋め込まれる利用者ＩＤ等の利用者に関連する情報を管理するデータベースである。
【００１５】
端末２０は、処理制御部２１と、通信部２２と、ＧＵＩ部２３と、リーダライタ部２４と、を有する。処理制御部２１は、端末２０全体の制御を行う。通信部２２は、サーバ１０との通信を行う。ＧＵＩ部２３は、運用者からの指示を受信し、運用者に対して処理結果を表示する。リーダライタ部２４は、通信部２２から受信したＡＰＤＵコマンドをＩＣカード３０に送信し、ＩＣカード３０からＡＰＤＵレスポンスを受信する。なお、リーダライタ部２４は、ＩＣカード発行機等の装置に組み込まれていてもよい。
【００１６】
ＩＣカード３０は、マルチアプリケーションシステムのＩＣカードであり、同一の又は異なるサービスプロバイダのサーバからダウンロードしたＮ個のカードアプリケーションＡＰ１〜ＡＰＮが格納されている。
【００１７】
以下、図２および図３を参照して、ＩＣカードシステム１００の処理手順を説明する。図２は、本発明のＩＣカードシステム１００の処理手順を示すシーケンス図である。
【００１８】
図３（ａ）は、コマンドシーケンスの定義の一例であり、ＩＣカードの発行処理、あるいは、カードアプリケーションの搭載・設定のためのコマンドシーケンスを定義するスクリプトである。図３（ａ）において、１６進の文字列は、カードに送信されるＡＰＤＵコマンドを示す。また、スクリプト中の記号として、「#」はコメント行を意味する。また、「Point n」はシーケンスにおける特定の箇所を意味し、図３（ｂ）に示すリカバリ処理の定義において利用される。また、「Recovery_type」は、処理制御部１１が、ＡＰＤＵレスポンスを受信しなかった場合に実施すべきリカバリのタイプを意味する。
【００１９】
図３（ｂ）は、リカバリ処理の定義の一例であり、図３（ａ）に示すコマンドシーケンスの定義のスクリプトにおいて「Recovery_type」で指定されるリカバリのタイプ毎に、リカバリ処理を定義する。１６進の文字列は、ＩＣカードに送信されるＡＰＤＵコマンドを示す。また、スクリプト中の記号として、「#」はコメント行を意味する。また、「Def」はリカバリ処理の定義の開始を意味し、「Def_end」はリカバリ処理の定義の終了を意味する。また、「Retry from Point n」は、図３（ａ）に示すコマンドシーケンスの定義のスクリプトにおける「Point n」で示される特定の箇所からシーケンスをリトライすることを意味する。また、「SW」はリカバリ処理を構成する最初のコマンドにおいて、ＩＣカードからの返却値が正常終了（9000h）以外もありうる場合に、その値を記載する。処理制御部１１は、ここに記述される値以外の返却値をＩＣカード３０から受信した場合、リカバリが正常に実施されていないと判断し、ＩＣカード３０に対するコマンド実行を中断し、エラーとして処理する。
【００２０】
ステップＳ１０１では、運用者が端末２０のＧＵＩ部２３に、ＡＰ１搭載のパーソナライズ情報の要求を入力する。パーソナライズ情報は、アプリケーション識別子（ＡＩＤ）およびカード識別子（ＣＩＤ）を含む。ＧＵＩ部２３は、ＡＰ１搭載のパーソナライズ情報の要求を処理制御部２１に送信する。処理制御部２１は、ＡＰ１搭載のパーソナライズ情報の要求を通信部２２に送信する。
【００２１】
ステップＳ１０２では、端末２０の通信部２２は、ＡＰ１搭載のパーソナライズ情報の要求をサーバ１０の通信部１２に送信する。通信部１２は、ＡＰ１搭載のパーソナライズ情報の要求を処理制御部１１に送信する。
【００２２】
ステップＳ１０３では、処理制御部１１は、ＡＩＤに関するスクリプトをスクリプト１３から取得する。
【００２３】
ステップＳ１０４では、処理制御部１１は、ＡＰ１搭載のパーソナライズ情報（ＡＩＤ、ＣＩＤ）を利用者パーソナライズ情報ＤＢ１４から取得する。
【００２４】
ステップＳ１０５では、処理制御部１１は、取得したスクリプトを解釈し、ＡＰＤＵコマンドを作成する。
【００２５】
ステップＳ１０６では、処理制御部１１は、ＡＰＤＵコマンドを通信部１２に送信する。サーバ１０の通信部１２は、ＡＰＤＵコマンドを端末２０の通信部２２に送信する。通信部２２は、ＡＰＤＵコマンドを処理制御部２１に送信する。処理制御部２１は、ＡＰＤＵコマンドをリーダライタ部２４に送信する。
【００２６】
ステップＳ１０７では、リーダライタ部２４は、ＡＰＤＵコマンドをＩＣカード３０に送信する。
【００２７】
ステップＳ１０８では、ＩＣカード３０は、ＡＰＤＵレスポンスをリーダライタ部２４に送信する。
【００２８】
ステップＳ１０９では、リーダライタ部２４は、ＡＰＤＵレスポンスを処理制御部２１に送信する。処理制御部２１は、ＡＰＤＵレスポンスを通信部２２に送信する。端末２０の通信部２２は、ＡＰＤＵレスポンスをサーバ１０の通信部１２に送信する。通信部１２は、ＡＰＤＵレスポンスを処理制御部１１に送信する。
【００２９】
ステップＳ１１０では、処理制御部１１は、所定の時間内にＡＰＤＵレスポンスを受信したか否かを判定する。
【００３０】
ステップＳ１０６〜ステップＳ１１０をＡＰＤＵコマンド数だけ繰り返す。具体的には、図３（ａ）に示すコマンドシーケンスの定義に記述されているスクリプトを上から順番に実行する。すなわち、はじめに、処理制御部１１は、１行目の「SELECT DF1」に相当するＡＰＤＵコマンド「00 A4 00 00 … 00 00」を実行する。処理制御部１１が、このＡＰＤＵコマンドに対するＡＰＤＵレスポンスを受信したら、３行目の「CREATE WEF1」に相当するＡＰＤＵコマンド「00 33 00 00 … 00 00」を実行する。この動作を、スクリプトに記述されている最後（２８行目）の「SET STATUS」に相当するＡＰＤＵコマンド「00 50 00 00 … 00 00」まで繰り返し実行する。
【００３１】
ステップＳ１１１では、処理制御部１１は、処理完了通知を通信部１２に送信する。サーバ１０の通信部１２は、処理完了通知を端末２０の通信部２２に送信する。通信部２２は、処理完了通知を処理制御部２１に送信する。処理制御部２１は、処理完了通知をＧＵＩ部２３に送信する。
【００３２】
ステップＳ１１２では、ＧＵＩ部２３は、処理完了通知を運用者に対して表示する。
【００３３】
次に、ステップＳ１０６〜ステップＳ１１０を繰り返している最中に通信断が発生した場合について説明する。すなわち、ステップＳ１１０において、処理制御部１１が、所定の時間内にＡＰＤＵレスポンスを受信しなかったと判定した場合について説明する。
【００３４】
第１に、リカバリ処理がスクリプトで定義されているＡＰＤＵコマンド（第１のＡＰＤＵコマンド）の送信中に、通信断が発生した場合を検討する。この場合、処理制御部２１は、第１のＡＰＤＵコマンドに対する第１のＡＰＤＵレスポンスを所定の時間内に受信しないので、第１のＡＰＤＵコマンドに対してスクリプトで定義されているリカバリ処理を行い、スクリプトのリカバリ定義で指定されている箇所からシーケンスをリトライする。
【００３５】
例えば、処理制御部１１が、図３（ａ）の９行目の「WRITE RECORD」に相当するＡＰＤＵコマンド「00 D2 00 00 … 00 00」に対するＡＰＤＵレスポンスを、所定の時間内に受信しなかった場合、図３（ａ）において、このＡＰＤＵコマンドのリカバリタイプが１であることが記載されているので（１０行目に「Recovery_type:1」が記載されているので）、図３（ｂ）のリカバリタイプ１の定義を参照する。すなわち、図３（ｂ）の２行目の「Def Recovery_type:1」を参照し、３行目の「DELETE WEF1」に相当するＡＰＤＵコマンド「00 22 00 00 … 00 00」を実行する。続けて、５行目の「Retry from Point 1」に従い、図３（ａ）の５行目の「Point 1」を参照し、６行目の「WRITE RECORD」に相当するＡＰＤＵコマンド「00 D2 00 00 … 00 00」からリトライする。
【００３６】
この場合、通信断が発生する前に、９行目の「WRITE RECORD」（２回目の「WRITE RECORD」）に相当するＡＰＤＵコマンド「00 D2 00 00 … 00 00」を実行したか否かに係わらず、「DELETE WEF1」に相当するＡＰＤＵコマンド「00 22 00 00 … 00 00」を実行することにより、ＷＥＦ１を削除している。それゆえ、改めて、６行目の「WRITE RECORD」（１回目の「WRITE RECORD」）に相当するＡＰＤＵコマンド「00 D2 00 00 … 00 00」からリトライするため、上述したような、同一の「WRITE RECORD」に相当するＡＰＤＵコマンドを実行したことにより、ＩＣカード３０が想定と異なる状態に遷移するといった問題が生じることはない。なお、ＷＥＦは作業用基礎ファイル（Working Elementary File）を意味する。
【００３７】
その他の例として、処理制御部１１が、図３（ａ）の２８行目の「SET STATUS」に相当するＡＰＤＵコマンドに対するＡＰＤＵレスポンスを所定の時間内に受信しなかった場合、図３（ａ）において、このＡＰＤＵコマンドのリカバリタイプが３であることが記載されているので（２９行目に「Recovery_type:3」が記載されているので）、図３（ｂ）のリカバリタイプ３の定義を参照する。すなわち、図３（ｂ）の１４行目の「Def Recovery_type:3」を参照し、１５行目の「Retry from Point 3」に従い、図３（ａ）の２７行目の「Point 3」を参照する。続けて、２８行目の「SET STATUS」に相当するＡＰＤＵコマンド「00 50 00 00 … 00 00」を実行する。
【００３８】
なお、図３（ｂ）の１６行目に「SW = 9000 or 6354」との記載があるため、ＩＣカード３０からのＡＰＤＵレスポンスが正常終了を表す「9000」ではなく「6354」であっても処理制御部１１は正常と判断する。また、処理制御部１１が、図３（ｂ）に記載されているＡＰＤＵレスポンスを、所定の時間内に受信しなかった場合は、ＩＣカード３０に対するコマンド実行を中断し、エラーとして処理する。
【００３９】
第２に、リカバリ処理がスクリプトで定義されていないＡＰＤＵコマンド（第２のＡＰＤＵコマンド）の送信中に、通信断が発生した場合を検討する。この場合、処理制御部２１は、第２のＡＰＤＵコマンドに対する第２のＡＰＤＵレスポンスを所定の時間内に受信しないので、同一の第２のＡＰＤＵコマンドからシーケンスをリトライする。
【００４０】
例えば、処理制御部１１が、図３（ａ）の３行目の「CREATE WEF1」に相当するＡＰＤＵコマンド「00 33 00 00 … 00 00」に対するＡＰＤＵレスポンスを、所定の時間内に受信しなかった場合、図３（ａ）において、このＡＰＤＵコマンドにはリカバリタイプが定義されていないため（「Recovery_type:n」との記載がないため）、同一のＡＰＤＵコマンドからシーケンスをリトライする。すなわち、３行目の「CREATE WEF1」に相当するＡＰＤＵコマンド「00 33 00 00 … 00 00」を再度実行する。
【００４１】
上述したように、第１のＡＰＤＵコマンドは、２度実行すると、ＩＣカードが想定と異なる状態に遷移するため、処理制御部１１が、第１のＡＰＤＵコマンドに対する第１のＡＰＤＵレスポンスを所定の時間内に受信しない場合、第１のＡＰＤＵコマンドに対してスクリプトで定義されたリカバリ処理を行う。一方、第２のＡＰＤＵコマンドは、２度実行しても、ＩＣカードは想定した状態に遷移するため、処理制御部１１が、第２のＡＰＤＵコマンドに対する第２のＡＰＤＵレスポンスを所定の時間内に受信しない場合、第２のＡＰＤＵコマンドを再度実行する、すなわち、第２のＡＰＤＵコマンドからシーケンスをリトライする。
【００４２】
以上のように、本発明によれば、ＩＣカードの発行や、ＩＣカード発行後のアプリケーション搭載・設定等の処理において、シーケンスの途中で処理が中断した場合でも、効率的なリカバリ処理が可能なＩＣカードシステムを提供することができる。
【符号の説明】
【００４３】
１０ サーバ
１１ 処理制御部
１２ 通信部
１３ スクリプト
１４ 利用者パーソナライズ情報ＤＢ
２０ 端末
２１ 処理制御部
２２ 通信部
２３ ＧＵＩ部
２４ リーダライタ部
３０ ＩＣカード
４０ ネットワーク
【技術分野】
【０００１】
本発明は、サーバが端末を介してＩＣカードと通信を行うＩＣカードシステム、ＩＣカードシステムにおけるコマンドシーケンスのリカバリ方法およびこのようなＩＣカードシステムにおけるサーバに関するものである。
【背景技術】
【０００２】
ＩＣカード等のセキュアデバイスに対するコマンドシーケンスをスクリプトで定義する技術として、例えば、特許文献１には、１つのＩＣカードに複数のアプリケーションが搭載されているマルチアプリケーションシステムにおいて、サーバとＩＣカードとの間のデータの送受信の際に定義ファイルを参照することにより、単一の通信制御アプリケーションでデータ通信可能な技術が記載されている。また、特許文献２には、各種シーケンス処理の実行に必要なプログラムと、シーケンス処理に用いられるデータとを分離し、シーケンス処理の実行に必要な入力パラメータ情報等を格納した定義ファイルを設け、プログラムを変更することなく定義ファイルの内容を修正するだけでシーケンスを変更可能な技術が記載されている。
【０００３】
上述した従来技術のように、コマンドシーケンスをスクリプトで定義することにより、新たなＩＣカードの発行、あるいは、新たなカードアプリケーションへの対応がスクリプトの編集で可能となる。そのため、コマンドシーケンスをＣやＪａｖａ（登録商標）等のプログラムに埋め込む場合と比較し、新たなＩＣカードの発行、あるいは、新たなカードアプリケーションへの対応が容易であるという利点がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第３８８７２６３号
【特許文献２】特許第３８５７１９０号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＩＣカードを発行する処理、あるいは、発行済みのＩＣカードにカードアプリケーションを搭載・設定する等の処理においては、複数のコマンドをＩＣカードに対して規定されたシーケンスで実行する必要がある。シーケンスの途中で通信断等により、ＩＣカードからのレスポンスがサーバ側に届かなかった場合、そのコマンドがＩＣカードに対して実行されたのか否かを、サーバは判断することができない。ＩＣカードに対してそのコマンドが未実施の場合は、リカバリ処理において、再度、レスポンスの届かなかったコマンドからシーケンスをリトライすればよい。しかし、ＩＣカードに対してそのコマンドが実施されていた場合、コマンドの種類によっては、そのコマンドを再度実行すると、ＩＣカードが想定と異なる状態に遷移する。例えば、ＩＣカードのコマンドの「WRITE RECORD」は、同一のコマンドを１度実行した場合と２度実行した場合で、ＩＣカードが異なる状態に遷移する。それゆえ、サーバは、このようなコマンドに対しては、適切なリカバリ処理を実行する必要がある。
【０００６】
従来のスクリプト技術では、リカバリ処理を定義する方法が規定されていないため、シーケンスの途中で処理が中断した場合は、ＩＣカードを初期化してシーケンスの最初から実行する必要があった。それゆえ、ＩＣカードを発行する処理を最初からやり直したり、搭載済みのアプリケーションを削除して再度アプリケーションを搭載し、設定をやり直したりといった、時間的に非効率なリカバリ処理を行う必要があった。
【０００７】
そこで、本発明の目的は、ＩＣカードの処理シーケンスを定義するスクリプトにおいて、処理シーケンスの中断箇所に応じたリカバリ処理を定義することにより、効率的なリカバリ処理が可能なＩＣカードシステム、ＩＣカードシステムのリカバリ方法およびサーバを提供することにある。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、本発明に係るＩＣカードシステムは、サーバが、前記サーバとネットワークにより接続されている端末を介してＩＣカードと通信を行うＩＣカードシステムであって、前記サーバは、前記端末と通信を行う通信部と、前記ＩＣカードの処理シーケンスを定義するスクリプトと、前記スクリプトに基づきＡＰＤＵコマンドを生成し、前記通信部に送信する処理制御部と、を有し、前記端末は、前記サーバと通信を行う通信部と、前記ＡＰＤＵコマンドを前記ＩＣカードに送信し、前記ＡＰＤＵコマンドに対応するＡＰＤＵレスポンスを前記ＩＣカードから受信するリーダライタ部と、を有し、前記処理制御部が、リカバリ処理が前記スクリプトで定義されている第１のＡＰＤＵコマンドに対応する第１のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第１のＡＰＤＵコマンドに対して前記スクリプトで定義されたリカバリ処理を行い、リカバリ処理が前記スクリプトで定義されていない第２のＡＰＤＵコマンドに対応する第２のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第２のＡＰＤＵコマンドを前記ＩＣカードに対して再送するように制御することを特徴とする。
【０００９】
また、上記課題を解決するため、本発明に係るＩＣカードシステムのリカバリ方法は、サーバが、前記サーバとネットワークにより接続されている端末を介してＩＣカードと通信を行うＩＣカードシステムのリカバリ方法であって、前記サーバにより、前記ＩＣカードの処理シーケンスを定義するスクリプトに基づきＡＰＤＵコマンドを生成し、前記端末に送信するステップと、前記端末により、前記サーバから受信したＡＰＤＵコマンドを前記ＩＣカードに送信し、前記ＡＰＤＵコマンドに対応するＡＰＤＵレスポンスを前記ＩＣカードから受信するステップと、前記サーバにより、リカバリ処理が前記スクリプトで定義されている第１のＡＰＤＵコマンドに対応する第１のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第１のＡＰＤＵコマンドに対して前記スクリプトで定義されたリカバリ処理を行うステップと、前記サーバにより、リカバリ処理が前記スクリプトで定義されていない第２のＡＰＤＵコマンドに対応する第２のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第２のＡＰＤＵコマンドを前記ＩＣカードに対して再送するように制御するステップと、を含むことを特徴とする。
【００１０】
また、上記課題を解決するため、本発明に係るサーバは、ネットワークにより接続されている端末を介してＩＣカードと通信を行うサーバであって、前記サーバは、前記端末と通信を行う通信部と、前記ＩＣカードの処理シーケンスを定義するスクリプトと、前記スクリプトに基づきＡＰＤＵコマンドを生成し、前記通信部に送信する処理制御部と、を有し、前記処理制御部が、リカバリ処理が前記スクリプトで定義されている第１のＡＰＤＵコマンドに対応する第１のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第１のＡＰＤＵコマンドに対して前記スクリプトで定義されたリカバリ処理を行い、リカバリ処理が前記スクリプトで定義されていない第２のＡＰＤＵコマンドに対応する第２のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第２のＡＰＤＵコマンドを前記ＩＣカードに対して再送するように制御することを特徴とする。
【発明の効果】
【００１１】
本発明では、ＩＣカードの発行、あるいは、ＩＣカード発行後のアプリケーション搭載・設定等の処理において、シーケンスの途中で処理が中断した場合でも、効率的なリカバリ処理が可能となる。また、本発明では、ＩＣカードの処理シーケンスをスクリプトで定義するため、プログラムコードで記述するよりも、可読性・メンテナンス性が高いという有利な効果をあわせて奏する。
【図面の簡単な説明】
【００１２】
【図１】ＩＣカードシステムの全体構成の一例を示す図である
【図２】ＩＣカードシステムの処理のシーケンス図である。
【図３】（ａ）はコマンドシーケンスの定義の一例を示し、（ｂ）はリカバリ処理の定義の一例を示す図である。
【発明を実施するための形態】
【００１３】
図１は本発明のＩＣカードシステムの全体構成の一例を示す図である。ＩＣカードシステム１００では、セキュアデバイス管理サーバ（以下、サーバと称する）１０は、運用者端末（以下、端末と称する）２０を介してＩＣカード３０と通信を行う。サーバ１０と端末２０とは、インターネット、ＬＡＮ等のネットワーク４０を介して接続されている。
【００１４】
サーバ１０は、処理制御部１１と、通信部１２と、スクリプト１３と、利用者パーソナライズ情報ＤＢ１４と、を有する。処理制御部１１は、処理の順番を制御する。また、処理制御部１１は、スクリプト１３を解釈し、ＩＣカード３０用のＡＰＤＵ（Application Protocol Data Unit）コマンドを生成する。また、処理制御部１１は、利用者パーソナライズ情報ＤＢ１４から利用者パーソナライズ情報を取得する。その他、処理制御部１１は、サーバ１０全体の制御を行う。通信部１２は、端末２０との通信を行う。スクリプト１３は、ＩＣカード３０用のＡＰＤＵコマンドを生成するための雛形である。利用者パーソナライズ情報ＤＢ１４は、ＩＣカード３０用のＡＰＤＵコマンドの一部に埋め込まれる利用者ＩＤ等の利用者に関連する情報を管理するデータベースである。
【００１５】
端末２０は、処理制御部２１と、通信部２２と、ＧＵＩ部２３と、リーダライタ部２４と、を有する。処理制御部２１は、端末２０全体の制御を行う。通信部２２は、サーバ１０との通信を行う。ＧＵＩ部２３は、運用者からの指示を受信し、運用者に対して処理結果を表示する。リーダライタ部２４は、通信部２２から受信したＡＰＤＵコマンドをＩＣカード３０に送信し、ＩＣカード３０からＡＰＤＵレスポンスを受信する。なお、リーダライタ部２４は、ＩＣカード発行機等の装置に組み込まれていてもよい。
【００１６】
ＩＣカード３０は、マルチアプリケーションシステムのＩＣカードであり、同一の又は異なるサービスプロバイダのサーバからダウンロードしたＮ個のカードアプリケーションＡＰ１〜ＡＰＮが格納されている。
【００１７】
以下、図２および図３を参照して、ＩＣカードシステム１００の処理手順を説明する。図２は、本発明のＩＣカードシステム１００の処理手順を示すシーケンス図である。
【００１８】
図３（ａ）は、コマンドシーケンスの定義の一例であり、ＩＣカードの発行処理、あるいは、カードアプリケーションの搭載・設定のためのコマンドシーケンスを定義するスクリプトである。図３（ａ）において、１６進の文字列は、カードに送信されるＡＰＤＵコマンドを示す。また、スクリプト中の記号として、「#」はコメント行を意味する。また、「Point n」はシーケンスにおける特定の箇所を意味し、図３（ｂ）に示すリカバリ処理の定義において利用される。また、「Recovery_type」は、処理制御部１１が、ＡＰＤＵレスポンスを受信しなかった場合に実施すべきリカバリのタイプを意味する。
【００１９】
図３（ｂ）は、リカバリ処理の定義の一例であり、図３（ａ）に示すコマンドシーケンスの定義のスクリプトにおいて「Recovery_type」で指定されるリカバリのタイプ毎に、リカバリ処理を定義する。１６進の文字列は、ＩＣカードに送信されるＡＰＤＵコマンドを示す。また、スクリプト中の記号として、「#」はコメント行を意味する。また、「Def」はリカバリ処理の定義の開始を意味し、「Def_end」はリカバリ処理の定義の終了を意味する。また、「Retry from Point n」は、図３（ａ）に示すコマンドシーケンスの定義のスクリプトにおける「Point n」で示される特定の箇所からシーケンスをリトライすることを意味する。また、「SW」はリカバリ処理を構成する最初のコマンドにおいて、ＩＣカードからの返却値が正常終了（9000h）以外もありうる場合に、その値を記載する。処理制御部１１は、ここに記述される値以外の返却値をＩＣカード３０から受信した場合、リカバリが正常に実施されていないと判断し、ＩＣカード３０に対するコマンド実行を中断し、エラーとして処理する。
【００２０】
ステップＳ１０１では、運用者が端末２０のＧＵＩ部２３に、ＡＰ１搭載のパーソナライズ情報の要求を入力する。パーソナライズ情報は、アプリケーション識別子（ＡＩＤ）およびカード識別子（ＣＩＤ）を含む。ＧＵＩ部２３は、ＡＰ１搭載のパーソナライズ情報の要求を処理制御部２１に送信する。処理制御部２１は、ＡＰ１搭載のパーソナライズ情報の要求を通信部２２に送信する。
【００２１】
ステップＳ１０２では、端末２０の通信部２２は、ＡＰ１搭載のパーソナライズ情報の要求をサーバ１０の通信部１２に送信する。通信部１２は、ＡＰ１搭載のパーソナライズ情報の要求を処理制御部１１に送信する。
【００２２】
ステップＳ１０３では、処理制御部１１は、ＡＩＤに関するスクリプトをスクリプト１３から取得する。
【００２３】
ステップＳ１０４では、処理制御部１１は、ＡＰ１搭載のパーソナライズ情報（ＡＩＤ、ＣＩＤ）を利用者パーソナライズ情報ＤＢ１４から取得する。
【００２４】
ステップＳ１０５では、処理制御部１１は、取得したスクリプトを解釈し、ＡＰＤＵコマンドを作成する。
【００２５】
ステップＳ１０６では、処理制御部１１は、ＡＰＤＵコマンドを通信部１２に送信する。サーバ１０の通信部１２は、ＡＰＤＵコマンドを端末２０の通信部２２に送信する。通信部２２は、ＡＰＤＵコマンドを処理制御部２１に送信する。処理制御部２１は、ＡＰＤＵコマンドをリーダライタ部２４に送信する。
【００２６】
ステップＳ１０７では、リーダライタ部２４は、ＡＰＤＵコマンドをＩＣカード３０に送信する。
【００２７】
ステップＳ１０８では、ＩＣカード３０は、ＡＰＤＵレスポンスをリーダライタ部２４に送信する。
【００２８】
ステップＳ１０９では、リーダライタ部２４は、ＡＰＤＵレスポンスを処理制御部２１に送信する。処理制御部２１は、ＡＰＤＵレスポンスを通信部２２に送信する。端末２０の通信部２２は、ＡＰＤＵレスポンスをサーバ１０の通信部１２に送信する。通信部１２は、ＡＰＤＵレスポンスを処理制御部１１に送信する。
【００２９】
ステップＳ１１０では、処理制御部１１は、所定の時間内にＡＰＤＵレスポンスを受信したか否かを判定する。
【００３０】
ステップＳ１０６〜ステップＳ１１０をＡＰＤＵコマンド数だけ繰り返す。具体的には、図３（ａ）に示すコマンドシーケンスの定義に記述されているスクリプトを上から順番に実行する。すなわち、はじめに、処理制御部１１は、１行目の「SELECT DF1」に相当するＡＰＤＵコマンド「00 A4 00 00 … 00 00」を実行する。処理制御部１１が、このＡＰＤＵコマンドに対するＡＰＤＵレスポンスを受信したら、３行目の「CREATE WEF1」に相当するＡＰＤＵコマンド「00 33 00 00 … 00 00」を実行する。この動作を、スクリプトに記述されている最後（２８行目）の「SET STATUS」に相当するＡＰＤＵコマンド「00 50 00 00 … 00 00」まで繰り返し実行する。
【００３１】
ステップＳ１１１では、処理制御部１１は、処理完了通知を通信部１２に送信する。サーバ１０の通信部１２は、処理完了通知を端末２０の通信部２２に送信する。通信部２２は、処理完了通知を処理制御部２１に送信する。処理制御部２１は、処理完了通知をＧＵＩ部２３に送信する。
【００３２】
ステップＳ１１２では、ＧＵＩ部２３は、処理完了通知を運用者に対して表示する。
【００３３】
次に、ステップＳ１０６〜ステップＳ１１０を繰り返している最中に通信断が発生した場合について説明する。すなわち、ステップＳ１１０において、処理制御部１１が、所定の時間内にＡＰＤＵレスポンスを受信しなかったと判定した場合について説明する。
【００３４】
第１に、リカバリ処理がスクリプトで定義されているＡＰＤＵコマンド（第１のＡＰＤＵコマンド）の送信中に、通信断が発生した場合を検討する。この場合、処理制御部２１は、第１のＡＰＤＵコマンドに対する第１のＡＰＤＵレスポンスを所定の時間内に受信しないので、第１のＡＰＤＵコマンドに対してスクリプトで定義されているリカバリ処理を行い、スクリプトのリカバリ定義で指定されている箇所からシーケンスをリトライする。
【００３５】
例えば、処理制御部１１が、図３（ａ）の９行目の「WRITE RECORD」に相当するＡＰＤＵコマンド「00 D2 00 00 … 00 00」に対するＡＰＤＵレスポンスを、所定の時間内に受信しなかった場合、図３（ａ）において、このＡＰＤＵコマンドのリカバリタイプが１であることが記載されているので（１０行目に「Recovery_type:1」が記載されているので）、図３（ｂ）のリカバリタイプ１の定義を参照する。すなわち、図３（ｂ）の２行目の「Def Recovery_type:1」を参照し、３行目の「DELETE WEF1」に相当するＡＰＤＵコマンド「00 22 00 00 … 00 00」を実行する。続けて、５行目の「Retry from Point 1」に従い、図３（ａ）の５行目の「Point 1」を参照し、６行目の「WRITE RECORD」に相当するＡＰＤＵコマンド「00 D2 00 00 … 00 00」からリトライする。
【００３６】
この場合、通信断が発生する前に、９行目の「WRITE RECORD」（２回目の「WRITE RECORD」）に相当するＡＰＤＵコマンド「00 D2 00 00 … 00 00」を実行したか否かに係わらず、「DELETE WEF1」に相当するＡＰＤＵコマンド「00 22 00 00 … 00 00」を実行することにより、ＷＥＦ１を削除している。それゆえ、改めて、６行目の「WRITE RECORD」（１回目の「WRITE RECORD」）に相当するＡＰＤＵコマンド「00 D2 00 00 … 00 00」からリトライするため、上述したような、同一の「WRITE RECORD」に相当するＡＰＤＵコマンドを実行したことにより、ＩＣカード３０が想定と異なる状態に遷移するといった問題が生じることはない。なお、ＷＥＦは作業用基礎ファイル（Working Elementary File）を意味する。
【００３７】
その他の例として、処理制御部１１が、図３（ａ）の２８行目の「SET STATUS」に相当するＡＰＤＵコマンドに対するＡＰＤＵレスポンスを所定の時間内に受信しなかった場合、図３（ａ）において、このＡＰＤＵコマンドのリカバリタイプが３であることが記載されているので（２９行目に「Recovery_type:3」が記載されているので）、図３（ｂ）のリカバリタイプ３の定義を参照する。すなわち、図３（ｂ）の１４行目の「Def Recovery_type:3」を参照し、１５行目の「Retry from Point 3」に従い、図３（ａ）の２７行目の「Point 3」を参照する。続けて、２８行目の「SET STATUS」に相当するＡＰＤＵコマンド「00 50 00 00 … 00 00」を実行する。
【００３８】
なお、図３（ｂ）の１６行目に「SW = 9000 or 6354」との記載があるため、ＩＣカード３０からのＡＰＤＵレスポンスが正常終了を表す「9000」ではなく「6354」であっても処理制御部１１は正常と判断する。また、処理制御部１１が、図３（ｂ）に記載されているＡＰＤＵレスポンスを、所定の時間内に受信しなかった場合は、ＩＣカード３０に対するコマンド実行を中断し、エラーとして処理する。
【００３９】
第２に、リカバリ処理がスクリプトで定義されていないＡＰＤＵコマンド（第２のＡＰＤＵコマンド）の送信中に、通信断が発生した場合を検討する。この場合、処理制御部２１は、第２のＡＰＤＵコマンドに対する第２のＡＰＤＵレスポンスを所定の時間内に受信しないので、同一の第２のＡＰＤＵコマンドからシーケンスをリトライする。
【００４０】
例えば、処理制御部１１が、図３（ａ）の３行目の「CREATE WEF1」に相当するＡＰＤＵコマンド「00 33 00 00 … 00 00」に対するＡＰＤＵレスポンスを、所定の時間内に受信しなかった場合、図３（ａ）において、このＡＰＤＵコマンドにはリカバリタイプが定義されていないため（「Recovery_type:n」との記載がないため）、同一のＡＰＤＵコマンドからシーケンスをリトライする。すなわち、３行目の「CREATE WEF1」に相当するＡＰＤＵコマンド「00 33 00 00 … 00 00」を再度実行する。
【００４１】
上述したように、第１のＡＰＤＵコマンドは、２度実行すると、ＩＣカードが想定と異なる状態に遷移するため、処理制御部１１が、第１のＡＰＤＵコマンドに対する第１のＡＰＤＵレスポンスを所定の時間内に受信しない場合、第１のＡＰＤＵコマンドに対してスクリプトで定義されたリカバリ処理を行う。一方、第２のＡＰＤＵコマンドは、２度実行しても、ＩＣカードは想定した状態に遷移するため、処理制御部１１が、第２のＡＰＤＵコマンドに対する第２のＡＰＤＵレスポンスを所定の時間内に受信しない場合、第２のＡＰＤＵコマンドを再度実行する、すなわち、第２のＡＰＤＵコマンドからシーケンスをリトライする。
【００４２】
以上のように、本発明によれば、ＩＣカードの発行や、ＩＣカード発行後のアプリケーション搭載・設定等の処理において、シーケンスの途中で処理が中断した場合でも、効率的なリカバリ処理が可能なＩＣカードシステムを提供することができる。
【符号の説明】
【００４３】
１０ サーバ
１１ 処理制御部
１２ 通信部
１３ スクリプト
１４ 利用者パーソナライズ情報ＤＢ
２０ 端末
２１ 処理制御部
２２ 通信部
２３ ＧＵＩ部
２４ リーダライタ部
３０ ＩＣカード
４０ ネットワーク
【特許請求の範囲】
【請求項１】
サーバが、前記サーバとネットワークにより接続されている端末を介してＩＣカードと通信を行うＩＣカードシステムであって、
前記サーバは、
前記端末と通信を行う通信部と、
前記ＩＣカードの処理シーケンスを定義するスクリプトと、
前記スクリプトに基づきＡＰＤＵコマンドを生成し、前記通信部に送信する処理制御部と、を有し、
前記端末は、
前記サーバと通信を行う通信部と、
前記ＡＰＤＵコマンドを前記ＩＣカードに送信し、前記ＡＰＤＵコマンドに対応するＡＰＤＵレスポンスを前記ＩＣカードから受信するリーダライタ部と、を有し、
前記処理制御部が、リカバリ処理が前記スクリプトで定義されている第１のＡＰＤＵコマンドに対応する第１のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第１のＡＰＤＵコマンドに対して前記スクリプトで定義されたリカバリ処理を行い、リカバリ処理が前記スクリプトで定義されていない第２のＡＰＤＵコマンドに対応する第２のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第２のＡＰＤＵコマンドを前記ＩＣカードに対して再送するように制御することを特徴とするＩＣカードシステム。
【請求項２】
サーバが、前記サーバとネットワークにより接続されている端末を介してＩＣカードと通信を行うＩＣカードシステムのリカバリ方法であって、
前記サーバにより、前記ＩＣカードの処理シーケンスを定義するスクリプトに基づきＡＰＤＵコマンドを生成し、前記端末に送信するステップと、
前記端末により、前記サーバから受信したＡＰＤＵコマンドを前記ＩＣカードに送信し、前記ＡＰＤＵコマンドに対応するＡＰＤＵレスポンスを前記ＩＣカードから受信するステップと、
前記サーバにより、リカバリ処理が前記スクリプトで定義されている第１のＡＰＤＵコマンドに対応する第１のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第１のＡＰＤＵコマンドに対して前記スクリプトで定義されたリカバリ処理を行うステップと、
前記サーバにより、リカバリ処理が前記スクリプトで定義されていない第２のＡＰＤＵコマンドに対応する第２のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第２のＡＰＤＵコマンドを前記ＩＣカードに対して再送するように制御するステップと、
を含むことを特徴とするＩＣカードシステムのリカバリ方法。
【請求項３】
ネットワークにより接続されている端末を介してＩＣカードと通信を行うサーバであって、
前記サーバは、
前記端末と通信を行う通信部と、
前記ＩＣカードの処理シーケンスを定義するスクリプトと、
前記スクリプトに基づきＡＰＤＵコマンドを生成し、前記通信部に送信する処理制御部と、を有し、
前記処理制御部が、リカバリ処理が前記スクリプトで定義されている第１のＡＰＤＵコマンドに対応する第１のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第１のＡＰＤＵコマンドに対して前記スクリプトで定義されたリカバリ処理を行い、リカバリ処理が前記スクリプトで定義されていない第２のＡＰＤＵコマンドに対応する第２のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第２のＡＰＤＵコマンドを前記ＩＣカードに対して再送するように制御することを特徴とするサーバ。
【請求項１】
サーバが、前記サーバとネットワークにより接続されている端末を介してＩＣカードと通信を行うＩＣカードシステムであって、
前記サーバは、
前記端末と通信を行う通信部と、
前記ＩＣカードの処理シーケンスを定義するスクリプトと、
前記スクリプトに基づきＡＰＤＵコマンドを生成し、前記通信部に送信する処理制御部と、を有し、
前記端末は、
前記サーバと通信を行う通信部と、
前記ＡＰＤＵコマンドを前記ＩＣカードに送信し、前記ＡＰＤＵコマンドに対応するＡＰＤＵレスポンスを前記ＩＣカードから受信するリーダライタ部と、を有し、
前記処理制御部が、リカバリ処理が前記スクリプトで定義されている第１のＡＰＤＵコマンドに対応する第１のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第１のＡＰＤＵコマンドに対して前記スクリプトで定義されたリカバリ処理を行い、リカバリ処理が前記スクリプトで定義されていない第２のＡＰＤＵコマンドに対応する第２のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第２のＡＰＤＵコマンドを前記ＩＣカードに対して再送するように制御することを特徴とするＩＣカードシステム。
【請求項２】
サーバが、前記サーバとネットワークにより接続されている端末を介してＩＣカードと通信を行うＩＣカードシステムのリカバリ方法であって、
前記サーバにより、前記ＩＣカードの処理シーケンスを定義するスクリプトに基づきＡＰＤＵコマンドを生成し、前記端末に送信するステップと、
前記端末により、前記サーバから受信したＡＰＤＵコマンドを前記ＩＣカードに送信し、前記ＡＰＤＵコマンドに対応するＡＰＤＵレスポンスを前記ＩＣカードから受信するステップと、
前記サーバにより、リカバリ処理が前記スクリプトで定義されている第１のＡＰＤＵコマンドに対応する第１のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第１のＡＰＤＵコマンドに対して前記スクリプトで定義されたリカバリ処理を行うステップと、
前記サーバにより、リカバリ処理が前記スクリプトで定義されていない第２のＡＰＤＵコマンドに対応する第２のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第２のＡＰＤＵコマンドを前記ＩＣカードに対して再送するように制御するステップと、
を含むことを特徴とするＩＣカードシステムのリカバリ方法。
【請求項３】
ネットワークにより接続されている端末を介してＩＣカードと通信を行うサーバであって、
前記サーバは、
前記端末と通信を行う通信部と、
前記ＩＣカードの処理シーケンスを定義するスクリプトと、
前記スクリプトに基づきＡＰＤＵコマンドを生成し、前記通信部に送信する処理制御部と、を有し、
前記処理制御部が、リカバリ処理が前記スクリプトで定義されている第１のＡＰＤＵコマンドに対応する第１のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第１のＡＰＤＵコマンドに対して前記スクリプトで定義されたリカバリ処理を行い、リカバリ処理が前記スクリプトで定義されていない第２のＡＰＤＵコマンドに対応する第２のＡＰＤＵレスポンスを所定の時間内に受信しない場合、前記第２のＡＰＤＵコマンドを前記ＩＣカードに対して再送するように制御することを特徴とするサーバ。
【図１】
【図２】
【図３】
【図２】
【図３】
【公開番号】特開２０１３−３６２８（Ｐ２０１３−３６２８Ａ）
【公開日】平成２５年１月７日（２０１３．１．７）
【国際特許分類】
【出願番号】特願２０１１−１３０９４５（Ｐ２０１１−１３０９４５）
【出願日】平成２３年６月１３日（２０１１．６．１３）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２５年１月７日（２０１３．１．７）
【国際特許分類】
【出願日】平成２３年６月１３日（２０１１．６．１３）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]