• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04N
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) H04N
審判 査定不服 原文新規事項追加の補正 特許、登録しない(前置又は当審拒絶理由) H04N
管理番号 1353084
審判番号 不服2016-16558  
総通号数 236 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-08-30 
種別 拒絶査定不服の審決 
審判請求日 2016-11-04 
確定日 2019-07-02 
事件の表示 特願2013-550406「相互階層最適化を用いた、マルチメディアデータパケットを送信する方法及び装置」拒絶査定不服審判事件〔平成24年 7月26日国際公開、WO2012/099417、平成26年 4月10日国内公表、特表2014-509113〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、2012年(平成24年)1月19日(パリ条約による優先権主張外国庁受理2011年1月19日、韓国)を国際出願日とする出願であって、その手続の経緯は以下のとおりである。

平成27年10月 8日付け:拒絶理由通知
平成28年 1月19日 :意見書、手続補正書の提出
平成28年 6月30日付け:拒絶査定
平成28年11月 4日 :審判請求書、手続補正書の提出
平成29年10月26日付け:拒絶理由通知(当審)
平成30年 3月30日 :意見書、手続補正書の提出
平成30年 8月 7日付け:拒絶理由通知(当審)(最後)
平成30年12月13日 :意見書、手続補正書の提出

第2 平成30年12月13日付けの手続補正についての補正の却下の決定
[補正の却下の決定の結論]
平成30年12月13日付けの手続補正を却下する。

[理由]
1 本件補正の内容
平成30年12月13日付けの手続補正(以下、「本件補正」という。)は、平成30年3月30日付けの手続補正により補正された特許請求の範囲の請求項1及び2を、本件補正による特許請求の範囲の請求項1及び2に補正するものであり、そのうち、請求項1に係る手続補正は以下のとおりである(下線は補正箇所を示す。)。
なお、請求項中の各構成の符号は、説明のために当審において付与したものであり、以下、補正前の請求項1については構成A?構成Fと称し、補正後の請求項1については構成A1?構成G1と称する。

(補正前の請求項1)
【請求項1】
(A)下位階層とアプリケーション階層を含む一つのエンティティーで前記下位階層と前記アプリケーション階層を接続するインターフェースに基づいて、マルチメディアデータを送信する方法であって、
(B)前記下位階層から前記アプリケーション階層にネットワークチャネル状態情報を前記インターフェースを通して周期的又は非周期的なボトムアップ式情報(ボトムアップネットワーク抽象化階層(B-NAL)情報)として提供するステップと、
(C)前記アプリケーション階層から前記下位階層にメディア特性に対する情報(メディアデータに関連する情報)を前記インターフェースを通してトップダウン式情報として提供するステップと、
(D)前記下位階層から前記トップダウン式情報として提供される前記メディア特性に対する情報に基づいてマルチメディアデータを送信するステップとを含み、
(E)前記トップダウン式情報として提供される前記メディア特性に対する情報は、リソース割り当て又は前記下位階層でサポートするサービス品質を識別するために使用されるレベル情報を含み、
(F)前記ボトムアップ式情報として提供される前記ネットワークチャネル状態情報は、異種ネットワーク環境で獲得した情報である
(A)ことを特徴とする方法。

(補正後の請求項1)
【請求項1】
(A1)下位階層とアプリケーション階層を含む送信装置で前記下位階層と前記アプリケーション階層を接続するインターフェースに基づいて、メディアデータを送信する方法であって、
(B1)前記下位階層から前記アプリケーション階層にユーザの要請サービス品質と、ネットワークチャネル状態情報を前記インターフェースを通して周期的又は非周期的なボトムアップ式情報(ボトムアップネットワーク抽象化階層(B-NAL)情報)として提供するステップと、
(G1)前記アプリケーション階層で前記下位階層から前記ボトムアップ式情報として提供を受けた前記ユーザの要請サービス品質と前記ネットワークチャネル状態情報に基づいて、メディアデータのサービス品質を決定し、前記決定されたメディアデータのサービス品質に関する情報を含むメディアデータに関連した情報を生成するステップと、
(C1)前記アプリケーション階層から前記下位階層に前記生成されたメディアデータに関連する情報を前記インターフェースを通してトップダウン式情報(トップダウンネットワーク抽象化階層(T-NAL)情報)として提供するステップと、
(D1)(D11)前記下位階層で前記アプリケーション階層から前記トップダウン式情報として提供を受けた前記メディアデータに関連した情報に含まれたレベル情報により、パケットの損失重要度及び遅延重要度、優先順位またはリソース予約状態を認識し、
(D12)前記認識したパケットの損失重要度及び遅延重要度、優先順位またはリソース予約状態を考慮して選択されたメディアデータにより、前記レベル情報をヘッダーに含むパケットを生成し、
(D13)前記生成したパケットを送信するステップとを含み、
(F1)前記ボトムアップ式情報として提供される前記ネットワークチャネル状態情報は、使用可能なビット率 、リアルタイム転送プロトコル(Real-time Transport Protocol:RTP)の結果として測定されたパケット損失率、遅延またはジッターに関する情報を含む
(A1)ことを特徴とする方法。

2 補正の適合性
(1)補正事項
請求項1に係る手続補正は、補正前の構成Dの「前記下位階層から前記トップダウン式情報として提供される前記メディア特性に対する情報に基づいてマルチメディアデータを送信するステップ」という記載を、補正後の構成D1の「前記下位階層で前記アプリケーション階層から前記トップダウン式情報として提供を受けた前記メディアデータに関連した情報に含まれたレベル情報により、パケットの損失重要度及び遅延重要度、優先順位またはリソース予約状態を認識し、前記認識したパケットの損失重要度及び遅延重要度、優先順位またはリソース予約状態を考慮して選択されたメディアデータにより、前記レベル情報をヘッダーに含むパケットを生成し、前記生成したパケットを送信するステップ」という記載とする補正(以下、「補正事項」という。)を含むものである。

ここで、本件補正後の請求項1に係る発明は、「下位階層とアプリケーション階層を含む送信装置で前記下位階層と前記アプリケーション階層を接続するインターフェースに基づいて、メディアデータを送信する方法」(構成A1)であるから、構成D1のステップは、「送信装置」で行われるステップといえる。

また、構成D1に係る記載は、構成D11?構成D13の順序で記載されており、加えて、構成D12は、構成D11で認識した「パケットの損失重要度及び遅延重要度、優先順位またはリソース予約状態」を考慮して選択されたメディアデータにより、パケットを生成するものであり、構成D13は構成D12で生成したパケットを送信するものであるから、構成D1は、構成D11、構成D12、構成D13の順序で処理を行うと解される。

(2)翻訳文等に記載された事項
本願の国際出願日における国際特許出願の明細書若しくは図面(図面の中の説明に限る。)の翻訳文、国際出願日における国際特許出願の請求の範囲の翻訳文又は国際出願日における国際特許出願の図面(図面の中の説明を除く。)(以下、「翻訳文等」という。)には、以下の記載がある。
なお、下線は、強調のために当審で付したものである。

ア「【0037】
一方、送信装置(例えば、サーバ又は端末)は、T-NAL情報を生成し、T-NAL情報をパケットのヘッダーに含んで送信する。ネットワークエンティティー(例えば、ルータ又は基地局(BS))は、T-NAL情報を用いてパケットの重要度又はリソース予約状態を識別し、したがって、この識別された結果に基づいてパケットを送信することができる。また、ネットワークエンティティーは、B-NAL情報を生成することができる。送信装置は、B-NAL情報に基づいて現在のネットワーク状態に従って適応的にパケットを送信することができる。」

イ「【0039】
図3は、本発明によるマルチメディアデータパケットを送信する装置及び方法を示す。送信装置300は、サーバ又は端末であることができる。
【0040】
図3を参照すると、送信装置300は、メディアデータ供給部301と、パケット生成部303と、本発明に特有な構成、すなわち、相互階層最適化(Cross Layer Optimization:CLO)部302と、B-NALレジスタ304とを含む。
【0041】
B-NALレジスタ304は、ネットワーク313からB-NAL情報310を受信し記憶する。B-NAL情報は、一般的に、ネットワークエンティティーにより生成されたネットワーク状態情報である。しかしながら、B-NAL情報は、ユーザー端末により要求されるQｏS情報又はメディアデータ制御に適合した制御情報であり得る。例えば、ユーザー端末の状態が高いQｏSサービスの受信に不適切である場合に、ユーザーは、低いQｏSパケットサービスを要求することができる。送信パケットの遅延及び損失が大きい場合に、特定のメディアは、このような情報をB-NALレジスタ304から取得することができる。この場合に、B-NAL情報は、ユーザーからの要求に従ってユーザー端末により生成された情報であり得る。しかしながら、説明の便宜上、下記の説明では、B-NAL情報がネットワーク状態情報であることを仮定する。
【0042】
CLO部302は、B-NALレジスタ304からB-NAL情報を読み出すか又は受信されたB-NALパケットから読み出し、B-NAL情報に従って送信されるメディアデータの品質を適応的に決定し、この送信されるメディアデータを少なくとも1つのアクセス単位(Access Unit:AU)でメディアデータ供給部301に要求し(305)、このメディアデータをメディアデータ供給部305から受信する(306)。
【0043】
この後に、CLO部302は、1つのIPパケットを通して送信されるメディアデータをパケット生成部303に送信する(309)。この時に、CLO部302は、対応するメディアデータに関するT-NAL情報、すなわち、ラベル情報を生成し、このラベル情報をパケット生成部303に送信する(308)。上述したように、このラベル情報は、下位ネットワークがパケットの重要度、優先順位、又はリソース予約状態を認識するために使用することができる。
【0044】
パケット生成部303は、この受信されたラベル情報を含むパケットを生成し、この生成されたパケットを、ネットワーク313を通して送信する(311)。このラベル情報は、IPパケットのヘッダー又は他の下位プロトコルのパケットヘッダーに含めることができる。」

