• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04N
管理番号 1290518
審判番号 不服2012-20172  
総通号数 177 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2014-09-26 
種別 拒絶査定不服の審決 
審判請求日 2012-10-12 
確定日 2014-08-06 
事件の表示 特願2009-548423「品質及びレート情報に基づいてマルチメディアコンテンツのサイズを変更するための方法及びシステム」拒絶査定不服審判事件〔平成20年 8月 7日国際公開、WO2008/095020、平成22年 5月20日国内公表、特表2010-517486〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
本願は、2008年1月30日(パリ条約による優先権主張外国庁受理2007年1月30日、米国)を国際出願日とする出願であって、平成21年9月30日付で審査請求がなされ、平成23年10月12日付(起案日)で拒絶の理由が通知され、平成24年4月17日付で意見書及び手続補正書が提出されたものの、平成24年6月8日付(起案日)で拒絶査定がなされたものである。
本件は、上記拒絶査定を不服として平成24年10月12日に請求された拒絶査定不服審判であって、当審において、平成25年7月29日付(起案日)で拒絶の理由が通知され、平成26年1月30日付で意見書・手続補正書が提出されたものである。

2.本願発明
本願の請求項1?105に係る発明は、平成24年4月17日付、及び、平成26年1月30日付手続補正書で補正された明細書、特許請求の範囲及び図面の記載からみて、それぞれ、平成26年1月30日付手続補正書で補正された特許請求の範囲の請求項1?105に記載されたとおりのものと認められるところ、その請求項1に係る発明は請求項1に記載された次のとおりである。(以下「本願発明」という。)

「【請求項1】
デジタルマルチメディアデータの流れを結合するための方法であって、
前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ることと、
前記複数のデータセグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定することと、
前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないときに前記複数のデータセグメントと関連づけられた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記複数のデータセグメントのうちの1つ以上を選択することと、
前記複数のセグメントに関する前記利用可能な帯域幅を達成するために前記1つ以上の選択されたデータセグメントの各々のサイズ変更を要求することと、を備え、
前記選択されたデータセグメントのサイズ変更を要求することは、前記選択されたデータセグメントに関する少なくとも最大サイズを指定することを備える、方法。」

3.引用例・引用発明
3.1.引用例の記載事項
当審における平成25年7月29日付の拒絶の理由で引用した国際公開第2006/110876号(2006年10月19日公開。以下「引用例」という。)には、図面と共に、以下の記載がある。(国際公開第2006/110876号に対応する特表2008-536409号公報の対応箇所の記載が、翻訳として適切であると認められるので、それを括弧内に併記する。)

“[0004] Data networks, such as wireless communication networks, have to trade off between services customized for a single terminal and services provided to a large number of terminals. For example, the distribution of multimedia content to a large number of resource limited portable devices (subscribers) is a complicated problem. Therefore, it is very important for network administrators, content retailers, and service providers to have a way to distribute content and/or other network services in a fast and efficient manner for presentation on networked devices.”(『(背景)無線通信ネットワークのようなデータネットワークは、単一の端末に対してカスタマイズされるサービスと、多数の端末に提供されるサービスとの間のトレードオフをする必要がある。例えば、マルチメディアコンテンツの、リソースが制限された多数の携帯型デバイス(加入者)への配布は、複雑な問題である。従って、ネットワーク管理者、コンテンツ小売業者、及びサービスプロバイダにとって、コンテンツ及び/又は他のネットワークサービスを、ネットワーク接続されたデバイスに提供するために迅速且つ効率的なやり方で配布する方法を有することが非常に重要である。
』(段落【0004】))

“[0005] In current content delivery/media distribution systems, real time and non real time services are packed into a transmission frame and delivered to devices on a network. For example, a communication network may utilize Orthogonal Frequency Division Multiplexing (OFDM) to provide communications between a network server and one or more mobile devices. This technology provides a transmission frame having data slots that are packed with services to be delivered and transmitted over a distribution network. [0006] Unfortunately, conventional systems may pack the services into the transmission frame in a very inefficient manner. For example, the services may be packed in a way that wastes available bandwidth, or requires a receiving device to utilize significant power to receive the content. For example, a device may be required to wake up (i.e., power up its receiving logic) for long time intervals to receive the content, or may be required to wake up at frequent intervals to receive the content. In either case, such inefficient packing leads to devices utilizing more battery power, which can degrade device standby times.”(『現在のコンテンツ配信/メディア流通システムにおいては、リアルタイム及び非リアルタイムサービスが送信フレームの中に詰め込まれ、ネットワーク上のデバイスに配信される。例えば、通信ネットワークが、直交波周波数分割多重(OFDM)を、ネットワークサーバと1つ以上のモバイルデバイスとの間の通信を提供するために使用してもよい。この技術は、配信されるべきサービスが詰まったデータスロットを有しており且つ流通ネットワークを通して送信される、送信フレームを提供する。』(段落【0005】))

“[0007] Therefore, what is needed is a system to efficiently transmit content over a data network that overcomes the problems of conventional systems, and thereby allows receiving devices to receive the content in a power efficient manner.”(『従って、必要なのは、従来のシステムの問題を克服し、これにより受信デバイスがコンテンツを電力効率のよいやり方で受信することを可能とする、データネットワーク上でコンテンツを効率的に送信するためのシステムである。』(段落【0007】))

“[0008] In one or more embodiments, a multiplexing system, comprising methods and apparatus, is provided that operates to efficiently multiplex one or more content flows for transmission over a data network. For example, in an aspect, the system operates to multiplex the content flows into available data slots in a transmission frame. An allocation algorithm is provided that allocates the data slots based on a variety of parameters and/or information associated with the content flows. In an aspect, the system also comprises a resize controller that operates to control how resizing is performed on one or more content flows that cannot fit into the available data slots, so that the resized flows will be able to fit into the available data slots. Thus, the system operates to efficiently multiplex one or more content flows for transmission over a data network is such a way as to meet requirements associated with the content flows, reduce transmission costs, increased bandwidth utilization, and reduce the power requirements of receiving devices.”(『1つ以上の実施形態の中では、方法と装置を備え、データネットワークを通しての送信のために1つ以上のコンテンツフローを効率的に多重化する働きをする、多重化システムが提供される。例えば、一態様によれば、このシステムは、送信フレーム内の利用可能なデータスロットの中にコンテンツフローを多重化する働きをする。コンテンツフローに関連するさまざまなパラメータ及び/又は情報に基づいてデータスロットを割り当てる、割り当てアルゴリズムが提供される。一態様によれば、このシステムはまた、利用可能なデータスロットに収まらない1つ以上のコンテンツフローに対してどのようにリサイズを実行するかを制御する働きをして、リサイズされたフローが利用可能なデータスロットの中に収まることができるようにする、リサイズ制御部を備えている。従って、システムは、データネットワークを通しての送信のために、コンテンツフローに関連する要求を満足し、送信コストを低減し、帯域幅の利用を増進させ、且つ受信デバイスの電力要求を低減するような方法で、1つ以上のコンテンツフローを効率的に多重化する働きをする。』(段落【0008】))

“[0014] In an aspect, a method is provided for transmitting services over a network. The method comprises receiving one or more services having associated delivery requirements, and determining that available network bandwidth is not able to meet the delivery requirements. The method also comprises resizing at least one of the one or more services to produce adjusted delivery requirements, and allocating the available network bandwidth to the one or more services based on the adjusted delivery requirements to produce network bandwidth allocations. ”(『一態様によれば、ネットワークを通してサービスを送信する方法が提供される。この方法は、関連する配信要求を有する1つ以上のサービスを受信することと、利用可能なネットワーク帯域幅は配信要求を満足することができないということを判断することとを備えている。方法はまた、1つ以上のサービスの少なくとも1つをリサイズして調整された配信要求を生成することと、この調整された配信要求に基づいて1つ以上のサービスに利用可能な帯域幅を割り当てしてネットワーク帯域幅割り当てを生成することとを、備えている。』(段落【0014】))

“[0015] In an aspect, an apparatus is provided for transmitting services over a network. The apparatus comprises receiving logic configured to receive one or more services having associated delivery requirements, and a resize controller configured to resize at least one of the one or more services to produce adjusted delivery requirements. The apparatus also comprises multiplexer logic configured to determine that available network bandwidth is not able to meet the delivery requirements, and to allocate the available network bandwidth to the one or more services based on the adjusted delivery requirements to produce network bandwidth allocations.”(『一態様によれば、ネットワークを通してサービスを送信する装置が提供される。この装置は、関連する配信要求を有する1つ以上のサービスを受信するように構成された受信ロジックと、1つ以上のサービスの少なくとも1つをリサイズして、調整された配信要求を生成するように構成されたリサイズ制御部とを備えている。装置はまた、利用可能なネットワーク帯域幅は前記配信要求を満足させることができないということを判断し、利用可能なネットワーク帯域幅を調整された配信要求に基づいて1つ以上のサービスに割り当てして、ネットワーク帯域幅割り当てを生成するように構成された、多重化ロジックを備える。』(段落【0015】))

“[0016] In an aspect, an apparatus is provided for transmitting services over a network. The apparatus comprises means for receiving one or more services having associated delivery requirements, and means for determining that available network bandwidth is not able to meet the delivery requirements. The apparatus also comprises means for resizing at least one of the one or more services to produce adjusted delivery requirements, and means for allocating the available network bandwidth to the one or more services based on the adjusted delivery requirements to produce network bandwidth allocations.”(『一態様によれば、ネットワークを通してサービスを送信する装置が提供される。この装置は、関連する配信要求を有する1つ以上のサービスを受信する手段と、利用可能なネットワーク帯域幅は配信要求を満足することができないということを判断する手段とを備えている。装置はまた、1つ以上のサービスの少なくとも1つをリサイズして調整された配信要求を生成する手段と、この調整された配信要求に基づいて1つ以上のサービスに利用可能な帯域幅を割り当てしてネットワーク帯域幅割り当てを生成する手段とを、備えている。』(段落【0016】))

“[0044] In one or more embodiments, a multiplexing system is provided that operates to multiplex content flows into a transmission frame for transmission over a data network. For example, the multiplexed content flows comprise a particular arrangement, sequence, mixing, and/or selection of real-time and/or non real-time services for transmission to a device. The system is especially well suited for use in wireless network environments, but may be used in any type of network environment, including but not limited to, communication networks, public networks, such as the Internet, private networks, such as virtual private networks (VPN), local area networks, wide area networks, long haul networks, or any other type of data network.”(『1つ以上の実施形態の中で、コンテンツフローを、データネットワークを通して送信するための送信フレームの中に多重化する働きをする、多重化システムが提供される。例えば、この多重化されたコンテンツフローは、特定の配置、順番、混合、及び/又はデバイスに送信するためのリアルタイムサービス及び/又は非リアルタイムサービスの選択を備えている。このシステムは、無線ネットワーク環境の中で用いるのに大変適しており、しかしながら、通信ネットワーク、インターネットのようなパブリックネットワーク、仮想プライベートネットワーク(VPN)のようなプライベートネットワーク、ローカルエリアネットワーク、広域ネットワーク、長距離ネットワーク、又は他の任意の種類のデータネットワークを含む、しかしこれらに限定されない、任意の種類のネットワーク環境の中で用いてもよい。』(段落【0021】))

“[0047] FIG. 1 shows a network 100 that comprises an embodiment of a multiplexing system. The network 100 comprises a mobile device 102, a server 104, and a data network 106. For the purpose of this description, it will be assumed that the data network 106 operates to communicate with one or more portable devices using OFDM technology; however, embodiments of the multiplexer system are suitable for use with other transmission technologies as well.”(『図1は、多重化システムの一実施形態を備える、ネットワーク100を表している。ネットワーク100は、モバイルデバイス102、サーバ104、及びデータネットワーク106を備えている。これの説明のために、データネットワーク106は、OFDM技術を用いて1つ以上の携帯型デバイスと通信する働きをすると仮定されよう。しかしながら、この多重化システムの実施形態は、同様に他の送信技術とともに用いることにも適している。』(段落【0030】))

“[0048] In an embodiment, the server 104 operates to provide services that may be subscribed to by devices in communication with the network 106. The server 104 is coupled to the network 106 through the communication link 108. The communication link 108 comprises any suitable communication link, such as a wired and/or wireless link that operates to allow the server 104 to communicate with the network 106. The network 106 comprises any combination of wired and/or wireless networks that allows services to be delivered from the server 104 to devices in communication with the network 106, such as the device 102.”(『一実施形態の中では、サーバ104は、ネットワーク106と通信するデバイスにより契約される可能性のあるサービスを提供する働きをする。サーバ104は、通信リンク108を通してネットワーク106に結合される。通信リンク108は、サーバ104がネットワーク106と通信するのを可能とさせる働きをする、有線及び/又は無線のリンクのような、任意の適切な通信リンクを備えている。ネットワーク106は、サービスが、サーバ104からデバイス102のようなネットワーク106と通信するデバイスに配信されることを可能とする、有線及び/又は無線の任意の組み合わせのネットワークを備えている。』(段落【0031】))

“[0049] It should be noted that the network 106 may communicate with any number and/or types of portable devices within the scope of the embodiments. For example, other devices suitable for use in embodiments of the multiplexer system include, but are not limited to, a personal digital assistant (PDA), email device, pager, a notebook computer, mp3 player, video player, or a desktop computer. The wireless link 110 comprises a wireless communication link based on OFDM technology; however, in other embodiments the wireless link may comprise any suitable wireless technology that operates to allow devices to communicate with the network 106.”(『ネットワーク106は、本実施形態の範囲内の、任意の数及び/又はタイプの携帯型デバイスと通信してもよい、ということに留意されたい。例えば、この多重化システムの実施形態の中で利用するのに適切な他のデバイスには、これらに限定するものではないものの、携帯情報端末(PDA)、eメールデバイス、ページャ、ノートブックコンピュータ、mp3プレーヤ、ビデオプレーヤ、又はデスクトップコンピュータが含まれる。無線リンク110は、OFDM技術に基づく無線通信リンクを備えているが、他の実施形態の中では、無線リンクは、デバイスがネットワーク106と通信することを可能にする働きをする、任意の適切な無線技術を備えてもよい。』(段落【0032】))

“[0050] The device 102 in this embodiment comprises a mobile telephone that communicates with the network 106 through the wireless link 110. The device 102 takes part in an activation process that allows the device 102 to subscribe to receive services over the network 106. In an embodiment, the activation process may be performed with the server 104; however, the activation process may also be performed with another server, service provider, content retailer, or other network entity. For the purpose of this description, it will be assumed that the device 102 performs the activation process with the server 104 and is now ready to subscribe and receive services from the server 104.”(『この実施形態におけるデバイス102は、無線リンク110を通してネットワーク106と通信する携帯電話を備えている。デバイス102は、デバイス102がネットワーク106を通してサービスを受けるために契約することを可能にする、起動処理に参加する。一実施形態の中では、この起動処理は、サーバ104で実行されてもよい。しかし、この起動処理は、同様に他のサーバ、サービスプロバイダ、コンテンツ小売業者、又は他のネットワークエンティティにより実行されてもよい。この説明のために、デバイス102は、サーバ104とともに起動処理を実行し、サーバ104からのサービスの契約及び受け取りの用意ができていると仮定されよう。』(段落【0033】))

“[0051] In an embodiment, the server 104 communicates with a real time media server (RTMS) 126 that comprises or has access to content that includes one or more real time (RT) services 112. The server 104 also communicates with a non real time media server (NRTMS) 128 that comprises or has access to one or more other than real time (ORT) services 120. For example, the services (112, 120) comprise multimedia content that includes news, sports, weather, financial information, movies, and/or applications, programs, scripts, or any other type of suitable content or service. Thus, the services (112, 120) may comprise video, audio or other information formatted in any suitable format. It should be noted that the server 104 may also communicate with one or more other media servers that comprise or have access to RT and/or ORT services. The services (112, 120) have associated delivery requirements that may include, but are not limited to bandwidth, priority, latency, type of service, and/or any other type of delivery requirement.”(『一実施形態の中では、サーバ104は、1つ以上のリアルタイム(RT)サービス112を含むコンテンツへのアクセスを備える又は有する、リアルタイムメディアサーバ(RTMS)126と通信する。サーバ104はまた、1つ以上のリアルタイム以外(ORT)のサービス120へのアクセスを備えるか又は有する、非リアルタイムメディアサーバ(NRTMS)128と通信する。例えば、サービス(112、120)は、ニュース、スポーツ、天気、金融情報、映画、及び/又はアプリケーション、プログラム、スクリプト、若しくは任意の他のタイプの適切なコンテンツ若しくはサービスを含む、マルチメディアコンテンツを備えている。従って、サービス(112、120)は、ビデオ、オーディオ、又は他の任意の適切なフォーマットの情報を備えていてもよい。サーバ104は、同様に、RT及び/又はORTサービスへのアクセスを備える又は有する1つ以上の他のメディアサーバと通信してもよいということに、留意されたい。サービス(112、120)は、これらに限定するものではないものの、帯域幅、プライオリティ、レーテンシ、サービスのタイプ、及び/又は他の任意のタイプの配信要求を含みうる、関連の配信要求を有する。』(段落【0034】))

