JP2003196625A - Ｉｃカードプログラム及びｉｃカード - Google Patents

Abstract

(57)【要約】 【課題】 複数のアプリケーション間での共有アクセス
においてセキュリティ性の向上を図ることが可能なＩＣ
カードプログラム及びＩＣカードを提供する。 【解決手段】 複数のアプリケーションを搭載可能なＩ
Ｃカード１に格納され、共有オブジェクト５５１を含
み、他のクライアントアプリ５１，５２から共有オブジ
ェクト５５１へのアクセスを管理するためにＣＰＵ２０
を実行させるためのＩＣカードプログラムであって、ク
ライアントアプリ５１，５２から共有オブジェクト５５
１へのアクセスを許可するか否かを共有オブジェクトに
含まれる共有管理テーブル５５２に基づいて判定するア
クセス判定手順Ｓ２０３を備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、搭載される複数の
アプリケーション間におけるオブジェクトの共有を管理
するＩＣカードプログラム及びＩＣカードに関するもの
である。

【０００２】

【従来の技術】従来は、ＩＣカード（ＩＣカードとは、
ＩＳＯ等の標準規格のサイズに準拠したＩＣカード、Ｓ
ＩＭカードに限られず、また、外形形状、厚さにかかわ
らず、ポケットに入れられる程度のサイズを有するポケ
ット型で携帯可能な情報端末をいう。）上のアプリケー
ション間のアクセスはセキュリティ上問題があり、通常
実行環境（オペレーションシステムの一部であってアプ
リケーションを動かすためのサービスを提供する。以
下、オペレーションシステムを「ＯＳ」という。）によ
り不可能となっていた（ファイアウォール、後述する図
５参照）。しかし、複数アプリケーションを搭載したＩ
Ｃカードでは限られた資源を有効に使う必要があるた
め、機能やデータを共有することによって管理された環
境下での限定的なアクセス（共有アクセス）を許す場合
がある。

【０００３】例えば、サンマイクロシステムズ社のＪａ
ｖａＣａｒｄ（「ＪＡＶＡ」は登録商標）では、各アプ
リケーションを管理している実行環境（ＪａｖａＣａｒ
ｄの場合はＪＣＲＥ：Ｊａｖａ Ｃａｒｄ Ｒｕｎｔｉ
ｍｅ Ｅｎｖｉｒｏｎｍｅｎｔと呼ばれる。）を介して
特定のオブジェクトを他のアプリケーションに提供する
ことが可能である（以下、オブジェクトを提供するアプ
リケーションを「サーバアプリ」、提供を受けるアプリ
ケーションを「クライアントアプリ」と言う。）。一
方、実行環境によって、各アプリケーションは、互いに
直接アクセスできず、クライアントアプリがサーバアプ
リのオブジェクトを直接呼び出そうとしてもエラーとな
る（ファイアウォール）。なお、オブジェクトとは、デ
ータと、これに対する処理プログラムであって一又は複
数の関数の集合である機能とを一体化したモジュールで
ある。

【０００４】また、ＪａｖａＣａｒｄでは、アプリケー
ションを搭載する場合に、予め共有アクセスを要求する
と予測されるクライアントアプリのユニークなＩＤ（以
下、「ＡＩＤ」という。）と認証のためのパラメータ
（ＰＩＮ等）を対象となるサーバアプリにデータとして
与えておき、サーバアプリはこのデータによってクライ
アントが正当なアプリケーションかどうかを確認するこ
とが可能である（セキュリティ上問題ない場合は無制限
にアクセスを許してもよい）。

【０００５】

