• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1314162
審判番号 不服2015-2080  
総通号数 198 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-06-24 
種別 拒絶査定不服の審決 
審判請求日 2015-02-03 
確定日 2016-05-06 
事件の表示 特願2010-168816「管理サーバ、情報処理装置、方法およびプログラム」拒絶査定不服審判事件〔平成24年 2月 9日出願公開、特開2012- 27869〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由
第1 手続の経緯

本件審判請求に係る出願(以下,「本願」という。)は,平成22年7月28日の出願であって,その手続の経緯は以下のとおりである。

平成24年12月14日 :出願審査請求書の提出
平成26年 2月17日付け :拒絶理由の通知
平成26年 4月28日 :意見書,手続補正書の提出
平成26年10月28日付け :拒絶査定
平成27年 2月 3日 :審判請求書,手続補正書の提出
平成27年 2月26日 :前置報告
平成27年 7月 8日 :上申書の提出
平成27年10月28日付け :拒絶理由の通知(当審)
平成27年12月21日 :意見書,手続補正書の提出


第2 本願発明

本願の請求項に係る発明は,上記平成27年12月21日付け手続補正書により補正された特許請求の範囲の請求項1乃至17に記載されたとおりのものであると認められるところ,その請求項1に係る発明(以下,「本願発明」という。)は,以下のとおりのものである。

「 管理対象装置に対する指示を蓄積する指示蓄積手段と,
前記管理対象装置からの接続を受け入れる接続受入手段と,
前記管理対象装置に対する複数の指示の内容に基づいて,該管理対象装置における指示の実行結果に応じて指示を変更する指示シナリオを生成する指示シナリオ生成手段と,
前記指示シナリオに従って,前記指示蓄積手段によって蓄積された指示を,前記接続を介して送信することで,該指示を前記管理対象装置に取得させる指示送信手段と,
前記管理対象装置における前記指示の実行結果通知を受信する実行結果通知受信手段と,
を備え,
前記指示送信手段は,前記指示シナリオに含まれる指示のうち,前記実行結果通知受信手段によって受信された前記実行結果に応じて変更された指示を,前記管理対象装置に送信する,
管理サーバ。」


第3 引用例

1 引用例1に記載されている技術的事項および引用発明

(1)本願の出願前に頒布又は電気通信回線を通じて公衆に利用可能となり,当審からの上記平成27年10月28日付けの拒絶理由通知において引用された,特開2007-334612号公報(平成19年12月27日出願公開,以下,「引用例1」という。)には,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

