• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
審判 査定不服 5項独立特許用件 特許、登録しない。 G06F
管理番号 1359394
審判番号 不服2018-8823  
総通号数 243 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2020-03-27 
種別 拒絶査定不服の審決 
審判請求日 2018-06-27 
確定日 2020-01-29 
事件の表示 特願2015-557200「コスト最小化タスクスケジューラ」拒絶査定不服審判事件〔平成26年 8月14日国際公開、WO2014/124448、平成28年 3月 7日国内公表、特表2016-507121〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯

本件審判請求に係る出願(以下,「本願」という。)は,2014年2月11日(パリ条約による優先権主張外国庁受理2013年2月11日,アメリカ合衆国)を国際出願日とする出願であって,平成27年8月11日に特許法第184条の5第1項に規定される書面の提出がなされ,同年8月28日付けで特許法第184条の4第1項の規定による国際出願日における明細書,請求の範囲,図面(図面の中の説明に限る。)及び要約の翻訳文の提出がなされるとともに,同日付けで審査請求がなされ,平成28年7月11日付けで拒絶理由通知(同年7月19日発送)がなされ,平成29年1月19日付けで意見書が提出されるとともに,同日付けで手続補正がなされ,同年7月26日付けで拒絶理由通知(同年8月8日発送)がなされ,同年11月7日付けで意見書が提出されるとともに,同日付けで手続補正がなされたが,平成30年2月15日付けで拒絶査定(同年2月27日謄本送達)がなされた。
これに対して,「原査定を取り消す、本願は特許をすべきものである、との審決を求める。」ことを請求の趣旨として,平成30年6月27日付けで本件審判請求がなされるとともに,同日付けで手続補正がなされたものである。

第2 平成30年6月27日付けの手続補正についての補正却下の決定

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

平成30年6月27日付けの手続補正を却下する。

[理由]

1 補正の内容

ア 平成30年6月27日付けの手続補正(以下,「本件補正」という。)の内容は,平成29年11月7日付けの手続補正により補正された特許請求の範囲の請求項1ないし請求項15の記載

