【事件の表示】
　特願２０１３−５５０４０６「相互階層最適化を用いた、マルチメディアデータパケットを送信する方法及び装置」拒絶査定不服審判事件〔平成２４年　７月２６日国際公開、ＷＯ２０１２／０９９４１７、平成２６年　４月１０日国内公表、特表２０１４−５０９１１３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２０１２年（平成２４年）１月１９日（パリ条約による優先権主張外国庁受理２０１１年１月１９日、韓国）を国際出願日とする出願であって、その手続の経緯は以下のとおりである。
平成２７年１０月　８日付け：拒絶理由通知
平成２８年　１月１９日　　：意見書、手続補正書の提出
平成２８年　６月３０日付け：拒絶査定
平成２８年１１月　４日　　：審判請求書、手続補正書の提出
平成２９年１０月２６日付け：拒絶理由通知（当審）
平成３０年　３月３０日　　：意見書、手続補正書の提出
平成３０年　８月　７日付け：拒絶理由通知（当審）（最後）
平成３０年１２月１３日　　：意見書、手続補正書の提出
第２　平成３０年１２月１３日付けの手続補正についての補正の却下の決定
［補正の却下の決定の結論］
　平成３０年１２月１３日付けの手続補正を却下する。
［理由］
１　本件補正の内容
　平成３０年１２月１３日付けの手続補正（以下、「本件補正」という。）は、平成３０年３月３０日付けの手続補正により補正された特許請求の範囲の請求項１及び２を、本件補正による特許請求の範囲の請求項１及び２に補正するものであり、そのうち、請求項１に係る手続補正は以下のとおりである（下線は補正箇所を示す。）。
　なお、請求項中の各構成の符号は、説明のために当審において付与したものであり、以下、補正前の請求項１については構成Ａ〜構成Ｆと称し、補正後の請求項１については構成Ａ１〜構成Ｇ１と称する。
（補正前の請求項１）
　　【請求項１】
（Ａ）下位階層とアプリケーション階層を含む一つのエンティティーで前記下位階層と前記アプリケーション階層を接続するインターフェースに基づいて、マルチメディアデータを送信する方法であって、
（Ｂ）前記下位階層から前記アプリケーション階層にネットワークチャネル状態情報を前記インターフェースを通して周期的又は非周期的なボトムアップ式情報（ボトムアップネットワーク抽象化階層（Ｂ−ＮＡＬ）情報）として提供するステップと、
（Ｃ）前記アプリケーション階層から前記下位階層にメディア特性に対する情報(メディアデータに関連する情報)を前記インターフェースを通してトップダウン式情報として提供するステップと、
（Ｄ）前記下位階層から前記トップダウン式情報として提供される前記メディア特性に対する情報に基づいてマルチメディアデータを送信するステップとを含み、
（Ｅ）前記トップダウン式情報として提供される前記メディア特性に対する情報は、リソース割り当て又は前記下位階層でサポートするサービス品質を識別するために使用されるレベル情報を含み、
（Ｆ）前記ボトムアップ式情報として提供される前記ネットワークチャネル状態情報は、異種ネットワーク環境で獲得した情報である
（Ａ）ことを特徴とする方法。
（補正後の請求項１）
　　【請求項１】
（Ａ１）下位階層とアプリケーション階層を含む
送信装置
、メ
（Ｂ１）前記下位階層から前記アプリケーション階層に
ユーザの要請サービス品質と、
（Ｇ１）
前記アプリケーション階層で前記下位階層から前記ボトムアップ式情報として提供を受けた前記ユーザの要請サービス品質と前記ネットワークチャネル状態情報に基づいて、メディアデータのサービス品質を決定し、前記決定されたメディアデータのサービス品質に関する情報を含むメディアデータに関連した情報を生成するステップと、
（Ｃ１）前記アプリケーション階層から前記下位階層に
前記生成された
を
（トップダウンネットワーク抽象化階層（Ｔ−ＮＡＬ）情報）
（Ｄ１）（Ｄ１１）前記下位階層
で前記アプリケーション階層から
を受けた
データに関連した
含まれたレベル情報により、パケットの損失重要度及び遅延重要度、優先順位またはリソース予約状態を認識し、
（Ｄ１２）
前記認識したパケットの損失重要度及び遅延重要度、優先順位またはリソース予約状態を考慮して選択されたメディアデータにより、前記レベル情報をヘッダーに含むパケットを生成し、
（Ｄ１３）
前記生成したパケット
（Ｆ１）前記ボトムアップ式情報として提供される前記ネットワークチャネル状態情報は、
使用可能なビット率 、リアルタイム転送プロトコル（Real-time Transport Protocol：ＲＴＰ）の結果として測定されたパケット損失率、遅延またはジッターに関する情報を含む
（Ａ１）ことを特徴とする方法。
２　補正の適合性
（１）補正事項
　請求項１に係る手続補正は、補正前の構成Ｄの「前記下位階層から前記トップダウン式情報として提供される前記メディア特性に対する情報に基づいてマルチメディアデータを送信するステップ」という記載を、補正後の構成Ｄ１の「前記下位階層
で前記アプリケーション階層から
を受けた
データに関連した
含まれたレベル情報により、パケットの損失重要度及び遅延重要度、優先順位またはリソース予約状態を認識し、前記認識したパケットの損失重要度及び遅延重要度、優先順位またはリソース予約状態を考慮して選択されたメディアデータにより、前記レベル情報をヘッダーに含むパケットを生成し、前記生成したパケット
　ここで、本件補正後の請求項１に係る発明は、「下位階層とアプリケーション階層を含む送信装置で前記下位階層と前記アプリケーション階層を接続するインターフェースに基づいて、メディアデータを送信する方法」（構成Ａ１）であるから、構成Ｄ１のステップは、「送信装置」で行われるステップといえる。
　また、構成Ｄ１に係る記載は、構成Ｄ１１〜構成Ｄ１３の順序で記載されており、加えて、構成Ｄ１２は、構成Ｄ１１で認識した「パケットの損失重要度及び遅延重要度、優先順位またはリソース予約状態」を考慮して選択されたメディアデータにより、パケットを生成するものであり、構成Ｄ１３は構成Ｄ１２で生成したパケットを送信するものであるから、構成Ｄ１は、構成Ｄ１１、構成Ｄ１２、構成Ｄ１３の順序で処理を行うと解される。
（２）翻訳文等に記載された事項
　本願の国際出願日における国際特許出願の明細書若しくは図面（図面の中の説明に限る。）の翻訳文、国際出願日における国際特許出願の請求の範囲の翻訳文又は国際出願日における国際特許出願の図面（図面の中の説明を除く。）（以下、「翻訳文等」という。）には、以下の記載がある。
　なお、下線は、強調のために当審で付したものである。
ア「【００３７】
　一方、
送信装置（例えば、サーバ又は端末）は、Ｔ−ＮＡＬ情報を生成し、Ｔ−ＮＡＬ情報をパケットのヘッダーに含んで送信する
ネットワークエンティティー（例えば、ルータ又は基地局（ＢＳ））は、Ｔ−ＮＡＬ情報を用いてパケットの重要度又はリソース予約状態を識別し、したがって、この識別された結果に基づいてパケットを送信することができる
イ「【００３９】
　図３は、本発明によるマルチメディアデータパケットを送信する装置及び方法を示す。送信装置３００は、サーバ又は端末であることができる。
【００４０】
　図３を参照すると、
送信装置３００は
パケット生成部３０３
相互階層最適化（Cross Layer Optimization：ＣＬＯ）部３０２
を含む
【００４１】
　Ｂ−ＮＡＬレジスタ３０４は、ネットワーク３１３からＢ−ＮＡＬ情報３１０を受信し記憶する。Ｂ−ＮＡＬ情報は、一般的に、ネットワークエンティティーにより生成されたネットワーク状態情報である。しかしながら、Ｂ−ＮＡＬ情報は、ユーザー端末により要求されるＱｏＳ情報又はメディアデータ制御に適合した制御情報であり得る。例えば、ユーザー端末の状態が高いＱｏＳサービスの受信に不適切である場合に、ユーザーは、低いＱｏＳパケットサービスを要求することができる。送信パケットの遅延及び損失が大きい場合に、特定のメディアは、このような情報をＢ−ＮＡＬレジスタ３０４から取得することができる。この場合に、Ｂ−ＮＡＬ情報は、ユーザーからの要求に従ってユーザー端末により生成された情報であり得る。しかしながら、説明の便宜上、下記の説明では、Ｂ−ＮＡＬ情報がネットワーク状態情報であることを仮定する。
【００４２】
　ＣＬＯ部３０２は、Ｂ−ＮＡＬレジスタ３０４からＢ−ＮＡＬ情報を読み出すか又は受信されたＢ−ＮＡＬパケットから読み出し、Ｂ−ＮＡＬ情報に従って送信されるメディアデータの品質を適応的に決定し、この送信されるメディアデータを少なくとも１つのアクセス単位（Access Unit：ＡＵ）でメディアデータ供給部３０１に要求し（３０５）、このメディアデータをメディアデータ供給部３０５から受信する（３０６）。
【００４３】
　この後に、ＣＬＯ部３０２は、１つのＩＰパケットを通して送信されるメディアデータをパケット生成部３０３に送信する（３０９）。この時に、
ＣＬＯ部３０２は、対応するメディアデータに関するＴ−ＮＡＬ情報、すなわち、ラベル情報を生成し、このラベル情報をパケット生成部３０３に送信する
このラベル情報は、下位ネットワークがパケットの重要度、優先順位、又はリソース予約状態を認識するために使用することができる
【００４４】
　
パケット生成部３０３は、この受信されたラベル情報を含むパケットを生成し、この生成されたパケットを、ネットワーク３１３を通して送信する（３１１）
ウ「【００４９】
　
パケットは、下位階層ネットワークエンティティーが対応するメディアデータパケットに関するメディアデータパケットの損失レベル、遅延レベル、又は優先順位レベル、又はリソース予約情報を認識することができるようにラベルの形態でＴ−ＮＡＬ情報を含む
エ「【００７６】
　以上、本発明により定義されたＴ−ＮＡＬ情報及びＢ−ＮＡＬ情報について説明した。ＣＬＯは、Ｔ−ＮＡＬ情報及びＢ−ＮＡＬ情報を使用して可能である。相互階層最適化は、ネットワーク状態を認識してビデオ符号化を実行し（network-aware video coding）、メディアストリームに関する情報、すなわち、メディアストリームの重要度又は優先順位などを認識して動作するメディアネットワークエンティティーによりメディアデータサービスを提供することを意味する。このメディアストリームに関する情報に基づいてサービスするエンティティーをメディア認識ネットワークエレメント（Media Aware Network Element：ＭＡＮＥ）と呼ぶ。下記では、“ＭＡＮＥ”という用語を使用して説明する。
【００７７】
　以下では、本発明の
ネットワークエンティティー、すなわち、ＭＡＮＥ
【００７８】
　ルータ、ＩＥＥＥ８０２シリーズのＭＡＣ階層、及び３ＧＰＰ ＢＭＳＣのように受信されたメディアパケットをフォーワーディング（fowading）するネットワークエンティティーは、Ｔ−ＮＡＬ情報のラベル情報から決定されたパケットの重要度に従ってパケットを適応的にフォーワーディングするＭＡＮＥとして動作することができる。例えば、ｄｉｆｆＳｅｒｖルーティング方式を使用するルータは、データがバッファを超過する場合に、優先順位がもっとも低いパケットから廃棄する。このために、ルータは、Ｔ−ＮＡＬのラベル値を確認する。
【００７９】
　
クラス別ＱｏＳ方式の場合に
パケットのＩＰヘッダーに含まれている重要度情報、すなわち、ラベル値
ラベル値に従ってパケットを廃棄する
【００８０】
　
フロー別ＱｏＳ方式の場合に、ラベル値を確認し、ラベル値に対応する予め定められたリソースを用いてＱｏＳ（ビット率、損失率、及び遅延など）をサポートする
【００８１】
　図７は、本発明の実施形態によるＭＡＮＥの動作の一例を示す。
【００８２】
　図７を参照すると、ＭＡＮＥ７０１は、リソース予約テーブル７０２と、フォーワーディングポリシー決定部７１１と、使用可能なリソース判定部７０８とを含む。
【００８３】
　
送信装置からパケットを受信する
【００８４】
　ＭＡＮＥ７０１がクラス別ＱｏＳをサポートする場合に、フォーワーディングポリシー決定部７１０は、対応するパケットのクラスを確認した後に、このパケットのクラスに従って対応するパケットをフォーワーディングするか否かを決定する。一方、ＭＡＮＥ７０１がストリーム別ＱｏＳをサポートする場合に、フォーワーディングポリシー決定部７１０は、このパケットのラベル値を確認し、リソース予約テーブル７０２内の対応するラベルに割り当てられたリソースを確認し（７０５及び７１１）、使用可能なリソース判定部７０４から使用可能なリソース情報を受信し（７０７）、使用可能なリソース内のパケットに対するフォーワーディングポリシーを決定した後に、このフォーワーディングポリシーに従ってこのパケットをフォーワーディングする（７１０）。」
（３）新規事項について
　補正事項について、請求人は、平成３０年１２月１３日付け意見書において、本願の段落００３７、段落００４３、段落００４４、および段落００４９にサポートされている旨を主張しているので、以下、補正事項による補正後の構成Ｄ１が、翻訳文等に記載された事項の範囲内か否かについて検討する。
　上記（２）アによれば、「送信装置（例えば、サーバ又は端末）」は、Ｔ−ＮＡＬ情報を生成し、Ｔ−ＮＡＬ情報をパケットのヘッダーに含んで送信し、「ネットワークエンティティー（例えば、ルータ又は基地局（ＢＳ））」は、Ｔ−ＮＡＬ情報を用いてパケットの重要度又はリソース予約状態を識別し、この識別された結果に基づいてパケットを送信することが記載されている。
　上記（２）イによれば、「送信装置３００」に含まれる「ＣＬＯ部３０２」は、対応するメディアデータに関するＴ−ＮＡＬ情報、すなわち、ラベル情報を生成し、このラベル情報をパケット生成部３０３に送信し、このラベル情報は、下位ネットワークがパケットの重要度、優先順位、又はリソース予約状態を認識するために使用することができ、「送信装置３００」に含まれる「パケット生成部３０３」は、この受信されたラベル情報を含むパケットを生成し、この生成されたパケットを、ネットワーク３１３を通して送信することが記載されている。
　上記（２）ウによれば、パケットは、下位階層ネットワークエンティティーが対応するメディアデータパケットに関するメディアデータパケットの損失レベル、遅延レベル、又は優先順位レベル、又はリソース予約情報を認識することができるようにラベルの形態でＴ−ＮＡＬ情報を含むことが記載されている。
　上記（２）エによれば、「ネットワークエンティティー」、すなわち、「ＭＡＮＥ」は、送信装置からパケットを受信し、クラス別ＱｏＳ方式の場合に、パケットのＩＰヘッダーに含まれている重要度情報、すなわち、ラベル値に従ってパケットを廃棄し、フロー別ＱｏＳ方式の場合に、ラベル値を確認し、ラベル値に対応する予め定められたリソースを用いてＱｏＳ（ビット率、損失率、及び遅延など）をサポートすることが記載されている。
　以上によれば、翻訳文等には、「送信装置」について、以下の事項が記載されているといえる。
・「送信装置（例えば、サーバ又は端末）」は、Ｔ−ＮＡＬ情報を生成し、Ｔ−ＮＡＬ情報をパケットのヘッダーに含んで送信する。
・「送信装置３００」に含まれる「ＣＬＯ部３０２」は、対応するメディアデータに関するＴ−ＮＡＬ情報、すなわち、ラベル情報を生成し、このラベル情報をパケット生成部３０３に送信する。
・「送信装置３００」に含まれる「パケット生成部３０３」は、この受信されたラベル情報を含むパケットを生成し、この生成されたパケットを、ネットワーク３１３を通して送信する。
　また、翻訳文等には、「ネットワークエンティティー」について、以下の事項が記載されているといえる。
・「ネットワークエンティティー（例えば、ルータ又は基地局（ＢＳ））」は、Ｔ−ＮＡＬ情報を用いてパケットの重要度又はリソース予約状態を識別し、この識別された結果に基づいてパケットを送信する。
・パケットは、下位階層ネットワークエンティティーが対応するメディアデータパケットに関するメディアデータパケットの損失レベル、遅延レベル、又は優先順位レベル、又はリソース予約情報を認識することができるようにラベルの形態でＴ−ＮＡＬ情報を含む。
・ラベル情報は、下位ネットワークがパケットの重要度、優先順位、又はリソース予約状態を認識するために使用することができる。
・「ネットワークエンティティー」、すなわち、「ＭＡＮＥ」は、送信装置からパケットを受信し、クラス別ＱｏＳ方式の場合に、パケットのＩＰヘッダーに含まれている重要度情報、すなわち、ラベル値に従ってパケットを廃棄し、フロー別ＱｏＳ方式の場合に、ラベル値を確認し、ラベル値に対応する予め定められたリソースを用いてＱｏＳ（ビット率、損失率、及び遅延など）をサポートする。
　そして、「送信装置」及び「ネットワークエンティティー」で行われるパケットの送受信の処理の手順について、翻訳文等の記載から把握される処理の内容及び順序は、以下のとおりである。以下、各処理の内容について、手順ア〜手順ウと称する。
（手順ア）「送信装置」が、Ｔ−ＮＡＬ情報（ラベル情報）をヘッダーに含むパケットを生成し、生成されたパケットを、ネットワークを通して送信する。
（手順イ）「ネットワークエンティティー」が、送信装置からパケットを受信し、Ｔ−ＮＡＬ情報（ラベル情報）により、メディアデータパケットの損失レベル、遅延レベル、又は優先順位レベル、又はリソース予約情報を認識する。
（手順ウ）「ネットワークエンティティー」が、識別された結果に基づいてパケットを送信し、ラベル値に従ってパケットの廃棄やリソースを用いたＱｏＳをサポートする。
　以上によれば、構成Ｄ１１に係る処理の後に、構成Ｄ１２に係る処理を行うという処理の順序は、手順アに係る処理の後に、手順イに係る処理を行うという処理の順序と異なるといえる。
　よって、構成Ｄ１１に係る処理の後に構成Ｄ１２に係る処理を行うという処理の順序は、翻訳文等に記載されたものとはいえない。
　また、構成Ｄ１１に係る処理の後に構成Ｄ１２に係る処理を行うという処理の順序は、翻訳文等から自明であるともいえない。
　また、構成Ｄ１１は送信装置が行う処理であるが、手順イの処理は、「ネットワークエンティティー」が行う処理であって、「送信装置」が行う処理ではない。
　よって、「送信装置」が、構成Ｄ１１に係る処理を行うことも、翻訳文等に記載されたものとはいえない。
　また、「送信装置」が、構成Ｄ１１に係る処理を行うことは、翻訳文等から自明であるともいえない。
　したがって、補正事項による補正後の構成Ｄ１は、翻訳文等に記載されたものではなく、翻訳文等から自明でもないから、翻訳文等のすべての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入するものである。
　以上によれば、請求項１に係る補正は、国際出願日における国際特許出願の明細書若しくは図面（図面の中の説明に限る。）の翻訳文、国際出願日における国際特許出願の請求の範囲の翻訳文又は国際出願日における国際特許出願の図面（図面の中の説明を除く。）に記載した事項の範囲内においてしたものでないから、特許法第１７条の２第３項に規定する要件を満たしていない。
３　まとめ
　以上のとおり、本件補正は、特許法第１７条の２第３項に規定する要件に違反するものであるから、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって、上記補正の却下の決定の結論のとおり決定する。
第３　本願発明について
１　本願発明
　平成３０年１２月１３日付けの手続補正は上記のとおり却下されたので、本願の請求項に係る発明は、平成３０年３月３０日付けの手続補正により補正された特許請求の範囲の請求項１及び２に記載された事項により特定されるものであり、そのうち、請求項１に係る発明（以下、「本願発明」という。）は、上記第２の１に示した（補正前の請求項１）に記載された事項により特定されるとおりのものである。
２　当審の拒絶の理由
　平成３０年８月７日付けで当審が通知した拒絶の理由のうち、理由１及び理由２（１）は、概略、以下のとおりである。
理由１．（進歩性）この出願の請求項１及び２に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　　　　　　　　　　　　　　　　　記
引用文献１．特開２００３−２４４６７６号公報
引用文献２．特開２００２−１４１９４５号公報（周知技術を示す文献）
理由２．（サポート要件）この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。
　　　　　　　　　　　　　　　　　記
　請求項１及び請求項２には、発明の課題を解決するための手段が反映されているとはいえず、請求項１及び請求項２は、発明の詳細な説明に記載した範囲を超えて特許を請求することとなっている。
３　理由２（サポート要件）について
　事案に鑑み、理由２（サポート要件）について検討する。
（１）発明の詳細な説明の記載
　本願の発明の詳細な説明には、以下の記載がある。
ア「【技術分野】
【０００１】
　
本発明は、マルチメディアデータパケットを送信する方法及び装置に関し、特に、相互階層最適化を通してマルチメディアデータパケットを送信する方法及び装置に関する
イ「【０００３】
　
マルチメディアサービスを提供するために、ネットワークは、大きく３通りの方式、すなわち、ベストエフォート（Best Effort：ＢＥ）方式、クラス別ＱｏＳ（per class QoS）方式、及びフロー別ＱｏＳ（per flow QoS）方式でサービス品質（Quality of Service：ＱｏＳ）を保証する
【０００４】
　クラス別ＱｏＳサービスは、パケットごとに重要度を異ならせてネットワークでその重要度に従ってパケットを処理する。すなわち、パケットのＱｏＳは、対応するパケットがどんなフローに属しているかに関係なく、対応するパケットの重要度、すなわち、優先順位に従って制御される。クラス別ＱｏＳ方式をサポートするためには、送信装置と受信装置間のリソースの予約が不要である。参考までに、この優先順位は、損失優先順位（loss priority）及び遅延優先順位（delay priority）に分類することができる。
【０００５】
　フロー別ＱｏＳサービスは、ストリーム別にリソースを予約する。すなわち、フロー別にリソース（例えば、ビット率及びバッファ状態）又はＱｏＳ（例えば、遅延及び損失率など）を予約する。ここで、フローとは、１つのサービスを提供するために必要とされるストリームを意味する。例えば、ＶｏＤサービスを提供するために必要とされるビデオストリーム、オーディオストリーム、及びテキストストリームは、個別のフローである。
【０００６】
　ＩＥＥＥ  ８０２．１６（ＷｉＢＲＯ及びＷＩＭＡＸ）及びロングタームエボルーション（Long Term Evolution：ＬＴＥ）標準だけではなく、３ＧＰＰ  ＵＭＴＳ（３Ｇ）標準でもクラス別ＱｏＳ及びフロー別ＱｏＳをサポートする。しかしながら、ＱｏＳ方式を使用するためには、上位階層であるメディア階層は、下位階層であるネットワーク間のインターフェースが必要である。
【０００７】
　
従来、リアルタイム転送プロトコル（Real-time Transport Protocol：ＲＴＰ）及びリアルタイム制御プロトコル（Real-Time Control Protocol：ＲＴＣＰ）は、下位階層を考慮せず、サービス終端で累積された情報を用いてネットワークリソース又はＱｏＳを測定するように設計される。従来のＲＴＰ及びＲＴＣＰにおいて、送信を担当するネットワーク部分は、ブラックボックスとして保持されるので、あらゆる変化を正確に認識することは難しい。したがって、正確なＱｏＳ制御のためには、下位階層から直接上がってくるインターフェースを使用しなければならない
ウ「【発明の概要】
【発明が解決しようとする課題】
【００２２】
　
本発明の目的は、少なくとも上述した問題点及び／又は不都合に取り組み、少なくとも以下の便宜を提供することにある。すなわち、本発明の目的は、メディアデータ、ネットワーク状態、及びユーザーの要求に従って適応的にマルチメディアサービスを提供する方法及び装置を提供することにある
【００２３】
　
本発明の他の目的は、アプリケーション階層及び下位階層ネットワークエンティティーとの情報を交換する統合ネットワーク抽象化階層（ＮＡＬ）を提供することにある
【００２４】
　本発明のまた他の目的は、メディアデータ状態、ネットワーク状態、及びユーザーの要求状態に従ってマルチメディアサービスを提供するためにこのような状態を抽象化し、エンティティー間で抽象化された状態に関する情報を送受信する方法及び装置を提供することにある。」
エ「【課題を解決するための手段】
【００２５】
　
上記のような目的を達成するために、本発明の実施形態の一態様によれば、マルチメディアデータパケットを送信する方法は、ボトムアップネットワーク抽象化階層（Ｂ−ＮＡＬ）情報をネットワークエンティティーから受信するステップと、上記受信されたＢ−ＮＡＬ情報に基づいてメディアデータ品質を決定し、上記決定された品質を有するメディアデータを生成するステップと、上記生成されたメディアデータに対するパケットを生成し、上記パケットを送信するステップとを有することを特徴とする
オ「【００３６】
　また、
本発明は、
ネットワーク状態に関連した情報を抽象化するボトムアップ（Bottom-up）インターフェース、すなわち、Ｂ−ＮＡＬ階層とを提案する
Ｂ−ＮＡＬ階層で抽象化されたネットワーク状態情報は、Ｂ−ＮＡＬ情報と呼ばれる
カ「【００３９】
　図３は、本発明によるマルチメディアデータパケットを送信する装置及び方法を示す。送信装置３００は、サーバ又は端末であることができる。
【００４０】
　図３を参照すると、
送信装置３００は
パケット生成部３０３と
相互階層最適化（Cross Layer Optimization：ＣＬＯ）部３０２と
を含む
【００４１】
　Ｂ−ＮＡＬレジスタ３０４は、ネットワーク３１３からＢ−ＮＡＬ情報３１０を受信し記憶する。Ｂ−ＮＡＬ情報は、一般的に、ネットワークエンティティーにより生成されたネットワーク状態情報である。しかしながら、Ｂ−ＮＡＬ情報は、ユーザー端末により要求されるＱｏＳ情報又はメディアデータ制御に適合した制御情報であり得る。例えば、ユーザー端末の状態が高いＱｏＳサービスの受信に不適切である場合に、ユーザーは、低いＱｏＳパケットサービスを要求することができる。送信パケットの遅延及び損失が大きい場合に、特定のメディアは、このような情報をＢ−ＮＡＬレジスタ３０４から取得することができる。この場合に、Ｂ−ＮＡＬ情報は、ユーザーからの要求に従ってユーザー端末により生成された情報であり得る。しかしながら、説明の便宜上、下記の説明では、Ｂ−ＮＡＬ情報がネットワーク状態情報であることを仮定する。
【００４２】
　
ＣＬＯ部３０２は
Ｂ−ＮＡＬ情報に従って送信されるメディアデータの品質を適応的に決定し、この送信されるメディアデータを少なくとも１つのアクセス単位（Access Unit：ＡＵ）でメディアデータ供給部３０１に要求し（３０５）、このメディアデータをメディアデータ供給部３０５から受信する（３０６）
【００４３】
　この後に、
ＣＬＯ部３０２は、１つのＩＰパケットを通して送信されるメディアデータをパケット生成部３０３に送信する
【００４４】
　
パケット生成部３０３は、この受信されたラベル情報を含むパケットを生成し、この生成されたパケットを、ネットワーク３１３を通して送信する
（２）本願発明が解決しようとする課題について
　本願発明が解決しようとする課題及び発明の課題を解決するための手段について検討する。
　上記（１）アによれば、本発明は、マルチメディアデータパケットを送信する方法及び装置に関し、特に、相互階層最適化を通してマルチメディアデータパケットを送信する方法及び装置に関するものである。
　また、上記（１）イによれば、マルチメディアサービスを提供するために、ネットワークは、大きく３通りの方式、すなわち、ベストエフォート（Best Effort：ＢＥ）方式、クラス別ＱｏＳ（per class QoS）方式、及びフロー別ＱｏＳ（per flow QoS）方式でサービス品質（Quality of Service：ＱｏＳ）を保証することが記載されている。
　また、上記（１）イによれば、従来、リアルタイム転送プロトコル（Real-time Transport Protocol：ＲＴＰ）及びリアルタイム制御プロトコル（Real-Time Control Protocol：ＲＴＣＰ）は、下位階層を考慮せず、サービス終端で累積された情報を用いてネットワークリソース又はＱｏＳを測定するように設計されており、従来のＲＴＰ及びＲＴＣＰにおいて、送信を担当するネットワーク部分は、ブラックボックスとして保持されるので、あらゆる変化を正確に認識することは難しく、正確なＱｏＳ制御のためには、下位階層から直接上がってくるインターフェースを使用しなければならないことが記載されている。
　また、上記（１）ウによれば、本発明の目的は、少なくとも上述した問題点及び／又は不都合に取り組み、少なくとも以下の便宜を提供すること、すなわち、本発明の目的は、メディアデータ、ネットワーク状態、及びユーザーの要求に従って適応的にマルチメディアサービスを提供する方法及び装置を提供することにあり、本発明の他の目的は、アプリケーション階層及び下位階層ネットワークエンティティーとの情報を交換する統合ネットワーク抽象化階層（ＮＡＬ）を提供することにあると記載されている。
　また、上記（１）エによれば、課題を解決するための手段として、上記のような目的を達成するために、本発明の実施形態の一態様によれば、マルチメディアデータパケットを送信する方法は、ボトムアップネットワーク抽象化階層（Ｂ−ＮＡＬ）情報をネットワークエンティティーから受信するステップと、上記受信されたＢ−ＮＡＬ情報に基づいてメディアデータ品質を決定し、上記決定された品質を有するメディアデータを生成するステップと、上記生成されたメディアデータに対するパケットを生成し、上記パケットを送信するステップとを有することを特徴とすると記載されている。
　また、上記（１）オによれば、本発明は、ネットワーク状態に関連した情報を抽象化するボトムアップ（Bottom-up）インターフェース、すなわち、Ｂ−ＮＡＬ階層を提案し、Ｂ−ＮＡＬ階層で抽象化されたネットワーク状態情報は、Ｂ−ＮＡＬ情報と呼ばれることが記載されている。
　また、上記（１）カによれば、送信装置３００は、パケット生成部３０３と、相互階層最適化（Cross Layer Optimization：ＣＬＯ）部３０２とを含み、ＣＬＯ部３０２は、Ｂ−ＮＡＬ情報に従って送信されるメディアデータの品質を適応的に決定し、この送信されるメディアデータを少なくとも１つのアクセス単位（Access Unit：ＡＵ）でメディアデータ供給部３０１に要求し、このメディアデータをメディアデータ供給部３０５から受信し、ＣＬＯ部３０２は、１つのＩＰパケットを通して送信されるメディアデータをパケット生成部３０３に送信し、パケット生成部３０３は、この受信されたラベル情報を含むパケットを生成し、この生成されたパケットを、ネットワーク３１３を通して送信することが記載されている。
　以上によれば、本願発明が解決しようとする課題は、相互階層最適化を通してマルチメディアデータパケットを送信する方法及び装置において、正確なＱｏＳ制御のためには、下位階層から直接上がってくるインターフェースを使用しなければならないことを問題点とし、メディアデータ、ネットワーク状態、及びユーザーの要求に従って適応的にマルチメディアサービスを提供する方法及び装置を提供するとともに、アプリケーション階層及び下位階層ネットワークエンティティーとの情報を交換する統合ネットワーク抽象化階層（ＮＡＬ）を提供することであるといえる。
　そして、当該課題を解決するための手段は、受信されたＢ−ＮＡＬ情報に基づいてメディアデータ品質を決定し、上記決定された品質を有するメディアデータを生成することであり、具体的には、本願発明に係る送信装置はＣＬＯ部を含み、ＣＬＯ部が、Ｂ−ＮＡＬ情報に従って送信されるメディアデータの品質を適応的に決定し、この送信されるメディアデータをメディアデータ供給部から受信して、パケット生成部に送信することであるといえる。
（３）判断
　本願の請求項１に、発明の課題を解決するための手段が反映されているかどうかについて検討する。
　上記（２）のとおり、発明の課題を解決するための手段は、受信されたＢ−ＮＡＬ情報に基づいてメディアデータ品質を決定し、上記決定された品質を有するメディアデータを生成することであり、具体的には、本願発明に係る送信装置はＣＬＯ部を含み、ＣＬＯ部が、Ｂ−ＮＡＬ情報に従って送信されるメディアデータの品質を適応的に決定し、この送信されるメディアデータをメディアデータ供給部から受信して、パケット生成部に送信することである。
　一方、本願の請求項１には、Ｂ−ＮＡＬ情報に関しては、「前記下位階層から前記アプリケーション階層にネットワークチャネル状態情報を前記インターフェースを通して周期的又は非周期的なボトムアップ式情報（ボトムアップネットワーク抽象化階層（Ｂ−ＮＡＬ）情報）として提供するステップ」（構成Ｂ）が記載されるのみであり、「Ｂ−ＮＡＬ情報に基づいてメディアデータ品質を決定し、上記決定された品質を有するメディアデータを生成する」ことについては、何らの記載もない。
　そして、ネットワークチャネル状態情報をＢ−ＮＡＬ情報として提供するステップを行うのみでは、ＱｏＳ制御を行ったことにはならないから、正確なＱｏＳ制御を行ってマルチメディアサービスを提供することができないことは、当業者にとって明らかである。
　よって、本願の請求項１には、発明の課題を解決するための手段が反映されているとはいえず、本願発明は、発明の詳細な説明において発明の課題が解決できることを当業者が認識できるように記載された範囲を超えるものである。
（４）まとめ
　以上によれば、本願発明は、発明の詳細な説明において発明の課題が解決できることを当業者が認識できるように記載された範囲を超えるものであるから、発明の詳細な説明に記載されたものとはいえず、特許法第３６条第６項第１号に規定する要件を満たしていない。
４　予備的検討（理由１（進歩性）について）
　上記３のとおり、本願発明は発明の詳細な説明に記載されたものとはいえないから、本願は拒絶をすべきものであるが、仮に、本願発明が発明の詳細な説明に記載されたものであったとしても、当審は、本願発明は、特許法第２９条第２項の規定により特許を受けることができないから、本願は拒絶をすべきものと考える。
　その理由は以下のとおりである。
（１）引用文献の記載事項
ア　引用文献１
　当審の拒絶の理由に引用された引用文献１である特開２００３−２４４６７６号公報には、「動画配信システム、動画配信装置および方法、記録媒体、並びにプログラム」（発明の名称）に関し、図面とともに次に掲げる事項が記載されている。
　なお、下線は、強調のために当審で付したものである。
（ア）「【０００１】
【発明の属する技術分野】本発明は、動画配信システム、動画配信装置および方法、記録媒体、並びにプログラムに関し、特に、
異なる品質の画像を指定する複数のユーザに対して、対応する品質の画像をそれぞれ同時に配信することができるようにした
動画配信装置および方法
（イ）「【００３９】
【発明の実施の形態】図１は、本発明が適用される動画配信システム１の構成例を表している。
【００４０】なお、動画配信システム１において処理される単位は、例えば、上述したように、フレームが単位とされることも可能であるが、フィールドが単位とされることも可能である。そこで、本発明では、この単位を、アクセスユニットとも称する。
【００４１】ビデオカメラ等により構成される動画入力装置１１は、映像や音声を入力し、それらを動画のデータに変換し、動画配信装置１２に供給する。
【００４２】なお、この例においては、上述したように、映像のデータのみならず、音声のデータ等も併せて、動画データと称する。
【００４３】
動画配信装置１２は、供給された動画のデータ
階層符号化し、階層符号化されたフレームをパケット化して、それぞれの階層に対応する複数のパケットからなるパケット群を生成する
【００４４】さらに、
動画配信装置１２は、生成されたパケット群のうち、配信先（後述するユーザ端末１５ａ乃至ユーザ端末１５ｃのうちのいずれかの端末）より指定された階層に対応するパケットをネットワーク１３ａに供給する
【００４５】なお、この例においては、ネットワーク１３ａは、インターネットであるものとする。この場合、動画配信装置１２は、パケットを、ＩＰ（Internet protocol）パケットとしてネットワーク１３ａに供給する。
【００４６】ネットワーク１３ａは、このIPパケットを、IPパケットに含まれているアドレスに対応する配信先に供給する。
【００４７】即ち、
ネットワーク１３ａに供給されたIPパケットは、配信先がユーザ端末１５ａであった場合、例えば、ダイアルアップサービスを提供するサービスプロバイダのネットワーク１３ｂを介してユーザ端末１５ａに、送信先が１５ｂであった場合、例えば、ADSL(Asymmetrical Digital Subscriber Line)を使ったサービスプロバイダのネットワーク１３ｃを介してユーザ端末１５ｂに、配信先がユーザ端末１５ｃであった場合、例えば、無線ネットワークにより基地局１４を介して移動端末（携帯電話機等の端末）であるユーザ端末１５ｃに、それぞれ供給（配信）される
（ウ）「【００７３】次に、図３を参照して、動画配信装置１２の構成を説明する。
【００７４】主制御部４１は、動画配信装置１２全体の動作を制御する。
【００７５】
符号化部４２は、動画入力装置１１より供給された動画データを、主制御部４１より供給される制御パラメータ（例えば、各フレームをどのプログレッシブに基づいて階層符号化させるのかを示すパラメータ等）に基づいて、フレームを単位として階層符号化し、制御パラメータにより指定されているバッファ部４３ａまたはバッファ部４３ｂに供給する
【００７６】例えば、主制御部４１より供給された制御パラメータに、各フレームを２種類のプログレッシブ（第１および第２のプログレッシブ）に基づいて階層符号化させる旨の情報が含まれていたものとすると、符号化部４２は、フレーム毎に、第１のプログレッシブに基づいて階層符号化し、バッファ部４３ａに供給するとともに、第２のプログレッシブに基づいて階層符号化し、バッファ部４３ｂに供給する。
【００７７】即ち、バッファ部４３ａは、第１のプログレッシブに基づいて階層符号化されたフレーム専用のバッファであり、バッファ部４３ｂは、第２のプログレッシブに基づいて階層符号化されたフレーム専用のバッファである。
【００７８】従って、図３の例では、バッファの数は、バッファ部４３ａおよびバッファ部４３ｂの２つだけであるが、実際には、主制御部４２により供給される制御パラメータに含まれるプログレッシブの種類の数だけ必要となる。
【００７９】換言すると、符号化部４２は、同一のフレーム（画像）を、プログレッシブ順序を変えてそれぞれ階層符号化し、対応するプログレッシブ専用のバッファ（バッファ部４３ａおよびバッファ部４３ｂ等）にそれぞれ供給する。
【００８０】なお、符号化部４２の符号化方式は、階層符号化が可能な符号化方式であれば限定されないが、この例においては、上述したように、プログレッシッブ符号化方式の１つであるMotion JPEG2000による符号化方式（ウェーブレット変換を利用した符号化方式）であるものとする。
【００８１】
パケット化部４４は、主制御部４１の制御に基づいて、バッファ部４３ａまたはバッファ部４３ｂに記憶されているデータ（符号化部４２により階層符号化されたフレームのデータ）を解析して、プログレッシブの階層毎にデータ区切りを検出して、同一の階層毎にパケット化し、それぞれの階層に対応する複数のパケットからなるパケット群を生成する
【００８２】また、
パケット化部４４は、これらのパケットのそれぞれに、各階層に対応する識別子を表すフラグをそれぞれ付与する
【００８３】この識別子は、動画配信装置１２が放送型の配信をする場合、受信端末（図１のユーザ端末１５ａ乃至ユーザ端末１５ｃ等）が、自身の能力に必要なパケットを指定するために必要なものであり、従って、１対１で通信される場合、この識別子は、必須とされない。
【００８４】このように、
パケット化部４４は、
各階層に対応する複数のパケット（各階層に対応する識別子がそれぞれ付与された複数のパケット）からなるパケット群をそれぞれ生成し、通信部４５に供給する
【００８５】
通信部４５は、主制御部４１の制御に基づいて、供給されたパケット群のうち、主制御部４１より指示されたパケットを、ネットワーク１３ａに送信する
（エ）「【００８６】なお、必要に応じて、
パケット化部４４は、さらに、パケットをＩＰパケットにすることができる。この場合、パケット化部４４は、識別子に対応する優先度を示すフラグをＩＰパケットのヘッダにつけ直してもよい
【００８７】例えば、IP規格のバージョン４（IPv4）においては、TOS（Type Of Service）に対して優先度が示され、Diffservに対応したネットワークにおいて優先度のあるパケットの優先制御が可能となる。また、IP規格のバージョン６（IPv6）においては、フローラベルに対して優先度が示されることが可能である。
【００８８】このように、ネットワーク層で利用されるプロトコルが異なると、優先度が示される数も異なるため、符号化部４２により階層符号化される場合の階層、アプリケーションが意識されたパケットにおける優先度、およびネットワーク層における優先度はそれぞれ対応付けられて指定されることが望ましく、その指定の制御を行うのが主制御部４１である。
【００８９】この指定の制御は、あらかじめ優先度の対応付けが設定された制御であってもよいし、動的にネットワークのトラフィックや受信端末（図１のユーザ端末１５ａ乃至ユーザ端末１５ｃ等）の負荷を考慮して優先度の設定を変更する制御であってもよい。
【００９０】ネットワークのトラフィック状態を監視する方法としては、例えば、IETF（Internet Engineering Task Force）のRFC(Request For Comments)1889におけるRTCP（RTP(Real-time Transport Protocol) Control Protocol）が適用された方法が知られている。
【００９１】この方法においては、
送信側は、一定時間毎に、送出RTPパケット数やタイムスタンプ情報等の情報、いわゆる「送信レポート」を受信側にパケットとして送信し、受信側は、この「送信レポート」に基づいて、送信側にRTPパケットの紛失率、紛失パケット数、受信した最大シーケンス番号、および到着間隔ジッタ等を含む情報、いわゆる「受信レポート」を返信する
【００９２】このように、RTCPは、送信側と受信側の間のプロトコルであり、送信側と受信側の間に介在するネットワークの種類、すなわちLAN（Local Area Network）やWAN(Wide Area Network)等に関わらず機能するプロトコルである。
【００９３】そこで、この例においては、主制御部４１は、このRTCPに基づいて、ネットワークのトラフィック情報を監視し、上述した指定の制御を行うものとする。
【００９４】即ち、
通信部４５は、各受信端末（図１のユーザ端末１５ａ乃至ユーザ端末１５ｃ等）からネットワーク１３ａを介して供給されてくる受信レポートを、それぞれネットワーク監視・解析部４６に供給する
【００９５】
ネットワーク監視・解析部４６は、供給されたこれらの各受信端末に対応する受信レポートに基づいて、ネットワークの輻輳状態を判定し、さらにその判定結果に基づいて、符号化部４２の符号化のレートを下げたり、送信フレーム数を下げたりさせるための制御に必要な各受信端末毎の情報を主制御部４１へそれぞれ供給する
【００９６】
主制御部４１は、供給された各受信端末毎のこれらの情報のうち、所定の受信端末に対応する情報等に基づいて、上述したように、その所定の受信端末に対応する制御パラメータを生成し、符号化部４２に供給する
【００９７】また、主制御部４１は、供給された各受信端末毎のこれらの情報に基づいて、それぞれのプログレッシブに対応する上述した設定の制御を行う。即ち、
主制御部４１は、各プログレッシブ毎に、上述した識別子に対応したIPの優先度を設定し、パケット化部４４にそれぞれ供給し
【００９８】このように、主制御部４１は、パケット化部４４を制御して優先度を設定することで、動画配信装置１２を使用するサービス提供者が最低限保証したい品質を確保するように制御することができる。」
イ　引用文献２
　当審の拒絶の理由に引用された引用文献２である特開２００２−１４１９４５号公報には、「データ送信装置、およびデータ送信方法、並びにプログラム記憶媒体」（発明の名称）に関し、図面とともに次に掲げる事項が記載されている。
　なお、下線は、強調のために当審で付したものである。
（ア）「【０００１】
【発明の属する技術分野】本発明は、
データ送信装置
（イ）「【００５１】なお、図８で説明したＩＰヘッダはＩＰｖ４のヘッダ構成である。
ＩＰｖ６のヘッダにも優先情報格納フィールドがあり、ＩＰｖ６の優先情報は、混雑制御タイプ（congestion-controlled）と、混雑非制御タイプ（Non-congestion-controlled）とがある
混雑非制御タイプ（Non-congestion-controlled）は、リアルタイム性を要求されるサービスで利用され、８〜１５までの優先順位が設定され、優先順位の低いもの（ｅｘ．優先度８）には狭い帯域を設定し、高いもの（ｅｘ．優先度１５）には広い帯域を設定し
（２）引用文献に記載された発明及び技術
ア　引用文献１に記載された発明
　引用文献１に記載された発明を以下に認定する。
（ア）動画配信装置における配信方法について
　上記（１）ア（ア）によれば、引用文献１には、「異なる品質の画像を指定する複数のユーザに対して、対応する品質の画像をそれぞれ同時に配信する」ことができるようにした「動画配信装置および方法」が記載されている。
　また、上記（１）ア（イ）によれば、「動画配信装置１２」は、「供給された動画のデータ」を「階層符号化」し、「階層符号化されたフレームをパケット化して、それぞれの階層に対応する複数のパケットからなるパケット群を生成」し、「生成されたパケット群のうち、配信先（後述するユーザ端末１５ａ乃至ユーザ端末１５ｃのうちのいずれかの端末）より指定された階層に対応するパケットをネットワーク１３ａに供給する」ことが記載されている。
　以上によれば、引用文献１には、『供給された動画のデータを階層符号化し、階層符号化されたフレームをパケット化して、それぞれの階層に対応する複数のパケットからなるパケット群を生成し、生成されたパケット群のうち、配信先より指定された階層に対応するパケットをネットワークに供給する動画配信装置における配信方法』の発明が記載されている。
（イ）符号化部について
　上記（１）ア（ウ）によれば、「符号化部４２は、動画入力装置１１より供給された動画データを、主制御部４１より供給される制御パラメータ（例えば、各フレームをどのプログレッシブに基づいて階層符号化させるのかを示すパラメータ等）に基づいて、フレームを単位として階層符号化し、制御パラメータにより指定されているバッファ部４３ａまたはバッファ部４３ｂに供給する」と記載されている。
　以上によれば、引用文献１には、『符号化部が、動画入力装置より供給された動画データを、主制御部より供給される制御パラメータに基づいて、フレームを単位として階層符号化し、制御パラメータにより指定されているバッファ部に供給する』ことが記載されている。
（ウ）パケット化部について
　上記（１）ア（ウ）によれば、「パケット化部４４は、主制御部４１の制御に基づいて、バッファ部４３ａまたはバッファ部４３ｂに記憶されているデータ（符号化部４２により階層符号化されたフレームのデータ）を解析して、プログレッシブの階層毎にデータ区切りを検出して、同一の階層毎にパケット化し、それぞれの階層に対応する複数のパケットからなるパケット群を生成する」と記載されている。
　また、上記（１）ア（ウ）によれば、「パケット化部４４は、これらのパケットのそれぞれに、各階層に対応する識別子を表すフラグをそれぞれ付与する」と記載されている。
　また、上記（１）ア（エ）によれば、「パケット化部４４は、さらに、パケットをＩＰパケットにすることができる。この場合、パケット化部４４は、識別子に対応する優先度を示すフラグをＩＰパケットのヘッダにつけ直してもよい」と記載されている。
　また、上記（１）ア（ウ）によれば、「パケット化部４４」は、「各階層に対応する複数のパケット（各階層に対応する識別子がそれぞれ付与された複数のパケット）からなるパケット群をそれぞれ生成し、通信部４５に供給する」と記載されている。
　以上によれば、引用文献１には、『パケット化部が、主制御部の制御に基づいて、バッファ部に記憶されているデータ（符号化部により階層符号化されたフレームのデータ）を解析して、プログレッシブの階層毎にデータ区切りを検出して、同一の階層毎にパケット化し、それぞれの階層に対応する複数のパケットからなるパケット群を生成し、これらのパケットのそれぞれに、各階層に対応する識別子を表すフラグをそれぞれ付与し、さらに、パケットをＩＰパケットにし、識別子に対応する優先度を示すフラグをＩＰパケットのヘッダにつけ直し、通信部に供給する』ことが記載されている。
（エ）受信レポートについて
　上記（１）ア（エ）によれば、「通信部４５は、各受信端末（図１のユーザ端末１５ａ乃至ユーザ端末１５ｃ等）からネットワーク１３ａを介して供給されてくる受信レポートを、それぞれネットワーク監視・解析部４６に供給する」と記載されている。
　また、上記（１）ア（エ）によれば、「送信側は、一定時間毎に、送出RTPパケット数やタイムスタンプ情報等の情報、いわゆる「送信レポート」を受信側にパケットとして送信し、受信側は、この「送信レポート」に基づいて、送信側にRTPパケットの紛失率、紛失パケット数、受信した最大シーケンス番号、および到着間隔ジッタ等を含む情報、いわゆる「受信レポート」を返信する」と記載されている。
　したがって、引用文献１には、『通信部が、各受信端末からネットワークを介して供給されてくる受信レポートを、それぞれネットワーク監視・解析部に供給し、ここで、受信レポートは、送信側が、一定時間毎に、送出RTPパケット数やタイムスタンプ情報等の情報、いわゆる「送信レポート」を受信側にパケットとして送信し、受信側が、この「送信レポート」に基づいて、送信側にRTPパケットの紛失率、紛失パケット数、受信した最大シーケンス番号、および到着間隔ジッタ等を含む情報、いわゆる「受信レポート」を返信することにより得られるものである』ことが記載されている。
（オ）ネットワーク監視・解析部について
　上記（１）ア（エ）によれば、「ネットワーク監視・解析部４６は、供給されたこれらの各受信端末に対応する受信レポートに基づいて、ネットワークの輻輳状態を判定し、さらにその判定結果に基づいて、符号化部４２の符号化のレートを下げたり、送信フレーム数を下げたりさせるための制御に必要な各受信端末毎の情報を主制御部４１へそれぞれ供給する」と記載されている。
　以上によれば、引用文献１には、『ネットワーク監視・解析部が、供給されたこれらの各受信端末に対応する受信レポートに基づいて、ネットワークの輻輳状態を判定し、さらにその判定結果に基づいて、符号化部の符号化のレートを下げたり、送信フレーム数を下げたりさせるための制御に必要な各受信端末毎の情報を主制御部へそれぞれ供給する』ことが記載されている。
（カ）主制御部について
　上記（１）ア（エ）によれば、「主制御部４１は、供給された各受信端末毎のこれらの情報のうち、所定の受信端末に対応する情報等に基づいて、上述したように、その所定の受信端末に対応する制御パラメータを生成し、符号化部４２に供給する」と記載されている。
　また、　上記（１）ア（エ）によれば、「主制御部４１は、各プログレッシブ毎に、上述した識別子に対応したIPの優先度を設定し、パケット化部４４にそれぞれ供給」することが記載されている。
　以上によれば、引用文献１には、『主制御部が、供給された各受信端末毎のこれらの情報のうち、所定の受信端末に対応する情報等に基づいて、その所定の受信端末に対応する制御パラメータを生成し、符号化部に供給するとともに、各プログレッシブ毎に、上述した識別子に対応したIPの優先度を設定し、パケット化部にそれぞれ供給する』ことが記載されている。
（キ）通信部ついて
　上記（１）ア（ウ）によれば、「通信部４５は、主制御部４１の制御に基づいて、供給されたパケット群のうち、主制御部４１より指示されたパケットを、ネットワーク１３ａに送信する」と記載されている。
　以上によれば、『通信部が、主制御部の制御に基づいて、供給されたパケット群のうち、主制御部より指示されたパケットを、ネットワークに送信する』ことが記載されている。
（ク）IPパケットの供給について
　上記（１）ア（イ）によれば、「ネットワーク１３ａに供給されたIPパケットは、配信先がユーザ端末１５ａであった場合、例えば、ダイアルアップサービスを提供するサービスプロバイダのネットワーク１３ｂを介してユーザ端末１５ａに、送信先が１５ｂであった場合、例えば、ADSL(Asymmetrical Digital Subscriber Line)を使ったサービスプロバイダのネットワーク１３ｃを介してユーザ端末１５ｂに、配信先がユーザ端末１５ｃであった場合、例えば、無線ネットワークにより基地局１４を介して移動端末（携帯電話機等の端末）であるユーザ端末１５ｃに、それぞれ供給（配信）される」と記載されている。
　以上によれば、引用文献１には、『ネットワークに供給されたIPパケットは、配信先がユーザ端末１５ａであった場合、例えば、ダイアルアップサービスを提供するサービスプロバイダのネットワークを介してユーザ端末１５ａに、送信先が１５ｂであった場合、例えば、ADSL(Asymmetrical Digital Subscriber Line)を使ったサービスプロバイダのネットワークを介してユーザ端末１５ｂに、配信先がユーザ端末１５ｃであった場合、例えば、無線ネットワークにより基地局を介して移動端末（携帯電話機等の端末）であるユーザ端末１５ｃに、それぞれ供給（配信）される』ことが記載されている。
（ケ）まとめ
　以上より、引用文献１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。引用発明の各構成については、以下、構成ａ〜構成ｈと称する。
（引用発明）
（ａ）供給された動画のデータを階層符号化し、階層符号化されたフレームをパケット化して、それぞれの階層に対応する複数のパケットからなるパケット群を生成し、生成されたパケット群のうち、配信先より指定された階層に対応するパケットをネットワークに供給する動画配信装置における配信方法であって、
（ｂ）符号化部が、動画入力装置より供給された動画データを、主制御部より供給される制御パラメータに基づいて、フレームを単位として階層符号化し、制御パラメータにより指定されているバッファ部に供給し、
（ｃ）パケット化部が、主制御部の制御に基づいて、バッファ部に記憶されているデータ（符号化部により階層符号化されたフレームのデータ）を解析して、プログレッシブの階層毎にデータ区切りを検出して、同一の階層毎にパケット化し、それぞれの階層に対応する複数のパケットからなるパケット群を生成し、これらのパケットのそれぞれに、各階層に対応する識別子を表すフラグをそれぞれ付与し、さらに、パケットをＩＰパケットにし、識別子に対応する優先度を示すフラグをＩＰパケットのヘッダにつけ直し、通信部に供給し、
（ｄ）通信部が、各受信端末からネットワークを介して供給されてくる受信レポートを、それぞれネットワーク監視・解析部に供給し、ここで、受信レポートは、送信側が、一定時間毎に、送出RTPパケット数やタイムスタンプ情報等の情報、いわゆる「送信レポート」を受信側にパケットとして送信し、受信側が、この「送信レポート」に基づいて、送信側にRTPパケットの紛失率、紛失パケット数、受信した最大シーケンス番号、および到着間隔ジッタ等を含む情報、いわゆる「受信レポート」を返信することにより得られるものであり、
（ｅ）ネットワーク監視・解析部が、供給されたこれらの各受信端末に対応する受信レポートに基づいて、ネットワークの輻輳状態を判定し、さらにその判定結果に基づいて、符号化部の符号化のレートを下げたり、送信フレーム数を下げたりさせるための制御に必要な各受信端末毎の情報を主制御部へそれぞれ供給し、
（ｆ）主制御部が、供給された各受信端末毎のこれらの情報のうち、所定の受信端末に対応する情報等に基づいて、その所定の受信端末に対応する制御パラメータを生成し、符号化部に供給するとともに、各プログレッシブ毎に、上述した識別子に対応したIPの優先度を設定し、パケット化部にそれぞれ供給し、
（ｇ）通信部が、主制御部の制御に基づいて、供給されたパケット群のうち、主制御部より指示されたパケットを、ネットワークに送信し、
（ｈ）ネットワークに供給されたIPパケットは、配信先がユーザ端末１５ａであった場合、例えば、ダイアルアップサービスを提供するサービスプロバイダのネットワークを介してユーザ端末１５ａに、送信先が１５ｂであった場合、例えば、ADSL(Asymmetrical Digital Subscriber Line)を使ったサービスプロバイダのネットワークを介してユーザ端末１５ｂに、配信先がユーザ端末１５ｃであった場合、例えば、無線ネットワークにより基地局を介して移動端末（携帯電話機等の端末）であるユーザ端末１５ｃに、それぞれ供給（配信）される
（ａ）配信方法。
イ　引用文献２に記載された技術
　上記（１）イ（ア）、（イ）によれば、引用文献２には、以下の技術（以下、「文献２技術」という。）が記載されていると認められる。
（文献２技術）
「データ送信装置において、ＩＰｖ６のヘッダに優先情報格納フィールドがあり、ＩＰｖ６の優先情報は、混雑制御タイプ（congestion-controlled）と、混雑非制御タイプ（Non-congestion-controlled）とがあり、混雑非制御タイプ（Non-congestion-controlled）は、リアルタイム性を要求されるサービスで利用され、８〜１５までの優先順位が設定され、優先順位の低いもの（ｅｘ．優先度８）には狭い帯域を設定し、高いもの（ｅｘ．優先度１５）には広い帯域を設定する技術。」
（３）対比
　本願発明と、引用発明を対比する。
ア　構成Ａについて
　引用発明の「符号化部」（構成ｂ）、「パケット化部」（構成ｃ）、「ネットワーク監視・解析部」（構成ｅ）、「主制御部」（構成ｆ）は、動画のデータの符号化に関する処理を行うものであり、動画のデータの符号化に関する処理はアプリケーションといえるから、これらの構成は、「アプリケーション階層」といえる。
　また、引用発明の「通信部」（構成ｄ、構成ｇ）は、パケットの送信に関する処理を行うものであり、当該パケットの送信に関する処理は、上述した「アプリケーション階層」における処理よりも下位の階層の処理といえるから、「通信部」は、「下位階層」といえる。
　また、構成ａの「動画配信装置」は、以上の構成を含むものであり、「一つのエンティティー」といえる。
　また、引用発明では、「通信部」が「受信レポート」を「ネットワーク監視・解析部」に供給し（構成ｄ）、「パケット化部」が「優先度を示すフラグ」をヘッダにつけた「パケット」を「通信部」に供給する（構成ｃ）から、「下位階層」に相当する「通信部」と、「アプリケーション階層」に相当する「ネットワーク監視・解析部」及び「パケット化部」の間には、両者を接続する「インターフェース」が存在しているといえ、引用発明は、「下位階層とアプリケーション階層を接続するインターフェース」に基づくものといえる。
　また、引用発明は、「供給された動画のデータを階層符号化し、階層符号化されたフレームをパケット化して、それぞれの階層に対応する複数のパケットからなるパケット群を生成し、生成されたパケット群のうち、配信先より指定された階層に対応するパケットをネットワークに供給する」（構成ａ）から、「マルチメディアデータを送信する」ものといえる。
　よって、本願発明と引用発明は、「下位階層とアプリケーション階層を含む一つのエンティティーで前記下位階層と前記アプリケーション階層を接続するインターフェースに基づいて、マルチメディアデータを送信する方法」である点で共通する。
イ　構成Ｂについて
　引用発明の構成ｄの「受信レポート」は、「RTPパケットの紛失率、紛失パケット数、受信した最大シーケンス番号、および到着間隔ジッタ等を含む情報」（構成ｄ）であり、構成ｅの「ネットワーク監視・解析部」は、「各受信端末に対応する受信レポートに基づいて、ネットワークの輻輳状態を判定」する（構成ｅ）から、「受信レポート」は「ネットワークチャネル状態情報」といえる。
　また、引用発明は、構成ｄの「通信部」が、「受信レポート」を「ネットワーク監視・解析部」に供給する（構成ｄ）ものである。
　また、上記アのとおり、「通信部」は「下位階層」といえ、「ネットワーク監視・解析部」は「アプリケーション階層」といえ、「通信部」と「ネットワーク監視・解析部」の間には、「インターフェース」が存在しているといえる。
　また、「下位階層」である「通信部」から、「アプリケーション階層」である「ネットワーク監視・解析部」に情報を供給することは、情報の伝達方向を考慮すると、「ボトムアップ式情報として提供する」ことといえる。
　よって、引用発明は、「前記下位階層」から「前記アプリケーション階層」に「ネットワークチャネル状態情報」を「前記インターフェース」を通して「ボトムアップ式情報」として提供するといえる。
　また、引用発明の構成ｄの「受信レポート」は、「送信側が、一定時間毎に、送出RTPパケット数やタイムスタンプ情報等の情報、いわゆる「送信レポート」を受信側にパケットとして送信し、受信側が、この「送信レポート」に基づいて、送信側にRTPパケットの紛失率、紛失パケット数、受信した最大シーケンス番号、および到着間隔ジッタ等を含む情報、いわゆる「受信レポート」を返信することにより得られる」（構成ｄ）から、「周期的又は非周期的」な情報といえる。
　よって、本願発明と引用発明は、「前記下位階層から前記アプリケーション階層にネットワークチャネル状態情報を前記インターフェースを通して周期的又は非周期的なボトムアップ式情報として提供するステップ」を含む点で共通する。
　ただし、「ボトムアップ式情報」が、本願発明では、「（ボトムアップネットワーク抽象化階層（Ｂ−ＮＡＬ）情報）」であるのに対し、引用発明では、そうであるか不明な点で、両発明は相違する。
ウ　構成Ｃについて
　引用発明の構成ｃの「優先度を示すフラグ」は、「階層符号化されたフレームのデータ」の「各階層に対応する識別子」に対応したものであり、「階層符号化されたフレームのデータ」の「階層」は、メディアの特性を表し、メディアのデータに関連したものといえるから、「優先度を示すフラグ」は、「メディア特性に対する情報(メディアデータに関連する情報)」であるといえる。
　また、引用発明の構成ｃの「パケット化部」は、「優先度を示すフラグ」をヘッダにつけた「パケット」を「通信部」に供給する（構成ｃ）ものである。
　また、上記アのとおり、「パケット化部」は、「アプリケーション階層」といえ、「通信部」は「下位階層」といえ、「パケット化部」と「通信部」の間には、「インターフェース」が存在しているといえる。
　また、「アプリケーション階層」である「パケット化部」から、「下位階層」である「通信部」に情報を供給することは、情報の伝達方向を考慮すると、「トップダウン式情報として提供する」ことといえる。
　したがって、引用発明は、「前記アプリケーション階層から前記下位階層にメディア特性に対する情報(メディアデータに関連する情報)を前記インターフェースを通してトップダウン式情報として提供する」といえる。
　よって、本願発明と引用発明は、「前記アプリケーション階層から前記下位階層にメディア特性に対する情報(メディアデータに関連する情報)を前記インターフェースを通してトップダウン式情報として提供するステップ」を含む点で一致する。
エ　構成Ｄについて
　引用発明の構成ｃの「パケット化部」は、「階層符号化されたフレームのデータ」を「パケット」とし、「優先度を示すフラグ」をヘッダにつけた「パケット」を「通信部」に供給し（構成ｃ）、構成ｇの「通信部」は、「供給されたパケット群のうち、主制御部より指示されたパケットを、ネットワークに送信」する（構成ｇ）ものであり、「階層符号化されたフレームのデータ」の「パケット」は「マルチメディアデータ」といえる。
　また、上記ウのとおり、構成ｃの「優先度を示すフラグ」は、「前記下位階層から前記トップダウン式情報として提供される前記メディア特性に対する情報」といえる。
　したがって、構成ｇの「通信部」は、「前記下位階層から前記トップダウン式情報として提供される前記メディア特性に対する情報に基づいてマルチメディアデータを送信する」といえる。
　よって、本願発明と引用発明は、「前記下位階層から前記トップダウン式情報として提供される前記メディア特性に対する情報に基づいてマルチメディアデータを送信するステップ」を含む点で一致する。
オ　構成Ｅについて
　引用発明の構成ｃの「優先度を示すフラグ」は、「階層符号化されたフレームのデータ」の「各階層に対応する識別子」に対応したものである。
　そして、「階層符号化されたフレームのデータ」の「各階層」は、それぞれの「品質」を有するものであることは明らかであり、構成ｃの「優先度を示すフラグ」により「階層符号化されたフレームのデータ」の「階層」を識別できるのであるから、構成ｃの「優先度を示すフラグ」は、「下位階層でサポートするサービス品質を識別するために使用されるレベル情報」といえる。
　また、上記ウのとおり、構成ｃの「優先度を示すフラグ」は、「前記トップダウン式情報として提供される前記メディア特性に対する情報」といえる。
　よって、本願発明と引用発明は、「前記トップダウン式情報として提供される前記メディア特性に対する情報は、前記下位階層でサポートするサービス品質を識別するために使用されるレベル情報を含む」点で共通する。
　ただし、「レベル情報」が、本願発明では、「リソース割り当て又は前記下位階層でサポートするサービス品質を識別するために使用される」のに対し、引用発明では、「前記下位階層でサポートするサービス品質を識別するために使用される」ものの、「リソース割り当て」には使用されない点で、両発明は相違する。
カ　構成Ｆについて
　引用発明では、「ネットワークに供給されたIPパケット」は、「ダイアルアップサービスを提供するサービスプロバイダのネットワーク」を介した「ユーザ端末１５ａ」や、「ADSL(Asymmetrical Digital Subscriber Line)を使ったサービスプロバイダのネットワーク」介した「ユーザ端末１５ｂ」、「無線ネットワークにより基地局」を介した「移動端末（携帯電話機等の端末）であるユーザ端末１５ｃ」にそれぞれ供給される（構成ｈ）から、引用発明は、「異種ネットワーク環境」で用いられるものといえる。
　そして、上記イのとおり、構成ｄの「受信レポート」は、「前記ボトムアップ式情報として提供される前記ネットワークチャネル状態情報」といえるから、引用発明では、「前記ボトムアップ式情報として提供される前記ネットワークチャネル状態情報は、異種ネットワーク環境で獲得した情報である」といえる。
　よって、本願発明と引用発明は、「前記ボトムアップ式情報として提供される前記ネットワークチャネル状態情報は、異種ネットワーク環境で獲得した情報である」点で一致する。
キ　まとめ
　以上によれば、本願発明と引用発明の一致点及び相違点は、以下のとおりである。
［一致点］
（Ａ）下位階層とアプリケーション階層を含む一つのエンティティーで前記下位階層と前記アプリケーション階層を接続するインターフェースに基づいて、マルチメディアデータを送信する方法であって、
（Ｂ’）前記下位階層から前記アプリケーション階層にネットワークチャネル状態情報を前記インターフェースを通して周期的又は非周期的なボトムアップ式情報として提供するステップと、
（Ｃ）前記アプリケーション階層から前記下位階層にメディア特性に対する情報(メディアデータに関連する情報)を前記インターフェースを通してトップダウン式情報として提供するステップと、
（Ｄ）前記下位階層から前記トップダウン式情報として提供される前記メディア特性に対する情報に基づいてマルチメディアデータを送信するステップとを含み、
（Ｅ’）前記トップダウン式情報として提供される前記メディア特性に対する情報は、前記下位階層でサポートするサービス品質を識別するために使用されるレベル情報を含み、
（Ｆ）前記ボトムアップ式情報として提供される前記ネットワークチャネル状態情報は、異種ネットワーク環境で獲得した情報である
（Ａ）ことを特徴とする方法。
［相違点］
（相違点１）
　「ボトムアップ式情報」が、本願発明では、「（ボトムアップネットワーク抽象化階層（Ｂ−ＮＡＬ）情報）」（構成Ｂ）であるのに対し、引用発明では、そうであるか不明な点。
（相違点２）
　「レベル情報」が、本願発明では、「リソース割り当て又は前記下位階層でサポートするサービス品質を識別するために使用される」（構成Ｅ）のに対し、引用発明では、「前記下位階層でサポートするサービス品質を識別するために使用される」ものの、「リソース割り当て」には使用されない点。
（４）判断
ア　相違点１について
　周知の動画像符号化規格であるＨ．２６４／ＡＶＣに見られるように、動画データの符号化を処理するビデオ符号化階層と符号化された情報の伝送及び格納を行う下位階層との間で、ネットワーク抽象化階層（ＮＡＬ）を定義して用いることは、当業者が普通に行う事項である。
　してみれば、下位階層からアプリケーション階層へと伝送する情報を、伝送の方向も考慮して、ボトムアップネットワーク抽象化階層（Ｂ−ＮＡＬ）情報として扱うことに、当業者が困難を要するものとは認められない。
イ　相違点２について
　上記（２）イのとおり、引用文献２に文献２技術が記載されているように、データ送信装置における優先順位の低いものには狭い帯域を設定し、高いものには広い帯域を設定する技術において、ＩＰのヘッダの優先情報（すなわち、レベル情報）を、リソース割り当てに使用することは周知技術である。
　したがって、引用発明に当該周知技術を採用して、引用発明の「レベル情報」を「リソース割り当て」にも使用することは、当業者が容易に想到し得ることである。
（５）効果等について
　本願発明の構成は、上記のとおり当業者が容易に想到できたものであるところ、本願発明が奏する効果は、その容易想到である構成から当業者が容易に予測し得る範囲内のものであり、同範囲を超える顕著なものではない。
（６）まとめ
　以上のように、本願発明は、引用文献１に記載された発明及び周知技術に基いて当業者が容易に発明をすることができたものである。
第４　むすび
　以上のとおり、本願の請求項１に係る発明は、発明の詳細な説明に記載したものでないから、本願は、特許法第３６条第６項第１号に規定する要件を満たしておらず、特許を受けることができない。
　また、仮に、本願の請求項１に係る発明が発明の詳細な説明に記載したものであったとしても、本願発明は、引用文献１に記載された発明及び周知技術に基いて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、その余の請求項について検討するまでもなく、拒絶をすべきものである。
　よって、結論のとおり審決する。