JP4843028B2 - ３ｇ無線ネットワークのセキュアな仮想ポイントサービス - Google Patents

Description

本発明は、事業者を介した任意の２人の加入者間でピアツーピアの取引を可能にする無線ネットワークに関する。より詳細には、本発明は、電子財布としてモバイル無線デバイスを使用して取引の支払いを行うことが可能な３Ｇ無線ネットワークのセキュアな仮想ポイントサービスに関する。

（関連出願の相互参照）
本願は、Ｆａｒａｍａｋ Ｖａｋｉｌらの名で２００５年５月１７日に出願された「Secure Virtual Point of Service for 3G Wireless Networks」という名称の米国仮出願第６０／６８１，６０３号に関連し、この出願を基礎として優先権を主張するものである。

誰もが過剰なほどのクレジットカードを所有し、クレジットカードによる支払いは、事実上、オンライン取引であっても実際の店舗での取引であっても、購入者と販売者との間で日常的な取引を行う一般的な方式となっている。一方で、クレジットカードが一杯入った財布を持ち歩くことは不便であり、紛失、盗難、不正行為の危険性がある。他方、現在の社会では銀行取引や買い物等のオンライン取引が日常化し、一般的になりつつある。オンラインで購入する際には、購入者が個人の資格証明（credential）と支払い情報とを提供することが必要となる。この慣行は、個人情報および支払い情報がネットワークを介して伝送されることを理由として、セキュリティ、プライバシ、匿名性などの多くの問題をもたらす。例えば、マーチャント（merchant）は、住所や電子メールといった個人の資格証明を他の業務提携者と共有することがある。また、マーチャントは、要求されない広告情報を直接購入者に送信することもある。

支払いも、オンライン取引における主要な問題の１つである。支払いの種類の１つは、クレジットカードを使用するものである。典型的なクレジットカードによる購入では、クレジットカード番号および購入数量に加えて、個人識別情報を入力することが、購入者に要求される。マーチャントは、その情報を受信し、その情報をマーチャントの銀行に転送する。マーチャントの銀行は、購入者の銀行から許可を得ようと試みる。そして、購入者の銀行は、その数量の購入を許可し、許可コードをマーチャントの銀行に送信し、マーチャントの銀行は、その許可をマーチャントに通知する。許可が通知されると、マーチャントは、その取引を承認することになる。これは、マーチャントへの直接の支払いである。

第２の種類の支払いは、電子的な支払い手段として、セルラ電話や携帯電話を使用するものである。例えば、ＮＴＴは、セルラ電話または携帯電話を使用して特定の商品の支払いを容易にするシステムを開発した。このシステムは、Ｉモード電話と呼ばれる。Ｉモード電話は、ユーザがインターネットおよびウェブにアクセスすることができる電話機である。この電話機は、電子メールやテキストメッセージを送信し、ウェブサイトへのアクセスを提供する。Ｉモードシステムでは、公式サイトと非公式サイトとの２種類のウェブサイトがある。公式サイトは、ＤｏＣｏＭｏによって承認されたサイトである。公式サイトは、ＤｏＣｏＭｏとの事前の提携または関係を有する。「公式サイト」から行われた購入は、自動的に加入者の月々の請求に課金される。非公式サイトは、ＤｏＣｏＭｏとの間に事前の提携または関係を持たず、非公式サイトからの購入は、加入者の月々の請求に課金されない。そうしたサイトは、ＤｏＣｏＭｏの課金システムへのアクセス権を持たない。支払いは、クレジットカードや他の支払い形態を使用して行わなければならない。

セルラ電話または携帯電話を使用した支払いを可能にする別のシステムは、Ｖｏｄａｆｏｎｅの「ｍ−ｐａｙ」または「ｓ−ｓｈｏｐｐｉｎｇ」である。支払いは、月々の請求に課金されるか、Ｐａｙ Ａｓ Ｙｏｕ Ｔａｌｋのクレジットから差し引かれる。支払いは、インターネット購入のためのユーザ名およびパスワードと、購入用のＰＩＮ番号とによって許可される。ｍ−ｐａｙサービスは、ＰＯＳ（Point Of Sale）クライアントをマーチャントの電子商取引プラットフォームに組み込むことによって機能する。このＰＯＳは、Ｖｏｄａｆｏｎｅのｍ−ｐａｙ課金サーバと通信して、支払いを許可し、取引の払い戻しを開始する。

ＰＯＳは、支払い、許可、および払い戻しの取り扱いを管理する。Ｖｏｄａｆｏｎｅのｍ−ｐａｙ課金サーバは、消費者の認証、支払い処理、および応答処理を管理する。

Ｖｏｄａｆｏｎｅのｍ−ｐａｙおよびＤｏＣｏＭｏの支払いシステムは、いずれも用途が限られている。購入者は、購入者の特定の電話会社との間に予め確立された明示的な事業関係を持たないマーチャントには、携帯電話を使用して取引の支払いをすることができない。これらのシステムは、明示的な提携を有するマーチャントおよびコンテンツプロバイダ、すなわち公式ウェブサイトとの間でのみ機能する。また、これらのシステムは、プライバシおよびセキュリティの問題がある。Ｖｏｄａｆｏｎｅのｍ−ｐａｙおよびＤｏＣｏＭｏは、明示的な公開鍵による管理インフラストラクチャを用いている。さらに、Ｖｏｄａｆｏｎｅのｍ−ｐａｙシステムは、購入数量に制限がある。

しかしながら、従来技術の制限をなくして、３Ｇネットワークの加入者が日常的な取引および支払いにモバイルデバイスを使用することを可能にするシステムが必要とされている。具体的には、３Ｇ加入者のプライバシおよび匿名性を保証し、その事業者、マーチャント、および加入者を事後拒否（repudiation）から保護するシステムが必要とされている。

独自のネットワークアプリケーション機能が提供される。すなわち、３Ｇネットワークの認証、許可、ＩＤ管理、および課金のイネーブラ（enabler）を連携させ、かつ加入者のモバイルデバイスをクレジット／負債支払いデバイス（credit/debt payment device）に変える、セキュアな仮想ポイントサービス（ＳＶＰＯＳ）が提供される。このＳＶＰＯＳは、事後拒否防止のイネーブラも含む。このＳＶＰＯＳシステムは、加入者がマーチャントと取引を行うことを可能にする。このＳＶＰＯＳは、３Ｇ事業者によって管理することができる。

特別に、ＳＶＰＯＳは、商取引の決済を管理し、制御する。ＳＶＰＯＳは、認証のために、購入者およびマーチャントの両方をブートストラップサーバ機能（ＢＳＦ）にリダイレクトする。認証の後、ＳＶＰＯＳは、購入者から支払いの許可を得、マーチャントが支払いの手段としてＳＶＰＯＳを使用して購入者に製品またはサービスを販売できる状態になったときに、その支払いの許可を再確認する。ＳＶＰＯＳは、パッケージの少なくとも一部分からなる計算されたマーチャントのハッシュと、このパッケージの少なくとも同じ部分からなる計算された購入者のハッシュとを受信して、事後拒否を防止する。このパッケージは、少なくとも、製品ＩＤと、取引の受領書とを含む。ＳＶＰＯＳは、計算された両方のハッシュを比較し、その比較に基づいてマーチャント暗号鍵を購入者に送信する。ＳＶＰＯＳは、購入者がパッケージに満足したとの判定に基づいて、支払いを認可させ、マーチャントに転送させる。

ＳＶＰＯＳは、商取引の支払い情報を記憶させる。支払い情報は、商取引の価格と、その受領書とを含む。

購入者がパッケージに満足しない場合、ＳＶＰＯＳは、商取引の調停（arbitration）を行う。この調停プロセスでは、マーチャントがパッケージに正しい製品と製品ＩＤとを含めたかどうかが判定される。パッケージが正しい製品を含んでいなかった場合、マーチャントには、その状況に対処する機会が与えられる。

ＳＶＰＯＳは、通信ネットワークに接続されたデバイスを使用した商取引のための決済システムの一部である。この決済システムは、購入者およびマーチャントの認証ベクトルを記憶するホーム加入者サーバ（ＨＳＳ）を備える。ＨＳＳは、ブートストラップサーバ（ＢＳＦ）と連携して機能して、購入者およびマーチャントの双方を認証する。ＢＳＦは、ＨＳＳから購入者およびマーチャントの認証ベクトルを取得し、ＢＳＦからのチャレンジに対する応答に基づいて購入者およびマーチャントのＩＤを認証するために、その認証ベクトルの情報を使用して購入者およびマーチャントにチャレンジを発行する。決済システムは、購入者の口座からマーチャントの口座に支払いを振り込み、商取引の記録を保持するＰＡＲＬＡＹサーバをさらに備える。ＳＶＰＯＳは、認証のために、購入者およびマーチャントをＢＳＦにリダイレクトし、認証の後に、購入者のモバイルデバイスをモバイル財布として使用した商取引の支払いの許可を得、購入者暗号鍵をマーチャントに送信することにより、この決済システムの動作を管理する。ＳＶＰＯＳは、事後拒否防止イネーブラを含み、このイネーブラは、パッケージの少なくとも一部分からなる購入者のハッシュ値と、このパッケージの少なくとも同じ部分からなるマーチャントのハッシュ値とを比較する。購入者のハッシュ値とマーチャントのハッシュ値とが同じである場合、ＳＶＰＯＳは、マーチャント暗号鍵を購入者に送信する。購入者がＳＶＰＯＳにパッケージを返送しなければ、ＳＶＰＯＳは、ＰＡＲＬＡＹサーバを使用したマーチャントへの支払いを認可する。

この決済システムは、購入者およびマーチャントと、決済システムとの間の仲介（intermediary）として機能して、購入者の匿名性を提供する認証プロキシをさらに備える。

電子支払い方法も提供される。この方法は、マーチャントに対する製品またはサービスの支払いに関する購入者からの要求を開始するステップを備える。この要求は、モバイル電子デバイスを使用して開始される。次いで、購入者暗号鍵およびマーチャント暗号鍵の両方が決定される。暗号化されたパッケージが生成される。暗号化されたパッケージは、製品またはサービスに関する識別情報を含む。このパッケージは、購入者暗号鍵およびマーチャント暗号鍵の両方を使用して暗号化される。パッケージの少なくとも一部分からなるマーチャントのハッシュと、このパッケージの少なくとも同じ部分からなる購入者のハッシュとの両方が計算される。マーチャントのハッシュおよび購入者のハッシュの両方が計算されると、それらのハッシュが比較される。この比較に基づいて、マーチャント暗号鍵が購入者に送信される。次いで、マーチャント暗号鍵を使用して、パッケージが復号される。購入者は、パッケージが正しいものであるかどうかを判定し、この判定に基づいて製品またはサービスの支払いが認可される。

モバイル電子デバイスは、携帯電話であってもよいし、ポータブルコンピュータであってもよい。

この電子支払い方法は、モバイル電子デバイスを使用している購入者と、製品またはサービスを販売しているマーチャントとを認証するステップをさらに備える。購入者の認証プロセスと、マーチャントの認証プロセスとは類似している。購入者については、認証プロセスは、ブートストラップサーバに第１の取引ＩＤを要求することと、ブートストラップサーバがＨＳＳから購入者の認証ベクトルを取得することと、購入者にチャレンジを発行することと、チャレンジに応答することであって、この応答は購入者暗号鍵を含む、応答することと、第１の取引ＩＤを購入者およびＳＶＰＯＳに送信することとを含む。マーチャントについても同様に、認証プロセスは、ブートストラップサーバに第２の取引ＩＤを要求することと、ブートストラップサーバがＨＳＳからマーチャントの認証ベクトルを取得することと、マーチャントにチャレンジを発行することと、チャレンジに応答することであって、この応答はマーチャント暗号鍵を含む、応答することと、第２の取引ＩＤをマーチャントおよびＳＶＰＯＳに送信することとを含む。第１の取引ＩＤと第２の取引ＩＤとは異なるものである。

この電子支払い方法は、ＳＶＰＯＳを介した支払いを許可するステップと、その許可を受信すると、マーチャントに購入者暗号鍵を送信するステップとをさらに備える。

購入者暗号鍵およびマーチャント暗号鍵は両方とも、モバイルデバイスにおけるＳＩＭカード内と、マーチャントに配置されたＳＩＭカード内の一意な識別情報に基づいて生成される。購入者暗号鍵およびマーチャント暗号鍵は、取引ごとに異なるものである。

暗号化されたパッケージには、製品またはサービス、製品ＩＤ、および受領書を含めることができる。製品が正しいものでない場合、購入者は、調停のためにパッケージをＳＶＰＯＳに送信する。調停は、正しい製品ＩＤが送信されたかどうかを判定することと、正しい製品が送信されたかどうかを判定することと、送信された製品ＩＤと送信された製品とを比較することとを含む。正しい製品は、データベースに記憶された製品ＩＤと、送信された製品ＩＤとの比較に基づいて判定される。製品が正しいと判定された場合、購入者は、ＳＶＰＯＳに受領書を送信し、支払いが認可される。

