• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 発明同一 特許、登録しない。 H04L
審判 査定不服 2項進歩性 特許、登録しない。 H04L
管理番号 1251292
審判番号 不服2010-10787  
総通号数 147 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2012-03-30 
種別 拒絶査定不服の審決 
審判請求日 2010-05-20 
確定日 2012-02-03 
事件の表示 特願2005- 48961「遠隔保守・メンテナンスシステム、SIP搭載機器、保守・メンテナンス機器および方法」拒絶査定不服審判事件〔平成18年 9月 7日出願公開、特開2006-237996〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、平成17年2月24日の出願であって、平成21年8月24日付けで拒絶理由が通知され、同年10月21日付けで手続補正されたが、平成22年2月18日付けで拒絶査定がなされ、これに対し、平成22年5月20日に拒絶査定不服の審判が請求されたものである。

第2 本願発明
特許請求の範囲の請求項1に係る発明(以下、「本願発明」という。)は、平成21年10月21日付けで手続補正された特許請求の範囲、明細書及び図面の記載からみて、その特許請求の範囲の請求項1に記載された以下のとおりのものと認める。

「機器機能を実行するために用いる通信プロトコルを実装した機器を遠隔から保守・メンテナンスする遠隔保守・メンテナンスシステムであって、
前記通信プロトコルを用いて実行される前記機器機能とは異なる機能として備えられた前記保守・メンテナンスのための保守・メンテナンス情報を、前記機器機能のための機器機能情報と同じ前記通信プロトコルにより送受信し、前記保守・メンテナンス情報に基づき保守・メンテナンス制御を実行する情報通信機器と、
前記情報通信機器との間で前記通信プロトコルにより前記保守・メンテナンス情報を送受信し、前記情報通信機器に前記保守・メンテナンス制御を指示する保守・メンテナンス機器とを有し、
前記通信プロトコルは、保守・メンテナンス制御のコマンドが付加されたSIPであり、
前記保守・メンテナンス機器から前記情報通信機器への前記保守・メンテナンス制御の指示が前記コマンドを用いて通知される、
遠隔保守・メンテナンスシステム。」

第3 先願発明
原審の拒絶理由に引用された本願の出願日前の他の出願であって、その出願後に出願公開された特願2003-338248号(特開2005-109714号)の願書に最初に添付された明細書又は図面(以下、「先願明細書」という。)には、図面とともに以下の事項が記載されている。

イ.「【0001】
本発明は、VｏIP(Voice over Internet Protocol)を利用して通話等の通信サービスを行うIP電話システムの管理技術に関し、特に、端末装置の保守に関する処理を行う保守装置の改良技術に関する。」(3頁)

ロ.「【0026】
[第1の実施の形態]
以下、本発明の実施の形態について図面を参照して説明する。本発明に係る保守端末装置は、VｏIP(Voice over IP)を利用して通話を行うIP電話システムに適用される。
【0027】
[システム概略図]
図1は、本発明の一実施形態が適用されたIP電話システムの概略図である。同図に示すように、本IP電話システムは、1または1以上のIP電話端末10-1・・・10-nと、IP電話端末10とLAN(Local Area Network)50を介して接続されたルータ40と、ルータ40および所定の通信網(例えば、インターネット)30を介してIP電話端末10と接続された保守サーバ20と、同様にルータ40および所定の通信網30を介してIP電話端末10と接続されIP電話端末10の通話を管理する呼制御サーバ60と、から構成される。
【0028】
各IP電話端末10は、それぞれのIPアドレスを備え、主に、アナログ音声信号をディジタル信号に変換する音声符号化機能、ディジタル化した音声信号をIPパケットとして加工するパケット化機能、図示しない入力手段から入力された電話番号をパケットの宛先のIPアドレスに変換するアドレス変換機能、および所定の呼制御プロトコルに従い通話を管理する呼制御機能を備えている。
【0029】
このような呼制御プロトコルには、例えば、TCP(Transmission Control Protocol)上で利用されるH.323プロトコルや、UDP(User Datagram Protocol)上で利用されるSIP(Session Initiation Protocol)などがある。本実施形態では、一例としてSIPを用いた場合について説明する。この場合、IP端末10は、SIPクライアントとして機能する。
【0030】
なお、本実施形態に係るIP電話端末10は、上記機能を備えた単一の装置として構成されているが、IP電話端末10の構成はこれに限られない。例えば、アナログ電話装置とVｏIPゲートウェイとを接続することにより構成されるものも、本実施形態に係るIP電話端末10に該当する。また、電話用のヘッドセット(マイクとスピーカ)や上記機能を実現するためのプログラムを実装したパーソナルコンピュータ等の汎用の情報処理装置であってもよい。
【0031】
ルータ40は、IPパケットに書き込まれた宛先のIPアドレスを読み取って、最適な方向にIPパケットを送出する機能を備えた経路選択装置(中継器)である。また、ルータ40は、外部のネットワークを通じて第三者が侵入することを防止するためファイヤーオール機能を備える。ファイヤーオール機能には、侵入検知システムやIPパケットの暗号化など周知の技術を適用することができる。ルータ40は、このファイヤーオール機能により、通信網30から受け入れたIPパケットが設定された条件に合致しない場合には、このIPパケットを受け付けず、その旨を発信元に送り返す。
【0032】
保守サーバ20は、IP電話システムを良好な稼動状態に保つためのサービスを提供するものである。保守サーバ20は、例えば、IP電話端末10内のデータやプログラムを必要に応じて更新・変更する機能や、IP電話端末10の稼動状況を外部から遠隔監視し、障害発生時に障害内容の通知や復旧作業を遠隔操作によって行う障害回復機能を備える。また、保守サーバ20は、所定の呼制御プロトコルを実装する。ここでは、上述したようにSIPを実装する。」(5?6頁)