“[0052] The server 104 also comprises a multiplexer (MUX) 114 that operates to efficiently multiplex one or more of the services (112, 120) into a transmission frame 122 based on the delivery requirements. For example the transmission frame is transmitted over the network 106 to the device 102, as shown by the path 118. A more detailed description of the MUX 114 is provided in another section of this document. As a result of the operation of the MUX 114, the services (112, 120) are optimally packed into the transmission frame 122 so that the delivery requirements (bandwidth, priority, latency, type of service, etc.) of the services (112, 120) are met, transmission bandwidth of the transmission frame 122 is efficiently utilized, and power at receiving device 102 is conserved. For example, by efficiently utilizing the available bandwidth, a mobile device can receive transmitted services over a short time interval, thereby conserving battery power.”(『サーバ104はまた、配信要求に基づいて送信フレーム122の中に1つ以上のサービス(112、120)を効率的に多重化する働きをする、多重化装置(MUX)114を備えている。例えば、送信フレームは、経路118によって示されるように、データネットワーク106を通してデバイス102に送信される。MUX114についてのより詳細な説明は、本明細書の他の章の中で提供されている。MUX114の動作の結果として、サービス(112、120)は、このサービス(112、120)についての配信要求(帯域幅、プライオリティ、レーテンシ、サービスのタイプ等)が満たされ、送信フレーム122の送信帯域幅が効率的に利用され、受信デバイス102における電力が節約されるように、最適に送信フレーム122の中に詰め込まれる。例えば、利用可能な帯域幅を効率的に利用することにより、モバイルデバイスは送信されるサービスを短い時間間隔で受信することができ、それによってバッテリー電力を節約する。』(段落【0035】))

“[0053] In an embodiment, the MUX 114 comprises a resize controller 116 that operates to control how the RT services 112 and/or the ORT services 120 are resized. For example, if selected RT services 112 to be multiplexed into the transmission frame 122 will not fit into the available bandwidth of the transmission frame 122, the resize controller 116 operates to control how those services are resized (or re-encoded) so as to reduce their bandwidth requirements. For example, the resize controller 116 communicates with the RTMS 126 to request selected resizing of a particular RT services. The resize controller 116 also operates in a similar fashion to communicate with the NRTMS 128 to control how selected ORT services 120 are resized. As a result of the operation of the resize controller 116, resized RT and ORT services will fit within the available bandwidth of the transmission frame 122. A more detailed description of the resize controller 116 is provided in another section of this document.”(『一実施形態の中では、MUX114は、どのようにRTサービス112及び/又はORTサービス120がリサイズされるかを制御する働きをするリサイズ制御部116を備えている。例えば、送信フレーム122の中に多重化されるべき選択されたRTサービス112が、送信フレーム122の利用可能な帯域幅の中に収まらない場合は、リサイズ制御部116が、これらのサービスを、これらの帯域幅要求を削減するためにどのようにリサイズ(又は再符号化)するかを制御する働きをする。例えば、リサイズ制御部116は、特定のRTサービスの選択されたリサイズを要求するために、RTMS126と通信する。リサイズ制御部116はまた、同様な形で、どのように選択されたORTサービス120がリサイズされるかを制御するために、NRTMS128と通信する働きをする。リサイズ制御部116の動作の結果として、リサイズされたRT及びORTサービスは、送信フレーム122の利用可能な帯域幅内に収まるであろう。リサイズ制御部116のより詳細な説明は、本明細書の他の章の中で提供されている。』(段落【0036】))

“[0054] In an embodiment, the device 102 comprises de-multiplexer (DE-MUX) logic 124 that operates to de-multiplex the transmission frame 122 to obtain the transmitted services (112, 120). Because the services have been efficiently multiplexed into the transmission frame 122, network bandwidth is conserved and the device 102 utilizes less power to receive the transmitted services. ”(『一実施形態の中では、デバイス102は、送信されるサービス(112、120)を得るために、送信フレーム122を逆多重化する働きをする、デマルチプレクサ(DE-MUX)ロジック124を備えている。これらのサービスは効率的に送信フレーム122の中に多重化されていることから、ネットワーク帯域幅は節約され、デバイス102は送信されるサービスを受信するためにより少ない電力しか使わない。』(段落【0037】))

“[0055] Therefore, embodiments of the multiplexing system operates to perform one or more of the following functions to provide efficient multiplexing of RT and ORT services into a transmission frame.
1. Receive or gain access to one or more RT and/or ORT services for transmission over a network.
2. Determine if the RT and/or ORT services will fit into the available bandwidth of a transmission frame.
3. If the RT and/or ORT services will not fit into the transmission frame, resize one or more selected RT and/or ORT services to reduce their bandwidth requirements.
4. Utilize embodiments of an allocation algorithm to assemble the transmission frame with original and/or resized RT services, and original and/or resized ORT services so that the frame is efficiently packed.
5. Transmit the transmission frame over a network to one or more receiving devices.”(『従って、この多重化システムの実施形態は、以下の機能の1つ以上を実行して、RT及びORTサービスの送信フレームへの効率的な多重化を提供する働きをする。
1.ネットワークを通しての送信のために、1つ以上のRT及び/又はORTサービスを受信するか又はこれらへのアクセスを得る。
2.RT及び/又はORTサービスが、送信フレームの利用可能な帯域幅の中に収まるかどうかを判断する。
3.RT及び/又はORTサービスが送信フレームの中に収まらない場合は、1つ以上の選択されたRT及び/又はORTサービスをリサイズして、これらの帯域幅要求を削減する。
4.割り当てアルゴリズムの実施形態を利用して、効率的にフレームに詰め込まれるように、元の及び/又はリサイズされたRTサービス、及び元の及び/又はリサイズされたORTサービスを伴う送信フレームを組み立てる。
5.1つ以上の受信デバイスに、ネットワークを通して上記の送信フレームを送信する。』(段落【0038】?【0043】))

“[0056] Therefore, in one or more embodiments, a multiplexing system operates to efficiently multiplex and transmit one or more RT and/or ORT services to devices on a data network. It should be noted that the multiplexing system is not limited to the implementations described with reference to FIG.1, and that other implementations are possible within the scope of the embodiments.”(『従って、1つ以上の実施形態の中で、多重化システムは、1つ以上のRT及び/又はORTサービスを効率的に多重化し、且つこれらをデータネットワーク上のデバイスへと送信するように動作する。この多重化システムは、図1に記述されたインプリメンテーションに限定されず、他のインプリメンテーションが本発明の実施形態の範囲の中で可能であるということに留意されたい。』(段落【0044】))

“[0057] FIG. 2 shows an embodiment of a server 200 for use in a multiplexing system. For example, the server 200 may be used as the server 104 in FIG. 1. The server 200 comprises processing logic 202, memory 204, and transceiver logic 206, all coupled to a data bus 208. The server 200 also comprises multiplexer (MUX) logic 210 and resize controller 212, which are also coupled to the data bus 208. It should be noted that the server 200 represents just one implementation and that other implementations are possible within the scope of the embodiments.”(『図2は、多重化システムの中で用いるサーバ200の一実施形態を示す。例えば、サーバ200は、図1のサーバ104として用いてもよい。サーバ200は、処理ロジック202、メモリ204、及びトランシーバロジック206を備え、これら全てはデータバス208に結合されている。サーバ200はまた、多重化装置(MUX)ロジック210及びリサイズ制御部212とを備え、これらは同様にデータバス208に結合されている。サーバ200は、ただ1つのインプリメンテーションを表すものであり、他のインプリメンテーションが本実施形態の範囲内で可能であるということに留意されたい。』(段落【0045】))

“[0058] In one or more embodiments, the processing logic 202 comprises a CPU, processor, gate array, hardware logic, memory elements, virtual machine, software, and/or any combination of hardware and software. Thus, the processing logic 202 generally comprises logic to execute machine-readable instructions and to control one or more other functional elements of the server 200 via the data bus 208.”(『1つ以上の実施形態の中では、処理ロジック202は、CPU、プロセッサ、ゲートアレイ、ハードウェアロジック、メモリ要素、バーチャルマシン、ソフトウェア、及び/又はハードウェアとソフトウェアとの任意の組み合わせを備えている。従って、処理ロジック202は、一般的に、機械で読み取り可能な命令を実行するための、及びサーバ200の1つ以上の他の機能要素をデータバス208を介して制御するためのロジックを備えている。』(段落【0046】))

“[0059] The transceiver logic 206 comprises hardware and/or software that operate to allow the server 200 to transmit and receive data and/or other information with remote devices or systems through the communication channel 214. For example, in an embodiment, the communication channel 214 comprises any suitable type of communication link to allow the server 200 to communicate directly with other servers or with one or more data networks and/or devices coupled to those data networks.”(『トランシーバロジック206は、サーバ200が、通信チャネル214を通して、リモートデバイス又はシステムとともにデータ及び/又は他の情報を送信及び受信することを可能とするように動作する、ハードウェア及び/又はソフトウェアを備えている。例えば、一実施形態では、通信チャネル214は、サーバ200が他のサーバ又は1つ以上のデータネットワーク及び/又はこれらのデータネットワークに結合されたデバイスと直接通信することを可能にする、任意の適切なタイプの通信リンクを備えている。』(段落【0047】))

“[0060] The memory 204 comprises any suitable type of storage device or element that allows the server 200 to store information parameters. For example, in an embodiment the memory 204 comprises any type of RAM, Flash memory, hard disk, or any other type of storage device.”(『メモリ204は、サーバ200が情報パラメータを格納することができるようにする、任意の適切なタイプの記憶デバイス又は要素を備えている。例えば、一実施形態では、メモリ204は、任意のタイプのRAM、フラッシュメモリ、ハードディスク、又は任意の他のタイプの記憶デバイスを備えている。』(段落【0048】))

“[0061] In an embodiment, the processing logic 202 operates to communicate with one or more content providers through the transceiver logic 208 and channel 214. For example, the processing logic 202 communicates with a RTMS to receive RT services 216 and a NRTMS to receive ORT services 218. For example, the RT services 216 and the ORT services 218 comprises one or more content flows that are to be delivered to devices on a network. Furthermore, the RT 216 and ORT 218 services have associated delivery requirements that include, but are not limited to, bandwidth, priority, latency, type of service, and/or any other type of delivery requirement.”(『一実施形態の中では、処理ロジック202は、トランシーバロジック208及びチャネル214を通して、1つ以上のコンテンツプロバイダと通信する働きをする。例えば、処理ロジック202は、RTサービス216を受信するためにRTMSと、ORTサービス218を受信するためにNRTMSと通信する。例えば、RTサービス216及びORTサービス218は、ネットワーク上のデバイスに配信されるべき1つ以上のコンテンツフローを備えている。更に、RTサービス216及びORTサービス218は、限定するものではないものの、帯域幅、プライオリティ、レーテンシ、サービスのタイプ、及び/又は任意の他のタイプの配信要求を含む、関連する配信要求を有する。』(段落【0049】))

“[0062] In one or more embodiments, the MUX logic 210 comprises a CPU, processor, gate array, hardware logic, memory elements, virtual machine, software, and/or any combination of hardware and software. The MUX logic 210 operates to multiplex one or more of the RT services 216 and/or ORT services 218 into a transmission frame based on the delivery requirements for transmission to devices using the transceiver logic 206 and the channel 214. For example, the MUX logic 210 operates to determine if selected ORT services 218, RT services 216, and Best Effort services (not shown) will fit into the available bandwidth of the transmission frame (with respect to their delivery requirements). For example, the Best Effort services comprise any type of data or information that needs to be transmitted. If the above flows will fit into the available bandwidth, the MUX logic 210 operates to pack them into the transmission frame according to one or more embodiments of algorithm described herein.”(『1つ以上の実施形態の中では、MUXロジック210は、CPU、プロセッサ、ゲートアレイ、ハードウェアロジック、メモリ要素、バーチャルマシン、ソフトウェア、及び/又はハードウェアとソフトウェアとの任意の組み合わせを備えている。MUXロジック210は、トランシーバロジック206及びチャネル214を用いてのデバイスへの送信のための配信要求に基づいて、送信フレームの中に、1つ以上のRTサービス216及び/又はORTサービス218を多重化する働きをする。例えば、MUXロジック210は、選択されたORTサービス218、RTサービス216、及びベストエフォートサービス(ここでは示されていない)が、送信フレームの利用可能な帯域幅(これらの配信要求に対しての)の中に収まるかどうかを判断する働きをする。例えば、ベストエフォートサービスは、送信が必要な任意のタイプのデータ又は情報を備えている。上記のフローが、利用可能な帯域幅に収まる場合は、MUXロジック210は、本明細書において説明されるアルゴリズムの1つ以上の実施形態に従って、これらを送信フレームの中に詰め込む働きをする。』(段落【0050】))

“[0063] If selected RT services 216 and/or ORT services 218 will not fit into the transmission frame, the MUX logic 210 signals the resize controller 212. The resize controller 212 operates to control how those services are resized to fit into the available bandwidth of the transmission frame. In an embodiment, the resize controller 212 operates to determine how much "resizing" a particular service needs to reduce its transmission bandwidth requirements and then assembles a resize request that is transmitted to the media server associated with that service. For example, the resize request is transmitted by the transceiver logic 206 using the communication link 214. The media server then operates to resize the service as requested. After the services have been resized to reduce their bandwidth requirements the MUX logic 210 is able to efficiently pack the original services and any resized services into the transmission frame. A more detailed description of allocation algorithms provided by the MUX logic 210 is provided in another section of this document.”(『選択されたRTサービス216及び/又はORTサービス218が、送信フレームに収まらない場合は、MUXロジック210は、リサイズ制御部212に信号を送る。リサイズ制御部212は、これらのサービスが送信フレームの利用可能な帯域幅に収まるように、どのようにリサイズされるかを制御する働きをする。一実施形態の中では、リサイズ制御部212は、特定のサービスが、これの送信帯域幅要求を削減するためにどれだけの「リサイズ」を必要としているのかを判断し、その後、このサービスに関連するメディアサーバに送信されるリサイズ要求をまとめる働きをする。例えば、リサイズ要求は、トランシーバロジック206によって、通信チャネル214を使って送信される。メディアサーバは、その後、要求されたようにこのサービスをリサイズする働きをする。帯域幅要求を低減するためにサービスがリサイズされた後、MUXロジック210は、送信フレームの中に、元のサービス及び任意のリサイズされたサービスを効率良く詰め込むことができる。MUXロジック210により提供される割り当てアルゴリズムについてのより詳細な説明は、本明細書の他の章の中で提供されている。』(段落【0051】))

“[0064] In one or more embodiments, the resize controller 212 comprises a CPU, processor, gate array, hardware logic, memory elements, virtual machine, software, and/or any combination of hardware and software. The resize controller 212 operates to control how one or more of the flows of the RT service 216 and the ORT services 218 are resized so that those flows will fit into the available bandwidth of a transmission frame. Thus, the resize controller 212 operates to resize one or more services so as to adjust its associated delivery requirements. For example, a service may be resized so that its bandwidth requirements are adjusted (i.e., reduced). In an embodiment, the resize controller 212 is part of the MUX logic 210. A more detailed description of the resize controller 212 is provided in another section of this document.”(『1つ以上の実施形態の中では、リサイズ制御部212は、CPU、プロセッサ、ゲートアレイ、ハードウェアロジック、メモリ要素、バーチャルマシン、ソフトウェア、及び/又はハードウェアとソフトウェアとの任意の組み合わせを備えている。リサイズ制御部212は、RTサービス216及びORTサービス218の1つ以上のフローをどのようにリサイズするかを制御する働きをし、これらのフローが送信フレームの利用可能な帯域幅の中に収まるようにする。従って、リサイズ制御部212は、1つ以上のサービスを、これに関連する配信要求を調整するためにリサイズする働きをする。例えば、サービスは、これの帯域幅要求が調整(すなわち削減)できるようにリサイズされてもよい。一実施形態の中では、リサイズ制御部212は、MUXロジック210の一部である。リサイズ制御部212のより詳細の説明は、本明細書の他の章の中で提供されている。』(段落【0052】))

“[0065] In an embodiment, the multiplexing system comprises a computer program having one or more program instructions ("instructions") stored on a computer-readable medium, which when executed by at least one processor, for instance, the processing logic 202, provides the functions of the multiplexing system described herein. For example, instructions may be loaded into the server 200 from a computer-readable media, such as a floppy disk, CDROM, memory card, FLASH memory device, RAM, ROM, or any other type of memory device or computer-readable medium that interfaces to the server 200. In another embodiment, the instructions may be downloaded into the server 200 from an external device or network resource that interfaces to the server 200 through the transceiver logic 206. The instructions, when executed by the processing logic 202, provide one or more embodiments of a multiplexing system as described herein.”(『一実施形態では、多重化システムは、コンピュータで読み取り可能な媒体上に格納された1つ以上のプログラム命令(「命令」)を有するコンピュータプログラムを備え、このコンピュータプログラムは、少なくとも1つのプロセッサ、例えば処理ロジック202により実行されると、本明細書の中で説明される多重化システムの機能を提供する。例えば、命令は、フロッピー(登録商標)ディスク、CDROM、メモリカード、フラッシュメモリデバイス、RAM、ROM、又はサーバ200に接続する任意の他のタイプのメモリデバイス若しくはコンピュータで読み取り可能な媒体などの、コンピュータで読み取り可能な媒体から、サーバ200の中にロードされてもよい。他の実施形態では、命令は、トランシーバロジック206を通して、外部のデバイスから又はサーバ200に接続するネットワークリソースから、サーバ200の中にダウンロードされてもよい。処理ロジック202により実行される時、命令は、本明細書において説明されるような多重化システムの1つ以上の実施形態を提供する。』(段落【0053】))

“[0066] Thus, the server 200 operates to provide embodiments of a multiplexing system to efficiently multiplex flows associated with the RT services 216 and the ORT services 218 into a transmission frame for transmission to devices on a network.”(『このように、サーバ200は、多重化システムの実施形態を提供する働きをし、ネットワーク上のデバイスに送信するための送信フレームの中に、RTサービス216及びORTサービス218に関連するフローを効率的に多重化する。』(段落【0054】))

“Transmission Frame Slot Allocation Algorithm
[0067] The following description describes a slot allocation algorithm for use in embodiments of a multiplexing system. In an embodiment, the slot allocation algorithm operates to allocate slots in a transmission frame to content flows associated with available RT and ORT services. The allocation algorithm operates to achieve efficient bandwidth utilization and thereby allows a receiving device to conserve power. In one or more embodiments, the allocation algorithm is performed by and/or under the control of the MUX logic 210.”(『<送信フレームスロット割り当てアルゴリズム> 以下の記述は、多重化システムの実施形態の中で用いるスロット割り当てアルゴリズムを説明している。一実施形態では、スロット割り当てアルゴリズムは、利用可能なRT及びORTサービスに関連するコンテンツフローに、送信フレーム内のスロットを割り当てする働きをする。割り当てアルゴリズムは、効率的な帯域幅利用を実現する働きをし、これにより受信デバイスが電力を節約することを可能にする。1つ以上の実施形態では、割り当てアルゴリズムは、MUXロジック210により及び/又はこれの制御の下で実行される。』(段落【0055】))

