(57)【特許請求の範囲】
【請求項１】
クライアントと１つまたは複数の遠隔サーバの間のネットワーク上のラウンドトリップ通信を低減する方法であって、
ａ．ソフトウェアアプリケーション識別、ソフトウェア・アプリケーション・パラメータ、および遠隔サーバ情報からなるグループから選択される入力をユーザから収集するためのクライアント側ソフトウェアアプリケーションを提供するステップと、
ｂ．前記クライアント側ソフトウェアアプリケーションを使用して、前記ユーザ入力を分析し、ＤＮＳリクエストを含む１組の必要とされるプロトコルおよびアプリケーションステップを決定し、前記ユーザ入力に基づき多数のプロトコルおよび／またはアプリケーションに関連付けられる部分を含むマルチ・パート・メッセージを構築し、前記１つまたは複数の遠隔サーバからレスポンスを受け取るステップと、
ｃ．前記マルチ・パート・メッセージをそのようなマルチ・パート・メッセージを受け取ることをサポートするネットワーク機器に向けて送信するステップと、
ｄ．前記ネットワーク機器を使用して、前記マルチ・パート・メッセージを受け取り、前記マルチ・パート・メッセージの前記ＤＮＳリクエスト部分を識別し、ドメイン名をアプリケーションサーバのアドレスに解決し、前記マルチ・パート・メッセージから前記ＤＮＳリクエストを取り除くステップと、
ｅ．前記ネットワーク機器を使用して、前記アプリケーションサーバに向けて前記マルチ・パート・メッセージの残りの部分を転送するステップと、
ｆ．前記アプリケーションサーバを使用して、前記マルチ・パート・メッセージの前記残りの部分を受け取り、前記メッセージのネットワークプロトコル部分を識別し、前記クライアント機器とのプロトコルハンドシェイクを完了するステップと、
ｇ．前記アプリケーションサーバを使用してアプリケーションパラメータを含む前記マルチ・パート・メッセージの部分を復号し、ステップｆで確立されたネットワーク接続上で前記クライアントにアプリケーションレスポンスを送信するステップと
を含む方法。
【請求項２】
前記プロトコルハンドシェイクおよび前記アプリケーションレスポンスがマルチ・パート・レスポンス・メッセージで前記クライアントに送信される、請求項１に記載の方法。
【請求項３】
前記ネットワーク機器が前記マルチ・パート・メッセージの受信後に以下のステップ、すなわち、
ａ．前記ネットワーク機器がサポートする前記マルチ・パート・メッセージの部分を認識するステップと、
ｂ．前記部分に対するパラメータを決定するステップと、
ｃ．前記マルチ・パート・メッセージの別の部分に前記決定されたパラメータを埋めるステップと、
ｄ．前記マルチ・パート・メッセージをアプリケーションサーバに向けて転送するステップと
を実行する、請求項１に記載の方法。
【請求項４】
前記ネットワーク機器がＤＮＳサーバであり、前記決定されたパラメータが前記アプリケーションサーバのＩＰアドレスを含み、前記ネットワーク機器が前記マルチ・パート・メッセージのネットワークプロトコル部分の中に前記ＩＰアドレスを埋める、請求項３に記載の方法。
【請求項５】
前記アプリケーションサーバが前記ネットワーク機器により転送された前記マルチ・パート・メッセージの残りの部分を受け取り、マルチ・パート・メッセージの前記残りの部分の処理を完了する、請求項３に記載の方法。
【請求項６】
前記マルチ・パート・メッセージの前記残りの部分を前記処理するステップが、前記クライアントとのトランスポート層接続を確立するステップと、前記アプリケーションサーバへのアプリケーションリクエストを引き渡すステップとを含む、請求項５に記載の方法。
【請求項７】
第２のネットワーク機器が、前記転送されたマルチ・パート・メッセージを受け取り、前記マルチ・パート・メッセージの受信後、以下のステップを、すなわち、
ａ．前記メッセージの一部を処理するステップと、
ｂ．前記メッセージの前記処理された部分を取り除くステップと、
ｃ．前記完了された処理からの残りのメッセージの一部を埋めるステップと、
ｄ．前記残りのメッセージを前記アプリケーションサーバに向けて転送するステップと
を実行する、請求項３に記載の方法。
【請求項８】
前記クライアント側ソフトウェアアプリケーションがユーザ入力を受け取り、前記クライアント機器内の関連するアプリケーション、およびユーザリクエストを完了するための対応するネットワークプロトコルを決定する、請求項１に記載の方法。
【請求項９】
前記ネットワーク機器が、前記受け取られたマルチ・パート・メッセージの各部分に対するレスポンスを受け取り、マルチ・パート・レスポンス・メッセージを構築し、前記レスポンスを前記クライアントに送信する、請求項１に記載の方法。
【請求項１０】
前記ネットワーク機器が、前記マルチ・パート・メッセージの前記ＤＮＳリクエスト部分を識別し前記ドメイン名をアプリケーションサーバのアドレスに解決した後に、前記クライアントにＤＮＳレスポンスを送信する、請求項１に記載の方法。
【請求項１１】
クライアントと１つまたは複数の遠隔サーバの間のインターネットを介したラウンドトリップ通信を低減する方法であって、
ａ．クライアント機器内のソフトウェアアプリケーションを使用して、
前記クライアント機器のユーザから受け取られる入力から得られるアプリケーション部分およびネットワークプロトコル部分であって、前記ネットワークプロトコル部分がＤＮＳリクエストと、ＴＣＰ  ＳＹＮリクエストおよび／またはＵＤＰ／アプリケーションデータと、別のネットワーク／転送プロトコル情報とを含み、前記アプリケーション部分が対応するアプリケーション情報を含み、前記プロトコル部分およびアプリケーション部分が前記クライアント機器内で利用できるローカルな情報だけを含み、前記クライアント内で利用できない情報が前記１つまたは複数の遠隔サーバにより埋められるように印をつけられるアプリケーション部分およびネットワークプロトコル部分
を含むマルチ・パート・メッセージを構築するステップと、
ｂ．前記１つまたは複数の遠隔サーバに向けて前記マルチ・パート・メッセージを送信するステップと
を含む方法。
【請求項１２】
ａ．前記クライアント機器内の前記ソフトウェアアプリケーションを使用して、ローカルのアプリケーションおよびネットワーク・プロトコル・エンティティを識別し起動し、前記マルチ・パート・メッセージからのレスポンスを受け取り処理するステップ
をさらに含む、請求項１１に記載の方法。
【請求項１３】
前記アプリケーション部分が、ローカルに公知の地理的位置情報、セルラネットワーク環境内の前記クライアント機器に公知のセクタ、セル、または領域の情報、および時刻情報からなるグループから選択される情報を含む、請求項１１に記載の方法。
【請求項１４】
前記対応するアプリケーション情報がｈｔｔｐリクエストを含む、請求項１１に記載の方法。
【請求項１５】
前記クライアントに利用できない前記情報がＩＰアドレスを含む、請求項１１に記載の方法。
【請求項１６】
クライアントと１つまたは複数の遠隔サーバの間のネットワーク上のラウンドトリップ通信を低減する方法であって、
ａ．ソフトウェアアプリケーション、識別、ソフトウェア・アプリケーション・パラメータ、および遠隔サーバ情報からなるグループから選択される入力をユーザから収集するためのクライアント側ソフトウェアアプリケーションを提供するステップと、
ｂ．前記クライアント側ソフトウェアアプリケーションを使用して、前記ユーザ入力を分析し、ＤＮＳリクエストを含む１組の必要とされるプロトコルおよびアプリケーションステップを決定し、前記ユーザ入力に基づき多数のプロトコルおよび／またはアプリケーションに関連する部分を含むマルチ・パート・メッセージを構築し、前記１つまたは複数の遠隔サーバからレスポンスを受け取るステップと、
ｃ．前記マルチ・パート・メッセージをそのようなマルチ・パート・メッセージを受け取ることをサポートするプロキシ機器に向けて送信するステップと、
ｄ．前記クライアントと前記遠隔サーバの間の経路内の前記プロキシ機器の位置を突き止めるステップであって、前記プロキシが以下のステップ、すなわち、
ｉ．前記マルチ・パート・メッセージの一部を識別するステップと、
ｉｉ．前記部分からの前記情報を使用して、対応する標準的メッセージを構築することにより前記メッセージのその部分に対してプロキシ動作を実行するステップと、
ｉｉｉ．前記標準的メッセージを関係のあるサーバに転送するステップと、
ｉｖ．前記関係のあるサーバからのレスポンスを受け取るステップと、
ｖ．レスポンスを元のサーバに返すステップと
を実行するステップと
を含む方法。
【請求項１７】
前記プロキシ機器が以下のステップを、すなわち、
ａ．前記マルチ・パート・メッセージの該当する部分を前記関係のあるサーバから受け取られた前記レスポンスで埋めるステップと、
ｂ．前記マルチ・パート・メッセージの次の部分を、
ｉ．前記満たされた部分からの前記情報を使用して、第２の対応する標準的メッセージを構築することにより前記マルチ・パート・メッセージの前記次の部分に対してプロキシ動作実行し、
ｉｉ．前記第２の標準的メッセージを第２の関係のあるサーバに転送し、
ｉｉｉ．前記第２の関係のあるサーバからレスポンスを受け取り、
ｉｖ．第２のレスポンスを前記元のサーバに返す
ことにより処理するステップと
をさらに実行する、請求項１６に記載の方法。
【請求項１８】
前記プロキシ機器が、前記遠隔サーバと通信しているときに標準的メッセージを利用する、請求項１６に記載の方法。
【請求項１９】
前記プロキシが無線ネットワーク内のラウンドトリップを低減するために無線アクセスネットワーク内に配置される、請求項１６に記載の方法。
【請求項２０】
前記プロキシが公衆移動通信網（Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ、ＰＬＭＮ）内に配置される、請求項１６に記載の方法。
【請求項２１】
前記プロキシがＧＧＳＮとインターネットの間に配置される、請求項２０に記載の方法。
【請求項２２】
前記プロキシが、前記受け取られたマルチ・パート・メッセージの各部分に対するレスポンスを収集し、マルチ・パート・レスポンス・メッセージを構築し、前記レスポンスを前記クライアントに送信する、請求項１６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、内容が本明細書において全体を参照により組み入れられる、２００８年８月６日に提出された、米国特許仮出願第６１／０８６，５１３号明細書の優先権を主張する。
【背景技術】
【０００２】
図１は例示的移動無線ネットワーク、たとえば３Ｇ／ＵＭＴＳネットワークにおけるネットワーク構成要素を示す。無線ネットワークは無線アクセスネットワーク（ＲＡＮ）およびコアネットワーク（ＣＮ）を含む。
【０００３】
ＧＧＳＮ（ゲートウェイＧＰＲＳサービスノード）が移動無線ネットワークをＩＰコアネットワークに接続する。ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）はＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）ネットワークの主要な構成要素である。ＧＧＳＮは、ＧＰＲＳネットワークと外部のパケット交換網、たとえばインターネットおよびＸ．２５ネットワークとの間の互換性に責任を負う。
【０００４】
外部ネットワークから見たとき、ＧＧＳＮは外部ネットワークからＧＰＲＳインフラストラクチャを隠すので、ＧＧＳＮはサブネットワークへのルータとして見える。ＧＧＳＮが特定ユーザにアドレス指定されたデータを受け取るとき、ＧＧＳＮは、ユーザが活動状態かどうかを調べる。ユーザが活動状態である場合、ＧＧＳＮは移動ユーザに対応するＳＧＳＮにデータを転送する。しかし移動ユーザが活動状態でない場合、データは捨てられる、または移動機器の位置を突き止め移動機器に通知するためにページング手順が開始される。ＧＰＲＳネットワーク内部で発生するデータについては、ＧＧＳＮはこれらの移動発生パケットを正しい外部ネットワークにルーティングする。
【０００５】
ＧＧＳＮはＳＧＳＮから得られるＧＰＲＳパケットを適切なパケット・データ・プロトコル（ＰＤＰ）形式（たとえば、ＩＰまたはＸ．２５）に変換し、それらを対応するパケット・データ・ネットワークに送信する。入力パケットについては、ＰＤＰアドレスが宛先ユーザのＧＳＭ（Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）アドレスに変換される。次に、再度アドレス指定されたパケットが、責任のあるＳＧＳＮに送信される。この機能を完了するために、ＧＧＳＮはユーザの現在のＳＧＳＮアドレス、およびユーザに関係するプロファイルをＧＧＳＮの位置レジスタ内に記憶する。ＧＧＳＮはＩＰアドレス割付に責任があり、接続されたユーザ装置（ＵＥ）に対するデフォルトルータとなる。ＧＧＳＮはまた認証機能を実行する。
【０００６】
サービングＧＰＲＳサポートノード（Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ、ＳＧＳＮ）が、ＳＧＳＮの地理的サービルエリア内部の移動局との間のデータパケットの引き渡しに責任を負う。ＳＧＳＮの仕事はパケットのルーティングおよび転送、移動管理（接続／切り離しおよび位置管理）、論理リンク管理、ならびに認証および課金の機能を含む。ＳＧＳＮの位置レジスタは、このＳＧＳＮに登録されたすべてのＧＰＲＳの位置情報およびユーザプロファイルを記憶する。
【０００７】
無線ネットワークコントローラ（すなわちＲＮＣ）は無線アクセスネットワーク内の管理構成要素であり、ＲＮＣに接続されるノードＢを制御する責任を負う。ＲＮＣは無線資源管理、すなわち移動管理機能の一部を実行し、ユーザデータが移動体との間で送信される前に暗号化が行われる地点である。ＲＮＣはパケット交換コアネットワーク内のＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）に接続する。
【０００８】
ノードＢはＵＭＴＳ／３ＧＰＰアーキテクチャにおける基地局（ｂａｓｅ  ｔｒａｎｓｃｅｉｖｅｒ  ｓｔａｔｉｏｎ、ＢＴＳ）を指すために使用される用語である。あらゆるセルラ方式、たとえばＧＳＭにおけるように、ノードＢ（すなわちＢＴＳ）は、ノードＢの周りを自由に移動するユーザ装置と直接通信するために使用される１つまたは複数の無線周波送信機および１つまたは複数の無線週波受信機を含む。
【０００９】
ＵＥは、ハンドセット、スマートホン、およびコンピューティング装置を含むあらゆるユーザ装置を含む。
【００１０】
基盤となる物理的転送媒体に関係なく、たいていのインターネットアプリケーションがクライアント・サーバ・アーキテクチャを使用し、クライアント・サーバ・アーキテクチャでは、クライアントおよびサーバは、ＴＣＰ／ＩＰプロトコルを使用してインターネットを介して通信する２つの異なる機器内の２つの頃なるアプリケーション（レイヤ７）である。典型的トランザクションに対してとられる動作のシーケンスが図２に示されている。
【００１１】
この例はＷｅｂサイトのアクセスを示すが、示されるシーケンスは多くの別のアプリケーションにも同様に適用できる。たとえば、インターネットサイト、たとえばｗｗｗ．ｙａｈｏｏ．ｃｏｍ上の職業別電話帳（ｙｅｌｌｏｗ  ｐａｇｅｓ）にアクセスするとき、ステップ１に示されるように、ユーザがクライアントアプリケーションをまず始動する。この例では、クライアントアプリケーションは好ましくはＷｅｂブラウザである。次に、ユーザはアクセスしようとするサイトのドメイン名を入力する。ステップ２に示されるように、クライアント機器がデフォルトＤＮＳサーバへのＤＮＳクエリを生成し、次にデフォルトＤＮＳサーバがドメイン名をＩＰアドレスに変換する。ステップ３で、ＤＮＳサーバが、意図されたサイトの名前に対応する１つまたは複数のＩＰアドレスを含むレスポンスを返す。次に、ステップ４で、クライアント側がＤＮＳレスポンスに含まれるＩＰアドレスにあるサーバのポート番号（たとえばＨＴＴＰポート）に接続するためのＴＣＰ接続（ＴＣＰ／ＳＹＮ）リクエストを生成する。次に、ステップ５に示されるように、アプリケーションサーバは肯定応答（ＴＣＰ／ＳＹＮ−ＡＣＫ）を返す。ステップ６で、クライアントはＴＣＰ／ＡＣＫで応答し、ＴＣＰ接続を確立する。次に、ステップ７に示されるように、クライアントアプリケーション（すなわち、ブラウザ）がサーバにＨＴＴＰリクエストを送信する。ステップ９で、サーバは職業別電話帳に対するリンクを含むｗｗｗ．ｙａｈｏｏ．ｃｏｍのホームページを含むＨＴＴＰレスポンスを返す。次に、ユーザは職業別電話帳のリンクを選択する。返されるページのサイズに応じて多数のＴＣＰパケットが交換されることがある。
【００１２】
上記のシーケンスでは、ＨＴＴＰレスポンスが１つのＴＣＰパケット内に、およびページがより大きい場合にはさらに多くのＴＣＰパケット内に含まれる場合、サイトのトップページを受け取るために最小３つのラウンドトリップがある。Ｗｅｂページコンテンツが単一ＴＣＰパケット（ｈｔｔｐ−レスポンス）内に含まれる場合でさえ、クライアントアプリケーションが任意のＷｅｂページコンテンツを見る前に、最小３つのランドトリップが経過する。周辺部のリンク上、たとえば無線移動環境内では、「無線の帯域幅」（ＯＴＡ  ＢＷ）およびラウンドトリップ時間が著しく変化することがある。たとえば３Ｇネットワークでは、ラウンドトリップ時間は、よい条件で１００ｍｓから２００ｍｓまで変化することがあり、より劣悪な無線条件でははるかに大きい（秒のオーダ）ことがある。したがって、最初のページが表示される前にユーザが体験する遅延は、最良の条件で３００ｍｓから６００ｍｓまでとなることがある。
【発明の概要】
【発明が解決しようとする課題】
【００１３】
無線ネットワーク、特に３Ｇネットワークに関係する長く予測できない遅延のために、ユーザと遠隔サーバの間に必要とされるラウンドトリップの数を低減することができるシステムおよび方法があれば有益である。
【課題を解決するための手段】
【００１４】
従来技術の問題は本発明により軽減される。本発明は、アプリケーション活動化とは無関係なユーザ入力の収集、ならびに基盤となる部分的に満たされたプロトコルパケット、たとえばＤＮＳリクエスト、ＴＣＰ−ＳＹＮデータ、ローカル・ブラウザ・パラメータ、およびアプリケーション−データパケットと共にユーザ入力をネットワークにその後転送することを開示する。強化されたサーバ側アプリケーション、たとえば強化されたＤＮＳサーバがマルチ・パート・メッセージを受け取り、メッセージのＤＮＳ部分を処理し、残りのメッセージを次のサーバに受け渡す。代わりの展開環境、たとえばプロキシでは、プロキシが多数のアプリケーションに対するデータ全体を受け取り、クライアントアプリケーションに代わって上記のステップを完了し、したがって、元のクライアントとサーバの間のラウンドトリップを最小にする。
【００１５】
本発明は、ターゲットＷｅｂサイト、たとえばｙａｈｏｏで処理される追加のアプリケーションデータ、たとえば「ｙｅｌｌｏｗ  ｐａｇｅｓ」、「ｒｅｓｔａｕｒａｎｔｓ」を含むように、クライアント側で上記のマルチ・パート・メッセージをさらに拡張する。クライアント側はユーザ入力を収集し、ネットワーク（サーバ）に向けて送信する。ターゲットサーバはより最適なＷｅｂページコンテンツをクライアントに返すために、受け取った入力を処理し、したがって、ユーザに適切なコンテンツを提示するための対話ステップ（および関連するラウンドトリップ）を最小にする。
【００１６】
本発明の追加部分が、マルチ・パート・メッセージ内のユーザが入れた入力と共に、利用でき関係のあるときには位置情報を追加するクライアント機器を含む。位置情報は、サーバがユーザ入力に対する適切なコンテンツをさらに決定することができるようにし、したがって、インターネットの正しいページを決定するための対話ステップを最小にする。
【００１７】
以下の説明および動作例はＤＮＳ解決、ＴＣＰ−接続確立、およびＨＴＴＰリクエスト／レスポンスなどを結合してラウンドトリップを３から１に低減するが、方法はステップの一部を結合するためにも同様に適用できることに留意されたい。たとえば、ＤＮＳ解決およびＴＣＰ接続確立は、ＨＴＴＰリクエスト／レスポンスを２番目のステップとして残し、１つのステップとして結合されることができ、したがって、ステップの総数を３から２に低減する。同様に、ＴＣＰ接続確立はＨＴＴＰリクエストを送信するステップと結合されることがある。別の組合せも可能であり、本発明の範囲内に入る。
【００１８】
本発明の別の様態が、アプリケーションの起動に対するユーザ入力を収集することに関する。アプリケーションを始動するために、最新技術で使用されるステップは以下を含む。すなわち、ユーザがまずアプリケーションを選択し、アプリケーションが１つまたは複数の選択ウィンドウを提示し、ユーザが１つのウィンドウを選択し、次に、入力ストリームが、選択されたアプリケーションウィンドウに結びつけられる。あるいは、別のオペレーティングシステム（ＯＳ）環境では、ＯＳ構成要素、たとえばシェルが最初の入力キーワードをアプリケーション名に突き合わせ（アプリケーションに対する文字列、またはファイルタイプを突き合わせることによる）、アプリケーションを活動化させる。本発明は、ユーザがまずパラメータを入力し、次に、パラメータを処理する１つまたは複数のアプリケーションを選択する入力を入れるポストフィックス順を提案する。パラメータはもう１つのローカルまたは遠隔のアプリケーションにより処理される。
【００１９】
本発明の別の様態が、ユーザが入れた入力に加えてクライアント機器に関する追加のパラメータを得ることである。そのようなパラメータの例が、ユーザのおおよその位置、時刻、またはユーザプロファイルを含み、ユーザが入れた入力と共にターゲットの遠隔サーバに向けて転送する。
【００２０】
本開示のより完全な理解を容易にするために、ここで、同様の特徴が同様の番号で参照される添付の図面が参照される。これらの図は本開示を限定すると解釈されるべきでなく、例示でしかないことが意図される。
【図面の簡単な説明】
【００２１】
【図１】図１は、代表的移動無線ネットワークである。
【図２】図２は、従来技術で行われるプロトコルシーケンスである。
【図３】図３は、第１の実施形態を表す図である。
【図４ａ】図４ａは、第１の実施形態による第１のプロトコルシーケンスである。
【図４ｂ】図４ｂは、第１の実施形態による第２のプロトコルシーケンスである。
【図５】図５は、第２の実施形態を表す図である。
【図６】図６は、第２の実施形態によるプロトコルシーケンスである。
【図７】図７は、クライアント側ソフトウェアがマルチ・パート・メッセージの内容を決定するために使用するシーケンスを示す図である。
【発明を実施するための形態】
【００２２】
図３は本発明の第１の実施形態を示し、本発明に記載される強化を含む１つまたは複数の機器を有する例示的ネットワーク構成を表す。図１と関連して説明されるこれらの構成要素は、特にことわらない限り同じ機能を有する。この実施形態はインラインプロキシを利用しない。この実施形態では、ユーザ装置（ＵＥ）が、後により詳細に説明されるアプリケーション起動環境（Ａｐｐｌｉｃａｔｉｏｎ  Ｌａｕｎｃｈ  Ｅｎｖｉｒｏｎｍｅｎｔ、ＡＬＥ）を含む。手短に言えば、ＡＬＥは、典型的には多数のメッセージ内に含まれる情報を一度に受け入れることによりラウンドトリップの低減を可能にする。この機能を含む機器またはソフトウェアはこの開示では「ＡＬＥサーバ」と呼ばれる。ＡＬＥサーバはある種の実施形態では関連するソフトウェアを伴う別個のハードウェア構成要素でもよい。別の実施形態では、ＡＬＥサーバはネットワーク内にあらかじめ存在する構成要素上に常駐する単なる専用ソフトウェアである。図３はまたＤＮＳサーバ、アプリケーションサーバ、およびＣＤＮ／キャッシュを含むＡＬＥサーバのためのいくつかの可能な構成を識別する。ＡＬＥサーバと連携して、好ましくはユーザ装置上に位置するクライアント側アプリケーションがある。以下の例でのユーザ機器は、好ましくはスマート携帯電話、または移動無線アクセスカードを備えるラップトップである。
【００２３】
この実施形態において本発明を使用する動作のシーケンスが図４ａおよび図４ｂに示されている。
【００２４】
上記で説明されるように、従来技術の環境では、ユーザがアプリケーションを活動化させ、次に、アプリケーションウィンドウに入力を入れる。本発明では、入力は、入力構文解析とアプリケーション活動化の間の重なりを容易にするために、アプリケーションと関係なく収集される。入力収集および構文解析はＯＳ構成要素（たとえばコマンド・ライン・シェル）、または本発明でアプリケーション起動環境（ＡＬＥ）と呼ばれる新しいアプリケーションクライアントにより行われることができる。ＡＬＥの動作は以下でより詳細に説明される。
【００２５】
本発明では、ユーザは「ｙａｈｏｏ」、「ｙｐ」と入力することがあり、ブラウザアプリケーションを選択する。ＡＬＥクライアント（またはＯＳ構成要素）がこのユーザ入力を収集し、「ｙａｈｏｏ」をｗｗｗ．ｙａｈｏｏ．ｃｏｍとして、および「ｙｐ」をｙａｈｏｏ  Ｗｅｂサイト上の職業別電話帳（ｙｅｌｌｏｗ−ｐａｇｅｓ）として翻訳する。この翻訳は、同じ言葉、キーワード、または文字列を含むＷｅｂサイトを発見するために、最近のブラウジング履歴を参照することにより行われることができる。あるいは、頻繁に使用されるＷｅｂサイトおよび省略形が機器によりブックマークされることができ、入力されたテキストが前にブックマークされたサイトであるかどうかを決定するために参照されることができる。
【００２６】
上記の説明は、クライアント側（ＡＬＥクライアント）が履歴および別の仕組みに基づきユーザ入力をアプリケーションデータに翻訳する一実施形態を詳述するが、別の一実施形態では、クライアント側がデータの一部、たとえば「ｙｐ」をサーバ側（たとえば、ｗｗｗ．ｙａｈｏｏ．ｃｏｍにあるサーバ）に渡すこともでき、サーバが翻訳を行うこともある。したがって、クライアント側はターゲット処理エンティティを決定し、マルチ・パート・メッセージでユーザ入力の一部を渡す。別の適用では、クライアントが、省略されていない入力、たとえば「ｗｗｗ．ｙａｈｏｏ．ｃｏｍ  ｙｅｌｌｏｗ  ｐａｇｅｓ  ｉｅ７」を供給する。
【００２７】
この例では、Ｗｅｂブラウザアプリケーションが選択されるので、ＡＬＥクライアントは、完全な翻訳には、ＤＮＳ解決、ＴＣＰ接続、ＨＴＴＰリクエスト、および追加のアプリケーションデータの送信が必要とされることを認識する（図２に示されるように）。この知識に基づき、ＡＬＥクライアントは以下のうちの１つまたは複数を含むマルチ・パート・メッセージを構築することがある。すなわち、
ａ）ＤＮＳリクエスト、ＤＮＳレスポンスを受け取るためのローカルＵＤＰポート番号、
ｂ）ＴＣＰ  ＳＹＮ（ローカルＴＣＰデータを伴う）、ローカルＴＣＰポート番号、
ｃ）公知のブラウザパラメータを伴うｈｔｔｐ−リクエスト、
ｄ）アプリケーションデータ、たとえば望まれるＷｅｂページ、すなわち「ｙｅｌｌｏｗ−ｐａｇｅｓ」、および
ｅ）任意選択で、クライアント機器のタイプに依存するローカルに利用できる情報。例示的パラメータは、
ａ．移動機器がＧＰＳ能力を有する場合には地理的座標、または移動機器が登録するＢＴＳのおおよその位置、
ｂ．時刻、および
ｃ．ユーザプロファイル
を含んでもよいが、それらに限定されない。
【００２８】
次に、図４ａおよび４ｂのステップ２に示されるように、情報のこの連結が転送される。この情報の受信者は強化ＤＮＳサーバ（マルチ・パート・メッセージに対するソフトウェア強化を伴う従来のＤＮＳサーバである）でも、ＡＬＥサーバと呼ばれる本発明における新しいサーバアプリケーションでもよい。ＡＬＥサーバはＤＮＳサーバ、すなわちアプリケーションサーバ内に、またはプロキシ機器内に配置されることがある論理エンティティであり、これらの機能を実装するために必要なソフトウェアを含む。
【００２９】
ステップ３で、強化ＤＮＳサーバまたはＡＬＥサーバが、マルチ・パート・メッセージを受け取り、ＤＮＳ名前をホストアドレスに解決し、図４ａのステップ３ａに示されるように、元のクライアントにＤＮＳレスポンスを送信する。ステップ４で、強化ＤＮＳサーバまたはＡＬＥサーバが残りのマルチ・パート・メッセージを解決されたホストアドレスに転送する。
【００３０】
ステップ５で、ホストアドレスにあるサーバがＴＣＰ接続データ（ＴＣＰ  ＳＹＮ）、ブラウザパラメータ、およびアプリケーションデータを受け取る。サーバは、マルチ・パート・メッセージの処理を可能にするまたはローカルサーバと通信するＡＬＥサーバを組み入れるソフトウェアを使って強化されることがある。一実施形態では、サーバはＴＣＰ−ＳＹＮ−ＡＣＫを元のクライアントに戻し、ブラウザパラメータおよびアプリケーションデータをｈｔｔｐ−サーバに渡す。
【００３１】
その後ステップ６で、ｈｔｔｐサーバはステップ５で確立された接続上でＨＴＴＰレスポンスを返す。したがって、元のクライアントリクエストはマルチ・パート／マルチ・アプリケーション・メッセージであるが、各アプリケーションが自分自身のレスポンスを元のクライアントに返すことがある。この実施形態では、ＤＮＳレスポンスがＤＮＳサーバにより引き渡され、ＴＣＰ／ＳＹＮ−ＡＣＫがホストアドレスにあるサーバにより返され、ＨＴＴＰレスポンスがｈｔｔｐサーバにより返された。この３つの別個のレスポンスがステップ３、５、および９で図２に示される３つのレスポンスをエミュレートする。
【００３２】
図４ｂに示される別の実施形態では、図４ｂのステップ６に示されるように、サーバ側からのレスポンス（すなわちＤＮＳレスポンス、ＴＣＰ／ＳＹＮ−ＡＣＫ、およびＨＴＴＰレスポンス）がマルチ・パート・メッセージとして結合され、元のサーバに送信される。この代替形態を使って、ステップ４に示されるように、強化ＤＮＳサーバがＤＮＳ名前をホストアドレスに解決し、解決されたホストアドレスにマルチ・パート・メッセージの残りと共にＤＮＳレスポンスを転送する。ホストアドレスにあるサーバがＴＣＰ−ＳＹＮデータを処理し、ＴＣＰ／ＳＹＮ−ＡＣＫを構築し、ブラウザパラメータおよびアプリケーションデータをアプリケーションサーバに転送する。次に、ステップ６で、アプリケーションサーバはＤＮＳレスポンス、ＴＣＰ／ＳＹＮ−ＡＣＫ、およびＨＴＴＰレスポンスを含むマルチ・パート・メッセージを構築し、元のクライアント（ブラウザ）に転送する。
【００３３】
図４ｂの実施形態はレスポンスをマルチ・パート・メッセージとして組み合わせるが、ラウンドトリップ低減はまた、対応するサーバ側アプリケーションにより直接にクライアントにレスポンスが返される、図４ａの前の実施形態でも同様に達成される。この低減は、これらのレスポンスがクライアントとの追加の対話なしにクライアントに送信されるという事実に基づく。したがって、各レスポンスが、クライアントとのどんな追加の通信または対話も待つことなくできるだけすぐにサーバにより送信される。
【００３４】
別の実施形態では、追加のパラメータがＡＬＥクライアントにより生成され、ＡＬＥサーバに渡されることができる。たとえば、ユーザ入力が「ｙａｈｏｏ  ｙｐ  ｐｉｚｚａ  ｉｅ」であり、その入力に対し、ＡＬＥクライアントがマルチ・パート・メッセージを生成すると仮定する。ＡＬＥクライアントはまた追加のクライアント関連パラメータをメッセージで渡すことがある。たとえば、上記のメッセージでは、ユーザが最寄りのピザ店の電話番号を探している可能性が高いので、クライアントの位置が有用な情報を提供することがある。この場合、追加のパラメータ、たとえば「ＧＰＳ座標」も渡されることがある。別の実施形態では、店が特定の日に閉まっている、または時間に制限があることがある。したがって、「ＧＰＳ座標」も「時刻」も含むことが、ＡＬＥサーバに渡す有用なパラメータとなることがある。ユーザ機器に特有の別のパラメータも必要に応じて渡されることがある。
【００３５】
図３および図４に示される実施形態は、追加のソフトウェア機能（ＡＬＥ）がネットワーク内の様々な構成要素に組み入れられると仮定する。別の実施形態では、ＡＬＥサーバの機能を組み入れるインラインプロキシが組み入れられる。具体的には、プロキシは以下に説明されるシーケンスを実装することが必要とされるソフトウェアを有する。
【００３６】
図５は第２の実施形態を示し、インラインプロキシのためのネットワーク構成および代わりの位置を表す。たとえば、３Ｇ／ＵＭＴＳネットワークでは、代わりの位置は、（１）ＲＮＣとＳＧＳＮの間のＩｕＰＳインタフェース、（２）ＳＧＳＮとＧＧＳＮの間のＧｎインタフェース、または（３）ＧＧＳＮとインターネットの間のＧＧＳＮのＧｉインタフェースノースを含む。プロキシは好ましくは、アプリケーション、ＤＮＳ、およびｈｔｔｐサーバへのすべての通信が有線ネットワークを介するように配置される。
【００３７】
図６はインラインプロキシと共に使用されるときのプロトコルシーケンスを示す。まず、すべての前の例のように、ステップ１で、ユーザが「ｙａｈｏｏ」、「ｙｐ」と入力し、ブラウザアプリケーションを選択する。
【００３８】
前の例のように、ＡＬＥクライアントがユーザ入力を収集し、ｙａｈｏｏをｗｗｗ．ｙａｈｏｏ．ｃｏｍと、「ｙｐ」をｙａｈｏｏサイト上の職業別電話帳と翻訳する。前のように、この翻訳は、同じ言葉、キーワード、または文字列を含むウェブサイトを発見するために最近のブラウジング履歴を参照することにより行われることができる。あるいは、頻繁に使用されるＷｅｂサイトおよび省略形が機器によりブックマークされることができ、入力されたテキストが前にブックマークされたサイトであるかどうかを決定するために参照されることができる。
【００３９】
上述のように、Ｗｅｂブラウザが選択されるので、クライアント機器は（ＯＳまたはソフトウェアアプリケーションを介して）ＤＮＳリクエスト、およびＴＣＰ接続を必要とすることを認識する。クライアント機器は以下の構成要素のうちの１つまたは複数を含むマルチ・パート・メッセージを構築する。すなわち、
（ａ）ＵＤＰレスポンスを受け取るためのＵＤＰポート番号と共にＤＮＳリクエスト、
（ｂ）ローカルＴＣＰポート番号と共にＴＣＰ  ＳＹＮ（公知のクライアントデータを伴う）、
（ｃ）公知のブラウザパラメータを伴うｈｔｔｐ−リクエスト、
（ｄ）アプリケーションデータ、たとえば「ｙｅｌｌｏｗ−ｐａｇｅｓ」、および
（ｅ）任意選択で、クライアント機器のタイプに依存するローカルに利用できる情報。例示的パラメータは、
ａ．移動機器がＧＰＳ能力を有する場合には地理的座標、または移動機器が登録するＢＴＳのおおよその位置、
ｂ．時刻、および
ｃ．ユーザプロファイル
を含むが、それらに限定されない。
【００４０】
次に、ステップ２に示されるように、このマルチ・パート・メッセージがプロキシ機器に転送される。
【００４１】
プロキシはＳｐｌｉｔ−ＴＣＰ動作をサポートし、したがって、クライアントへの別個のＴＣＰ接続、およびサーバへの異なるＴＣＰ接続を維持することができ、２つの接続間でパケット転送を行う。
【００４２】
プロキシは（ステップ６に示されるように）デフォルトＤＮＳサーバにＤＮＳクエリを転送する。同時に、ステップ３に示されるように、プロキシはクライアントへのＤＮＳレスポンス（プロキシ自体のホストアドレスを伴う）を生成し、ステップ４に示されるように、クライアントへのＴＣＰ／ＳＹＮ−ＡＣＫを生成する。プロキシはアプリケーションデータをローカルにバッファリングする。プロキシは、ＤＮＳレスポンスおよびＴＣＰ／ＳＹＮ−ＡＣＫをステップ３および４に示されるように別個のレスポンスとして、または単一のメッセージレスポンスとして返す選択肢を有することに留意されたい。両方の実施形態ともクライアントに伴う追加のラウンドトリップを必要としない。
【００４３】
ステップ７で、プロキシはターゲットサーバからＤＮＳレスポンスを受け取り、ステップ８に示されるように、ＤＮＳレスポンスに含まれるホストアドレスへのＴＣＰ接続を開始する。
【００４４】
アプリケーションサーバへのＴＣＰ接続が確立された後、ステップ１１で、プロキシはバッファリングされたアプリケーションデータをアプリケーションサーバ（ＨＴＴＰサーバ）に送信する。
【００４５】
ステップ１２で、アプリケーションサーバはプロキシにＨＴＴＰレスポンスを返し、ステップ１４で、プロキシはクライアントにレスポンスを転送する。
【００４６】
上記の説明は、無線ネットワークと、ＡＬＥサーバに対するアンカポイントの役割を果たす有線ネットワークとの間のインラインプロキシ機器を示す。したがって、インラインプロキシはマルチ・パート・メッセージを終端し、プロキシとホームサーバ（ＤＮＳ、Ｙａｈｏｏなど）の間で標準的プロトコルを使用している。したがって、例は無線ネットワーク上でこの開示で説明される方法を使用してラウンドトリップを低減するが、有線ネットワーク内では従来技術の仕組みを使用する。したがって、意図は、ラウンドトリップ回数が大きい無線アクセスネットワーク上でラウンドトリップを最小にすることである。
【００４７】
換言すれば、図６に示されるプロトコルには多数のラウンドトリップがある。しかし、無線ネットワーク上で発生するラウンドトリップの数は、通信経路内の待ち時間の主要な原因なので、最小化された。この実施形態には、この実施形態では最小量の変更がもたらされるという有利な点がさらにある。たとえば、クライアントおよびプロキシは強化されたＡＬＥ機能を有する必要がある。しかし、ＤＮＳ、アプリケーションサーバ、およびｈｔｔｐサーバは従来技術のプロトコルに従って動作し、それによりネットワーク全体に対する変更を最小限にし、この新技術の採用を促進する。
【００４８】
別の実施形態では、図４ｂに示されるように、上記に概説される方法は有線ネットワーク上でマルチパケットの使用によりさらに強化されることができる。本発明で概説される方法は、前の例のように有線ネットワーク上でマルチ・パート・メッセージを転送することにより有線ネットワーク上で同様に使用されることができる。
【００４９】
上記の例はどれもＤＮＳ、ＴＣＰ、およびアプリケーションデータを含む単一メッセージを送信するクライアントを示すが、クライアントが、必要とされるデータのすべてよりも少ないデータを含むマルチ・パート・メッセージを組み立てることがあることを理解されたい。たとえば、クライアントはＤＮＳおよびＴＣＰの情報を有する第１のメッセージ、およびアプリケーションデータを有する次のメッセージを送信することがある。本発明は、ターゲットが情報を従来引き渡されたよりも少ないメッセージに連結することだけを必要とする。
【００５０】
ＡＬＥ機器の配置だけでなく使用されることができる様々なプロトコルについても説明したが、ＡＬＥモジュールの機能がより詳細に説明される。ローカルのアプリケーション起動環境（ＡＬＥ）では、２つの様態が説明される、すなわち、１）ユーザ入力の収集、および２）多層パケットの生成である。
【００５１】
従来、ユーザが入力を入れるとき、入力はソフトウェア構成要素により構文解析される。たとえば、入力がアクティブなアプリケーションウィンドウ内に書かれた場合、そのソフトウェアアプリケーションが入力を構文解析する。コマンドライン入力の場合、オペレーティングシステム、たとえばｕｎｉｘまたはｌｉｎｕｘが入力を収集し、入力を処理する方法を決定する。そのような１つの例が以下に説明される。
【００５２】
ユーザがｘｙｚｔｅｓｔ１．ｂａｔと入力するとき、．ｂａｔおよびＣＲが入力された後だけ、これが．ｂａｔファイルであることをＯＳは認識し、パス内のファイルを探索し、バッチプロセッサを活動化する。本発明では、入力の収集、構文解析などはＯＳ環境により、またはある程度似ているがバッチプロセッサよりも賢い「アプリケーション起動環境（ＡＥ）クライアント」と名付けられた新しいアプリケーションにより同様の方法で行われることができる。
【００５３】
ＡＬＥクライアントは、入力を収集し、リクエストおよび／またはデータを別のノードに送信する最も効果的方法を決定することにより動作する。たとえば、入力が「ｉｅ７  ｙａｈｏｏ  ｙｐ  Ｍａｒｌｂｏｒｏ  ｒｅｓｔａｕｒａｎｔｓ」である場合、図７に示されるように、本発明は以下のステップを実行する。
【００５４】
まず、ボックス７００に示されるように、アプリケーションがブラウザである（この場合インターネットエクスプローラ）という知識に基づき、クライアントが「ｙａｈｏｏ」を「ｗｗｗ．ｙａｈｏｏ．ｃｏｍ」に（履歴または別のアルゴリズムに基づき）翻訳する。
次に、ボックス７１０に示されるように、アプリケーションがブラウザであり、かつターゲットがｙａｈｏｏサーバであるという知識および履歴に基づき、ＡＬＥクライアントが「ｙｐ」を「ｙｅｌｌｏｗ−ｐａｇｅｓ」に翻訳する。あるいは、ＡＬＥクライアントは、データがｗｗｗ．ｙａｈｏｏ．ｃｏｍにあるターゲットサーバのためのものであることを認識し、生のデータを渡す。別の代替形態では、ＡＬＥクライアントが処理ステップまたはアプリケーションと関連付けなかったユーザ入力を「非関連データ」としてマルチ・パート・メッセージで渡し、非関連データの関連性が明らかになるように、次のサーバが非関連データを構文解析する。
【００５５】
ボックス７２０に示されるように、ＡＬＥクライアントは、Ｗｅｂサイトの場合、ＤＮＳクエリがＤＮＳサーバに送信される必要があることを認識する。ステップ７３０に示されるように、ＡＬＥクライアントはまた、ＴＣＰ接続がＤＮＳサーバにより識別されるアドレスに送信される必要があることを認識するが、そのアドレスはまだ公知ではない。
【００５６】
最後に、ボックス７４０に示されるように、ＡＬＥクライアントは、ｈｔｔｐリクエストがローカルのブラウザパラメータを伴ってアプリケーションサーバに送信される必要があることを認識する。
【００５７】
たとえばブラウザアプリケーションでの従来技術の実装では、図２に示されるように、上記のステップは、アプリケーションが、対応するプロトコルパケットを送信し、次のステップを処理する前にレスポンスを待つことにより、順次処理される。
【００５８】
本発明では、これらのステップは、ＡＬＥソフトウェアアプリケーションによるルックアヘッド処理ステップである。ＡＬＥソフトウェアアプリケーションが入力ストリングを処理するとき、上記のステップを理解する。そのために、ボックス７２０で、ＡＬＥソフトウェアアプリケーションはｗｗｗ．ｙａｈｏｏ．ｃｏｍを伴うＤＮＳクエリパケット、およびレスポンスを受け取るためのローカルのＵＤＰポート番号を構築する。ボックス７３０で、ＡＬＥソフトウェアアプリケーションはＴＣＰ−ＳＹＮパケット（ＤＮＳサーバにより返されるはずの欠けている遠隔ＩＰアドレスを伴う）、およびローカルのＴＣＰポート番号を構築する。ボックス７４０で、ＡＬＥクライアントはＤＮＳまたはＴＣＰデータの知識なしにローカルのブラウザパラメータを伴うｈｔｔｐリクエストを構築する。次に、ＡＬＥクライアントはこれら３つのパケットを各セグメントがＴＬＶパラメータ（タイプ、長さ、値）を含むマルチ・セグメント・パケットとして組み合わせる。別の実施形態では、各セグメントにターゲットプロトコル（またはアプリケーション）を規定する４番目のパラメータが付加されるので、これがＰＴＬＶリストとなる。ＡＬＥはこのマルチ・パート・メッセージをサポートする拡張を有するＤＮＳサーバにこのリクエストを送信する。この機能を可能にするために、追加のＤＮＳサーバ拡張が規定される。あるいは、本発明で「ＡＬＥサーバ」と名付けられる新しいアプリケーションタイプがＤＮＳサーバまたは別の場所、たとえばインラインプロキシ内に常駐する。マルチ・パート・メッセージはＡＬＥサーバに送信される。ＡＬＥサーバは自分の処理ステップをはぎ取り、残りのステップを次のＡＬＥサーバ（または対応するアプリケーションサーバ）に引き渡す。そのために上記の５つのステップについて、以下に示されるように、ＰＴＬＶは３つ以上のＰＴＬＶセグメントを有するメッセージとして構築されることがある。すなわち、
（１）ＤＮＳ、ｄｎｓ−データ−タイプ、長さ、「ｗｗｗ．ｙａｈｏｏ．ｃｏｍ」、（２）ＴＣＰ、接続−データ−タイプ、長さ、「接続パラメータ」、（３）ＨＴＴＰ、ｈｔｔｐ−リクエスト−データ−タイプ、長さ、ブラウザ−パラメータ−データ、（４）任意選択の位置情報−データ−タイプ、長さ、位置データ、（５）任意選択の時刻情報−データ−タイプ、長さ、時刻データ。
【００５９】
上記の例は、Ｗｅｂページがアクセスされるときに生成されるステップおよびメッセージを示すが、同じ方法論が同様に別のアプリケーションに利用されることができる。たとえば、遠隔サーバからのファイル転送、あるいは、電子メールの取り出しまたは送信も本発明を使用して行われることがある。
【００６０】
別の適用が仮想プライベートネットワーク（ＶＰＮ）のユーザである。ユーザがＶＰＮを介して企業ネットワークにアクセスしており、ファイルをダウンロードしていると仮定する。この例では、ＡＬＥクライアントソフトウェアがユーザ入力、たとえばファイル名、適用できる場合にはターゲットディレクトリ／パス、およびアプリケーション名、たとえばＦＴＰ、ＰＰＴを収集し、マルチ・パート・メッセージを構築し、マルチ・パート・メッセージを企業ネットワーク内に配置されるＡＬＥサーバに向けて転送する。次に、ＡＬＥクライアントソフトウェアはローカルのアプリケーションおよびクライアント・プロトコル・エンティティを同時に始動して、マルチ・パート・メッセージに対するレスポンスを受け取る。受け取ると同時に、ＡＬＥサーバソフトウェアはマルチ・パート・メッセージを構文解析し、前の例のようにマルチ・パート・メッセージを対応する受信者に転送する。
【００６１】
別の考慮事項が、ユーザデータが収集され処理される方法である。携帯電話機の環境では、音声通話を開始するために、ユーザが所望の電話番号を入力し、次に、「呼出」ボタンをクリックする。このことは、アプリケーションが活動化される前にアプリケーションデータが入力されるので、本発明では「ポスト・フィックス・アプリケーション起動」と呼ばれる。したがって、音声アプリケーションは、活動化されたときに、前に入れられた入力をパラメータとして使用する。
【００６２】
しかし、Ｗｅｂブラウジングアプリケーションについては、従来技術では、ユーザがＷｅｂブラウザを起動し、Ｗｅｂブラウザが入力ウィンドウを提示して、ＯＳ環境がキーボード入力をブラウザの入力ウィンドウに結びつける。別のＯＳおよびブラウザの環境では、ユーザはブラウザの入力ウィンドウ（たとえばツールバー）をポイントし、次に入力を打ち込む必要がある。入力、たとえばｗｗｗ．ｙａｈｏｏ．ｃｏｍを入れた後、ユーザが異なるブラウザ、たとえばインターネットエクスプローラの代わりにＦｉｒｅＦｏｘを使用したい場合、ユーザは新しいアプリケーションを起動し、次に入力を再度入れなければならない。仕組み、たとえばカット・アンド・ペースト、および別のキーボード／ポインティング機器操作などがユーザのクリックを低減しようとするが、仕組みは携帯電話機器では面倒である。本発明はまた、音声通話起動に類似するポストフィックス型アプリケーション活動化を規定する。
【００６３】
本発明でのポスト・フィックス・アプリケーション活動化法では、ＯＳ構成要素たとえばシェルまたは入力ドライバ、あるいは新しいソフトウェアアプリケーション（ＡＬＥクライアントの一部）が、どのアプリケーションにも関連付けられていない入力を収集する。「ＡＬＥクライアント」はユーザ入力をバッファリングし、音声通話をするのと同様に、アプリケーションが活動化されたときにアプリケーションにユーザ入力を渡す。ＡＬＥクライアントソフトウェアはバッファリングされた入力を処理し、選択されたアプリケーション、自動補完、およびアプリケーション起動のために必要とされる動作に基づきコンテキストを確立する。たとえば、ユーザ入力が「ｙａｈｏｏ」であり、かつ活動化されたアプリケーションがブラウザである場合、ＡＬＥクライアントソフトウェアはＤＮＳルックアップ、ＴＣＰ接続、およびＨＴＴＰリクエストが必要とされることを決定する。あるいは、ＡＬＥクライアントソフトウェアが、活動化されたアプリケーションに、バッファリングされた入力を渡し、活動化されたアプリケーションが入力を構文解析し、必要とされるステップ、たとえばＤＮＳルックアップ、ＴＣＰ接続、およびＨＴＴＰリクエストなどを決定する。この後者の方法は、各リクエストを発行し、かつ次のステップに進む前にレスポンスを待つことなく、ステップを並行して処理するためのアプリケーション（たとえば、Ｗｅｂブラウザ）を必要とする。
【００６４】
上述のポストフィックス法は、入力プロセッサが前に入力された非関連入力を保存し、かつ起動された次のアプリケーションに渡すことにより、多数のアプリケーションに対して同じ入力を渡すことを容易にする。
【００６５】
本発明で規定されるポストフィックス起動法は、別の宛先に同じ１組のアプリケーションパラメータを送信すること（ユーザが各アプリケーションに対してパラメータを入力する、または最初にアプリケーションを活動化させ、次に各アプリケーションに対してパラメータを入力することなく）、または同じパラメータおよび異なるローカルアプリケーションを同じ宛先に送信することを容易にする。たとえば、コマンド
Ｙａｈｏｏ、ｙｅｌｌｏｗ−ｐａｇｅｓ、ｒｅｓｔａｕｒａｎｔｓ、（ＩＥ７、ＦｉｒｅＦｏｘ）
が２つのマルチ・パート・メッセージを、すなわちＩＥ７ブラウザパラメータを伴う第１のパケット、およびＦｉｒｅＦｏｘパラメータを伴う第２のパケットを生成し、ホームサーバ（またはプロキシ）がクライアントへの２つの接続を確立することになることがあり、したがって、ユーザが、異なるターゲット・サーバまたはクライアントアプリケーションを使って同じ目標を達成する際に実行しなければならない連続したステップを低減する。
【００６６】
本明細書において記載されるすべてのアプリケーションおよびソフトウェアは、コンピュータ読出可能媒体上に含まれるコンピュータ実行可能命令である。たとえば、ソフトウェアおよびアプリケーションは読出し専用メモリ内に、書換可能メモリ内に、または組込処理装置内部に保存されることがある。このソフトウェアが実行する具体的コンピュータはアプリケーションに依存し、本発明により限定されない。
【図１】
0005481481.tif 000002
【図２】
0005481481.tif 000003
【図３】
0005481481.tif 000004
【図４ａ】
0005481481.tif 000005
【図４ｂ】
0005481481.tif 000006
【図５】
0005481481.tif 000007
【図６】
0005481481.tif 000008
【図７】
0005481481.tif 000009