ハ.「【0057】
[データフォーマット]
図4は、本実施形態に係るデータ構成の一例を示す図である。
【0058】
図4(A)は、通常の呼制御処理を実行する際に送受信されるメッセージの一例である。図4(B)は、保守管理処理を実行する際に送受信される保守情報が格納されたメッセージの一例である。
【0059】
本実施形態では、「SIP INVITE メッセージ」のヘッダ部分に保守管理情報を格納している。具体的には、未規定部分に相当する「Meｓｓage Headeｒ」内の「Uｓeｒ-Agenｔ」フィールドに、保守情報が記載される。図4(A)では、「Uｓeｒ-Agenｔ」フィールドに通常の情報70aが記載されており、図4(B)では、「Uｓeｒ-Agenｔ」フィールドに保守情報70bが記載されていることがわかる。
【0060】
図5は、保守サーバの処理手順を示すフローチャートである。具体的には、保守サーバ20における呼制御部205、保守管理部206およびパケット処理部204のプログラムの処理内容の概要を表したものである。
【0061】
まず、保守管理部206は、保守処理を実行するか否かを判断する(STEP501)。例えば、特定のIP電話端末について特定の時間を指定した保守処理の実行が入出力部208を介して入力された場合には、保守管理部206は、保守処理を実行すると判断する。また、IP電話端末10に対するアクセス時間や対象となるIP電話端末10が予め設定されている場合には、これらの設定に従い保守処理の実行を判断する。
【0062】
そして、保守処理を実行すると判断した保守管理部206は、入力された情報あるいは設定された条件に従って、保守対象となるIP電話端末10を特定する(STEP503)。また、保守管理部206は、保守処理が所定の情報の設定である場合は、入力された情報あるいは設定された条件に従って、設定対象となる情報を記憶部210から読み込み、読み込んだ情報と設定命令とを含む保守情報を生成する(STEP505)。
【0063】
次に、保守対象となるIP電話端末が特定され、保守情報が生成されると、保守管理部206は、対象となるIP電話端末10が対応する呼制御手順プロトコルのデータフォーマットに従い、保守情報を格納する。ここで、保守情報は、呼制御手順プロトコルが本来予定している呼制御の処理とは異なる処理に関する情報である。従って、保守管理部206は、呼制御手順プロトコルのデータフォーマットにおいて、呼制御に利用されない所定の部分(未規定の部分、例えば、「Meｓｓage Headeｒ」内の「Uｓeｒ-Agenｔ」フィールド)に、保守情報を格納する。これにより、IP電話端末10において、呼制御処理のエラーや不具合を生じさせることなく保守情報を解釈実行させることができる。
【0064】
なお、各IP電話端末10が採用する呼制御手順プロトコルは、IP電話端末ごとに異なる場合があるので、IP電話端末10が対応する呼制御手順プロトコルの情報は、予め記憶部210に格納しておくか、入出力部208を介して入力するものとする。
【0065】
呼制御部205は、パケット処理部204を介して、IP電話端末10に対する接続情報(電話番号)及び接続要求メッセージを含む接続要求パケットを通信網30に送出する(STEP509)。その後、呼制御サーバ60を介して、IP電話端末10との間で通話路が確立すると、呼制御手順プロトコルの未規定部分に保守情報を格納したパケットを
送出する(STEP511)。通常の通話の場合、通話路が確立すると、発信側の保守サーバ20と着信側のIP電話端末10との間では、RTPに従い音声信号が格納されたIPパケットが送受信されるが、ここでは、音声パケットの代わりに、保守情報が格納されたパケットが保守サーバ20からIP電話端末10へ送信される。
【0066】
[IP電話端末の処理手順]
図6は、IP電話端末10の処理手順を示すフローチャートである。具体的には、IP電話端末10におけるパケット処理部104、呼制御部106および保守管理部206のプログラムの処理内容の概要を表したものである。
【0067】
パケット処理部104は、ネットワークインターフェース部50を介してパケットを受信すると(STEP601)、受け取ったパケットに含まれるデータが所定の呼制御プロトコルに従うデータであるか否かを判断する(STEP603)。そして、受け取ったパケットに含まれるデータが所定の呼制御プロトコルに従うデータであると判断した場合は(STEP603のYeｓ)、そのデータを呼制御部106に受け渡す。
【0068】
呼制御部106は、受け渡されたデータが保守情報を送信するものであるか否かを判断する(STEP605)。具体的には、呼制御プロトコルのデータフォーマット中の未規定部分に、保守情報が格納されている場合には、保守情報を送信するものであると判断し(STEP605のYeｓ)、保守情報を抽出する(STEP607)。一方、呼制御プロトコルのデータフォーマットに従い、呼制御に関する情報が格納されている場合には、保守情報を送信するものではないので(STEP605のNｏ)、呼制御処理を実行する(STEP606)。
【0069】
保守管理部114は、呼制御部106により抽出された保守情報に基づいて、保守処理を実行する。例えば、保守管理部114は、保守情報が情報の設定命令である場合は(STEP609のYeｓ)、抽出された情報に従って記憶部116を更新する(STEP611)。一方、保守情報が情報の収集命令である場合は(STEP613のYeｓ)、指示内容に従って所定の情報を取得する(STEP615)。保守管理部114は、保守処理の実行結果をパケット処理部104に通知する。
【0070】
パケット処理部104は、通知された内容に従い保守サーバ20を宛先とする応答パケットを生成し(STEP617)、ネットワークインターフェース部102は、これを送信する(STEP619)。」(10?11頁)