この電子支払い方法は、パッケージを購入者に送信するステップと、購入者暗号鍵のみを使用してパッケージを復号するステップと、パッケージに含まれる製品またはサービスに関する識別情報を確認するステップと、識別情報が要求された製品またはサービスと一致するかどうかを判定するステップと、その判定に基づいて購入者のハッシュを計算するステップとをさらに備える。ハッシュ関数は、鍵付きハッシュであってもよいし、鍵のないハッシュ関数であってもよい。鍵付きハッシュの場合、その鍵は、公開鍵インフラストラクチャを介して取得される。ハッシュが鍵付きハッシュである場合、パッケージは、ハッシュ計算のためにマーチャントによって使用された鍵も含んでいる。

製品またはサービスを購入する方法も開示される。製品またはサービスの購入および支払いの要求がマーチャントに対して開始される。この要求は、モバイル電子デバイスを使用して開始される。次いで、購入者暗号鍵が決定される。次いで、購入者は、マーチャントからパッケージを受信する。このパッケージは、少なくとも購入者暗号鍵を使用して暗号化される。このパッケージは、少なくとも、当該製品または当該サービスに関する識別情報を含む。ＳＶＰＯＳからマーチャント暗号鍵を受信するために、パッケージの少なくとも一部分からなるハッシュが計算され、そのハッシュがＳＶＰＯＳに送信される。パッケージは、マーチャント暗号鍵を使用して復号され、購入者は、パッケージが正しいものであるかどうかを判定する。この判定に基づいて、製品またはサービスの支払いが認可される。

マーチャント暗号鍵は、計算された購入者のハッシュが正しい場合にのみ受信される。計算された購入者のハッシュと、計算されたマーチャントのハッシュとが一致する場合、計算された購入者のハッシュは正しい。マーチャントは、マーチャントのハッシュを計算する。この製品またはサービスを購入する方法は、モバイル電子デバイスを使用している購入者と、製品またはサービスを販売しているマーチャントとを認証するステップをさらに備える。

製品またはサービスを販売する方法も開示される。マーチャントは、製品またはサービスの購入および支払いの要求を購入者から受信する。この要求は、モバイル電子デバイスを使用して行われる。購入者は、認証および支払いのために、ＳＶＰＯＳに導かれ、ＳＶＰＯＳにおいて、購入者鍵も生成される。マーチャントも同様に認証され、次いで、マーチャント暗号鍵が決定される。次いで、暗号化されたパッケージが生成される。暗号化されたパッケージは、製品またはサービスに関する識別情報を含む。暗号化されたパッケージは、マーチャント暗号鍵および購入者暗号鍵の両方を使用して暗号化される。暗号化されたパッケージは、購入者に送信される。暗号化されたパッケージの少なくとも一部分からなるマーチャントのハッシュが計算され、そのハッシュがＳＶＰＯＳに送信される。マーチャントのハッシュと購入者のハッシュとの両方が比較される。この比較に基づいて、マーチャント暗号鍵が購入者に送信される。購入者が満足したかどうかの判定に基づいて、当該購入および支払いの決済が行われる。

暗号化されたパッケージには、製品またはサービス、製品ＩＤ、および受領書を含めることができる。暗号化されたパッケージに製品が含まれる場合、満足したかどうかの判定は、その製品が正しいものであるかどうかの判定を含む。購入者がこの判定を行う。製品が正しくない場合、購入および支払いを決済するステップは調停を含む。製品が正しい場合、購入および支払いを決済するステップは、ＳＶＰＯＳによって受領書を受信するサブステップと、ＳＶＰＯＳを介して購入者からの支払いを受領するサブステップとを含む。

ＳＶＰＯＳは、認証が成功した後にのみ、ＳＶＰＯＳからマーチャントに購入者暗号鍵を送信する。マーチャント暗号鍵は、計算されたマーチャントのハッシュと、計算された購入者のハッシュとが同じであることが判明した場合にのみ、購入者に送信される。

図１は、本発明の一実施形態による、いくつかの３Ｇネットワークコンポーネントを備えるセキュアな仮想ポイントサービス（ＳＶＰＯＳ）１００を示している。ＳＶＰＯＳ１００は、３Ｇ無線ネットワークのセキュリティ、認証、許可、および支払いの機能を連携させて、３Ｇにおける購入者と３Ｇにおけるマーチャントとの間で行われる購入を可能／容易にする独自のネットワークアプリケーション機能である。図１では、３Ｇにおける購入者は、ユーザデバイスまたはユーザ機器（ＵＥ）１１０と表記されている。ＵＥまたは購入者１１０は、無線ネットワークコントローラ（ＲＮＣ）１２５を仲介として使用して、インターネット１５０と通信することができる。ＳＶＰＯＳ１００は、モバイルデバイスを電子財布に変える。モバイルデバイスは、携帯電話、ＰＤＡ、ラップトップなど、任意の種類のモバイルデバイスとすることができる。デバイスの種類に関する唯一の制限は、３Ｇ ＧＡＡ対応であることである。同様に、マーチャント１２０も、どのような種類のマーチャントとすることができるが、マーチャント１２０は、３Ｇ ＧＡＡ対応のサーバを備えなければならない。図１では、マーチャント１２０がインターネット１５０上に位置しているものとして示されているが、マーチャント１２０は、インターネットにアクセスできる実際の店舗でよく、必ずしもウェブサイトだけを有するとは限らない。ＳＶＰＯＳ１００は、３ＧＰＰのＧＡＡ（Generic Authentication Architecture）を利用し、これを新規の事後拒否防止機構と組み合わせて、モバイルデバイスをモバイル財布に変える。ＳＶＰＯＳ１００は、例えばＵＥ１１０などの加入者または購入者がマーチャント１２０と取引を行うことを可能にするとともに、３Ｇ事業者が商品の支払いをすることをマーチャント１２０に通知する。このシステムは、ＧＡＡを使用して加入者１１０およびマーチャント１２０を認証し、２つの暗号鍵を配布する。この暗号鍵の１つは購入者１１０に配布され、もう一方の暗号鍵はマーチャント１２０に配布される。

図１に示すように、実線はトランスポート（transport）を表している。トランスポートとは、ネットワークを介した加入者／ユーザのデータ（例えばメッセージの内容や通話中の会話の内容）の交換を意味する。破線は制御シグナリングを表している。シグナリングとは、サービスをサポートするためのネットワーク制御データの交換、例えば通話を確立するためのネットワークエンティティ間のデータ交換を指す。

ブートストラップ機能（ＢＳＦ）１３０、ＨＳＳ１３５、認証プロキシ（ＡＰ）１４０は、加入者およびマーチャントを認証するＧＡＡに属しており、Ｐａｒｌａｙ１４５は、事業者の会計および課金エンティティに課金の記録を提供する手段を提供する。ＮＲ１０５は、事後拒否防止機能エンティティを表している。例示した実施形態において、ＮＲ１０５は、ＳＶＰＯＳ１００と一体化されているものとして図示されているが、ＮＲ１０５は、分離させておくこともできる。また、図１では、ＡＰ１４０が、ＵＥ１１０とＳＶＰＯＳ１００との間の仲介として示されている。ＡＰ１４０は、加入者またはＵＥ１１０の匿名性を守るために使用される。加入者のＵＥ１１０とＳＶＰＯＳ１００との間に位置するＡＰ１４０は、ＵＥ１１０のためのアプリケーション機能（ＮＡＦ）の役割を担う。ＵＥ１１０は、ＡＰ１４０との間にＴＬＳトンネルを確立し、ＳＶＰＯＳ１００に転送するために、ＵＥ１１０自身のすべてのパケットをＡＰ１４０に送信する。ＡＰ１４０の利点は、３Ｇ事業者のためのプライバシポリシの実施ポイント（enforcement point）として機能できることであり、各種サービスのための異なるプライバシ／匿名性ポリシを実施できることである。ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１２７は、ＧＰＲＳネットワーク、例えば無線ネットワークと、外部のパケットデータネットワーク、すなわちＩＰネットワークとの間のインターフェースとして機能する。ＧＧＳＮ１２７は、サービングＧＲＰＳサポートノード（ＳＧＳＮ）１２６から送信されてくるパケットを、適切なパケットデータプロトコル（ＰＤＰ）フォーマット（例えばＩＰやＸ．２５）に変換し、対応するパケットデータネットワークに送出する。ＰＳＴＮ（公衆交換電話網）１５５は、加入者（ＵＥ）１１０の通話をサポートする。ＳＶＰＯＳ１００は、ＩＭＳのパケット交換ドメインを使用する。

ＳＶＰＯＳ１００は、購入者およびマーチャントの両方を表す１つのエンティティとすることができる。あるいは、２つ以上のＳＶＰＯＳ１００が存在して、１つのＳＶＰＯＳが購入者のＳＶＰＯＳを表し、別のＳＶＰＯＳがマーチャントのＳＶＰＯＳを表してもよい。購入者のＳＶＰＯＳ（以後、ＳＶＰＯＳ_ｂ１００ｂと表記する）と、マーチャントのＳＶＰＯＳ（以後、ＳＶＰＯＳ_ｍ１００ｍと表記する）とは、同じであってもよいし、異なってもよい。それらが同じである場合は、１つのＳＶＰＯＳだけが使用される。ＳＶＰＯＳ_ｂ１００ｂおよびＳＶＰＯＳ_ｍ１００ｍは、セキュアリンク、例えばＩＰＳＥＣトンネルを介して、またはＨＴＴＰ ｏｖｅｒ ＳＳＬを使用して通信する。説明の目的上、ＳＶＰＯＳ_ｂは、説明する機能が購入者のＳＶＰＯＳ１００のみによって行われる場合に参照し、ＳＶＰＯＳ_ｍは、説明する機能がマーチャントのＳＶＰＯＳ１００のみによって行われる場合に参照し、ＳＶＰＯＳ１００は、説明する機能が、購入者のＳＶＰＯＳとマーチャントのＳＶＰＯＳとのうちの少なくとも一方によって実行され得る場合に参照する。

図２を参照して、各要素の機能について説明する。図２は、本発明による電子的な購入の動作のフローチャートを示している。

図２に示すように、ステップ２００で、ＵＥ１１０がマーチャント１２０に商品を要求し、ＳＶＰＯＳ_ｂ１００ｂを使用して支払いが行われることを通知する。マーチャント１２０は、この要求を受信すると、ステップ２０５で、マーチャント１２０自身のＳＶＰＯＳ_ｍ１００ｍにコンタクトして、当該購入および支払いを容易にし、支払いの許可を要求する。ＳＶＰＯＳ_ｍ１００ｍは、ＳＶＰＯＳ_ｂ１００ｂにコンタクトして、取引の認証および許可を得る。ステップ２１０で、ＳＶＰＯＳ_ｂ１００ｂは、自身を認証し、かつ必要な資格証明、例えばその取引の取引識別子（Ｔ−ＩＤ）および暗号鍵を取得するよう、ＵＥ１１０に要求する。

ＳＶＰＯＳ１００は、要求に応じて、３ＧＰＰ ＧＡＡを使用して加入者を認証し、加入者の身元を匿名に保つ。加入者の認証のためにＧＡＡを使用することのいくつかの利点は、効率的であること、３ＧＰＰ標準であること、および、ＡＰの使用を通じて加入者の匿名性をサポートできることである。

ＳＶＰＯＳ１００は、認証のために、ＢＳＦ１３０を用いる。このＢＳＦ１３０は、ＨＳＳ１３５とのインターフェースを有する。ＨＳＳ１３５は、すべての加入者情報のリポジトリである。ＵＥ１１０は、ＢＳＦ１３０を介して、ＨＳＳ１３５との間でＡＫＡ（Authentication Key Agreement）を実行する。ＢＳＦ１３０およびＵＥ１１０において、セッション鍵が導出される。ネットワークアプリケーション機能（ＮＡＦ）またはＳＶＰＯＳ１００は、加入者のプロファイル情報とともに、ＢＳＦ１３０からこのセッション鍵を取り出すことができる。このようにして、ＳＶＰＯＳ１００およびＵＥ１１０は、秘密鍵を共有し、この秘密鍵は、後にアプリケーションのセキュリティのために、特にアプリケーションセッションの開始時にＵＥ１１０およびＳＶＰＯＳ１００を認証するために、使用することができる（整合性および／または秘密性の保護のためにも使用されることがある）。

