• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない。 G06K
審判 査定不服 2項進歩性 特許、登録しない。 G06K
管理番号 1351053
審判番号 不服2018-5820  
総通号数 234 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-06-28 
種別 拒絶査定不服の審決 
審判請求日 2018-04-26 
確定日 2019-04-24 
事件の表示 特願2017- 11952「ストリーミングされたバーコードを使用したデータ交換」拒絶査定不服審判事件〔平成29年 7月20日出願公開,特開2017-126343〕について,次のとおり審決する。 
結論 本件審判の請求は,成り立たない。 
理由 第1 手続の経緯
本願は,2013年9月2日(パリ条約による優先権主張外国庁受理2012年9月21日(以下,「優先日」という。),アメリカ合衆国)を国際出願日とする出願である特願2015-532520号(以下,「原出願」という。)の一部を平成29年1月26日に新たな特許出願としたものであって,その手続の経緯は以下のとおりである。

平成29年 5月25日 :手続補正書の提出
平成29年 9月 8日付け:拒絶理由通知書
平成29年12月12日 :意見書の提出
平成29年12月20日付け:拒絶査定(原査定)
平成30年 4月26日 :審判請求書,手続補正書の提出


第2 平成30年4月26日にされた手続補正についての補正の却下の決定
[補正の却下の決定の結論]
平成30年4月26日にされた手続補正(以下,「本件補正」という。)を却下する。

[理由]
1 本件補正について(補正の内容)
(1)本件補正後の特許請求の範囲の記載
本件補正により,特許請求の範囲の請求項1の記載は,次のとおり補正された(下線部は,補正箇所である。)。

「 データを符号化するための方法であって,
前記データを複数の部分へと分割するステップと,
各部分を別個のバーコード・フレームとして符号化することで,バーコード・フレームのシリーズを提供するステップと,
前記バーコード・フレームのシリーズにおいて,前記データ全体の特性を示す第1のバーコード・フレームを提供するステップと,
を含み,
前記特性は,前記バーコード・フレームのシリーズに含まれる各バーコード・フレームを,該バーコード・フレームのシリーズを提供する装置上で逐次的に表示するために用いられる速度を示すフレーム・レートを含む,方法。」

(2)本件補正前の特許請求の範囲
本件補正前の,平成29年5月25日の手続補正により補正された特許請求の範囲の請求項1の記載は次のとおりである。

「 データを符号化するための方法であって,
前記データを複数の部分へと分割するステップと,
各部分を別個のバーコード・フレームとして符号化することで,バーコード・フレームのシリーズを提供するステップと,
前記バーコード・フレームのシリーズにおいて,前記データの特性を示す第1のバーコード・フレームを提供するステップと,
を含み,
前記特性は,前記バーコード・フレームのシリーズに含まれる各バーコード・フレームを,該バーコード・フレームのシリーズを提供する装置上で逐次的に表示するために用いられる速度を示すフレーム・レートを含む,方法。」

2 補正の適否
本件補正は,本件補正前の請求項1に記載された発明を特定するために必要な事項である「データの特性」について,上記のとおり限定を付加するものであって,補正前の請求項1に記載された発明と補正後の請求項1に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるから,特許法第17条の2第5項第2号の特許請求の範囲の減縮を目的とするものに該当する。
そこで,本件補正後の請求項1に記載される発明(以下,「本件補正発明」という。)が同条第6項において準用する同法第126条第7項の規定に適合するか(特許出願の際独立して特許を受けることができるものであるか)について,以下に検討する。

(1)本件補正発明
本件補正発明は,上記1(1)に記載したとおりのものである。

(2)引用文献の記載事項
ア 引用文献1
(ア)原査定の拒絶の理由で引用された原出願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である,米国特許出願公開第2010/0020970号明細書(2010年1月28日出願公開。以下,「引用文献1」という。)には,図面とともに,次の記載がある(当審注:下線は重要箇所に対して当審が付与した。)。