上記先願明細書の記載及び図面並びにこの分野における技術常識を考慮すると、上記摘記事項ロ.の【0026】、【0027】、【0029】、【0032】の記載、及び図1によれば、IP電話システムは、IP電話端末(10)と、保守サーバ(20)とを有し、呼制御を行うために用いるSIP(Session Initiation Protocol)を実装したIP電話端末(10)を遠隔から保守するものである。
また、上記摘記事項ハ.の【0067】?【0070】の記載、及び図6によれば、IP電話端末(10)は、呼制御プロトコルを用いて実行される保守情報を、呼制御プロトコルにより受信し、実行結果を送信し、保守情報に基づき保守制御をしている。
ここで、上記摘記事項ハ.の【0063】における「保守情報は、呼制御手順プロトコルが本来予定している呼制御の処理とは異なる処理に関する情報である。」との記載によれば、保守情報は、呼制御とは異なる機能として備えられたものということができる。また、呼制御プロトコルは、呼制御のための呼制御情報と同じプロトコルであることは明らかである。
また、上記摘記事項ハ.の【0065】?【0070】の記載、図5及び図6によれば、保守サーバ(20)は、IP電話端末(10)との間で呼制御プロトコルにより保守情報を送信し、実行結果を受信していることが読み取れる。ここで、上記摘記事項ハ.の【0069】における「保守情報が情報の設定命令である場合は(STEP609のYeｓ)、抽出された情報に従って記憶部116を更新する(STEP611)。一方、保守情報が情報の収集命令である場合は(STEP613のYeｓ)、指示内容に従って所定の情報を取得する(STEP615)。」との記載によれば、保守サーバ(20)は、IP電話端末(10)に保守制御を指示しているから、IP電話端末(10)へ保守制御の指示を通知しているということができる。
また、上記摘記事項ハ.の【0058】、【0063】の記載、図4(B)及び図5によれば、呼制御プロトコルは、SIP(Session Initiation Protocol)であり、保守情報を格納したものである。

