【事件の表示】
　特願２００６−５４９１３８「メタＭＩＢを使用する自動アップデートシステム及び方法」拒絶査定不服審判事件〔平成１７年　７月２８日国際公開、ＷＯ２００５／０６９５４４、平成１９年　８月３０日国内公表、特表２００７−５２４９３９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、２００５年１月１４日（パリ条約による優先権主張外国庁受理２００４年１月１５日、韓国）を国際出願日とする出願であって、平成２０年１２月１６日付けの拒絶の理由の通知に対して、平成２１年６月１２日付けで意見書が提出されるとともに、同日付で手続補正がなされたが、平成２２年３月２６日付けで拒絶をすべき査定がされ、これに対し同年７月３０日に拒絶査定不服審判の請求がなされたものである。
　
２．本願発明
　本願の請求項１及び請求項２に係る発明は、平成２１年６月１２日付け手続補正により補正された特許請求の範囲の請求項１（以下「本願発明１」という。）、請求項２（以下「本願発明２」という。）に記載された次のとおりのものと認める。 
　
「【請求項１】
　エージェント及びネットワーク管理システム（ＮＭＳ）を有し、かつ、シンプルネットワークマネージメントプロトコル（ＳＮＭＰ）に基づくネットワークにおいて、メタＭＩＢを使用して前記エージェントのＭＩＢを自動アップデートするシステムであって、
　ＭＩＢ＿Ｉｎｆｏ＿Ｌａｓｔ＿Ｃｈａｎｇｅ＿Ｔｉｍｅと名付けられたＯＩＤを生成し、これを前記ＭＩＢに保存して、ＭＩＢ＿Ｉｎｆｏ＿Ｌａｓｔ＿Ｃｈａｎｇｅ＿Ｔｉｍｅが変化したときにトラップを転送することにより前記メタＭＩＢに同期させるエージェントと、
　あるトラップが前記ＮＭＳに入力された場合に、メタＭＩＢ＿Ｉｎｆｏの情報をＳＮＭＰウォーク・オペレーションによって読み出し、前記読み出し情報に基づいて前記エージェントのメタＭＩＢ情報を書き換え、そのメタＭＩＢ情報を前記ＭＩＢに保存し、前記メタＭＩＢ情報を前記エージェントに転送するＮＭＳと、
　を備えたことを特徴とするシステム。
【請求項２】
　ＭＩＢを有するネットワーク管理システム（ＮＭＳ）とＭＩＢを有するエージェントとの間の管理情報ベース（ＭＩＢ）情報をメタＭＩＢを使用して前記ネットワーク管理システム（ＮＭＳ）が自動アップデートするための方法であって、
　前記エージェントが生成したトラップを受信するステップであって、前記トラップは、ＭＩＢ＿Ｉｎｆｏ＿Ｌａｓｔ＿Ｃｈａｎｇｅ＿Ｔｉｍｅが変化したことを前記エージェントが検出すると送信されるものである、ステップと、
　前記トラップを受信すると、ウォーク・オペレーションを用いて、前記エージェントに保存されている前記ＭＩＢ情報を読み取るステップと、
　前記ウォーク・オペレーションの結果に基づいて、前記ネットワーク管理システム（ＮＭＳ）内のＭＩＢの表現の少なくとも一部を再構成するステップと
　を含む方法。」
　
３．原査定の理由
　
　一方、原査定の拒絶の理由の概要は、次のとおりである。
　
「　　　　　　　　　　　　　　　　理　由
　
１．この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。
２．この出願は、発明の詳細な説明の記載が下記の点で、特許法第３６条第４項第１号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　　　記
　
（１）請求項１及び請求項２に記載の「メタＭＩＢ」について、該請求項でいうところの「メタＭＩＢ」とはどのようなデータであるのかが定義されておらず、該「メタＭＩＢ」の技術上の範囲が不明である。
　
（２）〜（３）省略
　
３．この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　記　　　（引用文献等については引用文献等一覧参照）
　
・請求項　　　１、２
・引用文献等　１
・備考
　上記理由１及び２に示したように、本願の特許請求の範囲及び明細書の記載からは本願発明を明確に把握するのは極めて困難であるが、引用文献１（段落０００６〜００１１、０１３８〜０１４８、０２７５〜０２８７等）には、エージェントのタグテンプレート及びタグ定義リストのバージョン情報をそれぞれＭＩＢ上の所定のオブジェクトとして管理し、マネージャが、当該オブジェクトをエージェントから読み出して自身のタグテンプレート等のバージョン情報と比較し、両者が異なる場合に、エージェントの該タグテンプレートないしタグ定義リストを取得して書き換えることで、エージェントとマネージャのＭＩＢ情報の同期を取るシステムが記載され、上記タグテンプレート及びタグ定義リストは、ＭＩＢのシンタックス及びコンテキスト（意味）を定義するものであるから、本願発明でいう「メタＭＩＢ」に相当し、また、ＭＩＢ情報の更新をエージェントがＴｒａｐコマンドで通知すること、複数のオブジェクトをｓｎｍｐｗａｌｋコマンドで取得することは、いずれも当該技術分野における常套手段であるから、本願発明は、引用文献１に記載された発明から、当業者が容易になし得たものである。」
　
４．拒絶理由の１．（１）について
　
（１）拒絶の理由に対する審判請求人の主張内容
　拒絶理由の１．（１）に関して、平成２１年６月１２日付けの意見書において、以下のように釈明がなされている。
「まず、「メタＭＩＢ」とは、その記載自体から把握できるように、「メタデータ」と「ＭＩＢ」とを組み合わせた用語です。以下に、「メタデータ」と「ＭＩＢ」のそれぞれに分けてご説明したうえで、最後に「メタＭＩＢ」についてご説明いたします。
　「ＭＩＢ」とは「Management Information Base」の略語であり、日本語に翻訳すると、「管理情報ベース」となります（本願明細書段落［０００１］）。そして、本意見書と同時に提出する資料１（日本工業規格）によれば、「ＭＩＢは、ＯＳＩ管理プロトコルを使用することによって転送されたり、影響されたりする開放型システム内の情報とする。ＭＩＢは、開放型システム内の管理対象の集合とする。」と定義されています（資料１：日本工業規格　ＪＩＳ　Ｘ５００６「開放型システム間相互接続の基本参照モデル−管理の枠組み」、５．４節、１９９１年）。さらに、本願明細書には、「ＭＩＢは、ＮＥエージェント及びＮＭＳの間でＳＮＭＰを用いることよって交換される管理情報である」と記載されています（段落［００１０］）。
　次に、「メタデータ」とは、本意見書と同時に提出する資料２（日本工業規格）によれば、「データ記述を含むデータ要素に関するデータ、並びにデータの所有者、アクセス経路、アクセス権及びデータの変更度に関するデータ。」であると定義されています（資料２：日本工業規格　ＪＩＳ　Ｘ００１７「情報処理用語（データベース）」、番号１７．０６．０５、１９９７年）。
　すなわち、以上のＪＩＳ　Ｘ５００６とＪＩＳ　Ｘ００１７の定義に鑑みれば、「メタＭＩＢ」とは、「ＮＥエージェントとＮＭＳとの間で交換される管理情報の変更に関するデータ」であることが当業者の技術常識に照らして明らかなものと思料いたします。
　これをさらに具体的に説明するために、メタＭＩＢのツリー構造が図４に示されています（段落［００２０］）。図４の下から第４行目には、オブジェクト識別子（ＯＩＤ）の一つとして、「ｍｉｂＩｎｆｏＬａｓｔＣｈａｎｇｅＴｉｍｅ」（ＭＩＢ情報の最終変更時刻）が示されており、これは、請求項１の「ＭＩＢ＿Ｉｎｆｏ＿Ｌａｓｔ＿Ｃｈａｎｇｅ＿Ｔｉｍｅ」と同じものです。
　以上により、「メタＭＩＢ」は、それ自体明確なものです。よって、ご指摘の不備にはあたらないものと思料いたします。」
　
　同様に、平成２２年７月３０日に拒絶査定不服審判の請求における請求の理由において、以下のような主張もなされている。
「まず、「メタ」という用語はコンピュータ用語であり、本願出願日における技術常識として当業者に広く知られている用語です。これにつきましては、同時提出の資料１（コンピュータ英語活用辞典）をあわせてご覧下さい。
　また、「ＭＩＢ」というコンピュータ用語も、本願出願日における技術常識として当業者に広く知られています（資料２「コンピュータ用語英和対訳辞典」）。本願明細書では、「ＭＩＢ」とは「管理情報ベース」であるとした上で（段落［０００１］）、具体的には、「ＮＥエージェント及びＮＭＳの間でＳＮＭＰを用いることよって交換される管理情報」であるとしています（段落［００１０］）。
　つまり、「メタＭＩＢ」とは、「ＮＥエージェント及びＮＭＳの間でＳＮＭＰを用いることよって交換される管理情報」、すなわちＭＩＢの定義に関するデータという意味です（段落［００１０］）。
　この「メタＭＩＢ」を、本願の図２を用いて詳細に説明している資料３を同時に提出いたします。具体的には、メタＭＩＢは、ＮＭＳ（ネットワーク管理システム）１００に存在しています。そして、ＮＭＳ１００にあるメタＭＩＢは、エージェント２００にあるＭＩＢの内容と常に同じになるように保たれています。つまり、メタＭＩＢは、エージェント２００にあるＭＩＢのシャドーとして機能するものです（以上、段落［００１０］、［００１８］、図２）。
　以上により、ご指摘の不備は解消したものと思料いたします。」
　
（２）当審の判断
　本願の国際出願日における明細書の翻訳文（以下、当初明細書等という）には「メタＭＩＢ」の意味する内容及び定義についての特段の記載がなされていない。
　そこで「メタＭＩＢ」について上記主張に基づき検討する。上記主張における「メタデータ」という用語は当初明細書等には記載されておらず、「メタＭＩＢ」という用語が「メタデータ」と「ＭＩＢ」を組み合わせた用語であることを示す記載もなされていない。また、上記意見書において釈明されているように「メタＭＩＢ」が「メタデータ」と「ＭＩＢ」とを組み合わせた用語であるとしても、同意見書と共に提出された上記資料２には、「メタデータ」は「データ記述を含むデータ要素に関するデータ、並びにデータの所有者、アクセス経路、アクセス権及びデータの変更度に関するデータ」と定義されており、この内容から「メタデータ」が「変更に関するデータ」であるとする主張は成り立たない。よって、「メタＭＩＢ」が「ＮＥエージェントとＮＭＳとの間で交換される管理情報の変更に関するデータ」であるとする主張は、上記資料の「メタデータ」の定義に基づくものではなく、当該釈明により「メタＭＩＢ」の意味する内容及び定義は明かにはなっていない。
　仮に、上記意見書の釈明の通り「メタＭＩＢ」が「ＮＥエージェントとＮＭＳとの間で交換される管理情報の変更に関するデータ」であると解したとしても、「管理情報の変更に関するデータ」とはどのようなデータなのか、そして、どのようなデータが上記「管理情報の変更に関するデータ」に含まれ、どのようなデータは当該データには含まれないのかは当初明細書等によっても不明であり、「メタＭＩＢ」が示す技術的範囲は結局のところ不明である。
　また、メタＭＩＢのツリー構造が本願の図面の図４に示されているとの主張もなされているが、図４にはＭＩＢの全体の木構造がＭＩＢの情報を表示するブラウザにより表示されているものが示されているのであって、この図面から「メタＭＩＢ」が示す技術的範囲を把握することはできない。　
　さらに、拒絶査定不服審判の請求における請求の理由において「メタＭＩＢ」とは「ＮＥエージェント及びＮＭＳの間でＳＮＭＰを用いることよって交換される管理情報」すなわちＭＩＢの定義に関するデータという意味であるとの主張、及び、メタＭＩＢはエージェント２００にあるＭＩＢのシャドーとして機能するものであるとの主張がなされているが、シャドーとして機能するということは、写しのような内容を意味するものであるので、この主張によっても、ＭＩＢとメタＭＩＢはどのような関係にあり、どのような差異のあるデータまたは構成によるものであるかは依然として不めいりょうなままである。
　そうすると、本願の特許請求の範囲の請求項１及び請求項２に記載されている「メタＭＩＢ」はどのようなものであるか、技術的な範囲はどこを示すものであるのかを明確に把握することができない。また、本願の特許請求の範囲の請求項１及び請求項２の記載からは、当初明細書を参酌しても、どのような処理内容に基づいて「メタＭＩＢ」を用いてエージェントのＭＩＢを自動アップデートするものであるのかを明確に把握することができない。よって、本願の特許請求の範囲の請求項１及び請求項２の記載は明確ではない。
　したがって、本願は、特許法第３６条第６項第２号に規定する要件を満たしていない。
　
５．拒絶理由の３．について
　
（１）引用例に記載された発明
　原査定の拒絶の理由に引用された、特開２００３−１５０４６６号公報、平成１５年５月２３日公開（以下、「引用例」という。）には、図面とともに以下の記載がある。
　
Ａ．「【００１３】
【課題を解決するための手段】本発明は、エージェント側で管理情報の項目リストでありエンコード方法を記述したテンプレートと管理情報の実体データとを別に保持し、エージェント側からマネージャ側に、項目リストと項目リストに記されたエンコード方法でエンコードした実体データとをＳＮＭＰプロトコルを用いて送るようにした。
【００１４】これにより、エージェントはマネージャが必要とするすべての管理情報をひとかたまりとして一回のＳＮＭＰ応答で送信できるだけでなく、マネージャにおいては受信した管理情報を確実にデコードすることができる。この結果、応答性の良い管理システムを提供することができる。」（段落【００１３】−【００１４】）
　
Ｂ．「【００６８】（実施の形態１）以下、本発明の実施の形態１にかかる機器管理システムについて添付図面を参照しながら説明する。まず、実施の形態１にかかる機器管理システムの構成について、図１を用いて説明する。図１は、実施の形態１にかかる機器管理システムの構成図である。
【００６９】図１において、１０は機器管理ソフトウェアが稼動するマネージャであるＰＣであり、２０ａ、２０ｂは各々管理対象となるエージェントであるプリンタである。ＰＣ１０およびプリンタ２０ａ、２０ｂはネットワークケーブルなどの通信媒体３０によって接続されているものとする。」（段落【００６８】−【００６９】）
　
Ｃ．「【００８１】図４において、プリンタ２０は、ネットワークインタフェース部４１０と、印刷実行部４７０と、状態検出部４８０、ＭＩＢ制御部４６０、ＭＩＢデータベース４５０と、からなる装置として動作している。なお、図３におけるネットワークインタフェースカード３１６が、ネットワークインタフェース部４１０として機能しており、図３におけるネットワークインタフェースカード３１６を除く部分が、印刷実行部４７０、状態検出部４８０として機能している。また、ＣＰＵ３１１、ＲＡＭ３１４、ＨＤＤ３１５が、ＭＩＢ制御部４６０として機能している。また、図３におけるＨＤＤ３１５がＭＩＢデータベース４５０に対応している。
【００８２】ネットワークインタフェース部４１０は、通信媒体３０を介して他装置との間でパケットの送受信を行うパケット送受信部４１１と、パケット送受信部４１１によって受信されたパケットからデータを再構築するデータ生成部４１３とを備える。また、ネットワークインタフェース部４１０は、データ生成部４１３が生成したデータが印刷データである場合には、当該データを印刷実行部４７０に供給し、データ生成部４１３が生成したデータがＳＮＭＰメッセージである場合にはそのデータをＭＩＢ制御部４６０に供給するデータ判別部４１４を備える。さらに、ネットワークインタフェース部４１０は、ＭＩＢ制御部４６０から与えられたデータに応じたパケットを生成し、パケット送受信部４１１に供給するパケット生成部４１２を備える。
【００８３】このような構成により、ネットワークインタフェース部４１０は、他装置がプリンタ２０宛てに送信した印刷データを印刷実行部４７０に供給し、他装置がプリンタ装置２０宛てに送信したＳＮＭＰメッセージをＭＩＢ制御部４６０に供給する。そして、印刷実行部４７０は、ネットワークインタフェース部４１０から供給された印刷データに基づき、用紙上への印刷を行う。また、ネットワークインタフェース部４１０は、ＭＩＢ制御部４６０から与えられたデータに応じたパケット群を生成し、通信媒体３０上に送信する。
【００８４】また、状態検出部４８０は、印刷実行部４７０をはじめとしてプリンタ装置２０の各部の状態を検出する機能を有する。
【００８５】また、ＭＩＢデータベース４５０は、ＲＦＣ１５１４（Ｈｏｓｔ  ｒｅｓｏｕｒｃｅ  ＭＩＢ）、ＲＦＣ１７５９（Ｐｒｉｎｔｅｒ  ＭＩＢ）等で定義されたＭＩＢオブジェクト（ｈｒＤｅｖｉｃｅＳｔａｔｕｓ、ｐｒｔＭａｋｅｒＴｅｃｈ等）を含むデータベースである。ＭＩＢデータベース４５０の内容は、状態検出部４８０によって検出された各部の状態に応じてＭＩＢ制御部４６０が書き換える。
【００８６】また、ＭＩＢ制御部４６０は、ネットワークインタフェース部４１０から供給されたデータが、アクセスが許可されているＳＮＭＰマネージャ（実施の形態１では、図１のＰＣ１０）からのＳＮＭＰメッセージであった場合には、ネットワークインタフェース部４１０を制御し、送られてきたＳＮＭＰメッセージの要求に応じた情報（ＭＩＢオブジェクト）をＭＩＢデータベース４５０内から抽出し、ＳＮＭＰメッセージを送信してきたＳＮＭＰマネージャに返送する。アクセス許可の可否は、例えばＳＮＭＰマネージャが発行したデータに含まれるＣｏｍｍｕｎｉｔｙストリングをチェックすることによってなされる。
【００８７】さらに、ＭＩＢ制御部４６０は、プリンタ２０の状態が変化した場合、その旨を示すＴＲＡＰメッセージを、ＰＣ１０（トラップの宛先として設定されている装置）に対して送出する。すなわち、ＭＩＢ制御部４６０は、各部の状態を検出しており、状態に変化があった場合には、ＭＩＢデータベース４５０の内容を更新する。次いで、ＭＩＢ制御部４６０は、ネットワークインタフェース部４１０を制御することにより、ＰＣ１０に対して、状態が変化したことを示すＴＲＡＰメッセージを送出する。
【００８８】なお、ＰＣ１０のＩＰアドレス等（Ｃｏｍｍｕｎｉｔｙ名やＴＲＡＰメッセージ宛先等）のプリンタ２０への設定は、一般的なＳＮＭＰベースのシステムと同様に、ＳＮＭＰマネージャであるＰＣ１０からプリンタ２０への通知、またはプリンタ２０のコントロールパネル３２０からユーザが設定することによって行なわれる。
【００８９】次に、実施の形態１にかかるＭＩＢデータベースについて説明する。実施の形態１にかかるＭＩＢデータベースは、複数の要素をエンコードするエンコード方法を記述したテンプレートを設けたものである。これにより、マネージャはエージェントからテンプレートを取得して、エージェントで用いている要素群のエンコード方法を知ることができる。さらに、エージェント側で採用しているエンコード方法が何らかの理由で変更された場合でも、マネージャは変更したエンコード方法を遅滞なく知ることができる。
【００９０】実施の形態１にかかるＭＩＢデータベースの構造について図５から図９を用いて説明する。
【００９１】図５は、実施の形態１にかかるＭＩＢデータベースの構成を示す図である。図５に示すように、ＭＩＢデータベースは木構造にて表現され、全てのノードが一意に番号付けられている。各ノードは数字列よりなる固有の識別子を有し、これはオブジェクトＩＤ（Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ）と呼ばれている。図５の例では、例えば「ｉｓｏ」がノード名、その後の「（１）」がオブジェクトＩＤである。
【００９２】プリンタ２０ａ、２０ｂとも、ＳＮＭＰで管理される機器が標準的に備えている標準ＭＩＢと、企業や団体などが独自のＭＩＢ定義を行うことで独自拡張のできるプライベートＭＩＢとを搭載している。
【００９３】標準ＭＩＢとしては、同図のｍｉｂ−ＩＩ（ＲＦＣ１２１３  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ  ｆｏｒ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  ｏｆ  ＴＣＰ／ＩＰ−ｂａｓｅｄ  Ｉｎｔｅｒｎｅｔｓ：ＭＩＢ−ＩＩ）５３１と、ｈｒｍｉｂ（Ｈｏｓｔ  ｒｅｓｏｕｒｃｅ  ＭＩＢ（ＲＦＣ１５１４））５３２と、プリンタに関するｐｒｔｍｉｂ（（ＰｒｉｎｔｅｒＭＩＢ）ＲＦＣ１７５９）５３３がある。
【００９４】また、プライベートＭＩＢとしては、企業番号として２５８がＩｎｔｅｒｎｅｔ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒ  Ａｕｔｈｏｒｉｔｙ（ＩＡＮＡ）より割り当てられている、本発明では、プライベートＭＩＢとして松下電器産業株式会社独自のＭＩＢである松下ＭＩＢ５００を使用する。プライベートＭＩＢ５００はｅｎｔｅｒｐｒｉｓｅｓノード５４４の下のｐａｎａｓｏｎｉｃノード５４５の下に展開されている。よって、プライベートＭＩＢはオブジェクトＩＤ１．３．６．１．４．１．２５８以下に展開することができる。
【００９５】プライベートＭＩＢ５００のｐａｎａｓｏｎｉｃノード５４５の下には、ｊｏｂノード５０１、タグテンプレート（後に詳述）を表すｊｏｂＴａｇＤｅｆノード５１０、ジョブ情報を含むテーブル５２０、テーブル５２０の定義であるｊｏｂＴａｂｌｅ５２１、テーブル５２０に含まれる情報の一覧リストをあらわすエントリであるｊｏｂＥｎｔｒｙ５２２、ｊｏｂＴａｂｌｅ５２０のインデクスであるｊｏｂＩｎｄｅｘノード５２３、ジョブ情報を含むｊｏｂＤａｔａノード５３０より構成されている。
【００９６】ＭＩＢの構造は、管理情報構造（ＳＭＩ：Ｓｔｒｕｃｔｕｒｅ  ｏｆ  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ）と呼ばれ、ＲＦＣ１１５５  Ｓｔｒｕｃｔｕｒｅ  ａｎｄ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｏｆ  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  ｆｏｒ  ＴＣＰ／ＩＰ−ｂａｓｅｄ  Ｉｎｔｅｒｎｅｔｓで規定されており、プロトコル構文規定言語ＡＳＮ．１（Ａｂｓｔｒａｃｔ  Ｓｙｎｔａｘ  Ｎｏｔａｔｉｏｎ  Ｏｎｅ＝抽象構文記法．１）というＯＳＩ言語を使って定義されている。
【００９７】次に、実施の形態１にかかるＭＩＢデータベースをＡＳＮ．１で記述したものについて図６を用いて説明する。図６は、実施の形態１にかかるＭＩＢデータベースをＡＳＮ．１で記述したものを示す図である。
【００９８】ｊｏｂＴａｇＤｅｆノード５１０は記述６１０部分に、テーブル５２０は記述６２０に相当する。また、記述６２０の記述６２１はｊｏｂｔａｂｌｅ５２１、記述６２２はｊｏｂＥｎｔｒｙ５２２に、記述６２３はＪｏｂＩｎｄｅｘ５２３に、記述６３０はｊｏｂＤａｔａノード５３０にそれぞれ相当する。
【００９９】次に、実施の形態１にかかる機器管理システムで用いられるタグテンプレート（ｊｏｂＴａｇＤｅｆ５１０）について図７を用いて説明する。図７は、実施の形態１にかかるタグテンプレートを定義する方式を示した図である。
【０１００】タグテンプレート８３０は、データ構造オブジェクト７００の集合として定義される。データ構造オブジェクト７００は、固定長のフォーマットを持ったデータ構造リストの集合であり、それぞれ３２バイトのデータタグ番号７０１、データ属性７０２、データ長７０３、先頭からのオフセット量７０４から構成される。
【０１０１】データタグ番号７０１は、タグ定義リスト８１０で定義されたタグＩＤのいずれかの値を持つ。なお、タグ定義リストは、図２のＨＤＤ２０２および図３のＨＤＤ３１５に格納されている。
【０１０２】タグ定義リスト８１０は、ジョブ情報に関する項目をＴＡＧＩＤに対応づけたテーブルである。タグ定義リスト８１０では、ＴＡＧＩＤの１にＪＯＢＩＤ、ＴＡＧＩＤの２にＪＯＢ（ジョブ）のサイズ、ＴＡＧＩＤの３にＪＯＢの名前、ＴＡＧＩＤの４にＪＯＢの種類、ＴＡＧＩＤの５にＪＯＢの開始時刻、ＴＡＧＩＤの６にＪＯＢの終了時刻、ＴＡＧＩＤの７にＪＯＢステータス、ＴＡＧＩＤの８にＪＯＢエラーコード、ＴＡＧＩＤの９にＪＯＢ送信元が割り当てられている。
【０１０３】データ属性７０２は、タイプ定義リスト８２０で定義されたＴＹＰＥＩＤのいずれかの値を持つ。なお、タイプ定義リスト８２０は、図２のＨＤＤ２０２および図３のＨＤＤ３１５に格納されている。
【０１０４】例えば非負整数ならＴＹＰＥＩＤが１、符号付整数ならＴＹＰＥＩＤが２、文字列ならＴＹＰＥＩＤが３、実数ならＴＹＰＥＩＤが４、論理値ならＴＹＰＥＩＤ５、複素数ならＴＹＰＥＩＤ６で表される。
【０１０５】データ長７０３はジョブ情報を構成する各項目データの長さをバイト数で記述したものである。オフセット７０４は、先頭からのオフセット量を記述する。
【０１０６】このようにタグテンプレート８３０を構成することで、ジョブに関する必要な情報および、その情報の配置をタグテンプレート８３０に含ませることができる。
【０１０７】また、タグ定義リストやタイプ定義リスト内の種別をリストに記述された識別子を用いることでテンプレートをコンパクトにできる。
【０１０８】また、このタグテンプレート８３０はｊｏｂＴａｇＤｅｆノード５１０としてプリンタ２０のＭＩＢデータベース４５０に実装される。よって、タグテンプレート８３０は、記述６１０からオブジェクトＩＤ１．３．６．１．４．１．２５８．９９５．１に対するデータ取得要求をもってプリンタ２０からＰＣ１０が取得することが可能である。
【０１０９】なお、タグ定義リスト８１０、タイプ定義リスト８２０はＰＣ１０、プリンタ２０双方で適用を一にしておく必要がある。これは、正確にデコードするためには、ＰＣ１０とプリンタ２０間で同一のタグ定義を共有する必要があるからである。」（段落【００８１】−【０１０９】）
　
Ｄ．「【０１１６】次に、実施の形態１にかかるＰＣの機器管理処理について説明する。まず、ＰＣが実行する機器管理ソフトウェア（マネージャ）の構成について図９を用いて説明する。図９は、実施の形態１における機器管理ソフトウェアのモジュール構成を示す図である。
【０１１７】実施の形態１にかかる機器管理ソフトウェアは、図２に示すハードディスク２０２に格納されており、ＣＰＵ２０１ａによって実行される。その際、ＣＰＵ２０１ａはワークエリアとしてＲＡＭ２０１ｃを使用する。
【０１１８】図９において、１００１は一覧表示モジュールであり、通信媒体３０に接続されたプリンタ２０ａ、２０ｂなどを一覧にして表示するモジュールである。１００２は全体統括モジュールで、一覧表示モジュール１００１からの指示に基づき、他のモジュールを統括する。
【０１１９】１００３は探索モジュールで、通信媒体３０に接続されているプリンタを探索するモジュールである。この探索モジュール１００３によって探索されたプリンタが一覧表示モジュール１００１によって一覧表示される。プリンタを探索する方式は、たとえば既存の機器管理ソフトウェア（例えばＨＰ社のＪｅｔＡｄｍｉｎ（Ｒ）やＣＡＮＯＮ社のＮｅｔＳｐｏｔ（Ｒ））が採用しているＳＮＭＰメッセージをブロードキャストする方式などがある。
【０１２０】１００４は後述するプリンタ情報詳細ウィンドウを表示するためのＵＩ（Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）モジュールである。１００８は後述するジョブ表示ウィンドウを表示するためのジョブ表示モジュールである。
【０１２１】１００５は制御モジュールであり、プリンタの制御を受け持つモジュールである。制御モジュール１００５は、後述するＭＩＢモジュール１００６を用いてプリンタ２０ａ、２０ｂからＭＩＢデータを取得し、必要に応じてデータの変換を行い、ＵＩモジュール１００５およびジョブ表示モジュール１００８にデータを渡す。
【０１２２】ＭＩＢモジュール１００６は、オブジェクトＩＤに対する要求をＳＮＭＰエンコードして通信モジュール１００７を介して通信媒体３０上のプリンタ２０にデータ送信を実施、通信媒体３０上のプリンタ２０から受信したＳＮＭＰデータをデコードしてデータを取り出すモジュールである。
【０１２３】次に、図９に示す機器管理ソフトウェアを用いた機器管理システムの動作について述べる。
【０１２４】上述したようにＰＣ側の管理ソフトウェアを起動すると、ユーザはネットワーク機器一覧からプリンタを選択できる。プリンタの選択後、ジョブ管理画面に移行すると、管理ソフトウェアはプリンタにオブジェクトＩＤを指定することでデータ構造リストオブジェクトの取得要求を出す。要求を受け取ったプリンタは対応するデータ構造リストオブジェクトをＳＮＭＰレスポンスとして返す。それを受け取った管理ソフトウェアはＲＡＭにデータ構造リストを展開する。
【０１２５】以下、機器管理ソフトウェアを用いた機器管理システムの動作について図１０を用いて詳細に述べる。図１０は、実施の形態１にかかる機器管理システムの動作の処理を表すシーケンス図である。
【０１２６】ＰＣ１０（クライアントコンピュータ）が、印刷ジョブを、プリンタ２０に送信開始する（Ｓ１０１）。
【０１２７】プリンタ２０は、ＰＣ１０から送られてきた印刷ジョブをパケット送受信部４１１で受信開始する（Ｓ１０２）。そして、プリンタ２０のデータ生成部４１３がパケット送受信部４１１が受信した印刷ジョブのパケットからデータを再構築し、データ判別部４１４に送る。データ判別部４１４は、送られてきたデータが印刷要求であるので、受信したジョブ要求のデータを印刷実行部４７０に送る。
【０１２８】印刷実行部４７０は、受信した印刷ジョブにジョブＩＤを付加してジョブスプールを行う（Ｓ１０３）。ここで、印刷実行部４７０は、すでにスプールされているジョブとは異なったジョブＩＤを付与してジョブの管理を行い、ジョブ管理テーブルにはユーザ名、ジョブサイズ、ジョブ開始時刻などのデータが一緒に管理される（Ｓ１０４）。
【０１２９】次に、ＰＣ１０の制御モジュール１００５が、ＳＮＭＰ通信モジュール１００７、ＭＩＢモジュール１００６を用いてプリンタ２０に対しジョブ状態情報の取得を開始する（Ｓ１０５）。
【０１３０】まず、制御モジュール１００５は、プリンタ２０に対してｊｏｂＴａｇＤｅｆノード５１０で表されるタグテンプレート８３０の取得要求を開始し（Ｓ１０６）、ＳＮＭＰのＧＥＴＲＥＱＵＥＳＴを用いて出す（Ｓ１０７）。これに対して、プリンタ２０はＰＣ１０に対してタグテンプレートをＧＥＴＲＥＳＰＯＮＳＥで応答する（Ｓ１０８）。そして、ＰＣ１０は、プリンタ２０からのＧＥＴＲＥＳＰＯＮＳＥ応答に含まれるタグテンプレートの実体データを取得し（Ｓ１０９）、データ構造体に変換してＲＡＭ２０１ｃに保存する（Ｓ１１０）。
【０１３１】次に、制御モジュール１００５は、ｊｏｂＤａｔａ５３０で表される、プリンタ２０の印刷実行部４７０が管理しているスプールジョブ情報にＳＮＭＰのＧＥＴまたはＧＥＴＮＥＸＴ要求を用いてアクセスし、プリンタ２０のＧＥＴＲＥＳＰＯＮＳＥ応答を通じて個々のジョブ情報を得る（Ｓ１１１）。そして、制御モジュール１００５は、最終のジョブ情報まで取得したら（Ｓ１１２）、ＲＡＭ２０１ｃに保存したデータ構造体を読み出してマッチングをとることにより受信したジョブ情報のデコード処理を行う（Ｓ１１３）。
【０１３２】そして、制御モジュール１００５は、ジョブ情報のデコードが終了したら、デコードしたジョブ情報をジョブ表示モジュール１００８に送信し、ジョブ表示モジュール１００８がジョブ情報を画面表示する（Ｓ１１４）。
【０１３３】以上のように実施の形態１によれば、管理情報の項目リストでありエンコード方法を記述したタグテンプレート８３０と、管理情報であるジョブ情報の実体データである構造体９００とを別に保持し、マネージャであるＰＣ１０がエージェントであるプリンタ２０に別々のオブジェクトＩＤでアクセスすることで、プリンタ２０からＰＣ１０にタグテンプレート８３０とタグテンプレート８３０に記されたエンコード方法でエンコードしたジョブ情報とを送ることができる。これにより、従来のＳＮＭＰ機器管理の枠組みを変えることなく、テーブル内のすべてのジョブ詳細情報を一回のＳＮＭＰ要求・応答で処理することができるこの結果、応答性の良い管理システムを提供することができる。」（段落【０１１６】−【０１３３】）
　
Ｅ．「【０１４０】次に、実施の形態２にかかる機器管理システムについて、図１１を用いて説明する。図１１は、実施の形態２にかかるＰＣの処理を示すフロー図である。図１１は、ＰＣ１０がプリンタ２０に印刷ジョブを送信後の処理のフロー図である。
【０１４１】ＰＣ１０の制御モジュール１００５が、ＳＮＭＰ通信モジュール１００７、ＭＩＢモジュール１００６を用いてプリンタ２０にｊｏｂＴａｇＤｅｆノード５１０で表されるタグテンプレート８３０の取得要求を、ＳＮＭＰのＧＥＴ要求を用いて出し、プリンタ２０からのＧＥＴＲＥＳＰＯＮＳＥ応答に含まれるタグテンプレートの実体データの取得を開始する（Ｓ３０１）。
【０１４２】この段階では、既に、制御モジュール１００５が、プリンタ２０から以前にタグテンプレート８３０を取得、保存している状態であるとする。また、制御モジュールは１００５が受信するタグテンプレート８３０には、タグテンプレートのバージョンが付与されていて、バージョン情報も保存されているとする。
【０１４３】制御モジュール１００５は、現在プリンタ２０が使用しているタグテンプレートのバージョンを取得する（Ｓ３０２）。タグテンプレートのバージョンに関する情報は、タグテンプレートのヘッダ部に記述されているものとする。
【０１４４】次に、制御モジュール１００５は、ＰＣ１０がすでに保持しているタグテンプレートのバージョンと、今回の通信によって取得したタグテンプレートのバージョンを比較し（Ｓ３０３）、これらのバージョンが異なる場合は今回の通信によって取得したタグテンプレートでデータ構造体の置き換えを実施してＲＡＭ２０１ｃに保存する（Ｓ３０４）。
【０１４５】次に、制御モジュール１００５は、ｊｏｂＤａｔａ５３０で表される、プリンタ２０の印刷実行部４７０が管理しているスプールジョブ情報にＳＮＭＰのＧＥＴまたはＧＥＴＮＥＸＴ要求を用いてアクセスし、プリンタ２０のＧＥＴＲＥＳＰＯＮＳＥ応答を通じて個々のジョブ情報を得る（Ｓ３０５）。そして、制御モジュール１００５は、最終のジョブ情報まで取得したら（Ｓ３０６）、ＲＡＭ２０１ｃに保存したデータ構造体を読み出してマッチングをとることにより受信したジョブ情報のデコード処理を行う（Ｓ３０７）。
【０１４６】そして、制御モジュール１００５は、ジョブ情報のデコードが終了したら、デコードしたジョブ情報をジョブ表示モジュール１００８に送信し、ジョブ表示モジュール１００８がジョブ情報を画面表示する（Ｓ３０８）。
【０１４７】以上、実施の形態２によれば、プリンタのタグテンプレートが更新されバージョン情報が変更されない限り、タグテンプレートのデータ構造体変換処理をスキップできるため、全体の処理を効率化することができる。また、同一ネットワーク上に同種のプリンタがあって同じタグテンプレートを持っている場合には、プリンタ毎にタグテンプレートのデータ構造体変換処理をする必要がなくなる。
【０１４８】なお、実施の形態２では、タグテンプレートはバージョン情報を内包するとしたが、ＭＩＢの別オブジェクトに記録し、バージョンのチェックにはそれを参照するような構成でも良い。
【０１４９】（実施の形態３）本発明の実施の形態３は、ジョブを内蔵ハードディスク上にスプールする機能を有するプリンタを備えたシステムに対応したものであり、スプールしたジョブをＰＣからＳＮＭＰプロトコルを用いて制御するものである。」（段落【０１４０】−【０１４９】）
　
　以上の記載によれば、引用例には、次の発明（以下「引用発明」という。）が記載されている。
　
「機器管理ソフトウェアが稼働するマネージャであるＰＣ１０と、管理対象となるエージェントであるプリンタ２０とからなり、
　プリンタ２０は、ネットワークインタフェース部４１０と、ＭＩＢ制御部４６０、ＭＩＢデータベース４５０とを含み、
　ＭＩＢデータベース４５０は木構造にて表現され、プリンタ２０は、標準ＭＩＢと独自拡張のできるプライベートＭＩＢとを搭載しており、
　プライベートＭＩＢは、ジョブ情報（ｊｏｂＤａｔａ５３０）の実体データである構造体９００と、該実体データである構造体９００のデータ構造の定義（データ構造体）の集合であるタグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）とを保持し、
  機器管理ソフトウェアの構成であるＰＣ１０の制御モジュール１００５が、ＭＩＢモジュール１００６を用いてプリンタ２０からジョブ情報（ｊｏｂＤａｔａ５３０）の取得を開始する場合、タグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）を取得し、
