• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04N
管理番号 1324155
審判番号 不服2015-4116  
総通号数 207 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-03-31 
種別 拒絶査定不服の審決 
審判請求日 2015-03-02 
確定日 2017-01-18 
事件の表示 特願2011-534905「GPU加速を伴うソフトウエアビデオトランスコーダ」拒絶査定不服審判事件〔平成22年 5月14日国際公開、WO2010/054011、平成24年 4月 5日国内公表、特表2012-508485〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、2009年(平成21年)11月4日(パリ条約による優先権主張外国庁受理2008年11月4日、米国)を国際出願日とする国際特許出願であって、手続の概要は以下のとおりである。

手続補正 :平成24年10月23日
拒絶理由通知 :平成25年11月11日(起案日)
手続補正 :平成26年 3月13日
拒絶理由通知(最後) :平成26年 4月21日(起案日)
手続補正 :平成26年 9月24日
補正却下の決定 :平成26年10月21日
拒絶査定 :平成26年10月21日(起案日)
拒絶査定不服審判請求 :平成27年 3月 2日
手続補正 :平成27年 3月 2日
拒絶理由(当審) :平成28年 3月16日(起案日)
手続補正 :平成28年 7月20日

第2 本願発明
本願の請求項1に係る発明(以下、「本願発明」という。)は、平成28年7月20日付けの手続補正書により補正された特許請求の範囲の請求項1に記載された事項により特定される、以下のとおりのものである。
((A)ないし(G)は当審において付与した。以下「構成要件(A)」等として引用する。)

【請求項1】
(A)ビデオストリームを第1のデジタルフォーマットから第2のデジタルフォーマットへトランスコードするための装置であって、
(B)1つ以上の中央処理ユニット(CPU)と、
(C)前記1つ以上のCPUと通信可能に接続された1つ以上のグラフィックス処理ユニット(GPU)と、
(D)前記第1のデジタルフォーマットでエンコードされたビデオストリームを受信し、デコードされたビデオストリームを生成するデコーダであって、前記1つ以上のGPUを利用するGPUハードウエアデコーダと、前記1つ以上のGPU及び前記1つ以上のCPUを利用するGPUプログラム可能デコーダと、前記1つ以上のCPUを利用するCPUソフトウエアデコーダと、を含むデコーダと、
(E)前記デコードされたビデオストリームを受信し、前記デコードされたビデオストリームの画像サイズを変更して、スケーリングされデコードされたビデオストリームを生成するスケーラと、
(F)前記スケーリングされデコードされたビデオストリームを受信し、前記第2のデジタルフォーマットでエンコードされた出力ストリームを生成するエンコーダとを備え、
(G)前記スケーリングされデコードされたビデオストリームは、前記CPU及び前記GPUの両方に出力される、装置。

第3 刊行物の記載事項
(3-1)当審における拒絶の理由の通知において引用された刊行物である国際公開第2007/100616号(以下「刊行物1」という。)には、図面と共に次に掲げる事項が記載されている。(翻訳は、刊行物1のパテントファミリーである特表2009-527991号公報の記載に基づいて合議体が作成した。)