したがって、先願明細書には以下の発明(以下、「先願発明」という。)が記載されている。

「呼制御を行うために用いるSIP(Session Initiation Protocol)を実装したIP電話端末(10)を遠隔から保守するIP電話システムであって、
前記SIP(Session Initiation Protocol)を用いて実行される前記呼制御とは異なる機能として備えられた保守情報及び実行結果を、前記呼制御のための呼制御情報と同じ前記SIP(Session Initiation Protocol)により送受信し、保守情報に基づき保守制御を実行するIP電話端末(10)と、
前記IP電話端末(10)との間で前記SIP(Session Initiation Protocol)により保守情報及び実行結果を送受信し、前記IP電話端末(10)に前記保守制御を指示する保守サーバ(20)とを有し、
前記SIP(Session Initiation Protocol)は、保守情報を格納したSIP(Session Initiation Protocol)である、
前記保守サーバ(20)から前記IP電話端末(10)へ前記保守制御の指示が通知される、
IP電話システム。」

第4 対比・判断
本願発明と先願発明とを対比する。
a.先願発明の「呼制御を行うために用いるSIP(Session Initiation Protocol)」、「IP電話端末(10)」、及び「保守サーバ(20)」は、本願発明の「機器機能を実行するために用いる通信プロトコル」、「情報通信機器」、及び「保守・メンテナンス機器」にそれぞれ相当する。
b.先願発明の「保守情報」及び「実行結果」は、本願発明の保守・メンテナンスのための「保守・メンテナンス情報」に含まれる。
c.先願発明の「保守制御」は、本願発明の「保守・メンテナンス制御」に含まれる。
d.先願発明の「保守情報を格納した」と、本願発明の「保守・メンテナンス制御のコマンドが付加された」とは、いずれも、「保守に関する要素を有した」点で一致する。
e.先願発明の「IP電話システム」は、遠隔保守をするから、遠隔保守・メンテナンスシステムの一種である。

したがって、本願発明と先願発明は、以下の点で一致し、以下の点で一応相違する。

＜一致点＞
「機器機能を実行するために用いる通信プロトコルを実装した機器を遠隔から保守・メンテナンスする遠隔保守・メンテナンスシステムであって、
前記通信プロトコルを用いて実行される前記機器機能とは異なる機能として備えられた前記保守・メンテナンスのための保守・メンテナンス情報を、前記機器機能のための機器機能情報と同じ前記通信プロトコルにより送受信し、前記保守・メンテナンス情報に基づき保守・メンテナンス制御を実行する情報通信機器と、
前記情報通信機器との間で前記通信プロトコルにより前記保守・メンテナンス情報を送受信し、前記情報通信機器に前記保守・メンテナンス制御を指示する保守・メンテナンス機器とを有し、
前記通信プロトコルは、保守に関する要素を有したSIPであり、
前記保守・メンテナンス機器から前記情報通信機器への前記保守・メンテナンス制御の指示が通知される、
遠隔保守・メンテナンスシステム。」

＜相違点＞
「保守に関する要素を有した」SIPに関し、
本願発明は、「保守・メンテナンス制御のコマンドが付加された」ものであるのに対し、先願発明は、「保守情報を格納した」ものである点。

加えて、
「保守・メンテナンス制御の指示」に関し、
本願発明は、「前記コマンドを用いる」ものであるのに対し、先願発明は、「前記コマンドを用いる」との特定がない点。

そこで、上記相違点について検討する。
先願明細書の上記摘記事項ハ.の【0069】における「保守情報が情報の設定命令である場合は(STEP609のYeｓ)、抽出された情報に従って記憶部116を更新する(STEP611)。一方、保守情報が情報の収集命令である場合は(STEP613のYeｓ)、指示内容に従って所定の情報を取得する(STEP615)。」との記載によれば、保守情報は、保守制御の命令(コマンド)の要素を含むものであり、また、図4(B)によれば、保守情報が格納された、Uｓeｒ-Agenｔフィールド(70b)は、SIP INVITEメッセージのヘッダ部分における未規定部分に付加されているということができる。そうすると、先願明細書の「保守情報を格納した」ものは、「保守・メンテナンス制御のコマンドが付加された」ものということができ、また、「保守・メンテナンス制御の指示」に関し、「前記コマンドを用いる」ものであることは明らかであるから、上記相違点は実質的なものではなく、本願発明と先願発明とは、実質的に同一である。