A 「【0021】
(本実施形態の通信シーケンスの概略)
図2は,本実施形態に係る被管理装置102と管理サーバ106と管理者間の通信シーケンス例の一部を表した図である。尚,なお,ここでの管理者とは管理サーバ106に操作指示を行うメンテナンスオペレータのことを指し,以下では,単に管理者と呼ぶ。図2では,管理サーバ106から被管理装置102に,「設定情報リクエスト」と「リブートリクエスト」の指示を行なう例を示すが,これは通信シーケンスの概略の説明であってこれに限定されない。
【0022】
シーケンスS401/S402は,管理者が管理サーバ106を介して,被管理装置102に対して指示するコマンドの入力を表している。シーケンスS401では被管理装置102の設定情報取得,シーケンスS402では被管理装置のリブートを指示している。ここでは,管理者からの連続した指示の入力を例として考えている。この指示結果の一例が図6に示される。
【0023】
シーケンスS403で,管理サーバ106は管理者からリクエストされたコマンドに対応する。管理サーバ106は,ログイン時の管理者IDから,オペレーションしている管理者が対象としている被管理装置102(被管理装置ID)へのコマンド発行権限があるかを,データベースのアクセスコントロールをベースにして判定する。これは,データベースのアクセスコントロールを使用することに限定しない。アプリケーションプログラムでアクセスコントロールの仕組みが実装されていればよい。シーケンスS404では,管理サーバ106はS403の判定に従って,S401とS402の管理者からのリクエストを正規のリクエストとして,管理サーバ106のデータベース内に保管する。
【0024】
シーケンスS405は,対象の被管理装置102から管理サーバ106へのコマンドリクエストを表している。このシーケンスS405における被管理装置102によるコマンドリクエスト送信際して,被管理装置102主体で通信セッションが張られる。また,被管理装置102主体の管理サーバ106へのアクセスによる通信セッションの確立により,管理サーバ106は被管理装置102側のファイアウォールを越えて被管理装置102に対して各種指示を行える。これは,被管理装置102から管理サーバ106への,被管理装置102に対するコマンドがないかの問い合わせコマンドである。シーケンスS406で,管理サーバ106はS405での被管理装置102からのコマンドリクエストに対する認証を行う。具体的には,コマンドリクエストとともに送られてくる被管理装置102の識別ID(以下,被管理装置IDと呼ぶ)を認識し,管理サーバ106内のデータベースから被管理装置IDを検索する。この検索結果に基づいて,管理サーバ106は,正規の被管理装置であることを確認した後,受信したデータの種類を確認する。S405で受信したデータはコマンドリクエスト(getOperationList)なので,管理サーバ106は,対象の被管理装置102に対して管理者からコマンドが指示されていないかデータベース内を検索する。シーケンスS407にて,管理サーバ106は対象の被管理装置102に対するコマンドをデータベースから取得する。
【0025】
シーケンスS408で,管理サーバ106は,S405のコマンドリクエスト(getOperationList)のReplyとして,被管理装置102へコマンドを送信する。ここでのコマンドは被管理装置102への設定情報取得コマンドである。シーケンスS409は,管理サーバ106から被管理装置102へのReply通信を表す。この時のReplyの例が図5の通信サンプル1に相当する。シーケンスS410で,被管理装置102は管理サーバ106から受信したコマンドを実行する。コマンドは被管理装置102への設定情報取得コマンドなので,被管理装置102の設定情報を出力する。」

B 「【0026】
シーケンスS411は,S410で実行したコマンドの結果(被管理装置102の保持する設定情報)を被管理装置102から管理サーバ106へ送信することを表している。シーケンスS412にて,管理サーバ106は被管理装置102の設定情報を受信する。通信にてデータを受信したときには,S406と同様に被管理装置IDによって認証し,コマンド及びデータを解釈する。このときのコマンドは設定情報送信(postConfiguration)であり,データ部は被管理装置102の保持する設定情報である。本例では,管理サーバ106は,コマンドの結果をデータベースに格納した後に,被管理装置102に対して2つめのコマンド(リブート指示)があることを認識する。
【0027】
この場合,管理サーバ106は,シーケンスS413にて,被管理装置102にコマンドリクエスト(getOperationList)を行うように指示を発行する。シーケンスS414にて,管理サーバ106から被管理装置102に,前回のコマンドが受信成功したと伝えるとともに,コマンドリクエスト(getOperationList)を次に行うよう指示をする。このときのReplyの例が図5の通信サンプル2に相当する。シーケンスS415で,被管理装置102はS414のリクエストより,管理サーバ106に対してコマンドリクエスト(getOperationList)を送信する。
…(中略)…
【0032】
また,上の図2のシーケンスでは,管理サーバが被管理装置にコマンドを指示した後には,必ず,被管理装置はコマンドの実行結果を管理サーバに通知する処理を行う。このコマンド実行結果を受けた管理サーバは,さらに実行させたいコマンドがある場合に,このコマンド実行結果のReplyに,次のコマンドが用意されている事を表す情報を出力する事で,被管理装置に,再度コマンドリクエスト通信を行うよう指示する事ができる。一方,被管理装置に複数のコマンを処理させるために,管理サーバが被管理装置に複数のコマンドを一度に送信する方法も想定される。ここで,1回のコマンドを複数回繰り返して,複数のコマンドを処理する方法と,1度に複数のコマンドセットを送信する方法と比較すると,1回のコマンドを複数回繰り返して複数のコマンドを処理する方法には,次の効果がある。管理サーバが発行したコマンド処理の結果を1コマンドに対して,1回ずつ受信するので確認が容易である。また,1回のコマンドの結果を受信・確認してから,次の送信すべきコマンドを決定する事ができるので,コマンドの柔軟性が高くなる。また,順次コマンドを実行させ結果複数の一連のコマンドを実行させる方式によれば,コマンドを受ける被管理装置に,複数処理を一度に処理するのに必要な規模のハードウェアリソースを必要としない。」

