【事件の表示】
　特願２０１０−２２７２５２「ネットワーク・トラフィックのセキュリティのための方法およびシステム」拒絶査定不服審判事件〔平成２３年　３月３１日出願公開、特開２０１１−　６５６５３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
［１］手続の経緯
　
　本願は、平成１７年９月８日（パリ条約による優先権主張、平成１６年９月９日、アメリカ合衆国）を国際出願日とする特願２００７−５３１４３５号の一部を、平成２２年１０月７日（パリ条約による優先権主張　平成１６年９月９日、アメリカ合衆国）に新たな特許出願としたものであって、平成２４年９月２０日付けで拒絶理由通知がなされ、平成２５年３月２２日に意見書とともに手続補正書が提出されたが、同年９月２日付けで拒絶査定がなされ、これに対し、同年１２月２７日に拒絶査定不服審判の請求がなされるとともに手続補正書が提出されたものである。
　
　
　
［２］特許法第３６条第６項第１号および第２号に規定される要件違反（以下、それぞれの要件を「サポート要件」，「明確性要件」と呼ぶ）に関する審査の経緯と審判請求人の主張
　
（１）平成２４年９月２０日付け拒絶理由通知（以下、単に「拒絶理由通知」という）の対象となった特許請求の範囲
　拒絶理由通知の対象となった特許請求の範囲の記載は、出願当初の特許請求の範囲の欄に記載されたとおりであり、そのうち、請求項１の記載は、以下のとおりである　
「【請求項１】
  ａ．ネットワーク内のトラフィックを使用することによってユーザを自動的に発見するステップと、
  ｂ．前記ユーザに関連するアプリケーションのパフォーマンスを監視するステップと、
  ｃ．前記アプリケーションのパフォーマンスを査定するステップと、
  ｄ．前記トラフィックを制御するステップとを備える、方法。」
　
