JPWO2003077173A1 - サービス実行モジュール - Google Patents

Abstract

ＳＥ内に、サービスアイテム登録領域を設け、特定の証明書をもつサービスサーバのみが、ＳＥのサービスアイテム登録領域を用いたサービスを提供することができる。サービスアイテム登録領域のデータを用いた処理を行う場合には、必ず署名付きメッセージの交換を行う。

Description

技術分野
本発明は、セキュアモジュールを用いたサービスの提供方法、そのサービスのひとつとして電子チケットの購入、使用、譲渡など電子バリューを活用するためのシステム、利用方法、プログラム、装置、プログラムを記録した記録媒体に関するものである。
背景技術
セキュアにモバイルサービスを提供するために、携帯電話やＰＤＡにＩＣチップなどのタンパレジスタントなセキュアモジュールであるセキュアエレメント（ＳＥ）を挿入して、安全性を向上する技術がある。携帯電話などに挿入して使うＩＣチップの例としては、従来、たとえばＧＳＭのＳＩＭであれば、オペレータが発行管理をしていた。また、ＷＡＰ（Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）では、ＷＩＭ（ＷＡＰ Ｉｄｅｎｔｉｆｉｅｒ Ｍｏｄｕｌｅ）という署名機能をもったセキュアモジュールの仕様を公開している。このＷＩＭの実装のひとつとして、ＷＩＭをＳＩＭと同一チップ上に実装するＳＷＩＭという形態があり、これもまたオペレータが発行管理を行う見込みである。
ここで、電子チケットサービスに関しては、大きく二つのタイプがある。一つ目は、電子チケット自体に、携帯電話やＰＤＡ、またはそれらに挿入されたＳＥの秘密情報をあらかじめ含めて発行する方式であり、二つ目は、電子チケット自体には、それらデバイスの秘密情報は含まずに発行する方式である（例えば、日本電気株式会社、プレスリリース（２００２年１０月３日）、モバイル向け基盤技術、モバイル電子チケット・会員証サービス基盤、平成１５年１月１４日検索、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｎｅｃ．ｃｏ．ｊｐ／ｐｒｅｓｓ／ｊａ／０２１０／０３０３−０１．ｈｔｍｌ，ｈｔｔｐ：／／ｗｗｗ．ｎｅｃ．ｃｏ．ｊｐ／ｐｒｅｓｓ／ｊａ／０２１０／０３０３−０６．ｈｔｍｌ，ｈｔｔｐ：／／ｗｗｗ．ｎｅｃ．ｃｏ．ｊｐ／ｐｒｅｓｓ／ｊａ／０２１０／０３０３−０７．ｈｔｍｌ＞参照）。
これらの電子チケットサービスの方式の間には、チケットの譲渡および格納の操作に関して大きな違いがある。
まず、譲渡に関しては、前者は、チケットにＳＥ固有の情報を含むため、他人に譲渡する場合、サーバで再発行するなど、サーバ経由の処理が必須であった。それに比べ、後者では、サーバを介さずにオフラインで譲渡が可能である。
次に、格納に関しては、前者の方法であると、チケットにＳＥ固有の情報が含まれており、他人がチケットデータを盗んでもＳＥがなくては改札処理ができないため、ＳＥ持ち主による不正コピーのみを防げばよい。そのため、ＴＲＭに正しいチケットデータのハッシュ値を保存しておき、改札時にチケットと照合するなどといったＳＥ所有者の不正コピーを検出する仕組みを入れることで、チケットデータを暗号化することなく保存できる。後者の方法であると、ＳＥ所有者以外にも使えるため、メモリへチケットを保存する場合には、チケットデータを暗号化する必要があった。
しかしながら、これらには以下のような課題が残る。つまり、第１に、ＳＥなどのタンパレジスタントなモジュールは高価なため、携帯電話やＰＤＡに実装してサービスをしようとする場合、ＳＥ発行のコスト分担が課題となっていた。サービス提供者が発行費用を負担する場合には、費用負担をしていないサービス提供者にはＳＥを使わせないしくみが必要である。また、オペレータ以外であっても、自由にＳＥの発行管理が行えるビジネスモデルが必要である。
第２に、サービス管理者が、サービス提供者にＳＥのアクセスを提供する場合、そのサービスでの役割ごとに、ＳＥへのアクセスを制限しなければいけないという課題があった。例えば、サービス管理者から改札機としての許可を受けているエンティティは、チケットの改札サービスは可能だが、新規チケットの発行は不可能というように、処理の権限を制限するしくみが必要であった。
第３に、ローカルの譲渡が可能な電子チケットでは、他人が不正に使用できないようにするため、ＳＥなどのタンパレジスタント以外のメモリにはチケットデータを暗号化して保存する必要があった。そのため、保存、表示、使用の都度、復号化が必要となり、すべての処理時間について復号化の分だけ余計にかかってしまう。なお、ＳＥなどのタンパレジスタント以外のメモリにはチケットデータを暗号化して保存する必要のない従来の技術として、チケットにＳＥ固有情報を含めて発行する方式がある。しかし、その方式には、譲渡の再、サーバを介して再発行を受ける必要があるという問題点がある。
第４に、チケット発行時に支払い処理の負荷分散を図るために、まずは整理券を配り、支払いをしてからチケットを発行する場合、２種類のデータを発行・管理する必要があった。
第５に、リモートで譲渡の処理をする場合、どんなチケットを譲渡したいのかを相手に伝えるのに、電話、メールやＦＡＸなどでチケットの内容を伝える必要があった。
第６に、セキュアモジュールの高機能化に伴い、サーバ側のシステムを変化させる必要があった。サーバ側は異なる性能のデバイスをサポートできるプロトコルが必要である。
発明の開示
本発明の目的は、セキュアエレメントを用いて、セキュアエレメントへのアクセスを制限する手段をもつセキュアモバイルサービスシステムに用いられるサービス実行モジュールを提供することである。また、本発明の別の目的は、このセキュアモバイルサービスシステムを用いて、スケーラビリティのあるチケットサービスを提供することである。
上記目的を達成するために、本発明では、サービスを実行するための情報を格納したサービス実行モジュールであって、前記モジュールは耐タンパな記憶媒体で構成され、前記サービスを実行するためのアプリケーションを格納したサービスアプリケーション格納手段と、前記サービスを管理するサービス管理者の証明書であるサービス管理者証明書を格納するサービス管理者証明書格納手段と、前記サービスを実行するために必要な情報であるサービスアイテムを格納するサービスアイテム格納手段とを備える。
すなわち、本発明では、第１に、ＳＥにサービス管理者の証明書を格納して販売し、その証明書で署名が検証可能な証明書をもつサービスサーバのみＳＥのそのサービス専用の領域を使ったサービスを提供できるようにした。ＳＥ上に新たなサービス領域を生成する場合にも、そのためのサービス管理者の証明書を用いる。こうすることで、第三者は、このＳＥを用いたサービスを提供することはできないようにすることができる。
上記の構成において、「耐タンパ」とは、ソフトウェア的にもハードウェア（物理）的にもセキュア（安全）性が保証されている仕組みを指し、耐タンパモジュールとは、社会的に使用されているものではＩＣカードがこれに相当する。ソフトウェア的には、正当な保証が行なわれないとＩＣチップの記憶領域内のデータへのソフト的なアクセスを不可能にしてセキュアを達成する。また、ハードウェア的には、ＩＣチップへのハード的なアクセス、例えば、カードを分解して、メモリ領域へ信号線を接続してデータを読み取るといった強引な行為に対して、例えばメモリ内のデータが消去されたり、或いはデータが自動的に破壊されたりして、不正にデータを取得することを不可能にしてセキュアを達成するなどの仕組みをいう。
第２に、ＳＥに通信相手格納領域を設け、証明書に記述されたサービス管理者が認めた役割ごとに、実行できる処理を制限できるようにした。通信の始めに通信相手の証明書を検証し、証明書に指定された役割をＳＥに設けた通信相手格納領域に格納する。ＳＥはＭＥ（携帯電話やＰＤＡなどのモバイルエレメント）から処理要求を受信したときに、この通信相手格納領域の値を参照し、実行可能か判断する。
第３に、ＳＥ内のサービス専用の領域にサービスアイテム登録領域を設けた。さらに、サービスアイテム登録領域のデータを用いたサービスを実行するためには、署名付きのメッセージ交換なしには、サービスが行えないプロトコルとした。
第４に、ＳＥに設けたサービスアイテム登録領域に登録された登録データなしでは、使えない処理プロトコルとした。そのため、例えばチケット処理などにおいては、整理券とチケットデータは同一でよい。支払い処理の後、正しい登録プロトコルを実行し、ＳＥに設けたチケット登録領域（サービスアイテム登録領域）に登録しないとチケットは無効なので、整理券の発行管理は不要となった。
第５に、正しい証明書を持ったＳＥ同士が、ＳＥの署名付きメッセージをやりとりして、ＳＥに設けたチケット登録領域に登録されたチケット以外は使えない処理プロトコルとしたため、譲渡処理より前にチケットデータをメールなどに添付して譲渡相手に送信することが可能となった。相手はこのチケットデータを表示して、全内容を確認してからこのチケットを譲り受けるか決めることができる。
第６に、メッセージ全体を暗号化することのみでセキュリティ確保せず、サービスアイテム登録領域や署名機能を用いて処理を行うプロトコルとした。このため、ＳＥの高速化、大容量化、価格の減少により、ＭＥとの処理分担を変えることで、サービスサーバ側のサービスシステムを変更することなくサポートできる。
発明を実施するための最良の形態
以下、本発明の実施の形態について図面を参照して詳細に説明する。
＜実施の形態１＞
実施の形態１としてＳＥの発行モデルを、実施の形態２としてＳＥとサービスサーバの認証方式を、実施の形態３としてチケットサービスを、実施の形態４として認証と統合したチケットサービスを、実施の形態５として、処理能力の低いＳＥを用いた場合のチケットサービスを順に説明する。この実施の形態１では、図１から図４を用いて、セキュアモバイルサービスシステムにおけるＳＥの発行モデルを説明する。図１は本発明の実施の形態１に係るセキュアモバイルサービスシステムの概略構成をモデル化して示すブロック図である。携帯電話やＰＤＡといったモバイルデバイスＭＥ１００は、ＭＥサービスアプリケーション１０２、署名処理を含む暗号処理機能があるタンパレジスタントなモジュールであるＳＥ１０１、サービスデータ保存領域１０９をもつ。
なお、ＳＥ１０１とサービスデータ保存領域１０９の関係であるが、どちらか／両方が着脱可能であっても、どちらか／両方が複数あっても構わない。また、それらは物理的に同一のメディアに存在していてもしていなくても構わない。
また、それらの間でのデータのやりとりは、ＭＥサービスアプリケーション１０２などの外部を介して送受信しても、１０１と１０９が物理的に同一のメディア内にある場合は、外部を介した送受信を、あるいは外部を介することなく直接送受信をしても構わない。また、本発明においてサービスデータ保存領域１０９はなくても構わない。
ＳＥ１０１は、特定のサービスを実行管理するサービス領域１０３をもつ。ＳＥ１０１は署名のための暗号鍵ペア１０４を格納している。この暗号鍵ペア１０４は、ＳＥ１０１に共通でもよいし、サービス領域１０３に特定でもよい。サービス領域１０３は、このサービス領域１０３のサービスを管理するサービス管理者の証明書であるサービス管理者証明書１０５を格納している。サービス管理者証明書１０５はＳＥ１０１に共通でもサービス領域１０３に特定でもよい。ＳＥ証明書１１０は、ＳＥが特定のサービスを行いたい場合に、サービス管理者１１３から取得する、サービス実行時の認証に必要な証明書である。ＳＥ証明書１１０は不要なサービスもある。
ここで、サービス管理者証明書１０５とＳＥ証明書とサービス領域１０３の関係であるが、サービスの形態によってその組合せは様々である。つまり、ＳＥ所有者が一つのサービスしか登録していない場合は、サービス領域１０３は（後述の領域追加［図３］の可能性を持たない場合は）一つであり、その場合、ＳＥ証明書１１０はなくても構わない。一方、複数のサービスを登録している場合は、サービス領域１０３は複数存在し、１０５と１１０の組合せにより、個々のサービスが特定できる。この場合でも、サービス管理者証明書１０５を発行するサービス管理者が管理するサービスが一つしか存在しない場合は、ＳＥ証明書１１０はなくても構わない。一方、同一のサービス管理者が管理しているサービスでも、サービス管理者証明書１０５をそれぞれ異なるものとしても構わない。
ＳＥサービスアプリケーション１０６は、ＭＥサービスアプリケーション１０２と通信し、サービスサーバ１１１の認証と、各サービスの処理によって定義されたサービスアイテム登録領域１０８へのデータ処理を実行する。サービスアイテム登録領域１０８は、サービス領域１０３に特定の情報を登録しておくための領域である。
通信相手格納領域１０７は、ＳＥサービスアプリケーション１０６がサービスの処理を行う前にサービスサーバの認証を行い、そのサービスサーバの所有するサービスサーバ証明書が証明する値を格納しておく領域である。
ＳＥサービスアプリケーション１０６は、サービスの処理であるサービスアイテム登録領域１０８のデータ操作を行う前にこの通信相手格納領域１０７の値を参照し、処理が許可されているか確認する。
サービス管理者１１３は、このＳＥを発行し、ＳＥ１０１を用いて提供するサービスを管理する。サービスサーバ１１１は、サービス管理者１１３からサービスサーバ証明書１１２を取得し、ＳＥ１０１にサービスを提供する。サービスサーバ１１１とＭＥ１００は、有線でもよいが、無線公衆網、またはＩｒＤＡ、Ｂｌｕｅｔｏｏｔｈなどのローカル無線を用いて無線通信してもよい。サービスサーバ１１１の例としては、ＰＯＳ端末、キオスク端末、自動販売機、ネットワーク上の仮想店舗、改札機、などがある。
このように、ＳＥサービスアプリケーション１０６は、サービスアイテム登録領域１０８にアクセスする前に、認証処理を行ってサービス証明書に証明された権利を格納した通信相手格納領域１０７の値を参照して、合致する場合だけ処理を実行するため、サービス管理者１１３が発行したサービス証明書をもつサービスサーバのみがＳＥ１０１のサービスアイテム格納領域１０８を用いたセキュアなサービスを実行できる。
図２は、サービス管理者１１３が発行するＳＥ１０１のモデル図を示す。サービス管理者は、ＳＥ１０１を発行する。サービス管理者１１３は複数のサービス（２０１、２０２、２０３）を管理することができる。各サービスには、サービス内の役割に応じて複数の種類のサービスサーバ証明書１１２を発行することができる。サービスごとに、ＳＥ１０１内に、各サービス特定のサービス用領域（１０３ａ，１０３ｂ，１０３ｃ）をもつ。複数のサービス用領域（１０３ａ，１０３ｂ，１０３ｃ）をもつＳＥ１０１を発行してもよい。サービス用領域１０３別にサービス管理者証明書１０５を発行してもよい。サービス用領域１０３別にＳＥ証明書１１０を発行してもよい。サービス用領域１０３別に暗号鍵ペア１０４を発行してもよい。サービス管理者証明書１０５および暗号鍵ペア１０４はＳＥ１０１に共通でもよい。また、サービスによっては、ＳＥ証明書１１０はなくてもよい。
このように、ＳＥ１０１上のサービスアイテム登録領域１０８にアクセスできるサービスサーバ１１１を制限する機能を設けることで、サービス管理者１１３がサービスサーバ１１１にサービスサーバ証明書１１２を発行し、サービスサーバ１１１がＳＥ発行管理のコストを共有することが可能となる。
図３は、サービス管理者１１３が発行済みのＳＥ１０１上に、サービス領域１０３を追加するサービスの実施例を示す。サービス管理者１１３ｄは、領域追加サービス３０１と他のサービス（３０２、３０３）を管理しているものとする。サービス管理者１１３ｄは、ＳＥ１０１に領域追加サービス３０１のみを作成して販売しても、領域追加サービス３０１と他の複数のサービス、例えばサービスＦ３０３を追加して販売してもよい。このＳＥ１０１を購入したユーザは、たとえば、ネットワークなどを介してサービス管理者１１３ｄにアクセスし、サービスＥ３０２の申し込みをすると、ＳＥ１０１は、ＳＥ領域追加サービスアプリ１０６ａを介して、領域追加サービス管理者証明書１０５を用いてサービス管理者を認証し、正しければ、新たにサービスＥ用領域１０３ｅを生成する。
このように、ＳＥサービスアプリ１０６の一つとして、サービスを追加するための処理をするアプリ（ＳＥ領域追加サービスアプリ１０６ａ）として、ＳＥ発行時に提供しておけば、サービス管理者１１３は、発行後もネットワークを介してＳＥ１０１上にセキュアにサービス領域１０３を追加作成できる。これにより、サービス管理者はＳＥ１０１の発行をより柔軟に行えるようになる。ユーザも、必要なサービスだけを後から追加できるので、利便性が向上する。また、サービスサーバも、すでにユーザが所有しているＳＥ１０１に、あとから開始したサービスを追加することができるので、市場が広がる。
図４にサービス管理者がチケットサービスの管理を行う場合のモデル図を示す。チケットサービスを提供するサービス管理者１１３ｇは、チケットサービス領域１０３ｇをもつチケットサービス用ＳＥ１０１ｇを発行する。また、チケット発行者向けの発行サーバ証明書１１２ｇ−２と、チケット改札機向けの改札機証明書１１２ｇ−１と、ＳＥ向けのＳＥ証明書１１０ｇの、３種類のサービスサーバ証明書１１２を発行する。ここでＳＥ用とは、ＳＥ間でチケットの移動する処理が可能なＳＥを意味する。ＳＥ間でチケットの移動ができなくてもよい場合には、ＳＥ証明書１１０ｇは発行しなくてよい。
改札機１１１ｇ−１は、サービス管理者１１３ｇから改札機証明書１１２ｇ−１を取得すると、ＳＥ１０１ｇのチケット登録領域１０８ｇに対して、チケットの改札に関連する処理のみ実行できる。発行サーバ１１１ｇ−２は、サービス管理者１１３ｇから発行サーバ証明書１１２ｇ−２を取得すると、ＳＥ１０１ｇのチケット登録領域１０８ｇに対して、新規チケットの発行、チケットの交換、返却、といった処理のみ実行できる。ＳＥ１０１ｇは、サービス管理者１１３ｇからＳＥ証明書１１０ｇを取得すると、ＳＥ証明書１１０ｇを所有するＳＥ１０１ｇとの間で、チケットの移動に関連する処理のみ実行できる。
このように、ＳＥ１０１ｇのチケット登録領域１０８ｇへのアクセスをサービス管理者から発行された発行サーバ証明書１１２ｇ−２、改札機証明書１１２ｇ−１、ＳＥ証明書１１０ｇの所有者のみに制限できる。また、複数の役割にわけてサービスサーバ証明書１１２を発行することで、サービスにおける役割に応じてチケット登録領域１０８ｇへの処理を制限できる。また、サービス管理者１１３ｇは、発行するサービスサーバ証明書１１２の種類により、発行手数料などを変えるといった柔軟な運営が可能となる。
＜実施の形態２＞
実施の形態２では、図５から図９を用いて、ＳＥ１０１とサービスサーバ１１１の認証の仕組みについて説明する。
図５は、ＳＥの認証処理メッセージの例を示す図である。この認証処理メッセージは、大きく分けて、「認証開始」、「認証実行」、「通信終了」の３つからなる。認証実行で、認証に成功したら、通信相手格納領域１０７に、サービスサーバ証明書１１２により証明された権利を格納する。通信終了では、通信相手格納領域１０７の値を削除する。
このように、サービスアイテム登録領域１０８にアクセスするサービス独自の処理と、認証処理をわけることで、複数のサービス領域１０３をもつＳＥ１０１の場合には認証処理を共通化し、無駄のない実装も可能となる。
図６は、ＳＥ１０１がサービスサーバの認証を行う場合のメッセージの例を示す図である。この認証処理動作においては、まず（１）で、ＭＥ１００からＳＥ１０１に認証の開始を要求するメッセージＳｔａｒｔＡｃｃｅｓｓが送信されると、ＳＥ１０１は、（２）で乱数Ｃｈａｌｌｅｎｇｅを生成し、ＭＥ１００に返す。ＭＥ１００は、（３）で乱数Ｃｈａｌｌｅｎｇｅをサービスサーバ１１１に送信する。サービスサーバ１１１は、乱数Ｃｈａｌｌｅｎｇｅに署名をし（Ｓｉｇｎ＿ＳＥｒｖｅｒ（Ｃｈａｌｌｅｎｇｅ））、（４）で上記署名をした乱数（Ｓｉｇｎ＿ＳＥｒｖｅｒ（Ｃｈａｌｌｅｎｇｅ））をサービスサーバ証明書１１２（Ｃｅｒｔ＿ＳＥｒｖｅｒ）とともにＭＥ１００に送る。ＭＥ１００は、（５）で、サービスサーバ１１１から受信したＳｉｇｎ＿ＳＥｒｖｅｒ（Ｃｈａｌｌｅｎｇｅ）とＣｅｒｔ＿ＳＥｒｖｅｒをＳＥ１０１に送信する。Ｓｉｇｎ＿ＳＥｒｖｅｒ（Ｃｈａｌｌｅｎｇｅ）とＣｅｒｔ＿ＳＥｒｖｅｒをＭＥ１００から受信したＳＥ１０１は、サービス管理者証明書１０５を用いてＣｅｒｔ＿ＳＥｒｖｅｒを検証し、Ｃｈａｌｌｅｎｇｅの署名と値を検証し、正しければ、Ｃｅｒｔ＿ＳＥｒｖｅｒに証明されたサービスサーバ１１１の権利を通信相手格納領域１０７に格納する。その後ＳＥ１０１は、（６）において、処理の結果を通知するメッセージをＭＥ１００に送信する。ＭＥ１００は、（７）においてサービスサーバ１１１に認証結果を通知（Ａｃｋ）してもよい。その後、サービス特有の処理を行う。サービスの処理が終了、または、通信の切断があった場合には、ＭＥ１００は、（Ｅ１）においてＳＥ１０１に通信終了のメッセージを送信する。これに対して、ＳＥ１０１は、（Ｅ２）において通信相手格納領域１０７の値を削除して、処理結果をＭＥ１００に返す。
図７は、ＳＥ１０１とサービスサーバ１１１が相互認証を行う場合のメッセージの例を示す図である。
この相互認証処理動作においては、（３）までは、図６と同じである。（４）で、Ｓｉｇｎ＿ＳＥｒｖｅｒ（Ｃｈａｌｌｅｎｇｅ）とＣｅｒｔ＿ＳＥｒｖｅｒに加え、サービスサーバ１１１からＭＥ１００へ乱数Ｃｈａｌｌｅｎｇｅ＿２を送信する。ＭＥ１００は、（５）で、サービスサーバ１１１から受信した乱数Ｃｈａｌｌｅｎｇｅ＿２，Ｓｉｇｎ＿ＳＥｒｖｅｒ（Ｃｈａｌｌｅｎｇｅ）とＣｅｒｔ＿ＳＥｒｖｅｒをＳＥ１０１に送信する。これらのパラメータを受信したＳＥ１０１は、サービス管理者証明書１０５を用いてＣｅｒｔ＿ＳＥｒｖｅｒを検証し、Ｃｈａｌｌｅｎｇｅの署名と値を検証し、正しければ、Ｃｅｒｔ＿ＳＥｒｖｅｒに証明されたサービスサーバ１１１の権利を通信相手格納領域１０７に格納する。加えて、（６）で、乱数Ｃｈａｌｌｅｎｇｅ＿２に署名をして（Ｓｉｇｎ＿ＳＥ（Ｃｈａｌｌｅｎｇｅ＿２））、ＳＥ証明書１１０（Ｃｅｒｔ＿ＳＥ）とともにＭＥ１００に送信する。ＭＥ１００は、これらのパラメータを（７）でサービスサーバ１１１へ送信する。これらのパラメータを（７）で、受信したサービスサーバ１１１は、Ｃｅｒｔ＿ＳＥを検証し、Ｃｈａｌｌｅｎｇｅ＿２の署名と値を検証する。サービスサーバ１１１は、（８）においてＭＥ１００に対して処理結果を通知（Ａｃｋ）してもよい。またＭＥ１００は、（９）においてＳＥ１０１に対して処理結果を通知（Ａｃｋ）してもよい。その後の通信終了処理は図６と同じである。すなわち、サービスの処理が終了、または、通信の切断があった場合には、ＭＥ１００は、（Ｅ１）においてＳＥ１０１に通信終了のメッセージを送信する。これに対して、ＳＥ１０１は、（Ｅ２）において通信相手格納領域１０７の値を削除して、処理結果をＭＥ１００に返す。
図８は、公開鍵暗号を使ったサーバ認証処理のメッセージ例を示す図である。このサーバ認証処理動作においては、まず、サービスサーバ１１１からＭＥ１００を介して、ＳＥ１０１にサービスサーバ証明書１１２（Ｃｅｒｔ＿ＳＥｒｖｅｒ）を送信する（（１）と（２））。ＳＥは、送信されたＣｅｒｔ＿ＳＥｒｖｅｒから取得した公開鍵で、生成した乱数ＣｈａｌｌｅｎｇｅとＳＥ証明書１１０（Ｃｅｒｔ＿ＳＥ）を暗号化し、サービスサーバ１１１に送り返す（（３）と（４））。サービスサーバ１１１は、メッセージを復号化し、Ｃｅｒｔ＿ＳＥから取得したＳＥの公開鍵でＣｈａｌｌｅｎｇｅを暗号化してＭＥ１００を介してＳＥ１０１に送信する（（５）と（６））。ＳＥ１０１は処理の結果を通知してもよい。通信終了処理（（Ｅ１）と（Ｅ２））は図６と同じである。
図９は、公開鍵暗号を使った相互認証処理のメッセージ例を示す図である。この相互認証処理動作においては、（４）のメッセージまでは、図８と同様である。（５）のメッセージで、Ｃｈａｌｌｅｎｇｅと、サービスサーバ１１１からＳＥ１０１への乱数Ｃｈａｌｌｅｎｇｅ＿２に、ＳＥの公開鍵で暗号化して送信する。ＳＥ１０１は、メッセージを復号化し、Ｃｈａｌｌｅｎｇｅを検証し、Ｃｈａｌｌｅｎｇｅ＿２をサービスサーバ１１１の公開鍵で暗号化して送信する（（７）と（８））。通信終了処理（（Ｅ１）と（Ｅ２））は図６と同じである。
このように、サービス管理者１１３が発行したサービスサーバ証明書１１２を用いて、ＳＥ１０１と認証を行うことにより、ＳＥ１０１へのアクセスを制限できる。
＜実施の形態３＞
実施の形態３では、図１０から図２２を用いて、セキュアモバイルサービスシステムを用いたチケットサービスについて説明する。実施例１では、図１０と図１１を用いてチケットデータの説明を、実施例２では、図１２から図１６を用いてチケットダウンロードの説明を、実施例３では、図１７を用いて格納してあるチケットデータの格納を証明する処理の説明を、実施例４では、図１８と図１９を用いてチケット改札処理の説明を、実施例５では、図２０から図２２を用いてチケット移動処理の説明をする。
（実施例１）
図１０と図１１を用いてチケットデータとＳＥ１０１への格納について説明する。まず、図１０を用いてチケットデータについて説明する。チケットデータ１０００（Ｔｉｃｋｅｔ）は、改札必須部１００１（Ｔｉｃｋｅｔ＿Ｖａｒｉａｂｌｅ）、チケット固定部１００４（Ｔｉｃｋｅｔ＿Ｓ）、発行情報部１００５（Ｉｓｓｕｅｒ＿Ｉｎｆｏ）、改札情報部１００６（Ｐｕｎｃｈ＿ｉｎｆｏ）からなっている。各部は共通のチケットＩＤ（ＴｉｃｋｅｔＩＤ）をもつ。改札必須部１００１（Ｔｉｃｋｅｔ＿Ｖａｒｉａｂｌｅ）は、改札必須情報１００２（ＴｉｃｋｅｔＶａｒｉａｂｌｅ）と、それに対する署名１００３からなっている。署名１００３は、ＳＥ１０１の署名でも、改札機１１１ｇ−１の署名でも、発行者１１１ｇ−２の署名でもよい。改札必須部１００１は、チケットＩＤ（ＴｉｃｋｅｔＩＤ）、有効回数（ＶａｌｉｄＴｉｍｅ）、有効期限（ＶａｌｉｄＰｅｒｉｏｄ）、その他の改札に必須な情報（ｏｔｈｅｒＩｎｆｏ）が含まれる。その他の改札に必須な情報（ｏｔｈｅｒＩｎｆｏ）には、例えば、電車切符では、入場駅とその時刻などが入る。このように改札処理に必須な情報は、有効回数・有効期限など時間的な情報や、入場駅・コンサート会場など空間的な情報が、その改札処理の内容に応じて適宜含まれる。
チケットデータ１０００（Ｔｉｃｋｅｔ）において、改札必須部１００１（Ｔｉｃｋｅｔ＿Ｖａｒｉａｂｌｅ）は必須であるが、チケット固定部１００４（Ｔｉｃｋｅｔ＿Ｓ）、発行情報部１００５（Ｉｓｓｕｅｒ＿Ｉｎｆｏ）、改札情報部１００６（Ｐｕｎｃｈ＿ｉｎｆｏ）はなくてもよいし、複数あってもよい。
チケット固定部１００４（Ｔｉｃｋｅｔ＿Ｓ）は、チケトの固定情報（ＴｉｃｋｅｔＳｔａｔｉｃ）に発行サーバ１１１ｇ−２が署名をしたものである。チケットの固定情報（ＴｉｃｋｅｔＳｔａｔｉｃ）には、このチケットに関する情報、ユーザへの表示情報などが含まれる。
発行情報部１００５（Ｉｓｓｕｅｒ＿ｉｎｆｏ）は、追加情報（ａｄｄｉｔｉｏｎａｌＩｎｆｏ）に発行サーバ１１１ｇ−２が署名をしたものである。追加情報（ａｄｄｉｔｉｏｎａｌＩｎｆｏ）には、発行者から発信されるこのチケットへの追加情報、また、このチケットをもつユーザへの他のサービス案内などが含まれる。発行情報部１００５（Ｉｓｓｕｅｒ＿Ｉｎｆｏ）は、発行時にチケットに含まれることもあれば、後から発行者からメールで送信されたり、ユーザがダウンロードすることで追加できる。
改札情報部１００６（Ｐｕｎｃｈ＿ｉｎｆｏ）は、追加情報（ａｄｄｉｔｉｏｎａｌＩｎｆｏ）に改札機１１１ｇ−１が署名をしたものである。追加情報（ａｄｄｉｔｉｏｎａｌＩｎｆｏ）には、改札機からの追加情報、例えば、改札のログ記録だけでなく、コンサートであれば、最新のキャストであるとか、遊園地であれば、各アトラクションの混雑情報などの情報が考えられる。
以上の内容を、以下のように記述する。
チケットデータ：Ｔｉｃｋｅｔ＝Ｔｉｃｋｅｔ＿Ｓ，Ｔｉｃｋｅｔ＿Ｖ，Ｐｕｎｃｈ＿ｉｎｆｏ，Ｉｓｓｕｅｒ＿Ｉｎｆｏチケット固定部：Ｔｉｃｋｅｔ＿Ｓ＝Ｓｉｇｎ＿Ｉｓｓｕｅｒ（ＴｉｃｋｅｔＳｔａｔｉｃ）改札必須部：Ｔｉｃｋｅｔ＿Ｖａｒｉａｂｌｅ＝Ｓｉｇｎ＿Ｉｓｓｕｅｒ（ＴｉｃｋｅｔＶａｒｉａｂｌｅ）またはＳｉｇｎ＿Ｖｅｒｉｆｉｅｒ（ＴｉｃｋｅｔＶａｒｉａｂｌｅ）、またはＳｉｇｎ＿ＳＥ（ＴｉｃｋｅｔＶａｒｉａｂｌｅ）発行情報部：Ｉｓｓｕｅｒ＿Ｉｎｆｏ＝Ｓｉｇｎ＿Ｉｓｓｕｅｒ（ａｄｄｉｔｉｏｎａｌＩｎｆｏ）改札情報部：Ｐｕｎｃｈ＿ｉｎｆｏ＝Ｓｉｇｎ＿ｖｅｒｉｆｉｅｒ（ａｄｄｉｔｉｏｎａｌＩｎｆｏ）改札必須情報：ＴｉｃｋｅｔＶａｒｉａｂｌｅ＝ＴｉｃｋｅｔＩＤ，Ｖａｌｉｄｔｉｍｅ，ＶａｌｉｄＰｅｒｉｏｄ，ｏｔｈｅｒＩｎｆｏ。
このように、チケットデータ１０００は、共通のチケットＩＤをもつ発行サーバ１１１ｇ−２、ＳＥ１０１ｇ、改札機１１１ｇ−１の署名付きデータから成り立っており、増減も柔軟に行える構造になっている。
次に、図１１を用いてチケットデータのＳＥ１０１へ格納について説明する。ＳＥ１０１ｇへチケットデータ１０００（Ｔｉｃｋｅｔ）の格納処理が成功すると、改札必須情報１００２（ＴｉｃｋｅｔＶａｒｉａｂｌｅ）がチケット登録領域（１０８ｇ）に格納され、チケットデータ１０００（Ｔｉｃｋｅｔ）はチケット保存領域１０９ｇに格納される。
このように、改札必須情報１００２（ＴｉｃｋｅｔＶａｒｉａｂｌｅ）をＳＥ１０１のチケット登録領域（１０８ｇ）に格納することで、チケットデータ１０００（Ｔｉｃｋｅｔ）をタンパレジスタントでないメモリ上に格納する場合にも、暗号化する必要がない。理由は、チケット登録領域（１０８ｇ）に格納されていることを証明するメッセージなしには、改札処理はできないので、コピーしたチケットは使えないからである。
そのため、ユーザがチケットデータ１０００（Ｔｉｃｋｅｔ）を自由にコピーしたり、メールに添付して友人に送信することができる。友人にチケットを譲りたいとき、まずチケットをメールなどで送信して友人がデータを見てから実際のチケット移動の処理を行うことができる。
また、チケット発行時も、発行サーバ１１１ｇ−２は、発行情報部１００５（Ｉｓｓｕｅｒ＿Ｉｎｆｏ）に、このチケットは指定された期間内に支払いを済ませると有効になりますという旨の情報と支払いのアクセス先などを含む情報を記載しておく。そして、チケットデータをユーザにメールなどで送信する。このチケットデータ１０００を購入したいユーザは発行情報部１００５（Ｉｓｓｕｅｒ＿Ｉｎｆｏ）に記載された情報どおりに支払い処理を済ませると、ＳＥ１０１のチケット登録領域１０８ｇへの登録処理が実行され、有効なチケットとなる。その登録処理のときには、チケットデータ１０００（Ｔｉｃｋｅｔ）のダウンロードは不要で、登録処理のみを行えばよい。
これにより、発行サーバ１１１ｇ−２は、チケットのプロモーションの自由度が上がる。また、発行サーバ１１１ｇ−２は、支払い前の整理券と支払い後のチケットを別に発行管理する必要がない。
（実施例２）
図１２から図１６を用いてチケットダウンロードを説明する。このチケットダウンロードの前に、注文や購入の処理があってもよい。ＰＵＳＨサービスのようにサーバからアクセスがあってもよい。ダウンロード処理開始の前に、発行サーバ１１１ｇ−２とＭＥ１００ｇでチャレンジ・レスポンスなどによる認証を行ってもよい。実施の形態２に説明した認証方法を用いてもよい。
図１２は、ＳＥ１０１ｇと発行サーバ１１１ｇ−２で行う処理のためのインターフェイスの例を示す図である。大きく３つの機能がある。新規チケットのチケット登録領域１０８ｇへの登録、チケット登録領域１０８ｇへ登録されていることの証明、チケット登録領域１０８ｇへ登録されているチケットの変更である。このうち、チケット登録領域１０８ｇへ登録されているチケットの変更については、実施例３で説明する。
図１３は、新規チケットをダウンロードしてチケット登録領域１０８ｇへ登録する処理のメッセージ例を示している。この図では、実施の形態２に説明した認証処理はすでに成功したことを前提としている。また、発行サーバ１１１ｇ−２とＭＥ間はトランスポート層のセキュア通信路が確保されているものとする。
まず、発行サーバ１１１ｇ−２からＭＥ１００ｇを介してＳＥ１０１ｇにチケットデータ１０００が送信され（（１）と（２））、ＳＥ１０１ｇは、改札必須情報１００２（ＴｉｃｋｅｔＶａｒｉａｂｌｅ）をＳＥ１０１のチケット登録領域（１０８ｇ）に登録する。ＳＥ１０１ｇは登録処理結果を通知してもよい（（３）と（４））。
図１４は、ＳＥ１０１ｇが登録処理結果の通知に、署名付きメッセージを送る例を示す図である。この図では、実施の形態２に説明した認証処理はすでに成功したことを前提としている。また、発行サーバ１１１ｇ−２とＭＥ間はトランスポート層のセキュア通信路が確保されているものとする。
まず、発行サーバ１１１ｇ−２からＭＥ１００ｇを介してＳＥ１０１ｇにチケットデータ１０００と乱数Ｃｈａｌｌｅｎｇｅが送信され（（１）と（２））、ＳＥ１０１ｇは、チケットデータ１０００を検証し、改札必須情報１００２（ＴｉｃｋｅｔＶａｒｉａｂｌｅ）をＳＥ１０１のチケット登録領域（１０８ｇ）に登録する。チケットの検証はＭＥ１００ｇで行ってもよい。ＳＥ１０１ｇは、チケット登録要求に対する応答であるということを示すフラグと、登録した改札必須情報１００２（ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ）と、Ｃｈａｌｌｅｎｇｅに署名をして（Ｓｉｇｎ＿ＳＥ（ＲＥＧＩＳＴＥＲＴＩＣＫＥＴ，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ，Ｃｈａｌｌｅｎｇｅ））、送り返す（（３）と（４））。発行サーバ１１１ｇ−２は、ＳＥの署名を検証し、ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅとＣｈａｌｌｅｎｇｅの値を検証する。ＭＥ１００ｇは、（４）送信後にチケットをチケット保存領域１０９ｇに保存してもよい。
このように、発行サーバ１１１ｇ−２は、ＳＥ１０１ｇに登録された改札必須情報１００２（ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ）を確認することができる。また乱数Ｃｈａｌｌｅｎｇｅが含まれているので、現在の登録情報であることが確認できる。
図１５は、配信鍵を用いたダウンロードメッセージの例を示す図である。この例では、配信鍵（ｋｅｙ＿Ｄｅｌｉｖｅｒ）でチケットデータ１０００を暗号化し、配信鍵（ｋｅｙ＿Ｄｅｌｉｖｅｒ）をＳＥ１０１の公開鍵１０４ｄで暗号化して、発行サーバ１１１ｇ−２からＳＥ１０１にダウンロードする（（１）と（２））。ＳＥ１０１ｇは、配信鍵を復号化してから、チケットデータ１０００を復号化して、チケットの検証を行ってから、改札必須情報１００２（ＴｉｃｋｅｔＶａｒｉａｂｌｅ）をＳＥ１０１のチケット登録領域（１０８ｇ）に登録する（（３））。（４）で、ＭＥ１００ｇは、ＳＥ１０１ｇから復号化したチケットを受け取ると、チケットをチケット保存領域１０９ｇに保存する。
図１６は、公開鍵暗号を用いたダウンロードメッセージの例を示す図である。この例では、まず、ＭＥ１００ｇから発行サーバ１１１ｇ−２にＳＥ証明書１１０ｇを送信する（０）。発行サーバ１１１ｇ−２は、乱数Ｃｈａｌｌｅｎｇｅとチケットデータ１０００をＳＥ１０１の公開鍵で暗号化して送信する（（１）と（２））。
（実施例３）
図１７を用いて、チケット登録領域１０８ｇに登録してあるチケットデータを証明する処理を説明する。図１７では、発行サーバ１１１ｇ−２が、ＳＥから通信エラーなどにより登録処理に失敗したことなどによるチケットの再登録要求を受信したときに、ほんとうにチケット登録領域１０８ｇに登録されていないのか確認する処理を示す。ＳＥ１０１ｇは、発行サーバ１１１ｇ−２からチケットＩＤとＣｈａｌｌｅｎｇｅを受信し（（１）と（２））、チケット登録領域１０８ｇから対応するチケットＩＤを検索し、登録されていれば、現在の登録データ（ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ）と、Ｃｈａｌｌｅｎｇｅと、登録証明要求に応答するメッセージであることを示すフラグに署名をして（Ｓｉｇｎ＿ＳＥ（ＰＲＯＶＥＴＩＣＫＥＴ，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ，Ｃｈａｌｌｅｎｇｅ））、発行サーバ１１１ｇ−２に送信する（（３）と（４））。発行サーバ１１１ｇ−２は、署名を検証し、ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅとＣｈａｌｌｅｎｇｅの値を検証する。
このように、この機能を用いることで、発行サーバ１１１ｇ−２は、ＳＥ１０１ｇから再登録要求が来た場合にも本当に登録に失敗したのか確認できる。また、この機能があるため、発行時のダウンロード処理では、図１４に示すメッセージ（３）と（４）は省略して高速化することができる。
発行サーバ１１１ｇ−２だけでなく、改札機１１１ｇ−１も、サポートするするチケットがあるか確認したいときに使用することができる。
この例では、チケットＩＤを指定したが、チケットＩＤをパターンマッチ指定して一度に複数の登録証明を取得することも考えられる。
また、この例では、現在の登録データ（ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ）と、Ｃｈａｌｌｅｎｇｅと、登録証明要求に応答するメッセージであることを示すフラグに署名をして返すが、チケットＩＤのみ、またはチケットＩＤとＣｈａｌｌｅｎｇｅのみなどといったことも考えられる。
また、サービスサーバ１１１の種類によってデータの種類が変わることも考えられる。例えば、発行サーバ１１１ｇ−２には、現在の登録データ（ＣｕｒｒｅｎｔＴｉｅｋｅｔＶａｒｉａｂｌｅ）と、Ｃｈａｌｌｅｎｇｅと、登録証明要求に応答するメッセージであることを示すフラグに署名をして返し、改札機には、チケットＩＤとＣｈａｌｌｅｎｇｅと登録証明要求に応答するメッセージであることを示すフラグに署名をして返すことも考えられる。署名データには、登録証明要求に応答するメッセージであることを示すフラグが含まれているので、他の処理には用いることができない。
この機能により、サービスサーバ１１１は、サービスアイテム登録領域１０８ｇに登録されている内容を変えることなく、現在の登録データを知ることができる。
（実施例４）
図１８と図１９を用いてチケット改札処理を説明する。図１８はチケット改札処理のメッセージの例を示す図である。この例では、まず、改札機１１１ｇ−１は、改札命令（Ｐｕｎｃｈ＿Ｏｒｄｅｒ）を生成する。改札命令（Ｐｕｎｃｈ＿Ｏｒｄｅｒ）は、ＰｕｎｃｈＯｒｄｅｒに改札機１１ｇ−１の署名をつけたデータである。ここでは、ＰｕｎｃｈＯｒｄｅｒは、改札後の改札必須情報の値（ＵｐｄａｔｅｄＴｉｃｋｅｔＶａｒｉａｂｌｅ）を指定するものとする。この他にも、増減する料を指定する方法も考えられる。
まず、改札機１１１ｇ−１は、改札命令（Ｐｕｎｃｈ＿Ｏｒｄｅｒ）と乱数Ｃｈａｌｌｅｎｇｅと改札情報部１００６（Ｐｕｎｃｈ＿Ｉｎｆｏ）をＭＥ１００ｇに送信する（（１））。ＭＥ１０１ｇは改札情報部１００６をＳＥ１０１ｇに送らなくてもよい。ＳＥ１０１ｇは、（２）で受信した改札命令（Ｐｕｎｃｈ＿Ｏｒｄｅｒ）の署名を検証し、改札命令（Ｐｕｎｃｈ＿Ｏｒｄｅｒ）で指定された通りにチケット登録領域１０８ｇに登録してある対応するデータを更新する。ＳＥ１０１ｇは、更新後のチケット登録領域に登録されたデータ（ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ）と、乱数Ｃｈａｌｌｅｎｇｅと、変更要求に応答するメッセージであるということを示すフラグに署名したデータ（Ｓｉｇｎ＿ＳＥ（ＶＥＲＩＦＹＴＩＣＫＥＴ，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ，Ｃｈａｌｌｅｎｇｅ））と、乱数Ｃｈａｌｌｅｎｇｅ＿２を改札機１１１ｇ−１に送信する（（３）と（４））。改札機１１１ｇ−１は、署名を検証し、ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅとＣｈａｌｌｅｎｇｅの値を検証し、乱数Ｃｈａｌｌｅｎｇｅ＿２とＰｕｎｃｈＯｒｄｅｒと変更要求に応答するメッセージに確認するメッセージであるというフラグに署名してＳＥ１０１ｇに返す（（５）と（６））。ここで、ＰｕｎｃｈＯｒｄｅｒはふくめなくてもよい。また、変更要求に応答するメッセージに確認するメッセージであるというフラグは含めなくてもよい。また、（３）と（４）において、Ｃｈａｌｌｅｎｇｅ＿２はなくてもよい。この場合、（５）と（６）はなくてもよい。
図１９に改札処理の前と後のチケットの格納モデルを説明する。この例では、まず、改札前の状態として、チケット登録領域１０８ｇに改札必須情報部１００２ａが登録されており、チケット保存領域１０９ｇに、チケットデータ１０００の一部として、チケット固定部１００４と改札情報必須部１００３ａと発行情報部１００５が格納されている。登録されているチケットデータ１０００は、改札情報必須部１００３を持たなくてもよいし、発行時のまま保持していてもいいし、登録更新ごとに、ＳＥ１０１ｇの署名データに置き換えてもよいし、改札機１１１ｇ−１から送信されたＰｕｎｃｈ−ｏｒｄｅｒに置き換えても良い。ユーザにチケットデータ１０００の状態を表示するには、チケット登録領域１０８ｇの情報を提供するのが望ましい。この例では、改札後に、チケット登録領域１０８ｇに改札必須情報部１００２ｂが更新されると、改札情報必須部１００３ｂも、更新されている。そして新たに改札情報部１００６（Ｐｕｎｃｈ＿Ｉｎｆｏ）が追加されている。一度の改札で、複数の改札情報部１００６（Ｐｕｎｃｈ＿Ｉｎｆｏ）が追加されることも考えられる。
（実施例５）
図２０から図２２を用いてＳＥ間でチケットを移動する処理の説明をする。この処理動作では、ひとつのチケット全体（有効な価値すべて）を移動するほかに、例えば回数券だったら、残り有効回数のうちｎ回を移動、といった処理も可能である。
図２０は、ＳＥ間のチケット移動処理のＳＥのメッセージの例を示す図である。大きく２つあり、一つ目は他のＳＥから移動されたチケットの登録、２つ目は、他のＳＥへ移動したチケットの削除（または更新）である。
図２１は、ＳＥ間でチケットが移動するメッセージの例を示す図である。図２１において、チケットの登録元のＭＥをＭＥ１（１００ｇ−１）、チケットの移動先のＭＥをＭＥ２（１００ｇ−２）とする。同様にチケットの登録元のＳＥをＳＥ１（１０１ｇ−１）、チケットの移動先のＳＥをＳＥ２（１０１ｇ−２）とする。また、図２１では、ＳＥ間の相互認証は成功したものとする。
まず、ユーザが移動するチケットを指定し、移動処理の確認操作をすると、ＭＥ１（１００ｇ−１）は、移動させるサービスアイテムＭｏｖｅＯｆｆｅｒを生成する。ここでは、ＭｏｖｅＯｆｆｅｒは、チケット移動先のチケット登録領域１０８ｇに登録される改札必須情報（ＭｏｖｅｄＴｉｃｋｅｔＶａｒｉａｂｌｅ）とする。他にも、ＳＥ１に残す改札必須情報（ＴｉｃｋｅｔＶａｒｉａｂｌｅ）の値を指定する方法なども考えられる。ＭｏｖｅＯｆｆｅｒには、チケットＩＤが含まれる。ＳＥ１は、（１）でＭｏｖｅＯｆｆｅｒを受け取ると、ＭｏｖｅＯｆｆｅｒに指定されたサービスアイテムを、チケット登録領域１０８ｇに登録されている改札必須情報（ＴｉｃｋｅｔＶａｒｉａｂｌｅ）から移動する。ＭｏｖｅＯｆｆｅｒの値が現在の改札必須情報（ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ）に等しい場合、チケット登録領域１０８ｇから削除してもよい。ＳＥ１は、ＭｏｖｅＯｆｆｅｒ通りにチケット登録領域１０８ｇに登録されている改札必須情報（ＴｉｃｋｅｔＶａｒｉａｂｌｅ）を移動したことを示すメッセージとして、ＭｏｖｅＯｆｆｅｒと、乱数Ｃｈａｌｌｅｎｇｅと移動した処理を示すメッセージであるということを示すフラグに署名をして（Ｓｉｇｎ＿ＳＥ（ＭＯＶＥＯＵＴＴＩＣＫＥＴ，ＭｏｖｅＯｆｆｅｒ））、ＳＥ２に送信する（（２）と（３）と（４））。続いて、ＳＥ２は署名を検証し、ＭｏｖｅＯｆｆｅｒに指定されたとおりにＳＥ２のチケット登録領域１０８ｇに登録する。そして、登録した改札必須情報とＣｈａｌｌｅｎｇｅと移動処理に応答するメッセージであること示すフラグに署名した（Ｓｉｇｎ＿ＳＥ（ＭＯＶＥＩＮＴＩＣＫＥＴ，ｃｕｒｒｅｎｔ＿ＴｉｃｋｅｔＶａｒｉａｂｌｅ，Ｃｈａｌｌｅｎｇｅ））ものと乱数Ｃｈａｌｌｅｎｇｅ＿２をＳＥ１に返す（（５）と（６）と（７））。ＳＥ１は、署名を検証し、ｃｕｒｒｅｎｔ＿ＴｉｃｋｅｔＶａｒｉａｂｌｅとＣｈａｌｌｅｎｇｅの値を検証し、正しかったら、Ｃｈａｌｌｅｎｇｅ＿２に署名をしてＳＥ２に返す（（８）と（９）と（１０））。
ＳＥ１は、（７）がないと移動処理を完了できず、移動処理はキャンセルされ、もとに戻る。ＳＥ２は、（１０）がないと、移動処理を完了できず、移動処理はキャンセルされ、もとに戻る。
このように、移動元のＳＥ１０１が、登録されている価値から移動する価値情報を減らしてから、すでに移動したことを証明するデータ（例えば、移動したサービスアイテムに署名をつける）を移動先に送信し、移動先のＳＥはそのすでに移動したことを証明するデータに基づいて、登録処理を行い、登録したことを証明するデータ（例えば、登録した内容に署名をつける）を移動元のＳＥに送り返すことで、移動元のＳＥは移動処理を完了できる。また、移動元のＳＥの移動処理完了を証明するデータを受信すると、移動先のＳＥも処理を完了する。
この結果、ＳＥ１とＳＥ２の２つともに同時にサービスアイテムが存在することなく、ＳＥ間のサービスアイテムの移動が可能となる。
図２２に公開鍵暗号方式を用いた譲渡処理動作のモデル図を示す。この処理動作では、メッセージの内容は、図２１とほぼ同じだが、メッセージを公開鍵暗号で暗号化して通信している。
＜実施の形態４＞
実施の形態４では、図２３から図２５を用いて、認証処理とチケットサービス独自の処理のメッセージを結合した実施例を示す。図２３は、サーバ認証とチケットダウンロード処理の混合処理のメッセージ例を示す図である。この図は、図６と図１３を結合したメッセージの例を示すもので、図２３の（４）、（５）、（６）において、図６の（４）、（５）、（６）と図１３の（１）、（２）、（３）を統合した。また、図２３の（４）において、チケットデータ１０００の改札必須部１００１にＣｈａｌｌｅｎｇｅを含めて発行することで、ＳＥ１０１ｇでＣｈａｌｌｅｎｇｅを受信した先から来たチケットであるという検証ができる。図２３の（５）のメッセージは、チケットデータ１０００を送っても、改札必須部１００１のみを送信してもよい。
これにより、サーバ認証とチケットのダウンロード処理を別々に行うより、セキュリティを保ったまま、処理を効率的に行えるようになった。
図２４は、サーバ認証とチケット改札処理の混合処理のメッセージ例を示す図である。この図は、図６と図１８を結合したメッセージ例で、図２４の（４）、（５）、（６）において、図６の（４）、（５）、（６）と図１８の（１）、（２）、（３）を統合した。図２４の（４）において、Ｐｕｎｃｈ＿ＯｒｄｅｒにＣｈａｌｌｅｎｇｅ＿０を含めて発行することで、ＳＥ１０１ｇでＣｈａｌｌｅｎｇｅを受信した先から来た更新要求であるという検証ができる。
これにより、サーバ認証とチケットの改札処理を別々に行うより、セキュリティを保ったまま、処理を効率的に行えるようになった。
図２５は、相互認証とＳＥ間のチケット移動処理の混合メッセージの例を示す図である。この図は、図７と図２１を結合したメッセージ例を示しており、図７の（４）から、図６の（４）と図１８の（１）を統合した。図２５では、ＳＥ証明書１１０を（２）で送信しているが、（８）で送信してもよい。
この図では、移動先のユーザが移動処理開始の操作をすると移動処理用の認証処理が移動元のＭＥ１に、送信され、そこで移動元のユーザが移動処理開始操作を行うことで、処理が続行する例を示している。
図２５の（４）において、Ｍｏｖｅ＿ＯｆｆｅｒにＣｈａｌｌｅｎｇｅ＿０を含めて発行することで、ＳＥ１０１ｇでＣｈａｌｌｅｎｇｅを受信したＳＥから来た移動済み証明であるという検証ができる。これにより、サーバ認証とチケットの移動処理を別々に行うより、セキュリティを保ったまま、処理を効率的に行えるようになった。
以上のように、署名とＣｈａｌｌｅｎｇｅを用いたメッセージを交換しあうことで、認証を行うと同時にメッセージデータの再利用防止し、署名付きメッセージで否認を防止することもできる。その結果、より少ないメッセージでもセキュアに処理を行うことが出来る。
＜実施の形態５＞
実施の形態５では、図２６から図２８を用いて、処理能力の低いＳＥを用いた実施例を示す。図２６から図２８は、それぞれ図２３から図２５のメッセージ例に対応する。
処理能力が高く、安いＳＥが普及するまでは、それほど処理能力の高くないＳＥを使わなければいけない。そのため、ＳＥで行うべき処理をＭＥで肩代わりし、最低限守るべき処理のみをＳＥで行う実施例を以下に示す。市場に、処理能力の高くないＳＥと高性能なＳＥが混在しても、サービスサーバのインターフェイスが共通であることが望ましい。
この実施の形態では、証明書の検証、署名の検証はＭＥで行い、Ｃｈａｌｌｅｎｇｅの検証、チケット登録領域へのアクセスはＳＥで行う例を示す。図２６は、図２３に相当するダウンロード処理の例を示す図である。この図２６では、ＭＥ１００ｇで、発行サーバ証明書１１２ｇ−２の検証、チケットの検証を行っている。
図２７は、図２４に相当する改札処理のメッセージ例を示す図である。この図２７では、ＭＥ１００ｇで、改札機証明書１１２ｇ−１の検証、Ｐｕｎｃｈ＿Ｏｒｄｅｒの検証を行っている。
図２８は、図２５に相当するＳＥ間のチケット移動処理のメッセージ例を示す図である。この図２８では、同様に、譲渡元と譲渡先のＭＥ１００ｇで、証明書の検証とメッセージ署名の検証を行っている。これにより、処理能力が高いＳＥが普及するまでは、ＳＥの処理をＭＥで実行し、処理能力の高いＳＥが普及していく移行期には、多様な性能なＳＥが混在するが、サービスサーバ側のインターフェイスは変えずに対応することができる。
＜実施の形態６＞
実施の形態６では、図２９から図３１を用いて、通信路のトランスポート層の暗号化がない場合におけるチケット処理を説明する。通信路の暗号化がないと、乱数が盗み見され、成りすましが可能となる。そこで、乱数のみ公開鍵暗号を用いて送信する例について説明する。このほかに、共通鍵を用いることも考えられる。
図２９を用いてチケットのダウンロード処理について説明する。まず、発行サーバ１１１ｇ−２からＳＥ１０１ｇに、発行サーバ証明書１１２ｇ−２を送信する（（１）と（２））。ＳＥ１０１ｇは、送信された証明書を検証し、正しい発行サーバ証明書だった場合、通信相手格納領域に登録する。また、乱数Ｃｈａｌｌｅｎｇｅを生成し、発行サーバの公開鍵で暗号化し（Ｅｎｃｒｙｐｔ＿Ｉｓｓｕｅｒ｛Ｃｈａｌｌｅｎｇｅ｝）、送り返す（（３）と（４））。
発行サーバ１１１ｇ＿２は、Ｅｎｃｒｙｐｔ＿Ｉｓｓｕｅｒ｛Ｃｈａｌｌｅｎｇｅ｝を復号化し、Ｃｈａｌｌｅｎｇｅを取り出す。改札必須情報１００２にＣｈａｌｌｅｎｇｅを含め、発行サーバの署名をつけて、チケットの改札必須部１００３（Ｔｉｃｋｅｔ＿Ｖ）を生成する。あらかじめ生成しておいたチケットの他の部分と合わせてチケットデータ１０００（Ｔｉｃｋｅｔ）とし、送信する（（５）と（６））。ＭＥはＴｉｃｋｅｔをそのままＳＥにおくってもよい。チケットデータ１０００の改札必須部１００３のみ送ってもよい。
ＳＥは、改札必須部１００３の署名を検証し、正しければ、ＴｉｃｋｅｔＶａｒｉａｂｌｅの値をチケット登録領域１０８ｇに登録する。処理が成功した場合、処理成功通知を発行サーバに送る（（７）と（８））。（７）と（８）は署名付きデータでもよい。（７）と（８）は、現在登録されている改札必須情報を証明するＳＥの署名付きデータでもよい。
このように、乱数を送信時に暗号化するだけで、メッセージ全体を暗号化しなくても、チケットのダウンロードがセキュアに行えるようになる。
図３０を用いてチケットの改札処理について説明する。まず、改札機１１１ｇ−１からＳＥ１０１ｇに、改札機証明書１１２ｇ−１を送信する（１）。ＭＥは、改札するチケットのチケットＩＤと、改札機証明書１１２ｇ−１を送信する（２）。チケットＩＤは、改札機１１１ｇ−１から送信されてもよいし、ユーザ操作によりＭＥで付加してもよい。
ＳＥ１０１ｇは、送信された証明書を検証し、正しい改札機証明書だった場合、通信相手格納領域に登録する。また、乱数Ｃｈａｌｌｅｎｇｅ＿０を生成し、改札機の公開鍵で暗号化する（Ｅｎｃｒｙｐｔ＿Ｖｅｒｉｆｉｅｒ｛Ｃｈａｌｌｅｎｇｅ＿０｝）。ＳＥは、指定されたチケットＩＤに対応するチケット登録領域に登録されたチケット情報（ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ）と、ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅで指定されたチケットを発行サーバに提示するメッセージであることを示すフラグとを含むデータに署名をする（Ｓｉｇｎ＿ＳＥ（ＳＨＯＷＴＩＣＫＥＴ，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ））。
また、Ｅｎｃｒｙｐｔ＿Ｖｅｒｉｆｉｅｒ｛Ｃｈａｌｌｅｎｇｅ＿０｝とＳｉｇｎ＿ＳＥ（ＳＨＯＷＴＩＣＫＥＴ，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ）とＳＥ証明書をとともに送り返す（（３）と（４））。ここで、ＳＥ証明書は、ＳＥ公開鍵でもよい。
改札機１１１ｇ−１は、Ｅｎｃｒｙｐｔ＿ＳＥ（Ｃｈａｌｌｅｎｇｅ＿０）を復号化してＣｈａｌｌｅｎｇｅ＿０をとりだす。また、Ｓｉｇｎ＿ＳＥ（ＳＨＯＷＴＩＣＫＥＴ，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ）の署名を検証し、使用可能なチケットかどうか判断する。使用可能な場合、Ｐｕｎｃｈ＿Ｏｒｄｅｒを生成する。Ｐｕｎｃｈ＿Ｏｒｄｅｒは、ＰｕｎｃｈＯｒｄｅｒに改札機の署名をつけたものだが、この実施例では、チケットＩＤや、改札後の例えば有効期限や残り回数などの値である情報に加えて、Ｃｈａｌｌｅｎｇｅ＿０を含めたデータに改札機の署名をしたものを意味する。ここでは、ＰｕｎｃｈＯｒｄｅｒは、改札後のチケットの改札必須情報を指定する。改札後また、必要であれば、Ｐｕｎｃｈ＿Ｉｎｆｏを生成する。Ｐｕｎｃｈ＿Ｉｎｆｏはなくてもよい。複数あってもよい。また、Ｃｈａｌｌｅｎｇｅを生成し、ＳＥの公開鍵で暗号化する（Ｅｎｃｒｙｐｔ＿ＳＥ（Ｃｈａｌｌｅｎｇｅ））。これら改札機で生成したデータである、Ｐｕｎｃｈ＿Ｏｒｄｅｒ、Ｐｕｎｃｈ＿Ｉｎｆｏ、Ｅｎｃｒｙｐｔ＿ＳＥ（Ｃｈａｌｌｅｎｇｅ）をＳＥに送信する（（５）と（６））。
ＳＥ１０１は、Ｅｎｃｒｙｐｔ＿ＳＥ（Ｃｈａｌｌｅｎｇｅ）を復号化して、Ｃｈａｌｌｅｎｇｅを取り出す。また、Ｐｕｎｃｈ＿Ｏｒｄｅｒの署名を検証する。ＰｕｎｃｈＯｘｄｅｒに含まれるＣｈａｌｌｅｎｇｅ＿０と、（３）で送信したＣｈａｌｌｅｎｇｅ＿０を検証し、正しかったら変更処理を行う。チケット登録領域１０８ｇの、ＰｕｎｃｈＯｒｄｅｒに指定されたチケットＩＤのデータを、ＰｕｎｃｈＯｒｄｅｒに指定されたデータに書き換える。チケット登録領域１０８ｇで更新後の改札必須情報（ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ）と、Ｃｈａｌｌｅｎｇｅと、チケット登録領域１０８ｇのデータ更新を証明するデータであるということを示すフラグ、を含めたデータにＳＥ１０１ｇの署名をして、改札機１１１ｇ−１に送り返す（（７）と（８））。
改札機１１１ｇ−１は、Ｃｈａｌｌｅｎｇｅを（５）で送った値と比較し、正しかったら、ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅと（５）で送ったＰｕｎｃｈＯｒｄｅｒを比較する。このメッセージを証明として保存しておいても良い。正しかったら、ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅの値に変更されたことを確認したという証明として、ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅと、変更されたことを確認したという証明であるということを示すメッセージを含むデータに、改札機１１１ｇ−１の署名をして（Ｓｉｇｎ＿ＳＥ（ＶＥＲＩＦＹＴＩＣＫＥＴＣＯＮＦ，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ））送り返す（（９）と（１０））。
ＳＥ１０１ｇは、Ｓｉｇｎ＿ＳＥ（ＶＥＲＩＦＹＴＩＣＫＥＴＣＯＮＦ，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ）の署名を検証し、ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅと、（７）で送った値を比較して、正しかったら変更処理完了。このメッセージを変更確認の証明として保存しておいてもよい。
このあと、改札機１１１ｇ−１は、（１１）と（１２）で処理成功通知（ＡＣＫ）を受信したのち、ユーザにサービスを提供してもよいし、（１１）と（１２）はなくてもよい。
このように、乱数を送信時に暗号化するだけで、メッセージ全体を暗号化しなくても、チケットの改札処理がセキュアに行えるようになる。
図３１を用いてチケットの移動処理について説明する。このチケットの移動処理において、移動元ＭＥ１は、どのチケット価値のどのくらい移動するのかを示す情報であるＭｏｖｅＯｆｆｅｒを生成する。ユーザが入力して決めてもよいし、相手から指定されるのでも良い。ＭｏｖｅＯｆｆｅｒは、移動先のチケットの、チケットＩＤと有効期限や回数などを含む改札必須情報となる。ＭｏｖｅＯｆｆｅｒは、（４）のメッセージを送信する前までに作成すればよい。
まず、移動元ＭＥ１は移動元ＳＥ１からＳＥ１証明書を取得し（（１）と（２））、移動先ＳＥ２に送信する（（３）と（４））。
移動先ＳＥ２は、ＳＥ１証明書を検証し、正しかったら、通信相手格納領域に登録する。また、乱数Ｃｈａｌｌｅｎｇｅ＿０を生成し、ＳＥ１の公開鍵で暗号化し（Ｅｎｃｒｙｐｔ＿ＳＥ１（Ｃｈａｌｌｅｎｇｅ＿０））、ＳＥ２証明書とともに送り返す（（５）と（６））。移動元ＭＥ１は、Ｅｎｃｒｙｐｔ＿ＳＥ１（Ｃｈａｌｌｅｎｇｅ＿０）、ＳＥ２証明書に加えて、ＭｏｖｅＯｆｆｅｒをＳＥ１に送信する（７）。
ＳＥ１は、ＳＥ２証明書を検証し、正しかったら、通信相手格納領域に登録する。また、Ｅｎｃｒｙｐｔ＿ＳＥ１（Ｃｈａｌｌｅｎｇｅ＿０）を復号化する。
また、ＭｏｖｅＯｆｆｅｒに指定されたチケットＩＤのデータをチケット登録領域に登録されているデータと比較して検証してもよい。例えば有効期限などは、ＭｏｖｅＯｆｆｅｒの方が長くないか検証してもよい。また、有効回数であれば、ＭｏｖｅＯｆｆｅｒの回数の方が多くないか検証してもよい。ＭｏｖｅＯｆｆｅｒと現在のチケット登録領域のデータ（ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ）と、Ｃｈａｌｌｅｎｇｅ＿０と、指定したチケットの価値が移動してもよいことを証明するデータであることを示すフラグを含むデータにＳＥ１の署名をするＳｉｇｎ＿ＳＥ（ＭＯＶＥＯＵＴＴＩＣＫＥＴ，ＭｏｖｅＯｆｆｅｒ，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｘｉａｂｌｅ，Ｃｈａｌｌｅｎｇｅ＿０）。
また、乱数Ｃｈａｌｌｅｎｇｅを生成する。Ｃｈａｌｌｅｎｇｅを、チケット登録領域１０８ｇの更新したチケットＩＤに対応するデータとして格納してもよい。ＣｈａｌｌｅｎｇｅをＳＥ２の公開鍵で暗号化するＥｎｃｒｙｐｔ＿ＳＥ２（Ｃｈａｌｌｅｎｇｅ）。
ＳＥ１は、ＳＥ２に、Ｓｉｇｎ＿ＳＥ（ＭＯＶＥＯＵＴＴＩＣＫＥＴ，ＭｏｖｅＯｆｆｅｒ，，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅ，Ｃｈａｌｌｅｎｇｅ＿０）とＥｎｃｒｙｐｔ＿ＳＥ２（Ｃｈａｌｌｅｎｇｅ）を送信する（（８）と（９）と（１０））。ＳＥ２は、Ｅｎｃｒｙｐｔ＿ＳＥ２（Ｃｈａｌｌｅｎｇｅ）を復号化する。また、Ｓｉｇｎ＿ＳＥ（ＭＯＶＥＯＵＴＴＩＣＫＥＴ，ＭｏｖｅＯｆｆｅｒ，Ｃｈａｌｌｅｎｇｅ＿０）の署名を検証する。Ｃｈａｌｌｅｎｇｅ＿０と（５）で送った値とを検証する。正しければ、ＭｏｖｅＯｆｆｅｒの情報をチケット登録領域１０８ｇに登録する。ＳＥ２のチケット登録領域１０８ｇに登録後の改札必須情報（ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅＳＥ２）と、ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅＳＥ２で指定したとおりに登録したことを証明するメッセージであることを示すフラグと、Ｃｈａｌｌｅｎｇｅを含むデータに、ＳＥ２の署名をして（Ｓｉｇｎ＿ＳＥ２（ＭＯＶＥＩＮＴＩＣＫＥＴ，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅＳＥ２，Ｃｈａｌｌｅｎｇｅ））、ＳＥ１に送信する（（１１）と（１２）と（１３））。
ＳＥ１は、Ｓｉｇｎ＿ＳＥ２（ＭＯＶＥＩＮＴＩＣＫＥＴ，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅＳＥ２，Ｃｈａｌｌｅｎｇｅ）の署名を検証する。また、Ｃｈａｌｌｅｎｇｅと（７）で送信した値を比較する。正しかった場合、ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅＳＥ２と（７）で送ったＭｏｖｅＯｆｆｅｒを検証する。正しかった場合、ＭｏｖｅＯｆｆｅｒに回数があれば、指定された回数を減らすなどして、ＭｏｖｅＯｆｆｅｒの価値だけ移動した後の価値になるようチケット登録領域のデータを変更する。
現在の改札必須情報（ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅＳＥ１）に、移動後のデータはＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅＳＥ１であるように移動処理を完了したことを証明するメッセージであることを示すフラグ、を含むデータに署名して（Ｓｉｇｎ＿ＳＥ１（ＭＯＶＥＯＵＴＣＯＮＦ，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅＳＥ１））、ＳＥ２に送信する（（１３）と（１４）と（１５））。
ＳＥ２は、Ｓｉｇｎ＿ＳＥ１（ＭＯＶＥＯＵＴＣＯＮＦ，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅＳＥ１）の署名を検証する。正しければ、ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅＳＥ１を（１０）で受信したＭｏｖｅＯｆｆｅｒ，ＣｕｒｒｅｎｔＴｉｃｋｅｔＶａｒｉａｂｌｅの値と比較検証する。正しければ、処理成功通知（ＡＣＫ）を送信し（（１６）と（１７）と（１８））、移動処理は完了する。この処理が成功しないと、移動処理はキャンセルされ、移動処理により登録されたチケットはキャンセルされる。処理成功通知は、ＳＥ２の署名付きデータでもよい。
ＳＥ１はＳＥ２から処理成功通知（ＡＣＫ）を受信すると、移動処理を完了する。処理成功通知を受信しないと移動処理はキャンセルされる。
この実施例では、ＳＥ１については、（８）のメッセージ送信前に実際の移動処理は行われず、（１４）のメッセージ送信前に移動処理が実行されたが、（８）のメッセージの前に、実施の形態３の実施例に示す処理フローを追加することで、（８）のメッセージ送信前に実際の移動処理を行うことも考えられる。
このように、乱数を送信時に暗号化するだけで、メッセージ全体を暗号化しなくても、チケットの移動処理がセキュアに行えるようになる。また、通信路のトランスポート層の暗号化がない場合にも、大容量の暗号化を用いずに、セキュアなサービス処理が可能となる。
＜実施の形態７＞
実施の形態７では、図３２から図３４を用いて、通信路のトランスポート層の暗号化がない場合における処理能力の高くないＳＥを使ったチケット処理を説明する。実施の形態６ではＳＥで行っていた証明書の検証、乱数の暗号化、復号化、署名検証といった処理を、実施の形態７ではＭＥで行うことを特徴とする。
図３２は、実施の形態６における図２９に相当するダウンロード処理の例を示す図である。図３３は、図３０に相当する改札処理の例を示す図である。図３４は、図３１に相当するＳＥ間のチケット移動処理の例を示す図である。
実施の形態７では、ＳＥは、乱数の生成、乱数の検証、チケットの登録、署名の生成を行っているが、さらに処理を簡素化し、ＳＥではチケットの登録、署名の生成のみを行うことも考えられる。
このように、通信路のトランスポート層の暗号化がない場合にも、ＳＥの性能に応じてＭＥとの処理分担を調整することで、実施の形態７が目指す世界への移行期においても、サーバ側のシステムは変更することなくサービスを続けることができる。
＜実施の形態８＞
実施の形態８では、図３５から図３９を用いて、証明書を用いた相互認証処理を含む実施例を示す。それぞれ、図３５は図２３、図３６は図１７、図３７から図３８は図２４、図３９は図２５のメッセージ例に対応する。一部表記が変わっているが、それぞれＩｓｓｕｅｒは、図２３の発行サーバ１１１ｇ−２をあらわす。Ｒａｎｄｏｍは、図２３のＣｈａｌｌｅｎｇｅに相当する。ＴｉｃｋｅｔＶは、改札必須情報１００２に相当し、チケットＩＤや、有効度数、有効期限など改札処理に必須な情報を示す。
また、ＴｉｃｋｅｔＩＤは、このチケット処理を行うチケットアプリケーション種別を示すチケットシステムＩＤ、イベントチケットや回数券などといったチケットタイプＩＤ、特定のイベントなどを示すチケット種別ＩＤ、通し番号などのようにチケット一枚一枚ユニークに振られたシリアル番号など、何種類かあり、またこの組み合わせで指定することができる。こうすることで、場所や状況に応じ、確認したいチケットを効率的に特定することができる。
図３５は、図２３に相当するダウンロード処理の例を示す。図３５では、図２３に加えてメッセージ（１）から（３）で、サーバがＳＥを認証する処理を行っている。これにより、正しいＳＥにチケット登録処理を行うことができる。
図３５では、ＳＥに対するプリミティブが以下に示すように２つある。ダウンロード処理のプリミティブを定義することにより、ＭＥとＳＥ間の互換性が保障できる。
（ダウンロード処理のプリミティブ１）
プリミティブ名…ＳｔａｒｔＲｅｇｉｓｔｒａｔｉｏｎ
入力：（２）のメッセージ…Ｃｅｒｔ＿Ｉｓｓｕｅｒ，Ｒａｎｄｏｍ１
出力：（３）のメッセージ…Ｓｉｇｎ＿ＳＥ（ＳＴＡＲＴＲＥＧ，Ｒａｎｄｏｍ１），Ｒａｎｄｏｍ２
処理…入力された発行サーバ証明書１１２ｇ−２（Ｃｅｒｔ＿Ｉ）を検証する。正しければ、署名目的と入力された乱数に署名をしたデータ（Ｓｉｇｎ＿Ｉ（ＳＴＡＲＴＲＥＧ，Ｒａｎｄｏｍ１））と、あらたに生成した乱数（Ｒａｎｄｏｍ２）を返す。証明書の公開鍵と乱数の値（Ｒａｎｄｏｍ２）は格納しておく。
（ダウンロード処理のプリミティブ２）
プリミティブ名…Ｒｅｇｉｓｔｒａｔｉｏｎ
入力：（６）のメッセージ…Ｓｉｇｎ＿Ｉ（ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ２）
出力：（７）のメッセージ…ＡＣＫ
処理…Ｒａｎｄｏｍ２をＳｔａｒｔＲｅｇｉｓｔｒａｔｉｏｎで生成した乱数（Ｒａｎｄｏｍ２）と照合し、正しければ、入力されたデータの署名を、ＳｔａｒｔＲｅｇｉｓｔｒａｔｉｏｎ取得した公開鍵で検証する。正しければＴｉｃｋｅｔＶを格納する。正常に処理が終われば、ＡＣＫを返す。
（３）には、図２３と同様に発行されるチケットに含まれることとなるＲａｎｄｏｍ２が含まれる。このＳＥ１０１ｇ−１で生成したＲａｎｄｏｍ２を、発行するチケットの改札必須情報１００２に含めて署名生成しているため、通信中のチケットデータ１０００の差し替えを阻止できている。理由は、Ｃｈａｌｌｅｎｇｅ値が重複することは確率的に無視できることに加え、Ｃｈａｌｌｅｎｇｅが異なると署名は異なり、発行サーバの秘密鍵を知らない人間には署名が作成できないため、同じ署名になることもなく、どこかでコピーした値に差し替えることは出来ないからである。チケットデータ１０００だけ盗聴しても、そこに含まれるＲａｎｄｏｍ２を生成したＳＥ１０１ｇ−１しか、そのチケットを登録できないセキュアな処理となっている。
また、（３）の署名つき乱数にも、署名の目的（ここでは、チケットの登録開始のための認証処理）が含まれるので、悪意のあるユーザが、このメッセージを他の目的で再利用することができなくなっている。
ＭＥ１００ｇ−１では、（５）受信時に、改札必須部１００１の検証はＳＥに任せるが、その他の例えば、チケット固定部１００４の検証はＭＥで行う。このように、処理を分散し、ＳＥでの処理を最小限にすることで、早い処理が可能となる。チケット固定部１００４の署名検証を偽っても、実害のない嫌がらせにしかならないので、チケット固定部には署名をつけない場合もある。こうすることで、チケットデータ長を短縮でき、また、チケット固定部１００４の署名検証処理をしなくて済む。
図３６は図１７に相当するチケットの証明処理の例を示す。メッセージの名前が異なっているが、処理はまったく同様である。
図３５では、ＳＥに対するプリミティブが以下に示すように１つある。証明処理のプリミティブを定義することにより、ＭＥとＳＥ間の互換性が保障できる。
（証明処理のプリミティブ）
プリミティブ名…Ｃｈｅｃｋ
入力：（２）のメッセージ…ＴｉｃｋｅｔＩＤ，Ｒａｎｄｏｍ１
出力：（３）のメッセージ…Ｓｉｇｎ＿ＳＥ（ＣＨＥＣＫ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ１）
処理…入力されたＴｉｃｋｅｔＩＤの値を含むＴｉｃｋｅｔＶが格納されているか検索する。あれば、署名の目的と、そのＴｉｃｋｅｔＶと入力されたＲａｎｄｏｍ１を含む値に署名を生成し、戻り値として返す。
このフローは、定期券や身分証明書など、チケットの改札処理によってチケットデータが変化しない場合の改札処理にも用いることができる。改札処理に用いる場合、図３６のＩｓｓｕｅｒが改札機（Ｖｅｒｉｆｉｅｒ）１１１ｇ−１に変わる。また、ＳＥ１０１ｇ−１と改札機１１１ｇ−１の通信時間に制限時間を設けてもよい。こうすることで、以下に示す不正を防ぐことができる。
（１）不正端末が、改札機から通常手続きとして、Ｃｈａｌｌｅｎｇｅ、ＴｉｃｋｅｔＩＤをもらう。
（２）上記のＣｈａｌｌｅｎｇｅ、ＴｉｃｋｅｔＩＤを、（改札機から来たかのようにＳＥを騙して）正規端末に入力して、Ｃｈａｌｌｅｎｇｅと価値部に関する署名を生成させる。
（３）上記の正規端末作成の署名を、不正端末は受け取り、改札機に送信して改札をとおる。
図３７は、図２４に相当する改札処理の例を示す。改札処理には、図３６で説明した定期券や会員証のような改札時に価値が減らないサービスと、回数券やプリペイドカードのような改札処理が一度で終わるサービスと、電車のイオカードのような入場と退場の処理が必要なサービスがある。
図３７では、回数券やプリペイドカードのような改札処理が一度で終わるサービスと、電車のイオカードのようなサービスの入場処理のみを示す。このようにサービスごとにプリミティブを分けることで、処理を最適化し、高速に処理を行うことができる。
図３７には、ＳＥのプリミティブが以下に示すように２つある。改札処理のプリミティブを定義することにより、ＭＥとＳＥ間の互換性が保障できる。
（改札処理のプリミティブ１）
プリミティブ名…ＳｔａｒｔＴａｎｓａｃｔｉｏｎ
入力：（２）のメッセージ…Ｃｅｒｔ＿Ｖｅｒｉｆｉｅｒ，ＴｉｃｋｅｔＩＤ，Ｍｉｎ＿Ｖ
出力：（３）のメッセージ…Ｒａｎｄｏｍ１
処理…入力された改札機証明書Ｃｅｒｔ＿Ｖｅｒｉｆｉｅｒ１１２ｇ−１を検証する。正しければ、指定されたＴｉｃｋｅｔＩＤの値を含むＴｉｃｋｅｔＶが格納されているか検索する。Ｍｉｎ＿Ｖが有効度数として入力された場合、検索したＴｉｃｋｅｔＶの有効度数がＭｉｎ＿Ｖ以上か検証する。正しければ、あらたに生成した乱数を返す。証明書の公開鍵と生成した乱数の値（Ｒａｎｄｏｍ１）は格納しておく。ＴｉｃｋｅｔＩＤとＭｉｎ＿Ｖはオプション機能としてもよい。
（改札処理のプリミティブ２）
プリミティブ名…Ｔｒａｎｓａｃｔｉｏｎ
入力：（６）のメッセージ…Ｔｒａｎｓ＿Ｏｒｄｅｒ，Ｒａｎｄｏｍ２，Ｔ
出力：（７）のメッセージ…Ｓｉｇｎ＿ＳＥ（ＴＲＡＮＳＡＣＴＩＯＮ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ２，Ｔ）
処理…ＳｔａｒｔＴｒａｎｓａｃｔｉｏｎまたはＰｒｅＳＥｎｔａｔｉｏｎで生成したＲａｎｄｏｍ１と、Ｔｒａｎｓ＿Ｏｒｄｅｒに含まれる乱数の値を比較検証する。正しければ、入力の署名付きデータ（Ｔｒａｎｓ＿Ｏｒｄｅｒ）の署名を、ＳｔａｒｔＴｒａｎｓａｃｔｉｏｎまたはＰｒｅＳＥｎｔａｔｉｏｎで取得した公開鍵で検証する。正しければ、Ｔｒａｎｓ＿Ｏｒｄｅｒに指定されたＴｉｃｋｅｔＶの値を指定された値減額し、ＧａｔｅＩｎｆｏがあれば、書き換える。署名の目的と、更新後のＴｉｃｋｅｔＶの値と、入力されたＲａｎｄｏｍ２およびＴを含むデータ（ＴＲＡＮＳＡＣＴＩＯＮ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ２，Ｔ）に電子署名を生成したデータを返す。
図３７では、図２４の処理に加え、（１）のメッセージで改札機（Ｖｅｒｉｆｉｅｒ）１１１ｇ−１からＴｉｃｋｅｔＩＤを送っているので、ユーザが事前にチケットを選ばなくても、すべて自動的に改札処理が行えるようになった。また、（１）のメッセージでＭｉｎ＿Ｖ（最低限必要な有効度数など）をおくるようにしたため、実際の改札処理（Ｔｒａｎｓａｃｔｉｏｎ）をする前に、度数が足りない場合などの判定が早く行える。
また、（５）で、改札機（Ｖｅｒｉｆｉｅｒ）１１１ｇ−１側の時間情報を送るようにし、このデータも（６）のデータに含めることで、実運用中に発生した障害処理の判定に時間情報も参照できるようになり、判断が行いやすくなった。
（６）のメッセージに含まれるＴｒａｎｓ＿Ｏｒｄｅｒは、ＴｉｃｋｅｔＩＤと、減額する値（有効回数を何回、有効度数を何度、など）とＳｔａｒｔＴｒａｎｓａｃｔｉｏｎで生成したＲａｎｄｏｍ１を含む値にＶｅｒｉｆｉｅｒが署名したデータである。署名対象データの中に、他の情報（ＧａｔｅＩｎｆｏ：入退場情報など）が必要な場合、含まれることもある。
本実施の形態では、改札処理のたびに、減額していく処理を示したが、限度回数や限度度数を示す値と、累積値を表す値を別につくり、処理のたびに累積値を増やしていくという方法も可能である。このように、初期値と累積値を別にもつことで、初期値と累積値をいつでも確認することができる。
また、メッセージの（５）、（７）には、それぞれ、相手から送られた乱数が含まれるので、通信路上の差し替え攻撃を阻止できており、セキュアな通信となっている。
ＭＥ１００ｇ−１は、（５）のメッセージに含まれるＴｒａｎｓ＿Ｏｒｄｅｒと（７）のメッセージに含まれるＳｉｇｎ＿ＳＥ（ＴＲＡＮＳＡＣＴＩＯＮ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ２，Ｔ）を格納しておく。こうすることで、たとえ改札機が壊れているなど場合にも、これらのメッセージを示すことで、どの改札機に対してどんな改札処理を行ったのか、証明することができる。
図３８も、図２４に相当する改札処理を示しているが、図３８では、電車のイオカードのようなサービスの退場処理のみを示す。
図３７で示した処理と異なり、ＰｒｅＳＥｎｔａｔｉｏｎプリミティブを追加したので、改札処理の前に、入場時の情報を改札機１１１ｇ−１に提示し、改札機１１１ｇ−１は提示された入場情報に基づいて、精算の計算を行い、Ｔｒａｎｓ＿Ｏｒｄｅｒを生成できる。
図３７には、ＳＥのプリミティブが２つある。１つ目のプリミティブを以下に示す。改札処理のプリミティブを定義することにより、ＭＥとＳＥ間の互換性が保障できる。
（改札処理のプリミティブ１）
プリミティブ名…ＰｒｅＳＥｎｔａｔｉｏｎ
入力：（２）のメッセージ…Ｃｅｒｔ＿Ｖｅｒｉｆｉｅｒ，ＴｉｃｋｅｔＩＤ，Ｒａｎｄｏｍ
出力：（３）のメッセージ…Ｓｉｇｎ＿ＳＥ（ＰＲＥＳＥＮＴＡＴＩＯＮ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ３），Ｒａｎｄｏｍ１
処理…入力された改札機証明書Ｃｅｒｔ＿Ｖｅｒｉｆｉｅｒ１１２ｇ−１を検証する。正しければ、入力されたＴｉｃｋｅｔＩＤの値を含むＴｉｃｋｅｔＶが格納されているか検索する。存在すれば、署名の目的と、指定されたＴｉｃｋｅｔＶとＲａｎｄｏｍ３を含む値（ＰＲＥＳＥＮＴＡＴＩＯＮ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ３））に署名を生成したデータと、新たに生成した乱数（Ｒａｎｄｏｍ１）を返す。証明書の公開鍵と生成した乱数の値（Ｒａｎｄｏｍ１）は格納しておく。
２つ目のプリミティブは図３７で説明したＴｒａｎｓａｃｔｉｏｎプリミティブである。図３７と図３８は、（５）から（７）のメッセージがまったく同じである。二つのサービスを同じプリミティブで実装できるため、効率がよくなっている。例えば、今まで回数券サービスしかサポートしていなかったＳＥ１０１ｇ−１でも、ＰｒｅＳＥｎｔａｔｉｏｎプリミティブだけ実装すれば、電車のイオカードのような退場時に入場時の情報を参照して精算処理が必要なサービスを実現できる。
また、メッセージの（４）、（５）、（７）には、それぞれ、相手から送られた乱数が含まれるので、通信路上の差し替え攻撃を阻止できており、セキュアな通信となっている。
ＭＥ１００ｇ−１は、（５）のメッセージに含まれるＴｒａｎｓ＿Ｏｒｄｅｒと（７）のメッセージに含まれるＳｉｇｎ＿ＳＥ（ＴＲＡＮＳＡＣＴＩＯＮ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ２，Ｔ）を格納しておく。こうすることで、たとえ改札機が壊れているなど場合にも、これらのメッセージを示すことで、どの改札機に対してどんな改札処理を行ったのか、証明することができる。なお、メッセージ（４）に人数を指定するパラメータを加えても良い。こうすることで、Ｖｅｒｉｆｉｅｒに人数を自動検知する機能がない場合にも、Ｖｅｒｉｆｉｅｒは、複数人分や、大人一人とこども一人といった細かい依頼に応じたＴｒａｎｓ＿Ｏｒｄｅｒを生成することができる。
図３９は、図２５に相当するＳＥ間のチケット移動処理の例を示す。図３９では、図２５と異なり、ＳＥ１の証明書送信も含んだメッセージ図を示す。また、最適化して、確認メッセージを省いた。
図３９には以下に示すように４つのプリミティブがある。送り手側に２つ、受け手側に２つである。移動処理のプリミティブを定義することにより、ＭＥとＳＥ間の互換性が保障できる。
（移動処理のプリミティブ１）
プリミティブ名…ＳｔａｒｔＴｒａｎｓｆｅｒ
入力：（２）のメッセージ…Ｃｅｒｔ＿ＳＥ１
出力：（３）のメッセージ…Ｒａｎｄｏｍ１
処理…チケットを受け取る側のＳＥ２の処理。入力されたＳＥ１（送り手側のＳＥ）１０１ｇ−１の証明書Ｃｅｒｔ＿ＳＥ１を検証する。正しければ、新たに生成した乱数（Ｒａｎｄｏｍ１）を返す。証明書の公開鍵と生成した乱数の値（Ｒａｎｄｏｍ１）は格納しておく。
メッセージの（５）に示されるＭｏｖｅｄａｔａは、移動して相手のＳＥに登録されるＴｉｃｋｅｔＶの値を示す。このデータは、ＭＥ１００ｇ−１のアプリケーションを用いて、ユーザ操作を用いて生成されているものとする。チケットが一回限りのものでない場合、そのチケットの一部を移動するといった指定も可能としてもよい。また、チケットによっては、移動を一切許可しないチケットや、一部のみの移動を許さないチケットがあってよい。その場合、それを示す情報が、改札必須情報１００２に含まれる。こうすることで、サービス提供者は、柔軟性のあるサービスが提供できる。
（移動処理のプリミティブ２）
プリミティブ名…Ｉｎｓｔｒｕｃｔｉｏｎ
入力：（５）のメッセージ…Ｍｏｖｅｄａｔａ，Ｒａｎｄｏｍ１，Ｃｅｒｔ＿ＳＥ２
出力：（６）のメッセージ…ＭｏｖｅＯｆｆｅｒ，Ｒａｎｄｏｍ２
処理…チケットを送る側のＳＥ１の処理。入力されたＳＥ２（受け手側のＳＥ）１０１ｇ−２の証明書Ｃｅｒｔ＿ＳＥ２を検証する。正しければ、入力されたＭｏｖｅｄａｔａに示されたＴｉｃｋｅｔＶが格納されているか確認する。あれば、Ｍｏｖｅｄａｔａに指定された分をＴｉｃｋｅｔＶから減算し、ＴｉｃｋｅｔＶを更新する。処理が正常に終われば、更新前のＴｉｃｋｅｔＶの値と、Ｍｏｖｅｄａｔａと、Ｒａｎｄｏｍ１とＳＥ１が管理する時刻情報とを合わせたデータに署名をしたデータＭｏｖｅＯｆｆｅｒ＝Ｓｉｇｎ＿ＳＥ１（Ｍｏｖｅｄａｔａ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ１，Ｔ１）と、新たに生成した乱数（Ｒａｎｄｏｍ２）を返す。証明書の公開鍵と生成した乱数の値（Ｒａｎｄｏｍ２）は格納しておく。
時間情報Ｔ１は、処理が正常に終了しなかったときに、運用者が障害の原因判断に用いることができる。ただし、ＳＥにリアルタイムクロックが実装されていない場合、時間情報は含めなくてもよい。
予め、価値情報を削除してから、受け手側に移動命令を出すことで、価値情報が２重に存在することがなく、悪意のあるユーザが得をすることがないしくみになっているので、サービス事業者も安心してサービスを提供できる。
（移動処理のプリミティブ３）
プリミティブ名…Ｔａｎｓｆｅｒ
入力：（７）のメッセージ…ＭｏｖｅＯｆｆｅｒ，Ｒａｎｄｏｍ２
出力：（８）のメッセージ…Ｓｉｇｎ＿ＳＥ２（ＴＲＡＮＳＦＥＲ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ２，Ｔ２）
処理…チケットを送る側のＳＥ２の処理。ＭｏｖｅＯｆｆｅｒに含まれるＲａｎｄｏｍ１の値をＳｔａｒｔＴｒａｎｓｆｅｒで生成した値と比較検証する。正しければ、ＭｏｖｅＯｆｆｅｒの署名をＳｔａｒｔＴｒａｎｓｆｅｒで取得した公開鍵で検証する。正しければ、ＭｏｖｅＯｆｆｅｒに含まれるＭｏｖｅｄａｔａの値を新たなＴｉｃｋｅｔＶとして格納する。正常に終了したら、署名の目的、登録したＴｉｃｋｅｔＶ、入力されたＲａｎｄｏｍ２、ＳＥ２が管理してしている時間情報Ｔ２をあわせたデータ（ＴＲＡＮＳＦＥＲ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ２，Ｔ２）に署名をしたデータを返す。
時間情報Ｔ２は、処理が正常に終了しなかったときに、運用者が障害の原因判断に用いることができる。ただし、ＳＥにリアルタイムクロックが実装されていない場合、時間情報は含めなくてもよい。
（移動処理のプリミティブ４）
プリミティブ名…Ｒｅｃｅｉｐｔ
入力：（９）のメッセージ…Ｓｉｇｎ＿ＳＥ２（ＴＲＡＮＳＦＥＲ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ２，Ｔ２）
出力：（１０）のメッセージ…ＡＣＫ
処理…チケットを受け取る側のＳＥ１の処理。入力データに含まれるＲａｎｄｏｍ２とＴｉｃｋｅｔＶの値をＩｎｓｔｒｕｃｔｉｏｎで生成した値と比較検証する。正しければ、入力データに含まれる署名の目的を検証する。正しければ、入力データの署名をＩｎｓｔｒｕｃｔｉｏｎで取得した公開鍵で検証する。正常に終了したら、ＡＣＫを返す。
これらの４つのプリミティブを実装することで、サーバを介さずにチケットを譲渡することができる。また、電子署名とＳＥを用いてセキュリティを確保している上に、譲渡してしまえば、譲渡元の情報は残らないので、匿名性のあるセキュアな譲渡サービスを提供することができる。
ダウンロード、改札、譲渡など処理に応じてプリミティブを分け、生成されるデータに含まれる署名の目的が異なるため、ユーザが他の目的でデータを流用することができないようになっている。
また、送り手および受け手のＭＥ１０１は、ＭｏｖｅＯｆｆｅｒとＳｉｇｎ＿ＳＥ２（ＴＲＡＮＳＦＥＲ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ２，Ｔ２）を保存しておく。こうすることで、トラブルが起きたときにも、どんな移動の命令に対してどんな格納処理をしたのかが証明できる。
＜実施の形態９＞
実施の形態９では、図４０と図４１を用いて実施の形態６では判断できないエラーを自動で復旧する仕組みを説明する。そのために、図１１のＳＥ１０１ｇ内に、新たに、エラーリカバリー機能と処理履歴可能部を設ける。図３５に示すダウンロード処理と図３６に示す証明処理のみを実施する場合にはこの実施例は不要である。
まず、図４０を用いてＳＥ内で行う通信相手管理機能の処理の流れを説明する。各オペレーション実行時に、このフローを開始し、完了時に終了させる。例えば、図３５のダウンロード処理では、（２）のメッセージの受信時に、ステップ４００を開始し、ステップ４０６の処理にあたるところで、図３５のダウンロード処理で説明してきたチケット処理を行い、（７）のメッセージ送信に、ステップ４０７を実行し、ステップ４０８で処理を完了する。ＳＥ内に処理履歴可能部を持ち、ステップ４０４またはステップ４０７で通信相手格納領域１０７ｇに格納した情報とその処理のステータスを履歴情報として格納しておく。そのため、ユーザは不法にアクセスして都合のよいように書き換えることができないので不正を防ぐことができる。また、同じチケットに対する、ダウンロード処理、改札処理、譲渡処理の情報を区別して管理しておくことで、処理をまたがった不正も検知することができる。また、ステップ４０１で、改札処理でエラー状態となったチケットは移動処理できない、等の制御も可能となり、未然にトラブルを防ぐことができる。
通信相手格納領域１０７ｇに格納する情報は、チケットＩＤ、オペレーション（プリミティブ）の種類、通信相手の種類（Ｉｓｓｕｅｒ，Ｖｅｒｉｆｉｅｒなどの種別情報）、通信相手の公開鍵、処理中のデータ（生成した乱数）、検証するメッセージなどがある。これらのうち、すべてを処理履歴可能部に格納しても良いし、一部を格納しても良い。こうすることで、ＳＥのメモリサイズに応じたエラーリカバリー機能が提供できるようになる。
ＰＴＤの電源ＯＮ時、ＳＥ挿入時、またはチケットアプリ起動時に、ＳＥの通信相手格納領域に未完了処理データがあれば、未完了履歴にデータを格納する機能をもつこともある。
履歴情報をいつまで格納しておくかは、ユーザが設定しても良いし、期間を決めてもよいし、最大格納数を決めておいても良い。チケットサービス提供者が、この履歴情報を定期的に吸い上げ、バックアップサービスを提供するというサービスも考えられる。こうすることで、ユーザはメモリ管理を意識せずにサービスを受けることができる。また、チケットサービス提供者は、ユーザの使用履歴を集計することもできる。
次に図４１を用いて、自動的にエラーリカバリーを行う処理を説明する。図４０では、エラーリカバリーを行うサービス端末をＶｅｒｉｆｉｅｒ１１１ｇ−１と呼ぶ。この処理では、ＳＥの通信相手管理機能と、ＭＥ１００ｇ−１の処理中のメッセージを管理する機能を用いる。ＭＥ１００ｇ−１には、チケット処理中のメッセージ、例えば、図３７と図３８の改札処理ではＴｒａｎｓ＿Ｏｒｄｅｒと（７）のメッセージ、図３９のチケットの移動の処理では、ＭｏｖｅＯｆｆｅｒと（８）のメッセージ、を格納しており、ＴｉｃｋｅｔＩＤの値を指定すると、その値を含むデータを検索できる機能を持っている。これらの履歴データは、ＭＥ上にあるのでユーザが勝手に削除することなどが考えられるが、削除すると、ユーザがエラーリカバリー処理において不利になるので、勝手には削除しないと考えることができる。
この処理には２つのプリミティブを用いる。エラーリカバリーのプリミティブを定義することにより、アプリケーションとＳＥの互換性が保障できる。
（エラーリカバリーのプリミティブ１）
プリミティブ名…ＳｔａｒｔＲｅｃｏｖｅｒｙ
入力：（２）のメッセージ…Ｃｅｒｔ＿Ｖｅｒｉｆｉｅｒ，ＴｉｃｋｅｔＩＤ，Ｒａｎｄｏｍ３
出力：（３）のメッセージ…Ｓｉｇｎ＿ＳＥ（ＳＴＡＲＴＲＥＣＯＶＥＲ，ＴｉｃｋｅｔＶ，Ｓｔａｔｕｓ＿ｄａｔａ ｏｆ ｔｈｅ ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ３），Ｒａｎｄｏｍ１
処理…入力された証明書を検証する。正しければ、署名の目的と、ＴｉｃｋｅｔＩＤで指定されたＴｉｃｋｅｔＶの値と、そのＴｉｃｋｅｔＶに関係するの処理履歴Ｓｔａｔｕｓ＿ｄａｔａ ｏｆ ｔｈｅ ＴｉｃｋｅｔＶと、入力されたＲａｎｄｏｍ３を含むデータ（ＳＴＡＲＴＲＥＣＯＶＥＲ，ＴｉｃｋｅｔＶ，Ｓｔａｔｕｓ，Ｒａｎｄｏｍ３）に電子署名を生成したデータと、新規に生成した乱数Ｒａｎｄｏｍ１を返す。証明書の公開鍵と生成した乱数の値（Ｒａｎｄｏｍ２）は格納しておく。
（３）のメッセージを受け取ったＭＥ１００ｇ−１は、ＭＥに格納されているチケット処理データの履歴の中からＴｉｃｋｅｔＩＤで指定された値を含むデータを検索し、あれば、その履歴データ（Ｌｏｇ ｏｆ ｔｈｅ ＴｉｃｋｅｔＶ）とＳＥの証明書を（３）のデータとともに、メッセージの（４）としてＶｅｒｉｆｉｅｒに送信する。
Ｖｅｒｉｆｉｅｒは、Ｓｉｇｎ＿ＳＥ（ＳＴＡＲＴＲＥＣＯＶＥＲ，ＴｉｃｋｅｔＶ，Ｓｔａｔｕｓ＿ｄａｔａ ｏｆ ｔｈｅ ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ３）に含まれるＲａｎｄｏｍ３の値を検証し、正しければ、署名を検証する。正しければ、Ｓｉｇｎ＿ＳＥ（ＳＴＡＲＴＲＥＣＯＶ，ＴｉｃｋｅｔＶ，Ｓｔａｔｕｓ＿ｄａｔａ ｏｆ ｔｈｅ ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ３）に含まれるＴｉｃｋｅｔＶとＳｔａｔｕｓ＿ｄａｔａ ｏｆ ｔｈｅ ＴｉｃｋｅｔＶと、履歴データからエラーの原因を切り分ける。
図３７に示すチケットの移動処理のエラーを切り分ける場合には、移動元のＳＥと移動先のＳＥの両方に対してメッセージの（１）から（４）までを行う。こうすることで、移動の処理に関してもエラーの状況を正しく把握して判断することができる。
ここで、チケットのダウンロード処理においては、正常に格納したのに、すぐに譲渡処理をしたため、このＳＥに対象のＴｉｃｋｅｔＶが格納されていないのだ、と判断できることもある。または、本当にチケットダウンロード時になんらかの理由で格納処理に失敗し、ＳＥにＴｉｃｋｅｔＶが格納されていないことがわかる。
同様に、改札処理では、チケット処理が正常に行われており、改札機の機械的なトラブルで改札を通れなかったと判断できることもある。または、改札処理をまだ行っていない状態だということがわかる。
同様に、譲渡処理では、チケットの移動処理は正常に行われいるが、受け手側のＳＥがさらに譲渡処理をしたために、送り手側のＳＥにも受け手側のＳＥにも対象のＴｉｃｋｅｔＶが正しく登録されていないことがわかる。または、送り手側はすでに移動処理をしたのに、何らかのエラーで受け手側のＳＥに格納されていない状態だということがわかる。または、まだ移動処理を開始する前の状態だということがわかる。
Ｖｅｒｉｆｉｅｒは、障害の原因に応じてＲｅｃｏｖｅｒｙ＿Ｏｒｄｅｒを生成する。
Ｒｅｃｏｖｅｒｙ＿Ｏｒｄｅｒは、Ｓｉｇｎ＿Ｖｅｒｉｆｅｒ（ＲＥＣＶＯＲＤＥＲ，ＴｉｃｋｅｔＶ，Ｓｔａｔｕｓ＿ｄａｔａ ｏｆ ｔｈｅ ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ１）とあらわせる。ＳＥのＴｉｃｋｅｔＶに変更が必要ならば、修正後のＴｉｃｋｅｔＶの値を入れる。ＴｉｃｋｅｔＶに変更が必要ない場合、現在と同じ値を入れる。Ｓｔａｔｕｓ＿ｄａｔａ ｏｆ ｔｈｅ ＴｉｃｋｅｔＶに変更が必要ならば、変更後Ｓｔａｔｕｓ＿ｄａｔａ ｏｆ ｔｈｅ ＴｉｃｋｅｔＶに変更を加える。
さらにあらたな乱数Ｒａｎｄｏｍ２を生成し、Ｖｅｒｉｆｉｅｒが管理する時間情報ＴとＲｅｃｏｖｅｒｙ＿Ｏｒｄｅｒともに、メッセージの（５）としてＭＥに送信する。
メッセージ（５）には、ユーザに対してエラー内容を説明するデータＲｅｃｏｖｅｒｙ＿Ｉｎｆｏが含まれていても良い。Ｒｅｃｏｖｅｒｙ＿Ｉｎｆｏは署名付きデータの場合もある。Ｒｅｃｏｖｅｒｙ＿Ｉｎｆｏが含まれる場合、ＭＥはこの説明用のデータをユーザに提示する。これにより、ユーザはエラーの原因がどこにあり、どんなリカバリー処理をしようとしているのか知ることができ、安心してサービスを受けることができる。
（エラーリカバリーのプリミティブ２）
プリミティブ名…Ｒｅｃｏｖｅｒｙ
入力：（６）のメッセージ…Ｒｅｃｏｖｅｒｙ＿Ｏｒｄｅｒ，Ｒａｎｄｏｍ２，Ｔ
出力：（７）のメッセージ…Ｓｉｇｎ＿ＳＥ（ＲＥＣＯＶＥＲＹ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ２，Ｔ）
処理…ＳｔａｒｔＲｅｃｏｖｅｒｙで生成したＲａｎｄｏｍ１と、Ｒｅｃｏｖｅｒ＿Ｏｒｄｅｒに含まれる乱数の値を比較検証する。正しければ、入力の署名付きデータ（Ｒｅｃｏｖｅｒ＿Ｏｒｄｅｒ）の署名を、ＳｔａｒｔＲｅｃｏｖｅｒｙで取得した公開鍵で検証する。正しければ、Ｒｅｃｏｖｅｒ＿Ｏｒｄｅｒに指定されたＴｉｃｋｅｔＶの値を指定された値に更新し、対応する処理ステータスの履歴情報もＳｔａｔｕｓ＿ｄａｔａ ｏｆ ｔｈｅ ＴｉｃｋｅｔＶに書き換える。署名の目的と、更新後のＴｉｃｋｅｔＶの値と、入力されたＲａｎｄｏｍ２およびＴを含むデータ（ＲＥＣＯＶＥＲＹ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ２，Ｔ）に電子署名を生成したデータを返す。
乱数値を関与させて処理を行っているので、通信路での差し替え攻撃も防御でき、セキュアなリカバリー処理が行える。また、いろいろな障害の原因をこの処理を用いて分析し、リカバリーできるので効率的となっている。また、この処理のＶｅｒｉｆｉｅｒは、ユーザが至近距離に移動してサービスを実行するエラーリカバリー用の端末としても実装できるし、ネットワーク上の一サーバとしても実装できるため、サービス提供者も実装の自由度があり、ユーザも状況に応じて便利な方を選ぶことができる。また、エラーリカバリーのプリミティブを定義したので、アプリケーションとＳＥの互換性が保障できる。
＜実施の形態１０＞
実施の形態１０では、図３５から図４１を用いて、チケットＩＤに関連付けられた共有鍵を用いた例を説明する。
実施の形態８と９では、公開鍵暗号方式を用いる方法のみ提案したが、共有鍵を用いる方法も考えられる。共有鍵が、共有の秘密鍵の場合、鍵情報は送信先の公開鍵で暗号化して送信される。実施の形態９で説明した署名付きのデータは、署名の代わりに、共有鍵で暗号化して送受信される。共有鍵が、共有の公開鍵ペアの場合、データは暗号化または署名を用いて送受信される。どちらの場合も、共有鍵を送信する場合は、共有秘密鍵情報は送信先の秘密鍵で暗号化して送信される。相手の公開鍵で暗号化して送信する。ただし、共有の公開鍵は暗号化しなくて良い。実施の形態９で説明した署名付きのデータは、署名の代わりに、共有公開鍵で暗号化されるか、共有秘密鍵で暗号化して送受信される。
図３５のダウンロード処理の場合、メッセージ（５）のＩｓｓｕｅｒの署名付きチケットデータの中に、ＳＥの公開鍵で暗号化した共有鍵情報を含む。メッセージ（６）を受信したＳＥは、共有鍵を復号化し、ＳＥ内に、対応するチケットと関連付けて格納しておく。こうすることで、ＳＥは、以後のこのチケットを用いた処理において、証明書検証などのＰＫＩを用いた処理を行わなくて済む。
Ｉｓｓｕｅｒは、Ｖｅｒｉｆｉｅｒと相互認証ののち、Ｖｅｒｉｆｅｒの公開鍵で暗号化した共有鍵をチケットＩＤと関連付けて送信しておく。こうすることで、Ｖｅｒｉｆｅｒは、チケット改札時にＳＥごとに、ＳＥ証明書の検証を行わなくてすむ。
図３６の処理の場合、メッセージ（３）は、ＳＥの署名の代わりにそのチケットＩＤに対応する共有鍵で暗号化または署名したデータを出力してもよい。
図３７の改札処理の場合、メッセージ（１）から（４）は不要である。または、メッセージ（３）とメッセージ（４）のＲａｎｄｏｍはあってもよい。または、メッセージ（１）と（２）でチケットＩＤのみを送り、メッセージ（３）と（４）では、そのチケットＩＤに関連付けられた共有鍵でＲａｎｄｏｍを暗号化して送っても良い。
メッセージ（５）のＴｒａｎｓ＿Ｏｒｄｅｒは、Ｖｅｒｉｆｉｅｒの鍵で署名する代わりにそのチケットＩＤに対応する共有鍵で暗号化、または署名を付与されているものでもよい。また、ＳＥで生成されるメッセージ（７）も、ＳＥの署名を付与する代わりに、対応する共有鍵で暗号化、または署名を付与されているものでもよい。こうすることで、メッセージの数を４つ少なくすることができ、高速な処理が可能となる。
図３８の改札処理の場合、メッセージ（２）のＣｅｒｔ＿Ｖｅｒｉｆｉｅｒは不要となる。また、メッセージ（３）のデータＳｉｇ＿ＳＥ（ＰＲＥＳＥＮＴＡＴＩＯＮ，ＴｉｃｋｅｔＶ，Ｒａｎｄｏｍ３）は、ＳＥの鍵で署名する代わりにチケットＩＤに対応する共有鍵で暗号化、または署名を付与したデータでもよい。メッセージ（５）から（７）は図３７の説明と同じである。こうすることで、証明書の検証など、負荷の重い処理を省くことができる。
図３９の移動処理の場合、メッセージ（５）までは同様である。ＳＥで、メッセージ（５）を受信した後、共有鍵を生成し、ＭｏｖｅＯｆｆｅｒに、ＳＥ２の秘密鍵で暗号化した共有鍵のデータを含めて送信する。メッセージ（７）を受信したＳＥ２は、ＳＥ２の秘密鍵で暗号化した共有鍵を復号化し、メッセージ（８）は、ＳＥ２の秘密鍵で署名する代わりに、受信した共有鍵で暗号化、または署名を付与してもよい。メッセージ（１０）は同様である。
図４１の場合、メッセージ（２）のＣｅｒｔ＿Ｖｅｒｉｆｉｅｒは不要となる。また、メッセージ（３）のデータＳｉｇ＿ＳＥは、ＳＥの鍵で署名する代わりにチケットＩＤに対応する共有鍵で暗号化、または署名を付与したデータでもよい。メッセージ（５）のＲｅｃｏｖｅｒｙ＿Ｏｒｄｅｒは、Ｖｅｒｉｆｉｅｒの鍵で署名する代わりにそのチケットＩＤに対応する共有鍵で暗号化、または署名を付与されているものでもよい。また、ＳＥで生成されるメッセージ（７）も、ＳＥの署名を付与する代わりに、対応する共有鍵で暗号化、または署名を付与されているものでよい。
このように、チケットＩＤに関連付けられた共有鍵を用いることで、ＳＥにおける証明書の検証などの公開鍵暗号処理を省くことができ、ＳＥへの付加が軽くて処理の早いチケットサービスを提供することができる。
＜実施の形態１１＞
実施の形態８、９、１０では、処理のメッセージの中で、相手から送られた乱数を含めた処理データに署名や暗号化をしたデータとは別に、自ら生成した乱数を送信する例を示した。しかし、相手から送られた乱数を含めた処理データに加えて、自ら生成した乱数も含めて、署名や暗号化をしたデータを送信してもよい。
例えば、図３５のメッセージ（３）では、Ｓｉｇ＿ＳＥ（ＳＴＡＲＴＲＥＧ，Ｒａｎｄｏｍ１）とＲａｎｄｏｍ２となっているが、Ｓｉｇ＿ＳＥ（ＳＴＡＲＴＲＥＧ，Ｒａｎｄｏｍ１，Ｒａｎｄｏｍ２）としてもよい。こうすることで、乱数の差し替えを検知することができる。
以上説明したように、本発明によれば、複数のサービスサーバ運営者がＳＥの発行コストを分担することで、ＳＥを用いたセキュアなモバイルサービスの提供が容易になる。また、サービス管理者が発行する証明書を持つものだけしかＳＥを用いたサービスを提供でないので、ＳＥのコストを払っていないもののＳＥの利用を防ぐことができる。
また、本発明によれば、サービス管理者が発行する証明書の種類によって、ＳＥのサービスアイテム登録領域へのアクセスを制限することができるので、事業者別にも権利の制限を設定することができる。また、発行するサービス証明書の種類により、発行手数料などを変えるといった柔軟な運営が可能となる。
また、本発明によれば、サービス事業者は、一度発行したＳＥにも、リモートからセキュアに、ユーザの求めるサービスを追加することができる。これにより、サービス管理者はＳＥ１０１の発行管理をより柔軟に行えるようになる。ユーザも、必要なサービスだけを後から追加できるので、利便性が向上する。また、サービスサーバも、すでにユーザが所有しているＳＥ１０１に、あとから開始したサービスを追加することができるので、市場が広がる。
また、本発明によれば、ＳＥのインターフェイスは公開なので、ユーザはどのＳＥ対応の携帯電話でも、買ってきたＳＥを挿入することで、好みのサービスを受けることができる。
また、本発明によれば、ＳＥに固有の情報を含まないチケットであっても、チケットデータ本体は、ＳＥ以外のメモリに暗号化せずに保存することが可能となった。
また、本発明によれば、ユーザがチケットデータを自由にコピーしたり、メールに添付して友人に送信することができる。友人にチケットを譲りたいとき、まずチケットをメールなどで送信して友人がデータを見てから実際のチケット移動の処理を行うことができる。
また、本発明によれば、チケット発行時も、チケットデータをユーザにメールなどで送信し、購入したいユーザは指定された情報どおりに支払い処理を済ませると、有効なチケットとなるといったことができるので、発行サーバは、チケットのプロモーションの自由度が上がる。また、発行サーバは、支払い前の整理券と支払い後のチケットを別に発行管理する必要がない。
また、本発明によれば、サービスサーバがＳＥに特定のサービスアイテムが登録されているか確認したい場合、サービスサーバが発行した乱数を含むＳＥの署名つきのデータにより、確認できる。
また、本発明によれば、チケットの改札やＳＥ間のサービスアイテム移動処理に関して、サービス登録領域に登録された情報のみ送信すればよいので、データ通信量が減少した。
また、本発明によれば、ＳＥ間のサービスアイテムの移動処理において、移動先と移動元のＳＥの２つともに同時にサービスアイテムが存在することなく、ＳＥ間のサービスアイテムの移動が可能となる。
また、本発明によれば、ＳＥの高機能化に伴い、多様な性能なＳＥが混在する市場になっても、サービスサーバ側のインターフェイスは変えずに対応することができる。
また、本発明によれば、サーバが介すことなく、ＳＥ間でセキュアなチケット譲渡が行える。譲渡を行っても、譲渡履歴を付加しないため、プライバシーが保たれ、またチケットデータ量が増えない。
また、本発明によれば、チケット発行時にＳＥで生成した乱数をチケットデータの価値情報の一部に含めて発行する。こうすることで、通信路での盗聴や、差し替え攻撃にも対抗できるしくみになっている。
また、本発明によれば、改札必須情報に対して付与された送り手側の署名を外してＳＥに格納し、チケット使用時にはＳＥの署名を付加する。このため、一度ＳＥに格納されたチケットデータは、ＳＥの署名なしにＳＥの外へ出ない。また署名付きデータには、処理の目的が含まれる。そのため、オープンなＰＫＩの仕組みを用いて少ないＳＥ領域を用いたサービスが実現できる。
また、本発明によれば、人気チケットの発売時など決済処理の負荷が課題であった。本システムによれば、改札必須部をＳＥに登録する処理を行わないとチケットが有効にならないため、チケットデータ（ユーザ表示部）は、整理券と本券で共通に使うことができる。そのため、発行管理の手間を増やすことなく、整理券を用いて決済処理の負荷を分散できる。
また、本発明によれば、ＳＥを用いたエラーリカバリーのプロトコルを用いて、自動でエラーリカバリーの処理が行え、保守の手間を軽減できる。このエラーリカバリーのプロトコルでは、チケットの操作をまたがったエラーや不正を検知し、復旧することができる。また、ローカルでもリモートでもエラーリカバリーのサービスを提供することができる。
本明細書は、２００２年３月１３日出願の特願２００２−０６９３６２および２００３年１月１５日出願の特願２００３−００７６８４に基づくものである。これの内容はすべてここに含めておく。
【図面の簡単な説明】
図１は、本発明の実施の形態１に係るＳＥを用いたセキュアモバイルサービスシステムの概略構成をモデル化して示すブロック図である。
図２は、本発明の実施の形態１においてサービス管理者が発行するＳＥのモデル図である。
図３は、本発明の実施の形態１においてサービス管理者が発行済みのＳＥ上に、サービス領域を追加するサービスのモデル図である。
図４は、本発明の実施の形態１においてサービス管理者がチケットサービスの管理を行う場合のモデル図である。
図５は、本発明の実施の形態２に係るＳＥの認証処理メッセージの例を示す図である。
図６は、本発明の実施の形態２においてＳＥがサービスサーバの認証を行う場合のメッセージの例を示す図である。
図７は、本発明の実施の形態２においてＳＥとサービスサーバが相互認証を行う場合のメッセージの例を示す図である。
図８は、本発明の実施の形態２において公開鍵暗号を使ったサーバ認証処理のメッセージ例を示す図である。
図９は、本発明の実施の形態２において公開鍵暗号を用いた相互認証のメッセージの例を示す図である。
図１０は、本発明の実施の形態３に係るセキュアモバイルサービスシステムのチケットサービスで用いられるチケットデータのモデル図である。
図１１は、本発明の実施の形態３においてチケット格納のモデル図である。
図１２は、本発明の実施の形態３において発行サーバ対応のＳＥのメッセージの例を示す図である。
図１３は、本発明の実施の形態３においてダウンロード処理のメッセージ例を示す図である。
図１４は、本発明の実施の形態３において署名付き確認メッセージを用いたダウンロード処理のメッセージ例を示す図である。
図１５は、本発明の実施の形態３において配信鍵を用いたダウンロード処理のメッセージ例を示す図である。
図１６は、本発明の実施の形態３において公開鍵暗号を用いたダウンロード処理のメッセージ例を示す図である。
図１７は、本発明の実施の形態３において登録証明処理のメッセージ例を示す図である。
図１８は、本発明の実施の形態３において改札処理のメッセージ例を示す図である。
図１９は、本発明の実施の形態３において改札前後のチケットのモデル図である。
図２０は、本発明の実施の形態３においてＳＥ間でのチケット移動のＳＥのメッセージ例を示す図である。
図２１は、本発明の実施の形態３においてＳＥ間でのチケット移動処理のメッセージ例を示す図である。
図２２は、本発明の実施の形態３において公開鍵暗号を用いたＳＥ間でのチケット移動処理のメッセージ例を示す図である。
図２３は、本発明の実施の形態４に係るセキュアモバイルサービスシステムのサーバ認証とチケットダウンロード処理の混合処理のメッセージ例を示す図である。
図２４は、本発明の実施の形態４においてサーバ認証処理と改札処理の混合メッセージ例を示す図である。
図２５は、本発明の実施の形態４において相互認証処理とＳＥ間でのチケット移動処理の混合メッセージ例を示す図である。
図２６は、本発明の実施の形態５に係るセキュアモバイルサービスシステムの処理能力の低いＳＥを用いたサーバ認証処理とダウンロード処理の混合メッセージ例を示す図である。
図２７は、本発明の実施の形態５において処理能力の低いＳＥを用いたサーバ認証処理と改札処理の混合メッセージ例を示す図である。
図２８は、本発明の実施の形態５において処理能力の低いＳＥを用いた相互認証処理とＳＥ間でのチケット移動処理の混合メッセージ例を示す図である。
図２９は、本発明の実施の形態６に係るセキュアモバイルサービスシステムのチケットのダウンロード処理のメッセージ例を示す図である。
図３０は、本発明の実施の形態６においてチケットの改札処理のメッセージ例を示す図である。
図３１は、本発明の実施の形態６においてチケットの移動処理のメッセージ例を示す図である。
図３２は、本発明の実施の形態７において、図２９に相当するチケットのダウンロード処理のメッセージ例を示す図である。
図３３は、本発明の実施の形態７において図３０に相当するチケットの改札処理のメッセージ例を示す図である。
図３４は、本発明の実施の形態７において図３１に相当するＳＥ間のチケット移動処理のメッセージ例を示す図である。
図３５は、本発明の実施の形態８におけるダウンロード処理の例図である。
図３６は、本発明の実施の形態８におけるチケットの証明処理の例図である。
図３７は、本発明の実施の形態８における改札処理の例図である。
図３８は、本発明の実施の形態８における改札処理（退場処理）の例図である。
図３９は、本発明の実施の形態８におけるチケットの移動処理の例図である。
図４０は、本発明の実施の形態９における通信相手管理機能の処理の例図である。
図４１は、本発明の実施の形態９におけるエラーリカバリー処理の例図である。

