(57)【要約】  電子商取引のための認証、許可、識別、決済、調停、および事後拒否防止を連携して機能させるセキュアな仮想ポイントサービス（ＳＶＰＯＳ）。商取引ごとに、購入者およびマーチャントの両方が、自身をＳＶＰＯＳに対して認証し、購入者用の暗号鍵と、マーチャント用の暗号鍵との２つの一意な暗号鍵を作成する。マーチャントは、両方の暗号鍵を使用して、少なくとも製品ＩＤを含むパッケージを暗号化する。マーチャントおよび購入者は、パッケージのハッシュを計算し、事後拒否を防止する比較のために、計算したハッシュをＳＶＰＯＳに送信する。計算されたハッシュが同じである場合、購入者は、マーチャント暗号鍵を受信し、パッケージを復号する。購入者がパッケージに満足した場合、ＳＶＰＯＳによりＰａｒｌａｙシステムを介した支払いが認可される。購入者が満足しない場合、ＳＶＰＯＳは、パッケージが正しいものであるかどうかを判定するために、購入者とマーチャントとの間で調停を行う。
2008541305.tif 000002
【特許請求の範囲】
【請求項１】
ａ．モバイル電子デバイスを使用して、マーチャントに対する製品またはサービスの支払いの要求を購入者から開始するステップと、
ｂ．購入者暗号鍵を決定するステップと、
ｃ．マーチャント暗号鍵を決定するステップと、
ｄ．前記製品または前記サービスに関する識別情報を含む暗号化されたパッケージを生成するステップであって、該パッケージは、前記購入者暗号鍵および前記マーチャント暗号鍵の両方を使用して暗号化される、生成するステップと、
ｅ．前記パッケージの少なくとも一部分からなるマーチャントのハッシュを計算するステップと、
ｆ．前記パッケージの少なくとも同じ部分からなる購入者のハッシュを計算するステップと、
ｇ．前記購入者のハッシュと前記マーチャントのハッシュとを比較するステップと、
ｈ．前記比較に基づいて、前記マーチャント暗号鍵を前記購入者に送信するステップと、
ｉ．前記マーチャント暗号鍵を使用して前記パッケージを復号し、前記暗号化されたパッケージが正しいものであるかどうかを判定するステップと、
ｊ．前記判定に基づいて、前記製品または前記サービスの支払いを認可するステップと
を備えることを特徴とする電子的な支払い方法。
【請求項２】
前記モバイル電子デバイスを使用している購入者と、前記製品または前記サービスを販売しているマーチャントとを認証するステップ
をさらに備えることを特徴とする請求項１に記載の電子的な支払い方法。
【請求項３】
セキュアな仮想ポイントサービス（ＳＶＰＯＳ）を介した支払いを許可するステップと、
前記許可を受信すると、前記購入者暗号鍵を前記マーチャントに送信するステップと
をさらに備えることを特徴とする請求項１に記載の電子的な支払い方法。
【請求項４】
前記認証するステップは、
前記購入者について、
（ｉ）ブートストラップサーバに第１の取引ＩＤを要求するサブステップと、
（ｉｉ）ホーム加入者サーバ（ＨＳＳ）から前記購入者の認証ベクトルを取得するサブステップと、
（ｉｉｉ）前記購入者にチャレンジを発行するサブステップと、
（ｉｖ）前記チャレンジに応答するサブステップであって、該応答は前記購入者暗号鍵を含む、応答するサブステップと、
（ｖ）前記購入者およびＳＶＰＯＳに前記第１の取引ＩＤを送信するサブステップと
を含み、
前記マーチャントについて、
（ｖｉ）前記ブートストラップサーバに第２の取引ＩＤを要求するサブステップと、
（ｖｉｉ）前記ＨＳＳから前記マーチャントの認証ベクトルを取得するサブステップと、
（ｖｉｉｉ）前記マーチャントにチャレンジを発行するサブステップと、
（ｉｘ）前記チャレンジに応答するサブステップであって、該応答は前記マーチャント暗号鍵を含む、応答するサブステップと、
（ｘ）前記マーチャントおよび前記ＳＶＰＯＳに前記第２の取引ＩＤを送信するサブステップと
を含むことを特徴とする請求項２に記載の電子的な支払い方法。
【請求項５】
前記購入者暗号鍵および前記マーチャント暗号鍵は、前記モバイルデバイスにおけるＳＩＭカード内と、前記マーチャントに存在するＳＩＭカード内の一意な識別情報に基づいて生成され、前記購入者暗号鍵および前記マーチャント暗号鍵は、取引ごとに異なることを特徴とする請求項１に記載の電子的な支払い方法。
【請求項６】
前記暗号化されたパッケージは、前記製品または前記サービス、製品ＩＤ、および受領書をさらに含むことを特徴とする請求項１に記載の電子的な支払い方法。
【請求項７】
前記製品が正しいものでない場合、前記購入者は、調停のために、前記暗号化されたパッケージをＳＶＰＯＳに送信することを特徴とする請求項６に記載の電子的な支払い方法。
【請求項８】
前記製品が正しいと判定された場合、前記購入者は、前記受領書をＳＶＰＯＳに送信し、支払いが認可されることを特徴とする請求項６に記載の電子的な支払い方法。
【請求項９】
前記調停は、
（ｉ）正しい製品ＩＤが送信されたかどうかを判定するサブステップであって、前記正しい製品ＩＤは、データベースに記憶された製品ＩＤと、送信された製品ＩＤとの比較に基づいて判定される、判定するサブステップと、
（ｉｉ）正しい製品が送信されたかどうかを判定するサブステップと、
（ｉｉｉ）前記送信された製品ＩＤと、送信された製品とを比較するサブステップと
を含むことを特徴とする請求項７に記載の電子支払い方法。
【請求項１０】
ａ．前記暗号化されたパッケージを前記購入者に送信するステップと、
ｂ．前記購入者暗号鍵のみを使用して、前記暗号化されたパッケージを復号するステップと、
ｃ．前記暗号化されたパッケージに含まれる前記製品または前記サービスに関する前記識別情報を確認するステップと、
ｄ．前記識別情報が要求した前記製品または前記サービスと一致するかどうかを判定するステップと、
ｅ．前記判定に基づいて前記購入者のハッシュを計算するステップと
をさらに備えることを特徴とする請求項１に記載の電子的な支払い方法。
【請求項１１】
前記マーチャントのハッシュは、鍵付きハッシュであり、公開鍵インフラストラクチャを介して取得される鍵を使用して暗号化されることを特徴とする請求項１に記載の電子的な支払い方法。
【請求項１２】
製品またはサービスを購入する方法であって、
ａ．モバイル電子デバイスを使用して、マーチャントに対する前記製品または前記サービスの購入および支払いの要求を開始するステップと、
ｂ．購入者暗号鍵を決定するステップと、
ｃ．前記マーチャントから暗号化されたパッケージを受信するステップであって、該暗号化されたパッケージは、少なくとも前記購入者暗号鍵を使用して暗号化され、少なくとも、前記製品または前記サービスに関する識別情報を含む、受信するステップと、
ｄ．前記暗号化されたパッケージの少なくとも一部からなる購入者のハッシュを計算するステップと、
ｅ．マーチャント暗号鍵を使用して前記暗号化されたパッケージを復号し、該暗号化されたパッケージが正しいものであるかどうかを判定するステップと、
ｆ．前記判定に基づいて、前記製品または前記サービスの支払いを認可するステップと
を備えることを特徴とする製品またはサービスを購入する方法。
【請求項１３】
前記マーチャント暗号鍵は、前記計算された購入者のハッシュが正しい場合にのみ受信され、前記計算された購入者のハッシュが計算されたマーチャントのハッシュと一致する場合、該計算された購入者のハッシュは正しいものであることを特徴とする請求項１２に記載の製品またはサービスを購入する方法。
【請求項１４】
前記モバイル電子デバイスを使用している購入者と、前記製品または前記サービスを販売しているマーチャントとを認証するステップ
をさらに備えることを特徴とする請求項１２に記載の製品またはサービスを購入する方法。
【請求項１５】
前記認証するステップは、
前記購入者について、
（ｉ）ブートストラップサーバに第１の取引ＩＤを要求するサブステップと、
（ｉｉ）ホーム加入者サーバ（ＨＳＳ）から前記購入者の認証ベクトルを取得するサブステップと、
（ｉｉｉ）前記購入者にチャレンジを発行するサブステップと、
（ｉｖ）前記チャレンジに応答するサブステップであって、該応答は前記購入者暗号鍵を含む、応答するサブステップと、
（ｖ）前記購入者およびセキュアな仮想ポイントサービス（ＳＶＰＯＳ）に前記第１の取引ＩＤを送信するサブステップと
を含み、
前記マーチャントについて、
（ｖｉ）前記ブートストラップサーバに第２の取引ＩＤを要求するサブステップと、
（ｖｉｉ）前記ＨＳＳから前記マーチャントの認証ベクトルを取得するサブステップと、
（ｖｉｉｉ）前記マーチャントにチャレンジを発行するサブステップと、
（ｉｘ）前記チャレンジに応答するサブステップであって、該応答は前記マーチャント暗号鍵を含む、応答するサブステップと、
（ｘ）前記マーチャントおよび前記ＳＶＰＯＳに前記第２の取引ＩＤを送信するサブステップと
を含むことを特徴とする請求項１４に記載の製品またはサービスを購入する方法。
【請求項１６】
前記暗号化されたパッケージは、前記製品または前記サービス、製品ＩＤ、および受領書をさらに含むことを特徴とする請求項１２に記載の製品またはサービスを購入する方法。
【請求項１７】
前記製品が正しいものでない場合、前記購入者は、調停のために、前記暗号化されたパッケージをＳＶＰＯＳに送信することを特徴とする請求項１６に記載の製品またはサービスを購入する方法。
【請求項１８】
前記製品が正しいと判定された場合、前記購入者は、前記受領書をＳＶＰＯＳに送信し、支払いが認可されることを特徴とする請求項１６に記載の製品またはサービスを購入する方法。
【請求項１９】
前記調停は、
（ｉ）正しい製品ＩＤが送信されたかどうかを判定するサブステップであって、前記正しい製品ＩＤは、データベースに記憶された製品ＩＤと、送信された製品ＩＤとの比較に基づいて判定される、判定するサブステップと、
（ｉｉ）正しい製品が送信されたかどうかを判定するサブステップと、
（ｉｉｉ）前記送信された製品ＩＤと、送信された製品とを比較するサブステップと
を含むことを特徴とする請求項１７に記載の製品またはサービスを購入する方法。
【請求項２０】
製品またはサービスを販売する方法であって、
ａ．前記製品または前記サービスの購入および支払いの要求を購入者から受信するステップであって、前記要求は、モバイル電子デバイスを使用して行われる、受信するステップと、
ｂ．認証および支払いのために、前記購買者をセキュアな仮想ポイントサービス（ＳＶＰＯＳ）に導くステップと、
ｃ．マーチャント暗号鍵を決定するステップと、
ｄ．前記製品または前記サービスに関する識別情報を含む暗号化されたパッケージを生成するステップであって、該暗号化されたパッケージは、前記マーチャント暗号鍵および購入者暗号鍵の両方を使用して暗号化され、前記購入者に送信される、生成するステップと、
ｅ．前記暗号化されたパッケージの少なくとも一部分からなるマーチャントのハッシュを計算するステップであって、前記計算されたハッシュは、前記ＳＶＰＯＳに送信される、計算するステップと、
ｆ．前記暗号化されたパッケージの少なくとも一部分からなる前記マーチャントのハッシュと、計算された購入者のハッシュとを比較するステップと、
ｇ．前記比較に基づいて、前記マーチャント暗号鍵を前記購入者に送信するステップと、
ｈ．前記購入者が満足したかどうかの判定に基づいて、前記購入および前記支払いを決済するステップと
を備えることを特徴とする製品またはサービスを販売する方法。
【請求項２１】
前記購入者暗号鍵は、前記購入者の認証が成功した後にのみ、前記ＳＶＰＯＳから前記マーチャントに送信されることを特徴とする請求項２０に記載の製品またはサービスを販売する方法。
【請求項２２】
前記暗号化されたパッケージは、前記製品または前記サービス、製品ＩＤ、および受領書をさらに含むことを特徴とする請求項２０に記載の製品またはサービスを販売する方法。
【請求項２３】
前記満足したかどうかの判定は、前記製品が正しいものであるかどうかを判定することを含み、前記製品が正しいものでない場合、前記購入および前記支払いを前記決済するステップは、調停を含むことを特徴とする請求項２２に記載の製品またはサービスを販売する方法。
【請求項２４】
前記満足したかどうかの判定は、前記製品が正しいものであるかどうかを判定することを含み、前記製品が正しいものである場合、前記購入および前記支払いを前記決済するステップは、
（ｉ）前記ＳＶＰＯＳによって前記受領書を受信するサブステップと、
（ｉｉ）前記ＳＶＰＯＳを介して前記購入者からの支払いを受領するサブステップと
を含むことを特徴とする請求項２２に記載の製品またはサービスを販売する方法。
【請求項２５】
前記計算された購入者のハッシュは、前記購入者によって前記ＳＶＰＯＳに送信されることを特徴とする請求項２０に記載の製品またはサービスを販売する方法。
【請求項２６】
前記マーチャント暗号鍵は、前記計算されたマーチャントのハッシュと前記計算された購入者のハッシュが、前記ステップ（ｇ）において実質的に同じであると判明した場合にのみ、前記購入者に送信されることを特徴とする請求項２５に記載の製品またはサービスを販売する方法。
【請求項２７】
商取引の電子的な支払いに使用するセキュアな仮想ポイントサービス（ＳＶＰＯＳ）であって、
認証のために、購入者およびマーチャントの両方をブートストラップサーバ機能（ＢＳＦ）にリダイレクトする手段と、
前記購入者から支払いの許可を得る手段と、
パッケージの少なくとも一部分からなる計算されたマーチャントのハッシュと、前記パッケージの少なくとも一部分からなる計算された購入者のハッシュとを受信する手段であって、前記パッケージは、少なくとも製品ＩＤを含む、受信する手段と、
前記マーチャントのハッシュと、前記購入者のハッシュとを比較する手段と、
前記比較に基づいて、マーチャント暗号鍵を前記購入者に送信する手段と、
前記購入者が前記パッケージに満足したかどうかの判定に基づいて、前記商取引の支払いを決済する手段と
を備えたことを特徴とするＳＶＰＯＳ。
【請求項２８】
前記商取引の支払い情報を記憶する記憶手段であって、該支払い情報は、前記商取引の価格と前記商取引の受領書とを含む、記憶手段
をさらに備えたことを特徴とする請求項２７に記載のＳＶＰＯＳ。
【請求項２９】
前記支払いを決済する手段は、調停手段を含み、該調停手段は、前記マーチャントが前記パッケージに正しい製品と正しい製品ＩＤとを含めたかどうかを判定することを特徴とする請求項２７に記載のＳＶＰＯＳ。
【請求項３０】
商取引の決済システムであって、
購入者およびマーチャントの認証ベクトルを記憶するホーム加入者サーバ（ＨＳＳ）と、
前記購入者および前記マーチャントから情報を取得し、前記ＨＳＳに記憶された前記認証ベクトルを使用して前記情報を確認することにより、前記購入者および前記マーチャントの両方を認証するブートストラップサーバ（ＢＳＦ）と、
購入者の口座からマーチャントの口座に支払いを振り込み、前記商取引の記録を保持するＰＡＲＬＡＹサーバと、
前記決済システムの動作を管理するセキュアな仮想ポイントサービス（ＳＶＰＯＳ）であって、該ＳＶＰＯＳは、認証のために、前記購入者および前記マーチャントを前記ＢＳＦに送信し、認証の後、前記ＳＶＰＯＳは、モバイル財布として前記ＰＡＲＬＡＹサーバを使用した前記商取引の支払いの許可を得、購入者暗号鍵を前記マーチャントに送信し、前記ＳＶＰＯＳは、パッケージの少なくとも一部分からなる購入者のハッシュ値と、前記パッケージの少なくとも一部分からなるマーチャントのハッシュ値とを比較する事後拒否防止部を含み、前記ＳＶＰＯＳは、前記購入者のハッシュ値と前記マーチャントのハッシュ値とが同じである場合、マーチャント暗号鍵を前記購入者に送信し、前記購入者が前記ＳＶＰＯＳに前記パッケージを返送しなければ、前記ＳＶＰＯＳは、前記ＰＡＲＬＡＹサーバを使用した前記マーチャントへの支払いを認可するＳＶＰＯＳと
を備えたことを特徴とする決済システム。
【請求項３１】
前記ＳＶＰＯＳは、前記購入者が前記パッケージを前記ＳＶＰＯＳに返送した場合に、前記パッケージが正しい製品と製品ＩＤとを含むかどうかを判定する調停エンティティをさらに含むことを特徴とする請求項３０に記載の決済システム。
【請求項３２】
前記購入者の匿名性を提供するために、前記購入者および前記マーチャントと、前記決済システムとの間の仲介として機能する認証プロキシ
をさらに備えたことを特徴とする請求項３０に記載の決済システム。
【請求項３３】
前記モバイル電子デバイスは携帯電話であることを特徴とする請求項１に記載の電子的な支払い方法。
【請求項３４】
前記モバイル電子デバイスはポータブルコンピュータであることを特徴とする請求項１に記載の電子的な支払い方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、事業者を介した任意の２人の加入者間でピアツーピアの取引を可能にする無線ネットワークに関する。より詳細には、本発明は、電子財布としてモバイル無線デバイスを使用して取引の支払いを行うことが可能な３Ｇ無線ネットワークのセキュアな仮想ポイントサービスに関する。
【背景技術】
【０００２】
（関連出願の相互参照）  
本願は、Ｆａｒａｍａｋ  Ｖａｋｉｌらの名で２００５年５月１７日に出願された「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 }を、ＵＥ１１０に配信するために作成する。「プレビュー」は、ユーザが受け取った製品が要求したものであるかどうかを確認するための製品の要約である。
【００５０】
別の実施形態では、パッケージは、製品の要約または説明、受領書、および製品ＩＤだけを含む。
【００５１】
追加的に、ステップ２４５で、マーチャント１２０はハッシュファイルを生成する。ＳＶＰＯＳの事後拒否防止方式ではハッシュ関数が用いられる。ファイル／コンテンツをハッシュすると、一意（不可逆）なハッシュ出力が作成される。コンテンツが１ビットでも変化すると、異なるハッシュ出力になる。
【００５２】
別の実施形態では、ハッシュファイルは、鍵付きハッシュとすることができる。Ｋｓ−Ｎｒは、標準的なハッシュ関数ｈａｓｈＳＴＤの「事後拒否防止鍵」を表している。ＵＥ１１０およびマーチャント１２０が、事後拒否から取引を保護するために、この鍵を使用する。マーチャント１１０が、自身のＫｓ−Ｎｒを使用してハッシュに署名をすると、そのコンテンツと、そのハッシュがマーチャント１２０によって署名されたこととを保証する一意な署名が生成される。ＵＥ１１０（または、加入者の代理であるＳＶＰＯＳｂ１００）は、マーチャント公開鍵を使用してハッシュを復号することにより、そのハッシュがマーチャント１２０によって署名されたことを検証することができる。
【００５３】
マーチャント１２０は、Ｋｓ−ＭＥＲ‖ＵＥ−ＴＭＳＩによって暗号化された製品、受領書、および製品ＩＤのハッシュ（ｈａｓｈｄと表記する）、すなわち、hashd = hashSTD (Ks-MER‖UE-TMSI {Product + receipt + Product-ID})を作成し、そのハッシュをＳＶＰＯＳｍ１００ｍに送信する。代替として、ハッシュから製品が除かれてもよい。その場合、ハッシュは、受領書および製品ＩＤだけを含む。
【００５４】
ステップ２５０で、ＵＥ１１０は、パッケージを受信し、Ｋｓ−ＵＥを用いてパッケージを復号する。ＵＥ１１０は、(Preview + Ks-MER‖UE-TMSI {Product + receipt + Product-ID })を導出し、ｈａｓｈｄを計算する。この計算は、マーチャント１２０によって実行される計算と同じである。ＵＥ１１０は、計算したｈａｓｈｄをＳＶＰＯＳｂ１００ｂに送信する。同様に、ハッシュから製品を除くことができる。
【００５５】
ステップ２５５で、ＳＶＰＯＳ１００は、マーチャント公開鍵を使用して、マーチャント１２０から受信した署名付きのｈａｓｈｄを復号し、そのｈａｓｈｄが、ＵＥ１１０から受信したｈａｓｈｄと一致するかどうかを確認する。購入者のＳＶＰＯＳとマーチャントのＳＶＰＯＳとのうちの少なくとも一方が、この復号を行うことができる。ＵＥ１１０から受信したｈａｓｈｄの値とマーチャント１２０から受信したｈａｓｈｄの値とが一致する、すなわち同じである場合（ステップ２６０）、ステップ２６５で、ＳＶＰＯＳ１００は、加入者が製品を見ることができるように、Ｋｓ−ＭＥＲをＵＥ１１０に送信する。値の一致は、ＵＥ１１０が正しくパッケージを受信したことを意味する。値が一致しない場合は、ステップ２６１で取引が終了する。
【００５６】
ステップ２７０で、ＵＥ１１０は、ＳＶＰＯＳ１００（例えばＳＶＰＯＳｂ１００ｂ）からＵＥ１１０に転送されたＫｓ−ＭＥＲを使用して、パッケージを復号する。一実施形態では、このパッケージは、製品、受領書、および製品ＩＤを含む。ＵＥ１１０は、自身の鍵Ｋｓ−ＵＥも使用して、パッケージを復号する。ステップ２７５で、ＵＥ１１０は、製品またはサービスが満足のいくものであるかどうか、あるいは、製品またはサービスがパッケージに含まれない場合には、要約（製品の説明）が満足のいくものであるかどうかを判定する。この判定には、製品ＩＤと、受け取った製品と、ＵＥ１１０が選択した当初の製品とを比較することを含めることができる。製品または製品の説明が、満足のいくもので、かつ正しい場合、ステップ２８０で、ＵＥ１１０は、取引を承認する。具体的には、ＵＥ１１０は、受領書をＳＶＰＯＳｂ１００ｂに送信する。ＳＶＰＯＳｂ１００ｂが受領書を受信すると、ＳＶＰＯＳ１００（購入者のＳＶＰＯＳとマーチャントのＳＶＰＯＳとが異なる場合は、それらの両方）は、特に、時刻と、購入者の名前および販売者の名前と、取引の受領書と、購入者の最終的な承認とを含むセッションデータレコードを作成し、マーチャント（または、必要に応じて、マーチャントの事業者）に支払いをするために、そのレコードを購入者の事業者の会計エンティティに送信し、その取引を購入者の月々の請求に課金する。
【００５７】
これに対し、ＵＥ１１０が、製品または製品の説明に満足しない場合は、ステップ２８５で、ＵＥ１１０は、（受け取った場合は）製品、製品ＩＤおよび受領書を含むパッケージをＳＶＰＯＳｂ１００ｂに返送する。
【００５８】
パッケージが購入製品を含んでいる場合、ＳＶＰＯＳｂ１００ｂは、そのパッケージが返送された理由を調査する。返送されるパッケージには、３つの一般的なシナリオがある。第１のシナリオは、マーチャント１２０が誤って間違った製品と、間違ったプレビューまたは要約とをパッケージに入れて送信した場合である。この場合、マーチャント１２０は、間違った製品に対してハッシュを計算する。ＵＥ１１０は、プレビューが、要求した製品のプレビューと一致しないことに気付き、ＳＶＰＯＳｂ１００ｂおよびマーチャント１２０に通知する。間違いは意図したものではなかったため、マーチャント１２０は、正しい製品を再送することにより、そのような状況に対処する。
【００５９】
通常この場合、ＵＥ１１０は、ステップ２５０で、Ｋｓ−ＵＥを用いてパッケージを開いた時にプレビューまたは要約が正しくないことに気付く。前述したように、ＵＥ１１０は、プレビューまたは要約だけを見て、製品は見ない。ＵＥ１１０は、この時点でＳＶＰＯＳｂ１００ｂおよびマーチャント１２０に通知するか、ステップ２７５まで待つことができる。
【００６０】
第２のシナリオは、マーチャント１２０が意図的に（または誤って）間違った製品をパッケージに挿入する場合である。しかし、パッケージに挿入されたプレビューまたは要約は正しい。すなわち、ＵＥ１００から要求された製品のプレビューまたは要約である。
【００６１】
この場合、マーチャント１２０は、間違った製品と、正しいプレビューまたは要約と、正しい製品ＩＤまたは間違った製品ＩＤとからなるパッケージのｈａｓｈｄを計算する。ステップ２５０で、ＵＥ１１０は、正しいプレビューまたは要約を見て、ＳＶＰＯＳｂ１００ｂにＫｓ−ＭＥＲを要求する。ＵＥ１１０から返されるｈａｓｈｄは、マーチャント１２０から送信されたｈａｓｈｄと一致する。ＳＶＰＯＳ１００が、ＵＥ１１０から返されたパッケージのｈａｓｈｄを計算すると、そのｈａｓｈｄは、元のｈａｓｈｄと一致する。したがって、ＳＶＰＯＳ１００（ＳＶＰＯＳｂ１００ｂまたはＳＶＰＯＳｍ１００ｍ）は、製品ＩＤが、正しい製品すなわちＵＥ１１０が購入を望む製品のＩＤと一致するかどうかを検証することにより、この争いを解決しなければならない。マーチャント１２０が誤って間違った製品を挿入し、さらに間違った製品ＩＤも挿入した場合、ＳＶＰＯＳ１００は、ＵＥ１１０から受信した製品ＩＤと、（ＳＶＰＯＳの内部データベース、または独立した機関から得られる、）意図される製品の正しい製品ＩＤとを比較する。製品ＩＤが一致しないことにより、その取引に異議を唱え、パッケージを返送したことについて、ＵＥ１１０が正しかったことが明らかになり、ＳＶＰＯＳ１００は、争いを解決するために必要なステップをとる。
【００６２】
マーチャント１２０が間違った製品を挿入し、正しい製品ＩＤを挿入した場合、マーチャント１２０は、間違った製品と、正しいプレビューまたは要約と、正しい製品ＩＤとからなるパッケージのｈａｓｈｄを計算することになる。ステップ２５０で、ＵＥ１１０は、正しいプレビューまたは要約を見て、ＳＶＰＯＳｂ１００ｂにＫｓ−ＭＥＲを要求する。これは、マーチャント１２０が正しいプレビューまたは要約と製品ＩＤとを挿入することにより、間違ったコンテンツを送って、ＵＥ１１０およびＳＶＰＯＳ１００を混乱させることを悪意的に試みた場合である。ＵＥ１１０およびマーチャント１２０両方からのハッシュファイルの比較は一致する。また、ＳＶＰＯＳ１００による製品ＩＤの比較においても、一致が得られる。ＳＶＰＯＳ１００は、（例えば、ＭＰＡなどの独立した機関を介して、）受け取った製品のハッシュが、マーチャントによって挿入された製品ＩＤになることを検証しようと試みる。この検証の結果、製品ＩＤは一致せず、これは、マーチャントが不正行為を犯そうと試みたことを意味する。
【００６３】
第３のシナリオは、ＵＥ１１０が正しい製品を得たが、パッケージをＳＶＰＯＳｂ１００ｂに返送することにより、間違った製品が挿入されていたと主張しようと試みる場合である。ＵＥ１１０は、受け取ったプレビューまたは要約が要求した製品のものであっても、間違った製品を受け取ったと主張する。争いがあった場合、ＵＥ１１０は、争いを解決するためにパッケージ全体をＳＶＰＯＳ１００に送信する。ＵＥ１１０は、取得したプレビューまたは要約は要求した製品のものと一致したが、マーチャント１２０が不正に間違った製品を挿入したと主張する。ＵＥ１１０がＳＶＰＯＳ１００にパッケージを返送する場合、ＵＥ１１０は、マーチャント１２０が故意に間違った製品を挿入したことを証明しようとして、（Ｋｓ−ＭＥＲ‖ＵＥ−ＴＭＳＩによって暗号化された）間違った製品ＩＤまたは間違った製品を意図的に挿入する。ＳＶＰＯＳは、ＵＥ１１０から返送されたパッケージのhashd = hashmer (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}を導出し、ｈａｓｈｄを計算する（６２９）。ＵＥ１１０は、計算したｈａｓｈｄをＳＶＰＯＳ１００に送信する。計算されたハッシュは、ＨＴＴＰ  ＰＯＳＴの一部として送信される（６３０ａおよび６３０ｂ）。ＳＶＰＯＳ１００は、（ＵＥ１１０およびＳｏｎｙ１２０からの）両方のハッシュファイルを比較して、ハッシュが同一であるかどうかを判定する。ハッシュが一致した場合は、ＵＥ１１０がパッケージを正しく受信したことが保証される（ただし、映画が、ユーザが要求したものと同じであることは保証されない）。ハッシュが一致した場合、ＳＶＰＯＳ１００は、Ｓｏｎｙ１２０およびＵＥ１１０の両方にＨＴＴＰ  ＯＫメッセージを送信する。ＳｏｎｙへのメッセージＨＴＴＰ  ＯＫ６３１には、ＴＩＤしか含まれないが、ＵＥ１１０へのメッセージＨＴＴＰ  ＯＫ（６３１ａおよび６３１ｂ）には、ＴＩＤおよびＫｓ−Ｓｏｎｙの両方が含まれる。ＵＥ１１０は、映画、受領書、および映画ＩＤを復号する（６３２）。映画が正しいものである場合、ＵＥ１００は、ＳＶＰＯＳ１００に受領書を送信し（ＨＴＴＰ  ＰＯＳＴ６３３ａおよび６３３ｂ）、取引は成功して終了する。映画が正しいものでない場合、ＵＥ１１０は、ＳＶＰＯＳ１００にパッケージを返送し（ＨＴＴＰ  ＰＯＳＴ６３３ａおよび６３３ｂ）（受領書は含めない）、取引に関するＳＶＰＯＳ１００の決定を待つ。
【００７７】
取引が成功した場合、ＳＶＰＯＳ１００は、Ｓｏｎｙ１２０への支払いを認可する。ＳＶＰＯＳ１００は、ＵＥ１１０にＨＴＴＰ  ＯＫ（６３５ａおよび６３５ｂ）を送信する。このメッセージは、受領書を含む。争いがある場合、すなわちＵＥ１１０がパッケージを返送した場合、ＳＶＰＯＳ１００は調停を行う。ＳＶＰＯＳ１００は、ＵＥ１１０にＨＴＴＰ  ＯＫ（６３５ａおよび６３５ｂ）を送信する。このメッセージは、調停の結果を含む。
【００７８】
図９および図１０は、本発明の一実施形態による、映画購入の例のメッセージフローを示している。この代替実施形態では、ＵＥ１１０は、ＡＰ１４０を仲介として使用せずに通信する。ＡＰ１４０が除かれたので、メッセージは中継されない。メッセージのフローやメッセージの順序は、図５および図６のメッセージ、すなわち６００〜６３５と同じである。これらのメッセージは、符号９００〜９３４である。図５および図６と、図９および図１０との違いは、図９および図１０ではＴＬＳトンネルが必要でないことである。したがって、各メッセージについては、繰り返して説明しないことにする。
【００７９】
本発明について、特定の例示的実施形態を参照しながら説明した。当業者であれば、本発明の範囲から逸脱することなく、所定の改変および変更が可能であることが明らかでなろう。例示的実施形態は、説明を目的とするものであり、特許請求の範囲において定義される本発明の範囲を限定するものではない。
【図面の簡単な説明】
【００８０】
【図１】本発明の一実施形態による、加入者、マーチャント、およびＳＶＰＯＳを含む３Ｇ無線ネットワークを示す説明図である。
【図２】ＳＶＰＯＳの動作を示すフローチャートである。
【図３】本発明の一実施形態による、ＵＥまたはマーチャントを認証するステップを示すフローチャートである。
【図４】本発明の一実施形態による、ＵＥを使用した支払いを許可するステップを示すフローチャートである。
【図５】本発明の一実施形態による、映画の電子的な支払いのメッセージフローを示す図である。
【図６】本発明の一実施形態による、映画の電子的な支払いのメッセージフローを示す図である。
【図７】本発明の一実施形態による、映画の支払いのためにＵＥデバイスを認証する際のメッセージフローを示す図である。
【図８】本発明の一実施形態による、映画の支払いのためにＳｏｎｙを認証する際のメッセージフローを示す図である。
【図９】本発明の代替実施形態による、映画購入の支払いのためのメッセージフローを示す図である。
【図１０】本発明の代替実施形態による、映画購入の支払いのためのメッセージフローを示す図である。
【図１】
2008541305.tif 000003
【図２】
2008541305.tif 000004
【図３】
2008541305.tif 000005
【図４】
2008541305.tif 000006
【図５】
2008541305.tif 000007
【図６】
2008541305.tif 000008
【図７】
2008541305.tif 000009
【図８】
2008541305.tif 000010
【図９】
2008541305.tif 000011
【図１０】
2008541305.tif 000012
【国際調査報告】
2008541305.tif 000013