【事件の表示】
　特願２０１１−５３４９０５「ＧＰＵ加速を伴うソフトウエアビデオトランスコーダ」拒絶査定不服審判事件〔平成２２年　５月１４日国際公開、ＷＯ２０１０／０５４０１１、平成２４年　４月　５日国内公表、特表２０１２−５０８４８５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、２００９年（平成２１年）１１月４日（パリ条約による優先権主張外国庁受理２００８年１１月４日、米国）を国際出願日とする国際特許出願であって、手続の概要は以下のとおりである。
　
手続補正　　　　　　　：平成２４年１０月２３日
拒絶理由通知　　　　　：平成２５年１１月１１日（起案日）
手続補正　　　　　　　：平成２６年　３月１３日
拒絶理由通知（最後）　：平成２６年　４月２１日（起案日）
手続補正　　　　　　　：平成２６年　９月２４日
補正却下の決定　　　　：平成２６年１０月２１日
拒絶査定　　　　　　　：平成２６年１０月２１日（起案日）
拒絶査定不服審判請求　：平成２７年　３月　２日
手続補正　　　　　　　：平成２７年　３月　２日
拒絶理由（当審）　　　：平成２８年　３月１６日（起案日）
手続補正　　　　　　　：平成２８年　７月２０日
　
第２　本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２８年７月２０日付けの手続補正書により補正された特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
（（Ａ）ないし（Ｇ）は当審において付与した。以下「構成要件（Ａ）」等として引用する。）
　
　　【請求項１】
（Ａ）ビデオストリームを第１のデジタルフォーマットから第２のデジタルフォーマットへトランスコードするための装置であって、
（Ｂ）１つ以上の中央処理ユニット（ＣＰＵ）と、
（Ｃ）前記１つ以上のＣＰＵと通信可能に接続された１つ以上のグラフィックス処理ユニット（ＧＰＵ）と、
（Ｄ）前記第１のデジタルフォーマットでエンコードされたビデオストリームを受信し、デコードされたビデオストリームを生成するデコーダであって、前記１つ以上のＧＰＵを利用するＧＰＵハードウエアデコーダと、前記１つ以上のＧＰＵ及び前記１つ以上のＣＰＵを利用するＧＰＵプログラム可能デコーダと、前記１つ以上のＣＰＵを利用するＣＰＵソフトウエアデコーダと、を含むデコーダと、
（Ｅ）前記デコードされたビデオストリームを受信し、前記デコードされたビデオストリームの画像サイズを変更して、スケーリングされデコードされたビデオストリームを生成するスケーラと、
（Ｆ）前記スケーリングされデコードされたビデオストリームを受信し、前記第２のデジタルフォーマットでエンコードされた出力ストリームを生成するエンコーダとを備え、
（Ｇ）前記スケーリングされデコードされたビデオストリームは、前記ＣＰＵ及び前記ＧＰＵの両方に出力される、装置。
　
第３　刊行物の記載事項
（３−１）当審における拒絶の理由の通知において引用された刊行物である国際公開第２００７／１００６１６号（以下「刊行物１」という。）には、図面と共に次に掲げる事項が記載されている。（翻訳は、刊行物１のパテントファミリーである特表２００９−５２７９９１号公報の記載に基づいて合議体が作成した。）
　
（３−１−１）
[0017] Systems and methods for accelerated video encoding provide a video encoding acceleration service. This service allows an arbitrary video encoder application to interface, in a device independent manner, with arbitrary video acceleration hardware to define and implement a substantially optimal video encoding pipeline. To accomplish this, the service exposes video acceleration (VA) application program interfaces (APIs). These APIs encapsulate a model of the video encoding process. To define an encoding pipeline, the video encoder application uses the VA APIs to query implementation specifics (e.g., capabilities, etc.) of available video (graphics) acceleration hardware. The video encoder evaluates these specifics in view of the application's particular video encoding architecture (software-implemented) to identify any encoding operations that could benefit (e.g., speed and/or quality benefits) from being accelerated in hardware. Such operations include, for example, motion estimation, transform, and quantization operations and inverse operations such as Motion compensation, inverse transforms and inverse quantization. The API also allows the video encoder to design an encoding pipeline that substantially minimizes dataflow transitions across buses and processors associated with the host computing device and the acceleration hardware, and thereby, further increase encoding speeds. The API also allows the acceleration hardware to influence the location of the data to improve local caching (e.g. the video acceleration hardware may functional more efficiently on memory local to the video hardware).
　
[0018] Based on these evaluations the video encoder designs a customized video encoding pipeline that performs some number of encoding operations in software and some number of encoding operations using the acceleration hardware (i.e., at least a subset of the operations that could benefit from being hardware accelerated). The encoder application then uses the API to create the pipeline and encode video content. This customized pipeline is substantially optimized as compared to a completely software-implemented pipeline because certain encoding operations are accelerated and data transitions between the host and the acceleration hardware are minimized. Additionally, processing time freed up by accelerating certain aspects of the encoding process and minimizing data transitions allow the host processor(s) to perform higher-quality encoding operations with freed-up processing cycles. The API is also designed to allow components to operate in parallel so that computational resource usage can be maximized.
（訳）
［００１７］
　加速ビデオ符号化のシステム及び方法は、ビデオ符号化加速サービスを提供する。このサービスによって、任意のビデオ符号化アプリケーションが、デバイスに依存しない方法で、任意のビデオ加速ハードウェアとインターフェースして、実質的に最適なビデオ符号化パイプラインを定義して実施することが可能になる。これを実現するために、このサービスは、ビデオ加速（ＶＡ）アプリケーションプログラムインターフェース（ＡＰＩ）を公開する。これらのＡＰＩは、ビデオ符号化プロセスのモデルをカプセル化する。符号化パイプラインを定義するために、ビデオエンコーダアプリケーションは、ＶＡ  ＡＰＩを使用して、利用可能なビデオ（グラフィックス）加速ハードウェアの実施仕様（たとえば、機能等）を問い合わせる。ビデオエンコーダは、ハードウェアで加速されることで利益（たとえば、速度の利益及び／又は品質の利益）を得ることができるあらゆる符号化オペレーションを特定するために、そのアプリケーションの特定のビデオ符号化アーキテクチャ（ソフトウェア実装されたもの）を考慮してこれらの仕様を評価する。このようなオペレーションには、たとえば、動き推定オペレーション、変換オペレーション、量子化オペレーション、及び、動き補償、逆変換、逆量子化等の逆のオペレーションが含まれる。また、ＡＰＩによって、ビデオエンコーダは、ホストコンピューティングデバイス及び加速ハードウェアに関連付けられているバス及びプロセッサにわたるデータフロー移行（dataflow transition）を実質的に最小にする符号化パイプラインを設計することも可能になり、それによって、符号化速度をさらに増加させることが可能になる。また、ＡＰＩによって、加速ハードウェアは、ローカルキャッシュを改善するようにデータのロケーションに影響を与えることも可能になる（たとえば、ビデオ加速ハードウェアは、ビデオハードウェアにローカルなメモリでより効率的に機能することができる）。
［００１８］
　これらの評価に基づいて、ビデオエンコーダは、或る個数の符号化オペレーションをソフトウェアで実行し、或る個数の符号化オペレーション（すなわち、ハードウェアで加速されることで利益を得ることができるオペレーションの少なくともサブセット）を加速ハードウェアを使用して実行する、カスタマイズされたビデオ符号化パイプラインを設計する。エンコーダアプリケーションは、次に、ＡＰＩを使用してパイプラインを作成し、ビデオコンテンツを符号化する。このカスタマイズされたパイプラインは、一定の符号化オペレーションが加速され、ホストと加速ハードウェアとの間のデータ移行が最小にされるので、完全にソフトウェア実装されたパイプラインと比較して実質的に最適化されている。加えて、符号化プロセスの特定の態様を加速化すると共にデータ移行を最小にすることによって解放された処理時間によって、ホストプロセッサ（複数可）は、より高品質な符号化オペレーションを解放された処理サイクルで実行することが可能になる。また、ＡＰＩは、計算資源の使用量を最大にすることができるように、コンポーネントが並列に動作することを可能にするようにも設計される。
　
（３−１−２）
[0021] Fig. 1 shows an exemplary system 100 for accelerated video encoding, according to one embodiment. System 100 includes host computing device 102. Host computing device 102 represents any type of computing device such as a personal computer, a laptop, a server, handheld or mobile computing device, etc. Host computing device 102 includes one or more processihg units 104 coupled across a bus 103 to system memory 106. System memory 106 includes computer-program modules (program modules) 108 and program data 110. A processor 104 fetches and executes computer-program instructions from respective ones of the program modules 108. Program modules 108 include video processing modules 112 for processing video content, and other program modules 114 such as an operating system, device drivers (e.g., for interfacing to video encoding acceleration hardware, etc.), and/or so on. Video processing modules 112 include, for example, video encoder 116, video encoding acceleration service 118, and other processing modules 120, for example, a video decoder, video filter(s), a video renderer, etc.
　
[0022] In this implementation, video encoder 116 is an arbitrary video encoder. This means that the particular architecture, operation, data formats, etc, implemented and/or utilized by video encoder 116 are arbitrary. For example, video encoder 116 may be distributed by a third party, an OEM, etc. Additionally, although Fig. 1 shows video encoding acceleration service 118 independent of the operating system portion of other program modules 114, in one implementation, video encoding acceleration service 118 is part of the operating system.
　
[0023] Video processing modules 112 receive compressed or uncompressed input video data 122. When input video data 122 is compressed (already encoded), video processing modules 112 decode the input video data 122 to produce decoded source video data. Such decoding operations are performs by a decoder module. In another implementation, partially decoded data could also be retained to further assist the encoding process. For purposes of exemplary illustration, such a decoder module is shown as a respective portion of other video processing modules 120. Thus, decoded source video data is represented either by input video data 122 that was received in a decoded state, or represented with results of decoding input video data 122 that was received in an encoded state. Decoded source video data is shown as a respective portion of other program data 124.  
　
[0024] To design and implement a customized video encoding pipeline that can be used to encode decoded source video data into encoded video data 126, video encoder 116 interfaces with video encoding acceleration service 118 via video acceleration (VA) APIs 128. One exemplary implementation of multiple possible implementations of VA APIs 128 is described in the Appendix. To define an encoding pipeline, the video encoder application uses respective ones of the VA API 128 (e.g., please see the Appendix, §3.4, IVideoEncoderService) to obtain implementation specifics of available acceleration hardware 130. 
・・・略・・・
　
[0025] Responsive to receiving such requests from the video encoder 116, video encoding acceleration service 118 queries the video acceleration hardware 130 for the requested implementation specifics and returns information associated with the corresponding responses from the acceleration hardware 130 to the video encoder 116. Video encoding acceleration service 118 interfaces with the video acceleration hardware 130 using a corresponding device driver. Such a device driver is shown as respective portion of other program modules 114.  
　
[0026] Video encoder 116 evaluates the implementation specifics supported by acceleration hardware 130 in view of the application's particular video encoding architecture (software-implemented) to identify any encoding operations that could benefit (e.g., speed and/or quality benefits) from being accelerated in hardware, select a search profile to encapsulate a trade-off between video encoding quality and speed, minimize data transitions across buses and between processors, etc. Exemplary operations that may benefit from hardware acceleration include, for example, motion estimation, transform, and quantization. For example, one reason to perform quantization in hardware is to minimize dataflow between pipeline stages.
　
[0027] Fig. 2 shows an exemplary embodiment of a video encoding pipeline configuration, wherein some of the encoding processes are accelerated in hardware. For purposes of exemplary illustration and description, operations and data flow associated with Fig. 2 are described with respect to particular ones of the components of Fig. 1. In the description, the left-most number of a reference numeral indicates where the particular figure where the component/data path/referenced item was first introduced. For example, the left-most number of pipeline 200 is say 2, indicating that it is first introduced in Fig. 2. In this example, encoding pipeline 200 was configured/customized by video encoder 116 (Fig. 1) interfacing with video encoding service 118 such that respective ones of host 102 implemented processing operations are accelerated in hardware 130. For purposes of illustration, processing-operations illustrated on the right side of the bold dotted line in Fig. 2 are accelerated by hardware (e.g., acceleration hardware 130 of Fig. 1) and processing-operations illustrated on the left side of the figure are performed by the host computing device 102 (Fig. 1). In encoding pipeline 200, optional configured data access pathways are shown with non-bolded dotted lines. Ovals 204 and 212 represent respective original and coded picture memory stores.
　
[0028] In this example implementation, video encoder 116 (Fig. 1) takes as input some form of compressed or uncompressed video data 202 (please also see input video data 122 of Fig. 1). Please note that the exemplary pipeline configuration of Fig. 2 does not copy input source video 202 (raw video source) to the host computing device 102 if the source 202 is not originating from the host 102 and if the host decision making engine (e.g., video encoder 116) does not use the source video. For example, if quantization decisions do not require the host to touch the video data, the data will not be transferred. In this example, pipeline 200 is configured to convert the input data 202 to another compressed form using the respective operations of blocks 206, 208 and 214 through 218.
　
[0029] Such operations may include converting uncompressed (YUV) video data to compressed MPEG-2, or it may include transcoding video data from MPEG-2 data format to WMV data format. For purposes of exemplary illustration, assume that the transcoding operations include a full or partial decompression stage followed by an encode stage (there are more efficient models which by-pass decompression and work purely in the transform (DCT) space). A number of video compression formats make use of motion estimation, transform and quantization to achieve compression. Of the compression stages, motion estimation is typically the slowest step, including a massive search operation where an encoder (e.g., video encoder 116) attempts to find the closest matching reference macroblock for macroblocks in a given image.
　
[0030] Once the optimal motion vectors are determined (e.g., via block 206) for each of the macroblocks, the encoder 116 computes the differential residues (e.g., via block 208) based on the previously coded image and the optimal motion vector. The motion vector, along with the differential residue is a compact representation of the current image. The motion vector data is further represented differentially. The host encoder can optionally request the re-evaluation of motion vectors by the video acceleration hardware to find a macroblock with a smaller combined motion vector and/or residual. The resulting differential motion vector data, and the residual data are compacted (e.g., via block 218), for example, using techniques like run-length encoding (RLE) and differential coding (e.g.: Huffman and Arithmetic coding) to generate the final coded stream of bits (encoded video data 126) to communicate to a destination (block 218) for presentation to a user. In this example, the operations of blocks 206, 208 and 214 through 218 (e.g., operations such as motion estimation (206), mode decision, motion vector (MV) selection and rate control (208), prediction formation (210), transform and quantization operations (214), quantizer inversion and transform and version (216) and entropy coding (218)) are well-known in the art and are thus not described further herein.
　
[0031] Referring again to Fig. 1, in one implementation, video encoder 116 is a multi-threaded application providing for full utilization of acceleration hardware 130. In this implementation, when determining which video encoding operations are to be accelerated in hardware, video encoder 116 may structure the particular pipeline configuration such that both processor 104 and acceleration hardware 130 is fully utilized. For example, when video encoding pipeline motion estimation operations are being performed by hardware for a particular frame of video data, the pipeline may be configured to perform entropy (or arithmetic or Huffman) coding operations in software by the host, on a different frame of video data. An exemplary single motion vector pipeline representing the particular pipeline configuration selected/structured is described below in the Appendix in section 5.1.1. Exemplary multiple motion vector (relatively complex) pipelines wherein video encoder 116 requests multiple motion vectors from acceleration hardware 130 and selects one motion vector pipeline based on various parameters is described below in the Appendix in section 5.1.2.
（訳）
［００２１］
　図１は、一実施形態による加速ビデオ符号化の１つの例示的なシステム１００を示している。システム１００は、ホストコンピューティングデバイス１０２を含む。ホストコンピューティングデバイス１０２は、パーソナルコンピュータ、ラップトップ、サーバ、ハンドヘルドコンピューティングデバイス、モバイルコンピューティングデバイス等の任意のタイプのコンピューティングデバイスを表す。ホストコンピューティングデバイス１０２は、バス１０３を横断してシステムメモリ１０６に結合される１つ又は複数の処理ユニット１０４を含む。システムメモリ１０６は、コンピュータプログラムモジュール（「プログラムモジュール」）１０８及びプログラムデータ１１０を含む。プロセッサ１０４は、プログラムモジュール１０８のそれぞれからコンピュータプログラム命令をフェッチして実行する。プログラムモジュール１０８は、ビデオコンテンツを処理するビデオ処理モジュール１１２、及び、オペレーティングシステム、（たとえば、ビデオ符号化加速ハードウェアにインターフェースするため等の）デバイスドライバ等の他のプログラムモジュール１１４を含む。ビデオ処理モジュール１１２は、たとえば、ビデオエンコーダ１１６、ビデオ符号化加速サービス１１８、及び他の処理モジュール１２０を含む。他の処理モジュール１２０は、たとえば、ビデオデコーダ、ビデオフィルタ（複数可）、ビデオレンダラ等である。
［００２２］
　この実施態様では、ビデオエンコーダ１１６は、任意のビデオエンコーダである。これは、ビデオエンコーダ１１６によって実施され且つ／又は利用される特定のアーキテクチャ、オペレーション、データフォーマット等が任意であることを意味する。たとえば、ビデオエンコーダ１１６は、ＯＥＭ等のサードパーティによって配布される場合がある。加えて、図１は、ビデオ符号化加速サービス１１８が「他のプログラムモジュール」１１４のオペレーティングシステム部分から独立していることを示しているが、一実施態様では、ビデオ符号化加速サービス１１８は、オペレーティングシステムの一部である。
［００２３］
  ビデオ処理モジュール１１２は、圧縮された又は未圧縮の入力ビデオデータ１２２を受け取る。入力ビデオデータ１２２が圧縮（既に符号化）されているとき、ビデオ処理モジュール１１２は、入力ビデオデータ１２２を復号して、復号されたソースビデオデータを生成する。このような復号オペレーションは、デコーダモジュールによって実行される。別の実施態様では、符号化プロセスをさらに援助するために、部分的に復号されたデータを保持することもできる。例示的な説明のために、このようなデコーダモジュールは、「他のビデオ処理モジュール」１２０のそれぞれの部分として示される。したがって、復号されたソースビデオデータは、復号された状態で受け取られた入力ビデオデータ１２２によって表されるか、又は、符号化された状態で受け取られた入力ビデオデータ１２２の復号の結果で表される。復号されたソースビデオデータは、「他のプログラムデータ」１２４のそれぞれの部分として示される。
