• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04N
管理番号 1287786
審判番号 不服2012-819  
総通号数 175 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2014-07-25 
種別 拒絶査定不服の審決 
審判請求日 2012-01-16 
確定日 2014-05-14 
事件の表示 特願2007-555132「アジャイル・デコーダ」拒絶査定不服審判事件〔平成18年 8月24日国際公開、WO2006/088644、平成20年10月23日国内公表、特表2008-538457〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
本願は、2006年(平成18年)2月1日(パリ条約による優先権主張外国庁受理2005年2月16日、米国)を国際出願日とする出願であって、平成21年1月26日付で審査請求がなされるとともに手続補正書が提出され、平成23年4月7日付(起案日)で拒絶の理由が通知されたが、出願人からは何らの応答も無く、平成23年9月9日付(起案日)で拒絶査定がなされたものである。
本件は、上記拒絶査定を不服として平成24年1月16日付で請求された拒絶査定不服審判であって、平成24年2月6日付手続補正書によって請求の理由が補正され、当審において、平成24年12月10日付(起案日)で拒絶の理由が通知され、平成25年4月11日付で意見書・手続補正書が提出され、平成25年4月25日付(起案日)で拒絶の理由が通知され、平成25年11月7日付で意見書・手続補正書が提出されたものである。

2.本願発明
本願の請求項9に係る発明は、平成21年1月26日付、平成25年4月11日付、平成25年11月7日付手続補正書によって補正された明細書、特許請求の範囲及び図面の記載からみて、その特許請求の範囲の請求項9に記載されたとおりの以下のものと認める。(以下「本願発明」という。)

「【請求項9】
少なくとも第1および第2のビデオ・ストリームを復号する方法であって、
前記少なくとも第1および第2のビデオ・ストリームのそれぞれを、復号を行うためにルーティングするステップと、
少なくとも第1および第2の圧縮解除ビデオ・ストリームをそれぞれ生成するための、前記少なくとも第1および第2のビデオ・ストリームのそれぞれを復号するステップであって、前記少なくとも第1および第2のビデオ・ストリームが空間的に並列に独立して復号されるステップと、
前記少なくとも第1および第2の圧縮解除ビデオ・ストリームのそれぞれのフレームを第1および第2のプレゼンテーション・バッファ・ステージそれぞれに記憶するステップと、
前記第1および第2の圧縮解除ビデオ・ストリームの記憶したフレームを、共通のサイズにスケーリングするステップと、
を含む、前記方法。」

3.引用刊行物
3.1.引用例1
3.1.1.引用例1の記載事項
当審における平成25年4月25日付の拒絶の理由で引用した『Paramvir Bahl, Paul S. Gauthier, Robert A. Ulichney,“Software-only Compression, Rendering, and Playback of Digital Video”, Digital Technical Journal, 米国, 1995発行, Vol.7, No.4, p.52-75, http://www.hpl.hp.com/hpjournal/dtj/vol7num4/vol7num4art4.pdf』(以下「引用例1」という。)には、図面とともに以下の記載がある。(なお、括弧内に当審で作成した翻訳を付記する。)

“We follow that discussion with the section The Software Video Library, in which we present a common architecture for video compression, decompression, and playback that allows integration into Digital’s multimedia products. We then describe two sample applications, the Video Odyssey screen saverand a software-only video player. We conclude our paper by surveying related work in this rapidly evolving area of software digital video.”(第52頁右欄下から6行?第53頁左欄第3行)
(「ソフトウェア・ビデオ・ライブラリという項目において、ディジタルのマルチメディア製品への組込が可能な、ビデオ圧縮、ビデオ圧縮の復号、および、再生についての共通アーキテクチャについての議論を行う。」)



”(第53頁)



”(第58頁)

“The Software Video Library”(第60頁右欄第1行)
(「ソフトウェア・ビデオ・ライブラリ」)

“A second observation was that multiple emerging audio/video compression standards, both formal and industry de facto, were gaining popularity with application vendors and hence needed to be supported on Digital's platforms. On careful examination of the compression algorithms, we observed that most of the prominent schemes used common building blocks (see Figure 2). For example, all five international standards-JPEG, MPEG-1, MPEG-2, H.261, and H.263-have DCT-based transform coders followed by a quantizer. Similarly, all five use Huffman coding in their final step. This meant that work done on one codec could be reused for others.”(第60頁右欄第27?39行)
(「2つめの検討事項は、公式の標準であれ事実上の工業標準であれ、各種の新たなオーディオ/ビデオ圧縮規格がアプリケーションを供給する者の間で普及しつつあるため、ディジタルのプラットフォームでサポートする必要が出てきたことである。圧縮アルゴリズムを慎重に検討した結果、殆どの有名な手法が、共通の構成を用いていることを発見した。たとえば、JPEG, MPEG-1, MPEG-2, H.261, H.263のような5種類の国際標準では、DCTを用いる変換符号化器とそれに続く量子化器を用いている。同様に、これら5種類は最終段階にハフマン符号化を採用している。これは、一つのコーデックのための作業を、他のものに対して再利用できることを示している。」)

