【事件の表示】
　特願２０１７−　４３５１９「選択装置、装置選択方法、プログラム」拒絶査定不服審判事件〔平成３０年　９月２０日出願公開、特開２０１８−１４８４７７、請求項の数（４）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、平成２９年３月８日の出願であって、平成３０年３月３０日付けで拒絶理由通知がされ、平成３０年５月２３日に手続補正がされ、平成３０年１０月１１日付けで拒絶査定（原査定）がされ、これに対し、平成３１年１月１５日に拒絶査定不服審判の請求がされると同時に手続補正がされ、その後、平成３１年３月４日に前置報告がされ、令和２年４月１７日付けで当審より拒絶理由が通知され、令和２年６月１１日に手続補正がされたものである。
第２　本願発明
　本願請求項１−４に係る発明（以下、それぞれ「本願発明１」−「本願発明４」という。）は、令和２年６月１１日付けの手続補正で補正された特許請求の範囲の請求項１−４に記載された事項により特定される発明であり、本願発明１は以下のとおりの発明である。
　「【請求項１】
　装置の接続経路を示す接続経路情報を記憶する記憶部と、
　複数の前記装置の中から処理を実行する前記装置を選択する選択部と、
　を有し、
　前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し、
　前記装置の移動情報を取得する移動情報取得部を有し、
　前記選択部は、複数の前記装置のうちの前記移動情報取得部が取得した前記移動情報が所定の条件を満たす前記装置の中から、処理を実行する前記装置を選択し、
　前記選択部は、過去に処理を依頼した際の情報に基づいて、過去に実行した処理に用いられたデータと共通するデータを用いる処理を同一の前記装置が実行するよう前記装置の選択を行うこと、および、処理に用いるデータの一部が同一である共通性がある処理を同一の前記装置が実行するよう前記装置の選択を行うことにより、同一のデータを用いる複数の処理を同一の装置が実行するよう、処理を実行する前記装置を選択する
　選択装置。」
　なお、本願発明２−４の概要は以下のとおりである。
　本願発明２は、本願発明１を減縮した発明である。
　本願発明３、４は、それぞれ、本願発明１に対応する方法及びプログラムの発明であり、本願発明１とカテゴリ表現が異なるだけの発明である。
第３　引用文献、引用発明等
１．引用文献１及び引用発明
　原査定の拒絶の理由に引用された引用文献１（特開２０１２−０５３８５３号公報）には、図面とともに次の事項が記載されている（下線は、特に着目した箇所を示す。以下同様。）。
（１）　段落【０００７】−【０００８】
「【０００７】
　本発明は、上記課題に鑑み、
ユーザの目的に応じてクラウドサービスを動的に選択することができる情報処理装置
【課題を解決するための手段】
【０００８】
　上記課題に鑑み、本発明は、提供可能なサービスの種類及びサービスレベル情報を公開するサービス提供機器と、前記サービス提供機器を検出するサービス提供機器検出手段と、前記サービス提供機器から提供可能なサービスの種類が含まれるサービス種類情報及びサービスレベル情報を収集するサービス提供機器情報収集手段と、ネットワークを介して接続された情報処理装置であって、サービスの種類の入力を受け付けるサービス受け付け手段と、前記サービス提供機器の選択方針を受け付けるサービス選択方針取得手段と、前記サービス受け付け手段が受け付けたサービスを提供可能な前記サービス提供機器を前記サービス種類情報に基づき決定する候補機器選択手段と、前記候補機器選択手段が選択した前記サービス提供機器から１つ以上の前記サービス機器を前記選択方針に従って決定するサービス機器決定手段と、を有することを特徴とする。」
（２）　段落【００１１】−【００１４】
「【発明を実施するための形態】
【００１１】
以下、本発明を実施するための形態について図面を参照しながら説明する。
【００１２】
　図１は、本実施形態の情報処理システムの概略を説明する図の一例である。
クラウドサービス情報収集機２３と各種の機器がネットワークを介して接続され
ユーザは機器の１つ（デバイス２４
）を操作してサービスの提供を受け
【００１３】
　
処理のおよその流れ
（１）クラウドサービス情報収集機２３は、
定期的にネットワークを介して接続されたクラウドサービス機器２０と通信し、機器が提供可能な「利用可能サービス」、機器の「ＳＬＡ情報」を収集
して、ＳＬＡ情報を「ＳＬＡ評価ポイント」に変換
（２）ユーザは、自分のユーザポリシーを例えばデバイス２４を操作して設定し
設定されたユーザポリシーは、デバイス２４又はクラウドサービス情報収集機２３に記憶され
（３）ユーザは、サービスの提供を受ける際、デバイス２４を操作して処理フローを入力
処理フローは、処理の具体的な内容であり、利用可能サービスの組み合わせと言え
（４）デバイス２４は、クラウドサービス情報収集機２３から利用可能サービス及びＳＬＡ評価ポイントをダウンロード
（５）そして、デバイス２４は、処理フローに含まれる処理が可能なクラウドサービス機器２０を利用可能サービスを参照して決定
また、決定したクラウドサービス機器２０の中から、ユーザポリシーに適合するクラウドサービス機器２０をＳＬＡ評価ポイントに基づき選別
【００１４】
　単純な処理フローではクラウドサービス機器２０が１台の場合もあるが、
処理フローが複雑になると処理フローとユーザポリシーにより複数のクラウドサービス機器２０の組み合わせが決定される
（３）　段落【００４６】−【００４８】
「【００４６】
　図６はデバイス２４の機能ブロック図の一例を示す。
デバイス２４は、処理フロー受け付け部６１、クラウドサービス情報取得部６２、クラウド候補選択部６３、ポイント算出部６４、処理フロー実行部６５、クラウドサービス登録受け付け部６６、ポリシー受け付け手段６８、及び、ポリシーＤＢ６７を有
【００４７】
　処理フロー受け付け部６１は、ユーザが選択した処理フローの設定を受け付ける。
クラウドサービス情報取得部６２は、クラウドサービス情報収集機２３から利用可能サービスとＳＬＡ情報を取得
クラウド候補選択部６３は、処理フローに含まれる各処理と利用可能サービスに基づきサービスを提供可能なクラウドサービス機器２０の組み合わせ候補を選定
クラウドサービス決定部６４は、クラウドサービス機器２０の組み合わせ候補について、ＳＬＡ情報を用いて総合ポイントの平均と種別ポイントの平均を算出し、算出結果とポリシーＤＢ６７に記憶されたユーザポリシーに基づき、クラウドサービス機器２０の組み合わせ候補からユーザポリシーに合致したクラウドサービス機器２０の組み合わせを決定
【００４８】
　処理フロー実行部６５は、決定されたクラウドサービス機器２０の組み合わせに基づき処理フローを実行する。クラウドサービス登録受け付け部６６は、クラウドサービス情報収集機２３が利用可能サービスとＳＬＡ情報を収集できないクラウドサービス情報機器２０を、管理者が個別に設定できるようにする。クラウドサービス登録受け付け部６６は、管理者が設定したクラウドサービス機器２０をクラウドサービス情報収集機２３に送信するので、この後ユーザは、他のクラウドサービス機器２０と同様に登録したクラウドサービス機器２０を利用することができる。ポリシー受け付け手段６８は、ユーザが設定するユーザポリシーを受け付け、ポリシーＤＢ６７に登録する。」
（４）　段落【０１０１】−【０１０３】
「【０１０１】
　図１７は、
クラウドサービス機器２０の組み合わせ候補から、クラウドサービス決定部６４がユーザポリシーに従い、クラウドサービス機器２０の組み合わせを選択する手順
【０１０２】
　
ユーザＣＣＣのユーザポリシーは
ユーザポリシーに設定したとおりであ
（可用性ポイント３４以上、信頼性ポイント２８以上、条件外は問い合わせ）
【０１０３】
　
クラウドサービス機器２０の組み合わせ候補Ｎｏ１〜Ｎｏ４のうち、可用性ポイントが３４以上なのはＮｏ１の組み合わせであり、信頼性ポイントが２８以上なのはＮｏ１の組み合わせである
ため、クラウドサービス決定部６４は、クラウドサービス機器２０の組み合わせ候補Ｎｏ１〜Ｎｏ４のうち、ユーザＣＣＣの条件に合致する組み合わせとして、Ｎｏ１の組み合わせを選択する
（５）　したがって、上記引用文献１には次の発明（以下、「引用発明」という。）が記載されていると認められる。
「ユーザの目的に応じてクラウドサービスを動的に選択することができる情報処理装置であって、
　クラウドサービス情報収集機２３と各種の機器がネットワークを介して接続され、ユーザは機器の１つ（デバイス２４）を操作してサービスの提供を受け、
　処理のおよその流れは、
（１）クラウドサービス情報収集機２３は、定期的にネットワークを介して接続されたクラウドサービス機器２０と通信し、機器が提供可能な「利用可能サービス」、機器の「ＳＬＡ情報」を収集して、ＳＬＡ情報を「ＳＬＡ評価ポイント」に変換し、
（２）ユーザは、自分のユーザポリシーを例えばデバイス２４を操作して設定し、設定されたユーザポリシーは、デバイス２４又はクラウドサービス情報収集機２３に記憶され、
（３）ユーザは、サービスの提供を受ける際、デバイス２４を操作して処理フローを入力し、処理フローは、処理の具体的な内容であり、利用可能サービスの組み合わせと言え、
（４）デバイス２４は、クラウドサービス情報収集機２３から利用可能サービス及びＳＬＡ評価ポイントをダウンロードし、
（５）そして、デバイス２４は、処理フローに含まれる処理が可能なクラウドサービス機器２０を利用可能サービスを参照して決定し、また、決定したクラウドサービス機器２０の中から、ユーザポリシーに適合するクラウドサービス機器２０をＳＬＡ評価ポイントに基づき選別し、
　処理フローが複雑になると処理フローとユーザポリシーにより複数のクラウドサービス機器２０の組み合わせが決定されるものであり、
　デバイス２４は、処理フロー受け付け部６１、クラウドサービス情報取得部６２、クラウド候補選択部６３、ポイント算出部６４、処理フロー実行部６５、クラウドサービス登録受け付け部６６、ポリシー受け付け手段６８、及び、ポリシーＤＢ６７を有し、
　クラウドサービス情報取得部６２は、クラウドサービス情報収集機２３から利用可能サービスとＳＬＡ情報を取得し、
　クラウド候補選択部６３は、処理フローに含まれる各処理と利用可能サービスに基づきサービスを提供可能なクラウドサービス機器２０の組み合わせ候補を選定し、
　クラウドサービス決定部６４は、クラウドサービス機器２０の組み合わせ候補について、ＳＬＡ情報を用いて総合ポイントの平均と種別ポイントの平均を算出し、算出結果とポリシーＤＢ６７に記憶されたユーザポリシーに基づき、クラウドサービス機器２０の組み合わせ候補からユーザポリシーに合致したクラウドサービス機器２０の組み合わせを決定し、
　クラウドサービス機器２０の組み合わせ候補から、クラウドサービス決定部６４がユーザポリシーに従い、クラウドサービス機器２０の組み合わせを選択する手順において、
　ユーザＣＣＣのユーザポリシーは、ユーザポリシーに設定したとおりであり（可用性ポイント３４以上、信頼性ポイント２８以上、条件外は問い合わせ）、
　クラウドサービス機器２０の組み合わせ候補Ｎｏ１〜Ｎｏ４のうち、可用性ポイントが３４以上なのはＮｏ１の組み合わせであり、信頼性ポイントが２８以上なのはＮｏ１の組み合わせであるため、クラウドサービス決定部６４は、クラウドサービス機器２０の組み合わせ候補Ｎｏ１〜Ｎｏ４のうち、ユーザＣＣＣの条件に合致する組み合わせとして、Ｎｏ１の組み合わせを選択する、
デバイス２４。」
２．引用文献２について
　また、原査定の拒絶の理由に引用された引用文献２（特開２０１０−２４４４６９号公報）には、図面とともに、以下の記載がある。
（１）　段落【０００４】
「【
発明が解決しようとする課題
【０００４】
　
大規模なデータを多数のコンピュータで分散処理する場合には、データをコンピュータ間で移動させるコスト（遅延や通信時間など）の方が演算機能（プロセスなど）を移動させるコストよりも高くなる
そのため、データの移動をなるべく抑える必要がある。
（２）　段落【００１７】−【００２６】
「【００１７】
　分散処理システム１は、マップリデュース（ＭａｐＲｅｄｕｃｅ）というプログラミングモデルを用いて分散処理を実行するコンピュータシステムである。この分散処理システム１は、図１に示すように、１個のマスタノード１０と、複数のスレーブノード２０と、各ノード間を接続する複数のネットワークスイッチ（以下では単に「スイッチ」という）３０とを備えている。マスタノード１０は
分散処理を統括するコンピュータであ
　　　・・・（中略）・・・
【００２２】
　取得処理の詳細は次の通りである。まず、取得部１１は各スイッチ３０から構成情報を取得するための要求信号を生成し、各スイッチ３０に送信する。そして、取得部１１はその要求に応じて各スイッチ３０から送られてきた構成情報を取得し、算出部１２に出力する。ここで、
構成情報とは、スイッチ３０を識別するスイッチＩＤと、スイッチ３０に直接接続されているノードを識別するノードＩＤのリストとを含む情報である
【００２３】
　次に、
取得部１１は各スレーブノード２０に対して、
マスタノード１０からスレーブノード２０までの経路を示す経路情報を取得する
　　　・・・（中略）・・・
【００２６】
　
算出部１２は、すべての接続情報に基づいて上記の処理を実行し、各スイッチ３０にどのスレーブノード２０が直接接続されているかを算出する
（３）　段落【００３２】
「【００３２】
　
処理制御部１７は、分散処理を実行する複数のスレーブノード２０のうちの一つをリデューサー（Ｒｅｄｕｃｅｒ）として決定し
Ｄ（以下では「Ｒｅｄｕｃｅｒ情報」という）とをすべてのスレーブノード２０に送信する。」
（４）　段落【００３８】
「【００３８】
　処理部２３は、データブロックをＭａｐ処理して、演算結果データを生成する。そして、当該演算結果データの一部ごとにＲｅｄｕｃｅ処理を行う。その際、
処理部２３は、
当該Ｒｅｄｕｃｅｒと同じグループ内に存在するスレーブノード２０を選択する
（５）　段落【００４２】
「【００４２】
　まず、図６を用いて、グループ情報の算出手順を説明する。
マスタノード１０において、取得部１１が各スイッチ３０に対して構成情報を要求し、その要求に応じて送信されてきた構成情報を取得する
また、取得部１１は各スレーブノード２０と通信することで経路情報を取得する（ステップＳ１２、取得ステップ）
算出部１２がこれらの構成情報及び経路情報に基づいて、各スイッチ３０にどのスレーブノード２０が直接接続されているかを算出する
（６）　段落【００４７】
「【００４７】
　以上説明したように、本実施形態によれば、分散処理システム１内の各スレーブノード２０及びスイッチ３０と通信することで、スレーブノード２０とスイッチ３０との間の接続関係が取得され、この関係に基づいて、
各スイッチ３０にどのスレーブノード２０が直接接続されているかが導出される
処理される複数のデータブロックが、一のスイッチ３０に直接つながっている一又は複数のスレーブノード２０に配置される
これにより、データが複数のスイッチ３０を跨いで分散配置されることがなくなる
（７）　したがって、上記引用文献２には、大規模なデータを多数のコンピュータで分散処理する場合には、データをコンピュータ間で移動させるコストが高くなるため、データの移動をなるべく抑える必要があるという課題が公知であること、及び、分散処理を統括するコンピュータであるマスタノード１０から各スレーブノード２０までの経路情報を用いて、処理される複数のデータブロックが、一のスイッチ３０に直接つながっている複数のスレーブノード２０に分散配置されるように構成するという技術的事項が開示されていると認められる。
３．引用文献３について
　原査定の拒絶の理由に引用された引用文献３（特開２０１１−０５５１３９号公報）には、図面とともに、以下の記載がある。
（１）　段落【０００９】−【００１０】
「【０００９】
　本発明は、上述したような課題に鑑みてなされたものであり、
効率的な経路でのノード装置間の通信を行って、ネットワークの通信負荷を低減すること
【課題を解決するための手段】
【００１０】
　上記目的を達成するために、請求項１に係る発明は、複数のコンテンツデータを分散して保存する複数のノード装置から構成される情報通信システムであって、前記ノード装置は、
ネットワークに接続された特定装置へ向けてメッセージを送信する
メッセージを前記特定装置まで中継する中継装置のネットワークアドレスを示す第１中継アドレスを取得する
各ノード装置から前記特定装置までのネットワーク上の経路に位置する前記中継装置のネットワークアドレスを示す第２中継アドレスを取得する
コンテンツデータを記憶している複数のノード装置のうち、前記第２中継アドレスと、前記第１中継アドレスとの一致度が高いノード装置から前記所定のコンテンツデータを取得する
（２）　段落【００１８】
「【発明の効果】
【００１８】
　本発明によれば、各ノード装置は、
取得しようとするコンテンツデータを記憶している他のノード装置のうちネットワーク的に近い他のノード装置を優先的に選択し
総トラフィック量を軽減することができ、通信負荷を軽減することが可能となる。」
（３）　段落【００２２】
「【００２２】
　情報通信システムＳは、コンテンツデータを配信するためのシステムである。図１の上部枠５０内に示すように、ネットワーク８を介して相互に接続された複数のノード装置１ａ，１ｂ，１ｃ，１ｄ，・・・と、コンタクトサーバ１０とを備えて、情報通信システムＳは構成される。これらの装置には、各装置を示す情報としての固有の製造番号（例えば、ＭＡＣアドレス）及びネットワークアドレスが割り当てられている。なお、製造番号及びネットワークアドレスは、複数の装置間で重複しないものである。ネットワーク８がインターネットの場合、ネットワークアドレスは、ＩＰ（Internet Protocol）アドレスである。また、以下の説明において、ノード装置１ａ，１ｂ，１ｃ，１ｄ，・・のうち何れかのノード装置又は全てのノード装置を示す場合には、便宜上、ノード装置１という場合がある。また、
コンテンツデータは、例えば、映画データ、音楽データ、文書データなどである
（４）　段落【００２７】−【００２８】
「【００２７】
［２．１．各ノード装置１における経路情報の取得］
　まず、各ノード装置１ａ〜１ｃは、図３に示すように、
ネットワーク８に接続されたコンタクトサーバ１０へ向けて問い合わせメッセージを送信する
コンタクトサーバ１０まで中継する中継装置のネットワークアドレスを
「第１中継アドレス」と呼ぶ
【００２８】
　この第１中継アドレスは、各ノード装置１からコンタクトサーバ１０までのネットワーク８上の経路情報である。すなわち、ノード装置１ａとコンタクトサーバ１０との間には、中継装置１１，１２が存在しており、ノード装置１ａは、中継装置１１，１２のそれぞれのネットワークアドレスを取得して記憶する。そして、この２つの中継装置１１，１２のネットワークアドレスが、ノード装置１ａの第１中継アドレスである。また、同様に、ノード装置１ｂとコンタクトサーバ１０との間には、中継装置１１，１２が存在しており、ノード装置１ｂは、中継装置１１，１２のそれぞれのネットワークアドレスを取得して記憶する。そして、この２つの中継装置１１，１２のネットワークアドレスが、ノード装置１ｂの第１中継アドレスである。また、ノード装置１ｃとコンタクトサーバ１０との間には、中継装置１１，１３，１４とが存在しており、ノード装置１ｃは、中継装置１１，１３，１４のそれぞれのネットワークアドレスを取得して記憶する。そして、この３つの中継装置１１，１３，１４のネットワークアドレスが、ノード装置１ｃの第１中継アドレスである。」
（５）　段落【００４５】−【００４６】
「【００４５】
　図２に示す例では、リクエスタであるノード装置１ａは、コンテンツホルダであるノード装置１ｂ，１ｃの記憶手段に記憶されている第１中継アドレスを取得して、第２中継アドレスとして記憶手段に記憶する。ノード装置１ｂの記憶手段に記憶されている第１中継アドレスは、中継装置１１，１２のネットワークアドレスであり、ノード装置１ｃの記憶手段に記憶されている第１中継アドレスは、中継装置１１，１３，１４のネットワークアドレスである。従って、ノード装置１ａは、中継装置１１，１２のネットワークアドレスをノード装置１ｂの第２中継アドレスとして記憶手段に記憶し、中継装置１１，１３，１４のネットワークアドレスをノード装置１ｃの第２中継アドレスとして記憶手段に記憶する。このように、リクエスタは、コンテンツホルダから送信されるこのコンテンツホルダの第1中継アドレスを、
コンテンツホルダの第２中継アドレスとして取得する
【００４６】
　次に、リクエスタは、記憶手段に記憶している第１中継アドレスと第２中継アドレスとを比較する。そして、リクエスタは、
第１中継アドレスと一致度が高い第２中継アドレスを送信したコンテンツホルダからコンテンツデータを取得する
ここで、「一致度が高い」とは、両中継アドレスに共通するネットワークアドレスの数が多く、共通していないネットワークアドレスの数が少ないことを意味する
（６）　したがって、上記引用文献３には、映画データ、音楽データ、文書データなどの「コンテンツデータ」を「コンテンツホルダ」から取得する際、効率的な経路でノード装置間の通信を行ってネットワーク負荷を低減するために、より具体的には、自装置とネットワーク的により近い「コンテンツホルダ」を優先的に選択するために、特定の装置（コンタクトサーバ１０）から自装置までの経路（「第１中継アドレス」）との一致度の高い、特定の装置（コンタクトサーバ１０）から「コンテンツホルダ」までの経路（「第２中継アドレス」）を持つ「コンテンツホルダ」をデータの提供元として選択するという技術的事項が開示されていると認められる。
４．引用文献４について
　原査定において周知技術を示す文献として引用された引用文献４（特開２００５−１３６９０９号公報）には、アドホックネットワークなどの無線通信システムにおける基地局の決定において（【０００１】−【０００２】）、無線端末同士の通信ルート中に、無線通信の切断が生じる可能性の高い不安定なものが存在するという問題点に対処するために（【０００６】）、自端末の移動速度を測定して、移動速度が所定の速度以上（例えば５ｋｍ／ｈ以上）の無線端末は、無線通信の制御を行う基地局にならない（【００１２】）という技術的事項が開示されていると認められる。
５．引用文献５について
　原査定において周知技術を示す文献として引用された引用文献５（特開２００９−１５９４５７号公報）には、アドホック通信システムにおいて（【０００１】）、アドホック通信システムを形成する無線端末は、他の無線端末同士を中継する中継機能を提供しているため，常に動作している必要があり、消費電力を抑えることができないという問題点に対処するために（【０００７】）、送信元端末装置は、各アドホック中継装置３−１０の一定時間内の緯度・経度の変化に基づいて、各中継装置の移動速度を算出し、移動速度が閾値よりも大きい中継装置は、移動中であるか、端末グループから抜けるかも知れないと推定して、（例えば現時点から６０分後に）休止状態になるように指令して、他の中継装置を用いる他の中継ルートに切り替える（【００４６】−【００４８】）という技術的事項が記載されていると認められる。
６．引用文献６について
　原査定の拒絶の理由に引用された引用文献６（特開２００６−０３１０９６号公報）には、複数の処理サーバを有する分散処理システムにおいて（【０００１】）、サービス負荷の最も少ない時間に、あらかじめ設定した項目等に基づいて再起動を行うサーバを選択することで、サービスを停止させずにサーバを再起動する分散処理システムにおいて（【００１０】）、同一処理内容を複数の処理サーバで実行することによって負荷分散を実現する（【００２８】−【００２９】）という技術的事項が記載されていると認められる。
７．前置報告で引用された引用文献７について
　前置報告において周知技術を示す文献として引用された引用文献７（特開２００５−３１０１２０号公報）には、複数の計算機から構成される計算機システムにおいて、複数のタスクを処理する際に、特定のタスクをどの計算機に割り当てて処理を行うかを決定する技術において（【０００１】）、個々の計算機の負荷情報だけによる判断では最適なタスクの割当ができず、結果として実行効率の悪いタスク割当をしてしまうことがあるという問題点に対処するために（【０００４】）、個々の計算機の負荷情報だけでなく、個々の計算機で実行中のタスク、割り当てられるタスクと他のタスク間の関連度、計算機のネットワーク上での距離も考慮してタスクの割当を行うこと（【０００５】）、より具体的には、タスク割当計算機１０２には、負荷情報（２１１）、実行中タスク情報（２１２）、計算機間の距離情報（２１４）および、タスク間の関連度情報（２１３）とともに、タスクの割り当て結果を記録する「割当履歴情報」（２１５。タスクの割当てを行った時刻、当該タスクの終了時刻、割当て先計算機名とＩＰアドレスとポート番号、割り当てたタスク名からなる。）が格納されること（【００１１】、【００３０】、【図１】、【図１９】）、「割当履歴情報（２１５）」は、「タスク間の関連度情報」（２１３）を更新する際に用いられるデータであって（【００２８】）、例えば、タスク間の通信データ量の合計を求める際、「通信履歴情報」から送信元と送信先の計算機を特定し、「割当履歴情報」から、送信元／送信先計算機それぞれにおいて、その通信時に実行されていたタスクを特定していること（【００３２】）。そして、例えば、各タスク処理計算機間の通信データ量「１００ＫＢ」を、タスク間の関連度情報「１」として換算する（【００３５】）という技術的事項が記載されていると認められる。
８．前置報告で引用された引用文献８について
　前置報告において周知技術を示す文献として引用された引用文献８（特開２０１０−１３４５１８号公報）には、決裁などの業務処理を実行する、複数の計算機を含む計算機システムの構成管理において（【０００１】−【０００２】）、サーバ１の負荷が所定の上限値を超えた場合、前記サーバ１で実行中のサービスの一部（Ｓ３，Ｓ４）を、転送先のサーバ４に移し（「スケールアウト処理」）（【００１０】、【００５１】）、サービスの移動する際は、「共通のテーブル」を利用して、処理すべき複数のサービスの負荷合計が均等に分かれるようにグループ化した「サービスグループ」単位で行う（【００７９】、【図９】−【図１０】）という技術的事項が記載されていると認められる。
第４　対比・判断
１．本願発明１について
（１）　対比
　本願発明１と引用発明とを対比すると、次のことがいえる。
ア　引用発明の「デバイス２４」における「クラウドサービス情報取得部６２」は、「クラウドサービス情報収集機２３から利用可能サービスとＳＬＡ情報を取得し」ており、クラウドサービス情報収集機２３が「複数のクラウドサービス装置２０」から収集した情報を取得した後に、少なくとも一時的に「記憶」していることは明らかであるから、本願発明１の「装置の
接続経路を示す接続経路
イ　引用発明の「デバイス２４」における「クラウド候補選択部６３」は、「処理フローに含まれる各処理と利用可能サービスに基づきサービスを提供可能なクラウドサービス機器２０の組み合わせ候補を選定し」ているから、本願発明１の「複数の前記装置の中から処理を実行する前記装置を選択する選択部」に相当する。
ウ　引用発明の「デバイス２４」は、「ユーザの目的に応じてクラウドサービスを動的に
選択
　よって、本願発明１と引用発明との一致点・相違点は次のとおりであるといえる。
［一致点］
「装置の情報を記憶する記憶部と、
　複数の前記装置の中から処理を実行する前記装置を選択する選択部と、
　を有する、
　選択装置。」
［相違点１］
　本願発明１の「記憶部」は、「装置の
接続経路を示す接続経路
［相違点２］
　本願発明１の「選択部」は、「前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し」ているのに対して、引用発明の「クラウド候補選択部６３」は、「一のデータを用いる処理を複数の前記装置に実行させる場合」に、「データの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置」を選択していない点。
［相違点３］
　本願発明１では、「前記装置の移動情報を取得する移動情報取得部を有し」、「前記選択部は、複数の前記装置のうちの前記移動情報取得部が取得した前記移動情報が所定の条件を満たす前記装置の中から、処理を実行する前記装置を選択し」ているのに対して、引用発明では、「移動情報」を取得して選択に用いていない点。
［相違点４］
　本願発明１では、「前記選択部は、過去に処理を依頼した際の情報に基づいて、過去に実行した処理に用いられたデータと共通するデータを用いる処理を同一の前記装置が実行するよう前記装置の選択を行うこと」「により、同一のデータを用いる複数の処理を同一の装置が実行するよう」に装置を選択するのに対して、引用発明では、「共通するデータ」を用いる処理を「同一の装置」が実行するように装置を選択していない点。
［相違点５］
　本願発明１では、「前記選択部は、過去に処理を依頼した際の情報に基づいて」、「処理に用いるデータの一部が同一である共通性がある処理を同一の前記装置が実行するよう前記装置の選択を行うことにより、同一のデータを用いる複数の処理を同一の装置が実行するよう」に装置を選択するのに対して、引用発明では、「データの一部が同一である共通性がある処理」を「同一の装置」が実行するように装置を選択していない点。
（２）　相違点についての判断
　事案に鑑みて、上記［相違点２］について検討する。
　本願発明１の上記［相違点２］に係る、「前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し」ている構成、要するに、同一のデータを用いる処理を実行する複数の装置を、データの格納場所と前記装置との間の経路が少なくとも一部共通するように選択する構成は、上記相違点２に関連して原査定で引用された上記引用文献２−３を含む、上記引用文献２−８には記載されておらず、また、周知技術であるとも認められない。
　すなわち、上記「第３」の「２．（７）」のとおり、上記［相違点２］に関連して引用された「引用文献２」には、大規模なデータを多数のコンピュータで分散処理する場合には、データをコンピュータ間で移動させるコストが高くなるため、データの移動をなるべく抑える必要があるという課題が公知であること、及び、分散処理を統括するコンピュータであるマスタノード１０から各スレーブノード２０までの経路情報を用いて、処理される複数のデータブロックが、一のスイッチ３０に直接つながっている複数のスレーブノード２０に分散配置されるように構成するという技術的事項が開示されていると認められるが、同一のデータを用いる処理を実行する複数の装置を、データの格納場所と前記装置との間の経路が少なくとも一部共通するように選択する構成は記載されていない。
　上記「第３」の「３．（６）」のとおり、上記相違点２に関連して引用された「引用文献３」には、映画データ、音楽データ、文書データなどの「コンテンツデータ」を「コンテンツホルダ」から取得する際、効率的な経路でノード装置間の通信を行ってネットワーク負荷を低減するために、より具体的には、自装置とネットワーク的により近い「コンテンツホルダ」を優先的に選択するために、特定の装置（コンタクトサーバ１０）から自装置までの経路（「第１中継アドレス」）との一致度の高い、特定の装置（コンタクトサーバ１０）から「コンテンツホルダ」までの経路（「第２中継アドレス」）を持つ「コンテンツホルダ」をデータの提供元として選択するという技術的事項が開示されているが、同一のデータを用いる処理を実行する複数の装置を、データの格納場所と前記装置との間の経路が少なくとも一部共通するように選択する構成は記載されていない。
　したがって、上記［相違点２］に係る、「前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し」ている構成は、当業者であっても、引用発明、引用文献２−８に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
　よって、本願発明１は、当業者であっても、引用発明、引用文献２−８に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
２．本願発明２−４について
　本願発明２は、本願発明１を減縮した発明であり、本願発明３、４は、それぞれ、本願発明１に対応する方法及びプログラムの発明であり、本願発明１の上記［相違点２］に係る、「前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し」ている構成と同様の構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明、引用文献２−８に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
第５　原査定の概要及び原査定についての判断
　原査定（平成３０年１０月１１日付け拒絶査定）の概要は次のとおりである。
理由１　本願の請求項１−９に係る発明は、上記引用文献１−６に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　しかしながら、上記理由１について、令和２年６月１１日付け手続補正により補正された請求項１は、上記「前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し」ているという事項を有するものとなっているから、上記のとおり、本願発明１は、上記引用発明、引用文献２−６に記載された技術的事項に基づいて容易に発明できたものではない。
　また、同様に、令和２年６月１１日付け手続補正により補正された請求項２−４は、上記「前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し」ているという構成に対応する事項を有するものとなっているから、本願発明２は、上記引用発明、引用文献２−６に記載された技術的事項に基づいて容易に発明できたものではない。
　したがって、原査定を維持することはできない。
第６　当審拒絶理由（特許法第３６条第６項第２号）について
　当審では、（１）請求項１（及び請求項２−８）について「前記選択部は、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する前記装置を、当該処理を実行する前記装置として選択し」との記載では、「どの経路」と、経路が少なくとも一部が共通するのかが把握できない旨、（２）請求項７には「前記選択
部
部
同一のデータを用いる処理を複数の前記装置に実行させる場合、
複数の
手段
第７　むすび
　以上のとおり、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。