セキュアデバイス、端末装置、ゲート機器、機器
カードアプリ機能や装置機能等が発現されるエリアを限定できるＩＣカード等のセキュアデバイスを提供するセキュアデバイス、端末装置、ゲート機器、機器。セキュアデバイス（２０）に、ゲート機器（４０）に対して認証処理を行う認証アプリ（２４）と、端末である携帯電話（１０）にインストールする端末アプリ・設定命令（２６）や、端末アプリ（２７）と、認証アプリ（２４）がゲート機器（４０）との認証に成功した場合に、ゲート機器（４０）から指定された端末アプリを携帯電話（１０）にインストールする制御手段であるＣＰＵ（２３）とを設けている。セキュアデバイス（２０）をゲート機器（４０）に翳し、正常に通過したエリアでのみ、端末アプリ・設定命令（２６）、端末アプリ（２７）が携帯電話（１０）にインストールされる。ゲート機器（４０）のゲートアプリ（４３）が特定の領域で機能するアプリを指定するので、ユーザの登録操作等は不要であり、また、端末へのＧＰＳ受信機等の装備も必要がない。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＣカード等のセキュアデバイスと、このセキュアデバイスとの間で接触通信または非接触通信を行う端末装置、ゲート機器、機器に関するものである。
【背景技術】
【０００２】
近年、ＩＣカードは、電子決済用カードや定期乗車券、イベント用チケット、クレジットカード等として広く利用されている。最近では、微細化技術の向上とも相俟って、比較的大容量の記憶空間を持つＩＣカードが作られており、このようなＩＣカードは、カードサービスを実行する複数のカードアプリケーション（以下、アプリケーションを「アプリ」と略称する）を格納することにより、一枚で複数の用途に対応するマルチアプリカードとして使用することができる。
【０００３】
ＩＣカードの通信方式には、ＩＣカードの電気的接点にリーダ・ライタを接触して記録情報の読み書きを行う接触通信と、無線通信で情報をやり取りし、リーダ・ライタとの物理的な接触を必要としない非接触通信との二通りがある。最近は、接触通信及び非接触通信の両方が可能なＩＣカード（コンビカード）を携帯端末装置に搭載し、この携帯端末を電子財布や定期券の替わりに使用することも行われている。
【０００４】
下記特許文献１には、搭載したマルチアプリカードから、目的のカード機能を迅速かつ簡単に選択することを可能にした携帯端末装置が開示されている。この装置を使用するユーザは、マルチアプリカードのカード機能を携帯端末の表示画面に一覧表示して、その中から親アプリと、親アプリに関連付けたアプリ（優先アプリ）とを登録し、マルチアプリカードに記憶させる。例えば、親アプリとして定期乗車券機能を登録し、その優先アプリとして電子マネー機能を登録すると、携帯端末を自動改札装置に翳し、マルチアプリカードの定期乗車券機能を用いて駅構内に入場した場合に、携帯端末の表示画面には、優先アプリの電子マネー機能の表示順位を最上位に設定したアプリ選択画面が表示される。
【０００５】
また、ユーザがマルチアプリカードのアプリ機能を使用すると、その位置が携帯端末のＧＰＳ受信機等の現在位置検出手段で検出されて、使用したアプリ機能と使用位置との関係が携帯端末で記憶される。そして、その位置付近を再び訪れたとき、携帯端末の表示画面には、その位置に対応するアプリ機能の表示順位を最上位に設定したアプリ選択画面が表示される。
【特許文献１】特開２００３−７６９５８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
このように、場所と対応付けてアプリ選択画面の表示を変更することは前記特許文献１に記載されているが、ＩＣカードのカード機能を場所によって限定する発想は、この文献には示されていない。ＩＣカードのカード機能を場所で限定することができるならば、例えば、ＩＣカードを搭載した携帯電話を、社内エリアでは内線電話として使用できるようにし、あるいは、ＩＣカードに格納された特定データを社内エリアでのみ利用できるようにする等、新たな応用が可能になる。
【０００７】
また、ＩＣカードのカード機能を場所によって限定する場合に、前記特許文献１のように、ユーザの登録操作を必要とするのでは、ユーザの処理負担が大きいし、また、携帯端末が位置情報の取得手段を持つ必要があるのでは、携帯端末のコストが高くなる。
【０００８】
本発明の目的は、こうした従来の課題を解決するものであり、ユーザの処理負担やコスト負担を招かずに、セキュアデバイスのカード機能や、端末装置あるいは機器の機能を、場所と関連付けて変更したり、または通信方式、前回の無効化処理、さらにはメモリ容量等に応じて変更したり、よりセキュリティを確保することができるＩＣカード等のセキュアデバイスを提供し、また、このセキュアデバイスと連携して処理を行う端末装置、ゲート機器、機器を提供することである。
【課題を解決するための手段】
【０００９】
本発明のセキュアデバイスは、ゲート機器に対して認証処理を行う認証手段と、端末にインストールする端末アプリケーションと、前記認証手段がゲート機器との認証に成功した場合に、前記ゲート機器から指定された端末アプリケーションを端末にインストールする制御手段と、を備える構成を採る。
【００１０】
また、本発明のセキュアデバイスは、ゲート機器に対して認証処理を行う認証手段と、カードアプリケーションと、前記認証手段がゲート機器との認証に成功した場合に、前記ゲート機器から指定されたカードアプリケーションが、端末の端末アプリケーションのアクセスを許容する制御手段と、を備える構成を採る。
【００１１】
また、本発明のセキュアデバイスは、ゲート機器に対して認証処理を行い、認証に成功したゲート機器の識別情報を登録する認証手段と、前記認証手段がゲート機器との認証に成功したことを条件に所定の動作を行う機器に対して、前記機器の検証に供するためにゲート機器の前記識別情報を送信し、または、前記機器に代わって前記識別情報を検証するカードアプリケーションと、を備える構成を採る。
【００１２】
また、本発明のゲート機器は、セキュアデバイスまたは前記セキュアデバイスを保持する端末との通信手段と、前記通信手段を通じて前記セキュアデバイスとの認証処理を行い、認証に成功したセキュアデバイスに対して、端末にインストールする端末アプリケーションを指定するゲートアプリケーションと、を備える構成を採る。
【００１３】
また、本発明のゲート機器は、セキュアデバイスまたは前記セキュアデバイスを保持する端末との通信手段と、前記通信手段を通じて前記セキュアデバイスとの認証処理を行い、認証に成功したセキュアデバイスに対して、端末の端末アプリケーションがアクセスできるカードアプリケーションを指定するゲートアプリケーションと、を備える構成を採る。
【００１４】
また、本発明の端末装置は、セキュアデバイスを保持し、ゲート機器との認証に成功した前記セキュアデバイスから、前記ゲート機器が指定した端末アプリケーションをインストールする構成を採る。
【００１５】
また、本発明の端末装置は、セキュアデバイスを保持し、ゲート機器との認証に成功した前記セキュアデバイスが保持するカードアプリケーションの中で、前記ゲート機器が指定したカードアプリケーションにアクセスする端末アプリケーションを備える構成を採る。
【００１６】
また、本発明の機器は、ゲート機器との認証に成功したセキュアデバイスから前記ゲート機器の識別情報を取得し、前記識別情報の検証に成功した場合に所定の動作を行う構成を採る。
【００１７】
また、本発明の機器は、ゲート機器との認証に成功したセキュアデバイスから前記ゲート機器の識別情報の検証に成功した旨の情報を取得した場合に所定の動作を行う構成を採る。
【発明の効果】
【００１８】
本発明のセキュアデバイス、ゲート機器、端末装置及び機器は、連携して、セキュアデバイスのカード機能や、端末装置あるいは機器の機能を、場所と関連付けて変更したり、または通信方式、前回の無効化処理、さらにはメモリ容量等に応じて変更したり、よりセキュリティを確保することができる。例えば、端末装置の機能をオフィスの中と外とで切替えたり、特定の処理機能を限定したエリアでのみ可能にしたり、特定の入口から入場しなければ、部屋の扉や金庫が開かないようにしたりすることができる。また、こうした処理を、ユーザの処理負担やコスト負担を招かずに実現することができる。
【図面の簡単な説明】
【００１９】
［図１］本発明の第１の実施形態における携帯電話、コンビカード及びゲートの構成を示すブロック図
［図２］本発明の第１の実施形態に設定されたデータＤＢのデータ構成を示す図
［図３］本発明の第１の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図４］本発明の第１の実施形態における携帯電話、ＩＣカード及びゲートの構成を示すブロック図
［図５］本発明の第２の実施形態における携帯電話、コンビカード及びゲートの構成を示すブロック図
［図６］本発明の第２の実施形態に設定されたデータＤＢのデータ構成を示す図
［図７］本発明の第２の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図８］本発明の第２の実施形態における優先度設定ＤＢのデータ構成を示す図
［図９Ａ］本発明の第２の実施形態における優先度設定ＤＢの他のデータ構成であって、各カードアプリＩＤの優先度を規定した優先度テンプレートの一例を示す図
［図９Ｂ］本発明の第２の実施形態における優先度設定ＤＢの他のデータ構成であって、ゲートアプリＩＤに対応して優先度テンプレートを設定した優先設定ＤＢの一例を示す図
［図１０］本発明の第３の実施形態におけるドア、ＩＣカード及びゲートの構成を示すブロック図
［図１１］本発明の第３の実施形態におけるドア、ＩＣカード及びゲートの動作を示すシーケンス図
［図１２］本発明の第３の実施形態におけるＰＩＮ入力部を持つドア、ＩＣカード及びゲートの構成を示すブロック図
［図１３］本発明の第３の実施形態におけるＰＩＮ入力部を持つドア、ＩＣカード及びゲートの動作を示すシーケンス図
［図１４］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の構成を示すブロック図
［図１５］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図１６］本発明の第４の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図１７］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図（図１６の続き）
［図１８］本発明の第４の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図１９］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図（図１８の続き）
［図２０］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図２１］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図２２］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図２３］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図２４］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図２５］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図２６］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図２７］第５の実施形態における会社の入場処理と退場処理とを例にした認証情報ＤＢ例を示す図
［図２８］第５の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図２９］第６の実施形態の認証情報ＤＢの内容の一例を示す図
［図３０］第６の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図３１］第７の実施形態の構成を示すブロック図
［図３２］第７の実施形態の認証情報ＤＢに設定されたデータの一例を示す図
［図３３］第７の実施形態の端末設定管理部に設定されたデータの一例を示す図
［図３４］第７の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図３５］第８の実施形態の構成を示すブロック図。
［図３６］第８の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図３７］第８の実施形態の端末アプリ退避管理部における詳細処理を示すフローチャート
【発明を実施するための最良の形態】
【００２０】
（第１の実施形態）
本発明の第１の実施形態では、セキュアデバイスであるＩＣカードが特定エリアに位置するときだけ、ＩＣカードに格納された端末アプリが、端末にインストールされる場合について説明する。
【００２１】
この特定エリアの入口にはゲートが在り、ゲートアプリは、ＩＣカードとの認証処理に成功すると、ＩＣカードに対して、端末に設定すべき端末アプリを指定する。これを受けて、ＩＣカードは、適宜の時期に、保持する端末アプリの中から、指定された端末アプリを端末にインストールする。
【００２２】
図１は、端末（機器１）が携帯電話１０であり、ＩＣカード（機器２）が、携帯電話１０に装着されたチップ状のコンビカード２０である場合の、携帯電話１０、コンビカード２０及びゲート４０（機器３）の構成について示している。
【００２３】
ゲート４０は、コンビカード２０に対して認証処理や端末アプリの指定を行うゲートアプリ４３と、コンビカード２０への非接触通信を行う非接触通信手段（４）４１と、ゲート４０の動作を制御するＣＰＵ４２とを備えている。
【００２４】
コンビカード２０は、ゲート４０への非接触通信を行う非接触通信手段（３）２２と、携帯電話１０への接触通信を行う接触通信手段（２）２１と、認証情報等が格納された認証情報データベース（ＤＢ）２５と、他の機器１、３との認証処理を行う認証アプリ２４と、携帯電話１０にインストールする端末アプリ２７や設定命令、あるいはそれらのセットである端末アプリ・設定命令２６と、コンビカード２０の動作を制御するＣＰＵ２３とを備えている。
【００２５】
また、携帯電話１０は、コンビカード２０への接触通信を行う接触通信手段（１）１１と、携帯電話１０の動作を制御するＣＰＵ１２とを備えている。
【００２６】
このコンビカード２０の認証情報ＤＢ２５には、図２に示すように、ゲートアプリ４３のＩＤと対応付けて、認証処理に使用する共通鍵や秘密鍵等の認証情報と、携帯電話１０へのインストールが可能な端末アプリ２７のＩＤや、携帯電話１０で設定すべき端末アプリを指定する設定命令のＩＤが格納されている。
【００２７】
設定命令は、例えば、携帯電話１０に対する次のような指示である。・表示画面の背景イメージに会社ロゴを設定する。・音（着信時、アプリ実行時）に会社用の音を設定する。・メインメニューに、社内で使用するイントラネットアプリを追加する。・デフォルトを内線電話に変更する（外線への発信を０発信に変更）。・メール機能の設定（メールサーバアドレス、ユーザＩＤ、個人情報、ネットワーク設定、など）を変える。・会社では特定のメールサーバにしかアクセスできない。・会社では特定のアドレスにしかメール送信できない。・会社では、特定のメールを読むことしかできない。・アクセス可能なアプリサーバを制限する。・会社では特定のサイトにしかアクセスできない。
【００２８】
また、携帯電話１０へのインストールが可能な端末アプリは、携帯電話１０で保持されていない、設定命令の実行に必要なアプリであり、例えば、以下に示すアプリがある。・設定命令に基づく表示を実行するブラウザ等のソフトウエア。例えば、会社では、特定のサイトへのアクセスのみが可能なブラウザアプのみへ切り替える。・メールアプリを切り替える。例えば、会社では、メールの保存ができない特定のメールアプリしか使えないとか、会社では会社内でないと保存したメールが閲覧できない特定のメールアプリしか使えない。例えば、保存したメールは、特定のメールアプリしかアクセスできないコンビカード２０セキュアメモリエリアに保存されている。
【００２９】
図３は、このゲート４０、コンビカード２０及び携帯電話１０が連携して行う処理のシーケンスを示している。
【００３０】
ユーザは、所定エリアに入場する際に、コンビカード２０を装着した携帯電話１０をゲート４０に翳す。ゲート４０のＣＰＵ４２は、非接触通信手段４１の通信圏内にコンビカード２０が進入すると、コンビカード２０に認証アプリＩＤとゲートアプリＩＤとを指定して認証処理を要求する（１−１）。これを受けてコンビカード２０のＣＰＵ２３は認証アプリ２４を起動し、認証アプリ２４は、認証情報ＤＢ２５のゲートアプリＩＤに対応する認証情報を用いて、ゲートアプリ４３との間で、一般的なチャレンジレスポンスによる認証処理を実行する（１−２）。認証処理に成功すると、ゲートアプリ４３は、端末アプリＩＤを指定して、その端末アプリの端末へのインストールを要求する（１−３）。指定する端末アプリＩＤは複数であっても良い。
【００３１】
この要求を受けたコンビカード２０の認証アプリ２４は、認証情報ＤＢ２５の情報から、その端末アプリがインストール可能であることを確認（検証）し、その旨をＣＰＵ２３に伝える。ＣＰＵ２３は、携帯電話１０に端末アプリＩＤを示してインストール要求を送り（２−１）、認証アプリ２４に携帯電話１０との認証処理を行わせる（２−２）。なお、コンビカード２０を携帯電話１０に装着した時点で両者間の認証処理が既に済んでいれば、この認証処理を省略しても良い。認証処理に成功すると、ＣＰＵ２３は、該当する端末アプリ２６、２７を携帯電話１０に送信し（２−３）、携帯電話１０のＣＰＵ１２は、その端末アプリをインストールする。
【００３２】
このように、このゲート４０、コンビカード２０及び携帯電話１０の間では、三者の連携により、コンビカード２０とゲート４０との認証の成功を条件に、コンビカード２０から携帯電話１０への端末アプリのインストールが実行される。そのため、このコンビカード２０の動作や、携帯電話１０の端末アプリを利用する処理は、ゲート４０を通過して入場したエリアでのみ可能になる。
【００３３】
なお、ＩＣカードの国際標準規格（接触通信に関するＩＳＯ７８１６、非接触通信に関するＩＳＯ１４４４３）では、ＩＣカードのカードアプリとリーダ・ライタ側の端末アプリとのデータのやり取りは、端末アプリからカードアプリに送られる「コマンド」と、カードアプリから端末アプリに送られる「レスポンス」とが基本になると規定されている。従って、国際標準規格を満たすＩＣカードは、受動的な動作しかできず、（２−１）のインストール要求を自ら携帯電話１０に送信することができない。
【００３４】
そのため、携帯電話１０は、国際標準規格を満たすコンビカード２０の場合には、ユーザが携帯電話１０をゲート４０に翳した時点から、非接触通信の状態を監視するためにコンビカード２０にポーリング信号を送り続ける。そして、コンビカード２０から非接触通信終了の応答を受けると、コンビカード２０に対し、要求が有れば送信するように指示し、コンビカード２０は、これに応えてインストール要求を携帯電話１０に送信する（２−１）。
【００３５】
こうした手順を採ることにより、国際標準規格を満たすＩＣカードにも対応することができる。
【００３６】
なお、ここでは、ＩＣカードがコンビカードである場合について説明したが、ＩＣカードが接触通信機能のみを有するときは、図４に示すように、携帯電話１０の赤外線（またはＢｌｕｅｔｏｏｔｈや無線ＬＡＮ）等のローカル通信手段１３を利用して、ＩＣカード２０とゲート４０との通信を行うことができる。この場合、ゲート４０が、通信手段４４と携帯電話１０のローカル通信手段１３との通信（赤外線）接続を確立して、携帯電話１０にＩＣカード２０へのアクセス命令を送ると、携帯電話１０はＩＣカード２０との接触通信接続を実行し、ゲート４０とＩＣカード２０との通信が可能になる。ゲート４０、ＩＣカード２０及び携帯電話１０の三者間におけるデータのシーケンスは、図３と同じである。
【００３７】
また、ＩＣカードが非接触通信機能のみを有するときには、携帯電話１０およびゲート４０と非接触通信を用いて通信を行う。ユーザが携帯電話１０をゲート４０に翳した時点から、ゲート４０との処理状態を監視するために非接触ＩＣカード２０に問合せを行う。そして、非接触ＩＣカード２０は、ゲート４０との処理が終了すると、携帯電話１０に終了通知を返し、この結果携帯電話１０は非接触ＩＣカード２０に対し、要求が有れば送信するように指示し、非接触ＩＣカード２０は、これに応えてインストール要求を携帯電話１０に送信する（２−１）。または、非接触ＩＣカード２０は、ゲート４０との処理が終了すると、携帯電話１０に終了通知とともにインストール要求を携帯電話１０に送信する（２−１）。
【００３８】
（第２の実施形態）
本発明の第２の実施形態では、ＩＣカードとゲートとの認証成功を条件に、ＩＣカードに格納されたカードアプリの利用が、端末に対して許可される場合について説明する。
ゲートは、ＩＣカードとの認証に成功すると、ＩＣカードに、端末での利用を許容するカードアプリのＩＤと、ゲートを特定するゲートＰＩＮ情報とを伝え、このカードアプリＩＤとゲートＰＩＮとの対情報がＩＣカードに格納される。ＩＣカードは、端末からカードアプリを指定して、その利用が要求されたとき、この対情報を参照して、カードアプリの利用を許可するか否かを決定する。
【００３９】
図５は、この処理を連携して行う携帯電話１０、コンビカード２０及びゲート４０の構成について示している。コンビカード２０は、第１の実施形態（図１）と同様に、非接触通信手段（３）２２、接触通信手段（２）２１、認証情報ＤＢ２５、認証アプリ２４及びＣＰＵ２３を備え、さらに、ゲート４０との認証に成功した場合に有効になるカードアプリ２８と、カードアプリＩＤとゲートＰＩＮとの対情報を格納するＰＩＮＤＢ２９とを備えている。また、携帯電話１０は、接触通信手段（１）１１、ＣＰＵ１２の他に、カードアプリ２８を利用する端末アプリ１４を備えている。ゲート４０の構成は第１の実施形態（図１）と変わりが無い。
【００４０】
このコンビカード２０の認証情報ＤＢ２５には、図６に示すように、ゲートアプリ４３のＩＤと対応付けて、認証処理に使用する認証情報と、ゲートＰＩＮの設定が可能な（即ち、ゲート４０から入場したエリアで利用可能な）カードアプリのＩＤと、ＰＩＮ設定を解除する（即ち、そのエリアで利用できなくなる）カードアプリのＩＤとが格納されている。
【００４１】
ゲート４０から入場したエリアで利用可能になるカードアプリ２８は、例えば、所内の内線番号電話帳アプリであり、コンビカード２０とゲート４０との認証が成功すると、携帯電話１０の電話帳機能を実行する端末アプリ１４からコンビカード２０に格納された内線簿にアクセスできるようになる。
【００４２】
図７は、このゲート４０、コンビカード２０及び携帯電話１０が連携して行う処理のシーケンスを示している。
【００４３】
ユーザがコンビカード２０を装着した携帯電話１０をゲート４０に翳すと、ゲート４０は、コンビカード２０に認証アプリＩＤとゲートアプリＩＤとを示して相互間の認証処理を要求する（１−１）。これを受けてコンビカード２０の認証アプリ２４は、認証情報ＤＢ２５のゲートアプリＩＤに対応する認証情報を用いて、ゲートアプリ４３との認証処理を実行する（１−２）。認証処理に成功したゲートアプリ４３は、ゲートＰＩＮを設定したい（または削除したい）カードアプリのＩＤとゲートＰＩＮとを提示して、カードアプリＩＤとゲートＰＩＮとの対情報の登録（または削除）を認証アプリ２４に要求する（１−３）。このときゲートアプリ４３が提示するカードアプリＩＤの数は、複数であっても良い。
【００４４】
コンビカード２０の認証アプリ２４は、そのカードアプリＩＤに該当するカードアプリ２８にゲートアプリＩＤとゲートＰＩＮとの情報を送り、確認（検証）を要求する（２−１）。カードアプリ２８は、認証情報ＤＢ２５を参照して、ゲートアプリとの対応関係を有しているか否か（ゲートＰＩＮの設定が可能であるか否か）を検証し、検証結果を認証アプリ２４に返す（２−２）。認証アプリ２４は、検証結果がＯＫである場合に、検証されたカードアプリＩＤとゲートＰＩＮとの対情報をＰＩＮＤＢ２９に格納し（２−３）、検証結果をゲートアプリ４３に通知する（２−４）。以上がゲート通過時に行われる処理である。
【００４５】
一方、携帯電話１０の端末アプリ１４がカードアプリ２４を利用する場合には、次の処理が行われる。
【００４６】
携帯電話１０の端末アプリ１４は、カードアプリＩＤを提示して、コンビカード２０のカードアプリ２８にアクセスを要求する（３−１）。カードアプリ２８は、認証アプリ２４に、カードアプリＩＤを示して検証結果を要求する（３−２）。認証アプリ２４は、ＰＩＮＤＢ２９を参照し、そのカードアプリＩＤとゲートＰＩＮとの対情報が記録されているときはＯＫを応答し、記録されていないときはＮＧを応答する（３−３）。カードアプリ２８は、認証アプリ２４からの応答がＯＫである場合に、端末アプリ１４に対してアクセスを許可する（３−５）。
【００４７】
こうした処理により、ユーザが正しいゲート４０から入場した場合にのみ、カードアプリ２８の利用を可能にすることができ、例えば、ユーザがコンビカード２０等のＩＣカードを装着した携帯電話１０を正規のゲート４０に翳してオフィスに入場すると、ＩＣカードに格納されたオフィス用の内線番号電話帳アプリが自動的に有効になる。
【００４８】
なお、ゲートアプリ４３から提示されたカードアプリＩＤがＰＩＮ設定を解除するカードアプリＩＤとして認証情報ＤＢ２５に記録されている場合には、認証アプリ２４は、ＰＩＮＤＢ２９を参照し、そこに記録されているカードアプリＩＤとゲートＰＩＮとの対情報を削除する。
【００４９】
このようにＰＩＮＤＢ２９の削除処理を併せて行うことにより、例えば、ユーザが、入門処理をして、あるオフィスに入場した後、別のオフィスに入門処理をして入場した場合に、先のオフィス用の内線番号電話帳アプリが無効になり、後から入場したオフィス用の内線番号電話帳アプリだけが有効になる。
【００５０】
なお、各処理のメッセージ及びデータは、第三者の盗聴を防ぐために暗号化して送信するようにしても良い。
【００５１】
また、図７において、（２−３）の検証結果の格納は、カードアプリＩＤの検証結果がＯＫであることを示す情報だけをＰＩＮＤＢ２９に格納するようにしても良い。
【００５２】
また、コンビカード２０等のＩＣカードは、接触通信機能のみを有するものであっても良い。この場合には、第１の実施形態（図４）で説明したように、携帯電話１０のローカル通信手段を利用してＩＣカードとゲートとの通信を行う。また、ＩＣカードは、非接触通信機能のみを有するものであっても良い。
【００５３】
なお、図６に示す認証情報ＤＢ２５において、一つのゲートアプリＩＤに対し、複数のカードアプリＩＤが設定されている場合には、端末アプリ１４のアクセスを許容するカードアプリに優先度を設定することも可能である。この場合、図８に示すように、ゲートアプリＩＤに対応して、優先度設定可能なカードアプリＩＤ及び優先度設定を解除できるカードアプリＩＤの優先度を設定した優先設定ＤＢを保持する。あるいは、図９Ａに示すように、各カードアプリＩＤの優先度を優先度テンプレートで規定し、図９Ｂに示すようにゲートアプリＩＤに対応して優先度テンプレートを設定した優先設定ＤＢを保持する。
【００５４】
そして、認証情報ＤＢ２５から、ゲートアプリＩＤに対応するカードアプリ２８を選択する場合に、優先設定ＤＢを参照し、優先度に基づいて選択するカードアプリ２８を決定する。
【００５５】
（第３の実施形態）
本発明の第３の実施形態では、ＩＣカードとゲートとの認証成功を条件に、ＩＣカードに格納されたカードアプリの利用が、端末に対して許可される第２の実施形態の構成において、ＩＣカード、ゲート及び端末の三者間での処理が、第２の実施形態と異なる手順で行われる場合について説明する。
【００５６】
ここでは、図１０に示すように、機器１が、非接触通信手段（１）１１０を有するドア１００であり、機器２が、非接触通信手段２２のみを有するＩＣカード２００であるものとして説明する。機器１、機器２及び機器３のその他の構成は、第２の実施形態（図５）と変わりがない。
ここでは、非接触通信手段２２のみを有するが、接触通信手段のみを有しても良い。
【００５７】
図１１は、ゲート４０、ＩＣカード２００及びドア１００が連携して行う処理のシーケンスを示している。
【００５８】
ユーザがＩＣカード２００をゲート４０に翳すと、ゲート４０は、ＩＣカード２００に認証アプリＩＤとゲートアプリＩＤとを示して相互間の認証処理を要求する（１−１）。これを受けてＩＣカード２００の認証アプリ２４は、認証情報ＤＢ２５のゲートアプリＩＤに対応する認証情報を用いて、ゲートアプリ４３との認証処理を実行する（１−２）。認証処理に成功したゲートアプリ４３は、ゲートＰＩＮを設定するカードアプリのＩＤとゲートＰＩＮとを提示して、カードアプリＩＤとゲートＰＩＮとの対情報の登録を認証アプリ２４に要求し（１−３）、ＩＣカード２００の認証アプリ２４は、要求に従ってカードアプリＩＤとゲートＰＩＮとの対情報をＰＩＮＤＢ２９に登録する（１−４）。この登録の段階では、認証情報ＤＢ２５との検証は済んでいない。以上がゲート通過時に行われる処理である。
【００５９】
一方、ユーザがＩＣカード２００をドア１００に翳すと、次の処理が行われる。
【００６０】
ドア１００の端末アプリ１４は、端末アプリＩＤとカードアプリＩＤとを提示して、ＩＣカード２００のカードアプリ２８へのアクセスを要求する（２−１）。カードアプリ２８は、認証アプリ２４に、カードアプリＩＤとゲートアプリＩＤとを示してＰＩＮＤＢ２９の登録情報を要求し（２−２）、認証アプリ２４は、ＰＩＮＤＢ２９から、該当するカードアプリＩＤ及びゲートＰＩＮの対情報を取得してカードアプリ２８に提示する（２−３）。カードアプリ２８は、認証情報ＤＢ２５を参照して、ゲートアプリとの対応関係を有しているか（ゲートＰＩＮの設定が可能であるか）を検証し（２−４）、検証結果がＯＫである場合に、端末アプリ１４にアクセスを許可する（２−５）。
【００６１】
カードアプリ２８にアクセスしたドア１００の端末アプリ１４は、例えば、カードアプリ２８から鍵情報を取得してドア１００を開錠し、ユーザは、ドア１００の通過が可能になる。
【００６２】
このように、ゲート４０、ＩＣカード２００及びドア１００が連携することにより、正しい玄関（ゲート）から入らないと、ドアが開かないようにすることができる。
【００６３】
また、このＰＩＮ検証（２−４）では、カードアプリ２８が、端末アプリ１４とゲートＰＩＮとのペアを検証することも可能であり、この場合には、ある端末アプリ１４について、特定のゲートＰＩＮと対応していなければアクセスを許可しない（即ち、あるドアは特定の入口から入らないと開かない）と言う制御を行うこともできる。
【００６４】
また、図１２に示すように、ドア１００にＰＩＮ入力部１５を設け、ユーザがＰＩＮ入力部１５から入力したユーザＰＩＮをさらに検証して、ドア１００を開けるように制御することもできる。
【００６５】
図１３は、この場合のシーケンスを示している。ゲートＰＩＮを検証する（２−４）までの処理は、図１１の場合と同じである。ゲートＰＩＮの検証結果がＯＫである場合に、カードアプリ２８は、ドア１００にユーザＰＩＮを要求し（２−５）、ユーザがＰＩＮ入力部１５からユーザＰＩＮを入力すると（２−６）、カードアプリ２８は、ＩＣカード２００のＰＩＮＤＢ２９で保持されたユーザＰＩＮと照合して、それを検証する（２−７）。そして、検証結果が一致する場合に、端末アプリ１４に対してアクセスを許可する（２−８）。
【００６６】
（第４の実施形態）
本発明の第４の実施形態では、ＩＣカードとゲートとの認証処理が成功したことを条件に、機器の処理が可能になる場合について説明する。
【００６７】
ＩＣカードは、ゲートとの認証処理が成功すると、ゲートからゲートＰＩＮを取得し、このゲートＰＩＮを機器に送信する。機器は、ゲートＰＩＮの検証が終了した後、処理を開始する。
【００６８】
図１４は、ゲート４０、コンビカード２０及び携帯電話１０の構成と、機器（機器４）が金庫５０である場合の構成とを示している。このコンビカード２０を装着した携帯電話１０をゲート４０に翳し、コンビカード２０とゲート４０との認証処理を行う。認証が成功した場合に、この携帯電話１０を金庫５０に翳し、また、携帯電話１０からユーザＰＩＮを入力することにより、金庫５０の開錠が可能になる。
【００６９】
金庫５０は、コンビカード２０への非接触通信を行う非接触通信手段（５）５１と、金庫５０の鍵の開閉を制御する鍵アプリ５３と、金庫５０の動作を制御するＣＰＵ５２とを備えている。ゲート４０、コンビカード２０及び携帯電話１０の構成は、第２の実施形態（図１０）と変わりがない。
【００７０】
コンビカード２０を装着した携帯電話１０をゲート４０に翳すと、ゲート４０とコンビカード２０との間で、図１３の（１−１）から（１−４）までの処理が行われる。
【００７１】
図１５は、その後、ユーザが、コンビカード２０を装着した携帯電話１０を金庫５０に翳したときの処理シーケンスを示している。
【００７２】
金庫５０の鍵アプリ５３は、カードアプリＩＤを示して、コンビカード２０にカードアプリ２９へのアクセスを要求する（３−１）。カードアプリ２９は、カードアプリＩＤ及び鍵アプリＩＤを提示して、認証アプリ２４にゲートＰＩＮを要求する（３−２）。認証アプリ２４は、ＰＩＮＤＢ２９を参照し、カードアプリＩＤに対応するゲートＰＩＮ情報を取得してカードアプリ２９に返す（３−３）。
【００７３】
次に、カードアプリ２９は、携帯電話１０の端末アプリ１４にユーザＰＩＮを要求する（３−４）。端末アプリ１４は、ＰＩＮ入力画面を表示し、ユーザがＰＩＮを入力すると（３−５）、そのユーザＰＩＮをカードアプリ２９に送信する（３−６）。カードアプリ２９は、コンビカード２０のＰＩＮＤＢ２９で保持されているユーザＰＩＮ情報と照合して、それを検証する（３−７）。ユーザＰＩＮの検証結果が一致した場合は、ゲートＰＩＮを金庫の鍵アプリ５３に送信する（３−８）。鍵アプリ５３は、予め保持するゲートＰＩＮ情報と、カードアプリ２９から送られたゲートＰＩＮとを照合して検証し（３−９）、検証結果が一致する場合に、開錠処理を実行する（３−１０）。
【００７４】
このように、例えば、ゲート４０が玄関に設置されている場合では、玄関での入門処理が正しく行われたときにのみ、金庫５０の鍵が使えることになる。
【００７５】
なお、ユーザＰＩＮやゲートＰＩＮの検証を行う時期、あるいは、検証を行う主体等については、種々の変更が可能である。例えば、鍵アプリ５３がゲートＰＩＮの検証（３−９）を行う代わりに、カードアプリ２９が、ユーザＰＩＮ検証（３−８）とともに、ゲートＰＩＮの検証を行い、検証結果を鍵アプリ５３に伝えるようにしても良い。
【００７６】
また、カードアプリ２９がユーザＰＩＮ検証（３−８）を行う代わりに、入力されたユーザＰＩＮを鍵アプリ５３に送り、鍵アプリ５３が、金庫５０に登録されたユーザＰＩＮと照合してユーザＰＩＮ検証を行うようにしても良い。
【００７７】
また、図１６に示すように、ＰＩＮ登録（４−４）を終了した認証アプリ２４が、端末アプリ１４にユーザＰＩＮを要求し（４−５）、入力されたユーザＰＩＮをそのままＰＩＮＤＢ２９に登録（４−８）するようにしても良い。この場合は、図１７に示すように、携帯電話１０を金庫５０に翳した段階で、カードアプリ２９が、ＰＩＮＤＢ２９からゲートＰＩＮ及びユーザＰＩＮを取得し（５−３）、ユーザＰＩＮを検証し（５−４）、ゲートＰＩＮを金庫５０の鍵アプリ５３に送る（５−５）。この方式では、ユーザのＰＩＮ入力が事前に済んでいるため、金庫５０の前でのユーザの入力操作が不要になる。
【００７８】
また、図１８に示すように、ＰＩＮ登録（４−４）が終了した時点で、認証アプリ２４がＰＩＮ登録通知（ゲートアプリＩＤ）をカードアプリ２９に対し行ない（４−５）、その通知を受けたカードアプリ２８が、携帯電話１０に対しカードアプリＩＤを渡しながらユーザＰＩＮを要求する（４−６）。携帯電話１０の端末アプリ１４は、ユーザＰＩＮを入力し（４−７）、ユーザＰＩＮをコンビカード２０のカードアプリ２８に対し送信する。コンビカード２０では、カードアプリ２８が入力されたユーザＰＩＮを検証して（４−９）、ユーザＰＩＮの認証結果を認証アプリ２４に送信する。認証アプリ２４では、カードアプリ２８からのユーザＰＩＮの検証結果を登録する（４−１１）ようにしてもよい。この場合は、図１９に示すように、携帯電話１０を金庫５０に翳した段階で、ユーザの検証結果をチェックする（５−４）だけで足りる。この方式では、ユーザＰＩＮ検証が早い段階で行われるため、ユーザがＰＩＮ入力を間違えていた場合に、早い段階で修正できる。
【００７９】
また、図２０は、コンビカード（機器２）のカードアプリ（アプリ２）が、ユーザＰＩＮ要求と、ゲートＰＩＮ検証と、ユーザＰＩＮ検証とを行う場合のシーケンスを示している。
【００８０】
また、図２１は、コンビカード（機器２）のカードアプリ（アプリ２）が、ユーザＰＩＮ要求と、ユーザＰＩＮ検証とを行い、金庫（機器４）の鍵アプリ（アプリ５）がゲートＰＩＮ検証を行う場合のシーケンスを示している。
【００８１】
また、図２２は、コンビカード（機器２）のカードアプリ（アプリ２）が、ユーザＰＩＮ要求と、ゲートＰＩＮ検証とを行い、金庫（機器４）の鍵アプリ（アプリ５）がユーザＰＩＮ検証を行う場合のシーケンスを示している。
【００８２】
また、図２３は、コンビカード（機器２）の認証アプリ（アプリ３）が、ユーザＰＩＮ要求を行い、金庫（機器４）の鍵アプリ（アプリ５）がゲートＰＩＮ検証と、ユーザＰＩＮ検証とを行う場合のシーケンスを示している。
【００８３】
また、図２４は、ユーザＰＩＮ入力を金庫（機器４）から行い、金庫（機器４）の鍵アプリ（アプリ５）がゲートＰＩＮ検証と、ユーザＰＩＮ検証とを行う場合のシーケンスを示している。
【００８４】
また、図２５は、ユーザＰＩＮ入力を金庫（機器４）から行い、コンビカード（機器２）のカードアプリ（アプリ２）が、ユーザＰＩＮ検証を行い、金庫（機器４）の鍵アプリ（アプリ５）がゲートＰＩＮ検証を行う場合のシーケンスを示している。
【００８５】
また、図２６は、ユーザＰＩＮ入力を金庫（機器４）から行い、コンビカード（機器２）のカードアプリ（アプリ２）が、ゲートＰＩＮ検証を行い、金庫（機器４）の鍵アプリ（アプリ５）がユーザＰＩＮ検証を行う場合のシーケンスを示している。
【００８６】
コンビカード（機器２）のカードアプリ（アプリ２）でゲートＰＩＮを検証する場合は、ゲートＰＩＮが変わった場合に、カード内に格納されたゲートＰＩＮを変更すれば足りる。また、ゲートアプリ（アプリ４）と鍵アプリ（アプリ５）の組み合わせでアクセス制御を行うことができる。
【００８７】
また、金庫（機器４）の鍵アプリ（アプリ５）でゲートＰＩＮを検証する場合は、新しい金庫（機器４）が追加された時に、その金庫にゲートＰＩＮ情報を登録するだけで足りる。また、金庫を削除するときに、カードの設定を変える必要がない。
【００８８】
また、コンビカード（機器２）のカードアプリ（アプリ２）でユーザＰＩＮを検証する場合は、ユーザがユーザＰＩＮを変えたい場合に、コンビカード（機器２）に格納されているユーザＰＩＮを変更するだけで足り、わざわざユーザＰＩＮを換えたい機器（例えば金庫）のところに赴いて変えなくても済む。また、一つのユーザＰＩＮが複数の機器（ドアなど）に対応している場合でも、ドアごとにユーザＰＩＮを設定して回らなくて済む。また、図１８に示すように、ユーザＰＩＮを事前入力する場合に、ユーザＰＩＮの入力時に金庫（機器４）無しで検証が行えるので、金庫に翳してからユーザＰＩＮの再入力が必要になるような事態は発生しない。
【００８９】
また、金庫（機器４）の鍵アプリ（アプリ５）でユーザＰＩＮを検証する場合は、金庫でユーザＰＩＮを管理しているので、何人のユーザが登録されているのかが容易に把握できる。
【００９０】
また、本実施形態では、機器４を金庫、カードアプリとして鍵アプリを想定したが、機器４をビデオやセットトップボックス（ＳＴＢ）、カードアプリとして、決済カードアプリや、有料放送録画予約アプリ、有料放送受信操作アプリを想定してもよい。こうすることにより、正しく玄関の鍵の処理をしていないと、ＳＴＢ（ＰＣ）を介した決済処理（決済カードアプリ）ができない、ビデオ録画予約（その解除）（有料放送録画アプリ）ができない、といったサービスも可能である。
【００９１】
また、機器４を車の防犯モジュールとした場合、正しく玄関の鍵を閉じる処理をしたカードアプリと防犯モジュール（機器４）で正しいチェックイン処理をしないまま、車のドアを開けたり、車のエンジンをかけたり、車のオーディオを外したりすると防犯ベルが鳴るといったサービスも可能である。
【００９２】
なお、実施形態では、主に、ＩＣカードを携帯電話に装着する場合について説明したが、本発明はこれに限定されるものではない。携帯電話に代えて、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、メール端末、小型パーソナルコンピュータ、ゲーム機など、各種の端末装置・情報処理装置を用いることができる。また、ＩＣカードは、国際標準規格を満たすものでも、満たさないものでも使用可能である。セキュアデバイスの形状は、カード状でもチップ状でも良く、情報処理装置に埋め込む形態であっても良い。また、ＩＣカードは接触通信手段のみを有しても良い。
【００９３】
（第５の実施形態）
次に、本発明の第５の実施形態について説明する。第５の実施形態は、通信方式に応じてインストール可能なあるいは削除する端末アプリおよび設定命令の設定を変えるようにしたものである。なお、構成自体は、図１に示す実施形態１のものと同じであるので、図１を参照して説明する。
【００９４】
図１に示すように、第５の実施形態でも、第１の実施形態と同様に、端末（機器１）である携帯電話１０と、ＩＣカード（機器２）である携帯電話１０に装着されたチップ状のコンビカード２０と、ゲート機器（機器３）であるゲート４０から構成されている。
【００９５】
そして、第５の実施形態の場合、ＩＣカード（機器２）であるコンビカード２０が複数通信方式に対応した近距離無線通信機能を有する非接触通信手段２２を有しており、通信方式によってンストール可能なあるいは削除する端末アプリおよび設定命令の設定を変えるようにしている。
【００９６】
ここでは、一例として、会社の入場処理と退場処理とで、異なる通信方式を用いて端末アプリおよび設定命令の設定を変える例について説明する。
【００９７】
図２７は、第５の実施形態における会社の入場処理と退場処理とを例にした認証情報ＤＢ２５の一例を示す。
【００９８】
図２７の例では、通信方式としてＩＳＯ１４４４３ｔｙｐｅＡ等の独自通信方式Ａと、ＩＳＯ１４４４３ｔｙｐｅＢ等の独自通信方式Ｂとの２つがあり、独自通信方式Ａの場合、インストール可能な端末アプリＩＤとして端末アプリ１ＩＤ（個人用メーラ）および端末アプリ２ＩＤ（ゲーム）、インストール可能な設定命令ＩＤとして個人のネットワーク設定や、壁紙、通常通話モード等の設定命令５ＩＤ、削除する端末アプリＩＤとして端末アプリ３ＩＤ（内線番号閲覧ブラウザ）、削除する設定命令ＩＤとして（会社用設定である会社のネットワーク設定、壁紙、内線モード等の設定命令７ＩＤがあることを示している。
【００９９】
また、独自通信方式Ｂの場合、インストール可能な端末アプリＩＤとして端末アプリ１ＩＤ（会社用メーラ）および端末アプリ３ＩＤ（内線番号閲覧ブラウザ）があり、インストール可能な設定命令ＩＤとして設定命令７ＩＤ（会社用設定：会社のネットワーク設定、壁紙、内線モード）、削除する端末アプリＩＤとして端末アプリ１ＩＤ（個人用メーラ）および端末アプリ２ＩＤ（ゲーム）、削除する設定命令ＩＤとして設定命令５ＩＤ（個人のネットワーク設定、壁紙、通常通話モード）があるものとする。
【０１００】
これにより、同一のゲートアプリ４３から命令が来ても、あるいはアプリＩＤにかかわらず、通信方式に応じて、設定を変更することができる。
【０１０１】
例えば、図２７の例では、例えば、ＤＢテーブルのＩＤ１が出口、ＩＤ２が入り口の処理とする。ＩＤ１の入り口と、ＩＤ２の出口とでは、ゲートアプリＩＤは同じだが、通信方式が独自通信方式Ａと、独自通信方式Ｂとで異なるものとする。なお、ゲートアプリＩＤはなくてもよく、ゲートアプリＩＤでなく、ゲート機器ＩＤでもよい。
【０１０２】
この例の場合、個人用アプリとして、個人用メーラ（アプリ１）、ゲーム（アプリ２）、会社用アプリとして、会社用メーラ（アプリ４）、コンビカード２０内に格納された内線番号データにアクセスできる内線電話番号閲覧ブラウザ（アプリ３）があり、入口（２）と、出口（１）で削除またインストールされる。
【０１０３】
また、設定命令も、会社用、個人用があり、例えば、アクセス可能なネットワークの設定や、壁紙、通話モードなどが切り替えられる。
【０１０４】
次に図を参照して動作を説明する。
【０１０５】
図２８は、第５の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図である。
【０１０６】
本実施形態の場合、機器２であるコンビカード２０の非接触通信手段（３）２２が、機器３であるゲート４０の非接触通信手段（４）４１と非接触通信を行い、機器３であるゲート４０から機器２であるコンビカード２０に対し、処理要求が送信された場合（６−１）、コンビカード２０のＣＰＵ２３は、その非接触通信の通信方式を検出し（６−２）、機器３であるゲート４０との間で認証処理を行い（６−３）、認証情報ＤＢ２５の認証情報を参照して認証処理を確認する（６−４）。
【０１０７】
コンビカード２０のＣＰＵ２３は、認証処理が確認できた場合、機器３であるゲート４０に対し、認証した処理を通知する（６−５）。これにより、ゲート４０では、機器２であるコンビカード２０に対しインストールするアプリや設定命令を確認することができる。なお、この通知は、省略しても勿論よい。そして、ゲート４０は、その処理通知を受けて、通信方式に応じてゲートアプリ４３に対応したゲートを開く（６−６）。
【０１０８】
一方、コンビカード２０のＣＰＵ２３は、接触通信手段（２）２１を介し、機器１である携帯電話１０に対し、検出した通信方式に応じて、インストール可能なあるいは削除する端末アプリＩＤおよび設定命令ＩＤの設定要求を送信し（６−７）、認証処理を行う（６−８）。
【０１０９】
そして、認証できた場合には、コンビカード２０のＣＰＵ２３は、接触通信手段（２）２１を介し、機器１である携帯電話１０に対し、検出した通信方式に応じて、インストール可能なあるいは削除する端末アプリＩＤおよび設定命令ＩＤを送信し（６−９）、携帯電話１０では、コンビカード２０とゲート４０との間の通信方式に応じたインストール可能なあるいは削除する端末アプリＩＤおよび設定命令ＩＤを、機器２のＣＰＵ２３からの指示に従いインストールまたは削除し（６−１０）、その結果をコンビカード２０へ通知する（６−１１）。
【０１１０】
これにより、携帯電話１０へは、コンビカード２０とゲート４０との間の通信方式に応じた端末アプリＩＤおよび設定命令ＩＤをインストールしたり、あるいは通信方式に応じて削除することが可能となる。
【０１１１】
なお、コンビカード２０と機器１である携帯電話１０との間の認証処理は、インストール可能なあるいは削除する端末アプリＩＤおよび設定命令ＩＤの設定要求の前に行っても良い。また、コンビカード２０と機器１である携帯電話１０に装着した時点で認証処理する場合には、コンビカード２０と携帯電話１０との間の認証処理は、不要となる。
【０１１２】
このように、第５の実施形態によれば、通信方式に応じて、携帯電話１０にインストールや、携帯電話１０から削除する端末アプリや設定命令を変更することにより、場所だけでなく、通信方式に応じても、携帯電話１０の機能を変更することができる。
【０１１３】
なお、本実施形態では、通信方式に応じてインストール可能なあるいは削除する端末アプリおよび設定命令の設定を変える機能をＣＰＵ２３に持たせているが、認証アプリ２４にこのような機能を持たせるようにしても勿論良い。
【０１１４】
（第６の実施形態）
次に、本発明の第６の実施形態について説明する。第６の実施形態は、通信方式に応じて有効および無効（使用禁止）にするカードアプリを変えるようにしたものである。なお、構成自体は、カードアプリを使用する図５に示す第２の実施形態や、図１０に示す第３の実施形態、図１２に示す第３の実施形態のものと同じであるので、図１を参照して説明する。
【０１１５】
機器２であるコンビカード２０が、複数の近距離無線通信機能を有する非接触通信手段（３）２２を有する場合、通信方式によってカードアプリの有効または無効を変えることができる。ここで、カードアプリを無効にする、とは、例えば、Ｒ／Ｗ（リードライタ）からＩＣカードにＩＳＯ７８１６規格のセレクトコマンドを送っても、ＩＣカードから応答を返さない状態をいう。
【０１１６】
ここで、近距離無線によって、用途が限定される場合がある。例えば、ＩＳＯ１４４４３タイプＡは金融用途、ＩＳＯ１４４４３タイプＢは公共向け用途、ＪＩＣＳＡＰ２．０は交通向け等の特定エリア用途などと限定されている。
【０１１７】
このように、通信方式に応じて携帯電話１０の端末アプリ１４からコンビカード２０のカードアプリ２８へのアクセスを制限することで、ユーザが分野外のどのカードアプリ２８を格納しているかゲート４０等のＲ／Ｗ（リードライタ）に分からないようにする。例えば、カードアプリＩＤは公知なものなので、どのＲ／Ｗ（リードライタ）でも、ＩＳＯ７８１６規格のセレクトコマンドを送ると、コンビカード２０等のＩＣカードからの応答でカードアプリの有無が分かってしまう。
【０１１８】
つまり、公共のサービス用のＲ／Ｗ（リードライタ）が、そのユーザがどんなクレジットカードアプリをもっているかという個人情報を、ユーザに知られずに取得することが可能となる。
【０１１９】
そこで、この第６の実施形態では、通信方式に応じて、無効、すなわち使用禁止にするアプリＩＤを設定できるようにしたものである。
【０１２０】
図２９は、第６の実施形態の認証情報ＤＢ２５の内容の一例を示す図である。
【０１２１】
図２９において、通信方式がＩＳＯ１４４４３ｔｙｐｅＢの場合、無効にするアプリＩＤはカードアプリ３ＩＤ（クレジットカード）、通信方式がＩＳＯ１４４４３ｔｙｐｅＡの場合、無効にするアプリＩＤはカードアプリ１ＩＤ（運転免許証）、通信方式がＪＩＣＳＡＰ２．０の高速コマンド仕様の場合、無効にするアプリＩＤはカードアプリ３ＩＤ（クレジットカード）であるとする。
【０１２２】
次に図を参照して動作を説明する。
【０１２３】
図３０は、第６の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図である。
【０１２４】
本実施形態の場合、機器２であるコンビカード２０の非接触通信手段（３）２２が、機器３であるゲート４０の非接触通信手段（４）４１と非接触通信を行い、機器３であるゲート４０から機器２であるコンビカード２０に対し、リクエストコマンドが送信された場合（７−１）、コンビカード２０のＣＰＵ２３は、その非接触通信の通信方式を検出し（７−２）、通信方式を検出できた場合、応答コマンドを返す（７−３）。
【０１２５】
そして、機器３であるゲート４０からカードアプリのセレクトコマンドが送信された場合には（７−４）、コンビカード２０のＣＰＵ２３は、認証情報ＤＢ２５を参照してアクセス可否を確認し（７−５）、セレクトコマンド応答を、機器３であるゲート４０に対し返す（７−６）。
【０１２６】
つまり、コンビカード２０のＣＰＵ２３は、認証情報ＤＢ２５に格納された図２９の認証情報を参照し、ゲート４０から指定されたカードアプリＩＤが、コンビカード２０とゲート４０との間の通信方式に対応した無効にするアプリＩＤに指定されていなければ正常応答を返し、指定されていればエラー応答を、セレクトコマンド応答とし、ゲート４０に対し返すようにする。
【０１２７】
例えば、コンビカード２０とゲート４０との間の通信方式がＩＳＯ１４４４３ｔｙｐｅＢであり、ゲート４０から指定されたカードアプリＩＤが、カードアプリ３ＩＤ（クレジットカード）の場合は、図２９に示す認証情報ＤＢ２５の内容を参照すると、無効にするアプリＩＤであるため、コンビカード２０はゲート４０に対し、セレクトコマンド応答としてエラー応答を返す。通信方式がＪＩＣＳＡＰ２．０の高速コマンド仕様の場合も同様である。
【０１２８】
これに対し、コンビカード２０とゲート４０との間の通信方式がＩＳＯ１４４４３ｔｙｐｅＢであり、ゲート４０から指定されたカードアプリＩＤが、カードアプリ１ＩＤ（運転免許証）の場合は、図２９に示す認証情報ＤＢ２５の内容を参照すると、無効にするアプリＩＤには該当しないため、コンビカード２０はゲート４０に対し、セレクトコマンド応答として正常応答を返す。
【０１２９】
これにより、コンビカード２０とゲート４０との間の通信方式に応じて有効および無効（使用禁止）にするカードアプリ２８が変わるので、携帯電話１０の端末アプリ１４は、コンビカード２０とゲート４０との間の通信方式に応じて、コンビカード２０におけるカードアプリ２０にアクセスできる場合と、アクセスできない場合とが生じることになる。
【０１３０】
このように、第６の実施形態によれば、コンビカード２０とゲート４０との間の通信方式に応じてコンビカード２０内の端末アプリ２７の無効にするアプリＩＤを設定できるようにしたため、通信方式に応じてコンビカード２０等のＩＣカードへのアクセス制限をすることで、ユーザが分野外のどのアプリを格納しているかゲート４０等のＲ／Ｗ（リードライタ）に分からないようにすることができる。
【０１３１】
なお、この第６の実施形態では、通信方式に応じて無効にするアプリＩＤを指定するように説明したが、この第６の実施形態と、前述の第５の実施形態とを組み合わせて、機器２であるコンビカード２０と、機器３であるゲート４０との間の１回の通信方式の検出および認証処理により、通信方式に応じて、インストールまたは削除する端末アプリＩＤおよび設定命令ＩＤ、および無効にするアプリＩＤを同時に変えるようにしても勿論よい。
【０１３２】
また、この第６の実施形態では、機器２であるコンビカード２０のＣＰＵ２３にコンビカード２０とゲート４０との間の通信方式に応じてコンビカード２０内の端末アプリ２７の無効にするアプリＩＤを設定する機能を持たせたが、コンビカード２０の認証アプリ２４等にかかる機能を持たせても勿論良い。
【０１３３】
（第７の実施形態）
次に、本発明の第７の実施形態について説明する。第７の実施形態は、前回、機器２であるコンビカード２０と機器１である携帯電話１０との間で有効にした設定が正しく無効化されていれば、今回、機器３であるゲート４０と、機器２であるコンビカード２０との認証を許可するようにしたものである。
【０１３４】
図３１は、第７の実施形態の構成を示すブロック図である。
【０１３５】
この第７の実施形態では、機器２であるコンビカード２０に端末設定管理部２１０を設け、端末設定管理部２１０により前回の機器１である携帯電話１０と機器２であるコンビカード２０で有効にした設定が、正しく無効化されていれば、今回、機器３であるゲート４０と機器２であるコンビカード２０との間の認証を許可するようにしたものである。なお、端末設定管理部２１０は、認証アプリ２４と一体でも勿論よいし、ＣＰＵ２３と一体でも勿論よい。その他の構成は、図１に示す実施形態１等のものと同じであるので、図１の構成と同一符号を付して説明を省略する。
【０１３６】
図３２に、第７の実施形態の認証情報ＤＢ２５に設定されたデータの一例を示す。
【０１３７】
認証情報ＤＢ２５には、ＩＤ１、ＩＤ２それぞれのデータが設定されている。
【０１３８】
ＩＤ１の場合、ｗｗｗ．ａｐｐ．ｃｏ．ＪＰ／ｇａｔｅ１、通信方式はＩＳＯ１４４４３ｔｙｐｅＢ、有効時間は５；００時間、インストール可能な端末アプリＩＤおよび設定命令ＩＤとして端末アプリ３ＩＤ（内線番号閲覧ブラウザ）および設定命令７ＩＤ（会社用設定：会社のネットワーク設定、壁紙、内線モード）、削除する端末アプリＩＤおよび設定命令ＩＤとして端末アプリ２ＩＤ（ゲーム）および設定命令５ＩＤ（個人のネットワーク設定、壁紙、通常通話モード）が設定されている。
【０１３９】
また、ＩＤ２の場合、ｗｗｗ．ａｐｐ．ｃｏ．ＪＰ／ｇａｔｅ２、通信方式はＵＷＢ（Ｕｌｔｒａ ＷＩＤｅ Ｂａｎｄ）、有効時間は制限なし、インストール可能な端末アプリＩＤおよび設定命令ＩＤとして端末アプリ２ＩＤ（ゲーム）および設定命令５ＩＤ（個人のネットワーク設定、壁紙、通常通話モード）、削除する端末アプリＩＤおよび設定命令ＩＤとして端末アプリ３ＩＤ（内線番号閲覧ブラウザ）および設定命令７ＩＤ（会社用設定：会社のネットワーク設定、壁紙、内線モード）が設定されている。
【０１４０】
図３３に、第７の実施形態の端末設定管理部２１０に設定されたデータの一例を示す。
【０１４１】
端末設定管理部２１０に設定されたデータでは、ＩＤ１として、機器３のＩＤがｗｗｗ．ａｐｐ．ｃｏ．ｊｐ／ｇａｔｅｔｅｒｍｉｎａｌ１、ゲートアプリＩＤがｗｗｗ．ａｐｐ．ｃｏ．ｊｐ／ｇａｔｅａｐｐ１、機器１のＩＤがｗｗｗ．ａｐｐ．ｃｏ．ｊｐ／ｔｅｒｍｉｎａｌ１、設定時のタイムスタンプが２００４／１２／２４ １５：３２：０２、有効時間が５：００時間、認証情報ＤＢ２５のＩＤが１、インストールした時の端末アプリＩＤが端末アプリ３ＩＤ（内線番号閲覧ブラウザ）、インストールした設定命令ＩＤが設定命令７ＩＤ（会社用設定：会社のネットワーク設定、壁紙、内線モード）、削除した端末アプリＩＤが端末アプリ２ＩＤ（ゲーム）、削除した設定命令ＩＤが設定命令５ＩＤ（個人のネットワーク設定、壁紙、通常通話モード）、設定処理結果が正常である、等のデータが、認証アプリ２４から端末設定管理部２１０への設定通知処理により格納される（図３４の８−１４）。
【０１４２】
それ以外に、端末設定管理部２１０に設定されたデータでは、図３３に示すように、復活通知時のタイムスタンプとして２００４／１２／２４ ２０：３２：０２、復活処理結果として正常が、機器１のＣＰＵ１２から機器２の認証アプリ２４への復活通知結果に基づく認証アプリ２４から端末設定管理部２１０への復活結果通知処理により格納される（図３４の８−２０）。
【０１４３】
次に図を参照して動作を説明する。
【０１４４】
図３４は、第７の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図である。
【０１４５】
まず、インストール時の処理から説明すると、本実施形態の場合、機器２であるコンビカード２０の非接触通信手段（３）２２が、機器３であるゲート４０の非接触通信手段（４）４１と非接触通信を行い、機器３であるゲート４０のゲートアプリ４３から機器２であるコンビカード２０の認証アプリ２４に対し、認証要求が送信された場合（８−１）、コンビカード２０の認証アプリ２４は、機器３であるゲート４０との間で認証処理を行う（８−２）。
【０１４６】
そして、認証処理がＯＫであった場合、コンビカード２０の認証アプリ２４は、前回の結果を端末設定管理部２１０に対し要求し（８−３）、端末設定管理部２１０は、前回の結果がＯＫであれば、認証アプリ２４に対し前回結果ＯＫを返す（８−４）。
【０１４７】
すると、認証アプリ２４は、ゲート４０のゲートアプリ４３に対し、前回結果ＯＫを通知して（８−５）、ゲート４０のゲートアプリ４３は、ゲートをオープンにする（８−６）。なお、機器２であるコンビカード２０と、機器３であるゲート４０との間の非接触通信での認証時に前回の端末設定の結果を取得した際、前回有効にした設定が正しく無効化されていない場合は、認証を許可しないようにする。
【０１４８】
また、コンビカード２０の認証アプリ２４は、前回結果ＯＫの場合、機器１である携帯端末１０に対しインストール要求を送信し（８−７）、携帯端末１０のＣＰＵ１２との間で認証処理を実行する（８−８）。
【０１４９】
認証処理がＯＫの場合、コンビカード２０の認証アプリ２４は、機器１である携帯端末１０に対し、端末アプリ２７を送信し（８−９）、携帯端末１０はその端末アプリ２７を受信してインストールする（８−１０）。
【０１５０】
そして、携帯端末１０のＣＰＵ１２は、コンビカード２０から受信した端末アプリ２７がインストールできた場合は、インストール結果ＯＫの通知をコンビカード２０の認証アプリ２４に対し行ない（８−１１）、認証アプリ２４は、端末設定管理部２１０に対し設定通知を行なう（８−１３）。
【０１５１】
端末設定管理部２１０は、認証アプリ２４からの設定通知により、図３３に示すＩＤ、機器３のＩＤ、ゲートアプリＩＤ、機器１のＩＤ、設定時のタイムスタンプ、有効時間、認証情報ＤＢのＩＤ、インストールした時の端末アプリＩＤ、インストールした設定命令ＩＤ、削除した設定命令ＩＤ、設定処理結果を格納し（８−１４）、かかるデータの格納後、格納結果ＯＫの通知を認証アプリ２４に対し行う（８−１５）。
【０１５２】
一方、携帯端末１０では、ンストール結果ＯＫの通知をコンビカード２０の認証アプリ２４に対し行なった（８−１１）後、タイマー管理を行う（８−１６）。ここで、このタイマー管理を行う代わりに、コンビカード２０の端末設定管理部２１０が認証アプリ２４に対し格納結果を通知（８−１５）した後に、認証アプリ２４がタイマー管理を行い、後述する機器１の携帯端末１０における復活処理（８−１７）の前に機器２の認証アプリ２４から機器１のＣＰＵ１２に対し復活命令を行うようにしても良い。これで、インストール時の処理が終了する。
【０１５３】
一方、復活時の処理は、機器１である携帯端末１０にて、復活処理、すなわちインストールした端末アプリ・設定命令の削除処理を行った場合（８−１７）、携帯端末１０のＣＰＵ１２は、復活結果ＯＫの通知をコンビカード２０の認証アプリ２４に対し行う（８−１８）。
【０１５４】
ここで、復活時の処理の際、インストールされた端末アプリを削除するが、例えば、有効時間内に出口処理をした場合などは、インストールされた端末アプリがすでに削除されている場合もある。このような場合にも、復活結果ＯＫ、もしくは削除済みをコンビカード２０の認証アプリ２４に対し行うようにする。
【０１５５】
機器２であるコンビカード２０の認証アプリ２４は、携帯端末１０のＣＰＵ１２からの復活結果ＯＫの通知を受けて、復活結果通知を端末設定管理部２１０へ送信する（８−１９）。
【０１５６】
端末設定管理部２１０では、認証アプリ１９からの復活結果通知を受けると、例えば、図３３に示す復活通知時のタイムスタンプ、および復活処理結果を認証情報に格納し（８−２０）、格納結果ＯＫであれば、その格納結果ＯＫを認証アプリ２４に通知する（８−２１）。
【０１５７】
なお、よりセキュアにするためには、携帯端末１０のＣＰＵ１２から機器２であるコンビカード２０の認証アプリ２４に対する復活結果ＯＫの通知処理（８−１８）の前か後ろに認証処理を入れるようにしても勿論良い。
【０１５８】
このように、第７の実施形態によれば、前回、機器２であるコンビカード２０と機器１である携帯電話１０との間で有効にした設定が正しく無効化されていれば、今回、機器３であるゲート４０と、機器２であるコンビカード２０との認証を許可する一方、前回、機器２であるコンビカード２０と機器１である携帯電話１０との間で有効にした設定が正しく無効化されていない場合には、今回、機器３であるゲート４０と機器２であるコンビカード２０との認証を許可しないようにしたので、毎回、毎回、機器１と機器２との間で有効にした設定が正しく無効にしたかを確認してから、機器３と機器２との認証を許可することができ、よりセキュリティを向上させることができる。
【０１５９】
また、この第７の実施形態では、端末設定管理部２１０は、前回の端末設定の結果を管理する際、設定した内容である設定命令やインストールを認証情報に格納すると共に、有効時間後に削除（無効化）命令を出して削除を確認すると共に、端末１である携帯端末１０がタイマー管理しているその有効時間に基づいて削除管理通知を受け付け、前回の設定である図３３に示す設定内容等を履歴として認証情報に格納するようにしたので、次回ゲート認証時にその認証情報を参照することにより確実に前回の履歴を提供することができる。
【０１６０】
なお、この第７の実施形態では、認証アプリ２４とは別に、端末設定管理部２１０を設けて説明したが、端末設定管理部２１０は、認証アプリ２４と一体、すなわちその一機能として設けたり、さらにはＣＰＵ２３と一体、すなわちその一機能として設けるようにしても勿論よい。
【０１６１】
（第８の実施形態）
次に、本発明の第８の実施形態について説明する。第８の実施形態は、機器１である携帯電話のメモリ容量確保等のため、携帯電話の端末アプリを退避させた場合、機器２であるコンビカードがその端末アプリを関して、設定解除処理の際に、インストールし直すようにしたものである。
【０１６２】
図３５は、第８の実施形態の構成を示すブロック図である。
【０１６３】
図３５において、第８の実施形態の場合、機器１である携帯電話１０は、携帯電話１０における端末アプリの退避を管理する端末アプリ退避管理部１２０をさらに有している。また、機器２であるコンビカード２０は、携帯電話１０における端末アプリの退避を管理した際の端末の設定を管理する端末設定管理部２２０をさらに有している。なお、その他の構成は、図１などに示すものと同じであるので、同一符号を付してその説明は省略する。
【０１６４】
つまり、この第８の実施形態では、携帯電話１０からの端末アプリの退避する場合は、機器２であるコンビカード２０からインストール要求受信時に、携帯電話１０の端末メモリ（図示せず）の容量が少なく、新たに端末アプリ２７をインストールできない場合は、端末設定管理部２２０と、端末アプリ退避管理部１２０とで、認証を行う。そして、その認証に成功すれば、携帯電話１０がインストールしている端末アプリと、その端末アプリが保持するデータとを、端末設定管理部２２０が機器１の端末アプリ退避管理部１２０からしかアクセスできないセキュアな領域、例えば、ＩＣカード２０のタンパ領域またはＩＣカード２０の暗号化されたフラッシュメモリ領域などに格納する。また、認証時に鍵生成を行い、その鍵情報に基づいて暗号化して保存してもよい。
【０１６５】
機器１である携帯電話１０にて退避する端末アプリの選択方法は、機器１で端末アプリに優先順位をつけて保持しておく、あるいは機器２であるコンビカード２０から例えば、インストール要求に含めて退避するアプリを指定する等がある。
【０１６６】
一方、復活時は、機器２であるコンビカード２０から設定解除命令時に、コンビカード２０に退避されたアプリがあれば、設定解除処理確認後に、退避された端末アプリの復活命令を送り復活のための認証処理を行わせる。そして、端末設定管理部２２０と端末アプリ退避管理部１２０との間で認証を行い、その認証が成功すれば、退避された端末アプリと、そのデータとを端末アプリ退避管理部１２０に送信し、端末アプリ退避管理部１２０がその端末アプリの再インストール、端末アプリデータのリストアを行う。
【０１６７】
なお、この第８の実施形態においても、前述の第７の実施形態と同様に、機器２であるコンビカード２０と、機器３であるゲートとの間の非接触通信での認証時に、前回の端末設定の結果を取得して、前回機器１と機器２との間で有効にした設定が正しく無効化されている場合のみ、今回の機器２であるコンビカード２０と機器３であるゲートとの間の認証を許可するようにしても勿論よい。
【０１６８】
次に図を参照して動作を説明する。
【０１６９】
図３６は、第８の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図である。
【０１７０】
まず、端末アプリおよびそのデータの退避時の処理から説明すると、本実施形態の場合、機器２であるコンビカード２０の非接触通信手段（３）２２が、機器３であるゲート４０の非接触通信手段（４）４１と非接触通信を行い、機器３であるゲート４０のゲートアプリ４３から機器２であるコンビカード２０の認証アプリ２４に対し、認証要求が送信された場合（９−１）、コンビカード２０のＣＰＵ２３は、機器３であるゲート４０との間で認証処理を行う（９−２）。
【０１７１】
そして、認証処理がＯＫであった場合、コンビカード２０の認証アプリ２４は、前回の結果を端末設定管理部２２０に対し要求し（９−３）、端末設定管理部２２０は、前回の結果がＯＫであれば、認証アプリ２４に対し前回結果ＯＫを返す（９−４）。
【０１７２】
すると、認証アプリ２４は、ゲート４０のゲートアプリ４３に対し、前回結果ＯＫを通知して（９−５）、ゲート４０のゲートアプリ４３は、ゲートをオープンにする（９−６）。なお、この機器２であるコンビカード２０と機器３であるゲート４０との間の非接触通信での認証時に前回の端末設定の結果を取得した際、前回有効にした設定が正しく無効化されていない場合は、認証を許可しないようにする。
【０１７３】
また、コンビカード２０の認証アプリ２４は、前回結果ＯＫと判断された場合、機器１である携帯端末１０に対しインストール要求を送信する（９−７）。
【０１７４】
すると、携帯端末１０のＣＰＵ１２は、端末アプリ退避管理部１２０に対しインストール可否を問い合わせ（９−８）、端末アプリ退避管理部１２０がインストールの可否を判断する（９−９）。そして、インストール可と判断した場合、端末アプリ退避管理部１２０は、コンビカード２０の端末設定管理部２２０に対し、アプリ退避要求を送信して（９−１０）、端末アプリ退避管理部１２０と端末設定管理部２２０との間で認証処理を行う（９−１１）。
【０１７５】
その認証結果がＯＫの場合、端末アプリ退避管理部１２０は、携帯電話１０から退避させるべき端末アプリおよびそのデータを、コンビカード２０側の例えば端末設定管理部２２０に対し送信し（９−１２）、端末設定管理部２２０に退避させるべき端末アプリおよびそのデータを格納させる（９−１３）。
【０１７６】
そして、その格納処理が無事終了した場合、コンビカード２０の端末設定管理部２２０は、格納ＯＫの結果通知を、携帯端末１０の端末アプリ退避管理部１２０に対し送信し（９−１４）、端末アプリ退避管理部１２０は、ＣＰＵ１２に対し応答可かを返信する（９−１５）。
【０１７７】
すると、携帯電話１０のＣＰＵ１２は、コンビカード２０の認証アプリ２４との間で認証処理を実行し（９−１６）、その認証処理がＯＫの場合には、コンビカード２０の認証アプリ２４から携帯電話１０のＣＰＵ１２に対し新たにインストールする端末アプリが送信され（９−１７）、送信された端末アプリを受信してインストールする（９−１８）。
【０１７８】
携帯電話１０のＣＰＵ１２は、コンビカード２０から受信した端末アプリ２７がインストールできた場合は、インストール結果ＯＫの通知をコンビカード２０の認証アプリ２４に対し行ない（９−１９）、認証アプリ２４は端末設定管理部２２０に対し設定通知を行なう（９−２０）。
【０１７９】
端末設定管理部２２０は、認証アプリ２４からの設定通知により、第７の実施形態と同様に、図３３に示すＩＤ、機器３のＩＤ、ゲートアプリＩＤ、機器１のＩＤ、設定時のタイムスタンプ、有効時間、認証情報ＤＢのＩＤ、インストールした時の端末アプリＩＤ、インストールした設定命令ＩＤ、削除した設定命令ＩＤ、設定処理結果を格納する（９−２１）。
【０１８０】
端末設定管理部２２０は、かかるデータの格納後、格納結果ＯＫの通知を認証アプリ２４に対し行う（９−２２）。これで、携帯電話１０において先に保存されている端末アプリをコンビカード２０へ退避しての新たな端末アプリのインストール時の処理が終了する。なお、第７の実施形態と同様に、コンビカード２０では、端末設定管理部２２０は、認証アプリ２４またはＣＰＵ２３と一体でも勿論よい。
【０１８１】
次に、復活時の処理について説明する。
【０１８２】
復活時の処理は、機器１である携帯端末１０のＣＰＵ１２が、まず、タイマー管理によりインストールした端末アプリの削除処理を行い（９−２３）、その削除処理が終了した場合、端末アプリ退避管理部１２０に対し、復活要または不要の問い合わせを行う（９−２４）。
【０１８３】
端末アプリ退避管理部１２０は、その問い合わせを受けて、復活要または不要の判断を行い（９−２５）、端末アプリを退避させており復活をする必要がある場合は、コンビカード２０の端末設定管理部２２０に対し復活要急を送信し（９−２６）、端末アプリ退避管理部１２０と端末設定管理部２２０との間で認証処理を行う（９−２７）。
【０１８４】
その認証処理の結果、認証がＯＫの場合は、端末設定管理部２２０は端末アプリ退避管理部１２０に対し退避させていた端末アプリおよびその端末データのデータを送信し（９−２８）、端末アプリ退避管理部１２０はその退避させていた端末アプリおよびその端末データのデータを受信してメモリ等にインストールして復活し（９−２９）、復活結果を端末設定管理部２２０に対し送信する（９−３０）。
【０１８５】
すると、端末設定管理部２２０は、端末アプリ退避管理部１２０からの復活結果を、例えば、図３３に示す認証情報等に格納し（９−３１）、格納結果ＯＫであれば、その格納結果ＯＫを端末アプリ退避管理部１２０へ通知する（９−３２）。端末アプリ退避管理部１２０は、ＣＰＵ１２に対し復活完了通知を行い（９−３３）、復活時の処理が終了する。
【０１８６】
なお、端末アプリ退避管理部１２０と端末設定管理部２２０との間の認証処理（９−１１）は、端末アプリ退避管理部１２０から端末設定管理部２２０へのアプリ退避要求（９−１０）の前でもよく、携帯電話１０のＣＰＵ１２と、コンビカード２０の認証アプリ２４との間の認証処理（９−１６）は、認証アプリ２４から携帯電話１０のＣＰＵ１２へのインストール要求（９−７）の前でもよい。また、復活時の処理における端末アプリ管理部１２０と認証アプリ２４との間における認証処理は、ＣＰＵ１２から復活要または不要の問い合わせを受ける（９−２４）前に実行しても良い。さらに、機器２であるコンビカード２０を機器１である携帯電話１０に装着した時点で認証する形態をとる場合には、端末アプリ退避管理部１２０と端末設定管理部２２０との間の認証処理（９−１１，９−２７）や、携帯電話１０のＣＰＵ１２と認証アプリ２４との間の認証処理（９−１６）などは、不要となり、省略しても良い。
【０１８７】
また、機器２であるコンビカード２０にタイマー機能がある場合には、コンビカード２０で時間管理を行い、設定時間になると、機器１のＣＰＵ１２によるタイマー管理による削除処理（９−２３）の前に、機器２から機器１にタイマー機能に基づき削除命令を送って、機器１ではこの削除命令により削除処理を行うようにしてもよい。この場合、機器２の端末設定管理部２２０と、機器１の端末アプリ退避管理部１２０との間の認証処理（９−２５）は、機器２から機器１への削除命令の前に、または機器１のＣＰＵ１２によるタイマー管理による削除処理（９−２３）の前に行ってもよい。
【０１８８】
図３７に、第８の実施形態の端末アプリ退避管理部１２０における詳細処理を示すフローチャートである。
【０１８９】
端末アプリ退避管理部１２０では、まず、ＣＰＵ１２からの端末アプリのインストール可否の問い合わせか否かを判断し（ステップ１０００）、インストール可の場合は（ステップ１０００“ＹＥＳ”）、アプリ管理テーブル（図示せず）等を確認して（ステップ１１００）、端末アプリを退避させずインストールできるか否かを判断する（ステップ１２００）。
【０１９０】
例えば、アプリ管理テーブル（図示せず）等を確認して、格納可能な端末アプリの最大個数が１０コで、すでに端末アプリが１０コ格納されている場合には、端末アプリを退避させずの新規インストールはできないと判断する。なお、インストール可否問い合わせとしては、例えば、可否問合せＩＤ１として、アプリＩＤ３の端末アプリを削除し、アプリＩＤ１，アプリＩＤ２の端末アプリを２つインストールしたいという例が考えられる。
【０１９１】
そして、端末アプリを退避させずインストール可能と判断した場合（ステップ１２００“ＹＥＳ”）、端末アプリ退避管理部１２０は、ＣＰＵ１２にインストール可能を通知して、端末アプリを退避させずインストールを実行させる（ステップ１２５０）。
【０１９２】
一方、端末アプリを退避させずインストール不可と判断した場合（ステップ１２００“ＮＯ”）、端末アプリ退避管理部１２０は、まず、機器２であるコンビカード２０に退避させる端末アプリを決定する（ステップ１３００）。例えば、端末アプリの退避優先度テーブル（図示せず）等を参照して、アプリＩＤ８のゲームの端末アプリ等を退避することに決定する。
【０１９３】
端末アプリ退避管理部１２０は、退避させる端末アプリを決定すると、機器２の端末設定管理部２２０に対し、退避要求を送信し、アプリ退避処理を実施し（ステップ１４００）、その退避結果を管理テーブル等に格納して（ステップ１５００）、スタートに戻る。例えば、アプリＩＤ８のゲームの端末アプリの退避処理を行った場合、その端末アプリの可否問合せＩＤ１や、退避時のタイムスタンプ、退避結果ＯＫ、退避したアプリＩＤ（アプリＩＤ８）、機器２との認証情報等を、管理テーブル等に格納する。
【０１９４】
一方、ステップ３７００にて、インストール可否の問い合わせではなく（ステップ１０００“ＮＯ”）、復活要否の問い合わせであると判断した場合（ステップ１６００“ＹＥＳ”）、復活処理が必要か否かを、アプリ管理テーブル（図示せず）等を参照して確認する（ステップ１７００）。
【０１９５】
復活要否の問い合わせとしては、例えば、インストール可否問合せの可否問合ＩＤ１の設定を解除したので、復活処理が必要であれば復活処理を実行する等の復活要否問合せＩＤ２が考えられる。また、復活処理が必要か否かをアプリ管理テーブル（図示せず）等を参照して確認した際に、可否問合せＩＤ１ではアプリＩＤ８のゲームの端末アプリの退避処理を実施、等と記載されている場合は、復活処理が必要と判断する。
【０１９６】
ここで、復活が不要と判断した場合には（ステップ１８００“ＮＯ”）、ＣＰＵ１２に完了を通知して（ステップ１８５０）、スタートに戻る一方、復活が必要と判断した場合には（ステップ１８００“ＹＥＳ”）、端末アプリ退避管理部１２０は、機器２の端末設定管理部２２０に対し復活要求を送信し、機器２の端末設定管理部２２０等に退避させておいた端末アプリの復活処理を実施する（ステップ１９００）。そして、復活処理の結果をアプリ管理テーブル（図示せず）等に格納して、ＣＰＵ１２にその結果を通知し（ステップ１９５０）、最初に戻る。復活処理の結果としては、例えば、可否問合せＩＤ１、退避時のタイムスタンプ、退避結果ＯＫ、要否問合せＩＤ２、復活時のタイムスタンプ、復活結果ＯＫ、退避・復活したアプリＩＤ（アプリＩＤ８）、機器２との認証情報等がある。
【０１９７】
このように、第８の実施形態によれば、機器１である携帯電話１０に新たな端末アプリをインストールする場合、携帯電話１０のメモリ容量確保等のため、携帯電話１０の端末アプリをコンビカード２０に退避させて、新たな端末アプリを携帯電話１０にインストールし、タイマーの管理等により新たにインストールした端末アプリの設定解除を行った場合には、退避させておいた端末アプリを携帯電話にインストールするようにしたため、携帯電話１０のメモリ容量をそれほど増やさずに、カードアプリ機能や装置機能等が発現されるエリアを限定することができる。
【０１９８】
以上説明したように、本発明の一態様では、セキュアデバイスに、ゲート機器に対して認証処理を行う認証手段と、端末にインストールする端末アプリと、認証手段がゲート機器との認証に成功した場合に、ゲート機器から指定された端末アプリを端末にインストールする制御手段とを設けているため、セキュアデバイスをゲート機器に翳し、正常に通過したエリアでのみ、端末アプリが端末にインストールされる。ゲート機器のゲートアプリが特定の領域で機能するアプリを指定するので、ユーザの登録操作等は不要であり、また、端末へのＧＰＳ受信機等の装備も必要がない。
【０１９９】
また、本発明の別の態様では、セキュアデバイスに、ゲート機器に対して認証処理を行う認証手段と、カードアプリとを設け、認証手段がゲート機器との認証に成功した場合に、ゲート機器から指定されたカードアプリが、端末の端末アプリのアクセスを許容するようにしたため、セキュアデバイスをゲート機器に翳し、正常に通過したエリアでのみ、端末アプリは、カードアプリの利用が可能になる。
【０２００】
また、本発明の別の態様では、セキュアデバイスに、ゲート機器に対して認証処理を行い、認証に成功したゲート機器の識別情報を登録する認証手段と、認証手段がゲート機器との認証に成功したことを条件に所定の動作を行う機器に対して、この機器の検証に供するためにゲート機器の識別情報を送信し、または、この機器に代わって識別情報を検証するカードアプリとを設けたため、ゲート機器が設置された正規の入口から入場しないと、機器は動作しないようにすることができる。
【０２０１】
また、本発明の別の態様では、セキュアデバイスは、ゲート機器との間の通信方式に応じて、端末にインストールあるいは端末から削除する端末アプリケーションを設定するようにしたため、通信方式に応じて簡単に端末にインストールする端末アプリケーション等を変更することができ、セキュリティを簡単に確保することができる。
【０２０２】
また、本発明の別の態様では、セキュアデバイスは、ゲート機器との間で認証を行なう際、端末との間で前回有効にした設定が正しく無効化されているか否かを判断し、正しく無効化されている場合のみ、ゲート機器との間の認証を許可するようにしたため、前回の無効化処理が正しく行われたか否かに基づいて今回のゲート機器との認証を許可することができ、よりセキュリティを確保することができる。
【０２０３】
また、本発明の別の態様では、セキュアデバイスは、ゲート機器との間の通信方式に応じて、カードアプリケーションの有効または無効を設定するようにしたため、通信方式に応じて簡単にセキュリティを確保することができる。
【０２０４】
また、本発明の別の態様では、ゲート機器に、セキュアデバイスまたはセキュアデバイスを保持する端末との通信手段と、通信手段を通じてセキュアデバイスとの認証処理を行い、認証に成功したセキュアデバイスに対して、端末にインストールする端末アプリを指定するゲートアプリとを設けたり、あるいは、ゲート機器に、セキュアデバイスまたはセキュアデバイスを保持する端末との通信手段と、通信手段を通じてセキュアデバイスとの認証処理を行い、認証に成功したセキュアデバイスに対して、端末の端末アプリがアクセスできるカードアプリを指定するゲートアプリとを設けるようにしたため、認証に成功したセキュアデバイスに対して、端末にインストールする端末アプリや、端末アプリがアクセス可能となるカードアプリを指定することができる。
【０２０５】
また、本発明の別の態様では、端末装置は、セキュアデバイスを保持し、ゲート機器との認証に成功したセキュアデバイスから、ゲート機器が指定した端末アプリをインストールするようにしたり、あるいは、端末装置は、セキュアデバイスを保持し、ゲート機器との認証に成功したセキュアデバイスが保持するカードアプリの中で、ゲート機器が指定したカードアプリにアクセスする端末アプリを備えるようにしたため、入口にゲート機器が設置された特定のエリアの中でのみ、端末装置の特殊な機能が発揮できる。
【０２０６】
また、本発明の別の態様では、端末装置は、セキュアデバイスからの新たな端末アプリケーションのインストール要求受信時に、メモリ容量が少なく前記新たな端末アプリケーションをインストールできない場合には、保持している端末アプリケーションを前記セキュアデバイスに退避させてから前記新たな端末アプリケーションをインストールし、その後、インストールした前記新たな端末アプリケーションを削除して、前記退避させた端末アプリケーションを復活させるようにしたため、端末アプリケーションを保存するためのメモリ容量が少ない場合でも、新たな端末アプリケーションを実施させることができる。
【０２０７】
また、本発明の別の態様では、機器が、ゲート機器との認証に成功したセキュアデバイスからゲート機器の識別情報を取得し、この識別情報の検証に成功した場合に所定の動作を行うようにしたり、あるいは、機器が、ゲート機器との認証に成功したセキュアデバイスからゲート機器の識別情報の検証に成功した旨の情報を取得した場合に所定の動作を行うようにしたため、ユーザがセキュアデバイスを所持して正規の入口から入場しないと、機器が動作しないようにすることができる。
【０２０８】
本明細書は、２００４年１月２８日出願の特願２００４−１９４６１に基づく。この内容はすべてここに含めておく。
【産業上の利用可能性】
【０２０９】
本発明は、各種のセキュアデバイスの機能や、各種の端末、装置、機器等の機能を場所、経路、位置、または通信方式、前回の無効化処理、さらにはメモリ容量等との関連で変える場合に利用することができ、オフィス、家庭、医療現場、教育現場など、あらゆる分野での利用が可能である。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【技術分野】
【０００１】
本発明は、ＩＣカード等のセキュアデバイスと、このセキュアデバイスとの間で接触通信または非接触通信を行う端末装置、ゲート機器、機器に関するものである。
【背景技術】
【０００２】
近年、ＩＣカードは、電子決済用カードや定期乗車券、イベント用チケット、クレジットカード等として広く利用されている。最近では、微細化技術の向上とも相俟って、比較的大容量の記憶空間を持つＩＣカードが作られており、このようなＩＣカードは、カードサービスを実行する複数のカードアプリケーション（以下、アプリケーションを「アプリ」と略称する）を格納することにより、一枚で複数の用途に対応するマルチアプリカードとして使用することができる。
【０００３】
ＩＣカードの通信方式には、ＩＣカードの電気的接点にリーダ・ライタを接触して記録情報の読み書きを行う接触通信と、無線通信で情報をやり取りし、リーダ・ライタとの物理的な接触を必要としない非接触通信との二通りがある。最近は、接触通信及び非接触通信の両方が可能なＩＣカード（コンビカード）を携帯端末装置に搭載し、この携帯端末を電子財布や定期券の替わりに使用することも行われている。
【０００４】
下記特許文献１には、搭載したマルチアプリカードから、目的のカード機能を迅速かつ簡単に選択することを可能にした携帯端末装置が開示されている。この装置を使用するユーザは、マルチアプリカードのカード機能を携帯端末の表示画面に一覧表示して、その中から親アプリと、親アプリに関連付けたアプリ（優先アプリ）とを登録し、マルチアプリカードに記憶させる。例えば、親アプリとして定期乗車券機能を登録し、その優先アプリとして電子マネー機能を登録すると、携帯端末を自動改札装置に翳し、マルチアプリカードの定期乗車券機能を用いて駅構内に入場した場合に、携帯端末の表示画面には、優先アプリの電子マネー機能の表示順位を最上位に設定したアプリ選択画面が表示される。
【０００５】
また、ユーザがマルチアプリカードのアプリ機能を使用すると、その位置が携帯端末のＧＰＳ受信機等の現在位置検出手段で検出されて、使用したアプリ機能と使用位置との関係が携帯端末で記憶される。そして、その位置付近を再び訪れたとき、携帯端末の表示画面には、その位置に対応するアプリ機能の表示順位を最上位に設定したアプリ選択画面が表示される。
【特許文献１】特開２００３−７６９５８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
このように、場所と対応付けてアプリ選択画面の表示を変更することは前記特許文献１に記載されているが、ＩＣカードのカード機能を場所によって限定する発想は、この文献には示されていない。ＩＣカードのカード機能を場所で限定することができるならば、例えば、ＩＣカードを搭載した携帯電話を、社内エリアでは内線電話として使用できるようにし、あるいは、ＩＣカードに格納された特定データを社内エリアでのみ利用できるようにする等、新たな応用が可能になる。
【０００７】
また、ＩＣカードのカード機能を場所によって限定する場合に、前記特許文献１のように、ユーザの登録操作を必要とするのでは、ユーザの処理負担が大きいし、また、携帯端末が位置情報の取得手段を持つ必要があるのでは、携帯端末のコストが高くなる。
【０００８】
本発明の目的は、こうした従来の課題を解決するものであり、ユーザの処理負担やコスト負担を招かずに、セキュアデバイスのカード機能や、端末装置あるいは機器の機能を、場所と関連付けて変更したり、または通信方式、前回の無効化処理、さらにはメモリ容量等に応じて変更したり、よりセキュリティを確保することができるＩＣカード等のセキュアデバイスを提供し、また、このセキュアデバイスと連携して処理を行う端末装置、ゲート機器、機器を提供することである。
【課題を解決するための手段】
【０００９】
本発明のセキュアデバイスは、ゲート機器に対して認証処理を行う認証手段と、端末にインストールする端末アプリケーションと、前記認証手段がゲート機器との認証に成功した場合に、前記ゲート機器から指定された端末アプリケーションを端末にインストールする制御手段と、を備える構成を採る。
【００１０】
また、本発明のセキュアデバイスは、ゲート機器に対して認証処理を行う認証手段と、カードアプリケーションと、前記認証手段がゲート機器との認証に成功した場合に、前記ゲート機器から指定されたカードアプリケーションが、端末の端末アプリケーションのアクセスを許容する制御手段と、を備える構成を採る。
【００１１】
また、本発明のセキュアデバイスは、ゲート機器に対して認証処理を行い、認証に成功したゲート機器の識別情報を登録する認証手段と、前記認証手段がゲート機器との認証に成功したことを条件に所定の動作を行う機器に対して、前記機器の検証に供するためにゲート機器の前記識別情報を送信し、または、前記機器に代わって前記識別情報を検証するカードアプリケーションと、を備える構成を採る。
【００１２】
また、本発明のゲート機器は、セキュアデバイスまたは前記セキュアデバイスを保持する端末との通信手段と、前記通信手段を通じて前記セキュアデバイスとの認証処理を行い、認証に成功したセキュアデバイスに対して、端末にインストールする端末アプリケーションを指定するゲートアプリケーションと、を備える構成を採る。
【００１３】
また、本発明のゲート機器は、セキュアデバイスまたは前記セキュアデバイスを保持する端末との通信手段と、前記通信手段を通じて前記セキュアデバイスとの認証処理を行い、認証に成功したセキュアデバイスに対して、端末の端末アプリケーションがアクセスできるカードアプリケーションを指定するゲートアプリケーションと、を備える構成を採る。
【００１４】
また、本発明の端末装置は、セキュアデバイスを保持し、ゲート機器との認証に成功した前記セキュアデバイスから、前記ゲート機器が指定した端末アプリケーションをインストールする構成を採る。
【００１５】
また、本発明の端末装置は、セキュアデバイスを保持し、ゲート機器との認証に成功した前記セキュアデバイスが保持するカードアプリケーションの中で、前記ゲート機器が指定したカードアプリケーションにアクセスする端末アプリケーションを備える構成を採る。
【００１６】
また、本発明の機器は、ゲート機器との認証に成功したセキュアデバイスから前記ゲート機器の識別情報を取得し、前記識別情報の検証に成功した場合に所定の動作を行う構成を採る。
【００１７】
また、本発明の機器は、ゲート機器との認証に成功したセキュアデバイスから前記ゲート機器の識別情報の検証に成功した旨の情報を取得した場合に所定の動作を行う構成を採る。
【発明の効果】
【００１８】
本発明のセキュアデバイス、ゲート機器、端末装置及び機器は、連携して、セキュアデバイスのカード機能や、端末装置あるいは機器の機能を、場所と関連付けて変更したり、または通信方式、前回の無効化処理、さらにはメモリ容量等に応じて変更したり、よりセキュリティを確保することができる。例えば、端末装置の機能をオフィスの中と外とで切替えたり、特定の処理機能を限定したエリアでのみ可能にしたり、特定の入口から入場しなければ、部屋の扉や金庫が開かないようにしたりすることができる。また、こうした処理を、ユーザの処理負担やコスト負担を招かずに実現することができる。
【図面の簡単な説明】
【００１９】
［図１］本発明の第１の実施形態における携帯電話、コンビカード及びゲートの構成を示すブロック図
［図２］本発明の第１の実施形態に設定されたデータＤＢのデータ構成を示す図
［図３］本発明の第１の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図４］本発明の第１の実施形態における携帯電話、ＩＣカード及びゲートの構成を示すブロック図
［図５］本発明の第２の実施形態における携帯電話、コンビカード及びゲートの構成を示すブロック図
［図６］本発明の第２の実施形態に設定されたデータＤＢのデータ構成を示す図
［図７］本発明の第２の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図８］本発明の第２の実施形態における優先度設定ＤＢのデータ構成を示す図
［図９Ａ］本発明の第２の実施形態における優先度設定ＤＢの他のデータ構成であって、各カードアプリＩＤの優先度を規定した優先度テンプレートの一例を示す図
［図９Ｂ］本発明の第２の実施形態における優先度設定ＤＢの他のデータ構成であって、ゲートアプリＩＤに対応して優先度テンプレートを設定した優先設定ＤＢの一例を示す図
［図１０］本発明の第３の実施形態におけるドア、ＩＣカード及びゲートの構成を示すブロック図
［図１１］本発明の第３の実施形態におけるドア、ＩＣカード及びゲートの動作を示すシーケンス図
［図１２］本発明の第３の実施形態におけるＰＩＮ入力部を持つドア、ＩＣカード及びゲートの構成を示すブロック図
［図１３］本発明の第３の実施形態におけるＰＩＮ入力部を持つドア、ＩＣカード及びゲートの動作を示すシーケンス図
［図１４］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の構成を示すブロック図
［図１５］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図１６］本発明の第４の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図１７］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図（図１６の続き）
［図１８］本発明の第４の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図１９］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図（図１８の続き）
［図２０］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図２１］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図２２］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図２３］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図２４］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図２５］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図２６］本発明の第４の実施形態における携帯電話、コンビカード、ゲート及び金庫の動作を示すシーケンス図
［図２７］第５の実施形態における会社の入場処理と退場処理とを例にした認証情報ＤＢ例を示す図
［図２８］第５の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図２９］第６の実施形態の認証情報ＤＢの内容の一例を示す図
［図３０］第６の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図３１］第７の実施形態の構成を示すブロック図
［図３２］第７の実施形態の認証情報ＤＢに設定されたデータの一例を示す図
［図３３］第７の実施形態の端末設定管理部に設定されたデータの一例を示す図
［図３４］第７の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図３５］第８の実施形態の構成を示すブロック図。
［図３６］第８の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図
［図３７］第８の実施形態の端末アプリ退避管理部における詳細処理を示すフローチャート
【発明を実施するための最良の形態】
【００２０】
（第１の実施形態）
本発明の第１の実施形態では、セキュアデバイスであるＩＣカードが特定エリアに位置するときだけ、ＩＣカードに格納された端末アプリが、端末にインストールされる場合について説明する。
【００２１】
この特定エリアの入口にはゲートが在り、ゲートアプリは、ＩＣカードとの認証処理に成功すると、ＩＣカードに対して、端末に設定すべき端末アプリを指定する。これを受けて、ＩＣカードは、適宜の時期に、保持する端末アプリの中から、指定された端末アプリを端末にインストールする。
【００２２】
図１は、端末（機器１）が携帯電話１０であり、ＩＣカード（機器２）が、携帯電話１０に装着されたチップ状のコンビカード２０である場合の、携帯電話１０、コンビカード２０及びゲート４０（機器３）の構成について示している。
【００２３】
ゲート４０は、コンビカード２０に対して認証処理や端末アプリの指定を行うゲートアプリ４３と、コンビカード２０への非接触通信を行う非接触通信手段（４）４１と、ゲート４０の動作を制御するＣＰＵ４２とを備えている。
【００２４】
コンビカード２０は、ゲート４０への非接触通信を行う非接触通信手段（３）２２と、携帯電話１０への接触通信を行う接触通信手段（２）２１と、認証情報等が格納された認証情報データベース（ＤＢ）２５と、他の機器１、３との認証処理を行う認証アプリ２４と、携帯電話１０にインストールする端末アプリ２７や設定命令、あるいはそれらのセットである端末アプリ・設定命令２６と、コンビカード２０の動作を制御するＣＰＵ２３とを備えている。
【００２５】
また、携帯電話１０は、コンビカード２０への接触通信を行う接触通信手段（１）１１と、携帯電話１０の動作を制御するＣＰＵ１２とを備えている。
【００２６】
このコンビカード２０の認証情報ＤＢ２５には、図２に示すように、ゲートアプリ４３のＩＤと対応付けて、認証処理に使用する共通鍵や秘密鍵等の認証情報と、携帯電話１０へのインストールが可能な端末アプリ２７のＩＤや、携帯電話１０で設定すべき端末アプリを指定する設定命令のＩＤが格納されている。
【００２７】
設定命令は、例えば、携帯電話１０に対する次のような指示である。・表示画面の背景イメージに会社ロゴを設定する。・音（着信時、アプリ実行時）に会社用の音を設定する。・メインメニューに、社内で使用するイントラネットアプリを追加する。・デフォルトを内線電話に変更する（外線への発信を０発信に変更）。・メール機能の設定（メールサーバアドレス、ユーザＩＤ、個人情報、ネットワーク設定、など）を変える。・会社では特定のメールサーバにしかアクセスできない。・会社では特定のアドレスにしかメール送信できない。・会社では、特定のメールを読むことしかできない。・アクセス可能なアプリサーバを制限する。・会社では特定のサイトにしかアクセスできない。
【００２８】
また、携帯電話１０へのインストールが可能な端末アプリは、携帯電話１０で保持されていない、設定命令の実行に必要なアプリであり、例えば、以下に示すアプリがある。・設定命令に基づく表示を実行するブラウザ等のソフトウエア。例えば、会社では、特定のサイトへのアクセスのみが可能なブラウザアプのみへ切り替える。・メールアプリを切り替える。例えば、会社では、メールの保存ができない特定のメールアプリしか使えないとか、会社では会社内でないと保存したメールが閲覧できない特定のメールアプリしか使えない。例えば、保存したメールは、特定のメールアプリしかアクセスできないコンビカード２０セキュアメモリエリアに保存されている。
【００２９】
図３は、このゲート４０、コンビカード２０及び携帯電話１０が連携して行う処理のシーケンスを示している。
【００３０】
ユーザは、所定エリアに入場する際に、コンビカード２０を装着した携帯電話１０をゲート４０に翳す。ゲート４０のＣＰＵ４２は、非接触通信手段４１の通信圏内にコンビカード２０が進入すると、コンビカード２０に認証アプリＩＤとゲートアプリＩＤとを指定して認証処理を要求する（１−１）。これを受けてコンビカード２０のＣＰＵ２３は認証アプリ２４を起動し、認証アプリ２４は、認証情報ＤＢ２５のゲートアプリＩＤに対応する認証情報を用いて、ゲートアプリ４３との間で、一般的なチャレンジレスポンスによる認証処理を実行する（１−２）。認証処理に成功すると、ゲートアプリ４３は、端末アプリＩＤを指定して、その端末アプリの端末へのインストールを要求する（１−３）。指定する端末アプリＩＤは複数であっても良い。
【００３１】
この要求を受けたコンビカード２０の認証アプリ２４は、認証情報ＤＢ２５の情報から、その端末アプリがインストール可能であることを確認（検証）し、その旨をＣＰＵ２３に伝える。ＣＰＵ２３は、携帯電話１０に端末アプリＩＤを示してインストール要求を送り（２−１）、認証アプリ２４に携帯電話１０との認証処理を行わせる（２−２）。なお、コンビカード２０を携帯電話１０に装着した時点で両者間の認証処理が既に済んでいれば、この認証処理を省略しても良い。認証処理に成功すると、ＣＰＵ２３は、該当する端末アプリ２６、２７を携帯電話１０に送信し（２−３）、携帯電話１０のＣＰＵ１２は、その端末アプリをインストールする。
【００３２】
このように、このゲート４０、コンビカード２０及び携帯電話１０の間では、三者の連携により、コンビカード２０とゲート４０との認証の成功を条件に、コンビカード２０から携帯電話１０への端末アプリのインストールが実行される。そのため、このコンビカード２０の動作や、携帯電話１０の端末アプリを利用する処理は、ゲート４０を通過して入場したエリアでのみ可能になる。
【００３３】
なお、ＩＣカードの国際標準規格（接触通信に関するＩＳＯ７８１６、非接触通信に関するＩＳＯ１４４４３）では、ＩＣカードのカードアプリとリーダ・ライタ側の端末アプリとのデータのやり取りは、端末アプリからカードアプリに送られる「コマンド」と、カードアプリから端末アプリに送られる「レスポンス」とが基本になると規定されている。従って、国際標準規格を満たすＩＣカードは、受動的な動作しかできず、（２−１）のインストール要求を自ら携帯電話１０に送信することができない。
【００３４】
そのため、携帯電話１０は、国際標準規格を満たすコンビカード２０の場合には、ユーザが携帯電話１０をゲート４０に翳した時点から、非接触通信の状態を監視するためにコンビカード２０にポーリング信号を送り続ける。そして、コンビカード２０から非接触通信終了の応答を受けると、コンビカード２０に対し、要求が有れば送信するように指示し、コンビカード２０は、これに応えてインストール要求を携帯電話１０に送信する（２−１）。
【００３５】
こうした手順を採ることにより、国際標準規格を満たすＩＣカードにも対応することができる。
【００３６】
なお、ここでは、ＩＣカードがコンビカードである場合について説明したが、ＩＣカードが接触通信機能のみを有するときは、図４に示すように、携帯電話１０の赤外線（またはＢｌｕｅｔｏｏｔｈや無線ＬＡＮ）等のローカル通信手段１３を利用して、ＩＣカード２０とゲート４０との通信を行うことができる。この場合、ゲート４０が、通信手段４４と携帯電話１０のローカル通信手段１３との通信（赤外線）接続を確立して、携帯電話１０にＩＣカード２０へのアクセス命令を送ると、携帯電話１０はＩＣカード２０との接触通信接続を実行し、ゲート４０とＩＣカード２０との通信が可能になる。ゲート４０、ＩＣカード２０及び携帯電話１０の三者間におけるデータのシーケンスは、図３と同じである。
【００３７】
また、ＩＣカードが非接触通信機能のみを有するときには、携帯電話１０およびゲート４０と非接触通信を用いて通信を行う。ユーザが携帯電話１０をゲート４０に翳した時点から、ゲート４０との処理状態を監視するために非接触ＩＣカード２０に問合せを行う。そして、非接触ＩＣカード２０は、ゲート４０との処理が終了すると、携帯電話１０に終了通知を返し、この結果携帯電話１０は非接触ＩＣカード２０に対し、要求が有れば送信するように指示し、非接触ＩＣカード２０は、これに応えてインストール要求を携帯電話１０に送信する（２−１）。または、非接触ＩＣカード２０は、ゲート４０との処理が終了すると、携帯電話１０に終了通知とともにインストール要求を携帯電話１０に送信する（２−１）。
【００３８】
（第２の実施形態）
本発明の第２の実施形態では、ＩＣカードとゲートとの認証成功を条件に、ＩＣカードに格納されたカードアプリの利用が、端末に対して許可される場合について説明する。
ゲートは、ＩＣカードとの認証に成功すると、ＩＣカードに、端末での利用を許容するカードアプリのＩＤと、ゲートを特定するゲートＰＩＮ情報とを伝え、このカードアプリＩＤとゲートＰＩＮとの対情報がＩＣカードに格納される。ＩＣカードは、端末からカードアプリを指定して、その利用が要求されたとき、この対情報を参照して、カードアプリの利用を許可するか否かを決定する。
【００３９】
図５は、この処理を連携して行う携帯電話１０、コンビカード２０及びゲート４０の構成について示している。コンビカード２０は、第１の実施形態（図１）と同様に、非接触通信手段（３）２２、接触通信手段（２）２１、認証情報ＤＢ２５、認証アプリ２４及びＣＰＵ２３を備え、さらに、ゲート４０との認証に成功した場合に有効になるカードアプリ２８と、カードアプリＩＤとゲートＰＩＮとの対情報を格納するＰＩＮＤＢ２９とを備えている。また、携帯電話１０は、接触通信手段（１）１１、ＣＰＵ１２の他に、カードアプリ２８を利用する端末アプリ１４を備えている。ゲート４０の構成は第１の実施形態（図１）と変わりが無い。
【００４０】
このコンビカード２０の認証情報ＤＢ２５には、図６に示すように、ゲートアプリ４３のＩＤと対応付けて、認証処理に使用する認証情報と、ゲートＰＩＮの設定が可能な（即ち、ゲート４０から入場したエリアで利用可能な）カードアプリのＩＤと、ＰＩＮ設定を解除する（即ち、そのエリアで利用できなくなる）カードアプリのＩＤとが格納されている。
【００４１】
ゲート４０から入場したエリアで利用可能になるカードアプリ２８は、例えば、所内の内線番号電話帳アプリであり、コンビカード２０とゲート４０との認証が成功すると、携帯電話１０の電話帳機能を実行する端末アプリ１４からコンビカード２０に格納された内線簿にアクセスできるようになる。
【００４２】
図７は、このゲート４０、コンビカード２０及び携帯電話１０が連携して行う処理のシーケンスを示している。
【００４３】
ユーザがコンビカード２０を装着した携帯電話１０をゲート４０に翳すと、ゲート４０は、コンビカード２０に認証アプリＩＤとゲートアプリＩＤとを示して相互間の認証処理を要求する（１−１）。これを受けてコンビカード２０の認証アプリ２４は、認証情報ＤＢ２５のゲートアプリＩＤに対応する認証情報を用いて、ゲートアプリ４３との認証処理を実行する（１−２）。認証処理に成功したゲートアプリ４３は、ゲートＰＩＮを設定したい（または削除したい）カードアプリのＩＤとゲートＰＩＮとを提示して、カードアプリＩＤとゲートＰＩＮとの対情報の登録（または削除）を認証アプリ２４に要求する（１−３）。このときゲートアプリ４３が提示するカードアプリＩＤの数は、複数であっても良い。
【００４４】
コンビカード２０の認証アプリ２４は、そのカードアプリＩＤに該当するカードアプリ２８にゲートアプリＩＤとゲートＰＩＮとの情報を送り、確認（検証）を要求する（２−１）。カードアプリ２８は、認証情報ＤＢ２５を参照して、ゲートアプリとの対応関係を有しているか否か（ゲートＰＩＮの設定が可能であるか否か）を検証し、検証結果を認証アプリ２４に返す（２−２）。認証アプリ２４は、検証結果がＯＫである場合に、検証されたカードアプリＩＤとゲートＰＩＮとの対情報をＰＩＮＤＢ２９に格納し（２−３）、検証結果をゲートアプリ４３に通知する（２−４）。以上がゲート通過時に行われる処理である。
【００４５】
一方、携帯電話１０の端末アプリ１４がカードアプリ２４を利用する場合には、次の処理が行われる。
【００４６】
携帯電話１０の端末アプリ１４は、カードアプリＩＤを提示して、コンビカード２０のカードアプリ２８にアクセスを要求する（３−１）。カードアプリ２８は、認証アプリ２４に、カードアプリＩＤを示して検証結果を要求する（３−２）。認証アプリ２４は、ＰＩＮＤＢ２９を参照し、そのカードアプリＩＤとゲートＰＩＮとの対情報が記録されているときはＯＫを応答し、記録されていないときはＮＧを応答する（３−３）。カードアプリ２８は、認証アプリ２４からの応答がＯＫである場合に、端末アプリ１４に対してアクセスを許可する（３−５）。
【００４７】
こうした処理により、ユーザが正しいゲート４０から入場した場合にのみ、カードアプリ２８の利用を可能にすることができ、例えば、ユーザがコンビカード２０等のＩＣカードを装着した携帯電話１０を正規のゲート４０に翳してオフィスに入場すると、ＩＣカードに格納されたオフィス用の内線番号電話帳アプリが自動的に有効になる。
【００４８】
なお、ゲートアプリ４３から提示されたカードアプリＩＤがＰＩＮ設定を解除するカードアプリＩＤとして認証情報ＤＢ２５に記録されている場合には、認証アプリ２４は、ＰＩＮＤＢ２９を参照し、そこに記録されているカードアプリＩＤとゲートＰＩＮとの対情報を削除する。
【００４９】
このようにＰＩＮＤＢ２９の削除処理を併せて行うことにより、例えば、ユーザが、入門処理をして、あるオフィスに入場した後、別のオフィスに入門処理をして入場した場合に、先のオフィス用の内線番号電話帳アプリが無効になり、後から入場したオフィス用の内線番号電話帳アプリだけが有効になる。
【００５０】
なお、各処理のメッセージ及びデータは、第三者の盗聴を防ぐために暗号化して送信するようにしても良い。
【００５１】
また、図７において、（２−３）の検証結果の格納は、カードアプリＩＤの検証結果がＯＫであることを示す情報だけをＰＩＮＤＢ２９に格納するようにしても良い。
【００５２】
また、コンビカード２０等のＩＣカードは、接触通信機能のみを有するものであっても良い。この場合には、第１の実施形態（図４）で説明したように、携帯電話１０のローカル通信手段を利用してＩＣカードとゲートとの通信を行う。また、ＩＣカードは、非接触通信機能のみを有するものであっても良い。
【００５３】
なお、図６に示す認証情報ＤＢ２５において、一つのゲートアプリＩＤに対し、複数のカードアプリＩＤが設定されている場合には、端末アプリ１４のアクセスを許容するカードアプリに優先度を設定することも可能である。この場合、図８に示すように、ゲートアプリＩＤに対応して、優先度設定可能なカードアプリＩＤ及び優先度設定を解除できるカードアプリＩＤの優先度を設定した優先設定ＤＢを保持する。あるいは、図９Ａに示すように、各カードアプリＩＤの優先度を優先度テンプレートで規定し、図９Ｂに示すようにゲートアプリＩＤに対応して優先度テンプレートを設定した優先設定ＤＢを保持する。
【００５４】
そして、認証情報ＤＢ２５から、ゲートアプリＩＤに対応するカードアプリ２８を選択する場合に、優先設定ＤＢを参照し、優先度に基づいて選択するカードアプリ２８を決定する。
【００５５】
（第３の実施形態）
本発明の第３の実施形態では、ＩＣカードとゲートとの認証成功を条件に、ＩＣカードに格納されたカードアプリの利用が、端末に対して許可される第２の実施形態の構成において、ＩＣカード、ゲート及び端末の三者間での処理が、第２の実施形態と異なる手順で行われる場合について説明する。
【００５６】
ここでは、図１０に示すように、機器１が、非接触通信手段（１）１１０を有するドア１００であり、機器２が、非接触通信手段２２のみを有するＩＣカード２００であるものとして説明する。機器１、機器２及び機器３のその他の構成は、第２の実施形態（図５）と変わりがない。
ここでは、非接触通信手段２２のみを有するが、接触通信手段のみを有しても良い。
【００５７】
図１１は、ゲート４０、ＩＣカード２００及びドア１００が連携して行う処理のシーケンスを示している。
【００５８】
ユーザがＩＣカード２００をゲート４０に翳すと、ゲート４０は、ＩＣカード２００に認証アプリＩＤとゲートアプリＩＤとを示して相互間の認証処理を要求する（１−１）。これを受けてＩＣカード２００の認証アプリ２４は、認証情報ＤＢ２５のゲートアプリＩＤに対応する認証情報を用いて、ゲートアプリ４３との認証処理を実行する（１−２）。認証処理に成功したゲートアプリ４３は、ゲートＰＩＮを設定するカードアプリのＩＤとゲートＰＩＮとを提示して、カードアプリＩＤとゲートＰＩＮとの対情報の登録を認証アプリ２４に要求し（１−３）、ＩＣカード２００の認証アプリ２４は、要求に従ってカードアプリＩＤとゲートＰＩＮとの対情報をＰＩＮＤＢ２９に登録する（１−４）。この登録の段階では、認証情報ＤＢ２５との検証は済んでいない。以上がゲート通過時に行われる処理である。
【００５９】
一方、ユーザがＩＣカード２００をドア１００に翳すと、次の処理が行われる。
【００６０】
ドア１００の端末アプリ１４は、端末アプリＩＤとカードアプリＩＤとを提示して、ＩＣカード２００のカードアプリ２８へのアクセスを要求する（２−１）。カードアプリ２８は、認証アプリ２４に、カードアプリＩＤとゲートアプリＩＤとを示してＰＩＮＤＢ２９の登録情報を要求し（２−２）、認証アプリ２４は、ＰＩＮＤＢ２９から、該当するカードアプリＩＤ及びゲートＰＩＮの対情報を取得してカードアプリ２８に提示する（２−３）。カードアプリ２８は、認証情報ＤＢ２５を参照して、ゲートアプリとの対応関係を有しているか（ゲートＰＩＮの設定が可能であるか）を検証し（２−４）、検証結果がＯＫである場合に、端末アプリ１４にアクセスを許可する（２−５）。
【００６１】
カードアプリ２８にアクセスしたドア１００の端末アプリ１４は、例えば、カードアプリ２８から鍵情報を取得してドア１００を開錠し、ユーザは、ドア１００の通過が可能になる。
【００６２】
このように、ゲート４０、ＩＣカード２００及びドア１００が連携することにより、正しい玄関（ゲート）から入らないと、ドアが開かないようにすることができる。
【００６３】
また、このＰＩＮ検証（２−４）では、カードアプリ２８が、端末アプリ１４とゲートＰＩＮとのペアを検証することも可能であり、この場合には、ある端末アプリ１４について、特定のゲートＰＩＮと対応していなければアクセスを許可しない（即ち、あるドアは特定の入口から入らないと開かない）と言う制御を行うこともできる。
【００６４】
また、図１２に示すように、ドア１００にＰＩＮ入力部１５を設け、ユーザがＰＩＮ入力部１５から入力したユーザＰＩＮをさらに検証して、ドア１００を開けるように制御することもできる。
【００６５】
図１３は、この場合のシーケンスを示している。ゲートＰＩＮを検証する（２−４）までの処理は、図１１の場合と同じである。ゲートＰＩＮの検証結果がＯＫである場合に、カードアプリ２８は、ドア１００にユーザＰＩＮを要求し（２−５）、ユーザがＰＩＮ入力部１５からユーザＰＩＮを入力すると（２−６）、カードアプリ２８は、ＩＣカード２００のＰＩＮＤＢ２９で保持されたユーザＰＩＮと照合して、それを検証する（２−７）。そして、検証結果が一致する場合に、端末アプリ１４に対してアクセスを許可する（２−８）。
【００６６】
（第４の実施形態）
本発明の第４の実施形態では、ＩＣカードとゲートとの認証処理が成功したことを条件に、機器の処理が可能になる場合について説明する。
【００６７】
ＩＣカードは、ゲートとの認証処理が成功すると、ゲートからゲートＰＩＮを取得し、このゲートＰＩＮを機器に送信する。機器は、ゲートＰＩＮの検証が終了した後、処理を開始する。
【００６８】
図１４は、ゲート４０、コンビカード２０及び携帯電話１０の構成と、機器（機器４）が金庫５０である場合の構成とを示している。このコンビカード２０を装着した携帯電話１０をゲート４０に翳し、コンビカード２０とゲート４０との認証処理を行う。認証が成功した場合に、この携帯電話１０を金庫５０に翳し、また、携帯電話１０からユーザＰＩＮを入力することにより、金庫５０の開錠が可能になる。
【００６９】
金庫５０は、コンビカード２０への非接触通信を行う非接触通信手段（５）５１と、金庫５０の鍵の開閉を制御する鍵アプリ５３と、金庫５０の動作を制御するＣＰＵ５２とを備えている。ゲート４０、コンビカード２０及び携帯電話１０の構成は、第２の実施形態（図１０）と変わりがない。
【００７０】
コンビカード２０を装着した携帯電話１０をゲート４０に翳すと、ゲート４０とコンビカード２０との間で、図１３の（１−１）から（１−４）までの処理が行われる。
【００７１】
図１５は、その後、ユーザが、コンビカード２０を装着した携帯電話１０を金庫５０に翳したときの処理シーケンスを示している。
【００７２】
金庫５０の鍵アプリ５３は、カードアプリＩＤを示して、コンビカード２０にカードアプリ２９へのアクセスを要求する（３−１）。カードアプリ２９は、カードアプリＩＤ及び鍵アプリＩＤを提示して、認証アプリ２４にゲートＰＩＮを要求する（３−２）。認証アプリ２４は、ＰＩＮＤＢ２９を参照し、カードアプリＩＤに対応するゲートＰＩＮ情報を取得してカードアプリ２９に返す（３−３）。
【００７３】
次に、カードアプリ２９は、携帯電話１０の端末アプリ１４にユーザＰＩＮを要求する（３−４）。端末アプリ１４は、ＰＩＮ入力画面を表示し、ユーザがＰＩＮを入力すると（３−５）、そのユーザＰＩＮをカードアプリ２９に送信する（３−６）。カードアプリ２９は、コンビカード２０のＰＩＮＤＢ２９で保持されているユーザＰＩＮ情報と照合して、それを検証する（３−７）。ユーザＰＩＮの検証結果が一致した場合は、ゲートＰＩＮを金庫の鍵アプリ５３に送信する（３−８）。鍵アプリ５３は、予め保持するゲートＰＩＮ情報と、カードアプリ２９から送られたゲートＰＩＮとを照合して検証し（３−９）、検証結果が一致する場合に、開錠処理を実行する（３−１０）。
【００７４】
このように、例えば、ゲート４０が玄関に設置されている場合では、玄関での入門処理が正しく行われたときにのみ、金庫５０の鍵が使えることになる。
【００７５】
なお、ユーザＰＩＮやゲートＰＩＮの検証を行う時期、あるいは、検証を行う主体等については、種々の変更が可能である。例えば、鍵アプリ５３がゲートＰＩＮの検証（３−９）を行う代わりに、カードアプリ２９が、ユーザＰＩＮ検証（３−８）とともに、ゲートＰＩＮの検証を行い、検証結果を鍵アプリ５３に伝えるようにしても良い。
【００７６】
また、カードアプリ２９がユーザＰＩＮ検証（３−８）を行う代わりに、入力されたユーザＰＩＮを鍵アプリ５３に送り、鍵アプリ５３が、金庫５０に登録されたユーザＰＩＮと照合してユーザＰＩＮ検証を行うようにしても良い。
【００７７】
また、図１６に示すように、ＰＩＮ登録（４−４）を終了した認証アプリ２４が、端末アプリ１４にユーザＰＩＮを要求し（４−５）、入力されたユーザＰＩＮをそのままＰＩＮＤＢ２９に登録（４−８）するようにしても良い。この場合は、図１７に示すように、携帯電話１０を金庫５０に翳した段階で、カードアプリ２９が、ＰＩＮＤＢ２９からゲートＰＩＮ及びユーザＰＩＮを取得し（５−３）、ユーザＰＩＮを検証し（５−４）、ゲートＰＩＮを金庫５０の鍵アプリ５３に送る（５−５）。この方式では、ユーザのＰＩＮ入力が事前に済んでいるため、金庫５０の前でのユーザの入力操作が不要になる。
【００７８】
また、図１８に示すように、ＰＩＮ登録（４−４）が終了した時点で、認証アプリ２４がＰＩＮ登録通知（ゲートアプリＩＤ）をカードアプリ２９に対し行ない（４−５）、その通知を受けたカードアプリ２８が、携帯電話１０に対しカードアプリＩＤを渡しながらユーザＰＩＮを要求する（４−６）。携帯電話１０の端末アプリ１４は、ユーザＰＩＮを入力し（４−７）、ユーザＰＩＮをコンビカード２０のカードアプリ２８に対し送信する。コンビカード２０では、カードアプリ２８が入力されたユーザＰＩＮを検証して（４−９）、ユーザＰＩＮの認証結果を認証アプリ２４に送信する。認証アプリ２４では、カードアプリ２８からのユーザＰＩＮの検証結果を登録する（４−１１）ようにしてもよい。この場合は、図１９に示すように、携帯電話１０を金庫５０に翳した段階で、ユーザの検証結果をチェックする（５−４）だけで足りる。この方式では、ユーザＰＩＮ検証が早い段階で行われるため、ユーザがＰＩＮ入力を間違えていた場合に、早い段階で修正できる。
【００７９】
また、図２０は、コンビカード（機器２）のカードアプリ（アプリ２）が、ユーザＰＩＮ要求と、ゲートＰＩＮ検証と、ユーザＰＩＮ検証とを行う場合のシーケンスを示している。
【００８０】
また、図２１は、コンビカード（機器２）のカードアプリ（アプリ２）が、ユーザＰＩＮ要求と、ユーザＰＩＮ検証とを行い、金庫（機器４）の鍵アプリ（アプリ５）がゲートＰＩＮ検証を行う場合のシーケンスを示している。
【００８１】
また、図２２は、コンビカード（機器２）のカードアプリ（アプリ２）が、ユーザＰＩＮ要求と、ゲートＰＩＮ検証とを行い、金庫（機器４）の鍵アプリ（アプリ５）がユーザＰＩＮ検証を行う場合のシーケンスを示している。
【００８２】
また、図２３は、コンビカード（機器２）の認証アプリ（アプリ３）が、ユーザＰＩＮ要求を行い、金庫（機器４）の鍵アプリ（アプリ５）がゲートＰＩＮ検証と、ユーザＰＩＮ検証とを行う場合のシーケンスを示している。
【００８３】
また、図２４は、ユーザＰＩＮ入力を金庫（機器４）から行い、金庫（機器４）の鍵アプリ（アプリ５）がゲートＰＩＮ検証と、ユーザＰＩＮ検証とを行う場合のシーケンスを示している。
【００８４】
また、図２５は、ユーザＰＩＮ入力を金庫（機器４）から行い、コンビカード（機器２）のカードアプリ（アプリ２）が、ユーザＰＩＮ検証を行い、金庫（機器４）の鍵アプリ（アプリ５）がゲートＰＩＮ検証を行う場合のシーケンスを示している。
【００８５】
また、図２６は、ユーザＰＩＮ入力を金庫（機器４）から行い、コンビカード（機器２）のカードアプリ（アプリ２）が、ゲートＰＩＮ検証を行い、金庫（機器４）の鍵アプリ（アプリ５）がユーザＰＩＮ検証を行う場合のシーケンスを示している。
【００８６】
コンビカード（機器２）のカードアプリ（アプリ２）でゲートＰＩＮを検証する場合は、ゲートＰＩＮが変わった場合に、カード内に格納されたゲートＰＩＮを変更すれば足りる。また、ゲートアプリ（アプリ４）と鍵アプリ（アプリ５）の組み合わせでアクセス制御を行うことができる。
【００８７】
また、金庫（機器４）の鍵アプリ（アプリ５）でゲートＰＩＮを検証する場合は、新しい金庫（機器４）が追加された時に、その金庫にゲートＰＩＮ情報を登録するだけで足りる。また、金庫を削除するときに、カードの設定を変える必要がない。
【００８８】
また、コンビカード（機器２）のカードアプリ（アプリ２）でユーザＰＩＮを検証する場合は、ユーザがユーザＰＩＮを変えたい場合に、コンビカード（機器２）に格納されているユーザＰＩＮを変更するだけで足り、わざわざユーザＰＩＮを換えたい機器（例えば金庫）のところに赴いて変えなくても済む。また、一つのユーザＰＩＮが複数の機器（ドアなど）に対応している場合でも、ドアごとにユーザＰＩＮを設定して回らなくて済む。また、図１８に示すように、ユーザＰＩＮを事前入力する場合に、ユーザＰＩＮの入力時に金庫（機器４）無しで検証が行えるので、金庫に翳してからユーザＰＩＮの再入力が必要になるような事態は発生しない。
【００８９】
また、金庫（機器４）の鍵アプリ（アプリ５）でユーザＰＩＮを検証する場合は、金庫でユーザＰＩＮを管理しているので、何人のユーザが登録されているのかが容易に把握できる。
【００９０】
また、本実施形態では、機器４を金庫、カードアプリとして鍵アプリを想定したが、機器４をビデオやセットトップボックス（ＳＴＢ）、カードアプリとして、決済カードアプリや、有料放送録画予約アプリ、有料放送受信操作アプリを想定してもよい。こうすることにより、正しく玄関の鍵の処理をしていないと、ＳＴＢ（ＰＣ）を介した決済処理（決済カードアプリ）ができない、ビデオ録画予約（その解除）（有料放送録画アプリ）ができない、といったサービスも可能である。
【００９１】
また、機器４を車の防犯モジュールとした場合、正しく玄関の鍵を閉じる処理をしたカードアプリと防犯モジュール（機器４）で正しいチェックイン処理をしないまま、車のドアを開けたり、車のエンジンをかけたり、車のオーディオを外したりすると防犯ベルが鳴るといったサービスも可能である。
【００９２】
なお、実施形態では、主に、ＩＣカードを携帯電話に装着する場合について説明したが、本発明はこれに限定されるものではない。携帯電話に代えて、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、メール端末、小型パーソナルコンピュータ、ゲーム機など、各種の端末装置・情報処理装置を用いることができる。また、ＩＣカードは、国際標準規格を満たすものでも、満たさないものでも使用可能である。セキュアデバイスの形状は、カード状でもチップ状でも良く、情報処理装置に埋め込む形態であっても良い。また、ＩＣカードは接触通信手段のみを有しても良い。
【００９３】
（第５の実施形態）
次に、本発明の第５の実施形態について説明する。第５の実施形態は、通信方式に応じてインストール可能なあるいは削除する端末アプリおよび設定命令の設定を変えるようにしたものである。なお、構成自体は、図１に示す実施形態１のものと同じであるので、図１を参照して説明する。
【００９４】
図１に示すように、第５の実施形態でも、第１の実施形態と同様に、端末（機器１）である携帯電話１０と、ＩＣカード（機器２）である携帯電話１０に装着されたチップ状のコンビカード２０と、ゲート機器（機器３）であるゲート４０から構成されている。
【００９５】
そして、第５の実施形態の場合、ＩＣカード（機器２）であるコンビカード２０が複数通信方式に対応した近距離無線通信機能を有する非接触通信手段２２を有しており、通信方式によってンストール可能なあるいは削除する端末アプリおよび設定命令の設定を変えるようにしている。
【００９６】
ここでは、一例として、会社の入場処理と退場処理とで、異なる通信方式を用いて端末アプリおよび設定命令の設定を変える例について説明する。
【００９７】
図２７は、第５の実施形態における会社の入場処理と退場処理とを例にした認証情報ＤＢ２５の一例を示す。
【００９８】
図２７の例では、通信方式としてＩＳＯ１４４４３ｔｙｐｅＡ等の独自通信方式Ａと、ＩＳＯ１４４４３ｔｙｐｅＢ等の独自通信方式Ｂとの２つがあり、独自通信方式Ａの場合、インストール可能な端末アプリＩＤとして端末アプリ１ＩＤ（個人用メーラ）および端末アプリ２ＩＤ（ゲーム）、インストール可能な設定命令ＩＤとして個人のネットワーク設定や、壁紙、通常通話モード等の設定命令５ＩＤ、削除する端末アプリＩＤとして端末アプリ３ＩＤ（内線番号閲覧ブラウザ）、削除する設定命令ＩＤとして（会社用設定である会社のネットワーク設定、壁紙、内線モード等の設定命令７ＩＤがあることを示している。
【００９９】
また、独自通信方式Ｂの場合、インストール可能な端末アプリＩＤとして端末アプリ１ＩＤ（会社用メーラ）および端末アプリ３ＩＤ（内線番号閲覧ブラウザ）があり、インストール可能な設定命令ＩＤとして設定命令７ＩＤ（会社用設定：会社のネットワーク設定、壁紙、内線モード）、削除する端末アプリＩＤとして端末アプリ１ＩＤ（個人用メーラ）および端末アプリ２ＩＤ（ゲーム）、削除する設定命令ＩＤとして設定命令５ＩＤ（個人のネットワーク設定、壁紙、通常通話モード）があるものとする。
【０１００】
これにより、同一のゲートアプリ４３から命令が来ても、あるいはアプリＩＤにかかわらず、通信方式に応じて、設定を変更することができる。
【０１０１】
例えば、図２７の例では、例えば、ＤＢテーブルのＩＤ１が出口、ＩＤ２が入り口の処理とする。ＩＤ１の入り口と、ＩＤ２の出口とでは、ゲートアプリＩＤは同じだが、通信方式が独自通信方式Ａと、独自通信方式Ｂとで異なるものとする。なお、ゲートアプリＩＤはなくてもよく、ゲートアプリＩＤでなく、ゲート機器ＩＤでもよい。
【０１０２】
この例の場合、個人用アプリとして、個人用メーラ（アプリ１）、ゲーム（アプリ２）、会社用アプリとして、会社用メーラ（アプリ４）、コンビカード２０内に格納された内線番号データにアクセスできる内線電話番号閲覧ブラウザ（アプリ３）があり、入口（２）と、出口（１）で削除またインストールされる。
【０１０３】
また、設定命令も、会社用、個人用があり、例えば、アクセス可能なネットワークの設定や、壁紙、通話モードなどが切り替えられる。
【０１０４】
次に図を参照して動作を説明する。
【０１０５】
図２８は、第５の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図である。
【０１０６】
本実施形態の場合、機器２であるコンビカード２０の非接触通信手段（３）２２が、機器３であるゲート４０の非接触通信手段（４）４１と非接触通信を行い、機器３であるゲート４０から機器２であるコンビカード２０に対し、処理要求が送信された場合（６−１）、コンビカード２０のＣＰＵ２３は、その非接触通信の通信方式を検出し（６−２）、機器３であるゲート４０との間で認証処理を行い（６−３）、認証情報ＤＢ２５の認証情報を参照して認証処理を確認する（６−４）。
【０１０７】
コンビカード２０のＣＰＵ２３は、認証処理が確認できた場合、機器３であるゲート４０に対し、認証した処理を通知する（６−５）。これにより、ゲート４０では、機器２であるコンビカード２０に対しインストールするアプリや設定命令を確認することができる。なお、この通知は、省略しても勿論よい。そして、ゲート４０は、その処理通知を受けて、通信方式に応じてゲートアプリ４３に対応したゲートを開く（６−６）。
【０１０８】
一方、コンビカード２０のＣＰＵ２３は、接触通信手段（２）２１を介し、機器１である携帯電話１０に対し、検出した通信方式に応じて、インストール可能なあるいは削除する端末アプリＩＤおよび設定命令ＩＤの設定要求を送信し（６−７）、認証処理を行う（６−８）。
【０１０９】
そして、認証できた場合には、コンビカード２０のＣＰＵ２３は、接触通信手段（２）２１を介し、機器１である携帯電話１０に対し、検出した通信方式に応じて、インストール可能なあるいは削除する端末アプリＩＤおよび設定命令ＩＤを送信し（６−９）、携帯電話１０では、コンビカード２０とゲート４０との間の通信方式に応じたインストール可能なあるいは削除する端末アプリＩＤおよび設定命令ＩＤを、機器２のＣＰＵ２３からの指示に従いインストールまたは削除し（６−１０）、その結果をコンビカード２０へ通知する（６−１１）。
【０１１０】
これにより、携帯電話１０へは、コンビカード２０とゲート４０との間の通信方式に応じた端末アプリＩＤおよび設定命令ＩＤをインストールしたり、あるいは通信方式に応じて削除することが可能となる。
【０１１１】
なお、コンビカード２０と機器１である携帯電話１０との間の認証処理は、インストール可能なあるいは削除する端末アプリＩＤおよび設定命令ＩＤの設定要求の前に行っても良い。また、コンビカード２０と機器１である携帯電話１０に装着した時点で認証処理する場合には、コンビカード２０と携帯電話１０との間の認証処理は、不要となる。
【０１１２】
このように、第５の実施形態によれば、通信方式に応じて、携帯電話１０にインストールや、携帯電話１０から削除する端末アプリや設定命令を変更することにより、場所だけでなく、通信方式に応じても、携帯電話１０の機能を変更することができる。
【０１１３】
なお、本実施形態では、通信方式に応じてインストール可能なあるいは削除する端末アプリおよび設定命令の設定を変える機能をＣＰＵ２３に持たせているが、認証アプリ２４にこのような機能を持たせるようにしても勿論良い。
【０１１４】
（第６の実施形態）
次に、本発明の第６の実施形態について説明する。第６の実施形態は、通信方式に応じて有効および無効（使用禁止）にするカードアプリを変えるようにしたものである。なお、構成自体は、カードアプリを使用する図５に示す第２の実施形態や、図１０に示す第３の実施形態、図１２に示す第３の実施形態のものと同じであるので、図１を参照して説明する。
【０１１５】
機器２であるコンビカード２０が、複数の近距離無線通信機能を有する非接触通信手段（３）２２を有する場合、通信方式によってカードアプリの有効または無効を変えることができる。ここで、カードアプリを無効にする、とは、例えば、Ｒ／Ｗ（リードライタ）からＩＣカードにＩＳＯ７８１６規格のセレクトコマンドを送っても、ＩＣカードから応答を返さない状態をいう。
【０１１６】
ここで、近距離無線によって、用途が限定される場合がある。例えば、ＩＳＯ１４４４３タイプＡは金融用途、ＩＳＯ１４４４３タイプＢは公共向け用途、ＪＩＣＳＡＰ２．０は交通向け等の特定エリア用途などと限定されている。
【０１１７】
このように、通信方式に応じて携帯電話１０の端末アプリ１４からコンビカード２０のカードアプリ２８へのアクセスを制限することで、ユーザが分野外のどのカードアプリ２８を格納しているかゲート４０等のＲ／Ｗ（リードライタ）に分からないようにする。例えば、カードアプリＩＤは公知なものなので、どのＲ／Ｗ（リードライタ）でも、ＩＳＯ７８１６規格のセレクトコマンドを送ると、コンビカード２０等のＩＣカードからの応答でカードアプリの有無が分かってしまう。
【０１１８】
つまり、公共のサービス用のＲ／Ｗ（リードライタ）が、そのユーザがどんなクレジットカードアプリをもっているかという個人情報を、ユーザに知られずに取得することが可能となる。
【０１１９】
そこで、この第６の実施形態では、通信方式に応じて、無効、すなわち使用禁止にするアプリＩＤを設定できるようにしたものである。
【０１２０】
図２９は、第６の実施形態の認証情報ＤＢ２５の内容の一例を示す図である。
【０１２１】
図２９において、通信方式がＩＳＯ１４４４３ｔｙｐｅＢの場合、無効にするアプリＩＤはカードアプリ３ＩＤ（クレジットカード）、通信方式がＩＳＯ１４４４３ｔｙｐｅＡの場合、無効にするアプリＩＤはカードアプリ１ＩＤ（運転免許証）、通信方式がＪＩＣＳＡＰ２．０の高速コマンド仕様の場合、無効にするアプリＩＤはカードアプリ３ＩＤ（クレジットカード）であるとする。
【０１２２】
次に図を参照して動作を説明する。
【０１２３】
図３０は、第６の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図である。
【０１２４】
本実施形態の場合、機器２であるコンビカード２０の非接触通信手段（３）２２が、機器３であるゲート４０の非接触通信手段（４）４１と非接触通信を行い、機器３であるゲート４０から機器２であるコンビカード２０に対し、リクエストコマンドが送信された場合（７−１）、コンビカード２０のＣＰＵ２３は、その非接触通信の通信方式を検出し（７−２）、通信方式を検出できた場合、応答コマンドを返す（７−３）。
【０１２５】
そして、機器３であるゲート４０からカードアプリのセレクトコマンドが送信された場合には（７−４）、コンビカード２０のＣＰＵ２３は、認証情報ＤＢ２５を参照してアクセス可否を確認し（７−５）、セレクトコマンド応答を、機器３であるゲート４０に対し返す（７−６）。
【０１２６】
つまり、コンビカード２０のＣＰＵ２３は、認証情報ＤＢ２５に格納された図２９の認証情報を参照し、ゲート４０から指定されたカードアプリＩＤが、コンビカード２０とゲート４０との間の通信方式に対応した無効にするアプリＩＤに指定されていなければ正常応答を返し、指定されていればエラー応答を、セレクトコマンド応答とし、ゲート４０に対し返すようにする。
【０１２７】
例えば、コンビカード２０とゲート４０との間の通信方式がＩＳＯ１４４４３ｔｙｐｅＢであり、ゲート４０から指定されたカードアプリＩＤが、カードアプリ３ＩＤ（クレジットカード）の場合は、図２９に示す認証情報ＤＢ２５の内容を参照すると、無効にするアプリＩＤであるため、コンビカード２０はゲート４０に対し、セレクトコマンド応答としてエラー応答を返す。通信方式がＪＩＣＳＡＰ２．０の高速コマンド仕様の場合も同様である。
【０１２８】
これに対し、コンビカード２０とゲート４０との間の通信方式がＩＳＯ１４４４３ｔｙｐｅＢであり、ゲート４０から指定されたカードアプリＩＤが、カードアプリ１ＩＤ（運転免許証）の場合は、図２９に示す認証情報ＤＢ２５の内容を参照すると、無効にするアプリＩＤには該当しないため、コンビカード２０はゲート４０に対し、セレクトコマンド応答として正常応答を返す。
【０１２９】
これにより、コンビカード２０とゲート４０との間の通信方式に応じて有効および無効（使用禁止）にするカードアプリ２８が変わるので、携帯電話１０の端末アプリ１４は、コンビカード２０とゲート４０との間の通信方式に応じて、コンビカード２０におけるカードアプリ２０にアクセスできる場合と、アクセスできない場合とが生じることになる。
【０１３０】
このように、第６の実施形態によれば、コンビカード２０とゲート４０との間の通信方式に応じてコンビカード２０内の端末アプリ２７の無効にするアプリＩＤを設定できるようにしたため、通信方式に応じてコンビカード２０等のＩＣカードへのアクセス制限をすることで、ユーザが分野外のどのアプリを格納しているかゲート４０等のＲ／Ｗ（リードライタ）に分からないようにすることができる。
【０１３１】
なお、この第６の実施形態では、通信方式に応じて無効にするアプリＩＤを指定するように説明したが、この第６の実施形態と、前述の第５の実施形態とを組み合わせて、機器２であるコンビカード２０と、機器３であるゲート４０との間の１回の通信方式の検出および認証処理により、通信方式に応じて、インストールまたは削除する端末アプリＩＤおよび設定命令ＩＤ、および無効にするアプリＩＤを同時に変えるようにしても勿論よい。
【０１３２】
また、この第６の実施形態では、機器２であるコンビカード２０のＣＰＵ２３にコンビカード２０とゲート４０との間の通信方式に応じてコンビカード２０内の端末アプリ２７の無効にするアプリＩＤを設定する機能を持たせたが、コンビカード２０の認証アプリ２４等にかかる機能を持たせても勿論良い。
【０１３３】
（第７の実施形態）
次に、本発明の第７の実施形態について説明する。第７の実施形態は、前回、機器２であるコンビカード２０と機器１である携帯電話１０との間で有効にした設定が正しく無効化されていれば、今回、機器３であるゲート４０と、機器２であるコンビカード２０との認証を許可するようにしたものである。
【０１３４】
図３１は、第７の実施形態の構成を示すブロック図である。
【０１３５】
この第７の実施形態では、機器２であるコンビカード２０に端末設定管理部２１０を設け、端末設定管理部２１０により前回の機器１である携帯電話１０と機器２であるコンビカード２０で有効にした設定が、正しく無効化されていれば、今回、機器３であるゲート４０と機器２であるコンビカード２０との間の認証を許可するようにしたものである。なお、端末設定管理部２１０は、認証アプリ２４と一体でも勿論よいし、ＣＰＵ２３と一体でも勿論よい。その他の構成は、図１に示す実施形態１等のものと同じであるので、図１の構成と同一符号を付して説明を省略する。
【０１３６】
図３２に、第７の実施形態の認証情報ＤＢ２５に設定されたデータの一例を示す。
【０１３７】
認証情報ＤＢ２５には、ＩＤ１、ＩＤ２それぞれのデータが設定されている。
【０１３８】
ＩＤ１の場合、ｗｗｗ．ａｐｐ．ｃｏ．ＪＰ／ｇａｔｅ１、通信方式はＩＳＯ１４４４３ｔｙｐｅＢ、有効時間は５；００時間、インストール可能な端末アプリＩＤおよび設定命令ＩＤとして端末アプリ３ＩＤ（内線番号閲覧ブラウザ）および設定命令７ＩＤ（会社用設定：会社のネットワーク設定、壁紙、内線モード）、削除する端末アプリＩＤおよび設定命令ＩＤとして端末アプリ２ＩＤ（ゲーム）および設定命令５ＩＤ（個人のネットワーク設定、壁紙、通常通話モード）が設定されている。
【０１３９】
また、ＩＤ２の場合、ｗｗｗ．ａｐｐ．ｃｏ．ＪＰ／ｇａｔｅ２、通信方式はＵＷＢ（Ｕｌｔｒａ ＷＩＤｅ Ｂａｎｄ）、有効時間は制限なし、インストール可能な端末アプリＩＤおよび設定命令ＩＤとして端末アプリ２ＩＤ（ゲーム）および設定命令５ＩＤ（個人のネットワーク設定、壁紙、通常通話モード）、削除する端末アプリＩＤおよび設定命令ＩＤとして端末アプリ３ＩＤ（内線番号閲覧ブラウザ）および設定命令７ＩＤ（会社用設定：会社のネットワーク設定、壁紙、内線モード）が設定されている。
【０１４０】
図３３に、第７の実施形態の端末設定管理部２１０に設定されたデータの一例を示す。
【０１４１】
端末設定管理部２１０に設定されたデータでは、ＩＤ１として、機器３のＩＤがｗｗｗ．ａｐｐ．ｃｏ．ｊｐ／ｇａｔｅｔｅｒｍｉｎａｌ１、ゲートアプリＩＤがｗｗｗ．ａｐｐ．ｃｏ．ｊｐ／ｇａｔｅａｐｐ１、機器１のＩＤがｗｗｗ．ａｐｐ．ｃｏ．ｊｐ／ｔｅｒｍｉｎａｌ１、設定時のタイムスタンプが２００４／１２／２４ １５：３２：０２、有効時間が５：００時間、認証情報ＤＢ２５のＩＤが１、インストールした時の端末アプリＩＤが端末アプリ３ＩＤ（内線番号閲覧ブラウザ）、インストールした設定命令ＩＤが設定命令７ＩＤ（会社用設定：会社のネットワーク設定、壁紙、内線モード）、削除した端末アプリＩＤが端末アプリ２ＩＤ（ゲーム）、削除した設定命令ＩＤが設定命令５ＩＤ（個人のネットワーク設定、壁紙、通常通話モード）、設定処理結果が正常である、等のデータが、認証アプリ２４から端末設定管理部２１０への設定通知処理により格納される（図３４の８−１４）。
【０１４２】
それ以外に、端末設定管理部２１０に設定されたデータでは、図３３に示すように、復活通知時のタイムスタンプとして２００４／１２／２４ ２０：３２：０２、復活処理結果として正常が、機器１のＣＰＵ１２から機器２の認証アプリ２４への復活通知結果に基づく認証アプリ２４から端末設定管理部２１０への復活結果通知処理により格納される（図３４の８−２０）。
【０１４３】
次に図を参照して動作を説明する。
【０１４４】
図３４は、第７の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図である。
【０１４５】
まず、インストール時の処理から説明すると、本実施形態の場合、機器２であるコンビカード２０の非接触通信手段（３）２２が、機器３であるゲート４０の非接触通信手段（４）４１と非接触通信を行い、機器３であるゲート４０のゲートアプリ４３から機器２であるコンビカード２０の認証アプリ２４に対し、認証要求が送信された場合（８−１）、コンビカード２０の認証アプリ２４は、機器３であるゲート４０との間で認証処理を行う（８−２）。
【０１４６】
そして、認証処理がＯＫであった場合、コンビカード２０の認証アプリ２４は、前回の結果を端末設定管理部２１０に対し要求し（８−３）、端末設定管理部２１０は、前回の結果がＯＫであれば、認証アプリ２４に対し前回結果ＯＫを返す（８−４）。
【０１４７】
すると、認証アプリ２４は、ゲート４０のゲートアプリ４３に対し、前回結果ＯＫを通知して（８−５）、ゲート４０のゲートアプリ４３は、ゲートをオープンにする（８−６）。なお、機器２であるコンビカード２０と、機器３であるゲート４０との間の非接触通信での認証時に前回の端末設定の結果を取得した際、前回有効にした設定が正しく無効化されていない場合は、認証を許可しないようにする。
【０１４８】
また、コンビカード２０の認証アプリ２４は、前回結果ＯＫの場合、機器１である携帯端末１０に対しインストール要求を送信し（８−７）、携帯端末１０のＣＰＵ１２との間で認証処理を実行する（８−８）。
【０１４９】
認証処理がＯＫの場合、コンビカード２０の認証アプリ２４は、機器１である携帯端末１０に対し、端末アプリ２７を送信し（８−９）、携帯端末１０はその端末アプリ２７を受信してインストールする（８−１０）。
【０１５０】
そして、携帯端末１０のＣＰＵ１２は、コンビカード２０から受信した端末アプリ２７がインストールできた場合は、インストール結果ＯＫの通知をコンビカード２０の認証アプリ２４に対し行ない（８−１１）、認証アプリ２４は、端末設定管理部２１０に対し設定通知を行なう（８−１３）。
【０１５１】
端末設定管理部２１０は、認証アプリ２４からの設定通知により、図３３に示すＩＤ、機器３のＩＤ、ゲートアプリＩＤ、機器１のＩＤ、設定時のタイムスタンプ、有効時間、認証情報ＤＢのＩＤ、インストールした時の端末アプリＩＤ、インストールした設定命令ＩＤ、削除した設定命令ＩＤ、設定処理結果を格納し（８−１４）、かかるデータの格納後、格納結果ＯＫの通知を認証アプリ２４に対し行う（８−１５）。
【０１５２】
一方、携帯端末１０では、ンストール結果ＯＫの通知をコンビカード２０の認証アプリ２４に対し行なった（８−１１）後、タイマー管理を行う（８−１６）。ここで、このタイマー管理を行う代わりに、コンビカード２０の端末設定管理部２１０が認証アプリ２４に対し格納結果を通知（８−１５）した後に、認証アプリ２４がタイマー管理を行い、後述する機器１の携帯端末１０における復活処理（８−１７）の前に機器２の認証アプリ２４から機器１のＣＰＵ１２に対し復活命令を行うようにしても良い。これで、インストール時の処理が終了する。
【０１５３】
一方、復活時の処理は、機器１である携帯端末１０にて、復活処理、すなわちインストールした端末アプリ・設定命令の削除処理を行った場合（８−１７）、携帯端末１０のＣＰＵ１２は、復活結果ＯＫの通知をコンビカード２０の認証アプリ２４に対し行う（８−１８）。
【０１５４】
ここで、復活時の処理の際、インストールされた端末アプリを削除するが、例えば、有効時間内に出口処理をした場合などは、インストールされた端末アプリがすでに削除されている場合もある。このような場合にも、復活結果ＯＫ、もしくは削除済みをコンビカード２０の認証アプリ２４に対し行うようにする。
【０１５５】
機器２であるコンビカード２０の認証アプリ２４は、携帯端末１０のＣＰＵ１２からの復活結果ＯＫの通知を受けて、復活結果通知を端末設定管理部２１０へ送信する（８−１９）。
【０１５６】
端末設定管理部２１０では、認証アプリ１９からの復活結果通知を受けると、例えば、図３３に示す復活通知時のタイムスタンプ、および復活処理結果を認証情報に格納し（８−２０）、格納結果ＯＫであれば、その格納結果ＯＫを認証アプリ２４に通知する（８−２１）。
【０１５７】
なお、よりセキュアにするためには、携帯端末１０のＣＰＵ１２から機器２であるコンビカード２０の認証アプリ２４に対する復活結果ＯＫの通知処理（８−１８）の前か後ろに認証処理を入れるようにしても勿論良い。
【０１５８】
このように、第７の実施形態によれば、前回、機器２であるコンビカード２０と機器１である携帯電話１０との間で有効にした設定が正しく無効化されていれば、今回、機器３であるゲート４０と、機器２であるコンビカード２０との認証を許可する一方、前回、機器２であるコンビカード２０と機器１である携帯電話１０との間で有効にした設定が正しく無効化されていない場合には、今回、機器３であるゲート４０と機器２であるコンビカード２０との認証を許可しないようにしたので、毎回、毎回、機器１と機器２との間で有効にした設定が正しく無効にしたかを確認してから、機器３と機器２との認証を許可することができ、よりセキュリティを向上させることができる。
【０１５９】
また、この第７の実施形態では、端末設定管理部２１０は、前回の端末設定の結果を管理する際、設定した内容である設定命令やインストールを認証情報に格納すると共に、有効時間後に削除（無効化）命令を出して削除を確認すると共に、端末１である携帯端末１０がタイマー管理しているその有効時間に基づいて削除管理通知を受け付け、前回の設定である図３３に示す設定内容等を履歴として認証情報に格納するようにしたので、次回ゲート認証時にその認証情報を参照することにより確実に前回の履歴を提供することができる。
【０１６０】
なお、この第７の実施形態では、認証アプリ２４とは別に、端末設定管理部２１０を設けて説明したが、端末設定管理部２１０は、認証アプリ２４と一体、すなわちその一機能として設けたり、さらにはＣＰＵ２３と一体、すなわちその一機能として設けるようにしても勿論よい。
【０１６１】
（第８の実施形態）
次に、本発明の第８の実施形態について説明する。第８の実施形態は、機器１である携帯電話のメモリ容量確保等のため、携帯電話の端末アプリを退避させた場合、機器２であるコンビカードがその端末アプリを関して、設定解除処理の際に、インストールし直すようにしたものである。
【０１６２】
図３５は、第８の実施形態の構成を示すブロック図である。
【０１６３】
図３５において、第８の実施形態の場合、機器１である携帯電話１０は、携帯電話１０における端末アプリの退避を管理する端末アプリ退避管理部１２０をさらに有している。また、機器２であるコンビカード２０は、携帯電話１０における端末アプリの退避を管理した際の端末の設定を管理する端末設定管理部２２０をさらに有している。なお、その他の構成は、図１などに示すものと同じであるので、同一符号を付してその説明は省略する。
【０１６４】
つまり、この第８の実施形態では、携帯電話１０からの端末アプリの退避する場合は、機器２であるコンビカード２０からインストール要求受信時に、携帯電話１０の端末メモリ（図示せず）の容量が少なく、新たに端末アプリ２７をインストールできない場合は、端末設定管理部２２０と、端末アプリ退避管理部１２０とで、認証を行う。そして、その認証に成功すれば、携帯電話１０がインストールしている端末アプリと、その端末アプリが保持するデータとを、端末設定管理部２２０が機器１の端末アプリ退避管理部１２０からしかアクセスできないセキュアな領域、例えば、ＩＣカード２０のタンパ領域またはＩＣカード２０の暗号化されたフラッシュメモリ領域などに格納する。また、認証時に鍵生成を行い、その鍵情報に基づいて暗号化して保存してもよい。
【０１６５】
機器１である携帯電話１０にて退避する端末アプリの選択方法は、機器１で端末アプリに優先順位をつけて保持しておく、あるいは機器２であるコンビカード２０から例えば、インストール要求に含めて退避するアプリを指定する等がある。
【０１６６】
一方、復活時は、機器２であるコンビカード２０から設定解除命令時に、コンビカード２０に退避されたアプリがあれば、設定解除処理確認後に、退避された端末アプリの復活命令を送り復活のための認証処理を行わせる。そして、端末設定管理部２２０と端末アプリ退避管理部１２０との間で認証を行い、その認証が成功すれば、退避された端末アプリと、そのデータとを端末アプリ退避管理部１２０に送信し、端末アプリ退避管理部１２０がその端末アプリの再インストール、端末アプリデータのリストアを行う。
【０１６７】
なお、この第８の実施形態においても、前述の第７の実施形態と同様に、機器２であるコンビカード２０と、機器３であるゲートとの間の非接触通信での認証時に、前回の端末設定の結果を取得して、前回機器１と機器２との間で有効にした設定が正しく無効化されている場合のみ、今回の機器２であるコンビカード２０と機器３であるゲートとの間の認証を許可するようにしても勿論よい。
【０１６８】
次に図を参照して動作を説明する。
【０１６９】
図３６は、第８の実施形態における携帯電話、コンビカード及びゲートの動作を示すシーケンス図である。
【０１７０】
まず、端末アプリおよびそのデータの退避時の処理から説明すると、本実施形態の場合、機器２であるコンビカード２０の非接触通信手段（３）２２が、機器３であるゲート４０の非接触通信手段（４）４１と非接触通信を行い、機器３であるゲート４０のゲートアプリ４３から機器２であるコンビカード２０の認証アプリ２４に対し、認証要求が送信された場合（９−１）、コンビカード２０のＣＰＵ２３は、機器３であるゲート４０との間で認証処理を行う（９−２）。
【０１７１】
そして、認証処理がＯＫであった場合、コンビカード２０の認証アプリ２４は、前回の結果を端末設定管理部２２０に対し要求し（９−３）、端末設定管理部２２０は、前回の結果がＯＫであれば、認証アプリ２４に対し前回結果ＯＫを返す（９−４）。
【０１７２】
すると、認証アプリ２４は、ゲート４０のゲートアプリ４３に対し、前回結果ＯＫを通知して（９−５）、ゲート４０のゲートアプリ４３は、ゲートをオープンにする（９−６）。なお、この機器２であるコンビカード２０と機器３であるゲート４０との間の非接触通信での認証時に前回の端末設定の結果を取得した際、前回有効にした設定が正しく無効化されていない場合は、認証を許可しないようにする。
【０１７３】
また、コンビカード２０の認証アプリ２４は、前回結果ＯＫと判断された場合、機器１である携帯端末１０に対しインストール要求を送信する（９−７）。
【０１７４】
すると、携帯端末１０のＣＰＵ１２は、端末アプリ退避管理部１２０に対しインストール可否を問い合わせ（９−８）、端末アプリ退避管理部１２０がインストールの可否を判断する（９−９）。そして、インストール可と判断した場合、端末アプリ退避管理部１２０は、コンビカード２０の端末設定管理部２２０に対し、アプリ退避要求を送信して（９−１０）、端末アプリ退避管理部１２０と端末設定管理部２２０との間で認証処理を行う（９−１１）。
【０１７５】
その認証結果がＯＫの場合、端末アプリ退避管理部１２０は、携帯電話１０から退避させるべき端末アプリおよびそのデータを、コンビカード２０側の例えば端末設定管理部２２０に対し送信し（９−１２）、端末設定管理部２２０に退避させるべき端末アプリおよびそのデータを格納させる（９−１３）。
【０１７６】
そして、その格納処理が無事終了した場合、コンビカード２０の端末設定管理部２２０は、格納ＯＫの結果通知を、携帯端末１０の端末アプリ退避管理部１２０に対し送信し（９−１４）、端末アプリ退避管理部１２０は、ＣＰＵ１２に対し応答可かを返信する（９−１５）。
【０１７７】
すると、携帯電話１０のＣＰＵ１２は、コンビカード２０の認証アプリ２４との間で認証処理を実行し（９−１６）、その認証処理がＯＫの場合には、コンビカード２０の認証アプリ２４から携帯電話１０のＣＰＵ１２に対し新たにインストールする端末アプリが送信され（９−１７）、送信された端末アプリを受信してインストールする（９−１８）。
【０１７８】
携帯電話１０のＣＰＵ１２は、コンビカード２０から受信した端末アプリ２７がインストールできた場合は、インストール結果ＯＫの通知をコンビカード２０の認証アプリ２４に対し行ない（９−１９）、認証アプリ２４は端末設定管理部２２０に対し設定通知を行なう（９−２０）。
【０１７９】
端末設定管理部２２０は、認証アプリ２４からの設定通知により、第７の実施形態と同様に、図３３に示すＩＤ、機器３のＩＤ、ゲートアプリＩＤ、機器１のＩＤ、設定時のタイムスタンプ、有効時間、認証情報ＤＢのＩＤ、インストールした時の端末アプリＩＤ、インストールした設定命令ＩＤ、削除した設定命令ＩＤ、設定処理結果を格納する（９−２１）。
【０１８０】
端末設定管理部２２０は、かかるデータの格納後、格納結果ＯＫの通知を認証アプリ２４に対し行う（９−２２）。これで、携帯電話１０において先に保存されている端末アプリをコンビカード２０へ退避しての新たな端末アプリのインストール時の処理が終了する。なお、第７の実施形態と同様に、コンビカード２０では、端末設定管理部２２０は、認証アプリ２４またはＣＰＵ２３と一体でも勿論よい。
【０１８１】
次に、復活時の処理について説明する。
【０１８２】
復活時の処理は、機器１である携帯端末１０のＣＰＵ１２が、まず、タイマー管理によりインストールした端末アプリの削除処理を行い（９−２３）、その削除処理が終了した場合、端末アプリ退避管理部１２０に対し、復活要または不要の問い合わせを行う（９−２４）。
【０１８３】
端末アプリ退避管理部１２０は、その問い合わせを受けて、復活要または不要の判断を行い（９−２５）、端末アプリを退避させており復活をする必要がある場合は、コンビカード２０の端末設定管理部２２０に対し復活要急を送信し（９−２６）、端末アプリ退避管理部１２０と端末設定管理部２２０との間で認証処理を行う（９−２７）。
【０１８４】
その認証処理の結果、認証がＯＫの場合は、端末設定管理部２２０は端末アプリ退避管理部１２０に対し退避させていた端末アプリおよびその端末データのデータを送信し（９−２８）、端末アプリ退避管理部１２０はその退避させていた端末アプリおよびその端末データのデータを受信してメモリ等にインストールして復活し（９−２９）、復活結果を端末設定管理部２２０に対し送信する（９−３０）。
【０１８５】
すると、端末設定管理部２２０は、端末アプリ退避管理部１２０からの復活結果を、例えば、図３３に示す認証情報等に格納し（９−３１）、格納結果ＯＫであれば、その格納結果ＯＫを端末アプリ退避管理部１２０へ通知する（９−３２）。端末アプリ退避管理部１２０は、ＣＰＵ１２に対し復活完了通知を行い（９−３３）、復活時の処理が終了する。
【０１８６】
なお、端末アプリ退避管理部１２０と端末設定管理部２２０との間の認証処理（９−１１）は、端末アプリ退避管理部１２０から端末設定管理部２２０へのアプリ退避要求（９−１０）の前でもよく、携帯電話１０のＣＰＵ１２と、コンビカード２０の認証アプリ２４との間の認証処理（９−１６）は、認証アプリ２４から携帯電話１０のＣＰＵ１２へのインストール要求（９−７）の前でもよい。また、復活時の処理における端末アプリ管理部１２０と認証アプリ２４との間における認証処理は、ＣＰＵ１２から復活要または不要の問い合わせを受ける（９−２４）前に実行しても良い。さらに、機器２であるコンビカード２０を機器１である携帯電話１０に装着した時点で認証する形態をとる場合には、端末アプリ退避管理部１２０と端末設定管理部２２０との間の認証処理（９−１１，９−２７）や、携帯電話１０のＣＰＵ１２と認証アプリ２４との間の認証処理（９−１６）などは、不要となり、省略しても良い。
【０１８７】
また、機器２であるコンビカード２０にタイマー機能がある場合には、コンビカード２０で時間管理を行い、設定時間になると、機器１のＣＰＵ１２によるタイマー管理による削除処理（９−２３）の前に、機器２から機器１にタイマー機能に基づき削除命令を送って、機器１ではこの削除命令により削除処理を行うようにしてもよい。この場合、機器２の端末設定管理部２２０と、機器１の端末アプリ退避管理部１２０との間の認証処理（９−２５）は、機器２から機器１への削除命令の前に、または機器１のＣＰＵ１２によるタイマー管理による削除処理（９−２３）の前に行ってもよい。
【０１８８】
図３７に、第８の実施形態の端末アプリ退避管理部１２０における詳細処理を示すフローチャートである。
【０１８９】
端末アプリ退避管理部１２０では、まず、ＣＰＵ１２からの端末アプリのインストール可否の問い合わせか否かを判断し（ステップ１０００）、インストール可の場合は（ステップ１０００“ＹＥＳ”）、アプリ管理テーブル（図示せず）等を確認して（ステップ１１００）、端末アプリを退避させずインストールできるか否かを判断する（ステップ１２００）。
【０１９０】
例えば、アプリ管理テーブル（図示せず）等を確認して、格納可能な端末アプリの最大個数が１０コで、すでに端末アプリが１０コ格納されている場合には、端末アプリを退避させずの新規インストールはできないと判断する。なお、インストール可否問い合わせとしては、例えば、可否問合せＩＤ１として、アプリＩＤ３の端末アプリを削除し、アプリＩＤ１，アプリＩＤ２の端末アプリを２つインストールしたいという例が考えられる。
【０１９１】
そして、端末アプリを退避させずインストール可能と判断した場合（ステップ１２００“ＹＥＳ”）、端末アプリ退避管理部１２０は、ＣＰＵ１２にインストール可能を通知して、端末アプリを退避させずインストールを実行させる（ステップ１２５０）。
【０１９２】
一方、端末アプリを退避させずインストール不可と判断した場合（ステップ１２００“ＮＯ”）、端末アプリ退避管理部１２０は、まず、機器２であるコンビカード２０に退避させる端末アプリを決定する（ステップ１３００）。例えば、端末アプリの退避優先度テーブル（図示せず）等を参照して、アプリＩＤ８のゲームの端末アプリ等を退避することに決定する。
【０１９３】
端末アプリ退避管理部１２０は、退避させる端末アプリを決定すると、機器２の端末設定管理部２２０に対し、退避要求を送信し、アプリ退避処理を実施し（ステップ１４００）、その退避結果を管理テーブル等に格納して（ステップ１５００）、スタートに戻る。例えば、アプリＩＤ８のゲームの端末アプリの退避処理を行った場合、その端末アプリの可否問合せＩＤ１や、退避時のタイムスタンプ、退避結果ＯＫ、退避したアプリＩＤ（アプリＩＤ８）、機器２との認証情報等を、管理テーブル等に格納する。
【０１９４】
一方、ステップ３７００にて、インストール可否の問い合わせではなく（ステップ１０００“ＮＯ”）、復活要否の問い合わせであると判断した場合（ステップ１６００“ＹＥＳ”）、復活処理が必要か否かを、アプリ管理テーブル（図示せず）等を参照して確認する（ステップ１７００）。
【０１９５】
復活要否の問い合わせとしては、例えば、インストール可否問合せの可否問合ＩＤ１の設定を解除したので、復活処理が必要であれば復活処理を実行する等の復活要否問合せＩＤ２が考えられる。また、復活処理が必要か否かをアプリ管理テーブル（図示せず）等を参照して確認した際に、可否問合せＩＤ１ではアプリＩＤ８のゲームの端末アプリの退避処理を実施、等と記載されている場合は、復活処理が必要と判断する。
【０１９６】
ここで、復活が不要と判断した場合には（ステップ１８００“ＮＯ”）、ＣＰＵ１２に完了を通知して（ステップ１８５０）、スタートに戻る一方、復活が必要と判断した場合には（ステップ１８００“ＹＥＳ”）、端末アプリ退避管理部１２０は、機器２の端末設定管理部２２０に対し復活要求を送信し、機器２の端末設定管理部２２０等に退避させておいた端末アプリの復活処理を実施する（ステップ１９００）。そして、復活処理の結果をアプリ管理テーブル（図示せず）等に格納して、ＣＰＵ１２にその結果を通知し（ステップ１９５０）、最初に戻る。復活処理の結果としては、例えば、可否問合せＩＤ１、退避時のタイムスタンプ、退避結果ＯＫ、要否問合せＩＤ２、復活時のタイムスタンプ、復活結果ＯＫ、退避・復活したアプリＩＤ（アプリＩＤ８）、機器２との認証情報等がある。
【０１９７】
このように、第８の実施形態によれば、機器１である携帯電話１０に新たな端末アプリをインストールする場合、携帯電話１０のメモリ容量確保等のため、携帯電話１０の端末アプリをコンビカード２０に退避させて、新たな端末アプリを携帯電話１０にインストールし、タイマーの管理等により新たにインストールした端末アプリの設定解除を行った場合には、退避させておいた端末アプリを携帯電話にインストールするようにしたため、携帯電話１０のメモリ容量をそれほど増やさずに、カードアプリ機能や装置機能等が発現されるエリアを限定することができる。
【０１９８】
以上説明したように、本発明の一態様では、セキュアデバイスに、ゲート機器に対して認証処理を行う認証手段と、端末にインストールする端末アプリと、認証手段がゲート機器との認証に成功した場合に、ゲート機器から指定された端末アプリを端末にインストールする制御手段とを設けているため、セキュアデバイスをゲート機器に翳し、正常に通過したエリアでのみ、端末アプリが端末にインストールされる。ゲート機器のゲートアプリが特定の領域で機能するアプリを指定するので、ユーザの登録操作等は不要であり、また、端末へのＧＰＳ受信機等の装備も必要がない。
【０１９９】
また、本発明の別の態様では、セキュアデバイスに、ゲート機器に対して認証処理を行う認証手段と、カードアプリとを設け、認証手段がゲート機器との認証に成功した場合に、ゲート機器から指定されたカードアプリが、端末の端末アプリのアクセスを許容するようにしたため、セキュアデバイスをゲート機器に翳し、正常に通過したエリアでのみ、端末アプリは、カードアプリの利用が可能になる。
【０２００】
また、本発明の別の態様では、セキュアデバイスに、ゲート機器に対して認証処理を行い、認証に成功したゲート機器の識別情報を登録する認証手段と、認証手段がゲート機器との認証に成功したことを条件に所定の動作を行う機器に対して、この機器の検証に供するためにゲート機器の識別情報を送信し、または、この機器に代わって識別情報を検証するカードアプリとを設けたため、ゲート機器が設置された正規の入口から入場しないと、機器は動作しないようにすることができる。
【０２０１】
また、本発明の別の態様では、セキュアデバイスは、ゲート機器との間の通信方式に応じて、端末にインストールあるいは端末から削除する端末アプリケーションを設定するようにしたため、通信方式に応じて簡単に端末にインストールする端末アプリケーション等を変更することができ、セキュリティを簡単に確保することができる。
【０２０２】
また、本発明の別の態様では、セキュアデバイスは、ゲート機器との間で認証を行なう際、端末との間で前回有効にした設定が正しく無効化されているか否かを判断し、正しく無効化されている場合のみ、ゲート機器との間の認証を許可するようにしたため、前回の無効化処理が正しく行われたか否かに基づいて今回のゲート機器との認証を許可することができ、よりセキュリティを確保することができる。
【０２０３】
また、本発明の別の態様では、セキュアデバイスは、ゲート機器との間の通信方式に応じて、カードアプリケーションの有効または無効を設定するようにしたため、通信方式に応じて簡単にセキュリティを確保することができる。
【０２０４】
また、本発明の別の態様では、ゲート機器に、セキュアデバイスまたはセキュアデバイスを保持する端末との通信手段と、通信手段を通じてセキュアデバイスとの認証処理を行い、認証に成功したセキュアデバイスに対して、端末にインストールする端末アプリを指定するゲートアプリとを設けたり、あるいは、ゲート機器に、セキュアデバイスまたはセキュアデバイスを保持する端末との通信手段と、通信手段を通じてセキュアデバイスとの認証処理を行い、認証に成功したセキュアデバイスに対して、端末の端末アプリがアクセスできるカードアプリを指定するゲートアプリとを設けるようにしたため、認証に成功したセキュアデバイスに対して、端末にインストールする端末アプリや、端末アプリがアクセス可能となるカードアプリを指定することができる。
【０２０５】
また、本発明の別の態様では、端末装置は、セキュアデバイスを保持し、ゲート機器との認証に成功したセキュアデバイスから、ゲート機器が指定した端末アプリをインストールするようにしたり、あるいは、端末装置は、セキュアデバイスを保持し、ゲート機器との認証に成功したセキュアデバイスが保持するカードアプリの中で、ゲート機器が指定したカードアプリにアクセスする端末アプリを備えるようにしたため、入口にゲート機器が設置された特定のエリアの中でのみ、端末装置の特殊な機能が発揮できる。
【０２０６】
また、本発明の別の態様では、端末装置は、セキュアデバイスからの新たな端末アプリケーションのインストール要求受信時に、メモリ容量が少なく前記新たな端末アプリケーションをインストールできない場合には、保持している端末アプリケーションを前記セキュアデバイスに退避させてから前記新たな端末アプリケーションをインストールし、その後、インストールした前記新たな端末アプリケーションを削除して、前記退避させた端末アプリケーションを復活させるようにしたため、端末アプリケーションを保存するためのメモリ容量が少ない場合でも、新たな端末アプリケーションを実施させることができる。
【０２０７】
また、本発明の別の態様では、機器が、ゲート機器との認証に成功したセキュアデバイスからゲート機器の識別情報を取得し、この識別情報の検証に成功した場合に所定の動作を行うようにしたり、あるいは、機器が、ゲート機器との認証に成功したセキュアデバイスからゲート機器の識別情報の検証に成功した旨の情報を取得した場合に所定の動作を行うようにしたため、ユーザがセキュアデバイスを所持して正規の入口から入場しないと、機器が動作しないようにすることができる。
【０２０８】
本明細書は、２００４年１月２８日出願の特願２００４−１９４６１に基づく。この内容はすべてここに含めておく。
【産業上の利用可能性】
【０２０９】
本発明は、各種のセキュアデバイスの機能や、各種の端末、装置、機器等の機能を場所、経路、位置、または通信方式、前回の無効化処理、さらにはメモリ容量等との関連で変える場合に利用することができ、オフィス、家庭、医療現場、教育現場など、あらゆる分野での利用が可能である。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【特許請求の範囲】
【請求項１】
ゲート機器に対して認証処理を行う認証手段と、
端末にインストールする端末アプリケーションと、
前記認証手段がゲート機器との認証に成功した場合に、前記ゲート機器から指定された端末アプリケーションを端末にインストールする制御手段と、
を備えるセキュアデバイス。
【請求項２】
ゲート機器と端末アプリケーションとの対応関係が規定された対応情報を保持し、前記制御手段は、ゲート機器から指定された端末アプリケーションと前記ゲート機器との関係が前記対応情報に合致する場合にのみ、前記端末アプリケーションを端末にインストールする請求項１に記載のセキュアデバイス。
【請求項３】
前記制御手段は、ゲート機器との間の通信方式に応じて、前記端末にインストールあるいは前記端末から削除する端末アプリケーションを設定する請求項１に記載のセキュアデバイス。
【請求項４】
さらに、前記認証手段がゲート機器との間で認証を行なう際、端末との間で前回有効にした設定が正しく無効化されているか否かを判断し、正しく無効化されている場合のみ、前記ゲート機器との間の認証を許可する端末設定管理部を有する請求項１記載のセキュアデバイス。
【請求項５】
ゲート機器に対して認証処理を行う認証手段と、
カードアプリケーションと、
前記認証手段がゲート機器との認証に成功した場合に、前記ゲート機器から指定されたカードアプリケーションが、端末の端末アプリケーションのアクセスを許容する制御手段と、
を備えるセキュアデバイス。
【請求項６】
前記認証手段が認証に成功したゲート機器と前記ゲート機器から指定されたカードアプリケーションとの関係を記録するデータベースを保持し、カードアプリケーションは、端末アプリケーションからアクセス要求が有ったときに、前記データベースの情報に基づいて、アクセスの諾否を決定する請求項５に記載のセキュアデバイス。
【請求項７】
前記制御手段は、ゲート機器との間の通信方式に応じて、前記カードアプリケーションの有効または無効を設定する請求項５に記載のセキュアデバイス。
【請求項８】
ゲート機器に対して認証処理を行い、認証に成功したゲート機器の識別情報を登録する認証手段と、
前記認証手段がゲート機器との認証に成功したことを条件に所定の動作を行う機器に対して、前記機器の検証に供するためにゲート機器の前記識別情報を送信し、または、前記機器に代わって前記識別情報を検証するカードアプリケーションと、
を備えるセキュアデバイス。
【請求項９】
前記カードアプリケーションは、前記機器の検証に供するために、入力されたユーザ識別情報を前記機器に送信し、または、前記機器に代わって前記ユーザ識別情報を検証する請求項８に記載のセキュアデバイス。
【請求項１０】
セキュアデバイスまたは前記セキュアデバイスを保持する端末との通信手段と、
前記通信手段を通じて前記セキュアデバイスとの認証処理を行い、認証に成功したセキュアデバイスに対して、端末にインストールする端末アプリケーションを指定するゲートアプリケーションと、
を備えるゲート機器。
【請求項１１】
セキュアデバイスまたは前記セキュアデバイスを保持する端末との通信手段と、
前記通信手段を通じて前記セキュアデバイスとの認証処理を行い、認証に成功したセキュアデバイスに対して、端末の端末アプリケーションがアクセスできるカードアプリケーションを指定するゲートアプリケーションと、
を備えるゲート機器。
【請求項１２】
セキュアデバイスを保持し、ゲート機器との認証に成功した前記セキュアデバイスから、前記ゲート機器が指定した端末アプリケーションをインストールする端末装置。
【請求項１３】
さらに、セキュアデバイスからの新たな端末アプリケーションのインストール要求受信時に、メモリ容量が少なく前記新たな端末アプリケーションをインストールできない場合には、保持している端末アプリケーションを前記セキュアデバイスに退避させてから前記新たな端末アプリケーションをインストールし、その後、インストールした前記新たな端末アプリケーションを削除して、前記退避させた端末アプリケーションを復活させる端末アプリ退避管理部、
を有する請求項１２に記載の端末装置。
【請求項１４】
セキュアデバイスを保持し、ゲート機器との認証に成功した前記セキュアデバイスが保持するカードアプリケーションの中で、前記ゲート機器が指定したカードアプリケーションにアクセスする端末アプリケーションを備える端末装置。
【請求項１５】
前記セキュアデバイスが、着脱可能な状態で装着される請求項１２に記載の端末装置。
【請求項１６】
前記セキュアデバイスが、一体的に埋め込まれる請求項１２に記載の端末装置。
【請求項１７】
ゲート機器との認証に成功したセキュアデバイスから前記ゲート機器の識別情報を取得し、前記識別情報の検証に成功した場合に所定の動作を行う機器。
【請求項１８】
ゲート機器との認証に成功したセキュアデバイスから前記ゲート機器の識別情報の検証に成功した旨の情報を取得した場合に所定の動作を行う機器。
【請求項１】
ゲート機器に対して認証処理を行う認証手段と、
端末にインストールする端末アプリケーションと、
前記認証手段がゲート機器との認証に成功した場合に、前記ゲート機器から指定された端末アプリケーションを端末にインストールする制御手段と、
を備えるセキュアデバイス。
【請求項２】
ゲート機器と端末アプリケーションとの対応関係が規定された対応情報を保持し、前記制御手段は、ゲート機器から指定された端末アプリケーションと前記ゲート機器との関係が前記対応情報に合致する場合にのみ、前記端末アプリケーションを端末にインストールする請求項１に記載のセキュアデバイス。
【請求項３】
前記制御手段は、ゲート機器との間の通信方式に応じて、前記端末にインストールあるいは前記端末から削除する端末アプリケーションを設定する請求項１に記載のセキュアデバイス。
【請求項４】
さらに、前記認証手段がゲート機器との間で認証を行なう際、端末との間で前回有効にした設定が正しく無効化されているか否かを判断し、正しく無効化されている場合のみ、前記ゲート機器との間の認証を許可する端末設定管理部を有する請求項１記載のセキュアデバイス。
【請求項５】
ゲート機器に対して認証処理を行う認証手段と、
カードアプリケーションと、
前記認証手段がゲート機器との認証に成功した場合に、前記ゲート機器から指定されたカードアプリケーションが、端末の端末アプリケーションのアクセスを許容する制御手段と、
を備えるセキュアデバイス。
【請求項６】
前記認証手段が認証に成功したゲート機器と前記ゲート機器から指定されたカードアプリケーションとの関係を記録するデータベースを保持し、カードアプリケーションは、端末アプリケーションからアクセス要求が有ったときに、前記データベースの情報に基づいて、アクセスの諾否を決定する請求項５に記載のセキュアデバイス。
【請求項７】
前記制御手段は、ゲート機器との間の通信方式に応じて、前記カードアプリケーションの有効または無効を設定する請求項５に記載のセキュアデバイス。
【請求項８】
ゲート機器に対して認証処理を行い、認証に成功したゲート機器の識別情報を登録する認証手段と、
前記認証手段がゲート機器との認証に成功したことを条件に所定の動作を行う機器に対して、前記機器の検証に供するためにゲート機器の前記識別情報を送信し、または、前記機器に代わって前記識別情報を検証するカードアプリケーションと、
を備えるセキュアデバイス。
【請求項９】
前記カードアプリケーションは、前記機器の検証に供するために、入力されたユーザ識別情報を前記機器に送信し、または、前記機器に代わって前記ユーザ識別情報を検証する請求項８に記載のセキュアデバイス。
【請求項１０】
セキュアデバイスまたは前記セキュアデバイスを保持する端末との通信手段と、
前記通信手段を通じて前記セキュアデバイスとの認証処理を行い、認証に成功したセキュアデバイスに対して、端末にインストールする端末アプリケーションを指定するゲートアプリケーションと、
を備えるゲート機器。
【請求項１１】
セキュアデバイスまたは前記セキュアデバイスを保持する端末との通信手段と、
前記通信手段を通じて前記セキュアデバイスとの認証処理を行い、認証に成功したセキュアデバイスに対して、端末の端末アプリケーションがアクセスできるカードアプリケーションを指定するゲートアプリケーションと、
を備えるゲート機器。
【請求項１２】
セキュアデバイスを保持し、ゲート機器との認証に成功した前記セキュアデバイスから、前記ゲート機器が指定した端末アプリケーションをインストールする端末装置。
【請求項１３】
さらに、セキュアデバイスからの新たな端末アプリケーションのインストール要求受信時に、メモリ容量が少なく前記新たな端末アプリケーションをインストールできない場合には、保持している端末アプリケーションを前記セキュアデバイスに退避させてから前記新たな端末アプリケーションをインストールし、その後、インストールした前記新たな端末アプリケーションを削除して、前記退避させた端末アプリケーションを復活させる端末アプリ退避管理部、
を有する請求項１２に記載の端末装置。
【請求項１４】
セキュアデバイスを保持し、ゲート機器との認証に成功した前記セキュアデバイスが保持するカードアプリケーションの中で、前記ゲート機器が指定したカードアプリケーションにアクセスする端末アプリケーションを備える端末装置。
【請求項１５】
前記セキュアデバイスが、着脱可能な状態で装着される請求項１２に記載の端末装置。
【請求項１６】
前記セキュアデバイスが、一体的に埋め込まれる請求項１２に記載の端末装置。
【請求項１７】
ゲート機器との認証に成功したセキュアデバイスから前記ゲート機器の識別情報を取得し、前記識別情報の検証に成功した場合に所定の動作を行う機器。
【請求項１８】
ゲート機器との認証に成功したセキュアデバイスから前記ゲート機器の識別情報の検証に成功した旨の情報を取得した場合に所定の動作を行う機器。
【国際公開番号】ＷＯ２００５／０７３８４３
【国際公開日】平成１７年８月１１日（２００５．８．１１）
【発行日】平成１９年９月１３日（２００７．９．１３）
【国際特許分類】
【出願番号】特願２００５−５１７５２２（Ｐ２００５−５１７５２２）
【国際出願番号】ＰＣＴ／ＪＰ２００５／００１２３２
【国際出願日】平成１７年１月２８日（２００５．１．２８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
【国際公開日】平成１７年８月１１日（２００５．８．１１）
【発行日】平成１９年９月１３日（２００７．９．１３）
【国際特許分類】
【国際出願番号】ＰＣＴ／ＪＰ２００５／００１２３２
【国際出願日】平成１７年１月２８日（２００５．１．２８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]