「 【請求項1】
リソースマネージャが、タスクの定義を受信することであって、前記定義が、必要期限時刻を含み、前記必要期限時刻が、前記タスクの実行の完了に対するユーザー指定期限を含み、前記タスクは割り込み可能性特性に関連する、受信することと、
前記リソースマネージャが、クラウドベースの複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のコンピューティングリソースは、複数のリソースプールに体系化され、各前記リソースプールが関連付けられた使用量コストを有する、前記決定することと、
前記リソースマネージャが、前記複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了する推定コスト及び前記割り込み可能性特性に基づいて、前記コンピューティングリソースのうちの1つ以上を選択することと、
前記リソースマネージャが、前記選択された1つ以上のコンピューティングリソースを使用して、スケジュール設定された時刻に前記タスクの前記実行を開始することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、開始することと、を含む、コンピュータ実装方法。
【請求項2】
前記必要期限時刻前に前記タスクの前記実行の前記完了を確実にすることをさらに含む、請求項1に記載の方法。
【請求項3】
前記リソースマネージャが、前記タスクの前記実行のために、前記1つ以上のクラウドベースのコンピューティングリソースの構成を選択することをさらに含み、前記構成が、実行ウィンドウ内で前記タスクの前記実行のコストを最小限に抑えるように選択され、前記実行ウィンドウのエンドポイントが、前記必要期限時刻に基づく、請求項1に記載の方法。
【請求項4】
前記複数のコンピューティングリソースが、使用量コストの面で異なり、前記コンピューティングリソースのうちの1つ以上を選択することが、
前記必要期限時刻前に、前記タスクの前記実行の完了を可能にする、それぞれの推定期間を有する前記複数のコンピューティングリソースのうちの前記コンピューティングリソースから、最低の使用量コストを有する前記1つ以上のコンピューティングリソースを選択することを含み、
前記タスクの前記実行が、前記選択された1つ以上のコンピューティングリソースを使用して、前記スケジュール設定された時刻に開始される、請求項1に記載の方法。
【請求項5】
前記タスクの前記実行を完了するための前記推定期間が、前記タスクの1つ以上の以前の実行に基づいて決定される、請求項1に記載の方法。
【請求項6】
前記タスクの前記実行を完了するための前記推定期間が、1つ以上の他のタスクの以前の実行に基づいて決定される、請求項1に記載の方法。
【請求項7】
前記1つ以上のコンピューティングリソースが、前記タスク及び1つ以上の追加のタスクを実行するグローバルコストを最小限に抑えるように選択され、前記タスク及び前記1つ以上の追加のタスクの定義のそれぞれは、前記必要期限時刻を含み、前記1つ以上のコンピューティングリソースは、前記タスク及び前記1つ以上の追加のタスクのそれぞれの実行のためにそれぞれ選択される、請求項1に記載の前記方法。
【請求項8】
前記タスクの前記実行のための顧客価格を評価することをさらに含み、前記顧客価格が、前記必要期限時刻に基づく割引を含む、請求項1に記載の方法。
【請求項9】
前記タスクのための実行ウィンドウが、第1の時点で開始し、かつ第2の時点で終了し、前記第1の時点が、前記タスクの前記定義が受信される時点を含み、前記第2の時点が、前記必要期限時刻に基づき、前記割引が、前記実行ウィンドウの大きさに基づいて異なる、請求項8に記載の方法。
【請求項10】
少なくとも1つのプロセッサと、
前記少なくとも1つのプロセッサに連結されたメモリであって、前記メモリが、プログラム命令を記憶し、前記プログラム命令が、前記少なくとも1つのプロセッサによって実行可能であって、
リソースマネージャが、タスクの必要期限時刻を受信することであって、前記必要期限時刻が、前記タスクの実行の完了の期限を含み、前記タスクは割り込み可能性特性に関連する、受信することと、
前記リソースマネージャが、クラウドベースの複数のリソース構成の各々に対して前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のリソース構成は、複数のリソースプールに体系化され、前記複数のリソース構成の各々が、それぞれの使用量コストを有する、決定することと、
前記リソースマネージャが、実行ウィンドウ内で前記タスクの前記実行のコストを最小限に抑えるように、前記タスクの前記実行を完了する推定コスト及び前記割り込み可能性特性に基づいて、前記リソース構成のうちの1つ以上を選択することであって、前記実行ウィンドウのエンドポイントが、前記必要期限時刻に基づく、選択することと、
前記リソースマネージャが、前記選択された1つ以上のリソース構成を有する1つ以上の計算インスタンス上の前記タスクの前記実行のためのスケジュール設定された時刻を決定することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、決定することと、を行うように実行可能である、メモリと、を備える、システム。
【請求項11】
前記1つ以上のリソース構成が、前記タスク及び1つ以上の追加のタスクの実行のグローバルコストを最小限に抑えるように選択され、前記タスク及び前記1つ以上の追加のタスクのそれぞれは、前記必要期限時刻を含み、前記1つ以上のリソース構成は、前記タスク及び前記1つ以上の追加のタスクのそれぞれの実行のためにそれぞれ選択される、請求項10に記載のシステム。
【請求項12】
前記リソース構成のうちの1つ以上を選択する際に、前記プログラム命令が、前記少なくとも1つのプロセッサによって、
前記必要期限時刻前に、前記タスクの前記実行の完了を可能にする、それぞれの推定期間を有する前記複数のリソース構成のうちの前記リソース構成から、最低の使用量コストを有する前記1つ以上のリソース構成を選択するようにさらに実行可能である、請求項10に記載のシステム。
【請求項13】
前記タスクの前記実行を完了するための前記推定期間が、前記タスクの1つ以上の以前の実行に基づいて決定される、請求項10に記載のシステム。
【請求項14】
前記プログラム命令が、前記少なくとも1つのプロセッサによって、
前記タスクの前記実行のための顧客価格を決定するようにさらに実行可能であり、前記顧客価格が、前記必要期限時刻に基づく割引を含む、請求項10に記載のシステム。
【請求項15】
前記タスクのための実行ウィンドウが、第1の時点で開始し、かつ第2の時点で終了し、前記第1の時点が、前記タスクの前記定義が受信される時点を含み、前記第2の時点が、前記必要期限時刻に基づき、前記割引が、前記実行ウィンドウの大きさに基づいて異なる、請求項14に記載のシステム。」(以下,この特許請求の範囲に記載された請求項各項を「補正前の請求項」という。)

