• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 H04L
審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1363785
審判番号 不服2019-453  
総通号数 248 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2020-08-28 
種別 拒絶査定不服の審決 
審判請求日 2019-01-15 
確定日 2020-07-22 
事件の表示 特願2017- 43519「選択装置、装置選択方法、プログラム」拒絶査定不服審判事件〔平成30年 9月20日出願公開、特開2018-148477、請求項の数(4)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、平成29年3月8日の出願であって、平成30年3月30日付けで拒絶理由通知がされ、平成30年5月23日に手続補正がされ、平成30年10月11日付けで拒絶査定(原査定)がされ、これに対し、平成31年1月15日に拒絶査定不服審判の請求がされると同時に手続補正がされ、その後、平成31年3月4日に前置報告がされ、令和2年4月17日付けで当審より拒絶理由が通知され、令和2年6月11日に手続補正がされたものである。

第2 本願発明
本願請求項1-4に係る発明(以下、それぞれ「本願発明1」-「本願発明4」という。)は、令和2年6月11日付けの手続補正で補正された特許請求の範囲の請求項1-4に記載された事項により特定される発明であり、本願発明1は以下のとおりの発明である。

「【請求項1】
装置の接続経路を示す接続経路情報を記憶する記憶部と、
複数の前記装置の中から処理を実行する前記装置を選択する選択部と、
を有し、
前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し、
前記装置の移動情報を取得する移動情報取得部を有し、
前記選択部は、複数の前記装置のうちの前記移動情報取得部が取得した前記移動情報が所定の条件を満たす前記装置の中から、処理を実行する前記装置を選択し、
前記選択部は、過去に処理を依頼した際の情報に基づいて、過去に実行した処理に用いられたデータと共通するデータを用いる処理を同一の前記装置が実行するよう前記装置の選択を行うこと、および、処理に用いるデータの一部が同一である共通性がある処理を同一の前記装置が実行するよう前記装置の選択を行うことにより、同一のデータを用いる複数の処理を同一の装置が実行するよう、処理を実行する前記装置を選択する
選択装置。」

なお、本願発明2-4の概要は以下のとおりである。

本願発明2は、本願発明1を減縮した発明である。

本願発明3、4は、それぞれ、本願発明1に対応する方法及びプログラムの発明であり、本願発明1とカテゴリ表現が異なるだけの発明である。

第3 引用文献、引用発明等
1.引用文献1及び引用発明
原査定の拒絶の理由に引用された引用文献1(特開2012-053853号公報)には、図面とともに次の事項が記載されている(下線は、特に着目した箇所を示す。以下同様。)。

(1) 段落【0007】-【0008】
「【0007】
本発明は、上記課題に鑑み、ユーザの目的に応じてクラウドサービスを動的に選択することができる情報処理装置、情報処理システム、サービス提供機器決定方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【0008】
上記課題に鑑み、本発明は、提供可能なサービスの種類及びサービスレベル情報を公開するサービス提供機器と、前記サービス提供機器を検出するサービス提供機器検出手段と、前記サービス提供機器から提供可能なサービスの種類が含まれるサービス種類情報及びサービスレベル情報を収集するサービス提供機器情報収集手段と、ネットワークを介して接続された情報処理装置であって、サービスの種類の入力を受け付けるサービス受け付け手段と、前記サービス提供機器の選択方針を受け付けるサービス選択方針取得手段と、前記サービス受け付け手段が受け付けたサービスを提供可能な前記サービス提供機器を前記サービス種類情報に基づき決定する候補機器選択手段と、前記候補機器選択手段が選択した前記サービス提供機器から1つ以上の前記サービス機器を前記選択方針に従って決定するサービス機器決定手段と、を有することを特徴とする。」

(2) 段落【0011】-【0014】
「【発明を実施するための形態】
【0011】
以下、本発明を実施するための形態について図面を参照しながら説明する。
【0012】
図1は、本実施形態の情報処理システムの概略を説明する図の一例である。クラウドサービス情報収集機23と各種の機器がネットワークを介して接続されている。ユーザは機器の1つ(デバイス24とする)を操作してサービスの提供を受けるが、クラウドサービス機器20の機能を利用するか、どこにどのようなクラウドサービス機器20があるか等を意識する必要がない。すなわち、図1の情報処理システム100はクラウドコンピューティングと呼ばれる態様でサービスを提供する。
【0013】
処理のおよその流れを説明する。
(1)クラウドサービス情報収集機23は、例えば定期的にネットワークを介して接続されたクラウドサービス機器20と通信し、機器が提供可能な「利用可能サービス」、機器の「SLA情報」を収集する。そして、SLA情報を「SLA評価ポイント」に変換する。
(2)ユーザは、自分のユーザポリシーを例えばデバイス24を操作して設定しておく。設定されたユーザポリシーは、デバイス24又はクラウドサービス情報収集機23に記憶される。
(3)ユーザは、サービスの提供を受ける際、デバイス24を操作して処理フローを入力する。処理フローは、処理の具体的な内容であり、利用可能サービスの組み合わせと言える。
(4)デバイス24は、クラウドサービス情報収集機23から利用可能サービス及びSLA評価ポイントをダウンロードする。
(5)そして、デバイス24は、処理フローに含まれる処理が可能なクラウドサービス機器20を利用可能サービスを参照して決定する。また、決定したクラウドサービス機器20の中から、ユーザポリシーに適合するクラウドサービス機器20をSLA評価ポイントに基づき選別する。
【0014】
単純な処理フローではクラウドサービス機器20が1台の場合もあるが、処理フローが複雑になると処理フローとユーザポリシーにより複数のクラウドサービス機器20の組み合わせが決定される。」

