審決検索MVP
← 検索一覧に戻る
特許拒絶査定不服審判

2020-008460

クラスタに基づいた依存信号

審判番号
2020-008460
法域
特許
審判種別
拒絶査定不服審判(拒絶査定不服の審決)
出願番号
特願2018-121752
請求日
2020年06月18日
審決日
2022年03月31日
公報発行日
2022年09月30日
結論
請求不成立
当事者
  • 【請求人】ジーイー ビデオ コンプレッション エルエルシー
  • 【請求人代理人】岡田 全啓
審判長/審判官
  • 審判長 清水 正一
  • 審判官 川崎 優
  • 審判官 千葉 輝久
分類
P18 .537-WZ (H04N)
根拠条文(結論部分から自動抽出・参考)
行政事件訴訟法46条特許法36条1項特許法36条6項
条文(本文から自動抽出・参考)
特許法第36条第6項第1号、特許法第36条第6項
データ出所
審決公報(XML)

事件の表示

特願2018-121752「クラスタに基づいた依存信号」拒絶査定不服審判事件〔平成30年11月22日出願公開、特開2018-186529〕について、次のとおり審決する。

結論

結 論 本件審判の請求は、成り立たない。

理由

理 由 第1 手続の経緯 本願は、2014年7月15日(パリ条約による優先権主張 外国庁受理 2013年7月15日 (US)アメリカ合衆国)を国際出願日とする特願2016-526588号の一部を平成30年6月27日に新たな特許出願としたものであって、その手続の経緯は以下のとおりである。 平成30年 7月27日 :手続補正 令和 1年 6月26日付け:拒絶理由通知 2年 1月 9日 :意見書提出および手続補正 同年 2月 7日付け:拒絶査定 同年 6月18日 :拒絶査定不服審判請求および手続補正 同年 7月 9日 :前置報告 3年 7月30日付け:当審拒絶理由通知 4年 2月 3日 :意見書提出および手続補正 第2 本件補正発明について 特許請求の範囲の請求項1に係る発明(以下、本件補正発明1という)は、令和4年2月3日付の手続補正(以下、本件補正という)により補正された特許請求の範囲の請求項1に記載された、以下のとおりのものである。(下線は補正箇所を示す。また、符号A~F1は請求項の記載を分説するため当審で付したものであり、請求項1の記載を、符号A~F1を用いて、以下、「発明特定事項A」~「発明特定事項F1」と称する。以下同様。) 「【請求項1】 A 相互層予測を使用して、異なる情報量レベルに対応する異なる層でビデオ素材が符号化されている、多層データストリーム(10)を処理するように構成された装置であって、 B 前記多層データストリームは、前記異なる層の1つと関連する複数のパケット(12)のそれぞれを含み、 B1 それぞれの層はベース層ID(20)、または、ベース層ID(20)および拡張層ID(22)によって索引を付けられる装置であって、 (A) 前記装置は、 C 前記ベース層ID(20)によって表現できる、i<jである異なる値iおよびjのペアのそれぞれについて、 C1 一方の層がベース層IDiを有し、もう一方の層がベース層IDjを有するとともにベース層IDiを有する層に依存する、層のペアが少なくとも1つ存在するかを示す第1相互依存構文構造(24)を前記多層データストリームから読み取り、 D1’ 一方の層がベース層IDiを有し、もう一方の層がベース層IDjを有するとともにベース層IDiを有する層に依存する、層のペアが少なくとも1つ存在することを前記第1相互依存構文構造が示す、 D’ それぞれのペア(i,j)について、 E 前記拡張層ID(22)によって表現できる、値pおよびqのペアのそれぞれについて、 E1’ ベース層IDjおよび拡張層qを有する層が、ベース層IDiおよび拡張層pを有する層に依存するかを示す第2相互依存構文構造(26)のインスタンス化を、前記多層データストリームから読み取り、 F 前記第1相互依存構文構造および前記第2相互依存構文構造の前記インスタンス化に基づいて、 F1 前記異なる層間の可能な相互層予測依存を明らかにする相互層依存記述(14)を構築するように構成されていること A を特徴とする装置。」 第3 当審拒絶理由通知 令和3年7月30日付け拒絶理由通知における当審の拒絶理由のうち、理由1は以下のとおりである。(なお、下線は当審で付したものである。以下同じ。) 「1.(サポート要件)本件出願は、特許請求の範囲が下記の点で特許法第36条第6項第1号に規定する要件を満たしていない。 記 令和2年6月18日付け手続補正書により補正された特許請求の範囲の請求項1は以下のとおり記載されている。 「【請求項1】 A 相互層予測を使用して、異なる情報量レベルに対応する異なる層でビデオ素材が符号化されている、多層データストリーム(10)を処理するように構成された装置であって、 B 前記多層データストリームは、前記異なる層の1つと関連する複数のパケット(12)のそれぞれを含み、 B1 それぞれの層はベース層ID(20)、または、ベース層ID(20)および拡張層ID(22)によって索引を付けられる装置であって、 (A) 前記装置は、 C 前記ベース層ID(20)によって表現できる、i<jである異なる値iおよびjのペアのそれぞれについて、 C1 一方の層がベース層IDiを有し、もう一方の層がベース層IDjを有するとともにベース層IDiを有する層に依存する、層のペアが少なくとも1つ存在するかを示す第1相互依存構文構造(24)を前記多層データストリームから読み取り、 D1 一方の層がベース層IDiを有し、もう一方の層がベース層IDkを有するとともにベース層IDiを有する層に依存する、層のペアが少なくとも1つ存在することを前記第1相互依存構文構造が示す、 D それぞれのペア(j,k)について、 E 前記拡張層ID(22)によって表現できる、値pおよびqのペアのそれぞれについて、 E1 ベース層IDkおよび拡張層qを有する層が、ベース層IDiおよび拡張層pを有する層に依存するかを示す第2相互依存構文構造(26)のインスタンス化を、前記多層データストリームから読み取り、 F 前記第1相互依存構文構造および前記第2相互依存構文構造の前記インスタンス化に基づいて、 F1 前記異なる層間の可能な相互層予測依存を明らかにする相互層依存記述(14)を構築するように構成されていること A を特徴とする装置。」 ●理由1(サポート要件)について 当該請求項1に関連する本願の図9、及び明細書の【0055】、【0057】には以下の記載がある。 「【図9】 [図:0001387710000001.jpg] 」 「【0055】 図9の例に従って、第2相互依存構文構造の信号は、第1相互依存構文構造について差し挟まれた方法で、例示的に信号で伝えられる。しかし、この差し挟みは代わりの実施の形態に従って除外される。ともかく、図9の実施の形態において、副マトリクス38または40(すなわち、第2相互依存構文構造26の例示34)は、第1相互依存構文構造24が相互クラスタ依存を標示する(等しい又は等しくない)クラスタIDの個々のペアに対して提出される。構文例から引き出されるように、副マトリクス40の送信は、副マトリクス38より多いビットdirect_ext_dependency_flagを消費する。これは条件条項52と条件条項54からそれぞれ引き出すことができる。すなわち、クラスタ内部の相互依存規則のために第2相互依存構文構造26の例示を送信することにおいて、カウンターiによって示されたリファレンスしているクラスタIDは、カウンターjによって示されたリファレンスされたクラスタIDに等しく、direct_ext_dependency_flagは、エンハンスメント層IDの結合のために、リファレンス及びリファレンスしている層(リファレンスされた層(ここではl)のエンハンスメント層IDが、リファレンスされた層(ここではk)のエンハンスメント層IDのエンハンスメント層IDより小さい)に対してのみ送信される。すなわち、副マトリクス38のdirect_ext_dependency_flagは、副マトリクス38の対角線の下側のポジションに対してのみ送信される。別の場合において、すなわち、相互依存するクラスタペアi≠jのための第2相互依存構文構造26の例示に対して、完全な副マトリクスが送信される。すなわち、フラグdirect_ext_dependency_flagが、副マトリクス40のそれぞれのポジション毎に送信される。 ・・・ 【0057】 言い換えると、図9について説明したように、第2相互依存構文構造26の複数の例示34は、多層データストリームから、つまり、ベース層IDによって表現できる数値であるNである値が0<k≦j≦n<Nのペア(j、k)に対して読み取られる。nはNに等しいように設定される。しかし、また、ここに説明されるように、実際に使われたクラスタ濃度の明示的な信号は、送信オーバーヘッドを制限するために使われる。ペア(j、k)は詳察されて(図9の符号24でiとjに亘るループを見てください)、そして、第2相互依存構文構造を読み取ることが、このペア間の相互依存の存在または不存在を示している第1相互依存構文構造に条件付きで依存しているペア(j、k)に対して実行される又は抑制される(図9の「if(direct_dependency_flag[i][j])」を見てください、ここで、i、jはjとkにそれぞれ一致する)。j=kであるペア(j、k)に対して読み取る第2相互依存構文構造26の例示34は、ベース層IDがjである層のうちのどの層が、ベース層IDがjである層のうちの別の層に依存する相互層予測であることを示す。j>kである異なる値のペア(j、k)に対して読み取る第2相互依存構文構造26の例示34は、ベース層IDがjである層のうちどの層が、ベース層IDがkである層のうちのどの層に依存する相互層予測であることを示す。しかし、図7と同様に、第2相互依存構文構造26の1つの例示が、多層データストリームから読み取られることもある。第2相互依存構文構造26の1つの例示は、個々のクラスタ値ペア(j、j)に対して、共通して示す。ベース層IDがjである層のうちの層が、ベース層IDがjである層のうち別の層に依存する相互層予測である。」 これらの記載を総合すると、請求項1の構成C、C1、D、D1は、図9の第1相互依存構文構造24に略対応しているといえる。 ここで、請求項1の構成Cにおけるi、jに関して、これと対応する図9の第1の相互依存構文構造24のforループのインデックスi、jの値について検討する。 インデックスiの値はi=1からvps_max_layer_minus1をとり、これに対応して、インデックスjの値はj=0からj<i+1、またはj=0からj<iのいずれかの値をとるといえる。(なお、図9のlayer_id_ext_len>0?の後は、l(エルの小文字)ではなく1(数字の1)の誤記ではないか?) ここで、図9の第2の相互依存構文構造26は、layer_id_ext_lenが0となる場合、forループのインデックスkは始点としてk=0をとるが、終点条件として、k < 1<<layer_id_ext_len)、すなわちk<0となるから、ループ処理が実質的に行われない。 そうすると、請求項1により特定される発明は、通常layer_id_ext_lenは0より大きい値をとる必要があり、この場合、上記forループのインデックスjはj=0からj<i+1をとることになる。 ところが、請求項1の構成Cにおいては、i<jである異なる値iおよびjとなっていることから、上記の記載とは整合しない。 以上を総合すると、請求項1の構成Cは、発明の詳細な説明に記載されたものではない。 請求項1を引用する請求項2-7、請求項1を多層データストリームを処理するための方法の発明として特定した請求項8、エンコーダという物の発明として特定した請求項9、符号化するための方法として特定した請求項10、請求項8または10を引用し、プログラムという物の発明として特定した請求項11についても同様の拒絶理由がある。」 第4 当審拒絶理由が解消したか否かの検討及び判断 本件補正により補正された本件補正発明1は、令和2年6月18日付け手続補正書により補正された特許請求の範囲の請求項1の構成Cについては補正されておらず、当該構成Cをそのまま有するものである。 そこで、上記第3においても示したが、本件補正発明1の構成Cにおけるi、jに関して、これと対応する図9の第1の相互依存構文構造24のforループのインデックスi、jの値について検討する。 インデックスiの値はi=1からvps_max_layer_minus1をとり、これに対応して、インデックスjの値はj=0からj<i+1、またはj=0からj<iのいずれかの値をとるといえるが、図9の第2の相互依存構文構造26は、layer_id_ext_lenが0となる場合、forループのインデックスkは始点としてk=0をとるが、終点条件として、k < 1<<layer_id_ext_len)、すなわちk<0となるから、ループ処理が実質的に行われない。 そうすると、本件補正発明1は、通常layer_id_ext_lenは0より大きい値をとる必要があり、この場合、上記forループのインデックスjはj=0からj<i+1をとることになる。 ところが、本件補正発明1の構成Cにおいては、i<jである異なる値iおよびjとなっていることから、上記の記載とは整合しない。 以上を総合すると、本件補正発明1の構成Cは、発明の詳細な説明に記載されたものではなく、本件補正発明1もまた発明の詳細な説明に記載されたものではない。 第5 審判請求人の意見書における主張について 審判請求人の令和4年2月3日付け意見書の「D.拒絶理由1(サポート要件)について」における主張について、及び当該主張において引用される本件明細書【0048】並びに「G.参考図」を踏まえて検討する。 (1) 上記意見書の「D.拒絶理由1(サポート要件)について」の主張は以下のとおりである。 「審判官殿は、請求項1の「前記ベース層ID(20)によって表現できる、i<jである異なる値iおよびjのペアのそれぞれについて、一方の層がベース層IDiを有し、もう一方の層がベース層IDjを有するとともにベース層IDiを有する層に依存する、層のペアが少なくとも1つ存在するかを示す第1相互依存構文構造(24)を前記多層データストリームから読み取り」との特徴の「i<jである異なる値iおよびjのペア」が明細書、とりわけ明細書段落[0055]および[0057]と合致しないと認定されております。 そこで、審判官殿は、本拒絶理由通知書の<補正の示唆>におきまして、「…本件図9はインデックスiがインデックスjに依存する場合に関するものであるが、本件請求項1の構成C1はこれとは逆にインデックスjがインデックスiに依存することを定義している。 また、本来は、図9に対応する[0055]、[0057]の説明は、インデックスjがインデックスiに依存することを念頭においたものと思慮する。」と述べられております。 さらに、審判官殿は、本拒絶理由通知書の<補正の示唆>におきまして、「このため、本件請求項1の構成C1における定義を残したまま、本件図9の技術的事項に裏付けられるように請求項1を特定するにあたり、本件請求項1の構成Cについて、 ・「i<jである異なる値iおよびj」を「i<j+1」と補正することで、請求項1および請求項1を引用する請求項2-7についての上記理由1を解消することができる。」と述べられております。 ここで、繰り返しになりますが、審判請求書の請求の理由において述べましたように、請求項1の第2段落における「前記ベース層ID(20)によって表現できる、i<jである異なる値iおよびjのペアのそれぞれについて、一方の層がベース層IDiを有し、もう一方の層がベース層IDjを有するとともにベース層IDiを有する層に依存する、層のペアが少なくとも1つ存在するかを示す第1相互依存構文構造(24)を前記多層データストリームから読み取り、…」との記載は、本願の明細書の段落[0048]の記載、ならびに図5の上段のマトリクス36(図5に基づいて作成した「G.参考図」中のクロスハッチングで示している箇所)にも関連しています。 そして、図5のデータストリームから読み取られる第1相互依存構文構造24に見て取れる通り、リファレンスされたクラスタID(請求項1におけるベース層IDi)が縦軸に示され、リファレンスしているクラスタID(請求項1におけるベース層IDj)が横軸に示されています。そうすると、図5の第1相互依存構文構造24において、リファレンスされたクラスタIDiは読み取られた構文構造においてリファレンスしているクラスタIDjよりも小さいこと、すなわち、i<jが明確に図示されています。 審判官殿のご指摘のとおり、本件請求項1の構成C1は図9とは逆にインデックスjがインデックスiに依存することを定義しています。そして、「G.参考図(図5)」と図9に対してインデックスjがインデックスiに依存するように、すなわち、j=1 to …、i=0 to …と逆にすることで、図5と図9の両者に整合したうえで、かつ、i<jが整合します。 従いまして、補正後の請求項1は、発明の詳細な説明に記載されたものと思料いたします。また、補正後の請求項1を引用する請求項2-7、請求項8、請求項9、請求項10および請求項11に記載された発明につきましても発明の詳細な説明に記載されたものと思料いたします。」 (2) また、(1)の主張において引用される本件明細書【0048】と「G.参考図」の記載は以下のとおりである。 「【0048】 0と等しいdirect_dependency_flag[i][j]は、インデックスjである層またはクラスタが、インデックスiである層またはクラスタに対して、直接的なリファレンス層またはリファレンスクラスタではないことを規定する。1と等しいdirect_dependency_flag[i][j]は、インデックスjである層またはクラスタが、インデックスiである層又はリファレンスクラスタに対して、直接的なリファレンス層又はリファレンスクラスタであることを規定する。direct_dependency_flag[i][j]が、0からvps_max_layers_minus1の範囲内で、iとjに対して存在しないとき、それは0に等しいと推定される。 注記:仮に、layer_id_ext_lenが0より大きければ、direct_dependency_flag[i][j]は、クラスタ間の依存を信号で伝える。そうでなければ(layer_id_ext_lenが0と等しいならば)、direct_dependency_flag[i][j]は、層のための依存を信号で伝える。」 「G.参考図 [図:0001387710000002.jpg] 」 (3)そこで、本件明細書の【0048】及び上記「G.参考図」を踏まえた(1)の意見書の主張について検討する。 「前記ベース層ID(20)によって表現できる、i<jである異なる値iおよびjのペアのそれぞれについて、一方の層がベース層IDiを有し、もう一方の層がベース層IDjを有するとともにベース層IDiを有する層に依存する、層のペアが少なくとも1つ存在するかを示す第1相互依存構文構造(24)を前記多層データストリームから読み取り、…」との記載、すなわち構成CおよびC1、について、本件明細書の【0048】の記載に関連する旨の主張がある。 ここで、【0048】について検討すると、direct_dependency_flagが構成CおよびC1の第1相互依存構文に対応することは理解できるものの、【0048】には、上記拒絶理由通知において示した理由1を解消するに足る記載は存在しない。 次に、図5の上段のマトリクス36(図5に基づいて作成した「G.参考図」中のクロスハッチングで示している箇所)について検討する。 上記参考図は、審判請求人が審判請求時及び上記意見書提出時に、本件の図5に対してクロスハッチングを書き加えたものであって、当該参考図自体は本件明細書には記載されていない。 そこで、図5に関連する本件明細書中の記載についてさらに検討すると、本件明細書【0034】~【0037】には図5に関連して以下の記載がある。 「【0034】 上に既に記述したように、第1相互依存構文構成24および第2相互依存構文構成26は、ハイレベルパケット216内の情報214によって構成される(図2と比較してください)。図5は、第1相互依存構文構造24が符号36で描かれた層クラスタの間の相互依存を明らかにする例を説明する。例えば、ベース層ID2を持つクラスタは、ベース層ID2および1を持つクラスタに依存する。 【0035】 また、第2相互依存構文構造の第1例示34は、データストリームの中に存在し、副マトリクス38の形式で図5の中に描かれた層の間の内部クラスタ依存を調節する。さらに、図5の例に従って、データストリームは、また、異なるクラスタの層の層状相互依存を調節する第2相互依存構文構造26の例示34を含む。特に、第2例示は、リファレンスされたクラスタのエンハンスメント層ID当たり1つの行、および、リファレンスしているクラスタのエンハンスメント層ID当たり1つの列を持っている副マトリクス40を介して、異なるクラスタの層間の依存を説明する。 【0036】 図5の例において、副マトリクス38は、マトリクス36がクラスタ間の相互依存を示す個々の位置(すなわち、1が置かれる個々の位置)に置かれ、そのクラスタは同じベース層IDのクラスタ(すなわち、マトリクス36の対角線上にあるクラスタ)である。そして、副マトリクス40は、マトリクス36が異なるベース層IDのクラスタ間の相互依存を「1」で示す位置に置かれる。結果は符号42で示される。 【0037】 マトリクス42などのマトリクスを介する相互層依存の説明が、相互層依存を説明するための単なる1つの例であることは注意すべきである。別の説明が同様に使われうる。マトリクス36~40が第1および第2相互依存構文構造によって符号化される方法は、次の通りである。第1相互依存構文構造24は、対角線の下でかつ対角線を含むマトリクス36の各係数に対して、2進値を信号で伝える。マトリクス38を標示する第2相互依存構文構造26の例示34は、対角線の下でかつ対角線を含むマトリクス38の各係数に対して、2進値を信号で伝える。マトリクス40を標示する第2相互依存構文構造26の例示34は、マトリクス40の全ての係数に対して、2進値を信号で伝える。」 本件明細書の上記箇所以外には図5に関連する記載は見当たらない。 ここで、【0037】の「第1相互依存構文構造24は、対角線の下でかつ対角線を含むマトリクス36の各係数に対して、2進値を信号で伝える。」という記載について検討すると、当該下線部の記載はGの参考図のクロスハッチングの領域を示すものではなく、むしろ、マトリクス36のうち、対角線上を含む、下記のような数字0または1が○で囲まれた矩形領域を指すものである。 [図:0001387710000003.jpg] すなわち、明細書に裏付けられているのは、図5のマトリクス36のうち、対角線上を含む、上記の数字0または1が○で囲まれた矩形領域であって、Gの参考図におけるクロスハッチングの領域ではない。 そして、請求項1の構成Cの「i<jである異なる値iおよびj」という条件は、マトリクス36上の対角線上の領域、すなわちi=jとなる当該矩形領域、を含まないという条件であり、図5のマトリクス36やこれに関連する本件明細書【0034】~【0037】から導き出させるものではない。 以上を総合すると、本件補正発明1の構成Cは発明の詳細な説明に記載されたものではない。 第5 むすび 以上のとおり、本件補正発明1は、発明の詳細な説明には記載されておらず、本件出願は特許法第36条第6項第1項に規定する要件を満たしていない。 したがって、本件出願は、拒絶をすべきものである。