【発明が解決しようとする課題】しかし、カード発行後
に追加をされたクライアントアプリのＡＩＤを予めサー
バアプリに与えることはできず、発行後の追加や削除に
対応できない問題があった。また、追加されたクライア
ントアプリに対応するため、既に搭載されていたアプリ
ケーションを入れ直す場合には、このアプリケーション
とともに対応するデータを削除しなければならなかっ
た。更に、ＰＩＮ等の認証パラメータを何度も変更して
アクセスすることによって不正アクセスを許可してしま
う可能性があった。上記課題を解決するために、本出願
人は、「共有アクセス管理機能を備えた携帯可能な情報
処理装置」（特願２０００−２６８６７６、未公開）を
提案している。各サーバアプリは、どのクライアントア
プリに対してどのようなアクセスの許可を与えるかを判
断するための共有管理情報を有している。この共有管理
情報は追加、削除、交信ができるため、カード発行時に
想定していなかったアプリケーションの追加や削除に対
しても正しくアクセスの許可／不許可を管理でき、機能
やデータをアクセス可能／不可能にすることができる。

【０００６】しかし、例えば、ポイントアプリケーショ
ンを提供する会社及びキャッシュアプリケーションを提
供する会社が提携し、ポイントアプリケーションは、キ
ャッシュアプリケーションを認証し、ポイント加算機能
のオブジェクトがどの番地にあるかを示す参照を渡すこ
とによって、このオブジェクトをキャッシュアプリケー
ションに公開する。このキャッシュアプリケーションが
又貸しのような形でさらにこのオブジェクトを他社が提
供する他のアプリケーションに公開した場合には、この
アプリケーションからアクセスされるおそれがあり、ポ
イントがむやみに加算される等の弊害を生じる可能性が
あった。つまり、又貸しの形で次々とオブジェクトを公
開され、サーバアプリがアクセスを許可してないクライ
アントアプリのアクセスを許してしまうおそれがあり、
アプリケーション間においてセキュリティ上の問題が生
じる可能性があった。また、バグのために認証されてい
ないアプリケーションがサーバアプリにアクセスしてし
まうおそれがあり、同様にセキュリティ上の問題が生じ
る可能性があった。

【０００７】本発明の課題は、複数のアプリケーション
間での共有アクセスにおいてセキュリティ性の向上を図
ることが可能なＩＣカードプログラム及びＩＣカードを
提供する。

【０００８】

【課題を解決するための手段】本発明は、以下のような
解決手段により、前記課題を解決する。なお、理解を容
易にするために、本発明の実施形態に対応する符号を付
して説明するが、これに限定されるものではない。すな
わち、請求項１の発明は、複数のアプリケーションを搭
載可能なＩＣカード（１）に格納され、オブジェクト
（５５１）を含み、他のアプリケーション（５１，５
２）から前記オブジェクトへのアクセスを管理するため
に前記ＩＣカードのＣＰＵを実行させるＩＣカードプロ
グラムであって、前記他のアプリケーションから前記オ
ブジェクトへのアクセスを許可するか否かを前記オブジ
ェクトに含まれるアクセス条件情報（５５２）に基づい
て判定するアクセス判定手順（Ｓ２０３）を備えるこ
と、を特徴とするＩＣカードプログラム（５５）であ
る。

【０００９】請求項２の発明は、請求項１に記載のＩＣ
カードプログラムにおいて、前記他のアプリケーション
からの認証要求があった場合（Ｓ１０１，Ｓ１０２）
に、認証するか否かを判定する認証判定手順（Ｓ１０
３）を備え、前記アクセス判定手順は、前記認証判定手
順において認証された前記他のアプリケーションから前
記オブジェクトへのアクセスを許可すると判定するこ
と、を特徴とするＩＣカードプログラム（５５）であ
る。

【００１０】請求項３の発明は、請求項１又は請求項２
に記載のＩＣカードプログラムにおいて、前記オブジェ
クトのアクセス条件情報を書き換える、書き込む、又
は、削除する書換手順（Ｓ１０４）を備え、前記書換手
順は、前記認証判定手順において認証された場合に、前
記アクセス条件情報を書き換える、書き込む、又は、削
除すること、を特徴とするＩＣカードプログラム（５
５）である。