(3) 段落【0046】-【0048】
「【0046】
図6はデバイス24の機能ブロック図の一例を示す。デバイス24は、処理フロー受け付け部61、クラウドサービス情報取得部62、クラウド候補選択部63、ポイント算出部64、処理フロー実行部65、クラウドサービス登録受け付け部66、ポリシー受け付け手段68、及び、ポリシーDB67を有する。ポリシーDB67はユーザポリシーを記憶するDBであり、例えばデバイスBのHDD113などを実体とする。
【0047】
処理フロー受け付け部61は、ユーザが選択した処理フローの設定を受け付ける。
クラウドサービス情報取得部62は、クラウドサービス情報収集機23から利用可能サービスとSLA情報を取得する。クラウド候補選択部63は、処理フローに含まれる各処理と利用可能サービスに基づきサービスを提供可能なクラウドサービス機器20の組み合わせ候補を選定する。クラウドサービス決定部64は、クラウドサービス機器20の組み合わせ候補について、SLA情報を用いて総合ポイントの平均と種別ポイントの平均を算出し、算出結果とポリシーDB67に記憶されたユーザポリシーに基づき、クラウドサービス機器20の組み合わせ候補からユーザポリシーに合致したクラウドサービス機器20の組み合わせを決定する。
【0048】
処理フロー実行部65は、決定されたクラウドサービス機器20の組み合わせに基づき処理フローを実行する。クラウドサービス登録受け付け部66は、クラウドサービス情報収集機23が利用可能サービスとSLA情報を収集できないクラウドサービス情報機器20を、管理者が個別に設定できるようにする。クラウドサービス登録受け付け部66は、管理者が設定したクラウドサービス機器20をクラウドサービス情報収集機23に送信するので、この後ユーザは、他のクラウドサービス機器20と同様に登録したクラウドサービス機器20を利用することができる。ポリシー受け付け手段68は、ユーザが設定するユーザポリシーを受け付け、ポリシーDB67に登録する。」

(4) 段落【0101】-【0103】
「【0101】
図17は、クラウドサービス機器20の組み合わせ候補から、クラウドサービス決定部64がユーザポリシーに従い、クラウドサービス機器20の組み合わせを選択する手順を説明する図の一例である。
【0102】
ユーザCCCのユーザポリシーは、図12のユーザポリシーに設定したとおりである(可用性ポイント34以上、信頼性ポイント28以上、条件外は問い合わせ)。
【0103】
クラウドサービス機器20の組み合わせ候補No1?No4のうち、可用性ポイントが34以上なのはNo1の組み合わせであり、信頼性ポイントが28以上なのはNo1の組み合わせである。このため、クラウドサービス決定部64は、クラウドサービス機器20の組み合わせ候補No1?No4のうち、ユーザCCCの条件に合致する組み合わせとして、No1の組み合わせを選択する。従って、処理フローを実行する各主体は、IデバイスB→IIサーバC→IIIサーバH→IVサーバBとなる。」

(5) したがって、上記引用文献1には次の発明(以下、「引用発明」という。)が記載されていると認められる。

