JP2016012754A - サービスアプリケーション発行装置、サービスアプリケーション発行方法及びサービスアプリケーション発行システム - Google Patents

Abstract

【課題】同一の利用者の携帯端末に同一のアクセスコードのサービスアプリケーション（以下、ＳＡ）が多重に発行されることを防止するサービスアプリケーション発行装置を提供する。
【解決手段】本発明は、ＩＣカードの動作をエミュレートするＳＡを携帯端末に対して配信するサービスアプリケーション配信サーバーから配信されたＳＡを活性化する発行データを携帯端末に配信する発行データ配信サーバーと、利用者を識別する識別情報とＳＡを活性化するＳＡの発行データと、発行データの発行ステータスとが対応付けられたサービスアプリケーション発行テーブルが記憶された利用者テーブルとを備え、発行データ配信サーバーが、携帯端末に対してＳＡの発行データの出力後、利用者データベースの発行データの発行ステータスを未発行から発行中とし、ＳＡの活性化を示す通知を受信すると、発行ステータスを発行中から発行済に変更する。
【選択図】図１

Description

本発明は、サービスアプリケーション発行装置、サービスアプリケーション発行方法及びサービスアプリケーション発行システムに関する。

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

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

図６は、従来のサービスアプリケーション発行システムの構成を示す図である。
この図６に示すサービスアプリケーション発行システムにおいて、ＩＣカードを携帯端末５上においてエミュレートするためのサービスアプリケーションが、携帯端末５のＵＩＣＣ（Universal Integrated Circuit Card、汎用ＩＣカード）５２に、非接触記憶カード５３あるいは内蔵メモリ上のＵＩ（User Interface）アプリケーションによりインストールされる。非接触記憶カード５３は、例えば、ＳＤ（Secure Digital）カード（登録商標）などのフラッシュメモリを用いたメモリカードである。このＵＩＣＣ５２としては、例えばＳＩＭ（Subscriber Identity Module）カード、ＵＩＭ（User Identity Module）カードなどがある。ＵＩＣＣ５２は、例えば、内部にＣＰＵ（Central Processing Unit）及びメモリを有しており、活性化された後のサービスアプリケーションのＩＣカードのエミレートを行う。
Ａ社サービスセンター１０＿Ａ及びＺ社サービスセンター１０＿Ｚの各々は、ＩＣカードのサービスを提供する会社のサービスセンターであり、アクセスコード及びパスワードを、サービスを依頼した利用者に対して郵送、あるいは電子メールにより送付する。

そして、携帯端末５には、サービスアプリケーションをＵＩＣＣ５２に対してインストールする際、サービスアプリケーションをインストールするＵＩアプリケーションが必要となる。制御部５１は、ＧｏｏｇｌｅＰｌａｙ（登録商標）などの配信サービスサーバー３から、ＵＩアプリケーションをダウンロードする。そして、制御部５１は、携帯端末５の非接触記憶カード５３あるいは内蔵メモリに対し、ダウンロードしたＵＩアプリケーションをインストールする。

また、このサービスアプリケーションの配信は、ＭＮＯ（Mobile Network Operator）−ＴＳＭ（Trusted Service Manager）サーバー４が行う。また、利用者の認証、サービスアプリケーションに対する発行データの発行や管理は、ＳＰ（Service Provider）−ＴＳＭ（Trusted Service Manager）サーバー１０２が行う。
すなわち、ＳＰ−ＴＳＭサーバー１０２は、利用者の認証を行い、正しく認証されたと判定すると、正しく認証されたことを示す認証情報を携帯端末５に対して送信する。