“Architecture
Keeping in mind the observations outlined above, we designed a software video library (SLIB) that would
・ Provide a common architecture under which multiple audio and video codecs and renderers could be accessed
・ Be the lowest, functionally complete layer in the software video codec hierarchy
・ Be fast, extensible, and thread-safe, providing reentrant code with minimal overhead
・ Provide an intuitive, simple, flexible, and extensible application programming interface (API) that supports a client-server model of multimedia computing
・ Provide an API that would accommodate multiple upper layers, allowing for easy and seamless integration into Digital's multimedia products
Our intention was not to create a library that would be exposed to end-user applications but to create one that would provide a common architecture for video codecs for easy integration into Digital's multimedia products. SLIB's API was purposely designed to be a superset of Digital's Multimedia Services' API for greater flexibility in terms of algorithmic tuning and control. The library would fit well under the actual programming interface provided to end users by Digital's Multimedia Services. Digital's Multimedia API is the same as Microsoft's Video For Windows API, which facilitates the porting of multimedia applications from Windows and Windows NT to Digital UNIX and OpenVMS platforms. Figure 7 shows SLIB in relation to Digital's multimedia software hierarchy. The shaded regions indicate the topics discussed in this paper. As mentioned, the library contains routines for audio and video codecs and Digital's propriety videorendering algorithms. The routines are optimized both algorithmically and for the particular platform on which they are offered. The software has been successfully implemented on multiple platforms, including the Digital UNIX, the OpenVMS, and Microsoft's Windows NT operating systems. Three classes of routines are provided for the three subsystems: (1) video compression and decompression, (2) video rendering, and (3) audio processing. For each subsystem, routines can be further classified as (a) setup routines, (b) action routines, (c) query routines, and (d) teardown routines. Setup routines create and initialize all relevant internal data structures. They also compute values for the various look-up tables such as the ones used by the rendering subsystem. Action routines perform the actual coding, decoding, and rendering operations. Query routines may be used before setup or between action routines. These provide the programmer with information about the capability of the codec such as whether or not it can handle a particular input format and provide information about the bit stream being processed. These routines can also be used for gathering statistics. Teardown routines, as the name suggests, are used for closing the codec and destroying all internal memory (state information) associated with it. For all video codecs, SLIB provides convenience functions to construct a table of contents containing the offsets to the start of frames in the input bit stream. These convenience functions are useful for short clips: once a table of contents is built, random access and other VCR functions can be implemented easily. (These routines are discussed further in the section on sample applications.)”(第61頁左欄第4行?第62頁左欄第14行)
(「アーキテクチャ
上に示した検討事項を前提として、我々が設計したソフトウェア・ビデオ・ライブラリ(SLIB)は、

・ 複数のオーディオ/ビデオ・コーデックとレンダラーを用いることができるような共通のアーキテクチャを与えるものである。
・ ソフトウェア・ビデオ・コーデックの階層構造の中で、最も最下位の機能的に完全な層を与えるものである。
・ 最小のオーバーヘッド、高速、拡張可能の、スレッドセーフ、リエントラントなコードを与えるものである。
・ マルチメディア・コンピューティングにおけるクライアント・サーバモデルが可能な、直感的、簡素、フレキシブル、拡張可能なアプリケーションプログラミングインタフェース(API)を与えるものである。
・ 複数の上位層に対して対応可能なものであって、ディジタルのマルチメディア製品に簡易かつシームレスに組み込むことが可能なAPIを与えるものである。

我々の目的は、エンドユーザのアプリケーションに用いることができるライブラリを作成することではなく、ディジタルのマルチメディア製品に容易に組み込むことができるビデオ・コーデックのための共通アーキテクチャを供給することである。SLIBのAPIは、アルゴリズムの調整と制御に関する自由度を大きくするため、ディジタルのマルチメディアサービスのAPIのスーパーセットとして設計されている。ライブラリは、ディジタルのマルチメディアサービスによってエンド・ユーザに供給される実際のプログラミング・インターフェースの下に入り込むようになっている。ディジタルのマルチメディアAPIは、WindowsやWindows NT上のマルチメディア・アプリケーションを、ディジタルのUNIXやOpen VMSへの移植を容易になるように、マイクロソフトのVideo for WindowsのAPIと同じものとなっている。図7はSLIBとディジタルのマルチメディア・ソフトウェアの階層構造の関係を示している。影付きの場所がこの論文で議論する部分である。
既に述べたように、ライブラリは、オーディオ/ビデオ・コーデックと、ディジタルが所有するビデオ・レンダリング・アルゴリズムのためのルーチンを含んでいる。それらルーチンは、アルゴリズム、および、対象のプラットフォーム、双方に対して最適化されている。ソフトウェアは、ディジタルのUNIX、Open VMS、マイクロソフトのWindows NTを含む複数のプラットフォームに対して供給されている。
3つの種類のルーチンが、(1)ビデオ圧縮符号化と復号化、(2)ビデオ・レンダリング、(3)オーディオ処理という、3つのサブシステムに対して供給されている。それぞれのサブシステムに対して、これらルーチンは、(a)セットアップ・ルーチン、(b)実行ルーチン、(c)問い合わせルーチン、(d)破壊ルーチン、のように更に分類することができる。セットアップ・ルーチンは、すべての必要な内部データ構造を作成し初期化し、更に、レンダリング・サブシステムでもちいられるような、各種のルックアップテーブルの値を計算する。実行ルーチンは、実際の符号化、復号化、レンダリングを実行する。問い合わせルーチンは、セット・アップルーチンと、実行ルーチンの間で用いることができ、例えば、ある入力フォーマットを扱うことができるかどうかというようなそのコーデックの能力に関する情報、ビットストリームが処理中かどうかという情報を、プログラマーに与える。また、このルーチンは、統計情報を得ることに用いることもできる。破壊ルーチンは、その名前が示すように、コーデックの終了とそれに伴う内部記憶(状態情報)を破壊することに用いられる。すべてのビデオ・コーデックのために、SLIBは、入力ビデオストリームにおける開始フレームを指すオフセットを含む目次を容易に作成する機能を有している。この有用な機能は短いビデオ・クリップのために有用で、目次が一度作成されると、ランダム・アクセスやその他のビデオ録画再生機としての機能を簡単に供給することができる。(これらのルーチンについては、サンプルアプリケーションについての項で更に議論する。)」)



”(第61頁)

“ISO's MPEG-1 Video”(第63頁左欄第20行)
(「ISOのMPEG-1ビデオ」)

“Typically the order in which coded pictures are presented to the decoder does not correspond to the order in which they are to be displayed. Consider the following example:

Display Order I1 B2 B3 P4 B5 B6 P7 B8
Decoder Input I1 P4 B2 B3 P7 B5 B6 I10

The order mismatch is an artifact of the compression algorithm-a B-picture cannot be decoded until both its past and future reference frames have been decoded. Similarly a P-picture cannot be decoded until its past reference frame has been decoded. To get around this problem, SLIB defines an output multibuffer. The size of this multibuffer is approximately equal to three times the size of a single uncompressed frame. For example, for a 4:2:0 subsampled CIF image, the size of the multibuffer would be 352 by 288 by 1.5 by 3 bytes (the exact size is returned by the library during initial codec setup). After steady state has been reached, each invocation to the decompress call yields the correct next frame to be displayed as shown in Figure 11. To avoid expensive copy operations, the multibuffer is allocated and owned by the software above SLIB.”(第64頁右欄下から4行?第65頁左欄第18行)
(「一般的に、符号化されたピクチャがデコーダに供給される順序は、表示される順序とは一致しない。検討すべき以下の例:

表示順 I1 B2 B3 P4 B5 B6 P7 B8
デコーダへの入力順 I1 P4 B2 B3 P7 B5 B6 I10

順序が異なるのは、圧縮アルゴリズムの副作用である。Bピクチャは、過去と未来の参照フレームの双方が復号されるまでは復号することができない。同様に、Pピクチャは、過去の参照フレームが復号されるまでは復号することができない。この問題を回避するため、SLIBは、出力マルチバッファを設けている。このマルチバッファの大きさは、一つの復号されたフレームの大きさの約3倍と等しい。例えば、4:2:0でサブサンプリングされたCIFイメージに対して、マルチバッファの大きさは、352×288×1.5×3バイトとなる。(実際の大きさは、コーデックの初期セットアップの間にライブラリから返される。)定常状態に達した時点で、復号のための呼び出しは、図11に示されるように、次の正しいフレームを表示するように行われる。面倒な複写処理を避けるために、マルチバッファは、SLIBの上の層のソフトウェアによって、確保され所有されている。」)



”(第65頁)

“ITU-T’s Recommendation H.261 (a.k.a. p × 64) At the library level, decompressing an H.261 stream is very similar to MPEG-1 decoding with one exception: instead of three types of pictures, the H.261 recommendation defines only two, key frames and non-key frames (no bidirectional prediction). The implication for implementation is that the size of the multibuffer is approximately twice the size of a single decompressed frame. Furthermore, the order in which compressed frames are presented to the decompressor is the same as the order in which they are to be displayed.
To satisfy the H.261 recommendation, SLIB implements a streaming interface for compression and decompression. In this model, the application feeds input buffers to the codec, which processes the data in the buffers and returns the processed data to the application through a callback routine. During decompression, the application layer passes input buffers containing sections of an H.261 bit stream. The bit stream can be divided arbitrarily, or, in the case of live teleconferencing, each buffer can contain data from a transmission packet. Empty output buffers are also passed to the codec to fill with reconstructed images. Picture frames do not have to be aligned on buffer boundaries. The codec parses the bit stream and, when enough data is available, reconstructs an image. Input buffers are freed by calling the callback routine. When an image is reconstructed, it is placed in an output buffer and the buffer is returned to the application through the callback routine. The compression process is similar, but input buffers contain images and output buffers contain bit-stream data. One advantage to this streaming interface is that the application layer does not need to know the syntax of the H.261 bit stream. The codec is responsible for all bit-stream parsing. Another advantage is that the callback mechanism for returning completed images or bit-stream buffers allows the application to do other tasks without implementing multithreading.
SLIB’s architecture and API can easily accommodate ISO’s MPEG-2 and ITU-T’s H.263 video compression algorithms because of their similarity to the MPEG-1 and H.261 algorithms.”(第65頁左欄第19行?右欄第19行)
(「ITU勧告H.261 (p × 64としても知られている。) ライブラリの段階では、H.261勧告が、3つの種類のピクチャではなく、キーフレームと非キーフレームのみを有し、双方向予測を有さないという、一つの例外を除いて、H.261ストリームの圧縮を復号するのは、MPEG-1の復号化とよく似ている。インプリメンテーションに対する影響は、マルチバッファのサイズが、復号後のフレームの約2倍の大きさとなることである。更に、圧縮されたフレームがデコーダに送られる順序は、それが表示される順序と同じである。
H.261勧告を満たすために、SLIBは圧縮と復号のためのストリーミングインターフェースをインプリメントしている。このモデルでは、アプリケーションがコーデックに入力バッファを与え、コーデックはバッファの中のデータを処理して、処理済データをコールバックルーチンを介してアプリケーションに返す。圧縮の復号処理中に、アプリケーション層は、H.261ビットストリームのセクションを含む入力バッファを与える。ビットストリームは、任意に分割したものでも良く、また、テレビ会議の場合には、伝送パケットに含まれたものでも良い。空白の出力バッファもコーデックに渡され、コーデックは再構成した映像でそれを埋める。ピクチャフレームは、バッファの境界と整合される必要は無い。コーデックはビットストリームを解析し、必要なデータが揃った時点で、イメージを再構成する。入力バッファは、コールバックルーチンを呼ぶことで解放される。イメージが再構成されたとき、それは出力バッファに置かれ、コールバックルーチンを介して、アプリケーションに返される。圧縮処理も、入力バッファがイメージを持ち、出力バッファがビットストリームデータを持つ以外は同様である。このストリーミングインターフェースの利点は、アプリケーション層がH.261ビットストリームの文法を知る必要が無いことである。コーデックがすべてのビットストリームの解析に責任を持つ。他の利点は、完全なイメージやビットストリームをバッファに入れてコールバックメカニズムで返すことによって、マルチスレッドを適用しなくても、アプリケーションが他のタスクを実行できることである。
SLIBのアーキテクチャやAPIは、MPEG-1やH.261と、ISOのMPEG-2やITU-TのH.263動画圧縮アルゴリズムが非常に類似しているので、後者に簡単に適用できる。」)

