JP2010500832A

JP2010500832A - 簡易型ソケットインタフェースを経由する放送／同報ｉｐパケットをサポートするための装置と方法

Info

Publication number: JP2010500832A
Application number: JP2009523969A
Authority: JP
Inventors: リオイ、マルセロ; バッバー、アッピンダー・シング
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2006-08-09
Filing date: 2007-08-07
Publication date: 2010-01-07
Also published as: KR20090047518A; EP2060093A2; US20080040487A1; TW200818817A; WO2008070217A3; WO2008070217A2; CN101502080A; US8180899B2

Abstract

利用可能なローカルインタフェースを調査し、それらが特定のＩＰアドレスからデータを受信するように構成される能力について判定し、そのように構成可能であればＩＰアドレスを受信するためのインタフェースを構成し、このＩＰアドレスをそのインタフェースにバインドするように、bind()アプリケーションプログラミングインタフェース（ＡＰＩ）を修正した、放送または同報データフローを受信するためのＩＰアドレス構成方法。修正されたbind*()ＡＰＩは、各インタフェースがＩＰアドレスに対して構成されることができるかどうかを確認するために１つ以上のインタフェースと情報交換するかもしれない。あるいは、修正されたbind*()ＡＰＩは、アクセス制御リストを参考にして、インタフェースの構成可能性を判定する。修正されたbind*()操作がポリシーパラメータに基づいて最高の優先度のインタフェースを構成するように、ポリシーベースのルーティングルールが実施されるかもしれない。

Description

本出願は、２００６年８月９日出願の米国仮出願番号60/836,780の利益を主張する。これらの内容は全体としてここに参照として組み込まれる。

本発明はクライアントプロセッサとのＩＰ接続を確立するためのアプリケーションプログラミングインターフェースツールおよび方法に関する。

インターネット技術は高品質のオーディオおよびビデオコンテンツを、テレビジョンジョン、ラジオおよび他の形式のオーディオおよびビデオ配信のこれまでの範囲を超えた場所および機器に配信することを可能とする。このことにより、インターネットを介して放送音声およびビデオストリームを配信するための多くの新しいアプリケーションおよび機器の開発が進められてきた。例えば、テレビジョンクリップのようなビデオを携帯電話で受信することが今や可能である。そのような技術には、視覚媒体、テレビジョン、および映画産業に変革をもたらす可能性がある。したがって、インターネットを介して放送ストリームを様々な機器に配信するアプリケーションに対する要求が増え続けている。

