JP7150631B2 - 制御装置、サービス提供システム、制御方法、及びプログラム - Google Patents

Description

本発明は、ネットワークを介してユーザにサービスを提供するための技術に関連するものである。

ネットワークを介してユーザに提供されるサービスとして、映像、音声等のメディアストリームに関する種々のサービスが普及している。

一般に、メディアストリームを処理するシステムは、各コンポーネントが密結合した大きなソフトウェアからなる。各コンポーネントが密結合した大きなソフトウェアの開発には相当な時間を要する。

近年、機械学習技術等の台頭によりメディア解析技術が増え、メディアデータのストリームを用いたユースケースが多様化し、それに追従して、拡張性の高い、より早いシステム開発が求められている。

Real Time Streaming Protocol (RTSP)、https://tools.ietf.org/html/rfc2326

拡張性の高い、早いシステム開発を指向した従来技術として、サービス全体の機能を処理内容毎に複数のコンポーネントに分割するマイクロサービスがある。

しかし、メディアストリームを処理するシステムにマイクロサービスを適用する場合、コンポーネント間でやりとりするメディアストリームのライフサイクルが長いために、ストリームの状態に応じて、それぞれのコンポーネントのステートを管理するオーケストレーション機能が必要となる。

また、オーケストレーション機能により管理すべきコンポーネント及びそのステートが増えることで、システムの複雑性が増してしまう結果、拡張性が低くくなってしまう。また、システム開発にも時間がかかってしまう。なお、このような課題はメディアストリーム以外のデータ通信にも生じ得る課題である。

本発明は上記の点に鑑みてなされたものであり、１つ又は複数のコンポーネントによりサービスを提供するシステムにおいて、コンポーネントの管理を簡易化することを可能とする技術を提供することを目的とする。

開示の技術によれば、複数のコンポーネントによりサービスを提供するネットワークにおいて、前記複数のコンポーネントに対する制御を実行する制御装置であって、
メディアストリームのセッションを開始する開始要求を検知した場合に、メディアゲートウェイを含む前記複数のコンポーネントを作成し、前記メディアストリームのセッションの終了要求を検知した場合に、前記複数のコンポーネントを削除する制御部を備え、
前記制御装置は、ユーザ毎の設定情報を記憶するデータ記憶部を更に備え、
前記制御部は、前記開始要求の送信元のユーザの設定情報を参照することにより、作成する前記複数のコンポーネントを決定する
制御装置が提供される。

開示の技術によれば、１つ又は複数のコンポーネントによりサービスを提供するシステムにおいて、コンポーネントの管理を簡易化することを可能とする技術が提供される。

本発明の実施の形態の概要を説明するための図である。 本発明の実施の形態におけるシステムの構成例を示す図である。 システムの動作を示すシーケンス図である。 オーケストレーション装置の機能構成図である。 装置のハードウェア構成例を示す図である。 オーケストレーション装置の動作例を示すフローチャートである。

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

なお、本実施の形態では、音声や映像といったメディアデータのストリーム処理を例に説明しているが、本発明はメディアデータではないストリームデータの処理にも適用可能である。また、本発明はストリームデータではないデータの処理にも適用可能である。

（課題について）
本発明に係る技術を説明するにあたり、その課題に関してより詳細に説明する。

メディア（映像／音声）ストリームデータを処理するシステム開発において、これまでは各コンポーネントが密結合した大きなソフトウェアで作り上げてきていた。また、ＧｓｔｒｅａｍｅｒなどのＰｌｕｇｉｎ方式の台頭によって、メディアデータのエンコード／デコード処理内容を変更するといったシステム拡張がしやすくなっている。

また、ＲＴＳＰプロトコルによって、クライアントがサーバからストリームデータを受信する際のメディアデータのメタデータ等についてのネゴシエーションが標準化されており、プロセスを分けて、ストリームデータを処理するパターンでシステムが実装されてきた。

