アプリケーションサーバにより調停されている通信セッションの間に、アクセス端末からデータを送信する方法であって、前記アクセス端末が、第1の機能層、第2の機能層、および第3の機能層を含み、前記方法が、前記第3の機能層において、前記通信セッションの間に、前記アプリケーションサーバにデータパケットを送信することを決定するステップと、前記第1の機能層によって、前記アプリケーションサーバに転送されるべき前記データパケットを、サービングアクセスネットワークに送信するステップと、前記第1の機能層によって、前記サービングアクセスネットワークによる前記送信されたデータパケットの受信を確認する、前記送信されたデータパケットに対する第1の確認応答を、受信するステップと、前記第1の確認応答に応答して、かつ前記第1の機能層によって、前記データパケットの前記サービングアクセスネットワークへの送信が成功したことを、前記第3の機能層に通知するステップと、を含む、方法。前記第1の機能層が物理層またはメディアアクセス制御層と関連付けられ、前記第2の機能層がトランスポート層と関連付けられ、前記第3の機能層がアプリケーション層と関連付けられる、請求項1に記載の方法。前記第3の機能層によって、前記アプリケーションサーバによる前記送信されたデータパケットの受信を確認する、前記送信されたデータパケットに対する第2の確認応答を、受信するステップをさらに含む、請求項1に記載の方法。アプリケーションサーバにより調停されている通信セッションの間に、アクセス端末からデータを送信する方法であって、前記アクセス端末が、第1の機能層、第2の機能層、および第3の機能層を含み、前記方法が、前記第3の機能層において、前記通信セッションの間に、前記アプリケーションサーバにデータパケットを送信することを決定するステップと、前記第1の機能層によって、前記アプリケーションサーバに転送されるべき前記データパケットを、サービングアクセスネットワークに送信しようと試みるステップと、前記第1の機能層によって、前記サービングネットワークへの前記データパケットの送信の前記試みが失敗したと、判定するステップと、前記失敗の判定に応答して、かつ前記第1の機能層によって、前記データパケットの前記サービングアクセスネットワークへの送信が成功しなかったことを、前記第3の機能層に通知するステップと、を含む、方法。前記第1の機能層が物理層またはメディアアクセス制御層と関連付けられ、前記第2の機能層がトランスポート層と関連付けられ、前記第3の機能層がアプリケーション層と関連付けられる、請求項4に記載の方法。通信システムにおいてファイル転送セッションをセットアップする方法であって、前記ファイル転送セッションの間に用いられることになる、トラフィックチャネルのためのセットアップ手順を開始するステップと、前記ファイル転送セッションと関連付けられたアプリケーション層接続およびトランスポート層接続をセットアップするために、アプリケーション層データおよびトランスポート層データによってメッセージを構成するステップと、前記TCHセットアップ手順が完了する前に、前記構成されたメッセージを、シグナリングポートを介してアプリケーションサーバに送信するステップと、前記構成されたメッセージが送信された後、前記TCHセットアップ手順を完了するステップと、前記構成されたメッセージの前記送信に応答して、前記アプリケーションサーバからの応答メッセージを、データポートを通じて受信するステップと、前記ファイル転送セッションの間に、前記TCHを介し前記データポートを通じて、1つまたは複数のファイルを前記アプリケーションサーバに送信するステップとを含む、方法。前記構成されたメッセージがDataoverSignalingメッセージに相当し、前記シグナリングポートがDoSポートに相当する、請求項6に記載の方法。通信システムにおいて第1のアクセス端末と第2のアクセス端末との間でデータを交換する方法であって、前記第1のアクセス端末と前記第2のアクセス端末との間で、第1のタイプの通信セッションと関連付けられた高優先度のデータ、さらに、第2のタイプの通信セッションと関連付けられた低優先度のデータを交換するステップであって、前記第1のタイプの前記通信セッションおよび前記第2のタイプの前記通信セッションが、アプリケーションサーバによって調停される、ステップと、前記第1のアクセス端末の、データ速度の低い環境への移行を判定するステップと、前記判定に応答して、前記第2のタイプの前記通信セッションのために、前記第1のアクセス端末と前記アプリケーションサーバとの間で交換される、データパケットのサイズを低減するステップとを含む、方法。前記交換するステップ、前記判定するステップ、および前記低減するステップが各々、前記第1のアクセス端末によって実行される、請求項8に記載の方法。前記低減するステップが、前記第1のアクセス端末によって逆方向リンクで前記アプリケーションサーバに送信される、前記データパケットの前記サイズを低減する、請求項9に記載の方法。前記交換するステップ、前記判定するステップ、および前記低減するステップが各々、前記アプリケーションサーバによって実行される、請求項8に記載の方法。前記低減するステップが、前記アプリケーションサーバによってダウンリンクで前記第1のアクセス端末に送信される、前記第2のアクセス端末から受信される前記データパケットの前記サイズを低減する、請求項11に記載の方法。通信システムにおいて第1のアクセス端末と第2のアクセス端末との間でデータを交換する方法であって、前記第1のアクセス端末と前記第2のアクセス端末との間で、第1のタイプの通信セッションと関連付けられた高優先度のデータ、さらに、第2のタイプの通信セッションと関連付けられた低優先度のデータを交換するステップであって、前記第1のタイプの前記通信セッションおよび前記第2のタイプの前記通信セッションが、アプリケーションサーバによって調停される、ステップと、前記第1のタイプの前記通信セッションのために、前記第1のアクセス端末から前記第2のアクセス端末に、次に来るタイムスロットで送られることになる第1のデータパケットが、所与のタイプのデータの少ないパケットに相当すると、判定するステップと、前記次に来るデータパケットの送信を圧縮するステップと、前記第1のアクセス端末からの第2のデータパケットを、前記第1のデータパケットの代わりに、前記次に来るタイムスロットの中で、前記第2のタイプの前記通信セッションのための前記第2のアクセス端末に送信するステップとを含む、方法。前記交換するステップ、前記判定するステップ、前記圧縮するステップ、および前記スケジューリングするステップが各々、前記第1のアクセス端末によって実行される、請求項13に記載の方法。前記送信するステップが、前記第1のアクセス端末による、前記アプリケーションサーバへの、逆方向リンクでの前記第2のデータパケットの送信に相当する、請求項14に記載の方法。前記交換するステップ、前記判定するステップ、前記圧縮するステップ、および前記スケジューリングするステップが各々、前記アプリケーションサーバによって実行される、請求項13に記載の方法。前記送信するステップが、前記アプリケーションサーバによってダウンリンクで前記第2のアクセス端末に送信される、前記第1のアクセス端末から受信された前記第2のデータパケットの送信に相当する、請求項16に記載の方法。通信システムにおいて第1のアクセス端末と第2のアクセス端末との間でデータを交換する方法であって、前記第1のアクセス端末から発信され、アプリケーションサーバによって調停されているファイル転送セッションと関連して前記第2のアクセス端末に宛てられる、データパケットのシーケンスを送信するステップと、前記第1のアクセス端末が、前記シーケンスの中の最後のデータパケットまたは最後に近いデータパケットのセットの送信を試みたと、判定するステップと、前記シーケンスの中の最後のデータパケットまたは最後に近いデータパケットのセットの送信を最初に試みた後、前記第2のアクセス端末が、前記シーケンスの中の最後のデータパケットまたは最後に近いデータパケットの前記セットの送信の前記最初の試みの受信に対して確認応答するのを待機することなく、前記シーケンスの中の最後のデータパケットまたは最後に近いデータパケットの前記セットを再送信するステップとを含む、方法。前記送信するステップ、前記判定するステップ、および前記再送信するステップが各々、前記第1のアクセス端末によって実行される、請求項18に記載の方法。前記送信するステップが、前記第1のアクセス端末による、前記アプリケーションサーバへの、逆方向リンクでのデータパケットの前記シーケンスの送信に相当する、請求項19に記載の方法。前記送信するステップ、前記判定するステップ、および前記再送信するステップが各々、前記アプリケーションサーバによって実行される、請求項18に記載の方法。前記送信するステップが、前記アプリケーションサーバによってダウンリンクで前記第2のアクセス端末に送信される、前記第1のアクセス端末から受信されたデータパケットの前記シーケンスの送信に相当する、請求項21に記載の方法。アクセス端末にオブジェクトをダウンロードする方法であって、複数のオブジェクトを前記アクセス端末にダウンロードすることを決定するステップと、前記アクセス端末によって目立つように表示されている、少なくとも1つの現在のアクティブウィンドウを特定するステップと、前記アクセス端末によって目立つように表示されていない1つまたは複数のウィンドウと関連付けられる前記複数のオブジェクトの第2のセットよりも、前記少なくとも1つの現在のアクティブウィンドウと関連付けられる前記複数のオブジェクトの第1のセットに対してより高い優先順位を示す、前記複数のオブジェクトに対する1つまたは複数の要求を構成するステップと、前記複数のオブジェクトのための、前記1つまたは複数の構成された要求を送信するステップとを含む、方法。前記1つまたは複数の構成された要求が、前記複数のオブジェクトのダウンロード元となるアプリケーションサーバに送信される、請求項23に記載の方法。前記1つまたは複数の構成された要求が、前記複数のオブジェクトの送信元となる別のアクセス端末に送信される、請求項23に記載の方法。前記複数のオブジェクトの前記第1のセットを、前記複数のオブジェクトの前記第2のセットよりも優先する、ダウンロード順序に従って、前記複数のオブジェクトをダウンロードするステップをさらに含む、請求項23に記載の方法。前記少なくとも1つの現在のアクティブウィンドウが、前記アクセス端末によってもはや目立つように表示されていないことを、前記ダウンロードするステップの間に検知するステップと、前記検知に応答して、前記複数のオブジェクトの前記第1のセットに対してより低い優先順位を示す、1つまたは複数の補助メッセージを構成するステップと、前記構成された1つまたは複数の補助メッセージを送信するステップと、前記複数のオブジェクトの前記第1のセットを、前記複数のオブジェクトの前記第2のセットよりも優先しない、別のダウンロード順序に従って、前記複数のオブジェクトのダウンロードを続けるステップとをさらに含む、請求項26に記載の方法。現在、少なくとも1つの追加のウィンドウが、前記アクセス端末によって目立つように表示されていることを、前記ダウンロードするステップの間に検知するステップと、前記検知に応答して、前記少なくとも1つの追加のウィンドウと関連付けられる前記複数のオブジェクトの前記第3のセットに対してより高い優先順位を示す、1つまたは複数の補助メッセージを構成するステップと、前記構成された1つまたは複数の補助メッセージを送信するステップと、前記複数のオブジェクトの前記第3のセットに高い優先順位を割り当てる、別のダウンロード順序に従って、前記複数のオブジェクトのダウンロードを続けるステップとをさらに含む、請求項26に記載の方法。アクセス端末にオブジェクトをダウンロードする方法であって、ユーザ規定のオブジェクトのダウンロードの優先順位のセットを確立するステップと、ユーザ規定のオブジェクトのダウンロードの優先順位の前記セットが確立された後、複数のオブジェクトを前記アクセス端末にダウンロードすると決定するステップと、ユーザ規定のオブジェクトのダウンロードの優先順位の前記セットを示すものとともに、前記複数のオブジェクトに対する1つまたは複数の要求を構成するステップと、前記複数のオブジェクトのための、前記1つまたは複数の構成された要求を送信するステップと、ユーザ規定のオブジェクトのダウンロードの優先順位の前記セットに従って、前記複数のオブジェクトを受信するステップとを含む、方法。ユーザ規定のオブジェクトのダウンロードの優先順位の前記セットが、アプリケーションの第2のセットに関連してダウンロードされたオブジェクトよりも、アプリケーションの第1のセットに関連してダウンロードされたオブジェクトに対して、より高い優先順位を割り当てることに相当する、請求項29に記載の方法。前記構成された1つまたは複数の補助メッセージが、アプリケーションサーバに送信され、前記アクセス端末が、前記複数のオブジェクトを受信している複数のアクセス端末の1つであり、前記アプリケーションサーバが、前記複数のアクセス端末の2つ以上からのユーザ規定のオブジェクトのダウンロードの優先順位のセットに基づいて、前記複数のアクセス端末に前記複数のオブジェクトを供給するように構成される、請求項29に記載の方法。通信システムにおいて第1のアクセス端末と第2のアクセス端末との間でデータを交換する方法であって、前記第1のアクセス端末において、前記第2のアクセス端末から、ストリーミング通信セッションとともにデータを受信するステップであって、前記第1のアクセス端末のディスプレイのウィンドウの第1のセットがアクティブである間に、かつまたは前記ディスプレイ上に目立つように表示されている間に、前記データが受信される、ステップと、前記第1のアクセス端末の前記ディスプレイの、ウィンドウの前記第1のセットからウィンドウの第2のセットへの移行を検知するステップと、前記検知された移行に基づいて、ウィンドウの前記第1のセットと関連付けられる前記ストリーミング通信セッションの一部の、優先順位を下げるための要求を送信するステップとを含む、方法。ウィンドウの前記第1のセットが、前記ストリーミング通信セッションの映像部分と関連付けられ、前記検知された移行が、前記第1のアクセス端末が、前記ストリーミング通信セッションの前記映像部分をもはや表示していないことを検知することに相当し、優先順位を下げるための前記送信された要求が、前記ストリーミング通信セッションの前記映像部分が受信される速度を下げるための要求、または、前記ストリーミング通信セッションの前記映像部分の受信を停止するための要求に相当する、請求項32に記載の方法。前記第1のアクセス端末の前記ディスプレイの、ウィンドウの前記第1のセットに戻る移行を検知するステップと、ウィンドウの前記第1のセットへの前記検知された戻る移行に基づいて、ウィンドウの前記第1のセットと関連付けられる前記ストリーミング通信セッションの前記一部を、再優先順位付けするための要求を送信するステップとをさらに含む、請求項32に記載の方法。通信システムにおいて第1のアクセス端末と第2のアクセス端末との間でデータを交換する方法であって、前記第1のアクセス端末と前記第2のアクセス端末との間でストリーミング通信セッションを調停するアプリケーションサーバから、前記第1のアクセス端末に、データを送信するステップと、前記第1のアクセス端末から、前記ストリーミング通信セッションの一部の優先順位を下げるための要求を受信するステップと、前記優先順位を下げる要求に従って、前記第1のアクセス端末に送信されている前記データを修正するステップとを含む、方法。前記ストリーミング通信セッションの前記一部が、映像部分に相当し、前記修正するステップが、前記ストリーミング通信セッションの少なくとも音声部分の送信を続ける、請求項35に記載の方法。前記修正するステップが、前記データの前記一部が前記第1のアクセス端末に送信される速度を下げる、請求項35に記載の方法。前記第1のアクセス端末から、前記ストリーミング通信セッションの前記一部を再優先順位付けするための要求を受信するステップと、前記一部が前記修正の前に前記第1のアクセス端末に送信された方式に従って、前記ストリーミング通信セッションの前記一部の送信を再開するステップとをさらに含む、請求項35に記載の方法。アクセス端末にオブジェクトをダウンロードする方法であって、複数のオブジェクトを前記アクセス端末にダウンロードすることを決定するステップと、前記アクセス端末にダウンロードされることになる前記複数のオブジェクトに対して制限された環境で、前記アクセス端末が動作していると、判定するステップと、前記アクセス端末が前記制限された環境で動作していることを示すものによって、前記複数のオブジェクトのための1つまたは複数の要求を構成するステップと、前記複数のオブジェクトのための、前記1つまたは複数の構成された要求を送信するステップと、前記1つまたは複数の送信された要求に応答して、前記複数のオブジェクトの変更されたバージョンを受信するステップであって、前記複数のオブジェクトの前記変更されたバージョンが、前記アクセス端末の前記制限された環境に順応するように変更される、ステップとを含む、方法。前記アクセス端末にダウンロードされることになる前記複数のオブジェクトに対する前記制限された環境で、前記アクセス端末が動作しているという前記判定が、前記複数のオブジェクトを前記アクセス端末に提供するアプリケーションサーバから受信される、接続品質インジケータに基づく、請求項39に記載の方法。前記複数のオブジェクトの前記変更されたバージョンが受信された後、前記複数のオブジェクトの1つまたは複数の変更されていないバージョンを受信するステップをさらに含む、請求項39に記載の方法。前記複数のオブジェクトの前記変更されていないバージョンの前記受信が、前記複数のオブジェクトの前記変更されたバージョンの、前記アクセス端末における受信が完了したこと、前記アクセス端末が制限されない環境へ入ったこと、およびまたは、前記アクセス端末における前記複数のオブジェクトの前記変更されたバージョンの前記受信から、閾値の時間が経過したことにより、引き起こされる、請求項41に記載の方法。アクセス端末にオブジェクトをダウンロードする方法であって、前記アクセス端末にダウンロードされることになる複数のオブジェクトに対する制限された環境で、前記アクセス端末が動作しているということを示すものとともに、前記複数のオブジェクトのダウンロードのための1つまたは複数の要求を、前記アクセス端末から受信するステップと、前記1つまたは複数の受信された要求に応答して、前記複数のオブジェクトの変更されたバージョンを生成するために、前記アクセス端末の前記制限された環境に順応するように、前記複数のオブジェクトを変更するステップと、前記複数のオブジェクトの前記変更されたバージョンを、前記アクセス端末に送信するステップとを含む、方法。前記複数のオブジェクトの前記変更されたバージョンが送信された後、前記複数のオブジェクトの1つまたは複数の変更されていないバージョンを送信するステップをさらに含む、請求項43に記載の方法。前記複数のオブジェクトの前記変更されていないバージョンの前記送信が、前記複数のオブジェクトの前記変更されたバージョンの、前記アクセス端末への送信が完了したこと、前記アクセス端末が制限されない環境へ入ったこと、およびまたは、前記アクセス端末への前記複数のオブジェクトの前記変更されたバージョンの前記送信から、閾値の時間が経過したことにより、引き起こされる、請求項44に記載の方法。請求項1、4、6、8、13、18、23、29、32、35、39または43による方法を実行するための手段を含む、通信装置。請求項1、4、6、8、13、18、23、29、32、35、39または43による方法をコンピュータに実行させるための、少なくとも1つの命令を記録する、コンピュータ可読記録媒体。ある実施形態では、アクセス端末は、少なくとも第1、第2、および第3の機能層を含み、第1の機能層は、第3の機能層の代わりに、サービングネットワークを介して、データパケットをアプリケーションサーバへ送信することを試みる。サービングネットワークがデータパケットを受信したというACKを第1の機能層が受信すると、第3の機能層はACKを通知される。サービングネットワークへのデータパケットの送信の試みが失敗したと、第1の機能層が判定すると、第3の機能層は送信の失敗を通知される。別の実施形態では、通信セッションのためのトラフィックチャネルのセットアップの間、アクセス端末は、アプリケーション層接続情報とトランスポート層接続情報の両方を含むメッセージを、シグナリングポートを通じてアプリケーションサーバに送信し、通信セッションのためのデータポートのセットアップを容易にする。ある実施形態では、通信デバイスは、第1のアクセス端末と第2のアクセス端末の間で、第1のタイプの通信セッションと関連付けられる高優先度のデータを、さらに第2のタイプの通信セッションと関連付けられる低優先度のデータを、交換する。第1のアクセス端末がデータ速度の低い環境へ移行したと、通信デバイスが判定すると、通信デバイスは、第2のタイプの通信セッションのために第1のアクセス端末とアプリケーションサーバとの間で交換される、データパケットのサイズを低減する。次に来るデータパケットがデータの少ないパケットであると通信デバイスが判定すると、データの少ないパケットは圧縮される。第1のアクセス端末が、シーケンスの中で最後のデータパケットまたは最後に近いデータパケットのセットの送信を試みたと、通信デバイスが判定すると、通信デバイスは、ACKを待機することなく、最後のデータパケットまたは最後に近いデータパケットのセットを再送信する。ある実施形態では、どのウィンドウがATに目立つように表示されるかに基づいて、オブジェクトがアクセス端末にダウンロードされる。別の実施形態では、ユーザ規定のオブジェクトのダウンロード優先順位のセットに基づいて、オブジェクトがATにダウンロードされる。別の実施形態では、ストリーミングデータセッションと関連付けられるウィンドウの第1のセットから、異なるセッションと関連付けられるウィンドウの第2のセッションへの、ATのディスプレイの移行に応答して、ATへのストリーミングデータセッションの一部が優先順位を下げられる。たとえば、優先順位の低下により、一部が省略されまたは減らされることになり得る。別の実施形態では、ATが制限された環境に入ったことに応答して、ATにダウンロードされるオブジェクトが、ATの制限された環境と順応するように動的に変更され得る。本発明の実施形態およびその付随する利点の多くのより完全な理解は、以下の発明を実施するための形態を参照し、本発明を限定するためではなく単に例示するために提示する添付の図面とともに考察することによってより良く理解されれば、容易に得られるであろう。本発明の特定の実施形態を対象とする以下の説明および関連する図面で、本発明の態様を開示する。本発明の範囲から逸脱することなく、代替的な実施形態を考案することができる。さらに、本発明の関連する詳細を不明瞭にしないように、本発明のよく知られている要素は、詳細に説明されず、または省略される。例示的およびまたは例という用語は、本明細書では例、事例、または例示として機能することを意味するために使用される。本明細書で例示的およびまたは例として説明するいかなる実施形態も、必ずしも他の実施形態よりも好ましいまたは有利であると解釈すべきではない。同様に、本発明の実施形態という用語は、本発明のすべての実施形態が論じられた特徴、利点または動作モードを含むことを必要としない。さらに、多くの実施形態は、たとえば、コンピューティングデバイスの要素によって実行すべき一連のアクションに関して説明される。本明細書で説明する様々なアクションは、特定の回路によって、1つもしくは複数のプロセッサによって実行されるプログラム命令によって、または両方の組合せによって実行できることを認識されよう。さらに、本明細書で説明するこれらの一連のアクションは、実行時に、関連するプロセッサに本明細書で説明する機能を実行させる、コンピュータ命令の対応するセットを記憶した、任意の形式のコンピュータ可読記憶媒体内で、全体が具現化されるべきものと見なすことができる。したがって、本発明の様々な態様は、すべてが請求する主題の範囲内に入ることが企図されているいくつかの異なる形式で具現化できる。さらに、本明細書で説明する実施形態ごとに、任意のそのような実施形態の対応する形式を、たとえば、記載のアクションを実行するように構成された論理として本明細書で説明することがある。本明細書でアクセス端末と呼ぶ高データレート加入者局は、移動式でも固定式でもよく、本明細書でモデムプールトランシーバまたは基地局と呼ぶ1つまたは複数のHDR基地局と通信することができる。アクセス端末は、1つまたは複数のモデムプールトランシーバを介して、モデムプールコントローラ、基地局コントローラおよびまたはパケット制御機能と呼ばれるHDR基地局コントローラとの間で、データパケットを送信および受信する。モデムプールトランシーバおよびモデムプールコントローラは、アクセスネットワークと呼ばれるネットワークの一部である。アクセスネットワークは、複数のアクセス端末間でデータパケットをトランスポートする。アクセスネットワークは、企業イントラネットまたはインターネットなど、アクセスネットワークの外部の追加のネットワークにさらに接続されてよく、各アクセス端末とそのような外部のネットワークとの間でデータパケットをトランスポートし得る。1つまたは複数のモデムプールトランシーバとのアクティブトラフィックチャネル接続を確立したアクセス端末は、アクティブアクセス端末と呼ばれ、トラフィック状態にあると言われる。1つまたは複数のモデムプールトランシーバとのアクティブトラフィックチャネル接続を確立中であるアクセス端末は、接続セットアップ状態にあると言われる。アクセス端末は、ワイヤレスチャネルを介して、または、たとえば光ファイバまたは同軸ケーブルを使用する有線チャネルを介して通信する、任意のデータデバイスであり得る。アクセス端末はさらに、限定はしないが、PCカード、コンパクトフラッシュ、外部または内部モデム、またはワイヤレス電話もしくは有線電話を含む、いくつかのタイプのデバイスのいずれかであり得る。アクセス端末が信号をモデムプールトランシーバに送信するための通信リンクは、逆方向リンクまたは逆方向トラフィックチャネルと呼ばれる。モデムプールトランシーバが信号をアクセス端末に送信するための通信リンクは、順方向リンクまたは順方向トラフィックチャネルと呼ばれる。本明細書で使用するトラフィックチャネルという用語は、順方向トラフィックチャネルまたは逆方向トラフィックチャネルのいずれかを指すことができる。図1に、本発明の少なくとも1つの実施形態によるワイヤレスシステム100の例示的な一実施形態のブロック図を示す。システム100は、アクセス端末102をネットワーク機器に接続して、パケット交換データネットワークとアクセス端末102、108、110、112との間にデータ接続性を与えることができる、アクセスネットワークまたは無線アクセスネットワーク120とエアインターフェース104を介して通信している、セルラー電話102などのアクセス端末を含むことができる。本明細書に示すように、アクセス端末は、携帯電話102、携帯情報端末108、本明細書に双方向テキストページャとして示すページャ110、さらにはワイヤレス通信ポータルを有する別個のコンピュータプラットフォーム112であり得る。したがって、本発明の実施形態は、ワイヤレスモデム、PCMCIAカード、パーソナルコンピュータ、電話、またはそれらの任意の組合せもしくは部分的な組合せを限定することなく含む、ワイヤレス通信ポータルを含むか、またはワイヤレス通信機能を有する任意の形態のアクセス端末上で実現され得る。さらに、本明細書で使用するアクセス端末、ワイヤレスデバイス、クライアントデバイス、モバイル端末という用語およびそれらの変形体は、互換的に使用され得る。再び図1を参照すると、ワイヤレスネットワーク100の構成要素および本発明の例示的な実施形態の要素の相互関係は、図示の構成に制限されない。システム100は、例示的なものにすぎず、ワイヤレスクライアントコンピューティングデバイス102、108、110、112などの遠隔アクセス端末が、互いに、かつまたは、キャリアネットワーク126、インターネットおよびもしくは他のリモートサーバを限定なしに含む、エアインターフェース104およびRAN120を介して接続された構成要素との間で、無線で通信することを可能にする任意のシステムを含むことができる。RAN120は、基地局コントローラパケット制御機能122に送信されるメッセージを制御する。BSCPCF122は、パケットデータサービスノード100とアクセス端末102108110112との間のベアラチャネルのシグナリング、確立および切断を担う。リンク層の暗号化が使用可能である場合、BSCPCF122はまた、エアインターフェース104を介してコンテンツを転送する前にそのコンテンツを暗号化する。BSCPCF122の機能は当技術分野でよく知られており、簡潔のためにさらに論じない。キャリアネットワーク126は、ネットワーク、インターネットおよびまたは公衆交換電話網によってBSCPCF122と通信することができる。代替的に、BSCPCF122はインターネットまたは外部ネットワークに直接接続することができる。一般に、キャリアネットワーク126とBSCPCF122との間のネットワークまたはインターネット接続はデータを転送し、PSTNは音声情報を転送する。BSCPCF122は複数の基地局またはモデムプールトランシーバ124に接続され得る。キャリアネットワークと同様の方法で、BSCPCF122は一般に、データ転送およびまたは音声情報のために、ネットワーク、インターネットおよびまたはPSTNによってMPTBS124に接続される。MPTBS124は、携帯電話102などのアクセス端末にデータメッセージをワイヤレスにブロードキャストすることができる。MPTBS124、BSCPCF122および他の構成要素は、当技術分野で知られているように、RAN120を形成することができる。ただし、代替構成も使用でき、本発明は、図示の構成に制限されない。たとえば、別の実施形態では、BSCPCF122の機能とMPTBS124の1つまたは複数とを、BSCPCF122とMPTBS124の両方の機能を有する単一のハイブリッドモジュールに縮小することができる。図2Aに、本発明の一実施形態によるキャリアネットワーク126を示す。図2Aの実施形態では、キャリアネットワーク126は、パケットデータサービングノード160と、ブロードキャストサービングノード165と、アプリケーションサーバ170と、インターネット175とを含む。ただし、代替実施形態では、アプリケーションサーバ170および他の構成要素はキャリアネットワークの外部に位置してもよい。PDSN160は、たとえば、cdma2000の無線アクセスネットワークを利用して、インターネット175、イントラネットおよびまたはリモートサーバへのアクセスを移動局に与える。アクセスゲートウェイとして働くので、PDSN160は、単純IPおよびモバイルIPアクセス、外部エージェントサポート、およびパケットトランスポートを与えることができる。当技術分野で知られているように、PDSN160は、認証、認可、および課金サーバおよび他のサポートインフラストラクチャのクライアントとして働くことができ、IPネットワークへのゲートウェイを移動局に与える。図2Aに示すように、PDSN160は、従来のA10接続を介してRAN120と通信し得る。A10接続は当技術分野でよく知られており、簡潔のためにさらに説明しない。図2Aを参照すると、ブロードキャストサービングノード165は、マルチキャストおよびブロードキャストサービスをサポートするように構成され得る。BSN165について、以下でより詳細に説明する。BSN165は、ブロードキャストA10接続を介してRAN120と通信し、インターネット175を介してアプリケーションサーバ170と通信する。BCA10接続は、マルチキャストおよびまたはブロードキャストメッセージングを転送するために使用される。したがって、アプリケーションサーバ170は、インターネット175を介してユニキャストメッセージングをPDSN160に送信し、インターネット175を介してマルチキャストメッセージングをBSN165に送信する。一般に、以下でより詳細に説明するように、RAN120は、BCA10接続を介してBSN165から受信されたマルチキャストメッセージを、エアインターフェース104のブロードキャストチャネルを介して、1つまたは複数のアクセス端末200に送信する。図2Bに、図1のワイヤレス通信の例100をより詳細に示す。特に、図2Bを参照すると、AT1Nは、異なるパケットデータネットワークエンドポイントによってサービスされる位置において、RAN120に接続するものとして示されている。したがって、AT1およびAT3は、、外部エージェントなどに対応し得る第1のパケットデータネットワークエンドポイント162によってサービスされる部分において、RAN120に接続する。第1のパケットデータネットワークエンドポイント162は、今度はルーティングユニット188を介して、インターネット175に、ならびにまたは、認証、認可および課金サーバ182、プロビジョニングサーバ184、インターネットプロトコルマルチメディアサブシステムセッション開始プロトコル登録サーバ186およびもしくはアプリケーションサーバ170のうちの1つまたは複数に、接続する。AT2およびAT5Nは、第2のパケットデータネットワークエンドポイント164によってサービスされる部分において、RAN120に接続する。第1のパケットデータネットワークエンドポイント162と同様に、第2のパケットデータネットワークエンドポイント164は、今度はルーティングユニット188を介して、インターネット175に、ならびにまたは、AAAサーバ182、プロビジョニングサーバ184、IMSSIP登録サーバ186およびもしくはアプリケーションサーバ170のうちの1つまたは複数に、接続する。AT4は、インターネット175に直接接続し、次いで、インターネット175を通して、上記で説明したシステム構成要素のうちのいずれかに接続することができる。図2Bを参照すると、AT1、AT3およびAT5Nはワイヤレス携帯電話として示され、AT2はワイヤレスタブレットPCとして示され、AT4は有線のデスクトップ局として示されている。しかし、別の実施形態では、ワイヤレス通信システム100は任意のタイプのATに接続でき、図2Bに示される例は、システム内に実装され得るATのタイプを限定することは意図しないことを、理解されたい。また、AAAサーバ182、プロビジョニングサーバ184、IMSSIP登録サーバ186、およびアプリケーションサーバ170はそれぞれ、構造的に別のサーバとして示されているが、本発明の少なくとも1つの実施形態において、これらのサーバのうちの1つまたは複数は、統合されていてもよい。さらに、図2Bを参照すると、アプリケーションサーバ170は、複数のメディア制御コンプレックス1N170Bと複数の地域ディスパッチャ1N170Aとを含むものとして示されている。集合的に、地域ディスパッチャ170AおよびMCC170Bは、少なくとも1つの実施形態では、ワイヤレス通信システム100内の通信セッションを調停するように集合的に機能するサーバの分散型ネットワークに相当し得る、アプリケーションサーバ170内に含まれる。たとえば、アプリケーションサーバ170によって調停される通信セッションは、理論的には、システム100内のどこかに位置するAT間で行われ得るので、調停される通信セッションのレイテンシを低減するために複数の地域ディスパッチャ170AおよびMCCが分散される。したがって、アプリケーションサーバ170に言及する場合、地域ディスパッチャ170Aのうちの1つまたは複数、およびまたは、MCC170Bのうちの1つまたは複数によって、関連する機能が実施され得ることが理解されよう。地域ディスパッチャ170Aは、概して、通信セッションを確立することに関係する機能を担当し、MCC170Bは、調停された通信セッション中に呼中シグナリングおよびメディアの実際の交換を行うことを含む、呼インスタンスの持続時間の間に通信セッションをホスティングすることを担当する。したがって、本発明の別の実施形態では、調停される通信セッションがPTT呼に相当することを仮定して、MCC170Bは、PTTアプリケーションサーバおよびまたはPTTメディア頒布サーバと呼ばれ得る。図3を参照すると、携帯電話などのアクセス端末200は、キャリアネットワーク126、インターネットおよびまたは他のリモートサーバおよびネットワークから最終的に発生することがある、RAN120から送信されたソフトウェアアプリケーション、データおよびまたはコマンドを受信および実行することができるプラットフォーム202を有する。プラットフォーム202は、特定用途向け集積回路もしくは他のプロセッサ、マイクロプロセッサ、論理回路、または他のデータ処理デバイスに動作可能に結合されたトランシーバ206を含み得る。ASIC208または他のプロセッサは、ワイヤレスデバイスのメモリ212内の任意の常駐プログラムとインターフェースする、アプリケーションプログラミングインターフェース210層を実行する。メモリ212は、読取り専用メモリまたはランダムアクセスメモリ、EEPROM、フラッシュカード、またはコンピュータプラットフォームに共通の任意のメモリから構成することができる。プラットフォーム202は、メモリ212においてあまり使用されないアプリケーションを保持することができるローカルデータベース214も含み得る。ローカルデータベース214は、一般的に、フラッシュメモリセルであるが、たとえば磁気媒体、EEPROM、光学媒体、テープ、ソフトまたはハードディスクなど、当技術分野で知られている任意の二次記憶デバイスとすることができる。内部プラットフォーム202の構成要素は、当技術分野で知られているように、構成要素の中でも、アンテナ222、ディスプレイ224、プッシュツートークボタン228、およびキーパッド226などの外部デバイスに動作可能に結合されてもよい。したがって、本発明の一実施形態は、本明細書で説明する機能を実行するための能力を含むアクセス端末を含むことができる。当業者により理解されるように、本明細書で開示する機能を達成するために、様々な論理要素を、個別要素、プロセッサ上で実行されるソフトウェアモジュール、またはソフトウェアとハードウェアとの任意の組合せで具現化することができる。たとえば、ASIC208、メモリ212、API210およびローカルデータベース214をすべて協働的に使用して、本明細書で開示する様々な機能をロード、記憶および実行することができ、したがってこれらの機能を実行する論理を様々な要素に分散することができる。あるいは、機能は1つの個別構成要素に組み込まれてもよい。したがって、図3中のアクセス端末の特徴は例示的なものにすぎないと見なすべきであり、本発明は図示の特徴または構成に制限されない。アクセス端末102とRAN120との間のワイヤレス通信は、符号分割多元接続、WCDMA、時分割多元接続、周波数分割多元接続、直交周波数分割多重、GlobalSystemforMobileCommunications、またはワイヤレス通信ネットワークまたはデータ通信ネットワークにおいて使用できる他のプロトコルなど、様々な技術に基づくことができる。データ通信は、一般に、クライアントデバイス102とMPTBS124とBSCPCF122との間で行われる。BSCPCF122は、キャリアネットワーク126、PSTN、インターネット、仮想プライベートネットワークなどの複数のデータネットワークに接続でき、したがって、アクセス端末102はより広範囲の通信ネットワークにアクセスできるようになる。前述のように、かつ当技術分野で知られているように、様々なネットワークおよび構成を使用して、音声送信およびまたはデータをRANからアクセス端末に送信することができる。したがって、本明細書で提供する例は、本発明の実施形態を限定するものではなく、本発明の実施形態の態様の説明を助けるものにすぎない。所与のアクセス端末が、特定のターゲットに送るべき大量のデータを有する場合、ファイル転送セッションに関連する時間が、ファイル転送セッションのセットアップ時間と比較して相対的に長くなるので、ファイル転送セッションのセットアップ時間は、比較的重要度が低い。しかし、相対的に少量のデータが交換されるファイル転送セッションのセットアップ時間は、セッション自体の長さと比較して、不釣り合いに長くなり得る。図4Aは、ファイルが通信システムにおいてAT間で交換され得る際の、従来の方式を示す。具体的には、図4Aは、送信ATがすでに通信セッションに関与している時に、送信ATがターゲットATにファイルをどのように送信するかという従来の例を示す。図4Aを参照すると、所与のATは、ファイル転送セッションを開始すべきかどうかを決定する。AT1が、ファイル転送セッションを開始しないと決定すると、AT1は、400Aにおいて、通信セッションおよび残りの処理のためのリソースをセットアップしない。それ以外の場合、AT1が、ファイル転送セッションを開始すると決定すると、AT1は、ファイル転送セッションのために、RAN120によりTCHをセットアップする。次いで、ファイル転送セッションのためのTCHを取得すると、AT1は、アプリケーションサーバ170とのファイル転送セッションの間にデータを交換するためのデータポートを取得するために、3ウェイTCPハンドシェイクに関与することによって、ファイル転送セッションのためのトランスポート接続をセットアップする。TCPは、当技術分野においてよく知られており、標準的なネットワーク層プロトコルを用いる。一般に、AT1のようなクライアントが、アプリケーションサーバ170のようなサーバとの接続を試みる前に、サーバはまず、接続に向けてクライアントを開放するためにポートに結合しなければならず、これはパッシブオープンと呼ばれる。パッシブオープンが確立されると、クライアントはアクティブオープンを開始することができる。トランスポートまたはTCP接続を実際に確立するために、3ウェイハンドシェイクが行われ、これにより、SYNをサーバに送るクライアントによってアクティブオープンが実行されて、サーバはSYNACKによって応答し、クライアントはサーバにACKを送り返す。この時点で、この場合はAT1であるクライアントは、アプリケーションサーバ170とのトランスポート接続をアクティブ化しており、アプリケーションサーバ170へのメッセージのタグ付けに用いるデータポートを有する。図4Aには明示的に示されないが、上述のTCPハンドシェイクは、通信セッションのターゲット側においても行われる。ターゲット側で行われるセットアップは、図4Bに関して以下で説明される。トランスポート接続をセットアップした後、AT1は、AT1においてファイル転送セッションを処理するアプリケーションをセットアップすることができ、AT2への送信のために、アプリケーションサーバ170へのアプリケーション層データの送信を開始することができる。AT1は、ファイル転送セッションの間に転送されるべきファイルが、AT2への送信のためにアプリケーションサーバ170に無事に送られたかどうかを、定期的に判定することができる。1つもしくは複数のファイルまたはファイルの一部の送信がまだ完了していないと、420AにおいてAT1が判定すると、処理は415Aに戻り、AT1は、405Aおよび410Aで取得されたリソースを用いて、AT2への送信のためにファイルまたはファイルの一部をアプリケーションサーバ170に送り続ける。それ以外の場合、415Aのファイル転送セッションのためのすべてのファイルの転送の送信が完了した後、処理は425Aに進む。425Aにおいて、AT1は、415Aのデータ送信のために取得されたセッションリソースを解放するので、405AからのTCHは切断され、410Aのトランスポート接続は終了する。何らかの後の時点において、AT1は、任意の追加のファイルをAT2へ送るべきかどうかを決定する。送るべきである場合、AT1が再びセッションリソースを取得し、AT2への別のファイル転送セッションの間に1つまたは複数のファイルを送れるように、処理は405Aに戻る。図4Bは、ファイルが通信システムにおいてAT間で交換され得る際の、従来の方式を示す。具体的には、図4Bは、ターゲットATがどのように送信ATからファイルを受信するかという、従来の例を示す。ある例では、図4Bは、図4Aの処理の間に、ターゲットATまたはAT2において行われ得る処理を示す。図4Bを参照すると、AT2へ転送されるべきデータをAT1が送信していることを、アプリケーションサーバ170が通知された後、アプリケーションサーバ170は、OpenメッセージをRAN120に送り、Openメッセージは次いで、RAN120によってAT2に送信される。AT2は、Openメッセージを受信し、トラフィックチャネルのセットアップを開始する。次に、410Bにおいて、AT2は、410AにおいてAT1で行われる処理と同様に、TCPハンドシェイクを介してトランスポート接続をセットアップする。この処理の何らかの時点において、415Aで、AT1は、通信セッションのために確立されたデータポートを介して、アプリケーションサーバ170へのデータの送信を開始する。AT2とのTCPハンドシェイクがまだ完了していないので、かつまたは、アプリケーションサーバ170が順序通りにデータパケットを送ることを要求され、パケットが順序がばらばらになって到達し得るので、アプリケーションサーバ170は416BにおいてAT1からのデータのバッファリングを開始する。AT2が、SYNACKメッセージにより確認応答することによって、TCHハンドシェイクを完了すると、アプリケーションサーバ170は、バッファリングされたデータのAT2への転送を開始することができる。しかし、416Bのバッファリングは、ACKが受信される時に必ずしも終わらず、ある期間継続し得ることが理解されよう。理解されるように、415Aにおいてアプリケーションサーバ170に到達するデータパケットは、ワイヤレスリンクにおける損失のために、順序または順番がばらばらになることがある。したがって、アプリケーションサーバ170は、416Bにおいてすべてのパケットをバッファリングする。データポートがAT2により確立された後、アプリケーションサーバ170は、バッファリングされたデータパケットのAT2への送達を開始することができる。従来は、n1個のパケットが利用可能である場合であっても、パケットp1が依然として欠けているので、1からpまでの連続パケットしかAT2に送達できなかった。これは、当技術分野において行頭ブロッキングとして知られ、従来のTCPにおける問題点である。以下でより詳細に説明されるように、本発明の少なくとも1つの実施形態では、行頭ブロッキングを減少させ、かつまたは除去することができる。したがって、一つには、TCP中のファイルが順序通りまたは順番通りに送達されることを強いられるので、図4Aおよびまたは図4Bに関連する遅延が発生する。理解されるように、400AにおいてAT1がファイル転送セッションを開始すると決定する時間と、415AにおいてAT1がファイル転送セッションのためのデータパケットの送信を開始できるようになる時間との間には、比較的長い時間が発生し得る。たとえば、TCHをセットアップするには約300msかかることがあり、トランスポート接続をセットアップするためにさらなる時間がかかることがある。したがって、本発明の実施形態は、ATが事前に確立された通信セッションに同時に関与している時に、ファイル転送セッションのためのデータの送信を、ATがより迅速に開始できるようにすることを対象とする。図4Cおよび図4Dは、本発明のある実施形態による、発信側AT1とターゲットAT2との間のファイル転送セッションのセットアップと関連付けられるシグナリングを示す。具体的には、図4Cは、ファイル転送セッションのセットアップの間にAT1とアプリケーションサーバ170との間で行われるシグナリングに注目し、図4Dは、ファイル転送セッションのセットアップの間にアプリケーションサーバ170とAT2との間で行われるシグナリングに注目する。図4Cを参照すると、所与のATが、ファイル転送セッションを開始すべきかどうかを決定する。ファイル転送セッションを開始しないと、AT1が決定すると、処理は400Cにとどまる。それ以外の場合、ファイル転送セッションを開始するとAT1が決定すると、AT1は、AT1によりすでに確立されている通信セッションが、ファイル転送セッションのためのファイルの送信に現在利用可能であるセッションリソースへのアクセスを有するかどうかを判定する。たとえば、AT1が405Cにおいて別のファイル転送セッションにすでに関与している場合、AT1は単に、新たに開始されるファイル転送セッションのために、他のファイル転送セッションのTCHおよびトランスポート接続を用いることができる。それ以外の場合、既存のセッションリソースがファイル転送セッションのために利用可能ではなければ、処理は410Cに進む。図4Cを参照すると、AT1は、ファイル転送セッションのために、RAN120とのTCHのセットアップを開始する。図4Aとは異なり、415Cにおいて、TCHのセットアップが完了するのを待機する代わりに、AT1は、トランスポートデータおよびアプリケーションデータを含めるようにdataoversignalingメッセージを構成することによって、トランスポート接続およびアプリケーション層接続のセットアップを先に開始して、逆方向リンクアクセスチャネルでDoSメッセージをRAN120に送り、RAN120は、DoSメッセージをアプリケーションサーバ170に転送する。ある例では、415Cにおいて送信されるDoSメッセージは、AT1のシグナリングメッセージのためにすでにセットアップされている、シグナリングポートまたはDoSポートを用いることができる。たとえば、一部のATは、ATのエンドユーザに対して準備される前に、サービスプロバイダによって、DoSポートにより事前構成され得る。その後、カバレッジがRAN120により提供され得る限り、ATは、関連するDoSポートの使用を許可される。したがって、AT1は、事前に確立されたシグナリングポートを利用して、415Cにおけるファイル転送セッションのための、トランスポート接続およびアプリケーション層接続をセットアップする。アプリケーションサーバ170は、415CにおけるDoSメッセージに含まれる具体的な情報を認識し、ファイル転送セッションの間にAT2へデータを送るために、AT1がトランスポート接続のセットアップを試みていると判定する。したがって、アプリケーションサーバ170は、415CからのDoSメッセージに含まれるトランスポート層パラメータを用いて、ファイル転送セッションの間に用いるAT1のためのデータポートを選択する。アプリケーションサーバ170は、401DにおいてStartメッセージをAT2に送り、ファイル転送セッションの準備をするようにAT2に指示する。401Dは、図4Dに関して以下でより詳細に論じられ、図4Dは、アプリケーションサーバ170とターゲットAT2との間のシグナリングをより詳細に扱う。何らかの後の時点において、AT1がTCHのセットアップを完了したと仮定する。AT1はまた、417CにおいてAT1のためにセットアップされたデータポートで、415CのDoSメッセージへの応答を、アプリケーションサーバ170から受信する。この時点において、AT1は、そのデータポートでAT2に転送されるべきデータの、アプリケーションサーバ170への送信を開始する。理解されるように、RAN120へTCHを通じてデータポート上で送られ、アプリケーションサーバ170に転送されることになる、最初のデータメッセージ431Cは、425Cからの応答メッセージへのACKとして機能するので、AT1は、応答メッセージに対する明示的なACKを送る必要はない。アプリケーションサーバ170は、445DにおいてデータをAT1からAT2に転送し、これは図4Dに関して以下でより詳細に論じられる。上で論じられたように、415CのDoSメッセージは、SYNメッセージとして機能し得る。その後、425Cの応答メッセージは、SYNACKメッセージとして機能することができ、AT1は、430Cおよび431Cにおいてデータポートでデータを送ることによって、データポートのセットアップを完了することができ、このことが、応答メッセージへのACKとして機能する。したがって、415C、425Cおよび431Cはまとめて、図4Aの415Aに示されるTCPハンドシェイクを実行する異なる方式に対応し、これらにより、TCHが取得される前にトランスポート接続がセットアップを開始できる。ある例では、TCPSYNメッセージは、415CのDoSメッセージ内に組み込まれてもよい。TCPSYNメッセージの主要な内容には、発信元ポート、宛先ポートおよび最初のシーケンス番号がある。アプリケーションサーバ170は、SYNACKメッセージにより応答することができ、または、呼要求メッセージへのACKを通じたCallACKメッセージのような、AT1に送られる別のメッセージの中の、SYNACKメッセージの主要な内容を符号化することができる。いずれの場合でも、AT1のファイル転送セッションのためのTCPトランスポート接続は、通常はアプリケーション層通信セッションのために用いられる、シグナリングセッションパラメータを利用する。415Cにおいてトランスポート接続のセットアップを開始することによって、SYNメッセージを、アプリケーションサーバ170へより迅速に通信することができ、その結果、TCP接続のセットアップが、参加者間の端末と端末の間の呼のために迅速に行われ得る。言い換えると、TCP接続をセットアップするための3ウェイハンドシェイクを実行することに関連する遅延が、図4Cの実施形態では低減される。425Cの応答メッセージは、シグナリングポートの代わりにデータポートで送られ、425Cにおいて応答メッセージが送られた後、AT1は、ファイル転送セッションの間のデータの送信のために、そのデータポートの使用を開始することができる。したがって、TCHを用意しファイル転送セッションのためのトランスポート接続を取得するための処理を同時に開始することによって、AT1は、ファイル転送セッションのためのアプリケーション層のデータの送信をより迅速に開始することができる。図4Cを参照して上で述べられたように、430Cおよび431Cで送られるデータパケットは、ワイヤレスリンクにおける損失のために、順序がばらばらになってアプリケーションサーバ170に到達することがある。この場合、アプリケーションサーバ170は、すべてのパケットをバッファリングする。従来は、n1個のパケットが利用可能である場合であっても、パケットp1が依然として欠けているので、1からpまでの連続パケットしかAT2に送達できない。これは、当技術分野において行頭ブロッキングとして知られ、従来のTCPにおける問題点である。以下でより詳細に説明されるように、本発明の少なくとも1つの実施形態では、行頭ブロッキングを減少させ、かつまたは、除去することができる。たとえば、以下でより詳細に論じられるように、所与のファイルが転送を完了するまでバッファリングが行われる従来の図4Aおよび図4Bと比較して、バッファリングは、図4Dの440Dにおいて応答メッセージがターゲットAT2から受信されるまでしか、続かなくてよい。AT1は、ファイル転送セッションの間に転送されるべきファイルが、AT2への送信のためにアプリケーションサーバ170に無事に送られたかどうかを、定期的に判定することができる。1つもしくは複数のファイルまたはファイルの一部の送信がまだ完了していないと、440CにおいてAT1が判定すると、処理は430Cに戻り、AT1は、AT2への送信のためにファイルまたはファイルの一部をアプリケーションサーバ170に送り続ける。それ以外の場合、430Cのファイル転送セッションのためのすべてのファイルの転送の送信が完了した後、処理は445Cに進む。445Cにおいて、AT1は、任意の追加のファイルをAT2へ送るべきかどうかを決定する。送るべきである場合、処理は430Cに戻り、AT1は、AT2への別のファイル転送セッションの間に1つまたは複数のファイルを送るための前のファイル転送セッションのために410Cから435Cの間に確立されたセッションリソースを、再使用する。それ以外の場合、445Cにおいて、AT2に送信する必要のあるデータはこれ以上ないと、AT1が判定すると、AT1は、430Cおよび431Cのデータ送信のために取得されたセッションリソースを解放するので、410Cおよび420CからのTCHは切断され、トランスポート接続は終了する。図4Cの検討から理解されるように、シグナリングポートは、SYNメッセージを送るために用いられ、その後、データはデータポートを介してアプリケーションサーバ170に送られる。したがって、トランスポート接続は、実際のセッションのためにセットアップされているポート以外のポートでセットアップされる。図4Dは、本発明のある実施形態による、図4Cの処理の間に、アプリケーションサーバ170とターゲットAT2との間で行われる動作を示す。具体的には、図4Dは、図4Cの401Dと445Dとの間での、アプリケーションサーバ170とターゲットAT2との間のシグナリングを示す。図4Dを参照して、図4Cの415CにおいてAT1からStartメッセージを受信すると、アプリケーションサーバ170は、ファイル転送セッションの各々の意図されるターゲットを特定して位置決定し、Startメッセージを各々の特定され位置決定されたターゲットに送る。図4Dでは、説明の便宜上、単一のターゲットAT2が示される。401DのStartメッセージは、時間遅延およびメッセージウィンドウのサイズのようなトランスポートデータを、アプリケーションサーバ170がAT2からデータを受信する際に用いる予定のポートの指定のような、何らかのアプリケーションデータとともに、含む。理解されるように、ファイル転送セッションのターゲットに割り当てられるデータポートは、AT2に割り当てられるデータポートと同じである必要はない。401DのStartメッセージは、DoSポートのようなシグナリングポートを通じて送られる。したがって、Startメッセージは、AT1からの415Cにおけるような移動機から発信されたDoSメッセージとは対照的な、移動機で終端するDoSメッセージに相当し得る。Startメッセージを受信すると、AT2は、AT2はすでにTCHを有するかといった、AT2が既存の通信セッションにすでに関与しているかどうかを判定する。AT2がまだTCHを有していないと、410DにおいてAT2が判定すると、415DにおいてAT2はTCHを用意する。AT1に戻ると、AT1がデータポートを取得した後、AT1は、データポートでアプリケーションサーバ170へのデータの送信を開始する。図4Dでは、431Cは、AT1からデータポートを通じて送られる最初のデータパケットに相当し、図4Dの431Cはまた、図4Cに関して上で論じられた同様の番号の信号に相当する。図4Dの実施形態では、AT2に宛てられたAT1からのデータは、AT2がデータの受信の準備ができる前に、AT1のデータポート上で、アプリケーションサーバ170に到達し始めると仮定される。したがって、アプリケーションサーバ170は、425DにおいてAT1からのデータのバッファリングを開始し、少なくとも、アプリケーションサーバ170からのデータのダウンロードの準備ができていることをAT2が示すまで、アプリケーションサーバ170は、425Dにおいてデータのバッファリングを続ける。415DにおいてTCHをセットアップした後、または、410DにおいてAT2がすでにTCHを有していたことを確認した後、AT2は、応答メッセージをアプリケーションサーバ170に送る。440Cの応答メッセージは、AT2がファイル転送セッションのために用いているポートのような、情報を含む。AT2から応答メッセージを受信すると、アプリケーションサーバ170は、ファイル転送セッションのためにAT2により用いられるデータポートを知り、それにより、425CのバッファリングされたデータのAT2への送信を開始する。図4Dには示されないが、AT1からのデータが431Cにおいてアプリケーションサーバ170に到達する前に、440Dの応答メッセージがアプリケーションサーバ170に到達できるということが、あり得る。たとえば、AT1がTCHなしで図4Cの処理を開始し、AT2がTCHにより図4Dの処理を開始すると、AT2は、AT1が固有のTCHをセットアップしてデータの送信を開始できるようになるよりも早く、Startメッセージに対して応答できるようになり得る。この場合、アプリケーションサーバ170は、425Dのバッファリングを実行する必要はなく、むしろ、AT1からのデータがアプリケーションサーバ170に到達し始めるとすぐに、AT1からAT2へのデータの転送を開始することができる。図4C~図4Dは、ファイル転送セッションがどのようにセットアップされ得るかに関連するが、ワイヤレス通信システムにおけるファイル転送セッションの別の側面は、発信側アクセス端末またはターゲットアクセス端末の異なる機能層の間の対話である。図5Aから図5Dでは、AT1の機能層1、2、および3に言及がなされる。これらの異なる機能層は、異なる層において特定の機能を実行する役割を果たす、ソフトウェアおよびまたはハードウェアの組合せに対応する。しかし、以下で説明される実施形態は、説明の便宜上、3つの機能層に注目するが、実施形態は3つの機能層に限定されず、代わりに任意の数の機能層を含んでもよいことが、理解されよう。ある例では、機能層1はMAC層と呼ばれることがあり、機能層2はトランスポート層と呼ばれることがあり、機能層3はアプリケーション層と呼ばれることがある。機能層1は、逆方向リンク物理層チャネルでのRAN120への送信のために待ち行列に入れられたデータパケットを保持する、送信ウィンドウまたは送信待ち行列を有するものとして、特徴付けられる。機能層2は、一部のパケットを機能層1の送信ウィンドウに追加することを要求することができ、これらのパケットは実際には、機能層3によって、高レベルまたは高次層において生成され得る。ある例では、機能層3は、セッション開始プロトコルクライアントまたは任意の他のマルチメディアアプリケーション層のインターフェースプロセスのような、アプリケーション層インターフェースに相当し得る。たとえば、SIPクライアントは、メディアアプリケーションのアプリケーション層の機能、トランスポート層プロトコル、および低次層コントローラ層のコントローラ、EVDOシステムにおける無線リンクプロトコル層のコントローラなどを管理する役割を果たし得る。一般に、機能層3が、別のセッション参加者に送るべきデータを有する場合、機能層3は、データを送るように機能層2に要求し、そして機能層2は、物理チャネルでデータを送るように機能層1に要求する。しかし、機能層3は、データが実際にいつ送信されるかに関して直接の制御権を有さないので、機能層3は、データがいつ機能層1によって物理チャネルで送られるかを決定できない。したがって、機能層3は通常、機能層3がいつデータパケット通信命令を機能層2に対して発行するかを追跡するが、機能層1がいつ実際のデータパケットを物理層で送信するかは追跡しない。図5Aを参照して、AT1は、少なくとも1人の他のセッション参加者との通信セッションへの参加をセットアップして開始すると、仮定する。次に、機能層3は、通信セッションのための新たなデータパケットをアプリケーションサーバ170に、次いで少なくとも1人の他のセッション参加者に送るための要求を、機能層2に対して発行する。新たなデータパケットを送信するように機能層2に要求した後、機能層3は、所与の満了期間を有する満了タイマーを始動させる。満了タイマーが動いている間は、機能層3は送信されるデータパケットのACKの受信を待機し、それにより、機能層3は、満了タイマーが満了する前にACKが受信されなかった場合に、データパケットの送信が成功しなかったと推測する。機能層2は、新たなデータパケットの送信の要求を受信して、機能層2により保持される送信待ち行列または送信ウィンドウに、データパケットを追加し、その後、機能層2は、機能層2の送信ウィンドウの中で現在予定されているデータパケットのすべての送信を試みるように、機能層1に指示する。理解されるように、本発明のすべての実施形態が、固有の送信ウィンドウまたは送信待ち行列を有するように機能層2に要求するわけではない。機能層2がそのような送信ウィンドウを有さない場合、機能層2は単に、新たなデータパケットが送信のために機能層3によって要求される度に、505Aにおいて送信のために要求されたデータパケットを、機能層1の送信ウィンドウに追加することができる。したがって、機能層2は固有の送信待ち行列を必ずしも有さないが、図5Aから図5Dの実施形態は、機能層2が固有の送信待ち行列へのアクセスを有するという仮定の下で、説明される。本発明の他の実施形態において、機能層2に送信待ち行列がないことに対応するように、図5Aから図5Dをどのように修正できるかは、当業者には容易に理解されよう。機能層1は、機能層2から送信の順序を受信し、次いで、機能層2の送信ウィンドウからのデータパケットを、固有の送信ウィンドウに追加する。530Aにおいて、機能層1は、機能層1の送信ウィンドウに含まれるデータパケットの送信を、1回または複数回試みる。530Aにおいて、機能層1の送信ウィンドウのデータパケットの1つの送信の試みが成功しなかった場合、データパケットの送信が成功するまで、機能層1は、送信が成功しなかったデータパケットを、所定の回数、機能層1の送信ウィンドウに再び加える。したがって、535Aは、データパケットが機能層1の送信ウィンドウに再び加えられ、その結果送信が成功するのを示す。当業者により理解されるように、機能層3は、データパケットを送信するこれらの個々の試みが成功したか成功しなかったかに関して、通知されない。535Aにおいてデータパケットの送信に成功した後、アプリケーションサーバ170は、機能層3ACKメッセージをAT1に送り返すことによって、データパケットの受信に成功したと確認応答する。上で説明されたデータパケット送信処理が、機能層1において進行中である間、機能層3は、機能層1で行われている動作を実際には認識せず、機能層3は単に、505Aにおいて送信のために要求されたデータパケットに対するACKが、機能層3において受信されたかどうかを監視する。したがって、545Aにおいて、機能層3は、505Aからの要求されたデータパケットに対するACKが、満了タイマーが満了する前に受信されたかどうかを判定する。545Aにおいて、データパケットに対する確認応答が成功したと、機能層3が判定した場合、処理は560Aに進む。それ以外の場合、545Aにおいて、データパケットに対する確認応答が成功しなかったと、機能層3が判定した場合、機能層3は、データパケットの送信が失敗したと推測し、データパケットを再び送信するために、トランスポート層プロトコルに対して別の要求を発行する。図5Aの実施形態では、540AにおけるACKは、満了タイマーの満了の後で受信されるので、545Aにおいて、機能層3はすでに、データパケットに対する確認応答が成功していないと判定している。したがって、機能層2は、データパケットの送信のための新たな要求を受信し、機能層2の送信ウィンドウにデータパケットを再び追加する。この時点において、処理は520Aに戻り、機能層1によるデータパケットの送信の新たな要求を繰り返す。理解されるように、機能層1がデータパケットの送信の試みを続けた場合でも、機能層3は、満了タイマーが満了したことを認識するだけであり、このことはデータパケットの送信の新たな要求を引き起こす。そしてこれによって、アプリケーションサーバ170にデータパケットを2回送るように、機能層1が要求される。図5Aの実施形態では、機能層3が送信のために要求したデータパケットの1つに対する、アプリケーションサーバ170による確認応答が成功したと、機能層3が545Aにおいて判定すると、機能層3は次いで、さらなるデータがアプリケーションサーバ170への送信のために要求されるべきかどうかを判定する。機能層3が560Aにおいて、さらなるデータをアプリケーションサーバ170に送信すると決定すると、処理は505Aに戻り、1つまたは複数のさらなるデータパケットの送信のために繰り返す。それ以外の場合、図5Aの処理は終了するが、500Aの通信セッションは、AT1が、ある期間データパケットを送ることなくデータパケットを受信することで、継続しうる。機能層1における送信を待機しているパケットの状態に関連する情報を、機能層3および機能層1が交換できる機構を対象とする、本発明のある実施形態が、ここで図5Bを参照して説明される。図5Bを参照して、AT1は、少なくとも1人の他のセッション参加者との通信セッションへの参加をセットアップして開始すると、仮定する。次に、機能層3は、通信セッションのための新たなデータパケットを、アプリケーションサーバ170に、次いで少なくとも1人の他のセッション参加者に送信するために、機能層2に送ることを要求する。しかし、図5Aとは異なり、505Bにおいて新たなデータパケットを送るように機能層2に要求した後、データパケットに対するACKを機能層3が待機する期間を定める満了タイマーを、機能層3はまだ始動させない。次に、図5Bの510Bから530Bは全般に、それぞれ図5Aの515Aから535Aに対応するので、簡潔にするためにさらに詳細には説明されない。機能層1が、530Bにおいて、物理層でのRAN120へのデータパケットの送信に成功した後、RAN120は、AT1の機能層1に層1ACKを送り、その後、機能層1は、505Bにおいて送信のために要求されたデータパケットがAT1から送信されたことを示す通知メッセージを、機能層3に送る。たとえば、機能層1から機能層3への通知メッセージは、コールバックAPIとして実装され得る。図5Bには明示的に示されないが、535Bの通知は、機能層3によって送信のために要求された各々のデータパケットについて、それぞれのデータパケットが機能層1においてAT1から送信された時に、実行され得る。従来、機能層3は、機能層3自体がデータパケットの送信を要求した時に満了タイマーを始動させ、これには、データパケットがAT1から送信できるようになるまでの、機能層2およびまたは機能層1における遅延が考慮されていない。図5Bの実施形態では、535Bで、機能層3においてデータパケットの送信の通知を受信すると、機能層3は、データパケット送信要求が505Bで発行された時ではなく、540Bにおいて満了タイマーを始動させる。当業者により理解されるように、このように後の時点で満了期間を開始することで、データパケットの送信の前に発生する、AT1の機能層2およびまたは機能層1における遅延によって、機能層3が同一のデータパケットを送信するための要求を再発行する確率が下がる。また、端の状況を除き、スループットを低下させる必要はない。さらに、540Bで始動する満了タイマーは、510Aにおける満了タイマーよりも短い期間動作するように示されるが、510Aおよび540Bの実際の満了期間は同一であってもよいことが、理解されよう。しかし、540Bにおける満了タイマーは後の時点で始動するので、ACKがタイマーの始動に続いてより迅速に受信され、540Bの満了タイマーはより短い期間しか動作しなくてもよい。機能層1に戻り、530Bにおいてデータパケットの送信に成功した後、アプリケーションサーバ170は、機能層3のACKメッセージまたはSIP層のACKメッセージをAT1に送り返すことによって、データパケットの受信に成功したと確認応答する。550Bにおいて、機能層3は、530BにおいてAT1から送信された、505Bからの要求されたデータパケットに対して、満了タイマーが満了する前に、ACKが受信されたかどうかを判定する。やはり、図5Bの満了タイマーは、実際のデータパケット送信要求が505Bにおいて機能層3から発行された、より早い時点ではなく、535Bの通知の後で開始し、このことは一般に、再送信が機能層3によって要求される前に、最初のデータパケットの送信に確認応答するためのより長いタイマーを、図5Bの満了タイマーがアプリケーションサーバ170に対して許可するということを意味する。550Bにおいて、データパケットに対する確認応答が成功したと、機能層3が判定した場合、処理は565Bに進む。それ以外の場合、550Bにおいて、データパケットに対する確認応答が成功しなかったと、機能層3が判定した場合、機能層3は、データパケットの送信が失敗したと推測し、データパケットを再び送信するために、機能層2に対して別の要求を発行する。機能層2は、データパケットの送信のための新たな要求を受信し、機能層2の送信ウィンドウにデータパケットを再び追加する。この時点において、処理は515Bに戻り、データパケットの送信の新たな要求を繰り返す。図5Bの例では、505Bの送信要求ではなく535Bの通知に応答して、機能層3が満了タイマーを始動させたことに少なくとも一部基づいて、満了期間内で受信されているアプリケーションサーバ170からのACKを、550Bの判定ブロックが評価することが理解されよう。したがって、図5Bは、ワイヤレス層または物理層を通じたRAN120へのデータパケット送信がいつ成功したかを、機能層1が機能層3に対して通知できる機構を実装することによって、機能層3からの不要な繰り返されるデータパケット送信要求の数をどのように減らせるかを示す、1つの例示的な実施形態である。したがって、図5A~図5Bは、所与のデータパケットの物理層での送信の成功を、機能層3に早く通知することに関連する利点を示し、図5C~図5Dは、所与のデータパケットの物理層での送信の失敗を、機能層3に早く通知することに関連する利点を示す。図5Cを参照して、AT1は、少なくとも1人の他のセッション参加者との通信セッションへの参加を、セットアップして開始すると仮定する。次に、機能層3は、新たなデータパケットをアプリケーションサーバ170に、次いで少なくとも1人の他のセッション参加者に送信するための要求を、機能層2に対して発行する。図5Aの510Aにおけるように、新たなデータパケットを送るように機能層2に要求した後、機能層3は、所与の満了期間を有する満了タイマーを始動させる。満了タイマーが動いている間は、機能層3は送信されるデータパケットのACKの受信を待機し、それにより、機能層3は、満了タイマーが満了する前にACKが受信されなかった場合に、データパケットの送信が成功しなかったと推測する。機能層2は、新たなデータパケットの送信の要求を受信して、機能層2の送信ウィンドウにデータパケットを追加し、その後、機能層2は、機能層2の送信ウィンドウの中で現在スケジューリングされているデータパケットのすべての送信を試みるように、機能層1に指示する。機能層1は、機能層2から送信の順序を受信し、次いで、機能層2の送信ウィンドウからのデータパケットを、固有の送信ウィンドウに追加する。530Cにおいて、機能層1は、機能層1の送信ウィンドウに含まれるデータパケットの送信を、1回または複数回試みる。530Cにおいて、機能層1の送信ウィンドウのデータパケットの1つの送信の試みが成功しなかった場合、データパケットの送信に成功するまで、または繰り返される送信の試みの数が閾値を超えるまで、機能層1は、送信が成功しなかったデータパケットを、所定の回数、機能層1の送信ウィンドウに再び加える。したがって、530Cは、アプリケーションサーバへのデータパケットの送信の、不成功の試みを示し、データパケットのRAN120への送信は不成功である。RAN120がアプリケーションサーバ170へのデータパケットの送信を完了できないので、RAN120は、層1の否定ACKをAT1の機能層1に送る。あるいは、明示的なNACKがRAN120によって送られる必要はなく、その場合、機能層1は単に、ACKがRAN120から受信されることなく閾値の期間が経過した後、物理層でのデータパケットの送信の失敗を推測する。しかし、機能層1は、NACKフレームを受信し、またはACKが受信されない場合にパケット損失を推測するが、機能層1は、データパケットの送信の試みがすでに失敗したことを、機能層3に通知しない。図5Cの実施形態では、上で説明されたデータパケット送信処理が、機能層1において進行中である間、機能層3は、機能層1で行われている動作を実際には認識せず、機能層3は単に、505Cにおいて送信のために要求されたデータパケットに対するACKが、機能層3において受信されたかどうかを監視する。したがって、545Cにおいて、機能層3は、505Cからの要求されたデータパケットに対するACKが、満了タイマーが満了する前に受信されたかどうかを判定する。545Cにおいて、データパケットに対する確認応答が成功したと、機能層3が判定した場合、処理は560Cに進む。それ以外の場合、545Cにおいて、データパケットに対する確認応答が成功しなかったと、機能層3が判定した場合、機能層3は、データパケットの送信が失敗したと推測し、データパケットを再び送信するために、機能層2に対して別の要求を発行する。機能層2は、データパケットの送信のための新たな要求を受信し、機能層2の送信ウィンドウにデータパケットを再び追加する。この時点において、処理は520Cに戻り、データパケットの送信の新たな要求を繰り返す。理解されるように、540Cにおいて、機能層1がパケット障害またはパケット損失を判定した場合であっても、545Cにおいて、機能層3は、満了タイマーの満了のみによって送信の失敗を推測する。したがって、図5Aにおける満了タイマーの利用は、ACKが遅く到達した場合に、データパケットの不必要な繰り返しの送信を引き起こし、図5Cにおける満了タイマーの利用は、送信の試みが実際に失敗した場合に、データパケットの繰り返しの送信を命令するまでの、不必要な遅延を引き起こした。図5Cに戻り、機能層3が送信のために要求したデータパケットの1つに対する、アプリケーションサーバ170による確認応答が成功したと、機能層3が545Cにおいて判定すると、機能層3は、さらなるデータがアプリケーションサーバ170への送信のために要求されるべきかどうかを判定する。機能層3が560Cにおいて、さらなるデータをアプリケーションサーバ170に送信すると決定すると、処理は505Cに戻り、1つまたは複数のさらなるデータパケットの送信のために繰り返す。それ以外の場合、図5Cの処理は終了するが、500Cの通信セッションは、AT1が、ある期間データパケットを送ることなくデータパケットを受信することで、継続しうる。機能層1における送信を待機しているパケットの状態に関連する情報を、機能層1および機能層3が交換できる機構を対象とする、本発明のある実施形態が、ここで図5Dを参照して説明される。図5Dを参照して、AT1は、少なくとも1人の他のセッション参加者との通信セッションへの参加をセットアップして開始すると、仮定する。次に、機能層3は、通信セッションのための新たなデータパケットを、アプリケーションサーバ170に、次いで少なくとも1人の他のセッション参加者に送信するために、機能層2に送ることを要求する。しかし、図5Cとは異なり、505Dにおいて新たなデータパケットを送るように機能層2に要求した後、データパケットに対するACKを機能層3が待機する期間を定める満了タイマーを、機能層3はまだ始動させない。次に、図5Dの510Dから530Dは全般に、それぞれ図5Cの515Cから535Cに対応するので、簡潔にするためにさらに詳細には説明されない。図5Bの535Bと同様に、機能層1が、530Bにおいて、任意のデータパケットのRAN120への送信に成功できた場合、機能層1は、505Dにおいて送信のために要求されたデータパケットがAT1から送信されたことを示す通知メッセージを、機能層3に送る。しかし、535Dの直後に、RAN120が、データパケットに対する層1のNACKをAT1の機能層1に送り、または代替的には、RAN120がデータパケットに対して確認応答できなかった時に、機能層1がパケット障害またはパケット損失を推測すると、仮定する。図5Cでは、540Cでパケット送信の失敗を示したことで、データパケットの次の送信の試みが中止された。しかし、図5Dでは、540Dでパケット送信の失敗を示したことで、535Dにおいて機能層3により示されたデータパケットの送信の試みが失敗したことが、545Dにおいて機能層3に通知もされる。図5Bの535Bおよびまたは図5Dの535Dの通知と同様に、545Dにおける機能層1から機能層3への通知メッセージは、コールバックAPIとして実装され得る。図5Dには示されないが、機能層3は、535Dにおいて送信の通知が受信されると、満了タイマーを始動させることができる。しかし、545Dにおいて送信の失敗の通知を次に受信すると、機能層3は、この満了タイマーが満了するのを待つ必要はなく、むしろ、機能層1からの通知を介して、データパケットを再送信する必要があると推測することができる。したがって、機能層1からの送信の失敗の通知に応答して、機能層3は、データパケットを送信するための別の要求を、機能層2に対して発行する。機能層2は、データパケットの送信のための新たな要求を受信し、機能層2の送信ウィンドウにデータパケットを再び追加する。そして、機能層2は、機能層2の送信ウィンドウでパケットのすべての送信を試みるように、機能層1に指示する。機能層1は、機能層2から送信の順序を受信し、次いで、機能層2の送信ウィンドウからのデータパケットを、固有の送信ウィンドウに追加する。570Dにおいて、機能層1が、データパケットのRAN120への送信に成功し、RAN120が、データパケットのアプリケーションサーバ170への転送に成功したと仮定する。したがって、アプリケーションサーバ170は、層3のACKメッセージをAT1に送り返すことによって、データパケットの受信に成功したと確認応答する。ACKを受信すると、機能層3は、別のデータパケットを送信すべきかどうかを決定する。機能層3が別のデータパケットを送信すると決定すると、処理は505Dに戻る。それ以外の場合、機能層3が580Dにおいて別のデータパケットを送信しないと決定すると、図5Dの処理は終了するが、500Dの通信セッションは、AT1が、ある期間データパケットを送ることなくデータパケットを受信することで、継続しうる。シグナリングダイアグラムを簡潔にするために図5Dには明示的に示されないが、550Dと575Dの間の、データパケットの送信の繰り返しの試みは、適宜、535Dおよび545Dの通知とも関連付けられてよいことが、理解されよう。これらの通知メッセージは、分かりやすくするために省略されるが、たとえば、送信の通知は、570Dの後で機能層1から機能層3に送られてよく、これによって、満了タイマーが機能層3において始動され得ることが、理解されよう。さらなる例では、図5Dを参照すると、EnhancedMultiflowPacketApplicationを用いる場合、RLP層が、最大送信単位の設定および設定解除を行う。RLPNACKが機能層1で受信される場合、パケットを閾値の回数再送信したRLP層は、MTUの送信が成功したかどうかを高次層に示すことができる。RLPNACKが無効にされるが、MTUが、物理層パケットにわたってさらにセグメント化される複数のRLPパケットにわたり断片化される場合、セグメントの損失が、物理層NACKにより推測され得る。RLPパケットは、これらの物理層NACKに基づいて、成功したと推測され得る。しかし、物理層セグメントの1つのみが完全に失われた場合でも、MTUは失われ、この情報は高次層により利用されて、MTUの再送信を引き起こすことができる。損失がRLC層によって推測される場合、同様の手順が、WCDMAの物理層において実施され得る。したがって、540DのNACKまたはパケット送信の失敗は、任意の特定のセグメントに対するNACKまたはパケット送信の失敗であり得る。図6Aは、ストリーミング通信セッションまたはリアルタイム通信セッションと同時に、ファイル転送セッションをサポートする、従来の機構を示す。したがって、図6Aを参照して、アプリケーションサーバ170は、AT1とAT2との間のストリーミング通信セッションに相当する第1のセッションをセットアップし、次いで、アプリケーションサーバ170は、ファイル転送セッションに相当する第2のセッションをセットアップし、AT1からAT2への1つまたは複数のファイルの転送を容易にすると、仮定する。600Aの第1のセッションは、605Aの第2のセッションと比較して、サービス品質がより高いことがさらに仮定され得る。この時点において、AT1は、第1のセッションのためのAT1のリアルタイムメディア送信をサポートできる、比較的高速なネットワークに位置し、第2のセッションのための所与のペイロードサイズにおいて、AT1のパケット送信を同時にサポートすることもできると、さらに仮定する。したがって、AT1は、第1のセッションのためにストリーミングパケット1を送信し、次いで、第2のセッションのためにデータパケット1を送信する。そして、AT1は、第1のセッションのためにストリーミングパケット2を送信し、次いで、第2のセッションのためにデータパケット2を送信する。そして、AT1は、第1のセッションのためにストリーミングパケット3を送信する。以下では、データ速度の低い環境およびデータ速度の高い環境への言及がなされる。理解されるように、転送されているデータのタイプに基づいて、ユーザが良好なユーザ体験を得るための、時間に対する何らかの期待がある。この場合、ノミナルのデータ速度が定められることがあり、これによって、多くのユーザが、満足のいく体験レベルを判断すると予想される。ノミナルのデータ速度は、様々なネットワーク技術の間で変わることがあり、個々のユーザの性能に対する期待およびまたは他の要因に基づいても変わり得る。したがって、本明細書で用いられる場合、データ速度の低い環境は、データ速度の高い環境と比較して、予測されるデータ速度または実際のデータ速度が低いことと関連付けられる。また、本明細書で用いられる場合、データ速度の低い環境は、関連するノミナルのデータ速度よりも低速な、実際のデータ速度または予測されるデータ速度と関連付けられ、データ速度の高い環境は、関連するノミナルのデータ速度以上の、実際のデータ速度または予測されるデータ速度と関連付けられる。この時点において、AT1が、データ速度の低い環境に移行したと仮定する。したがって、AT1は、スケジューリングされたとおりに第2のセッションのためのデータパケット3を依然として送り、アプリケーションサーバ170は、データパケット3をAT2に送る。しかし、データ速度の低い環境にあるので、データパケット3の送信には、より長い時間がかかり、第1のセッションのためのストリーミングパケット4がスケジューリングされるスロットと、部分的に重複する。したがって、第2のセッションのためのデータパケット3が送信を完了できるように、第1のセッションのためのストリーミングパケット4は、645Aにおいて、スケジューリングされたスロットの間、脱落または遅延する。そして、第1のセッションのためのストリーミングパケット4は、650Aにおける第2のセッションのためのデータパケット3の送信の後、スロットの送信のために再びスケジューリングされる。理解されるように、図6Aでは、第1のセッションが一般にパケット送信の遅延の影響をより受けやすいが、低速なデータ速度環境では、データパケット3の送信が、第1のセッションのための次のストリーミングパケットの送信を遅らせる。たとえば、機能層1はすでに、ある数のパケットを送信待ち行列の中に有するので、第2のセッションのパケットがすでに待ち行列にある時に、第1のセッションのパケットを、第2のセッションのパケットよりも優先し続けることは難しいことがある。したがって、図6Bは、リアルタイムセッションまたはストリーミングセッションのパケット送信の遅延が低減およびまたは完全に回避されるように、ファイル転送セッションのような非ストリーミングセッションのためのデータパケットのサイズが動的に調整される、本発明の実施形態を示す。図6Bを参照すると、600Bから630Bは、図6Aの600Aから630Aにそれぞれ実質的に対応するので、簡潔にするためにさらに説明はされない。635Bにおいて、AT1は、AT1がデータ速度の低い環境に移行したことを検知する。ある例では、データ速度の低い環境の検知は、ハンドセットに対して対応できないQoSを有する、1x、GeneralPacketRadioService、EvolutionDataOptimizedRel0ネットワークまたはRevAネットワークに入ったことなどに、相当し得る。635Bにおいてデータ速度の低い環境に移行した後、AT1は、第2のセッションのためのパケット内のデータペイロードのサイズを、動的に低減する。たとえば、640Bのペイロードサイズ低減は、AT1が移行した先のネットワークに基づいて計算され得る。あるいは、640Bのペイロードサイズ低減は、第2のセッションのデータパケットが、第1のセッションのストリーミングデータパケットの遅延または再スケジューリングを引き起こさないように、データ速度の低い環境についての任意の他のタイプの推定に基づいて計算されてもよい。あるいは、アプリケーションサーバ170は、次のストリーミングデータパケットへの遅延を招くことなく次のデータパケットに割り当てられ得るサイズを計算することができ、アプリケーションサーバ170は、許容可能なデータパケットサイズを、AT1に搬送することができる。したがって、AT1は、第2のセッションのためのデータパケット3aを送信する。上で述べられたように、データパケット3aのペイロード部分は、615Bおよび616Bならびにまたは625Bおよび626Bの、データパケット1およびまたはデータパケット2のペイロード部分よりも小さい。次に、AT1は、第1のセッションのためにストリーミングパケット4を送信する。645Bおよび646Bとは異なり、AT1のデータ速度の低い環境に順応するために、第1のセッションではなく第2のセッションのためのパケットが減らされるので、第1のセッションのためのストリーミングパケット4は、時間通りに、かつフルペイロードのパケットとして送信され得る。セッションは継続し、これにより、AT1は、減らされたペイロード部分を有する第2のセッションのためのデータパケット3bを送信し、次いでAT1は、再スケジューリングすることなく、完全なデータ速度で別のストリーミングデータパケット5を送信する。したがって、ファイル転送セッションよりもストリーミング通信セッションを優先することによって、AT1は、AT1がデータ速度の低い環境に移行した場合に、ストリーミング通信セッションのためのリアルタイムパケットの再スケジューリングまたは遅延の発生を減らすことができる。さらに、図6Bは、データ速度の高い環境またはネットワークから、データ速度の低い環境またはネットワークへ、AT1が移行する特定の例を示すが、図6Bは、動的な速度制御アルゴリズムをより広く表すものであることが理解されよう。たとえば、DRCAは、高優先度の、遅延の影響を受けやすいストリーミングされるデータを、一定の間隔でスケジューリングすることができ、非QoSデータを、ストリーミングされるデータの連続する送信の間の時間間隔で、量を制御して送信することができる。たとえば、ネットワークの種類に応じて、非QoS用途のデータの量は、一定の値に制限され得る。あるいは、非QoS用途のデータの量は、1つの適応アルゴリズムまたは探索アルゴリズムに基づいて、すべての連続する時間間隔において調整され得る。このアルゴリズムは、たとえば、慎重な値で開始して、音声QoSパケットが遅延の影響を受けない場合にはMTUサイズを大きくして、音声パケットが何らかの遅延の影響を受ける場合には送信されるデータの量を減らすというものである。たとえば、rewardpenalty型のアルゴリズムのような学習アルゴリズムが、用いられ得る。別の代替的な例では、非QoS用途のデータの量は、QoSストリーミングデータとともに過去の非QoSストリーミングデータを送信するのに必要なスロットの数に関する正確な情報に基づいて、すべての連続する時間間隔において調整されてよく、この場合、次の時間間隔でスケジューリングされるデータの量は、ハンドセットにより計算され得る。したがって、図6Bは、データ速度の低い環境へ入った時の、データペイロードの低減を明示的に示す。ある代替的な例では、図6Bは、データ速度の低い環境からデータ速度の高い環境へ移行するATに対応するように、修正され得る。この代替的な例では、ペイロードは、データ速度の高い環境に入ると上がり、次の非QoSパケットのための実際のペイロードを計算する多くの異なる機構を、用いることができる。図6Cは、ストリーミング通信セッションまたはリアルタイム通信セッションと同時に、ファイル転送セッションをサポートする、別の従来の機構を示す。具体的には、送信AT1ではなくターゲットAT2が、データ速度の低い環境に移行することを除き、図6Cは、いくつかの面で図6Aと同様である。図6Cを参照すると、600Cから630Cは、それぞれ図6Aの600Aから630Aに、およびまたはそれぞれ図6Bの600Bから630Bに実質的に対応するので、簡潔にするためにさらに説明はされない。この時点において、AT2が、データ速度の低い環境に移行したと仮定する。したがって、AT1は、スケジューリングされたとおりに第2のセッションのためのデータパケット3を依然として送り、アプリケーションサーバ170は、データパケット3のAT2への送信を開始する。データパケット3のAT2への送信が完了する前に、AT1は、第1のセッションのためのストリーミングパケット4を、AT2への送信のためにアプリケーションサーバ170に送信する。アプリケーションサーバ170は、ストリーミングパケット4のAT2への転送を遅延させる。言い換えると、AT2がデータ速度の低い環境にあるので、アプリケーションサーバ170からAT2へのデータパケット3の送信には、より長い時間がかかり、第1のセッションのためのストリーミングパケット4がスケジューリングされるスロットと、部分的に重複する。したがって、第1のセッションのためのストリーミングパケット4は、646Cにおいて遅延される。そして、第1のセッションのためのストリーミングパケット4は、647Cにおける第2のセッションのためのデータパケット3の送信の後、スロットの送信のために再スケジューリングされる。理解されるように、図6Cでは、第1のセッションが一般にパケット送信の遅延の影響をより受けやすいが、低速なデータ速度環境では、データパケット3の送信が、第1のセッションのための次のストリーミングパケットの送信を遅らせる。したがって、図6Dは、リアルタイムセッションまたはストリーミングセッションのパケット送信の遅延が低減およびまたは完全に回避されるように、アプリケーションサーバ170およびまたはRAN120において、ファイル転送セッションのようなダウンリンク非ストリーミングセッションのためのデータパケットのサイズが動的に調整される、本発明の実施形態を示す。図6Dを参照すると、600Dから635Dは、図6Cの600Cから635Cにそれぞれ実質的に対応するので、簡潔にするためにさらに説明はされない。図6Dを参照すると、AT2が635Dにおいてデータ速度の低い環境に移行した後、アプリケーションサーバ170は、低速のデータ速度環境へのAT2の移行を検知する。たとえば、データ速度の低い環境へのAT2の移行の、アプリケーションサーバ170による検知は、AT2の現在のデータ速度環境に関するAT2またはRAN120からの通知、アプリケーションサーバ170のAT2への接続の性能の低下の検知、AT2の現在の位置の報告、このときアプリケーションサーバ170は特定の地理的な領域またはサービングエリアに関連するデータ速度を知っている、およびまたは、AT2へのアプリケーションサーバ170のリンクまたは接続の性能の特性を、アプリケーションサーバ170が推測することができる任意の他の機構に、相当し得る。AT2がデータ速度の低い環境に移行したと、640Dで判定すると、アプリケーションサーバ170は、アプリケーションサーバ170が第2のセッションのためにAT2に転送している個々のデータパケットのペイロードを、低減する。たとえば、645Dのペイロードサイズ低減は、AT2が移行した先のネットワークに基づいて計算され得る。あるいは、645Dのペイロードサイズ低減は、第2のセッションのデータパケットが、第1のセッションのストリーミングデータパケットの遅延または再スケジューリングを引き起こさないように、データ速度の低い環境についての任意の他の種類の推定に基づいて計算され得る。あるいは、AT2は、次のストリーミングデータパケットへの遅延を招くことなく次のデータパケットに割り当ることができるサイズを計算することができ、AT2は、許容可能なデータパケットサイズを、アプリケーションサーバ170に伝達することができる。したがって、AT1は、通常のまたはフルサイズのペイロード部分を有する、第2のセッションのためのデータパケット3を送信する。AT1からデータパケット3を受信すると、アプリケーションサーバ170は、データパケット3のペイロードサイズを低減して、低減されたペイロード部分を有するデータパケット3aを生成し、一方で、データパケット3aから除外された任意のデータペイロードをバッファリングする。そして、アプリケーションサーバ170は、データパケット3aをAT2に送る。次に、AT1は、第1のセッションのためのストリーミングパケット4をアプリケーションサーバ170に送信し、RAN120が、ペイロードサイズの低減によって、データパケット3aをより迅速に送信できるようになるので、アプリケーションサーバ170は、図6Cに示される遅延を招くことなく、ストリーミングパケット4をAT2に送ることができる。660Dにおいて、アプリケーションサーバ170は、低減されたペイロード部分を有する第2のセッションのためのデータパケット3bを送信する。したがって、ファイル転送セッションよりもストリーミング通信セッションを優先することによって、アプリケーションサーバ170は、ターゲットAT2がデータ速度の低い環境に移行した場合に、ストリーミング通信セッションのためのリアルタイムパケットの再スケジューリングまたは遅延の発生を減らすことができる。さらに、図6Dは、データ速度の高い環境またはネットワークから、データ速度の低い環境またはネットワークへ、AT2が移行する特定の例を示すが、図6Dは、動的な速度制御アルゴリズムをより広く表すものであることが理解されよう。たとえば、DRCAは、高優先度の、遅延の影響を受けやすいストリーミングされるデータを、一定の間隔でスケジューリングすることができ、非QoSデータを、ストリーミングされるデータの連続する送信の間の時間間隔で、量を制御して送信することができる。たとえば、ネットワークの種類に応じて、非QoS用途のデータの量は、一定の値に制限され得る。あるいは、非QoS用途のデータの量は、1つの適応アルゴリズムまたは探索アルゴリズムに基づいて、すべての連続する時間間隔において調整され得る。このアルゴリズムは、たとえば、慎重な値で開始して、音声QoSパケットが遅延の影響を受けない場合にはMTUサイズを大きくして、音声パケットが何らかの遅延の影響を受ける場合には送信されるデータの量を減らすというものである。たとえば、rewardpenalty型のアルゴリズムのような学習アルゴリズムが、用いられ得る。別の代替的な例では、非QoS用途のデータの量は、QoSストリーミングデータとともに過去の非QoSストリーミングデータを送信するのに必要なスロットの数に関する正確な情報に基づいて、すべての連続する時間間隔において調整されてよく、この場合、次の時間間隔でスケジューリングされるデータの量は、アプリケーションサーバ170により計算され得る。したがって、図6Dは、データ速度の低い環境に入った時のデータペイロードの低減を明示的に示すが、データペイロードが他の実施形態で調整される方式は、ペイロードを上げることができ、次の非QoSパケットのための実際のペイロードを計算する多くの異なる機構を、用いることができる。また、図6Dは、非QoSセッションまたは非リアルタイムセッションのために、動的なペイロード低減を実行するアプリケーションサーバ170を示すが、これらの動作は、本発明の他の実施形態では、AT2のRAN120により実行されてもよいことが理解されよう。この場合、アプリケーションサーバ170は、第1および第2のセッションのためのデータパケットをRAN120に転送し、RAN120は、ストリーミングパケットのペイロードサイズを動的に低減して、非ストリーミングパケットの送信がストリーミングセッションに対する遅延を招かないようにする役割を果たす。図7Aは、ストリーミング通信セッションまたはリアルタイム通信セッションと同時に、ファイル転送セッションをサポートする、従来の機構を示す。したがって、図7Aを参照して、アプリケーションサーバ170は、AT1とAT2との間のストリーミング音声通信セッションに相当する第1のセッションをセットアップし、次いで、アプリケーションサーバ170は、ファイル転送セッションに相当する第2のセッションをセットアップし、AT1からAT2への1つまたは複数のファイルの転送を容易にすると、仮定する。700Aの第1のセッションは、705Aの第2のセッションと比較して、サービス品質がより高いことがさらに仮定され得る。具体的には、AT1のユーザが声による質問HellohowareyoudoingtodayをAT2に転送しており、AT2のユーザがGoodを示すことによりAT1のユーザの質問に答えるという、図7Aが説明される。この言葉による第1のセッションの交換の間、AT1は、第2のセッションのためのデータパケットもAT2に送っていると仮定する。したがって、AT1は、第1のセッションのために音声パケット1を送信し、次いで、第2のセッションのためにデータパケット1を送信する。そして、AT1は、第1のセッションのために音声パケット2を送信し、次いで、第2のセッションのためにデータパケット2を送信する。そして、AT1は、第1のセッションのために音声パケット3を送信し、次いで、第2のセッションのためにデータパケット3を送信する。この時点において、AT1のユーザが、AT1のマイクロフォンに向かって話すのを止めると仮定する。したがって、AT1は、無音パケットを音声パケット4として送信し、無音パケットは、無音フレームのみを含む音声パケットに相当する。無音パケットは、比較的少量のデータペイロードを含み、一般に、バックグラウンドのコンフォートノイズのみを含むが、本物の音声パケットと同じQoSを有するものとしてネットワークで扱われる。理解されるように、音声とメディアを同時に送る状況では、これらの無音パケットは、ファイル転送セッションまたは第2のセッションのためのデータを代わりに送ることができたであろうパケットである。その後、AT1は、第2のセッションのためのデータパケット4を送り、最終的に、AT2は、自身の音声応答パケット1により応答することによって、AT1の質問に応答する。理解されるように、図7Aにおいて、AT1は、実際の音声データがほとんどまたはまったく含まれていない場合であっても、無音パケットを送る。したがって、図7Bを参照して次で説明されるように、音声セッションが行われると同時にファイル転送が行われる同時セッションでは、無音パケットを圧縮することができ、ファイル転送セッションのためのデータパケットを代わりに送ることができる。したがって、図7Bは、ストリーミングマルチメディアセッションのための無音フレームが圧縮され、低QoSのファイル転送セッションまたは非QoSのファイル転送セッションのためのより多数のデータパケットが送信される、本発明の実施形態を示す。図7Bを参照すると、700Bから736Bは、図7Aの700Aから736Aにそれぞれ実質的に対応するので、簡潔にするためにさらに説明はされない。第2のセッションのためのデータパケット3を735Bにおいて送信した後、待ち行列の次のストリーミング音声パケットが無音パケットに相当すると、AT1が判定する。本明細書で用いられる場合、無音パケットは一連の無音フレームに相当し得る。たとえば、無音が閾値期間に達する一連の無音フレームが740Bで検知されると、このことにより、無音パケットが検知されることになり得る。なぜなら、次の音声パケットは、無音フレームしか含まず、実際の音声データを含まないからである。ある例では、EVDOプロトコルは、20msごとに無音フレームを特定し、この場合、AT1は、次の音声パケットに含まれることになる20msのフレームの数を数えることができ、これらの20msのフレームの各々が無音フレームである場合、AT1は次の音声パケットが無音パケットであると判定する。さらに、各無音フレームは一般に、標準的な方式で構築されているので、無音フレームは比較的検知しやすいことがある。したがって、AT1は、各音声フレームを、所定の無音フレームと比較することができる。テンプレートとして用いるために単一の無音フレームを記憶することで、AT1は、テンプレートの無音フレームと、待ち行列にある音声パケットを比較して、特定の音声パケットが無音フレームを搬送しているかどうかを判定することができる。待ち行列の次のストリーミング音声パケットが無音パケットに相当すると、740Bで判定した後、AT1は、無音パケットを圧縮し、無音パケットまたは音声パケット4を搬送することになっていたスロットにおいて、第2のセッションのための待ち行列の次のデータパケットをスケジューリングする。そして、AT1は、最初は第1のセッションの音声パケット4をスケジューリングされていたスロットで、第2のセッションのための待ち行列の次のデータパケットを送信する。AT2は、751Bにおいて予定されていないデータパケット4を受信し、第2のセッションのための非ストリーミングデータパケットまたは非音声データパケットの連続した受信を、AT1が第1のセッションのための無音パケットを圧縮したことの表れであると解釈し、これにより、一連の無音フレームを含む無音パケットをAT1が実際に送信していた場合にAT2が有していたであろう、コンフォートノイズを再生する。そして、AT1は、データパケット4が無音パケットを置き換える前に、最初はデータパケット4の送信をスケジューリングされていたスロットで、第2のセッションのためのデータパケット5を送信する。何らかの後の時点で、AT2は、固有の音声応答パケット1により応答することによって、AT1の質問に応答する。したがって、ストリーミング通信セッションがファイル転送セッションと同時に行われる時に、無音パケットを圧縮することによって、ストリーミングセッションの音声パケットよりも通常は優先順位の低い、ファイル転送セッションのためのデータパケットが代わりに送られる。図7Cは、ストリーミングマルチメディアセッションのための無音フレームが圧縮され、低QoSのファイル転送セッションまたは非QoSのファイル転送セッションのためのより多数のデータパケットが送信される、本発明の別の実施形態を示す。具体的には、無音パケットの圧縮が、送信AT1ではなくアプリケーションサーバ170で行われることを除き、図7Cは、いくつかの面で図7Bと同様である。図7Cを参照すると、700Cから736Cは、それぞれ図7Aの700Aから736Aに、およびまたはそれぞれ図7Bの700Bから736Bに実質的に対応するので、簡潔にするためにさらに説明はされない。図7Cを参照すると、735Cおよび736Cにおいて第2のセッションのためのデータパケット3を送信した後、AT1は、第1のセッションのために、音声パケット4をアプリケーションサーバ170に送信する。図7Cの実施形態では、音声パケット4は、所与の数の無音フレームを含む無音パケットに相当することが、仮定され得る。アプリケーションサーバ170は、音声パケット4を受信して評価し、音声パケット4が無音パケットであると判定する。次のストリーミング音声パケットが4が無音パケットに相当すると、745Cにおいて判定した後、アプリケーションサーバ170は、無音パケットを圧縮して、音声パケット4を送る代わりに、AT2のためのAT1から受信された次のパケットを、スケジューリングすると決定する。したがって、AT1は次いで、第2のセッションのための待ち行列の次のデータパケットを、アプリケーションサーバ170に送信する。この例では、データパケット4は、AT1において、スケジューリングされたスロットにおいて変えられることなく送られる。アプリケーションサーバ170は、データパケット4を受信し、最初は第1のセッションの音声パケット4をスケジューリングされていたスロットで、データパケット4をAT2に転送する756C。AT2は、予定されていないデータパケット4を受信し、第2のセッションのための非ストリーミングデータパケットまたは非音声データパケットの連続した受信を、アプリケーションサーバ170が第1のセッションのための無音パケットを圧縮したことの表れであると解釈し、これにより、一連の無音フレームを含む無音パケットをAT1が実際に送信していた場合にAT2が有していたであろう、コンフォートノイズを再生する。何らかの後の時点で、AT2は、固有の音声応答パケット1により応答することによって、AT1の質問に応答する。したがって、ストリーミング通信セッションがファイル転送セッションと同時に行われる時に、無音パケットを圧縮することによって、ストリーミングセッションの音声パケットよりも通常は優先順位の低い、ファイル転送セッションのためのデータパケットが、代わりにアプリケーションサーバ170により送られる。図8Aは、従来のファイル転送セッションの終了または完了に注目した処理を示す。図8Aを参照すると、アプリケーションサーバ170は、AT1からAT2への1つまたは複数のファイルの転送を容易にするために、ファイル転送セッションをセットアップする。図8Aの例では、ファイル転送セッションは、複数のデータパケット1Nの転送に相当すると仮定することができ、N≧3である。したがって、800Aにおいてファイル転送セッションがセットアップされた後、AT1は、ファイル転送セッションのためのデータパケット1N2をAT2に送る。809Aにおいて、アプリケーションサーバ170は、データパケット1N2に対して確認応答する。AT2がデータパケット1N2の各々を受信するので、AT2はまた、データパケット1N2の各々に対する確認応答をアプリケーションサーバ170に送り返すと、仮定する。次に、AT1がデータパケットN1およびNを送り、これらはファイル転送セッションのための最後の2つのパケットである。この時点において、AT1は、ファイル転送セッションのためのパケットのすべてをAT2に送信しているので、AT1は825Aにおいてデータの送信を停止する。しかし、やはり825Aにおいて、AT1は送信されたデータパケットのすべてに対するACKをまだ受信しておらず、NACKがデータパケットN1およびまたはデータパケットNに対して受信される可能性があり、その場合パケットの再送信が要求されるので、AT1はTCHを保持する。829Aにおいて、アプリケーションサーバ170は、データパケットN1およびNに対して確認応答し、その後、AT1はTCHを切断する。この例では、AT2は最終的に、データパケットN1とデータパケットNの両方に対するACKも送ると、仮定する。理解されるように、データパケットN1およびNが図8Aで示されるように確認応答される場合、AT1は、ファイル転送セッションのために実際に必要な時間よりも長く、不必要にTCHを保持する。また、図8Bを参照して次に説明されるように、データパケットN1およびまたはNの再送信が必要とされる場合、これらのデータパケットの最初の送信から、データパケットの最終的な再送信までの期間は、AT1がTCHを有するが実際にデータを送信していない、浪費時間に相当する。図8Bは、ファイル転送セッションの終わりにおける、AT1とアプリケーションサーバ170との間のシグナリングに注目した、別の従来の処理を示すので、AT2とアプリケーションサーバ170との間のシグナリングが点線により示される。図8Bを参照すると、800Bから810Bは、図8Aの800Aから810Aにそれぞれ実質的に対応するので、簡潔にするためにさらに説明はされない。データパケット1N2に対するACKを受信した後、AT1は、データパケットN1の送信を試み、データパケットNの送信を試みる。図8Bの実施形態では、820Bおよび825Bにおいてそれぞれ、データパケットN1とデータパケットNの両方の送信の試みが失敗すると、仮定する。830Bにおいて、図8Aの825Aにおけるように、AT1はデータの送信を停止し、TCHを保持する。次に、アプリケーションサーバ170は、データパケットN1およびNに対するNACKを、AT1に送る。また、所与の期間の後、AT2はまた、データパケットN1およびNのためのNACKを、アプリケーションサーバ170に送ることを決定し、838Bにおいて、NACKが、AT2からアプリケーションサーバ170に送られる。したがって、AT1は、840Bおよび841B、ならびに845Bおよび846Bにおいてそれぞれ、データパケットN1およびNを再送信する。アプリケーションサーバ170は、AT1からのデータパケットN1およびNに対して確認応答し、その後、AT1はTCHを切断する。AT2はまた、アプリケーションサーバ170からの、AT2における受信が成功したデータパケットN1およびNに対して、確認応答する。図8Cおよび図8Dを参照してここで説明されるように、本発明の実施形態は、送信ATがTCHを有するがデータを送信していない期間における、データパケットの機会主義的な再送信または先取り的な再送信を対象とする。図8Bと同様に、図8Cおよび図8Dは、AT1とアプリケーションサーバ170との間のシグナリングに各々注目するので、AT2とアプリケーションサーバ170との間のシグナリングは、点線により示される。図8Cを参照すると、800Cから821Cは、図8Aの800Aから821Aにそれぞれ実質的に対応するので、簡潔にするためにさらに説明はされない。データパケットN1およびNを、815Cおよび816Cにおいてそれぞれ送信した後、単にTCHを保持して、AT2からのACKまたはNACKを待機するのではなく、AT1は、TCHを維持して、データパケットN1およびNへのACKまたはNACKが実際に受信される前に、データパケットN1およびNを先取り的に再送信することを決定する。したがって、AT1は、830Cおよび835Cにおいてそれぞれ、データパケットN1およびNをアプリケーションサーバ170に再送信し、アプリケーションサーバ170は、831Cおよび836Cにおいてそれぞれ、データパケットN1およびNをAT2に転送する。アプリケーションサーバ170は、データパケットN1およびNに対して確認応答し、その後、AT1はTCHを切断する。また、AT2は、アプリケーションサーバに対して、データパケットN1およびNへの確認応答を行う。837CでAT1において受信されるACKは、815Cから820CにおけるデータパケットN1およびNの最初の送信と、830Cから835CにおけるデータパケットN1およびNの再送信とのいずれかのためのものであってよい。さらに、図8Cは、データパケットN1およびNの単一の再送信を示すが、ACKまたはNACKが、アプリケーションサーバ170から受信されるまで、または所与の回数受信されるまで、AT1は単に、データパケットN1およびNの再送信を続けてもよいことを理解されたい。さらに、図8Cは、ファイル転送セッションのためのデータパケットのストリームの中の最後の2つのデータパケットに対して再送信が実行される例を対象とするが、他の実施形態では、最後の3つのパケット、最後の4つのパケット、最後のパケットのみなどのような、異なる数のパケットについて、上で説明された先取り的なパケットの再送信を実行することができる。図8Dを参照すると、800Dから825Dは、図8Bの800Bから825Bにそれぞれ実質的に対応するので、簡潔にするためにさらに説明はされない。データパケットN1およびNの送信の試みが、820Dおよび825Dにおいてそれぞれ失敗した後、単にTCHを保持して、アプリケーションサーバ170からのACKタイムアウトまたはACKまたはNACKを待機するのではなく、AT1は、TCHを維持して、ACKまたはNACKの前に、データパケットN1およびNを先取り的に再送信することを決定する。したがって、AT1は、831Dおよび836Dにおいてそれぞれ、データパケットN1およびNをアプリケーションサーバ170に再送信し、アプリケーションサーバ170は、836Dおよび841Dにおいてそれぞれ、データパケットN1およびNをAT2に転送する。何らかの後の時点において、AT1は、アプリケーションサーバ170から、データパケットN1およびNに対するACKを受信すると仮定する。AT1において845Dで受信されるACKは、831Dおよび835Dにおける、データパケットN1およびNの再送信のためのものであることが、理解されよう。この時点において、AT1はTCHを切断することができる。何らかの後の時点において、AT2はまた、アプリケーションサーバ170に対して、データパケットN1およびNを受信したことを確認応答することができる。さらに、図8Dは、データパケットN1およびNの単一の再送信を示すが、ACKタイムアウトが判定されるまで、または、ACKもしくはNACKが、アプリケーションサーバ170から受信されるまで、または所与の回数受信されるまで、AT1は単に、データパケットN1およびNの再送信を続けてもよいことが、理解されよう。さらに、図8Dは、ファイル転送セッションのためのデータパケットのストリームの中の最後の2つのデータパケットに対して再送信が実行される例を対象とするが、他の実施形態では、最後の3つのパケット、最後の4つのパケット、最後のパケットのみなどのような、異なる数のパケットについて、上で説明された先取り的なパケットの再送信を実行することができる。さらに、図8Cおよび図8Dは、データパケットの先取り的な再送信が、ファイル転送セッションの予想される終わりの時点の近くで行われる例を各々示すが、TCHがATにより維持されて連続的に用いられない、パケットの先取り的な再送信を引き起こすために、他の条件が用いられてもよいことが理解されよう。たとえば、送信者は、実際のネットワーク条件を計測していてもよく、ネットワーク条件が貧弱であると判定され、損失が存在する可能性が高い場合に、送信者は、パケットの最後のウィンドウを楽観的に再送信してもよい。あるいは、送信者は、接続の経路全体でどれだけのパケットが失われたかを測定する所与のタイプの学習アルゴリズムを利用してもよく、先取り的な再送信をいつ実行すべきかについて、経験に基づく推測を行う。学習アルゴリズムは、さらにより複雑であってもよく、特定のターゲットへの特定の呼、特定の位置への特定の呼、特定の時間帯における特定の呼などの期間全体に拡張されてもよい。ある例では、学習アルゴリズムは、データパケットをいつ先取り的に再送信すべきかを予測できるだけではなく、損失の可能性に基づいて、パケットを再送信する順序を、またはどのパケットを再送信すべきかを、予測することもできる。図8Eは、本発明のある実施形態による、送信ATがTCHを有しデータを送信していない期間における、データパケットの別の機会主義的な再送信または先取り的な再送信を対象とする。図8Cおよび図8Dとは異なり、図8Eは、機械主義的な再送信または先取り的な再送信が、送信AT1ではなく、アプリケーションサーバ170により引き起こされまたは始まる、実装形態を対象とする。したがって、図8Eは、AT2とアプリケーションサーバ170との間のシグナリングに注目するので、AT1とアプリケーションサーバ170との間のシグナリングは、点線により示される。図8Eを参照すると、800Eから810Eは、図8Dの800Dから810Dにそれぞれ実質的に対応するので、簡潔にするためにさらに説明はされない。図8Cと異なり、815Eおよび820Eにおいて、AT1は、データパケットN1およびNのアプリケーションサーバ170への送信に成功する。しかし、アプリケーションサーバ170は、816Eおよび821Eにおいてそれぞれ、データパケットN1およびNのAT2への送信に成功できない。アプリケーションサーバ170は、825Eにおいて、データパケットN1およびNに対して確認応答し、その後、AT1はTCHを切断することができる。830Eにおいて、データパケットN1およびNの1つのインスタンスを単に転送するのではなく、アプリケーションサーバ170は、データパケットN1およびNへのACKまたはNACKがAT2から実際に受信される前に、データパケットN1およびNを先取り的に再送信することを決定する。ある例では、830Eの決定は、データパケットN1およびNが通信セッションのための最後の2つのパケットに相当することを、アプリケーションサーバ170が知っていることに基づき得る。したがって、アプリケーションサーバ170は、835Eおよび840Eにおいてそれぞれ、データパケットN1およびNをAT2へ再送信する。何らかの後の時点において、アプリケーションサーバ170は、データパケットN1およびNに対するACKを、AT2から受信する。この時点において、アプリケーションサーバ170は、データパケットN1およびNの再送信を停止することができる。さらに、図8Eは、データパケットN1およびNの単一の再送信を示すが、ACKまたはNACKが、AT2から受信されるまで、または所与の回数受信されるまで、アプリケーションサーバ170は単に、データパケットN1およびNの再送信を続けてもよいことが、理解されよう。さらに、図8Eは、ファイル転送セッションのためのデータパケットのストリームの中の最後の2つのデータパケットに対して再送信が実行される例を対象とするが、他の実施形態では、最後の3つのパケット、最後の4つのパケット、最後のパケットのみなどのような、異なる数のパケットについて、上で説明された先取り的なパケットの再送信を実行することができる。コンテンツに基づく処理の実施形態が、ここで、図9Aから図9Dを参照して説明される。本明細書で用いられる場合、AT上のディスプレイに関して、ウィンドウは、ディスプレイ上で見えるように構成されるオブジェクトに相当し、AT上で実行される特定のアプリケーションと関連付けられる。たとえば、ATが携帯電話に相当し、ATがモバイルウェブブラウジングアプリケーションを実行しており、特定のウェブページがディスプレイ上でユーザに表示されていると仮定する。この場合、ウィンドウは、ディスプレイ上でATのユーザに特定のウェブページを提示するために、モバイルウェブブラウジングアプリケーションにより用いられる、グラフィカルな構造物に相当する。本明細書で用いられるようなウィンドウは、ATのディスプレイ上で見えるように構成されるが、各ウィンドウは、常にATのディスプレイ上で見えなくてもよいことが、理解されよう。たとえば、そうされなければATのディスプレイ上で見えるであろう特定のウィンドウは、最小化されてもよく、または別のウィンドウと重複してもよいので、ある期間、ATのディスプレイ上で見えなくなる。別の例では、ATのディスプレイ上の異なるウィンドウは、ATのユーザがダウンロードを要求した異なるオブジェクトと関連付けられてよい。モバイルウェブブラウジングアプリケーションの場合、異なるオブジェクトは、ウィンドウの特定のウェブページと関連付けられてATのユーザに表示およびまたは提示されることになる、オブジェクトのセットを含み得る。しかし、これらのウィンドウのすべてを、所与の時間においてアクティブにはできない。たとえば、ATの所与のユーザは、4つの異なるウェブサイトを、モバイルウェブブラウジングアプリケーションを介してATにダウンロードするように要求できるが、所与のユーザは、4つのウェブサイトの1つを、アクティブに、またはAT上で見える状態に設定することができる。あるいは、複数のウィンドウが見えていてもよいが、1つの特定のウィンドウが、他のウィンドウよりも目立つように提示される。理解されるように、このことは、ユーザが他のウェブサイトの前にアクティブなウェブサイトを見ることに興味があることを、示している。しかし、4つのウェブサイトのオブジェクトのダウンロード元のサーバは、従来、所与のユーザがどのウィンドウをアクティブにしたかを認識しない。したがって、図9Aは、本発明のある実施形態における、コンテンツに基づく優先順位の方式に従って、ATにファイルオブジェクトを選択的にダウンロードする処理を示す。図9Aを参照すると、所与のATは、複数のオブジェクトをダウンロードするための、1つまたは複数のユーザ要求を受信する。ある例では、900Aの要求は、AT2のユーザがダウンロードを要求することに相当してもよく、または、AT1のユーザが複数のオブジェクトをAT2に送るのを要求していることを示す、AT1から受信されたメッセージに相当してもよく、またはこれらの組合せに相当してもよい。上で述べられたように、900Aの要求は、ウェブブラウザの複数のウィンドウの中の、異なるウェブサイトと関連付けられる内容を、ロードするための要求に相当し得る。905Aにおいて、AT2は、AT2上のどのウィンドウが現在アクティブであるかを判定する。上で述べられたように、アクティブウィンドウは、AT2のユーザにより現在選択されていない隠れたウィンドウとは対照的に、どのブラウザウィンドウが最もAT2上で目立つかに、相当し得る。次に、AT2は、現在のアクティブウィンドウと関連付けられるべき、900Aからの複数のオブジェクトの少なくとも1つを決定する。たとえば、スポーツのウェブサイト、さらにニュースのウェブサイトをロードすることを、900Aにおいてユーザが要求する場合、スポーツのウェブサイトが表示されることになるウィンドウは、AT2上で最も目立つように表示され、910Aにおいて現在のアクティブウィンドウと関連すると判定されたファイルまたはオブジェクトは、スポーツのウェブサイトと関連付けられるオブジェクトである。915Aにおいて、AT2は、アプリケーションサーバ170からの複数のオブジェクトのダウンロードを要求するように、1つまたは複数のダウンロード要求を構成し、さらに、どのオブジェクトがAT2の現在のアクティブウィンドウと関連付けられるかを示すように、その要求を構成する。理解されるように、どのオブジェクトがATの現在のアクティブウィンドウと関連付けられるかを示すことは、関連付けられたオブジェクトを、関連付けられていないオブジェクトよりも優先するように機能する。920Aにおいて、AT2は、構成された要求をアプリケーションサーバ170に送る。そして、アプリケーションサーバ170は、構成された要求をAT1に送る。920Aで受信される構成された要求に応答して、AT1は、922AでAT1に転送された、構成された要求で示されるオブジェクトの優先順位に従って、複数のオブジェクトのAT2への送信を開始する。たとえば、AT1は、AT2の現在のアクティブウィンドウと関連付けられるオブジェクトをまず提供し、次いで、関連付けられないオブジェクトを提供することができる。同様に、アプリケーションサーバ170は、924AにおいてAT1からオブジェクトを受信し、そして、構成された要求のオブジェクトの優先順位に従って、複数のオブジェクトのAT2への提供を開始する。複数のオブジェクトのダウンロードの間、AT2は、現在のアクティブウィンドウが変化したかどうかを判定する。変化していない場合、AT2は、ダウンロードが完了したかどうかを判定する。ダウンロードが完了した場合、処理は900Aに戻り、そこで、AT2は次のオブジェクトのダウンロード要求を待機する。それ以外の場合、現在のアクティブウィンドウが変化しておらず、ダウンロードがまだ完了していない時は、AT2は、複数のオブジェクトのダウンロードの監視を続ける。しかし、現在のアクティブウィンドウが変化したと、930AにおいてAT2が判定した場合、AT2は、新たな現在のアクティブウィンドウと関連付けられるべき、900Aからの複数のオブジェクトの少なくとも1つを決定する。940Aにおいて、AT1は、アプリケーションサーバ170からの複数のオブジェクトのダウンロードを要求するように、1つまたは複数の補助的なダウンロード要求を構成し、さらに、どのオブジェクトがAT2の新たな現在のアクティブウィンドウと関連付けられるかを示すように、補助的な要求を構成する。945Aにおいて、AT2は、構成された補助的な要求をアプリケーションサーバ170に送る。945Aで受信される構成された補助的な要求に応答して、アプリケーションサーバ170は、複数のオブジェクトをアプリケーションサーバ170からAT2に提供するための、ダウンロードの優先順位を更新し、また、AT1が複数のオブジェクトをアプリケーションサーバ170にアップロードする際の、アップロードの優先順位も更新する。また950Aにおいて、アプリケーションサーバ170は、AT2のウィンドウの変化に基づく新たなまたは更新されたオブジェクトの優先順位に順応するように、AT1がアップロードの順序を調整することを、要求するメッセージを、AT1に送ることができる。ある例では、アップロードおよびダウンロードの順序または優先順位は、同じになるように設定され得る。たとえば、ファイルA、B、C、およびDについて、ダウンロードの順序はABCDであってよく、アップロードの順序もABCDであってよい。しかし、ある代替的な実施形態では、アップロードおよびダウンロードの順序は同じである必要はない。たとえば、ファイルBがアプリケーションサーバ170においてすでにアクセス可能である場合には、ダウンロードの順序はABCDであってよく、アップロードの順序はACDであってよい。その後、AT1は、構成された補助的な要求で示されるオブジェクトの優先順位に従って、複数のオブジェクトのアプリケーションサーバ170への送信を続け、アプリケーションサーバ170は同様に、構成された補助的な要求で示されるオブジェクトの優先順位に従って、複数のオブジェクトのAT2への送信を続ける。理解されるように、図9Aは、ユーザのコンテンツの優先順位が、ユーザがどのウィンドウをアクティブに設定したかに基づいて推測され、推測されたユーザの優先順位が、次いでダウンロードサーバに運ばれる、処理を説明する。別の例では、ユーザは、オブジェクトをダウンロードするための優先順位を、明示的に確立することができるので、ユーザの挙動からユーザの予想される優先順位を推測することは、行う必要がない。したがって、図9Bを参照すると、AT2は、ユーザ規定のオブジェクトのダウンロードの優先順位のセットを受信する。ユーザ規定のオブジェクトのダウンロードの優先順位のセットは、いくつかの異なる方法で構成され得る。たとえば、ユーザ規定のオブジェクトのダウンロードの優先順位のセットは、あるMIMEタイプを他のMIMEタイプよりも優先するように構成され得る。たとえば、AT2は、複数の異なるMIMEタイプのオブジェクトがこれまでにダウンロードされた、頻度を追跡することができ、そして、より頻繁にダウンロードされたMIMEタイプに、より高い優先順位を割り当てることができる。別の例では、多くのウェブサイトで一般的なように、カスケーディングスタイルシートを用いた異なる層のzindexを生成することができ、zindexは所与のページ内の優先順位を伝えることができる。したがって、特定のウェブサイトが音楽に関連するウェブサイトである場合、音声が、他の形態のメディアよりも優先され得る。別の例では、特定のウェブサイトがグラフィックの静止画像または美術に関連する場合、画像が、他の形態のメディアよりも優先され得る。さらなる例では、異なるウェブサイトのzindexは、ウェブサイト間の優先順位を確立するために用いられ得るので、AT2が複数のウェブサイトを同時にロードしようとしている場合、それぞれのウェブサイトのオブジェクトは、それぞれの相対的な優先度に従ってダウンロードされ得る。別の例では、CSS要素ウィジェットを含むウェブページは、特定の順序でウィジェットの順序でzindexを編成し、ユーザ体験を向上させることができる。別の実施形態では、ユーザ規定のオブジェクトのダウンロードの優先順位のセットは、あるアプリケーションのためのファイルを他のアプリケーションのためのファイルよりも優先するものであってよい。ある例では、アプリケーションのタイプは、重要度または緊急性を示すものであり得るので、たとえば、受動的なOSの更新よりも、ウェブブラウジングセッションが優先されるように、より重要なまたはより緊急のアプリケーションに優先権が与えられる。別の例では、AT2は、どの程度頻繁にアプリケーションが使用または実行されるかに関連する、情報を記録することができる。そして、アプリケーションの使用履歴情報は、アプリケーション間の相対的な優先順位を確立するために用いられ得るので、より頻繁に用いられるアプリケーションが、頻繁には用いられないアプリケーションよりも優先される。別の例では、AT2のユーザがファイルのダウンロードを要求するたびに、ファイルのダウンロード要求と関連付けられるタイムスタンプが、AT2に記憶され得る。そして、AT2のユーザがそれぞれのファイルのダウンロードを要求する相対的な時刻が、ファイルのダウンロードの相対的な優先順位を確立するために、用いられ得る。たとえば、より最近に開始されたファイルのダウンロード要求は、ファイルのダウンロードの前の要求または古い要求よりも優先され得る。何らかの後の時点において、AT2は、複数のオブジェクトをダウンロードするための、1つまたは複数のユーザ要求を受信する。905Bの要求は、1つまたは複数のウェブサイトと関連付けられるコンテンツをロードするための要求に、またはある例では、通信セッションの間に別のATからのファイル転送を受信するための要求に、相当し得る。910Bにおいて、AT2は、アプリケーションサーバ170からの複数のオブジェクトのダウンロードを要求するように、1つまたは複数のダウンロード要求を構成し、さらに、900Bからの、ユーザ規定のオブジェクトのダウンロードの優先順位のセットを示すように、その要求を構成する。915Bにおいて、AT2は、構成された要求をアプリケーションサーバ170に送る。そして、アプリケーションサーバ170は、構成された要求をAT1に送る。構成された要求に応答して、AT1は、構成された要求で示される、ユーザ規定のオブジェクトのダウンロードの優先順位のセットに従って、複数のオブジェクトのアプリケーションサーバ170への送信を開始し920B、アプリケーションサーバ170は同様に、構成された要求で示されるオブジェクトの優先順位に従って、複数のオブジェクトをAT2へ送る925B。理解されるように、AT1から見ると、オブジェクトの優先順位は、ダウンロードの優先順位ではなくアップロードの優先順位として解釈され得る。いずれの場合でも、ファイルがAT1からアップロードされる順序は、ファイルがアプリケーションサーバ170からAT2にダウンロードされる順序と一致するように保たれる。別の実施形態では、図9Bを参照すると、AT2は、AT1からオブジェクトを受信している複数のATを表すものであってよい。この場合、AT1が複数のATにオブジェクトを送信するファイルの順序に、複数のATのすべてが影響を与えることを許され得るのではないことが、理解されよう。ある例では、アプリケーションサーバ170は、複数のATから、最初に要求されたユーザ規定のオブジェクトのダウンロードの優先順位を転送することができ、その後、後で要求されたユーザ規定のオブジェクトのダウンロードの優先順位を、拒絶することができる。ある代替的な例では、アプリケーションサーバ170は、後で要求されたユーザ規定のオブジェクトのダウンロードの優先順位を、AT1に転送することができ、これによってAT1は、最も新しく転送されたユーザ規定のオブジェクトのダウンロードの優先順位に従うが、それは、後で要求されたユーザ規定のオブジェクトのダウンロードの優先順位が、最初に要求されたまたは前に要求されたユーザ規定のオブジェクトのダウンロードの優先順位と比較して優先順位がより高いATから、アプリケーションサーバ170において受信された場合のみである。別の例では、AT2が複数のATの代表である場合、アプリケーションサーバ170は、それぞれのATからの、異なる要求されたユーザ規定のオブジェクトのダウンロードの優先順位の、重み付けまたは平均を実行することができる。たとえば、閾値の割合のATが、ユーザ規定のオブジェクトのダウンロードの優先順位の特定のセットを要求する場合、アプリケーションサーバ170は、ユーザ規定のオブジェクトのダウンロードの優先順位のその特定のセットのみに対して動作を実行でき、または、アプリケーションサーバ170は、複数の要求されたユーザ規定のオブジェクトのダウンロードの優先順位にわたり共通の要素を求め、その共通の要素のみに対して動作を実行できる、などである。別の実施形態では、図9Bを参照すると、AT1は、AT2にオブジェクトを転送している複数のATの代表であってよい。この場合、ユーザ規定のオブジェクトのダウンロードの優先順位のセットは、あるATからのオブジェクトを他のATからのオブジェクトよりも優先するように構成され得る。この場合、ある例では、915Bにおける複数のオブジェクトのための構成された要求は、AT2により待ち行列に入れられてよく、そして、ATがそれぞれのオブジェクトの転送を完了した後、高優先度から低優先度の順序で、複数のATに連続して送られ得る。あるいは、AT2は、AT2に対するATのそれぞれの優先順位を、アプリケーションサーバ170に通知してもよい。この場合、915Bにおける複数のオブジェクトのための構成された要求は、複数のATの各々に送られてよく、アプリケーションサーバ170は、次いで、ユーザ規定のオブジェクトのダウンロードの優先順位のAT2のセットに対応する順序で、オブジェクトをAT2に送達するために、複数のATから受信されたオブジェクトのバッファリングを試みることができる。別の例では、図9Cを参照して以下で説明されるように、AT2の所与のユーザは、異なる通信セッションと関連付けられたウィンドウを見進むことができる。どのウィンドウがアクティブであるかに応じて、アクティブウィンドウと関連付けられないセッションのメディアのすべてまたは一部は、優先順位が下げられ得る。たとえば、AT2でウィンドウが重なっているために、部分的な映像しか表示されていないと仮定する。この場合、示されているウィンドウの一部のみが、映像の一部として送られ得る。AT2は、表示される映像部分を示す何らかのものを伝達することができ、アプリケーションサーバ170は、その表示される映像部分から見えない部分をフィルタリングできる。図9Cを参照して、AT2が、第1の接続を通じて、ウィンドウの第1のセットと関連付けられるストリーミング通信セッションに参加していると仮定する。ある例では、第1の接続は、単一のタイプのメディアまたは複数のタイプのメディアを搬送する、単一の接続に相当し得る。別の例では、第1の接続は複数の異なる接続に相当してよく、各タイプのストリーミングメディアは、そうした接続の異なる1つに割り当てられている。また、ストリーミング通信セッションは、AT2と、サーバ、AT1、または何らかの他のATとの間のセッションであってよく、図9Cでは、AT1はストリーミング通信セッションの一部として明示的には示されていないが、これは可能な実装形態である。次に、AT2は、ファイル転送セッションを開始して送信AT1から第2の接続を通じて1つまたは複数のオブジェクトを転送するために、ウィンドウの第2のセットに切り替える。たとえば、ストリーミング通信セッションは、高QoSの接続により支援される映像会議に相当してよく、ファイル転送セッションは、低QoSの接続により、またはさらにはQoSの程度が何ら保証されない接続により支援され得る。AT2が、現在のアクティブウィンドウを、ストリーミング通信セッションと関連付けられたウィンドウから、ファイル転送セッションと関連付けられたウィンドウに切り替えたので、AT2は、910Cにおいて、ストリーミング通信セッションの少なくとも一部の優先順位を下げるための要求を送る。ある例では、ストリーミング通信セッションが、映像のみのセッションに相当する場合、優先順位を下げる要求は、AT2が映像を表示するウィンドウを見てもいないので、映像フィードをAT2にこれ以上送らないように要求することができる。さらなる例では、ストリーミング通信セッションが、映像および音声を含むフィードに相当する場合、優先順位を下げる要求は、音声フィードまたはストリーミング通信セッションの一部をAT1に送るように依然として要求する一方で、映像フィードをこれ以上AT1に送らないように要求することができる。この例では、第1の接続が音声および映像のために異なる接続を含む場合、優先順位を下げる要求は、映像フレームがAT2に運ばれる速度を下げることを要求し、または代替的には、映像接続を一時的に中断または停止することを要求するように、構成され得る。したがって、915Cにおいて、アプリケーションサーバ170は、910Cからの優先順位を下げる要求に従って、AT1へのストリーミング通信セッションを修正する。920Cにおいて、AT1は、ファイル転送セッションの第2の接続を通じて1つまたは複数のオブジェクトをダウンロードすることを要求し、アプリケーションサーバ170は、ダウンロード要求をAT1に転送する。AT1は、要求されたオブジェクトのアプリケーションサーバ170への送信を開始し、アプリケーションサーバ170は、第2の接続を通じて、AT1からAT2に要求されたオブジェクトを送る。ある例では、AT2は、話題になっている図のような、ストリーミング通信セッションのセッション参加者からAT2に電子メールで送られる写真を、ダウンロードすることができる。代替的には、ファイル転送セッションは、ストリーミング通信セッションと直接関連付けられる必要はない。この時点において、ウィンドウの第1のセットが再びアクティブ化され、AT2が再びストリーミング通信セッションに完全に参加できるように、AT2は、ストリーミング通信セッションに再び切り替えると、仮定する。したがって、AT1は、ストリーミング通信セッションの優先順位が下げられた部分が、高い優先度を与えられるように要求するための、再優先順位付け要求を送る。たとえば、再優先順位付け要求は、映像会議の中止された映像フィードを再開するように、要求することができる。したがって、940Cにおいて、アプリケーションサーバ170は、935Cからの再優先順位付け要求に従って、AT1へのストリーミング通信セッションを修正する。図9Cの実施形態では、特定のTCP接続と関連するアプリケーションサーバ170およびまたはAT1に、ウィンドウの特性のセットが通知される方式を修正するために、所与のトランスポートプロトコルが用いられ得る。たとえば、第1のTCP接続はウィンドウの第1のセットと関連付けられてよく、第2のTCP接続はウィンドウの第2のセットと関連付けられてよい。これにより、910Cの優先順位を下げる要求は、ウィンドウの第1のセットの優先順位が低いことを反映するように、ウィンドウの第1のセットの第1のTCP接続のために通知されるウィンドウが小さいという構成に相当してよく、935Cの再優先順位付け要求は、ウィンドウの第2のセットの優先順位が高いことを反映するように、ウィンドウの第2のセットの第2のTCP接続のために通知されるウィンドウが大きいという構成に相当してよい。ウィンドウの第1のセットおよび第2のセットは、TCP接続に各々関連しているものとして上で説明されるが、本発明の他の実施形態では、接続の少なくとも1つはTCPである必要はなく、むしろ、UDPまたは何らかの他のワイヤレストランスポートプロトコルであってよいことが、理解されよう。図9Aから図9Cは、オブジェクトまたはメディアが、コンテンツの推測される優先順位または明示的な優先順位のいずれかに基づいてAT2に選択的に提供される例を示すが、図9Aから図9Cでは、実際にAT2に提供される任意のデータは、完全な品質のレベルで運ばれることが、全般に仮定される。図9Dを参照して以下で説明される、ある代替的な実施形態では、AT2が制限された環境に位置する場合、AT2は、再フォーマットされたオブジェクトのダウンロードが、その制限された環境に順応するようにすることができる。本明細書で用いられる場合、制限された環境は、AT2のダウンロード要求の性能低下と関連付けられると考えられる、任意の条件、任意の定性的な測定値、およびまたは任意の定量的な測定値として定義される。たとえば、制限された環境は、AT2が、高干渉のゾーン、1xネットワークで動作しており、かつまたは、AT2が複数のセッションに同時に参加している場合のようにAT2のリソースに対する負荷が高い、帯域幅が制限された環境に相当し得る。別の例では、AT2がEVDOネットワークに接続され、EVDOのT2Pが所与の閾値を下回る場合、または、CapProbeもしくはCapProbeのようなプログラムを用いた帯域幅の測定結果が所定の閾値を下回る場合、AT2は制限された環境にあると考えられ得る。図9Dを参照すると、AT2は、複数のオブジェクトをダウンロードするための、少なくとも1つの要求を受信する。上で述べられたように、複数オブジェクトのダウンロード要求は、ウェブサイトをロードするための要求、またはある例では、通信セッションの間に別のATからのファイル転送を受信するための要求に、相当し得る。別の例では、複数オブジェクトのダウンロード要求は、写真のスライドショーに相当し得る。905Dでは、ダウンロード要求に対して制限されていると見込まれる制限された環境で、AT2が現在動作しているかどうかを、AT2が判定する。理解されるように、現在の動作環境が制限された動作環境かどうかをAT2が判定できる、いくつかの異なる方式がある。たとえば、要求されたデータ量の、普通のユーザがそのデータ量を受信するのにかかると予想する時間に対する比率が、所定の量よりも長くかかる場合、環境はダウンロード要求に対して制限され得る。この比率は、ある例では、それぞれのATまたはUEにおいて事前に構成され得る。したがって、ATが10キロバイトのファイルのダウンロードを要求された場合、1xネットワークに接続されていることは制限された環境ではないが、要求されたダウンロードが10メガバイトのファイルに対するものである場合、1xネットワークは制限された環境であり得る。同様に、ATが10メガバイトのファイルのダウンロードを要求された場合、4Gネットワークに接続されていることは制限された環境ではないが、要求されたダウンロードが10ギガバイトのファイルに対するものである場合、4Gネットワークですら制限された環境であり得る。別の例では、AT2が1xネットワークにおいて動作している場合、AT2は単純に、環境は制限されているとすることができる。別の例では、AT2は、最近の通信セッションで得られたデータ速度を評価することができ、データ速度が比較的低い場合、または閾値よりも低い場合、AT2は環境が制限されていると判定することができる。別の例では、903Dで示されるように、アプリケーションサーバ170は、AT2の現在の接続品質のレベルを示す接続品質インジケータを、AT2に送ることができる。たとえば、接続品質インジケータは、アプリケーションサーバ170により測定されたような、AT2の現在のサービングネットワークと関連するネットワーク遅延、混雑または損失を、示すものであってよい。理解されるように、帯域幅が広がりレイテンシが小さくなると、ユーザの体験または知覚の範囲では品質低下がなくなる点が最終的には存在するので、帯域幅およびまたはレイテンシの変化を評価して、特定の動作環境が制限されているかどうかを判定することができる。さらなる例では、AT2がすでに、アプリケーションサーバ170に対して確立された接続を有する場合、接続品質インジケータは、アプリケーションサーバ170によりAT2に送られるACKパケットまたはデータパケット内で、AT2に運ばれ得る。たとえば、アプリケーションサーバ170は、AT2の現在のネットワークの接続品質に関連する特別な知識を有することがあり、AT2の現在のネットワークは、たとえばAT2の地理的な位置に一部基づき得る。そして、アプリケーションサーバ170は、コードまたはビットセッティングによって、AT2へのパケットのヘッダ部分を構成して、特別な知識を伝達することができる。905Dにおいて、AT2が環境を制限された環境であると判定すると、仮定する。したがって、AT2は、アプリケーションサーバ170からの複数のオブジェクトのダウンロードを要求するように、1つまたは複数のダウンロード要求を構成し、さらに、AT2が制限された環境で動作していることを示すように、その要求を構成する。915Dにおいて、AT2は、構成された要求をアプリケーションサーバ170に送り、アプリケーションサーバ170は、構成された要求をAT1に転送する。構成された要求に応答して、AT1は、自身の接続を介して、要求されたオブジェクトのアプリケーションサーバ170への送信を開始する。AT1から複数のオブジェクトを受信すると、アプリケーションサーバ170は、変更または修正されるべき少なくとも1つのオブジェクトの送達時間を減らすために、第1の実現形態から第2の実現形態へ、複数のオブジェクトの少なくとも1つを、変更または修正する。ある例では、グラフィックオブジェクトについて、922Dの修正は、グラフィックオブジェクトの解像度を下げることに相当し得る。別の例では、音声オブジェクトについて、922Dの修正は、音声オブジェクトの品質を下げることに相当し得る。922Dの修正の後、任意の修正されたオブジェクトが修正されていないバージョンの代わりに送られるように、アプリケーションサーバ170は、複数のオブジェクトのAT2への送信を開始する。930Dにおいて、何らかの後の時点で、アプリケーションサーバ170は、少なくとも1つのオブジェクトを、最初の形式または修正されていない形式でAT2に送るべきかどうかを、判定する。ある例では、アプリケーションサーバ170は、すべての他の複数のオブジェクトがAT2に送られた後、またはAT2がもう制限された環境では動作していないというメッセージに応答して、または閾値の期間の後などに、完全な品質の最初の形式で少なくとも1つのオブジェクトを送ると、決定することができる。AT2が、少なくとも1つのオブジェクトを最初の形式で送信しないと決定した場合、処理は925Dに戻り、アプリケーションサーバ170は、複数のオブジェクトのAT2への送信を続ける。それ以外の場合、AT2が、少なくとも1つのオブジェクトを最初の形式でAT2に送信すると決定した場合、アプリケーションサーバ170は、920Dで修正されたオブジェクトを、元の、または修正されていない第1の実現形態でAT2に送りつつ、複数のオブジェクトのAT1への送信を続ける。図9Dでは、ダウンロード要求900Dが、リアルタイムメディアまたはストリーミングメディアに相当することが可能である。この場合、たとえば低解像度の映像がユーザに送られるのであれば、ユーザがより高性能なネットワークに再接続した場合、または他の方法で接続が改善した場合に、高解像度の映像を送ることにはほとんど価値がないことが、理解されよう。この場合、本発明のある実施形態では、ブロック930Dおよび935Dは、ストリーミングセッションまたはリアルタイムセッションに対しては省略される可能性があってよく、このとき、古いファイルがより低い品質で送られたとしても、古いファイルはより新しいファイルよりも価値が低い。図9Aから図9Dは、上では別々の処理として説明されたが、本発明の他の実施形態では、図9Aから図9Dの2つ以上は、協調的に実施され得ることが理解されよう。たとえば、図9A、図9Bおよびまたは図9Cの、優先順位付けに注目する実施形態は、図9Dの制限された環境に注目する実施形態と連携して、実施され得る。この場合、922Dにおいて複数のオブジェクトの実現形態を修正することに加えて、かつまたはその代わりに、AT2の制限された環境への移行により、図9A、図9Bおよびまたは図9Cのオブジェクト転送の優先順位が、修正されるようになり得る。別の例では、図9A、図9Bおよびまたは図9Cは単に、図9Dと並行して実行されてもよいが、図9Dにより実際には直接の影響を受けなくてもよい。たとえば、図9DでA1からAT2に転送されるものとして説明される複数のオブジェクトは、図9A、図9Bおよびまたは図9Cのそれぞれのオブジェクトの転送の優先順位に基づいた順序で、提供され得る。さらに、図9Aから図9Dの各々は、オブジェクトがAT1からAT2に転送される実施形態を対象とするが、AT1およびまたはAT2のいずれかが、複数のATの代表であってもよいことが理解されよう。言い換えると、図9Aから図9DでAT2に到達するオブジェクトは、代替的には、単一のAT1ではなく複数のATから発信されてよい。また、図9Aから図9DでAT1から送られるオブジェクトは、代替的には、単一のAT2ではなく複数のターゲットATに送られてよい。AT2が、AT1からオブジェクトを受信している複数のATの1つである場合、図9Aから図9Cに関して、AT1からオブジェクトを受信している各ATは、固有のそれぞれのオブジェクト転送の優先順位と関連付けられてよいことが、理解されよう。したがって、図9Aから図9Cの処理は、各々のそれぞれの受信ATに対して実行されてよく、AT2からのオブジェクトが、それぞれの受信ATに異なる順序で送達されるようになる可能性がある。図9Dに関して、制限された環境へ受信ATの1つが入っても、制限された環境にはない他の受信ATへのオブジェクトの転送は制限されなくてもよいことが、理解されよう。したがって、図9Dの実行は、受信ATのすべてには影響を与えなくてもよい。さらに、図9Aから図9Dのいずれかにおいて、転送されているオブジェクトの1つまたは複数はある満了時間と関連付けられてよく、その満了時間の後、1つまたは複数のオブジェクトと関連付けられる値は下げられ、かつまたは完全に削除される。したがって、オブジェクトの転送の間、所与のエンティティが、1つまたは複数のオブジェクトの関連する満了時間に対する現在の時間を確認し、1つまたは複数のオブジェクトの優先順位を動的に下げ、かつまたは、1つまたは複数のオブジェクトを完全に脱落させるかどうかを、判定することができる。ある例では、この動作は、AT1において、図9Aの924A、図9Bの920B、図9Cの924C、およびまたは図9Dの920Dの間に、行われ得る。あるいは、この動作は、アプリケーションサーバ170において、図9Aの925A、図9Bの925B、図9Cの925C、およびまたは図9Dの925Dの間に、行われ得る。情報および信号は、多種多様な技術および技法のいずれかを使用して表すことができることを当業者は理解されよう。たとえば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界または磁性粒子、光場または光学粒子、あるいはそれらの任意の組合せによって表され得る。さらに、本明細書で開示した実施形態に関連して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装できることを、当業者は理解されよう。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを、上記では概してそれらの機能に関して説明した。そのような機能をハードウェアとして実装するか、ソフトウェアとして実装するかは、特定の適用例および全体的なシステムに課される設計制約に依存する。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装することができるが、そのような実装の決定は、本発明の範囲からの逸脱を生じるものと解釈すべきではない。本明細書で開示する実施形態に関して説明する様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタルシグナルプロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイもしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書で説明する機能を実行するように設計されたそれらの任意の組合せで実装または実行することができる。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、または任意の他のそのような構成として実装され得る。本明細書で開示する実施形態に関して説明した方法、シーケンスおよびまたはアルゴリズムは、直接ハードウェアで、プロセッサによって実行されるソフトウェアモジュールで、またはこの2つの組合せで具体化され得る。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CDROM、または当技術分野で知られている任意の他の形態の記憶媒体中に存在し得る。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替として、記憶媒体はプロセッサと一体であり得る。プロセッサおよび記憶媒体はASIC中に存在し得る。ASICはユーザ端末中に存在し得る。代替として、プロセッサおよび記憶媒体は、ユーザ端末中に個別構成要素として存在し得る。1つまたは複数の例示的な実施形態では、説明した機能はハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装する場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶され、または、コンピュータ可読媒体を介して送信され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータ記憶媒体とコンピュータ通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CDROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または、命令もしくはデータ構造の形態の所望のプログラムコードを搬送または記憶するために使用でき、コンピュータによってアクセスできる、任意の他の媒体を含むことができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線、または、たとえば赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、もしくは他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または、赤外線、無線、およびマイクロ波などのワイヤレス技術は媒体の定義内に含まれる。本明細書で使用する場合、ディスクおよびディスクは、コンパクトディスク、レーザディスク、光ディスク、デジタル多用途ディスク、フレキシブルディスク、およびブルーレイディスクを含み、ディスクは、通常、磁気的にデータを再生し、ディスクは、レーザで光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれるものとする。上記の開示は本発明の例示的な実施形態を示すが、添付の特許請求の範囲によって規定される本発明の範囲から逸脱することなく、本明細書において様々な変更および修正を行うことができることに留意されたい。本明細書で説明した本発明の実施形態による方法クレームの機能、ステップおよびまたはアクションは、特定の順序で実行されなくてもよい。さらに、本発明の要素は、単数形で説明または請求されていることがあるが、単数形に限定することが明示的に述べられていない限り、複数形が企図される。