「ユーザの目的に応じてクラウドサービスを動的に選択することができる情報処理装置であって、
クラウドサービス情報収集機23と各種の機器がネットワークを介して接続され、ユーザは機器の1つ(デバイス24)を操作してサービスの提供を受け、
処理のおよその流れは、
(1)クラウドサービス情報収集機23は、定期的にネットワークを介して接続されたクラウドサービス機器20と通信し、機器が提供可能な「利用可能サービス」、機器の「SLA情報」を収集して、SLA情報を「SLA評価ポイント」に変換し、
(2)ユーザは、自分のユーザポリシーを例えばデバイス24を操作して設定し、設定されたユーザポリシーは、デバイス24又はクラウドサービス情報収集機23に記憶され、
(3)ユーザは、サービスの提供を受ける際、デバイス24を操作して処理フローを入力し、処理フローは、処理の具体的な内容であり、利用可能サービスの組み合わせと言え、
(4)デバイス24は、クラウドサービス情報収集機23から利用可能サービス及びSLA評価ポイントをダウンロードし、
(5)そして、デバイス24は、処理フローに含まれる処理が可能なクラウドサービス機器20を利用可能サービスを参照して決定し、また、決定したクラウドサービス機器20の中から、ユーザポリシーに適合するクラウドサービス機器20をSLA評価ポイントに基づき選別し、
処理フローが複雑になると処理フローとユーザポリシーにより複数のクラウドサービス機器20の組み合わせが決定されるものであり、
デバイス24は、処理フロー受け付け部61、クラウドサービス情報取得部62、クラウド候補選択部63、ポイント算出部64、処理フロー実行部65、クラウドサービス登録受け付け部66、ポリシー受け付け手段68、及び、ポリシーDB67を有し、
クラウドサービス情報取得部62は、クラウドサービス情報収集機23から利用可能サービスとSLA情報を取得し、
クラウド候補選択部63は、処理フローに含まれる各処理と利用可能サービスに基づきサービスを提供可能なクラウドサービス機器20の組み合わせ候補を選定し、
クラウドサービス決定部64は、クラウドサービス機器20の組み合わせ候補について、SLA情報を用いて総合ポイントの平均と種別ポイントの平均を算出し、算出結果とポリシーDB67に記憶されたユーザポリシーに基づき、クラウドサービス機器20の組み合わせ候補からユーザポリシーに合致したクラウドサービス機器20の組み合わせを決定し、
クラウドサービス機器20の組み合わせ候補から、クラウドサービス決定部64がユーザポリシーに従い、クラウドサービス機器20の組み合わせを選択する手順において、
ユーザCCCのユーザポリシーは、ユーザポリシーに設定したとおりであり(可用性ポイント34以上、信頼性ポイント28以上、条件外は問い合わせ)、
クラウドサービス機器20の組み合わせ候補No1?No4のうち、可用性ポイントが34以上なのはNo1の組み合わせであり、信頼性ポイントが28以上なのはNo1の組み合わせであるため、クラウドサービス決定部64は、クラウドサービス機器20の組み合わせ候補No1?No4のうち、ユーザCCCの条件に合致する組み合わせとして、No1の組み合わせを選択する、
デバイス24。」

2.引用文献2について
また、原査定の拒絶の理由に引用された引用文献2(特開2010-244469号公報)には、図面とともに、以下の記載がある。

(1) 段落【0004】
「【発明が解決しようとする課題】
【0004】
大規模なデータを多数のコンピュータで分散処理する場合には、データをコンピュータ間で移動させるコスト(遅延や通信時間など)の方が演算機能(プロセスなど)を移動させるコストよりも高くなる。例えば、マップリデュース(MapReduce)によるソーティング処理では、一般に、処理の中間結果(中間データ)をネットワーク内で移動させる際のオーバヘッドが大きくなってしまう。そのため、データの移動をなるべく抑える必要がある。」

(2) 段落【0017】-【0026】
「【0017】
分散処理システム1は、マップリデュース(MapReduce)というプログラミングモデルを用いて分散処理を実行するコンピュータシステムである。この分散処理システム1は、図1に示すように、1個のマスタノード10と、複数のスレーブノード20と、各ノード間を接続する複数のネットワークスイッチ(以下では単に「スイッチ」という)30とを備えている。マスタノード10は分散処理を統括するコンピュータであり、スレーブノード20はデータを実際に処理するコンピュータである。スイッチ30は、ノード間で伝送されるデータを中継する装置であり、例えばL2スイッチ、L3スイッチ、ルータなどである。


・・・(中略)・・・

【0022】
取得処理の詳細は次の通りである。まず、取得部11は各スイッチ30から構成情報を取得するための要求信号を生成し、各スイッチ30に送信する。そして、取得部11はその要求に応じて各スイッチ30から送られてきた構成情報を取得し、算出部12に出力する。ここで、構成情報とは、スイッチ30を識別するスイッチIDと、スイッチ30に直接接続されているノードを識別するノードIDのリストとを含む情報である。また、各IDは、識別番号やコンピュータ名、IPアドレスなどにより表現することができる。構成情報の取得方法としては、例えばSNMP(Simple Network Management Protocol)のrequest/responseメッセージの利用が可能である。また、構成情報はMIB(ManagementInformation Base)に含まれる情報であってもよい。
【0023】
次に、取得部11は各スレーブノード20に対して、例えばトレースルート(traceroute)コマンドを発行することで、マスタノード10からスレーブノード20までの経路を示す経路情報を取得する。この経路情報には、経路の終点であるスレーブノード20を識別するノードIDと、そのスレーブノード20に至るまでに経由したスイッチ30のスイッチIDとが含まれる。取得部11は各スレーブノード20について取得した経路情報を算出部12に出力する。