“Implementation of Video Rendering
Our software implementation of video rendering essentially parallels the hardware realization detailed elsewhere in this issue.^(9) As with the hardware implementation, the software renderer is fast and simple because the complicated computations are performed off line in building the various look-up tables. In both hardware and software cases, a shortcut is achieved by dithering in YUV space and then converting to some small number of RGB index values in a look-up table.^(16)
Although in most cases the mapping values in the look-up tables remain fixed for the duration of the run, the video library provides routines to dynamically adjust image brightness, contrast, saturation, and the number of colors. Image scaling is possible but affects performance. When quality is important, the software performs scaling before dithering and when speed is the primary concern, it is done after dithering.”(第65頁右欄第21?38行)
(「ビデオレンダリングのインプリメンテーション
我々のビデオ・レンダリングのソフトウェア・インプリメンテーションは、この号の別の場所に記述されているハードウェアの実現と実質的に同様のものである。オフラインでルックアップテーブルを作成する過程で、既に複雑な計算は実行されているので、ハードウェアのインプリメンテーションと同様に、ソフトウェア・レンダラーは高速で簡素なものである。ハードウェアで行う場合とソフトウェアで行う場合の両方において、YUV空間におけるディザリングによってショートカットが実現され、ルックアップテーブル中の少数のRGBインデックス値に変換されている。
殆どの場合は、ルックアップテーブル中のマップされた値は、実行される居合いだ固定されているが、ビデオ・ライブラリは、イメージの明るさ、コントラスト、飽和値、色数を動的に修正するためのルーチンを用意している。質が重要である場合、ソフトウェアはディザリングの前にスケーリングを実施するが、速度が重要である場合は、ディザリングの後にスケーリングを実施する。」)

“Consistent with one of the design goals, SLIB was made thread-safe and fully reentrant. The Digital UNIX, the OpenVMS, and Microsoft's Windows NT operating systems all offer support for multithreaded applications. Applications such as video playback can improve their performance by having separate threads for reading, decompressing, rendering, and displaying. Also, a multithreaded application scales up well on a multiprocessor system. Global multithreading is possible if the library code is reentrant or thread-safe. When we were trying to multithread the library internals, we found that the overhead caused by the birth and death of threads, the increase in memory accesses, and the fragmentation of the codec pipeline caused operations to slow down. For these reasons, routines within SLIB were kept single-threaded. Other operating-system optimizations such as memory locking, priority scheduling, nonpreemption, and faster timers that are generally good for real-time applications were experimented with but not included in our present implementation.”(第67頁左欄第6?26行)
(「設計目標の一つを実現するため、SLIBは、スレッドセーフ、且つ、完全リエントラントに作られている。ディジタルUNIX、Open VMS、そして、マイクロソフトWindows NTというオペレーティングシステムは、すべてマルチスレッドアプリケーションに対応している。読み取り、圧縮の復号、レンダリング、表示を独立のスレッドで実行することによって、ビデオ再生のようなアプリケーションのパフォーマンスは向上する。更に、マルチスレッドのアプリケーションは、マルチプロセッサシステムに良く対応する。グローバル・マルチスレッド化は、ライブラリのコードがリエントラント且つスレッドセーフの時に可能である。ライブラリの内部処理をマルチスレッド化したときに、スレッドの生起と消滅によるオーバーヘッド、メモリアクセスの増加、コーデックのパイプラインのフラグメンテーションが、動作を遅くすることを発見した。一般的にリアルタイム・アプリケションにとって良いとされる、メモリのロック、優先度のスケジューリング、ノンプリエンプション、高速なタイマなどの他のオペレーティングシステムにおける最適化は試されてはいるが、現在の我々のインプリメンテーションには含まれていない。」)

3.1.2.引用例1記載の発明
引用例1の上記記載について検討する。

