【事件の表示】
　特願２００９−５４８４２３「品質及びレート情報に基づいてマルチメディアコンテンツのサイズを変更するための方法及びシステム」拒絶査定不服審判事件〔平成２０年　８月　７日国際公開、ＷＯ２００８／０９５０２０、平成２２年　５月２０日国内公表、特表２０１０−５１７４８６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、２００８年１月３０日（パリ条約による優先権主張外国庁受理２００７年１月３０日、米国）を国際出願日とする出願であって、平成２１年９月３０日付で審査請求がなされ、平成２３年１０月１２日付(起案日)で拒絶の理由が通知され、平成２４年４月１７日付で意見書及び手続補正書が提出されたものの、平成２４年６月８日付(起案日)で拒絶査定がなされたものである。　
　本件は、上記拒絶査定を不服として平成２４年１０月１２日に請求された拒絶査定不服審判であって、当審において、平成２５年７月２９日付(起案日)で拒絶の理由が通知され、平成２６年１月３０日付で意見書・手続補正書が提出されたものである。
　
２．本願発明
　本願の請求項１〜１０５に係る発明は、平成２４年４月１７日付、及び、平成２６年１月３０日付手続補正書で補正された明細書、特許請求の範囲及び図面の記載からみて、それぞれ、平成２６年１月３０日付手続補正書で補正された特許請求の範囲の請求項１〜１０５に記載されたとおりのものと認められるところ、その請求項１に係る発明は請求項１に記載された次のとおりである。（以下「本願発明」という。）　
　
「【請求項１】
　デジタルマルチメディアデータの流れを結合するための方法であって、
　前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ることと、
　前記複数のデータセグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定することと、
　前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないときに前記複数のデータセグメントと関連づけられた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記複数のデータセグメントのうちの１つ以上を選択することと、
　前記複数のセグメントに関する前記利用可能な帯域幅を達成するために前記１つ以上の選択されたデータセグメントの各々のサイズ変更を要求することと、を備え、
　前記選択されたデータセグメントのサイズ変更を要求することは、前記選択されたデータセグメントに関する少なくとも最大サイズを指定することを備える、方法。」
　
３．引用例・引用発明
３．１．引用例の記載事項
　当審における平成２５年７月２９日付の拒絶の理由で引用した国際公開第２００６／１１０８７６号(２００６年１０月１９日公開。以下「引用例」という。)には、図面と共に、以下の記載がある。(国際公開第２００６／１１０８７６号に対応する特表２００８−５３６４０９号公報の対応箇所の記載が、翻訳として適切であると認められるので、それを括弧内に併記する。)
　
“[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.”(『（背景）無線通信ネットワークのようなデータネットワークは、単一の端末に対してカスタマイズされるサービスと、多数の端末に提供されるサービスとの間のトレードオフをする必要がある。例えば、マルチメディアコンテンツの、リソースが制限された多数の携帯型デバイス（加入者）への配布は、複雑な問題である。従って、ネットワーク管理者、コンテンツ小売業者、及びサービスプロバイダにとって、コンテンツ及び／又は他のネットワークサービスを、ネットワーク接続されたデバイスに提供するために迅速且つ効率的なやり方で配布する方法を有することが非常に重要である。
』(段落【０００４】))
　
“[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.”(『現在のコンテンツ配信／メディア流通システムにおいては、リアルタイム及び非リアルタイムサービスが送信フレームの中に詰め込まれ、ネットワーク上のデバイスに配信される。例えば、通信ネットワークが、直交波周波数分割多重（ＯＦＤＭ）を、ネットワークサーバと１つ以上のモバイルデバイスとの間の通信を提供するために使用してもよい。この技術は、配信されるべきサービスが詰まったデータスロットを有しており且つ流通ネットワークを通して送信される、送信フレームを提供する。』(段落【０００５】))
　
“[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.”(『従って、必要なのは、従来のシステムの問題を克服し、これにより受信デバイスがコンテンツを電力効率のよいやり方で受信することを可能とする、データネットワーク上でコンテンツを効率的に送信するためのシステムである。』(段落【０００７】))
　
“[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.”(『１つ以上の実施形態の中では、方法と装置を備え、データネットワークを通しての送信のために１つ以上のコンテンツフローを効率的に多重化する働きをする、多重化システムが提供される。例えば、一態様によれば、このシステムは、送信フレーム内の利用可能なデータスロットの中にコンテンツフローを多重化する働きをする。コンテンツフローに関連するさまざまなパラメータ及び／又は情報に基づいてデータスロットを割り当てる、割り当てアルゴリズムが提供される。一態様によれば、このシステムはまた、利用可能なデータスロットに収まらない１つ以上のコンテンツフローに対してどのようにリサイズを実行するかを制御する働きをして、リサイズされたフローが利用可能なデータスロットの中に収まることができるようにする、リサイズ制御部を備えている。従って、システムは、データネットワークを通しての送信のために、コンテンツフローに関連する要求を満足し、送信コストを低減し、帯域幅の利用を増進させ、且つ受信デバイスの電力要求を低減するような方法で、１つ以上のコンテンツフローを効率的に多重化する働きをする。』(段落【０００８】))
　
“[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. ”(『一態様によれば、ネットワークを通してサービスを送信する方法が提供される。この方法は、関連する配信要求を有する１つ以上のサービスを受信することと、利用可能なネットワーク帯域幅は配信要求を満足することができないということを判断することとを備えている。方法はまた、１つ以上のサービスの少なくとも１つをリサイズして調整された配信要求を生成することと、この調整された配信要求に基づいて１つ以上のサービスに利用可能な帯域幅を割り当てしてネットワーク帯域幅割り当てを生成することとを、備えている。』(段落【００１４】))
　
“[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.”(『一態様によれば、ネットワークを通してサービスを送信する装置が提供される。この装置は、関連する配信要求を有する１つ以上のサービスを受信するように構成された受信ロジックと、１つ以上のサービスの少なくとも１つをリサイズして、調整された配信要求を生成するように構成されたリサイズ制御部とを備えている。装置はまた、利用可能なネットワーク帯域幅は前記配信要求を満足させることができないということを判断し、利用可能なネットワーク帯域幅を調整された配信要求に基づいて１つ以上のサービスに割り当てして、ネットワーク帯域幅割り当てを生成するように構成された、多重化ロジックを備える。』(段落【００１５】))
　
“[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.”(『一態様によれば、ネットワークを通してサービスを送信する装置が提供される。この装置は、関連する配信要求を有する１つ以上のサービスを受信する手段と、利用可能なネットワーク帯域幅は配信要求を満足することができないということを判断する手段とを備えている。装置はまた、１つ以上のサービスの少なくとも１つをリサイズして調整された配信要求を生成する手段と、この調整された配信要求に基づいて１つ以上のサービスに利用可能な帯域幅を割り当てしてネットワーク帯域幅割り当てを生成する手段とを、備えている。』(段落【００１６】))
　
“[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.”(『１つ以上の実施形態の中で、コンテンツフローを、データネットワークを通して送信するための送信フレームの中に多重化する働きをする、多重化システムが提供される。例えば、この多重化されたコンテンツフローは、特定の配置、順番、混合、及び／又はデバイスに送信するためのリアルタイムサービス及び／又は非リアルタイムサービスの選択を備えている。このシステムは、無線ネットワーク環境の中で用いるのに大変適しており、しかしながら、通信ネットワーク、インターネットのようなパブリックネットワーク、仮想プライベートネットワーク（ＶＰＮ）のようなプライベートネットワーク、ローカルエリアネットワーク、広域ネットワーク、長距離ネットワーク、又は他の任意の種類のデータネットワークを含む、しかしこれらに限定されない、任意の種類のネットワーク環境の中で用いてもよい。』(段落【００２１】))
　
“[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.”(『図１は、多重化システムの一実施形態を備える、ネットワーク１００を表している。ネットワーク１００は、モバイルデバイス１０２、サーバ１０４、及びデータネットワーク１０６を備えている。これの説明のために、データネットワーク１０６は、ＯＦＤＭ技術を用いて１つ以上の携帯型デバイスと通信する働きをすると仮定されよう。しかしながら、この多重化システムの実施形態は、同様に他の送信技術とともに用いることにも適している。』(段落【００３０】))
　
“[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.”(『一実施形態の中では、サーバ１０４は、ネットワーク１０６と通信するデバイスにより契約される可能性のあるサービスを提供する働きをする。サーバ１０４は、通信リンク１０８を通してネットワーク１０６に結合される。通信リンク１０８は、サーバ１０４がネットワーク１０６と通信するのを可能とさせる働きをする、有線及び／又は無線のリンクのような、任意の適切な通信リンクを備えている。ネットワーク１０６は、サービスが、サーバ１０４からデバイス１０２のようなネットワーク１０６と通信するデバイスに配信されることを可能とする、有線及び／又は無線の任意の組み合わせのネットワークを備えている。』(段落【００３１】))
　
“[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.”(『ネットワーク１０６は、本実施形態の範囲内の、任意の数及び／又はタイプの携帯型デバイスと通信してもよい、ということに留意されたい。例えば、この多重化システムの実施形態の中で利用するのに適切な他のデバイスには、これらに限定するものではないものの、携帯情報端末（ＰＤＡ）、ｅメールデバイス、ページャ、ノートブックコンピュータ、ｍｐ３プレーヤ、ビデオプレーヤ、又はデスクトップコンピュータが含まれる。無線リンク１１０は、ＯＦＤＭ技術に基づく無線通信リンクを備えているが、他の実施形態の中では、無線リンクは、デバイスがネットワーク１０６と通信することを可能にする働きをする、任意の適切な無線技術を備えてもよい。』(段落【００３２】))
　
“[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.”(『この実施形態におけるデバイス１０２は、無線リンク１１０を通してネットワーク１０６と通信する携帯電話を備えている。デバイス１０２は、デバイス１０２がネットワーク１０６を通してサービスを受けるために契約することを可能にする、起動処理に参加する。一実施形態の中では、この起動処理は、サーバ１０４で実行されてもよい。しかし、この起動処理は、同様に他のサーバ、サービスプロバイダ、コンテンツ小売業者、又は他のネットワークエンティティにより実行されてもよい。この説明のために、デバイス１０２は、サーバ１０４とともに起動処理を実行し、サーバ１０４からのサービスの契約及び受け取りの用意ができていると仮定されよう。』(段落【００３３】))
　
“[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.”(『一実施形態の中では、サーバ１０４は、１つ以上のリアルタイム（ＲＴ）サービス１１２を含むコンテンツへのアクセスを備える又は有する、リアルタイムメディアサーバ（ＲＴＭＳ）１２６と通信する。サーバ１０４はまた、１つ以上のリアルタイム以外（ＯＲＴ）のサービス１２０へのアクセスを備えるか又は有する、非リアルタイムメディアサーバ（ＮＲＴＭＳ）１２８と通信する。例えば、サービス（１１２、１２０）は、ニュース、スポーツ、天気、金融情報、映画、及び／又はアプリケーション、プログラム、スクリプト、若しくは任意の他のタイプの適切なコンテンツ若しくはサービスを含む、マルチメディアコンテンツを備えている。従って、サービス（１１２、１２０）は、ビデオ、オーディオ、又は他の任意の適切なフォーマットの情報を備えていてもよい。サーバ１０４は、同様に、ＲＴ及び／又はＯＲＴサービスへのアクセスを備える又は有する１つ以上の他のメディアサーバと通信してもよいということに、留意されたい。サービス（１１２、１２０）は、これらに限定するものではないものの、帯域幅、プライオリティ、レーテンシ、サービスのタイプ、及び／又は他の任意のタイプの配信要求を含みうる、関連の配信要求を有する。』(段落【００３４】))
　
“[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.”(『サーバ１０４はまた、配信要求に基づいて送信フレーム１２２の中に１つ以上のサービス（１１２、１２０）を効率的に多重化する働きをする、多重化装置（ＭＵＸ）１１４を備えている。例えば、送信フレームは、経路１１８によって示されるように、データネットワーク１０６を通してデバイス１０２に送信される。ＭＵＸ１１４についてのより詳細な説明は、本明細書の他の章の中で提供されている。ＭＵＸ１１４の動作の結果として、サービス（１１２、１２０）は、このサービス（１１２、１２０）についての配信要求（帯域幅、プライオリティ、レーテンシ、サービスのタイプ等）が満たされ、送信フレーム１２２の送信帯域幅が効率的に利用され、受信デバイス１０２における電力が節約されるように、最適に送信フレーム１２２の中に詰め込まれる。例えば、利用可能な帯域幅を効率的に利用することにより、モバイルデバイスは送信されるサービスを短い時間間隔で受信することができ、それによってバッテリー電力を節約する。』(段落【００３５】))
　
“[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.”(『一実施形態の中では、ＭＵＸ１１４は、どのようにＲＴサービス１１２及び／又はＯＲＴサービス１２０がリサイズされるかを制御する働きをするリサイズ制御部１１６を備えている。例えば、送信フレーム１２２の中に多重化されるべき選択されたＲＴサービス１１２が、送信フレーム１２２の利用可能な帯域幅の中に収まらない場合は、リサイズ制御部１１６が、これらのサービスを、これらの帯域幅要求を削減するためにどのようにリサイズ（又は再符号化）するかを制御する働きをする。例えば、リサイズ制御部１１６は、特定のＲＴサービスの選択されたリサイズを要求するために、ＲＴＭＳ１２６と通信する。リサイズ制御部１１６はまた、同様な形で、どのように選択されたＯＲＴサービス１２０がリサイズされるかを制御するために、ＮＲＴＭＳ１２８と通信する働きをする。リサイズ制御部１１６の動作の結果として、リサイズされたＲＴ及びＯＲＴサービスは、送信フレーム１２２の利用可能な帯域幅内に収まるであろう。リサイズ制御部１１６のより詳細な説明は、本明細書の他の章の中で提供されている。』(段落【００３６】))
　
“[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. ”(『一実施形態の中では、デバイス１０２は、送信されるサービス（１１２、１２０）を得るために、送信フレーム１２２を逆多重化する働きをする、デマルチプレクサ（ＤＥ−ＭＵＸ）ロジック１２４を備えている。これらのサービスは効率的に送信フレーム１２２の中に多重化されていることから、ネットワーク帯域幅は節約され、デバイス１０２は送信されるサービスを受信するためにより少ない電力しか使わない。』(段落【００３７】))
　
“[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.”(『従って、この多重化システムの実施形態は、以下の機能の１つ以上を実行して、ＲＴ及びＯＲＴサービスの送信フレームへの効率的な多重化を提供する働きをする。
　　　１．ネットワークを通しての送信のために、１つ以上のＲＴ及び／又はＯＲＴサービスを受信するか又はこれらへのアクセスを得る。
　　　２．ＲＴ及び／又はＯＲＴサービスが、送信フレームの利用可能な帯域幅の中に収まるかどうかを判断する。
　　　３．ＲＴ及び／又はＯＲＴサービスが送信フレームの中に収まらない場合は、１つ以上の選択されたＲＴ及び／又はＯＲＴサービスをリサイズして、これらの帯域幅要求を削減する。
　　　４．割り当てアルゴリズムの実施形態を利用して、効率的にフレームに詰め込まれるように、元の及び／又はリサイズされたＲＴサービス、及び元の及び／又はリサイズされたＯＲＴサービスを伴う送信フレームを組み立てる。
　　　５．１つ以上の受信デバイスに、ネットワークを通して上記の送信フレームを送信する。』(段落【００３８】〜【００４３】))
　
“[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.”(『従って、１つ以上の実施形態の中で、多重化システムは、１つ以上のＲＴ及び／又はＯＲＴサービスを効率的に多重化し、且つこれらをデータネットワーク上のデバイスへと送信するように動作する。この多重化システムは、図１に記述されたインプリメンテーションに限定されず、他のインプリメンテーションが本発明の実施形態の範囲の中で可能であるということに留意されたい。』(段落【００４４】))
　
“[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.”(『図２は、多重化システムの中で用いるサーバ２００の一実施形態を示す。例えば、サーバ２００は、図１のサーバ１０４として用いてもよい。サーバ２００は、処理ロジック２０２、メモリ２０４、及びトランシーバロジック２０６を備え、これら全てはデータバス２０８に結合されている。サーバ２００はまた、多重化装置（ＭＵＸ）ロジック２１０及びリサイズ制御部２１２とを備え、これらは同様にデータバス２０８に結合されている。サーバ２００は、ただ１つのインプリメンテーションを表すものであり、他のインプリメンテーションが本実施形態の範囲内で可能であるということに留意されたい。』(段落【００４５】))
　
“[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.”(『１つ以上の実施形態の中では、処理ロジック２０２は、ＣＰＵ、プロセッサ、ゲートアレイ、ハードウェアロジック、メモリ要素、バーチャルマシン、ソフトウェア、及び／又はハードウェアとソフトウェアとの任意の組み合わせを備えている。従って、処理ロジック２０２は、一般的に、機械で読み取り可能な命令を実行するための、及びサーバ２００の１つ以上の他の機能要素をデータバス２０８を介して制御するためのロジックを備えている。』(段落【００４６】))
　
“[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.”(『トランシーバロジック２０６は、サーバ２００が、通信チャネル２１４を通して、リモートデバイス又はシステムとともにデータ及び／又は他の情報を送信及び受信することを可能とするように動作する、ハードウェア及び／又はソフトウェアを備えている。例えば、一実施形態では、通信チャネル２１４は、サーバ２００が他のサーバ又は１つ以上のデータネットワーク及び／又はこれらのデータネットワークに結合されたデバイスと直接通信することを可能にする、任意の適切なタイプの通信リンクを備えている。』(段落【００４７】))
　
“[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.”(『メモリ２０４は、サーバ２００が情報パラメータを格納することができるようにする、任意の適切なタイプの記憶デバイス又は要素を備えている。例えば、一実施形態では、メモリ２０４は、任意のタイプのＲＡＭ、フラッシュメモリ、ハードディスク、又は任意の他のタイプの記憶デバイスを備えている。』(段落【００４８】))
　
“[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.”(『一実施形態の中では、処理ロジック２０２は、トランシーバロジック２０８及びチャネル２１４を通して、１つ以上のコンテンツプロバイダと通信する働きをする。例えば、処理ロジック２０２は、ＲＴサービス２１６を受信するためにＲＴＭＳと、ＯＲＴサービス２１８を受信するためにＮＲＴＭＳと通信する。例えば、ＲＴサービス２１６及びＯＲＴサービス２１８は、ネットワーク上のデバイスに配信されるべき１つ以上のコンテンツフローを備えている。更に、ＲＴサービス２１６及びＯＲＴサービス２１８は、限定するものではないものの、帯域幅、プライオリティ、レーテンシ、サービスのタイプ、及び／又は任意の他のタイプの配信要求を含む、関連する配信要求を有する。』(段落【００４９】))
　
“[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.”(『１つ以上の実施形態の中では、ＭＵＸロジック２１０は、ＣＰＵ、プロセッサ、ゲートアレイ、ハードウェアロジック、メモリ要素、バーチャルマシン、ソフトウェア、及び／又はハードウェアとソフトウェアとの任意の組み合わせを備えている。ＭＵＸロジック２１０は、トランシーバロジック２０６及びチャネル２１４を用いてのデバイスへの送信のための配信要求に基づいて、送信フレームの中に、１つ以上のＲＴサービス２１６及び／又はＯＲＴサービス２１８を多重化する働きをする。例えば、ＭＵＸロジック２１０は、選択されたＯＲＴサービス２１８、ＲＴサービス２１６、及びベストエフォートサービス（ここでは示されていない）が、送信フレームの利用可能な帯域幅（これらの配信要求に対しての）の中に収まるかどうかを判断する働きをする。例えば、ベストエフォートサービスは、送信が必要な任意のタイプのデータ又は情報を備えている。上記のフローが、利用可能な帯域幅に収まる場合は、ＭＵＸロジック２１０は、本明細書において説明されるアルゴリズムの１つ以上の実施形態に従って、これらを送信フレームの中に詰め込む働きをする。』(段落【００５０】))
　
“[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.”(『選択されたＲＴサービス２１６及び／又はＯＲＴサービス２１８が、送信フレームに収まらない場合は、ＭＵＸロジック２１０は、リサイズ制御部２１２に信号を送る。リサイズ制御部２１２は、これらのサービスが送信フレームの利用可能な帯域幅に収まるように、どのようにリサイズされるかを制御する働きをする。一実施形態の中では、リサイズ制御部２１２は、特定のサービスが、これの送信帯域幅要求を削減するためにどれだけの「リサイズ」を必要としているのかを判断し、その後、このサービスに関連するメディアサーバに送信されるリサイズ要求をまとめる働きをする。例えば、リサイズ要求は、トランシーバロジック２０６によって、通信チャネル２１４を使って送信される。メディアサーバは、その後、要求されたようにこのサービスをリサイズする働きをする。帯域幅要求を低減するためにサービスがリサイズされた後、ＭＵＸロジック２１０は、送信フレームの中に、元のサービス及び任意のリサイズされたサービスを効率良く詰め込むことができる。ＭＵＸロジック２１０により提供される割り当てアルゴリズムについてのより詳細な説明は、本明細書の他の章の中で提供されている。』(段落【００５１】))
　
“[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.”(『１つ以上の実施形態の中では、リサイズ制御部２１２は、ＣＰＵ、プロセッサ、ゲートアレイ、ハードウェアロジック、メモリ要素、バーチャルマシン、ソフトウェア、及び／又はハードウェアとソフトウェアとの任意の組み合わせを備えている。リサイズ制御部２１２は、ＲＴサービス２１６及びＯＲＴサービス２１８の１つ以上のフローをどのようにリサイズするかを制御する働きをし、これらのフローが送信フレームの利用可能な帯域幅の中に収まるようにする。従って、リサイズ制御部２１２は、１つ以上のサービスを、これに関連する配信要求を調整するためにリサイズする働きをする。例えば、サービスは、これの帯域幅要求が調整（すなわち削減）できるようにリサイズされてもよい。一実施形態の中では、リサイズ制御部２１２は、ＭＵＸロジック２１０の一部である。リサイズ制御部２１２のより詳細の説明は、本明細書の他の章の中で提供されている。』(段落【００５２】))
　
“[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.”(『一実施形態では、多重化システムは、コンピュータで読み取り可能な媒体上に格納された１つ以上のプログラム命令（「命令」）を有するコンピュータプログラムを備え、このコンピュータプログラムは、少なくとも１つのプロセッサ、例えば処理ロジック２０２により実行されると、本明細書の中で説明される多重化システムの機能を提供する。例えば、命令は、フロッピー（登録商標）ディスク、ＣＤＲＯＭ、メモリカード、フラッシュメモリデバイス、ＲＡＭ、ＲＯＭ、又はサーバ２００に接続する任意の他のタイプのメモリデバイス若しくはコンピュータで読み取り可能な媒体などの、コンピュータで読み取り可能な媒体から、サーバ２００の中にロードされてもよい。他の実施形態では、命令は、トランシーバロジック２０６を通して、外部のデバイスから又はサーバ２００に接続するネットワークリソースから、サーバ２００の中にダウンロードされてもよい。処理ロジック２０２により実行される時、命令は、本明細書において説明されるような多重化システムの１つ以上の実施形態を提供する。』(段落【００５３】))
　
“[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.”(『このように、サーバ２００は、多重化システムの実施形態を提供する働きをし、ネットワーク上のデバイスに送信するための送信フレームの中に、ＲＴサービス２１６及びＯＲＴサービス２１８に関連するフローを効率的に多重化する。』(段落【００５４】))
　
“
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.”(『＜送信フレームスロット割り当てアルゴリズム＞　以下の記述は、多重化システムの実施形態の中で用いるスロット割り当てアルゴリズムを説明している。一実施形態では、スロット割り当てアルゴリズムは、利用可能なＲＴ及びＯＲＴサービスに関連するコンテンツフローに、送信フレーム内のスロットを割り当てする働きをする。割り当てアルゴリズムは、効率的な帯域幅利用を実現する働きをし、これにより受信デバイスが電力を節約することを可能にする。１つ以上の実施形態では、割り当てアルゴリズムは、ＭＵＸロジック２１０により及び／又はこれの制御の下で実行される。』(段落【００５５】))
　
“[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.”(『この説明のために、送信フレームは、以下においてスーパーフレームと呼ばれよう。スーパーフレームはただ１つのインプリメンテーションであり、この多重化システムの各実施形態は、他のタイプの送信フレームのインプリメンテーションとともに用いるのに適しているということに留意されたい。』(段落【００５６】))
　
“[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.”(『一実施形態の中では、スーパーフレームは、帯域幅割り当てに利用されるデータシンボル部を備えている。スーパーフレームのデータシンボル部は、４つの同じ部分に分けられ、これらは以下において「フレーム」と呼ばれる。送信されるべきサービスからのデータ（一実施形態の中では、これはリードソロモン（ＲＳ）ブロックである）は、４つのフレーム全体に平等に分配される。従って、スーパーフレーム全体へのスロット割り当てアルゴリズムの動作は、１つのフレームに対するスロット割り当てアルゴリズムの動作の繰り返しである。従って、以下の記述は１つのフレームへのスロット割り当てを説明するが、しかしながら、これはスーパーフレーム全体に同様に適用可能である。加えて、論じられるスロット配置アルゴリズムは、リアルタイムサービス、非リアルタイムサービス、及びＩＰデータキャストを含む、しかしこれらに限定されない、全てのタイプのサービスに対してスロットを割り当てするために用いてもよい。』(段落【００５７】))
　
“
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.”(『（アルゴリズム概要）１つ以上の実施形態の中では、割り当てアルゴリズムは、フレームの中へのフローの効率的な詰め込みをもたらし、これにより、受信デバイスの「目を覚ます」頻度及び「オンタイム」を最小化する。例えば、サービスのチャネルを一緒にグループ化することは、目を覚ます頻度を低減し、一方maxSlotHeightでのサービスの送信は、オンタイムを削減する。』(段落【０１３１】))
　
“[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.”(『一実施形態の中では、アルゴリズムにより提供されるスロット割り当てが４つの不等条件の中の１つのために失敗した場合、アルゴリズムは指令を、どのようにサービスをリサイズするか制御するリサイズ制御部２１２に伝える。リサイズ制御部２１２が、これらの指令に基づいてリサイズされたサービスを有している場合は、詰め込みの解決策は保証される。』(段落【０１３２】))
　
“[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.”(『図１６は、ＲＴサービスを、使用されないスロットが２つの領域にグループ化されるような方法で詰め込む、割り当てアルゴリズムの実施形態の動作を説明する、フレーム１６００を示す。使われないスロットをより少ない領域に集めるということは、割り当てアルゴリズムに入力されるサービスよりも低いプライオリティのサービスによる、これらのスロットのよりよい利用を確実にする。一実施形態では、ＯＲＴサービスがこれらの領域に詰め込まれてもよい。例えば、フレーム１６００の中では、使用されないスロットは領域１６０２及び１６０４の中にグループ化される。』(段落【０１３３】))
　
“
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.”(『（リアルタイムサービス・リサイズアルゴリズム）１つ以上の実施形態では、リサイズ制御部１１６は、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをする。例えば、サービスは、これらの関連する配信要求を調整するためにリサイズされる。一実施形態では、１つ以上のサービスが関連する帯域幅要求を低減するためにリサイズされる。しかしながら、リサイズ制御部１１６は、任意の関連する配信要求を調整するために、サービスをリサイズする働きをする。以下の記述は、ＲＴサービスの中のコンポーネントストリームをリサイズする働きをする、リサイズアルゴリズムを説明している。ＲＴサービスのリサイズを生じさせる条件も、同様に提供される。一実施形態では、リサイズ制御部１１６は、リサイズパラメータを決定するリサイズアルゴリズムを実行する働きをする。これらのパラメータは、次にリサイズ要求の中のＲＴサービスに関連するＲＴＭＳへと送信される。ＲＴＭＳは次に、特定されたＲＴサービスを、上記のリサイズ要求の中のパラメータに従ってリサイズする働きをする。』(段落【０１３４】))
　
“[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.”(『リサイズ制御部１１６はまた、任意のＯＲＴサービスをリサイズする働きもするということに留意されたい。例えば、リサイズ制御部１１６は、１つ以上のＯＲＴサービスがどのようにリサイズされるべきかを判断し、この決定したリサイズを実行するために任意のＮＲＴＭＳと通信する働きをすることが可能である。結果として、これらのサービスに関連する配信要求が調整される。例えば、リサイズ制御部１１６は、あるＯＲＴサービスの帯域幅要求を低減するためにＮＲＴＭＳと通信しても良く、これによりこのＯＲＴサービスの配信要求を調整する。従って、ＲＴサービスのリサイズを参照して本明細書において説明された実施形態は、ＯＲＴサービスにも同じように適用可能である。』(段落【０１３５】))
　
“[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.”(『図１に示すように、ＭＵＸ１１４は、コンテンツのフローデータ、及びＲＴＭＳ１２６及びＮＲＴＭＳ１２８からの関連するシグナリングデータを受信する。スーパーフレームごとに、ＭＵＸ１１４は、全てのアクティブなリアルタイムサービスに対してＲＴＭＳ１２６と、且つ随意的にＯＲＴサービスに対してＮＲＴＭＳ１２８と、データ帯域幅を交渉する。一実施形態では、帯域幅交渉は、以下の動作シーケンスを含む。
　　ａ．ＭＵＸ１１４は、あるスーパーフレームの中で送信すべきＲＴサービスに対するデータのサイズを要求するために、GetDataSize.Requestメッセージを、ＲＴＭＳ１２６に送る。
　　ｂ．ＲＴＭＳ１２６は、スーパーフレームの中で送信すべき上記ＲＴサービスに対するデータのサイズを指定する、GetDataSize.Responseメッセージを、ＭＵＸ１１４に送る。
　　ｃ．ＭＵＸ１１４は、ＲＴＭＳ１２６及び他のソースから受信した全てのデータサイズに基づき、コンテンツのスケジューリング（割り当て）を実行する。
　　ｄ．ＭＵＸ１１４は、ＲＴＭＳ１２６に、ＲＴサービスのフローデータに対する更新されたサイズを、UpdateDataSize.Notificationメッセージの一部として、送信する。』(段落【０１３６】〜【０１４０】))
　
“[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.”(『一実施形態の中では、ＭＵＸ１１４は、上述のスロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供する働きをする。リサイズ制御部１１６は、リサイズアルゴリズムの実施形態を提供する。このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与する。特定のシステム制約（例えば、デバイス上のターボ復号器の最大スループットが、単一のＯＦＤＭシンボルの中で特定のメディアサービスに与えることができるスロット数を制限する）が、与えられたスロットの合計がスーパーフレーム内の利用可能なスロットの総数を下回るか又はこれと同じにもかかわらず、スロット割り当て手続きの失敗をもたらす可能性がある。また、無線リンクリソースに対する要求を支配すると予想されるリアルタイムのサービスコンポーネントは、ビデオコンテンツである。このコンテンツは、非常に変化しやすいビットレートのフローに帰着する、ソースコーディングを用いて圧縮される。最後に、リアルタイムサービスの送信のために利用可能なスーパーフレーム当たりの容量は、他の同時に起こるメディアサービスの要求のために変化する可能性がある。これらの要因は、以下の割り当て状態の生起につながる。
　　１．ＲＴサービスにより要求される全てのデータの合計が、利用可能な容量に満たないか又はこれに等しく、スロット割り当てアルゴリズムは成功する。
　　２．ＲＴサービスにより要求される全てのデータの合計が、利用可能な容量に満たないか又はこれに等しいが、スロット割り当てアルゴリズムは失敗する。
　　３．ＲＴサービスにより要求される全てのデータの合計が、利用可能な容量を超える。』(段落【０１４１】〜【０１４４】))
　
“[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.”(『割り当て状態２及び３は、ＲＴサービスフローにより要求されるデータの量の割り当ての失敗に帰着する。これらのシナリオでは、ＭＵＸ１１４はリサイズ制御部１１６を起動して、ＲＴサービスをリサイズするためにリサイズアルゴリズムを実行する。次の章は、リアルタイムサービスに対する品質の概念と、リサイズアルゴリズムの実施形態の目的を説明する。』(段落【０１４５】))
　
“
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)”(『（リアルタイムサービスの品質及びリサイズアルゴリズムの目的）品質の概念は、リアルタイムストリーミングメディアサービスの中のビデオフローに関連する。リアルタイムサービスの品質（Ｑ）は、サービスフローに割り当てられるビットレート（ｒ）の関数であり、またこれは以下で表される品質関数によりモデル化される。
　　　　Ｑ＝ｆ（ｒ）　　　　　　（３）
』(段落【０１４６】〜【０１４７】))
　
“[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.”(『スーパーフレーム毎に、ＲＴＭＳ１２６は、ＭＵＸ１１４がこの関数を評価することを支援する情報を提供する。これは、ＭＵＸ１１４へ、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.”(『リサイズアルゴリズムは、レートを（物理レイヤパケット（ＰＬＰ）を単位にして）、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がＲＴサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てる。従って、一実施形態の中では、ＲＴサービスへのレートの割り当ては、ＲＴサービスのビデオフローの品質関数が、以下に従って、これらの重量に比例するようにすべきである。
　　　　（Ｑｉ／Ｑｊ）＝（Ｗｉ／Ｗｊ）　　　（４）
ここで、Ｑｉ（Ｗｉ）及びＱｊ（Ｗｊ）は、任意のＲＴサービスｉ、ｊに対する品質関数（フロー重量）である。品質関数は、上記の方程式（３）を用いて見積もられる。フローに関連する重量の値は、他のＲＴビデオフローとの間でのこのフローの相対的な重要性の尺度を与える。一実施形態の中では、ＭＵＸ１１４はこれらのフローの重量値を、「契約プロビジョニングサブシステム」から取得し、このサブシステムは、流通ネットワークに関連するサービス計画・管理機能に同様に関与してもよい。』(段落【０１４８】〜【０１４９】))
　
“
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.”(『（リサイズアルゴリズム）この章では、ＲＴサービスのリサイズアルゴリズムについての実施形態を説明する。このアルゴリズムは、ＲＴサービスの中のビデオコンポーネントストリーム（フロー）に対するレート割り当てに集中する、反復アプローチを用いる。このアルゴリズムは、各ビデオストリームにより要求されるＰＬＰ数（レート）から始まる。アルゴリズムの反復のそれぞれには、レート削減のための候補サービスを特定することが含まれている。候補ストリームは、レート削減に最も鈍感であり、且つ他のストリームと比べて品質上好ましくない削減に苦しむことの無いストリームである。一実施形態では、リサイズアルゴリズムの機能は、図２に示すリサイズ制御部２１２により提供される。』(段落【０１５０】))
　
“[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.”(『候補ストリームが特定された後、このストリームに割り当てられるレートは削減される。例えば、レートは、２つのリードソロモンコードのブロックに相当する量だけ削減してもよい。ネットワークは、１つのリードソロモンブロックに相当するＰＬＰの数で規定される細かさで、全てのサービスにレートを割り当てする。ビデオストリームは、基本及び強化ビデオコンポーネントを伴って、ネットワークの階層化された送信モードの１つを用いて送信されるものと思われる。加えて、システムは、この２つのビデオコンポーネントの中のデータが同等であるべきとの制約をかける。従って、レート削減の単位として、２つのリードソロモンブロックの選択となる。しかしながら、任意の他の選択された量だけストリームのレートを削減することは、本実施形態の範囲内であるということに留意されたい。』(段落【０１５１】))
　
“
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　任意のリアルタイムビデオストリームに対するレートの部分削減についての上限。この上限は、ストリームにより要求されるレートに関連してのものである。一実施形態の中では、０．５の値が用いられる。sysMin　ストリームの品質に対する最小値。これは、レート削減上限に達したストリームが更にレート削減されるのを防ぐために用いられる。payloadPLP　１つのＰＬＰに対する有効なペイロードであり、これはおよそ９６８ビットである。』(段落【０１５２】〜【０１５６】))
　
“
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　リアルタイムサービスに対して利用可能なスーパーフレーム当たりの、ＯＦＤＭシンボル数における容量。numRTS　利用可能な容量を共有するリアルタイムサービスの数。numVStreams　リアルタイムサービスの中のビデオコンポーネントストリームの総数。例えば、VStreamは、それぞれのリアルタイムビデオコンポーネントストリームを記述する構造のリストである。_weight　ストリームに対する相対的な重量値を保持する。requestedPLPs　ストリームにより要求される、スーパーフレーム当たりのＰＬＰの数を保持する。requestedPLPs×payloadPLP（９６８ビット）として、要求された生のビット数を見積もることが可能である。rsCodeParameterK　リードソロモン（Ｎ、Ｋ）コードに対するパラメータＫ。』(段落【０１５６】〜【０１６２】 ))
　
“
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]　ビデオコンポーネントストリームを特定する数（０〜numVStreams−１）によりインデックスが付けられた配列。この配列は、VStream構造のrequestedPLPs部分により指示されるものとしての、このストリームにより要求されるスーパーフレーム当たりのＰＬＰ数を保持する。assgnPLPs[numVStreams]　ビデオコンポーネントストリームを特定する数（０〜numVStreams−１）によりインデックスが付けられた配列。この配列は、このストリームに割り当てられた、スーパーフレーム当たりのＰＬＰ数を保持する。tempPLPs[numVStreams]　ビデオコンポーネントストリームを特定する数（０〜numVStreams−１）によりインデックスが付けられた配列。この配列は、ビデオコンポーネントストリームに割り当てられた、スーパーフレーム当たりのＰＬＰ数を保持する。これは、アルゴリズムにより内部的に用いられる一時的変数である。weight[numVStreams]　ビデオコンポーネントストリームを特定する数（０〜numVStreams−１）によりインデックスが付けられた配列。この配列は、VStream構造の重量部分により表される、ストリームの相対的重量値を保持する。effQuality[numVStreams]　ビデオコンポーネントストリームを特定する数（０〜numVStreams−１）によりインデックスが付けられた配列。この配列は、リアルタイムサービスストリームに対する見積り品質を保持する。PLPsPerRSBlk[numVStreams]　ビデオコンポーネントストリームを特定する数（０〜numVStreams−１）によりインデックスが付けられた配列。この配列は、VStream構造のrsCodeParameterK部分により指示されるものとしての、リードソロモンコードブロック当たりのデータＰＬＰ数を保持する。』(段落【０１６３】〜【０１６９】))
　
“[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.”(『このようにして、リサイズ制御部２１２は、多重化システムの実施形態の中でサービスをリサイズするための上記の機能を提供する働きをする。例えば、上述の割り当てアルゴリズムの実施形態により提供されるように、ＲＴサービスのレートは削減されて、このサービスがスーパーフレームの利用可能なスロットに割り当てされることを可能とする。』(段落【０１８４】))
　
“
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.”(『（スロット割り当てアルゴリズム及びリサイズアルゴリズム間の相互作用）これまでの章の中で、スロット割り当てアルゴリズム及びリサイズアルゴリズムの実施形態が説明されている。以下の章は、多重化システムの実施形態の中で用いるこれらのアルゴリズムの全般的な相互作用についての記述を提供する。』(段落【０２０７】))
　
“[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.”(『図２０は、多重化システムの中で用いる、スロット割り当て、リサイズ、及び輻輳制御を提供するための方法２０００の一実施形態を示す。例えば、サーバ２００は、以下に説明する機能を提供する働きをする。』(段落【０２０８】))
　
“[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.”(『ブロック２００２では、高プライオリティ及び中プライオリティのＯＲＴサービスが、スロット割り当てされる。例えば、スーパーフレームごとに、ＭＵＸ１１４は、さまざまなフローデータの量及びこれらの相対的プライオリティを、ＲＴＭＳ１２６及びＮＲＴＭＳ１２８などのコンテンツエンティティからGetDataSize.Response命令を用いて入手する。この情報を用いて、高プライオリティ及び中プライオリティのＯＲＴサービスに対するスロット割り当てが実行される。例えば、一実施形態の中では、ＭＵＸロジック２１０は、上記のアルゴリズムに従って高プライオリティ及び中プライオリティのＯＲＴサービスに対するスロット割り当てを実行する働きをする。』(段落【０２０９】))
　
“[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.”(『ブロック２００４では、高プライオリティ及び中プライオリティのＯＲＴサービスのスロット割り当てが成功かどうかを判断するテストが実行される。割り当てが成功だった場合には、方法はブロック２００６に進む。割り当てが成功でなかった場合には、方法はブロック２０１８に進む。』(段落【０２１０】))
　
“[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.”(『ブロック２０１８では、輻輳制御が実行される。高プライオリティ及び中プライオリティのＯＲＴサービスのスロット割り当てが成功でなかったことから、システムは対処の必要な輻輳に悩むことになる。一実施形態では、ＭＵＸロジック２１０は、図２２を参照して説明される輻輳制御アルゴリズムを実行する。輻輳制御から戻り次第、方法はブロック２０２８で停止する。』(段落【０２１１】))
　
“[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.”(『ブロック２００６では、ＯＲＴサービススロット割り当ての成功に基づいて、ＲＴサービスに対して利用可能なシンボルの数が計算され、反復パラメータが０にセットされる。例えば、一実施形態では、ＭＵＸロジック２１０は、これらの機能を実行する。』(段落【０２１２】))
　
“[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.”(『ブロック２００８で、ＲＴサービスのスロット割り当てが、フレーム内の残りのシンボルを使って実行される。例えば、上述のスロット割り当てアルゴリズムの実施形態は、ＲＴサービスにスロットを割り当てるために用いられる。』(段落【０２１３】))
　
“[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.”(『ブロック２０１０では、ＲＴサービスが成功裏に割り当てされたかどうかを判断するテストが実行される。割り当てが成功でなかった場合には、方法はブロック２０１４に進む。割り当てが成功だった場合には、方法はブロック２０１２に進む。』(段落【０２１４】))
　
“[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.”(『ブロック２０１２で、利用可能なシンボルの数が減じられ、反復パラメータが増加される。例えば、一実施形態では、ＭＵＸロジック２１０は、これらの機能を実行する。方法は次に、ＲＴサービスにスロットを割り当てするためにブロック２００８に進む。』(段落【０２１５】))
　
“[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.”(『ブロック２０１４では、反復パラメータがゼロより大きいかどうかを判断するテストが実行される。例えば、一実施形態では、ＭＵＸロジック２１０は、これらの機能を実行する。反復パラメータがゼロよりも大きい場合は、方法はブロック２０１６に進む。反復パラメータがゼロよりも大きくない場合は、方法はブロック２０２０に進む。』(段落【０２１６】))
　
“[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.”(『ブロック２０１６で、ＲＴサービススロット割り当てが、numRTSymbols＋１を用いて実行される。例えば、ＭＵＸロジック２１０は、増加されたnumRTSymbols値を用いて、ＲＴサービスに対してスロット割り当てを実行する。方法は次に、ブロック２０２４に進む。』(段落【０２１７】))
　
“[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.”(『ブロック２０２０で、選択されたＲＴサービスがリサイズされる。一実施形態の中では、ＲＴサービスのスロット割り当てが成功するように、１つ以上のフローのレートをリサイズするために、リサイズアルゴリズムが用いられる。例えば、リサイズ制御部２１２は、図２２を参照して説明されるリサイズアルゴリズムを実行する働きをする。リサイズアルゴリズムから戻り次第、方法はブロック２０２２に進む。』(段落【０２１８】))
　
“[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.”(『ブロック２０２２では、ＲＴサービスのリサイズが成功だったかどうかを判断するテストが実行される。例えば、リサイズアルゴリズムが、許容できる下限ビデオ品質又は下限リサイズ率を伴うスロット割り当てに失敗する事態がありうる。リサイズが成功だった場合には、方法はブロック２０２４に進む。リサイズが成功でなかった場合には、この状態は、システムが輻輳していることを意味し、従って、方法は輻輳制御を実行するためにブロック２０１８に進む。』(段落【０２１９】))
　
“[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.”(『ブロック２０２４で、低プライオリティのＯＲＴサービスが、ランクが増えていく順にスロット割り当てされる。例えば、ＭＵＸロジック２１０が、この機能を行う。』(段落【０２２０】))
　
“[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.”(『ブロック２０２６では、ベストエフォートＯＲＴサービス又はデータがスロット割り当てされる。例えば、ＭＵＸロジック２１０が、この機能を行う。方法２０００は次に、ブロック２０２８で停止する。』(段落【０２２１】))
　
“[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.”(『従って、方法２０００の完了時、ＭＵＸ１１４はスーパーフレームで送ることができるさまざまなフローの、正確なデータサイズについての情報を有する。この情報は、ＲＴＭＳ１２６及びＯＲＴＭＳ１２８に、UpdateDataSize.Notificationメッセージを用いて送り戻される。』(段落【０２２２】))
　
“[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.”(『方法２０００は、ただ１つのインプリメンテーションのみを表し、方法２０００の変更、追加、削除、複合又は他の修正は、各実施形態の範囲の中で可能であるということに留意されたい。』(段落【０２２３】))
　
“[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.”(『図２１は、多重化システムの中で用いる、リサイズを提供するための方法２１００の一実施形態を示す。例えば、方法２１００は、図２０００の中のブロック２０２０として用いるのに適している。一実施形態の中では、リサイズ制御部２１２は、以下に説明する機能を提供する働きをする。』(段落【０２２４】))
　
“[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.”(『ブロック２１０２では、要求されたスロットの数が評価され、パラメータｎが計算される。一実施形態では、ｎは、あるサービスのために要求されたスロットの数と、利用可能なスロットの数との比率を表す。例えば、リサイズ制御部２１２は、この計算を行う。』(段落【０２２５】))
　
“[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.”(『ブロック２１０４で、リサイズされるべきフローの品質が評価される。例えば、各フローに対するＭＬＣをｎコードブロックだけ削減した後に、品質評価がなされる。例えば、あるサービスの品質（Ｑ）は、サービスフローに割り当てられたビットレート（ｒ）の関数であり、またこれは上記で表される品質関数によりモデル化される。例えば、リサイズ制御部２１２は、この品質判定を行う。』(段落【０２２６】))
　
“[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.”(『ブロック２１０６では、結果としての最大品質を伴うフローが決定される（候補）。例えば、リサイズ制御部２１２は、ブロック２１０４において、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定する。』(段落【０２２７】))
　
“[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.”(『ブロック２１０８で、最大品質がシステムの最小品質要求よりも大きいかどうかを判断するためのテストが実行される。例えば、リサイズ制御部２１２は、このテストの結果を判断する。最大品質が、システムの最小品質要求よりも大きくない場合は、方法はブロック２１１６に進む。最大品質が、システムの最小品質要求よりも大きい場合は、方法はブロック２１１０に進む。』(段落【０２２８】))
　
“[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.”(『ブロック２１１０では、最大品質を有するフローがリサイズされ、スロット割り当てが実行される。例えば、最大品質を有するフローがｎコードブロックだけ削減され、スロット割り当てが実行される。例えば、リサイズ制御部２１２はフローをリサイズし、ＭＵＸロジック２１０にスロット割り当てを実行するよう要求する。』(段落【０２２９】))
　
“[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.”(『ブロック２１１２では、スロット割り当てが成功だったかどうかを判断するテストが実行される。例えば、リサイズ制御部２１２は、ブロック２１１０で実行されたスロット割り当てが成功だったかどうかを示す指標を、ＭＵＸロジック２１０から受信する。スロット割り当てが成功だった場合には、方法はブロック２１１４に進む。スロット割り当てが成功でなかった場合には、方法はブロック２１０２に進む。』(段落【０２３０】))
　
“[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.”(『ブロック２１１４において、リサイズは成功と判断され、ブロック２１１６において、リサイズは失敗と判断される。例えば、リサイズ制御部２１２は、これらの判断を行う。方法は次に、ブロック２１１８に進み、ここで方法は図２０００のブロック２０２０に戻る。』(段落【０２３１】))
　
“[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.”(『このようにして、方法２１００は、多重化システムの中で用いるリサイズを提供する働きをする。方法２１００は、ただ１つのインプリメンテーションのみを表し、方法２１００の変更、追加、削除、複合又は他の修正は、各実施形態の範囲の中で可能であるということに留意されたい。』(段落【０２３２】))
　
“
”
“
”
“
”
“
”
　
３．２．引用例記載の発明
　ここで、上記記載を検討する。
　
　第一に、上記段落[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.”(「１つ以上の実施形態の中では、方法と装置を備え、データネットワークを通しての送信のために１つ以上のコンテンツフローを効率的に多重化する働きをする、多重化システムが提供される。」(段落【０００８】))との記載、上記段落[0044][0047][0051][0052](段落【００２１】【００３０】【００３４】【００３５】)の記載、及び、Fig.1, Fig.2 の記載からみて、引用例記載の発明は「データネットワークを通しての送信のために１つ以上のコンテンツフローを効率的に多重化する働きをする多重化方法」である。
　第二に、上記段落[0067]〜[0069](段落【００５５】〜【００５７】)の記載からみて、引用例記載の発明の「スロット割り当てアルゴリズムは、コンテンツフローに、スーパーフレーム内のスロットを割り当てするもの」であって、「割り当てアルゴリズムは、効率的な帯域幅利用を実現する働きを」するものである。
　第三に、上記段落[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.”(『（リアルタイムサービス・リサイズアルゴリズム）１つ以上の実施形態では、リサイズ制御部１１６は、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをする。例えば、サービスは、これらの関連する配信要求を調整するためにリサイズされる。一実施形態では、１つ以上のサービスが関連する帯域幅要求を低減するためにリサイズされる。しかしながら、リサイズ制御部１１６は、任意の関連する配信要求を調整するために、サービスをリサイズする働きをする。以下の記述は、ＲＴサービスの中のコンポーネントストリームをリサイズする働きをする、リサイズアルゴリズムを説明している。ＲＴサービスのリサイズを生じさせる条件も、同様に提供される。一実施形態では、リサイズ制御部１１６は、リサイズパラメータを決定するリサイズアルゴリズムを実行する働きをする。これらのパラメータは、次にリサイズ要求の中のＲＴサービスに関連するＲＴＭＳへと送信される。ＲＴＭＳは次に、特定されたＲＴサービスを、上記のリサイズ要求の中のパラメータに従ってリサイズする働きをする。』(段落【０１３４】))、段落[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.”(『図１に示すように、ＭＵＸ１１４は、コンテンツのフローデータ、及びＲＴＭＳ１２６及びＮＲＴＭＳ１２８からの関連するシグナリングデータを受信する。スーパーフレームごとに、ＭＵＸ１１４は、全てのアクティブなリアルタイムサービスに対してＲＴＭＳ１２６と、且つ随意的にＯＲＴサービスに対してＮＲＴＭＳ１２８と、データ帯域幅を交渉する。』(段落【０１３６】))、段落[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.”(『一実施形態の中では、ＭＵＸ１１４は、上述のスロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供する働きをする。リサイズ制御部１１６は、リサイズアルゴリズムの実施形態を提供する。このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与する。特定のシステム制約（例えば、デバイス上のターボ復号器の最大スループットが、単一のＯＦＤＭシンボルの中で特定のメディアサービスに与えることができるスロット数を制限する）が、与えられたスロットの合計がスーパーフレーム内の利用可能なスロットの総数を下回るか又はこれと同じにもかかわらず、スロット割り当て手続きの失敗をもたらす可能性がある。また、無線リンクリソースに対する要求を支配すると予想されるリアルタイムのサービスコンポーネントは、ビデオコンテンツである。このコンテンツは、非常に変化しやすいビットレートのフローに帰着する、ソースコーディングを用いて圧縮される。最後に、リアルタイムサービスの送信のために利用可能なスーパーフレーム当たりの容量は、他の同時に起こるメディアサービスの要求のために変化する可能性がある。これらの要因は、以下の割り当て状態の生起につながる。　１．ＲＴサービスにより要求される全てのデータの合計が、利用可能な容量に満たないか又はこれに等しく、スロット割り当てアルゴリズムは成功する。　２．ＲＴサービスにより要求される全てのデータの合計が、利用可能な容量に満たないか又はこれに等しいが、スロット割り当てアルゴリズムは失敗する。　３．ＲＴサービスにより要求される全てのデータの合計が、利用可能な容量を超える。』(段落【０１４１】〜【０１４４】))、段落[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.”(「割り当て状態２及び３は、ＲＴサービスフローにより要求されるデータの量の割り当ての失敗に帰着する。これらのシナリオでは、ＭＵＸ１１４はリサイズ制御部１１６を起動して、ＲＴサービスをリサイズするためにリサイズアルゴリズムを実行する。次の章は、リアルタイムサービスに対する品質の概念と、リサイズアルゴリズムの実施形態の目的を説明する。」(段落【０１４５】))との記載、及び、Fig.1, Fig.2 の記載からみて、引用例記載の発明は「ＭＵ��」、及び、その一部をなす「リサイズ制御部」を有し、「ＭＵＸ」は「スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供」するものであって、この「スロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与する」ものであり、「リサイズ制御部」は「リサイズアルゴリズムの実施形態を提供する」ものであって「サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをする」ものである。
　第四に、上記段落[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)”(「品質の概念は、リアルタイムストリーミングメディアサービスの中のビデオフローに関連する。リアルタイムサービスの品質（Ｑ）は、サービスフローに割り当てられるビットレート（ｒ）の関数であり、またこれは以下で表される品質関数によりモデル化される。　Ｑ＝ｆ（ｒ）　（３）」(段落【０１４６】【０１４７】))との記載、上記段落[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.”(『スーパーフレーム毎に、ＲＴＭＳ１２６は、ＭＵＸ１１４がこの関数を評価することを支援する情報を提供する。これは、ＭＵＸ１１４へ、GetDataSize.Responseメッセージの中で送信される。以下の章で説明されるように、ＭＵＸ１１４は、リサイズ手順を手助けして、この情報をリアルタイムサービスの品質見積もりのために用いる。任意の選択された品質測定又は特性は、品質見積もり目的のためにＭＵＸ１１４により用いられるということも同様に注目すべきである。』(段落【０１４７】))、上記段落[00133][00178][00179](段落【０１４８】【０１４９】【０２２４】【０２２５】)の記載、上記段落[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.”(『ブロック２１０４で、リサイズされるべきフローの品質が評価される。例えば、各フローに対するＭＬＣをｎコードブロックだけ削減した後に、品質評価がなされる。例えば、あるサービスの品質（Ｑ）は、サービスフローに割り当てられたビットレート（ｒ）の関数であり、またこれは上記で表される品質関数によりモデル化される。例えば、リサイズ制御部２１２は、この品質判定を行う。』(段落【０２２６】))の記載、上記段落[00181][00182](段落【０２２７】【０２２８】)の記載からみて、引用例記載の発明は「リサイズ制御部は、リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート（ｒ）の関数である品質関数 Q = f(r) を利用」するものであって、この「品質」は「スーパーフレーム毎に、ＭＵＸへ、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.”(『リサイズアルゴリズムは、レートを（物理レイヤパケット（ＰＬＰ）を単位にして）、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がＲＴサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てる。従って、一実施形態の中では、ＲＴサービスへのレートの割り当ては、ＲＴサービスのビデオフローの品質関数が、以下に従って、これらの重量に比例するようにすべきである。 （Ｑｉ／Ｑｊ）＝（Ｗｉ／Ｗｊ）（４）　ここで、Ｑｉ（Ｗｉ）及びＱｊ（Ｗｊ）は、任意のＲＴサービスｉ、ｊに対する品質関数（フロー重量）である。品質関数は、上記の方程式（３）を用いて見積もられる。フローに関連する重量の値は、他のＲＴビデオフローとの間でのこのフローの相対的な重要性の尺度を与える。一実施形態の中では、ＭＵＸ１１４はこれらのフローの重量値を、「契約プロビジョニングサブシステム」から取得し、このサブシステムは、流通ネットワークに関連するサービス計画・管理機能に同様に関与してもよい。』(段落【０１４８】〜【０１４９】))、段落[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.”(『ブロック２１０６では、結果としての最大品質を伴うフローが決定される（候補）。例えば、リサイズ制御部２１２は、ブロック２１０４において、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定する。』(段落【０２２７】))、段落[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.”(『ブロック２１０８で、最大品質がシステムの最小品質要求よりも大きいかどうかを判断するためのテストが実行される。例えば、リサイズ制御部２１２は、このテストの結果を判断する。最大品質が、システムの最小品質要求よりも大きくない場合は、方法はブロック２１１６に進む。最大品質が、システムの最小品質要求よりも大きい場合は、方法はブロック２１１０に進む。』(段落【０２２８】))、段落[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.”(『ブロック２１１０では、最大品質を有するフローがリサイズされ、スロット割り当てが実行される。例えば、���大品質を有するフローがｎコードブロックだけ削減され、スロット割り当てが実行される。例えば、リサイズ制御部２１２はフローをリサイズし、ＭＵＸロジック２１０にスロット割り当てを実行するよう要求する。』(段落【０２２９】))」、段落[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.”(『ブロック２１１２では、スロット割り当てが成功だったかどうかを判断するテストが実行される。例えば、リサイズ制御部２１２は、ブロック２１１０で実行されたスロット割り当てが成功だったかどうかを示す指標を、ＭＵＸロジック２１０から受信する。スロット割り当てが成功だった場合には、方法はブロック２１１４に進む。スロット割り当てが成功でなかった場合には、方法はブロック２１０２に進む。』(段落【０２３０】))、段落[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.”(『ブロック２１１４において、リサイズは成功と判断され、ブロック２１１６において、リサイズは失敗と判断される。例えば、リサイズ制御部２１２は、これらの判断を行う。方法は次に、ブロック２１１８に進み、ここで方法は図２０００のブロック２０２０に戻る。』(段落【０２３１】))との記載からみて、引用例記載の発明の「リサイズアルゴリズムは、レートを（物理レイヤパケット（ＰＬＰ）を単位にして）、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がＲＴサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てる」ものであって「リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ、スロット割り当てが実行され、スロット割り当てが成功だった場合には、リサイズは成功と判断され」るものである。
　
　したがって、引用例には以下の発明(以下「引用発明」という。)が記載されている。
　
「データネットワークを通しての送信のために１つ以上のコンテンツフローを効率的に多重化する働きをする多重化方法であって、
　スロット割り当てアルゴリズムは、コンテンツフローに、スーパーフレーム内のスロットを割り当てするものであって、割り当てアルゴリズムは、効率的な帯域幅利用を実現する働きをするものであり、
　ＭＵＸ、及び、その一部をなすリサイズ制御部を有し、
　ＭＵＸは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与するものであり、
　リサイズ制御部は、リサイズアルゴリズムの実施形態を提供するものであって、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをするものであり、
　リサイズ制御部は、リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート（ｒ）の関数である品質関数 Q = f(r) を利用するものであり、
　この品質は、スーパーフレーム毎に、ＭＵＸへ、GetDataSize.Responseメッセージの中で送信されるものであり、
　リサイズアルゴリズムは、レートを（物理レイヤパケット（ＰＬＰ）を単位にして）、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がＲＴサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てるものであって、リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ、スロット割り当てが実行され、スロット割り当てが成功だった場合には、リサイズは成功と判断される、
　データネットワークを通しての送信のために１つ以上のコンテンツフローを効率的に多重化する働きをする多重化方法。」
　
４．対比
　ここで、本願発明と引用発明を対比する。
　
４．１．「デジタルマルチメディアデータの流れを結合するための方法」
　引用発明は「データネットワークを通しての送信のために１つ以上のコンテンツフローを効率的に多重化する働きをする多重化方法」であって、引用発明の「多重化」とは「１つ以上のコンテンツフロー」を結合する方法であるということができ、また、引用発明の「コンテンツフロー」と本願発明の「デジタルマルチメディアデータの流れ」が一致しているといえるから、引用発明は本願発明と同様に「デジタルマルチメディアデータの流れを結合するための方法」であるといえる。
　
４．２．「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」
４．２．１．「データセグメント」「複数のデータセグメント」「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」の解釈
　本願発明の「データセグメント」「複数のデータセグメント」「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」が、どのような技術概念を指すのか、明細書の記載を参酌して以下検討する。
　
４．２．１．１．「データセグメント」とは
　本願明細書には「データセグメント」について多数の記載があるが、「データセグメント」が何であるか言及されている記載として、
　
「【０２３０】
　マルチメディア符号化デバイス２４００は、マルチメディアデータの１つ以上の流れを含む複数のサービスを符号化し、符号化された流れを結合し、結合された流れを送信チャネル２４０２を介してマルチメディア復号デバイスに送信する。この開示の一側面においては、マルチメディア符号化デバイス２４００は、ある期間にわたって受信されたデータの流れの一部分を符号化、結合及び送信する。一例として、マルチメディア符号化デバイス２４００は、１秒ごとに流れに対して動作することができる。換言すると、マルチメディア符号化デバイス２４００は、複数の流れのうちの１秒のデータセグメントを符号化し、１秒のデータセグメントを結合してデータのスーパーフレームを形成し、送信機２４０８を介して送信チャネル２４０２を通じてそのスーパーフレームを送信する。ここにおいて用いられる用語“スーパーフレーム”は、ある期間又はウィンドー、例えば１秒の期間又はウィンドー、にわたって収集されたデータセグメントのグループを指す。データセグメントは、１つ以上のデータフレームを含むことができる。この開示の技法は、１秒のデータセグメントに関して説明されるが、これらの技法は、その他のデータセグメントを結合及び送信するために、例えば固定された期間である場合とない場合がある異なる期間にわたって受信されたデータセグメントに関して、又は個々のデータフレーム又はデータフレームの組に関しても利用することができる。換言すると、スーパーフレームは、１秒の期間よりも長い又は短い時間間隔、又は時間が可変の間隔、を網羅するように定義することが可能である。」
「【０２３３】
　符号器モジュール２４０４は、受信されたデータ流を少なくとも品質及びレート情報と関連づけることができる。より詳細に説明されるように、符号化モジュール２４０４は、流れのコンテンツを解析し、流れを、各々の品質及びレート情報、例えば品質−レート曲線、コンテンツ分類曲線又は品質−レートテーブルと関連づけることができる。品質及びレート情報は、特に、符号器モジュール２４０４が現在のスーパーフレーム内に含めることを希望するデータセグメントに関して異なる品質レベルでデータセグメントのサイズを示すことができる。符号器モジュール２４０４は、データセグメントと関連づけられた少なくとも品質及びレート情報をマルチプレクスモジュール２４０６に送る。符号器モジュール２４０４は、制御チャネルを介して品質及びレート情報をマルチプレクスモジュール２４０６に送ることができる。例えば、符号器モジュール２４０４は、マルチプレクスモジュール２４０６から受け取られた要求に応答して制御チャネルを介して品質及びレート情報を送ることができる。マルチプレクスモジュール２４０６及び符号器モジュール２４０４は、幾つかの異なる通信プロトコルを用いて通信することができる。一側面においては、マルチプレクスモジュール２４０６は、メッセージトランスポート層（ＭＴＬ）を基本的なトランスポート機構として利用するプロトコルを用いて通信することができる。」
　
　との記載がある。そして、段落【０２３０】の「マルチメディア符号化デバイス２４００は、マルチメディアデータの１つ以上の流れを含む複数のサービスを符号化し、符号化された流れを結合し、結合された流れを送信チャネル２４０２を介してマルチメディア復号デバイスに送信する。」「換言すると、マルチメディア符号化デバイス２４００は、複数の流れのうちの１秒のデータセグメントを符号化し、１秒のデータセグメントを結合してデータのスーパーフレームを形成し、送信機２４０８を介して送信チャネル２４０２を通じてそのスーパーフレームを送信する。ここにおいて用いられる用語“スーパーフレーム”は、ある期間又はウィンドー、例えば１秒の期間又はウィンドー、にわたって収集されたデータセグメントのグループを指す。データセグメントは、１つ以上のデータフレームを含むことができる。」との記載からみて、本願発明の「データセグメント」とは、デジタルマルチメディアデータの流れを符号化したものであって、「データセグメント」の長さは「１秒」のような固定した時間の長さで決められるものであり、「データセグメント」が複数「結合」されて「スーパーフレームを形成」するものであるということができる。
　
４．２．１．２．「複数のデータセグメント」とは
　本願明細書及び図面には「複数のデータセグメント」について以下の記載がある。
　
「【０２３６】
　複数のデータセグメントが利用可能な帯域幅内にぴったり納まらないことをマルチプレクスモジュール２４０６が決定した場合、例えば、スロット割り当てアルゴリズムが失敗であるか又は必要な送信チャネル資源の合計が利用可能な送信チャネル資源を超える場合は、マルチプレクスモジュール２４０６は、符号器モジュール２４０４から受け取られた品質及びレート情報に基づいてサイズが変更されるべき１つ以上のセグメントを選択する。マルチプレクスモジュール２４０６は、対応する縮小されたサイズにおける品質上の影響が最も小さいサイズが変更されるべきデータセグメントを選択することを試みる。以下においてより詳細に説明されるように、マルチプレクスモジュール２４０６は、品質−レート情報を解析してセグメントに対して割り当てられたビット数の減少後における各々のデータセグメントへの品質上の影響を決定し、縮小されたサイズにおいて最高のレベルを有するデータセグメントのうちの１つ以上を選択する。この方法により、マルチプレクスモジュールは、符号器モジュール２４０４のリアルタイムサービス間で裁定することができる。しかしながら、幾つかの場合においては、マルチプレクスモジュール２４０６は、関連づけられた配送要求事項に基づいてサイズが変更されるべき１つ以上のＯＲＴサービスを選択し、符号器モジュール２４０４のリアルタイムサービス及びＯＲＴサービス間で帯域幅を割り当てることができる。繰り返すと、ここにおける技法は、典型例を目的としてリアルタイムサービスに関して説明される。マルチプレクスモジュール２４０６は、依然として、上述される技法に従ってＯＲＴサービスを解析及びサイズ変更することができる。以上のように、以下の図において説明される技法は、リアルタイムサービスのサイズ変更により適用可能である。」
「【０２６１】
　図２７は、この開示の技法によりビット割り当てを管理する典型的マルチプレクスモジュール２７００を例示するブロック図である。特に、マルチプレクスモジュール２７００は、各々の符号器モジュール、例えば符号器モジュール２４０４（図２４）、から複数のデータセグメントを受け取り、データセグメントを送るために必要なエアリンク資源が利用可能なエアリンク資源を超えないような形でデータセグメントのうちの１つ以上のサイズを変更するように要求する。マルチプレクスモジュール２７００は、例えば、図２４のマルチプレクスモジュール２４０６又は図２５のマルチプレクスモジュール２５０６を表すことができる。マルチプレクスモジュール２７００は、符号器モジュールインタフェース２７０２と、データ収集モジュール２０８６と、ビット管理モジュール２７０４と、を含む。ビット管理モジュール２７０４は、利用可能な帯域幅を割り当てる割り当てモジュール２７０８と、帯域幅割り当てが不成功であるときにデータセグメントのうちのいずれをサイズ変更すべきかを決定する選択モジュール２７１０と、を含む。」
「【０２６４】
　ビット管理モジュール２７０４は、少なくとも品質及びレート情報を解析して複数のデータセグメントが送信チャネル２４０２の利用可能な帯域幅内にぴったり納まるかどうかを決定することができる。ビット管理モジュール２７０４は、品質及びレート情報に加えてその他の配送要求事項を解析することができる。例えば、ビット管理モジュール２７０４は、ＯＲＴサービスと関連づけられた優先度及びレーテンシー要求事項を解析することができる。ビット管理モジュール２７０４は、データセグメント間で利用可能な帯域幅を割り当てることを試みる割り当てモジュール２７０８を含むことができる。割り当てモジュール２７０８は、例えば、上述される割り当てアルゴリズムのうちの１つを用いて利用可能な帯域幅を割り当てることを試みることができる。利用可能な帯域幅を割り当てる第１の試みにおいては、割り当てモジュール２７０８は、データセグメントと関連づけられた目標品質レベルと各々の品質−レート曲線との間の交点に対応するサイズを用いて帯域幅を割り当てることを試みることができる。他の例として、マルチプレクスモジュール２４０６は、データセグメントと関連づけられた品質−レートテーブルにおいて指定される最高の品質レベルに対応するサイズを用いてデータセグメントが現在のスーパーフレーム内にぴったり納まるかどうかに関する最初の決定を行うことができる。割り当てモジュール２７０８がデータセグメント間において帯域幅を割り当てることに成功した場合、例えば、データセグメントを送る上での十分な送信チャネル資源が存在し及び余分の送信チャネル資源が存在しない場合は、サイズ変更は必要ない。」
「【図２４】
」
「【図２７】
」
　
　
　ここで、上記段落【０２３６】の「複数のデータセグメントが利用可能な帯域幅内にぴったり納まらないことをマルチプレクスモジュール２４０６が決定した場合」、上記段落【０２６４】の「ビット管理モジュール２７０４は、少なくとも品質及びレート情報を解析して複数のデータセグメントが送信チャネル２４０２の利用可能な帯域幅内にぴったり納まるかどうかを決定することができる。」との記載における、これら「複数のデータセグメント」は「送信チャネル２４０２の利用可能な帯域幅内にぴったり納まるかどうかを決定する」対象となるものであるから、本願発明でいう「デジタルマルチメディアデータの流れを結合」した後のものであって、同時に伝送されるものである必要がある。また、上記段落【０２６１】の「特に、マルチプレクスモジュール２７００は、各々の符号器モジュール、例えば符号器モジュール２４０４（図２４）、から複数のデータセグメントを受け取り、データセグメントを送るために必要なエアリンク資源が利用可能なエアリンク資源を超えないような形でデータセグメントのうちの１つ以上のサイズを変更するように要求する」との記載は、上記【図２４】に記載されるように「符号器モジュール２４０４」自体が複数存在しているところからみて、この「複数のデータセグメント」とは、この「マルチプレクスモジュール２７００」でマルチプレクスする、すなわち、本願発明でいう「デジタルマルチメディアデータの流れを結合」する対象となる「複数のデータセグメント」であるということができる。
　すなわち、これら段落【０２３６】【０２６１】【０２６４】の記載からは、本願発明の「複数のデータセグメント」とは、それが「デジタルマルチメディアデータの流れを結合」する前であれば、その「結合」の対象となるものであり、既に「デジタルマルチメディアデータの流れを結合」した後であれば「結合」した結果であって、同時に伝送される複数の「データセグメント」のことを指し「送信チャネル２４０２の利用可能な帯域幅内にぴったり納まるかどうかを決定する」対象となるものということができる。
　
４．２．１．３．「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」とは
　本願明細書には「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」について以下の記載がある。
　
「【０２３３】
　符号器モジュール２４０４は、受信されたデータ流を少なくとも品質及びレート情報と関連づけることができる。より詳細に説明されるように、符号化モジュール２４０４は、流れのコンテンツを解析し、流れを、各々の品質及びレート情報、例えば品質−レート曲線、コンテンツ分類曲線又は品質−レートテーブルと関連づけることができる。品質及びレート情報は、特に、符号器モジュール２４０４が現在のスーパーフレーム内に含めることを希望するデータセグメントに関して異なる品質レベルでデータセグメントのサイズを示すことができる。符号器モジュール２４０４は、データセグメントと関連づけられた少なくとも品質及びレート情報をマルチプレクスモジュール２４０６に送る。符号器モジュール２４０４は、制御チャネルを介して品質及びレート情報をマルチプレクスモジュール２４０６に送ることができる。例えば、符号器モジュール２４０４は、マルチプレクスモジュール２４０６から受け取られた要求に応答して制御チャネルを介して品質及びレート情報を送ることができる。マルチプレクスモジュール２４０６及び符号器モジュール２４０４は、幾つかの異なる通信プロトコルを用いて通信することができる。一側面においては、マルチプレクスモジュール２４０６は、メッセージトランスポート層（ＭＴＬ）を基本的なトランスポート機構として利用するプロトコルを用いて通信することができる。」
「【０２３４】
　マルチプレクスモジュール２４０６は、品質及びレート情報を受け取る。幾つかの場合においては、マルチプレクスモジュール２４０６は、配送要求事項、例えば１つ以上のＯＲＴサービスと関連づけられた優先度及びレーテンシーの要求事項を受け取ることもできる。マルチプレクスモジュール２４０６は、１つ以上の配送要求事項を解析し、符号器モジュール２４０４が現在のスーパーフレーム内に含めることを希望するデータセグメントが送信チャネル２４０２の利用可能な帯域幅内にぴったり納まるかどうかを決定する。マルチプレクスモジュール２４０６は、例えば、マルチメディア符号化デバイス２４００の目標品質レベルとデータセグメントと関連づけられた各々の品質−レート曲線との間の交点に対応するサイズを用いてデータセグメントが現在のスーパーフレーム内にぴったり納まるかどうかについての最初の決定を行う。他の例として、マルチプレクスモジュール２４０６は、データセグメントと関連づけられた品質−レートテーブルにおいて指定される最高の品質レベルに対応するサイズを用いてデータセグメントが現在のスーパーフレーム内にぴったり納まるかどうかについての最初の決定を行うことができる。」
「【０２３５】
　データセグメントが送信チャネル２４０２の利用可能な帯域幅内にぴったり納まるかどうかを決定するために、マルチプレクスモジュール２４０６は、品質レベルのうちの選択された１つに対応するサイズでデータセグメントの各々を送るために必要な送信資源量を決定し、データセグメントを送るために必要な送信チャネル資源量を合計し、及び全データセグメントによって要求される送信チャネル資源の合計量を利用可能な送信チャネル資源量と比較してデータセグメントを送る上での十分な送信チャネル資源が存在するかどうかを決定することができる。無線に関しては、送信チャネル資源は、エアリンク又はエアインタフェース資源を備えることができる。一側面例においては、マルチプレクスモジュール２４０６は、十分な送信チャネル資源が存在するかどうかを決定するためのスロット割り当てアルゴリズム、例えば上述されるスロット割り当てアルゴリズムのうちの１つ、を実行することができる。上記においてより詳細に説明されるように、マルチプレクスモジュール２４０６は、全サービス／セグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定するために符号器モジュール２４０４のデータセグメントと関連づけられた品質及びレート情報と連携してＯＲＴサービス配送要求事項を考慮に入れることもできる。」
「【０２３６】
　複数のデータセグメントが利用可能な帯域幅内にぴったり納まらないことをマルチプレクスモジュール２４０６が決定した場合、例えば、スロット割り当てアルゴリズムが失敗であるか又は必要な送信チャネル資源の合計が利用可能な送信チャネル資源を超える場合は、マルチプレクスモジュール２４０６は、符号器モジュール２４０４から受け取られた品質及びレート情報に基づいてサイズが変更されるべき１つ以上のセグメントを選択する。マルチプレクスモジュール２４０６は、対応する縮小されたサイズにおける品質上の影響が最も小さいサイズが変更されるべきデータセグメントを選択することを試みる。以下においてより詳細に説明されるように、マルチプレクスモジュール２４０６は、品質−レート情報を解析してセグメントに対して割り当てられたビット数の減少後における各々のデータセグメントへの品質上の影響を決定し、縮小されたサイズにおいて最高のレベルを有するデータセグメントのうちの１つ以上を選択する。この方法により、マルチプレクスモジュールは、符号器モジュール２４０４のリアルタイムサービス間で裁定することができる。しかしながら、幾つかの場合においては、マルチプレクスモジュール２４０６は、関連づけられた配送要求事項に基づいてサイズが変更されるべき１つ以上のＯＲＴサービスを選択し、符号器モジュール２４０４のリアルタイムサービス及びＯＲＴサービス間で帯域幅を割り当てることができる。繰り返すと、ここにおける技法は、典型例を目的としてリアルタイムサービスに関して説明される。マルチプレクスモジュール２４０６は、依然として、上述される技法に従ってＯＲＴサービスを解析及びサイズ変更することができる。以上のように、以下の図において説明される技法は、リアルタイムサービスのサイズ変更により適用可能である。」
「【０２４４】
　従って、図２４の符号器モジュール２４０４の機能は、符号器モジュール２５０４とサイズ変更モジュール２５０２との間で分割される。換言すると、符号器モジュール２５０４は、利用可能な帯域幅をデータセグメントに割り当て、その割り当てが失敗したときにサイズが変更されるべきデータセグメントのうちの１つ以上を選択する際に用いるために各々のデータセグメントと関連づけられた品質及びレート情報をマルチプレクスモジュール２５０６に提供する。サイズ変更モジュール２５０２は、データセグメントのサイズを変更する要求をマルチプレクスモジュール２５０６から受け取り、マルチプレクスモジュール２５０６から受け取られたサイズ変更に従ってデータセグメントのサイズを変更する。」
「【０２６３】
　ビット管理モジュール２７０４は、生成されたスーパーフレームの各々のスーパーフレームのサイズをモニタリングし、スーパーフレームを送るために必要な送信チャネル資源（例えば、エアリンク資源）が送信チャネル２４０２を通じての利用可能な送信チャネル資源を超過しないようにする。ビット管理モジュール２７０４がスーパーフレームのサイズをモニタリングするのを援助するため、データ収集モジュール２７０６は、各々の符号器モジュール２７０４から品質及びレート情報を受け取る。データ収集モジュール２７０６は、例えば、符号器モジュール２４０４が現在のスーパーフレーム内に含めることを希望する各データセグメントと関連づけられた配送要求事項、例えば品質及びレート情報、を要求する要求を各々の符号器モジュール２４０４に送ることができる。品質及びレート情報は、データセグメントに関する少なくとも品質評価基準をビットレート又はデータサイズの関数として示す。例えば、データ収集モジュール２７０６は、ＰＳＮＲ等の品質評価基準をモデル化するセグメントに対応する品質−レート曲線を、各々のデータセグメントに関するビットレートの関数として受け取ることができる。他の例においては、データ収集モジュール２７０６は、データセグメントと関連づけられた品質−レートテーブルを受け取る。上述されるように、品質−レートテーブルは、様々な順位（又は品質レベル）及び異なる順位の各々と関連づけられたサイズを示すことができる。従って、品質及びレート情報は、特に、符号器モジュール２４０４が現在のスーパーフレームにおいて送信することを希望するデータセグメントに関する異なる品質レベルにおけるデータセグメントのサイズを記述する。」
「【０２６４】
　ビット管理モジュール２７０４は、少なくとも品質及びレート情報を解析して複数のデータセグメントが送信チャネル２４０２の利用可能な帯域幅内にぴったり納まるかどうかを決定することができる。ビット管理モジュール２７０４は、品質及びレート情報に加えてその他の配送要求事項を解析することができる。例えば、ビット管理モジュール２７０４は、ＯＲＴサービスと関連づけられた優先度及びレーテンシー要求事項を解析することができる。ビット管理モジュール２７０４は、データセグメント間で利用可能な帯域幅を割り当てることを試みる割り当てモジュール２７０８を含むことができる。割り当てモジュール２７０８は、例えば、上述される割り当てアルゴリズムのうちの１つを用いて利用可能な帯域幅を割り当てることを試みることができる。利用可能な帯域幅を割り当てる第１の試みにおいては、割り当てモジュール２７０８は、データセグメントと関連づけられた目標品質レベルと各々の品質−レート曲線との間の交点に対応するサイズを用いて帯域幅を割り当てることを試みることができる。他の例として、マルチプレクスモジュール２４０６は、データセグメントと関連づけられた品質−レートテーブルにおいて指定される最高の品質レベルに対応するサイズを用いてデータセグメントが現在のスーパーフレーム内にぴったり納まるかどうかに関する最初の決定を行うことができる。割り当てモジュール２７０８がデータセグメント間において帯域幅を割り当てることに成功した場合、例えば、データセグメントを送る上での十分な送信チャネル資源が存在し及び余分の送信チャネル資源が存在しない場合は、サイズ変更は必要ない。」
　
　ここで、上記段落【０２３６】の「複数のデータセグメントが利用可能な帯域幅内にぴったり納まらないことをマルチプレクスモジュール２４０６が決定した場合、例えば、スロット割り当てアルゴリズムが失敗であるか又は必要な送信チャネル資源の合計が利用可能な送信チャネル資源を超える場合は、マルチプレクスモジュール２４０６は、符号器モジュール２４０４から受け取られた品質及びレート情報に基づいてサイズが変更されるべき１つ以上のセグメントを選択する。」との記載、段落【０２４４】の「換言すると、符号器モジュール２５０４は、利用可能な帯域幅をデータセグメントに割り当て、その割り当てが失敗したときにサイズが変更されるべきデータセグメントのうちの１つ以上を選択する際に用いるために各々のデータセグメントと関連づけられた品質及びレート情報をマルチプレクスモジュール２５０６に提供する。」との記載、段落【０２６３】の「ビット管理モジュール２７０４がスーパーフレームのサイズをモニタリングするのを援助するため、データ収集モジュール２７０６は、各々の符号器モジュール２７０４から品質及びレート情報を受け取る。データ収集モジュール２７０６は、例えば、符号器モジュール２４０４が現在のスーパーフレーム内に含めることを希望する各データセグメントと関連づけられた配送要求事項、例えば品質及びレート情報、を要求する要求を各々の符号器モジュール２４０４に送ることができる。品質及びレート情報は、データセグメントに関する少なくとも品質評価基準をビットレート又はデータサイズの関数として示す。例えば、データ収集モジュール２７０６は、ＰＳＮＲ等の品質評価基準をモデル化するセグメントに対応する品質−レート曲線を、各々のデータセグメントに関するビットレートの関数として受け取ることができる。他の例においては、データ収集モジュール２７０６は、データセグメントと関連づけられた品質−レートテーブルを受け取る。」、段落【０２６４】の「割り当てモジュール２７０８は、例えば、上述される割り当てアルゴリズムのうちの１つを用いて利用可能な帯域幅を割り当てることを試みることができる。利用可能な帯域幅を割り当てる第１の試みにおいては、割り当てモジュール２７０８は、データセグメントと関連づけられた目標品質レベルと各々の品質−レート曲線との間の交点に対応するサイズを用いて帯域幅を割り当てることを試みることができる。他の例として、マルチプレクスモジュール２４０６は、データセグメントと関連づけられた品質−レートテーブルにおいて指定される最高の品質レベルに対応するサイズを用いてデータセグメントが現在のスーパーフレーム内にぴったり納まるかどうかに関する最初の決定を行うことができる。」との記載からは、本願明細書記載の発明における「品質及びレート情報」は「各々のデータセグメントと関連づけられた」ものであることが読み取れる。
　そして、上記『４．２．１．２．「複数のデータセグメント」とは』で述べたように、本願発明の「複数のデータセグメント」とは、それが「デジタルマルチメディアデータの流れを結合」する前であれば、その「結合」の対象となるものであり、既に「デジタルマルチメディアデータの流れを結合」した後であれば「結合」した結果であって、同時に伝送される複数の「データセグメント」のことを指すものということができるが、本願発明が「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取る」のは、上記明細書の記載からみて「デジタルマルチメディアデータの流れを結合」する前であると認められるから、結局、本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」の「複数のデータセグメント」とは、「前記デジタルマルチメディアデータの流れと関連づけられた」ものであり、「デジタルマルチメディアデータの流れを結合」する対象となるものであって、結合した後に同時に伝送される複数の「データセグメント」を指すということができる。
　これに加えて、上記『４．２．１．１．「データセグメント」とは』で述べたように、本願発明の「データセグメント」とは、マルチメディアデータの流れを符号化したものである。
　
　これらをまとめると、本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」における、「品質及びレート情報」は「各々のデータセグメントと関連づけられた」ものであり、「データセグメント」とはデジタルマルチメディアデータの流れを符号化したものであり、「複数のデータセグメント」とは、その「データセグメント」を複数まとめて「前記デジタルマルチメディアデータの流れと関連づけられた」ものであって、結局、本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」は、「デジタルマルチメディアデータの流れを結合する対象となる前記デジタルマルチメディアデータの流れと関連づけられ、結合した後に同時に伝送される複数のデータセグメントにおける、各々のデータセグメントと関連づけられた少なくとも品質及びレート情報」と解釈すべきものであるということができる。
　
４．２．２．本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」と引用発明の対比
　『４．２．１．「データセグメント」「複数のデータセグメント」「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」の解釈』で検討した、これらの解釈、すなわち、
　
(1)　本願発明の「データセグメント」とは、マルチメディアデータの流れを符号化したものであって、「データセグメント」の長さは「１秒」のような固定した時間の長さで決められるものであり、「データセグメント」が複数「結合」されて「スーパーフレームを形成」するものである。
(2)　本願発明の「複数のデータセグメント」とは、それが「デジタルマルチメディアデータの流れを結合」する前であれば、その「結合」の対象となるものであり、既に「デジタルマルチメディアデータの流れを結合」した後であれば「結合」した結果であって、同時に伝送される複数の「データセグメント」のことを指し「送信チャネル２４０２の利用可能な帯域幅内にぴったり納まるかどうかを決定する」対象となるものである。
(3)　本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」とは、「デジタルマルチメディアデータの流れを結合する対象となる前記デジタルマルチメディアデータの流れと関連づけられ、結合した後に同時に伝送される複数のデータセグメントにおける、各々のデータセグメントと関連づけられた少なくとも品質及びレート情報」と解釈すべきものである。
　
　を踏まえて、本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」と引用発明を以下対比する。
　
　ここで、引用発明の「リサイズ制御部は、リサイズアルゴリズムの実施形態を提供するものであって、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをするものであり、リサイズ制御部は、リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート（ｒ）の関数である品質関数 Q = f(r) を利用するものであり、この品質は、スーパーフレーム毎に、ＭＵＸへ、GetDataSize.Responseメッセージの中で送信されるものであり、リサイズアルゴリズムは、レートを（物理レイヤパケット（ＰＬＰ）を単位にして）、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がＲＴサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てるものであって、リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ、スロット割り当てが実行され、スロット割り当てが成功だった場合には、リサイズは成功と判断される」ものである。
　
４．２．２．１．「品質及びレート情報」
　引用発明の「ビットレート（ｒ）の関数である品質関数 Q = f(r) 」は、ビットレートと品質の関数であるから、引用発明の「ビットレート（ｒ）の関数である品質関数 Q = f(r) 」と本願発明の「品質及びレート情報」は、いずれも「品質及びレート」に関する情報である点で一致している。
　
４．２．２．２．「品質及びレート情報を受け取ること」
　引用発明の「この品質は、スーパーフレーム毎に、ＭＵＸへ、GetDataSize.Responseメッセージの中で送信されるもの」であって、ＭＵＸは「品質」を受け取っているといえるから、引用発明と本願発明は「少なくとも品質及びレート情報を受け取る」点で一致する。
　
４．２．２．３．「複数のデータセグメント」
　本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」の「複数のデータセグメント」とは、上記したように、それが「デジタルマルチメディアデータの流れを結合」する前であれば、その「結合」の対象となるものであり、既に「デジタルマルチメディアデータの流れを結合」した後であれば「結合」した結果であって、同時に伝送される複数の「データセグメント」のことを指し「送信チャネル２４０２の利用可能な帯域幅内にぴったり納まるかどうかを決定する」対象となるものである。
　これに対し、引用発明の「リサイズ制御部は、リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート（ｒ）の関数である品質関数 Q = f(r) を利用するものであり、この品質は、スーパーフレーム毎に、ＭＵＸへ、GetDataSize.Responseメッセージの中で送信されるものであ」るから、この「リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート（ｒ）の関数である品質関数 Q = f(r)」は、「リアルタイムストリーミングメディアサービスのサービスフロー」毎に存在するのみならず、「スーパーフレーム毎」に存在するといえる。そして、引用発明は、更に「スロット割り当てアルゴリズムは、コンテンツフローに、スーパーフレーム内のスロットを割り当てするものであって」「スロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与するものであ」るから、引用発明の「スーパーフレーム」は、本願発明の「複数のデータセグメント」と同様に「利用可能な帯域幅内にぴったり納まるかどうかを決定する対象となる」ものであって、この点で引用発明の「スーパーフレーム」と本願発明の「複数のデータセグメント」が一致している。
　
４．２．２．４．「データセグメントに関する少なくとも品質及びレート情報を受け取ること」
　上記『４．２．１．３．「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」とは』で述べたように、本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」とは、「デジタルマルチメディアデータの流れを結合する対象となる前記デジタルマルチメディアデータの流れと関連づけられ、結合した後に同時に伝送される複数のデータセグメントにおける、各々のデータセグメントと関連づけられた少なくとも品質及びレート情報」と解釈すべきものであって、本願発明の「品質及びレート情報」は「各々のデータセグメントと関連づけられた」ものである。
　これに対し、上記『４．２．２．３．「複数のデータセグメント」』で述べたように、引用発明の「リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート（ｒ）の関数である品質関数 Q = f(r)」は、「リアルタイムストリーミングメディアサービスのサービスフロー」毎、「スーパーフレーム毎」に存在するから、この「品質関数 Q = f(r)」は、それぞれの「スーパーフレーム」に対して「リアルタイムストリーミングメディアサービスのサービスフロー」の数だけ存在することとなり、逆にいえば、「スーパーフレーム」の中に複数存在する「リアルタイムストリーミングメディアサービスのサービスフロー」のそれぞれに関して「品質関数 Q = f(r)」があるといえる。
　すなわち、引用発明の「スーパーフレーム」の中に複数存在する「リアルタイムストリーミングメディアサービスのサービスフロー」のそれぞれと、本願発明の「データセグメント」が対応し、更に、引用発明の「品質関数 Q = f(r)」も本願発明と同様に「データセグメントに関する少なくとも品質及びレート情報」であるといえる。そして、上記『４．２．２．２．「品質及びレート情報を受け取ること」』で述べたように、引用発明と本願発明は「少なくとも品質及びレート情報を受け取る」点で一致するから、結局、引用発明も本願発明と同様に「データセグメントに関する少なくとも品質及びレート情報を受け取ること」で一致している。
　
４．２．２．５．「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメント」
　上記『４．２．１．３．「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」とは』で述べたように、本願発明の「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報」とは、「デジタルマルチメディアデータの流れを結合する対象となる前記デジタルマルチメディアデータの流れと関連づけられ、結合した後に同時に伝送される複数のデータセグメントにおける、各々のデータセグメントと関連づけられた少なくとも品質及びレート情報」と解釈すべきものであって、本願発明の「複数のデータセグメント」は「前記デジタルマルチメディアデータの流れと関連づけられた」ものである。
　そして、上記『４．２．２．３．「複数のデータセグメント」』で述べたように、引用発明の「スーパーフレーム」と本願発明の「複数のデータセグメント」が一致し、上記『４．２．２．４．「データセグメントに関する少なくとも品質及びレート情報を受け取ること」』で述べたように、引用発明の「スーパーフレーム」の中に複数存在する「リアルタイムストリーミングメディアサービスのサービスフロー」のそれぞれと、本願発明の「データセグメント」が対応しているから、結局、引用発明も本願発明と同様に「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメント」を有しているといえる。
　
４．２．３．「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」についてのまとめ
　したがって、引用発明と本願発明は「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」という点で一致しているといえる。
　
４．３．「前記複数のデータセグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定すること」
　ここで、本願発明の「前記複数のデータセグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定すること」の「ぴったり納まる」とは、どのような技術概念なのか、また、引用発明の「スロット割り当てアルゴリズムは、コンテンツフローに、スーパーフレーム内のスロットを割り当てするものであり」、「ＭＵＸは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与するものであ」るが、この「うまく適合させる」とは、どのような技術概念なのか、本願明細書の記載、引用例の記載を参酌して以下検討する。
　
　まず、本願明細書には、以下の記載がある。(なお、国際特許出願(PCT/US2008/052497)の特許協力条約第３条(2)に規定する明細書の対応箇所の記載を括弧内に併記する。))
　
「【０００５】
　前記マルチプレクスモジュールは、少なくとも前記品質及びレート情報を解析して前記符号器モジュールが送信することを希望するデータセグメントが送信チャネルの利用可能な帯域幅内にぴったり納まる（ｆｉｔ）かどうかを決定する。前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないと前記マルチプレクスモジュールが決定した場合は、前記マルチプレクスモジュールは、前記符号器モジュールから受け取られた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記セグメントのうちの１つ以上を選択する。マルチプレクスモジュールは、前記選択されたデータセグメントと関連づけられた前記符号器モジュールが前記縮小されたビット割り当てに従って前記データセグメントのサイズを変更するように要求する。」(“[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.”)
「【０１２８】
　一側面においては、ＭＵＸ１１４は、上述されるスロット割り当てアルゴリズムの側面を備えるコンテンツスケジューリング機能を提供するために動作する。サイズ変更コントローラ１１６は、サイズ変更アルゴリズムの側面を提供する。スロット割り当てアルゴリズムは、スーパーフレーム内のすべてのメディアサービスに割り当てられたスロット（レート）をぴったり納める責任を有する。一定のシステム上の制約（例えば、デバイスのターボ復号器のピークスループットは、単一のＯＦＤＭシンボルにおいて特定のメディアサービスに割り当てることができるスロット数を制限する）は、割り当てられた総スロット数がスーパーフレームにおいて利用可能な総スロット数以下であるにもかかわらずスロット割り当て手順を失敗させる可能性がある。さらに、エアリンク資源要求の圧倒的割合を占めることが予想されるリアルタイムのサービス構成要素は、映像コンテンツである。このコンテンツは、ソースコーディングを用いて圧縮され、その結果可変性が非常に高いビートレート流になる。最後に、リアルタイムサービスの送信に関して利用可能なスーパーフレーム当たりの容量は、その他の同時並行するメディアサービスの要求事項に起因して変化する可能性がある。これらの要因は、以下の割り当て状態のうちの１つを生じさせる。」(“[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.”)
　
　上記段落【０００５】には「前記マルチプレクスモジュールは、少なくとも前記品質及びレート情報を解析して前記符号器モジュールが送信することを希望するデータセグメントが送信チャネルの利用可能な帯域幅内にぴったり納まる（ｆｉｔ）かどうかを決定する。前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないと前記マルチプレクスモジュールが決定した場合は、前記マルチプレクスモジュールは、前記符号器モジュールから受け取られた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記セグメントのうちの１つ以上を選択する。」との記載が、上記段落【０１２８】には「スロット割り当てアルゴリズムは、スーパーフレーム内のすべてのメディアサービスに割り当てられたスロット（レート）をぴったり納める責任を有する。」との記載があり、これらは、それぞれ、国際特許出願(PCT/US2008/052497)の特許協力条約第３条(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])との記載に対応するものと認められる。
　
　これに対し、引用発明は「ＭＵＸは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与するものであ」るが、上記「３．２．引用例記載の発明」の「第三に」で述べたように、この「このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与する」とは、引用例の上記段落[00129]の“The slot allocation algorithm is responsible for fitting the slots (rate) allocated to all the media services in a superframe.”(「このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与する。」(段落【０１４１】))という部分に対応するものである。
　
　そうすると、本願発明の「ぴったり納まる」は、国際特許出願(PCT/US2008/052497)の特許協力条約第３条(2)に規定する明細書の“fit”に対応するものであり、引用発明の「うまく適合させる」も“fit”に対応するものであるから、結局、引用発明の「うまく適合させる」と本願発明の「ぴったり納まる」は同じ意味であって、引用発明と本願発明は、いずれも「ぴったり納まる」ようにしている点で一致している。
　
　更に、引用発明の「スロット割り当てアルゴリズムは、コンテンツフローに、スーパーフレーム内のスロットを割り当てするものであって、割り当てアルゴリズムは、効率的な帯域幅利用を実現する働きをするものであり」、「ＭＵＸは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与するものであ」り、「リサイズアルゴリズムは、レートを（物理レイヤパケット（ＰＬＰ）を単位にして）、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がＲＴサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てるものであって、リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ、スロット割り当てが実行され、スロット割り当てが成功だった場合には、リサイズは成功と判断される」ものであって、この「スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させること」によって「効率的な帯域幅利用を実現」され、「スロット割り当てが成功だった場合には、リサイズは成功と判断される」のであるから、引用発明も本願発明と同様に「利用可能な帯域幅内にぴったり納まるかどうかを決定する」ことを行っているということができる。
　
　そして、上記『４．２．「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」』で述べたように、引用発明の「スーパーフレーム」と本願発明の「複数のデータセグメント」が対応するということができる。
　
　結局、引用発明と本願発明は「前記複数のデータセグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定すること」という点で一致する。
　
４．４．「前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないときに前記複数のデータセグメントと関連づけられた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記複数のデータセグメントのうちの１つ以上を選択すること」「前記複数のセグメントに関する前記利用可能な帯域幅を達成するために前記１つ以上の選択されたデータセグメントの各々のサイズ変更を要求すること」
　引用発明は「ＭＵＸ、及び、その一部をなすリサイズ制御部を有し、ＭＵＸは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与するものであり、リサイズ制御部は、リサイズアルゴリズムの実施形態を提供するものであって、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをするものであり、リサイズ制御部は、リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート（ｒ）の関数である品質関数 Q = f(r) を利用するものであり、この品質はスーパーフレーム毎にＭＵＸへ、GetDataSize.Responseメッセージの中で送信されるものであり、リサイズアルゴリズムは、レートを（物理レイヤパケット（ＰＬＰ）を単位にして）、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がＲＴサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てるものであって、リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ、スロット割り当てが実行され、スロット割り当てが成功だった場合には、リサイズは成功と判断される」ものである。
　
　第一に、上記『４．３．「前記複数のデータセグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定すること」』で述べたように、引用発明と本願発明は「前記複数のデータセグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定すること」という点で一致するから、引用発明も本願発明同様に「前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないときに」という判断をしているといえる。
　第二に、上記『４．２．「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」』で述べたように、引用発明と本願発明は「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」という点で一致しており、引用発明の「リサイズ制御部」は、この「品質及びレート情報」に相当する「リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート（ｒ）の関数である品質関数 Q = f(r) を利用」しているものであるから、引用発明と本願発明は「前記複数のデータセグメントと関連づけられた少なくとも前記品質及びレート情報」を利用している点で一致している。
　第三に、引用発明は「ＭＵＸは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与するものであり」、「リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ」るものであって、上記『４．２．「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」』で述べたように、引用発明と本願発明は「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」という点で一致しており、また、上記『４．２．「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」』で述べたように、引用発明の「スーパーフレーム」と本願発明の「複数のデータセグメント」が対応することからみて、引用発明は本願発明の「前記複数のデータセグメントと関連づけられた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記複数のデータセグメントのうちの１つ以上を選択すること」および「前記複数のセグメントに関する前記利用可能な帯域幅を達成するために前記１つ以上の選択されたデータセグメントの各々のサイズ変更を要求すること」と同様の処理を行っているといえる。
　
　したがって、引用発明と本願発明は「前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないときに前記複数のデータセグメントと関連づけられた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記複数のデータセグメントのうちの１つ以上を選択すること」「前記複数のセグメントに関する前記利用可能な帯域幅を達成するために前記１つ以上の選択されたデータセグメントの各々のサイズ変更を要求すること」を有する点で一致している。
　
４．５．「前記選択されたデータセグメントのサイズ変更を要求することは、前記選択されたデータセグメントに関する少なくとも最大サイズを指定することを備える」
　本願発明は「前記選択されたデータセグメントのサイズ変更を要求することは、前記選択されたデータセグメントに関する少なくとも最大サイズを指定することを備える」ものであるが、この「最大サイズ」の意味について、明細書の記載を参酌して以下検討する。
　
　本願明細書には「最大サイズ」という用語を用いた以下の記載がある。
　
「【０２３８】
　選択されたデータセグメントと関連づけられた符号器モジュール２４０４は、各々のデータセグメントと関連づけられたサイズ変更要求を受け取り、マルチメディアデータセグメントのサイズを変更する。符号器モジュール２４０４は、幾つかの異なる方法でデータセグメントのサイズを変更することができる。選択されたデータセグメントと関連づけられた符号器モジュール２４０４は、１つ以上の符号化変数を調整し、データセグメントのサイズをサイズ変更要求において指定される最大サイズ以下に縮小することができる。例えば、符号化モジュール２４０４は、より高い量子化パラメータ（ＱＰ）を用いてデータセグメントを再符号化することができる。他の例として、符号化モジュール２４０４は、引き下げられた符号化レートでデータセグメントを再符号化することができる。代替として又は追加で、符号化モジュール２４０４は、符号化されるべき情報量を減らし、それによってデータセグメントのサイズを縮小することができる。幾つかの場合においては、符号化モジュール２４０４は、１つ以上の符号化変数を調整し、サイズ変更要求において指定されるサイズとなるデータセグメントのサイズを拡大することができる。例えば、符号化モジュール２４０４は、より小さいＱＰを用いてデータセグメントを再符号化するか又は引き上げられた符号化レートでデータセグメントを再符号化することができる。」
「【０２５８】
　符号器モジュール２６００と関連づけられたデータセグメントのうちのいずれかをサイズ変更する必要がある場合は、マルチプレクスモジュール（２４０６、２５０６）は、符号器モジュール２６００にサイズ変更要求を送る。サイズ変更要求に応答して、サイズ変更モジュール２６１２は、マルチメディアデータセグメントのサイズを変更する。一例においては、サイズ変更モジュール２６１２は、データセグメントのサイズを大きくする、すなわち、データセグメントを拡大することができる。他の例においては、サイズ変更モジュール２６１２は、データセグメントのサイズを小さくする、すなわちデータセグメントを縮小する。データセグメントの縮小は、データセグメントの品質レベルを目標品質レベル以下に低下させる可能性がある。しかしながら、サイズが変更されたデータセグメントの品質レベルが最低品質レベルを下回る場合は、サイズ変更モジュール２６１２は、最低品質レベル以上であるサイズにデータセグメントのサイズを変更することしかできない。マルチプレクスモジュール（２４０６、２５０６）からのサイズ変更要求は、データセグメントに関するサイズ、例えば最大サイズ、を含むことができ、及びサイズ変更モジュール２６１２は、再符号化要求において指定されるサイズを達成するために１つ以上の符号化変数を調整することができる。サイズ変更モジュール２６１２は、例えば、データセグメントのサイズを変更するためにデータセグメントを調整されたビットレートで再符号化する、例えば、データセグメントがサイズ変更要求において指定される最大サイズ以下になるようにサイズ変更するためにデータセグメントを引き下げられたビットレートで再符号化することができる。他の例として、サイズ変更モジュール２６１２は、調整された量子化パラメータを用いてデータセグメントを再符号化することができる。」
「【０２７４】
　上記のパラメータに基づき、選択モジュール２７１０は、４８００ｋｂｐｓのビットレートを第１のマルチメディアセグメントに割り当て、２００ｋｂｐｓのビットレートを第２のマルチメディアセグメントに割り当てる。１秒のデータセグメントの場合は、第１のデータセグメントの最大サイズは、４８００キロビットで、第２のデータセグメントの最大サイズは２００キロビットである。選択モジュール２７１０は、品質及びレート情報において示されるデータセグメントの推定サイズを計算された最大サイズと比較し、関連づけられた最大サイズを超えるいずれかのデータセグメントをサイズ変更されるべきセグメントとして選択する。」
　
　ここで、上記段落【０２３８】の「選択されたデータセグメントと関連づけられた符号器モジュール２４０４は、１つ以上の符号化変数を調整し、データセグメントのサイズをサイズ変更要求において指定される最大サイズ以下に縮小することができる。」、段落【０２５８】の「サイズ変更モジュール２６１２は、例えば、データセグメントのサイズを変更するためにデータセグメントを調整されたビットレートで再符号化する、例えば、データセグメントがサイズ変更要求において指定される最大サイズ以下になるようにサイズ変更するためにデータセグメントを引き下げられたビットレートで再符号化することができる。」との記載からみて、本願発明の「最大サイズ」とは、それが指定されたときには、データセグメントのサイズを、指定された
「最大サイズ」以下に縮小するためのものであるということができる。更に、上記段落【０２７４】の「選択モジュール２７１０は、品質及びレート情報において示されるデータセグメントの推定サイズを計算された最大サイズと比較し、関連づけられた最大サイズを超えるいずれかのデータセグメントをサイズ変更されるべきセグメントとして選択する。」との記載からみて、本願発明の「最大サイズ」とは、更に、それが指定されたときには、「最大サイズ」を超えるデータセグメントがサイズ変更されるべきセグメントとして選択されるものであるともいうことができる。
　
　以下、この解釈を踏まえて、本願発明の「前記選択されたデータセグメントのサイズ変更を要求することは、前記選択されたデータセグメントに関する少なくとも最大サイズを指定することを備える」と引用発明を比較する。
　
　引用発明は「ＭＵＸ、及び、その一部をなすリサイズ制御部を有し、ＭＵＸは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与するものであり、リサイズ制御部は、リサイズアルゴリズムの実施形態を提供するものであって、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをするものであり、リサイズ制御部は、リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート（ｒ）の関数である品質関数 Q = f(r) を利用するものであり、この品質はスーパーフレーム毎にＭＵＸへ、GetDataSize.Responseメッセージの中で送信されるものであり、リサイズアルゴリズムは、レートを（物理レイヤパケット（ＰＬＰ）を単位にして）、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がＲＴサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てるものであって、リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ、スロット割り当てが実行され、スロット割り当てが成功だった場合には、リサイズは成功と判断される」ものである。
　
　第一に、上記『４．４．「前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないときに前記複数のデータセグメントと関連づけられた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記複数のデータセグメントのうちの１つ以上を選択すること」「前記複数のセグメントに関する前記利用可能な帯域幅を達成するために前記１つ以上の選択されたデータセグメントの各々のサイズ変更を要求すること」』で述べたように、引用発明と本願発明は「選択されたデータセグメントのサイズ変更を要求する」点で一致している。
　第二に、引用発明の「リサイズアルゴリズムは、レートを（物理レイヤパケット（ＰＬＰ）を単位にして）、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がＲＴサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てるもの」であるから、「リアルタイムサービスに割り当て」られるのは「レート」であるが、引用発明の「レート」と本願発明の「選択されたデータセグメントに関する少なくとも最大サイズ」は、いずれも「データセグメント」の情報量に関するものであるという点で一致している。そして、通常、「データセグメントに関する」「サイズ」を、「データセグメントに関する」「レート」に換算するときには、その「データセグメント」の時間長による除算が必要となるが、上記『４．２．「前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ること」』で述べたように、本願発明の「データセグメント」の長さは「１秒」のような固定した時間の長さで決められるものであって、それを前提とすると、本願発明の「データセグメントに関する」「サイズ」は、そのまま「データセグメントに関する」「レート」であるともいうことができるから、結局、引用発明の「レート」と本願発明の「サイズ」は同じものであるということができる。
　第三に、引用発明において「レート」を「リアルタイムサービスに割り当てる」の「割り当てる」という行為自体は、いずれも、情報量に関する数値を与えるという点で、本願発明の「指定する」と同じ行為であるということができる。
　
　しかしながら、引用発明のようにコンテンツの情報圧縮を行う場合、その圧縮率を指定するときに、圧縮後のコンテンツのレートの目標値の形で指定すること、および、この圧縮後のコンテンツのレートの目標値を、「平均レート」や「最大レート」等の形で指定することは、例を挙げるまでもなく極めて良く行われているといえるところ、引用例には、引用発明において「リアルタイムサービスに割り当て」られる「レート」が、これら「平均レート」や「最大レート」等の、いずれの「レート」であるのか記載されていないから、この「指定」される「サイズ」が、本願発明は「最大」サイズであるのに対し、引用発明ではどのようなものなのか明らかではない点で相違する。
　
　したがって、引用発明と本願発明は「前記選択されたデータセグメントのサイズ変更を要求することは、前記選択されたデータセグメントに関する少なくともサイズを指定することを備える」点で一致し、この「指定」される「サイズ」が、本願発明は「最大」サイズであるのに対し、引用発明ではどのようなものなのか明らかではない点で相違する。
　
５．一致点・相違点
　したがって、本願発明と引用発明１は以下の点で一致し、相違する。
　
[一致点]
「デジタルマルチメディアデータの流れを結合するための方法であって、
　前記デジタルマルチメディアデータの流れと関連づけられた複数のデータセグメントに関する少なくとも品質及びレート情報を受け取ることと、
　前記複数のデータセグメントが利用可能な帯域幅内にぴったり納まるかどうかを決定することと、
　前記複数のデータセグメントが前記利用可能な帯域幅内にぴったり納まらないときに前記複数のデータセグメントと関連づけられた少なくとも前記品質及びレート情報に基づいてサイズが変更されるべき前記複数のデータセグメントのうちの１つ以上を選択することと、
　前記複数のセグメントに関する前記利用可能な帯域幅を達成するために前記１つ以上の選択されたデータセグメントの各々のサイズ変更を要求することと、
　前記選択されたデータセグメントのサイズ変更を要求することは、前記選択されたデータセグメントに関する少なくともサイズを指定することを備える、方法。」
　
［相違点］
　「指定」される「サイズ」が、本願発明は「最大」サイズであるのに対し、引用発明ではどのようなものなのか明らかではない点。
　
６．当審の判断
　上記相違点について検討する。
　
　引用発明の「ＭＵＸは、スロット割り当てアルゴリズムの実施形態を備えるコンテンツスケジューリング機能を提供するものであって、このスロット割り当てアルゴリズムは、スーパーフレーム内の全てのメディアサービスに割り当てられるスロット（レート）を、うまく適合させることに関与するものであり、リサイズ制御部は、リサイズアルゴリズムの実施形態を提供するものであって、サービスがフレームの中に詰め込まれることが可能になるように、これらのサービスをどのようにリサイズするかを制御する働きをするものであり、リサイズ制御部は、リアルタイムストリーミングメディアサービスのサービスフローに割り当てられるビットレート（ｒ）の関数である品質関数 Q = f(r) を利用するものであり、この品質はスーパーフレーム毎にＭＵＸへ、GetDataSize.Responseメッセージの中で送信されるものであり、リサイズアルゴリズムは、レートを（物理レイヤパケット（ＰＬＰ）を単位にして）、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がＲＴサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てるものであって、リサイズ制御部は、コードブロックの削減を実行した後に結果として生じるであろう最大品質を伴うフローを決定し、最大品質が、システムの最小品質要求よりも大きい場合は、最大品質を有するフローがリサイズされ、スロット割り当てが実行され、スロット割り当てが成功だった場合には、リサイズは成功と判断される」ものである。ここで、「リサイズアルゴリズムは、レートを（物理レイヤパケット（ＰＬＰ）を単位にして）、スロット割り当てアルゴリズムが成功することができるように、割り当てられたレートの合計がＲＴサービスに対する利用可能な容量より少ないか又はこれと同じになるように、リアルタイムサービスに割り当てる」ときに、この「リアルタイムサービスに割り当てる」「レート」として「最大レート」を用いることは、その「リアルタイムサービス」の符号化レートが経時的に変化するものであったとしても、それを用いることによって、「割り当てられたレートの合計がＲＴサービスに対する利用可能な容量より少ないか又はこれと同じになる」ことを必ず実現できることから、当業者が自然に選択することにすぎない。
　そして、上記『４．５．「前記選択されたデータセグメントのサイズ変更を要求することは、前記選択されたデータセグメントに関する少なくとも最大サイズを指定することを備える」』で述べたように、本願発明の「データセグメント」の長さは「１秒」のような固定した時間の長さで決められるものであって、それを前提とすると、本願発明の「データセグメントに関する」「サイズ」は、そのまま「データセグメントに関する」「レート」であるともいうことができるから、本願発明のように「最大サイズ」を指定するようにしたことは、当業者が容易になしえたことにすぎない。
　
　また、本願発明は、格別の作用効果を奏するものとも認められない。
　
　したがって、本願発明は、引用発明に基づき当業者が容易に発明できたものである。
　
７．むすび
　以上のとおり、平成２６年１月３０日付手続補正書で補正された請求項１に係る発明は、引用例に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条２項の規定により特許を受けることができない。
　
　したがって、本願は平成２６年１月３０日付手続補正書で補正された請求項２〜１０５に係る発明について特に検討するまでもなく拒絶されるべきものである。
　
　よって、結論のとおり審決する。