図３は、ＵＥ１１０の認証のフローチャートを示している。ステップ３００で、ＳＶＰＯＳ_ｂ１００ｂは、ブートストラップのためにＵＥ１１０をＢＳＦ１３０にリダイレクトして、ＵＥ１１０がＢＳＦ１３０から取引識別子を取得し、ＵＥ１１０自身のＳＩＭカード内のＡＫＡを使用してセッション鍵を生成できるようにする。ステップ３０５で、ＵＥ１１０は、ＢＳＦ１３０に取引識別子（ＴＩＤ−ＵＥ）を要求する。ＢＳＦ１３０は、ＴＩＤ−ＵＥを送信する前に、ＵＥ１１０を認証しなければならない。ステップ３１０で、ＢＳＦ１３０は、ＨＳＳ１３５からＵＥの認証ベクトルを取得する。認証ベクトルは、特に、乱数（ＲＡＮＤ）、認証トークン（ＡＵＴＮ）、暗号鍵（ＣＫ）、インテグリティ鍵（ＩＫ）、および予想される応答（ＸＲＥＳ）から構成されるクインテット（quintet）である。認証ベクトルは、ＨＳＳに記憶された、モバイルデバイスに関連付けられた一意なＩＤである。ステップ３１５で、ＢＳＦ１３０は、ＲＡＮＤおよびＡＵＴＮだけを含んだチャレンジメッセージをＵＥ１１０に発行して、ＵＥ１１０自身を認証させる。ステップ３２０で、ＵＥ１１０は、自身のＳＩＭカード内に存在するＡＫＡの標準的な数学関数とともに、そのＲＡＮＤおよびＡＵＴＮ鍵を使用して、ＸＲＥＳと、その取引のセッション鍵（Ｋｓ−ＵＥ）とを導出する。ＡＫＡ鍵生成アルゴリズムは、ＡＵＴＮ、ＲＡＮＤとともに、ＳＩＭカードに保存されている５つの標準的な数学関数の実行可能プログラムを使用して、ＸＲＥＳとＫｓ−ＵＥとを導出する。次いで、ＵＥ１１０は、その鍵を含みＸＲＥＳを含む、チャレンジに対する応答をＢＳＦに送信する。応答、すなわちＸＲＥＳが正しい場合、ステップ３２５で、ＢＳＦ１３０は、ＴＩＤ−ＵＥを送信する。ＸＲＥＳが正しくない場合は、認証が失敗する。応答が正しい場合、ステップ３２５で、ＢＳＦ１３０は、ＴＩＤ−ＵＥを送信する。応答が正しくない場合は、認証が失敗する。ＵＥ１１０は、ＢＳＦからＴＩＤ−ＵＥを受信すると、マーチャント１２０への製品の要求を更新する。更新された要求は、ＴＩＤ−ＵＥとＴＭＳＩ（Temporary Mobile Subscriber Identity）とを含む。

ステップ２１５で、ＳＶＰＯＳ_ｂ１００ｂは、認証が成功したかどうかを判定する。成功したと判定した場合、ＳＶＰＯＳ_ｂ１００ｂは、ＳＶＰＯＳ_ｍ１００ｍにコンタクトしてマーチャントを認証する。Ｎｏの場合、すなわち購入者の認証が成功しなかった場合は、取引が終了する（ステップ２１６）。

ステップ２２０で、マーチャントのＳＶＰＯＳ_ｍ１００ｍは、マーチャント１１０を認証する。マーチャント１２０の認証プロセスの特性は、マーチャント１２０と３Ｇ事業者またはＳＶＰＯＳ１００との関係によって異なる。関係には３種類ある。第１の種類の関係は、マーチャントが３Ｇ事業者の提携先業者である場合であり、これは、マーチャントが事業者との間に明示的な業務提携を有することを意味する。ＧＡＡの分野では、このシナリオにおけるマーチャントサーバは、実質的に、さらなる認証を必要としない「事業者管理下にある」ネットワークアプリケーション機能（ＮＡＦ）とみなすことができる。このシナリオでは、マーチャントのＳＶＰＯＳは、マーチャントを認証する必要がない。第２の種類の関係は、マーチャントが業務の提携先ではなく、サードパーティ業者である場合であり、ＯＳＡ／ＰＡＲＬＡＹまたは同様の機構を利用して、マーチャント自身を事業者に対して認証する。このシナリオでは、マーチャント１２０は、ＧＡＡに対応している場合もあるし、対応していない場合もある。ＧＡＡに対応していない場合、マーチャント１２０は、ＯＳＡ／Ｐａｒｌａｙ認証および検証機構のいずれかを使用して、マーチャント１２０自身をＳＶＰＯＳ_ｍ１００ｍに対して認証し、ＯＳＡ／Ｐａｒｌａｙプラットフォームを通じて、またはマーチャント１２０とその事業者とが合意した他の認証機構を通じて、マーチャント鍵を生成する。マーチャントがＧＡＡに対応している場合、２番目のシナリオは３番目のシナリオと同じになる。第３の種類の関係は、マーチャント１２０が、３ＧネットワークのＳＶＰＯＳに対応する別の加入者である場合であり、これは、マーチャントのアプリケーションサーバが、ＧＡＡ対応であり、３Ｇ事業者のＳＶＰＯＳ１００のサービスに加入していることを意味する。この場合、マーチャント１２０は、ＧＡＡアルゴリズムを使用してマーチャント１２０自身を認証し、マーチャント鍵を生成する。

この場合もＳＶＰＯＳ１００（例えばＳＶＰＯＳ_ｍ１００ｍ）は、認証のために、ＧＡＡを使用する。第２および第３の種類の関係では、マーチャント１２０にとって認証プロセスは同じものになる。この認証プロセスは、マーチャント１２０がＳＩＭカード機能または同様の身元識別機能を有していることを前提とする。マーチャント１２０は、適切なパラメータ（すなわちＴＩＤ−ＵＥ、ＵＥ−ＴＭＳＩ等）を含む更新された要求をＵＥ１１０から受信した後、ＴＩＤ−ＵＥ、ＵＥ、ＴＭＳＩ、価格等を含んだメッセージをＳＶＰＯＳ_ｍ１００ｍに送信して、その取引の許可を要求する。

ＳＶＰＯＳ_ｍ１００ｍは、マーチャント１２０に応答を送信して、マーチャント１２０が自身の取引識別子（ＴＩＤ−ＭＥＲ）およびセッション鍵（Ｋｓ−ＭＥＲ）を取得できるように、マーチャント１２０をＢＳＦ１３０に導く。認証および鍵生成プロセスは、（図３に示した）ＵＥ１１０の場合と同じであるため、詳細には説明しない。

ステップ２２５で、ＳＶＰＯＳ_ｍ１００ｍは、認証が成功したかどうかを判定する。成功したと判定した場合、ＳＶＰＯＳ_ｍ１００ｍは、ＳＶＰＯＳ_ｂ１００ｂにコンタクトし、ＵＥ１１０の最終的な同意を得て、ＵＥ１１０からの支払いを再許可する。認証が成功しなかった場合は、取引が終了する（ステップ２２６）。

図４は、再許可のために実行されるステップ、すなわちステップ２３０のサブステップを示している。

ステップ４００で、マーチャント１２０は、ＳＶＰＯＳ１００を介したＵＥ１１０からの支払いの許可要求を更新する。この要求は、ＳＶＰＯＳ_ｍ１００ｍに送信され、ＴＩＤ−ＵＥ、ＴＩＤ−ＭＥＲ、マーチャントサーバのホスト名、価格等を含む。ＳＶＰＯＳ_ｍ１００ｍは、その要求をＳＶＰＯＳ_ｂ１００ｂに転送する。次いで、ステップ４０５で、ＳＶＰＯＳ_ｂ１００ｂは、ＢＳＦ１３０に対して、セッション鍵Ｋｓ−ＵＥおよびＫｓ−ＭＥＲ両方の要求を送信する。この要求は、ＵＥ１１０およびマーチャント１２０のＴＩＤ、ＵＥ−ＴＭＳＩ、価格等を含む。ステップ４１０で、ＢＳＦ１３０は、鍵、すなわちＫｓ−ＵＥおよびＫｓ−ＭＥＲを送信することにより、要求に応答する。ＳＶＰＯＳ_ｂ１００ｂおよびＳＶＰＯＳ_ｍ１００ｍはいずれも、この鍵にアクセスすることができる。ステップ４１５で、ＳＶＰＯＳ_ｂ１００ｂは、取引を再確認するよう、ＵＥ１１０に要求する。この要求は、両方のＴＩＤと、商品またはサービスの価格とを含む。ＵＥ１１０は、ＴＩＤを含むメッセージを用いて、取引を再確認する。このメッセージは、ＳＶＰＯＳ_ｂ１００ｂに送信される。ＳＶＰＯＳ_ｂ１００ｂは、その確認をＳＶＰＯＳ_ｍ１００ｍに転送する。ＵＥ１１０からの再確認を受信すると、ステップ４２０で、ＳＶＰＯＳ_ｍ１００ｍは、ＴＩＤ、Ｋｓ−ＵＥ、価格等を含んだ応答メッセージをマーチャント１２０に送信して、ＳＶＰＯＳ１００が取引の支払いを承諾することをマーチャント１２０に通知する。

ステップ２３０の許可が成功した場合は、ステップ２４０で、ＵＥの鍵Ｋｓ−ＵＥがマーチャント１２０に送信される。ＳＶＰＯＳ_ｍ１００ｍは、Ｋｓ−ＵＥをマーチャント１２０に送信する。許可が失敗した場合は、ステップ２３６で取引が終了する。

確認を受信すると、マーチャント１２０は、製品の要約またはプレビューを含む事後拒否防止パッケージの作成を開始する。製品が電子的に配信可能である場合、ステップ２４５で、パッケージには、その製品を含めることができる。このパッケージは、電子商取引における主要な問題である事後拒否を防止する。事後拒否防止にはいくつかの理由がある。マーチャント１２０が意図しない間違いを犯し、その結果、加入者が間違ったコンテンツを受け取ってしまう場合がある。正しいコンテンツを受け取った悪意のある加入者が、間違ったコンテンツを受け取ったと主張して、取引の支払いを回避する場合がある。最後に、マーチャント１３０が意図的に間違ったコンテンツを送信して、ユーザが望まない何らかの事から収益を得る場合がある。図１に示したように、ＳＶＰＯＳ１００は、ＮＲ部１０５を含む。ＮＲ部１０５は、検査用のハッシュ関数とデジタル署名とを含めることにより、事後拒否を防止する。

ＳＶＰＯＳ１００は、１回のセッション／取引につき、２つの別個の暗号鍵を必要とする。鍵の１つは加入者に属し、Ｋｓ−ＵＥと表され、もう一方の鍵は、マーチャントに属し、Ｋｓ−ＭＥＲと表される。

一実施形態では、マーチャント１２０は、商品またはサービスを含んだパッケージを作成し、その商品またはサービスは、両方の鍵によってのみ開くことができる。この実施形態は、製品が電子的に配信可能である場合に使用される。マーチャント１２０からＵＥ１１０に配信されるパッケージは、加入者が不正に取引を事後拒否することを防止し、マーチャントがユーザに対して不正行為を犯すことを防止し、コンテンツの著作権侵害からマーチャントを保護し、ユーザが反論できない配信の受領書を提供することを確実にし、３Ｇ事業者が主張および反主張を調査できるようにする。

マーチャント１２０はパッケージを作成し、マーチャント１２０は、自身のセッション鍵（すなわちＫｓ−ＭＥＲ）とＵＥのＴＭＳＩとの連結（concatenation）、すなわち（Ｋｓ−ＭＥＲ‖ＵＥ−ＴＭＳＩ）を使用して、製品をさらに暗号化する。この鍵の意図は、製品を暗号化して、（マーチャントまたは購入者の）ＳＶＰＯＳ１００がＵＥ１１０にＫｓ−ＭＥＲを送信するまでＵＥ１１０が製品を復号できず、製品を見ることができないようにすることである。さらに、この鍵の意図は、要求元のＵＥ１１０でしか製品を表示することができないことを確実にし、製品が他のデバイスにコピーされることを防止することである。ＳＶＰＯＳ１００は、ＵＥ１１０およびＳＶＰＯＳ１００がパッケージの正確な配信を確信した後にのみ、ＵＥにＫｓ−ＭＥＲを送信する。