（２）拒絶理由通知における指摘事項
　
（２-１）サポート要件違反の指摘事項
　拒絶理由通知におけるサポート要件違反の指摘は、拒絶の理由２として指摘されており、
　「２．特許法第３６条第６項第１号に関して
　この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。」というものであり、そのうちの請求項１についての具体的指摘内容は、以下のとおりである。
　
　「【請求項１】には「ユーザを自動的に発見するステップ」が記載されているが、発明の詳細な説明のどの部分に対応するのか明らかでない。
　なお、【００２０】等には「トラフィックを観察し、ネットワークのユーザを監視」することは記載されているが、当該ユーザを「自動的に発見する」ことについては記載されていない。
　よって、【請求項１】に係る発明は、発明の詳細な説明に記載したものでない。」
　
（２-２）明確性要件違反の指摘事項
　拒絶理由通知における明確性要件違反の指摘は、（特許法第３６条第４項第１号に規定される要件違反とともに）拒絶の理由３として指摘されており、
　「３．特許法第３６条第４項第１号及び第６項第２号に関して
　特許請求の範囲及び発明の詳細な説明の記載が下記の点で、特許法第３６条第４項第１号及び第６項第２号に規定する要件を満たしていない。」というものであり、そのうちの請求項１についての具体的指摘内容は、以下のとおりである。
　
　「（１）ユーザを自動的に発見するステップに関して
　【請求項１】の「ユーザを自動的に発見するステップ」の内容が不明確である。また、発明の詳細な説明を見ても当該ステップの内容が不明確である。
　したがって、【請求項１】の上記ステップは不明確であり、特許法第３６条第４項第１号及び第６項第２号の要件を満たさない。」
　「なお、【００２０】等には「トラフィックを観察し、ネットワークのユーザを監視」と記載されているが、発明の詳細な説明の記載を総合的に参酌すると、ユーザ自信の挙動を監視するのではなく、単に、ユーザが使用しているアプリケーションのトラフィックを監視しているように思われる。」
　
　「（２）パフォーマンスを査定するステップに関して
　【請求項１】には「アプリケーションのパフォーマンスを監視する」ことと、「アプリケーションのパフォーマンスを査定する」ことが記載されているが、「アプリケーションのパフォーマンスを査定」するという処理が何を意味しているのか不明確である。特に、「パフォーマンスを査定」が「パフォーマンスの監視」とどのように異なるのか不明確である。
　したがって、【請求項１】の「アプリケーションのパフォーマンスを査定するステップ」は不明確であり、特許法第３６条第６項第２号の要件を満たさない。」
　
（３）上記（２）の指摘を受けての出願人（審判請求人）の応答
　
　上記（２）の指摘を受け出願人（審判請求人）は、平成２５年３月２２日付け手続補正書により、特許請求の範囲を補正した。補正した請求項１は以下のとおりである（下線は補正箇所を示すもので、出願人が付与したもの。）。
　
「　【請求項１】
　ａ．
ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかを決定するために前記
　ｂ．
監視されたパフォーマンスを得るために、
　ｃ．
前記監視されたパフォーマンスを履歴パフォーマンスと比較することによって、
　ｄ．
前記パフォーマンスの査定に基づいて
　
　そして、平成２５年３月２２日付けの意見書において、次のように主張した。
　
　「審査官殿がご指摘の独立形式の請求項１における「ユーザを自動的に発見する」ことに関し、出願人は、如何にしてユーザを発見するかを明確にするよう、請求項１を補正致しました。さらに、審査官殿がご指摘の請求項１における「パフォーマンスを査定する」ことに関し、出願人は、如何にしてパフォーマンスが査定されるか、そして、如何に査定されたパフォーマンスが監視されたパフォーマンスと関連するかを明確するよう、請求項１を補正致しました。上記補正は、例えば、当初明細書［００４６］乃至［００５２］等に記載されています。」
　
（４）サポート要件違反及び明確性要件違反に関する原査定の理由
　原査定の理由は、「平成２４年９月２０日付け拒絶理由通知書に記載した理由１−３によって、拒絶をすべきものです。」とするものであり、すなわち、依然として、平成２４年９月２０日付け拒絶理由通知書に記載したサポート要件違反及び明確性要件違反があるというものである。そして、それらの要件違反について、備考欄に、以下のとおり説示している（下線は、当審で施した。）。
　
　「理由２及び理由３について
出願人は、意見書において、「如何にしてユーザを発見するかを明確にするよう、請求項１を補正致しました。」と主張するとともに、当初明細書［００４６］乃至［００５２］を根拠として、本願の請求項１に係る発明が、「ａ．ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかを決定するために前記トラフィックを監視することによってユーザを発見する」ものである旨特定する補正を行っているものと認める。
　しかしながら、「ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかを決定する」という処理そのものについて、その詳細が本願当初明細書の記載において明確に説明されておらず、
当該処理と「ユーザを発見する」こととの関係も不明であるから、「ユーザを発見する」処理の内容について、依然として不明である
　また、「
ユーザを発見する」処理について、発明の詳細な説明のどの部分に対応するのか依然として明らかでない
　
　出願人は意見書において、「如何にしてパフォーマンスが査定されるか、そして、如何に査定されたパフォーマンスが監視されたパフォーマンスと関連するかを明確するよう、請求項１を補正致しました。」と主張するとともに、当初明細書［００４６］乃至［００５２］を根拠として、本願の請求項１に係る発明が、「ｃ．前記監視されたパフォーマンスを履歴パフォーマンスと比較することによって、前記アプリケーションの前記パフォーマンスを査定する」ものである旨特定する補正を行っているものと認める。
　しかしながら、先に通知した拒絶理由の内容は、「アプリケーションのパフォーマンスを査定」するという処理が何を意味しているのか不明確である旨を指摘するものであるところ、「監視されたパフォーマンスを履歴パフォーマンスと比較する」という、本願当初明細書の記載において明確な説明のない事項を伴うものである点、単に特定することによって、当該「アプリケーションのパフォーマンスを査定」するという処理の意味が明らかになるものでなく、「パフォーマンスを査定」することが「パフォーマンスの監視」とどのように異なるのかも、依然として不明である。」
　
（５）審判請求時の補正と審判請求人の主張
　
　審判請求人は、上記（４）を踏まえ、平成２５年１２月２７日付けの手続補正書において、特許請求の範囲の請求項１を、次のとおりに補正した（下線は補正箇所を示すもので、審判請求人が付与したもの。）。
　
「【請求項１】
　ａ．ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するか
どうか
　ｂ．監視されたパーフォーマンスを得るために、前記ユーザに関連するアプリケーションのパーフォーマンスを監視すること、
　ｃ．前記監視されたパーフォーマンスを履歴パーフォーマンスと比較することによって、前記アプリケーションの前記パーフォーマンスを査定すること、及び
ｄ．前記パーフォーマンスの査定に基づいて前記トラフィックを制御することを含む
ことを特徴とする
　
　そして、審判請求書において、次のように主張している。
　
　「拒絶査定謄本では、請求項１中の「ａ．ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかを決定するために前記トラフィックを監視することによってユーザを発見する」との過程について、その「決定する」という処理そのものについては明細書に明確に記載されておらず、「ユーザを発見する」こととの関係も不明であるとの御指摘を頂きました。これについて検討し、斯かる過程を「ａ．ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうか前記トラフィックを監視することによってユーザを発見する」と補正することにより、「決定する」処理を削除するとともに、監視態様とユーザ発見との関連性を明らかに致しました。従いまして、記載不備の問題は解消したものと思料致します。」
　
［３］当審の判断
　
　当審は、上記２．（５）に転記した補正後の請求項１の記載は、依然としてサポート要件（特許法第３６条第６項第１号に規定する要件）及び明確性要件（特許法第３６条第６項第２号に規定する要件）のいずれの要件も満たしているとはいえないと判断する。理由は以下のとおりである。
　
　《サポート要件違反》
　
　ア　上記補正後の請求項１には、「ａ．ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうか前記トラフィックを監視することによってユーザを発見すること、」という記載（以下、「記載ａ」という。）があり、
　この記載は、「・・・かどうか・・・を監視することによって・・・する」という書きぶりからみて、文言上、「ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうか」を、「前記トラフィックを監視することによって」判断し、その判断結果により、「ユーザを発見すること」、すなわち、『ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうかを、前記トラフィックを監視することによって判断し、その判断結果により、ユーザを発見すること』（以下、「特定事項Ａ」という。）を特定する記載と解されるが、
　当該「特定事項Ａ」は、（明確性要件：その技術内容・構成が明確であるかは別としても）発明の詳細な説明に記載されている事項とはいえない。
　
　以下、説明する。
　
　イ　請求人は、審判請求書において上記「記載ａ」の根拠となる発明の詳細な説明の箇所を明示していないが、意見書において、（拒絶理由通知においてサポート要件違反と明確性要件違反の指摘を受けた）「ユーザを自動的に発見する」ことに関し、「如何にしてユーザを発見するかを明確にするよう」に補正（「記載ａ」も「如何にしてユーザを発見するか」を特定するものである。）した根拠として、当初明細書［００４６］乃至［００５２］を挙げており、これら段落の記載についてみるに、
　段落【００４７】（下記に転記した。）には、「トラフィックは、信頼できるエンドポイントの予想されるパターンにそれが一致するかどうか判断するために、このユーザから観察される」との記載はあるものの、
　当該記載の意味するところは、
　・「このユーザ」から「トラフィック」が観察されること、
　・そのようにすることは、トラフィックが「信頼できるエンドポイントの予想されるパターンに」「一致するかどうか判断するために」なされること
　であって、それは上記「特定事項Ａ」が意味するところのものとは異なるものであることは明らかである。
　すなわち、当該記載から、上記「特定事項Ａ」が把握されるとはいえず、上記記載が、『ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうかを、前記トラフィックを監視することによって判断し、その判断結果により、ユーザを発見すること』を記載するものではない。
　
　また、段落【００４７】には「
情報を発見する
情報を発見する
ユーザの特性および要件の知識
トラフィックが本当に信頼できるかどうかの判断に資する
　「ユーザの特性および要件の知識」（を発見すること）と「ユーザ」（を発見すること）とは異なるものであるし、『ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうかを、前記トラフィックを監視することによって判断し、その判断結果により、ユーザを発見すること』が把握される記載でもない。
　
　　　　　　　　　　記（段落【００４７】の記載）
「【００４７】
  信頼できるトラフィックを他のトラフィックと区別するために、ディレクトリからの情報、および他のネットワーク管理およびアプリケーション管理ツールが使用される。これらのツールには、たとえば、ライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ：lightweight directory access protocol）、セッション開始プロトコル（ＳＩＰ：session initiation protocol）および／またはＮｅｔｆｌｏｗｓ（登録商標）コンピュータ・ネットワーク・パフォーマンス・システムが含まれる。Ｎｅｔｆｌｏｗｓ（登録商標）は、ジョージア州ＡｐｐｌｉｎｇのＪａｎｕｓ  Ｒｅｓｅａｒｃｈ  Ｇｒｏｕｐ  ｉｎｃ．社の商標である。ユーザの特性および要件の知識は、トラフィックが本当に信頼できるかどうかの判断に資する。たとえば、一部の実施形態は、所与のユーザが現在特定の地理的領域内に存在し、特定のアプリケーションを実行すると予想され、またセルラ装置を使用していることを知っている。一部の実施形態はＳＩＰディレクトリを使用することによってこの情報を取得するが、一部の実施形態はコール・サーバとの統合によって情報を発見する。トラフィックは、信頼できるエンドポイントの予想されるパターンにそれが一致するかどうか判断するために、このユーザから観察される。第１トラフィック・サブセットのカテゴリを判断する助けとし、および／または第２トラフィック・サブセットについての措置を判断するために、プロトコル・スイートが使用され得る。」
　