［００２４］
　復号されたソースビデオデータを符号化して符号化されたビデオデータ１２６にするのに使用することができる、カスタマイズされたビデオ符号化パイプラインを設計して実施するために、ビデオエンコーダ１１６は、ビデオ加速（ＶＡ）ＡＰＩ１２８を介してビデオ符号化加速サービス１１８とインターフェースする。ＶＡ  ＡＰＩ１２８の複数の可能な実施態様のうちの例示的な一実施態様は、付録に記載されている。符号化パイプラインを定義するために、ビデオエンコーダアプリケーションは、ＶＰ  ＡＰＩ１２８（付録の§３．４のIVideoEncoderServiceを参照されたい）のそれぞれを使用して、利用可能な加速ハードウェア１３０の実施仕様を取得する。
・・・略・・・
［００２５］
　ビデオ符号化加速サービス１１８は、このような要求をビデオエンコーダ１１６から受け取ったことに応答して、要求された実施仕様をビデオ加速ハードウェア１３０に問い合わせ、加速ハードウェア１３０からビデオエンコーダ１１６へ、対応する応答に関連付けられる情報を返す。ビデオ符号化加速サービス１１８は、対応するデバイスドライバを使用してビデオ加速ハードウェア１３０とインターフェースする。このようなデバイスドライバは、「他のプログラムモジュール」１１４のそれぞれの部分として示される。
［００２６］
　ビデオエンコーダ１１６は、ハードウェアで加速されることで利益（たとえば、速度の利益及び／又は品質の利益）を得ることができるあらゆる符号化オペレーションを特定し、ビデオ符号化品質と速度との間のトレードオフをカプセル化する検索プロファイルを選択すること、バスにわたるデータ移行及びプロセッサ間のデータ移行を最小にすること等を行うために、アプリケーションの特定のビデオ符号化アーキテクチャ（ソフトウェア実装されたもの）を考慮して、加速ハードウェア１３０によってサポートされる実施仕様を評価する。ハードウェア加速で利益を得ることができる例示的なオペレーションには、たとえば、動き推定、変換、及び量子化が含まれる。たとえば、ハードウェアで量子化を行う１つの理由は、パイプラインステージ間のデータフローを最小にすることである。
［００２７］
　図２は、ビデオ符号化パイプライン構成の１つの例示的な実施形態を示している。符号化プロセスのうちのいくつかは、ハードウェアで加速される。説明及び例示的な説明のために、図２に関連付けられるオペレーション及びデータフローは、図１のコンポーネントの特定のものに関して説明されている。この説明では、参照符号の左端の数字は、コンポーネント／データパス／参照アイテムが最初に紹介された特定の図を示している。たとえば、パイプライン２００の左端の数字は、たとえば「２」であり、パイプライン２００が図２で最初に紹介されていることを示している。この例では、ホスト１０２によって実施される処理オペレーションのそれぞれがハードウェア１３０で加速されるように、符号化パイプライン２００は、ビデオエンコーダ１１６（図１）がビデオ符号化サービス１１８とインターフェースすることによって構成／カスタマイズされている。説明のために、図２の太破線の右側に示す処理オペレーションは、ハードウェア（たとえば、図１の加速ハードウェア１３０）によって加速され、図の左側に示す処理オペレーションは、ホストコンピューティングデバイス１０２（図１）によって実行される。符号化パイプライン２００では、オプションの構成されたデータアクセスパスウェイが、太線でない破線で示される。楕円２０４及び２１２は、それぞれ、元の映像のメモリストア及び符号化された映像のメモリストアを表す。
［００２８］
　この例の実施態様では、ビデオエンコーダ１１６（図１）は、或る形態の圧縮された又は未圧縮のビデオデータ２０２を入力として取り込む（図１の入力ビデオデータ１２２も参照されたい）。ソース２０２が、ホスト１０２を起源とするものではなく、且つ、ホスト意志決定エンジン（たとえば、ビデオエンコーダ１１６）がソースビデオを使用しない場合には、図２の例示的なパイプライン構成は、入力ソースビデオ２０２（「生のビデオソース」）をホストコンピューティングデバイス１０２にコピーしないことに留意されたい。たとえば、量子化決定が、ビデオデータに作用するようにホストに要求しない場合には、そのデータは転送されない。この例では、パイプライン２００は、ブロック２０６、２０８、及び２１４〜２１８のそれぞれのオペレーションを使用して、入力データ２０２を別の圧縮された形態に変換するように構成されている。
［００２９］
　このようなオペレーションは、未圧縮（ＹＵＶ）のビデオデータを圧縮されたＭＰＥＧ−２に変換することを含む場合もあるし、ビデオデータをＭＰＥＧ−２データフォーマットからＷＭＶデータフォーマットにトランスコードすることを含む場合もある。例示的な説明のために、トランスコードオペレーションは、解凍ステージを全体的又は部分的に含み、その後に符号化ステージが続くものと仮定する（解凍を迂回し、純粋に変換（ＤＣＴ）空間で機能する、より効率的なモデルが存在する）。複数のビデオ圧縮フォーマットが、動き推定、変換、及び量子化を活用して、圧縮を達成する。圧縮ステージの場合、動き推定は、通常、最も遅いステップであり、エンコーダ（たとえば、ビデオエンコーダ１１６）が、所与の画像のマクロブロックに関して、最も近似する基準マクロブロックを見つけようと試みる大規模な検索オペレーションを含む。
［００３０］
　マクロブロックのそれぞれに関して最適な動きベクトルが（たとえば、ブロック２０６を介して）求められると、エンコーダ１１６は、事前に符号化された画像及び最適な動きベクトルに基づき（たとえば、ブロック２０８を介して）差分残差（differential residue）を計算する。動きベクトルは、この差分残差と共に、現画像のコンパクトな表現である。動きベクトルデータは、さらに、差分でも表現される。ホストエンコーダは、オプションとして、動きベクトル及び／又は残差のより小さな組み合わせを有するマクロブロックを見つけるために、ビデオ加速ハードウェアによる動きベクトルの再評価を要求することができる。結果の差分動きベクトルデータ及び残差データは、たとえば、ランレングス符号化（ＲＬＥ）及び差分符号化（たとえば、ハフマン符号化及び算術符号化）のような技法を使用して（たとえば、ブロック２１８を介して）コンパクト化され、ユーザに提示するために宛先（ブロック２１８）へ通信する、最終的な符号化されたビットストリーム（符号化されたビデオデータ１２６）が生成される。この例では、ブロック２０６、２０８、及び２１４〜２１８のオペレーション（たとえば、動き推定オペレーション（２０６）、モード決定オペレーション、動きベクトル（ＭＶ）選択オペレーション、及びレート制御オペレーション（２０８）、予測形成（prediction formation）オペレーション（２１０）、変換オペレーション及び量子化オペレーション（２１４）、逆量子化器（quantizer inversion）及び変換及びバージョン（２１６）、並びにエントロピー符号化（２１８））は、当該技術分野で既知であり、本明細書ではこれ以上説明しない。
［００３１］
　図１を再び参照して、一実施態様では、ビデオエンコーダ１１６は、加速ハードウェア１３０の完全利用を可能にするマルチスレッド化されたアプリケーションである。この実施態様では、いずれのビデオ符号化オペレーションをハードウェアで加速するのかを決定するときに、ビデオエンコーダ１１６は、プロセッサ１０４及び加速ハードウェア１３０の双方が完全利用されるように特定のパイプライン構成を構築することができる。たとえば、ビデオ符号化パイプライン動き推定オペレーションが、ビデオデータの特定のフレームに関してハードウェアによって実行されているときに、パイプラインは、ビデオデータの異なるフレームに対してホストによってソフトウェアでエントロピー（又は算術若しくはハフマン）符号化オペレーションを実行するように構成することができる。選択／構築された特定のパイプライン構成を表す１つの例示的な単一の動きベクトルパイプラインが、付録のセクション５．１．１で後述される。ビデオエンコーダ１１６が複数の動きベクトルを加速ハードウェア１３０に要求し、さまざまなパラメータに基づいて１つの動きベクトルパイプラインを選択する例示的な複数の動きベクトル（比較的複雑な）パイプラインは、付録のセクション５．１．２で後述される。
　
（３−１−３）
[0044]・・・略・・・
This Appendix describes aspects of an exemplary implementation of the video encoding acceleration APIs 128 (Fig. 1) for accelerated video encoding, also referred to as VA Encode. In this implementation, APIs 128 are designed to enable encoding and video processing applications (e.g., a video encoder module 1 16) to leverage acceleration hardware 130 (e.g., a GPU) support for accelerating Motion Estimation, Residue Computation, Motion Compensation and Transform.
（訳）
［００４４］
・・・略・・・
　この付録は、ＶＡ符号化とも呼ばれる加速ビデオ符号化用のビデオ符号化加速ＡＰＩ１２８（図１）の１つの例示的な実施態様の複数の態様を記載している。この実施態様では、ＡＰＩ１２８は、符号化アプリケーション及びビデオ処理アプリケーション（たとえば、ビデオエンコーダモジュール１１６）が、Motion Estimation（動き推定）、Residue Computation（残差計算）、Motion Compensation（動き補償）、及びTransform（変換）を加速するための加速ハードウェア１３０（たとえば、ＧＰＵ）のサポートを利用することを可能にするように設計される。
　
第４　刊行物に記載された発明
　以上の記載によれば、刊行物１には次の発明（以下、刊行物１発明という。）が記載されている。
　
（４−１）刊行物１の（３−１−１）の［００１８］の記載によれば、刊行物１に記載された発明は、「加速ビデオ符号化のシステム」に関する発明である。
　上記「加速ビデオ符号化のシステム」について、さらに検討する。
　刊行物１の（３−１−２）の
［００２３］には「ビデオ処理モジュール１１２は、圧縮された又は未圧縮の入力ビデオデータ１２２を受け取る。入力ビデオデータ１２２が圧縮（既に符号化）されているとき、ビデオ処理モジュール１１２は、入力ビデオデータ１２２を復号して、復号されたソースビデオデータを生成する。このような復号オペレーションは、デコーダモジュールによって実行される。別の実施態様では、符号化プロセスをさらに援助するために、部分的に復号されたデータを保持することもできる。例示的な説明のために、このようなデコーダモジュールは、「他のビデオ処理モジュール」１２０のそれぞれの部分として示される。したがって、復号されたソースビデオデータは、復号された状態で受け取られた入力ビデオデータ１２２によって表されるか、又は、符号化された状態で受け取られた入力ビデオデータ１２２の復号の結果で表される。復号されたソースビデオデータは、「他のプログラムデータ」１２４のそれぞれの部分として示される。」との記載があり、
［００２９］には「このようなオペレーションは、未圧縮（ＹＵＶ）のビデオデータを圧縮されたＭＰＥＧ−２に変換することを含む場合もあるし、ビデオデータをＭＰＥＧ−２データフォーマットからＷＭＶデータフォーマットにトランスコードすることを含む場合もある。例示的な説明のために、トランスコードオペレーションは、解凍ステージを全体的又は部分的に含み、その後に符号化ステージが続くものと仮定する（解凍を迂回し、純粋に変換（ＤＣＴ）空間で機能する、より効率的なモデルが存在する）。」との記載がある。
　上記［００２９］の「ビデオデータをＭＰＥＧ−２データフォーマットからＷＭＶデータフォーマットにトランスコードすることを含む場合」は、入力ビデオデータがＭＰＥＧ−２データフォーマットに圧縮（符号化）されている状態であるから、［００２３］の「入力ビデオデータ１２２が圧縮（既に符号化）されているとき」に等しく、このとき、［００２３］の「ビデオ処理モジュール１１２は、入力ビデオデータ１２２を復号して、復号されたソースビデオデータを生成」することは、［００２９］の「解凍ステージ」に相当することも明らかである。
　したがって、刊行物１に記載された「加速ビデオ符号化のシステム」は、ビデオデータをＭＰＥＧ−２データフォーマットからＷＭＶデータフォーマットにトランスコードすることを含んでいるから、「ビデオデータをＭＰＥＧ−２データフォーマットからＷＭＶデータフォーマットにトランスコードする加速ビデオ符号化のシステム」に関する発明であるといえ、この場合、ビデオ処理モジュール１１２は、入力ビデオデータ１２２を復号（デコード）して、復号（デコード）されたソースビデオデータを生成することを含み、その後に符号化（エンコード）ステージが続く構成であることが開示されている。
　
（４−２）刊行物１の（３−１−２）の［００２１］には「システム１００は、ホストコンピューティングデバイス１０２を含む。ホストコンピューティングデバイス１０２は、パーソナルコンピュータ、ラップトップ、サーバ、ハンドヘルドコンピューティングデバイス、モバイルコンピューティングデバイス等の任意のタイプのコンピューティングデバイスを表す。」との記載があり、上記「ホストコンピューティングデバイス１０２」として例示された、「パーソナルコンピュータ、ラップトップ、サーバ、ハンドヘルドコンピューティングデバイス、モバイルコンピューティングデバイス等の任意のタイプのコンピューティングデバイス」は、周知のコンピュータハードウェア（コンピュータ装置）といえるから、刊行物１に記載された「加速ビデオ符号化のシステム」は、（周知の）コンピュータ装置（ホストコンピューティングデバイス１０２）を含むことが開示されている。
　また、刊行物１の（３−１−２）の［００２１］の記載によれば、上記コンピュータ装置（ホストコンピューティングデバイス１０２）は、１つ又は複数の処理ユニット１０４とシステムメモリ１０６とがバス１０３を介して接続されていることが開示されており、図１を参酌すると、上記バス１０３には加速ハードウェア１３０も接続されている。
　上記「１つ又は複数の処理ユニット１０４」について、他の記載では「プロセッサ１０４」との記載もあるから、「１つ又は複数のプロセッサ１０４」と称してもよいことは明らかである。
　また、「加速ハードウェア１３０」は［００４４］の記載によれば「ＧＰＵ」である。
　以上のことから、刊行物１に記載された「加速ビデオ符号化のシステム」は、（周知の）コンピュータ装置を含み、上記コンピュータ装置は、バス１０３で接続された、１つ又は複数のプロセッサ１０４、システムメモリ１０６、加速ハードウェア１３０（ＧＰＵ）を備えていることが開示されている。
　
（４−３）刊行物１の（３−１−２）の［００２１］の記載によれば、刊行物１に記載された「加速ビデオ符号化のシステム」のシステムメモリ１０６は、プロセッサ１０４が実行するプログラムモジュール１０８を含み、上記プログラムモジュール１０８には、「ビデオエンコーダ１１６」、「ビデオ符号化加速サービス１１８」、ビデオデコーダ等を含む「ビデオ処理モジュール１１２」を備えていることが開示されている。
　上記「ビデオエンコーダ１１６」、「ビデオ符号化加速サービス１１８」、「ビデオ処理モジュール１１２」は、プログラムモジュール１０８に備えられているから、「ビデオエンコーダプログラム１１６」、「ビデオ符号化加速サービスプログラム１１８」、「ビデオ処理モジュールプログラム１１２」といえる。
　また、［００２４］−［００２７］には、「ビデオエンコーダ１１６」と「ビデオ符号化加速サービス１１８」との関係は、「ビデオエンコーダ１１６」と「ビデオ符号化加速サービス１１８」とがインターフェースし、符号化プロセスのうちのいくつかを加速ハードウェア１３０によって加速化するよう構成されていることが記載されており、
刊行物１の（３−１−２）の［００３１］には「図１を再び参照して、一実施態様では、ビデオエンコーダ１１６は、加速ハードウェア１３０の完全利用を可能にするマルチスレッド化されたアプリケーションである。この実施態様では、いずれのビデオ符号化オペレーションをハードウェアで加速するのかを決定するときに、ビデオエンコーダ１１６は、プロセッサ１０４及び加速ハードウェア１３０の双方が完全利用されるように特定のパイプライン構成を構築することができる。」の記載がある。
　これらの記載によれば、刊行物１に記載された「加速ビデオ符号化のシステム」では、システムメモリ１０６に、プロセッサ１０４が実行するプログラムモジュール１０８として、「ビデオエンコーダプログラム１１６」、「ビデオ符号化加速サービスプログラム１１８」、「ビデオ処理モジュールプログラム１１２」が備えられ、「ビデオエンコーダプログラム１１６」、「ビデオ符号化加速サービスプログラム１１８」とがインターフェースし、プロセッサ１０４及び加速ハードウェア１３０の双方が完全利用されるように特定のパイプライン構成を構築して、符号化プロセスのうちのいくつかを加速ハードウェア１３０によって加速化するよう構成されていることが開示されている。
　
（４−４）まとめ
　以上の検討において、（４−３）の『「ビデオエンコーダプログラム１１６」、「ビデオ符号化加速サービスプログラム１１８」とがインターフェースし、プロセッサ１０４及び加速ハードウェア１３０の双方が完全利用されるように特定のパイプライン構成を構築して、符号化プロセスのうちのいくつかを加速ハードウェア１３０によって加速化する』の構成は、符号化（エンコード）プロセスに係るものであるから、（４−１）の「入力ビデオデータ１２２を復号（デコード）して、復号（デコード）されたソースビデオデータを生成することを含み、その後に符号化（エンコード）ステージが続く構成であることが開示されている。」の符号化（エンコード）ステージのことであることは明らかである。
　してみると、刊行物１発明として、以下のとおりのものを認定することができる。（（ａ）ないし（ｅ）は当審において付与し、以下「構成要件（ａ）」等として引用する。）
　
（ａ）「ビデオデータをＭＰＥＧ−２データフォーマットからＷＭＶデータフォーマットにトランスコードする加速ビデオ符号化のシステム」に関する発明であって、
（ｂ）（周知の）コンピュータ装置を含み、上記コンピュータ装置は、バス１０３で接続された、１つ又は複数のプロセッサ１０４、システムメモリ１０６、加速ハードウェア１３０（ＧＰＵ）を備え、
（ｃ）システムメモリ１０６は、プロセッサ１０４が実行するプログラムモジュール１０８として、「ビデオエンコーダプログラム１１６」、「ビデオ符号化加速サービスプログラム１１８」、「ビデオ処理モジュールプログラム１１２」を備え、
（ｄ）ビデオ処理モジュールプログラム１１２は、入力ビデオデータ１２２をデコードして、デコードされたソースビデオデータを生成し、
（ｅ）デコードされたソースビデオデータをエンコードする処理では、「ビデオエンコーダプログラム１１６」、「ビデオ符号化加速サービスプログラム１１８」とがインターフェースし、プロセッサ１０４及び加速ハードウェア１３０の双方が完全利用されるように特定のパイプライン構成を構築して、符号化プロセスのうちのいくつかを加速ハードウェア１３０によって加速化する加速ビデオ符号化のシステム。
　
第５　対比
　本願発明と刊行物１発明とを対比する。
　
（５−１）本願発明の構成要件（Ａ）と刊行物１発明の構成要件（ａ）とを対比する。
　刊行物１発明の加速ビデオ符号化のシステムにおける、「ＭＰＥＧ−２データフォーマット」、「ＷＭＶデータフォーマット」は、デジタルビデオデータのフォーマットであるから「第１のデジタルフォーマット」、「第２のデジタルフォーマット」と称してもよいことは明らかである。
　刊行物１発明のビデオデータは、ビデオストリームのデータであるから、「ビデオデータをＭＰＥＧ−２データフォーマットからＷＭＶデータフォーマットにトランスコードすることを含」む「加速ビデオ符号化のシステム」は、「ビデオストリームを第１のデジタルフォーマットから第２のデジタルフォーマットへトランスコードするための装置」である点で、本願発明の構成要件（Ａ）と相違がない。
　
（５−２）本願発明の構成要件（Ｂ）、（Ｃ）と刊行物１発明の構成要件（ｂ）とを対比する。
　刊行物１発明の「１つ又は複数のプロセッサ１０４」は、（周知の）コンピュータ装置に含まれるプロセッサであって、構成要件（ｃ）にあるように、システムメモリ１０６に含まれるプログラムモジュールを実行するプロセッサであるから、本願発明の「中央処理ユニット（ＣＰＵ）」といえることは、当業者には明らかである。
　したがって、刊行物１発明は、本願発明の構成要件（Ｂ）を備えている。
　また、刊行物１発明の「加速ハードウェア１３０（ＧＰＵ）」は、構成要件（ｅ）にあるように「プロセッサ１０４及び加速ハードウェア１３０の双方が完全利用されるように特定のパイプライン構成を構築」しているから、「前記１つ以上のＣＰＵと通信可能に接続された」ＧＰＵであるといえる。
　したがって、刊行物１発明は、本願発明の構成要件（Ｃ）を備えている。
　
（５−３）本願発明の構成要件（Ｄ）と刊行物１発明の構成要件（ａ）、（ｄ）とを対比する。
　刊行物１発明の「ビデオデータをＭＰＥＧ−２データフォーマットからＷＭＶデータフォーマットにトランスコードする」の構成では、「ＭＰＥＧ−２データフォーマット」のビデオデータを入力として受け取っていることは明らかであり、「ビデオ処理モジュールプログラム１１２は、入力ビデオデータ１２２をデコードして、デコードされたソースビデオデータを生成」することは、デコード処理であることは技術常識である。
　したがって、刊行物１発明は、「前記第１のデジタルフォーマットでエンコードされたビデオストリームを受信し、デコードされたビデオストリームを生成するデコーダ」を備えているといえる。
　もっとも、刊行物１発明では、本願発明のＧＰＵとＣＰＵを備えてはいるものの、これらをどのように用いて、デコード処理を行っているか特定されていないから、「前記１つ以上のＧＰＵを利用するＧＰＵハードウエアデコーダと、前記１つ以上のＧＰＵ及び前記１つ以上のＣＰＵを利用するＧＰＵプログラム可能デコーダと、前記１つ以上のＣＰＵを利用するＣＰＵソフトウエアデコーダと、を含むデコーダ」を備えていない点で、本願発明と相違する。
　
（５−４）本願発明の構成要件（Ｅ）と刊行物１発明とを対比する。
　刊行物１発明は、「前記デコードされたビデオストリームの画像サイズを変更して、スケーリング」する構成を有していないから、構成要件（Ｅ）を備えていない。
　
（５−５）本願発明の構成要件（Ｆ）と刊行物１発明の構成要件（ｅ）とを対比する。
　刊行物１発明の「デコードされたソースビデオデータをエンコードする処理」により出力されるビデオデータは構成要件（ａ）からみて、「ＷＭＶデータフォーマット」のビデオデータであることは明らかであるから、本願発明の「前記第２のデジタルフォーマットでエンコードされた出力ストリームを生成する」構成に相当する。
　上記処理では、『「ビデオエンコーダプログラム１１６」、「ビデオ符号化加速サービスプログラム１１８」とがインターフェースし、プロセッサ１０４及び加速ハードウェア１３０の双方が完全利用されるように特定のパイプライン構成を構築して、符号化プロセスのうちのいくつかを加速ハードウェア１３０によって加速化する』のであるから、上記ビデオエンコーダプログラム１１６が本願発明のエンコーダに相当するといえる。
　以上まとめると、刊行物１発明は、「デコードされたビデオストリームを受信し、前記第２のデジタルフォーマットでエンコードされた出力ストリームを生成するエンコーダとを備え」ている点で本願発明と相違がない。
　もっとも、上記（５−４）で検討したように、刊行物１発明は、スケーラを有していないから、受信するビデオストリームが「
前記スケーリングされ
　
（５−６）本願発明の構成要件（Ｇ）と刊行物１発明の構成要件（ｂ）、（ｃ）、（ｅ）とを対比する。
　上記（５−５）で検討したように、刊行物１発明では、デコードされたソースビデオデータを受信し、ビデオエンコーダプログラム１１６の処理を、プロセッサ１０４及び加速ハードウェア１３０の双方が完全利用されるように特定のパイプライン構成を構築して行っている。
　したがって、デコードされたビデオストリームは、プロセッサ１０４及び加速ハードウェア１３０の双方に出力されていることは明らかである。
　刊行物１発明の上記「プロセッサ１０４」、「加速ハードウェア１３０」、「加速ビデオ符号化のシステム」は、それぞれ、本願発明の「前記ＣＰＵ」、「前記ＧＰＵ」、「装置」であるから、刊行物１発明は、「デコードされたビデオストリームは、前記ＣＰＵ及び前記ＧＰＵの両方に出力される、装置」の点で、本願発明と相違がない。
　もっとも、上記（５−４）で検討したように、刊行物１発明は、スケーラを有していないから、ビデオストリームが「
前記スケーリングされ
　
（５−７）まとめ（一致点・相違点）
　以上まとめると、本願発明と刊行物１発明とは以下の一致点で一致し相違点で相違する。
　
（一致点）
　ビデオストリームを第１のデジタルフォーマットから第２のデジタルフォーマットへトランスコードするための装置であって、
　１つ以上の中央処理ユニット（ＣＰＵ）と、
　前記１つ以上のＣＰＵと通信可能に接続された１つ以上のグラフィックス処理ユニット（ＧＰＵ）と、
　前記第１のデジタルフォーマットでエンコードされたビデオストリームを受信し、デコードされたビデオストリームを生成するデコーダと、
　前記デコードされたビデオストリームを受信し、前記第２のデジタルフォーマットでエンコードされた出力ストリームを生成するエンコーダとを備え、
　デコードされたビデオストリームは、前記ＣＰＵ及び前記ＧＰＵの両方に出力される、装置。
　
（相違点）
相違点１
刊行物１発明は、「前記１つ以上のＧＰＵを利用するＧＰＵハードウエアデコーダと、前記１つ以上のＧＰＵ及び前記１つ以上のＣＰＵを利用するＧＰＵプログラム可能デコーダと、前記１つ以上のＣＰＵを利用するＣＰＵソフトウエアデコーダと、を含むデコーダ」を備えていない点
　
相違点２
刊行物１発明は、「前記デコードされたビデオストリームを受信し、前記デコードされたビデオストリームの画像サイズを変更して、スケーリングされデコードされたビデオストリームを生成するスケーラ」を備えていない点。
　
第６　判断
　上記相違点について検討する。
　
（６−１）相違点１について
　相違点１は、結局、デコーダについて、本願発明では、ＧＰＵのみでデコード処理を行う「ＧＰＵハードウエアデコーダ」、ＧＰＵとＣＰＵを共に利用してデコード処理を行う「ＧＰＵプログラム可能デコーダ」、ＣＰＵのみでデコード処理を行う「ＣＰＵソフトウエアデコーダ」を備えているのに対し、刊行物１発明では、「ＧＰＵ」と「ＣＰＵ」とを備え、「ビデオデコーダ」のプログラムを、上記「ＧＰＵ」、「ＣＰＵ」に処理させて、デコード処理を行っているものの、上記デコード処理において、i）「ＧＰＵ」のみに処理をさせるのか、ii）「ＣＰＵ」のみに処理をさせるのか、iii）「ＧＰＵ」と「ＣＰＵ」とを組み合わせて処理させるのか特定されていない点で相違するというものである。
　この点、「ＧＰＵ」と「ＣＰＵ」を備え、「ＧＰＵ」と「ＣＰＵ」とを組み合わせ、デコード処理を適宜負担させる構成は、当審が平成２８年３月１６日付けで通知した、拒絶理由通知書にて提示した引用文献３（以下の検討参照）、引用文献４（【００２０】等）、引用文献５（【０２６５】−【０３４４】等）にあるとおり、本願出願前周知の事項であるといえ、また、「ＧＰＵ」と「ＣＰＵ」を備え、「ＧＰＵ」と「ＣＰＵ」とを適宜組み合わせる構成としては、i）「ＧＰＵ」のみに処理をさせる、ii）「ＣＰＵ」のみに処理をさせる、iii）「ＧＰＵ」と「ＣＰＵ」とを組み合わせて処理させるの、いずれかの組み合わせがあることは当業者には普通に想定できることである。
　そして、例えば、上記引用文献３（特開２００８−２５２８１８号公報）には、【００４４】に
「混合レベル０：全てのピクチャをＧＰＵ１１７で復号化を行う
  混合レベル１：ＩピクチャをＣＰＵ１１１で復号化し、Ｐ、ＢピクチャをＧＰＵ１１７で復号化する。
  混合レベル２：Ｉ、ＰピクチャをＣＰＵ１１１で復号化し、ＢピクチャをＧＰＵ１１７で復号化する。」