・・・(中略)・・・

【0026】
算出部12は、すべての接続情報に基づいて上記の処理を実行し、各スイッチ30にどのスレーブノード20が直接接続されているかを算出する。このとき算出される各スレーブノード群(グループ)は、一のラックRに格納されている一以上のスレーブノード20に対応する。この対応関係を利用して、算出部12はグループを識別するためのラックIDを各グループに割り当てる。そして、算出部12は算出結果(判定結果)をグループ情報記憶部13に出力する。」

(3) 段落【0032】
「【0032】
処理制御部17は、分散処理を実行する複数のスレーブノード20のうちの一つをリデューサー(Reducer)として決定し、そのReducerの識別情報を各スレーブノード20に送信する部分である。まず、処理制御部17は入力されたデータ情報に対応する複数の配置情報を配置情報記憶部16から読み出し、これらの配置情報に基づいて、Reducerとなる一のスレーブノード20を選択する。Reducerの選択方法は一つに限定されるものではないが、処理制御部17は記憶しているデータブロックの個数が最も多いグループから一つのスレーブノード20を選択するのが好ましい。処理制御部17は、入力されたアプリケーション情報と、選択されたスレーブノード20のノードI
D(以下では「Reducer情報」という)とをすべてのスレーブノード20に送信する。」

(4) 段落【0038】
「【0038】
処理部23は、データブロックをMap処理して、演算結果データを生成する。そして、当該演算結果データの一部ごとにReduce処理を行う。その際、処理部23は、Reducer情報に対応するグループ情報をグループ情報記憶部22から読み出し、当該Reducerと同じグループ内に存在するスレーブノード20を選択する。なお、このときの選択方法は限定されない。そして、処理部23は、演算結果データの一部及び選択したスレーブノード20のノードIDを結果送信部24に出力する。処理部23は、このような選択及び出力処理を、演算結果データに対する処理がすべて終了するまで繰り返し実行する。なお、出力される演算結果データは、更なる処理が必要なデータブロック(被分割データ)であるといえる。」

(5) 段落【0042】
「【0042】
まず、図6を用いて、グループ情報の算出手順を説明する。マスタノード10において、取得部11が各スイッチ30に対して構成情報を要求し、その要求に応じて送信されてきた構成情報を取得する(ステップS11、取得ステップ)。また、取得部11は各スレーブノード20と通信することで経路情報を取得する(ステップS12、取得ステップ)。続いて、算出部12がこれらの構成情報及び経路情報に基づいて、各スイッチ30にどのスレーブノード20が直接接続されているかを算出する(ステップS13、算出ステップ)。この算出結果は、グループ情報としてグループ情報記憶部13に記憶されると共に(ステップS14)、グループ情報送信部14により各スレーブノード20に送信される(ステップS15)。」

(6) 段落【0047】
「【0047】
以上説明したように、本実施形態によれば、分散処理システム1内の各スレーブノード20及びスイッチ30と通信することで、スレーブノード20とスイッチ30との間の接続関係が取得され、この関係に基づいて、各スイッチ30にどのスレーブノード20が直接接続されているかが導出される。そして、処理される複数のデータブロックが、一のスイッチ30に直接つながっている一又は複数のスレーブノード20に配置される。これにより、データが複数のスイッチ30を跨いで分散配置されることがなくなるので、分散処理時にネットワーク上を流れるデータの量を低減でき、ひいては、分散処理の速度を向上させることができる。」

(7) したがって、上記引用文献2には、大規模なデータを多数のコンピュータで分散処理する場合には、データをコンピュータ間で移動させるコストが高くなるため、データの移動をなるべく抑える必要があるという課題が公知であること、及び、分散処理を統括するコンピュータであるマスタノード10から各スレーブノード20までの経路情報を用いて、処理される複数のデータブロックが、一のスイッチ30に直接つながっている複数のスレーブノード20に分散配置されるように構成するという技術的事項が開示されていると認められる。

3.引用文献3について
原査定の拒絶の理由に引用された引用文献3(特開2011-055139号公報)には、図面とともに、以下の記載がある。