「[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.

B. VCode Acquisition

[0068] The acquisition size and frame rate are constrained by the device. The process, however, must optimize throughput by trading off acquisition speed, image resolution, and processing requirements. Ideally we would choose the highest resolution which remains robust to degradation, yet can be processed at frame rates. Although camera phones often allow users to capture images with different resolutions, from 160×120 to 1600×1200 (2M pixels), our initial experiments suggest that QVGA resolution is a balance between speed and image quality for current mid level devices. The acquisition process itself is very simple: Users only need to aim the camera at the VCode to keep the frames at the center of the display. Detection and decoding will occur at frame rate.」
(当審仮訳:
[0054] 本発明の方法の好適な実施例は符号化から始まる。

A.VCode符号化

[0055] データファイルをVCodeに符号化するために,最初にデータを小さなセグメントに分割し,それから各セグメントをイメージ系列に符号化する。その手法は簡単ではあるものの,課題はイメージ化プロセスにおいて不可避な劣化とデータ損失に対して符号化をロバストなものとすることである。電話のカメラはしばしばデジタルカメラよりもずっと低い品質であり,我々はユーザーが照明や視野角の制限のない現実の環境でVCodeをキャプチャーすることを予期している。我々の戦略はこの種の劣化に対して符号をよりロバストにするために時間と空間における従来の誤り制御を用いることである。
[0056] 1)データ分割と誤り訂正:データはフレーム内及びフレーム間誤り訂正ビットが簡単に挿入され得るように分割される。データを複数のチャンクに分割し,各チャンクは個々のフレームにさらに分割される。これにより図3に示されるように,3層構造のデータ表現が形成される。
[0057]・・・(中略)・・・特に,本発明の好適な実施例の誤り訂正符号化スキームは以下のように表現される:
[0058] 1)データの分割:データをチャンクに分割し,各チャンクはK×W×H,ここでKはフレーム数,WとHはそれぞれ各フレームの幅と高さ,のディメンジョンを持つ。
[0059] 2)フレーム間誤りの訂正:データキューブのZ(時間)軸に沿って各列をスキャンし,スキャンした各列毎に誤り訂正バイトを付け加える。“データキューブ”にはK個のデータフレームがあるので,各チャンクの最後に(N-K)個のフレームをフレーム間誤り訂正フレームとして付け加える。そうすると,(N, K)-リード-ソロモン符号を使って各チャンクをK×W×Hのキューブに符号化する。これらの冗長フレームは必要がなくなれば捨てられる。
[0060] 3)フレーム内誤りの訂正:x-y平面の各フレームに余分なビットを埋め込んで誤り訂正符号を付加する。各フレームはサイズW×HからW×(H+R)に拡大される。
[0061] 各フレームは次の3つの部分からなる:フレームヘッダー,データ領域,誤り訂正領域。フレームヘッダーは,フレームインデックス,チャンクインデックス,チャンクの総数,チェックサムを含む。フレームインデックスとチャンクインデックスは各フレームの位置を規定し,復号後に正しい位置に置かれる。チェックサムは復号されたフレームインデックスとチャンクインデックスが正しいかをチェックするために使われる。もしもそれらが正しくなければそのフレームは捨てられ,後に誤り訂正フレームによって回復される。チャンク数は全てのフレームにおいて同一であり,ファイルが完全にダウンロードされたかどうかをチェックするために使われる。ユーザがどのフレームからキャプチャーし始めても良いように全フレームを表示する(全データフレームが正しくキャプチャーされ復号されるまで,VCodeは繰り返しディスプレイされる。)。
・・・(中略)・・・
[0066] 2)VCodeレンダリング:このレンダリングにより各フレーム(誤り訂正フレームを含む)はフラットスクリーンに表示され得る画像に変換される。QRコードやDataMatrixなどの既存の2Dバーコードを使うのではなく,我々はデータ容量を最大化するために図7aに示されるような独自のコードをデザインした。カメラ付き電話のセンサーはしばしば正方形ではないので,VCodeのフレームのための我々のデザインはキャプチャーされた画像と同様のアスペクト比を持つ長方形である。図7aに示されるように,符号領域は次の2つの部分から成る:コードの境界を定義する長方形の境界ボックス710,データ領域720,誤り訂正領域730。境界は検出パターンとして使用されてもよく,新しい高速ハフ変換手法を用いて十分に検出され得る。データ領域は白及び黒のセルから成り,各々が1ビットのデータを表し,黒が1,白が0を表す。
[0067] フレームが描画される前に,各フレームをXORするマスクを使用する。マスクについての予備知識が無ければ復号はほとんど不可能なので,マスクはデータの暗号手段となる。これにより,データは“パスコード”を持っているユーザーによってのみダウンロードできる。典型的なマスクが図7bに示される。

B. VCode取得

[0068] 取得サイズ及びフレームレートは,装置に制約される。しかしながら,処理は,取得速度,画像解像度,及び処理要件をトレードオフすることにより,スループットを最適化しなければならない。劣化に対してロバストであり続け,かつフレームレートで処理を行うことができる最高解像度を選択するのが理想的である。しばしばユーザはカメラ付き電話により異なる解像度,160×120から1600×1200(2M画素)で撮像することができるものの,我々の最初の実験は,現在の中レベルの装置にとっては,QVGA解像度が速度と画質の間の均衡となることを示している。取得処理自体は,非常に簡潔である:ユーザはVCodeにカメラを向けてフレームをディスプレイの中心に保つようにするだけでよい。検出と復号が,フレームレートで起こることになる。)