“[0068] For the purpose of this description, the transmission frame will be referred to hereinafter as a superframe. It should be noted that the superframe is just one implementation and that embodiments of the multiplexing system are suitable for use with other types of transmission frame implementations.”(『この説明のために、送信フレームは、以下においてスーパーフレームと呼ばれよう。スーパーフレームはただ1つのインプリメンテーションであり、この多重化システムの各実施形態は、他のタイプの送信フレームのインプリメンテーションとともに用いるのに適しているということに留意されたい。』(段落【0056】))

“[0069] In an embodiment, a superframe comprises a data symbol portion that is utilized for bandwidth allocation. The data symbol portion of a superframe is divided into four equal portions, which are referred to hereinafter as "frames." Data from services to be transmitted, which in an embodiment are in Reed Solomon (RS) blocks, are distributed equally over the four frames. Therefore, the operation of the slot allocation algorithm over a superframe is a repetition of the operation of the slot allocation algorithm over a frame. Thus, the following description describes slot allocation over a frame, but is equally applicable to an entire superframe. Additionally, the slot allocation algorithm discussed may be used to allocate slots for all types of services, including but not limited to, real time services, non real time services, and IP data cast.”(『一実施形態の中では、スーパーフレームは、帯域幅割り当てに利用されるデータシンボル部を備えている。スーパーフレームのデータシンボル部は、4つの同じ部分に分けられ、これらは以下において「フレーム」と呼ばれる。送信されるべきサービスからのデータ(一実施形態の中では、これはリードソロモン(RS)ブロックである)は、4つのフレーム全体に平等に分配される。従って、スーパーフレーム全体へのスロット割り当てアルゴリズムの動作は、1つのフレームに対するスロット割り当てアルゴリズムの動作の繰り返しである。従って、以下の記述は1つのフレームへのスロット割り当てを説明するが、しかしながら、これはスーパーフレーム全体に同様に適用可能である。加えて、論じられるスロット配置アルゴリズムは、リアルタイムサービス、非リアルタイムサービス、及びIPデータキャストを含む、しかしこれらに限定されない、全てのタイプのサービスに対してスロットを割り当てするために用いてもよい。』(段落【0057】))

“Algorithm Summary
[00123] In one or more embodiments, the allocation algorithm provides efficient packing of flows into a frame, thereby minimizing the "wake-up" frequency and "on- time" of a receiving device. For example, grouping channels of a service together reduces wake-up frequency, while transmitting a service at its maxSlotHeight reduces on-time.”(『(アルゴリズム概要)1つ以上の実施形態の中では、割り当てアルゴリズムは、フレームの中へのフローの効率的な詰め込みをもたらし、これにより、受信デバイスの「目を覚ます」頻度及び「オンタイム」を最小化する。例えば、サービスのチャネルを一緒にグループ化することは、目を覚ます頻度を低減し、一方maxSlotHeightでのサービスの送信は、オンタイムを削減する。』(段落【0131】))

“[00124] In an embodiment, if a slot allocation provided by the algorithm fails because of one of the four inequality conditions, the algorithm passes on directives to the resizing controller 212 that controls how services are resized. If the resizing controller 212 has services resized based on these directives, a packing solution is guaranteed.”(『一実施形態の中では、アルゴリズムにより提供されるスロット割り当てが4つの不等条件の中の1つのために失敗した場合、アルゴリズムは指令を、どのようにサービスをリサイズするか制御するリサイズ制御部212に伝える。リサイズ制御部212が、これらの指令に基づいてリサイズされたサービスを有している場合は、詰め込みの解決策は保証される。』(段落【0132】))

“[00125] FIG. 16 shows a frame 1600 that illustrates the operation of an embodiment of an allocation algorithm to pack RT services in such a way that unused slots are grouped in two areas. Collecting unused slots in fewer areas ensures better utilization of these slots by services that are lower in priority than the services that were input to the allocation algorithm. In an embodiment, ORT services may be packed into these areas. For example, in the frame 1600, the unused slots are groups in areas 1602 and 1604.”(『図16は、RTサービスを、使用されないスロットが2つの領域にグループ化されるような方法で詰め込む、割り当てアルゴリズムの実施形態の動作を説明する、フレーム1600を示す。使われないスロットをより少ない領域に集めるということは、割り当てアルゴリズムに入力されるサービスよりも低いプライオリティのサービスによる、これらのスロットのよりよい利用を確実にする。一実施形態では、ORTサービスがこれらの領域に詰め込まれてもよい。例えば、フレーム1600の中では、使用されないスロットは領域1602及び1604の中にグループ化される。』(段落【0133】))

“Real-Time Service Resizing Algorithm
[00126] In one or more embodiments, the resize controller 116 operates to control how services are resized so that they may be packed into a frame. For example, services are resized to adjust their associated delivery requirements. In an embodiment, one or more services are resized to reduce associated bandwidth requirements; however, the resize controller 116 operates to resize services to adjust any of the associated delivery requirements. The following description describes a resizing algorithm that operates to resize component streams in RT services. The conditions which give rise to the resizing of RT services are also provided. In an embodiment, the resize controller 116 operates to implement a resizing algorithm that determines resizing parameters. These parameters are then transmitted to the RTMS associated with the RT services in a resizing request. The RTMS then operates to resize the identified RT services according to the parameters in the resizing request.”(『(リアルタイムサービス・リサイズアルゴリズム)1つ以上の実施形態では、リサイズ制御部116は、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをする。例えば、サービスは、これらの関連する配信要求を調整するためにリサイズされる。一実施形態では、1つ以上のサービスが関連する帯域幅要求を低減するためにリサイズされる。しかしながら、リサイズ制御部116は、任意の関連する配信要求を調整するために、サービスをリサイズする働きをする。以下の記述は、RTサービスの中のコンポーネントストリームをリサイズする働きをする、リサイズアルゴリズムを説明している。RTサービスのリサイズを生じさせる条件も、同様に提供される。一実施形態では、リサイズ制御部116は、リサイズパラメータを決定するリサイズアルゴリズムを実行する働きをする。これらのパラメータは、次にリサイズ要求の中のRTサービスに関連するRTMSへと送信される。RTMSは次に、特定されたRTサービスを、上記のリサイズ要求の中のパラメータに従ってリサイズする働きをする。』(段落【0134】))

“[00127] It should also be noted that the resize controller 116 also operates to resize any ORT service. For example, the resize controller 116 is operable to determine how one or more ORT services should be resized and communication with any NRTMS to implement the determined resizing. As a result, delivery requirements associated with those services will be adjusted. For example, the resize controller 116 may communicate with a NRTMS to reduce the bandwidth requirement of an ORT service thereby adjusting its delivery requirements. Thus, the embodiments described herein with reference to resizing RT services are equally applicable to ORT services as well.”(『リサイズ制御部116はまた、任意のORTサービスをリサイズする働きもするということに留意されたい。例えば、リサイズ制御部116は、1つ以上のORTサービスがどのようにリサイズされるべきかを判断し、この決定したリサイズを実行するために任意のNRTMSと通信する働きをすることが可能である。結果として、これらのサービスに関連する配信要求が調整される。例えば、リサイズ制御部116は、あるORTサービスの帯域幅要求を低減するためにNRTMSと通信しても良く、これによりこのORTサービスの配信要求を調整する。従って、RTサービスのリサイズを参照して本明細書において説明された実施形態は、ORTサービスにも同じように適用可能である。』(段落【0135】))

“[00128] As shown in FIG. 1, the MUX 114 receives content flow data, and associated signaling data from the RTMS 126 and NRTMS 128. Every superframe, the MUX 114 negotiates data bandwidth with the RTMS 126 for all the active real time services and optionally with the NRTMS 128 for ORT services. In an embodiment, the bandwidth negotiation involves the following sequence of operations.
a. The MUX 114 sends a GetDataSize.Request message to the RTMS 126 to request data sizes for RT services to be sent in a superframe.
b. The RTMS 126 sends a GetDataSize.Response message to the MUX 114 specifying data sizes for the RT services to be sent in a superframe.
c. The MUX 114 performs content scheduling (alllocations) based on all the received data sizes from the RTMS 126 as well as from other sources.
d. The MUX 114 sends the updated sizes for the RT services flow data to the RTMS 126 as part of an UpdateDataSize.Notification message.”(『図1に示すように、MUX114は、コンテンツのフローデータ、及びRTMS126及びNRTMS128からの関連するシグナリングデータを受信する。スーパーフレームごとに、MUX114は、全てのアクティブなリアルタイムサービスに対してRTMS126と、且つ随意的にORTサービスに対してNRTMS128と、データ帯域幅を交渉する。一実施形態では、帯域幅交渉は、以下の動作シーケンスを含む。
a.MUX114は、あるスーパーフレームの中で送信すべきRTサービスに対するデータのサイズを要求するために、GetDataSize.Requestメッセージを、RTMS126に送る。
b.RTMS126は、スーパーフレームの中で送信すべき上記RTサービスに対するデータのサイズを指定する、GetDataSize.Responseメッセージを、MUX114に送る。
c.MUX114は、RTMS126及び他のソースから受信した全てのデータサイズに基づき、コンテンツのスケジューリング(割り当て)を実行する。
d.MUX114は、RTMS126に、RTサービスのフローデータに対する更新されたサイズを、UpdateDataSize.Notificationメッセージの一部として、送信する。』(段落【0136】?【0140】))

“[00129] In an embodiment, the MUX 114 operates to provide a content scheduling function that comprises embodiments of the slot allocation algorithm described above. The resize controller 116 provides embodiments of a resizing algorithm. The slot allocation algorithm is responsible for fitting the slots (rate) allocated to all the media services in a superframe. Certain systems constraints (e.g. peak throughput of the turbo decoder on the device limits the number of slots that can be assigned to a particular media service in a single OFDM symbol) can cause the slot allocation procedure to fail in spite of the total assigned slots being less than or equal to the total available slots in a superframe. Also, the real-time service component that is expected to dominate demand for air-link resources is video content. This content is compressed using source coding which results in a highly variable bit-rate flow. Finally, the capacity per superframe available for transmission of real time services may vary due to requirements of other concurrent media services. These factors lead to one of the following allocation conditions to occur.
1. The sum of all the data requested by the RT services is less than or equal to the available capacity and the slot allocation algorithm succeeds.
2. The sum of all the data requested by the RT services is less than or equal to the available capacity but the slot allocation algorithm fails.
3. The sum of all the data requested by the RT services is more than the available capacity.”(『一実施形態の中では、MUX114は、上述のスロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供する働きをする。リサイズ制御部116は、リサイズアルゴリズムの実施形態を提供する。このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させることに関与する。特定のシステム制約(例えば、デバイス上のターボ復号器の最大スループットが、単一のOFDMシンボルの中で特定のメディアサービスに与えることができるスロット数を制限する)が、与えられたスロットの合計がスーパーフレーム内の利用可能なスロットの総数を下回るか又はこれと同じにもかかわらず、スロット割り当て手続きの失敗をもたらす可能性がある。また、無線リンクリソースに対する要求を支配すると予想されるリアルタイムのサービスコンポーネントは、ビデオコンテンツである。このコンテンツは、非常に変化しやすいビットレートのフローに帰着する、ソースコーディングを用いて圧縮される。最後に、リアルタイムサービスの送信のために利用可能なスーパーフレーム当たりの容量は、他の同時に起こるメディアサービスの要求のために変化する可能性がある。これらの要因は、以下の割り当て状態の生起につながる。
1.RTサービスにより要求される全てのデータの合計が、利用可能な容量に満たないか又はこれに等しく、スロット割り当てアルゴリズムは成功する。
2.RTサービスにより要求される全てのデータの合計が、利用可能な容量に満たないか又はこれに等しいが、スロット割り当てアルゴリズムは失敗する。
3.RTサービスにより要求される全てのデータの合計が、利用可能な容量を超える。』(段落【0141】?【0144】))

“[00130] The allocation conditions 2 and 3 result in failure to allocate the amount of data requested by the RT service flows. In these scenarios, the MUX 114 invokes the resize controller 116 to perform a resize algorithm to resize RT services. The next section explains the concept of quality for the real time services and the objective of embodiments of the resize algorithm.”(『割り当て状態2及び3は、RTサービスフローにより要求されるデータの量の割り当ての失敗に帰着する。これらのシナリオでは、MUX114はリサイズ制御部116を起動して、RTサービスをリサイズするためにリサイズアルゴリズムを実行する。次の章は、リアルタイムサービスに対する品質の概念と、リサイズアルゴリズムの実施形態の目的を説明する。』(段落【0145】))

“Real Time Service Quality and Resize Algorithm Objective
[00131] The concept of quality is associated with the video flows within a real time streaming media service. The quality (Q) of a real-time service is a function of the bit rate (r) allocated to the service flows and is modeled by a quality function expressed as;
Q = f(r) (3)”(『(リアルタイムサービスの品質及びリサイズアルゴリズムの目的)品質の概念は、リアルタイムストリーミングメディアサービスの中のビデオフローに関連する。リアルタイムサービスの品質(Q)は、サービスフローに割り当てられるビットレート(r)の関数であり、またこれは以下で表される品質関数によりモデル化される。
Q=f(r) (3)
』(段落【0146】?【0147】))

“[00132] Every superframe, the RTMS 126 provides information which helps the MUX 114 evaluate this function. This is sent to the MUX 114 in the GetDataSize.Response message. As explained in the following sections, the MUX 114 uses this information for quality estimation of the real time service facilitating the resize procedure. It should also be noted that any selected quality measurement or characteristic can be used by the MUX 114 for quality estimation purposes.”(『スーパーフレーム毎に、RTMS126は、MUX114がこの関数を評価することを支援する情報を提供する。これは、MUX114へ、GetDataSize.Responseメッセージの中で送信される。以下の章で説明されるように、MUX114は、リサイズ手順を手助けして、この情報をリアルタイムサービスの品質見積もりのために用いる。任意の選択された品質測定又は特性は、品質見積もり目的のためにMUX114により用いられるということも同様に注目すべきである。』(段落【0147】))

“[00133] The resize algorithm assigns rates (in units of physical layer packets (PLPs)) to the real time services such that the total allocated rate is less than or equal to the available capacity for RT services so that the slot allocation algorithm succeeds. Thus, in an embodiment, the rate assignment for RT services should be such that the quality function of the RT service video flows is in proportion to their weights according to the following.
(Qi/Qj) = (Wi/Wj)
where Qi(Wi) and Qj(Wj) are quality functions (flow weights) for any RT services i, j. The quality function is estimated using equation (3) above. The weight value associated with a flow gives a measure of the relative significance of that flow amongst the other RT video flows. In an embodiment, the MUX 114 obtains these flow weight values from a Subscription and Provisioning Sub-system, which may also be responsible for service planning and management functions associated with a distribution network.”(『リサイズアルゴリズムは、レートを(物理レイヤパケット(PLP)を単位にして)、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がRTサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てる。従って、一実施形態の中では、RTサービスへのレートの割り当ては、RTサービスのビデオフローの品質関数が、以下に従って、これらの重量に比例するようにすべきである。
(Qi/Qj)=(Wi/Wj) (4)
ここで、Qi(Wi)及びQj(Wj)は、任意のRTサービスi、jに対する品質関数(フロー重量)である。品質関数は、上記の方程式(3)を用いて見積もられる。フローに関連する重量の値は、他のRTビデオフローとの間でのこのフローの相対的な重要性の尺度を与える。一実施形態の中では、MUX114はこれらのフローの重量値を、「契約プロビジョニングサブシステム」から取得し、このサブシステムは、流通ネットワークに関連するサービス計画・管理機能に同様に関与してもよい。』(段落【0148】?【0149】))

“Resize Algorithm
[00134] This section explains embodiments of the RT service resize algorithm. The algorithm uses an iterative approach to converge to a rate assignment for the video component streams (flows) in the RT services. The algorithm begins with the number of PLPs (rate) requested by each video stream. Each of the iterations of the algorithm involves identifying a candidate service for rate reduction. The candidate stream is one that is least sensitive to rate reduction and does not suffer an unfavorable reduction in quality in comparison with the other streams. In an embodiment, the functions of the resize algorithm are provided by the resize controller 212 shown in FIG. 2.”(『(リサイズアルゴリズム)この章では、RTサービスのリサイズアルゴリズムについての実施形態を説明する。このアルゴリズムは、RTサービスの中のビデオコンポーネントストリーム(フロー)に対するレート割り当てに集中する、反復アプローチを用いる。このアルゴリズムは、各ビデオストリームにより要求されるPLP数(レート)から始まる。アルゴリズムの反復のそれぞれには、レート削減のための候補サービスを特定することが含まれている。候補ストリームは、レート削減に最も鈍感であり、且つ他のストリームと比べて品質上好ましくない削減に苦しむことの無いストリームである。一実施形態では、リサイズアルゴリズムの機能は、図2に示すリサイズ制御部212により提供される。』(段落【0150】))

