【事件の表示】
　特願２００７−２８１０３４「符号化装置および方法、記録媒体、並びに、プログラム」拒絶査定不服審判事件〔平成２０年　５月　１日出願公開、特開２００８−１０４２０５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１　経緯
　本件出願は、平成１４年４月２６日に出願した特願２００２−１２５２９５号の一部を平成１８年８月１８日に新たな特許出願とした特願２００６−２２３４８３号の一部を平成１９年１０月２９日に新たな特許出願としたものであって、 平成２２年５月１９日付けで拒絶理由の通知がなされ、これに対し、平成２２年７月２３日付けで手続補正がなされたが、平成２３年１月１４日付けで拒絶査定がなされたものである。
　本件は、上記拒絶査定を不服として平成２３年４月１３日付けで請求された拒絶査定不服審判であって、平成２３年４月１３日付けで手続補正（明細書、特許請求の範囲又は図面について請求と同時にする補正）がなされたものである。
　
２　補正の却下の決定
　平成２３年４月１３日付けの手続補正について次のとおり決定する。
　
〈補正の却下の決定の結論〉
　平成２３年４月１３日付けの手続補正を却下する。
　
〈補正の却下の決定の理由〉
（１）補正の内容
　平成２３年４月１３日付けの手続補正（以下、本件補正という）は、特許請求の範囲について、補正前の請求項７、８を削除し、補正後の請求項１ないし９を補正前の請求項１ないし６、９ないし１１にそれぞれ対応するものとし、補正前の独立項である請求項１、９、１０、１１の各「コンテキストモデルを算出する」構成について「換算された前記隣接マクロブロックの動きベクトル情報を用いて、」との特定を付加し、補正後の独立項である請求項１、７、８、９とする補正を含むものである。
　
（２）補正の適法性
　「コンテキストモデルを算出する」構成について「換算された前記隣接マクロブロックの動きベクトル情報を用いて、」との特定を付加する補正は、特許請求の範囲の減縮を目的とする補正であると認められるので、独立特許要件について検討する。
　
　ア　補正後発明
　本件補正後の請求項１ないし９の内、請求項７に係る発明（以下、「補正後発明」ともいう）は、補正後の請求項７に記載されたところにより特定されるものと認められるところ、補正後の請求項７は次のとおりである。
　
［補正後発明］（【請求項７】）
　画像情報を符号化する符号化装置の符号化方法であって、
　コンテキストモデル手段が、符号化の対象となる対象マクロブロックに隣接する隣接マクロブロックがフィールドモードで符号化されており、前記対象マクロブロックをフレームモードで符号化する場合、前記隣接マクロブロックの動きベクトル情報を対象マクロブロックのフレームモードにあわせるように換算して、換算された前記隣接マクロブロックの動きベクトル情報を用いて、前記対象マクロブロックの動きベクトル情報に対応するコンテキストモデルを算出し、
　コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う
　符号化方法。
　
　イ　引用例
　査定の理由として示された「Ｄｅｔｌｅｖ　Ｍａｒｐｅ　ｅｔ　ａｌ．，Ａｄａｐｔｉｖｅ　Ｃｏｄｅｓ　ｆｏｒ　Ｈ．２６Ｌ，ＩＴＵ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ　Ｓｅｃｔｏｒ　ＳＴＵＤＹ　ＧＲＯＵＰ　１６　Ｑｕｅｓｔｉｏｎ　６　Ｖｉｄｅｏ　Ｃｏｄｉｎｇ　Ｅｘｐｅｒｔｓ　Ｇｒｏｕｐ（Ｖ，Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ｕｎｉｏｎ，２００１年　１月　９日，ｐ．１−８」（以下、「引用例１」ともいう）には、図、表と共に次の記載がある。
　
（引用例１の記載）
「1 Introduction
（１　はじめに）
　
In a number of previous contributions [1],[2],[3], it has been shown, that the universal variable length code (UVLC) used in the entropy coding method of the current H.26L test model is not optimal with respect to coding efficiency. 
（いくつかの寄稿［１］［２］［３］で示されるように、現在のＨ．２６Ｌテストモデルのエントロピー符号化方法に用いられるユニバーサル可変長符号（ＵＶＬＣ）は、符号化効率に関して最適化されていません。）
　
Proposals were made either to improve on the VLC table or to adapt the mapping between syntax elements and UVLC codewords.
（いくつかの提案が、ＶＬＣテーブルを改善するため、または、シンタックス要素とＵＶＬＣ符号語の間のマッピングを修正させるためになされた。）
　
In this contribution, we present a more fundamental approach which is based on context-based adaptive binary arithmetic coding.
（この寄稿で、コンテキストベース適応２値算術符号化に基づく、より根本的なアプローチを提示する。）
　
We introduce a number of techniques for rapid adaptation to the changing statistics of all syntax elements.
（すべてのシンタックス要素の統計変化に迅速に適応するためのいくつかの技法を紹介する。）
　
As will be shown, these techniques improve the compression performance of the test model, particularly at low and high bit rates.
（これらの技法が、特に低いビットレートと高いビットレートで、テストモデルの圧縮性能を向上させることが示される。）
　
（　　　　　　　　　　　　　図１　　　　　　　　　　　　）
　
Figure 1: Proposed entropy coding scheme
（図１：提案されたエントロピー符号化方式）
　
In the following, we give a short overview of the main coding elements of our proposed entropy coding scheme.
（提案するエントロピー符号化方式の主なコード化要素の簡単な概要を以下に示す。）
　
Suppose, a symbol related to an arbitrary syntax element is given, then in a first step, a suitable model is chosen according to a set of past observations which serves as a statistical model of the source and which is used to encode the actual symbol.
（任意のシンタックス要素に関連するシンボルが与えられていると仮定して、最初のステップで、適切なモデルは、ソースの統計モデルとして働き、実際のシンボルをエンコードするために使用される過去の観測値の集合に応じて選択されます。）
　
This process of constructing a model is commonly referred to as context modeling and it depends in our approach on the given syntax element.
（モデルを構築するこのプロセスは、一般的にコンテクストモデリングと呼ばれ、我々のアプローチで与えられたシンタックス要素に依存します。）
　
In Section 2 and 3, we will describe in detail, which context models have been chosen for the different syntax elements.
（コンテキストモデルが異なるシンタックス要素のために選択されることを、セクション２と３で、詳細に説明します。）
　
If the actual symbol is non-binary valued, it will be mapped onto a sequence of binary decisions, so-called bins, in a second  step.
（実際のシンボルが非バイナリ値である場合、２番目のステップで、ビンと称されるバイナリ決定のシーケンス上にマッピングされます。）
　
The actual binarization is done according to a given binary tree, as specified in Section 4.
（セクション４で指定される与えられたバイナリツリーに従って、実際の２値化は行われます。）
　
Finally, each binary decision is encoded with the binary arithmetic coding engine using the probability model which has been supplied by the context modeling stage.
（最後に、それぞれのバイナリの決定は、コンテキストモデリング段階によって供給された確率モデルを使用して、２値算術符号化エンジンによりエンコードされる。）
　
Note, that during encoding the current context model will be updated with the previously encoded symbol.
（そのエンコード中に、現在のコンテキストモデルは以前にエンコードされたシンボルで更新されることに注意。）
　
Hence, the model keeps track of the actual statistics and provides a fast adaptation.
（したがって、このモデルは、実際の統計を追跡し、高速な適応を提供しています。）
　
Figure 1 illustrates the whole process. 
（図１は、全体のプロセスを示しています。）
　
2 Context Modeling for Coding of Motion and Mode Information
（２　モーションおよびモード情報の符号化のためのコンテキストモデリング）
　
In this section we describe in detail the context modeling of our adaptive coding method for the syntax elements macroblock type (MB_type), motion vector data (MVD) and reference frame parameter (Ref_frame), as defined in the description of the H.26L test model TML-4 [4].
（このセクションでは、Ｈ．２６ＬテストモデルＴＭＬ−４ [４］の説明で定義されているよう、構文要素、マクロブロックタイプ（ＭＢ＿ｔｙｐｅ）、動きベクトルデータ（ＭＶＤ）と参照フレームパラメータ（Ｒｅｆ＿ｆｒａｍｅ）のための、私たちの適応符号化方式のコンテクストモデリングの詳細を記述する。）
　
2.1 Context Models for Macroblock Type
（２．１　マクロブロックタイプのためのコンテキストモデル）
　
　　　　　　　　　　　・
　　　　　　　　　　（略）
　　　　　　　　　　　・
（　　　　　図２（ａ）　　　　図２（ｂ）　　　　　　　　）
　
Figure 2:
（図２）
　
(a) Neighboring symbols A and B used for conditional coding of a current symbol C.
（（ａ）現在のシンボルＣの条件付き符号化のために使用される隣接シンボルＡとＢ）
　
(b) Neighboring blocks A and B used for conditional coding of motion vector data related to block C.
（（ｂ）ブロックＣに関連した動きベクトルデータの条件付き符号化のために使用される隣接ブロックＡとＢ）
　
　　　　　　　　　　　・
　　　　　　　　　　（略）
　　　　　　　　　　　・
　
2.2 Context Models for Motion Vector Data
（２．２　動きベクトルデータのためのコンテキストモデル）
　
Motion vector data consists of residual vectors obtained by applying motion vector prediction.
（動きベクトルデータは、動きベクトル予測を適用して得られた残差ベクトルで構成されています。）
　
Thus, it is a reasonable approach to build a model conditioned on the local prediction error.
（したがって、それは局所予測誤差の条件モデルを構築するための合理的なアプローチである。）
　
A simple measure of the local prediction error at a given block C is given by evaluating the L1-norm　ek(A,B)=|mvdk(A)|+|mvdk(B)| of two neighboring motion vector prediction residues mvdk(A) and mvdk(B) for each component of a motion vector residue mvdk(C) of a given block, where A and B are neighboring blocks of block C, as shown in Figure 2 (b).
（与えられたブロックＣにおける局所予測誤差の単純な尺度は、与えられたブロックの動きベクトル残差ｍｖｄｋ（Ｃ）の各コンポーネントのために、二つの隣接する動きベクトル予測残差ｍｖｄｋ（Ａ）とｍｖｄｋ（Ｂ）のＬ１ノルムｅｋ（Ａ、Ｂ）＝｜ｍｖｄｋ（Ａ）｜＋｜ｍｖｄｋ（Ｂ）｜を評価することによって与えられる。図２（ｂ）に示すように、ＡとＢはブロックＣの隣接しているブロックである。）
　
If one of the neighboring blocks belongs to an adjacent macroblock, we take the residual vector component of the leftmost neighboring block in the case of the upper block B, and in the case of the left neighboring block A we use the topmost neighboring block.
（隣接ブロックの一つが隣接するマクロブロックに属している場合、上方のブロックＢについては一番左の隣接ブロックの残差ベクトル成分を取り、左側のブロックＡについては一番上の隣接ブロックを使用します。）
　
If one of the neighboring blocks is not available, because, for instance, the current block is at the picture boundary, we discard the corresponding part of ek.
（例えば、現在のブロックが画像の境界に位置していることにより、隣接ブロックのいずれかが使用できない場合、我々は、ｅｋの対応する部分を破棄します。）
　
By using ek , we now define a context model ctx_mvd(C,k) for the residual motion vector component mvdk(C) consisting of three different context models:
（ｅｋを使用することにより、３つの異なるコンテキストモデルから成る残差動きベクトル成分ｍｖｄｋ（Ｃ）のコンテキストモデルｃｔｘ＿ｍｖｄ（Ｃ、ｋ）を定義します。
　
　　　　　　　　　　　　　　　　　０，ｅｋ（Ｃ）＜３，
　　ｃｔｘ＿ｍｖｄ（Ｃ，ｋ）　＝　１，ｅｋ（Ｃ）＞１５，
　　　　　　　　　　　　　　　　　２，ｅｌｓ
　
For the actual coding process, we separate mvdk(C) in sign and modulus, where only the first bin of the binarization of the modulus |mvdk(C)| is coded using the context models ctx_mvd(C,k).
（実際の符号化処理のために、ｍｖｄｋ（Ｃ）を符号と係数に分離します。｜ｍｖｄｋ（Ｃ）｜の二値化した最初のビン（桁）においてのみ、コンテキストモデルｃｔｘ＿ｍｖｄ（Ｃ、ｋ）を使用してコード化します。）
　
For the remaining bins, we have three additional models: two for the second and the third bin and a third model for all remaining bins.
（残りのビンにおいて、３つの追加モデルを持っています。２番目と３番目の桁に対する２つのモデルと残りのビンに対する３番目のモデルです。）
　
Additionally, the sign coding routine is provided with a separate model. 
（さらに、ルーチンコーディング記号は別のモデルを備えている。）
　
This results in a total sum of 7 different models for each vector component.
（各ベクトル成分のための７つの異なったモデルをすべて合わせると結果となります。）
　
2.3 Context Models for Reference Frame Parameter
（２．３　リファレンスフレームパラメータのためのコンテキストモデル）
　
　　　　　　　　　　　・
　　　　　　　　　　（略）
　　　　　　　　　　　・
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　」
（引用例１の記載、以上）
　
　以上の記載によると、引用例１には、エントロピー符号化方法におけるコンテキストベース適応２値算術符号化の手法について記載されており、このコンテキストベース適応２値算術符号化の手法は、全体のプロセスが図１に示され、
　最初のステップ（コンテキストモデリング）で、適切なモデルを過去の観察値の集合に応じて選択し、
　２番目のステップで、シンボルが非バイナリ値である場合、２値化を行い、
　最後（のステップ）で、コンテキストモデリング段階（最初のステップ）によって供給された確率モデルを使用して、それぞれのバイナリの決定は、２値算術符号化エンジンによりエンコードされる。
　
　コンテキストモデリングは、マクロブロックタイプ（ＭＢ＿ｔｙｐｅ）、動きベクトルデータ（ＭＶＤ）と参照フレームパラメータ（Ｒｅｆ＿ｆｒａｍｅ）についてなされ、
　動きベクトルデータ（ＭＶＤ）については、図２（ｂ）に示すように、ＡとＢはブロックＣの隣接しているブロックであるとして、与えられたブロックの動きベクトル残差ｍｖｄｋ（Ｃ）の各コンポーネントのために、二つの隣接する動きベクトル予測残差ｍｖｄｋ（Ａ）とｍｖｄｋ（Ｂ）のＬ１ノルムｅｋ（Ａ、Ｂ）＝｜ｍｖｄｋ（Ａ）｜＋｜ｍｖｄｋ（Ｂ）｜を評価し、
　
　　　　　　　　　　　　　　　　０，ｅｋ（Ｃ）＜３，
　ｃｔｘ＿ｍｖｄ（Ｃ，ｋ）　＝　１，ｅｋ（Ｃ）＞１５，
　　　　　　　　　　　　　　　　２，ｅｌｓ
　
　と、３つの異なるコンテキストモデルから成る残差動きベクトル成分ｍｖｄｋ（Ｃ）のコンテキストモデルｃｔｘ＿ｍｖｄ（Ｃ、ｋ）を定義し、二値化した最初のビン（桁）においてのみ、コンテキストモデルｃｔｘ＿ｍｖｄ（Ｃ、ｋ）を使用してコード化する。
　
　このコンテキストベース適応２値算術符号化の手法を引用例１に記載された発明（以下、「引用発明」ともいう）として認定する。
　
　ウ　対比
　補正後発明と引用発明とを対比する。
　
　（ア）「画像情報を符号化する符号化装置の符号化方法」
　
　　引用発明は、「コンテキストベース適応２値算術符号化の手法」であって、画像情報を符号化の対象とすると認められ、その符号化は普通に符号化装置においてなされることを想定するといえるから、「画像情報を符号化する符号化装置の符号化方法」といい得るものであり、この点で補正後発明と一致する。
　
　（イ）「コンテキストモデル手段が、符号化の対象となる対象マクロブロックに隣接する隣接マクロブロックがフィールドモードで符号化されており、前記対象マクロブロックをフレームモードで符号化する場合、前記隣接マクロブロックの動きベクトル情報を対象マクロブロックのフレームモードにあわせるように換算して、換算された前記隣接マクロブロックの動きベクトル情報を用いて、前記対象マクロブロックの動きベクトル情報に対応するコンテキストモデルを算出し」
　
　　引用発明は、そのコンテキストモデリングにおいて、
「動きベクトルデータ（ＭＶＤ）については、図２（ｂ）に示すように、ＡとＢはブロックＣの隣接しているブロックであるとして、与えられたブロックの動きベクトル残差ｍｖｄｋ（Ｃ）の各コンポーネントのために、二つの隣接する動きベクトル予測残差ｍｖｄｋ（Ａ）とｍｖｄｋ（Ｂ）のＬ１ノルムｅｋ（Ａ、Ｂ）＝｜ｍｖｄｋ（Ａ）｜＋｜ｍｖｄｋ（Ｂ）｜を評価し、
　
　　　　　　　　　　　　　　　　０，ｅｋ（Ｃ）＜３，
　ｃｔｘ＿ｍｖｄ（Ｃ，ｋ）　＝　１，ｅｋ（Ｃ）＞１５，
　　　　　　　　　　　　　　　　２，ｅｌｓ
　
　と、３つの異なるコンテキストモデルから成る残差動きベクトル成分ｍｖｄｋ（Ｃ）のコンテキストモデルｃｔｘ＿ｍｖｄ（Ｃ、ｋ）を定義し、二値化した最初のビン（桁）においてのみ、コンテキストモデルｃｔｘ＿ｍｖｄ（Ｃ、ｋ）を使用してコード化する。」
　　のであり、
　　ブロックＣを対象ブロックとして、「コンテキストモデル手段が、符号化の対象となる対象ブロックに隣接する隣接ブロックの動きベクトル情報を用いて、前記対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出」するといい得るから、この点で補正後発明と一致する。
　
　　しかしながら、まず、補正後発明では対象ブロックおよび隣接ブロックを「マクロブロック」と特定しているところ、引用発明ではそうでないことから、前記対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出し、コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う対象ブロック、及び、算出に用いる隣接ブロックが、補正後発明では「マクロブロック」であることに対して、引用発明ではそうでない点で相違する。
　
　　また、補正後発明は、コンテキストモデルの算出について、「符号化の対象となる対象マクロブロックに隣接する隣接マクロブロックがフィールドモードで符号化されており、前記対象マクロブロックをフレームモードで符号化する場合、前記隣接マクロブロックの動きベクトル情報を対象マクロブロックのフレームモードにあわせるように換算して、換算された前記隣接マクロブロックの動きベクトル情報を用いて」算出することを特定しているところ、引用発明はそうでないことから、上記「マクロブロック」に関する相違に加えて、コンテキストモデルの算出手法として、対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出する際に用いる隣接ブロックの動きベクトル情報が、補正後発明では、「隣接ブロックがフィールドモードで符号化されており、前記対象ブロックをフレームモードで符号化する場合、前記隣接ブロックの動きベクトル情報を対象ブロックのフレームモードにあわせるように換算して、換算された」動きベクトル情報であることに対して、引用発明ではそうでない点で相違する。
　
　（ウ）「コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う」
　
　　引用発明は、最後（のステップ）で、コンテキストモデリング段階（最初のステップ）によって供給された確率モデル、すなわち、（イ）で上記した算出されたモデル、を使用して、それぞれのバイナリの決定は、２値算術符号化エンジンによりエンコードされるのであり、「コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う」といい得るものである。
　　したがって、補正後発明と引用発明とは、この点で一致する。
　
　エ　一致点相違点
　以上のとおり対比されるから、補正後発明と引用発明との一致点、相違点は次のとおりである。
　
［一致点］
　画像情報を符号化する符号化装置の符号化方法であって、
　コンテキストモデル手段が、符号化の対象となる対象ブロックに隣接する隣接ブロックの動きベクトル情報を用いて、前記対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出し、
　コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う
　符号化方法。
　
［相違点］
（相違点１）
　前記対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出し、コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う対象ブロック、及び、算出に用いる隣接ブロックが、補正後発明では「マクロブロック」であることに対して、引用発明ではそうでない点。
　
（相違点２）
　対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出する際に用いる隣接ブロックの動きベクトル情報が、補正後発明では、「隣接ブロックがフィールドモードで符号化されており、前記対象ブロックをフレームモードで符号化する場合、前記隣接ブロックの動きベクトル情報を対象ブロックのフレームモードにあわせるように換算して、換算された」動きベクトル情報であることに対して、引用発明ではそうでない点。
　
　オ　判断
　（ア）　引用例２
　　査定の理由として示された「Ｌ．　Ｗａｍｇ　ｅｔ　ａｌ．，Ｉｎｔｅｒｌａｃｅ　Ｃｏｄｉｎｇ　Ｔｏｏｌｓ　ｆｏｒ　Ｈ．２６Ｌ　Ｖｉｄｅｏ　Ｃｏｄｉｎｇ，ＩＴＵ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ　Ｓｅｃｔｏｒ　ＳＴＵＤＹ　ＧＲＯＵＰ　１６　Ｑｕｅｓｔｉｏｎ　６　Ｖｉｄｅｏ　Ｃｏｄｉｎｇ　Ｅｘｐｅｒｔｓ　Ｇｒｏｕｐ（Ｖ，Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ｕｎｉｏｎ，２００１年１２月　４日，ｐ．１−２０」（以下、「引用例２」ともいう）には、図、表と共に次の記載がある。
　
（引用例２の記載）
「1. Introduction
（１．はじめに）
　
H.26L TML 8.5 [1] allows three possible picture types for an input frame: I, P and B.
（Ｈ．２６Ｌ　ＴＭＬ８．５［１］は、入力フレームには、次の３つのピクチャタイプを可能にする。Ｉ、Ｐ、とＢ。）
　
A frame of any picture type I, P or B is divided into MBs of 16x16 pixels.
（任意の画像タイプＩ、ＰまたはＢのフレームは１６ｘ１６ピクセルのＭＢに分割されています。）
　
Each MB of 16x16 can be further divided into blocks in one of seven patterns (modes), as shown in Fig. 1.
（１６ｘ１６の各ＭＢはさらに、図１に示すように７つのパターン（モード）のいずれかのブロックに分割することができます。）
　
Block size can be 16x16, 16x8, 8x16, 8x8, 8x4, 4x8, or 4x4.
（ブロックサイズは、１６ｘ１６、１６ｘ８、８ｘ１６、８ｘ８、８ｘ４、４ｘ８または４ｘ４とすることができます。）
　
A MB can be coded in either intra or inter.
（ＭＢは、イントラかインターどちらかで符号化することができます。）
　
For intra mode, MB can be only in either mode 1 (block size of 16x16) or mode 7 (block size of 4x4).
（イントラモードの場合、ＭＢはモード１（１６ｘ１６のブロックサイズ）またはモード７（４ｘ４のブロックサイズ）のどちらかにのみ指定できます。）
　
For inter mode, MB can be in any of seven modes.
（インターモードの場合、ＭＢは７つのモードのいずれかになります。）
　
Motion estimation and compensation (ME/MC) is performed for these blocks separately.
（動き予測と補償（ＭＥ／ＭＣ）はこれらのブロック毎に実行されます。）
　
In other words, each block within a MB has a separate MV, and hence, a MB can have up to 16 MVs, depending upon the MB mode.
（言い換えれば、ＭＢ内の各ブロックは、個別のＭＶを持っており、それ故に、ＭＢはＭＢモードに応じて、最大１６のＭＶを持つことができます。）
　
（　　　　　　　　　　　　　図１　　　　　　　　　　　　）
　
Fig. 1. Seven frame-based block patterns (modes) per MB.
（図１。ＭＢにおける７つのフレームベースブロックパターン（モード）。）
　
The current TML 8.5 is designed for progressively scanned video materials.
（現在ＴＭＬ８．５は、プログレッシブスキャンビデオ素材用に設計されています。）
　
All the code modes in the current TML 8.5 are frame-based.
（現在ＴＭＬ８．５内のすべての符号化モードは、フレームベースです。）
　
Nature of interlace video materials and its possible impact on H.26L has been under discussion [2], [3], [4], [5], [6].
（インターレースビデオ素材の性質とＨ．２６Ｌにおける影響の可能性が議論［２］、［３］、［４］、［５］、［６］の下にあります。）
　
In particular, a frame of interlace video sequence consists of two fields, scanned at different time instants.
（具体的には、インターレースビデオシーケンスのフレームは、異なる時刻でスキャンされた２つのフィールドから構成されています。）
　
Therefore, a video sequence consisting of interlaced video can be compressed in many different ways.
（そのため、インターレースビデオから成るビデオシーケンスは、多くの異なる方法で圧縮することができます。）
　
They can be grouped in two main categories:
(a) Fixed Frame/Field and
(b) Adaptive Frame/Field
（これらは、主に２つのカテゴリに分類することができます。
　（ａ）固定フレーム/フィールド　と
　（ｂ）適応フレーム/フィールド　　　　　　　　　　　　　）
　
In Fixed Field/Frame method, an interlaced video sequence is always coded with either Field or Frame structure irrespective of the content.
（固定フィールド/フレーム方式では、インターレースされたビデオシーケンスは、常にコンテンツに関わらずフィールドまたはフレーム構造のいずれかでコーディングされています。）
　
In Adaptive Field/Frame methods, depending upon the content, one adaptively selects whether to use the field or frame structure.
（適応フィールド/フレーム方式では、コンテンツに応じて、フィールド構造を使用するかフレーム構造を使用するかを適応的に選択します。）
　
Adaptation can be done at either Picture level or Macroblock level.
（適応は画像レベルまたはマクロブロックレベルのいずれかで行うことができます。）
　
This document provides results obtained by different coding tools in these categories.
（この文書では、カテゴリで異なる符号化ツールによって得られた結果を提供します。）
　
It is shown that if either fixed field or fixed frame structure is picked to compress interlaced video, it will lead to coding inefficiency as for some video sequences field structure is better and for others frame structure is better.
（インターレースビデオを圧縮するために固定フィールド構造または固定されたフレーム構造が選ばれた場合、より優れているいくつかのフィールド構造のビデオシーケンス、より優れている他のフレーム構造のビデオシーケンスについて、非効率な符号化につながることが示されます。）
　
Content adaptive Field/Frame based tools are introduced where a decision regarding field or frame structure is made based on the content type.
（コンテンツの種類に基づいてフィールドまたはフレーム構造に関する決定がなされるところでの、コンテンツ適応フィールド/フレームベースのツールを紹介しています。）
　
It is shown that they perform better than fixed frame or field method by adaptively picking the optimal structure for a given content.
（与えられたコンテンツのための最適な構造を適応的に選択することによって、固定フレームまたはフィールド方式よりも高いパフォーマンスを発揮することが示されている。）
　
2. Interlace Coding
（２．インターレースコーディング）
　
Inputs to the H.26L video code can be considered as a series of units at three different levels: sequence, picture, and MB.
（Ｈ．２６Ｌビデオコードへの入力は、３つの異なるレベルでのユニットのシリーズとして考えることができる。シーケンス、ピクチャ、およびＭＢ。）
　
Frame or field coding can also be made adaptive at these three levels, that is, adaptive frame/field coding at sequence level, adaptive frame/field coding at picture level, and adaptive frame/field coding at MB level.
(フレームまたはフィールド符号化は、これらの３つのレベルで適応することができる。それは、シーケンスレベル、ピクチャーレベル、 ＭＢレベルである。）
　
2.1 Fixed Frame/Field - Sequence Level
（２．１　固定フレーム/フィールド　−　シーケンスレベル）
　
　　　　　　　　　　　・
　　　　　　　　　　（略）
　　　　　　　　　　　・
　
2.2 Adaptive Frame/Field Coding  - Picture Level
（２．２　適応フレーム/フィールド符号化　−　ピクチャーレベル）
　
　　　　　　　　　　　・
　　　　　　　　　　（略）
　　　　　　　　　　　・
　
2.3 Adaptive Frame/Field Coding  - MB Level
（２．３　適応フレーム/フィールド符号化　−　ＭＢレベル）
　
For MB level adaptation of frame/field coding, a MB can be coded in frame- or field-based.
（フレーム/フィールド符号化のＭＢレベルでの適応のため、ひとつのＭＢがフレームまたはフィールドベースでコーディングすることができます。）
　
A frame/field flag may be required at MB level to indicate if the MB is coded in frame- or field- based, as shown in Fig. 2.
（図２に示すように、ＭＢがフレームまたはフィールドベースでコード化されている場合を示すために、フレーム/フィールドフラグは、ＭＢレベルで必要であるかもしれません。）
　
0 indicates frame-based coding and 1 field-based coding.
（”０”はフレームベースのコーディング、”１”はフィールドベースのコーディングを示します。）
　
Frame-based coding of a MB follows TML 8.5.
（ＭＢのフレームベースのコーディングは、ＴＭＬ８．５に従う。）
　
Field-based coding will be described as follows.
（フィールドベースのコーディングは次に説明する。）
　
（　　　　　　　　　　　　　図２　　　　　　　　　　　　）
　
Fig. 2. A frame/field flag of one bit may be required to indicate if the following MB is coded in frame- or field-based.
（図２。１ビットのフレーム/フィールドフラグは、次のＭＢがフレームまたはフィールドベースでコーディングされている場合を示すために、必要になることがあります。）
　
Five additional block patterns are introduced for field-based coding, as shown in Fig. 3.
（図３に示すように、５つの追加ブロックパターンは、フィールドベース符号化のために導入されています。）
　
For field-based coding, a MB is first split into two fields of top and bottom. 
（フィールドベース符号化のために、ＭＢは、まず、ＴＯＰフィールドとＢＯＴＴＯＭフィールドに分割されます。）
　
The split MB is then further divided into one of five possible block patterns. 
（分割されたＭＢは、その後さらに５つの可能なブロックパターンのいずれかに分かれています。）
　
Similar to in frame mode, a MB in field mode can be coded in intra or inter mode.
（フレームモードと同様に、フィールドモードでＭＢがイントラまたはインターモードでコーディングすることができます。）
　
（　　　　　　　　　　　　　図３　　　　　　　　　　　　）
　
Fig.3. 
（図３）
Five additional field-based block patterns (modes) per MB. 
（ＭＢあたりフィールドベースの５つの追加ブロックパターン（モード）。）
The shadow (blue) areas are for top field and blank for bottom field.
（影（青）領域がトップフィールドのためのもの、ブランクがボトムフィールドのためのものです。）
　
Intra Prediction
イントラ予測
　
　　　　　　　　　　　・
　　　　　　　　　　（略）
　　　　　　　　　　　・
　
Inter Code Mode
（インターコードモード）
　
For inter code modes, ME/MC is preformed on each frame/field block.
（インターコードモードでは、ＭＥ／ＭＣは、各フレーム/フィールドブロックに対して設定されている。）
　
As in frame mode, there are also up to 16 blocks per MB in field mode (see Fig. 3). 
（フレームモードのように、フィールドモードでＭＢあたり最大１６ブロックあります。（図３参照））
　
The smallest block is 4x4. Hence, there are up to 16 MVs per MB in field mode. 
（最小ブロックは４ｘ４である。したがって、フィールドモードでＭＢあたり最大１６のＭＶがあります。）
　
The reference fields for a field-based block can be either the top or the bottom fields of any previously coded frames. 
（フィールドベースのブロックのための基準のフィールドは、以前にコード化されたフレームのトップまたはボトムフィールドのどちらかになります。）
　
Six field-based ME/MC code modes can be the possible code modes in encoding a MB. 
（６つのフィールドベースＭＥ／ＭＣコードモードは、ひとつのＭＢを符号化可能なコードモードを指定できます。）
　
They are field inter 16x16, inter 8x16, inter 8x8, inter 4x8, inter 8x4, and inter 4x4. 
（それは、フィールドインター１６ｘ１６、インター８ｘ１６、インター８ｘ８、インター４ｘ８、インター８ｘ４、およびインター４ｘ４である。）
　
The field inter 16x16 is similar to the inter 8x16 mode except the motion vectors for the top field and the bottom field are forced to be the same, and the reference field for the bottom field is the field immediately following the reference field for the top field. 
（フィールドインター１６ｘ１６は、トップフィールドとボトムフィールドの動きベクトルが同じにされる以外は、インター８ｘ１６モードに似ています。そして、ボトムフィールドの参照フィールドは、トップフィールドの参照フィールドの次に続くフィールドである。）
　
The advantage of the field 16x16 mode lies in the fact that it reduces the number of bits required to send the motion information and the extra reference field information. 
（フィールド１６ｘ１６モードの利点は、それが動き情報と余分な参照フィールド情報を送信するのに必要なビット数を減少させるという事実にある。）
　
These code modes are assigned the code numbers of 0, 1, 2, 3, 4 and 5 accordingly.
（これらのコードモードは、０、１、２、３、４、続く５のコード番号が割り当てられています。）
　
There will be no confusion with frame-based inter code modes because of the frame/field flag at MB level (see Fig. 2).
（ＭＢレベルでのフレーム/フィールドフラグのため、フレームベースのインター符号化モードとの混乱はありません。）（図２参照）
　
Reference Frames/Fields
（参照フレーム/フィールド）
　
　　　　　　　　　　　・
　　　　　　　　　　（略）
　　　　　　　　　　　・
　
PMV for Inter Blocks
（インターブロックのＰＭＶ）
　
The MVs are differentially coded.
（ＭＶｓは差動でコーディングされています。）
　
Assume block E, as shown in Fig. 9, is inter coded. 
（図９に示すように、ブロックＥを想定して、インターコード化します。）
　
The prediction for MV of block E is the median of the MVs of the neighboring blocks A, B, C and D, as shown in Fig. 9. 
（図９に示すように、ブロックＥのＭＶの予測は、隣接するブロックＡ、Ｂ、Ｃ、ＤのＭＶの中央値である。）
　
For definition of positions of A, B, C, and D, refer to TML8 [1]. 
（Ａ、Ｂ、Ｃ、Ｄの位置の定義については、ＴＭＬ８［１］を参照してください。）
　
Block E can now be either frame- or field-based block. 
（ブロックＥは現在、フレームまたはフィールドベースのブロックのどちらかを使用できます。）
　
In other words, all the frame- and field-based modes are allowed.
（言い換えれば、すべてのフレームとフィールドベースのモードは許可されています。）
　
1. If E is in frame-based, the MVs of A, B, C and D used in calculating PMV are also frame-based. 
（１．Ｅがフレームベースの場合、ＰＭＶを計算する際に使用されるＡ、Ｂ、ＣおよびＤのＭＶｓは、フレームベースです。）
　
If block A, B, C, or D is coded in field-based, the two field-based MVs are averaged and the vertical component of this averaged MV is multiplied by 2.
（もし、ブロックＡ、Ｂ、Ｃ、またはＤがフィールドベースでコーディングされている場合、２つのフィールドベースのＭＶｓは平均化され、この平均ＭＶの鉛直成分は２倍されます。）
　
2. If E is in field-based, the MVs of A, B, C and D used in calculating PMV are also field-based in the same field parity. 
（２．Ｅがフィールドベースの場合、ＰＭＶを計算する際に使用されるＡ、Ｂ、ＣおよびＤのＭＶｓも同じフィールドパリティのフィールドベースです。）
　
If A, B, C, or D is frame coded, the vertical component of MV is divided by 2.
（Ａ、Ｂ、Ｃ、Ｄのいずれかがフレームコーディングであれば、ＭＶの鉛直成分を２で割ります。）
　
For directional segmentation, follow the same conventions as in TML8 [1], but the neighboring blocks are in the same field parity.
（双方向セグメンテーションについては、ＴＭＬ８［１］と同じ規則に従いますが、隣接ブロックは同じフィールドパリティのものです。）
　
（　　　　　　　　　　　　　図９　　　　　　　　　　　　）
　
Fig. 9. Calculation of PMV.
（図９　ＰＭＶの計算。）
　　　　　　　　　　　・
　　　　　　　　　　（略）
　　　　　　　　　　　・
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　」
（引用例２の記載、以上）
　
　　以上の記載によると、引用例２では、
「Ｈ．２６Ｌ　ＴＭＬ８．５［１］は、入力フレームには、次の３つのピクチャタイプ（Ｉ、Ｐ、とＢ）を可能に」し、
「任意の画像タイプＩ、ＰまたはＢのフレームは１６ｘ１６ピクセルのＭＢに分割され」
「１６ｘ１６の各ＭＢはさらに、図１に示すように７つのパターン（モード）のいずれかのブロックに分割することができ」
「ブロックサイズは、１６ｘ１６、１６ｘ８、８ｘ１６、８ｘ８、８ｘ４、４ｘ８または４ｘ４とすることができ」
「ＭＢは、イントラかインターどちらかで符号化することができ」
「インターモードの場合、ＭＢは７つのモードのいずれかになり」
「ＭＢはＭＢモードに応じて、最大１６のＭＶを持つことができ」
「現在ＴＭＬ８．５は、プログレッシブスキャンビデオ素材用に設計され」
「現在ＴＭＬ８．５内のすべての符号化モードは、フレームベース」であるところ、
「インターレースビデオシーケンスのフレームは、異なる時刻でスキャンされた２つのフィールドから構成され」
「インターレースビデオから成るビデオシーケンスは、多くの異なる方法で圧縮することができ」
「これらは、主に２つのカテゴリに分類することができ」
　　それは、
「（ａ）固定フレーム/フィールド　と　（ｂ）適応フレーム/フィールド」であり、
「適応フィールド/フレーム方式では、コンテンツに応じて、フィールド構造を使用するかフレーム構造を使用するかを適応的に選択し」
「コンテンツの種類に基づいてフィールドまたはフレーム構造に関する決定がなされるところでの、コンテンツ適応フィールド/フレームベースのツールを紹介」している。
　
　　そして、
「フレームまたはフィールド符号化は、・・３つのレベルで適応することができ」「それは、シーケンスレベル、ピクチャーレベル、 ＭＢレベルであ」り、
「フレーム/フィールド符号化のＭＢレベルでの適応のため、ひとつのＭＢがフレームまたはフィールドベースでコーディングすることができ」
「図９に示すように、ブロックＥを想定して、インターコード化」するとき、「ブロックＥのＭＶの予測は、隣接するブロックＡ、Ｂ、Ｃ、ＤのＭＶの中央値であり」
「Ｅがフレームベースの場合、ＰＭＶを計算する際に使用されるＡ、Ｂ、ＣおよびＤのＭＶｓは、フレームベースで」あり
「もし、ブロックＡ、Ｂ、Ｃ、またはＤがフィールドベースでコーディングされている場合、２つのフィールドベースのＭＶｓは平均化され、この平均ＭＶの鉛直成分は２倍され」る。
　
　　ここでは、特定のマクロブロック（Ｅ）のＭＶ（動きベクトル）の予測を隣接するブロック（Ａ、Ｂ、Ｃ、Ｄ）のＭＶを用いて行う（中央値とする）とき、「Ｅがフレームベースの場合」「使用されるＡ、Ｂ、ＣおよびＤのＭＶｓは、フレームベースで」あり、「もし、ブロックＡ、Ｂ、Ｃ、またはＤがフィールドベースでコーディングされている場合、２つのフィールドベースのＭＶｓは平均化され、この平均ＭＶの鉛直成分は２倍され」るのであり、この「ブロックＡ、Ｂ、Ｃ、またはＤがフィールドベースでコーディングされている場合、２つのフィールドベースのＭＶｓは平均化され、この平均ＭＶの鉛直成分は２倍され」ることは、「隣接マクロブロックの動きベクトル情報を対象マクロブロックのフレームモードにあわせるように換算して」いるということができるものと認められる。
　
　　したがって、引用例２には、符号化モードがフレームベースである現在ＴＭＬ８．５に、適応フレーム/フィールドを採用したとき、対象のマクロブロックの動きベクトルの予測を、隣接するマクロブロックの動きベクトルを用いて行うにあたり、対象のマクロブロックをフレームベースで符号化するとき、隣接するマクロブロックがフィールドベースで符号化されている場合、予測に用いる隣接するマクロブロックの動きベクトルを対象マクロブロックのフレームモードにあわせるように換算」して予測をする技術が開示されているといえる。
　
　（イ）引用例１と引用例２
　　引用例１と引用例２とは共に「ＩＴＵ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ　Ｓｅｃｔｏｒ　ＳＴＵＤＹ　ＧＲＯＵＰ　１６　Ｑｕｅｓｔｉｏｎ　６　Ｖｉｄｅｏ　Ｃｏｄｉｎｇ　Ｅｘｐｅｒｔｓ　Ｇｒｏｕｐ」での提案であって、引用例１は算術符号化の段階での提案であり、引用例２は算術符号化より前の符号化の段階での提案であるが、これらの提案は各段階が組み合わさって符号化全体の仕組みとして構築されることを前提としたものと認められ、引用例２で提案される符号化の後に、引用例１で提案される算術符号化を組み合わすことは、符号化全体の仕組みを考える上で当業者が普通に想定するものと認められる。
　　
　　引用例１に記載された引用発明は、隣接するブロックのベクトルから得られるｅｋ（Ｃ）の値（｜ｍｖｄｋ（Ａ）｜＋｜ｍｖｄｋ（Ｂ）｜）の場合分けによって、
　
　　　　　　　　　　　　　　　　　０，ｅｋ（Ｃ）＜３，
　　ｃｔｘ＿ｍｖｄ（Ｃ，ｋ）　＝　１，ｅｋ（Ｃ）＞１５，
　　　　　　　　　　　　　　　　　２，ｅｌｓ
　
　　と、コンテキストモデルｃｔｘ＿ｍｖｄ（Ｃ、ｋ）が定義されるところ、
　　この定義は、「｜ｍｖｄｋ（Ａ）｜＋｜ｍｖｄｋ（Ｂ）｜」すなわち隣接するブロックのベクトルの大きさについて
　　ｅｋ（Ｃ）＜３　　：３より小さい
　　ｅｋ（Ｃ）＞１５　：１５より大きい
　　ｅｌｓ　　　　　　：その他（３と１５の間）
　と３つの場合に分け、すなわち、隣接するブロックのベクトルが小さいか、大きいか、中間の大きさかで、対象とするブロックのベクトルの算術符号化に用いる符号化すべき値と符号との対応関係をｃｔｘ＿ｍｖｄ（Ｃ，ｋ）の値（０か１か２）で特定し、その対応関係に従って算術符号化を行うものと認められ、その算術符号化に用いる対応関係は、発生確率の多い値に小さい符号量の符号を割り当てることで、符号量の少ない符号を発生させるためのものと認められる。
　　これは、結局、対象とするブロックのベクトルがどのようなものとなるか、隣接するブロックのベクトルに基づいてその大きさを推定することで、推定される大きさのベクトルの発生確率が高い対応関係を判断して選択しているといえ、引用発明は、対象とするブロックのベクトルがどのようなものとなるかを隣接するブロックのベクトルに基づいて判断することを前提とした技術といえる。
　　
　　引用例２の技術は、上記したように、対象マクロブロックのベクトルを隣接するブロックのベクトルから予測するものといえ、対象とするブロックのベクトルがどのようなものとなるかを隣接するブロックのベクトルに基づいて判断することを前提とした技術といえることは、引用発明と同様である。
　
　　上記のように、引用例２で提案される符号化の後に、引用例１で提案される算術符号化を組み合わすことは、符号化全体の仕組みを考える上で当業者が普通に想定するものと認められるところ、
　　「符号化モードがフレームベースである現在ＴＭＬ８．５に、適応フレーム/フィールドを採用したとき、対象のマクロブロックの動きベクトルの予測を、隣接するマクロブロックの動きベクトルを用いて行い、対象のマクロブロックをフレームベースで符号化するとき、隣接するマクロブロックがフィールドベースで符号化されている場合、予測に用いる隣接するマクロブロックの動きベクトルを対象マクロブロックのフレームモードにあわせるように換算して予測をする」ものである引用例２で提案される符号化の後に、引用例１で提案される算術符号化を組み合わせることとなるのであるから、組み合わせることになる引用例１で提案される算術符号化においても、前段階である引用例２で提案される符号化、すなわち、適応フレーム/フィールドを採用した符号化がなされていることを想定して、引用例１で提案される算術符号化で前提とする「対象とするブロックのベクトルがどのようなものとなるかを隣接するブロックのベクトルに基づいて判断すること」において、前段階で適応フレーム/フィールドを採用した符号化がなされていることの想定の下に、「適応フレーム/フィールドを採用した場合に、対象とするブロックのベクトルがどのようなものとなるかを隣接するブロックのベクトルに基づいて判断する」引用例２の技術を採用することは、容易に想到できることである。
　
　（ウ）相違点１について
　　引用例２の技術は、ブロックとしてマクロブロックを更にブロックに分割する前提で説明されているが、分割をしないでマクロブロックのままのブロックで、すなわち１６ｘ１６で符号化することが記載されており、引用例２で提案される符号化の後に引用例１で提案される算術符号化を組み合わせる際に、引用例１に記載された引用発明における対象ブロックと隣接ブロックを１６ｘ１６のマクロブロックで行うことが容易に想到される。
　　したがって、相違点１に係る補正後発明の構成は、当業者が容易に想到できるものといえる。
　
　（エ）相違点２について
　　上記（イ）で述べたように、算術符号化における動きベクトルの符号化に当たって、前段階の符号化に適応フレーム/フィールドを採用し、それに伴い、算術符号化においても適応フレーム/フィールドに対応するために、隣接するブロックのベクトルを「対象ブロックのフレームモードにあわせるように換算」することにより、相違点２に係る補正後発明の構成とすることは当業者が容易に想到できることといえる。
　
　（オ）総合
　　以上のとおり、相違点１および相違点２に係る補正後発明の構成は当業者が容易に想到できることといえるところ、相違点１に係る構成として、対象とするブロック、隣接するブロックを「マクロブロック」とすると、モデル算出の対象とするブロックも「マクロブロック」とすることが自然に想到されるから、相違点１および相違点２に係る補正後発明の構成を総合した補正後発明の構成も当業者が容易に想到できることといえ、補正後発明の効果も予測されるものと認められる。
　　したがって、補正後発明は、引用例１に記載された発明及び引用例２に記載の技術に基づいて、当業者が容易に発明をすることができたものである。
　
　（カ）まとめ
　以上のとおり、補正後発明は、引用例１に記載された発明及び引用例２に記載の技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができるものであるとはいうことができない。
　
　カ　補正の適法性まとめ
　以上のとおり、本件補正後の請求項７に係る発明は、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができるものであるとはいうことができないから、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反する。
　
（３）補正の却下の決定の理由のまとめ
　以上のとおりであるので、平成２３年４月１３日付けの手続補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
　よって、補正の却下の決定の結論のとおり、決定する。
　
３　本願発明
　上記のとおり、平成２３年４月１３日付けの手続補正を却下する。
　したがって、本件出願の請求項１ないし１１に係る発明は、平成２２年７月２３日付けで補正された特許請求の範囲の請求項１ないし１１に記載されたとおりのものであり、そのうち、請求項９に係る発明（以下、本願発明という）は、次のとおりである。
　
［本願発明］（【請求項９】）
　画像情報を符号化する符号化装置の符号化方法であって、
　コンテキストモデル手段が、符号化の対象となる対象マクロブロックに隣接する隣接マクロブロックがフィールドモードで符号化されており、前記対象マクロブロックをフレームモードで符号化する場合、前記隣接マクロブロックの動きベクトル情報を対象マクロブロックのフレームモードにあわせるように換算して、前記対象マクロブロックの動きベクトル情報に対応するコンテキストモデルを算出し、
　コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う
　符号化方法。
　
４　引用例
　引用例１には、上記［２　（２）　イ　引用例］のとおりの記載、引用発明が認められる。また、引用例２には、上記［２　（２）　オ　（ア）　引用例２］の記載、技術が認められる。
　
５　対比、一致点相違点
　補正後発明と本願発明との関係は、上記［２　（１）　補正の内容］のとおりであって、本願発明は補正後発明から「コンテキストモデルを算出する」構成について「換算された前記隣接マクロブロックの動きベクトル情報を用いて、」との特定を削除するものである。
　本願発明の「前記隣接マクロブロックの動きベクトル情報を対象マクロブロックのフレームモードにあわせるように換算して、前記対象マクロブロックの動きベクトル情報に対応するコンテキストモデルを算出」することは、、補正後発明で特定する「換算された前記隣接マクロブロックの動きベクトル情報を用いて、」算出を行うものと当然に認められるから、本願発明と引用発明との対比は上記［２　（２）　ウ　対比］と同様に対比され、本願発明と引用発明との一致点、相違点は次のとおりである。
　
［一致点］
　画像情報を符号化する符号化装置の符号化方法であって、
　コンテキストモデル手段が、符号化の対象となる対象ブロックに隣接する隣接ブロックの動きベクトル情報を用いて、前記対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出し、
　コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う
　符号化方法。
　
［相違点］
（相違点１）
　前記対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出し、コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う対象ブロック、及び、算出に用いる隣接ブロックが、本願発明では「マクロブロック」であることに対して、引用発明ではそうでない点。
　
（相違点２）
　対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出する際に用いる隣接ブロックの動きベクトル情報が、本願発明では、「隣接ブロックがフィールドモードで符号化されており、前記対象ブロックをフレームモードで符号化する場合、前記隣接ブロックの動きベクトル情報を対象ブロックのフレームモードにあわせるように換算して、換算された」動きベクトル情報であることに対して、引用発明ではそうでない点。
　
６　判断
　本願発明と引用発明との上記一致点、相違点は、補正後発明と引用発明との一致点、相違点と同じであり、補正後発明に対する上記［２　（２）　オ　判断］と同じく判断されるから、本願発明は、引用例１に記載された発明及び引用例２に記載の技術に基づいて、当業者が容易に発明をすることができたものである。
　
７　むすび
　以上のとおり、本件出願の請求項９に係る発明は、引用例１に記載された発明及び引用例２に記載の技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本件出願は、残る請求項１ないし８、請求項１０ないし１１に係る発明について特に検討するまでもなく拒絶されるべきものである。
　
　よって、結論のとおり審決する。