そして、ＵＩアプリケーションは、認証情報が入力されると、ＭＮＯ−ＴＳＭサーバー４に対して、ＵＩＣＣ５２に対してサービスアプリケーションの発行におけるイニシャライズを行うことを要求する。そして、ＭＮＯ−ＴＳＭサーバー４は、サービスアプリケーションをインストールする領域をＵＩＣＣ５２内に確保し、確保した領域にサービスアプリケーションをインストールすることで、ＵＩＣＣ５２に対するイニシャライズを行う。イニシャライズが終了した後、ＭＮＯ−ＴＳＭサーバー４が、携帯端末５に対してイニシャライズが終了したことを示す発行レスポンスを出力する。
ＵＩアプリケーションは、発行レスポンスを受信すると、ＵＩＣＣ５２の識別情報及びサービスプロバイダの識別情報を付加し、パーソナライズの要求をＳＰ−ＴＳＭサーバー１０２に送信する。

これにより、ＳＰ−ＴＳＭサーバー１０２は、携帯端末５のサービスアプリケーションに対して発行データの発行を行い、携帯端末５にインストールされているサービスアプリケーションが活性化される。この発行データは、携帯端末５のＵＩＣＣ５２にインストールされた所定のＩＣカードをエミュレートするサービスアプリケーションを、所有者に対応して使用可能とする（サービスアプリケーションの活性化を行う）ためのデータ（後述）である。
そして、サービスアプリケーションは、ＵＩアプリケーションを介して、ＳＰ−ＴＳＭサーバー１０２に対して正常にサービスアプリケーションが活性化（パーソナライズ）されたことを示すパーソナライズ完了通知を出力する。そして、ＳＰ−ＴＳＭサーバー１０２は、サービスアプリケーションのパーソナライズが正常に終了したことを検出し、携帯端末５に対してパーソナライズレスポンスを出力する。このとき、ＳＰ−ＴＳＭサーバー１０２は、内部のアクセスコードと発行状態を示す発行ステータスとが対応付けられたアプリケーション発行テーブルにおいて、発行ステータスを未発行から発行済に変更する。

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

しかしながら、ＳＰ−ＴＳＭサーバー１０２が、サービスアプリケーションを活性化する発行データの発行を行った後、通信エラーなどにより、携帯端末５とＳＰ−ＴＳＭサーバー２との通信が遮断される場合がある。この通信が遮断された場合、ＳＰ−ＴＳＭサーバー１０２は、サービスアプリケーションが発行データにより正常に活性化（パーソナライズ）されたことを示すパーソナライズ完了通知を携帯端末５から受信できない。
このため、ＳＰ−ＴＳＭサーバー１０２は、ＵＩＣＣ５２にインストールされたサービスアプリケーションのパーソナライズが正常に終了し、サービスアプリケーションが活性化されたか否かを検出することができない。このため、アプリケーション発行テーブルにおける発行ステータスは未発行の状態のままとなる。

また、携帯端末５とＳＰ−ＴＳＭサーバー１０２の間における通信の遮断が発行データを送信している際に起こった場合にも、ＳＰ−ＴＳＭサーバー１０２は、携帯端末５からパーソナライズ完了通知が受信できない。
従来は、ＳＰ−ＴＳＭサーバー１０２がパーソナライズ完了通知を受信できない場合、発行データが送信されていないとし、携帯端末５に対するサービスアプリケーションが未発行の状態であると判定している。
このため、ＳＰ−ＴＳＭサーバー１０２は、携帯端末５からサービスアプリケーションの発行要求が再度入力されると、新たにサービスアプリケーションの発行処理を行う。

しかしながら、すでに述べたように、ＳＰ−ＴＳＭサーバー１０２により発行データが送信され、携帯端末５においてサービスアプリケーションが活性化されているにも係わらず、通信が遮断したことにより、携帯端末５から送信されたパーソナライズ完了通知がＳＰ−ＴＳＭサーバー１０２に到達していない可能性もある。
この場合、携帯端末５ではサービスアプリケーションが活性化しているにも係わらず、ＳＰ−ＴＳＭサーバー１０２においては発行データが未発行の状態となっている。このため、携帯端末５において、利用者がＵＩＣＣ５２を入れ替えることにより、新たなＵＩＣＣ５２にもサービスアプリケーションが発行される。すなわち、同一の利用者に対する同一のアクセスコードの示すサービスアプリケーションが多重に発行、すなわち同一のカード番号等を有するＩＣカードの複製が複数生成されることになる。