既に説明したように、機械学習技術などの台頭によりメディア解析技術が増え、メディアデータのストリームを用いたユースケースが多様化し、それに追従してより早いシステム開発が求められるようになったが、従来技術において以下に述べる課題があり、多様な処理を組み合わせて、拡張性が高く、安定したストリーム処理システムを実現するのが困難であった。

上述したＰｌｕｇｉｎ方式では、それぞれのコンポーネントが密結合してしまうゆえに、増加するモジュール間の依存関係によって拡張が困難となってしまう。そのたゆ、プロセスを分けたシステム実装を組み合わせる必要がでてくる。

プロセスを分けたシステム実装を組み合わせる技術として、ストリーム処理内容ごとにコンポーネントを分割するマイクロサービスがある。しかし、マイクロサービス化をした場合、一般的にマイクロサービスのコンポーネント間で利用されるＲＥＳＴやＲＰＣと違い、コンポーネント間でやりとりするストリームのライフサイクルが長いために、ストリームの状態に応じて、それぞれのコンポーネントのステートを管理するオーケストレーション機能が必要となる。既に説明したように、管理するコンポーネントおよぴステートが増えることでシステムの複雑性が増してしまう結果、拡張性が低くくなってしまう。

また、従来技術では、クライアント・サーバ間のやりとり（ネゴシエーション）にオーバーヘッドがあり、クライアント又はサーバプロセスの障害時に、ストリームの復旧に時間がかかり、可用性が小さくなってしまう。また、ネゴシエーション後にメタデータを更新するにはセッションを一度切断する必要があり、伸縮性が小さい。

また、従来技術では、ＲＴＳＰで規格化されているフォーマットでのメタデータのやり取りしかできず、例えばＡＩで解析結果をストリームデータに付与するなどといった、メディア処理用に規格化されたフォーマットの範囲外のデータを付与することができない。その結果、多様なユースケースを実現するためにＲＴＳＰだけでは疎結合にコンポーネントを実装することができず、拡張性が低くなってしまう。以下、これらの課題を解決する技術として、本発明の実施の形態を説明する。

（実施の形態の概要）
本実施の形態では、下記の要素技術１、要素技術２により、マイクロサービスアーキテクチャにおけるストリーム処理に対して、自律分散性・疎結合性を導入することで、拡張性及び可用性の高いマイクロサービスを実現している。

要素技術１（ライフサイクル管理）：コンポーネントの作成・削除ライフサイクルをストリームセッションのライフサイクルに合わせ、セッションイベントに応じてオーケストレータによるコンポーネントの作成／削除を実行する。ここで、各コンポーネントはストリームデータごとに作成され、複数のストリームを処理する場合、その数だけコンポーネントを作成する。

要素技術２（データフォーマット）：送受信するストリームデータ自体にメタデータを同時に付与できるようデータフォーマットを定義することで、ＲＴＳＰのようにネゴシエーション時にメタデータを解決するのではなく、各コンポーネントがストリーム処理中に、同時に送付されるメタデータ情報を取り出し計算することで、自律的かつ動的にメタデータを解決できるようにしている。また、メタデータの中身については、各コンポーネントの実装者が自由に設計できるようにしている。すなわち、同じシステム内に閉じるマイクロサービス間のインタラクションであるため、ＲＴＳＰのような厳格なネゴシエーションやフォーマットを必要としない。また、実装例としてｇＲＰＣ Ｓｔｒｅａｍを使用することができるが、ｇＲＰＣ Ｓｔｒｅａｍを使用することは一例である。

図１に、本発明の実施の形態の概要を表すシステム構成を示す。本実施の形態では、所望のサービスのための機能（図１の例ではメディアストリーム処理に係る機能）を疎結合したマイクロサービスに分解する。図１では、所望の機能を分解してできたメディア処理のコンポーネントがＧａｔｅｗａｙ１（ゲートウェイ機能１）、Ｄｅｃｏｄｅ２（デコード機能２）、Ｗｒｉｔｅ３（書き込み機能３）として示されている。