ウ「【0049】
パケットは、下位階層ネットワークエンティティーが対応するメディアデータパケットに関するメディアデータパケットの損失レベル、遅延レベル、又は優先順位レベル、又はリソース予約情報を認識することができるようにラベルの形態でT-NAL情報を含む。一方、本発明のT-NAL情報フォーマットは、既存の他のプロトコル標準、例えば、IPヘッダープロトコル、TCP及びUDPヘッダープロトコル、及びRTPヘッダープロトコルと両立するように使用することができる。T-NAL情報を用いてメディアサービスを提供するためには、送信側ネットワークと受信側ネットワーク間の呼設定過程が必要である。すなわち、この呼設定過程を通して各ネットワークエンティティーは、ラベル値が意味することを約束することができる。」

エ「【0076】
以上、本発明により定義されたT-NAL情報及びB-NAL情報について説明した。CLOは、T-NAL情報及びB-NAL情報を使用して可能である。相互階層最適化は、ネットワーク状態を認識してビデオ符号化を実行し(network-aware video coding)、メディアストリームに関する情報、すなわち、メディアストリームの重要度又は優先順位などを認識して動作するメディアネットワークエンティティーによりメディアデータサービスを提供することを意味する。このメディアストリームに関する情報に基づいてサービスするエンティティーをメディア認識ネットワークエレメント(Media Aware Network Element:MANE)と呼ぶ。下記では、“MANE”という用語を使用して説明する。
【0077】
以下では、本発明のネットワークエンティティー、すなわち、MANEの動作について説明する。
【0078】
ルータ、IEEE802シリーズのMAC階層、及び3GPP BMSCのように受信されたメディアパケットをフォーワーディング(fowading)するネットワークエンティティーは、T-NAL情報のラベル情報から決定されたパケットの重要度に従ってパケットを適応的にフォーワーディングするMANEとして動作することができる。例えば、diffSeｒｖルーティング方式を使用するルータは、データがバッファを超過する場合に、優先順位がもっとも低いパケットから廃棄する。このために、ルータは、T-NALのラベル値を確認する。
【0079】
クラス別QｏS方式の場合に、受信されたパケットがどんなサービスに属しているパケットであるかと無関係に、パケットのIPヘッダーに含まれている重要度情報、すなわち、ラベル値に従って適応的に処理される。例えば、ラベル値11を有するオーディオパケット、ラベル値10を有する基本階層ビデオパケット、ラベル値01を有する向上1階層ビデオパケット、及びラベル値00を有する向上2階層ビデオパケットが受信され、ネットワーク状態又はルータバッファの容量を超過するデータ量によりパケットのうちのいずれか1つが廃棄されるべき場合に、ラベル値に従ってパケットを廃棄する。すなわち、向上2階層ビデオパケット、向上1階層ビデオパケット、基本階層ビデオパケット、及びオーディオパケットの順序にパケットを廃棄する。IEEE802.11e標準において、パケットのIPヘッダーに含まれている重要度情報に従って予め定められたキュー(Queue)にパケットを挿入する。一般的に、パケットは、4つのステップで優先順位が設定され、各キューは、キューを通過するパケットの速度及びパケット損失処理方法の観点で異なることがある。
【0080】
フロー別QｏS方式の場合に、ラベル値を確認し、ラベル値に対応する予め定められたリソースを用いてQｏS(ビット率、損失率、及び遅延など)をサポートする。このラベルに対応するリソースは、対応するネットワークエンティティーにストリーム別に予め保存されたリソース予約テーブルを参照して決定することができる。例えば、IEEE802.16において、オーディオストリームに対するQｏSクラスがUGS(Unsolicited Guaranteed Service)である場合に、QｏSクラスに対して予め定められたQｏS要件を保証する。したがって、このリソース予約テーブルは、対応するサービスが終了するまでネットワークエンティティーに保存される。すなわち、送信装置からパケットが受信される場合に、対応するパケットのラベルを確認し、ラベルに対応するストリームのQｏS要件をリソース予約テーブルから検索する。このようなサービスは、QｏS要件に従うリソースを用いて提供される。
【0081】
図7は、本発明の実施形態によるMANEの動作の一例を示す。
【0082】
図7を参照すると、MANE701は、リソース予約テーブル702と、フォーワーディングポリシー決定部711と、使用可能なリソース判定部708とを含む。
【0083】
送信装置からパケットを受信する場合(706)に、フォーワーディングポリシー決定部709は、フォーワーディングポリシーに従ってパケットを適応的にフォーワーディングする。このフォーワーディングポリシーは、受信されたパケットのT-NAL情報に含まれているラベル値に基づいて変わる。
【0084】
MANE701がクラス別QｏSをサポートする場合に、フォーワーディングポリシー決定部710は、対応するパケットのクラスを確認した後に、このパケットのクラスに従って対応するパケットをフォーワーディングするか否かを決定する。一方、MANE701がストリーム別QｏSをサポートする場合に、フォーワーディングポリシー決定部710は、このパケットのラベル値を確認し、リソース予約テーブル702内の対応するラベルに割り当てられたリソースを確認し(705及び711)、使用可能なリソース判定部704から使用可能なリソース情報を受信し(707)、使用可能なリソース内のパケットに対するフォーワーディングポリシーを決定した後に、このフォーワーディングポリシーに従ってこのパケットをフォーワーディングする(710)。」

(3)新規事項について
補正事項について、請求人は、平成30年12月13日付け意見書において、本願の段落0037、段落0043、段落0044、および段落0049にサポートされている旨を主張しているので、以下、補正事項による補正後の構成D1が、翻訳文等に記載された事項の範囲内か否かについて検討する。

上記(2)アによれば、「送信装置(例えば、サーバ又は端末)」は、T-NAL情報を生成し、T-NAL情報をパケットのヘッダーに含んで送信し、「ネットワークエンティティー(例えば、ルータ又は基地局(BS))」は、T-NAL情報を用いてパケットの重要度又はリソース予約状態を識別し、この識別された結果に基づいてパケットを送信することが記載されている。

上記(2)イによれば、「送信装置300」に含まれる「CLO部302」は、対応するメディアデータに関するT-NAL情報、すなわち、ラベル情報を生成し、このラベル情報をパケット生成部303に送信し、このラベル情報は、下位ネットワークがパケットの重要度、優先順位、又はリソース予約状態を認識するために使用することができ、「送信装置300」に含まれる「パケット生成部303」は、この受信されたラベル情報を含むパケットを生成し、この生成されたパケットを、ネットワーク313を通して送信することが記載されている。

上記(2)ウによれば、パケットは、下位階層ネットワークエンティティーが対応するメディアデータパケットに関するメディアデータパケットの損失レベル、遅延レベル、又は優先順位レベル、又はリソース予約情報を認識することができるようにラベルの形態でT-NAL情報を含むことが記載されている。

上記(2)エによれば、「ネットワークエンティティー」、すなわち、「MANE」は、送信装置からパケットを受信し、クラス別QｏS方式の場合に、パケットのIPヘッダーに含まれている重要度情報、すなわち、ラベル値に従ってパケットを廃棄し、フロー別QｏS方式の場合に、ラベル値を確認し、ラベル値に対応する予め定められたリソースを用いてQｏS(ビット率、損失率、及び遅延など)をサポートすることが記載されている。

以上によれば、翻訳文等には、「送信装置」について、以下の事項が記載されているといえる。
・「送信装置(例えば、サーバ又は端末)」は、T-NAL情報を生成し、T-NAL情報をパケットのヘッダーに含んで送信する。
・「送信装置300」に含まれる「CLO部302」は、対応するメディアデータに関するT-NAL情報、すなわち、ラベル情報を生成し、このラベル情報をパケット生成部303に送信する。
・「送信装置300」に含まれる「パケット生成部303」は、この受信されたラベル情報を含むパケットを生成し、この生成されたパケットを、ネットワーク313を通して送信する。