本発明は、このような事情に鑑みてなされたもので、サービスアプリケーションのパーソナライズ完了通知が受信できない場合でも、同一の利用者に対する同一のアクセスコードのサービスアプリケーションが多重に発行され、同一のカード番号等を有するＩＣカードの複製が複数生成されることを防止するサービスアプリケーション発行装置、サーバーサービスアプリケーション発行方法及びサービスアプリケーション発行システムを提供することを目的とする。

この発明は上述した課題を解決するためになされたもので、本発明のサービスアプリケーション発行装置は、利用者の選択したＩＣカードの動作をエミュレートするサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケーションを活性化する発行データを前記携帯端末に配信する発行データ配信サーバーと、前記利用者を識別する識別情報と前記サービスアプリケーションを活性化する当該サービスアプリケーションの発行データと、当該発行データの発行状態を示す発行ステータスが対応付けられたサービスアプリケーション発行テーブルを記憶する利用者データベースとを備え、前記発行データ配信サーバーが、前記携帯端末に対してサービスアプリケーションの前記発行データを出力した後、前記利用者データベースにおいて当該発行データに対応する発行ステータスを未発行から発行中とし、前記携帯端末から前記サービスアプリケーションが活性化されたことを示す通知を受信すると、前記発行ステータスを発行中から発行済に変更することを特徴とする。

本発明のサービスアプリケーション発行装置は、前記発行データ配信サーバーが、前記携帯端末から前記サービスアプリケーションの発行処理が再度依頼された場合、前記発行ステータスが発行中であると、前記サービスアプリケーションの発行処理を行わないことを特徴とする。

本発明のサービスアプリケーション発行装置は、前記発行データ配信サーバーが、前記サービスアプリケーションが活性化されたことを示す通知として、前記サービスアプリケーションの生存確認を示す通知のポーリングが前記携帯端末から供給された場合、当該サービスアプリケーションの発行状態を発行中から発行済に変更することを特徴とする。

本発明のサービスアプリケーション発行装置は、前記発行データ配信サーバーが、前記サービスアプリケーションの発行状態が未発行から発行中に変更されてから予め設定された所定の期間が経過した時点において、前記発行データの発行ステータスを発行中から未発行に変更することを特徴とする。

本発明のサービスアプリケーション発行方法は、発行データ配信サーバーが、利用者の選択したＩＣカードの動作をエミュレートするサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケーションを活性化する発行データを、前記携帯端末に対して出力した後、前記利用者の識別情報と、未発行の前記サービスアプリケーションを活性化する当該サービスアプリケーションの発行データと、サービスアプリケーションの発行状態とが対応付けられたサービスアプリケーション発行テーブルを記憶する利用者データベースにおける前記サービスアプリケーションの前記発行ステータスを未発行から発行中に変更することを特徴とするサービスアプリケーション発行方法。

本発明のサービスアプリケーション発行システムは、利用者の選択したＩＣカードの動作をエミュレートするサービスアプリケーションを、前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーと、前記携帯端末に配信されたサービスアプリケーションを活性化する発行データを前記携帯端末に配信する発行データ配信サーバーと、前記利用者を識別する識別情報と前記サービスアプリケーションを活性化する当該サービスアプリケーションの発行データと、当該発行データの発行状態を示す発行ステータスとが対応付けられたサービスアプリケーション発行テーブルを記憶する利用者データベースとを備え、前記発行データ配信サーバーが、前記携帯端末に対してサービスアプリケーションの前記発行データを出力した後、前記利用者データベースにおいて当該発行データに対応する発行ステータスを未発行から発行中とし、前記携帯端末から前記サービスアプリケーションが活性化されたことを示す通知を受信すると、前記発行ステータスを発行中から発行済に変更することを特徴とする。

