(57)【要約】  システムと方法は、端末をアップデート又はアップグレードするために、情報が端末に転送されることを許可することを示す。しかしながら、クライアントは、クライアントが配置された後、中央位置からリアルタイムでアップデートされることが可能である。本発明と共に与られるシステムと方法は、さらにソフトウェア又は端末の設定を自動的に、又はユーザによって操作されるアップデートを許可する。
2007506197.tif 000002
【特許請求の範囲】
【請求項１】
クライアントのアップデート方法において、
前記クライアントからサーバへの接続を確立するステップ、
前記クライアントが最新のアップデートを有するか判断するステップ、及び
前記クライアントにアップデート情報をダウンロードするステップを含む、
クライアントのアップデート方法。
【請求項２】
請求項１のクライアントのアップデート方法において、
前記判断するステップは、
前記クライアントのタイムスタンプ情報と最新の利用可能なアップデート情報のタイムスタンプ情報とを比較するステップ、
前記クライアントの前記タイムスタンプ情報が最新の情報でない場合に前記サーバから前記クライアントに前記アップデート情報を転送するステップ、及び
前記クライアントが最新の情報を有しアップデートが必要ないことを示す為に標識を前記サーバから前記クライアントに転送するステップを含む、
クライアントのアップデート方法。
【請求項３】
請求項２のクライアントのアップデート方法において、
前記サーバが、前記クライアントがアップデートを備える第２のサーバ通信を実行する
アップデートの位置からＵＲＬアドレスを供給する、
クライアントのアップデート方法。
【請求項４】
請求項２のクライアントのアップデート方法において、
前記サーバは前記アップデート情報を備える、
クライアントのアップデート方法。
【請求項５】
請求項２のクライアントのアップデート方法において、
前記接続を確立するステップは、無線通信への接続を確立する処理であり、
クライアントは、無線端末である、
クライアントのアップデート方法。
【請求項６】
請求項１のクライアントのアップデート方法において、
前記接続を確立するステップは、
サーバのURLアドレスを予めプログラムするステップ、及び、
クライアントが前記サーバと接続を行っていることを確認する為にサーバでクライアントを認証する、
クライアントのアップデート方法。
【請求項７】
請求項６のクライアントのアップデート方法において、
さらに、前記クライアントが最後に通信をするべきであったときから前記サーバの指定の変更があったことに起因して前記サーバが前記クライアントを認証できないときは、前記クライアントを異なるサーバへ案内するステップを有する、
クライアントのアップデート方法。
【請求項８】
請求項１のクライアントのアップデート方法において、
前記サーバは前記クライアントに、新たなサーバとなる第２のサーバの新たなURLを供給する、
クライアントのアップデート方法。
【請求項９】
請求項１のクライアントのアップデート方法において、
前記クライアントは、自動的にアップデート通信処理を行う、
クライアントのアップデート方法。
【請求項１０】
請求項１のクライアントのアップデート方法において、
前記通信処理は、前記クライアントのユーザによって行われる、
クライアントのアップデート方法。
【請求項１１】
請求項１のクライアントのアップデート方法において、
前記接続を確立するステップは、保護された接続による前記クライアントの認証のステップを含む、
クライアントのアップデート方法。
【請求項１２】
端末をアップデートするシステムにおいて、
前記システムは、少なくとも１つのアップデート可能なコンポーネント及び認証情報を転送可能な端末と、
前記端末と通信するサーバとを備え、
前記サーバは、当該サーバによって前記端末が認証されたときにアップデートを端末にダウンロードすることが可能な、
端末をアップデートするシステム。
【請求項１３】
請求項１２記載の端末をアップデートするシステムにおいて、
さらに、ネットワークを通じて保護された情報を転送する手段を備える、
端末をアップデートするシステム。
【請求項１４】
請求項１２記載の端末をアップデートするシステムにおいて、
前記端末は無線端末である、
端末をアップデートするシステム。
【請求項１５】
請求項１４記載の方法において、
前記通信処理はイントラネットを通じて起こる、
方法。
【請求項１６】
請求項１４記載の方法において、
前記通信処理はインターネットを通じて起こる、
方法。
【請求項１７】
請求項１２記載の端末をアップデートするシステムにおいて、
前記サーバと通信を行う少なくとも１つの追加サーバを備え、
前記少なくとも１つの追加サーバは、前記クライアントに転送されるアップデート情報を格納する、
端末をアップデートするシステム。
【請求項１８】
請求項１２記載の端末をアップデートするシステムにおいて、
前記サーバと組み合わされ、多数のアップデートの位置のみならず多数のアップデートのタイムスタンプに関する情報を格納する為に前記クライアントと通信を行うアップデータ装置を備える、
端末をアップデートするシステム。
【請求項１９】
請求項１８記載の端末をアップデートするシステムにおいて、
無線通信リンクを介して前記アップデータは前記クライアントと通信する、
端末をアップデートするシステム。
【請求項２０】
サーバと共に無線通信でクライアントをアップデートするシステムにおいて、
前記システムは、前記クライアントから前記サーバへの通信を開始する手段と、
前記クライアントが最新のアップデートを有するかを判断する手段とを備え、
前記判断する手段は、
前記クライアントの前記タイムスタンプ情報と現在アップデートが可能な前記サーバの前記タイムスタンプ情報を比較する手段、
前記クライアントのタイムスタンプ情報が前記クライアントが最新のアップデートでないと示したときに前記アップデート情報を前記サーバから前記クライアントに転送する手段、及び
前記クライアントが最新のアップデートを有しアップデートは必要ないことを示す為に前記サーバから前記クライアントに標識を転送する手段、及び
前記クライアントにアップデート情報をダウンロードする手段を備える、
クライアントをアップデートするシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
本発明は通信システム、より具体的には、有線、及び無線ネットワークの背景で、ソフトウェア、及び設定を含むアップデートに関する。
【０００２】
無線通信端末の端末のアップデートを含む典型的な通信システムでは、時間がかかり、さらに非効率的な作業である。通常、端末は、アップデート又はアップグレードする為に、購入した場所まで持って帰られる。幾つかの端末は、アップデート又はアップグレードを行うことができず、従って新しい端末を購入する必要があった。
【０００３】
さらには、ソフトウェアプログラムのエラーの修正、又は「バグの修正」を行う場合、プログラムを入れ替える作業、又は電話構成を交換することは高価であり、効率が悪い。さらに、従来のシステムはホットスポットの位置、及びホットスポットの変更に関連するアップデート情報を辿り、端末に提供することができない。
【０００４】
故に、必要とされるのは、端末がある位置の独自の情報を無線通信でダウンロードすることを可能とするアップデートシステム、及び方法である。
【０００５】
開示するシステムと方法は、端末をアップデート、又はアップグレードする為に、情報を端末に転送することを可能とする。以下に述べる様に、クライアントが配置された後、クライアントは、中央位置にあるサーバによってアップデートされる。本発明によって開示するシステムと方法は、更に、ソフトウェア、又は装置構成の自動化された、又はユーザが起動したアップデートを可能とする。
【０００６】
端末をアップデートする方法は、クライアントからマスターサーバへの通信を開始し、クライアントの有するタイムスタンプ情報と、現在の使用可能なアップデートのタイムスタンプ情報を比較することでクライアントが最新のアップデートを有しているかを判断し、必要であれば、必要な情報をクライアントにダウンロードする、というステップを含む
【０００７】
システムは、少なくとも一つのアップデート可能な認証情報を、端末と通信しているサーバに通信することが可能な構成を有する端末を含み、サーバは、端末がサーバによって認証されたときに、アップデートをダウンロードすることが可能である。
【発明を実施するための最良の形態】
【０００８】
図１に示す様に、通信環境１０は、イントラネット又はインターネットの何れかのネットワーク１６の内部でクライアント１２がサーバ１４と通信を行っているものとして示される。サーバが、１個又は複数個のコンピュータを含むことは当業者には明らかである。クライアントと端末という表現は同義的に使用され、クライアントは、他の物の情報資源を利用する、端末及びソフトウェア、又はその他の物からなることは当業者には明らかである。インターネットは、クライアント又は端末がサーバに自身を認識することを可能とすると共に、接続されるサーバに適切な情報を送信することを可能とする。従って、クライアントは、端末又は端末に存在する、特定の構成を有し、特定の情報と共に予めプログラムされた一般的なソフトウェアとすることが可能である。サーバ１４は、下記の方法でクライアント１２を認証すると共に、例えば、アップグレード及び構成データの様な情報を送信する。
【０００９】
例えば、通信は、ＸＭＬを経由して、クライアント１２とサーバ１４との間でインターネット１６を介して行われる。保護された通信回線、例えば一つの具体例として、ＨＴＴＰ（Hyper Text Transfer Protocol）を使用して行われることが場合によっては望ましい。この様な保護された通信回線は、クライアントがサーバ１４によって制御される情報にアクセスを確立する為に要求される認証情報を供給する際に使用することが可能である。
【００１０】
次に、図２は、図１に示されたシステム１０が、サーバ１４と通信している複数のサーバと共に示されている。サーバ１４は、少なくとも１つの他のサーバと通信する中央サーバである。この様な構成において、サーバ１４は、中央サーバ又はＣＣＳ（Central Configuration Server）とみなすことも可能である。具体例に示す様に、サーバ２０，２２は、サーバ１４、及びクライアント１２と通信を行っている。従って、サーバ１４は、ソフトウェアや設定のアップデートを容易にする為に、クライアント１２とサーバ２０，２２との間の接続を提供する。何れのサーバ１４，２０，２２もアップデート情報を格納することが可能であり、以下では、中央サーバを介して作業を行っている複数のサーバをアップデータ２４とみなす。アップデータ２４は、例えば無線通信機器であるクライアント１２と通信を行うが、本発明の趣旨は、有線機器であったとしても制限されるものではない。
【００１１】
例えば、詳細な後述するが、アップデータは、サーバの一部であり、さらに別の例としては、アップデータは、遠隔地に設置されたサーバと通信を行っていることも可能である。
【００１２】
他の実施の形態としては、ＣＣＳは、実際の通信トラフィック（ソフトウェアの機能として、及び／又はハードウェアに備えられた）と共に、アップデート情報を送信する。
【００１３】
本発明の教示に従えば、クライアントは自動的にアップデートされ、クライアント又はユーザは実行、又はアップデートする
【００１４】
図３を参照して、クライアントマネージャ３４と組み合わされたアップデータ３２を含むサーバ３０の一例が示されている。クライアントマネージャは、アップデートを行う際のルールを格納するエンジン３６を備える。クライアントマネージャ３４は、さらにＷｉＦｉ  ＦＳＭ３８、ＧＰＲＳ  ＦＳＭ４０、及びＥｔｈｅｒｎｅｔ  ＦＳＭ４２の様な、様々なＦＳＭ（File Server Manager）と連結されている。アップデータ３２は、ルールに基づいてクライアントとサーバ３０との間の通信が管理することを可能とする為、クライアントサーバ３４とクライアントとの間の通信を管理する。クライアントとサーバ３０との間でアップデートの通信活動が開始すると、アップデータ３２は、様々なファイル又はコンポーネントからタイプに関わらず、コードをもとにアップデートの有無をチェックする。この例では、アップデータ３２は、ＤＬＬ（Dynamically Linked Library）に保持されており、アプリケーション又はソフトウェアに存在する。変形例としては、アップデータは、図３に示す様に分離されたＤＬＬに保持されており、中央クライアントアプリケーションと共に置かれている。アップデータ３２が、アップデートはクライアントにダウンロード可能であると判断すると、ダウンロード又は他の構成が実行される。ダウンロードの処理は、アップデートは自動に行われても良く、又はユーザがアップデートのダウンロードを促されるものであっても良い。
【００１５】
アップデータ３２とアップデータ３２に関係するＤＬＬは、同様に、上位サーバのキー情報を送信する様に設定される。例えば、ユーザインターフェースをアップデータのコア部と分離することが望ましい。これは全ての例において必要とされるものではなく、この様な例では、ユーザインターフェースはＤＬＬの内部に保有されることも可能である。上位サーバは、端末がオンされたとき、又は最初に起動されたときに最初に接続するサーバである。上位サーバのＵＲＬは、クライアントに格納されており、上位サーバは、認証の為に格納された端末に関する情報を有している。クライアントがこの様な上位サーバに接続すると、クライアントは、端末に格納された、アップデータによって管理された最も新しい情報によって判断されたアップデートを取得し、ダウンロードすることが可能である。
【００１６】
一旦、クライアントと上位サーバとの間で通信が確立すると、その後クライアントは、アップデータを介してアップデートを取得する為に、最初に上位サーバに接続する。他の例としては、上位サーバからのＵＲＬは、上位サーバ及びアップデータが同一の端末である場合は、アップデータのＵＲＬと同一とすることも可能である。上位サーバは、将来のアップデート動作において、クライアントが特定のアップデート動作を行っている間に、接続をする為に新たなＵＲＬを供給し、次のアップデート動作では、クライアントは再度同一の上位サーバに接続する。しかしながら、アップデート動作を行っているどのタイミングにおいても上位サーバは、新たなＵＲＬをクライアントに供給し、クライアントが将来アップデート接続動作を行う為の上位サーバとなる為に、サーバに新しく異なるＵＲＬを与えることが可能である。その後、クライアントは、古い上位サーバではなく、新しい上位サーバに接続する。
【００１７】
動作中は、アップデータ３２は、アップデータ３２が少なくとも一つのダウンロードされたファイルを取得したときは、通知を適切な技術要素に送り、そして、ダウンロードされたファイルは、アップデート動作において必要とされるまで、アップデータ３２によって使用可能に維持される。アップデートと共に、一つ以上のファイルがＣＣＳにおいて生成された場合は、アップデータ３２は、一回の動作において全てのファイルをダウンロードする様に指示される。アップデータ３２は、一つの動作で全てのファイルが正確にダウンロードされると、アップデートが成功したことを認識する。
【００１８】
他の例としては、アップデータ３２は、アップデータ３２が、サーバ又はＣＣＳのアップデートが可能であると分かったときに、通知を送る様に構成される。この様な処理では、アップデートファイルは、ＣＣＳの要素がファイルの転送を、アップデートを要求している要素に促し、当該要素がアップデートを受信する準備が出来た旨をアップデータ３２に通知するまで格納部に管理される。例えば、通信事業者からＷｉＦｉパートナーのアップデートを受信すると、アップデータ３２は、ＷｉＦｉ  ＤＬＬに対して新たなアップデートがあることを通知する。すると、ＷｉＦｉの要素は、以前リロードされた古いデータ、又は情報ではなく、新しいアップデートをリロードすることができる。従って、次回、クライアントがアップデート処理を実行し、アップデートを確認したときに新しいアップデートは使用可能になる。
【００１９】
クライアント３２の何れのコンポーネントアプリケーションも、それが必要とするファイルのためにアップデータ３２と共に登録することができ、クライアントマネージャ３４は、自身のコンポーネントを登録することができる。クライアントマネージャが特定の実装の必要性に従って構成された多くのソフトウェアコンポーネントを備えることが好ましい。変形例としては、ＣＣＳは、どの様なファイルがどの様なＤＬＬに動くかをシステムの他の適切な部品に通知するために構成される。さらに、この様な統計はＣＣＳに戻されるが、代わりに、そのような統計が以下に述べるインフラストラクチャＡＰＩへのクライアントの一部とすることができる。どの場合にも、登録のためのデータは、ＷｉＦｉ、ＧＰＲＳ、ＣＤＭＡ、位置ファインダー等の様に、コードに関連する技術のタイプの代理をするストリングを含む。
【００２０】
どの場合にも、登録のためのデータは、ＷｉＦｉ、ＧＰＲＳ、ＣＤＭＡ、位置ファインダー等の様に、コードに関連する技術のタイプの代理をする識別ストリングを含む。ソフトウェアのバージョン、及びクライアントの他の情報が任意なときに、サーバによって生成された最後にダウンロードが成功したアップデートのタイムスタンプが供給される必要がある。
【００２１】
具体例として、クライアント、及びネットワーク又はインターネットの間には、２個のインタフェースが、サーバに接続するか、又は通信するためにある。まず、クライアントは、ローカルコミュニケーション、及び認証のためにホットスポットと通信する。次に、リンクは、状態情報、プロバイダーが実装されるのを必要とするかもしれない顧客の情報を供給していて他のプッシュ・タイプサービスのためにクライアントとサービスプロバイダーの間に確立される。最初のインターフェースに関しては、今日の市場に存在する、ＷＩＳＰｒ、ＡＷＳ、Ｃｏｍｅｔａ  Ｃｏｌｕｂｒｉｓを含む、数個の異なったホットスポットアプリケーションプログラムインターフェース（ＡＰｉＳ）がある。これらのインターフェースは、CCSかサーバでの構成設定を介してクライアントに作動、又は供給される。CCSは、個々に優先的に使用する為のネットワークのリストを保持する。新しいローミングパートナーを容易にCCSに加えて、透過的にクライアントに分配することもできる。
【００２２】
上述した様に、クライアントとローカルホットスポットとのインターフェースに加えて、クライアントとそのサービスプロバイダーとの安全なリンクがある。この通信インターフェースは、クライアントが操作環境における現在の状態のプロバイダーを通知することを可能とし、プロバイダーがクライアントに指示を流すことを可能とする。どの様な指示をクライアントに送るべきであるかに関する決定は、クライアントが実体であると認識するクライアントの現在の状態と他の情報に基づいて決定する。サービスプロバイダーは、どの様な指示をクライアントに、クライアントがいつも最新の決定を求めるものとするの同等に必要な状態で送るべきであるかに関する論理を変化させることができる。例えば、通信リンクは少なくとも、ＨＴＴＰＳを介して行われる。クライアントからのメッセージは、最新のアップデートのためのタイムスタンプなどの様に、デバイスの現状の情報を通常含む。以下のUI要素が必要となる。
バルーン通知
ダイアログ通知
ダウンロード、及び
構成
【００２３】
例えば、アップデータ３２は、接続を可能とするクライアントのサーバ３０ネットワーク接続形態、又は帯域幅のタイプを認識することができない。従って、アップデータ３２は、サーバとのコミュニケーションを確立する位置にはない。この様な例において、アップデータ３２は、アップデートの有無をチェックしようとすることができるかと返答されることを可能とするコントロールインターフェース（図３には図示せぬ）が供給される。また、この、メッセージのフォームにあるインターフェースは接続のタイプをアップデータに知らせることも可能である。さらに、コントロールインターフェースは、ユーザに、本質的には上で説明された自動化された過程への手動を開始する「アップデートをチェックする」ことを実行させる。
【００２４】
図４に示す様にアップデータ５０は、サーバとのコミュニケーションを開始するか、又は模範的ＸＭＬのＨＴＴＰ（Ｓ）ポストを通して以下のパラメータを送り、設定を格納し又はクライアントとアップデータとの間の通信を提供する為に使用されるＣＣＳ５２を形成する。
【００２５】
【表１】
2007506197.tif 000003
【００２６】
以下はアップデータ５０とＣＣＳ５２とのコミュニケーションに関する例について詳しく説明しており、経路５０１でアップデータ５０はＣＣＳ５２へクライアント情報を提示する。
https://ccs.pctel.com/GetSomeUpdate
POST
vendor=PCTEL 
product=RC_WIFI_GPRS
version=2.64.00
serialnumber=123456789
lastupdate=2003-08-13 17:13:19.12
【００２７】
ＣＣＳ５２は、経路５０４のダウンロードについて、あるファイルを指定するフォーマットされたＸＭＬ応答を返すことによって、応じる。
https://server1.ccs.com/downloads/File1.zip
An updated list of carrier defined WiFi networks is available for
download.Do you want to download now?
22048
CSIDL_COMMON_APPDATA
PCTEL_Networks.xml
2003-08-16 12:16:11.12
https://server1.ccs.com/downloads/File2.zip
An updated list of company defined WiFi networks is available for
download.Do you want to download now?
12048
CSIDL_COMMON_APPDATA
PCTEL_Co_Networks.xml
【００２８】
ダウンロードに利用可能なファイルがなければ、ＣＣＳは空のファイルリストを返信する。
【００２９】
【表２】
2007506197.tif 000004
【００３０】
アップデータ５０は、５０６と５０８の経路の指定された、離れた場所からファイルをダウンロードする。また、さらに、上述の発明を取り入れるシステムは、主要なサーバとリモートデバイスとのコミュニケーションを容易にするためにＡＰＩを含む。多数の様々なデバイスが首尾よく本発明のシステムと通信するのを許可するために、ＡＰＩ(独自に使用することができる)を提供する。本発明に従って、以下の模範的情報は典型的なＡＰＩを代表する。
【００３１】
より詳しくは、発明のこの局面はワイヤレスネットワークの中でシームレスのローミングを行うことが可能なクライアントのために、インフラストラクチャＡＰＩのクライアント（以下では、「高性能クライアント」又は「ローミングクライアント」）に向けられる。
そして、このインターフェースは、高性能クライアントと通信事業者のインフラとの間で認証通信を行う様に設計されている。
【００３２】
有料のＷｉ‐Ｆｉプロバイダーの大多数は、Ｗｉ‐Ｆｉローミングパートナーを加えることで元のネットワークを増大させる。ローミングクライアントとＣＣＳは、通信事業者が絶えず各ローミングのためにネットワーク認証と接続論理を加える能力を提供し、その論理をフィールドにいるユーザに提供する。さらに、個別のネットワーク管理ＡＰＩは、ローミングクライアントに能力を統合する間に、通信事業者が継続してセルフサービスネットワーク管理、及びアカウント管理サイトを使用することを可能とする。したがって、本発明は、プロバイダーが高性能クライアントのソリューションをそれらのネットワークの提供と統合とを可能とする。
【００３３】
インターフェース
インターフェースは、インフラに様々な接続状態を送ることでクライアントをサポートする。例えば、クライアントが最初に接続し、プレ認証状態にあるときはプレ認証メッセージを送る。このメッセージは、表３の高性能クライアントの状態に示す状態、及び表４の状態から与えられた情報を含む。
【００３４】
【表３】
2007506197.tif 000005
【００３５】
【表４】
2007506197.tif 000006
【００３６】
表４は、単に発信することがあるかもしれない情報のタイプに関する例であり、制限として意図されていない。以下の様な様々な情報を送信することが可能である。
connected
someuser
123456789
63.142.45.23
【００３７】
動作
アプリケーションキャリアインタフェースは、実行することができる様々な動作から成る。これらの動作は、クライアントがステータスメッセージを送信した後に、インフラからクライアントに供給される。これらのメッセージは、スタンダードＨＴＭＬ内部に埋め込まれるか、又はＸＭＬとすることが可能である。これらの通信は、非保護ＨＴＴＰフォーマットを通じてＨＴＴＰＳフォーマットを使用して行われる。以下は、アクションの例のリストであり、排他的な又は完全なリストを意図するものでは無い。
【００３８】
【表５−１】
2007506197.tif 000007
【００３９】
【表５−２】
2007506197.tif 000008
【００４０】
ＣＣＳインターフェース
ＣＣＳはクライアントのために中心で管理されたインターフェースを可能にする。ＣＣＳは、ローミングクライアントの通信論理の為の中央管理ポイントとして機能する様に設計されており、ローミングクライアントに埋め込まれた複数の位置特定機能を可能とする。ＣＣＳは、この情報の管理を行う為のローミングクライアントのマネジメント制御装置を提供し、又はこの種の情報の第三者の位置を特定するように構成することも可能である。
この様なＣＣＳの構成は、プロバイダーが、簡単に新しいローミングパートナーネットワークを現在提供しているサービスに合体させることを許可する。
【００４１】
ＣＣＳは、新しいＷｉ−Ｆｉローミングパートナーネットワークを作成すること、及び配備されたローミングクライアントに新たな通信論理を分配することを可能とする。
ＣＣＳは、Ｗｉ−Ｆｉサービスパートナーの為にローミングパートナーを増加させ／移動させる機能を有する。これを達成するための模範的テンプレートは以下の通りである。
【００４２】
【表６】
2007506197.tif 000009
【００４３】
クライアントは、ＣＣＳによって判断された方法によってＷｉ−Ｆｉネットワークが「見える」（すなわち、クライアントは、ＣＣＳが「言った」方法によってこの様なネットワークが見える）。例えば、クライアントは、利用可能なＷｉ−Ｆｉネットワークを承知しているが、クライアントのユーザが通信事業者／プロバイダーによって特定され、ユーザが申し込んだ情報が見える様に、入ってきた、ＣＣＳによって提供された構成情報によってネットワーク情報抽出レイヤーを作成する。各Ｗｉ−Ｆｉネットワークは、上の表に示された様なＳＳＩＤによって特定される。しかしながら、ＣＣＳは、情報をエイリアスし、ユーザにさらなる提示された情報を提供する為の構成ファイルを作成する。この様な情報は、例えばＵＲＬ、接続オプション（自動／促進／手動）等のさらに詳細なネットワークの説明を含む。
SomeSSID
PCTEL WiFi Network
This is PCTEL's WiFi network provided by XYZ
roaming partner.
・・・
http://www.pctel.com
・・・
【００４４】
ホットスポットのＡＰＩの設定
例えばＣＣＳは、Ｗｉ−Ｆｉサービスプロバイダーのローミングパートナーの為にホットスポットの設定を増加／移動させる機能を含む。他の変形例として、ホットスポットの情報は、ユーザフレンドリーなＣＣＳユーザインターフェース（ＵＩ）を通じて管理される。典型的に、必ずしも全ての形態において必要とされるものではないが、全ての情報は、迅速で柔軟なデータサーチ及び修正の為に、関連するデータベースフォーマットに格納される。さらには、典型的な修正として、ホットスポットの設定の為のアップデートファイルは、クライアントに対して簡単で柔軟な操作が行える、売却し易いＸＭＬフォーマットで供給される。以下の表は、ホットスポットのテーブルが管理されるかを反映する。
【００４５】
【表７】
2007506197.tif 000010
【００４６】
さらには、ホットスポットを増加させるテンプレートの例を以下に示す。
【００４７】
【表８】
2007506197.tif 000011
【００４８】
この様なホットスポットのコードの例を以下に示す。
D/FW International Airport Terminal E
PO Drawer 619428
DFW Airport
TX
75261
Wayport HotSpot
Airport
USA
・・・
・・・
【００４９】
Ｗｉ−Ｆｉサービスプロバイダーがホットスポットを増加し、又は移動させる為のローミングパートナーの為の、基本的なＣＣＳの機能の通信事業者インターフェースの設定を以下の表に示す。
【００５０】
【表９】
2007506197.tif 000012
【００５１】
ＣＣＳは、通信事業者、及び／又はローミングパートナーに、認証及びＷｉ−Ｆｉネットワークへのログインの為の具体的な方法を特定する為の、快適、且つ柔軟な方法を提供する。変形例として、各ネットワークは、それに定義された任意の数のＡＰＩ設定を有するものであっても良い。ＡＰＩ設定は、認証符号のフォーム、及び関連するパラメータで表現される。各認証符号は、任意の数のパラメータを有するものであっても良い。この仕組みを使用することで、ＣＣＳは、異なるネットワーク環境でクライアントが作動する方法に動的な変化の手段を提供する。柔軟な構成ファイル（以下を参照）優位性の意味に実行される任意の数の認証符号を特定する可能とする。もし、高い優位性を有する認証符号が失敗すると、クライアントは自動的に、次の認証符号をリストから例示する。認証符号のコードの例を以下に示す。
https://awireless-
oac-
g3.qpass.com/wificontrollerservlet/
aws
http://Watergate.corp.au
s.wayport.net/roamer_login.adp
loopyfix
Auth_Wayport
goport.com
http://www.google.com
/index.html
Mozilla/4.0
(compatible; MSIE 5.5; Windows NT 5.0)-
AWSWiFiManager/1.0
・・・
・・・
【００５２】
サインアップ方法
図５を参照して、ローミングクライアントをインストールしたが未だ使用したことの無い客の為の手順ダイアグラムが示されている。客は支援されたホットスポットにいるので、彼は、インターネットに接続する為に、クライアントが既に作動し、又はアプリケーションを起動しているのであれば接続を促される。図５の手順ダイアグラムの上部には、アカウントを登録するプロセス、購入サービス、及びインターネットに接続と題された手順を示す。以下は、ステップの記述の間の交互作用を意味する手順のリストである。
【００５３】
図５のステップ１では、本発明のアプリケーションは、プロバイダーと位置情報を抽出する為に外部のＵＲＬに「ＨＴＴＰ取得」を生成する。
【００５４】
【表１０】
2007506197.tif 000013
【００５５】
ステップ２では、アプリケーションはＨＴＴＰの応答を説明し、プロバイダー、位置、及びエラー等の供給された情報を格納する（このステップの実行者はプロバイダー／具体的にはＮＡＳ）。
【００５６】
【表１１】
2007506197.tif 000014
【００５７】
ステップ３で、アプリケーションはウェブポータルに現在の状態、位置等の情報を提示する。
【００５８】
【表１２】
2007506197.tif 000015
【００５９】
ステップ４で、ウェブポータルは、アプリケーション（テーブル１で示された通常の動作）によって行われるべき一組の動作を判断する。この場合、通信事業者のウェブポータルは、「ミニブラウザを起動」の命令を送信し、新たなユーザサインアップ動作を実行する為に使用されるべきＵＲＬを特定する。
【００６０】
【表１３】
2007506197.tif 000016
【００６１】
ステップ５で、「ミニブラウザを起動」の動作は、３個のパラメータ、即ちＵＲＬ、幅、及び高さ、を採用する。幅及び高さはピクセルによって特定される。アプリケーションは、典型的には、必ずしも必要ではないが、ユーザのスクリーンの中心にブラウザウィンドウを表示する。もし、幅及び高さが供給されず、又は不正な値を含むときは、ミニブラウザのサイズは６４０×４８０ピクセルに初期化される。
【００６２】
ステップ５ａから５ｄで、ポータルは、新たなユーザアカウントを設定する為の一つ又は複数のステップを提供する。ユーザは、現在のＨＴＭＬページと相互に通信することで異なるオプションの指示及び選択する自由性を有する。ミニブラウザは、サインアップ動作を終了する為の新たな動作の組を列挙する。
【００６３】
ステップ６で、ウェブポータルは、埋め込まれたＸＭＬの一部として一つ又は複数の動作を応答する。ＨＴＴＰの応答では、アプリケーション動作のカスタムＨＴＴＰのヘッダーは、「Ｙｅｓ」にセットされ、これによりアプリケーションクライアントは埋め込まれた動作のリストの説明、及び実行をする。
【００６４】
【表１４】
2007506197.tif 000017
【００６５】
ステップ7では、アプリケーションクライアントは、ユーザにパスワードを確認するように促した後に、ログイン手順を試みる。
【００６６】
【表１５】
2007506197.tif 000018
【００６７】
ステップ9では、システムは、ログイン手順が成功したかどうかを判断する。
【表１６】
2007506197.tif 000019
【００６８】
ステップ9では、アプリケーションは新しい状態情報及び関連する情報をキャリヤーウェブポータルへ提示する。
【００６９】
【表１７】
2007506197.tif 000020
【００７０】
ステップ１０では、ウェブポータルは、アプリケーション情報を分析して、さらなる動作が固有識別文字によって実行されるべきであるかどうか決定する。また、これはユーザにカスタム設計された広告内容を延期されることができた瞬間でもある。
【００７１】
【表１８】
2007506197.tif 000021
【００７２】
そして、ユーザが既にアカウントを有している例では、クライアントはログインの状態アップデートとの関係を開始する。このメッセージは、上述した新しいユーザに対する類似の方法で適切な情報を主要なシステムに供給される。
【００７３】
図6を参照して、クライアントをアップデートするプロセスはステップ６００で開始する。ステップ６０４では、クライアントは初めて起動され、そして、ステップ６０６では、クライアントは予めプログラムされたＵＲＬに存在しているサーバとのコミュニケーションセッションを開始する。ステップ６０８では、サーバは、クライアントを確認にするためにクライアントを認証する。クライアントがアップデートのためのこのサーバに通信するべきであるときサーバがクライアントを判断することができない場合は、ステップ６１６では、サーバはクライアントからの要求を無視する。また、要求を無視することに加えて、特にこれが動かされた後のクライアントの最初のアップデートコミュニケーションセッションであるなら、サーバは誤りの原因を決定するために中央の位置にクライアントの識別情報を供給する。サーバがクライアントを認証する場合は、クライアントがサーバへの情報を送るステップ６１０では、アップデートとサーバに関する時間・日付のスタンプ情報を含んでいるのは、アップデートが利用可能で、必要であるかどうか決定する。ステップ６１２でアップデートは必要でない決定した場合は、サーバはアップデートは必要でなく、プロセスがステップ６４０で終了することをクライアントに通知する。他方で、サーバを有する管理プログラムが、ステップ６１０でアップデートが必要であることを決定した場合は、ステップ６１４では、アップデートを含む位置のURLを決定する。ステップ６１８において、サーバは、アップデートのためのURLがそれ自身のURLと同一又は異なるものであるかを決定する。URLが異なるものである場合、ステップ６２０では、リモートURLからアップデートを得る。URLが同一の場合は、ステップ６２２では、アップデートは、現在のサーバのURLに位置する。ステップ６２４では、アップデートをクライアントにダウンロードする。ステップ６２８では、クライアントからの情報と現在のアップデート情報に基づいて、利用可能で、追加しているアップデートが必要であるか否かを決定する。追加アップデートがある場合は、ステップ６２６では、URLを得てステップ６１８へのプロセスとなる。追加アップデートは必要でない場合は、ステップ６３０では、アップデートセッションを終了する。
【００７４】
ステップ６３２では、親サーバが、より長い間最初の連絡先として機能しないことをシステムで決定する。ステップ６３６では、現在の親サーバは、新しい親サーバが指定されたなら、予めプログラムされたＵＲＬを置き換えるために新しいＵＲＬを提供し、そして、クライアントはその後、新しいＵＲＬに位置している新しい親サーバとのアップデートコミュニケーションセッションを開始する。他方では、新しい親サーバが必要でない、又は指定されないなら、クライアントで予めプログラムされる現在のＵＲＬは変わらずに、ステップ６４０でプロセスが終了する。他の例として、最初のコミュニケーションセッションが開始されていない場合は、最後のコミュニケーションセッションかクライアントが予めプログラムされて以来新しいＵＲＬの新しい親サーバが指定されているので、親サーバがステップ６０８にある認証ステップの間に新しいＵＲＬを提供する。この場合、サーバはクライアントを認証することができ、そして、新しいＵＲＬの新しい親サーバか代替手段による親サーバへのコミュニケーションセッションの残っている部分が新しいＵＲＬでクライアントをアップデートして、クライアントを命令することができるパスは新しい親サーバとの新しいコミュニケーションセッションを開始する。
【００７５】
この分野において熟練した者は、教示をもとに様々な具体化及び代替手段を本発明とそうかけ離れていない位置に存在することが解る。
【図面の簡単な説明】
【００７６】
【図１】本発明による、クライアントがサーバと通信している状態を示す。
【図２】本発明による、複数のサーバと通信を行っているクライアントを示す。
【図３】本発明による、クライアントに送信されるアップデートを行うアップデートソフトを示す。
【図４】アップデートソフトとサーバとの通信方法を示す。
【図５】クライアントが、サーバからアップデートをダウンロードする方法を示す。
【図１】
2007506197.tif 000022
【図２】
2007506197.tif 000023
【図３】
2007506197.tif 000024
【図４】
2007506197.tif 000025
【図５】
2007506197.tif 000026
【図６】
2007506197.tif 000027
【国際調査報告】
2007506197.tif 000028
2007506197.tif 000029