第5 引用発明
原審の拒絶理由に引用された特表2004-523828号公報(以下、「引用例」という。)には、図面とともに以下の事項が記載されている。

ニ.「【0002】
本発明は、ネットワーク対応機器の操作を行うためのネットワークを通じたコントロール信号およびステータス信号の通信に関し、より詳細には、複数のネットワーク対応機器との通信を改良するためのセッション開始プロトコルの使用に関する。」(5頁)

ホ.「【0046】
図5は、ネットワーク対応機器をサポートするためのSIPアーキテクチャの機能図である。このアーキテクチャは、図3および図4のプロキシアーキテクチャを介したメッセージングに基づく。機能エンティティは、異なる物理的なネットワーク要素(図6参照)に分散することができる。上記の通り、ネットワーク対応機器の操作またはそのステータスを求める要求は、SIP UAC100の発信元クライアントアプリケーション(発信元アプリケーション)で開始する。発信元アプリケーションはSIP UAC100を使用して機器メッセージ(DO)を生成し、サービスプロバイダまたはホームRGWによってホストされるSIPプロキシ108に送信する。サービスプロバイダドメイン中のSIPプロキシ108は、位置データベース140で検索することにより、通信しようとする機器のアドレス(該当するホームドメインRGWを含む)を解決する。SIPプロキシは、クライアントSIP UA100からホームドメインRGW中のSIPプロキシ116’に機器メッセージを転送するか、またはセキュアな接続を介してターゲットデバイス中のSIP UASに直接転送する。
【0047】
位置データベース140は、ホームドメイン内のすべての登録された機器の位置情報を含む。このデータベースには、登録手順中にサービスプロバイダのSIPプロキシ108によって収集された情報が格納される。詳細には、REGISTERメッセージがプロキシ108に送信されてクライアントおよび各機器の位置を登録する。機器の場合、この登録は単にその機器がホームドメイン200内にあるということでよい。さらに、これすら登録できない場合には、ホームドメイン200のIPアドレスだけでよい。その場合、ユーザはホームドメイン中で利用できる機器を知っていることを求められる。そのドメインを宛先とする場合、メッセージは、プロキシ116’におけるアドレスマッピングによりその機器にアドレス指定される。
【0048】
ホームドメインの住居ゲートウェイ中のSIPプロキシ116’は、ホームドメイン内の機器と、ワイドエリアネットワーク300内のエンティティとの間のゲートウェイを提供する。ファイアウォールやNATなどの他のRGW機能は、RGW SIPプロキシ116’と同じ場所に置くことができる。SIP UASは、発信元アプリケーションSIP UAC100からのSIP機器メッセージを終了する。SIP UASは、SIPメッセージからメッセージング情報を取り出し、その情報をインターワーキング装置208に渡す。このSIP UASは、スタンドアロン装置でよく、図5に示すようにRGW116または機器コントローラ204に常駐する。SIP UACと機器コントローラとの論理的マッピングは1:Nであり、Nは、発信元プログラムがネットワークを通じて到達できるコントローラの数である。
【0049】
インターワーキング装置208は、SIPメッセージのペイロードで搬送される機器メッセージを、機器固有のプロトコルにマッピングする。このプロトコルは、非IP機器206によって解釈できる形態であり、したがって、非IP機器206は、発信元のクライアントアプリケーションと通信/対話するために、インターワーキング装置208の使用を通じて機器コントローラ204によって制御される。
【0050】
SIP UAS(IP対応機器)202は、IP(SIP)対応ネットワーク対応機器内に常駐する。SIP UASは、発信元アプリケーションSIP UAC100からのSIP機器コントロールメッセージを終了し、機器アプリケーションの機器コントロールステータス情報を取り出し、非IP機器に必要とされる仲介のインターワーキング装置208または機器コントローラ204を必要とせずに、その情報に直接作用する。
【0051】
図5の主要インタフェースは、(1)SIPネットワーク対応機器、(2)機器の登録および位置、および(3)機器固有のインタフェースである。SIP機器インタフェースは、ネットワーク対応機器と通信するためのDOメソッドを備えるIETF SIPに相当する。機器の登録および位置のインタフェースは、任意の適切なデータベース更新と、位置データベース140にアクセスするのに使用する検索プロトコルによって実現される。そのようなプロトコルの例は、LDAPおよびSLPである。さらに、機器固有のインタフェースは、現在利用できる数多くのホームネットワーキング技術である。SIPから、ターゲット機器の固有の技術のプロトコルへのマッピングは、インターワーキング装置208の機能である。
【0052】
図5の機能システムの物理的な実現を図6に示し、ここでは発信元SIP UAC100がユーザのオフィスのPC101にある。このマシンからメッセージを発信して、例えばビデオカメラ210や照明212など住宅内のオブジェクトを操作する。このメッセージは、本発明により修正した標準的なSIP技術を使用して、その住宅を担当するサービスプロバイダシステム109(SIPプロキシ108を含む)に転送される。プロバイダ109は、メッセージをセットトップボックス(STB)117に送信するが、STB117は、RGW、ケーブルモデム、ADSLモデム、または展開された住宅技術の適切な他のエッジを含むことができる。STB117は、SIP対応デバイス(ビデオカメラ210や家庭用AV機器などより高機能のデバイスである傾向がある)に直接メッセージを送信するか、または機器コントローラの一部とすることができるインターワーキング装置208を介して間接的に送信する。この物理的実現では、ユーザは、自分たちのために行われている通信のレベルおよび精度(sophistication)を意識する必要がない。
【0053】
以下の例で、本発明によりDOタイプを含むように修正したSIP符号化を機器のドメイン間ネットワーキングに使用する方式を例示する。この説明では、すべてのSIPメッセージヘッダフィールドを含めてはいない(例えばCｓeｑ、Call-ID、およびCｏnｔenｔ-lengｔhなど)。説明を簡潔にするために、特に対象となるヘッダフィールドだけを含めている。また、デバイスメッセージングプロトコル(DMP)はまだ標準化されておらず、DMPの例は、例証だけを目的とすると考えるべきことにも留意されたい。
【0054】
図7に示すシナリオでは、ユーザは、オフィスのPC101から自宅のランプのスイッチをつけたい。住宅内のネットワーク対応機器(例えばランプ)の(例えばオフィスからの)リモートコントロールのためのSIPメッセージについて以下で説明する。実際の応用例でのSLP URL情報は、符号化され、任意でプライバシーのために暗号化されるが、分かりやすいように角括弧内では暗号化せずに示すことに留意されたい。この例では、ｓｔan.hｏme.neｔに位置する例えばセットトップボックス117などのユーザエージェントは、ｓｔan.hｏme.neｔに登録され、その情報がhｏme.neｔに伝達されている。下記の番号「1」のメッセージは、PCとアウトバウンドプロキシcｏ.cｏm間のものである。図7ではこれを円内の「1」として示している。
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
On
【0055】
cｏ.cｏmプロキシは、[d=lamｐ,ｒ=bedｒｏｏm,ｕ=ｓｔanm]@hｏme.neｔについてDNSでSRV検索を行って、宛先ドメインのSIPサーバの名前を見つけ、hｏme.neｔの値を入手する。これは、SRVレコードがあるサービスプロバイダのプロキシを指すときには、ユーザ/サービス名がそのサービスプロバイダのドメイン内で一意でなければならないことを意味する。
【0056】
図7のメッセージ「2」は、以下のようにcｏ.cｏmからhｏme.neｔへのものである。
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
On
【0057】
hｏme.neｔからｓｔan.hｏme.neｔ(セットトップボックス117など)へのメッセージは次である。
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
On
【0058】
セットトップボックス117からインターワーキング装置208へのメッセージは次である。
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
On
【0059】
そして、インターワーキング装置は、次のようにランプ212に動作メッセージを送信して、ランプのスイッチを入れる。
5. 上記のシナリオは失敗のシナリオを説明するためにも使用することができる。ランプは、メッセージを受信すると、電球が「切れて」(壊れて)いることに気付く可能性があり、それに応答して次のようなものを送信する。
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!」(13?17頁)