“[00135] After a candidate stream is identified, the rate allocated to that stream is reduced. For example, the rate may be reduced by an amount corresponding to two Reed-Solomon code blocks. The network assigns rates to all services with a granularity defined by the number of PLPs corresponding to one Reed-Solomon block. The video streams are assumed to be transmitted using one of the network's layered transmit modes with base and enhancement video components. In addition, the system constrains the data in the two video components to be equal. Hence, the choice of two Reed-Solomon blocks as the unit of rate reduction. However, it should be noted that it is within the scope of the embodiments to reduce the rate of a stream by any other selected amount.”(『候補ストリームが特定された後、このストリームに割り当てられるレートは削減される。例えば、レートは、2つのリードソロモンコードのブロックに相当する量だけ削減してもよい。ネットワークは、1つのリードソロモンブロックに相当するPLPの数で規定される細かさで、全てのサービスにレートを割り当てする。ビデオストリームは、基本及び強化ビデオコンポーネントを伴って、ネットワークの階層化された送信モードの1つを用いて送信されるものと思われる。加えて、システムは、この2つのビデオコンポーネントの中のデータが同等であるべきとの制約をかける。従って、レート削減の単位として、2つのリードソロモンブロックの選択となる。しかしながら、任意の他の選択された量だけストリームのレートを削減することは、本実施形態の範囲内であるということに留意されたい。』(段落【0151】))

“Constants
[00136] The following constant parameters are used in embodiments of a multiplexing system to provide a resize function.

rateReductionBnd
The upper bound on the fractional reduction in rate for any real time video stream. The bound is in reference to the rates requested by the streams. In an embodiment, a value of 0.5 is used.

sysMin
A minimum value for a stream's quality. It is used to prevent streams that have reached the rate reduction bound from further reduction in rate.

payloadPLP
Effective payload for a PLP, which is approximately 968 bits.”(『(定数)以下の定数パラメータが、リサイズ機能を提供するために、多重化システムの実施形態の中で用いられる。rateReductionBnd 任意のリアルタイムビデオストリームに対するレートの部分削減についての上限。この上限は、ストリームにより要求されるレートに関連してのものである。一実施形態の中では、0.5の値が用いられる。sysMin ストリームの品質に対する最小値。これは、レート削減上限に達したストリームが更にレート削減されるのを防ぐために用いられる。payloadPLP 1つのPLPに対する有効なペイロードであり、これはおよそ968ビットである。』(段落【0152】?【0156】))

“Algorithm Inputs
[00137] The following inputs are used in embodiments of a multiplexing system to provide a resize function.

maxRTSOFDMSym
Capacity in number of OFDM symbols per superframe available for the real time services. numRTS Number of real time services sharing the available capacity.

numVStreams
The total number of video component streams in the real time services. For example, VStream is a list of structures describing each real time video component stream.

_weight
Holds the relative weight value for the stream.

requestedPLPs
Holds the number of PLPs per superframe requested by the stream. It is possible to estimate the raw number of bits requested as requestedPLPs x payloadPLP (968 bits).

rsCodeParameterK
Parameter K for a Reed Solomon (N,K) code.”(『(アルゴリズムの入力)以下の入力が、リサイズ機能を提供するために、多重化システムの実施形態の中で用いられる。maxRTSOFDMSym リアルタイムサービスに対して利用可能なスーパーフレーム当たりの、OFDMシンボル数における容量。numRTS 利用可能な容量を共有するリアルタイムサービスの数。numVStreams リアルタイムサービスの中のビデオコンポーネントストリームの総数。例えば、VStreamは、それぞれのリアルタイムビデオコンポーネントストリームを記述する構造のリストである。_weight ストリームに対する相対的な重量値を保持する。requestedPLPs ストリームにより要求される、スーパーフレーム当たりのPLPの数を保持する。requestedPLPs×payloadPLP(968ビット)として、要求された生のビット数を見積もることが可能である。rsCodeParameterK リードソロモン(N、K)コードに対するパラメータK。』(段落【0156】?【0162】 ))

“Variables
[00138] The following variables are used in embodiments of a multiplexing system to provide a resize function.

reqPLPs [numVStreams]
Array indexed by a number (0 to numVStreams - 1) identifying the video component stream. The array holds the number of PLPs per superframe requested by this stream as indicated by the requestedPLPs member of the VStream structure.

assgnPLPs [numVStreams]
Array indexed by a number (0 to numVStreams - 1) identifying the video component stream. The array holds the number of PLPs per superframe assigned to this stream.

tempPLPs [numVStreams]
Array indexed by a number (0 to numVStreams - 1) identifying the video component stream. The array holds the number of PLPs per superframe assigned to the video component stream. This is a temporary variable used internally by the algorithm.

weight [numVStreams]
Array indexed by a number (0 to numVStreams - 1) identifying the video component stream. The array holds the relative weight value of the stream indicated by the _weight member of the VStream structure.

effQuality [numVStreams]
Array indexed by a number (0 to numVStreams - 1) identifying the video component stream. The array holds the estimated quality for the real time service stream.

PLPsPerRSBlk [numVStreams]
Array indexed by a number (0 to numVStreams - 1) identifying the video component stream. The array holds the number of data PLPs per Reed-Solomon code block as indicated by the rsCodeParameterK member of the VStream structure.”(『(変数)以下の変数が、リサイズ機能を提供するために、多重化システムの実施形態の中で用いられる。reqPLPs[numVStreams] ビデオコンポーネントストリームを特定する数(0?numVStreams-1)によりインデックスが付けられた配列。この配列は、VStream構造のrequestedPLPs部分により指示されるものとしての、このストリームにより要求されるスーパーフレーム当たりのPLP数を保持する。assgnPLPs[numVStreams] ビデオコンポーネントストリームを特定する数(0?numVStreams-1)によりインデックスが付けられた配列。この配列は、このストリームに割り当てられた、スーパーフレーム当たりのPLP数を保持する。tempPLPs[numVStreams] ビデオコンポーネントストリームを特定する数(0?numVStreams-1)によりインデックスが付けられた配列。この配列は、ビデオコンポーネントストリームに割り当てられた、スーパーフレーム当たりのPLP数を保持する。これは、アルゴリズムにより内部的に用いられる一時的変数である。weight[numVStreams] ビデオコンポーネントストリームを特定する数(0?numVStreams-1)によりインデックスが付けられた配列。この配列は、VStream構造の重量部分により表される、ストリームの相対的重量値を保持する。effQuality[numVStreams] ビデオコンポーネントストリームを特定する数(0?numVStreams-1)によりインデックスが付けられた配列。この配列は、リアルタイムサービスストリームに対する見積り品質を保持する。PLPsPerRSBlk[numVStreams] ビデオコンポーネントストリームを特定する数(0?numVStreams-1)によりインデックスが付けられた配列。この配列は、VStream構造のrsCodeParameterK部分により指示されるものとしての、リードソロモンコードブロック当たりのデータPLP数を保持する。』(段落【0163】?【0169】))

“[00144] Thus, the resize controller 212 operates to provide the above functions to resize services in embodiments of a multiplexing system. For example, the rate of a RT service is reduced to allow the service to be allocated to the available slots of a superframe as provided by embodiments of the allocation algorithm described above.”(『このようにして、リサイズ制御部212は、多重化システムの実施形態の中でサービスをリサイズするための上記の機能を提供する働きをする。例えば、上述の割り当てアルゴリズムの実施形態により提供されるように、RTサービスのレートは削減されて、このサービスがスーパーフレームの利用可能なスロットに割り当てされることを可能とする。』(段落【0184】))

“Interactions between Slot Allocation and Resize Algorithms
[00161] In the previous sections, embodiments of slot allocation and resize algorithms are described. The following sections provide a description of the overall interaction of these algorithms for use in embodiments of a multiplexing system.”(『(スロット割り当てアルゴリズム及びリサイズアルゴリズム間の相互作用)これまでの章の中で、スロット割り当てアルゴリズム及びリサイズアルゴリズムの実施形態が説明されている。以下の章は、多重化システムの実施形態の中で用いるこれらのアルゴリズムの全般的な相互作用についての記述を提供する。』(段落【0207】))

“[00162] FIG. 20 shows an embodiment of a method 2000 for providing slot allocation, resizing, and congestion control for use in a multiplexing system. For example, the server 200 operates to provide the functions described below.”(『図20は、多重化システムの中で用いる、スロット割り当て、リサイズ、及び輻輳制御を提供するための方法2000の一実施形態を示す。例えば、サーバ200は、以下に説明する機能を提供する働きをする。』(段落【0208】))

“[00163] At block 2002, high and medium priority ORT services are slot allocated.
For example, every superframe the MUX 114 gets the amount of various flow data and their relative priorities from content entities, such as the RTMS 126 and the NRTMS 128 using the GetDataSize.Response instruction. Using this information, slot allocation for high priority and medium priority ORT services is performed. For example, in an embodiment, the MUX logic 210 operates to perform slot allocation of high and medium priority ORT services according to the above algorithms.”(『ブロック2002では、高プライオリティ及び中プライオリティのORTサービスが、スロット割り当てされる。例えば、スーパーフレームごとに、MUX114は、さまざまなフローデータの量及びこれらの相対的プライオリティを、RTMS126及びNRTMS128などのコンテンツエンティティからGetDataSize.Response命令を用いて入手する。この情報を用いて、高プライオリティ及び中プライオリティのORTサービスに対するスロット割り当てが実行される。例えば、一実施形態の中では、MUXロジック210は、上記のアルゴリズムに従って高プライオリティ及び中プライオリティのORTサービスに対するスロット割り当てを実行する働きをする。』(段落【0209】))

“[00164] At block 2004, a test is performed to determine if the high and medium priority ORT service slot allocation was successful. If the allocation was successful, the method proceeds to block 2006. If the allocation was not successful, the method proceeds to block 2018.”(『ブロック2004では、高プライオリティ及び中プライオリティのORTサービスのスロット割り当てが成功かどうかを判断するテストが実行される。割り当てが成功だった場合には、方法はブロック2006に進む。割り当てが成功でなかった場合には、方法はブロック2018に進む。』(段落【0210】))

“[00165] At block 2018, congestion control is performed. Because the high and medium priority ORT service slot allocation was not successful, the system experiences congestion that needs to be addressed. In an embodiment, the MUX logic 210 performs a congestion control algorithm that is described with reference to FIG. 22. Upon returning from the congestion control the method stops at block 2028.”(『ブロック2018では、輻輳制御が実行される。高プライオリティ及び中プライオリティのORTサービスのスロット割り当てが成功でなかったことから、システムは対処の必要な輻輳に悩むことになる。一実施形態では、MUXロジック210は、図22を参照して説明される輻輳制御アルゴリズムを実行する。輻輳制御から戻り次第、方法はブロック2028で停止する。』(段落【0211】))

“[00166] At block 2006, based on the success of the ORT service slot allocation, the number of symbols available for RT services is computed and an iteration parameter is set to zero. For example, in an embodiment, the MUX logic 210 performs these functions.”(『ブロック2006では、ORTサービススロット割り当ての成功に基づいて、RTサービスに対して利用可能なシンボルの数が計算され、反復パラメータが0にセットされる。例えば、一実施形態では、MUXロジック210は、これらの機能を実行する。』(段落【0212】))

“[00167] At block 2008, slot allocation of RT service is carried out with the remaining symbols in the frame. For example, embodiments of the slot allocation algorithm described above are used to allocate slots to the RT services.”(『ブロック2008で、RTサービスのスロット割り当てが、フレーム内の残りのシンボルを使って実行される。例えば、上述のスロット割り当てアルゴリズムの実施形態は、RTサービスにスロットを割り当てるために用いられる。』(段落【0213】))

“[00168] At block 2010, a test is performed to determine if the RT services were successfully allocated. If the allocation was not successful, the method proceeds to block 2014. If the allocation was successful, the method proceeds to block 2012.”(『ブロック2010では、RTサービスが成功裏に割り当てされたかどうかを判断するテストが実行される。割り当てが成功でなかった場合には、方法はブロック2014に進む。割り当てが成功だった場合には、方法はブロック2012に進む。』(段落【0214】))

“[00169] At block 2012, the number of available symbols is decreased and the iteration parameter is increased. For example, in an embodiment, the MUX logic 210 performs these functions. The method then proceeds to block 2008 to slot allocated the RT services.”(『ブロック2012で、利用可能なシンボルの数が減じられ、反復パラメータが増加される。例えば、一実施形態では、MUXロジック210は、これらの機能を実行する。方法は次に、RTサービスにスロットを割り当てするためにブロック2008に進む。』(段落【0215】))

“[00170] At block 2014, a test is performed to determine if the iteration parameter is greater than zero. For example, in an embodiment, the MUX logic 210 performs these functions. If the iteration parameter is greater than zero, the method proceeds to block 2016. If the iteration parameter is not greater than zero, the method proceeds to block 2020.”(『ブロック2014では、反復パラメータがゼロより大きいかどうかを判断するテストが実行される。例えば、一実施形態では、MUXロジック210は、これらの機能を実行する。反復パラメータがゼロよりも大きい場合は、方法はブロック2016に進む。反復パラメータがゼロよりも大きくない場合は、方法はブロック2020に進む。』(段落【0216】))

“[00171] At block 2016, RT service slot allocation is performed using the numRTSymbols plus one. For example, the MUX logic 210 performs slot allocation for the RT services using the increased numRTSymbols value. The method then proceeds to block 2024.”(『ブロック2016で、RTサービススロット割り当てが、numRTSymbols+1を用いて実行される。例えば、MUXロジック210は、増加されたnumRTSymbols値を用いて、RTサービスに対してスロット割り当てを実行する。方法は次に、ブロック2024に進む。』(段落【0217】))

“[00172] At block 2020, selected RT services are resized. In an embodiment, a resize algorithm is used to resize the rate of one or more flow so that a RT service slot allocation can succeed. For example, the resize controller 212 operates to perform a resize algorithm described with reference to FIG. 22. Upon returning from the resize algorithm, the method proceeds to block 2022.”(『ブロック2020で、選択されたRTサービスがリサイズされる。一実施形態の中では、RTサービスのスロット割り当てが成功するように、1つ以上のフローのレートをリサイズするために、リサイズアルゴリズムが用いられる。例えば、リサイズ制御部212は、図22を参照して説明されるリサイズアルゴリズムを実行する働きをする。リサイズアルゴリズムから戻り次第、方法はブロック2022に進む。』(段落【0218】))

“[00173] At block 2022, a test is performed to determine if the resize of the RT services was successful. For example, there may be a situation where the resize algorithm fails to achieve a slot allocation with an acceptable lower bound video quality or lower bound resize ratios. If the resize was successful, the method proceeds to block 2024. If the resize was not successful, this situation means that the system is congested, and so the method proceeds to block 2018 to perform congestion control.”(『ブロック2022では、RTサービスのリサイズが成功だったかどうかを判断するテストが実行される。例えば、リサイズアルゴリズムが、許容できる下限ビデオ品質又は下限リサイズ率を伴うスロット割り当てに失敗する事態がありうる。リサイズが成功だった場合には、方法はブロック2024に進む。リサイズが成功でなかった場合には、この状態は、システムが輻輳していることを意味し、従って、方法は輻輳制御を実行するためにブロック2018に進む。』(段落【0219】))

“[00174] At block 2024, low priority ORT services are slot allocated in increasing order of rank. For example, the MUX logic 210 performs this function.”(『ブロック2024で、低プライオリティのORTサービスが、ランクが増えていく順にスロット割り当てされる。例えば、MUXロジック210が、この機能を行う。』(段落【0220】))

“[00175] At block 2026, Best Effort ORT service or data is slot allocated. For example, the MUX logic 210 performs this function. The method 2000 then ends at block 2028.”(『ブロック2026では、ベストエフォートORTサービス又はデータがスロット割り当てされる。例えば、MUXロジック210が、この機能を行う。方法2000は次に、ブロック2028で停止する。』(段落【0221】))

“[00176] Therefore, at the completion of the method 2000, the MUX 114 has the information on the exact data sizes of various flows that can be sent a superframe. This information is conveyed back to the RTMS 126 and the ORTMS 128 using the UpdateDataSize.Notification message.”(『従って、方法2000の完了時、MUX114はスーパーフレームで送ることができるさまざまなフローの、正確なデータサイズについての情報を有する。この情報は、RTMS126及びORTMS128に、UpdateDataSize.Notificationメッセージを用いて送り戻される。』(段落【0222】))

“[00177] It should be noted that the method 2000 represents just one implementation and the changes, additions, deletions, combinations or other modifications of the method 2000 are possible within the scope of the embodiments.”(『方法2000は、ただ1つのインプリメンテーションのみを表し、方法2000の変更、追加、削除、複合又は他の修正は、各実施形態の範囲の中で可能であるということに留意されたい。』(段落【0223】))

“[00178] FIG. 21 shows an embodiment of a method 2100 for providing resizing for use in a multiplexing system. For example, the method 2100 is suitable for use as block 2020 in FIG. 2000. In an embodiment, the resize controller 212 operates to provide the functions described below.”(『図21は、多重化システムの中で用いる、リサイズを提供するための方法2100の一実施形態を示す。例えば、方法2100は、図2000の中のブロック2020として用いるのに適している。一実施形態の中では、リサイズ制御部212は、以下に説明する機能を提供する働きをする。』(段落【0224】))

“[00179] At block 2102, the number of slots requested is evaluated and a parameter n is calculated. In an embodiment, n represents a ratio between the number of slots requested for a service and the number of slots available. For example, the resize controller 212 performs this calculation.”(『ブロック2102では、要求されたスロットの数が評価され、パラメータnが計算される。一実施形態では、nは、あるサービスのために要求されたスロットの数と、利用可能なスロットの数との比率を表す。例えば、リサイズ制御部212は、この計算を行う。』(段落【0225】))

“[00180] At block 2104, the quality of flows to be resized is evaluated. For example, after reducing the MLCs for each flow by n code blocks a quality evaluation is made. For example, the quality (Q) of a service is a function of the bit rate (r) allocated to the service flows and is modeled by the quality function expressed above. For example, the resize controller 212 performs this quality determination.”(『ブロック2104で、リサイズされるべきフローの品質が評価される。例えば、各フローに対するMLCをnコードブロックだけ削減した後に、品質評価がなされる。例えば、あるサービスの品質(Q)は、サービスフローに割り当てられたビットレート(r)の関数であり、またこれは上記で表される品質関数によりモデル化される。例えば、リサイズ制御部212は、この品質判定を行う。』(段落【0226】))

