ホーム > 特許ランキング > 株式会社ＮＴＴドコモ
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2025011429
(43)【公開日】2025-01-24
(54)【発明の名称】配信システム
(51)【国際特許分類】
H04N 21/241 20110101AFI20250117BHJP
H04N 21/2668 20110101ALI20250117BHJP
G10K 15/02 20060101ALI20250117BHJP
A63F 13/54 20140101ALI20250117BHJP
H04L 67/131 20220101ALI20250117BHJP
【ＦＩ】
H04N21/241
H04N21/2668
G10K15/02
A63F13/54
H04L67/131
【審査請求】未請求
【請求項の数】5
【出願形態】ＯＬ
(21)【出願番号】P 2023113537
(22)【出願日】2023-07-11
(71)【出願人】
【識別番号】392026693
【氏名又は名称】株式会社ＮＴＴドコモ
(74)【代理人】
【識別番号】100088155
【弁理士】
【氏名又は名称】長谷川 芳樹
(74)【代理人】
【識別番号】100113435
【弁理士】
【氏名又は名称】黒木 義樹
(74)【代理人】
【識別番号】100121980
【弁理士】
【氏名又は名称】沖山 隆
(74)【代理人】
【識別番号】100128107
【弁理士】
【氏名又は名称】深石 賢治
(72)【発明者】
【氏名】山添 隆文
【テーマコード（参考）】
5C164
5D208
【Ｆターム（参考）】
5C164FA22
5C164PA31
5C164PA46
5C164SB02S
5C164SB04S
5C164SB51P
5C164SC05P
5D208BA01
5D208BB01
(57)【要約】
【課題】クライアントに適切な音声を配信すること。
【解決手段】配信システム１は、一のクライアントに配信する音声であって、三次元空間内の複数の位置のうち一の位置に応じた音声を生成して当該一のクライアントに配信する第一配信処理と、一の音源に関する音源情報であって当該一の音源の三次元空間内での位置情報を含む音源情報を各クライアントに配信する第二配信処理と、をそれぞれ異なるプロセスで実行し、所定の基準に基づいて、第一配信処理を実行するプロセスと第二配信処理を実行するプロセスとの割合を変更する。クライアントの数又は音源の数の少なくとも一方に基づいて割合を変更してもよい。
【選択図】図５
【解決手段】配信システム１は、一のクライアントに配信する音声であって、三次元空間内の複数の位置のうち一の位置に応じた音声を生成して当該一のクライアントに配信する第一配信処理と、一の音源に関する音源情報であって当該一の音源の三次元空間内での位置情報を含む音源情報を各クライアントに配信する第二配信処理と、をそれぞれ異なるプロセスで実行し、所定の基準に基づいて、第一配信処理を実行するプロセスと第二配信処理を実行するプロセスとの割合を変更する。クライアントの数又は音源の数の少なくとも一方に基づいて割合を変更してもよい。
【選択図】図５
【特許請求の範囲】
【請求項1】
一のクライアントに配信する音声であって、三次元空間内の複数の位置のうち一の位置に応じた音声を生成して当該一のクライアントに配信する第一配信処理と、一の音源に関する音源情報であって当該一の音源の前記三次元空間内での位置情報を含む音源情報を各クライアントに配信する第二配信処理と、をそれぞれ異なるプロセスで実行する配信システムであって、
所定の基準に基づいて、前記第一配信処理を実行するプロセスと前記第二配信処理を実行するプロセスとの割合を変更する、
配信システム。
所定の基準に基づいて、前記第一配信処理を実行するプロセスと前記第二配信処理を実行するプロセスとの割合を変更する、
配信システム。
【請求項2】
前記クライアントの数又は前記音源の数の少なくとも一方に基づいて前記割合を変更する、
請求項１に記載の配信システム。
請求項１に記載の配信システム。
【請求項3】
前記クライアントの数が、
所定の閾値未満の場合に、前記第一配信処理を実行するプロセスの割合を増やす、又は、
所定の閾値以上の場合に、前記第二配信処理を実行するプロセスの割合を増やす、
請求項１に記載の配信システム。
所定の閾値未満の場合に、前記第一配信処理を実行するプロセスの割合を増やす、又は、
所定の閾値以上の場合に、前記第二配信処理を実行するプロセスの割合を増やす、
請求項１に記載の配信システム。
【請求項4】
前記音源の数が、
所定の閾値以上の場合に、前記第一配信処理を実行するプロセスの割合を増やす、又は、
所定の閾値未満の場合に、前記第二配信処理を実行するプロセスの割合を増やす、
請求項１に記載の配信システム。
所定の閾値以上の場合に、前記第一配信処理を実行するプロセスの割合を増やす、又は、
所定の閾値未満の場合に、前記第二配信処理を実行するプロセスの割合を増やす、
請求項１に記載の配信システム。
【請求項5】
前記クライアントの数が前記音源の数未満の場合に、前記第一配信処理を実行するプロセスの割合を増やす、又は、
前記クライアントの数が前記音源の数以上の場合に、前記第二配信処理を実行するプロセスの割合を増やす、
請求項１に記載の配信システム。
前記クライアントの数が前記音源の数以上の場合に、前記第二配信処理を実行するプロセスの割合を増やす、
請求項１に記載の配信システム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示の一側面は、映像及び音声を配信する配信システムに関する。
【背景技術】
【0002】
下記特許文献１では、複数のゲームエンジンノードを有する分散型ゲームエンジンが開示されている。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特表２０２２－５１０６００号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
一般的なゲームエンジンなどでは、音声が一系統分の出力しか想定されていない。そのため、一つのゲームエンジン上で複数のカメラ視点の映像をストリーミング（配信）しても、音声はカメラ視点に合わせたものにならず、全体共通の一系統のみとなり、それぞれのユーザ位置（複数のカメラ視点）にあわせた（複数の）音声を配信できない。すなわち、クライアントに適切な音声を配信することができない。そこで、クライアントに適切な音声を配信することが望まれている。
【課題を解決するための手段】
【0005】
本開示の一側面に係る配信システムは、一のクライアントに配信する音声であって、三次元空間内の複数の位置のうち一の位置に応じた音声を生成して当該一のクライアントに配信する第一配信処理と、一の音源に関する音源情報であって当該一の音源の三次元空間内での位置情報を含む音源情報を各クライアントに配信する第二配信処理と、をそれぞれ異なるプロセスで実行する配信システムであって、所定の基準に基づいて、第一配信処理を実行するプロセスと第二配信処理を実行するプロセスとの割合を変更する。
【0006】
このような側面においては、第一配信処理が実行されるプロセスでは、一のクライアントに対して三次元空間内の一の位置に応じた音声が生成されて配信される。それゆえ、クライアントに適切な音声を配信することができる。また、第二配信処理が実行されるプロセスでは、各クライアントに対して一の音源に関する音源情報であって当該一の音源の三次元空間内での位置情報を含む音源情報が配信される。例えば各クライアントは、配信された音源情報に基づいて適切な音声を再生することができる。それゆえ、クライアントに適切な音声を配信することができる。
【発明の効果】
【0007】
本開示の一側面によれば、クライアントに適切な音声を配信することができる。
【図面の簡単な説明】
【0008】
【図1】従来の配信システムのシステム構成を示す図である。
【図2】実施形態に係る配信システム（プロセスＢタイプ）のシステム構成の一例を示す図である。
【図3】実施形態に係る配信システム（プロセスＣタイプ）のシステム構成の一例を示す図である。
【図4】仮想空間での位置関係の一例を示す図である。
【図5】実施形態に係る配信システムが実行する割合変更処理の一例を示すフローチャートである。
【図6】実施形態に係る配信システムの割合変更前のシステム構成の一例を示す図である。
【図7】実施形態に係る配信システムの割合変更後のシステム構成の一例を示す図である。
【図8】実施形態に係る配信システムで用いられるコンピュータのハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【0009】
以下、図面を参照しながら本開示での実施形態を詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。また、以下の説明における本開示での実施形態は、本発明の具体例であり、特に本発明を限定する旨の記載がない限り、これらの実施形態に限定されないものとする。
【0010】
まず、実施形態で対象とする仮想／ゲーム空間などについて説明する。実施形態の対象となるサービスは、仮想空間又はゲーム画面などの映像を生成して配信するシステム（サーバ）、その映像を受信する不特定多数のクライアントで構成されていることを想定している。仮想空間に対して、クライアントは操作信号を送信することができ、仮想空間上のクライアントに対応するアバター（キャラクター）などが操作信号により制御することができる（いわゆるクラウドゲーミングという手法に基づくサービス）。
【0011】
仮想空間などは、コンピュータグラフィックス（ＣＧ；Computer Graphics）による複数系統の映像を生成できるが、音声については複数系統の生成に制約があるゲームエンジンを想定している。ただし、一系統（又は映像数以下の少数の系統）として、ステレオ音声又はサラウンド音声は生成可能で、仮想空間上に配置された、仮想空間内のＢＧＭ（Background Music）（もしくは位置に関係なく利用する音、効果音・アナウンス音声など）又は複数の音源（滝の音又はガラスが割れる音などの空間の位置に紐づいて生成される音）などから合成された立体的な音響効果は実現できる。
【0012】
例えば、複数人のクライアント（利用者）がアバターを主観視点で操作するために、複数視点の映像を生成した上で、それぞれの位置における臨場感のある音声を生成しようとしても、音声が一系統しか取り扱えなければ映像の数に対応した音声を生成することができない。なお、実施形態において用語「音声」は「音」に置き換えてもよい。
【0013】
図１は、従来の配信システムのシステム構成を示す図である。図１では、３つのクライアントであるクライアントα、クライアントβ及びクライアントγに映像及び音声をストリーミング（配信）する場合の配信システムのシステム構成を示している。
【0014】
サーバ（従来の配信システム）側では、４つのゲームエンジンのプロセスが実行されている。４つのうち３つのプロセスは、クライアントごとにあるプロセス、すなわち、クライアントα用のプロセス（以降では「αプロセス」と記す）と、クライアントβ用のプロセス（以降では「βプロセス」と記す）と、クライアントγ用のプロセス（以降では「γプロセス」と記す）との３つのプロセスである。４つのうち残りの１つのプロセスは、上述のクライアントごとにあるプロセスの同期管理を行うプロセス（以降では「同期プロセス」と記す）である。各プロセスは同一環境に存在し、（同期プロセスが主導して）プロセス間の処理を同期する。
【0015】
αプロセス、βプロセス及びγプロセスはそれぞれ、ＣＧ生成の処理、同期処理、映像の処理、音声の処理、及び、仮想空間での相互作用の計算の処理を実行する。ＣＧ生成の処理は、対象のクライアント（例えばαプロセスならばクライアントα）用のＣＧを生成する。同期処理は、同期プロセスと連携して、クライアントごとにある３つのプロセス間での同期を行う。映像の処理は、同じプロセス内のＣＧ生成の処理によって生成されたＣＧに基づいて、対象のクライアント用の映像を生成する。音声の処理は、対象のクライアント用の音声を生成する。仮想空間での相互作用の計算の処理は、仮想空間でのアバターなどの相互作用を計算する。なお、ＣＧ生成の処理、同期処理、映像の処理及び音声の処理は、仮想空間での相互作用の計算結果に基づいてもよい。
【0016】
αプロセス、βプロセス及びγプロセスそれぞれは、当該プロセスの映像の処理によって生成された映像、及び、音声の処理によって生成された音声を、対象のクライアントにストリーミングする。αプロセス、βプロセス及びγプロセスそれぞれの仮想空間での相互作用の計算の処理は、対象のクライアントからアバターなどの操作信号を受信し、受信した操作信号に基づいて計算する。
【0017】
音アセットは、ＢＧＭ、音源１及び音源２などを含み、サーバのストレージに格納される。音アセットは、必要に応じて必要とするプロセスに読み込まれる。
【0018】
図１に示す従来の配信システムのシステム構成の課題として、１台のサーバ内であっても、プロセス間の同期処理、及び、共通化が可能な仮想空間での相互作用の計算などを、それぞれのプロセスで行う必要があることが挙げられる。
【0019】
実施形態に係る配信システム（配信システム１）は、２種類のシステム構成を、排他的又は非排他的（同時に利用）に取り得る。１種類目のシステム構成をプロセスＢタイプと記し、２種類目のシステム構成をプロセスＣタイプと記す。以下では、まず、プロセスＢタイプの詳細、及び、プロセスＣタイプの詳細を順に説明する。
【0020】
［プロセスＢタイプ］
配信システム１のプロセスＢタイプは、映像又は音声の少なくとも一方を処理するプロセスを複数実行し、三次元空間内の複数の位置それぞれに応じた映像を生成して各クライアントに配信する共通処理（後述のプロセスＡで実行される）と、一のクライアントに配信する音声であって、複数の位置のうち一の位置に応じた音声を生成して当該一のクライアントに配信する配信処理（後述のプロセスＢで実行される）とをそれぞれ異なるプロセスで実行する。
配信システム１のプロセスＢタイプは、映像又は音声の少なくとも一方を処理するプロセスを複数実行し、三次元空間内の複数の位置それぞれに応じた映像を生成して各クライアントに配信する共通処理（後述のプロセスＡで実行される）と、一のクライアントに配信する音声であって、複数の位置のうち一の位置に応じた音声を生成して当該一のクライアントに配信する配信処理（後述のプロセスＢで実行される）とをそれぞれ異なるプロセスで実行する。
【0021】
三次元空間は、仮想空間であってもよい。音声を処理するプロセスは、一系統分の音声しか処理できなくてもよい。一の位置は、一のクライアントに対応するアバターがいる位置であってもよい。共通処理と、複数のクライアント分の複数の配信処理とをそれぞれ異なるプロセスで実行してもよい。共通処理は、生成した映像を１対多で配信してもよい。共通処理は、生成した映像をＳＦＵ（Selective Forwarding Unit）を介して配信してもよい。配信処理を実行するプロセスの数は、クライアントの数に基づいてもよい。例えば、配信処理を実行するプロセスの数は、クライアントの数と同一であってもよいし、クライアントの数以上であってもよいし、クライアントの数に応じて動的に増減してもよい。配信処理は、映像に関する処理を行わなくてもよい。
【0022】
【0023】
配信システム１（プロセスＢタイプ）は、１つ又は複数のサーバ上で独立した形で動作する複数のゲームエンジンの処理（プロセス）で構成される。具体的には、配信システム１（プロセスＢタイプ）は、プロセスＡ、プロセスＢ－α、プロセスＢ－β及びプロセスＢ－γの４つのプロセスで構成される。なお、プロセスＢ－α、プロセスＢ－β及びプロセスＢ－γを総称して「プロセスＢ」と適宜記す。
【0024】
プロセスＡ（で実行される仮想空間での相互作用の計算の処理）は、不特定多数のクライアント（例えばクライアントα、クライアントβ及びクライアントγ）から操作信号を受信し、それぞれのクライアントに対応するアバターを仮想空間に配置し、それぞれの位置に応じた視点（ただし、アバターと視点が１：１の関係でなくてもよい。例えば複数クライアントで１つの視点を共有してもよい）を生成し、アバターの操作と仮想空間におけるリアルタイムの相互作用を計算する。
【0025】
プロセスＡ（で実行されるＣＧ生成・映像化の処理（図中の「ＣＧ生成・映像化１」及び「ＣＧ生成・映像化２」））は、前述の相互作用によって発生する仮想空間内の音に関する情報（音源の発生又は位置関係の変化など。音声の生成は行わなくてもよいがＢＧＭなどの共通の音については映像にのせることもできる）を用意する。また、それぞれのアバターの視点に応じたＣＧ（例えばＣＧ１とＣＧ２の２つ）を生成し、ＣＧを映像化し（例えば「映像１」及び「映像２」を生成し）、クライアントに映像配信する。音に関する情報は、それぞれのアバターの位置情報とあわせてリアルタイムで後述するプロセスＢに伝達する（メモリアドレスなどの参照情報、あるいはプロセス間通信又はＩＰ通信といったデータ転送）。
【0026】
複数の映像・音声を不特定多数のクライアントに分配したり、配信システム１（プロセスＢタイプ）とクライアントの接続の管理を容易にするために、ＳＦＵ（クライアント・サーバ方式のひとつ）を用いてもよい。例えば、図２に示すように、プロセスＡからクライアントへの映像配信は、ＳＦＵを介することで、一部の映像配信はＳＦＵで分配化される。これにより、例えば、映像１はクライアントα及びクライアントβに配信され（１対多の配信）、映像２はクライアントγに配信される（１対１の配信）。
【0027】
プロセスＢは、クライアントの数に応じて用意され、（プロセスＢの音声の処理が）プロセスＡでの音に関する情報からアバター位置に応じた音声を生成し、音声を圧縮された情報としてクライアントにストリーミングする。プロセスＢは、音源からの音声生成を実施して配信する。例えば、プロセスＢ－αは、音声１（クライアントαの位置に応じた音声）を生成し、生成した音声１をクライアントαにストリーミングする。また例えば、プロセスＢ－βは、音声２（クライアントβの位置に応じた音声）を生成し、生成した音声２をクライアントβにストリーミングする。また例えば、プロセスＢ－γは、音声３（クライアントγの位置に応じた音声）を生成し、生成した音声３をクライアントγにストリーミングする。プロセスＢからクライアントへの音声の配信は、Ｐ２Ｐ（ピアツーピア）であるが、ＳＦＵを経由してもよい。
【0028】
プロセスＢが音に関する情報からアバター位置に応じた音声を生成する点について具体例を挙げる。生成する音声は、それぞれのクライアントが操作するアバターの位置に応じた、音響効果を踏まえた音声データになる。例えば、ユーザＸ及びユーザＹが左右に並んで立っていて、その真ん中にたき火の音（これの音に関する情報がプロセスＡからプロセスＢに伝達されている。ただし、音そのものではなく、音そのものはプロセスＢで他の音とあわせて音響効果も考慮された形で生成される）がしていた場合、ユーザＸの音声としてはたき火の音が右側から聞こえる形で生成され、ユーザＹの音声としてはたき火の音が左側から聞こえる形で生成される。
【0029】
ＣＧの生成は、リアルタイムで逐次的に行われる、その時点での３ＤＣＧの見え方（とそのデータが格納されたサーバ上のメモリの領域）を指している。映像化は、その逐次的な時系列の情報をいわゆる映像エンコードにより圧縮し、外部に伝送できる状態にすることを指している。
【0030】
プロセスＢは、音声を生成するための音源データは保持するが、ＣＧデータの読み込み・描画処理・映像化・仮想空間内のイベント処理・物理シミュレーション処理などのプロセスＡで行われる処理は行わない。なお、プロセスＢは、ゲームエンジンより低い処理負荷で映像圧縮・配信が行えるプログラムを用いてもよい。
【0031】
例えば、プロセスＢ－αは、αの位置にあわせて生成された仮想空間上での音声を合わせてクライアントαに配信する。クライアントαからの操作信号はプロセスＢ－αではなく、プロセスＡが受信する。
【0032】
図２における音アセットについて、プロセスＡが読み込み、共通のＢＧＭなどは映像に乗せることもできる。また、音アセットはプロセスＢが読み込み、ゲームエンジン内の音データから位置にあわせた音声を生成する。
【0033】
図２において、音声生成に必要な高負荷処理は映像側で実施し、音声処理側に同期してもよい。すなわち、プロセスＡでは複数のクライアントの処理を行ったうえで、それをプロセスＢに分配する形になるので、効率的にできる処理はやっておく。高負荷処理の一例としては、複数クライアントによる操作に対して空間上で生じる相互作用（物理シミュレーション、マルチプレイ処理）などが挙げられる。
【0034】
以上がプロセスＢタイプの説明である。続いて、プロセスＣタイプの詳細を説明する。
【0035】
［プロセスＣタイプ］
配信システム１のプロセスＣタイプは、映像又は音声の少なくとも一方を処理するプロセスを複数実行し、三次元空間内の複数の位置それぞれに応じた映像を生成して各クライアントに配信する共通処理（後述のプロセスＡで実行される）と、一の音源に関する音源情報であって当該一の音源の三次元空間内での位置情報を含む音源情報を各クライアントに配信する配信処理（後述のプロセスＣで実行される）とをそれぞれ異なるプロセスで実行する。
配信システム１のプロセスＣタイプは、映像又は音声の少なくとも一方を処理するプロセスを複数実行し、三次元空間内の複数の位置それぞれに応じた映像を生成して各クライアントに配信する共通処理（後述のプロセスＡで実行される）と、一の音源に関する音源情報であって当該一の音源の三次元空間内での位置情報を含む音源情報を各クライアントに配信する配信処理（後述のプロセスＣで実行される）とをそれぞれ異なるプロセスで実行する。
【0036】
三次元空間は、仮想空間であってもよい。音声を処理するプロセスは、一系統分の音声しか処理できなくてもよい。共通処理と、複数の音源分の複数の配信処理とをそれぞれ異なるプロセスで実行してもよい。共通処理は、生成した映像を１対多で配信してもよい。共通処理は、生成した映像をＳＦＵ（Selective Forwarding Unit）を介して配信してもよい。配信処理を実行するプロセスの数は、音源の数に基づいてもよい。例えば、配信処理を実行するプロセスの数は、音源の数と同一であってもよいし、音源の数以上であってもよいし、音源の数に応じて動的に増減してもよい。配信処理は、映像に関する処理を行わなくてもよい。配信処理は、音源情報を１対多で配信してもよい。配信処理は、音源情報をＳＦＵを介して配信してもよい。
【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】
配信システム１によれば、配信システム１で映像と音声を別々に配信し、クライアントで映像と音声を同時に再生して利用する。個別の情報が音のみであるため、映像配信のＧＰＵ（Graphics Processing Unit）サーバ負荷・通信量を最小化することができる。それにより、多数配信、及び、通信コストを抑えるシステム構成が可能となる。配信システム１においては、個別のユーザ位置からの聞こえ方としての音声を生成し、ユーザ（クライアント）側でユーザ位置の音声を受信し、別で配信された映像とあわせてクライアント上で再生される。
【0069】
配信システム１によれば、１つのゲームエンジンで１つの音声しか処理できない場合でも、複数のクライアントそれぞれに応じた音声を用意して配信できる。また、配信システム１によれば、映像を生成する映像処理はクライアント数に依存しないため、配信システム１の負荷を軽減することができる。また、配信システム１によれば、映像と音声を合成する処理はクライアント側で行われるため、配信システム１の負荷を軽減することができる。
【0070】
配信システム１によれば、共通的で複雑な処理を行うプロセスＡと、それぞれのクライアントに応じた音源情報の配信を行うプロセスＣにより、（複数のゲームエンジン（プロセス）で、それぞれのクライアントに対応するすべての仮想空間処理とゲームエンジン間の同期処理を個別に行う場合と比べて）最低限の処理負荷の上昇により、複数系統の映像・音声を用いた仮想空間の処理を一台のシステム（又はサーバ）で行うことができる。
【0071】
配信システム１においては、配信システム１で映像に加えて音源そのものを配信し、クライアントで映像と音源を同時に再生して利用する。これにより、配信システム１の負荷が最小化される。配信システム１においては、全体共通の背景音響（環境音）と、個別の音源オブジェクトの音と位置を個別にストリーミングし、クライアントのアバター位置にあわせてクライアント側で音響処理をして音声を再生する。なお、ＢＧＭなどは映像と一緒にストリーミングされ、個別の音源オブジェクトは音のみストリーミングされる。
【0072】
配信システム１によれば、一つのゲームエンジンで一つの音声しか処理できない場合でも、複数のクライアントそれぞれにて当該クライアントに応じた映像・音声を再生できる。また、配信システム１によれば、映像を生成する映像処理はクライアント数に依存しないため、配信システム１の負荷を軽減することができる。また、配信システム１によれば、配信処理を実行するプロセスはクライアント数に依存しないため、配信システム１の負荷を軽減することができる。また、配信システム１によれば、音声を生成する処理はクライアント側で行われるため、配信システム１の負荷を軽減することができる。また、配信システム１によれば、映像と音声を合成する処理はクライアント側で行われるため、配信システム１の負荷を軽減することができる。
【0073】
配信システム１によれば、クライアント数及び音源数に応じて、通信量、サーバ負荷及びクライアント負荷を考慮した配信手法に切り替えることができる。
【0074】
従来の課題として、一般的なゲームエンジンなどでは音声が一系統分の出力しか想定されていないことが挙げられる。そのため、一つのゲームエンジン上で複数のカメラ視点の映像をストリーミングしても、音声はカメラ視点に合わせたものにならず、全体共通の一系統のみとなり、それぞれのアバター位置（複数のカメラ視点）にあわせた複数の音声をストリーミングできない。また、クラウドレンダリングで複数クライアントに一つのレンダリング映像を分配した場合も、アバター位置にあわせた音響が実現できない。
【0075】
配信システム１は、例えば、１つのクラウドレンダリング環境で複数のゲームエンジン処理を実行し、複数のうちの追加のゲームエンジン処理では位置情報に基づく音響処理を実施し、配信することで、上記課題を解決している。
【0076】
配信システム１は、クラウドレンダリングでの空間オーディオ制御手法を実現する。配信システム１は、視聴者数と音源数の比率による空間オーディオ制御手法を実現する。
【0077】
本開示の配信システム１は、以下の構成を有してもよい。
【0078】
［１］
一のクライアントに配信する音声であって、三次元空間内の複数の位置のうち一の位置に応じた音声を生成して当該一のクライアントに配信する第一配信処理と、一の音源に関する音源情報であって当該一の音源の前記三次元空間内での位置情報を含む音源情報を各クライアントに配信する第二配信処理と、をそれぞれ異なるプロセスで実行する配信システムであって、
所定の基準に基づいて、前記第一配信処理を実行するプロセスと前記第二配信処理を実行するプロセスとの割合を変更する、
配信システム。
一のクライアントに配信する音声であって、三次元空間内の複数の位置のうち一の位置に応じた音声を生成して当該一のクライアントに配信する第一配信処理と、一の音源に関する音源情報であって当該一の音源の前記三次元空間内での位置情報を含む音源情報を各クライアントに配信する第二配信処理と、をそれぞれ異なるプロセスで実行する配信システムであって、
所定の基準に基づいて、前記第一配信処理を実行するプロセスと前記第二配信処理を実行するプロセスとの割合を変更する、
配信システム。
【0079】
［２］
前記クライアントの数又は前記音源の数の少なくとも一方に基づいて前記割合を変更する、
［１］に記載の配信システム。
前記クライアントの数又は前記音源の数の少なくとも一方に基づいて前記割合を変更する、
［１］に記載の配信システム。
【0080】
［３］
前記クライアントの数が、
所定の閾値未満の場合に、前記第一配信処理を実行するプロセスの割合を増やす、又は、
所定の閾値以上の場合に、前記第二配信処理を実行するプロセスの割合を増やす、
［１］又は［２］に記載の配信システム。
前記クライアントの数が、
所定の閾値未満の場合に、前記第一配信処理を実行するプロセスの割合を増やす、又は、
所定の閾値以上の場合に、前記第二配信処理を実行するプロセスの割合を増やす、
［１］又は［２］に記載の配信システム。
【0081】
［４］
前記音源の数が、
所定の閾値以上の場合に、前記第一配信処理を実行するプロセスの割合を増やす、又は、
所定の閾値未満の場合に、前記第二配信処理を実行するプロセスの割合を増やす、
［１］～［３］の何れか一項に記載の配信システム。
前記音源の数が、
所定の閾値以上の場合に、前記第一配信処理を実行するプロセスの割合を増やす、又は、
所定の閾値未満の場合に、前記第二配信処理を実行するプロセスの割合を増やす、
［１］～［３］の何れか一項に記載の配信システム。
【0082】
［５］
前記クライアントの数が前記音源の数未満の場合に、前記第一配信処理を実行するプロセスの割合を増やす、又は、
前記クライアントの数が前記音源の数以上の場合に、前記第二配信処理を実行するプロセスの割合を増やす、
［１］～［４］の何れか一項に記載の配信システム。
前記クライアントの数が前記音源の数未満の場合に、前記第一配信処理を実行するプロセスの割合を増やす、又は、
前記クライアントの数が前記音源の数以上の場合に、前記第二配信処理を実行するプロセスの割合を増やす、
［１］～［４］の何れか一項に記載の配信システム。
【0083】
なお、上記実施形態の説明に用いたプロセスは、ハードウェア及びソフトウェアの少なくとも一方の任意の組み合わせによって実現される。また、プロセスの実現方法は特に限定されない。すなわち、プロセスは、物理的又は論理的に結合した１つの装置を用いて実現されてもよいし、物理的又は論理的に分離した２つ以上の装置を直接的又は間接的に（例えば、有線、無線などを用いて）接続し、これら複数の装置を用いて実現されてもよい。プロセスは、上記１つの装置又は上記複数の装置にソフトウェアを組み合わせて実現されてもよい。
【0084】
機能には、判断、決定、判定、計算、算出、処理、導出、調査、探索、確認、受信、送信、出力、アクセス、解決、選択、選定、確立、比較、想定、期待、見做し、報知（broadcasting）、通知（notifying）、通信（communicating）、転送（forwarding）、構成（configuring）、再構成（reconfiguring）、割り当て（allocating、mapping）、割り振り（assigning）などがあるが、これらに限られない。たとえば、送信を機能させる機能ブロック（構成部）は、送信部（transmitting unit）や送信機（transmitter）と呼称される。いずれも、上述したとおり、実現方法は特に限定されない。
【0085】
例えば、本開示の一実施の形態における配信システム１などは、本開示の方法の処理を行うコンピュータとして機能してもよい。図８は、本開示の一実施の形態に係る配信システム１のハードウェア構成の一例を示す図である。上述の配信システム１は、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。
【0086】
なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。配信システム１のハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
【0087】
配信システム１における各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることによって、プロセッサ１００１が演算を行い、通信装置１００４による通信を制御したり、メモリ１００２及びストレージ１００３におけるデータの読み出し及び書き込みの少なくとも一方を制御したりすることによって実現される。
【0088】
プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Central Processing Unit）によって構成されてもよい。
【0089】
また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュール、データなどを、ストレージ１００３及び通信装置１００４の少なくとも一方からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態において説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。上述の各種処理は、１つのプロセッサ１００１によって実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップによって実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されても良い。
【0090】
メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ROM）、ＲＡＭ（Random Access Memory）などの少なくとも１つによって構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本開示の一実施の形態に係る無線通信方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。
【0091】
ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ－ＲＯＭ（Compact Disc ROM）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク（例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ－ｒａｙ（登録商標）ディスク）、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つによって構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及びストレージ１００３の少なくとも一方を含むデータベース、サーバその他の適切な媒体であってもよい。
【0092】
通信装置１００４は、有線ネットワーク及び無線ネットワークの少なくとも一方を介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。通信装置１００４は、例えば周波数分割複信（ＦＤＤ：Frequency Division Duplex）及び時分割複信（ＴＤＤ：Time Division Duplex）の少なくとも一方を実現するために、高周波スイッチ、デュプレクサ、フィルタ、周波数シンセサイザなどを含んで構成されてもよい。
【0093】
入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、ＬＥＤランプなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。
【0094】
また、プロセッサ１００１、メモリ１００２などの各装置は、情報を通信するためのバス１００７によって接続される。バス１００７は、単一のバスを用いて構成されてもよいし、装置間ごとに異なるバスを用いて構成されてもよい。
【0095】
また、配信システム１は、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つを用いて実装されてもよい。
【0096】
情報の通知は、本開示において説明した態様／実施形態に限られず、他の方法を用いて行われてもよい。
【0097】
本開示において説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本開示において説明した方法については、例示的な順序を用いて様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【0098】
入出力された情報等は特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルを用いて管理してもよい。入出力される情報等は、上書き、更新、又は追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。
【0099】
判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：true又はfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。
【0100】
本開示において説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。
【0101】
以上、本開示について詳細に説明したが、当業者にとっては、本開示が本開示中に説明した実施形態に限定されるものではないということは明らかである。本開示は、請求の範囲の記載により定まる本開示の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本開示の記載は、例示説明を目的とするものであり、本開示に対して何ら制限的な意味を有するものではない。
【0102】
ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。
【0103】
また、ソフトウェア、命令、情報などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、有線技術（同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ：Digital Subscriber Line）など）及び無線技術（赤外線、マイクロ波など）の少なくとも一方を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び無線技術の少なくとも一方は、伝送媒体の定義内に含まれる。
【0104】
本開示において説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
【0105】
なお、本開示において説明した用語及び本開示の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。
【0106】
本開示において使用する「システム」及び「ネットワーク」という用語は、互換的に使用される。
【0107】
また、本開示において説明した情報、パラメータなどは、絶対値を用いて表されてもよいし、所定の値からの相対値を用いて表されてもよいし、対応する別の情報を用いて表されてもよい。
【0108】
上述したパラメータに使用する名称はいかなる点においても限定的な名称ではない。さらに、これらのパラメータを使用する数式等は、本開示で明示的に開示したものと異なる場合もある。
【0109】
本開示で使用する「判断（determining）」、「決定（determining）」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定（judging）、計算（calculating）、算出（computing）、処理（processing）、導出（deriving）、調査（investigating）、探索（looking up、search、inquiry）（例えば、テーブル、データベース又は別のデータ構造での探索）、確認（ascertaining）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信（receiving）（例えば、情報を受信すること）、送信（transmitting）（例えば、情報を送信すること）、入力（input）、出力（output）、アクセス（accessing）（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決（resolving）、選択（selecting）、選定（choosing）、確立（establishing）、比較（comparing）などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。また、「判断（決定）」は、「想定する（assuming）」、「期待する（expecting）」、「みなす（considering）」などで読み替えられてもよい。
【0110】
「接続された（connected）」、「結合された（coupled）」という用語、又はこれらのあらゆる変形は、２又はそれ以上の要素間の直接的又は間接的なあらゆる接続又は結合を意味し、互いに「接続」又は「結合」された２つの要素間に１又はそれ以上の中間要素が存在することを含むことができる。要素間の結合又は接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。例えば、「接続」は「アクセス」で読み替えられてもよい。本開示で使用する場合、２つの要素は、１又はそれ以上の電線、ケーブル及びプリント電気接続の少なくとも一つを用いて、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光（可視及び不可視の両方）領域の波長を有する電磁エネルギーなどを用いて、互いに「接続」又は「結合」されると考えることができる。
【0111】
本開示において使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
【0112】
本開示において使用する「第１の」、「第２の」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定しない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本開示において使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみが採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。
【0113】
上記の各装置の構成における「手段」を、「部」、「回路」、「デバイス」等に置き換えてもよい。
【0114】
本開示において、「含む（include）」、「含んでいる（including）」及びそれらの変形が使用されている場合、これらの用語は、用語「備える（comprising）」と同様に、包括的であることが意図される。さらに、本開示において使用されている用語「又は（or）」は、排他的論理和ではないことが意図される。
【0115】
本開示において、例えば、英語でのa、an及びtheのように、翻訳により冠詞が追加された場合、本開示は、これらの冠詞の後に続く名詞が複数形であることを含んでもよい。
【0116】
本開示において、「ＡとＢが異なる」という用語は、「ＡとＢが互いに異なる」ことを意味してもよい。なお、当該用語は、「ＡとＢがそれぞれＣと異なる」ことを意味してもよい。「離れる」、「結合される」などの用語も、「異なる」と同様に解釈されてもよい。
【符号の説明】
【0117】
１…配信システム、１００１…プロセッサ、１００２…メモリ、１００３…ストレージ、１００４…通信装置、１００５…入力装置、１００６…出力装置、１００７…バス。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】