【事件の表示】
　特願２００５−　４８９６１「遠隔保守・メンテナンスシステム、ＳＩＰ搭載機器、保守・メンテナンス機器および方法」拒絶査定不服審判事件〔平成１８年　９月　７日出願公開、特開２００６−２３７９９６〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、平成１７年２月２４日の出願であって、平成２１年８月２４日付けで拒絶理由が通知され、同年１０月２１日付けで手続補正されたが、平成２２年２月１８日付けで拒絶査定がなされ、これに対し、平成２２年５月２０日に拒絶査定不服の審判が請求されたものである。
　
第２　本願発明
　特許請求の範囲の請求項１に係る発明（以下、「本願発明」という。）は、平成２１年１０月２１日付けで手続補正された特許請求の範囲、明細書及び図面の記載からみて、その特許請求の範囲の請求項１に記載された以下のとおりのものと認める。
　
　「機器機能を実行するために用いる通信プロトコルを実装した機器を遠隔から保守・メンテナンスする遠隔保守・メンテナンスシステムであって、
　前記通信プロトコルを用いて実行される前記機器機能とは異なる機能として備えられた前記保守・メンテナンスのための保守・メンテナンス情報を、前記機器機能のための機器機能情報と同じ前記通信プロトコルにより送受信し、前記保守・メンテナンス情報に基づき保守・メンテナンス制御を実行する情報通信機器と、
　前記情報通信機器との間で前記通信プロトコルにより前記保守・メンテナンス情報を送受信し、前記情報通信機器に前記保守・メンテナンス制御を指示する保守・メンテナンス機器とを有し、
　前記通信プロトコルは、保守・メンテナンス制御のコマンドが付加されたＳＩＰであり、
　前記保守・メンテナンス機器から前記情報通信機器への前記保守・メンテナンス制御の指示が前記コマンドを用いて通知される、
遠隔保守・メンテナンスシステム。」
　
第３　先願発明
　原審の拒絶理由に引用された本願の出願日前の他の出願であって、その出願後に出願公開された特願２００３−３３８２４８号（特開２００５−１０９７１４号）の願書に最初に添付された明細書又は図面（以下、「先願明細書」という。）には、図面とともに以下の事項が記載されている。
　
イ．「【０００１】
  本発明は、ＶｏＩＰ（Voice over Internet Protocol）を利用して通話等の通信サービスを行うＩＰ電話システムの管理技術に関し、特に、端末装置の保守に関する処理を行う保守装置の改良技術に関する。」（３頁）
　
ロ．「【００２６】
  ［第１の実施の形態］
  以下、本発明の実施の形態について図面を参照して説明する。本発明に係る保守端末装置は、ＶｏＩＰ（Voice over IP）を利用して通話を行うＩＰ電話システムに適用される。
【００２７】
  ［システム概略図］
  図１は、本発明の一実施形態が適用されたＩＰ電話システムの概略図である。同図に示すように、本ＩＰ電話システムは、１または１以上のＩＰ電話端末１０-1・・・１０−ｎと、ＩＰ電話端末１０とＬＡＮ（Local Area Network）５０を介して接続されたルータ４０と、ルータ４０および所定の通信網（例えば、インターネット）３０を介してＩＰ電話端末１０と接続された保守サーバ２０と、同様にルータ４０および所定の通信網３０を介してＩＰ電話端末１０と接続されＩＰ電話端末１０の通話を管理する呼制御サーバ６０と、から構成される。
【００２８】
  各ＩＰ電話端末１０は、それぞれのＩＰアドレスを備え、主に、アナログ音声信号をディジタル信号に変換する音声符号化機能、ディジタル化した音声信号をＩＰパケットとして加工するパケット化機能、図示しない入力手段から入力された電話番号をパケットの宛先のＩＰアドレスに変換するアドレス変換機能、および所定の呼制御プロトコルに従い通話を管理する呼制御機能を備えている。
【００２９】
  このような呼制御プロトコルには、例えば、ＴＣＰ（Transmission Control Protocol）上で利用されるＨ．３２３プロトコルや、ＵＤＰ（User Datagram Protocol）上で利用されるＳＩＰ（Session Initiation Protocol）などがある。本実施形態では、一例としてＳＩＰを用いた場合について説明する。この場合、ＩＰ端末１０は、ＳＩＰクライアントとして機能する。
【００３０】
  なお、本実施形態に係るＩＰ電話端末１０は、上記機能を備えた単一の装置として構成されているが、ＩＰ電話端末１０の構成はこれに限られない。例えば、アナログ電話装置とＶｏＩＰゲートウェイとを接続することにより構成されるものも、本実施形態に係るＩＰ電話端末１０に該当する。また、電話用のヘッドセット（マイクとスピーカ）や上記機能を実現するためのプログラムを実装したパーソナルコンピュータ等の汎用の情報処理装置であってもよい。
