【事件の表示】
　特願２０１０−５１９８４４「モバイルデバイスに対するＴＣＰベースのサービス拒否攻撃の遮断方法」拒絶査定不服審判事件〔平成２１年　２月１２日国際公開、ＷＯ２００９／０２０２５５、平成２２年１１月２５日国内公表、特表２０１０−５３６２２１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本件出願は、２００７年９月１４日（パリ条約による優先権主張外国庁受理２００７年８月８日、大韓民国）を国際出願日とする出願であって、平成２４年１月２０日付けで拒絶査定がなされ、これに対し、同年５月２５日に拒絶査定不服の審判請求がなされるとともに同日付けで手続補正がなされたものである。
　
第２．補正却下の決定
［補正却下の決定の結論］
　　平成２４年５月２５日付けの手続補正を却下する。
　
［理由］
１．本願発明と補正後の発明
　平成２４年５月２５日付けの手続補正は、補正前の平成２２年２月２６日付け国際出願翻訳文提出書の特許請求の範囲の請求項１に記載された
「ＴＣＰプロトコルを利用して基地局とモバイルデバイスとの間に伝送されるパケットの流れを確認することによって、サービス拒否（ＤｏＳ）攻撃を遮断するための方法であって、
前記方法は、
前記基地局が前記モバイルデバイスにＴＣＰ接続のための接続要求ＳＹＮパケットを伝送した後、前記モバイルデバイスが前記伝送された接続要求ＳＹＮパケットを受信すると、前記モバイルデバイス側で接続要求確認応答ＳＹＮ／ＡＣＫ＿１パケットを前記基地局に伝送する段階と、
前記伝送された接続要求確認応答ＳＹＮ／ＡＣＫ＿１パケットが受信されると、前記基地局側で前記接続要求確認応答ＳＹＮ／ＡＣＫ＿１パケットに対応する確認応答ＡＣＫ＿２パケットを前記モバイルデバイスに伝送する段階と、
前記モバイルデバイスが前記伝送された確認応答ＡＣＫ＿２パケットを受信すると、前記ＴＣＰ接続を完了する段階と、
前記ＴＣＰ接続が完了した後、前記モバイルデバイスが前記基地局からリセットＲＳＴまたは接続要求ＳＹＮフラグが設定されたパケットを受信すると、前記完了したＴＣＰ接続を終了する段階を含むサービス拒否攻撃の遮断方法。」
　という発明（以下、「本願発明」という。）を、補正後の特許請求の範囲の請求項１に記載された
「ＴＣＰプロトコルを利用して基地局とモバイルデバイスとの間に伝送されるパケットの流れを確認することによって、サービス拒否（ＤｏＳ）攻撃を遮断するための方法であって、
　前記方法は、
　前記基地局が前記モバイルデバイスにＴＣＰ接続のための接続要求ＳＹＮパケットを伝送した後、前記モバイルデバイスが前記伝送された接続要求ＳＹＮパケットを受信すると、前記モバイルデバイス側で接続要求確認応答ＳＹＮ／ＡＣＫ＿１パケットを前記基地局に伝送する第１の段階と、
　前記伝送された接続要求確認応答ＳＹＮ／ＡＣＫ＿１パケットが受信されると、前記基地局側で前記接続要求確認応答ＳＹＮ／ＡＣＫ＿１パケットに対応する確認応答ＡＣＫ＿２パケットを前記モバイルデバイスに伝送する第２の段階と、
　前記モバイルデバイスが前記伝送された確認応答ＡＣＫ＿２パケットを受信すると、前記ＴＣＰ接続を完了する第３の段階と、
　前記ＴＣＰ接続が完了した後、前記モバイルデバイスが前記基地局からリセットＲＳＴまたは接続要求ＳＹＮフラグが設定されたパケットを受信する第４の段階と、
　前記第１乃至第４の段階によって形成されたＴＣＰ接続は不正なＴＣＰ接続であるとして、前記モバイルデバイスは、前記完了したＴＣＰ接続を直ちに終了する段階と、
を含むサービス拒否攻撃の遮断方法。」
　という発明（以下、「補正後の発明」という。）に変更することを含むものである。
　
２．新規事項の有無、補正の目的要件について
　上記補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内において、「（第１乃至第４の段階によって形成された）ＴＣＰ接続」が「不正なＴＣＰ接続であると」する点、及び、「ＴＣＰ接続を終了する」のが「直ちに」である点を付加して限定することにより、特許請求の範囲を減縮するものであるから、本件補正は、特許法第１７条の２第３項(新規事項)及び特許法第１７条の２第５項第２号(補正の目的)の規定に適合している。
　
３．独立特許要件について
　上記補正は特許請求の範囲の減縮を目的とするものを含むから、上記補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。
　
（１）補正後の発明
　上記「１．本願発明と補正後の発明」の項で認定したとおりである。
　
（２）引用発明及び周知技術
Ａ．引用発明
　原査定の拒絶理由に引用されたTRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION, RFC：７９３, １９８１年９月（以下、「引用例」という。）には、図面とともに以下の事項が記載されている。
　
ア．「A connection progresses through a series of states during its lifetime.  The states are:  LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK,  TIME-WAIT, and the fictional state CLOSED.  CLOSED is fictional  because it represents the state when there is no TCB, and therefore, no connection.  Briefly the meanings of the states are:
　
    LISTEN - represents waiting for a connection request from any remote  TCP and port.
　
    SYN-SENT - represents waiting for a matching connection request after having sent a connection request.
　
    SYN-RECEIVED - represents waiting for a confirming connection request acknowledgment after having both received and sent a connection request.
　
    ESTABLISHED - represents an open connection, data received can be delivered to the user. The normal state for the data transfer phase of the connection.
　