を,

「 【請求項1】
リソースマネージャが、タスクの定義を受信することであって、前記定義が、必要期限時刻を含み、前記必要期限時刻が、前記タスクの実行の完了に対するユーザー指定期限を含み、前記タスクは割り込み可能性特性に関連する、受信することと、
前記リソースマネージャが、クラウドベースの複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のコンピューティングリソースは、複数のリソースプールに体系化され、各前記リソースプールが関連付けられた使用量コストを有し、前記推定期間は、前記クラウドベースの複数のコンピューティングリソースを使用して前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定される、前記決定することと、
前記リソースマネージャが、前記複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了する推定コスト及び前記割り込み可能性特性に基づいて、前記コンピューティングリソースのうちの1つ以上を選択することと、
前記リソースマネージャが、前記選択された1つ以上のコンピューティングリソースを使用して、スケジュール設定された時刻に前記タスクの前記実行を開始することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、開始することと、を含む、コンピュータ実装方法。
【請求項2】
前記必要期限時刻前に前記タスクの前記実行の前記完了を確実にすることをさらに含む、請求項1に記載の方法。
【請求項3】
前記リソースマネージャが、前記タスクの前記実行のために、前記1つ以上のクラウドベースのコンピューティングリソースの構成を選択することをさらに含み、前記構成が、実行ウィンドウ内で前記タスクの前記実行のコストを最小限に抑えるように選択され、前記実行ウィンドウのエンドポイントが、前記必要期限時刻に基づく、請求項1に記載の方法。
【請求項4】
前記複数のコンピューティングリソースが、使用量コストの面で異なり、前記コンピューティングリソースのうちの1つ以上を選択することが、
前記必要期限時刻前に、前記タスクの前記実行の完了を可能にする、それぞれの推定期間を有する前記複数のコンピューティングリソースのうちの前記コンピューティングリソースから、最低の使用量コストを有する前記1つ以上のコンピューティングリソースを選択することを含み、
前記タスクの前記実行が、前記選択された1つ以上のコンピューティングリソースを使用して、前記スケジュール設定された時刻に開始される、請求項1に記載の方法。
【請求項5】
前記1つ以上のコンピューティングリソースが、前記タスク及び1つ以上の追加のタスクを実行するグローバルコストを最小限に抑えるように選択され、前記タスク及び前記1つ以上の追加のタスクの定義のそれぞれは、前記必要期限時刻を含み、前記1つ以上のコンピューティングリソースは、前記タスク及び前記1つ以上の追加のタスクのそれぞれの実行のためにそれぞれ選択される、請求項1に記載の前記方法。
【請求項6】
前記タスクの前記実行のための顧客価格を評価することをさらに含み、前記顧客価格が、前記必要期限時刻に基づく割引を含む、請求項1に記載の方法。
【請求項7】
前記タスクのための実行ウィンドウが、第1の時点で開始し、かつ第2の時点で終了し、前記第1の時点が、前記タスクの前記定義が受信される時点を含み、前記第2の時点が、前記必要期限時刻に基づき、前記割引が、前記実行ウィンドウの大きさに基づいて異なる、請求項6に記載の方法。
【請求項8】
少なくとも1つのプロセッサと、
前記少なくとも1つのプロセッサに連結されたメモリであって、前記メモリが、プログラム命令を記憶し、前記プログラム命令が、前記少なくとも1つのプロセッサによって実行可能であって、
リソースマネージャが、タスクの必要期限時刻を受信することであって、前記必要期限時刻が、前記タスクの実行の完了の期限を含み、前記タスクは割り込み可能性特性に関連する、受信することと、
前記リソースマネージャが、クラウドベースの複数のリソース構成の各々に対して前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のリソース構成は、複数のリソースプールに体系化され、前記複数のリソース構成の各々が、それぞれの使用量コストを有し、前記推定期間は、前記クラウドベースの複数のリソース構成を使用して前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定される、前記決定することと、
前記リソースマネージャが、実行ウィンドウ内で前記タスクの前記実行のコストを最小限に抑えるように、前記タスクの前記実行を完了する推定コスト及び前記割り込み可能性特性に基づいて、前記リソース構成のうちの1つ以上を選択することであって、前記実行ウィンドウのエンドポイントが、前記必要期限時刻に基づく、選択することと、
前記リソースマネージャが、前記選択された1つ以上のリソース構成を有する1つ以上の計算インスタンス上の前記タスクの前記実行のためのスケジュール設定された時刻を決定することであって、前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い、決定することと、を行うように実行可能である、メモリと、を備える、システム。
【請求項9】
前記1つ以上のリソース構成が、前記タスク及び1つ以上の追加のタスクの実行のグローバルコストを最小限に抑えるように選択され、前記タスク及び前記1つ以上の追加のタスクのそれぞれは、前記必要期限時刻を含み、前記1つ以上のリソース構成は、前記タスク及び前記1つ以上の追加のタスクのそれぞれの実行のためにそれぞれ選択される、請求項8に記載のシステム。
【請求項10】
前記リソース構成のうちの1つ以上を選択する際に、前記プログラム命令が、前記少なくとも1つのプロセッサによって、
前記必要期限時刻前に、前記タスクの前記実行の完了を可能にする、それぞれの推定期間を有する前記複数のリソース構成のうちの前記リソース構成から、最低の使用量コストを有する前記1つ以上のリソース構成を選択するようにさらに実行可能である、請求項8に記載のシステム。
【請求項11】
前記プログラム命令が、前記少なくとも1つのプロセッサによって、
前記タスクの前記実行のための顧客価格を決定するようにさらに実行可能であり、前記顧客価格が、前記必要期限時刻に基づく割引を含む、請求項8に記載のシステム。
【請求項12】
前記タスクのための実行ウィンドウが、第1の時点で開始し、かつ第2の時点で終了し、前記第1の時点が、前記タスクの前記定義が受信される時点を含み、前記第2の時点が、前記必要期限時刻に基づき、前記割引が、前記実行ウィンドウの大きさに基づいて異なる、請求項11に記載のシステム。」(以下,この特許請求の範囲に記載された請求項各項を「補正後の請求項」という。)
(なお,下線は,補正箇所を示すものとして,出願人が付与したものである。)