第一に、引用例1の“We follow that discussion with the section The Software Video Library, in which we present a common architecture for video compression, decompression, and playback that allows integration into Digital’s multimedia products. We then describe two sample applications, the Video Odyssey screen saverand a software-only video player. We conclude our paper by surveying related work in this rapidly evolving area of software digital video.”(第52頁右欄下から6行?第53頁左欄第3行)(「ソフトウェア・ビデオ・ライブラリという項目において、ディジタルのマルチメディア製品への組込が可能な、ビデオ圧縮、ビデオ圧縮の復号、および、再生についての共通アーキテクチャについての議論を行う。」)、“Architecture Keeping in mind the observations outlined above, we designed a software video library (SLIB) that would...”(第61頁左欄第4?6行)(「上に示した検討事項を前提として、我々が設計したソフトウェア・ビデオ・ライブラリ(SLIB)は...」)との記載からみて、引用例1に記載されている「ソフトウェア・ビデオ・ライブラリ(SLIB)」は「ビデオ圧縮、ビデオ圧縮の復号、および、再生」に関するものであるが、引用例1の記載からみて、この「ソフトウェア・ビデオ・ライブラリ(SLIB)」は「方法の発明」として把握することができるから、引用例1には「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」が記載されているといえる。
第二に、引用例1の“Provide a common architecture under which multiple audio and video codecs and renderers could be accessed”(第61頁左欄第7?9行)(「複数のオーディオ/ビデオ・コーデックとレンダラーを用いることができるような共通のアーキテクチャを与えるものである。」)、“As mentioned, the library contains routines for audio and video codecs and Digital's propriety videorendering algorithms.”(第61頁右欄第10?12行)(「既に述べたように、ライブラリは、オーディオ/ビデオ・コーデックと、ディジタルが所有するビデオ・レンダリング・アルゴリズムのためのルーチンを含んでいる。」)、“Three classes of routines are provided for the three subsystems: (1) video compression and decompression, (2) video rendering, and (3) audio processing.”(第61頁右欄第18?20行)(「3つの種類のルーチンが、(1)ビデオ圧縮符号化と復号化、(2)ビデオ・レンダリング、(3)オーディオ処理という、3つのサブシステムに対して供給されている。」)との記載からみて、引用例1記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」は「ビデオ圧縮符号化と復号化、ビデオ・レンダリング、オーディオ処理を含」むものである。
第三に、引用例1の“Provide a common architecture under which multiple audio and video codecs and renderers could be accessed”(第61頁左欄第7?9行)(「複数のオーディオ/ビデオ・コーデックとレンダラーを用いることができるような共通のアーキテクチャを与えるものである。」)との記載、および、Figure 7(第61頁)の左下の“VIDEO CODECS”というブロックが、JPEG, MPEG, H.261という画像圧縮の規格名と矢印で接続されているところからみて、引用例1記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」の「ビデオ圧縮符号化と復号化」としては「JPEG, MPEG, H.261等の複数種類のビデオ・コーデックを用いることができ」るものである。
第四に、引用例1の“Three classes of routines are provided for the three subsystems: (1) video compression and decompression, (2) video rendering, and (3) audio processing. For each subsystem, routines can be further classified as (a) setup routines, (b) action routines, (c) query routines, and (d) teardown routines. Setup routines create and initialize all relevant internal data structures. They also compute values for the various look-up tables such as the ones used by the rendering subsystem. Action routines perform the actual coding, decoding, and rendering operations. Query routines may be used before setup or between action routines. These provide the programmer with information about the capability of the codec such as whether or not it can handle a particular input format and provide information about the bit stream being processed. These routines can also be used for gathering statistics. Teardown routines, as the name suggests, are used for closing the codec and destroying all internal memory (state information) associated with it.”(第61頁右欄第18行?第62頁左欄第7行)(「3つの種類のルーチンが、(1)ビデオ圧縮符号化と復号化、(2)ビデオ・レンダリング、(3)オーディオ処理という、3つのサブシステムに対して供給されている。それぞれのサブシステムに対して、これらルーチンは、(a)セットアップ・ルーチン、(b)実行ルーチン、(c)問い合わせルーチン、(d)破壊ルーチン、のように更に分類することができる。セットアップ・ルーチンは、すべての必要な内部データ構造を作成し初期化し、更に、レンダリング・サブシステムでもちいられるような、各種のルックアップテーブルの値を計算する。実行ルーチンは、実際の符号化、復号化、レンダリングを実行する。問い合わせルーチンは、セット・アップルーチンと、実行ルーチンの間で用いることができ、例えば、ある入力フォーマットを扱うことができるかどうかというようなそのコーデックの能力に関する情報、ビットストリームが処理中かどうかという情報を、プログラマーに与える。また、このルーチンは、統計情報を得ることに用いることもできる。破壊ルーチンは、その名前が示すように、コーデックの終了とそれに伴う内部記憶(状態情報)を破壊することに用いられる。」)との記載からみて、引用例1記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」は「すべての必要な内部データ構造を作成し初期化し、更に、レンダリング・サブシステムでもちいられるような、各種のルックアップテーブルの値を計算するセットアップ・ルーチン」を有している。
第五に、引用例1の“Implementation of Video Rendering ... Image scaling is possible but affects performance. When quality is important, the software performs scaling before dithering and when speed is the primary concern, it is done after dithering.”(第65頁右欄第21?38行)(「ビデオレンダリングのインプリメンテーション ...質が重要である場合、ソフトウェアはディザリングの前にスケーリングを実施するが、速度が重要である場合は、ディザリングの後にスケーリングを実施する。」)との記載、および、Figure 7(第61頁)の中下の“VIDEO RENDERERS”というブロックが、“DITHER”、“ SCALE”と矢印で接続されているところからみて、引用例1記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」の「ビデオ・レンダリング」は「ディザリングとスケーリングを含」むものである。
第六に、引用例1の“Be fast, extensible, and thread-safe, providing reentrant code with minimal overhead”(第61頁左欄第12?13行)(「最小のオーバーヘッド、高速、拡張可能の、スレッドセーフ、リエントラントなコードを与えるものである。」)、“Consistent with one of the design goals, SLIB was made thread-safe and fully reentrant.”(第67頁左欄第6?7行)(「設計目標の一つを実現するため、SLIBは、スレッドセーフ、且つ、完全リエントラントに作られている。」)、“Also, a multithreaded application scales up well on a multiprocessor system. Global multithreading is possible if the library code is reentrant or thread-safe.”(第67頁左欄第13?15行)(「更に、マルチスレッドのアプリケーションは、マルチプロセッサシステムに良く対応する。グローバル・マルチスレッド化は、ライブラリのコードがリエントラント且つスレッドセーフの時に可能である。」)との記載からみて、引用例1記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」は「スレッドセーフ、且つ、完全リエントラントに作られ、マルチプロセッサシステムに良く対応し」ているものである。
第七に、引用例1の“Consistent with one of the design goals, SLIB was made thread-safe and fully reentrant. The Digital UNIX, the OpenVMS, and Microsoft's Windows NT operating systems all offer support for multithreaded applications. Applications such as video playback can improve their performance by having separate threads for reading, decompressing, rendering, and displaying. Also, a multithreaded application scales up well on a multiprocessor system. Global multithreading is possible if the library code is reentrant or thread-safe.”(第67頁左欄第6?15行)(「設計目標の一つを実現するため、SLIBは、スレッドセーフ、且つ、完全リエントラントに作られている。ディジタルUNIX、Open VMS、そして、マイクロソフトWindows NTというオペレーティングシステムは、すべてマルチスレッドアプリケーションに対応している。読み取り、圧縮の復号、レンダリング、表示を独立のスレッドで実行することによって、ビデオ再生のようなアプリケーションのパフォーマンスは向上する。更に、マルチスレッドのアプリケーションは、マルチプロセッサシステムに良く対応する。グローバル・マルチスレッド化は、ライブラリのコードがリエントラント且つスレッドセーフの時に可能である。」)との記載からみて、引用例1記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」は「圧縮の復号、レンダリング、表示を独立のスレッドで実行」するものである。
第八に、Figure 7(第61頁)の左上の“DIGITAL’S MULTIMEDIA CLIENT LIBRARY”というブロックに対して“APPLICATION 1 ・・・APPLICATION N”から複数の矢印で接続されていること、および、左上の“MICROSOFT’S VIDEO FOR WINDOWS (WINDOWS NT)”というブロックに対して“APPLICATION 1 ・・・APPLICATION M”から複数の矢印で接続されていることからみて、引用例1記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」は、「複数のアプリケーションに対して入出力を行える」ものである。
第九に、“Typically the order in which coded pictures are presented to the decoder does not correspond to the order in which they are to be displayed. Consider the following example: Display Order I1 B2 B3 P4 B5 B6 P7 B8 Decoder Input I1 P4 B2 B3 P7 B5 B6 I10 The order mismatch is an artifact of the compression algorithm-a B-picture cannot be decoded until both its past and future reference frames have been decoded. Similarly a P-picture cannot be decoded until its past reference frame has been decoded. To get around this problem, SLIB defines an output multibuffer. The size of this multibuffer is approximately equal to three times the size of a single uncompressed frame. For example, for a 4:2:0 subsampled CIF image, the size of the multibuffer would be 352 by 288 by 1.5 by 3 bytes (the exact size is returned by the library during initial codec setup). After steady state has been reached, each invocation to the decompress call yields the correct next frame to be displayed as shown in Figure 11. To avoid expensive copy operations, the multibuffer is allocated and owned by the software above SLIB.”(第64頁右欄下から4行?第65頁左欄第18行)(「一般的に、符号化されたピクチャがデコーダに供給される順序は、表示される順序とは一致しない。検討すべき以下の例: 表示順 I1 B2 B3 P4 B5 B6 P7 B8 デコーダへの入力順 I1 P4 B2 B3 P7 B5 B6 I10 順序が異なるのは、圧縮アルゴリズムの副作用である。Bピクチャは、過去と未来の参照フレームの双方が復号されるまでは復号することができない。同様に、Pピクチャは、過去の参照フレームが復号されるまでは復号することができない。この問題を回避するため、SLIBは、出力マルチバッファを設けている。このマルチバッファの大きさは、一つの復号されたフレームの大きさの約3倍と等しい。例えば、4:2:0でサブサンプリングされたCIFイメージに対して、マルチバッファの大きさは、352×288×1.5×3バイトとなる。(実際の大きさは、コーデックの初期セットアップの間にライブラリから返される。)定常状態に達した時点で、復号のための呼び出しは、図11に示されるように、次の正しいフレームを表示するように行われる。面倒な複写処理を避けるために、マルチバッファは、SLIBの上の層のソフトウェアによって、確保され所有されている。」)、Figure 11 の記載、および、引用例1第63頁左欄第20行?第65頁左欄第18行の記載が“ISO's MPEG-1 Video”のためのものであるところからみて、引用例1記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」は「MPEG-1ビデオ圧縮の復号」の出力部分に "output multibuffer"(「出力マルチバッファ」) を有しているものであって、その"output multibuffer"(「出力マルチバッファ」) に入力されるピクチャの順序は表示されるべき順序と一致していないが、それから出力されるピクチャの順序は表示されるべき順序と一致しているものである。更に、“To avoid expensive copy operations, the multibuffer is allocated and owned by the software above SLIB.”(第65頁左欄第16?18行)(「面倒な複写処理を避けるために、マルチバッファは、SLIBの上の層のソフトウェアによって、確保され所有されている。」)との記載からみて、この"output multibuffer"(「出力マルチバッファ」) は、「SLIBの上の層のソフトウェア」、すなわち、「アプリケーション」によって確保され所有されているものである。
第十に、“To satisfy the H.261 recommendation, SLIB implements a streaming interface for compression and decompression. In this model, the application feeds input buffers to the codec, which processes the data in the buffers and returns the processed data to the application through a callback routine.”(第65頁左欄第30?35行)(「H.261勧告を満たすために、SLIBは圧縮と復号のためのストリーミングインターフェースをインプリメントしている。このモデルでは、アプリケーションがコーデックに入力バッファを与え、コーデックはバッファの中のデータを処理して、処理済データをコールバックルーチンを介してアプリケーションに返す。」)、“Empty output buffers are also passed to the codec to fill with reconstructed images.”(第65頁左欄第40?41行)(「空白の出力バッファもコーデックに渡され、コーデックは再構成した映像でそれを埋める。」)との記載からみて、引用例1記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」の「ビデオ圧縮の復号」には、「アプリケーションが確保した入力バッファを介してビットストリームが入力され」、「アプリケーションが確保した出力バッファを介して再構成した映像を出力する」ものである。

