【事件の表示】
　特願２０１２−１１１４２５「遠隔診断の方法および遠隔診断を実行するセットトップ・ボックス」拒絶査定不服審判事件〔平成２４年１１月　１日出願公開、特開２０１２−２１３１６８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、２００２年３月１５日（パリ条約による優先権主張外国庁受理２００１年３月２０日、米国）を国際出願日として出願した特願２００２−５７３４３８号の一部を平成２１年３月２６日に新たな特許出願とした特願２００９−７６００５号の一部を平成２４年５月１５日に新たな特許出願としたものであって、手続の経緯の概要は、以下のとおりである。
手続補正　　　　　　　平成２４年　９月２７日
拒絶理由通知　　　　　平成２５年　８月１３日（起案日）
手続補正　　　　　　　平成２６年　２月２１日
拒絶理由通知（最後）　平成２６年　４月２１日（起案日）
手続補正　　　　　　　平成２６年１０月２１日
補正の却下の決定　　　平成２７年　３月１７日（起案日）
拒絶査定　　　　　　　平成２７年　３月１７日（起案日）
拒絶査定不服審判請求　平成２７年　７月２３日
手続補正　　　　　　　平成２７年　７月２３日
拒絶理由通知（当審）　平成２８年　５月１７日（起案日）
手続補正　　　　　　　平成２８年１１月１５日
２．本願発明
　本願の請求項１ないし４に係る発明は、平成２８年１１月１５日付けで補正された特許請求の範囲の請求項１ないし４に記載されたとおりのものであり、そのうち、請求項１に係る発明（以下、「本願発明」という。）は、次のとおりである。
　なお、Ａ〜Ｇについては、説明のために当審にて付したものである。
（以下、「構成Ａ」、・・・、「構成Ｇ」という。）
「Ａ　ヘッドエンド装置、および診断用のソフトウェアを有する装置を備えるディジタル加入者線ネットワークにおける遠隔診断の方法であって、
　Ｂ　ユーザからのリクエストに応答して前記ヘッドエンド装置から前記装置にデータ・リクエストを送信するステップと、
　Ｃ　受信したデータ・リクエストが前記装置に対し、当該装置内に存在する内部診断用ソフトウェアを実行することを要求しているかどうかを判定するステップと、
　Ｄ　前記データ・リクエストが前記装置に前記内部診断用ソフトウェアを実行することを要求していなければ、前記データ・リクエストの受信に応答して、前記装置から前記ヘッドエンド装置に第１の応答を送信するステップと、
　Ｅ　前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、前記データ・リクエストの受信に応答して、前記内部診断用ソフトウェアを実行するステップと、
　Ｆ　前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、前記データ・リクエストに応答して第２の応答を前記装置から前記ヘッドエンド装置に送信するステップであって、前記第２の応答は、当該データ・リクエストの結果として前記装置によって生成されたデータを含み、当該データは、エラー・コード、機器識別、ソフトウェア改訂、ビットレート、およびビット・エラーレートのうちの少なくとも１つを含み、前記装置は、利用者宅内にある、前記送信するステップと、
　Ｇ　を含む、前記遠隔診断の方法。」
３．引用発明
　当審の拒絶理由通知に引用された、特開平７−２０３０２８号公報（以下、「引用例１」という。）には、「メンテナンス情報収集方式と、該方式を構成する保守センタ側端末装置及びユーザ側端末装置」として、図面とともに以下の事項が記載されている。
　なお、下線は、当審にて付したものである。
ア．「【０００１】
【産業上の利用分野】本発明は、メンテナンス情報収集方式と、該方式を構成する保守センタ側端末装置及びユーザ側端末装置に関するもであり、更に詳しくは、
通信網に接続されたユーザ側端末装置から保守センタ側に障害発生の申告がなされたとき、保守センタ側端末装置から通信網を介して前記ユーザ側端末装置にアクセスして、障害発生の原因解明に必要なユーザ側端末装置関連情報をメンテナンス情報として保守センタ側に収集するメンテナンス情報収集方式
イ．「【０００７】そこで本発明では、かかる問題点を解決し、ユーザ側からユーザ側データ送受信端末装置について不具合が保守センタ側に申告されたとき、その不具合の原因解明に役立つ端末装置関連情報を、メンテナンス情報（正確にはメンテナンスに役立つ情報）として、正確かつ大量に、ごそっと保守センタ側に取り込むことができて、
適切な対応が可能になるメンテナンス情報収集方式
【０００８】
【課題を解決するための手段】上記目的達成のため、本発明では、
通信網に接続されたユーザ側端末装置から保守センタ側に障害発生の申告がなされたとき、保守センタ側端末装置から通信網を介して前記ユーザ側端末装置にアクセスして、障害発生の原因解明に必要なユーザ側端末装置関連情報をメンテナンス情報として保守センタ側に収集するメンテナンス情報収集方式において、ユーザ側端末装置には、当該装置の関連情報をメンテナンス情報として送信するためのプログラムを診断プログラムとして、そのアプリケーションプログラムの中に含ませ
【０００９】
【作用】
保守センタ側端末装置では、ユーザ側端末装置から障害発生の申告がなされたとき、通信網を介して当該ユーザ側端末装置に向け、コマンド送出手段から診断プログラム起動コマンドを送出する。そしてその保守センタ側端末装置から送信された診断プログラム起動コマンドが、ユーザ側端末装置に受信されると、ユーザ側端末装置のアプリケーションプログラムに含まれている診断プログラムが起動して、当該ユーザ側端末装置の、障害発生の原因解明に役立つ関連情報をメンテナンス情報として、通信網を介して保守センタ側端末装置に送出する。
障害発生の原因解明に供する。
ウ．「【００１１】
【実施例】次に図を参照して本発明の実施例を説明する。図１は、本発明の一実施例としてのメンテナンス情報収集方式を示す構成図である。同図において、１はユーザ設置端末（データ送受信端末として例えば、パケット形態端末を想定しており、パソコンで構成される）、２は
ＩＳＤＮ網
エ．「【００１３】図１、図２を参照する。ユーザ設置端末１は、データ通信端末として、通常はＩＳＤＮ網２を介して図示せざる他のデータ通信端末との間で、データの送受信を行っている。その
ユーザ設置端末１に何らかの障害が起きると、ユーザは電話連絡などにより保守センタ側に、その旨の申告を行う。
保守センタ側では、保守センタ側設置端末３を使い、ＩＳＤＮ網２を介して、障害の起きたユーザ設置端末１にアクセスして、メンテナンス情報をそのユーザ設置端末１から収集しようとする。
オ．「【００１５】こうして呼が設定されると、保守センタ側設置端末３からコマンド送信が開始される。即ち、
保守センタ側設置端末３は、診断プログラム起動コマンドを
ＩＳＤＮ網２を介してユーザ設置端末１に送信する。
ユーザ設置端末１では、そのアプリケーションプログラム中に予め含ませておいた診断プログラム（ユーザ設置端末１の障害時、その原因解明つまり診断に必要な、当該端末の関連情報を、メンテナンス情報として送信するためのプログラム）を起動する。
【００１６】その結果、
障害の原因解明に役立つ当該端末の関連情報
カ．「【００１８】上述の通信ボード情報、アプリケーションプログラムに関するソフトウエア情報、及び通信設定環境に関する情報の具体例を次に説明する。通信ボードというのは、ユーザ設置端末としてのパソコンをＩＳＤＮ網に接続する際に用いられる装置であるが、この通信ボード情報としては、適合認定・形式指定番号、ＩＢＩＯＳ．ＥＸＥ実行時の情報、日付などがある。
【００１９】アプリケーションプログラムに関するソフトウエア情報としては、
ソフトウエアバージョン
自局テレックス番号
自局ＩＳＤＮ番号
キ．「【００２１】図３は、ユーザ設置端末１としてのパソコンに搭載されるプログラム構成例を示した説明図である。即ち、パソコンには、ＯＳ（オペレーションシステム）とＡＰ（アプリケーションプログラム）とＡＰＩライブラリ（ツール）が搭載されるが、本発明では、その中のＡＰ（アプリケーションプログラム）に、特に
診断機能として前述の診断プログラム（障害時、その原因解明つまり診断に必要な、当該パソコンの関連情報を、メンテナンス情報として送信するためのプログラム）を、他の諸々の諸機能と共に、含ませている
ク．「【００２５】図６は、図１においてユーザ設置端末１が、本発明を実行する際に行う動作のフローを示すチャートである。先ず、保守センタ側端末３から受信する直前の画面（着信前画面）状態において、着呼を検出し、次に受信したものが診断プログラム起動コマンドであるか、それ以外のデータであるか判断し、データであれば通常のデータ受信を行い、コマンドであれば、診断プログラムの起動を行い、その結果として関連情報をリモートメンテナンスデータとして保守センタ側端末３に向け送信する。」
　このような事項を踏まえ、上記ア．〜ク．の記載及び関連する図面並びにこの分野における技術常識を考慮すると、
（ａ）引用例１には、上記ア．、イ．に記載があるように、通信網に接続されたユーザ側端末装置から障害発生の申告がなされたとき、保守センタ側端末装置から通信網を介して前記ユーザ側端末装置にアクセスして、障害発生の原因解明に必要なユーザ側端末装置関連情報をメンテナンス情報として保守センタ側に収集するメンテナンス情報収集方式において、ユーザ側端末装置に、当該装置の関連情報をメンテナンス情報として送信するためのプログラムを診断プログラムとして含ませることにより、適切な対応が可能になるメンテナンス情報収集方式についての記載がある。
（ｂ）上記イ．、ウ．、キ．の記載から、引用例１のメンテナンス情報収集方式は、保守センタ側端末装置、および診断プログラムを含むユーザ側端末装置を備えるＩＳＤＮ網を介したメンテナンス情報収集方式である。
（ｃ）上記イ．、エ．、オ．の記載から、引用例１のメンテナンス情報収集方式は、ユーザ側端末装置から障害発生の申告がなされると、保守センタ側端末装置からユーザ側端末装置に診断プログラム起動コマンドを発信する段階を含むものである。
（ｄ）上記イ．、オ．の記載から、引用例１のメンテナンス情報収集方式は、ユーザ側端末装置が診断プログラム起動コマンドを受信すると、ユーザ側端末装置に含まれている診断プログラムの起動を行う段階を含むものである。
（ｅ）上記イ．、オ．、カ．の記載から、引用例１のメンテナンス情報収集方式は、ユーザ側端末装置が診断プログラム起動コマンドを受信すると、障害の原因解明に役立つ当該ユーザ側端末装置の関連情報を、ユーザ側端末装置から保守センタ側端末装置に送信する段階を含むものであり、関連情報は、ソフトウェアバージョン、自局テレックス番号、自局ＩＳＤＮ番号を含むものである。
　そして、引用例１のメンテナンス情報収集方式は、上記（ｃ）〜（ｅ）のような段階を含むものであるから、以下のようなメンテナンス情報収集方法の発明（以下、「引用発明」という。）が開示されているものといえる。
　なお、ａ〜ｅについては、説明のために当審にて付したものである。（以下、「構成ａ」、・・・、「構成ｅ」という。）
［引用発明］
「ａ　保守センタ側端末装置、および診断プログラムを含むユーザ側端末装置を備えるＩＳＤＮ網を介したメンテナンス情報収集方法であって、
　ｂ　ユーザ側端末装置から障害発生の申告がなされると、保守センタ側端末装置からユーザ側端末装置に診断プログラム起動コマンドを発信する段階と、
　ｃ　ユーザ側端末装置が診断プログラム起動コマンドを受信すると、ユーザ側端末装置に含まれている診断プログラムの起動を行う段階と、
　ｄ　ユーザ側端末装置が診断プログラム起動コマンドを受信すると、障害の原因解明に役立つ当該ユーザ側端末装置の関連情報を、ユーザ側端末装置から保守センタ側端末装置に送信する段階であって、関連情報は、ソフトウェアバージョン、自局テレックス番号、自局ＩＳＤＮ番号を含む段階と、
　ｅ　を含む、前記メンテナンス情報収集方法。」
４．本願発明と引用発明との対比と、一致点・相違点の認定
ア．対比
（ア−１）構成Ａについて
　引用発明の構成ａの「メンテナンス情報収集方法」は、構成ｂ〜ｄを考慮するに、ユーザ側端末装置の障害発生時に診断プログラムを起動し、ＩＳＤＮ網を介した保守センタ側端末装置にて、障害の原因解明に役立つ当該ユーザ側端末装置の関連情報を収集するものである。
　ここで、保守センタ側端末装置は、ＩＳＤＮ網を介していることから、遠隔地にあり、関連情報を収集することによりユーザ側端末装置の状態を遠隔地で診断するものといえるから、引用発明の構成ａの「メンテナンス情報収集方法」は、本願発明の構成Ａの「遠隔診断の方法」に相当する。
　また、引用発明の構成ａの「保守センタ側端末装置」、「ユーザ側端末装置」は、本願発明の構成Ａの「ヘッドエンド装置」、「装置」に相当し、構成ａの「診断プログラム」は、構成Ａの「診断用のソフトウェア」に相当する。
　さらに、引用発明の構成ａの「ＩＳＤＮ網」は、デジタルのネットワークであるから、本願発明の構成Ａの「ディジタル加入者線ネットワーク」に相当する。
　したがって、引用発明の構成ａは、本願発明の構成Ａに相当する。
（ア−２）構成Ｂについて
　引用発明の構成ｂの「ユーザ側端末装置から障害発生の申告」をすることは、保守センタ側端末装置が関連情報を収集し、障害に対する適切な対応を行うために申告をするのであるから、ユーザが保守センタ側端末装置に障害に対する対応を依頼するために送信しているといえるので、本願発明の構成Ｂの「ユーザからのリクエスト」に相当する。
　引用発明の構成ｂの「診断プログラム起動コマンド」は、ユーザ側端末装置に対して、診断プログラムの起動を行わせ、関連情報を送信させるための信号であり、関連情報というデータを要求する信号であるから、本願発明の構成Ｂの「データ・リクエスト」に相当する。
　また、引用発明の構成ｂは、「障害発生の申告がなされると、」「診断プログラム起動コマンドを発信する」ものであり、申告に応答して、診断プログラム起動コマンドを送信するものである。
　したがって、引用発明の構成ｂは本願発明の構成Ｂに相当する。
（ア−３）構成Ｃについて
　引用発明は、構成ｃのように、診断プログラム起動コマンドを受信すると、診断プログラムの起動を行うものであり、受信してから起動を行う間に、受信したコマンドが、診断プログラムを起動することを要求しているかどうかを判定する構成を含んでいない。
　したがって、引用発明は、本願発明の構成Ｃのような構成を含むものではない。
（ア−４）構成Ｄについて
　上記（ア−３）で検討したように、引用発明は、本願発明の構成Ｃのような判定する構成を含むものではないので、要求しているかどうかを判定した結果として生じる構成である、本願発明の構成Ｄの「前記データ・リクエストが前記装置に前記内部診断用ソフトウェアを実行することを要求していなければ、」という前提を有さないものである。
　さらに、引用発明が、ユーザ側端末装置から障害発生の申告後に受信するコマンドは、診断プログラム起動コマンドであり、それ以外のコマンドを受信するものではないため、診断プログラムを起動しない場合において、どのような処理を行うかという構成を想定しておらず、本願発明の構成Ｄのように、「前記データ・リクエストが前記装置に前記内部診断用ソフトウェアを実行することを要求していなければ、前記データ・リクエストの受信に応答して、前記装置から前記ヘッドエンド装置に第１の応答を送信する」という構成を含むものではない。
　
　したがって、引用発明は、本願発明の構成Ｄのような構成を含むものではない。
（ア−５）構成Ｅについて
　上記（ア−３）で検討したように、引用発明は、本願発明の構成Ｃのような判定する構成を含むものではないので、要求しているかどうかを判定した結果として生じる構成である、本願発明の構成Ｅの「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を有さないものである。
　上記（ア−２）で検討したように、引用発明の「診断プログラム起動コマンド」は、本願発明の「データ・リクエスト」に相当する。
　そして、引用発明の構成ｃの「診断プログラム起動コマンドを受信すると、」「診断プログラムの起動を行う」ことは、本願発明の構成Ｅの「前記データ・リクエストの受信に応答して、前記内部診断用ソフトウェアを実行する」ことに相当する。
　したがって、引用発明の構成ｃと、本願発明の構成Ｅは、「前記データ・リクエストの受信に応答して、前記内部診断用ソフトウェアを実行するステップ」である点で共通する。
　しかし、引用発明の構成ｃは、本願発明の構成Ｅのように、「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を有さないものである。
（ア−６）構成Ｆについて
　上記（ア−５）と同様に、引用発明は、本願発明の構成Ｆの「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を有さないものである。
　引用発明の構成ｄの「診断プログラム起動コマンドを受信すると、障害の原因解明に役立つ当該ユーザ側端末装置の関連情報を、ユーザ側端末装置から保守センタ側端末装置に送信する」とは、『診断プログラム起動コマンドに応答して、関連情報を含む応答をユーザ側端末装置から保守センタ側端末装置に送信する』ことである。
　ここで、関連情報を含む応答について、第２の応答と定義すると、『診断プログラム起動コマンドに応答して、関連情報を含む応答をユーザ側端末装置から保守センタ側端末装置に送信する』は、本願発明の構成Ｆの「前記データ・リクエストに応答して第２の応答を前記装置から前記ヘッドエンド装置に送信する」に相当する。
　引用発明の構成ｄの関連情報は、「ソフトウェアバージョン、自局テレックス番号、自局ＩＳＤＮ番号を含む」ものであり、「ソフトウェアバージョン」、「自局テレックス番号、自局ＩＳＤＮ番号」は、それぞれ、本願発明の構成Ｆの「ソフトウェア改訂」、「機器識別」に相当する。
　また、これらの関連情報は、診断プログラムを起動させたユーザ側端末装置で、発生したデータであるから、本願発明の構成Ｆの「前記装置によって生成されたデータ」に相当する。
　
　したがって、引用発明の構成ｄと本願発明の構成Ｆとは、「前記データ・リクエストに応答して第２の応答を前記装置から前記ヘッドエンド装置に送信するステップであって、前記第２の応答は、当該データ・リクエストの結果として前記装置によって生成されたデータを含み、当該データは、エラー・コード、機器識別、ソフトウェア改訂、ビットレート、およびビット・エラーレートのうちの少なくとも１つを含み、前記送信するステップ」である点で共通する。
　しかし、引用発明の構成ｄは、本願発明の構成Ｆのように、「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を有さないものである。
　また、引用発明のユーザ側端末装置は、どこにあるかについて記載されておらず、本願発明の構成Ｆのように、「前記装置は、利用者宅内にある」かどうか不明である。
（ア−７）構成Ｇについて
　上記（ア−１）で検討したように、引用発明の「メンテナンス情報収集方法」は、本願発明の「遠隔診断の方法」に相当するので、引用発明の構成ｅは、本願発明の構成Ｇに相当する。
イ．一致点・相違点
　したがって、引用発明と本願発明は、以下の点で一致ないし相違する。
［一致点］
「ヘッドエンド装置、および診断用のソフトウェアを有する装置を備えるディジタル加入者線ネットワークにおける遠隔診断の方法であって、
　ユーザからのリクエストに応答して前記ヘッドエンド装置から前記装置にデータ・リクエストを送信するステップと、
　前記データ・リクエストの受信に応答して、前記内部診断用ソフトウェアを実行するステップと、
　前記データ・リクエストに応答して第２の応答を前記装置から前記ヘッドエンド装置に送信するステップであって、前記第２の応答は、当該データ・リクエストの結果として前記装置によって生成されたデータを含み、当該データは、エラー・コード、機器識別、ソフトウェア改訂、ビットレート、およびビット・エラーレートのうちの少なくとも１つを含み、前記送信するステップと、
　を含む、前記遠隔診断の方法。
［相違点］
　相違点１
　本願発明は、「受信したデータ・リクエストが前記装置に対し、当該装置内に存在する内部診断用ソフトウェアを実行することを要求しているかどうかを判定するステップ」を含むのに対し、引用発明は、そのようなステップを含まない点。
　相違点２
　本願発明は、「前記データ・リクエストが前記装置に前記内部診断用ソフトウェアを実行することを要求していなければ、前記データ・リクエストの受信に応答して、前記装置から前記ヘッドエンド装置に第１の応答を送信するステップ」を含むのに対し、引用発明は、そのようなステップを含まない点。
　相違点３
　「前記データ・リクエストの受信に応答して、前記内部診断用ソフトウェアを実行するステップ」に関して、本願発明は、「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を有するのに対し、引用発明は、そのような前提を有さない点。
　相違点４
　「前記データ・リクエストに応答して第２の応答を前記装置から前記ヘッドエンド装置に送信するステップ」に関して、本願発明は、「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を有するのに対し、引用発明は、そのような前提を有さない点。
　
　相違点５
　「診断用のソフトウェアを有する装置」に関して、本願発明は、「利用者宅内にある」のに対し、引用発明は、どこにあるか不明である点。
５．当審の判断
　上記相違点について検討する。
（１）相違点１〜４について
　相違点１〜４は、本願発明の「データ・リクエスト」が、「内部診断用ソフトウェアを実行することを要求している」リクエストと、「内部診断用ソフトウェアを実行することを要求していない」リクエストを含む、すなわち、複数種類のリクエストを含むものであるのに対し、引用発明の「診断プログラム起動コマンド」は、本願発明の「内部診断用ソフトウェアを実行することを要求している」リクエストに相当するものの、引用発明では、「内部診断用ソフトウェアを実行することを要求していない」リクエストについて記載がない、すなわち、１種類のリクエストのみであることに起因して、
　引用発明は、どちらのリクエストであるかを判定するための「受信したデータ・リクエストが前記装置に対し、当該装置内に存在する内部診断用ソフトウェアを実行することを要求しているかどうかを判定するステップ」を含んでいない。
　そのため、引用発明は、「前記データ・リクエストが前記装置に前記内部診断用ソフトウェアを実行することを要求していなければ、前記データ・リクエストの受信に応答して、前記装置から前記ヘッドエンド装置に第１の応答を送信するステップ」を含んでおらず、また、
　「前記データ・リクエストの受信に応答して、前記内部診断用ソフトウェアを実行するステップ」と「前記データ・リクエストに応答して第２の応答を前記装置から前記ヘッドエンド装置に送信するステップ」について、「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を有さないものである。
　当審の拒絶理由にて引用された特開平５−２１６７８９号公報（以下、「引用例２」という。）に記載されている（段落００５４〜００６２）ように、遠隔地の装置の異常状態を検出したとき、故障原因を調べるための診断プログラムを実行させたり、サービスマン用に必要な情報を転送させるプログラムを実行させたりすることは、良く知られている技術である。
　
　引用発明のような、診断プログラムを含むユーザ側端末装置において、診断プログラム起動コマンドの受信により、診断プログラムを起動させて関連情報を送信するような構成に、上記引用例２に記載された技術を適用することにより、診断プログラムを起動させる診断プログラム起動コマンドだけでなく、その他のプログラム（例えば、サービスマン用に必要な情報を転送させるプログラム）を起動させるようなコマンド、すなわち、診断プログラムを起動させないようなコマンドを受信するようにすることは、当業者が容易に想到し得るものである。そして、そのように構成された場合には、本願発明のように、「データ・リクエスト」が、「内部診断用ソフトウェアを実行することを要求している」リクエストと、「内部診断用ソフトウェアを実行することを要求していない」リクエストを含むものとなる。
　そして、引用例１においても、「ユーザ側端末装置から障害発生の申告後に受信する信号」、すなわち、受信したデータリクエストに対しての構成ではないが、上記ク．に記載されているように、「診断プログラム起動コマンドであるか、それ以外のデータであるか判断し、データであれば通常のデータ受信を行い、コマンドであれば、診断プログラムの起動を行う」構成、すなわち、異なる信号を受信するのであれば、受信した信号に応じて異なる処理を行う必要があるため、いずれの信号であるかを判定するステップや、判定結果に応じた制御を行うステップを設けることについての示唆があることから、引用発明が、本願発明のように、「データ・リクエスト」が、「内部診断用ソフトウェアを実行することを要求している」リクエストと、「内部診断用ソフトウェアを実行することを要求していない」リクエストを含むものであれば、「受信したデータ・リクエストが前記装置に対し、当該装置内に存在する内部診断用ソフトウェアを実行することを要求しているかどうかを判定するステップ」や、「前記データ・リクエストが前記装置に前記内部診断用ソフトウェアを実行することを要求していなければ、前記データ・リクエストの受信に応答して、前記装置から前記ヘッドエンド装置に第１の応答を送信するステップ」を含み、また、「前記データ・リクエストの受信に応答して、前記内部診断用ソフトウェアを実行するステップ」と「前記データ・リクエストに応答して第２の応答を前記装置から前記ヘッドエンド装置に送信するステップ」が、「前記データ・リクエストが前記装置に内部診断用ソフトウェアを実行することを要求していれば、」という前提を含むようにすることは、当業者が適宜なし得るものである。
（２）相違点５について
　引用発明における「診断プログラムを含むユーザ側端末装置」をどこに置くかは、ユーザが使用したい場所に応じて適宜決めれば良いことであり、ユーザの宅内に設置することは、普通に考えることにすぎず、本願発明のように、「前記装置は、利用者宅内にある」ようにすることは、当業者が容易に想到し得るものである。
　よって、各相違点については、格別のものではなく、本願発明に関する作用・効果も、その容易想到である構成から当業者が予測できる範囲のものである。
　したがって、本願発明は、引用発明及び引用例２に記載された技術に基づいて、当業者が容易に発明をすることができたものである。
６．むすび
　以上のとおり、本願の請求項１に係る発明は、引用例１に記載された発明及び引用例２に記載された技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、その余の請求項について論及するまでもなく、拒絶すべきものである。
　よって、結論のとおり審決する。