ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04N |
|---|---|
| 管理番号 | 1328432 |
| 審判番号 | 不服2015-13838 |
| 総通号数 | 211 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2017-07-28 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2015-07-23 |
| 確定日 | 2017-05-18 |
| 事件の表示 | 特願2012-111425「遠隔診断の方法および遠隔診断を実行するセットトップ・ボックス」拒絶査定不服審判事件〔平成24年11月 1日出願公開、特開2012-213168〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
1.手続の経緯 本願は、2002年3月15日(パリ条約による優先権主張外国庁受理2001年3月20日、米国)を国際出願日として出願した特願2002-573438号の一部を平成21年3月26日に新たな特許出願とした特願2009-76005号の一部を平成24年5月15日に新たな特許出願としたものであって、手続の経緯の概要は、以下のとおりである。 手続補正 平成24年 9月27日 拒絶理由通知 平成25年 8月13日(起案日) 手続補正 平成26年 2月21日 拒絶理由通知(最後) 平成26年 4月21日(起案日) 手続補正 平成26年10月21日 補正の却下の決定 平成27年 3月17日(起案日) 拒絶査定 平成27年 3月17日(起案日) 拒絶査定不服審判請求 平成27年 7月23日 手続補正 平成27年 7月23日 拒絶理由通知(当審) 平成28年 5月17日(起案日) 手続補正 平成28年11月15日 2.本願発明 本願の請求項1ないし4に係る発明は、平成28年11月15日付けで補正された特許請求の範囲の請求項1ないし4に記載されたとおりのものであり、そのうち、請求項1に係る発明(以下、「本願発明」という。)は、次のとおりである。 なお、A?Gについては、説明のために当審にて付したものである。 (以下、「構成A」、・・・、「構成G」という。) 「A ヘッドエンド装置、および診断用のソフトウェアを有する装置を備えるディジタル加入者線ネットワークにおける遠隔診断の方法であって、 B ユーザからのリクエストに応答して前記ヘッドエンド装置から前記装置にデータ・リクエストを送信するステップと、 C 受信したデータ・リクエストが前記装置に対し、当該装置内に存在する内部診断用ソフトウェアを実行することを要求しているかどうかを判定するステップと、 D 前記データ・リクエストが前記装置に前記内部診断用ソフトウェアを実行することを要求していなければ、前記データ・リクエストの受信に応答して、前記装置から前記ヘッドエンド装置に第1の応答を送信するステップと、 E 前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、前記データ・リクエストの受信に応答して、前記内部診断用ソフトウェアを実行するステップと、 F 前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、前記データ・リクエストに応答して第2の応答を前記装置から前記ヘッドエンド装置に送信するステップであって、前記第2の応答は、当該データ・リクエストの結果として前記装置によって生成されたデータを含み、当該データは、エラー・コード、機器識別、ソフトウェア改訂、ビットレート、およびビット・エラーレートのうちの少なくとも1つを含み、前記装置は、利用者宅内にある、前記送信するステップと、 G を含む、前記遠隔診断の方法。」 3.引用発明 当審の拒絶理由通知に引用された、特開平7-203028号公報(以下、「引用例1」という。)には、「メンテナンス情報収集方式と、該方式を構成する保守センタ側端末装置及びユーザ側端末装置」として、図面とともに以下の事項が記載されている。 なお、下線は、当審にて付したものである。 ア.「【0001】 【産業上の利用分野】本発明は、メンテナンス情報収集方式と、該方式を構成する保守センタ側端末装置及びユーザ側端末装置に関するもであり、更に詳しくは、通信網に接続されたユーザ側端末装置から保守センタ側に障害発生の申告がなされたとき、保守センタ側端末装置から通信網を介して前記ユーザ側端末装置にアクセスして、障害発生の原因解明に必要なユーザ側端末装置関連情報をメンテナンス情報として保守センタ側に収集するメンテナンス情報収集方式と、該方式における前記保守センタ側端末装置及びユーザ側端末装置に関するもである。」 イ.「【0007】そこで本発明では、かかる問題点を解決し、ユーザ側からユーザ側データ送受信端末装置について不具合が保守センタ側に申告されたとき、その不具合の原因解明に役立つ端末装置関連情報を、メンテナンス情報(正確にはメンテナンスに役立つ情報)として、正確かつ大量に、ごそっと保守センタ側に取り込むことができて、適切な対応が可能になるメンテナンス情報収集方式と、該情報収集方式を構成する保守センタ側端末装置及びユーザ側端末装置を、提供することを目的とする。 【0008】 【課題を解決するための手段】上記目的達成のため、本発明では、通信網に接続されたユーザ側端末装置から保守センタ側に障害発生の申告がなされたとき、保守センタ側端末装置から通信網を介して前記ユーザ側端末装置にアクセスして、障害発生の原因解明に必要なユーザ側端末装置関連情報をメンテナンス情報として保守センタ側に収集するメンテナンス情報収集方式において、ユーザ側端末装置には、当該装置の関連情報をメンテナンス情報として送信するためのプログラムを診断プログラムとして、そのアプリケーションプログラムの中に含ませ、保守センタ側端末装置には、診断プログラム起動コマンドの送出手段と、記憶ファイルと、を設けることとした。 【0009】 【作用】保守センタ側端末装置では、ユーザ側端末装置から障害発生の申告がなされたとき、通信網を介して当該ユーザ側端末装置に向け、コマンド送出手段から診断プログラム起動コマンドを送出する。そしてその保守センタ側端末装置から送信された診断プログラム起動コマンドが、ユーザ側端末装置に受信されると、ユーザ側端末装置のアプリケーションプログラムに含まれている診断プログラムが起動して、当該ユーザ側端末装置の、障害発生の原因解明に役立つ関連情報をメンテナンス情報として、通信網を介して保守センタ側端末装置に送出する。保守センタ側端末装置では、これを受信して記憶ファイルに格納し、障害発生の原因解明に供する。」 ウ.「【0011】 【実施例】次に図を参照して本発明の実施例を説明する。図1は、本発明の一実施例としてのメンテナンス情報収集方式を示す構成図である。同図において、1はユーザ設置端末(データ送受信端末として例えば、パケット形態端末を想定しており、パソコンで構成される)、2はISDN網、3は保守センタ側設置端末(やはりパケット形態端末を想定しており、パソコンで構成される)、4,5はそれぞれISDN網の提供する信号チャネルとしてのDチャネル、10はユーザ設置端末1のアプリケーションプログラムに含ませた診断プログラム(正確には、診断に供する情報の提供プログラム)、である。」 エ.「【0013】図1、図2を参照する。ユーザ設置端末1は、データ通信端末として、通常はISDN網2を介して図示せざる他のデータ通信端末との間で、データの送受信を行っている。そのユーザ設置端末1に何らかの障害が起きると、ユーザは電話連絡などにより保守センタ側に、その旨の申告を行う。すると保守センタ側では、保守センタ側設置端末3を使い、ISDN網2を介して、障害の起きたユーザ設置端末1にアクセスして、メンテナンス情報をそのユーザ設置端末1から収集しようとする。」 オ.「【0015】こうして呼が設定されると、保守センタ側設置端末3からコマンド送信が開始される。即ち、保守センタ側設置端末3は、診断プログラム起動コマンドをデータパケットDTとして、ISDN網2を介してユーザ設置端末1に送信する。これを受信したユーザ設置端末1では、そのアプリケーションプログラム中に予め含ませておいた診断プログラム(ユーザ設置端末1の障害時、その原因解明つまり診断に必要な、当該端末の関連情報を、メンテナンス情報として送信するためのプログラム)を起動する。 【0016】その結果、障害の原因解明に役立つ当該端末の関連情報として、通信ボード情報、アプリケーションプログラムに関するソフトウエア情報、及び通信設定環境に関する情報が、データパケットDTとして、ISDN網2を介して保守センタ側設置端末3に送られ、保守センタ側設置端末3では、これらの情報を一括してファイル(図示せず)に記憶する。保守センタ側では、ファイルに一括記憶された大量の正確な情報を基に、障害の原因究明を行うことができ、その後の、ユーザ側に対する的確な応対を可能にする。」 カ.「【0018】上述の通信ボード情報、アプリケーションプログラムに関するソフトウエア情報、及び通信設定環境に関する情報の具体例を次に説明する。通信ボードというのは、ユーザ設置端末としてのパソコンをISDN網に接続する際に用いられる装置であるが、この通信ボード情報としては、適合認定・形式指定番号、IBIOS.EXE実行時の情報、日付などがある。 【0019】アプリケーションプログラムに関するソフトウエア情報としては、ソフトウエアバージョン、受信電文ファイル格納ディレクトリ容量情報、初期設定情報がある。初期設定情報には、自局テレックス番号、自局テレックスアンサーバック送信〔手動/自動〕、自局ISDN番号、自局ISDNサブアドレス、NCU種別、モニタプリンタ種別、モニタプリンタ接続ポート番号、モニタプリンタ通信速度、モニタプリンタデータ長、等々が含まれる。」 キ.「【0021】図3は、ユーザ設置端末1としてのパソコンに搭載されるプログラム構成例を示した説明図である。即ち、パソコンには、OS(オペレーションシステム)とAP(アプリケーションプログラム)とAPIライブラリ(ツール)が搭載されるが、本発明では、その中のAP(アプリケーションプログラム)に、特に診断機能として前述の診断プログラム(障害時、その原因解明つまり診断に必要な、当該パソコンの関連情報を、メンテナンス情報として送信するためのプログラム)を、他の諸々の諸機能と共に、含ませている点が特徴である。」 ク.「【0025】図6は、図1においてユーザ設置端末1が、本発明を実行する際に行う動作のフローを示すチャートである。先ず、保守センタ側端末3から受信する直前の画面(着信前画面)状態において、着呼を検出し、次に受信したものが診断プログラム起動コマンドであるか、それ以外のデータであるか判断し、データであれば通常のデータ受信を行い、コマンドであれば、診断プログラムの起動を行い、その結果として関連情報をリモートメンテナンスデータとして保守センタ側端末3に向け送信する。」 このような事項を踏まえ、上記ア.?ク.の記載及び関連する図面並びにこの分野における技術常識を考慮すると、 (a)引用例1には、上記ア.、イ.に記載があるように、通信網に接続されたユーザ側端末装置から障害発生の申告がなされたとき、保守センタ側端末装置から通信網を介して前記ユーザ側端末装置にアクセスして、障害発生の原因解明に必要なユーザ側端末装置関連情報をメンテナンス情報として保守センタ側に収集するメンテナンス情報収集方式において、ユーザ側端末装置に、当該装置の関連情報をメンテナンス情報として送信するためのプログラムを診断プログラムとして含ませることにより、適切な対応が可能になるメンテナンス情報収集方式についての記載がある。 (b)上記イ.、ウ.、キ.の記載から、引用例1のメンテナンス情報収集方式は、保守センタ側端末装置、および診断プログラムを含むユーザ側端末装置を備えるISDN網を介したメンテナンス情報収集方式である。 (c)上記イ.、エ.、オ.の記載から、引用例1のメンテナンス情報収集方式は、ユーザ側端末装置から障害発生の申告がなされると、保守センタ側端末装置からユーザ側端末装置に診断プログラム起動コマンドを発信する段階を含むものである。 (d)上記イ.、オ.の記載から、引用例1のメンテナンス情報収集方式は、ユーザ側端末装置が診断プログラム起動コマンドを受信すると、ユーザ側端末装置に含まれている診断プログラムの起動を行う段階を含むものである。 (e)上記イ.、オ.、カ.の記載から、引用例1のメンテナンス情報収集方式は、ユーザ側端末装置が診断プログラム起動コマンドを受信すると、障害の原因解明に役立つ当該ユーザ側端末装置の関連情報を、ユーザ側端末装置から保守センタ側端末装置に送信する段階を含むものであり、関連情報は、ソフトウェアバージョン、自局テレックス番号、自局ISDN番号を含むものである。 そして、引用例1のメンテナンス情報収集方式は、上記(c)?(e)のような段階を含むものであるから、以下のようなメンテナンス情報収集方法の発明(以下、「引用発明」という。)が開示されているものといえる。 なお、a?eについては、説明のために当審にて付したものである。(以下、「構成a」、・・・、「構成e」という。) [引用発明] 「a 保守センタ側端末装置、および診断プログラムを含むユーザ側端末装置を備えるISDN網を介したメンテナンス情報収集方法であって、 b ユーザ側端末装置から障害発生の申告がなされると、保守センタ側端末装置からユーザ側端末装置に診断プログラム起動コマンドを発信する段階と、 c ユーザ側端末装置が診断プログラム起動コマンドを受信すると、ユーザ側端末装置に含まれている診断プログラムの起動を行う段階と、 d ユーザ側端末装置が診断プログラム起動コマンドを受信すると、障害の原因解明に役立つ当該ユーザ側端末装置の関連情報を、ユーザ側端末装置から保守センタ側端末装置に送信する段階であって、関連情報は、ソフトウェアバージョン、自局テレックス番号、自局ISDN番号を含む段階と、 e を含む、前記メンテナンス情報収集方法。」 4.本願発明と引用発明との対比と、一致点・相違点の認定 ア.対比 (ア-1)構成Aについて 引用発明の構成aの「メンテナンス情報収集方法」は、構成b?dを考慮するに、ユーザ側端末装置の障害発生時に診断プログラムを起動し、ISDN網を介した保守センタ側端末装置にて、障害の原因解明に役立つ当該ユーザ側端末装置の関連情報を収集するものである。 ここで、保守センタ側端末装置は、ISDN網を介していることから、遠隔地にあり、関連情報を収集することによりユーザ側端末装置の状態を遠隔地で診断するものといえるから、引用発明の構成aの「メンテナンス情報収集方法」は、本願発明の構成Aの「遠隔診断の方法」に相当する。 また、引用発明の構成aの「保守センタ側端末装置」、「ユーザ側端末装置」は、本願発明の構成Aの「ヘッドエンド装置」、「装置」に相当し、構成aの「診断プログラム」は、構成Aの「診断用のソフトウェア」に相当する。 さらに、引用発明の構成aの「ISDN網」は、デジタルのネットワークであるから、本願発明の構成Aの「ディジタル加入者線ネットワーク」に相当する。 したがって、引用発明の構成aは、本願発明の構成Aに相当する。 (ア-2)構成Bについて 引用発明の構成bの「ユーザ側端末装置から障害発生の申告」をすることは、保守センタ側端末装置が関連情報を収集し、障害に対する適切な対応を行うために申告をするのであるから、ユーザが保守センタ側端末装置に障害に対する対応を依頼するために送信しているといえるので、本願発明の構成Bの「ユーザからのリクエスト」に相当する。 引用発明の構成bの「診断プログラム起動コマンド」は、ユーザ側端末装置に対して、診断プログラムの起動を行わせ、関連情報を送信させるための信号であり、関連情報というデータを要求する信号であるから、本願発明の構成Bの「データ・リクエスト」に相当する。 また、引用発明の構成bは、「障害発生の申告がなされると、」「診断プログラム起動コマンドを発信する」ものであり、申告に応答して、診断プログラム起動コマンドを送信するものである。 したがって、引用発明の構成bは本願発明の構成Bに相当する。 (ア-3)構成Cについて 引用発明は、構成cのように、診断プログラム起動コマンドを受信すると、診断プログラムの起動を行うものであり、受信してから起動を行う間に、受信したコマンドが、診断プログラムを起動することを要求しているかどうかを判定する構成を含んでいない。 したがって、引用発明は、本願発明の構成Cのような構成を含むものではない。 (ア-4)構成Dについて 上記(ア-3)で検討したように、引用発明は、本願発明の構成Cのような判定する構成を含むものではないので、要求しているかどうかを判定した結果として生じる構成である、本願発明の構成Dの「前記データ・リクエストが前記装置に前記内部診断用ソフトウェアを実行することを要求していなければ、」という前提を有さないものである。 さらに、引用発明が、ユーザ側端末装置から障害発生の申告後に受信するコマンドは、診断プログラム起動コマンドであり、それ以外のコマンドを受信するものではないため、診断プログラムを起動しない場合において、どのような処理を行うかという構成を想定しておらず、本願発明の構成Dのように、「前記データ・リクエストが前記装置に前記内部診断用ソフトウェアを実行することを要求していなければ、前記データ・リクエストの受信に応答して、前記装置から前記ヘッドエンド装置に第1の応答を送信する」という構成を含むものではない。 したがって、引用発明は、本願発明の構成Dのような構成を含むものではない。 (ア-5)構成Eについて 上記(ア-3)で検討したように、引用発明は、本願発明の構成Cのような判定する構成を含むものではないので、要求しているかどうかを判定した結果として生じる構成である、本願発明の構成Eの「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を有さないものである。 上記(ア-2)で検討したように、引用発明の「診断プログラム起動コマンド」は、本願発明の「データ・リクエスト」に相当する。 そして、引用発明の構成cの「診断プログラム起動コマンドを受信すると、」「診断プログラムの起動を行う」ことは、本願発明の構成Eの「前記データ・リクエストの受信に応答して、前記内部診断用ソフトウェアを実行する」ことに相当する。 したがって、引用発明の構成cと、本願発明の構成Eは、「前記データ・リクエストの受信に応答して、前記内部診断用ソフトウェアを実行するステップ」である点で共通する。 しかし、引用発明の構成cは、本願発明の構成Eのように、「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を有さないものである。 (ア-6)構成Fについて 上記(ア-5)と同様に、引用発明は、本願発明の構成Fの「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を有さないものである。 引用発明の構成dの「診断プログラム起動コマンドを受信すると、障害の原因解明に役立つ当該ユーザ側端末装置の関連情報を、ユーザ側端末装置から保守センタ側端末装置に送信する」とは、『診断プログラム起動コマンドに応答して、関連情報を含む応答をユーザ側端末装置から保守センタ側端末装置に送信する』ことである。 ここで、関連情報を含む応答について、第2の応答と定義すると、『診断プログラム起動コマンドに応答して、関連情報を含む応答をユーザ側端末装置から保守センタ側端末装置に送信する』は、本願発明の構成Fの「前記データ・リクエストに応答して第2の応答を前記装置から前記ヘッドエンド装置に送信する」に相当する。 引用発明の構成dの関連情報は、「ソフトウェアバージョン、自局テレックス番号、自局ISDN番号を含む」ものであり、「ソフトウェアバージョン」、「自局テレックス番号、自局ISDN番号」は、それぞれ、本願発明の構成Fの「ソフトウェア改訂」、「機器識別」に相当する。 また、これらの関連情報は、診断プログラムを起動させたユーザ側端末装置で、発生したデータであるから、本願発明の構成Fの「前記装置によって生成されたデータ」に相当する。 したがって、引用発明の構成dと本願発明の構成Fとは、「前記データ・リクエストに応答して第2の応答を前記装置から前記ヘッドエンド装置に送信するステップであって、前記第2の応答は、当該データ・リクエストの結果として前記装置によって生成されたデータを含み、当該データは、エラー・コード、機器識別、ソフトウェア改訂、ビットレート、およびビット・エラーレートのうちの少なくとも1つを含み、前記送信するステップ」である点で共通する。 しかし、引用発明の構成dは、本願発明の構成Fのように、「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を有さないものである。 また、引用発明のユーザ側端末装置は、どこにあるかについて記載されておらず、本願発明の構成Fのように、「前記装置は、利用者宅内にある」かどうか不明である。 (ア-7)構成Gについて 上記(ア-1)で検討したように、引用発明の「メンテナンス情報収集方法」は、本願発明の「遠隔診断の方法」に相当するので、引用発明の構成eは、本願発明の構成Gに相当する。 イ.一致点・相違点 したがって、引用発明と本願発明は、以下の点で一致ないし相違する。 [一致点] 「ヘッドエンド装置、および診断用のソフトウェアを有する装置を備えるディジタル加入者線ネットワークにおける遠隔診断の方法であって、 ユーザからのリクエストに応答して前記ヘッドエンド装置から前記装置にデータ・リクエストを送信するステップと、 前記データ・リクエストの受信に応答して、前記内部診断用ソフトウェアを実行するステップと、 前記データ・リクエストに応答して第2の応答を前記装置から前記ヘッドエンド装置に送信するステップであって、前記第2の応答は、当該データ・リクエストの結果として前記装置によって生成されたデータを含み、当該データは、エラー・コード、機器識別、ソフトウェア改訂、ビットレート、およびビット・エラーレートのうちの少なくとも1つを含み、前記送信するステップと、 を含む、前記遠隔診断の方法。 [相違点] 相違点1 本願発明は、「受信したデータ・リクエストが前記装置に対し、当該装置内に存在する内部診断用ソフトウェアを実行することを要求しているかどうかを判定するステップ」を含むのに対し、引用発明は、そのようなステップを含まない点。 相違点2 本願発明は、「前記データ・リクエストが前記装置に前記内部診断用ソフトウェアを実行することを要求していなければ、前記データ・リクエストの受信に応答して、前記装置から前記ヘッドエンド装置に第1の応答を送信するステップ」を含むのに対し、引用発明は、そのようなステップを含まない点。 相違点3 「前記データ・リクエストの受信に応答して、前記内部診断用ソフトウェアを実行するステップ」に関して、本願発明は、「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を有するのに対し、引用発明は、そのような前提を有さない点。 相違点4 「前記データ・リクエストに応答して第2の応答を前記装置から前記ヘッドエンド装置に送信するステップ」に関して、本願発明は、「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を有するのに対し、引用発明は、そのような前提を有さない点。 相違点5 「診断用のソフトウェアを有する装置」に関して、本願発明は、「利用者宅内にある」のに対し、引用発明は、どこにあるか不明である点。 5.当審の判断 上記相違点について検討する。 (1)相違点1?4について 相違点1?4は、本願発明の「データ・リクエスト」が、「内部診断用ソフトウェアを実行することを要求している」リクエストと、「内部診断用ソフトウェアを実行することを要求していない」リクエストを含む、すなわち、複数種類のリクエストを含むものであるのに対し、引用発明の「診断プログラム起動コマンド」は、本願発明の「内部診断用ソフトウェアを実行することを要求している」リクエストに相当するものの、引用発明では、「内部診断用ソフトウェアを実行することを要求していない」リクエストについて記載がない、すなわち、1種類のリクエストのみであることに起因して、 引用発明は、どちらのリクエストであるかを判定するための「受信したデータ・リクエストが前記装置に対し、当該装置内に存在する内部診断用ソフトウェアを実行することを要求しているかどうかを判定するステップ」を含んでいない。 そのため、引用発明は、「前記データ・リクエストが前記装置に前記内部診断用ソフトウェアを実行することを要求していなければ、前記データ・リクエストの受信に応答して、前記装置から前記ヘッドエンド装置に第1の応答を送信するステップ」を含んでおらず、また、 「前記データ・リクエストの受信に応答して、前記内部診断用ソフトウェアを実行するステップ」と「前記データ・リクエストに応答して第2の応答を前記装置から前記ヘッドエンド装置に送信するステップ」について、「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を有さないものである。 当審の拒絶理由にて引用された特開平5-216789号公報(以下、「引用例2」という。)に記載されている(段落0054?0062)ように、遠隔地の装置の異常状態を検出したとき、故障原因を調べるための診断プログラムを実行させたり、サービスマン用に必要な情報を転送させるプログラムを実行させたりすることは、良く知られている技術である。 引用発明のような、診断プログラムを含むユーザ側端末装置において、診断プログラム起動コマンドの受信により、診断プログラムを起動させて関連情報を送信するような構成に、上記引用例2に記載された技術を適用することにより、診断プログラムを起動させる診断プログラム起動コマンドだけでなく、その他のプログラム(例えば、サービスマン用に必要な情報を転送させるプログラム)を起動させるようなコマンド、すなわち、診断プログラムを起動させないようなコマンドを受信するようにすることは、当業者が容易に想到し得るものである。そして、そのように構成された場合には、本願発明のように、「データ・リクエスト」が、「内部診断用ソフトウェアを実行することを要求している」リクエストと、「内部診断用ソフトウェアを実行することを要求していない」リクエストを含むものとなる。 そして、引用例1においても、「ユーザ側端末装置から障害発生の申告後に受信する信号」、すなわち、受信したデータリクエストに対しての構成ではないが、上記ク.に記載されているように、「診断プログラム起動コマンドであるか、それ以外のデータであるか判断し、データであれば通常のデータ受信を行い、コマンドであれば、診断プログラムの起動を行う」構成、すなわち、異なる信号を受信するのであれば、受信した信号に応じて異なる処理を行う必要があるため、いずれの信号であるかを判定するステップや、判定結果に応じた制御を行うステップを設けることについての示唆があることから、引用発明が、本願発明のように、「データ・リクエスト」が、「内部診断用ソフトウェアを実行することを要求している」リクエストと、「内部診断用ソフトウェアを実行することを要求していない」リクエストを含むものであれば、「受信したデータ・リクエストが前記装置に対し、当該装置内に存在する内部診断用ソフトウェアを実行することを要求しているかどうかを判定するステップ」や、「前記データ・リクエストが前記装置に前記内部診断用ソフトウェアを実行することを要求していなければ、前記データ・リクエストの受信に応答して、前記装置から前記ヘッドエンド装置に第1の応答を送信するステップ」を含み、また、「前記データ・リクエストの受信に応答して、前記内部診断用ソフトウェアを実行するステップ」と「前記データ・リクエストに応答して第2の応答を前記装置から前記ヘッドエンド装置に送信するステップ」が、「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を含むようにすることは、当業者が適宜なし得るものである。 (2)相違点5について 引用発明における「診断プログラムを含むユーザ側端末装置」をどこに置くかは、ユーザが使用したい場所に応じて適宜決めれば良いことであり、ユーザの宅内に設置することは、普通に考えることにすぎず、本願発明のように、「前記装置は、利用者宅内にある」ようにすることは、当業者が容易に想到し得るものである。 よって、各相違点については、格別のものではなく、本願発明に関する作用・効果も、その容易想到である構成から当業者が予測できる範囲のものである。 したがって、本願発明は、引用発明及び引用例2に記載された技術に基づいて、当業者が容易に発明をすることができたものである。 6.むすび 以上のとおり、本願の請求項1に係る発明は、引用例1に記載された発明及び引用例2に記載された技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 したがって、本願は、その余の請求項について論及するまでもなく、拒絶すべきものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2016-12-14 |
| 結審通知日 | 2016-12-21 |
| 審決日 | 2017-01-05 |
| 出願番号 | 特願2012-111425(P2012-111425) |
| 審決分類 |
P
1
8・
121-
WZ
(H04N)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 佐野 潤一 |
| 特許庁審判長 |
藤井 浩 |
| 特許庁審判官 |
渡辺 努 冨田 高史 |
| 発明の名称 | 遠隔診断の方法および遠隔診断を実行するセットトップ・ボックス |
| 代理人 | 倉持 誠 |
| 代理人 | 吹田 礼子 |