(1) 段落【0009】-【0010】
「【0009】
本発明は、上述したような課題に鑑みてなされたものであり、効率的な経路でのノード装置間の通信を行って、ネットワークの通信負荷を低減することができる情報通信システム、ノード装置及びそのプログラム、並びにコンテンツ取得方法を提供することを目的とする。
【課題を解決するための手段】
【0010】
上記目的を達成するために、請求項1に係る発明は、複数のコンテンツデータを分散して保存する複数のノード装置から構成される情報通信システムであって、前記ノード装置は、ネットワークに接続された特定装置へ向けてメッセージを送信するメッセージ送信手段と、前記メッセージ送信手段により送信されたメッセージを前記特定装置まで中継する中継装置のネットワークアドレスを示す第1中継アドレスを取得する情報取得手段と、前記複数のノード装置に分散して記憶されたコンテンツデータの中から、所定のコンテンツデータを要求する要求手段と、前記要求手段により要求されるコンテンツデータを記憶している各ノード装置から前記特定装置までのネットワーク上の経路に位置する前記中継装置のネットワークアドレスを示す第2中継アドレスを取得する第2情報取得手段と、前記コンテンツデータを記憶している複数のノード装置のうち、前記第2中継アドレスと、前記第1中継アドレスとの一致度が高いノード装置から前記所定のコンテンツデータを取得するコンテンツ取得手段と、を備えることを特徴とする。」

(2) 段落【0018】
「【発明の効果】
【0018】
本発明によれば、各ノード装置は、取得しようとするコンテンツデータを記憶している他のノード装置のうちネットワーク的に近い他のノード装置を優先的に選択し、このように選択した他のノード装置からコンテンツデータを取得する。従って、ネットワークでの
総トラフィック量を軽減することができ、通信負荷を軽減することが可能となる。」

(3) 段落【0022】
「【0022】
情報通信システムSは、コンテンツデータを配信するためのシステムである。図1の上部枠50内に示すように、ネットワーク8を介して相互に接続された複数のノード装置1a,1b,1c,1d,・・・と、コンタクトサーバ10とを備えて、情報通信システムSは構成される。これらの装置には、各装置を示す情報としての固有の製造番号(例えば、MACアドレス)及びネットワークアドレスが割り当てられている。なお、製造番号及びネットワークアドレスは、複数の装置間で重複しないものである。ネットワーク8がインターネットの場合、ネットワークアドレスは、IP(Internet Protocol)アドレスである。また、以下の説明において、ノード装置1a,1b,1c,1d,・・のうち何れかのノード装置又は全てのノード装置を示す場合には、便宜上、ノード装置1という場合がある。また、コンテンツデータは、例えば、映画データ、音楽データ、文書データなどである。コンタクトサーバ10は、各ノード装置1からの問い合わせメッセージに応答して、応答メッセージを返信する。各ノード装置1は、後述するように、応答メッセージを受信することにより、コンタクトサーバ10までのネットワーク8上の経路情報を取得することができる。そして、この経路情報は、コンテンツデータを要求するノード装置1を決定する際に用いられる。」

(4) 段落【0027】-【0028】
「【0027】
[2.1.各ノード装置1における経路情報の取得]
まず、各ノード装置1a?1cは、図3に示すように、ネットワーク8に接続されたコンタクトサーバ10へ向けて問い合わせメッセージを送信する。そして、各ノード装置1a?1cは、この問い合わせメッセージをコンタクトサーバ10まで中継する中継装置のネットワークアドレスを取得して記憶する。以下、これらのネットワークアドレスを、「第1中継アドレス」と呼ぶ。
【0028】
この第1中継アドレスは、各ノード装置1からコンタクトサーバ10までのネットワーク8上の経路情報である。すなわち、ノード装置1aとコンタクトサーバ10との間には、中継装置11,12が存在しており、ノード装置1aは、中継装置11,12のそれぞれのネットワークアドレスを取得して記憶する。そして、この2つの中継装置11,12のネットワークアドレスが、ノード装置1aの第1中継アドレスである。また、同様に、ノード装置1bとコンタクトサーバ10との間には、中継装置11,12が存在しており、ノード装置1bは、中継装置11,12のそれぞれのネットワークアドレスを取得して記憶する。そして、この2つの中継装置11,12のネットワークアドレスが、ノード装置1bの第1中継アドレスである。また、ノード装置1cとコンタクトサーバ10との間には、中継装置11,13,14とが存在しており、ノード装置1cは、中継装置11,13,14のそれぞれのネットワークアドレスを取得して記憶する。そして、この3つの中継装置11,13,14のネットワークアドレスが、ノード装置1cの第1中継アドレスである。」