Claims (15)

1. サービスを実行するための情報を格納したモジュールであって、
   前記モジュールは耐タンパな記憶媒体で構成され、
   前記サービスを実行するためのアプリケーションを格納したサービスアプリケーション格納手段と、
   前記サービスを管理するサービス管理者の証明書であるサービス管理者証明書を格納するサービス管理者証明書格納手段と、
   前記サービスを実行するために必要な情報であるサービスアイテムを格納するサービスアイテム格納手段と、
   を備えるサービス実行モジュール。
2. サービスの提供元であるサービスサーバからサービスサーバ証明書を受信し、サービスサーバ証明書をサービス管理者証明書を用いて検証し、検証に成功した場合、サービスアイテムを用いて当該サービスを実行する、
   請求項１記載のサービス実行モジュール。
3. サービスアプリケーション格納手段には、新たに追加されるサービスである追加サービスを実行するための情報である追加サービス情報を格納するための追加サービス情報格納アプリケーションが格納され、
   サービス管理者証明書格納手段には、前記追加サービス情報の発行を管理する追加サービス情報発行管理者の証明書である追加サービス情報発行管理者証明書が格納され、
   サービスアイテム格納手段には、前記追加サービス情報を格納するために必要な情報である追加サービス情報格納アイテムが格納され、
   追加サービス情報の提供元である追加サービス情報提供サーバから、追加サービス情報提供サーバ証明書を受信し、追加サービス情報提供サーバ証明書を追加サービス情報発行管理者証明書を用いて検証し、検証に成功した場合、追加サービス情報格納アイテムを用いて、追加サービスを実行するための追加サービスアプリケーションと、追加サービスを管理する追加サービス管理者の証明書である追加サービス管理者証明書と、追加サービスを実行するために必要な追加サービスアイテムと、を格納する、
   請求項１記載のサービス実行モジュール。