　・・・（中略）・・・
　
    CLOSED - represents no connection state at all.
　
A TCP connection progresses from one state to another in response to events.  The events are the user calls, OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS; the incoming segments, particularly those containing the SYN, ACK, RST and FIN flags; and timeouts.
　
The state diagram in figure 6 illustrates only state changes, together with the causing events and resulting actions, but addresses neither error conditions nor actions which are not connected with state changes. In a later section, more detail is offered with respect to the reaction of the TCP to events.
　
NOTE BENE:  this diagram is only a summary and must not be taken as the total specification.
　
　・・・（図省略）・・・
　
                      TCP Connection State Diagram
                               Figure 6.　　　　　　　　　　　　　　　　　　
　
（当審仮訳：
接続はその存在期間中、一連の状態を経て進行する。その状態は、LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, そして仮想的な状態のCLOSEDである。CLOSEDは、転送制御ブロック（TCB）が存在しない状態、従って、接続が無い状態を表すから仮想的なものである。簡潔には、状態の意味は：
　
　LISTEN - 任意のリモートＴＣＰ及びポートからの接続要求の待機を表す。
　
　SYN-SENT - 接続要求を送信した後の対応する接続要求の待機を表す。
　
　SYN-RECEIVED - 接続要求を受信及び送信した後の接続要求確認応答の待機を表す。
　
　ESTABLISHED - 開通した接続を表し、受信したデータはユーザーに配送される。該接続のデータ転送段階の通常状態。
　
　・・・（中略）・・・
　
　CLOSED - 接続が全くない状態を表す。
　
ＴＣＰ接続は、イベントに応答してある状態から他の状態へ進行する。そのイベントは、OPEN, SEND, RECEIVE, CLOSE, ABORT, そして STATUSのユーザーコール、到着するセグメント、特に、SYN, ACK, RST そしてFINフラグを含むもの、そして、タイムアウトである。
　
図６の状態図は、原因となるイベントと結果となる行動とともに、状態変化のみを表すが、エラー状態や状態遷移に関連しない行動は表さない。後のセクションで、イベントに対するＴＣＰの反応について詳述される。
　
注：この図は単なる要約であり、全明細と介されるべきではない。
　
・・・（図省略）・・・
　
　ＴＣＰ状態遷移図
　図６）」（２１−２３頁）　
　
イ．「3.9.  Event Processing
　
The processing depicted in this section is an example of one possible implementation. Other implementations may have slightly different processing sequences, but they should differ from those in this section only in detail, not in substance.
　
The activity of the TCP can be characterized as responding to events. The events that occur can be cast into three categories:  user calls, arriving segments, and timeouts.  This section describes the processing the TCP does in response to each of the events. In many cases the processing required depends on the state of the connection.
　
    Events that occur:
　
      User Calls
　
        OPEN
        SEND
        RECEIVE
        CLOSE
        ABORT
        STATUS
　
      Arriving Segments
　
        SEGMENT ARRIVES
　
      Timeouts
　
        USER TIMEOUT
        RETRANSMISSION TIMEOUT
        TIME-WAIT TIMEOUT
　