(3-1-1)
[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.
(訳)
[0017]
加速ビデオ符号化のシステム及び方法は、ビデオ符号化加速サービスを提供する。このサービスによって、任意のビデオ符号化アプリケーションが、デバイスに依存しない方法で、任意のビデオ加速ハードウェアとインターフェースして、実質的に最適なビデオ符号化パイプラインを定義して実施することが可能になる。これを実現するために、このサービスは、ビデオ加速(VA)アプリケーションプログラムインターフェース(API)を公開する。これらのAPIは、ビデオ符号化プロセスのモデルをカプセル化する。符号化パイプラインを定義するために、ビデオエンコーダアプリケーションは、VA APIを使用して、利用可能なビデオ(グラフィックス)加速ハードウェアの実施仕様(たとえば、機能等)を問い合わせる。ビデオエンコーダは、ハードウェアで加速されることで利益(たとえば、速度の利益及び/又は品質の利益)を得ることができるあらゆる符号化オペレーションを特定するために、そのアプリケーションの特定のビデオ符号化アーキテクチャ(ソフトウェア実装されたもの)を考慮してこれらの仕様を評価する。このようなオペレーションには、たとえば、動き推定オペレーション、変換オペレーション、量子化オペレーション、及び、動き補償、逆変換、逆量子化等の逆のオペレーションが含まれる。また、APIによって、ビデオエンコーダは、ホストコンピューティングデバイス及び加速ハードウェアに関連付けられているバス及びプロセッサにわたるデータフロー移行(dataflow transition)を実質的に最小にする符号化パイプラインを設計することも可能になり、それによって、符号化速度をさらに増加させることが可能になる。また、APIによって、加速ハードウェアは、ローカルキャッシュを改善するようにデータのロケーションに影響を与えることも可能になる(たとえば、ビデオ加速ハードウェアは、ビデオハードウェアにローカルなメモリでより効率的に機能することができる)。
[0018]
これらの評価に基づいて、ビデオエンコーダは、或る個数の符号化オペレーションをソフトウェアで実行し、或る個数の符号化オペレーション(すなわち、ハードウェアで加速されることで利益を得ることができるオペレーションの少なくともサブセット)を加速ハードウェアを使用して実行する、カスタマイズされたビデオ符号化パイプラインを設計する。エンコーダアプリケーションは、次に、APIを使用してパイプラインを作成し、ビデオコンテンツを符号化する。このカスタマイズされたパイプラインは、一定の符号化オペレーションが加速され、ホストと加速ハードウェアとの間のデータ移行が最小にされるので、完全にソフトウェア実装されたパイプラインと比較して実質的に最適化されている。加えて、符号化プロセスの特定の態様を加速化すると共にデータ移行を最小にすることによって解放された処理時間によって、ホストプロセッサ(複数可)は、より高品質な符号化オペレーションを解放された処理サイクルで実行することが可能になる。また、APIは、計算資源の使用量を最大にすることができるように、コンポーネントが並列に動作することを可能にするようにも設計される。

(3-1-2)
[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.
(訳)
[0021]
図1は、一実施形態による加速ビデオ符号化の1つの例示的なシステム100を示している。システム100は、ホストコンピューティングデバイス102を含む。ホストコンピューティングデバイス102は、パーソナルコンピュータ、ラップトップ、サーバ、ハンドヘルドコンピューティングデバイス、モバイルコンピューティングデバイス等の任意のタイプのコンピューティングデバイスを表す。ホストコンピューティングデバイス102は、バス103を横断してシステムメモリ106に結合される1つ又は複数の処理ユニット104を含む。システムメモリ106は、コンピュータプログラムモジュール(「プログラムモジュール」)108及びプログラムデータ110を含む。プロセッサ104は、プログラムモジュール108のそれぞれからコンピュータプログラム命令をフェッチして実行する。プログラムモジュール108は、ビデオコンテンツを処理するビデオ処理モジュール112、及び、オペレーティングシステム、(たとえば、ビデオ符号化加速ハードウェアにインターフェースするため等の)デバイスドライバ等の他のプログラムモジュール114を含む。ビデオ処理モジュール112は、たとえば、ビデオエンコーダ116、ビデオ符号化加速サービス118、及び他の処理モジュール120を含む。他の処理モジュール120は、たとえば、ビデオデコーダ、ビデオフィルタ(複数可)、ビデオレンダラ等である。
[0022]
この実施態様では、ビデオエンコーダ116は、任意のビデオエンコーダである。これは、ビデオエンコーダ116によって実施され且つ/又は利用される特定のアーキテクチャ、オペレーション、データフォーマット等が任意であることを意味する。たとえば、ビデオエンコーダ116は、OEM等のサードパーティによって配布される場合がある。加えて、図1は、ビデオ符号化加速サービス118が「他のプログラムモジュール」114のオペレーティングシステム部分から独立していることを示しているが、一実施態様では、ビデオ符号化加速サービス118は、オペレーティングシステムの一部である。
[0023]
ビデオ処理モジュール112は、圧縮された又は未圧縮の入力ビデオデータ122を受け取る。入力ビデオデータ122が圧縮(既に符号化)されているとき、ビデオ処理モジュール112は、入力ビデオデータ122を復号して、復号されたソースビデオデータを生成する。このような復号オペレーションは、デコーダモジュールによって実行される。別の実施態様では、符号化プロセスをさらに援助するために、部分的に復号されたデータを保持することもできる。例示的な説明のために、このようなデコーダモジュールは、「他のビデオ処理モジュール」120のそれぞれの部分として示される。したがって、復号されたソースビデオデータは、復号された状態で受け取られた入力ビデオデータ122によって表されるか、又は、符号化された状態で受け取られた入力ビデオデータ122の復号の結果で表される。復号されたソースビデオデータは、「他のプログラムデータ」124のそれぞれの部分として示される。
[0024]
復号されたソースビデオデータを符号化して符号化されたビデオデータ126にするのに使用することができる、カスタマイズされたビデオ符号化パイプラインを設計して実施するために、ビデオエンコーダ116は、ビデオ加速(VA)API128を介してビデオ符号化加速サービス118とインターフェースする。VA API128の複数の可能な実施態様のうちの例示的な一実施態様は、付録に記載されている。符号化パイプラインを定義するために、ビデオエンコーダアプリケーションは、VP API128(付録の§3.4のIVideoEncoderServiceを参照されたい)のそれぞれを使用して、利用可能な加速ハードウェア130の実施仕様を取得する。
・・・略・・・
[0025]
ビデオ符号化加速サービス118は、このような要求をビデオエンコーダ116から受け取ったことに応答して、要求された実施仕様をビデオ加速ハードウェア130に問い合わせ、加速ハードウェア130からビデオエンコーダ116へ、対応する応答に関連付けられる情報を返す。ビデオ符号化加速サービス118は、対応するデバイスドライバを使用してビデオ加速ハードウェア130とインターフェースする。このようなデバイスドライバは、「他のプログラムモジュール」114のそれぞれの部分として示される。
[0026]
ビデオエンコーダ116は、ハードウェアで加速されることで利益(たとえば、速度の利益及び/又は品質の利益)を得ることができるあらゆる符号化オペレーションを特定し、ビデオ符号化品質と速度との間のトレードオフをカプセル化する検索プロファイルを選択すること、バスにわたるデータ移行及びプロセッサ間のデータ移行を最小にすること等を行うために、アプリケーションの特定のビデオ符号化アーキテクチャ(ソフトウェア実装されたもの)を考慮して、加速ハードウェア130によってサポートされる実施仕様を評価する。ハードウェア加速で利益を得ることができる例示的なオペレーションには、たとえば、動き推定、変換、及び量子化が含まれる。たとえば、ハードウェアで量子化を行う1つの理由は、パイプラインステージ間のデータフローを最小にすることである。
[0027]
図2は、ビデオ符号化パイプライン構成の1つの例示的な実施形態を示している。符号化プロセスのうちのいくつかは、ハードウェアで加速される。説明及び例示的な説明のために、図2に関連付けられるオペレーション及びデータフローは、図1のコンポーネントの特定のものに関して説明されている。この説明では、参照符号の左端の数字は、コンポーネント/データパス/参照アイテムが最初に紹介された特定の図を示している。たとえば、パイプライン200の左端の数字は、たとえば「2」であり、パイプライン200が図2で最初に紹介されていることを示している。この例では、ホスト102によって実施される処理オペレーションのそれぞれがハードウェア130で加速されるように、符号化パイプライン200は、ビデオエンコーダ116(図1)がビデオ符号化サービス118とインターフェースすることによって構成/カスタマイズされている。説明のために、図2の太破線の右側に示す処理オペレーションは、ハードウェア(たとえば、図1の加速ハードウェア130)によって加速され、図の左側に示す処理オペレーションは、ホストコンピューティングデバイス102(図1)によって実行される。符号化パイプライン200では、オプションの構成されたデータアクセスパスウェイが、太線でない破線で示される。楕円204及び212は、それぞれ、元の映像のメモリストア及び符号化された映像のメモリストアを表す。
[0028]
この例の実施態様では、ビデオエンコーダ116(図1)は、或る形態の圧縮された又は未圧縮のビデオデータ202を入力として取り込む(図1の入力ビデオデータ122も参照されたい)。ソース202が、ホスト102を起源とするものではなく、且つ、ホスト意志決定エンジン(たとえば、ビデオエンコーダ116)がソースビデオを使用しない場合には、図2の例示的なパイプライン構成は、入力ソースビデオ202(「生のビデオソース」)をホストコンピューティングデバイス102にコピーしないことに留意されたい。たとえば、量子化決定が、ビデオデータに作用するようにホストに要求しない場合には、そのデータは転送されない。この例では、パイプライン200は、ブロック206、208、及び214?218のそれぞれのオペレーションを使用して、入力データ202を別の圧縮された形態に変換するように構成されている。
[0029]
このようなオペレーションは、未圧縮(YUV)のビデオデータを圧縮されたMPEG-2に変換することを含む場合もあるし、ビデオデータをMPEG-2データフォーマットからWMVデータフォーマットにトランスコードすることを含む場合もある。例示的な説明のために、トランスコードオペレーションは、解凍ステージを全体的又は部分的に含み、その後に符号化ステージが続くものと仮定する(解凍を迂回し、純粋に変換(DCT)空間で機能する、より効率的なモデルが存在する)。複数のビデオ圧縮フォーマットが、動き推定、変換、及び量子化を活用して、圧縮を達成する。圧縮ステージの場合、動き推定は、通常、最も遅いステップであり、エンコーダ(たとえば、ビデオエンコーダ116)が、所与の画像のマクロブロックに関して、最も近似する基準マクロブロックを見つけようと試みる大規模な検索オペレーションを含む。
[0030]
マクロブロックのそれぞれに関して最適な動きベクトルが(たとえば、ブロック206を介して)求められると、エンコーダ116は、事前に符号化された画像及び最適な動きベクトルに基づき(たとえば、ブロック208を介して)差分残差(differential residue)を計算する。動きベクトルは、この差分残差と共に、現画像のコンパクトな表現である。動きベクトルデータは、さらに、差分でも表現される。ホストエンコーダは、オプションとして、動きベクトル及び/又は残差のより小さな組み合わせを有するマクロブロックを見つけるために、ビデオ加速ハードウェアによる動きベクトルの再評価を要求することができる。結果の差分動きベクトルデータ及び残差データは、たとえば、ランレングス符号化(RLE)及び差分符号化(たとえば、ハフマン符号化及び算術符号化)のような技法を使用して(たとえば、ブロック218を介して)コンパクト化され、ユーザに提示するために宛先(ブロック218)へ通信する、最終的な符号化されたビットストリーム(符号化されたビデオデータ126)が生成される。この例では、ブロック206、208、及び214?218のオペレーション(たとえば、動き推定オペレーション(206)、モード決定オペレーション、動きベクトル(MV)選択オペレーション、及びレート制御オペレーション(208)、予測形成(prediction formation)オペレーション(210)、変換オペレーション及び量子化オペレーション(214)、逆量子化器(quantizer inversion)及び変換及びバージョン(216)、並びにエントロピー符号化(218))は、当該技術分野で既知であり、本明細書ではこれ以上説明しない。
[0031]
図1を再び参照して、一実施態様では、ビデオエンコーダ116は、加速ハードウェア130の完全利用を可能にするマルチスレッド化されたアプリケーションである。この実施態様では、いずれのビデオ符号化オペレーションをハードウェアで加速するのかを決定するときに、ビデオエンコーダ116は、プロセッサ104及び加速ハードウェア130の双方が完全利用されるように特定のパイプライン構成を構築することができる。たとえば、ビデオ符号化パイプライン動き推定オペレーションが、ビデオデータの特定のフレームに関してハードウェアによって実行されているときに、パイプラインは、ビデオデータの異なるフレームに対してホストによってソフトウェアでエントロピー(又は算術若しくはハフマン)符号化オペレーションを実行するように構成することができる。選択/構築された特定のパイプライン構成を表す1つの例示的な単一の動きベクトルパイプラインが、付録のセクション5.1.1で後述される。ビデオエンコーダ116が複数の動きベクトルを加速ハードウェア130に要求し、さまざまなパラメータに基づいて1つの動きベクトルパイプラインを選択する例示的な複数の動きベクトル(比較的複雑な)パイプラインは、付録のセクション5.1.2で後述される。

(3-1-3)
[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.
(訳)
[0044]
・・・略・・・
この付録は、VA符号化とも呼ばれる加速ビデオ符号化用のビデオ符号化加速API128(図1)の1つの例示的な実施態様の複数の態様を記載している。この実施態様では、API128は、符号化アプリケーション及びビデオ処理アプリケーション(たとえば、ビデオエンコーダモジュール116)が、Motion Estimation(動き推定)、Residue Computation(残差計算)、Motion Compensation(動き補償)、及びTransform(変換)を加速するための加速ハードウェア130(たとえば、GPU)のサポートを利用することを可能にするように設計される。

第4 刊行物に記載された発明
以上の記載によれば、刊行物1には次の発明(以下、刊行物1発明という。)が記載されている。

(4-1)刊行物1の(3-1-1)の[0018]の記載によれば、刊行物1に記載された発明は、「加速ビデオ符号化のシステム」に関する発明である。
上記「加速ビデオ符号化のシステム」について、さらに検討する。
刊行物1の(3-1-2)の
[0023]には「ビデオ処理モジュール112は、圧縮された又は未圧縮の入力ビデオデータ122を受け取る。入力ビデオデータ122が圧縮(既に符号化)されているとき、ビデオ処理モジュール112は、入力ビデオデータ122を復号して、復号されたソースビデオデータを生成する。このような復号オペレーションは、デコーダモジュールによって実行される。別の実施態様では、符号化プロセスをさらに援助するために、部分的に復号されたデータを保持することもできる。例示的な説明のために、このようなデコーダモジュールは、「他のビデオ処理モジュール」120のそれぞれの部分として示される。したがって、復号されたソースビデオデータは、復号された状態で受け取られた入力ビデオデータ122によって表されるか、又は、符号化された状態で受け取られた入力ビデオデータ122の復号の結果で表される。復号されたソースビデオデータは、「他のプログラムデータ」124のそれぞれの部分として示される。」との記載があり、
[0029]には「このようなオペレーションは、未圧縮(YUV)のビデオデータを圧縮されたMPEG-2に変換することを含む場合もあるし、ビデオデータをMPEG-2データフォーマットからWMVデータフォーマットにトランスコードすることを含む場合もある。例示的な説明のために、トランスコードオペレーションは、解凍ステージを全体的又は部分的に含み、その後に符号化ステージが続くものと仮定する(解凍を迂回し、純粋に変換(DCT)空間で機能する、より効率的なモデルが存在する)。」との記載がある。
上記[0029]の「ビデオデータをMPEG-2データフォーマットからWMVデータフォーマットにトランスコードすることを含む場合」は、入力ビデオデータがMPEG-2データフォーマットに圧縮(符号化)されている状態であるから、[0023]の「入力ビデオデータ122が圧縮(既に符号化)されているとき」に等しく、このとき、[0023]の「ビデオ処理モジュール112は、入力ビデオデータ122を復号して、復号されたソースビデオデータを生成」することは、[0029]の「解凍ステージ」に相当することも明らかである。
したがって、刊行物1に記載された「加速ビデオ符号化のシステム」は、ビデオデータをMPEG-2データフォーマットからWMVデータフォーマットにトランスコードすることを含んでいるから、「ビデオデータをMPEG-2データフォーマットからWMVデータフォーマットにトランスコードする加速ビデオ符号化のシステム」に関する発明であるといえ、この場合、ビデオ処理モジュール112は、入力ビデオデータ122を復号(デコード)して、復号(デコード)されたソースビデオデータを生成することを含み、その後に符号化(エンコード)ステージが続く構成であることが開示されている。

(4-2)刊行物1の(3-1-2)の[0021]には「システム100は、ホストコンピューティングデバイス102を含む。ホストコンピューティングデバイス102は、パーソナルコンピュータ、ラップトップ、サーバ、ハンドヘルドコンピューティングデバイス、モバイルコンピューティングデバイス等の任意のタイプのコンピューティングデバイスを表す。」との記載があり、上記「ホストコンピューティングデバイス102」として例示された、「パーソナルコンピュータ、ラップトップ、サーバ、ハンドヘルドコンピューティングデバイス、モバイルコンピューティングデバイス等の任意のタイプのコンピューティングデバイス」は、周知のコンピュータハードウェア(コンピュータ装置)といえるから、刊行物1に記載された「加速ビデオ符号化のシステム」は、(周知の)コンピュータ装置(ホストコンピューティングデバイス102)を含むことが開示されている。
また、刊行物1の(3-1-2)の[0021]の記載によれば、上記コンピュータ装置(ホストコンピューティングデバイス102)は、1つ又は複数の処理ユニット104とシステムメモリ106とがバス103を介して接続されていることが開示されており、図1を参酌すると、上記バス103には加速ハードウェア130も接続されている。
上記「1つ又は複数の処理ユニット104」について、他の記載では「プロセッサ104」との記載もあるから、「1つ又は複数のプロセッサ104」と称してもよいことは明らかである。
また、「加速ハードウェア130」は[0044]の記載によれば「GPU」である。
以上のことから、刊行物1に記載された「加速ビデオ符号化のシステム」は、(周知の)コンピュータ装置を含み、上記コンピュータ装置は、バス103で接続された、1つ又は複数のプロセッサ104、システムメモリ106、加速ハードウェア130(GPU)を備えていることが開示されている。

(4-3)刊行物1の(3-1-2)の[0021]の記載によれば、刊行物1に記載された「加速ビデオ符号化のシステム」のシステムメモリ106は、プロセッサ104が実行するプログラムモジュール108を含み、上記プログラムモジュール108には、「ビデオエンコーダ116」、「ビデオ符号化加速サービス118」、ビデオデコーダ等を含む「ビデオ処理モジュール112」を備えていることが開示されている。
上記「ビデオエンコーダ116」、「ビデオ符号化加速サービス118」、「ビデオ処理モジュール112」は、プログラムモジュール108に備えられているから、「ビデオエンコーダプログラム116」、「ビデオ符号化加速サービスプログラム118」、「ビデオ処理モジュールプログラム112」といえる。
また、[0024]-[0027]には、「ビデオエンコーダ116」と「ビデオ符号化加速サービス118」との関係は、「ビデオエンコーダ116」と「ビデオ符号化加速サービス118」とがインターフェースし、符号化プロセスのうちのいくつかを加速ハードウェア130によって加速化するよう構成されていることが記載されており、
刊行物1の(3-1-2)の[0031]には「図1を再び参照して、一実施態様では、ビデオエンコーダ116は、加速ハードウェア130の完全利用を可能にするマルチスレッド化されたアプリケーションである。この実施態様では、いずれのビデオ符号化オペレーションをハードウェアで加速するのかを決定するときに、ビデオエンコーダ116は、プロセッサ104及び加速ハードウェア130の双方が完全利用されるように特定のパイプライン構成を構築することができる。」の記載がある。
これらの記載によれば、刊行物1に記載された「加速ビデオ符号化のシステム」では、システムメモリ106に、プロセッサ104が実行するプログラムモジュール108として、「ビデオエンコーダプログラム116」、「ビデオ符号化加速サービスプログラム118」、「ビデオ処理モジュールプログラム112」が備えられ、「ビデオエンコーダプログラム116」、「ビデオ符号化加速サービスプログラム118」とがインターフェースし、プロセッサ104及び加速ハードウェア130の双方が完全利用されるように特定のパイプライン構成を構築して、符号化プロセスのうちのいくつかを加速ハードウェア130によって加速化するよう構成されていることが開示されている。

(4-4)まとめ
以上の検討において、(4-3)の『「ビデオエンコーダプログラム116」、「ビデオ符号化加速サービスプログラム118」とがインターフェースし、プロセッサ104及び加速ハードウェア130の双方が完全利用されるように特定のパイプライン構成を構築して、符号化プロセスのうちのいくつかを加速ハードウェア130によって加速化する』の構成は、符号化(エンコード)プロセスに係るものであるから、(4-1)の「入力ビデオデータ122を復号(デコード)して、復号(デコード)されたソースビデオデータを生成することを含み、その後に符号化(エンコード)ステージが続く構成であることが開示されている。」の符号化(エンコード)ステージのことであることは明らかである。
してみると、刊行物1発明として、以下のとおりのものを認定することができる。((a)ないし(e)は当審において付与し、以下「構成要件(a)」等として引用する。)

(a)「ビデオデータをMPEG-2データフォーマットからWMVデータフォーマットにトランスコードする加速ビデオ符号化のシステム」に関する発明であって、
(b)(周知の)コンピュータ装置を含み、上記コンピュータ装置は、バス103で接続された、1つ又は複数のプロセッサ104、システムメモリ106、加速ハードウェア130(GPU)を備え、
(c)システムメモリ106は、プロセッサ104が実行するプログラムモジュール108として、「ビデオエンコーダプログラム116」、「ビデオ符号化加速サービスプログラム118」、「ビデオ処理モジュールプログラム112」を備え、
(d)ビデオ処理モジュールプログラム112は、入力ビデオデータ122をデコードして、デコードされたソースビデオデータを生成し、
(e)デコードされたソースビデオデータをエンコードする処理では、「ビデオエンコーダプログラム116」、「ビデオ符号化加速サービスプログラム118」とがインターフェースし、プロセッサ104及び加速ハードウェア130の双方が完全利用されるように特定のパイプライン構成を構築して、符号化プロセスのうちのいくつかを加速ハードウェア130によって加速化する加速ビデオ符号化のシステム。

第5 対比
本願発明と刊行物1発明とを対比する。

(5-1)本願発明の構成要件(A)と刊行物1発明の構成要件(a)とを対比する。
刊行物1発明の加速ビデオ符号化のシステムにおける、「MPEG-2データフォーマット」、「WMVデータフォーマット」は、デジタルビデオデータのフォーマットであるから「第1のデジタルフォーマット」、「第2のデジタルフォーマット」と称してもよいことは明らかである。
刊行物1発明のビデオデータは、ビデオストリームのデータであるから、「ビデオデータをMPEG-2データフォーマットからWMVデータフォーマットにトランスコードすることを含」む「加速ビデオ符号化のシステム」は、「ビデオストリームを第1のデジタルフォーマットから第2のデジタルフォーマットへトランスコードするための装置」である点で、本願発明の構成要件(A)と相違がない。

(5-2)本願発明の構成要件(B)、(C)と刊行物1発明の構成要件(b)とを対比する。
刊行物1発明の「1つ又は複数のプロセッサ104」は、(周知の)コンピュータ装置に含まれるプロセッサであって、構成要件(c)にあるように、システムメモリ106に含まれるプログラムモジュールを実行するプロセッサであるから、本願発明の「中央処理ユニット(CPU)」といえることは、当業者には明らかである。
したがって、刊行物1発明は、本願発明の構成要件(B)を備えている。
また、刊行物1発明の「加速ハードウェア130(GPU)」は、構成要件(e)にあるように「プロセッサ104及び加速ハードウェア130の双方が完全利用されるように特定のパイプライン構成を構築」しているから、「前記1つ以上のCPUと通信可能に接続された」GPUであるといえる。
したがって、刊行物1発明は、本願発明の構成要件(C)を備えている。

(5-3)本願発明の構成要件(D)と刊行物1発明の構成要件(a)、(d)とを対比する。
刊行物1発明の「ビデオデータをMPEG-2データフォーマットからWMVデータフォーマットにトランスコードする」の構成では、「MPEG-2データフォーマット」のビデオデータを入力として受け取っていることは明らかであり、「ビデオ処理モジュールプログラム112は、入力ビデオデータ122をデコードして、デコードされたソースビデオデータを生成」することは、デコード処理であることは技術常識である。
したがって、刊行物1発明は、「前記第1のデジタルフォーマットでエンコードされたビデオストリームを受信し、デコードされたビデオストリームを生成するデコーダ」を備えているといえる。
もっとも、刊行物1発明では、本願発明のGPUとCPUを備えてはいるものの、これらをどのように用いて、デコード処理を行っているか特定されていないから、「前記1つ以上のGPUを利用するGPUハードウエアデコーダと、前記1つ以上のGPU及び前記1つ以上のCPUを利用するGPUプログラム可能デコーダと、前記1つ以上のCPUを利用するCPUソフトウエアデコーダと、を含むデコーダ」を備えていない点で、本願発明と相違する。

(5-4)本願発明の構成要件(E)と刊行物1発明とを対比する。
刊行物1発明は、「前記デコードされたビデオストリームの画像サイズを変更して、スケーリング」する構成を有していないから、構成要件(E)を備えていない。

(5-5)本願発明の構成要件(F)と刊行物1発明の構成要件(e)とを対比する。
刊行物1発明の「デコードされたソースビデオデータをエンコードする処理」により出力されるビデオデータは構成要件(a)からみて、「WMVデータフォーマット」のビデオデータであることは明らかであるから、本願発明の「前記第2のデジタルフォーマットでエンコードされた出力ストリームを生成する」構成に相当する。
上記処理では、『「ビデオエンコーダプログラム116」、「ビデオ符号化加速サービスプログラム118」とがインターフェースし、プロセッサ104及び加速ハードウェア130の双方が完全利用されるように特定のパイプライン構成を構築して、符号化プロセスのうちのいくつかを加速ハードウェア130によって加速化する』のであるから、上記ビデオエンコーダプログラム116が本願発明のエンコーダに相当するといえる。
以上まとめると、刊行物1発明は、「デコードされたビデオストリームを受信し、前記第2のデジタルフォーマットでエンコードされた出力ストリームを生成するエンコーダとを備え」ている点で本願発明と相違がない。
もっとも、上記(5-4)で検討したように、刊行物1発明は、スケーラを有していないから、受信するビデオストリームが「前記スケーリングされデコードされたビデオストリーム」ではない点で相違する。

(5-6)本願発明の構成要件(G)と刊行物1発明の構成要件(b)、(c)、(e)とを対比する。
上記(5-5)で検討したように、刊行物1発明では、デコードされたソースビデオデータを受信し、ビデオエンコーダプログラム116の処理を、プロセッサ104及び加速ハードウェア130の双方が完全利用されるように特定のパイプライン構成を構築して行っている。
したがって、デコードされたビデオストリームは、プロセッサ104及び加速ハードウェア130の双方に出力されていることは明らかである。
刊行物1発明の上記「プロセッサ104」、「加速ハードウェア130」、「加速ビデオ符号化のシステム」は、それぞれ、本願発明の「前記CPU」、「前記GPU」、「装置」であるから、刊行物1発明は、「デコードされたビデオストリームは、前記CPU及び前記GPUの両方に出力される、装置」の点で、本願発明と相違がない。
もっとも、上記(5-4)で検討したように、刊行物1発明は、スケーラを有していないから、ビデオストリームが「前記スケーリングされデコードされたビデオストリーム」ではない点で相違する。

(5-7)まとめ(一致点・相違点)
以上まとめると、本願発明と刊行物1発明とは以下の一致点で一致し相違点で相違する。

(一致点)
ビデオストリームを第1のデジタルフォーマットから第2のデジタルフォーマットへトランスコードするための装置であって、
1つ以上の中央処理ユニット(CPU)と、
前記1つ以上のCPUと通信可能に接続された1つ以上のグラフィックス処理ユニット(GPU)と、
前記第1のデジタルフォーマットでエンコードされたビデオストリームを受信し、デコードされたビデオストリームを生成するデコーダと、
前記デコードされたビデオストリームを受信し、前記第2のデジタルフォーマットでエンコードされた出力ストリームを生成するエンコーダとを備え、
デコードされたビデオストリームは、前記CPU及び前記GPUの両方に出力される、装置。

(相違点)
相違点1
刊行物1発明は、「前記1つ以上のGPUを利用するGPUハードウエアデコーダと、前記1つ以上のGPU及び前記1つ以上のCPUを利用するGPUプログラム可能デコーダと、前記1つ以上のCPUを利用するCPUソフトウエアデコーダと、を含むデコーダ」を備えていない点

相違点2
刊行物1発明は、「前記デコードされたビデオストリームを受信し、前記デコードされたビデオストリームの画像サイズを変更して、スケーリングされデコードされたビデオストリームを生成するスケーラ」を備えていない点。

第6 判断
上記相違点について検討する。

(6-1)相違点1について
相違点1は、結局、デコーダについて、本願発明では、GPUのみでデコード処理を行う「GPUハードウエアデコーダ」、GPUとCPUを共に利用してデコード処理を行う「GPUプログラム可能デコーダ」、CPUのみでデコード処理を行う「CPUソフトウエアデコーダ」を備えているのに対し、刊行物1発明では、「GPU」と「CPU」とを備え、「ビデオデコーダ」のプログラムを、上記「GPU」、「CPU」に処理させて、デコード処理を行っているものの、上記デコード処理において、i)「GPU」のみに処理をさせるのか、ii)「CPU」のみに処理をさせるのか、iii)「GPU」と「CPU」とを組み合わせて処理させるのか特定されていない点で相違するというものである。
この点、「GPU」と「CPU」を備え、「GPU」と「CPU」とを組み合わせ、デコード処理を適宜負担させる構成は、当審が平成28年3月16日付けで通知した、拒絶理由通知書にて提示した引用文献3(以下の検討参照)、引用文献4(【0020】等)、引用文献5(【0265】-【0344】等)にあるとおり、本願出願前周知の事項であるといえ、また、「GPU」と「CPU」を備え、「GPU」と「CPU」とを適宜組み合わせる構成としては、i)「GPU」のみに処理をさせる、ii)「CPU」のみに処理をさせる、iii)「GPU」と「CPU」とを組み合わせて処理させるの、いずれかの組み合わせがあることは当業者には普通に想定できることである。
そして、例えば、上記引用文献3(特開2008-252818号公報)には、【0044】に
「混合レベル0:全てのピクチャをGPU117で復号化を行う
混合レベル1:IピクチャをCPU111で復号化し、P、BピクチャをGPU117で復号化する。
混合レベル2:I、PピクチャをCPU111で復号化し、BピクチャをGPU117で復号化する。」
のように
「全てのピクチャをGPU117で復号化を行う」すなわち、「前記1つ以上のGPUを利用するGPUハードウエアデコーダ」の構成(上記iの場合)と、
CPU111とGPU117とを組み合わせて復号化を行う、すなわち、「前記1つ以上のGPU及び前記1つ以上のCPUを利用するGPUプログラム可能デコーダ」(上記iiiの場合)とが開示されている。
また、同公報の【0033】には
「H.264コーデックはMPEG-2等の従来のコーデックと比べて処理量が多い。そのためコンピュータ10でH.264動画像符号列251をデコードする場合は、GPU117を利用してデコードする方が一般的である。しかしながら、GPU117での処理内容にも得手不得手があり、GPU117よりもCPU111で処理した方が速いケースもある。本実施例では、ピクチャ単位に処理させるプロセッサを適応的に切り換えることにより、復号化処理の遅延発生を抑制する。」
との記載があることからみて、CPUで処理した方が早いケースでは、当然CPUを用いて全てのデコードを行うことも予測されるから、「前記1つ以上のCPUを利用するCPUソフトウエアデコーダ」(上記iiの場合)もケースによっては存在することは、当業者であれば、容易に想起できたことである。
したがって、刊行物1発明に、「GPU」と「CPU」とを備え、「ビデオデコーダ」のプログラムを、上記「GPU」、「CPU」に処理させて、デコード処理を行っていることが開示されているのであるから、その組み合わせとして、上記相違点1の構成を採用することは、当業者が容易になしえたことである。