4. チケットデータを発行する発行サーバから発行サーバ証明書を受信し、発行サーバ証明書をサービス管理者証明書を用いて検証し、検証に成功した場合、チケットデータに記載された情報の一部又は全部を、サービスアイテム格納手段へ格納する、
   請求項１記載のサービス実行モジュール。
5. 耐タンパではない記憶媒体であるサービスデータ保存領域と直接又は間接的にデータの送受信が可能であり、
   発行されたチケットデータはサービス保存領域に格納され、前記チケットデータのうち、改札処理に必要な情報はサービスアイテム格納手段へ格納される、
   請求項４記載のサービス実行モジュール。
6. チケットデータの改札処理を行う改札機から改札機証明書を受信し、改札機証明書をサービス管理者証明書を用いて検証し、検証に成功した場合、サービスアイテムを用いて当該改札処理を行う、
   請求項４記載のサービス実行モジュール。
7. チケットデータは、チケットＩＤと、チケット改札に関する時間的情報及び／又はチケット改札に関する空間的情報と、を含む改札必須情報を有し、
   前記改札必須情報は、チケットデータを発行した発行者の署名、チケットデータを改札処理する改札機の署名、又はサービス実行モジュール自身の署名のいずれかがされている、
   請求項４に記載のサービス実行モジュール。
