JP2016092452A - 発行データ配信サーバー、発行データ配信方法及び発行データ配信システム - Google Patents

Abstract

【課題】キャリアを変更する際に、携帯端末のＳＩＭに対するアプリケーションの再発行を利用者に不便を生じさせずに安全に行うサービスアプリケーション発行装置を提供する。【解決手段】本発明は、利用者が選択したサービスアプリケションを活性化する発行データを携帯端末に配信するものあり、携帯端末のキャリアが変更された際、携帯端末に発行されサービスアプリケーションの発行データが記憶されたサービスアプリケーション発行テーブルに対し、変更後のキャリアに対応したサービスアプリケーションのレコードを生成し、キャリアの変更後においてサービスアプリケーションが活性化された後、サービスアプリケーション発行テーブルに変更前のキャリアのサービスアプリケーションのレコードの発行データを削除し、新たなキャリアのサービスアプリケーションのレコードの発行データを使用可とする。【選択図】図１

Description

本発明は、発行データ配信サーバー、発行データ配信方法及び発行データ配信システムに関する。

近年、携帯電話やスマートフォン等の携帯端末に対してサーバからのデータの送受信を行い、サーバから携帯端末へのコンテンツなどのデータを配信するサービスが行われている（例えば、特許文献１参照）。
この携帯端末の利用の発展した形態である、非接触ＩＣ（Integrated Circuit、集積回路）カードインターフェースの規格として国際標準化機構（ISO：International Organization Standardization）で規定されたＮＦＣ（Near Field Communication）対応の携帯端末がある。このＮＦＣ対応の携帯端末の普及により、携帯端末を用いた決済手法として、非接触ＩＣ決済サービスを用いたクレジットの利用が増加している（例えば、特許文献１参照）。すなわち、このＮＦＣを用いることにより、クレジットのＩＣカードと同様に、決済サービスのシステムにおけるＲ／Ｗ（Reader/Writer）機器とのデータの送受信が携帯端末でも行える。

上述したように、携帯端末を近距離無線通信機能を有するＩＣカードと同様に決済サービスに適用させる場合、決済サービスアプリケーションをインストールする。そして、インストールしたサービスアプリケーションにより、携帯端末がクレジットカードなどのＩＣカードの決済機能を有する。
また、今後は、クレジットカードのみではなく、プリペイドカード、ポイントカードあるいは社員証ＩＤ（Identification）カードなどのＩＣカードにおいて、これらのエミュレートするサービスアプリケーションのインストールを、ＮＦＣ対応のスマートフォンなどの携帯端末に対して行うことが予想される。

また、上述したＮＦＣの規定を用いたサービスの特徴は、ＯＴＡ（Over The Air）と呼ばれる無線通信を用いた情報処理技術が利用されている。ＯＴＡでは、例えば、無線通信を利用して、携帯電話などの移動体通信端末に対する電話番号や識別情報の書き込みや消去、ファームウェア更新やコンテンツの自動配信、コンテンツのダウンロード販売などが行われる。
従来、ＩＣ（Integrated Circuit）カード発行機を用いて行われていたＩＣカード発行処理を、ＯＴＡで行うためのシステムが開発されてきている。なお、ＩＣカードの発行処理とは、ＩＣカードのホルダがＩＣカードを利用可能とするための処理であり、次のような０次から２次までの発行処理を含む。

すなわち、０次発行では携帯端末の接触型ＩＣカードへの一意の識別子の書き込み処理等が行われ、接触型ＩＣカードが個別化される。１次発行では、接触型ＩＣカードへのアプリケーションのインストール、初期設定等が行われ、ＵＩＣＣがイニシャライズされる。そして、２次発行では、接触型ＩＣカードのホルダの個人用の設定を行ったり、個人用の情報を書き込んだりするパーソナライズが行われる。

携帯電話やスマートフォン（携帯端末）においては、一般的に上記接触型ＩＣカードとしてＵＩＣＣ（Universal Integrated Circuit Card）が用いられ、例えばＵＩＣＣの一種であるＳＩＭ（Subscriber Identity Module）カードに対して、上述したアプリケーションが書き込まれる。
また、ナンバーポータビリティやＳＩＭロック解除した携帯端末を用いる機会が増加しており、ユーザが簡易にキャリアを変更することができる環境となっている。

特開２００４−１９３７２２号公報

しかしながら、アプリケーションをＳＩＭにインストールした後、携帯電話のキャリアを異なる他のキャリアに変更する場合、新たなキャリアのＳＩＭに変更するためのＳＩＭロック解除が行われる。
この結果、キャリア変更に伴ったＳＩＭの差し替えが行われるため、旧環境のＳＩＭにインストールされたアプリケーションの個人用の情報を、新ＳＩＭに対して移行する必要がある。

ＳＩＭを発行したキャリアが異なるため、ユーザはＳＩＭ内のアプリケーションの個人用のデータを削除した上で、新たなキャリアでアプリケーションを利用するため、再度、クレジットカード会社などのサービス会社に申し込み手続きから開始する必要がある。この場合、アプリケーションの個人用のデータの移行において、クレジットなどのアプリケーションに関しては、カード会社に対して申請書を送るなど、処理がオフラインで行われるために非常に効率が悪い。

上述したように、カード会社に対してアプリケーションの再発行を申請すると、新たなＳＩＭに対するクレジットのアプリケーションのインストール処理を行う再発行処理が行われる。
このとき、新たなキャリアのＳＩＭに対して、アプリケーションの再発行が行われるまでの手続に必要な時間を要し、クレジットカードなどのアプリケーションの場合、引き落としなどの決済ができない期間が生じる。
したがって、キャリアを変更した際におけるＩＣカードのアプリケーションの再発行の終了するまでの期間、ＩＣカードの機能が使用できなくなる。このため、ユーザが不便を強いられることになる。

また、ユーザがＳＩＭの旧環境（キャリア変更前の環境）におけるアプリケーションの個人用のデータを削除し忘れるなどの危険な状態に陥ることも想定される。
変更前のＳＩＭに対してインストールされたアプリケーションを削除せずに、かつ、ＩＣカードに関する発行データの管理を行うＳＰ（Service Provider）−ＴＳＭ（Trusted Service Manager）サーバーに対し、削除依頼を行うのを失念した場合、ＳＩＭが他人に入手されてしまうと、ＳＩＭには個人用のデータが残っているため、ＩＣカードを悪用される危険がある。

本発明は、このような事情に鑑みてなされたもので、キャリアを変更する際に、新たなキャリアのＳＩＭに対するサービスアプリケーションの再発行の際、ＩＣカードの機能が使用できなくなる期間を無くし、かつ利用者が変更前のＳＩＭのアプリケーションの個人用のデータを削除し忘れても悪用されるような危険な状態となることを防止し、携帯端末のＳＩＭに対するアプリケーションの再発行を利用者に不便を生じさせずに安全に行うことができる発行データ配信サーバー、発行データ配信方法及び発行データ配信システムを提供することを目的とする。

この発明は上述した課題を解決するためになされたもので、本発明の発行データ配信サーバーは、利用者の選択したＩＣカードの動作するサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケションを活性化する発行データを前記携帯端末に配信する発行データ配信サーバーであって、前記携帯端末のキャリアが変更された際、当該携帯端末に対して発行した前記サービスアプリケーションの発行データが記憶されたサービスアプリケーション発行テーブルに対し、変更後のキャリアに対応したサービスアプリケーションのレコードを生成し、前記携帯端末においてキャリアの変更後において前記サービスアプリケーションが活性化された後、前記サービスアプリケーション発行テーブルに変更前のキャリアに対応したサービスアプリケーションのレコードの発行データを削除し、新たなキャリアに対応したサービスアプリケーションのレコードの発行データを使用可とすることを特徴とする。