C 「【0069】
(動作例1の動作手順例)
図9は,管理サーバが,管理者のリクエストを受け,被管理装置にコマンドを送信する処理を表すフローチャートである。このフローチャートで表す動作例は,管理者から複数のリクエストを受けたときに,複数のコマンドがすべて処理されるように,管理サーバが被管理装置へリクエストすることを特徴とする。すなわち,管理サーバがリクエストを被管理装置へ送信する際に,複数のコマンドの1つ1つのコマンドの結果を確認できるように,コマンドの数だけ被管理装置のコマンドリクエストを被管理装置へ送信する。
…(中略)…
【0072】
被管理装置への設定変更のコマンドがあれば,ステップS508で,カウンタCNTをリセットしてCNT = 1をセットする。ステップS510にて,カウンタCNTの値が,コマンドの数N未満だった場合に,ステップS511で,被管理装置に対して,CNT番目のコマンドを送信する。ステップS512にて,ステップS511で被管理装置に送信したCNT番目のコマンドの結果を受信する。そして,ステップS519で,管理サーバ106は,S512で受信した実行結果から,次のコマンド送信を行うための準備を行うか,その他の処理を行うかを決定する。ここでは,コマンド結果が成功していた場合に,次のコマンド送信を準備するためにステップS513へ進む。また,被管理装置へ送信した前回コマンドが失敗していた場合には,再度,同じコマンドを送信するようにステップS511へ進む。このS519の判定処理により,より確実に被管理装置に対して一連のコマンドを指示することができる。ステップS513にて,次のコマンドのために,被管理装置へコマンドリクエストの要求を送信する。ステップS514にて,ステップS513の指示結果として,被管理装置からコマンドリクエストを受信する。この被管理装置からのコマンドリクエストは,getOperationListのメソッドに相当する。ステップS515にて,カウンタCNTの値を1つインクリメントする。」


(2)ここで,引用例1に記載されている事項を検討する。

ア 上記Aの「図2は,本実施形態に係る被管理装置102と管理サーバ106と管理者間の通信シーケンス例の一部を表した図である。」,「シーケンスS401/S402は,管理者が管理サーバ106を介して,被管理装置102に対して指示するコマンドの入力を表している。」,「シーケンスS403で,管理サーバ106は管理者からリクエストされたコマンドに対応する。管理サーバ106は,ログイン時の管理者IDから,オペレーションしている管理者が対象としている被管理装置102(被管理装置ID)へのコマンド発行権限があるかを,データベースのアクセスコントロールをベースにして判定する。 …(中略)… シーケンスS404では,管理サーバ106はS403の判定に従って,S401とS402の管理者からのリクエストを正規のリクエストとして,管理サーバ106のデータベース内に保管する。」との記載からすると,管理者から被管理装置へのリクエストは複数種類のコマンドからなり,管理サーバが自装置のデータベースに当該リクエストを保管することが読み取れるから,引用例1には,
“管理者から被管理装置への複数種類のコマンドからなるリクエストをデータベース内に保管”する“管理サーバ”
が記載されていると解される。

イ 上記Aの「シーケンスS405は,対象の被管理装置102から管理サーバ106へのコマンドリクエストを表している。このシーケンスS405における被管理装置102によるコマンドリクエスト送信際して,被管理装置102主体で通信セッションが張られる。また,被管理装置102主体の管理サーバ106へのアクセスによる通信セッションの確立により,管理サーバ106は被管理装置102側のファイアウォールを越えて被管理装置102に対して各種指示を行える。」との記載からすると,被管理装置が管理サーバへコマンドリクエストを送信するためにアクセスし,管理サーバが被管理装置との間で通信セッションを確立することが読み取れるから,引用例1には,
“被管理装置からのアクセスにより通信セッションを確立し,前記被管理装置からコマンドリクエストを受信”する“管理サーバ”
が記載されていると解される。