また、翻訳文等には、「ネットワークエンティティー」について、以下の事項が記載されているといえる。
・「ネットワークエンティティー(例えば、ルータ又は基地局(BS))」は、T-NAL情報を用いてパケットの重要度又はリソース予約状態を識別し、この識別された結果に基づいてパケットを送信する。
・パケットは、下位階層ネットワークエンティティーが対応するメディアデータパケットに関するメディアデータパケットの損失レベル、遅延レベル、又は優先順位レベル、又はリソース予約情報を認識することができるようにラベルの形態でT-NAL情報を含む。
・ラベル情報は、下位ネットワークがパケットの重要度、優先順位、又はリソース予約状態を認識するために使用することができる。
・「ネットワークエンティティー」、すなわち、「MANE」は、送信装置からパケットを受信し、クラス別QｏS方式の場合に、パケットのIPヘッダーに含まれている重要度情報、すなわち、ラベル値に従ってパケットを廃棄し、フロー別QｏS方式の場合に、ラベル値を確認し、ラベル値に対応する予め定められたリソースを用いてQｏS(ビット率、損失率、及び遅延など)をサポートする。

そして、「送信装置」及び「ネットワークエンティティー」で行われるパケットの送受信の処理の手順について、翻訳文等の記載から把握される処理の内容及び順序は、以下のとおりである。以下、各処理の内容について、手順ア?手順ウと称する。

(手順ア)「送信装置」が、T-NAL情報(ラベル情報)をヘッダーに含むパケットを生成し、生成されたパケットを、ネットワークを通して送信する。
(手順イ)「ネットワークエンティティー」が、送信装置からパケットを受信し、T-NAL情報(ラベル情報)により、メディアデータパケットの損失レベル、遅延レベル、又は優先順位レベル、又はリソース予約情報を認識する。
(手順ウ)「ネットワークエンティティー」が、識別された結果に基づいてパケットを送信し、ラベル値に従ってパケットの廃棄やリソースを用いたQｏSをサポートする。

以上によれば、構成D11に係る処理の後に、構成D12に係る処理を行うという処理の順序は、手順アに係る処理の後に、手順イに係る処理を行うという処理の順序と異なるといえる。
よって、構成D11に係る処理の後に構成D12に係る処理を行うという処理の順序は、翻訳文等に記載されたものとはいえない。
また、構成D11に係る処理の後に構成D12に係る処理を行うという処理の順序は、翻訳文等から自明であるともいえない。

また、構成D11は送信装置が行う処理であるが、手順イの処理は、「ネットワークエンティティー」が行う処理であって、「送信装置」が行う処理ではない。
よって、「送信装置」が、構成D11に係る処理を行うことも、翻訳文等に記載されたものとはいえない。
また、「送信装置」が、構成D11に係る処理を行うことは、翻訳文等から自明であるともいえない。

したがって、補正事項による補正後の構成D1は、翻訳文等に記載されたものではなく、翻訳文等から自明でもないから、翻訳文等のすべての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入するものである。

以上によれば、請求項1に係る補正は、国際出願日における国際特許出願の明細書若しくは図面(図面の中の説明に限る。)の翻訳文、国際出願日における国際特許出願の請求の範囲の翻訳文又は国際出願日における国際特許出願の図面(図面の中の説明を除く。)に記載した事項の範囲内においてしたものでないから、特許法第17条の2第3項に規定する要件を満たしていない。

3 まとめ
以上のとおり、本件補正は、特許法第17条の2第3項に規定する要件に違反するものであるから、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。
よって、上記補正の却下の決定の結論のとおり決定する。

第3 本願発明について
1 本願発明
平成30年12月13日付けの手続補正は上記のとおり却下されたので、本願の請求項に係る発明は、平成30年3月30日付けの手続補正により補正された特許請求の範囲の請求項1及び2に記載された事項により特定されるものであり、そのうち、請求項1に係る発明(以下、「本願発明」という。)は、上記第2の1に示した(補正前の請求項1)に記載された事項により特定されるとおりのものである。

2 当審の拒絶の理由
平成30年8月7日付けで当審が通知した拒絶の理由のうち、理由1及び理由2(1)は、概略、以下のとおりである。

理由1.(進歩性)この出願の請求項1及び2に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

記
引用文献1.特開2003-244676号公報
引用文献2.特開2002-141945号公報(周知技術を示す文献)

理由2.(サポート要件)この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第1号に規定する要件を満たしていない。

記
請求項1及び請求項2には、発明の課題を解決するための手段が反映されているとはいえず、請求項1及び請求項2は、発明の詳細な説明に記載した範囲を超えて特許を請求することとなっている。

3 理由2(サポート要件)について
事案に鑑み、理由2(サポート要件)について検討する。

(1)発明の詳細な説明の記載
本願の発明の詳細な説明には、以下の記載がある。

ア「【技術分野】
【0001】
本発明は、マルチメディアデータパケットを送信する方法及び装置に関し、特に、相互階層最適化を通してマルチメディアデータパケットを送信する方法及び装置に関する。」

イ「【0003】
マルチメディアサービスを提供するために、ネットワークは、大きく3通りの方式、すなわち、ベストエフォート(Best Effort:BE)方式、クラス別QｏS(per class QoS)方式、及びフロー別QｏS(per flow QoS)方式でサービス品質(Quality of Service:QｏS)を保証する。BEサービスのQｏSを保証するためには何のサポートもしない。
【0004】
クラス別QｏSサービスは、パケットごとに重要度を異ならせてネットワークでその重要度に従ってパケットを処理する。すなわち、パケットのQｏSは、対応するパケットがどんなフローに属しているかに関係なく、対応するパケットの重要度、すなわち、優先順位に従って制御される。クラス別QｏS方式をサポートするためには、送信装置と受信装置間のリソースの予約が不要である。参考までに、この優先順位は、損失優先順位(loss priority)及び遅延優先順位(delay priority)に分類することができる。
【0005】
フロー別QｏSサービスは、ストリーム別にリソースを予約する。すなわち、フロー別にリソース(例えば、ビット率及びバッファ状態)又はQｏS(例えば、遅延及び損失率など)を予約する。ここで、フローとは、1つのサービスを提供するために必要とされるストリームを意味する。例えば、VｏDサービスを提供するために必要とされるビデオストリーム、オーディオストリーム、及びテキストストリームは、個別のフローである。
【0006】
IEEE 802.16(WiBRO及びWIMAX)及びロングタームエボルーション(Long Term Evolution:LTE)標準だけではなく、3GPP UMTS(3G)標準でもクラス別QｏS及びフロー別QｏSをサポートする。しかしながら、QｏS方式を使用するためには、上位階層であるメディア階層は、下位階層であるネットワーク間のインターフェースが必要である。
【0007】
従来、リアルタイム転送プロトコル(Real-time Transport Protocol:RTP)及びリアルタイム制御プロトコル(Real-Time Control Protocol:RTCP)は、下位階層を考慮せず、サービス終端で累積された情報を用いてネットワークリソース又はQｏSを測定するように設計される。従来のRTP及びRTCPにおいて、送信を担当するネットワーク部分は、ブラックボックスとして保持されるので、あらゆる変化を正確に認識することは難しい。したがって、正確なQｏS制御のためには、下位階層から直接上がってくるインターフェースを使用しなければならない。」

ウ「【発明の概要】
【発明が解決しようとする課題】
【0022】
本発明の目的は、少なくとも上述した問題点及び/又は不都合に取り組み、少なくとも以下の便宜を提供することにある。すなわち、本発明の目的は、メディアデータ、ネットワーク状態、及びユーザーの要求に従って適応的にマルチメディアサービスを提供する方法及び装置を提供することにある。
【0023】
本発明の他の目的は、アプリケーション階層及び下位階層ネットワークエンティティーとの情報を交換する統合ネットワーク抽象化階層(NAL)を提供することにある。
【0024】
本発明のまた他の目的は、メディアデータ状態、ネットワーク状態、及びユーザーの要求状態に従ってマルチメディアサービスを提供するためにこのような状態を抽象化し、エンティティー間で抽象化された状態に関する情報を送受信する方法及び装置を提供することにある。」

エ「【課題を解決するための手段】
【0025】
上記のような目的を達成するために、本発明の実施形態の一態様によれば、マルチメディアデータパケットを送信する方法は、ボトムアップネットワーク抽象化階層(B-NAL)情報をネットワークエンティティーから受信するステップと、上記受信されたB-NAL情報に基づいてメディアデータ品質を決定し、上記決定された品質を有するメディアデータを生成するステップと、上記生成されたメディアデータに対するパケットを生成し、上記パケットを送信するステップとを有することを特徴とする。」

オ「【0036】
また、本発明は、送信されるメディアデータに関連した情報を抽象化するトップダウン(Top-down)インターフェース、すなわち、T-NAL階層と、ネットワーク状態に関連した情報を抽象化するボトムアップ(Bottom-up)インターフェース、すなわち、B-NAL階層とを提案する。以下では、T-NAL階層で抽象化されたデータ関連情報は、T-NAL情報と呼ばれ、B-NAL階層で抽象化されたネットワーク状態情報は、B-NAL情報と呼ばれる。」