　そして、段落【００４６】〜【００５２】の他の箇所を含め、発明の詳細な説明には、上記「特定事項Ａ」が把握される記載もない。
　
　ウ　さらに、査定において、「「
ユーザを発見する」処理について、発明の詳細な説明のどの部分に対応するのか依然として明らかでない
　そもそも、段落【００４６】〜【００５２】の他の箇所を含め、発明の詳細な説明には、「ユーザを発見（する）」との文言自体が見当たらず、
　また、発明の詳細な説明には、「ユーザを発見すること」について、発明の詳細な説明のどこが、それが具体的にどういうことであるか等を説明している箇所であるかが普通に理解できるように記載されているともいえないし、このことについて、請求人は、「記載ａ」の根拠が当初明細書［００４６］乃至［００５２］である以上の説明もしていない。
　
　エ　まとめ（サポート要件違反）
　上記イ-１，２によれば、補正後の請求項１の記載は、サポート要件を満たしているとはいえない。
　
　《明確性要件違反》
　
　オ　補正後の請求項１の上記「記載ａ」が文言上、上記「特定事項Ａ」を特定する記載と解されることは上記（１）のとおりである。
　補正後の請求項１の記載からはもとより発明の詳細な説明の記載・技術常識を参酌しても、具体的にどのような構成を具備していれば「特定事項Ａ」を具備していることになるのか、が理解でき明確であるとはいえず、したがって、当該「特定事項Ａ」は明確であるとはいえない。
　
　以下、説明する。
　
　具体的にどのような構成を具備していれば、上記「特定事項Ａ」、すなわち、『ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうかを、前記トラフィックを監視することによって判断し、その判断結果により、ユーザを発見すること』を具備していることになるのか理解できるか、の点について検討するに、
　補正後の請求項１の記載自体からみても、技術常識を参酌しても、上記の点は理解できるとはいえない。
　
　そして、発明の詳細な説明中、上記「特定事項Ａ」に対応すると思われる（請求人が根拠とする段落【００４６】〜【００５２】中、「予想されるパターン」と「一致するかどうか」を唯一記載する箇所である）段落【００４７】の「トラフィックは、信頼できるエンドポイントの予想されるパターンにそれが一致するかどうか判断するために、このユーザから観察される」をみてみるに、
　当該記載の意味するところは、
　・「このユーザ」から「トラフィック」が観察されること、
　・そのようにすることは、トラフィックが「信頼できるエンドポイントの予想されるパターンに」「一致するかどうか判断するために」なされること
　であって、それが上記「特定事項Ａ」が意味するところのものとは異なるものであることは上記イのとおりであって、そもそも上記「特定事項Ａ」を説明するものではないし、
　(i)具体的にどのような構成を具備していれば、『ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうかを、前記トラフィックを監視することによって判断』することになるのか、そして、
　(ii)具体的にどのような構成を具備していれば、『その判断結果により、ユーザを発見すること』になるのかを説明するものでもない。
　また、発明の詳細な説明には、他に、かかる(i)(ii)を説明する記載も認められない。
　
　そして、そもそも、具体的にどのような構成を具備していれば「ユーザを発見する」ことになるのかも不明であって、発明の詳細な説明中には、これを説明する箇所もないことは上記ウのとおりである。
　
　以上によれば、補正後の請求項１の記載は、明確性要件を満たしているとはいえない。
　
［５］むすび
　
　以上のとおり、上記補正後の請求項１の記載は、特許法第３６条第６項第１号に規定する要件及び特許法第３６条第６項第２号に規定する要件のいずれの要件も満たしていない。
　
　したがって、本願は、他の拒絶の理由について検討するまでもなく、拒絶されるべきものである。
　
　よって、結論のとおり審決する。