【００３１】
  ルータ４０は、ＩＰパケットに書き込まれた宛先のＩＰアドレスを読み取って、最適な方向にＩＰパケットを送出する機能を備えた経路選択装置（中継器）である。また、ルータ４０は、外部のネットワークを通じて第三者が侵入することを防止するためファイヤーオール機能を備える。ファイヤーオール機能には、侵入検知システムやＩＰパケットの暗号化など周知の技術を適用することができる。ルータ４０は、このファイヤーオール機能により、通信網３０から受け入れたＩＰパケットが設定された条件に合致しない場合には、このＩＰパケットを受け付けず、その旨を発信元に送り返す。
【００３２】
  保守サーバ２０は、ＩＰ電話システムを良好な稼動状態に保つためのサービスを提供するものである。保守サーバ２０は、例えば、ＩＰ電話端末１０内のデータやプログラムを必要に応じて更新・変更する機能や、ＩＰ電話端末１０の稼動状況を外部から遠隔監視し、障害発生時に障害内容の通知や復旧作業を遠隔操作によって行う障害回復機能を備える。また、保守サーバ２０は、所定の呼制御プロトコルを実装する。ここでは、上述したようにＳＩＰを実装する。」（５〜６頁）
　
ハ．「【００５７】
  ［データフォーマット］
  図４は、本実施形態に係るデータ構成の一例を示す図である。
【００５８】
  図４（Ａ）は、通常の呼制御処理を実行する際に送受信されるメッセージの一例である。図４（Ｂ）は、保守管理処理を実行する際に送受信される保守情報が格納されたメッセージの一例である。
【００５９】
  本実施形態では、「ＳＩＰ  ＩＮＶＩＴＥ  メッセージ」のヘッダ部分に保守管理情報を格納している。具体的には、未規定部分に相当する「Ｍｅｓｓａｇｅ  Ｈｅａｄｅｒ」内の「Ｕｓｅｒ−Ａｇｅｎｔ」フィールドに、保守情報が記載される。図４（Ａ）では、「Ｕｓｅｒ−Ａｇｅｎｔ」フィールドに通常の情報７０ａが記載されており、図４（Ｂ）では、「Ｕｓｅｒ−Ａｇｅｎｔ」フィールドに保守情報７０ｂが記載されていることがわかる。
【００６０】
  図５は、保守サーバの処理手順を示すフローチャートである。具体的には、保守サーバ２０における呼制御部２０５、保守管理部２０６およびパケット処理部２０４のプログラムの処理内容の概要を表したものである。
【００６１】
  まず、保守管理部２０６は、保守処理を実行するか否かを判断する（ＳＴＥＰ５０１）。例えば、特定のＩＰ電話端末について特定の時間を指定した保守処理の実行が入出力部２０８を介して入力された場合には、保守管理部２０６は、保守処理を実行すると判断する。また、ＩＰ電話端末１０に対するアクセス時間や対象となるＩＰ電話端末１０が予め設定されている場合には、これらの設定に従い保守処理の実行を判断する。
【００６２】
  そして、保守処理を実行すると判断した保守管理部２０６は、入力された情報あるいは設定された条件に従って、保守対象となるＩＰ電話端末１０を特定する（ＳＴＥＰ５０３）。また、保守管理部２０６は、保守処理が所定の情報の設定である場合は、入力された情報あるいは設定された条件に従って、設定対象となる情報を記憶部２１０から読み込み、読み込んだ情報と設定命令とを含む保守情報を生成する（ＳＴＥＰ５０５）。
【００６３】
  次に、保守対象となるＩＰ電話端末が特定され、保守情報が生成されると、保守管理部２０６は、対象となるＩＰ電話端末１０が対応する呼制御手順プロトコルのデータフォーマットに従い、保守情報を格納する。ここで、保守情報は、呼制御手順プロトコルが本来予定している呼制御の処理とは異なる処理に関する情報である。従って、保守管理部２０６は、呼制御手順プロトコルのデータフォーマットにおいて、呼制御に利用されない所定の部分（未規定の部分、例えば、「Ｍｅｓｓａｇｅ  Ｈｅａｄｅｒ」内の「Ｕｓｅｒ−Ａｇｅｎｔ」フィールド）に、保守情報を格納する。これにより、ＩＰ電話端末１０において、呼制御処理のエラーや不具合を生じさせることなく保守情報を解釈実行させることができる。
【００６４】
  なお、各ＩＰ電話端末１０が採用する呼制御手順プロトコルは、ＩＰ電話端末ごとに異なる場合があるので、ＩＰ電話端末１０が対応する呼制御手順プロトコルの情報は、予め記憶部２１０に格納しておくか、入出力部２０８を介して入力するものとする。
【００６５】
  呼制御部２０５は、パケット処理部２０４を介して、ＩＰ電話端末１０に対する接続情報（電話番号）及び接続要求メッセージを含む接続要求パケットを通信網３０に送出する（ＳＴＥＰ５０９）。その後、呼制御サーバ６０を介して、ＩＰ電話端末１０との間で通話路が確立すると、呼制御手順プロトコルの未規定部分に保守情報を格納したパケットを
