JP2017021443A

JP2017021443A - 電子情報記憶媒体、情報処理方法及び代表アプリケーション

Info

Publication number: JP2017021443A
Application number: JP2015136408A
Authority: JP
Inventors: 正徳浅野; Masanori Asano
Original assignee: Dai Nippon Printing Co Ltd
Current assignee: Dai Nippon Printing Co Ltd
Priority date: 2015-07-07
Filing date: 2015-07-07
Publication date: 2017-01-26

Abstract

【課題】一のサービスに対応する複数のアプリがインストールされている場合であっても、利用者がサービス利用時において使用するアプリを選択しなくて済むとともに、外部装置がサービス提供時に当該サービスに有効な一のアプリを把握して当該アプリに対応するコマンドを送信することができるICチップなどの電子情報記憶媒体等を提供することを課題とする。【解決手段】サービスに対応するグループ毎に複数のサービスアプリと一の代表アプリを対応付けて記憶し、代表アプリを実行することにより、当該代表アプリに対応するグループ内の有効なサービスアプリの数を一つに制御する。【選択図】図５

Description

本発明は、同一のサービスを提供する複数のサービスアプリケーションを記憶するICチップなどの電子情報記憶媒体等の技術分野に関する。

従来、携帯電話分野におけるICカード（ICチップが組み込まれたカード）においては、電話機能に対応したUSIM（Universal Subscriber Identity Module） Applicationのみを搭載したUICC（Universal Integrated Circuit Card）が主流であったが、近年はUSIM Application以外のアプリケーション（以下、「アプリ」と記載する場合がある）が搭載されることが珍しくない。この背景として、モバイル決済の発達に伴って、クレジットカード決済事業者がUSIM内に決済アプリを搭載し、USIMと携帯端末の連携によりモバイル決済を実施しようとしていることが挙げられる。

このように、従来はID-1サイズのカードにより提供されてきたサービスが、USIMによる提供に移行していく傾向が見受けられるが、ID-1サイズのカードによるサービス提供とUSIMによるサービス提供には、『カードと事業者の対応関係』に大きな差がある。ID-1サイズのカードにおいては、基本的に1枚のカードに対し、サービス提供を行う事業者が1社のみ対応する（例えば、A社のクレジット決済サービスを利用する場合、A社から発行されたクレジットカードを提示し、B社のクレジット決済サービスを利用する場合、B社から発行されたクレジットカードを提示するといったように、サービス提供事業者とカードが一対一の関係にある）。すなわち、サービス提供事業者を一意に特定した上で、利用者にカードを発行する運用となっている。後日、利用者がサービス提供事業者を変更する際には、カードを物理的に再発行（再交付）してもらう運用が大半である。一方で、USIMは原則として通信事業者に所有権があるため、サービス提供事業者は、通信事業者に対し、自らのサービス提供アプリをUSIMに搭載する許可を得た上で、全サービス提供事業者が単一のUSIMにアプリをインストールして、サービスを提供する形になる。このため、サービス提供事業者とUSIMとが一対一の関係にならない。また、USIMにおいてアプリは原則として利用者の操作によりインストールやアンインストールされるため、対応関係が変動しうる。したがって、USIMの利用者は複数のサービス提供事業者から好きな事業者を選択することが可能になるが、一方で次に挙げる問題が発生する。

一つ目の問題は、利用者がサービスを受ける際、USIMを搭載する情報処理端末（例えば、スマートフォンや携帯電話端末）上で事業者をわざわざ選択しなければならない（例えば、USIMにクレジット決済サービス用のアプリとして、A社のアプリとB社のアプリがインストールされている場合に、何れかのアプリを選択しなければならない）ことである。

二つ目の問題は、サービス提供時においてリーダーライター（R/W）等の外部装置側は、USIMにインストールされている何れのアプリが有効であるかを確認して、有効であるアプリに対応するコマンドを送信する必要があるため処理が複雑になることである。例えば、USIMにインストールされている複数のアプリが有効化されている場合、USIM側は全ての有効なアプリを外部装置に通知するが、外部装置は何れのアプリに対応するコマンドを送信すればよいか分からずに適切なサービスを提供することができなくなる。

一方で、特許文献１には、ICチップに複数の電子マネー用のアプリがインストールされている場合の利用者の利便性を向上させる技術が開示されている。

特許５３１１６１２号公報

しかしながら、特許文献１に記載の技術では、上記二つの問題を解決することができない。また、例えば、GlobalPlatform Amendment C（以下、Amendment C）では、Application GroupとHead Applicationという2つの概念を用いて、複数のApplication GroupをHead Applicationが代表し、Head Applicationの状態に変動してApplication Groupに含まれるMember Applicationの状態も変化する仕様となっている。しかしながら、この状態変化はMember ApplicationがHead Applicationと同一の状態遷移を取ることを特徴としており、Application Groupの状態が一体的に変化する以上の機能を提供せず、上記問題の解決には寄与しない。