に補正するものである。

イ そして,本件補正は,本件補正前の請求項1記載の発明を特定するための事項(以下,「発明特定事項」という。)であるところの「前記リソースマネージャが、クラウドベースの複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のコンピューティングリソースは、複数のリソースプールに体系化され、各前記リソースプールが関連付けられた使用量コストを有する、前記決定すること」を「前記リソースマネージャが、クラウドベースの複数のリソース構成の各々に対して前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のリソース構成は、複数のリソースプールに体系化され、前記複数のリソース構成の各々が、それぞれの使用量コストを有し、前記推定期間は、前記クラウドベースの複数のリソース構成を使用して前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定される、前記決定すること」に限定し,本件補正前の請求項10記載の発明定事項であるところの「前記リソースマネージャが、クラウドベースの複数のリソース構成の各々に対して前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のリソース構成は、複数のリソースプールに体系化され、前記複数のリソース構成の各々が、それぞれの使用量コストを有する、決定すること」を「前記リソースマネージャが、クラウドベースの複数のリソース構成の各々に対して前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のリソース構成は、複数のリソースプールに体系化され、前記複数のリソース構成の各々が、それぞれの使用量コストを有し、前記推定期間は、前記クラウドベースの複数のリソース構成を使用して前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定される、前記決定すること」に限定して本件補正後の請求項8記載の発明特定事項とするものであり,この限定によって,本件補正前後の請求項1,及び本件補正前の請求項10と本件補正後の請求項8に係る発明の産業上の利用分野及び解決しようとする課題が格別変更されるものではない。