のように
「全てのピクチャをＧＰＵ１１７で復号化を行う」すなわち、「前記１つ以上のＧＰＵを利用するＧＰＵハードウエアデコーダ」の構成（上記iの場合）と、
ＣＰＵ１１１とＧＰＵ１１７とを組み合わせて復号化を行う、すなわち、「前記１つ以上のＧＰＵ及び前記１つ以上のＣＰＵを利用するＧＰＵプログラム可能デコーダ」（上記iiiの場合）とが開示されている。
　また、同公報の【００３３】には
「Ｈ．２６４コーデックはＭＰＥＧ−２等の従来のコーデックと比べて処理量が多い。そのためコンピュータ１０でＨ．２６４動画像符号列２５１をデコードする場合は、ＧＰＵ１１７を利用してデコードする方が一般的である。
しかしながら、ＧＰＵ１１７での処理内容にも得手不得手があり、ＧＰＵ１１７よりもＣＰＵ１１１で処理した方が速いケースもある。
との記載があることからみて、ＣＰＵで処理した方が早いケースでは、当然ＣＰＵを用いて全てのデコードを行うことも予測されるから、「前記１つ以上のＣＰＵを利用するＣＰＵソフトウエアデコーダ」（上記iiの場合）もケースによっては存在することは、当業者であれば、容易に想起できたことである。
　したがって、刊行物１発明に、「ＧＰＵ」と「ＣＰＵ」とを備え、「ビデオデコーダ」のプログラムを、上記「ＧＰＵ」、「ＣＰＵ」に処理させて、デコード処理を行っていることが開示されているのであるから、その組み合わせとして、上記相違点１の構成を採用することは、当業者が容易になしえたことである。
　
（６−２）相違点２について
　トランスコードを行うとき、符号化されたデジタルフォーマットのビデオストリームを復号化し、上記復号化したビデオストリームの画像サイズを変更してスケーリングを行い、再符号化（エンコード）することは、当審が平成２８年３月１６日付けで通知した、拒絶理由通知書にて提示した引用文献２（段落［００７４］−［００７８］、図１２）にあるように普通のことであり、刊行物１発明に、上記相違点２の構成を採用することは当業者が適宜なしえたことである。
　
　したがって、上記各相違点は、当業者が容易に想到し得たものと認められ、本願発明全体としてみても格別のものはなく、その作用効果も、上記各相違点に係る構成の採用に伴って当然に予測される程度のものにすぎず、格別顕著なものがあるとは認められない。
　
第８　むすび
　以上のとおり、本願発明は、刊行物１ないし刊行物５に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、残る請求項２ないし請求項１９に係る発明について検討するまでもなく、本願は拒絶すべきものである。
　よって、結論のとおり審決する。