2017-001146

特願２０１５－５３２５２０「ストリーミングされたバーコードを使用したデータ交換」拒絶査定不服審判事件〔平成２６年　３月２７日国際公開、ＷＯ２０１４／０４５１０５、平成２７年１１月２６日国内公表、特表２０１５－５３４１８１〕について、次のとおり審決する。

【結　論】 本件審判の請求は、成り立たない。

【理　由】 １　手続の経緯と本願発明 本願は，２０１３年９月２日（パリ条約による優先権主張外国庁受理２０１２年９月２１，アメリカ合衆国）を国際出願日とする出願であって，平成２８年３月２２付けで拒絶理由が通知され，平成２８年５月２５日に意見書と手続補正書が提出されたが，平成２８年９月２６日付けで拒絶査定がなされ，これを不服として，平成２９年１月２６日に拒絶査定に対する審判請求がなされたものであって，本願の請求項１に係る発明（以下，「本願発明」という。）は，平成２８年５月２５日に提出された手続補正書により補正された特許請求の範囲の請求項１に記載された以下のとおりのものと認める。 「　データを符号化するための方法であって， 前記データを複数の部分へと分割するステップと， 各部分を別個のバーコード・フレームとして符号化することで，バーコード・フレームのシリーズを提供するステップと， 前記バーコード・フレームのシリーズにおいて，前記データの特性を示す第１のバーコード・フレームを提供するステップと を含み， 前記特性はフレーム・レートを含む，方法。」 ２　引用発明 原査定の拒絶の理由に引用された米国特許出願公開第２０１０／００２０９７０号明細書（以下，「引用例」という。）には，「System And Method For Camera Imaging Data Channel」（当審仮訳：カメライメージングデータチャネルのためのシステム及び方法）（発明の名称）に関し，図面とともに以下の事項が記載されている（なお，下線は重要箇所に対して当審が付与した。）。 ア 「[0054]　A preferred embodiment of the method of the present invention starts with encoding. A. VCode Encoding [0055] To encode a data file into a VCode, we first split the data file into small segments, and then encode each segment into an image sequence. While the scheme is straightforward, the challenge is to make the encoding robust to the degradation and data loss which are inevitable in the imaging process. The cameras on phones often have much lower quality than digital cameras, and we expect users to capture VCode in real environment without constraints in lighting and perspective angles. Our strategy is to use state of the art error control in both time and space to make code more robust against these types of degradations. [0056] 1)Data Partitioning and Error Correction: The data is partitioned in the way that both intra and inter error correction bits can easily be inserted. We divide the data into multiple chunks, each of which is further divided into individual frames. This forms a three layer structure of the data representation, as shown in FIG. 3 . [0057]　・・・（中略）・・・Specifically, the error correction encoding scheme of a preferred embodiment of the present invention is described as: [0058] 1)Partition data: Split the data into chunks, each of which has the dimension K×W×H, where K is the frame number, W and H are the width and height for each frame. [0059] 2)Correct inter frame errors: Scan each column along the Z (time) axis of the data cube and add error correction bytes for each column scanned. Since we have K data frames in the “Data Cube”. We add (N－K) frames at the end of each chuck as inter frame error correction frames. We then can use a (N, K)-Reed-Solomon code to encode each chunk into an K×W×H cube. These redundancy frames will be dropped if they are not needed. [0060] 3) Correct intra frame errors: We add error correction code by padding extra bits to each frame on the x-y plane. Each frame is extended from size W×H to W×(H＋R). [0061] Each frame consists of three parts: the frame header, the data area and the error correction area. The frame header contains the frame index, chunk index, the total number of chunks, and a checksum. The frame and chunk indexes provide the position of each frame so it can be put into the right position after decoding. The checksum is used to check if the decoded frame and chunk indexes are correct. If they are incorrect, the whole frame will be dropped and recovered later by error correction frames. The number of chunks is uniform on all frames and can be used to check if the file is downloaded completely. We put on every frame so users can begin capturing from any frame (the VCode will be displayed in a loop until all data frames are correctly captured and decoded). ・・・（中略）・・・ [0066] 2) VCode Rendering: The rendering converts each frame (including error correction frames) into an image, which can be displayed on flat screens. Rather than using existing 2D barcode symbologies such as QR codes or Data Matrix (which are inherently static), we designed our own symbology, as shown in FIG. 7 a, to maximize the data capacity. Since the sensors in camera phones are often not square, our design for the frame of a VCode is a rectangle to have a similar aspect ratio to the captured image. As shown in FIG. 7 a, the code area consists of two parts: a rectangle bounding box 710 defining the boundary of the code, a data area 720 and an error correction area 730 . The boundary can be used as the detection pattern and can be efficiently detected using a new fast Hough transform method. The data area consists of black and white cells, each carrying one bit of data with black representing 1 and white representing 0. [0067] Before a frame is rendered, we use a mask to xor each frame. The mask provides encryption to the data since decoding is almost impossible without preknowledge of the mask. This allows the data to be downloaded only by users who have the “passcode”. A typical mask is shown in FIG. 7 b. 」 （当審仮訳： [0054]　本発明の方法の好適な実施例は符号化から始まる。 Ａ．VCode符号化 [0055]　データファイルをVCodeに符号化するために，最初にデータを小さなセグメントに分割し，それから各セグメントをイメージ系列に符号化する。その手法は簡単ではあるものの，課題はイメージ化プロセスにおいて不可避な劣化とデータ損失に対して符号化をロバストなものとすることである。電話のカメラはしばしばデジタルカメラよりもずっと低い品質であり，我々はユーザーが照明や視野角の制限のない現実の環境でVCodeをキャプチャーすることを予期している。我々の戦略はこの種の劣化に対して符号をよりロバストにするために時間と空間における従来の誤り制御を用いることである。 [0056]　1)データ分割と誤り訂正：データはフレーム内及びフレーム間誤り訂正ビットが簡単に挿入され得るように分割される。データを複数のチャンクに分割し，各チャンクは個々のフレームにさらに分割される。これにより図３に示されるように，３層構造のデータ表現が形成される。 [0057]・・・（中略）・・・特に，本発明の好適な実施例の誤り訂正符号化スキームは以下のように表現される： [0058]　1)データの分割：データをチャンクに分割し，各チャンクはK×W×H，ここでKはフレーム数，WとHはそれぞれ各フレームの幅と高さ，のディメンジョンを持つ。 [0059]　2)フレーム間誤りの訂正：データキューブのZ（時間）軸に沿って各列をスキャンし，スキャンした各列毎に誤り訂正バイトを付け加える。“データキューブ”にはＫ個のデータフレームがあるので，各チャンクの最後に(N－K)個のフレームをフレーム間誤り訂正フレームとして付け加える。そうすると，(N, K)-リード-ソロモン符号を使って各チャンクをK×W×Hのキューブに符号化する。これらの冗長フレームは必要がなくなれば捨てられる。 [0060]　3)フレーム内誤りの訂正：x-y平面の各フレームに余分なビットを埋め込んで誤り訂正符号を付加する。各フレームはサイズW×HからW×(H＋R)に拡大される。 [0061]　各フレームは次の３つの部分からなる：フレームヘッダー，データ領域，誤り訂正領域。フレームヘッダーは，フレームインデックス，チャンクインデックス，チャンクの総数，チェックサムを含む。フレームインデックスとチャンクインデックスは各フレームの位置を規定し，復号後に正しい位置に置かれる。チャックサムは復号されたフレームインデックスとチャンクインデックスが正しいかをチェックするために使われる。もしもそれらが正しくなければそのフレームは捨てられ，後に誤り訂正フレームによって回復される。チャンク数は全てのフレームにおいて同一であり，ファイルが完全にダウンロードされたかどうかに使われる。ユーザがどのフレームからキャプチャーし始めても良いように全フレームを表示する（全データフレームが正しくキャプチャーされ復号されるまで，VCodeは繰り返しディスプレイされる。）。 ・・・（中略）・・・ [0066]　2)VCodeレンダリング：このレンダリングにより各フレーム（誤り訂正フレームを含む）はフラットスクリーンに表示され得る画像に変換される。ＱＲコードやDataMatrixなどの既存の２Ｄバーコードを使うのではなく，我々はデータ容量を最大化するために図７ａに示されるような独自のコードをデザインした。カメラ付き電話のセンサーはしばしば正方形ではないので，VCodeのフレームのための我々のデザインはキャプチャーされた画像と同様のアスペクト比を持つ長方形である。図７ａに示されるように，符号領域は次の２つの部分から成る：コードの境界を定義する長方形の境界ボックス７１０，データ領域７２０，誤り訂正領域７３０。境界は検出パターンとして使用されてもよく，新しい高速ハフ変換手法を用いて十分に検出され得る。データ領域は白及び黒のセルから成り，各々が１ビットのデータを表し，黒が１，白が０を表す。 [0067]　フレームが描画される前に，各フレームをXORするマスクを使用する。マスクについての予備知識が無ければ復号はほとんど不可能なので，マスクはデータの暗号手段となる。これにより，データは“パスコード”を持っているユーザーによってのみダウンロードできる。典型的なマスクが図７ｂに示される。） イ　「[0092] The “V-Code” is designed to work in three modes: (1) The Static Mode: This is similar to existing 2D barcode, a short message is encoded in a static image, and the camera phone reads this message when it scans over the code. (2) The Handheld Mode: When downloading more data, the camera phone needs to read a sequence of frames and the user will have to hold the phone facing the visual sequence for a period of time. The user does not have to hold very still, as long as the “V-Code” is in scope; the program will track the “V-Code” automatically. (3) The Dock Mode: Downloading rather long size data. It works when the phone is still and the position of code matrix in the image remains unchanged. In the dock mode, the downloading speed is much faster because no geometrical computation is required after the first frame is located. ・・・（中略）・・・ [0094] For each frame, the first byte indicates its frame type: [0095] Type I - Static Single Frame: the following bytes encode the message body as a null-terminate string. [0096] Type II - Sequence Header: this is a unique frame for sending data file in handheld mode and dock mode. This frame encodes the file name and size. [0097] Type III - Data Frame: this frame encodes a chunk of data beginning with its offset and chunk length. Since each frame carries with its own offset and chunk length, the reading order of the frames has no importance. [0098] When encoding a data file, the encoder generates the sequence header frame according to the file name and size, and then chops the file into chunks and generates data frames for each chunk. In case any of the data frame might be dropped while capturing, all data frames are replicated three times. Finally the encoder puts the sequence header frame together with the data frames into a sequence of frames. [0099] The decoder tries to decode every single frame it #sees# through the camera. To guarantee that the frame is read correctly it will be read twice and only accepted when the two matrices are identical. When reading the matrix, the decoder starts with the first byte, which must be Type I, II or III, to be considered a valid frame. [0100] For Type I, it will decode all other bits in this frame and show it as a popup message. When the decoder sees Type II, which is the sequence header, it allocates the memory according to the file size and gets ready to accept data chunks. For each chunk, a flag is initialized as “incomplete”. When the decoder sees Type III, it first reads its frame offset and if the corresponding chunk is “incomplete” the reader will fill in this chunk and mark it as “complete”. When all chunks are completed the data is dumped to the file system.」 （当審仮訳： [0092]　“VCode”は次の３つのモードで働くようデザインされている。 (1)静的モード：これは既存の２Ｄバーコード同様であり，短いメッセージが静止画に符号化され，カメラ付き電話はそのコードをスキャンしてこのメッセージを読み取る。 (2)手持ちモード：より多くのデータをダウンロードするとき，カメラ付き電話は一連のフレームを読む必要があり，ユーザーは一定時間その視覚的系列に電話を向けて保持しなければならないだろう。“VCode”が視野にある限りユーザーは完全に静止して保持する必要はない；プログラムが“VCode”を自動的に追跡するであろう。 (3)ドックモード：かなり長いデータをダウンロードする際，電話が静止して画像中のコードマトリックスの位置が変わらなければうまくいく。ドックモードでは最初のフレームの位置が特定された後は幾何学的計算は不要なのでダウンロードスピードはずっと速い。 ・・・（中略）・・・ [0094]　各フレームにおいて，最初のバイトは次のフレームタイプを示す： [0095]　タイプＩ　－　静止した１枚のフレーム：それに続くバイトでは，ヌル終端文字列としてメッセージ本文を符号化する。 [0096]　タイプII　－　系列ヘッダー：これは手持ちモードとドックモードでデータファイルを送信するための唯一のフレームである。このフレームはファイル名とサイズを符号化する。 [0097]　タイプIII　－　データフレーム：このフレームは，そのオフセットとチャンク長で始まるデータのチャンクを符号化する。各フレームにはオフセットとチャンク長が付いているので，フレームを読む順序は重要ではない。 [0098]　データファイルを符号化するとき，符号化器はそのファイル名とサイズに従った系列ヘッダーフレームを生成し，それからファイルをチャンクに分割してデータフレームを生成する。キャプチャリング時にデータフレームが無くなる場合に備え，全てのデータフレームは３回反復される。最後に符号化器は系列ヘッダーとデータフレームとを合わせてフレームの系列にする。 [0099]　復号器はカメラを通して“見える”あらゆるフレームを復号しようとする。フレームが正しく読まれたことを保証するためにフレームは２回読まれ，その２つのマトリックスが同一であるときのみ受け入れられる。マトリックスを読む際には，復号器は最初のバイトから始めるが，有効なフレームと考えられるためにはそのバイトはタイプＩ，タイプII，タイプIIIでなければならない。 [0100]　タイプＩの場合，このフレームの他の全てのビットを復号し，それをポップアップメッセージとして示す。復号器が系列ヘッダーであるタイプIIと理解したとき，そのファイルサイズに合わせてメモリを割り当て，データチャンクを受け取る準備をする。各チャンク毎に“不完全”というフラグが立てられる。復号器がタイプIIIと理解したとき，そのフレームオフセットを読み，対応するチャンクが“不完全”であればその読取器はこのチャンクを埋める。全てのチャンクが“完全”になったときデータはファイルシステムへとダンプされる。） ウ　「VI. Examples [0115] One of the direct applications of VCodes is for downloading data through visual communication. From the user's point of view two factors are important: the data transmission speed and robustness. Our experiments evaluate the performance of these two factors. A. Data Transmission Speed [0116] The factors directly affecting the data transmission speed are (1) the amount of data encoded in a frame, and (2) the frame rate at which the VCode is displayed and subsequently decoded. Assume the displayed frame rate is P frames/second and D bits are encoded in each frame, then theoretically the overall bit rate is P×D bits per second (bps). Therefore the increase of P and/or D will lead to higher bit rates. Practically however, it is much more complex. For example, if more bits are encoded in a frame (increasing D), it will increase the barcode density and decrease the resolution of a single cell unit when the image is captured, possibly leading to more decoding errors. If the frames are displayed too quickly (increasing P), the device may not be fast enough to capture and process them resulting in missed frames. The experiments we conduct in the following sections result in a quantitative analysis of these factors. ・・・（中略）・・・ [0124] 2)Display Frame Rate: Generally the display frame rate depends on how quickly a frame can be captured and processed by camera phones, and this is device dependent. A frame can not be displayed too quickly since camera phones need to have enough time to perform geometrical correction, decoding and error correction. If it is displayed too slowly, however, the camera phone will have to process the same frame again and again. Although the duplicate data will be identified and removed, re-decoding decreases the overall bit rate. The ideal situation is that camera phones process every frame exactly once. If a frame is dropped, it can be recovered by error correction or be recaptured in the next round since the VCode is displayed in a loop.」 （当審仮訳： VI．実例 [0115]　VCodeの直接的な応用の１つは視覚的通信によってデータをダウンロードすることである。ユーザーの視点からは次の２つのファクターが重要である：データ伝送速度とロバストネス。我々の実験はこれら２つのファクターの性能を評価する。 Ａ.　データ伝送速度 [0116]　データ伝送速度に直接影響する要因は，(1)１つのフレームに符号化されたデータの量と，(2)VCodeが表示されそれに引き続いて復号されるフレームレートである。表示されるフレームレートがPフレーム／秒であり，各フレームにDビットが符号化されているとすれば，理論的には全体としてのビットレートはP×Dビットパーセカンド（bps）である。従って，Pおよび／またはDの増大はより高いビットレートにつながる。しかしながら，現実はさらにもっと複雑である。例えば，もしももっと多くのビットがフレームに符号化されていれば（Dを増大），バーコード密度が増加し，１つのセル単位の解像度は下がり，画像がキャプチャーされたとき，恐らくは復号エラーにつながるであろう。もしもフレームがあまりに速く表示されれば（Pを増大），装置はそれらをキャプチャーして処理できるほど速くはないかもしれず，フレームを損失する結果となる。次のセクションで実施した実験は，これらのファクターの定量的解析をもたらす。 ・・・（中略）・・・ [0124]　(2)表示フレームレート：一般的に表示フレームレートはフレームがカメラ付き電話によりどれだけ素早くキャプチャーされ処理されるかに依存するので，これはデバイス依存である。カメラ付き電話は幾何学的修正，復号，誤り訂正を実行するために充分な時間必要なため，フレームは余りに素早く表示されるべきではない。しかしながら，もしも，あまりにゆっくりと表示されれば，カメラ付き電話は同じフレームを何度も処理しなければならない。重複したデータは特定され除去されるけれども，再復号は全体的なビットレートを下げる。理想的な状況は，カメラ付き電話が各フレームを厳密に１度だけ処理することである。もしもフレームが失われれば，誤り訂正で回復されるか，あるいは，VCodeは繰り返しディスプレイされるので次のラウンドで再びキャプチャーできる。） 上記引用例の記載及び図面ならびにこの分野における技術常識を考慮すると，引用例には「VCode符号化方法」に関する以下の発明（以下，「引用発明」という。）が記載されているものと認める。 「VCode符号化方法であって， データはフレーム内及びフレーム間誤り訂正ビットが簡単に挿入され得るように複数のチャンクに分割され，各チャンクは個々のフレームにさらに分割され， VCodeレンダリングにより各フレーム（誤り訂正フレームを含む）はフラットスクリーンに表示され得る画像に変換され，該画像はＱＲコードやDataMatrixなどの既存の２Ｄバーコードを使うのではなく，独自のコードであり， VCodeは次の３つのモードで働くようデザインされており：(1)静的モード(2)手持ちモード(3)ドックモード， 各フレームにおいて，最初のバイトは次のフレームタイプを示し：タイプＩ，タイプII，タイプIII， タイプIIは系列ヘッダーであり，これは手持ちモードとドックモードでデータファイルを送信するための唯一のフレームであり，このフレームはファイル名とサイズを符号化し， タイプIIIはデータフレームであり，このフレームは，そのオフセットとチャンク長で始まるデータのチャンクを符号化し， データファイルを符号化するとき，符号化器はそのファイル名とサイズに従った系列ヘッダーフレームを生成し，それからファイルをチャンクに分割してデータフレームを生成し，キャプチャリング時にデータフレームが無くなる場合に備え，全てのデータフレームは３回反復され，最後に符号化器は系列ヘッダーとデータフレームとを合わせてフレームの系列にする，方法。」 ３　対比 本願発明と引用発明とを対比する。 ａ　引用発明の「VCode符号化方法」が「データを符号化するための方法」であることは明らかであって，後述する相違点を除き，本願発明の「データを符号化するための方法」に相当する。 ｂ　引用発明では「データはフレーム内及びフレーム間誤り訂正ビットが簡単に挿入され得るように複数のチャンクに分割され，各チャンクは個々のフレームにさらに分割され」るが，該分割された「フレーム」は本願発明の「部分」に相当するものであり，引用発明は，本願発明の「前記データを複数の部分へと分割するステップ」を備えているといえる。 ｃ　引用発明では「VCodeレンダリングにより各フレーム（誤り訂正フレームを含む）はフラットスクリーンに表示され得る画像に変換され，該画像はＱＲコードやDataMatrixなどの既存の２Ｄバーコードを使うのではなく，独自のコードであ」るが，該「変換され」た「画像」である「独自のコード」は，各（データ）フレーム毎に生成された「別個の」（視覚的）フレームといえるから，本願発明の「別個のバーコード・フレーム」とは，「別個のフレーム」である点で共通する。 したがって，引用発明は，本願発明の「各部分を別個のバーコード・フレームとして符号化することで，バーコード・フレームのシリーズを提供するステップ」とは「各部分を別個のフレームとして符号化することで，フレームのシリーズを提供するステップ」である点で共通するステップを備えているといえる。 ｄ　引用発明の「系列ヘッダー」はデータファイルの「ファイル名とサイズを符号化」した「フレーム」であるから，「データの特性を示すフレーム」であるといえる。そして，該「系列ヘッダー」は「データフレームとを合わせてフレームの系列」にされるものである。 したがって，引用発明は，本願発明の「前記バーコード・フレームのシリーズにおいて，前記データの特性を示す第１のバーコード・フレームを提供するステップ」とは，「前記フレームのシリーズにおいて，前記データの特性を示すフレームを提供するステップ」である点で共通するステップを備えているといえる。 以上をまとめると，本願発明と引用発明は，以下の点で一致ないし相違する。 （一致点） 「　データを符号化するための方法であって， 前記データを複数の部分へと分割するステップと， 各部分を別個のフレームとして符号化することで，フレームのシリーズを提供するステップと， 前記フレームのシリーズにおいて，前記データの特性を示すフレームを提供するステップと を含む方法。」 （相違点１） 一致点の「フレーム」が， 本願発明では「バーコード・フレーム」であるのに対し， 引用発明では「変換され」た「画像」である「独自のコード」である点。 （相違点２） 一致点の「前記データの特性を示すフレーム」が， 本願発明では「第１の」フレームであるのに対し， 引用発明では何番目のフレームかは明らかでない点。 （相違点３） 本願発明では「前記特性はフレーム・レートを含む」のに対し， 引用発明では「前記特性」は「フレーム・レート」を含まない点。 ４　検討 上記各相違点につき検討する。 （相違点１）について 引用発明の「独自のコード」は「キャプチャーされた画像と同様のアスペクト比を持つ長方形」であるが，「データ領域は白及び黒のセルから成り，各々が１ビットのデータを表し，黒が１，白が０を表す」２次元の画像コードであるから，２次元バーコードと呼ぶことができるものである。 したがって，上記（相違点１）は実質的な相違点ではない。 （相違点２）について 引用発明の「系列ヘッダー」に関し，引用例に「復号器が系列ヘッダーであるタイプIIと理解したとき，そのファイルサイズに合わせてメモリを割り当て，データチャンクを受け取る準備をする。」（[0100]）と記載されていることから，受信側において「系列ヘッダー」に含まれた情報（データファイルのサイズ）がデータファイルを受信する前に使用されることがわかる。 そうすると，引用発明において「系列ヘッダー」を「データファイル」よりも先に送った方が良いことは明らかであるから，「系列ヘッダー」を「最初の」フレーム，即ち，「第１の」フレームとすることは，引用例の記載に基づいて当業者が容易に想到し得たものである。 （相違点３）について 上記「（相違点２）について」でも述べたように，引用発明の「系列ヘッダー」に含まれる情報は転送しようとするデータファイルそのものではなく，データファイル転送の際に受信側で使用される情報であって，制御情報といえるものである。 そして，データ転送時の制御情報である「フレームレート」に関し，引用例には「一般的に表示フレームレートはフレームがカメラ付き電話によりどれだけ素早くキャプチャーされ処理されるかに依存するので，これはデバイス依存である。・・・（中略）・・・しかしながら，もしも，あまりにゆっくりと表示されれば，カメラ付き電話は同じフレームを何度も処理しなければならない。重複したデータは特定され除去されるけれども，再復号は全体的なビットレートを下げる。理想的な状況は，カメラ付き電話が各フレームを厳密に１度だけ処理することである。」（[0124]）と記載されているが，これによれば，「フレームレート」はこれにより受信デバイスが同じフレームを処理する回数が定まる制御情報であって，受信デバイスにとって有用な制御情報であることがわかる。 そうすると，引用発明において「ファイル名とサイズ」に加えて「フレームレート」を「系列ヘッダー」に含まれる情報とすることは，引用例１の記載に基づいて当業者が容易に想到し得たものである。 さらに付言するに，バーコード・フレーム系列（シンボル系列）によりデータ転送する前に，送信側（表示装置）から受信側（入出力端末）に送信フレームレート（シンボル数／秒）を通知することは，原査定の拒絶の理由に引用された特開２００５－３３８９２２号公報にも記載されている公知の技術に過ぎない（【図１８】のＳ３０６「フォーマットおよび通信条件の決定内容通知を送信」参照）。 そして，本願発明が奏する効果も引用例から容易に予測出来る範囲内のものである。 ５　むすび 以上のとおり，本願発明は，引用発明及び引用例の記載に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 よって，結論のとおり審決する。