• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1373086
審判番号 不服2020-2461  
総通号数 258 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-06-25 
種別 拒絶査定不服の審決 
審判請求日 2020-02-25 
確定日 2021-04-14 
事件の表示 特願2018-121759「コスト最小化タスクスケジューラ」拒絶査定不服審判事件〔平成30年10月18日出願公開、特開2018-163697〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯

本願は,2014年2月11日(パリ条約による優先権主張外国庁受理2013年2月11日(以下,「優先日」という。),アメリカ合衆国)を国際出願日とする特願2015-557200号の一部を,平成30年6月27日に新たな特許出願としたものであって,同年9月28日付けで拒絶の理由が通知され,平成31年1月9日に意見書とともに手続補正書が提出され,令和1年5月10日付けで拒絶の理由が通知され,同年8月28日に意見書とともに手続補正書が提出されたところ,同年10月8日付けで拒絶査定(謄本送達日同年10月23日。以下,「原査定」という。)がなされ,これに対して令和2年2月25日に拒絶査定不服審判の請求がなされるとともに手続補正がなされ,同年4月3日付けで審査官により特許法164条3項の規定に基づく報告がなされたものである。


第2 令和2年2月25日にされた手続補正についての補正の却下の決定

[補正の却下の決定の結論]

令和2年2月25日にされた手続補正(以下,「本件補正」という。)を却下する。

[理由]

1 本件補正について(補正の内容)

(1)本件補正後の特許請求の範囲の記載

本件補正により,特許請求の範囲の請求項1の記載は,次のとおり補正された。(下線部は,補正箇所である。)

「リソースマネージャが、タスクの定義を受信することであって、前記定義が、必要期限時刻を含み、前記必要期限時刻が、前記タスクの実行の完了に対する期限を含む、受信することと、
前記リソースマネージャが、クラウドベースの、複数のリソースプールに体系化され且つ各前記リソースプールが関連付けられた使用量コストを有する複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を、前記タスクの一部を実行し、前記一部を実行した期間から前記一部が実行された前記タスクの合計の推定実行期間を外挿することによって決定することと、
前記リソースマネージャが、前記複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了する推定コストに基づいて、前記必要期限時刻よりも前に前記タスクの前記実行を完了するために利用可能である前記コンピューティングリソースの中から、1つ以上の前記コンピューティングリソースを選択することであって、前記推定コストは、前記複数のコンピューティングリソースの過去の価格設定変動に基づいて将来の価格設定変更を予測する予測モデルを少なくとも使用して推定される、前記選択することと、
前記リソースマネージャが、前記選択された1つ以上のコンピューティングリソースを使用して、スケジュール設定された時刻に前記タスクの前記実行を開始することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、開始することと、を含む、コンピュータ実装方法。」

(2)本件補正前の特許請求の範囲

本件補正前の,令和1年8月28日にされた手続補正により補正された特許請求の範囲の請求項1の記載は次のとおりである。

「リソースマネージャが、タスクの定義を受信することであって、前記定義が、必要期限時刻を含み、前記必要期限時刻が、前記タスクの実行の完了に対する期限を含む、受信することと、
前記リソースマネージャが、クラウドベースの、複数のリソースプールに体系化され且つ各前記リソースプールが関連付けられた使用量コストを有する複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を、前記タスクの一部を実行し、前記一部を実行した期間から前記一部が実行された前記タスクの合計の推定実行期間を外挿することによって決定することと、
前記リソースマネージャが、前記複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了する推定コストに基づいて、前記必要期限時刻よりも前に前記タスクの前記実行を完了するために利用可能である前記コンピューティングリソースの中から、1つ以上の前記コンピューティングリソースを選択することと、
前記リソースマネージャが、前記選択された1つ以上のコンピューティングリソースを使用して、スケジュール設定された時刻に前記タスクの前記実行を開始することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、開始することと、を含む、コンピュータ実装方法。」

2 補正の適否

本件補正は,本件補正前の請求項1に記載された発明を特定するために必要な事項である「推定コスト」について,上記のとおり限定を付加するものであって,本件補正前の請求項1に記載された発明と本件補正後の請求項1に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるから,特許法17条の2第5項2号の特許請求の範囲の減縮を目的とするものに該当する。
そこで,本件補正後の請求項1に記載される発明(以下,「本件補正発明」という。)が同条6項において準用する同法126条7項の規定に適合するか(特許出願の際独立して特許を受けることができるものであるか)について,以下,検討する。

(1)本件補正発明

本件補正発明は,上記1(1)に記載したとおりのものである。

(2)引用例及び参考例の記載事項

ア 引用例1の記載事項及び引用発明
(ア)原査定の拒絶の理由において引用した,本願の優先日前に既に公知である,米国特許出願公開第2012/0131591号明細書(2012年5月24日公開。以下,これを「引用例1」という。)には,関連する図面と共に,次の事項が記載されている。(下線は当審で付加。以下同様。)

A 「[0052] According to another embodiment, assuming a set of cloud compute providers that meet a minimum reliability bar, it's possible to treat cloud compute cycles as an interchangeable commodity, tiered by price, performance and other features. A cloud compute system and/or method can then seamlessly parcel out compute work among multiple providers to generate optimal cloud compute execution. In some embodiments, the cloud compute marketplace can factor in the cost in terms of cycles and/or time in translating a given compute job for execution by disparate providers.
(当審訳:[0052] 別の実施形態によれば,最低信頼度を満たすクラウド計算プロバイダのセットを仮定すると,価格,性能,及び他の機能によって階層化された,交換可能な商品としてクラウド計算サイクルを扱うことが可能である。クラウド計算システム及び/または方法は,最適なクラウド計算実行を生成するために,複数のプロバイダ間で計算作業をシームレスに分割することができる。いくつかの実施形態では,クラウド計算市場は,異なるプロバイダによる実行のために,与えられた計算ジョブを翻訳する際のサイクル及び/または時間に関して,コストを考慮に入れることができる。)
[0053] Various embodiments solve some of the issues with conventional cloud compute systems. One embodiment develops an intelligent cloud compute pricing model based on real-time price and availability information furnished by a plurality of cloud compute providers. Another embodiment hosts a cloud compute marketplace, where compute providers can register their resources and consumers can submit work and any known constraints of time, cost, and features, such that the work is automatically distributed among the plurality of providers to meet the constraints. In one setting, an environment is provided where cloud resources - whether they be compute, storage, or other interchangeable services - are seamlessly allocated in an efficient market.
(当審訳:[0053] 様々な実施形態は,従来のクラウド計算システムに関するいくつかの問題を解決する。一実施形態は,複数のクラウド計算プロバイダによって提供されるリアルタイムの価格及び入手可能性情報に基づいて,インテリジェントクラウド計算価格付けモデルを開発する。別の実施形態は,クラウド計算市場をホスティングし,計算プロバイダは,それらのリソースを登録することができ,複数のプロバイダ間で自動的に分配されるように,消費者は,仕事,及び,時間,コスト,機能の既知の制約を提出することができる。ある環境では,クラウドリソース(計算,記憶装置,その他の交換可能なサービスなど)が,効率的な市場でシームレスに割り当てられる環境が提供される。)」

