【事件の表示】
　特願２００５−　２９５３７「ＴＣＰコネクション管理装置、ＴＣＰコネクション管理方法及びプログラム保存装置」拒絶査定不服審判事件〔平成１７年　８月２５日出願公開、特開２００５−２２８３１６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１７年２月４日（パリ条約に基づく優先権主張２００４年２月１３日、大韓民国）の出願であって、平成２０年４月２３日付けで拒絶査定がなされ、これに対し、平成２０年８月４日に拒絶査定不服審判が請求されたものである。
　
２．本願発明
　本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２０年４月７日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
　「【請求項１】
　任意の二つのアプリケーションの間に設定されたＴＣＰコネクションを管理する装置であって、
　前記ＴＣＰコネクションの設定情報及び前記ＴＣＰコネクションについてのＴＣＰセッションコネクティビティチェックのための設定値を保存しておき、当該設定情報及び設定値に従って前記ＴＣＰコネクションの連結状態を感知するためのパケットであるＳＣＣメッセージを生成して相手側のＴＣＰ/ＩＰカーネルに送信すると共に、この相手側のＴＣＰ/ＩＰカーネルからの前記ＳＣＣメッセージに対する応答であるＳＣＣ応答メッセージの受信の有無に基づいて前記ＴＣＰコネクションが正常に動作しているか否かを判定するＴＣＰ/ＩＰカーネルを含むこと
　を特徴とするＴＣＰコネクション管理装置。」　
　
３．刊行物
　
刊行物１．Douglas E. Comer, et al.,“Probing TCP Implementations”, Proceedings of the USENIX Summer 1994 Technical Conference, Volume 1, USENIX Association,  (1994), pp.245-255
　
刊行物２．竹内章平 他, 「１０のポイントで学ぶインターネット基礎技術」, 株式会社エクシードプレス（株式会社ビー・エヌ・エヌ発売）, ２０００年１１月１５日, ｐｐ．９０−９３、９８−１０１
　
３−１．刊行物１の記載
　原査定の拒絶の理由に引用された刊行物１には、図面と共に、以下の事項が記載されている。
　
（ア）第３節（第２４９頁右欄第１９行から第２５０頁第３行）
  Some TCP implementations include a mechanism that tests an idle connection and releases it if the remote host has crashed. Called TCP keep-alive, the mechanism periodically sends a probe segment to elicit response from the peer. If the peer responds to the probe by sending an ACK, the connection is alive. If the peer TCP fails to respond to probe segments for longer than a fixed threshold, the connection is declared down and the connection is closed.
  According to RFC-1122, a TCP implementation may include the keep-alive mechanism. However, if TCP keep-alive is included, the applications must be able to turn it on or off in a per connection basis, and by default, it must be off. The threshold interval to send TCP keep-alives must be configurable and must default to 7,200 seconds (two hours) or more. Because TCP does not reliably transmit ACK segments that carry no data, an ACK segment in response to the keep-alive probe may be lost. Therefore, a TCP should drop the connection only after a predefined number of keep-alive probes fail to elicit response from the peer.
　