送出する（ＳＴＥＰ５１１）。通常の通話の場合、通話路が確立すると、発信側の保守サーバ２０と着信側のＩＰ電話端末１０との間では、ＲＴＰに従い音声信号が格納されたＩＰパケットが送受信されるが、ここでは、音声パケットの代わりに、保守情報が格納されたパケットが保守サーバ２０からＩＰ電話端末１０へ送信される。
【００６６】
  ［ＩＰ電話端末の処理手順］
  図６は、ＩＰ電話端末１０の処理手順を示すフローチャートである。具体的には、ＩＰ電話端末１０におけるパケット処理部１０４、呼制御部１０６および保守管理部２０６のプログラムの処理内容の概要を表したものである。
【００６７】
  パケット処理部１０４は、ネットワークインターフェース部５０を介してパケットを受信すると（ＳＴＥＰ６０１）、受け取ったパケットに含まれるデータが所定の呼制御プロトコルに従うデータであるか否かを判断する（ＳＴＥＰ６０３）。そして、受け取ったパケットに含まれるデータが所定の呼制御プロトコルに従うデータであると判断した場合は（ＳＴＥＰ６０３のＹｅｓ）、そのデータを呼制御部１０６に受け渡す。
【００６８】
  呼制御部１０６は、受け渡されたデータが保守情報を送信するものであるか否かを判断する（ＳＴＥＰ６０５）。具体的には、呼制御プロトコルのデータフォーマット中の未規定部分に、保守情報が格納されている場合には、保守情報を送信するものであると判断し（ＳＴＥＰ６０５のＹｅｓ）、保守情報を抽出する（ＳＴＥＰ６０７）。一方、呼制御プロトコルのデータフォーマットに従い、呼制御に関する情報が格納されている場合には、保守情報を送信するものではないので（ＳＴＥＰ６０５のＮｏ）、呼制御処理を実行する（ＳＴＥＰ６０６）。
【００６９】
  保守管理部１１４は、呼制御部１０６により抽出された保守情報に基づいて、保守処理を実行する。例えば、保守管理部１１４は、保守情報が情報の設定命令である場合は（ＳＴＥＰ６０９のＹｅｓ）、抽出された情報に従って記憶部１１６を更新する（ＳＴＥＰ６１１）。一方、保守情報が情報の収集命令である場合は（ＳＴＥＰ６１３のＹｅｓ）、指示内容に従って所定の情報を取得する（ＳＴＥＰ６１５）。保守管理部１１４は、保守処理の実行結果をパケット処理部１０４に通知する。
【００７０】
  パケット処理部１０４は、通知された内容に従い保守サーバ２０を宛先とする応答パケットを生成し（ＳＴＥＰ６１７）、ネットワークインターフェース部１０２は、これを送信する（ＳＴＥＰ６１９）。」（１０〜１１頁）
　