“[00181] At block 2106, the flow with the maximum resulting quality is determined (candidate). For example, the resize controller 212 determines the flow with the maximum quality that would result after performing the reduction of code blocks at block 2104.”(『ブロック2106では、結果としての最大品質を伴うフローが決定される(候補)。例えば、リサイズ制御部212は、ブロック2104において、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定する。』(段落【0227】))

“[00182] At block 2108, a test is performed to determine if the maximum quality is greater than a system minimum quality requirement. For example, the resize controller 212 determines the result of this test. If the maximum quality is not greater than the system minimum quality requirement, the method proceeds to block 2116. If the maximum quality is greater than the system minimum quality requirement, the method proceeds to block 2110.”(『ブロック2108で、最大品質がシステムの最小品質要求よりも大きいかどうかを判断するためのテストが実行される。例えば、リサイズ制御部212は、このテストの結果を判断する。最大品質が、システムの最小品質要求よりも大きくない場合は、方法はブロック2116に進む。最大品質が、システムの最小品質要求よりも大きい場合は、方法はブロック2110に進む。』(段落【0228】))

“[00183] At block 2110, the flow having the maximum quality is resized and slot allocation is performed. For example, the flow having the maximum quality is reduced by n code blocks and slot allocation is performed. For example, the resize controller 212 resizes the flow and requests the MUX logic 210 to perform a slot allocation.”(『ブロック2110では、最大品質を有するフローがリサイズされ、スロット割り当てが実行される。例えば、最大品質を有するフローがnコードブロックだけ削減され、スロット割り当てが実行される。例えば、リサイズ制御部212はフローをリサイズし、MUXロジック210にスロット割り当てを実行するよう要求する。』(段落【0229】))

“[00184] At block 2112, a test is performed to determine if the slot allocation was successful. For example, the resize controller 212 receives an indicator from the MUX logic 210 that indicates whether the slot allocation performed at block 2110 was successful. If the slot allocation was successful, the method proceeds to block 2114. If the slot allocation was not successful, the method proceeds to block 2102.”(『ブロック2112では、スロット割り当てが成功だったかどうかを判断するテストが実行される。例えば、リサイズ制御部212は、ブロック2110で実行されたスロット割り当てが成功だったかどうかを示す指標を、MUXロジック210から受信する。スロット割り当てが成功だった場合には、方法はブロック2114に進む。スロット割り当てが成功でなかった場合には、方法はブロック2102に進む。』(段落【0230】))

“[00185] At block 2114, the resize is determined to be successful, and at block 2116, the resize is determined to have failed. For example, the resize controller 212 makes these determinations. The method then proceeds to block 2118 where the method returns to block 2020 in FIG. 2000.”(『ブロック2114において、リサイズは成功と判断され、ブロック2116において、リサイズは失敗と判断される。例えば、リサイズ制御部212は、これらの判断を行う。方法は次に、ブロック2118に進み、ここで方法は図2000のブロック2020に戻る。』(段落【0231】))

“[00186] Therefore, the method 2100 operates to provide resizing for use in a multiplexing system. It should be noted that the method 2100 represents just one implementation and the changes, additions, deletions, combinations or other modifications of the method 2100 are possible within the scope of the embodiments.”(『このようにして、方法2100は、多重化システムの中で用いるリサイズを提供する働きをする。方法2100は、ただ1つのインプリメンテーションのみを表し、方法2100の変更、追加、削除、複合又は他の修正は、各実施形態の範囲の中で可能であるということに留意されたい。』(段落【0232】))














3.2.引用例記載の発明
ここで、上記記載を検討する。

第一に、上記段落[0008]の“In one or more embodiments, a multiplexing system, comprising methods and apparatus, is provided that operates to efficiently multiplex one or more content flows for transmission over a data network.”(「1つ以上の実施形態の中では、方法と装置を備え、データネットワークを通しての送信のために1つ以上のコンテンツフローを効率的に多重化する働きをする、多重化システムが提供される。」(段落【0008】))との記載、上記段落[0044][0047][0051][0052](段落【0021】【0030】【0034】【0035】)の記載、及び、Fig.1, Fig.2 の記載からみて、引用例記載の発明は「データネットワークを通しての送信のために1つ以上のコンテンツフローを効率的に多重化する働きをする多重化方法」である。
第二に、上記段落[0067]?[0069](段落【0055】?【0057】)の記載からみて、引用例記載の発明の「スロット割り当てアルゴリズムは、コンテンツフローに、スーパーフレーム内のスロットを割り当てするもの」であって、「割り当てアルゴリズムは、効率的な帯域幅利用を実現する働きを」するものである。
第三に、上記段落[0126]の“In one or more embodiments, the resize controller 116 operates to control how services are resized so that they may be packed into a frame. For example, services are resized to adjust their associated delivery requirements. In an embodiment, one or more services are resized to reduce associated bandwidth requirements; however, the resize controller 116 operates to resize services to adjust any of the associated delivery requirements. The following description describes a resizing algorithm that operates to resize component streams in RT services. The conditions which give rise to the resizing of RT services are also provided. In an embodiment, the resize controller 116 operates to implement a resizing algorithm that determines resizing parameters. These parameters are then transmitted to the RTMS associated with the RT services in a resizing request. The RTMS then operates to resize the identified RT services according to the parameters in the resizing request.”(『(リアルタイムサービス・リサイズアルゴリズム)1つ以上の実施形態では、リサイズ制御部116は、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをする。例えば、サービスは、これらの関連する配信要求を調整するためにリサイズされる。一実施形態では、1つ以上のサービスが関連する帯域幅要求を低減するためにリサイズされる。しかしながら、リサイズ制御部116は、任意の関連する配信要求を調整するために、サービスをリサイズする働きをする。以下の記述は、RTサービスの中のコンポーネントストリームをリサイズする働きをする、リサイズアルゴリズムを説明している。RTサービスのリサイズを生じさせる条件も、同様に提供される。一実施形態では、リサイズ制御部116は、リサイズパラメータを決定するリサイズアルゴリズムを実行する働きをする。これらのパラメータは、次にリサイズ要求の中のRTサービスに関連するRTMSへと送信される。RTMSは次に、特定されたRTサービスを、上記のリサイズ要求の中のパラメータに従ってリサイズする働きをする。』(段落【0134】))、段落[0128]の“As shown in FIG. 1, the MUX 114 receives content flow data, and associated signaling data from the RTMS 126 and NRTMS 128. Every superframe, the MUX 114 negotiates data bandwidth with the RTMS 126 for all the active real time services and optionally with the NRTMS 128 for ORT services.”(『図1に示すように、MUX114は、コンテンツのフローデータ、及びRTMS126及びNRTMS128からの関連するシグナリングデータを受信する。スーパーフレームごとに、MUX114は、全てのアクティブなリアルタイムサービスに対してRTMS126と、且つ随意的にORTサービスに対してNRTMS128と、データ帯域幅を交渉する。』(段落【0136】))、段落[00129]の“In an embodiment, the MUX 114 operates to provide a content scheduling function that comprises embodiments of the slot allocation algorithm described above. The resize controller 116 provides embodiments of a resizing algorithm. The slot allocation algorithm is responsible for fitting the slots (rate) allocated to all the media services in a superframe. Certain systems constraints (e.g. peak throughput of the turbo decoder on the device limits the number of slots that can be assigned to a particular media service in a single OFDM symbol) can cause the slot allocation procedure to fail in spite of the total assigned slots being less than or equal to the total available slots in a superframe. Also, the real-time service component that is expected to dominate demand for air-link resources is video content. This content is compressed using source coding which results in a highly variable bit-rate flow. Finally, the capacity per superframe available for transmission of real time services may vary due to requirements of other concurrent media services. These factors lead to one of the following allocation conditions to occur. 1. The sum of all the data requested by the RT services is less than or equal to the available capacity and the slot allocation algorithm succeeds. 2. The sum of all the data requested by the RT services is less than or equal to the available capacity but the slot allocation algorithm fails. 3. The sum of all the data requested by the RT services is more than the available capacity.”(『一実施形態の中では、MUX114は、上述のスロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供する働きをする。リサイズ制御部116は、リサイズアルゴリズムの実施形態を提供する。このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させることに関与する。特定のシステム制約(例えば、デバイス上のターボ復号器の最大スループットが、単一のOFDMシンボルの中で特定のメディアサービスに与えることができるスロット数を制限する)が、与えられたスロットの合計がスーパーフレーム内の利用可能なスロットの総数を下回るか又はこれと同じにもかかわらず、スロット割り当て手続きの失敗をもたらす可能性がある。また、無線リンクリソースに対する要求を支配すると予想されるリアルタイムのサービスコンポーネントは、ビデオコンテンツである。このコンテンツは、非常に変化しやすいビットレートのフローに帰着する、ソースコーディングを用いて圧縮される。最後に、リアルタイムサービスの送信のために利用可能なスーパーフレーム当たりの容量は、他の同時に起こるメディアサービスの要求のために変化する可能性がある。これらの要因は、以下の割り当て状態の生起につながる。 1.RTサービスにより要求される全てのデータの合計が、利用可能な容量に満たないか又はこれに等しく、スロット割り当てアルゴリズムは成功する。 2.RTサービスにより要求される全てのデータの合計が、利用可能な容量に満たないか又はこれに等しいが、スロット割り当てアルゴリズムは失敗する。 3.RTサービスにより要求される全てのデータの合計が、利用可能な容量を超える。』(段落【0141】?【0144】))、段落[0130]の“The allocation conditions 2 and 3 result in failure to allocate the amount of data requested by the RT service flows. In these scenarios, the MUX 114 invokes the resize controller 116 to perform a resize algorithm to resize RT services. The next section explains the concept of quality for the real time services and the objective of embodiments of the resize algorithm.”(「割り当て状態2及び3は、RTサービスフローにより要求されるデータの量の割り当ての失敗に帰着する。これらのシナリオでは、MUX114はリサイズ制御部116を起動して、RTサービスをリサイズするためにリサイズアルゴリズムを実行する。次の章は、リアルタイムサービスに対する品質の概念と、リサイズアルゴリズムの実施形態の目的を説明する。」(段落【0145】))との記載、及び、Fig.1, Fig.2 の記載からみて、引用例記載の発明は「MUX」、及び、その一部をなす「リサイズ制御部」を有し、「MUX」は「スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供」するものであって、この「スロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させることに関与する」ものであり、「リサイズ制御部」は「リサイズアルゴリズムの実施形態を提供する」ものであって「サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをする」ものである。
第四に、上記段落[00131]の“The concept of quality is associated with the video flows within a real time streaming media service. The quality (Q) of a real-time service is a function of the bit rate (r) allocated to the service flows and is modeled by a quality function expressed as; Q = f(r) (3)”(「品質の概念は、リアルタイムストリーミングメディアサービスの中のビデオフローに関連する。リアルタイムサービスの品質(Q)は、サービスフローに割り当てられるビットレート(r)の関数であり、またこれは以下で表される品質関数によりモデル化される。 Q=f(r) (3)」(段落【0146】【0147】))との記載、上記段落[00132]の“Every superframe, the RTMS 126 provides information which helps the MUX 114 evaluate this function. This is sent to the MUX 114 in the GetDataSize.Response message. As explained in the following sections, the MUX 114 uses this information for quality estimation of the real time service facilitating the resize procedure. It should also be noted that any selected quality measurement or characteristic can be used by the MUX 114 for quality estimation purposes.”(『スーパーフレーム毎に、RTMS126は、MUX114がこの関数を評価することを支援する情報を提供する。これは、MUX114へ、GetDataSize.Responseメッセージの中で送信される。以下の章で説明されるように、MUX114は、リサイズ手順を手助けして、この情報をリアルタイムサービスの品質見積もりのために用いる。任意の選択された品質測定又は特性は、品質見積もり目的のためにMUX114により用いられるということも同様に注目すべきである。』(段落【0147】))、上記段落[00133][00178][00179](段落【0148】【0149】【0224】【0225】)の記載、上記段落[00180]の“At block 2104, the quality of flows to be resized is evaluated. For example, after reducing the MLCs for each flow by n code blocks a quality evaluation is made. For example, the quality (Q) of a service is a function of the bit rate (r) allocated to the service flows and is modeled by the quality function expressed above. For example, the resize controller 212 performs this quality determination.”(『ブロック2104で、リサイズされるべきフローの品質が評価される。例えば、各フローに対するMLCをnコードブロックだけ削減した後に、品質評価がなされる。例えば、あるサービスの品質(Q)は、サービスフローに割り当てられたビットレート(r)の関数であり、またこれは上記で表される品質関数によりモデル化される。例えば、リサイズ制御部212は、この品質判定を行う。』(段落【0226】))の記載、上記段落[00181][00182](段落【0227】【0228】)の記載からみて、引用例記載の発明は「リサイズ制御部は、リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート(r)の関数である品質関数 Q = f(r) を利用」するものであって、この「品質」は「スーパーフレーム毎に、MUXへ、GetDataSize.Responseメッセージの中で送信される」ものである。
第五に、上記段落[00133]の“The resize algorithm assigns rates (in units of physical layer packets (PLPs)) to the real time services such that the total allocated rate is less than or equal to the available capacity for RT services so that the slot allocation algorithm succeeds. Thus, in an embodiment, the rate assignment for RT services should be such that the quality function of the RT service video flows is in proportion to their weights according to the following.
(Qi/Qj) = (Wi/Wj)
where Qi(Wi) and Qj(Wj) are quality functions (flow weights) for any RT services i, j. The quality function is estimated using equation (3) above. The weight value associated with a flow gives a measure of the relative significance of that flow amongst the other RT video flows. In an embodiment, the MUX 114 obtains these flow weight values from a Subscription and Provisioning Sub-system, which may also be responsible for service planning and management functions associated with a distribution network.”(『リサイズアルゴリズムは、レートを(物理レイヤパケット(PLP)を単位にして)、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がRTサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てる。従って、一実施形態の中では、RTサービスへのレートの割り当ては、RTサービスのビデオフローの品質関数が、以下に従って、これらの重量に比例するようにすべきである。 (Qi/Qj)=(Wi/Wj)(4) ここで、Qi(Wi)及びQj(Wj)は、任意のRTサービスi、jに対する品質関数(フロー重量)である。品質関数は、上記の方程式(3)を用いて見積もられる。フローに関連する重量の値は、他のRTビデオフローとの間でのこのフローの相対的な重要性の尺度を与える。一実施形態の中では、MUX114はこれらのフローの重量値を、「契約プロビジョニングサブシステム」から取得し、このサブシステムは、流通ネットワークに関連するサービス計画・管理機能に同様に関与してもよい。』(段落【0148】?【0149】))、段落[00181]の“At block 2106, the flow with the maximum resulting quality is determined (candidate). For example, the resize controller 212 determines the flow with the maximum quality that would result after performing the reduction of code blocks at block 2104.”(『ブロック2106では、結果としての最大品質を伴うフローが決定される(候補)。例えば、リサイズ制御部212は、ブロック2104において、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定する。』(段落【0227】))、段落[00182]の“At block 2108, a test is performed to determine if the maximum quality is greater than a system minimum quality requirement. For example, the resize controller 212 determines the result of this test. If the maximum quality is not greater than the system minimum quality requirement, the method proceeds to block 2116. If the maximum quality is greater than the system minimum quality requirement, the method proceeds to block 2110.”(『ブロック2108で、最大品質がシステムの最小品質要求よりも大きいかどうかを判断するためのテストが実行される。例えば、リサイズ制御部212は、このテストの結果を判断する。最大品質が、システムの最小品質要求よりも大きくない場合は、方法はブロック2116に進む。最大品質が、システムの最小品質要求よりも大きい場合は、方法はブロック2110に進む。』(段落【0228】))、段落[00183] の“At block 2110, the flow having the maximum quality is resized and slot allocation is performed. For example, the flow having the maximum quality is reduced by n code blocks and slot allocation is performed. For example, the resize controller 212 resizes the flow and requests the MUX logic 210 to perform a slot allocation.”(『ブロック2110では、最大品質を有するフローがリサイズされ、スロット割り当てが実行される。例えば、最大品質を有するフローがnコードブロックだけ削減され、スロット割り当てが実行される。例えば、リサイズ制御部212はフローをリサイズし、MUXロジック210にスロット割り当てを実行するよう要求する。』(段落【0229】))」、段落[00184]の“At block 2112, a test is performed to determine if the slot allocation was successful. For example, the resize controller 212 receives an indicator from the MUX logic 210 that indicates whether the slot allocation performed at block 2110 was successful. If the slot allocation was successful, the method proceeds to block 2114. If the slot allocation was not successful, the method proceeds to block 2102.”(『ブロック2112では、スロット割り当てが成功だったかどうかを判断するテストが実行される。例えば、リサイズ制御部212は、ブロック2110で実行されたスロット割り当てが成功だったかどうかを示す指標を、MUXロジック210から受信する。スロット割り当てが成功だった場合には、方法はブロック2114に進む。スロット割り当てが成功でなかった場合には、方法はブロック2102に進む。』(段落【0230】))、段落[00185]の“At block 2114, the resize is determined to be successful, and at block 2116, the resize is determined to have failed. For example, the resize controller 212 makes these determinations. The method then proceeds to block 2118 where the method returns to block 2020 in FIG. 2000.”(『ブロック2114において、リサイズは成功と判断され、ブロック2116において、リサイズは失敗と判断される。例えば、リサイズ制御部212は、これらの判断を行う。方法は次に、ブロック2118に進み、ここで方法は図2000のブロック2020に戻る。』(段落【0231】))との記載からみて、引用例記載の発明の「リサイズアルゴリズムは、レートを(物理レイヤパケット(PLP)を単位にして)、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がRTサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てる」ものであって「リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ、スロット割り当てが実行され、スロット割り当てが成功だった場合には、リサイズは成功と判断され」るものである。

したがって、引用例には以下の発明(以下「引用発明」という。)が記載されている。