上記引用例の記載及び図面並びにこの分野における技術常識を考慮すると、上記摘記事項ホ.の【0046】、【0054】、【0059】の記載、図5乃至図7によれば、SIPアーキテクチャは、PC(101)とランプ(212)とを有し、リモートコントロールするために用いるSIPを実装したランプ(212)を遠隔からリモートコントロール動作の監視を行うものである。
また、上記摘記事項ホ.の【0059】における「次のようにランプ212に動作メッセージを送信して、ランプのスイッチを入れる。5. 上記のシナリオは失敗のシナリオを説明するためにも使用することができる。ランプは、メッセージを受信すると、電球が「切れて」(壊れて)いることに気付く可能性があり、それに応答して次のようなものを送信する。・・・(後略)・・・」との記載、及び図7によれば、ランプ(212)は、メッセージBulb has blown !! Replace with new !をSIPにより送信している。
また、PC(101)は、ランプ(212)との間でSIPによりメッセージBulb has blown !! Replace with new !を受信していることが読み取れる。
ここで、SIPは、リモートコントロールのためのメッセージと同じSIPである。

したがって、引用例には以下の発明(以下、「引用発明」という。)が記載されている。

「リモートコントロールするために用いるSIPを実装したランプ(212)を遠隔からリモートコントロール動作の監視を行うSIPアーキテクチャであって、
メッセージBulb has blown !! Replace with new !を、前記リモートコントロールのためのメッセージと同じ前記SIPにより送信するランプ(212)と、
前記ランプ(212)との間で前記SIPにより前記メッセージBulb has blown !! Replace with new !を受信するPC(101)とを有する、
SIPアーキテクチャ。」