（当審仮訳：
３．９　イベント処理
このセクションに記された処理は、一つの可能な実施例である。他の実施例は少し異なる処理シーケンスを持つかもしれないが、そうであるとしても、このセクションに記されたものとは枝葉において異なるだけで、本質的に異なるものでは無い。
　
ＴＣＰの活動は、イベントに対する反応として特徴付けられる。発生するイベントは、３つのカテゴリー：ユーザーコール、到着するセグメント、タイムアウト　に分けられる。このセクションでは、各々のイベントに反応してＴＣＰが行う処理について記述する。多くの場合、必要とされる処理は、接続の状態に依存する。
　
　発生するイベント：
　
　ユーザーコール
　
        OPEN
        SEND
        RECEIVE
        CLOSE
        ABORT
        STATUS
　
　到着するセグメント
　
        SEGMENT ARRIVES
　
　タイムアウト
　
        USER TIMEOUT
        RETRANSMISSION TIMEOUT
        TIME-WAIT TIMEOUT）」（５２頁）
　
ウ．「SEGMENT ARRIVES
　
  SEGMENT ARRIVES
　
    If the state is CLOSED (i.e., TCB does not exist) then
　　・・・（中略）・・・
　
    If the state is LISTEN then
　　・・・（中略）・・・
　
    If the state is SYN-SENT then
　　・・・（中略）・・・
　
    Otherwise,
　
    first check sequence number
　　・・・（中略）・・・
　
    second check the RST bit,
　　・・・（中略）・・・
　
    fourth, check the SYN bit,
　
      SYN-RECEIVED
      ESTABLISHED STATE
      FIN-WAIT STATE-1
      FIN-WAIT STATE-2
      CLOSE-WAIT STATE
      CLOSING STATE
      LAST-ACK STATE
      TIME-WAIT STATE
　
If the SYN is in the window it is an error, send a reset, any outstanding RECEIVEs and SEND should receive reset responses, all segment queues should be flushed, the user should also receive an unsolicited general connection reset signal, enter the CLOSED state, delete the TCB, and return.
　
If the SYN is not in the window this step would not be reached and an ack would have been sent in the first step (sequence number check).
　
（当審仮訳：
セグメントが到着する
　
　セグメントが到着する
　
　もし、状態がCLOSED (即ち、ＴＣＢが存在しない) なら
　・・・（中略）・・・
　
　もし、状態がLISTENなら
　・・・（中略）・・・
　
　もし、状態がSYN-SENTなら
　・・・（中略）・・・
　
　その他の場合
　
　最初にシーケンス番号をチェックする
　・・・（中略）・・・
　
　２番目にＲＳＴビットをチェックする
　・・・（中略）・・・
　
　４番目にＳＹＮビットをチェックする
　
      SYN-RECEIVED
      ESTABLISHED STATE
      FIN-WAIT STATE-1
      FIN-WAIT STATE-2
      CLOSE-WAIT STATE
      CLOSING STATE
      LAST-ACK STATE
      TIME-WAIT STATE
　