また、Ｏｒｃｈｅｓｔｒａｔｉｏｎ１００（オーケストレーション装置１００）が備えられている。オーケストレーション装置１００は、メディアセッションのライフサイクルを各コンポーネントに適用し、セッションのライフサイクルイベント毎に各コンポーネントを作成／削除（ｓｐａｗｎｅｄ／ｔｅｒｍｉｎａｔｅｄ）するようにしている。なお、本明細書において、「削除」を「終了」、「停止」等と言い換えてもよい。

これにより、各コンポーネントが互いに異なる機能を有する場合でも、オーケストレーション装置１００は、各コンポーネントに同じアクションを実行するだけでよいので、サービスを提供するコンポーネントの管理が簡易化される。

また、図１のシステムでは、メディア固有のストリーミングフォーマットを導入し、メディアストリームとともにメディアのメタデータを送信可能としている、これにより、各コンポーネントは、メタデータから動的にメディアの属性（ｍｅｄｉａ ｃａｐａｂｉｌｉｔｙ）を把握できる。すなわち、各コンポーネントは、外部に依存することなく（ネゴシエーション等をすることなく）、受信したメタデータから自身でメディアフォーマットを決定できる。

なお、本実施の形態では、サービス提供のために複数のコンポーネントを作成することとしているが、コンポーネントの数は１つでもよい。また、サービス提供のために作成される１つ又は複数のコンポーネントの全てが要素技術２の機能を備えてもよいし、当該１つ又は複数のコンポーネントのうちのいずれか１つ又は複数が要素技術２の機能を備えてもよい。また、オーケストレーション装置１００を制御装置と称してもよい。また、本実施の形態の技術をマイクロサービスによるストリーム処理パイプラインと称してもよい。

（システム構成）
図２は、本実施の形態におけるシステム構成の例を示す図である。本システムにおいて、メディアストリームの送信を行うユーザ端末１０がネットワーク２００に接続される。なお、ネットワーク２００は、クラウドであってもよい。ネットワーク２００上の各要素の機能概要は下記のとおりである。

図２に示すように、ネットワーク２００上には、ユーザエンドポイント２０、イベントハブ３０、オーケストレーション装置１００、メディアＧＷ（ゲートウェイ）４０、トランスコーディング機能５０、カスタム機能６０が備えられる。

ユーザエンドポイント２０は、ユーザ端末１０からの接続要求を受け付け、接続イベントを発出する。イベントハブ３０は、受信したイベントをオーケストレーション装置１００に通知する。オーケストレーション装置１００は、メディアストリームのセッションのライフサイクルに合わせてコンポーネントの作成・終了を実行する。なお、ここでの「セッション」は、ユーザにより要求され、当該ユーザに提供される「サービス」と称してもよい。

図２に示す例では、オーケストレーション装置１００は、コンポーネントとして、メディアＧＷ４０、トランスコーディング機能５０、カスタム機能６０を作成する。なお、コンポーネントを作成するとは、具体的には、当該コンポーネントが動作するコンピュータにおける、当該コンポーネントの動作を実行するプログラムを起動することに相当する。また、複数コンポーネントが同一コンピュータ上で動作してもよい。

メディアＧＷ４０はメディアデータの送受信を行う。トランスコーディング機能５０は、ある方式で符号化されたメディアデータを別の符号化方式で符号化されたメディアデータに変換する。カスタム機能６０は、例えば、メディアデータをファイルに書き込む。また、メディアＧＷ４０、トランスコーディング機能５０、カスタム機能６０は、それぞれ、要素技術２として、メタデータを作成する機能、メディアデータにメタデータを付加して送付する機能、受信したメタデータを解釈する機能を備える。

ユーザエンドポイント２０、イベントハブ３０、オーケストレーション装置１００、メディアＧＷ（ゲートウェイ）４０、トランスコーディング機能５０、カスタム機能６０は、それぞれサーバ等のコンピュータ及びプログラムで実現されてもよいし、これらのうちの任意の複数が１つのコンピュータ及びプログラムで実現されてもよい。また、本明細書で述べる「コンピュータ」は、物理マシンであってもよいし、仮想マシンであってもよい。

