ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない。 G06F |
|---|---|
| 管理番号 | 1301214 |
| 審判番号 | 不服2013-25725 |
| 総通号数 | 187 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2015-07-31 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2013-12-27 |
| 確定日 | 2015-05-20 |
| 事件の表示 | 特願2010-227252「ネットワーク・トラフィックのセキュリティのための方法およびシステム」拒絶査定不服審判事件〔平成23年 3月31日出願公開、特開2011- 65653〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
[1]手続の経緯 本願は、平成17年9月8日(パリ条約による優先権主張、平成16年9月9日、アメリカ合衆国)を国際出願日とする特願2007-531435号の一部を、平成22年10月7日(パリ条約による優先権主張 平成16年9月9日、アメリカ合衆国)に新たな特許出願としたものであって、平成24年9月20日付けで拒絶理由通知がなされ、平成25年3月22日に意見書とともに手続補正書が提出されたが、同年9月2日付けで拒絶査定がなされ、これに対し、同年12月27日に拒絶査定不服審判の請求がなされるとともに手続補正書が提出されたものである。 [2]特許法第36条第6項第1号および第2号に規定される要件違反(以下、それぞれの要件を「サポート要件」,「明確性要件」と呼ぶ)に関する審査の経緯と審判請求人の主張 (1)平成24年9月20日付け拒絶理由通知(以下、単に「拒絶理由通知」という)の対象となった特許請求の範囲 拒絶理由通知の対象となった特許請求の範囲の記載は、出願当初の特許請求の範囲の欄に記載されたとおりであり、そのうち、請求項1の記載は、以下のとおりである 「【請求項1】 a.ネットワーク内のトラフィックを使用することによってユーザを自動的に発見するステップと、 b.前記ユーザに関連するアプリケーションのパフォーマンスを監視するステップと、 c.前記アプリケーションのパフォーマンスを査定するステップと、 d.前記トラフィックを制御するステップとを備える、方法。」 (2)拒絶理由通知における指摘事項 (2-1)サポート要件違反の指摘事項 拒絶理由通知におけるサポート要件違反の指摘は、拒絶の理由2として指摘されており、 「2.特許法第36条第6項第1号に関して この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第1号に規定する要件を満たしていない。」というものであり、そのうちの請求項1についての具体的指摘内容は、以下のとおりである。 「【請求項1】には「ユーザを自動的に発見するステップ」が記載されているが、発明の詳細な説明のどの部分に対応するのか明らかでない。 なお、【0020】等には「トラフィックを観察し、ネットワークのユーザを監視」することは記載されているが、当該ユーザを「自動的に発見する」ことについては記載されていない。 よって、【請求項1】に係る発明は、発明の詳細な説明に記載したものでない。」 (2-2)明確性要件違反の指摘事項 拒絶理由通知における明確性要件違反の指摘は、(特許法第36条第4項第1号に規定される要件違反とともに)拒絶の理由3として指摘されており、 「3.特許法第36条第4項第1号及び第6項第2号に関して 特許請求の範囲及び発明の詳細な説明の記載が下記の点で、特許法第36条第4項第1号及び第6項第2号に規定する要件を満たしていない。」というものであり、そのうちの請求項1についての具体的指摘内容は、以下のとおりである。 「(1)ユーザを自動的に発見するステップに関して 【請求項1】の「ユーザを自動的に発見するステップ」の内容が不明確である。また、発明の詳細な説明を見ても当該ステップの内容が不明確である。 したがって、【請求項1】の上記ステップは不明確であり、特許法第36条第4項第1号及び第6項第2号の要件を満たさない。」 「なお、【0020】等には「トラフィックを観察し、ネットワークのユーザを監視」と記載されているが、発明の詳細な説明の記載を総合的に参酌すると、ユーザ自信の挙動を監視するのではなく、単に、ユーザが使用しているアプリケーションのトラフィックを監視しているように思われる。」 「(2)パフォーマンスを査定するステップに関して 【請求項1】には「アプリケーションのパフォーマンスを監視する」ことと、「アプリケーションのパフォーマンスを査定する」ことが記載されているが、「アプリケーションのパフォーマンスを査定」するという処理が何を意味しているのか不明確である。特に、「パフォーマンスを査定」が「パフォーマンスの監視」とどのように異なるのか不明確である。 したがって、【請求項1】の「アプリケーションのパフォーマンスを査定するステップ」は不明確であり、特許法第36条第6項第2号の要件を満たさない。」 (3)上記(2)の指摘を受けての出願人(審判請求人)の応答 上記(2)の指摘を受け出願人(審判請求人)は、平成25年3月22日付け手続補正書により、特許請求の範囲を補正した。補正した請求項1は以下のとおりである(下線は補正箇所を示すもので、出願人が付与したもの。)。 「 【請求項1】 a.ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかを決定するために前記トラフィックを監視することによってユーザを発見すること、 b.監視されたパフォーマンスを得るために、前記ユーザに関連するアプリケーションのパフォーマンスを監視すること、 c.前記監視されたパフォーマンスを履歴パフォーマンスと比較することによって、前記アプリケーションの前記パフォーマンスを査定すること、及び、 d.前記パフォーマンスの査定に基づいて前記トラフィックを制御することを含む、方法。」 そして、平成25年3月22日付けの意見書において、次のように主張した。 「審査官殿がご指摘の独立形式の請求項1における「ユーザを自動的に発見する」ことに関し、出願人は、如何にしてユーザを発見するかを明確にするよう、請求項1を補正致しました。さらに、審査官殿がご指摘の請求項1における「パフォーマンスを査定する」ことに関し、出願人は、如何にしてパフォーマンスが査定されるか、そして、如何に査定されたパフォーマンスが監視されたパフォーマンスと関連するかを明確するよう、請求項1を補正致しました。上記補正は、例えば、当初明細書[0046]乃至[0052]等に記載されています。」 (4)サポート要件違反及び明確性要件違反に関する原査定の理由 原査定の理由は、「平成24年9月20日付け拒絶理由通知書に記載した理由1-3によって、拒絶をすべきものです。」とするものであり、すなわち、依然として、平成24年9月20日付け拒絶理由通知書に記載したサポート要件違反及び明確性要件違反があるというものである。そして、それらの要件違反について、備考欄に、以下のとおり説示している(下線は、当審で施した。)。 「<<理由2及び理由3について>> 出願人は、意見書において、「如何にしてユーザを発見するかを明確にするよう、請求項1を補正致しました。」と主張するとともに、当初明細書[0046]乃至[0052]を根拠として、本願の請求項1に係る発明が、「a.ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかを決定するために前記トラフィックを監視することによってユーザを発見する」ものである旨特定する補正を行っているものと認める。 しかしながら、「ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかを決定する」という処理そのものについて、その詳細が本願当初明細書の記載において明確に説明されておらず、当該処理と「ユーザを発見する」こととの関係も不明であるから、「ユーザを発見する」処理の内容について、依然として不明である。 また、「ユーザを発見する」処理について、発明の詳細な説明のどの部分に対応するのか依然として明らかでない。 出願人は意見書において、「如何にしてパフォーマンスが査定されるか、そして、如何に査定されたパフォーマンスが監視されたパフォーマンスと関連するかを明確するよう、請求項1を補正致しました。」と主張するとともに、当初明細書[0046]乃至[0052]を根拠として、本願の請求項1に係る発明が、「c.前記監視されたパフォーマンスを履歴パフォーマンスと比較することによって、前記アプリケーションの前記パフォーマンスを査定する」ものである旨特定する補正を行っているものと認める。 しかしながら、先に通知した拒絶理由の内容は、「アプリケーションのパフォーマンスを査定」するという処理が何を意味しているのか不明確である旨を指摘するものであるところ、「監視されたパフォーマンスを履歴パフォーマンスと比較する」という、本願当初明細書の記載において明確な説明のない事項を伴うものである点、単に特定することによって、当該「アプリケーションのパフォーマンスを査定」するという処理の意味が明らかになるものでなく、「パフォーマンスを査定」することが「パフォーマンスの監視」とどのように異なるのかも、依然として不明である。」 (5)審判請求時の補正と審判請求人の主張 審判請求人は、上記(4)を踏まえ、平成25年12月27日付けの手続補正書において、特許請求の範囲の請求項1を、次のとおりに補正した(下線は補正箇所を示すもので、審判請求人が付与したもの。)。 「【請求項1】 a.ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうか前記トラフィックを監視することによってユーザを発見すること、 b.監視されたパーフォーマンスを得るために、前記ユーザに関連するアプリケーションのパーフォーマンスを監視すること、 c.前記監視されたパーフォーマンスを履歴パーフォーマンスと比較することによって、前記アプリケーションの前記パーフォーマンスを査定すること、及び d.前記パーフォーマンスの査定に基づいて前記トラフィックを制御することを含むことを特徴とする方法。」 そして、審判請求書において、次のように主張している。 「拒絶査定謄本では、請求項1中の「a.ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかを決定するために前記トラフィックを監視することによってユーザを発見する」との過程について、その「決定する」という処理そのものについては明細書に明確に記載されておらず、「ユーザを発見する」こととの関係も不明であるとの御指摘を頂きました。これについて検討し、斯かる過程を「a.ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうか前記トラフィックを監視することによってユーザを発見する」と補正することにより、「決定する」処理を削除するとともに、監視態様とユーザ発見との関連性を明らかに致しました。従いまして、記載不備の問題は解消したものと思料致します。」 [3]当審の判断 当審は、上記2.(5)に転記した補正後の請求項1の記載は、依然としてサポート要件(特許法第36条第6項第1号に規定する要件)及び明確性要件(特許法第36条第6項第2号に規定する要件)のいずれの要件も満たしているとはいえないと判断する。理由は以下のとおりである。 《サポート要件違反》 ア 上記補正後の請求項1には、「a.ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうか前記トラフィックを監視することによってユーザを発見すること、」という記載(以下、「記載a」という。)があり、 この記載は、「・・・かどうか・・・を監視することによって・・・する」という書きぶりからみて、文言上、「ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうか」を、「前記トラフィックを監視することによって」判断し、その判断結果により、「ユーザを発見すること」、すなわち、『ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうかを、前記トラフィックを監視することによって判断し、その判断結果により、ユーザを発見すること』(以下、「特定事項A」という。)を特定する記載と解されるが、 当該「特定事項A」は、(明確性要件:その技術内容・構成が明確であるかは別としても)発明の詳細な説明に記載されている事項とはいえない。 以下、説明する。 イ 請求人は、審判請求書において上記「記載a」の根拠となる発明の詳細な説明の箇所を明示していないが、意見書において、(拒絶理由通知においてサポート要件違反と明確性要件違反の指摘を受けた)「ユーザを自動的に発見する」ことに関し、「如何にしてユーザを発見するかを明確にするよう」に補正(「記載a」も「如何にしてユーザを発見するか」を特定するものである。)した根拠として、当初明細書[0046]乃至[0052]を挙げており、これら段落の記載についてみるに、 段落【0047】(下記に転記した。)には、「トラフィックは、信頼できるエンドポイントの予想されるパターンにそれが一致するかどうか判断するために、このユーザから観察される」との記載はあるものの、 当該記載の意味するところは、 ・「このユーザ」から「トラフィック」が観察されること、 ・そのようにすることは、トラフィックが「信頼できるエンドポイントの予想されるパターンに」「一致するかどうか判断するために」なされること であって、それは上記「特定事項A」が意味するところのものとは異なるものであることは明らかである。 すなわち、当該記載から、上記「特定事項A」が把握されるとはいえず、上記記載が、『ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうかを、前記トラフィックを監視することによって判断し、その判断結果により、ユーザを発見すること』を記載するものではない。 また、段落【0047】には「情報を発見する」との記載があるが、「情報を発見する」の「情報」とは、「ユーザの特性および要件の知識」のことであって、「トラフィックが本当に信頼できるかどうかの判断に資する」ものと解されるから、段落【0047】には、「トラフィックが本当に信頼できるかどうかの判断に資する」「ユーザの特性および要件の知識」を発見することは記載されているといいえるものの、 「ユーザの特性および要件の知識」(を発見すること)と「ユーザ」(を発見すること)とは異なるものであるし、『ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうかを、前記トラフィックを監視することによって判断し、その判断結果により、ユーザを発見すること』が把握される記載でもない。 記(段落【0047】の記載) 「【0047】 信頼できるトラフィックを他のトラフィックと区別するために、ディレクトリからの情報、および他のネットワーク管理およびアプリケーション管理ツールが使用される。これらのツールには、たとえば、ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP:lightweight directory access protocol)、セッション開始プロトコル(SIP:session initiation protocol)および/またはNeｔflｏｗｓ(登録商標)コンピュータ・ネットワーク・パフォーマンス・システムが含まれる。Neｔflｏｗｓ(登録商標)は、ジョージア州AｐｐlingのJanｕｓ Reｓeaｒch Gｒｏｕｐ inc.社の商標である。ユーザの特性および要件の知識は、トラフィックが本当に信頼できるかどうかの判断に資する。たとえば、一部の実施形態は、所与のユーザが現在特定の地理的領域内に存在し、特定のアプリケーションを実行すると予想され、またセルラ装置を使用していることを知っている。一部の実施形態はSIPディレクトリを使用することによってこの情報を取得するが、一部の実施形態はコール・サーバとの統合によって情報を発見する。トラフィックは、信頼できるエンドポイントの予想されるパターンにそれが一致するかどうか判断するために、このユーザから観察される。第1トラフィック・サブセットのカテゴリを判断する助けとし、および/または第2トラフィック・サブセットについての措置を判断するために、プロトコル・スイートが使用され得る。」 そして、段落【0046】?【0052】の他の箇所を含め、発明の詳細な説明には、上記「特定事項A」が把握される記載もない。 ウ さらに、査定において、「「ユーザを発見する」処理について、発明の詳細な説明のどの部分に対応するのか依然として明らかでない。」とサポート要件違反と指摘された「ユーザを発見する」について検討するに、 そもそも、段落【0046】?【0052】の他の箇所を含め、発明の詳細な説明には、「ユーザを発見(する)」との文言自体が見当たらず、 また、発明の詳細な説明には、「ユーザを発見すること」について、発明の詳細な説明のどこが、それが具体的にどういうことであるか等を説明している箇所であるかが普通に理解できるように記載されているともいえないし、このことについて、請求人は、「記載a」の根拠が当初明細書[0046]乃至[0052]である以上の説明もしていない。 エ まとめ(サポート要件違反) 上記イ-1,2によれば、補正後の請求項1の記載は、サポート要件を満たしているとはいえない。 《明確性要件違反》 オ 補正後の請求項1の上記「記載a」が文言上、上記「特定事項A」を特定する記載と解されることは上記(1)のとおりである。 補正後の請求項1の記載からはもとより発明の詳細な説明の記載・技術常識を参酌しても、具体的にどのような構成を具備していれば「特定事項A」を具備していることになるのか、が理解でき明確であるとはいえず、したがって、当該「特定事項A」は明確であるとはいえない。 以下、説明する。 具体的にどのような構成を具備していれば、上記「特定事項A」、すなわち、『ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうかを、前記トラフィックを監視することによって判断し、その判断結果により、ユーザを発見すること』を具備していることになるのか理解できるか、の点について検討するに、 補正後の請求項1の記載自体からみても、技術常識を参酌しても、上記の点は理解できるとはいえない。 そして、発明の詳細な説明中、上記「特定事項A」に対応すると思われる(請求人が根拠とする段落【0046】?【0052】中、「予想されるパターン」と「一致するかどうか」を唯一記載する箇所である)段落【0047】の「トラフィックは、信頼できるエンドポイントの予想されるパターンにそれが一致するかどうか判断するために、このユーザから観察される」をみてみるに、 当該記載の意味するところは、 ・「このユーザ」から「トラフィック」が観察されること、 ・そのようにすることは、トラフィックが「信頼できるエンドポイントの予想されるパターンに」「一致するかどうか判断するために」なされること であって、それが上記「特定事項A」が意味するところのものとは異なるものであることは上記イのとおりであって、そもそも上記「特定事項A」を説明するものではないし、 (i)具体的にどのような構成を具備していれば、『ネットワーク内のトラフィックがユーザのエンドポイントについて予想されるパターンと一致するかどうかを、前記トラフィックを監視することによって判断』することになるのか、そして、 (ii)具体的にどのような構成を具備していれば、『その判断結果により、ユーザを発見すること』になるのかを説明するものでもない。 また、発明の詳細な説明には、他に、かかる(i)(ii)を説明する記載も認められない。 そして、そもそも、具体的にどのような構成を具備していれば「ユーザを発見する」ことになるのかも不明であって、発明の詳細な説明中には、これを説明する箇所もないことは上記ウのとおりである。 以上によれば、補正後の請求項1の記載は、明確性要件を満たしているとはいえない。 [5]むすび 以上のとおり、上記補正後の請求項1の記載は、特許法第36条第6項第1号に規定する要件及び特許法第36条第6項第2号に規定する要件のいずれの要件も満たしていない。 したがって、本願は、他の拒絶の理由について検討するまでもなく、拒絶されるべきものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2014-12-15 |
| 結審通知日 | 2014-12-16 |
| 審決日 | 2015-01-07 |
| 出願番号 | 特願2010-227252(P2010-227252) |
| 審決分類 |
P
1
8・
537-
Z
(G06F)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 小林 秀和、千本 潤介 |
| 特許庁審判長 |
小曳 満昭 |
| 特許庁審判官 |
乾 雅浩 白石 圭吾 |
| 発明の名称 | ネットワーク・トラフィックのセキュリティのための方法およびシステム |
| 代理人 | 岡部 讓 |