本発明によれば、サービスアプリケーションの活性化を示すパーソナライズ完了通知が受信できず、発行データによるパーソナライズの完了を検出できない場合でも、発行データが発行済とされるため、同一の利用者に対する同一のアクセスコードのサービスアプリケーションが多重に発行され、同一のカード番号等を有するＩＣカードの複製が複数生成されることを防止するサービスアプリケーション発行装置、サーバーサービスアプリケーション発行方法及びサービスアプリケーション発行システムを提供することが可能となる。

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

以下、図面を参照して、本発明の実施形態について説明する。図１は、本発明の一実施形態によるサービスアプリケーション発行システムの構成例を示す概略ブロック図である。この図１において、サービスアプリケーション発行システムは、ＳＰ−ＴＳＭサーバー２、配信サービスサーバー３、ＭＮＯ−ＴＳＭサーバー４、携帯端末５及び利用者データベース２１を備えている。本実施形態において、ＳＰ−ＴＳＭサーバー２は発行データ配信サーバーの具体例であり、ＭＮＯ−ＴＳＭサーバー４はアプリケーション発行サーバーの具体例であり、ＵＩＣＣ５２は汎用集積回路カードの具体例である。ここで、ＳＰ−ＴＳＭサーバー２及び利用者データベース２１の各々は、アプリケーション発行装置の構成要素である。

ＭＮＯ−ＴＳＭサーバー４は、ＩＣカードのサービスを提供する会社のサービスプロバイダ（事業者）が契約したキャリアの保有するサーバーであり、携帯端末５のＵＩＣＣ５２にインストールされるサービスアプリケーションを、配信要求を行った携帯端末５に対して供給（配信）する。ＭＮＯ−ＴＳＭサーバー４は、サービスアプリケーションを各ＩＣカードのサービスプロバイダから受託して、サービスアプリケーションとこのサービスアプリケーションを識別するサービス識別情報との対応するアプリケーションテーブルを、図示しないデータベースにて管理している。発行データは、携帯端末５のＵＩＣＣ５２にインストールされた所定のＩＣカードをエミュレートするサービスアプリケーションを、所有者に対応して使用可能とするパーソナライズ（活性化）を行うためのデータである。発行データの種類については後述する。

ＳＰ−ＴＳＭサーバー２は、各ＩＣカードのサービスを提供するサービスプロバイダにより発行される、サービスアプリケーションを活性化させる発行データを、携帯端末５に送信し、ＵＩＣＣ５２にインストールされたサービスアプリケーションを活性化させる。また、ＳＰ−ＴＳＭサーバー２は、後述する利用者データベース２１を有し、利用者の認証及び利用者に対する発行データの管理を行っている。

利用者データベース２１には、アクセスコード及びパスワードと発行ステータスとが対応して記憶されたサービスアプリケーション発行テーブル（後述）が書き込まれて記憶されている。この発行ステータスは、サービスアプリケーションの発行状態を示すステータスであり、サービスアプリケーションが発行されていないことを示す未発行と、サービスアプリケーションに対する発行データを発行したことを示す発行中と、サービスアプリケーションの発行が完了したことを示す発行済との３つの種類の状態がある。
利用者からサービスアプリケーションの発行の申請がなされた際、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルに対し、この利用者のアクセスコード、パスワード、ＳＰ（サービスプロバイダ）コード、サービスコード及び発行ステータスを有するレコードを生成する。また、このレコードには、携帯端末５にインストールされたサービスアプリケーションを活性化する発行データも含まれている。このとき、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルにおける新たに作成したレコードの発行ステータスを未発行とする。

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