したがって,本件補正の目的は,請求項に記載した発明特定事項を限定するものであって,その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるもの(以下,「限定的減縮」という。)に該当し,特許法第17条の2第4項第2号に掲げられる事項を目的とするものであると解することができる。

2 独立特許要件

以上のように,本件補正後の請求項1に記載された発明(以下,「本件補正発明」という。)は,補正前の請求項1に対して,限定的減縮を行ったものと認められる。そこで,本件補正発明が特許出願の際独立して特許を受けることができるものであるか(平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に適合するか)以下に検討する。

(1)補正後の発明

本件補正発明は,前記「1.補正の内容」において,補正後の請求項1として引用した,次の記載のとおりのものである。

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

(2)引用文献に記載されている技術的事項及び引用発明の認定

ア 本願の優先日前に頒布(又は電気通信回線を通じて公衆に利用可能となった文献である)され,原審の拒絶査定の理由である平成29年7月26日付けの拒絶理由通知において引用された文献である,米国特許出願公開第2012/0131591号明細書(2012年5月24日出願公開。以下,「引用文献」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

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で確認を要求するように構成することができる。一実施形態によれば,システムは,ユーザアカウント及び課金情報のデータベースを維持するように構成することができる。データベースは,保留中のジョブ,既存の見積もり,キャンセル,実行履歴,スピード,価格などに関する情報を含むことができる。)」

イ ここで,上記引用文献に記載されている事項を検討する。

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

(イ)上記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で指定することができる。)」との記載からすると,引用文献には,“価格決定システムは,ユーザインタフェースを介して,顧客画面を生成し,顧客に提供し,前記ユーザインタフェースは,顧客が,ジョブの完了のために,所望の制約(時間,コストなど)を供給することを可能にするように構成され,顧客は,ジョブを完了するためのデッドラインも同様に指定することができ”る態様が記載されている。

(ウ)上記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を反映するように構成することができる。)」との記載からすると,引用文献には,“ある環境では,クラウドリソース(計算,記憶装置など)が,シームレスに割り当てられ,提出されたデッドラインの見積もりは,顧客画面において顧客に提供され,見積もり確認画面は,開始時間,完了時間を反映するように構成され,顧客は,計算タスクを実行することを望む場合,デッドラインに同意することができ,ジョブは実行のためにコミットされ,ジョブマネージャは,サブタスクを分配し,サブタスクを開始するように構成され”る態様が記載されている。

(エ)上記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.(いくつかの実施形態では,クラウド計算市場は,異なるプロバイダによる実行のために,与えられた計算ジョブを翻訳する際のサイクル及び/または時間に関して,コストを考慮に入れることができる。)」との記載からすると,引用文献には,“クラウド計算プロバイダのセットは,価格,性能,及び他の機能によって階層化された,交換可能な商品としてクラウド計算サイクルを扱うことが可能であり,クラウド計算市場は,異なるプロバイダによる実行のために,コストを考慮に入れることができ”る態様が記載されている。

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

(カ)上記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を開始するように構成される。)」との記載からすると,引用文献には,“価格付けの要求は,プロバイダマネージャに,価格付けを決定させることができ,提出されたタスクの価格の見積もりは,顧客画面において顧客に提供され,顧客は,計算タスクを実行することを望む場合,顧客は,価格に同意することができ,ジョブは実行のためにコミットされ,ジョブマネージャは,サブタスクを分配し,サブタスクを開始するように構成され”る態様が記載されている。

