拒絶査定不服の審決｜不服2010-17158 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

ポートフォリオを新規に作成して保存		追加
既存のポートフォリオに追加保存		追加

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 2項進歩性特許、登録しない。 G06F 審判査定不服特36条6項1、2号及び3号請求の範囲の記載不備特許、登録しない。 G06F
管理番号	1254265
審判番号	不服2010-17158
総通号数	149
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2012-05-25
種別	拒絶査定不服の審決
審判請求日	2010-07-30
確定日	2012-03-21
事件の表示	特願2006-549138「メタMIBを使用する自動アップデートシステム及び方法」拒絶査定不服審判事件〔平成17年 7月28日国際公開、WO2005/069544、平成19年 8月30日国内公表、特表2007-524939〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	1.手続の経緯本願は、2005年1月14日(パリ条約による優先権主張外国庁受理2004年1月15日、韓国)を国際出願日とする出願であって、平成20年12月16日付けの拒絶の理由の通知に対して、平成21年6月12日付けで意見書が提出されるとともに、同日付で手続補正がなされたが、平成22年3月26日付けで拒絶をすべき査定がされ、これに対し同年7月30日に拒絶査定不服審判の請求がなされたものである。 2.本願発明本願の請求項1及び請求項2に係る発明は、平成21年6月12日付け手続補正により補正された特許請求の範囲の請求項1(以下「本願発明1」という。)、請求項2(以下「本願発明2」という。)に記載された次のとおりのものと認める。「【請求項1】エージェント及びネットワーク管理システム(NMS)を有し、かつ、シンプルネットワークマネージメントプロトコル(SNMP)に基づくネットワークにおいて、メタMIBを使用して前記エージェントのMIBを自動アップデートするシステムであって、 MIB_Infｏ_Laｓｔ_Change_Timeと名付けられたOIDを生成し、これを前記MIBに保存して、MIB_Infｏ_Laｓｔ_Change_Timeが変化したときにトラップを転送することにより前記メタMIBに同期させるエージェントと、あるトラップが前記NMSに入力された場合に、メタMIB_Infｏの情報をSNMPウォーク・オペレーションによって読み出し、前記読み出し情報に基づいて前記エージェントのメタMIB情報を書き換え、そのメタMIB情報を前記MIBに保存し、前記メタMIB情報を前記エージェントに転送するNMSと、を備えたことを特徴とするシステム。【請求項2】 MIBを有するネットワーク管理システム(NMS)とMIBを有するエージェントとの間の管理情報ベース(MIB)情報をメタMIBを使用して前記ネットワーク管理システム(NMS)が自動アップデートするための方法であって、前記エージェントが生成したトラップを受信するステップであって、前記トラップは、MIB_Infｏ_Laｓｔ_Change_Timeが変化したことを前記エージェントが検出すると送信されるものである、ステップと、前記トラップを受信すると、ウォーク・オペレーションを用いて、前記エージェントに保存されている前記MIB情報を読み取るステップと、前記ウォーク・オペレーションの結果に基づいて、前記ネットワーク管理システム(NMS)内のMIBの表現の少なくとも一部を再構成するステップとを含む方法。」 3.原査定の理由一方、原査定の拒絶の理由の概要は、次のとおりである。「理由 1.この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第2号に規定する要件を満たしていない。 2.この出願は、発明の詳細な説明の記載が下記の点で、特許法第36条第4項第1号に規定する要件を満たしていない。記 (1)請求項1及び請求項2に記載の「メタMIB」について、該請求項でいうところの「メタMIB」とはどのようなデータであるのかが定義されておらず、該「メタMIB」の技術上の範囲が不明である。 (2)?(3)省略 3.この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。記 (引用文献等については引用文献等一覧参照) ・請求項 1、2 ・引用文献等 1 ・備考上記理由1及び2に示したように、本願の特許請求の範囲及び明細書の記載からは本願発明を明確に把握するのは極めて困難であるが、引用文献1(段落0006?0011、0138?0148、0275?0287等)には、エージェントのタグテンプレート及びタグ定義リストのバージョン情報をそれぞれMIB上の所定のオブジェクトとして管理し、マネージャが、当該オブジェクトをエージェントから読み出して自身のタグテンプレート等のバージョン情報と比較し、両者が異なる場合に、エージェントの該タグテンプレートないしタグ定義リストを取得して書き換えることで、エージェントとマネージャのMIB情報の同期を取るシステムが記載され、上記タグテンプレート及びタグ定義リストは、MIBのシンタックス及びコンテキスト(意味)を定義するものであるから、本願発明でいう「メタMIB」に相当し、また、MIB情報の更新をエージェントがTｒaｐコマンドで通知すること、複数のオブジェクトをｓnmｐｗalkコマンドで取得することは、いずれも当該技術分野における常套手段であるから、本願発明は、引用文献1に記載された発明から、当業者が容易になし得たものである。」 4.拒絶理由の1.(1)について (1)拒絶の理由に対する審判請求人の主張内容拒絶理由の1.(1)に関して、平成21年6月12日付けの意見書において、以下のように釈明がなされている。「まず、「メタMIB」とは、その記載自体から把握できるように、「メタデータ」と「MIB」とを組み合わせた用語です。以下に、「メタデータ」と「MIB」のそれぞれに分けてご説明したうえで、最後に「メタMIB」についてご説明いたします。「MIB」とは「Management Information Base」の略語であり、日本語に翻訳すると、「管理情報ベース」となります(本願明細書段落[0001])。そして、本意見書と同時に提出する資料1(日本工業規格)によれば、「MIBは、OSI管理プロトコルを使用することによって転送されたり、影響されたりする開放型システム内の情報とする。MIBは、開放型システム内の管理対象の集合とする。」と定義されています(資料1:日本工業規格 JIS X5006「開放型システム間相互接続の基本参照モデル-管理の枠組み」、5.4節、1991年)。さらに、本願明細書には、「MIBは、NEエージェント及びNMSの間でSNMPを用いることよって交換される管理情報である」と記載されています(段落[0010])。次に、「メタデータ」とは、本意見書と同時に提出する資料2(日本工業規格)によれば、「データ記述を含むデータ要素に関するデータ、並びにデータの所有者、アクセス経路、アクセス権及びデータの変更度に関するデータ。」であると定義されています(資料2:日本工業規格 JIS X0017「情報処理用語(データベース)」、番号17.06.05、1997年)。すなわち、以上のJIS X5006とJIS X0017の定義に鑑みれば、「メタMIB」とは、「NEエージェントとNMSとの間で交換される管理情報の変更に関するデータ」であることが当業者の技術常識に照らして明らかなものと思料いたします。これをさらに具体的に説明するために、メタMIBのツリー構造が図4に示されています(段落[0020])。図4の下から第4行目には、オブジェクト識別子(OID)の一つとして、「mibInfｏLaｓｔChangeTime」(MIB情報の最終変更時刻)が示されており、これは、請求項1の「MIB_Infｏ_Laｓｔ_Change_Time」と同じものです。以上により、「メタMIB」は、それ自体明確なものです。よって、ご指摘の不備にはあたらないものと思料いたします。」同様に、平成22年7月30日に拒絶査定不服審判の請求における請求の理由において、以下のような主張もなされている。「まず、「メタ」という用語はコンピュータ用語であり、本願出願日における技術常識として当業者に広く知られている用語です。これにつきましては、同時提出の資料1(コンピュータ英語活用辞典)をあわせてご覧下さい。また、「MIB」というコンピュータ用語も、本願出願日における技術常識として当業者に広く知られています(資料2「コンピュータ用語英和対訳辞典」)。本願明細書では、「MIB」とは「管理情報ベース」であるとした上で(段落[0001])、具体的には、「NEエージェント及びNMSの間でSNMPを用いることよって交換される管理情報」であるとしています(段落[0010])。つまり、「メタMIB」とは、「NEエージェント及びNMSの間でSNMPを用いることよって交換される管理情報」、すなわちMIBの定義に関するデータという意味です(段落[0010])。この「メタMIB」を、本願の図2を用いて詳細に説明している資料3を同時に提出いたします。具体的には、メタMIBは、NMS(ネットワーク管理システム)100に存在しています。そして、NMS100にあるメタMIBは、エージェント200にあるMIBの内容と常に同じになるように保たれています。つまり、メタMIBは、エージェント200にあるMIBのシャドーとして機能するものです(以上、段落[0010]、[0018]、図2)。以上により、ご指摘の不備は解消したものと思料いたします。」 (2)当審の判断本願の国際出願日における明細書の翻訳文(以下、当初明細書等という)には「メタMIB」の意味する内容及び定義についての特段の記載がなされていない。そこで「メタMIB」について上記主張に基づき検討する。上記主張における「メタデータ」という用語は当初明細書等には記載されておらず、「メタMIB」という用語が「メタデータ」と「MIB」を組み合わせた用語であることを示す記載もなされていない。また、上記意見書において釈明されているように「メタMIB」が「メタデータ」と「MIB」とを組み合わせた用語であるとしても、同意見書と共に提出された上記資料2には、「メタデータ」は「データ記述を含むデータ要素に関するデータ、並びにデータの所有者、アクセス経路、アクセス権及びデータの変更度に関するデータ」と定義されており、この内容から「メタデータ」が「変更に関するデータ」であるとする主張は成り立たない。よって、「メタMIB」が「NEエージェントとNMSとの間で交換される管理情報の変更に関するデータ」であるとする主張は、上記資料の「メタデータ」の定義に基づくものではなく、当該釈明により「メタMIB」の意味する内容及び定義は明かにはなっていない。仮に、上記意見書の釈明の通り「メタMIB」が「NEエージェントとNMSとの間で交換される管理情報の変更に関するデータ」であると解したとしても、「管理情報の変更に関するデータ」とはどのようなデータなのか、そして、どのようなデータが上記「管理情報の変更に関するデータ」に含まれ、どのようなデータは当該データには含まれないのかは当初明細書等によっても不明であり、「メタMIB」が示す技術的範囲は結局のところ不明である。また、メタMIBのツリー構造が本願の図面の図4に示されているとの主張もなされているが、図4にはMIBの全体の木構造がMIBの情報を表示するブラウザにより表示されているものが示されているのであって、この図面から「メタMIB」が示す技術的範囲を把握することはできない。さらに、拒絶査定不服審判の請求における請求の理由において「メタMIB」とは「NEエージェント及びNMSの間でSNMPを用いることよって交換される管理情報」すなわちMIBの定義に関するデータという意味であるとの主張、及び、メタMIBはエージェント200にあるMIBのシャドーとして機能するものであるとの主張がなされているが、シャドーとして機能するということは、写しのような内容を意味するものであるので、この主張によっても、MIBとメタMIBはどのような関係にあり、どのような差異のあるデータまたは構成によるものであるかは依然として不めいりょうなままである。そうすると、本願の特許請求の範囲の請求項1及び請求項2に記載されている「メタMIB」はどのようなものであるか、技術的な範囲はどこを示すものであるのかを明確に把握することができない。また、本願の特許請求の範囲の請求項1及び請求項2の記載からは、当初明細書を参酌しても、どのような処理内容に基づいて「メタMIB」を用いてエージェントのMIBを自動アップデートするものであるのかを明確に把握することができない。よって、本願の特許請求の範囲の請求項1及び請求項2の記載は明確ではない。したがって、本願は、特許法第36条第6項第2号に規定する要件を満たしていない。 5.拒絶理由の3.について (1)引用例に記載された発明原査定の拒絶の理由に引用された、特開2003-150466号公報、平成15年5月23日公開(以下、「引用例」という。)には、図面とともに以下の記載がある。 A.「【0013】【課題を解決するための手段】本発明は、エージェント側で管理情報の項目リストでありエンコード方法を記述したテンプレートと管理情報の実体データとを別に保持し、エージェント側からマネージャ側に、項目リストと項目リストに記されたエンコード方法でエンコードした実体データとをSNMPプロトコルを用いて送るようにした。【0014】これにより、エージェントはマネージャが必要とするすべての管理情報をひとかたまりとして一回のSNMP応答で送信できるだけでなく、マネージャにおいては受信した管理情報を確実にデコードすることができる。この結果、応答性の良い管理システムを提供することができる。」(段落【0013】-【0014】) B.「【0068】(実施の形態1)以下、本発明の実施の形態1にかかる機器管理システムについて添付図面を参照しながら説明する。まず、実施の形態1にかかる機器管理システムの構成について、図1を用いて説明する。図1は、実施の形態1にかかる機器管理システムの構成図である。【0069】図1において、10は機器管理ソフトウェアが稼動するマネージャであるPCであり、20a、20bは各々管理対象となるエージェントであるプリンタである。PC10およびプリンタ20a、20bはネットワークケーブルなどの通信媒体30によって接続されているものとする。」(段落【0068】-【0069】) C.「【0081】図4において、プリンタ20は、ネットワークインタフェース部410と、印刷実行部470と、状態検出部480、MIB制御部460、MIBデータベース450と、からなる装置として動作している。なお、図3におけるネットワークインタフェースカード316が、ネットワークインタフェース部410として機能しており、図3におけるネットワークインタフェースカード316を除く部分が、印刷実行部470、状態検出部480として機能している。また、CPU311、RAM314、HDD315が、MIB制御部460として機能している。また、図3におけるHDD315がMIBデータベース450に対応している。【0082】ネットワークインタフェース部410は、通信媒体30を介して他装置との間でパケットの送受信を行うパケット送受信部411と、パケット送受信部411によって受信されたパケットからデータを再構築するデータ生成部413とを備える。また、ネットワークインタフェース部410は、データ生成部413が生成したデータが印刷データである場合には、当該データを印刷実行部470に供給し、データ生成部413が生成したデータがSNMPメッセージである場合にはそのデータをMIB制御部460に供給するデータ判別部414を備える。さらに、ネットワークインタフェース部410は、MIB制御部460から与えられたデータに応じたパケットを生成し、パケット送受信部411に供給するパケット生成部412を備える。【0083】このような構成により、ネットワークインタフェース部410は、他装置がプリンタ20宛てに送信した印刷データを印刷実行部470に供給し、他装置がプリンタ装置20宛てに送信したSNMPメッセージをMIB制御部460に供給する。そして、印刷実行部470は、ネットワークインタフェース部410から供給された印刷データに基づき、用紙上への印刷を行う。また、ネットワークインタフェース部410は、MIB制御部460から与えられたデータに応じたパケット群を生成し、通信媒体30上に送信する。【0084】また、状態検出部480は、印刷実行部470をはじめとしてプリンタ装置20の各部の状態を検出する機能を有する。【0085】また、MIBデータベース450は、RFC1514(Hｏｓｔｒeｓｏｕｒce MIB)、RFC1759(Pｒinｔeｒ MIB)等で定義されたMIBオブジェクト(hｒDeｖiceSｔaｔｕｓ、ｐｒｔMakeｒTech等)を含むデータベースである。MIBデータベース450の内容は、状態検出部480によって検出された各部の状態に応じてMIB制御部460が書き換える。【0086】また、MIB制御部460は、ネットワークインタフェース部410から供給されたデータが、アクセスが許可されているSNMPマネージャ(実施の形態1では、図1のPC10)からのSNMPメッセージであった場合には、ネットワークインタフェース部410を制御し、送られてきたSNMPメッセージの要求に応じた情報(MIBオブジェクト)をMIBデータベース450内から抽出し、SNMPメッセージを送信してきたSNMPマネージャに返送する。アクセス許可の可否は、例えばSNMPマネージャが発行したデータに含まれるCｏmmｕniｔｙストリングをチェックすることによってなされる。【0087】さらに、MIB制御部460は、プリンタ20の状態が変化した場合、その旨を示すTRAPメッセージを、PC10(トラップの宛先として設定されている装置)に対して送出する。すなわち、MIB制御部460は、各部の状態を検出しており、状態に変化があった場合には、MIBデータベース450の内容を更新する。次いで、MIB制御部460は、ネットワークインタフェース部410を制御することにより、PC10に対して、状態が変化したことを示すTRAPメッセージを送出する。【0088】なお、PC10のIPアドレス等(Cｏmmｕniｔｙ名やTRAPメッセージ宛先等)のプリンタ20への設定は、一般的なSNMPベースのシステムと同様に、SNMPマネージャであるPC10からプリンタ20への通知、またはプリンタ20のコントロールパネル320からユーザが設定することによって行なわれる。【0089】次に、実施の形態1にかかるMIBデータベースについて説明する。実施の形態1にかかるMIBデータベースは、複数の要素をエンコードするエンコード方法を記述したテンプレートを設けたものである。これにより、マネージャはエージェントからテンプレートを取得して、エージェントで用いている要素群のエンコード方法を知ることができる。さらに、エージェント側で採用しているエンコード方法が何らかの理由で変更された場合でも、マネージャは変更したエンコード方法を遅滞なく知ることができる。【0090】実施の形態1にかかるMIBデータベースの構造について図5から図9を用いて説明する。【0091】図5は、実施の形態1にかかるMIBデータベースの構成を示す図である。図5に示すように、MIBデータベースは木構造にて表現され、全てのノードが一意に番号付けられている。各ノードは数字列よりなる固有の識別子を有し、これはオブジェクトID(Objecｔ Idenｔifieｒ)と呼ばれている。図5の例では、例えば「iｓｏ」がノード名、その後の「(1)」がオブジェクトIDである。【0092】プリンタ20a、20bとも、SNMPで管理される機器が標準的に備えている標準MIBと、企業や団体などが独自のMIB定義を行うことで独自拡張のできるプライベートMIBとを搭載している。【0093】標準MIBとしては、同図のmib-II(RFC1213 Managemenｔ Infｏｒmaｔiｏn Baｓe fｏｒ Neｔｗｏｒk Managemenｔｏf TCP/IP-baｓed Inｔeｒneｔｓ:MIB-II)531と、hｒmib(Hｏｓｔｒeｓｏｕｒce MIB(RFC1514))532と、プリンタに関するｐｒｔmib((PｒinｔeｒMIB)RFC1759)533がある。【0094】また、プライベートMIBとしては、企業番号として258がInｔeｒneｔ Aｓｓigned Nｕmbeｒ Aｕｔhｏｒiｔｙ(IANA)より割り当てられている、本発明では、プライベートMIBとして松下電器産業株式会社独自のMIBである松下MIB500を使用する。プライベートMIB500はenｔeｒｐｒiｓeｓノード544の下のｐanaｓｏnicノード545の下に展開されている。よって、プライベートMIBはオブジェクトID1.3.6.1.4.1.258以下に展開することができる。【0095】プライベートMIB500のｐanaｓｏnicノード545の下には、jｏbノード501、タグテンプレート(後に詳述)を表すjｏbTagDefノード510、ジョブ情報を含むテーブル520、テーブル520の定義であるjｏbTable521、テーブル520に含まれる情報の一覧リストをあらわすエントリであるjｏbEnｔｒｙ522、jｏbTable520のインデクスであるjｏbIndeｘノード523、ジョブ情報を含むjｏbDaｔaノード530より構成されている。【0096】MIBの構造は、管理情報構造(SMI:Sｔｒｕcｔｕｒe ｏf Managemenｔ Infｏｒmaｔiｏn)と呼ばれ、RFC1155 Sｔｒｕcｔｕｒe and Idenｔificaｔiｏn ｏf Managemenｔ Infｏｒmaｔiｏn fｏｒ TCP/IP-baｓed Inｔeｒneｔｓで規定されており、プロトコル構文規定言語ASN.1(Abｓｔｒacｔ Sｙnｔaｘ Nｏｔaｔiｏn One=抽象構文記法.1)というOSI言語を使って定義されている。【0097】次に、実施の形態1にかかるMIBデータベースをASN.1で記述したものについて図6を用いて説明する。図6は、実施の形態1にかかるMIBデータベースをASN.1で記述したものを示す図である。【0098】jｏbTagDefノード510は記述610部分に、テーブル520は記述620に相当する。また、記述620の記述621はjｏbｔable521、記述622はjｏbEnｔｒｙ522に、記述623はJｏbIndeｘ523に、記述630はjｏbDaｔaノード530にそれぞれ相当する。【0099】次に、実施の形態1にかかる機器管理システムで用いられるタグテンプレート(jｏbTagDef510)について図7を用いて説明する。図7は、実施の形態1にかかるタグテンプレートを定義する方式を示した図である。【0100】タグテンプレート830は、データ構造オブジェクト700の集合として定義される。データ構造オブジェクト700は、固定長のフォーマットを持ったデータ構造リストの集合であり、それぞれ32バイトのデータタグ番号701、データ属性702、データ長703、先頭からのオフセット量704から構成される。【0101】データタグ番号701は、タグ定義リスト810で定義されたタグIDのいずれかの値を持つ。なお、タグ定義リストは、図2のHDD202および図3のHDD315に格納されている。【0102】タグ定義リスト810は、ジョブ情報に関する項目をTAGIDに対応づけたテーブルである。タグ定義リスト810では、TAGIDの1にJOBID、TAGIDの2にJOB(ジョブ)のサイズ、TAGIDの3にJOBの名前、TAGIDの4にJOBの種類、TAGIDの5にJOBの開始時刻、TAGIDの6にJOBの終了時刻、TAGIDの7にJOBステータス、TAGIDの8にJOBエラーコード、TAGIDの9にJOB送信元が割り当てられている。【0103】データ属性702は、タイプ定義リスト820で定義されたTYPEIDのいずれかの値を持つ。なお、タイプ定義リスト820は、図2のHDD202および図3のHDD315に格納されている。【0104】例えば非負整数ならTYPEIDが1、符号付整数ならTYPEIDが2、文字列ならTYPEIDが3、実数ならTYPEIDが4、論理値ならTYPEID5、複素数ならTYPEID6で表される。【0105】データ長703はジョブ情報を構成する各項目データの長さをバイト数で記述したものである。オフセット704は、先頭からのオフセット量を記述する。【0106】このようにタグテンプレート830を構成することで、ジョブに関する必要な情報および、その情報の配置をタグテンプレート830に含ませることができる。【0107】また、タグ定義リストやタイプ定義リスト内の種別をリストに記述された識別子を用いることでテンプレートをコンパクトにできる。【0108】また、このタグテンプレート830はjｏbTagDefノード510としてプリンタ20のMIBデータベース450に実装される。よって、タグテンプレート830は、記述610からオブジェクトID1.3.6.1.4.1.258.995.1に対するデータ取得要求をもってプリンタ20からPC10が取得することが可能である。【0109】なお、タグ定義リスト810、タイプ定義リスト820はPC10、プリンタ20双方で適用を一にしておく必要がある。これは、正確にデコードするためには、PC10とプリンタ20間で同一のタグ定義を共有する必要があるからである。」(段落【0081】-【0109】) D.「【0116】次に、実施の形態1にかかるPCの機器管理処理について説明する。まず、PCが実行する機器管理ソフトウェア(マネージャ)の構成について図9を用いて説明する。図9は、実施の形態1における機器管理ソフトウェアのモジュール構成を示す図である。【0117】実施の形態1にかかる機器管理ソフトウェアは、図2に示すハードディスク202に格納されており、CPU201aによって実行される。その際、CPU201aはワークエリアとしてRAM201cを使用する。【0118】図9において、1001は一覧表示モジュールであり、通信媒体30に接続されたプリンタ20a、20bなどを一覧にして表示するモジュールである。1002は全体統括モジュールで、一覧表示モジュール1001からの指示に基づき、他のモジュールを統括する。【0119】1003は探索モジュールで、通信媒体30に接続されているプリンタを探索するモジュールである。この探索モジュール1003によって探索されたプリンタが一覧表示モジュール1001によって一覧表示される。プリンタを探索する方式は、たとえば既存の機器管理ソフトウェア(例えばHP社のJeｔAdmin(R)やCANON社のNeｔSｐｏｔ(R))が採用しているSNMPメッセージをブロードキャストする方式などがある。【0120】1004は後述するプリンタ情報詳細ウィンドウを表示するためのUI(Uｓeｒ Inｔeｒface)モジュールである。1008は後述するジョブ表示ウィンドウを表示するためのジョブ表示モジュールである。【0121】1005は制御モジュールであり、プリンタの制御を受け持つモジュールである。制御モジュール1005は、後述するMIBモジュール1006を用いてプリンタ20a、20bからMIBデータを取得し、必要に応じてデータの変換を行い、UIモジュール1005およびジョブ表示モジュール1008にデータを渡す。【0122】MIBモジュール1006は、オブジェクトIDに対する要求をSNMPエンコードして通信モジュール1007を介して通信媒体30上のプリンタ20にデータ送信を実施、通信媒体30上のプリンタ20から受信したSNMPデータをデコードしてデータを取り出すモジュールである。【0123】次に、図9に示す機器管理ソフトウェアを用いた機器管理システムの動作について述べる。【0124】上述したようにPC側の管理ソフトウェアを起動すると、ユーザはネットワーク機器一覧からプリンタを選択できる。プリンタの選択後、ジョブ管理画面に移行すると、管理ソフトウェアはプリンタにオブジェクトIDを指定することでデータ構造リストオブジェクトの取得要求を出す。要求を受け取ったプリンタは対応するデータ構造リストオブジェクトをSNMPレスポンスとして返す。それを受け取った管理ソフトウェアはRAMにデータ構造リストを展開する。【0125】以下、機器管理ソフトウェアを用いた機器管理システムの動作について図10を用いて詳細に述べる。図10は、実施の形態1にかかる機器管理システムの動作の処理を表すシーケンス図である。【0126】PC10(クライアントコンピュータ)が、印刷ジョブを、プリンタ20に送信開始する(S101)。【0127】プリンタ20は、PC10から送られてきた印刷ジョブをパケット送受信部411で受信開始する(S102)。そして、プリンタ20のデータ生成部413がパケット送受信部411が受信した印刷ジョブのパケットからデータを再構築し、データ判別部414に送る。データ判別部414は、送られてきたデータが印刷要求であるので、受信したジョブ要求のデータを印刷実行部470に送る。【0128】印刷実行部470は、受信した印刷ジョブにジョブIDを付加してジョブスプールを行う(S103)。ここで、印刷実行部470は、すでにスプールされているジョブとは異なったジョブIDを付与してジョブの管理を行い、ジョブ管理テーブルにはユーザ名、ジョブサイズ、ジョブ開始時刻などのデータが一緒に管理される(S104)。【0129】次に、PC10の制御モジュール1005が、SNMP通信モジュール1007、MIBモジュール1006を用いてプリンタ20に対しジョブ状態情報の取得を開始する(S105)。【0130】まず、制御モジュール1005は、プリンタ20に対してjｏbTagDefノード510で表されるタグテンプレート830の取得要求を開始し(S106)、SNMPのGETREQUESTを用いて出す(S107)。これに対して、プリンタ20はPC10に対してタグテンプレートをGETRESPONSEで応答する(S108)。そして、PC10は、プリンタ20からのGETRESPONSE応答に含まれるタグテンプレートの実体データを取得し(S109)、データ構造体に変換してRAM201cに保存する(S110)。【0131】次に、制御モジュール1005は、jｏbDaｔa530で表される、プリンタ20の印刷実行部470が管理しているスプールジョブ情報にSNMPのGETまたはGETNEXT要求を用いてアクセスし、プリンタ20のGETRESPONSE応答を通じて個々のジョブ情報を得る(S111)。そして、制御モジュール1005は、最終のジョブ情報まで取得したら(S112)、RAM201cに保存したデータ構造体を読み出してマッチングをとることにより受信したジョブ情報のデコード処理を行う(S113)。【0132】そして、制御モジュール1005は、ジョブ情報のデコードが終了したら、デコードしたジョブ情報をジョブ表示モジュール1008に送信し、ジョブ表示モジュール1008がジョブ情報を画面表示する(S114)。【0133】以上のように実施の形態1によれば、管理情報の項目リストでありエンコード方法を記述したタグテンプレート830と、管理情報であるジョブ情報の実体データである構造体900とを別に保持し、マネージャであるPC10がエージェントであるプリンタ20に別々のオブジェクトIDでアクセスすることで、プリンタ20からPC10にタグテンプレート830とタグテンプレート830に記されたエンコード方法でエンコードしたジョブ情報とを送ることができる。これにより、従来のSNMP機器管理の枠組みを変えることなく、テーブル内のすべてのジョブ詳細情報を一回のSNMP要求・応答で処理することができるこの結果、応答性の良い管理システムを提供することができる。」(段落【0116】-【0133】) E.「【0140】次に、実施の形態2にかかる機器管理システムについて、図11を用いて説明する。図11は、実施の形態2にかかるPCの処理を示すフロー図である。図11は、PC10がプリンタ20に印刷ジョブを送信後の処理のフロー図である。【0141】PC10の制御モジュール1005が、SNMP通信モジュール1007、MIBモジュール1006を用いてプリンタ20にjｏbTagDefノード510で表されるタグテンプレート830の取得要求を、SNMPのGET要求を用いて出し、プリンタ20からのGETRESPONSE応答に含まれるタグテンプレートの実体データの取得を開始する(S301)。【0142】この段階では、既に、制御モジュール1005が、プリンタ20から以前にタグテンプレート830を取得、保存している状態であるとする。また、制御モジュールは1005が受信するタグテンプレート830には、タグテンプレートのバージョンが付与されていて、バージョン情報も保存されているとする。【0143】制御モジュール1005は、現在プリンタ20が使用しているタグテンプレートのバージョンを取得する(S302)。タグテンプレートのバージョンに関する情報は、タグテンプレートのヘッダ部に記述されているものとする。【0144】次に、制御モジュール1005は、PC10がすでに保持しているタグテンプレートのバージョンと、今回の通信によって取得したタグテンプレートのバージョンを比較し(S303)、これらのバージョンが異なる場合は今回の通信によって取得したタグテンプレートでデータ構造体の置き換えを実施してRAM201cに保存する(S304)。【0145】次に、制御モジュール1005は、jｏbDaｔa530で表される、プリンタ20の印刷実行部470が管理しているスプールジョブ情報にSNMPのGETまたはGETNEXT要求を用いてアクセスし、プリンタ20のGETRESPONSE応答を通じて個々のジョブ情報を得る(S305)。そして、制御モジュール1005は、最終のジョブ情報まで取得したら(S306)、RAM201cに保存したデータ構造体を読み出してマッチングをとることにより受信したジョブ情報のデコード処理を行う(S307)。【0146】そして、制御モジュール1005は、ジョブ情報のデコードが終了したら、デコードしたジョブ情報をジョブ表示モジュール1008に送信し、ジョブ表示モジュール1008がジョブ情報を画面表示する(S308)。【0147】以上、実施の形態2によれば、プリンタのタグテンプレートが更新されバージョン情報が変更されない限り、タグテンプレートのデータ構造体変換処理をスキップできるため、全体の処理を効率化することができる。また、同一ネットワーク上に同種のプリンタがあって同じタグテンプレートを持っている場合には、プリンタ毎にタグテンプレートのデータ構造体変換処理をする必要がなくなる。【0148】なお、実施の形態2では、タグテンプレートはバージョン情報を内包するとしたが、MIBの別オブジェクトに記録し、バージョンのチェックにはそれを参照するような構成でも良い。【0149】(実施の形態3)本発明の実施の形態3は、ジョブを内蔵ハードディスク上にスプールする機能を有するプリンタを備えたシステムに対応したものであり、スプールしたジョブをPCからSNMPプロトコルを用いて制御するものである。」(段落【0140】-【0149】) 以上の記載によれば、引用例には、次の発明(以下「引用発明」という。)が記載されている。「機器管理ソフトウェアが稼働するマネージャであるPC10と、管理対象となるエージェントであるプリンタ20とからなり、プリンタ20は、ネットワークインタフェース部410と、MIB制御部460、MIBデータベース450とを含み、 MIBデータベース450は木構造にて表現され、プリンタ20は、標準MIBと独自拡張のできるプライベートMIBとを搭載しており、プライベートMIBは、ジョブ情報(jｏbDaｔa530)の実体データである構造体900と、該実体データである構造体900のデータ構造の定義(データ構造体)の集合であるタグテンプレート830(jｏbTagDef)とを保持し、機器管理ソフトウェアの構成であるPC10の制御モジュール1005が、MIBモジュール1006を用いてプリンタ20からジョブ情報(jｏbDaｔa530)の取得を開始する場合、タグテンプレート830(jｏbTagDef)を取得し、取得したタグテンプレート830(jｏbTagDef)が更新され、バージョン情報が変更されていれば、実体データである構造体900のデータ構造の定義(データ構造体)を、取得したタグテンプレート830(jｏbTagDef)で置き換えて保存し、実体データである個々のジョブ情報を得、前記保存したデータ構造の定義(データ構造体)を読み出してマッチングを取ることによりジョブ情報をデコードする、機器管理システム。」 (2)対比本願発明2と引用発明を対比する。引用発明において、「機器管理ソフトウェアが稼働するマネージャであるPC10」は、本願発明2の「ネットワーク管理システム(NMS)」に相当する。次に、引用発明において、「MIBデータベース450」を有する「エージェントであるプリンタ20」が、本願発明2の「MIBを有するエージェント」に相当する。次に、引用発明において、「タグテンプレート830(jｏbTagDef)」は、実体データである構造体900のデータ構造の定義(データ構造体)の集合であるから、本願発明2の「MIB情報」(MIBの定義情報を意味する用語と解釈して引用発明と対比する。なお、本解釈は、本願の請求項2の記載が不明りょうであることを前提とした解釈である。以下、同様。)の少なくとも一部に相当する。次に、引用発明において、取得した「タグテンプレート830(jｏbTagDef)が更新され」ている場合に、「PC10が実行する機器管理ソフトウェア」が、「実体データである構造体900のデータ構造の定義(データ構造体)を、取得したタグテンプレート830(jｏbTagDef)で置き換えて保存」することと、本願発明2の「管理情報ベース(MIB)情報をメタMIBを使用して前記ネットワーク管理システム(NMS)が自動アップデートする」こととは、管理情報ベース(MIB)情報の更新を、前記ネットワーク管理システム(NMS)が自動アップデートする、点で共通する。次に、引用発明において、「PC10が実行する機器管理ソフトウェア」が「エージェントであるプリンタ20」から「タグテンプレート830(jｏbTagDef)を取得」することが、本願発明2の「前記エージェントに保存されている前記MIB情報を読み取るステップ」に相当する。次に、引用発明において、「バージョン情報が変更されていれば、実体データである構造体900のデータ構造の定義(データ構造体)を、取得したタグテンプレート830(jｏbTagDef)で置き換えて保存」することが、本願発明2の「前記ネットワーク管理システム(NMS)内のMIBの表現の少なくとも一部を再構成するステップ」(なお、本願発明2の「MIBの表現」とは、実体データの表現形式に関する情報を意味するものと解釈して対比した。)に相当する。よって、本願発明2と引用発明とは、次の点で一致する。一致点「ネットワーク管理システム(NMS)とMIBを有するエージェントとの間の管理情報ベース(MIB)情報の更新を、前記ネットワーク管理システム(NMS)が自動アップデータするための方法であって、前記エージェントに保存されている前記MIB情報を読み取るステップと、前記ネットワーク管理システム(NMS)内のMIBの表現の少なくとも一部を再構成するステップとを含む方法。」一方、両者は次の点で相違する。 (相違点1) 本願発明2では、「ネットワーク管理システム(NMS)」が「MIB」を有しているのに対し、引用発明では、「PC10が実行する機器管理ソフトウェア」がMIBを有しているか明らかでない点。 (相違点2) 本願発明2では、「MIB_Infｏ_Laｓｔ_Change_Time」が変化したことをエージェントが検出すると「トラップ」が送信され、「前記ネットワーク管理システム(NMS)」は、該「トラップを受信」すると、「ウォーク・オペレーションを用いて、前記エージェントに保存されている前記MIB情報を読み取」っているのに対し、引用発明では、「タグテンプレート830(jｏbTagDef)」(前記MIB情報)を「エージェントであるプリンタ20」(エージェント)から取得する契機に、かかるトラップは用いられておらず、また、「タグテンプレート830(jｏbTagDef)」(前記MIB情報)を取得する手段としてウォーク・オペレーションを用いているか、明らかでない点。 (相違点3) 本願発明2では、管理情報ベース(MIB)情報の更新を、「メタMIBを使用して」行っているのに対し、引用発明では、実体データである構造体900のデータ構造の定義(データ構造体)(管理情報ベース(MIB)情報)の置き換え(更新)を、「タグテンプレート830(jｏbTagDef)」を使用して行っているものの、「メタMIB」を使用して行っているか明らかでない点。 (3)当審の判断 (相違点1について) マネージャとエージェントとからなる管理システムにおいて、マネージャとエージェントとが共に「MIB」を保持し、両者の設定内容を一致させることは、特開2002-149509号公報:段落【0001】?【0003】に記載されているように、周知技術である。よって、引用発明において、「機器管理ソフトウェアが稼働するマネージャであるPC10」(ネットワーク管理システム(NMS))がMIBを有するものとすることは、当業者が容易になし得たことである。 (相違点2について) MIBデータが変化するとエージェントがマネージャにトラップを送り、エージェントから送出された該トラップに応答して、マネージャが、変化したMIBデータの取得を行うこと、及び、MIBからの情報の取得にウォーク・オペレーションを用いることは、共に周知技術である(それぞれ、特開2000-66978号公報:段落【0002】、【0006】)、及び、工藤智行、FｒeeBSDサイト管理風雲録第12回、SNMPの話(その2)、SｏfｔｗaｒeDeｓign、第118号、(株)技術評論社、2000年8月18日、ｐ.90?101、特に、第90?91の「ｓnmｐｗalk」、第92頁の「ｓnmｐbｕlkｗalk」、参照。)。よって、引用発明において、「エージェントであるプリンタ20」(エージェント)が「タグテンプレート830(jｏbTagDef)」(前記MIB情報)の変化を検知すると「トラップ」が送信され、「PC10が実行する機器管理ソフトウェア」(ネットワーク管理システム(NMS))は、該トラップを受信すると、ウォーク・オペレーションを用いて、「エージェントであるプリンタ20」(エージェント)に含まれている(保存されている)「タグテンプレート830(jｏbTagDef)」(前記MIB情報)の取得(読み取り)を行うことは、当業者が容易になし得たことである。また、その際、情報の更新の有無を「日時」によって認識することは、当業者に普通に知られていることである(前記特開2002-149509号公報:段落【0014】の「MIB1が更新されたことは、ファイル更新日属性等によって認識できる。」参照。)から、「エージェントであるプリンタ20」(エージェント)による「タグテンプレート830(jｏbTagDef)」(前記MIB情報)の変化の検知を、その更新の日時(「MIB_Infｏ_Laｓｔ_Change_Time」)により検知することも、当業者が適宜なし得たことである。 (相違点3について) 既に述べたとおり、本願発明2の「メタMIB」とはどのようなものであるのか、不明りょうである。しかし、引用発明の「タグテンプレート830(jｏbTagDef)」が本願発明2の「メタMIB」に相当するか否かはともかくとして、引用発明は、「MIBデータベース450」のうち、実体データ(ジョブ情報)の構造体900の「定義」が変更された場合であっても、該実体データ(ジョブ情報)の「定義」を記述する情報(タグテンプレート)を用いることによって、実体データ(ジョブ情報)の構造体900の「定義」を置き換え(更新し)、該「定義」が変更された後の実体データ(ジョブ情報)の取得を可能にしている点で、本願発明2の「管理情報ベース(MIB)情報」(前記MIB情報、つまりMIBの定義情報)の更新を「メタMIBを用いて」「自動アップデートする」との要件を実質的に備えているものと認めることができる。そして、本願発明2の作用効果も、引用発明及び周知技術から当業者が予測できる範囲のものである。 (4)小活したがって、本願発明2は、引用例に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法29条2項の規定により特許を受けることができない。 6.むずび以上のとおりであるから、上記項目4で検討したように、本願は、原査定の拒絶理由で指摘したとおり、特許法第36条第6項第2号に規定する要件を満たしていない。また、本願発明2は、上記項目5検討したように、引用例に記載された発明及び周知技術に基づいて当業者が容易に発明ができたものであるので、特許法第29条第2項の規定により特許を受けることができない。よって、結論のとおり審決する。
審理終結日	2011-09-30
結審通知日	2011-10-04
審決日	2011-11-09
出願番号	特願2006-549138(P2006-549138)
審決分類	P 1 8・ 537- Z (G06F) P 1 8・ 121- Z (G06F)
最終処分	不成立
前審関与審査官	寺谷大亮
特許庁審判長	清水稔
特許庁審判官	安久司郎青木健
発明の名称	メタMIBを使用する自動アップデートシステム及び方法
代理人	松島鉄男
代理人	中村綾子
代理人	深川英里
代理人	河村英文
代理人	森本聡二
代理人	奥山尚一
代理人	吉田尚美
代理人	有原幸一

プライバシーポリシーセキュリティーポリシー運営会社概要サービスに関しての問い合わせ