2023-011365

特願２０２１－５１７４４３「動きベクトル圧縮方法、プログラム、エンコーダ及びデコーダ」拒絶査定不服審判事件〔令和 ２年 ７月 ２日国際公開、ＷＯ２０２０／１３９１７２、令和 ４年 ２月１７日特許出願公表、特表２０２２－５１５００３〕について、次のとおり審決する。

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

理 由 第１ 手続の経緯 本願は、２０１９年（令和元年）１２月２７日（パリ条約による優先権主張 ２０１８年１２月２９日 （ＵＳ）アメリカ合衆国、２０１８年１２月２９日 （ＵＳ）アメリカ合衆国）を国際出願日とする出願であって、その手続きの経緯は以下のとおりである。 令和４年 ６月２８日付け：拒絶理由の通知 同年 ９月２７日 ：手続補正書及び意見書の提出 同年１０月１１日付け：拒絶理由の通知 令和５年 １月 ６日 ：意見書の提出 同年 ２月２７日付け：拒絶査定 同年 ７月 ６日 ：審判請求書及び手続補正書の提出 同年 ８月 ４日付け：前置報告 同年１０月１３日 ：上申書の提出 令和６年 ９月３０日付け：拒絶理由の通知（当審） 同年１２月２０日 ：手続補正書及び意見書の提出 第２ 本願発明について 本願の請求項１ないし１７に係る発明は、令和６年１２月２０日に提出された手続補正書による手続補正により補正された特許請求の範囲の請求項１ないし１７に記載された事項により特定されるものと認められるところ、その請求項１に係る発明（以下「本願発明」という。）は、以下のとおりのものである。 ここで、記号「Ａ」から「Ｅ」は、分説するために当審が付したものであり、記号「Ａ」から「Ｅ」に対応する発明特定事項を、以下「構成Ａ」から「構成Ｅ」という。 「Ａ 時間的な動きベクトルを取得する段階と、 Ｂ 前記時間的な動きベクトルの二進表現を用いて圧縮された動きベクトルを決定する段階であって、前記圧縮された動きベクトルの二進表現が指数部及び仮数部を含み、前記指数部はＮビットを含み、前記仮数部はＭビットを含み、Ｎは非負の整数であり、Ｍは正の整数であり、前記圧縮された動きベクトルの前記二進表現は、圧縮される前の前記時間的な動きベクトルよりも少なくとも２ビット少ない、段階と、 Ｃ 前記圧縮された動きベクトルを用いて、時間的な動きベクトル予測（ＴＭＶＰ）を実行する段階と、 Ｄ を含む、 Ｅ 動きベクトル圧縮方法。」 第３ 原査定における拒絶の理由 原査定（令和５年２月２７日付け拒絶査定）における拒絶の理由は、概略、「この出願の下記の請求項に係る発明は、その出願の日前の外国語特許出願（特許法第１８４条の４第３項の規定により取り下げられたものとみなされたものを除く。）であって、その出願後に国際公開がされた下記の外国語特許出願の国際出願日における国際出願の明細書、請求の範囲又は図面に記載された発明と同一であり、しかも、この出願の発明者がその出願前の外国語特許出願に係る上記の発明をした者と同一ではなく、またこの出願の時において、その出願人が上記外国語特許出願の出願人と同一でもないので、特許法第２９条の２の規定により、特許を受けることができない（同法第１８４条の１３参照）。」というものであり、請求項１に係る発明に対して、以下の先願１が引用された。 先願１：ＰＣＴ／ＫＲ２０１９／００３２５１号、特願２０２０－５５４２６１号（国際公開第２０１９／１９４４３６号、特表２０２１－５１８０８４号公報） 第４ 先願発明及び技術常識 １ 先願発明 （１） 先願明細書等に記載された事項 原査定の拒絶の理由で引用され、本願優先日前の２０１８年４月２日及び２０１８年５月１日を優先日とし、本願の出願の日前の２０１９年３月２０日を国際出願日とする国際特許出願（ＰＣＴ／ＫＲ２０１９／００３２５１）であって、本願の優先日後の２０１９年１０月１０日に国際公開（国際公開第２０１９／１９４４３６号）され、その後、特許法第１８４条の４第１項に規定する翻訳文が提出された外国語特許出願である特願２０２０－５５４２６１号（以下、「先願」という。）の国際出願日における明細書、特許請求の範囲又は図面（以下、「先願明細書等」という。）には、以下の事項が記載されている。ここで、先願の発明者はPALURI, Seethal（シータル パルリ）、及びKIM, Seunghwan（キム スンファン）であって本願発明者と同一の者でなく、かつ、本願出願の時における先願の出願人はLG ELECTRONICS INC.（エルジー エレクトロニクス インコーポレイティド）であり、本願出願人とは異なる。（先願は韓国語で記載されているので、当審仮訳として特表２０２１－５１８０８４号公報の記載を援用し、当該公報の段落番号を【】付き数字で示した。また、下線は当審で付したものであり、以下、同様。） ア 「 ［図：0001426245000001.jpg］ ［図：0001426245000002.jpg］ ［図：0001426245000003.jpg］ ［図：0001426245000004.jpg］ 」 （当審仮訳： 【００７４】 ［８３］ 一実施例において、ＴＭＶＰは、エンコード装置１００またはデコード装置２００のインター予測において、ＭＶＰ候補またはマージ候補として含まれることができる。より具体的には、デコード装置２００は、現ブロックの空間的隣接ブロックおよび／または時間的隣接ブロックに基づいて動き情報候補リスト（例えば、ＭＶＰ候補リスト）を導出することができ、受信した選択情報（例えば、ｍｅｒｇｅ ｉｎｄｅｘ、ＭＶＰフラグまたはＭＶＰインデックス）に基づいて上記動き情報候補リストに含まれている候補の中から一つを選択することができ、上記選択された候補に基づいて上記現ブロックの動き情報を導出することができる。デコード装置２００は、上記導出された動き情報に基づいて予測サンプルを生成することができる。ここで、例えば、デコード装置２００は、上記選択された候補を上記現ブロックのＭＶＰとして導出することができる。また、上記時間的隣接ブロックは、上記現ブロックに対応する参照ピクチャ内のｃｏｌｌｏｃａｔｅｄ ｂｌｏｃｋを示すことができ、ＴＭＶＰ ｍｅｔｈｏｄは、上記時間的隣接ブロック（collocated block）の動きベクトルを上記動き情報候補リストの時間的候補（temporal candidate）として導出し、上記ｃｏｌｌｏｃａｔｅｄ ｂｌｏｃｋの動きベクトルから導出された時間的候補を上記現ブロックのＭＶＰとして使用する方法を示すことができる。 【００７５】 ［８４］ 図３を参照すると、ＴＭＶＰでは、現ブロックの右（上）下端（Right-bottom）位置に該当する参照ピクチャ（reference picture）内のブロックをｃｏｌｌｏｃａｔｅｄブロックＣ０と定義し、該当ブロックの動きベクトルをＭＶＰとして使用することができる。このとき、Ｒｉｇｈｔ-ｂｏｔｔｏｍ位置（Ｃ０）のブロックがイントラ（ＩＮＴＲＡ）予測にのみ利用されることができ、またはピクチャ境界（picture boundary）を外れるなどの理由で使用不可能な場合（unavailable）、現ブロックのＣｅｎｔｅｒ位置（Ｃ１）に対応するブロックがｃｏｌｌｏｃａｔｅｄブロックとして利用されることができる。ここで、ｃｅｎｔｅｒ位置とは、センタ右下側位置を示すことができる。すなわち、上記ｃｅｎｔｅｒ位置は、現ブロックのセンタに４個のサンプルが位置する場合において、上記４個のサンプルのうちの右下側のサンプル位置を示すことができる。一例において、上記ＲＢ位置は、ＣｏｌＢｒと呼ばれることができ、上記Ｃ１位置は、ＣｏｌＣｔｒと呼ばれることができる。一方、ｃｏｌｌｏｃａｔｅｄブロックを含むピクチャは、ｃｏｌｌｏｃａｔｅｄピクチャまたはｃｏｌｌｏｃａｔｅｄフレームという。 【００７６】 ［８５］ 一実施例において、ブロックのサイズが増加する場合、ＴＭＶＰ候補を導出するにあたって、Ｃ０よりＣ１が優先的に考慮されることができる。あるいは、Ｃ０およびＣ１以外の他の位置のｃｏｌｌｏｃａｔｅｄブロックが現ブロックの動き情報をよりよく示す場合、ＴＭＶＰ候補を導出するにあたって、Ｃ０およびＣ１以外の他の位置のｃｏｌｌｏｃａｔｅｄブロックが利用されることができる。） イ 「 ［図：0001426245000005.jpg］ ［図：0001426245000006.jpg］ ［図：0001426245000007.jpg］ ・・・ ［図：0001426245000008.jpg］ ［図：0001426245000009.jpg］ ［図：0001426245000010.jpg］ ［図：0001426245000011.jpg］ ［図：0001426245000012.jpg］ 」 （当審仮訳： 【００８３】 ［９３］ インター予測が実行される間に、各コーディングユニットまたは予測ユニットの動きベクトルがデコードされ、各コーディングユニットまたは予測ユニットに対する動きベクトルフィールド（Motion Vector Field、ＭＶＦ）がアップデートされることができる。ＭＶＦに記憶された情報は、動きベクトル、参照インデックス、リスト情報、予測モード情報などを含むことができる。ＭＶＦに記憶された情報を表現するためにビット（bit）が必要であり、したがって、多数のＭＶＦの動き情報を動きフィールドストレージ（motion field storage）に記憶する場合、動きフィールドストレージに過負荷（overhead）がかかることができる。 【００８４】 ［９４］ 一実施例において、－２15ないし２15－１の範囲の動きベクトルを示すために、例えば、１６個、１８個、２０個のビットなどが利用されることができる。動きベクトルを示すために、必要なビットの個数は、サブペル（sub-pel）の種類によって多様である。より具体的な例において、－２15ないし２15－１の範囲の動きベクトルがクォーターペル（quarter-pel）単位で記憶される場合、１８個のビットが利用されることができる。このとき、動きベクトルの符号を示すために１ビットが利用されることができ、１５桁の二進数を示すために１５個のビットが利用されることができる。本例示の方法に基づいて動きベクトルを示すことを以下で“動きベクトル非圧縮（ノンコンプレッション）（non-compression）”と命名する。 【００８５】 ［９５］ 本発明の一実施例では、動きベクトルを記憶するときに必要なビットの個数を減少させるために、すなわち、動きベクトル圧縮（compression）を増加させるために、１６個より少ない数のビットを利用する方法を提案する。以下、動きベクトルを記憶するときに必要な情報、例えば、ビットの個数を減少させるものを“動きベクトル圧縮（motion vector compression）”という。 ・・・ 【００８７】 ［９７］ 図４の動きベクトル構造（structure）は、スケールファクタ（scale factor）、符号（sign）、および動きデータ（motion data）で構成されている。一実施例において、動きベクトルは、以下の数式１に基づいて導出されることができる。 【００８８】 ［９８］ ［数式１］ ［９９］ ＭＶ＝（Ｓｃａｌｅ Ｆａｃｔｏｒ×Ｍｏｔｉｏｎ Ｄａｔａ）×Ｓｉｇｎ 【００８９】 ［１００］ 数式１において、動きベクトルは、スケールファクタ、符号、および動きデータの積を介して導出されることを確認することができる。 【００９０】 ［１０１］ －２15ないし２15－１の範囲の動きベクトルを示すとき、本発明の一実施例によると、スケールファクタを示すためのビット数であるｓｆ、動きデータを示すためのビット数であるｋ、および符号を示すためのビット数であるｂ＝１は、以下の数式２を満たすことができる。 【００９１】 ［１０２］ ［数式２］ ［１０３］ ｓｆ＋ｋ＋ｂ＜１６） （２） 先願発明の認定 ア 上記（１）アの段落［８３］には、ＴＭＶＰでは、時間的隣接ブロックに基づいて動き情報候補リスト（例えば、ＭＶＰ候補リスト）が導出され、ＴＭＶＰ ｍｅｔｈｏｄは、上記時間的隣接ブロック（collocated block）の動きベクトルを上記動き情報候補リストの時間的候補（temporal candidate）として導出することが記載されている。 そして、当該「時間的隣接ブロック（collocated block）の動きベクトル」を導出に利用する「時間的候補」に関して、段落［８５］に「ＴＭＶＰ候補を導出するにあたって、・・・ｃｏｌｌｏｃａｔｅｄブロックが利用される」と記載されているように、上記「時間的候補」は「ＴＭＶＰ候補」とも称されるから、先願明細書等には、ＴＭＶＰでは、ＴＭＶＰ候補が導出されることが記載されている。 イ 上記（１）イの段落［９３］には、動きベクトルがデコードされ、動きベクトルフィールド（ＭＶＦ）がアップデートされ、ＭＶＦに記憶された情報は、動きベクトル、参照インデックス、リスト情報、予測モード情報を含むことが記載されている。 情報がデコードされ、当該情報の記憶手段をアップデートするにあたっては、当該アップデートの処理にデコードした情報を記憶手段に記憶する処理が含まれることが技術常識であるから、「動きベクトルフィールド（ＭＶＦ）」の上記「アップデート」に、デコードされた動きベクトルを動きベクトルフィールド（ＭＶＦ）に記憶する処理を含むことは明らかである。 また、同段落［９３］には、ＭＶＦに記憶された情報を表現するためにビット（bit）が必要であり、したがって、動きフィールドストレージに過負荷（overhead）がかかることが記載されている。 そうすると、先願明細書等には、動きベクトルがデコードされ、デコードされた動きベクトルが動きベクトルフィールド（ＭＶＦ）に記憶され、ＭＶＦに記憶された情報は、動きベクトル、参照インデックス、リスト情報、予測モード情報を含み、ＭＶＦに記憶された情報を表現するためにビットが必要であり、動きフィールドストレージに過負荷（overhead）がかかることが記載されている。 ウ 上記（１）イの段落［９４］には、－２15ないし２15－１の範囲の動きベクトルを示すために１６個のビットが利用され、本例示の方法に基づいて動きベクトルを示すことを動きベクトル非圧縮と命名することが記載されているから、先願明細書等には、動きベクトル非圧縮の場合に、－２15ないし２15－１の範囲の動きベクトルを示すために１６個のビットが利用されることが記載されている。 エ 上記（１）イの段落［９５］には、動きベクトルを記憶するときに必要なビットの個数を減少させるために、１６個より少ない数のビットを利用する方法を提案すること、及び、動きベクトルを記憶するときに必要な情報、例えば、ビットの個数を減少させるものを動きベクトル圧縮ということが記載されている。 オ 上記（１）イの段落［９７］～［９９］によれば、動きベクトル構造（structure）は、スケールファクタ（scale factor）、符号（sign）、および動きデータ（motion data）で構成され、動きベクトルは、ＭＶ＝（Ｓｃａｌｅ Ｆａｃｔｏｒ×Ｍｏｔｉｏｎ Ｄａｔａ）×Ｓｉｇｎに基づいて導出されるから、動きベクトルは、ＭＶ＝（スケールファクタ×動きデータ）×符号で表されるといえる。 また、上記（１）イの段落［１０１］～［１０３］には、スケールファクタを示すためのビット数であるｓｆ、動きデータを示すためのビット数であるｋ、および符号を示すためのビット数であるｂ＝１は、ｓｆ＋ｋ＋ｂ＜１６を満たすことが記載されており、これは「１６個より少ない数のビットを利用する」ことであるから、上記エを踏まえると、「ＭＶ＝（スケールファクタ×動きデータ）×符号で表される」のは、「動きベクトル圧縮」した場合ということができる。 カ 上記イ～オを総合すると、先願明細書等には、動きベクトル非圧縮の場合に、－２15ないし２15－１の範囲の動きベクトルを示すために１６個のビットが利用され、ビットが必要であり、動きフィールドストレージに過負荷（overhead）がかかることから、動きベクトルを記憶するときに必要なビットの個数を減少させるため、動きベクトル圧縮した場合に、動きベクトルは、ＭＶ＝（スケールファクタ×動きデータ）×符号で表され、スケールファクタを示すためのビット数であるｓｆ、動きデータを示すためのビット数であるｋ、および符号を示すためのビット数であるｂ＝１は、ｓｆ＋ｋ＋ｂ＜１６を満たす方法が記載されている。 キ 以上ア、イ、及びカを総合すると、先願明細書等には、以下の発明（以下、「先願発明」という。）が記載されているものと認める。（記号「ａ」～「ｆ」は、分説するために当審が付したものであり、記号「ａ」～「ｆ」に対応する発明特定事項を、以下「構成ａ」～「構成ｆ」という。） 「ａ ＴＭＶＰでは、ＴＭＶＰ候補が導出され、（ア） ｂ 動きベクトルがデコードされ、デコードされた動きベクトルが動きベクトルフィールド（ＭＶＦ）に記憶され、ＭＶＦに記憶された情報は、動きベクトル、参照インデックス、リスト情報、予測モード情報を含み、（イ） ｃ 動きベクトル非圧縮の場合に、-２15ないし２15-１の範囲の動きベクトルを示すために１６個のビットが利用され、（カ） ｄ ＭＶＦに記憶された情報を表現するためにビットが必要であり、動きフィールドストレージに過負荷（overhead）がかかることから、動きベクトルを記憶するときに必要なビットの個数を減少させるため、動きベクトル圧縮した場合に、動きベクトルは、ＭＶ＝（スケールファクタ×動きデータ）×符号で表され、（カ） ｅ スケールファクタを示すためのビット数であるｓｆ、動きデータを示すためのビット数であるｋ、および符号を示すためのビット数であるｂ＝１は、 ｓｆ＋ｋ＋ｂ＜１６を満たす、（カ） ｆ 方法。」 ２ 先願発明の優先権 （１） 先願の優先権基礎出願に記載された事項 先願は、パリ条約による優先権主張を伴う出願であるところ、本願の最先の優先日である２０１８年１２月２９日より前の２０１８年５月１日に提出された、先願の優先権主張の基礎となる米国仮特許出願（ＵＳ６２／６６５４５６）の明細書又は図面（以下、「先願の優先権基礎出願明細書等」という。）には、次の事項が記載されている。 ア 「1. Introduction 1.1 Title An apparatus for Motion Vector Compression. 1.2 Scope of Invention This disclosure relates to video coding and in particular to limiting the number of bits required to store the motion vectors in the motion vector field. 1.3 Description During inter decoding, the motion vectors of each prediction unit are decoded and the motion vector field (MVF) is updated. The information stored in the field includes motion vectors, reference indices, list information, and prediction mode. This can consume several bits and as a result can be an expensive entity to maintain at the decoder as sufficient memory needs to be allocated during processing. This compounded with the fact that the decoder may need to store several MVFs can result in a significant memory overhead.」 （第２頁第２行～第１５行） （当審仮訳： １． 序論 １．１ タイトル 動きベクトル圧縮のための装置。 １．２ 発明の範囲 本開示は、ビデオコーディングに関し、特に、動きベクトルを動きベクトルフィールドに記憶するのに必要とされるビット数を制限することに関する。 １．３ 説明 インター復号化の間、各予測ユニットの動きベクトルがデコードされ、動きベクトルフィールド（ＭＶＦ）がアップデートされる。フィールドに記憶される情報は、動きベクトル、参照インデックス、リスト情報、予測モードを含む。これは、数ビットを消費し得、結果として、デコーダにおいて処理中に割り当てられる必要がある十分なメモリを維持するために高価なエンティティとなり得る。これは、デコーダがいくつかのＭＶＦを格納する必要があり得るという事実と組み合わされて、かなりのメモリオーバーヘッドをもたらし得る。） イ 「Background To enable temporal motion vector prediction, the collocated reference frame is first deciphered from the slice header. Then, the reference index corresponding to the collocated block is picked from the collocated frame. The motion vectors are then retrieved and stored in a MVF. Therefore,MVF storage requires a significant amount of memory as HEVC stores this motion data at a 16x16 level, while Beyond HEVC stores this data at a 4x4 level.」（第２頁第２２行～第２７行） （当審仮訳： 背景 時間的動きベクトル予測を可能にするために、コロケートされた参照フレームが最初にスライスヘッダから解読される。次に、コロケートされたブロックに対応する参照インデックスが、コロケートされたフレームから選ばれる。動きベクトルが取り出され、ＭＶＦに記憶される。したがって、ＨＥＶＣはこの動きデータを１６×１６レベルで記憶するが、Ｂｅｙｏｎｄ ＨＥＶＣはこのデータを４×４レベルで記憶するので、ＭＶＦストレージはかなりの量のメモリを必要とする。） ウ 「3 Embodiments of this Invention Embodiment 1 Currently, the MVs are stored using 16 bits to facilitate a MV range of -215 to 215 -1, inclusive. In this embodiment, we propose to reduce the number of bits required to store the motion vectors, i.e., increase motion vector compression, such that we may use R < 16 bits to represent the information. This may be achieved in several ways. In one example, a new structure to represent motion can be introduced as shown in Figure 1 below. This structure has the capacity to serve independently, of the motion vector resolution defined a priori for a given system. For example, the motion vector resolution may be quarter-pel (HEVC), one-sixteenth pel (JEM) or otherwise appropriately defined. The new structure introduces a scale factor, a sign bit, and motion data, such that the motion vector, MV may be represented as a product of the entities as shown below: MV = (Scale Factor x Motion Data) x Sign (1) Here, we may choose to restrict the Scale Factor to sf bits, Motion Data to k bits and the Sign information to b = 1 bit such that: sf + k + b < 16 (2) In one example, we may choose sf = 2, k = 5 and b = 1 to represent the motion information. In such a case, the scale factor may be derived as follows:」（第３頁第１行～第１８行） （当審仮訳： ３ 本発明の実施形態 実施形態１ 現在、ＭＶは、両端値を含めて－２１５から２１５－１のＭＶ範囲を容易に扱えるように１６ビットを使用して記憶される。この実施形態では、動きベクトルを記憶するのに必要なビットの個数を減らすこと、すなわち、情報を表すためにＲ＜１６ビットを使用するような動きベクトル圧縮を増加させることを提案する。これはいくつかの方法で達成することができる。一例では、以下の図１に示すように、動きを表す新たな構造を導入することができる。この構造は、所与のシステムに対して先験的に定義された動きベクトル分解能から独立して機能する能力を有する。例えば、動きベクトル解像度は、クォーターペル（ＨＥＶＣ）、１６分の１ペル（ＪＥＭ）、さもなければ適切に定義され得る。 新しい構造は、スケールファクタ、符号ビット、及び動きデータを導入し、その結果、動きベクトルＭＶは、以下に示すようにエンティティの積として表すことができる。 ＭＶ＝（スケールファクタ×動きデータ）×符号 （１） ここで、以下のように、スケールファクタをｓｆビットに、動きデータをｋビットに、符号情報をｂ＝１ビットに制限することを選択してもよい。 ｓｆ＋ｋ＋ｂ＜１６ （２） 一例では、動き情報を表すためにｓｆ＝２、ｋ＝５およびｂ＝１を選択することができる。そのような場合、スケールファクタは以下のように導出され得る。） エ 「Embodiment 2 In one embodiment, we propose to consider a different pixel location within the block during the derivation of the temporal motion vector predictor (TMVP) candidate. Typically, in TMVP, the bottom right comer (CO) or the center index (Cl) is used to compute the collocated neighbor, with CO being preferred over C1. However, when the block size is large, it may be beneficial to consider using (i) Cl over CO or (ii) other pixel locations within the block, while deriving the TMVP predictor, as this may have a higher correlation with the true motion of the block. This can also be extended to incorporate the case when the block shape may be non-square, i.e., rectangular. An example below shows the syntax elements that may be introduced to convey the modified pixel location being used during the TMVP process in the decoder as follows: If the adaptive_pixel_loc_flag is enabled then the decoder expects an index for the adaptive_pix_idx to be parsed. This index may be used to specify the location of the pixel to be used during the TMVP decoding.」（第５頁第５行～第１７行） （当審仮訳： 実施形態２ 一実施形態では、時間的動きベクトル予測子（ＴＭＶＰ）候補の導出中にブロック内の異なる画素位置を考慮することを提案する。典型的には、ＴＭＶＰでは、右下角（ＣＯ）又は中心インデックス（Ｃ１）が、コロケートされたネイバーを計算するために使用され、ＣＯがＣ１よりも好ましい。しかしながら、ブロックサイズが大きいとき、ＴＭＶＰ予測子を導出しながら、（ｉ）ＣＯよりもＣｌ又は（ｉｉ）ブロック内の他のピクセルロケーションを使用することを考慮することが有益であり得る。これは、ブロックの真の動きとのより高い相関を有し得るからである。 これは、ブロック形状が非正方形、すなわち長方形であり得る場合を組み込むように拡張することもできる。以下の例は、以下のように、デコーダにおけるＴＭＶＰプロセス中に使用されている修正されたピクセルロケーションを伝達するために導入され得るシンタックス要素を示す。adaptive_pixel_loc_flagが有効にされる場合、デコーダは、adaptive_pix_idxのためのインデックスが解析されることを予想する。このインデックスは、ＴＭＶＰ復号中に使用されるべきピクセルのロケーションを指定するために使用され得る。） オ 「 ［図：0001426245000013.jpg］ 」（第４頁） （当審仮訳： 表２．０は高レベルシンタックスを示す ［図：0001426245000014.jpg］ ここで、 １に等しいcompress_motion_flagは、ＳＰＳにおいて動き圧縮パラメータが続くことを示す。０に等しいcompress_motion_flagは、動き圧縮パラメータは存在しないことを示す。 num_bits_for_scaling_factorは、スケールファクタに使用されるビット数、すなわち、ｓｆビットを指定する。 num_bits_for_motion_payload_minuskプラスｋは、動きデータを表すために使用されるビット数を指定する。ここで、ｋは予め定められた一定値であってよい。他の例では、ｋはビットストリームにおいてシグナリングされてよい。 sign_bit_infoは、符号情報、すなわち、ｂ＝１ビットを指定する。） （２） 優先権基礎出願に記載された発明 ア 上記（１）エによれば、先願の優先権基礎出願明細書等には、「実施形態２」として「ＴＭＶＰ」に関する事項が記載されている。 そして、「時間的動きベクトル予測子（ＴＭＶＰ）候補の導出」の記載によれば、ＴＭＶＰでは、ＴＭＶＰ候補が導出されるといえる。 イ 上記（１）アによれば、先願の優先権基礎出願明細書等には、動きベクトルがデコードされ、動きベクトルフィールド（ＭＶＦ）がアップデートされ、フィールドに記憶される情報は、動きベクトル、参照インデックス、リスト情報、予測モードを含むことが記載されている。 情報がデコードされた際に、当該情報の記憶手段をアップデートするにあたっては、当該アップデートの処理に、デコードした情報を記憶手段に記憶する処理が含まれることが技術常識であるから、「動きベクトルフィールド（ＭＶＦ）」の上記「アップデート」に、デコードされた動きベクトルを動きベクトルフィールド（ＭＶＦ）に記憶する処理を含むことは明らかである。 また、上記「フィールドに記憶される情報」の「フィールド」が動きベクトルフィールド（ＭＶＦ）を指すことは文脈から明らかである。 そうすると、先願の優先権基礎出願明細書等には、動きベクトルがデコードされ、デコードされた動きベクトルが動きベクトルフィールド（ＭＶＦ）に記憶され、ＭＶＦに記憶される情報は、動きベクトル、参照インデックス、リスト情報、予測モードを含むことが記載されている。 ウ 上記（１）ウによれば、先願の優先権基礎出願明細書等には、現在、ＭＶすなわち動きベクトルは、－２１５から２１５－１のＭＶ範囲を容易に扱えるように１６ビットを使用して記憶されることが記載されている。 また、－２１５から２１５－１の値は、通常の二進数の形式では、符号を含め、１６ビットで表現することが技術常識である。 そうすると、下記エの「動きベクトルを記憶するのに必要なビットの個数を減ら」していない場合であって、下記オの「動き圧縮」していない動きベクトルについては、-２15ないし２15-１の範囲の動きベクトルを示すために１６個のビットが利用されると解される。 エ 上記（１）アには、「フィールド（当審注：ＭＶＦ）に記憶される情報は、動きベクトル・・・を含む。これは、数ビットを消費し得、・・・る。これは、・・・かなりのメモリオーバーヘッドをもたらし得る。」との記載があり、これを受けて上記（１）イの「背景」には「動きベクトルが・・・ＭＶＦに記憶される。したがって、・・・ＭＶＦストレージはかなりの量のメモリを必要とする。」と記載されている。 そして、上記（１）ウによれば、先願の優先権基礎出願明細書等には、当該背景を踏まえて、動きベクトルを記憶するのに必要なビットの個数を減らすこと、すなわち、情報を表すためにＲ＜１６ビットを使用するような動きベクトル圧縮を増加させることを提案することが記載されている。 オ 上記（１）ウによれば、上記エの「提案」について、「これはいくつかの方法で達成することができる」とした上で、「動きを表す新たな構造を導入すること」として、「動きベクトルＭＶは、以下に示すようにエンティティの積として表すことができる」こと、及び、「ＭＶ＝（スケールファクタ×動きデータ）×符号」であることが記載されていることから、先願の優先権基礎出願明細書等には、上記エの「提案」の、動きベクトルを記憶するのに必要なビットの個数を減らすために動きベクトルは、ＭＶ＝（スケールファクタ×動きデータ）×符号で表される方法が記載されている。 そして、上記（１）ウの「以下のように、スケールファクタをｓｆビットに、動きデータをｋビットに、符号情報をｂ＝１ビットに制限する」の記載、及び、式（２）の記載によれば、ｓｆはスケールファクタを示すためのビット数、ｋは動きデータを示すためのビット数、ｂ＝１は、符号を示すためのビット数ということができ、先願の優先権基礎出願明細書等には、ｓｆ＋ｋ＋ｂ＜１６を満たすようにすることが記載されている。 ここで、上記（１）オでは、表２．０の「seq_parameter_set_rbsp()」では、「if(compress_ motion_ flag) {」文により、compress_motion_flagが真（＝１）である場合に、「num_bits_for_scaling_factor」、「num_bits_for_motion_payload_minusk」、「sign_bit_info」の３者が続くシンタックスが示されており、上記（１）オの表２．０についての説明によれば、それら３者は「ｓｆ」、「ｋ」、「ｂ」を指定するパラメータである。 さらに、１に等しいcompress_motion_flagは、動き圧縮パラメータが続くことを示すと説明されていることを踏まると、ｓｆ（スケールファクタを示すためのビット数）、ｋ（動きデータを示すためのビット数）、ｂ（符号を示すためのビット数）は、compress_motion_flagが真（＝１）である場合に示される「動き圧縮パラメータ」であるから、「動き圧縮」した場合に、「動きベクトルは、ＭＶ＝（スケールファクタ×動きデータ）×符号で表される」ということができる。 カ 以上ア～オを総合すると、先願の優先権基礎出願明細書等には、以下の発明が記載されているものと認める。 「ＴＭＶＰでは、ＴＭＶＰ候補が導出され、（ア） 動きベクトルがデコードされ、デコードされた動きベクトルが動きベクトルフィールド（ＭＶＦ）に記憶され、ＭＶＦに記憶される情報は、動きベクトル、参照インデックス、リスト情報、予測モードを含み、（イ） 動き圧縮していない場合に、-２15ないし２15-１の範囲の動きベクトルを示すために１６個のビットが利用され、（ウ） ＭＶＦストレージのメモリオーバーヘッドを背景とし、動きベクトルを記憶するのに必要なビットの個数を減らすため、動き圧縮した場合に、動きベクトルは、ＭＶ＝（スケールファクタ×動きデータ）×符号で表され、（エ、オ） スケールファクタを示すためのビット数であるｓｆ、動きデータを示すためのビット数であるｋ、および符号を示すためのビット数であるｂ＝１は、ｓｆ＋ｋ＋ｂ＜１６を満たす、（オ） 方法。」 ここで、先願の優先権基礎出願明細書等に記載された「ＭＶＦに記憶される情報」、「予測モード」、「動き圧縮していない場合」、「ＭＶＦストレージのメモリオーバーヘッドを背景と」すること、「動きベクトルを記憶するのに必要なビットの個数を減らす」こと、及び、「動き圧縮した場合」は、先願発明の「ＭＶＦに記憶された情報」、「予測モード情報」、「動きベクトル非圧縮の場合」、「ＭＶＦに記憶された情報を表現するためにビットが必要であり、動きフィールドストレージに過負荷（overhead）がかかること」、「動きベクトルを記憶するときに必要なビットの個数を減少させる」こと、及び、「動きベクトル圧縮した場合」にそれぞれ相当する。 すると、先願発明は、先願の優先権基礎出願明細書等にも記載されているから、特許法第２９条の２本文の規定の適用に関しては、先願は、優先権主張の基礎となる米国仮特許出願（ＵＳ６２／６６５４５６）の出願日である２０１８年５月１日に出願がなされたものとして扱う。 ３ 技術常識 （１） 技術常識１ ア 参考文献１ Jianle Chen et al., Algorithm description for Versatile Video Coding and Test Model 2 (VTM 2), Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11, JVET-K1002-v3(version 3)「JVET-K1002-v2.docx」, 2018-10-02, p.1,19（以下「参考文献１」という。）は、 本願の優先日前に公表された第１１回ＪＶＥＴ会議の寄書であり、当該寄書には、以下の記載がある。 「3.4.4 Motion field storage In VTM-2.0, the highest precision of explicitly signalled motion vectors is quarter-luma-sample. In some inter prediction modes such as the affine mode, motion vectors are derived at 1/16th-luma-sample precision and motion compensated prediction is performed at 1/16th-sample-precision. In terms of internal motion field storage, all motion vectors are stored at 1/16th-luma-sample precision. For temporal motion field storage used by TMVP and ATVMP, motion field compression is performed at 8x8 granularity in contrast to the 16x16 granularity in HEVC.」（第１９頁第２５行～第３１行） （当審仮訳： ３．４．４ 動きフィールドストレージ ＶＴＭ－２．０では、明示的にシグナリングされる動きベクトルの最高精度は４分の１ルーマサンプルである。アフィンモードなどのいくつかのインター予測モードでは、動きベクトルは１／１６のルーマサンプル精度で導出され、動き補償予測は１／１６のサンプル精度で実行される。内部動きフィールド記憶に関して、すべての動きベクトルは、１／１６のルーマサンプル精度で記憶される。ＴＭＶＰ及びＡＴＶＭＰによって使用される時間的動きフィールドストレージの場合、動きフィールド圧縮は、ＨＥＶＣにおける１６×１６粒度とは対照的に、８×８粒度で実行される。） イ 参考文献２ 本願の優先日前に公開された特表２０１７－５３２８８５号公報（以下「参考文献２」という。）には、以下の記載がある。 「【０１２５】 単一レイヤＨＥＶＣおよび現在のＳＣＣ拡張設計において、符号化された動きフィールドは、動きベクトルが４×４ブロックごとに異なるという点において非常に細かい粒度を有することができる。記憶域を節約するために、ＴＭＶＰに使用されるすべての参照ピクチャの動きフィールドが圧縮される。動き圧縮の後、より粗い粒度の動き情報が保存される。１６×１６ブロックごとに、（単予測または双予測などの予測モード、各リストの１または両方の参照インデックス、参照ごとの１または２つのＭＶを含む）動き情報の１つのみのセットが格納される。」 ウ 参考文献１～２に記載された技術常識 参考文献１には、動きフィールドストレージがＴＭＶＰによって使用されることが記載されており、参考文献２には、動きフィールドがＴＭＶＰに使用されることが記載されている。 参考文献１～２に例示されるように、動きフィールドはＴＭＶＰによっても使用されることが技術常識（以下「技術常識１」という。）である。 （２） 技術常識２ ア 参考文献３ 本願の優先日前に公開された国際公開第２０１４／０３４４８０号（以下「参考文献３」という。）には、以下の記載がある。 （ア） 「[0066] また、HEVCでは、カレントブロックの、時間的に周辺のブロックの動きベクトルを用いて、予測動きベクトルの候補を生成することもできる（TMVP（Temporal Motion Vector Prediction））。時間的に周辺のブロックとは、カレントブロックと同一ビューの異なるPOCの画像の、カレントブロックに対応する（例えば同一の位置の）ブロック（コロケーテッドブロックとも称する）である。」 （イ） 「[0133] 以上のように求められた1/16圧縮後V0動きベクトル（動きベクトルの代表値）は、V0動きベクトルメモリ１２２-０に供給され、記憶される。V0動きベクトルメモリ１２２-０は、適宜、記憶している1/16圧縮後V0動きベクトルを、時間的に周辺のブロックの動きベクトルとして、動き予測・補償部１１４-０に供給する。また、V0動きベクトルメモリ１２２-０は、適宜、記憶している1/16圧縮後V0動きベクトルを、ビュー間的に周辺のブロックの動きベクトルとして、動き予測・補償部１１４-１に供給する。」 （ウ） 「[0140] また、上述したように、動き予測・補償部１１４は、V0動きベクトルメモリ１２２-０、V1動きベクトルメモリ１２２-１、およびV2動きベクトルメモリ１２２-２に格納された動きベクトルを、TMVP用の動きベクトルとして参照するだけでなく、IVMP用の動きベクトルとして参照することができる。このようにTMVP用の動きベクトルとIVMP用の動きベクトルとを共通化することにより、符号化に必要な記憶容量を低減させることができる。また、動きベクトルの圧縮による負荷の増大を抑制することができる。これにより、画像符号化装置１００の、製造や開発のコストの低減、装置の小型化、並びに、消費電力の低減等を実現することができる。」 イ 参考文献３に記載された技術常識 上記ア（ア）の段落[0066]には、時間的に周辺のブロック（コロケーテッドブロック）の動きベクトルを用いて、予測動きベクトルの候補を生成するTMVP（Temporal Motion Vector Prediction）について記載されている。 上記ア（イ）、（ウ）の段落[0133]、[0140]には、動きベクトルは、動きベクトルメモリ１２２-０に記憶され、動きベクトルメモリ１２２-０は、記憶している動きベクトルを、時間的に周辺のブロックの動きベクトルとして、動き予測・補償部１１４-０に供給し、動き予測・補償部１１４は、動きベクトルメモリ１２２-０に格納された動きベクトルをTMVP用の動きベクトルとして参照することが記載されている。 そうすると、参考文献３には、記憶している動きベクトルを、時間的に周辺のブロック（コロケーテッドブロック）の動きベクトルとして、TMVP用に参照し、時間的に周辺のブロック（コロケーテッドブロック）の動きベクトルを用いて、予測動きベクトルの候補を生成するTMVP（Temporal Motion Vector Prediction）について記載されている。 参考文献３に例示されるように、記憶している動きベクトルを用いて、予測動きベクトルの候補を生成することで、ＴＭＶＰ（Temporal Motion Vector Prediction）を行うことは、技術常識（以下「技術常識２」という。）である。 第５ 本願発明と先願発明の対比及び判断 １ 対比 本願発明を先願発明と対比する。 （１） 構成Ａ、Ｄについて ア 先願発明の構成ｄの「動きベクトル圧縮」は、「動きベクトルを記憶するときに必要なビットの個数を減少させる」ものであるから、構成ｂの「デコードされた動きベクトル」は、当該「デコード」後の「記憶」処理の際に「動きベクトル圧縮」されると解される。 イ 上記第４の３（１）ウの技術常識１のとおり、動きフィールドはＴＭＶＰによっても使用されることが技術常識であることを踏まえると、先願発明の構成ｂの「デコードされ」、「動きベクトルフィールド（ＭＶＦ）に記憶され」る「動きベクトル」は、ＴＭＶＰによっても使用されるものである。 ここで、ＴＭＶＰは、Temporal Motion Vector Predictionの略語であって、時間的な動きベクトル予測を意味することも技術常識である。 ウ 先願発明の構成ｂの「デコードされた動きベクトル」は、後に、上記ア、イで検討したように、「動きベクトル圧縮」され、「動きベクトルフィールド（ＭＶＦ）に記憶され」、時間的な動きベクトル予測に使用されることを踏まえると、構成Ａの「時間的な動きベクトル」に相当する。 そして、動きベクトルのデコードにより、上記「デコードされた動きベクトル」が得られることを踏まえると、先願発明の構成ｂの「動きベクトル」を「デコード」することは、本願発明の構成Ａの「時間的な動きベクトルを取得する」ことに相当する。 そうすると、本願発明の構成Ａ、及びＤと先願発明の構成ｂは、「時間的な動きベクトルを取得する段階」「を含む」点で共通する。 （２） 構成Ｂ、Ｄについて ア 上記（１）の検討のとおり、先願発明の構成ｂの「デコードされた動きベクトル」は、後に、記憶され、時間的な動きベクトル予測に使用されることを踏まえると、構成Ａの「時間的な動きベクトル」に相当する。 また、先願発明の構成ｄ、ｅによれば、「動きベクトルを記憶するときに必要なビットの個数を減少させるため、動きベクトル圧縮した場合に、動きベクトルは、ＭＶ＝（スケールファクタ×動きデータ）×符号で表され」ることから、先願発明の構成ｂの「デコードされた動きベクトル」は、「動きベクトルフィールド（ＭＶＦ）に記憶され」る際に「動きベクトル圧縮」され、「ＭＶ＝（スケールファクタ×動きデータ）×符号で表され」ると解される。 そして、先願発明の構成ｂの「デコードされた動きベクトル」を記憶する際に、構成ｄの「ＭＶ＝（スケールファクタ×動きデータ）×符号で表」すことは、本願発明の構成Ｂの「時間的な動きベクトルを用いて圧縮された動きベクトルを決定する」ことに相当する。 イ 先願発明の構成ｅによれば、構成ｄの「ＭＶ＝（スケールファクタ×動きデータ）×符号で表され」る「動きベクトル」は、「ｋ」ビットの「動きデータ」、「ｓｆ」ビットの「スケールファクタ」、及び、「１」ビットの「符号」といったビットのデータで表される。 このように、ビットのデータにより表されるから、先願発明の構成ｄの「ＭＶ＝（スケールファクタ×動きデータ）×符号で表され」る「動きベクトル」が「二進表現を用いて」表されることは明らかである。 ウ 上記ア、イを踏まえると、先願発明の構成ｂの「デコードされた動きベクトル」を記憶する際に、構成ｄの「ＭＶ＝（スケールファクタ×動きデータ）×符号で表」すことは、本願発明の構成Ｂの「前記時間的な動きベクトルの二進表現を用いて圧縮された動きベクトルを決定する」ことに相当する。 エ 先願発明の「スケールファクタ」、「動きデータ」は、構成Ｂの「指数部」、「仮数部」にそれぞれ相当するから、先願発明の構成ｄの「動きベクトル圧縮した場合に、動きベクトルは、ＭＶ＝（スケールファクタ×動きデータ）×符号で表され」ることは、本願発明の構成Ｂの「前記圧縮された動きベクトルの二進表現が指数部及び仮数部を含」むことに相当する。 また、先願発明において、「ｓｆ」は「スケールファクタを示すためのビット数」であり、「ｋ」は「動きデータを示すためのビット数」であるから、先願発明の「ｓｆ」と「ｋ」は、構成Ｂの「Ｎ」と「Ｍ」にそれぞれ相当する。 そうすると、先願発明の構成ｅの「スケールファクタを示すためのビット数であるｓｆ、動きデータを示すためのビット数であるｋ」で構成ｄの「動きベクトル」が「表され」ることは、本願発明の構成Ｂの「前記指数部はＮビットを含み、前記仮数部はＭビットを含」むことに相当する。 オ 先願発明では、構成ｃのとおり、動きベクトル非圧縮の場合に、-２15ないし２15-１の範囲の動きベクトルを示すために１６個のビットが利用され、構成ｄのように、動きベクトルを記憶するときに必要なビットの個数を減少させるため、動きベクトル圧縮した場合に、動きベクトルは、ＭＶ＝（スケールファクタ×動きデータ）×符号で表され、スケールファクタを示すためのビット数であるｓｆ、動きデータを示すためのビット数であるｋ、および符号を示すためのビット数であるｂ＝１は、ｓｆ＋ｋ＋ｂ＜１６を満たす。 そして、「ｓｆ＋ｋ＋ｂ＜１６」を満たす「ｓｆ」、「ｋ」、「ｂ」のうち、「ｓｆ＋ｋ＋ｂ」が１４以下の「ｓｆ」、「ｋ」、「ｂ」、すなわち「スケールファクタ」、「動きデータ」、「符号」を示すためのビット数により、動きベクトルを「ＭＶ＝（スケールファクタ×動きデータ）×符号で表」したものは、動きベクトル非圧縮の場合に１６個のビットが利用される動きベクトルを、１４ビット以下で表したものであり、動きベクトル非圧縮の場合に比べて、少なくとも２ビット少ない。 そうすると、本願発明の構成Ｂの「前記圧縮された動きベクトルの前記二進表現」と、先願発明において「ｓｆ＋ｋ＋ｂ」が１４以下の「ｓｆ」、「ｋ」、「ｂ」、すなわち「スケールファクタ」、「動きデータ」、「符号」を示すためのビット数により、動きベクトルを「ＭＶ＝（スケールファクタ×動きデータ）×符号で表」したものは、「圧縮される前の前記時間的な動きベクトルよりも少なくとも２ビット少ない」点で一致する。 カ 上記ウ～オを踏まえると、本願発明の構成Ｂ、Ｄと先願発明の構成ｂ～ｅは、「前記時間的な動きベクトルの二進表現を用いて圧縮された動きベクトルを決定する段階であって、前記圧縮された動きベクトルの二進表現が指数部及び仮数部を含み、前記指数部はＮビットを含み、前記仮数部はＭビットを含み」、「前記圧縮された動きベクトルの前記二進表現は、圧縮される前の前記時間的な動きベクトルよりも少なくとも２ビット少ない、段階」「を含む」点で共通する。 ただし、本願発明では、「Ｎは非負の整数であり、Ｍは正の整数であ」ることが特定されているのに対し、先願発明では、当該特定がなされていない点で一応相違する。 （３） 構成Ｃ、Ｄについて 上記（２）アで説示したとおり、先願発明の構成ｂの「デコードされた動きベクトル」を記憶する際に、構成ｄの「ＭＶ＝（スケールファクタ×動きデータ）×符号で表」すことは、本願発明の構成Ｂの「圧縮された動きベクトルを決定する」ことに相当する。 ここで、上記第４の３（２）イの技術常識２のとおり、記憶している動きベクトルを用いて、予測動きベクトルの候補を生成することで、ＴＭＶＰ（Temporal Motion Vector Prediction）を行うことは技術常識であるから、先願発明の構成ａにおいて、「ＴＭＶＰ候補」を「導出」する際に、記憶している動きベクトルを用いて、予測動きベクトルの候補を生成し、ＴＭＶＰ（Temporal Motion Vector Prediction）を行うことは明らかである。 そうすると、本願発明の構成Ｃ、Ｄと先願発明の構成ａは「前記圧縮された動きベクトルを用いて、時間的な動きベクトル予測（ＴＭＶＰ）を実行する段階」「を含む」点で一致する。 （４） 構成Ｅについて 上記（２）イ、ウを踏まえると、本願発明の構成Ｅの「方法」と、先願発明の構成ｆの「方法」は、「動きベクトル圧縮方法」である点で一致する。 ２ 一致点及び相違点 以上を総合すると、本願発明と先願発明とは、以下の点で一致ないし相違する。 （一致点） 「Ａ 時間的な動きベクトルを取得する段階と、 Ｂ’ 前記時間的な動きベクトルの二進表現を用いて圧縮された動きベクトルを決定する段階であって、前記圧縮された動きベクトルの二進表現が指数部及び仮数部を含み、前記指数部はＮビットを含み、前記仮数部はＭビットを含み、前記圧縮された動きベクトルの前記二進表現は、圧縮される前の前記時間的な動きベクトルよりも少なくとも２ビット少ない、段階と、 Ｃ 前記圧縮された動きベクトルを用いて、時間的な動きベクトル予測（ＴＭＶＰ）を実行する段階と、 Ｄ を含む、 Ｅ 動きベクトル圧縮方法。」 （相違点） 本願発明では、「Ｎは非負の整数であり、Ｍは正の整数であ」ることが特定されているのに対し、先願発明では、当該特定がなされていない点。 ３ 相違点についての判断 （１） 相違点についての当審の判断 上記相違点について検討する。 先願発明において、「ｓｆ」が「スケールファクタを示すためのビット数」であり、「ｋ」が「動きデータを示すためのビット数である」ことを考慮すれば、「ｓｆ」及び「ｋ」について、いずれも整数であって負の値をとり得ないことは自明であり、かつ、「動きベクトル」の大きさによっては「ｓｆ」がゼロとなりうることもまた当業者には明らかである。 そうすると、先願発明において、明記がなくても、「ｓｆ」は非負の整数であり、「ｋ」は正の整数であることが明らかであるから、本願発明と先願発明は実質的に相違しない。 （２） 請求人の主張について ア 請求人の主張 審判請求人は、審判請求書並びに令和５年１０月１３日に提出された上申書の「本願発明が特許されるべき理由」において、以下のとおり主張している。 「引用文献１には、本願の補正後請求項１に係る発明の「指数部及び／又は仮数部を含む圧縮された動きベクトルを、前記時間的な動きベクトルの値を特定範囲に制限しつつ、前記時間的な動きベクトルの二進表現を用いて決定する段階」は、記載されていない。したがって、本願の補正後請求項１に係る発明は、引用文献１の発明と同一ではない。」 イ 請求人の主張についての検討 請求人の当該主張について検討する。 令和６年１２月２０日にされた手続補正により、補正前の特許請求の範囲における請求項１の「指数部及び／又は仮数部を含む圧縮された動きベクトルを、前記時間的な動きベクトルの値を特定範囲に制限しつつ、」の記載は削除されたので、請求人の上記主張は、上記手続補正後の特許請求の範囲における請求項１の記載に基づくものではないから採用できない。 また、上記手続補正により、当該補正後の特許請求の範囲における請求項１では、「前記圧縮された動きベクトルの前記二進表現は、圧縮される前の前記時間的な動きベクトルよりも少なくとも２ビット少ない」ことが新たに特定された。 しかしながら、本願発明の当該特定事項は、上記第５の１（２）オで検討したとおり、先願発明との相違点とはならない。 したがって、請求人の上記アの主張は採用できない。 第６ むすび 以上のとおり、本願発明は、先願の国際出願日における国際出願の明細書、請求の範囲又は図面に記載された発明と同一であり、しかも、本願の発明者が先願に係る上記の発明をした者と同一ではなく、また本願の出願の時において、本願の出願人が先願の出願人と同一でもないので、特許法第２９条の２の規定により、特許を受けることができない。 したがって、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。 よって、結論のとおり審決する。