【００１１】請求項４の発明は、請求項１から請求項３
までのいずれか１項に記載のＩＣカードプログラムにお
いて、前記アクセス判定手順は、前記オブジェクトの処
理プログラムにおいて実行されること、を特徴とするＩ
Ｃカードプログラム（５５）である。

【００１２】請求項５の発明は、請求項１から請求項４
までのいずれか１項に記載のＩＣカードプログラムにお
いて、前記アクセス判定手順は、以前に前記他のアプリ
ケーションからのアクセスが前記アクセス判定手順にお
いて否と判定された回数が所定の回数以上である場合
に、否と判定すること、を特徴とするＩＣカードプログ
ラム（５５）である。

【００１３】請求項６の発明は、複数のアプリケーショ
ンを搭載可能なＩＣカードであって、少なくとも、請求
項１から請求項５までのいずれか１項に記載のＩＣカー
ドプログラム（５５）を記憶するプログラム記憶手段
（５０）を備えること、を特徴とするＩＣカード（１）
である。

【００１４】請求項７の発明は、複数のアプリケーショ
ンを記憶するアプリケーション記憶手段（５０）と、前
記アプリケーション記憶手段に記憶されている、一のア
プリケーション（５１，５２）から他のアプリケーショ
ン（５５）に含まれるオブジェクト（５５１）へのアク
セスを許可するか否かをこのオブジェクトに含まれるア
クセス条件情報（５５２）に基づいて判定するアクセス
判定手段（２３）と、を備えるＩＣカード（１）であ
る。

【００１５】請求項８の発明は、請求項７に記載のＩＣ
カードにおいて、前記アクセス判定手段は、以前に前記
一のアプリケーションから前記オブジェクトへのアクセ
スが前記アクセス判定手段によって否と判定された回数
が所定の回数以上である場合に、否と判定すること、を
特徴とするＩＣカード（１）である。

【００１６】

【発明の実施の形態】以下、図面等を参照しながら、本
発明の実施の形態について、更に詳しく説明する。 （実施形態）図１は、本発明によるＩＣカードの実施形
態を示すブロック図である。図１に示すように、ＩＣカ
ード１は、外部リーダライタ２との通信を制御するＩ／
Ｏインターフェイス１０、機器全体を制御するＣＰＵ２
０、情報を記憶する記憶手段であるＲＡＭ３０、ＲＯＭ
４０、ＥＥＰＲＯＭ５０等を備えるＪａｖａＣａｒｄ
等、インタプリタ言語の実行環境を搭載し、書き換え可
能な複数のアプリケーションを搭載するマルチアプリケ
ーションＩＣカード上に構築することができる。

【００１７】ＣＰＵ２０は、このＩＣカード１を統括制
御する中央処理装置であり、認証部２１、テーブル書込
部２２、アクセス判定部２３等を備えている。各部は、
ＣＰＵ２０がＥＥＰＲＯＭ５０等に格納されているアプ
リケーション等のプログラムを実行することによって実
現される。認証部２１は、共有オブジェクト５５１へア
クセスするための参照を求める認証要求があった場合
に、要求を行ったクライアントアプリのＡＩＤ、認証パ
ラメータ（ＰＩＮ）、アクセスの種別であるアクセス種
別等に基づいて、共有オブジェクト５５１の参照を渡す
か否か（クライアントアプリを認証するか否か）を判定
する。

【００１８】テーブル書込部２２は、認証部２１が認証
したクライアントアプリのＡＩＤを共有オブジェクト５
５１の共有管理テーブル５５２に許可状態として書き込
む、アクセス回数、不許可回数を加算して書き換える
等、共有管理テーブル５５２の要素の書き込み、書き換
え、削除等を行う（後述する図２参照）。アクセス判定
部２３は、クライアントアプリ５１，５２からサーバア
プリ５５のオブジェクト５５１へのアクセス要求があっ
た場合に、アクセスを許可するか否かを共有オブジェク
ト５５１に含まれる共有管理テーブル５５２に基づいて
判定する。