また、クレジットカード決済分野においては、EMVCoが発行しているContactless Mobile Payment Application Activation UI(以下、AAUI)仕様が開示されている。ここでは、決済アプリとしてPPSE（Proximity Payment Systems Environment）という代表的なアプリを準備し、その他の決済アプリの活性化状態に応じて、PPSEのレスポンスデータを変更するメカニズムを提供している。これにより、外部装置が決済処理を行うにあたり、最初に実行するコマンドを固定化するメリットを享受できるが、ユーザは依然として複数の決済アプリの中から1つを選択しなければならず、上記問題の解決には至っていない。

本発明は、上記の問題等に鑑みてなされたもので、一のサービスに対応する複数のアプリがインストールされている場合であっても、利用者がサービス利用時において使用するアプリを選択しなくて済み、外部装置がサービス提供時に当該サービスに有効な一のアプリを把握して当該アプリに対応するコマンドを送信することができるICチップなどの電子情報記憶媒体等を提供することを課題とする。

上記課題を解決するために、請求項１に記載の発明は、サービスに対応するグループ毎に複数のサービスアプリケーションと一の代表アプリケーションを対応付けて記憶するメモリと、前記代表アプリケーションを実行することにより、当該代表アプリケーションに対応する前記グループ内の有効なサービスアプリケーションの数を一つに制御するプロセッサと、を備えることを特徴とする。

また、請求項２に記載の発明は、請求項１に記載の電子情報記憶媒体であって、前記プロセッサは、外部装置から前記代表アプリケーションに対するコマンドを受信した場合に、前記代表アプリケーションを実行することにより、当該代表アプリケーションに対応するグループについて有効となっている一つのサービスアプリケーションを識別する有効アプリケーション識別情報を前記外部装置に送信することを特徴とする。

また、請求項３に記載の発明は、請求項１又は２に記載の電子情報記憶媒体であって、前記プロセッサは、前記代表アプリケーションを実行することにより、前記グループ内で新たにサービスアプリケーションを有効にする場合に、それまで有効であったサービスアプリケーションを無効にする、ことを特徴とする。

また、請求項４に記載の発明は、請求項３に記載の電子情報記憶媒体であって、前記プロセッサは、前記代表アプリケーションを実行することにより、サービスアプリケーションを無効にする場合には、当該サービスアプリケーションを直近に有効であった直近有効サービスアプリケーションとして前記メモリに記憶させ、現在有効なサービスアプリケーションを削除又は無効とする場合に、当該直近有効サービスアプリケーションを有効にする、ことを特徴とする。

また、請求項５に記載の発明は、サービスに対応するグループ毎に複数のサービスアプリケーションと一の代表アプリケーションを対応付けて記憶するメモリと、プロセッサを備える電子情報記憶媒体による情報処理方法であって、前記プロセッサが、前記代表アプリケーションを実行することにより、当該代表アプリケーションに対応する前記グループ内の有効なサービスアプリケーションの数を一つに制御する制御工程、を含むことを特徴とする。

また、請求項６に記載の発明は、サービスに対応するグループ毎に複数のサービスアプリケーションと一の代表アプリケーションを対応付けて記憶するメモリと、プロセッサを備える電子情報記憶媒体における前記プロセッサを、前記代表アプリケーションに対応する前記グループ内の有効なサービスアプリケーションの数を一つに制御する制御手段、として機能させる。

本発明によれば、一のサービスに対応するグループ毎に有効なサービスアプリケーションの数が一つに制御されることから、利用者がサービス利用時において使用するサービスアプリケーションを選択しなくて済む。また、外部装置からアクセスされた場合には、有効な一つのサービスアプリケーションを通知することにより、外部装置はサービス提供時に当該有効なサービスアプリケーションに対応するコマンドを送信することができる。

スマートフォン２の概要構成例を示すブロック図である。 USIM１の概要構成例を示すブロック図である。 USIM１の実行環境の一例を示す概念図である。ＣＰＵ１０による状態変更コマンド受信時処理の一例を示すフローチャートである。ＣＰＵ１０による有効アプリ制御処理の一例を示すフローチャートである。

以下、図面を参照して本発明の実施形態について詳細に説明する。以下に説明する実施形態は、スマートフォンに組み込まれるICカードであるUSIMに対して本発明を適用した場合の実施の形態である。

