【事件の表示】
　特願２００３−５４３２５９「信頼性の低い通信環境における通信効率および性能の改良」拒絶査定不服審判事件〔平成１５年　５月１５日国際公開、ＷＯ０３／４１３４５、平成１７年　４月　７日国内公表、特表２００５−５０９３７０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯と本願発明
　本件出願は、平成１４年１０月２６日（パリ条約による優先権主張２００１年１１月６日、米国）を国際出願日とする出願であって、平成１９年１月２２日付けで手続補正がなされたが、平成１９年３月２９日付けで拒絶査定がなされ、これに対し、平成１９年５月１１日に拒絶査定に対する審判請求がなされたものであって、その請求項１に係る発明（以下、「本願発明」という。）は、上記手続補正により補正された特許請求の範囲、明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　
　「マルチノード・データ処理環境においてメッセージを伝送する方法であって、
　アプリケーションから送信されるメッセージを前記アプリケーションの識別子とともにメッセージ・キューに配置するステップと、
　現在のネットワーク伝送容量の指標に基づいて、送信するメッセージの数を選択するステップと、
　前記選択された数のメッセージを送信するステップと、
　前記送信されたメッセージの到着の確認応答を受信するステップと、
　受信した確認応答の数を、現在のネットワーク伝送容量の指標に基づいて送信された前記メッセージの数と比較して、受信した確認応答の前記数に基づいて前記送信するメッセージの数を修正するステップと、
　を含む方法。」
　
２．引用発明
　これに対して、原査定の拒絶の理由に引用された特開昭６４−２０７５５号公報（以下、「引用例」という。）には「ウィンドウ制御方式」に関し、図面とともに以下の事項が記載されている。
　
イ．「〔従来の技術〕
　ウィンドウ制御方式とは、パケット通信において送信側からデータパケットを送る際に、最大ウィンドウサイズ個までのデータパケットは、受信側から送られる送達確認パケットの受信を待たずに先送りすることを許している方式である。
　従来、ウィンドウ制御方式は、第３図ａに示すような、全ての端末（ＴＩ、Ｔ２）とノード（Ｎ１、Ｎ２）間、ノード（Ｎ１）とノード（Ｎ２）間でそれぞれ独立にウィンドウ制御を行うリンク・パイ・リンク（１ｉｎｋ−ｂｙ−１ｉｎｋ）方式とよばれる方式が主に用いられていたが、この方式では、端末やノード間のパケット転送速度の変化はそれぞれのリンクごとに吸収されるため、ネットワークの利用効率や送信側のパケット転送速度を低下させることがなかった。しかし、高速化したパケット・ネットワークでは、第３図ｂに示すように端末（Ｔ１）と端末（Ｔ２）間でのみウィンドウ制御を行うエンド・ツー・エンド（ｅｎｄ−ｔｏ−ｅｎｄ）方式が考えられている。このｅｎｄ−ｔｏ−ｅｎｄでのウィンドウ制御を行う場合は、中継途中のパケット転送速度の変化がリンクごとに吸収されずネットワーク全体に影響を及ぼすことになる。」（第１頁左欄第１９行〜第２頁左上欄第１行）
　
ロ．「第４図に、さまざまな固定したウィンドウサイズを用いてｅｎｄ−ｔｏ−ｅｎｄでウィンドウ制御を行った場合に、一定の大きさのデータファイルの転送を行うための所要時間を示す。・・・（中略）・・・領域Ｃは、ウィンドウサイズが大きすぎ、中継途中のパケット転送速度以上の速度で送信側がパケットを送出するために、中継途中でパケットの廃棄が起こり、送信側は受信側からの再送要求パケットなどを待ってデータ再送を行うので送信側の実効的なパケット送出速度は低下し、中継途中のネットワーク全体の利用効率も低下する領域である。」（第２頁左上欄第２〜２０行）
　
ハ．「次に、送信側は、通常のウィンドウ制御を行いながら送信したデータパケットの応答として受信側から送られてくる応答パケットを受信すると、通常の受信動作に加えて次のような動作をする。まず応答パケットが送達確認パケットであれば、そのパケットによって新たに送達の確認されたパケット数を送達確認パケット数信号入力線１３から入力する。送達確認パケット受信数カウンタ６は、その入力線１３からの信号をカウントする。また応答パケットが再送要求パケットであればそのパケットの再送要求数を入力線１４に入力する。再送要求パケット数カウンタ７は、入力線１４からの値をカウントする。送信側は、ウィンドウサイズと等しい数のパケットの送達を確認するまでこの動作を続ける。」（第３頁左下欄第１８行〜同頁右下欄第１５行）
　
ニ．「セレクタ１６のもう一方の入力には、ウィンドウサイズレジスタ２の値から、カランタ７の値、即ち今回のウィンドウサイズを用いてウィンドウサイズ個のパケットの送達確認を受信する間に受信したパケット再送要求の数を引いたものが入力されている。
　セレクタ１６は、比較器１９により、カウンタ７の値が０よりも大きいときに、即ち再送要求パケットを１つでも受信していた場合には、減算器２３の出力を選択し、再送要求パケットを１つも受信しなかった場合には、加算器２０の値を出力する。この値が、新しいウィンドウサイズとして出力線１０から出力される。」（第４頁右下欄第７〜１９行）
　
ホ．「上述の動作により、このウィンドウサイズ決定器では、ウィンドウサイズを設定した後、そのウィンドウサイズを用いて通常のウィンドウ制御によるデータパケットの送出を行い、ウィンドウサイズと等しい数のパケットの送達確認を行う。その間に、パケットの再送要求が生じていれば、ウィンドウサイズをその受信した再送要求の数だけ小さくする。」（第５頁左上欄第３〜１０行）
　
　上記引用例の記載及び図面ならびにこの分野における技術常識を考慮すると、
ａ．従来の技術として第３図ａ，ｂに記載された端末（Ｔ１，Ｔ２）とノード（Ｎ１，Ｎ２）からなるネットワークにおいてデータパケットを伝送する際のウィンドウ制御方式が記載されており（上記摘記事項イ）、引用例のウィンドウ制御方式は従来のウィンドウ制御方式の課題を解決するものである。ここにおいて、端末（Ｔ１，Ｔ２）とノード（Ｎ１，Ｎ２）からなるネットワークは「マルチノード」であり、これらのノードはデータパケットの送受信、転送等の「データ処理」を行うものであるから、「マルチノード・データ処理環境においてデータパケットを伝送する方法」が記載されているということができる。
　
ｂ．再送要求パケットは、ウィンドウサイズが大きすぎ、中継途中のパケット転送速度以上の速度で送信側がパケットを送出するために、中継途中でパケットの廃棄が起こるために受信側から送信側に送られるものである（上記摘記事項ロ）から、再送要求パケットの数は「現在のネットワーク伝送容量の指標」ということができ、現在のウィンドウサイズから再送要求パケットの数を減算した数が新しいウィンドウサイズとなり（上記摘記事項ニ）、新しいウィンドウサイズを用いて通常のウィンドウ制御によるデータパケットの送出を行う（上記摘記事項ホ）のであるから、「現在のネットワーク伝送容量の指標に基づいて、新しいウィンドウサイズを選択するステップ」および「新しいウィンドウサイズのデータパケットを送信するステップ」が記載されているといえる。
　
ｃ．送信側は、通常のウィンドウ制御を行いながら送信したデータパケットの応答として受信側から送られてくる応答パケットを受信する（上記摘記事項ハ）のであるから、「送信されたデータパケットの到着の確認応答を受信するステップ」が記載されているということができる。
　
ｄ．現在のウィンドウサイズから再送要求パケットの数を減算した数が新しいウィンドウサイズとなる（上記摘記事項ニ）から、「受信した再送要求パケットの数に基づいてウィンドウサイズを修正するステップ」が記載されている。
　
　以上を総合すると、上記引用例には以下の発明（以下、「引用発明」という。）が開示されている。
「マルチノード・データ処理環境においてデータパケットを伝送する方法であって、
　現在のネットワーク伝送容量の指標に基づいて、新しいウィンドウサイズを選択するステップと、
　前記選択された新しいウィンドウサイズのデータパケットを送信するステップと、
　前記送信されたデータパケットの到着の確認応答を受信するステップと、
　受信した再送要求パケットの数に基づいて前記ウィンドウサイズを修正するステップと、
　を含む方法。」
　
３．対比
　本願発明と引用発明とを対比するに、本願発明の「メッセージ」は、本願明細書に「メッセージは、メッセージ・パケットを喪失した旨の通知をすることなく、宛先ノードで気付かないうちに削除されることもある。」（段落【０００２】）と記載されているように「メッセージ・パケット」を意味しているから引用発明の「データパケット」に相当し、引用発明の「新しいウィンドウサイズ」は通常のウィンドウ制御により送出されるデータパケット数であって本願発明の「送信されるメッセージの数」に相当するから、本願発明と引用発明とは、以下の点で一致ないし相違している。
　
（一致点）
　「マルチノード・データ処理環境においてメッセージを伝送する方法であって、
　現在のネットワーク伝送容量の指標に基づいて、送信するメッセージの数を選択するステップと、
　前記選択された数のメッセージを送信するステップと、
　前記送信されたメッセージの到着の確認応答を受信するステップと、
　前記送信するメッセージの数を修正するステップと、
　を含む方法。」
　
（相違点）
（１）本願発明が「アプリケーションから送信されるメッセージを前記アプリケーションの識別子とともにメッセージ・キューに配置するステップ」を含むのに対し、引用発明はそのようなステップを含まない点。
（２）「送信するメッセージの数を修正するステップ」に関し、本願発明が「受信した確認応答の数を、現在のネットワーク伝送容量の指標に基づいて送信された前記メッセージの数と比較して、受信した確認応答の前記数に基づいて」修正するのに対し、引用発明は「受信した再送要求パケットの数に基づいて」修正する点。
　
４．検討
　そこで、まず、上記相違点（１）につき検討する。
　コンピュータネットワークのようなマルチノード・データ処理環境における慣用の通信プロトコルであるＴＣＰでは、各パケットがアプリケーションの識別子であるポート番号をヘッダ情報として備え、かつ、ノードからの送信時に各パケットが送信バッファにキューイングされることは周知であり、マルチノード・データ処理環境におけるメッセージ（データパケット）を伝送する方法である引用発明の通信プロトコルとして上記ＴＣＰを採用して上記相違点（１）の構成を付加することは当業者であれば容易に想到し得たものである。
　次に、上記相違点（２）につき検討する。
　引用例には明記されていないものの、再送要求パケットは、受信ノードが所定時間内にパケットを受信できなかった場合に送信ノードに送信されるものであることは技術常識である。そして、受信ノードで受信できたパケットについては確認応答である送達確認パケットが送信ノードに返されるのであるから、結局、引用発明の「受信した再送要求パケットの数」は送信されたメッセージの数から所定時間内に受信した確認応答の数を引いた数に等しいことは明白である。つまり、本願発明の「受信した確認応答の数」と引用発明の「受信した再送要求パケットの数」とはいずれも「現在のネットワーク伝送容量の指標」となるものであって、送信するメッセージの数を修正するステップにおいて、「受信した確認応答の数に基づいて」修正する本願発明と「受信した再送要求パケットの数に基づいて」修正する引用発明との間に実質的な差異は無いから、上記相違点（２）は格別の相違とすることはできない。
　
５．むすび
　以上のとおり、本願発明は、上記引用例に記載された発明及び周知慣用技術に基づいて、当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。