アクセスコードは、パスワードとともにサービスアプリケーションの発行を申請した際に利用者に供給される、サービスアプリケーションの発行に用いるデータである。このアクセスコードは、利用者を識別する利用者識別情報である。発行データとは、サービスアプリケーションを活性化させる（パーソナライズする）ためのデータであり、ＩＣカードのサービスに対応したサービスアプリケーションに与えられる利用者個々の決済ブランドにおける会員番号（PAN：Primary Account Number） 、発行されたＩＣカードの使用可能期間である有効期間、利用者の名前などを含む情報である。発行ステータスは、サービスアプリケーションの発行状態を示している。

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

また、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、サービスアプリケーションの利用者のレコードに対して、事前に、発行データを書き込んで記憶させてある。すなわち、この発行データは、サービスプロバイダが利用者に対してアクセスコード及びパスワードが送付される以前に、すなわち、利用者からＩＣカードのサービスの申込みを受け付けた際に、サービスプロバイダからＳＰ−ＴＳＭサーバー２を介して、利用者データベース２１のサービスアプリケーションテーブルに書き込まれる。

そして、ＳＰ−ＴＳＭサーバー２は、携帯端末５に対するサービスアプリケーションに対応する発行データの発行が正常に行われたと判定した場合、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、対応するレコードの発行ステータスを未発行から発行中に変更する処理を行う。また、ＳＰ−ＴＳＭサーバー２は、携帯端末５にインストールされたサービスアプリケーションが活性化されたことを示す通知が確認されると、サービスアプリケーションの発行が正常に行われたと判定する。
本実施形態において、ＳＰ−ＴＳＭサーバー２は、携帯端末５からパーソナライズ完了通知が送信されるか、あるいは携帯端末５からサービスアプリケーションの生存確認の通知が供給されたか、のいずれかの場合にサービスアプリケーションの発行が正常に行われたと判定する。

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

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

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

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

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

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

図１において、Ａ社サービスセンター１０＿ＡからＺ社サービスセンター１０＿Ｚの各々は、それぞれ携帯端末５により利用可能なサービスを提供する会社のサービスセンターである。利用者から所定のＩＣカードのサービスの利用を受けたいとする申請がなされると、利用者個々を識別するアクセスコードと、利用者毎に異なるパスワードとを郵送なドにより、利用者宅に送付する。ここで、Ａ社サービスセンター１０＿ＡからＺ社サービスセンター１０＿Ｚの各々は、アクセスコード及びパスワードの供給を、インターネット１００を介した電子メールにより行っても良い。この供給されるアクセスコードには、例えば、利用者を識別する利用者識別情報、サービスアプリケーションを識別するサービスアプリケーション識別情報などが含まれている。

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

図３は、本実施形態におけるサービスアプリケーションのカード発行でのサービスアプリケーション発行システムの動作例を示すシーケンス図である。この図３は、サービスアプリケーションの発行中に通信の遮断がなく、携帯端末５からパーソナライズが完了したことを示すパーソナライズ完了通知を、ＳＰ−ＴＳＭサーバー２が正常に受信した場合を示している。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図４は、本実施形態におけるサービスアプリケーションのカード発行でのサービスアプリケーション発行システムの動作例を示すシーケンス図である。この図４は、サービスアプリケーションの発行中に通信の遮断が発生し、携帯端末５からの発行結果の通知が、ＳＰ−ＴＳＭサーバー２が正常に受信できなかった場合を示している。
図４において、シーケンスＦ１からシーケンスＦ８までは、図３と同様であるため、その説明を省略する。