まず、図１を参照して、USIM１が組み込まれるスマートフォン２の構成及び機能概要について説明する。スマートフォン２は、無線通信回線（例えば、３Ｇ（3rd Generation）回線又はＷｉ−Ｆｉ（Wireless Fidelity）回線）、及び通信ネットワークを介して他の装置に接続可能になっている。スマートフォン２には、USIM１（小型ＩＣカード）、及びＣＬＦ（Contactless Front End）２８が搭載される。ＣＬＦ２８は、外部の外部端末３（例えば店舗に設置され、例えばクレジット決済時に専用線を介してホストサーバに接続可能になっている。また、外部端末３は、当該外部端末３に接続された読取器（例えば、ＩＣカードリーダライタ）により発せられる電波によりスマートフォン２（より具体的には、USIM１）との間で無線通信（例えばＮＦＣの規格で規定される非接触通信）を行いつつクレジット決済処理を行うことが可能になっている。）に接続された読取器と電波により通信（例えばＮＦＣの規格で規定される非接触通信）するための非接触型ＩＣチップ（例えばＮＦＣモジュール）である。ＣＬＦ２８には、非接触通信のフィールド内で当該通信を行うためのアンテナが接続されている。ＣＬＦ２８は、外部端末３とUSIM１の間の非接触通信を担う。なお、ＣＬＦ２８は、スマートフォン２のＯＳにより操作可能になっている。

スマートフォン２は、制御部２１、記憶部２２、無線通信部２３、表示部２４、入力部２５、及びICカードインターフェース２６等を備えて構成され、これらの構成要素はバス２７を介して相互に接続される。

制御部２１は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、及びＲＡＭ（Random Access Memory）等により構成される。記憶部２２は、例えばフラッシュメモリ等の不揮発性メモリにより構成される。上記ＲＯＭまたは記憶部２２には、オペレーティングシステム（ＯＳ）及びミドルウェアが記憶される。

無線通信部２３は、アンテナを有し、移動体通信網における基地局との間で行われる無線通信を制御する。表示部２４は、例えばタッチパネル方式の表示パネルを有し、表示パネルへの表示制御、及びユーザからの操作指示の受け付けを行う。入力部２５は、ユーザからの操作指示を入力するための操作ボタンを有し、操作ボタンに応じた信号を制御部２１に出力する。ICカードインターフェース２６は、制御部２１とUSIM１との間のインターフェース、及び制御部２１とＣＬＦ２８との間のインターフェースを担う。

次に、図２を参照して、本実施形態に係るUSIM１の構成及び機能概要について説明する。図２は、USIM１の概要構成例を示す図である。

USIM１には、ICチップ１ａが搭載されている。ICチップ１ａは、本発明の電子情報記憶媒体の一例である。ICチップ１ａは、ＣＰＵ１０、ＲＡＭ１１、ＲＯＭ１２、不揮発性メモリ１３、及びＩ／Ｏ回路１４を備えて構成される。なお、Ｉ／Ｏ回路１４は、スマートフォン２のＣＬＦ２８と、ICカードインターフェース２６と接続されている。スマートフォン２の無線通信部２３は、無線通信回線を介してサービス提供事業者のアプリケーション提供サーバにアクセスして、サービスを提供するサービスアプリケーション（「サービスアプリ」という場合がある）をダウンロードする。ダウンロードされたサービスアプリは、ICカードインターフェース２６を介してUSIM１に送信され、インストールされる。また、スマートフォン２の利用者の入力部２５に対する操作に応じたコマンドが制御部２１からICカードインターフェース２６を介して、USIM１に送信される。例えば、利用者がサービスアプリを有効化する場合は、入力部２５に対する操作を行うことにより、スマートフォン２の制御部２１から有効化コマンドが出力され、ICカードインターフェース２６を介してUSIM１に送信され、有効化される。

ＣＰＵ１０は、ＲＯＭ１２又は不揮発性メモリ１３に記憶されたプログラム（本発明の代表アプリケーションを含む）を実行するプロセッサ（コンピュータ）である。ＣＰＵ１０は、記憶されたプログラムに従って後述する処理を実行する。

不揮発性メモリ１３は、例えばフラッシュメモリが適用される。なお、不揮発性メモリ１３は、「Electrically Erasable Programmable Read-Only Memory」であっても構わない。不揮発性メモリ１３には、一のサービス（本実施形態ではクレジット決済サービス）について複数のサービスアプリがインストールされる。不揮発性メモリ１３は、サービスアプリがインストールされると、サービスアプリに関するデータ（アプリケーションプログラム、設定データ等）を記憶する。なお、アプリケーションプログラムは、複数の命令コードにより更新されるソフトウェアモジュールである。命令コードはＣＰＵ（Central Processing Unit）により実行される。

