(58)【調査した分野】(Int.Cl.,DB名)
利用者の選択したICカードの動作をエミュレートするサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケーションを活性化する発行データを前記携帯端末に配信する発行データ配信サーバーと、
前記サービスアプリケーションからの問い合わせに対応し、前記携帯端末にインストールされたサービスアプリケーションの稼働及び非稼働を管理する管理サーバーと
を備え、
前記発行データ配信サーバーが前記発行データとしてダミーデータを前記携帯端末に対して発行することで発行済とし、前記管理サーバーが前記問い合わせにおいて前記携帯端末に対して前記発行データが前記サービスアプリケーションに対して未発行である場合、当該携帯端末に対して前記発行データを発行して前記サービスアプリケーションを活性化する
ことを特徴とするサービスアプリケーション発行装置。
携帯端末にインストールされており、利用者の選択したICカードの動作をエミュレートするサービスアプリケーションをサービスアプリケーション発行装置からダウンロードさせ、当該サービスアプリケーションが前記携帯端末にインストールされた後、前記サービスアプリケーション発行装置から前記サービスアプリケーションを活性化する発行データを受信する処理を行うインストーラであり、
前記サービスアプリケーションがイニシャライズされた、当該サービスアプリケーションが発行データにより活性化される際、前記発行データとしてダミーデータを受信して前記サービスアプリケーションの発行処理を一旦終了し、当該サービスアプリケーションの稼働の可否を、前記サービスアプリケーションからの問い合わせに対応し、前記携帯端末にインストールされたサービスアプリケーションの稼働及び非稼働を管理する管理サーバーにアクセスして確認するタイミングにおいて、前記サービスアプリケーションを活性化する発行データを当該管理サーバーから取り込む
ことを特徴とするインストーラ。
前記識別情報を前記携帯端末の記憶部に一旦記憶し、前記管理サーバーにアクセスする際、前記記憶部から前記識別情報を読み出して問い合わせに付加して前記管理サーバーに送信する
ことを特徴とする請求項5に記載のインストーラ。
利用者の選択したICカードの動作をエミュレートするサービスアプリケーションを、サービスプロバイダからダウンロードし、当該サービスアプリケーションのインストールを行うインストーラが実装された携帯端末と、
利用者の選択したICカードの動作をエミュレートするサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケーションを活性化する発行データを前記携帯端末に配信する発行データ配信サーバーと、
前記携帯端末にインストールされた前記サービスアプリケーションからの問い合わせに対応し、前記携帯端末にインストールされたサービスアプリケーションの稼働及び非稼働を管理する管理サーバーと
を備え、
前記発行データ配信サーバーが前記発行データとしてダミーデータを前記携帯端末に対して発行することで発行済とし、前記管理サーバーが前記携帯端末の前記インストーラからの前記問い合わせの際、前記携帯端末の前記サービスアプリケーションに対して前記発行データが未発行である場合、当該携帯端末に対して前記発行データを発行して前記サービスアプリケーションを活性化する
ことを特徴とするサービスアプリケーション発行システム。
発行データ配信サーバーが利用者の選択したICカードの動作をエミュレートするサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケーションを活性化する発行データを前記携帯端末に配信する発行データ配信過程と、
管理サーバーが前記サービスアプリケーションからの問い合わせに対応し、前記携帯端末にインストールされたサービスアプリケーションの稼働及び非稼働を管理する管理過程と
を備え、
前記発行データ配信サーバーが前記発行データとしてダミーデータを前記携帯端末に対して発行することで発行済とし、前記管理サーバーが前記問い合わせにおいて前記携帯端末に対して前記発行データが前記サービスアプリケーションに対して未発行である場合、当該携帯端末に対して前記発行データを発行して前記サービスアプリケーションを活性化する
ことを特徴とするサービスアプリケーション発行方法。
携帯端末にインストールされており、利用者の選択したICカードの動作をエミュレートするサービスアプリケーションをサービスアプリケーション発行装置からダウンロードさせ、当該サービスアプリケーションが前記携帯端末にインストールされた後、前記サービスアプリケーション発行装置から前記サービスアプリケーションを活性化する発行データを受信する処理を行うインストーラによるインストール方法であり、
前記サービスアプリケーションがイニシャライズされた、当該サービスアプリケーションが発行データにより活性化される際、前記発行データとしてダミーデータを受信して前記サービスアプリケーションの発行処理を一旦終了し、当該サービスアプリケーションの稼働の可否を、前記サービスアプリケーションからの問い合わせに対応し、前記携帯端末にインストールされたサービスアプリケーションの稼働及び非稼働を管理する管理サーバーにアクセスして確認するタイミングにおいて、前記サービスアプリケーションを活性化する発行データを当該管理サーバーから取り込む
ことを特徴とするインストール方法。
利用者の選択したICカードの動作をエミュレートするサービスアプリケーションを、サービスプロバイダからダウンロードし、当該サービスアプリケーションのインストールを行うインストーラを携帯端末に実装する過程と、
発行データ配信サーバーが利用者の選択したICカードの動作をエミュレートするサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケーションを活性化する発行データを前記携帯端末に配信する過程と、
管理サーバーが前記携帯端末にインストールされた前記サービスアプリケーションからの問い合わせに対応し、前記携帯端末にインストールされたサービスアプリケーションの稼働及び非稼働を管理する過程と
を含み、
前記発行データ配信サーバーが前記発行データとしてダミーデータを前記携帯端末に対して発行することで発行済とし、前記管理サーバーが前記携帯端末の前記インストーラからの前記問い合わせの際、前記携帯端末の前記サービスアプリケーションに対して前記発行データが未発行である場合、当該携帯端末に対して前記発行データを発行して前記サービスアプリケーションを活性化する
ことを特徴とするサービスアプリケーション発行方法。
【背景技術】
【0002】
近年、スマートフォン等の携帯端末に対してサーバからのデータの送受信を行い、サーバから携帯端末へのコンテンツなどのデータを配信するサービスが行われている。
この携帯端末の利用の発展した形態である、非接触IC(Integrated Circuit、集積回路)カードインターフェースの規格として国際標準化機構(ISO:International Organization Standardization)で規定されたNFC(Near Field Communication)対応の携帯端末がある。このNFC対応の携帯端末の普及により、携帯端末を用いた決済手法として、非接触IC決済サービスを用いたクレジットの利用が増加している(例えば、特許文献1参照)。すなわち、このNFCを用いることにより、クレジットのICカードと同様に、決済サービスのシステムにおけるR/W(Reader/Writer)機器とのデータの送受信が携帯端末でも行える。
【0003】
上述したように、携帯端末を近距離無線通信機能を有するIDカードと同様に決済サービスに適用させる場合、ICカードのエミュレートを行うサービスアプリケーションをインストールする。そして、インストールしたサービスアプリケーションにより、クレジットカードなどのICカードの決済機能を携帯端末に対してエミュレートさせる。
また、今後は、クレジットカードのみではなく、プリペイドカード、ポイントカードあるいは社員証ID(Identification)カードなどのICカードにおいて、これらのエミュレートするサービスアプリケーションのインストールを、NFC対応のスマートフォンなどの携帯端末に対して行うことが予想される。
【0004】
また、上述したNFCの規定を用いたサービスの特徴は、OTA(Over The Air)と呼ばれる無線通信を用いた情報処理技術が利用されている。OTAでは、例えば、無線通信を利用して、携帯電話などの移動体通信端末に対する電話番号や識別情報の書き込みや消去、ファームウェア更新やコンテンツの自動配信、コンテンツのダウンロード販売などが行われる。
従来、IC(Integrated Circuit)カード発行機を用いて行われていたICカード発行処理を、OTAで行うためのシステムが開発されてきている。なお、ICカードの発行処理とは、ICカードのホルダがICカードを利用可能とするための処理であり、次のような0次から2次までの発行処理を含む。
【0005】
すなわち、0次発行ではICカードへの一意の識別子の書き込み処理等が行われ、ICカードが個別化される。1次発行では、ICカードへのアプリケーションのインストール、初期設定等が行われ、ICカードがイニシャライズされる。そして、2次発行では、ICカードにホルダの個人用の設定を行ったり、個人用の情報を書き込んだりするパーソナライズが行われる。
【0006】
図5は、従来のサービスアプリケーション発行システムの構成を示す図である。
この
図5に示すサービスアプリケーション発行システムにおいて、ICカードを携帯端末5上においてエミュレートするためのサービスアプリケーションが、携帯端末5のUICC(Universal Integrated Circuit Card、汎用ICカード)52に、非接触記憶カード53あるいは内蔵メモリ上のUI(User Interface)アプリケーションによりインストールされる。非接触記憶カード53は、例えば、SD(Secure Digital)カード(登録商標)などのフラッシュメモリを用いたメモリカードである。このUICC52としては、例えばSIM(Subscriber Identity Module)カード、UIM(User Identity Module)カードなどがある。UICC52は、例えば、内部にCPU(Central Processing Unit)及びメモリを有しており、活性化された後のサービスアプリケーションのICカードのエミュレートを行う。
A社サービスセンター10_A及びZ社サービスセンター10_Zの各々は、ICカードのサービスを提供する会社のサービスセンターであり、アクセスコード及びパスワードを、サービスを依頼した利用者に対して郵送、あるいは電子メールにより送付する。
【0007】
そして、携帯端末5には、サービスアプリケーションをUICC52に対してインストールする際、サービスアプリケーションをインストールするUIアプリケーションが必要となる。制御部51は、GooglePlay(登録商標)などの配信サービスサーバー3から、UIアプリケーションをダウンロードする。そして、制御部51は、携帯端末5の非接触記憶カード53あるいは内蔵メモリに対し、ダウンロードしたUIアプリケーションをインストールする。MNO(Mobile Network Operator)−TSM(Trusted Service Manager)サーバー4は、携帯端末5に対してサービスアプリケーションの配信を行う。SP(Service Provider)−TSM(Trusted Service Manager)サーバー2’は、利用者の認証、サービスアプリケーションに対する発行データの発行や管理を行う。
【0008】
図6は、従来のサービスアプリケーションのカード発行におけるサービスアプリケーション発行システムの動作例を示すシーケンス図である。
図5及び
図6を参照し、サービスアプリケーションの発行を説明する。
また、このサービスアプリケーションの配信は、MNO−TSMサーバー4が行う。また、利用者の認証、サービスアプリケーションに対する発行データの発行や管理は、SP−TSMサーバー2’が行う(F101、F102)。
すなわち、SP−TSMサーバー2’は、利用者の認証を行い、正しく認証されたと判定すると、正しく認証されたことを示す認証情報を携帯端末5に対して送信する。
【0009】
そして、UIアプリケーションは、認証情報が入力されると、MNO−TSMサーバー4に対して、UICC52に対してサービスアプリケーションの発行におけるイニシャライズを行うことを要求する(F103)。そして、MNO−TSMサーバー4は、サービスアプリケーションをインストールする領域をUICC52内に確保し、確保した領域にサービスアプリケーションをインストールすることで、UICC52に対するイニシャライズを行う(F104)。イニシャライズが終了した後、MNO−TSMサーバー4が、携帯端末5に対してイニシャライズが終了したことを示す発行レスポンスを出力する(F105、F106)。
UIアプリケーションは、発行レスポンスを受信すると、UICC52の識別情報及びサービスプロバイダの識別情報を付加し、パーソナライズの要求をSP−TSMサーバー2’に送信する(F107)。
【0010】
これにより、SP−TSMサーバー2’は、携帯端末5のサービスアプリケーションに対して発行データの発行を行い、携帯端末5にインストールされているサービスアプリケーションを活性化する(F108)。この発行データは、携帯端末5のUICC52にインストールされた所定のICカードをエミュレートするサービスアプリケーションを、所有者に対応して使用可能とする(サービスアプリケーションの活性化を行う)ためのデータ(後述)である。
【0011】
そして、サービスアプリケーションは、TSMProxyを介して、SP−TSMサーバー2’に対して正常にサービスアプリケーションが活性化(パーソナライズ)されたことを示すパーソナライズ完了通知を出力する(F109)。そして、SP−TSMサーバー2’は、サービスアプリケーションのパーソナライズが正常に終了したことを検出し、携帯端末5に対してパーソナライズレスポンスを出力する(F110)。このとき、SP−TSMサーバー2’は、内部のアクセスコードと発行状態を示す発行ステータスとが対応付けられたアプリケーション発行テーブルにおいて、発行ステータスを未発行から発行済に変更する。また、サービスアプリケーションは、MNO−TSMサーバー4に対してICカードの発行が終了したことを示す完了処理リクエストを送信する(F111)。そして、MNO−TSMサーバー4は、発行ステータスを未発行から発行済に変更し、UIアプリケーションに対して完了レスポンスを送信する(F112)。
【発明の概要】
【発明が解決しようとする課題】
【0013】
しかしながら、OTAを使用したICカードの個人データの発行を行い、ICカードのサービス機能を携帯端末にインストールする際、OTAにおける無線通信が不安定となり、インストール処理が途中で終了し、発行エラーが発生する場合がある。また、ICカードを発行するサーバー側の不良により、ICカードの発行が中断する場合がある。
また、UIアプリケーションは、発行リクエストが発行を開始する際の一種類のコマンドしかなく、UICC52におけるICカードの発行完了(パーソナライズ及びイニシャライズの終了)までいずれのサーバーからも発行状況を示す通知が供給されない。
【0014】
このため、発行エラーが発生した際、現在のサービスアプリケーションの発行スキームにおいては、MNO−TSMサーバー4によるサービスアプリケーションのイニシャライズでエラーが発生したのか、あるいはSP−TSMサーバー2’によるサービスアプリケーションのパーソナライズでエラーが発生したのかの判別ができない。
例えば、イニシャライズまでが正常に終了し、パーソナライズにおいてエラーが発生した場合、パーソナライズから発行処理の再開を行えば良い。しかし、サービスアプリケーションのUICC52における発行状態が不明のため、パーソナライズからの再開を行うことができない。そのため、UIアプリケーションは、MNO−TSMサーバー4に対して、UICC52の初期化を要求し、一旦、UICC52のデータを削除した後、イニシャライズから発行処理を行う。
【0015】
上述したように、MNO−TSMサーバー4にUICC52におけるサービスアプリケーションのデータの削除を依頼し、MNO−TSMサーバー4がUICC52のデータを削除する。そして、アプリケーションデータの削除の後に、SP−TSMサーバー2’及びMNO−TSMサーバー4におけるカード発行状態を未発行とする。この後に、MNO−TSMサーバー4再度ICカードの発行のイニシャライズを行うため、再処理を行う際に手間がかかるとともに、時間的なロスが大きくなる。
【0016】
一方、UIアプリケーションに対し、サービスアプリケーションのイニシャライズ及びパーソナライズの各々の発行リクエストを持たせ、イニシャライズ及びパーソナライズの処理を分離して行うことが考えられる。
しかしながら、ICカードの発行中にエラーが発生した場合に、ICカードの発行状態に係わらず、UICC52、SP−TSMサーバー2’及びMNO−TSMサーバー4におけるICカードの発行状態の同期を取るスキームとなっているため、変更することができない。
【0017】
本発明は、このような事情に鑑みてなされたもので、ICカードの発行時にエラーが発生した際、エラーがイニシャライズかパーソナライズかの何れかで発生したかをUIアプリケーションが判別でき、発行状態に応じた再処理を開始することができるサービスアプリケーション発行装置、インストーラ、サービスアプリケーション発行システム、サービスアプリケーション発行方法及びインストール方法を提供することを目的とする。
【課題を解決するための手段】
【0018】
この発明は上述した課題を解決するためになされたもので、本発明のサービスアプリケーション発行装置は、利用者の選択したICカードの動作をエミュレートするサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケ
ーションを活性化する発行データを前記携帯端末に配信する発行データ配信サーバーと、前記サービスアプリケーションからの問い合わせに対応し、前記携帯端末にインストールされたサービスアプリケーションの稼働及び非稼働を管理する管理サーバーとを備え、前記発行データ配信サーバーが前記発行データとしてダミーデータを前記携帯端末に対して発行することで発行済とし、前記管理サーバーが前記問い合わせにおいて前記携帯端末に対して前記発行データが前記サービスアプリケーションに対して未発行である場合、当該携帯端末に対して前記発行データを発行して前記サービスアプリケーションを活性化することを特徴とする。
【0019】
本発明のサービスアプリケーション発行装置は、前記発行データ配信サーバ
ーが前記サービスアプリケーションを前記携帯端末にインストールするイニシャライズを行い、前記管理サーバーが前記携帯端末にインストールされた前記サービスアプリケーションを前記発行データにより活性化するパーソナライズを行う ことを特徴とする。
【0020】
本発明のサービスアプリケーション発行装置は、前記ダミーデータが前記携帯端末にインストールされている前記サービスアプリケーションを識別する識別情報を含んでいることを特徴とする。
【0021】
本発明のインストーラは、携帯端末にインストールされており、利用者の選択したICカードの動作をエミュレートするサービスアプリケーションをサービスアプリケーション発行装置からダウンロードさせ、当該サービスアプリケーションが前記携帯端末にインストールされた後、前記サービスアプリケーション
発行装置から前記サービスアプリケーションを活性化する発行データを受信する処理を行うインストーラであり、前記
サービスアプリケーションがイニシャライズされた、当該サービスアプリケーションが発行データにより活性化される際、前記発行データとしてダミーデータを受信して前記サービスアプリケーションの発行処理を一旦終了し、当該サービスアプリケーションの稼働の可否を、前記サービスアプリケーションからの問い合わせに対応し、前記携帯端末にインストールされたサービスアプリケーションの稼働及び非稼働を管理する管理サーバーにアクセスして確認するタイミングにおいて、前記サービスアプリケーションを活性化する発行データを当該管理サーバーから取り込むことを特徴とする。
【0022】
本発明のインストーラは、前記ダミーデータが前記携帯端末にインストールされている前記サービスアプリケーションを識別する識別情報を含んでいることを特徴とする。
【0023】
本発明のインストーラは、前記識別情報を前記携帯端末の記憶部に一旦記憶し、前記管理サーバーにアクセスする際、前記記憶部から前記識別情報を読み出して問い合わせに付加して前記管理サーバーに送信することを特徴とする。
【0024】
本発明のサービスアプリケーション発行システムは、利用者の選択したICカードの動作をエミュレートするサービスアプリケーションを、サービスプロバイダからダウンロードし、当該サービスアプリケーションのインストールを行うインストーラが実装された携帯端末と、利用者の選択したICカードの動作をエミュレートするサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケ
ーションを活性化する発行データを前記携帯端末に配信する発行データ配信サーバーと、前記携帯端末にインストールされた前記サービスアプリケーションからの問い合わせに対応し、前記携帯端末にインストールされたサービスアプリケーションの稼働及び非稼働を管理する管理サーバーとを備え、前記発行データ配信サーバーが前記発行データとしてダミーデータを前記携帯端末に対して発行することで発行済とし、前記管理サーバーが前記携帯端末の前記インストーラからの前記問い合わせの際、前記携帯端末の前記サービスアプリケーションに対して前記発行データが未発行である場合、当該携帯端末に対して前記発行データを発行して前記サービスアプリケーションを活性化することを特徴とする。
【0025】
本発明のサービスアプリケーション発行システムは、前記発行データ配信サーバ
ーが前記サービスアプリケーションを前記携帯端末にインストールするイニシャライズを行い、前記管理サーバーが前記携帯端末にインストールされた前記サービスアプリケーションを前記発行データにより活性化するパーソナライズを行うことを特徴とする。
【0026】
本発明のサービスアプリケーション発行システムは、前記ダミーデータが前記携帯端末にインストールされている前記サービスアプリケーションを識別する識別情報を含んでいることを特徴とする。
【0027】
本発明のサービスアプリケーション発行方法は、発行データ配信サーバーが利用者の選択したICカードの動作をエミュレートするサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケ
ーションを活性化する発行データを前記携帯端末に配信する発行データ配信過程と、管理サーバーが前記サービスアプリケーションからの問い合わせに対応し、前記携帯端末にインストールされたサービスアプリケーションの稼働及び非稼働を管理する管理過程とを備え、前記発行データ配信サーバーが前記発行データとしてダミーデータを前記携帯端末に対して発行することで発行済とし、前記管理サーバーが前記問い合わせにおいて前記携帯端末に対して前記発行データが前記サービスアプリケーションに対して未発行である場合、当該携帯端末に対して前記発行データを発行して前記サービスアプリケーションを活性化することを特徴とする。
【0028】
本発明のインストール方法は、携帯端末にインストールされており、利用者の選択したICカードの動作をエミュレートするサービスアプリケーションをサービスアプリケーション発行装置からダウンロードさせ、当該サービスアプリケーションが前記携帯端末にインストールされた後、前記サービスアプリケーション
発行装置から前記サービスアプリケーションを活性化する発行データを受信する処理を行うインストーラによるインストール方法であり、前記
サービスアプリケーションがイニシャライズされた、当該サービスアプリケーションが発行データにより活性化される際、前記発行データとしてダミーデータを受信して前記サービスアプリケーションの発行処理を一旦終了し、当該サービスアプリケーションの稼働の可否を、前記サービスアプリケーションからの問い合わせに対応し、前記携帯端末にインストールされたサービスアプリケーションの稼働及び非稼働を管理する管理サーバーにアクセスして確認するタイミングにおいて、前記サービスアプリケーションを活性化する発行データを当該管理サーバーから取り込むことを特徴とする。
【0029】
本発明のサービスアプリケーション発行方法は、利用者の選択したICカードの動作をエミュレートするサービスアプリケーションを、サービスプロバイダからダウンロードし、当該サービスアプリケーションのインストールを行うインストーラを携帯端末に実装する過程と、発行データ配信サーバーが利用者の選択したICカードの動作をエミュレートするサービスアプリケーションを前記利用者の携帯端末に対して配信するサービスアプリケーション配信サーバーから配信された前記サービスアプリケ
ーションを活性化する発行データを前記携帯端末に配信する過程と、管理サーバーが前記携帯端末にインストールされた前記サービスアプリケーションからの問い合わせに対応し、前記携帯端末にインストールされたサービスアプリケーションの稼働及び非稼働を管理する過程とを含み、前記発行データ配信サーバーが前記発行データとしてダミーデータを前記携帯端末に対して発行することで発行済とし、前記管理サーバーが前記携帯端末の前記インストーラからの前記問い合わせの際、前記携帯端末の前記サービスアプリケーションに対して前記発行データが未発行である場合、当該携帯端末に対して前記発行データを発行して前記サービスアプリケーションを活性化することを特徴とする。
【発明の効果】
【0030】
本発明によれば、ICカードの機能をエミュレートするサービスアプリケーションの発行時にエラーが発生した際、サービスアプリケーションの発行における異常(エラー)がパーソナライズかイニシャライズのいずれで発生したかをUIアプリケーションが判別でき、発行状態に応じた再処理を開始することができるサービスアプリケーション発行装置、インストーラ、サービスアプリケーション発行システム、サービスアプリケーション発行方法及びインストール方法を提供することが可能となる。
【発明を実施するための形態】
【0032】
以下、図面を参照して、本発明の実施形態について説明する。
図1は、本発明の一実施形態によるサービスアプリケーション発行システムの構成例を示す概略ブロック図である。この
図1において、サービスアプリケーション発行システムは、SP−TSMサーバー2、配信サービスサーバー3、MNO−TSMサーバー4、携帯端末5、PI(post insurance)サーバー6及び利用者データベース21を備えている。本実施形態において、SP−TSMサーバー2は発行データ配信サーバーの一例であり、MNO−TSMサーバー4はアプリケーション発行サーバーの一例であり、PIサーバー6は管理サーバーの一例である。ここで、SP−TSMサーバー2、利用者データベース21及びMNO−TSMサーバー4の各々の機能を有するアプリケーション発行装置として構成することも可能である。また、従来例と同様の構成には、同一の符号を付してある。
【0033】
SP−TSMサーバー2は、サービスアプリケーションを活性化させる発行データのダミーであるダミーデータを、携帯端末5に送信し、UICC52にインストールされたサービスアプリケーションに対してダミーの発行(疑似パーソナライズ)を行う。この発行データは、各ICカードのサービスを提供するサービスプロバイダにより発行される。また、SP−TSMサーバー2は、後述する利用者データベース21を有し、利用者の認証及び利用者に対する発行データに対応したダミーデータの管理を行っている。しかしながら、本実施形態において、SP−TSMサーバー2は、携帯端末5に対して、上記発行データの代わりにダミーデータを送信する。このダミーデータは、発行データと同一のデータ構成であるが、ユーザのサービスアプリケーションを識別する識別情報以外のデータがダミーの情報に置換されている。ここで、ダミーデータは、発行装置側でパーソナライズが完了したと判定することができるデータを含む。すなわち、ダミーデータは、SP−TSMサーバー2による疑似パーソナライズが完了しているサービスアプリケーションを、PIサーバー6が識別できる識別情報を含んでいる。
【0034】
すなわち、ダミーデータは、携帯端末5のUICC52にインストールされているサービスアプリケーションを識別する識別情報を含んでいる。このサービスアプリケーションの識別情報は、例えば発行データの一部である会員番号を用いたり、あるいはアクセスコード、パスワードなどのユーザのサービスアプリケーションを識別できるものであればいずれの情報を用いても良い。
また、SP−TSMサーバー2は、ダミーデータによりUICC52におけるサービスアプリケーションを偽活性させるとともに、このダミーデータを、携帯端末5における後述するUIアプリケーションの指定する記憶領域に書き込んで記憶させる。
【0035】
SP−TSMサーバー2には、利用者データベース21が接続されている。
利用者データベース21には、アクセスコード及びパスワードと発行ステータスとが対応して記憶されたサービスアプリケーション発行テーブル(後述)が書き込まれて記憶されている。この発行ステータスは、サービスアプリケーションの発行状態を示すステータスであり、サービスアプリケーションが発行されていないことを示す未発行と、サービスアプリケーションの発行が完了したことを示す発行済との2つのステータスがある。
利用者からサービスアプリケーションの発行の申請がなされた際、SP−TSMサーバー2は、利用者データベース21のサービスアプリケーション発行テーブルに対し、この利用者のアクセスコード、パスワード、SP(サービスプロバイダ)コード、サービスコード及び発行ステータスを有するレコードを生成する。また、このレコードには、携帯端末5にインストールされたサービスアプリケーションに対応したダミーデータも含まれている。このとき、SP−TSMサーバー2は、利用者データベース21のサービスアプリケーション発行テーブルにおける新たに作成したレコードの発行ステータスを未発行とする。
【0036】
MNO−TSMサーバー4は、ICカードのサービスを提供する会社のサービスプロバイダ(事業者)が契約したキャリアの保有するサーバーであり、携帯端末5のUICC52にインストールされるサービスアプリケーションを、配信要求を行った携帯端末5に対して供給(配信)する。MNO−TSMサーバー4は、各ICカードのサービスプロバイダから提供されたサービスアプリケーションと、このサービスアプリケーションを識別するサービス識別情報との対応するアプリケーションテーブルを、図示しないデータベースに書き込んで記憶させている。
【0037】
PIサーバー6は、携帯端末5にインストールされたサービスアプリケーションの稼働及び非稼働の管理を行う。すなわち、PIサーバー6は、携帯端末5毎のサービスアプリケーションが不正利用などにより使用不可となっているか否かの検出を行う。携帯端末5にインストールされているサービスアプリケーションは、定期的にPIサーバー6に対してアクセスし、自身のサービスアプリケーションが使用可能な状態であるか否かの検出を行う。ここで、上記サービスアプリケーションは、使用可能な状態でない場合、すなわち使用不可である場合、自身をロックしてICカードのエミュレーションを行わない設定をする。
【0038】
また、本実施形態において、PIサーバー6は、サービスアプリケーションがインストールされ、発行済となった後に携帯端末5において、このサービスアプリケーションから最初にアクセスされて問い合わせを受けた場合、この問い合わせに含まれる識別情報に対応する発行データを、図示しない記憶部に記憶されているサービスアプリケーション発行テーブルから読み出し、問い合わせた携帯端末5に対して送信する。
発行データは、携帯端末5のUICC52にインストールされた所定のICカードをエミュレートするサービスアプリケーションを、所有者に対応して使用可能とするパーソナライズ(活性化)を行うためのデータである。発行データのデータの種類については後述する。
【0039】
図2は、利用者データベース21に記憶されている利用者を管理するサービスアプリケーション発行テーブルの構成例を示す図である。
サービスアプリケーション発行テーブルは、ICCID(UICCの識別情報)、アクセスコード、パスワード、SP(サービスプロバイダ)コード、サービスコード、会員番号(カード会員番号)、利用者の名前(ダミーデータ)、有効期限(ダミーデータ)及び発行ステータスなどを含むレコードとして構成されている。SPコードはサービスプロバイダを識別する情報である。サービスコードは、エミュレートされるICカードのサービスを識別するコードであり、例えば決済ブランド毎に設定されている。
【0040】
アクセスコードは、パスワードとともにサービスアプリケーションの発行を申請した際に利用者に供給される、サービスアプリケーションの発行に用いるデータである。このアクセスコードは、利用者を識別する利用者識別情報である。ダミーデータは、本実施形態においては、ICカードの会員番号と、会員のダミーの名前と、ダミーの有効期限を含む構成として設定されている。発行ステータスは、サービスアプリケーションの発行状態を示している。発行データは、ダミーデータにおける会員の名前及びICカードの有効期限を正しいデータとしたものである。
【0041】
ここで、会員番号は、PAN(Primary Account Number)であり、ICカードのサービスに対応したサービスアプリケーションに与えられる利用者個々の決済ブランド毎における識別番号である。
有効期限は発行されたICカードの使用可能な期間を示し、名前はICカードの使用を申請した利用者の名前である。上述したダミーデータにおける会員の名前及びICカードの有効期限はダミーであり、意味のないあるいは意味があるがサービスに関係ないデータが用いられる。
【0042】
図1に戻り、SP−TSMサーバー2は、利用者の認証処理を行う際、利用者データベース21に記憶されているサービスアプリケーション発行テーブルを参照し、携帯端末5(UIアプリケーション)から供給されるアクセスコード及びパスワードの各々が登録されているか否かの判定を行う。これにより、SP−TSMサーバー2は、アクセスコード及びパスワードがサービスアプリケーション発行テーブルに書き込まれている場合、正常に認証されたとして、正しく認証されたことを示す認証情報を携帯端末5に対して送信する。認証情報には、例えば、サービスアプリケーションを識別するサービスアプリケーション識別情報と、SP−TSMサーバー2のURLなどが含まれている。
【0043】
また、SP−TSMサーバー2は、利用者データベース21のサービスアプリケーション発行テーブルにおいて、サービスアプリケーションの利用者のレコードに対して、事前に、ダミーデータを書き込んで記憶させてある。すなわち、このダミーデータは、サービスプロバイダが利用者に対してアクセスコード及びパスワードが送付される以前に、すなわち、利用者からICカードのサービスの申込みを受け付けた際に、サービスプロバイダからSP−TSMサーバー2を介して、利用者データベース21のサービスアプリケーションテーブルに書き込まれる。
【0044】
そして、SP−TSMサーバー2はサービスアプリケーションに対応するダミーデータの発行により携帯端末5におけるサービスアプリケーションのパーソナライズが正常に行われたと判定し、利用者データベース21のサービスアプリケーション発行テーブルにおいて、対応するレコードの発行ステータスを未発行から発行済に変更する。本実施形態において、SP−TSMサーバー2は、携帯端末5からパーソナライズ完了通知が送信された場合にサービスアプリケーションの発行が正常に行われたと判定する。
【0045】
このとき、携帯端末5は、パーソナライズ完了通知を受信した段階において、実際にはパーソナライズが行われていないため、イニシャライズのみが正常に行われたと判定する。一方、携帯端末5は、発行エラーを受信した段階において、上述したように、実際にはパーソナライズが行われていないため、イニシャライズで異常が発生したと判定する。このように、本実施形態においては、発行エラーの原因がイニシャライズにおける異常か、あるいはパーソナライズにおける異常であるかの判別を可能とする。これにより、本実施形態によれば、イニシャライズが正常に終了していると判定され、パーソナライズが異常に終了した場合、パーソナライズから発行処理を行うことができ、発行エラーにおける再発行の処理に要する時間を短縮することができる。
【0046】
配信サービスサーバー3は、配信要求を行った携帯端末5に対して、UIアプリケーションの配信を行う。配信サービスサーバー3は、携帯端末向けにデジタルコンテンツ(アプリケーション・映画・音楽・書籍など)の配信サービスを行うサーバーであり、例えばGooglePlay(登録商標)などのサイトに設けられたサーバーである。ここで、UIアプリケーションとは、サービスインターフェースを携帯端末5に対してインストールするためのインストーラーであり、MNO−TSMサーバー4に対してサービスアプリケーションの配信と、SP−TSMサーバー2に対して、このサービスアプリケーションを活性化(パーソナライズ)する発行データの配信要求とを行うためのアプリケーションである。
【0047】
MNO−TSMサーバー4は、利用者が契約した携帯端末5の通信会社(キャリア)が管理するサーバーであり、例えば携帯端末5に搭載されているNFC対応のUICC52における記憶部の領域管理を行っている。MNO−TSMサーバー4は、すでに述べたように、サービスアプリケーション識別情報と、このサービスアプリケーション識別情報が識別するサービスアプリケーションとが予め書き込まれたアプリケーションテーブルを有している。また、MNO−TSMサーバー4は、
図2に示すサービスアプリケーション発行テーブルを有している。
【0048】
そして、MNO−TSMサーバー4は、サービスアプリケーションのイニシャライズの処理として、携帯端末5からUICC52に対するイニシャライズが要求されると、SP−TSMサーバー2が利用者の認証を行って登録を認証した携帯端末5のUICC52において、サービスアプリケーションをインストールする領域を確保する。
また、MNO−TSMサーバー4は、確保した領域に対してインストールするサービスアプリケーションを、携帯端末5が送信する認証情報(SP−TSMサーバー2が携帯端末5に送信した認証情報)から抽出したサービスアプリケーション識別情報により、上記アプリケーションテーブルから読み出す。そして、MNO−TSMサーバー4は、読み出したサービスアプリケーションを携帯端末5に対して送信し、UIアプリケーションを介してUICC52にインストールする。
【0049】
携帯端末5は、利用者の各々が保持する端末であり、例えば携帯電話、スマートフォンあるいはタブレット型端末などである。
また、携帯端末5は、制御部51、UICC52及び非接触記憶カード53の各々を備えている。
【0050】
制御部51は、図示しない無線基地局及びインターネット100を用いて外部装置とのデータの送受信を行い、非接触記憶カード53に対してデータの書き込みなどの処理を行う。また、制御部51は、NFCなどの近距離無線通信を用いた送受信機能を有し、R/W機器とのデータの送受信を、ICカードと同様に行う。
非接触記憶カード53は、不揮発性のメモリで構成される記憶部であり、UIアプリケーションやTSMProxyなどがインストールされる。また、このUIアプリケーションやTSMProxyは、非接触記憶カード53ではなく、携帯端末5の内部メモリにインストールされても良い。TSMProxyは、プログラムであり、例えば、携帯端末5が販売される際に、予めインストールされている。
【0051】
UICC52は、固有の識別情報を有するICカードであり、内部に自身の固有の識別情報、携帯端末の加入者情報(携帯端末が携帯電話であれば電話番号など)が記憶されている。この固有の識別情報は、UICC52を識別する識別情報であり、例えばUICC52がSIMカードであれば、IMSI(International Mobile Subscriber Identity)である。また、UICC52には、UIアプリケーションにより、利用者が選択したICカードのサービスの動作をエミュレートするサービスアプリケーションがインストールされる。そして、UICC52は、内部にCPU及びメモリを備えており、サービスアプリケーションにより、ICカードのエミュレートを行う。
【0052】
UIアプリケーションは、サービスアプリケーションの発行処理を行うリクエストをMNO−TSMサーバー4に対して送信し、ICカードの発行処理を開始する。また、UIアプリケーションは、SP−TSMサーバー2が記憶部(例えば、非接触記憶カード53)の所定の領域に書き込んで記憶したダミーデータから識別情報を抽出し、抽出した識別情報を付加して、PIサーバー6に対して、携帯端末5のサービスアプリケーションが使用可能か否かの問い合わせを行う。
【0053】
TSMProxyは、MNO−TSMサーバー4のURL(IPアドレス)を有し、SP−TSMサーバー2及びMNO−TSMサーバー4の各々のURLを切り替えてアクセスを行い、サービスアプリケーションの発行における各要求を行うアプリケーションであるTSMプロキシエージェントの機能を含んでいる。
【0054】
A社サービスセンター10_AからZ社サービスセンター10_Zの各々は、それぞれ携帯端末5により利用可能なサービスを提供する会社のサービスセンターである。利用者から所定のICカードのサービスの利用を受けたいとする申請がなされると、利用者個々を識別するアクセスコードと、利用者毎に異なるパスワードとを郵送などにより、利用者宅に送付する。
【0055】
ここで、A社サービスセンター10_AからZ社サービスセンター10_Zの各々は、アクセスコード及びパスワードの供給を、インターネット100を介した電子メールにより行っても良い。この供給されるアクセスコードには、例えば、利用者を識別する利用者識別情報と、サービスアプリケーションを識別するサービスアプリケーション識別情報となどが含まれている。
【0056】
また、A社からZ社の各々は、SP−TSMサーバー2を介して、利用者からICカードの利用の申請があると、利用者データベース21のサービスアプリケーション発行テーブルに対して、新たなレコードを生成し、ICCID、アクセスコード、パスワード、SPコード、サービスコードを書き込んで記憶させる。この際、SP−TSMサーバー2は、利用者データベース21のサービスアプリケーション発行テーブルに記載された会員番号と、ダミーの名前及び有効期限のダミーデータを生成し、サービスアプリケーション発行テーブルに書き込んで、利用者のサービスアプリケーションの発行状態の管理を行う。
【0057】
図3及び
図4は、本実施形態におけるサービスアプリケーションのカード発行でのサービスアプリケーション発行システムの動作例を示すシーケンス図である。
図3のシーケンスによる処理の前に、利用者は受けたいサービス会社(A社からZ社のいずれか)に対し、ICカードのサービスの申請を行っており、利用者は郵送あるいは電子メールによりアクセスコード及びパスワードを、各サービス会社から受領している。SP−TSMサーバー2においてICCID、アクセスコード、パスワード、SPコード、サービスコード、会員番号、ダミーの名前、ダミーの有効期限及び発行ステータスが、利用者データベース21のサービスアプリケーション発行テーブルにすでに書き込まれている。
【0058】
一方、PIサーバー6においてICCID、アクセスコード、パスワード、SPコード、サービスコード、会員番号、名前、有効期限及び発行ステータスが、図示しないデータベースのサービスアプリケーション発行テーブルにすでに書き込まれている。このアプリケーション発行テーブルは、構成が
図2と同様であり、ダミーデータではなく発行データが書き込まれて記憶されている。ここで、SP−TSMサーバー2及びPIサーバー6の各々において発行ステータスは未発行となっている。以下の説明において、ダミーデータには会員番号が含まれているとして説明する。
【0059】
また、利用者は、UIアプリケーションを配信サービスサーバー3(
図1参照)から、携帯端末5に対してダウンロードしている。このとき、携帯端末5において、制御部51は、ダウンロードしたUIアプリケーションを、非接触記憶カード53あるいは内蔵メモリに対してインストールする。
【0060】
シーケンスF1:
利用者は携帯端末5においてUIアプリケーションを起動させ、図示しない携帯端末5の表示画面に表示されるサービスのアイコンのなかから、すでに申請してある所定のICカードのサービスのアイコンを選択する。
これにより、UIアプリケーションは、例えば、アクセスコード、パスワードなどを入力する入力欄を、携帯端末5の表示画面に対して表示する。
【0061】
次に、利用者は、携帯端末5の表示画面の入力欄に対して図示しない入力手段により、アクセスコード及びパスワードなどを上記入力欄に入力する。
UIアプリケーションは、入力されたアクセスコード、パスワードなどを、UICC52の識別情報(ICCID)及びアクションパラメータ(インストールアクション)とともにSP−TSMサーバー2に対し、制御部51を介して送信して、認証の処理を要求する。
【0062】
シーケンスF2:
SP−TSMサーバー2は、アクションパラメータ(インストールアクション)が入力されることにより、供給されるアクセスコード、パスワードなどにより、利用者データベース21のサービスアプリケーション発行テーブルを参照し、利用者の認証を行う。このとき、SP−TSMサーバー2は、利用者から供給されたアクセスコード、パスワードと、利用者が対応するサービスアプリケーションの利用申請により登録されたサービスアプリケーション発行テーブルに記憶されているアクセスコード、パスワードとが一致するレコードを検出し、この検出したレコードにおける発行ステータスが未発行であるか否かの判定を行う。
【0063】
このとき、SP−TSMサーバー2は、検出したレコードにおける発行ステータスが発行済であれば、処理を終了して、携帯端末5に対して発行済であることを示す通知を行う。一方、SP−TSMサーバー2は、発行ステータスが未発行であれば、以下の処理を行う。
SP−TSMサーバー2は、サービスアプリケーション発行テーブルにおいて、利用者から供給されるアクセスコード、パスワードとが一致するレコードにおける発行ステータスが未発行であることを検出すると、携帯端末5に対して暗号化された認証情報を送信する。このとき、SP−TSMサーバー2は、利用者データベース21のサービスアプリケーション発行テーブルに対して、供給されたICCIDを対応するレコードに書き込んで記憶させる。
【0064】
シーケンスF3:
UIアプリケーションは、SP−TSMサーバー2から認証情報が供給されると、MNO−TSMサーバー4に対して、認証情報を、アクションパラメータ(イニシャライズ)とともに送信する。このとき、UIアプリケーションは、UICC52におけるサービスアプリケーションをインストールする領域の確保、及びサービスアプリケーションをこの確保した領域にインストールするイニシャライズを、MNO−TSMサーバー4に要求する。
【0065】
シーケンスF4:
MNO−TSMサーバー4は、携帯端末5からイニシャライズの要求が供給されると、携帯端末5におけるUICC52の内部のメモリに対し、UIアプリケーションを介して、サービスアプリケーションをインストールする領域を確保する。
そして、MNO−TSMサーバー4は、認証情報からサービスアプリケーション識別情報を抽出し、抽出したサービスアプリケーション識別情報により、このサービスアプリケーション識別情報の示すサービスアプリケーションをアプリケーションテーブルから読み出す。
また、MNO−TSMサーバー4は、UICC52内部のメモリにおける確保した領域に対して、UIアプリケーションを介してサービスアプリケーションのインストールを行う。
【0066】
シーケンスF5:
そして、UICC52は、UIアプリケーションを介し、MNO−TSMサーバー4に対して、サービスアプリケーションのインストールが終了したことを示す発行完了通知を送信する。
このとき、UIアプリケーションは、サービスアプリケーションがUICC52におけるイニシャライズされた所定の領域にインストールされたことを、UICC52のCPUからの通知により判定する。
【0067】
シーケンスF6:
MNO−TSMサーバー4は、携帯端末5から発行完了通知を受信すると、イニシャライズが終了したことを示す発行レスポンスを携帯端末5に対して送信する。
【0068】
シーケンスF7:
UICC52のCPUは、MNO−TSMサーバー4から発行レスポンスが供給されると、SP−TSMサーバー2に対してアクセスする。このとき、TSMProxyは、通信先のURLをMNO−TSMサーバー4からSP−TSMサーバー2に変更する。
そして、UICC52のCPUは、自身の記憶部からICCIDを読み出し、ICCID、認証情報及びアクションパラメータ(パーソナライズアクション)を含む、サービスアプリケーションを活性化する発行データの発行を依頼するパーソナライズリクエストを、SP−TSMサーバー2に対して送信する。
【0069】
シーケンスF8:
SP−TSMサーバー2は、認証情報とともにパーソナライズアクションが供給されると、利用者データベース21のサービスアプリケーション発行テーブルを参照して、携帯端末5から供給されたICCID及びサービスアプリケーション識別情報と一致するICCID及びサービスアプリケーション識別情報が記載されたレコードの有無を確認する。
そして、SP−TSMサーバー2は、利用者データベース21のサービスアプリケーション発行テーブルを参照した結果、ICCID及びサービスアプリケーション識別情報と一致するICCID及びサービスアプリケーション識別情報が記載されたレコードが検出されると、このレコードにおけるダミーデータを読み出す。
【0070】
そして、SP−TSMサーバー2は、利用者データベース21のサービスアプリケーション発行テーブルから読み出したダミーデータを、携帯端末5に対して送信する。
UICC52のCPUは、SP−TSMサーバー2から供給されたダミーデータをUICC52の所定の領域にインストールされているサービスアプリケーションの所定の箇所に書き込み、サービスアプリケーションのダミーの偽活性化(ダミーの偽パーソナライズ)を行う。
このとき、SP−TSMサーバー2は、例えば、携帯端末5の非接触記憶カード53の所定の領域に上記ダミーデータを書き込んでおく。この処理により、UICC52に対するダミーのパーソナライズが終了する。しかしながら、この時点においては、サービスアプリケーションが活性化されておらず、携帯端末5には、受けたいサービスのICカードの動作をエミュレートする機能が付加されず、このサービスアプリケーションの発行が終了していない。
【0071】
シーケンスF9:
UICC52のCPUは、偽活性化されたサービスアプリケーションの示す動作に基づき、正常にサービスプリケーションが活性化されたことを示すパーソナライズ完了通知を、UIアプリケーションを介して、SP−TSMサーバー2に対して送信する。
そして、SP−TSMサーバー2は、このパーソナライズ完了通知を受信することにより、携帯端末5に対するサービスアプリケーションのパーソナライズが正常に行われたと判定する。SP−TSMサーバー2は、利用者データベース21のサービスアプリケーション発行テーブルにおいて、送信した発行データに対応するレコードにおける発行ステータスを未発行から発行済に変更し、ダミーデータを削除する処理を行う。
【0072】
シーケンスF10:
SP−TSMサーバー2は、利用者データベース21におけるサービスアプリケーションのパーソナライズの完了に伴う処理が終了すると、携帯端末5に対して、サービスアプリケーションのパーソナライズにおける処理が完了したことを示す通知であるパーソナライズレスポンスを出力する。
【0073】
シーケンスF11:
UIアプリケーションは、SP−TSMサーバー2からパーソナライズレスポンスを受信すると、MNO−TSMサーバー4に対して、サービスアプリケーションの偽パーソナライズにおける処理が全て完了したことを示す完了処理リクエストを出力する。
これにより、MNO−TSMサーバー4は、自身の有するサービスアプリケーション発行テーブルにおいて、完了リクエストに含まれるICCIDに対応するレコードにおける発行ステータスを未発行から発行中に変更する。
【0074】
シーケンスF12:
MNO−TSMサーバー4は、携帯端末5から完了処理リクエストを受信すると、携帯端末5に対して完了レスポンスを送信する。
これにより、UIアプリケーションは、携帯端末5に対するサービスアプリケーションの発行処理が、ダミーのパーソナライズを含めて全て終了したことを検出する。
【0075】
シーケンスF13:
UICC52にインストールされたサービスアプリケーションは、PIサーバー6に対して、自身が使用可能であるか否かを問い合わせるPIリクエストを発行する。
UIアプリケーションは、ダミーのパーソナライズが終了し、PIリクエストが発行される際、非接触記憶カード53に記憶されているダミーデータから会員番号を読み出す。
そして、UIアプリケーションは、発行されたICカードが使用可能か否かの判定を行うためのPIリクエストに対してこの会員番号を付加し、この会員番号が付加されたPIリクエストをPIサーバ6に対して送信する。
【0076】
シーケンスF14:
PIサーバー6は、携帯端末5からPIリクエストが供給されると、このPIリクエストから会員番号を抽出する。
そして、PIサーバー6は、抽出した会員番号に対応するレコードを、自身のデータベースにおけるサービスアプリケーション発行テーブルから検索する。
PIサーバー6は、サービスアプリケーション発行テーブルにおいて、検索されたレコードにおける発行ステータスが未発行か発行済のいずれであるかの判定を行う。ここで、PIサーバー6は、レコードにおける発行ステータスが未発行である場合、レコードから発行データを読み出して、この発行データを携帯端末5に対して送信する。
【0077】
携帯端末5において、UIアプリケーションは、SP−TSMサーバー2から供給された発行データをUICC52の所定の領域にインストールされているサービスアプリケーションの所定の箇所に書き込み、サービスアプリケーションの活性化(パーソナライズ)を行う。これにより、サービスアプリケーションが活性化され、携帯端末5には、受けたいサービスのICカードの動作をエミュレートする機能が付加され、このサービスアプリケーションの発行が行われる。
【0078】
シーケンスF15:
UIアプリケーションは、活性化されたサービスアプリケーションの示す動作に基づき、正常にサービスプリケーションが活性化されたことを示すパーソナライズ完了の通知を、PIサーバー6に対して送信する。
そして、PIサーバー6は、このパーソナライズ完了の通知を受信することにより、携帯端末5に対するサービスアプリケーションのパーソナライズが正常に行われたと判定する。PIサーバー6は、自身のデータベースのサービスアプリケーション発行テーブルにおいて、送信した発行データに対応するレコードにおける発行ステータスを未発行から発行済に変更し、発行データを削除する処理を行う。
【0079】
シーケンスF16:
PIサーバー6は、自身のデータベースにおけるサービスアプリケーションのパーソナライズの完了に伴う処理が終了すると、サービスアプリケーションのパーソナライズにおける処理が完了したことを示す通知であるPIレスポンスを、携帯端末5に対して出力する。
【0080】
シーケンスF17:
UIアプリケーションは、PIサーバー6からPIレスポンスを受信すると、MNO−TSMサーバー4に対して、サービスアプリケーションのパーソナライズにおける処理が全て完了したことを示す完了処理リクエストを出力する。
これにより、MNO−TSMサーバー4は、自身の有するサービスアプリケーション発行テーブルにおいて、完了処理リクエストに含まれるICCIDに対応するレコードにおける発行ステータスを未発行から発行済に変更する。
【0081】
シーケンスF18:
MNO−TSMサーバー4は、携帯端末5から完了処理リクエストを受信すると、携帯端末5に対して完了レスポンスを送信する。
これにより、UIアプリケーションは、携帯端末5に対するサービスアプリケーションの発行処理が、ダミーのパーソナライズを含めて全て終了したことを検出する。
【0082】
上述したように、本実施形態によれば、パーソナライズ完了通知を受信した段階において、実際にはパーソナライズが行われていないため、UIアプリケーションはパーソナライズ完了通知を受信するとイニシャライズのみが正常に行われたと判定する。一方、UIアプリケーションは、サービスアプリケーションの発行中に発行エラーを受信した場合、上述したように、実際にはパーソナライズが行われていないため、イニシャライズで異常が発生したと判定する。
【0083】
また、本実施形態によれば、PIサーバー6に対するPIリクエストを送信して、実際のパーソナライズの処理のトリガとしているため、PIサーバー6から発行エラーを受信した場合、パーソナライズの処理中に異常が発生したことを検出することができる。
このように、本実施形態においては、発行エラーの原因がイニシャライズにおける異常か、あるいはパーソナライズにおける異常であるかの判別を可能とする。
これにより、本実施形態によれば、サービスアプリケーションの発行中に発生した異常を、イニシャライズ及びパーソナライズのいずれで発生したかを明確に検出することができる。このため、イニシャライズが正常に終了し、かつパーソナライズが異常に終了した場合、パーソナライズから発行処理を行うことができ、発行エラーが発生した場合にイニシャライズから発行をの処理を再開する従来に比較して、発行エラーにおける再発行の処理に要する時間を短縮することができる。
【0084】
また、
図1におけるUIアプリケーション、SP−TSMサーバー2、MNO−TSMサーバー4、PIサーバー6の各々の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによりサービス情報の管理の処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、OSや周辺機器等のハードウェアを含むものとする。
【0085】
また、「コンピュータシステム」は、WWWシステムを利用している場合であれば、ホームページ提供環境(あるいは表示環境)も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【0086】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイルであっても良い。
【0087】
以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。