【００１９】ＲＡＭ３０は、揮発性メモリであり、ＣＰ
Ｕ２０がＯＳ、アプリケーション等の処理を行う作業領
域として使用される。ＲＯＭ４０は、不揮発性の読み出
し専用メモリであって、ＯＳ、実行環境等を格納してい
る。ＯＳは、ＩＣカードの用途によらず汎用的に使用で
きる基本ソフトウェアである。実行環境は、ＪＣＲＥ等
であって、ＯＳ及びアプリケーションの間に位置し（後
述する図５参照）、アプリケーションの選択、オブジェ
クトの共有の仲介等を行う。

【００２０】ＥＥＰＲＯＭ５０は、随時書き換え可能な
不揮発性メモリであり、クライアントアプリ５１，５
２、サーバアプリ５５等の複数のアプリケーション等を
格納している。また、ＥＥＰＲＯＭ５０は、ＯＳやアプ
リケーションの作業領域として使用される。各アプリケ
ーション５１，５２は、ＯＳの管理下において、ＣＰＵ
２０がＩＣカードの各種用途固有の処理を行うためのプ
ログラムである。

【００２１】クライアントアプリ５１は、サーバアプリ
５５の共有オブジェクト５５１への共有アクセスの認証
条件を備えるアプリケーションであって、ＣＰＵ２０に
よる処理において、共有オブジェクト５５１の認証要
求、呼び出し等を行う。クライアントアプリ５１は、例
えば、サーバアプリであるポイントアプリケーションの
ポイント加算機能を共有するキャッシュアプリケーショ
ンである。一方、クライアントアプリ５２は、共有オブ
ジェクト５５１への共有アクセスの認証条件を備えてい
ないアプリケーションである。

【００２２】サーバアプリ５５は、ＩＣカード１に搭載
されている他のアプリケーション５１，５２と共有可能
なオブジェクトである共有オブジェクト５５１とを含む
アプリケーションである。また、ＣＰＵ２０が実行する
ことによって認証部２１及びテーブル書換部２２が実現
されるプログラムと、認証に必要な情報等を含んでい
る。共有オブジェクト５５１は、サーバアプリ５５だけ
でなく、他のアプリケーションからも呼び出すことがで
きる、データ及び機能を一体化した共有可能なモジュー
ルである。共有オブジェクト５５１は、本来の機能であ
るポイント加算機能に、データとして共有管理テーブル
５５２と、このデータに対応する機能としてアクセス判
定プログラムとを備えている。

【００２３】アクセス判定プログラムは、ＣＰＵ２０が
処理を実行することによってアクセス判定部２３を実現
するプログラムであって、処理において、共有管理テー
ブル５５２を参照する。アクセス判定プログラムは、共
有オブジェクト５５１がクライアントアプリ５１，５２
に呼び出された場合に、ポイント加算機能の処理前に実
行される。

【００２４】図２は、共有管理テーブルを説明する概略
図である。共有管理テーブル５５２は、サーバアプリ５
５から共有オブジェクト５５１がどのクライアントアプ
リに対して公開され、アクセスが許可されているか等の
アクセス条件情報を記録し、共有アクセスを管理するた
めのテーブルであって、クライアントアプリ５１，５２
等のＡＩＤ、許可状態フラグＦＬＧ、不許可回数、アク
セス回数等を結びつけて格納している。ＡＩＤは、一の
クライアントアプリ５１，５２をＩＣカード１に格納さ
れた他のアプリケーションから識別するための符号であ
って、本実施形態においては、クライアントアプリ５
１，５２のＡＩＤは、それぞれ「００１」、「００２」
である。