もし、そのＳＹＮがウィンドウ内であれば、それはエラーであり、リセットを送信し、いかなる未処理のRECEIVEやSENDも“リセット”の応答を得、全てのセグメントキューはフラッシュされ、ユーザーは、一般的な“接続リセット”信号を送りつけられ、終了状態（CLOSED STATE）に入り、ＴＣＢを消去し、リターンする。
　
もし、そのＳＹＮがウィンドウ内に無ければ、このステップには達せず、まず最初のステップ（シーケンス番号チェック）で、確認応答が送られているであろう。）」（６５−７１頁）
　
　上記引用例の記載及び図面並びにこの分野における技術常識を考慮すると、
ａ．「３．９　イベント処理」（摘記事項イ）のセクションには、ＴＣＰプロトコルにおいて、ユーザーコール、セグメント到着、タイムアウト等の各種イベントが発生した場合の処理方法が記載されているから、
　「ＴＣＰプロトコルにおけるイベント処理方法」が記載されている。
ｂ．図６のＴＣＰ接続状態図（摘記事項ア）は、「リモートＴＣＰ」と「ユーザー」との間のＴＣＰ接続について、セグメントの送受信などのイベントが発生した場合のユーザーの状態遷移を表しており、それによれば、「passive OPEN」時には、「LISTEN」→「SYN RCVD」→「ESTAB」の状態遷移を経てＴＣＰ接続が完了するが、その過程で、次のｂ１．〜ｂ３．の３つの段階からなる周知の３ウェイハンドシェイクが実行されている。
ｂ１．接続要求ＳＹＮセグメントを受信する（rcv SYN）。
ｂ２．接続要求確認応答ＳＹＮ／ＡＣＫセグメントを送信する（snd SYN,ACK）。
ｂ３．確認応答ＡＣＫセグメントを受信し（rcv ACK of SYN）、ＴＣＰ接続完了状態（ＥＳＴＡＢ）に入る。
　ここで、上記ｂ１．の接続要求ＳＹＮセグメントが「リモートＴＣＰ」（摘記事項ア）から「ユーザー」（摘記事項ア）へと送信されたものであることは明らかであるから、結局、上記ｂ１．〜ｂ３．の３つの段階をまとめると以下の処理が実行されるものと認める。
　「リモートＴＣＰがユーザーにＴＣＰ接続のための接続要求ＳＹＮセグメントを伝送した後、前記ユーザーが前記伝送された接続要求ＳＹＮセグメントを受信すると、前記ユーザー側で接続要求確認応答ＳＹＮ／ＡＣＫセグメントを前記リモートＴＣＰに伝送する第１の段階と、
　前記伝送された接続要求確認応答ＳＹＮ／ＡＣＫセグメントが受信されると、前記リモートＴＣＰ側で前記接続要求確認応答ＳＹＮ／ＡＣＫセグメントに対応する確認応答ＡＣＫセグメントを前記ユーザーに伝送する第２の段階と、
　前記ユーザーが前記伝送された確認応答ＡＣＫセグメントを受信すると、前記ＴＣＰ接続を完了する第３の段階」
ｃ．セグメントが到着した際の処理に関し、ＳＹＮビットをチェックして、接続状態がＴＣＰ接続完了状態（ESTABLISHED STATE）の場合、そのＳＹＮセグメントが受信ウィンドウ内であれば、エラーであるから、リセットを送信し、終了状態（CLOSED STATE）に入ることが記載されているが（摘記事項ウ）、
ｃ１．該セグメントの到着がユーザによるセグメントの受信を意味することは明らかであって、上記ｂ１．〜ｂ３．の第１〜第３段階を経てＴＣＰ接続完了状態（ESTABLISHED STATE）になった後の上記受信は第４の段階と言えるから、
　「前記ＴＣＰ接続が完了した後、前記ユーザーが接続要求ＳＹＮフラグが設定されたセグメントを受信する第４の段階」が記載されている。
ｃ２．上記ｃ１．の第４の段階の後、上記ＴＣＰ接続はリセットの送信により終了状態に入るから、
　「前記ユーザーは、リセットを送信して前記完了したＴＣＰ接続を終了する段階」が記載されている。
　
　以上を総合すれば、上記引用例には、以下の発明（以下、「引用発明」という。）が開示されていると認める。
　
「ＴＣＰプロトコルにおけるイベント処理方法であって、
　前記方法は、
　リモートＴＣＰがユーザーにＴＣＰ接続のための接続要求ＳＹＮセグメントを伝送した後、前記ユーザーが前記伝送された接続要求ＳＹＮセグメントを受信すると、前記ユーザー側で接続要求確認応答ＳＹＮ／ＡＣＫセグメントを前記リモートＴＣＰに伝送する第１の段階と、
　前記伝送された接続要求確認応答ＳＹＮ／ＡＣＫセグメントが受信されると、前記リモートＴＣＰ側で前記接続要求確認応答ＳＹＮ／ＡＣＫセグメントに対応する確認応答ＡＣＫセグメントを前記ユーザーに伝送する第２の段階と、
　前記ユーザーが前記伝送された確認応答ＡＣＫセグメントを受信すると、前記ＴＣＰ接続を完了する第３の段階と、
　前記ＴＣＰ接続が完了した後、前記ユーザーが接続要求ＳＹＮフラグが設定されたセグメントを受信する第４の段階と、
　前記ユーザーは、リセットを送信して前記完了したＴＣＰ接続を終了する段階と、
を含む方法。」
　
Ｂ．周知技術
　例えば、特開２００５−１１０２５５号公報（以下、「周知例１」という。）には下記エ．が記載され、また、特開２００５−１２４０５５号公報（以下、「周知例２」という。）には下記オ．が記載されている。
　
エ．「【０００５】
  ＴＣＰサーバ上のある特定のタイプのＤＤｏＳ攻撃は、その限定されたリソースが枯渇されるまで、目標のサーバへの新たなＴＣＰ接続を連続して生成することによって開始されることができ、したがって、正当なユーザからのサービス要求を受けなくさせる。（当業者に良く知られているように、ＴＣＰは、良く知られている標準の伝送制御プロトコルの防御部門である。例えば、Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｃｉｅｎｃｅｓ  ＩｎｓｔｉｔｕｔｅによるＤｅｆｅｎｃｅ  Ａｄｖａｎｃｅｄ  Ｒｅｓｅａｒｃｈ  Ｐｒｏｊｅｃｔｓ  Ａｇｅｎｃｙに関して準備された「Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｏｒｏｌ  Ｐｒｏｔｏｃｏｌ」、Ｊ．Ｐｏｓｔｅｌ、ｅｄｉｔｏｒ、Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ（ＲＦＣ）７９３、１９８１年９月、「ｗｗｗ．ｆａｑｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃ７９３．ｈｔｍｌ」を参照されたい。ＲＦＣ７９３は、本明細書に完全に示されるように、参照によって本明細書に組み込まれる。）特に、そのような攻撃は、「ＳＹＮ攻撃」として知られる。なぜなら、それらは、新たなＴＣＰ接続を開始させるように送られる、膨大な初期ＳＹＮパケットのほんのフラリからなるからである。（ＳＹＮパケットは、当業者には完全に知られている接続要求パケットである。それらは、例えば、上記に参照されたＲＦＣ７９３のＴＣＰ標準に定義されかつ説明される。）