ウ 上記Aの「S405で受信したデータはコマンドリクエスト(getOperationList)なので,管理サーバ106は,対象の被管理装置102に対して管理者からコマンドが指示されていないかデータベース内を検索する。シーケンスS407にて,管理サーバ106は対象の被管理装置102に対するコマンドをデータベースから取得する。」,「シーケンスS408で,管理サーバ106は,S405のコマンドリクエスト(getOperationList)のReplyとして,被管理装置102へコマンドを送信する。」との記載からすると,管理サーバは被管理装置から受信したコマンドリクエストに対応するコマンドをデータベースから検索し,データベースから取得した当該コマンドリクエストに対応するコマンドを被管理装置へ送信することが読み取れるから,引用例1には,
“被管理装置からのコマンドリクエストに対応するコマンドをデータベースから取得し,取得したコマンドを前記被管理装置へ送信”する“管理サーバ”
が記載されていると解される。

エ 上記Aの「シーケンスS410で,被管理装置102は管理サーバ106から受信したコマンドを実行する。」との記載,上記Bの「シーケンスS411は,S410で実行したコマンドの結果(被管理装置102の保持する設定情報)を被管理装置102から管理サーバ106へ送信することを表している。」,「また,上の図2のシーケンスでは,管理サーバが被管理装置にコマンドを指示した後には,必ず,被管理装置はコマンドの実行結果を管理サーバに通知する処理を行う。」との記載からすると,被管理装置は管理サーバから受信した,コマンドリクエストに対応するコマンドを実行し,管理サーバは,被管理装置がコマンドを実行した結果を受信することが読み取れるから,引用例1には,
“被管理装置が実行したコマンドの実行結果を受信”する“管理サーバ”
が記載されていると解される。

オ 上記Bの「このコマンド実行結果を受けた管理サーバは,さらに実行させたいコマンドがある場合に,このコマンド実行結果のReplyに,次のコマンドが用意されている事を表す情報を出力する事で,被管理装置に,再度コマンドリクエスト通信を行うよう指示する事ができる。 …(中略)… 管理サーバが発行したコマンド処理の結果を1コマンドに対して,1回ずつ受信するので確認が容易である。また,1回のコマンドの結果を受信・確認してから,次の送信すべきコマンドを決定する事ができるので,コマンドの柔軟性が高くなる。」との記載,上記Cの「ステップS512にて,ステップS511で被管理装置に送信したCNT番目のコマンドの結果を受信する。そして,ステップS519で,管理サーバ106は,S512で受信した実行結果から,次のコマンド送信を行うための準備を行うか,その他の処理を行うかを決定する。ここでは,コマンド結果が成功していた場合に,次のコマンド送信を準備するためにステップS513へ進む。また,被管理装置へ送信した前回コマンドが失敗していた場合には,再度,同じコマンドを送信するようにステップS511へ進む。このS519の判定処理により,より確実に被管理装置に対して一連のコマンドを指示することができる。」との記載からすると,管理サーバは,被管理装置でのコマンドの実行結果に応じて,例えば,次のコマンドの送信を行うための準備を行うか,同じコマンドを送信するかを決定するように,次のコマンドを変更する決定を順次行うことが読み取れるから,引用例1には,
“被管理装置でのコマンドの実行結果に応じて次のコマンドを変更する決定を順次行う”“管理サーバ”
が記載されていると解される。

(3)以上,ア乃至オの検討によれば,引用例1には次の発明(以下,「引用発明」という。)が記載されているものと認める。

「 管理者から被管理装置への複数種類のコマンドからなるリクエストをデータベース内に保管し,
前記被管理装置からのアクセスにより通信セッションを確立し,
前記被管理装置からコマンドリクエストを受信し,
前記被管理装置からの前記コマンドリクエストに対応するコマンドを前記データベースから取得し,取得したコマンドを前記被管理装置へ送信し,
前記被管理装置が実行した前記コマンドの実行結果を受信し,
前記被管理装置での前記コマンドの実行結果に応じて次のコマンドを変更する決定を順次行う
ことを特徴とする管理サーバ。」


2 引用例2に記載されている技術的事項

本願の出願前に頒布又は電気通信回線を通じて公衆に利用可能となり,当審からの上記平成27年10月28日付けの拒絶理由通知において引用された,特開平9-146765号公報(平成9年6月6日出願公開,以下,「引用例2」という。)には,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