(6-2)相違点2について
トランスコードを行うとき、符号化されたデジタルフォーマットのビデオストリームを復号化し、上記復号化したビデオストリームの画像サイズを変更してスケーリングを行い、再符号化(エンコード)することは、当審が平成28年3月16日付けで通知した、拒絶理由通知書にて提示した引用文献2(段落[0074]-[0078]、図12)にあるように普通のことであり、刊行物1発明に、上記相違点2の構成を採用することは当業者が適宜なしえたことである。

したがって、上記各相違点は、当業者が容易に想到し得たものと認められ、本願発明全体としてみても格別のものはなく、その作用効果も、上記各相違点に係る構成の採用に伴って当然に予測される程度のものにすぎず、格別顕著なものがあるとは認められない。

第8 むすび
以上のとおり、本願発明は、刊行物1ないし刊行物5に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
したがって、残る請求項2ないし請求項19に係る発明について検討するまでもなく、本願は拒絶すべきものである。
よって、結論のとおり審決する。
 
審理終結日 2016-08-16 
結審通知日 2016-08-23 
審決日 2016-09-05 
出願番号 特願2011-534905(P2011-534905)
審決分類 P 1 8・ 121- WZ (H04N)
最終処分 不成立  
前審関与審査官 岩井 健二  
特許庁審判長 藤井 浩
特許庁審判官 渡邊 聡
清水 正一
発明の名称 GPU加速を伴うソフトウエアビデオトランスコーダ  
代理人 村雨 圭介  
代理人 早川 裕司  
代理人 佐野 良太  

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