【００２５】許可状態フラグＦＬＧは、クライアントア
プリ５１，５２について共有オブジェクト５５１への共
有アクセスを許可する状態であるか否かを示している。
サーバアプリ５５から共有オブジェクト５５１を公開し
た（共有アクセスが認証された）クライアントアプリ５
１については、「許可」となり、共有オブジェクト５５
１を公開していないクライアントアプリ５２等に対して
は、「不許可」又は「閉塞」となる。また、該当するＡ
ＩＤがないサーバアプリへのアクセスは、「不許可」と
なる。従って、サーバアプリ５５以外から共有オブジェ
クト５５１を公開したクライアントアプリ（例えば、ク
ライアントアプリ５１から共有オブジェクト５５１が公
開されたクライアントアプリ５２）であっても「不許
可」又は「閉塞」となる。「閉塞」は、共有アクセスの
認証を受け付けない状態を示す。なお、許可状態を「不
許可」へ書き換える代わりにＡＩＤごと削除してもよ
い。

【００２６】不許可回数は、アクセス判定部２３がそれ
ぞれのクライアントアプリ５１，５２から共有オブジェ
クト５５１への共有アクセスを許可しなかった回数であ
る。不許可回数が所定の回数（本実施形態では３回）に
達した場合には、許可状態が閉塞となる。アクセス回数
は、アクセスが可能な回数を示し、アクセスをする度に
回数が減算され、アクセス回数が０となった場合には、
許可状態が閉塞となる。例えば、クライアントアプリ５
１から共有オブジェクト５５１へ４回のアクセスを行っ
た場合には、閉塞となる。共有管理テーブル５５２は、
制限されたアクセス期間を示すアクセス期間等のアクセ
ス条件情報を含んでいてもよい。また、共有管理テーブ
ル５５２のサイズは、固定であっても、可変であっても
よく、その要素は、追加、更新、削除することができ
る。更に、リスト構造として実装していてもよい。

【００２７】図３は、クライアントアプリからサーバア
プリへ共有オブジェクトの公開を要求する共有オブジェ
クト要求処理を示すフローチャートであり、図５（ａ）
は、共有オブジェクト要求処理における共有管理テーブ
ルを説明する論理構造図であって、クライアントアプリ
５１から要求を行った場合を示している。Ｓ１００にお
いて、ＩＣカード１は、外部リーダライタ２と通信可能
な環境に設置され、クライアントアプリ５１（又はクラ
イアントアプリ５２）を実行するコマンドを外部リーダ
ライタ２から入力し、処理を開始する。Ｓ１０１におい
て、ＣＰＵ２０は、クライアントアプリ５１（又はクラ
イアントアプリ５２）を実行することによって、実行環
境にサーバアプリ５５の共有オブジェクト５５１へアク
セスするための参照を求める認証要求を行う［図５
（ａ）（１）］。

【００２８】Ｓ１０２において、ＣＰＵ２０は、実行環
境からサーバアプリ５５へクライアントアプリ５１（又
はクライアントアプリ５２）から認証要求がきているこ
とをＡＩＤ「００１」（又は「００２」）とともに伝え
る［図５（ａ）（２）］。Ｓ１０３において、認証部２
１は、要求を行っているクライアントアプリ５１（又は
クライアントアプリ５２）に参照を提供することが妥当
であるか否か、認証するか否かをＡＩＤ「００１」等に
基づいて判定する［図５（ａ）（３）］。否と判定した
場合（クライアントアプリ５２が認証要求を行った場
合）には、ＣＰＵ２０は、ｎｕｌｌ値を返す、エラーを
返す等、共有拒否を実行環境に伝え（Ｓ１１１）、同様
に実行環境からクライアントアプリ５２へ伝え（Ｓ１１
２）、ＣＰＵ２０は、クライアントアプリ５２の実行を
終了する（Ｓ１１３）。なお、ｎｕｌｌ値は、何もない
値であって、０，１，２等の数値でないため、結果を受
けたクライアントアプリ５２では、正しく番地を取得で
きなかったと認識する。