(キ)上記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コントローラは,ジョブ見積もりに基づいてジョブを開始するために,ジョブバックエンドを呼び出す。)」との記載からすると,引用文献には,“ユーザが見積もりを承認すると,UIコントローラは,ジョブ見積もりに基づいてジョブを開始”する態様が記載されている。

(ク)上記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を開始するように構成される。)」との記載からすると,引用文献には,“ジョブを開始する前に,ユーザが見積もりを承認する見積もり確認画面は,開始時間,完了時間を反映するように構成することができ,顧客は,計算タスクを実行することを望む場合,デッドラインに同意することができ,ジョブは実行のためにコミットされ,サブタスクを開始するように構成され”る態様が記載されている。

ウ 以上,(ア)ないし(ク)で指摘した事項を踏まえると,引用文献には,次の発明(以下,「引用発明」という。)が記載されているものと認められる。

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

(3)参考文献に記載されている技術的事項

(3-1)参考文献1

本願の優先日前に頒布(又は電気通信回線を通じて公衆に利用可能となった文献である)され,原審の拒絶査定において引用された文献である,特開2012-93832号公報(平成24年5月17日出願公開。以下,「参考文献1」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

F 「【要約】
【課題】メモリ領域を効率良く使用すると共に、スタック領域のオーバーフロー等の不都合を防止すること。
【解決手段】複数のタスクを所定のスケジュールに従って起床するスケジューラと、前記複数のタスクにより使用され、所定の領域がスタック領域として設定された共有メモリと、タスク毎のスタック使用量及び最大処理時間を記憶した記憶手段と、を備え、スケジューラは、複数のタスクのうち一のタスクを起床しようとする際に、当該タスクの最大処理時間が経過するまでに起床される予定のタスクであって、当該タスクに割り込み可能なタスクを抽出し、抽出したタスクのスタック使用量と当該タスクのスタック使用量を加算したスタック使用量がスタック領域の容量を超える場合には、起床しようとするタスクの起床を中止する情報処理装置。」

(3-2)参考文献2

本願の優先日前に頒布(又は電気通信回線を通じて公衆に利用可能となった文献である)され,原審の拒絶査定において引用された文献である,特開2003-208320号公報(平成15年7月25日出願公開。以下,「参考文献2」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

G 「【請求項1】実行優先度を示すタスクレベルが設定され、切り換えられて実行されるタスクと、
該タスクの起床要求及び、前記タスクレベルに基づき、前記タスクの切り換えを行うリアルタイムオペレーティングシステムと、
前記タスクに割り込んで実行され、実行優先度を示す割込レベルが設定された割込処理とで少なくとも構成される制御プログラムを搭載した電子制御装置において、前記制御プログラムは、
所定のタスク内に、前記割込レベルをマスクレベルとして指定することにより、当該割込レベル以下の前記割込処理の割り込み及び、前記タスクの切り換えを禁止する割込禁止区間が設定されており、
前記割込禁止区間の終了時に前記タスクの切り換えがなされる可能性の有無をコーディングの際に予め判断することにより、当該可能性が無ければ、前記割込禁止区間の終了時に、前記タスクの切り換えを行うためのタスクスケジューリング処理を実行しないようにされていることを特徴とする電子制御装置。」

H 「【0012】そこで次に、割込禁止区間について説明する。タスクの実行途中に実行優先度の高い割込処理が割り込むことは、既に述べた。しかし、タスクと割込処理でリソースを共有している場合など、割り込みのタイミングによっては、リソースの干渉が生じることがある。」

(3-3)参考文献3

本願の優先日前に頒布(又は電気通信回線を通じて公衆に利用可能となった文献である)され,原審の拒絶査定において引用された文献である,特表2007-511819号公報(平成19年5月10日出願公表。以下,「参考文献3」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

J 「【要約】
多重処理のデータ処理システムのスケジューラによる使用のための、メインメモリ要求および排他的なリソース使用に基づいてタスク優先割り込み点を選択する方法および装置が提供される。該方法および装置はコスト効率がよく、システム一貫性を維持し、特に、追加的な優先割り込み方針を可能にする。該方法および装置においては:一致する諸同期プリミティブは優先割り込み点すなわちサブジョブ境界をまたがない;特定のリソースRkについて、このリソースを使用する(そして同期プリミティブを使ってそれを保護する)すべてのタスクのすべての区間/サブジョブは、すべて優先割り込み可能であるかすべて優先割り込み不可能であるかのいずれかであり、i.すべて優先割り込み可能である場合、同期プリミティブは実行されなければならず、ii.すべて優先割り込み不可能である場合、同期プリミティブを実行する必要はない;ある部分集合に属する諸タスクへの優先割り込みはこの部分集合の優先割り込み点に限定され、一方では他のすべてのタスクには任意の優先割り込みを許容する;ある部分集合に属する諸タスクへの優先割り込みはそれらのタスクの優先割り込み点に限定され、他の諸タスクへの優先割り込みはそれらのタスクの優先割り込み点の部分集合に限定され一方ではそれらの残りの区間への任意の優先割り込みを許容する。すなわち、本発明は、所定の優先割り込み点のみでの優先割り込みに制限されず、リソースの排他的使用に起因するハングアップを回避する、メインメモリに基づく優先割り込み技術である。」

(3-4)参考文献4

本願の優先日前に頒布(又は電気通信回線を通じて公衆に利用可能となった文献である)された文献である,特開2010-152738号公報(平成22年7月8日出願公開。以下,「参考文献4」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

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

(3-5)参考文献5

本願の優先日前に頒布(又は電気通信回線を通じて公衆に利用可能となった文献である)された文献である,特表2007-524951号公報(平成19年8月30日出願公表。以下,「参考文献5」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

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

(4)本件補正発明と引用発明との対比

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

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

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

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

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

(オ)上記(ア)ないし(エ)の検討結果を踏まえると,引用発明の「クラウド計算方法」は,本件補正発明の「コンピュータ実装方法」に相当するといえる。

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

(一致点)

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

(相違点1)

本件補正発明は,「タスクは割り込み可能性特性に関連する」ものであるのに対して,引用発明は,そのようなものではない点。

(相違点2)

本件補正発明は,「前記リソースマネージャが、前記複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了する推定コスト及び前記割り込み可能性特性に基づいて、前記コンピューティングリソースのうちの1つ以上を選択する」ものであるのに対して,引用発明は,「コストを考慮に入れる」ものではあるが,割り込み可能性特性に基づくものではない点。

(相違点3)

本件補正発明は,「推定期間は、前記クラウドベースの複数のコンピューティングリソースを使用して前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定される」ものであるのに対して,引用発明の「完了時間」がどのように決定されるものか明記されていない点。

(相違点4)

本件補正発明は,「前記スケジュール設定された時刻が、少なくとも前記推定期間だけ前記必要期限時刻よりも早い」ものであるのに対して,引用発明は,見積もり確認画面にて提供される「開始時間」と「完了時間」が,「デッドライン」とどのような関係にあるか明記されていない点。

(5)当審の判断

ア 上記相違点1ないし相違点4について検討する。

(ア)相違点1及び相違点2について

参考文献1の上記Fに「スケジューラは、複数のタスクのうち一のタスクを起床しようとする際に…(中略)…当該タスクに割り込み可能なタスクを抽出」と記載され,参考文献2の上記Gに「タスクの切り換えがなされる可能性の有無をコーディングの際に予め判断することにより、当該可能性が無ければ、前記割込禁止区間の終了時に、前記タスクの切り換えを行うためのタスクスケジューリング処理を実行しない」と記載され,参考文献3の上記Jに「多重処理のデータ処理システムのスケジューラによる使用のための、メインメモリ要求および排他的なリソース使用に基づいてタスク優先割り込み点を選択する方法」と記載されるように,タスクの割り込み可能性特性に関連してタスクのスケジュール管理を行うことは,当該技術分野において慣用的に行われている周知技術であった。また,参考文献3の上記Jの記載内容に加え,参考文献2の上記Hに「タスクと割込処理でリソースを共有している場合など、割り込みのタイミングによっては、リソースの干渉が生じることがある」と記載されるように,リソースの状況を考慮に入れて,タスクの割り込みを管理する技術についても,当該技術分野において周知技術であった。そして,引用発明と,参考文献1ないし参考文献3に記載された技術思想は,タスクのスケジューリングに関する技術である点で共通する。

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

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

(イ)相違点3について

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

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

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

(ウ)相違点4について

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

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

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

イ 小括

上記で検討したごとく,相違点1ないし相違点4は,いずれも格別のものではなく,そして,これらの相違点を総合的に勘案しても,本件補正発明の奏する作用効果は,上記引用発明及び周知技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。

したがって,本件補正発明は,上記引用発明及び周知技術に基づいて,当業者が容易に発明をすることができたものであり,特許法第29条第2項の規定により,特許出願の際独立して特許を受けることができない。

3 むすび

以上のように,上記「2 独立特許要件」で指摘したとおり,補正後の請求項1に記載された発明は,特許出願の際独立して特許を受けることができるものではないから,本件補正は,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するので,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって,補正却下の決定の結論のとおり決定する。


第3 本件審判請求の成否について

1 本願発明の認定

平成30年6月27日付けの手続補正は上記のとおり却下されたので,本願の請求項1に係る発明(以下,「本願発明」という。)は,平成29年11月7日付け手続補正書の特許請求の範囲の請求項1に記載された事項により特定される,以下のとおりのものである。

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

2 引用文献に記載されている技術的事項及び引用発明の認定

原査定の拒絶の理由に引用された,引用文献およびその記載事項は,前記「第2 平成30年6月27日付けの手続補正についての補正却下の決定」の「2 独立特許要件」の「(2)引用文献に記載されている技術的事項及び引用発明の認定」に記載したとおりである。

3 対比・判断

本願発明は,前記「第2 平成30年6月27日付けの手続補正についての補正却下の決定」の「2 独立特許要件」で検討した本件補正発明における「前記リソースマネージャが、クラウドベースの複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のコンピューティングリソースは、複数のリソースプールに体系化され、各前記リソースプールが関連付けられた使用量コストを有し、前記推定期間は、前記クラウドベースの複数のコンピューティングリソースを使用して前記タスクの一部を実行し、前記一部を実行した期間から合計の推定実行期間を外挿すること、によって決定される、前記決定すること」の下線部の限定を省き,「前記リソースマネージャが、クラウドベースの複数のコンピューティングリソースの各々に対して、前記タスクの前記実行を完了するための推定期間を決定することであって、前記複数のコンピューティングリソースは、複数のリソースプールに体系化され、各前記リソースプールが関連付けられた使用量コストを有する、前記決定すること」としたものである。

そうすると,本願発明の発明特定事項を全て含む本件補正発明が,上記「第2 平成30年6月27日付けの手続補正についての補正却下の決定」の「2 独立特許要件」の「(3)参考文献に記載されている技術的事項」ないし「(5)当審の判断」に記載したとおり,引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから,本願発明も同様の理由により,引用発明及び周知技術に基づいて,当業者が容易に発明をすることができたものである。

4 むすび

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

よって,結論のとおり審決する。
 
別掲
 
審理終結日 2019-08-08 
結審通知日 2019-08-20 
審決日 2019-09-10 
出願番号 特願2015-557200(P2015-557200)
審決分類 P 1 8・ 121- Z (G06F)
P 1 8・ 575- Z (G06F)
最終処分 不成立  
前審関与審査官 小林 哲雄  
特許庁審判長 仲間 晃
特許庁審判官 山崎 慎一
田中 秀人
発明の名称 コスト最小化タスクスケジューラ  
代理人 山川 茂樹  
代理人 小池 勇三  
代理人 山川 政樹  

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