したがって、引用例1には以下の発明(以下「引用発明1」という。)が記載されている。

「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法であって、
複数のアプリケーションに対して入出力を行えるものであり、スレッドセーフ、且つ、完全リエントラントに作られ、マルチプロセッサシステムに良く対応し、
ビデオ圧縮符号化と復号化、ビデオ・レンダリング、オーディオ処理を含み、
ビデオ圧縮符号化と復号化としては、JPEG, MPEG, H.261等の複数種類のビデオ・コーデックを用いることができ、
ビデオ・レンダリングは、ディザリングとスケーリングを含み、圧縮の復号、レンダリング、表示を独立のスレッドで実行し、
すべての必要な内部データ構造を作成し初期化し、更に、レンダリング・サブシステムでもちいられるような、各種のルックアップテーブルの値を計算するセットアップ・ルーチンを有し、
MPEG-1ビデオ圧縮の復号の復号の出力部分に、アプリケーションによって確保され所有されている出力マルチバッファを有し、出力マルチバッファに入力されるピクチャの順序は表示されるべき順序と一致していないが、それから出力されるピクチャの順序は表示されるべき順序と一致し、
ビデオ圧縮の復号には、アプリケーションが確保した入力バッファを介してビットストリームが入力され、アプリケーションが確保した出力バッファを介して再構成した映像を出力する、
ビデオ圧縮、ビデオ圧縮の復号、および、再生方法。」

3.2.引用例2
3.2.1.引用例2の記載事項
当審における平成25年4月25日付の拒絶の理由で引用した特開2002-354475号公報(以下「引用例2」という。)には、図面とともに以下の記載がある。
「【0007】
【課題を解決するための手段】本発明(請求項1)の画像復号処理装置は、画像の符号化データを復号処理し復号画像を生成するデコード部と、デコード部で生成される復号画像を保持する画像メモリと、画像メモリから読み込んだ復号画像を拡大縮小処理し、拡大縮小画像を生成するフィルタ部と、デコード部における復号処理時間の指定と、フィルタ部における拡大縮小処理時間の指定と、デコード部で生成される復号画像を書き込む画像メモリの領域指定と、フィルタ部で復号画像を読み込む画像メモリの領域指定とを行う制御部とで構成される。」
「【0008】この構成により、デコード部の復号処理とフィルタ部の拡大縮小処理を非同期に行うことが可能である。」
「【0029】
【発明の実施の形態】以下、本発明の実施の形態について、図面を参照しながら説明する。」
「【0030】(実施の形態1)図1は、本発明の実施の形態1における画像処理装置の構成を示すブロック図である。本実施の形態の画像復号処理装置は、画像の符号化データ15を復号処理し、復号画像16を生成するデコード部11と、デコード部11で生成される復号画像16を保持する画像メモリの機能を備えたフレームメモリ12と、フレームメモリ12の復号画像17を読み込み、拡大縮小処理し、拡大縮小画像18を生成するフィルタ部13と、デコード部11における復号処理時間の指定と、フィルタ部13における拡大縮小処理時間の指定と、デコード部11で生成される復号画像を書き込むフレームメモリ12の領域指定と、フィルタ部13で復号画像を読み込むフレームメモリ12の領域指定を行う制御部14から構成される。」
「【0031】デコード部11は、画像を16ラインごとに復号処理し、復号された部分復号画像をフレームメモリ12に書き込む。フィルタ部13は、フレームメモリ12の復号画像を16ラインごとに読み込み、拡大縮小処理し、部分拡大縮小画像を出力する。」
「【0032】制御部14によるデコード部11の制御手順について、図2を参照して説明する。STEP20では、デコード部11を起動する。STEP21では、デコード部11で復号される最初の部分復号画像を書き込むフレームメモリ12の領域を指定する。」
「【0033】STEP22では、STEP21で指定したフレームメモリ12領域に以前に復号した部分復号画像がある場合には、その部分復号画像に対して、フィルタ部13の拡大縮小処理がなされているか否かで以降の処理を分岐させる。拡大縮小処理がなされていない場合には、STEP23で、デコード部11の動作を一時停止し、再度、STEP22に戻る。こうして以前に復号した部分復号画像に対する拡大縮小処理がなされるまで、デコード部11を停止する。」
「【0034】STEP22で、以前に復号した部分復号画像に対して拡大縮小処理がなされている場合には、STEP24で部分画像の復号処理を行い、STEP25で生成される部分復号画像をフレームメモリ12の指定領域に書き込みを行う。」
「【0035】STEP26では、復号処理した部分画像が画像の最後の部分画像である場合には、STEP27で、デコード部11を終了し、最後の部分画像でない場合には、STEP28で、次の部分復号画像の書き込み領域を指定し、STEP21に戻り、同様の処理を繰り返す。」
「【0036】次に制御部14によるフィルタ部13の制御手順について、図3を参照して説明する。STEP30で、フィルタ部13を起動する。STEP31では、フレームメモリから部分復号画像を読み込む領域を指定する。STEP32では、読み込み領域に部分復号画像がある場合には、この部分復号画像が次に拡大縮小処理する部分復号画像か否かにより以降の処理を分岐させる。この部分復号画像が次に拡大縮小処理を行う部分復号画像でない場合には、STEP33で、フィルタ部13を一時停止し、その後、STEP32に戻る。」
「【0037】こうして、部分復号画像が書き込まれるまで、フィルタ部13を停止する。STEP32で、次に拡大縮小処理する部分復号画像がある場合には、STEP34で、部分復号画像を読み込み、STEP35で、部分復号画像の拡大縮小処理を行う。STEP36では、拡大縮小処理した部分復号画像が復号画像の最後の部分復号画像である場合には、STEP37でフィルタ部13を終了し、最後の部分復号画像でない場合には、STEP38に戻り、同様の処理を繰り返す。」
「【0038】次に、デコード部11で生成される部分復号画像を、フレームメモリに書き込む領域を決定する手順について図4を参照して説明する。部分復号画像は、復号画像の上から順に復号され、ここでは、部分復号画像1に続き、部分復号画像2が生成される。部分復号画像1をフレームメモリ12の第1の領域に書き込むとすると、部分復号画像2は、第1の領域に続く第2の領域に書き込みを行う。ただし、第1の領域に続く領域が存在しない場合には、フレームメモリ12の先頭の領域である、第3の領域に書き込みを行う。」
「【0039】次に、デコード部11で生成される部分復号画像のうち、各画像の最初の部分復号画像を書き込むフレームメモリ12の領域の決定手順について、図5を参照して説明する。」
「【0040】図5(A)のフローチャートにおいて、STEP51で、フレームメモリ12の容量が、復号画像のデータ量より大きい場合には、STEP54で、フレームメモリ12の先頭領域に書き込む。STEP51で、フレームメモリ12の容量が、復号画像のデータ量より小さい場合には、STEP52に進む。STEP52では、フレームメモリ12に、フィルタ部13での拡大縮小処理が未処理である部分復号画像があるか否かで、その後の処理を分岐する。STEP52で、拡大縮小処理が未処理である部分復号画像がある場合には、STEP53で、前部分復号画像を保持する領域に続く領域に書き込みを行い、拡大縮小処理が未処理である部分復号画像がない場合には、STEP54でフレームメモリ12の先頭領域に書き込む。」
「【0041】次に、本実施の形態の動作について図6を参照して説明する。まず、復号処理1は、復号処理開始時間1に画像の復号処理を開始する。その後、デコード部11において復号した画像がフレームメモリ12に16ライン分書き込まれた直後の時間である、拡大縮小処理1開始時間に拡大縮小処理1を開始する。復号処理1が終了すると、直後に次の画像に対する復号処理2を開始する。その後、拡大縮小処理1が終了すると、直後に次の画像に対する拡大縮小処理2を開始する。」
「【0042】デコード部11は、各画像に対して復号処理期限が設定されており、それまでに復号処理が終了しない場合には、現復号処理を中断し、直ちに次の画像の復号処理を開始する。」
「【0043】フィルタ部13も同様に、各画像に対して拡大縮小処理期限が設定されており、それまでに拡大縮小処理が終了しない場合には、現拡大縮小処理を中断し、直ちに次の画像の拡大縮小処理を開始する。」
「【0044】以上のように本実施の形態によれば、フィルタ部13は、前画像に対する復号処理の終了後、直ちに次の画像の復号処理を開始することができ、また、フィルタ部13においても、同様に、前画像に対する拡大縮小処理の終了後、直ちに次の画像の拡大縮小処理を開始することができる。」
「【0045】また、フレームメモリ12への復号画像の書き込み方法を、フレームメモリ12の使用状態によって切り替えることにより、データの書き潰しや復号画像の読み間違い等を防止し、さらに、デコード部11とフィルタ部13において、復号画像の読み書きを効率よく行うことができる。」
「【0046】尚、処理方法については、本実施の形態では、デコード部11で生成される復号画像は、16ライン単位で、フレームメモリ12に書き込むと述べたが、それに制約されるものではない。」
「【0047】また、デコード部11で生成される復号画像のうち、最初の部分復号画像を書き込むフレームメモリ12領域は、前復号画像に続く領域を指定してもよい。こうすることで、デコード部11は各画像の復号処理開始後、フィルタ部13において部分復号画像を読み込むフレームメモリ12領域と、同一のフレームメモリ12領域を使用することが少なくなり、復号処理を停止することなく、スムーズに実行することができる。」
「【図1】


