(57)【要約】【課題】データデリバリーに適用できるシステム及び方法を提供する。【解決手段】例えば、サービスオペレータサーバー及び／又は他のコンピュータは、１つ以上の受信器が、ディスパッチされたデータを正しく受信しない場合に、ポイント・ツー・ポイント修理モード及びポイント・ツー・マルチポイント修理モードのいずれを使用すべきか決定するように働く。別の例として、サービスオペレータサーバー及び／又は他のコンピュータは、１つ以上の推定値を計算し、１つ以上の修理サーバーから１つ以上の値を要求し、及び／又は使用すべき修理モードに関する１つ以上の指令を１つ以上の修理サーバーに与える。【選択図】図１
2008546237.tif 000002
【特許請求の範囲】
【請求項１】
時間を計算するステップであって、この計算には、データセットに対するデータセット送信終了時間、バックオフオフセット時間、及びバックオフウインドウが考慮されるステップと、
前記計算された時間に、受け取られた修理要求の数に対する要求を１つ以上の修理サーバーに送信するステップと、
ポイント・ツー・ポイント修理及びポイント・ツー・マルチポイント修理の一方を最も有効な修理モードであると決定するステップと、
前記決定された最も有効な修理モードを１つ以上の修理サーバーに通知するためのステップと、
を備えた方法。
【請求項２】
データのある部分を受信しなかった受信器の数を推定するステップを更に備えた、請求項１に記載の方法。
【請求項３】
ポイント・ツー・ポイントチャンネルオーバーヘッドを推定するステップを更に備えた、請求項１に記載の方法。
【請求項４】
ポイント・ツー・マルチポイントチャンネルオーバーヘッドを推定するステップを更に備えた、請求項１に記載の方法。
【請求項５】
ポイント・ツー・マルチポイント修理セッションロスパーセンテージを推定するステップを更に備えた、請求項１に記載の方法。
【請求項６】
首尾良いデータセット受信の数を推定するステップを更に備えた、請求項１に記載の方法。
【請求項７】
ポイント・ツー・ポイントチャンネルを経てデータユニットをトランスポートするためのコストを推定するステップを更に備えた、請求項１に記載の方法。
【請求項８】
ポイント・ツー・マルチポイントチャンネルを経てデータユニットをトランスポートするためのコストを推定するステップを更に備えた、請求項１に記載の方法。
【請求項９】
修理モードの有効性を推定するステップを更に備えた、請求項１に記載の方法。
【請求項１０】
デジタルビデオブロードキャスティング・フォー・ハンドヘルドのポイント・ツー・マルチポイントが使用される、請求項１に記載の方法。
【請求項１１】
ユニバーサルモバイルテレコミュニケーションズサービスのポイント・ツー・ポイントが使用される、請求項１に記載の方法。
【請求項１２】
データのある部分を受信しなかった受信器の数を推定するステップと、
ポイント・ツー・ポイントチャンネルオーバーヘッドを推定するステップと、
ポイント・ツー・マルチポイントチャンネルオーバーヘッドを推定するステップと、
ポイント・ツー・マルチポイント修理セッションロスパーセンテージを推定するステップと、
ポイント・ツー・ポイント修理モードに対する首尾良い受信の数を推定するステップと、
ポイント・ツー・マルチポイント修理モードに対する首尾良い受信の数を推定するステップと、
ポイント・ツー・ポイント修理モード選択のコストを推定するステップと、
ポイント・ツー・マルチポイント修理モード選択のコストを推定するステップと、
修理モードの有効性を推定するステップと、
ポイント・ツー・ポイント修理及びポイント・ツー・マルチポイント修理の一方を最も有効な修理モードであると決定するステップと、
を備えた方法。
【請求項１３】
ポイント・ツー・ポイントチャンネルにわたりデータユニットをトランスポートするためのコストを推定するステップを更に備えた、請求項１２に記載の方法。
【請求項１４】
ポイント・ツー・マルチポイントチャンネルにわたりデータユニットをトランスポートするためのコストを推定するステップを更に備えた、請求項１２に記載の方法。
【請求項１５】
時間を計算するステップであって、この計算には、データセットに対するデータセット送信終了時間、バックオフオフセット時間、及びバックオフウインドウが考慮されるステップを更に備えた、請求項１２に記載の方法。
【請求項１６】
前記計算された時間に、受け取られた修理要求の数に対する要求を１つ以上の修理サーバーに送信するステップを更に備えた、請求項１２に記載の方法。
【請求項１７】
前記決定された最も有効な修理モードを１つ以上の修理サーバーに通知するステップを更に備えた、請求項１２に記載の方法。
【請求項１８】
修理要求を送信する受信器のうちの一部を推定するステップを更に備えた、請求項１２に記載の方法。
【請求項１９】
ポイント・ツー・ポイント修理モードを使用するように１つ以上の修理サーバーに最初に命令するステップを更に備えた、請求項１２に記載の方法。
【請求項２０】
デジタルビデオブロードキャスティング・フォー・ハンドヘルドのポイント・ツー・マルチポイントが使用される、請求項１２に記載の方法。
【請求項２１】
ユニバーサルモバイルテレコミュニケーションズサービスのポイント・ツー・ポイントが使用される、請求項１２に記載の方法。
【請求項２２】
プログラムコードが記憶されたメモリと、
メモリと通信状態に配置され、前記記憶されたプログラムコードに基づいてインストラクションを実行するためのプロセッサと、
を備え、前記プログラムコードは、前記プロセッサにより実行されたときに、前記プロセッサが、
時間を計算し、この計算には、データセットに対するデータセット送信終了時間、バックオフオフセット時間、及びバックオフウインドウが考慮され、
前記計算された時間に、受け取られた修理要求の数に対する要求を１つ以上の修理サーバーに送信し、
ポイント・ツー・ポイント修理及びポイント・ツー・マルチポイント修理の一方を最も有効な修理モードであると決定し、
前記決定された最も有効な修理モードを１つ以上の修理サーバーに通知する、
というようにさせるシステム。
【請求項２３】
前記プロセッサは、更に、データのある部分を受信しなかった受信器の数の推定を行う、請求項２２に記載のシステム。
【請求項２４】
前記プロセッサは、更に、ポイント・ツー・ポイントチャンネルオーバーヘッドの推定を行う、請求項２２に記載のシステム。
【請求項２５】
前記プロセッサは、更に、ポイント・ツー・マルチポイントチャンネルオーバーヘッドの推定を行う、請求項２２に記載のシステム。
【請求項２６】
前記プロセッサは、更に、ポイント・ツー・マルチポイント修理セッションロスパーセンテージの推定を行う、請求項２２に記載のシステム。
【請求項２７】
前記プロセッサは、更に、首尾良いデータセット受信の数の推定を行う、請求項２２に記載のシステム。
【請求項２８】
前記プロセッサは、更に、ポイント・ツー・ポイントチャンネルを経てデータユニットをトランスポートするためのコストの推定を行う、請求項２２に記載のシステム。
【請求項２９】
前記プロセッサは、更に、ポイント・ツー・マルチポイントチャンネルを経てデータユニットをトランスポートするためのコストの推定を行う、請求項２２に記載のシステム。
【請求項３０】
前記プロセッサは、更に、修理モードの有効性の推定を行う、請求項２２に記載のシステム。
【請求項３１】
デジタルビデオブロードキャスティング・フォー・ハンドヘルドのポイント・ツー・マルチポイントが使用される、請求項２２に記載のシステム。
【請求項３２】
ユニバーサルモバイルテレコミュニケーションズサービスのポイント・ツー・ポイントが使用される、請求項２２に記載のシステム。
【請求項３３】
プログラムコードが記憶されたメモリと、
メモリと通信状態に配置され、前記記憶されたプログラムコードに基づいてインストラクションを実行するためのプロセッサと、
を備え、前記プログラムコードは、前記プロセッサにより実行されたときに、前記プロセッサが、
データのある部分を受信しなかった受信器の数を推定し、
ポイント・ツー・ポイントチャンネルオーバーヘッドを推定し、
ポイント・ツー・マルチポイントチャンネルオーバーヘッドを推定し、
ポイント・ツー・マルチポイント修理セッションロスパーセンテージを推定し、
ポイント・ツー・ポイント修理モードに対する首尾良い受信の数を推定し、
ポイント・ツー・マルチポイント修理モードに対する首尾良い受信の数を推定し、
ポイント・ツー・ポイント修理モード選択のコストを推定し、
ポイント・ツー・マルチポイント修理モード選択のコストを推定し、
修理モードの有効性を推定し、
ポイント・ツー・ポイント修理及びポイント・ツー・マルチポイント修理の一方を最も有効な修理モードであると決定する、
というようにさせるシステム。
【請求項３４】
前記プロセッサは、更に、ポイント・ツー・ポイントチャンネルにわたりデータユニットをトランスポートするためのコストの推定を行う、請求項３３に記載のシステム。
【請求項３５】
前記プロセッサは、更に、ポイント・ツー・マルチポイントチャンネルにわたりデータユニットをトランスポートするためのコストの推定を行う、請求項３３に記載のシステム。
【請求項３６】
前記プロセッサは、更に、時間を計算し、この計算には、データセットに対するデータセット送信終了時間、バックオフオフセット時間、及びバックオフウインドウが考慮される、請求項３３に記載のシステム。
【請求項３７】
前記プロセッサは、更に、前記計算された時間に、受け取られた修理要求の数に対する要求を１つ以上の修理サーバーに送信する、請求項３３に記載のシステム。
【請求項３８】
前記プロセッサは、更に、前記決定された最も有効な修理モードを１つ以上の修理サーバーに通知する、請求項３３に記載のシステム。
【請求項３９】
前記プロセッサは、更に、修理要求を送信する受信器のうちの一部を推定する、請求項３３に記載のシステム。
【請求項４０】
前記プロセッサは、更に、ポイント・ツー・ポイント修理モードを使用するように１つ以上の修理サーバーに最初に命令する、請求項３３に記載のシステム。
【請求項４１】
デジタルビデオブロードキャスティング・フォー・ハンドヘルドのポイント・ツー・マルチポイントが使用される、請求項３３に記載のシステム。
【請求項４２】
ユニバーサルモバイルテレコミュニケーションズサービスのポイント・ツー・ポイントが使用される、請求項３３に記載のシステム。
【請求項４３】
プログラムコードが記憶されたメモリと、
メモリと通信状態に配置され、前記記憶されたプログラムコードに基づいてインストラクションを実行するためのプロセッサと、
前記プロセッサと通信状態に配置されたネットワークインターフェイスと、
を備え、前記プログラムコードは、前記プロセッサにより実行されたときに、前記プロセッサが、
バックオフウインドウ内のある時点に対するポイント・ツー・ポイント修理モードの有効性を推定し、
前記バックオフウインドウ内の前記時点に対するポイント・ツー・マルチポイント修理モードの有効性を推定し、
ポイント・ツー・ポイント修理及びポイント・ツー・マルチポイント修理の一方を最も有効な修理モードであると決定する、
というようにさせるシステム。
【請求項４４】
ポイント・ツー・ポイントチャンネルを経てある量のデータを送信するコストを推定するステップと、
ポイント・ツー・マルチポイントチャンネルを経てある量のデータを送信するコストを推定するステップと、
修理サーバーから、その修理サーバーにより受け取られる修理要求の数を受け取るステップと、
前記修理サーバーから、その修理サーバーから要求されたエンコード記号の数を受け取るステップと、
修理要求の合計数を推定するステップであって、前記修理サーバーにより受け取られた修理要求の数、０と１との間の選択された値、及び修理サーバーの量が考慮に入れられるステップと、
要求されたエンコード記号の合計数を推定するステップであって、前記修理サーバーから要求されたエンコード記号の数、０と１との間の選択された値、及び修理サーバーの量が考慮に入れられるステップと、
ポイント・ツー・ポイント修理モードに対するコストを計算するステップであって、ポイント・ツー・ポイントチャンネルを経てある量のデータを送信する推定コスト、修理要求の合計数、及び要求されたエンコード記号の合計数が考慮に入れられるステップと、
ポイント・ツー・マルチポイント修理モードに対するコストを計算するステップであって、ポイント・ツー・マルチポイントチャンネルを経てある量のデータを送信する推定コスト、ポイント・ツー・ポイントチャンネルを経てある量のデータを送信する推定コスト、修理要求の合計数、及び修理サーバーから要求されたエンコード記号の数が考慮に入れられるステップと、
を備えた方法。
【請求項４５】
前記データの量は、オクテットである、請求項４４に記載の方法。
【請求項４６】
時間を計算するステップであって、データセット送信終了時間、バックオフオフセット時間、及びバックオフウインドウが考慮されるステップと、
前記計算された時間に、前記修理サーバーにより受け取られた修理要求の数、及び前記修理サーバーから要求されたエンコード記号の数を、前記修理サーバーから要求するステップと、
を更に備えた請求項４４に記載の方法。
【請求項４７】
１つ以上の推定が更新される、請求項４４に記載の方法。
【請求項４８】
修理サーバーへ修理要求を送信する独特な受信器の数を修理サーバーから受け取るステップと、
修理要求を送信する独特な受信器の合計数を推定するステップであって、修理サーバーへ修理要求を送信する独特な受信器の数、０と１との間の選択された値、及び修理サーバーの量が考慮に入れられるステップと、
ポイント・ツー・マルチポイント修理モードの後に回復を経験する受信器の合計数を計算するステップであって、修理サーバーへ修理要求を送信する独特な受信器の数、平均ロスレート、修理要求を送信する独特な受信器の合計数、及び１と０との間の値であって、ポイント・ツー・ポイント接続を使用しない受信器の推定部分に対応する値が考慮に入れられるステップと、
を備えた方法。
【請求項４９】
ポイント・ツー・ポイント修理モードの後に回復を経験する受信器の合計数を、修理要求を送信する独特の受信器の合計数であるとみなすステップを更に備えた、請求項４８に記載の方法。
【請求項５０】
時間を計算するステップであって、データセット送信終了時間、バックオフオフセット時間、及びバックオフウインドウが考慮されるステップと、
前記計算された時間に、修理サーバーへ修理要求を送信する独特な受信器の数を修理サーバーから要求するステップと、
を更に備えた請求項４８に記載の方法。
【請求項５１】
１つ以上の推定が更新される、請求項４８に記載の方法。
【請求項５２】
ポイント・ツー・ポイント修理モードの効率を計算するステップであって、ポイント・ツー・ポイント修理モードの後に回復を経験する受信器の合計数、及びポイント・ツー・ポイント修理モードのコストが考慮に入れられるステップと、
ポイント・ツー・マルチポイント修理モードの効率を計算するステップであって、ポイント・ツー・マルチポイント修理モードの後に回復を経験する受信器の合計数、及びポイント・ツー・マルチポイント修理モードのコストが考慮に入れられるステップと、
ポイント・ツー・マルチポイント修理モードの方がポイント・ツー・ポイント修理モードより効率が高いと決定された場合には、ポイント・ツー・マルチポイント修理モードを使用するステップと、
を備えた方法。
【請求項５３】
ポイント・ツー・マルチポイント修理モードの方がポイント・ツー・ポイント修理モードより効率が高いと決定された場合には、ポイント・ツー・マルチポイント修理モードに受信器を再指向するステップを更に備え、修理は、ある時間の前にはポイント・ツー・ポイントであり、そしてその時間の後にはポイント・ツー・マルチポイントである、請求項５２に記載の方法。
【請求項５４】
ポイント・ツー・ポイント修理モードに対して満足な受信器当たりのコストを計算するステップと、
ポイント・ツー・マルチポイント修理モードに対して満足な顧客当たりのコストを計算するステップと、
を更に備えた請求項５２に記載の方法。
【請求項５５】
決定された最も効果的な修理モードを１つ以上の修理サーバーに通知するステップを更に備えた、請求項５２に記載の方法。
【請求項５６】
プログラムコードが記憶されたメモリと、
前記メモリと通信状態に配置され、前記記憶されたプログラムコードに基づいてインストラクションを実行するためのプロセッサと、
前記プロセッサと通信状態に配置されたネットワークインターフェイスと、
を備え、前記プログラムコードは、前記プロセッサにより実行されたときに、前記プロセッサが、
ポイント・ツー・ポイントチャンネルを経てある量のデータを送信するコストを推定し、
ポイント・ツー・マルチポイントチャンネルを経てある量のデータを送信するコストを推定し、
修理サーバーから、その修理サーバーにより受け取られる修理要求の数を受け取り、
修理サーバーから、その修理サーバーから要求されたエンコード記号の数を受け取り、
修理要求の合計数を推定し、ここでは、前記修理サーバーにより受け取られた修理要求の数、０と１との間の選択された値、及び修理サーバーの量が考慮に入れられ、
要求されたエンコード記号の合計数を推定し、ここでは、前記修理サーバーから要求されたエンコード記号の数、０と１との間の選択された値、及び修理サーバーの量が考慮に入れられ、
ポイント・ツー・ポイント修理モードに対するコストを計算し、ここでは、ポイント・ツー・ポイントチャンネルを経てある量のデータを送信する推定コスト、修理要求の合計数、及び要求されたエンコード記号の合計数が考慮に入れられ、
ポイント・ツー・マルチポイント修理モードに対するコストを計算し、ここでは、ポイント・ツー・マルチポイントチャンネルを経てある量のデータを送信する推定コスト、ポイント・ツー・ポイントチャンネルを経てある量のデータを送信する推定コスト、修理要求の合計数、及び修理サーバーから要求されたエンコード記号の数が考慮に入れられ、
というようにされたサーバー。
【請求項５７】
前記データの量は、オクテットである、請求項５６に記載のサーバー。
【請求項５８】
前記プロセッサは、更に、
時間を計算し、ここでは、データセット送信終了時間、バックオフオフセット時間及びバックオフウインドウが考慮され、
前記計算された時間に、前記修理サーバーにより受け取られた修理要求の数、及び前記修理サーバーから要求されたエンコード記号の数を、前記修理サーバーから要求する、
ことを行なう請求項５６に記載のサーバー。
【請求項５９】
１つ以上の推定が更新される、請求項５６に記載のサーバー。
【請求項６０】
プログラムコードが記憶されたメモリと、
前記メモリと通信状態に配置され、前記記憶されたプログラムコードに基づいてインストラクションを実行するためのプロセッサと、
前記プロセッサと通信状態に配置されたネットワークインターフェイスと、
を備え、前記プログラムコードは、前記プロセッサにより実行されたときに、前記プロセッサが、
修理サーバーへ修理要求を送信する独特な受信器の数を修理サーバーから受け取り、
修理要求を送信する独特な受信器の合計数を推定し、ここでは、修理サーバーへ修理要求を送信する独特な受信器の数、０と１との間の選択された値、及び修理サーバーの量が考慮され、
ポイント・ツー・マルチポイント修理モードの後に回復を経験する受信器の合計数を計算し、ここでは、修理サーバーへ修理要求を送信する独特な受信器の数、平均ロスレート、修理要求を送信する独特な受信器の合計数、及び１と０との間の値であって、ポイント・ツー・ポイント接続を使用しない受信器の推定部分に対応する値が考慮される、
というようにしたサーバー。
【請求項６１】
前記プロセッサは、更に、ポイント・ツー・ポイント修理モードの後に回復を経験する受信器の合計数を、修理要求を送信する独特の受信器の合計数であるとみなす、請求項６０に記載のサーバー。
【請求項６２】
前記プロセッサは、更に、
時間を計算し、ここでは、データセット送信終了時間、バックオフオフセット時間及びバックオフウインドウが考慮され、
前記計算された時間に、修理サーバーへ修理要求を送信する独特な受信器の数を修理サーバーから要求する、
ことを行なう請求項６０に記載のサーバー。
【請求項６３】
１つ以上の推定が更新される、請求項６０に記載のサーバー。
【請求項６４】
プログラムコードが記憶されたメモリと、
前記メモリと通信状態に配置され、前記記憶されたプログラムコードに基づいてインストラクションを実行するためのプロセッサと、
前記プロセッサと通信状態に配置されたネットワークインターフェイスと、
を備え、前記プログラムコードは、前記プロセッサにより実行されたときに、前記プロセッサが、
ポイント・ツー・ポイント修理モードの効率を計算し、ここでは、ポイント・ツー・ポイント修理モードの後に回復を経験する受信器の合計数、及びポイント・ツー・ポイント修理モードのコストが考慮に入れられ、
ポイント・ツー・マルチポイント修理モードの効率を計算し、ここでは、ポイント・ツー・マルチポイント修理モードの後に回復を経験する受信器の合計数、及びポイント・ツー・マルチポイント修理モードのコストが考慮に入れられ、
ポイント・ツー・マルチポイント修理モードの方がポイント・ツー・ポイント修理モードより効率が高いと決定された場合には、ポイント・ツー・マルチポイント修理モードを使用する、
というようにされたサーバー。
【請求項６５】
前記プロセッサは、更に、ポイント・ツー・マルチポイント修理モードの方がポイント・ツー・ポイント修理モードより効率が高いと決定された場合には、ポイント・ツー・マルチポイント修理モードに受信器を再指向し、修理は、ある時間の前にはポイント・ツー・ポイントであり、そしてその時間の後にはポイント・ツー・マルチポイントである、請求項６４に記載のサーバー。
【請求項６６】
前記プロセッサは、更に、
ポイント・ツー・ポイント修理モードに対して満足な受信器当たりのコストを計算し、
ポイント・ツー・マルチポイント修理モードに対して満足な顧客当たりのコストを計算する、
ことを行なう請求項６４に記載のサーバー。
【請求項６７】
前記プロセッサは、更に、決定された最も効果的な修理モードを１つ以上の修理サーバーに通知する、請求項６４に記載のサーバー。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データデリバリーのためのシステム及び方法に係る。
【背景技術】
【０００２】
最近では、データデリバリーの利用が増えて来ている。例えば、多くのユーザは、データデリバリー（例えば、デジタルビデオブロードキャスティング：ハンドヘルド（ＤＶＢ−Ｈ）インターネットプロトコルデータキャスティング（ＩＰＤＣ）データデリバリー）を、情報、娯楽、データ等の他のソースより好むようになってきている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従って、例えば、データデリバリーに適用できる技術に関心が集まっている。
【課題を解決するための手段】
【０００４】
本発明の実施形態によれば、例えば、データデリバリーに適用できるシステム及び方法が提供される。
【０００５】
例えば、種々の実施形態において、サービスオペレータサーバー及び／又は他のコンピュータは、１つ以上の受信器が、ディスパッチされたデータを正しく受信しない場合に、ポイント・ツー・ポイント修理モード及びポイント・ツー・マルチポイント修理モードのいずれを使用すべきか決定するように働く。
【０００６】
サービスオペレータサーバー及び／又は他のコンピュータは、種々の実施形態において、１つ以上の推定値を計算し、１つ以上の修理サーバーから１つ以上の値を要求し、及び／又は使用すべき修理モードに関する１つ以上の指令を１つ以上の修理サーバーに与えることができる。
【発明を実施するための最良の形態】
【０００７】
一般的オペレーション
本発明の実施形態によれば、例えば、データデリバリーに適用できるシステム及び方法が提供される。
【０００８】
例えば、種々の実施形態において、サービスオペレータサーバー及び／又は他のコンピュータは、１つ以上の受信器が、デジタルビデオブロードキャスティング：ハンドヘルド（ＤＶＢ−Ｈ）インターネットプロトコルデータキャスティング（ＩＰＤＣ）デジタルマルチメディアブロードキャスト−地上（ＤＭＢ−Ｔ）、ＭｅｄｉａＦＬＯ（順方向リンクのみ）、等を経てディスパッチされたデータを正しく受信しない場合に、ポイント・ツー・ポイント修理モード及びポイント・ツー・マルチポイント修理モードのいずれを使用すべきか決定するように働く。
【０００９】
サービスオペレータサーバー及び／又は他のコンピュータは、種々の実施形態において、１つ以上の推定値（例えば、データのある部分を受信しなかった受信器の数、ロスパーセンテージ、及び／又は修理モードの有効性）を計算し、１つ以上の修理サーバーから１つ以上の値（例えば、受け取られた修理要求の数）を要求し、及び／又は使用すべき修理モードに関する１つ以上の指令を１つ以上の修理サーバーに与えることができる。
【００１０】
本発明の種々の態様を以下に詳細に説明する。
【００１１】
サービスオペレータのオペレーション
図１を参照すると、本発明の種々の実施形態によれば、サービスオペレータサーバー及び／又は他のコンピュータは、デジタルビデオブロードキャスティング：ハンドヘルド（ＤＶＢ−Ｈ）インターネットプロトコルデータキャスティング（ＩＰＤＣ）デジタルマルチメディアブロードキャスト−地上（ＤＭＢ−Ｔ）、ＭｅｄｉａＦＬＯ（順方向リンクのみ）、等に使用された１つ以上の修理サーバーに、１つ以上の受信器（例えば、移動ノード）がデータを正しく受信しない場合に、ポイント・ツー・ポイント修理モード（例えば、ユニバーサルモバイルテレコミュニケーションズサービス（ＵＭＴＳ）及び／又は汎用パケット無線サービス（ＧＰＲＳ）を使用する）を使用すべきであるという初期指示を与える（ステップ１０１）。このような初期指示は、例えば、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）、Ｊａｖａ（登録商標）メッセージングサービス（ＪＭＡ）、及び／又はリモートメソッドインボケーション（ＲＭＩ）を使用する仕方でディスパッチすることができる。
【００１２】
種々の実施形態において、このような初期指示は、これを与えなくてもよいことに注意されたい。これは、例えば、ポイント・ツー・ポイント修理モードの使用が、デフォールト修理サーバー振舞いとしてセットされた（例えば、製造者、システム管理者及び／又はサービスオペレータにより）場合である。
【００１３】
サービスオペレータサーバー及び／又は他のコンピュータは、種々の実施形態において、所与のデータセット（例えば、ファイル及び／又はパケットのセット）に対応する１つ以上の値を決定する（ステップ１０３）。このような値は、例えば、データセット送信終了時間ｔe、バックオフオフセット時間ｔo、及び／又はバックオフウインドウＴを含む。次いで、サービスオペレータサーバー及び／又は他のコンピュータは、例えば、次の時間を計算する。
ｔe＋ｔo＋α・Ｔ
但し、
2008546237.tif 000003
であり、ｔは、バックオフウインドウのスタート以来の時間である（ステップ１０５）。
【００１４】
種々の実施形態において、サービスオペレータサーバー及び／又は他のコンピュータは、計算された時間に１つ以上の修理サーバーに要求を送信する（ステップ１０７）。この要求は、例えば、データセットに対してそれまでに受け取った修理要求の数の指示を修理サーバーがサービスオペレータサーバー及び／又は他のコンピュータに与えねばならないことを指示する。このような要求及び／又はそれに対する応答は、例えば、ＳＯＡＰ、ＪＭＳ及び／又はＲＭＩを使用する仕方でディスパッチすることができる。
【００１５】
要求を受け取る修理サーバーは、例えば、要求された値を与える。種々の実施形態において、このような修理サーバーは、それとは別に又はそれに加えて、所与のデータセットの所与のソースブロック又はエンコード記号（例えば、完全な要求ウインドウ）に対して受け取る修理要求の全数の推定値Ｎを計算する。
2008546237.tif 000004
但し、ｎは、１つの修理サーバーによりデータセットに対してそれまでに受け取った修理要求の数であり、そしてｒは、修理サーバーの数である。又、種々の実施形態において、Ｎは、それとは別に又はそれに加えて、サービスオペレータサーバー及び／又は他のコンピュータにより計算されてもよいことに注意されたい。更に、種々の実施形態において、このようなＮの計算は、修理ウインドウの最初の数個の時間単位（例えば、秒）の間は、使用されなくてもよいことに注意されたい。例えば、このようなＮの計算は、修理ウインドウの最初の１０秒間は、使用されなくてもよい。これは、おそらく、精度を高めることになる。
【００１６】
サービスオペレータサーバー及び／又は他のコンピュータは、例えば、値βを推定してもよく、このβは、返送チャンネルを有していて修理要求を送信でき及び／又は送信しようとする受信器の一部分である。図２を参照すれば、サービスオペレータサーバー及び／又は他のコンピュータは、例えば、データセットのある部分を受信しなかった受信器の予想数の推定値Ｎtを計算する際にβを使用することに注意されたい（ステップ２０１）。
2008546237.tif 000005
種々の実施形態において、βは、次のように計算されることに注意されたい。
2008546237.tif 000006
但し、Ｍは、修理を要求できる受信器の全予想数である。
【００１７】
更に、サービスオペレータサーバー及び／又は他のコンピュータは、例えば、使用するポイント・ツー・ポイントチャンネル（例えば、ＧＰＲＳ又はＵＭＴＳ）を経てある量のデータ（例えば、オクテット）を搬送するコストの推定値ｃuを計算し、及び／又は使用するポイント・ツー・マルチポイントチャンネル（例えば、ＤＶＢ−Ｈ）を経てある量のデータ（例えば、オクテット）を搬送するコストの推定値ｃmを計算する（ステップ２０３）。
【００１８】
更に別の例として、サービスオペレータサーバー及び／又は他のコンピュータは、ある量のデータ（例えば、オクテット）に関するポイント・ツー・ポイント（例えば、ＧＰＲＳ又はＵＭＴＳ）オーバーヘッドの推定値ｓuを計算し、これは、修理要求に対するポイント・ツー・ポイントオーバーヘッドの推定値として、及び再指向応答に対するポイント・ツー・ポイントオーバーヘッドの推定値としても適用できる（ステップ２０５）。
【００１９】
更に別の例として、サービスオペレータサーバー及び／又は他のコンピュータは、ポイント・ツー・マルチポイント（例えば、ＤＶＢ−Ｈ）修理セッションに対するセッションアナウンスメントのためにある量のデータ（例えば、オクテット）に関するポイント・ツー・マルチポイント（例えば、ＤＶＢ−Ｈ）オーバーヘッドの推定値ｓmを計算する（ステップ２０５）。
【００２０】
サービスオペレータサーバー及び／又は他のコンピュータは、例えば、ポイント・ツー・マルチポイント修理セッション（例えば、ＤＶＢ−Ｈ修理セッション）ロス比の推定値ｐを計算する。種々の実施形態において、ｐは、次のように計算される。
2008546237.tif 000007
【００２１】
更に別の例として、サービスオペレータサーバー及び／又は他のコンピュータは、ポイント・ツー・ポイント修理モード及びポイント・ツー・マルチポイント修理モードの各々に対して効率の推定値（例えば、コスト単位当たりの首尾良い受信状態の受信器の数）を計算する。このような効率は、例えば、次のように計算される。
2008546237.tif 000008
但し、Ｃは、修理モードに対する合計コストであり、そしてＮsは、修理モードに対する首尾良い受信の数（例えば、首尾良いデータセット受信状態の受信器の数）である。このような有効性は、種々の実施形態において、バックオフウインドウ内のある時点に対して計算される。
【００２２】
種々の実施形態において、ポイント・ツー・ポイント修理モードに対する首尾良い受信の数、及び／又はポイント・ツー・マルチポイント修理モードに対する首尾良い受信の数を推定できることに注意されたい。更に、種々の実施形態において、ポイント・ツー・ポイント修理モードのコスト、及び／又はポイント・ツー・マルチポイント修理モードのコストも推定できることに注意されたい。修理モードに対するこのようなコスト推定値は、おそらく、修理モードを選択するためのコスト推定値と考えられる。
【００２３】
サービスオペレータサーバー及び／又は他のコンピュータは、例えば、
2008546237.tif 000009
を計算する。ここで、Ｎptpは、ポイント・ツー・ポイント修理モードに対する首尾良い受信の数であり、Ｎptmは、ポイント・ツー・マルチポイント修理モードに対する首尾良い受信の数であり、Ｃptpは、ポイント・ツー・ポイント修理モードに対する推定合計コストであり、そしてＣptmは、ポイント・ツー・マルチポイント修理モードに対する推定合計コストである。サービスオペレータサーバー及び／又は他のコンピュータは、種々の実施形態において、使用すべき修理モードを判断する際にこのような計算を考慮する（ステップ２０７）。
【００２４】
サービスオペレータサーバー及び／又は他のコンピュータが、前記式が真であると計算した場合には（即ち、前記式の左半分が右半分以下であると分かった場合には）、サービスオペレータサーバー及び／又は他のコンピュータは、種々の実施形態において、ポイント・ツー・ポイント修理モード（例えば、ＧＰＲＳ又はＵＭＴＳ修理モード）を使用すべきであると判断する。
【００２５】
サービスオペレータサーバー及び／又は他のコンピュータが、前記式が偽であると計算した場合には（即ち、前記式の左半分が右半分より大きい場合には）、サービスオペレータサーバー及び／又は他のコンピュータは、種々の実施形態において、ポイント・ツー・マルチポイント修理モード（例えば、ＤＶＢ−Ｈ修理モード）を使用すべきであると判断する。
【００２６】
種々の実施形態において、前記式は、複数の修理サーバーの各々に対して計算されてもよいことに注意されたい。前記式が１つ以上の修理サーバーに対して真であると計算された場合には、例えば、ポイント・ツー・ポイント修理モードが全ての修理サーバーに対して使用されてもよい。更に、種々の実施形態において、複数の修理サーバーがある場合には、使用すべき修理モードに関して判断を行うときには、生のデータを収集して使用してもよいことに注意されたい。ここで、Ｎは、おそらく個々のＮ／αの和であると考えられる。更に、種々の実施形態において、複数の修理サーバーがある場合には、使用すべき修理モードに関して判断を行うために個々のＮ／αの種々の組み合せを使用してもよいことに注意されたい。
【００２７】
使用すべき修理モードに関して行なわれる生のデータの収集及び／又は判断は、種々の実施形態において、複数のサーバー及び／又は他のコンピュータ間で分散させ、前記式の計算は、おそらく、Ｎtを（Ｎt−ｎ）に置き換えて行なわれる。このような実施形態において、Ｎtは、ウインドウ内で予想される将来の要求の数であると考えられ、Ｎt・（１−ｐ）は、ポイント・ツー・マルチポイント再送信の後に予想される首尾良い修理の数であると考えられ、及び／又はＮt・ｐは、満足されない受信の数であると考えられる。
【００２８】
種々の実施形態において、ｐは、データに依存するとみなされる（例えば、１０ＭＢの再送信は、１ｋＢの再送信よりも、受信器を未分析のままにする見込みが高いと考えられる）。Ｎ・ｃu・ｓuは、種々の実施形態において、オリジナルのポイント・ツー・マルチポイントが修理ウインドウ中に全クライアントにより常にドロップされるときには、全ての要求の修理のコストであると考えられることに注意されたい。これは、おそらく、全てのクライアントが要求を発し、且つポイント・ツー・マルチポイント修理のアナウンスメントがある割合をサイレンスにしないと仮定する。このような割合は、おそらく、Ｎtより小さい（例えば、判断とアナウンスメントの送信との間にタイムラグがあり、しかも、受信器のある割合がアナウンスメントを受信しないために）。
【００２９】
更に、前記式の分母は、種々の実施形態において、それを、例えば、「ポイント・ツー・ポイントコスト」、「ポイント・ツー・マルチポイントアナウンスメント待ち時間コスト」及び「ポイント・ツー・マルチポイントコスト」のような項に分離するように書かれることに注意されたい。従って、例えば、「ポイント・ツー・ポイントコスト」は、ｎ・ｃu・（ｓ＋ｓu）となる。別の例として、「ポイント・ツー・マルチポイントアナウンスメント待ち時間コスト」は、Ｌ・ｃu・（ｓ＋ｓu）（ポイント・ツー・ポイントが、判断がなされた後にポイント・ツー・ポイント応答によってサービスされる場合）であるか、又はＬ・ｃu・ｓu（ポイント・ツー・マルチポイントへの再指向が、判断がなされた後に行われる場合）である。
【００３０】
Ｌは、例えば、判断とウインドウの終了ｔe＋ｔo＋Ｔとの間のクライアント要求の予想数であると考えられる。種々の実施形態において、判断がなされたときに受信者が修理要求の送信を停止した場合には、Ｌがゼロになると考えられる。更に、種々の実施形態において、判断に関するアナウンスメントが送信も受信もされない場合には、ＬがＮtであると考えられる。或いは又、判断に関するアナウンスメントが送信も受信もされない場合には、Ｎtは、次のようになると考えられる。
Ｎt・（χ）＋Ｎt・ｑ
但し、χは、判断とアナウンスメント受信との間の時間で、ページング待ち時間を含む時間であり、そしてｑは、受信器がアナウンスメントを受信しない確率である。種々の実施形態において、アナウンスメントが２回以上送信される場合には、それがより詳細に表わされる（例えば、各アナウンスメントに対する確率、アナウンスメントの数、及び／又はアナウンスメント間の時間に関して）。
【００３１】
種々の実施形態では、このような判断においてサービスオペレータサーバー及び／又は他のコンピュータにより前記以外のものが計算されてもよいことに注意されたい。例えば、サービスオペレータサーバー及び／又は他のコンピュータは、ポイント・ツー・ポイント修理モード及び／又はポイント・ツー・マルチポイント修理モードの有効性（例えば、首尾良いデータ受信当たりのコスト）を推定するのに、異なる式を使用してもよい。例えば、サービスオペレータサーバー及び／又は他のコンピュータは、種々の実施形態において、次の計算を行なう。
2008546237.tif 000010
但し、ｓは、受信器により正しく受信されなかったデータに関して送信されるべきデータの量（例えば、オクテットに関する）である。種々の実施形態において、サービスオペレータサーバー及び／又は他のコンピュータは、前記式が真であると計算した場合には、ポイント・ツー・ポイント修理モードを使用すべきであると判断し、そして前記式が偽であると計算したした場合には、ポイント・ツー・マルチポイント修理モードを使用すべきであると判断する。
【００３２】
サービスオペレータサーバー及び／又は他のコンピュータは、例えば、１つ以上の修理サーバーにその判断を通知する。このようなファンクションは、多数の仕方で実施することができる。例えば、ＳＯＡＰ、ＪＭＳ、及び／又はＲＭＩが使用されてもよい。種々の実施形態において、ポイント・ツー・マルチポイント修理モードを使用すべきであることが決定された場合にはこのような通知のみが行われてもよい。これは、例えば、ポイント・ツー・ポイント修理モードの使用が、デフォールト修理サーバー振舞いとしてセットされる場合である。
【００３３】
種々の実施形態において、ポイント・ツー・マルチポイント修理モードを使用すべきであると判断された場合には、サービスオペレータサーバー及び／又は他のコンピュータは、例えば、各データをトランスポートするようにポイント・ツー・マルチポイントセッションをスケジュールしてもよい。
【００３４】
種々の実施形態において、１つ以上のサーバー（例えば、ファイルデリバリーサーバー）は、例えば、対応する初期データセットデリバリーセッション（例えば、ＤＶＢ−Ｈ  ＩＰＤＣデータセットデリバリーセッション）の更新インバンド及び／又はアウトオブバンドを送信することにより、それらに関連したデリバリー手順記述を更新できることに注意されたい。１つ以上のサーバーは、例えば、同じチャンネル、異なるチャンネル、及び／又は異なるデータセットデリバリーセッションを使用して、ポイント・ツー・マルチポイント修理セッションを配送することができる。更に、有効性は、種々の実施形態において、首尾良い受信及び／又は満足な受信器の個数当たりの合計コストと考えられることに注意されたい。
【００３５】
更に、種々の実施形態において、ここに述べる種々のオペレーションを介して、利用可能なデータ送信チャンネルのより有効な使用、及び／又はより最適な修理モード選択（例えば、ネットワークコスト及び満足なクライアントの数を考慮した）を達成できることに注意されたい。更に又、種々の実施形態において、戻りチャンネル能力が欠乏し、及び／又はユーザが修理要求を送信しようとしない受信器は、他のものの修理要求及び／又はポイント・ツー・マルチポイント応答から利益が得られることにも注意されたい。
【００３６】
種々の実施形態において、ファイルデリバリーセッションの始めに、サーバー及び／又は他のコンピュータは、ポイント・ツー・ポイント修理セッション及び／又はチャンネルの存在を受信器に指示できることに注意されたい。受信器は、例えば、データセットデリバリー（例えば、ファイルデリバリー）が終了した後に修理セッションに加わることができる。受信器は、例えば、ポイント・ツー・ポイント修理要求をランダムなタイムインスタンスでディスパッチすることができる。ポイント・ツー・マルチポイント修理モードを使用するための判断がなされた場合には、その判断を、修理要求に対する再指向応答として受信器へシグナリングしてもよく、及び／又はポイント・ツー・マルチポイント修理セッションに対して更新された時間切れタイマーと共にファイルデリバリーテーブル（ＦＤＴ）を送信することによりシグナリングしてもよい。
【００３７】
サービスオペレータサーバー及び／又は他のコンピュータは、種々の実施形態において、効率的なメトリックに基づいて修理モードの選択を行うことができる。修理モードの効率は、例えば、次のように計算することができる。
2008546237.tif 000011
【００３８】
サービスオペレータサーバー及び／又は他のコンピュータは、例えば、ポイント・ツー・ポイント及びポイント・ツー・マルチポイント修理モードに対する両パラメータを各々推定することができる。サービスオペレータサーバー及び／又は他のコンピュータは、例えば、ポイント・ツー・マルチポイント修理モードの方が効率が良いと分かった場合には、特定のファイルに対してポイント・ツー・マルチポイント修理セッションをスケジュールするように判断することができる。
【００３９】
サービスオペレータサーバー及び／又は他のコンピュータは、例えば、ポイント・ツー・ポイント（例えば、ＧＰＲＳ又はＵＭＴＳ）ネットワークを経て単一量のデータ（例えば、オクテット）を送信するためのコストｃuを推定する。別の例として、ポイント・ツー・マルチポイント（例えば、ＤＶＢ−Ｈ）ネットワークを経て単一量のデータ（例えば、オクテット）を送信するためのコストｃmが計算される。更に別の例として、サービスオペレータサーバー及び／又は他のコンピュータは、修理要求の予想数、ポイント・ツー・ポイントネットワークを経て交換されるデータの量、及び／又はポイント・ツー・マルチポイントネットワークを経て交換されるデータの量を推定する。
【００４０】
種々の実施形態において、修理セッションがスタートした後に（例えば、データセット送信が終了した後に）、受信器は、バックオフオフセットタイム中待機し、次いで、ランダムな時間周期内にそれらの修理要求をランダムに送信する必要がある。サービスオペレータサーバー及び／又は他のコンピュータは、例えば、αの値を０と１との間で選択する。サービスオペレータサーバー及び／又は他のコンピュータは、例えば、時定数を計算する。
ｔe＋ｔo＋α・Ｔrandom_time_period
【００４１】
サービスオペレータサーバー及び／又は他のコンピュータは、種々の実施形態において、計算された時間に、１つ以上の修理サーバーにコンタクトし、例えば、受け取った修理要求の数ｎreq、要求されたエンコード記号の数ｎstm、及び／又は修理要求を送信する独特の受信器の数ｎrecvに関する情報を得る。サービスオペレータサーバー及び／又は他のコンピュータは、種々の実施形態において、時間経過と共に及び／又は修理サーバーにわたり均一にランダムに分布されるべき修理要求を考え、そして例えば、要求の全予想数Ｎreq、要求される記号の全予想数Ｎsym、及び／又は修理要求を送信する独特の受信器の全予想数ｎrecvに対する推定値を計算することができる。
2008546237.tif 000012
2008546237.tif 000013
2008546237.tif 000014
但し、ｒは、現在ファイルデリバリーセッションに対する修理サーバーの数である。種々の実施形態において、ポイント・ツー・ポイント修理モードに対する合計コストは、Ｃptpとして推定される。
Ｃptp＝ｃu・Ｎsym・ｓsym＋ｃu・Ｎreq・ｓreq
但し、ｓsym及びｓreqは、各々修理要求のエンコード記号及びオーバーヘッドである。
【００４２】
種々の実施形態において、ポイント・ツー・マルチポイント修理モードの場合、サービスオペレータサーバー及び／又は他のコンピュータは、例えば、判断がなされた後（例えば、時間ｔの後）受信器をポイント・ツー・マルチポイント修理セッションに再指向させることに注意されたい。このような場合、例えば、修理モードは、時間ｔの前にポイント・ツー・ポイントであり、そして時間ｔの後にポイント・ツー・マルチポイントとなる。種々の実施形態において、受信器は、修理時間の終了までポイント・ツー・ポイント修理要求を依然として送信すると仮定する。更に、種々の実施形態では、ポイント・ツー・マルチポイント修理セッションは、完全な受信を達成するために全データセット（例えば、全ファイル）を含むと仮定する。従って、例えば、ポイント・ツー・マルチポイント修理に対するコストは、Ｃptmとして計算される。
Ｃptm＝ｃm・（Ｓ＋ｓan）＋ｃu・Ｎreq・ｓreq＋ｃu・ｎsym・ｓsym
但し、Ｓは、データセットのサイズであり、そしてｓanは、アナウンスメントセッションのサイズである。
【００４３】
種々の実施形態によれば、サービスオペレータサーバー及び／又は他のコンピュータは、修理セッションの後に所与のデータセット（例えば、ファイル）を完全に回復することのできた受信器の数を推定する。ポイント・ツー・ポイント修理の場合には、サービスオペレータサーバー及び／又は他のコンピュータは、種々の実施形態において、修理要求を送信した全ての受信器がデータセットを回復できると仮定する。従って、種々の実施形態では、ポイント・ツー・ポイント修理モードに対して、Ｎrecv個の受信器がファイルを回復できると考えられる。
Number_of_receivers_with_successful_receptionptp＝Ｎrecv
【００４４】
しかしながら、種々の実施形態において、ポイント・ツー・ポイント接続をもたず及び／又はそれを使用しようとしない受信器があり得る。サービスオペレータサーバー及び／又は他のコンピュータは、例えば、これら受信器の一部分を（１−β）で推定し、但し、βは、０と１との間である。ポイント・ツー・マルチポイント修理モードを使用するときには、これらの受信器は、種々の実施形態において、データセットを回復する機会をもつことができる。しかしながら、種々の実施形態において、ポイント・ツー・マルチポイント修理セッションの後にデータセットを回復できない受信器の一部分が依然として存在し得る。この一部分は、種々の実施形態では、平均ロスレートｐに依存する。従って、サービスオペレータサーバー及び／又は他のコンピュータは、例えば、ポイント・ツー・マルチポイント修理の後にファイルを回復する受信器の全数の推定値を次のように計算する。
2008546237.tif 000015
【００４５】
サービスオペレータサーバー及び／又は他のコンピュータは、種々の実施形態において、首尾良い受信状態の受信器のコスト及び／又は個数を使用して、満足な受信器当たりのコストを計算する。サービスオペレータサーバー及び／又は他のコンピュータは、例えば、満足な受信器当たり最低のコストの修理モード（例えば、効率のよい修理モードを表わす）を使用するように判断する。
【００４６】
更に、種々の実施形態において、ここに述べる種々の推定値及び／又は値は、周期的に及び／又は１つ以上のスケジュールに基づいて更新されることに注意されたい（例えば、スケジュールは、製造者、システム管理者及び／又はサービスオペレータにより確立される）。更に、種々の実施形態において、ここに述べる種々のオペレーション、等は、複数のサービスオペレータサーバー及び／又は他のコンピュータにより遂行されてもよいことに注意されたい。
【００４７】
ユーザオペレーション
図３を参照するに、種々の実施形態によれば、受信器がデータセットデリバリーセッション（例えば、ＤＶＢ−Ｈ  ＩＰＤＣデータセットデリバリーセッション）中にデータを正しく受信しない場合には（ステップ３０１）、受信器は、例えば、１つ以上の修理要求を１つ以上のサーバーへ送信する（ステップ３０３）。このような修理要求は、おそらく、正しく受信されなかったデータを指示する。
【００４８】
１つ以上の修理要求を受け取る修理サーバーは、例えば、ポイント・ツー・ポイント修理モード（例えば、ＧＰＲＳ又はＵＭＴＳ修理モード）を使用する仕方で応答する。従って、修理サーバーは、例えば、ある欠落データをポイント・ツー・ポイント式に受信器へディスパッチすることにより応答する。
【００４９】
別の例として、１つ以上の修理要求を受け取るサーバーは、ポイント・ツー・マルチポイント修理モード（例えば、ＤＶＢ−Ｈ修理モード）を使用する仕方で応答する。従って、修理サーバーは、例えば、受信器をポイント・ツー・マルチポイント修理セッションに再指向して、セッションアナウンスメントを経てポイント・ツー・マルチポイント修理セッションをシグナリングし、及び／又はインバンドでポイント・ツー・マルチポイント修理セッションをシグナリングすることにより、応答する。
【００５０】
ポイント・ツー・ポイント修理モードを使用する仕方又はポイント・ツー・マルチポイント修理モードを使用する仕方でのサーバーの応答は、種々の実施形態において、ここに述べる種類のサービスオペレータサーバー及び／又は他のコンピュータの判断に従って行われる（ステップ３０５）。
【００５１】
種々の実施形態において、受信器に指示されるのは（例えば、ファイルデリバリーサーバーを経て）、修理サーバー及び／又はバックオフアルゴリズムパラメータのリストであることに注意されたい。更に、種々の実施形態において、受信器は、修理サーバー、及びバックオフタイムウインドウ内の時間をランダムに選択する。このようなオペレーションを経て、修理要求が、おそらく、修理サーバー及び／又は時間にわたって均一に分布される。
【００５２】
ハードウェア及びソフトウェア
ここに述べる種々のオペレーション等は、種々の実施形態において、コンピュータの助けにより及び／又はコンピュータの助けで実行することができる。更に、例えば、ここに述べる装置は、コンピュータであってもよく、及び／又はコンピュータを組み込んでもよい。ここで使用する「コンピュータ」、「汎用コンピュータ」、等の語は、スマートカード、メディアデバイス、パーソナルコンピュータ、エンジニアリングワークステーション、ＰＣ、マッキントッシュ、ＰＤＡ、ポータブルコンピュータ、コンピュータ化ウオッチ、ワイヤード又はワイヤレスターミナル、電話、通信装置、ノード等、サーバー、ネットワークアクセスポイント、ネットワークマルチキャストポイント、ネットワーク装置、セットトップボックス、パーソナルビデオレコーダ（ＰＶＲ）、ゲームコンソール、ポータブルゲーム装置、ポータブルオーディオ装置、ポータブルメディア装置、ポータブルビデオ装置、テレビジョン、デジタルカメラ、デジタルカムコーダー、グローバルポジショニングシステム（ＧＰＳ）受信器、ワイヤレスパーソナルサーバー等、又はその組み合せであって、おそらく、ＯＳ  Ｘ、Ｌｉｎｕｘ、Ｄａｒｗｉｎ、Ｗｉｎｄｏｗｓ（登録商標）  ＣＥ、Ｗｉｎｄｏｗｓ（登録商標）  ＸＰ、Ｗｉｎｄｏｗｓ（登録商標）  Ｓｅｒｖｅｒ２００３、Ｐａｌｍ  ＯＳ、Ｓｙｍｂｉａｎ  ＯＳ等のオペレーティングシステムを実行し、おそらく、シリーズ４０プラットホーム、シリーズ６０プラットホーム、シリーズ８０プラットホーム、及び／又はシリーズ９０プラットホームを使用し、そしておそらく、Ｊａｖａ（登録商標）及び／又は.Ｎｅｔに対するサポートを有するものを指すが、これらに限定されない。
【００５３】
又、「汎用コンピュータ」、「コンピュータ」、等の語は、１つ以上のメモリ又は記憶ユニットに作動的に接続された１つ以上のプロセッサを指すが、これらに限定されず、ここで、メモリ又は記憶装置は、データ、アルゴリズム及び／又はプログラムコードを含み、そしてプロセッサ（１つ又は複数）は、プログラムコードを実行し、及び／又はプログラムコード、データ、及び／又はアルゴリズムを操作することができる。本発明の種々の実施形態に使用できる例示的コンピュータが図４に示されている。この例示的コンピュータ４０００は、システムバス４０５０を備え、これは、２つのプロセッサ４０５１及び４０５２、ランダムアクセスメモリ４０５３、リードオンリメモリ４０５５、入力出力（Ｉ／Ｏ）インターフェイス４０５７及び４０５８、記憶装置インターフェイス４０５９、及びディスプレイインターフェイス４０６１を作動的に接続する。記憶装置インターフェイス４０５９は、次いで、大量記憶装置４０６３に接続される。Ｉ／Ｏインターフェイス４０５７及び４０５８の各々は、例えば、イーサネット（登録商標）、ＩＥＥＥ１３９４、ＩＥＥＥ１３９４ｂ、ＩＥＥＥ８０２．１１ａ、ＩＥＥＥ８０２．１１ｂ、ＩＥＥＥ８０２．１１ｇ、ＩＥＥＥ８０２．１１ｉ、ＩＥＥＥ８０２．１１ｅ、ＩＥＥＥ８０２．１１ｎ、ＩＥＥＥ８０２．１５ａ、ＩＥＥＥ８０２．１６ａ、ＩＥＥＥ８０２．１６ｄ、ＩＥＥＥ８０２．１６ｅ、ＩＥＥＥ８０２．１６ｘ、ＩＥＥＥ８０２．２０、ＩＥＥＥ８０２．１５．３、ＺｉｇＢｅｅ、Ｂｌｕｅｔｏｏｔｈ、ウルトラワイドバンド（ＵＷＢ）、ワイヤレスユニバーサルシリアルバス（ＷＵＳＢ）、ワイヤレスファイアワイア、地上デジタルビデオ放送（ＤＶＢ−Ｔ）、衛星デジタルビデオ放送（ＤＶＢ−Ｓ）、アドバンストテレビジョンシステムズコミッティ（ＡＴＳＣ）、サービス総合デジタル放送（ＩＳＤＢ）、デジタルマルチメディア放送−地上（ＤＭＢ−Ｔ）、地上デジタルマルチメディア放送（Ｔ−ＤＭＢ）、ＭｅｄｉａＦＬＯ（順方向リンクのみ）、デジタルオーディオ放送（ＤＡＢ）、デジタル無線モンデール（ＤＲＭ）、汎用パケット無線サービス（ＧＰＲＳ）、ユニバーサルモバイルテレコミュニケーションズサービス（ＵＭＴＳ）、移動通信用のグローバルシステム（ＧＳＭ）、ＤＶＢ−Ｈ（デジタルビデオ放送：ハンドヘルド）、ＩｒＤＡ（赤外線データアソシエーション）、及び／又は他のインターフェイスでよい。
【００５４】
大量記憶装置４０６３は、ハードドライブ、光学的ドライブ、メモリチップ等でよい。プロセッサ４０５１及び４０５２は、各々、通常知られたプロセッサ、例えば、ＩＢＭ又はＦｒｅｅｓｃａｌｅ  ＰｏｗｅｒＰＣ、ＡＭＤ  Ａｔｈｌｏｎ、ＡＭＤ  Ｏｐｔｅｒｏｎ、インテルＡＲＭ、インテルＸＳｃａｌｅ、Ｔｒａｎｓｍｅｔａ  Ｃｒｕｓｏｅ、Ｔｒａｎｓｍｅｔａ  Ｅｆｆｉｃｅｏｎ、インテルＸｅｎｏｎ、インテルＩｔａｎｉｕｍ、インテルＰｅｎｔｉｕｍ（登録商標）、又はＩＢＭ、東芝、又はソニーセルプロセッサでよい。又、この例に示されたコンピュータ４０００は、タッチスクリーン４００１及びキーボード４００２も備えている。種々の実施形態において、それとは別に又はそれに加えて、マウス、キーパッド、及び／又はインターフェイスが使用されてもよい。コンピュータ４０００は、更に、カードリーダー、ＤＶＤドライブ、フロッピー（登録商標）ディスクドライブ、ハードドライブ、メモリカード、ＲＯＭ等を含むか又はそれらにアタッチされてもよく、従って、プログラムコード（例えば、ここに述べる種々のオペレーション等を遂行するための）を含むメディアを、コンピュータにコードをロードする目的で挿入することができる。
【００５５】
本発明の種々の実施形態によれば、コンピュータは、上述したオペレーションの１つ以上を遂行するように設計された１つ以上のソフトウェアモジュールを実行することができる。このようなモジュールは、例えば、この技術で知られた方法に基づきＪａｖａ（登録商標）、ＯｂｊｅｃｔｉｖｅＣ、Ｃ、Ｃ＃、Ｃ＋＋、Ｐｅｒｌ、Ｐｙｔｈｏｎ、及び／又はＣｏｍｅｇａのような言語を使用してプログラムされる。それに対応するプログラムコードを、例えば、ＤＶＤ、ＣＤ−ＲＯＭ、メモリカード、及び／又はフロッピー（登録商標）ディスクのようなメディアに入れることができる。特定のソフトウェアモジュールの中のオペレーションのここに示す区分は、例示のためであり、オペレーションの別の区分も使用できることに注意されたい。従って、１つのソフトウェアモジュールにより遂行されるものとして述べるオペレーションは、複数のソフトウェアモジュールにより遂行されてもよい。同様に、複数のモジュールにより遂行されるものとして述べるオペレーションは、１つのモジュールにより遂行されてもよい。又、特定のコンピュータにより遂行されるものとして開示するオペレーションは、複数のコンピュータにより遂行されてもよいことに注意されたい。更に、種々の実施形態において、ピア・ツー・ピア及び／又はグリッドコンピューティング技術が使用されてもよいことに注意されたい。更に、種々の実施形態において、ソフトウェアモジュール間でリモート通信が行なえることに注意されたい。このようなリモート通信は、例えば、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）、Ｊａｖａ（登録商標）メッセージングサービス（ＪＭＳ）、及び／又はリモートメソッドインボケーション（ＲＭＩ）を含むことができる。
【００５６】
図５は、本発明の種々の実施形態に使用できるターミナル、即ち例示的コンピュータを示すブロック図である。以下、対応する参照符号を、対応する部分に適用する。図５の例示的ターミナル５０００は、処理ユニットＣＰＵ５０３と、信号受信器５０５と、ユーザインターフェイス（５０１、５０２）とを示す。信号受信器５０５は、例えば、単一搬送波又は多搬送波の受信器でよい。信号受信器５０５及びユーザインターフェイス（５０１、５０２）は、処理ユニット５０３に結合される。多搬送波信号ターミナル部分５０５とメモリ５０４との間には、１つ以上の直接メモリアクセス（ＤＭＡ）チャンネルが存在する。ユーザインターフェイス（５０１、５０２）は、ユーザがターミナル５０００を使用できるようにするためのディスプレイ及びキーボードを備えている。更に、ユーザインターフェイス（５０１、５０２）は、音声信号を受け取り及び発生するためのマイクロホン及びスピーカを備えている。又、ユーザインターフェイス（５０１、５０２）は、音声認識（図示せず）も含む。
【００５７】
処理ユニットＣＰＵ５０３は、マイクロプロセッサ（図示せず）、メモリ５０４、及びおそらくソフトウェアを備えている。ソフトウェアは、メモリ５０４に記憶することができる。マイクロプロセッサは、ソフトウェアに基づき、データストリーム、データ受信におけるインパルスバーストノイズの公差を受け取り、ユーザインターフェイスに出力を表示し、そしてユーザインターフェイスから受け取った入力を読み取り、等のターミナル５０００のオペレーションを制御する。ハードウェアは、信号を検出する回路、復調回路、インパルスを検出する回路、著しい量のインパルスノイズが存在する場合には記号のサンプルをブランキングする回路、推定値を計算する回路、及び崩壊したデータの修正を遂行する回路を含む。
【００５８】
更に、図５を参照すれば、ミドルウェア又はソフトウェア実施を適用することができる。ターミナル５０００は、例えば、ユーザが快適に携帯できるハンドヘルド装置でよい。ターミナル５０００は、例えば、マルチキャスト送信ストリームを受信するための多搬送波信号ターミナル部分５０５を備えたセルラー移動電話でよい。それ故、ターミナル５０００は、おそらく、サービスプロバイダーと対話することができる。
【００５９】
ここに述べる種々のオペレーション等は、種々の実施形態において、ハードウェアで（例えば、１つ以上の集積回路を経て）実施できることに注意されたい。例えば、種々の実施形態において、ここに述べる種々のオペレーション等は、特殊なハードウェアで実行されてもよいし、１つ以上の汎用プロセッサではない他のもので実行されてもよい。種々の実施形態において、１つ以上のチップ及び／又はチップセットが使用されてもよい。種々の実施形態において、１つ以上の特定用途向け集積回路（ＡＳＩＣ）が使用されてもよい。
【００６０】
効果及び範囲
前記説明は、多数の特定例を含むものであったが、それらは、本発明を例示するためのものであり、本発明の範囲を限定するものではない。従って、当業者であれば、本発明の精神又は範囲から逸脱せずに本発明のシステム及びプロセスに種々の変更や修正がなされ得ることが明らかであろう。
【００６１】
更に、上述した本発明の実施形態、特徴、方法、システム、及び詳細は、本発明の新たな実施形態を生成し又は説明するように別々に又は任意の組み合せで結合できる。
【図面の簡単な説明】
【００６２】
【図１】本発明の種々の実施形態によるサービスオペレータのオペレーションに含まれる例示的ステップを示す図である。
【図２】本発明の種々の実施形態によるサービスオペレータのオペレーションに含まれる更に別の例示的ステップを示す図である。
【図３】本発明の種々の実施形態によるユーザのオペレーションに含まれる例示的ステップを示す図である。
【図４】例示的コンピュータを示す図である。
【図５】更に別の例示的コンピュータを示す図である。
【図１】
2008546237.tif 000016
【図２】
2008546237.tif 000017
【図３】
2008546237.tif 000018
【図４】
2008546237.tif 000019
【図５】
2008546237.tif 000020
【手続補正書】
【提出日】平成20年2月14日(2008.2.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
時間を計算するステップであって、この計算には、データセットに対するデータセット送信終了時間、バックオフオフセット時間、及びバックオフウインドウが考慮されるステップと、
前記計算された時間に、受け取られた修理要求の数に対する要求を１つ以上の修理サーバーに送信するステップと、
ポイント・ツー・ポイント修理及びポイント・ツー・マルチポイント修理の一方を最も有効な修理モードであると決定するステップと、
前記決定された最も有効な修理モードを１つ以上の修理サーバーに通知するためのステップと、
を備えた方法。
【請求項２】
データのある部分を受信しなかった受信器の数を推定するステップを更に備えた、請求項１に記載の方法。
【請求項３】
ポイント・ツー・ポイントチャンネルオーバーヘッドを推定するステップを更に備えた、請求項１に記載の方法。
【請求項４】
ポイント・ツー・マルチポイントチャンネルオーバーヘッドを推定するステップを更に備えた、請求項１に記載の方法。
【請求項５】
ポイント・ツー・マルチポイント修理セッションロスパーセンテージを推定するステップを更に備えた、請求項１に記載の方法。
【請求項６】
首尾良いデータセット受信の数を推定するステップを更に備えた、請求項１に記載の方法。
【請求項７】
ポイント・ツー・ポイントチャンネルを経てデータユニットをトランスポートするためのコストを推定するステップを更に備えた、請求項１に記載の方法。
【請求項８】
ポイント・ツー・マルチポイントチャンネルを経てデータユニットをトランスポートするためのコストを推定するステップを更に備えた、請求項１に記載の方法。
【請求項９】
修理モードの有効性を推定するステップを更に備えた、請求項１に記載の方法。
【請求項１０】
デジタルビデオブロードキャスティング・フォー・ハンドヘルドのポイント・ツー・マルチポイントが使用される、請求項１に記載の方法。
【請求項１１】
ユニバーサルモバイルテレコミュニケーションズサービスのポイント・ツー・ポイントが使用される、請求項１に記載の方法。
【請求項１２】
プログラムコードが記憶されたメモリと、
メモリと通信状態に配置され、前記記憶されたプログラムコードに基づいてインストラクションを実行するためのプロセッサと、
を備え、前記プログラムコードは、前記プロセッサにより実行されたときに、前記プロセッサが、
時間を計算し、この計算には、データセットに対するデータセット送信終了時間、バックオフオフセット時間、及びバックオフウインドウが考慮され、
前記計算された時間に、受け取られた修理要求の数に対する要求を１つ以上の修理サーバーに送信し、
ポイント・ツー・ポイント修理及びポイント・ツー・マルチポイント修理の一方を最も有効な修理モードであると決定し、
前記決定された最も有効な修理モードを１つ以上の修理サーバーに通知する、
というようにさせるシステム。
【請求項１３】
プログラムコードが記憶されたメモリと、
メモリと通信状態に配置され、前記記憶されたプログラムコードに基づいてインストラクションを実行するためのプロセッサと、
を備え、前記プログラムコードは、前記プロセッサにより実行されたときに、前記プロセッサが、
データのある部分を受信しなかった受信器の数を推定し、
ポイント・ツー・ポイントチャンネルオーバーヘッドを推定し、
ポイント・ツー・マルチポイントチャンネルオーバーヘッドを推定し、
ポイント・ツー・マルチポイント修理セッションロスパーセンテージを推定し、
ポイント・ツー・ポイント修理モードに対する首尾良い受信の数を推定し、
ポイント・ツー・マルチポイント修理モードに対する首尾良い受信の数を推定し、
ポイント・ツー・ポイント修理モード選択のコストを推定し、
ポイント・ツー・マルチポイント修理モード選択のコストを推定し、
修理モードの有効性を推定し、
ポイント・ツー・ポイント修理及びポイント・ツー・マルチポイント修理の一方を最も有効な修理モードであると決定する、
というようにさせるシステム。
【請求項１４】
ポイント・ツー・ポイントチャンネルを経てある量のデータを送信するコストを推定するステップと、
ポイント・ツー・マルチポイントチャンネルを経てある量のデータを送信するコストを推定するステップと、
修理サーバーから、その修理サーバーにより受け取られる修理要求の数を受け取るステップと、
前記修理サーバーから、その修理サーバーから要求されたエンコード記号の数を受け取るステップと、
修理要求の合計数を推定するステップであって、前記修理サーバーにより受け取られた修理要求の数、０と１との間の選択された値、及び修理サーバーの量が考慮に入れられるステップと、
要求されたエンコード記号の合計数を推定するステップであって、前記修理サーバーから要求されたエンコード記号の数、０と１との間の選択された値、及び修理サーバーの量が考慮に入れられるステップと、
ポイント・ツー・ポイント修理モードに対するコストを計算するステップであって、ポイント・ツー・ポイントチャンネルを経てある量のデータを送信する推定コスト、修理要求の合計数、及び要求されたエンコード記号の合計数が考慮に入れられるステップと、
ポイント・ツー・マルチポイント修理モードに対するコストを計算するステップであって、ポイント・ツー・マルチポイントチャンネルを経てある量のデータを送信する推定コスト、ポイント・ツー・ポイントチャンネルを経てある量のデータを送信する推定コスト、修理要求の合計数、及び修理サーバーから要求されたエンコード記号の数が考慮に入れられるステップと、
を備えた方法。
【請求項１５】
前記データの量は、オクテットである、請求項１４に記載の方法。
【請求項１６】
時間を計算するステップであって、データセット送信終了時間、バックオフオフセット時間、及びバックオフウインドウが考慮されるステップと、
前記計算された時間に、前記修理サーバーにより受け取られた修理要求の数、及び前記修理サーバーから要求されたエンコード記号の数を、前記修理サーバーから要求するステップと、
を更に備えた請求項１４に記載の方法。
【請求項１７】
１つ以上の推定が更新される、請求項１４に記載の方法。
【請求項１８】
修理サーバーへ修理要求を送信する独特な受信器の数を修理サーバーから受け取るステップと、
修理要求を送信する独特な受信器の合計数を推定するステップであって、修理サーバーへ修理要求を送信する独特な受信器の数、０と１との間の選択された値、及び修理サーバーの量が考慮に入れられるステップと、
ポイント・ツー・マルチポイント修理モードの後に回復を経験する受信器の合計数を計算するステップであって、修理サーバーへ修理要求を送信する独特な受信器の数、平均ロスレート、修理要求を送信する独特な受信器の合計数、及び１と０との間の値であって、ポイント・ツー・ポイント接続を使用しない受信器の推定部分に対応する値が考慮に入れられるステップと、
を備えた方法。
【請求項１９】
ポイント・ツー・ポイント修理モードの後に回復を経験する受信器の合計数を、修理要求を送信する独特の受信器の合計数であるとみなすステップを更に備えた、請求項１８に記載の方法。
【請求項２０】
時間を計算するステップであって、データセット送信終了時間、バックオフオフセット時間、及びバックオフウインドウが考慮されるステップと、
前記計算された時間に、修理サーバーへ修理要求を送信する独特な受信器の数を修理サーバーから要求するステップと、
を更に備えた請求項１８に記載の方法。
【請求項２１】
１つ以上の推定が更新される、請求項１８に記載の方法。
【請求項２２】
ポイント・ツー・ポイント修理モードの効率を計算するステップであって、ポイント・ツー・ポイント修理モードの後に回復を経験する受信器の合計数、及びポイント・ツー・ポイント修理モードのコストが考慮に入れられるステップと、
ポイント・ツー・マルチポイント修理モードの効率を計算するステップであって、ポイント・ツー・マルチポイント修理モードの後に回復を経験する受信器の合計数、及びポイント・ツー・マルチポイント修理モードのコストが考慮に入れられるステップと、
ポイント・ツー・マルチポイント修理モードの方がポイント・ツー・ポイント修理モードより効率が高いと決定された場合には、ポイント・ツー・マルチポイント修理モードを使用するステップと、
を備えた方法。
【請求項２３】
ポイント・ツー・マルチポイント修理モードの方がポイント・ツー・ポイント修理モードより効率が高いと決定された場合には、ポイント・ツー・マルチポイント修理モードに受信器を再指向するステップを更に備え、修理は、ある時間の前にはポイント・ツー・ポイントであり、そしてその時間の後にはポイント・ツー・マルチポイントである、請求項２２に記載の方法。
【請求項２４】
ポイント・ツー・ポイント修理モードに対して満足な受信器当たりのコストを計算するステップと、
ポイント・ツー・マルチポイント修理モードに対して満足な顧客当たりのコストを計算するステップと、
を更に備えた請求項２２に記載の方法。
【請求項２５】
決定された最も効果的な修理モードを１つ以上の修理サーバーに通知するステップを更に備えた、請求項２２に記載の方法。
【請求項２６】
プログラムコードが記憶されたメモリと、
前記メモリと通信状態に配置され、前記記憶されたプログラムコードに基づいてインストラクションを実行するためのプロセッサと、
前記プロセッサと通信状態に配置されたネットワークインターフェイスと、
を備え、前記プログラムコードは、前記プロセッサにより実行されたときに、前記プロセッサが、
ポイント・ツー・ポイントチャンネルを経てある量のデータを送信するコストを推定し、
ポイント・ツー・マルチポイントチャンネルを経てある量のデータを送信するコストを推定し、
修理サーバーから、その修理サーバーにより受け取られる修理要求の数を受け取り、
修理サーバーから、その修理サーバーから要求されたエンコード記号の数を受け取り、
修理要求の合計数を推定し、ここでは、前記修理サーバーにより受け取られた修理要求の数、０と１との間の選択された値、及び修理サーバーの量が考慮に入れられ、
要求されたエンコード記号の合計数を推定し、ここでは、前記修理サーバーから要求されたエンコード記号の数、０と１との間の選択された値、及び修理サーバーの量が考慮に入れられ、
ポイント・ツー・ポイント修理モードに対するコストを計算し、ここでは、ポイント・ツー・ポイントチャンネルを経てある量のデータを送信する推定コスト、修理要求の合計数、及び要求されたエンコード記号の合計数が考慮に入れられ、
ポイント・ツー・マルチポイント修理モードに対するコストを計算し、ここでは、ポイント・ツー・マルチポイントチャンネルを経てある量のデータを送信する推定コスト、ポイント・ツー・ポイントチャンネルを経てある量のデータを送信する推定コスト、修理要求の合計数、及び修理サーバーから要求されたエンコード記号の数が考慮に入れられ、
というようにされたサーバー。
【請求項２７】
前記データの量は、オクテットである、請求項２６に記載のサーバー。
【請求項２８】
前記プロセッサは、更に、
時間を計算し、ここでは、データセット送信終了時間、バックオフオフセット時間及びバックオフウインドウが考慮され、
前記計算された時間に、前記修理サーバーにより受け取られた修理要求の数、及び前記修理サーバーから要求されたエンコード記号の数を、前記修理サーバーから要求する、
ことを行なう請求項２６に記載のサーバー。
【請求項２９】
１つ以上の推定が更新される、請求項２６に記載のサーバー。
【請求項３０】
プログラムコードが記憶されたメモリと、
前記メモリと通信状態に配置され、前記記憶されたプログラムコードに基づいてインストラクションを実行するためのプロセッサと、
前記プロセッサと通信状態に配置されたネットワークインターフェイスと、
を備え、前記プログラムコードは、前記プロセッサにより実行されたときに、前記プロセッサが、
修理サーバーへ修理要求を送信する独特な受信器の数を修理サーバーから受け取り、
修理要求を送信する独特な受信器の合計数を推定し、ここでは、修理サーバーへ修理要求を送信する独特な受信器の数、０と１との間の選択された値、及び修理サーバーの量が考慮され、
ポイント・ツー・マルチポイント修理モードの後に回復を経験する受信器の合計数を計算し、ここでは、修理サーバーへ修理要求を送信する独特な受信器の数、平均ロスレート、修理要求を送信する独特な受信器の合計数、及び１と０との間の値であって、ポイント・ツー・ポイント接続を使用しない受信器の推定部分に対応する値が考慮される、
というようにしたサーバー。
【請求項３１】
前記プロセッサは、更に、ポイント・ツー・ポイント修理モードの後に回復を経験する受信器の合計数を、修理要求を送信する独特の受信器の合計数であるとみなす、請求項３０に記載のサーバー。
【請求項３２】
前記プロセッサは、更に、
時間を計算し、ここでは、データセット送信終了時間、バックオフオフセット時間及びバックオフウインドウが考慮され、
前記計算された時間に、修理サーバーへ修理要求を送信する独特な受信器の数を修理サーバーから要求する、
ことを行なう請求項３０に記載のサーバー。
【請求項３３】
１つ以上の推定が更新される、請求項３０に記載のサーバー。
【請求項３４】
プログラムコードが記憶されたメモリと、
前記メモリと通信状態に配置され、前記記憶されたプログラムコードに基づいてインストラクションを実行するためのプロセッサと、
前記プロセッサと通信状態に配置されたネットワークインターフェイスと、
を備え、前記プログラムコードは、前記プロセッサにより実行されたときに、前記プロセッサが、
ポイント・ツー・ポイント修理モードの効率を計算し、ここでは、ポイント・ツー・ポイント修理モードの後に回復を経験する受信器の合計数、及びポイント・ツー・ポイント修理モードのコストが考慮に入れられ、
ポイント・ツー・マルチポイント修理モードの効率を計算し、ここでは、ポイント・ツー・マルチポイント修理モードの後に回復を経験する受信器の合計数、及びポイント・ツー・マルチポイント修理モードのコストが考慮に入れられ、
ポイント・ツー・マルチポイント修理モードの方がポイント・ツー・ポイント修理モードより効率が高いと決定された場合には、ポイント・ツー・マルチポイント修理モードを使用する、
というようにされたサーバー。
【請求項３５】
前記プロセッサは、更に、ポイント・ツー・マルチポイント修理モードの方がポイント・ツー・ポイント修理モードより効率が高いと決定された場合には、ポイント・ツー・マルチポイント修理モードに受信器を再指向し、修理は、ある時間の前にはポイント・ツー・ポイントであり、そしてその時間の後にはポイント・ツー・マルチポイントである、請求項３４に記載のサーバー。
【請求項３６】
前記プロセッサは、更に、
ポイント・ツー・ポイント修理モードに対して満足な受信器当たりのコストを計算し、
ポイント・ツー・マルチポイント修理モードに対して満足な顧客当たりのコストを計算する、
ことを行なう請求項３４に記載のサーバー。
【請求項３７】
前記プロセッサは、更に、決定された最も効果的な修理モードを１つ以上の修理サーバーに通知する、請求項３４に記載のサーバー。
【国際調査報告】
2008546237.tif 000021
2008546237.tif 000022
2008546237.tif 000023
2008546237.tif 000024