• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 H04N
審判 査定不服 2項進歩性 特許、登録しない。 H04N
審判 査定不服 5項独立特許用件 特許、登録しない。 H04N
管理番号 1268169
審判番号 不服2011-7789  
総通号数 158 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2013-02-22 
種別 拒絶査定不服の審決 
審判請求日 2011-04-13 
確定日 2013-01-04 
事件の表示 特願2007-281034「符号化装置および方法、記録媒体、並びに、プログラム」拒絶査定不服審判事件〔平成20年 5月 1日出願公開、特開2008-104205〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1 経緯
本件出願は、平成14年4月26日に出願した特願2002-125295号の一部を平成18年8月18日に新たな特許出願とした特願2006-223483号の一部を平成19年10月29日に新たな特許出願としたものであって、 平成22年5月19日付けで拒絶理由の通知がなされ、これに対し、平成22年7月23日付けで手続補正がなされたが、平成23年1月14日付けで拒絶査定がなされたものである。
本件は、上記拒絶査定を不服として平成23年4月13日付けで請求された拒絶査定不服審判であって、平成23年4月13日付けで手続補正(明細書、特許請求の範囲又は図面について請求と同時にする補正)がなされたものである。

2 補正の却下の決定
平成23年4月13日付けの手続補正について次のとおり決定する。

〈補正の却下の決定の結論〉
平成23年4月13日付けの手続補正を却下する。

〈補正の却下の決定の理由〉
(1)補正の内容
平成23年4月13日付けの手続補正(以下、本件補正という)は、特許請求の範囲について、補正前の請求項7、8を削除し、補正後の請求項1ないし9を補正前の請求項1ないし6、9ないし11にそれぞれ対応するものとし、補正前の独立項である請求項1、9、10、11の各「コンテキストモデルを算出する」構成について「換算された前記隣接マクロブロックの動きベクトル情報を用いて、」との特定を付加し、補正後の独立項である請求項1、7、8、9とする補正を含むものである。

(2)補正の適法性
「コンテキストモデルを算出する」構成について「換算された前記隣接マクロブロックの動きベクトル情報を用いて、」との特定を付加する補正は、特許請求の範囲の減縮を目的とする補正であると認められるので、独立特許要件について検討する。

ア 補正後発明
本件補正後の請求項1ないし9の内、請求項7に係る発明(以下、「補正後発明」ともいう)は、補正後の請求項7に記載されたところにより特定されるものと認められるところ、補正後の請求項7は次のとおりである。

[補正後発明](【請求項7】)
画像情報を符号化する符号化装置の符号化方法であって、
コンテキストモデル手段が、符号化の対象となる対象マクロブロックに隣接する隣接マクロブロックがフィールドモードで符号化されており、前記対象マクロブロックをフレームモードで符号化する場合、前記隣接マクロブロックの動きベクトル情報を対象マクロブロックのフレームモードにあわせるように換算して、換算された前記隣接マクロブロックの動きベクトル情報を用いて、前記対象マクロブロックの動きベクトル情報に対応するコンテキストモデルを算出し、
コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う
符号化方法。

イ 引用例
査定の理由として示された「Detlev Marpe et al.,Adaptive Codes for H.26L,ITU-Telecommunications Standardization Sector STUDY GROUP 16 Question 6 Video Coding Experts Group(V,International Telecommunications Union,2001年 1月 9日,p.1-8」(以下、「引用例1」ともいう)には、図、表と共に次の記載がある。

(引用例1の記載)
「1 Introduction
(1 はじめに)

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.
(いくつかの寄稿[1][2][3]で示されるように、現在のH.26Lテストモデルのエントロピー符号化方法に用いられるユニバーサル可変長符号(UVLC)は、符号化効率に関して最適化されていません。)

Proposals were made either to improve on the VLC table or to adapt the mapping between syntax elements and UVLC codewords.
(いくつかの提案が、VLCテーブルを改善するため、または、シンタックス要素とUVLC符号語の間のマッピングを修正させるためになされた。)

In this contribution, we present a more fundamental approach which is based on context-based adaptive binary arithmetic coding.
(この寄稿で、コンテキストベース適応2値算術符号化に基づく、より根本的なアプローチを提示する。)

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.
(これらの技法が、特に低いビットレートと高いビットレートで、テストモデルの圧縮性能を向上させることが示される。)

( 図1 )

Figure 1: Proposed entropy coding scheme
(図1:提案されたエントロピー符号化方式)

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.
(コンテキストモデルが異なるシンタックス要素のために選択されることを、セクション2と3で、詳細に説明します。)

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.
(実際のシンボルが非バイナリ値である場合、2番目のステップで、ビンと称されるバイナリ決定のシーケンス上にマッピングされます。)

The actual binarization is done according to a given binary tree, as specified in Section 4.
(セクション4で指定される与えられたバイナリツリーに従って、実際の2値化は行われます。)

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.
(最後に、それぞれのバイナリの決定は、コンテキストモデリング段階によって供給された確率モデルを使用して、2値算術符号化エンジンによりエンコードされる。)

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.
(図1は、全体のプロセスを示しています。)

2 Context Modeling for Coding of Motion and Mode Information
(2 モーションおよびモード情報の符号化のためのコンテキストモデリング)

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].
(このセクションでは、H.26LテストモデルTML-4 [4]の説明で定義されているよう、構文要素、マクロブロックタイプ(MB_type)、動きベクトルデータ(MVD)と参照フレームパラメータ(Ref_frame)のための、私たちの適応符号化方式のコンテクストモデリングの詳細を記述する。)