本発明の発行データ配信サーバーは、サービスアプリケーションが活性化された後、前記携帯端末から発行データのステータスの更新依頼が供給された際、前記サービスアプリケーション発行テーブルにおいて、変更前のキャリアに対応したサービスアプリケーションのレコードの発行データを削除し、新たなキャリアに対応したサービスアプリケーションのレコードの発行データを使用可とすることを特徴とする。

本発明の発行データ配信サーバーは、予め設定された期間の間、新たなキャリアに対応したサービスアプリケーションの活性化の依頼が前記携帯端末から供給されない場合、前記サービスアプリケーション発行テーブルにおける変更後のキャリアに対応したサービスアプリケーションの発行データの前記レコードを削除することを特徴とする。

本発明の発行データ配信方法は、利用者の選択したＩＣカードの動作するサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケションを活性化する発行データを前記携帯端末に配信する発行データ配信サーバーにおける発行データ配信方法であって、前記携帯端末のキャリアが変更された際、当該携帯端末に対して発行した前記サービスアプリケーションの発行データが記憶されたサービスアプリケーション発行テーブルに対し、変更後のキャリアに対応したサービスアプリケーションのレコードを生成する過程と、前記携帯端末においてキャリアの変更後において前記サービスアプリケーションが活性化された後、前記サービスアプリケーション発行テーブルに変更前のキャリアに対応したサービスアプリケーションのレコードの発行データを削除し、新たなキャリアに対応したサービスアプリケーションのレコードの発行データを使用可とする過程とを含むことを特徴とする。

本発明の発行データ配信システムは、利用者が携帯する携帯端末と、前記利用者の選択したＩＣカードの動作するサービスアプリケーションを前記携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケションを活性化する発行データを前記携帯端末に配信する発行データ配信サーバーとを有する発行データ配信システムであり、前記携帯端末が、前記発行データ配信サーバーに対してキャリア変更に伴う、前記ＩＣカードのサービスアプリケーションの再発行を依頼し、前記発行データ配信サーバーが、前記携帯端末からの再発行の依頼に対応し、当該携帯端末に対して発行した前記サービスアプリケーションの発行データが記憶されたサービスアプリケーション発行テーブルに対し、変更後のキャリアに対応したサービスアプリケーションのレコードを生成し、前記携帯端末においてキャリアの変更後において前記サービスアプリケーションが活性化された後、前記サービスアプリケーション発行テーブルに変更前のキャリアに対応したサービスアプリケーションのレコードの発行データを削除し、新たなキャリアに対応したサービスアプリケーションのレコードの発行データを使用可とすることを特徴とする。

本発明によれば、キャリアを変更する際に、新たなキャリアのＳＩＭに対するサービスアプリケーションの再発行の際にＩＣカードの機能が使用できなくなる期間を無くし、かつ利用者が変更前のＳＩＭのアプリケーションの個人用のデータを削除し忘れても悪用されるような危険な状態となることを防止し、携帯端末のＳＩＭに対するアプリケーションの再発行を利用者に不便を生じさせずに安全に行うことができるサービスアプリケーション発行装置、サービスアプリケーション発行方法及びサービスアプリケーション発行システムを提供することが可能となる。

本発明の一実施形態によるサービスアプリケーション発行システムの構成例を示す概略ブロック図である。 利用者データベース２１に記憶されている利用者を管理するサービスアプリケーション発行テーブルの構成例を示す図である。 本実施形態におけるサービスアプリケーションのカード発行でのサービスアプリケーション発行システムの動作例を示すシーケンス図である。 本実施形態でのキャリア変更の際に行われる、ＩＣカードのサービスアプリケーションの再発行におけるサービスアプリケーション発行システムの動作例を示すシーケンス図である。 本実施形態でのキャリア変更の際に行われる、ＩＣカードのサービスアプリケーションの再発行におけるサービスアプリケーション発行システムの動作例を示すシーケンス図である。 本実施形態でのキャリア変更の際に行われる、ＩＣカードのサービスアプリケーションの再発行におけるサービスアプリケーション発行システムの動作例を示すシーケンス図である。 本実施形態でのキャリア変更の際に行われる、ＩＣカードのサービスアプリケーションの再発行におけるサービスアプリケーション発行システムの動作例を示すシーケンス図である。

以下、図面を参照して、本発明の実施形態について説明する。図１は、本発明の一実施形態によるサービスアプリケーション発行システムの構成例を示す概略ブロック図である。この図１において、サービスアプリケーション発行システムは、ＳＰ−ＴＳＭサーバー２、配信サービスサーバー３、ＭＮＯ−ＴＳＭサーバー４＿１、ＭＮＯ−ＴＳＭサーバー４＿２、携帯端末５及び利用者データベース２１を備えている。本実施形態において、ＳＰ−ＴＳＭサーバー２は発行データ配信サーバーの一例であり、ここでは２つ設けられている。これらＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２は、アプリケーション発行サーバー（サービスアプリケーション配信サーバー）の一例である。ここで、ＳＰ−ＴＳＭサーバー２及び利用者データベース２１と、ＭＮＯ−ＴＳＭサーバー４＿１あるいはＭＮＯ−ＴＳＭサーバー４＿２のいずれかとを、それぞれの機能を有するアプリケーション発行装置として一体に構成することも可能である。ここで、ＭＮＯ−ＴＳＭサーバー４＿１はキャリアのＸ社で用いられているサーバーであり、ＭＮＯ−ＴＳＭサーバー４＿２はキャリアのＹ社で用いられているサーバーである。

ＳＰ−ＴＳＭサーバー２は、サービスアプリケーションを活性化させる発行データのダミーであるダミーデータを、携帯端末５に送信し、ＵＩＣＣ５２にインストールされたサービスアプリケーションに対して発行データ（後述）が発行する（パーソナライズ）。この発行データは、各ＩＣカードのサービスを提供するサービスプロバイダにより発行される。また、ＳＰ−ＴＳＭサーバー２は、後述する利用者データベース２１を有し、利用者の認証及び利用者に対する発行データの管理を行っている。発行データは、携帯端末５のＵＩＣＣ５２にインストールされた所定のサービスアプリケーションを、所有者に対応して使用可能とするパーソナライズ（活性化）を行うためのデータである。発行データのデータの種類については後述する。

ここで、発行データは、携帯端末５のＵＩＣＣ５２にインストールされているサービスアプリケーションを識別する識別情報を含んでいる。このサービスアプリケーションの識別情報は、例えば発行データの一部である会員番号を用いたり、あるいはアクセスコード、パスワードなどのユーザのサービスアプリケーションを識別できるものであればいずれの情報を用いても良い。
また、ＳＰ−ＴＳＭサーバー２は、発行データによりＵＩＣＣ５２におけるサービスアプリケーションを活性させる。

ＳＰ−ＴＳＭサーバー２には、利用者データベース２１が接続されている。
利用者データベース２１には、アクセスコード及びパスワードと発行ステータスとが対応して記憶されたサービスアプリケーション発行テーブル（後述）が書き込まれて記憶されている。この発行ステータスは、サービスアプリケーションの発行状態を示すステータスであり、サービスアプリケーションが発行されていないことを示す未発行と、キャリアが変更中であることを示す発行中と、サービスアプリケーションの発行が完了したことを示す（ＩＣカードの機能が使用可となったことを示す）発行済との３つのステータスがある。

利用者からサービスアプリケーションの発行の申請がなされた際、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルに対し、この利用者のアクセスコード、パスワード、ＳＰ（サービスプロバイダ）コード、サービスコード及び発行ステータスを有するレコードを生成する。また、このレコードには、携帯端末５にインストールされたサービスアプリケーションに対応した発行データも含まれている。このとき、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルにおける新たに作成したレコードの発行ステータスを未発行とする。