「【図2】


「【図3】


「【図4】


「【図5】


「【図6】



3.2.2.引用例2記載の発明
上記段落【0007】【0008】【0041】?【0047】、および、【図1】【図6】の記載からみて、引用例2には以下の発明(以下「引用発明2」という。)が記載されている。

「画像の符号化データを復号処理し復号画像を生成するデコード部と、デコード部で生成される復号画像を保持する画像メモリと、画像メモリから読み込んだ復号画像を拡大縮小処理し、拡大縮小画像を生成するフィルタ部と、デコード部における復号処理時間の指定と、フィルタ部における拡大縮小処理時間の指定と、デコード部で生成される復号画像を書き込む画像メモリの領域指定と、フィルタ部で復号画像を読み込む画像メモリの領域指定とを行う制御部とで構成される画像復号処理装置であって、デコード部の復号処理とフィルタ部の拡大縮小処理を非同期に時間的に並列に動作させることが可能である画像復号処理装置。」

4.対比
本願発明と引用発明1を比較する。

4.1.「少なくとも第1および第2のビデオ・ストリームを復号する方法であって、・・・を含む、前記方法。」
引用発明1は「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法であって、複数のアプリケーションに対して入出力を行えるものであ」り「ビデオ圧縮の復号には、アプリケーションが確保した入力バッファを介してビットストリームが入力される」ものであって、これら「複数のアプリケーション」からは、それぞれ異なる「ビットストリームが入力され」、これら「ビットストリーム」は少なくとも2つあるということができるから、引用発明1の「ビットストリーム」は本願発明の「少なくとも第1および第2のビデオ・ストリーム」と対応し、引用発明1と本願発明は「少なくとも第1および第2のビデオ・ストリームを復号する方法であって、・・・を含む、前記方法。」である点で一致している。

4.2.「前記少なくとも第1および第2のビデオ・ストリームのそれぞれを、復号を行うためにルーティングするステップ」
引用発明1は「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法であって、複数のアプリケーションに対して入出力を行えるものであり」、「ビデオ圧縮符号化と復号化としては、JPEG, MPEG, H.261等の複数種類のビデオ・コーデックを用いることができ」、「すべての必要な内部データ構造を作成し初期化し、更に、レンダリング・サブシステムでもちいられるような、各種のルックアップテーブルの値を計算するセットアップ・ルーチンを有し」ており、この「セットアップ・ルーチン」による「内部データ構造を作成し初期化」することによって、入力される「ビットストリーム」に対して、JPEG, MPEG, H.261等の複数種類のビデオ・コーデックの中からいずれを用いるのか設定しているということができ、これは、入力されるビットストリームをそれを復号するに適切なビデオ・コーデックにルーティングするように設定しているといえる。更に、上記『4.1.「少なくとも第1および第2のビデオ・ストリームを復号する方法であって、・・・を含む、前記方法。」』で述べたように、引用発明1は、これら「複数のアプリケーション」からは、それぞれ異なる「ビットストリームが入力され」、これら「ビットストリーム」は本願発明の「少なくとも第1および第2のビデオ・ストリーム」と対応しているといえるから、引用発明1と本願発明は「前記少なくとも第1および第2のビデオ・ストリームのそれぞれを、復号を行うためにルーティングするステップ」を有する点で一致している。

4.3.「少なくとも第1および第2の圧縮解除ビデオ・ストリームをそれぞれ生成するための、前記少なくとも第1および第2のビデオ・ストリームのそれぞれを復号するステップであって、前記少なくとも第1および第2のビデオ・ストリームが空間的に並列に独立して復号されるステップ」
引用発明1は「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法であって、複数のアプリケーションに対して入出力を行えるものであ」って、上記『4.1.「少なくとも第1および第2のビデオ・ストリームを復号する方法であって、・・・を含む、前記方法。」』で述べたように、引用発明1は、これら「複数のアプリケーション」からは、それぞれ異なる「ビットストリームが入力され」、これら「ビットストリーム」は本願発明の「少なくとも第1および第2のビデオ・ストリーム」と対応しているといえ、また、それに対して「ビデオ圧縮の復号」を行った結果、本願発明の「少なくとも第1および第2の圧縮解除ビデオ・ストリーム」に対応するものが生成されているから、引用発明1と本願発明は「少なくとも第1および第2の圧縮解除ビデオ・ストリームをそれぞれ生成するための、前記少なくとも第1および第2のビデオ・ストリームのそれぞれを復号するステップ」を有する点では一致しているということができる。
しかしながら、引用例1には引用発明1のビデオ圧縮の復号が、アプリケーション毎、そして、アプリケーションから入力されるビットストリーム毎に、互いに空間的に並列に独立して動作することは記載されていないから、引用発明1のビデオ圧縮の復号が、アプリケーション毎、そして、アプリケーションから入力されるビットストリーム毎に、互いに空間的に並列に独立して動作するか明らかではない。すなわち、本願発明は「前記少なくとも第1および第2のビデオ・ストリームが空間的に並列に独立して復号される」ものであるのに対し、引用発明1のビデオ圧縮の復号は、アプリケーション毎、そして、アプリケーションから入力されるビットストリーム毎に、互いに空間的に並列に独立して動作するか明らかではない点で相違する。
これらをまとめると、引用発明1と本願発明は「少なくとも第1および第2の圧縮解除ビデオ・ストリームをそれぞれ生成するための、前記少なくとも第1および第2のビデオ・ストリームのそれぞれを復号するステップ」を有する点では一致しているが、本願発明は、この「ステップ」が「前記少なくとも第1および第2のビデオ・ストリームが空間的に並列に独立して復号されるステップ」であるのに対し、引用発明1のビデオ圧縮の復号は、アプリケーション毎、そして、アプリケーションから入力されるビットストリーム毎に、互いに空間的に並列に独立して動作するか明らかではない点で相違する。