【０００６】
  より詳細には、当業者には良く知られているように、各ＴＣＰ接続は、ＳＹＮパケットで開始する。ＴＣＰサーバは、各有効なＳＹＮ要求にＳＹＮ、ＡＣＫで応答しなければならず、必要であれば再送信しなければならない。（ＡＣＫパケットは、当業者には完全に知られ、同様にＲＦＣ７９３で定義されかつ説明される承認パケットである。）ＳＹＮパケットは、パケットにおける前の状態なしに、一時的なファイアウオールを貫通する。ＳＹＮパケットは、また、サーバおよびファイアウオールを、新たな接続に関する準備でリソースを割り当てさせる。結果として、それらは、サービス拒否攻撃を開始する第１の可能性があるビークルである。
【特許文献１】特許仮出願第６０／４９７８８６号
【非特許文献１】Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｃｉｅｎｃｅｓ  ＩｎｓｔｉｔｕｔｅによるＤｅｆｅｎｓｅ  Ａｄｖａｎｃｅｄ  Ｒｅｓｅａｒｃｈ  Ｐｒｏｊｅｃｔｓ  Ａｇｅｎｃｙに関して準備された「Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ」、Ｊ．Ｐｏｓｔｅｌ、ｅｄｉｔｏｒ、Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ（ＲＦＣ）７９３、１９８１年９月、「ｗｗｗ．ｆａｒｓ．ｏｒｇ／ｒｆｃｓ／ｅｒｃ７９３．ｈｔｍｌ」
【発明の開示】
【発明が解決しようとする課題】
【０００７】
  実際、２つの異なる形態のＳＹＮ攻撃が存在する。ＳＹＮ状態攻撃とＳＹＮ帯域幅攻撃である。ＳＹＮ状態攻撃は、ハンドシェークの残りを完了することなく、接続要求ＳＹＮパケットを送ることによってＴＣＰサーバを圧倒しようとし、サーバ上の「バックログ・キュー」を最終的にはオーバフローさせ、それによってサービス拒否を正当な要求にする。（当業者には良く知られているように、ＴＣＰ接続は、３方向ハンドシェークを介して確立され、不完全な接続は、一般にパー・リスナ・キューに保持される。バックログ・キューの制限は、通常はむしろ小さい。）しかしながら、ＴＣＰサーバが、自身によってＳＹＮ状態攻撃に対して防御することを可能にする少なくとも２つの解決方法が存在し、１つの解決方法は、不完全な接続に使用されるメモリ量を低減することであり、他方の解決方法は、任意のメモリ使用を完全に排除することである。