また、利用者が携帯端末のキャリアをＸ社からＹ社に変更することにより、Ｙ社のＭＮＯ−ＴＳＭサーバー４＿２が新たなキャリアのサーバーとなり、旧環境のＵＩＣＣ５２も新たなキャリアのＵＩＣＣ５２に交換される。このため、利用者は新しいキャリアに対応したＵＩＣＣ５２に対して、変更前のキャリアのＵＩＣＣ５２にインストールされているＩＣカードのアプリケーションを移行させる必要がある。このとき、ＩＣカードの会員番号であるＰＡＮ（Primary Account Number）は、新旧で同一である必要があるため、そのままの番号で移行される。

ＳＰ−ＴＳＭサーバー２は、キャリア変更の際に、携帯端末５（利用者）から再発行データの作成依頼が供給されると、利用者データベース２１のサービスアプリケーション発行テーブルに対し、新たなレコードを作成する。ここで、ＳＰ−ＴＳＭサーバー２は、作成依頼に対して、現在のＵＩＣＣ５２の識別情報ＩＣＣＩＤとＩＣカードの会員番号であるＰＡＮ（Primary Account Number）とをユーザ識別子として付加する。
ＳＰ−ＴＳＭサーバー２は、サービスアプリケーション発行テーブルから、上記ユーザ識別子をキーとして、サービスアプリケーションの再発行を依頼した利用者の発行データを抽出する。また、ＳＰ−ＴＳＭサーバー２は、抽出した発行データ、再発行用アクセスコード、パスワードに基づいて、サービスアプリケーション発行テーブルに対して、新たな発行データに対応したレコードを生成する。

ＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２の各々は、ＩＣカードのサービスを提供する会社のサービスプロバイダ（事業者）が契約したキャリアの保有するサーバーであり、携帯端末５のＵＩＣＣ５２にインストールされるサービスアプリケーションを、配信要求を行った携帯端末５に対して供給（配信）する。ＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２の各々は、それぞれ各ＩＣカードのサービスプロバイダから提供されたサービスアプリケーションと、このサービスアプリケーションを識別するサービス識別情報との対応するアプリケーションテーブルを、図示しないデータベースに書き込んで記憶させている。

図２は、利用者データベース２１に記憶されている利用者に関する情報を管理するサービスアプリケーション発行テーブルの構成例を示す図である。
サービスアプリケーション発行テーブルは、ＩＣＣＩＤ（ＵＩＣＣの識別情報）、アクセスコード、パスワード、ＳＰ（サービスプロバイダ）コード、サービスコード、キャリアコード、会員番号（カード会員番号であるＰＡＮ）、利用者の名前、有効期限及び発行ステータスなどを含むレコードとして構成されている。ＳＰコードはサービスプロバイダを識別する情報である。サービスコードは、サービスアプリケーション識別情報として用いられる。例えば決済ブランド毎に設定されている。キャリアコードは、キャリアを識別するキャリア識別情報として用いられる。

アクセスコードは、パスワードとともにサービスアプリケーションの発行を申請した際に利用者に供給される、サービスアプリケーションの発行に用いるデータである。このアクセスコードは、利用者を識別する利用者識別情報である。発行データは、本実施形態においては、ＩＣカードの会員番号と、会員の名前と、有効期限を含む構成として設定されている。発行ステータスは、サービスアプリケーションの発行状態（未発行、発行中、発行済）を示している。

また、未発行は、レコードが生成された時点のステータスである。発行中は、再発行の発行データを携帯端末５に送信した時点であり、ＩＣカードが発行の途中にあることを示すステータスである。発行済は、ＩＣカードカードが決済できる状態にあることを示す。上記発行ステータスが未発行及び発行中の場合には、そのレコードに対応したＩＣカードによる決済はできない。会員番号は、ＰＡＮであり、ＩＣカードのサービスに対応したサービスアプリケーションに与えられる利用者個々の決済ブランド毎における識別番号である。有効期限は発行されたＩＣカードの使用可能な期間を示し、名前はＩＣカードの使用を申請した利用者の名前である。

図１に戻り、ＳＰ−ＴＳＭサーバー２は、利用者の認証処理を行う際、利用者データベース２１に記憶されているサービスアプリケーション発行テーブルを参照し、携帯端末５（ＵＩアプリケーション）から供給されるアクセスコード及びパスワードの各々が登録されているか否かの判定を行う。これにより、ＳＰ−ＴＳＭサーバー２は、アクセスコード及びパスワードがサービスアプリケーション発行テーブルに書き込まれている場合、正常に認証されたとして、正しく認証されたことを示す認証情報を携帯端末５に対して送信する。認証情報には、例えば、サービスアプリケーションを識別するサービスアプリケーション識別情報と、ＳＰ−ＴＳＭサーバー２のＵＲＬなどが含まれている。

そして、ＳＰ−ＴＳＭサーバー２は、サービスアプリケーションに対応する発行データの発行により、携帯端末５におけるサービスアプリケーションのパーソナライズが正常に行われたと判定し、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、対応するレコードの発行ステータスを未発行から発行済に変更する。本実施形態において、ＳＰ−ＴＳＭサーバー２は、新規発行の際において、携帯端末５からパーソナライズ完了通知が送信された場合にサービスアプリケーションの発行が正常に行われたと判定する。

また、ＳＰ−ＴＳＭサーバー２は、キャリアが変更された際の発行データの再発行の場合も、新たなキャリアに対応してサービスアプリケーション発行テーブルにおいて新たなレコードを生成した時点において、このレコードにおける発行ステータスを未発行とする。
一方、ＳＰ−ＴＳＭサーバー２は、再発行の発行データを携帯端末５に送信した時点で、サービスアプリケーション発行テーブルにおいて、再発行のために生成した新たなレコードを発行ステータスを発行中とする。
そして、ＳＰ−ＴＳＭサーバー２は、再発行された発行データにより、新たなＵＩＣＣ５２が活性化されたことを示す携帯端末５からのステータス更新依頼が供給されると、旧いキャリアに対応するＩＣカードのレコードを削除し、新たなキャリアに対応するＩＣカードのレコードの発行ステータスを発行済みに変更する。

配信サービスサーバー３は、配信要求を行った携帯端末５に対して、ＵＩアプリケーションの配信を行う。配信サービスサーバー３は、携帯端末向けにデジタルコンテンツ（アプリケーション・映画・音楽・書籍など）の配信サービスを行うサーバーであり、例えばＧｏｏｇｌｅＰｌａｙ（登録商標）などのサイトに設けられたサーバーである。ここで、ＵＩアプリケーションとは、サービスインターフェースを携帯端末５に対してインストールするためのインストーラーであり、ＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２の各々に対してサービスアプリケーションの配信と、ＳＰ−ＴＳＭサーバー２に対して、このサービスアプリケーションを活性化（パーソナライズ）する発行データの配信要求とを行うためのアプリケーションである。

ＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２の各々は、すでに述べたように、利用者が契約した携帯端末５の通信会社（キャリア）が管理するサーバーである。本実施形態においては、ＭＮＯ−ＴＳＭサーバー４＿１は通信会社のＸ社のサーバーであり、ＭＮＯ−ＴＳＭサーバー４＿２は通信会社のＹ社のサーバーである。ＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２の各々は、例えば携帯端末５に搭載されているＮＦＣ対応のＵＩＣＣ５２における記憶部の領域管理を行っている。また、ＭＮＯ−ＴＳＭサーバー４ＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２の各々は、サービスアプリケーション識別情報と、このサービスアプリケーション識別情報が識別するサービスアプリケーションとが予め書き込まれたアプリケーションテーブルを有している。また、ＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２の各々は、図２に示すサービスアプリケーション発行テーブルを有している。

そして、ＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２の各々は、サービスアプリケーションのイニシャライズの処理として、携帯端末５からＵＩＣＣ５２に対するイニシャライズが要求されると、ＳＰ−ＴＳＭサーバー２が利用者の認証を行って登録を認証した携帯端末５のＵＩＣＣ５２において、サービスアプリケーションをインストールする領域を確保する。
また、ＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２の各々は、確保した領域に対してインストールするサービスアプリケーションを、携帯端末５が送信する認証情報（ＳＰ−ＴＳＭサーバー２が携帯端末５に送信した認証情報）から抽出したサービスアプリケーション識別情報により、上記アプリケーションテーブルから読み出す。そして、ＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２の各々は、読み出したサービスアプリケーションを携帯端末５に対して送信し、ＵＩアプリケーションを介してＵＩＣＣ５２にインストールする。

