WiFiHotspot20ネットワークについての安全なオンラインサインアップ及び提供のためにモバイルデバイスにより実行される方法であって、EAPExtensibleAuthenticationProtocol技術を使用してWiFiホットスポットを通じてWiFiネットワークと関連付けするステップであり、前記関連付けの一部として、前記モバイルデバイスが前記WiFiネットワークにアクセスして前記モバイルデバイスとのWiFi接続を確立することを可能にするために、RADIUSACCESSACCEPTメッセージがAAAサーバから前記WiFiホットスポットにより受信されるステップと、前記確立されたWiFi接続上で申し込みサーバと初期のSOAPSimpleObjectAccessProtocol交換を実行し、信任の提供又は申し込みの修正を要求するステップであり、前記初期のSOAP交換は、前記モバイルデバイスが前記申し込みサーバを認証することを含むステップと、WiFiネットワークアクセスのサービスプロバイダと申し込みを確立し、前記申し込みの信任を提供し、前記提供された信任の申し込み管理オブジェクトMOを生成するために、前記申し込みサーバと情報を交換するステップと、前記申し込みMOを受信するために、前記WiFiネットワーク上で前記申し込みサーバと最後のSOAP交換を実行するステップとを有する方法。前記初期のSOAP交換は、前記モバイルデバイスの少なくともいくつかのデバイス機能情報を提供するステップと、信任の提供又は申し込みの修正のうち1つを有する要求の理由を示すステップと、前記要求の理由が信任の提供である場合、前記申し込みサーバにより、前記申し込みサーバにより提供される信任の種類を示すステップとを更に含む、請求項1に記載の方法。前記初期及び最後のSOAP交換は、トランスポート用のアプリケーションレイヤプロトコルとしてHTTPSsecureHypertextTransferProtocolを使用してSOAP技術に従って構成されたメッセージを有し、前記メッセージは、XMLextensiblemarkuplanguageメッセージフォーマットに従って構成される、請求項1に記載の方法。前記初期のSOAP交換は、前記モバイルデバイスにより、前記SOAP技術に従ってオンラインサインアッププロトコルospのポストデバイスデータospPostDevDataメッセージを前記申し込みサーバに送信するステップであり、前記メッセージは、要求理由requestReasonの値と、デバイス情報DevInfoと、デバイス詳細DevDetailとを含み、前記モバイルデバイスは、前記メッセージの前記要求理由の値を、申し込みの登録又は申し込みの修正に設定するように構成されるステップと、前記申し込みサーバから前記SOAP技術に従ってospPostDevDataResponseメッセージを受信するステップであり、応答メッセージは、ExecuteLaunchBrowsertoURIコマンドを含むステップとを有し、前記モバイルデバイスは、ブラウザを起動し、前記応答メッセージで受信したオンラインサーバのURIに安全なHTTPS接続を確立し、前記オンラインサーバのURIにHTTPSGET要求を送信するように構成される、請求項3に記載の方法。前記RADIUSACCESSACCEPTメッセージは、前記WiFiアクセスポイントにより実施されるアクセス制限を含み、前記アクセス制限は、信任の提供又は申し込みの修正のために前記WiFiネットワークへの前記モバイルデバイスのアクセスを制限する、請求項1に記載の方法。前記WiFiホットスポットは、前記モバイルデバイスを、前記初期及び最後のSOAP交換の実行並びに信任の提供又は申し込みの修正のための前記サービスプロバイダとの情報の交換に制限することにより、前記アクセス制限を実施するように構成される、請求項5に記載の方法。前記申し込みMOを受信した後に、前記方法は、前記最後のSOAP交換の後に前記WiFiホットスポットと関連付け解除するステップと、前記WiFiホットスポットと再関連付けし、WiFi接続を再確立するステップとを含み、前記再関連付けは、EAP技術を使用し、前記再確立されたWiFi接続上で前記提供された信任を前記AAAサーバに提供するステップを含み、前記申し込みに従って前記WiFiネットワークへの前記モバイルデバイスのアクセスを許可するために、第2のRADIUSACCESSACCEPTメッセージが、前記AAAサーバから前記WiFiホットスポットで受信される、請求項1に記載の方法。前記WiFiホットスポットは、前記申し込みに関連する前記第2のRADIUSACCESSACCEPTメッセージに示されたアクセス制限を実施するように構成される、請求項7に記載の方法。前記申し込みサーバとの前記初期のSOAP交換の一部として、前記申し込みサーバは、提供される信任の種類を判定し、提供される前記信任の種類を前記モバイルデバイスに示すように構成され、提供される前記信任の種類は、1つ又は複数の証明書に基づく信任、ユーザ名/パスワードの信任、又は加入者情報モジュールSIM形式の信任を含む、請求項1に記載の方法。申し込みの仲裁が必要な場合、前記方法は、前記モバイルデバイスが、前記WiFiホットスポットに関連付けした後に、申し込みの修正の必要性を示すアクションメッセージを受信するステップを含み、前記初期のSOAP交換の間に、前記モバイルデバイスは、申し込み仲裁サーバでの申し込みの修正を要求し、SOAP技術に従って情報を交換するように構成される、請求項1に記載の方法。WiFiHotspot20ネットワークについての安全なオンラインサインアップ及び提供のために構成されたモバイルデバイスであって、EAPExtensibleAuthenticationProtocol技術を使用してWiFiホットスポットを通じてWiFiネットワークと関連付けし、ただし、前記関連付けの一部として、前記モバイルデバイスが前記WiFiネットワークにアクセスして前記モバイルデバイスとのWiFi接続を確立することを可能にするために、許可メッセージがAAAサーバから前記WiFiホットスポットにより受信され、前記確立されたWiFi接続上で申し込みサーバと初期のSOAPSimpleObjectAccessProtocol交換を実行し、信任の提供又は申し込みの修正を要求し、ただし、前記初期のSOAP交換は、前記モバイルデバイスが前記申し込みサーバを認証することを含み、WiFiネットワークアクセスのサービスプロバイダと申し込みを確立し、前記申し込みの信任を提供し、前記提供された信任の申し込み管理オブジェクトMOを生成するために、前記申し込みサーバと情報を交換し、前記申し込みMOを受信するために、前記WiFiネットワーク上で前記申し込みサーバと最後のSOAP交換を実行するように構成されたモバイルデバイス。前記初期のSOAP交換の一部として、前記モバイルデバイスは、前記モバイルデバイスの少なくともいくつかのデバイス機能情報を提供し、信任の提供又は申し込みの修正のうち1つを有する要求の理由を示し、前記要求の理由が信任の提供である場合、前記申し込みサーバにより、前記申し込みサーバにより提供される信任の種類を示すように更に構成される、請求項11に記載のモバイルデバイス。前記初期及び最後のSOAP交換は、トランスポート用のアプリケーションレイヤプロトコルとしてHTTPSsecureHypertextTransferProtocolを使用してSOAP技術に従って構成されたメッセージを有し、前記メッセージは、XMLextensiblemarkuplanguageメッセージフォーマットに従って構成される、請求項12に記載のモバイルデバイス。前記許可メッセージは、前記WiFiアクセスポイントにより実施されるアクセス制限を含むRADIUSACCESSACCEPTメッセージであり、前記アクセス制限は、信任の提供又は申し込みの修正のために前記WiFiネットワークへの前記モバイルデバイスのアクセスを制限する、請求項13に記載のモバイルデバイス。前記WiFiホットスポットは、前記モバイルデバイスを、前記初期及び最後のSOAP交換の実行並びに信任の提供又は申し込みの修正のための前記サービスプロバイダとの情報の交換に制限することにより、前記アクセス制限を実施するように構成される、請求項14に記載のモバイルデバイス。モバイルデバイスのためにWiFiHotspot20ネットワークについての安全なオンラインサインアップ及び提供を提供するための申し込みサーバにより実行される方法であって、前記モバイルデバイスがWiFiネットワークにアクセスして前記モバイルデバイスとのWiFi接続を確立することを可能にするために、AAAサーバからWiFiホットスポットに許可メッセージを送信するステップと、信任の提供又は申し込みの修正を実行するために、前記モバイルデバイスと初期のSOAPSimpleObjectAccessProtocol交換を実行するステップであり、前記初期のSOAP交換は、前記モバイルデバイスが前記申し込みサーバを認証することを含むステップと、前記モバイルデバイスが前記申し込みMOを受信することを可能にするために、前記WiFiネットワーク上で前記モバイルデバイスと最後のSOAP交換を実行するステップとを有する方法。WiFiネットワークアクセスのサービスプロバイダと申し込みを確立し、前記申し込みの信任を提供し、前記提供された信任の申し込み管理オブジェクトMOを生成するために、前記モバイルデバイスと情報を交換するステップを更に有する、請求項16に記載の方法。前記許可メッセージは、前記WiFiアクセスポイントにより実施されるアクセス制限を含むRADIUSACCESSACCEPTメッセージであり、前記アクセス制限は、信任の提供又は申し込みの修正のために前記WiFiネットワークへの前記モバイルデバイスのアクセスを制限し、前記許可メッセージは、EAPExtensibleAuthenticationProtocol技術を使用して、前記モバイルデバイスが前記WiFiホットスポットと関連付けしたことに応じて送信される、請求項17に記載の方法。前記申し込みサーバとの前記初期のSOAP交換の一部として、前記方法は、提供される信任の種類を判定し、提供される前記信任の種類を前記モバイルデバイスに示すステップを含み、提供される前記信任の種類は、1つ又は複数の証明書に基づく信任、ユーザ名/パスワードの信任、又は加入者情報モジュールSIM形式の信任を含む、請求項18に記載の方法。WiFiネットワークアクセスのサービスプロバイダとの申し込み契約subscriptionの確立に関する1つの問題は、簡単且つユーザフレンドリーなプロセスではない点にある。WiFi動作可能なデバイス及びネットワークのための安全なオンラインサインアップ及び信任の提供のための標準化されたプロセスは存在しない。一般的に、ユーザは、異なる種類のウェブページに直面し、異なる位置に情報を登録してユーザ名/パスワードを選択する必要があることがある。申し込みの確立に関する他の問題は、セキュリティである。安全なネットワーク8021xの動作可能なもの等は未登録者に対するアクセスを禁止し得るが、オープンネットワークは十分なセキュリティを提供しないことがある。現在のオンラインサインアップ機構は、ユーザを、例えば、周知のハニーポットhoneypot又は双子の悪魔twinevilのセキュリティホールを通じてクレジットカード及び個人情報が盗まれることのような許容できないセキュリティ上のリスクにさらしている。申し込みの確立に関する他の問題は、提供される必要がある可能性がある異なる種類の信任である。いくつかのデバイス又はネットワークは、証明書certificateに基づく信任を必要とすることがあり、いくつかの他のデバイス又はネットワークは、ユーザ名/パスワードの信任を使用することがある。他のデバイス又はネットワークは、加入者情報モジュールSIM:subscriberinformationmodule形式の信任を使用することがある例えば、一般的にいくつかのセルラネットワークで使用される。従って、オンラインサインアップ及び信任の提供について一般的なニーズが存在する。また、トランスポートとしてSOAPXML技術を使用するオンラインサインシステムを安全に使用した安全なオンラインサインアップ及び信任の提供について一般的なニーズも存在する。また、ユーザ名/パスワードの信任、SIM形式の信任及び証明書に基づく信任のような異なる種類の信任を提供するのに適した、安全なオンラインサインアップのための標準化されたプロセスの一般的なニーズも存在する。また、オープンネットワーク及び安全なネットワークの双方を含み、いずれかの80211に基づくネットワークで使用するのに適した安全なオンラインサインアップ及び信任の提供のための標準化されたプロセスの一般的なニーズも存在する。以下の説明及び図面は、当業者が特定の実施例を実行可能にする程度に十分に特定の実施例を示している。他の実施例は、構造上、論理上、電気的、プロセス上及び他の変更を取り入れてもよい。或る実施例の部分及び機能は、他の実施例のものに含まれてもよく、置換されてもよい。請求項に示す実施例は、これらの請求項の全ての利用可能な等価物を含む。本発明の実施例は、SOAPXML技術を使用してユーザがWiFiサービスプロバイダと申し込みを確立し、信任及びポリシーコンポーネントをクライアントデバイスに安全にダウンロードできるように、WiFiホットスポットサービスのための安全なオンラインサインアップ及び信任の提供を提供する。これにより、オペレータ例えば、WiFiサービスプロバイダは、標準化されたツールを使用してかなり低いコストでオンラインサインアップ機構を開発することが可能になる。実施例は、従来のWiFiネットワークと進展したHotspot20ネットワークとの双方に適用可能である。本発明の実施例はまた、SOAPXML技術を使用してWiFiホットスポットサービスの信任を更新する申し込みの修正も提供する。図1は、或る実施例による安全なオンラインサインアップ及び信任の提供のためのネットワークエレメントの動作環境を示している。モバイルデバイス102は、WiFiホットスポット104に関連付け、安全なオンラインサインアップ及び提供のためにここに記載される様々な動作を実行するように構成されたWiFi動作可能なデバイスでもよい。WiFiホットスポット104は、インターネットサービスプロバイダへのリンクに接続されたルータで、無線ローカルエリアネットワークWLAN:wirelesslocalareanetwork上でインターネットアクセスを提供してもよい。WiFiホットスポット104は、WiFiネットワークの一部でもよく、インターネットのようなネットワーク105に結合されてもよく、特に、証明機関120、申し込みサーバ106、アクティベーションポータルactivationportal108、証明書登録サーバ110及び登録機関122を含み、ゲートウェイを通じて他の様々なネットワークエレメントに接続されてもよい。或る実施例では、申し込みサーバ106は、SOAPXML技術に従ってメッセージを交換するように構成されたサーバでもよい。WiFiホットスポット104は、WiFiアクセスポイントAP:accesspointとして動作してもよい。モバイルデバイス102は、SOAPXML技術を実装し、ここに記載の様々な動作を実行するように構成されたSOAP処理エレメント125を含んでもよい。同様に、申し込みサーバ106は、以下に詳細に説明するようにSOAPXML技術を実装するように構成されたSOAP処理エレメント135を含んでもよい。或る実施例では、WiFiホットスポット104は、WiFiホットスポット104の管理エンティティとして機能するアクセスコントローラAC:accesscontroller124を含んでもよい。アクセスコントローラ124は、WiFiネットワークの複数のアクセスポイントを管理してもよく、インターネットのような他のネットワークへのアクセスを提供するためのWLANアクセスネットワークのゲートウェイとして動作してもよい。アクセスコントローラ124は、WiFiネットワークへのモバイルデバイスのアクセスを可能にするために、ここに記載の様々な動作を実行してもよい。実施例によれば、モバイルデバイス102は、WiFiホットスポットのための安全なオンラインサインアップ及び信任の提供のために構成されてもよい。或る実施例では、モバイルデバイス102は、SOAPXML技術を使用したWiFiホットスポットのための安全なオンラインサインアップ及び提供のために構成されてもよい。これらの実施例では、モバイルデバイス102及び申し込みサーバ106は、SOAPSimpleObjectAccessProtocolに従って構成された要求及び応答メッセージを交換してもよい。或る実施例では、ここに記載の安全なオンラインサインアップ及び提供プロセスにより、ユーザは、トランスポートとしてSOAPXML技術を使用して、安全にサービスプロバイダと申し込みを確立し、モバイルデバイス102のようなクライアントデバイスへの信任及びオペレータのポリシーをダウンロードすることが可能になる。このことにより、バックエンドのコアネットワークでSOAPXML技術を既に実装し得るセルラ形式のネットワークサービスプロバイダは、同じサーバ及びインストールされたコンポーネントを使用し、WiFiネットワークにサービス提供するためのその機能を拡張することが可能になり得る。或る実施例は、ユーザ名/パスワードの信任、証明書に基づく信任及びSIM形式の信任を含む、安全なオンラインサインアップ及び信任の提供のための標準化されたプロセスを提供する。安全なオンラインサインアップ及び信任の提供のための標準化されたプロセスは、ほとんど如何なるIEEE80211に基づくネットワークに適用可能になり、そのプロセスをオープンネットワークと安全なネットワークとの双方に適用可能にし得る。例えば、安全なWiFiネットワークは、RSNrobustsecuritynetworkプロトコルに従ってセキュリティを実装してもよい。このようなネットワークは、RSNネットワークすなわち、RSNArobustsecuritynetworkassociationの生成を可能にするセキュリティネットワークと考えられてもよい。従って、ユーザは、もはや異なる種類のウェブページに直面し、異なる位置に情報を登録してユーザ名/パスワードを選択する必要がなくなる。WiFiネットワークは、現在では使用が容易であり、安全になっている。SOAPXML技術の使用は、WiFネットワークの動作が現在及び将来のセルラ形式のネットワークと容易に統合されることを可能にする。或る実施例では、安全なオンラインサインアップ及び信任の提供は、ユーザの相互作用なしに自動的に実行されてもよい。実施例によれば、モバイルデバイス102は、WiFiHotspot20ネットワークについて安全なオンラインサインアップ及び提供のために構成されてもよい。これらの実施例では、モバイルデバイス102は、EAPExtensibleAuthenticationProtocol技術を使用してWiFiホットスポット104を通じてWiFiネットワークと認証するように構成されてもよい。認証の一部として、RADIUSACCESSACCEPTメッセージがAAAサーバ126からWiFiホットスポット104により受信され、モバイルデバイス102がWiFiネットワークにアクセスし、モバイルデバイス102とのWiFi接続を確立することを可能にする。モバイルデバイス102は、確立されたWiFi接続上で申し込みサーバ106と初期のSOAP交換を実行し、信任の提供又は申し込みの修正を要求してもよい。初期のSOAP交換は、モバイルデバイスが申し込みサーバ106を認証することを含む。モバイルデバイスはまた、WiFiネットワークアクセスのサービスプロバイダと申し込みを確立し、申し込みのための信任を提供し、提供された信任のための申し込み管理オブジェクトMO:managementobjectを生成するために、申し込みサーバ106と情報を交換してもよい。モバイルデバイスはまた、申し込みMOを受信するために、WiFiネットワーク上で申し込みサーバ106と最後のSOAP交換を実行してもよい。これらの実施例では、RADIUSACCESSACCEPTの受信に応じて、WiFiホットスポット104は、認証の成功を示すEAPSuccessメッセージをモバイルデバイス102に送信するように構成される。或る実施例では、WiFiホットスポット104との関連付けアソシエーション、初期及び最後のSOAP交換及び申し込みサーバ106の認証は、ユーザ入力なしにすなわち、自動的に実行されてもよい。或る実施例では、申し込みの確立のための申し込みサーバ106との情報の交換もまた、必要な情報に応じてユーザ入力なしに実行されてもよい。或る実施例では、この方法は、ユーザ入力のためにユーザに促し、ユーザ入力を申し込みサーバ106に提供することを含んでもよい。或る実施例では、初期のSOAP交換は、モバイルデバイス102の少なくともいくつかのデバイス機能情報を提供し、要求の理由例えば、信任の提供又は申し込みの修正を示すことを含んでもよい。要求の理由が信任の提供である場合、申し込みサーバ106は、提供される申し込みの種類を示してもよい。或る実施例では、初期及び最後のSOAP交換は、トランスポート用のアプリケーションレイヤプロトコルとして安全なハイパーテキスト転送プロトコルHTTPSを使用してSOAP技術に従って構成されたメッセージを有する。メッセージは、XMLextensiblemarkuplanguageメッセージフォーマットに従って構成されてもよい。HTTPSは、安全な暗号化された通信を提供するために、HTTPとSSLTLSプロトコルとの組み合わせを含んでもよい。或る実施例では、RADIUSACCESSACCEPTメッセージは、WiFiホットスポット104により実施されるアクセス制限を含んでもよい。アクセス制限は、信任の提供又は申し込みの修正のためのWiFiネットワークへのモバイルデバイス102のアクセスを制限する。WiFiホットスポット104は、初期及び最後のSOAP交換の実行と、信任の提供又は申し込みの修正のためのサービスプロバイダとの情報の交換とにモバイルデバイス102を制限することにより、アクセス制限を実施するように構成されてもよい。申し込みMOを受信した後に、モバイルデバイスは、最後のSOAP交換の後にWiFiホットスポット104と関連付けを解除し、WiFiホットスポット104と再関連付けしてWiFi接続を再確立するように構成されてもよい。再関連付けの際に、モバイルデバイス102は、EAP技術を使用するように構成されてもよく、再確立されたWiFi接続上で提供された信任をAAAサーバ126に提供してもよい。RADIUSACCESSACCEPTメッセージは、ユーザの申し込みに従ってWiFiネットワークへのモバイルデバイス102のアクセスを許可するために、AAAサーバ126からWiFiホットスポット104で受信されてもよい。或る実施例では、関連付け解除及び再関連付けは、ユーザの相互作用なしに実行されてもよい。WiFiホットスポット104は、ユーザの申し込みに関連するRADIUSACCESSACCEPTメッセージで示されたアクセス制限を実施するように構成される。或る実施例では、申し込みサーバ106との初期のSOAP交換の一部として、申し込みサーバ106は、提供される信任の種類を判定し、モバイルデバイス102に提供される信任の種類を示すように構成されてもよい。提供される信任の種類は、1つ又は複数の証明書に基づく信任、ユーザ名/パスワードの信任、又は加入者情報モジュールSIM形式の信任を含む。信任の提供は、以下に詳細に説明するようなSOAPで構成されたメッセージの交換を含んでもよい。提供される信任の種類は、オペレータ又はサービスプロバイダにより判定されてもよい。提供する信任の種類及び認証の使用を判定するために、オペレータのポリシーが使用されてもよい。申し込みの仲裁が必要な場合すなわち、ユーザの申し込みに問題が存在する場合、この方法は、モバイルデバイスがWiFiホットスポット104に関連付けしてその後の認証要求の後に、申し込みの修正の必要性を示すアクションメッセージを受信することを含む。初期のSOAP交換の間に、モバイルデバイスは、申し込み仲裁サーバ506との申し込みの修正を要求し、SOAP技術に従って情報を交換するように構成される。或る実施例では、申し込み仲裁サーバは、申し込みサーバ106と同じサーバでもよいが、これは要求事項ではない。実施例によれば、モバイルデバイス102は、登録機関122のURLのような登録機関情報で構成されてもよい。登録機関122は、サービスプロバイダのエントリを含んでもよい。サービスプロバイダのエントリは、サービスプロバイダのFQDNfullyqualifieddomainnameと、サービスプロバイダのフレンドリー名と、サービスプロバイダのオンラインサインアップのルートトラストroottrustとを含んでもよい。登録機関122は、サービスプロバイダのドメイン名と他のデータとの間の暗号による結び付きを提供してもよい。登録機関122は、モバイルデバイス102と申し込みサーバ106のようなオンラインサインアップサーバとの間の信頼関係を確立するために、モバイルデバイス102により使用されてもよい。モバイルデバイス102がオンラインサインアップを開始すると、オンラインサインアップサーバのメタデータについて登録機関122に問い合わせてもよく、オンラインサインアップのサービスプロバイダの真正性を確認してもよい。モバイルデバイス102はまた、事前に登録情報をダウンロードし、それをローカルに格納してもよく、ここに記載の安全なオンラインサインアップ及び提供プロセスを開始するときに、それを使用してもよい。モバイルデバイス102がデュアルモードのモバイルデバイスである例えば、セルラネットワーク機能とWiFiネットワーク機能との双方を有する場合、モバイルデバイス102はまた、セルラネットワーク接続を使用してリアルタイムに登録機関122に問い合わせ、オンラインサインアップサーバ情報を取得して真正性を確認するように構成されてもよい。実施例によれば、モバイルデバイス102は、WiFiネットワークのWiFiホットスポット104に関連付けし、WiFiホットスポット104を通じて申し込みサーバ106とのTLStransportlayersecurityセッションを確立し、申し込みサーバ106のデジタル証明書を受信するように構成されてもよい。実施例によれば、モバイルデバイス102は、WiFiネットワークアクセスの申し込みを提供し、申し込み管理オブジェクトMOを生成するために、確立された安全なHTTP接続上でアクティベーションポータル108と情報を交換してもよい。申し込みMOは、Hotspot20ネットワークを含む特定のWiFiネットワークへの自動接続のために提供された信任の種類例えば、ユーザ名/パスワード、SIM形式のもの、証明書に基づくものへの参照を含んでもよい。ユーザ名/パスワードの信任の場合、申し込みMOは、ユーザ名とパスワードとを含んでもよい。SIM形式の信任の場合、申し込みMOは、SIM形式の信任についての少なくともいくつかの基本情報を含んでもよい。証明書に基づく信任の場合、申し込みMOは、証明書に基づく信任にアクセスするための情報を含んでもよい。これらの実施例については以下に詳細に説明する。WiFiHotspot20ネットワークのための安全なオンラインサインアップ及び提供について多くの実施例が記載されるが、本発明の範囲はこの点に限定されない。他の実施例は、他の無線ローカルエリアネットワークWLAN及びセルラ形式のネットワークを含み、他の種類のネットワークのための安全なオンラインサインアップ及び提供にも適用可能である。或る実施例によれば、証明機関120は、Hotspot20証明機関CA:CertificateAuthorityすなわち、ルートトラストRootTrustでもよく、Hotspot20証明書を含む証明書を発行するように構成されてもよい。登録機関122は、Hotspot20サービスプロバイダとして登録された会社又は組織でもよい。登録機関122は、既に登録されたFQDN及び/又は選択されたフレンドリー名を含んでもよい。FQDNオーナーは、公衆利用可能なWHOISデータベースで識別されてもよい。選択されたフレンドリー名は、既に登録されたフレンドリー名と同様のものではなく、或いは混同されるべきでない。登録機関122は、適切でない場合には要求されたフレンドリー名の拒否を可能にし得る登録のためのルールを呼び出してもよい。登録機関122は、登録されたサービスプロバイダのデータベースを、これらのフレンドリー名と共に維持管理し、無効なエントリーを除去してもよい。証明機関120からのHotspot20証明書は、登録されたエンティティすなわち、登録機関のデータベースに登録されたものに対してのみ発行されてもよい。証明書は、FQDN登録有効期間を超えない有効期間を有してもよい。或る場合、登録機関122はまた、証明機関として動作してもよい。実施例によれば、モバイルデバイス102は、証明機関120から1つ以上のHotspot20ルート証明書を取得してもよく、ルート証明書は、サーバのFQDNを識別し、オンラインサインアップ及び信任の提供のためのHTTPSに基づく認証に使用可能であることを示してもよい。Hotspot20サービスプロバイダは、証明機関120からの証明書をオンライン申し込みサーバ106に提供してもよく、オンライン申し込みサーバ106で適切なポリシー設定を提供してもよい。これらの実施例については以下に詳細に説明する。サービスプロバイダのネットワークはまた、特に加入者データベースを含む認証、許可及びアカウンティングAAA:authenticationauthorizationandaccountingサーバ126を含んでもよい。AAAサーバ126は、IPアドレスの動的な構成のためのDHCPDynamicHostConfigurationProtocolサーバ127、ドメイン名変換のためのDNSDomainNameServer128のようなネットワークエレメントと通信してもよく、他のネットワーキング動作を実行してもよい。或る実施例では、WiFiホットスポット104は、WiFiAllianceのHotspot20evolutionspecificationのようなHotspot20evolutionの仕様に従って動作するWiFiHotspot20でもよい。モバイルデバイス102は、Hotspot20の動作可能なデバイスでもよく、申し込み情報は、WiFiHotspot20への自動接続のための予め提供された申し込み情報を含んでもよい。WiFiネットワークは、WLANのためのIEEE80211標準及びこれに対する修正のうち1つに従って動作するように構成されたWiFiホットスポットを含む無線ネットワークでもよい。WiFiネットワークは、アップストリーム及びダウンストリームの通信が時分割多重処理に従って同じ周波数チャネルを使用するCSMACAcarriersensemultipleaccesstechniquewithcollisionavoidanceを使用してもよい。或るWiFiネットワークはOFDMorthogonalfrequencydivisionmultiplexingを使用してもよい。他方、第4世代4GLTEネットワーク及びWiMAXネットワークのようなセルラネットワークはOFDMAorthogonalfrequencydivisionmultipleaccess技術を実装してもよい。第3世代3Gセルラネットワークは、CDMAcodedivisionmultipleaccessを使用してもよい。或る実施例では、モバイルデバイス102は、WiFiとセルラネットワークとの双方と通信するように構成された物理レイヤ回路を有するデュアルモードのデバイスでもよい。図2は、或る実施例によるSOAPXMLを使用した安全なオンラインサインアップ及び信任の提供の概略である。これらの実施例では、サーバ側の認証が、ネットワークコンポーネントを認証するために使用される。その後、WiFiネットワークは、申し込みを確立して信任を生成するためにモバイルデバイス102を申し込みサーバ106にリダイレクトする、或いは申し込みの修正のために申し込み修正サーバにリダイレクトする。動作202において、モバイルデバイス102は、EAP方法を使用してWiFiネットワークに関連付けすることにより、信任提供プロセスを開始する。成功したEAPの交換は、WiFiホットスポット104に配信されるRADUSACCESSACCEPTメッセージ203になる。RADIUSACCESSACCEPTメッセージ203は、自分のために実施するWiFiホットスポット104のアクセス制限を含んでもよく、アクセス制限を示してもよい。信任提供プロセスの間のアクセス制限の使用は、ネットワークを保護し、ユーザがインターネットアクセスを得ることを回避することに役立ってもよい。或る実施例では、RADIUS認証プロトコルが動作202の一部として実行されてもよい。或る実施例では、RADIUSACCESSACCEPTメッセージ203は、WiFiホットスポット104に対して、制限された一式のサーバへのモバイルデバイス102のアクセスを制限させる命令を含んでもよい。動作206において、申し込み修正サーバ106を認証し、少なくともいくつかのデバイス機能情報を申し込みサーバ106に提供し、信任の提供が要求されているか否か又は申し込みの修正が要求されているか否かを申し込みサーバ106に通知するために、初期のSOAP交換がモバイルデバイス102により実行される。申し込みの修正の場合のようにモバイルデバイス102が既に信任を有する場合、申し込みサーバ106は、モバイルデバイスを自動的に認証してもよい。この情報を受信すると、申し込みサーバ106は、ユーザ入力が必要であるか、機械のみで交換するメッセージが必要であるかを判定してもよい。ユーザ入力が必要である場合、申し込みサーバ106は、モバイルデバイス102に対してブラウザを起動するように通知してもよい。機械のみのメッセージが必要である場合、申し込みサーバ106からの応答は、メッセージフローが終了したこと又は更なる機械の交換が必要であることの指示を含んでもよい。これらの実施例では、このフローのメッセージは、applicationsoapxmlのHTTPコンテンツタイプを伝達してもよい。メッセージは、モバイルデバイス102のSOAP処理アプリケーション例えば、SOAP処理エレメント125と申し込みサーバ106のSOAP処理アプリケーション例えば、SOAP処理エレメント135との双方に配信されてもよい。動作212は、ユーザ入力が必要な場合に実行される例えば、サービスにサインアップするため又は請求書に対して支払いを行うため。動作212において、モバイルデバイス102はブラウザを起動し、ユーザは、ウェブページを介して情報について促されてもよい。ユーザ交換の終了時に、メッセージフローが完了してもよく、更なるメッセージが要求されてもよい。いずれの場合であっても、申し込みサーバ106は、メッセージ交換が完了したことをモバイルデバイス102に通知してもよく、或いはプロセスの次のステップを特定してもよい。これらの実施例では、このフローのメッセージは、ウェブページに使用されるHTTPコンテンツタイプを伝達する。これは、texthtml、applicationxml及びapplicationxhtmlxmlのコンテンツタイプを含むが、これらに限定されない。動作214において、最後のSOAP交換が、信任提供プロセスを完了してもよい。この最後のSOAP交換は、機械対機械の通信を有してもよいすなわち、ユーザ入力が必要ない。この最後のSOAP交換は、証明書を提供するときに使用されてもよい。これらの実施例では、このフローのメッセージは、applicationsoapxmlのHTTPコンテンツタイプを伝達する。これらのメッセージは、モバイルデバイス102及び申し込みサーバ106の双方のSOAP処理アプリケーションに配信されてもよい。動作226において、モバイルデバイス102は、WiFiネットワークから関連付けを解除してもよい。この理由は、信任が提供されていないからでもよい。動作338において、モバイルデバイス102は、次回にWiFiネットワークに関連付けして認証してもよい。WiFiホットスポット104は、EPAメッセージをAAAサーバ126に及びAAAサーバ126から中継してもよい。AccessAcceptRADIUSメッセージ230になる成功したEAPメッセージの終了の際に、AAAサーバ126は、適切な場合には、ユーザの申し込みに従って、いずれかのアクセス制限をWiFiホットスポット104に配信してもよい。これにより、信任の提供又は申し込みの修正のためにインスタンス化されたいずれかのアクセス制限は、除去される。図3A及び3Bは、或る実施例によるSOAPXML技術を使用した安全なオンラインサインアップ及び証明書に基づく信任の提供のために交換されるメッセージを示している。動作302において、モバイルデバイス102は、WiFiホットスポット104に関連付けしてもよい。或る実施例では、モバイルデバイス102は、最初にHotspot20の動作可能なネットワークをスキャンし、また、WiFiネットワークが安全であるか否か例えば、RSNが可能であり、Hotspot20接続をサポートしているか否かを判定するために、WiFiホットスポットのビーコンの指示指標を探してもよい。モバイルデバイス102は、ユーザプレファレンスに基づいて最も適切なネットワークを選択してもよい。モバイルデバイス102が選択されたサービスプロバイダとの申し込みを有さないと判定した場合、以下に詳細に説明するように、オンラインサインアップ及び提供に自動的にすなわち、ユーザの介入なしに携わるように構成されてもよい。RSN可能なネットワークでは、モバイルデバイス102は、信任なしにRSN可能なネットワークにアクセスするように構成されてもよい。これらの実施例では、モバイルデバイス102は、GASgenericserveraccess要求IEEE80211uに基づくGAS要求等を送信し、オンラインサインアップのNAINetworkAccessIdentifierを要求するように構成されてもよい。オンラインサインアップのNAIは、GASクエリを使用してネットワークから受信されてもよい。NAIを受信した後に、モバイルデバイス102は、サービスにサインアップして提供のための信任を生成する意図があることをネットワークに示すために、EAPExtensibleAuthenticationProtocol認証処理でNAIを使用してもよい。ネットワークは、ユーザ認証を必要とせずに、この目的でモバイルデバイス102へのアクセスを可能にするように構成されてもよい。次に、モバイルデバイス102は、以下に詳細に説明するようにサーバ側の認証を実行してもよい。或る実施例では、動作302は、モバイルデバイス及び認証者がEAP認証処理の後に生成されたマスター鍵からセッション鍵を導くことを可能にするために、4ウェイハンドシェイク4WHS:fourwayhandshakeを実行することを含んでもよい。4WHSは、IEEE80211iに従ってもよいが、これは要求事項ではない。動作302において、モバイルデバイス102は、WiFiホットスポット104を通じて申し込みサーバ106とTLSセッションを確立し、申し込みサーバ106の証明書を受信するように構成されてもよい。証明書は、Hotspot20証明機関により発行されたHotspot20証明書すなわち、ルートトラストでもよく、ルート証明書と呼ばれてもよい。或る実施例では、モバイルデバイス102は、動作304においてRFC2560の手順に従って申し込みサーバ106とTLSセッションを確立してもよく、HTTPSを使用してサーバ側の認証を実行してもよい。或る実施例では、申し込みサーバ106とTLSセッションを確立した後に、モバイルデバイス102は、申し込みサーバ106の証明書がHotspot20トラストルートにより署名されていることを確認してもよい。申し込みサーバ106の証明書がHotspot20ルートトラストにより署名されていることをモバイルデバイス102が確認した場合又は確認することができる場合、モバイルデバイス102は、新たな申し込みの確立を開始するために、動作306を実行するように構成されてもよい。ここに開示の実施例は、オープンネットワークと安全な8021xの種類のネットワークとの双方に適用可能である。この理由は、TLSセッションが証明書の提供のために確立されるからである。従って、以下に説明する同じ処理がオープンWiFiネットワーク/安全でないWiFiネットワークと安全なWiFiネットワーク例えば、8021xのセキュリティを有するものとの双方に使用されてもよい。或る実施例では、申し込みサーバ106の証明書がHotspot20ルートトラストにより署名されていることを確認するために、モバイルデバイス102は、Hotspot20ルートトラストの公開鍵を使用し、証明書を確認してもよい。公開鍵は、鍵サーバ又はモバイルデバイス102内の記憶エレメントから取得されてもよい。サインアップサーバの証明書がHotspot20ルートトラストにより署名されていることをモバイルデバイス102が確認できない場合、又はサインアップのサーバの証明書がHotspot20ルートトラストにより署名されていない場合、モバイルデバイス102は、オンラインサインアップ及び提供プロセスを中止し、確立されたTLSセッションを解放/終了してもよい。動作306において、モバイルデバイス102は、SOAP技術に従ってオンラインサインアッププロトコルospのポストデバイスデータospPostDevDataメッセージを申し込みサーバ106に送信してもよい。メッセージは、要求理由requestReasonの値と、デバイス情報DevInfoと、デバイス詳細DevDetailとを含んでもよい。或る実施例では、デバイス情報及びデバイス詳細情報は、特許出願第13188205に開示されたもののようなOMADMDevlnfo及びOMADMDevDetailMOでもよい。モバイルデバイス102は、モバイルデバイス102が信任に対して登録を希望することを示す申し込み登録に、メッセージの要求理由の値を設定してもよい。申し込みの修正では、モバイルデバイス102は、モバイルデバイス102が申し込みの修正を実行することを希望することを示す申し込みの修正に、メッセージの要求理由の値を設定してもよい。これらの実施例については以下に詳細に説明する図5参照。動作308において、申し込みサーバ106は、提供する信任の種類すなわち、ユーザ/パスワードの信任又は証明書に基づく信任を判定するために、DevInfo及びDevDetailMOで提供された情報を使用してもよい。図3に記載する実施例では、証明書に基づく信任が提供される。動作308において、申し込みサーバ106は、SOAP技術に従ってospPostDevDataResponseメッセージをモバイルデバイス102に送信してもよい。モバイルデバイス102が申し込み登録を要求したため、申し込みサーバ106は、モバイルデバイスがメッセージに与えられたURIに対してブラウザを起動するためのコマンドを返信してもよい。動作310において、申し込みサーバ106からExecuteLaunchBrowsertoURIを受信すると、モバイルデバイス102は、ブラウザを起動し、動作308で戻されたURIに安全なHTTPS接続を確立し、動作308において戻されたオンラインサーバのURIにHTTPSGET要求を送信してもよい。動作312において、モバイルデバイス102及び申し込みサーバ106は、申し込みの生成のためにサービスプロバイダにより要求されたいずれか必要なユーザ情報を交換してもよい。この交換は、ユーザについての情報を提供し、適切な申し込みプランを選択し、いずれかのクレジットカード情報又は支払い情報を提供し、ポリシー及び他のパラメータを確立することを含んでもよい。動作312における登録データの交換の後に、動作314が実行され、モバイルデバイス102は、申し込みサーバ106からospUserlnputResponseXMLインスタンスドキュメントを取得してもよい。エラーが発生しない場合、ospUserlnputResponseは、ospStatus及びgetCertificate実行コマンドのコンテナである。ウェブブラウザは、処理のためにXMLインスタンスドキュメントをローカルに登録されたヘルパーアプリケーション例えば、接続マネージャに渡してもよい。XMLインスタンスドキュメントは、証明書登録サーバ110のURIと、証明書の登録に必要な他のメタデータとを含んでもよい。動作316は、証明書に基づく信任が提供される場合に実行される。動作316の証明書登録手順は、サービスプロバイダとの認証のための申し込み証明書をモバイルデバイス102に提供するために、証明書登録プロトコル例えば、CMPcertificatemanagementprotocol又はSCEPsimplecertificateenrollmentprotocolに従って実行されてもよい。或る実施例では、証明書登録プロセスは、典型的な条件で60秒未満を要するように構成されてもよい。典型的な条件は、WiFiホットスポット012及びサービスプロバイダのコアネットワークが混雑しておらず、証明書登録サーバ110が過負荷でない場合を含んでもよい。成功した手順の後に、モバイルデバイス102は、サービスプロバイダのWiFiネットワークとの認証に使用される申し込み証明書を提供される。成功しない場合、モバイルデバイス102は、証明書の登録の失敗を通知される。動作316で受信した申し込み証明書は、ネットワークとのEAPTLSに基づく認証に使用されるのに適したX509タイプの証明書でもよい。或る実施例では、申し込み証明書は、X509v3の証明書でもよく、シングルサインオンSSO:singlesignonのための公開鍵インフラストラクチャPKI:publickeyinfrastructure及び権限管理インフラストラクチャPMI:PrivilegeManagementInfrastructureについてのITUT標準に従って構成されてもよい。動作318において、モバイルデバイス102は、RFC2560の手順に従って申し込みサーバ106へのTLS接続を開始して再ネゴシエーションしてもよい。証明書の登録が成功した場合、モバイルデバイス102は、TLS認証を実行するときに提供された証明書を使用するように構成されてもよい。証明書の登録が失敗した場合例えば、モバイルデバイス102が証明書を受信しなかった場合、モバイルデバイス102は、TLS認証を実行するときにサーバ側のみの認証を実行してもよい。TLS認証が失敗した場合、モバイルデバイス102は、証明書提供プロセスを中止するように構成されてもよい。動作320において、モバイルデバイスは、SOAP技術に従ってospPostDevDataメッセージを申し込みサーバ106に送信してもよい。メッセージは、デバイス詳細及びデバイス情報のMOを含んでもよい。モバイルデバイス102は、このメッセージの要求理由の値を、証明書の登録が成功した場合には証明書登録完了Certificateenrollmentcompletedに設定してもよく、証明書の登録が失敗した場合には証明書登録失敗Certificateenrollmentfailedに設定してもよい。動作322において、証明書の登録が成功した場合、申し込みサーバ106は、SOAP技術に従ってospPostDevDataResponseメッセージをモバイルデバイス102に送信する。このメッセージは、追加MOaddMOコマンド及び申し込みMOを含んでもよい。申し込みMOは、提供された証明書を申し込みに結び付ける証明書識別子と、補助の提供データとを含んでもよい。ospPostDevDataResponseメッセージには、申し込み及び証明書の提供プロセスが完了したことを示すために、状態すなわち、ospStatusの値が提供完了provisioningcompleteに設定されてもよい。動作324において、モバイルデバイス102は、動作304において確立されたTLSセッションを解放してもよい。動作326において、モバイルデバイス102は、WiFiネットワークから関連付け解除してもよい。動作328において、申し込みが動作316で成功して確立された場合、モバイルデバイス102は、新たに取得された信任すなわち、動作322で提供された信任を使用してWiFiホットスポット104にすなわち、同じサービスセット識別子SSID:servicesetidentifier又は同じHESSIDを用いて再び関連付けしてもよい。図4は、或る実施例によるSOAPXML技術を使用した安全なオンラインサインアップ及びユーザ名/パスワード形式の信任の提供のために交換されるメッセージを示している。動作402、404、406及び408は、動作408においてユーザ/パスワードの信任が提供されることを判定するために申し込みサーバ106がDevInfo及びDevDetailのMOで提供された情報を使用してもよい点を除き、動作302、304、306及び308と同様である。動作410及び412は、動作310及び312と同様である。動作422において、モバイルデバイス102は、申し込みサーバ106からospUserlnputResponseXMLインスタンスドキュメントを取得してもよく、申し込みサーバ106は、SOAP技術に従ってモバイルデバイス102にospPostDevDataResponseメッセージを送信してもよい。このメッセージは、追加MOaddMOコマンド及び申し込みMOを含んでもよい。動作424において、モバイルデバイス102は、動作404において確立されたTLSセッションを解放してもよい。動作426において、モバイルデバイス102は、WiFiネットワークから関連付け解除してもよい。動作428において、申し込みがステップ7で成功して確立された場合、モバイルデバイス102は、新たに取得された信任すなわち、動作422で提供された信任を使用してWiFiホットスポット104にすなわち、同じサービスセット識別子SSID又は同じHESSIDを用いて再び関連付けしてもよい。図5は、或る実施例によるSOAPXML技術を使用した申し込みの修正のために交換されるメッセージを示している。ときどき、ユーザの申し込み又はアカウントが修正される必要があることがある。サービスプロバイダは、これが必要な場合を判定する。この例は、パスワードの失効と、アカウントの滞納した支払いとを含む。申し込みの修正の必要性は、AAAサーバ126のようなサービスプロバイダのAAAサーバの加入者の申し込みデータベースのエントリに格納されてもよい。WiFiネットワークでの加入者からの認証要求に続いて、修正の必要性はモバイルデバイス102に伝達されてもよい。モバイルデバイス102は、以下に説明するように、申し込み修正サーバと申し込み修正メッセージの交換に携わってもよい。動作502において、モバイルデバイス502は、WiFiホットスポット104と関連付けし、動作202図2のものと同様に、EAP方法を含む認証プロセスを実行する。申し込みの修正が必要であることをサービスプロバイダが判定した場合、動作503において、AAAサーバ126は、EAP認証シーケンスの最後に認証者へのURLリダイレクトを備えたRADIUSACCESSACCEPTメッセージを送信するように構成される。RADIUSACCESSACCEPTメッセージは、申し込みの修正の目的でモバイルデバイス102へのアクセスを制限するアクセス制限を含んでもよい。URLリダイレクトは、申し込み修正サーバ506のURLを示してもよい。動作513において、認証者は、WiFiホットスポット104モバイルデバイスが認証されたものに対して、申し込みの修正の必要性を示すアクションフレームをモバイルデバイス102に送信させる。アクションフレームは、ベンダ特有VS:vendorspecificのアクションフレームでもよい。他の実施例では、モバイルデバイス102は、限られた接続が存在すること例えば、アクセス制限のためを判定するため及び申し込みの修正が必要であることをを判定するための技術すなわち、アクションフレームの受信以外を使用してもよい。動作518において、モバイルデバイス102は、動作304図4と同様に、申し込み修正サーバ506とTLS接続を確立してもよい。モバイルデバイス102は、申し込み修正サーバ506の証明書が無効にされていないことを確認するように構成されてもよい。或る実施例では、モバイルデバイス102は、証明書の状態を判定するために、TLS接続内でOCSPOnlineCertificateStatusProtocolを使用してもよい。証明書が無効にされている場合、モバイルデバイス102は、申し込み修正プロセスを中止してもよい。モバイルデバイス102が申し込み修正サーバ506へのTLS接続を開始することができない場合にも、申し込み修正プロセスを中止するように構成されてもよい。モバイルデバイス102は、HTTPを使用してすなわち、HTTPSのセキュリティなしに申し込みの修正を実行する試みを回避するように構成されてもよい。動作520において、モバイルデバイス102は、動作306と同様に、SOAP技術に従ってospPostDevDataメッセージを申し込み修正サーバ506に送信するように構成されてもよい。メッセージは、OMADMOpenMobileAllianceDeviceManagementプロトコルのDevlnfo、DevDetail及びSubscriptionのMOを含むように構成されてもよく、requestReasonの値は、申し込みの修正Subscriptionremediationに設定されてもよい。申し込み修正サーバ506は、ダイジェストdigest方法を使用してHTTP認証を要求してもよく、モバイルデバイス102は、ユーザ名及びパスワードのダイジェストをサーバに提供してもよい。HTTP認証が成功しない場合、申し込みの修正は可能ではなく、モバイルデバイス102は、プロセスを中止するように構成されてもよく、それに従ってユーザに通知してもよい。動作522において、申し込み修正サーバ506は、SOAP技術に従ってospPostDevDataResponseメッセージをモバイルデバイス102に送信してもよい。メッセージは、申し込みMO以下に詳細に説明するの1つ以上の内部ノードについてのXMLデータを含んでもよい。モバイルデバイス102は、申し込みMOの1つ以上の内部ノードを、メッセージで受信した更新された信任で置換するように構成されてもよい。ospPostDevDataResponseメッセージのospStatusは、申し込み修正プロセスが完了したことを示す修正完了Remediationcompleteに設定されてもよい。動作524において、モバイルデバイス102は、動作518において確立されたTLSを解放してもよく、動作526においてWiFiネットワークと関連付け解除してもよい。動作528において、モバイルデバイス102は、申し込み修正プロセスの間に更新された信任を使用して関連付けしてもよい。ここに記載の実施例は、機械の修正及びユーザの修正に適用可能である。機械の修正は、申し込みがユーザの介入なしに修正可能である問題を示す。ユーザの修正は、修正するためにユーザの介入を必要とし得る申し込みに関する問題を示す。図6は、或る実施例による管理オブジェクトツリーを示している。管理オブジェクトツリー600は、モバイルデバイス102に格納されてもよく、ツリールート601と、サービスプロバイダSP:serviceprovider毎の申し込みMOsubscriptionMO602と、サービスプロバイダ毎のFQDN608とを含んでもよい。管理オブジェクトツリー600はまた、デバイス情報MO606DevInfoと、デバイス詳細MO604DevDetailとを含んでもよい。管理オブジェクトツリー600はまた、デバイス特有のWiFiオブジェクトのためのWiFiMO610を含んでもよい。或る実施例では、デバイス詳細MO604は、モデル、ベンダ情報、アダプタの種類、アダプタ構成等のようなデバイス情報と、ユーザ情報とを含んでもよい。デバイス詳細MO604は、デバイスに特有の更なる情報が取得され得るURI、デバイスの種類例えば、PCカード、USB、モデム、エクスプレスカード、ゲームデバイス、音楽プレイヤ、ナビゲーションデバイス、OEM名、ファームウェアバージョン、ソフトウェアバージョン、ハードウェアバージョン、及びホストデバイスが大きいオブジェクトの処理をサポートするか否かのような更なる情報を含んでもよい。デバイス情報MO606は、ホストデバイスの固有の識別子例えば、GUID、製造者識別子、デバイスのモデル、SOAPクライアントのバージョン識別子、及びホストデバイスの言語設定を含んでもよい。図7は、或る実施例によるモバイルデバイスを示している。モバイルデバイス700は、モバイルデバイス102として使用するのに適しており、安全なオンラインサインアップ及び信任の提供並びに申し込みの修正について前述した様々な動作を実行するように構成されてもよい。モバイルデバイス700は、1つ以上のアンテナ701を使用してWiFiホットスポット104図1のようなWiFiホットスポットと無線通信するように構成された物理レイヤ回路702を含んでもよい。モバイルデバイス700はまた、特に提供された信任及び申し込みMO602図6並びに管理オブジェクトツリー600図6の他のエレメントを格納するメモリ706と共に、ここに記載の動作を実行するように構成され得る処理回路704を含んでもよい。処理回路704は、ここに記載の様々なSOAP技術を実行するSOAP処理エレメント125を含んでもよい。モバイルデバイス700はまた、他の動作を実行する媒体アクセス制御のための媒体アクセス制御MAC:mediaaccesscontrolレイヤ回路のような他の機能エレメントを含んでもよい。シングルモードのモバイルデバイスの場合、物理レイヤ回路702は、WiFiネットワークと通信するように構成されてもよい。デュアルモードの実施例では、物理レイヤ回路702は、セルラネットワークとWiFiネットワークとの双方と通信するように構成されてもよい。デュアルモードの実施例では、モバイルデバイス700は、WiFi送受信機と、1つ以上のセルラネットワーク送受信機との双方を含んでもよい。デュアルモードの実施例では、モバイルデバイス700はまた、セルラネットワークからのトラヒックを利用可能なWiFiネットワークに負荷軽減するように構成されてもよい。或る実施例では、モバイルデバイス700は、パーソナルデジタルアシスタントPDA:personaldigitalassistant、無線通信機能を備えたラップトップ若しくはポータブルコンピュータ、ウェブタブレット、無線電話、スマートフォン、無線ヘッドセット、ページャ、インスタントメッセージングデバイス、デジタルカメラ、アクセスポイント、テレビ、医療若しくは健康デバイス、エンターテイメントデバイス、又は情報を無線で送信及び/又は受信し得る他のデバイスのようなポータブル無線通信デバイスでもよい。アンテナ701は、例えば、ダイポールアンテナ、モノポールアンテナ、パッチアンテナ、ループアンテナ、マイクロストリップアンテナ、又はRF信号の送信に適した他の種類のアンテナを含み、1つ以上の指向性又は無指向性アンテナを含んでもよい。或る実施例では、2つ以上のアンテナの代わりに、複数の開口を有する単一のアンテナが使用されてもよい。これらの実施例では、それぞれの開口が別々のアンテナと考えられてもよい。或るMIMOmultipleinputmultipleoutputの実施例では、アンテナ701は、それぞれのアンテナ701と送信局のアンテナとの間に生じ得る空間ダイバーシチ及び異なるチャネル特性を利用するように、効果的に分離されてもよい。モバイルデバイス700は複数の機能エレメントを有するものとして示されているが、1つ以上の機能エレメントは結合されてもよく、デジタルシグナルプロセッサDSP:digitalsignalprocessorを含む処理エレメントのようなソフトウェア構成されたエレメント及び/又は他のハードウェアエレメントとの組み合わせにより実装されてもよい。例えば、或るエレメントは、1つ以上のマイクロプロセッサ、DSP、特定用途向け集積回路ASIC:applicationspecificintegratedcircuit、無線周波数集積回路RFIC:radiofrequencyintegratedcircuit、並びにここに記載の機能を少なくとも実行する様々なハードウェア及び論理回路の組み合わせを有してもよい。或る実施例では、モバイルデバイス700の機能エレメントは、1つ以上の処理エレメントで動作する1つ以上のプロセスを示してもよい。実施例は、ハードウェア、ファームウェア及びソフトウェアのうち1つ又は組み合わせで実装されてもよい。実施例はまた、コンピュータ可読記憶デバイスに格納された命令として実装されてもよい。この命令は、少なくとも1つのプロセッサにより読み取られて実行され、ここに記載の動作を実行してもよい。コンピュータ可読記憶デバイスは、機械例えば、コンピュータにより読み取り可能な形式で情報を格納するためのいずれかの過渡的でない機構を含んでもよい。例えば、コンピュータ可読記憶デバイスは、読み取り専用メモリROM、ランダムアクセスメモリRAM、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイス並びに他の記憶デバイス及び媒体を含んでもよい。或る実施例では、1つ以上のプロセッサは、ここに記載の様々な動作を実装するために、コンピュータ可読記憶デバイスに格納された命令により構成されてもよい。要約は、読者が技術的開示の本質及び要旨を把握することを可能にするという要約を要求する37CFRSection172に従うように提供されている。これは、特許請求の範囲又は意味を限定又は解釈するために使用されないという理解で提示されている。以下の特許請求の範囲は、各請求項が別々の実施例として自立するように、詳細な説明に組み込まれる。