カ「【0039】
図3は、本発明によるマルチメディアデータパケットを送信する装置及び方法を示す。送信装置300は、サーバ又は端末であることができる。
【0040】
図3を参照すると、送信装置300は、メディアデータ供給部301と、パケット生成部303と、本発明に特有な構成、すなわち、相互階層最適化(Cross Layer Optimization:CLO)部302と、B-NALレジスタ304とを含む。
【0041】
B-NALレジスタ304は、ネットワーク313からB-NAL情報310を受信し記憶する。B-NAL情報は、一般的に、ネットワークエンティティーにより生成されたネットワーク状態情報である。しかしながら、B-NAL情報は、ユーザー端末により要求されるQｏS情報又はメディアデータ制御に適合した制御情報であり得る。例えば、ユーザー端末の状態が高いQｏSサービスの受信に不適切である場合に、ユーザーは、低いQｏSパケットサービスを要求することができる。送信パケットの遅延及び損失が大きい場合に、特定のメディアは、このような情報をB-NALレジスタ304から取得することができる。この場合に、B-NAL情報は、ユーザーからの要求に従ってユーザー端末により生成された情報であり得る。しかしながら、説明の便宜上、下記の説明では、B-NAL情報がネットワーク状態情報であることを仮定する。
【0042】
CLO部302は、B-NALレジスタ304からB-NAL情報を読み出すか又は受信されたB-NALパケットから読み出し、B-NAL情報に従って送信されるメディアデータの品質を適応的に決定し、この送信されるメディアデータを少なくとも1つのアクセス単位(Access Unit:AU)でメディアデータ供給部301に要求し(305)、このメディアデータをメディアデータ供給部305から受信する(306)。
【0043】
この後に、CLO部302は、1つのIPパケットを通して送信されるメディアデータをパケット生成部303に送信する(309)。この時に、CLO部302は、対応するメディアデータに関するT-NAL情報、すなわち、ラベル情報を生成し、このラベル情報をパケット生成部303に送信する(308)。上述したように、このラベル情報は、下位ネットワークがパケットの重要度、優先順位、又はリソース予約状態を認識するために使用することができる。
【0044】
パケット生成部303は、この受信されたラベル情報を含むパケットを生成し、この生成されたパケットを、ネットワーク313を通して送信する(311)。このラベル情報は、IPパケットのヘッダー又は他の下位プロトコルのパケットヘッダーに含めることができる。」

(2)本願発明が解決しようとする課題について
本願発明が解決しようとする課題及び発明の課題を解決するための手段について検討する。

上記(1)アによれば、本発明は、マルチメディアデータパケットを送信する方法及び装置に関し、特に、相互階層最適化を通してマルチメディアデータパケットを送信する方法及び装置に関するものである。

また、上記(1)イによれば、マルチメディアサービスを提供するために、ネットワークは、大きく3通りの方式、すなわち、ベストエフォート(Best Effort:BE)方式、クラス別QｏS(per class QoS)方式、及びフロー別QｏS(per flow QoS)方式でサービス品質(Quality of Service:QｏS)を保証することが記載されている。

また、上記(1)イによれば、従来、リアルタイム転送プロトコル(Real-time Transport Protocol:RTP)及びリアルタイム制御プロトコル(Real-Time Control Protocol:RTCP)は、下位階層を考慮せず、サービス終端で累積された情報を用いてネットワークリソース又はQｏSを測定するように設計されており、従来のRTP及びRTCPにおいて、送信を担当するネットワーク部分は、ブラックボックスとして保持されるので、あらゆる変化を正確に認識することは難しく、正確なQｏS制御のためには、下位階層から直接上がってくるインターフェースを使用しなければならないことが記載されている。

また、上記(1)ウによれば、本発明の目的は、少なくとも上述した問題点及び/又は不都合に取り組み、少なくとも以下の便宜を提供すること、すなわち、本発明の目的は、メディアデータ、ネットワーク状態、及びユーザーの要求に従って適応的にマルチメディアサービスを提供する方法及び装置を提供することにあり、本発明の他の目的は、アプリケーション階層及び下位階層ネットワークエンティティーとの情報を交換する統合ネットワーク抽象化階層(NAL)を提供することにあると記載されている。

また、上記(1)エによれば、課題を解決するための手段として、上記のような目的を達成するために、本発明の実施形態の一態様によれば、マルチメディアデータパケットを送信する方法は、ボトムアップネットワーク抽象化階層(B-NAL)情報をネットワークエンティティーから受信するステップと、上記受信されたB-NAL情報に基づいてメディアデータ品質を決定し、上記決定された品質を有するメディアデータを生成するステップと、上記生成されたメディアデータに対するパケットを生成し、上記パケットを送信するステップとを有することを特徴とすると記載されている。

また、上記(1)オによれば、本発明は、ネットワーク状態に関連した情報を抽象化するボトムアップ(Bottom-up)インターフェース、すなわち、B-NAL階層を提案し、B-NAL階層で抽象化されたネットワーク状態情報は、B-NAL情報と呼ばれることが記載されている。

また、上記(1)カによれば、送信装置300は、パケット生成部303と、相互階層最適化(Cross Layer Optimization:CLO)部302とを含み、CLO部302は、B-NAL情報に従って送信されるメディアデータの品質を適応的に決定し、この送信されるメディアデータを少なくとも1つのアクセス単位(Access Unit:AU)でメディアデータ供給部301に要求し、このメディアデータをメディアデータ供給部305から受信し、CLO部302は、1つのIPパケットを通して送信されるメディアデータをパケット生成部303に送信し、パケット生成部303は、この受信されたラベル情報を含むパケットを生成し、この生成されたパケットを、ネットワーク313を通して送信することが記載されている。

以上によれば、本願発明が解決しようとする課題は、相互階層最適化を通してマルチメディアデータパケットを送信する方法及び装置において、正確なQｏS制御のためには、下位階層から直接上がってくるインターフェースを使用しなければならないことを問題点とし、メディアデータ、ネットワーク状態、及びユーザーの要求に従って適応的にマルチメディアサービスを提供する方法及び装置を提供するとともに、アプリケーション階層及び下位階層ネットワークエンティティーとの情報を交換する統合ネットワーク抽象化階層(NAL)を提供することであるといえる。

そして、当該課題を解決するための手段は、受信されたB-NAL情報に基づいてメディアデータ品質を決定し、上記決定された品質を有するメディアデータを生成することであり、具体的には、本願発明に係る送信装置はCLO部を含み、CLO部が、B-NAL情報に従って送信されるメディアデータの品質を適応的に決定し、この送信されるメディアデータをメディアデータ供給部から受信して、パケット生成部に送信することであるといえる。

(3)判断
本願の請求項1に、発明の課題を解決するための手段が反映されているかどうかについて検討する。

上記(2)のとおり、発明の課題を解決するための手段は、受信されたB-NAL情報に基づいてメディアデータ品質を決定し、上記決定された品質を有するメディアデータを生成することであり、具体的には、本願発明に係る送信装置はCLO部を含み、CLO部が、B-NAL情報に従って送信されるメディアデータの品質を適応的に決定し、この送信されるメディアデータをメディアデータ供給部から受信して、パケット生成部に送信することである。

一方、本願の請求項1には、B-NAL情報に関しては、「前記下位階層から前記アプリケーション階層にネットワークチャネル状態情報を前記インターフェースを通して周期的又は非周期的なボトムアップ式情報(ボトムアップネットワーク抽象化階層(B-NAL)情報)として提供するステップ」(構成B)が記載されるのみであり、「B-NAL情報に基づいてメディアデータ品質を決定し、上記決定された品質を有するメディアデータを生成する」ことについては、何らの記載もない。
そして、ネットワークチャネル状態情報をB-NAL情報として提供するステップを行うのみでは、QｏS制御を行ったことにはならないから、正確なQｏS制御を行ってマルチメディアサービスを提供することができないことは、当業者にとって明らかである。

よって、本願の請求項1には、発明の課題を解決するための手段が反映されているとはいえず、本願発明は、発明の詳細な説明において発明の課題が解決できることを当業者が認識できるように記載された範囲を超えるものである。

(4)まとめ
以上によれば、本願発明は、発明の詳細な説明において発明の課題が解決できることを当業者が認識できるように記載された範囲を超えるものであるから、発明の詳細な説明に記載されたものとはいえず、特許法第36条第6項第1号に規定する要件を満たしていない。

4 予備的検討(理由1(進歩性)について)
上記3のとおり、本願発明は発明の詳細な説明に記載されたものとはいえないから、本願は拒絶をすべきものであるが、仮に、本願発明が発明の詳細な説明に記載されたものであったとしても、当審は、本願発明は、特許法第29条第2項の規定により特許を受けることができないから、本願は拒絶をすべきものと考える。
その理由は以下のとおりである。

(1)引用文献の記載事項
ア 引用文献1
当審の拒絶の理由に引用された引用文献1である特開2003-244676号公報には、「動画配信システム、動画配信装置および方法、記録媒体、並びにプログラム」(発明の名称)に関し、図面とともに次に掲げる事項が記載されている。
なお、下線は、強調のために当審で付したものである。

(ア)「【0001】
【発明の属する技術分野】本発明は、動画配信システム、動画配信装置および方法、記録媒体、並びにプログラムに関し、特に、異なる品質の画像を指定する複数のユーザに対して、対応する品質の画像をそれぞれ同時に配信することができるようにした動画配信システム、動画配信装置および方法、記録媒体、並びにプログラムに関する。」