携帯端末５は、利用者の各々が保持する端末であり、例えば携帯電話、スマートフォンあるいはタブレット型端末などである。
また、携帯端末５は、制御部５１、ＵＩＣＣ５２及び非接触記憶カード５３の各々を備えている。

制御部５１は、図示しない無線基地局及びインターネット１００を用いて外部装置とのデータの送受信を行い、非接触記憶カード５３に対してデータの書き込みなどの処理を行う。また、制御部５１は、ＮＦＣなどの近距離無線通信を用いた送受信機能を有し、Ｒ／Ｗ機器とのデータの送受信を、ＩＣカードと同様に行う。
非接触記憶カード５３は、不揮発性のメモリで構成される記憶部であり、ＵＩアプリケーションやＴＳＭプロキシなどがインストールされる。また、このＵＩアプリケーションやＴＳＭプロキシは、非接触記憶カード５３ではなく、携帯端末５の内部メモリにインストールされても良い。ＴＳＭプロキシは、プログラムであり、例えば、携帯端末５が販売される際に、予めインストールされている。

ＵＩＣＣ５２は、固有の識別情報を有するＩＣカードであり、内部に自身の固有の識別情報、携帯端末の加入者情報（携帯端末が携帯電話であれば電話番号など）が記憶されている。この固有の識別情報は、ＵＩＣＣ５２を識別する識別情報であり、例えばＵＩＣＣ５２がＳＩＭカードであれば、ＩＭＳＩ(International Mobile Subscriber Identity)である。また、ＵＩＣＣ５２には、ＵＩアプリケーションにより、利用者が選択したサービスアプリケーションがインストールされる。

ＵＩアプリケーションは、サービスアプリケーションの発行処理を行うリクエストをＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２の各々に対して送信し、ＩＣカードの発行処理を開始する。

また、ＵＩアプリケーションは、利用者がキャリアを変更した際におけるＩＣカードの再発行の処理機能を有しており、表示画面に対してＩＣカードの発行処理の入力画面及び情報の通知画面におけるアイコンを表示し、利用者の再発行に関する情報の入力を促す。
すなわち、ＵＩアプリケーションは、ＳＰ−ＴＳＭサーバー２、ＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２の各々と、ＩＣカードの再発行に必要なデータの送受信を行う。

ＴＳＭプロキシは、ＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２の各々のＵＲＬ（ＩＰアドレス）を有し、ＳＰ−ＴＳＭサーバー２、ＭＮＯ−ＴＳＭサーバー４＿１及びＭＮＯ−ＴＳＭサーバー４＿２の各々のＵＲＬを切り替えてアクセスを行い、サービスアプリケーションの発行における各要求を行うアプリケーションであるＴＳＭプロキシエージェントの機能を含んでいる。

Ａ社サービスセンター１０＿Ａ、Ｂ社サービスセンター１０＿Ｂ及びＣ社サービスセンター１０＿Ｃの各々は、それぞれ携帯端末５により利用可能なサービスを提供する会社のサービスセンターである。利用者から所定のＩＣカードのサービスの利用を受けたいとする申請がなされると、利用者個々を識別するアクセスコードと、利用者毎に異なるパスワードとを郵送などにより、利用者宅に送付する（通知）。

ここで、Ａ社サービスセンター１０＿Ａ、Ｂ社サービスセンター１０＿Ｂ及びＣ社サービスセンター１０＿Ｃの各々は、アクセスコード及びパスワードの供給を、インターネット１００を介した電子メールにより行っても良い。この供給されるアクセスコードには、例えば、利用者を識別する利用者識別情報と、サービスアプリケーションを識別するサービスアプリケーション識別情報となどが含まれている。

また、Ａ社サービスセンター１０＿Ａ、Ｂ社サービスセンター１０＿Ｂ及びＣ社サービスセンター１０＿Ｃの各々は、ＳＰ−ＴＳＭサーバー２を介して、利用者からＩＣカードの利用の申請があると、利用者データベース２１のサービスアプリケーション発行テーブルに対して、新たなレコードを生成し、ＩＣＣＩＤ、アクセスコード、パスワード、ＳＰコード、サービスコードを書き込んで記憶させる。この際、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルに記載された会員番号と、利用者の名前及び有効期限のデータを生成し、サービスアプリケーション発行テーブルに書き込んで、利用者のサービスアプリケーションの発行状態の管理を行う。

図３は、本実施形態におけるサービスアプリケーションのカード発行でのサービスアプリケーション発行システムの動作例を示すシーケンス図である。この図３は、新規にＩＣカードのサービスアプリケーションの発行が、携帯端末５に対して行われる処理を示している。本実施形態においては、一例として、新規にＩＣカードのアプリケーションを携帯端末５にインストールする際、キャリアとしてＸ社が用いられている場合を想定して以下の説明を行う。

図３のシーケンスによる処理の前に、利用者は受けたいサービス会社（Ａ社、Ｂ社及びＣ社のいずれか）に対し、サービスの申請を行っており、利用者は郵送あるいは電子メールにてアクセスコード及びパスワードを、各サービス会社から通知として受領している。ＳＰ−ＴＳＭサーバー２においてＩＣＣＩＤ、アクセスコード、パスワード、ＳＰコード、サービスコード、会員番号、名前、有効期限及び発行ステータスが、利用者データベース２１のサービスアプリケーション発行テーブルにすでに書き込まれている。ここで、発行ステータスは未発行となっている。
また、利用者は、ＵＩアプリケーションを配信サービスサーバー３から、携帯端末５に対してダウンロードしている。このとき、携帯端末５において、制御部５１は、ダウンロードしたＵＩアプリケーションを、非接触記憶カード５３あるいは内蔵メモリに対してインストールする。

シーケンスＦ１０１：
利用者は携帯端末５においてＵＩアプリケーションを起動させ、図示しない携帯端末５の表示画面に表示されるサービスのアイコンのなかから、すでに申請してある所定のＩＣカードのサービスのアイコンを選択する。
これにより、ＵＩアプリケーションは、例えば、アクセスコード、パスワードなどを入力する入力欄を、携帯端末５の表示画面に対して表示する。

次に、利用者は、携帯端末５の表示画面の入力欄に対して図示しない入力手段により、アクセスコード及びパスワードなどを入力する。
ＵＩアプリケーションは、入力されたアクセスコード、パスワードなどを、ＵＩＣＣ５２の識別情報（ＩＣＣＩＤ）及びアクションパラメータ（インストールアクション）とともにＳＰ−ＴＳＭサーバー２に対し、制御部５１を介して送信して、認証の処理を要求する。

シーケンスＦ１０２：
ＳＰ−ＴＳＭサーバー２は、アクションパラメータ（インストールアクション）が入力されることにより、供給されるアクセスコード、パスワードなどにより、利用者データベース２１のサービスアプリケーション発行テーブルを参照し、利用者の認証を行う。このとき、ＳＰ−ＴＳＭサーバー２は、利用者から供給されたアクセスコード及びパスワードなどと、利用者が対応するサービスアプリケーションの利用申請により登録されたサービスアプリケーション発行テーブルに記憶されているアクセスコード及びパスワードなどとが一致するレコードを検出し、この検出したレコードにおける発行ステータスが未発行であるか否かの判定を行う。

このとき、ＳＰ−ＴＳＭサーバー２は、検出したレコードにおける発行ステータスが発行済であれば、処理を終了して、携帯端末５に対して発行済であることを示す通知を行う。一方、ＳＰ−ＴＳＭサーバー２は、発行ステータスが未発行であれば、以下の処理を行う。
ＳＰ−ＴＳＭサーバー２は、サービスアプリケーション発行テーブルにおいて、利用者から供給されるアクセスコードとパスワードとが一致するレコードにおける発行ステータスが未発行であることを検出すると、携帯端末５に対して暗号化された認証情報を送信する。このとき、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、供給されたＩＣＣＩＤを対応するレコードに書き込んで記憶させる。