【００２９】一方、Ｓ１０３において、妥当と判定した
場合（クライアントアプリ５１が認証要求を行った場
合）には、テーブル書換部２２は、共有オブジェクト５
５１の共有管理テーブル５５２にクライアントアプリ５
１のＡＩＤを追加する［Ｓ１０４、図５（ａ）
（３）］。ＣＰＵ２０は、共有オブジェクトの参照
（例：１００番地）を実行環境に返し［Ｓ１０５、図５
（ａ）（４）］、実行環境からクライアントアプリ５１
へ共有オブジェクト５５１の参照を返す［Ｓ１０６、図
５（ａ）（５）］。Ｓ１０７において、ＣＰＵ２０は、
実行環境から得た参照の値（１００）をクライアントア
プリ５１の変数にセットし、共有オブジェクト要求処理
を終了する［Ｓ１０８、図５（ａ）（６）］。

【００３０】図４は、本発明によるＩＣカードプログラ
ムの実施形態を示すフローチャートであって、クライア
ントアプリから共有オブジェクトを呼び出し、その機能
を実行する呼び出し処理を示している。図５（ｂ）は、
呼び出し処理において共有管理テーブルを説明する論理
構造図であって、クライアントアプリ５１から呼び出し
をおこなった場合を示している。

【００３１】この呼び出し処理は、共有オブジェクト要
求処理の後に行われ、Ｓ２００において、クライアント
アプリ５１の変数に共有オブジェクト５５１の参照の値
（１００）がセットされ（図３、Ｓ１０７参照）、クラ
イアントアプリ５２の変数には、クライアントアプリ５
１から又貸しされた参照の値（１００）がセットされて
いる。

【００３２】Ｓ２０１において、ＣＰＵ２０は、クライ
アントアプリ５１（又はクライアントアプリ５２）を実
行し、共有オブジェクト５５１の参照を利用してサーバ
アプリ５５内の共有オブジェクト５５１の機能を呼び出
す［図５（ｂ）（７）］。Ｓ２０２において、アクセス
判定部２３は、共有オブジェクトの共有管理テーブル５
５２を呼び出したクライアントアプリ５１（又はクライ
アントアプリ５２）のＡＩＤを実行環境に問い合わせ、
このＡＩＤ「００１」（又は「００２」）を共有オブジ
ェクト５５１の共有管理テーブル５５２で参照し（Ｓ２
０２）、このＡＩＤ「００１」（又は「００２」）の許
可状態フラグＦＬＧが許可状態で登録されているか否か
を判定することによって、アクセスを許可するか否かを
判定する［Ｓ２０３、図５（ｂ）（８））。

【００３３】許可状態でない場合（ＡＩＤ「００２」の
場合）には、ＣＰＵ２０は、エラーをクライアントアプ
リ５２へ返す、不許可回数をカウントする等の拒否処理
を行い、クライアントアプリ５２の処理へ戻る（Ｓ２０
６）。一方、許可状態である場合（ＡＩＤ「００１」の
場合）には、ＣＰＵ２０は、共有オブジェクト５５１の
ポイント加算機能を実行してその結果をクライアントア
プリ５１へ返す。テーブル書込部２２は、アクセス回数
を減算して書き込み、ＣＰＵ２０は、クライアントアプ
リ５１の処理へ戻り、サーバアプリ５５の処理を終了す
る（Ｓ２０５）。

【００３４】このように、本実施形態によれば、ＩＣカ
ード１は、アクセス判定部２３を備え、共有オブジェク
ト５５１の共有管理テーブル５５２に基づいて、アクセ
スを許可するか否かを判定するため、例えば、サーバア
プリ５５に認証されたクライアントアプリ５１から参照
を又貸しの形で公開されたクライアントアプリ５２から
共有オブジェクト５５１へのアクセスを防止することに
よって、アクセスを許可していないクライアントアプリ
５２のアクセスを防止し、アプリケーション間における
セキュリティ性を向上することが可能となった。