また、不揮発性メモリ１３には、ICチップ１ａ内において図３に示すようなマルチアプリケーションプラットフォームＭＰ（複数のサービスアプリをインストール、実行、削除することが可能なアプリ実行環境の一つ）を構築するために必要なプログラム（「環境プログラム」という場合がある）及びデータを記憶する。マルチアプリケーションプラットフォームＭＰは、JavaCard（登録商標）等の実行機能に加え、GlobalPlatform等のアプリケーション管理機能を有する。本実施形態では、一のサービスに対応する複数のサービスアプリによりグループが形成され、グループには一の代表アプリケーション（「代表アプリ」という場合がある）が含まれる。

マルチアプリケーションプラットフォームＭＰは、インストールされているサービスアプリに関する情報を対応付けるアプリ管理テーブル３００を保持する（アプリ管理テーブル３００は、不揮発性メモリ１３内のマルチアプリケーションプラットフォームＭＰが直接アクセス可能な領域に記憶される）。アプリ管理テーブル３００は、USIM１製造時に作成されるがその時点ではデータが格納されておらず、サービスアプリがインストールされる度に、レコードが追加される。アプリ管理テーブル３００には、インストールされている各サービスアプリについて、サービスアプリのアプリケーション名（実際には、サービスアプリを一意に特定するための識別情報であり、例えば、5〜16バイトのバイト列を用い、Application ID（AID）として表現される）、サービスアプリが属するグループ名（サービスアプリが属するグループを一意に特定する情報であり、例えば、何らかのバイト列として表現される。グループに属さない場合にはそのことを示すデータが格納される）、代表アプリであるか否かの情報（少なくとも2値(true/false)の値を取り得る形式で表現される）、サービスアプリの活性化状態（そのサービスアプリが、外部から選択可能であるかを示し、“有効”であれば、外部から選択し、当該サービスアプリの機能を利用可能である。一方、”無効”の場合、外部から選択できないため、インストールされていても当該サービスアプリの機能を使用することができない。少なくとも2値(true/false)の値を取り得る形式で表現される）が記述される。図３の例では、クレジット決済代表アプリ４００が、クレジット決済サービスグループの代表アプリであり、有効な状態であることが示されている（なお、代表アプリは常に有効である）。また、A社クレジット決済サービスアプリ４０１Ａが、クレジット決済サービスグループに属し、代表アプリではなく、有効な状態であることが示されている。更に、B社クレジット決済サービスアプリ４０１Ｂが、クレジット決済サービスグループに属し、代表アプリではなく、無効な状態であることが示されている。

なお、アプリ管理テーブル３００は、図３に示す情報以外の情報を格納していてもよい。アプリ管理テーブル３００は、不揮発性メモリ１３に格納されるため、電源断に関係なく情報を保持し続ける。アプリ管理テーブル３００は、外部から与えられたコマンドによって、アプリ管理状態の変化を伴うイベントが発生した場合、当該状態の変化を反映するよう、内容が書き換えられる。具体的なコマンドとイベントとしては、例えば以下の（１）−（６）が挙げられる。

（１）インストールコマンド：サービスアプリのインストール（新しいサービスアプリを外部からインストールする）
（２）削除コマンド：サービスアプリの削除（マルチアプリケーションプラットフォームＭＰに格納済みのサービスアプリを削除する）
（３）加入コマンド：インストール済みサービスアプリを、既存グループに加える
（４）脱退コマンド：グループに加わっているサービスアプリを、グループから離脱させ、単独のサービスアプリにする
（５）有効化コマンド：「無効」のサービスアプリを「有効」に設定（サービスアプリを外部から選択可能にする）
（６）無効化コマンド：「有効」のサービスアプリを「無効」に設定（サービスアプリを外部から選択不可能にする）
以下、（１）−（６）のコマンドは状態変更コマンドという。状態変更コマンドに応じて、ＣＰＵ１０は環境プログラムを実行することにより、アプリ管理テーブル３００の内容を書き換える。状態変更コマンドは、例えば、スマートフォン２の利用者による操作に基づいて発行される。