シーケンスＦ９’：
ＵＩＣＣ５２のＣＰＵは、活性化されたサービスアプリケーションの示す動作に基づき、発行結果の通知を、ＵＩアプリケーションを介して、ＳＰ−ＴＳＭサーバー２に対して送信する。
しかしながら、ＵＩアプリケーションがＳＰ−ＴＳＭサーバー２から発行データを受信した後、携帯端末５との間の通信が遮断され、ＳＰ−ＴＳＭサーバー２は、ＵＩアプリケーションからのパーソナライズ完了通知を受信することができない。このとき、ＳＰ−ＴＳＭサーバー２が発行データを送信しているため、ＳＰ−ＴＳＭサーバー２は、サービスアプリケーション発行テーブルの発行ステータスにより、携帯端末５において発行データによるサービスアプリケーションを活性化する処理が行われている状態と判定する。
このとき、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、送信した発行データに対応するレコードの発行ステータスは、サービスアプリケーションに対応する発行データが発行中の状態になっている。一方、携帯端末５におけるサービスアプリケーションの状態は発行データにより活性化され発行済の状態となっており、利用者データベース２１のサービスアプリケーション発行テーブルにおける状態フラグに対応していない。

シーケンスＦ１３：
サービスアプリケーションは、携帯端末５の通信がオン状態である場合、自身の生存確認のためにＳＰ−ＴＳＭサーバー２に対し、自身の生存を示す通知としてもポーリングを、制御部５１を介して周期的（例えば、８時間毎）に送信する。このポーリングの信号には、ＵＩＣＣ５２のＩＣＣＩＤが含まれている。
ＳＰ−ＴＳＭサーバー２は、携帯端末５からポーリングを受信すると、このポーリングからＵＩＣＣ５２のＩＣＣＩＤを抽出する。そして、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、抽出したＩＣＣＩＤに対応するレコードの発行ステータスを参照する。

このとき、ＳＰ−ＴＳＭサーバー２は、サービスアプリケーション発行テーブルにおいて、抽出したＩＣＣＩＤに対応するレコードの発行ステータスが発行中の場合、発行ステータスを発行中から発行済に変更する。また、ＳＰ−ＴＳＭサーバー２は、サービスアプリケーション発行テーブルにおいて、抽出したＩＣＣＩＤに対応するレコードの発行データを削除する。ここで、本実施形態においてはポーリングで説明しているが、ポーリングでなくとも、生存確認するための信号を、一定期間毎にＳＰ−ＴＳＭサーバー２に送信する機能をサービスアプリケーションに付加する構成としてもよい。

しかしながら、図４の場合には、ＳＰ−ＴＳＭサーバー２から携帯端末５に対して発行データを送信中に、通信が遮断あるいは携帯端末５のバッテリの電池切れが発生し、発行データが携帯端末５が受信できない。
このとき、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、送信した発行データに対応するレコードの発行ステータスは、サービスアプリケーションに対応する発行データが発行中の状態になっている。このため、携帯端末５におけるサービスアプリケーションの状態は発行データが供給されないため発行中の状態となっており、利用者データベース２１のサービスアプリケーション発行テーブルにおける状態フラグに対応している。

上述したように、本実施形態の場合、図４に示すように、ＳＰ−ＴＳＭサーバー２から送信された発行データが携帯端末５に供給されない場合、利用者データベース２１のサービスアプリケーション発行テーブルの状態フラグが発行中となる。このため、ＳＰ−ＴＳＭサーバー２は、携帯端末５から再度アクセスコード及びパスワードが入力されても、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、入力されたアクセスコードに対応するレコードの状態フラグが発行中のため、新たにサービスアプリケーション及び発行データを送信しない。

これにより、本実施形態によれば、発行データが送信された時点において、利用者データベース２１のサービスアプリケーション発行テーブルにおける状態フラグが発行中の状態となるため、従来のように、同一の利用者に対する同一のアクセスコードのサービスアプリケーションが多重に発行され、同一のカード番号等を有するＩＣカードの複製が複数生成されることが無くなる。

図５は、他の実施形態におけるサービスアプリケーションのカード発行でのサービスアプリケーション配信システムの動作例を示すシーケンス図である。この図５は、ＳＰ−ＴＳＭサーバー２がパーソナライズのための発行データを、携帯端末５に対して送信した際に通信の遮断が発生し、ＳＰ−ＴＳＭサーバー２から発行データが携帯端末５に対して正常に送信できなかった場合を示している。
図５において、シーケンスＦ１からシーケンスＦ７までは、図３と同様であるため、その説明を省略する。

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