第6 対比
本願発明と引用発明とを対比する。
f.引用発明の「リモートコントロールするために用いるSIP」、及び「ランプ(212)」は、本願発明の「機器機能を実行するために用いる通信プロトコル」、及び「情報通信機器」にそれぞれ相当する。
g.引用発明の「リモートコントロール動作の監視を行う」と、本願発明の「保守・メンテナンスする」とは、いずれも、「処理する」という点で一致する。
h.引用発明の「メッセージBulb has blown !! Replace with new !」と、本願発明の「前記通信プロトコルを用いて実行される前記機器機能とは異なる機能として備えられた前記保守・メンテナンスのための保守・メンテナンス情報」とは、いずれも、「情報」という点で一致する。
i.引用発明の「前記リモートコントロールのためのメッセージと同じ前記SIP」は、上記e.の対比を考慮すると、「前記機器機能のための機器機能情報と同じ前記通信プロトコル」ということができる。
j.引用発明の「PC(101)」と、本願発明の「保守・メンテナンス機器」とは、いずれも、「特定の機器」という点で一致する。
k.引用発明の「SIPアーキテクチャ」は、システムの一種である。

したがって、本願発明と引用発明は、以下の点で一致ないし相違する。

＜一致点＞
「機器機能を実行するために用いる通信プロトコルを実装した機器を遠隔から処理するシステムであって、
情報を、前記機器機能のための機器機能情報と同じ前記通信プロトコルにより送信する情報通信機器と、
前記情報通信機器との間で前記通信プロトコルにより前記情報を受信する特定の機器とを有する、
システム。」

＜相違点1＞
システムにおける「処理する」に関し、
本願発明は、「保守・メンテナンスする」のに対し、引用発明は、「リモートコントロール動作の監視を行う」点。

＜相違点2＞
「情報」に関し、
本願発明は、「前記通信プロトコルを用いて実行される前記機器機能とは異なる機能として備えられた前記保守・メンテナンスのための保守・メンテナンス情報」であるのに対し、引用発明は、「メッセージBulb has blown !! Replace with new !」である点。

＜相違点3＞
「情報通信機器」における「送信」に関し、
本願発明は、「送受信」であるのに対し、引用発明は、「送信」である点。

＜相違点4＞
「情報通信機器」の態様に関し、
本願発明は、「前記保守・メンテナンス情報に基づき保守・メンテナンス制御を実行する」ものであるのに対し、引用発明は、その様な構成を備えていない点。

＜相違点5＞
「特定の機器」における「受信」に関し、
本願発明は、「送受信」であるのに対し、引用発明は、「受信」である点。

＜相違点6＞
「特定の機器」の態様に関し、
本願発明は、「前記情報通信機器に前記保守・メンテナンス制御を指示する」ものであるのに対し、引用発明は、その様な構成を備えていない点。

＜相違点7＞
「特定の機器」に関し、
本願発明は、「保守・メンテナンス機器」であるのに対し、引用発明は、「PC(101)」である点。

＜相違点8＞
「通信プロトコル」に関し、
本願発明は、「前記通信プロトコルは、保守・メンテナンス制御のコマンドが付加されたSIPである」ものであるのに対し、引用発明は、その様な構成を備えていない点。