「データネットワークを通しての送信のために1つ以上のコンテンツフローを効率的に多重化する働きをする多重化方法であって、
スロット割り当てアルゴリズムは、コンテンツフローに、スーパーフレーム内のスロットを割り当てするものであって、割り当てアルゴリズムは、効率的な帯域幅利用を実現する働きをするものであり、
MUX、及び、その一部をなすリサイズ制御部を有し、
MUXは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させることに関与するものであり、
リサイズ制御部は、リサイズアルゴリズムの実施形態を提供するものであって、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをするものであり、
リサイズ制御部は、リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート(r)の関数である品質関数 Q = f(r) を利用するものであり、
この品質は、スーパーフレーム毎に、MUXへ、GetDataSize.Responseメッセージの中で送信されるものであり、
リサイズアルゴリズムは、レートを(物理レイヤパケット(PLP)を単位にして)、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がRTサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てるものであって、リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ、スロット割り当てが実行され、スロット割り当てが成功だった場合には、リサイズは成功と判断される、
データネットワークを通しての送信のために1つ以上のコンテンツフローを効率的に多重化する働きをする多重化方法。」

4.対比
ここで、本願発明と引用発明を対比する。

4.1.「デジタルマルチメディアデータの流れを結合するための方法」
引用発明は「データネットワークを通しての送信のために1つ以上のコンテンツフローを効率的に多重化する働きをする多重化方法」であって、引用発明の「多重化」とは「1つ以上のコンテンツフロー」を結合する方法であるということができ、また、引用発明の「コンテンツフロー」と本願発明の「デジタルマルチメディアデータの流れ」が一致しているといえるから、引用発明は本願発明と同様に「デジタルマルチメディアデータの流れを結合するための方法」であるといえる。

4.2.「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」
4.2.1.「データセグメント」「複数のデータセグメント」「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」の解釈
本願発明の「データセグメント」「複数のデータセグメント」「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」が、どのような技術概念を指すのか、明細書の記載を参酌して以下検討する。

4.2.1.1.「データセグメント」とは
本願明細書には「データセグメント」について多数の記載があるが、「データセグメント」が何であるか言及されている記載として、

「【0230】
マルチメディア符号化デバイス2400は、マルチメディアデータの1つ以上の流れを含む複数のサービスを符号化し、符号化された流れを結合し、結合された流れを送信チャネル2402を介してマルチメディア復号デバイスに送信する。この開示の一側面においては、マルチメディア符号化デバイス2400は、ある期間にわたって受信されたデータの流れの一部分を符号化、結合及び送信する。一例として、マルチメディア符号化デバイス2400は、1秒ごとに流れに対して動作することができる。換言すると、マルチメディア符号化デバイス2400は、複数の流れのうちの1秒のデータセグメントを符号化し、1秒のデータセグメントを結合してデータのスーパーフレームを形成し、送信機2408を介して送信チャネル2402を通じてそのスーパーフレームを送信する。ここにおいて用いられる用語“スーパーフレーム”は、ある期間又はウィンドー、例えば1秒の期間又はウィンドー、にわたって収集されたデータセグメントのグループを指す。データセグメントは、1つ以上のデータフレームを含むことができる。この開示の技法は、1秒のデータセグメントに関して説明されるが、これらの技法は、その他のデータセグメントを結合及び送信するために、例えば固定された期間である場合とない場合がある異なる期間にわたって受信されたデータセグメントに関して、又は個々のデータフレーム又はデータフレームの組に関しても利用することができる。換言すると、スーパーフレームは、1秒の期間よりも長い又は短い時間間隔、又は時間が可変の間隔、を網羅するように定義することが可能である。」
「【0233】
符号器モジュール2404は、受信されたデータ流を少なくとも品質及びレート情報と関連づけることができる。より詳細に説明されるように、符号化モジュール2404は、流れのコンテンツを解析し、流れを、各々の品質及びレート情報、例えば品質-レート曲線、コンテンツ分類曲線又は品質-レートテーブルと関連づけることができる。品質及びレート情報は、特に、符号器モジュール2404が現在のスーパーフレーム内に含めることを希望するデータセグメントに関して異なる品質レベルでデータセグメントのサイズを示すことができる。符号器モジュール2404は、データセグメントと関連づけられた少なくとも品質及びレート情報をマルチプレクスモジュール2406に送る。符号器モジュール2404は、制御チャネルを介して品質及びレート情報をマルチプレクスモジュール2406に送ることができる。例えば、符号器モジュール2404は、マルチプレクスモジュール2406から受け取られた要求に応答して制御チャネルを介して品質及びレート情報を送ることができる。マルチプレクスモジュール2406及び符号器モジュール2404は、幾つかの異なる通信プロトコルを用いて通信することができる。一側面においては、マルチプレクスモジュール2406は、メッセージトランスポート層(MTL)を基本的なトランスポート機構として利用するプロトコルを用いて通信することができる。」

との記載がある。そして、段落【0230】の「マルチメディア符号化デバイス2400は、マルチメディアデータの1つ以上の流れを含む複数のサービスを符号化し、符号化された流れを結合し、結合された流れを送信チャネル2402を介してマルチメディア復号デバイスに送信する。」「換言すると、マルチメディア符号化デバイス2400は、複数の流れのうちの1秒のデータセグメントを符号化し、1秒のデータセグメントを結合してデータのスーパーフレームを形成し、送信機2408を介して送信チャネル2402を通じてそのスーパーフレームを送信する。ここにおいて用いられる用語“スーパーフレーム”は、ある期間又はウィンドー、例えば1秒の期間又はウィンドー、にわたって収集されたデータセグメントのグループを指す。データセグメントは、1つ以上のデータフレームを含むことができる。」との記載からみて、本願発明の「データセグメント」とは、デジタルマルチメディアデータの流れを符号化したものであって、「データセグメント」の長さは「1秒」のような固定した時間の長さで決められるものであり、「データセグメント」が複数「結合」されて「スーパーフレームを形成」するものであるということができる。

4.2.1.2.「複数のデータセグメント」とは
本願明細書及び図面には「複数のデータセグメント」について以下の記載がある。

「【0236】
複数のデータセグメントが利用可能な帯域幅内にぴったり納まらないことをマルチプレクスモジュール2406が決定した場合、例えば、スロット割り当てアルゴリズムが失敗であるか又は必要な送信チャネル資源の合計が利用可能な送信チャネル資源を超える場合は、マルチプレクスモジュール2406は、符号器モジュール2404から受け取られた品質及びレート情報に基づいてサイズが変更されるべき1つ以上のセグメントを選択する。マルチプレクスモジュール2406は、対応する縮小されたサイズにおける品質上の影響が最も小さいサイズが変更されるべきデータセグメントを選択することを試みる。以下においてより詳細に説明されるように、マルチプレクスモジュール2406は、品質-レート情報を解析してセグメントに対して割り当てられたビット数の減少後における各々のデータセグメントへの品質上の影響を決定し、縮小されたサイズにおいて最高のレベルを有するデータセグメントのうちの1つ以上を選択する。この方法により、マルチプレクスモジュールは、符号器モジュール2404のリアルタイムサービス間で裁定することができる。しかしながら、幾つかの場合においては、マルチプレクスモジュール2406は、関連づけられた配送要求事項に基づいてサイズが変更されるべき1つ以上のORTサービスを選択し、符号器モジュール2404のリアルタイムサービス及びORTサービス間で帯域幅を割り当てることができる。繰り返すと、ここにおける技法は、典型例を目的としてリアルタイムサービスに関して説明される。マルチプレクスモジュール2406は、依然として、上述される技法に従ってORTサービスを解析及びサイズ変更することができる。以上のように、以下の図において説明される技法は、リアルタイムサービスのサイズ変更により適用可能である。」
「【0261】
図27は、この開示の技法によりビット割り当てを管理する典型的マルチプレクスモジュール2700を例示するブロック図である。特に、マルチプレクスモジュール2700は、各々の符号器モジュール、例えば符号器モジュール2404(図24)、から複数のデータセグメントを受け取り、データセグメントを送るために必要なエアリンク資源が利用可能なエアリンク資源を超えないような形でデータセグメントのうちの1つ以上のサイズを変更するように要求する。マルチプレクスモジュール2700は、例えば、図24のマルチプレクスモジュール2406又は図25のマルチプレクスモジュール2506を表すことができる。マルチプレクスモジュール2700は、符号器モジュールインタフェース2702と、データ収集モジュール2086と、ビット管理モジュール2704と、を含む。ビット管理モジュール2704は、利用可能な帯域幅を割り当てる割り当てモジュール2708と、帯域幅割り当てが不成功であるときにデータセグメントのうちのいずれをサイズ変更すべきかを決定する選択モジュール2710と、を含む。」
「【0264】
ビット管理モジュール2704は、少なくとも品質及びレート情報を解析して複数のデータセグメントが送信チャネル2402の利用可能な帯域幅内にぴったり納まるかどうかを決定することができる。ビット管理モジュール2704は、品質及びレート情報に加えてその他の配送要求事項を解析することができる。例えば、ビット管理モジュール2704は、ORTサービスと関連づけられた優先度及びレーテンシー要求事項を解析することができる。ビット管理モジュール2704は、データセグメント間で利用可能な帯域幅を割り当てることを試みる割り当てモジュール2708を含むことができる。割り当てモジュール2708は、例えば、上述される割り当てアルゴリズムのうちの1つを用いて利用可能な帯域幅を割り当てることを試みることができる。利用可能な帯域幅を割り当てる第1の試みにおいては、割り当てモジュール2708は、データセグメントと関連づけられた目標品質レベルと各々の品質-レート曲線との間の交点に対応するサイズを用いて帯域幅を割り当てることを試みることができる。他の例として、マルチプレクスモジュール2406は、データセグメントと関連づけられた品質-レートテーブルにおいて指定される最高の品質レベルに対応するサイズを用いてデータセグメントが現在のスーパーフレーム内にぴったり納まるかどうかに関する最初の決定を行うことができる。割り当てモジュール2708がデータセグメント間において帯域幅を割り当てることに成功した場合、例えば、データセグメントを送る上での十分な送信チャネル資源が存在し及び余分の送信チャネル資源が存在しない場合は、サイズ変更は必要ない。」
「【図24】


「【図27】




ここで、上記段落【0236】の「複数のデータセグメントが利用可能な帯域幅内にぴったり納まらないことをマルチプレクスモジュール2406が決定した場合」、上記段落【0264】の「ビット管理モジュール2704は、少なくとも品質及びレート情報を解析して複数のデータセグメントが送信チャネル2402の利用可能な帯域幅内にぴったり納まるかどうかを決定することができる。」との記載における、これら「複数のデータセグメント」は「送信チャネル2402の利用可能な帯域幅内にぴったり納まるかどうかを決定する」対象となるものであるから、本願発明でいう「デジタルマルチメディアデータの流れを結合」した後のものであって、同時に伝送されるものである必要がある。また、上記段落【0261】の「特に、マルチプレクスモジュール2700は、各々の符号器モジュール、例えば符号器モジュール2404(図24)、から複数のデータセグメントを受け取り、データセグメントを送るために必要なエアリンク資源が利用可能なエアリンク資源を超えないような形でデータセグメントのうちの1つ以上のサイズを変更するように要求する」との記載は、上記【図24】に記載されるように「符号器モジュール2404」自体が複数存在しているところからみて、この「複数のデータセグメント」とは、この「マルチプレクスモジュール2700」でマルチプレクスする、すなわち、本願発明でいう「デジタルマルチメディアデータの流れを結合」する対象となる「複数のデータセグメント」であるということができる。
すなわち、これら段落【0236】【0261】【0264】の記載からは、本願発明の「複数のデータセグメント」とは、それが「デジタルマルチメディアデータの流れを結合」する前であれば、その「結合」の対象となるものであり、既に「デジタルマルチメディアデータの流れを結合」した後であれば「結合」した結果であって、同時に伝送される複数の「データセグメント」のことを指し「送信チャネル2402の利用可能な帯域幅内にぴったり納まるかどうかを決定する」対象となるものということができる。

4.2.1.3.「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」とは
本願明細書には「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」について以下の記載がある。

「【0233】
符号器モジュール2404は、受信されたデータ流を少なくとも品質及びレート情報と関連づけることができる。より詳細に説明されるように、符号化モジュール2404は、流れのコンテンツを解析し、流れを、各々の品質及びレート情報、例えば品質-レート曲線、コンテンツ分類曲線又は品質-レートテーブルと関連づけることができる。品質及びレート情報は、特に、符号器モジュール2404が現在のスーパーフレーム内に含めることを希望するデータセグメントに関して異なる品質レベルでデータセグメントのサイズを示すことができる。符号器モジュール2404は、データセグメントと関連づけられた少なくとも品質及びレート情報をマルチプレクスモジュール2406に送る。符号器モジュール2404は、制御チャネルを介して品質及びレート情報をマルチプレクスモジュール2406に送ることができる。例えば、符号器モジュール2404は、マルチプレクスモジュール2406から受け取られた要求に応答して制御チャネルを介して品質及びレート情報を送ることができる。マルチプレクスモジュール2406及び符号器モジュール2404は、幾つかの異なる通信プロトコルを用いて通信することができる。一側面においては、マルチプレクスモジュール2406は、メッセージトランスポート層(MTL)を基本的なトランスポート機構として利用するプロトコルを用いて通信することができる。」
「【0234】
マルチプレクスモジュール2406は、品質及びレート情報を受け取る。幾つかの場合においては、マルチプレクスモジュール2406は、配送要求事項、例えば1つ以上のORTサービスと関連づけられた優先度及びレーテンシーの要求事項を受け取ることもできる。マルチプレクスモジュール2406は、1つ以上の配送要求事項を解析し、符号器モジュール2404が現在のスーパーフレーム内に含めることを希望するデータセグメントが送信チャネル2402の利用可能な帯域幅内にぴったり納まるかどうかを決定する。マルチプレクスモジュール2406は、例えば、マルチメディア符号化デバイス2400の目標品質レベルとデータセグメントと関連づけられた各々の品質-レート曲線との間の交点に対応するサイズを用いてデータセグメントが現在のスーパーフレーム内にぴったり納まるかどうかについての最初の決定を行う。他の例として、マルチプレクスモジュール2406は、データセグメントと関連づけられた品質-レートテーブルにおいて指定される最高の品質レベルに対応するサイズを用いてデータセグメントが現在のスーパーフレーム内にぴったり納まるかどうかについての最初の決定を行うことができる。」
「【0235】
データセグメントが送信チャネル2402の利用可能な帯域幅内にぴったり納まるかどうかを決定するために、マルチプレクスモジュール2406は、品質レベルのうちの選択された1つに対応するサイズでデータセグメントの各々を送るために必要な送信資源量を決定し、データセグメントを送るために必要な送信チャネル資源量を合計し、及び全データセグメントによって要求される送信チャネル資源の合計量を利用可能な送信チャネル資源量と比較してデータセグメントを送る上での十分な送信チャネル資源が存在するかどうかを決定することができる。無線に関しては、送信チャネル資源は、エアリンク又はエアインタフェース資源を備えることができる。一側面例においては、マルチプレクスモジュール2406は、十分な送信チャネル資源が存在するかどうかを決定するためのスロット割り当てアルゴリズム、例えば上述されるスロット割り当てアルゴリズムのうちの1つ、を実行することができる。上記においてより詳細に説明されるように、マルチプレクスモジュール2406は、全サービス/セグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定するために符号器モジュール2404のデータセグメントと関連づけられた品質及びレート情報と連携してORTサービス配送要求事項を考慮に入れることもできる。」
「【0236】
複数のデータセグメントが利用可能な帯域幅内にぴったり納まらないことをマルチプレクスモジュール2406が決定した場合、例えば、スロット割り当てアルゴリズムが失敗であるか又は必要な送信チャネル資源の合計が利用可能な送信チャネル資源を超える場合は、マルチプレクスモジュール2406は、符号器モジュール2404から受け取られた品質及びレート情報に基づいてサイズが変更されるべき1つ以上のセグメントを選択する。マルチプレクスモジュール2406は、対応する縮小されたサイズにおける品質上の影響が最も小さいサイズが変更されるべきデータセグメントを選択することを試みる。以下においてより詳細に説明されるように、マルチプレクスモジュール2406は、品質-レート情報を解析してセグメントに対して割り当てられたビット数の減少後における各々のデータセグメントへの品質上の影響を決定し、縮小されたサイズにおいて最高のレベルを有するデータセグメントのうちの1つ以上を選択する。この方法により、マルチプレクスモジュールは、符号器モジュール2404のリアルタイムサービス間で裁定することができる。しかしながら、幾つかの場合においては、マルチプレクスモジュール2406は、関連づけられた配送要求事項に基づいてサイズが変更されるべき1つ以上のORTサービスを選択し、符号器モジュール2404のリアルタイムサービス及びORTサービス間で帯域幅を割り当てることができる。繰り返すと、ここにおける技法は、典型例を目的としてリアルタイムサービスに関して説明される。マルチプレクスモジュール2406は、依然として、上述される技法に従ってORTサービスを解析及びサイズ変更することができる。以上のように、以下の図において説明される技法は、リアルタイムサービスのサイズ変更により適用可能である。」
「【0244】
従って、図24の符号器モジュール2404の機能は、符号器モジュール2504とサイズ変更モジュール2502との間で分割される。換言すると、符号器モジュール2504は、利用可能な帯域幅をデータセグメントに割り当て、その割り当てが失敗したときにサイズが変更されるべきデータセグメントのうちの1つ以上を選択する際に用いるために各々のデータセグメントと関連づけられた品質及びレート情報をマルチプレクスモジュール2506に提供する。サイズ変更モジュール2502は、データセグメントのサイズを変更する要求をマルチプレクスモジュール2506から受け取り、マルチプレクスモジュール2506から受け取られたサイズ変更に従ってデータセグメントのサイズを変更する。」
「【0263】
ビット管理モジュール2704は、生成されたスーパーフレームの各々のスーパーフレームのサイズをモニタリングし、スーパーフレームを送るために必要な送信チャネル資源(例えば、エアリンク資源)が送信チャネル2402を通じての利用可能な送信チャネル資源を超過しないようにする。ビット管理モジュール2704がスーパーフレームのサイズをモニタリングするのを援助するため、データ収集モジュール2706は、各々の符号器モジュール2704から品質及びレート情報を受け取る。データ収集モジュール2706は、例えば、符号器モジュール2404が現在のスーパーフレーム内に含めることを希望する各データセグメントと関連づけられた配送要求事項、例えば品質及びレート情報、を要求する要求を各々の符号器モジュール2404に送ることができる。品質及びレート情報は、データセグメントに関する少なくとも品質評価基準をビットレート又はデータサイズの関数として示す。例えば、データ収集モジュール2706は、PSNR等の品質評価基準をモデル化するセグメントに対応する品質-レート曲線を、各々のデータセグメントに関するビットレートの関数として受け取ることができる。他の例においては、データ収集モジュール2706は、データセグメントと関連づけられた品質-レートテーブルを受け取る。上述されるように、品質-レートテーブルは、様々な順位(又は品質レベル)及び異なる順位の各々と関連づけられたサイズを示すことができる。従って、品質及びレート情報は、特に、符号器モジュール2404が現在のスーパーフレームにおいて送信することを希望するデータセグメントに関する異なる品質レベルにおけるデータセグメントのサイズを記述する。」
「【0264】
ビット管理モジュール2704は、少なくとも品質及びレート情報を解析して複数のデータセグメントが送信チャネル2402の利用可能な帯域幅内にぴったり納まるかどうかを決定することができる。ビット管理モジュール2704は、品質及びレート情報に加えてその他の配送要求事項を解析することができる。例えば、ビット管理モジュール2704は、ORTサービスと関連づけられた優先度及びレーテンシー要求事項を解析することができる。ビット管理モジュール2704は、データセグメント間で利用可能な帯域幅を割り当てることを試みる割り当てモジュール2708を含むことができる。割り当てモジュール2708は、例えば、上述される割り当てアルゴリズムのうちの1つを用いて利用可能な帯域幅を割り当てることを試みることができる。利用可能な帯域幅を割り当てる第1の試みにおいては、割り当てモジュール2708は、データセグメントと関連づけられた目標品質レベルと各々の品質-レート曲線との間の交点に対応するサイズを用いて帯域幅を割り当てることを試みることができる。他の例として、マルチプレクスモジュール2406は、データセグメントと関連づけられた品質-レートテーブルにおいて指定される最高の品質レベルに対応するサイズを用いてデータセグメントが現在のスーパーフレーム内にぴったり納まるかどうかに関する最初の決定を行うことができる。割り当てモジュール2708がデータセグメント間において帯域幅を割り当てることに成功した場合、例えば、データセグメントを送る上での十分な送信チャネル資源が存在し及び余分の送信チャネル資源が存在しない場合は、サイズ変更は必要ない。」