4.4.「前記少なくとも第1および第2の圧縮解除ビデオ・ストリームのそれぞれのフレームを第1および第2のプレゼンテーション・バッファ・ステージそれぞれに記憶するステップ」
引用発明1は「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法であって、複数のアプリケーションに対して入出力を行えるものであり、スレッドセーフ、且つ、完全リエントラントに作られ、ビデオ圧縮符号化と復号化、ビデオ・レンダリング、オーディオ処理を含」むものであり、「ビデオ・レンダリングは、ディザリングとスケーリングを含み、圧縮の復号、レンダリング、表示を独立のスレッドで実行し」ているものであって、更に、「ビデオ圧縮の復号には、アプリケーションが確保した入力バッファを介してビットストリームが入力され、アプリケーションが確保した出力バッファを介して再構成した映像を出力する」ものである。そして、引用発明1の「再構成した映像」と本願発明の「少なくとも第1および第2の圧縮解除ビデオ・ストリームのそれぞれのフレーム」が対応している。
しかしながら、引用例1の記載からは、引用発明1の「出力バッファ」が用いられるのは、ビデオ圧縮を復号し直接アプリケーションに対して再構成した映像を出力するときのみなのか、それとも、ビデオ圧縮を復号した後、スケーリングを含むビデオレンダリングを行うときにも、ビデオ圧縮を復号した出力は、この「出力バッファ」を介して、スケーリングを含むビデオレンダリングに送られるのか、必ずしも明らかではない。これに対し、本願発明は「前記少なくとも第1および第2の圧縮解除ビデオ・ストリームのそれぞれのフレームを第1および第2のプレゼンテーション・バッファ・ステージそれぞれに記憶するステップ」「前記第1および第2の圧縮解除ビデオ・ストリームの記憶したフレームを、共通のサイズにスケーリングするステップ」双方を有するとことからみて、この「第1および第2のプレゼンテーション・バッファ・ステージ」は「共通のサイズにスケーリングする」時に用いられているから、本願発明は「前記少なくとも第1および第2の圧縮解除ビデオ・ストリームのそれぞれのフレームを第1および第2のプレゼンテーション・バッファ・ステージそれぞれに記憶するステップ」を有するのに対し、引用発明1は、スケーリングを含むビデオレンダリングを行うときにも、ビデオ圧縮を復号した出力は、「出力バッファ」を介して、スケーリングを含むビデオレンダリングに送られるのか、必ずしも明らかではない点で相違する。
これらをまとめると、引用発明1の「再構成した映像」と本願発明の「少なくとも第1および第2の圧縮解除ビデオ・ストリームのそれぞれのフレーム」が対応するものの、本願発明は「前記少なくとも第1および第2の圧縮解除ビデオ・ストリームのそれぞれのフレームを第1および第2のプレゼンテーション・バッファ・ステージそれぞれに記憶するステップ」を有するのに対し、引用発明1は、スケーリングを含むビデオレンダリングを行うときにも、ビデオ圧縮を復号した出力は、「出力バッファ」を介して、スケーリングを含むビデオレンダリングに送られるのか、必ずしも明らかではない点で相違する。

4.5.「前記第1および第2の圧縮解除ビデオ・ストリームの記憶したフレームを、共通のサイズにスケーリングするステップ」
引用発明1の「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」は「複数のアプリケーションに対して入出力を行えるものであり」、「ビデオ圧縮符号化と復号化、ビデオ・レンダリング、オーディオ処理を含み」、「ビデオ・レンダリングは、ディザリングとスケーリングを含」むものである。ここで、上記『4.1.「少なくとも第1および第2のビデオ・ストリームを復号する方法であって、・・・を含む、前記方法。」』『4.3.「少なくとも第1および第2の圧縮解除ビデオ・ストリームをそれぞれ生成するための、前記少なくとも第1および第2のビデオ・ストリームのそれぞれを復号するステップであって、前記少なくとも第1および第2のビデオ・ストリームが空間的に並列に独立して復号されるステップ」』で述べたように、引用発明1は、これら「複数のアプリケーション」からは、本願発明の「少なくとも第1および第2のビデオストリーム」と対応している、それぞれ異なる「ビットストリームが入力され」、また、「ビデオ圧縮の復号」の結果、本願発明の「少なくとも第1および第2の圧縮解除ビデオ・ストリーム」に対応するものが生成されていること、また、引用発明1の「スケーリング」の対象は「フレーム」であるといえることから、引用発明1と本願発明は「前記第1および第2の圧縮解除ビデオ・ストリームのフレームをスケーリングするステップ」を有する点で一致しているといえるが、この「スケーリング」が、アプリケーション毎、そして、アプリケーションから入力されるビットストリーム毎に、同じ大きさにスケーリングされるか否かは明らかではないから、本願発明は「共通のサイズにスケーリングする」のに対し、引用発明1は、同じ大きさにスケーリングされるか否かは明らかではない点で相違する。また、上記『4.4.「前記少なくとも第1および第2の圧縮解除ビデオ・ストリームのそれぞれのフレームを第1および第2のプレゼンテーション・バッファ・ステージそれぞれに記憶するステップ」』で述べたのと同様に、本願発明では「共通のサイズにスケーリングする」対象の「フレーム」は「記憶した」ものであるのに対し、引用発明1では、その点が明らかではない点でも相違する。
これらをまとめると、引用発明1と本願発明は「前記第1および第2の圧縮解除ビデオ・ストリームのフレームをスケーリングするステップ」を有する点で一致しているが、本願発明は「共通のサイズにスケーリングする」のに対し、引用発明1は、同じ大きさにスケーリングされるか否かは明らかではない点、および、本願発明では「共通のサイズにスケーリングする」対象の「フレーム」は「記憶した」ものであるのに対し、引用発明1では、その点が明らかではない点で相違する。

5.一致点・相違点
上記「4.対比」で述べたことからみて、本願発明と引用発明1は以下の点で一致し、相違する。

[一致点]
「少なくとも第1および第2のビデオ・ストリームを復号する方法であって、
前記少なくとも第1および第2のビデオ・ストリームのそれぞれを、復号を行うためにルーティングするステップと、
少なくとも第1および第2の圧縮解除ビデオ・ストリームをそれぞれ生成するための、前記少なくとも第1および第2のビデオ・ストリームのそれぞれを復号するステップと、
前記第1および第2の圧縮解除ビデオ・ストリームのフレームをスケーリングするステップと、
を含む、前記方法。」