【００３５】また、認証されていないアプリケーション
から他のアプリケーションに含まれる共有オブジェクト
５５１へのバグによるアクセスを防止することが可能と
なった。更に、アクセス判定部２３は、共有管理テーブ
ル５５２の不許可回数が所定の回数、制限回数が零とな
っている場合には、そのクライアントアプリ５２から共
有オブジェクト５５１へのアクセスを許可しないため、
無制限のアクセス試行を許可せず、より一層のセキュリ
ティ性の向上を図るとともに、アクセスの回数を制限
し、利便性の向上を図ることが可能となった。

【００３６】（変形形態）以上説明した実施形態に限定
されることなく、種々の変形や変更が可能であって、そ
れらも本発明の均等の範囲内である。例えば、ＥＥＰＲ
ＯＭ５０は、サーバアプリ５５におけるオブジェクト５
５１以外の部分に判定プログラムを記憶し、ＣＰＵ２０
がこれを実行することによってアクセス判定部２３を実
現してもよい。また、ＥＥＰＲＯＭ５０は、共有管理テ
ーブル５５２に、アクセス種別等、様々なアクセス条件
情報を格納していてもよい。

【００３７】ＩＣカード１は、認証部２１を備えず、認
証要求のあったすべてのクライアントアプリにオブジェ
クト５５１の参照を返し、認証による共有管理テーブル
５５２へのＡＩＤの追加登録等をせずに、予め共有管理
テーブル５５２にＡＩＤ、許可状態等を登録しておき、
共有アクセスを管理してもよい。

【００３８】共有管理テーブル５５２は、ＡＩＤのみを
格納し、テーブル書換部２２は、共有管理テーブル５５
２に認証部２１によって認証されたクライアントアプリ
５１のＡＩＤ「００１」を書き込み、アクセス判定部２
３は、この登録されたＡＩＤに基づいて判定を行っても
よい。少なくともアクセス条件情報として、アクセスを
許可するクライアントアプリを許可しないクライアント
アプリから区別できる情報であればよい。

【００３９】ＲＡＭ３０又はＥＥＰＲＯＭ５０が共有管
理テーブル５５２を格納し、アクセス判定プログラムが
ＲＯＭ４０に格納されている等、機能からデータが呼び
出せれば、オブジェクトのデータと機能が分かれて記憶
されていてもよい。

【００４０】共有オブジェクト５５１を含むアプリケー
ションをサーバアプリ５５、共有オブジェクト５５１へ
共有アクセスを要求するアプリケーションをクライアン
トアプリ５１，５２としたが、クライアントアプリ５
１，５２と同様に共有オブジェクト５５１を含むアプリ
ケーションが他のアプリケーションへ共有アクセスを要
求してもよい。

【００４１】共有オブジェクト５５１は、ＣＰＵ２０が
実行することによって認証部２１及びテーブル書換部２
２が実現されるプログラムと、認証に必要な情報等を含
んでいてもよい。

【００４２】

【発明の効果】以上詳しく説明したように、本発明によ
れば、以下のような効果を得ることが可能となった。 （１）オブジェクトに含まれるアクセス条件情報に基づ
いてオブジェクトへのアクセスを許可するか否かを判定
することによって、アクセスを許可していないアプリケ
ーションからのアクセスを防止し、アプリケーション間
におけるセキュリティ性の向上を図る。 （２）所定の回数以上アクセスが否と判定されたアプリ
ケーションからのアクセスを否と判定することによっ
て、より一層のセキュリティ性の向上を図る。

【図面の簡単な説明】

【図１】本発明によるＩＣカードの実施形態を示すブロ
ック図である。

【図２】共有管理テーブルを説明する概略図である。