（システムの動作例）
次に、図２に示すシステムにおけるセッション開始時及び終了時の動作例を、図３のシーケンス図を参照して説明する。ここでは、要素技術１として、Ｃｏｎｎｅｃｔイベント（開始要求を示すイベント）をもとに、コンポーネントを作成し、Ｄｉｓｃｏｎｎｅｃｔイベント（終了要求を示すイベント）をもとに、コンポーネントの削除を行っている。また、要素技術２として、メディアＧＷ４０において、クライアントから送られてきたストリームデータに、メディアフォーマットを示す情報等のメタデータを付与して、後続のＦｕｎｃｔｉｏｎに送信している。

なお、図２に示したユーザ端末１０、ユーザエンドポイント２０、イベントハブ３０、オーケストレーション装置１００、メディアＧＷ（ゲートウェイ）４０、トランスコーディング機能５０、カスタム機能６０をそれぞれ、図３では、Ｕｓｅｒ１０、Ｕｓｅｒ Ｅｎｄｐｏｉｎｔ２０、Ｅｖｅｎｔ Ｈｕｂ３０、Ｏｒｃｈｅｓｔｒａｔｉｏｎ１００、Ｍｅｄｉａ ＧＷ４０、Ｔｒａｎｓｃｏｄｉｎｇ Ｆｕｎｃｔｉｏｎ５０、Ｃｕｓｔｏｍ Ｆｕｎｃｔｉｏｎ６０と表記している。

Ｓ１（ステップ１）において、ユーザ端末１０は接続要求を送信する。この接続要求は、メディアストリーム（メディア通信）のセッション（サービス）を開始することの要求に相当する。

接続要求を受信したユーザエンドポイント２０は、Ｓ２において、接続イベントをイベントハブ３０に送信する。Ｓ３において、イベントハブ３０は、接続イベントをオーケストレーション装置１００に通知する。

接続イベントとしてオーケストレーション装置１００に通知される情報には、例えば、ユーザ端末１０あるいはユーザを識別するユーザ識別情報、セッションを開始することを示す情報（つまり、セッションのライフサイクルが開始することを示す情報）が含まれる。

オーケストレーション装置１００には、ユーザ端末１０がどのコンポーネントを使用するかを示す設定情報（定義情報と称してもよい）が予め格納されている。Ｓ３の通知を受けたオーケストレーション装置１００は、ユーザ端末１０によるセッション開始要求があったことを把握し（ライフサイクルが開始されることを把握し）、設定情報を参照することで、メディアＧＷ４０、トランスコーディング機能５０、カスタム機能６０を作成することを決定し、これらを作成（Ｓｐａｗｎ）する（Ｓ４～Ｓ６）。

具体的には、例えば、メディアＧＷ４０の処理を実行するプログラムを備えるコンピュータに対し、当該プログラムを起動させる命令を送信する。トランスコーディング機能５０、カスタム機能６０についても同様である。後述するように、メディアＧＷ４０、トランスコーディング機能５０、カスタム機能６０はそれぞれメタデータを処理する機能を含んでおり、作成（Ｓｐａｗｎ）において、当該メタデータを処理する機能のプログラムも起動される。

メディアＧＷ４０、トランスコーディング機能５０、カスタム機能６０のそれぞれにおいて、スタートアップのための処理が実行される（Ｓ７～Ｓ１０）。特に、メディアＧＷ４０については、ユーザ端末１０とメディアデータの送受信のための接続を確立するための処理が実行される（Ｓ９、Ｓ１０）。

Ｓ１１において、ユーザ端末１０はメディアデータを送信する。メディアデータは連続的に送られるので、その流れを「ストリーム」と呼ぶ。

メディアＧＷ４０は、例えば、メディアストリーム（の個々のメディアデータ）を解析し、当該メディアストリームにおけるメディアの情報（符号化方式等）を把握し、当該情報を表すメタデータをメディアストリームに付加し、メタデータが付加されたメディアストリームをトランスコーディング機能５０に送信する（Ｓ１２）。