　取得したタグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）が更新され、バージョン情報が変更されていれば、実体データである構造体９００のデータ構造の定義（データ構造体）を、取得したタグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）で置き換えて保存し、
　実体データである個々のジョブ情報を得、前記保存したデータ構造の定義（データ構造体）を読み出してマッチングを取ることによりジョブ情報をデコードする、
機器管理システム。」
　
（２）対比
　本願発明２と引用発明を対比する。
　
　引用発明において、「機器管理ソフトウェアが稼働するマネージャであるＰＣ１０」は、本願発明２の「ネットワーク管理システム（ＮＭＳ）」に相当する。
　次に、引用発明において、「ＭＩＢデータベース４５０」を有する「エージェントであるプリンタ２０」が、本願発明２の「ＭＩＢを有するエージェント」に相当する。
　次に、引用発明において、「タグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）」は、実体データである構造体９００のデータ構造の定義（データ構造体）の集合であるから、本願発明２の「ＭＩＢ情報」（ＭＩＢの定義情報を意味する用語と解釈して引用発明と対比する。なお、本解釈は、本願の請求項２の記載が不明りょうであることを前提とした解釈である。以下、同様。）の少なくとも一部に相当する。
　次に、引用発明において、取得した「タグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）が更新され」ている場合に、「ＰＣ１０が実行する機器管理ソフトウェア」が、「実体データである構造体９００のデータ構造の定義（データ構造体）を、取得したタグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）で置き換えて保存」することと、本願発明２の「管理情報ベース（ＭＩＢ）情報をメタＭＩＢを使用して前記ネットワーク管理システム（ＮＭＳ）が自動アップデートする」こととは、管理情報ベース（ＭＩＢ）情報の更新を、前記ネットワーク管理システム（ＮＭＳ）が自動アップデートする、点で共通する。
　次に、引用発明において、「ＰＣ１０が実行する機器管理ソフトウェア」が「エージェントであるプリンタ２０」から「タグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）を取得」することが、本願発明２の「前記エージェントに保存されている前記ＭＩＢ情報を読み取るステップ」に相当する。
　次に、引用発明において、「バージョン情報が変更されていれば、実体データである構造体９００のデータ構造の定義（データ構造体）を、取得したタグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）で置き換えて保存」することが、本願発明２の「前記ネットワーク管理システム（ＮＭＳ）内のＭＩＢの表現の少なくとも一部を再構成するステップ」（なお、本願発明２の「ＭＩＢの表現」とは、実体データの表現形式に関する情報を意味するものと解釈して対比した。）に相当する。
　
　よって、本願発明２と引用発明とは、次の点で一致する。
　
一致点
　
「ネットワーク管理システム（ＮＭＳ）とＭＩＢを有するエージェントとの間の管理情報ベース（ＭＩＢ）情報の更新を、前記ネットワーク管理システム（ＮＭＳ）が自動アップデータするための方法であって、
　前記エージェントに保存されている前記ＭＩＢ情報を読み取るステップと、
　前記ネットワーク管理システム（ＮＭＳ）内のＭＩＢの表現の少なくとも一部を再構成するステップと
　を含む方法。」
　
　一方、両者は次の点で相違する。
　
（相違点１）
　本願発明２では、「ネットワーク管理システム（ＮＭＳ）」が「ＭＩＢ」を有しているのに対し、引用発明では、「ＰＣ１０が実行する機器管理ソフトウェア」がＭＩＢを有しているか明らかでない点。
　
（相違点２）
　本願発明２では、「ＭＩＢ＿Ｉｎｆｏ＿Ｌａｓｔ＿Ｃｈａｎｇｅ＿Ｔｉｍｅ」が変化したことをエージェントが検出すると「トラップ」が送信され、「前記ネットワーク管理システム（ＮＭＳ）」は、該「トラップを受信」すると、「ウォーク・オペレーションを用いて、前記エージェントに保存されている前記ＭＩＢ情報を読み取」っているのに対し、引用発明では、「タグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）」（前記ＭＩＢ情報）を「エージェントであるプリンタ２０」（エージェント）から取得する契機に、かかるトラップは用いられておらず、また、「タグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）」（前記ＭＩＢ情報）を取得する手段としてウォーク・オペレーションを用いているか、明らかでない点。
　
（相違点３）
　本願発明２では、管理情報ベース（ＭＩＢ）情報の更新を、「メタＭＩＢを使用して」行っているのに対し、引用発明では、実体データである構造体９００のデータ構造の定義（データ構造体）（管理情報ベース（ＭＩＢ）情報）の置き換え（更新）を、「タグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）」を使用して行っているものの、「メタＭＩＢ」を使用して行っているか明らかでない点。
　
（３）当審の判断
（相違点１について）
　マネージャとエージェントとからなる管理システムにおいて、マネージャとエージェントとが共に「ＭＩＢ」を保持し、両者の設定内容を一致させることは、特開２００２−１４９５０９号公報：段落【０００１】〜【０００３】に記載されているように、周知技術である。
　よって、引用発明において、「機器管理ソフトウェアが稼働するマネージャであるＰＣ１０」（ネットワーク管理システム（ＮＭＳ））がＭＩＢを有するものとすることは、当業者が容易になし得たことである。
　
（相違点２について）
　ＭＩＢデータが変化するとエージェントがマネージャにトラップを送り、エージェントから送出された該トラップに応答して、マネージャが、変化したＭＩＢデータの取得を行うこと、及び、ＭＩＢからの情報の取得にウォーク・オペレーションを用いることは、共に周知技術である（それぞれ、特開２０００−６６９７８号公報：段落【０００２】、【０００６】）、及び、工藤智行、ＦｒｅｅＢＳＤサイト管理風雲録  第１２回、ＳＮＭＰの話（その２）、ＳｏｆｔｗａｒｅＤｅｓｉｇｎ、第１１８号、（株）技術評論社、２０００年８月１８日、ｐ．９０〜１０１、特に、第９０〜９１の「ｓｎｍｐｗａｌｋ」、第９２頁の「ｓｎｍｐｂｕｌｋｗａｌｋ」、参照。）。
　よって、引用発明において、「エージェントであるプリンタ２０」（エージェント）が「タグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）」（前記ＭＩＢ情報）の変化を検知すると「トラップ」が送信され、「ＰＣ１０が実行する機器管理ソフトウェア」（ネットワーク管理システム（ＮＭＳ））は、該トラップを受信すると、ウォーク・オペレーションを用いて、「エージェントであるプリンタ２０」（エージェント）に含まれている（保存されている）「タグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）」（前記ＭＩＢ情報）の取得（読み取り）を行うことは、当業者が容易になし得たことである。
　また、その際、情報の更新の有無を「日時」によって認識することは、当業者に普通に知られていることである（前記特開２００２−１４９５０９号公報：段落【００１４】の「ＭＩＢ１が更新されたことは、ファイル更新日属性等によって認識できる。」参照。）から、「エージェントであるプリンタ２０」（エージェント）による「タグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）」（前記ＭＩＢ情報）の変化の検知を、その更新の日時（「ＭＩＢ＿Ｉｎｆｏ＿Ｌａｓｔ＿Ｃｈａｎｇｅ＿Ｔｉｍｅ」）により検知することも、当業者が適宜なし得たことである。
　
（相違点３について）
　既に述べたとおり、本願発明２の「メタＭＩＢ」とはどのようなものであるのか、不明りょうである。
　しかし、引用発明の「タグテンプレート８３０（ｊｏｂＴａｇＤｅｆ）」が本願発明２の「メタＭＩＢ」に相当するか否かはともかくとして、引用発明は、「ＭＩＢデータベース４５０」のうち、実体データ（ジョブ情報）の構造体９００の「定義」が変更された場合であっても、該実体データ（ジョブ情報）の「定義」を記述する情報（タグテンプレート）を用いることによって、実体データ（ジョブ情報）の構造体９００の「定義」を置き換え（更新し）、該「定義」が変更された後の実体データ（ジョブ情報）の取得を可能にしている点で、本願発明２の「管理情報ベース（ＭＩＢ）情報」（前記ＭＩＢ情報、つまりＭＩＢの定義情報）の更新を「メタＭＩＢを用いて」「自動アップデートする」との要件を実質的に備えているものと認めることができる。
　
　そして、本願発明２の作用効果も、引用発明及び周知技術から当業者が予測できる範囲のものである。
　
（４）小活
　したがって、本願発明２は、引用例に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない。
　
６．むずび
　以上のとおりであるから、上記項目４で検討したように、本願は、原査定の拒絶理由で指摘したとおり、特許法第３６条第６項第２号に規定する要件を満たしていない。
　また、本願発明２は、上記項目５検討したように、引用例に記載された発明及び周知技術に基づいて当業者が容易に発明ができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。