2014-024621

特願２０１３－５２８４９８「ＯＮＵとＯＬＴとの間に省エネルギーメカニズム管理を実現する方法及びシステム」拒絶査定不服審判事件〔平成２４年　３月２２日国際公開、ＷＯ２０１２／０３４３８５、平成２５年１０月１０日国内公表、特表２０１３－５３８５３１〕について、次のとおり審決する。

【結　論】 本件審判の請求は、成り立たない。

【理　由】 第１　手続の経緯 本願は、２０１１年３月９日（パリ条約による優先権主張外国庁受理２０１０年９月１７日　中華人民共和国）を国際出願日とした出願であって、原審において平成２６年７月３０日付けで拒絶査定がなされ、これに対し、同年１２月２日に拒絶査定不服審判が請求され、平成２７年１０月２日付けで当審より拒絶理由が通知され、平成２８年１月５日付けで意見書が提出され、同年６月１日付けで拒絶理由が通知され、同年９月７日付けで意見書及び手続補正書が提出されたものである。 第２　平成２８年６月１日付け拒絶理由の概要 「理　由 １）本件出願は、特許請求の範囲の記載が下記の点で不備のため、特許法第３６条第６項第２号に規定する要件を満たしていない。 ２）本件出願は、発明の詳細な説明の記載が下記の点で不備のため、特許法第３６条第４項第１号に規定する要件を満たしていない。 ３）（略） ４）本件出願の下記の請求項に係る発明は、その出願前日本国内または外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 記 理由１について １．発明の詳細な説明の記載及び本願の優先日当時の技術常識を参酌しても、「拡張ＯＡＭフレーム」の定義が不明確であり、「拡張ＯＡＭイベント通知フォーマット」、「拡張組織専用ＯＡＭフォーマット」、「拡張ＯＡＭプロトコルデータユニット（ＰＤＵ：Protocol Data Unit）フォーマット」の定義も不明確であるため、請求項１～１４に係る発明が不明確である。 明細書段落【００３９】に「ここで、拡張ＯＡＭフレームは、拡張ＯＡＭイベント通知フォーマット、又は拡張組織専用ＯＡＭフォーマット、又は他の類似する拡張ＯＡＭプロトコルデータユニット（ＰＤＵ：Protocol Data Unit）フォーマットを含む。」との記載があるが、「拡張ＯＡＭイベント通知フォーマット」、「拡張組織専用ＯＡＭフォーマット」、「拡張ＯＡＭプロトコルデータユニット（ＰＤＵ：Protocol Data Unit）フォーマット」の定義も明らかにされておらず、これらがいかなるものか不明であるため、【００３９】の上記記載自体、意味不明である。また、これらの用語が技術常識であることを示す証拠も見当たらない。 このため、請求項１、９に記載中の「前記省エネルギー情報が、拡張ＯＡＭフレームのＯＡＭプロトコルデータユニット情報メッセージにおける組織専用情報タイプ－長さ－値フィールドに含まれ」る、「前記省エネルギー情報が、前記拡張ＯＡＭフレームの拡張ＯＡＭイベント通知メッセージに含まれ」る、「前記省エネルギー情報が、前記拡張ＯＡＭフレームの拡張ＯＡＭプロトコルデータユニットＰＤＵフォーマットに含まれる」 とは、それぞれいかなることか不明確である。また、これら３つの態様が「又は」と択一的に記載されているものの、３つの態様が排他的に独立した関係にあるのか、或いは包含関係を有しているのかも不明確である。 なお、請求人は、平成２８年１月５日付け意見書において、「拡張ＯＡＭフレームについては、ＩＥＥＥ８０２．３ａｈの規格に記載されている。従って、「拡張ＯＡＭフレーム」の定義が明確であり、本願の請求項１－１４に係る発明が明確である。」と釈明しているが、ＩＥＥＥ８０２．３ａｈをみても「拡張ＯＡＭフレーム」（extended OAM frame）なるものは記載されておらず、ＩＥＥＥ８０２．３ａｈの規格における具体的な記載箇所及び記載内容も特定されていないから、当該釈明は採用できない。同様に、ＩＥＥＥ８０２．３ａｈの規格によっても、「拡張ＯＡＭイベント通知フォーマット」、「拡張組織専用ＯＡＭフォーマット」、「拡張ＯＡＭプロトコルデータユニット（ＰＤＵ：Protocol Data Unit）フォーマット」の定義は不明であり、これらがいかなるものか不明である。 （ＩＥＥＥ８０２．３ａｈの規格における具体的な記載箇所及び記載内容も特定し、上記各用語の定義を十分に説明されたい。） ２．請求項１には、「拡張運用管理およびメインテナンスフレーム」との記載と、「拡張ＯＡＭフレーム」との記載があり、両者の異同が不明である。用語は、その有する普通の意味で使用し、かつ、明細書及び特許請求の範囲全体を通じて統一して使用しなければならないことに留意されたい。 理由２について １．上記理由１のとおり、発明の詳細な説明には、「拡張ＯＡＭフレーム」、「拡張ＯＡＭイベント通知フォーマット」、「拡張組織専用ＯＡＭフォーマット」、「拡張ＯＡＭプロトコルデータユニットフォーマット」それぞれの内容を明確に把握し得る程度に十分な開示がされていない。このため、発明の詳細な説明は、請求項１～１４に係る発明を当業者が実施できる程度に十分に記載されていない。 理由３について（略） 理由４について 請求項１～１４に対して引用文献１～４。 引用文献１：国際公開第２０１０／０９８２６２号（新たに引用する文献。） 引用文献２：ＩＥＥＥ　Ｓｔｄ　８０２．３ａｈ－２００４，ＩＥＥＥ　Ｃｏｍｐｕｔｅｒ　Ｓｏｃｉｅｔｙ，２００４年９月７日（新たに引用する文献。） 引用文献３：欧州特許出願公開第１８０１９８４号明細書（新たに引用する文献。） 引用文献４：米国特許出願公開第２０１０／０１１８７５３号明細書（新たに引用する文献。） 上記理由１．のとおり「拡張ＯＡＭフレーム」の定義が不明確であるが、発明の詳細な説明の記載を総合して、ＯＡＭフレームの組織専用（ＯＵＩ）ＴＬＶフィールドにコマンド書き込み得るものと解して、以下判断する。 備考：（１）上記理由３のとおり、引用文献１（段落【０２２７】～【０２５７】、図２２～２４）には、ＯＬＴからＯＮＵに、ＯＡＭフレームにおいてスリープ指令メッセージを送信し、スリープ指令メッセージに応じてＯＮＵを休止後起動することが記載されている。 ここで、引用文献１に記載された発明は、ＯＡＭフレームにおける、省エネルギー情報を組み込む位置が特定されていない点で本願発明と相違する。 しなしながら、引用文献２（２１５頁　５７．４．３．６　Ｏｒｇａｎｉｚａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　ＯＡＭＰＤＵ、Ｆｉｇｕｒｅ５７－１５）に記載されているように、ＯＡＭフレームが、組織専用情報ＴＬＶフィールドを有することは技術常識であり、引用文献１のＯＡＭフレームも具体的には当該構造を持ち得るところ、また、引用文献３（［００３８]）及び引用文献４（［００４２］～［００５２］）に記載されているように、組織専用情報ＴＬＶフィールドにコマンド等を組み入れることは普通に行われていることである。してみれば、組織専用情報ＴＬＶフィールドに、コマンド等の省エネルギー情報を含むことは適宜なし得ることである。 そうすると、引用文献２～４に接した当業者であれば、引用文献１に記載されたＯＡＭフレームにおいて、組織専用情報ＴＬＶフィールドにスリープ指令を組み入れることに格別な困難性はない。 したがって、請求項１～１４に係る発明は、引用文献１～４に記載された発明に基づいて、当業者が容易に想到し得るものである。」 第３　請求人の対応 請求人は、平成２８年９月７日付けで、特許請求の範囲を補正するとともに、意見書を提出した。 １．補正の概要 特許請求の範囲の補正は、独立請求項である請求項１及び９について「前記省エネルギー情報のキャリー方式は、・・方式・・方式・・方式の何れかであること」を追加して省エネルギー情報のキャリー方式の３つの態様が排他的に独立した関係にあるように限定し、また、「拡張運用管理およびメンテナンスフレーム」を「拡張運用管理およびメンテナンス（拡張ＯＡＭ＝Operations，Administration，Maintenance）フレーム」とするものであり、補正後の特許請求の範囲の請求項１に係る発明は、以下のとおりである。 「光ネットワークユニットＯＮＵと光回線端末ＯＬＴとの間に省エネルギーメカニズム管理を実現する方法であって、 ＯＮＵとＯＬＴとの間に拡張運用管理およびメンテナンス（拡張ＯＡＭ＝Operations，Administration，Maintenance）フレームを介して省エネルギー情報を伝送するステップと、 取得した省エネルギー情報に応じてＯＮＵの光モジュールをオフ／オンにするステップとを含み、 前記省エネルギー情報のキャリー方式は、 前記省エネルギー情報が、拡張ＯＡＭフレームのＯＡＭプロトコルデータユニット情報メッセージにおける組織専用情報タイプ－長さ－値フィールドに含まれる方式、又は、 前記省エネルギー情報が、前記拡張ＯＡＭフレームの拡張ＯＡＭイベント通知メッセージに含まれる方式、又は、 前記省エネルギー情報が、前記拡張ＯＡＭフレームの拡張ＯＡＭプロトコルデータユニットＰＤＵフォーマットに含まれる方式 の何れかであること を特徴とする方法。」 ２．意見書の主張 意見書の主張の概要は、以下のとおりである。 「（３）先ず、理由１に関して意見を述べる。 （３－１）拡張ＯＡＭフレームの構造については、以下のＵＲＬに対応するドキュメントの記載を参照願いたい。 http://wenku.baidu.com/link?url=EyLMw27b2M6vQzfWgjRG_5Cp4nOC15gKluxB4SdGIBEuuvFlG_B19WVqMikDHa03P_OlEJgLGQ9eCavB3fo4Gf_sMGV2rBTRr4qIpvGRjhe 上記ドキュメントの記載によれば、拡張ＯＡＭフレームの定義が明確である。また、拡張ＯＡＭフレームのＯＡＭプロトコルデータユニット情報メッセージにおける組織専用情報タイプ－長さ－値フィールド、拡張ＯＡＭフレームの拡張ＯＡＭイベント通知メッセージ、および拡張ＯＡＭフレームの拡張ＯＡＭプロトコルデータユニットＰＤＵフォーマットの定義が明確である。従って、明細書の段落【００３９】の記載、並びに請求項１及び９の記載も明確である。更に、請求項１及び９における補正により、省エネルギー情報のキャリー方式の３つの態様が排他的に独立した関係にあることが明確である。 （３－２）請求項１における「拡張運用管理およびメインテナンス（拡張ＯＡＭ＝Operations，Administration，Maintenance）フレーム」及び「拡張ＯＡＭフレーム」は明らかに同じものである。 （３－３）よって、請求項１～１４に係る発明は明確であり、特許法第３６条第６項第２号に規定する要件を満たしている。 （４）次に、理由２に関して意見を述べる。 理由１を解消したことにより、拡張ＯＡＭフレームのＯＡＭプロトコルデータユニット情報メッセージにおける組織専用情報タイプ－長さ－値フィールド、拡張ＯＡＭフレームの拡張ＯＡＭイベント通知メッセージ、および拡張ＯＡＭフレームの拡張ＯＡＭプロトコルデータユニットＰＤＵフォーマットの定義は明確である。このため、発明の詳細な説明は、請求項１～１４に係る発明を当事者が実施できる程度に十分に記載されており、特許法第３６条第４項第１号に規定する要件を満たしている。 （５）（略） （６）最後に、理由４に関して意見を述べる。 （６－１）本願の請求項１に係る発明を引用文献１～４に記載の発明と対比してみると、請求項１に係る発明の発明特定事項 「前記省エネルギー情報のキャリー方式は、前記省エネルギー情報が、拡張ＯＡＭフレームのＯＡＭプロトコルデータユニット情報メッセージにおける組織専用情報タイプ－長さ－値フィールドに含まれる方式、又は、前記省エネルギー情報が、前記拡張ＯＡＭフレームの拡張ＯＡＭイベント通知メッセージに含まれる方式、又は、前記省エネルギー情報が、前記拡張ＯＡＭフレームの拡張ＯＡＭプロトコルデータユニットＰＤＵフォーマットに含まれる方式の何れかであること」 は、引用文献１～４に記載されておらず、それを示唆する記述も見られない。 （６－２）引用文献１には、上述したようにＭＰＣＰフレーム又はＯＡＭフレームを介してスリープ指令メッセージをどのようにキャリーするか、すなわち、ＭＰＣＰフレーム又はＯＡＭフレームのどの情報ユニットにスリープ指令メッセージをキャリーするかについては記載されておらず、ＭＰＣＰフレームおよびＯＡＭフレームの詳しい構造についても記載されていない。引用文献１に記載のスリープ指令は、睡眠の指示情報のみを含んでいる。 （６－３）これに対し、請求項１に係る発明によれば、省エネルギー情報が、前記拡張ＯＡＭフレームのＯＡＭプロトコルデータユニット情報メッセージにおける組織専用情報タイプ－長さ－値フィールド、又は前記拡張ＯＡＭフレームの拡張ＯＡＭイベント通知メッセージ、又は前記拡張ＯＡＭフレームの拡張ＯＡＭプロトコルデータユニットＰＤＵフォーマットの何れかに含まれており、省エネルギー情報が、仮眠、快速睡眠、深度睡眠、周期睡眠等の指示情報を含んでいる。引用文献１に記載の発明と比較して、省エネルギー情報がキャリーされている拡張ＯＡＭフレームのフィールドが異なり、拡張ＯＡＭフレームにより省エネルギー情報を解析する速度及び方式も異なる。更に、省エネルギー情報が、拡張ＯＡＭフレームのＯＡＭプロトコルデータユニット情報メッセージにおける組織専用情報タイプ－長さ－値フィールド又は拡張ＯＡＭイベント通知メッセージ又は拡張ＯＡＭプロトコルデータユニットＰＤＵフォーマットの何れかによってキャリーされた後、受信者の省エネルギー情報の解析速度を向上させる効果を奏する。 （６－４）引用文献２には、ＯＡＭ　ＰＤＵフレームの構造については記載されているが、ＯＡＭ　ＰＤＵフレームがどのように使用されるかについては記載されておらず、省エネルギー情報についても記載されていない。引用文献３には、バックアップ電池がアラーム設定値を下回ることが検出されると、省電力状態に入り、または、省電力状態に入る前に、電源の現状をユーザーへ通知し、省電力状態に入るかどうかをユーザーにより決定することが記載されているが、省エネルギー情報と省エネルギー情報のキャリー方式とについては記載されていない。引用文献４には、スリープ要求メッセージフレームおよびスリープ要求メッセージフレームの情報ユニットの構造と、ＯＵＩおよび拡張ＯＰＣＯＤＥの情報ユニットの構造とについては記載されているが、拡張ＯＡＭフレームの構造については記載されていない。 （６－５）以上のように、本願の請求項１に係る発明は、引用文献１～４には開示も示唆もされていない要件を備え、またこの要件を備えることによって奏する効果にも優れたものがあることから、本願の請求項１に係る発明が引用文献１～４に基づきその進歩性を否定される理由はない。本願の請求項９に係る発明は、本願の請求項１に係る発明と実質同一の技術的特徴を有しており、進歩性を有する。また、本願の請求項２－８及び１０－１４夫々は、その発明が進歩性を有して拒絶されるべきではない請求項１及び９に従属しているため、請求項２－８及び１０－１４に係る発明も進歩性を有している。」 第４　当審の判断 １．特許法第３６条第６項第２項について 特許請求の範囲の「拡張ＯＡＭフレーム」、「拡張ＯＡＭイベント通知メッセージ」、「拡張ＯＡＭプロトコルデータユニットＰＤＵフォーマット」の用語、及び発明の詳細な説明の「拡張組織専用ＯＡＭフォーマット」の用語は、本願優先日当時における通常の技術用語ではなく、本願優先日当時の技術常識を考慮してもその意義を理解できない。このため、発明の詳細な説明の記載（【００３９】）を参酌すると、本願明細書【００３９】【００４３】に以下の記載がある。 「【００３９】ここで、拡張ＯＡＭフレームは、拡張ＯＡＭイベント通知フォーマット、又は拡張組織専用ＯＡＭフォーマット、又は他の類似する拡張ＯＡＭプロトコルデータユニット（ＰＤＵ：Protocol Data Unit）フォーマットを含む。 【００４３】当業者にとっては、ＯＮＵとＯＬＴの間のインタラクションが拡張ＯＡＭフレームを介して実現され、拡張ＯＡＭフレームがイーサネットプロトコル８０２．３で定義されたＯＡＭ拡張フォーマットメッセージである。本発明では、拡張ＯＡＭフレームのＯＡＭプロトコルデータユニット情報（INFO OAM PDU）メッセージにおける組織専用情報タイプ－長さ－値（Organization specific information TLV）フィールドに省エネルギー情報を加えてよい、８０２．３における拡張ＯＡＭフレームの拡張ＯＡＭイベント通知（Event Notification）メッセージに省エネルギー情報を加えてもよい。」 しかしながら、ＩＥＥＥ８０２．３には、「拡張ＯＡＭ」なるものは存在せず、本願明細書には、その具体的な記載箇所も明らかにされていない。これについて、請求人は、平成２８年１月５日付け意見書において、拡張ＯＡＭフレームは、ＩＥＥＥ８０２．３ａｈの規格に記載されていると主張するが、ＩＥＥＥ８０２．３ａｈの規格にも「拡張ＯＡＭ」なるものは存在せず、その具体的な記載箇所も明らかにされていない。 そして、請求人は、平成２８年９月７日付け意見書において、拡張ＯＡＭフレームは、ＵＲＬ：http://wenku.baidu.com/link?url=EyLMw27b2M6vQzfWgjRG_5Cp4nOC15gKluxB4SdGIBEuuvFlG_B19WVqMikDHa03P_OlEJgLGQ9eCavB3fo4Gf_sMGV2rBTRr4qIpvGRjheのドキュメントに記載されていると主張している。 しかしながら、当ドキュメントは、その著者、表題、掲載年月日が不明であるから、ＩＥＥＥ８０２．３との関係が不明であり、上記イ．の【００４３】の記載を裏付けるものではないし、本願優先日当時の技術常識であるとすることもできない。 したがって、発明の詳細な説明の記載及び本願優先日当時の技術常識を参酌しても、依然として、請求項に記載された「拡張ＯＡＭフレーム」、「拡張ＯＡＭフレームのＯＡＭプロトコルデータユニット情報メッセージにおける組織専用情報タイプ－長さ－値フィールド」（発明の詳細な説明では、「拡張組織専用ＯＡＭフォーマット」と表現されている。）、「拡張ＯＡＭイベント通知メッセージ」、「拡張ＯＡＭプロトコルデータユニットＰＤＵフォーマット」なる用語の意味内容を当業者が理解できず、発明の技術的範囲を特定できないから、請求項１～１４に係る発明が不明確である。 また、請求人は、意見書において、「省エネルギー情報のキャリー方式の３つの態様が排他的に独立した関係にあることが明確である。」と主張しているが、発明の詳細な説明の【表１】～【表１４】の記載を参酌すると、「拡張ＯＡＭフレームのＯＡＭプロトコルデータユニット情報メッセージにおける組織専用情報タイプ－長さ－値フィールド」は、「拡張ＯＡＭプロトコルデータユニットＰＤＵフォーマット」に含まれるとも解釈されるから、依然として、これらの態様が排他的に独立した関係にあるのか、或いは包含関係を有しているのか不明確である。 ２．特許法第３６条第４項第１項について 上記１．のとおり、発明の詳細な説明には、「拡張ＯＡＭフレーム」、「拡張ＯＡＭイベント通知フォーマット」、「拡張ＯＡＭフレームのＯＡＭプロトコルデータユニット情報メッセージにおける組織専用情報タイプ－長さ－値フィールド」（発明の詳細な説明では、「拡張組織専用ＯＡＭフォーマット」と表現されている。）、「拡張ＯＡＭプロトコルデータユニット（ＰＤＵ：Protocol Data Unit）フォーマット」それぞれの内容を明確に把握し得る程度に十分な開示がなされていない。 そして、発明の詳細な説明はこれらの用語を用いて記載されているため、これらの用語の意味内容が理解できないことに起因して、発明な詳細な説明の記載自体も不明確となっている。 したがって、発明の詳細な説明は、請求項１～１４に係る発明を当業者が実施できる程度に明確かつ十分に記載されていない。 ３．特許法第２９条第２項について （１）本願発明 上記「１．」の項で判断したとおり、「拡張ＯＡＭフレーム」の定義が不明確であるが、発明の詳細な説明の【表１】～【表１４】の記載を参酌して、ＯＡＭフレームの組織専用（ＯＵＩ）ＴＬＶフィールドにコマンドを書き込むものを含むと解して、以下判断する。 当該解釈に従い、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２８年９月７日付けで手続補正された特許請求の範囲の請求項１に記載された次のとおりのものと認める。 「光ネットワークユニットＯＮＵと光回線端末ＯＬＴとの間に省エネルギーメカニズム管理を実現する方法であって、 ＯＮＵとＯＬＴとの間に拡張運用管理およびメンテナンス（拡張ＯＡＭ＝Operations，Administration，Maintenance）フレームを介して省エネルギー情報を伝送するステップと、 取得した省エネルギー情報に応じてＯＮＵの光モジュールをオフ／オンにするステップとを含み、 前記省エネルギー情報のキャリー方式は、 前記省エネルギー情報が、拡張ＯＡＭフレームのＯＡＭプロトコルデータユニット情報メッセージにおける組織専用情報タイプ－長さ－値フィールドに含まれる方式、又は、 前記省エネルギー情報が、前記拡張ＯＡＭフレームの拡張ＯＡＭイベント通知メッセージに含まれる方式、又は、 前記省エネルギー情報が、前記拡張ＯＡＭフレームの拡張ＯＡＭプロトコルデータユニットＰＤＵフォーマットに含まれる方式 の何れかであること を特徴とする方法。」 （２）引用例及び引用発明 当審の平成２８年６月１日付け拒絶理由に引用された国際公開第２０１０／０９８２６２号（以下、「引用例」という。）には図面とともに以下の事項が記載されている。 イ．「技術分野 ［０００１］ 本発明は、ポイントツーポイントまたはポイントツーマルチポイントの通信を行う光ネットワークにおいて、一部の機能を一定期間休止させることによって装置の省電力化を図る機能を有する光加入者線終端装置および光ネットワーク終端装置に関する。 背景技術 ［０００２］ 図１に示すように、光ネットワークは、１つの光加入者線終端装置（ＯＬＴ：Ｏｐｔｉｃａｌ　Ｌｉｎｅ　Ｔｅｒｍｉｎａｌ）が１つの光ネットワーク終端装置（ＯＮＵ：Ｏｐｔｉｃａｌ　Ｎｅｔｗｏｒｋ　Ｕｎｉｔ）と光ファイバ伝送路を介してポイントツーポイントの通信を行うネットワークである。 また、図２に示すように、受動光ネットワーク（ＰＯＮ：Ｐａｓｓｉｖｅ　Ｏｐｔｉｃａｌ　Ｎｅｔｗｏｒｋ）は、１つの光加入者線終端装置（ＯＬＴ）が複数の光ネットワーク終端装置（ＯＮＵ）と光ファイバ伝送路および１対ｎの光スプリッタ（ｎは自然数）を介してポイントツーマルチポイントの通信を行うネットワークである。ギガビットクラスのＰＯＮの代表的な規格として、ＩＥＥＥ８０２．３にて標準化されたＥＰＯＮ（Ｅｔｈｅｒｎｅｔ（登録商標）ＰＯＮ）がある。また、ＩＥＥＥ８０２．３ａｖ検討グループでは１０ギガビットクラスのＰＯＮとして１０Ｇ－ＥＰＯＮの検討がなされている。」（１頁） ロ．「［０２１９］ ［ＯＮＵの構成］ ＯＮＵ２０は、ＵＮＩ１２１と、キュー管理部１２２と、ＰＯＮ信号処理部２１と、ＰＯＮ－ＩＦ１２４と、休止部２２とを備える。 ［０２２０］ ＰＯＮ信号処理部２１は、ＭＰＣＰ基２３と、ＯＡＭ基２４と、ＭＡＣ基１２７と、ＰＨＹ基１２８とを有し、後述するように、休止部２２とメッセージのやりとりをする。 ［０２２１］ 休止部２２は、ＯＬＴ１０からスリープ指令メッセージを受信すると、確認応答（ＡＣＫメッセージ）をＯＬＴ１０に送信し、ＯＮＵ２０の一部（例えば、キュー管理部１２２及びＰＯＮ信号処理部２１）の機能を一定時間ｔ２の期間休止させる。そして、一定時間ｔ２経過後に、休止していた一部の機能を起動させ、ＯＬＴ１０に対してトラヒックの有無を確認する（トラヒック確認メッセージ）。無通信状態であれば（ＮＯメッセージ）、一部の機能を一定時間ｔ２の期間休止させ、フレーム到着があれば（ＹＥＳメッセージ）、ＯＬＴ１０との通信を開始させる。 ［０２２２］ また、休止部２２は、ＵＮＩ１２１からトラヒックが流入してきた場合、フレームの転送遅延を防止するため、休止している一部の機能を即座に起動させ、ＯＬＴ１０へフレームを転送する機能を備えるのが好適である。また、ＵＮＩ１２１からのトラヒック流入が存在する場合、ＯＬＴ１０からのスリープ指令に対して拒否応答（ＮＡＣＫメッセージ）を返し、一部の機能の休止を中止するようにすることもできる。なお、上述した各メッセージ（ＡＣＫメッセージ、ＮＡＣＫメッセージ、トラヒック確認メッセージ、ＮＯメッセージ、及びＹＥＳメッセージ）の送受信には、例えばＭＰＣＰ基２３やＯＡＭ基２４を用いることができる。 ［０２２３］ 以下では、例えば、無通信状態を使用帯域（トラヒック量）によって判定する場合について説明する。 ［０２２４］ 例えば、ＲＴＰやＳＩＰを利用したＶｏＩＰ通信などの高優先トラヒックのコネクションが存在する場合には、高優先トラヒックに対する通信品質を保持するために、いかなる場合でもＯＮＵ２０の機能を休止させないことにする。 ［０２２５］ このために、ＯＬＴ１０のキュー管理部１２は、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケットのヘッダに格納されたＴｏＳ値をフレームごとに観測する機能を具備し、ＶｏＩＰトラヒックの有無を確認する。または、ＩＰパケットのＴｏＳ値をＶＬＡＮ（Ｖｉｒｔｕａｌ ＬＡＮ）タグ付きＭＡＣフレームに格納されるＣｏＳ値と一対一に対応するように運用し、ＣｏＳ値をフレームごとに観測する機能を具備する。 ［０２２６］ 次に、ＯＬＴ１０の機能について図２２を用いて説明する。図２２は、ＯＬＴ１０の機能ブロック図である。 ［０２２７］ ［ＯＬＴの機能］ 図２２では、キュー管理部１２が、ＩＰパケットのＴｏＳ値をＶＬＡＮタグ付きＭＡＣフレームに格納されるＣｏＳ値と一対一に対応するように運用し、ＣｏＳ値をフレームごとに観測する場合について示している。 ［０２２８］ また、キュー管理部１２は、ＶＬＡＮタグ内で指定されるＶＬＡＮ－ＩＤと、ＰＯＮのＬＬＩＤ（Ｌｏｇｉｃａｌ Ｌｉｎｋ ＩＤ）とを対応させて通信を行うことを前提としている。ＬＬＩＤとは、各ロジカルリンクに割り当てられる識別子である。 ［０２２９］ 観測部・休止判定部３１は、観測部１４及び休止判定部１３の機能をまとめて１つのブロックで表したものである。観測部・休止判定部３１は、キュー管理部１２で処理されるフレームのＶＬＡＮ－ＩＤごとに、トラヒック量及びトラヒックの優先度を観測し、それらに基づいて休止判定を行う。 ［０２３０］ 観測部・休止判定部３１は、あるＶＬＡＮ－ＩＤに対し、一定時間ｔ１の期間にトラヒック量が閾値以下であり、かつ、特定の優先度（ＴｏＳ値又はＣｏＳ値）のトラヒックを観測しなかった場合には、一部の機能を休止するとの判定をし、対応するＬＬＩＤに対してスリープ指令メッセージを送信する（３１１）。スリープ指令メッセージは、ＭＰＣＰフレーム又はＯＡＭフレームの１つとして定義される。なお、３１１～３１４中に示したｋは、ＯＬＴに登録されている各ＯＮＵに対応する値であり、例えば、ＯＬＴにｎ台のＯＮＵが登録されている場合には、１≦ｋ≦ｎの範囲の値となる。 ［０２３１］ トラヒック量が閾値以下であり、かつ、特定の優先度のトラヒックを観測した場合には、一部の機能を休止しないとの判定をし、一定時間ｔ３の期間、スリープ指令メッセージを送信することなく、トラヒックの観測を継続する（３１２）。 ［０２３２］ 一定時間ｔ１の期間にトラヒック量が閾値以上であった場合には、特定の優先度のトラヒックを観測したか否かにかかわらず、一部の機能を休止しないとの判定をする（３１３、３１４）。 ［０２３３］ ＰＯＮ信号処理部１１が有するＭＰＣＰ／ＯＡＭ基３２は、ＭＰＣＰ基１５又はＯＡＭ基１６を表している。ＭＰＣＰ／ＯＡＭ基３２は、下り信号の場合には、ＶＬＡＮ－ＩＤにＬＬＩＤを対応付け、上り信号の場合には、ＬＬＩＤにＶＬＡＮ－ＩＤを対応付ける。また、観測部・休止判定部３１からスリープ指令メッセージを受信した場合には、ＭＰＣＰフレーム又はＯＡＭフレームの１つとして送信する。 ［０２３４］ ここで、ＯＬＴ１０は、ＯＮＵ２０が休止状態であるときに該ＯＮＵ２０宛てのトラヒックが発生した場合、損失フレーム数をゼロに抑えるために、到着したフレームを一時的に格納するバッファ（バッファ容量は休止時間に転送可能な最大転送量とする）を備えるのが好適である。 ［０２３５］ また、観測部１４は、休止判定部１３の判断を向上させるために、ＯＮＵ２０において破棄されるフレームについて、通信トラヒックの種類を監視する対象に含めないようにするのが好適である。 ［０２３６］ さらに、特定の種類のトラヒックが流通している場合であっても、特定の種類のトラヒックが当該ＯＮＵ２０において破棄されるフレームの場合には当該ＯＮＵ２０に対してスリープ指令メッセージを送信することもできる。例えば、ＰＯＮにおいてマルチキャスト通信を実現する方法として、ＯＬＴ１０からブロードキャストフレームをすべてのＯＮＵ２０へ送信し、ＯＮＵ２０側でフレームの識別子を用いてフィルタリングする方法が考えられる。このような場合でも、ＯＬＴ１０はマルチキャスト通信を行う対象のＯＮＵ２０とフレーム識別子の対応テーブルを保持しているため、ＯＬＴ１０側で送信先ＯＮＵ２０を特定することができる。 ［０２３７］ また、特定のプロトコルをフィルタリングするプロトコルフィルタがＯＮＵ２０に実装されている場合にもフィルタ情報をＯＬＴ１０が保持していれば、同様に適用することができる。このように、マルチキャストフレームがＰＯＮを流通している場合であっても、無通信状態のＯＮＵ２０だけを選択し、該ＯＮＵ２０の一部の機能を休止させることができる。 ［０２３８］ 次に、ＯＬＴ１０及びＯＮＵ２０の動作ついて、図２３及び図２４を用いて説明する。 ［０２３９］ ［ＯＬＴ及びＯＮＵの動作］ 図２３は、ＯＬＴ１０の動作の一例を示したフローチャートである。ＯＬＴ１０では各ＶＬＡＮ－ＩＤごとに図２３の処理が実行される。 ［０２４０］ ステップＳ４０１では、観測部１４により、計測時間Ｔｗが一定時間ｔ１に設定される。そして、処理をステップＳ４０２に進める。 ［０２４１］ ステップＳ４０２では、観測部１４により、タイマーをリセットした後にタイマーを起動させる。そして、処理をステップＳ４０３に進める。 ［０２４２］ ステップＳ４０３では、観測部１４により、タイマー値が計測時間Ｔｗ以上であるか否かを判定する。タイマー値が計測時間Ｔｗ以上でない場合には（ステップＳ４０３－Ｎｏ）、処理をステップＳ４０４に進め、タイマー値が計測時間Ｔｗ以上になった場合には（ステップＳ４０３－Ｙｅｓ）、処理をステップＳ４０５に進める。 ［０２４３］ ステップＳ４０４では、休止判定部１３により、トラヒックの有無を判定する。トラヒックが有る場合には（ステップＳ４０４－Ｙｅｓ）、処理をステップＳ４０７に進め、トラヒックが無い場合には（ステップＳ４０４－Ｎｏ）、処理をステップＳ４０３に戻す。 ［０２４４］ ステップＳ４０５では、計測時間Ｔｗの間トラヒックがないため、休止判定部１３により、無通信状態であると判断し、スリープ指令メッセージをＯＮＵ２０に送信する。そして、処理をステップＳ４０６に進める。 ［０２４５］ ステップＳ４０６では、観測部１４により、ＯＮＵ２０からトラヒック確認メッセージを受信したか否かを判定する。ＯＮＵ２０からトラヒック確認メッセージを受信した場合には（ステップＳ４０６－Ｙｅｓ）、処理をステップＳ４０１に戻し、トラヒック確認メッセージを受信していない場合には（ステップＳ４０６－Ｎｏ）、処理をステップＳ４０６に戻す。すなわち、ＯＮＵ２０からトラヒック確認メッセージを受信するまでの間、処理を停止する。 ［０２４６］ ステップＳ４０７では、休止判定部１３により、トラヒックが特定の優先度のトラヒックであるか否かを判定する。トラヒックが特定の優先度のトラヒックである場合には（ステップＳ４０７－Ｙｅｓ）、処理をステップＳ４０８に進め、トラヒックが特定の優先度のトラヒックでない場合には（ステップＳ４０７－Ｎｏ）、処理をステップＳ４０９に進める。 ［０２４７］ ステップＳ４０８では、観測部１４により、計測時間Ｔｗを一定時間ｔ３に設定する。そして、処理をステップＳ４０９に進める。計測時間Ｔｗを一定時間ｔ３に設定するのは、トラヒックが特定の優先度のトラヒックである場合には、ステップＳ４０３においてｔ１の期間ではなくｔ３の期間トラヒックが無い場合に、処理をステップＳ４０５に進めるようにするためである。このようにすることで、トラヒックの種類によって計測時間Ｔｗを変え、ＯＮＵの一部の機能を休止させる条件を変更することができる。 ［０２４８］ ステップＳ４０９では、ＯＬＴ１０はＯＮＵ２０と通信し、データを送受信する。そして、処理をステップＳ４１０に進める。 ［０２４９］ ステップＳ４１０では、ＯＬＴ１０がＯＮＵ２０と接続されているか否かを判定する。ＯＮＵ２０と接続されている場合には（ステップＳ４１０－Ｙｅｓ）、処理をステップＳ４０２に戻す。ＯＮＵ２０と接続されていない場合には（ステップＳ４１０－Ｎｏ）、処理は終了する。 ［０２５０］ 本フローチャートは、一例として、特定の優先度のトラヒックを観測した後は、一定時間ｔ３の期間、いずれのトラヒックも観測されなかった場合にスリープ指令メッセージを送信する動作例を示した。 ［０２５１］ 特定の優先度のトラヒックを観測後、一定時間ｔ３の期間、特定の優先度のトラヒックが観測されなかった場合には、さらに一定時間ｔ１の期間、いずれのトラヒックも観測されなければスリープ指令メッセージを送信する動作とすることもできる。この場合は、第２の時間計測手段（タイマー）を用い、特定の優先度のトラヒックを観測した際にこの第２の時間計測手段の値を０に設定（リセット）して起動し、第２の時間計測手段の値が一定時間ｔ３以上となった時点で、計測時間Ｔｗを一定時間ｔ１に設定し直すようにすればよい。 ［０２５２］ 図２４は、ＯＮＵ２０の動作の一例を示したフローチャートである。まず、ステップＳ５０１では、休止部２２により、トラヒックの有無を判定する。トラヒックが有る場合には（ステップＳ５０１－Ｙｅｓ）、処理をステップＳ５０２に進め、トラヒックが無い場合には（ステップＳ５０１－Ｎｏ）、処理をステップＳ５０３に進める。 ［０２５３］ ステップＳ５０２では、ＯＮＵ２０はＯＬＴ１０と通信し、データを送受信する。そして、処理をステップＳ５０５に進める。 ［０２５４］ ステップＳ５０３では、休止部２２により、ＯＬＴ１０からスリープ指令メッセージを受信したか否かを判定する。スリープ指令メッセージを受信した場合には（ステップＳ５０３－Ｙｅｓ）、処理をステップＳ５０４に進め、スリープ指令メッセージを受信していない場合には（ステップＳ５０３－Ｎｏ）、処理をステップＳ５０５に進める。 ［０２５５］ ステップＳ５０４では、休止部２２により、一定時間ｔ２の期間、ＯＮＵ２０の一部の機能を休止し、一定時間ｔ２の期間経過後に停止していた一部の機能を起動する。そして、処理をステップＳ５０５に進める。 ［０２５６］ ステップＳ５０５では、ＯＮＵ２０の電源がＯＦＦにされたか否かを判定する。電源がＯＦＦにされた場合には（ステップＳ５０５－Ｙｅｓ）、処理は終了し、電源がＯＮの場合には（ステップＳ５０５－Ｎｏ）、処理をステップＳ５０１に戻す。 ［０２５７］ 第３－１の実施形態によれば、特定の種類のトラヒックの通信品質を劣化させることなく、ＯＮＵ２０の省電力化を図ることができるようになる。」（５０～５６頁） 引用例の記載及び図面並びにこの分野における技術常識を考慮すると、上記イ．の［０００２］における「受動光ネットワーク（ＰＯＮ：Ｐａｓｓｉｖｅ　Ｏｐｔｉｃａｌ　Ｎｅｔｗｏｒｋ）は、１つの光加入者線終端装置（ＯＬＴ）が複数の光ネットワーク終端装置（ＯＮＵ）と光ファイバ伝送路および１対ｎの光スプリッタ（ｎは自然数）を介してポイントツーマルチポイントの通信を行うネットワークである。」との記載によれば、引用例の受動光ネットワーク（ＰＯＮ）は、ＯＮＵと、ＯＬＴから構成されている。 また、上記ロ．の［０２４４］における「ステップＳ４０５では、計測時間Ｔｗの間トラヒックがないため、休止判定部１３により、無通信状態であると判断し、スリープ指令メッセージをＯＮＵ２０に送信する。」との記載、及び図２２によれば、前述のＯＬＴは、ＯＮＵへスリープ指令メッセージを送信している。ここで、同ロ．の［０２３０］における「スリープ指令メッセージは、ＭＰＣＰフレーム又はＯＡＭフレームの１つとして定義される。」との記載によれば、前述のスリープ指令メッセージは、ＯＡＭフレームとして送信されるということができる。 また、上記ロ．の［０２５４］における「ステップＳ５０３では、休止部２２により、ＯＬＴ１０からスリープ指令メッセージを受信したか否かを判定する。スリープ指令メッセージを受信した場合には（ステップＳ５０３－Ｙｅｓ）、処理をステップＳ５０４に進め」との記載、同ロ．の［０２５５］における「ステップＳ５０４では、休止部２２により、一定時間ｔ２の期間、ＯＮＵ２０の一部の機能を休止し」との記載、及び図２４によれば、引用例には、「前記スリープ指令メッセージに応じてＯＮＵの一部の機能を休止するステップ」を含む、「ＯＮＵ（２０）とＯＬＴから構成され、ＯＮＵが、ＯＡＭフレームを受信して、ＯＮＵを休止する方法」について記載されているということができる。 したがって、上記引用例には、以下の発明（以下、「引用発明」という。）が記載されているものと認められる。 「ＯＮＵとＯＬＴから構成され、ＯＮＵが、ＯＡＭフレームを受信して、ＯＮＵを休止する方法であって、 ＯＬＴからＯＮＵへ前記ＯＡＭフレームによりスリープ指令メッセージを送信するステップと、 前記スリープ指令メッセージに応じてＯＮＵの一部の機能を休止するステップとを含む、 方法。」 （３）技術常識等 当審の平成２８年６月１日付け拒絶理由に引用されたＩＥＥＥ　Ｓｔｄ　８０２．３ａｈ－２００４，ＩＥＥＥ　Ｃｏｍｐｕｔｅｒ　Ｓｏｃｉｅｔｙ，２００４年９月７日　には図面とともに以下の事項が記載されている。 イ．「57.4.3.6 Organization Specific OAMPDU The optional Organization Specific OAMPDU, identified with the Code field set to 0xFE, is used for organization specific extensions. The Organization Specific OAMPDU frame structure shall be as depicted in Figure 57.15.」 訳文（イ．）「５７．４．３．６　組織専用ＯＡＭＰＤＵ ０ｘＦＥにセットされるコードフィールドで識別される、オプションの組織専用ＯＡＭＰＤＵは、組織専用拡張のために使用される。組織専用ＯＡＭＰＤＵフレーム構造は、図５７．１５に示される。」 ロ．「The first three octets of the Organization Specific OAMPDU Data field shall contain the Organizationally Unique Identifier (OUI).5 The format and function of the rest of the Organization Specific OAMPDU Data field is dependent on OUI value and is beyond the scope of this standard.」 訳文（ロ．）「組織専用ＯＡＭＰＤＵデータフィールドの最初の３オクテットは、組織固有の識別子（ＯＵＩ）を含む。組織専用ＯＡＭＰＤＵデータフィールドの残りのフォーマットと機能は、ＯＵＩの値に依存しており、この標準の範囲外のものである。」 ハ．「57.5.2.3 Organization Specific Information TLV The Organization Specific Information TLV shall have the following fields: a) Information Type = Organization Specific Information. This one-octet field indicates the nature of the data carried in this TLV-tuple. The encoding of this field is found in Table 57.6. b) Information Length. This one-octet field indicates the length (in octets) of this TLV_tuple. The length of an Organization Specific Information TLV is unspecified. c) Organizationally Unique Identifier. This three-octet field shall contain the 24-bit Organizationally Unique Identifier (OUI). d) Organization Specific Value. This field indicates the value of the Organization Specific Information TLV. This field’s length and contents are unspecified.」 訳文（ハ．）「５７．５．２．３　組織専用情報ＴＬＶ 組織専用情報ＴＬＶは、以下のフィールドを有するべきである。 ａ）情報タイプ＝組織専用情報。この１オクテットフィールドは、このＴＬＶタプルで担うデータの特徴を示す。このフィールドの符号化は、表７５．６に見られる。 ｂ）情報長。この１オクテットフィールドは、このＴＬＶタプルの長さを示す。組織専用情報ＴＬＶの長さは、特定されない。 ｃ）組織固有識別子。この３オクテットフィールドは、２４ビットの組織固有識別子（ＯＵＩ）を含むべきである。 ｄ）組織専用値。このフィールドは組織専用情報ＴＬＶの値を示す。このフィールドの長さと内容は特定されない。」 また、当審の平成２８年６月１日付け拒絶理由に引用された欧州特許出願公開第１８０１９８４号明細書には図面とともに以下の事項が記載されている。 ニ．「[0038] The sending of the alert message from the PON user terminal to the OLT may be implemented at different network layers, such as the multi-point control protocol (MPCP), the MAC, or the RS protocol layers, to adapt to the requirements of different PON standard protocols. For example, in the Ethernet passive optical network (EPON or Ethernet PON) standard protocol, the operation, administration, and maintenance (OAM) protocol extension can be used for the implementation. In the IEEE 802.3ah protocol specification (incorporated herein by reference), the OAM Organization Specific Information TLV is used in which the format of the control message is defined in the Organization Specific Value field following the definition of the Organizationally Unique Identifier (OUI) field, so that carrying of the above alert or response control messages can be implemented at the EPON OAM protocol layer. The OAM Organization Specific Information TLV is discussed in IEEE Draft P 802.3ah/D3.3, Paragraph 57.5.2.3, which is incorporated herein by reference.」 訳文（ニ．）「［００３８］ＰＯＮのユーザ端末からＯＬＴへアラートメッセージを送信することは、異なるＰＯＮ標準プロトコルの要件に適合するために、マルチ－ポイントコントロールプロトコル（ＭＰＣＰ）、ＭＡＣ、あるいはＲＳプロトコル層のような、異なるネットワーク層で実行されてもよい。例えば、イーサネットパッシブオプティカルネットワーク（ＥＰＯＮまたはイーサーネットＰＯＮ）標準プロトコルで、運用管理およびメインテナンス（ＯＡＭ）プロトコル拡張部分は、実行のために使用することができる。ＩＥＥＥ８０２．３ａｈプロトコル仕様では、ＯＡＭ組織専用情報ＴＬＶは、コントロールメッセージのフォーマットが組織固有識別子（ＯＵＩ）フィールドの定義に従った組織専用値フィールドに定義されるように使用される。そのため、上記アラートまたはレスポンスコントロールメッセージの保持は、ＥＰＯＮ　ＯＡＭプロトコル層で実行される。ＯＡＭ組織専用情報ＴＬＶは、参照することによってここに組み入れられる、ＩＥＥＥドラフトＰ８０２．３ａｈ／Ｄ３．３、パラグラフ５７．５．２．３で議論される。」 したがって、上記イ．～ハ．の記載、及び図５７．１５にみられるように、ＯＡＭフレームが、組織専用情報ＴＬＶフィールドを有することは技術常識であり、引用発明のＯＡＭフレームも具体的には当該構造を持ち得るところ、例えば、上記ニ．にみられるように、「ＯＡＭフレームにおいて、組織専用情報ＴＬＶフィールドにコントロールメッセージを組み入れること。」は、普通に行われているこということができる。 （４）対比 本願発明と引用発明とを対比する。 ａ．引用発明の「ＯＮＵ」及び「ＯＬＴ」は、それぞれ本願発明の「光ネットワークユニットＯＮＵ」及び「光回線端末ＯＬＴ」に相当する。 ｂ．本願明細書段落【００１１】における「省エネルギーメカニズムは、仮眠、又は快速睡眠、又は深度睡眠、又は周期睡眠を含む。」との記載によれば、本願発明の「省エネルギーメカニズム」は、快速睡眠を含んでいる。 一方、引用例の［０２５４］～［０２５５］の記載によれば、スリープ指令メッセージを受信すると直ちにＯＮＵの一部の機能を休止すると解されることから、引用発明は、「快速睡眠」を実現しているといえる。 また、引用発明の方法を、省エネルギーメカニズム管理を実現する方法と称することは任意のことである。 ｃ．本願明細書段落【０００９】における「省エネルギー情報は、入る省エネルギーメカニズムを指示する省エネルギーメカニズム指示を含む。」との記載、同段落【００１１】における「省エネルギーメカニズムは、仮眠、又は快速睡眠、又は深度睡眠、又は周期睡眠を含む。」との記載によれば、本願発明の「省エネルギー情報」は、快速睡眠指示を含むものと解される。 一方、引用発明の「スリープ指令メッセージ」も、快速睡眠を指示しているといえる。 したがって、引用発明の「スリープ指令メッセージ」は、本願発明の「省エネルギー情報」に含まれる。 ｄ．引用発明の「ＯＡＭフレーム」は、「運用管理およびメンテナンス（ＯＡＭ＝Operations，Administration，Maintenance）フレーム」であるから、引用発明と、本願発明とは、後述する相違点を除いて、「ＯＮＵとＯＬＴとの間に運用管理およびメンテナンス（ＯＡＭ）フレームを介して省エネルギー情報を伝送する」という点で一致する。 ｅ．引用発明の「ＯＮＵの一部の機能を休止する」と、本願発明の「ＯＮＵの光モジュールをオフ／オンにする」とは、後述する相違点を除いて、「ＯＮＵを睡眠させる」点で一致する。 ｆ．本願発明は、省エネルギー情報のキャリー方式として３つの選択肢を択一的に採用するものである。 そこで、そのうち、「前記省エネルギー情報のキャリー方式は、前記省エネルギー情報が、拡張ＯＡＭフレームのＯＡＭプロトコルデータユニット情報メッセージにおける組織専用情報タイプ－長さ－値フィールドに含まれる方式」と対比すると、引用発明とは、後述する相違点を除いて、「前記省エネルギー情報が、ＯＡＭフレームにて送信される」という点で一致する。 したがって、本願発明と引用発明は、以下の点で一致ないし相違している。 （一致点） 「光ネットワークユニットＯＮＵと光回線端末ＯＬＴとの間に省エネルギーメカニズム管理を実現する方法であって、 ＯＮＵとＯＬＴとの間に運用管理およびメンテナンス（ＯＡＭ）フレームを介して省エネルギー情報を伝送するステップと、 取得した省エネルギー情報に応じてＯＮＵを睡眠させるステップとを含み、 前記省エネルギー情報が、ＯＡＭフレームにて送信される 方法。」 （相違点１） 一致点の「運用管理およびメンテナンス（ＯＡＭ）フレーム」に関し、 本願発明は、「拡張ＯＡＭフレーム」であるのに対し、引用発明は、当該事項が明らかでない点。 加えて、 一致点の「前記省エネルギー情報が、ＯＡＭフレームにて送信される」に関し、 本願発明は、「前記省エネルギー情報のキャリー方式は、前記省エネルギー情報が、拡張ＯＡＭフレームのＯＡＭプロトコルデータユニット情報メッセージにおける組織専用情報タイプ－長さ－値フィールドに含まれる方式」であるのに対し、引用発明は、スリープ指令メッセージが、どこに含まれるか明らかでない点。 （相違点２） 一致点の「ＯＮＵを睡眠させる」に関し、 本願発明は、「ＯＮＵの光モジュールをオフ／オンにする」のに対し、引用発明は、ＯＮＵの一部の機能を休止するものの、「光モジュールをオフ／オンにする」ことが明らかでない点。 （５）判断 そこで、まず、上記相違点１について検討する。 上記「（３）技術常識等」の項のとおり、「ＯＡＭフレームにおいて、組織専用情報ＴＬＶフィールドにコントロールメッセージを組み入れること。」は、普通に行なわれていることである。 そうすると、当業者であれば、引用発明のＯＡＭフレームにおいて、組織専用情報ＴＬＶフィールドにスリープ指令メッセージを組み入れることに格別な困難性はない。 したがって、相違点１に係る構成は、引用発明及び周知技術に基づいて、当業者が容易に想到し得るものである。 次に、上記相違点２について検討する。 引用発明の「ＯＮＵの一部の機能を休止する」を具体的にどのように実現するかは、設計上の選択事項であるところ、光モジュールをオフ／オンすることは格別困難なことではなく、当業者が適宜なし得ることである。 そして、本願発明の作用効果も、引用発明及び周知技術から当業者が容易に予測できるものである。 第４　むすび 以上のとおり、本願は、特許法第３６条第６項第２号及び同法第３６条第４項第１号に規定する要件を満たしていないから、特許を受けることができな。また、本願発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 したがって、本願はその余の請求項について論及するまでもなく拒絶すべきものである。 よって、結論のとおり審決する。