シーケンスＦ１０３：
ＵＩアプリケーションは、ＳＰ−ＴＳＭサーバー２から認証情報が供給されると、キャリアであるＸ社のＭＮＯ−ＴＳＭサーバー４＿１に対して、認証情報をアクションパラメータ（イニシャライズ）とともに送信する。このとき、ＵＩアプリケーションは、ＵＩＣＣ５２におけるサービスアプリケーションをインストールする領域の確保、及びサービスアプリケーションをこの確保した領域にインストールするイニシャライズを、ＭＮＯ−ＴＳＭサーバー４＿１に要求する。

シーケンスＦ１０４：
ＭＮＯ−ＴＳＭサーバー４＿１は、携帯端末５からイニシャライズの要求が供給されると、携帯端末５におけるＵＩＣＣ５２の内部のメモリに対し、ＵＩアプリケーションを介して、サービスアプリケーションをインストールする領域を確保する。
そして、ＭＮＯ−ＴＳＭサーバー４＿１は、認証情報からサービスアプリケーション識別情報を抽出し、抽出したサービスアプリケーション識別情報により、このサービスアプリケーション識別情報の示すサービスアプリケーションをアプリケーションテーブルから読み出す。
また、ＭＮＯ−ＴＳＭサーバー４＿１は、ＵＩＣＣ５２内部のメモリにおける確保した領域に対して、ＵＩアプリケーションを介してサービスアプリケーションのインストールを行う。

シーケンスＦ１０５：
そして、ＵＩＣＣ５２は、ＵＩアプリケーションを介し、ＭＮＯ−ＴＳＭサーバー４＿１に対して、サービスアプリケーションのインストールが終了したことを示す発行完了通知を送信する。
このとき、ＵＩアプリケーションは、サービスアプリケーションがＵＩＣＣ５２におけるイニシャライズされた所定の領域にインストールされたことを、ＵＩＣＣ５２のＣＰＵからの通知により確認する。

シーケンスＦ１０６：
ＭＮＯ−ＴＳＭサーバー４＿１は、携帯端末５から発行完了通知を受信すると、イニシャライズが終了したことを示す発行レスポンスを携帯端末５に対して送信する。

シーケンスＦ１０７：
ＵＩアプリケーションまたはＴＳＭプロキシは、ＭＮＯ−ＴＳＭサーバー４＿１から発行レスポンスが供給されると、ＳＰ−ＴＳＭサーバー２に対してアクセスする。
そして、ＵＩアプリケーションは、ＵＩＣＣ５２からＩＣＣＩＤを読み出す。そして、ＵＩアプリケーションは、ＩＣＣＩＤ、認証情報及びアクションパラメータ（パーソナライズアクション）を含む、サービスアプリケーションを活性化する発行データの発行を依頼するパーソナライズリクエストを、ＳＰ−ＴＳＭサーバー２に対して送信する。

シーケンスＦ１０８：
ＳＰ−ＴＳＭサーバー２は、認証情報とともにパーソナライズアクションが供給されると、利用者データベース２１のサービスアプリケーション発行テーブルを参照して、携帯端末５から供給されたＩＣＣＩＤ及びサービスアプリケーション識別情報と一致するＩＣＣＩＤ及びサービスアプリケーション識別情報が記載されたレコードの有無を確認する。
そして、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルを参照した結果、ＩＣＣＩＤ及びサービスアプリケーション識別情報と一致するＩＣＣＩＤ及びサービスアプリケーション識別情報が記載されたレコードが検出されると、このレコードにおける発行データを読み出す。

そして、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルから読み出した発行データを、携帯端末５に対して送信する。このとき、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１におけるサービスアプリケーション発行サーバーにおいて、携帯端末５に対して送信した発行データに対応するレコードの発行ステータスを未発行から発行中に変更する。
ＵＩアプリケーションは、ＳＰ−ＴＳＭサーバー２から供給された発行データをＵＩＣＣ５２の所定の領域にインストールされているサービスアプリケーションの所定の箇所に書き込み、サービスアプリケーションの活性化（パーソナライズ）を行う。これにより、サービスアプリケーションが活性化され、携帯端末５には、受けたいサービスの機能が付加される。

シーケンスＦ１０９：
ＵＩＣＣ５２のＣＰＵは、活性化されたサービスアプリケーションの示す動作に基づき、正常にサービスプリケーションが活性化されたことを示すパーソナライズ完了通知を、ＵＩアプリケーションを介して、ＳＰ−ＴＳＭサーバー２に対して送信する。
そして、ＳＰ−ＴＳＭサーバー２は、このパーソナライズ完了通知を受信することにより、携帯端末５に対するサービスアプリケーションのパーソナライズが正常に行われたと判定する。ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、送信した発行データレコードにおける発行ステータスを発行中から発行済に変更し、発行データを削除する処理を行う。

シーケンスＦ１１０：
ＳＰ−ＴＳＭサーバー２は、利用者データベース２１におけるサービスアプリケーションのパーソナライズの完了に伴う処理が終了すると、携帯端末５に対して、サービスアプリケーションのパーソナライズにおける処理が完了したことを示す通知であるパーソナライズレスポンスを出力する。

シーケンスＦ１１１：
ＵＩアプリケーションは、ＳＰ−ＴＳＭサーバー２からパーソナライズレスポンスを受信すると、ＭＮＯ−ＴＳＭサーバー４＿１に対して、サービスアプリケーションのパーソナライズにおける処理が全て完了したことを示す完了処理リクエストを出力する。

シーケンスＦ１１２：
ＭＮＯ−ＴＳＭサーバー４＿１は、携帯端末５から完了処理リクエストを受信すると、携帯端末５に対して完了レスポンスを送信する。
これにより、ＵＩアプリケーションは、携帯端末５に対するサービスアプリケーションの発行処理が全て終了したことを検出する。
そして、ＵＩアプリケーションは、ＩＣカードが発行されて使用可能となったことを示す通知を携帯端末５の表示画面に対して表示する。

図４、図５、図６及び図７の各々は、本実施形態でのキャリア変更の際に行われる、ＩＣカードのサービスアプリケーションの再発行におけるサービスアプリケーション発行システムの動作例を示すシーケンス図である。これら図４、図５、図６及び図７の各々は、利用者が携帯端末のキャリアを変更した際、すなわちキャリア変更前のキャリアの時点で携帯端末５にインストールしたＩＣカードのサービスアプリケーションを、新しいキャリアのＵＩＣＣ５２に対して移行するＩＣカードのサービスアプリケーションの再発行の処理を示している。本実施形態においては、一例として、新規にＩＣカードのアプリケーションを携帯端末５にインストールした際のキャリアをＸ社（図３で説明済み）として、このＸ社からＹ社にキャリアを変更する場合を想定して以下の説明を行う。本実施形態において、ＵＩアプリケーションは、図３の処理が行われる時点でインストールされている。

シーケンスＦ１：
利用者は携帯端末５においてＵＩアプリケーションを起動させ、図示しない携帯端末５の表示画面に表示されるサービスのアイコンのなかから、ＩＣカードの再発行の処理を示すサービスのアイコンを選択する。

シーケンスＦ２：
ＵＩアプリケーションは、携帯端末５内のＵＩＣＣ５２に対して、ユーザ識別子として用いるＰＡＮ及びＩＣＣＩＤ（ＵＩＣＣ５２の識別情報）の個人用データを要求する。