(5) 段落【0045】-【0046】
「【0045】
図2に示す例では、リクエスタであるノード装置1aは、コンテンツホルダであるノード装置1b,1cの記憶手段に記憶されている第1中継アドレスを取得して、第2中継アドレスとして記憶手段に記憶する。ノード装置1bの記憶手段に記憶されている第1中継アドレスは、中継装置11,12のネットワークアドレスであり、ノード装置1cの記憶手段に記憶されている第1中継アドレスは、中継装置11,13,14のネットワークアドレスである。従って、ノード装置1aは、中継装置11,12のネットワークアドレスをノード装置1bの第2中継アドレスとして記憶手段に記憶し、中継装置11,13,14のネットワークアドレスをノード装置1cの第2中継アドレスとして記憶手段に記憶する。このように、リクエスタは、コンテンツホルダから送信されるこのコンテンツホルダの第1中継アドレスを、コンテンツホルダの第2中継アドレスとして取得する。
【0046】
次に、リクエスタは、記憶手段に記憶している第1中継アドレスと第2中継アドレスとを比較する。そして、リクエスタは、第1中継アドレスと一致度が高い第2中継アドレスを送信したコンテンツホルダからコンテンツデータを取得する。ここで、「一致度が高い」とは、両中継アドレスに共通するネットワークアドレスの数が多く、共通していないネットワークアドレスの数が少ないことを意味する。」

(6) したがって、上記引用文献3には、映画データ、音楽データ、文書データなどの「コンテンツデータ」を「コンテンツホルダ」から取得する際、効率的な経路でノード装置間の通信を行ってネットワーク負荷を低減するために、より具体的には、自装置とネットワーク的により近い「コンテンツホルダ」を優先的に選択するために、特定の装置(コンタクトサーバ10)から自装置までの経路(「第1中継アドレス」)との一致度の高い、特定の装置(コンタクトサーバ10)から「コンテンツホルダ」までの経路(「第2中継アドレス」)を持つ「コンテンツホルダ」をデータの提供元として選択するという技術的事項が開示されていると認められる。

4.引用文献4について
原査定において周知技術を示す文献として引用された引用文献4(特開2005-136909号公報)には、アドホックネットワークなどの無線通信システムにおける基地局の決定において(【0001】-【0002】)、無線端末同士の通信ルート中に、無線通信の切断が生じる可能性の高い不安定なものが存在するという問題点に対処するために(【0006】)、自端末の移動速度を測定して、移動速度が所定の速度以上(例えば5km/h以上)の無線端末は、無線通信の制御を行う基地局にならない(【0012】)という技術的事項が開示されていると認められる。

5.引用文献5について
原査定において周知技術を示す文献として引用された引用文献5(特開2009-159457号公報)には、アドホック通信システムにおいて(【0001】)、アドホック通信システムを形成する無線端末は、他の無線端末同士を中継する中継機能を提供しているため,常に動作している必要があり、消費電力を抑えることができないという問題点に対処するために(【0007】)、送信元端末装置は、各アドホック中継装置3-10の一定時間内の緯度・経度の変化に基づいて、各中継装置の移動速度を算出し、移動速度が閾値よりも大きい中継装置は、移動中であるか、端末グループから抜けるかも知れないと推定して、(例えば現時点から60分後に)休止状態になるように指令して、他の中継装置を用いる他の中継ルートに切り替える(【0046】-【0048】)という技術的事項が記載されていると認められる。

6.引用文献6について
原査定の拒絶の理由に引用された引用文献6(特開2006-031096号公報)には、複数の処理サーバを有する分散処理システムにおいて(【0001】)、サービス負荷の最も少ない時間に、あらかじめ設定した項目等に基づいて再起動を行うサーバを選択することで、サービスを停止させずにサーバを再起動する分散処理システムにおいて(【0010】)、同一処理内容を複数の処理サーバで実行することによって負荷分散を実現する(【0028】-【0029】)という技術的事項が記載されていると認められる。

7.前置報告で引用された引用文献7について
前置報告において周知技術を示す文献として引用された引用文献7(特開2005-310120号公報)には、複数の計算機から構成される計算機システムにおいて、複数のタスクを処理する際に、特定のタスクをどの計算機に割り当てて処理を行うかを決定する技術において(【0001】)、個々の計算機の負荷情報だけによる判断では最適なタスクの割当ができず、結果として実行効率の悪いタスク割当をしてしまうことがあるという問題点に対処するために(【0004】)、個々の計算機の負荷情報だけでなく、個々の計算機で実行中のタスク、割り当てられるタスクと他のタスク間の関連度、計算機のネットワーク上での距離も考慮してタスクの割当を行うこと(【0005】)、より具体的には、タスク割当計算機102には、負荷情報(211)、実行中タスク情報(212)、計算機間の距離情報(214)および、タスク間の関連度情報(213)とともに、タスクの割り当て結果を記録する「割当履歴情報」(215。タスクの割当てを行った時刻、当該タスクの終了時刻、割当て先計算機名とIPアドレスとポート番号、割り当てたタスク名からなる。)が格納されること(【0011】、【0030】、【図1】、【図19】)、「割当履歴情報(215)」は、「タスク間の関連度情報」(213)を更新する際に用いられるデータであって(【0028】)、例えば、タスク間の通信データ量の合計を求める際、「通信履歴情報」から送信元と送信先の計算機を特定し、「割当履歴情報」から、送信元/送信先計算機それぞれにおいて、その通信時に実行されていたタスクを特定していること(【0032】)。そして、例えば、各タスク処理計算機間の通信データ量「100KB」を、タスク間の関連度情報「1」として換算する(【0035】)という技術的事項が記載されていると認められる。