(イ)「【0039】
【発明の実施の形態】図1は、本発明が適用される動画配信システム1の構成例を表している。
【0040】なお、動画配信システム1において処理される単位は、例えば、上述したように、フレームが単位とされることも可能であるが、フィールドが単位とされることも可能である。そこで、本発明では、この単位を、アクセスユニットとも称する。
【0041】ビデオカメラ等により構成される動画入力装置11は、映像や音声を入力し、それらを動画のデータに変換し、動画配信装置12に供給する。
【0042】なお、この例においては、上述したように、映像のデータのみならず、音声のデータ等も併せて、動画データと称する。
【0043】動画配信装置12は、供給された動画のデータを、ウェーブレット変換を使用した符号化方式(例えば、Motion JPEG200による符号化方式)により、フレームを単位として階層符号化し、階層符号化されたフレームをパケット化して、それぞれの階層に対応する複数のパケットからなるパケット群を生成する。
【0044】さらに、動画配信装置12は、生成されたパケット群のうち、配信先(後述するユーザ端末15a乃至ユーザ端末15cのうちのいずれかの端末)より指定された階層に対応するパケットをネットワーク13aに供給する。
【0045】なお、この例においては、ネットワーク13aは、インターネットであるものとする。この場合、動画配信装置12は、パケットを、IP(Internet protocol)パケットとしてネットワーク13aに供給する。
【0046】ネットワーク13aは、このIPパケットを、IPパケットに含まれているアドレスに対応する配信先に供給する。
【0047】即ち、ネットワーク13aに供給されたIPパケットは、配信先がユーザ端末15aであった場合、例えば、ダイアルアップサービスを提供するサービスプロバイダのネットワーク13bを介してユーザ端末15aに、送信先が15bであった場合、例えば、ADSL(Asymmetrical Digital Subscriber Line)を使ったサービスプロバイダのネットワーク13cを介してユーザ端末15bに、配信先がユーザ端末15cであった場合、例えば、無線ネットワークにより基地局14を介して移動端末(携帯電話機等の端末)であるユーザ端末15cに、それぞれ供給(配信)される。」

(ウ)「【0073】次に、図3を参照して、動画配信装置12の構成を説明する。
【0074】主制御部41は、動画配信装置12全体の動作を制御する。
【0075】符号化部42は、動画入力装置11より供給された動画データを、主制御部41より供給される制御パラメータ(例えば、各フレームをどのプログレッシブに基づいて階層符号化させるのかを示すパラメータ等)に基づいて、フレームを単位として階層符号化し、制御パラメータにより指定されているバッファ部43aまたはバッファ部43bに供給する。
【0076】例えば、主制御部41より供給された制御パラメータに、各フレームを2種類のプログレッシブ(第1および第2のプログレッシブ)に基づいて階層符号化させる旨の情報が含まれていたものとすると、符号化部42は、フレーム毎に、第1のプログレッシブに基づいて階層符号化し、バッファ部43aに供給するとともに、第2のプログレッシブに基づいて階層符号化し、バッファ部43bに供給する。
【0077】即ち、バッファ部43aは、第1のプログレッシブに基づいて階層符号化されたフレーム専用のバッファであり、バッファ部43bは、第2のプログレッシブに基づいて階層符号化されたフレーム専用のバッファである。
【0078】従って、図3の例では、バッファの数は、バッファ部43aおよびバッファ部43bの2つだけであるが、実際には、主制御部42により供給される制御パラメータに含まれるプログレッシブの種類の数だけ必要となる。
【0079】換言すると、符号化部42は、同一のフレーム(画像)を、プログレッシブ順序を変えてそれぞれ階層符号化し、対応するプログレッシブ専用のバッファ(バッファ部43aおよびバッファ部43b等)にそれぞれ供給する。
【0080】なお、符号化部42の符号化方式は、階層符号化が可能な符号化方式であれば限定されないが、この例においては、上述したように、プログレッシッブ符号化方式の1つであるMotion JPEG2000による符号化方式(ウェーブレット変換を利用した符号化方式)であるものとする。
【0081】パケット化部44は、主制御部41の制御に基づいて、バッファ部43aまたはバッファ部43bに記憶されているデータ(符号化部42により階層符号化されたフレームのデータ)を解析して、プログレッシブの階層毎にデータ区切りを検出して、同一の階層毎にパケット化し、それぞれの階層に対応する複数のパケットからなるパケット群を生成する。この処理は、フレーム毎に、バッファ部43aおよびバッファ部43bのそれぞれに対して行われる。
【0082】また、パケット化部44は、これらのパケットのそれぞれに、各階層に対応する識別子を表すフラグをそれぞれ付与する。
【0083】この識別子は、動画配信装置12が放送型の配信をする場合、受信端末(図1のユーザ端末15a乃至ユーザ端末15c等)が、自身の能力に必要なパケットを指定するために必要なものであり、従って、1対1で通信される場合、この識別子は、必須とされない。
【0084】このように、パケット化部44は、バッファ部43aおよびバッファ部43bに記憶されているそれぞれの階層符号化されたフレームのデータを、対応するプログレッシブ順序でそれぞれパケット化し、各階層に対応する複数のパケット(各階層に対応する識別子がそれぞれ付与された複数のパケット)からなるパケット群をそれぞれ生成し、通信部45に供給する。
【0085】通信部45は、主制御部41の制御に基づいて、供給されたパケット群のうち、主制御部41より指示されたパケットを、ネットワーク13aに送信する。」

(エ)「【0086】なお、必要に応じて、パケット化部44は、さらに、パケットをIPパケットにすることができる。この場合、パケット化部44は、識別子に対応する優先度を示すフラグをIPパケットのヘッダにつけ直してもよい。
【0087】例えば、IP規格のバージョン4(IPv4)においては、TOS(Type Of Service)に対して優先度が示され、Diffservに対応したネットワークにおいて優先度のあるパケットの優先制御が可能となる。また、IP規格のバージョン6(IPv6)においては、フローラベルに対して優先度が示されることが可能である。
【0088】このように、ネットワーク層で利用されるプロトコルが異なると、優先度が示される数も異なるため、符号化部42により階層符号化される場合の階層、アプリケーションが意識されたパケットにおける優先度、およびネットワーク層における優先度はそれぞれ対応付けられて指定されることが望ましく、その指定の制御を行うのが主制御部41である。
【0089】この指定の制御は、あらかじめ優先度の対応付けが設定された制御であってもよいし、動的にネットワークのトラフィックや受信端末(図1のユーザ端末15a乃至ユーザ端末15c等)の負荷を考慮して優先度の設定を変更する制御であってもよい。
【0090】ネットワークのトラフィック状態を監視する方法としては、例えば、IETF(Internet Engineering Task Force)のRFC(Request For Comments)1889におけるRTCP(RTP(Real-time Transport Protocol) Control Protocol)が適用された方法が知られている。
【0091】この方法においては、送信側は、一定時間毎に、送出RTPパケット数やタイムスタンプ情報等の情報、いわゆる「送信レポート」を受信側にパケットとして送信し、受信側は、この「送信レポート」に基づいて、送信側にRTPパケットの紛失率、紛失パケット数、受信した最大シーケンス番号、および到着間隔ジッタ等を含む情報、いわゆる「受信レポート」を返信する。
【0092】このように、RTCPは、送信側と受信側の間のプロトコルであり、送信側と受信側の間に介在するネットワークの種類、すなわちLAN(Local Area Network)やWAN(Wide Area Network)等に関わらず機能するプロトコルである。
【0093】そこで、この例においては、主制御部41は、このRTCPに基づいて、ネットワークのトラフィック情報を監視し、上述した指定の制御を行うものとする。
【0094】即ち、通信部45は、各受信端末(図1のユーザ端末15a乃至ユーザ端末15c等)からネットワーク13aを介して供給されてくる受信レポートを、それぞれネットワーク監視・解析部46に供給する。
【0095】ネットワーク監視・解析部46は、供給されたこれらの各受信端末に対応する受信レポートに基づいて、ネットワークの輻輳状態を判定し、さらにその判定結果に基づいて、符号化部42の符号化のレートを下げたり、送信フレーム数を下げたりさせるための制御に必要な各受信端末毎の情報を主制御部41へそれぞれ供給する。
【0096】主制御部41は、供給された各受信端末毎のこれらの情報のうち、所定の受信端末に対応する情報等に基づいて、上述したように、その所定の受信端末に対応する制御パラメータを生成し、符号化部42に供給する。
【0097】また、主制御部41は、供給された各受信端末毎のこれらの情報に基づいて、それぞれのプログレッシブに対応する上述した設定の制御を行う。即ち、主制御部41は、各プログレッシブ毎に、上述した識別子に対応したIPの優先度を設定し、パケット化部44にそれぞれ供給し、パケット化部44は、これらのIPの優先度を示すフラグを、対応するプログレッシブのIPパケットのヘッダにそれぞれつけ直す。
【0098】このように、主制御部41は、パケット化部44を制御して優先度を設定することで、動画配信装置12を使用するサービス提供者が最低限保証したい品質を確保するように制御することができる。」

