【事件の表示】
　特願２００７−５５５１３２「アジャイル・デコーダ」拒絶査定不服審判事件〔平成１８年　８月２４日国際公開、ＷＯ２００６／０８８６４４、平成２０年１０月２３日国内公表、特表２００８−５３８４５７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、２００６年(平成１８年)２月１日（パリ条約による優先権主張外国庁受理２００５年２月１６日、米国）を国際出願日とする出願であって、平成２１年１月２６日付で審査請求がなされるとともに手続補正書が提出され、平成２３年４月７日付(起案日)で拒絶の理由が通知されたが、出願人からは何らの応答も無く、平成２３年９月９日付(起案日)で拒絶査定がなされたものである。　
　本件は、上記拒絶査定を不服として平成２４年１月１６日付で請求された拒絶査定不服審判であって、平成２４年２月６日付手続補正書によって請求の理由が補正され、当審において、平成２４年１２月１０日付(起案日)で拒絶の理由が通知され、平成２５年４月１１日付で意見書・手続補正書が提出され、平成２５年４月２５日付(起案日)で拒絶の理由が通知され、平成２５年１１月７日付で意見書・手続補正書が提出されたものである。 　
　
２．本願発明
　本願の請求項９に係る発明は、平成２１年１月２６日付、平成２５年４月１１日付、平成２５年１１月７日付手続補正書によって補正された明細書、特許請求の範囲及び図面の記載からみて、その特許請求の範囲の請求項９に記載されたとおりの以下のものと認める。（以下「本願発明」という。）　
　
「【請求項９】　
　少なくとも第１および第２のビデオ・ストリームを復号する方法であって、　
　前記少なくとも第１および第２のビデオ・ストリームのそれぞれを、復号を行うためにルーティングするステップと、　
　少なくとも第１および第２の圧縮解除ビデオ・ストリームをそれぞれ生成するための、前記少なくとも第１および第２のビデオ・ストリームのそれぞれを復号するステップであって、前記少なくとも第１および第２のビデオ・ストリームが空間的に並列に独立して復号されるステップと、　
　前記少なくとも第１および第２の圧縮解除ビデオ・ストリームのそれぞれのフレームを第１および第２のプレゼンテーション・バッファ・ステージそれぞれに記憶するステップと、　
　前記第１および第２の圧縮解除ビデオ・ストリームの記憶したフレームを、共通のサイズにスケーリングするステップと、　
を含む、前記方法。」　
　
３．引用刊行物
３．１．引用例１
３．１．１．引用例１の記載事項
　当審における平成２５年４月２５日付の拒絶の理由で引用した『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』(以下「引用例１」という。)には、図面とともに以下の記載がある。(なお、括弧内に当審で作成した翻訳を付記する。)　
　
“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.”(第５２頁右欄下から６行〜第５３頁左欄第３行)　
(「ソフトウェア・ビデオ・ライブラリという項目において、ディジタルのマルチメディア製品への組込が可能な、ビデオ圧縮、ビデオ圧縮の復号、および、再生についての共通アーキテクチャについての議論を行う。」)　
　
“
”(第５３頁)　
　
“
”(第５８頁)　
　
“The Software Video Library”(第６０頁右欄第１行)　
(「ソフトウェア・ビデオ・ライブラリ」)　
　
“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.”(第６０頁右欄第２７〜３９行)　
(「２つめの検討事項は、公式の標準であれ事実上の工業標準であれ、各種の新たなオーディオ／ビデオ圧縮規格がアプリケーションを供給する者の間で普及しつつあるため、ディジタルのプラットフォームでサポートする必要が出てきたことである。圧縮アルゴリズムを慎重に検討した結果、殆どの有名な手法が、共通の構成を用いていることを発見した。たとえば、JPEG, MPEG-1, MPEG-2, H.261, H.263のような５種類の国際標準では、ＤＣＴを用いる変換符号化器とそれに続く量子化器を用いている。同様に、これら５種類は最終段階にハフマン符号化を採用している。これは、一つのコーデックのための作業を、他のものに対して再利用できることを示している。」)　
　
“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.)”(第６１頁左欄第４行〜第６２頁左欄第１４行)　
(「アーキテクチャ　
　上に示した検討事項を前提として、我々が設計したソフトウェア・ビデオ・ライブラリ(SLIB)は、　
　
・　複数のオーディオ／ビデオ・コーデックとレンダラーを用いることができるような共通のアーキテクチャを与えるものである。　
・　ソフトウェア・ビデオ・コーデックの階層構造の中で、最も最下位の機能的に完全な層を与えるものである。　
・　最小のオーバーヘッド、高速、拡張可能の、スレッドセーフ、リエントラントなコードを与えるものである。　
・　マルチメディア・コンピューティングにおけるクライアント・サーバモデルが可能な、直感的、簡素、フレキシブル、拡張可能なアプリケーションプログラミングインタフェース(API)を与えるものである。　
・　複数の上位層に対して対応可能なものであって、ディジタルのマルチメディア製品に簡易かつシームレスに組み込むことが可能なAPIを与えるものである。　
　
　我々の目的は、エンドユーザのアプリケーションに用いることができるライブラリを作成することではなく、ディジタルのマルチメディア製品に容易に組み込むことができるビデオ・コーデックのための共通アーキテクチャを供給することである。SLIBのAPIは、アルゴリズムの調整と制御に関する自由度を大きくするため、ディジタルのマルチメディアサービスのAPIのスーパーセットとして設計されている。ライブラリは、ディジタルのマルチメディアサービスによってエンド・ユーザに供給される実際のプログラミング・インターフェースの下に入り込むようになっている。ディジタルのマルチメディアAPIは、WindowsやWindows NT上のマルチメディア・アプリケーションを、ディジタルのUNIXやOpen VMSへの移植を容易になるように、マイクロソフトのVideo for WindowsのAPIと同じものとなっている。図７はSLIBとディジタルのマルチメディア・ソフトウェアの階層構造の関係を示している。影付きの場所がこの論文で議論する部分である。　
　既に述べたように、ライブラリは、オーディオ／ビデオ・コーデックと、ディジタルが所有するビデオ・レンダリング・アルゴリズムのためのルーチンを含んでいる。それらルーチンは、アルゴリズム、および、対象のプラットフォーム、双方に対して最適化されている。ソフトウェアは、ディジタルのUNIX、Open VMS、マイクロソフトのWindows NTを含む複数のプラットフォームに対して供給されている。　
　３つの種類のルーチンが、(1)ビデオ圧縮符号化と復号化、(2)ビデオ・レンダリング、(3)オーディオ処理という、３つのサブシステムに対して供給されている。それぞれのサブシステムに対して、これらルーチンは、(a)セットアップ・ルーチン、(b)実行ルーチン、(c)問い合わせルーチン、(d)破壊ルーチン、のように更に分類することができる。セットアップ・ルーチンは、すべての必要な内部データ構造を作成し初期化し、更に、レンダリング・サブシステムでもちいられるような、各種のルックアップテーブルの値を計算する。実行ルーチンは、実際の符号化、復号化、レンダリングを実行する。問い合わせルーチンは、セット・アップルーチンと、実行ルーチンの間で用いることができ、例えば、ある入力フォーマットを扱うことができるかどうかというようなそのコーデックの能力に関する情報、ビットストリームが処理中かどうかという情報を、プログラマーに与える。また、このルーチンは、統計情報を得ることに用いることもできる。破壊ルーチンは、その名前が示すように、コーデックの終了とそれに伴う内部記憶(状態情報)を破壊することに用いられる。すべてのビデオ・コーデックのために、SLIBは、入力ビデオストリームにおける開始フレームを指すオフセットを含む目次を容易に作成する機能を有している。この有用な機能は短いビデオ・クリップのために有用で、目次が一度作成されると、ランダム・アクセスやその他のビデオ録画再生機としての機能を簡単に供給することができる。(これらのルーチンについては、サンプルアプリケーションについての項で更に議論する。)」)　
　
“
”(第６１頁)　
　
“ISO's MPEG-1 Video”(第６３頁左欄第２０行)　
(「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.”(第６４頁右欄下から４行〜第６５頁左欄第１８行)　
(「一般的に、符号化されたピクチャがデコーダに供給される順序は、表示される順序とは一致しない。検討すべき以下の例：　
　
表示順　　　　　　　I1 B2 B3 P4 B5 B6 P7 B8　
デコーダへの入力順　I1 P4 B2 B3 P7 B5 B6 I10　
　
　順序が異なるのは、圧縮アルゴリズムの副作用である。Bピクチャは、過去と未来の参照フレームの双方が復号されるまでは復号することができない。同様に、Pピクチャは、過去の参照フレームが復号されるまでは復号することができない。この問題を回避するため、SLIBは、出力マルチバッファを設けている。このマルチバッファの大きさは、一つの復号されたフレームの大きさの約３倍と等しい。例えば、4:2:0でサブサンプリングされたCIFイメージに対して、マルチバッファの大きさは、３５２×２８８×１．５×３バイトとなる。(実際の大きさは、コーデックの初期セットアップの間にライブラリから返される。)定常状態に達した時点で、復号のための呼び出しは、図１１に示されるように、次の正しいフレームを表示するように行われる。面倒な複写処理を避けるために、マルチバッファは、SLIBの上の層のソフトウェアによって、確保され所有されている。」)　
　
“
”(第６５頁)　
　
“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.”(第６５頁左欄第１９行〜右欄第１９行)　
(「ITU勧告H.261 (p × 64としても知られている。)　ライブラリの段階では、H.261勧告が、３つの種類のピクチャではなく、キーフレームと非キーフレームのみを有し、双方向予測を有さないという、一つの例外を除いて、H.261ストリームの圧縮を復号するのは、MPEG-1の復号化とよく似ている。インプリメンテーションに対する影響は、マルチバッファのサイズが、復号後のフレームの約２倍の大きさとなることである。更に、圧縮されたフレームがデコーダに送られる順序は、それが表示される順序と同じである。　
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.”(第６５頁右欄第２１〜３８行)　
(「ビデオレンダリングのインプリメンテーション　
　我々のビデオ・レンダリングのソフトウェア・インプリメンテーションは、この号の別の場所に記述されているハードウェアの実現と実質的に同様のものである。オフラインでルックアップテーブルを作成する過程で、既に複雑な計算は実行されているので、ハードウェアのインプリメンテーションと同様に、ソフトウェア・レンダラーは高速で簡素なものである。ハードウェアで行う場合とソフトウェアで行う場合の両方において、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.”(第６７頁左欄第６〜２６行)　
(「設計目標の一つを実現するため、SLIBは、スレッドセーフ、且つ、完全リエントラントに作られている。ディジタルUNIX、Open VMS、そして、マイクロソフトWindows NTというオペレーティングシステムは、すべてマルチスレッドアプリケーションに対応している。読み取り、圧縮の復号、レンダリング、表示を独立のスレッドで実行することによって、ビデオ再生のようなアプリケーションのパフォーマンスは向上する。更に、マルチスレッドのアプリケーションは、マルチプロセッサシステムに良く対応する。グローバル・マルチスレッド化は、ライブラリのコードがリエントラント且つスレッドセーフの時に可能である。ライブラリの内部処理をマルチスレッド化したときに、スレッドの生起と消滅によるオーバーヘッド、メモリアクセスの増加、コーデックのパイプラインのフラグメンテーションが、動作を遅くすることを発見した。一般的にリアルタイム・アプリケションにとって良いとされる、メモリのロック、優先度のスケジューリング、ノンプリエンプション、高速なタイマなどの他のオペレーティングシステムにおける最適化は試されてはいるが、現在の我々のインプリメンテーションには含まれていない。」)　
　
３．１．２．引用例１記載の発明
　引用例１の上記記載について検討する。　
 　
　第一に、引用例１の“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.”(第５２頁右欄下から６行〜第５３頁左欄第３行)(「ソフトウェア・ビデオ・ライブラリという項目において、ディジタルのマルチメディア製品への組込が可能な、ビデオ圧縮、ビデオ圧縮の復号、および、再生についての共通アーキテクチャについての議論を行う。」)、“Architecture　Keeping in mind the observations outlined above, we designed a software video library (SLIB) that would...”(第６１頁左欄第４〜６行)(「上に示した検討事項を前提として、我々が設計したソフトウェア・ビデオ・ライブラリ(SLIB)は...」)との記載からみて、引用例１に記載されている「ソフトウェア・ビデオ・ライブラリ(SLIB)」は「ビデオ圧縮、ビデオ圧縮の復号、および、再生」に関するものであるが、引用例１の記載からみて、この「ソフトウェア・ビデオ・ライブラリ(SLIB)」は「方法の発明」として把握することができるから、引用例１には「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」が記載されているといえる。　
　第二に、引用例１の“Provide a common architecture under which multiple audio and video codecs and renderers could be accessed”(第６１頁左欄第７〜９行)(「複数のオーディオ／ビデオ・コーデックとレンダラーを用いることができるような共通のアーキテクチャを与えるものである。」)、“As mentioned, the library contains routines for audio and video codecs and Digital's propriety videorendering algorithms.”(第６１頁右欄第１０〜１２行)(「既に述べたように、ライブラリは、オーディオ／ビデオ・コーデックと、ディジタルが所有するビデオ・レンダリング・アルゴリズムのためのルーチンを含んでいる。」)、“Three classes of routines are provided for the three subsystems: (1) video compression and decompression, (2) video rendering, and (3) audio processing.”(第６１頁右欄第１８〜２０行)(「３つの種類のルーチンが、(1)ビデオ圧縮符号化と復号化、(2)ビデオ・レンダリング、(3)オーディオ処理という、３つのサブシステムに対して供給されている。」)との記載からみて、引用例１記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」は「ビデオ圧縮符号化と復号化、ビデオ・レンダリング、オーディオ処理を含」むものである。　
　第三に、引用例１の“Provide a common architecture under which multiple audio and video codecs and renderers could be accessed”(第６１頁左欄第７〜９行)(「複数のオーディオ／ビデオ・コーデックとレンダラーを用いることができるような共通のアーキテクチャを与えるものである。」)との記載、および、Figure 7(第６１頁)の左下の“VIDEO　CODECS”というブロックが、JPEG, MPEG, H.261という画像圧縮の規格名と矢印で接続されているところからみて、引用例１記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」の「ビデオ圧縮符号化と復号化」としては「JPEG, MPEG, H.261等の複数種類のビデオ・コーデックを用いることができ」るものである。　
　第四に、引用例１の“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.”(第６１頁右欄第１８行〜第６２頁左欄第７行)(「３つの種類のルーチンが、(1)ビデオ圧縮符号化と復号化、(2)ビデオ・レンダリング、(3)オーディオ処理という、３つのサブシステムに対して供給されている。それぞれのサブシステムに対して、これらルーチンは、(a)セットアップ・ルーチン、(b)実行ルーチン、(c)問い合わせルーチン、(d)破壊ルーチン、のように更に分類することができる。セットアップ・ルーチンは、すべての必要な内部データ構造を作成し初期化し、更に、レンダリング・サブシステムでもちいられるような、各種のルックアップテーブルの値を計算する。実行ルーチンは、実際の符号化、復号化、レンダリングを実行する。問い合わせルーチンは、セット・アップルーチンと、実行ルーチンの間で用いることができ、例えば、ある入力フォーマットを扱うことができるかどうかというようなそのコーデックの能力に関する情報、ビットストリームが処理中かどうかという情報を、プログラマーに与える。また、このルーチンは、統計情報を得ることに用いることもできる。破壊ルーチンは、その名前が示すように、コーデックの終了とそれに伴う内部記憶(状態情報)を破壊することに用いられる。」)との記載からみて、引用例１記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」は「すべての必要な内部データ構造を作成し初期化し、更に、レンダリング・サブシステムでもちいられるような、各種のルックアップテーブルの値を計算するセットアップ・ルーチン」を有している。　
　第五に、引用例１の“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.”(第６５頁右欄第２１〜３８行)(「ビデオレンダリングのインプリメンテーション　．．．質が重要である場合、ソフトウェアはディザリングの前にスケーリングを実施するが、速度が重要である場合は、ディザリングの後にスケーリングを実施する。」)との記載、および、Figure 7(第６１頁)の中下の“VIDEO RENDERERS”というブロックが、“DITHER”、“ SCALE”と矢印で接続されているところからみて、引用例１記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」の「ビデオ・レンダリング」は「ディザリングとスケーリングを含」むものである。　
　第六に、引用例１の“Be fast, extensible, and thread-safe, providing reentrant code with minimal overhead”(第６１頁左欄第１２〜１３行)(「最小のオーバーヘッド、高速、拡張可能の、スレッドセーフ、リエントラントなコードを与えるものである。」)、“Consistent with one of the design goals, SLIB was made thread-safe and fully reentrant.”(第６７頁左欄第６〜７行)(「設計目標の一つを実現するため、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.”(第６７頁左欄第１３〜１５行)(「更に、マルチスレッドのアプリケーションは、マルチプロセッサシステムに良く対応する。グローバル・マルチスレッド化は、ライブラリのコードがリエントラント且つスレッドセーフの時に可能である。」)との記載からみて、引用例１記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」は「スレッドセーフ、且つ、完全リエントラントに作られ、マルチプロセッサシステムに良く対応し」ているものである。　
　第七に、引用例１の“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.”(第６７頁左欄第６〜１５行)(「設計目標の一つを実現するため、SLIBは、スレッドセーフ、且つ、完全リエントラントに作られている。ディジタルUNIX、Open VMS、そして、マイクロソフトWindows NTというオペレーティングシステムは、すべてマルチスレッドアプリケーションに対応している。読み取り、圧縮の復号、レンダリング、表示を独立のスレッドで実行することによって、ビデオ再生のようなアプリケーションのパフォーマンスは向上する。更に、マルチスレッドのアプリケーションは、マルチプロセッサシステムに良く対応する。グローバル・マルチスレッド化は、ライブラリのコードがリエントラント且つスレッドセーフの時に可能である。」)との記載からみて、引用例１記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」は「圧縮の復号、レンダリング、表示を独立のスレッドで実行」するものである。　
　第八に、Figure 7(第６１頁)の左上の“DIGITAL’S MULTIMEDIA CLIENT LIBRARY”というブロックに対して“APPLICATION 1 ・・・APPLICATION N”から複数の矢印で接続されていること、および、左上の“MICROSOFT’S VIDEO FOR WINDOWS (WINDOWS NT)”というブロックに対して“APPLICATION 1 ・・・APPLICATION M”から複数の矢印で接続されていることからみて、引用例１記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」は、「複数のアプリケーションに対して入出力を行える」ものである。　
　第九に、“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.”(第６４頁右欄下から４行〜第６５頁左欄第１８行)(「一般的に、符号化されたピクチャがデコーダに供給される順序は、表示される順序とは一致しない。検討すべき以下の例：　表示順　I1 B2 B3 P4 B5 B6 P7 B8　デコーダへの入力順　I1 P4 B2 B3 P7 B5 B6 I10　順序が異なるのは、圧縮アルゴリズムの副作用である。Bピクチャは、過去と未来の参照フレームの双方が復号されるまでは復号することができない。同様に、Pピクチャは、過去の参照フレームが復号されるまでは復号することができない。この問題を回避するため、SLIBは、出力マルチバッファを設けている。このマルチバッファの大きさは、一つの復号されたフレームの大きさの約３倍と等しい。例えば、4:2:0でサブサンプリングされたCIFイメージに対して、マルチバッファの大きさは、３５２×２８８×１．５×３バイトとなる。(実際の大きさは、コーデックの初期セットアップの間にライブラリから返される。)定常状態に達した時点で、復号のための呼び出しは、図１１に示されるように、次の正しいフレームを表示するように行われる。面倒な複写処理を避けるために、マルチバッファは、SLIBの上の層のソフトウェアによって、確保され所有されている。」)、Figure 11 の記載、および、引用例１第６３頁左欄第２０行〜第６５頁左欄第１８行の記載が“ISO's MPEG-1 Video”のためのものであるところからみて、引用例１記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」は「MPEG-1ビデオ圧縮の復号」の出力部分に output multibuffer(「出力マルチバッファ」) を有しているものであって、そのoutput multibuffer(「出力マルチバッファ」) に入力されるピクチャの順序は表示されるべき順序と一致していないが、それから出力されるピクチャの順序は表示されるべき順序と一致しているものである。更に、“To avoid expensive copy operations, the multibuffer is allocated and owned by the software above SLIB.”(第６５頁左欄第１６〜１８行)(「面倒な複写処理を避けるために、マルチバッファは、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.”(第６５頁左欄第３０〜３５行)(「H.261勧告を満たすために、SLIBは圧縮と復号のためのストリーミングインターフェースをインプリメントしている。このモデルでは、アプリケーションがコーデックに入力バッファを与え、コーデックはバッファの中のデータを処理して、処理済データをコールバックルーチンを介してアプリケーションに返す。」)、“Empty output buffers are also passed to the codec to fill with reconstructed images.”(第６５頁左欄第４０〜４１行)(「空白の出力バッファもコーデックに渡され、コーデックは再構成した映像でそれを埋める。」)との記載からみて、引用例１記載の発明である「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」の「ビデオ圧縮の復号」には、「アプリケーションが確保した入力バッファを介してビットストリームが入力され」、「アプリケーションが確保した出力バッファを介して再構成した映像を出力する」ものである。　
　
　したがって、引用例１には以下の発明(以下「引用発明１」という。)が記載されている。　
　
「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法であって、　
複数のアプリケーションに対して入出力を行えるものであり、スレッドセーフ、且つ、完全リエントラントに作られ、マルチプロセッサシステムに良く対応し、　
ビデオ圧縮符号化と復号化、ビデオ・レンダリング、オーディオ処理を含み、　
ビデオ圧縮符号化と復号化としては、JPEG, MPEG, H.261等の複数種類のビデオ・コーデックを用いることができ、　
ビデオ・レンダリングは、ディザリングとスケーリングを含み、圧縮の復号、レンダリング、表示を独立のスレッドで実行し、　
すべての必要な内部データ構造を作成し初期化し、更に、レンダリング・サブシステムでもちいられるような、各種のルックアップテーブルの値を計算するセットアップ・ルーチンを有し、　
MPEG-1ビデオ圧縮の復号の復号の出力部分に、アプリケーションによって確保され所有されている出力マルチバッファを有し、出力マルチバッファに入力されるピクチャの順序は表示されるべき順序と一致していないが、それから出力されるピクチャの順序は表示されるべき順序と一致し、　
ビデオ圧縮の復号には、アプリケーションが確保した入力バッファを介してビットストリームが入力され、アプリケーションが確保した出力バッファを介して再構成した映像を出力する、　
ビデオ圧縮、ビデオ圧縮の復号、および、再生方法。」　
　
３．２．引用例２
３．２．１．引用例２の記載事項
　当審における平成２５年４月２５日付の拒絶の理由で引用した特開２００２−３５４４７５号公報(以下「引用例２」という。)には、図面とともに以下の記載がある。　
「【０００７】 　
 【課題を解決するための手段】本発明（請求項１）の画像復号処理装置は、画像の符号化データを復号処理し復号画像を生成するデコード部と、デコード部で生成される復号画像を保持する画像メモリと、画像メモリから読み込んだ復号画像を拡大縮小処理し、拡大縮小画像を生成するフィルタ部と、デコード部における復号処理時間の指定と、フィルタ部における拡大縮小処理時間の指定と、デコード部で生成される復号画像を書き込む画像メモリの領域指定と、フィルタ部で復号画像を読み込む画像メモリの領域指定とを行う制御部とで構成される。」　
「【０００８】この構成により、デコード部の復号処理とフィルタ部の拡大縮小処理を非同期に行うことが可能である。」　
「【００２９】 　
 【発明の実施の形態】以下、本発明の実施の形態について、図面を参照しながら説明する。」　
「【００３０】（実施の形態１）図１は、本発明の実施の形態１における画像処理装置の構成を示すブロック図である。本実施の形態の画像復号処理装置は、画像の符号化データ１５を復号処理し、復号画像１６を生成するデコード部１１と、デコード部１１で生成される復号画像１６を保持する画像メモリの機能を備えたフレームメモリ１２と、フレームメモリ１２の復号画像１７を読み込み、拡大縮小処理し、拡大縮小画像１８を生成するフィルタ部１３と、デコード部１１における復号処理時間の指定と、フィルタ部１３における拡大縮小処理時間の指定と、デコード部１１で生成される復号画像を書き込むフレームメモリ１２の領域指定と、フィルタ部１３で復号画像を読み込むフレームメモリ１２の領域指定を行う制御部１４から構成される。」　
「【００３１】デコード部１１は、画像を１６ラインごとに復号処理し、復号された部分復号画像をフレームメモリ１２に書き込む。フィルタ部１３は、フレームメモリ１２の復号画像を１６ラインごとに読み込み、拡大縮小処理し、部分拡大縮小画像を出力する。」　
「【００３２】制御部１４によるデコード部１１の制御手順について、図２を参照して説明する。ＳＴＥＰ２０では、デコード部１１を起動する。ＳＴＥＰ２１では、デコード部１１で復号される最初の部分復号画像を書き込むフレームメモリ１２の領域を指定する。」　
「【００３３】ＳＴＥＰ２２では、ＳＴＥＰ２１で指定したフレームメモリ１２領域に以前に復号した部分復号画像がある場合には、その部分復号画像に対して、フィルタ部１３の拡大縮小処理がなされているか否かで以降の処理を分岐させる。拡大縮小処理がなされていない場合には、ＳＴＥＰ２３で、デコード部１１の動作を一時停止し、再度、ＳＴＥＰ２２に戻る。こうして以前に復号した部分復号画像に対する拡大縮小処理がなされるまで、デコード部１１を停止する。」　
「【００３４】ＳＴＥＰ２２で、以前に復号した部分復号画像に対して拡大縮小処理がなされている場合には、ＳＴＥＰ２４で部分画像の復号処理を行い、ＳＴＥＰ２５で生成される部分復号画像をフレームメモリ１２の指定領域に書き込みを行う。」　
「【００３５】ＳＴＥＰ２６では、復号処理した部分画像が画像の最後の部分画像である場合には、ＳＴＥＰ２７で、デコード部１１を終了し、最後の部分画像でない場合には、ＳＴＥＰ２８で、次の部分復号画像の書き込み領域を指定し、ＳＴＥＰ２１に戻り、同様の処理を繰り返す。」　
「【００３６】次に制御部１４によるフィルタ部１３の制御手順について、図３を参照して説明する。ＳＴＥＰ３０で、フィルタ部１３を起動する。ＳＴＥＰ３１では、フレームメモリから部分復号画像を読み込む領域を指定する。ＳＴＥＰ３２では、読み込み領域に部分復号画像がある場合には、この部分復号画像が次に拡大縮小処理する部分復号画像か否かにより以降の処理を分岐させる。この部分復号画像が次に拡大縮小処理を行う部分復号画像でない場合には、ＳＴＥＰ３３で、フィルタ部１３を一時停止し、その後、ＳＴＥＰ３２に戻る。」　
「【００３７】こうして、部分復号画像が書き込まれるまで、フィルタ部１３を停止する。ＳＴＥＰ３２で、次に拡大縮小処理する部分復号画像がある場合には、ＳＴＥＰ３４で、部分復号画像を読み込み、ＳＴＥＰ３５で、部分復号画像の拡大縮小処理を行う。ＳＴＥＰ３６では、拡大縮小処理した部分復号画像が復号画像の最後の部分復号画像である場合には、ＳＴＥＰ３７でフィルタ部１３を終了し、最後の部分復号画像でない場合には、ＳＴＥＰ３８に戻り、同様の処理を繰り返す。」　
「【００３８】次に、デコード部１１で生成される部分復号画像を、フレームメモリに書き込む領域を決定する手順について図４を参照して説明する。部分復号画像は、復号画像の上から順に復号され、ここでは、部分復号画像１に続き、部分復号画像２が生成される。部分復号画像１をフレームメモリ１２の第１の領域に書き込むとすると、部分復号画像２は、第１の領域に続く第２の領域に書き込みを行う。ただし、第１の領域に続く領域が存在しない場合には、フレームメモリ１２の先頭の領域である、第３の領域に書き込みを行う。」　
「【００３９】次に、デコード部１１で生成される部分復号画像のうち、各画像の最初の部分復号画像を書き込むフレームメモリ１２の領域の決定手順について、図５を参照して説明する。」　
「【００４０】図５（Ａ）のフローチャートにおいて、ＳＴＥＰ５１で、フレームメモリ１２の容量が、復号画像のデータ量より大きい場合には、ＳＴＥＰ５４で、フレームメモリ１２の先頭領域に書き込む。ＳＴＥＰ５１で、フレームメモリ１２の容量が、復号画像のデータ量より小さい場合には、ＳＴＥＰ５２に進む。ＳＴＥＰ５２では、フレームメモリ１２に、フィルタ部１３での拡大縮小処理が未処理である部分復号画像があるか否かで、その後の処理を分岐する。ＳＴＥＰ５２で、拡大縮小処理が未処理である部分復号画像がある場合には、ＳＴＥＰ５３で、前部分復号画像を保持する領域に続く領域に書き込みを行い、拡大縮小処理が未処理である部分復号画像がない場合には、ＳＴＥＰ５４でフレームメモリ１２の先頭領域に書き込む。」　
「【００４１】次に、本実施の形態の動作について図６を参照して説明する。まず、復号処理１は、復号処理開始時間１に画像の復号処理を開始する。その後、デコード部１１において復号した画像がフレームメモリ１２に１６ライン分書き込まれた直後の時間である、拡大縮小処理１開始時間に拡大縮小処理１を開始する。復号処理１が終了すると、直後に次の画像に対する復号処理２を開始する。その後、拡大縮小処理１が終了すると、直後に次の画像に対する拡大縮小処理２を開始する。」　
「【００４２】デコード部１１は、各画像に対して復号処理期限が設定されており、それまでに復号処理が終了しない場合には、現復号処理を中断し、直ちに次の画像の復号処理を開始する。」　
「【００４３】フィルタ部１３も同様に、各画像に対して拡大縮小処理期限が設定されており、それまでに拡大縮小処理が終了しない場合には、現拡大縮小処理を中断し、直ちに次の画像の拡大縮小処理を開始する。」　
「【００４４】以上のように本実施の形態によれば、フィルタ部１３は、前画像に対する復号処理の終了後、直ちに次の画像の復号処理を開始することができ、また、フィルタ部１３においても、同様に、前画像に対する拡大縮小処理の終了後、直ちに次の画像の拡大縮小処理を開始することができる。」　
「【００４５】また、フレームメモリ１２への復号画像の書き込み方法を、フレームメモリ１２の使用状態によって切り替えることにより、データの書き潰しや復号画像の読み間違い等を防止し、さらに、デコード部１１とフィルタ部１３において、復号画像の読み書きを効率よく行うことができる。」　
「【００４６】尚、処理方法については、本実施の形態では、デコード部１１で生成される復号画像は、１６ライン単位で、フレームメモリ１２に書き込むと述べたが、それに制約されるものではない。」　
「【００４７】また、デコード部１１で生成される復号画像のうち、最初の部分復号画像を書き込むフレームメモリ１２領域は、前復号画像に続く領域を指定してもよい。こうすることで、デコード部１１は各画像の復号処理開始後、フィルタ部１３において部分復号画像を読み込むフレームメモリ１２領域と、同一のフレームメモリ１２領域を使用することが少なくなり、復号処理を停止することなく、スムーズに実行することができる。」　
「【図１】
」　
「【図２】
」　
「【図３】
」　
「【図４】
」　
「【図５】
」　
「【図６】
」　
　
３．２．２．引用例２記載の発明
　上記段落【０００７】【０００８】【００４１】〜【００４７】、および、【図１】【図６】の記載からみて、引用例２には以下の発明（以下「引用発明２」という。）が記載されている。　
　
「画像の符号化データを復号処理し復号画像を生成するデコード部と、デコード部で生成される復号画像を保持する画像メモリと、画像メモリから読み込んだ復号画像を拡大縮小処理し、拡大縮小画像を生成するフィルタ部と、デコード部における復号処理時間の指定と、フィルタ部における拡大縮小処理時間の指定と、デコード部で生成される復号画像を書き込む画像メモリの領域指定と、フィルタ部で復号画像を読み込む画像メモリの領域指定とを行う制御部とで構成される画像復号処理装置であって、デコード部の復号処理とフィルタ部の拡大縮小処理を非同期に時間的に並列に動作させることが可能である画像復号処理装置。」　
　
４．対比
　本願発明と引用発明１を比較する。　
　
４．１．「少なくとも第１および第２のビデオ・ストリームを復号する方法であって、・・・を含む、前記方法。」
　引用発明１は「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法であって、複数のアプリケーションに対して入出力を行えるものであ」り「ビデオ圧縮の復号には、アプリケーションが確保した入力バッファを介してビットストリームが入力される」ものであって、これら「複数のアプリケーション」からは、それぞれ異なる「ビットストリームが入力され」、これら「ビットストリーム」は少なくとも２つあるということができるから、引用発明１の「ビットストリーム」は本願発明の「少なくとも第１および第２のビデオ・ストリーム」と対応し、引用発明１と本願発明は「少なくとも第１および第２のビデオ・ストリームを復号する方法であって、・・・を含む、前記方法。」である点で一致している。　
　
４．２．「前記少なくとも第１および第２のビデオ・ストリームのそれぞれを、復号を行うためにルーティングするステップ」
　引用発明１は「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法であって、複数のアプリケーションに対して入出力を行えるものであり」、「ビデオ圧縮符号化と復号化としては、JPEG, MPEG, H.261等の複数種類のビデオ・コーデックを用いることができ」、「すべての必要な内部データ構造を作成し初期化し、更に、レンダリング・サブシステムでもちいられるような、各種のルックアップテーブルの値を計算するセットアップ・ルーチンを有し」ており、この「セットアップ・ルーチン」による「内部データ構造を作成し初期化」することによって、入力される「ビットストリーム」に対して、JPEG, MPEG, H.261等の複数種類のビデオ・コーデックの中からいずれを用いるのか設定しているということができ、これは、入力されるビットストリームをそれを復号するに適切なビデオ・コーデックにルーティングするように設定しているといえる。更に、上記『４．１．「少なくとも第１および第２のビデオ・ストリームを復号する方法であって、・・・を含む、前記方法。」』で述べたように、引用発明１は、これら「複数のアプリケーション」からは、それぞれ異なる「ビットストリームが入力され」、これら「ビットストリーム」は本願発明の「少なくとも第１および第２のビデオ・ストリーム」と対応しているといえるから、引用発明１と本願発明は「前記少なくとも第１および第２のビデオ・ストリームのそれぞれを、復号を行うためにルーティングするステップ」を有する点で一致している。　
　
４．３．「少なくとも第１および第２の圧縮解除ビデオ・ストリームをそれぞれ生成するための、前記少なくとも第１および第２のビデオ・ストリームのそれぞれを復号するステップであって、前記少なくとも第１および第２のビデオ・ストリームが空間的に並列に独立して復号されるステップ」
　引用発明１は「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法であって、複数のアプリケーションに対して入出力を行えるものであ」って、上記『４．１．「少なくとも第１および第２のビデオ・ストリームを復号する方法であって、・・・を含む、前記方法。」』で述べたように、引用発明１は、これら「複数のアプリケーション」からは、それぞれ異なる「ビットストリームが入力され」、これら「ビットストリーム」は本願発明の「少なくとも第１および第２のビデオ・ストリーム」と対応しているといえ、また、それに対して「ビデオ圧縮の復号」を行った結果、本願発明の「少なくとも第１および第２の圧縮解除ビデオ・ストリーム」に対応するものが生成されているから、引用発明１と本願発明は「少なくとも第１および第２の圧縮解除ビデオ・ストリームをそれぞれ生成するための、前記少なくとも第１および第２のビデオ・ストリームのそれぞれを復号するステップ」を有する点では一致しているということができる。　
　しかしながら、引用例１には引用発明１のビデオ圧縮の復号が、アプリケーション毎、そして、アプリケーションから入力されるビットストリーム毎に、互いに空間的に並列に独立して動作することは記載されていないから、引用発明１のビデオ圧縮の復号が、アプリケーション毎、そして、アプリケーションから入力されるビットストリーム毎に、互いに空間的に並列に独立して動作するか明らかではない。すなわち、本願発明は「前記少なくとも第１および第２のビデオ・ストリームが空間的に並列に独立して復号される」ものであるのに対し、引用発明１のビデオ圧縮の復号は、アプリケーション毎、そして、アプリケーションから入力されるビットストリーム毎に、互いに空間的に並列に独立して動作するか明らかではない点で相違する。　
　これらをまとめると、引用発明１と本願発明は「少なくとも第１および第２の圧縮解除ビデオ・ストリームをそれぞれ生成するための、前記少なくとも第１および第２のビデオ・ストリームのそれぞれを復号するステップ」を有する点では一致しているが、本願発明は、この「ステップ」が「前記少なくとも第１および第２のビデオ・ストリームが空間的に並列に独立して復号されるステップ」であるのに対し、引用発明１のビデオ圧縮の復号は、アプリケーション毎、そして、アプリケーションから入力されるビットストリーム毎に、互いに空間的に並列に独立して動作するか明らかではない点で相違する。　
　
４．４．「前記少なくとも第１および第２の圧縮解除ビデオ・ストリームのそれぞれのフレームを第１および第２のプレゼンテーション・バッファ・ステージそれぞれに記憶するステップ」
　引用発明１は「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法であって、複数のアプリケーションに対して入出力を行えるものであり、スレッドセーフ、且つ、完全リエントラントに作られ、ビデオ圧縮符号化と復号化、ビデオ・レンダリング、オーディオ処理を含」むものであり、「ビデオ・レンダリングは、ディザリングとスケーリングを含み、圧縮の復号、レンダリング、表示を独立のスレッドで実行し」ているものであって、更に、「ビデオ圧縮の復号には、アプリケーションが確保した入力バッファを介してビットストリームが入力され、アプリケーションが確保した出力バッファを介して再構成した映像を出力する」ものである。そして、引用発明１の「再構成した映像」と本願発明の「少なくとも第１および第２の圧縮解除ビデオ・ストリームのそれぞれのフレーム」が対応している。　
　しかしながら、引用例１の記載からは、引用発明１の「出力バッファ」が用いられるのは、ビデオ圧縮を復号し直接アプリケーションに対して再構成した映像を出力するときのみなのか、それとも、ビデオ圧縮を復号した後、スケーリングを含むビデオレンダリングを行うときにも、ビデオ圧縮を復号した出力は、この「出力バッファ」を介して、スケーリングを含むビデオレンダリングに送られるのか、必ずしも明らかではない。これに対し、本願発明は「前記少なくとも第１および第２の圧縮解除ビデオ・ストリームのそれぞれのフレームを第１および第２のプレゼンテーション・バッファ・ステージそれぞれに記憶するステップ」「前記第１および第２の圧縮解除ビデオ・ストリームの記憶したフレームを、共通のサイズにスケーリングするステップ」双方を有するとことからみて、この「第１および第２のプレゼンテーション・バッファ・ステージ」は「共通のサイズにスケーリングする」時に用いられているから、本願発明は「前記少なくとも第１および第２の圧縮解除ビデオ・ストリームのそれぞれのフレームを第１および第２のプレゼンテーション・バッファ・ステージそれぞれに記憶するステップ」を有するのに対し、引用発明１は、スケーリングを含むビデオレンダリングを行うときにも、ビデオ圧縮を復号した出力は、「出力バッファ」を介して、スケーリングを含むビデオレンダリングに送られるのか、必ずしも明らかではない点で相違する。
　これらをまとめると、引用発明１の「再構成した映像」と本願発明の「少なくとも第１および第２の圧縮解除ビデオ・ストリームのそれぞれのフレーム」が対応するものの、本願発明は「前記少なくとも第１および第２の圧縮解除ビデオ・ストリームのそれぞれのフレームを第１および第２のプレゼンテーション・バッファ・ステージそれぞれに記憶するステップ」を有するのに対し、引用発明１は、スケーリングを含むビデオレンダリングを行うときにも、ビデオ圧縮を復号した出力は、「出力バッファ」を介して、スケーリングを含むビデオレンダリングに送られるのか、必ずしも明らかではない点で相違する。
　
４．５．「前記第１および第２の圧縮解除ビデオ・ストリームの記憶したフレームを、共通のサイズにスケーリングするステップ」
　引用発明１の「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法」は「複数のアプリケーションに対して入出力を行えるものであり」、「ビデオ圧縮符号化と復号化、ビデオ・レンダリング、オーディオ処理を含み」、「ビデオ・レンダリングは、ディザリングとスケーリングを含」むものである。ここで、上記『４．１．「少なくとも第１および第２のビデオ・ストリームを復号する方法であって、・・・を含む、前記方法。」』『４．３．「少なくとも第１および第２の圧縮解除ビデオ・ストリームをそれぞれ生成するための、前記少なくとも第１および第２のビデオ・ストリームのそれぞれを復号するステップであって、前記少なくとも第１および第２のビデオ・ストリームが空間的に並列に独立して復号されるステップ」』で述べたように、引用発明１は、これら「複数のアプリケーション」からは、本願発明の「少なくとも第１および第２のビデオストリーム」と対応している、それぞれ異なる「ビットストリームが入力され」、また、「ビデオ圧縮の復号」の結果、本願発明の「少なくとも第１および第２の圧縮解除ビデオ・ストリーム」に対応するものが生成されていること、また、引用発明１の「スケーリング」の対象は「フレーム」であるといえることから、引用発明１と本願発明は「前記第１および第２の圧縮解除ビデオ・ストリームのフレームをスケーリングするステップ」を有する点で一致しているといえるが、この「スケーリング」が、アプリケーション毎、そして、アプリケーションから入力されるビットストリーム毎に、同じ大きさにスケーリングされるか否かは明らかではないから、本願発明は「共通のサイズにスケーリングする」のに対し、引用発明１は、同じ大きさにスケーリングされるか否かは明らかではない点で相違する。また、上記『４．４．「前記少なくとも第１および第２の圧縮解除ビデオ・ストリームのそれぞれのフレームを第１および第２のプレゼンテーション・バッファ・ステージそれぞれに記憶するステップ」』で述べたのと同様に、本願発明では「共通のサイズにスケーリングする」対象の「フレーム」は「記憶した」ものであるのに対し、引用発明１では、その点が明らかではない点でも相違する。　
　これらをまとめると、引用発明１と本願発明は「前記第１および第２の圧縮解除ビデオ・ストリームのフレームをスケーリングするステップ」を有する点で一致しているが、本願発明は「共通のサイズにスケーリングする」のに対し、引用発明１は、同じ大きさにスケーリングされるか否かは明らかではない点、および、本願発明では「共通のサイズにスケーリングする」対象の「フレーム」は「記憶した」ものであるのに対し、引用発明１では、その点が明らかではない点で相違する。
　
５．一致点・相違点
　上記「４．対比」で述べたことからみて、本願発明と引用発明１は以下の点で一致し、相違する。　
　
[一致点]　
「少なくとも第１および第２のビデオ・ストリームを復号する方法であって、　
　前記少なくとも第１および第２のビデオ・ストリームのそれぞれを、復号を行うためにルーティングするステップと、　
　少なくとも第１および第２の圧縮解除ビデオ・ストリームをそれぞれ生成するための、前記少なくとも第１および第２のビデオ・ストリームのそれぞれを復号するステップと、　
　前記第１および第２の圧縮解除ビデオ・ストリームのフレームをスケーリングするステップと、　
を含む、前記方法。」　
　
[相違点]　
(1)　「少なくとも第１および第２の圧縮解除ビデオ・ストリームをそれぞれ生成するための、前記少なくとも第１および第２のビデオ・ストリームのそれぞれを復号するステップ」について、本願発明は「前記少なくとも第１および第２のビデオ・ストリームが空間的に並列に独立して復号されるステップ」であるのに対し、引用発明１のビデオ圧縮の復号は、アプリケーション毎、そして、アプリケーションから入力されるビットストリーム毎に、互いに空間的に並列に独立して動作するか明らかではない点。　
(2)　本願発明は「前記少なくとも第１および第２の圧縮解除ビデオ・ストリームのそれぞれのフレームを第１および第２のプレゼンテーション・バッファ・ステージそれぞれに記憶するステップ」を有するのに対し、引用発明１は、スケーリングを含むビデオレンダリングを行うときにも、ビデオ圧縮を復号した出力は、「出力バッファ」を介して、スケーリングを含むビデオレンダリングに送られるのか、必ずしも明らかではない点。 　
(3)　「前記第１および第２の圧縮解除ビデオ・ストリームのフレームをスケーリングするステップ」について、本願発明は「共通のサイズにスケーリングする」のに対し、引用発明１は、同じ大きさにスケーリングされるか否かは明らかではない点。　
　
６．当審の判断
　以下、上記相違点(1)〜(3)について判断する。 　
 　 　
６．１．相違点(1)
　まず、本願発明は「前記少なくとも第１および第２のビデオ・ストリームが空間的に並列に独立して復号される」ものであるが、この「空間的に並列に独立して復号される」の意味について、明細書の記載を参酌して検討する。本願明細書段落【００１２】の「プロセッサ１２は、大規模システム内でその他のプロセッサとネットワーク接続されているときには、利用可能なその他のプロセッサの数を検知することもできる。プロセッサ１２以外の別のプロセッサが利用可能になった場合には、自動的に空間的並列処理を行うことができるようになる。」との記載からみて、本願発明の「空間的に並列に独立して復号される」とは、複数のプロセッサを利用して並列処理を行って復号処理を行うことを指すものと認めることができる。　
　
　これに対し、引用発明１は「ビデオ圧縮、ビデオ圧縮の復号、および、再生方法であって、複数のアプリケーションに対して入出力を行えるものであり、複数のアプリケーションに対して入出力を行えるものであり、スレッドセーフ、且つ、完全リエントラントに作られ、マルチプロセッサシステムに良く対応し」ているものであり「MPEG-1ビデオ圧縮の復号の復号の出力部分に、アプリケーションによって確保され所有されている出力マルチバッファを有し、出力マルチバッファに入力されるピクチャの順序は表示されるべき順序と一致していないが、それから出力されるピクチャの順序は表示されるべき順序と一致し、ビデオ圧縮の復号には、アプリケーションが確保した入力バッファを介してビットストリームが入力され、アプリケーションが確保した出力バッファを介して再構成した映像を出力する」ものであるが、この構成の技術的意味について以下検討する。　
　まず、引用発明1の「スレッドセーフ、且つ、完全リエントラントに作られ」とは、引用例１の“Consistent with one of the design goals, SLIB was made thread-safe and fully reentrant.”(第６７頁左欄第６〜７行)(「設計目標の一つを実現するため、SLIBは、スレッドセーフ、且つ、完全リエントラントに作られている。」)との記載から、引用発明１が「圧縮の復号、レンダリング、表示を独立のスレッドで実行」できるのみならず、“SLIB”、すなわち、引用発明１が全体として「スレッドセーフ」且つ「リエントラント」であるということができる。　
　次に、「リエントラント」とは「プログラムやサブルーチンが、実行の途中で割り込まれ、その実行が完了する前に再び呼び出され実行されても安全だという性質」(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)という意味である。　
　そして、上記したように、引用発明１が全体として「スレッドセーフ」且つ「リエントラント」であり、その結果「マルチプロセッサシステムに良く対応し」ており、更に、引用発明１は「複数のアプリケーションに対して入出力を行えるものであ」るから、結局、引用発明１は、あるアプリケーションから引用発明１が呼び出され、その実行が完了する前に、別のアプリケーションから再び引用発明１が呼び出され実行されても安全であって、更に、引用発明１をマルチプロセッサシステムによって複数のスレッドが同時並行的に実行しても問題が発生しないものであることとなる。　
　加えて、引用発明１は「MPEG-1ビデオ圧縮の復号の復号の出力部分に、アプリケーションによって確保され所有されている出力マルチバッファを有し、出力マルチバッファに入力されるピクチャの順序は表示されるべき順序と一致していないが、それから出力されるピクチャの順序は表示されるべき順序と一致し、ビデオ圧縮の復号には、アプリケーションが確保した入力バッファを介してビットストリームが入力され、アプリケーションが確保した出力バッファを介して再構成した映像を出力する」ものであって、処理に必要な「出力マルチバッファ」「入力バッファ」「出力バッファ」は、それぞれのアプリケーションによって確保されていることからみて、これら「出力マルチバッファ」「入力バッファ」「出力バッファ」は、アプリケーション毎、そして、アプリケーションから入力されるビットストリーム毎に、互いに重ならないように確保することができるものであるが、引用発明１は、このような構成を取ることによって、あるアプリケーションから引用発明１が呼び出され、その実行が完了する前に、別のアプリケーションから再び引用発明１が呼び出されたときに、入力されるビットストリームや出力される再構成した映像が同じ場所に書き込まれることによって破壊されることを回避しているものということができる。　
　
　これらの点からみて、引用発明１は、複数のアプリケーションから複数のビットストリームを復号するために、同時並行に呼び出されることは元々想定され、しかも、それに加えて、マルチプロセッサで実行できるように設計されているものであるといえるから、引用例１記載の発明において「前記少なくとも第１および第２のビデオ・ストリームが空間的に並列に独立して復号」したことは、その想定に基づいて、当業者が自然に考えつくことにすぎない。　
　
６．２．相違点(2)
　引用発明１は「圧縮の復号、レンダリング、表示を独立のスレッドで実行」されるものであり「ビデオ・レンダリングは、ディザリングとスケーリングを含」むものであるから、引用発明１における「圧縮の復号」と「レンダリング」に含まれる「スケーリング」は元来「時間的に並列に動作」するものである。　
　そして、引用発明２には「デコード部で生成される復号画像を保持する画像メモリ」を有することによって「画像の符号化データを復号処理し復号画像を生成するデコード部」と「画像メモリから読み込んだ復号画像を拡大縮小処理し、拡大縮小画像を生成するフィルタ部」の間で「デコード部の復号処理とフィルタ部の拡大縮小処理を非同期に時間的に並列に動作させることが可能である」ものが記載されており、引用発明１において「圧縮の復号」と「スケーリング」は「時間的に並列に動作」させるためには同様の構成が必要であるから、引用発明１において、スケーリングを含むビデオレンダリングを行うときにも、ビデオ圧縮を復号した出力を、出力バッファを介して、スケーリングを含むビデオレンダリングに送ったことは、当業者が自然に考えつくことにすぎない。　
　
６．３．相違点(3)
　引用例１の Figure 1 に示されるように引用発明１は最終的にはディスプレイに表示を行うものであること、また、ビデオを全画面表示することは極めて良く行われていることを考えると、ディスプレイに全画面表示するときには、入力の映像の大きさにかかわらず、そのディスプレイの解像度、画面の大きさに合わせたスケーリングを行う必要があるから、引用発明１でスケーリングの結果を「共通のサイズに」なるようにすることは、当業者が容易に想到し得たことである。　
　
　また、本願発明は、格別の作用効果を奏するものとも認められない。　
　
　したがって、本願発明は、引用発明１，２に基づき当業者が容易に発明できたものである。　
　
７．むすび
　以上のとおり、本願発明は、引用例１，２に記載された発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。　
　
　したがって、本件出願は拒絶をすべきものである。　
　
　よって、結論のとおり審決する。