8.前置報告で引用された引用文献8について
前置報告において周知技術を示す文献として引用された引用文献8(特開2010-134518号公報)には、決裁などの業務処理を実行する、複数の計算機を含む計算機システムの構成管理において(【0001】-【0002】)、サーバ1の負荷が所定の上限値を超えた場合、前記サーバ1で実行中のサービスの一部(S3,S4)を、転送先のサーバ4に移し(「スケールアウト処理」)(【0010】、【0051】)、サービスの移動する際は、「共通のテーブル」を利用して、処理すべき複数のサービスの負荷合計が均等に分かれるようにグループ化した「サービスグループ」単位で行う(【0079】、【図9】-【図10】)という技術的事項が記載されていると認められる。

第4 対比・判断
1.本願発明1について
(1) 対比
本願発明1と引用発明とを対比すると、次のことがいえる。

ア 引用発明の「デバイス24」における「クラウドサービス情報取得部62」は、「クラウドサービス情報収集機23から利用可能サービスとSLA情報を取得し」ており、クラウドサービス情報収集機23が「複数のクラウドサービス装置20」から収集した情報を取得した後に、少なくとも一時的に「記憶」していることは明らかであるから、本願発明1の「装置の接続経路を示す接続経路情報を記憶する記憶部」と、「装置の情報を記憶する記憶部」である点で共通するといえる。

イ 引用発明の「デバイス24」における「クラウド候補選択部63」は、「処理フローに含まれる各処理と利用可能サービスに基づきサービスを提供可能なクラウドサービス機器20の組み合わせ候補を選定し」ているから、本願発明1の「複数の前記装置の中から処理を実行する前記装置を選択する選択部」に相当する。

ウ 引用発明の「デバイス24」は、「ユーザの目的に応じてクラウドサービスを動的に選択することができる情報処理装置であ」るから、本願発明1の「選択装置」に相当する。

よって、本願発明1と引用発明との一致点・相違点は次のとおりであるといえる。

[一致点]
「装置の情報を記憶する記憶部と、
複数の前記装置の中から処理を実行する前記装置を選択する選択部と、
を有する、
選択装置。」

[相違点1]
本願発明1の「記憶部」は、「装置の接続経路を示す接続経路情報を記憶する記憶部」であるのに対して、引用発明では、他装置の「利用可能サービスとSLA情報を取得し」て記憶するものであって、接続経路は記憶していない点。

[相違点2]
本願発明1の「選択部」は、「前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し」ているのに対して、引用発明の「クラウド候補選択部63」は、「一のデータを用いる処理を複数の前記装置に実行させる場合」に、「データの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置」を選択していない点。

[相違点3]
本願発明1では、「前記装置の移動情報を取得する移動情報取得部を有し」、「前記選択部は、複数の前記装置のうちの前記移動情報取得部が取得した前記移動情報が所定の条件を満たす前記装置の中から、処理を実行する前記装置を選択し」ているのに対して、引用発明では、「移動情報」を取得して選択に用いていない点。

[相違点4]
本願発明1では、「前記選択部は、過去に処理を依頼した際の情報に基づいて、過去に実行した処理に用いられたデータと共通するデータを用いる処理を同一の前記装置が実行するよう前記装置の選択を行うこと」「により、同一のデータを用いる複数の処理を同一の装置が実行するよう」に装置を選択するのに対して、引用発明では、「共通するデータ」を用いる処理を「同一の装置」が実行するように装置を選択していない点。

[相違点5]
本願発明1では、「前記選択部は、過去に処理を依頼した際の情報に基づいて」、「処理に用いるデータの一部が同一である共通性がある処理を同一の前記装置が実行するよう前記装置の選択を行うことにより、同一のデータを用いる複数の処理を同一の装置が実行するよう」に装置を選択するのに対して、引用発明では、「データの一部が同一である共通性がある処理」を「同一の装置」が実行するように装置を選択していない点。