ここで、上記段落【0236】の「複数のデータセグメントが利用可能な帯域幅内にぴったり納まらないことをマルチプレクスモジュール2406が決定した場合、例えば、スロット割り当てアルゴリズムが失敗であるか又は必要な送信チャネル資源の合計が利用可能な送信チャネル資源を超える場合は、マルチプレクスモジュール2406は、符号器モジュール2404から受け取られた品質及びレート情報に基づいてサイズが変更されるべき1つ以上のセグメントを選択する。」との記載、段落【0244】の「換言すると、符号器モジュール2504は、利用可能な帯域幅をデータセグメントに割り当て、その割り当てが失敗したときにサイズが変更されるべきデータセグメントのうちの1つ以上を選択する際に用いるために各々のデータセグメントと関連づけられた品質及びレート情報をマルチプレクスモジュール2506に提供する。」との記載、段落【0263】の「ビット管理モジュール2704がスーパーフレームのサイズをモニタリングするのを援助するため、データ収集モジュール2706は、各々の符号器モジュール2704から品質及びレート情報を受け取る。データ収集モジュール2706は、例えば、符号器モジュール2404が現在のスーパーフレーム内に含めることを希望する各データセグメントと関連づけられた配送要求事項、例えば品質及びレート情報、を要求する要求を各々の符号器モジュール2404に送ることができる。品質及びレート情報は、データセグメントに関する少なくとも品質評価基準をビットレート又はデータサイズの関数として示す。例えば、データ収集モジュール2706は、PSNR等の品質評価基準をモデル化するセグメントに対応する品質-レート曲線を、各々のデータセグメントに関するビットレートの関数として受け取ることができる。他の例においては、データ収集モジュール2706は、データセグメントと関連づけられた品質-レートテーブルを受け取る。」、段落【0264】の「割り当てモジュール2708は、例えば、上述される割り当てアルゴリズムのうちの1つを用いて利用可能な帯域幅を割り当てることを試みることができる。利用可能な帯域幅を割り当てる第1の試みにおいては、割り当てモジュール2708は、データセグメントと関連づけられた目標品質レベルと各々の品質-レート曲線との間の交点に対応するサイズを用いて帯域幅を割り当てることを試みることができる。他の例として、マルチプレクスモジュール2406は、データセグメントと関連づけられた品質-レートテーブルにおいて指定される最高の品質レベルに対応するサイズを用いてデータセグメントが現在のスーパーフレーム内にぴったり納まるかどうかに関する最初の決定を行うことができる。」との記載からは、本願明細書記載の発明における「品質及びレート情報」は「各々のデータセグメントと関連づけられた」ものであることが読み取れる。
そして、上記『4.2.1.2.「複数のデータセグメント」とは』で述べたように、本願発明の「複数のデータセグメント」とは、それが「デジタルマルチメディアデータの流れを結合」する前であれば、その「結合」の対象となるものであり、既に「デジタルマルチメディアデータの流れを結合」した後であれば「結合」した結果であって、同時に伝送される複数の「データセグメント」のことを指すものということができるが、本願発明が「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取る」のは、上記明細書の記載からみて「デジタルマルチメディアデータの流れを結合」する前であると認められるから、結局、本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」の「複数のデータセグメント」とは、「前記デジタルマルチメディアデータの流れと関連づけられた」ものであり、「デジタルマルチメディアデータの流れを結合」する対象となるものであって、結合した後に同時に伝送される複数の「データセグメント」を指すということができる。
これに加えて、上記『4.2.1.1.「データセグメント」とは』で述べたように、本願発明の「データセグメント」とは、マルチメディアデータの流れを符号化したものである。

これらをまとめると、本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」における、「品質及びレート情報」は「各々のデータセグメントと関連づけられた」ものであり、「データセグメント」とはデジタルマルチメディアデータの流れを符号化したものであり、「複数のデータセグメント」とは、その「データセグメント」を複数まとめて「前記デジタルマルチメディアデータの流れと関連づけられた」ものであって、結局、本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」は、「デジタルマルチメディアデータの流れを結合する対象となる前記デジタルマルチメディアデータの流れと関連づけられ、結合した後に同時に伝送される複数のデータセグメントにおける、各々のデータセグメントと関連づけられた少なくとも品質及びレート情報」と解釈すべきものであるということができる。

4.2.2.本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」と引用発明の対比
『4.2.1.「データセグメント」「複数のデータセグメント」「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」の解釈』で検討した、これらの解釈、すなわち、

(1) 本願発明の「データセグメント」とは、マルチメディアデータの流れを符号化したものであって、「データセグメント」の長さは「1秒」のような固定した時間の長さで決められるものであり、「データセグメント」が複数「結合」されて「スーパーフレームを形成」するものである。
(2) 本願発明の「複数のデータセグメント」とは、それが「デジタルマルチメディアデータの流れを結合」する前であれば、その「結合」の対象となるものであり、既に「デジタルマルチメディアデータの流れを結合」した後であれば「結合」した結果であって、同時に伝送される複数の「データセグメント」のことを指し「送信チャネル2402の利用可能な帯域幅内にぴったり納まるかどうかを決定する」対象となるものである。
(3) 本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」とは、「デジタルマルチメディアデータの流れを結合する対象となる前記デジタルマルチメディアデータの流れと関連づけられ、結合した後に同時に伝送される複数のデータセグメントにおける、各々のデータセグメントと関連づけられた少なくとも品質及びレート情報」と解釈すべきものである。

を踏まえて、本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」と引用発明を以下対比する。

ここで、引用発明の「リサイズ制御部は、リサイズアルゴリズムの実施形態を提供するものであって、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをするものであり、リサイズ制御部は、リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート(r)の関数である品質関数 Q = f(r) を利用するものであり、この品質は、スーパーフレーム毎に、MUXへ、GetDataSize.Responseメッセージの中で送信されるものであり、リサイズアルゴリズムは、レートを(物理レイヤパケット(PLP)を単位にして)、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がRTサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てるものであって、リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ、スロット割り当てが実行され、スロット割り当てが成功だった場合には、リサイズは成功と判断される」ものである。

4.2.2.1.「品質及びレート情報」
引用発明の「ビットレート(r)の関数である品質関数 Q = f(r) 」は、ビットレートと品質の関数であるから、引用発明の「ビットレート(r)の関数である品質関数 Q = f(r) 」と本願発明の「品質及びレート情報」は、いずれも「品質及びレート」に関する情報である点で一致している。

4.2.2.2.「品質及びレート情報を受け取ること」
引用発明の「この品質は、スーパーフレーム毎に、MUXへ、GetDataSize.Responseメッセージの中で送信されるもの」であって、MUXは「品質」を受け取っているといえるから、引用発明と本願発明は「少なくとも品質及びレート情報を受け取る」点で一致する。

4.2.2.3.「複数のデータセグメント」
本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」の「複数のデータセグメント」とは、上記したように、それが「デジタルマルチメディアデータの流れを結合」する前であれば、その「結合」の対象となるものであり、既に「デジタルマルチメディアデータの流れを結合」した後であれば「結合」した結果であって、同時に伝送される複数の「データセグメント」のことを指し「送信チャネル2402の利用可能な帯域幅内にぴったり納まるかどうかを決定する」対象となるものである。
これに対し、引用発明の「リサイズ制御部は、リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート(r)の関数である品質関数 Q = f(r) を利用するものであり、この品質は、スーパーフレーム毎に、MUXへ、GetDataSize.Responseメッセージの中で送信されるものであ」るから、この「リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート(r)の関数である品質関数 Q = f(r)」は、「リアルタイムストリーミングメディアサービスのサービスフロー」毎に存在するのみならず、「スーパーフレーム毎」に存在するといえる。そして、引用発明は、更に「スロット割り当てアルゴリズムは、コンテンツフローに、スーパーフレーム内のスロットを割り当てするものであって」「スロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させることに関与するものであ」るから、引用発明の「スーパーフレーム」は、本願発明の「複数のデータセグメント」と同様に「利用可能な帯域幅内にぴったり納まるかどうかを決定する対象となる」ものであって、この点で引用発明の「スーパーフレーム」と本願発明の「複数のデータセグメント」が一致している。

4.2.2.4.「データセグメントに関する少なくとも品質及びレート情報を受け取ること」
上記『4.2.1.3.「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」とは』で述べたように、本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」とは、「デジタルマルチメディアデータの流れを結合する対象となる前記デジタルマルチメディアデータの流れと関連づけられ、結合した後に同時に伝送される複数のデータセグメントにおける、各々のデータセグメントと関連づけられた少なくとも品質及びレート情報」と解釈すべきものであって、本願発明の「品質及びレート情報」は「各々のデータセグメントと関連づけられた」ものである。
これに対し、上記『4.2.2.3.「複数のデータセグメント」』で述べたように、引用発明の「リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート(r)の関数である品質関数 Q = f(r)」は、「リアルタイムストリーミングメディアサービスのサービスフロー」毎、「スーパーフレーム毎」に存在するから、この「品質関数 Q = f(r)」は、それぞれの「スーパーフレーム」に対して「リアルタイムストリーミングメディアサービスのサービスフロー」の数だけ存在することとなり、逆にいえば、「スーパーフレーム」の中に複数存在する「リアルタイムストリーミングメディアサービスのサービスフロー」のそれぞれに関して「品質関数 Q = f(r)」があるといえる。
すなわち、引用発明の「スーパーフレーム」の中に複数存在する「リアルタイムストリーミングメディアサービスのサービスフロー」のそれぞれと、本願発明の「データセグメント」が対応し、更に、引用発明の「品質関数 Q = f(r)」も本願発明と同様に「データセグメントに関する少なくとも品質及びレート情報」であるといえる。そして、上記『4.2.2.2.「品質及びレート情報を受け取ること」』で述べたように、引用発明と本願発明は「少なくとも品質及びレート情報を受け取る」点で一致するから、結局、引用発明も本願発明と同様に「データセグメントに関する少なくとも品質及びレート情報を受け取ること」で一致している。

4.2.2.5.「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメント」
上記『4.2.1.3.「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」とは』で述べたように、本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」とは、「デジタルマルチメディアデータの流れを結合する対象となる前記デジタルマルチメディアデータの流れと関連づけられ、結合した後に同時に伝送される複数のデータセグメントにおける、各々のデータセグメントと関連づけられた少なくとも品質及びレート情報」と解釈すべきものであって、本願発明の「複数のデータセグメント」は「前記デジタルマルチメディアデータの流れと関連づけられた」ものである。
そして、上記『4.2.2.3.「複数のデータセグメント」』で述べたように、引用発明の「スーパーフレーム」と本願発明の「複数のデータセグメント」が一致し、上記『4.2.2.4.「データセグメントに関する少なくとも品質及びレート情報を受け取ること」』で述べたように、引用発明の「スーパーフレーム」の中に複数存在する「リアルタイムストリーミングメディアサービスのサービスフロー」のそれぞれと、本願発明の「データセグメント」が対応しているから、結局、引用発明も本願発明と同様に「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメント」を有しているといえる。

4.2.3.「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」についてのまとめ
したがって、引用発明と本願発明は「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」という点で一致しているといえる。

4.3.「前記複数のデータセグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定すること」
ここで、本願発明の「前記複数のデータセグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定すること」の「ぴったり納まる」とは、どのような技術概念なのか、また、引用発明の「スロット割り当てアルゴリズムは、コンテンツフローに、スーパーフレーム内のスロットを割り当てするものであり」、「MUXは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させることに関与するものであ」るが、この「うまく適合させる」とは、どのような技術概念なのか、本願明細書の記載、引用例の記載を参酌して以下検討する。

まず、本願明細書には、以下の記載がある。(なお、国際特許出願(PCT/US2008/052497)の特許協力条約第3条(2)に規定する明細書の対応箇所の記載を括弧内に併記する。))

「【0005】
前記マルチプレクスモジュールは、少なくとも前記品質及びレート情報を解析して前記符号器モジュールが送信することを希望するデータセグメントが送信チャネルの利用可能な帯域幅内にぴったり納まる(fit)かどうかを決定する。前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないと前記マルチプレクスモジュールが決定した場合は、前記マルチプレクスモジュールは、前記符号器モジュールから受け取られた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記セグメントのうちの1つ以上を選択する。マルチプレクスモジュールは、前記選択されたデータセグメントと関連づけられた前記符号器モジュールが前記縮小されたビット割り当てに従って前記データセグメントのサイズを変更するように要求する。」(“[0005] The multiplex module analyzes at least the quality and rate information to determine whether the segments of data that encoder modules desire to transmit fit within the available bandwidth of a transmission channel. If the multiplex module determines the plurality of segments of data do not fit within the available bandwidth, the multiplex module selects one or more of the segments to be resized based on at least the quality and rate information received from the encoder modules. Multiplex module requests the encoder modules associated with the selected segments of data to resize the segments of data in accordance with the reduced bit allocation.”)
「【0128】
一側面においては、MUX114は、上述されるスロット割り当てアルゴリズムの側面を備えるコンテンツスケジューリング機能を提供するために動作する。サイズ変更コントローラ116は、サイズ変更アルゴリズムの側面を提供する。スロット割り当てアルゴリズムは、スーパーフレーム内のすべてのメディアサービスに割り当てられたスロット(レート)をぴったり納める責任を有する。一定のシステム上の制約(例えば、デバイスのターボ復号器のピークスループットは、単一のOFDMシンボルにおいて特定のメディアサービスに割り当てることができるスロット数を制限する)は、割り当てられた総スロット数がスーパーフレームにおいて利用可能な総スロット数以下であるにもかかわらずスロット割り当て手順を失敗させる可能性がある。さらに、エアリンク資源要求の圧倒的割合を占めることが予想されるリアルタイムのサービス構成要素は、映像コンテンツである。このコンテンツは、ソースコーディングを用いて圧縮され、その結果可変性が非常に高いビートレート流になる。最後に、リアルタイムサービスの送信に関して利用可能なスーパーフレーム当たりの容量は、その他の同時並行するメディアサービスの要求事項に起因して変化する可能性がある。これらの要因は、以下の割り当て状態のうちの1つを生じさせる。」(“[00132] In an aspect, the MUX 114 operates to provide a content scheduling function that comprises aspects of the slot allocation algorithm described above. The resize controller 116 provides aspects of a resizing algorithm. The slot allocation algorithm is responsible for fitting the slots (rate) allocated to all the media services in a superframe. Certain systems constraints (e.g. peak throughput of the turbo decoder on the device limits the number of slots that can be assigned to a particular media service in a single OFDM symbol) can cause the slot allocation procedure to fail in spite of the total assigned slots being less than or equal to the total available slots in a superframe. Also, the real-time service component that is expected to dominate demand for air-link resources is video content. This content is compressed using source coding which results in a highly variable bit-rate flow. Finally, the capacity per superframe available for transmission of real time services may vary due to requirements of other concurrent media services. These factors lead to one of the following allocation conditions to occur.”)