D 「【0016】図1に戻り,シナリオ記述部20は,シナリオ(1) 20-1,…,シナリオ(n) 20-nからなる。各シナリオ(1) 20-1,…,シナリオ(n) 20-nは,それぞれ任意のサービスを行う場合の単位となっており,それぞれのサービスを実行する場合に必要となるプログラム群格納部10に格納された各プログラムと,これらプログラムの実行順序を記述している。尚,これらシナリオ(1) 20-1,…,シナリオ(n) 20-nの詳細については後述する。
…(中略)…
【0019】シナリオ実行部41は,任意のサービスが要求された場合に,シナリオ選択面44よりそのサービスに対応したシナリオを選択し,選択したシナリオをシナリオ記述部20より得て,これを実行する機能を有している。シナリオリード部42は,個々のシナリオの読み出しを行い,また,シナリオライト部43は,新規のシナリオをシナリオ記述部20に書き込む機能を有している。更に,シナリオ選択面44は,任意のサービスに対応したシナリオ記述部20におけるシナリオ(1) 20-1,…,シナリオ(n) 20-nの関係を示している。」

E 「【0022】ステップS5-1?nにおける各プログラムの処理において,その実行結果が正常か異常かをシナリオ実行部41に応答し,シナリオ実行部41は,その実行結果を判定する(ステップS6)。実行結果が正常時には,シナリオ実行部41は,シナリオ記述部20で記述されるシナリオの正常時の分岐先を次の実行シナリオのインデックスとし(ステップS7),実行結果が異常であった場合は,シナリオの異常時の分岐先を次の実行シナリオのインデックスとする(ステップS8)。
…(中略)…
【0024】メッセージ分析では,受信したメッセージを入力として,受信トランザクションID,受信イベントを出力し,同時にプログラムの実行結果をシナリオ記述部20に応答するシナリオ記述部20では,メッセージ分析が正常であった場合,正常時のメソッド番号のインデックス値を2に設定する。その後は,ステップS2に戻り,メソッド番号のインデックス値の2(図5における項番2)に対応するメソッド番号が終了かを判定するが,この場合のメソッド番号が状態番号取得であるため,結果的に前回のメッセージ分析で出力されたトランザクションIDでインデックスされる制御データ30-1?30-nの状態番号を出力として応答し,実行結果が正常であれば,次に正常のメソッド番号のインデックス値を3に設定する。」


第4 対比

1 本願発明と引用発明とを対比する。

(1)引用発明では,「管理サーバ」が「管理者から被管理装置への複数種類のコマンドからなるリクエストをデータベース内に保管」するところ,引用発明の「管理サーバ」は本願発明の「管理サーバ」に対応することは明らかであり,引用発明の「管理サーバ」は「被管理装置」への「コマンド」を「データベース」内に保管することから,引用発明の「被管理装置」,「コマンド」,「データベース」はそれぞれ,本願発明の「管理対象装置」,「指示」,「指示蓄積手段」に相当すると言える。

(2)引用発明では,「管理サーバ」が「被管理装置からのアクセスにより通信セッションを確立」するところ,「被管理装置」との「通信セッション」は「接続」とみることができ,「管理サーバ」は「被管理装置」からの「接続」を受け入れる手段を実質的に備えていると言えるから,引用発明における「被管理装置からのアクセスにより通信セッションを確立」することは,本願発明の「管理対象装置からの接続を受け入れる接続受入手段」に相当すると言える。

