【事件の表示】
　特願２０１０−１６８８１６「管理サーバ、情報処理装置、方法およびプログラム」拒絶査定不服審判事件〔平成２４年　２月　９日出願公開、特開２０１２−　２７８６９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
第１　手続の経緯
　
　本件審判請求に係る出願（以下，「本願」という。）は，平成２２年７月２８日の出願であって，その手続の経緯は以下のとおりである。
　
　　平成２４年１２月１４日　　　：出願審査請求書の提出
　　平成２６年　２月１７日付け　：拒絶理由の通知
　　平成２６年　４月２８日　　　：意見書，手続補正書の提出
　　平成２６年１０月２８日付け　：拒絶査定　
　　平成２７年　２月　３日　　　：審判請求書，手続補正書の提出
　　平成２７年　２月２６日　　　：前置報告　
　　平成２７年　７月　８日　　　：上申書の提出
　　平成２７年１０月２８日付け　：拒絶理由の通知（当審）
　　平成２７年１２月２１日　　　：意見書，手続補正書の提出
　
　
第２　本願発明
　
　本願の請求項に係る発明は，上記平成２７年１２月２１日付け手続補正書により補正された特許請求の範囲の請求項１乃至１７に記載されたとおりのものであると認められるところ，その請求項１に係る発明（以下，「本願発明」という。）は，以下のとおりのものである。
　
「　管理対象装置に対する指示を蓄積する指示蓄積手段と，
　前記管理対象装置からの接続を受け入れる接続受入手段と，
　前記管理対象装置に対する複数の指示の内容に基づいて，該管理対象装置における指示の実行結果に応じて指示を変更する指示シナリオを生成する指示シナリオ生成手段と，
　前記指示シナリオに従って，前記指示蓄積手段によって蓄積された指示を，前記接続を介して送信することで，該指示を前記管理対象装置に取得させる指示送信手段と，
　前記管理対象装置における前記指示の実行結果通知を受信する実行結果通知受信手段と，
　を備え，
　前記指示送信手段は，前記指示シナリオに含まれる指示のうち，前記実行結果通知受信手段によって受信された前記実行結果に応じて変更された指示を，前記管理対象装置に送信する，
　管理サーバ。」
　
第３　引用例
　
１　引用例１に記載されている技術的事項および引用発明
　
（１）本願の出願前に頒布又は電気通信回線を通じて公衆に利用可能となり，当審からの上記平成２７年１０月２８日付けの拒絶理由通知において引用された，特開２００７−３３４６１２号公報（平成１９年１２月２７日出願公開，以下，「引用例１」という。）には，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ａ　「【００２１】
　（本実施形態の通信シーケンスの概略）
　
図２は，本実施形態に係る被管理装置102と管理サーバ106と管理者間の通信シーケンス例の一部を表した図である。
【００２２】
　
シーケンスS401/S402は，管理者が管理サーバ106を介して，被管理装置102に対して指示するコマンドの入力を表している。
【００２３】
　
シーケンスS403で，管理サーバ106は管理者からリクエストされたコマンドに対応する。管理サーバ106は，ログイン時の管理者IDから，オペレーションしている管理者が対象としている被管理装置102（被管理装置ID）へのコマンド発行権限があるかを，データベースのアクセスコントロールをベースにして判定する。
シーケンスS404では，管理サーバ106はS403の判定に従って，S401とS402の管理者からのリクエストを正規のリクエストとして，管理サーバ106のデータベース内に保管する。
【００２４】
　
シーケンスS405は，対象の被管理装置102から管理サーバ106へのコマンドリクエストを表している。このシーケンスS405における被管理装置102によるコマンドリクエスト送信際して，被管理装置102主体で通信セッションが張られる。また，被管理装置102主体の管理サーバ106へのアクセスによる通信セッションの確立により，管理サーバ106は被管理装置102側のファイアウォールを越えて被管理装置102に対して各種指示を行える。
S405で受信したデータはコマンドリクエスト(getOperationList)なので，管理サーバ106は，対象の被管理装置102に対して管理者からコマンドが指示されていないかデータベース内を検索する。シーケンスS407にて，管理サーバ106は対象の被管理装置102に対するコマンドをデータベースから取得する。
【００２５】
　
シーケンスS408で，管理サーバ106は，S405のコマンドリクエスト（getOperationList）のReplyとして，被管理装置102へコマンドを送信する。
シーケンスS410で，被管理装置102は管理サーバ106から受信したコマンドを実行する。
　
Ｂ　「【００２６】
　
シーケンスS411は，S410で実行したコマンドの結果（被管理装置102の保持する設定情報）を被管理装置102から管理サーバ106へ送信することを表している。
【００２７】
　この場合，管理サーバ106は，シーケンスS413にて，被管理装置102にコマンドリクエスト(getOperationList)を行うように指示を発行する。シーケンスS414にて，管理サーバ106から被管理装置102に，前回のコマンドが受信成功したと伝えるとともに，コマンドリクエスト(getOperationList)を次に行うよう指示をする。このときのReplyの例が図５の通信サンプル2に相当する。シーケンスS415で，被管理装置102はS414のリクエストより，管理サーバ106に対してコマンドリクエスト(getOperationList)を送信する。
　…（中略）…
　【００３２】
　
また，上の図２のシーケンスでは，管理サーバが被管理装置にコマンドを指示した後には，必ず，被管理装置はコマンドの実行結果を管理サーバに通知する処理を行う。このコマンド実行結果を受けた管理サーバは，さらに実行させたいコマンドがある場合に，このコマンド実行結果のＲｅｐｌｙに，次のコマンドが用意されている事を表す情報を出力する事で，被管理装置に，再度コマンドリクエスト通信を行うよう指示する事ができる。
管理サーバが発行したコマンド処理の結果を１コマンドに対して，１回ずつ受信するので確認が容易である。また，1回のコマンドの結果を受信・確認してから，次の送信すべきコマンドを決定する事ができるので，コマンドの柔軟性が高くなる。また，順次コマンドを実行させ結果複数の一連のコマンドを実行させる方式によれば，
　
Ｃ　「【００６９】
　（動作例１の動作手順例）
　図９は，管理サーバが，管理者のリクエストを受け，被管理装置にコマンドを送信する処理を表すフローチャートである。このフローチャートで表す動作例は，管理者から複数のリクエストを受けたときに，複数のコマンドがすべて処理されるように，管理サーバが被管理装置へリクエストすることを特徴とする。すなわち，管理サーバがリクエストを被管理装置へ送信する際に，複数のコマンドの１つ１つのコマンドの結果を確認できるように，コマンドの数だけ被管理装置のコマンドリクエストを被管理装置へ送信する。
　…（中略）…
【００７２】
　被管理装置への設定変更のコマンドがあれば，ステップS508で，カウンタCNTをリセットしてCNT = 1をセットする。ステップS510にて，カウンタCNTの値が，コマンドの数Ｎ未満だった場合に，ステップS511で，被管理装置に対して，CNT番目のコマンドを送信する。
ステップS512にて，ステップS511で被管理装置に送信したCNT番目のコマンドの結果を受信する。そして，ステップS519で，管理サーバ106は，S512で受信した実行結果から，次のコマンド送信を行うための準備を行うか，その他の処理を行うかを決定する。ここでは，コマンド結果が成功していた場合に，次のコマンド送信を準備するためにステップS513へ進む。また，被管理装置へ送信した前回コマンドが失敗していた場合には，再度，同じコマンドを送信するようにステップS511へ進む。このS519の判定処理により，より確実に被管理装置に対して一連のコマンドを指示することができる。
　
　
（２）ここで，引用例１に記載されている事項を検討する。　
　
ア　上記Ａの「図２は，本実施形態に係る被管理装置102と管理サーバ106と管理者間の通信シーケンス例の一部を表した図である。」，「シーケンスS401/S402は，管理者が管理サーバ106を介して，被管理装置102に対して指示するコマンドの入力を表している。」，「シーケンスS403で，管理サーバ106は管理者からリクエストされたコマンドに対応する。管理サーバ106は，ログイン時の管理者IDから，オペレーションしている管理者が対象としている被管理装置102（被管理装置ID）へのコマンド発行権限があるかを，データベースのアクセスコントロールをベースにして判定する。　…（中略）…　シーケンスS404では，管理サーバ106はS403の判定に従って，S401とS402の管理者からのリクエストを正規のリクエストとして，管理サーバ106のデータベース内に保管する。」との記載からすると，管理者から被管理装置へのリクエストは複数種類のコマンドからなり，管理サーバが自装置のデータベースに当該リクエストを保管することが読み取れるから，引用例１には，
“管理者から被管理装置への複数種類のコマンドからなるリクエストをデータベース内に保管”する“管理サーバ”
が記載されていると解される。
　
イ　上記Ａの「シーケンスS405は，対象の被管理装置102から管理サーバ106へのコマンドリクエストを表している。このシーケンスS405における被管理装置102によるコマンドリクエスト送信際して，被管理装置102主体で通信セッションが張られる。また，被管理装置102主体の管理サーバ106へのアクセスによる通信セッションの確立により，管理サーバ106は被管理装置102側のファイアウォールを越えて被管理装置102に対して各種指示を行える。」との記載からすると，被管理装置が管理サーバへコマンドリクエストを送信するためにアクセスし，管理サーバが被管理装置との間で通信セッションを確立することが読み取れるから，引用例１には，
“被管理装置からのアクセスにより通信セッションを確立し，前記被管理装置からコマンドリクエストを受信”する“管理サーバ”
が記載されていると解される。
　
ウ　上記Ａの「S405で受信したデータはコマンドリクエスト(getOperationList)なので，管理サーバ106は，対象の被管理装置102に対して管理者からコマンドが指示されていないかデータベース内を検索する。シーケンスS407にて，管理サーバ106は対象の被管理装置102に対するコマンドをデータベースから取得する。」，「シーケンスS408で，管理サーバ106は，S405のコマンドリクエスト（getOperationList）のReplyとして，被管理装置102へコマンドを送信する。」との記載からすると，管理サーバは被管理装置から受信したコマンドリクエストに対応するコマンドをデータベースから検索し，データベースから取得した当該コマンドリクエストに対応するコマンドを被管理装置へ送信することが読み取れるから，引用例１には，
“被管理装置からのコマンドリクエストに対応するコマンドをデータベースから取得し，取得したコマンドを前記被管理装置へ送信”する“管理サーバ”
が記載されていると解される。
　
エ　上記Ａの「シーケンスS410で，被管理装置102は管理サーバ106から受信したコマンドを実行する。」との記載，上記Ｂの「シーケンスS411は，S410で実行したコマンドの結果（被管理装置102の保持する設定情報）を被管理装置102から管理サーバ106へ送信することを表している。」，「また，上の図２のシーケンスでは，管理サーバが被管理装置にコマンドを指示した後には，必ず，被管理装置はコマンドの実行結果を管理サーバに通知する処理を行う。」との記載からすると，被管理装置は管理サーバから受信した，コマンドリクエストに対応するコマンドを実行し，管理サーバは，被管理装置がコマンドを実行した結果を受信することが読み取れるから，引用例１には，
“被管理装置が実行したコマンドの実行結果を受信”する“管理サーバ”
が記載されていると解される。
　
オ　上記Ｂの「このコマンド実行結果を受けた管理サーバは，さらに実行させたいコマンドがある場合に，このコマンド実行結果のＲｅｐｌｙに，次のコマンドが用意されている事を表す情報を出力する事で，被管理装置に，再度コマンドリクエスト通信を行うよう指示する事ができる。　…（中略）…　管理サーバが発行したコマンド処理の結果を１コマンドに対して，１回ずつ受信するので確認が容易である。また，1回のコマンドの結果を受信・確認してから，次の送信すべきコマンドを決定する事ができるので，コマンドの柔軟性が高くなる。」との記載，上記Ｃの「ステップS512にて，ステップS511で被管理装置に送信したCNT番目のコマンドの結果を受信する。そして，ステップS519で，管理サーバ106は，S512で受信した実行結果から，次のコマンド送信を行うための準備を行うか，その他の処理を行うかを決定する。ここでは，コマンド結果が成功していた場合に，次のコマンド送信を準備するためにステップS513へ進む。また，被管理装置へ送信した前回コマンドが失敗していた場合には，再度，同じコマンドを送信するようにステップS511へ進む。このS519の判定処理により，より確実に被管理装置に対して一連のコマンドを指示することができる。」との記載からすると，管理サーバは，被管理装置でのコマンドの実行結果に応じて，例えば，次のコマンドの送信を行うための準備を行うか，同じコマンドを送信するかを決定するように，次のコマンドを変更する決定を順次行うことが読み取れるから，引用例１には，
“被管理装置でのコマンドの実行結果に応じて次のコマンドを変更する決定を順次行う”“管理サーバ”
が記載されていると解される。
　
（３）以上，ア乃至オの検討によれば，引用例１には次の発明（以下，「引用発明」という。）が記載されているものと認める。
　
「　管理者から被管理装置への複数種類のコマンドからなるリクエストをデータベース内に保管し，
　前記被管理装置からのアクセスにより通信セッションを確立し，
　前記被管理装置からコマンドリクエストを受信し，
　前記被管理装置からの前記コマンドリクエストに対応するコマンドを前記データベースから取得し，取得したコマンドを前記被管理装置へ送信し，
　前記被管理装置が実行した前記コマンドの実行結果を受信し，
　前記被管理装置での前記コマンドの実行結果に応じて次のコマンドを変更する決定を順次行う
ことを特徴とする管理サーバ。」　
　
　
２　引用例２に記載されている技術的事項
　
　本願の出願前に頒布又は電気通信回線を通じて公衆に利用可能となり，当審からの上記平成２７年１０月２８日付けの拒絶理由通知において引用された，特開平９−１４６７６５号公報（平成９年６月６日出願公開，以下，「引用例２」という。）には，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｄ　「【００１６】
図１に戻り，シナリオ記述部２０は，シナリオ(1) ２０−１，…，シナリオ(n) ２０−ｎからなる。各シナリオ(1) ２０−１，…，シナリオ(n) ２０−ｎは，それぞれ任意のサービスを行う場合の単位となっており，それぞれのサービスを実行する場合に必要となるプログラム群格納部１０に格納された各プログラムと，これらプログラムの実行順序を記述している。
　…（中略）…
【００１９】
シナリオ実行部４１は，任意のサービスが要求された場合に，シナリオ選択面４４よりそのサービスに対応したシナリオを選択し，選択したシナリオをシナリオ記述部２０より得て，これを実行する機能を有している。シナリオリード部４２は，個々のシナリオの読み出しを行い，また，シナリオライト部４３は，新規のシナリオをシナリオ記述部２０に書き込む機能を有している。
　
Ｅ　「【００２２】
ステップＳ５−１〜ｎにおける各プログラムの処理において，その実行結果が正常か異常かをシナリオ実行部４１に応答し，シナリオ実行部４１は，その実行結果を判定する（ステップＳ６）。実行結果が正常時には，シナリオ実行部４１は，シナリオ記述部２０で記述されるシナリオの正常時の分岐先を次の実行シナリオのインデックスとし（ステップＳ７），実行結果が異常であった場合は，シナリオの異常時の分岐先を次の実行シナリオのインデックスとする（ステップＳ８）。
　…（中略）…
【００２４】
メッセージ分析では，受信したメッセージを入力として，受信トランザクションＩＤ，受信イベントを出力し，同時にプログラムの実行結果をシナリオ記述部２０に応答するシナリオ記述部２０では，メッセージ分析が正常であった場合，正常時のメソッド番号のインデックス値を２に設定する。その後は，ステップＳ２に戻り，メソッド番号のインデックス値の２（図５における項番２）に対応するメソッド番号が終了かを判定するが，この場合のメソッド番号が状態番号取得であるため，結果的に前回のメッセージ分析で出力されたトランザクションＩＤでインデックスされる制御データ３０−１〜３０−ｎの状態番号を出力として応答し，実行結果が正常であれば，次に正常のメソッド番号のインデックス値を３に設定する。
　
　
第４　対比
　
１　本願発明と引用発明とを対比する。
　
（１）引用発明では，「管理サーバ」が「管理者から被管理装置への複数種類のコマンドからなるリクエストをデータベース内に保管」するところ，引用発明の「管理サーバ」は本願発明の「管理サーバ」に対応することは明らかであり，引用発明の「管理サーバ」は「被管理装置」への「コマンド」を「データベース」内に保管することから，引用発明の「被管理装置」，「コマンド」，「データベース」はそれぞれ，本願発明の「管理対象装置」，「指示」，「指示蓄積手段」に相当すると言える。
　
（２）引用発明では，「管理サーバ」が「被管理装置からのアクセスにより通信セッションを確立」するところ，「被管理装置」との「通信セッション」は「接続」とみることができ，「管理サーバ」は「被管理装置」からの「接続」を受け入れる手段を実質的に備えていると言えるから，引用発明における「被管理装置からのアクセスにより通信セッションを確立」することは，本願発明の「管理対象装置からの接続を受け入れる接続受入手段」に相当すると言える。
　
（３）引用発明では，「管理サーバ」が「被管理装置からの前記コマンドリクエストに対応するコマンドを前記データベースから取得」するに当たって，「被管理装置での前記コマンドの実行結果に応じて次のコマンドを変更する決定を順次行う」ところ，引用例１の上記Ｂの「また，1回のコマンドの結果を受信・確認してから，次の送信すべきコマンドを決定する事ができるので，コマンドの柔軟性が高くなる。また，順次コマンドを実行させ結果複数の一連のコマンドを実行させる方式によれば，　…（後略）…」との記載からすると，「被管理装置」における「コマンド」の実行結果に応じて次の「コマンド」を適宜変更しながら，変更された「コマンド」を「データベース」から取得することで，「管理サーバ」が「データベース」に保管された複数種類の「コマンド」に基づいて，一連の「コマンド」を順次決定しているとみることができる。
　そうすると，引用発明では，「管理サーバ」が，「データベース」に保管された複数種類の「コマンド」に基づいて，「被管理装置」における「コマンド」の実行結果に応じて一連の「コマンド」を順次決定するための“指示決定ルール”を実質的に保持していると言える。
　一方，本願発明の「指示シナリオ」も「管理対象装置に対する複数の指示の内容に基づいて，該管理対象装置における指示の実行結果に応じて指示を変更する」ために生成されるものであるから，“指示決定ルール”に従って一連の指示を決定するための手段であると言え，すると，「指示シナリオ」を生成する手段を備える本願発明も，一連の指示を決定するための“指示決定ルール”を実質的に保持すると言える。
　してみると，引用発明での「被管理装置での前記コマンドの実行結果に応じて次のコマンドを変更する決定を順次行う」ことと，本願発明の「管理対象装置に対する複数の指示の内容に基づいて，該管理対象装置における指示の実行結果に応じて指示を変更する指示シナリオを生成する指示シナリオ生成手段」とは，後記する点で相違するものの，“管理対象装置に対する複数の指示の内容に基づいて，該管理対象装置における指示の実行結果に応じて指示を変更する指示決定ルールを保持する手段”である点で共通すると言える。
　
（４）引用発明では，「管理サーバ」が「被管理装置からの前記コマンドリクエストに対応するコマンドを前記データベースから取得し，取得したコマンドを前記被管理装置へ送信」するところ，上記（３）の検討から，「被管理装置」へ送信する「コマンド」は「データベース」に保管され，“指示決定ルール”に基づき実行結果に応じて変更された「コマンド」を含むと言え，「管理サーバ」が保持する“指示決定ルール”に従って「通信セッション」を介して「被管理装置」に送信することも明らかである。
　そうすると，引用発明での「被管理装置からの前記コマンドリクエストに対応するコマンドを前記データベースから取得し，取得したコマンドを前記被管理装置へ送信」することと，本願発明の「指示シナリオに含まれる指示のうち，前記実行結果通知受信手段によって受信された前記実行結果に応じて変更された指示を，前記管理対象装置に送信する」ものであって，「前記指示シナリオに従って，前記指示蓄積手段によって蓄積された指示を，前記接続を介して送信することで，該指示を前記管理対象装置に取得させる指示送信手段」とは，後記する点で相違するものの，“前記実行結果通知受信手段によって受信された前記実行結果に応じて変更された指示を，前記管理対象装置に送信する”ものであって，“指示決定ルールに従って，前記指示蓄積手段によって蓄積された指示を，前記接続を介して送信することで，該指示を前記管理対象装置に取得させる指示送信手段”である点で共通すると言える。
　
（５）引用発明では，「管理サーバ」が「被管理装置が実行した前記コマンドの実行結果を受信」するところ，「被管理装置」における「コマンド」の実行結果を受信する手段を実質的に備えていると言えるから，引用発明での「被管理装置が実行した前記コマンドの実行結果を受信」することは，本願発明の「管理対象装置における前記指示の実行結果通知を受信する実行結果通知受信手段」に相当すると言える。
　
　
２　以上から，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
＜一致点＞　
　
「　管理対象装置に対する指示を蓄積する指示蓄積手段と，
　前記管理対象装置からの接続を受け入れる接続受入手段と，
　前記管理対象装置に対する複数の指示の内容に基づいて，該管理対象装置における指示の実行結果に応じて指示を変更する指示決定ルールを保持する手段と，
　前記指示決定ルールに従って，前記指示蓄積手段によって蓄積された指示を，前記接続を介して送信することで，該指示を前記管理対象装置に取得させる指示送信手段と，
　前記管理対象装置における前記指示の実行結果通知を受信する実行結果通知受信手段と，
　を備え，
　前記指示送信手段は，前記実行結果通知受信手段によって受信された前記実行結果に応じて変更された指示を，前記管理対象装置に送信する，
　管理サーバ。」　
　
＜相違点１＞　
　
　本願発明は，「管理対象装置に対する複数の指示の内容に基づいて，該管理対象装置における指示の実行結果に応じて指示を変更する指示シナリオを生成する指示シナリオ生成手段」を備えるのに対して，引用発明では，「被管理装置での前記コマンドの実行結果に応じて次のコマンドを変更する決定を順次行う」ものの，「指示シナリオ」を生成することは言及されていない点。
　
＜相違点２＞　
　
　本願発明では，「指示シナリオに従って，前記指示蓄積手段によって蓄積された指示を，前記接続を介して送信する」のに対して，引用発明では，「コマンドを前記データベースから取得し，取得したコマンドを前記被管理装置へ送信」するものの，「指示シナリオ」に従って「コマンド」を取得することについて特定されていない点。
　
　
第５　当審の判断
　
　上記相違点１，２について検討する。
　
１　相違点１について
　
　引用発明では，「被管理装置での前記コマンドの実行結果に応じて次のコマンドを変更する決定を順次行う」ところ，「第４　対比」「１」「（３）」で検討したとおり，「管理サーバ」が，「データベース」に保管された複数種類の「コマンド」に基づいて，「被管理装置」における「コマンド」の実行結果に応じて一連の「コマンド」を順次決定するための“指示決定ルール”を実質的に保持していると言える。また，引用発明における「コマンド」の実行は，対応する「プログラム」の実行であることも自明である。そして，引用発明において，「被管理装置」における「コマンド」の実行結果に応じて一連の「コマンド」を順次決定するためのルールを具体的に如何なる手段により実現しているか明示されていないものの，それは必要に応じて適宜選択し得た事項であると言える。 
　一方，プログラム実行順序を制御する情報処理システムに関し，外部からのサービス要求に対応したプログラム実行順序を制御するシナリオを選択により生成し，生成されたシナリオに従い実行結果に応じて分岐先を変更してプログラムを順次実行することは，例えば，引用例２（上記Ｄ，Ｅを参照）に記載されるように，本願出願前には当該技術分野の周知技術であった。
　そうすると，引用発明において，実行結果に応じた一連のコマンド決定のために上記引用例２に記載の周知技術を適用し，被管理装置に対する複数のコマンドの内容に基づいて，該被管理装置におけるコマンドの実行結果に応じてコマンドを変更する指示シナリオを生成する指示シナリオ生成手段を具備すること，すなわち，上記相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
　
２　相違点２について
　
　引用発明では，「コマンドを前記データベースから取得し，取得したコマンドを前記被管理装置へ送信」し，送信される「コマンド」は「実行結果に応じて次のコマンドを変更する決定を順次行う」ことにより選択されるものであるところ，生成されたシナリオに従い実行結果に応じて分岐先を変更してプログラムを順次実行することは，例えば，引用例２（上記Ｄ，Ｅを参照）に記載されるように，本願出願前には当該技術分野の周知技術であった。
　そして，引用発明において，コマンド決定のために上記引用例２に記載の周知技術を適用し，適宜，指示シナリオに従ってデータベースに保管されたコマンドを選択し，選択されたコマンドを被管理装置に送信すること，すなわち，上記相違点２に係る構成とすることは，当業者が容易に想到し得たことである。
　
３　小括
　
　上記で検討したごとく，相違点１，２に係る構成は当業者が容易に想到し得たものであり，そして，これらの相違点を総合的に勘案しても，本願発明の奏する作用効果は，引用発明及び当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　
　
第６　むすび 
　
　以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。 
　
　よって，結論のとおり審決する。