クレジット決済代表アプリ４００はUSIM１のカードベンダー又は通信キャリアによりインストールされる。クレジット決済代表アプリ４００は外部端末３がクレジット決済サービスを利用する際、最初のアクセス対象となる。例えば、クレジット決済代表アプリ４００は外部端末３からアクセスされた際（例えば、外部端末３がクレジット決済サービスに対してSELECTコマンドを実行した際）、現在有効となっているクレジット決済サービスアプリの識別情報（AID）をレスポンスデータとして外部端末３に返送する。これにより、外部端末３は当該サービスを利用するためのアプリ（事業者）を一意に特定することができる。また、クレジット決済代表アプリ４００は、クレジット決済サービスグループ内のサービスアプリ４０１Ａ、４０１Ｂに対する状態変化があった旨の通知をマルチアプリケーションプラットフォームＭＰから受け取ることにより、グループ内の何れか一つのサービスアプリのみを有効化するよう、グループ内のサービスアプリを管理する。クレジット決済代表アプリ４００は、マルチアプリケーションプラットフォームＭＰとは別に、現在有効アプリ格納領域４００ａと、直近有効アプリ格納領域４００ｂを保持する（現在有効アプリ格納領域４００ａと、直近有効アプリ格納領域４００ｂは、不揮発性メモリ１３内の代表アプリが直接アクセス可能な領域に記憶される）。クレジット決済代表アプリ４００は、現在有効なサービスアプリを示す識別情報（AID）を現在有効アプリ格納領域４００ａに格納する。また、クレジット決済代表アプリ４００は、無効であるサービスアプリを新たに有効にする場合には、それまで有効であったサービスアプリを識別する識別情報（AID）を直近情報として直近有効アプリ格納領域４００ｂに格納する。これにより代表アプリは、新たに有効になったサービスアプリの前に有効であったサービスアプリを特定することができる。

ＣＰＵ１０は、本発明における制御手段として機能する。具体的には、ＣＰＵ１０は、代表アプリを実行することにより、当該代表アプリに対応するグループ内の有効なサービスアプリの数を一つに制御する。

次に、図４を参照して、ＣＰＵ１０による状態変更コマンド受信時処理の一例について説明する。図４は、ＣＰＵ１０による状態変更コマンド受信時処理の一例を示すフローチャートである。なお、状態変更コマンド受信時処理は、ＣＰＵ１０が環境プログラムに従って実行する。

まず、ＣＰＵ１０は、Ｉ／Ｏ回路１４を介して、スマートフォン２又は外部端末３から状態変更コマンドを受信すると（ステップＳ１）、当該状態変更コマンドの内容に従って、アプリ管理テーブル３００の内容を書き換える（ステップＳ２）。

具体的には、ＣＰＵ１０は、（１）インストールコマンドを受信した場合には、アプリ管理テーブル３００にインストールするサービスアプリに対応するレコード（アプリケーション名のみ記述されており、グループ名は空欄、代表は「Ｘ」、活性化状態は「無効」とするレコード）を追加する。なお、（１）インストールコマンドを受信した場合には、インストール対象のサービスアプリの実行プログラムと関連データがマルチアプリケーションプラットフォームＭＰ上に配置される。

ＣＰＵ１０は、（２）削除コマンドを受信した場合には、アプリ管理テーブル３００から削除対象のサービスアプリに対応するレコードを削除する。このとき、有効だったサービスアプリが削除された場合、このグループ内で有効なサービスアプリの数が一時的に０になる。なお、（２）削除コマンドを受信した場合には、削除対象のサービスアプリの実行プログラムと関連データがマルチアプリケーションプラットフォームＭＰ上から削除される。

ＣＰＵ１０は、（３）加入コマンドを受信した場合には、アプリ管理テーブル３００における対象のサービスアプリに対応するレコードにおけるグループ名に加入先のグループ名を格納する。なお、サービスアプリが加入コマンドによりグループに加入した際、当初の活性化状態は無効とする。

ＣＰＵ１０は、（４）脱退コマンドを受信した場合には、アプリ管理テーブル３００における対象のサービスアプリに対応するレコードにおけるグループ名を空欄にする。このとき、有効だったサービスアプリが脱退した場合、このグループ内で有効なサービスアプリの数が一時的に０になる。

ＣＰＵ１０は、（５）有効化コマンドを受信した場合には、アプリ管理テーブル３００における対象のサービスアプリに対応するレコードにおける活性化状態を「有効」に変更する。このとき、すでに有効だったサービスアプリが存在する場合、このグループ内で有効なサービスアプリの数が一時的に２つになる。

ＣＰＵ１０は、（６）無効化コマンドを受信した場合には、アプリ管理テーブル３００における対象のサービスアプリに対応するレコードにおける活性化状態を「無効」に変更する。このとき、有効だったサービスアプリが「無効」になった場合、このグループ内で有効なサービスアプリの数が一時的に０になる。