(3)引用発明では,「管理サーバ」が「被管理装置からの前記コマンドリクエストに対応するコマンドを前記データベースから取得」するに当たって,「被管理装置での前記コマンドの実行結果に応じて次のコマンドを変更する決定を順次行う」ところ,引用例1の上記Bの「また,1回のコマンドの結果を受信・確認してから,次の送信すべきコマンドを決定する事ができるので,コマンドの柔軟性が高くなる。また,順次コマンドを実行させ結果複数の一連のコマンドを実行させる方式によれば, …(後略)…」との記載からすると,「被管理装置」における「コマンド」の実行結果に応じて次の「コマンド」を適宜変更しながら,変更された「コマンド」を「データベース」から取得することで,「管理サーバ」が「データベース」に保管された複数種類の「コマンド」に基づいて,一連の「コマンド」を順次決定しているとみることができる。
そうすると,引用発明では,「管理サーバ」が,「データベース」に保管された複数種類の「コマンド」に基づいて,「被管理装置」における「コマンド」の実行結果に応じて一連の「コマンド」を順次決定するための“指示決定ルール”を実質的に保持していると言える。
一方,本願発明の「指示シナリオ」も「管理対象装置に対する複数の指示の内容に基づいて,該管理対象装置における指示の実行結果に応じて指示を変更する」ために生成されるものであるから,“指示決定ルール”に従って一連の指示を決定するための手段であると言え,すると,「指示シナリオ」を生成する手段を備える本願発明も,一連の指示を決定するための“指示決定ルール”を実質的に保持すると言える。
してみると,引用発明での「被管理装置での前記コマンドの実行結果に応じて次のコマンドを変更する決定を順次行う」ことと,本願発明の「管理対象装置に対する複数の指示の内容に基づいて,該管理対象装置における指示の実行結果に応じて指示を変更する指示シナリオを生成する指示シナリオ生成手段」とは,後記する点で相違するものの,“管理対象装置に対する複数の指示の内容に基づいて,該管理対象装置における指示の実行結果に応じて指示を変更する指示決定ルールを保持する手段”である点で共通すると言える。

(4)引用発明では,「管理サーバ」が「被管理装置からの前記コマンドリクエストに対応するコマンドを前記データベースから取得し,取得したコマンドを前記被管理装置へ送信」するところ,上記(3)の検討から,「被管理装置」へ送信する「コマンド」は「データベース」に保管され,“指示決定ルール”に基づき実行結果に応じて変更された「コマンド」を含むと言え,「管理サーバ」が保持する“指示決定ルール”に従って「通信セッション」を介して「被管理装置」に送信することも明らかである。
そうすると,引用発明での「被管理装置からの前記コマンドリクエストに対応するコマンドを前記データベースから取得し,取得したコマンドを前記被管理装置へ送信」することと,本願発明の「指示シナリオに含まれる指示のうち,前記実行結果通知受信手段によって受信された前記実行結果に応じて変更された指示を,前記管理対象装置に送信する」ものであって,「前記指示シナリオに従って,前記指示蓄積手段によって蓄積された指示を,前記接続を介して送信することで,該指示を前記管理対象装置に取得させる指示送信手段」とは,後記する点で相違するものの,“前記実行結果通知受信手段によって受信された前記実行結果に応じて変更された指示を,前記管理対象装置に送信する”ものであって,“指示決定ルールに従って,前記指示蓄積手段によって蓄積された指示を,前記接続を介して送信することで,該指示を前記管理対象装置に取得させる指示送信手段”である点で共通すると言える。

(5)引用発明では,「管理サーバ」が「被管理装置が実行した前記コマンドの実行結果を受信」するところ,「被管理装置」における「コマンド」の実行結果を受信する手段を実質的に備えていると言えるから,引用発明での「被管理装置が実行した前記コマンドの実行結果を受信」することは,本願発明の「管理対象装置における前記指示の実行結果通知を受信する実行結果通知受信手段」に相当すると言える。


2 以上から,本願発明と引用発明とは,以下の点で一致し,また,以下の点で相違する。

<一致点>

「 管理対象装置に対する指示を蓄積する指示蓄積手段と,
前記管理対象装置からの接続を受け入れる接続受入手段と,
前記管理対象装置に対する複数の指示の内容に基づいて,該管理対象装置における指示の実行結果に応じて指示を変更する指示決定ルールを保持する手段と,
前記指示決定ルールに従って,前記指示蓄積手段によって蓄積された指示を,前記接続を介して送信することで,該指示を前記管理対象装置に取得させる指示送信手段と,
前記管理対象装置における前記指示の実行結果通知を受信する実行結果通知受信手段と,
を備え,
前記指示送信手段は,前記実行結果通知受信手段によって受信された前記実行結果に応じて変更された指示を,前記管理対象装置に送信する,
管理サーバ。」

<相違点1>