上述したように、メディアストリームはメディアデータ（パケットと呼んでもよい）の流れである。上記のメタデータは、例えば、個々のメディアデータにヘッダとして付加されてもよいし、一部のメディアデータ（例えば１０個中１個のメディアデータ）にヘッダとして付加されてもよい。

また、メタデータが、メディアデータに追加される形で付加されてもよい。例えば、「...メディアデータ１、メディアデータ２、メディアデータ３、メディアデータ４、...」のようにメディアデータの流れている場合において、「...メディアデータ１、メディアデータ２、メタデータ、メディアデータ３、メディアデータ４、...」のようにメタデータが追加されてもよい。

メタデータが付加されたメディアストリームを受信するトランスコーディング機能５０は、メタデータを自律で解釈し、その意味（例えばメディアデータの符号化方式）を把握できる。これにより、適切なトランスコーディング動作を実施できる。

トランスコーディング機能５０は、例えば、メディアストリームのメディアデータに対してトランスコーディングを実施し、トランスコーディング後の符号化方式を表すメタデータを付加したメディアストリームを送信する（Ｓ１３）。カスタム機能６０は、例えば、トランスコーディング機能５０から受信したメディアデータをファイルに書き込む。

Ｓ１４において、ユーザ端末１０は、メディアＧＷ４０に対して、セッションの切断（Ｄｉｓｃｏｎｎｅｃｔ）を要求する。

メディアＧＷ４０は切断イベントをイベントハブ３０に送信し（Ｓ１５）、イベントハブ３０は切断イベントをオーケストレーション装置１００に通知する（Ｓ１６）。ここで通知される情報には、ユーザ端末１０あるいはユーザを識別するユーザ識別情報、セッションを終了することを示す情報（つまり、セッションのライフサイクルが終了することを示す情報）が含まれる。

Ｓ１６の通知を受信したオーケストレーション装置１００は、当該ユーザのセッションが終了することを把握し、当該ユーザに対してサービスを提供しているメディアＧＷ４０、トランスコーディング機能５０、カスタム機能６０のそれぞれに削除（Ｔｅｒｍｉｎａｔｅ）を指示する（Ｓ１７～Ｓ１９）。この指示により、メディアＧＷ４０、トランスコーディング機能５０、カスタム機能８０のそれぞれのプログラムが停止する（機能が削除される）。

＜効果等＞
上記のシーケンスに示したように、オーケストレーション装置１００は、前述した要素技術１に基づく動作を実行している。これにより、１オーケストレータ（１オーケストレーション）としては、機能の異なるコンポーネントであっても、さらには複数のストリームデータを処理する場合であっても、作成・削除といった共通的なＡｃｔｉｏｎを実行すればよくなり、複雑なステートを管理する必要がなくなる。その結果、システムの複雑性が下がり、システムの拡張性が向上する。

また、上記のシーケンスに示したように、各コンポーネントは要素技術２を用いている。これにより、各コンポーネントが自律分散して動的にストリームデータを処理できるようになり、システムの可用性及び伸縮性が大きくなる。具体的には、下記のとおりである。

ａ）コンポーネント故障時であっても、新しいコンポーネントを再作成してストリームデータを受信させるだけよくなる。新しいコンポーネントが動的にメタデータを解決し、ネゴシエーションのコストなしに処理を再開できるため、ダウンタイムが少なくなる。

ｂ）ネットワーク利用率に応じてエンコード方式を変更するなどといった動的なパラメータ変更に対して、セッションを切断せずに追従することが可能となり、データの欠損を防ぐことができる。

上記のａ）に関して、例えば、図３のシーケンスにおいて、メディアストリームのセッション継続中に、トランスコーディング機能５０が故障し、その故障をオーケストレーション装置１００が検知したとする。すると、オーケストレーション装置１００はトランスコーディング機能５０を再作成する。トランスコーディング機能５０は、メディアＧＷ４０からメディアストリームとともに受信するメタデータを自律で解釈できるので、すぐに故障前の動作に戻ることができる。