〈当審和訳〉
　あるTCPの実装では、アイドル・コネクションをテストしリモート・ホストがクラッシュした場合にそれ（当審注：アイドル・コネクション）を解放するメカニズムを含んでいる。TCP keep-aliveと呼ばれるそのメカニズムは、定期的にプローブ・セグメントを送り、通信相手からの応答を引き出す。もし通信相手がACKを送ることによってプローブに応答したならば、コネクションは生きている。もし通信相手のTCPが一定のしきい値よりも長い間プローブ・セグメントに応答できなかったならば、コネクションはダウンしたと宣言されてコネクションは閉じられる。
　RFC-1122によれば、TCPの実装はkeep-aliveメカニズムを含んでもよい。しかしながら、もしTCP keep-aliveが含まれるならば、アプリケーションはそれ（当審注：TCP keep-alive）をコネクション毎にオンオフできなければならず、かつ、初期状態ではオフでなければならない。TCP keep-aliveを送る間隔のしきい値は、設定で変えられなければならず、かつ、初期設定は７２００秒（２時間）以上でなければならない。
　
　以上の刊行物１の記載によれば、刊行物１には、次の発明（以下、「刊行物１記載発明」という。）が記載されていると認められる。
　
　「アイドル・コネクションをテストしリモート・ホストがクラッシュした場合にアイドル・コネクションを解放するメカニズムを含むTCPの実装であって、
　そのメカニズムはTCP keep-aliveと呼ばれ、定期的にプローブ・セグメントを送り、通信相手からの応答を引き出し、
　もし通信相手がACKを送ることによってプローブに応答したならば、コネクションは生きているとし、
　もし通信相手のTCPが一定のしきい値よりも長い間プローブ・セグメントに応答できなかったならば、コネクションはダウンしたと宣言されてコネクションは閉じられ、
　アプリケーションはTCP keep-aliveをコネクション毎にオンオフできなければならず、
　TCP keep-aliveを送る間隔のしきい値は、設定で変えられなければならない、
TCPの実装。」
　
４．対比
　本願発明と刊行物１記載発明とを以下で対比する。
　
　刊行物１記載発明はTCPの実装に関するものであるから、刊行物１記載発明の「コネクション」は、本願発明の「TCPコネクション」に相当する。
　
　刊行物１記載発明は、通信相手とTCPにてプローブ・セグメントとACKとをやりとりすることによってアイドル・コネクションをテストし、コネクションが生きているかダウンしたかを判断してコネクションを閉じるものであるから、刊行物１記載発明と本願発明とは、「ＴＣＰコネクションを管理する装置」である点、及び、「前記ＴＣＰコネクションの連結状態を感知するためのパケットであるメッセージを生成して相手側に送信すると共に、この相手側からの前記メッセージに対する応答である応答メッセージの受信の有無に基づいて前記ＴＣＰコネクションが正常に動作しているか否かを判定する手段」を含む点で一致する。
　
　刊行物１記載発明のTCP keep-aliveは、上述したTCPコネクションを管理するためのメカニズムであり、刊行物１記載発明では、TCP keep-aliveをコネクション毎にオンオフできなければならないから、刊行物１記載発明では、TCP keep-aliveがオンなのかオフなのかをコネクション毎に記憶しておく必要がある。
　してみると、刊行物１記載発明と本願発明とは「前記ＴＣＰコネクションについてのＴＣＰセッションコネクティビティチェックのための設定値を保存」しておく点、及び、「当該設定値に従って前記ＴＣＰコネクションの連結状態を感知するためのパケットであるメッセージを生成して相手側に送信する」点で一致する。
　
　すると、本願発明と刊行物１記載発明との一致点及び相違点は、以下のとおりである。
　
〈一致点〉
　「ＴＣＰコネクションを管理する装置であって、
　前記ＴＣＰコネクションについてのＴＣＰセッションコネクティビティチェックのための設定値を保存しておき、当該設定値に従って前記ＴＣＰコネクションの連結状態を感知するためのパケットであるメッセージを生成して相手側に送信すると共に、この相手側からの前記メッセージに対する応答である応答メッセージの受信の有無に基づいて前記ＴＣＰコネクションが正常に動作しているか否かを判定する手段を含むこと
　を特徴とするＴＣＰコネクション管理装置。」である点。
　
〈相違点１〉
　本願発明の「ＴＣＰコネクション」は「任意の二つのアプリケーションの間に設定された」ものであるのに対し、刊行物１記載発明のコネクションは、任意の二つのアプリケーションの間に設定されたものか否かが明らかではない点。
　
〈相違点２〉
　本願発明では、「ＴＣＰコネクションの設定情報」を設定値と共に保存しておき、メッセージを生成して相手側に送信する動作を当該「ＴＣＰコネクションの設定情報」と設定値とに基づいて行っているのに対し、刊行物１記載発明では、「ＴＣＰコネクションの設定情報」を保存しているか否かが明らかでなく、メッセージの送信に際して設定情報が用いられているかも明らかでない点。
　
〈相違点３〉
　本願発明では、ＴＣＰコネクションの連結状態を感知するためのパケットが「ＳＣＣメッセージ」であり、その応答が「ＳＣＣ応答メッセージ」であるのに対し、刊行物１記載発明では、ＴＣＰコネクションの連結状態を感知するためのパケットが「プローブ・セグメント」であって「ＳＣＣメッセージ」ではなく、その応答は単なるＡＣＫであって「ＳＣＣ応答メッセージ」ではない点。
　
〈相違点４〉
　本願発明では、メッセージの送信先及び応答メッセージの送信元が「ＴＣＰ／ＩＰカーネル」であるのに対し、刊行物１記載発明では、メッセージの送信先及び応答メッセージの送信元が「ＴＣＰ／ＩＰカーネル」であるか否かが明らかではない点。
　
　
５．判断
　
５−１．相違点１について
　ＴＣＰはトランスポート層のプロトコルであり、上位のアプリケーション層に位置するアプリケーションプログラムからポートを介して使われるものである（例えば刊行物２第９２頁図５−１を参照）から、ＴＣＰコネクションを任意の二つのアプリケーションの間に設定するよう構成することは、当業者が容易になし得ることである。
　
５−２．相違点２について
　ＴＣＰコネクションは、ローカルホスト上のアプリケーションとリモートホスト上のアプリケーションとを１対１に関係づけたものである（刊行物２第９１頁表５−１の「通信サービスの管理」を参照）から、ＴＣＰコネクションを管理する上では、ローカルホスト上のアプリケーションとリモートホスト上のアプリケーションとを対応付けて保存しておく必要があり、かつ、コネクション毎にＭＳＳも異なる（刊行物２第９９頁「まめ知識」参照）から、コネクション毎にＭＳＳを保存しておく必要がある。
　ローカルホスト上のアプリケーションとリモートホスト上のアプリケーションとの対応付けや、ＭＳＳ等は、ＴＣＰコネクションの設定情報に他ならず、実際にＴＣＰで通信を行うときに用いる情報であるから、刊行物１記載発明において、「ＴＣＰコネクションの設定情報」を保存しておき、該設定情報に従ってメッセージを生成して相手側に送信するように構成することは、当然になすべきことである。
　
５−３．相違点３について
　刊行物１記載発明は、アイドル・コネクションをテストするものであって、プローブ・セグメントを送りそれに対するＡＣＫの有無によって、コネクションが生きているか否かを判定するものである。
　そして、本願発明の「ＳＣＣメッセージ」はＴＣＰコネクションの連結状態を感知するためのパケットであり、ＳＣＣメッセージの送信に対する応答としての「ＳＣＣ応答メッセージ」の有無によってＴＣＰコネクションが正常に動作しているか否かを判定するものである。
　してみると、刊行物１記載発明のプローブ・セグメント及びそれに対するＡＣＫは、本願発明のＳＣＣメッセージ及びＳＣＣ応答メッセージと機能的に変わることがない。
　
　この点について、審判請求人は「これに対し、本願発明は、明細書に詳しく説明されている通り、アプリケーション間のＴＣＰセッションの確認可否を、アプリケーション間ではないＴＣＰカーネル間で処理し、これによりＴＣＰセッション状態を確認するメッセージ（パケット）量を減少するものであります。」「これに対し本願発明では、Ａ、ＢアプリケーションのＴＣＰカーネル（Ａ）と、Ｃ、ＤアプリケーションのＴＣＰカーネル（Ｂ）との間で２つメッセージのみを交換すればよいので、大幅にメッセージ送受信量を減少させることができ、これによりオーバーヘッドを大幅に低減できるという格別の効果を得ることができます。拒絶査定の理由では、周知文献１を挙げて、通信相手（ピア）を監視することとコネクションの状態を監視することは等価であると認定されておりますが、本願発明と引用文献１の発明には効果の面に大幅な差異があります。」と意見を述べている（いずれも審判請求書）。
　そこで、審判請求人の上記意見について検討する。
　本願発明のＳＣＣメッセージ及びＳＣＣ応答メッセージは、明細書及び図面を参照すると、ＴＣＰパケットのヘッダー部における６ビットの予約フィールドの中の１ビットをＳＣＣフラッグとして使用し（第００７０段落）、このＳＣＣフラッグをオンにしたパケットのことである（第００７１段落及び図１２）と認められる。
　してみると、このＳＣＣメッセージ及びＳＣＣ応答メッセージは、ＴＣＰヘッダの予約フィールドのうちの１ビットをオンにした以外は、通常のＴＣＰパケットと変わることがない。
　そうであれば、ＴＣＰのコネクションは、ローカルホスト上のアプリケーションとリモートホスト上のアプリケーションを１対１に関連づけているものであるのだから（例えば刊行物２第９１頁表５−１「通信サービスの管理」参照）、ＳＣＣメッセージ及びＳＣＣ応答メッセージであっても、通常のＴＣＰパケットと同様に、設立されているコネクションの数、すなわち、ローカルホスト上のアプリケーションとリモートホスト上のアプリケーションとを対応付けたその対応付けの数に応じた量のパケットが伝送されることになる。
　してみると、ＳＣＣメッセージ及びＳＣＣ応答メッセージを用いた場合のパケット量は、TCP keep-aliveメカニズムによるパケット量と変わることがなく、審判請求人の「これに対し本願発明では、Ａ、ＢアプリケーションのＴＣＰカーネル（Ａ）と、Ｃ、ＤアプリケーションのＴＣＰカーネル（Ｂ）との間で２つメッセージのみを交換すればよい」との説明は合理的ではない。
　
　以上のとおり、ＳＣＣメッセージ及びＳＣＣ応答メッセージは、ＴＣＰパケットヘッダの予約フィールドの中の１ビットをオンにしたに過ぎず、本質的にTCP keep-aliveメカニズムと変わらないものであるから、刊行物１記載発明のTCP keep-aliveメカニズムで用いられるプローブ・セグメント及びそれに対するＡＣＫに対して、ＴＣＰパケットヘッダの予約フィールドの中の１ビットをオンしたものとするよう変更することは、単なる設計的事項に過ぎず、当業者であれば容易になし得ることである。
　
５−４．相違点４について
　ＴＣＰの通信を担うソフトウェアとしてＴＣＰ／ＩＰカーネルを用いることは一般的に行われていることであるから、ＴＣＰの実装である刊行物１記載発明のメッセージの送信先及び応答メッセージの送信元を「ＴＣＰ／ＩＰカーネル」とすることは、容易になし得ることである。
　
５−５．本願発明の効果について
　本願発明の全体を総合してみても、その効果は、刊行物１記載発明及び周知技術から予測される範囲内のものにすぎず、格別顕著なものということはできない。
　
　
６．むすび
　以上のとおり、本願発明は、刊行物１記載発明及び周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条２項の規定により特許を受けることができない。
　したがって、その余の請求項について論及するまでもなく、本願は、拒絶すべきものである。
　
　よって、結論のとおり審決する。