本願発明は,「管理対象装置に対する複数の指示の内容に基づいて,該管理対象装置における指示の実行結果に応じて指示を変更する指示シナリオを生成する指示シナリオ生成手段」を備えるのに対して,引用発明では,「被管理装置での前記コマンドの実行結果に応じて次のコマンドを変更する決定を順次行う」ものの,「指示シナリオ」を生成することは言及されていない点。

<相違点2>

本願発明では,「指示シナリオに従って,前記指示蓄積手段によって蓄積された指示を,前記接続を介して送信する」のに対して,引用発明では,「コマンドを前記データベースから取得し,取得したコマンドを前記被管理装置へ送信」するものの,「指示シナリオ」に従って「コマンド」を取得することについて特定されていない点。


第5 当審の判断

上記相違点1,2について検討する。

1 相違点1について

引用発明では,「被管理装置での前記コマンドの実行結果に応じて次のコマンドを変更する決定を順次行う」ところ,「第4 対比」「1」「(3)」で検討したとおり,「管理サーバ」が,「データベース」に保管された複数種類の「コマンド」に基づいて,「被管理装置」における「コマンド」の実行結果に応じて一連の「コマンド」を順次決定するための“指示決定ルール”を実質的に保持していると言える。また,引用発明における「コマンド」の実行は,対応する「プログラム」の実行であることも自明である。そして,引用発明において,「被管理装置」における「コマンド」の実行結果に応じて一連の「コマンド」を順次決定するためのルールを具体的に如何なる手段により実現しているか明示されていないものの,それは必要に応じて適宜選択し得た事項であると言える。
一方,プログラム実行順序を制御する情報処理システムに関し,外部からのサービス要求に対応したプログラム実行順序を制御するシナリオを選択により生成し,生成されたシナリオに従い実行結果に応じて分岐先を変更してプログラムを順次実行することは,例えば,引用例2(上記D,Eを参照)に記載されるように,本願出願前には当該技術分野の周知技術であった。
そうすると,引用発明において,実行結果に応じた一連のコマンド決定のために上記引用例2に記載の周知技術を適用し,被管理装置に対する複数のコマンドの内容に基づいて,該被管理装置におけるコマンドの実行結果に応じてコマンドを変更する指示シナリオを生成する指示シナリオ生成手段を具備すること,すなわち,上記相違点1に係る構成とすることは,当業者が容易に想到し得たことである。

2 相違点2について

引用発明では,「コマンドを前記データベースから取得し,取得したコマンドを前記被管理装置へ送信」し,送信される「コマンド」は「実行結果に応じて次のコマンドを変更する決定を順次行う」ことにより選択されるものであるところ,生成されたシナリオに従い実行結果に応じて分岐先を変更してプログラムを順次実行することは,例えば,引用例2(上記D,Eを参照)に記載されるように,本願出願前には当該技術分野の周知技術であった。
そして,引用発明において,コマンド決定のために上記引用例2に記載の周知技術を適用し,適宜,指示シナリオに従ってデータベースに保管されたコマンドを選択し,選択されたコマンドを被管理装置に送信すること,すなわち,上記相違点2に係る構成とすることは,当業者が容易に想到し得たことである。

3 小括

上記で検討したごとく,相違点1,2に係る構成は当業者が容易に想到し得たものであり,そして,これらの相違点を総合的に勘案しても,本願発明の奏する作用効果は,引用発明及び当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。


第6 むすび

以上のとおり,本願の請求項1に係る発明は,特許法第29条第2項の規定により特許を受けることができないものであるから,その余の請求項に係る発明について検討するまでもなく,本願は拒絶すべきものである。

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

 
審理終結日 2016-03-04 
結審通知日 2016-03-08 
審決日 2016-03-23 
出願番号 特願2010-168816(P2010-168816)
審決分類 P 1 8・ 121- WZ (G06F)
最終処分 不成立  
前審関与審査官 漆原 孝治  
特許庁審判長 高木 進
特許庁審判官 須田 勝巳
辻本 泰隆
発明の名称 管理サーバ、情報処理装置、方法およびプログラム  
代理人 平川 明  
代理人 高田 大輔  
代理人 畑添 隆人  

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