2.1 Context Models for Macroblock Type
(2.1 マクロブロックタイプのためのコンテキストモデル)


(略)

( 図2(a) 図2(b) )

Figure 2:
(図2)

(a) Neighboring symbols A and B used for conditional coding of a current symbol C.
((a)現在のシンボルCの条件付き符号化のために使用される隣接シンボルAとB)

(b) Neighboring blocks A and B used for conditional coding of motion vector data related to block C.
((b)ブロックCに関連した動きベクトルデータの条件付き符号化のために使用される隣接ブロックAとB)


(略)


2.2 Context Models for Motion Vector Data
(2.2 動きベクトルデータのためのコンテキストモデル)

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).
(与えられたブロックCにおける局所予測誤差の単純な尺度は、与えられたブロックの動きベクトル残差mvdk(C)の各コンポーネントのために、二つの隣接する動きベクトル予測残差mvdk(A)とmvdk(B)のL1ノルムek(A、B)=|mvdk(A)|+|mvdk(B)|を評価することによって与えられる。図2(b)に示すように、AとBはブロックCの隣接しているブロックである。)

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.
(隣接ブロックの一つが隣接するマクロブロックに属している場合、上方のブロックBについては一番左の隣接ブロックの残差ベクトル成分を取り、左側のブロックAについては一番上の隣接ブロックを使用します。)

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.
(例えば、現在のブロックが画像の境界に位置していることにより、隣接ブロックのいずれかが使用できない場合、我々は、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:
(ekを使用することにより、3つの異なるコンテキストモデルから成る残差動きベクトル成分mvdk(C)のコンテキストモデルctx_mvd(C、k)を定義します。

0,ek(C)<3,
ctx_mvd(C,k) = 1,ek(C)>15,
2,els

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).
(実際の符号化処理のために、mvdk(C)を符号と係数に分離します。|mvdk(C)|の二値化した最初のビン(桁)においてのみ、コンテキストモデル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.
(残りのビンにおいて、3つの追加モデルを持っています。2番目と3番目の桁に対する2つのモデルと残りのビンに対する3番目のモデルです。)

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.
(各ベクトル成分のための7つの異なったモデルをすべて合わせると結果となります。)

2.3 Context Models for Reference Frame Parameter
(2.3 リファレンスフレームパラメータのためのコンテキストモデル)


(略)


(引用例1の記載、以上)

以上の記載によると、引用例1には、エントロピー符号化方法におけるコンテキストベース適応2値算術符号化の手法について記載されており、このコンテキストベース適応2値算術符号化の手法は、全体のプロセスが図1に示され、
最初のステップ(コンテキストモデリング)で、適切なモデルを過去の観察値の集合に応じて選択し、
2番目のステップで、シンボルが非バイナリ値である場合、2値化を行い、
最後(のステップ)で、コンテキストモデリング段階(最初のステップ)によって供給された確率モデルを使用して、それぞれのバイナリの決定は、2値算術符号化エンジンによりエンコードされる。

コンテキストモデリングは、マクロブロックタイプ(MB_type)、動きベクトルデータ(MVD)と参照フレームパラメータ(Ref_frame)についてなされ、
動きベクトルデータ(MVD)については、図2(b)に示すように、AとBはブロックCの隣接しているブロックであるとして、与えられたブロックの動きベクトル残差mvdk(C)の各コンポーネントのために、二つの隣接する動きベクトル予測残差mvdk(A)とmvdk(B)のL1ノルムek(A、B)=|mvdk(A)|+|mvdk(B)|を評価し、

0,ek(C)<3,
ctx_mvd(C,k) = 1,ek(C)>15,
2,els

と、3つの異なるコンテキストモデルから成る残差動きベクトル成分mvdk(C)のコンテキストモデルctx_mvd(C、k)を定義し、二値化した最初のビン(桁)においてのみ、コンテキストモデルctx_mvd(C、k)を使用してコード化する。

このコンテキストベース適応2値算術符号化の手法を引用例1に記載された発明(以下、「引用発明」ともいう)として認定する。

ウ 対比
補正後発明と引用発明とを対比する。

(ア)「画像情報を符号化する符号化装置の符号化方法」

引用発明は、「コンテキストベース適応2値算術符号化の手法」であって、画像情報を符号化の対象とすると認められ、その符号化は普通に符号化装置においてなされることを想定するといえるから、「画像情報を符号化する符号化装置の符号化方法」といい得るものであり、この点で補正後発明と一致する。

(イ)「コンテキストモデル手段が、符号化の対象となる対象マクロブロックに隣接する隣接マクロブロックがフィールドモードで符号化されており、前記対象マクロブロックをフレームモードで符号化する場合、前記隣接マクロブロックの動きベクトル情報を対象マクロブロックのフレームモードにあわせるように換算して、換算された前記隣接マクロブロックの動きベクトル情報を用いて、前記対象マクロブロックの動きベクトル情報に対応するコンテキストモデルを算出し」

引用発明は、そのコンテキストモデリングにおいて、
「動きベクトルデータ(MVD)については、図2(b)に示すように、AとBはブロックCの隣接しているブロックであるとして、与えられたブロックの動きベクトル残差mvdk(C)の各コンポーネントのために、二つの隣接する動きベクトル予測残差mvdk(A)とmvdk(B)のL1ノルムek(A、B)=|mvdk(A)|+|mvdk(B)|を評価し、

0,ek(C)<3,
ctx_mvd(C,k) = 1,ek(C)>15,
2,els

と、3つの異なるコンテキストモデルから成る残差動きベクトル成分mvdk(C)のコンテキストモデルctx_mvd(C、k)を定義し、二値化した最初のビン(桁)においてのみ、コンテキストモデルctx_mvd(C、k)を使用してコード化する。」
のであり、
ブロックCを対象ブロックとして、「コンテキストモデル手段が、符号化の対象となる対象ブロックに隣接する隣接ブロックの動きベクトル情報を用いて、前記対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出」するといい得るから、この点で補正後発明と一致する。

しかしながら、まず、補正後発明では対象ブロックおよび隣接ブロックを「マクロブロック」と特定しているところ、引用発明ではそうでないことから、前記対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出し、コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う対象ブロック、及び、算出に用いる隣接ブロックが、補正後発明では「マクロブロック」であることに対して、引用発明ではそうでない点で相違する。

また、補正後発明は、コンテキストモデルの算出について、「符号化の対象となる対象マクロブロックに隣接する隣接マクロブロックがフィールドモードで符号化されており、前記対象マクロブロックをフレームモードで符号化する場合、前記隣接マクロブロックの動きベクトル情報を対象マクロブロックのフレームモードにあわせるように換算して、換算された前記隣接マクロブロックの動きベクトル情報を用いて」算出することを特定しているところ、引用発明はそうでないことから、上記「マクロブロック」に関する相違に加えて、コンテキストモデルの算出手法として、対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出する際に用いる隣接ブロックの動きベクトル情報が、補正後発明では、「隣接ブロックがフィールドモードで符号化されており、前記対象ブロックをフレームモードで符号化する場合、前記隣接ブロックの動きベクトル情報を対象ブロックのフレームモードにあわせるように換算して、換算された」動きベクトル情報であることに対して、引用発明ではそうでない点で相違する。

(ウ)「コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う」

引用発明は、最後(のステップ)で、コンテキストモデリング段階(最初のステップ)によって供給された確率モデル、すなわち、(イ)で上記した算出されたモデル、を使用して、それぞれのバイナリの決定は、2値算術符号化エンジンによりエンコードされるのであり、「コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う」といい得るものである。
したがって、補正後発明と引用発明とは、この点で一致する。

エ 一致点相違点
以上のとおり対比されるから、補正後発明と引用発明との一致点、相違点は次のとおりである。

[一致点]
画像情報を符号化する符号化装置の符号化方法であって、
コンテキストモデル手段が、符号化の対象となる対象ブロックに隣接する隣接ブロックの動きベクトル情報を用いて、前記対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出し、
コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う
符号化方法。

[相違点]
(相違点1)
前記対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出し、コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う対象ブロック、及び、算出に用いる隣接ブロックが、補正後発明では「マクロブロック」であることに対して、引用発明ではそうでない点。

(相違点2)
対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出する際に用いる隣接ブロックの動きベクトル情報が、補正後発明では、「隣接ブロックがフィールドモードで符号化されており、前記対象ブロックをフレームモードで符号化する場合、前記隣接ブロックの動きベクトル情報を対象ブロックのフレームモードにあわせるように換算して、換算された」動きベクトル情報であることに対して、引用発明ではそうでない点。

オ 判断
(ア) 引用例2
査定の理由として示された「L. Wamg et al.,Interlace Coding Tools for H.26L Video Coding,ITU-Telecommunications Standardization Sector STUDY GROUP 16 Question 6 Video Coding Experts Group(V,International Telecommunications Union,2001年12月 4日,p.1-20」(以下、「引用例2」ともいう)には、図、表と共に次の記載がある。

(引用例2の記載)
「1. Introduction
(1.はじめに)

H.26L TML 8.5 [1] allows three possible picture types for an input frame: I, P and B.
(H.26L TML8.5[1]は、入力フレームには、次の3つのピクチャタイプを可能にする。I、P、とB。)

A frame of any picture type I, P or B is divided into MBs of 16x16 pixels.
(任意の画像タイプI、PまたはBのフレームは16x16ピクセルのMBに分割されています。)

Each MB of 16x16 can be further divided into blocks in one of seven patterns (modes), as shown in Fig. 1.
(16x16の各MBはさらに、図1に示すように7つのパターン(モード)のいずれかのブロックに分割することができます。)

Block size can be 16x16, 16x8, 8x16, 8x8, 8x4, 4x8, or 4x4.
(ブロックサイズは、16x16、16x8、8x16、8x8、8x4、4x8または4x4とすることができます。)

A MB can be coded in either intra or inter.
(MBは、イントラかインターどちらかで符号化することができます。)

For intra mode, MB can be only in either mode 1 (block size of 16x16) or mode 7 (block size of 4x4).
(イントラモードの場合、MBはモード1(16x16のブロックサイズ)またはモード7(4x4のブロックサイズ)のどちらかにのみ指定できます。)

For inter mode, MB can be in any of seven modes.
(インターモードの場合、MBは7つのモードのいずれかになります。)

Motion estimation and compensation (ME/MC) is performed for these blocks separately.
(動き予測と補償(ME/MC)はこれらのブロック毎に実行されます。)

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.
(言い換えれば、MB内の各ブロックは、個別のMVを持っており、それ故に、MBはMBモードに応じて、最大16のMVを持つことができます。)

( 図1 )

Fig. 1. Seven frame-based block patterns (modes) per MB.
(図1。MBにおける7つのフレームベースブロックパターン(モード)。)

The current TML 8.5 is designed for progressively scanned video materials.
(現在TML8.5は、プログレッシブスキャンビデオ素材用に設計されています。)

All the code modes in the current TML 8.5 are frame-based.
(現在TML8.5内のすべての符号化モードは、フレームベースです。)

Nature of interlace video materials and its possible impact on H.26L has been under discussion [2], [3], [4], [5], [6].
(インターレースビデオ素材の性質とH.26Lにおける影響の可能性が議論[2]、[3]、[4]、[5]、[6]の下にあります。)

In particular, a frame of interlace video sequence consists of two fields, scanned at different time instants.
(具体的には、インターレースビデオシーケンスのフレームは、異なる時刻でスキャンされた2つのフィールドから構成されています。)

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
(これらは、主に2つのカテゴリに分類することができます。
(a)固定フレーム/フィールド と
(b)適応フレーム/フィールド )

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
(2.インターレースコーディング)

Inputs to the H.26L video code can be considered as a series of units at three different levels: sequence, picture, and MB.
(H.26Lビデオコードへの入力は、3つの異なるレベルでのユニットのシリーズとして考えることができる。シーケンス、ピクチャ、および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.
(フレームまたはフィールド符号化は、これらの3つのレベルで適応することができる。それは、シーケンスレベル、ピクチャーレベル、 MBレベルである。)

2.1 Fixed Frame/Field - Sequence Level
(2.1 固定フレーム/フィールド - シーケンスレベル)


(略)


2.2 Adaptive Frame/Field Coding - Picture Level
(2.2 適応フレーム/フィールド符号化 - ピクチャーレベル)


(略)


2.3 Adaptive Frame/Field Coding - MB Level
(2.3 適応フレーム/フィールド符号化 - MBレベル)

For MB level adaptation of frame/field coding, a MB can be coded in frame- or field-based.
(フレーム/フィールド符号化のMBレベルでの適応のため、ひとつのMBがフレームまたはフィールドベースでコーディングすることができます。)

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.
(図2に示すように、MBがフレームまたはフィールドベースでコード化されている場合を示すために、フレーム/フィールドフラグは、MBレベルで必要であるかもしれません。)

"0" indicates frame-based coding and "1" field-based coding.
(”0”はフレームベースのコーディング、”1”はフィールドベースのコーディングを示します。)

Frame-based coding of a MB follows TML 8.5.
(MBのフレームベースのコーディングは、TML8.5に従う。)

Field-based coding will be described as follows.
(フィールドベースのコーディングは次に説明する。)

( 図2 )

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.
(図2。1ビットのフレーム/フィールドフラグは、次のMBがフレームまたはフィールドベースでコーディングされている場合を示すために、必要になることがあります。)

Five additional block patterns are introduced for field-based coding, as shown in Fig. 3.
(図3に示すように、5つの追加ブロックパターンは、フィールドベース符号化のために導入されています。)

For field-based coding, a MB is first split into two fields of top and bottom.
(フィールドベース符号化のために、MBは、まず、TOPフィールドとBOTTOMフィールドに分割されます。)

The split MB is then further divided into one of five possible block patterns.
(分割されたMBは、その後さらに5つの可能なブロックパターンのいずれかに分かれています。)

Similar to in frame mode, a MB in field mode can be coded in intra or inter mode.
(フレームモードと同様に、フィールドモードでMBがイントラまたはインターモードでコーディングすることができます。)

( 図3 )

Fig.3.
(図3)
Five additional field-based block patterns (modes) per MB.
(MBあたりフィールドベースの5つの追加ブロックパターン(モード)。)
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.
(インターコードモードでは、ME/MCは、各フレーム/フィールドブロックに対して設定されている。)

As in frame mode, there are also up to 16 blocks per MB in field mode (see Fig. 3).
(フレームモードのように、フィールドモードでMBあたり最大16ブロックあります。(図3参照))

The smallest block is 4x4. Hence, there are up to 16 MVs per MB in field mode.
(最小ブロックは4x4である。したがって、フィールドモードでMBあたり最大16のMVがあります。)

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.
(6つのフィールドベースME/MCコードモードは、ひとつのMBを符号化可能なコードモードを指定できます。)

They are field inter 16x16, inter 8x16, inter 8x8, inter 4x8, inter 8x4, and inter 4x4.
(それは、フィールドインター16x16、インター8x16、インター8x8、インター4x8、インター8x4、およびインター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.
(フィールドインター16x16は、トップフィールドとボトムフィールドの動きベクトルが同じにされる以外は、インター8x16モードに似ています。そして、ボトムフィールドの参照フィールドは、トップフィールドの参照フィールドの次に続くフィールドである。)

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.
(フィールド16x16モードの利点は、それが動き情報と余分な参照フィールド情報を送信するのに必要なビット数を減少させるという事実にある。)

These code modes are assigned the code numbers of 0, 1, 2, 3, 4 and 5 accordingly.
(これらのコードモードは、0、1、2、3、4、続く5のコード番号が割り当てられています。)

There will be no confusion with frame-based inter code modes because of the frame/field flag at MB level (see Fig. 2).
(MBレベルでのフレーム/フィールドフラグのため、フレームベースのインター符号化モードとの混乱はありません。)(図2参照)

Reference Frames/Fields
(参照フレーム/フィールド)


(略)


PMV for Inter Blocks
(インターブロックのPMV)

The MVs are differentially coded.
(MVsは差動でコーディングされています。)

Assume block E, as shown in Fig. 9, is inter coded.
(図9に示すように、ブロックEを想定して、インターコード化します。)

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.
(図9に示すように、ブロックEのMVの予測は、隣接するブロックA、B、C、DのMVの中央値である。)

For definition of positions of A, B, C, and D, refer to TML8 [1].
(A、B、C、Dの位置の定義については、TML8[1]を参照してください。)

Block E can now be either frame- or field-based block.
(ブロックEは現在、フレームまたはフィールドベースのブロックのどちらかを使用できます。)

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.
(1.Eがフレームベースの場合、PMVを計算する際に使用されるA、B、CおよびDのMVsは、フレームベースです。)

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.
(もし、ブロックA、B、C、またはDがフィールドベースでコーディングされている場合、2つのフィールドベースのMVsは平均化され、この平均MVの鉛直成分は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.
(2.Eがフィールドベースの場合、PMVを計算する際に使用されるA、B、CおよびDのMVsも同じフィールドパリティのフィールドベースです。)

If A, B, C, or D is frame coded, the vertical component of MV is divided by 2.
(A、B、C、Dのいずれかがフレームコーディングであれば、MVの鉛直成分を2で割ります。)

For directional segmentation, follow the same conventions as in TML8 [1], but the neighboring blocks are in the same field parity.
(双方向セグメンテーションについては、TML8[1]と同じ規則に従いますが、隣接ブロックは同じフィールドパリティのものです。)

( 図9 )

Fig. 9. Calculation of PMV.
(図9 PMVの計算。)

(略)


(引用例2の記載、以上)

以上の記載によると、引用例2では、
「H.26L TML8.5[1]は、入力フレームには、次の3つのピクチャタイプ(I、P、とB)を可能に」し、
「任意の画像タイプI、PまたはBのフレームは16x16ピクセルのMBに分割され」
「16x16の各MBはさらに、図1に示すように7つのパターン(モード)のいずれかのブロックに分割することができ」
「ブロックサイズは、16x16、16x8、8x16、8x8、8x4、4x8または4x4とすることができ」
「MBは、イントラかインターどちらかで符号化することができ」
「インターモードの場合、MBは7つのモードのいずれかになり」
「MBはMBモードに応じて、最大16のMVを持つことができ」
「現在TML8.5は、プログレッシブスキャンビデオ素材用に設計され」
「現在TML8.5内のすべての符号化モードは、フレームベース」であるところ、
「インターレースビデオシーケンスのフレームは、異なる時刻でスキャンされた2つのフィールドから構成され」
「インターレースビデオから成るビデオシーケンスは、多くの異なる方法で圧縮することができ」
「これらは、主に2つのカテゴリに分類することができ」
それは、
「(a)固定フレーム/フィールド と (b)適応フレーム/フィールド」であり、
「適応フィールド/フレーム方式では、コンテンツに応じて、フィールド構造を使用するかフレーム構造を使用するかを適応的に選択し」
「コンテンツの種類に基づいてフィールドまたはフレーム構造に関する決定がなされるところでの、コンテンツ適応フィールド/フレームベースのツールを紹介」している。

そして、
「フレームまたはフィールド符号化は、・・3つのレベルで適応することができ」「それは、シーケンスレベル、ピクチャーレベル、 MBレベルであ」り、
「フレーム/フィールド符号化のMBレベルでの適応のため、ひとつのMBがフレームまたはフィールドベースでコーディングすることができ」
「図9に示すように、ブロックEを想定して、インターコード化」するとき、「ブロックEのMVの予測は、隣接するブロックA、B、C、DのMVの中央値であり」
「Eがフレームベースの場合、PMVを計算する際に使用されるA、B、CおよびDのMVsは、フレームベースで」あり
「もし、ブロックA、B、C、またはDがフィールドベースでコーディングされている場合、2つのフィールドベースのMVsは平均化され、この平均MVの鉛直成分は2倍され」る。

ここでは、特定のマクロブロック(E)のMV(動きベクトル)の予測を隣接するブロック(A、B、C、D)のMVを用いて行う(中央値とする)とき、「Eがフレームベースの場合」「使用されるA、B、CおよびDのMVsは、フレームベースで」あり、「もし、ブロックA、B、C、またはDがフィールドベースでコーディングされている場合、2つのフィールドベースのMVsは平均化され、この平均MVの鉛直成分は2倍され」るのであり、この「ブロックA、B、C、またはDがフィールドベースでコーディングされている場合、2つのフィールドベースのMVsは平均化され、この平均MVの鉛直成分は2倍され」ることは、「隣接マクロブロックの動きベクトル情報を対象マクロブロックのフレームモードにあわせるように換算して」いるということができるものと認められる。

したがって、引用例2には、符号化モードがフレームベースである現在TML8.5に、適応フレーム/フィールドを採用したとき、対象のマクロブロックの動きベクトルの予測を、隣接するマクロブロックの動きベクトルを用いて行うにあたり、対象のマクロブロックをフレームベースで符号化するとき、隣接するマクロブロックがフィールドベースで符号化されている場合、予測に用いる隣接するマクロブロックの動きベクトルを対象マクロブロックのフレームモードにあわせるように換算」して予測をする技術が開示されているといえる。

(イ)引用例1と引用例2
引用例1と引用例2とは共に「ITU-Telecommunications Standardization Sector STUDY GROUP 16 Question 6 Video Coding Experts Group」での提案であって、引用例1は算術符号化の段階での提案であり、引用例2は算術符号化より前の符号化の段階での提案であるが、これらの提案は各段階が組み合わさって符号化全体の仕組みとして構築されることを前提としたものと認められ、引用例2で提案される符号化の後に、引用例1で提案される算術符号化を組み合わすことは、符号化全体の仕組みを考える上で当業者が普通に想定するものと認められる。

引用例1に記載された引用発明は、隣接するブロックのベクトルから得られるek(C)の値(|mvdk(A)|+|mvdk(B)|)の場合分けによって、

0,ek(C)<3,
ctx_mvd(C,k) = 1,ek(C)>15,
2,els

と、コンテキストモデルctx_mvd(C、k)が定義されるところ、
この定義は、「|mvdk(A)|+|mvdk(B)|」すなわち隣接するブロックのベクトルの大きさについて
ek(C)<3 :3より小さい
ek(C)>15 :15より大きい
els :その他(3と15の間)
と3つの場合に分け、すなわち、隣接するブロックのベクトルが小さいか、大きいか、中間の大きさかで、対象とするブロックのベクトルの算術符号化に用いる符号化すべき値と符号との対応関係をctx_mvd(C,k)の値(0か1か2)で特定し、その対応関係に従って算術符号化を行うものと認められ、その算術符号化に用いる対応関係は、発生確率の多い値に小さい符号量の符号を割り当てることで、符号量の少ない符号を発生させるためのものと認められる。
これは、結局、対象とするブロックのベクトルがどのようなものとなるか、隣接するブロックのベクトルに基づいてその大きさを推定することで、推定される大きさのベクトルの発生確率が高い対応関係を判断して選択しているといえ、引用発明は、対象とするブロックのベクトルがどのようなものとなるかを隣接するブロックのベクトルに基づいて判断することを前提とした技術といえる。

引用例2の技術は、上記したように、対象マクロブロックのベクトルを隣接するブロックのベクトルから予測するものといえ、対象とするブロックのベクトルがどのようなものとなるかを隣接するブロックのベクトルに基づいて判断することを前提とした技術といえることは、引用発明と同様である。

上記のように、引用例2で提案される符号化の後に、引用例1で提案される算術符号化を組み合わすことは、符号化全体の仕組みを考える上で当業者が普通に想定するものと認められるところ、
「符号化モードがフレームベースである現在TML8.5に、適応フレーム/フィールドを採用したとき、対象のマクロブロックの動きベクトルの予測を、隣接するマクロブロックの動きベクトルを用いて行い、対象のマクロブロックをフレームベースで符号化するとき、隣接するマクロブロックがフィールドベースで符号化されている場合、予測に用いる隣接するマクロブロックの動きベクトルを対象マクロブロックのフレームモードにあわせるように換算して予測をする」ものである引用例2で提案される符号化の後に、引用例1で提案される算術符号化を組み合わせることとなるのであるから、組み合わせることになる引用例1で提案される算術符号化においても、前段階である引用例2で提案される符号化、すなわち、適応フレーム/フィールドを採用した符号化がなされていることを想定して、引用例1で提案される算術符号化で前提とする「対象とするブロックのベクトルがどのようなものとなるかを隣接するブロックのベクトルに基づいて判断すること」において、前段階で適応フレーム/フィールドを採用した符号化がなされていることの想定の下に、「適応フレーム/フィールドを採用した場合に、対象とするブロックのベクトルがどのようなものとなるかを隣接するブロックのベクトルに基づいて判断する」引用例2の技術を採用することは、容易に想到できることである。

(ウ)相違点1について
引用例2の技術は、ブロックとしてマクロブロックを更にブロックに分割する前提で説明されているが、分割をしないでマクロブロックのままのブロックで、すなわち16x16で符号化することが記載されており、引用例2で提案される符号化の後に引用例1で提案される算術符号化を組み合わせる際に、引用例1に記載された引用発明における対象ブロックと隣接ブロックを16x16のマクロブロックで行うことが容易に想到される。
したがって、相違点1に係る補正後発明の構成は、当業者が容易に想到できるものといえる。

(エ)相違点2について
上記(イ)で述べたように、算術符号化における動きベクトルの符号化に当たって、前段階の符号化に適応フレーム/フィールドを採用し、それに伴い、算術符号化においても適応フレーム/フィールドに対応するために、隣接するブロックのベクトルを「対象ブロックのフレームモードにあわせるように換算」することにより、相違点2に係る補正後発明の構成とすることは当業者が容易に想到できることといえる。

(オ)総合
以上のとおり、相違点1および相違点2に係る補正後発明の構成は当業者が容易に想到できることといえるところ、相違点1に係る構成として、対象とするブロック、隣接するブロックを「マクロブロック」とすると、モデル算出の対象とするブロックも「マクロブロック」とすることが自然に想到されるから、相違点1および相違点2に係る補正後発明の構成を総合した補正後発明の構成も当業者が容易に想到できることといえ、補正後発明の効果も予測されるものと認められる。
したがって、補正後発明は、引用例1に記載された発明及び引用例2に記載の技術に基づいて、当業者が容易に発明をすることができたものである。

(カ)まとめ
以上のとおり、補正後発明は、引用例1に記載された発明及び引用例2に記載の技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許出願の際独立して特許を受けることができるものであるとはいうことができない。

カ 補正の適法性まとめ
以上のとおり、本件補正後の請求項7に係る発明は、特許法第29条第2項の規定により特許出願の際独立して特許を受けることができるものであるとはいうことができないから、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反する。

(3)補正の却下の決定の理由のまとめ
以上のとおりであるので、平成23年4月13日付けの手続補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって、補正の却下の決定の結論のとおり、決定する。

3 本願発明
上記のとおり、平成23年4月13日付けの手続補正を却下する。
したがって、本件出願の請求項1ないし11に係る発明は、平成22年7月23日付けで補正された特許請求の範囲の請求項1ないし11に記載されたとおりのものであり、そのうち、請求項9に係る発明(以下、本願発明という)は、次のとおりである。

[本願発明](【請求項9】)
画像情報を符号化する符号化装置の符号化方法であって、
コンテキストモデル手段が、符号化の対象となる対象マクロブロックに隣接する隣接マクロブロックがフィールドモードで符号化されており、前記対象マクロブロックをフレームモードで符号化する場合、前記隣接マクロブロックの動きベクトル情報を対象マクロブロックのフレームモードにあわせるように換算して、前記対象マクロブロックの動きベクトル情報に対応するコンテキストモデルを算出し、
コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う
符号化方法。

4 引用例
引用例1には、上記[2 (2) イ 引用例]のとおりの記載、引用発明が認められる。また、引用例2には、上記[2 (2) オ (ア) 引用例2]の記載、技術が認められる。

5 対比、一致点相違点
補正後発明と本願発明との関係は、上記[2 (1) 補正の内容]のとおりであって、本願発明は補正後発明から「コンテキストモデルを算出する」構成について「換算された前記隣接マクロブロックの動きベクトル情報を用いて、」との特定を削除するものである。
本願発明の「前記隣接マクロブロックの動きベクトル情報を対象マクロブロックのフレームモードにあわせるように換算して、前記対象マクロブロックの動きベクトル情報に対応するコンテキストモデルを算出」することは、、補正後発明で特定する「換算された前記隣接マクロブロックの動きベクトル情報を用いて、」算出を行うものと当然に認められるから、本願発明と引用発明との対比は上記[2 (2) ウ 対比]と同様に対比され、本願発明と引用発明との一致点、相違点は次のとおりである。

[一致点]
画像情報を符号化する符号化装置の符号化方法であって、
コンテキストモデル手段が、符号化の対象となる対象ブロックに隣接する隣接ブロックの動きベクトル情報を用いて、前記対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出し、
コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う
符号化方法。

[相違点]
(相違点1)
前記対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出し、コンテキスト適応算術符号化手段が、算出された前記コンテキストモデルを用いて、前記画像情報にコンテキスト適応算術符号化を行う対象ブロック、及び、算出に用いる隣接ブロックが、本願発明では「マクロブロック」であることに対して、引用発明ではそうでない点。

(相違点2)
対象ブロックの動きベクトル情報に対応するコンテキストモデルを算出する際に用いる隣接ブロックの動きベクトル情報が、本願発明では、「隣接ブロックがフィールドモードで符号化されており、前記対象ブロックをフレームモードで符号化する場合、前記隣接ブロックの動きベクトル情報を対象ブロックのフレームモードにあわせるように換算して、換算された」動きベクトル情報であることに対して、引用発明ではそうでない点。

6 判断
本願発明と引用発明との上記一致点、相違点は、補正後発明と引用発明との一致点、相違点と同じであり、補正後発明に対する上記[2 (2) オ 判断]と同じく判断されるから、本願発明は、引用例1に記載された発明及び引用例2に記載の技術に基づいて、当業者が容易に発明をすることができたものである。

7 むすび
以上のとおり、本件出願の請求項9に係る発明は、引用例1に記載された発明及び引用例2に記載の技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
したがって、本件出願は、残る請求項1ないし8、請求項10ないし11に係る発明について特に検討するまでもなく拒絶されるべきものである。

よって、結論のとおり審決する。
 
審理終結日 2012-11-01 
結審通知日 2012-11-06 
審決日 2012-11-19 
出願番号 特願2007-281034(P2007-281034)
審決分類 P 1 8・ 121- Z (H04N)
P 1 8・ 575- Z (H04N)
P 1 8・ 121- Z (H04N)
最終処分 不成立  
前審関与審査官 古市 徹  
特許庁審判長 奥村 元宏
特許庁審判官 藤内 光武
小池 正彦
発明の名称 符号化装置および方法、記録媒体、並びに、プログラム  
代理人 稲本 義雄  

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