そして、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルから読み出した発行データを、携帯端末５に対して送信する。このとき、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１におけるサービスアプリケーション発行サーバーにおいて、携帯端末５に対して送信した発行データに対応するレコードの発行ステータスを未発行から発行中に変更する。
しかしながら、ＳＰ−ＴＳＭサーバー２が発行データを携帯端末５に対して送信した際、通信の遮断が発生し、携帯端末５が発行データを受信することができない。この場合、サービスアプリケーションは、ＵＩＣＣ５２にインストールはされているが、活性化されない状態となる。
このため、サービスアプリケーションは、活性化されていないため、ＳＰ−ＴＳＭサーバー２に対してパーソナライズ完了通知を送信しない。また、サービスアプリケーションは、活性化されていないため、ＳＰ−ＴＳＭサーバー２に対してポーリングの通知も送信しない。

したがって、ＳＰ−ＴＳＭサーバー２は、発行データを携帯端末５に対して送信した後、この携帯端末５からサービスアプリケーションの生存（活性化が終了して駆動していること）を確認する信号が入力されない。このとき、サービスアプリケーションがＵＩＣＣ５２にインストールされてはいるが、活性化されていないため、サービスアプリケーションの発行が完了していない。
この場合、ＳＰ−ＴＳＭサーバー２は、発行データを送信してから所定の期間（例えば、一日）が経過した後においても、携帯端末５から生存確認が得られないと、利用者データベース２１のサービスアプリケーション発行テーブルにおける対応するレコードの発行ステータスを発行中から未発行に変更する。これにより、携帯端末５は、ＳＰ−ＴＳＭサーバー２から、再度、発行データの配信を受けることができる。

ここで、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルに対して、それぞれのサービスアプリケーションのレコードにおいて未発行から発行中に変更した際の日時を記述する構成としてもよい。この場合、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルを、周期的（例えば、８時間毎）に参照し、一定期間（例えば、一日）が経過している日時のレコードを検出する。
そして、ＳＰ−ＴＳＭサーバー２は、利用者データベース２１のサービスアプリケーション発行テーブルにおける状態フラグを発行中から未発行に変更する。これにより、携帯端末５からサービスアプリケーションの再度発行が行えるようにし、同一のアクセスコード及びパスワードにより、利用者に対してサービスアプリケーションの再度のインストール及び活性化の処理を可能とする。

上述したように、本実施形態の場合、図５に示すように、ＳＰ−ＴＳＭサーバー２から発行データを携帯端末５に送信することにより、利用者データベース２１のサービスアプリケーション発行テーブルの状態フラグが発行中となる。このため、ＳＰ−ＴＳＭサーバー２は、所定の一定期間が経過するまで、携帯端末５から再度アクセスコード及びパスワードが入力されても、利用者データベース２１のサービスアプリケーション発行テーブルにおいて、入力されたアクセスコードに対応するレコードの状態フラグが発行中のため、新たにサービスアプリケーション及び発行データを送信しない。

これにより、本実施形態によれば、発行データが送信された時点において、利用者データベース２１のサービスアプリケーション発行テーブルにおける状態フラグが発行中の状態となるため、従来のように、同一の利用者に対する同一のアクセスコードのサービスアプリケーションが多重に発行され、同一のカード番号等を有するＩＣカードの複製が複数生成されることが無くなる。
また、本実施形態によれば、発行データを送信してから一定期間に生存確認がされない場合、再度サービスアプリケーションの発行が行えるようにし、同一のアクセスコード及びパスワードにより、利用者に対してサービスアプリケーションの再度のインストールを可能とするため、発行データがＳＰ−ＴＳＭサーバー２から携帯端末５に対して、通常状態等により送信されなかった場合にも対応することができる。

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

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

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

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