審決本文(J-PlatPat)

J-PlatPatの審決検索トップを開きます。番号入力で「審判番号」を選び、下の番号を貼り付けて検索してください。

J-PlatPat 審決検索を開く
2020-008460

番号・当事者・条文・審決分類・商標の称呼が一致(または近い)審決を機械的に集めた候補です。判断内容は各審決の本文でご確認ください。

同じ当事者の審決21件(ジーイー ビデオ コンプレッション エルエルシー)
  • 2023-018260拒絶査定不服審判 / 2025-08-15 / 原査定取消(特許/登録すべき)マルチレイヤ・ビデオ符号化における低遅延コンセプト
    同じ当事者: ジーイー ビデオ コンプレッション エルエルシー
  • 2021-007901拒絶査定不服審判 / 2022-11-28 / 原査定取消(特許/登録すべき)デプスマップの推定および更新を用いる効率的なマルチビュー符号化
    同じ当事者: ジーイー ビデオ コンプレッション エルエルシー
  • 2018-016433拒絶査定不服審判 / 2021-03-24 / 原査定取消(特許/登録すべき)パーティション符号化を用いた有効な予測
    同じ当事者: ジーイー ビデオ コンプレッション エルエルシー
  • 2018-010654拒絶査定不服審判 / 2020-10-26 / 原査定取消(特許/登録すべき)並列処理を許容している符号化概念、トランスポートデマルチプレクサおよびビデオビッ…
    同じ当事者: ジーイー ビデオ コンプレッション エルエルシー
  • 2018-000079拒絶査定不服審判 / 2020-10-23 / 原査定取消(特許/登録すべき)ブロック分割及びブロック統合をサポートする画像符号化
    同じ当事者: ジーイー ビデオ コンプレッション エルエルシー
検索でもっと見る →
同じ論点・分野の審決(審決分類)721件(537・H04N)
  • 2024-019403拒絶査定不服審判 / 2026-08-18 / 原査定取消(特許/登録すべき)撮像装置およびその設定画面
    共通の審決分類: 537・H04N
  • 2025-014340拒絶査定不服審判 / 2026-08-04 / 原査定取消(特許/登録すべき)自律型ゴルフ競技会システムおよび方法
    共通の審決分類: 537・H04N
  • 2025-014869拒絶査定不服審判 / 2026-08-04 / 原査定取消(特許/登録すべき)自律型ゴルフ競技会システムおよび方法
    共通の審決分類: 537・H04N
  • 2025-018783拒絶査定不服審判 / 2026-07-24 / 原査定取消(特許/登録すべき)セキュリティシステム及びセキュリティシステム用プログラム
    共通の審決分類: 537・H04N
  • 2024-015845拒絶査定不服審判 / 2026-07-07 / 原査定取消(特許/登録すべき)情報処理システム、及び処理方法
    共通の審決分類: 537・H04N

メモ・タグ(非公開)

あなただけに表示されます。審決本文の公開範囲は変わりません。

メモとタグは Pro の機能です。ログイン/Proでメモを保存