また、ｂ）に関して、例えば、図３のシーケンスにおいて、メディアストリームのセッション継続中に、ユーザ端末１０がエンコード方式（符号化方式）を変更したとする。メディアＧＷ４０は、変更後の符号化方式で符号化されたメディアデータを受信すると、変更後の符号化方式を把握し、当該符号化方式を表すメタデータを含むメディアストリームを後段に流す。よって、セッションを切断せずにパラメータ変更に追従することができる。

更に、要素技術２により、メタデータを実装者が自由に設計・拡張して、ユースケースに応じた独自のパラメータをストリーム中に伝搬することで、オーケストレータなどを介してパラメータを調整する必要なしに、コンポーネント実装の範囲内でユースケースを拡張することが可能となる（システムの拡張性が向上する）。

例えば、ＡＩでの分析結果をストリームのメタデータに付与するコンポーネントを加えて、後続のコンポーネントにそのパラメータを利用したロジックを追加するだけで、ＡＩを活用したストリーム処理をするシステムに変更できる。

（装置構成）
図４に、オーケストレーション装置１００の機能構成例を示す。図４に示すように、オーケストレーション装置１００は、送信部１１０、受信部１２０、制御部１３０、データ記憶部１４０を有する。

送信部１１０は、コンポーネントの作成命令／削除命令等の送信を行う。受信部１２０は、イベントの通知を受信する。制御部１３０は、データ記憶部１４０に格納された設定情報、管理情報等に基づき、作成すべきコンポーネント／終了すべきコンポーネントを決定する等の制御を実行する。なお、送信部１１０、受信部１２０が制御部１３０に含まれていてもよい。

データ記憶部１４０には、例えば、ユーザ毎の設定情報（どのコンポーネントを使用すかを示す情報等）、各コンポーネントが作成（起動）しているか、終了（停止）しているかを示す管理情報等を格納する。

オーケストレーション装置１００は、例えば、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。

オーケストレーション装置１００は、コンピュータに内蔵されるＣＰＵやメモリ等のハードウェア資源を用いて、当該オーケストレーション装置１００で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。

図５は、本実施の形態における上記コンピュータのハードウェア構成例を示す図である。図５のコンピュータは、それぞれバスＢで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、及び入力装置１００７等を有する。

当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、当該オーケストレーション装置１００に係る機能を実現する。インタフェース装置１００５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。

上記のように、コンピュータとプログラムで実現できる点は、ユーザエンドポイント２０、イベントハブ３０、オーケストレーション装置１００、メディアＧＷ（ゲートウェイ）４０、トランスコーディング機能５０、カスタム機能６０のそれぞれについても同様である。

（オーケストレーション装置１００の動作例）
図６は、図４に示した構成を有するオーケストレーション装置１００の動作例を示すフローチャートである。図６を参照して動作例を説明する。

Ｓ１０１において、受信部１２０が接続イベントの通知を受信することで、制御部１３０が接続イベント（サービスの開始要求）を検知する。

Ｓ１０２において、制御部１３０は、接続イベントのもととなる接続要求を発したユーザに関する設定情報を参照することで、作成すべきコンポーネントを決定し、当該コンポーネントへの作成命令送信を送信部１１０に指示し、送信部１１０は作成命令を送信することで必要なコンポーネントの作成を行う。

Ｓ１０３において、受信部１２０が切断イベントの通知を受信することで、制御部１３０が切断イベント（サービスの終了要求）を検知する。

Ｓ１０４において、制御部１３０は、切断イベントのもととなる切断要求を発したユーザに関する設定情報を参照することで、終了すべきコンポーネントを決定し、当該コンポーネントへの削除命令送信を送信部１１０に指示し、送信部１１０は削除命令を送信することでコンポーネントを終了させる。