上記段落【0005】には「前記マルチプレクスモジュールは、少なくとも前記品質及びレート情報を解析して前記符号器モジュールが送信することを希望するデータセグメントが送信チャネルの利用可能な帯域幅内にぴったり納まる(fit)かどうかを決定する。前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないと前記マルチプレクスモジュールが決定した場合は、前記マルチプレクスモジュールは、前記符号器モジュールから受け取られた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記セグメントのうちの1つ以上を選択する。」との記載が、上記段落【0128】には「スロット割り当てアルゴリズムは、スーパーフレーム内のすべてのメディアサービスに割り当てられたスロット(レート)をぴったり納める責任を有する。」との記載があり、これらは、それぞれ、国際特許出願(PCT/US2008/052497)の特許協力条約第3条(2)に規定する明細書の“The multiplex module analyzes at least the quality and rate information to determine whether the segments of data that encoder modules desire to transmit fit within the available bandwidth of a transmission channel. If the multiplex module determines the plurality of segments of data do not fit within the available bandwidth, the multiplex module selects one or more of the segments to be resized based on at least the quality and rate information received from the encoder modules.”(段落[0005])、“The slot allocation algorithm is responsible for fitting the slots (rate) allocated to all the media services in a superframe.”(段落[00132])との記載に対応するものと認められる。

これに対し、引用発明は「MUXは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させることに関与するものであ」るが、上記「3.2.引用例記載の発明」の「第三に」で述べたように、この「このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させることに関与する」とは、引用例の上記段落[00129]の“The slot allocation algorithm is responsible for fitting the slots (rate) allocated to all the media services in a superframe.”(「このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させることに関与する。」(段落【0141】))という部分に対応するものである。

そうすると、本願発明の「ぴったり納まる」は、国際特許出願(PCT/US2008/052497)の特許協力条約第3条(2)に規定する明細書の“fit”に対応するものであり、引用発明の「うまく適合させる」も“fit”に対応するものであるから、結局、引用発明の「うまく適合させる」と本願発明の「ぴったり納まる」は同じ意味であって、引用発明と本願発明は、いずれも「ぴったり納まる」ようにしている点で一致している。

更に、引用発明の「スロット割り当てアルゴリズムは、コンテンツフローに、スーパーフレーム内のスロットを割り当てするものであって、割り当てアルゴリズムは、効率的な帯域幅利用を実現する働きをするものであり」、「MUXは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させることに関与するものであ」り、「リサイズアルゴリズムは、レートを(物理レイヤパケット(PLP)を単位にして)、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がRTサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てるものであって、リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ、スロット割り当てが実行され、スロット割り当てが成功だった場合には、リサイズは成功と判断される」ものであって、この「スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させること」によって「効率的な帯域幅利用を実現」され、「スロット割り当てが成功だった場合には、リサイズは成功と判断される」のであるから、引用発明も本願発明と同様に「利用可能な帯域幅内にぴったり納まるかどうかを決定する」ことを行っているということができる。

そして、上記『4.2.「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」』で述べたように、引用発明の「スーパーフレーム」と本願発明の「複数のデータセグメント」が対応するということができる。

結局、引用発明と本願発明は「前記複数のデータセグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定すること」という点で一致する。

4.4.「前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないときに前記複数のデータセグメントと関連づけられた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記複数のデータセグメントのうちの1つ以上を選択すること」「前記複数のセグメントに関する前記利用可能な帯域幅を達成するために前記1つ以上の選択されたデータセグメントの各々のサイズ変更を要求すること」
引用発明は「MUX、及び、その一部をなすリサイズ制御部を有し、MUXは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させることに関与するものであり、リサイズ制御部は、リサイズアルゴリズムの実施形態を提供するものであって、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをするものであり、リサイズ制御部は、リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート(r)の関数である品質関数 Q = f(r) を利用するものであり、この品質はスーパーフレーム毎にMUXへ、GetDataSize.Responseメッセージの中で送信されるものであり、リサイズアルゴリズムは、レートを(物理レイヤパケット(PLP)を単位にして)、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がRTサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てるものであって、リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ、スロット割り当てが実行され、スロット割り当てが成功だった場合には、リサイズは成功と判断される」ものである。

第一に、上記『4.3.「前記複数のデータセグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定すること」』で述べたように、引用発明と本願発明は「前記複数のデータセグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定すること」という点で一致するから、引用発明も本願発明同様に「前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないときに」という判断をしているといえる。
第二に、上記『4.2.「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」』で述べたように、引用発明と本願発明は「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」という点で一致しており、引用発明の「リサイズ制御部」は、この「品質及びレート情報」に相当する「リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート(r)の関数である品質関数 Q = f(r) を利用」しているものであるから、引用発明と本願発明は「前記複数のデータセグメントと関連づけられた少なくとも前記品質及びレート情報」を利用している点で一致している。
第三に、引用発明は「MUXは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させることに関与するものであり」、「リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ」るものであって、上記『4.2.「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」』で述べたように、引用発明と本願発明は「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」という点で一致しており、また、上記『4.2.「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」』で述べたように、引用発明の「スーパーフレーム」と本願発明の「複数のデータセグメント」が対応することからみて、引用発明は本願発明の「前記複数のデータセグメントと関連づけられた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記複数のデータセグメントのうちの1つ以上を選択すること」および「前記複数のセグメントに関する前記利用可能な帯域幅を達成するために前記1つ以上の選択されたデータセグメントの各々のサイズ変更を要求すること」と同様の処理を行っているといえる。

したがって、引用発明と本願発明は「前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないときに前記複数のデータセグメントと関連づけられた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記複数のデータセグメントのうちの1つ以上を選択すること」「前記複数のセグメントに関する前記利用可能な帯域幅を達成するために前記1つ以上の選択されたデータセグメントの各々のサイズ変更を要求すること」を有する点で一致している。

4.5.「前記選択されたデータセグメントのサイズ変更を要求することは、前記選択されたデータセグメントに関する少なくとも最大サイズを指定することを備える」
本願発明は「前記選択されたデータセグメントのサイズ変更を要求することは、前記選択されたデータセグメントに関する少なくとも最大サイズを指定することを備える」ものであるが、この「最大サイズ」の意味について、明細書の記載を参酌して以下検討する。

本願明細書には「最大サイズ」という用語を用いた以下の記載がある。

「【0238】
選択されたデータセグメントと関連づけられた符号器モジュール2404は、各々のデータセグメントと関連づけられたサイズ変更要求を受け取り、マルチメディアデータセグメントのサイズを変更する。符号器モジュール2404は、幾つかの異なる方法でデータセグメントのサイズを変更することができる。選択されたデータセグメントと関連づけられた符号器モジュール2404は、1つ以上の符号化変数を調整し、データセグメントのサイズをサイズ変更要求において指定される最大サイズ以下に縮小することができる。例えば、符号化モジュール2404は、より高い量子化パラメータ(QP)を用いてデータセグメントを再符号化することができる。他の例として、符号化モジュール2404は、引き下げられた符号化レートでデータセグメントを再符号化することができる。代替として又は追加で、符号化モジュール2404は、符号化されるべき情報量を減らし、それによってデータセグメントのサイズを縮小することができる。幾つかの場合においては、符号化モジュール2404は、1つ以上の符号化変数を調整し、サイズ変更要求において指定されるサイズとなるデータセグメントのサイズを拡大することができる。例えば、符号化モジュール2404は、より小さいQPを用いてデータセグメントを再符号化するか又は引き上げられた符号化レートでデータセグメントを再符号化することができる。」
「【0258】
符号器モジュール2600と関連づけられたデータセグメントのうちのいずれかをサイズ変更する必要がある場合は、マルチプレクスモジュール(2406、2506)は、符号器モジュール2600にサイズ変更要求を送る。サイズ変更要求に応答して、サイズ変更モジュール2612は、マルチメディアデータセグメントのサイズを変更する。一例においては、サイズ変更モジュール2612は、データセグメントのサイズを大きくする、すなわち、データセグメントを拡大することができる。他の例においては、サイズ変更モジュール2612は、データセグメントのサイズを小さくする、すなわちデータセグメントを縮小する。データセグメントの縮小は、データセグメントの品質レベルを目標品質レベル以下に低下させる可能性がある。しかしながら、サイズが変更されたデータセグメントの品質レベルが最低品質レベルを下回る場合は、サイズ変更モジュール2612は、最低品質レベル以上であるサイズにデータセグメントのサイズを変更することしかできない。マルチプレクスモジュール(2406、2506)からのサイズ変更要求は、データセグメントに関するサイズ、例えば最大サイズ、を含むことができ、及びサイズ変更モジュール2612は、再符号化要求において指定されるサイズを達成するために1つ以上の符号化変数を調整することができる。サイズ変更モジュール2612は、例えば、データセグメントのサイズを変更するためにデータセグメントを調整されたビットレートで再符号化する、例えば、データセグメントがサイズ変更要求において指定される最大サイズ以下になるようにサイズ変更するためにデータセグメントを引き下げられたビットレートで再符号化することができる。他の例として、サイズ変更モジュール2612は、調整された量子化パラメータを用いてデータセグメントを再符号化することができる。」
「【0274】
上記のパラメータに基づき、選択モジュール2710は、4800kbpsのビットレートを第1のマルチメディアセグメントに割り当て、200kbpsのビットレートを第2のマルチメディアセグメントに割り当てる。1秒のデータセグメントの場合は、第1のデータセグメントの最大サイズは、4800キロビットで、第2のデータセグメントの最大サイズは200キロビットである。選択モジュール2710は、品質及びレート情報において示されるデータセグメントの推定サイズを計算された最大サイズと比較し、関連づけられた最大サイズを超えるいずれかのデータセグメントをサイズ変更されるべきセグメントとして選択する。」

ここで、上記段落【0238】の「選択されたデータセグメントと関連づけられた符号器モジュール2404は、1つ以上の符号化変数を調整し、データセグメントのサイズをサイズ変更要求において指定される最大サイズ以下に縮小することができる。」、段落【0258】の「サイズ変更モジュール2612は、例えば、データセグメントのサイズを変更するためにデータセグメントを調整されたビットレートで再符号化する、例えば、データセグメントがサイズ変更要求において指定される最大サイズ以下になるようにサイズ変更するためにデータセグメントを引き下げられたビットレートで再符号化することができる。」との記載からみて、本願発明の「最大サイズ」とは、それが指定されたときには、データセグメントのサイズを、指定された
「最大サイズ」以下に縮小するためのものであるということができる。更に、上記段落【0274】の「選択モジュール2710は、品質及びレート情報において示されるデータセグメントの推定サイズを計算された最大サイズと比較し、関連づけられた最大サイズを超えるいずれかのデータセグメントをサイズ変更されるべきセグメントとして選択する。」との記載からみて、本願発明の「最大サイズ」とは、更に、それが指定されたときには、「最大サイズ」を超えるデータセグメントがサイズ変更されるべきセグメントとして選択されるものであるともいうことができる。

以下、この解釈を踏まえて、本願発明の「前記選択されたデータセグメントのサイズ変更を要求することは、前記選択されたデータセグメントに関する少なくとも最大サイズを指定することを備える」と引用発明を比較する。

引用発明は「MUX、及び、その一部をなすリサイズ制御部を有し、MUXは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させることに関与するものであり、リサイズ制御部は、リサイズアルゴリズムの実施形態を提供するものであって、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをするものであり、リサイズ制御部は、リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート(r)の関数である品質関数 Q = f(r) を利用するものであり、この品質はスーパーフレーム毎にMUXへ、GetDataSize.Responseメッセージの中で送信されるものであり、リサイズアルゴリズムは、レートを(物理レイヤパケット(PLP)を単位にして)、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がRTサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てるものであって、リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ、スロット割り当てが実行され、スロット割り当てが成功だった場合には、リサイズは成功と判断される」ものである。

第一に、上記『4.4.「前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないときに前記複数のデータセグメントと関連づけられた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記複数のデータセグメントのうちの1つ以上を選択すること」「前記複数のセグメントに関する前記利用可能な帯域幅を達成するために前記1つ以上の選択されたデータセグメントの各々のサイズ変更を要求すること」』で述べたように、引用発明と本願発明は「選択されたデータセグメントのサイズ変更を要求する」点で一致している。
第二に、引用発明の「リサイズアルゴリズムは、レートを(物理レイヤパケット(PLP)を単位にして)、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がRTサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てるもの」であるから、「リアルタイムサービスに割り当て」られるのは「レート」であるが、引用発明の「レート」と本願発明の「選択されたデータセグメントに関する少なくとも最大サイズ」は、いずれも「データセグメント」の情報量に関するものであるという点で一致している。そして、通常、「データセグメントに関する」「サイズ」を、「データセグメントに関する」「レート」に換算するときには、その「データセグメント」の時間長による除算が必要となるが、上記『4.2.「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」』で述べたように、本願発明の「データセグメント」の長さは「1秒」のような固定した時間の長さで決められるものであって、それを前提とすると、本願発明の「データセグメントに関する」「サイズ」は、そのまま「データセグメントに関する」「レート」であるともいうことができるから、結局、引用発明の「レート」と本願発明の「サイズ」は同じものであるということができる。
第三に、引用発明において「レート」を「リアルタイムサービスに割り当てる」の「割り当てる」という行為自体は、いずれも、情報量に関する数値を与えるという点で、本願発明の「指定する」と同じ行為であるということができる。

しかしながら、引用発明のようにコンテンツの情報圧縮を行う場合、その圧縮率を指定するときに、圧縮後のコンテンツのレートの目標値の形で指定すること、および、この圧縮後のコンテンツのレートの目標値を、「平均レート」や「最大レート」等の形で指定することは、例を挙げるまでもなく極めて良く行われているといえるところ、引用例には、引用発明において「リアルタイムサービスに割り当て」られる「レート」が、これら「平均レート」や「最大レート」等の、いずれの「レート」であるのか記載されていないから、この「指定」される「サイズ」が、本願発明は「最大」サイズであるのに対し、引用発明ではどのようなものなのか明らかではない点で相違する。

したがって、引用発明と本願発明は「前記選択されたデータセグメントのサイズ変更を要求することは、前記選択されたデータセグメントに関する少なくともサイズを指定することを備える」点で一致し、この「指定」される「サイズ」が、本願発明は「最大」サイズであるのに対し、引用発明ではどのようなものなのか明らかではない点で相違する。

5.一致点・相違点
したがって、本願発明と引用発明1は以下の点で一致し、相違する。

[一致点]
「デジタルマルチメディアデータの流れを結合するための方法であって、
前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ることと、
前記複数のデータセグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定することと、
前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないときに前記複数のデータセグメントと関連づけられた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記複数のデータセグメントのうちの1つ以上を選択することと、
前記複数のセグメントに関する前記利用可能な帯域幅を達成するために前記1つ以上の選択されたデータセグメントの各々のサイズ変更を要求することと、
前記選択されたデータセグメントのサイズ変更を要求することは、前記選択されたデータセグメントに関する少なくともサイズを指定することを備える、方法。」

[相違点]
「指定」される「サイズ」が、本願発明は「最大」サイズであるのに対し、引用発明ではどのようなものなのか明らかではない点。

6.当審の判断
上記相違点について検討する。

引用発明の「MUXは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット(レート)を、うまく適合させることに関与するものであり、リサイズ制御部は、リサイズアルゴリズムの実施形態を提供するものであって、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをするものであり、リサイズ制御部は、リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート(r)の関数である品質関数 Q = f(r) を利用するものであり、この品質はスーパーフレーム毎にMUXへ、GetDataSize.Responseメッセージの中で送信されるものであり、リサイズアルゴリズムは、レートを(物理レイヤパケット(PLP)を単位にして)、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がRTサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てるものであって、リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ、スロット割り当てが実行され、スロット割り当てが成功だった場合には、リサイズは成功と判断される」ものである。ここで、「リサイズアルゴリズムは、レートを(物理レイヤパケット(PLP)を単位にして)、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がRTサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てる」ときに、この「リアルタイムサービスに割り当てる」「レート」として「最大レート」を用いることは、その「リアルタイムサービス」の符号化レートが経時的に変化するものであったとしても、それを用いることによって、「割り当てられたレートの合計がRTサービスに対する利用可能な容量より少ないか又はこれと同じになる」ことを必ず実現できることから、当業者が自然に選択することにすぎない。
そして、上記『4.5.「前記選択されたデータセグメントのサイズ変更を要求することは、前記選択されたデータセグメントに関する少なくとも最大サイズを指定することを備える」』で述べたように、本願発明の「データセグメント」の長さは「1秒」のような固定した時間の長さで決められるものであって、それを前提とすると、本願発明の「データセグメントに関する」「サイズ」は、そのまま「データセグメントに関する」「レート」であるともいうことができるから、本願発明のように「最大サイズ」を指定するようにしたことは、当業者が容易になしえたことにすぎない。

また、本願発明は、格別の作用効果を奏するものとも認められない。

したがって、本願発明は、引用発明に基づき当業者が容易に発明できたものである。

7.むすび
以上のとおり、平成26年1月30日付手続補正書で補正された請求項1に係る発明は、引用例に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条2項の規定により特許を受けることができない。

したがって、本願は平成26年1月30日付手続補正書で補正された請求項2?105に係る発明について特に検討するまでもなく拒絶されるべきものである。

よって、結論のとおり審決する。
 
審理終結日 2014-03-14 
結審通知日 2014-03-18 
審決日 2014-03-25 
出願番号 特願2009-548423(P2009-548423)
審決分類 P 1 8・ 121- WZ (H04N)
最終処分 不成立  
前審関与審査官 多賀 和宏  
特許庁審判長 松尾 淳一
特許庁審判官 千葉 輝久
渡辺 努
発明の名称 品質及びレート情報に基づいてマルチメディアコンテンツのサイズを変更するための方法及びシステム  
代理人 堀内 美保子  
代理人 峰 隆司  
代理人 白根 俊郎  
代理人 竹内 将訓  
代理人 砂川 克  
代理人 福原 淑弘  
代理人 中村 誠  
代理人 河野 直樹  
代理人 蔵田 昌俊  
代理人 井関 守三  
代理人 幸長 保次郎  
代理人 岡田 貴志  
代理人 野河 信久  
代理人 佐藤 立志  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