シーケンスＦ３：
ＵＩＣＣ５２は、ＵＩアプリケーションの要求に対応し、内部のサービスアプリケーションにおける発行データから、ＰＡＮ及びＩＣＣＩＤの各々を読み出す。
そして、ＵＩＣＣ５２は、読み出したＰＡＮ及びＩＣＣＩＤをユーザ識別子として、ＵＩアプリケーションに対して出力する。

シーケンスＦ４：
次に、ＵＩアプリケーションは、ＳＰ−ＴＳＭサーバー２に対し、キャリア変更に伴うＩＣカードカードの再発行に用いる発行データである再発行データの作成を依頼することを示す制御信号を送信する。この制御信号にはユーザ識別子としてのＰＡＮ及びＩＣＣＩＤが付加されている。このとき、ＵＩアプリケーションは、設定された変更前のキャリアの発行データの保持期間を、上記制御信号に付加している。この保持期間は、携帯端末５の表示画面から利用者が入力するように構成してもよいし、また、予めＵＩアプリケーションに設定されていても良い。

シーケンスＦ５：
ＳＰ−ＴＳＭサーバー２は、利用者データベース２１におけるサービスアプリケーション発行テーブルから、ユーザ識別子であるＰＡＮ及びＩＣＣＩＤに対応する、発行データの一覧（サービスアプリケーション発行テーブルのレコード）を取得する。
ＳＰ−ＴＳＭサーバー２は、上記保持期間の間、サービスアプリケーション発行テーブルにおけるキャリア変更前の発行データの削除は行わないため、この時点における日時を記憶し、所定の保持期間に達するまでキャリア変更前の発行データの保持を行う。

シーケンスＦ６：
ＳＰ−ＴＳＭサーバー２は、再発行を依頼した利用者に対して、再発行用のアクセスコードである再発行用アクセスコード及びパスワードを作成し、再発行用の発行データである再発行データを作成する。

シーケンスＦ７：
そして、利用者データベース２１のサービスアプリケーション発行テーブルに対し、新たなキャリアに対応して生成した再発行データのアップロードを行う。
すなわち、ＳＰ−ＴＳＭサーバー２は、この利用者の再発行アクセスコード、パスワードと、ユーザ識別子により抽出したＳＰ（サービスプロバイダ）コード、サービスコード及び発行ステータスと、ＰＡＮとに基づき、利用者データベース２１のサービスアプリケーション発行テーブルに対し、新たなキャリアに対応したサービスアプリケーションの活性化に用いる再発行データのレコードを生成する（再発行データのアップロード）。このとき、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブル作成した新たなキャリアに対応したレコードの発行ステータスを未発行とする。

シーケンスＦ８：
ＳＰ−ＴＳＭサーバー２は、再発行データのサービスアプリケーション発行テーブルに対するアップロードが終了すると、携帯端末５のＵＩアプリケーションに対して準備完了レスポンスを送信する。

シーケンスＦ９：
ＵＩアプリケーションは、ＵＩＣＣ５２（Ｘ社対応）におけるサービスアプリケーションの削除依頼コマンドをＭＮＯ−ＴＳＭサーバー４＿１に対して送信する。

シーケンスＦ１０：
ＭＮＯ−ＴＳＭサーバー４＿１は、ＵＩアプリケーションを介して、携帯端末５におけるＵＩＣＣ５２の内部のメモリにおいて、サービスアプリケーションがインストールされた領域から、このサービスアプリケーションを削除する。

シーケンスＦ１１：
そして、ＵＩＣＣ５２は、ＵＩアプリケーションを介し、ＭＮＯ−ＴＳＭサーバー４＿１に対して、サービスアプリケーションを削除する処理が終了したことを示す削除完了レスポンスを送信する。

シーケンスＦ１２：
そして、ＭＮＯ−ＴＳＭサーバー４＿１は、ＵＩＣＣ５２からのレスポンスに対応し、ＵＩアプリケーションに対して、サービスアプリケーションを削除する処理が終了したことを示す削除完了レスポンスを送信する。

シーケンスＦ１３：
ＵＩアプリケーションは、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、再発行データのレコードにおけるステータスの変更を依頼するため、ＳＰ−ＴＳＭサーバー２に対してステータス更新依頼コマンドを送信する。

シーケンスＦ１４：
ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、ユーザ識別子により旧い発行データを特定する。このとき、ＳＰ−ＴＳＭサーバー２は、すでに説明した所定の保持期間の間、サービスアプリケーション発行テーブルにおける旧い発行データ（キャリア変更前の発行データ）の削除は行わない。
また、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、ユーザ識別子により再発行データのレコードにおけるステータスを未発行から発行中に更新する。

シーケンスＦ１５：
ＳＰ−ＴＳＭサーバー２は、携帯端末５に対して、ＩＣカードを更新するために用いる再発行用アクセスコード及びパスワードを送信して通知する。

シーケンスＦ１６：
ＵＩアプリケーションは、再発行用アクセスコード及びパスワードを受信すると、非接触記憶カード５３に書き込んで記憶させる。
そして、ＵＩアプリケーションは、再発行処理におけるＵＩＣＣ５２における発行データの削除が完了したことを示す利用者に対する通知を表示画面に表示する。
また、ＵＩアプリケーションは、表示画面に対して、再発行用アクセスコード及びパスワードを表示画面に対して表示するように構成しても良い。

シーケンスＦ１７：
利用者は、ＵＩＣＣ５２における発行データの削除が完了したことを示す通知を表示画面において確認すると、携帯端末５の電源をオフとして、携帯端末５のＵＩＣＣ５２を新たなキャリアの他のＵＩＣＣ５２に差し替える。
または、利用者は、携帯端末５とＵＩＣＣ５２との双方を、新たなキャリアの提供する携帯端末５、ＵＩＣＣ５２に交換する。

シーケンスＦ１８：
利用者は、携帯端末５の電源をオンとして、表示画面に表示されるアイコンなどにより、ＵＩアプリケーションを立ち上げる（起動させる）。

シーケンスＦ１９：
ＵＩアプリケーションは、起動された後、ＵＩＣＣ５２に対してＩＣカードの発行状態を確認するためのステータスの問い合わせを行う。

シーケンスＦ２０：
ＵＩＣＣ５２は、ＩＣカードのサービスアプリケーションがインストールされていないため、未発行状態を示すステータスをレスポンスとしてＵＩアプリケーションに対して出力する。

シーケンスＦ２１：
ＵＩアプリケーションは、表示画面に対してＩＣカードの再発行画面を表示する。利用者は、再発行を示すアイコンなどによりＩＣカードの発行処理の開始を入力する。
このとき、利用者は、再発行用アクセスコード及びパスワードを入力欄に入力するようにしても良い。

シーケンスＦ２２：
利用者は携帯端末５においてＵＩアプリケーションを起動させ、図示しない携帯端末５の表示画面に表示されるサービスのアイコンのなかから、所定のＩＣカードの再発行を行うサービスのアイコンを選択する。
これにより、ＵＩアプリケーションは、例えば、再発行用アクセスコード、パスワードなどを入力する入力欄を、携帯端末５の表示画面に対して表示する。

次に、利用者は、携帯端末５の表示画面の入力欄に対して図示しない入力手段により、アクセスコード及びパスワードなどを上記入力欄に入力する。
また、非接触記憶カード５３に再発行用アクセスコード及びパスワードが記憶されている場合、ＵＩアプリケーションが、再発行用アクセスコード及びパスワードを、非接触記憶カード５３から読み出して使用するようにしても良い。
ＵＩアプリケーションは、入力されたあるいは、非接触記憶カード５３から読み出した再発行用アクセスコード、パスワードなどを、ＵＩＣＣ５２の識別情報（ＩＣＣＩＤ）及びアクションパラメータ（インストールアクション）とともにＳＰ−ＴＳＭサーバー２に対し、制御部５１を介して送信して、認証の処理を要求する。