イ 引用文献2
当審の拒絶の理由に引用された引用文献2である特開2002-141945号公報には、「データ送信装置、およびデータ送信方法、並びにプログラム記憶媒体」(発明の名称)に関し、図面とともに次に掲げる事項が記載されている。
なお、下線は、強調のために当審で付したものである。

(ア)「【0001】
【発明の属する技術分野】本発明は、データ送信装置、およびデータ送信方法、並びにプログラム記憶媒体に関する。さらに詳細には、異なる重要度を有するデータの混在データを転送する処理において、重要度に応じた転送処理を実行することにより、転送データの品質低下を防止することを可能としたデータ送信装置、およびデータ送信方法、並びにプログラム記憶媒体に関する。」

(イ)「【0051】なお、図8で説明したIPヘッダはIPｖ4のヘッダ構成である。IPｖ6のヘッダにも優先情報格納フィールドがあり、IPｖ6の優先情報は、混雑制御タイプ(congestion-controlled)と、混雑非制御タイプ(Non-congestion-controlled)とがある。混雑制御タイプ(congestion-controlled)は、確実なデータ転送を制御する優先順位であり、0?7までの優先順位が設定され、例えばネットワーク管理やリモートログインなどに高い優先順位を設定し、電子メールなどに低い優先順位を設定するなどの利用が可能である。混雑非制御タイプ(Non-congestion-controlled)は、リアルタイム性を要求されるサービスで利用され、8?15までの優先順位が設定され、優先順位の低いもの(eｘ.優先度8)には狭い帯域を設定し、高いもの(eｘ.優先度15)には広い帯域を設定し、帯域確保が十分でない場合は、優先順位の低いもの(eｘ.優先度8)を破棄し、高いもののみを送付するような構成とする処理が実行される。」

(2)引用文献に記載された発明及び技術
ア 引用文献1に記載された発明
引用文献1に記載された発明を以下に認定する。

(ア)動画配信装置における配信方法について
上記(1)ア(ア)によれば、引用文献1には、「異なる品質の画像を指定する複数のユーザに対して、対応する品質の画像をそれぞれ同時に配信する」ことができるようにした「動画配信装置および方法」が記載されている。
また、上記(1)ア(イ)によれば、「動画配信装置12」は、「供給された動画のデータ」を「階層符号化」し、「階層符号化されたフレームをパケット化して、それぞれの階層に対応する複数のパケットからなるパケット群を生成」し、「生成されたパケット群のうち、配信先(後述するユーザ端末15a乃至ユーザ端末15cのうちのいずれかの端末)より指定された階層に対応するパケットをネットワーク13aに供給する」ことが記載されている。

以上によれば、引用文献1には、『供給された動画のデータを階層符号化し、階層符号化されたフレームをパケット化して、それぞれの階層に対応する複数のパケットからなるパケット群を生成し、生成されたパケット群のうち、配信先より指定された階層に対応するパケットをネットワークに供給する動画配信装置における配信方法』の発明が記載されている。

(イ)符号化部について
上記(1)ア(ウ)によれば、「符号化部42は、動画入力装置11より供給された動画データを、主制御部41より供給される制御パラメータ(例えば、各フレームをどのプログレッシブに基づいて階層符号化させるのかを示すパラメータ等)に基づいて、フレームを単位として階層符号化し、制御パラメータにより指定されているバッファ部43aまたはバッファ部43bに供給する」と記載されている。

以上によれば、引用文献1には、『符号化部が、動画入力装置より供給された動画データを、主制御部より供給される制御パラメータに基づいて、フレームを単位として階層符号化し、制御パラメータにより指定されているバッファ部に供給する』ことが記載されている。

(ウ)パケット化部について
上記(1)ア(ウ)によれば、「パケット化部44は、主制御部41の制御に基づいて、バッファ部43aまたはバッファ部43bに記憶されているデータ(符号化部42により階層符号化されたフレームのデータ)を解析して、プログレッシブの階層毎にデータ区切りを検出して、同一の階層毎にパケット化し、それぞれの階層に対応する複数のパケットからなるパケット群を生成する」と記載されている。
また、上記(1)ア(ウ)によれば、「パケット化部44は、これらのパケットのそれぞれに、各階層に対応する識別子を表すフラグをそれぞれ付与する」と記載されている。
また、上記(1)ア(エ)によれば、「パケット化部44は、さらに、パケットをIPパケットにすることができる。この場合、パケット化部44は、識別子に対応する優先度を示すフラグをIPパケットのヘッダにつけ直してもよい」と記載されている。
また、上記(1)ア(ウ)によれば、「パケット化部44」は、「各階層に対応する複数のパケット(各階層に対応する識別子がそれぞれ付与された複数のパケット)からなるパケット群をそれぞれ生成し、通信部45に供給する」と記載されている。

以上によれば、引用文献1には、『パケット化部が、主制御部の制御に基づいて、バッファ部に記憶されているデータ(符号化部により階層符号化されたフレームのデータ)を解析して、プログレッシブの階層毎にデータ区切りを検出して、同一の階層毎にパケット化し、それぞれの階層に対応する複数のパケットからなるパケット群を生成し、これらのパケットのそれぞれに、各階層に対応する識別子を表すフラグをそれぞれ付与し、さらに、パケットをIPパケットにし、識別子に対応する優先度を示すフラグをIPパケットのヘッダにつけ直し、通信部に供給する』ことが記載されている。

(エ)受信レポートについて
上記(1)ア(エ)によれば、「通信部45は、各受信端末(図1のユーザ端末15a乃至ユーザ端末15c等)からネットワーク13aを介して供給されてくる受信レポートを、それぞれネットワーク監視・解析部46に供給する」と記載されている。
また、上記(1)ア(エ)によれば、「送信側は、一定時間毎に、送出RTPパケット数やタイムスタンプ情報等の情報、いわゆる「送信レポート」を受信側にパケットとして送信し、受信側は、この「送信レポート」に基づいて、送信側にRTPパケットの紛失率、紛失パケット数、受信した最大シーケンス番号、および到着間隔ジッタ等を含む情報、いわゆる「受信レポート」を返信する」と記載されている。

したがって、引用文献1には、『通信部が、各受信端末からネットワークを介して供給されてくる受信レポートを、それぞれネットワーク監視・解析部に供給し、ここで、受信レポートは、送信側が、一定時間毎に、送出RTPパケット数やタイムスタンプ情報等の情報、いわゆる「送信レポート」を受信側にパケットとして送信し、受信側が、この「送信レポート」に基づいて、送信側にRTPパケットの紛失率、紛失パケット数、受信した最大シーケンス番号、および到着間隔ジッタ等を含む情報、いわゆる「受信レポート」を返信することにより得られるものである』ことが記載されている。

(オ)ネットワーク監視・解析部について
上記(1)ア(エ)によれば、「ネットワーク監視・解析部46は、供給されたこれらの各受信端末に対応する受信レポートに基づいて、ネットワークの輻輳状態を判定し、さらにその判定結果に基づいて、符号化部42の符号化のレートを下げたり、送信フレーム数を下げたりさせるための制御に必要な各受信端末毎の情報を主制御部41へそれぞれ供給する」と記載されている。

以上によれば、引用文献1には、『ネットワーク監視・解析部が、供給されたこれらの各受信端末に対応する受信レポートに基づいて、ネットワークの輻輳状態を判定し、さらにその判定結果に基づいて、符号化部の符号化のレートを下げたり、送信フレーム数を下げたりさせるための制御に必要な各受信端末毎の情報を主制御部へそれぞれ供給する』ことが記載されている。

(カ)主制御部について
上記(1)ア(エ)によれば、「主制御部41は、供給された各受信端末毎のこれらの情報のうち、所定の受信端末に対応する情報等に基づいて、上述したように、その所定の受信端末に対応する制御パラメータを生成し、符号化部42に供給する」と記載されている。
また、 上記(1)ア(エ)によれば、「主制御部41は、各プログレッシブ毎に、上述した識別子に対応したIPの優先度を設定し、パケット化部44にそれぞれ供給」することが記載されている。

以上によれば、引用文献1には、『主制御部が、供給された各受信端末毎のこれらの情報のうち、所定の受信端末に対応する情報等に基づいて、その所定の受信端末に対応する制御パラメータを生成し、符号化部に供給するとともに、各プログレッシブ毎に、上述した識別子に対応したIPの優先度を設定し、パケット化部にそれぞれ供給する』ことが記載されている。

(キ)通信部ついて
上記(1)ア(ウ)によれば、「通信部45は、主制御部41の制御に基づいて、供給されたパケット群のうち、主制御部41より指示されたパケットを、ネットワーク13aに送信する」と記載されている。

以上によれば、『通信部が、主制御部の制御に基づいて、供給されたパケット群のうち、主制御部より指示されたパケットを、ネットワークに送信する』ことが記載されている。