　上記先願明細書の記載及び図面並びにこの分野における技術常識を考慮すると、上記摘記事項ロ．の【００２６】、【００２７】、【００２９】、【００３２】の記載、及び図１によれば、ＩＰ電話システムは、ＩＰ電話端末（１０）と、保守サーバ（２０）とを有し、呼制御を行うために用いるＳＩＰ（Session Initiation Protocol）を実装したＩＰ電話端末（１０）を遠隔から保守するものである。
　また、上記摘記事項ハ．の【００６７】〜【００７０】の記載、及び図６によれば、ＩＰ電話端末（１０）は、呼制御プロトコルを用いて実行される保守情報を、呼制御プロトコルにより受信し、実行結果を送信し、保守情報に基づき保守制御をしている。
　ここで、上記摘記事項ハ．の【００６３】における「保守情報は、呼制御手順プロトコルが本来予定している呼制御の処理とは異なる処理に関する情報である。」との記載によれば、保守情報は、呼制御とは異なる機能として備えられたものということができる。また、呼制御プロトコルは、呼制御のための呼制御情報と同じプロトコルであることは明らかである。
　また、上記摘記事項ハ．の【００６５】〜【００７０】の記載、図５及び図６によれば、保守サーバ（２０）は、ＩＰ電話端末（１０）との間で呼制御プロトコルにより保守情報を送信し、実行結果を受信していることが読み取れる。ここで、上記摘記事項ハ．の【００６９】における「保守情報が情報の設定命令である場合は（ＳＴＥＰ６０９のＹｅｓ）、抽出された情報に従って記憶部１１６を更新する（ＳＴＥＰ６１１）。一方、保守情報が情報の収集命令である場合は（ＳＴＥＰ６１３のＹｅｓ）、指示内容に従って所定の情報を取得する（ＳＴＥＰ６１５）。」との記載によれば、保守サーバ（２０）は、ＩＰ電話端末（１０）に保守制御を指示しているから、ＩＰ電話端末（１０）へ保守制御の指示を通知しているということができる。
　また、上記摘記事項ハ．の【００５８】、【００６３】の記載、図４（Ｂ）及び図５によれば、呼制御プロトコルは、ＳＩＰ（Session Initiation Protocol）であり、保守情報を格納したものである。
　
　したがって、先願明細書には以下の発明（以下、「先願発明」という。）が記載されている。
　
　「呼制御を行うために用いるＳＩＰ（Session Initiation Protocol）を実装したＩＰ電話端末（１０）を遠隔から保守するＩＰ電話システムであって、
　前記ＳＩＰ（Session Initiation Protocol）を用いて実行される前記呼制御とは異なる機能として備えられた保守情報及び実行結果を、前記呼制御のための呼制御情報と同じ前記ＳＩＰ（Session Initiation Protocol）により送受信し、保守情報に基づき保守制御を実行するＩＰ電話端末（１０）と、
　前記ＩＰ電話端末（１０）との間で前記ＳＩＰ（Session Initiation Protocol）により保守情報及び実行結果を送受信し、前記ＩＰ電話端末（１０）に前記保守制御を指示する保守サーバ（２０）とを有し、
　前記ＳＩＰ（Session Initiation Protocol）は、保守情報を格納したＳＩＰ（Session Initiation Protocol）である、
　前記保守サーバ（２０）から前記ＩＰ電話端末（１０）へ前記保守制御の指示が通知される、
ＩＰ電話システム。」
　
第４　対比・判断
　本願発明と先願発明とを対比する。
ａ．先願発明の「呼制御を行うために用いるＳＩＰ（Session Initiation Protocol）」、「ＩＰ電話端末（１０）」、及び「保守サーバ（２０）」は、本願発明の「機器機能を実行するために用いる通信プロトコル」、「情報通信機器」、及び「保守・メンテナンス機器」にそれぞれ相当する。
ｂ．先願発明の「保守情報」及び「実行結果」は、本願発明の保守・メンテナンスのための「保守・メンテナンス情報」に含まれる。
ｃ．先願発明の「保守制御」は、本願発明の「保守・メンテナンス制御」に含まれる。
ｄ．先願発明の「保守情報を格納した」と、本願発明の「保守・メンテナンス制御のコマンドが付加された」とは、いずれも、「保守に関する要素を有した」点で一致する。
ｅ．先願発明の「ＩＰ電話システム」は、遠隔保守をするから、遠隔保守・メンテナンスシステムの一種である。
　
　したがって、本願発明と先願発明は、以下の点で一致し、以下の点で一応相違する。
　
＜一致点＞
　「機器機能を実行するために用いる通信プロトコルを実装した機器を遠隔から保守・メンテナンスする遠隔保守・メンテナンスシステムであって、
　前記通信プロトコルを用いて実行される前記機器機能とは異なる機能として備えられた前記保守・メンテナンスのための保守・メンテナンス情報を、前記機器機能のための機器機能情報と同じ前記通信プロトコルにより送受信し、前記保守・メンテナンス情報に基づき保守・メンテナンス制御を実行する情報通信機器と、
　前記情報通信機器との間で前記通信プロトコルにより前記保守・メンテナンス情報を送受信し、前記情報通信機器に前記保守・メンテナンス制御を指示する保守・メンテナンス機器とを有し、
　前記通信プロトコルは、保守に関する要素を有したＳＩＰであり、
　前記保守・メンテナンス機器から前記情報通信機器への前記保守・メンテナンス制御の指示が通知される、
遠隔保守・メンテナンスシステム。」
　
＜相違点＞
　「保守に関する要素を有した」ＳＩＰに関し、
　本願発明は、「保守・メンテナンス制御のコマンドが付加された」ものであるのに対し、先願発明は、「保守情報を格納した」ものである点。
　
　加えて、
　「保守・メンテナンス制御の指示」に関し、
　本願発明は、「前記コマンドを用いる」ものであるのに対し、先願発明は、「前記コマンドを用いる」との特定がない点。
　
　そこで、上記相違点について検討する。
　先願明細書の上記摘記事項ハ．の【００６９】における「保守情報が情報の設定命令である場合は（ＳＴＥＰ６０９のＹｅｓ）、抽出された情報に従って記憶部１１６を更新する（ＳＴＥＰ６１１）。一方、保守情報が情報の収集命令である場合は（ＳＴＥＰ６１３のＹｅｓ）、指示内容に従って所定の情報を取得する（ＳＴＥＰ６１５）。」との記載によれば、保守情報は、保守制御の命令（コマンド）の要素を含むものであり、また、図４（Ｂ）によれば、保守情報が格納された、Ｕｓｅｒ−Ａｇｅｎｔフィールド（７０ｂ）は、ＳＩＰ　ＩＮＶＩＴＥメッセージのヘッダ部分における未規定部分に付加されているということができる。そうすると、先願明細書の「保守情報を格納した」ものは、「保守・メンテナンス制御のコマンドが付加された」ものということができ、また、「保守・メンテナンス制御の指示」に関し、「前記コマンドを用いる」ものであることは明らかであるから、上記相違点は実質的なものではなく、本願発明と先願発明とは、実質的に同一である。
　
第５　引用発明
　原審の拒絶理由に引用された特表２００４−５２３８２８号公報（以下、「引用例」という。）には、図面とともに以下の事項が記載されている。
　
ニ．「【０００２】
本発明は、ネットワーク対応機器の操作を行うためのネットワークを通じたコントロール信号およびステータス信号の通信に関し、より詳細には、複数のネットワーク対応機器との通信を改良するためのセッション開始プロトコルの使用に関する。」（５頁）
　
ホ．「【００４６】
図５は、ネットワーク対応機器をサポートするためのＳＩＰアーキテクチャの機能図である。このアーキテクチャは、図３および図４のプロキシアーキテクチャを介したメッセージングに基づく。機能エンティティは、異なる物理的なネットワーク要素（図６参照）に分散することができる。上記の通り、ネットワーク対応機器の操作またはそのステータスを求める要求は、ＳＩＰ  ＵＡＣ１００の発信元クライアントアプリケーション（発信元アプリケーション）で開始する。発信元アプリケーションはＳＩＰ  ＵＡＣ１００を使用して機器メッセージ（ＤＯ）を生成し、サービスプロバイダまたはホームＲＧＷによってホストされるＳＩＰプロキシ１０８に送信する。サービスプロバイダドメイン中のＳＩＰプロキシ１０８は、位置データベース１４０で検索することにより、通信しようとする機器のアドレス（該当するホームドメインＲＧＷを含む）を解決する。ＳＩＰプロキシは、クライアントＳＩＰ  ＵＡ１００からホームドメインＲＧＷ中のＳＩＰプロキシ１１６’に機器メッセージを転送するか、またはセキュアな接続を介してターゲットデバイス中のＳＩＰ  ＵＡＳに直接転送する。
【００４７】
位置データベース１４０は、ホームドメイン内のすべての登録された機器の位置情報を含む。このデータベースには、登録手順中にサービスプロバイダのＳＩＰプロキシ１０８によって収集された情報が格納される。詳細には、ＲＥＧＩＳＴＥＲメッセージがプロキシ１０８に送信されてクライアントおよび各機器の位置を登録する。機器の場合、この登録は単にその機器がホームドメイン２００内にあるということでよい。さらに、これすら登録できない場合には、ホームドメイン２００のＩＰアドレスだけでよい。その場合、ユーザはホームドメイン中で利用できる機器を知っていることを求められる。そのドメインを宛先とする場合、メッセージは、プロキシ１１６’におけるアドレスマッピングによりその機器にアドレス指定される。
【００４８】
ホームドメインの住居ゲートウェイ中のＳＩＰプロキシ１１６’は、ホームドメイン内の機器と、ワイドエリアネットワーク３００内のエンティティとの間のゲートウェイを提供する。ファイアウォールやＮＡＴなどの他のＲＧＷ機能は、ＲＧＷ  ＳＩＰプロキシ１１６’と同じ場所に置くことができる。ＳＩＰ  ＵＡＳは、発信元アプリケーションＳＩＰ  ＵＡＣ１００からのＳＩＰ機器メッセージを終了する。ＳＩＰ  ＵＡＳは、ＳＩＰメッセージからメッセージング情報を取り出し、その情報をインターワーキング装置２０８に渡す。このＳＩＰ  ＵＡＳは、スタンドアロン装置でよく、図５に示すようにＲＧＷ１１６または機器コントローラ２０４に常駐する。ＳＩＰ  ＵＡＣと機器コントローラとの論理的マッピングは１：Ｎであり、Ｎは、発信元プログラムがネットワークを通じて到達できるコントローラの数である。
【００４９】
インターワーキング装置２０８は、ＳＩＰメッセージのペイロードで搬送される機器メッセージを、機器固有のプロトコルにマッピングする。このプロトコルは、非ＩＰ機器２０６によって解釈できる形態であり、したがって、非ＩＰ機器２０６は、発信元のクライアントアプリケーションと通信／対話するために、インターワーキング装置２０８の使用を通じて機器コントローラ２０４によって制御される。
【００５０】
ＳＩＰ  ＵＡＳ（ＩＰ対応機器）２０２は、ＩＰ（ＳＩＰ）対応ネットワーク対応機器内に常駐する。ＳＩＰ  ＵＡＳは、発信元アプリケーションＳＩＰ  ＵＡＣ１００からのＳＩＰ機器コントロールメッセージを終了し、機器アプリケーションの機器コントロールステータス情報を取り出し、非ＩＰ機器に必要とされる仲介のインターワーキング装置２０８または機器コントローラ２０４を必要とせずに、その情報に直接作用する。
【００５１】
図５の主要インタフェースは、（１）ＳＩＰネットワーク対応機器、（２）機器の登録および位置、および（３）機器固有のインタフェースである。ＳＩＰ機器インタフェースは、ネットワーク対応機器と通信するためのＤＯメソッドを備えるＩＥＴＦ  ＳＩＰに相当する。機器の登録および位置のインタフェースは、任意の適切なデータベース更新と、位置データベース１４０にアクセスするのに使用する検索プロトコルによって実現される。そのようなプロトコルの例は、ＬＤＡＰおよびＳＬＰである。さらに、機器固有のインタフェースは、現在利用できる数多くのホームネットワーキング技術である。ＳＩＰから、ターゲット機器の固有の技術のプロトコルへのマッピングは、インターワーキング装置２０８の機能である。
【００５２】
図５の機能システムの物理的な実現を図６に示し、ここでは発信元ＳＩＰ  ＵＡＣ１００がユーザのオフィスのＰＣ１０１にある。このマシンからメッセージを発信して、例えばビデオカメラ２１０や照明２１２など住宅内のオブジェクトを操作する。このメッセージは、本発明により修正した標準的なＳＩＰ技術を使用して、その住宅を担当するサービスプロバイダシステム１０９（ＳＩＰプロキシ１０８を含む）に転送される。プロバイダ１０９は、メッセージをセットトップボックス（ＳＴＢ）１１７に送信するが、ＳＴＢ１１７は、ＲＧＷ、ケーブルモデム、ＡＤＳＬモデム、または展開された住宅技術の適切な他のエッジを含むことができる。ＳＴＢ１１７は、ＳＩＰ対応デバイス（ビデオカメラ２１０や家庭用ＡＶ機器などより高機能のデバイスである傾向がある）に直接メッセージを送信するか、または機器コントローラの一部とすることができるインターワーキング装置２０８を介して間接的に送信する。この物理的実現では、ユーザは、自分たちのために行われている通信のレベルおよび精度（sophistication）を意識する必要がない。
【００５３】
以下の例で、本発明によりＤＯタイプを含むように修正したＳＩＰ符号化を機器のドメイン間ネットワーキングに使用する方式を例示する。この説明では、すべてのＳＩＰメッセージヘッダフィールドを含めてはいない（例えばＣｓｅｑ、Ｃａｌｌ−ＩＤ、およびＣｏｎｔｅｎｔ−ｌｅｎｇｔｈなど）。説明を簡潔にするために、特に対象となるヘッダフィールドだけを含めている。また、デバイスメッセージングプロトコル（ＤＭＰ）はまだ標準化されておらず、ＤＭＰの例は、例証だけを目的とすると考えるべきことにも留意されたい。
【００５４】
図７に示すシナリオでは、ユーザは、オフィスのＰＣ１０１から自宅のランプのスイッチをつけたい。住宅内のネットワーク対応機器（例えばランプ）の（例えばオフィスからの）リモートコントロールのためのＳＩＰメッセージについて以下で説明する。実際の応用例でのＳＬＰ  ＵＲＬ情報は、符号化され、任意でプライバシーのために暗号化されるが、分かりやすいように角括弧内では暗号化せずに示すことに留意されたい。この例では、ｓｔａｎ．ｈｏｍｅ．ｎｅｔに位置する例えばセットトップボックス１１７などのユーザエージェントは、ｓｔａｎ．ｈｏｍｅ．ｎｅｔに登録され、その情報がｈｏｍｅ．ｎｅｔに伝達されている。下記の番号「１」のメッセージは、ＰＣとアウトバウンドプロキシｃｏ．ｃｏｍ間のものである。図７ではこれを円内の「１」として示している。
1.DO sip:[d=lamp,r=bedroom,u=stanm]@home.net SIP/2.0
　From: sip:stan@co.com
　To: sip:[d=lamp,r=bedroom,u=stanm]@home.net
　Via: SIP/2.0/UDP anypc.co.com 
　Content-function: render
　Content-type: application/dmp
　commandtumOn/turn/command
【００５５】
ｃｏ．ｃｏｍプロキシは、［ｄ＝ｌａｍｐ，ｒ＝ｂｅｄｒｏｏｍ，ｕ＝ｓｔａｎｍ］＠ｈｏｍｅ．ｎｅｔについてＤＮＳでＳＲＶ検索を行って、宛先ドメインのＳＩＰサーバの名前を見つけ、ｈｏｍｅ．ｎｅｔの値を入手する。これは、ＳＲＶレコードがあるサービスプロバイダのプロキシを指すときには、ユーザ／サービス名がそのサービスプロバイダのドメイン内で一意でなければならないことを意味する。
【００５６】
図７のメッセージ「２」は、以下のようにｃｏ．ｃｏｍからｈｏｍｅ．ｎｅｔへのものである。
2.DO sip:[d=lamp,r=bedroom,u=stanm]@home.net SIP/2.0
　From: sip:stan@co.com
　To: sip:[2=lamp,r=bedroom,u=stanm]@home.net
　Via: SIP/2.0/UDP co.com
　Via: SIP/2.0/UDP anypc.co.com
　Content-function: render
　Content-type: application/dmp 
　commandturnOn/turn/command
【００５７】
ｈｏｍｅ．ｎｅｔからｓｔａｎ．ｈｏｍｅ．ｎｅｔ（セットトップボックス１１７など）へのメッセージは次である。
3.DO sip:[d=lamps=bedroom,u=stanm]@stan.home.net SIP/2.0
　From: sip:stan@co.com
　To: sip:[d=lamp,r=bedroom,u=stanm]@home.net
　Via: SIP/2.0/UDP home.net
　Via: SIP/2.0/UDP co.com
　Via: SIP/2.0/UDP anypc.co.comContent-function: render
　Content-type: application/dmp
　commandturnOn/turn/command
【００５８】
セットトップボックス１１７からインターワーキング装置２０８へのメッセージは次である。
4.DO sip:[d=lamp,r=bedroom,u=stanm]@ua.stan.home.net SIP/2.0
　From: sip:stan@co.com
　To: sip:[d=lamp,r=bedroom,u=stanm]@home.net
　Via: SIP/2.0/UDP stan.home.net
　Via: SIP/2.0/UDP home.net
　Via: SIP/2.0/UDP co.com 
　Via: SIP/2.0/UDP anypc.co.com 
　Content-function: render
　Content-type: application/dmp 
　commandturnOn/turn/cornmand
【００５９】
そして、インターワーキング装置は、次のようにランプ２１２に動作メッセージを送信して、ランプのスイッチを入れる。
5. Action!!!上記のシナリオは失敗のシナリオを説明するためにも使用することができる。ランプは、メッセージを受信すると、電球が「切れて」（壊れて）いることに気付く可能性があり、それに応答して次のようなものを送信する。
6.SIP/2.0 503 Service Unavailable
　From: sip:stan@co.com
　To: sip:[d=lamp,r=bedroom,u=stanm]@home.net
　Via: SIP/2.0/UDP stan.home.net
　Via: SIP/2.0/UDP co.com
　Via: SIP/2.0/UDP anypc.co.com 
　Content-function: render
　Content-type: application/text
　Bulb has blown !! Replace with new!」（１３〜１７頁）
　
　上記引用例の記載及び図面並びにこの分野における技術常識を考慮すると、上記摘記事項ホ．の【００４６】、【００５４】、【００５９】の記載、図５乃至図７によれば、ＳＩＰアーキテクチャは、ＰＣ（１０１）とランプ（２１２）とを有し、リモートコントロールするために用いるＳＩＰを実装したランプ（２１２）を遠隔からリモートコントロール動作の監視を行うものである。
　また、上記摘記事項ホ．の【００５９】における「次のようにランプ２１２に動作メッセージを送信して、ランプのスイッチを入れる。5. Action!!!上記のシナリオは失敗のシナリオを説明するためにも使用することができる。ランプは、メッセージを受信すると、電球が「切れて」（壊れて）いることに気付く可能性があり、それに応答して次のようなものを送信する。・・・（後略）・・・」との記載、及び図７によれば、ランプ（２１２）は、メッセージBulb has blown !! Replace with new !をＳＩＰにより送信している。
　また、ＰＣ（１０１）は、ランプ（２１２）との間でＳＩＰによりメッセージBulb has blown !! Replace with new !を受信していることが読み取れる。
　ここで、ＳＩＰは、リモートコントロールのためのメッセージと同じＳＩＰである。
　
　したがって、引用例には以下の発明（以下、「引用発明」という。）が記載されている。
　
　「リモートコントロールするために用いるＳＩＰを実装したランプ（２１２）を遠隔からリモートコントロール動作の監視を行うＳＩＰアーキテクチャであって、
　メッセージBulb has blown !! Replace with new !を、前記リモートコントロールのためのメッセージと同じ前記ＳＩＰにより送信するランプ（２１２）と、
　前記ランプ（２１２）との間で前記ＳＩＰにより前記メッセージBulb has blown !! Replace with new !を受信するＰＣ（１０１）とを有する、
ＳＩＰアーキテクチャ。」
　
第６　対比
　本願発明と引用発明とを対比する。
ｆ．引用発明の「リモートコントロールするために用いるＳＩＰ」、及び「ランプ（２１２）」は、本願発明の「機器機能を実行するために用いる通信プロトコル」、及び「情報通信機器」にそれぞれ相当する。
ｇ．引用発明の「リモートコントロール動作の監視を行う」と、本願発明の「保守・メンテナンスする」とは、いずれも、「処理する」という点で一致する。
ｈ．引用発明の「メッセージBulb has blown !! Replace with new !」と、本願発明の「前記通信プロトコルを用いて実行される前記機器機能とは異なる機能として備えられた前記保守・メンテナンスのための保守・メンテナンス情報」とは、いずれも、「情報」という点で一致する。
ｉ．引用発明の「前記リモートコントロールのためのメッセージと同じ前記ＳＩＰ」は、上記ｅ．の対比を考慮すると、「前記機器機能のための機器機能情報と同じ前記通信プロトコル」ということができる。
ｊ．引用発明の「ＰＣ（１０１）」と、本願発明の「保守・メンテナンス機器」とは、いずれも、「特定の機器」という点で一致する。
ｋ．引用発明の「ＳＩＰアーキテクチャ」は、システムの一種である。
　
　したがって、本願発明と引用発明は、以下の点で一致ないし相違する。
　
＜一致点＞
　「機器機能を実行するために用いる通信プロトコルを実装した機器を遠隔から処理するシステムであって、
　情報を、前記機器機能のための機器機能情報と同じ前記通信プロトコルにより送信する情報通信機器と、
　前記情報通信機器との間で前記通信プロトコルにより前記情報を受信する特定の機器とを有する、
システム。」
　
＜相違点１＞
　システムにおける「処理する」に関し、
　本願発明は、「保守・メンテナンスする」のに対し、引用発明は、「リモートコントロール動作の監視を行う」点。
　
＜相違点２＞
　「情報」に関し、
　本願発明は、「前記通信プロトコルを用いて実行される前記機器機能とは異なる機能として備えられた前記保守・メンテナンスのための保守・メンテナンス情報」であるのに対し、引用発明は、「メッセージBulb has blown !! Replace with new !」である点。
　
＜相違点３＞
　「情報通信機器」における「送信」に関し、
　本願発明は、「送受信」であるのに対し、引用発明は、「送信」である点。
　
＜相違点４＞
　「情報通信機器」の態様に関し、
　本願発明は、「前記保守・メンテナンス情報に基づき保守・メンテナンス制御を実行する」ものであるのに対し、引用発明は、その様な構成を備えていない点。
　
＜相違点５＞
　「特定の機器」における「受信」に関し、
　本願発明は、「送受信」であるのに対し、引用発明は、「受信」である点。
　
＜相違点６＞
　「特定の機器」の態様に関し、
　本願発明は、「前記情報通信機器に前記保守・メンテナンス制御を指示する」ものであるのに対し、引用発明は、その様な構成を備えていない点。
　
＜相違点７＞
　「特定の機器」に関し、
　本願発明は、「保守・メンテナンス機器」であるのに対し、引用発明は、「ＰＣ（１０１）」である点。
　
＜相違点８＞
　「通信プロトコル」に関し、
　本願発明は、「前記通信プロトコルは、保守・メンテナンス制御のコマンドが付加されたＳＩＰである」ものであるのに対し、引用発明は、その様な構成を備えていない点。
　
＜相違点９＞
　「通信プロトコル」に関し、
　本願発明は、「前記保守・メンテナンス機器から前記情報通信機器への前記保守・メンテナンス制御の指示が前記コマンドを用いて通知される」ものであるのに対し、引用発明は、その様な構成を備えていない点。
　
第７　判断
　そこで、まず、上記相違点１について検討する。
　上記引用例の上記摘記事項ホ．の【００５９】の記載によれば、引用発明は、ランプ（２１２）（情報通信機器）の電球が切れて（壊れて）いた場合、メッセージBulb has blown !! Replace with new !を送信し、新品との交換（保守・メンテナンス）を要求するから、本願発明のように「保守・メンテナンスする」ということができることは当然である。
　
　次に、上記相違点２について検討する。
　引用発明は、「メッセージBulb has blown !! Replace with new !」であるところ、ランプ（２１２）（情報通信機器）の電球が切れて（壊れて）いた場合、新品との交換（保守・メンテナンス）を要求するものであって、ＳＩＰを用いて実行されるリモートコントロールとは異ることは明らかであるから、本願発明のように「前記通信プロトコルを用いて実行される前記機器機能とは異なる機能として備えられた前記保守・メンテナンスのための保守・メンテナンス情報」ということができることは当然である。
　
　次に、上記相違点３乃至７について検討する。　
　遠隔保守・メンテナンスシステムにおいて、保守・メンテナンス情報を送受信し、保守・メンテナンス情報に基づき保守・メンテナンス制御を実行する情報通信機器と、保守・メンテナンス情報を送受信し、情報通信機器に保守・メンテナンス制御を指示する保守・メンテナンス機器とを設けることは、例えば、特開２００４−１８７１４９号公報（段落４２〜４８、図４）に開示されるように周知であるから、引用発明に周知技術を適用して、本願発明のように「情報通信機器」における「送信」、「特定の機器」における「受信」に関し、共に「送受信」とすること（相違点３、５）、「情報通信機器」に関し、本願発明のように「前記保守・メンテナンス情報に基づき保守・メンテナンス制御を実行する」ものとすること（相違点４）、「特定の機器」に関し、本願発明のように「前記情報通信機器に前記保守・メンテナンス制御を指示する」ものとすること（相違点６）は当業者が容易に成し得ることである。また、その際、引用発明の「ＰＣ（１０１）」を、本願発明のように「保守・メンテナンス機器」と称することができること（相違点７）は当然である。
　
　次に、上記相違点８について検討する。　
　通信プロトコルを、保守・メンテナンス制御のコマンドが付加されたＳＩＰとすることは、例えば、前述の特開２００４−１８７１４９号公報（段落４３、４４、４６）に開示されるように周知であるから、引用発明に周知技術を適用して、本願発明のように「前記通信プロトコルは、保守・メンテナンス制御のコマンドが付加されたＳＩＰである」ものとすることは当業者が容易に成し得ることである。
　
　次に、上記相違点９について検討する。　
　上記相違点６乃至８についての検討を踏まえれば、「前記通信プロトコルは、保守・メンテナンス制御のコマンドが付加されたＳＩＰである」から、本願発明のように「前記保守・メンテナンス機器から前記情報通信機器への前記保守・メンテナンス制御の指示が前記コマンドを用いて通知される」ものとすることは当業者が容易に成し得ることである。
　
　そして、本願発明の作用効果も、引用発明及び周知技術から当業者が容易に予測できる範囲のものである。
　
　
第８　むすび
　以上のとおり、本願発明は、先願明細書に記載された発明と同一であり、しかも、先願明細書に記載された発明をした者が本願発明の発明者であるとも、又、本願の出願の時に、その出願人が先願明細書の出願人と同一であるとも認められないから、特許法第２９条の２の規定により、特許を受けることができない。また、本願発明は、引用発明及び周知技術に基いて当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。