(2) 相違点についての判断
事案に鑑みて、上記[相違点2]について検討する。
本願発明1の上記[相違点2]に係る、「前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し」ている構成、要するに、同一のデータを用いる処理を実行する複数の装置を、データの格納場所と前記装置との間の経路が少なくとも一部共通するように選択する構成は、上記相違点2に関連して原査定で引用された上記引用文献2-3を含む、上記引用文献2-8には記載されておらず、また、周知技術であるとも認められない。
すなわち、上記「第3」の「2.(7)」のとおり、上記[相違点2]に関連して引用された「引用文献2」には、大規模なデータを多数のコンピュータで分散処理する場合には、データをコンピュータ間で移動させるコストが高くなるため、データの移動をなるべく抑える必要があるという課題が公知であること、及び、分散処理を統括するコンピュータであるマスタノード10から各スレーブノード20までの経路情報を用いて、処理される複数のデータブロックが、一のスイッチ30に直接つながっている複数のスレーブノード20に分散配置されるように構成するという技術的事項が開示されていると認められるが、同一のデータを用いる処理を実行する複数の装置を、データの格納場所と前記装置との間の経路が少なくとも一部共通するように選択する構成は記載されていない。
上記「第3」の「3.(6)」のとおり、上記相違点2に関連して引用された「引用文献3」には、映画データ、音楽データ、文書データなどの「コンテンツデータ」を「コンテンツホルダ」から取得する際、効率的な経路でノード装置間の通信を行ってネットワーク負荷を低減するために、より具体的には、自装置とネットワーク的により近い「コンテンツホルダ」を優先的に選択するために、特定の装置(コンタクトサーバ10)から自装置までの経路(「第1中継アドレス」)との一致度の高い、特定の装置(コンタクトサーバ10)から「コンテンツホルダ」までの経路(「第2中継アドレス」)を持つ「コンテンツホルダ」をデータの提供元として選択するという技術的事項が開示されているが、同一のデータを用いる処理を実行する複数の装置を、データの格納場所と前記装置との間の経路が少なくとも一部共通するように選択する構成は記載されていない。

したがって、上記[相違点2]に係る、「前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し」ている構成は、当業者であっても、引用発明、引用文献2-8に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
よって、本願発明1は、当業者であっても、引用発明、引用文献2-8に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

2.本願発明2-4について
本願発明2は、本願発明1を減縮した発明であり、本願発明3、4は、それぞれ、本願発明1に対応する方法及びプログラムの発明であり、本願発明1の上記[相違点2]に係る、「前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し」ている構成と同様の構成を備えるものであるから、本願発明1と同様の理由により、当業者であっても、引用発明、引用文献2-8に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

第5 原査定の概要及び原査定についての判断
原査定(平成30年10月11日付け拒絶査定)の概要は次のとおりである。

理由1 本願の請求項1-9に係る発明は、上記引用文献1-6に記載された発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

しかしながら、上記理由1について、令和2年6月11日付け手続補正により補正された請求項1は、上記「前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し」ているという事項を有するものとなっているから、上記のとおり、本願発明1は、上記引用発明、引用文献2-6に記載された技術的事項に基づいて容易に発明できたものではない。
また、同様に、令和2年6月11日付け手続補正により補正された請求項2-4は、上記「前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し」ているという構成に対応する事項を有するものとなっているから、本願発明2は、上記引用発明、引用文献2-6に記載された技術的事項に基づいて容易に発明できたものではない。

したがって、原査定を維持することはできない。

第6 当審拒絶理由(特許法第36条第6項第2号)について
当審では、(1)請求項1(及び請求項2-8)について「前記選択部は、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する前記装置を、当該処理を実行する前記装置として選択し」との記載では、「どの経路」と、経路が少なくとも一部が共通するのかが把握できない旨、(2)請求項7には「前記選択部」とあるが、先行する「選択部」の記載がない旨の拒絶の理由を通知しているが、令和2年6月11日付けの補正において、(1)補正後の請求項1(及び請求項2-4)について「前記選択部は、同一のデータを用いる処理を複数の前記装置に実行させる場合、前記接続経路情報に基づいて、処理に用いるデータの格納場所と前記装置との間の経路が少なくとも一部共通する複数の前記装置を、当該処理を実行する前記装置として選択し」と補正され、(2)補正後の請求項4(補正前の請求項7に対応。)について、「前記選択手段」と補正された結果、この拒絶の理由は解消した。

第7 むすび
以上のとおり、原査定の理由によっては、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。
 
審決日 2020-07-07 
出願番号 特願2017-43519(P2017-43519)
審決分類 P 1 8・ 121- WY (H04L)
P 1 8・ 537- WY (H04L)
最終処分 成立  
前審関与審査官 中川 幸洋松崎 孝大速水 雄太  
特許庁審判長 ▲吉▼田 耕一
特許庁審判官 岩田 玲彦
稲葉 和生
発明の名称 選択装置、装置選択方法、プログラム  
代理人 唐鎌 睦  
代理人 馬場 資博  
代理人 境 廣巳  
代理人 桂木 雄二  

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