B 「[0091] FIG. 13 illustrates an example component architecture and communication flow. There are four high-level components in the illustrated example system. A customer 1320 interacts with a cloud compute market places. The customer can access a user interface over the web made available by a pricing system 1324. The pricing system generates and provides a consumer view 1326 to the customer through the user interface 1322. The user interface is configured to permit the customer to supply a compute job and any known or desired constraints 1301 for job completion. A pricing engine 1328 is configured to compute real-time pricing and sub-task breakdown at 1302. The pricing engine makes the determination of pricing and availability based on real-time data received from compute providers connected to the pricing system 1324. A provider manager 1330 can be configured to interact with compute providers, controlling registration of providers, maintaining real-time pricing and availability information, as well as tracking other information, including execution format, confidence level for task completion, etc. Pricing engine 1328 can access provider pricing and availability at 1302A. A request for pricing and availability can trigger provider manager to query 1302B individual providers to determine price/availability. Provider manager 1330 can include provider API translation 1331 configured to manage communication channels with compute providers, e.g., 1332 and 1334. Each provider can be associated with its own API, e.g., 1335 and 1337 having its own execution format and/or communication protocols.
(当審訳:[0091] 図13は,実施例のコンポーネントアーキテクチャ,及び通信フローを示す図である。図示される例示的システムには,4つの高レベルの構成要素がある。顧客1320は,クラウド計算市場とやりとりする。顧客は,価格決定システム1324によって利用可能にされたウェブを介して,ユーザインタフェースにアクセスすることができる。価格決定システムは,ユーザインタフェース1322を介して,顧客画面1326を生成し,顧客に提供する。ユーザインタフェースは,顧客が,ジョブの完了のために,計算ジョブおよび任意の既知のまたは所望の制約1301を供給することを可能にするように構成される。価格付けエンジン1328は,1302でリアルタイムの価格付けおよびサブタスク内訳を計算するように構成される。価格付けエンジンは,価格決定システム1324に接続されている計算プロバイダから受信したリアルタイムデータに基づいて,価格付け及び入手可能性の判断を行う。プロバイダマネージャ1330は,計算プロバイダと対話し,プロバイダの登録を制御し,リアルタイムの価格付け及び利用可能性情報を維持し,ならびに,実行フォーマット及びタスク完了に対する信頼レベルなどを含む他の情報を追跡するように,構成することが可能である。価格付けエンジン1328は,1302Aでプロバイダの価格付け及び入手可能性にアクセスすることができる。価格付けおよび入手可能性の要求は,プロバイダマネージャに,1302Bで個々のプロバイダに問い合わせて,価格付け/入手可能性を決定させることができる。プロバイダマネージャ1330は,計算プロバイダ(例えば1332及び1334)との通信チャネルを管理するように構成されたプロバイダAPI変換1331を含むことができる。各プロバイダは,それ自体の実行フォーマット及び/または通信プロトコルを有するそれ自身のAPI(例えば1335及び1337)と関連付けることができる。)
[0092] At 1303 an estimate of price and/or deadline for a submitted task is provider to the customer in the customer view 1326. If the customer wishes the compute task to be executed the customer can agree to the price and/or deadline and the job is committed for execution at 1305. A job manager is configured to manage job information, distributing sub-tasks, and starting sub-tasks 1306 at the assigned compute providers through interaction with the provider manager 1330. The provider API translation plugin can manage individual sub-tasks 1306A, and can provide translation for any sub-task so that the compute providers 1332 and 1334 receive each sub-task in a compatible execution format.
(当審訳:[0092] 1303において,提出されたタスクの価格及び/またはデッドラインの見積もりは,顧客画面1326において顧客に提供される。顧客は,計算タスクを実行することを望む場合,顧客は,価格及び/またはデッドラインに同意することができ,ジョブは1305で実行のためにコミットされる。ジョブマネージャ1340は,プロバイダマネージャ1330との対話を通じて,割り当てられた計算プロバイダでジョブ情報を管理し,サブタスクを分配し,サブタスク1306を開始するように構成される。プロバイダAPI変換プラグインは,個々のサブタスク1306A,計算プロバイダ1332及び1334が互換性のある実行フォーマットで各サブタスクを受け取るように,任意のサブタスクに対して変換を提供することができる。)」

C 「[0113] FIG. 15 illustrates an example view provided by the user interface, title submit new job at 1502. As illustrated there are two ways to submit a new job - with a fixed size 1504, or with an unlimited size 1506. If the job is a fixed size job, the customer can specify a size 1508 in terms of virtual machine hours to complete 1510. In some settings, the system can determine the size of the job automatically based on analysis of the submitted task. A compute job can be uploaded from a given location specified in the user interface 1516 by executing an upload operation triggered by display 1518. The customer can also specify a name for the given job. A deadline 1512 for completing the job and/or a budget 1514 can also be specified. For unlimited size jobs, a minimum rate for processing can be specified 1522 and a maximum rent in cost per hour can be established at 1524.
(当審訳:[0113] 図15は,新たなジョブを投入するユーザインタフェース1502によって提供される画面の例を示している。図示されるように,新しいジョブを投入するには,固定サイズ1504または無制限サイズ1506の2つの方法がある。ジョブが固定サイズのジョブである場合,顧客は,完了するための仮想マシン時間を1510で,サイズを1508で,指定することができる。設定によっては,システムは,投入されたタスクの分析に基づいて,ジョブのサイズを自動的に決定することができる。ディスプレイ1518によってトリガされるアップロード操作を実行することによって,ユーザインタフェース1516で指定された所与の場所から,計算ジョブをアップロードすることができる。顧客は,所与のジョブの名前を指定することもできる。ジョブを完了するためのデッドライン及び/または予算も同様に,それぞれ1512,1514で指定することができる。無制限サイズのジョブの処理の場合,処理の最小レートを1522で指定でき,1時間当たり最大賃料を1524で設定することができる。)」

D 「[0115] FIG. 16 illustrates an example view of a review estimate 1602 screen. According to one embodiment, before the job can start, the user must approve an estimate, in the form of a job estimate object. The job estimate object can be specified by job name 1604, size 1608, and indicate a source of the job 1606. If the job estimate indicates that constraints will not be met, the view can be configured to highlight a warning message. The view can also indicate if the job constraints have been met, e.g., 1607, 1609, 1611, and 1613. The review estimate view can be configured to reflect start time 1612, completion time 1614, cost 1616, aggregate rate 1618, average cost 1620, and when the estimate expires 1622. A job estimate can be configured as a persistent object. Further the job estimate can be accessed from multiple user interfaces, for example from the Submit New job view and from the Track jobs view.
(当審訳:[0115] 図16は,見積もり確認画面1602の一例を示す図である。一実施形態によれば,ジョブを開始する前に,ユーザは,ジョブ見積もりオブジェクトの形で,見積もりを承認しなければならない。ジョブ見積もりオブジェクトは,ジョブ名1604,サイズ1608,ジョブのソース1606を示すことで,指定することができる。ジョブ見積もりが,制約が満たされないことを示している場合,画面は,警告メッセージを強調表示するように構成することができる。画面はまた,ジョブ見積もりが満たされているかどうか(例えば1607,1609,1011,及び1613)も示すことができる。見積もり確認画面は,開始時間1612,完了時間1614,コスト1616,集約率1618,平均コスト1620,及び見積もりがデッドライン切れになる時期1622を反映するように構成することができる。ジョブ推定値は,永続的オブジェクトとして構成することができる。さらにジョブ見積もりは,複数のユーザインタフェース(例えば新しいジョブの送信画面やジョブの追跡画面)からアクセスできる。)
[0116] If the user approves of the estimate before it expires, the UI Controller will invoke the job backend to start the job based on the job estimate. An estimate may or may not meet the constraints set by the user. According to one embodiment, the user can approve of an unsatisfactory estimate. In some embodiments, approving an estimate and starting a job authorizes the system to charge the user's account for any work that is completed.
(当審訳:[0116] デッドラインが切れる前にユーザが見積もりを承認すると,UIコントローラは,ジョブ見積もりに基づいてジョブを開始するために,ジョブバックエンドを呼び出す。見積もりは,ユーザが設定した制約を満たす場合とそうでない場合がある。一実施形態によれば,ユーザは,不十分な見積もりを承認することができる。いくつかの実施形態では,見積もりを承認してジョブを開始すると,システムは,完了した作業に対してユーザのアカウントに請求することを許可する。)」