次に、ＣＰＵ１０は、状態変更したサービスアプリがグループに属するか否かを判定する（ステップＳ３）。具体的には、アプリ管理テーブル３００を参照し、ステップＳ２の処理で内容を書き換えたサービスアプリのグループ名に基づいて判定する。このとき、ＣＰＵ１０は、状態変更したサービスアプリがグループに属さないと判定した場合には（ステップＳ３：ＮＯ）、当該フローチャートに示す処理を終了する。一方、ＣＰＵ１０は、状態変更したサービスアプリがグループに属すると判定した場合には（ステップＳ３：ＹＥＳ）、アプリ管理テーブル３００を参照し、状態変更したサービスアプリが属するグループの代表アプリを特定する（ステップＳ４）。

次に、ＣＰＵ１０は、ステップＳ４の処理で特定した代表アプリに状態変更があった旨（状態変更の内容を含む）を通知し（ステップＳ５）、当該フローチャートに示す処理を終了する。

次に、図５を参照して、ＣＰＵ１０による有効アプリ制御処理の一例について説明する。図５は、ＣＰＵ１０による有効アプリ制御処理の一例を示すフローチャートである。なお、有効アプリ制御処理は、図４のステップＳ５の処理によりマルチアプリケーションプラットフォームＭＰから代表アプリに状態変更があった旨の通知を受けたことを契機に、ＣＰＵ１０が代表アプリに従って実行する。

まず、ＣＰＵ１０は、マルチアプリケーションプラットフォームＭＰからグループ内のサービスアプリに状態変更があった旨の通知を受信すると（ステップＳ３１）、アプリ管理テーブル３００内において活性化状態が「有効」であるサービスアプリの数が「１」であるか否かを判定する（ステップＳ３２）。具体的には、ＣＰＵ１０は、現在有効アプリ格納領域４００ａにAIDが格納されているか否かと、ステップＳ３１の処理で受信した通知の内容に基づいて、活性化状態が「有効」であるサービスアプリの数を特定する。例えば、現在有効アプリ格納領域４００ａについては、AIDが格納されていれば一のサービスアプリの活性化状態が「有効」であると特定できる。一方、通知の内容が、（１）インストールコマンド又は（３）加入コマンドに基づいてアプリ管理テーブル３００の書き換えを行ったことを示す場合には、新たに有効になったアプリは「０」であることを特定できる。通知の内容が、（２）削除コマンド、（４）脱退コマンド又は（６）無効化コマンドに基づいてアプリ管理テーブル３００の書き換えを行ったことを示す場合には、新たに無効になったアプリは「１」であることを特定できる。通知の内容が、（５）有効化コマンドに基づいてアプリ管理テーブル３００の書き換えを行ったことを示す場合には、新たに有効になったアプリは「１」であることを特定できる。すなわち、例えば、現在有効アプリ格納領域４００ａにAIDが格納されており、且つ、通知の内容が（１）インストールコマンドに基づく書き換えを行ったことを示す場合には、活性化状態が「有効」であるサービスアプリの数は「１＋０＝１」と判定する。また、現在有効アプリ格納領域４００ａにAIDが格納されており、且つ、通知の内容が（２）削除コマンドに基づく書き換えを行ったことを示す場合には、活性化状態が「有効」であるサービスアプリの数は「１−１＝０」と判定する。更に、現在有効アプリ格納領域４００ａにAIDが格納されており、且つ、通知の内容が（５）有効化コマンドに基づく書き換えを行ったことを示す場合には、活性化状態が「有効」であるサービスアプリの数は「１＋１＝２」と判定する。更にまた、現在有効アプリ格納領域４００ａにAIDが格納されておらず、且つ、通知の内容が（１）インストールコマンドに基づく書き換えを行ったことを示す場合には、活性化状態が「有効」であるサービスアプリの数は「０＋０＝０」と判定する。

ＣＰＵ１０は、活性化状態が「有効」であるサービスアプリの数が「１」であると判定した場合には（ステップＳ３２：ＹＥＳ）、当該フローチャートに示す処理を終了する。一方、ＣＰＵ１０は、活性化状態が「有効」であるサービスアプリの数が「１」ではないと判定した場合には（ステップＳ３２：ＮＯ）、次いで、アプリ管理テーブル３００内において活性化状態が「有効」であるサービスアプリの数が「２」であるか否かを判定する（ステップＳ３３）。

ＣＰＵ１０は、活性化状態が「有効」であるサービスアプリの数が「２」であると判定した場合には（ステップＳ３３：ＹＥＳ）、現在有効アプリ格納領域４００ａに格納されているAIDを直近有効アプリ格納領域４００ｂに格納し（ステップＳ３４）、新たに有効になったサービスアプリのAIDを現在有効アプリ格納領域４００ａに格納する（ステップＳ３５）。

