【事件の表示】
　特願２０１７−　１１９５２「ストリーミングされたバーコードを使用したデータ交換」拒絶査定不服審判事件〔平成２９年　７月２０日出願公開，特開２０１７−１２６３４３〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
第１　手続の経緯
　本願は，２０１３年９月２日（パリ条約による優先権主張外国庁受理２０１２年９月２１日（以下，「優先日」という。），アメリカ合衆国）を国際出願日とする出願である特願２０１５−５３２５２０号（以下，「原出願」という。）の一部を平成２９年１月２６日に新たな特許出願としたものであって，その手続の経緯は以下のとおりである。
　平成２９年　５月２５日　　：手続補正書の提出
　平成２９年　９月　８日付け：拒絶理由通知書
　平成２９年１２月１２日　　：意見書の提出
　平成２９年１２月２０日付け：拒絶査定（原査定）
　平成３０年　４月２６日　　：審判請求書，手続補正書の提出
第２　平成３０年４月２６日にされた手続補正についての補正の却下の決定
［補正の却下の決定の結論］
　平成３０年４月２６日にされた手続補正（以下，「本件補正」という。）を却下する。
［理由］
１　本件補正について（補正の内容）
（１）本件補正後の特許請求の範囲の記載
　本件補正により，特許請求の範囲の請求項１の記載は，次のとおり補正された（下線部は，補正箇所である。）。
「　データを符号化するための方法であって，
　前記データを複数の部分へと分割するステップと，
　各部分を別個のバーコード・フレームとして符号化することで，バーコード・フレームのシリーズを提供するステップと，
　前記バーコード・フレームのシリーズにおいて，前記データ
全体
を含み，
　前記特性は，前記バーコード・フレームのシリーズに含まれる各バーコード・フレームを，該バーコード・フレームのシリーズを提供する装置上で逐次的に表示するために用いられる速度を示すフレーム・レートを含む，方法。」
（２）本件補正前の特許請求の範囲
　本件補正前の，平成２９年５月２５日の手続補正により補正された特許請求の範囲の請求項１の記載は次のとおりである。
「　データを符号化するための方法であって，
　前記データを複数の部分へと分割するステップと，
　各部分を別個のバーコード・フレームとして符号化することで，バーコード・フレームのシリーズを提供するステップと，
　前記バーコード・フレームのシリーズにおいて，前記データの特性を示す第１のバーコード・フレームを提供するステップと，
を含み，
　前記特性は，前記バーコード・フレームのシリーズに含まれる各バーコード・フレームを，該バーコード・フレームのシリーズを提供する装置上で逐次的に表示するために用いられる速度を示すフレーム・レートを含む，方法。」
２　補正の適否
　本件補正は，本件補正前の請求項１に記載された発明を特定するために必要な事項である「データの特性」について，上記のとおり限定を付加するものであって，補正前の請求項１に記載された発明と補正後の請求項１に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるから，特許法第１７条の２第５項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで，本件補正後の請求項１に記載される発明（以下，「本件補正発明」という。）が同条第６項において準用する同法第１２６条第７項の規定に適合するか（特許出願の際独立して特許を受けることができるものであるか）について，以下に検討する。
（１）本件補正発明
　本件補正発明は，上記１（１）に記載したとおりのものである。
（２）引用文献の記載事項
ア　引用文献１
（ア）原査定の拒絶の理由で引用された原出願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である，米国特許出願公開第２０１０／００２０９７０号明細書（２０１０年１月２８日出願公開。以下，「引用文献１」という。）には，図面とともに，次の記載がある（当審注：下線は重要箇所に対して当審が付与した。）。
「[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.
[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.
our design for the frame of a VCode is a rectangle to have a similar aspect ratio to the captured image
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. 
B. VCode Acquisition 
[0068] 
The acquisition size and frame rate are constrained by the device. The process, however, must optimize throughput by trading off
processing requirements
Ideally we would choose the highest resolution which remains robust to degradation, yet can be processed at frame rates.
（当審仮訳： 
[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するマスクを使用する。マスクについての予備知識が無ければ復号はほとんど不可能なので，マスクはデータの暗号手段となる。これにより，データは“パスコード”を持っているユーザーによってのみダウンロードできる。典型的なマスクが図７ｂに示される。
B. VCode取得
[0068]　
取得サイズ及びフレームレートは，装置に制約される。しかしながら，処理は，
処理要件をトレードオフすることにより，スループットを最適化しなければならない。劣化に対してロバストであり続け，かつフレームレートで処理を行うことができる最高解像度を選択するのが理想的である。
 　 
「[0092] 
The “V-Code” is designed to work in three modes:
(1) 
The Static Mode
(2) 
The Handheld Mode
(3) 
The Dock Mode
・・・（中略）・・・ 
[0094] 
For each frame, the first byte indicates its frame type:
 　[0095] 
Type I
 　[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.
[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)
手持ちモード
(3)
ドックモード
・・・（中略）・・・ 
[0094]　
各フレームにおいて，最初のバイトは次のフレームタイプを示す
タイプＩ
 　[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
the frame rate at which the VCode is displayed and subsequently decoded
・・・（中略）・・・ 
[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.
・・・（中略）・・・ 
From Table I, we see that when the animation frame rate is very high (20 fps) or very low (4 fps), the downloading bit rate is low. 
The optimal result is achieved when the animation frame rate is between 6.6 to 10 fps.
（当審仮訳： 
VI．実例 
 　 
[0115]　VCodeの直接的な応用の１つは視覚的通信によってデータをダウンロードすることである。ユーザーの視点からは次の２つのファクターが重要である：データ伝送速度とロバストネス。我々の実験はこれら２つのファクターの性能を評価する。 
 　 
Ａ.　データ伝送速度 
 　 
[0116]　
データ伝送速度に直接影響する要因は，
VCodeが表示されそれに引き続いて復号されるフレームレートである
・・・（中略）・・・ 
[0124]　2)
表示フレームレート
一般的に表示フレームレートはフレームがカメラ付き電話によりどれだけ素早くキャプチャーされ処理されるかに依存するので，これはデバイス依存である。カメラ付き電話は幾何学的修正，復号，誤り訂正を実行するために充分な時間が必要なため，フレームは余りに素早く表示されるべきではない。しかしながら，もしも，あまりにゆっくりと表示されれば，カメラ付き電話は同じフレームを何度も処理しなければならない。重複したデータは特定され除去されるけれども，再復号は全体的なビットレートを下げる。理想的な状況は，カメラ付き電話が各フレームを厳密に１度だけ処理することである。
・・・（中略）・・・
表１から，アニメーションレートが非常に高い（20fps）または非常に低い（4fps）ときはダウンロードのビットレートは低いことがわかる。
アニメーションレートが6.6から10fpsのときに，最適な結果が得られた。
（イ）上記記載から，引用文献１には，次の技術的事項が記載されているものと認められる。
ａ　VCode符号化方法は，ＱＲコードやDataMatrixなどの既存の２Ｄバーコードを使うのではなく，独自のコードを用いたデータ転送の技術に関するものである（[0066]）。
ｂ　転送されるデータは，フレーム内及びフレーム間誤り訂正ビットが簡単に挿入され得るように分割されるものであるが，データはまず複数のチャンクに分割され，各チャンクは個々のフレームにさらに分割される（[0056]）。
ｃ　独自のコードは，キャプチャーされた画像と同様のアスペクト比を持つ長方形であり，データ領域は白及び黒のセルから成り，各々が１ビットのデータを表し，黒が１，白が０を表す２次元の画像コードを含むものである（[0066]）。
ｄ　VCodeは，静的モード，手持ちモード，ドックモードの３つのモードで働くようデザインされている（[0092]）。
ｅ　フレームは，最初のバイトは，当該フレームがタイプI，タイプII，タイプIIIのいずれのフレームタイプであるかを示す（[0094]）。 
　また，タイプIIは，手持ちモードとドックモードでデータファイルを送信するための唯一のフレームである系列ヘッダーであり，当該フレームはファイル名とサイズを符号化するものである（[0096]）。
　さらに， タイプIIIは，そのオフセットとチャンク長で始まるデータのチャンクを符号化するデータフレームである（[0097]）。
ｆ　符号化器は，データファイルを符号化する際には，そのファイル名とサイズに従った系列ヘッダーフレームを生成し，それからファイルをチャンクに分割してデータフレームを生成するが，キャプチャリング時にデータフレームが無くなる場合に備え，全てのデータフレームを３回反復し，最後に系列ヘッダーとデータフレームとを合わせてフレームの系列にする（[0098]）。
ｇ　フレームレートは，VCodeが表示され，引き続いて復号される速度である（[0116]）。
　また，当該フレームレートは，データ転送速度に直接影響する要因であるが，デバイス依存であり，スループット最適化のために調整されるべきものとされている（[0068]，[0116]，[0124]）。
（ウ）上記（ア），（イ）から，引用文献１には，次の発明（以下，「引用発明」という。）が記載されていると認められる。
「VCode符号化方法であって， 
　データはフレーム内及びフレーム間誤り訂正ビットが簡単に挿入され得るように複数のチャンクに分割され，各チャンクは個々のフレームにさらに分割され， 
　VCodeレンダリングにより各フレーム（誤り訂正フレームを含む）はフラットスクリーンに表示され得る画像に変換され，該画像はＱＲコードやDataMatrixなどの既存の２Ｄバーコードを使うのではなく，独自のコードであり， 
　VCodeは次の３つのモードで働くようデザインされており：(1)静的モード(2)手持ちモード(3)ドックモード， 
　各フレームにおいて，最初のバイトは次のフレームタイプを示し：タイプＩ，タイプII，タイプIII， 
　タイプIIは系列ヘッダーであり，これは手持ちモードとドックモードでデータファイルを送信するための唯一のフレームであり，このフレームはファイル名とサイズを符号化し， 
　タイプIIIはデータフレームであり，このフレームは，そのオフセットとチャンク長で始まるデータのチャンクを符号化し， 
　データファイルを符号化するとき，符号化器はそのファイル名とサイズに従った系列ヘッダーフレームを生成し，それからファイルをチャンクに分割してデータフレームを生成し，キャプチャリング時にデータフレームが無くなる場合に備え，全てのデータフレームは３回反復され，最後に符号化器は系列ヘッダーとデータフレームとを合わせてフレームの系列にし，
　VCodeは，デバイス依存であるフレームレートで表示及び復号され，当該フレームレートは，スループット最適化のために調整されるべきものである，方法。」
イ　引用文献２
（ア）原査定の拒絶の理由で引用された原出願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である，特開２００５−３３８９２２号公報（平成１７年１２月８日出願公開。以下，「引用文献２」という。）には，図面とともに，次の記載がある。
「【０００４】
　しかしながら，上記した特許文献１の技術では，他の情報処理装置との間の情報伝達方式に関し，例えば同文献の図７に示されているような概念的な内容が提案されているにすぎず，具体的な内容は明らかではなかった。このため，
実際に他の情報処理装置と情報伝達を行うに際しては，機器仕様や性能面での互換性が問題となり，必ずしも確実かつ効率的に情報伝達を行うことが可能になるという保証はなかった
・・・（中略）・・・
【０００６】
　本発明はかかる問題点に鑑みてなされたもので，その目的は，
２次元コードの動的表示および検出を通じて，大容量の情報伝達を確実かつ効率的に行う
「【０００７】
　
本発明の通信方法は，動画像の表示が可能な表示画面を有する２つの表示装置の少なくとも一方に，光の受光が可能な受光手段を設け，時間軸に沿って変化する２次元コードである動画２次元コードに関して
送信対象の情報を示す動画２次元コードを生成し，表示画面および受光手段を利用して，生成された動画２次元コードの表示および読み取りを行うことにより，２つの表示装置の間で通信を行うものである。
「【００１２】
　ここで，
「動画２次元コード」とは，時間軸に沿って変化する一連の２次元コードからなるコード情報である
「２次元コード」とは，各時点において静止した内容をもつシンボルであって，所定のフォーマットに従って予めその構成や意味内容が規定されている
「【００１７】
　
処理性能情報がさらに，通信条件としてこれらの情報のうちの少なくとも１つを含むようにした場合には，この通信条件をも考慮して，表示画面，受光手段および動画２次元コードを用いた通信が行われる。
「通信条件」とは，２つの表示装置の間において動画２次元コードを用いた通信を行う際の条件を意味し，
最大送信速度を示す情報
を含むように構成した場合には，それぞれこれらの処理性能情報に対応して，
送信速度
といった条件が決定される。
「【００８２】
　また，図８（Ｂ）に示したように，シンボルＩＤ４３２の値が「１０００ｂ」の場合，このシンボルは，動画２次元コードにおけるスタートシンボル４３５として機能する。また，
シンボルＩＤ４３２の値が「１００１ｂ」〜「１１１１ｂ」の場合，このシンボルは，動画２次元コードにおけるヘッダシンボル４３６として機能し
【００８３】
　このフォーマットＢにおける特徴である，
シンボルＩＤ４３２の値が「１１１１ｂ」の場合，データ領域４３３の内容は初期ネゴシエーション用データとして利用される
・・・（中略）・・・
【００８５】
　
そして，
予約ＩＤ４３８の値が「００００２ｈ」の場合，処理性能情報に基づいて決定されたフォーマットおよび通信条件の決定内容通知を送信することを表す
【００８６】
　なお，
これらの場合における処理性能情報，あるいは決定されたフォーマットおよび通信条件は，
図８（Ｄ）に示した，アスキーコードを用いた初期ネゴシエーション処理用プロトコル４４の形式で送受信されるようになっている。
「【０１５４】
　図１７は，上記のように初期ネゴシエーション処理において使用される，図１の表示装置１および入出力端末２の処理性能情報の一例を表すものである。
この処理性能情報６は，
最大送信速度６２と
を含む。
【０１５６】
　
最大送信速度６２は，その装置が動画２次元コードを用いてコンテンツデータを送信可能な最大速度を表し，図１７に示したように例えば，１２０（シンボル／秒）などとなる。
「【０１５９】
　図１８は，図１の通信システムにおける表示装置１および入出力端末２の間の初期ネゴシエーション処理を表すものである。ここで，
表示装置１が動画２次元コードを用いたコンテンツデータの送信装置側，入出力端末２が動画２次元コードを用いたコンテンツデータの受信装置側であり
処理性能情報は，図１７に示した情報である
・・・（中略）・・・
【０１６５】
　そして
表示装置１は，このフォーマットおよび通信条件の決定内容通知を，入出力端末２へ送信する
【０１６６】
　入出力端末２は，このフォーマットおよび通信条件の決定内容通知を受信し（ステップＳ３０７），どのようなフォーマットおよび通信条件に基づいて受信すればよいかを認識する。
そして表示装置１は，この決定したフォーマットおよび通信条件で，動画２次元コードを用いたデータ転送を開始する
（イ）上記記載から，引用文献２には，次の技術的事項が記載されているものと認められる。
ａ　引用文献２は，２次元コードの動的表示及び検出を通じての情報伝達の技術に関するものである（【０００６】）。
　また，実際に他の情報処理装置と当該情報伝達を行う際に，機器仕様や性能面での互換性の問題のため必ずしも確実かつ効率的に情報伝達を行うことができず（【０００４】），通信条件を含む機器の処理性能情報を考慮して情報伝達を行う必要がある，との課題認識を開示している（【００１７】）。
ｂ　引用文献２に記載の通信方法は，２つの表示装置間で，表示画面及び受光手段を利用して，生成された動画２次元コードの表示及び読み取りを行うことにより通信を行うものである（【０００７】）。
ｃ　動画２次元コードは，時間軸にそって変化する一連の，２次元コードであるシンボルからなるものである（【００１２】）。
ｄ　処理性能情報に含まれる最大送信速度は，装置が動画２次元コードを用いてコンテンツデータを送信可能な最大速度を表すものであり，（シンボル／秒）の単位を用いて表現される（【０１５４】，【０１５６】）。
ｅ　送信側装置である表示装置は，受信側装置である入出力端末へ通信条件の決定内容通知を送信し，当該決定した通信条件で，動画２次元コードを用いたデータ転送を行う（【０１５９】，【０１６５】−【０１６６】）。
　また，当該通信条件の決定内容通知の送信は，ヘッダシンボルを用いて行われる（【００８２】−【００８３】，【００８５】−【００８６】）。
（ウ）上記（ア），（イ）から，引用文献２には，次の発明（以下，「副引用発明」という。）が記載されていると認められる。
「２つの装置間で一連の２次元コードであるシンボルからなる動画２次元コードを通信する方法であって，
　送信側装置の表示画面に順次表示した前記シンボルを受信側装置の受光手段で読み取ることにより当該通信を行い，
　当該順次表示したシンボルの送信に際し，送信側装置から受信側装置へ通信条件をヘッダシンボルを用いて送信し，
　当該通信条件は，（シンボル数／秒）の単位で表現される当該シンボルを送信する速度である最大送信速度を含む，通信方法。」
（３）引用発明との対比
ア　本件補正発明と引用発明とを対比する。
（ア）引用発明の「VCode符号化方法」は，上位概念では「データを符号化するための方法」であるといえることから，本件補正発明とは「データを符号化するための方法」である点で一致する。 
（イ）引用発明では「データはフレーム内及びフレーム間誤り訂正ビットが簡単に挿入され得るように複数のチャンクに分割され，各チャンクは個々のフレームにさらに分割され」るが，該分割された「フレーム」は符号化の単位であり，本件補正発明の「部分」に相当するものであるから，引用発明と本件補正発明とは「前記データを複数の部分へと分割するステップ」を備えている点で共通するといえる。 
（ウ）引用発明の「VCodeレンダリングにより各フレーム（誤り訂正フレームを含む）はフラットスクリーンに表示され得る画像に変換され」る当該「画像」は，「ＱＲコードやDataMatrixなどの既存の２Ｄバーコードを使うのではなく，独自のコードであ」るが，当該「変換され」た「画像」である「独自のコード」は，各（データ）フレーム毎に生成された「別個の」（視覚的）フレームといえるから，本件補正発明の「別個のバーコード・フレーム」とは，「別個のフレーム」である点で共通する。 
　したがって，引用発明と，本件補正発明の「各部分を別個のバーコード・フレームとして符号化することで，バーコード・フレームのシリーズを提供するステップ」とは，後記する点で相違するものの，「各部分を別個のフレームとして符号化することで，フレームのシリーズを提供するステップ」を備える点で共通するといえる。 
（エ）引用発明の「系列ヘッダー」は，データファイルの「ファイル名とサイズを符号化」した「フレーム」であるから，上位概念では当該データファイルに関し「データ全体の特性を示すフレーム」であり，また，データフレームとは異なるフレームであって，データファイルを送信するための唯一のフレームであるといえる。
　よって，引用発明の「系列ヘッダー」と本件補正発明の「第１のバーコード・フレーム」とは，「前記データ全体の特性を示す第１のフレーム」である点で共通する。
（オ）また，引用発明の「系列ヘッダー」は，「データフレームとを合わせてフレームの系列」にされるものである。 
　したがって，引用発明と，本件補正発明の「前記バーコード・フレームのシリーズにおいて，前記データ全体の特性を示す第１のバーコード・フレームを提供するステップ」とは，後記する点で相違するものの，「前記フレームのシリーズにおいて，前記データ全体の特性を示す第１のフレームを提供するステップ」を備える点で共通するといえる。
イ　以上のことから，本件補正発明と引用発明との一致点及び相違点は，次のとおりである。
　【一致点】
「　データを符号化するための方法であって， 
　前記データを複数の部分へと分割するステップと， 
　各部分を別個のフレームとして符号化することで，フレームのシリーズを提供するステップと， 
　前記フレームのシリーズにおいて，前記データ全体の特性を示す第１のフレームを提供するステップと，
　を含む方法。」
【相違点１】
　「フレーム」に関して，本件補正発明では「バーコード・フレーム」であるのに対し，引用発明では「変換され」た「画像」である「独自のコード」である点。
【相違点２】
　本件補正発明の「特性」は，「前記バーコード・フレームのシリーズに含まれる各バーコード・フレームを，該バーコード・フレームのシリーズを提供する装置上で逐次的に表示するために用いられる速度を示すフレーム・レートを含む」のに対し， 引用発明の系列ヘッダーが示す「特性」は，当該フレーム・レートを含まない点。
（４）判断
　以下，上記相違点について検討する。
ア　相違点１について
　引用発明の「独自のコード」は，「キャプチャーされた画像と同様のアスペクト比を持つ長方形」であるが，「データ領域は白及び黒のセルから成り，各々が１ビットのデータを表し，黒が１，白が０を表す」２次元の画像コードであるから，当該技術分野においては，２次元バーコードと呼ぶことができるものである。 
　したがって，上記【相違点１】は実質的な相違点ではない。
イ　相違点２について
　副引用発明の「最大送信速度」は，動画２次元コードを構成する一連の２次元コードであるシンボルを送信側装置から受信側装置へ送信する速度であり，また，当該送信は，送信側装置において複数のシンボルを順次表示することで行われるものであるから，本件補正発明の「フレーム・レート」に相当する。
　そして，当該「最大送信速度」は「ヘッダシンボル」を用いて送信側装置から受信側装置へ送信されるものであるから，当該「ヘッダシンボル」は，本件補正発明の「第１のバーコード・フレーム」に対応するといえる。
　他方，引用発明の系列ヘッダーが示す「特性」には，フレームレートは含まれていないが，前記（２）ア（イ）ｇにおいて検討したとおり，スループットの最適化のためにデバイス依存である当該フレームレートを調整する必要があるとの課題認識は引用文献１に開示されていると解することができる。
　そうすると，引用発明及び副引用発明は，いずれも２次元コードを利用したデータ転送（情報伝達）といった共通の技術分野に属し，また，機器の処理性能情報を考慮して情報伝達を行う必要があるとの共通の課題認識を有するものであるから，引用発明に副引用発明を適用することにより，フレームレート（最大送信速度）を系列ヘッダーに含めて提供するように構成することで，当該系列ヘッダーが示す前記特性が当該フレームレートを含むことになるように構成することは，引用文献１−２に接した当業者であれば容易になし得たものである。
ウ　そして，これらの相違点を総合的に勘案しても，本件補正発明の奏する作用効果は，引用発明及び副引用発明の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
エ　したがって，本件補正発明は，引用発明及び副引用発明に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができないものである。
３　本件補正についてのむすび
　よって，本件補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって，上記補正の却下の決定の結論のとおり決定する。
第３　本願発明について
１　本願発明
　平成３０年４月２６日にされた手続補正は，上記のとおり却下されたので，本願の請求項に係る発明は，平成２９年５月２５日にされた手続補正により補正された特許請求の範囲の請求項１ないし１９に記載された事項により特定されるものであるところ，その請求項１に係る発明（以下，「本願発明」という。）は，その請求項１に記載された事項により特定される，前記第２［理由］１（２）に記載のとおりのものである。
２　原査定の拒絶の理由
　原査定の拒絶の理由は，この出願の請求項１ないし１９に係る発明は，原出願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献１に記載された発明及び引用文献２に記載された技術事項に基づいて，その優先日前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない，というものである。
引用文献１：米国特許出願公開第２０１０／００２０９７０号明細書
引用文献２：特開２００５−３３８９２２号公報
３　引用文献
　原査定の拒絶の理由で引用された引用文献１並びに２及びその記載事項は，前記第２の［理由］２（２）に記載したとおりである。
４　対比・判断
　本願発明は，前記第２の［理由］２で検討した本件補正発明の発明特定事項である「データ全体の特性」から，限定事項である「全体」を削除したものである。
　そうすると，本願発明の発明特定事項を全て含み，さらに他の事項を付加したものに相当する本件補正発明が，前記第２の［理由］２（３），（４）に記載したとおり，引用発明及び副引用発明に基づいて，当業者が容易に発明をすることができたものであるから，本願発明も，引用発明及び副引用発明に基づいて当業者が容易に発明をすることができたものである。
第４　むすび
　以上のとおり，本願発明は，特許法第２９条第２項の規定により特許を受けることができないから，他の請求項に係る発明について検討するまでもなく，本願は拒絶されるべきものである。
　よって，結論のとおり審決する。