E 「[0146] FIG. 18 illustrates an example view of a job detail screen. The job Detail view includes header 1802 and displays information in a job record, and can include current status, estimates, and errors interesting to the user (e.g., VM rebooted, VM ran out of disk space, etc.). According to one embodiment, an in-progress job can be canceled outright at 1804. Already-consumed resources (e.g., instance-time) will be debited from the user's account. Resource consumption will be rounded to the greatest-common-denominator unit across all backend providers. This rounding unit can be static. According to one embodiment, compute providers allocate by the hour. Confirmation display 1806 is triggered upon selection of 1804. Confirmation display can be configured to include information on incurred expenses 1808 and require confirmation at 1810 to complete cancellation. According to one embodiment, the system can be configured to maintain a database of user accounts and billing information. The database can include information on pending jobs, existing estimates, cancellations, execution history, speed, price etc.
(当審訳:[0146] 図18は,ジョブ詳細画面の一例を示す画面である。ジョブ詳細画面はヘッダ1802を含み,ジョブレコード内の情報を表示し,現在の状態,見積もり,及びユーザにとって興味深いエラー(例えば,VMの再起動,VMのディスクスペースの不足など)を含むことができる。一実施形態によれば,1804で進行中のジョブを完全にキャンセルすることができる。既に消費されたリソース(例えば,インスタンス時間)は,ユーザの口座から引き落とされることになる。リソース消費量は,全てのバックエンドプロバイダ間の最大公約数単位に丸められることになる。この丸め単位は,静的にすることができる。一実施形態によれば,計算プロバイダは,時間単位で割り当てる。確認表示画面1806は,1804を選択した際に起動される。確認表示画面は,発生費用1808に関する情報を含み,キャンセルを完了するために,1810で確認を要求するように構成することができる。一実施形態によれば,システムは,ユーザアカウント及び課金情報のデータベースを維持するように構成することができる。データベースは,保留中のジョブ,既存の見積もり,キャンセル,実行履歴,スピード,価格などに関する情報を含むことができる。)」

(イ)上記記載から,引用例1には,次の技術的事項が記載されているものと認められる。

a 上記Aの「A cloud compute system and/or method can then seamlessly parcel out compute work among multiple providers to generate optimal cloud compute execution.(クラウド計算システム及び/または方法は,最適なクラウド計算実行を生成するために,複数のプロバイダ間で計算作業をシームレスに分割することができる。)」との記載からすると,引用例1には,“最適なクラウド計算実行を生成するために,複数のプロバイダ間で計算作業をシームレスに分割することができるクラウド計算方法”が記載されている。

b 上記Bの「The pricing system generates and provides a consumer view 1326 to the customer through the user interface 1322. The user interface is configured to permit the customer to supply a compute job and any known or desired constraints 1301 for job completion.(価格決定システムは,ユーザインタフェース1322を介して,顧客画面1326を生成し,顧客に提供する。ユーザインタフェースは,顧客が,ジョブの完了のために,計算ジョブおよび任意の既知のまたは所望の制約1301を供給することを可能にするように構成される。)」との記載,上記Aの「consumers can submit work and any known constraints of time, cost, and features(消費者は,仕事,及び,時間,コスト,機能の既知の制約を提出することができる)」との記載,及び上記Cの「The customer can also specify a name for the given job. A deadline 1512 for completing the job and/or a budget 1514 can also be specified.(顧客は,所与のジョブの名前を指定することもできる。ジョブを完了するためのデッドライン及び/または予算も同様に,それぞれ1512,1514で指定することができる。)」との記載からすると,引用例1には,“価格決定システムは,ユーザインタフェースを介して,顧客画面を生成し,顧客に提供し,前記ユーザインタフェースは,顧客が,ジョブの完了のために,所望の制約(時間,コストなど)を供給することを可能にするように構成され,顧客は,ジョブを完了するためのデッドラインも同様に指定することができ”る態様が記載されている。

c 上記Aの「In one setting, an environment is provided where cloud resources - whether they be compute, storage, or other interchangeable services - are seamlessly allocated in an efficient market.(ある環境では,クラウドリソース(計算,記憶装置,その他の交換可能なサービスなど)が,効率的な市場でシームレスに割り当てられる環境が提供される。)」との記載,上記Bの「At 1303 an estimate of price and/or deadline for a submitted task is provider to the customer in the customer view 1326. If the customer wishes the compute task to be executed the customer can agree to the price and/or deadline and the job is committed for execution at 1305. A job manager is configured to manage job information, distributing sub-tasks, and starting sub-tasks 1306 at the assigned compute providers through interaction with the provider manager 1330.(1303において,提出されたタスクの価格及び/またはデッドラインの見積もりは,顧客画面1326において顧客に提供される。顧客は,計算タスクを実行することを望む場合,顧客は,価格及び/またはデッドラインに同意することができ,ジョブは1305で実行のためにコミットされる。ジョブマネージャ1340は,プロバイダマネージャ1330との対話を通じて,割り当てられた計算プロバイダでジョブ情報を管理し,サブタスクを分配し,サブタスク1306を開始するように構成される。)」との記載,及び上記Dの「The review estimate view can be configured to reflect start time 1612, completion time 1614, cost 1616, aggregate rate 1618, average cost 1620, and when the estimate expires 1622.(見積もり確認画面は,開始時間1612,完了時間1614,コスト1616,集約率1618,平均コスト1620,及び見積もりがデッドライン切れになる時期1622を反映するように構成することができる。)」との記載からすると,引用例1には,“ある環境では,クラウドリソース(計算,記憶装置など)が,シームレスに割り当てられ,提出されたデッドラインの見積もりは,顧客画面において顧客に提供され,見積もり確認画面は,開始時間,完了時間を反映するように構成され,顧客は,計算タスクを実行することを望む場合,デッドラインに同意することができ,ジョブは実行のためにコミットされ,ジョブマネージャは,サブタスクを分配し,サブタスクを開始するように構成され”る態様が記載されている。