8. 耐タンパな記憶領域であるセキュア領域を有し、任意のサービスを実行するモジュールであって、
   前記サービスを管理するサービス管理者の公開鍵であるサービス管理者公開鍵を格納する公開鍵格納手段と、
   前記サービスを実行するために必要な情報であるサービスアイテムを格納するアイテム格納手段と、
   公開鍵格納手段、アイテム格納手段、及び当該モジュールにおける処理の制御を行う処理制御手段と、
   を前記セキュア領域内に備えるサービス実行モジュール。
9. 処理制御手段は、前記サービスに関する情報であるサービス情報を発行する発行主体から、前記サービス情報の登録要求を受けると、
   前記登録要求に含まれ、サービス管理者が署名した発行者証明書を、サービス管理者公開鍵で検証した後、サービス情報を受信し、
   前記サービス情報に含まれる署名情報を自身の秘密鍵で検証した後、前記サービス情報に含まれるサービスアイテムを抽出し、アイテム格納手段へ格納する、
   請求項８に記載のサービス実行モジュール。
10. 非耐タンパな記憶領域である通常領域を有し、
    サービス情報のうち、少なくともサービスアイテムを除いた情報である二次情報を格納する二次情報格納手段を前記通常領域内に備えた
    請求項９に記載のサービス実行モジュール。
11. あるサービスアイテムの一部又は全部の情報である譲渡情報を譲渡する場合、譲渡情報の譲渡処理より前に、前記サービスアイテムに対応する二次情報を前記譲渡処理の相手に送信する、
    請求項１０に記載のサービス実行モジュール。
12. あるサービスアイテムの一部又は全部の情報である譲受情報を譲受する場合、譲受情報の譲受処理より前に、前記サービスアイテムに対応する二次情報を前記譲受処理の相手から受信する、
    請求項１０に記載のサービス実行モジュール。
13. サービスを実行処理するための通信相手に関する情報を格納する通信相手格納手段と、
    前記通信相手との処理の履歴を格納する処理履歴格納手段と、
    をセキュア領域内に備える請求項１０に記載のサービス実行モジュール。
14. 前記通信相手からの処理メッセージの履歴を格納するメッセージ履歴格納手段を通常領域内に備える、
    請求項１３に記載のサービス実行モジュール。
15. 制御手段は、ある処理のエラーを検出すると、メッセージ履歴格納手段より前記処理に関する処理メッセージを取得し、前記メッセージに再度応答する、
    請求項１４に記載のサービス実行モジュール。

Images