[相違点]
(1) 「少なくとも第1および第2の圧縮解除ビデオ・ストリームをそれぞれ生成するための、前記少なくとも第1および第2のビデオ・ストリームのそれぞれを復号するステップ」について、本願発明は「前記少なくとも第1および第2のビデオ・ストリームが空間的に並列に独立して復号されるステップ」であるのに対し、引用発明1のビデオ圧縮の復号は、アプリケーション毎、そして、アプリケーションから入力されるビットストリーム毎に、互いに空間的に並列に独立して動作するか明らかではない点。
(2) 本願発明は「前記少なくとも第1および第2の圧縮解除ビデオ・ストリームのそれぞれのフレームを第1および第2のプレゼンテーション・バッファ・ステージそれぞれに記憶するステップ」を有するのに対し、引用発明1は、スケーリングを含むビデオレンダリングを行うときにも、ビデオ圧縮を復号した出力は、「出力バッファ」を介して、スケーリングを含むビデオレンダリングに送られるのか、必ずしも明らかではない点。
(3) 「前記第1および第2の圧縮解除ビデオ・ストリームのフレームをスケーリングするステップ」について、本願発明は「共通のサイズにスケーリングする」のに対し、引用発明1は、同じ大きさにスケーリングされるか否かは明らかではない点。

6.当審の判断
以下、上記相違点(1)?(3)について判断する。

6.1.相違点(1)
まず、本願発明は「前記少なくとも第1および第2のビデオ・ストリームが空間的に並列に独立して復号される」ものであるが、この「空間的に並列に独立して復号される」の意味について、明細書の記載を参酌して検討する。本願明細書段落【0012】の「プロセッサ12は、大規模システム内でその他のプロセッサとネットワーク接続されているときには、利用可能なその他のプロセッサの数を検知することもできる。プロセッサ12以外の別のプロセッサが利用可能になった場合には、自動的に空間的並列処理を行うことができるようになる。」との記載からみて、本願発明の「空間的に並列に独立して復号される」とは、複数のプロセッサを利用して並列処理を行って復号処理を行うことを指すものと認めることができる。

これに対し、引用発明1は「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法であって、複数のアプリケーションに対して入出力を行えるものであり、複数のアプリケーションに対して入出力を行えるものであり、スレッドセーフ、且つ、完全リエントラントに作られ、マルチプロセッサシステムに良く対応し」ているものであり「MPEG-1ビデオ圧縮の復号の復号の出力部分に、アプリケーションによって確保され所有されている出力マルチバッファを有し、出力マルチバッファに入力されるピクチャの順序は表示されるべき順序と一致していないが、それから出力されるピクチャの順序は表示されるべき順序と一致し、ビデオ圧縮の復号には、アプリケーションが確保した入力バッファを介してビットストリームが入力され、アプリケーションが確保した出力バッファを介して再構成した映像を出力する」ものであるが、この構成の技術的意味について以下検討する。
まず、引用発明1の「スレッドセーフ、且つ、完全リエントラントに作られ」とは、引用例1の“Consistent with one of the design goals, SLIB was made thread-safe and fully reentrant.”(第67頁左欄第6?7行)(「設計目標の一つを実現するため、SLIBは、スレッドセーフ、且つ、完全リエントラントに作られている。」)との記載から、引用発明1が「圧縮の復号、レンダリング、表示を独立のスレッドで実行」できるのみならず、“SLIB”、すなわち、引用発明1が全体として「スレッドセーフ」且つ「リエントラント」であるということができる。
次に、「リエントラント」とは「プログラムやサブルーチンが、実行の途中で割り込まれ、その実行が完了する前に再び呼び出され実行されても安全だという性質」(http://ja.wikipedia.org/wiki/%E3%83%AA%E3%82%A8%E3%83%B3%E3%83%88%E3%83%A9%E3%83%B3%E3%83%88)を指すものということができ、「スレッドセーフ」とは「そのコードを複数のスレッドが同時並行的に実行しても問題が発生しない」(http://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89%E3%82%BB%E3%83%BC%E3%83%95)という意味である。
そして、上記したように、引用発明1が全体として「スレッドセーフ」且つ「リエントラント」であり、その結果「マルチプロセッサシステムに良く対応し」ており、更に、引用発明1は「複数のアプリケーションに対して入出力を行えるものであ」るから、結局、引用発明1は、あるアプリケーションから引用発明1が呼び出され、その実行が完了する前に、別のアプリケーションから再び引用発明1が呼び出され実行されても安全であって、更に、引用発明1をマルチプロセッサシステムによって複数のスレッドが同時並行的に実行しても問題が発生しないものであることとなる。
加えて、引用発明1は「MPEG-1ビデオ圧縮の復号の復号の出力部分に、アプリケーションによって確保され所有されている出力マルチバッファを有し、出力マルチバッファに入力されるピクチャの順序は表示されるべき順序と一致していないが、それから出力されるピクチャの順序は表示されるべき順序と一致し、ビデオ圧縮の復号には、アプリケーションが確保した入力バッファを介してビットストリームが入力され、アプリケーションが確保した出力バッファを介して再構成した映像を出力する」ものであって、処理に必要な「出力マルチバッファ」「入力バッファ」「出力バッファ」は、それぞれのアプリケーションによって確保されていることからみて、これら「出力マルチバッファ」「入力バッファ」「出力バッファ」は、アプリケーション毎、そして、アプリケーションから入力されるビットストリーム毎に、互いに重ならないように確保することができるものであるが、引用発明1は、このような構成を取ることによって、あるアプリケーションから引用発明1が呼び出され、その実行が完了する前に、別のアプリケーションから再び引用発明1が呼び出されたときに、入力されるビットストリームや出力される再構成した映像が同じ場所に書き込まれることによって破壊されることを回避しているものということができる。

これらの点からみて、引用発明1は、複数のアプリケーションから複数のビットストリームを復号するために、同時並行に呼び出されることは元々想定され、しかも、それに加えて、マルチプロセッサで実行できるように設計されているものであるといえるから、引用例1記載の発明において「前記少なくとも第1および第2のビデオ・ストリームが空間的に並列に独立して復号」したことは、その想定に基づいて、当業者が自然に考えつくことにすぎない。

6.2.相違点(2)
引用発明1は「圧縮の復号、レンダリング、表示を独立のスレッドで実行」されるものであり「ビデオ・レンダリングは、ディザリングとスケーリングを含」むものであるから、引用発明1における「圧縮の復号」と「レンダリング」に含まれる「スケーリング」は元来「時間的に並列に動作」するものである。
そして、引用発明2には「デコード部で生成される復号画像を保持する画像メモリ」を有することによって「画像の符号化データを復号処理し復号画像を生成するデコード部」と「画像メモリから読み込んだ復号画像を拡大縮小処理し、拡大縮小画像を生成するフィルタ部」の間で「デコード部の復号処理とフィルタ部の拡大縮小処理を非同期に時間的に並列に動作させることが可能である」ものが記載されており、引用発明1において「圧縮の復号」と「スケーリング」は「時間的に並列に動作」させるためには同様の構成が必要であるから、引用発明1において、スケーリングを含むビデオレンダリングを行うときにも、ビデオ圧縮を復号した出力を、出力バッファを介して、スケーリングを含むビデオレンダリングに送ったことは、当業者が自然に考えつくことにすぎない。

6.3.相違点(3)
引用例1の Figure 1 に示されるように引用発明1は最終的にはディスプレイに表示を行うものであること、また、ビデオを全画面表示することは極めて良く行われていることを考えると、ディスプレイに全画面表示するときには、入力の映像の大きさにかかわらず、そのディスプレイの解像度、画面の大きさに合わせたスケーリングを行う必要があるから、引用発明1でスケーリングの結果を「共通のサイズに」なるようにすることは、当業者が容易に想到し得たことである。

また、本願発明は、格別の作用効果を奏するものとも認められない。

したがって、本願発明は、引用発明1,2に基づき当業者が容易に発明できたものである。

7.むすび
以上のとおり、本願発明は、引用例1,2に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

したがって、本件出願は拒絶をすべきものである。

よって、結論のとおり審決する。
 
審理終結日 2013-12-09 
結審通知日 2013-12-10 
審決日 2013-12-24 
出願番号 特願2007-555132(P2007-555132)
審決分類 P 1 8・ 121- WZ (H04N)
最終処分 不成立  
前審関与審査官 川崎 優  
特許庁審判長 松尾 淳一
特許庁審判官 小池 正彦
奥村 元宏
発明の名称 アジャイル・デコーダ  
代理人 林 一好  
代理人 正林 真之  

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