(57)【要約】【課題】アプリケーション間でデータを引渡すメッソドで、１バイトのデータした引渡せない場合であっても、１バイトを超える認証データ利用することができるＩＣカードを提供する。【解決手段】サーバアプレット２４には、クライアントアプレット２３がアクセスする共有オブジェクトであるＳＩＯ２４１と、ＳＩＯ２４１をクライアントアプレット２３に提供するためのオブジェクトであるＳＩＯサービスオブジェクト２４０を備え、ＳＩＯサービスオブジェクト２４０は、クライアントアプレット２３から１バイトづつ引渡されるＰＩＮを順に蓄積することでＰＩＮを組み立て、組み立てたＰＩＮを照合する。そして、ＰＩＮの照合に成功したときのみ、ＳＩＯ２４１へのアクセスを許可する。【選択図】図４
2008139923.tif 000002
【特許請求の範囲】
【請求項１】
プラットフォーム型オペレーティングシステム上に、共有アクセス可能なオブジェクトである共有オブジェクトを有するアプリケーション（サーバアプリケーション）が実装されたＩＣカードであって、前記サーバアプリケーションは、前記共有オブジェクトへアクセスするアプリケーション（クライアントアプリケーション）から前記共有オブジェクトへのアクセス要求が示されたとき、前記プラットフォーム型オペレーティングシステムを介し、前記クライアントアプリケーションから１バイト単位で引渡される認証データを引渡された順に蓄積することで前記認証データを組み立て、前記サーバアプリケーションが保持している参照データと組み立てた前記認証データを照合し、照合に成功した場合のみ、前記クライアントアプリケーションの前記共有オブジェクトへのアクセスを許可することを特徴とするＩＣカード。
【請求項２】
請求項１に記載のＩＣカードであって、前記サーバアプリケーションは、前記共有オブジェクトへのアクセスを許可する前記クライアントアプリケーションを特定するためのデータであるアプリケーション識別子を記憶し、更に、前記サーバアプリケーションは、前記認証データを１バイト単位で引渡す前記クライアントアプリケーションの前記アプリケーション識別子を確認し、前記共有オブジェクトへのアクセスが許可された前記アプリケーション識別子であったときのみ、前記アプリケーション識別子に関連付けて前記認証データを組み立てることを特徴とするＩＣカード。
【請求項３】
請求項２に記載のＩＣカードであって、前記サーバアプリケーションは、前記共有オブジェクトへのアクセスを許可する前記クライアントアプリケーションの前記アプリケーション識別子ごとに前記参照データを保持し、前記認証データを照合するときは、前記認証データの前記アプリケーション識別子に対応した前記参照データを用いることを特徴とするＩＣカード。
【請求項４】
プラットフォーム型オペレーティングシステム上に、共有アクセス可能なオブジェクトである共有オブジェクトを有するアプリケーション（サーバアプリケーション）が実装されたＩＣカードにおいて、前記サーバアプリケーションが有する前記共有オブジェクトへのアクセス管理方法であって、前記プラットフォーム型オペレーティングシステムを介して、前記共有オブジェクトへアクセスするアプリケーション（クライアントアプリケーション）が前記サーバアプリケーションへ前記共有オブジェクトへのアクセスを要求するステップａ）、前記クライアントアプリケーションから１バイト単位で引渡される認証データを引渡された順に蓄積することで前記認証データを組み立るステップｂ）、前記サーバアプリケーションが保持している参照データと組み立てた前記認証データを照合するステップｃ）、前記ステップｃ）で照合に成功した場合のみ、前記クライアントアプリケーションの前記共有オブジェクトへのアクセスを許可するステップｄ）を含むこと特徴とする共通オブジェクトへのアクセス管理方法。
【請求項５】
請求項４に記載の共有オブジェクトへのアクセス管理方法であって、前記サーバアプリケーションは、前記共有オブジェクトへのアクセスを許可する前記クライアントアプリケーションを特定するためのデータであるアプリケーション識別子を記憶し、前記ステップｂ）において、前記サーバアプリケーションは、前記認証データを１バイト単位で引渡す前記クライアントアプリケーションの前記アプリケーション識別子を確認し、前記共有オブジェクトへのアクセスが許可された前記アプリケーション識別子であったときのみ、前記アプリケーション識別子に関連付けて前記認証データを組み立てることを特徴とする共通オブジェクトへのアクセス管理方法。
【請求項６】
請求項５に記載の共有オブジェクトへのアクセス管理方法であって、前記サーバアプリケーションは、前記共有オブジェクトへのアクセスを許可する前記クライアントアプリケーションの前記識別データごとに前記参照データを保持し、前記ステップｃ）において、前記認証データを照合するときは、前記認証データの前記識別データに対応した前記参照データを用いることを特徴とする共通オブジェクトへのアクセス管理方法。
【請求項７】
プラットフォーム型オペレーティングシステム上に、共有アクセス可能なオブジェクトである共有オブジェクトを有するアプリケーション（サーバアプリケーション）が実装されたＩＣカードに、前記プラットフォーム型オペレーティングシステムを介して、前記共有オブジェクトへアクセスするアプリケーション（クライアントアプリケーション）が前記サーバアプリケーションへ前記共有オブジェクトへのアクセスを要求するステップａ）、前記クライアントアプリケーションから１バイト単位で引渡される認証データを引渡された順に蓄積することで前記認証データを組み立るステップｂ）、前記サーバアプリケーションが保持している参照データと組み立てた前記認証データを照合するステップｃ）、前記ステップｃ）で照合に成功した場合のみ、前記クライアントアプリケーションの前記共有オブジェクトへのアクセスを許可するステップｄ）を実行させるためのＩＣカードプログラム。
【請求項８】
請求項７に記載のＩＣカードプログラムであって、前記サーバアプリケーションは、前記共有オブジェクトへのアクセスを許可する前記クライアントアプリケーションを特定するためのデータであるアプリケーション識別子を記憶し、前記ステップｂ）において、前記サーバアプリケーションは、前記認証データを１バイト単位で引渡す前記クライアントアプリケーションの前記アプリケーション識別子を確認し、前記共有オブジェクトへのアクセスが許可された前記アプリケーション識別子であったときのみ、前記アプリケーション識別子に関連付けて前記認証データを組み立てることを特徴とするＩＣカードプログラム。
【請求項９】
請求項８に記載のＩＣカードプログラムであって、前記サーバアプリケーションは、前記共有オブジェクトへのアクセスを許可する前記クライアントアプリケーションの前記識別データごとに前記参照データを保持し、前記ステップｃ）において、前記認証データを照合するときは、前記認証データの前記識別データに対応した前記参照データを用いることを特徴とするＩＣカードプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プラットフォーム型オペレーティングシステムが実装されたＩＣカードに係り、更に詳しくは、ＩＣカードに実装されたアプリケーション間のアクセスの管理に関する。
【背景技術】
【０００２】
Ｊａｖａ（登録商標）などのプラットフォーム型オペレーティングシステムが実装され、複数のアプリケーションの追加・削除が可能なマルチアプリケーションＩＣカードにおいて、マルチアプリケーションＩＣカードに実装されたアプリケーション間のアクセスは禁止することが望ましいが、マルチアプリケーションＩＣカードの限られた資源を有効に使うため、共有アクセス可能なオブジェクトである共有オブジェクトをアプリケーションは備えていることがある。
【０００３】
アプリケーションに備えられた共有オブジェクトへのアクセスを限定したいとき、一般的に、共有オブジェクトへアクセス要求するアプリケーションのアプリケーション識別子（AID: Application Identifier）から、共有オブジェクトへのアクセスの許可/不許可が判定される。
【０００４】
また、共有オブジェクトへアクセス要求するアプリケーションのＡＩＤに加え、共有オブジェクトへアクセス要求するアプリケーションから引渡された認証データを照合することで、共有オブジェクトへのアクセスの許可/不許可を判定することもできる。
【０００５】
しかし、Ｊａｖａ（登録商標）のプラットフォーム型ＯＳが実装されている場合、共有オブジェクトへアクセスすために利用されるメッソッド、すなわち、getAppletShareableInterfaceObjectやgetShareableInterfaceObjectにおいては、ＡＩＤに加え、１バイトのパラメータを引渡すことしかできず、認証データとして１バイトのパラメータしか利用することができないためセキュリティ的に問題がある。
【０００６】
そこで、本出願人は、Ｊａｖａ（登録商標）のプラットフォーム型ＯＳが実装されているＩＣカードにおいて、認証データの照合に連続してリトライできる回数を制限することでセキュリティ性を向上させる発明として、特許文献１を既に出願している。
【特許文献１】特開２００２−７３１９６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、特許文献１で開示している発明を用い、共有オブジェクトへアクセスするときのセキュリティ性を向上させたとしても、照合する認証データは１バイトしか利用できない問題が残る。
【０００８】
そこで、本発明は、Ｊａｖａ（登録商標）のプラットフォーム型ＯＳが実装されているＩＣカードにおいて、アプリケーション間でデータを引渡すメッソドで、１バイトのデータした引渡せない場合であっても、１バイトを超える認証データ利用することができるＩＣカード、共有オブジェクトへのアクセス管理方法及びＩＣカードプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決する第１の発明は、プラットフォーム型オペレーティングシステム上に、共有アクセス可能なオブジェクトである共有オブジェクトを有するアプリケーション（サーバアプリケーション）が実装されたＩＣカードであって、前記サーバアプリケーションは、前記共有オブジェクトへアクセスするアプリケーション（クライアントアプリケーション）から前記共有オブジェクトへのアクセス要求が示されたとき、前記プラットフォーム型オペレーティングシステムを介し、前記クライアントアプリケーションから１バイト単位で引渡される認証データを引渡された順に蓄積することで前記認証データを組み立て、前記サーバアプリケーションが保持している参照データと組み立てた前記認証データを照合し、照合に成功した場合のみ、前記クライアントアプリケーションの前記共有オブジェクトへのアクセスを許可することを特徴とする。
【００１０】
更に、第２の発明は、第１の発明に記載のＩＣカードであって、前記サーバアプリケーションは、前記共有オブジェクトへのアクセスを許可する前記クライアントアプリケーションを特定するためのデータであるアプリケーション識別子を記憶し、更に、前記サーバアプリケーションは、前記認証データを１バイト単位で引渡す前記クライアントアプリケーションの前記アプリケーション識別子を確認し、前記共有オブジェクトへのアクセスが許可された前記アプリケーション識別子であったときのみ、前記アプリケーション識別子に関連付けて前記認証データを組み立てることを特徴とする。
【００１１】
更に、第３の発明は、第２の発明に記載のＩＣカードであって、前記サーバアプリケーションは、前記共有オブジェクトへのアクセスを許可する前記クライアントアプリケーションの前記アプリケーション識別子ごとに前記参照データを保持し、前記認証データを照合するときは、前記認証データの前記アプリケーション識別子に対応した前記参照データを用いることを特徴とする。
【００１２】
更に、第４の発明は、プラットフォーム型オペレーティングシステム上に、共有アクセス可能なオブジェクトである共有オブジェクトを有するアプリケーション（サーバアプリケーション）が実装されたＩＣカードにおいて、前記サーバアプリケーションが有する前記共有オブジェクトへのアクセス管理方法であって、前記プラットフォーム型オペレーティングシステムを介して、前記共有オブジェクトへアクセスするアプリケーション（クライアントアプリケーション）が前記サーバアプリケーションへ前記共有オブジェクトへのアクセスを要求するステップａ）、前記クライアントアプリケーションから１バイト単位で引渡される認証データを引渡された順に蓄積することで前記認証データを組み立るステップｂ）、前記サーバアプリケーションが保持している参照データと組み立てた前記認証データを照合するステップｃ）、前記ステップｃ）で照合に成功した場合のみ、前記クライアントアプリケーションの前記共有オブジェクトへのアクセスを許可するステップｄ）を含むこと特徴とする。
【００１３】
更に、第５の発明は、第４の発明に記載の共有オブジェクトへのアクセス管理方法であって、前記サーバアプリケーションは、前記共有オブジェクトへのアクセスを許可する前記クライアントアプリケーションを特定するためのデータであるアプリケーション識別子を記憶し、前記ステップｂ）において、前記サーバアプリケーションは、前記認証データを１バイト単位で引渡す前記クライアントアプリケーションの前記アプリケーション識別子を確認し、前記共有オブジェクトへのアクセスが許可された前記アプリケーション識別子であったときのみ、前記アプリケーション識別子に関連付けて前記認証データを組み立てることを特徴とする。
【００１４】
更に、第６の発明は、第５の発明に記載の共有オブジェクトへのアクセス管理方法であって、前記サーバアプリケーションは、前記共有オブジェクトへのアクセスを許可する前記クライアントアプリケーションの前記識別データごとに前記参照データを保持し、前記ステップｃ）において、前記認証データを照合するときは、前記認証データの前記識別データに対応した前記参照データを用いることを特徴とする。
【００１５】
更に、第７の発明は、プラットフォーム型オペレーティングシステム上に、共有アクセス可能なオブジェクトである共有オブジェクトを有するアプリケーション（サーバアプリケーション）が実装されたＩＣカードに、前記プラットフォーム型オペレーティングシステムを介して、前記共有オブジェクトへアクセスするアプリケーション（クライアントアプリケーション）が前記サーバアプリケーションへ前記共有オブジェクトへのアクセスを要求するステップａ）、前記クライアントアプリケーションから１バイト単位で引渡される認証データを引渡された順に蓄積することで前記認証データを組み立るステップｂ）、前記サーバアプリケーションが保持している参照データと組み立てた前記認証データを照合するステップｃ）、前記ステップｃ）で照合に成功した場合のみ、前記クライアントアプリケーションの前記共有オブジェクトへのアクセスを許可するステップｄ）を実行させるためのＩＣカードプログラムである。
【００１６】
更に、第８の発明は、第７の発明に記載のＩＣカードプログラムであって、前記サーバアプリケーションは、前記共有オブジェクトへのアクセスを許可する前記クライアントアプリケーションを特定するためのデータであるアプリケーション識別子を記憶し、前記ステップｂ）において、前記サーバアプリケーションは、前記認証データを１バイト単位で引渡す前記クライアントアプリケーションの前記アプリケーション識別子を確認し、前記共有オブジェクトへのアクセスが許可された前記アプリケーション識別子であったときのみ、前記アプリケーション識別子に関連付けて前記認証データを組み立てることを特徴とする。
【００１７】
更に、第９の発明は、第８の発明に記載のＩＣカードプログラムであって、前記サーバアプリケーションは、前記共有オブジェクトへのアクセスを許可する前記クライアントアプリケーションの前記識別データごとに前記参照データを保持し、前記ステップｃ）において、前記認証データを照合するときは、前記認証データの前記識別データに対応した前記参照データを用いることを特徴とする。
【発明の効果】
【００１８】
上述した本発明によれば、共有オブジェクトを有するサーバアプリケーションは、クライアントアプリケーションから１バイト単位で引渡される認証データを引渡された順に蓄積することで認証データを組み立てるため、共有オブジェクトへのアクセスを管理するときに、１バイトを超える認証データを利用できるようになる。
【００１９】
更に、アプリケーション識別子に関連付けて認証データを組み立てることで、複数のクライアントアプリケーションから共有オブジェクトへのアクセス要求があった場合でも対応を取ることができる。
【００２０】
更に、サーバアプリケーションがアプリケーション識別子ごとに参照データを保持することで、共有オブジェクトへのアクセス要求があった場合、クライアントアプリケーションごとに異なる参照データを用いることができる。
【発明を実施するための最良の形態】
【００２１】
ここから、共有オブジェクトを有するＩＣカードについて、図を参照しながら詳細に説明する。図１は、共有オブジェクトを有するＩＣカード１を説明する図である。
【００２２】
図１に示したＩＣカード１は、プラスチックカードにＩＣチップ２が実装された接触型ＩＣカードで、プラットフォーム型ＯＳとしてＪＣＲＥ（JCRE: Java Card Runtime Environment）が実装され、ＪＣＲＥで解釈実行されるＪａｖａ（登録商標）のコードで記述された複数のアプリケーションをＩＣカード１に追加・削除できる。
【００２３】
図２は、図１で示したＩＣカード１に実装されるＩＣチップ２の構成図で、図３は、ＩＣカード１に実装されるソフトウェアを説明する図である。
【００２４】
図２に示したようにＩＣカード１のＩＣチップ２には、演算機能およびＩＣチップ２が具備するデバイスを制御する機能を備えた中央演算装置２ａ（CPU：Central Processing Unit）、読み出し専用の不揮発性メモリ２ｃ（ROＭ：Read Only Memory、）、電気的に書換え可能な不揮発性メモリとしてＥＥＰＲＯＭ２ｄ（EEPROM：Electrically Erasable Programmable Read-Only Memoryの略）、揮発性メモリとしてランダムアクセスメモリ２ｂ（RAM：Random Access Memory）、および、外部の端末装置とデータ通信するためのＩ／Ｆ２ｅとを少なくとも備なえている。
【００２５】
本発明は、ＩＣカード１に実装されるＩＣチップ２の仕様をなんら限定するものではなく、ＩＣカード１の用途に適した仕様のＩＣチップ２を選択することができる。例えば、ＲＯＭ２ｃおよびＥＥＰＲＯＭ２ｄの容量については限定しないし、書換え可能な不揮発性メモリはフラッシュメモリ等であっても構わない。またＩＣチップ２は乱数を生成する乱数生成回路等の図示していない他のデバイスを備えていても構わない。
【００２６】
なお、図１においては、ＩＣカード１を接触ＩＣカードとして図示しているが、本発明は何らＩＣカード１の通信方式に依存するものではなく、無線でデータ通信する非接触ＩＣカード、または、接触データ通信と非接触データ通信の２つの通信機能を備えたデュアルインターフェースＩＣカードであってもよい。加えて、ＩＣカード１は、ＩＣチップ２の近辺を短冊状に切り取った形状をしているＳＩＭ（Subscriber Identity Module）であってもよい。
【００２７】
図３で示したように、ＩＣカード１の不揮発性メモリであるＲＯＭ２ｃ及びＥＥＰＲＯＭ２ｄには、ＩＣチップ２ごとの仕様差分を吸収するためのプログラムであるカードオペレーティングシステム２０（COS: Card Operating System）上に、Ｊａｖａ（登録商標）のコードの解釈・実行機能を備えたＪＣＲＥ２１が実装されている。
【００２８】
更に、ＩＣカード１の電気的に書換え可能な不揮発性メモリであるＥＥＰＲＯＭ２ｄには、アプリケーションとして、ＪＣＲＥ２１上で動作する複数のアプレット２２が実装されている。
【００２９】
ＩＣカード１に実装されたアプレット２２の少なくとも一つは、他のアプレット２２から共有アクセス可能なオブジェクトである共有オブジェクトを有している。共有オブジェクトを有するアプレット２２および共有オブジェクトにアクセスするアプレット２２は一つとは限らないが、便宜的に、共有オブジェクトにアクセスするアプレット２２をクライアントアプレットと、そして、共有アクセスを有するアプレット２２をサーバアプレットと呼ぶことにする。
【００３０】
図４は、クライアントアプレットとサーバアプレットを説明する図である。サーバアプレット２４には、クライアントアプレット２３がアクセスする共有オブジェクトであるＳＩＯ２４１（SIO: Shareable Interface Object）と、ＳＩＯ２４１をクライアントアプレット２３に提供するためのオブジェクトであるＳＩＯサービスオブジェクト２４０を備え、クライアントアプレット２３はＳＩＯサービスオブジェクト２４０を介してのみＳＩＯ２４１にアクセスできる。すなわち、ＳＩＯサービスオブジェクト２４０は、ＳＩＯ２４１へのアクセスに対するファイヤーウォールの役割を果たしている。
【００３１】
また、ＪＣＲＥ２１には、クライアントアプレット２３とＪＣＲＥ２１間でデータを受け渡すメッソドであるｇＡＳＩＯ (gASIO: getAppletShareableInterfaceObject)と、ＪＣＲＥ２１とサーバアプレット２４間で１バイトのデータを受け渡すメッソドであるｇＳＩＯ(gSIO: getShareableInterfaceObject)が、ＪＣＲＥ２１のフレームワークに備えられている。
【００３２】
ＳＩＯ２４１へのアクセスに対するファイヤーウォールの役割を果たすために、ＳＩＯサービスオブジェクト２４０は、ＳＩＯ２４１へアクセス要求するクライアントアプレット２３から送信される認証データを認証し、認証に成功したときのみ、ＳＩＯ２４１へのアクセスを許可する。
【００３３】
本実施の形態で認証データはＰＩＮで、クライアントアプレット２３は、サーバアプレット２４のＳＩＯ２４１へアクセス要求するとき、ｇＡＳＩＯ及びｇＳＩＯを利用して、ＰＩＮを１バイト単位でサーバアプレット２４に引渡し、サーバアプレット２４はクライアントアプレット２３から１バイトづつ引渡されるＰＩＮを順に蓄積することでＰＩＮを組み立て、組み立てたＰＩＮを照合する。
【００３４】
サーバアプレット２４のＳＩＯサービスオブジェクト２４０は、クライアントアプレット２３から引渡されるＰＩＮを照合するために、共有アクセスを許可するクライアントアプレットのＣ＿ＡＩＤに関連付けて、ＰＩＮと照合するためのデータである参照ＰＩＮを記憶したデータテーブルオブジェクト２４２を備えている。
【００３５】
図５は、サーバアプレット２４が有するデータテーブルオブジェクト２４２を説明する図である。図５のデータテーブルオブジェクト２４２には、共有が許可される３つのＣ＿ＡＩＤが記述され、それぞれのＣ＿ＡＩＤに関連付けて、参照ＰＩＮの長さと参照ＰＩＮが記憶されている。図５に従えば、Ｃ＿ＡＩＤが「0x 01 02 03 0A」のクライアントアプレット２３の参照ＰＩＮの長さは８バイトで、参照ＰＩＮは「0x11 22 33 44 55 66 77 88」である。
【００３６】
図６は、サーバアプレット２４のコードを説明するための図である。サーバアプレット２４には、少なくとも、クライアントアプレット２３がアクセスするＳＩＯ２４１と、ＳＩＯ２４１を提供するためのオブジェクトであるＳＩＯサービスオブジェクト２４０が定義されている。
【００３７】
ＳＩＯサービスオブジェクト２４０には、ｇＳＩＯが定義され、ＳＩＯ２４１へアクセス要求するクライアントを認証するメッソドである認証メッソド２４０ａが定義され、認証メッソド２４０ａで認証されたクライアントアプレット２３に対してのみ、ＳＩＯ２４１が提供される。
【００３８】
ここから、サーバクライアントが、共有オブジェクトへアクセス要求するクライアントアプレット２３を認証する手順について説明する。
【００３９】
図７は、クライアントアプレット２３からサーバアプレット２４へ１バイトのデータが引渡される動作を説明する図で、図８は、サーバアプレットのＳＩＯサービスオブジェクト２４０が、ＳＩＯ２４１へアクセス要求するクライアントアプレット２３を認証開始するまでのフロー図で、図９は、サーバクライアントのＳＩＯサービスオブジェクト２４０が、ＳＩＯ２４１へアクセス要求するクライアントアプレット２３を認証する手順を示したフロー図である。
【００４０】
まず、図７を参照しながら、クライアントアプレット２３からサーバアプレット２４へ１バイトのデータが引渡される動作を説明する。ｇＡＳＩＯのコードは、クライアントアプレット２３内に記述され、ｇＡＳＩＯの引数は、ＳＩＯ２４１を有するサーバアプレット２４のＡＩＤ（以下、S#AID: Server#AID）及び１バイトのパラメータで、ＳＩＯ２４１に対するアクセス要求をクライアントアプレット２３がサーバアプレット２４にするとき、ＪＣＲＥ２１のｇＡＳＩＯがクライアントアプレット２３によって呼出される。
【００４１】
ｇＳＩＯのコードはサーバアプレット２４のＳＩＯサービスオブジェクト２４０内に記述されており、ｇＳＩＯの引数は、ＳＩＯ２４１にアクセス要求したクライアントアプレット２３のＡＩＤ（以下、C#AID: Client#AID）及びｇＡＳＩＯの１バイトのパラメータで、ＪＣＲＥ２１のｇＡＳＩＯが呼出されると、ｇＡＳＩＯを呼出したクライアントアプレット２３のＣ＿ＡＩＤと、ｇＡＳＩＯのパラメータを含むｇＳＩＯが生成され、ＪＣＲＥ２１は、ｇＡＳＩＯのＳ＿ＡＩＤで特定されるサーバアプレット２４のｇＳＩＯを呼出す。
【００４２】
ＪＣＲＥ２１からサーバアプレット２４のｇＳＩＯが呼出されることで、サーバアプレット２４のＳＩＯサービスオブジェクト２４０には、Ｃ＿ＡＩＤと１バイトのパラメータが引渡され、サーバアプレット２４のＳＩＯサービスオブジェクト２４０は、Ｃ＿ＡＩＤと１バイトのパラメータに従い処理を行う。
【００４３】
次に、図８を参照しながら、サーバクライアントが、共有オブジェクトへアクセス要求するクライアントアプレット２３を認証開始する手順について説明する。
【００４４】
この手順の最初のステップＳ１は、ＪＣＲＥ２１からサーバクライアントのｇＳＩＯが呼出されるステップで、このステップでは、ＳＩＯ２４１へアクセス要求するクライアントアプレット２３のＣ＿ＡＩＤとパラメータが、ｇＡＳＩＯによりサーバクライアントのＳＩＯサービスオブジェクト２４０に引渡される。
【００４５】
次のステップＳ２は、ステップＳ１で引渡されたＣ＿ＡＩＤがデータテーブルオブジェクト２４２に登録されているか確認するステップである。このステップで、認証メッソッド２４０ａはデータテーブルオブジェクト２４２を参照し、受信したＣ＿ＡＩＤがデータテーブルオブジェクト２４２に登録されているか確認する。Ｃ＿ＡＩＤが登録されていればステップＳ３に進み、受信したＣ＿ＡＩＤがデータテーブルオブジェクト２４２に登録されていなければステップＳ６に進み、ステップＳ６ではＮｕｌｌを送信してこの手順は終了する。
【００４６】
ステップＳ３は、ステップＳ１で受信したパラメータが認証開始を示すパラメータであるか確認するステップである。ＳＩＯサービスオブジェクト２４０の認証メッソド２４０ａは、ステップＳ１で受信したパラメータを確認し、認証開始を示すパラメータ（例えば、０ｘＦＦ）であればステップＳ４に進み、認証開始を示すパラメータでなければステップＳ６に進み、ステップＳ６ではＮｕｌｌを送信してこの手順は終了する。
【００４７】
ステップＳ４は、クライアントアプレット２３から送信されるＰＩＮを格納するためのバッファであるＰＩＮ受信バッファを生成するステップである。このステップで認証メッソド２４０ａは、ステップＳ１で受信したＣ＿ＡＩＤで特定されるクライアントアプレット２３から１バイト単位で引渡されるＰＩＮを順に蓄積するためのＰＩＮ受信バッファを、ＩＣチップ２のＲＡＭ２ｂなどに生成する。
【００４８】
ステップＳ４の後に実行されるステップＳ５は、サーバアプレット２４のＳＩＯサービスオブジェクト２４０が、クライアントアプレット２３を認証する状態に遷移したことを示すオブジェクトをクライアントアプレット２３へＪＣＲＥ２１経由で返信するステップである。
【００４９】
クライアントアプレット２３を認証する状態に遷移したことを示すオブジェクトをクライアントアプレット２３へ返信した後、ＳＩＯサービスオブジェクト２４０はフラグを立てるなどして、ＳＩＯ２４１へアクセス要求するクライアントアプレット２３を認証する状態に遷移する。
【００５０】
このステップＳ５をもって、サーバアプレット２４に備えられたＳＩＯ２４１の認証メッソド２４０ａが、ＳＩＯ２４１へアクセス要求するクライアントアプレット２３を認証開始する手順は終了する。
【００５１】
次に図９を参照しながら、サーバアプレット２４に備えられたＳＩＯサービスオブジェクト２４０が、ＳＩＯ２４１へアクセス要求するクライアントアプレット２３を認証する手順について説明する。
【００５２】
この手順の最初のステップＳ１０は、ＪＣＲＥ２１からサーバクアプレット２４のｇＳＩＯが呼出されるステップで、このステップで、サーバアプレット２４のＳＩＯサービスオブジェクト２４０には、ＳＩＯ２４１へアクセス要求するクライアントアプレット２３のＣ＿ＡＩＤとパラメータが引渡される。
【００５３】
次のステップＳ１１は、受信したクライアントアプレット２３のＣ＿ＡＩＤがデータテーブルオブジェクト２４２に登録されているか確認するステップである。ＳＩＯサービスオブジェクト２４０の認証メッソド２４０ａは、データテーブルオブジェクト２４２を参照し、受信したＣ＿ＡＩＤがデータテーブルオブジェクト２４２に登録されていればステップＳＳ１３に進み、受信したＣ＿ＡＩＤがデータテーブルオブジェクト２４２に登録されていなければステップＳ１２に進み、ステップＳ１２ではＮｕｌｌを送信しステップＳ１０に戻る。
【００５４】
ステップＳ１３は、ステップＳ１０で引渡されたＣ＿ＡＩＤで特定されるクライアントアプレット２３から送信されるＰＩＮを順に蓄積するためのＰＩＮ受信バッファが生成されているか確認するステップである。認証メッソド２４０ａは、生成しているＰＩＮ受信バッファを確認し、ステップＳ１０で受信したＣ＿ＡＩＤ用のＰＩＮ受信バッファが生成されていればステップＳ１４に進み、されていなければステップＳ１２に進み、ステップＳ１２ではＮｕｌｌを送信してステップＳ１０に戻る。
【００５５】
ステップＳ１４は、ステップＳ１０で受信したパラメータがＰＩＮの送信完了を示すパラメータであるか確認するステップである。認証メッソド２４０ａは、ステップＳ１０で受信したパラメータを確認し、ＰＩＮの送信完了を示すパラメータ（例えば、０ｘＦＦ）であればステップＳ１７に進み、ＰＩＮの送信完了を示すパラメータでなければステップＳ１５に進む。
【００５６】
ステップＳ１５は、ステップＳ１０で受信したパラメータをＰＩＮ受信バッファに蓄積するステップである。ステップＳ１５が実行された後はステップＳ１６が実行され、ステップＳ１６では、ＡＣＫを示すオブジェクトをクライアントアプレット２３にＪＣＲＥ２１経由で返信し、ステップＳ１０に戻る。
【００５７】
図１０は、ＰＩＮ受信バッファに蓄積されるをＰＩＮを説明する図である。図１０は、Ｃ＿ＡＩＤが「0x 01 02 03 0A」であるクライアントアプレット２３用のＰＩＮ受信バッファの内容を説明する図である。
【００５８】
図８のステップＳ４でＰＩＮ受信バッファが生成された時点では、ＰＩＮ受信バッファの内容は「Ｎｕｌｌ」で、図９のステップＳ１５が最初に実行されると、ＰＩＮ受信バッファには「0x11」が蓄積され、ステップＳ１５が繰り返して８回実行されることで、ＰＩＮ受信バッファにＰＩＮのすべてが蓄積される。
【００５９】
ステップＳ１７は、ＰＩＮ受信バッファに蓄積されたＰＩＮと、ステップＳ１０で受信したＣ＿ＡＩＤに対応する参照ＰＩＮとを照合し、ＳＩＯ２４１へアクセス要求したクライアントアプレット２３を認証するステップである。
【００６０】
ＳＩＯサービスオブジェクト２４０の認証メッソドは、データテーブルオブジェクト２４２を参照することで、ステップＳ１０で引渡されたＣ＿ＡＩＤ用の参照ＰＩＮを取得し、取得した参照ＰＩＮとＰＩＮ受信バッファの内容を照合する。
【００６１】
ステップＳ１７で、取得した参照ＰＩＮとＰＩＮ受信バッファの内容が同一であるとき、すなわち、ＳＩＯ２４１へアクセス要求したクライアントアプレット２３の認証に成功したときはステップＳ１８に進みＳＩＯサービスオブジェクト２４０で定義されたＳＩＯ２４１がクライアントアプレット２３に提供され、この手順は終了する。
【００６２】
また、ステップＳ１７で、取得した参照ＰＩＮとＰＩＮ受信バッファの内容が異なるとき、すなわち、ＳＩＯ２４１へアクセス要求したクライアントアプレット２３の認証に失敗したときはステップＳ１９に進み、認証に失敗したことを示すオブジェクトがクライアントアプレット２３に返信し、この手順は終了する。
【００６３】
なお、本発明は、これまで説明した実施の形態に限定されることなく、種々の変形や変更が可能であって、それらも本発明の均等の範囲内である。例えば、サーバアプレット２４は複数のＳＩＯ２４１を備えていてもよい。
【００６４】
サーバアプレット２４が複数のＳＩＯ２４１を備えているとき、図８のステップＳ１が実行される前に、ｇＳＩＯのパラメータによって、サーバアプレット２４に備えられた複数のＳＩＯ２４１の中から、クライアントアプレット２３がアクセス要求するＳＩＯ２４１が指定される。
【００６５】
また、本実施の形態では、サーバアプレット２４がクライアントアプレット２３を認証するためにＰＩＮを利用しているが、サーバアプレット２４がクライアントアプレット２３を認証する方式はＰＩＮに限らず、如何なる方式を用いてもよい。
【図面の簡単な説明】
【００６６】
【図１】ＩＣカードを説明する図。
【図２】ＩＣカードに実装されるＩＣチップの構成図。
【図３】ＩＣカードに実装されるソフトウェアを説明する図。
【図４】クライアントアプレットとサーバアプレットを説明する図。
【図５】データテーブルオブジェクトを説明する図。
【図６】サーバアプレットのコードを説明するための図。
【図７】クライアントアプレットからサーバアプレットへ１バイトのデータが引渡される動作を説明する図。
【図８】クライアントアプレットを認証開始するまでのフロー図。
【図９】クライアントアプレットを認証する手順を示したフロー図。
【図１０】ＰＩＮ受信バッファに蓄積されるをＰＩＮを説明する図。
【符号の説明】
【００６７】
１  ＩＣカード
２  ＩＣチップ
２０  ＣＯＳ
２１  ＪＣＲＥ
２２  アプレット
２３  クライアントアプレット
２４  サーバアプレット
２４０  ＳＩＯサービスオブジェクト
２４１  ＳＩＯ
２４２  データテーブルオブジェクト
【図１】
2008139923.tif 000003
【図２】
2008139923.tif 000004
【図３】
2008139923.tif 000005
【図４】
2008139923.tif 000006
【図５】
2008139923.tif 000007
【図６】
2008139923.tif 000008
【図７】
2008139923.tif 000009
【図８】
2008139923.tif 000010
【図９】
2008139923.tif 000011
【図１０】
2008139923.tif 000012