d 上記Aの「According to another embodiment, assuming a set of cloud compute providers that meet a minimum reliability bar, it's possible to treat cloud compute cycles as an interchangeable commodity, tiered by price, performance and other features.(別の実施形態によれば,最低信頼度を満たすクラウド計算プロバイダのセットを仮定すると,価格,性能,及び他の機能によって階層化された,交換可能な商品としてクラウド計算サイクルを扱うことが可能である。)」,及び「In some embodiments, the cloud compute marketplace can factor in the cost in terms of cycles and/or time in translating a given compute job for execution by disparate providers.(いくつかの実施形態では,クラウド計算市場は,異なるプロバイダによる実行のために,与えられた計算ジョブを翻訳する際のサイクル及び/または時間に関して,コストを考慮に入れることができる。)」との記載からすると,引用例1には,“クラウド計算プロバイダのセットは,価格,性能,及び他の機能によって階層化された,交換可能な商品としてクラウド計算サイクルを扱うことが可能であり,クラウド計算市場は,異なるプロバイダによる実行のために,コストを考慮に入れることができ”る態様が記載されている。

e 上記Eの「FIG. 18 illustrates an example view of a job detail screen. The job Detail view…(中略)…can include current status, estimates(図18は,ジョブ詳細画面の一例を示す画面である。ジョブ詳細画面は…(中略)…現在の状態,見積もり…(中略)…を含むことができる)」との記載からすると,引用例1には,“ジョブ詳細画面は,現在の状態,見積もりを含むことができ”る態様が記載されている。

f 上記Bの「A request for pricing and availability can trigger provider manager to query 1302B individual providers to determine price/availability.(価格付けおよび入手可能性の要求は,プロバイダマネージャに,1302Bで個々のプロバイダに問い合わせて,価格付け/入手可能性を決定させることができる。)」,及び「At 1303 an estimate of price and/or deadline for a submitted task is provider to the customer in the customer view 1326. If the customer wishes the compute task to be executed the customer can agree to the price and/or deadline and the job is committed for execution at 1305. A job manager is configured to manage job information, distributing sub-tasks, and starting sub-tasks 1306 at the assigned compute providers through interaction with the provider manager 1330.(1303において,提出されたタスクの価格及び/またはデッドラインの見積もりは,顧客画面1326において顧客に提供される。顧客は,計算タスクを実行することを望む場合,顧客は,価格及び/またはデッドラインに同意することができ,ジョブは1305で実行のためにコミットされる。ジョブマネージャ1340は,プロバイダマネージャ1330との対話を通じて,割り当てられた計算プロバイダでジョブ情報を管理し,サブタスクを分配し,サブタスク1306を開始するように構成される。)」との記載からすると,引用例1には,“価格付けの要求は,プロバイダマネージャに,価格付けを決定させることができ,提出されたタスクの価格の見積もりは,顧客画面において顧客に提供され,顧客は,計算タスクを実行することを望む場合,顧客は,価格に同意することができ,ジョブは実行のためにコミットされ,ジョブマネージャは,サブタスクを分配し,サブタスクを開始するように構成され”る態様が記載されている。

g 上記Dの「If the user approves of the estimate before it expires, the UI Controller will invoke the job backend to start the job based on the job estimate.(デッドラインが切れる前にユーザが見積もりを承認すると,UIコントローラは,ジョブ見積もりに基づいてジョブを開始するために,ジョブバックエンドを呼び出す。)」との記載からすると,引用例1には,“ユーザが見積もりを承認すると,UIコントローラは,ジョブ見積もりに基づいてジョブを開始”する態様が記載されている。

h 上記Dの「According to one embodiment, before the job can start, the user must approve an estimate, in the form of a job estimate object.(一実施形態によれば,ジョブを開始する前に,ユーザは,ジョブ見積もりオブジェクトの形で,見積もりを承認しなければならない。)」,「The review estimate view can be configured to reflect start time 1612, completion time 1614, cost 1616, aggregate rate 1618, average cost 1620, and when the estimate expires 1622.(見積もり確認画面は,開始時間1612,完了時間1614,コスト1616,集約率1618,平均コスト1620,及び見積もりがデッドライン切れになる時期1622を反映するように構成することができる。)」,及び上記Bの「At 1303 an estimate of price and/or deadline for a submitted task is provider to the customer in the customer view 1326. If the customer wishes the compute task to be executed the customer can agree to the price and/or deadline and the job is committed for execution at 1305. A job manager is configured to manage job information, distributing sub-tasks, and starting sub-tasks 1306 at the assigned compute providers through interaction with the provider manager 1330.(1303において,提出されたタスクの価格及び/またはデッドラインの見積もりは,顧客画面1326において顧客に提供される。顧客は,計算タスクを実行することを望む場合,顧客は,価格及び/またはデッドラインに同意することができ,ジョブは1305で実行のためにコミットされる。ジョブマネージャ1340は,プロバイダマネージャ1330との対話を通じて,割り当てられた計算プロバイダでジョブ情報を管理し,サブタスクを分配し,サブタスク1306を開始するように構成される。)」との記載からすると,引用例1には,“ジョブを開始する前に,ユーザが見積もりを承認する見積もり確認画面は,開始時間,完了時間を反映するように構成することができ,顧客は,計算タスクを実行することを望む場合,デッドラインに同意することができ,ジョブは実行のためにコミットされ,サブタスクを開始するように構成され”る態様が記載されている。

(ウ)上記(ア)及び(イ)より,引用例1には,次の発明(以下「引用発明」という。)が記載されていると認められる。

「最適なクラウド計算実行を生成するために,複数のプロバイダ間で計算作業をシームレスに分割することができるクラウド計算方法において,
価格決定システムは,ユーザインタフェースを介して,顧客画面を生成し,顧客に提供し,前記ユーザインタフェースは,顧客が,ジョブの完了のために,所望の制約(時間,コストなど)を供給することを可能にするように構成され,顧客は,ジョブを完了するためのデッドラインも同様に指定することができ,
ある環境では,クラウドリソース(計算,記憶装置など)が,シームレスに割り当てられ,提出されたデッドラインの見積もりは,顧客画面において顧客に提供され,見積もり確認画面は,開始時間,完了時間を反映するように構成され,顧客は,計算タスクを実行することを望む場合,デッドラインに同意することができ,ジョブは実行のためにコミットされ,ジョブマネージャは,サブタスクを分配し,サブタスクを開始するように構成され,
クラウド計算プロバイダのセットは,価格,性能,及び他の機能によって階層化された,交換可能な商品としてクラウド計算サイクルを扱うことが可能であり,クラウド計算市場は,異なるプロバイダによる実行のために,コストを考慮に入れることができ,
ジョブ詳細画面は,現在の状態,見積もりを含むことができ,
価格付けの要求は,プロバイダマネージャに,価格付けを決定させることができ,提出されたタスクの価格の見積もりは,顧客画面において顧客に提供され,顧客は,計算タスクを実行することを望む場合,顧客は,価格に同意することができ,ジョブは実行のためにコミットされ,ジョブマネージャは,サブタスクを分配し,サブタスクを開始するように構成され,
ユーザが見積もりを承認すると,UIコントローラは,ジョブ見積もりに基づいてジョブを開始するものであり,当該ジョブを開始する前に,ユーザが見積もりを承認する見積もり確認画面は,開始時間,完了時間を反映するように構成することができ,顧客は,計算タスクを実行することを望む場合,デッドラインに同意することができ,ジョブは実行のためにコミットされ,サブタスクを開始するように構成される,こととを含む,方法。」

