知財求人 - 知財ポータルサイト「IP Force」
▶ エルティーエヌ グローバル コミュニケーションズ，インコーポレイテッドの特許一覧
特表2024-533930マルチメディア信号を用いるプログラムを作成するための論理エンティティを用いるスケーラブルシステム及び方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-09-18
(54)【発明の名称】マルチメディア信号を用いるプログラムを作成するための論理エンティティを用いるスケーラブルシステム及び方法
(51)【国際特許分類】
H04N 21/2668 20110101AFI20240910BHJP
H04N 21/241 20110101ALI20240910BHJP
H04L 45/00 20220101ALI20240910BHJP
【ＦＩ】
H04N21/2668
H04N21/241
H04L45/00
【審査請求】有
【予備審査請求】有
(21)【出願番号】P 2023581061
(86)(22)【出願日】2021-08-16
(85)【翻訳文提出日】2024-02-28
(86)【国際出願番号】 US2021030421
(87)【国際公開番号】W WO2023022697
(87)【国際公開日】2023-02-23
(81)【指定国・地域】
(71)【出願人】
【識別番号】524004216
【氏名又は名称】エルティーエヌ グローバル コミュニケーションズ，インコーポレイテッド
(74)【代理人】
【識別番号】100079108
【弁理士】
【氏名又は名称】稲葉 良幸
(74)【代理人】
【識別番号】100109346
【弁理士】
【氏名又は名称】大貫 敏史
(74)【代理人】
【識別番号】100117189
【弁理士】
【氏名又は名称】江口 昭彦
(74)【代理人】
【識別番号】100134120
【弁理士】
【氏名又は名称】内藤 和彦
(72)【発明者】
【氏名】イーバート，ジョア ディエゴ
(72)【発明者】
【氏名】ヤコビ，アンドレアス
(72)【発明者】
【氏名】カーン，マリク
【テーマコード（参考）】
5C164
5K030
【Ｆターム（参考）】
5C164FA06
5C164SB21S
5C164SB51P
5C164SC05P
5K030HB02
5K030KA05
5K030LB05
(57)【要約】
【課題】 柔軟なシステム及び方法を提供することである。
【解決手段】 本発明に従って、コンピューティングシステムの１つ以上のサーバでアプリケーションソフトウェアを実行することにより、１つ以上のソースから通信チャネルを介して受信されたマルチメディア信号等の信号を用いるプログラムがコンピューティングシステムで作成される。サーバのうち少なくとも１つは、定義された論理エンティティを処理する１つ以上のプロセッサを有する。ソースから通信チャネルを介してサーバで、プログラムの作成に用いられる信号を受信する。信号のソースに関連付けられた属性を有する入力論理エンティティを定義して、入力論理エンティティが信号を受容又は拒否するための論理表現を含むユーザ定義述語に応答するようにする。また、受容された信号を識別するストリーム論理エンティティと、ストリーム論理エンティティ及び宛先の間で接続を確立するルーティング論理エンティティと、を定義する。ルーティングルールに基づいて、受容された信号を宛先にルーティングする。
【選択図】 図３
【解決手段】 本発明に従って、コンピューティングシステムの１つ以上のサーバでアプリケーションソフトウェアを実行することにより、１つ以上のソースから通信チャネルを介して受信されたマルチメディア信号等の信号を用いるプログラムがコンピューティングシステムで作成される。サーバのうち少なくとも１つは、定義された論理エンティティを処理する１つ以上のプロセッサを有する。ソースから通信チャネルを介してサーバで、プログラムの作成に用いられる信号を受信する。信号のソースに関連付けられた属性を有する入力論理エンティティを定義して、入力論理エンティティが信号を受容又は拒否するための論理表現を含むユーザ定義述語に応答するようにする。また、受容された信号を識別するストリーム論理エンティティと、ストリーム論理エンティティ及び宛先の間で接続を確立するルーティング論理エンティティと、を定義する。ルーティングルールに基づいて、受容された信号を宛先にルーティングする。
【選択図】 図３
【特許請求の範囲】
【請求項1】
１つ以上のソースから通信チャネルを介して受信された信号を用いるプログラムを作成するためのコンピューティングシステムにおいて実行される方法であって、ａ）前記コンピューティングシステムの１つ以上のサーバでアプリケーションソフトウェアを実行するステップであって、前記１つ以上のサーバのうち少なくとも１つは、定義された論理エンティティを処理する１つ以上のプロセッサを有する、ステップと、
ｂ）ソースから通信チャネルを介してサーバでプログラムの作成に用いられる信号を受信するステップと、
ｃ）前記信号の前記ソースに関連付けられた属性を有する入力論理エンティティを定義するステップであって、前記入力論理エンティティは、前記信号を受容又は拒否するための論理表現を含むユーザ定義述語に応答する、ステップと、
ｄ）受容された信号を識別するストリーム論理エンティティを定義するステップと、
ｅ）前記ストリーム論理エンティティと宛先との間で接続を確立するルーティング論理エンティティを定義するステップと、
ｆ）ルーティングルールに基づいて前記受容された信号を前記宛先にルーティングするステップと、
を含む方法。
【請求項2】
前記ストリーム論理エンティティを前記宛先に関連付ける出力論理エンティティを定義するステップを更に含む、請求項１に記載の方法。
【請求項3】
前記出力論理エンティティは、前記受容された信号を前記宛先にマッピングするために評価されるユーザ定義プログラム変換ルールに従って前記ストリーム論理エンティティを変換する、請求項２に記載の方法。
【請求項4】
前記信号はＭＰＥＧ信号であり、前記ユーザ定義プログラム変換ルールはプログラム特定情報（ＰＳＩ）に基づく、請求項３に記載の方法。
【請求項5】
前記ストリーム論理エンティティはパケット化エレメンタリストリーム（ＰＥＳ）に関連付けられている、請求項４に記載の方法。
【請求項6】
前記ＰＳＩはプログラムマッピングテーブル（ＰＭＴ）を含み、前記ストリーム論理エンティティはＰＭＴに関連付けられている、請求項５に記載の方法。
【請求項7】
前記ＭＰＥＧ信号のパケットの到着間時間（ＩＡＴ）はサーバで記録され、一定のビットレートを達成するため前記出力論理エンティティによって用いられる、請求項４に記載の方法。
【請求項8】
前記ルーティングルールは前記入力論理エンティティに関連付けられたユーザ定義の論理ルールであり、前記信号が前記入力論理エンティティに与えられた場合にユーザ定義の論理ルールが評価される、請求項１に記載の方法。
【請求項9】
前記ユーザ定義述語は、時刻、地理領域、位置、又はＩＰアドレスに基づく、請求項１に記載の方法。
【請求項10】
前記入力論理エンティティはユーザによって永続論理エンティティとして定義される、請求項１に記載の方法。
【請求項11】
前記入力論理エンティティはグラフィカルユーザインタフェース又はアプリケーションプログラミングインタフェース（ＡＰＩ）を介して前記ユーザによって構成される、請求項１０に記載の方法。
【請求項12】
前記ストリーム論理エンティティは、局所接続を生成するセッションタグに関連付けられている、請求項１に記載の方法。
【請求項13】
前記ストリーム論理エンティティは前記信号の所有者又は発行者の一意の識別（ＩＤ）に関連付けられている、請求項１に記載の方法。
【請求項14】
信頼度に基づいて前記信号の特徴を認識し、前記認識した特徴を前記信号に関連付けられたメタデータとして用いることを更に含む、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、一般に、プログラムで用いられるマルチメディア（例えばオーディオビジュアル信号）のフィルタリング及びルーティングを必要とするプログラムを作成するためのシステム及び方法に関する。
【背景技術】
【0002】
プログラムを作成する際、複数のソースで生じたストリームは、エンリッチメントの後、最終的に消費者へ提示される。本明細書で用いられる場合、プログラムは、任意の観客、ユーザ、視聴者、加入者等に消費されるため用いられるいずれか１つの又は組み合わせたストリームコンテンツとすることができる。ストリームマルチメディアコンテンツはビデオデータとオーディオデータの双方を含むが、このようなストリーミングは多くの場合、ストリームがビデオデータとオーディオデータの双方を送ることを理解した上で、ビデオストリーミング又はストリーミングと呼ばれる。本明細書は、マルチメディアストリーミング、ビデオストリーミング、及びストリーミングを同じ意味で示す。
【0003】
ストリーミングによるプログラムのライブ作成、後処理、及び配信で用いられるシステムは既知である。また、インターネット（又は他のネットワーク）を介して消費者にビデオ／オーディオデータを配信するため用いられるストリーミングサービスも既知である。典型的に、これらのサービスは、プログラムを複数のセグメントに分割し、各セグメントをエンコードし、エンコードしたセグメントを多種多様なトランスポートプロトコルを介してクライアントデバイスにトランスポートするメディアサーバを使用する。クライアントデバイスは、トランスポートされたセグメントを受信し、セグメントをデコードし、デコードしたセグメントを適切なフォーマットでマルチメディアストリームの視聴者を含むクライアントに提示する。ビデオ及びオーディオコーデックフォーマットは、デジタルビデオ及びオーディオの生成及び再生の双方を行うために用いられる技術を表す。各フォーマットは、どのようにビデオとオーディオを組み合わせるかを規定する。時としてビデオエンコーディングと呼ばれるビデオトランスコーディングは、例えば映画データファイル用の、あるデジタルエンコーディングフォーマットから別のものへの変換である。ビデオトランスコーディングは、デジタルビデオの３つの要素、すなわちファイルフォーマット、ビデオ、及びオーディオを同時に翻訳することを含む。ビデオエンジンは、高解像度（ＨＤ：Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）記録、再生、及び編集をサポートするために用いられる基礎コードである。
【0004】
ビデオオンデマンド（ＶＯＤ：ｖｉｄｅｏ ｏｎ ｄｅｍａｎｄ）は、加入者へ送られるストリームの所有者（ｏｗｎｅｒ）又は発行者（ｐｕｂｌｉｓｈｅｒ）であるＮｅｔＦｌｉｘやＡｐｐｌｅ等の企業によって採用されている既知の配信サービスである。ＶＯＤによって、そのような加入者は、固定の放送スケジュールの制約なしでマルチメディアストリームにアクセスすることができる。また、競技場、コンサートホール、ＴＶスタジオ等の会場で発生したコンテンツがインターネットを用いてリアルタイムで視聴者に送信される公共又は民間のプログラムのライブストリーミングも既知である。インターネットプロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いるライブストリーミング展開では、作成用パケット化ライブストリームをルーティングした後、作成されたストリームを視聴者へ配信することが知られている。このような作成は、ストリームのエンリッチメント、変更、修正、又はストリームタイプの限定を行うために用いられる情報の挿入を含むことができ、例えば広告や字幕等を挿入することを含み得る。
【0005】
ライブストリーミングは、例えば、Ａｍｉｒ等に対する「Ｓｙｓｔｅｍ ａｎｄ ｍｅｔｈｏｄ ｔｈａｔ ｒｏｕｔｅｓ ｆｌｏｗｓ ｖｉａ ｍｕｌｔｉｃａｓｔ ｆｌｏｗ ｔｒａｎｓｐｏｒｔ ｆｏｒ ｇｒｏｕｐｓ」と題する米国特許第８，５９９，８５１号、Ａｍｉｒ等に対する「Ｓｙｓｔｅｍ ａｎｄ ｍｅｔｈｏｄ ｆｏｒ ｒｅｃｏｖｅｒｙ ｏｆ ｐａｃｋｅｔｓ ｉｎ ｏｖｅｒｌａｙ ｎｅｔｗｏｒｋｓ」と題する米国特許第８，４３７，２６７号、Ａｍｉｒ等に対する「Ｓｃａｌａｂｌｅ ｆｌｏｗ ｔｒａｎｓｐｏｒｔ ａｎｄ ｄｅｌｉｖｅｒｙ ｎｅｔｗｏｒｋ ａｎｄ ａｓｓｏｃｉａｔｅｄ ｍｅｔｈｏｄｓ ａｎｄ ｓｙｓｔｅｍｓ」と題する米国特許第８，６１９，７７５号、Ａｍｉｒ等に対する「Ｓｙｓｔｅｍ ａｎｄ ｍｅｔｈｏｄ ｔｈａｔ ｒｏｕｔｅｓ ｆｌｏｗｓ ｖｉａ ｍｕｌｔｉｃａｓｔ ｆｌｏｗ ｔｒａｎｓｐｏｒｔ ｆｏｒ ｇｒｏｕｐｓ」と題する米国特許第９，１０６，５６９号、及び、Ａｍｉｒ等に対する「Ｍｅｔｈｏｄ ｆｏｒ ｄｅｌｉｖｅｒｙ ｏｆ ｄｅａｄｌｉｎｅ－ｄｒｉｖｅｎ ｃｏｎｔｅｎｔ ｆｌｏｗｓ ｏｖｅｒ ａ ｆｌｏｗ ｔｒａｎｓｐｏｒｔ ｓｙｓｔｅｍ ｔｈａｔ ｉｎｔｅｒｆａｃｅｓ ｗｉｔｈ ａ ｆｌｏｗ ｄｅｌｉｖｅｒｙ ｓｙｓｔｅｍ ｖｉａ ａ ｓｅｌｅｃｔｅｄ ｇａｔｅｗａｙ」と題する米国特許第８，１８１，２１０号に開示されているシステム及び方法を用いてインターネットを介して実施することができる。本出願の譲受人であるＬＴＮ Ｇｌｏｂａｌ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，Ｉｎｃ．（メリーランド州コロンビア）によって所有されるこれらの特許は、援用により本願に含まれる。
【0006】
２つのノード間でパケットが送信される場合、それらは、帯域幅変動やパケット損失のようなストリーミング品質を低下させる多くのトランスポート障害に遭遇する。品質を改善するため、様々なトランスポートプロトコルが開発されている。例えばＳＲＴは、インターネットのようなノイズの多いネットワークを介して低遅延で高品質ストリームを配信するトランスポートプロトコルである。このプロトコルは、リアルタイムネットワーク条件を適応させ、パケット損失を最小限に抑え、より良い視聴経験を生成することによって、予測できないネットワークを介したストリームのトランスポートを最適化する。
【0007】
ハイパーテキスト転送プロトコル（ＨＴＴＰ：Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）ライブストリーミング（ＨＬＳ：ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ）は、クライアントのデバイスで実行されるウェブブラウザを用いて実施するためＡｐｐｌｅが開発したＨＴＴＰベースのアダプティブビットレートストリーミング通信プロトコルである。例えば、クライアントがハイパーリンクのクリック等によってストリームを要求した場合、ブラウザは、要求されたストリームの要求メッセージをＨＴＴＰサーバに送信する。サーバは要求を受信し、ストリームと共に応答メッセージをブラウザに送信する。しかしながら、ＨＴＴＰサーバはクライアントに関する情報を何も維持しないので、クライアントが再び同じストリームを求めた場合、サーバはストリームを再送信する。このため、ＨＴＴＰはステートレスプロトコルと呼ばれる。ＨＴＴＰは、非永続すなわち揮発性の接続と永続接続の双方を用いることができる。揮発性接続は、ＨＴＴＰサーバが要求されたストリームをクライアントへ送った後に閉じる接続である。言い換えると、この接続は、１つの要求と１つの応答のために用いられる。永続接続では、ＨＴＴＰサーバは応答を送信した後に接続を開いたままにするので、同じクライアントとサーバとの間でその後の要求及び応答を交換することができる。サーバが接続を閉じるのは、特定の構成可能な時間量にわたって接続が使用されない場合のみである。ＨＬＳは、ストリーム全体を小さいＨＴＴＰベースのファイルダウンロードのシーケンスに分割することによって機能する。各ダウンロードは、全体として潜在的に制限のないストリームの１つの短いチャンクを含む。
【0008】
リアルタイムメッセージングプロトコル（ＲＴＭＰ：Ｒｅａｌ－Ｔｉｍｅ Ｍｅｓｓａｇｉｎｇ Ｐｒｏｔｏｃｏｌ）は、永続接続を維持すると共に低遅延通信を可能とするＴＣＰベースのプロトコルである。ストリームを円滑に配信し、できる限り多くの情報を送信するため、ＲＴＭＰはストリームを複数のフラグメントに分割し、それらのサイズはクライアントとサーバとの間で動的に交渉される。ＲＴＭＰは、パケットストリームを送信及び受信するために用いられるいくつかの独立仮想チャネルを規定する。
【0009】
リアルタイムトランスポートプロトコル（ＲＴＰ：Ｒｅａｌ－ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）は、ＩＰネットワークを介してストリームを配信するためのネットワークプロトコルである。ＲＴＰは、ストリーミング及びビデオ遠隔会議を含む通信及びエンターテインメントシステムで用いられる。ＲＴＰは典型的に、ユーザデータグラムプロトコル（ＵＤＰ：Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）上で動作する。ＲＴＰは、ＲＴＰ制御プロトコル（ＲＴＣＰ：ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）と共に用いられる。ＲＴＰがストリームを送っている間、ＲＴＣＰを用いて送信統計データ及びサービス品質（ＱｏＳ：ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）を監視し、複数のストリームの同期を支援する。リアルタイムストリーミングプロトコル（ＲＴＳＰ：Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）は、メディアサーバを制御するためエンターテインメント及び通信システムで用いるように設計されたネットワーク制御プロトコルである。このプロトコルは、エンドポイント間のメディアセッションを確立及び制御するために用いられる。ストリーミングビデオ／オーディオデータの送信自体は、ＲＴＳＰによって実行されるタスクではない。ほとんどのＲＴＳＰサーバは、ストリーミングのためにＲＴＣＰと共にＲＴＰを用いる。ＲＴＰの１つの用途は、アプリケーションプログラミングインタフェース（ＡＰＩ：ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ）を介してウェブブラウザ及びモバイルアプリケーションにリアルタイム通信（ＲＴＣ：ｒｅａｌ－ｔｉｍｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）を提供するフリーオープンソースのプロジェクトであるウェブリアルタイム通信（ＷｅｂＲＴＣ：Ｗｅｂ Ｒｅａｌ－Ｔｉｍｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）である。これは、直接ピアツーピア通信を用いたウェブページ内でのストリーミングを可能とし、従ってプラグインのインストール又はネイティブアプリケーションのダウンロードが必要なくなる。ＷｅｂＲＴＣで用いられるストリームタグは、システムコンポーネントによって帯域外で生成され、ストリームと並行して下流に流れる。ストリームタグは、別のシステムコンポーネントによって強制的に伝搬を停止され得る。
【0010】
ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）トランスポートストリーム（トランスポートストリーム、ＭＰＥＧ－ＴＳ、ＭＴＳ、又はＴＳとしても既知である）は、オーディオ、ビデオ、並びにプログラム及びシステム情報プロトコル（ＰＳＩＰ：Ｐｒｏｇｒａｍ ａｎｄ Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）データの送信及び記憶のための標準的なデジタルコンテナフォーマットである。プログラム特定情報（ＰＳＩ：Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）を含むＴＳストリームは、ＴＣＰ／ＩＰを介してトランスポートすることができる。ＰＳＩは、プログラムマッピングテーブル（ＰＭＴ：Ｐｒｏｇｒａｍ Ｍａｐｐｉｎｇ Ｔａｂｌｅ）等、プログラムを逆多重化及び提示するために必要な情報を送るテーブルセットである。
【0011】
ＨＴＴＰを介した動的アダプティブストリーミング（ＤＡＳＨ：Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）は、ＭＰＥＧ－ＤＡＳＨとしても既知であり、インターネットを介した高品質ストリーミングを可能とするアダプティブビットレートストリーミング技法である。ＭＰＥＧ－ＤＡＳＨは、従来のＨＴＴＰウェブサーバから配信することができる。ＨＬＳと同様、ＭＰＥＧ－ＤＡＳＨは、コンテンツを小さいＨＴＴＰベースのファイルセグメントのシーケンスに分割することによって機能する。各セグメントは、映画やスポーツイベントのライブ放送のような数時間継続する可能性のあるコンテンツの短い再生時間間隔を含む。コンテンツは様々な異なるビットレートで利用可能となり、代替的なセグメントが異なるビットレートでエンコードされて、整列した短い再生時間間隔をカバーする。ＭＰＥＧ－ＤＡＳＨによって、インターネット接続テレビ、ＴＶセットトップボックス、デスクトップコンピュータ、スマートフォン、タブレット等のデバイスは、インターネットで配信されたマルチメディアコンテンツを消費することができ、従って、様々なインターネット受信条件に対応することが可能となる。
【0012】
図１は、例えば、プログラム用の制限されたＴＳストリーム等のストリーム、又は制限のないＷｅｂＲＴＣストリームを介したストリームタグ、又は外部デバイスからのストリームを受信するシステムにおけるコンテンツ配信の実施例を示す。これらのストリームは、インジェストサーバ（Ｉｎｇｅｓｔ ｓｅｒｖｅｒ）として知られるメディアサーバによって取り込まれる（ｉｎｇｅｓｔ）。取り込まれたストリームは、出力デバイス、レコーダデバイス、又はマルチビューデバイスに送信することができる。ビデオ作成のため、様々なシステム、プラットフォーム、ハードウェア、ソフトウェア、ネットワーク、設備等が、ストリーミングの開発、試験、配信、監視、制御、又はサポートを行う必要がある。ビデオ作成はＩＴインフラで実施されているので、ビデオストリームを「取り込む」には、多数の会場から、ユーザが１つ以上のインジェストサーバと接続する作成プラットフォーム内へ、それらを移動させる。
【0013】
作成プロセスがいっそう洗練されるにつれて、クラウドでライブストリームをサポートすると共に、プラットフォームの構造を変化させることなくその拡張を可能とする柔軟なシステム及び方法が必要とされる。このような柔軟なシステムは、様々なトランスポートフォーマットをサポートし、また、自動化ルーティング、監視、及び警報もサポートしなければならない。
【発明の概要】
【0014】
簡潔に述べると、本発明によれば、コンピューティングシステムの１つ以上のサーバでアプリケーションソフトウェアを実行することにより、１つ以上のソースから通信チャネルを介して受信されたマルチメディア信号等の信号を用いるプログラムがコンピューティングシステムで作成される。サーバのうち少なくとも１つは、定義された論理エンティティ（ｌｏｇｉｃａｌ ｅｎｔｉｔｙ）を処理する１つ以上のプロセッサを有する。ソースから通信チャネルを介してサーバで、プログラムの作成に用いられる信号を受信する。信号のソースに関連付けられた属性を有する入力論理エンティティを定義して、入力論理エンティティが信号を受容又は拒否するための論理表現を含むユーザ定義述語（ｐｒｅｄｉｃａｔｅ）に応答するようにする。また、受容された信号を識別するストリーム論理エンティティと、ストリーム論理エンティティ及び宛先の間で接続を確立するルーティング論理エンティティと、を定義する。ルーティングルールに基づいて、受容された信号を宛先にルーティングする。
【0015】
本発明のより詳細な特徴のいくつかによれば、ストリーム論理エンティティを宛先に関連付ける出力論理エンティティが定義され、出力論理エンティティは、受容された信号を宛先にマッピングするために評価されるユーザ定義プログラム変換ルールに従ってストリーム論理エンティティを変換するようになっている。例えば、信号はＭＰＥＧ信号とすることができ、ユーザ定義プログラム変換ルールはプログラム特定情報（ＰＳＩ）に基づく。一実施形態において、ストリーム論理エンティティはパケット化エレメンタリストリーム（ＰＥＳ：Ｐａｃｋｅｔｉｚｅｄ Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）に関連付けられ、ＰＳＩはストリーム論理エンティティに関連付けられたプログラムマッピングテーブル（ＰＭＴ）を含む。別の実施形態において、ＭＰＥＧ信号のパケットの到着間時間（ＩＡＴ：ｉｎｔｅｒ ａｒｒｉｖａｌ ｔｉｍｅ）はサーバで記録され、一定のビットレートを達成するため出力論理エンティティによって用いられる。
【0016】
本発明の他のより詳細な特徴によれば、ルーティングルールは、入力論理エンティティに関連付けられたユーザ定義の論理ルールであり、信号が入力論理エンティティに与えられた場合にユーザ定義の論理ルールが評価されるようになっている。一実施形態において、ユーザ定義述語は、時刻、地理領域、位置、又はＩＰアドレスに基づく。別の実施形態において、入力論理エンティティはユーザによって永続論理エンティティとして定義されて、入力論理エンティティがグラフィカルユーザインタフェース又はアプリケーションプログラミングインタフェース（ＡＰＩ）を介してユーザによって構成されるようになっている。更に別の実施形態において、ストリーム論理エンティティは、局所接続を生成するセッションタグ及び／又は信号の所有者又は発行者の一意の識別（ＩＤ）に関連付けられている。
【0017】
本発明の更に別の詳細な特徴によれば、信頼度に基づいて信号の特徴が認識され、認識した特徴は信号に関連付けられたメタデータとして用いられる。
【図面の簡単な説明】
【0018】
【図1】ストリームを受信するシステムにおけるコンテンツ配信の実施例を示す。
【図2】ストリーミングによるプログラムの作成、後処理、及び配信で用いられるライブビデオクラウド（ＬＶＣ：Ｌｉｖｅ Ｖｉｄｅｏ Ｃｌｏｕｄ）プラットフォームにおける本発明の実施例を示す。
【図3】ＬＶＣプラットフォームの物理及び論理コンポーネントを層状にする図を示す。
【図4】デバイスが複数のインジェストサーバに結合されたインジェストロードバランサにビデオ信号を提供する場合の、入力の属性の機能ブロック図を示す。
【図5】本発明に従ってＬＶＣプラットフォームにおいて入力を生成するためのプロセスを示し、ユーザインタフェースを介して入力を生成するためのポータルを示す。
【図6】本発明に従ってＬＶＣプラットフォームにおいて入力を生成するためのプロセスを示し、「一般」タブの選択を示す。これによってオペレータは、ＬＶＣプラットフォーム内で入力を発見可能とする一般的な情報を入力することができる。
【図7】本発明に従ってＬＶＣプラットフォームにおいて入力を生成するためのプロセスを示し、ＳＲＴプッシュに特有の設定を含む「設定」タブの選択を示す。
【図8】本発明に従ってＬＶＣプラットフォームにおいて入力を生成するためのプロセスを示し、ＵＲＬが提供されるリストから選択されたデータセンタを示す。
【図9】本発明に従ってＬＶＣプラットフォームにおいて入力を生成するためのプロセスを示し、この例では５０ｍｓに設定されている待ち時間のような他の構成を示す。
【図10】本発明に従ってＬＶＣプラットフォームにおいて入力を生成するためのプロセスを示し、述語を示す。
【図11】本発明に従ってＬＶＣプラットフォームにおいて入力を生成するためのプロセスを示し、所与のＩＰアドレスからのストリームのみを受容又は承認する第１の述語と、午後８時～午後１０時の間にストリームを受容又は承認することを要求する第２の述語と、を生成することを示す。
【図12】本発明に従ってＬＶＣプラットフォームにおいて入力を生成するためのプロセスを示し、オペレータが「生成」ボタンをクリックすると、ＬＶＣは、ＤＢＭＳに生成された入力のレコードを生成するよう関連するＡＰＩに要求することを示す。
【図13】本発明に従ってＬＶＣプラットフォームにおいて出力を生成するためのプロセスを示し、ユーザインタフェースを介して出力を生成するためのポータルを示す。
【図14】本発明に従ってＬＶＣプラットフォームにおいて出力を生成するためのプロセスを示し、「一般」タブの選択を示す。これによってオペレータは、ＬＶＣプラットフォーム内で出力を発見可能とする一般的な情報を入力することができる。
【図15】本発明に従ってＬＶＣプラットフォームにおいて出力を生成するためのプロセスを示し、ユーザが、遅延、フレームレート解像度、及びインターレースモードを設定することができる「設定」タブの選択を示す。
【図16】本発明に従ってＬＶＣプラットフォームにおいて出力を生成するためのプロセスを示し、ユーザが変換パラメータを設定することができる「プログラム変換」タブの選択を示す。
【図17】本発明に従ってＬＶＣプラットフォームにおいて出力を生成するためのプロセスを示し、ユーザが宛先パラメータを選択することができる「宛先」タブの選択を示す。
【図18】本発明に従ってＬＶＣプラットフォームにおいて出力を生成するためのプロセスを示し、ユーザが宛先パラメータを選択することができる「宛先」タブの選択を示す。
【図19】ストリームを定義する属性を示す。
【図20】ルーティングルールの実施例を示す。
【図21】ストリームのソースをターゲットに接続する場合のルーティングを示す。
【図22】ＬＶＣプラットフォームのエンティティ間のフロー図の例を示す。
【図23】ＬＶＣプラットフォームで論理により実施される方法において本発明の一実施形態を実施することを例示するフローチャートを示す。
【発明を実施するための形態】
【0019】
以下は、本発明を記載するために用いられる用語集である。
【0020】
【表1】
【0021】
図２は、ストリーミングによるプログラムの作成、後処理、及び配信で用いられるライブビデオクラウド（ＬＶＣ）プラットフォームにおける本発明の実施例を示す。ＬＶＣは、プログラム作成において用いられる様々なコンポーネントを表す論理エンティティを処理するプロセッサを含むサーバを使用する。これらの論理エンティティによってＬＶＣをスケーラブルにすることができ、以下で更に説明するユーザ定義パラメータに基づいて様々な作成ニーズに合うように処理パワーを調整できるようになっている。ＬＶＣプラットフォームはシステム管理者によって管理され、システム管理者は、データベースを制御すると共に、インターネットを含むクラウドコンピューティングネットワークを介してデータベース管理システム（ＤＢＭＳ：ｄａｔａｂａｓｅ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ）を形成するバックエンド及びフロントエンドのサーバを制御する。ＬＶＣプラットフォームは、プラットフォームの物理構造を変更することなくユーザ定義パラメータに基づいた柔軟なルーティング選択を可能とするプログラマブルストリーミングパイプラインをサポートする。このように、記載されるＬＶＣプラットフォームは、作成プロセス中の監視及び警報をスケーラブルにサポートしながら、様々なストリーミングフォーマットを介した自動化マルチメディアルーティングを提供する。ＬＶＣは、ストリームの所有者又は発行者によって任命されて管理機能を実行する特権が与えられた作成担当者、すなわちオペレータによって使用することができる。また、ＬＶＣは、プログラムの所有者又は発行者を含む、プログラムで用いられる信号を供給する特権が与えられた供給者（ｃｏｎｔｒｉｂｕｔｏｒ）によっても使用される。オペレータが実行する管理機能には、入力、ストリーム、ルーティング、及び出力（以下で更に記載する）のような論理エンティティを生成すること、並びに、供給者のメンバーシップを個別に又はチームで管理することが含まれる。ＬＶＣのユーザは、作成担当者すなわちオペレータと、ＬＶＣに対する信号の供給者である可能性がある。例えばオペレータは、プログラムの所有者又は発行者のために作成を行う企業であり得る。作成（Ｐｒｏｄｕｃｔｉｏｎ）はオペレータによって生成され得る。ＬＶＣプラットフォームにおいて、オペレータは入力及び出力を作成に割り当てることができる。作成は、構造、入力及び出力のセットを割り当てることによるフィルタリング、並びに入力及び出力を開始／停止する能力を与える構成概念である。
【0022】
本明細書で用いられる場合、「コンポーネント」、「システム」、「プラットフォーム」、「デバイス」、「エンティティ」等の用語は、コンピュータエンティティ、又は、エンコーダもしくはトランスコーダ機能性のような１つ以上の特定の機能性を有する動作可能マシンに関連したエンティティ、並びに、入力、出力、プログラム変換、及びルーティングのような論理エンティティを示すことができる。本明細書で開示されているエンティティは、ハードウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、又は実行中ソフトウェアであり得る。本明細書で用いられる論理エンティティは、論理アクティビティによって消費又は生成される機能性を表す。それらはシステム内での現実世界の物体の表現であり、このため、システム内の他の多くのエンティティと関係を有する。エンティティの属性は、それらの目的及び使用法を反映する。例えば、エンティティ又はコンポーネントは、限定ではないが、プロセッサ上で実行するプロセス、プロセッサ、オブジェクト、実行ファイル、実行スレッド、プログラム、及び／又はコンピュータであり得る。一例として、プロセッサを有するサーバ上で動作するアプリケーションと、サーバ又はプロセッサは、双方ともコンポーネント又はエンティティであり得る。１つ以上のコンポーネント又はエンティティがプロセス及び／又は実行スレッド内に存在することができ、１つのコンポーネントが１つのコンピュータ又はサーバ上に局所化する及び／又は２つ以上のコンピュータ又はサーバ間に分散することができる。また、これらのコンポーネント又はエンティティは、様々なデータ構造が記憶されている様々なコンピュータ可読媒体から実行することができる。コンポーネント又はエンティティは、例えば１つ以上のデータパケット（例えば、ローカルシステム内、分散システム内で別のコンポーネントと相互作用する、及び／又はインターネット等のネットワークを介して別のシステムと相互作用するコンポーネントからのデータ）を有する信号に従って、ローカル及び／又はリモートのプロセスを介して通信することができる。
【0023】
図２は、例えばＴＳ、ＷｅｂＲＴＣ、ＲＴＭＰ、及びＳＲＴ等の様々なトランスポートプロトコルを用いた様々なフォーマットのビデオ信号がストリームとしてインターネットを介してインジェストサーバにルーティングされることを示す。図示のように、供給者のチームはＷｅｂＲＴＣ及びＳＲＴ信号を供給し、チームの一員ではない単一の供給者はＲＴＭＰ信号を供給する。プログラムの発行者又は所有者は、ＴＳプロトコルを用いて信号を供給することができる。取り込まれた信号は、論理的に抽象化された入力によって受容された場合、ストリームとして抽象化された後に、論理エンティティとして定義された抽象化出力に送信される。出力は、レコーダデバイス又はマルチビューデバイスにマッピングすることができ、マルチビューデバイスはビデオ画像をいわゆるタイルで示す。ＴＳを介したＭＰＥＧ－ＤＡＳＨを用いる１つのルーティング例では、ＬＶＣは、ＥＩＤＲとして知られている汎用一意識別システムを用いて様々なオーディオビジュアルオブジェクトタイプを識別する。ＥＩＤＲは、資産、所有者／発行者、タイトル、編集、及びコレクション、シリーズ、時期、エピソード、及びクリップを識別する。ＬＶＣは、電子プログラミングガイド（ＥＰＧ：Ｅｌｅｃｔｒｏｎｉｃ Ｐｒｏｇｒａｍｍｉｎｇ Ｇｕｉｄｅ）及び対話型プログラミングガイド（ＩＰＧ：Ｉｎｔｅｒａｃｔｉｖｅ Ｐｒｏｇｒａｍｍｉｎｇ Ｇｕｉｄｅ）をサポートする。この例では、インジェストサーバにルーティングされるＴＳストリームは、映画、ニュース放送、ＴＶ及びスポーツ番組等に関連したオーディオ／ビデオデータ及び帯域内（ＩＢ：Ｉｎ－ｂａｎｄ）メタデータを含む。当技術分野において周知の業界標準がいくつか存在し、その例として、帯域内メタデータシグナリングに関連するＡＮＳＩ ＳＣＴＥ３５１、ＡＮＳＩ ＳＣＴＥ１０４２、ＳＭＰＴＥ２０１０、及びＳＭＰＴＥ２０３８がある。
【0024】
また、ＰＭＴ及びＥＰＧのような帯域外（ＯＯＢ：Ｏｕｔ－ｏｆ－ｂａｎｄ）メタデータもルーティングされる。メタデータは任意の種類のシグナリングデータを表すことができ、例えば、シグナリンググラフィカルオーバーレイ、テロップ（ｔｉｃｋｅｒ）、プログラム内イベント（サッカーの試合での得点ゴール等）、イベントの正確なタイミング（例えばプログラム、チャプタ、広告、及びコマーシャルの時間の開始）、資産ＩＤ（例えばＥＩＤＲ、Ａｄ－ＩＤ）、字幕、例えばゲームのようなプログラムに関する統計データ等である。また、メタデータは、例えば人工知能（ＡＩ：Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）又は機械学習（ＭＬ：Ｍａｃｈｉｎｅ Ｌａｍｉｎｇ）を用いて、何らかの信頼度に基づいて認識するか又は他の方法で測定することができるシーンの特徴を示すために使用できる。一実施形態では、ＡＩ／ＭＬを用いて、信頼度に基づいてオーディオ／ビデオデータの指定された特徴を認識する。一度認識されたら、指定された特徴に関連付けられた属性又はパラメータをメタデータとして使用することができる。例えば、ＡＩ／ＭＬを用いて、シーン内の人の顔を分析し、例えば笑顔又はしかめ面等、そのような分析の信頼度に関連付けられたメタデータを生成することができる。
【0025】
ＬＶＣプラットフォームのユーザは、ｗｗｗ．ｌｉｖｅｖｉｄｅｏｃｌｏｕｄ．ｃｏｍ等のＵＲＬにおいてフロントエンドサーバが提供するポータルを介してプラットフォームにアクセスし、ユーザのログインＩＤ及びパスワードを入力することができる。一度ログインしたら、ウェブポータルは、ユーザ／オペレータが本発明に従ってＬＶＣプラットフォームの様々なコンポーネントを構成することを可能とするインタフェースを提供する。プラットフォームの構成可能エンティティの１つは入力であり、これは、結果として生じる１つ以上のストリームに関連付けることができる。入力は、グラフィカルユーザインタフェース又はアプリケーションプログラミングインタフェース（ＡＰＩ）を介して構成及び管理された永続論理エンティティとしてユーザにより定義される。一実施形態において、入力は、オペレータによる手作業のアクションを介して明示的に削除されるまで存在する。別の実施形態において、入力は、入来信号が存在しない間は存在する。一例では、入力の結果として多くのストリームが生じ得る。各ストリームには、局所接続を生成するセッションタグが関連付けられる。ストリームの各セッションタグは、一意の識別（ＩＤ）を有するストリームの所有者／発行者によって生成される。
【0026】
オペレータは、フロントエンドサーバが提供する管理インタフェースを用いてストリームを管理する。ＤＢＭＳは、供給された信号の受容又は承認を管理し、更に、承認又は受容された出立ストリームのエンリッチメント及びルーティングを管理する。全ての入来信号は集約される。インジェストサーバ及びオペレータは、どの信号を再配信及び／又は記録の前に論理ストリームに抽象化するか、並びに、どの信号をストリームに論理抽象化することなく廃棄するかを決定する。オペレータは、記録されたストリームを、再利用のため、典型的にＺＩＰコンテナである「メディアミックス」コンテナに集めることができる。再利用には、例えば、ダウンロードされたアーカイブ、サードパーティのエディタによる使用、記録後のオンデマンドでの視聴等が含まれ得る。ＶＯＤでは、インジェストサーバがメディアミックスコンテナから記録されたストリームを読み出し、それらをコンテンツデリバリネットワーク（ＣＤＮ：ｃｏｎｔｅｎｔ ｄｅｌｉｖｅｒｙ ｎｅｔｗｏｒｋ）に公開し、ＣＤＮはそれらを下流の視聴者に配信する。
【0027】
ライブビデオストリーミングでは、インジェストサーバによって、オペレータは、受容されたストリームを管理し、ＤＢＭＳが保持する構成情報に基づいて「オンエア」するものを選択することができる。バックエンドサーバは、データベースにアクセスして、構成パラメータ、ＩＤ、属性、述語、ルーティングルール、ユーザプロファイルデータ等を記憶及び検索する。このようにしてオペレータは、受容されたストリームが配信のため出力へ送られる前にライブセッションを管理することができる。フロンドエンドサーバは、各セッションタグに関連付けられた全ての入力をオペレータに表示し、オペレータは、ストリーム受容及びルーティング構成パラメータや、例えばチームやグループ等のユーザプロファイルを、見ると共に管理することができる。
【0028】
バックエンドサーバによって、オペレータは、フロントエンドサーバが提供するインタフェースを用いて放送を開始するため及びライブストリームの記録をトリガするために利用可能な入力を割り当てることができる。このように、オペレータは、配信のためセッションに対するリンク又は埋め込まれたコードをコピーすることができる。
【0029】
図３は、２つの物理層すなわち入力物理層及び出力物理層で囲まれた論理層として抽象化することによりＬＶＣプラットフォームの物理及び論理コンポーネントを層状にする図を示す。図示のように、入力物理層は、入力ハードウェアデバイス及び／又はコンピューティングデバイス上で動作するウェブブラウザアプリケーションで生じたマルチメディア信号のような信号の入力ソースを示す。ソースは、サーバに与えられる信号を提供するエンティティである。また、入力物理層は、ＬＶＣで論理エンティティとして入力、ストリーム、出力、ルーティング、及びルーティングルールのようなコンポーネントを実施する処理のため、ＤＢＭＳにより実施された論理層にＩＢメタデータ及び／又は挿入ＯＯＢメタデータと共に未加工の供給された信号を提供する。信号は、本明細書で入力と呼ばれる論理抽象化に与えられる。ポリシー層の承認制御コンポーネントは、ユーザ定義述語に基づいて供給された信号を受容又は拒否するためのフィルタとして作用する。述語は、真（ＴＲＵＥ）又は偽（ＦＡＬＳＥ）を評価する論理表現である。評価は、コードを処理する際の実行論理を指示する。例えば、論理表現が真と評価された場合、供給された信号は受容される。同じ例において、論理表現が偽と評価された場合、信号は拒否される。別の例では、以下で更に記載されるように、反対の論理が適用され得る。信号は、信号が拒否されるか又は受容されるかを決定するために用いられるユーザ定義述語に基づいて、ストリームとして論理的に抽象化される。受容された信号のみがストリームとして抽象化され、拒否された信号は抽象化されることなく廃棄される。ストリームは、ＩＢ／ＯＯＢメタデータに関連付けられ、更に、ＭＰＥＧ－２（ＩＳＯ／ＩＥＣ１３８１８－１）及びＩＴＵ－Ｔ Ｈ．２２２．０の仕様であるパケット化エレメンタリストリーム（ＰＥＳ）に関連付けられる。ＰＥＳは、ＭＰＥＧプログラムストリーム及びＭＰＥＧトランスポートストリーム内のパケットのエレメンタリストリーム（通常はオーディオ又はビデオエンコーダの出力）の送信を定義する。エレメンタリストリームは、ＰＥＳパケットヘッダ内でエレメンタリストリームからの順次データバイトをカプセル化することによってパケット化される。
【0030】
受容された信号すなわち受容されたストリームを表すストリームは、ポリシー層の一部であるルーティングルールに基づいてルーティングされる。ポリシー層は、述語に加えて、ルーティングルール及びプログラム変換を含む他のユーザ定義パラメータを実施する。ルーティングルールは、論理層が受容されたストリームを出力にルーティングする前のストリーミング中にＩＢ／ＯＯＢメタデータを考慮することができる。受容されたストリームのルーティングは、ルーティング再評価ループによる再評価に基づいて生成される。ルーティングは、受容されたストリームが出力にルーティングされる前のユーザ定義ルーティングルールに基づく。
【0031】
出力は、ユーザ定義プログラム変換に基づいて、基礎となる物理トランスポート内でＰＥＳのサブセットを選択することができる。各プログラム変換は、ストリームの多重送信を生成する場合に評価される、出力に関連付けられた論理ルールを含む。プログラム変換は、プログラムに関するメタデータを含むプログラム特定情報（ＰＳＩ）を使用する。ＰＳＩは、とりわけ、ＰＡＴ（Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅ：プログラム関連テーブル）及びＰＭＴ（プログラムマッピングテーブル）を含む。ＰＭＴは、複数のＰＥＳをＰＩＤによって指定することによりプログラムを規定する。例えばＰＭＴは、ビデオに対してはＰＩＤ１００で、オーディオに対してはＰＩＤ１０１でＰＥＳを参照する。１つのＭＰＥＧ信号は、ＰＡＴにリスト化されている多くのＰＭＴを含み得る。
【0032】
本発明によれば、プログラム変換は、事前に（ａｈｅａｄ ｏｆ ｔｉｍｅ）又は実行時に（ｊｕｓｔ ｉｎ ｔｉｍｅ）、受容されたストリームを選択する。例えば、ＰＩＤ１００に対するプログラム変換ＦＩＲＳＴ＿ＶＩＤＥＯは、プログラムマッピングテーブル（ＰＭＴ）が利用可能となり、ＰＩＤ１００でビデオ信号を送信する第１のＰＥＳを配信する場合、実行時に第１のビデオを選択する。論理出力は、出力物理層において、ストリームの多重送信を生成する場合に評価される出力に関連付けられた論理ルールを用いて、１つ以上のサーバで使用されるような１つ以上の処理ユニット又はプロセッサにより処理される。サーバは、コンテンツデリバリネットワーク（ＣＤＮ１～４）又はソーシャルネットワークによって用いられる多重送信及びＰＥＳを含む信号を提供する。
【0033】
図４は、入力よって抽象化される信号の所有者、エンドポイント、ルーティングルール、述語、状態、及びメタデータを含む、入力として定義された論理エンティティの属性の機能ブロック図を示す。入力は、オンライン、オフライン、エラー、未知等の状態を有する。一例において、ソースは、デバイス、エンコーダ、公共もしくは民間ＷｅｂＲＴＣを介して信号を供給するウェブブラウザ、又はトランスコーダとすることができる。ストリームは、アクティブでありストリームによって識別可能である受容された信号の表現である。ストリームは、受容された信号がアクティブである間は存在する。ターゲット／宛先は、１又は複数のストリームがルーティングされるエンティティである。ターゲット／宛先は、出力、トランスコーダ、１又は複数のストリームを受信する入口を備えたレコーダとすることができる。ターゲット／宛先は、多重ビューのために用いられるストリームの入口を有し得る。また、ターゲット／宛先は、出力、トランスコーダ、又はレコーダとすることができる。
【0034】
ソースの出力は、ＬＶＣプラットフォームのコンポーネントに対する入力とすることができる。入力は、図３に示されている論理層で実施されるものとして見ることができる。ＬＶＣは、２つのタイプの入力、すなわち「プッシュ」入力と「プル」入力をサポートする。プッシュ入力は、接続を聞き、プッシュ信号をＬＶＣプラットフォーム内へ入れる。プル入力は、ソースに対するアクティブな接続を必要とし、信号をＬＶＣ内へプルする。入力の例を以下に挙げる。
・Ｐｕｌｌ ＨＬＳ、ＭＰ４
・Ｐｕｌｌ Ｉｍａｇｅ（スレート、オーバーレイ）
・Ｐｕｓｈ ＳＲＴ
・Ｐｕｓｈ ＲＴＭＰ
・Ｐｕｓｈ ＨＬＳ
・Ｐｕｌｌ ＨＬＳ、ＭＰ４
・Ｐｕｌｌ Ｉｍａｇｅ（スレート、オーバーレイ）
・Ｐｕｓｈ ＳＲＴ
・Ｐｕｓｈ ＲＴＭＰ
・Ｐｕｓｈ ＨＬＳ
【0035】
一実施形態において、入力は、一人のオペレータ又は複数人のオペレータのチーム／グループの双方でなくいずれか一方によってタイプに基づいて管理される。特定の入力タイプは管理されない場合がある。一例において、入力は１つ以上のＵＲＬを提供し、これに対して、デバイス（エンコーダ、ソフトウェア、ブラウザ等）をエンドポイントで接続することができる。エンドポイントは、通常、サーバ又はサービスのＵＲＬによって表現される通信チャネルの一端である。エンドポイントは、入力がオフに切り換えられると無効になる。エンドポイントは有効期間（ＴＴＬ：Ｔｉｍｅ ｔｏ Ｌｉｖｅ）を有し、この後は期限が切れる。ＴＴＬは、パケットが無限に循環するのを防止するカウンタ又はタイムスタンプとして実施され得る。ＴＴＬは、安定したＲＴＭＰ、プッシュＵＲＬ、又は他のハードウェアエンコーダのような特定の入力に対して適用されない。エンドポイントは、事前に知られない場合があるという点で、動的であり得る。例えば入力は、要求に応じて動的にエンドポイントを発生することができる。
【0036】
入力は、１つ以上の述語を有し得る。述語は、ｆ（入力、ストリーム）→ブール値（真又は偽）の形態で機能する。一例において、いずれかの述語が偽である場合、入力は供給された信号を受容しない。この例では、全ての述語が真である場合にのみ、入力は供給された信号を受容する。述語は、ウェブポータル又はＡＰＩによって与えられたユーザインタフェースを介してオペレータが構成することができる。例えば、「特定の時間帯に信号を受容することができる」、「信号があるジオフェンスによって又はあるゾーンもしくは位置内で開始した場合、これを受容することができる」、又は「特定のＩＰアドレスからの信号を受容することができる」等であるように、オペレータによって関数を構成できる。
【0037】
関数ジオフェンス：（ｌａｔ，ｌｎｇ，ｄ）→（入力、ストリーム）→ブール値は、所与の緯度、経度、及び距離のための述語を生成する関数である。この関数を用いて、供給された信号のメタデータをそれに応じて評価すると共に、特定の対象点の近くにない全ての信号を拒否することができる。述語が偽である場合、信号はストリームとして抽象化されることなくインジェストからドロップされる。ＬＶＣプラットフォームは、システム管理者が内部で用いる述語を生成することができる。例えば、入力のために入来する接続は、最大でＮ個の接続のみを可能とする内部述語を用いて制限することができる。
【0038】
ＬＶＣプラットフォームは、様々なルーティングプロトコルを守るルーティング可能エンティティのユーザ定義の自動化ルーティングをサポートする。ルーティングは、受容されたストリーム（又はその実際のビデオソース）とターゲットとの間の接続を確立する。ターゲットは、ストリームが有効である限り有効である。より具体的には、入力は、ユーザ定義のルーティングルールに基づいてルーティングすることができる。ルーティングルールは、供給された信号が入力に現れた場合に評価される、入力に付随する定義である。ルーティングルールは、ストリームの状態を決定するため、定期的に（例えば毎秒）再評価される。入力のルーティングルールは、述語が変化した場合に再評価される。
【0039】
ユーザ定義のルーティングルールを用いて、以下のように所望のセットアップを定義することができる。
・１９：３０にオンデマンドループからライブに切り換える
・１０ｍｂｉｔ／ｓ未満の場合、ストリームをドロップする
・営業時間でない場合、入来ストリームを記録する
・入力Ａから常に出力Ｂにストリームをルーティングする
・１９：３０にオンデマンドループからライブに切り換える
・１０ｍｂｉｔ／ｓ未満の場合、ストリームをドロップする
・営業時間でない場合、入来ストリームを記録する
・入力Ａから常に出力Ｂにストリームをルーティングする
【0040】
受容された信号を表すストリームをルーティングする場合、この受容された信号が存在する限り、ソースとターゲットとの間で通信チャネルを介して接続を確立することができる。ストリームは、従来のビデオ、圧縮データストリーム又はデータファイル、並びに、オーディオビジュアルコンテンツの他のコンポーネントと共に送信されるＩＢメタデータを含む（ビデオ、オーディオ、字幕等）、受容された信号を表すことができる。入力は、オペレータが論理エンティティとして生成又は定義する際に受容されたストリームに付随する追加のメタデータを定義することができる。メタデータは時間と共に変化し得るので、ストリームは、それらのメタデータが変化した場合に再評価される。一実施形態では、入力の状態の変化によってもルーティング関係の再評価が行われる。
【0041】
入力の生成
図５から図１２は、本発明に従ってＬＶＣプラットフォームで入力を生成するためのプロセスを示す。プロセスは図５で開始し、ここで、図２に示されているＬＶＣプラットフォームにログインするオペレータは、ユーザインタフェースを介して入力タブ（図示せず）を選択する。入力タブ内で、オペレータは「新しい入力」をクリックし、ストリームタグ、ＲＴＭＰプッシュ、又はＳＲＴプッシュ等の利用可能な入力のリストが提示される。この例では、オペレータはＳＲＴプッシュを選択する。２つのタブ、すなわち「一般」及び「設定」を含む構成ウィザードがオペレータに提示される。図６は、「一般」タブの選択を示す。これによってオペレータは、ＬＶＣプラットフォーム内で入力を発見可能とする一般的な情報を入力することができる。図７は、ＳＲＴプッシュに特有の設定を含む「設定」タブの選択を示す。ＬＶＣプラットフォームは、供給された信号に対して、各入力に一意のＵＲＬを生成する。図８は、ＵＲＬが提供されるリストから選択されたデータセンタを示す。図９は、この例では５０ｍｓに設定されている待ち時間のような他の構成を示す。図１０は述語を示す。各入力はゼロ以上の述語を含み得る。図１１は、所与のＩＰアドレスからのストリームのみを受容する第１の述語と、午後８時～午後１０時の間にストリームを受容することを要求する第２の述語と、を生成することを示す。図１２で示されているように、オペレータが「生成」ボタンをクリックすると、ＬＶＣは、ＤＢＭＳに生成された入力のレコードを生成するよう関連ＡＰＩに要求する。
図５から図１２は、本発明に従ってＬＶＣプラットフォームで入力を生成するためのプロセスを示す。プロセスは図５で開始し、ここで、図２に示されているＬＶＣプラットフォームにログインするオペレータは、ユーザインタフェースを介して入力タブ（図示せず）を選択する。入力タブ内で、オペレータは「新しい入力」をクリックし、ストリームタグ、ＲＴＭＰプッシュ、又はＳＲＴプッシュ等の利用可能な入力のリストが提示される。この例では、オペレータはＳＲＴプッシュを選択する。２つのタブ、すなわち「一般」及び「設定」を含む構成ウィザードがオペレータに提示される。図６は、「一般」タブの選択を示す。これによってオペレータは、ＬＶＣプラットフォーム内で入力を発見可能とする一般的な情報を入力することができる。図７は、ＳＲＴプッシュに特有の設定を含む「設定」タブの選択を示す。ＬＶＣプラットフォームは、供給された信号に対して、各入力に一意のＵＲＬを生成する。図８は、ＵＲＬが提供されるリストから選択されたデータセンタを示す。図９は、この例では５０ｍｓに設定されている待ち時間のような他の構成を示す。図１０は述語を示す。各入力はゼロ以上の述語を含み得る。図１１は、所与のＩＰアドレスからのストリームのみを受容する第１の述語と、午後８時～午後１０時の間にストリームを受容することを要求する第２の述語と、を生成することを示す。図１２で示されているように、オペレータが「生成」ボタンをクリックすると、ＬＶＣは、ＤＢＭＳに生成された入力のレコードを生成するよう関連ＡＰＩに要求する。
【0042】
出力の生成
出力はストリームの宛先である。それらは、１つ以上の物理サーバ及び多くの潜在的な宛先、例えば図３に関連付けて説明したソーシャルウェブサイト又はコンテンツデリバリネットワーク（ＣＤＮ）等を表し得る論理エンティティである。物理的な宛先は、１つの出力内でグループ化されて、標準変換のような同じビデオ処理をビデオ信号に適用できるようになっている。出力は、１つ以上のプログラム変換を含み得る。プログラム変換は、各ターゲット／宛先ごとに個別に指定され得る。特定の宛先の多重送信を生成する前に、ＰＭＴ内で指定された入来ＰＥＳを選択し、特定のパケット識別子（ＰＩＤ：Ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒ）を割り当てる。従ってユーザは、１つのトランスポートストリーム内でどの宛先がどの特定のストリームセットを受信するかを選択することができる。例えば、ある宛先は１つの言語のオーディオトラックを受信し、別の宛先は異なる言語のオーディオを受信できる。図１３から図１８は、本発明に従ってＬＶＣプラットフォームで出力を生成するためのプロセスを示す。図１３は、ユーザインタフェースを介して出力を生成するためのポータルを示し、ここでユーザは、コード変換又はパススルー出力等の様々な出力のリストから新しい出力を生成することができる。図１３において、ユーザはパススルー出力の生成を選択する。図１４は、「一般」タブの選択を示す。これによってオペレータは、ＬＶＣプラットフォーム内で出力を発見可能とする一般的な情報を入力することができる。図１５は、「設定」タブの選択を示す。これによってユーザは、遅延、フレームレート解像度、及びインターレースモードを設定することができる。
出力はストリームの宛先である。それらは、１つ以上の物理サーバ及び多くの潜在的な宛先、例えば図３に関連付けて説明したソーシャルウェブサイト又はコンテンツデリバリネットワーク（ＣＤＮ）等を表し得る論理エンティティである。物理的な宛先は、１つの出力内でグループ化されて、標準変換のような同じビデオ処理をビデオ信号に適用できるようになっている。出力は、１つ以上のプログラム変換を含み得る。プログラム変換は、各ターゲット／宛先ごとに個別に指定され得る。特定の宛先の多重送信を生成する前に、ＰＭＴ内で指定された入来ＰＥＳを選択し、特定のパケット識別子（ＰＩＤ：Ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒ）を割り当てる。従ってユーザは、１つのトランスポートストリーム内でどの宛先がどの特定のストリームセットを受信するかを選択することができる。例えば、ある宛先は１つの言語のオーディオトラックを受信し、別の宛先は異なる言語のオーディオを受信できる。図１３から図１８は、本発明に従ってＬＶＣプラットフォームで出力を生成するためのプロセスを示す。図１３は、ユーザインタフェースを介して出力を生成するためのポータルを示し、ここでユーザは、コード変換又はパススルー出力等の様々な出力のリストから新しい出力を生成することができる。図１３において、ユーザはパススルー出力の生成を選択する。図１４は、「一般」タブの選択を示す。これによってオペレータは、ＬＶＣプラットフォーム内で出力を発見可能とする一般的な情報を入力することができる。図１５は、「設定」タブの選択を示す。これによってユーザは、遅延、フレームレート解像度、及びインターレースモードを設定することができる。
【0043】
プログラムの変換
図１６は、オペレータ／ユーザが変換パラメータを設定することを可能とする「プログラム変換」タブの選択を示す。オペレータは、全体として又は各宛先ごとに個別に、出力のためにプログラム変換を指定し得る。プログラム変換は、１つのＰＭＴ内でＰＥＳに適用される個別ルールである。それらは、事前に又は実行時のいずれかでＰＥＳを選択する。プログラム変換は、「絶対的」、「相対的」、又は「任意」のいずれかのモードを有し、「絶対的」、「キープする」又は「ドロップする」のいずれかのアクションを有する。
図１６は、オペレータ／ユーザが変換パラメータを設定することを可能とする「プログラム変換」タブの選択を示す。オペレータは、全体として又は各宛先ごとに個別に、出力のためにプログラム変換を指定し得る。プログラム変換は、１つのＰＭＴ内でＰＥＳに適用される個別ルールである。それらは、事前に又は実行時のいずれかでＰＥＳを選択する。プログラム変換は、「絶対的」、「相対的」、又は「任意」のいずれかのモードを有し、「絶対的」、「キープする」又は「ドロップする」のいずれかのアクションを有する。
【0044】
絶対的及び任意のプログラム変換は、事前のものであり、ＰＭＴに知識の要件を課すことはない。絶対的ルールは、ＰＥＳをＰＩＤによって選択する。任意ルールは、任意のＰＥＳを選択する。相対ルールは、「第１のビデオ」又は「第２のオーディオ」のように、ある種類のｎ番目の形態を有する。これらのルールは、ＰＭＴに現れた時点のｎ番目のＰＥＳを選択する。従って相対ルールは、ＰＭＴを有するトランスポートストリームの存在を評価することを要求する。
【0045】
プログラム変換は、一度ストリームが利用可能となった場合にのみ分解され（ｒｅｓｏｌｖｅ）評価することができる。全てのＰＥＳの存在はＰＭＴが既知になった後でのみ知られるので、２つのプログラム変換が衝突するか否かを知ることは不可能である。しかしながら、オペレータは、異なるストリームを標準化するため意図的に衝突ルールを定義することができる。ルールＰＩＤ１００からＰＩＤ１００及びＰＩＤ１０１からＰＩＤ１００は、ＰＩＤ１００又はＰＩＤ１０１のどちらかに定義されたパケット化エレメンタリストリームを有するストリームを標準化し、このフィードをＰＩＤ１００上で利用可能とする。このようなルールは、ソースがＰＩＤ１００及びＰＩＤ１０１の双方を公表する場合に衝突を引き起こすだけである。従ってプログラム変換は、一度ストリームが出力にルーティングされて宛先に対して多重送信された場合にのみ評価及び実現することができる。
【0046】
プログラム変換は、最も特定的なものから最も特定的でないものへという順序で評価される。絶対的変換は相対的変換の前に評価され、相対的変換は任意変換の前に評価される。これらのカテゴリ内で、変換は、アクションに基づいて、より特定的で絶対的なものから、より特定的でなくドロップされるものへ評価される。プログラム変換は、一度ＰＭＴが既知になったら具体化される。このプロセスでは、相対的変換におけるｎ番目のインデックスのＰＥＳを選択することによって、全ての相対的変換は絶対的になる。一度全ての絶対的変換が既知になったら、衝突の解消が発生し得る。このプロセスにおいて、実質的に同一であるマッピング（ＰＩＤ１００からＰＩＤ１００、及びＦＩＲＳＴ＿ＶＩＤＥＯからＰＩＤ１００に対して、ＦＩＲＳＴ＿ＶＩＤＥＯはＰＩＤ１００である）はマージされる。ここで、衝突するアクションは正の結果を選択し（ドロップに対して勝利（ｗｉｎ）を維持する）、他の場合、衝突するマッピングはエラーとしてユーザに報告される（例えば、ＰＩＤ１００及びＰＩＤ２００の双方がビデオ信号に存在する場合、マッピングＰＩＤ１００からＰＩＤ２００及びＰＩＤ１０１からＰＩＤ２００は衝突する）。一実施形態において、プログラム変換パラメータは、ＬＶＣを用いて作成されているプログラムの要件に従ってユーザ定義される。
【0047】
待ち時間
基礎にあるインフラを抽象化する分散システムは、システムのユーザに対して追加の待ち時間を誘発し得る。信号の優れた分散は、これらの信号を一定のビットレートで配信して受信側ハードウェアデコーダが故障しないように、例えば一瞬で多すぎるパケットを受信して内部バッファのオーバーフローを引き起こし、これによりパケットをドロップして最終的にパケット損失及び視覚的アーチファクトを生じないようにしなければならない。ワイドエリアネットワーク上での信号の分散は、典型的に、受信されるパケットが一定の離散時間間隔に調整され得るバッファリング形態を必要とする。このようなバッファが無ければ、信号を転送しているパーティは、ネットワークジッタを受けている信号を受信するペースでしか信号を転送できない。パケットバッファのサイズは、言い換えれば、待ち時間の直線的増加ということである。従って、信号フロー内に追加のサーバを加えると、信号の知覚される待ち時間が加わり、これは望ましくない。ＬＶＣは、出力が信号を最終的な宛先へ送る時まで、一定のビットレートを達成するために必要なバッファリングを必要としない。パケットの到着間時間（ＩＡＴ）は、インジェストサーバで記録され、出力までシステム全体を通して維持される。この点で、個々のパケットのＩＡＴは、トランスポートストリームのパケットと共に追加のメタデータとして記憶されているので、再生することができる。
基礎にあるインフラを抽象化する分散システムは、システムのユーザに対して追加の待ち時間を誘発し得る。信号の優れた分散は、これらの信号を一定のビットレートで配信して受信側ハードウェアデコーダが故障しないように、例えば一瞬で多すぎるパケットを受信して内部バッファのオーバーフローを引き起こし、これによりパケットをドロップして最終的にパケット損失及び視覚的アーチファクトを生じないようにしなければならない。ワイドエリアネットワーク上での信号の分散は、典型的に、受信されるパケットが一定の離散時間間隔に調整され得るバッファリング形態を必要とする。このようなバッファが無ければ、信号を転送しているパーティは、ネットワークジッタを受けている信号を受信するペースでしか信号を転送できない。パケットバッファのサイズは、言い換えれば、待ち時間の直線的増加ということである。従って、信号フロー内に追加のサーバを加えると、信号の知覚される待ち時間が加わり、これは望ましくない。ＬＶＣは、出力が信号を最終的な宛先へ送る時まで、一定のビットレートを達成するために必要なバッファリングを必要としない。パケットの到着間時間（ＩＡＴ）は、インジェストサーバで記録され、出力までシステム全体を通して維持される。この点で、個々のパケットのＩＡＴは、トランスポートストリームのパケットと共に追加のメタデータとして記憶されているので、再生することができる。
【0048】
図１７及び図１８は「宛先」タブの選択を示し、これによってユーザは宛先パラメータを選択することができる。図１７は、例えばＲＴＭＰ及びＳＲＴ宛先のような複数の宛先の指定を示す。出力にルーティングされた同じストリームは、これらの宛先に多重送信される。図１８は、オペレータが「生成」ボタンをクリックした場合、ライブビデオクラウドＵＩがデータベース内に出力レコードを維持するようライブビデオクラウドＡＰＩに要求することを示す。ライブビデオクラウドＡＰＩはデータの正しさを検証し、生成した出力に対する一意の識別子を有するレコードと共にデータベース内に有効な出力を維持する。
【0049】
ストリーム
図１９は、ストリームを定義する属性を示す。ストリームは、識別されたＵＲＬ及びメタデータによって参照される、受容されたビデオ信号に関連付けることができる。メタデータは、ストリームの一部（すなわちＩＢメタデータ）であるか、又は異なるソースから提供することができ、その場合、システムの他のコンポーネントが、Ｈ．２６４のような使用されるビデオコーデックのバイナリフォーマットの知識なしでストリームメタデータを読み出すことができる。外部エンティティがビデオ信号をＬＶＣにプッシュした場合、又はビデオ信号がＬＶＣによってプルされた場合、供給された信号は入力の承認制御述語に基づいて受容される。受容された信号のみがストリームとして抽象化され、ストリームは、接続が確立され、安定し、述語の再評価に基づいて有効である限り、存在する。
図１９は、ストリームを定義する属性を示す。ストリームは、識別されたＵＲＬ及びメタデータによって参照される、受容されたビデオ信号に関連付けることができる。メタデータは、ストリームの一部（すなわちＩＢメタデータ）であるか、又は異なるソースから提供することができ、その場合、システムの他のコンポーネントが、Ｈ．２６４のような使用されるビデオコーデックのバイナリフォーマットの知識なしでストリームメタデータを読み出すことができる。外部エンティティがビデオ信号をＬＶＣにプッシュした場合、又はビデオ信号がＬＶＣによってプルされた場合、供給された信号は入力の承認制御述語に基づいて受容される。受容された信号のみがストリームとして抽象化され、ストリームは、接続が確立され、安定し、述語の再評価に基づいて有効である限り、存在する。
【0050】
また、ストリームは、再接続中に同じ発行者又は所有者の供給された信号を識別するため用いられるセッション識別子を含む。上記で明らかであるように、汎用一意識別子（ＵＵＩＤ：ｕｎｉｖｅｒｓａｌｌｙ ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ）を用いて、発行者、所有者、及び他のタイプの公共もしくは民間供給者によって供給されたストリームを識別する。セッション識別子は、入力によって定義及び／又は生成されるか、又は、インジェストサーバによって検証中に与えることができる。プル入力は、それら自体によってセッション識別子を発生する。
【0051】
例えば、ユーザＡは公共ＷｅｂＲＴＣプッシュ入力のためのランディングページを開き、ＷｅｂＲＴＣストリームにセッションＩＤが割り当てられる。この例において、ユーザＡは、例えば供給者を示す受容されたビデオ信号とすることができるＷｅｂＲＴＣストリームの供給者である。ストリームＡ１が、オペレータによってストリームＡ１を出力１にルーティングするよう構成された入力に関連付けられるまで、ＬＶＣプラットフォームはセッションＩＤを追跡する。ユーザＡは短い接続損失を経験し、ストリームは終了する。ブラウザクライアントは接続を再確立することができ、これにより新しいストリームＡ２が生じる。セッションＩＤは再接続中に安定しているので、出力１に関するルーティングを評価することができ、ストリームＡ２は出力１にルーティングされる。
【0052】
１つのストリームは１つの入力を参照できると共に、複数のストリームは同一の入力を参照できる。各ストリームは少なくとも１つのストリームＵＲＬを定義するが、１つのストリームには２つ以上のＵＲＬが存在し得る。ストリームＵＲＬはＭＩＭＥタイプの属性を有する。同一のＭＩＭＥタイプには２つ以上のストリームＵＲＬが存在し得る。以下に、２つの使用事例の実施例を示す。
使用事例（ｉ）ストリームＵＲＬｒｔｍｐ：／／ｉｎｇｅｓｔ．ｌｉｖｅ／＿／Ｘ１２３ＺＷ及びｈｔｔｐｓ：／／ｉｎｇｅｓｔ．ｌｉｖｅ／＿／Ｘ１２３ＺＷ／ｔｈｕｍｂｎａｉｌ．ｊｐｇが、同一のストリームに対して存在し得る。一方はライブビデオ信号のため、他方はプレビューサムネイルのためである。
使用事例（ｉｉ）ストリームＵＲＬｒｔｍｐ：／／ｉｎｇｅｓｔ－ａｆ１２３ｈ．ｓｍｔ－ｓｅｒｖｉｃｅｓ．ｃｏｍ／＿／Ｘ１２３ＺＷ及びｒｔｍｐ：／／ｉｎｇｅｓｔ－ｂｆｄｈ７１．ｓｍｔ－ｓｅｒｖｉｃｅｓ．ｃｏｍ／＿／Ｘ１２３ＺＷが、同一のストリームに対して存在し得る。ここで、ストリームは、同一のストリームに対するバックアップであり得る。
使用事例（ｉ）ストリームＵＲＬｒｔｍｐ：／／ｉｎｇｅｓｔ．ｌｉｖｅ／＿／Ｘ１２３ＺＷ及びｈｔｔｐｓ：／／ｉｎｇｅｓｔ．ｌｉｖｅ／＿／Ｘ１２３ＺＷ／ｔｈｕｍｂｎａｉｌ．ｊｐｇが、同一のストリームに対して存在し得る。一方はライブビデオ信号のため、他方はプレビューサムネイルのためである。
使用事例（ｉｉ）ストリームＵＲＬｒｔｍｐ：／／ｉｎｇｅｓｔ－ａｆ１２３ｈ．ｓｍｔ－ｓｅｒｖｉｃｅｓ．ｃｏｍ／＿／Ｘ１２３ＺＷ及びｒｔｍｐ：／／ｉｎｇｅｓｔ－ｂｆｄｈ７１．ｓｍｔ－ｓｅｒｖｉｃｅｓ．ｃｏｍ／＿／Ｘ１２３ＺＷが、同一のストリームに対して存在し得る。ここで、ストリームは、同一のストリームに対するバックアップであり得る。
【0053】
受容された信号に対応する供給ストリームの発行者／所有者のアイデンティティは既知であり得る。発行者が既知である場合、ＤＢＭＳにおいて有効で一意の発行者／所有者ＩＤが参照される。ストリームの一部の供給者は未知であり得る。
【0054】
受容された信号に対応するストリームは、そのオーディオ及びビデオコーデック、フレームレート、及び、場合によっては位置のような、追加のメタデータを含む。このメタデータは、ストリームの寿命中に変化する可能性があり、ストリームの生成に対するタイムスタンプと共にＤＢＭＳに記憶される。メタデータの変化は増分的であり得る。すなわち、ある時点ｔでメタデータキーｘの値が変化した場合、例えばキーｙ、キーｚのように異なるメタデータについて、最新値がｔで存在すると見なされる。例えば、ｔ＋０秒、ｔ＋５秒、．．．、ｔ＋Ｎ秒で、タプル（緯度、経度）を記憶することが望ましい場合がある。あるいは、ＡＩ／ＭＬシステムからの信頼スコアを記憶することが望ましい場合がある。しかしながら、これらの値の変化は、ビデオコーデックのように、以前存在していた他のメタデータが失われたことを意味しない。
【0055】
ルーティングルール
図２０はルーティングルールの実施例を示す。ルーティングルールは、一度供給された信号が受容されてストリームとして抽象化されたら適用されるルールを定義する。ルーティングルールは、対応する述語に基づいて複数のルーティングルールを発生させることができる。同一のターゲットに対する複数のルーティングルールを単一の入力に適用できる。ルーティングルールは、関数ｆ（ストリーム）→ルーティングと見なすことができ、この結果、受容された信号に対して抽象化された所与のストリームのルーティングが得られる。ルーティングルールは、図３に示されているポリシー層を実行することによって明示しなければならない物理ルーティングの所望の状態を引き起こす。ルーティングのため、各ソースは一意に識別可能とすることができる。複数のルーティングルールは同一のソースを参照できる。一実施形態において、ルーティングルールはターゲットを参照する。１つのルーティングルールは多くの述語を含み得る。上述のように、述語は、形態ｆ（ルール、ストリーム）→ブール値（真又は偽）の関数である。ルーティングルールは、述語の指定ブール値条件（真又は偽）が満足されない場合はルーティングを生成しない。
図２０はルーティングルールの実施例を示す。ルーティングルールは、一度供給された信号が受容されてストリームとして抽象化されたら適用されるルールを定義する。ルーティングルールは、対応する述語に基づいて複数のルーティングルールを発生させることができる。同一のターゲットに対する複数のルーティングルールを単一の入力に適用できる。ルーティングルールは、関数ｆ（ストリーム）→ルーティングと見なすことができ、この結果、受容された信号に対して抽象化された所与のストリームのルーティングが得られる。ルーティングルールは、図３に示されているポリシー層を実行することによって明示しなければならない物理ルーティングの所望の状態を引き起こす。ルーティングのため、各ソースは一意に識別可能とすることができる。複数のルーティングルールは同一のソースを参照できる。一実施形態において、ルーティングルールはターゲットを参照する。１つのルーティングルールは多くの述語を含み得る。上述のように、述語は、形態ｆ（ルール、ストリーム）→ブール値（真又は偽）の関数である。ルーティングルールは、述語の指定ブール値条件（真又は偽）が満足されない場合はルーティングを生成しない。
【0056】
ルーティング
図２１は、ストリームのソースをターゲットに接続する場合のルーティングを示す。一例において、ターゲットはＬＶＣプラットフォームの内部又は外部の任意の位置であるが、これは必ずしも出力ではない。例えばターゲットは、受容されたストリームを記録するか又はメタデータに基づいてストリームのエンリッチメントを行うコンポーネントとすることができ、例えば、ストリームの定義された特徴における信頼度の分析のようなＡＩ／ＭＬ決定パラメータに基づくルーティングである。
図２１は、ストリームのソースをターゲットに接続する場合のルーティングを示す。一例において、ターゲットはＬＶＣプラットフォームの内部又は外部の任意の位置であるが、これは必ずしも出力ではない。例えばターゲットは、受容されたストリームを記録するか又はメタデータに基づいてストリームのエンリッチメントを行うコンポーネントとすることができ、例えば、ストリームの定義された特徴における信頼度の分析のようなＡＩ／ＭＬ決定パラメータに基づくルーティングである。
【0057】
信号のソースはインジェストサーバであり得るが、ターゲットは、出力、タイラーエンジン（ｔｉｌｅｒ ｅｎｇｉｎｅ）、スイッチ、ルータ又は内部ノード、例えばレコーダであり得る。ルーティングは、ストリームが出現した場合に自動的に生成され得る。また、ルーティングは、ＬＶＣプラットフォーム内のコンポーネントによって生成され得る。一実施形態において、出力は不変である。すなわちそれらは生成後にアップデートされない。ルーティングは、生成後にユーザによって編集又は削除することができる。
【0058】
ルーティングは、ストリームの一意の識別子又は内部もしくは外部のＵＲＬを有するソースを参照する。例えば、ソースストリームＵＵＩＤ／／９５ａｃ５１ｃ７－９ａｆ１－４９７ｂ－ｂ５４２－０７ｂｅ６４５８ｂ０７１、又はソースＵＲＬｒｔｍｐ：／／ｉｎｇｅｓｔ．ｌｉｖｅ／＿／ＡＢＣ１２３。また、ルーティングは、一意の識別子又はＵＲＬを有する確定可能ターゲットも参照する。例えば、ターゲットＵＵＩＤ／／９５ａｃ５１ｃ７－９ａｆ１－４９７ｂ－ｂ５４２－０７ｂｅ６４５８ｂ０７１、又はターゲットビデオエンジン：／／２３ａｃ５１ｃ７－９ａ１１－４９７ｂ－ｂ５４２－０７ｂｅ６４５８ｂ０７１であり、これは例えば、ソースストリームＵＵＩＤ／／９５ａｃ５１ｃ７－９ａｆ１－４９７ｂ－ｂ５４２－０７ｂｅ６４５８ｂ０７１のタイラーターゲットであり得る。
【0059】
ルーティングの分解
一実施形態によれば、ルーティングは、ソース及びターゲットを分解することによって分解される。ソース参照は、例えば、ＵＲＬ又はインジェストサーバに分解可能であり得る。例えば、ストリームＵＵＩＤは、最終的にＵＲＬ又はインジェストサーバに分解可能であり得る。ＵＲＬはすでに分解ソースと考えられる。また、ターゲット参照もＵＲＬに分解可能である。ＵＵＩＤは最終的に、以下に分解可能である。
・ビデオエンジンが参照される場合、ビデオエンジンのＡＰＩエンドポイントのＵＲＬ。
・プログラムの作成が参照される場合、作成ＡＰＩのＵＲＬ。
・出力が参照される場合、出力ＡＰＩのＵＲＬ。
ターゲットのルーティングは、ルーティングの寿命中に変化し得る作成を参照することができる。
例：出力ｆｏｏは、その作成に付随する限り、作成ｆｏｏを参照することができる。
一実施形態によれば、ルーティングは、ソース及びターゲットを分解することによって分解される。ソース参照は、例えば、ＵＲＬ又はインジェストサーバに分解可能であり得る。例えば、ストリームＵＵＩＤは、最終的にＵＲＬ又はインジェストサーバに分解可能であり得る。ＵＲＬはすでに分解ソースと考えられる。また、ターゲット参照もＵＲＬに分解可能である。ＵＵＩＤは最終的に、以下に分解可能である。
・ビデオエンジンが参照される場合、ビデオエンジンのＡＰＩエンドポイントのＵＲＬ。
・プログラムの作成が参照される場合、作成ＡＰＩのＵＲＬ。
・出力が参照される場合、出力ＡＰＩのＵＲＬ。
ターゲットのルーティングは、ルーティングの寿命中に変化し得る作成を参照することができる。
例：出力ｆｏｏは、その作成に付随する限り、作成ｆｏｏを参照することができる。
【0060】
ルーティングのタイプ
ストリームは、一度現れたらターゲットにルーティングすることができる。そのようなルーティングの一例は、最初に現れた場合にタイラー（セレクタ）アプリケーションにルーティングされるストリームである。オペレータは、基準に基づいてルーティングのための自動化を定義できる。ＤＢＭＳは、ストリームが基準に合致するか否かを評価し、動的に選択され得るターゲットに対するルーティングを生成する。
ストリームは、一度現れたらターゲットにルーティングすることができる。そのようなルーティングの一例は、最初に現れた場合にタイラー（セレクタ）アプリケーションにルーティングされるストリームである。オペレータは、基準に基づいてルーティングのための自動化を定義できる。ＤＢＭＳは、ストリームが基準に合致するか否かを評価し、動的に選択され得るターゲットに対するルーティングを生成する。
【0061】
一例において、ストリームＢはストリームＡのバックアップとして定義される。一度ストリームＡが例えば接続損失のため存在しなくなったら、ストリームＢは自動的にストリームＡのターゲットにルーティングされる。別の例として、オペレータがストリームをルーティングするルールを定義し、「笑顔（ｓｍｉｌｅ）」のようなキーワード等、ＡＩ／ＭＬを適用することから導出されるメタデータに対して最高の信頼スコアを用いることができる。ＡＩ／ＭＬ顔認識を適用して、信頼度が閾値を超えているか否かに基づき、顔（例えば笑顔）の特徴の信頼スコアを含むストリームからのメタデータをルーティングに用いる。
【0062】
また、オペレータは、グラフィカルユーザインタフェースを介して（又はＬＶＣ ＡＰＩを用いて）アクションを実行することにより、ストリームをターゲットにルーティングすることができる。一実施形態において、オペレータは、提示されたユーザインタフェースを用いてストリームを選択し、これを出力にルーティングする。
【0063】
ルーティングプロトコル
ターゲットはルーティングプロトコルを実施する。ターゲットはソースでもある場合がある。例えば、ｇＲＰＣを用いて定義されるルーティングは以下の通りである。
サービスルーティングターゲット｛
／／ソースをこのターゲットに接続
／／
／／実施は冪等でなければならない。ストリームが
／／すでにこのターゲットに接続されている場合、要求は単に無視され
／／既存のトークンが戻される。
／／
／／ターゲットは同一のストリーム＿セッション＿ｉｄの任意のストリームを切断し得る。
／／これは、１つだけの入力を受容しているターゲットに対してのみ適切である。
／／
ｒｐｃ接続（接続要求）が戻る（接続応答）；
／／このターゲットからのソースを切断する
ｒｐｃ切断（切断要求）が戻る（切断応答）；
｝
メッセージ切断要求｛
ストリングルーティング＿ｉｄ＝１； ／／ルーティングの一意の識別子
ストリングソース＿ｕｒｌ＝２； ／／ソースの分解されたｕｒｌ
ストリングストリーム＿セッション＿ｉｄ＝３；／／ストリームの一意のセッション識別子
｝
メッセージ接続応答｛
ストリングトークン＝１； ／／確立された接続を識別する任意のトークン
反復ストリング切断＝２； ／／新たに確立された接続による接続のリスト（各トークン）
｝
メッセージ切断要求｛
ストリングトークン＝１； ／／接続応答によって与えられたトークンと一致しなければならない
｝
メッセージ切断応答｛｝
ターゲットはルーティングプロトコルを実施する。ターゲットはソースでもある場合がある。例えば、ｇＲＰＣを用いて定義されるルーティングは以下の通りである。
サービスルーティングターゲット｛
／／ソースをこのターゲットに接続
／／
／／実施は冪等でなければならない。ストリームが
／／すでにこのターゲットに接続されている場合、要求は単に無視され
／／既存のトークンが戻される。
／／
／／ターゲットは同一のストリーム＿セッション＿ｉｄの任意のストリームを切断し得る。
／／これは、１つだけの入力を受容しているターゲットに対してのみ適切である。
／／
ｒｐｃ接続（接続要求）が戻る（接続応答）；
／／このターゲットからのソースを切断する
ｒｐｃ切断（切断要求）が戻る（切断応答）；
｝
メッセージ切断要求｛
ストリングルーティング＿ｉｄ＝１； ／／ルーティングの一意の識別子
ストリングソース＿ｕｒｌ＝２； ／／ソースの分解されたｕｒｌ
ストリングストリーム＿セッション＿ｉｄ＝３；／／ストリームの一意のセッション識別子
｝
メッセージ接続応答｛
ストリングトークン＝１； ／／確立された接続を識別する任意のトークン
反復ストリング切断＝２； ／／新たに確立された接続による接続のリスト（各トークン）
｝
メッセージ切断要求｛
ストリングトークン＝１； ／／接続応答によって与えられたトークンと一致しなければならない
｝
メッセージ切断応答｛｝
【0064】
ルーティング及びルーティングルール
オペレータによってストリームが出力にルーティングされた場合、ストリームの一意のセッション識別子に対して入力から出力へルーティングルールが入力される。１つの出力ターゲットに１つ以下のルーティングルールが存在する。異なる出力に対して複数のルーティングルールが存在し得る。しかしながら、同一のソース－＞ターゲット関係では１つ以下のルーティングルールが存在する。任意のターゲットのために新しいルーティングルールを生成する場合、例えば異なる入力からの既存のルーティングルールは除去される。
オペレータによってストリームが出力にルーティングされた場合、ストリームの一意のセッション識別子に対して入力から出力へルーティングルールが入力される。１つの出力ターゲットに１つ以下のルーティングルールが存在する。異なる出力に対して複数のルーティングルールが存在し得る。しかしながら、同一のソース－＞ターゲット関係では１つ以下のルーティングルールが存在する。任意のターゲットのために新しいルーティングルールを生成する場合、例えば異なる入力からの既存のルーティングルールは除去される。
【0065】
ルーティングルールの評価及び再評価
ルーティングルールの評価は、全ての述語を試験することと、所与のルーティングルールのためのターゲットのセットを構築することと、ターゲットを関連したルーティングにマッピングすることと、を含み得る。任意のルーティングルール、ルーティングルールのターゲット、又は入力が生成、アップデート、又は削除された場合、入力の状態（例えばオンライン又はオフライン）とは無関係に、ルーティングルールが評価される。再評価は次の場合に実行され得る。
（１）作成の参照されたターゲットが変化した場合、
（２）参照されたターゲットがアップデート又は削除された場合、
（３）ルーティング関連の前提条件が変化した場合、
（４）入力の前提条件が変化した場合、
（５）入力の状態が変化した場合、
（６）ルーティングルールが入力に追加された場合、及び
（７）ルーティングルールが入力から除去された場合。
ルーティングルールの評価は、全ての述語を試験することと、所与のルーティングルールのためのターゲットのセットを構築することと、ターゲットを関連したルーティングにマッピングすることと、を含み得る。任意のルーティングルール、ルーティングルールのターゲット、又は入力が生成、アップデート、又は削除された場合、入力の状態（例えばオンライン又はオフライン）とは無関係に、ルーティングルールが評価される。再評価は次の場合に実行され得る。
（１）作成の参照されたターゲットが変化した場合、
（２）参照されたターゲットがアップデート又は削除された場合、
（３）ルーティング関連の前提条件が変化した場合、
（４）入力の前提条件が変化した場合、
（５）入力の状態が変化した場合、
（６）ルーティングルールが入力に追加された場合、及び
（７）ルーティングルールが入力から除去された場合。
【0066】
オペレータによって１つのストリームｓｅｘｐが出力ｏｅｘｐにルーティングされた場合、関連付けられた入力に対して関連するルーティングルールは（ストリーム＝ｓｅｘｐ、ターゲット＝出力：／／ｏｅｘｐ）になる。オペレータが入力を異なる作成Ｐｎｅｗに移動することを決定した場合、入力はＰｏｌｄから除去される。このアクションの結果、入力に対する全てのルーティングルールの再評価が行われる。従ってＤＢＭＳは、以下を実行することによって現在のルーティングの再評価と新しいルーティングの評価を実行する。
１．ルーティングルールの変化を実行し、Ｐｏｌｄを除去し、Ｐｎｅｗを追加する
２．入力及びコンテキストに対する全ての現在のルーティングをロードし、ルーティングＲｏｌｄを参照する
３．入力状態がオンラインである場合、全ての残りのルーティング関係を評価し、入力がオフラインである場合、結果として得られるルーティングＲｏｌｄ．Ｒｎｅｗイコール｛｝のセットをコールする
４．共通集合Ｒｏｌｄ∩Ｒｎｅｗにおけるルーティングを無視することができる
５．異なるセットＲｏｌｄ＼Ｒｎｅｗ、Ｒｏｌｄ内にあるがＲｎｅｗ内に無い全てのルーティングのセット内の各ルーティングを削除する
６．異なるセットＲｎｅｗ＼Ｒｏｌｄ、Ｒｎｅｗ内にあるがＲｏｌｄ内に無い全てのルーティングのセット内の各ルーティングを削除する
７．コンテキスト情報を持たないルーティングは変化しない。
１．ルーティングルールの変化を実行し、Ｐｏｌｄを除去し、Ｐｎｅｗを追加する
２．入力及びコンテキストに対する全ての現在のルーティングをロードし、ルーティングＲｏｌｄを参照する
３．入力状態がオンラインである場合、全ての残りのルーティング関係を評価し、入力がオフラインである場合、結果として得られるルーティングＲｏｌｄ．Ｒｎｅｗイコール｛｝のセットをコールする
４．共通集合Ｒｏｌｄ∩Ｒｎｅｗにおけるルーティングを無視することができる
５．異なるセットＲｏｌｄ＼Ｒｎｅｗ、Ｒｏｌｄ内にあるがＲｎｅｗ内に無い全てのルーティングのセット内の各ルーティングを削除する
６．異なるセットＲｎｅｗ＼Ｒｏｌｄ、Ｒｎｅｗ内にあるがＲｏｌｄ内に無い全てのルーティングのセット内の各ルーティングを削除する
７．コンテキスト情報を持たないルーティングは変化しない。
【0067】
事実上、ルーティングルール（ストリーム＝ｓｅｘｐ、ターゲット＝出力：／／ｏｅｘｐ）が最初に削除される。これは出力が作成に関連するからである。しかしながら、作成はもはやルーティングルールのリスト内に存在しない。もはや有効でない全てのルーティング、例えば出力のためのルールから生じたルーティングは、切断される。最後に、例えば新しいタイラーに対する新しいルーティングを生成することができる。
【0068】
以下の再評価アルゴリズムを用いて、現在の状態又はルーティングから所望のルーティングの状態にマッピングすることができる。
（１）ターゲットとして作成を有するルールから、参照された作成のセットを構築する
（２）再評価されている入力について全てのストリームをフェッチする
（３）各ストリームを入力の述語に対してマッチングし、一致しないものを捨てる
（４）（１）からのセット内に存在しない作成参照を有する全てのルールを除去する
（５）入力を参照し、（１）からのセット内に存在するコンテキストを有する全てのルーティングをフェッチする
（６）入力がオンラインであると仮定して、各ストリームの各ルールを評価することにより新しいルーティングのセットを構築する。入力がオンラインでない場合、空のセットを用いる。
（７）（５）からのセットに存在するが（６）には存在しない全てのルーティングを切断する
（８）（６）からのセットに存在するが（５）には存在しない全てのルーティングを接続する
（１）ターゲットとして作成を有するルールから、参照された作成のセットを構築する
（２）再評価されている入力について全てのストリームをフェッチする
（３）各ストリームを入力の述語に対してマッチングし、一致しないものを捨てる
（４）（１）からのセット内に存在しない作成参照を有する全てのルールを除去する
（５）入力を参照し、（１）からのセット内に存在するコンテキストを有する全てのルーティングをフェッチする
（６）入力がオンラインであると仮定して、各ストリームの各ルールを評価することにより新しいルーティングのセットを構築する。入力がオンラインでない場合、空のセットを用いる。
（７）（５）からのセットに存在するが（６）には存在しない全てのルーティングを切断する
（８）（６）からのセットに存在するが（５）には存在しない全てのルーティングを接続する
【0069】
ルーティング管理の例
この例では、以下の基準が仮定される。
（１）入力Ａは、受容されたストリームを作成Ａにルーティングするルールを有する
（２）作成Ａは、タイラーＡに対する入来接続のためのルーティングを生成する
（３）再評価が実行される
この例では、以下の基準が仮定される。
（１）入力Ａは、受容されたストリームを作成Ａにルーティングするルールを有する
（２）作成Ａは、タイラーＡに対する入来接続のためのルーティングを生成する
（３）再評価が実行される
【0070】
この例では、基準（１）に基づいて、作成Ａに対する入来ストリームのための暗黙のルーティングが生成される。これらのルーティングは、コンテキストとして作成ＡのＵＵＩＤを受信する。ストリームが作成Ａにルーティングされた場合、ルーティングを受信するサービスは、基準（２）に基づいてタイラーＡに対するストリームのための新しいルーティングを生成する。ルーティングは入力によって生成されないのでもはやルーティングでなく、コンテキスト情報は付随しない。
【0071】
次いで、基準（３）に基づいて再評価を実行する。一度再評価を実行したら、作成からタイラーへの対応するルーティングは、作成から除去された場合に除去される。作成によって生成されたタイラーへのルーティングを無視することで、対応するルーティングが作成に対してアクティブのままである場合、タイラーへのルーティングは除去されない。入力によって直接生成されないルーティングは、再評価中に無視される。作成のためのルーティングを処理するサービスは、サービスによってストリームが切断されていると決定した場合、タイラーからの対応するストリームを切断していることが想定される。一方で、接続は冪等動作である、すなわち、無限の回数だけ実行され得る動作であり、状態は同一であるので、同一のルーティングを２度生成しない。
【0072】
ターゲットのルーティングルールは、間接的に作成を参照することができる。この参照は、ルーティングルールの寿命中に変化し得る。
【0073】
例：出力ｆｏｏは、その作成に付随する限り作成ｆｏｏを参照し、ルーティング＿ルールｐｒｏｄｕｃｔｉｏｎは、作成ｆｏｏに関連付けられる。
【0074】
一実施形態において、ＬＶＣプラットフォームは以下の非網羅的な入力タイプの例をサポートする。
１：ＲＴＭＰプッシュ入力；
２：公共／民間ＷｅｂＲＴＣプッシュ；
３：ＨＬＳプル
１：ＲＴＭＰプッシュ入力；
２：公共／民間ＷｅｂＲＴＣプッシュ；
３：ＨＬＳプル
【0075】
ＲＴＭＰプッシュ入力は、１：１関係で単一の供給ストリームに対するエンドポイントを事前に定義する。エンドポイントは、ｒｔｍｐ：／／ｉｎｇｅｓｔ．ｌｉｖｅ／ｉ／ＸＹＺ１２３のような形態を有する。ＲＴＭＰプッシュ入力は、ユーザ又はチームのいずれかによって所有される外部デバイスとすることができる。ＲＴＭＰプッシュ入力は、ストリームが同一のセッションＩＤについて現在アクティブであると見なされる場合、ストリームが現在のビデオ信号を置換することを可能としない。例えばＲＴＭＰプッシュ入力は、ＩＰ範囲に基づいて信号を受容するための述語をサポートすることができる。
【0076】
公共ＷｅｂＲＴＣプッシュは、例えば関連付けられた入力が多くのストリームを生じ得る１：Ｎ関係で、ＷｅｂＲＴＣエンドポイントと、供給者がストリームを開始するために使用できるランディングページと、の双方を定義することができる。公共ＷｅｂＲＴＣ入力は、単一の供給者でなく、供給者のチームによって所有され得る。一実施形態において、公共ＷｅｂＲＴＣ入力は、例えば供給者の現在の位置に基づいて信号を受容するための述語をサポートする。民間及び公共ＷｅｂＲＴＣプッシュは、潜在的に同一の入力タイプであり得る。民間ＷｅｂＲＴＣプッシュは追加の述語を定義することができ、これは例えば、供給者が存在すると共に特定のチームのメンバでなければならないというものである。一方で、ＨＬＳプル入力は単一のユーザでなくチームによって所有される。
【0077】
ストリームは記録することができる。ストリームが記録されるか否かは、その寿命中に変化し得る。記録されていないストリームは失われ、回復できない。ＭＩＭＥタイプに基づいてストリームのＵＲＬを選択することができる。ＬＶＣプラットフォームの一実施例は、所与のＭＩＭＥタイプについてストリームＵＲＬのサブセットを構築する。結果として得られるセットが２つ以上の入力を含む場合、ラウンドロビン負荷バランシングを用いてランダムに結果が選択される。
【0078】
図２２は、ＬＶＣプラットフォームのエンティティ間のフロー図の例を示す。図示のように、クラウド内部のデバイスという名称の外部関係者はインジェストサーバに接続し（１）、インジェストサーバは入力を介して接続を有効にする（２）。例えばＷｅｂＲＴＣプッシュ入力のような入力が受容されると仮定すると、これは新しいストリームを生成してこれをＬＶＣプラットフォームに知らせる（３）。一度ルーティング関係が評価されたら（４）、受容されたストリームに対して、３つのルーティング、すなわち出力、作成、又はレコーダに対するルーティングが適用される（５）。
【0079】
図２３は、ＬＶＣプラットフォームで論理により実施される方法において本発明の一実施形態を実施することを例示するフローチャートを示す。図示のように、ＬＶＣプラットフォームは、汎用一意発行者ＩＤによって識別されるプログラムの発行者／所有者のオペレータにログインインタフェースを提供する。オペレータは、公共又は民間ストリームを供給する個人又はグループ／チームを生成し管理する。オペレータは、ストリームを識別する入力を生成し、供給された信号を受容又は拒否するための述語論理を関連付ける。承認制御プロセスは、ユーザ／オペレータ定義述語に基づいてこのような信号を識別する入力論理に基づいて、供給された信号を受容する。決定論理は、承認制御述語をチェックして、ユーザ定義述語に基づいて真又は偽を決定する。この決定に基づいて、供給された信号は拒否又は受容される。ある論理は、関連した述語が真である場合は信号を受容し、関連した述語が偽である場合は信号を拒否することができる。反対の論理は、関連した述語が偽である場合は信号を受容し、関連した述語が真である場合は信号を拒否することができる。一実施形態では、ＬＶＣプラットフォームにアクセスするオペレータによって論理選択を行う。このようなオペレータは、受容されたストリームに適用されるルーティングルールに基づいて入力のルーティングを指定する。一例において、オペレータはソースから宛先へのルーティングのために述語を指定する。全てのオペレータによって指定されたか又は他の方法で生成された入力、ルーティング、入力及びルーティング述語、並びにプログラム変換パラメータは、図２に示されているＤＢＭＳに記憶される。述語をチェックするには、述語を検索し、それらを、ルーティングルールに基づく受容ストリームをプログラム変換に基づく出力にルーティングするための承認制御及びルーティング論理プロセスに与える。
【0080】
ここに記載されているシステム及び技法の様々な実施例は、デジタル電子回路、集積回路、特別に設計されたＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ：特定用途向け集積回路）、コンピュータハードウェア、ファームウェア、ソフトウェア、及び／又はそれらの組み合わせで実現され得る。これらの様々な実施例は、プログラマブルシステム上で実行可能及び／又は解釈可能である１つ以上のコンピュータプログラムにおける実施例を含み得る。プログラマブルシステムは、ストレージシステムからデータ及び命令を受信すると共にストレージシステムにデータ及び命令を送信するように結合された特殊用途又は汎用であり得る少なくとも１つのプログラマブルプロセッサと、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスと、を含む。
【0081】
これらのコンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、又はコードとしても知られる）は、プログラマブルプロセッサのための機械命令を含み、高レベル手続き型言語及び／又はオブジェクト指向プログラミング言語及び／又はアセンブリ／機械言語で実施され得る。本明細書で用いられる場合、「機械可読媒体」及び「コンピュータ可読媒体」という用語は、機械命令及び／又はデータをプログラマブルプロセッサに提供するために用いられる任意のコンピュータプログラム製品、装置、及び／又はデバイス（例えば磁気ディスク、光ディスク、メモリ、プログラマブル論理デバイス（ＰＬＤ：Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ））を表し、機械命令を機械可読信号として受信する機械可読媒体を含む。「機械可読信号」という用語は、命令及び／又はデータをプログラマブルプロセッサに提供するために用いられる任意の信号を表す。
【0082】
ユーザとの相互作用を可能とするため、ここに記載されているシステム及び技法は、ユーザに情報を表示するためのディスプレイデバイス（例えばＣＲＴ（ｃａｔｈｏｄｅ ｒａｙ ｔｕｂｅ：ブラウン管）又はＬＣＤ（ｌｉｑｕｉｄ ｃｒｙｓｔａｌ ｄｉｓｐｌａｙ：液晶ディスプレイ）モニタ）と、ユーザがコンピュータに入力を提供できるキーボード及びポインティングデバイス（例えばマウス又はトラックボール）と、を有するコンピュータ上で実施され得る。ユーザとの相互作用を可能とするために他の種類のデバイスを使用することも可能である。例えば、ユーザに提供されるフィードバックは、任意の形態の感覚フィードバック（例えば視覚フィードバック、聴覚フィードバック、又は触覚フィードバック）とすることができ、ユーザからの入力は、音響、音声、又は触覚入力を含む任意の形態で受信できる。
【0083】
ここに記載されているシステム及び技法は、バックエンドコンポーネント（例えばデータサーバ）を含むか、又はミドルウェアコンポーネント（例えばアプリケーションサーバ）を含むか、又はフロントエンドコンポーネント（例えば、ここに記載されているシステム及び技法の実施例とユーザが相互作用できるグラフィカルユーザインタフェースもしくはウェブブラウザを有するクライアントコンピュータ）を含む、又はそのようなバックエンド、ミドルウェア、もしくはフロントエンドコンポーネントの任意の組み合わせを含むコンピューティングシステムで実施することができる。システムのコンポーネントは、デジタルデータ通信の任意の形態又は媒体（例えば通信ネットワーク）によって相互接続できる。通信ネットワークの例は、ローカルエリアネットワーク（「ＬＡＮ」）、ワイドエリアネットワーク（「ＷＡＮ」）、及びインターネットを含む。
【0084】
コンピューティングシステムは、多様なプログラム作成ニーズを満たすため、例えば上述の入力、ストリーム、ルーティング、及び出力のような論理エンティティを実行する複数のスケーラブルプロセッサを含むクラウドで実施されたスケーラブルサーバを含み得る。例えば、供給信号の数が増えるにつれて、記載されている論理エンティティを実施するため、より多くのプロセッサを展開することができる。クライアント及びサーバは、一般に相互に遠く、典型的に通信ネットワークを介して相互作用する。クライアントとサーバの関係は、コンピュータプログラムが各コンピュータ上で実行し、クライアントとサーバの相互の関係を有することによって生じる。
【0085】
前述の記載は、本開示と一致する全ての可能な実施例又は記載されている実施例の全ての可能な変形の網羅的なリストを表していない。多数の実施例が記載されている。それにもかかわらず、ここに記載されているシステム、デバイス、方法、及び技法の精神及び範囲から逸脱することなく、様々な変形が可能であることは理解されよう。例えば、上記のフローの様々な形態を使用し、ステップの並べ替え、追加、又は除去を行うことができる。従って、他の実施例は以下の特許請求の範囲の範囲内である。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【手続補正書】
【提出日】2024-03-13
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
１つ以上のソースから通信チャネルを介して受信された信号を用いるプログラムを作成するためのコンピューティングシステムにおいて実行される方法であって、ａ）前記コンピューティングシステムの１つ以上のサーバでアプリケーションソフトウェアを実行するステップであって、前記１つ以上のサーバのうち少なくとも１つは、定義された論理エンティティを処理する１つ以上のプロセッサを有し、各論理エンティティはストレージシステムに格納された対応するデータ構造によって表され、前記データ構造は機能アクティビティを実行するために使用される、ステップと、
ｂ）ソースから通信チャネルを介してプログラムの作成に用いられる信号を受信するステップと、
ｃ）前記信号のルーティングに使用される属性を定義する第１のデータ構造を含む入力論理エンティティを定義するステップであって、前記入力論理エンティティは、前記信号を受容又は拒否するために用いられる論理表現を含むユーザ定義述語に応答する、ステップと、
ｄ）受容された信号を識別するために用いられる第２のデータ構造を含むストリーム論理エンティティを定義するステップと、
ｅ）宛先への接続を確立するルーティング論理エンティティを定義するステップと、
ｆ）前記受容された信号をルーティングに使用される前記属性に基づいて前記受容された信号を前記宛先にルーティングするステップと、
を含む方法。
【請求項2】
前記ストリーム論理エンティティを前記宛先に関連付ける第４のデータ構造を含む出力論理エンティティを定義するステップを更に含む、請求項１に記載の方法。
【請求項3】
前記出力論理エンティティは、前記受容された信号を前記宛先にマッピングするために評価されるユーザ定義プログラム変換ルールに従って前記ストリーム論理エンティティを変換する、請求項２に記載の方法。
【請求項4】
前記信号はＭＰＥＧ信号であり、前記ユーザ定義プログラム変換ルールはプログラム特定情報（ＰＳＩ）に基づく、請求項３に記載の方法。
【請求項5】
前記ストリーム論理エンティティはパケット化エレメンタリストリーム（ＰＥＳ）に関連付けられている、請求項４に記載の方法。
【請求項6】
前記ＰＳＩはプログラムマッピングテーブル（ＰＭＴ）を含み、前記ストリーム論理エンティティはＰＭＴに関連付けられている、請求項５に記載の方法。
【請求項7】
前記ＭＰＥＧ信号のパケットの到着間時間（ＩＡＴ）はサーバで記録され、一定のビットレートを達成するため前記出力論理エンティティによって用いられる、請求項４に記載の方法。
【請求項8】
前記ルーティングルールは前記入力論理エンティティに関連付けられたユーザ定義の論理ルールであり、前記信号が前記入力論理エンティティに与えられた場合にユーザ定義の論理ルールが評価される、請求項１に記載の方法。
【請求項9】
前記ユーザ定義述語は、時刻、地理領域、位置、又はＩＰアドレスに基づく、請求項１に記載の方法。
【請求項10】
前記入力論理エンティティはユーザによって永続論理エンティティとして定義される、請求項１に記載の方法。
【請求項11】
前記入力論理エンティティはグラフィカルユーザインタフェース又はアプリケーションプログラミングインタフェース（ＡＰＩ）を介して前記ユーザによって構成される、請求項１０に記載の方法。
【請求項12】
前記ストリーム論理エンティティは、局所接続を生成するセッションタグに関連付けられている、請求項１に記載の方法。
【請求項13】
前記ストリーム論理エンティティは前記信号の所有者又は発行者の一意の識別（ＩＤ）に関連付けられている、請求項１に記載の方法。
【請求項14】
信頼度に基づいて前記信号の特徴を認識し、前記認識した特徴を前記信号に関連付けられたメタデータとして用いることを更に含む、請求項１に記載の方法。
【国際調査報告】