(57)【特許請求の範囲】
【請求項１】
Wi-Fi  Hotspot  2.0ネットワークについての安全なオンラインサインアップ及び提供のためにモバイルデバイスにより実行される方法であって、
EAP（Extensible  Authentication  Protocol）を使用してWi-Fiホットスポットを通じてWi-Fiアクセスネットワークと認証するステップと、
申し込みサーバを認証し、要求理由の指示を提供するために、前記申し込みサーバと初期のSOAP（Simple  Object  Access  Protocol）交換を実行するステップと、
前記Wi-Fiアクセスネットワーク上で前記申し込みサーバと最後のSOAP交換を実行するステップと
を有する方法。
【請求項２】
前記初期のSOAP交換は、
前記モバイルデバイスのデバイス機能情報を提供するステップを更に含み、
前記要求理由は、信任の提供又は申し込みの修正を有する、請求項１に記載の方法。
【請求項３】
前記初期のSOAP交換及び前記最後のSOAP交換は、トランスポート用のアプリケーションレイヤプロトコルとしてHTTPS（secure  Hypertext  Transfer  Protocol）を使用してSOAP技術に従って構成されたメッセージを有し、
前記メッセージは、XML（extensible-markup  language）メッセージフォーマットに従って構成される、請求項１に記載の方法。
【請求項４】
前記初期のSOAP交換は、
前記モバイルデバイスにより、前記SOAP技術に従ってオンラインサインアッププロトコル（osp）のポストデバイスデータ（ospPostDevData）メッセージを前記申し込みサーバに送信するステップであり、前記メッセージは、デバイス情報（DevInfo）と、デバイス詳細（DevDetail）とを含むステップと、
前記申し込みサーバから前記SOAP技術に従ってospPostDevDataResponseメッセージを受信するステップであり、応答メッセージは、Execute:LaunchBrowsertoURIコマンドを含むステップと
を有し、
前記モバイルデバイスは、ブラウザを起動し、前記応答メッセージで受信したオンラインサーバのURIに安全なHTTPS接続を確立し、前記オンラインサーバのURIにHTTPS  GET要求を送信するように構成される、請求項３に記載の方法。
【請求項５】
前記申し込みサーバがオンラインサインアップサーバ（OSU）として動作する場合、前記方法は、
Wi-Fiネットワークアクセスのサービスプロバイダと申し込みを確立し、申し込み管理オブジェクト（MO）を受信するために、前記OSUと情報を交換するステップと、
前記最後のSOAP交換の後に前記Wi-Fiホットスポットと関連付け解除するステップと、
前記Wi-Fiホットスポットと再関連付けし、Wi-Fi接続を再確立するステップと
を含み、
前記再関連付けは、EAP技術を使用し、前記再確立されたWi-Fi接続上で前記提供された信任をAAAサーバに提供するステップを含む、請求項１に記載の方法。
【請求項６】
前記申し込みサーバとの前記初期のSOAP交換の一部として、提供される信任の指示を受信するステップを更に有し、
提供される前記信任の種類は、証明書に基づく信任、ユーザ名／パスワードの信任、又は加入者情報モジュール（SIM）形式の信任のうち１つを含む、請求項１に記載の方法。
【請求項７】
申し込みの仲裁が必要な場合、前記方法は、
前記Wi-Fiホットスポットに関連付けした後に、申し込みの修正の必要性を示すアクションメッセージを受信するステップを含み、
前記初期のSOAP交換の間に、前記方法は、申し込み仲裁サーバでの申し込みの修正を要求し、SOAP技術に従って情報を交換するステップを更に含む、請求項１に記載の方法。
【請求項８】
ロジックを有する回路を含む１つ以上のプロセッサを含むデバイスであって、
前記ロジックは、
EAP（Extensible  Authentication  Protocol）を使用してWi-Fiホットスポットを通じてWi-Fiアクセスネットワーク（AN）と認証し、
申し込みサーバを認証し、要求理由の指示を提供するために、前記申し込みサーバと初期のSOAP（Simple  Object  Access  Protocol）交換を実行し、
前記Wi-Fiアクセスネットワーク上で前記申し込みサーバと最後のSOAP交換を実行するように構成されたデバイス。
【請求項９】
前記初期のSOAP交換の一部として、
前記ロジックは、更に、
前記デバイスのデバイス機能情報を提供し、
前記要求理由は、信任の提供又は申し込みの修正のうち１つを有する、請求項８に記載のデバイス。
【請求項１０】
前記初期のSOAP交換及び前記最後のSOAP交換は、トランスポート用のアプリケーションレイヤプロトコルとしてHTTPS（secure  Hypertext  Transfer  Protocol）を使用してSOAP技術に従って構成されたメッセージを有し、
前記メッセージは、XML（extensible-markup  language）メッセージフォーマットに従って構成される、請求項８に記載のデバイス。
【請求項１１】
モバイルデバイスのためにWi-Fi  Hotspot  2.0ネットワークについての安全なオンラインサインアップ及び提供を提供するための申し込みサーバにより実行される方法であって、
モバイルデバイスがWi-Fiネットワークにアクセスして前記モバイルデバイスとのWi-Fi接続を確立することを可能にするために、AAAサーバからWi-Fiホットスポットに許可メッセージを送信するステップと、
信任の提供又は申し込みの修正を実行するために、前記モバイルデバイスと初期のSOAP（Simple  Object  Access  Protocol）交換を実行するステップであり、前記初期のSOAP交換は、前記モバイルデバイスが前記申し込みサーバを認証することを含むステップと、
前記モバイルデバイスが申し込み管理オブジェクト（MO）を受信することを可能にするために、前記Wi-Fiネットワーク上で前記モバイルデバイスと最後のSOAP交換を実行するステップと
を有する方法。
【請求項１２】
Wi-Fiネットワークアクセスのサービスプロバイダと申し込みを確立し、前記申し込みの信任を提供し、前記提供された信任の前記申し込みMOを生成するために、前記モバイルデバイスと情報を交換するステップを更に有する、請求項１１に記載の方法。
【請求項１３】
前記許可メッセージは、前記Wi-Fiホットスポットにより実施されるアクセス制限を含むRADIUS  ACCESS-ACCEPTメッセージであり、前記アクセス制限は、信任の提供又は申し込みの修正のために前記Wi-Fiネットワークへの前記モバイルデバイスのアクセスを制限し、
前記許可メッセージは、EAP（Extensible  Authentication  Protocol）技術を使用して、前記モバイルデバイスが前記Wi-Fiホットスポットと関連付けしたことに応じて送信される、請求項１２に記載の方法。
【請求項１４】
前記申し込みサーバとの前記初期のSOAP交換の一部として、前記方法は、提供される信任の種類を判定し、提供される前記信任の種類を前記モバイルデバイスに示すステップを含み、
提供される前記信任の種類は、証明書に基づく信任、ユーザ名／パスワードの信任、又は加入者情報モジュール（SIM）形式の信任のうち１つを含む、請求項１３に記載の方法。
【請求項１５】
前記ロジックは、更に、
ユーザ入力を受信するためのウェブページのユーザプロンプトを提供し、
ユーザ交換において前記ユーザ入力を前記申し込みサーバと交換し、
前記ユーザ交換が終了したか否かについて前記申し込みサーバから通知を受信する、請求項８に記載のデバイス。
【請求項１６】
前記要求理由は、信任の提供であり、
前記ロジックは、前記申し込みサーバから、前記サーバにより提供される信任の種類の指示を受信する、請求項９に記載のデバイス。
【請求項１７】
前記要求理由は、申し込みの仲裁の要求であり、
前記初期のSOAP交換は、前記デバイスが前記申し込みサーバから認証の指示を受信することを含む、請求項９に記載のデバイス。
【請求項１８】
前記申し込みサーバがオンラインサインアップサーバ（OSU）として動作する場合、前記ロジックは、
Wi-Fiネットワークアクセスのサービスプロバイダと申し込みを確立し、申し込み管理オブジェクト（MO）を受信するために、前記OSUと情報を交換し、
前記最後のSOAP交換の後に前記Wi-Fiホットスポットと関連付け解除し、
前記Wi-Fiホットスポットと再関連付けし、Wi-Fi接続を再確立し、前記再関連付けは、EAP技術を使用し、前記再確立されたWi-Fi接続上で前記提供された信任をAAAサーバに提供することを含む、請求項９に記載のデバイス。
【請求項１９】
メモリと、１つ以上の送受信機とを更に含む、請求項８に記載のデバイス。
【請求項２０】
１つ以上のアンテナを更に含む、請求項１９に記載のデバイス。
【請求項２１】
１つ以上のプロセッサにより実行される命令を格納した機械可読媒体であって、
前記命令は、デバイスを、
EAP（Extensible  Authentication  Protocol）技術を使用してWi-Fiホットスポットを通じてWi-Fiネットワークと関連付けし、
申し込みサーバを認証し、要求理由の指示を提供するために、前記申し込みサーバと初期のSOAP（Simple  Object  Access  Protocol）交換を実行し、
前記Wi-Fiネットワーク上で前記申し込みサーバと最後のSOAP交換を実行するように構成する機械可読媒体。
【請求項２２】
前記命令は、前記デバイスを、前記デバイスのデバイス機能情報を提供するように更に構成し、
前記要求理由は、信任の提供又は申し込みの修正のうち１つを有する、請求項２１に記載の機械可読媒体。
【請求項２３】
前記初期及び最後のSOAP交換は、トランスポート用のアプリケーションレイヤプロトコルとしてHTTPS（secure  Hypertext  Transfer  Protocol）を使用してSOAP技術に従って構成されたメッセージを有し、
前記メッセージは、XML（extensible-markup  language）メッセージフォーマットに従って構成される、請求項２１に記載の機械可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
この出願は、2011年6月30日に出願された“MOBILE  DEVICE  AND  METHOD  FOR  AUTOMATIC  CONNECTIVITY,  DATA  OFFLOADING  AND  ROAMING  BETWEEN  NETWORKS”
（Attorney  Docket  No.884.J38US1及びClient  Ref.  No.  P37992）という題の米国特許出願第13/173,338号に関し、この全内容を援用する。
【０００２】
この出願はまた、2011年7月21日に出願された“SECURE  ON-LINE  SIGN-UP  AND  PROVISIONING  FOR  WI-FI  HOTSPOTS  USING  A  DEVICE-MANAGEMENT  PROTOCOL”（Attorney  Docket  No.884.J39US1及びClient  Ref.  No. P37993）という題の米国特許出願第13/188,205号に関し、この全内容を援用する。
【０００３】
実施例は、Wi-Fi（wireless  fidelity）ネットワークに関する。いくつかの実施例は、サービス及び接続のための安全なオンラインサインアップ及び信任（credential）の提供（プロビジョニング）に関する。いくつかの実施例は、SOAP（Simple  Object  Access  Protocol）XML（extensible-markup  language）技術を使用したオンラインサインアップ及び提供に関する。いくつかの実施例は、Hotspot  2.0ネットワーク及びHotspot  2.0の展開（evolution）に関する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
Wi-Fiネットワークアクセスのサービスプロバイダとの申し込み（契約）（subscription）の確立に関する１つの問題は、簡単且つユーザフレンドリーなプロセスではない点にある。Wi-Fi動作可能なデバイス及びネットワークのための安全なオンラインサインアップ及び信任の提供のための標準化されたプロセスは存在しない。一般的に、ユーザは、異なる種類のウェブページに直面し、異なる位置に情報を登録してユーザ名／パスワードを選択する必要があることがある。
【０００５】
申し込みの確立に関する他の問題は、セキュリティである。安全なネットワーク（802.1xの動作可能なもの等）は未登録者に対するアクセスを禁止し得るが、オープンネットワークは十分なセキュリティを提供しないことがある。現在のオンラインサインアップ機構は、ユーザを、（例えば、周知のハニーポット（honey-pot）又は双子の悪魔（twin-evil）のセキュリティホールを通じて）クレジットカード及び個人情報が盗まれることのような許容できないセキュリティ上のリスクにさらしている。
【０００６】
申し込みの確立に関する他の問題は、提供される必要がある可能性がある異なる種類の信任である。いくつかのデバイス又はネットワークは、証明書（certificate）に基づく信任を必要とすることがあり、いくつかの他のデバイス又はネットワークは、ユーザ名／パスワードの信任を使用することがある。他のデバイス又はネットワークは、加入者情報モジュール（SIM：subscriber-information  module）形式の信任を使用することがある（例えば、一般的にいくつかのセルラネットワークで使用される）。
【０００７】
従って、オンラインサインアップ及び信任の提供について一般的なニーズが存在する。また、トランスポートとしてSOAP-XML技術を使用するオンラインサインシステムを安全に使用した安全なオンラインサインアップ及び信任の提供について一般的なニーズも存在する。また、ユーザ名／パスワードの信任、SIM形式の信任及び証明書に基づく信任のような異なる種類の信任を提供するのに適した、安全なオンラインサインアップのための標準化されたプロセスの一般的なニーズも存在する。また、オープンネットワーク及び安全なネットワークの双方を含み、いずれかの802.11に基づくネットワークで使用するのに適した安全なオンラインサインアップ及び信任の提供のための標準化されたプロセスの一般的なニーズも存在する。
【図面の簡単な説明】
【０００８】
【図１】或る実施例による安全なオンラインサインアップ及び信任の提供のためのネットワークエレメントの動作環境を示す図
【図２】或る実施例によるSOAP-XML技術を使用した安全なオンラインサインアップ及び信任の提供のための概略図
【図３Ａ】或る実施例によるSOAP-XML技術を使用した安全なオンラインサインアップ及び証明書に基づく信任の提供のために交換されるメッセージを示す図
【図３Ｂ】或る実施例によるSOAP-XML技術を使用した安全なオンラインサインアップ及び証明書に基づく信任の提供のために交換されるメッセージを示す図
【図４】或る実施例によるSOAP-XML技術を使用した安全なオンラインサインアップ及びユーザ名／パスワード形式の信任の提供のために交換されるメッセージを示す図
【図５】或る実施例によるSOAP-XML技術を使用した申し込みの修正のために交換されるメッセージを示す図
【図６】或る実施例による管理オブジェクトツリーを示す図
【図７】或る実施例によるモバイルデバイスを示す図
【発明を実施するための形態】
【０００９】
以下の説明及び図面は、当業者が特定の実施例を実行可能にする程度に十分に特定の実施例を示している。他の実施例は、構造上、論理上、電気的、プロセス上及び他の変更を取り入れてもよい。或る実施例の部分及び機能は、他の実施例のものに含まれてもよく、置換されてもよい。請求項に示す実施例は、これらの請求項の全ての利用可能な等価物を含む。
【００１０】
本発明の実施例は、SOAP-XML技術を使用してユーザがWi-Fiサービスプロバイダと申し込みを確立し、信任及びポリシーコンポーネントをクライアントデバイスに安全にダウンロードできるように、Wi-Fiホットスポットサービスのための安全なオンラインサインアップ及び信任の提供を提供する。これにより、オペレータ（例えば、Wi-Fiサービスプロバイダ）は、標準化されたツールを使用してかなり低いコストでオンラインサインアップ機構を開発することが可能になる。実施例は、従来のWi-Fiネットワークと進展したHotspot  2.0ネットワークとの双方に適用可能である。本発明の実施例はまた、SOAP-XML技術を使用してWi-Fiホットスポットサービスの信任を更新する申し込みの修正も提供する。
【００１１】
図１は、或る実施例による安全なオンラインサインアップ及び信任の提供のためのネットワークエレメントの動作環境を示している。モバイルデバイス102は、Wi-Fiホットスポット104に関連付け、安全なオンラインサインアップ及び提供のためにここに記載される様々な動作を実行するように構成されたWi-Fi動作可能なデバイスでもよい。Wi-Fiホットスポット104は、インターネットサービスプロバイダへのリンクに接続されたルータで、無線ローカルエリアネットワーク（WLAN：wireless  local  area  network）上でインターネットアクセスを提供してもよい。Wi-Fiホットスポット104は、Wi-Fiネットワークの一部でもよく、インターネットのようなネットワーク105に結合されてもよく、特に、証明機関120、申し込みサーバ106、アクティベーションポータル（activation  portal）108、証明書登録サーバ110及び登録機関122を含み、ゲートウェイを通じて他の様々なネットワークエレメントに接続されてもよい。或る実施例では、申し込みサーバ106は、SOAP-XML技術に従ってメッセージを交換するように構成されたサーバでもよい。Wi-Fiホットスポット104は、Wi-Fiアクセスポイント（AP：access  point）として動作してもよい。モバイルデバイス102は、SOAP-XML技術を実装し、ここに記載の様々な動作を実行するように構成されたSOAP処理エレメント125を含んでもよい。同様に、申し込みサーバ106は、以下に詳細に説明するようにSOAP-XML技術を実装するように構成されたSOAP処理エレメント135を含んでもよい。
【００１２】
或る実施例では、Wi-Fiホットスポット104は、Wi-Fiホットスポット104の管理エンティティとして機能するアクセスコントローラ（AC：access  controller）124を含んでもよい。アクセスコントローラ124は、Wi-Fiネットワークの複数のアクセスポイントを管理してもよく、インターネットのような他のネットワークへのアクセスを提供するためのWLANアクセスネットワークのゲートウェイとして動作してもよい。アクセスコントローラ124は、Wi-Fiネットワークへのモバイルデバイスのアクセスを可能にするために、ここに記載の様々な動作を実行してもよい。
【００１３】
実施例によれば、モバイルデバイス102は、Wi-Fiホットスポットのための安全なオンラインサインアップ及び信任の提供のために構成されてもよい。或る実施例では、モバイルデバイス102は、SOAP-XML技術を使用したWi-Fiホットスポットのための安全なオンラインサインアップ及び提供のために構成されてもよい。これらの実施例では、モバイルデバイス102及び申し込みサーバ106は、SOAP（Simple  Object  Access  Protocol）に従って構成された要求及び応答メッセージを交換してもよい。
【００１４】
或る実施例では、ここに記載の安全なオンラインサインアップ及び提供プロセスにより、ユーザは、トランスポートとしてSOAP-XML技術を使用して、安全にサービスプロバイダと申し込みを確立し、モバイルデバイス102のようなクライアントデバイスへの信任及びオペレータのポリシーをダウンロードすることが可能になる。このことにより、バックエンドのコアネットワークでSOAP-XML技術を既に実装し得るセルラ形式のネットワークサービスプロバイダは、同じサーバ及びインストールされたコンポーネントを使用し、Wi-Fiネットワークにサービス提供するためのその機能を拡張することが可能になり得る。
【００１５】
或る実施例は、ユーザ名／パスワードの信任、証明書に基づく信任及びSIM形式の信任を含む、安全なオンラインサインアップ及び信任の提供のための標準化されたプロセスを提供する。安全なオンラインサインアップ及び信任の提供のための標準化されたプロセスは、ほとんど如何なるIEEE802.11に基づくネットワークに適用可能になり、そのプロセスをオープンネットワークと安全なネットワークとの双方に適用可能にし得る。例えば、安全なWi-Fiネットワークは、RSN（robust-security  network）プロトコルに従ってセキュリティを実装してもよい。このようなネットワークは、RSNネットワーク（すなわち、RSNA（robust  security  network  association）の生成を可能にするセキュリティネットワーク）と考えられてもよい。
【００１６】
従って、ユーザは、もはや異なる種類のウェブページに直面し、異なる位置に情報を登録してユーザ名／パスワードを選択する必要がなくなる。Wi-Fiネットワークは、現在では使用が容易であり、安全になっている。SOAP-XML技術の使用は、Wi-F-ネットワークの動作が現在及び将来のセルラ形式のネットワークと容易に統合されることを可能にする。或る実施例では、安全なオンラインサインアップ及び信任の提供は、ユーザの相互作用なしに自動的に実行されてもよい。
【００１７】
実施例によれば、モバイルデバイス102は、Wi-Fi  Hotspot  2.0ネットワークについて安全なオンラインサインアップ及び提供のために構成されてもよい。これらの実施例では、モバイルデバイス102は、EAP（Extensible  Authentication  Protocol）技術を使用してWi-Fiホットスポット104を通じてWi-Fiネットワークと認証するように構成されてもよい。認証の一部として、RADIUS  ACCESS-ACCEPTメッセージがAAAサーバ126からWi-Fiホットスポット104により受信され、モバイルデバイス102がWi-Fiネットワークにアクセスし、モバイルデバイス102とのWi-Fi接続を確立することを可能にする。モバイルデバイス102は、確立されたWi-Fi接続上で申し込みサーバ106と初期のSOAP交換を実行し、信任の提供又は申し込みの修正を要求してもよい。初期のSOAP交換は、モバイルデバイスが申し込みサーバ106を認証することを含む。モバイルデバイスはまた、Wi-Fiネットワークアクセスのサービスプロバイダと申し込みを確立し、申し込みのための信任を提供し、提供された信任のための申し込み管理オブジェクト（MO：management  object）を生成するために、申し込みサーバ106と情報を交換してもよい。モバイルデバイスはまた、申し込みMOを受信するために、Wi-Fiネットワーク上で申し込みサーバ106と最後のSOAP交換を実行してもよい。
【００１８】
これらの実施例では、RADIUS  ACCESS-ACCEPTの受信に応じて、Wi-Fiホットスポット104は、認証の成功を示すEAP-Successメッセージをモバイルデバイス102に送信するように構成される。或る実施例では、Wi-Fiホットスポット104との関連付け（アソシエーション）、初期及び最後のSOAP交換及び申し込みサーバ106の認証は、ユーザ入力なしに（すなわち、自動的に）実行されてもよい。或る実施例では、申し込みの確立のための申し込みサーバ106との情報の交換もまた、必要な情報に応じてユーザ入力なしに実行されてもよい。或る実施例では、この方法は、ユーザ入力のためにユーザに促し、ユーザ入力を申し込みサーバ106に提供することを含んでもよい。
【００１９】
或る実施例では、初期のSOAP交換は、モバイルデバイス102の少なくともいくつかのデバイス機能情報を提供し、要求の理由（例えば、信任の提供又は申し込みの修正）を示すことを含んでもよい。要求の理由が信任の提供である場合、申し込みサーバ106は、提供される申し込みの種類を示してもよい。
【００２０】
或る実施例では、初期及び最後のSOAP交換は、トランスポート用のアプリケーションレイヤプロトコルとして安全なハイパーテキスト転送プロトコル（HTTPS）を使用してSOAP技術に従って構成されたメッセージを有する。メッセージは、XML（extensible-markup  language）メッセージフォーマットに従って構成されてもよい。HTTPSは、安全な暗号化された通信を提供するために、HTTPとSSL/TLSプロトコルとの組み合わせを含んでもよい。
【００２１】
或る実施例では、RADIUS  ACCESS-ACCEPTメッセージは、Wi-Fiホットスポット104により実施されるアクセス制限を含んでもよい。アクセス制限は、信任の提供又は申し込みの修正のためのWi-Fiネットワークへのモバイルデバイス102のアクセスを制限する。Wi-Fiホットスポット104は、初期及び最後のSOAP交換の実行と、信任の提供又は申し込みの修正のためのサービスプロバイダとの情報の交換とにモバイルデバイス102を制限することにより、アクセス制限を実施するように構成されてもよい。
【００２２】
申し込みMOを受信した後に、モバイルデバイスは、最後のSOAP交換の後にWi-Fiホットスポット104と関連付けを解除し、Wi-Fiホットスポット104と再関連付けしてWi-Fi接続を再確立するように構成されてもよい。再関連付けの際に、モバイルデバイス102は、EAP技術を使用するように構成されてもよく、再確立されたWi-Fi接続上で提供された信任をAAAサーバ126に提供してもよい。RADIUS  ACCESS-ACCEPTメッセージは、ユーザの申し込みに従ってWi-Fiネットワークへのモバイルデバイス102のアクセスを許可するために、AAAサーバ126からWi-Fiホットスポット104で受信されてもよい。或る実施例では、関連付け解除及び再関連付けは、ユーザの相互作用なしに実行されてもよい。Wi-Fiホットスポット104は、ユーザの申し込みに関連するRADIUS  ACCESS-ACCEPTメッセージで示されたアクセス制限を実施するように構成される。
【００２３】
或る実施例では、申し込みサーバ106との初期のSOAP交換の一部として、申し込みサーバ106は、提供される信任の種類を判定し、モバイルデバイス102に提供される信任の種類を示すように構成されてもよい。提供される信任の種類は、１つ又は複数の証明書に基づく信任、ユーザ名／パスワードの信任、又は加入者情報モジュール（SIM）形式の信任を含む。信任の提供は、以下に詳細に説明するようなSOAPで構成されたメッセージの交換を含んでもよい。提供される信任の種類は、オペレータ又はサービスプロバイダにより判定されてもよい。提供する信任の種類及び認証の使用を判定するために、オペレータのポリシーが使用されてもよい。
【００２４】
申し込みの仲裁が必要な場合（すなわち、ユーザの申し込みに問題が存在する場合）、この方法は、モバイルデバイスがWi-Fiホットスポット104に関連付けしてその後の認証要求の後に、申し込みの修正の必要性を示すアクションメッセージを受信することを含む。初期のSOAP交換の間に、モバイルデバイスは、申し込み仲裁サーバ506との申し込みの修正を要求し、SOAP技術に従って情報を交換するように構成される。或る実施例では、申し込み仲裁サーバは、申し込みサーバ106と同じサーバでもよいが、これは要求事項ではない。
【００２５】
実施例によれば、モバイルデバイス102は、登録機関122のURLのような登録機関情報で構成されてもよい。登録機関122は、サービスプロバイダのエントリを含んでもよい。サービスプロバイダのエントリは、サービスプロバイダのFQDN（fully  qualified  domain  name）と、サービスプロバイダのフレンドリー名と、サービスプロバイダのオンラインサインアップのルートトラスト（root  trust）とを含んでもよい。登録機関122は、サービスプロバイダのドメイン名と他のデータとの間の暗号による結び付きを提供してもよい。登録機関122は、モバイルデバイス102と申し込みサーバ106のようなオンラインサインアップサーバとの間の信頼関係を確立するために、モバイルデバイス102により使用されてもよい。モバイルデバイス102がオンラインサインアップを開始すると、オンラインサインアップサーバのメタデータについて登録機関122に問い合わせてもよく、オンラインサインアップのサービスプロバイダの真正性を確認してもよい。モバイルデバイス102はまた、事前に登録情報をダウンロードし、それをローカルに格納してもよく、ここに記載の安全なオンラインサインアップ及び提供プロセスを開始するときに、それを使用してもよい。モバイルデバイス102がデュアルモードのモバイルデバイスである（例えば、セルラネットワーク機能とWi-Fiネットワーク機能との双方を有する）場合、モバイルデバイス102はまた、セルラネットワーク接続を使用してリアルタイムに登録機関122に問い合わせ、オンラインサインアップサーバ情報を取得して真正性を確認するように構成されてもよい。
【００２６】
実施例によれば、モバイルデバイス102は、Wi-FiネットワークのWi-Fiホットスポット104に関連付けし、Wi-Fiホットスポット104を通じて申し込みサーバ106とのTLS（transport-layer  security）セッションを確立し、申し込みサーバ106のデジタル証明書を受信するように構成されてもよい。実施例によれば、モバイルデバイス102は、Wi-Fiネットワークアクセスの申し込みを提供し、申し込み管理オブジェクト（MO）を生成するために、確立された安全なHTTP接続上でアクティベーションポータル108と情報を交換してもよい。申し込みMOは、Hotspot  2.0ネットワークを含む特定のWi-Fiネットワークへの自動接続のために提供された信任の種類（例えば、ユーザ名／パスワード、SIM形式のもの、証明書に基づくもの）への参照を含んでもよい。
【００２７】
ユーザ名／パスワードの信任の場合、申し込みMOは、ユーザ名とパスワードとを含んでもよい。SIM形式の信任の場合、申し込みMOは、SIM形式の信任についての少なくともいくつかの基本情報を含んでもよい。証明書に基づく信任の場合、申し込みMOは、証明書に基づく信任にアクセスするための情報を含んでもよい。これらの実施例については以下に詳細に説明する。
【００２８】
Wi-Fi  Hotspot  2.0ネットワークのための安全なオンラインサインアップ及び提供について多くの実施例が記載されるが、本発明の範囲はこの点に限定されない。他の実施例は、他の無線ローカルエリアネットワーク（WLAN）及びセルラ形式のネットワークを含み、他の種類のネットワークのための安全なオンラインサインアップ及び提供にも適用可能である。
【００２９】
或る実施例によれば、証明機関120は、Hotspot  2.0証明機関（CA：Certificate  Authority）（すなわち、ルートトラスト（Root  Trust））でもよく、Hotspot  2.0証明書を含む証明書を発行するように構成されてもよい。登録機関122は、Hotspot  2.0サービスプロバイダとして登録された会社又は組織でもよい。登録機関122は、既に登録されたFQDN及び／又は選択されたフレンドリー名を含んでもよい。FQDNオーナーは、公衆利用可能な“WHOIS”データベースで識別されてもよい。選択されたフレンドリー名は、既に登録されたフレンドリー名と同様のものではなく、或いは混同されるべきでない。登録機関122は、適切でない場合には要求されたフレンドリー名の拒否を可能にし得る登録のためのルールを呼び出してもよい。登録機関122は、登録されたサービスプロバイダのデータベースを、これらのフレンドリー名と共に維持管理し、無効なエントリーを除去してもよい。証明機関120からのHotspot  2.0証明書は、登録されたエンティティ（すなわち、登録機関のデータベースに登録されたもの）に対してのみ発行されてもよい。証明書は、FQDN登録有効期間を超えない有効期間を有してもよい。或る場合、登録機関122はまた、証明機関として動作してもよい。
【００３０】
実施例によれば、モバイルデバイス102は、証明機関120から１つ以上のHotspot  2.0ルート証明書を取得してもよく、ルート証明書は、サーバのFQDNを識別し、オンラインサインアップ及び信任の提供のためのHTTPSに基づく認証に使用可能であることを示してもよい。Hotspot  2.0サービスプロバイダは、証明機関120からの証明書をオンライン申し込みサーバ106に提供してもよく、オンライン申し込みサーバ106で適切なポリシー設定を提供してもよい。これらの実施例については以下に詳細に説明する。
【００３１】
サービスプロバイダのネットワークはまた、特に加入者データベースを含む認証、許可及びアカウンティング（AAA：authentication,  authorization,  and  accounting）サーバ126を含んでもよい。AAAサーバ126は、IPアドレスの動的な構成のためのDHCP（Dynamic  Host  Configuration  Protocol）サーバ127、ドメイン名変換のためのDNS（Domain  Name  Server）128のようなネットワークエレメントと通信してもよく、他のネットワーキング動作を実行してもよい。
【００３２】
或る実施例では、Wi-Fiホットスポット104は、Wi-Fi  AllianceのHotspot  2.0  evolution  specificationのようなHotspot  2.0  evolutionの仕様に従って動作するWi-Fi  Hotspot  2.0でもよい。モバイルデバイス102は、Hotspot  2.0の動作可能なデバイスでもよく、申し込み情報は、Wi-Fi  Hotspot  2.0への自動接続のための予め提供された申し込み情報を含んでもよい。Wi-Fiネットワークは、WLANのためのIEEE802.11標準（及びこれに対する修正）のうち１つに従って動作するように構成されたWi-Fiホットスポットを含む無線ネットワークでもよい。
【００３３】
Wi-Fiネットワークは、アップストリーム及びダウンストリームの通信が時分割多重処理に従って同じ周波数チャネルを使用するCSMA/CA（carrier-sense  multiple  access  technique  with  collision  avoidance）を使用してもよい。或るWi-FiネットワークはOFDM（orthogonal  frequency  division  multiplexing）を使用してもよい。他方、第４世代（4G）LTEネットワーク及びWiMAXネットワークのようなセルラネットワークはOFDMA（orthogonal-frequency  division  multiple  access）技術を実装してもよい。第３世代（3G）セルラネットワークは、CDMA（code-division  multiple  access）を使用してもよい。或る実施例では、モバイルデバイス102は、Wi-Fiとセルラネットワークとの双方と通信するように構成された物理レイヤ回路を有するデュアルモードのデバイスでもよい。
【００３４】
図２は、或る実施例によるSOAP-XMLを使用した安全なオンラインサインアップ及び信任の提供の概略である。これらの実施例では、サーバ側の認証が、ネットワークコンポーネントを認証するために使用される。その後、Wi-Fiネットワークは、申し込みを確立して信任を生成するためにモバイルデバイス102を申し込みサーバ106にリダイレクトする、或いは申し込みの修正のために申し込み修正サーバにリダイレクトする。
【００３５】
動作202において、モバイルデバイス102は、EAP方法を使用してWi-Fiネットワークに関連付けすることにより、信任提供プロセスを開始する。成功したEAPの交換は、Wi-Fiホットスポット104に配信されるRADUS  ACCESS-ACCEPTメッセージ203になる。RADIUS  ACCESS-ACCEPTメッセージ203は、自分のために実施するWi-Fiホットスポット104のアクセス制限を含んでもよく、アクセス制限を示してもよい。信任提供プロセスの間のアクセス制限の使用は、ネットワークを保護し、ユーザがインターネットアクセスを得ることを回避することに役立ってもよい。或る実施例では、RADIUS認証プロトコルが動作202の一部として実行されてもよい。或る実施例では、RADIUS  ACCESS-ACCEPTメッセージ203は、Wi-Fiホットスポット104に対して、制限された一式のサーバへのモバイルデバイス102のアクセスを制限させる命令を含んでもよい。
【００３６】
動作206において、申し込み修正サーバ106を認証し、少なくともいくつかのデバイス機能情報を申し込みサーバ106に提供し、信任の提供が要求されているか否か又は申し込みの修正が要求されているか否かを申し込みサーバ106に通知するために、初期のSOAP交換がモバイルデバイス102により実行される。申し込みの修正の場合のようにモバイルデバイス102が既に信任を有する場合、申し込みサーバ106は、モバイルデバイスを自動的に認証してもよい。この情報を受信すると、申し込みサーバ106は、ユーザ入力が必要であるか、機械のみで交換するメッセージが必要であるかを判定してもよい。ユーザ入力が必要である場合、申し込みサーバ106は、モバイルデバイス102に対してブラウザを起動するように通知してもよい。機械のみのメッセージが必要である場合、申し込みサーバ106からの応答は、メッセージフローが終了したこと又は更なる機械の交換が必要であることの指示を含んでもよい。これらの実施例では、このフローのメッセージは、
“application/soap+xml”のHTTPコンテンツタイプを伝達してもよい。メッセージは、モバイルデバイス102のSOAP処理アプリケーション（例えば、SOAP処理エレメント125）と申し込みサーバ106のSOAP処理アプリケーション（例えば、SOAP処理エレメント135）との双方に配信されてもよい。
【００３７】
動作212は、ユーザ入力が必要な場合に実行される（例えば、サービスにサインアップするため又は請求書に対して支払いを行うため）。動作212において、モバイルデバイス102はブラウザを起動し、ユーザは、ウェブページを介して情報について促されてもよい。ユーザ交換の終了時に、メッセージフローが完了してもよく、更なるメッセージが要求されてもよい。いずれの場合であっても、申し込みサーバ106は、メッセージ交換が完了したことをモバイルデバイス102に通知してもよく、或いはプロセスの次のステップを特定してもよい。これらの実施例では、このフローのメッセージは、ウェブページに使用されるHTTPコンテンツタイプを伝達する。これは、“text/html”、“application/xml”及び“application/xhtml+xml”のコンテンツタイプを含むが、これらに限定されない。
【００３８】
動作214において、最後のSOAP交換が、信任提供プロセスを完了してもよい。この最後のSOAP交換は、機械対機械の通信を有してもよい（すなわち、ユーザ入力が必要ない）。この最後のSOAP交換は、証明書を提供するときに使用されてもよい。これらの実施例では、このフローのメッセージは、“application/soap+xml”のHTTPコンテンツタイプを伝達する。これらのメッセージは、モバイルデバイス102及び申し込みサーバ106の双方のSOAP処理アプリケーションに配信されてもよい。
【００３９】
動作226において、モバイルデバイス102は、Wi-Fiネットワークから関連付けを解除してもよい。この理由は、信任が提供されていないからでもよい。動作338において、モバイルデバイス102は、次回にWi-Fiネットワークに関連付けして認証してもよい。Wi-Fiホットスポット104は、EPAメッセージをAAAサーバ126に及びAAAサーバ126から中継してもよい。Access-Accept  RADIUSメッセージ230になる成功したEAPメッセージの終了の際に、AAAサーバ126は、適切な場合には、ユーザの申し込みに従って、いずれかのアクセス制限をWi-Fi-ホットスポット104に配信してもよい。これにより、信任の提供又は申し込みの修正のためにインスタンス化されたいずれかのアクセス制限は、除去される。
【００４０】
図３Ａ及び３Ｂは、或る実施例によるSOAP-XML技術を使用した安全なオンラインサインアップ及び証明書に基づく信任の提供のために交換されるメッセージを示している。動作302において、モバイルデバイス102は、Wi-Fiホットスポット104に関連付けしてもよい。或る実施例では、モバイルデバイス102は、最初にHotspot  2.0の動作可能なネットワークをスキャンし、また、Wi-Fiネットワークが安全であるか否か（例えば、RSNが可能であり、Hotspot  2.0接続をサポートしているか否か）を判定するために、Wi-Fiホットスポットのビーコンの指示（指標）を探してもよい。モバイルデバイス102は、ユーザプレファレンスに基づいて最も適切なネットワークを選択してもよい。モバイルデバイス102が選択されたサービスプロバイダとの申し込みを有さないと判定した場合、以下に詳細に説明するように、オンラインサインアップ及び提供に自動的に（すなわち、ユーザの介入なしに）携わるように構成されてもよい。
【００４１】
RSN可能なネットワークでは、モバイルデバイス102は、信任なしにRSN可能なネットワークにアクセスするように構成されてもよい。これらの実施例では、モバイルデバイス102は、GAS（generic  server  access）要求（IEEE802.11uに基づくGAS要求等）を送信し、オンラインサインアップのNAI（Network  Access  Identifier）を要求するように構成されてもよい。オンラインサインアップのNAIは、GASクエリを使用してネットワークから受信されてもよい。NAIを受信した後に、モバイルデバイス102は、サービスにサインアップして提供のための信任を生成する意図があることをネットワークに示すために、EAP（Extensible  Authentication  Protocol）認証処理でNAIを使用してもよい。ネットワークは、ユーザ認証を必要とせずに、この目的でモバイルデバイス102へのアクセスを可能にするように構成されてもよい。次に、モバイルデバイス102は、以下に詳細に説明するようにサーバ側の認証を実行してもよい。
【００４２】
或る実施例では、動作302は、モバイルデバイス及び認証者がEAP認証処理の後に生成されたマスター鍵からセッション鍵を導くことを可能にするために、４ウェイ・ハンドシェイク（4WHS：four-way  handshake）を実行することを含んでもよい。4WHSは、IEEE802.11iに従ってもよいが、これは要求事項ではない。動作302において、モバイルデバイス102は、Wi-Fiホットスポット104を通じて申し込みサーバ106とTLSセッションを確立し、申し込みサーバ106の証明書を受信するように構成されてもよい。証明書は、Hotspot  2.0証明機関により発行されたHotspot  2.0証明書（すなわち、ルートトラスト）でもよく、ルート証明書と呼ばれてもよい。
【００４３】
或る実施例では、モバイルデバイス102は、動作304においてRFC2560の手順に従って申し込みサーバ106とTLSセッションを確立してもよく、HTTPSを使用してサーバ側の認証を実行してもよい。或る実施例では、申し込みサーバ106とTLSセッションを確立した後に、モバイルデバイス102は、申し込みサーバ106の証明書がHotspot  2.0トラストルートにより署名されていることを確認してもよい。申し込みサーバ106の証明書がHotspot  2.0ルートトラストにより署名されていることをモバイルデバイス102が確認した場合又は確認することができる場合、モバイルデバイス102は、新たな申し込みの確立を開始するために、動作306を実行するように構成されてもよい。
【００４４】
ここに開示の実施例は、オープンネットワークと安全な802.1xの種類のネットワークとの双方に適用可能である。この理由は、TLSセッションが証明書の提供のために確立されるからである。従って、以下に説明する同じ処理がオープンWi-Fiネットワーク／安全でないWi-Fiネットワークと安全なWi-Fiネットワーク（例えば、802.1xのセキュリティを有するもの）との双方に使用されてもよい。
【００４５】
或る実施例では、申し込みサーバ106の証明書がHotspot  2.0ルートトラストにより署名されていることを確認するために、モバイルデバイス102は、Hotspot  2.0ルートトラストの公開鍵を使用し、証明書を確認してもよい。公開鍵は、鍵サーバ又はモバイルデバイス102内の記憶エレメントから取得されてもよい。サインアップサーバの証明書がHotspot  2.0ルートトラストにより署名されていることをモバイルデバイス102が確認できない場合、又はサインアップのサーバの証明書がHotspot  2.0ルートトラストにより署名されていない場合、モバイルデバイス102は、オンラインサインアップ及び提供プロセスを中止し、確立されたTLSセッションを解放／終了してもよい。
【００４６】
動作306において、モバイルデバイス102は、SOAP技術に従ってオンラインサインアッププロトコル（osp）のポストデバイスデータ（ospPostDevData）メッセージを申し込みサーバ106に送信してもよい。メッセージは、要求理由（requestReason）の値と、デバイス情報（DevInfo）と、デバイス詳細（DevDetail）とを含んでもよい。或る実施例では、デバイス情報及びデバイス詳細情報は、特許出願第13/188,205に開示されたもののようなOMA-DM  Devlnfo及びOMA-DM  DevDetail  MOでもよい。モバイルデバイス102は、モバイルデバイス102が信任に対して登録を希望することを示す“申し込み登録”に、メッセージの要求理由の値を設定してもよい。
【００４７】
申し込みの修正では、モバイルデバイス102は、モバイルデバイス102が申し込みの修正を実行することを希望することを示す“申し込みの修正”に、メッセージの要求理由の値を設定してもよい。これらの実施例については以下に詳細に説明する（図５参照）。
【００４８】
動作308において、申し込みサーバ106は、提供する信任の種類（すなわち、ユーザ／パスワードの信任又は証明書に基づく信任）を判定するために、DevInfo及びDevDetail  MOで提供された情報を使用してもよい。図３に記載する実施例では、証明書に基づく信任が提供される。動作308において、申し込みサーバ106は、SOAP技術に従ってospPostDevDataResponseメッセージをモバイルデバイス102に送信してもよい。モバイルデバイス102が申し込み登録を要求したため、申し込みサーバ106は、モバイルデバイスがメッセージに与えられたURIに対してブラウザを起動するためのコマンドを返信してもよい。
【００４９】
動作310において、申し込みサーバ106からExecute:LaunchBrowsertoURIを受信すると、モバイルデバイス102は、ブラウザを起動し、動作308で戻されたURIに安全なHTTPS接続を確立し、動作308において戻されたオンラインサーバのURIにHTTPS  GET要求を送信してもよい。
【００５０】
動作312において、モバイルデバイス102及び申し込みサーバ106は、申し込みの生成のためにサービスプロバイダにより要求されたいずれか必要なユーザ情報を交換してもよい。この交換は、ユーザについての情報を提供し、適切な申し込みプランを選択し、いずれかのクレジットカード情報又は支払い情報を提供し、ポリシー及び他のパラメータを確立することを含んでもよい。
【００５１】
動作312における登録データの交換の後に、動作314が実行され、モバイルデバイス102は、申し込みサーバ106からospUserlnputResponse  XMLインスタンスドキュメントを取得してもよい。エラーが発生しない場合、ospUserlnputResponseは、ospStatus及びgetCertificate実行コマンドのコンテナである。ウェブブラウザは、処理のためにXMLインスタンスドキュメントをローカルに登録されたヘルパーアプリケーション（例えば、接続マネージャ）に渡してもよい。XMLインスタンスドキュメントは、証明書登録サーバ110のURIと、証明書の登録に必要な他のメタデータとを含んでもよい。
【００５２】
動作316は、証明書に基づく信任が提供される場合に実行される。動作316の証明書登録手順は、サービスプロバイダとの認証のための申し込み証明書をモバイルデバイス102に提供するために、証明書登録プロトコル（例えば、CMP（certificate-management  protocol）又はSCEP（simple  certificate  enrollment  protocol））に従って実行されてもよい。或る実施例では、証明書登録プロセスは、典型的な条件で60秒未満を要するように構成されてもよい。典型的な条件は、Wi-Fiホットスポット012及びサービスプロバイダのコアネットワークが混雑しておらず、証明書登録サーバ110が過負荷でない場合を含んでもよい。成功した手順の後に、モバイルデバイス102は、サービスプロバイダのWi-Fiネットワークとの認証に使用される申し込み証明書を提供される。成功しない場合、モバイルデバイス102は、証明書の登録の失敗を通知される。
【００５３】
動作316で受信した申し込み証明書は、ネットワークとのEAP-TLSに基づく認証に使用されるのに適したX.509タイプの証明書でもよい。或る実施例では、申し込み証明書は、X.509v3の証明書でもよく、シングルサインオン（SSO：single  sign-on）のための公開鍵インフラストラクチャ（PKI：public  key  infrastructure）及び権限管理インフラストラクチャ（PMI：Privilege  Management  Infrastructure）についてのITU-T標準に従って構成されてもよい。
【００５４】
動作318において、モバイルデバイス102は、RFC2560の手順に従って申し込みサーバ106へのTLS接続を開始して再ネゴシエーションしてもよい。証明書の登録が成功した場合、モバイルデバイス102は、TLS認証を実行するときに提供された証明書を使用するように構成されてもよい。証明書の登録が失敗した場合（例えば、モバイルデバイス102が証明書を受信しなかった場合）、モバイルデバイス102は、TLS認証を実行するときにサーバ側のみの認証を実行してもよい。TLS認証が失敗した場合、モバイルデバイス102は、証明書提供プロセスを中止するように構成されてもよい。
【００５５】
動作320において、モバイルデバイスは、SOAP技術に従ってospPostDevDataメッセージを申し込みサーバ106に送信してもよい。メッセージは、デバイス詳細及びデバイス情報のMOを含んでもよい。モバイルデバイス102は、このメッセージの要求理由の値を、証明書の登録が成功した場合には“証明書登録完了（Certificate  enrollment  completed）”に設定してもよく、証明書の登録が失敗した場合には“証明書登録失敗（Certificate  enrollment  failed）”に設定してもよい。
【００５６】
動作322において、証明書の登録が成功した場合、申し込みサーバ106は、SOAP技術に従ってospPostDevDataResponseメッセージをモバイルデバイス102に送信する。このメッセージは、追加MO（addMO）コマンド及び申し込みMOを含んでもよい。申し込みMOは、提供された証明書を申し込みに結び付ける証明書識別子と、補助の提供データとを含んでもよい。ospPostDevDataResponseメッセージには、申し込み及び証明書の提供プロセスが完了したことを示すために、状態（すなわち、ospStatus）の値が“提供完了（provisioning  complete）”に設定されてもよい。
【００５７】
動作324において、モバイルデバイス102は、動作304において確立されたTLSセッションを解放してもよい。動作326において、モバイルデバイス102は、Wi-Fiネットワークから関連付け解除してもよい。
【００５８】
動作328において、申し込みが動作316で成功して確立された場合、モバイルデバイス102は、新たに取得された信任（すなわち、動作322で提供された信任）を使用してWi-Fiホットスポット104に（すなわち、同じサービスセット識別子（SSID：service-set  identifier）又は同じHESSIDを用いて）再び関連付けしてもよい。
【００５９】
図４は、或る実施例によるSOAP-XML技術を使用した安全なオンラインサインアップ及びユーザ名／パスワード形式の信任の提供のために交換されるメッセージを示している。
【００６０】
動作402、404、406及び408は、動作408においてユーザ／パスワードの信任が提供されることを判定するために申し込みサーバ106がDevInfo及びDevDetailのMOで提供された情報を使用してもよい点を除き、動作302、304、306及び308と同様である。動作410及び412は、動作310及び312と同様である。
【００６１】
動作422において、モバイルデバイス102は、申し込みサーバ106からospUserlnputResponse  XMLインスタンスドキュメントを取得してもよく、申し込みサーバ106は、SOAP技術に従ってモバイルデバイス102にospPostDevDataResponseメッセージを送信してもよい。このメッセージは、追加MO（addMO）コマンド及び申し込みMOを含んでもよい。
【００６２】
動作424において、モバイルデバイス102は、動作404において確立されたTLSセッションを解放してもよい。動作426において、モバイルデバイス102は、Wi-Fiネットワークから関連付け解除してもよい。
【００６３】
動作428において、申し込みがステップ7で成功して確立された場合、モバイルデバイス102は、新たに取得された信任（すなわち、動作422で提供された信任）を使用してWi-Fiホットスポット104に（すなわち、同じサービスセット識別子（SSID）又は同じHESSIDを用いて）再び関連付けしてもよい。
【００６４】
図５は、或る実施例によるSOAP-XML技術を使用した申し込みの修正のために交換されるメッセージを示している。ときどき、ユーザの申し込み又はアカウントが修正される必要があることがある。サービスプロバイダは、これが必要な場合を判定する。この例は、パスワードの失効と、アカウントの滞納した支払いとを含む。申し込みの修正の必要性は、AAAサーバ126のようなサービスプロバイダのAAAサーバの加入者の申し込みデータベースのエントリに格納されてもよい。Wi-Fiネットワークでの加入者からの認証要求に続いて、修正の必要性はモバイルデバイス102に伝達されてもよい。モバイルデバイス102は、以下に説明するように、申し込み修正サーバと申し込み修正メッセージの交換に携わってもよい。
【００６５】
動作502において、モバイルデバイス502は、Wi-Fiホットスポット104と関連付けし、動作202（図２）のものと同様に、EAP方法を含む認証プロセスを実行する。申し込みの修正が必要であることをサービスプロバイダが判定した場合、動作503において、AAAサーバ126は、EAP認証シーケンスの最後に認証者へのURLリダイレクトを備えたRADIUS  ACCESS-ACCEPTメッセージを送信するように構成される。RADIUS  ACCESS-ACCEPTメッセージは、申し込みの修正の目的でモバイルデバイス102へのアクセスを制限するアクセス制限を含んでもよい。URLリダイレクトは、申し込み修正サーバ506のURLを示してもよい。
【００６６】
動作513において、認証者は、Wi-Fiホットスポット104（モバイルデバイスが認証されたもの）に対して、申し込みの修正の必要性を示すアクションフレームをモバイルデバイス102に送信させる。アクションフレームは、ベンダ特有（VS：vendor  specific）のアクションフレームでもよい。他の実施例では、モバイルデバイス102は、限られた接続が存在すること（例えば、アクセス制限のため）を判定するため及び申し込みの修正が必要であることをを判定するための技術（すなわち、アクションフレームの受信以外）を使用してもよい。
【００６７】
動作518において、モバイルデバイス102は、動作304（図４）と同様に、申し込み修正サーバ506とTLS接続を確立してもよい。モバイルデバイス102は、申し込み修正サーバ506の証明書が無効にされていないことを確認するように構成されてもよい。或る実施例では、モバイルデバイス102は、証明書の状態を判定するために、TLS接続内でOCSP（Online  Certificate  Status  Protocol）を使用してもよい。証明書が無効にされている場合、モバイルデバイス102は、申し込み修正プロセスを中止してもよい。モバイルデバイス102が申し込み修正サーバ506へのTLS接続を開始することができない場合にも、申し込み修正プロセスを中止するように構成されてもよい。モバイルデバイス102は、HTTPを使用して（すなわち、HTTPSのセキュリティなしに）申し込みの修正を実行する試みを回避するように構成されてもよい。
【００６８】
動作520において、モバイルデバイス102は、動作306と同様に、SOAP技術に従ってospPostDevDataメッセージを申し込み修正サーバ506に送信するように構成されてもよい。メッセージは、OMA-DM（Open  Mobile  Alliance  Device-Management）プロトコルのDevlnfo、DevDetail及びSubscriptionのMOを含むように構成されてもよく、requestReasonの値は、“申し込みの修正（Subscription  remediation）”に設定されてもよい。申し込み修正サーバ506は、ダイジェスト（digest）方法を使用してHTTP認証を要求してもよく、モバイルデバイス102は、ユーザ名及びパスワードのダイジェストをサーバに提供してもよい。HTTP認証が成功しない場合、申し込みの修正は可能ではなく、モバイルデバイス102は、プロセスを中止するように構成されてもよく、それに従ってユーザに通知してもよい。
【００６９】
動作522において、申し込み修正サーバ506は、SOAP技術に従ってospPostDevDataResponseメッセージをモバイルデバイス102に送信してもよい。メッセージは、申し込みMO（以下に詳細に説明する）の１つ以上の内部ノードについてのXMLデータを含んでもよい。モバイルデバイス102は、申し込みMOの１つ以上の内部ノードを、メッセージで受信した更新された信任で置換するように構成されてもよい。ospPostDevDataResponseメッセージのospStatusは、申し込み修正プロセスが完了したことを示す“修正完了（Remediation  complete）”に設定されてもよい。
【００７０】
動作524において、モバイルデバイス102は、動作518において確立されたTLSを解放してもよく、動作526においてWi-Fiネットワークと関連付け解除してもよい。動作528において、モバイルデバイス102は、申し込み修正プロセスの間に更新された信任を使用して関連付けしてもよい。
【００７１】
ここに記載の実施例は、機械の修正及びユーザの修正に適用可能である。機械の修正は、申し込みがユーザの介入なしに修正可能である問題を示す。ユーザの修正は、修正するためにユーザの介入を必要とし得る申し込みに関する問題を示す。
【００７２】
図６は、或る実施例による管理オブジェクトツリーを示している。管理オブジェクトツリー600は、モバイルデバイス102に格納されてもよく、ツリールート601と、サービスプロバイダ（SP：service  provider）毎の申し込みMO（subscription  MO）602と、サービスプロバイダ毎のFQDN608とを含んでもよい。管理オブジェクトツリー600はまた、デバイス情報MO606（DevInfo）と、デバイス詳細MO604（DevDetail）とを含んでもよい。管理オブジェクトツリー600はまた、デバイス特有のWi-FiオブジェクトのためのWi-Fi  MO610を含んでもよい。
【００７３】
或る実施例では、デバイス詳細MO604は、モデル、ベンダ情報、アダプタの種類、アダプタ構成等のようなデバイス情報と、ユーザ情報とを含んでもよい。デバイス詳細MO604は、デバイスに特有の更なる情報が取得され得るURI、デバイスの種類（例えば、PCカード、USB、モデム、エクスプレスカード、ゲームデバイス、音楽プレイヤ、ナビゲーションデバイス）、OEM名、ファームウェアバージョン、ソフトウェアバージョン、ハードウェアバージョン、及びホストデバイスが大きいオブジェクトの処理をサポートするか否かのような更なる情報を含んでもよい。デバイス情報MO606は、ホストデバイスの固有の識別子（例えば、GUID）、製造者識別子、デバイスのモデル、SOAPクライアントのバージョン識別子、及びホストデバイスの言語設定を含んでもよい。
【００７４】
図７は、或る実施例によるモバイルデバイスを示している。モバイルデバイス700は、モバイルデバイス102として使用するのに適しており、安全なオンラインサインアップ及び信任の提供並びに申し込みの修正について前述した様々な動作を実行するように構成されてもよい。
【００７５】
モバイルデバイス700は、１つ以上のアンテナ701を使用してWi-Fiホットスポット104（図１）のようなWi-Fiホットスポットと無線通信するように構成された物理レイヤ回路702を含んでもよい。モバイルデバイス700はまた、特に提供された信任及び申し込みMO602（図６）並びに管理オブジェクトツリー600（図６）の他のエレメントを格納するメモリ706と共に、ここに記載の動作を実行するように構成され得る処理回路704を含んでもよい。処理回路704は、ここに記載の様々なSOAP技術を実行するSOAP処理エレメント125を含んでもよい。モバイルデバイス700はまた、他の動作を実行する媒体アクセス制御のための媒体アクセス制御（MAC：media-access  control）レイヤ回路のような他の機能エレメントを含んでもよい。
【００７６】
シングルモードのモバイルデバイスの場合、物理レイヤ回路702は、Wi-Fiネットワークと通信するように構成されてもよい。デュアルモードの実施例では、物理レイヤ回路702は、セルラネットワークとWi-Fiネットワークとの双方と通信するように構成されてもよい。デュアルモードの実施例では、モバイルデバイス700は、Wi-Fi送受信機と、１つ以上のセルラネットワーク送受信機との双方を含んでもよい。デュアルモードの実施例では、モバイルデバイス700はまた、セルラネットワークからのトラヒックを利用可能なWi-Fiネットワークに負荷軽減するように構成されてもよい。
【００７７】
或る実施例では、モバイルデバイス700は、パーソナルデジタルアシスタント（PDA：personal  digital  assistant）、無線通信機能を備えたラップトップ若しくはポータブルコンピュータ、ウェブタブレット、無線電話、スマートフォン、無線ヘッドセット、ページャ、インスタントメッセージングデバイス、デジタルカメラ、アクセスポイント、テレビ、医療若しくは健康デバイス、エンターテイメントデバイス、又は情報を無線で送信及び／又は受信し得る他のデバイスのようなポータブル無線通信デバイスでもよい。
【００７８】
アンテナ701は、例えば、ダイポールアンテナ、モノポールアンテナ、パッチアンテナ、ループアンテナ、マイクロストリップアンテナ、又はRF信号の送信に適した他の種類のアンテナを含み、１つ以上の指向性又は無指向性アンテナを含んでもよい。或る実施例では、２つ以上のアンテナの代わりに、複数の開口を有する単一のアンテナが使用されてもよい。これらの実施例では、それぞれの開口が別々のアンテナと考えられてもよい。或るMIMO（multiple-input  multiple-output）の実施例では、アンテナ701は、それぞれのアンテナ701と送信局のアンテナとの間に生じ得る空間ダイバーシチ及び異なるチャネル特性を利用するように、効果的に分離されてもよい。
【００７９】
モバイルデバイス700は複数の機能エレメントを有するものとして示されているが、１つ以上の機能エレメントは結合されてもよく、デジタルシグナルプロセッサ（DSP：digital  signal  processor）を含む処理エレメントのようなソフトウェア構成されたエレメント及び／又は他のハードウェアエレメントとの組み合わせにより実装されてもよい。例えば、或るエレメントは、１つ以上のマイクロプロセッサ、DSP、特定用途向け集積回路（ASIC：application  specific  integrated  circuit）、無線周波数集積回路（RFIC：radio-frequency  integrated  circuit）、並びにここに記載の機能を少なくとも実行する様々なハードウェア及び論理回路の組み合わせを有してもよい。或る実施例では、モバイルデバイス700の機能エレメントは、１つ以上の処理エレメントで動作する１つ以上のプロセスを示してもよい。
【００８０】
実施例は、ハードウェア、ファームウェア及びソフトウェアのうち１つ又は組み合わせで実装されてもよい。実施例はまた、コンピュータ可読記憶デバイスに格納された命令として実装されてもよい。この命令は、少なくとも１つのプロセッサにより読み取られて実行され、ここに記載の動作を実行してもよい。コンピュータ可読記憶デバイスは、機械（例えば、コンピュータ）により読み取り可能な形式で情報を格納するためのいずれかの過渡的でない機構を含んでもよい。例えば、コンピュータ可読記憶デバイスは、読み取り専用メモリ（ROM）、ランダムアクセスメモリ（RAM）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス並びに他の記憶デバイス及び媒体を含んでもよい。或る実施例では、１つ以上のプロセッサは、ここに記載の様々な動作を実装するために、コンピュータ可読記憶デバイスに格納された命令により構成されてもよい。
【００８１】
要約は、読者が技術的開示の本質及び要旨を把握することを可能にするという要約を要求する37  C.F.R.  Section  1.72(b)に従うように提供されている。これは、特許請求の範囲又は意味を限定又は解釈するために使用されないという理解で提示されている。以下の特許請求の範囲は、各請求項が別々の実施例として自立するように、詳細な説明に組み込まれる。
【図１】
0005934364.tif 000002
【図２】
0005934364.tif 000003
【図３Ａ】
0005934364.tif 000004
【図３Ｂ】
0005934364.tif 000005
【図４】
0005934364.tif 000006
【図５】
0005934364.tif 000007
【図６】
0005934364.tif 000008
【図７】
0005934364.tif 000009