インターネットを介して放送または同報ビデオストリームを受信するアプリケーションは、ビデオストリームの送信源に結びつけられるインターネットへの接続を確立しなければならない。最近のオペレーティングシステムにおいてインターネットに接続するための標準インタフェースは、ＢＳＤソケットＡＰＩとも言われるバークレーソケットアプリケーションプログラミングインタフェース（ＡＰＩ）として知られている。（ＢＳＤはBerkeley Software Distributionを意味し、バークレーＵｎｉｘ(登録商標）と呼ばれることがある）。ＡＰＩは、コンピュータシステムまたはプログラムライブラリが、コンピュータプログラム（アプリケーション）でなされる標準的サービスに対する要求をサポートするために提供するソースコードインタフェースである。バークレーソケットＡＰＩは、Ｃプログラミング言語で計算機ネットワーキングアプリケーションを開発するために有効なルーチンライブラリを含む。バークレーソケットＡＰＩが、使用されている唯一のＡＰＩでないが、インターネットアプリケーションの開発に適するほとんどのプログラミング言語は、内蔵されるルーチンおよびそれらの機能において類似したインタフェースを用いる。さらに、多くのプログラミング言語がＢＳＤソケットＡＰＩ版を採用している。したがって、ここに述べるＡＰＩの説明はＢＳＤソケットＡＰＩのフォーマットおよび機能に基づいている。

アプリケーションがインターネットを介して放送または同報ビデオストリームを受信するために、送信源への「ソケット」と呼ばれる接続が作成されなければならない。ソケットはクライアントとサーバとの間のインターネット接続のエンドポイントである。ソケットを作成することによって、サーバによって送られたパケットが、クライアントのアプリケーションに配信されることが確実になる。ソケットを作成するために、アプリケーションはsocket()ＡＰＩを呼出す。この様な方法でソケットを作成する場合、ソケットはアドレスファミリーが与えられるが、クライアント機器の特定のローカルインタフェースには割り当てられない。したがって、ソケットがサーバから入力データを受けるかもしれないより前に、ソケットはインターネットとの機器インタフェースとして用いられる特定のローカルインタフェースに割り当てられなければならない。特定のローカルアドレスをソケットに割り当てる１つの方法はbind()ＡＰＩによって成される。

アプリケーションが放送または同報ストリームを受信するために、アプリケーションはioctl()またはsocket_opt()呼出のいずれかを呼出さなければならない。ioctl()またはsocket_opt()呼出のいずれかを呼出す場合、ＩＰ放送ストリームを受信するときに用いられる特定のインタフェースは既知でなければならない。しかし、通常の機器には、データが受信されるかもしれないときに用いられる多くのインタフェースがある。ＩＰデータストリームが受信される時に用いられる特定のローカルインタフェースを決定するために、予めアプリケーションは複雑な命令セットを実行しなければならない。この付加的な複雑は、不必要なプログラムオーバヘッド、アプリケーション開発コスト、および放送ストリームへの接続確立時の処理遅延を引き起こす。

放送データフローを受信するためにＩＰアドレスを構成するためのストリームライン法を種々の実施例を用いて提供する。bind()ＡＰＩを修正、拡張して、利用可能なローカルインタフェースを調査し、あるインタフェースが特定のＩＰアドレスからデータを受信するように構成されうるかを判定し、そのインタフェースがそのように構成される可能性がある場合、そのインタフェースを構成し、次にＩＰアドレスをそのインタフェースにバインドするようにする。一実施例において、bind()ＡＰＩは、１つ以上のインタフェースと、各インタフェースがそのＩＰアドレスに対して構成されうるかを確認するために明示的に情報交換する。別の実施例において、bind()ＡＰＩは、ルーティングルックアップテーブルを参考にして、インタフェースの構成可能性を判定する。この実施例の変形例において、bind()操作がポリシーパラメータに基づく最優先度のインタフェースを構成するために、ポリシーベースのルーティングルールが実施されるかもしれない。

従来技術のbind()ＡＰＩの機能を示すフローチャートである。従来技術のbind()ＡＰＩの機能を示すフローチャートである。本発明の、bind()ＡＰＩに対する修正の第１の実施例を示す処理フローチャートである。本発明の、bind()ＡＰＩに対する修正の第２の実施例を示す処理フローチャートである。本発明の、図２に示す実施例の代替を示す処理フローチャートである。本発明の、図３に示す実施例の代替を示す処理フローチャートである。本発明の、図２に示す実施例を実施する修正bind()ＡＰＩの機能を示す処理フローチャートである。本発明の、図３に示す実施例を実施する修正bind()ＡＰＩの機能を示す処理フローチャートである。本発明の、図４に示す実施例を実施する修正bind()ＡＰＩの機能を示す処理フローチャートである。本発明の、図５に示す実施例を実施する修正bind()ＡＰＩの機能を示す処理フローチャートである。本発明の、上記実施例で使用される移動機器を示す図である。

ここに組み込まれ、本明細書の部分を構成する添付図面は、本発明の代表的実施例を例示し、上記一般的説明と下記詳細な説明と共に、本発明の特徴を説明することに役立つ。

添付図面を参照して種々の実施例を詳細に説明する。可能であれば常に、図面全般にわたり、同じ参照記号を同一または類似の部品を参照するために用いられる。ここでのbind()ＡＰＩへの参照は、ここに説明し図面で例示する機能のすべての実施を参照するように意図されており、本発明の範囲または特許請求範囲を特定の関数呼出、ＡＰＩの実施、ソフトウェアプログラミング言語またはアプリケーションに限定するように意図されているものではない。

現在、さまざまな電子機器は、有線および無線ネットワーク上でインターネットデータを受信することができ、したがって、放送および同報用アプリケーションを実施することができる。そのような装置はパーソナルコンピュータ、ラップトップコンピュータ、およびワークステーションを含む。最近では、携帯電話、無線モデムを備えた携帯情報端末（ＰＤＡ）、無線電子メール受信機（例えば、Blackberry(登録商標）およびTreo（登録商標）機器）、並びにインターネットで動作可能なマルチメディア携帯電話（例えば、iPhone（登録商標））のような移動機器はインターネットへのポータルになっている。移動機器用の放送および同報用ビデオＩＰアプリケーションの発展が従来の個人用計算機のそれらをいつか凌駕するかもしれないと予想されている。

一般に、電池の寿命を延ばすために電力消費を最小にするという理由以外に理由がなければ、移動機器（例えば、ＰＤＡ、携帯電話）は、パーソナルコンピュータおよびラップトップコンピュータに較べて限定的な計算能力とメモリーを有している。その結果、移動機器で実行されるアプリケーションは、可能なところはすべて効率的にし、かつ不要な処理のオーバヘッドを排除する必要がある。この目的のために、本発明の種々の実施例は、放送ＩＰパケットを受信するためのソケット接続を確立するための簡易な方法を提供する。

種々の実施例は、bind()ＡＰＩを修正し、または新しいbind_broadcast()ＡＰＩを提案する。したがって、実施例を説明する前に、従来のbind()ＡＰＩの実施の機能を復習することが有効である。

bind()ＡＰＩは１つのソケットを１つのローカルインタフェースに割り当て、その結果送信源サーバからそのソケットを介して流れるデータが、アプリケーションによって受信されることができる。bind()ＡＰＩ呼出は３つの引数を必要とする。第１に、この呼出は、ソケットを表す記述子を含まなければならない。これはデータを読み、書くためにソケットに対するハンドルとして用いられるsocket()ＡＰＩを実行した後に受け取る値である。第２に、この呼出は、システム上で構成されたＩＰアドレスへのバインドを完成するために用いられるローカルＩＰアドレスおよびローカルポート番号の双方を定義するデータ構造を指定しなければならない。あるいは、第２の引数としてワイルドカード値（多くのＡＰＩ実施において「０」またはINADDR_ANY）が提供されるかもしれない。この場合、ＡＰＩは、ＩＰアドレスによって構成された任意のインタフェースをバインドするだろう。しかし、種々の実施例の説明を簡単にするために、この関数の引数はここでは指示されたＩＰアドレスまたは単にＩＰアドレスと呼ばれるだろう。第３に、この呼出はローカルアドレスの長さを指定しなければならない。これによりこの関数が異なるバージョンのＩＰに対応できるようになる。

ＩＰアドレスがbind()ＡＰＩ呼出に含まれている場合（すなわち、INADDR_ANYの選択ではない場合）、この関数は、機器またはシステムの各ローカルインタフェースを評価し、そのインタフェースがそのＩＰアドレスと接続するように構成されているかどうかを確認する。ＩＰアドレスに対して構成されたローカルインタフェースを見つけた場合、bind()関数は特定のローカルポート番号を発信データグラムの送信源ポートとしておよびソケットを介して受信される到来データグラムに対する宛先ポートとして割り当てる。また、この関数は、バインディング操作の完了に成功したことを示すための「０」のフラグ値を返す。Ｕｎｉｘのようないくつかの実施においてはこの成功フラグ値は「０」であり、したがって例示のために、図および説明において成功フラグ値として「０」を用いる。しかし、本発明および特許請求の範囲は「０」の成功フラグ値を用いることに限定されると解釈されるべきではない。ローカルインタフェースがbind()ＡＰＩ呼出で指定されるＩＰアドレスに対して構成されない場合、誤り符号が生成され、操作が失敗したことを示すための失敗フラグ値が返される。Ｕｎｉｘのようないくつかの実施においてはこの失敗フラグ値は「−１」であり、したがって例示のために、図および説明において失敗フラグ値として「−１」を用いる。しかし、本発明および特許請求の範囲は「−１」の失敗フラグ値を用いることに限定されると解釈されるべきではない。このように、ローカルインタフェースがＩＰアドレスに対してまだ構成されていない場合、bind()関数呼出は失敗するだろう。アプリケーションによるアクセスのために、生成される誤り符号はレジスタ、例えば「errno」と名付けたレジスタ、に格納されるかもしれない。誤り符号は異なるＡＰＩ実施の間で変わるかもしれず、また既存文書の裏付けがあるため、そのような誤り符号の詳細は本発明に必須ではない。

INADDR_ANYワイルドカードまたは「０」がbind()ＡＰＩ呼出のローカルアドレスとして指定される場合、関数は指示されたソケットにアクセスするように構成されたすべてのローカルインタフェースにバインドするだろう。いずれのインタフェースもそのように構成されていない場合、誤り符号が生成され、操作が失敗したことを示すためにフラグ値（−１）が返される。

図１ＡにＩＰアドレスが示されたときの（すなわち、INADDR_ANY機能を除いた）bind()ＡＰＩの基本的な機能的ステップを示す。このフローチャートは、関数の最上位の機能を示すことが意図されており、必ずしもＡＰＩによって実施される実際のソフトウェア処理を反映していない。bind()呼出１０は指示されたソケットの記述子、ソケットにバインドされるべきＩＰアドレス、およびＩＰアドレスの長さである。bind()関数がバインディング成功の「０」を、バインディング失敗の場合は「−１」を返す故、このフラグ値は関数の開始時には「−１」に設定されるかもしれない、ステップ１２。またはテストに基づいて後に「−１」に設定されるかもしれない。また、bind()関数は、ＩＰアドレスが示されたかどうか、またはワイルドカード値（例えば、「０」）が指定されたかどうかを判定するために呼出引数をテストする、ステップ１４。特定のＩＰアドレスが関数呼出において要求される場合、（すなわち、テスト１４の結果が「はい」である場合）、bind()関数は、一度に一つ、インタフェースの構成を、例えばループルーチンを実行することによって、テストするかもしれない。このループの例はステップ１６、１８、２０、２８、３０に例示される。カウンタは第１のインタフェースを示すかまたはポイントするために初期化されるかもしれない、ステップ１６。次にカウント値を用いて、関数はインタフェースを選択し、ステップ１８、次に選択されたインタフェースは、そのインタフェースが指示されたＩＰアドレスに対して構成されているかどうかを判定するために質問される、ステップ２０。そのように構成されている場合、関数は指示されたソケットまたはＩＰアドレスを、指定されたローカルインタフェースにバインドする、ステップ２２。次に関数は状態フラグをbind()操作が成功したことを示す「０」に設定する、ステップ２４。次にbind()呼出を行ったアプリケーションへ戻る、ステップ２６。選択されたインタフェースが指示されたＩＰアドレスに対して構成されていない場合（すなわち、テスト２０の結果が「いいえ」の場合）、関数は、評価されるべきインタフェースがさらにあるかどうかを判定するために（例えばカウンタを機器のインタフェースの総数と比較することによって）カウンタをテストする、ステップ２８。評価されるべきインタフェースがさらにある場合、処理を続けるためにステップ１８へループバックする前に次のインタフェースへポイントするためにカウンタを進める、ステップ３０。最後のインタフェースが評価された場合（すなわち、テスト２８の結果が「いいえ」である場合）、誤り符号の値はレジスタ（例えばerrno）に格納される、ステップ３４。次に関数はbind()呼出を行ったアプリケーションへ戻る、ステップ２６。この状況において関数はbind()操作が失敗したことを示す「−１」値を返す。

指定されたローカルインタフェースの値がINADDR_ANYまたは「０」のようなワイルドカードである場合（すなわち、テスト１４の結果が「いいえ」の場合）、任意のインタフェースが任意のＩＰアドレスをサポートするように構成されうるかを判定するために、図１Ｂに示すINADDR_ANY機能を実行することによって、機器内のすべてのインタフェースを調査するだろう。関数は、一度に一つ、すべてのインタフェースを、ループルーチンを実行することによって、テストするかもしれない。このループの例はステップ３８、４０、４２、４４、４６、４８に例示される。カウンタは第１のインタフェースを示すかまたはポイントするために初期化されるかもしれない、ステップ３６。次にカウント値を用いて、関数はインタフェースを選択し、ステップ３８、次に選択されたインタフェースは、そのインタフェースが任意のＩＰアドレスに対して構成されているかを判定するために質問される、ステップ４０。構成されている場合、選択されたインタフェースはソケットにバインドされ、ステップ４２、次に、状態フラグはバインディング成功を示すために「０」に設定される、ステップ４４。しかし、この時点で戻らずに、関数は、評価されるべきインタフェースがさらにあるかどうかをテストすることによってループの実行を続け、各インタフェースの評価を続ける、テスト４６。ない場合、ステップ３８へ戻る前にカウンタを進める、ステップ４８。すべてのインタフェースが評価されると（すなわち、テスト４６の結果が「いいえ」）、関数は、例えば状態フラグが「０」または「−１」と等しいかどうかをテストすることによって、誤り符号が生成されるべきかどうか判定する、テスト３２。状態フラグのテストには多くのフォーマットがあるかもしれず、図示した「−１」か「０」のテストは単に例示目的であることが理解されるだろう。状態フラグ＝−１の場合、インタフェースはバインドされなかった故、関数はbind()ＡＰＩを呼出した処理へステップ２６で戻る前に誤り符号が生成され、提示される必要がある、ステップ３４。しかし、アドレスがバインドされた場合（すなわち、テスト３２の結果が「いいえ」の場合）、関数がbind()ＡＰＩを呼出した処理へステップ２６で戻る前に誤り符号が提示される、ステップ３４。（図１Ａにはテスト３２を示していない。その処理では答えが常に「はい」であるからであり、従って図を簡単にするために図１Ａはテスト２８からステップ３４へ直接進むフローを示していることに注意のこと）。

図１Ａおよび１Ｂに例示する機能が明らかにするように、従来のbind()ＡＰＩは選択されたインタフェースが要求されたＩＰアドレスに対して既に構成されているかどうかを評価するだけである。bind()ＡＰＩのこの限界は、現状では、bind()ＡＰＩ呼出がなされる前に特定のインタフェースが放送または同報データストリームのＩＰアドレスに対して構成されることを確実にする付加的なアプリケーションソフトウェアステップによって克服される。しかし、そのようなソフトウェア命令はオーバヘッドおよび不要な複雑さをソフトウェアアプリケーションに付加する。

図２に、従来のbind()ＡＰＩの限界を克服し、ソケットインタフェースの確立を簡素化するように意図される実施例を示す。この実施例において、指示されたＩＰアドレスに対してインタフェースが構成されうるかどうかを判定する新しい機能２００を加えて、操作がシステムインタフェースを調査する処理への修正を行う。この実施例の説明を簡単化するために、図2は特定のＩＰアドレスがバインドされるように要求される場合に関するbind()ＡＰＩの機能がbind()呼出１０*に含まれていることを示すだけであり、またそれに対応する説明もそのように説明するだけである。

図２に示す実施例の機能は、bind_broadcast()（すなわち、bind()ＡＰＩの修正よりむしろＡＰＩライブラリへの追加）のような新しいＡＰＩ関数として提供されるかもしれない。放送、同報並びに他の関連ビデオおよび／またはオーディオ用のアプリケーションで使用するための新しいbind_broadcast()ＡＰＩを加えることは、これらのアプリケーションが図１Ｂに示すINADDR_ANYワイルドカードの機能を必要としないため、好ましいかもしれない。新しいＡＰＩとして本実施例が実施されるかもしれないことを反映して、この呼出は１０*と名付けられ、図２から図５においてBind*()として識別される。さらに、ＩＰアドレスのテスト１４は放送専用の新しいＡＰＩには必要がないだろう。従ってこのステップは図２から図５において破線で示され、このステップが選択的でありこれらの図面の説明に含まれないことを表す。代替的実施例において、bind()ＡＰＩは、bind()の従来のINADDR_ANYワイルドカードの機能を保持しながら、ここに説明する機能を追加するように修正されるかもしれない。そのような代替的実施例を図６から図９に示し、後で説明する。

図２を参照して、修正されたbind*()関数は図１Ａを参照して説明したものと同様の方法で、すべてのローカルインタフェースが評価されるまで続く。具体的には、フラグ値は関数の開始時に−１に設定されるかもしれない、ステップ１２。（または、後でテストに基づいて「−１」に設定されるかもしれない）。特定のＡＰＩの実施に依存して、bind()関数は、一度に一つ、すべてのインタフェースを、ループルーチンを実行することによって、テストするかもしれない。このループ例をステップ１６、１８、２０、２８、３０に例示する。カウンタは第１のインタフェースを示すかまたはポイントするために初期化されるかもしれない、ステップ１６。次にカウント値を用いて、関数はインタフェースを選択し、ステップ１８、次に選択されたインタフェースは、そのインタフェースが指示されたＩＰアドレスに対して構成されているかを判定するために質問される、ステップ２０。そのように構成されている場合、bind*()関数は指示されたソケットまたはＩＰアドレスを、指定されたローカルインタフェースにバインドする、ステップ２２。次に関数は状態フラグをbind*()操作が成功したことを示す「０」に設定する、ステップ２４。次にbind()呼出を行ったアプリケーションへ戻る、ステップ２６。選択されたインタフェースが指示されたＩＰアドレスに対して構成されていない場合（すなわち、テスト２０の結果が「いいえ」の場合）、関数は、評価されるべきインタフェースがさらにあるかどうかを判定するために（例えばカウンタを機器のインタフェースの総数と比較することによって）カウンタをテストする、ステップ２８。評価されるべきインタフェースがさらにある場合、処理を続けるためにステップ１８へループバックする前に次のインタフェースへポイントするためにカウンタを進める、ステップ３０。

最後のインタフェースが評価された場合（すなわち、テスト２８の結果が「いいえ」の場合）、このことは、どのインタフェースも指示されたＩＰアドレスに対して構成されなかったことを意味する。しかし、戻ることおよびバインド失敗を示さずに、新しい機能２００が実施される。この新しい機能２００は、インタフェースが所望のＩＰアドレスに対して構成されうるかどうかを判定するために、例えば第２のループ（例えばステップ２１４、２１６、２１８、２２４、２２６）を実施することにより、各インタフェースを再度評価する。例えば、カウンタは第１のローカルインタフェースを示すかまたはポイントするために初期化されるかもしれない、ステップ２１４。つづいて評価のためにそのインタフェースの選択がされる、ステップ２１６。次に、関数は選択されたインタフェースが指示されたＩＰアドレスに対して構成されうるかどうかを判定するために、選択されたインタフェースを評価する、ステップ２１８。構成されうる場合、インタフェースがそのＩＰアドレスに対して構成される、ステップ２２０。インタフェースが構成されると、ソケットは、通常のbind()ＡＰＩの標準的機能と同様にそのインタフェースにバインドされる、ステップ２２。バインド操作の完了に成功すると、状態フラグは「０」に変更されるかもしれない、ステップ２４。次にbind*()呼出を行ったアプリケーションに戻ることによって関数は終了する、ステップ２６。

修正bind*()関数が特定のＩＰアドレスに対するインタフェースの構成可能性をテストすることができる少なくとも２つの方法がある。第１の方法において、bind*()関数は、選択されたインタフェースが指示されたアドレスに対して構成され得るかどうかを判定するために、選択されたインタフェースと明示的に情報交換することができる。このことは、指示されたＩＰアドレスを用い、および成功値が返されるかどうかをテストして、選択されたインタフェースに関する構成操作ＡＰＩまたは同様の関数呼出を実行することを含むかもしれない。また、これは、構成が可能であるかどうかを確認するだけではなく（戻値によって伝達された情報）、同じステップ内で構成を完了する。その結果、図に示すステップ２１８およびステップ２２０は結合されるか単一の処理呼出で成されるかもしれない。指示されたＩＰアドレスに対する構成が可能であるという報告を返すだけの処理呼出しが用いられる場合には、構成を完成するために分離した別の操作、ステップ２２０、がbind*()関数に含まれるだろう。

第２の方法において、新しいbind*()関数は、選択されたインタフェースの構成パラメータを決定するために、例えばアクセス制御リスト（ＡＣＬ）、またはインタフェース構成に関する情報を含む別のデータベースにアクセスすることにより、ルーティング検索法を用いることができる。機器またはシステムがポリシーベースのルーティングを実施済みの場合、ＡＣＬはアドレスに対して各インタフェースが構成されたそのアドレス、および各インタフェースの入力／出力構成可能性を記載するかもしれない。したがって、ＡＣＬ検索を行うことにより（例えばＡＣＬに記載された各インタフェース値を検討するループを実行することにより）、関数はいずれかのインタフェースが指示されたＩＰアドレスもしくはソケットに対して構成されているかまたは構成されるかもしれないかを素早く判定できる。

すべての機器またはシステムのインタフェースが評価された場合（すなわち、テスト２２４の結果が「いいえ」である場合）、どのインタフェースも指示されたＩＰアドレスにバインドされていない。このことはどのインタフェースも指示されたＩＰアドレスに対して構成されることができないことを示す。それ故、修正されたbind*()関数は失敗し、従って関数は誤りレジスタに誤り符号を提示し、ステップ３４、bind*()ＡＰＩを呼出したアプリケーションへ戻る、ステップ２６。図２に示す例示的処理において、バインド操作が完了されなかったため、状態フラグは「０」に変更されなかった。従って、bind*()操作が失敗したことを示す「−１」値が返される。プログラミング技術者は、様々な方法および処理フローの間の様々な点でbind*()の戻値を設定できることを理解するだろう。

図３にシステムまたは機器のローカルインタフェース全体を通した単一ループのみを必要とする本発明を実施するための代替的実施例を示す。図２を参照して上で説明した実施例のように、関数は選択されたインタフェースが指示されたＩＰアドレスに対して構成されないと判定される（テスト２０）まで従来のbind()関数に類似した方法で始まる。具体的には、関数の開始時にフラグ値は−１に設定されるかもしれない、ステップ１２、（または、後でテストに基づいて「−１」に設定されるかもしれない）。特定のＡＰＩの実施に依存して、bind()関数は、一度に一つ、すべてのインタフェースを、ループルーチンを実行することによって、テストするかもしれない。このループ例をステップステップ１６，１８，２０，２８，３０に例示する。カウンタは第１のインタフェースを示すかまたはポイントするために初期化されるかもしれない、ステップ１６。次にカウント値を用いて、bind*()関数はインタフェースを選択し、ステップ１８、次に選択されたインタフェースは、そのインタフェースが指示されたＩＰアドレスに対して構成されているかを判定するために質問される、ステップ２０。そのように構成されている場合、関数は指示されたソケットまたはＩＰアドレスを指定されたローカルインタフェースにバインドする、ステップ２２。次に関数は状態フラグをbind*()操作が成功したことを示す「０」に設定する、ステップ２４。次にbind*()呼出を行ったアプリケーションへ戻る、ステップ２６。

しかし、選択されたインタフェースが指示されたＩＰアドレスに対して構成されていない場合（すなわち、テスト２０の結果が「いいえ」の場合）、関数は、インタフェースが指示されたＩＰアドレスに対して構成されうるかを判定するためにそのインタフェースを評価する、ステップ２１８。上で検討したように、この評価を行うことができる少なくとも２つの方法がある。インタフェースが指示されたＩＰアドレスに対して構成され得ると判定された場合、そのインタフェースはそのように構成され、ステップ２２０、その後選択されたインタフェースはソケットにバインドされる、ステップ２２。インタフェースのＩＰアドレスへのバインドに成功すると、状態フラグは「０」に設定され、ステップ２４、その後関数はbind*()ＡＰＩを呼出したアプリケーションへ戻る。選択されたインタフェースが指示されたＩＰアドレスに対して構成されることができない場合（すなわち、テスト２１８の結果が「いいえ」の場合）、関数は、評価されるべきインタフェースがさらにあるかどうかを判定するためにカウントをテストする、ステップ２８。評価されるべきインタフェースがさらにある場合、ステップ１８へループバックする前にカウンタを進める、ステップ３０。評価されるべきインタフェースがもはや無い場合（すなわち、テスト２８の結果が「いいえ」の場合）、このことは、インタフェースはバインドされていないことを意味し、したがってbind*()ＡＰＩを呼出したアプリケーションへステップ２６で戻る前に誤り符号が誤りレジスタに提示される、ステップ３４。

図４に第３の実施例を示す。これは放送または同報データストリームを受信できるかどうかに関して各インタフェースに実行される追加テストを含む。この実施例において、bind*()関数は、新しいステップ４００以外は図２を参照して上で説明した手法と同一の手法で進行する。従って、冗長な説明に対する要求を避けるために、図２の説明がここに参照として組み込まれる。bind*()関数があるインタフェースをインジケータＩＰアドレスに対するその構成可能性の評価のために選択すると、関数は、最初に選択されたインタフェースをテストし、そのインタフェースにＩＰデータの放送または同報ストリームを受信する可能性があるかどうかを判定する、ステップ４００。このテストはインタフェースパラメータを決定するためにＡＣＬにアクセスすることによって、またはインタフェースの直接質問を実行することによって、成されるかもしれない。特定のインタフェースをその構成可能性に対して評価する前に、ＩＰデータの放送または同報ストリームの受信に対する選択されたインタフェースの能力を評価することは効率的であるかもしれない。この判定はＡＣＬを介して直ちになされ、一方インタフェースの構成可能性を判定することは処理能力が原因でより時間が掛かるかもしれないからである。この評価により、インタフェースがＩＰデータの放送または同報ストリームを受信できると確認する場合、（すなわち、テスト４００の結果が「はい」の場合）、bind*()関数は、選択されたインタフェースが指示されたＩＰアドレスに対して構成されることが可能であるかどうかをテストするために、次へ進む、ステップ２１８。しかし、この評価が選択されたインタフェースがＩＰデータの放送または同報ストリームを受信できない場合、例えば追加のインタフェースが評価のために利用可能かどうかをテストし、ステップ２２４、利用可能であれば、カウンタを進めることにより、ステップ２２６、bind*()関数は次のインタフェースを評価するためにループを進める。ＩＰデータの放送または同報ストリームを受信するインタフェースの能力を評価することを除いて、図４に示す実施例の残余の機能は図２に示し、同図面を参照して上で説明した実施例の機能と同一である。

同様に、図５に代替的実施例を示す。これは、選択されたインタフェースにＩＰデータの放送または同報ストリームを受信する能力があるかどうかを判定するための、選択されたインタフェースをテストする追加テスト、ステップ４００、を除くと図３と同一である。冗長な説明に対する要求を避けるために、図３の説明がここに参照として組み込まれる。bind*()関数が、あるインタフェースが指示されたＩＰアドレスに対して構成されていないと判定すると、テスト２０、そのインタフェースが放送データストリームを受信することができるかどうかを判定するために評価される、ステップ４００。受信できる場合、選択されたインタフェースは、それが指示されたＩＰアドレスに対して構成されうるかどうかを判定するために評価される、ステップ２１８。しかし、選択されたインタフェースがＩＰデータの放送または同報ストリームを受信できない場合には、例えば追加のインタフェースが評価のために利用可能かどうかをテストし、ステップ２８、利用可能であれば、ステップ１８へループバックする前にカウンタを進めることにより、ステップ３０、ループが進められる。ＩＰデータの放送または同報ストリームを受信するインタフェースの能力を評価することを除いて、図５に示す実施例の残余の機能は、図３に示し同図面を参照して上で説明した実施例の機能と同一である。

上述したように、種々の実施例は従来からあった機能のすべてを保持する修正されたbind()ＡＰＩとして実施されるかもしれない。図６に、図２を参照して上で説明した追加機能２００がbind*()ＡＰＩの全機能に組み入れられた実施例を示す。この実施例において、ＩＰアドレスがbind*()呼出１０*の引数に含まれている場合、関数は図２を参照して上で説明したように進む。bind*()呼出１０*の引数が、ＩＰアドレスとしてINADDR_ANYバインド不特定（bind-any）機能を起動するINADDR_ANYまたは「０」を含む場合、テスト１４の結果は「いいえ」であり、従って関数は各インタフェースをテストしそのインタフェースがＩＰアドレスを有して構成されているかどうかを判定するために、テスト４０、ステップ３８、４０、４２、４４、４６、４８のループを実行するように進む。具体的には、カウンタは第１のインタフェースを示すかまたはポイントするために初期化されるかもしれない。次にカウント値を用いて、関数はインタフェースを選択し、ステップ３８、次に選択されたインタフェースはそのインタフェースが任意のＩＰアドレスに対して構成されているかどうかを判定するために質問される、テスト４０。選択されたインタフェースがＩＰアドレスに対して構成されている場合、そのインタフェースはバインドされ、ステップ４２、「０」の成功状態フラグが設定される、ステップ４４。選択されたインタフェースがＩＰアドレスに対して構成されないか、またはステップ４２でバインドされることに成功しないかに係わらず、例えば評価されるべき追加のインタフェースが残っているかどうかをテストし、テスト４６、残っていれば、ステップ３８へループバックする前にカウンタを進めることにより、ステップ４８、ループを進める。しかし、評価されるべきインタフェースがこれ以上無い場合（すなわち、テスト４６の結果が「いいえ」の場合）、bind*()関数は、状態フラグが「−１」のままであるかどうか、またはインタフェースの１つが任意のＩＰアドレスにバインドされた結果として「０」に設定されたかを判定するための状態フラグをテストするかもしれない、テスト３２。このテストの結果が「いいえ」（すなわち、状態フラグが「０」）の場合、関数は「０」の状態値を返し、bind*()ＡＰＩを呼出したアプリケーションへ戻る、ステップ２６。しかし、状態フラグが「−１」（すなわち、テスト３２の結果が「はい」）の場合、これはバインディング操作が成功しなかったことを示し、従って関数はbind*()ＡＰＩを呼出したアプリケーションへステップ２６で戻る前に誤り符号が誤りレジスタに提示される、ステップ３４。図６に示す修正されたbind*()関数の残余のステップは図２を参照して上で説明したステップと本質的に同じである。

同様に、図７に図３を参照して上で説明した追加機能３００がbind*()ＡＰＩの全機能に組み入れられた実施例を示す。この実施例において、ＩＰアドレスがbind*()呼出１０*引数に含まれている場合、関数は図２を参照して上で説明したように進む。bind*()呼出１０*の引数が、ＩＰアドレスに対してINADDR_ANYまたは「０」を含む場合、図６の上記ステップ３６−４８について説明したものと本質的には同じであるINADDR_ANYバインド不特定機能を起動。図７に示す修正されたbind*()機能の残余のステップは図３を参照して上で説明したステップと本質的に同じである。

同様に、図８に図２を参照して上で説明した追加機能２００および図４を参照して上で説明した選択されたインタフェースの付加的テスト４００がbind()ＡＰＩの全機能に組み入れられた実施例を示す。この実施例において、ＩＰアドレスがbind*()呼出１０*の引数に含まれている場合、関数は図２を参照して上で説明したように進む。bind*()呼出１０*の引数が、ＩＰアドレスに対してINADDR_ANYまたは「０」を含む場合、図６の上記ステップ３６−４８について説明したものと本質的には同じであるINADDR_ANYバインド不特定機能を起動。図８に示す修正されたバインド機能の残余のステップは図４を参照して上で説明したステップと本質的に同じである。

同様に、図９に、図３を参照して上で説明した追加機能３００および図５を参照して上で説明した選択されたインタフェースの付加的テスト４００がbind*()ＡＰＩの全機能に組み入れられた実施例を示す。この実施例において、ＩＰアドレスがbind*()呼出１０*の引数に含まれている場合、関数は図３を参照して上で説明したように進む。bind*()呼出の引数が、ＩＰアドレスに対してINADDR_ANYまたは「０」を含む場合、図６の上記ステップ３６−４８について説明したものと本質的には同じであるINADDR_ANYバインド不特定機能を起動。図９に示す修正されたバインド機能の残余のステップは図５を参照して上で説明したステップと本質的に同じである。

図２、４、６、および８に示す実施例に最も効果的でさらに進んだ実施例において、インタフェースは、ポリシールールに基づいて確立されるかもしれないような優先度順で質問されるかもしれない。これを達成するために、インタフェースの優先度順位一覧がインタフェースを評価する際にステップ２１４、２１６、２１８、２２４、２２６を含むループにおいて順に用いるように作成されるかもしれない。ポリシールールに従って第１のインタフェースが最高優先度を有し、最後のインタフェースが最低優先度を有するように上記優先度順の一覧を準備することにより、上述のインタフェースの構成可能性を評価する処理は、構成されおよびバインドされるインタフェースがポリシールールに従って最高優先度になることを確実にする。この優先度一覧を作成するためには、ポリシーパラメータ、ルールまたは優先度づけ基準のセットが、例えばポリシーベースのルーティングエンジンのようなインタフェース順位づけアプリケーションにとって既知である必要がある。そのようなポリシーパラメータは費用、サービス品質、標準プロトコル選好、および個々のインタフェースに関連する他の要素を含むかもしれない。このインタフェース順位づけアプリケーションは、各インタフェースに対するＡＣＬ内に格納された情報にアクセスでき、順位づけの値または基準を作成するために、ポリシーパラメータ、ルールまたは優先度づけを利用可能である。ポリシーパラメータ、ルールまたは優先度づけ基準についてＡＣＬから得たインタフェース特性のこの評価がすべてのインタフェースについて完了すると、インタフェースは順位づけの値または基準の順に配列されることができる。この実施例を実施するために、修正されたbind*()ＡＰＩは、図２を参照して上で説明した新しい機能２００においてインタフェース全体を通じてループを実行するために、順位一覧を用いる必要がある。

さらに別の代替的実施例において、図２、４、６および８のステップ２１６で、あるインタフェースが評価のために選択される際、ＡＰＩから得られるようなインタフェース特性にポリシーベースのルールが適用されるかもしれない。同様に、追加のポリシーベースのルールテストは、選択されたインタフェースが指示されたＩＰアドレスに対して構成可能であるかを判定するためのテストに先行して実行されるかもしれない。例えば、図４、５、８、および９を参照して上で説明した実施例は、あるインタフェースが、選択されたインタフェースの構成可能性のテストに先立ってＩＰデータの放送および同報ＩＰストリームを受信可能であるかを評価することにより、１つの形式のポリシーベースのテストを実行する。上で説明したように、このポリシーベースのテストが満足されない場合、そのインタフェースは構成可能と評価されない。この概念はさらに費用、サービス品質、セキュリティ、およびＳＰ選好のような他のポリシーパラメータに適用できる。

上述した種々の実施例は、携帯電話または無線ネットワーク接続を介してインターネット放送またはインターネットデータストリームを受信するための回路およびソフトウェアで構成された移動機器において実施されるかもしれない。図１０にそのような移動機器１００の実施例を示す。これは携帯電話、マルチメディアインターネットが可能な携帯電話、携帯情報端末、および／または、無線電子メール受信機のいずれかであるかもしれない。そのような移動機器１００はメモリー１０４およびディスプレイ１０６と接続されたプロセッサ１０２を含むかもしれない。また、移動機器１００は多くのデータ入出力インタフェース、例えば携帯電話データ受信機、有線（例えばファイアワイア）データリンク、ブルートゥース無線データリンク、および赤外線データリンクを含むかもしれない。携帯電話データ受信機は無線ネットワーク送信機／受信機（図示せず）から電磁信号を受信するためのアンテナ１２０、およびアンテナ１２０に接続された無線信号を受信し、その信号を、プロセッサ１０２に中継されるディジタルデータに変換する無線送受信機１２２を含むかもしれない。同様に、ブルートゥースまたは同様のローカル無線データリンクは、受信無線信号をプロセッサ１０２に中継されるディジタルデータに変換するブルートゥース送受信機１２４に接続されたアンテナ１２０（または分離して示していない別のアンテナ）を含むかもしれない。データは、ファイアワイア、ＵＳＢ、シリアル（例えばＲＳ−２３２）、またはイーサネット（登録商標）データリンクのような有線データリンクを用いて移動機器１００へ、および移動機器１００から送信されるかもしれない。例えば、データは、コネクタ１３０から受信したデータをプロセッサ１０２に中継されるディジタルデータに変換するファイアワイアモデム回路１３２に接続されるファイアワイアコネクタ１３０を通じて送信されるかもしれない。当業者には周知のとおり、他の有線データリンクはその特定のデータリンクに適した同様の回路を含むだろう。また、データは、移動機器１００からおよび移動機器１００へ赤外線（ＩＲ）データリンクによって例えばＩＲ送信機／受信機１４０から受信したデータをプロセッサ１０２に中継されるディジタルデータに変換するＩＲデータリンクモデム回路１４２に接続されたＩＲデータ送信機／受信機１４０を通じて、送信されるかもしれない。

携帯電話データ受信装置１２０、１２２、有線データリンク１３０、１３２、ブルートゥース無線データリンク１２０、１２４、およびＩＲデータリンク１４０、１４２の各々は、プロセッサが受信データにアクセスするかもしれないインタフェースである。さらに、他のモジュールおよびコプロセッサ間でデータを転送するために、移動機器１００の中で他のインタフェースが実施されるかもしれない。したがって、ＩＰデータの放送または同報ストリームを受信するために、移動機器１００はこれらのインタフェースの１つを放送または同報データストリームのＩＰアドレスにバインドしなければならない。このことは、上で説明した実施例の方法の１つを実行するプロセッサ１０２によって、例えば方法の１つを実施するように構成されたソフトウェア命令を実行することによって、成されるかもしれない。そのようなソフトウェア命令はＡＰＩとしてまたは実施例の方法を実施するコンパイルされたソフトウェアとしてメモリー１０４に格納されるかもしれない。

プロセッサ１０２は汎用プロセッサ、ディジタル信号プロセッサ（ＤＳＰ）、特定用途向集積回路（ＡＳＩＣ）、プログラマブルゲートアレイ（ＦＰＧＡ）、もしくは他のプログラム可能論理回路、個別ゲートもしくはトランジスタ論理、個別ハードウェア部品、またはここに説明した機能を実行するように設計されたそれらの任意の組合せであるかもしれない。汎用プロセッサは、マイクロプロセッサであるかもしれないが、代替的にはプロセッサは、任意の通常のプロセッサ、制御器、マイクロ制御器または状態機械であるかもしれない。プロセッサはまた、計算機器の組合せ、例えばＤＳＰとマイクロプロセッサ、複数のマイクロプロセッサ、ＤＳＰコアと連係した１つ以上のマイクロプロセッサ、または他のそのような構成として実施されるかもしれない。

種々の実施例の修正されたbind*()ＡＰＩを実施するために、bind()ＡＰＩの機能を提供する基本的なソフトウェアは、ここに説明したものと同様なソフトウェアまたは同様な機能を提供するソフトウェアを加えるために修正される必要がある。さらに、アプリケーション開発者へ修正されたbind()ＡＰＩの新しい機能および挙動を通知するために、ＡＰＩが更新される必要があるだろう。

図２−９および上で説明した種々の実施例には、インタフェースが所望のＩＰアドレスに対して構成されていない場合であっても、１つのＡＰＩ呼出だけで、bind*()ＡＰＩが適切なインタフェースを選択し、それを構成し、さらに所望のＩＰアドレスとバインドを行うだろう、という利点がある。従って、そのＩＰのための特別のインタフェースを構成するための付加的なアプリケーションの複雑さは要求されない。さらに、インタフェース選択、構成およびバインディングがただ一つのＡＰＩ呼出で達成される故、下層のソフトウェアがbind*()ＡＰＩを呼出すことができる。このことにより、データストリームの入力を識別し、それを復調するために下層（すなわち、アプリケーション層の下位のソフトウェア層）にとって必要な情報を送ることにより、新しいまたは修正されたbind*()ＡＰＩが、下層でインターネット放送または同報ストリームの構成および復調を始動するために用いられることが可能となる。このことは、また下層ソフトウェアが、ＩＰデータストリームを受信するためのインタフェースを構成することを可能とする。したがって、新しいまたは修正されたbind*()ＡＰＩは、アプリケーション開発者の作業を簡素化しながら、ＩＰアドレスへのインタフェースを選択し、識別し、構成し、およびバインドするための付加的ＡＰＩ呼出に対する要求を排除する。

種々の実施例は、放送または同報ＩＰコンテンツを受信するためのアプリケーションの場面において特に有利である。これは、そのような状況においては他の形式のインターネットアプリケーションの場合のような逆方向の伝達がないと予想されるからである。したがって、種々の実施例の修正されたbind*()ＡＰＩを実施することによって操作の結合と中止を当然に要求するＩＰアドレスとの結合に関連する複雑さを、回避することができる。

上述の実施例のイベントを実施するために用いられるハードウェアは、本方法の上記イベントに対応するステップを実行するための命令セットを実行するように構成された処理構成要素およびメモリー構成要素であるかもしれない。あるいはまた、いくつかのイベントは所与の関数に特有な回路によって実行されるかもしれない。

当業者は、ここに開示された実施例に関連して説明された種々の例示的論理ブロック、モジュール、回路およびアルゴリズムのステップは、電子的ハードウェア、計算機ソフトウェア、またはその双方の組合せとして実施されるかもしれないことを認識するだろう。ハードウェアとソフトウェアのこの互換性を明確に示すために、ここまで種々の例示的構成要素、ブロック、モジュール、回路、およびステップは、それらの機能の見地から一般的に説明してきた。そのような機能がハードウェアまたはソフトウェアとして実施されるかどうかは、全体のシステムに課せられた特定の用途および設計制約に依存する。当業者は、説明した機能を各特定の用途に対して異なる方法で実施するかもしれないが、そのような実施の決定は本発明の範囲からの逸脱を引き起こすと解釈されるべきではない。

ここに開示された実施例に関して説明された方法またはアルゴリズムのステップは、直接ハードウェアで、プロセッサで実行されるソフトウェアモジュールで、またはその２つの組合せで具体化されるかもしれない。ソフトウェアモジュールはＲＡＭメモリー、フラッシュメモリー、ＲＯＭメモリー、ＥＰＲＯＭメモリー、ＥＥＰＲＯＭメモリー、レジスタ、ハードディスク、可搬形ディスク、ＣＤ−ＲＯＭ、または当業者に既知の任意の他の形式の記憶媒体のいずれかであるかもしれないプロセッサ可読メモリー内にもあるかもしれない。代表的記憶媒体は、プロセッサが情報を記憶媒体から読み出しおよび情報を記憶媒体に書き込むことができるようにプロセッサに接続される。代替的には、記憶媒体はプロセッサの構成部品であるかもしれない。プロセッサおよび記憶媒体はＡＳＩＣ内にあるかもしれない。ＡＳＩＣはユーザ端末内にあるかもしれない。代替的に、プロセッサおよび記憶媒体は個別部品としてユーザ端末内にあるかもしれない。

種々の実施例のこれまでの説明は、当業者が本発明を製造しまたは使用することを可能にするように提供されている。これらの実施例への種々の変形は当業者に容易に明らかになるだろう。また、ここに定義した一般的原理は本発明の精神または範囲から逸脱することなく他の実施例に適用されるかもしれない。したがって、本発明は、ここに示した実施例に限定することを意図されていず、むしろ、請求範囲はここに開示した原理および新規な特徴と矛盾しない最も広い範囲に一致されるべきである。

Claims

インターネットを介してデータを受信するために複数のローカルインタフェースの１つを１つのＩＰアドレスにバインドするための方法であって、
複数のローカルインタフェースの１つが前記ＩＰアドレスに対して構成されているかどうかを判定することと、
複数のローカルインタフェースの前記１つが前記ＩＰアドレスに対して構成されていると判定される場合、複数のローカルインタフェースの前記１つを前記ＩＰアドレスにバインドすることと、
複数のローカルインタフェースの前記１つが前記ＩＰアドレスに対して構成されているかどうかを判定するステップを、複数のインタフェースの少なくとも１つが前記ＩＰアドレスにバインドされるかまたはすべての複数のローカルインタフェースが評価され終わるまで、反復することと、
複数のローカルインタフェースのいずれも前記ＩＰアドレスにバインドされない場合、複数のローカルインタフェースの１つを選択することと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうるかどうかを判定することと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうると判定される場合、複数のローカルインタフェースの前記選択された１つを前記ＩＰアドレスに対して構成すること、および
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうると判定される場合、複数のローカルインタフェースの前記選択された１つを前記ＩＰアドレスにバインドすることと、
複数のローカルインタフェースの１つを選択するステップと、複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうるかどうかを判定するステップとを、複数のインタフェースの少なくとも１つが前記ＩＰアドレスにバインドされるかまたはすべてのローカルインタフェースが評価され終わるまで、反復することと、
複数のローカルインタフェースのいずれも前記ＩＰアドレスにバインドされない場合、バインドに失敗したことを示すこととを含む方法。
複数のローカルインタフェースの選択された１つが、インターネットデータの放送または同報ストリームを受信できるかどうかを判定することをさらに含み、複数のローカルインタフェースの前記選択された１つがＩＰアドレスに対して構成されうるかどうかを判定することが、複数のローカルインタフェースの前記選択された１つがインターネットデータの放送または同報ストリームを受信できると判定された場合にのみ成される、請求項１に記載の方法。
複数のローカルインタフェースの１つを選択するステップが、優先度順に従って複数のローカルインタフェースから選択することを含む、請求項１に記載の方法。
複数のローカルインタフェースの１つを選択するステップが、複数のローカルインタフェースの各々１つの特性に適用されるポリシールールに基づく優先度順に従って複数のローカルインタフェースから選択することを含む、請求項１に記載の方法。
インターネットを介してデータを受信するために複数のローカルインタフェースの１つを１つのＩＰアドレスにバインドするための方法であって、
複数のローカルインタフェースの１つを選択することと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されているかどうかを判定することと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されていないと判定される場合、複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうるかどうかを判定することと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうると判定される場合、複数のローカルインタフェースの前記選択された１つを前記ＩＰアドレスに対して構成することと、
前記選択されたインタフェースが前記ＩＰアドレスに対して構成されている場合、複数のローカルインタフェースの前記選択された１つを前記ＩＰアドレスにバインドすることと、
複数のインタフェースの少なくとも１つが前記ＩＰアドレスにバインドされるかまたは複数のローカルインタフェースの各々が評価され終わるまで、上記複数のステップを反復することと、
複数のローカルインタフェースのいずれも前記ＩＰアドレスにバインドされない場合、バインドに失敗したことを示すこととを含む方法。
複数のローカルインタフェースの選択された１つが、インターネットデータの放送または同報ストリームを受信できるかどうかを判定することをさらに含み、複数のローカルインタフェースの前記選択された１つがＩＰアドレスに対して構成されうるかどうかを判定することが、複数のローカルインタフェースの前記選択された１つがインターネットデータの放送または同報ストリームを受信できると判定された場合にのみ成される、請求項５に記載の方法。
複数のローカルインタフェースの選択された１つがＩＰアドレスに対して構成されうるかどうかを評価するステップと、前記ＩＰアドレスに対する複数のローカルインタフェースの前記選択された１つを構成するステップとが、複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されていない場合にのみ、実行される、請求項５に記載の方法。
アプリケーションプログラミングインタフェース関数のための、プロセッサが実行可能なソフトウェア命令を格納したプロセッサ可読メモリーであって、ソフトウェア命令が、
複数のローカルインタフェースの１つがＩＰアドレスに対して構成されているかどうかを判定するステップと、
複数のローカルインタフェースの前記１つが前記ＩＰアドレスに対して構成されていると判定される場合、複数のローカルインタフェースの前記１つを前記ＩＰアドレスにバインドするステップと、
複数のローカルインタフェースの１つが前記ＩＰアドレスに対して構成されているかどうかを判定するステップを、複数のインタフェースの少なくとも１つが前記ＩＰアドレスにバインドされるかまたは複数のローカルインタフェースの各々が評価され終わるまで、反復するステップと、
複数のローカルインタフェースのいずれも前記ＩＰアドレスにバインドされない場合、複数のローカルインタフェースの１つを選択するステップと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうるかどうかを判定するステップと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうると判定される場合、複数のローカルインタフェースの前記選択された１つを前記ＩＰアドレスに対して構成するステップと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されている場合、複数のローカルインタフェースの前記選択された１つを前記ＩＰアドレスにバインドするステップと、
複数のローカルインタフェースの１つを選択するステップと、複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうるかどうかを判定するステップとを、複数のインタフェースの少なくとも１つが前記ＩＰアドレスにバインドされるかまたは複数のローカルインタフェースの各々が評価され終わるまで、反復するステップと、
複数のローカルインタフェースのいずれも前記ＩＰアドレスにバインドされない場合、バインドに失敗したことを示すステップとを含む、プロセッサ可読メモリー。
ソフトウェア命令が、複数のローカルインタフェースの選択された１つがインターネットデータの放送または同報ストリームを受信できるかどうかを評価するステップをさらに含み、
複数のローカルインタフェースの前記選択された１つがＩＰアドレスに対して構成されうるかどうかを評価するステップが、複数のローカルインタフェースの前記選択された１つがインターネットデータの放送または同報ストリームを受信できると評価された場合にのみ成される、請求項８に記載のプロセッサ可読メモリー。
ソフトウェア命令が、複数のローカルインタフェースの１つを選択するステップが優先度順に従って複数のローカルインタフェースから選択することを含むように構成された、請求項８に記載のプロセッサ可読メモリー。
ソフトウェア命令が、複数のローカルインタフェースの１つを選択するステップが複数のローカルインタフェースの各々の特性に適用されるポリシールールに基づく優先度順に従って複数のローカルインタフェースから選択することを含むように構成された、請求項８に記載のプロセッサ可読メモリー。
アプリケーションプログラミングインタフェース機能のための、プロセッサが実行可能なソフトウェアを格納したプロセッサ可読メモリーであって、ソフトウェア命令が、
複数のローカルインタフェースの１つを選択するステップと、
複数のローカルインタフェースの前記選択された１つがＩＰアドレスに対して構成されているかどうかを評価するステップと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されていないと判定される場合、複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうるかどうかを評価するステップと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうると判定される場合、複数のローカルインタフェースの前記選択された１つを前記ＩＰアドレスに対して構成するステップと、
前記選択された複数のローカルインタフェースの１つが前記ＩＰアドレスに対して構成されている場合、複数のローカルインタフェースの前記選択された１つを前記ＩＰアドレスにバインドするステップと、
複数のインタフェースの少なくとも１つが前記ＩＰアドレスにバインドされるかまたは複数のローカルインタフェースの各々が評価され終わるまで、上記ステップを反復するステップと、
複数のローカルインタフェースのいずれも前記ＩＰアドレスにバインドされない場合、バインドに失敗したことを示すステップとを含む、プロセッサ可読メモリー。
ソフトウェア命令が、複数のローカルインタフェースの選択された１つがインターネットデータの放送または同報ストリームを受信できるかどうかを判定するステップをさらに含み、ソフトウェア命令は、複数のローカルインタフェースの前記選択された１つがＩＰアドレスに対して構成されうるかどうかを判定するステップが、複数のローカルインタフェースの１つがインターネットデータの放送または同報ストリームを受信できると判定された場合にのみ成されるように構成された、請求項１２に記載のプロセッサ可読メモリー。
ソフトウェア命令が、複数のローカルインタフェースの１つを選択するステップと、複数のローカルインタフェースの前記選択された１つがＩＰアドレスに対して構成されうるかどうかを判定するステップと、複数のローカルインタフェースの前記選択された１つを前記ＩＰアドレスに対して構成するステップとが、複数のローカルインタフェースの前記選択された１つがＩＰアドレスに対して構成されない場合にのみ、実行されるように構成された、請求項１２に記載のプロセッサ可読メモリー。
プロセッサと、
前記プロセッサに接続されたメモリーであって、前記プロセッサに、
複数のローカルインタフェースの１つがＩＰアドレスに対して構成されているかどうかを判定するステップと、
複数のローカルインタフェースの前記１つが前記ＩＰアドレスに対して構成されている場合、複数のローカルインタフェースの前記１つを前記ＩＰアドレスにバインドするステップと、
複数のローカルインタフェースの前記１つが前記ＩＰアドレスに対して構成されているかどうかを判定するステップを、複数のインタフェースの少なくとも１つが前記ＩＰアドレスにバインドされるかまたは複数のローカルインタフェースの各々が評価され終わるまで、反復するステップと、
複数のローカルインタフェースのいずれもＩＰアドレスにバインドされない場合、複数のローカルインタフェースの１つを選択するステップと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうるかどうかを判定するステップと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうると判定される場合、複数のローカルインタフェースの前記選択された１つを前記ＩＰアドレスに対して構成するステップと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されていると判定される場合、前記複数のローカルインタフェースの前記選択された１つを前記ＩＰアドレスにバインドするステップと、
複数のローカルインタフェースの１つを選択するステップと、複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうるかどうかを判定するステップとを、複数のインタフェースの少なくとも１つが前記ＩＰアドレスにバインドされるかまたは複数のローカルインタフェースの各選択された１つが評価され終わるまで、反復するステップと、
複数のローカルインタフェースのいずれも前記ＩＰアドレスにバインドされない場合、バインドに失敗したことを示すステップとを実行させるように構成された、ソフトウェア命令を格納するメモリーとを含む移動機器。
ソフトウェア命令が、プロセッサに、複数のローカルインタフェースの選択された１つがインターネットデータの放送または同報ストリームを受信できるかどうかを判定するステップを実行させるようにさらに構成され、
ソフトウェア命令は、複数のローカルインタフェースの前記選択された１つがＩＰアドレスに対して構成されうるかどうかを判定するステップが、複数のローカルインタフェースの前記選択された１つがインターネットデータの放送または同報ストリームを受信できると判定された場合にのみ成されるように、さらに構成された、請求項１５に記載の移動機器。
ソフトウェア命令が、プロセッサに、優先度順に従って複数のローカルインタフェースの１つを選択させるようにさらに構成された、請求項１５に記載の移動機器。
ソフトウェア命令が、プロセッサに、複数のローカルインタフェースの各選択された１つの特性に適用されるポリシールールに基づく優先度順に従って複数のローカルインタフェースの１つを選択させるようにさらに構成された、請求項１５に記載の移動機器。
プロセッサと、
前記プロセッサに接続されたメモリーであって、前記プロセッサに、
複数のローカルインタフェースの１つを選択するステップと、
複数のローカルインタフェースの前記選択された１つがＩＰアドレスに対して構成されているかどうかを判定するステップと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されていないと判定される場合、複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうるかどうかを判定するステップと、
複数のローカルインタフェースの前記選択された１つが前記ＩＰアドレスに対して構成されうると判定される場合、複数のローカルインタフェースの前記選択された１つを前記ＩＰアドレスに対して構成するステップと、
前記選択されたインタフェースが前記ＩＰアドレスに対して構成されている場合、複数のローカルインタフェースの前記選択された１つを前記ＩＰアドレスにバインドするステップと、
複数のインタフェースの少なくとも１つが前記ＩＰアドレスにバインドされるかまたは複数のローカルインタフェースの各々が評価され終わるまで、上記複数のステップを反復するステップと、
複数のローカルインタフェースのいずれも前記ＩＰアドレスにバインドされない場合、バインドに失敗したことを示すステップとを実行させるように構成されたソフトウェア命令を格納するメモリー、とを含む移動機器。
ソフトウェア命令が、プロセッサに複数のローカルインタフェースの選択された１つがインターネットデータの放送または同報ストリームを受信できるかどうかを判定するステップを実行させるようにさらに構成され、
ソフトウェア命令は、複数のローカルインタフェースの１つを選択するステップと、複数のローカルインタフェースの前記選択された１つがインターネットデータの放送または同報ストリームを受信できると判定された場合にのみ複数のローカルインタフェースの前記選択された１つがＩＰアドレスに対して構成されうるかどうかを判定するステップとが、達成されるようにさらに構成された、請求項１９に記載の移動機器。
ソフトウェア命令は、プロセッサに、複数のローカルインタフェースの１つを選択するステップと、複数のローカルインタフェースの前記選択された１つが、インターネットデータがＩＰアドレスに対して構成されていない場合にのみ、複数のローカルインタフェースの前記選択された１つがＩＰアドレスに対して構成されうるかどうかを判定するステップが達成されるように実行させるようにさらに構成された、請求項１９に記載の移動機器。