【事件の表示】
　特願２０１５−５５７２００「コスト最小化タスクスケジューラ」拒絶査定不服審判事件〔平成２６年　８月１４日国際公開、ＷＯ２０１４／１２４４４８、平成２８年　３月　７日国内公表、特表２０１６−５０７１２１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本件審判請求に係る出願（以下，「本願」という。）は，２０１４年２月１１日（パリ条約による優先権主張外国庁受理２０１３年２月１１日，アメリカ合衆国）を国際出願日とする出願であって，平成２７年８月１１日に特許法第１８４条の５第１項に規定される書面の提出がなされ，同年８月２８日付けで特許法第１８４条の４第１項の規定による国際出願日における明細書，請求の範囲，図面（図面の中の説明に限る。）及び要約の翻訳文の提出がなされるとともに，同日付けで審査請求がなされ，平成２８年７月１１日付けで拒絶理由通知（同年７月１９日発送）がなされ，平成２９年１月１９日付けで意見書が提出されるとともに，同日付けで手続補正がなされ，同年７月２６日付けで拒絶理由通知（同年８月８日発送）がなされ，同年１１月７日付けで意見書が提出されるとともに，同日付けで手続補正がなされたが，平成３０年２月１５日付けで拒絶査定（同年２月２７日謄本送達）がなされた。
　これに対して，「原査定を取り消す、本願は特許をすべきものである、との審決を求める。」ことを請求の趣旨として，平成３０年６月２７日付けで本件審判請求がなされるとともに，同日付けで手続補正がなされたものである。
第２　平成３０年６月２７日付けの手続補正についての補正却下の決定
　
［補正却下の決定の結論］
　
　平成３０年６月２７日付けの手続補正を却下する。
　
［理由］
　
１　補正の内容
　
ア　平成３０年６月２７日付けの手続補正（以下，「本件補正」という。）の内容は，平成２９年１１月７日付けの手続補正により補正された特許請求の範囲の請求項１ないし請求項１５の記載
　
「　【請求項１】
　リソースマネージャが、タスクの定義を受信することであって、前記定義が、必要期限時刻を含み、前記必要期限時刻が、前記タスクの実行の完了に対するユーザー指定期限を含み、前記タスクは割り込み可能性特性に関連する、受信することと、
　前記リソースマネージャが、クラウドベースの複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のコンピューティングリソースは、複数のリソースプールに体系化され、各前記リソースプールが関連付けられた使用量コストを有する、前記決定することと、
　前記リソースマネージャが、前記複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了する推定コスト及び前記割り込み可能性特性に基づいて、前記コンピューティングリソースのうちの１つ以上を選択することと、
　前記リソースマネージャが、前記選択された１つ以上のコンピューティングリソースを使用して、スケジュール設定された時刻に前記タスクの前記実行を開始することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、開始することと、を含む、コンピュータ実装方法。
　　【請求項２】
　前記必要期限時刻前に前記タスクの前記実行の前記完了を確実にすることをさらに含む、請求項１に記載の方法。
　　【請求項３】
　前記リソースマネージャが、前記タスクの前記実行のために、前記１つ以上のクラウドベースのコンピューティングリソースの構成を選択することをさらに含み、前記構成が、実行ウィンドウ内で前記タスクの前記実行のコストを最小限に抑えるように選択され、前記実行ウィンドウのエンドポイントが、前記必要期限時刻に基づく、請求項１に記載の方法。
　　【請求項４】
　前記複数のコンピューティングリソースが、使用量コストの面で異なり、前記コンピューティングリソースのうちの１つ以上を選択することが、
　前記必要期限時刻前に、前記タスクの前記実行の完了を可能にする、それぞれの推定期間を有する前記複数のコンピューティングリソースのうちの前記コンピューティングリソースから、最低の使用量コストを有する前記１つ以上のコンピューティングリソースを選択することを含み、
　前記タスクの前記実行が、前記選択された１つ以上のコンピューティングリソースを使用して、前記スケジュール設定された時刻に開始される、請求項１に記載の方法。
　　【請求項５】
　前記タスクの前記実行を完了するための前記推定期間が、前記タスクの１つ以上の以前の実行に基づいて決定される、請求項１に記載の方法。
　　【請求項６】
　前記タスクの前記実行を完了するための前記推定期間が、１つ以上の他のタスクの以前の実行に基づいて決定される、請求項１に記載の方法。
　　【請求項７】
　前記１つ以上のコンピューティングリソースが、前記タスク及び１つ以上の追加のタスクを実行するグローバルコストを最小限に抑えるように選択され、前記タスク及び前記１つ以上の追加のタスクの定義のそれぞれは、前記必要期限時刻を含み、前記１つ以上のコンピューティングリソースは、前記タスク及び前記１つ以上の追加のタスクのそれぞれの実行のためにそれぞれ選択される、請求項１に記載の前記方法。
　　【請求項８】
　前記タスクの前記実行のための顧客価格を評価することをさらに含み、前記顧客価格が、前記必要期限時刻に基づく割引を含む、請求項１に記載の方法。
　　【請求項９】
　前記タスクのための実行ウィンドウが、第１の時点で開始し、かつ第２の時点で終了し、前記第１の時点が、前記タスクの前記定義が受信される時点を含み、前記第２の時点が、前記必要期限時刻に基づき、前記割引が、前記実行ウィンドウの大きさに基づいて異なる、請求項８に記載の方法。
　　【請求項１０】
　少なくとも１つのプロセッサと、
　前記少なくとも１つのプロセッサに連結されたメモリであって、前記メモリが、プログラム命令を記憶し、前記プログラム命令が、前記少なくとも１つのプロセッサによって実行可能であって、
　　リソースマネージャが、タスクの必要期限時刻を受信することであって、前記必要期限時刻が、前記タスクの実行の完了の期限を含み、前記タスクは割り込み可能性特性に関連する、受信することと、
　　前記リソースマネージャが、クラウドベースの複数のリソース構成の各々に対して前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のリソース構成は、複数のリソースプールに体系化され、前記複数のリソース構成の各々が、それぞれの使用量コストを有する、決定することと、
　　前記リソースマネージャが、実行ウィンドウ内で前記タスクの前記実行のコストを最小限に抑えるように、前記タスクの前記実行を完了する推定コスト及び前記割り込み可能性特性に基づいて、前記リソース構成のうちの１つ以上を選択することであって、前記実行ウィンドウのエンドポイントが、前記必要期限時刻に基づく、選択することと、
　　前記リソースマネージャが、前記選択された１つ以上のリソース構成を有する１つ以上の計算インスタンス上の前記タスクの前記実行のためのスケジュール設定された時刻を決定することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、決定することと、を行うように実行可能である、メモリと、を備える、システム。
　　【請求項１１】
　前記１つ以上のリソース構成が、前記タスク及び１つ以上の追加のタスクの実行のグローバルコストを最小限に抑えるように選択され、前記タスク及び前記１つ以上の追加のタスクのそれぞれは、前記必要期限時刻を含み、前記１つ以上のリソース構成は、前記タスク及び前記１つ以上の追加のタスクのそれぞれの実行のためにそれぞれ選択される、請求項１０に記載のシステム。
　　【請求項１２】
　前記リソース構成のうちの１つ以上を選択する際に、前記プログラム命令が、前記少なくとも１つのプロセッサによって、
　前記必要期限時刻前に、前記タスクの前記実行の完了を可能にする、それぞれの推定期間を有する前記複数のリソース構成のうちの前記リソース構成から、最低の使用量コストを有する前記１つ以上のリソース構成を選択するようにさらに実行可能である、請求項１０に記載のシステム。
　　【請求項１３】
　前記タスクの前記実行を完了するための前記推定期間が、前記タスクの１つ以上の以前の実行に基づいて決定される、請求項１０に記載のシステム。
　　【請求項１４】
　前記プログラム命令が、前記少なくとも１つのプロセッサによって、
　前記タスクの前記実行のための顧客価格を決定するようにさらに実行可能であり、前記顧客価格が、前記必要期限時刻に基づく割引を含む、請求項１０に記載のシステム。
　　【請求項１５】
　前記タスクのための実行ウィンドウが、第１の時点で開始し、かつ第２の時点で終了し、前記第１の時点が、前記タスクの前記定義が受信される時点を含み、前記第２の時点が、前記必要期限時刻に基づき、前記割引が、前記実行ウィンドウの大きさに基づいて異なる、請求項１４に記載のシステム。」（以下，この特許請求の範囲に記載された請求項各項を「補正前の請求項」という。）
　
を，
　
「　【請求項１】
　リソースマネージャが、タスクの定義を受信することであって、前記定義が、必要期限時刻を含み、前記必要期限時刻が、前記タスクの実行の完了に対するユーザー指定期限を含み、前記タスクは割り込み可能性特性に関連する、受信することと、
　前記リソースマネージャが、クラウドベースの複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のコンピューティングリソースは、複数のリソースプールに体系化され、各前記リソースプールが関連付けられた使用量コストを有
し、前記推定期間は、前記クラウドベースの複数のコンピューティングリソースを使用して前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定され
　前記リソースマネージャが、前記複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了する推定コスト及び前記割り込み可能性特性に基づいて、前記コンピューティングリソースのうちの１つ以上を選択することと、
　前記リソースマネージャが、前記選択された１つ以上のコンピューティングリソースを使用して、スケジュール設定された時刻に前記タスクの前記実行を開始することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、開始することと、を含む、コンピュータ実装方法。
　　【請求項２】
　前記必要期限時刻前に前記タスクの前記実行の前記完了を確実にすることをさらに含む、請求項１に記載の方法。
　　【請求項３】
　前記リソースマネージャが、前記タスクの前記実行のために、前記１つ以上のクラウドベースのコンピューティングリソースの構成を選択することをさらに含み、前記構成が、実行ウィンドウ内で前記タスクの前記実行のコストを最小限に抑えるように選択され、前記実行ウィンドウのエンドポイントが、前記必要期限時刻に基づく、請求項１に記載の方法。
　　【請求項４】
　前記複数のコンピューティングリソースが、使用量コストの面で異なり、前記コンピューティングリソースのうちの１つ以上を選択することが、
　前記必要期限時刻前に、前記タスクの前記実行の完了を可能にする、それぞれの推定期間を有する前記複数のコンピューティングリソースのうちの前記コンピューティングリソースから、最低の使用量コストを有する前記１つ以上のコンピューティングリソースを選択することを含み、
　前記タスクの前記実行が、前記選択された１つ以上のコンピューティングリソースを使用して、前記スケジュール設定された時刻に開始される、請求項１に記載の方法。
　　【請求項５】
　前記１つ以上のコンピューティングリソースが、前記タスク及び１つ以上の追加のタスクを実行するグローバルコストを最小限に抑えるように選択され、前記タスク及び前記１つ以上の追加のタスクの定義のそれぞれは、前記必要期限時刻を含み、前記１つ以上のコンピューティングリソースは、前記タスク及び前記１つ以上の追加のタスクのそれぞれの実行のためにそれぞれ選択される、請求項１に記載の前記方法。
　　【請求項６】
　前記タスクの前記実行のための顧客価格を評価することをさらに含み、前記顧客価格が、前記必要期限時刻に基づく割引を含む、請求項１に記載の方法。
　　【請求項７】
　前記タスクのための実行ウィンドウが、第１の時点で開始し、かつ第２の時点で終了し、前記第１の時点が、前記タスクの前記定義が受信される時点を含み、前記第２の時点が、前記必要期限時刻に基づき、前記割引が、前記実行ウィンドウの大きさに基づいて異なる、請求項
６
　　【請求項８】
　少なくとも１つのプロセッサと、
　前記少なくとも１つのプロセッサに連結されたメモリであって、前記メモリが、プログラム命令を記憶し、前記プログラム命令が、前記少なくとも１つのプロセッサによって実行可能であって、
　　リソースマネージャが、タスクの必要期限時刻を受信することであって、前記必要期限時刻が、前記タスクの実行の完了の期限を含み、前記タスクは割り込み可能性特性に関連する、受信することと、
　　前記リソースマネージャが、クラウドベースの複数のリソース構成の各々に対して前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のリソース構成は、複数のリソースプールに体系化され、前記複数のリソース構成の各々が、それぞれの使用量コストを有
し、前記推定期間は、前記クラウドベースの複数のリソース構成を使用して前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定される、前記
　　前記リソースマネージャが、実行ウィンドウ内で前記タスクの前記実行のコストを最小限に抑えるように、前記タスクの前記実行を完了する推定コスト及び前記割り込み可能性特性に基づいて、前記リソース構成のうちの１つ以上を選択することであって、前記実行ウィンドウのエンドポイントが、前記必要期限時刻に基づく、選択することと、
　　前記リソースマネージャが、前記選択された１つ以上のリソース構成を有する１つ以上の計算インスタンス上の前記タスクの前記実行のためのスケジュール設定された時刻を決定することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、決定することと、を行うように実行可能である、メモリと、を備える、システム。
　　【請求項９】
　前記１つ以上のリソース構成が、前記タスク及び１つ以上の追加のタスクの実行のグローバルコストを最小限に抑えるように選択され、前記タスク及び前記１つ以上の追加のタスクのそれぞれは、前記必要期限時刻を含み、前記１つ以上のリソース構成は、前記タスク及び前記１つ以上の追加のタスクのそれぞれの実行のためにそれぞれ選択される、請求項
８
　　【請求項１０】
　前記リソース構成のうちの１つ以上を選択する際に、前記プログラム命令が、前記少なくとも１つのプロセッサによって、
　前記必要期限時刻前に、前記タスクの前記実行の完了を可能にする、それぞれの推定期間を有する前記複数のリソース構成のうちの前記リソース構成から、最低の使用量コストを有する前記１つ以上のリソース構成を選択するようにさらに実行可能である、請求項
８
　　【請求項１１】
　前記プログラム命令が、前記少なくとも１つのプロセッサによって、
　前記タスクの前記実行のための顧客価格を決定するようにさらに実行可能であり、前記顧客価格が、前記必要期限時刻に基づく割引を含む、請求項
８
　　【請求項１２】
　前記タスクのための実行ウィンドウが、第１の時点で開始し、かつ第２の時点で終了し、前記第１の時点が、前記タスクの前記定義が受信される時点を含み、前記第２の時点が、前記必要期限時刻に基づき、前記割引が、前記実行ウィンドウの大きさに基づいて異なる、請求項
１１
（なお，下線は，補正箇所を示すものとして，出願人が付与したものである。）
に補正するものである。
イ　そして，本件補正は，本件補正前の請求項１記載の発明を特定するための事項（以下，「発明特定事項」という。）であるところの「前記リソースマネージャが、クラウドベースの複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のコンピューティングリソースは、複数のリソースプールに体系化され、各前記リソースプールが関連付けられた使用量コストを有する、前記決定すること」を「前記リソースマネージャが、クラウドベースの複数のリソース構成の各々に対して前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のリソース構成は、複数のリソースプールに体系化され、前記複数のリソース構成の各々が、それぞれの使用量コストを有し、前記推定期間は、前記クラウドベースの複数のリソース構成を使用して前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定される、前記決定すること」に限定し，本件補正前の請求項１０記載の発明定事項であるところの「前記リソースマネージャが、クラウドベースの複数のリソース構成の各々に対して前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のリソース構成は、複数のリソースプールに体系化され、前記複数のリソース構成の各々が、それぞれの使用量コストを有する、決定すること」を「前記リソースマネージャが、クラウドベースの複数のリソース構成の各々に対して前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のリソース構成は、複数のリソースプールに体系化され、前記複数のリソース構成の各々が、それぞれの使用量コストを有し、前記推定期間は、前記クラウドベースの複数のリソース構成を使用して前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定される、前記決定すること」に限定して本件補正後の請求項８記載の発明特定事項とするものであり，この限定によって，本件補正前後の請求項１，及び本件補正前の請求項１０と本件補正後の請求項８に係る発明の産業上の利用分野及び解決しようとする課題が格別変更されるものではない。
　したがって，本件補正の目的は，請求項に記載した発明特定事項を限定するものであって，その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるもの（以下，「限定的減縮」という。）に該当し，特許法第１７条の２第４項第２号に掲げられる事項を目的とするものであると解することができる。
２　独立特許要件
　以上のように，本件補正後の請求項１に記載された発明（以下，「本件補正発明」という。）は，補正前の請求項１に対して，限定的減縮を行ったものと認められる。そこで，本件補正発明が特許出願の際独立して特許を受けることができるものであるか（平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）以下に検討する。
（１）補正後の発明
　本件補正発明は，前記「１．補正の内容」において，補正後の請求項１として引用した，次の記載のとおりのものである。
　
「リソースマネージャが、タスクの定義を受信することであって、前記定義が、必要期限時刻を含み、前記必要期限時刻が、前記タスクの実行の完了に対するユーザー指定期限を含み、前記タスクは割り込み可能性特性に関連する、受信することと、
　前記リソースマネージャが、クラウドベースの複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のコンピューティングリソースは、複数のリソースプールに体系化され、各前記リソースプールが関連付けられた使用量コストを有し、前記推定期間は、前記クラウドベースの複数のコンピューティングリソースを使用して前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定される、前記決定することと、
　前記リソースマネージャが、前記複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了する推定コスト及び前記割り込み可能性特性に基づいて、前記コンピューティングリソースのうちの１つ以上を選択することと、
　前記リソースマネージャが、前記選択された１つ以上のコンピューティングリソースを使用して、スケジュール設定された時刻に前記タスクの前記実行を開始することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、開始することと、を含む、コンピュータ実装方法。」
（２）引用文献に記載されている技術的事項及び引用発明の認定
ア　本願の優先日前に頒布（又は電気通信回線を通じて公衆に利用可能となった文献である）され，原審の拒絶査定の理由である平成２９年７月２６日付けの拒絶理由通知において引用された文献である，米国特許出願公開第２０１２／０１３１５９１号明細書（２０１２年５月２４日出願公開。以下，「引用文献」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ａ　「[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
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] 様々な実施形態は，従来のクラウド計算システムに関するいくつかの問題を解決する。一実施形態は，複数のクラウド計算プロバイダによって提供されるリアルタイムの価格及び入手可能性情報に基づいて，インテリジェントクラウド計算価格付けモデルを開発する。別の実施形態は，クラウド計算市場をホスティングし，計算プロバイダは，それらのリソースを登録することができ，複数のプロバイダ間で自動的に分配されるように，
消費者は，仕事，及び，時間，コスト，機能の既知の制約を提出することができる
ある環境では，クラウドリソース（計算，記憶装置，その他の交換可能なサービスなど）が，効率的な市場でシームレスに割り当てられる環境が提供される。
Ｂ　「[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 request for pricing and availability can trigger provider manager to query 1302B individual providers to determine price/availability.
（当審訳：[0091] 図13は，実施例のコンポーネントアーキテクチャ，及び通信フローを示す図である。図示される例示的システムには，4つの高レベルの構成要素がある。顧客1320は，クラウド計算市場とやりとりする。顧客は，価格決定システム1324によって利用可能にされたウェブを介して，ユーザインタフェースにアクセスすることができる。
価格決定システムは，ユーザインタフェース1322を介して，顧客画面1326を生成し，顧客に提供する。ユーザインタフェースは，顧客が，ジョブの完了のために，計算ジョブおよび任意の既知のまたは所望の制約1301を供給することを可能にするように構成される。
価格付けおよび入手可能性の要求は，プロバイダマネージャに，1302Bで個々のプロバイダに問い合わせて，価格付け／入手可能性を決定させることができる。
[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.
（当審訳：[0092]
 1303において，提出されたタスクの価格及び／またはデッドラインの見積もりは，顧客画面1326において顧客に提供される。顧客は，計算タスクを実行することを望む場合，顧客は，価格及び／またはデッドラインに同意することができ，ジョブは1305で実行のためにコミットされる。ジョブマネージャ1340は，プロバイダマネージャ1330との対話を通じて，割り当てられた計算プロバイダでジョブ情報を管理し，サブタスクを分配し，サブタスク1306を開始するように構成される。
Ｃ　「[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.
（当審訳：[0113] 図15は，新たなジョブを投入するユーザインタフェース1502によって提供される画面の例を示している。図示されるように，新しいジョブを投入するには，固定サイズ1504または無制限サイズ1506の２つの方法がある。ジョブが固定サイズのジョブである場合，顧客は，完了するための仮想マシン時間を1510で，サイズを1508で，指定することができる。設定によっては，システムは，投入されたタスクの分析に基づいて，ジョブのサイズを自動的に決定することができる。ディスプレイ1518によってトリガされるアップロード操作を実行することによって，ユーザインタフェース1516で指定された所与の場所から，計算ジョブをアップロードすることができる。
顧客は，所与のジョブの名前を指定することもできる。ジョブを完了するためのデッドライン及び／または予算も同様に，それぞれ1512，1514で指定することができる。
Ｄ　「[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 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.
（当審訳：[0115] 図16は，見積もり確認画面1602の一例を示す図である。
一実施形態によれば，ジョブを開始する前に，ユーザは，ジョブ見積もりオブジェクトの形で，見積もりを承認しなければならない。
見積もり確認画面は，開始時間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.
（当審訳：[0116] 
デッドラインが切れる前にユーザが見積もりを承認すると，UIコントローラは，ジョブ見積もりに基づいてジョブを開始するために，ジョブバックエンドを呼び出す。
Ｅ　「[0146] 
FIG. 18 illustrates an example view of a job detail screen. The job Detail view
can include current status, estimates
（当審訳：[0146] 
図18は，ジョブ詳細画面の一例を示す画面である。ジョブ詳細画面は
現在の状態，見積もり
を含むことができる
イ　ここで，上記引用文献に記載されている事項を検討する。
（ア）上記Ａの「A cloud compute system and/or method can then seamlessly parcel out compute work among multiple providers to generate optimal cloud compute execution.（クラウド計算システム及び／または方法は，最適なクラウド計算実行を生成するために，複数のプロバイダ間で計算作業をシームレスに分割することができる。）」との記載からすると，引用文献には，“最適なクラウド計算実行を生成するために，複数のプロバイダ間で計算作業をシームレスに分割することができるクラウド計算方法”が記載されている。
（イ）上記Ｂの「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を供給することを可能にするように構成される。）」との記載，上記Ａの「consumers can submit work and any known constraints of time, cost, and features（消費者は，仕事，及び，時間，コスト，機能の既知の制約を提出することができる）」との記載，及び上記Ｃの「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で指定することができる。）」との記載からすると，引用文献には，“価格決定システムは，ユーザインタフェースを介して，顧客画面を生成し，顧客に提供し，前記ユーザインタフェースは，顧客が，ジョブの完了のために，所望の制約（時間，コストなど）を供給することを可能にするように構成され，顧客は，ジョブを完了するためのデッドラインも同様に指定することができ”る態様が記載されている。
（ウ）上記Ａの「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.（ある環境では，クラウドリソース（計算，記憶装置，その他の交換可能なサービスなど）が，効率的な市場でシームレスに割り当てられる環境が提供される。）」との記載，上記Ｂの「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を開始するように構成される。）」との記載，及び上記Ｄの「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を反映するように構成することができる。）」との記載からすると，引用文献には，“ある環境では，クラウドリソース（計算，記憶装置など）が，シームレスに割り当てられ，提出されたデッドラインの見積もりは，顧客画面において顧客に提供され，見積もり確認画面は，開始時間，完了時間を反映するように構成され，顧客は，計算タスクを実行することを望む場合，デッドラインに同意することができ，ジョブは実行のためにコミットされ，ジョブマネージャは，サブタスクを分配し，サブタスクを開始するように構成され”る態様が記載されている。
（エ）上記Ａの「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.（いくつかの実施形態では，クラウド計算市場は，異なるプロバイダによる実行のために，与えられた計算ジョブを翻訳する際のサイクル及び／または時間に関して，コストを考慮に入れることができる。）」との記載からすると，引用文献には，“クラウド計算プロバイダのセットは，価格，性能，及び他の機能によって階層化された，交換可能な商品としてクラウド計算サイクルを扱うことが可能であり，クラウド計算市場は，異なるプロバイダによる実行のために，コストを考慮に入れることができ”る態様が記載されている。
（オ）上記Ｅの「FIG. 18 illustrates an example view of a job detail screen. The job Detail view…（中略）…can include current status, estimates（図18は，ジョブ詳細画面の一例を示す画面である。ジョブ詳細画面は…（中略）…現在の状態，見積もり…（中略）…を含むことができる）」との記載からすると，引用文献には，“ジョブ詳細画面は，現在の状態，見積もりを含むことができ”る態様が記載されている。
（カ）上記Ｂの「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を開始するように構成される。）」との記載からすると，引用文献には，“価格付けの要求は，プロバイダマネージャに，価格付けを決定させることができ，提出されたタスクの価格の見積もりは，顧客画面において顧客に提供され，顧客は，計算タスクを実行することを望む場合，顧客は，価格に同意することができ，ジョブは実行のためにコミットされ，ジョブマネージャは，サブタスクを分配し，サブタスクを開始するように構成され”る態様が記載されている。
（キ）上記Ｄの「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コントローラは，ジョブ見積もりに基づいてジョブを開始するために，ジョブバックエンドを呼び出す。）」との記載からすると，引用文献には，“ユーザが見積もりを承認すると，UIコントローラは，ジョブ見積もりに基づいてジョブを開始”する態様が記載されている。
（ク）上記Ｄの「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を反映するように構成することができる。）」，及び上記Ｂの「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を開始するように構成される。）」との記載からすると，引用文献には，“ジョブを開始する前に，ユーザが見積もりを承認する見積もり確認画面は，開始時間，完了時間を反映するように構成することができ，顧客は，計算タスクを実行することを望む場合，デッドラインに同意することができ，ジョブは実行のためにコミットされ，サブタスクを開始するように構成され”る態様が記載されている。
ウ　以上，（ア）ないし（ク）で指摘した事項を踏まえると，引用文献には，次の発明（以下，「引用発明」という。）が記載されているものと認められる。
　最適なクラウド計算実行を生成するために，複数のプロバイダ間で計算作業をシームレスに分割することができるクラウド計算方法において，
　価格決定システムは，ユーザインタフェースを介して，顧客画面を生成し，顧客に提供し，前記ユーザインタフェースは，顧客が，ジョブの完了のために，所望の制約（時間，コストなど）を供給することを可能にするように構成され，顧客は，ジョブを完了するためのデッドラインも同様に指定することができ，
　ある環境では，クラウドリソース（計算，記憶装置など）が，シームレスに割り当てられ，提出されたデッドラインの見積もりは，顧客画面において顧客に提供され，見積もり確認画面は，開始時間，完了時間を反映するように構成され，顧客は，計算タスクを実行することを望む場合，デッドラインに同意することができ，ジョブは実行のためにコミットされ，ジョブマネージャは，サブタスクを分配し，サブタスクを開始するように構成され， 
　クラウド計算プロバイダのセットは，価格，性能，及び他の機能によって階層化された，交換可能な商品としてクラウド計算サイクルを扱うことが可能であり，クラウド計算市場は，異なるプロバイダによる実行のために，コストを考慮に入れることができ，
　ジョブ詳細画面は，現在の状態，見積もりを含むことができ，
　価格付けの要求は，プロバイダマネージャに，価格付けを決定させることができ，提出されたタスクの価格の見積もりは，顧客画面において顧客に提供され，顧客は，計算タスクを実行することを望む場合，顧客は，価格に同意することができ，ジョブは実行のためにコミットされ，ジョブマネージャは，サブタスクを分配し，サブタスクを開始するように構成され，
　ユーザが見積もりを承認すると，UIコントローラは，ジョブ見積もりに基づいてジョブを開始するものであり，当該ジョブを開始する前に，ユーザが見積もりを承認する見積もり確認画面は，開始時間，完了時間を反映するように構成することができ，顧客は，計算タスクを実行することを望む場合，デッドラインに同意することができ，ジョブは実行のためにコミットされ，サブタスクを開始するように構成される，こととを含む，方法。
（３）参考文献に記載されている技術的事項
（３−１）参考文献１
　本願の優先日前に頒布（又は電気通信回線を通じて公衆に利用可能となった文献である）され，原審の拒絶査定において引用された文献である，特開２０１２−９３８３２号公報（平成２４年５月１７日出願公開。以下，「参考文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｆ　「【要約】
【課題】メモリ領域を効率良く使用すると共に、スタック領域のオーバーフロー等の不都合を防止すること。
【解決手段】複数のタスクを所定のスケジュールに従って起床するスケジューラと、前記複数のタスクにより使用され、所定の領域がスタック領域として設定された共有メモリと、タスク毎のスタック使用量及び最大処理時間を記憶した記憶手段と、を備え、
スケジューラは、複数のタスクのうち一のタスクを起床しようとする際に
当該タスクに割り込み可能なタスクを抽出
（３−２）参考文献２
　本願の優先日前に頒布（又は電気通信回線を通じて公衆に利用可能となった文献である）され，原審の拒絶査定において引用された文献である，特開２００３−２０８３２０号公報（平成１５年７月２５日出願公開。以下，「参考文献２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｇ　「【請求項１】実行優先度を示すタスクレベルが設定され、切り換えられて実行されるタスクと、
該タスクの起床要求及び、前記タスクレベルに基づき、前記タスクの切り換えを行うリアルタイムオペレーティングシステムと、
前記タスクに割り込んで実行され、実行優先度を示す割込レベルが設定された割込処理とで少なくとも構成される制御プログラムを搭載した電子制御装置において、前記制御プログラムは、
所定のタスク内に、前記割込レベルをマスクレベルとして指定することにより、当該割込レベル以下の前記割込処理の割り込み及び、前記タスクの切り換えを禁止する割込禁止区間が設定されており、
前記割込禁止区間の終了時に前記
タスクの切り換えがなされる可能性の有無をコーディングの際に予め判断することにより、当該可能性が無ければ、前記割込禁止区間の終了時に、前記タスクの切り換えを行うためのタスクスケジューリング処理を実行しない
Ｈ　「【００１２】そこで次に、割込禁止区間について説明する。タスクの実行途中に実行優先度の高い割込処理が割り込むことは、既に述べた。しかし、
タスクと割込処理でリソースを共有している場合など、割り込みのタイミングによっては、リソースの干渉が生じることがある
（３−３）参考文献３
　本願の優先日前に頒布（又は電気通信回線を通じて公衆に利用可能となった文献である）され，原審の拒絶査定において引用された文献である，特表２００７−５１１８１９号公報（平成１９年５月１０日出願公表。以下，「参考文献３」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｊ　「【要約】
多重処理のデータ処理システムのスケジューラによる使用のための、メインメモリ要求および排他的なリソース使用に基づいてタスク優先割り込み点を選択する方法
（３−４）参考文献４
　本願の優先日前に頒布（又は電気通信回線を通じて公衆に利用可能となった文献である）された文献である，特開２０１０−１５２７３８号公報（平成２２年７月８日出願公開。以下，「参考文献４」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｋ　「【００２３】
　
完了予測部２７０は、確保されたリソース上で指定処理を実行中に、当該リソースが確保された時間内に指定処理が完了するか否かを予測する。完了予測部２７０は
当該指定処理の実行状態の監視結果
に基づいて、確保時間内に指定処理が完了するか否かを予測
（３−５）参考文献５
　本願の優先日前に頒布（又は電気通信回線を通じて公衆に利用可能となった文献である）された文献である，特表２００７−５２４９５１号公報（平成１９年８月３０日出願公表。以下，「参考文献５」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｌ　「【請求項１５】
　
複数のコンピューティング・リソースからなるグリッド
を含むネットワーク・システムで実行される方法であって、
　顧客の１つまたは複数のコンピュータ・システムが、前記要求マネージャに結合され、さらに、１つまたは複数のプロセッサと、前記１つまたは複数のプロセッサのうちの少なくとも１つに結合されたメモリと、前記メモリ内に常駐し、前記少なくとも１つのプロセッサによって実行可能なスケジューリング・マネージャとを含み、
　
少なくとも１つの事前定義された照会時間境界に関するデータに関して照会のランタイムを評価するステップと、
　前記照会時間境界内に前記照会の実行を完了するために割り振るべきコンピュータ・リソースの適切な量を動的に予測するステップとを含み、
　前記要求マネージャが、
前記動的予測に基づいて、前記グリッド・コンピューティング・リソースのコンピューティング・リソースについて動的に割振り／割振り解除を行う、方法
（４）本件補正発明と引用発明との対比
ア　本件補正発明と引用発明とを対比する。
（ア）引用発明の「価格決定システム」，「ジョブ」，「所望の制約」，「時間」，及び「デッドライン」は，それぞれ，本件補正発明の「リソースマネージャ」，「タスクの定義」，「定義」，「必要期限時刻」，及び「ユーザー指定期限」に対応付けられるものであるところ，引用発明の「時間」は，所望の制約の一つとして顧客によって供給されるものであることから，本件補正発明の「必要期限時刻」に相当するといえる。そうすると，引用発明の「価格決定システム」は，ユーザインタフェースを介して，顧客からジョブ完了のために所望の制約（時間，コストなど）を供給されるものであり，顧客は所望の制約としてデッドラインも同様に指定できるものであることから，引用発明の「価格決定システムは，ユーザインタフェースを介して，顧客画面を生成し，顧客に提供し，前記ユーザインタフェースは，顧客が，ジョブの完了のために，所望の制約（時間，コストなど）を供給することを可能にするように構成され，顧客は，ジョブを完了するためのデッドラインも同様に指定することができ」ることは，本件補正発明の「リソースマネージャが、タスクの定義を受信することであって、前記定義が、必要期限時刻を含み、前記必要期限時刻が、前記タスクの実行の完了に対するユーザー指定期限を含み、」「受信すること」と一致するといえる。
（イ）引用発明の「クラウドリソース（計算，記憶装置など）」，「完了時間」，「交換可能な商品」，「階層化」，及び「コスト」は，それぞれ，本件補正発明の「クラウドベースの複数のコンピューティングリソース」，「推定期間」，「リソースプール」，「体系化」，及び「使用量コスト」に対応付けられる。ここで，引用発明の価格決定システムは，ジョブの実行がコミットされると，サブタスクを分配し，サブタスクを開始するように構成されているものであるから，見積もり確認画面において顧客にジョブの「完了時間」を提供する際には，分配される各サブタスクの実行が完了する時間を決定しているものと認められる。また，引用発明の「クラウド計算プロバイダのセット」は，複数のクラウドリソースがシームレスに割り当てられるものであり，当該複数のクラウドリソースは，価格，性能，及び他の機能によって階層化され，交換可能な商品として扱うことが可能であり，コストを考慮に入れることができるものであると認められる。してみると，引用発明の「ある環境では，クラウドリソース（計算，記憶装置など）が，シームレスに割り当てられ，提出されたデッドラインの見積もりは，顧客画面において顧客に提供され，見積もり確認画面は，開始時間，完了時間を反映するように構成され，顧客は，計算タスクを実行することを望む場合，完了時間に同意することができ，ジョブは実行のためにコミットされ，ジョブマネージャは，サブタスクを分配し，サブタスクを開始するように構成され，クラウド計算プロバイダのセットは，価格，性能，及び他の機能によって階層化された，交換可能な商品としてクラウド計算サイクルを扱うことが可能であり，クラウド計算市場は，異なるプロバイダによる実行のために，コストを考慮に入れることができ」ることは，本件補正発明の「前記リソースマネージャが、クラウドベースの複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のコンピューティングリソースは、複数のリソースプールに体系化され、各前記リソースプールが関連付けられた使用量コストを有し、」「決定すること」と一致するといえる。
（ウ）引用発明の「価格の見積もり」は，本件補正発明の「推定コスト」に対応付けられるものであるところ，引用発明の「価格の見積もり」は，価格決定システムにおける顧客画面において顧客に提供され，顧客が同意すると，ジョブマネージャが，サブタスクを分配するように構成されるものであることから，サブタスクは，価格の見積もりに基づいて，複数のクラウドリソースのうちの少なくとも１つ以上を選択して分配されるものと認められる。してみると，引用発明の「価格付けの要求は，プロバイダマネージャに，個々のプロバイダに問い合わせて，価格付けを決定させることができ，提出されたタスクの価格の見積もりは，顧客画面において顧客に提供され，顧客は，計算タスクを実行することを望む場合，顧客は，価格に同意することができ，ジョブは実行のためにコミットされ，ジョブマネージャは，サブタスクを分配し，サブタスクを開始するように構成され」ることは，本件補正発明の「前記リソースマネージャが、前記複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了する推定コスト」「に基づいて、前記コンピューティングリソースのうちの１つ以上を選択すること」と一致するといえる。
（エ）引用発明の「開始時間」及び「完了時間」は，本件補正発明の「スケジュール設定された時刻」及び「推定期間」に対応付けられるものであるところ，引用発明の「開始時間」及び「完了時間」は，価格決定システムにおける顧客画面において顧客に提供され，顧客が同意すると，サブタスクを開始するように構成されているものであるから，上記（ウ）の検討結果を踏まえると，引用発明は，選択された１つ以上の複数のクラウドリソースを使用して，開始時間にジョブを開始するものであると認められる。してみると，引用発明の「ユーザが見積もりを承認すると，UIコントローラは，ジョブ見積もりに基づいてジョブを開始するものであり，当該ジョブを開始する前に，ユーザが見積もりを承認する見積もり確認画面は，開始時間，完了時間を反映するように構成することができ，顧客は，計算タスクを実行することを望む場合，デッドラインに同意することができ，ジョブは実行のためにコミットされ，サブタスクを開始するように構成される」ことは，本件補正発明の「前記リソースマネージャが、前記選択された１つ以上のコンピューティングリソースを使用して、スケジュール設定された時刻に前記タスクの前記実行を開始すること」と一致するといえる。
（オ）上記（ア）ないし（エ）の検討結果を踏まえると，引用発明の「クラウド計算方法」は，本件補正発明の「コンピュータ実装方法」に相当するといえる。
イ　以上から，本件補正発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
（一致点）
　リソースマネージャが，タスクの定義を受信することであって，前記定義が，必要期限時刻を含み，前記必要期限時刻が，前記タスクの実行の完了に対するユーザー指定期限を含み，受信することと，
　前記リソースマネージャが，クラウドベースの複数のコンピューティングリソースの各々に対して，前記タスクの前記実行を完了するための推定期間を決定することであって，前記複数のコンピューティングリソースは，複数のリソースプールに体系化され，各前記リソースプールが関連付けられた使用量コストを有し，決定することと，
　前記リソースマネージャが，前記複数のコンピューティングリソースの各々に対して，前記タスクの前記実行を完了する推定コストに基づいて，前記コンピューティングリソースのうちの１つ以上を選択することと，
　前記リソースマネージャが，前記選択された１つ以上のコンピューティングリソースを使用して，スケジュール設定された時刻に前記タスクの前記実行を開始することと，を含む，コンピュータ実装方法。
（相違点１）
　本件補正発明は，「タスクは割り込み可能性特性に関連する」ものであるのに対して，引用発明は，そのようなものではない点。
（相違点２）
　本件補正発明は，「前記リソースマネージャが、前記複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了する推定コスト及び前記割り込み可能性特性に基づいて、前記コンピューティングリソースのうちの１つ以上を選択する」ものであるのに対して，引用発明は，「コストを考慮に入れる」ものではあるが，割り込み可能性特性に基づくものではない点。
（相違点３）
　本件補正発明は，「推定期間は、前記クラウドベースの複数のコンピューティングリソースを使用して前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定される」ものであるのに対して，引用発明の「完了時間」がどのように決定されるものか明記されていない点。
（相違点４）
　本件補正発明は，「前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い」ものであるのに対して，引用発明は，見積もり確認画面にて提供される「開始時間」と「完了時間」が，「デッドライン」とどのような関係にあるか明記されていない点。
（５）当審の判断
ア　上記相違点１ないし相違点４について検討する。
（ア）相違点１及び相違点２について
　参考文献１の上記Ｆに「スケジューラは、複数のタスクのうち一のタスクを起床しようとする際に…（中略）…当該タスクに割り込み可能なタスクを抽出」と記載され，参考文献２の上記Ｇに「タスクの切り換えがなされる可能性の有無をコーディングの際に予め判断することにより、当該可能性が無ければ、前記割込禁止区間の終了時に、前記タスクの切り換えを行うためのタスクスケジューリング処理を実行しない」と記載され，参考文献３の上記Ｊに「多重処理のデータ処理システムのスケジューラによる使用のための、メインメモリ要求および排他的なリソース使用に基づいてタスク優先割り込み点を選択する方法」と記載されるように，タスクの割り込み可能性特性に関連してタスクのスケジュール管理を行うことは，当該技術分野において慣用的に行われている周知技術であった。また，参考文献３の上記Ｊの記載内容に加え，参考文献２の上記Ｈに「タスクと割込処理でリソースを共有している場合など、割り込みのタイミングによっては、リソースの干渉が生じることがある」と記載されるように，リソースの状況を考慮に入れて，タスクの割り込みを管理する技術についても，当該技術分野において周知技術であった。そして，引用発明と，参考文献１ないし参考文献３に記載された技術思想は，タスクのスケジューリングに関する技術である点で共通する。
　してみれば，引用発明に参考文献１ないし参考文献３に記載された技術思想を適用し，相違点１及び相違点２に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点１及び相違点２は格別なものではない。　
（イ）相違点３について
　引用発明は，「ジョブ詳細画面は，現在の状態，見積もりを含むことができ」るものであり，ユーザはジョブ開始前に，見積もり確認画面で「完了時間」を確認できる他，ジョブ開始後においても適宜，ジョブ詳細画面にて，ジョブの進行状況，時間やコストの見積もり等を確認できるものである。
　引用発明のジョブ詳細画面に表示される時間の見積もりがどのように決定されるのか，引用発明に明確な記載はないが，例えば，参考文献４の上記Ｋに「完了予測部２７０は、確保されたリソース上で指定処理を実行中に、当該リソースが確保された時間内に指定処理が完了するか否かを予測する。完了予測部２７０は…（中略）…当該指定処理の実行状態の監視結果…（中略）…に基づいて、確保時間内に指定処理が完了するか否かを予測」と記載され，参考文献５の上記Ｌに「複数のコンピューティング・リソースからなるグリッド…（中略）…を含むネットワーク・システムで実行される方法であって、…（中略）…少なくとも１つの事前定義された照会時間境界に関するデータに関して照会のランタイムを評価するステップと、前記照会時間境界内に前記照会の実行を完了するために割り振るべきコンピュータ・リソースの適切な量を動的に予測するステップとを含み、…（中略）…前記動的予測に基づいて、前記グリッド・コンピューティング・リソースのコンピューティング・リソースについて動的に割振り／割振り解除を行う、方法」と記載されるように，複数のコンピューティングリソースを使用して処理の一部を実行した段階で，それまでに要した処理時間から完了時間を動的に予測する技術は，当該技術分野において周知技術であった。そして，引用発明と，参考文献４及び参考文献５に記載された技術思想は，タスクの実行管理に関する技術である点で共通する。
　してみれば，引用発明に参考文献４及び参考文献５に記載された技術思想を適用し，相違点３に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点３は格別なものではない。　
（ウ）相違点４について
　引用発明の「見積もり確認画面」は，「ジョブを開始する前に，ユーザが見積もりを承認する」ためのものであり，実行するジョブをデッドライン内で処理するために，当該確認画面に提示される「開始時間」と「完了時間」について，「デッドライン」よりも早い時間となるようにスケジュールすることは当業者にとって必然である。
　してみれば，引用発明においても，相違点４に係る構成とすることは，当業者が容易に想到し得たことである。
　よって，相違点４は格別なものではない。　
イ　小括
　上記で検討したごとく，相違点１ないし相違点４は，いずれも格別のものではなく，そして，これらの相違点を総合的に勘案しても，本件補正発明の奏する作用効果は，上記引用発明及び周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　したがって，本件補正発明は，上記引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により，特許出願の際独立して特許を受けることができない。　
３　むすび
　
　以上のように，上記「２　独立特許要件」で指摘したとおり，補正後の請求項１に記載された発明は，特許出願の際独立して特許を受けることができるものではないから，本件補正は，特許法第１７条の２第６項において準用する同法第１２６条第７項の規定に違反するので，同法第１５９条第１項の規定において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　よって，補正却下の決定の結論のとおり決定する。
第３　本件審判請求の成否について 
１　本願発明の認定
　平成３０年６月２７日付けの手続補正は上記のとおり却下されたので，本願の請求項１に係る発明（以下，「本願発明」という。）は，平成２９年１１月７日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される，以下のとおりのものである。
　
「リソースマネージャが、タスクの定義を受信することであって、前記定義が、必要期限時刻を含み、前記必要期限時刻が、前記タスクの実行の完了に対するユーザー指定期限を含み、前記タスクは割り込み可能性特性に関連する、受信することと、
　前記リソースマネージャが、クラウドベースの複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のコンピューティングリソースは、複数のリソースプールに体系化され、各前記リソースプールが関連付けられた使用量コストを有する、前記決定することと、
　前記リソースマネージャが、前記複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了する推定コスト及び前記割り込み可能性特性に基づいて、前記コンピューティングリソースのうちの１つ以上を選択することと、
　前記リソースマネージャが、前記選択された１つ以上のコンピューティングリソースを使用して、スケジュール設定された時刻に前記タスクの前記実行を開始することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、開始することと、を含む、コンピュータ実装方法。」
　
２　引用文献に記載されている技術的事項及び引用発明の認定
　
　原査定の拒絶の理由に引用された，引用文献およびその記載事項は，前記「第２　平成３０年６月２７日付けの手続補正についての補正却下の決定」の「２　独立特許要件」の「（２）引用文献に記載されている技術的事項及び引用発明の認定」に記載したとおりである。
　
３　対比・判断 
　
　本願発明は，前記「第２　平成３０年６月２７日付けの手続補正についての補正却下の決定」の「２　独立特許要件」で検討した本件補正発明における「前記リソースマネージャが、クラウドベースの複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のコンピューティングリソースは、複数のリソースプールに体系化され、各前記リソースプールが関連付けられた使用量コストを有し、前記推定期間は、前記クラウドベースの複数のコンピューティングリソースを使用して前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定される、前記決定すること」の下線部の限定を省き，「前記リソースマネージャが、クラウドベースの複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のコンピューティングリソースは、複数のリソースプールに体系化され、各前記リソースプールが関連付けられた使用量コストを有する、前記決定すること」としたものである。
　そうすると，本願発明の発明特定事項を全て含む本件補正発明が，上記「第２　平成３０年６月２７日付けの手続補正についての補正却下の決定」の「２　独立特許要件」の「（３）参考文献に記載されている技術的事項」ないし「（５）当審の判断」に記載したとおり，引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから，本願発明も同様の理由により，引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものである。
４　むすび
　
　以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。
　
　よって，結論のとおり審決する。