イ 引用例2の記載事項
原査定の備考欄において引用文献7として引用した,本願の優先日前に既に公知である,特開2010-152738号公報(平成22年7月8日公開。以下,これを「引用例2」という。)には,関連する図面と共に,次の事項が記載されている。

F 「【0023】
完了予測部270は、確保されたリソース上で指定処理を実行中に、当該リソースが確保された時間内に指定処理が完了するか否かを予測する。完了予測部270は、一例として実行履歴DB260に格納された当該指定処理の実行状態の監視結果、および指定処理に類似する過去の処理の実行時間の履歴等に基づいて、確保時間内に指定処理が完了するか否かを予測して、予測結果をフロントエンド処理部200および実行管理部240に通知する。これを受けて、フロントエンド処理部200内の問合せ部206は、確保時間内に指定処理が完了しない場合には、リソースを追加で確保するか否かをユーザ端末120のユーザに問い合わせる。また、実行管理部240は、指定処理の実行の中断を計算機システム100に指示する。」

ウ 引用例3の記載事項
原査定の備考欄において引用文献8として引用した,本願の優先日前に既に公知である,特表2007-524951号公報(平成19年8月30日公開。以下,これを「引用例3」という。)には,関連する図面と共に,次の事項が記載されている。

G 「【請求項15】
複数のコンピューティング・リソースからなるグリッドと、前記グリッドのコンピューティング・リソースの使用状況に関して1人または複数の顧客の要求を受信するための前記グリッドの要求マネージャとを含むネットワーク・システムで実行される方法であって、
顧客の1つまたは複数のコンピュータ・システムが、前記要求マネージャに結合され、さらに、1つまたは複数のプロセッサと、前記1つまたは複数のプロセッサのうちの少なくとも1つに結合されたメモリと、前記メモリ内に常駐し、前記少なくとも1つのプロセッサによって実行可能なスケジューリング・マネージャとを含み、
少なくとも1つの事前定義された照会時間境界に関するデータに関して照会のランタイムを評価するステップと、
前記照会時間境界内に前記照会の実行を完了するために割り振るべきコンピュータ・リソースの適切な量を動的に予測するステップとを含み、
前記要求マネージャが、前記動的予測に基づいて、前記グリッド・コンピューティング・リソースのコンピューティング・リソースについて動的に割振り/割振り解除を行う、方法。」

エ 参考例1の記載事項
本願の優先日前に既に公知である,米国特許出願公開第2009/0240798号明細書(2009年9月24日公開。以下,これを「参考例1」という。)には,関連する図面と共に,次の事項が記載されている。

H 「[0016] Various exemplary methods, devices and system described herein pertain to monitoring resources in one or more data centers. An exemplary monitoring system is configured to monitor resources associated with one or more data centers and to receive requests for resources. Such a system can utilize resources better for an existing data center or can allow for more effective data center design.
(当審訳:[0016]本明細書で説明される様々な例示的な方法、デバイスおよびシステムは、1つ以上のデータセンタ内のリソースの監視に関連する。例示的な監視システムは、1つ以上のデータセンタに関連付けられたリソースを監視し、リソースを求める要求を受信するように構成されている。このようなシステムは、既存のデータセンタのリソースを利用することができる、またはより効果的なデータセンタ設計を可能にすることができる。)」