「[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”は次の3つのモードで働くようデザインされている。
(1)静的モード:これは既存の2Dバーコードと同様であり,短いメッセージが静止画に符号化され,カメラ付き電話はそのコードをスキャンしてこのメッセージを読み取る。
(2)手持ちモード:より多くのデータをダウンロードするとき,カメラ付き電話は一連のフレームを読む必要があり,ユーザーは一定時間その視覚的系列に電話を向けて保持しなければならないだろう。“VCode”が視野にある限りユーザーは完全に静止して保持する必要はない;プログラムが“VCode”を自動的に追跡するであろう。
(3)ドックモード:かなり長いデータをダウンロードする際,電話が静止して画像中のコードマトリックスの位置が変わらなければうまくいく。ドックモードでは最初のフレームの位置が特定された後は幾何学的計算は不要なのでダウンロードスピードはずっと速い。
・・・(中略)・・・
[0094] 各フレームにおいて,最初のバイトは次のフレームタイプを示す: [0095] タイプI - 静止した1枚のフレーム:それに続くバイトでは,ヌル終端文字列としてメッセージ本文を符号化する。
[0096] タイプII - 系列ヘッダー:これは手持ちモードとドックモードでデータファイルを送信するための唯一のフレームである。このフレームはファイル名とサイズを符号化する。
[0097] タイプIII - データフレーム:このフレームは,そのオフセットとチャンク長で始まるデータのチャンクを符号化する。各フレームにはオフセットとチャンク長が付いているので,フレームを読む順序は重要ではない。
[0098] データファイルを符号化するとき,符号化器はそのファイル名とサイズに従った系列ヘッダーフレームを生成し,それからファイルをチャンクに分割してデータフレームを生成する。キャプチャリング時にデータフレームが無くなる場合に備え,全てのデータフレームは3回反復される。最後に符号化器は系列ヘッダーとデータフレームとを合わせてフレームの系列にする。
[0099] 復号器はカメラを通して“見える”あらゆるフレームを復号しようとする。フレームが正しく読まれたことを保証するためにフレームは2回読まれ,その2つのマトリックスが同一であるときのみ受け入れられる。マトリックスを読む際には,復号器は最初のバイトから始めるが,有効なフレームと考えられるためにはそのバイトはタイプI,タイプII,タイプIIIでなければならない。
[0100] タイプIの場合,このフレームの他の全てのビットを復号し,それをポップアップメッセージとして示す。復号器が系列ヘッダーであるタイプ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. We tested four different display frame rates with a NOKIA 6680 camera phone as a capture device. The data file selected was a 4 KB MIDI ring tone encoded as a VCode containing 60 frames. The VCode was displayed at frame rate of 20, 10, 6.6, 4 frames/second respectively on a 15 inch flat panel computer monitor. For each frame rate we let three users download the file into the camera phone. The time t used for download is recorded for each run and the throughput is calculated as 4096×8/t bps. The overall results are shown below in Table I.
・・・(中略)・・・
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. To explain these results, we recorded the total number of dropped frames in each run. From Table II, below, we see that when the frame rate is high (20 fps), the number of dropped frames (over 600) is much higher than that of other settings when the final download is finished.」
(当審仮訳:
VI.実例

[0115] VCodeの直接的な応用の1つは視覚的通信によってデータをダウンロードすることである。ユーザーの視点からは次の2つのファクターが重要である:データ伝送速度とロバストネス。我々の実験はこれら2つのファクターの性能を評価する。

A. データ伝送速度

[0116] データ伝送速度に直接影響する要因は,(1)1つのフレームに符号化されたデータの量と,(2)VCodeが表示されそれに引き続いて復号されるフレームレートである。表示されるフレームレートがPフレーム/秒であり,各フレームにDビットが符号化されているとすれば,理論的には全体としてのビットレートはP×Dビットパーセカンド(bps)である。従って,Pおよび/またはDの増大はより高いビットレートにつながる。しかしながら,現実はさらにもっと複雑である。例えば,もしももっと多くのビットがフレームに符号化されていれば(Dを増大),バーコード密度が増加し,1つのセル単位の解像度は下がり,画像がキャプチャーされたとき,恐らくは復号エラーにつながるであろう。もしもフレームがあまりに速く表示されれば(Pを増大),装置はそれらをキャプチャーして処理できるほど速くはないかもしれず,フレームを損失する結果となる。次のセクションで実施した実験は,これらのファクターの定量的解析をもたらす。
・・・(中略)・・・
[0124] 2)表示フレームレート:一般的に表示フレームレートはフレームがカメラ付き電話によりどれだけ素早くキャプチャーされ処理されるかに依存するので,これはデバイス依存である。カメラ付き電話は幾何学的修正,復号,誤り訂正を実行するために充分な時間が必要なため,フレームは余りに素早く表示されるべきではない。しかしながら,もしも,あまりにゆっくりと表示されれば,カメラ付き電話は同じフレームを何度も処理しなければならない。重複したデータは特定され除去されるけれども,再復号は全体的なビットレートを下げる。理想的な状況は,カメラ付き電話が各フレームを厳密に1度だけ処理することである。もしもフレームが失われれば,誤り訂正で回復されるか,あるいは,VCodeは繰り返しディスプレイされるので次のラウンドで再びキャプチャーできる。我々は,NOKIA 6680カメラ付き電話を捕捉装置として,異なる4つのフレームレートをテストした。選択されたデータファイルは,60フレームを含むVCodeとして符号化された4KBのMIDI着信音である。VCodeは,それぞれ毎秒20,10,6.6,4フレームのフレームレートで15インチのフラットパネルコンピュータモニタに表示された。各フレームレートについて,3人のユーザにカメラ付き電話にファイルをダウンロードさせた。ダウンロードにかかった時間tを各回において記録し,4096×8/t bpsとしてスループットを計算した。全体的な結果は,以下の表1に示されている。
・・・(中略)・・・
表1から,アニメーションレートが非常に高い(20fps)または非常に低い(4fps)ときはダウンロードのビットレートは低いことがわかる。アニメーションレートが6.6から10fpsのときに,最適な結果が得られた。この結果を説明するために,各回において取りこぼしたフレームの全体数を記録した。以下の表2から,フレームレートが高い(20fps)ときは,ダウンロードが終了したときの取りこぼしたフレームの数(600以上)は,他の設定時よりも非常に大きいことがわかる。)