(ク)IPパケットの供給について
上記(1)ア(イ)によれば、「ネットワーク13aに供給されたIPパケットは、配信先がユーザ端末15aであった場合、例えば、ダイアルアップサービスを提供するサービスプロバイダのネットワーク13bを介してユーザ端末15aに、送信先が15bであった場合、例えば、ADSL(Asymmetrical Digital Subscriber Line)を使ったサービスプロバイダのネットワーク13cを介してユーザ端末15bに、配信先がユーザ端末15cであった場合、例えば、無線ネットワークにより基地局14を介して移動端末(携帯電話機等の端末)であるユーザ端末15cに、それぞれ供給(配信)される」と記載されている。

以上によれば、引用文献1には、『ネットワークに供給されたIPパケットは、配信先がユーザ端末15aであった場合、例えば、ダイアルアップサービスを提供するサービスプロバイダのネットワークを介してユーザ端末15aに、送信先が15bであった場合、例えば、ADSL(Asymmetrical Digital Subscriber Line)を使ったサービスプロバイダのネットワークを介してユーザ端末15bに、配信先がユーザ端末15cであった場合、例えば、無線ネットワークにより基地局を介して移動端末(携帯電話機等の端末)であるユーザ端末15cに、それぞれ供給(配信)される』ことが記載されている。

(ケ)まとめ
以上より、引用文献1には、次の発明(以下、「引用発明」という。)が記載されていると認められる。引用発明の各構成については、以下、構成a?構成hと称する。

(引用発明)
(a)供給された動画のデータを階層符号化し、階層符号化されたフレームをパケット化して、それぞれの階層に対応する複数のパケットからなるパケット群を生成し、生成されたパケット群のうち、配信先より指定された階層に対応するパケットをネットワークに供給する動画配信装置における配信方法であって、
(b)符号化部が、動画入力装置より供給された動画データを、主制御部より供給される制御パラメータに基づいて、フレームを単位として階層符号化し、制御パラメータにより指定されているバッファ部に供給し、
(c)パケット化部が、主制御部の制御に基づいて、バッファ部に記憶されているデータ(符号化部により階層符号化されたフレームのデータ)を解析して、プログレッシブの階層毎にデータ区切りを検出して、同一の階層毎にパケット化し、それぞれの階層に対応する複数のパケットからなるパケット群を生成し、これらのパケットのそれぞれに、各階層に対応する識別子を表すフラグをそれぞれ付与し、さらに、パケットをIPパケットにし、識別子に対応する優先度を示すフラグをIPパケットのヘッダにつけ直し、通信部に供給し、
(d)通信部が、各受信端末からネットワークを介して供給されてくる受信レポートを、それぞれネットワーク監視・解析部に供給し、ここで、受信レポートは、送信側が、一定時間毎に、送出RTPパケット数やタイムスタンプ情報等の情報、いわゆる「送信レポート」を受信側にパケットとして送信し、受信側が、この「送信レポート」に基づいて、送信側にRTPパケットの紛失率、紛失パケット数、受信した最大シーケンス番号、および到着間隔ジッタ等を含む情報、いわゆる「受信レポート」を返信することにより得られるものであり、
(e)ネットワーク監視・解析部が、供給されたこれらの各受信端末に対応する受信レポートに基づいて、ネットワークの輻輳状態を判定し、さらにその判定結果に基づいて、符号化部の符号化のレートを下げたり、送信フレーム数を下げたりさせるための制御に必要な各受信端末毎の情報を主制御部へそれぞれ供給し、
(f)主制御部が、供給された各受信端末毎のこれらの情報のうち、所定の受信端末に対応する情報等に基づいて、その所定の受信端末に対応する制御パラメータを生成し、符号化部に供給するとともに、各プログレッシブ毎に、上述した識別子に対応したIPの優先度を設定し、パケット化部にそれぞれ供給し、
(g)通信部が、主制御部の制御に基づいて、供給されたパケット群のうち、主制御部より指示されたパケットを、ネットワークに送信し、
(h)ネットワークに供給されたIPパケットは、配信先がユーザ端末15aであった場合、例えば、ダイアルアップサービスを提供するサービスプロバイダのネットワークを介してユーザ端末15aに、送信先が15bであった場合、例えば、ADSL(Asymmetrical Digital Subscriber Line)を使ったサービスプロバイダのネットワークを介してユーザ端末15bに、配信先がユーザ端末15cであった場合、例えば、無線ネットワークにより基地局を介して移動端末(携帯電話機等の端末)であるユーザ端末15cに、それぞれ供給(配信)される
(a)配信方法。

イ 引用文献2に記載された技術
上記(1)イ(ア)、(イ)によれば、引用文献2には、以下の技術(以下、「文献2技術」という。)が記載されていると認められる。

(文献2技術)
「データ送信装置において、IPｖ6のヘッダに優先情報格納フィールドがあり、IPｖ6の優先情報は、混雑制御タイプ(congestion-controlled)と、混雑非制御タイプ(Non-congestion-controlled)とがあり、混雑非制御タイプ(Non-congestion-controlled)は、リアルタイム性を要求されるサービスで利用され、8?15までの優先順位が設定され、優先順位の低いもの(eｘ.優先度8)には狭い帯域を設定し、高いもの(eｘ.優先度15)には広い帯域を設定する技術。」

(3)対比
本願発明と、引用発明を対比する。

ア 構成Aについて
引用発明の「符号化部」(構成b)、「パケット化部」(構成c)、「ネットワーク監視・解析部」(構成e)、「主制御部」(構成f)は、動画のデータの符号化に関する処理を行うものであり、動画のデータの符号化に関する処理はアプリケーションといえるから、これらの構成は、「アプリケーション階層」といえる。

また、引用発明の「通信部」(構成d、構成g)は、パケットの送信に関する処理を行うものであり、当該パケットの送信に関する処理は、上述した「アプリケーション階層」における処理よりも下位の階層の処理といえるから、「通信部」は、「下位階層」といえる。

また、構成aの「動画配信装置」は、以上の構成を含むものであり、「一つのエンティティー」といえる。

また、引用発明では、「通信部」が「受信レポート」を「ネットワーク監視・解析部」に供給し(構成d)、「パケット化部」が「優先度を示すフラグ」をヘッダにつけた「パケット」を「通信部」に供給する(構成c)から、「下位階層」に相当する「通信部」と、「アプリケーション階層」に相当する「ネットワーク監視・解析部」及び「パケット化部」の間には、両者を接続する「インターフェース」が存在しているといえ、引用発明は、「下位階層とアプリケーション階層を接続するインターフェース」に基づくものといえる。

また、引用発明は、「供給された動画のデータを階層符号化し、階層符号化されたフレームをパケット化して、それぞれの階層に対応する複数のパケットからなるパケット群を生成し、生成されたパケット群のうち、配信先より指定された階層に対応するパケットをネットワークに供給する」(構成a)から、「マルチメディアデータを送信する」ものといえる。

よって、本願発明と引用発明は、「下位階層とアプリケーション階層を含む一つのエンティティーで前記下位階層と前記アプリケーション階層を接続するインターフェースに基づいて、マルチメディアデータを送信する方法」である点で共通する。

イ 構成Bについて
引用発明の構成dの「受信レポート」は、「RTPパケットの紛失率、紛失パケット数、受信した最大シーケンス番号、および到着間隔ジッタ等を含む情報」(構成d)であり、構成eの「ネットワーク監視・解析部」は、「各受信端末に対応する受信レポートに基づいて、ネットワークの輻輳状態を判定」する(構成e)から、「受信レポート」は「ネットワークチャネル状態情報」といえる。

また、引用発明は、構成dの「通信部」が、「受信レポート」を「ネットワーク監視・解析部」に供給する(構成d)ものである。
また、上記アのとおり、「通信部」は「下位階層」といえ、「ネットワーク監視・解析部」は「アプリケーション階層」といえ、「通信部」と「ネットワーク監視・解析部」の間には、「インターフェース」が存在しているといえる。
また、「下位階層」である「通信部」から、「アプリケーション階層」である「ネットワーク監視・解析部」に情報を供給することは、情報の伝達方向を考慮すると、「ボトムアップ式情報として提供する」ことといえる。
よって、引用発明は、「前記下位階層」から「前記アプリケーション階層」に「ネットワークチャネル状態情報」を「前記インターフェース」を通して「ボトムアップ式情報」として提供するといえる。

また、引用発明の構成dの「受信レポート」は、「送信側が、一定時間毎に、送出RTPパケット数やタイムスタンプ情報等の情報、いわゆる「送信レポート」を受信側にパケットとして送信し、受信側が、この「送信レポート」に基づいて、送信側にRTPパケットの紛失率、紛失パケット数、受信した最大シーケンス番号、および到着間隔ジッタ等を含む情報、いわゆる「受信レポート」を返信することにより得られる」(構成d)から、「周期的又は非周期的」な情報といえる。

よって、本願発明と引用発明は、「前記下位階層から前記アプリケーション階層にネットワークチャネル状態情報を前記インターフェースを通して周期的又は非周期的なボトムアップ式情報として提供するステップ」を含む点で共通する。
ただし、「ボトムアップ式情報」が、本願発明では、「(ボトムアップネットワーク抽象化階層(B-NAL)情報)」であるのに対し、引用発明では、そうであるか不明な点で、両発明は相違する。