【０００８】
  しかしながら、他の形態のＳＹＮ攻撃は、ＳＹＮ帯域幅攻撃である。ＳＹＮ帯域幅攻撃は、「下流側」（すなわち、攻撃下のＴＣＰサーバで）で扱うのがより困難である。一般的なＳＹＮパケットは、ただ６４バイト長であるにすぎないことに留意されたい。そのような最小サイズのパケットのバーストは、したがって、サーバ上でライブロックを引き起こす。（当業者には良く知られているように、「ライブロック」は、２つ以上のプロセスが、あらゆる有用な動作を行うことなく、他の１つまたは複数のプロセスにおける変化に応答してそれらの状態を連続して変化させるとき発生する状況である。）すなわち、デッドリー攻撃は、単にサーバのイングレス・リンクに多くのそのような小さなパケットでブラスティングすることからなり得る。多くの最適化が、受信器ライブロックを避けるために存在するが、一般に、帯域幅攻撃は、現在まで、さらに「上流側」だけで、すなわち損傷がサーバになされる前だけで扱われた。」（周知例１、４〜５頁）
　
オ．「【背景技術】
【０００２】
  正常なＴＣＰ（Transmission Control Protocol）の通信手順を図１４を参照して説明する。ネットワーク４を介してサーバ２とクライアント３とが接続されている。このときに、クライアント３からサーバ２に対してＳＹＮパケットが送出されるとサーバ２からクライアント３に対してＳＹＮ−ＡＣＫパケットが返送される。これにより、クライアント３とサーバ２とは通信可能な状態となる。
【０００３】
  次に、ＳＹＮ攻撃と呼ばれるサーバのサービスを不能にさせる攻撃を図１５を参照して説明する。図１５に示すように、攻撃の特徴は、悪意のあるクライアント３は、ＳＹＮパケットをサーバ２に送り続け、正常な通信をしようとした正しい通信を妨げる。さらに、攻撃者は、自分のＩＰアドレスを詐称する場合がある。このとき、サーバ２はＳＹＮ−ＡＣＫパケットをＳＹＮパケットを送信した悪意のあるクライアント３ではなく、詐称されたクライアントに送ることになる。詐称されたクライアントでは、自己が送出していないＳＹＮパケットに対するＳＹＮ−ＡＣＫパケットの返送が繰り返し行われるので、自己が要求するＳＹＮパケットを送出することができなくなるという異常事態に陥る。
【０００４】
  このような攻撃に対する従来の防御装置を図１６を参照して説明する。従来のＳＹＮ攻撃に対する防御装置１１は、攻撃ＳＹＮパケットと正常なＳＹＮパケットとを区別せず、ＳＹＮパケットの伝送レートを測定し、設定された閾値以上の伝送レートのＳＹＮパケットを全て廃棄していた（例えば、非特許文献１参照）。