(イ)上記記載から,引用文献1には,次の技術的事項が記載されているものと認められる。

a VCode符号化方法は,QRコードやDataMatrixなどの既存の2Dバーコードを使うのではなく,独自のコードを用いたデータ転送の技術に関するものである([0066])。

b 転送されるデータは,フレーム内及びフレーム間誤り訂正ビットが簡単に挿入され得るように分割されるものであるが,データはまず複数のチャンクに分割され,各チャンクは個々のフレームにさらに分割される([0056])。

c 独自のコードは,キャプチャーされた画像と同様のアスペクト比を持つ長方形であり,データ領域は白及び黒のセルから成り,各々が1ビットのデータを表し,黒が1,白が0を表す2次元の画像コードを含むものである([0066])。

d VCodeは,静的モード,手持ちモード,ドックモードの3つのモードで働くようデザインされている([0092])。

e フレームは,最初のバイトは,当該フレームがタイプI,タイプII,タイプIIIのいずれのフレームタイプであるかを示す([0094])。
また,タイプIIは,手持ちモードとドックモードでデータファイルを送信するための唯一のフレームである系列ヘッダーであり,当該フレームはファイル名とサイズを符号化するものである([0096])。
さらに, タイプIIIは,そのオフセットとチャンク長で始まるデータのチャンクを符号化するデータフレームである([0097])。

f 符号化器は,データファイルを符号化する際には,そのファイル名とサイズに従った系列ヘッダーフレームを生成し,それからファイルをチャンクに分割してデータフレームを生成するが,キャプチャリング時にデータフレームが無くなる場合に備え,全てのデータフレームを3回反復し,最後に系列ヘッダーとデータフレームとを合わせてフレームの系列にする([0098])。

g フレームレートは,VCodeが表示され,引き続いて復号される速度である([0116])。
また,当該フレームレートは,データ転送速度に直接影響する要因であるが,デバイス依存であり,スループット最適化のために調整されるべきものとされている([0068],[0116],[0124])。

(ウ)上記(ア),(イ)から,引用文献1には,次の発明(以下,「引用発明」という。)が記載されていると認められる。

「VCode符号化方法であって,
データはフレーム内及びフレーム間誤り訂正ビットが簡単に挿入され得るように複数のチャンクに分割され,各チャンクは個々のフレームにさらに分割され,
VCodeレンダリングにより各フレーム(誤り訂正フレームを含む)はフラットスクリーンに表示され得る画像に変換され,該画像はQRコードやDataMatrixなどの既存の2Dバーコードを使うのではなく,独自のコードであり,
VCodeは次の3つのモードで働くようデザインされており:(1)静的モード(2)手持ちモード(3)ドックモード,
各フレームにおいて,最初のバイトは次のフレームタイプを示し:タイプI,タイプII,タイプIII,
タイプIIは系列ヘッダーであり,これは手持ちモードとドックモードでデータファイルを送信するための唯一のフレームであり,このフレームはファイル名とサイズを符号化し,
タイプIIIはデータフレームであり,このフレームは,そのオフセットとチャンク長で始まるデータのチャンクを符号化し,
データファイルを符号化するとき,符号化器はそのファイル名とサイズに従った系列ヘッダーフレームを生成し,それからファイルをチャンクに分割してデータフレームを生成し,キャプチャリング時にデータフレームが無くなる場合に備え,全てのデータフレームは3回反復され,最後に符号化器は系列ヘッダーとデータフレームとを合わせてフレームの系列にし,
VCodeは,デバイス依存であるフレームレートで表示及び復号され,当該フレームレートは,スループット最適化のために調整されるべきものである,方法。」

イ 引用文献2
(ア)原査定の拒絶の理由で引用された原出願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった引用文献である,特開2005-338922号公報(平成17年12月8日出願公開。以下,「引用文献2」という。)には,図面とともに,次の記載がある。

「【0004】
しかしながら,上記した特許文献1の技術では,他の情報処理装置との間の情報伝達方式に関し,例えば同文献の図7に示されているような概念的な内容が提案されているにすぎず,具体的な内容は明らかではなかった。このため,実際に他の情報処理装置と情報伝達を行うに際しては,機器仕様や性能面での互換性が問題となり,必ずしも確実かつ効率的に情報伝達を行うことが可能になるという保証はなかった。
・・・(中略)・・・
【0006】
本発明はかかる問題点に鑑みてなされたもので,その目的は,2次元コードの動的表示および検出を通じて,大容量の情報伝達を確実かつ効率的に行うことを可能とする汎用性のある表示装置,通信システムおよび通信方法を提供することにある。」

「【0007】
本発明の通信方法は,動画像の表示が可能な表示画面を有する2つの表示装置の少なくとも一方に,光の受光が可能な受光手段を設け,時間軸に沿って変化する2次元コードである動画2次元コードに関して複数種類のフォーマットを用意し,これら複数種類のフォーマットの中から,2つの表示装置の間での通信に用いるフォーマットを決定し,この決定されたフォーマットに基づいて,送信対象の情報を示す動画2次元コードを生成し,表示画面および受光手段を利用して,生成された動画2次元コードの表示および読み取りを行うことにより,2つの表示装置の間で通信を行うものである。この場合において,2つの表示装置のうちの一方の表示装置において,表示画面および受光手段を利用して,表示装置の処理性能に関する処理性能情報を示す動画2次元コードを他方の表示装置から受信し,この受信した処理性能情報に基づいて,上記複数種類のフォーマットの中から,他方の表示装置との間の通信に用いるフォーマットを決定するようにするのが好ましい。」

「【0012】
ここで,「動画2次元コード」とは,時間軸に沿って変化する一連の2次元コードからなるコード情報である。ここで,「2次元コード」とは,各時点において静止した内容をもつシンボルであって,所定のフォーマットに従って予めその構成や意味内容が規定されている。なお,バーコードは,2次元コードの特殊な一態様である。また,「シンボル」とは,例えば複数の表示エレメントを配置して構成される画像パターンである。通常は,各表示エレメントごとに例えば輝度や色等の光学的物理量を設定することにより,そのような画像パターンとしてのシンボルが形成される。」

「【0017】
処理性能情報がさらに,通信条件としてこれらの情報のうちの少なくとも1つを含むようにした場合には,この通信条件をも考慮して,表示画面,受光手段および動画2次元コードを用いた通信が行われる。ここで,「通信条件」とは,2つの表示装置の間において動画2次元コードを用いた通信を行う際の条件を意味し,例えば上記のように処理性能情報に,対応可能な最上位フォーマット,最大送信速度を示す情報,表示画面サイズ,受光領域のサイズ,受光解像度および同期の可否を示す情報などを含むように構成した場合には,それぞれこれらの処理性能情報に対応して,フォーマット,送信速度,表示画面サイズ,受光領域のサイズ,受光解像度および同期処理を行うかどうかといった条件が決定される。」

「【0082】
また,図8(B)に示したように,シンボルID432の値が「1000b」の場合,このシンボルは,動画2次元コードにおけるスタートシンボル435として機能する。また,シンボルID432の値が「1001b」?「1111b」の場合,このシンボルは,動画2次元コードにおけるヘッダシンボル436として機能し,データ領域433の内容は,シンボルID432の値が「1001b」?「1110b」の場合,この動画2次元コードにおけるファイル名を定義するようになっている。また,シンボルID432の値が「0000b」?「0111b」の場合,このシンボルは,動画2次元コードにおけるデータシンボル437として機能する。
【0083】
このフォーマットBにおける特徴である,シンボルID432の値が「1111b」の場合,データ領域433の内容は初期ネゴシエーション用データとして利用される。具体的にはこの場合,データ領域433の20ビットは,予約ID438として利用される。そして図8(C)に示したように,この予約ID438とそのデータシンボル437の内容との関係は,以下のようになる。」
・・・(中略)・・・
【0085】
そして,予約ID438の値が「00001h」および「00002h」の場合は,データシンボル437におけるデータ情報の内容は,初期ネゴシエーション処理用のデータであることを表す。具体的には,予約ID438の値が「00001h」の場合,後述する装置の処理性能情報を送信することを表し,予約ID438の値が「00002h」の場合,処理性能情報に基づいて決定されたフォーマットおよび通信条件の決定内容通知を送信することを表す。
【0086】
なお,これらの場合における処理性能情報,あるいは決定されたフォーマットおよび通信条件は,データシンボル437において,図8(D)に示した,アスキーコードを用いた初期ネゴシエーション処理用プロトコル44の形式で送受信されるようになっている。この初期ネゴシエーション処理用プロトコル44は,動画2次元コードを用いたデータ通信の最大送信速度を表す領域441と,動画2次元コードについて対応可能な最上位フォーマットを表す領域442と,動画2次元コードを用いたデータ通信の送受信時における同期の可否を表す領域443と,画面サイズを表す領域444と,受光解像度を表す領域445とを含む。」

「【0154】
図17は,上記のように初期ネゴシエーション処理において使用される,図1の表示装置1および入出力端末2の処理性能情報の一例を表すものである。この処理性能情報6は,例えば,対応可能な最上位フォーマット61と,最大送信速度62と,画面サイズ63と,受光解像度64と,同期の可否65とを含む。また,これらの処理性能情報は,例えば図6(C)に示した初期ネゴシエーション処理用プロトコルの形式で,装置間を送受信される。・・・(中略)・・・
【0156】
最大送信速度62は,その装置が動画2次元コードを用いてコンテンツデータを送信可能な最大速度を表し,図17に示したように例えば,120(シンボル/秒)などとなる。また,画面サイズ63は,その装置が備える受発光部が表示および受光することが可能な画面サイズ(画面の短辺方向の実寸サイズ)を表し,例えば200mmなどとなる。受光解像度64は,その装置が備える受発光部が受光することが可能な解像度を表し,例えば72ppi(pixel per inch)などとなる。」

「【0159】
図18は,図1の通信システムにおける表示装置1および入出力端末2の間の初期ネゴシエーション処理を表すものである。ここで,表示装置1が動画2次元コードを用いたコンテンツデータの送信装置側,入出力端末2が動画2次元コードを用いたコンテンツデータの受信装置側であり,また,表示装置1および入出力端末2処理性能情報は,図17に示した情報であるものとする。」
・・・(中略)・・・
【0165】
そして表示装置1は,このフォーマットおよび通信条件の決定内容通知を,入出力端末2へ送信する(ステップS306)。なお,このときはまだ入出力端末2はこの決定内容通知を受信する前であり,どのようなフォーマットおよび通信条件に基づいて受信すればよいか不明であるので,引き続きフォーマットB(ver.1.01)および40(シンボル/秒)の設定で送信する。
【0166】
入出力端末2は,このフォーマットおよび通信条件の決定内容通知を受信し(ステップS307),どのようなフォーマットおよび通信条件に基づいて受信すればよいかを認識する。そして表示装置1は,この決定したフォーマットおよび通信条件で,動画2次元コードを用いたデータ転送を開始する(ステップS308)。この場合,決定したフォーマットおよび通信条件は上記のように,フォーマットはフォーマットC(ver.2.01),送信速度は40(シンボル/秒)である。そして入出力端末2はこの動画2次元コードを用いたデータを受信し,初期ネゴシエーション処理が終了となる。以後,この決定されたフォーマットおよび通信条件でデータ転送が行われる。」

(イ)上記記載から,引用文献2には,次の技術的事項が記載されているものと認められる。

a 引用文献2は,2次元コードの動的表示及び検出を通じての情報伝達の技術に関するものである(【0006】)。
また,実際に他の情報処理装置と当該情報伝達を行う際に,機器仕様や性能面での互換性の問題のため必ずしも確実かつ効率的に情報伝達を行うことができず(【0004】),通信条件を含む機器の処理性能情報を考慮して情報伝達を行う必要がある,との課題認識を開示している(【0017】)。

b 引用文献2に記載の通信方法は,2つの表示装置間で,表示画面及び受光手段を利用して,生成された動画2次元コードの表示及び読み取りを行うことにより通信を行うものである(【0007】)。

c 動画2次元コードは,時間軸にそって変化する一連の,2次元コードであるシンボルからなるものである(【0012】)。

d 処理性能情報に含まれる最大送信速度は,装置が動画2次元コードを用いてコンテンツデータを送信可能な最大速度を表すものであり,(シンボル/秒)の単位を用いて表現される(【0154】,【0156】)。

e 送信側装置である表示装置は,受信側装置である入出力端末へ通信条件の決定内容通知を送信し,当該決定した通信条件で,動画2次元コードを用いたデータ転送を行う(【0159】,【0165】-【0166】)。
また,当該通信条件の決定内容通知の送信は,ヘッダシンボルを用いて行われる(【0082】-【0083】,【0085】-【0086】)。

(ウ)上記(ア),(イ)から,引用文献2には,次の発明(以下,「副引用発明」という。)が記載されていると認められる。

「2つの装置間で一連の2次元コードであるシンボルからなる動画2次元コードを通信する方法であって,
送信側装置の表示画面に順次表示した前記シンボルを受信側装置の受光手段で読み取ることにより当該通信を行い,
当該順次表示したシンボルの送信に際し,送信側装置から受信側装置へ通信条件をヘッダシンボルを用いて送信し,
当該通信条件は,(シンボル数/秒)の単位で表現される当該シンボルを送信する速度である最大送信速度を含む,通信方法。」

(3)引用発明との対比
ア 本件補正発明と引用発明とを対比する。
(ア)引用発明の「VCode符号化方法」は,上位概念では「データを符号化するための方法」であるといえることから,本件補正発明とは「データを符号化するための方法」である点で一致する。

(イ)引用発明では「データはフレーム内及びフレーム間誤り訂正ビットが簡単に挿入され得るように複数のチャンクに分割され,各チャンクは個々のフレームにさらに分割され」るが,該分割された「フレーム」は符号化の単位であり,本件補正発明の「部分」に相当するものであるから,引用発明と本件補正発明とは「前記データを複数の部分へと分割するステップ」を備えている点で共通するといえる。

(ウ)引用発明の「VCodeレンダリングにより各フレーム(誤り訂正フレームを含む)はフラットスクリーンに表示され得る画像に変換され」る当該「画像」は,「QRコードやDataMatrixなどの既存の2Dバーコードを使うのではなく,独自のコードであ」るが,当該「変換され」た「画像」である「独自のコード」は,各(データ)フレーム毎に生成された「別個の」(視覚的)フレームといえるから,本件補正発明の「別個のバーコード・フレーム」とは,「別個のフレーム」である点で共通する。
したがって,引用発明と,本件補正発明の「各部分を別個のバーコード・フレームとして符号化することで,バーコード・フレームのシリーズを提供するステップ」とは,後記する点で相違するものの,「各部分を別個のフレームとして符号化することで,フレームのシリーズを提供するステップ」を備える点で共通するといえる。

(エ)引用発明の「系列ヘッダー」は,データファイルの「ファイル名とサイズを符号化」した「フレーム」であるから,上位概念では当該データファイルに関し「データ全体の特性を示すフレーム」であり,また,データフレームとは異なるフレームであって,データファイルを送信するための唯一のフレームであるといえる。
よって,引用発明の「系列ヘッダー」と本件補正発明の「第1のバーコード・フレーム」とは,「前記データ全体の特性を示す第1のフレーム」である点で共通する。

(オ)また,引用発明の「系列ヘッダー」は,「データフレームとを合わせてフレームの系列」にされるものである。
したがって,引用発明と,本件補正発明の「前記バーコード・フレームのシリーズにおいて,前記データ全体の特性を示す第1のバーコード・フレームを提供するステップ」とは,後記する点で相違するものの,「前記フレームのシリーズにおいて,前記データ全体の特性を示す第1のフレームを提供するステップ」を備える点で共通するといえる。

イ 以上のことから,本件補正発明と引用発明との一致点及び相違点は,次のとおりである。

【一致点】
「 データを符号化するための方法であって,
前記データを複数の部分へと分割するステップと,
各部分を別個のフレームとして符号化することで,フレームのシリーズを提供するステップと,
前記フレームのシリーズにおいて,前記データ全体の特性を示す第1のフレームを提供するステップと,
を含む方法。」


【相違点1】
「フレーム」に関して,本件補正発明では「バーコード・フレーム」であるのに対し,引用発明では「変換され」た「画像」である「独自のコード」である点。

【相違点2】
本件補正発明の「特性」は,「前記バーコード・フレームのシリーズに含まれる各バーコード・フレームを,該バーコード・フレームのシリーズを提供する装置上で逐次的に表示するために用いられる速度を示すフレーム・レートを含む」のに対し, 引用発明の系列ヘッダーが示す「特性」は,当該フレーム・レートを含まない点。

(4)判断
以下,上記相違点について検討する。

ア 相違点1について
引用発明の「独自のコード」は,「キャプチャーされた画像と同様のアスペクト比を持つ長方形」であるが,「データ領域は白及び黒のセルから成り,各々が1ビットのデータを表し,黒が1,白が0を表す」2次元の画像コードであるから,当該技術分野においては,2次元バーコードと呼ぶことができるものである。
したがって,上記【相違点1】は実質的な相違点ではない。

イ 相違点2について
副引用発明の「最大送信速度」は,動画2次元コードを構成する一連の2次元コードであるシンボルを送信側装置から受信側装置へ送信する速度であり,また,当該送信は,送信側装置において複数のシンボルを順次表示することで行われるものであるから,本件補正発明の「フレーム・レート」に相当する。
そして,当該「最大送信速度」は「ヘッダシンボル」を用いて送信側装置から受信側装置へ送信されるものであるから,当該「ヘッダシンボル」は,本件補正発明の「第1のバーコード・フレーム」に対応するといえる。
他方,引用発明の系列ヘッダーが示す「特性」には,フレームレートは含まれていないが,前記(2)ア(イ)gにおいて検討したとおり,スループットの最適化のためにデバイス依存である当該フレームレートを調整する必要があるとの課題認識は引用文献1に開示されていると解することができる。
そうすると,引用発明及び副引用発明は,いずれも2次元コードを利用したデータ転送(情報伝達)といった共通の技術分野に属し,また,機器の処理性能情報を考慮して情報伝達を行う必要があるとの共通の課題認識を有するものであるから,引用発明に副引用発明を適用することにより,フレームレート(最大送信速度)を系列ヘッダーに含めて提供するように構成することで,当該系列ヘッダーが示す前記特性が当該フレームレートを含むことになるように構成することは,引用文献1-2に接した当業者であれば容易になし得たものである。

ウ そして,これらの相違点を総合的に勘案しても,本件補正発明の奏する作用効果は,引用発明及び副引用発明の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。

エ したがって,本件補正発明は,引用発明及び副引用発明に基づいて,当業者が容易に発明をすることができたものであり,特許法第29条第2項の規定により,特許出願の際独立して特許を受けることができないものである。

3 本件補正についてのむすび
よって,本件補正は,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。
よって,上記補正の却下の決定の結論のとおり決定する。


第3 本願発明について
1 本願発明
平成30年4月26日にされた手続補正は,上記のとおり却下されたので,本願の請求項に係る発明は,平成29年5月25日にされた手続補正により補正された特許請求の範囲の請求項1ないし19に記載された事項により特定されるものであるところ,その請求項1に係る発明(以下,「本願発明」という。)は,その請求項1に記載された事項により特定される,前記第2[理由]1(2)に記載のとおりのものである。

2 原査定の拒絶の理由
原査定の拒絶の理由は,この出願の請求項1ないし19に係る発明は,原出願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献1に記載された発明及び引用文献2に記載された技術事項に基づいて,その優先日前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない,というものである。

引用文献1:米国特許出願公開第2010/0020970号明細書
引用文献2:特開2005-338922号公報

3 引用文献
原査定の拒絶の理由で引用された引用文献1並びに2及びその記載事項は,前記第2の[理由]2(2)に記載したとおりである。

4 対比・判断
本願発明は,前記第2の[理由]2で検討した本件補正発明の発明特定事項である「データ全体の特性」から,限定事項である「全体」を削除したものである。
そうすると,本願発明の発明特定事項を全て含み,さらに他の事項を付加したものに相当する本件補正発明が,前記第2の[理由]2(3),(4)に記載したとおり,引用発明及び副引用発明に基づいて,当業者が容易に発明をすることができたものであるから,本願発明も,引用発明及び副引用発明に基づいて当業者が容易に発明をすることができたものである。


第4 むすび
以上のとおり,本願発明は,特許法第29条第2項の規定により特許を受けることができないから,他の請求項に係る発明について検討するまでもなく,本願は拒絶されるべきものである。

よって,結論のとおり審決する。
 
別掲
 
審理終結日 2018-11-27 
結審通知日 2018-11-29 
審決日 2018-12-11 
出願番号 特願2017-11952(P2017-11952)
審決分類 P 1 8・ 121- Z (G06K)
P 1 8・ 575- Z (G06K)
最終処分 不成立  
前審関与審査官 月野 洋一郎  
特許庁審判長 辻本 泰隆
特許庁審判官 ▲はま▼中 信行
須田 勝巳
発明の名称 ストリーミングされたバーコードを使用したデータ交換  
代理人 吉澤 弘司  
代理人 岡部 讓  

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