（実施の形態のまとめ）
本明細書には、少なくとも下記の技術が開示されている。
（第１項）
１つ又は複数のコンポーネントによりサービスを提供するネットワークにおいて、前記１つ又は複数のコンポーネントに対する制御を実行する制御装置であって、
前記サービスの開始要求を検知した場合に、前記１つ又は複数のコンポーネントを作成し、前記サービスの終了要求を検知した場合に、前記１つ又は複数のコンポーネントを削除する制御部
を備える制御装置。
（第２項）
前記制御装置は、ユーザ毎の設定情報を記憶するデータ記憶部を更に備え、
前記制御部は、前記開始要求の送信元のユーザの設定情報を参照することにより、作成する１つ又は複数のコンポーネントを決定する
第１項に記載の制御装置。
（第３項）
前記１つ又は複数のコンポーネントのうちのいずれかのコンポーネント又は全部のコンポーネントは、
受信するデータストリームにメタデータを付加し、当該メタデータを含むデータストリームを送信する機能と、
受信するメタデータを解釈する機能と
を含む第１項又は第２項に記載の制御装置。
（第４項）
第１項ないし第３項のうちいずれか１項に記載の前記制御装置と、前記１つ又は複数のコンポーネントとを有するサービス提供システム。
（第５項）
１つ又は複数のコンポーネントによりサービスを提供するネットワークにおいて、前記１つ又は複数のコンポーネントに対する制御を実行する制御装置により行われる制御方法であって、
前記サービスの開始要求を検知した場合に、前記１つ又は複数のコンポーネントを作成するステップと、
前記サービスの終了要求を検知した場合に、前記１つ又は複数のコンポーネントを削除するステップと
を備える制御方法。
（第６項）
コンピュータを、第１項ないし第３項のうちいずれか１項に記載の制御装置の各部として機能させるためのプログラム。

以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ ユーザ端末
２０ ユーザエンドポイント
３０ イベントハブ
４０ メディアＧＷ
５０ トランスコーディング機能
６０ カスタム機能
１００ オーケストレーション装置
１１０ 送信部
１２０ 受信部
１３０ 制御部
１４０ データ記憶部
２００ ネットワーク
１０００ ドライブ装置
１００２ 補助記憶装置
１００３ メモリ装置
１００４ ＣＰＵ
１００５ インタフェース装置
１００６ 表示装置
１００７ 入力装置

Claims (5)

1. 複数のコンポーネントによりサービスを提供するネットワークにおいて、前記複数のコンポーネントに対する制御を実行する制御装置であって、
   メディアストリームのセッションを開始する開始要求を検知した場合に、メディアゲートウェイを含む前記複数のコンポーネントを作成し、前記メディアストリームのセッションの終了要求を検知した場合に、前記複数のコンポーネントを削除する制御部を備え、
   前記制御装置は、ユーザ毎の設定情報を記憶するデータ記憶部を更に備え、
   前記制御部は、前記開始要求の送信元のユーザの設定情報を参照することにより、作成する前記複数のコンポーネントを決定する
   制御装置。
2. 前記複数のコンポーネントのうちのいずれかのコンポーネント又は全部のコンポーネントは、
   受信するデータストリームにメタデータを付加し、当該メタデータを含むデータストリームを送信する機能と、
   受信するメタデータを解釈する機能と
   を含む請求項１に記載の制御装置。
3. 請求項１又は２に記載の前記制御装置と、前記複数のコンポーネントとを有するサービス提供システム。
4. 複数のコンポーネントによりサービスを提供するネットワークにおいて、前記複数のコンポーネントに対する制御を実行する制御装置により行われる制御方法であって、
   メディアストリームのセッションを開始する開始要求を検知した場合に、メディアゲートウェイを含む前記複数のコンポーネントを作成する第１ステップと、
   前記メディアストリームのセッションの終了要求を検知した場合に、前記複数のコンポーネントを削除する第２ステップと、を備え
   前記制御装置は、ユーザ毎の設定情報を記憶するデータ記憶部を備え、
   前記第１ステップにおいて、前記開始要求の送信元のユーザの設定情報を参照することにより、作成する前記複数のコンポーネントを決定する
   制御方法。
5. コンピュータを、請求項１又は２に記載の制御装置の各部として機能させるためのプログラム。

Images