【非特許文献１】“ＤＤｏＳ攻撃の防御対策について”、［ｏｎｌｉｎｅ］、平成１５年６月３日、警察庁技術対策課サイバーテロ対策技術室、［平成１５年１０月７日検索］、インターネット、＜ＵＲＬ：http://www.cyberpolice.go.jp/server/virus/pdf/Strategies_to_Protect_Against_DDoS_Attacks.pdf＞」（周知例２、４〜５頁）
　
　
　上記周知例１，２に記載されているように、ＴＣＰプロトコルを用いた通信システムにおいて、
　「ＳＹＮパケットを攻撃対象装置に送信するＳＹＮ攻撃」
　は周知のＤｏＳ（Denial of Service：サービス拒否）攻撃である。
　
（３）対比・判断
　補正後の発明と引用発明とを対比すると、
ａ．引用発明の「ＴＣＰプロトコルにおけるイベント処理方法」と補正後の発明の「ＴＣＰプロトコルを利用して基地局とモバイルデバイスとの間に伝送されるパケットの流れを確認することによって、サービス拒否（ＤｏＳ）攻撃を遮断するための方法」とは、「ＴＣＰプロトコルにおける方法」である点で共通する。
ｂ．引用発明では、「リモートＴＣＰ」と「ユーザー」は、「リモートＴＣＰ」からの接続要求でＴＣＰ接続し、補正後の発明では、「基地局」と「モバイルデバイス」は、「基地局」からの接続要求でＴＣＰ接続するから、引用発明の「リモートＴＣＰ」、「ユーザー」は、それぞれ、補正後の発明の「基地局」、「モバイルデバイス」に対応するが、
　補正後の発明の「モバイルデバイス」が「ユーザー」によって利用されるものであることは明らかであるから、引用発明の「ユーザー」と補正後の発明の「モバイルデバイス」は、ＴＣＰ接続に関して、「ユーザー側」である点で共通し、
　補正後の発明の「基地局」が「ユーザー側」からみて「リモート」なデバイスであると言えるから、引用発明の「リモートＴＣＰ」と補正後の発明の「基地局」は、ＴＣＰ接続に関して、「リモート側」である点で共通する。
ｃ．引用発明の「セグメント」がパケット化されたデータであることは明らかであって、補正後の発明の「パケット」に相当するから、引用発明の「接続要求ＳＹＮセグメント」、「接続要求確認応答ＳＹＮ／ＡＣＫセグメント」、「確認応答ＡＣＫセグメント」、「接続要求ＳＹＮフラグが設定されたセグメント」は、それぞれ、補正後の発明の「接続要求ＳＹＮパケット」、「接続要求確認応答ＳＹＮ／ＡＣＫ＿１パケット」、「確認応答ＡＣＫ＿
２パケット」、「接続要求ＳＹＮフラグが設定されたパケット」に相当する。
ｄ．引用発明の「前記ユーザーは、リセットを送信して前記完了したＴＣＰ接続を終了する段階」と補正後の発明の「前記第１乃至第４の段階によって形成されたＴＣＰ接続は不正なＴＣＰ接続であるとして、前記モバイルデバイスは、前記完了したＴＣＰ接続を直ちに終了する段階」は、「前記ユーザー側は、前記完了したＴＣＰ接続を終了する」点で共通する。
ｅ．引用発明の「方法」と補正後の発明の「サービス拒否攻撃の遮断方法」は「方法」である点で共通する。
　
　以上をまとめると、両者は、以下の点で一致ないし相違している。
　
（一致点）
「ＴＣＰプロトコルにおける方法であって、
　前記方法は、
　リモート側がユーザー側にＴＣＰ接続のための接続要求ＳＹＮパケットを伝送した後、前記ユーザー側が前記伝送された接続要求ＳＹＮパケットを受信すると、前記ユーザー側で接続要求確認応答ＳＹＮ／ＡＣＫ＿１パケットを前記リモート側に伝送する第１の段階と、
　前記伝送された接続要求確認応答ＳＹＮ／ＡＣＫ＿１パケットが受信されると、前記リモート側で前記接続要求確認応答ＳＹＮ／ＡＣＫ＿１パケットに対応する確認応答ＡＣＫ＿２パケットを前記ユーザー側に伝送する第２の段階と、
　前記ユーザー側が前記伝送された確認応答ＡＣＫ＿２パケットを受信すると、前記ＴＣＰ接続を完了する第３の段階と、
　前記ＴＣＰ接続が完了した後、前記ユーザー側が前記リモート側から接続要求ＳＹＮフラグが設定されたパケットを受信する第４の段階と、
　前記ユーザー側は、前記完了したＴＣＰ接続を終了する段階と、
を含む方法。」
　
（相違点１）
　「ＴＣＰプロトコルにおける方法」が、
　補正後の発明では、「ＴＣＰプロトコルを利用して基地局とモバイルデバイスとの間に伝送されるパケットの流れを確認することによって、サービス拒否（ＤｏＳ）攻撃を遮断するための方法であって」「サービス拒否攻撃の遮断方法」であるのに対し、
　引用発明では、「ＴＣＰプロトコルにおけるイベント処理方法」である点
　
（相違点２）
　「リモート側」、「ユーザー側」が、
　補正後の発明では、それぞれ、「基地局」、「モバイルデバイス」であるのに対し、
　引用発明では、それぞれ、「リモートＴＣＰ」、「ユーザー」である点。
　
（相違点３）
　「完了したＴＣＰ接続を終了する段階」において、
　補正後の発明では、「前記第１乃至第４の段階によって形成されたＴＣＰ接続は不正なＴＣＰ接続であるとして、前記モバイルデバイスは、前記完了したＴＣＰ接続を直ちに終了する」のに対し、
　引用発明では「前記ユーザーは、リセットを送信して前記完了したＴＣＰ接続を終了する」点。
　
　以下に、上記各相違点につき検討する。
　
　まず、（相違点２）について検討する。
　ＴＣＰプロトコルは、基地局とモバイルデバイス間の無線通信においても普通に利用されているプロトコルに過ぎないから、引用発明において、ＴＣＰ接続される「リモートＴＣＰ」、「ユーザー」を、それぞれ、補正後の発明の「基地局」、「モバイルデバイス」とすることは、当業者が適宜なし得ることである。
　
　次に、（相違点１）及び（相違点３）についてまとめて検討する。
　まず、上記「（２）引用発明及び周知技術」項中の「Ｂ．周知技術」の項に記したように、ＴＣＰプロトコルを用いた通信システムにおいて、「ＳＹＮパケットを攻撃対象装置に送信するＳＹＮ攻撃」は周知のＤｏＳ攻撃である。
　引用例にはＤｏＳ攻撃やＳＹＮ攻撃に関しての記載は無いものの、上記ＳＹＮ攻撃の周知性に鑑みれば、リセットを送信する原因となるＳＹＮセグメントを受信する引用発明に接した当業者であれば、該ＳＹＮセグメントの受信からＳＹＮ攻撃（ＤｏＳ攻撃）の発生の可能性は容易に想起し得るものである。
　そして、引用発明の第４段階におけるＳＹＮセグメントの受信が、その前の第１〜第３段階で形成されたＴＣＰ接続で用いられるものと同じＴＣＰソケット（ＩＰアドレス及びポート番号）で行われていることは明らかであることから、上記第４段階におけるＳＹＮセグメントの受信が「不正な」ＳＹＮ攻撃であるとした場合、その前の第１〜第３段階で完了されたＴＣＰ接続自体も「不正な」ものと判断することは当業者であれば容易になし得るものである。
　さらに、このような「不正な」接続をできる限り早期に遮断すべきであることは当然であるから、引用発明の前記完了したＴＣＰ接続の終了を「直ちに」行うことは当業者が当然成すべきことに過ぎない。
　とすると、
　「完了したＴＣＰ接続を終了する段階」において、補正後の発明のように、「前記第１乃至第４の段階によって形成されたＴＣＰ接続は不正なＴＣＰ接続であるとして、前記モバイルデバイスは、前記完了したＴＣＰ接続を直ちに終了する」こと（相違点３）は、上記周知技術に基づいて当業者が容易に想到し得たものである。
　また、このようなＴＣＰ接続を終了する処理は、「サービス拒否攻撃の遮断方法」と言い得るものであって、引用発明のように、第４段階におけるＳＹＮセグメントの受信に応じて当該「遮断」を行うとき、上記「サービス拒否攻撃の遮断方法」は、「ＴＣＰプロトコルを利用して基地局とモバイルデバイスとの間に伝送されるパケットの流れを確認することによって、サービス拒否（ＤｏＳ）攻撃を遮断するための方法」と言い得るものであるから、上記（相違点１）も格別なものではない。
　
　そして、補正後の発明の作用・効果も引用発明及び周知技術から当業者が予測し得る範囲のものである。
　
４．結語
　以上のとおり、本件補正は、補正後の発明が特許出願の際独立して特許を受けることができないものであるから、特許法第１７条の２第６項において準用する特許法第１２６条第７項の規定に適合していない。
　したがって、本件補正は、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
１．本願発明
　平成２４年５月２５日付けの手続補正は上記のとおり却下されたので、本願発明は上記「第２．補正却下の決定」の項中の「１．本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。
　
２．引用発明
　引用発明は、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項中の「（２）引用発明及び周知技術」の項で認定したとおりである。
　
３．対比・判断
　そこで、本願発明と引用発明とを対比するに、
　本願発明は上記補正後の発明から当該補正に係る限定を省いたものである。
　そうすると、本願発明の構成に当該補正に係る限定を付加した補正後の発明が、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項で検討したとおり、引用発明および周知技術に基づいて当業者が容易に発明できたものであるから、本願発明も同様の理由により、容易に発明できたものである。
　
４．むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。