シーケンスＦ２３：
ＳＰ−ＴＳＭサーバー２は、アクションパラメータ（インストールアクション）が入力されることにより、供給される再発行用アクセスコード、パスワードなどにより、利用者データベース２１のサービスアプリケーション発行テーブルを参照し、利用者の認証を行う。このとき、ＳＰ−ＴＳＭサーバー２は、利用者から供給されたアクセスコード及びパスワードなどと、利用者が対応するサービスアプリケーションの利用申請により登録されたサービスアプリケーション発行テーブルに記憶されているアクセスコード及びパスワードなどとが一致するレコードを検出し、この検出したレコードにおける発行ステータスが未発行であるか否かの判定を行う。

このとき、ＳＰ−ＴＳＭサーバー２は、検出したレコードにおける発行ステータスが発行済であれば、処理を終了して、携帯端末５に対して発行済であることを示す通知を行う。一方、ＳＰ−ＴＳＭサーバー２は、発行ステータスが未発行であれば、以下の処理を行う。
ＳＰ−ＴＳＭサーバー２は、サービスアプリケーション発行テーブルにおいて、利用者から供給される再発行アクセスコードとパスワードとが一致するレコードにおける発行ステータスが未発行であることを検出すると、携帯端末５に対して暗号化された認証情報を送信する。このとき、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、供給されたＩＣＣＩＤを対応するレコードに書き込んで記憶させる。

シーケンスＦ２４：
ＵＩアプリケーションまたはＴＳＭプロキシは、ＳＰ−ＴＳＭサーバー２から認証情報が供給されると、更新後のキャリアであるＹ社のＭＮＯ−ＴＳＭサーバー４＿２に対して、認証情報をアクションパラメータ（イニシャライズ）とともに送信する。このとき、ＵＩアプリケーションは、ＵＩＣＣ５２におけるサービスアプリケーションをインストールする領域の確保、及びサービスアプリケーションをこの確保した領域にインストールするイニシャライズを、ＭＮＯ−ＴＳＭサーバー４＿２に要求する。

シーケンスＦ２５：
ＭＮＯ−ＴＳＭサーバー４＿２は、携帯端末５からイニシャライズの要求が供給されると、携帯端末５におけるＵＩＣＣ５２の内部のメモリに対し、ＵＩアプリケーションを介して、サービスアプリケーションをインストールする領域を確保する。
そして、ＭＮＯ−ＴＳＭサーバー４＿２は、認証情報からサービスアプリケーション識別情報を抽出し、抽出したサービスアプリケーション識別情報により、このサービスアプリケーション識別情報の示すサービスアプリケーションをアプリケーションテーブルから読み出す。
また、ＭＮＯ−ＴＳＭサーバー４＿２は、ＵＩＣＣ５２内部のメモリにおける確保した領域に対して、ＵＩアプリケーションを介してサービスアプリケーションのインストールを行う。

シーケンスＦ２６：
そして、ＵＩＣＣ５２は、ＵＩアプリケーションを介し、ＭＮＯ−ＴＳＭサーバー４＿２に対して、サービスアプリケーションのインストールが終了したことを示す発行完了通知としての完了レスポンスを送信する。
このとき、ＵＩアプリケーションは、サービスアプリケーションがＵＩＣＣ５２におけるイニシャライズされた所定の領域にインストールされたことを、ＵＩＣＣ５２のＣＰＵからの完了レスポンスの通知により確認する。

シーケンスＦ２７：
ＭＮＯ−ＴＳＭサーバー４＿２は、携帯端末５から発行完了通知を受信すると、イニシャライズが終了したことを示す発行レスポンスを携帯端末５に対して送信する。

シーケンスＦ２８：
ＵＩアプリケーションまたはＴＳＭプロキシは、ＭＮＯ−ＴＳＭサーバー４＿２から発行レスポンスが供給されると、ＳＰ−ＴＳＭサーバー２に対してアクセスする。
そして、ＵＩアプリケーションまたはＴＳＭプロキシは、ＵＩＣＣ５２からＩＣＣＩＤを読み出す。そして、ＵＩアプリケーションは、ＩＣＣＩＤ、認証情報（再発行アクセスコード、パスワード、サービスアプリケーション識別情報）及びアクションパラメータ（パーソナライズアクション）を含む、サービスアプリケーションを活性化する発行データの発行を依頼するパーソナライズリクエストを、ＳＰ−ＴＳＭサーバー２に対して送信する。

シーケンスＦ２９：
ＳＰ−ＴＳＭサーバー２は、認証情報とともにパーソナライズアクションが供給されると、利用者データベース２１のサービスアプリケーション発行テーブルを参照して、携帯端末５から供給されたＩＣＣＩＤ及びサービスアプリケーション識別情報と一致するＩＣＣＩＤ及びサービスアプリケーション識別情報が記載されたレコードの有無を確認する。
そして、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルを参照した結果、ＩＣＣＩＤ及びサービスアプリケーション識別情報と一致するＩＣＣＩＤ及びサービスアプリケーション識別情報が記載された再発行のＩＣカードに対応するレコードが検出されると、このレコードにおける再発行データを読み出す。

そして、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルから読み出した再発行データを、携帯端末５に対して送信する。このとき、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１におけるサービスアプリケーション発行サーバーにおいて、携帯端末５に対して送信した発行データに対応するレコードの発行ステータスを未発行から発行中に変更する。
このとき、ＵＩＣＣ５２は、ＳＰ−ＴＳＭサーバー２から供給された発行データを所定の領域にインストールされているサービスアプリケーションの所定の箇所に書き込み、サービスアプリケーションの活性化（パーソナライズ）を行う。これにより、サービスアプリケーションが活性化され、携帯端末５には、受けたいサービスの機能が付加される。

シーケンスＦ３０：
ＵＩＣＣ５２のＣＰＵは、活性化されたサービスアプリケーションの示す動作に基づき、正常に再発行のＩＣカードのサービスプリケーションが活性化されたことを示すパーソナライズ完了通知を、ＵＩアプリケーションを介して、ＳＰ−ＴＳＭサーバー２に対して送信する。

シーケンスＦ３１：
そして、ＳＰ−ＴＳＭサーバー２は、このパーソナライズ完了通知を受信することにより、携帯端末５に対する再発行のＩＣカードのサービスアプリケーションのパーソナライズが正常に行われたと判定する。
すなわち、ＳＰ−ＴＳＭサーバー２は、パーソナライズ完了通知によって、再発行データを用いたＩＣカードの再発行が行われたことを検出する。

シーケンスＦ３２：
ＳＰ−ＴＳＭサーバー２は、携帯端末５におけるサービスアプリケーションのパーソナライズの完了に伴う処理が終了すると、携帯端末５のＵＩアプリケーションに対して、サービスアプリケーションのパーソナライズにおける処理が完了したことを示す通知であるパーソナライズレスポンスを出力する。

シーケンスＦ３３：
ＵＩアプリケーションは、ＳＰ−ＴＳＭサーバー２からパーソナライズレスポンスを受信すると、ＭＮＯ−ＴＳＭサーバー４＿２に対して、サービスアプリケーションのパーソナライズにおける処理が全て完了したことを示す完了処理リクエストを出力する。

シーケンスＦ３４：
ＭＮＯ−ＴＳＭサーバー４＿２は、携帯端末５から完了処理リクエストを受信すると、携帯端末５のＵＩアプリケーションに対して完了のレスポンスを送信する。このとき、ＭＮＯ−ＴＳＭサーバー４＿２は、サービスアプリケーション発行テーブルの更新を行う。
これにより、ＵＩアプリケーションは、携帯端末５に対するサービスアプリケーションの発行処理が全て終了したことを検出する。

シーケンスＦ３５：
ＵＩアプリケーションは、キャリア変更後のＩＣカードのサービスアプリケーションの再発行が終了したため、サービスアプリケーションテーブルのステータスの更新を依頼するステータス更新通知をＳＰ−ＴＳＭサーバー２に対して送信する。このとき、ＵＩアプリケーションは、再発行前のサービスアプリケーション及び再発行後のサービスアプリケーションの各々のユーザ識別子をステータス更新通知に付加し、ＳＰ−ＴＳＭサーバー２に対して送信する。