２…ＳＰ−ＴＳＭサーバー
３…配信サービスサーバー
４…ＭＮＯ−ＴＳＭサーバー
５…携帯端末
１０＿Ａ…Ａ社サービスセンター
１０＿Ｚ…Ｚ社サービスセンター
２１…利用者データベース
５１…制御部
５２…ＵＩＣＣ
５３…非接触記憶カード
１００…インターネット

Claims (6)

1. 利用者の選択したＩＣカードの動作をエミュレートするサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケーションを活性化する発行データを前記携帯端末に配信する発行データ配信サーバーと、
   前記利用者を識別する識別情報と前記サービスアプリケーションを活性化する当該サービスアプリケーションの発行データと、当該発行データの発行状態を示す発行ステータスとが対応付けられたサービスアプリケーション発行テーブルを記憶する利用者データベースと
   を備え、
   前記発行データ配信サーバーが、前記携帯端末に対してサービスアプリケーションの前記発行データを出力した後、前記利用者データベースにおいて当該発行データに対応する発行ステータスを未発行から発行中とし、前記携帯端末から前記サービスアプリケーションが活性化されたことを示す通知を受信すると、前記発行ステータスを発行中から発行済に変更する
   ことを特徴とするサービスアプリケーション発行装置。
2. 前記発行データ配信サーバーが、前記携帯端末から前記サービスアプリケーションの発行処理が再度依頼された場合、前記発行ステータスが発行中であると、前記サービスアプリケーションの発行処理を行わない
   ことを特徴とする請求項１に記載のサービスアプリケーション発行装置。
3. 前記発行データ配信サーバーが、前記サービスアプリケーションが活性化されたことを示す通知として、前記サービスアプリケーションの生存確認を示す通知のポーリングが前記携帯端末から供給された場合、当該サービスアプリケーションの発行状態を発行中から発行済に変更する
   ことを特徴とする請求項１または請求項２に記載のサービスアプリケーション発行装置。
4. 前記発行データ配信サーバーが、前記サービスアプリケーションの発行状態が未発行から発行中に変更されてから予め設定された所定の期間が経過した時点において、前記発行データの発行ステータスを発行中から未発行に変更する
   ことを特徴とする請求項１または請求項２に記載のサービスアプリケーション発行装置。
5. 発行データ配信サーバーが、利用者の選択したＩＣカードの動作をエミュレートするサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケーションを活性化する発行データを、前記携帯端末に対して出力した後、前記利用者の識別情報と、未発行の前記サービスアプリケーションを活性化する当該サービスアプリケーションの発行データと、サービスアプリケーションの発行状態とが対応付けられたサービスアプリケーション発行テーブルを記憶する利用者データベースにおける前記サービスアプリケーションの前記発行ステータスを未発行から発行中に変更する
   ことを特徴とするサービスアプリケーション発行方法。
6. 利用者の選択したＩＣカードの動作をエミュレートするサービスアプリケーションを、前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーと、
   前記携帯端末に配信されたサービスアプリケーションを活性化する発行データを前記携帯端末に配信する発行データ配信サーバーと、
   前記利用者を識別する識別情報と前記サービスアプリケーションを活性化する当該サービスアプリケーションの発行データと、当該発行データの発行状態を示す発行ステータスとが対応付けられたサービスアプリケーション発行テーブルを記憶する利用者データベースと
   を備え、
   前記発行データ配信サーバーが、前記携帯端末に対してサービスアプリケーションの前記発行データを出力した後、前記利用者データベースにおいて当該発行データに対応する発行ステータスを未発行から発行中とし、前記携帯端末から前記サービスアプリケーションが活性化されたことを示す通知を受信すると、前記発行ステータスを発行中から発行済に変更する
   ことを特徴とするサービスアプリケーション発行システム。

Images