マーチャント１２０は、Ｋｓ−ＭＥＲ‖ＵＥ−ＴＭＳＩによって暗号化された製品、受領書、および製品ＩＤと、製品のプレビューまたは要約とを含む「パッケージ」、すなわち、Package = Ks-UE{ Preview + Ks-MER‖UE-TMSI {PRODUCT + receipt + PRODUCT-ID }を、ＵＥ１１０に配信するために作成する。「プレビュー」は、ユーザが受け取った製品が要求したものであるかどうかを確認するための製品の要約である。

別の実施形態では、パッケージは、製品の要約または説明、受領書、および製品ＩＤだけを含む。

追加的に、ステップ２４５で、マーチャント１２０はハッシュファイルを生成する。ＳＶＰＯＳの事後拒否防止方式ではハッシュ関数が用いられる。ファイル／コンテンツをハッシュすると、一意（不可逆）なハッシュ出力が作成される。コンテンツが１ビットでも変化すると、異なるハッシュ出力になる。

別の実施形態では、ハッシュファイルは、鍵付きハッシュとすることができる。Ｋｓ−Ｎｒは、標準的なハッシュ関数ｈａｓｈ_ＳＴＤの「事後拒否防止鍵」を表している。ＵＥ１１０およびマーチャント１２０が、事後拒否から取引を保護するために、この鍵を使用する。マーチャント１１０が、自身のＫｓ−Ｎｒを使用してハッシュに署名をすると、そのコンテンツと、そのハッシュがマーチャント１２０によって署名されたこととを保証する一意な署名が生成される。ＵＥ１１０（または、加入者の代理であるＳＶＰＯＳ_ｂ１００）は、マーチャント公開鍵を使用してハッシュを復号することにより、そのハッシュがマーチャント１２０によって署名されたことを検証することができる。

マーチャント１２０は、Ｋｓ−ＭＥＲ‖ＵＥ−ＴＭＳＩによって暗号化された製品、受領書、および製品ＩＤのハッシュ（ｈａｓｈ_ｄと表記する）、すなわち、hash_d = hash_STD (Ks-MER‖UE-TMSI {Product + receipt + Product-ID})を作成し、そのハッシュをＳＶＰＯＳ_ｍ１００ｍに送信する。代替として、ハッシュから製品が除かれてもよい。その場合、ハッシュは、受領書および製品ＩＤだけを含む。

ステップ２５０で、ＵＥ１１０は、パッケージを受信し、Ｋｓ−ＵＥを用いてパッケージを復号する。ＵＥ１１０は、(Preview + Ks-MER‖UE-TMSI {Product + receipt + Product-ID })を導出し、ｈａｓｈ_ｄを計算する。この計算は、マーチャント１２０によって実行される計算と同じである。ＵＥ１１０は、計算したｈａｓｈ_ｄをＳＶＰＯＳ_ｂ１００ｂに送信する。同様に、ハッシュから製品を除くことができる。

ステップ２５５で、ＳＶＰＯＳ１００は、マーチャント公開鍵を使用して、マーチャント１２０から受信した署名付きのｈａｓｈ_ｄを復号し、そのｈａｓｈ_ｄが、ＵＥ１１０から受信したｈａｓｈ_ｄと一致するかどうかを確認する。購入者のＳＶＰＯＳとマーチャントのＳＶＰＯＳとのうちの少なくとも一方が、この復号を行うことができる。ＵＥ１１０から受信したｈａｓｈ_ｄの値とマーチャント１２０から受信したｈａｓｈ_ｄの値とが一致する、すなわち同じである場合（ステップ２６０）、ステップ２６５で、ＳＶＰＯＳ１００は、加入者が製品を見ることができるように、Ｋｓ−ＭＥＲをＵＥ１１０に送信する。値の一致は、ＵＥ１１０が正しくパッケージを受信したことを意味する。値が一致しない場合は、ステップ２６１で取引が終了する。

ステップ２７０で、ＵＥ１１０は、ＳＶＰＯＳ１００（例えばＳＶＰＯＳ_ｂ１００ｂ）からＵＥ１１０に転送されたＫｓ−ＭＥＲを使用して、パッケージを復号する。一実施形態では、このパッケージは、製品、受領書、および製品ＩＤを含む。ＵＥ１１０は、自身の鍵Ｋｓ−ＵＥも使用して、パッケージを復号する。ステップ２７５で、ＵＥ１１０は、製品またはサービスが満足のいくものであるかどうか、あるいは、製品またはサービスがパッケージに含まれない場合には、要約（製品の説明）が満足のいくものであるかどうかを判定する。この判定には、製品ＩＤと、受け取った製品と、ＵＥ１１０が選択した当初の製品とを比較することを含めることができる。製品または製品の説明が、満足のいくもので、かつ正しい場合、ステップ２８０で、ＵＥ１１０は、取引を承認する。具体的には、ＵＥ１１０は、受領書をＳＶＰＯＳ_ｂ１００ｂに送信する。ＳＶＰＯＳ_ｂ１００ｂが受領書を受信すると、ＳＶＰＯＳ１００（購入者のＳＶＰＯＳとマーチャントのＳＶＰＯＳとが異なる場合は、それらの両方）は、特に、時刻と、購入者の名前および販売者の名前と、取引の受領書と、購入者の最終的な承認とを含むセッションデータレコードを作成し、マーチャント（または、必要に応じて、マーチャントの事業者）に支払いをするために、そのレコードを購入者の事業者の会計エンティティに送信し、その取引を購入者の月々の請求に課金する。

これに対し、ＵＥ１１０が、製品または製品の説明に満足しない場合は、ステップ２８５で、ＵＥ１１０は、（受け取った場合は）製品、製品ＩＤおよび受領書を含むパッケージをＳＶＰＯＳ_ｂ１００ｂに返送する。

パッケージが購入製品を含んでいる場合、ＳＶＰＯＳ_ｂ１００ｂは、そのパッケージが返送された理由を調査する。返送されるパッケージには、３つの一般的なシナリオがある。第１のシナリオは、マーチャント１２０が誤って間違った製品と、間違ったプレビューまたは要約とをパッケージに入れて送信した場合である。この場合、マーチャント１２０は、間違った製品に対してハッシュを計算する。ＵＥ１１０は、プレビューが、要求した製品のプレビューと一致しないことに気付き、ＳＶＰＯＳ_ｂ１００ｂおよびマーチャント１２０に通知する。間違いは意図したものではなかったため、マーチャント１２０は、正しい製品を再送することにより、そのような状況に対処する。

通常この場合、ＵＥ１１０は、ステップ２５０で、Ｋｓ−ＵＥを用いてパッケージを開いた時にプレビューまたは要約が正しくないことに気付く。前述したように、ＵＥ１１０は、プレビューまたは要約だけを見て、製品は見ない。ＵＥ１１０は、この時点でＳＶＰＯＳ_ｂ１００ｂおよびマーチャント１２０に通知するか、ステップ２７５まで待つことができる。

第２のシナリオは、マーチャント１２０が意図的に（または誤って）間違った製品をパッケージに挿入する場合である。しかし、パッケージに挿入されたプレビューまたは要約は正しい。すなわち、ＵＥ１００から要求された製品のプレビューまたは要約である。

この場合、マーチャント１２０は、間違った製品と、正しいプレビューまたは要約と、正しい製品ＩＤまたは間違った製品ＩＤとからなるパッケージのｈａｓｈ_ｄを計算する。ステップ２５０で、ＵＥ１１０は、正しいプレビューまたは要約を見て、ＳＶＰＯＳ_ｂ１００ｂにＫｓ−ＭＥＲを要求する。ＵＥ１１０から返されるｈａｓｈ_ｄは、マーチャント１２０から送信されたｈａｓｈ_ｄと一致する。ＳＶＰＯＳ１００が、ＵＥ１１０から返されたパッケージのｈａｓｈ_ｄを計算すると、そのｈａｓｈ_ｄは、元のｈａｓｈ_ｄと一致する。したがって、ＳＶＰＯＳ１００（ＳＶＰＯＳ_ｂ１００ｂまたはＳＶＰＯＳ_ｍ１００ｍ）は、製品ＩＤが、正しい製品すなわちＵＥ１１０が購入を望む製品のＩＤと一致するかどうかを検証することにより、この争いを解決しなければならない。マーチャント１２０が誤って間違った製品を挿入し、さらに間違った製品ＩＤも挿入した場合、ＳＶＰＯＳ１００は、ＵＥ１１０から受信した製品ＩＤと、（ＳＶＰＯＳの内部データベース、または独立した機関から得られる、）意図される製品の正しい製品ＩＤとを比較する。製品ＩＤが一致しないことにより、その取引に異議を唱え、パッケージを返送したことについて、ＵＥ１１０が正しかったことが明らかになり、ＳＶＰＯＳ１００は、争いを解決するために必要なステップをとる。

マーチャント１２０が間違った製品を挿入し、正しい製品ＩＤを挿入した場合、マーチャント１２０は、間違った製品と、正しいプレビューまたは要約と、正しい製品ＩＤとからなるパッケージのｈａｓｈ_ｄを計算することになる。ステップ２５０で、ＵＥ１１０は、正しいプレビューまたは要約を見て、ＳＶＰＯＳ_ｂ１００ｂにＫｓ−ＭＥＲを要求する。これは、マーチャント１２０が正しいプレビューまたは要約と製品ＩＤとを挿入することにより、間違ったコンテンツを送って、ＵＥ１１０およびＳＶＰＯＳ１００を混乱させることを悪意的に試みた場合である。ＵＥ１１０およびマーチャント１２０両方からのハッシュファイルの比較は一致する。また、ＳＶＰＯＳ１００による製品ＩＤの比較においても、一致が得られる。ＳＶＰＯＳ１００は、（例えば、ＭＰＡなどの独立した機関を介して、）受け取った製品のハッシュが、マーチャントによって挿入された製品ＩＤになることを検証しようと試みる。この検証の結果、製品ＩＤは一致せず、これは、マーチャントが不正行為を犯そうと試みたことを意味する。

第３のシナリオは、ＵＥ１１０が正しい製品を得たが、パッケージをＳＶＰＯＳ_ｂ１００ｂに返送することにより、間違った製品が挿入されていたと主張しようと試みる場合である。ＵＥ１１０は、受け取ったプレビューまたは要約が要求した製品のものであっても、間違った製品を受け取ったと主張する。争いがあった場合、ＵＥ１１０は、争いを解決するためにパッケージ全体をＳＶＰＯＳ１００に送信する。ＵＥ１１０は、取得したプレビューまたは要約は要求した製品のものと一致したが、マーチャント１２０が不正に間違った製品を挿入したと主張する。ＵＥ１１０がＳＶＰＯＳ１００にパッケージを返送する場合、ＵＥ１１０は、マーチャント１２０が故意に間違った製品を挿入したことを証明しようとして、（Ｋｓ−ＭＥＲ‖ＵＥ−ＴＭＳＩによって暗号化された）間違った製品ＩＤまたは間違った製品を意図的に挿入する。ＳＶＰＯＳは、ＵＥ１１０から返送されたパッケージのhash_d = hash_mer (Ks-MER‖UE-TMSI {Product + receipt + Product-ID })を計算する。しかし、マーチャント１２０から受信したｈａｓｈ_ｄのコピーは、実際の「正しい製品または製品ＩＤ」を使用して計算されているので、新しく計算されたｈａｓｈ_ｄは、（パッケージの受信を確認して、Ｋｓ−ＭＥＲを得るために）ＵＥ１１０からＳＶＰＯＳ１００に最初に返されたｈａｓｈ_ｄと一致しない。このことは、ＵＥ１１０が、返送されたパッケージに故意に別の製品または製品ＩＤを挿入することにより、悪意的に正しいコンテンツの受信に異議を唱えたことを明白に証明するものである。

（映画購入の事例）
加入者が自分のラップトップを立ち上げ、３Ｇ加入者識別モジュール（ＳＩＭ）などのスマートカードを使用して、デバイスのＵＭＴＳインターフェースを介して自分のＶｅｒｉｓｏｎのアカウント「ｌａｄｙｓｈｉｐ＠ｖｅｒｉｚｏｎ．ｃｏｍ」にログインする。加入者はウェブを閲覧して、Ｓｏｎｙ Ｐｉｃｔｕｒｅｓ Ｅｎｔｅｒｔａｉｎｍｅｎｔのサイトに入り、映画「Ｏｎ ｔｈｅ Ｒｉｖｅｒｆｒｏｎｔ」を自分のラップトップにダウンロードしようとする。この加入者がＶｅｒｉｚｏｎにアクセスできるのは、加入者がラップトップを介して３Ｇネットワークにアクセスすることを許可し、ネットワーク内でラップトップを起動することを許可するサービス契約を通じて、Ｖｅｒｉｚｏｎとの信頼関係を確立しているためである。３Ｇネットワークへアクセスするためには、ＵＥ１１０は、ＵＥ１１０を３Ｇネットワークにアタッチして（attach）、ＵＥ１１０を起動しなければならない。図９において、アタッチメント（attachment）および起動（activation）には、符号９００が付されている。アタッチメントは、ＵＥ１１０を３Ｇネットワークに導入するプロセス、すなわちデバイスを認証するプロセスである。起動は、そのネットワークを介して情報を送信する権利および手段をＵＥ１１０に付与するプロセスである。起動およびアタッチメントのために、ＵＥ１１０は、自身のＩＭＳＩ（International Mobile Subscriber Identity）または自身のＴＩＭＳＩ（Temporary IMSI）のどちらか一方のみを含むアタッチ要求メッセージをＳＧＳＮ１２６に送信する。ＳＧＳＮ１２６は、ＵＥのＩＭＳＩ（またはＴＩＭＳＩ）を含む認証要求メッセージをＨＳＳ１３５に送信する。ＨＳＳ１３５は、特に、乱数（ＲＡＮＤ）、認証トークン（ＡＵＴＮ）、暗号鍵（ＣＫ）、および予想される応答（ＸＲＥＳ）を含む認証応答メッセージをＳＧＳＮ１２６に返送する。ＳＧＳＮ１２６は、ＵＥ１１０にアタッチ応答を送信する前に、その情報を使用してＵＥ１１０にチャレンジを発行する。チャレンジが成功した場合、ＳＧＳＮ１２６は、ＲＡＮＤおよびＡＵＴＮを含む認証要求をＵＥ１１０に送信する。ＵＥ１１０は、自身の応答を含む認証応答をもって応答する。ＳＧＳＮ１２６は、ＵＥの応答がＸＲＥＳと一致するか否かに応じて、肯定アタッチ応答メッセージか、または否定アタッチ応答メッセージをＵＥ１１０に返送する。ＵＥ１１０は、特に、ＰＤＰアドレス、ネットワーク層サービスアクセスポイント識別子（ＮＳＡＰＩ）、ＰＤＰタイプ、アクセスポイント名（ＡＰＮ）、ＰＤＰ構成オプションを含むＰＤＰコンテキスト起動要求を送信する。ＳＧＳＮ１２６は、ＵＥ１１０から受信したＡＰＮと、ＳＧＳＮ１２６に記憶された構成情報とを使用して、当該モバイルデバイスのサービングＧＧＳＮ１２７となるべきＧＧＳＮ１２７を選択し、そのＧＧＳＮ１２７にＰＤＰコンテキスト作成要求を送信する。このＰＤＰコンテキスト作成要求メッセージは、ＮＳＰＡＩ、ＰＤＰタイプ、ＰＤＰアドレス、ＡＰＮ、ネゴシエートされたＱｏＳ、トンネルエンドポイント識別子（ＴＥＩＤ）、選択モード、課金特性、ＰＤＰ構成オプション等を含む。ＧＧＳＮ１２７は、必要なアクションをとった後、ＳＧＳＮ１２６にＰＤＰコンテキスト作成応答メッセージを返送する。次いで、ＳＧＳＮ１２６は、ＵＥ１１０に応答を送信する前に、ＲＮＣ１２５およびＧＧＳＮ１２７とネゴシエートして、無線アクセスベアラを確立する。次いで、ＳＧＳＮは、ＰＤＰコンテキスト起動応答をＵＥ１１０に返送して、要求されたＰＤＰの起動を確認する。

この例では、Ｓｏｎｙサーバは、ネットワーク事業者とのＳｏｎｙの契約を介してインターネットに接続されるか、または、公衆ウェブサーバ上に位置する。図５および図６は、ＨＴＴＰプロトコルシステムを使用した映画購入における、ＳＶＰＯＳの動作のメッセージフローを示している。例示の目的上、ＳＶＰＯＳは、１つのエンティティであるものとして説明する。すなわち、購入者のＳＶＰＯＳとＳｏｎｙのＳＶＰＯＳとは同一である。図５に示すように、ＵＥ１１０は、ＳＶＰＯＳ１００またはＳｏｎｙサーバ１２０と直接通信しない。ＵＥ１１０は、仲介であるＡＰ１４０を介して通信する。ＡＰ１４０は、ＵＥ１１０が匿名を保つことを可能にする。したがって、ＵＥ１１０によって生成された信号またはＵＥ１１０に到来する信号はすべて、途中でＡＰ１４０によって受信され、中継される。説明の目的上、オリジナルの信号を「ｘｘｘａ」と呼ぶ。ここで、「ｘｘｘ」が信号であり、中継される信号は、「ｘｘｘｂ」とする。また、「Ｓｏｎｙサーバ」は、マーチャント１２０またはＳｏｎｙ１２０として呼ばれるものとする。

ＳＶＰＯＳ１００は、３ＧＰＰ ＧＡＡを利用して加入者を認証し、要求に応じて、加入者の身元を匿名に保つ。加入者の認証プロセスは、加入者のＵＥ１１０がマーチャント１２０に映画を要求し、ＳＶＰＯＳ１００のアドレスを送信して、３Ｇ事業者がその取引の支払いをすることをマーチャント１２０に通知した後に開始される。ＵＥ１１０は、ＡＰ１４０との間にＴＬＳトンネル６０１を確立して、アプリケーションサーバに転送するために、ＵＥ１１０自身のすべてのパケットをＡＰ１４０に送信する。ＡＰ１４０の利点は、３Ｇ事業者のためのプライバシポリシの実施ポイントとして機能できることであり、各種サービスのための異なるプライバシ／匿名性ポリシを実施できることである。

ＵＥ１１０は、Ｓｏｎｙのページを開き、すなわちＨＴＴＰ ＧＥＴ（６０２ａおよび６０２ｂ） ｈｔｔｐ：／／ｗｗｗ．ｓｏｎｙ．ｃｏｍメッセージをＳｏｎｙ１２０に送信する。Ｓｏｎｙ１２０は、２００ ＯＫ（６０３ａ）メッセージをもって応答して、ＵＥ１１０の画面にページを表示する。このメッセージは、ＡＰ１４０により６０３ｂとして中継される。ユーザは、映画「Ｏｎ ｔｈｅ Ｗａｔｅｒｆｒｏｎｔ」へのリンクをクリックし、すなわちＵＥ１１０は、ＧＥＴ ｍｏｖｉｅ（６０４ａおよび６０４ｂ）（ｈｔｔｐ：／／ｗｗｗ．ｓｏｎｙ．ｃｏｍ／ｏｎｔｈｅｗａｔｅｒｆｒｏｎｔ．ｈｔｍｌ）をＳｏｎｙ１２０に送信する。Ｓｏｎｙ１２０は、ＨＴＴＰ ３０２メッセージ（６０５ａおよび６０５ｂ）をもってユーザに応答し、価格を含む支払い選択フォームにユーザをリダイレクトする。ＨＴＴＰ ３０２メッセージは、Ｓｏｎｙ１２０における支払い選択フォームのＵＲＬを含んでおり、このフォームは価格も表示する。ユーザは、そのフィールドにＳＶＰＯＳ１００のＵＲＬを含めることにより、支払いフォームに入力して、事業者すなわちＶｅｒｉｚｏｎが支払いをすることを通知し、ｓｕｂｍｉｔボタンをクリックする。すなわち、ＵＥ１１０は、ＰＯＳＴ（６０６ａおよび６０６ｂ） ｈｔｔｐ：／／ｗｗｗ．ｓｏｎｙ．ｃｏｍ／ｏｎｔｈｅｗａｔｅｒｆｒｏｎｔ．ｈｔｍｌ／ｆｏｒｍをＳｏｎｙ１２０に送信する。Ｓｏｎｙ１２０は、ＨＴＴＰ ３０２（６０７ａおよび６０７ｂ）（ＳＶＰＯＳのＵＲＬ）メッセージを送信することにより、ＵＥ１１０をＳＶＰＯＳ１００にリダイレクトして、ユーザがＳＶＰＯＳの加入者であり、事業者がＳｏｎｙ１２０に支払いをすることを確実にする。ＵＥ１１０は、ＳＶＰＯＳフォームに入力し、ＳＶＰＯＳ１００にサブミットする。すなわち、ＵＥ１１０は、ＨＴＴＰ ＰＯＳＴ（６０８ａおよび６０８ｂ） ｈｔｔｐ：／／ｗｗｗ．ｖｅｒｉｚｏｎ．ｃｏｍ／ｓｖｐｏｓ／ｆｏｒｍをＳＶＰＯＳ１００に送信する。ＳＶＰＯＳ１００は、ＨＴＴＰ ３０２（６０９ａおよび６０９ｂ）メッセージを返送して、ＵＥ１１０をＢＳＦ１３０にリダイレクトし、ＧＡＡとブートストラップとを併用して自身のＩＤを認証するよう、ＵＥ１１０に指示する。

認証およびブートストラップメッセージのフローを図７に示す。ＳＶＰＯＳ１００は、ＢＳＦ１３０のＵＲＬを含むメッセージ７００をＵＥ１１０に送信する。ＵＥ１１０は、ＨＴＴＰ ＰＯＳＴ ｈｔｔｐ：／／ｗｗｗ．ｖｅｒｉｚｏｎ．ｃｏｍ／ＢＳＦ／ｆｏｒｍメッセージ７０１をＢＳＦ１３０に送信することにより、取引識別子（ＴＩＤ−ＵＥ）を要求する。ＢＳＦ１３０は、ＵＥの認証ベクトル７０２をＨＳＳ１３５から取得する。ＢＳＦ１３０は、ＨＴＴＰ ２００ ＯＫメッセージ７０３をＵＥ１１０に送信して、自身のＩＤを認証するよう、ＵＥ１１０にチャレンジを発行する。ＵＥ１１０は、自身のＳＩＭカード内のＡＫＡ７０４とともにこのチャレンジを使用して、鍵Ｋｓ−ＵＥを生成する。ＵＥ１１０は、ＢＳＦ１３０からのチャレンジに対するこの適切な応答を含んだＨＴＴＰ ＰＯＳＴ７０５を送信する。ＢＳＦ１３０は、取引識別子（ＴＩＤ−ＵＥ）を含むＨＴＴＰ ２００ ＯＫ７０６をＵＥ１１０に送信する。

ＴＩＤ−ＵＥを受信すると、ＵＥ１１０は、Ｓｏｎｙ１２０への映画の要求を更新し、ＴＩＤ−ＵＥ、ＵＥ−ＴＭＳＩ、映画、価格、ＳＶＰＯＳアドレスを含むＨＴＴＰ ＧＥＴ（６１１ａおよび６１１ｂ）、例えば「ＨＴＴＰ ＧＥＴ ｈｔｔｐ：／／ｗｗｗ．ｓｏｎｙ．ｃｏｍ？ＩＤ＝ＴＩＤＵＥ＆ＵＥ＝ＴＭＳＩ＆ｍｏｖｉｅ＝ｘｘｘ＆ＳＶＰＯＳ＝ｙｙｙ」をＳｏｎｙ１２０に送信する。

適切なパラメータ（すなわちＴＩＤ−ＵＥ、ＵＥ−ＴＭＳＩ等）を含む更新された映画の要求をＵＥ１１０から受信すると、マーチャント（すなわちＳｏｎｙ１２０）は、ＴＩＤ−ＵＥ、ＵＥ−ＴＭＳＩ、価格等を含むＨＴＴＰ ＰＯＳＴメッセージ６１２をＳＶＰＯＳ１００に送信して、取引の許可を要求する。ＳＶＰＯＳ１００は、Ｓｏｎｙ１２０に応答６１３を送信して、ブートストラップする（６１４）よう指示する。図８は、Ｓｏｎｙ１２０がブートストラップする際のメッセージフローを示している。そして、マーチャントは、以下のようにブートストラップして、自身の取引識別子（ＴＩＤ−Ｓｏｎｙ）を取得し、自身の鍵（Ｋｓ−Ｓｏｎｙ）を生成する。

Ｓｏｎｙ１２０は、ＨＴＴＰ ＰＯＳＴ ｈｔｔｐ：／／ｗｗｗ．ｖｅｒｉｚｏｎ．ｃｏｍ／ＢＳＦ／ｆｏｒｍメッセージ８００をＢＳＦ１３０に送信することにより、取引識別子（ＴＩＤ−ＵＥ）を要求する。ＢＳＦ１３０は、ＨＳＳ１３５からＳｏｎｙの認証ベクトル８０１を取得する。ＢＳＦ１３０は、ＨＴＴＰ ２００ ＯＫメッセージ８０２をＳｏｎｙ１２０に送信して、自身のＩＤを認証するよう、Ｓｏｎｙ１２０にチャレンジを発行する。Ｓｏｎｙ１２０は、自身のＳＩＭカード内のＡＫＡ８０３またはＡＫＡ８０３に相当するものとともにこのチャレンジを使用して、鍵Ｋｓ−Ｓｏｎｙを生成する。Ｓｏｎｙ１２０は、ＢＳＦからのチャレンジに対するこの適切な応答を含むＨＴＴＰ ＰＯＳＴ８０４を送信する。ＢＳＦ１３０は、取引識別子（ＴＩＤ−ＵＥ）を含むＨＴＴＰ ２００ ＯＫ８０５をＳｏｎｙ１２０に送信する。

ＴＩＤ−ＳｏｎｙおよびＫｓ−Ｓｏｎｙを取得すると、Ｓｏｎｙ１２０は、ＳＶＰＯＳ１００への許可要求を更新し、ＴＩＤ−ＵＥ、ＴＩＤ−Ｓｏｎｙ、Ｓｏｎｙサーバのホスト名、価格等を含む要求ＨＴＴＰ ＰＯＳＴ６１５をＳＶＰＯＳ１００に送信する。ＳＶＰＯＳ１００は、ＴＩＤ−ＵＥ、ＴＩＤ−Ｓｏｎｙ、ＵＥ−ＴＭＳＩ等を含むメッセージＨＴＴＰ ＧＥＴ６１６をＢＳＦ１３０に送信して、当該取引のＫｓ−ＵＥおよびＫｓ−Ｓｏｎｙを要求する。ＢＳＦ１３０は、ＴＩＤ、Ｋｓ−ＵＥ、Ｋｓ−Ｓｏｎｙ、「ＵＥのアドレス」、Ｓｏｎｙサーバのホスト名等を含むメッセージＨＴＴＰ ＯＫ６１７を送信する。

ＳＶＰＯＳ１００は、メッセージＨＴＴＰ ３０２（６１８）をＳｏｎｙ１２０に送信して、取引を再確認するよう要求する。このメッセージは、ＴＩＤと、ＳＶＰＯＳ１００に対する取引見積もり額のＵＲＬとを含むＨＴＴＰ ３０２（６１８）リダイレクトメッセージとなる。Ｓｏｎｙ１２０は、見積もり額を検討し、ＴＩＤと、検討された取引見積もり額とを含むＨＴＴＰ ＰＯＳＴ（６１９）をＳＶＰＯＳ１００に送信する。Ｓｏｎｙ１２０は、メッセージＨＴＴＰ ＰＯＳＴ（６１９）をもって取引を再確認する。

Ｓｏｎｙ１２０から再確認を受信すると、ＳＶＰＯＳ１００は、ＴＩＤおよび取引確認番号を含む応答メッセージＨＴＴＰ ＯＫ６２０をＳｏｎｙ１２０に送信する。Ｓｏｎｙ１２０は、メッセージＨＴＴＰ ３０２（６２１ａおよび６２１ｂ）を送信して、ＵＥ１１０に取引を再確認するよう要求する。Ｓｏｎｙ１２０は、ＵＥ１１０による確認のために、ＳＶＰＯＳ１００に対する取引見積もり額のＵＲＬを含むＨＴＴＰ ３０２メッセージ（６２１ａおよび６２１ｂ）をＵＥ１１０に送信する。メッセージＨＴＴＰ ３０２（６２１ａおよび６２１ｂ）は、ＴＩＤおよび見積もり額のＵＲＬを含む。ＵＥ１１０は、そのＴＩＤと確認された取引見積もり額とを含むＨＴＴＰ ＰＯＳＴメッセージ（６２２ａおよび６２２ｂ）をＳＶＰＯＳ１００に送信する。これは、ＵＥによる取引の確認となる。ＳＶＰＯＳ１００は、ＴＩＤおよび取引確認番号を含むＨＴＴＰ ２００ ＯＫ（６２３ａおよび６２３ｂ）をもってＵＥ１１０に応答する。ＵＥ１１０は、商品およびサービスに対するＳＶＰＯＳ１００による支払いを事実上許可したことになる。

ＵＥ１１０は、ＴＩＤ、取引確認番号、および映画を含むＨＴＴＰ ＧＥＴ（６２４ａおよび６２４ｂ）をＳｏｎｙ１２０に送信することにより、映画の要求を更新する。Ｓｏｎｙ１２０は、ＴＩＤおよび取引確認アドレスを含むＨＴＴＰ ＧＥＴ（６２５）をＳＶＰＯＳ１００に送信して、Ｋｓ−ＵＥを要求する。ＳＶＰＯＳ１００は、ＴＩＤ、取引確認番号、およびＫｓ−ＵＥを含む２００ ＯＫ応答メッセージ（６２６）をＳｏｎｙ１２０に送信する。Ｓｏｎｙは、ＴＩＤ、要求された映画、およびその他のものを含むパッケージを含んだＨＴＴＰ ２００ ＯＫ応答メッセージ（６２７ａおよび６２７ｂ）をＵＥ１１０に送信する。映画は電子的に配信可能なので、このパッケージは製品を含んでいる。このパッケージは、映画、受領書、および映画ＩＤを含む。このパッケージは、Ｋｓ−Ｓｏｎｙ‖ＵＥ−ＴＭＳＩにより暗号化される。このパッケージは、映画のプレビューも含む。このプレビューは、ユーザが受信した映画が要求したものであるかどうかを確認するための映画の概要である。パッケージは次のように見える：Package = Ks-UE{Preview + Ks-Sony‖UE-TMSI {Movie + receipt + Movie-ID}。別の実施形態では、パッケージは、事後拒否防止鍵を含む。

次いで、Ｓｏｎｙ１２０は、プレビューおよびｈａｓｈ_ｄをＳＶＰＯＳ１００に送信する（６２８）。このメッセージは、ＨＴＴＰ ＰＯＳＴの形態をとる。ハッシュは、Ｓｏｎｙ１２０によって計算される。ＵＥ１１０は、パッケージを開く（６２９）。ＵＥ１１０は、Ｋｓ−ＵＥを使用してパッケージを復号し、(Preview +Ks-Sony‖UE-TMSI {Movie +receipt +Movie-ID}を導出し、ｈａｓｈ_ｄを計算する（６２９）。ＵＥ１１０は、計算したｈａｓｈ_ｄをＳＶＰＯＳ１００に送信する。計算されたハッシュは、ＨＴＴＰ ＰＯＳＴの一部として送信される（６３０ａおよび６３０ｂ）。ＳＶＰＯＳ１００は、（ＵＥ１１０およびＳｏｎｙ１２０からの）両方のハッシュファイルを比較して、ハッシュが同一であるかどうかを判定する。ハッシュが一致した場合は、ＵＥ１１０がパッケージを正しく受信したことが保証される（ただし、映画が、ユーザが要求したものと同じであることは保証されない）。ハッシュが一致した場合、ＳＶＰＯＳ１００は、Ｓｏｎｙ１２０およびＵＥ１１０の両方にＨＴＴＰ ＯＫメッセージを送信する。ＳｏｎｙへのメッセージＨＴＴＰ ＯＫ６３１には、ＴＩＤしか含まれないが、ＵＥ１１０へのメッセージＨＴＴＰ ＯＫ（６３１ａおよび６３１ｂ）には、ＴＩＤおよびＫｓ−Ｓｏｎｙの両方が含まれる。ＵＥ１１０は、映画、受領書、および映画ＩＤを復号する（６３２）。映画が正しいものである場合、ＵＥ１００は、ＳＶＰＯＳ１００に受領書を送信し（ＨＴＴＰ ＰＯＳＴ６３３ａおよび６３３ｂ）、取引は成功して終了する。映画が正しいものでない場合、ＵＥ１１０は、ＳＶＰＯＳ１００にパッケージを返送し（ＨＴＴＰ ＰＯＳＴ６３３ａおよび６３３ｂ）（受領書は含めない）、取引に関するＳＶＰＯＳ１００の決定を待つ。

取引が成功した場合、ＳＶＰＯＳ１００は、Ｓｏｎｙ１２０への支払いを認可する。ＳＶＰＯＳ１００は、ＵＥ１１０にＨＴＴＰ ＯＫ（６３５ａおよび６３５ｂ）を送信する。このメッセージは、受領書を含む。争いがある場合、すなわちＵＥ１１０がパッケージを返送した場合、ＳＶＰＯＳ１００は調停を行う。ＳＶＰＯＳ１００は、ＵＥ１１０にＨＴＴＰ ＯＫ（６３５ａおよび６３５ｂ）を送信する。このメッセージは、調停の結果を含む。

図９および図１０は、本発明の一実施形態による、映画購入の例のメッセージフローを示している。この代替実施形態では、ＵＥ１１０は、ＡＰ１４０を仲介として使用せずに通信する。ＡＰ１４０が除かれたので、メッセージは中継されない。メッセージのフローやメッセージの順序は、図５および図６のメッセージ、すなわち６００〜６３５と同じである。これらのメッセージは、符号９００〜９３４である。図５および図６と、図９および図１０との違いは、図９および図１０ではＴＬＳトンネルが必要でないことである。したがって、各メッセージについては、繰り返して説明しないことにする。

本発明について、特定の例示的実施形態を参照しながら説明した。当業者であれば、本発明の範囲から逸脱することなく、所定の改変および変更が可能であることが明らかでなろう。例示的実施形態は、説明を目的とするものであり、特許請求の範囲において定義される本発明の範囲を限定するものではない。

本発明の一実施形態による、加入者、マーチャント、およびＳＶＰＯＳを含む３Ｇ無線ネットワークを示す説明図である。 ＳＶＰＯＳの動作を示すフローチャートである。 本発明の一実施形態による、ＵＥまたはマーチャントを認証するステップを示すフローチャートである。 本発明の一実施形態による、ＵＥを使用した支払いを許可するステップを示すフローチャートである。 本発明の一実施形態による、映画の電子的な支払いのメッセージフローを示す図である。 本発明の一実施形態による、映画の電子的な支払いのメッセージフローを示す図である。 本発明の一実施形態による、映画の支払いのためにＵＥデバイスを認証する際のメッセージフローを示す図である。 本発明の一実施形態による、映画の支払いのためにＳｏｎｙを認証する際のメッセージフローを示す図である。 本発明の代替実施形態による、映画購入の支払いのためのメッセージフローを示す図である。 本発明の代替実施形態による、映画購入の支払いのためのメッセージフローを示す図である。

Claims (42)

1. モバイル電子デバイス、マーチャント端末、ＢＳＦ（ブートストラップサーバ機能）サーバデバイス及びＳＶＰＯＳ（Secure Virtual Point of Service）サーバデバイスを有するシステムで実施される方法であって、
   前記モバイル電子デバイスが前記マーチャント端末に製品またはサービスの支払いの要求を送信するステップと、
   前記ＢＳＦサーバデバイス又は前記モバイル電子デバイスのうちの少なくとも一方が購入者暗号鍵を決定するステップと、
   前記ＢＳＦサーバデバイス又は前記マーチャント端末のうちの少なくとも一方がマーチャント暗号鍵を決定するステップと、
   前記マーチャント端末が前記製品または前記サービスを含むパッケージを前記マーチャント暗号鍵で暗号化して第１の暗号化パッケージを生成するステップと、
   前記マーチャント端末が、前記第１の暗号化パッケージと前記製品またはサービスの要約とを含むデータを、前記ＳＶＰＯＳサーバデバイスを介して前記ＢＳＦサーバデバイスから取得した前記購入者暗号鍵で暗号化することによって第２の暗号化パッケージを生成するステップと、
   前記マーチャント端末が、前記第２の暗号化パッケージを前記ＳＶＰＯＳサーバデバイスに送信するステップと、
   前記マーチャント端末が、前記第１の暗号化パッケージの少なくとも一部分からなるマーチャントのハッシュを計算するステップと、
   前記モバイル電子デバイスが、前記ＳＶＰＯＳサーバデバイスから受信した前記第２の暗号化パッケージを前記購入者暗号鍵で復号して前記要約を明らかにするステップと、
   前記モバイル電子デバイスが、前記購入者暗号鍵による復号で得られた前記第１の暗号化パッケージの、少なくとも前記一部分と同じ部分からなる購入者のハッシュを計算するステップと、
   前記ＳＶＰＯＳサーバデバイスが、前記購入者のハッシュと前記マーチャントのハッシュとを比較するステップと、
   前記ＳＶＰＯＳサーバデバイスが、前記比較結果に基づいて、前記ＢＳＦサーバデバイスから取得した前記マーチャント暗号鍵を前記モバイル電子デバイスに送信するステップと、
   前記モバイル電子デバイスが、前記マーチャント暗号鍵を使用して前記第１の暗号化パッケージを復号し、当該復号された第１の暗号化パッケージの内容を購入者に提示するステップと、
   前記購入者の指示に応じて、前記モバイル電子デバイスが、前記ＳＶＰＯＳサーバデバイスに前記製品または前記サービスの支払いの認可を送信するステップと
   を備えることを特徴とする電子的な支払い方法。
2. 前記ＳＶＰＯＳサーバデバイスが、前記モバイル電子デバイスを使用している購入者と、前記製品または前記サービスを販売しているマーチャントとを認証するステップをさらに備え、
   前記認証するステップは、
   前記購入者について、
   前記モバイル電子デバイスが、前記ＢＳＦサーバデバイスに第１の取引ＩＤを要求するサブステップと、
   前記ＢＳＦサーバデバイスが、ホーム加入者サーバ（ＨＳＳ）サーバデバイスから前記モバイル電子デバイスの認証ベクトルを取得するサブステップと、
   前記ＢＳＦサーバデバイスが、前記モバイル電子デバイスにチャレンジを発行するサブステップと、
   前記モバイル電子デバイスが、前記チャレンジに応答するサブステップであって、該応答は前記購入者暗号鍵を含む、応答するサブステップと、
   を含み、
   前記マーチャントについて、
   前記マーチャント端末が、前記ＢＳＦサーバデバイスに第２の取引ＩＤを要求するサブステップと、
   前記ＢＳＦサーバデバイスが、前記ＨＳＳサーバデバイスから前記マーチャント端末の認証ベクトルを取得するサブステップと、
   前記ＢＳＦサーバデバイスが、前記マーチャント端末にチャレンジを発行するサブステップと、
   前記マーチャント端末が、前記チャレンジに応答するサブステップであって、該応答は前記マーチャント暗号鍵を含む、応答するサブステップと
   を含むことを特徴とする請求項１に記載の電子的な支払い方法。
3. 前記モバイル電子デバイスが、前記ＳＶＰＯＳサーバデバイスを介した支払いを許可するステップと、
   前記ＳＶＰＯＳサーバデバイスが、前記許可を受信すると、前記購入者暗号鍵を前記マーチャントに送信するステップと
   をさらに備えることを特徴とする請求項１に記載の電子的な支払い方法。
4. 前記購入者暗号鍵および前記マーチャント暗号鍵は、前記モバイル電子デバイスにおけるＳＩＭカード内と前記マーチャント端末に存在するＳＩＭカード内それぞれの一意な識別情報に基づいて生成され、前記購入者暗号鍵および前記マーチャント暗号鍵は、取引ごとに異なることを特徴とする請求項１に記載の電子的な支払い方法。
5. 前記第１の暗号化されたパッケージは、製品ＩＤおよび受領書をさらに含むことを特徴とする請求項１に記載の電子的な支払い方法。
6. 正しくない前記製品またはサービスを提示された前記購入者の指示に応じて、前記モバイル電子デバイスは、調停のために、前記暗号化されたパッケージを前記ＳＶＰＯＳサーバデバイスに送信することを特徴とする請求項５に記載の電子的な支払い方法。
7. 正しい前記製品またはサービスを提示された前記購入者の指示に応じて、前記モバイル電子デバイスは、前記受領書を前記ＳＶＰＯＳサーバデバイスに送信し、前記ＳＶＰＯＳサーバデバイスは支払いを認可することを特徴とする請求項５に記載の電子的な支払い方法。
8. 前記調停は、
   前記ＳＶＰＯＳサーバデバイスが、正しい製品ＩＤが送信されたかどうかを判定するサブステップであって、前記正しい製品ＩＤは、データベースに記憶された製品ＩＤと、送信された製品ＩＤとの比較に基づいて判定される、判定するサブステップと、
   前記ＳＶＰＯＳサーバデバイスが、正しい製品が送信されたかどうかを判定するサブステップと、
   前記ＳＶＰＯＳサーバデバイスが、前記送信された製品ＩＤと、送信された製品とを比較するサブステップと
   を含むことを特徴とする請求項６に記載の電子支払い方法。
9. 前記モバイル電子デバイスが、前記要約は要求した前記製品または前記サービスの記述と一致するかどうかを判定するステップと、
   前記モバイル電子デバイスが、前記判定に基づいて前記購入者のハッシュを計算するステップと
   をさらに備えることを特徴とする請求項１に記載の電子的な支払い方法。
10. 前記マーチャントのハッシュは、鍵付きハッシュであり、公開鍵インフラストラクチャを介して取得される鍵を使用して暗号化されることを特徴とする請求項１に記載の電子的な支払い方法。
11. 製品またはサービスを購入する方法であって、
    モバイル電子デバイスを使用して、マーチャントに対する前記製品または前記サービスの購入および支払いの要求を開始するステップと、
    前記モバイル電子デバイスが、ＢＳＦ（ブートストラップサーバ機能）サーバデバイスと協働して購入者暗号鍵を決定するステップと、
    前記モバイル電子デバイスが、マーチャント端末から暗号化されたパッケージを受信するステップであって、該暗号化されたパッケージは、前記購入者暗号鍵で暗号化された製品又はサービスの要約を有する第１の部分と前記購入者暗号鍵及びマーチャント暗号鍵で暗号化された前記製品又はサービスを有する第２の部分とを含む、受信するステップと、
    前記モバイル電子デバイスが、前記暗号化されたパッケージの少なくとも一部からなる購入者のハッシュを計算するステップと、
    前記モバイル電子デバイスが、前記要約が前記製品又はサービスを正しく特定するかを前記購入者が判断できるように、前記購入者暗号鍵を使用して前記暗号化されたパッケージを復号するステップと、
    前記モバイル電子デバイスは、前記購入者のハッシュが、前記一部と同じ部分からなり前記マーチャント端末により計算されたマーチャントのハッシュと一致するというＳＶＰＯＳ（Secure Virtual Point of Service）サーバデバイスの判断に応答して、マーチャント暗号鍵を受信するステップと
    を備えることを特徴とする製品またはサービスを購入する方法。
12. 前記購入者が前記復号された製品又はサービスが前記要求された製品又はサービスに一致するかを判断するために、前記モバイル電子デバイスが、前記暗号化されたパッケージの前記第２の部分を前記マーチャント暗号鍵を使用して復号するステップ
    をさらに備えることを特徴とする請求項１１に記載の方法。
13. 前記モバイル電子デバイスが、前記モバイル電子デバイス自身を前記ＢＳＦサーバデバイスに対して認証するステップであって、前記認証するステップは、
    前記モバイル電子デバイスが、前記ＢＳＦサーバデバイスに取引ＩＤを要求するサブステップと、
    前記モバイル電子デバイスが、前記ＢＳＦサーバデバイスからチャレンジを受信するサブステップと、
    前記モバイル電子デバイスが、前記チャレンジに応答するサブステップであって、該応答は前記購入者暗号鍵の送信を含む、応答するサブステップと
    を含むことを特徴とする請求項１１に記載の方法。
14. 前記暗号化されたパッケージの前記第２の部分は、製品ＩＤおよび受領書をさらに含むことを特徴とする請求項１２に記載の方法。
15. 前記モバイル電子デバイスが、前記復号された製品又はサービスが前記要求された製品又はサービスに一致しないと判断した前記購入者からの指示に応答して、調停のために、前記暗号化されたパッケージを前記ＳＶＰＯＳサーバデバイスに送信することを特徴とする請求項１２に記載の方法。
16. 前記モバイル電子デバイスが、前記復号された製品又はサービスが前記要求された製品又はサービスに一致すると判断した前記購入者からの指示に応答して、承認を前記ＳＶＰＯＳサーバデバイスに送信して支払いを許可することを特徴とする請求項１２に記載の方法。
17. 製品またはサービスを販売する方法であって、
    マーチャント端末が、前記製品または前記サービスの要求を購入者から受信するステップであって、前記要求は、モバイル電子デバイスを使用して行われる、受信するステップと、
    前記マーチャント端末が、認証および支払いのために、前記モバイル電子デバイスをＳＶＰＯＳ（Secure Virtual Point of Service）サーバデバイスに導くステップと、
    前記マーチャント端末が、ＢＳＦ（ブートストラップサーバ機能）サーバデバイスと協働してマーチャント暗号鍵を決定するステップと、
    前記マーチャント端末が、購入者暗号鍵を前記モバイル電子デバイスから受信するステップと、
    前記マーチャント端末が、前記購入者暗号鍵を使用して暗号化された前記製品または前記サービスの要約を有する第１の部分と、前記マーチャント暗号鍵を使用した暗号化の後前記購入者暗号鍵を使用して暗号化された前記製品またはサービスを有する第２の部分とを含む暗号化されたパッケージを生成するステップと、
    前記マーチャント端末が、前記暗号化されたパッケージを前記モバイル電子デバイスに送信するステップと、
    前記マーチャント端末が、前記暗号化されたパッケージの少なくとも一部分からなるマーチャントのハッシュを計算するステップと、
    前記マーチャント端末が、前記マーチャントのハッシュを前記ＳＶＰＯＳサーバデバイスに送信するステップと、
    前記マーチャント端末が、前記マーチャントのハッシュが、前記一部分と同じ部分からなり前記モバイル電子デバイスにより計算された購入者のハッシュと一致するという前記ＳＶＰＯＳサーバデバイスの判断に応答して、前記マーチャント暗号鍵を前記ＳＶＰＯＳサーバデバイスに送信するステップと
    を備えることを特徴とする製品またはサービスを販売する方法。
18. 前記暗号化されたパッケージの前記第２の部分は、製品ＩＤおよび受領書をさらに含むことを特徴とする請求項１７に記載の方法。
19. 前記マーチャント端末が、前記マーチャント端末自身を前記ＢＳＦサーバデバイスに対して認証するステップであって、前記認証するステップは、
    前記マーチャント端末が、前記ＢＳＦサーバデバイスに取引ＩＤを要求するサブステップと、
    前記マーチャント端末が、前記ＢＳＦサーバデバイスからチャレンジを受信するサブステップと、
    前記マーチャント端末が、前記チャレンジに応答するサブステップであって、該応答は前記マーチャント暗号鍵の送信を含む、応答するサブステップと
    を含むことを特徴とする請求項１７に記載の方法。
20. 前記マーチャント端末は、前記暗号化されたパッケージは前記要求された製品又はサービスを含まないという前記購入者の判断に応答して、前記ＳＶＰＯＳサーバデバイスを介して調停処理に入るステップをさらに備えることを特徴とする請求項１７に記載の方法。
21. 前記マーチャント端末が、前記モバイル電子デバイスによる前記製品又はサービスの受信に応答して、前記ＳＶＰＯＳサーバデバイスを介して前記購入者からの支払いを受領するステップをさらに備えることを特徴とする請求項１７に記載の方法。
22. 製品又はサービスの商取引のためのセキュアなＳＶＰＯＳ（Secure Virtual Point of Service）サーバデバイスであって、
    認証のために、モバイル電子デバイスおよびマーチャント端末の両方をブートストラップサーバ機能（ＢＳＦ）サーバデバイスにリダイレクトする手段と、
    前記モバイル電子デバイスから支払いの許可を得る手段と、
    暗号化されたパッケージの少なくとも一部分からなり、前記マーチャント端末で計算されたマーチャントのハッシュと、前記暗号化されたパッケージの前記一部分と同じ部分からなり、前記モバイル電子デバイスで計算された購入者のハッシュとを受信する手段であって、前記暗号化されたパッケージは、購入者暗号鍵を使用して暗号化された前記製品又はサービスを特定する要約を有する第１の部分と、マーチャント暗号鍵を使用した暗号化の後前記購入者暗号鍵を使用して暗号化された前記製品又はサービスを有する第２の部分とを含む、受信する手段と、
    前記マーチャントのハッシュと、前記購入者のハッシュとを比較する手段と、
    前記比較に基づいて、前記マーチャント暗号鍵を前記モバイル電子デバイスに送信する手段と、
    前記前記モバイル電子デバイスから受信した、前記暗号化されたパッケージの満足の判定結果に基づいて、前記商取引の支払いを決済する手段と
    を備えたことを特徴とするＳＶＰＯＳサーバデバイス。
23. 前記商取引の支払い情報を記憶する記憶手段であって、該支払い情報は、前記商取引の価格と前記商取引の受領書とを含む、記憶手段
    をさらに備えたことを特徴とする請求項２２に記載のＳＶＰＯＳサーバデバイス。
24. 前記支払いを決済する手段は、前記暗号化されたパッケージが正しい製品又はサービスを含んでいたかどうかを判定するための調停手段を含み、
    前記調停手段は、
    正しい製品ＩＤが送信されたかどうかを判定する手段であって、前記正しい製品ＩＤは、データベースに記憶された製品ＩＤと、送信された製品ＩＤとの比較に基づいて判定される、手段と、
    正しい製品が送信されたかどうかを判定する手段と、
    前記送信された製品ＩＤと、送信された製品とを比較する手段と
    を含むことを特徴とする請求項２２に記載のＳＶＰＯＳサーバデバイス。
25. 商取引の決済システムであって、
    購入者およびマーチャントの認証ベクトルを記憶するように構成されたホーム加入者サーバ（ＨＳＳ）サーバデバイスと、
    前記購入者および前記マーチャントから情報を取得することにより前記購入者および前記マーチャントの両方を認証するように構成され、かつ、前記ＨＳＳサーバデバイスに記憶された前記認証ベクトルを使用して前記情報を確認するように構成されたブートストラップサーバ機能（ＢＳＦ）サーバデバイスと、
    購入者の口座からマーチャントの口座に支払いを振り込み、前記商取引の記録を保持するように構成された交渉サーバデバイスと、
    前記決済システムの動作を管理するセキュアなＳＶＰＯＳ（Secure Virtual Point of Service）サーバデバイスであって、該ＳＶＰＯＳサーバデバイスは、認証のために、前記購入者のモバイル電子デバイスおよび前記マーチャントのマーチャント端末を前記ＢＳＦサーバデバイスにリダイレクトし、認証の後、前記ＳＶＰＯＳサーバデバイスは、モバイル財布として前記交渉サーバデバイスを使用した前記商取引の支払いの許可を得、購入者暗号鍵を前記マーチャントに送信するように構成されており、前記ＳＶＰＯＳサーバデバイスは、パッケージの少なくとも一部分からなる購入者のハッシュ値と、前記パッケージの少なくとも一部分からなるマーチャントのハッシュ値とを比較するようにさらに構成されており、前記ＳＶＰＯＳサーバデバイスは、前記購入者のハッシュ値と前記マーチャントのハッシュ値とが同じである場合、マーチャント暗号鍵を前記購入者に送信するように構成されており、前記ＳＶＰＯＳサーバデバイスは、前記購入者が前記ＳＶＰＯＳサーバデバイスに前記パッケージを返送しないことに応答して、前記交渉サーバデバイスに対して前記マーチャントへの支払いを認可するように構成された、ＳＶＰＯＳサーバデバイスと
    を備え
    前記パッケージは、前記購入者暗号鍵を使用して暗号化された製品またはサービスの要約を有する第１の部分と、前記マーチャント暗号鍵を使用した暗号化の後前記購入者暗号鍵を使用して暗号化された前記製品またはサービスを有する第２の部分とを含み、
    前記購入者のハッシュ値は、前記パッケージの少なくとも一部分からなり前記モバイル電子デバイスにより計算され、
    前記マーチャントのハッシュ値は、前記一部分と同じ部分からなり前記マーチャント端末により計算され、
    前記購入者の認証は、前記ＢＳＦサーバデバイスが、前記購入者からの第１の取引ＩＤの要求に応じて、前記ＨＳＳサーバデバイスから前記購入者の認証ベクトルを取得して、第１のチャレンジを発行し、前記第１のチャレンジの発行に対して、前記購入者から前記購入者暗号鍵を含む応答を受信することを含み、
    前記マーチャントの認証は、前記ＢＳＦサーバデバイスが、前記マーチャントからの第２の取引ＩＤの要求に応じて、前記ＨＳＳサーバデバイスから前記マーチャントの認証ベクトルを取得して、第２のチャレンジを発行し、前記第２のチャレンジの発行に対して、前記マーチャントから前記マーチャント暗号鍵を含む応答を受信することを含むことを特徴とする決済システム。
26. 前記ＳＶＰＯＳサーバデバイスは、前記購入者が前記パッケージを前記ＳＶＰＯＳサーバデバイスに返送したことに応答して、前記パッケージが正しい製品を含むかどうかを判定するために調停を実施するように構成されており、
    前記ＳＶＰＯＳサーバデバイスは、前記調停のために、
    正しい製品ＩＤが送信されたかどうかを判定する手段であって、前記正しい製品ＩＤは、データベースに記憶された製品ＩＤと、送信された製品ＩＤとの比較に基づいて判定される、手段と、
    正しい製品が送信されたかどうかを判定する手段と、
    前記送信された製品ＩＤと、送信された製品とを比較する手段と
    を備えることを特徴とする請求項２５に記載の決済システム。
27. 前記購入者の識別情報が前記マーチャントに送信されないようにすることによって前記購入者の匿名性を提供するために、前記購入者および前記マーチャントと、前記決済システムとの間の仲介として機能するように構成された認証プロキシデバイス
    をさらに備えたことを特徴とする請求項２５に記載の決済システム。
28. 前記モバイル電子デバイスは携帯電話を含むことを特徴とする請求項１に記載の電子的な支払い方法。
29. 前記モバイル電子デバイスはポータブルコンピュータを含むことを特徴とする請求項１に記載の電子的な支払い方法。
30. モバイル電子デバイス及びマーチャント端末の間で要求された製品又はサービスの電子的購買取引を実施するための方法であって、
    ＳＶＰＯＳ（Secure Virtual Point of Service）サーバデバイスが、ＢＳＦ（ブートストラップサーバ機能）サーバデバイス又は前記モバイル電子デバイスのうちの少なくとも一方で決定した購入者暗号鍵を前記モバイル電子デバイスから受信するステップと、
    前記ＳＶＰＯＳサーバデバイスが、第１の部分と製品又はサービスの要約とを含むデータを前記購入者暗号鍵で暗号化した第２の部分とを含む暗号化パッケージを前記マーチャント端末から受信するステップであって、前記第１の部分は、前記ＢＳＦサーバデバイス又は前記マーチャント端末のうちの少なくとも一方で決定したマーチャント暗号鍵によって暗号化された前記製品又はサービスを有する、受信するステップと、
    前記ＳＶＰＯＳサーバデバイスが、前記暗号化パッケージを前記モバイル電子デバイスに送信するステップと、
    前記ＳＶＰＯＳサーバデバイスが、前記マーチャント端末によって計算された、前記第１の部分の少なくとも一部分からなるマーチャントのハッシュを受信するステップと、
    前記ＳＶＰＯＳサーバデバイスが、前記モバイル電子デバイスによって計算された購入者のハッシュであって、前記第２の部分を前記購入者暗号鍵で復号して得た前記第１の部分の、少なくとも前記一部分と同じ部分からなる購入者のハッシュを受信するステップと、
    前記ＳＶＰＯＳサーバデバイスが、前記購入者のハッシュと前記マーチャントのハッシュとを比較するステップと、
    前記ＳＶＰＯＳサーバデバイスが、前記比較結果に基づいて、前記ＢＳＦサーバデバイスから取得した前記マーチャント暗号鍵を前記モバイル電子デバイスに送信するステップと
    を備えることを特徴とする方法。
31. 前記第２の部分は受領書を含み、
    前記ＳＶＰＯＳサーバデバイスが、前記モバイル電子デバイスから、取引の承認として前記受領書を受信して前記製品又はサービスの支払いを許可するステップを備えることを特徴とする請求項３０に記載の方法。
32. 前記暗号化されたパッケージが前記モバイル電子デバイスにより要求された前記製品又はサービスを含まないという前記購入者による判断に応答して、前記ＳＶＰＯＳサーバデバイスが、前記モバイル電子デバイスから前記暗号化されたパッケージを受信し、調停処理を実施するステップを備え、
    前記暗号化されたパッケージは、製品ＩＤを含み、前記調停処理を実施するステップは、
    前記ＳＶＰＯＳサーバデバイスが、正しい製品ＩＤが送信されたかを前記送信された製品ＩＤとデータベースに記憶された製品ＩＤの比較に基づいて判断するステップと、
    前記ＳＶＰＯＳサーバデバイスが、正しい製品又はサービスが送信されたかを判断するステップと、
    前記ＳＶＰＯＳサーバデバイスが、前記送信された製品ＩＤを前記送信された製品又はサービスと比較するステップと
    を含むことを特徴とする請求項３０に記載の方法。
33. モバイル電子デバイス及びマーチャント端末の間で要求された製品又はサービスの電子的購買取引を実施するためのＳＶＰＯＳ（Secure Virtual Point of Service）サーバデバイスであって、
    ＢＳＦ（ブートストラップサーバ機能）サーバデバイス又は前記モバイル電子デバイスのうちの少なくとも一方で決定した購入者暗号鍵を前記モバイル電子デバイスから受信する手段と、
    第１の部分と製品又はサービスの要約とを含むデータを前記購入者暗号鍵で暗号化した第２の部分とを含む暗号化パッケージを前記マーチャント端末から受信する手段であって、前記第１の部分は、前記ＢＳＦサーバデバイス又は前記マーチャント端末のうちの少なくとも一方で決定したマーチャント暗号鍵によって暗号化された前記製品又はサービスを有する、受信する手段と、
    前記暗号化パッケージを前記モバイル電子デバイスに送信する手段と、
    前記マーチャント端末によって計算された、前記第１の部分の少なくとも一部分からなるマーチャントのハッシュを受信する手段と、
    前記モバイル電子デバイスによって計算された購入者のハッシュであって、前記第２の部分を前記購入者暗号鍵で復号して得た前記第１の部分の、少なくとも前記一部分と同じ部分からなる購入者のハッシュを受信する手段と、
    前記購入者のハッシュと前記マーチャントのハッシュとを比較する手段と、
    前記比較結果に基づいて、前記ＢＳＦサーバデバイスから取得した前記マーチャント暗号鍵を前記モバイル電子デバイスに送信する手段と、
    前記モバイル電子デバイスで前記マーチャント暗号鍵により復号された前記第１の暗号化パッケージの内容に応じて、前記モバイル電子デバイスから前記製品または前記サービスの支払いの認可を受信する手段と
    を備えることを特徴とするＳＶＰＯＳサーバデバイス。
34. 前記第２の部分は受領書を含み、
    前記モバイル電子デバイスから、取引の承認として前記受領書を受信して前記製品又はサービスの支払いを許可する手段を備えることを特徴とする請求項３３に記載のＳＶＰＯＳサーバデバイス。
35. 前記暗号化されたパッケージが前記モバイル電子デバイスにより要求された前記製品又はサービスを含まないという前記購入者による判断に応答して、前記モバイル電子デバイスから前記暗号化されたパッケージを受信し、調停処理を実施する手段を備え、
    前記暗号化されたパッケージは、製品ＩＤを含み、前記調停処理を実施する手段は、
    前記ＳＶＰＯＳサーバデバイスが、正しい製品ＩＤが送信されたかを前記送信された製品ＩＤとデータベースに記憶された製品ＩＤの比較に基づいて判断する手段と、
    前記ＳＶＰＯＳサーバデバイスが、正しい製品又はサービスが送信されたかを判断する手段と、
    前記ＳＶＰＯＳサーバデバイスが、前記送信された製品ＩＤを前記送信された製品又はサービスと比較する手段と
    を含むことを特徴とする請求項３３に記載のＳＶＰＯＳサーバデバイス。
36. 製品またはサービスを購入するためのモバイル電子デバイスであって、
    マーチャントに対する前記製品または前記サービスの購入および支払いの要求を開始する手段と、
    ＢＳＦ（ブートストラップサーバ機能）サーバデバイスと協働して購入者暗号鍵を決定する手段と、
    マーチャント端末から暗号化されたパッケージを受信する手段であって、該暗号化されたパッケージは、前記購入者暗号鍵で暗号化された製品又はサービスの要約を有する第１の部分と前記購入者暗号鍵及びマーチャント暗号鍵で暗号化された前記製品又はサービスを有する第２の部分とを含む、受信する手段と、
    前記暗号化されたパッケージの少なくとも一部からなる購入者のハッシュを計算する手段と、
    前記要約が前記製品又はサービスを正しく特定するかを前記購入者が判断できるように、前記購入者暗号鍵を使用して前記暗号化されたパッケージを復号する手段と、
    前記購入者のハッシュが、前記一部と同じ部分からなり前記マーチャント端末により計算されたマーチャントのハッシュと一致するというＳＶＰＯＳ（Secure Virtual Point of Service）サーバデバイスの判断に応答して、マーチャント暗号鍵を受信する手段と
    を備えることを特徴とするモバイル電子デバイス。
37. 前記購入者が前記復号された製品又はサービスが前記要求された製品又はサービスに一致するかを判断するために、前記暗号化されたパッケージの前記第２の部分を前記マーチャント暗号鍵を使用して復号する手段
    をさらに備えることを特徴とする請求項３６に記載のモバイル電子デバイス。
38. 前記モバイル電子デバイス自身を前記ＢＳＦサーバデバイスに対して認証する手段であって、前記認証する手段は、
    前記ＢＳＦサーバデバイスに取引ＩＤを要求する手段と、
    前記ＢＳＦサーバデバイスからチャレンジを受信する手段と、
    前記チャレンジに応答する手段であって、該応答は前記購入者暗号鍵の送信を含む、応答する手段と
    を含むことを特徴とする請求項３６に記載のモバイル電子デバイス。
39. 前記暗号化されたパッケージの前記第２の部分は、製品ＩＤおよび受領書をさらに含むことを特徴とする請求項３７に記載のモバイル電子デバイス。
40. 製品またはサービスを販売するためのマーチャント端末であって、
    前記製品または前記サービスの要求を購入者から受信する手段であって、前記要求は、モバイル電子デバイスを使用して行われる、受信する手段と、
    認証および支払いのために、前記モバイル電子デバイスをＳＶＰＯＳ（Secure Virtual Point of Service）サーバデバイスに導く手段と、
    ＢＳＦ（ブートストラップサーバ機能）サーバデバイスと協働してマーチャント暗号鍵を決定する手段と、
    購入者暗号鍵を前記モバイル電子デバイスから受信する手段と、
    前記購入者暗号鍵を使用して暗号化された前記製品または前記サービスの要約を有する第１の部分と、前記マーチャント暗号鍵を使用した暗号化の後前記購入者暗号鍵を使用して暗号化された前記製品またはサービスを有する第２の部分とを含む暗号化されたパッケージを生成する手段と、
    前記暗号化されたパッケージを前記モバイル電子デバイスに送信する手段と、
    前記暗号化されたパッケージの少なくとも一部分からなるマーチャントのハッシュを計算する手段と、
    前記マーチャントのハッシュを前記ＳＶＰＯＳサーバデバイスに送信する手段と、
    前記マーチャントのハッシュが、前記一部分と同じ部分からなり前記モバイル電子デバイスにより計算された購入者のハッシュと一致するという前記ＳＶＰＯＳサーバデバイスの判断に応答して、前記マーチャント暗号鍵を前記ＳＶＰＯＳサーバデバイスに送信する手段と
    を備えることを特徴とするマーチャント端末。
41. 前記暗号化されたパッケージの前記第２の部分は、製品ＩＤおよび受領書をさらに含むことを特徴とする請求項４０に記載のマーチャント端末。
42. 前記マーチャント端末自身を前記ＢＳＦサーバデバイスに対して認証する手段であって、前記認証する手段は、
    前記ＢＳＦサーバデバイスに取引ＩＤを要求する手段と、
    前記ＢＳＦサーバデバイスからチャレンジを受信する手段と、
    前記マーチャント端末が、前記チャレンジに応答する手段であって、該応答は前記マーチャント暗号鍵の送信を含む、応答する手段と
    を含むことを特徴とする請求項４０に記載のマーチャント端末。

Images