シーケンスＦ３６：
ＳＰ−ＴＳＭサーバー２は、ステータス更新通知が供給されると、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、付加された再発行前のＩＣカードのサービスアプリケーションに対応するレコードを削除する。
そして、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、付加された再発行後の新しいＩＣカードのサービスアプリケーションに対応するレコードのステータスを発行中から発行済に書き換えて変更する。

シーケンスＦ３７：
ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、キャリア発行前のサービスアプリケーションのレコードの削除、新しいサービスアプリケーションのレコードにおけるステータスの変更により、ＩＣカードの再発行が終了したとする。
そして、ＳＰ−ＴＳＭサーバー２は、キャリアの変更に伴うＩＣカードのサービスアプリケーションの再発行が全て終了したことを示す再発行完了レスポンスを、携帯端末５のＵＩアプリケーションに対して送信する。

シーケンスＦ３８：
ＵＩアプリケーションは、ＳＰ−ＴＳＭサーバー２から再発行完了レスポンスが供給されると、ＩＣカードの再発行処理が終了したことを検出し、表示画面に対してＩＣカードの再発行が完了したことを示す画面を表示する。
この画面表示を見ることにより、利用者はキャリア変更に伴う携帯端末５におけるＩＣカードの変更処理が終了したことを認識する。

また、シーケンスＳＰ−ＴＳＭサーバー２は、上述したシーケンスＦ２３におけるＩＣカード発行要求がなく、上記保持期間の間、新たなサービスアプリケーションを発行済とするステータス変更が行われない場合、サービスアプリケーション発行テーブルにおける旧い発行データ（キャリア変更前の発行データ）をそのまま発行済の状態とし、新しい再発行データ（キャリア変更後の再発行データ）のレコードを削除する。そして、ＩＣカードの発行元であるＡ社サービスセンター１０＿Ａ（またはＢ社サービスセンター１０＿ＢあるいはＣ社サービスセンター１０＿Ｃ）から、安全性を確保するためにＩＣカードの再発行の処理を停止したとし、新たに再発行を行うことを促す通知が利用者に対して送られる。

また、上述したキャリアの変更に伴うＩＣカードの再発行において、キャリアを変更する際に、携帯端末５を継続して使用する場合と、携帯端末５も変更する場合とがあるが、いずれの場合にも、ＩＣカードの再発行を行うために、変更後の携帯端末５の非接触記憶カード５３に対して、新たにＵＩアプリケーションのダウンロードが必要となる。

上述したように、本実施形態によれば、携帯端末５のＵＩＣＣ５２に対するデータ削除が行われて、新たなＵＩＣＣ５２にサービスアプリケーションがインストールされ、新たなキャリアにおけるＵＩＣＣ５２においてＩＣカードが使用可能となるまで、サービスアプリケーション発行テーブルにおけるキャリア更新前のＩＣカードの発行データが継続して使用できる。
このため、本実施形態によれば、キャリア変更による新たなＵＩＣＣ５２に対するＩＣカードの再発行処理が行われていても、キャリア変更前のＰＡＮでの決済が可能な状態にあり、公共料金の自動引き落としや買い物における決済処理が可能であり、利用者にとってＩＣカードの変更において不便を強いられることがなく、キャリアの変更を従来に比較して容易とすることが可能となる。

また、本実施形態によれば、利用者がキャリアを変更する際に、変更前のキャリアのＭＮＯ−ＴＳＭサーバー４＿１が自身がインストールしたＵＩＣＣ５２におけるサービスアプリケーション及び発行データの削除を行うため、利用者が変更前のＵＩＣＣ５２のアプリケーションの個人用の発行データを削除し忘れても悪用されるような危険な状態となることを防止することができる。

また、図１におけるＵＩアプリケーション、ＳＰ−ＴＳＭサーバー２の各々の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによりサービス情報の管理の処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。

さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイルであっても良い。

以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

１…サービスアプリケーション発行システム
２…ＳＰ−ＴＳＭサーバー
３…配信サービスサーバー
４＿１，４＿２…ＭＮＯ−ＴＳＭサーバー
５…携帯端末
６…管理サーバー
１０＿Ａ…Ａ社サービスセンター
１０＿Ｂ…Ｂ社サービスセンター
１０＿Ｃ…Ｃ社サービスセンター
２１…利用者データベース
５１…制御部
５２…ＵＩＣＣ
５３…非接触記憶カード５３
１００…インターネット

Claims (5)

1. 利用者の選択したＩＣカードの動作するサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケションを活性化する発行データを前記携帯端末に配信する発行データ配信サーバーであって、
   前記携帯端末のキャリアが変更された際、当該携帯端末に対して発行した前記サービスアプリケーションの発行データが記憶されたサービスアプリケーション発行テーブルに対し、変更後のキャリアに対応したサービスアプリケーションのレコードを生成し、前記携帯端末においてキャリアの変更後において前記サービスアプリケーションが活性化された後、前記サービスアプリケーション発行テーブルに変更前のキャリアに対応したサービスアプリケーションのレコードの発行データを削除し、新たなキャリアに対応したサービスアプリケーションのレコードの発行データを使用可とする
   ことを特徴とする発行データ配信サーバー。
2. サービスアプリケーションが活性化された後、前記携帯端末から発行データのステータスの更新依頼が供給された際、前記サービスアプリケーション発行テーブルにおいて、変更前のキャリアに対応したサービスアプリケーションのレコードの発行データを削除し、新たなキャリアに対応したサービスアプリケーションのレコードの発行データを使用可とすることを特徴とする請求項１に記載の発行データ配信サーバー。
3. 予め設定された期間の間、新たなキャリアに対応したサービスアプリケーションの活性化の依頼が前記携帯端末から供給されない場合、前記サービスアプリケーション発行テーブルにおける変更後のキャリアに対応したサービスアプリケーションの発行データの前記レコードを削除する
   ことを特徴とする請求項１または請求項２に記載の発行データ配信サーバー。
4. 利用者の選択したＩＣカードの動作するサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケションを活性化する発行データを前記携帯端末に配信する発行データ配信サーバーにおける発行データ配信方法であって、
   前記携帯端末のキャリアが変更された際、当該携帯端末に対して発行した前記サービスアプリケーションの発行データが記憶されたサービスアプリケーション発行テーブルに対し、変更後のキャリアに対応したサービスアプリケーションのレコードを生成する過程と、
   前記携帯端末においてキャリアの変更後において前記サービスアプリケーションが活性化された後、前記サービスアプリケーション発行テーブルに変更前のキャリアに対応したサービスアプリケーションのレコードの発行データを削除し、新たなキャリアに対応したサービスアプリケーションのレコードの発行データを使用可とする過程と
   を含む
   ことを特徴とする発行データ配信方法。
5. 利用者が携帯する携帯端末と、前記利用者の選択したＩＣカードの動作するサービスアプリケーションを前記携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケションを活性化する発行データを前記携帯端末に配信する発行データ配信サーバーとを有する発行データ配信システムであり、
   前記携帯端末が、
   前記発行データ配信サーバーに対してキャリア変更に伴う、前記ＩＣカードのサービスアプリケーションの再発行を依頼し、
   前記発行データ配信サーバーが、
   前記携帯端末からの再発行の依頼に対応し、当該携帯端末に対して発行した前記サービスアプリケーションの発行データが記憶されたサービスアプリケーション発行テーブルに対し、変更後のキャリアに対応したサービスアプリケーションのレコードを生成し、前記携帯端末においてキャリアの変更後において前記サービスアプリケーションが活性化された後、前記サービスアプリケーション発行テーブルに変更前のキャリアに対応したサービスアプリケーションのレコードの発行データを削除し、新たなキャリアに対応したサービスアプリケーションのレコードの発行データを使用可とする
   ことを特徴とする発行データ配信システム。

Images