【図３】共有オブジェクト要求処理を示すフローチャー
トである。

【図４】本発明によるＩＣカードプログラムの実施形態
を示すフローチャートである。

【図５】共有オブジェクト要求処理及び呼び出し処理に
おける共有管理テーブルを説明する論理構造図である。

【符号の説明】

１ ＩＣカード ２ リーダライタ １０ Ｉ／Ｏインターフェイス ２０ ＣＰＵ ２１ 認証部 ２２ テーブル書換部 ２３ アクセス判定部 ３０ ＲＡＭ ４０ ＲＯＭ ５０ ＥＥＰＲＯＭ ５１，５２ クライアントアプリ ５５ サーバアプリ ５５１ 共有オブジェクト ５５２ 共有管理テーブル

Claims (8)

【特許請求の範囲】
1. 【請求項１】 複数のアプリケーションを搭載可能なＩ
   Ｃカードに格納され、オブジェクトを含み、他のアプリ
   ケーションから前記オブジェクトへのアクセスを管理す
   るために前記ＩＣカードのＣＰＵを実行させるＩＣカー
   ドプログラムであって、 前記他のアプリケーションから前記オブジェクトへのア
   クセスを許可するか否かを前記オブジェクトに含まれる
   アクセス条件情報に基づいて判定するアクセス判定手順
   を備えること、 を特徴とするＩＣカードプログラム。
2. 【請求項２】 請求項１に記載のＩＣカードプログラム
   において、 前記他のアプリケーションからの認証要求があった場合
   に、認証するか否かを判定する認証判定手順を備え、 前記アクセス判定手順は、前記認証判定手順において認
   証された前記他のアプリケーションから前記オブジェク
   トへのアクセスを許可すると判定すること、を特徴とす
   るＩＣカードプログラム。
3. 【請求項３】 請求項１又は請求項２に記載のＩＣカー
   ドプログラムにおいて、 前記オブジェクトのアクセス条件情報を書き換える、書
   き込む、又は、削除する書換手順を備え、 前記書換手順は、前記認証判定手順において認証された
   場合に、前記アクセス条件情報を書き換える、書き込
   む、又は、削除すること、 を特徴とするＩＣカードプログラム。
4. 【請求項４】 請求項１から請求項３までのいずれか１
   項に記載のＩＣカードプログラムにおいて、 前記アクセス判定手順は、前記オブジェクトの処理プロ
   グラムにおいて実行されること、 を特徴とするＩＣカードプログラム。
5. 【請求項５】 請求項１から請求項４までのいずれか１
   項に記載のＩＣカードプログラムにおいて、 前記アクセス判定手順は、以前に前記他のアプリケーシ
   ョンからのアクセスが前記アクセス判定手順において否
   と判定された回数が所定の回数以上である場合に、否と
   判定すること、 を特徴とするＩＣカードプログラム。
6. 【請求項６】 複数のアプリケーションを搭載可能なＩ
   Ｃカードであって、少なくとも、請求項１から請求項５
   までのいずれか１項に記載のＩＣカードプログラムを記
   憶しているプログラム記憶手段を備えること、 を特徴とするＩＣカード。
7. 【請求項７】 複数のアプリケーションを記憶するアプ
   リケーション記憶手段と、 前記アプリケーション記憶手段に記憶されている、一の
   アプリケーションから他のアプリケーションに含まれる
   オブジェクトへのアクセスを許可するか否かをこのオブ
   ジェクトに含まれるアクセス条件情報に基づいて判定す
   るアクセス判定手段と、 を備えるＩＣカード。
8. 【請求項８】 請求項７に記載のＩＣカードにおいて、 前記アクセス判定手段は、以前に前記一のアプリケーシ
   ョンから前記オブジェクトへのアクセスが前記アクセス
   判定手段によって否と判定された回数が所定の回数以上
   である場合に、否と判定すること、 を特徴とするＩＣカード。