I 「[0028] FIG. 3 shows an exemplary system 300 that includes one or more services 110 and a resource monitoring layer 320 . In this example, the resource monitoring layer 320 includes a request module 321 , a resource module 324 , monitored resources 326 and a pricing and/or billing module 328 that can determine pricing based at least in part on utilization of monitored resources (e.g., past utilization, current utilization and/or predicted, future utilization).
(当審訳:[0028]図3は、1つ以上のサービス110、およびリソース・モニタリング層320を含む例示的なシステム300を示している。この例では、リソースモニタリング層320は、要求モジュール321、リソースモジュール324、監視対象リソース326,およびモニタされたリソース利用率(例えば、過去の使用、現在の使用及び/又は予測された、未来の利用)に少なくとも部分的に基づいて価格を決定することができる価格設定/請求書モジュール328を含む。」

オ 参考例2の記載事項
本願の優先日前に既に公知である,特開2010-176342号公報(平成22年8月12日公開。以下,これを「参考例2」という。)には,関連する図面と共に,次の事項が記載されている。

J 「【0114】
図21に示す解析装置は、ウェブログ保存部211、平常行動分析部203、需要予測補正部205の構成は、第1実施形態と同様であり、平常行動分析部203および需要予測補正部205の分析結果を用いて想定外需要を検出する想定外需要検出システム2001をさらに備えている。

…(中略)…

【0122】
コスト算出部2024は、追加情報生成部2023が生成した追加ITリソース情報で表されるITリソースを追加するためのコストを、コスト情報記録部2015に記録されたデータを用いて算出する。コスト情報記録部2015には、たとえば、IT資源価格情報2016及び運用作業情報2017が記録されている。IT資源価格情報2016は、共有のITリソースの貸出価格を含むものである。この貸出価格は、過去ログに基づいて設定された固定価格であってもよく、需要バランスに応じて変動するものであってもよい。運用作業情報2017は、ITリソースとしてサーバが人手により追加される場合に、その追加作業に必要となる人数や作業時間を表すデータを挙げることができる。」

カ 参考例3の記載事項
本願の優先日前に既に公知である,米国特許出願公開第2006/0069621号明細書(2006年5月30日公開。以下,これを「参考例3」という。)には,関連する図面と共に,次の事項が記載されている。

K 「[0030] The present invention is preferably realized in conjunction with an on-demand computing technology or architecture, such as a grid computing environment. As the present invention's benefits are not limited to grid computing environment alone, it will be recognized by those skilled in the art that our disclosure of specific implementation details with respect to grid environments does not limit the scope of the invention to such. It is within the skill of those in the art to adapt and configure the present invention for use with other on-demand computing technologies, including but not limited to data centers and utility computing.
(当審訳:[0030] 本発明は、オンデマンド・コンピューティングの技術またはアーキテクチャに関連して実現され、グリッドコンピューティング環境のようなものであることが好ましい。本発明の利点は、グリッドコンピューティング環境に限定されるものではなく、当業者であれば、グリッド環境に対して特定の実装の詳細の開示は、本発明の範囲を限定しないことが認識されるであろう。それは他のオンデマンド・コンピューティング技術との使用のために、本発明は、データセンタおよびユーティリティー・コンピューティングを非限定的に含む適合および構成するのに当業者の技術の範囲内である。)」

L 「[0080] A set of Producer Trending Agents (“PTA”) (6, 7, 8) are provided, which are monitoring systems that work on behalf of each “producer”, and which facilitate listing or offering of free resources from those producers (2). A PTA can be programmed to list which free resources can be placed into the AAREAS. Additionally, it can also be programmed to use historical trend data to predict future available pools of resources for use. Each PTA such as PTAa, PTAb, and PTAn manages each resource provider and its available resources.
(当審訳:[0080] Producer傾向分析エージェント(“PTA”)(6, 7, 8)のセットが設けられており、これらは、“producer”毎に代わって機能し、これらの作成器(2)からの空き資源の一覧または提供を容易にする監視システムである。PTAは、空きリソースがAAREAS内に配置することができるリストにプログラムすることができる。加えて、それはまた、
過去のトレンドデータを使用して将来利用可能なリソースのプールを予測するようにプログラムすることができる。PTAa、PTAb、PTAnなど各PTAは、各リソースプロバイダおよびその利用可能なリソースを管理する。)」

(3)対比

本件補正発明と引用発明とを対比する。

ア 引用発明の「価格決定システム」,「ジョブ」,「所望の制約」,「時間」,及び「デッドライン」は,それぞれ,本件補正発明の「リソースマネージャ」,「タスクの定義」,「定義」,「必要期限時刻」,及び「ユーザー指定期限」に対応付けられるものであるところ,引用発明の「時間」は,所望の制約の一つとして顧客によって供給されるものであることから,本件補正発明の「必要期限時刻」に相当するといえる。そうすると,引用発明の「価格決定システム」は,ユーザインタフェースを介して,顧客からジョブ完了のために所望の制約(時間,コストなど)を供給されるものであり,顧客は所望の制約としてデッドラインも同様に指定できるものであることから,引用発明の「ユーザインタフェースを介して,顧客画面を生成し,顧客に提供し,前記ユーザインタフェースは,顧客が,ジョブの完了のために,所望の制約(時間,コストなど)を供給することを可能にするように構成され,顧客は,ジョブを完了するためのデッドラインも同様に指定することができ」ることは,本件補正発明の「リソースマネージャが、タスクの定義を受信することであって、前記定義が、必要期限時刻を含み、前記必要期限時刻が、前記タスクの実行の完了に対する期限を含む、受信すること」と一致するといえる。
したがって引用発明と本件補正発明とは,“リソースマネージャが,タスクの定義を受信することであって,前記定義が,必要期限時刻を含み,前記必要期限時刻が,前記タスクの実行の完了に対する期限を含む,受信すること”の点で一致する。

イ 引用発明の「クラウドリソース(計算,記憶装置など)」,「完了時間」,「交換可能な商品」,「階層化」,及び「コスト」は,それぞれ,本件補正発明の「クラウドベースの、複数のリソースプール」,「推定期間」,「リソースプール」,「体系化」,及び「使用量コスト」に対応付けられる。ここで,引用発明の価格決定システムは,ジョブの実行がコミットされると,サブタスクを分配し,サブタスクを開始するように構成されていて,「見積もり確認画面」に「完了時間」が「反映」されるものであり,当該「見積もり確認画面」において顧客にジョブの「完了時間」を提供する際には,分配される各サブタスクの実行が完了する時間を決定しているものと認められる。
また,引用発明は,「ある環境では,クラウドリソース(計算,記憶装置など)が,シームレスに割り当てられ」るとともに,「クラウド計算プロバイダのセット」が,「価格,性能,及び他の機能によって階層化された,交換可能な商品としてクラウド計算サイクルを扱うことが可能であり,クラウド計算市場は,異なるプロバイダによる実行のために,コストを考慮に入れることができ」るものであるから,複数のクラウドリソースが,価格,性能,及び他の機能によって階層化され,交換可能な商品として扱うことが可能であり,コストを考慮に入れることができるものであると認められる。
してみると,引用発明の「ある環境では,クラウドリソース(計算,記憶装置など)が,シームレスに割り当てられ,提出されたデッドラインの見積もりは,顧客画面において顧客に提供され,見積もり確認画面は,開始時間,完了時間を反映するように構成され,顧客は,計算タスクを実行することを望む場合,デッドラインに同意することができ,ジョブは実行のためにコミットされ,ジョブマネージャは,サブタスクを分配し,サブタスクを開始するように構成され,」「クラウド計算プロバイダのセットは,価格,性能,及び他の機能によって階層化された,交換可能な商品としてクラウド計算サイクルを扱うことが可能であり,クラウド計算市場は,異なるプロバイダによる実行のために,コストを考慮に入れることができ」ることと,本件補正発明の「前記リソースマネージャが、クラウドベースの、複数のリソースプールに体系化され且つ各前記リソースプールが関連付けられた使用量コストを有する複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を、前記タスクの一部を実行し、前記一部を実行した期間から前記一部が実行された前記タスクの合計の推定実行期間を外挿することによって決定すること」とは,後記する点(相違点1)で相違するものの,“前記リソースマネージャが,クラウドベースの,複数のリソースプールに体系化され且つ各前記リソースプールが関連付けられた使用量コストを有する複数のコンピューティングリソースの各々に対して,前記タスクの前記実行を完了するための推定期間を決定すること”の点で一致する。

ウ 引用発明の「価格の見積もり」は,本件補正発明の「推定コスト」に対応付けられるものであるところ,当該引用発明の「価格の見積もり」は,価格決定システムにおける顧客画面において顧客に提供され,顧客が同意すると,ジョブマネージャが,サブタスクを分配するように構成されるものであることから,サブタスクは,「価格の見積もり」に基づいて,複数のクラウドリソースのうちの少なくとも1つ以上を選択して分配されるものと認められる。
そして,引用発明の「サブタスク」は,本件補正発明の「複数のコンピューティングリソース」のうちの1つに対応するところ,引用発明の「ジョブマネージャ」が「サブタスクを分配し,サブタスクを開始する」ことは,本件補正発明において,「1つ以上の前記コンピューティングリソースを選択」することに相当するといえる。
してみると,引用発明の「価格付けの要求は,プロバイダマネージャに,価格付けを決定させることができ,提出されたタスクの価格の見積もりは,顧客画面において顧客に提供され,顧客は,計算タスクを実行することを望む場合,顧客は,価格に同意することができ,ジョブは実行のためにコミットされ,ジョブマネージャは,サブタスクを分配し,サブタスクを開始するように構成され」ることと,本件補正発明の「前記リソースマネージャが、前記複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了する推定コストに基づいて、前記必要期限時刻よりも前に前記タスクの前記実行を完了するために利用可能である前記コンピューティングリソースの中から、1つ以上の前記コンピューティングリソースを選択すること」とは,後記する点(相違点2及び相違点3)で相違するものの,“前記リソースマネージャが,前記複数のコンピューティングリソースの各々に対して,前記タスクの前記実行を完了する推定コストに基づいて,1つ以上の前記コンピューティングリソースを選択すること”の点で一致する。

エ 引用発明の「開始時間」及び「完了時間」は,本件補正発明の「スケジュール設定された時刻」及び「推定期間」に対応付けられるものであるところ,引用発明の「開始時間」及び「完了時間」は,価格決定システムにおける顧客画面において顧客に提供され,顧客が同意すると,サブタスクを開始するように構成されているものであるから,上記ウの検討結果を踏まえると,引用発明は,選択された1つ以上のクラウドリソースを使用して,開始時間にジョブを開始するものであると認められる。
してみると,引用発明の「ユーザが見積もりを承認すると,UIコントローラは,ジョブ見積もりに基づいてジョブを開始するものであり,当該ジョブを開始する前に,ユーザが見積もりを承認する見積もり確認画面は,開始時間,完了時間を反映するように構成することができ,顧客は,計算タスクを実行することを望む場合,デッドラインに同意することができ,ジョブは実行のためにコミットされ,サブタスクを開始するように構成される」ことと,本件補正発明の「前記リソースマネージャが、前記選択された1つ以上のコンピューティングリソースを使用して、スケジュール設定された時刻に前記タスクの前記実行を開始すること」とは,“前記リソースマネージャが,前記選択された1つ以上のコンピューティングリソースを使用して,スケジュール設定された時刻に前記タスクの前記実行を開始すること”の点で一致する。

オ 以上,アないしエの検討結果を踏まえると,引用発明の「クラウド計算方法」と,本件補正発明の「コンピュータ実装方法」とは,アないしエを“含む,コンピュータ実装方法”で一致するから,引用発明と本件補正発明とは,次の一致点及び相違点を有する。

〈一致点〉

リソースマネージャが,タスクの定義を受信することであって,前記定義が,必要期限時刻を含み,前記必要期限時刻が,前記タスクの実行の完了に対する期限を含む,受信することと,
前記リソースマネージャが,クラウドベースの,複数のリソースプールに体系化され且つ各前記リソースプールが関連付けられた使用量コストを有する複数のコンピューティングリソースの各々に対して,前記タスクの前記実行を完了するための推定期間を決定することと,
前記リソースマネージャが,前記複数のコンピューティングリソースの各々に対して,前記タスクの前記実行を完了する推定コストに基づいて,1つ以上の前記コンピューティングリソースを選択することと,
前記リソースマネージャが,前記選択された1つ以上のコンピューティングリソースを使用して,スケジュール設定された時刻に前記タスクの前記実行を開始することと,を含む,コンピュータ実装方法。

〈相違点1〉

本件補正発明が,「前記タスクの前記実行を完了するための推定期間を、前記タスクの一部を実行し、前記一部を実行した期間から前記一部が実行された前記タスクの合計の推定実行期間を外挿することによって決定する」ものであるのに対し,引用発明は,「見積もり確認画面」に「反映」される「完了時間」がどのように決定されるのか,特定されていない点。

〈相違点2〉

本件補正発明が,「1つ以上の前記コンピューティングリソースを選択する」にあたり,「前記必要期限時刻よりも前に前記タスクの前記実行を完了するために利用可能である前記コンピューティングリソースの中から」選択するものであるのに対し,引用発明は,「ジョブマネージャ」が「サブタスクを分配」するものであるが,選択されるサブタスクがどのようなものの中から選択されるのか,特定されていない点。

〈相違点3〉

本件補正発明の「推定コスト」は,「前記複数のコンピューティングリソースの過去の価格設定変動に基づいて将来の価格設定変更を予測する予測モデルを少なくとも使用して推定される」ものであるのに対し,引用発明は,そのような予測モデルを使用することは特定されていない点。

〈相違点4〉

本件補正発明の「スケジュール設定された時刻」が,「少なくとも前記推定期間だけ前記必要期限時刻よりも早い」ものであるのに対し,引用発明は,「顧客は,計算タスクを実行することを望む場合,デッドラインに同意することができ,ジョブは実行のためにコミットされ,サブタスクを開始するように構成される」ものであるが,当該「サブタスク」の「開始」がいつなされるか特定されていない点。

(4)当審の判断

上記相違点につき検討する。

ア 相違点1について
引用発明は,「ジョブ詳細画面は,現在の状態,見積もりを含むことができ」るものであり,ユーザはジョブ開始前に,見積もり確認画面で「完了時間」を確認できる他,ジョブ開始後においても適宜,ジョブ詳細画面にて,ジョブの進行状況,時間やコストの見積もり等を確認できるものである。
引用発明の「ジョブ詳細画面」に表示される時間の見積もりがどのように決定されるのかについては,引用発明において特定されていないものの,例えば,引用例2の上記Fに,「完了予測部270は、確保されたリソース上で指定処理を実行中に、当該リソースが確保された時間内に指定処理が完了するか否かを予測する。完了予測部270は…(中略)…当該指定処理の実行状態の監視結果…(中略)…に基づいて、確保時間内に指定処理が完了するか否かを予測」と記載され,引用例3のGに「複数のコンピューティング・リソースからなるグリッド…(中略)…を含むネットワーク・システムで実行される方法であって、…(中略)…少なくとも1つの事前定義された照会時間境界に関するデータに関して照会のランタイムを評価するステップと、前記照会時間境界内に前記照会の実行を完了するために割り振るべきコンピュータ・リソースの適切な量を動的に予測するステップとを含み、…(中略)…前記動的予測に基づいて、前記グリッド・コンピューティング・リソースのコンピューティング・リソースについて動的に割振り/割振り解除を行う、方法」と記載されるように,複数のコンピューティングリソースを使用して処理の一部を実行した段階で,それまでに要した処理時間から完了時間を動的に予測する技術は,当該技術分野において周知技術であった。そして,引用発明と,引用例2及び引用例3に記載された技術思想は,タスクの実行管理に関する技術である点で共通する。

してみれば,引用発明に引用例2及び引用例3に記載された技術思想を適用し,相違点1に係る構成とすることは,当業者が容易に想到し得たことである。

よって,相違点1は格別なものではない。

イ 相違点2について
引用発明は,「ユーザインタフェース」に対して,「顧客」が,「ジョブの完了のために,所望の制約(時間,コストなど)を供給」し,「ジョブを完了するためのデッドラインも同様に指定」して,「クラウドリソース(計算,記憶装置など)が,シームレスに割り当てられ,提出されたデッドラインの見積もりは,顧客画面において顧客に提供され,見積もり確認画面は,開始時間,完了時間を反映するように構成され,顧客は,計算タスクを実行することを望む場合,デッドラインに同意することができ,ジョブは実行のためにコミットされ,ジョブマネージャは,サブタスクを分配し,サブタスクを開始するように構成され」ていて,当該「見積もり確認画面」に反映された「完了時間」は,「顧客が,ジョブの完了のために」供給した,「所望の制約(時間,コストなど)」や「ジョブを完了するためのデッドライン」に基づいて提供されるものであるから,当該「所望の制約」の1つである,本件補正発明の「必要期限時刻」に相当する時刻よりも前にジョブの実行が完了するような,「サブタスク」を実行するリソース,すなわちコンピューティングリソースが用いられて,見積もりが作成されていることは当業者にとって自明である。
そうすると,引用発明において,1つ以上のコンピューティングリソースを選択するにあたり,必要期限時刻よりも前にタスクの実行を完了するために利用可能である前記コンピューティングリソースの中から選択する程度のことは,当業者が適宜なし得ることと認められる。

よって,相違点2は格別なものではない。

ウ 相違点3について
相違点3に関し,本願明細書には,「リソースマネージャー180によって使用される価格設定データ304は、プロバイダネットワークの多様な場所にある多様な種類のリソース(オンデマンドまたはスポットインスタンス等)に有効な現在の価格設定、ならびにそのような価格の経時的な過去の変動を含むことができる。いくつかの実施形態において、リソースマネージャー180は、例えば、過去の価格設定変動に基づいて、将来の価格設定変更を予測する予測モデルを開発することができる。」(段落【0032】。下線は説明のために当審で付加。以下同様。),「リソースマネージャー180によって使用される価格設定データ304は、プロバイダネットワークの多様な場所にある多様な種類のリソース(オンデマンドまたはスポットインスタンス等)に有効な現在の価格設定、ならびにそのような価格の経時的な過去の変動を含むことができる。いくつかの実施形態において、リソースマネージャー180は、例えば、過去の価格設定変動に基づいて、将来の価格設定変更を予測する予測モデルを開発することができる。」(段落【0046】),及び,「リソースマネージャー180によって使用される価格設定データ304は、プロバイダネットワークの多様な場所にある多様な種類のリソース(オンデマンドまたはスポットインスタンス等)に有効な現在の価格設定、ならびにそのような価格の経時的な過去の変動を含むことができる。いくつかの実施形態において、リソースマネージャー180は、例えば、過去の価格設定変動に基づいて、将来の価格設定変更を予測する予測モデルを開発することができる。」(段落【0077】)との記載があるのみで,いずれも単なる例示にとどまり,「複数のコンピューティングリソースの過去の価格設定変動に基づいて将来の価格設定変更を予測する予測モデル」が,具体的にどのようなものであって,どのような処理がなされることを意味するのかについての具体的な構成の開示は認められない。
そうとすると,相違点3に係る構成,すなわち「推定コスト」を,「前記複数のコンピューティングリソースの過去の価格設定変動に基づいて将来の価格設定変更を予測する予測モデルを少なくとも使用して推定」することは,本件補正発明において,課題を解決するための格別な構成であるとはいえず,この点において,従来技術に対する格別顕著な技術的貢献をなす構成とも認められない。
そして,参考例1ないし参考例3の上記HないしLに記載されているように,コンピューティングリソースにかかるコストを予測するにあたり,過去の状況から将来の状況を推定して利用する程度のことは,当該技術分野において普通に行われている慣用技術と認められ,引用発明において当該慣用技術を採用することを阻害する特段の要因もみあたらない。

してみれば,引用発明において,参考例1ないし参考例3に記載されたような慣用技術を採用し,相違点3に係る構成とすることは,当業者が容易に想到し得たことである。

よって,相違点3は格別なものではない。

エ 相違点4について
引用発明の「見積もり確認画面」は,「ジョブを開始する前に,ユーザが見積もりを承認する」ためのものであり,実行するジョブをデッドライン内で処理するために,当該確認画面に提示される「開始時間」と「完了時間」について,「デッドライン」よりも早い時間となるようにスケジュールすることは当業者にとって必然である。

してみれば,引用発明においても,相違点4に係る構成とすることは,当業者が容易に想到し得たことである。

よって,相違点4は格別なものではない。

オ 当審の判断についての結論
以上検討したとおり,相違点1ないし4はいずれも格別なものではなく,またそのことによる効果も,当業者であれば普通に想起し得る程度のことに過ぎない。
したがって,本件補正発明は,引用発明並びに引用例2及び引用例3に記載されたような周知技術,さらには参考例1ないし参考例3に記載されたような慣用技術に基づいて当業者が容易になし得たものであり,特許法29条2項の規定により,特許出願の際独立して特許を受けることができないものである。

3 本件補正についてのむすび

以上のとおり,本件補正は特許法17条の2第6項において準用する同法126条7項の規定に違反するので,同法159条1項において読み替えて準用する同法53条1項の規定により却下すべきものである。
よって,上記補正の却下の決定の結論のとおり決定する。


第3 本願発明について

1 本願発明

令和2年2月25日にされた手続補正は,上記のとおり却下されたので,本願の請求項に係る発明は,令和1年8月28日にされた手続補正により補正された特許請求の範囲に記載された事項により特定されるものであるところ,その請求項1に係る発明(以下,「本願発明」という。)は,明細書及び図面の記載からみて,その請求項1に記載された事項により特定される,前記第2[理由]1(2)に記載のとおりのものである。再掲すれば,次のとおり。

「リソースマネージャが、タスクの定義を受信することであって、前記定義が、必要期限時刻を含み、前記必要期限時刻が、前記タスクの実行の完了に対する期限を含む、受信することと、
前記リソースマネージャが、クラウドベースの、複数のリソースプールに体系化され且つ各前記リソースプールが関連付けられた使用量コストを有する複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を、前記タスクの一部を実行し、前記一部を実行した期間から前記一部が実行された前記タスクの合計の推定実行期間を外挿することによって決定することと、
前記リソースマネージャが、前記複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了する推定コストに基づいて、前記必要期限時刻よりも前に前記タスクの前記実行を完了するために利用可能である前記コンピューティングリソースの中から、1つ以上の前記コンピューティングリソースを選択することと、
前記リソースマネージャが、前記選択された1つ以上のコンピューティングリソースを使用して、スケジュール設定された時刻に前記タスクの前記実行を開始することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、開始することと、を含む、コンピュータ実装方法。」

2 原査定の拒絶の理由

原査定の拒絶の理由は,この出願の請求項1ないし15に係る発明は,本願の優先日前に頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献1ないし3に記載された発明及び引用文献4ないし8に記載された周知技術に基づいて,その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから,特許法29条2項の規定により特許を受けることができない,というものである。

引用文献1:米国特許出願公開第2012/0131591号明細書
引用文献2:特開2003-256222号公報
引用文献3:特開平09-198354号公報
引用文献4:特開2012-252422号公報
引用文献5:米国特許出願公開第2011/0138055号明細書
引用文献6:米国特許出願公開第2012/0180055号明細書
引用文献7:特開2010-152738号公報
引用文献8:特表2007-524951号公報

3 引用文献

原査定の拒絶の理由で引用された引用文献1並びに引用文献7及び8の記載事項は,前記第2の[理由]2(2)においてそれぞれ,引用例1,引用例2及び引用例3として記載したとおりである。

4 対比・判断

本願発明は,前記第2の[理由]2で検討した本件補正発明から,「推定コスト」に係る限定事項を削除したものである。
そうすると,本願発明の発明特定事項を全て含み,さらに他の事項を付加したものに相当する本件補正発明が,前記第2の[理由]の2(3),(4)に記載したとおり,引用発明及び引用例2,3(原査定の引用文献1及び引用文献7,8)に記載された技術に基づいて,当業者が容易に発明をすることができたものであるから,本願発明も,同様の理由により,引用発明及び引用例2,3に記載された技術に基づいて,当業者が容易に発明することができたものである。


第4 むすび

以上のとおり,本願発明は,本願優先日前に頒布された引用例に記載された発明に基づいて当業者が容易に発明をすることができたものであるから,特許法29条2項の規定により特許を受けることができない。
したがって,その余の請求項に係る発明について論及するまでもなく,本願は拒絶すべきものである。
よって,結論のとおり審決する。
 
別掲
 
審理終結日 2020-10-21 
結審通知日 2020-11-04 
審決日 2020-11-18 
出願番号 特願2018-121759(P2018-121759)
審決分類 P 1 8・ 575- Z (G06F)
P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 木村 貴俊  
特許庁審判長 田中 秀人
特許庁審判官 山崎 慎一
須田 勝巳
発明の名称 コスト最小化タスクスケジューラ  
代理人 小池 勇三  
代理人 山川 政樹  
代理人 山川 茂樹  
  • この表をプリントする

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