＜相違点9＞
「通信プロトコル」に関し、
本願発明は、「前記保守・メンテナンス機器から前記情報通信機器への前記保守・メンテナンス制御の指示が前記コマンドを用いて通知される」ものであるのに対し、引用発明は、その様な構成を備えていない点。

第7 判断
そこで、まず、上記相違点1について検討する。
上記引用例の上記摘記事項ホ.の【0059】の記載によれば、引用発明は、ランプ(212)(情報通信機器)の電球が切れて(壊れて)いた場合、メッセージBulb has blown !! Replace with new !を送信し、新品との交換(保守・メンテナンス)を要求するから、本願発明のように「保守・メンテナンスする」ということができることは当然である。

次に、上記相違点2について検討する。
引用発明は、「メッセージBulb has blown !! Replace with new !」であるところ、ランプ(212)(情報通信機器)の電球が切れて(壊れて)いた場合、新品との交換(保守・メンテナンス)を要求するものであって、SIPを用いて実行されるリモートコントロールとは異ることは明らかであるから、本願発明のように「前記通信プロトコルを用いて実行される前記機器機能とは異なる機能として備えられた前記保守・メンテナンスのための保守・メンテナンス情報」ということができることは当然である。

次に、上記相違点3乃至7について検討する。
遠隔保守・メンテナンスシステムにおいて、保守・メンテナンス情報を送受信し、保守・メンテナンス情報に基づき保守・メンテナンス制御を実行する情報通信機器と、保守・メンテナンス情報を送受信し、情報通信機器に保守・メンテナンス制御を指示する保守・メンテナンス機器とを設けることは、例えば、特開2004-187149号公報(段落42?48、図4)に開示されるように周知であるから、引用発明に周知技術を適用して、本願発明のように「情報通信機器」における「送信」、「特定の機器」における「受信」に関し、共に「送受信」とすること(相違点3、5)、「情報通信機器」に関し、本願発明のように「前記保守・メンテナンス情報に基づき保守・メンテナンス制御を実行する」ものとすること(相違点4)、「特定の機器」に関し、本願発明のように「前記情報通信機器に前記保守・メンテナンス制御を指示する」ものとすること(相違点6)は当業者が容易に成し得ることである。また、その際、引用発明の「PC(101)」を、本願発明のように「保守・メンテナンス機器」と称することができること(相違点7)は当然である。

次に、上記相違点8について検討する。
通信プロトコルを、保守・メンテナンス制御のコマンドが付加されたSIPとすることは、例えば、前述の特開2004-187149号公報(段落43、44、46)に開示されるように周知であるから、引用発明に周知技術を適用して、本願発明のように「前記通信プロトコルは、保守・メンテナンス制御のコマンドが付加されたSIPである」ものとすることは当業者が容易に成し得ることである。

次に、上記相違点9について検討する。
上記相違点6乃至8についての検討を踏まえれば、「前記通信プロトコルは、保守・メンテナンス制御のコマンドが付加されたSIPである」から、本願発明のように「前記保守・メンテナンス機器から前記情報通信機器への前記保守・メンテナンス制御の指示が前記コマンドを用いて通知される」ものとすることは当業者が容易に成し得ることである。

そして、本願発明の作用効果も、引用発明及び周知技術から当業者が容易に予測できる範囲のものである。


第8 むすび
以上のとおり、本願発明は、先願明細書に記載された発明と同一であり、しかも、先願明細書に記載された発明をした者が本願発明の発明者であるとも、又、本願の出願の時に、その出願人が先願明細書の出願人と同一であるとも認められないから、特許法第29条の2の規定により、特許を受けることができない。また、本願発明は、引用発明及び周知技術に基いて当業者が容易に発明をすることができたものと認められるから、特許法第29条第2項の規定により特許を受けることができない。

よって、結論のとおり審決する。

 
審理終結日 2011-11-24 
結審通知日 2011-11-29 
審決日 2011-12-15 
出願番号 特願2005-48961(P2005-48961)
審決分類 P 1 8・ 121- Z (H04L)
P 1 8・ 161- Z (H04L)
最終処分 不成立  
前審関与審査官 石田 紀之  
特許庁審判長 藤井 浩
特許庁審判官 神谷 健一
萩原 義則
発明の名称 遠隔保守・メンテナンスシステム、SIP搭載機器、保守・メンテナンス機器および方法  
代理人 石橋 政幸  
代理人 緒方 雅昭  
代理人 宮崎 昭夫  

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