次に、ＣＰＵ１０は、直近有効アプリ格納領域４００ｂに格納されているAIDで識別されるサービスアプリについて活性化状態を「無効」にさせ（ステップＳ３６）、当該フローチャートに示す処理を終了する。具体的には、ＣＰＵ１０は、マルチアプリケーションプラットフォームＭＰに対して、直近有効アプリ格納領域４００ｂに格納されているAIDで識別されるサービスアプリについて、活性化状態を「無効」にするようにアプリ管理テーブル３００を書き換えることを指示する。これにより、グループ内の「有効」なサービスアプリの数は「２」から「１」に制御される。

一方、ＣＰＵ１０は、活性化状態が「有効」であるサービスアプリの数が「２」ではないと判定した場合には（ステップＳ３３：ＮＯ）、次いで、アプリ管理テーブル３００内において活性化状態が「有効」であるサービスアプリの数が「０」であるか否かを判定する（ステップＳ３７）。

ＣＰＵ１０は、活性化状態が「有効」であるサービスアプリの数が「２」ではないと判定した場合には（ステップＳ３７：ＮＯ）、当該フローチャートに示す処理を終了する。一方、ＣＰＵ１０は、活性化状態が「有効」であるサービスアプリの数が「０」であると判定した場合には（ステップＳ３７：ＹＥＳ）、次いで、直近有効アプリ格納領域４００ｂにAIDが格納されているか否かを判定する（ステップＳ３８）。

ＣＰＵ１０は、直近有効アプリ格納領域４００ｂにAIDが格納されていないと判定した場合には（ステップＳ３８：ＮＯ）、当該フローチャートに示す処理を終了する。一方、ＣＰＵ１０は、直近有効アプリ格納領域４００ｂにAIDが格納されていると判定した場合には（ステップＳ３８：ＹＥＳ）、直近有効アプリ格納領域４００ｂに格納されているAIDで識別されるサービスアプリがアプリ管理テーブル３００に存在するか否かを判定する（ステップＳ３９）。具体的には、ＣＰＵ１０は、マルチアプリケーションプラットフォームＭＰに対して、直近有効アプリ格納領域４００ｂに格納されているAIDを送信し、アプリ管理テーブル３００に等がAIDで識別されるサービスアプリが存在するか否かを問い合わせ、その結果に基づいて、ステップＳ３９の判定を行う。

ＣＰＵ１０は、直近有効アプリ格納領域４００ｂに格納されているAIDで識別されるサービスアプリがアプリ管理テーブル３００に存在しないと判定した場合には（ステップＳ３９：ＮＯ）、当該フローチャートに示す処理を終了する。一方、ＣＰＵ１０は、直近有効アプリ格納領域４００ｂに格納されているAIDで識別されるサービスアプリがアプリ管理テーブル３００に存在すると判定した場合には（ステップＳ３９：ＹＥＳ）、直近有効アプリ格納領域４００ｂに格納されているAIDで識別されるサービスアプリについて活性化状態を「有効」にさせる。具体的には、ＣＰＵ１０は、マルチアプリケーションプラットフォームＭＰに対して、直近有効アプリ格納領域４００ｂに格納されているAIDで識別されるサービスアプリについて、活性化状態を「有効」にするようにアプリ管理テーブル３００を書き換えることを指示する。これにより、グループ内の「有効」なサービスアプリの数は「０」から「１」に制御される。

次いで、ＣＰＵ１０は、直近有効アプリ格納領域４００ｂに格納されているAIDを現在有効アプリ格納領域４００ａに格納し、直近有効アプリ格納領域４００ｂをクリアし（ステップＳ４１）、当該フローチャートに示す処理を終了する。

ステップＳ３８の処理、ステップＳ３９の処理で「ＮＯ」判定となった場合、一時的にグループ内の有効なサービスアプリが「０」となるが、グループ内で新たにサービスアプリが有効になるまでこれを許容する。

以上説明したように、本実施形態のUSIM１（「電子情報記憶媒体」の一例）は、不揮発性メモリ１３（「メモリ」の一例）が、クレジット決済サービス（「サービス」の一例）に対応するグループ毎に複数のクレジット決済サービスアプリ４０１Ａ、４０１Ｂ（「サービスアプリケーションプログラム（サービスアプリ）」の一例）と一のクレジット決済代表アプリ４００（「代表アプリケーションプログラム（代表アプリ）」の一例）を対応付けて記憶し、ＣＰＵ１０（「プロセッサ」の一例）が、クレジット決済代表アプリ４００を実行することにより、クレジット決済代表アプリ４００に対応するクレジット決済サービスグループ内の有効なクレジット決済サービスアプリの数を一つに制御する。

したがって、本実施形態のUSIM１によれば、クレジット決済サービスに対応するクレジット決済サービスグループ内の有効なクレジット決済サービスアプリの数が一つに制御されることから、利用者がクレジット決済サービス利用時において使用するクレジット決済サービスアプリを選択しなくて済む。