ウ 構成Cについて
引用発明の構成cの「優先度を示すフラグ」は、「階層符号化されたフレームのデータ」の「各階層に対応する識別子」に対応したものであり、「階層符号化されたフレームのデータ」の「階層」は、メディアの特性を表し、メディアのデータに関連したものといえるから、「優先度を示すフラグ」は、「メディア特性に対する情報(メディアデータに関連する情報)」であるといえる。

また、引用発明の構成cの「パケット化部」は、「優先度を示すフラグ」をヘッダにつけた「パケット」を「通信部」に供給する(構成c)ものである。
また、上記アのとおり、「パケット化部」は、「アプリケーション階層」といえ、「通信部」は「下位階層」といえ、「パケット化部」と「通信部」の間には、「インターフェース」が存在しているといえる。
また、「アプリケーション階層」である「パケット化部」から、「下位階層」である「通信部」に情報を供給することは、情報の伝達方向を考慮すると、「トップダウン式情報として提供する」ことといえる。
したがって、引用発明は、「前記アプリケーション階層から前記下位階層にメディア特性に対する情報(メディアデータに関連する情報)を前記インターフェースを通してトップダウン式情報として提供する」といえる。

よって、本願発明と引用発明は、「前記アプリケーション階層から前記下位階層にメディア特性に対する情報(メディアデータに関連する情報)を前記インターフェースを通してトップダウン式情報として提供するステップ」を含む点で一致する。

エ 構成Dについて
引用発明の構成cの「パケット化部」は、「階層符号化されたフレームのデータ」を「パケット」とし、「優先度を示すフラグ」をヘッダにつけた「パケット」を「通信部」に供給し(構成c)、構成gの「通信部」は、「供給されたパケット群のうち、主制御部より指示されたパケットを、ネットワークに送信」する(構成g)ものであり、「階層符号化されたフレームのデータ」の「パケット」は「マルチメディアデータ」といえる。
また、上記ウのとおり、構成cの「優先度を示すフラグ」は、「前記下位階層から前記トップダウン式情報として提供される前記メディア特性に対する情報」といえる。
したがって、構成gの「通信部」は、「前記下位階層から前記トップダウン式情報として提供される前記メディア特性に対する情報に基づいてマルチメディアデータを送信する」といえる。

よって、本願発明と引用発明は、「前記下位階層から前記トップダウン式情報として提供される前記メディア特性に対する情報に基づいてマルチメディアデータを送信するステップ」を含む点で一致する。

オ 構成Eについて
引用発明の構成cの「優先度を示すフラグ」は、「階層符号化されたフレームのデータ」の「各階層に対応する識別子」に対応したものである。
そして、「階層符号化されたフレームのデータ」の「各階層」は、それぞれの「品質」を有するものであることは明らかであり、構成cの「優先度を示すフラグ」により「階層符号化されたフレームのデータ」の「階層」を識別できるのであるから、構成cの「優先度を示すフラグ」は、「下位階層でサポートするサービス品質を識別するために使用されるレベル情報」といえる。
また、上記ウのとおり、構成cの「優先度を示すフラグ」は、「前記トップダウン式情報として提供される前記メディア特性に対する情報」といえる。

よって、本願発明と引用発明は、「前記トップダウン式情報として提供される前記メディア特性に対する情報は、前記下位階層でサポートするサービス品質を識別するために使用されるレベル情報を含む」点で共通する。
ただし、「レベル情報」が、本願発明では、「リソース割り当て又は前記下位階層でサポートするサービス品質を識別するために使用される」のに対し、引用発明では、「前記下位階層でサポートするサービス品質を識別するために使用される」ものの、「リソース割り当て」には使用されない点で、両発明は相違する。

カ 構成Fについて
引用発明では、「ネットワークに供給されたIPパケット」は、「ダイアルアップサービスを提供するサービスプロバイダのネットワーク」を介した「ユーザ端末15a」や、「ADSL(Asymmetrical Digital Subscriber Line)を使ったサービスプロバイダのネットワーク」介した「ユーザ端末15b」、「無線ネットワークにより基地局」を介した「移動端末(携帯電話機等の端末)であるユーザ端末15c」にそれぞれ供給される(構成h)から、引用発明は、「異種ネットワーク環境」で用いられるものといえる。
そして、上記イのとおり、構成dの「受信レポート」は、「前記ボトムアップ式情報として提供される前記ネットワークチャネル状態情報」といえるから、引用発明では、「前記ボトムアップ式情報として提供される前記ネットワークチャネル状態情報は、異種ネットワーク環境で獲得した情報である」といえる。

よって、本願発明と引用発明は、「前記ボトムアップ式情報として提供される前記ネットワークチャネル状態情報は、異種ネットワーク環境で獲得した情報である」点で一致する。

キ まとめ
以上によれば、本願発明と引用発明の一致点及び相違点は、以下のとおりである。

[一致点]
(A)下位階層とアプリケーション階層を含む一つのエンティティーで前記下位階層と前記アプリケーション階層を接続するインターフェースに基づいて、マルチメディアデータを送信する方法であって、
(B’)前記下位階層から前記アプリケーション階層にネットワークチャネル状態情報を前記インターフェースを通して周期的又は非周期的なボトムアップ式情報として提供するステップと、
(C)前記アプリケーション階層から前記下位階層にメディア特性に対する情報(メディアデータに関連する情報)を前記インターフェースを通してトップダウン式情報として提供するステップと、
(D)前記下位階層から前記トップダウン式情報として提供される前記メディア特性に対する情報に基づいてマルチメディアデータを送信するステップとを含み、
(E’)前記トップダウン式情報として提供される前記メディア特性に対する情報は、前記下位階層でサポートするサービス品質を識別するために使用されるレベル情報を含み、
(F)前記ボトムアップ式情報として提供される前記ネットワークチャネル状態情報は、異種ネットワーク環境で獲得した情報である
(A)ことを特徴とする方法。

[相違点]
(相違点1)
「ボトムアップ式情報」が、本願発明では、「(ボトムアップネットワーク抽象化階層(B-NAL)情報)」(構成B)であるのに対し、引用発明では、そうであるか不明な点。

(相違点2)
「レベル情報」が、本願発明では、「リソース割り当て又は前記下位階層でサポートするサービス品質を識別するために使用される」(構成E)のに対し、引用発明では、「前記下位階層でサポートするサービス品質を識別するために使用される」ものの、「リソース割り当て」には使用されない点。

(4)判断
ア 相違点1について
周知の動画像符号化規格であるH.264/AVCに見られるように、動画データの符号化を処理するビデオ符号化階層と符号化された情報の伝送及び格納を行う下位階層との間で、ネットワーク抽象化階層(NAL)を定義して用いることは、当業者が普通に行う事項である。
してみれば、下位階層からアプリケーション階層へと伝送する情報を、伝送の方向も考慮して、ボトムアップネットワーク抽象化階層(B-NAL)情報として扱うことに、当業者が困難を要するものとは認められない。

イ 相違点2について
上記(2)イのとおり、引用文献2に文献2技術が記載されているように、データ送信装置における優先順位の低いものには狭い帯域を設定し、高いものには広い帯域を設定する技術において、IPのヘッダの優先情報(すなわち、レベル情報)を、リソース割り当てに使用することは周知技術である。
したがって、引用発明に当該周知技術を採用して、引用発明の「レベル情報」を「リソース割り当て」にも使用することは、当業者が容易に想到し得ることである。

(5)効果等について
本願発明の構成は、上記のとおり当業者が容易に想到できたものであるところ、本願発明が奏する効果は、その容易想到である構成から当業者が容易に予測し得る範囲内のものであり、同範囲を超える顕著なものではない。

(6)まとめ
以上のように、本願発明は、引用文献1に記載された発明及び周知技術に基いて当業者が容易に発明をすることができたものである。

第4 むすび
以上のとおり、本願の請求項1に係る発明は、発明の詳細な説明に記載したものでないから、本願は、特許法第36条第6項第1号に規定する要件を満たしておらず、特許を受けることができない。

また、仮に、本願の請求項1に係る発明が発明の詳細な説明に記載したものであったとしても、本願発明は、引用文献1に記載された発明及び周知技術に基いて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

したがって、本願は、その余の請求項について検討するまでもなく、拒絶をすべきものである。

よって、結論のとおり審決する。
 
別掲
 
審理終結日 2019-01-31 
結審通知日 2019-02-04 
審決日 2019-02-15 
出願番号 特願2013-550406(P2013-550406)
審決分類 P 1 8・ 537- WZ (H04N)
P 1 8・ 121- WZ (H04N)
P 1 8・ 562- WZ (H04N)
最終処分 不成立  
前審関与審査官 後藤 嘉宏  
特許庁審判長 鳥居 稔
特許庁審判官 坂東 大五郎
樫本 剛
発明の名称 相互階層最適化を用いた、マルチメディアデータパケットを送信する方法及び装置  
代理人 木内 敬二  
代理人 崔 允辰  
代理人 阿部 達彦  
代理人 阿部 達彦  
代理人 実広 信哉  
代理人 実広 信哉  
代理人 崔 允辰  
代理人 木内 敬二  

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