JP4548758B2 - 共有アクセス管理機能を備えた携帯可能な情報処理装置 - Google Patents
共有アクセス管理機能を備えた携帯可能な情報処理装置 Download PDFInfo
- Publication number
- JP4548758B2 JP4548758B2 JP2000268676A JP2000268676A JP4548758B2 JP 4548758 B2 JP4548758 B2 JP 4548758B2 JP 2000268676 A JP2000268676 A JP 2000268676A JP 2000268676 A JP2000268676 A JP 2000268676A JP 4548758 B2 JP4548758 B2 JP 4548758B2
- Authority
- JP
- Japan
- Prior art keywords
- application
- access
- management information
- authentication
- shared
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 230000010365 information processing Effects 0.000 title claims description 10
- 238000012217 deletion Methods 0.000 claims description 16
- 230000037430 deletion Effects 0.000 claims description 16
- 238000007726 management method Methods 0.000 description 86
- 230000006870 function Effects 0.000 description 33
- 238000010586 diagram Methods 0.000 description 29
- 238000000034 method Methods 0.000 description 16
- 102000005591 NIMA-Interacting Peptidylprolyl Isomerase Human genes 0.000 description 11
- 108010059419 NIMA-Interacting Peptidylprolyl Isomerase Proteins 0.000 description 11
- 238000012545 processing Methods 0.000 description 11
- MOVRNJGDXREIBM-UHFFFAOYSA-N aid-1 Chemical compound O=C1NC(=O)C(C)=CN1C1OC(COP(O)(=O)OC2C(OC(C2)N2C3=C(C(NC(N)=N3)=O)N=C2)COP(O)(=O)OC2C(OC(C2)N2C3=C(C(NC(N)=N3)=O)N=C2)COP(O)(=O)OC2C(OC(C2)N2C3=C(C(NC(N)=N3)=O)N=C2)COP(O)(=O)OC2C(OC(C2)N2C(NC(=O)C(C)=C2)=O)COP(O)(=O)OC2C(OC(C2)N2C3=C(C(NC(N)=N3)=O)N=C2)COP(O)(=O)OC2C(OC(C2)N2C3=C(C(NC(N)=N3)=O)N=C2)COP(O)(=O)OC2C(OC(C2)N2C3=C(C(NC(N)=N3)=O)N=C2)COP(O)(=O)OC2C(OC(C2)N2C(NC(=O)C(C)=C2)=O)COP(O)(=O)OC2C(OC(C2)N2C3=C(C(NC(N)=N3)=O)N=C2)COP(O)(=O)OC2C(OC(C2)N2C3=C(C(NC(N)=N3)=O)N=C2)COP(O)(=O)OC2C(OC(C2)N2C3=C(C(NC(N)=N3)=O)N=C2)COP(O)(=O)OC2C(OC(C2)N2C(NC(=O)C(C)=C2)=O)COP(O)(=O)OC2C(OC(C2)N2C3=C(C(NC(N)=N3)=O)N=C2)COP(O)(=O)OC2C(OC(C2)N2C3=C(C(NC(N)=N3)=O)N=C2)COP(O)(=O)OC2C(OC(C2)N2C3=C(C(NC(N)=N3)=O)N=C2)CO)C(O)C1 MOVRNJGDXREIBM-UHFFFAOYSA-N 0.000 description 4
- 238000013475 authorization Methods 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Landscapes
- Credit Cards Or The Like (AREA)
- Storage Device Security (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は書き換え可能な複数のアプリケーションを搭載可能な携帯可能情報処理装置（例えば、ＩＣカード）に係り、特にアプリケーション間のアクセスの管理に関するものである。
【０００２】
【従来の技術】
ＩＣカード上のアプリケーション間のアクセスはセキュリティ上問題があり、通常、ＯＳ等により不可能となっている（ファイアーウォール）。しかし、複数のアプリケーションを搭載したＩＣカードでは限られた資源を有効に使うため、機能やデータの共有を目的として、お互いに管理された環境下での限定的なアクセス（共有アクセス）を許す必要がある。さらに各アプリケーションは任意のタイミングで追加、削除されるため、管理方法もそれに対応する必要がある。この共有アクセスについて以下に説明するが、ここでは、共有アクセスを要求する側をクライアントアプリケーション、共有アクセスを許可し、機能や情報を提供する側をサーバーアプリケーションと呼ぶことにする。
【０００３】
従来、ＩＣカードにアプリケーションを搭載する場合に、予め共有アクセスを要求されると予測される他のアプリケーションの情報（ＩＤ）と認証のためのパラメータ（ＰＩＮ：Ｐｅｒｓｏｎａｌ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ）等を各アプリケーションにデータとして与えておき、アプリケーションが他のアプリケーションにアクセスしたい場合、対象となるアプリケーションに対して自分のアプリケーションのＩＤと引き数となる認証パラメータ（ＰＩＮ等）を渡す。アクセスを要求されたサーバーアプリケーション側では渡されたアプリケーションＩＤと認証パラメータを予め自分が知っているデータ（アプリケーションＩＤと認証パラメータの組）と比較し、一致／不一致によってアクセス許可／不許可を判定する。他のアプリケーションに関する情報（アプリケーションＩＤと認証パラメータの組）を追加する場合には、アプリケーションのプログラムを新しく作成し、ＩＣカードに再びインストールしなおす手順により行う。
【０００４】
【発明が解決しようとする課題】
このような従来のＩＣカードにおける共有アクセス管理は、次のような問題があった。
▲１▼自分以外のアプリケーションの情報はカード発行時に確定してしまうため、想定しなかったアプリケーションの追加や削除に対して正しく共有アクセスの許可／不許可を管理できなかった。従来では、後から追加されたアプリケーションには「その他の場合」として対応し、限定的に使用を認めることができるようにしている。
▲２▼後から作成されたアプリケーションに対応するために、既存のアプリケーションを入れなおすと、特にアプリケーションとデータが一体になって管理されている仕組みのＩＣカードの場合に、そのアプリケーションに対応したデータも一緒に消えてしまう場合がある。
▲３▼認証パラメータ（ＰＩＮ）を変更して何度もアクセスを試す等、不正なアプリケーションが不正な共有アクセス権を取得できてしまう可能性があった。
【０００５】
本発明は上記課題を解決するためのもので、カード発行後のアプリケーションの追加や削除に対応できるようにするとともに、不正な共有アクセスや共有管理情報への不正なアクセスを監視してアプリケーションに対してアクセスを閉塞することで、セキュリティを高めるようにすることを目的とする。
【０００６】
【課題を解決するための手段】
本発明は、書き換え可能な複数のアプリケーションを搭載可能で、各アプリケーション間での共有アクセスが可能であり、各アプリケーション（サーバーアプリケーション）が共有管理情報を有し、他のアプリケーション（クライアントアプリケーション）からのアクセス要求があったとき共有管理情報に基づいてアクセスの許可／不許可を判断する共有アクセス管理機能を備えた携帯可能な情報処理装置において、前記共有管理情報が、アプリケーション管理情報、アクセス管理情報、認証管理情報からなることを特徴とする。
また、本発明は、前記アプリケーション管理情報がクライアントアプリケーションを特定するためのＩＤごとのアクセス種別、前記ＩＤとアクセス種別に対する許可状態を示す情報、アクセス種別ごとの認証に失敗した要求回数からなることを特徴とする。
また、本発明は、前記アクセス管理情報が、アクセス種別ごとの認証レベル、アクセスしたクライアントアプリケーションに返す返却値からなることを特徴する。
また、本発明は、前記認証管理情報が、認証レベルに応じたアクセス認証条件と追加削除認証条件からなることを特徴とする。
【０００７】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を、形態可能な情報処理装置としてＩＣカードを例にとって説明する。
（第１の実施例）
図１はＩＣカードに搭載される各アプリケーションが持つ共有管理情報を説明する図である。共有管理情報はアプリケーション管理情報（図１（ａ））、アクセス管理情報（図１（ｂ））、認証管理情報（図１（ｃ））からなっている。
アプリケーション管理情報は、クライアントアプリケーションのＩＤ（ＡＩＤ）、アクセス種別（ＴＹＰＥ）、許可状態、要求回数からなり、クライアントアプリケーションからの共有アクセスを管理し、各アプリケーションが個々に所有するが、共有アクセス機能を提供しないアプリケーションは持たなくてもよい。その場合は、どのアプリケーションからの共有アクセス要求も受けつけないことになる。
【０００８】
アプリケーションＩＤ（ＡＩＤ）はクライアントアプリケーションを特定するための少なくともＩＣカード内でユニークな番号である。
アクセス種別（ＴＹＰＥ）はそのアプリケーションに与えるアクセスの種別で共有するデータや関数、オブジェクト（データと機能を一まとめにした単位）や、それらの集合を表す番号を指定するか、あるいは直接アドレスやポインタ、関数名を指定するようにしても良い。
【０００９】
許可状態はあるアプリケーションＩＤとアクセス種別に対するアクセスの許可状態を表し、最低限、許可／不許可／閉塞を表せるものとする。その他にアクセス速度を速くするために、一度認証が成功したら、その後認証をしなくても良い「常時許可」や回数や期限を限定した「一時許可」等の状態を設けるようにしても良い。閉塞状態では、後述するように、共有アクセスの認証自体を受け付けない。
要求回数はアクセス種別の認証に失敗した回数、およびアプリケーション管理情報への追加／削除要求の認証失敗の回数をカウントする。なお、追加と削除について両者を分けてカウントできるように項目を追加するようにしても良い。
【００１０】
アクセス管理情報はアクセス種別、認証レベル、返却値からなる。認証レベルはその共有アクセス時に必要な認証のレベルを示す番号である。返却値はクライアントアプリケーションに返却する共有アクセスのための参照値で関数名、変数名、関数へのポインタ、変数へのポインタ、オブジェクトへの参照、実アドレス、値（変数への値そのもの）等、あるいはそれらの集合である。
【００１１】
認証管理情報は認証ベルとアクセス認証条件（ＰＩＮ１）、追加／削除認証条件（追加／削除のために予め有しているＰＩＮ２との照合）からなる。ある認証レベルの共有アクセスの要求があった場合、それに対応したアクセス認証条件（予め保持しているＰＩＮ２との比較）を満たした場合に、共有アクセスが許される。
【００１２】
アプリケーション管理情報はアプリケーション名とアクセス種別の組単位で追加／削除可能とし、その際、図１（ｂ）に示すように、アクセス種別に対応する認証レベルが設定されており、その認証レベルに対応した追加／削除認証条件を満たすことを条件とするように、図１（ｃ）のように、レベル毎に異なるＰＩＮを用意する。
【００１３】
次にアプリケーション管理情報の追加／削除の手順について説明する。
▲１▼クライアントアプリケーション、または端末側から、追加（削除）するアプリケーションＩＤとアクセス種別、認証パラメータ（ＰＩＮ）をサーバーアプリケーションに渡す。
▲２▼サーバーアプリケーションはアクセス種別に対応した認証条件を検索し、認証処理（ＰＩＮの照合等）をする。認証に成功したら、自分が持つアプリケーション管理情報にアプリケーションＩＤとアクセス種別と許可状態（許可）を追加する。
▲３▼不正なアプリケーションや外部からの不正アクセスを防ぐため、認証に失敗した場合は要求回数のカウントを１つ増し、特定の回数に達したら許可状態を「閉塞」し、それ以降、アプリケーションＩＤとアクセス種別の追加、削除要求を閉塞する。閉塞解除は行えないか特定の認証を必要とするようにする。
【００１４】
次に共有アクセス管理の手順について説明する。
▲１▼クライアントアプリケーションから直接、またはＯＳを通じてデータや処理にアクセス要求が発生する。
▲２▼サーバーアプリケーションは共有管理テーブルを参照し、アプリケーションＩＤとアクセス種別の組から許可状態フラグを検索し、許可であり、かつ認証条件があえばクライアントアプリケーションへアクセスの手段を返却値（データや機能への参照アドレス等）として提供する。
【００１５】
図２は各アプリケーションが持つ（メモリ領域に格納）共有管理情報を説明する図である。
図示するようにアプリケーションは自分のアプリケーションＩＤ（ＡＩＤ）と共有管理テーブルの情報を持ち、ＡＩＤ０のアプリケーションがＡＩＤ１、ＡＩＤ２についてアプリケーション管理情報、アクセス管理情報、認証管理情報を持っている。図では本来アプリケーションが持つデータ、関数、その他が格納されているメモリ領域は図示を省略している。なお、以下ではＡＩＤ０、１、２のアプリケーションをそれぞれアプリケーション０、１、２と呼ぶことにする。
【００１６】
図３はクライアントアプリケーションから共有アクセスを求める例を説明する図である。
図の例では、アプリケーション１がアプリケーション０に対してアクセス種別１のアクセス許可を求める様子を示している。サーバーとなるアプリケーション０はＡＩＤとＴＹＰＥ（アクセス種別）の組から認証ＰＩＮを検索し、ＰＩＮ１が１２３４で、一致していること、アクセス状態が許可（フラグ＝１）であることを確認し、アクセス許可を出し、共有データ関数への参照を返す。
【００１７】
図４は共有アクセスに失敗する例を示す図である。
アプリケーション３がアプリケーション０に対してアクセス種別（ＴＹＰＥ）２の許可を求めている様子を示している。サーバーとなるアプリケーション０はＡＩＤ３とＴＹＰＥ２の組が共有管理テーブルにないため、共有アクセス許可を出さない。
【００１８】
図５は共有管理情報にアプリケーションを追加する例を示す図である。
アプリケーション３がアプリケーション０に対して共有管理情報にアプリケーションを追加する様子を示しており、アプリケーション３がＡＩＤ＝３、ＴＹＰＥ＝２とそれに対応する認証パラメータ（ＰＩＮ２＝８７６５）をサーバーとなるアプリケーション０に送る。アプリケーション０はＴＹＰＥ＝２のアクセス権を追加するのに必要な認証レベル２のＰＩＮ＝８７６５（予め保持）と、アプリケーション３からのＰＩＮ２を比較し、両者が一致しているので共有管理情報にＡＩＤ３、ＴＹＰＥ２を追加する。その結果、図６に示すように、共有管理情報にアプリケーション３が追加される。
【００１９】
図７は共有アクセスとアプリケーション管理情報の追加処理フローを示す図である。
外部端末あるいはクライアントから呼び出し（関数呼び出しまたは通信）が発生すると（ステップＳ１）、アクセス要求か否か判断する（ステップＳ２）。アクセス要求であるとアプリケーション管理情報にそのＡＩＤ、ＴＹＰＥがあるか否か判断する（ステップＳ３）。アプリケーション管理情報にＡＩＤ ＴＹＰＥがある場合、次いで認証処理（ＰＩＮが一致か否か）を行い（ステップＳ４）、ＰＩＮが一致した場合、アクセス種別に対応した参照（返却値）を返す（ステップＳ５）。ステップＳ４において、ＰＩＮが一致しない場合、アプリケーション管理情報の要求回数を１追加し（ステップＳ６）、要求回数が規定値を超えたか否か判断し（ステップＳ７）、超えた場合にはアプリケーション管理情報の許可状態フラグを２にセットし、このアプリケーションのアクセスを閉塞する（ステップＳ８）。ステップＳ２において、アクセス要求でない場合、アプリケーション管理情報への追加要求か否か判断する（ステップＳ９）。追加要求である場合、アクセス種別から認証レベルを検索し、追加用の認証レベル２のＰＩＮを得る（ステップＳ１０）。次いで、ＰＩＮが一致するか否か判断し（ステップＳ１１）、一致する場合にはアプリケーション管理情報にＡＩＤ、アクセス種別があるか否か判断し（ステップＳ１２）、ない場合にはアプリケーション管理情報に追加し、許可状態フラグを１にセットする。アプリケーション管理情報にＡＩＤアクセス種別がある場合には、それが閉塞されているか否か判断し（ステップＳ１３）、閉塞されている場合には処理は終了し、閉塞されていない場合は許可状態フラグが１にセットされる。
【００２０】
図８は共有アクセス管理の手順を説明する処理フローである。
外部端末かクライアントからアプリケーション管理情報へＡＩＤ、アクセス種別、許可状態を追加し（ステップＳ２１）、クライアントが共有アクセスを求めると（ステップＳ２２）、許可状態が許可であるか、かつＰＩＮが一致するか否か判断し（ステップＳ２３）、これらを満たさない場合はアクセスを不許可とし、満たす場合には、サーバーはクライアントに許可されたアクセス種別の関数群へのポインタを返す（ステップＳ２４）。クライアントはサーバーの関数を呼び出し（ステップＳ２５）、関数（実際はオブジェクト）は処理を実行する（ステップＳ２６）。この時、すでに許可済みの関数へのポインタが与えられているので、特にチェックはせず、処理が実行される。
（第２の実施例）
第１の実施例においては、アクセス種別毎に認証条件が異なり，許可状態になっていると、関数へのポインタを得た時点で自由にアクセスできるようにし、また認証レベル毎に異なるＰＩＮを用意するようにしていたが、アプリケーションＩＤとアクセス種別に対して認証条件を設定してレベル毎に異なるＰＩＮを用意せず、アクセスがあったときに全てのポインタを返し、各関数の実行時に関数自身が許可状態を参照するようにした例について以下に説明する。
【００２１】
図９は共有管理情報を説明する図で、アプリケーション管理情報と追加削除認証条件管理情報とからなっている。
アプリケーション管理情報はＡＩＤ、アクセス種別、許可状態、要求回数、認証条件からなっており（図９（ａ））、追加削除認証条件管理情報は認証条件（ＰＩＮ２）と要求回数とからなっている。そしてアプリケーション管理情報はアプリケーション名とアクセス種別の組単位で追加、削除を可能とし、その際には、図９（ｂ）の追加削除認証条件を満たすことが条件となる。
【００２２】
第２の実施例におけるアクセス管理情報の追加手順について説明する。
▲１▼端末側から追加削除用認証条件（ＰＩＮ２）をサーバーアプリケーションに渡す。認証が成功すれば次に進み、不正なアプリケーションや外部からの不正アクセスを防ぐため、認証に失敗した場合は要求回数のカウントを１つ増し、特定の回数に達したら「閉塞」し、それ以降サーバーアプリケーションへの追加、削除要求を閉塞する。閉塞解除は行えないか、特定の認証を必要とする。
▲２▼端末側から追加するアプリケーションＩＤとアクセス種別、認証パラメータ（ＰＩＮ１）をサーバーアプリケーションに渡す。サーバーアプリケーションは自分が持つアプリケーション管理情報にアプリケーションＩＤとアクセス種別と認証条件（ＰＩＮ１）を追加する。
【００２３】
次にアプリケーション管理情報の削除の手順について説明する。
▲１▼端末側から追加削除用認証条件（ＰＩＮ２）をサーバーアプリケーションに渡す。認証が成功すれば次に進み、不正なアプリケーションや外部からの不正アクセスを防ぐため、認証に失敗した場合は要求回数のカウンタを１つ増し、特定の回数に達したら「閉塞」し、それ以降サーバーアプリケーションへの追加削除要求を閉塞する。閉塞解除は行えないか、特定の認証を必要とする。
▲２▼端末側から削除するアプリケーションＩＤとアクセス種別、認証パラメータ（ＰＩＮ１）をサーバーアプリケーションに渡す。
▲３▼サーバーアプリケーションは自分が持つアプリケーション管理情報内からアプリケーションＩＤとアクセス種別を検索し、認証条件（ＰＩＮ１）についてチェックする。認証が成功したら、そのアプリケーションＩＤとアクセス種別に対する管理情報を削除する。
【００２４】
次に、共有アクセス管理の手順について説明する。
▲１▼クライアントアプリケーションから直接、またはＯＳを通じて共有アクセスを要求し、サーバーアプリケーションからは各関数（実際はオブジェクト）への参照ポインタが返ってくる。
▲２▼クライアントアプリケーションは上記参照ポインタを通じてＡＩＤとアクセス種別認証用ＰＩＮをパラメータとして送る。
▲３▼サーバー（実際はサーバーの認証用関数）は管理テーブルを参照し、アプリケーションＩＤとアクセス種別の組から認証条件を検索し、認証に成功すれば許可フラグを立てて許可状態とする。
▲４▼クライアントはサーバーから共有している各関数を呼び出しＡＩＤもパラメータとして渡す。
▲５▼呼び出されたサーバーの各関数は管理テーブルを参照し、ＡＩＤとアクセス種別（各関数はどのアクセス種別に属するか予め定義されている）に対応する許可フラグが「許可」であるか否かをチェックし、許可であれば処理を実行する。
【００２５】
図１０はアプリケーションが持つ共有管理情報を説明する図で、アプリケーション０がＡＩＤ１、２についての管理情報と、追加削除認証条件ＰＩＮ２＝４３２１を有していることが示されている。
【００２６】
図１１はクライアントアプリケーションから共有アクセスを求める例を示す図である。アプリケーション１がアプリケーション０に対してアクセス種別１のアクセス許可をもとめている様子を示しており、サーバーとなるアプリケーション０はＡＩＤとアクセス種別の組から認証ＰＩＮを検索し、ＰＩＮ１がそれぞれ１２３４で、正しいことを確認する。ＰＩＮ１が一致したので、ＡＩＤ１、ＴＹＰＥ１について許可状態フラグを１としている（図１２）。
【００２７】
図１３は共有アクセスに失敗した例を示す図である。アプリケーション１がアプリケーション０に対してアクセス種別１のアクセス許可を求めており、サーバーとなるアプリケーション０はＡＩＤ１とアクセス種別１のＰＩＮ１が１２３４であり、アプリケーション１が提示してきたＰＩＮ１が４３２１であるので、認証が成立せず共有アクセス許可を出さない。
【００２８】
図１４は共有管理情報にアプリケーションを追加する例を示す図である。
アプリケーション３がアプリケーション０に対してアクセス種別２とそれに対応する認証パラメータＰＩＮ１、ＰＩＮ２をサーバーとなるアプリケーション０に送る。アプリケーション０のアクセス権を追加するのに必要な認証条件（ＰＩＮ２）について認証し、アプリケーション３から送られてくるＰＩＮ２＝４３２１がアプリケーション０の持つＰＩＮ２＝４３２１と一致するので、ＡＩＤ＝３、ＴＹＰＥ＝２、ＰＩＮ１＝９８７６を図１５に示すように追加する。
【００２９】
図１６は第２の実施例の処理フローを示す図である。
【００３０】
外部からの呼び出しが発生すると（ステップＳ３１）、共有アクセスの認証要求か否か判断する（ステップＳ３２）。共有アクセス認証要求である場合、アプリケーション管理情報にそのＡＩＤ、アクセス種別があるか否か判断する（ステップＳ３３）。ある場合にそれが閉塞されていないか否か判断し（ステップＳ３４）、閉塞されていない場合、ＰＩＮが一致するか否か判断する（ステップＳ３５）。ＰＩＮが一致すると、ＡＩＤとアクセス種別に対応した認証フラグを立てる（ステップＳ３６）。ステップＳ３５において、ＰＩＮが一致していないと、アプリケーション管理情報の要求回数を１増加させ（ステップＳ３７）、次いで要求回数が規定値を超えたか否か判断し（ステップＳ３８）、超えている場合アプリケーション管理情報の該当するＡＩＤとアクセス種別のフラグを２にセットし、閉塞する（ステップＳ３９）。ステップＳ３２において、共有アクセス認証の要求でない場合、共有している関数の呼び出し要求か否か判断する（ステップＳ４０）。関数の呼び出し要求であると、呼ばれた関数のアクセス種別をセットし（ステップＳ４１）、次いでアプリケーション管理情報にそのＡＩＤとアクセス種別があるか否か判断し（ステップＳ４２）、ある場合にそれが閉塞されていないか否か判断する（ステップＳ４３）。閉塞されていない場合には、認証フラグが立っているか否か判断し（ステップＳ４４）、認証フラグが立っていると呼ばれた関数の処理を実行する（ステップＳ４５）。
【００３１】
図１７は第２の実施例における共有アクセス管理の手順を示す処理フローである。
外部端末からアプリケーション管理情報へＡＩＤ、アクセス種別が追加（ステップＳ５１）されたクライアントアプリケーションはサーバーアプリケーションの関数群のポインタを得ることができる（ステップＳ５２）。このクライアントアプリケーションが共有アクセスの要求を行うと（ステップＳ５３）、サーバーアプリケーションはＰＩＮが一致するか否か判断し（ステップＳ５４）、ＰＩＮが一致するとアプリケーション管理情報の許可状態を「許可」にし（ステップＳ５５）、一致しなければ不許可とする。次いで、クライアントアプリケーションがサーバーアプリケーションの関数を呼び出すと（ステップＳ５６）、この関数のアクセス種別が許可状態にあるか否かアプリケーション管理情報を参照して判断し（ステップＳ５７）、許可状態にあれば関数は処理を実行し、許可状態でなければアクセス不許可となる。
【００３２】
【発明の効果】
以上のように、本発明によれば、複数のアプリケーションを搭載可能な携帯可能情報処理装置における共有アクセス管理において、当初想定していなかったアプリケーションの追加や削除に対しても正しくアクセス種別の許可／不許可を管理でき、機能やデータをアクセス可能／不可能とすることが可能である。また、不正なアプリケーションからの共有アクセスを防ぎ、不正な共有アクセス権の取得を防ぐことが可能となる。
【図面の簡単な説明】
【図１】 ＩＣカードに搭載される各アプリケーションが持つ共有管理情報を説明する図である。
【図２】 各アプリケーションが持つ共有管理情報を説明する図である。
【図３】 クライアントアプリケーションから共有アクセスを求める例を説明する図である。
【図４】 共有アクセスに失敗する例を示す図である。
【図５】 共有管理情報にアプリケーションを追加する例を示す図である。
【図６】 共有管理情報にアプリケーションが追加された例を示す図である。
【図７】 共有アクセスとアプリケーション管理情報の追加処理フローを示す図である。
【図８】 共有アクセス管理の手順を説明する処理フロー図である。
【図９】 共有管理情報を説明する図である。
【図１０】 アプリケーションが持つ共有管理情報を説明する図である。
【図１１】 クライアントアプリケーションから共有アクセスを求める例を示す図である。
【図１２】 認証済みフラグが立つ例を示す図である。
【図１３】 共有アクセスに失敗した例を示す図である。
【図１４】 共有管理情報にアプリケーションを追加する例を示を図である。
【図１５】 共有管理情報にアプリケーションが追加された例の図である。
【図１６】 第２の実施例の処理フローを示す図である。
【図１７】 第２の実施例の共有アクセス管理の手順の処理フローを示す図である。
【符号の説明】
ＡＩＤ…アプリケーションＩＤ、ＴＹＰＥ…アクセス種別。
【発明の属する技術分野】
本発明は書き換え可能な複数のアプリケーションを搭載可能な携帯可能情報処理装置（例えば、ＩＣカード）に係り、特にアプリケーション間のアクセスの管理に関するものである。
【０００２】
【従来の技術】
ＩＣカード上のアプリケーション間のアクセスはセキュリティ上問題があり、通常、ＯＳ等により不可能となっている（ファイアーウォール）。しかし、複数のアプリケーションを搭載したＩＣカードでは限られた資源を有効に使うため、機能やデータの共有を目的として、お互いに管理された環境下での限定的なアクセス（共有アクセス）を許す必要がある。さらに各アプリケーションは任意のタイミングで追加、削除されるため、管理方法もそれに対応する必要がある。この共有アクセスについて以下に説明するが、ここでは、共有アクセスを要求する側をクライアントアプリケーション、共有アクセスを許可し、機能や情報を提供する側をサーバーアプリケーションと呼ぶことにする。
【０００３】
従来、ＩＣカードにアプリケーションを搭載する場合に、予め共有アクセスを要求されると予測される他のアプリケーションの情報（ＩＤ）と認証のためのパラメータ（ＰＩＮ：Ｐｅｒｓｏｎａｌ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ）等を各アプリケーションにデータとして与えておき、アプリケーションが他のアプリケーションにアクセスしたい場合、対象となるアプリケーションに対して自分のアプリケーションのＩＤと引き数となる認証パラメータ（ＰＩＮ等）を渡す。アクセスを要求されたサーバーアプリケーション側では渡されたアプリケーションＩＤと認証パラメータを予め自分が知っているデータ（アプリケーションＩＤと認証パラメータの組）と比較し、一致／不一致によってアクセス許可／不許可を判定する。他のアプリケーションに関する情報（アプリケーションＩＤと認証パラメータの組）を追加する場合には、アプリケーションのプログラムを新しく作成し、ＩＣカードに再びインストールしなおす手順により行う。
【０００４】
【発明が解決しようとする課題】
このような従来のＩＣカードにおける共有アクセス管理は、次のような問題があった。
▲１▼自分以外のアプリケーションの情報はカード発行時に確定してしまうため、想定しなかったアプリケーションの追加や削除に対して正しく共有アクセスの許可／不許可を管理できなかった。従来では、後から追加されたアプリケーションには「その他の場合」として対応し、限定的に使用を認めることができるようにしている。
▲２▼後から作成されたアプリケーションに対応するために、既存のアプリケーションを入れなおすと、特にアプリケーションとデータが一体になって管理されている仕組みのＩＣカードの場合に、そのアプリケーションに対応したデータも一緒に消えてしまう場合がある。
▲３▼認証パラメータ（ＰＩＮ）を変更して何度もアクセスを試す等、不正なアプリケーションが不正な共有アクセス権を取得できてしまう可能性があった。
【０００５】
本発明は上記課題を解決するためのもので、カード発行後のアプリケーションの追加や削除に対応できるようにするとともに、不正な共有アクセスや共有管理情報への不正なアクセスを監視してアプリケーションに対してアクセスを閉塞することで、セキュリティを高めるようにすることを目的とする。
【０００６】
【課題を解決するための手段】
本発明は、書き換え可能な複数のアプリケーションを搭載可能で、各アプリケーション間での共有アクセスが可能であり、各アプリケーション（サーバーアプリケーション）が共有管理情報を有し、他のアプリケーション（クライアントアプリケーション）からのアクセス要求があったとき共有管理情報に基づいてアクセスの許可／不許可を判断する共有アクセス管理機能を備えた携帯可能な情報処理装置において、前記共有管理情報が、アプリケーション管理情報、アクセス管理情報、認証管理情報からなることを特徴とする。
また、本発明は、前記アプリケーション管理情報がクライアントアプリケーションを特定するためのＩＤごとのアクセス種別、前記ＩＤとアクセス種別に対する許可状態を示す情報、アクセス種別ごとの認証に失敗した要求回数からなることを特徴とする。
また、本発明は、前記アクセス管理情報が、アクセス種別ごとの認証レベル、アクセスしたクライアントアプリケーションに返す返却値からなることを特徴する。
また、本発明は、前記認証管理情報が、認証レベルに応じたアクセス認証条件と追加削除認証条件からなることを特徴とする。
【０００７】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態を、形態可能な情報処理装置としてＩＣカードを例にとって説明する。
（第１の実施例）
図１はＩＣカードに搭載される各アプリケーションが持つ共有管理情報を説明する図である。共有管理情報はアプリケーション管理情報（図１（ａ））、アクセス管理情報（図１（ｂ））、認証管理情報（図１（ｃ））からなっている。
アプリケーション管理情報は、クライアントアプリケーションのＩＤ（ＡＩＤ）、アクセス種別（ＴＹＰＥ）、許可状態、要求回数からなり、クライアントアプリケーションからの共有アクセスを管理し、各アプリケーションが個々に所有するが、共有アクセス機能を提供しないアプリケーションは持たなくてもよい。その場合は、どのアプリケーションからの共有アクセス要求も受けつけないことになる。
【０００８】
アプリケーションＩＤ（ＡＩＤ）はクライアントアプリケーションを特定するための少なくともＩＣカード内でユニークな番号である。
アクセス種別（ＴＹＰＥ）はそのアプリケーションに与えるアクセスの種別で共有するデータや関数、オブジェクト（データと機能を一まとめにした単位）や、それらの集合を表す番号を指定するか、あるいは直接アドレスやポインタ、関数名を指定するようにしても良い。
【０００９】
許可状態はあるアプリケーションＩＤとアクセス種別に対するアクセスの許可状態を表し、最低限、許可／不許可／閉塞を表せるものとする。その他にアクセス速度を速くするために、一度認証が成功したら、その後認証をしなくても良い「常時許可」や回数や期限を限定した「一時許可」等の状態を設けるようにしても良い。閉塞状態では、後述するように、共有アクセスの認証自体を受け付けない。
要求回数はアクセス種別の認証に失敗した回数、およびアプリケーション管理情報への追加／削除要求の認証失敗の回数をカウントする。なお、追加と削除について両者を分けてカウントできるように項目を追加するようにしても良い。
【００１０】
アクセス管理情報はアクセス種別、認証レベル、返却値からなる。認証レベルはその共有アクセス時に必要な認証のレベルを示す番号である。返却値はクライアントアプリケーションに返却する共有アクセスのための参照値で関数名、変数名、関数へのポインタ、変数へのポインタ、オブジェクトへの参照、実アドレス、値（変数への値そのもの）等、あるいはそれらの集合である。
【００１１】
認証管理情報は認証ベルとアクセス認証条件（ＰＩＮ１）、追加／削除認証条件（追加／削除のために予め有しているＰＩＮ２との照合）からなる。ある認証レベルの共有アクセスの要求があった場合、それに対応したアクセス認証条件（予め保持しているＰＩＮ２との比較）を満たした場合に、共有アクセスが許される。
【００１２】
アプリケーション管理情報はアプリケーション名とアクセス種別の組単位で追加／削除可能とし、その際、図１（ｂ）に示すように、アクセス種別に対応する認証レベルが設定されており、その認証レベルに対応した追加／削除認証条件を満たすことを条件とするように、図１（ｃ）のように、レベル毎に異なるＰＩＮを用意する。
【００１３】
次にアプリケーション管理情報の追加／削除の手順について説明する。
▲１▼クライアントアプリケーション、または端末側から、追加（削除）するアプリケーションＩＤとアクセス種別、認証パラメータ（ＰＩＮ）をサーバーアプリケーションに渡す。
▲２▼サーバーアプリケーションはアクセス種別に対応した認証条件を検索し、認証処理（ＰＩＮの照合等）をする。認証に成功したら、自分が持つアプリケーション管理情報にアプリケーションＩＤとアクセス種別と許可状態（許可）を追加する。
▲３▼不正なアプリケーションや外部からの不正アクセスを防ぐため、認証に失敗した場合は要求回数のカウントを１つ増し、特定の回数に達したら許可状態を「閉塞」し、それ以降、アプリケーションＩＤとアクセス種別の追加、削除要求を閉塞する。閉塞解除は行えないか特定の認証を必要とするようにする。
【００１４】
次に共有アクセス管理の手順について説明する。
▲１▼クライアントアプリケーションから直接、またはＯＳを通じてデータや処理にアクセス要求が発生する。
▲２▼サーバーアプリケーションは共有管理テーブルを参照し、アプリケーションＩＤとアクセス種別の組から許可状態フラグを検索し、許可であり、かつ認証条件があえばクライアントアプリケーションへアクセスの手段を返却値（データや機能への参照アドレス等）として提供する。
【００１５】
図２は各アプリケーションが持つ（メモリ領域に格納）共有管理情報を説明する図である。
図示するようにアプリケーションは自分のアプリケーションＩＤ（ＡＩＤ）と共有管理テーブルの情報を持ち、ＡＩＤ０のアプリケーションがＡＩＤ１、ＡＩＤ２についてアプリケーション管理情報、アクセス管理情報、認証管理情報を持っている。図では本来アプリケーションが持つデータ、関数、その他が格納されているメモリ領域は図示を省略している。なお、以下ではＡＩＤ０、１、２のアプリケーションをそれぞれアプリケーション０、１、２と呼ぶことにする。
【００１６】
図３はクライアントアプリケーションから共有アクセスを求める例を説明する図である。
図の例では、アプリケーション１がアプリケーション０に対してアクセス種別１のアクセス許可を求める様子を示している。サーバーとなるアプリケーション０はＡＩＤとＴＹＰＥ（アクセス種別）の組から認証ＰＩＮを検索し、ＰＩＮ１が１２３４で、一致していること、アクセス状態が許可（フラグ＝１）であることを確認し、アクセス許可を出し、共有データ関数への参照を返す。
【００１７】
図４は共有アクセスに失敗する例を示す図である。
アプリケーション３がアプリケーション０に対してアクセス種別（ＴＹＰＥ）２の許可を求めている様子を示している。サーバーとなるアプリケーション０はＡＩＤ３とＴＹＰＥ２の組が共有管理テーブルにないため、共有アクセス許可を出さない。
【００１８】
図５は共有管理情報にアプリケーションを追加する例を示す図である。
アプリケーション３がアプリケーション０に対して共有管理情報にアプリケーションを追加する様子を示しており、アプリケーション３がＡＩＤ＝３、ＴＹＰＥ＝２とそれに対応する認証パラメータ（ＰＩＮ２＝８７６５）をサーバーとなるアプリケーション０に送る。アプリケーション０はＴＹＰＥ＝２のアクセス権を追加するのに必要な認証レベル２のＰＩＮ＝８７６５（予め保持）と、アプリケーション３からのＰＩＮ２を比較し、両者が一致しているので共有管理情報にＡＩＤ３、ＴＹＰＥ２を追加する。その結果、図６に示すように、共有管理情報にアプリケーション３が追加される。
【００１９】
図７は共有アクセスとアプリケーション管理情報の追加処理フローを示す図である。
外部端末あるいはクライアントから呼び出し（関数呼び出しまたは通信）が発生すると（ステップＳ１）、アクセス要求か否か判断する（ステップＳ２）。アクセス要求であるとアプリケーション管理情報にそのＡＩＤ、ＴＹＰＥがあるか否か判断する（ステップＳ３）。アプリケーション管理情報にＡＩＤ ＴＹＰＥがある場合、次いで認証処理（ＰＩＮが一致か否か）を行い（ステップＳ４）、ＰＩＮが一致した場合、アクセス種別に対応した参照（返却値）を返す（ステップＳ５）。ステップＳ４において、ＰＩＮが一致しない場合、アプリケーション管理情報の要求回数を１追加し（ステップＳ６）、要求回数が規定値を超えたか否か判断し（ステップＳ７）、超えた場合にはアプリケーション管理情報の許可状態フラグを２にセットし、このアプリケーションのアクセスを閉塞する（ステップＳ８）。ステップＳ２において、アクセス要求でない場合、アプリケーション管理情報への追加要求か否か判断する（ステップＳ９）。追加要求である場合、アクセス種別から認証レベルを検索し、追加用の認証レベル２のＰＩＮを得る（ステップＳ１０）。次いで、ＰＩＮが一致するか否か判断し（ステップＳ１１）、一致する場合にはアプリケーション管理情報にＡＩＤ、アクセス種別があるか否か判断し（ステップＳ１２）、ない場合にはアプリケーション管理情報に追加し、許可状態フラグを１にセットする。アプリケーション管理情報にＡＩＤアクセス種別がある場合には、それが閉塞されているか否か判断し（ステップＳ１３）、閉塞されている場合には処理は終了し、閉塞されていない場合は許可状態フラグが１にセットされる。
【００２０】
図８は共有アクセス管理の手順を説明する処理フローである。
外部端末かクライアントからアプリケーション管理情報へＡＩＤ、アクセス種別、許可状態を追加し（ステップＳ２１）、クライアントが共有アクセスを求めると（ステップＳ２２）、許可状態が許可であるか、かつＰＩＮが一致するか否か判断し（ステップＳ２３）、これらを満たさない場合はアクセスを不許可とし、満たす場合には、サーバーはクライアントに許可されたアクセス種別の関数群へのポインタを返す（ステップＳ２４）。クライアントはサーバーの関数を呼び出し（ステップＳ２５）、関数（実際はオブジェクト）は処理を実行する（ステップＳ２６）。この時、すでに許可済みの関数へのポインタが与えられているので、特にチェックはせず、処理が実行される。
（第２の実施例）
第１の実施例においては、アクセス種別毎に認証条件が異なり，許可状態になっていると、関数へのポインタを得た時点で自由にアクセスできるようにし、また認証レベル毎に異なるＰＩＮを用意するようにしていたが、アプリケーションＩＤとアクセス種別に対して認証条件を設定してレベル毎に異なるＰＩＮを用意せず、アクセスがあったときに全てのポインタを返し、各関数の実行時に関数自身が許可状態を参照するようにした例について以下に説明する。
【００２１】
図９は共有管理情報を説明する図で、アプリケーション管理情報と追加削除認証条件管理情報とからなっている。
アプリケーション管理情報はＡＩＤ、アクセス種別、許可状態、要求回数、認証条件からなっており（図９（ａ））、追加削除認証条件管理情報は認証条件（ＰＩＮ２）と要求回数とからなっている。そしてアプリケーション管理情報はアプリケーション名とアクセス種別の組単位で追加、削除を可能とし、その際には、図９（ｂ）の追加削除認証条件を満たすことが条件となる。
【００２２】
第２の実施例におけるアクセス管理情報の追加手順について説明する。
▲１▼端末側から追加削除用認証条件（ＰＩＮ２）をサーバーアプリケーションに渡す。認証が成功すれば次に進み、不正なアプリケーションや外部からの不正アクセスを防ぐため、認証に失敗した場合は要求回数のカウントを１つ増し、特定の回数に達したら「閉塞」し、それ以降サーバーアプリケーションへの追加、削除要求を閉塞する。閉塞解除は行えないか、特定の認証を必要とする。
▲２▼端末側から追加するアプリケーションＩＤとアクセス種別、認証パラメータ（ＰＩＮ１）をサーバーアプリケーションに渡す。サーバーアプリケーションは自分が持つアプリケーション管理情報にアプリケーションＩＤとアクセス種別と認証条件（ＰＩＮ１）を追加する。
【００２３】
次にアプリケーション管理情報の削除の手順について説明する。
▲１▼端末側から追加削除用認証条件（ＰＩＮ２）をサーバーアプリケーションに渡す。認証が成功すれば次に進み、不正なアプリケーションや外部からの不正アクセスを防ぐため、認証に失敗した場合は要求回数のカウンタを１つ増し、特定の回数に達したら「閉塞」し、それ以降サーバーアプリケーションへの追加削除要求を閉塞する。閉塞解除は行えないか、特定の認証を必要とする。
▲２▼端末側から削除するアプリケーションＩＤとアクセス種別、認証パラメータ（ＰＩＮ１）をサーバーアプリケーションに渡す。
▲３▼サーバーアプリケーションは自分が持つアプリケーション管理情報内からアプリケーションＩＤとアクセス種別を検索し、認証条件（ＰＩＮ１）についてチェックする。認証が成功したら、そのアプリケーションＩＤとアクセス種別に対する管理情報を削除する。
【００２４】
次に、共有アクセス管理の手順について説明する。
▲１▼クライアントアプリケーションから直接、またはＯＳを通じて共有アクセスを要求し、サーバーアプリケーションからは各関数（実際はオブジェクト）への参照ポインタが返ってくる。
▲２▼クライアントアプリケーションは上記参照ポインタを通じてＡＩＤとアクセス種別認証用ＰＩＮをパラメータとして送る。
▲３▼サーバー（実際はサーバーの認証用関数）は管理テーブルを参照し、アプリケーションＩＤとアクセス種別の組から認証条件を検索し、認証に成功すれば許可フラグを立てて許可状態とする。
▲４▼クライアントはサーバーから共有している各関数を呼び出しＡＩＤもパラメータとして渡す。
▲５▼呼び出されたサーバーの各関数は管理テーブルを参照し、ＡＩＤとアクセス種別（各関数はどのアクセス種別に属するか予め定義されている）に対応する許可フラグが「許可」であるか否かをチェックし、許可であれば処理を実行する。
【００２５】
図１０はアプリケーションが持つ共有管理情報を説明する図で、アプリケーション０がＡＩＤ１、２についての管理情報と、追加削除認証条件ＰＩＮ２＝４３２１を有していることが示されている。
【００２６】
図１１はクライアントアプリケーションから共有アクセスを求める例を示す図である。アプリケーション１がアプリケーション０に対してアクセス種別１のアクセス許可をもとめている様子を示しており、サーバーとなるアプリケーション０はＡＩＤとアクセス種別の組から認証ＰＩＮを検索し、ＰＩＮ１がそれぞれ１２３４で、正しいことを確認する。ＰＩＮ１が一致したので、ＡＩＤ１、ＴＹＰＥ１について許可状態フラグを１としている（図１２）。
【００２７】
図１３は共有アクセスに失敗した例を示す図である。アプリケーション１がアプリケーション０に対してアクセス種別１のアクセス許可を求めており、サーバーとなるアプリケーション０はＡＩＤ１とアクセス種別１のＰＩＮ１が１２３４であり、アプリケーション１が提示してきたＰＩＮ１が４３２１であるので、認証が成立せず共有アクセス許可を出さない。
【００２８】
図１４は共有管理情報にアプリケーションを追加する例を示す図である。
アプリケーション３がアプリケーション０に対してアクセス種別２とそれに対応する認証パラメータＰＩＮ１、ＰＩＮ２をサーバーとなるアプリケーション０に送る。アプリケーション０のアクセス権を追加するのに必要な認証条件（ＰＩＮ２）について認証し、アプリケーション３から送られてくるＰＩＮ２＝４３２１がアプリケーション０の持つＰＩＮ２＝４３２１と一致するので、ＡＩＤ＝３、ＴＹＰＥ＝２、ＰＩＮ１＝９８７６を図１５に示すように追加する。
【００２９】
図１６は第２の実施例の処理フローを示す図である。
【００３０】
外部からの呼び出しが発生すると（ステップＳ３１）、共有アクセスの認証要求か否か判断する（ステップＳ３２）。共有アクセス認証要求である場合、アプリケーション管理情報にそのＡＩＤ、アクセス種別があるか否か判断する（ステップＳ３３）。ある場合にそれが閉塞されていないか否か判断し（ステップＳ３４）、閉塞されていない場合、ＰＩＮが一致するか否か判断する（ステップＳ３５）。ＰＩＮが一致すると、ＡＩＤとアクセス種別に対応した認証フラグを立てる（ステップＳ３６）。ステップＳ３５において、ＰＩＮが一致していないと、アプリケーション管理情報の要求回数を１増加させ（ステップＳ３７）、次いで要求回数が規定値を超えたか否か判断し（ステップＳ３８）、超えている場合アプリケーション管理情報の該当するＡＩＤとアクセス種別のフラグを２にセットし、閉塞する（ステップＳ３９）。ステップＳ３２において、共有アクセス認証の要求でない場合、共有している関数の呼び出し要求か否か判断する（ステップＳ４０）。関数の呼び出し要求であると、呼ばれた関数のアクセス種別をセットし（ステップＳ４１）、次いでアプリケーション管理情報にそのＡＩＤとアクセス種別があるか否か判断し（ステップＳ４２）、ある場合にそれが閉塞されていないか否か判断する（ステップＳ４３）。閉塞されていない場合には、認証フラグが立っているか否か判断し（ステップＳ４４）、認証フラグが立っていると呼ばれた関数の処理を実行する（ステップＳ４５）。
【００３１】
図１７は第２の実施例における共有アクセス管理の手順を示す処理フローである。
外部端末からアプリケーション管理情報へＡＩＤ、アクセス種別が追加（ステップＳ５１）されたクライアントアプリケーションはサーバーアプリケーションの関数群のポインタを得ることができる（ステップＳ５２）。このクライアントアプリケーションが共有アクセスの要求を行うと（ステップＳ５３）、サーバーアプリケーションはＰＩＮが一致するか否か判断し（ステップＳ５４）、ＰＩＮが一致するとアプリケーション管理情報の許可状態を「許可」にし（ステップＳ５５）、一致しなければ不許可とする。次いで、クライアントアプリケーションがサーバーアプリケーションの関数を呼び出すと（ステップＳ５６）、この関数のアクセス種別が許可状態にあるか否かアプリケーション管理情報を参照して判断し（ステップＳ５７）、許可状態にあれば関数は処理を実行し、許可状態でなければアクセス不許可となる。
【００３２】
【発明の効果】
以上のように、本発明によれば、複数のアプリケーションを搭載可能な携帯可能情報処理装置における共有アクセス管理において、当初想定していなかったアプリケーションの追加や削除に対しても正しくアクセス種別の許可／不許可を管理でき、機能やデータをアクセス可能／不可能とすることが可能である。また、不正なアプリケーションからの共有アクセスを防ぎ、不正な共有アクセス権の取得を防ぐことが可能となる。
【図面の簡単な説明】
【図１】 ＩＣカードに搭載される各アプリケーションが持つ共有管理情報を説明する図である。
【図２】 各アプリケーションが持つ共有管理情報を説明する図である。
【図３】 クライアントアプリケーションから共有アクセスを求める例を説明する図である。
【図４】 共有アクセスに失敗する例を示す図である。
【図５】 共有管理情報にアプリケーションを追加する例を示す図である。
【図６】 共有管理情報にアプリケーションが追加された例を示す図である。
【図７】 共有アクセスとアプリケーション管理情報の追加処理フローを示す図である。
【図８】 共有アクセス管理の手順を説明する処理フロー図である。
【図９】 共有管理情報を説明する図である。
【図１０】 アプリケーションが持つ共有管理情報を説明する図である。
【図１１】 クライアントアプリケーションから共有アクセスを求める例を示す図である。
【図１２】 認証済みフラグが立つ例を示す図である。
【図１３】 共有アクセスに失敗した例を示す図である。
【図１４】 共有管理情報にアプリケーションを追加する例を示を図である。
【図１５】 共有管理情報にアプリケーションが追加された例の図である。
【図１６】 第２の実施例の処理フローを示す図である。
【図１７】 第２の実施例の共有アクセス管理の手順の処理フローを示す図である。
【符号の説明】
ＡＩＤ…アプリケーションＩＤ、ＴＹＰＥ…アクセス種別。
Claims (4)
- 書き換え可能な複数のアプリケーションを搭載可能で、各アプリケーション間での共有アクセスが可能であり、各アプリケーション（サーバーアプリケーション）が共有管理情報を有し、他のアプリケーション（クライアントアプリケーション）からのアクセス要求があったとき共有管理情報に基づいてアクセスの許可／不許可を判断する共有アクセス管理機能を備えた携帯可能な情報処理装置において、
前記共有管理情報が、アプリケーション管理情報、アクセス管理情報、認証管理情報からなることを特徴とする共有アクセス管理機能を備えた携帯可能な情報処理装置。 - 前記アプリケーション管理情報はクライアントアプリケーションを特定するためのＩＤごとのアクセス種別、前記ＩＤとアクセス種別に対する許可状態を示す情報、アクセス種別ごとの認証に失敗した要求回数からなることを特徴とする請求項１記載の携帯可能な情報処理装置。
- 前記アクセス管理情報は、アクセス種別ごとの認証レベル、アクセスしたクライアントアプリケーションに返す返却値からなることを特徴する請求項１記載の携帯可能な情報処理装置。
- 前記認証管理情報は、認証レベルに応じたアクセス認証条件と追加削除認証条件からなることを特徴とする請求項１記載の携帯可能な情報処理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000268676A JP4548758B2 (ja) | 2000-09-05 | 2000-09-05 | 共有アクセス管理機能を備えた携帯可能な情報処理装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000268676A JP4548758B2 (ja) | 2000-09-05 | 2000-09-05 | 共有アクセス管理機能を備えた携帯可能な情報処理装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002073196A JP2002073196A (ja) | 2002-03-12 |
| JP4548758B2 true JP4548758B2 (ja) | 2010-09-22 |
Family
ID=18755423
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000268676A Expired - Fee Related JP4548758B2 (ja) | 2000-09-05 | 2000-09-05 | 共有アクセス管理機能を備えた携帯可能な情報処理装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4548758B2 (ja) |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3884963B2 (ja) * | 2002-01-23 | 2007-02-21 | 大日本印刷株式会社 | 共有アクセス監視機能を備えたｉｃカード |
| JP2004029945A (ja) * | 2002-06-21 | 2004-01-29 | Dainippon Printing Co Ltd | Ｉｃカード及びｉｃカードプログラム |
| JP4185715B2 (ja) * | 2002-06-28 | 2008-11-26 | 大日本印刷株式会社 | Ｉｃカード及びｉｃカードプログラム |
| JP5036770B2 (ja) * | 2002-07-19 | 2012-09-26 | 株式会社リコー | 装置及びラッピング処理方法並びにプログラム |
| JP4177642B2 (ja) * | 2002-11-08 | 2008-11-05 | 株式会社東芝 | 携帯可能電子装置 |
| JP4323190B2 (ja) * | 2003-03-07 | 2009-09-02 | 株式会社エヌ・ティ・ティ・ドコモ | 通信端末 |
| JP2005044009A (ja) * | 2003-07-24 | 2005-02-17 | Hitachi Ltd | 携帯情報保護方法、携帯端末装置並びにサーバ装置 |
| US20050091658A1 (en) * | 2003-10-24 | 2005-04-28 | Microsoft Corporation | Operating system resource protection |
| JP4580164B2 (ja) * | 2003-12-10 | 2010-11-10 | 株式会社エヌ・ティ・ティ・ドコモ | 電子機器およびプログラム |
| US7543331B2 (en) * | 2003-12-22 | 2009-06-02 | Sun Microsystems, Inc. | Framework for providing a configurable firewall for computing systems |
| JP4125227B2 (ja) * | 2003-12-25 | 2008-07-30 | キヤノン株式会社 | 認証システム及び認証方法 |
| EP1728156A2 (en) * | 2004-03-04 | 2006-12-06 | Axalto SA | A secure sharing of resources between applications in independent execution environments in a retrievable token (e.g smart card) |
| JP4994575B2 (ja) * | 2004-03-12 | 2012-08-08 | キヤノン株式会社 | ネットワークインターフェース装置及びその制御方法、及び画像形成システム |
| JP4717381B2 (ja) * | 2004-06-11 | 2011-07-06 | 株式会社エヌ・ティ・ティ・ドコモ | 移動機、及び、アクセス制御方法 |
| JP4745657B2 (ja) * | 2004-12-20 | 2011-08-10 | キヤノン株式会社 | データ処理装置、認証処理方法及びコンピュータプログラム |
| JP4685567B2 (ja) | 2005-09-15 | 2011-05-18 | 株式会社日立製作所 | 情報処理装置によるサービス提供システム |
| JP5150116B2 (ja) * | 2006-03-31 | 2013-02-20 | パナソニック株式会社 | Ｉｃカード及び読み書き装置 |
| JP2008139923A (ja) * | 2006-11-30 | 2008-06-19 | Dainippon Printing Co Ltd | 共有オブジェクトを有するｉｃカード、共有オブジェクトへのアクセス管理方法、及び、ｉｃカードプログラム |
| JP5034921B2 (ja) * | 2007-12-14 | 2012-09-26 | ソニー株式会社 | 情報処理装置、ディスク、および情報処理方法、並びにプログラム |
| WO2011074168A1 (ja) * | 2009-12-14 | 2011-06-23 | パナソニック株式会社 | 情報処理装置 |
| JP6226373B2 (ja) * | 2013-11-21 | 2017-11-08 | 株式会社東芝 | Ｉｃカード |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002503007A (ja) * | 1998-02-03 | 2002-01-29 | モンデックス インターナショナル リミテッド | Ｉｃカード内のコンピュータコードへのアクセスを制御するシステムおよび方法 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000172490A (ja) * | 1998-12-01 | 2000-06-23 | Toshiba Corp | Ｉｃカード発行システムとｉｃカード処理システムとｉｃカード |
-
2000
- 2000-09-05 JP JP2000268676A patent/JP4548758B2/ja not_active Expired - Fee Related
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002503007A (ja) * | 1998-02-03 | 2002-01-29 | モンデックス インターナショナル リミテッド | Ｉｃカード内のコンピュータコードへのアクセスを制御するシステムおよび方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002073196A (ja) | 2002-03-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4548758B2 (ja) | 共有アクセス管理機能を備えた携帯可能な情報処理装置 | |
| US11956235B2 (en) | Behavioral baselining from a data source perspective for detection of compromised users | |
| US10002152B2 (en) | Client computer for updating a database stored on a server via a network | |
| US8510818B2 (en) | Selective cross-realm authentication | |
| CN112637214B (zh) | 资源访问方法、装置及电子设备 | |
| US5944824A (en) | System and method for single sign-on to a plurality of network elements | |
| US8955077B1 (en) | Server-token lockstep systems and methods | |
| US11863557B2 (en) | Sidecar architecture for stateless proxying to databases | |
| CN107196951A (zh) | 一种hdfs系统防火墙的实现方法和防火墙系统 | |
| WO2004114087A2 (en) | User not present | |
| CN115987696B (zh) | 一种基于区块链结构的零信任安全网关实现方法及装置 | |
| EP3407241B1 (en) | User authentication and authorization system for a mobile application | |
| US20230334140A1 (en) | Management of applications’ access to data resources | |
| CN115913676B (zh) | 云原生应用的访问控制方法、装置、电子设备及存储介质 | |
| US20230061620A1 (en) | Dynamic temporary data source access management | |
| RU2536678C1 (ru) | Способ проверки прав доступа для учетных записей пользователей в грид-системах и система для его осуществления | |
| CN106533688A (zh) | 安全认证的方法及装置 | |
| KR20050003587A (ko) | 보안 시스템 및 그의 접근 제어 방법 | |
| JP2005025346A (ja) | データベースシステム及びデータベース管理方法並びにデータベース管理プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20070511 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100108 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100205 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100318 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100416 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100611 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20100702 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100702 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130716 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |