【事件の表示】
　特願２００４−５６９１７８「データを送受信するためのシステムと方法」拒絶査定不服審判事件〔平成１６年　９月１６日国際公開、ＷＯ２００４／０７９９５６、平成１８年　４月２７日国内公表、特表２００６−５１４４８９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、平成１５年４月２３日（パリ条約による優先権主張外国庁受理平成１５年３月５日、米国）を国際出願日とする出願であって、平成２０年８月２０日に手続補正がなされたが、同年１０月２日付けで拒絶査定され、これに対し、平成２１年１月５日に拒絶査定不服審判が請求されたものであって、特許請求の範囲の請求項１に係る発明（以下、「本願発明」という。）は、平成２０年８月２０日付け手続補正書により補正された明細書及び図面からみて、その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　
「データを送信する方法であって、
　第1方向の配列と、この第1方向と直交する方向である第2方向の配列とを有する二次元データ構造に、前記第1方向の配列に沿って、1つ以上のデータ・セグメントを収納するステップと、
　前記第2方向の配列のそれぞれに、対応する計算した1つ以上の特性値を付加するステップと、
　前記特性値の一部を含む1つ以上の前記第1方向の配列の内容を送信するステップと、
　前記データ・セグメントのそれぞれに、前記データ構造における位置指標を付加するステップと、
　1つ以上の前記データ・セグメントを送信するステップと、
　を含む方法。」
　
２．引用発明
　原査定の拒絶の理由に引用された特開平１１−１３６２２０号公報（以下、「引用例」という。）には、「符号伝送方法、送信装置、受信装置および通信システム」として図面と共に次の記載がある。
　
イ．「【００３２】
【発明の実施の形態】以下、本発明の実施の形態について図面を参照しながら説明する。
【００３３】（第１の実施形態）第１の実施形態では、本発明のベースとなる基本的な誤り訂正符号の通信方法について説明する。
【００３４】初めに、従来の一般的な符号化方式を用いた誤り訂正について説明する。
【００３５】例として、組織的である巡回符号の場合を示す。組織的であるとは誤り訂正符号化を行ったときに、元の情報がそのまま情報部分として残り、冗長部分が情報部分とは別個にできて情報部分とはっきりと分割できる状態のことをいう。」（６頁１０欄２行〜１４行）
　
ロ．「【００４０】ここでシンボル単位の抜けが発生し得るような通信の形態について記述する。図１にパケット通信と符号語との関係を示す。図のように符号語は１つのシンボルが１つのパケットに入るように分割されている。そして、第１のパケットから第ｍのパケットには情報シンボルが、第（ｍ＋１）のパケットから第（ｍ＋ｋ）のパケットには冗長シンボルが含まれる。
【００４１】第１のパケットを見ると、そのぺイロードは複数の符号語の第１の情報シンボルが集まってできているように見える。同様に第（ｍ＋１）のパケットは複数の符号語の第（ｍ＋１）のシンボルである冗長シンボルが集まってできているように見える。このように、パケットは全てが情報シンボルからなる情報パケットと全てが冗長シンボルからなる冗長パケットに完全に分割されている。
【００４２】パケットはルータ等で廃棄されることがあり、１つのパケットが廃棄された時、図１の各符号語から見ると、１つのシンボルが廃棄されたように見える。
【００４３】ただし、図１は全てのパケットの長さが同じである場合について記述したが、図２のように長さの異なるパケットが存在する場合は、冗長パケットは、情報パケットのうち最長のもの（図では第２のパケット）に合わせて作成される。このとき、実質上情報パケット部分のシンボルにデータのない符号語もあるので、情報パケットが廃棄されてもその符号語にとっては情報損失が起こらない場合もある。
【００４４】以上のように、まず送信すべき情報をシンボルを単位として複数の情報パケットに分散させて入れる。また、送信すべき冗長部分をやはりシンボル単位に複数の冗長パケットに分散させて入れておく。このようないわゆる符号語を複数のパケットに対してインターリーブさせるような形で挿入しておくことによって、ｌつのパケットの廃棄は、そこに含まれる複数（例えばｎ個）の符号語のそれぞれにとって、１つのシンボルの抜け、を意味することとなる。」（６頁９欄３３行〜１０欄４４行）
　
ハ．「【００５１】以下では、代表例として、ＧＦ（２＾h ）上のＲＳ符号を用いた場合について記述することにする。ＲＳ符号は多くの符号の中でｋシンボルの冗長があった場合にｋシンボルまでの抜けを訂正できる非常に効率のよい符号である。ただし、ＲＳ符号以外のブロック符号においても同様の方法があてはまり、一般性は失われない。」（７頁１２欄１０行〜１６行）
　
ニ．「【００８２】はじめに送信側における処理を説明する。この流れは図７に示される。
【００８３】まずＦＥＣレイヤはＩＰパケットをＩＰのレイヤ（ネットワークレイヤ）から受け取る。この渡されたＩＰパケットをここではオリジナルＩＰパケット１３０１と呼ぶことにする。このオリジナルＩＰパケット１３０１をインタリーブマトリクス１３０２と呼ばれるメモリバッファ領域にパケットのヘッダも含めて書き込む。この書き込みは、インタリーブマトリクス１３０２の縦方向にデータを書き込んで行くことによって行われる。１つの縦の列は例えば１２８バイト、５１２バイト、１０２４バイトといった固定サイズからなる場合が多いが、本例では可変サイズとしている。オリジナルＩＰパケット１３０１は可変長なので、最後の列の途中でデータが終る場合がある。その場合、最終列にはパディング（ＰＡＤ）をつける。
【００８４】次に、横の一行毎に誤り訂正符号化の計算を行い、その計算結果である符号化データを、図７においてインタリーブマトリクスの右側に位置しているコード領域の同じ行に相当する部分に書き込んで行く。横のサイズは、誤り訂正に用いられるシンボルの大きさによって最大長が決まり、具体的には１シンボルのビット数をＢとすると、２B −１となる。このサイズはデータの縦列とコードの縦列の合計の最大数に相当する。
【００８５】誤り訂正符号の方法は前述した通りであり、シンボル単位で横方向に計算する。このとき、マトリクスの左側の何も入っていない部分は無視される。マトリクス毎に符号化の程度を変更することも可能である。例えば、オリジナルＩＰパケット１３０１の長さや、コネクションの種類によって符号化のパラメータを変更することができる。
【００８６】上記インタリーブマトリクスは、実は図１および図２と対応させることができる。ここでは図１との対応を記述する。
【００８７】図１におけるぺイロード部分がマトリクスの縦の列に対応している。従って、元のＩＰパケットは図１において、先頭から同じシンボル数（ここではｎシンボル数であるとする）ずつｍ個に区切られて、第１のパケットから第ｍのパケットのペイロードにそれぞれ分割されて入れられることになる。そして、第１のパケットから第ｍのパケットまでのｊ番目のシンボル（ｊ＝１〜ｎ）を使って、ｋシンボル分の冗長シンボルを作成する。作成方法は既に述べた通りである。
【００８８】そしてそれらｋ個の冗長シンボルを図１の第（ｍ＋1)のパケットから第（ｍ＋ｋ）のパケットまでのｊ番目のシンボル位置にそれぞれ書き込む。ｎ個のシンボルについて同様の操作を行うと、第（ｍ＋１）のパケットから第（ｍ＋ｋ）のパケットのぺイロ−ドに冗長シンボルが詰まることになる。
【００８９】図１はｊ番目のｍ個のシンボルからｊ番目のｋ個のシンボルを作成しているが、対応づけが明確であれば、シンボル順序を変更して計算してもよい。すなわち、第ｉ番目の（ｉ＝１〜ｍ）パケットのｊ［ｉ］番目（ｊ［ｉ］＝１〜ｎ）のシンボルを取り出してｍ個の情報シンボルとし、そのｍ個の情報シンボルから得られるｋ個の冗長シンボルを第（ｍ＋１）のパケットから第（ｍ＋ｋ）のパケットまでの任意のシンボル位置に１つずつ書き込む。このとき、選択するｍ個の情報シンボルは重複なく選択することとし、また冗長シンボルを書き込む位置も重複のないようにすれば、同様の訂正能力を持った冗長パケットが出来上がることになる。
【００９０】次に、情報の入っている縦の列のそれぞれに対してＦＥＣヘッダを付与する。１つの縦の列はこのＦＥＣへッダおよびＩＰ−ＦＥＣへッダを付与された状態で１つのＩＰパケットとなる。この固定長の短いＩＰパケットをＩＰ−ＦＥＣパケット１３０３と呼ぶ。
【００９１】ＦＥＣヘッダに含まれる情報の例を図８に示す。同図に示すように、ＦＥＣヘッダ１４０１は４バイトからなり、以下のフィールドを持つ。
【００９２】・＃ｐａｒｉｔｙ
マトリクスの横の１行に対して何シンボルの訂正シンボルを付与しているかを示す。よって、各マトリクス毎に付与する訂正シンボル数が異なっていることもある。
【００９３】・ｄａｔａ／ｃｏｄｅ
そのＦＥＣヘッダが付与されているペイロードがデータを含むのか、それとも訂正コードを含むのかを示す。
【００９４】・＃ｄａｔａ  ｐｋｔ
そのマトリクスが含まれるデータの縦の列数をしめす。
【００９５】・Ｆｒａｍｅ  ＩＤ
マトリクス単位に送信側で順次インクリメントしていくＩＤ番号。ＩＰレイヤはコネクションレス通信なので受信側でのパケットの到着順序が入れ替わることがある。このために送信側でそれを識別するための情報を入れておき、到着したパケットがどのインタリーブマトリクスに属するかの判定を行えるようにする。
・ＳＮ
マトリクス毎に初期化され付与されるシーケンスナンバ。すなわちこれは、あるインタリーブマトリクスの中でのパケットの識別のために使われる。同一のマトリクスに同じＳＮを持ったパケットは存在しない。
【００９６】次に、ＩＰ−ＦＥＣヘッダ１４０２を付与する。これは、基本的には上位レイヤから渡された時に付与されていたオリジナルのＩＰパケット１３０１のヘッダのコピーである。変更点は、プロトコルフィールドをＦＥＣに設定しておくことと、パケットのトータル長をＩＰ−ＦＥＣヘッダ長（２０バイト＋オプション）、ＦＥＣヘッダ長（図８の例では４バイト）、インタリーブマトリクスの縦の長さ（１２８バイト、５１２バイトなど）の合計に設定すること、そして、チェックサムは計算し直すことである。
【００９７】ＩＰ−ＦＥＣヘッダ１４０２を付与したら、完成したＩＰ−ＦＥＣパケット１３０３をデータリンクレイヤに順次渡して行く。
【００９８】次に、受信側の動作について説明する。この様子を図９に示す。ＩＰ−ＦＥＣパケット１５０３がデータリンクレイヤから上げられると、まずＩＰレイヤがこれを受信する。ＩＰレイヤにおいて、ＩＰ−ＦＥＣパケット１５０３は一般のＩＰパケットと同じようにハンドリングされ、ヘッダのプロトコルフィールドの内容（ＦＥＣ）に従ってＦＥＣレイヤヘ渡される。ＩＰ−ＦＥＣヘッダはＩＰレイヤで解釈可能である。
【００９９】ＦＥＣレイヤでは、ＩＰ−ＦＥＣパケット１５０３からＩＰ−ＦＥＣヘッダを取り出してＦＥＣヘッダのチェックを行い、図８に示したフレームＩＤとＳＮの情報から、ペイロードの部分を適切なインタリーブマトリクス１５０２の適切な列に縦に書き込む。ＩＰプロトコルの転送では正しい到着順序が保証されていないため、図９で示されているように、複数のフレームを同時に保持できるようにしている。
【０１００】図９の一番左のインタリーブマトリクスのようにデータ領域に相当する部分が全て揃えば、オリジナルＩＰパケット１５０１の組み立てが完了するので、コード領域のＩＰ−ＦＥＣパケットは不必要なものとして廃棄される。
【０１０１】また、図９の真ん中に示されるマトリクスの場合は、コード領域の部分が到着してもデータ部分が到着していないのでパケットロスが発生した可能性があると見なされる。そこで誤り（消失）訂正を行う機会の待機状態に入る。
【０１０２】パケットロスなしでオリジナルＩＰパケットが出来上がった、もしくは、パケットロスはあったが訂正によりオリジナルＩＰパケットが再生できたら、再度、そのオリジナルＩＰパケットをＩＰレイヤヘ渡す。
【０１０３】インタリーブマトリクスはー度に保持できる最大数が決っており、それ以上になった場合には最も保持時間の長い（古い）マトリクスを探し、このマトリクスに書き込まれたデータの訂正処理を開始する。また、タイマを設けておき、ある時間が経過したにも関わらずマトリクスにデータが揃わない場合にも訂正処理を開始するようにしてもよい。」（９頁１６欄１５行〜１１頁１９欄４行）
　
ホ．「【０１２５】ＩＰ−ＦＥＣパケット処理モジュール１７０５には、到着したＩＰ−ＦＥＣパケットのペイロードに対する複数のインタリーブマトリクスが用意されている。ＩＰ−ＦＥＣパケット処理モジュール１７０５は、ＩＰパケット受信モジュール１７０６からのＩＰ−ＦＥＣヘッダの情報と、渡されたＦＥＣヘッダの情報を使って、ＩＰ−ＦＥＣパケットのペイロードを該当するインタリーブマトリクスの所定の位置に書き込む。インタリーブマトリクスは送信装置１６０１において符号化された１つの単位毎に構成される。受信装置１７０１における具体的な手順においては、ＦＥＣヘッダにおいて同じフレームＩＤを有するものは原則として同じインタリーブマトリクスに入れられる。ただし、同じフレームＩＤを持っていても、その中にさらに順序を示す識別子があれば、その識別子別にインタリーブマトリクスを作成する。この識別子は、送信装置１６０１においては、１つのオリジナルＩＰパケットに対して複数の符号化処理を行った場合の識別子を意昧する。」（１２頁２２欄４０行〜１３頁２３欄７行）
　
　
　上記引用例の記載及び関連する図面並びにこの分野の技術常識を考慮すると、
（１）上記イ．、ニ．の【００８３】〜【００９０】、図７から明らかなように、引用例記載の「通信方法」では、「縦方向」の「列」と「横方向」の「行」とを有する「マトリクス」が用いられており、この「マトリクス」は二次元といえるものであって、「縦方向」と「横方向」とが直交していることは技術常識であり、
（２）上記ニ．の【００８７】の記載、図１及び図７に記載された「マトリクス」の縦横の対応から明らかなように、図７に記載された「マトリクス」の「縦方向」の「列」に沿って、１つ以上の「ペイロード」（図１）に分割された「ＩＰパケット」を収納しており、
（３）上記ニ．の【００８４】、図７から明らかなように、図７に記載された「マトリクス」の「横方向」の「行」のそれぞれに「計算」された「符号化データ」（図１の「冗長データ」相当）が付加されており、
（４）上記ロ．、ニ．の【００８９】〜【００９１】、図１から明らかなように、「冗長データ」（符号化データ）の一部を含む「縦方向」の「列」の内容が送信されており、
（５）上記ニ．の【００９０】〜【００９５】から明らかなように、「縦の列」のそれぞれに「ＦＥＣヘッダ」を付加して「ＩＰ−ＦＥＣパケット」として送信しており、この「ＦＥＣヘッダ」には「シーケンスナンバ」が含まれている。
　
　したがって、上記（１）〜（５）からして、引用例には以下の発明（以下、「引用発明」という。）が開示されていると認められる。
　 
（引用発明） 
「データを送信する方法であって、
　縦方向の列と、この縦方向と直交する方向である横方向の行とを有する二次元マトリクスに、前記縦方向の列に沿って、1つ以上の分割されたＩＰパケットを収納するステップと、
　前記横方向の行のそれぞれに、対応する計算した1つ以上の符号化データを付加するステップと、
　前記符号化データの一部を含む1つ以上の前記縦方向の列の内容を送信するステップと、
　縦の列のそれぞれに、前記マトリクスにおけるシーケンスナンバを付加するステップと、
　1つ以上のＩＰ−ＦＥＣパケットを送信するステップと、
　を含む方法。」 
　 
　 
３．対比・判断 
　本願発明と引用発明とを対比する。 
　引用発明の「縦方向」、「横方向」をそれぞれ「第1方向」、「第2方向」と呼ぶことは任意であり、
　引用発明の「行」、「列」は、いずれも本願発明の「配列」に相当し、
　引用発明の「分割されたＩＰパケット」は、データであるＩＰパケットを分割した部分（セグメント）あるから、「データ・セグメント」といえるものであり、
　引用発明の「マトリクス」は、データを格納する形式であるから、「データ構造」といえるものであり、
　引用発明の「符号化データ」は、上記ハ．、ニ．から明らかなように、例えばＦＥＣやＲＳ符号により得られた符号化データであるから、データの特性を表す値であって本願発明の「特性値」に相当し、
　引用発明の「シーケンスナンバ」は、上記ニ．の【００９５】〜【０１０２】、ホ．から明らかなように、マトリクス中の位置を示しているから、「位置指標」といえるものである。
　 
　したがって、本願発明と引用発明とは、以下の点で一致し、また相違する。 
　 
（一致点） 
「データを送信する方法であって、
　第1方向の配列と、この第1方向と直交する方向である第2方向の配列とを有する二次元データ構造に、前記第1方向の配列に沿って、1つ以上のデータ・セグメントを収納するステップと、
　前記第2方向の配列のそれぞれに、対応する計算した1つ以上の特性値を付加するステップと、
　前記特性値の一部を含む1つ以上の前記第1方向の配列の内容を送信するステップと、
　を含む方法。」 
　 
（相違点）
　本願発明が、「前記データ・セグメント」のそれぞれに、前記データ構造における位置指標を付加するステップと、1つ以上の「前記データ・セグメント」を送信するステップとを含むのに対して、引用発明では、「縦の列」のそれぞれに、前記データ構造における位置指標を付加するステップと、1つ以上の「ＩＰ−ＦＥＣパケット」を送信するステップとを含む点。
　
　そこで、上記相違点について検討するに、上記ニ．の【００８７】、【００９０】から明らかなように、引用発明における「縦の列」には、分割されたＩＰパケット（データ・セグメント）が入れられたものが含まれており、引用発明における「ＩＰ−ＦＥＣパケット」は、この縦の列にシーケンスナンバ（位置指標）を含むヘッダが付加されたものであるから、上記相違点は表現上の微差であって格別のものではない。
　
　そして、本願発明の効果も引用発明から当業者が予測し得る範囲のものであり、審判請求の理由における審判請求人の主張も上記認定判断を覆すものではない。
　 
　 
４．むすび 
　以上のとおり、本願発明は、引用発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
　 
　よって、結論のとおり審決する。