また、ＣＰＵ１０は、外部端末３からクレジット決済代表アプリ４００に対するコマンドを受信した場合に、クレジット決済代表アプリ４００を実行することにより、クレジット決済代表アプリ４００に対応するクレジット決済サービスグループについて有効となっている一つのクレジット決済サービスアプリを識別するAID（「有効アプリケーション識別情報」の一例）を外部端末３に送信する。これにより、外部端末３はクレジット決済サービス提供時に一の有効なクレジット決済サービスアプリを把握して当該有効なクレジット決済サービスアプリに対応するコマンドを送信することができる。

更に、ＣＰＵ１０は、クレジット決済代表アプリ４００を実行することにより、クレジット決済サービスグループ内で新たにクレジット決済サービスアプリを有効にする場合に、それまで有効であったクレジット決済サービスアプリを無効にする。これにより、クレジット決済サービスグループ内で有効なクレジット決済サービスアプリの数を二つにすることなく一つに制御することができる。

更にまた、ＣＰＵ１０は、クレジット決済代表アプリ４００を実行することにより、クレジット決済サービスアプリを無効にする場合には、当該クレジット決済サービスアプリのAIDを直近有効アプリ格納領域４００ｂに格納することにより、当該クレジット決済サービスアプリを直近に有効であったクレジット決済サービスアプリとして不揮発性メモリ１３に記憶させ、現在有効なクレジット決済サービスアプリを削除又は無効とする場合に、直近有効アプリ格納領域に格納されているAIDで識別されるクレジット決済サービスアプリを有効にする。これにより、クレジット決済サービスグループ内で有効なクレジット決済サービスアプリの数を０にすることなく一つに制御することができる。

なお、本実施形態はUSIM１が提供するサービスがクレジット決済サービスである場合について説明したが、その他のサービス（例えば、電子マネーサービス、交通サービス、医療サービス、認証サービス等）についても適用することができる。

１ USIM
１ａ ICチップ
１０ＣＰＵ
１１ＲＡＭ
１２ＲＯＭ
１３不揮発性メモリ
１４Ｉ／Ｏ回路
２スマートフォン
２１制御部
２２記憶部
２３無線通信部
２４表示部
２５入力部
２６ ICカードインターフェース
２７バス
２８ＣＬＦ
３外部端末

Claims

サービスに対応するグループ毎に複数のサービスアプリケーションプログラムと一の代表アプリケーションを対応付けて記憶するメモリと、
前記代表アプリケーションを実行することにより、当該代表アプリケーションに対応する前記グループ内の有効なサービスアプリケーションの数を一つに制御するプロセッサと、
を備えることを特徴とする電子情報記憶媒体。
請求項１に記載の電子情報記憶媒体であって、
前記プロセッサは、外部装置から代表アプリケーションに対するコマンドを受信した場合に、前記代表アプリケーションを実行することにより、当該代表アプリケーションに対応するグループについて有効となっている一つのサービスアプリケーションを識別する有効アプリケーション識別情報を前記外部装置に送信することを特徴とする電子情報記憶媒体。
請求項１又は２に記載の電子情報記憶媒体であって、
前記プロセッサは、前記代表アプリケーションを実行することにより、前記グループ内で新たにサービスアプリケーションを有効にする場合に、それまで有効であったサービスアプリケーションを無効にする、ことを特徴とする電子情報記憶媒体。
請求項３に記載の電子情報記憶媒体であって、
前記プロセッサは、前記代表アプリケーションを実行することにより、サービスアプリケーションを無効にする場合には、当該サービスアプリケーションを直近に有効であった直近有効サービスアプリケーションとして前記メモリに記憶させ、現在有効なサービスアプリケーションを削除又は無効とする場合に、当該直近有効サービスアプリケーションを有効にする、ことを特徴とする電子情報記憶媒体。
サービスに対応するグループ毎に複数のサービスアプリケーションと一の代表アプリケーションを対応付けて記憶するメモリと、プロセッサを備える電子情報記憶媒体による情報処理方法であって、
前記プロセッサが、前記代表アプリケーションを実行することにより、当該代表アプリケーションに対応する前記グループ内の有効なサービスアプリケーションの数を一つに制御する制御工程、
を含むことを特徴とする情報処理方法。
サービスに対応するグループ毎に複数のサービスアプリケーションと一の代表アプリケーションを対応付けて記憶するメモリと、プロセッサを備える電子情報記憶媒体における前記プロセッサを、
前記代表アプリケーションに対応する前記グループ内の有効なサービスアプリケーションの数を一つに制御する制御手段、
として機能させる代表アプリケーション。