【事件の表示】
　特願２０１３−５４０３６３「サーバ側の処理能力を拡張するための方法及び装置」拒絶査定不服審判事件〔平成２４年　６月　７日国際公開、ＷＯ２０１２／０７２４８６、平成２６年　１月１６日国内公表、特表２０１４−５０１０１０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
第１　手続の経緯
　
　本件審判請求に係る出願（以下，「本願」という。）は，２０１１年１１月２４日（パリ条約による優先権主張外国庁受理２０１０年１１月２９日（以下，「優先日」という。），中国）を国際出願日とする出願であって，その手続の経緯は以下のとおりである。
　
　　平成２５年　１月　８日　　　：国内書面の提出
　　平成２６年　６月１０日　　　：出願審査請求書の提出
　　平成２７年　７月２４日付け　：拒絶理由の通知
　　平成２７年１０月２７日　　　：意見書，手続補正書の提出
　　平成２８年　３月２４日付け　：拒絶査定　
　　平成２８年　７月１９日　　　：審判請求書の提出
　
　
第２　本願発明
　
　本願の請求項に係る発明は，上記平成２７年１０月２７日付け手続補正により補正された特許請求の範囲の請求項１乃至１８に記載されたとおりのものであると認められるところ，その請求項１に係る発明（以下，「本願発明」という。）は，以下のとおりのものである。
　
「　　【請求項１】
　サーバ側の処理能力を拡張するための方法であって，
（ａ）前記サーバ側の処理能力を拡張するための装置が，前記サーバ側のコンピュータ装置で実行すべきであった一のジョブであって，前記サーバ側からオフロードすべき一のジョブを決定するステップと，
（ｂ）前記装置が，前記ジョブを１つ以上のタスクに分割するステップと，
（ｃ）前記装置が，１つ以上のクライアントから送信されたＨＴＴＰ要求に応答して，前記１つ以上のタスクを前記１つ以上のクライアントに割り振るステップと，
（ｄ）前記装置が，前記１つ以上のクライアントから送信された前記ＨＴＴＰ要求から，前記１つ以上のタスクに対する前記１つ以上のクライアントの応答を受信するステップを有し，
　前記ステップ（ｃ）が，前記１つ以上のクライアントが前記サーバ側にログオンすることに応答して，前記１つ以上のタスクに対応するタスク記述及び処理すべきデータを前記１つ以上のクライアントに送信するステップを含む，方法。」
　
　
第３　引用例
　
１　引用例１に記載されている技術的事項および引用発明
　
（１）本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の拒絶査定の理由である平成２７年７月２４日付けの拒絶理由通知において引用された，特開２０００−２４２６１４号公報（２０００年９月８日出願公開，以下，「引用例１」という。）には，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ａ　「【０００５】そのため，１台の計算機で処理をさせるには負荷が大き過ぎると考えられる大規模な計算処理を複数の小さなジョブに分割し，これらをネットワーク上の複数の計算機が備えるＣＰＵ群を用いて分散して行うようにすれば，ネットワーク上の余った計算機資源を有効に活用することが可能となる。そこで従来，インターネット上に分散して存在する複数の計算機を協調して動作させることにより，大規模な並列計算を行わせようとするシステムが提案されてきている。
…（中略）…
【０００７】
本発明は，このような実情に鑑みて成されたものであり，１台の計算機で処理するには負荷が大き過ぎる大規模な処理を，ネットワーク上で密結合された各計算機のＣＰＵ群を有効に利用して少ない負荷で実行できるようにすることを目的とする。
　
Ｂ　「【００１６】
【発明の実施の形態】（第１の実施形態）図１は，第１の実施形態による分散処理システムの構成を示すブロック図である。
図１に示すように，本実施形態の分散処理システムでは，ＬＡＮやＷＡＮあるいはインターネット等のネットワーク上に，複数の計算機が分散して存在している。すなわち，ジョブの管理を行うジョブ管理端末装置であるサーバ１と，ユーザが通常使用する端末２ａ，２ｂ，２ｃ，２ｄ，２ｅ，…とがネットワークを介して相互に接続されており，互いにデータの送受信を行うことができるようになっている。
【００１７】
本実施形態において，上記サーバ１は，分割可能な大規模ジョブ３を適宜分割し，ネットワーク上に存在する複数の端末２ａ〜２ｅに対して分割済の小さなジョブ＃１〜＃ｎを割り当てて解いてもらう。そして，それぞれの端末２ａ〜２ｅから小ジョブ＃１〜＃ｎの処理結果である回答を集めて，最初の大規模ジョブ３の解答とする。
　
Ｃ　「【００３４】図３において，まず最初に，サーバ１は所定の管理情報をセットする（ステップＳ１）。ここでは，例えば図２に示したような回答管理テーブルを初期状態にセットする。次に，本実施形態のフレームワークにひも付いたＷｅｂのホームページがサーバ１上で立ち上がっているかどうかを判断し（ステップＳ２），立ち上がっていない場合は立ち上げる（ステップＳ３）。
そして，サーバ１内のジョブ分割部１１が，大規模ジョブ３に記述された分割方法に従って，当該大規模ジョブ３を複数の小ジョブ＃１〜＃ｎに分割する（ステップＳ４）。
【００３５】
以上のようにして，大規模ジョブ３が複数の小ジョブ＃１〜＃ｎに分割されてＯＯＤＢ４に格納されることによって事前準備が完了すると，稼働しているフレームワークのプログラムによってジョブ配信が実行される（ステップＳ５）。すなわち，図４に示すように，まず，各端末２ａ〜２ｅの要求／回答送信部２１からサーバ１のアクセス受信部１２に対して，ホームページへのアクセスがあったかどうかを判断する（ステップＳ１１）。
【００３６】
一方，ホームページへのアクセスがあった場合は，ＯＯＤＢ４内に未処理の小ジョブがあるかどうかを判断する（ステップＳ１２）。
また，未処理の小ジョブがまだ残っている場合は，ホームページへのアクセスを行った端末に対してその未処理の小ジョブを送信する（ステップＳ１４）。
【００３７】
このステップＳ１４では，まず，ホームページのアクセスを行った端末に対してサーバ１からエージェント（Applet）をダウンロードする。そして，そのエージェントが当該端末に常駐して，定められたプログラムに従ってサーバ１に対してジョブ取得要求を与えることにより，未処理の小ジョブをサーバ１から取得する。小ジョブの配信を受けた端末では，その取得した小ジョブの処理を実行し，その処理結果である回答をサーバ１に返すことになる。サーバ１内の回答管理部１５は，受け取った回答をＯＯＤＢ４内に格納するとともに，図２に示した回答管理テーブルを更新する。
　
Ｄ　「【００４２】
なお，上記実施形態では，ジョブの管理を行うサーバ１が，ユーザが通常使用する端末２ａ〜２ｅとは別に設けられているが，このサーバ１が持つ機能を，ネットワーク上に分散して存在する各端末２ａ〜２ｅのうちの１つが備えるようにしても良い。また，上記実施形態では，ホームページへのアクセスをトリガとして小ジョブ＃１〜＃ｎの配信を実行しているが，このトリガは，必ずしもホームページへのアクセスである必要はなく，端末２ａ〜２ｅからサーバ１に対して要求が伝えられるものであれば何でも良い。
【００４３】また，上記実施形態では詳しく説明していないが，大規模ジョブ３を複数の小ジョブ＃１〜＃ｎに分割して分散処理し，それぞれの端末２ａ〜２ｅから得た回答をどのように処理するかについては，アプリケーションの内容に応じて適宜決めれば良い。各端末２ａ〜２ｅから得られた個々の回答をそのまま利用しても良いし，それらを１つの回答にまとめ上げるようにしても良い。どのようにまとめ上げるかについては，大規模ジョブ３のプログラム中に分割方法を記述したのと同様，大規模ジョブ３のプログラム中に記述される。」
　
（２）ここで，引用例１に記載されている事項を検討する。　
　
ア　上記Ａの段落【０００７】の「本発明は，このような実情に鑑みて成されたものであり，１台の計算機で処理するには負荷が大き過ぎる大規模な処理を，ネットワーク上で密結合された各計算機のＣＰＵ群を有効に利用して少ない負荷で実行できるようにすることを目的とする。」との記載，上記Ｂの段落【００１６】の「図１に示すように，本実施形態の分散処理システムでは，ＬＡＮやＷＡＮあるいはインターネット等のネットワーク上に，複数の計算機が分散して存在している。すなわち，ジョブの管理を行うジョブ管理端末装置であるサーバ１と，ユーザが通常使用する端末２ａ，２ｂ，２ｃ，２ｄ，２ｅ，…とがネットワークを介して相互に接続されており，互いにデータの送受信を行うことができるようになっている。」との記載からすると，「サーバ」と複数の「端末」とが「ネットワーク」を介して相互に接続されることにより「分散処理システム」が構成され，当該「分散処理システム」において，１台の計算機で処理するには負荷が大き過ぎる大規模な処理を分散して実行する方法が読み取れるから，引用例１には，
“サーバと複数の端末とがネットワークを介して相互に接続される分散処理システムにおいて，１台の計算機で処理するには負荷が大き過ぎる大規模な処理を分散して実行する方法”
が記載されていると解される。
イ　上記Ｂの段落【００１７】の「本実施形態において，上記サーバ１は，分割可能な大規模ジョブ３を適宜分割し，ネットワーク上に存在する複数の端末２ａ〜２ｅに対して分割済の小さなジョブ＃１〜＃ｎを割り当てて解いてもらう。」との記載，上記Ｃの段落【００３４】の「そして，サーバ１内のジョブ分割部１１が，大規模ジョブ３に記述された分割方法に従って，当該大規模ジョブ３を複数の小ジョブ＃１〜＃ｎに分割する（ステップＳ４）。」との記載からすると，端末で処理可能な大きさとするため，「大規模ジョブ」を複数の「小ジョブ」に分割することが読み取れるから，引用例１には，
“サーバは，大規模ジョブを複数の小ジョブに分割すること”
が記載されていると解される。
ウ　上記Ｃの段落【００３５】の「以上のようにして，大規模ジョブ３が複数の小ジョブ＃１〜＃ｎに分割されてＯＯＤＢ４に格納されることによって事前準備が完了すると，稼働しているフレームワークのプログラムによってジョブ配信が実行される（ステップＳ５）。すなわち，図４に示すように，まず，各端末２ａ〜２ｅの要求／回答送信部２１からサーバ１のアクセス受信部１２に対して，ホームページへのアクセスがあったかどうかを判断する（ステップＳ１１）。」，段落【００３６】の「一方，ホームページへのアクセスがあった場合は，ＯＯＤＢ４内に未処理の小ジョブがあるかどうかを判断する（ステップＳ１２）。」との記載からすると，サーバは，各端末からホームページへのアクセスがあったかどうかを判断し，ホームページへのアクセスがあった場合は，未処理の小ジョブがあるかどうかを判断することが読み取れる。
　また，上記Ｃの段落【００３６】の「また，未処理の小ジョブがまだ残っている場合は，ホームページへのアクセスを行った端末に対してその未処理の小ジョブを送信する（ステップＳ１４）。」，段落【００３７】の「このステップＳ１４では，まず，ホームページのアクセスを行った端末に対してサーバ１からエージェント（Applet）をダウンロードする。そして，そのエージェントが当該端末に常駐して，定められたプログラムに従ってサーバ１に対してジョブ取得要求を与えることにより，未処理の小ジョブをサーバ１から取得する。」との記載からすると，サーバは，未処理の小ジョブがまだ残っている場合は，ホームページへのアクセス要求を行った端末に，エージェントと未処理の小ジョブとを送信することが読み取れるから，引用例１には，
“サーバは，各端末からホームページへのアクセスがあったかどうかを判断し，前記ホームページへのアクセスがあった場合は，未処理の小ジョブがあるかどうかを判断し，未処理の小ジョブがまだ残っている場合は，前記ホームページへのアクセス要求を行った端末に，エージェントと未処理の小ジョブとを送信すること”
が記載されていると解される。
エ　上記Ｂの段落【００１７】の「そして，それぞれの端末２ａ〜２ｅから小ジョブ＃１〜＃ｎの処理結果である回答を集めて，最初の大規模ジョブ３の解答とする。」との記載，上記Ｃの段落【００３７】の「小ジョブの配信を受けた端末では，その取得した小ジョブの処理を実行し，その処理結果である回答をサーバ１に返すことになる。サーバ１内の回答管理部１５は，受け取った回答をＯＯＤＢ４内に格納するとともに，図２に示した回答管理テーブルを更新する。」との記載からすると，サーバは，複数の端末からの回答，すなわち，小ジョブの処理結果を受信して，それら回答を集めることは明らかであり，それら回答を集めたものが大規模ジョブの処理結果となることが読み取れるから，引用例１には，
“サーバは，複数の端末から小ジョブの処理結果である回答を受信して，それらの回答を集めて大規模ジョブの処理結果とすること”
が記載されていると解される。
　
（３）以上，ア乃至エの検討によれば，引用例１には次の発明（以下，「引用発明」という。）が記載されているものと認める。
　
「サーバと複数の端末とがネットワークを介して相互に接続される分散処理システムにおいて，１台の計算機で処理するには負荷が大き過ぎる大規模な処理を分散して実行する方法であって，
　前記サーバは，大規模ジョブを複数の小ジョブに分割すること，
　前記サーバは，各端末からホームページへのアクセスがあったかどうかを判断し，前記ホームページへのアクセスがあった場合は，未処理の小ジョブがあるかどうかを判断し，未処理の小ジョブがまだ残っている場合は，前記ホームページへのアクセス要求を行った端末に，エージェントと未処理の小ジョブとを送信すること，
　前記サーバは，複数の端末から小ジョブの処理結果である回答を受信して，それらの回答を集めて大規模ジョブの処理結果とすること，
を有する方法。」
　
　
２　引用例２に記載されている技術的事項
　
　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の拒絶査定の理由である平成２７年７月２４日付けの拒絶理由通知において引用された，特表２００３−５１５８０７号公報（２００３年５月７日出願公表，以下，「引用例２」という。）には，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｅ　「　　【００２４】
　
図３は，本発明のプロセスを実行するための模範的ステップを示す図である。このプロセスは，クライアント200がサーバ202からジョブ及びデータを引き出すことにより実行される。
…（中略）…
　　　【００２６】
　
ステップST4において，クライアントノードが，ジョブが利用可能であるとの応答をサーバから受信した場合，次のステップST5において，クライアントノードはサーバからジョブ記述を引き出す。上記のように，サーバからジョブ記述を引き出すステップは，HTTPにおけるGETリクエストをサーバに送信するステップを含んでいてもよい。
　　　【００２７】
　
ステップST8において，クライアントノードはオペレーティングシステムアイドルスレッドを生成してジョブプログラムを実行する。
…（中略）…
　　　【００２９】
　ジョブ実行スレッドを生成した後，オペレーティングシステムがスケジュールするまでこのスレッドは実行されない。これは図３のST9に示すとおりである。ステップST10において，オペレーティングシステムがジョブ実行スレッドをスケジュールすると，ジョブプログラムが実行される。ステップST11において，ジョブプログラムはサーバから入力データを引き出す。ジョブ記述により特定される問題によりこのようなアクションを行うことができ，アイドルスレッドがオペレーティングシステムによりスケジュールされたジョブプログラムを有する場合に，入力データは解決される。問題の解決は，ジョブが完了する（スケジュールST13）か，又は他の高優先度スレッドがスケジュールされるまで続けられる。高優先度スレッドがスケジュールされると，オペレーティングシステムはアイドルスレッドのコンテキストをセーブし，高優先度スレッドを実行した後，アイドルスレッドの実行に復帰する。
ステップST14において，ジョブを完了すると，ジョブプログラムは結果をサーバに送出する。HTTP又はFTPにおけるPUTリクエストによりこれを行うことができる。
３　引用例３に記載されている技術的事項
　
　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，原審の拒絶査定の理由である平成２７年７月２４日付けの拒絶理由通知において引用された，特開２００６−２４４１４６号公報（２００６年９月１４日出願公開，以下，「引用例３」という。）には，以下の技術的事項が記載されている。
　（当審注：下線は，参考のために当審で付与したものである。）
　
Ｆ　「【００１４】
　
本コンテンツ管理システムは，コンテンツ管理サーバ（１０５）とクライアント（１０１），から構成され，コンテンツ管理サーバ（１０５）は，コンテンツデータを保存する機能（１０９）を有し，それらデータをサーバ内で一意に管理するコンテンツ管理機能（１０６），コンテンツ登録時にコンテンツを編集する機能（１１１）を有する。
クライアント（１０１）は，サーバとの通信制御機能（１０４）及び，ＷｅｂシステムのＵＩとしてＷｅｂブラウザ（１０２），サーバのコンテンツ編集処理を分担するためのコンテンツ編集機能（１０３）を有する。
…（中略）…
【００１７】
　
サーバは，各コンテンツファイル毎の登録ジョブとそのジョブリスト生成する（２０９）。サーバはジョブ処理スレッドを生成する（２１０）。ジョブ処理スレッド（２２５）では，サーバの負荷が低いときにはジョブリスト中のまだ実行されていない登録ジョブを実行し（２２６），登録コンテンツを編集処理していく（２２７）。
【００１８】
　クライアントは，上記レスポンスに従いヘルパアプリを起動しジョブ処理スレッドを生成する（２１３）。クライアントメインスレッドは，上記スレッドを生成後に自動リダイレクト指示されているページへアクセスを繰り返す（２１６）。サーバ側（２１５）で処理が終了していない場合には，再度リダイレクトページのレスポンスが戻され（２１７），全ての処理が終了した場合には，自動リダイレクトページではなく登録終了ページのレスポンスがサーバから戻される（２１８）。
クライアントのジョブ処理スレッド（２１４）は，サーバへ分担ジョブ取得のリクエストを発行する（２１９）。
【００１９】
　
サーバは，ジョブリスト中のまだ実行されていないジョブが有る場合には，そのジョブの分担依頼データを作成し（２２０）クライアントのジョブ処理スレッドへ分担依頼レスポンスを返す（２２１）。クライアントのジョブ処理スレッドは，サーバのジョブ分担依頼データに従いコンテンツ編集処理を行なう（２２２）。編集が終了したら編集結果をサーバへアップロードする（２２９）。
再度，ジョブリスト中のまだ実行されていないジョブをチェックする。ジョブが有る場合には，再度クライアントのジョブ処理スレッドへ分担依頼のレスポンスを返し，無い場合には分担依頼なしのデータを生成し（２３３），レスポンスを返す（２３７）。
　
　
第４　対比
　
１　本願発明と引用発明とを対比する。
　
（１）引用発明では，「大規模ジョブ」をその負荷に応じた複数の「端末」で分散して処理することから，ジョブの負荷に応じて分散処理システムの処理能力を拡張するとみることができる。
　また，引用発明の「分散処理システム」と本願発明の「サーバ」とは，上位概念では，“システム”である点で一致するといえる。
　そうすると，引用発明の「サーバと複数の端末とがネットワークを介して相互に接続される分散処理システムにおいて，１台の計算機で処理するには負荷が大き過ぎる大規模な処理を分散して実行する方法」と，
　本願発明の「サーバ側の処理能力を拡張するための方法」とは，後記する点で相違するものの，
　“システムの処理能力を拡張するための方法”
である点で共通するといえる。
（２）引用発明では，「前記サーバは，大規模ジョブを複数の小ジョブに分割する」ところ，複数の「小ジョブ」に分割された「大規模ジョブ」は複数の「端末」で実行されることは明らかであり，「小ジョブ」は「大規模ジョブ」を分割したものであることから，引用発明の「大規模ジョブ」，「小ジョブ」はそれぞれ，本願発明の「ジョブ」，「タスク」に相当する。
　一方，本願発明では，「サーバ側の処理能力を拡張するための装置が，前記サーバ側のコンピュータ装置で実行すべきであった一のジョブであって，前記サーバ側からオフロードすべき一のジョブを決定する」ものの，複数の「タスク」に分割された「ジョブ」は複数の「クライアント」で実行されることは明らかであるから，引用発明の「端末」は本願発明の「クライアント」に相当し，引用発明の「大規模ジョブ」と本願発明の「ジョブ」とは，“クライアントで実行される”点で一致するといえる。
　そうすると，引用発明の「前記サーバは，大規模ジョブを複数の小ジョブに分割すること」と，
　本願発明の「（ａ）前記サーバ側の処理能力を拡張するための装置が，前記サーバ側のコンピュータ装置で実行すべきであった一のジョブであって，前記サーバ側からオフロードすべき一のジョブを決定するステップと，
（ｂ）前記装置が，前記ジョブを１つ以上のタスクに分割するステップと，」は，後記する点で相違するものの，
　“クライアントで実行されるジョブを１つ以上のタスクに分割するステップ”
である点で共通するといえる。
（３）引用発明では，「前記サーバは，各端末からホームページへのアクセスがあったかどうかを判断し，前記ホームページへのアクセスがあった場合は，未処理の小ジョブがあるかどうかを判断し，未処理の小ジョブがまだ残っている場合は，前記ホームページへのアクセス要求を行った端末に，エージェントと未処理の小ジョブとを送信する」ところ，「端末」から「ホームページ」への「アクセス要求」は，「小ジョブ」の割り付けの要求に他ならず，“タスク実行要求”とみることができるから，「サーバ」は，１つ以上の「端末」から送信された“タスク実行要求”に応答して，１つ以上の「小ジョブ」を１つ以上の「端末」に割り振るといえる。
　一方，本願発明では，「前記１つ以上のクライアントが前記サーバ側にログオンすることに応答して，前記１つ以上のタスクに対応するタスク記述及び処理すべきデータを前記１つ以上のクライアントに送信する」ものの，「１つ以上のクライアントから送信されたＨＴＴＰ要求に応答して，前記１つ以上のタスクを前記１つ以上のクライアントに割り振」っており，「１つ以上のクライアントから送信されたＨＴＴＰ要求」は，「タスク」割り振りの要求に他ならず，“タスク実行要求”とみることができるから，１つ以上の「クライアント」から送信された“タスク実行要求”に応答して，１つ以上の「タスク」を１つ以上の「クライアント」に割り振るといえる。
　そうすると，引用発明の「前記サーバは，各端末からホームページへのアクセスがあったかどうかを判断し，前記ホームページへのアクセスがあった場合は，未処理の小ジョブがあるかどうかを判断し，未処理の小ジョブがまだ残っている場合は，前記ホームページへのアクセス要求を行った端末に，エージェントと未処理の小ジョブとを送信すること」と，
　本願発明の「（ｃ）前記装置が，１つ以上のクライアントから送信されたＨＴＴＰ要求に応答して，前記１つ以上のタスクを前記１つ以上のクライアントに割り振るステップと，」
「前記ステップ（ｃ）が，前記１つ以上のクライアントが前記サーバ側にログオンすることに応答して，前記１つ以上のタスクに対応するタスク記述及び処理すべきデータを前記１つ以上のクライアントに送信するステップを含む」とは，後記する点で相違するものの，
　“１つ以上のクライアントから送信されたタスク実行要求に応答して，前記１つ以上のタスクを前記１つ以上のクライアントに割り振るステップ”
である点で共通するといえる。
（４）引用発明では，「前記サーバは，複数の端末から小ジョブの処理結果である回答を受信して，それらの回答を集めて大規模ジョブの処理結果とする」ところ，１つ以上の「端末」から，１つ以上の「小ジョブ」に対する前記１つ以上の「端末」の応答を受信するといえる。
　そうすると，引用発明の「前記サーバは，複数の端末から小ジョブの処理結果である回答を受信して，それらの回答を集めて大規模ジョブの処理結果とすること」と，
　本願発明の「（ｄ）前記装置が，前記１つ以上のクライアントから送信された前記ＨＴＴＰ要求から，前記１つ以上のタスクに対する前記１つ以上のクライアントの応答を受信するステップ」とは，後記する点で相違するものの，
　“前記１つ以上のクライアントから，前記１つ以上のタスクに対する前記１つ以上のクライアントの応答を受信するステップ”
である点で共通するといえる。
　
２　以上から，本願発明と引用発明とは，以下の点で一致し，また，以下の点で相違する。
　
＜一致点＞　
　
「システムの処理能力を拡張するための方法であって，
　クライアントで実行されるジョブを１つ以上のタスクに分割するステップと，
　１つ以上のクライアントから送信されたタスク実行要求に応答して，前記１つ以上のタスクを前記１つ以上のクライアントに割り振るステップと，
　前記１つ以上のクライアントから，前記１つ以上のタスクに対する前記１つ以上のクライアントの応答を受信するステップと，
を有する方法。」
＜相違点１＞
　本願発明は，「サーバ側の処理能力を拡張するための方法」であるのに対して，引用発明は，「サーバと複数の端末とがネットワークを介して相互に接続される分散処理システムにおいて，１台の計算機で処理するには負荷が大き過ぎる大規模な処理を分散して実行する方法」である点。
＜相違点２＞
　「ジョブ」と「タスク」の決定に関し，本願発明では，「前記サーバ側の処理能力を拡張するための装置が，前記サーバ側のコンピュータ装置で実行すべきであった一のジョブであって，前記サーバ側からオフロードすべき一のジョブを決定する」とともに，「前記ジョブを１つ以上のタスクに分割する」のに対して，引用発明では，「前記サーバは，大規模ジョブを複数の小ジョブに分割する」ものの，「大規模ジョブ」の決定について言及されていない点。
＜相違点３＞
　「クライアント」への「タスク」の割り振りの契機に関し，本願発明では，「サーバ側の処理能力を拡張するための装置」が「クライアントから送信されたＨＴＴＰ要求に応答して」行い，かつ「１つ以上のクライアントが前記サーバ側にログオンすることに応答」するのに対して，引用発明では，「サーバ」が「ホームページへのアクセス要求を行った端末に，エージェントと未処理の小ジョブとを送信する」ものの，「端末」から送信される「ＨＴＴＰ要求」，「端末」からの「ログオン」に応答することについて言及されていない点。
＜相違点４＞
　「クライアント」への「タスク」の割り振りに関し，本願発明では，「サーバ側の処理能力を拡張するための装置」が「前記１つ以上のタスクに対応するタスク記述及び処理すべきデータを前記１つ以上のクライアントに送信する」のに対して，引用発明では，「サーバ」が「端末に，エージェントと未処理の小ジョブとを送信する」ものの，「タスクに対応するタスク記述及び処理すべきデータ」を「端末」に送信するかどうか特定されていない点。
＜相違点５＞
　「タスク」に対する「クライアント」からの応答受信の契機に関し，本願発明では，「サーバ側の処理能力を拡張するための装置が，前記１つ以上のクライアントから送信された」「ＨＴＴＰ要求」から受信するのに対して，引用発明では，「サーバ」が「複数の端末から小ジョブの処理結果である回答を受信して，それらの回答を集めて大規模ジョブの処理結果とする」ものの，「端末」から送信される「ＨＴＴＰ要求」から受信することについて言及されていない点。
　
　
第５　当審の判断
　
　上記相違点１乃至５について検討する。
　
１　相違点１，２について
　引用発明では，「サーバと複数の端末とがネットワークを介して相互に接続される分散処理システムにおいて，１台の計算機で処理するには負荷が大き過ぎる大規模な処理を分散して実行する」ために，「サーバ」が「大規模ジョブ」を分割し，分割された「小ジョブ」を複数の「端末」に送信するところ，引用例１の上記Ｄの段落【００４２】の「なお，上記実施形態では，ジョブの管理を行うサーバ１が，ユーザが通常使用する端末２ａ〜２ｅとは別に設けられているが，このサーバ１が持つ機能を，ネットワーク上に分散して存在する各端末２ａ〜２ｅのうちの１つが備えるようにしても良い。」との記載から，「分散処理システム」において「小ジョブ」を実行する「計算機」のうちの１つが，「大規模ジョブ」を分割し，分割された「小ジョブ」を複数の「端末」に送信する機能を備えることが示唆されている。
　また，サーバのジョブ処理をクライアントへ分担するシステムにおいて，クライアントからサーバへ分担ジョブ取得のリクエストがあった際に，サーバの負荷が大きい場合には，サーバは実行されていないジョブをチェックし，実行されていないジョブをクライアントへ分担依頼する旨の技術は，例えば，引用例３（上記Ｆを参照）に記載されるように，本願の優先日前には当該技術分野における周知技術であった。
　すなわち，サーバのジョブ処理をクライアントへ分担するシステムにおいて，サーバで実行すべきであったジョブであって，クライアントへ分担依頼するためにサーバからオフロードすべきジョブを決定することは周知技術であり，引用発明とは，分散処理システムにおいて，サーバがクライアントにジョブ処理を依頼する点で課題が共通するといえる。
　そうすると，引用発明において上記周知技術を適用し，適宜，サーバ側に処理能力を拡張するための機能に加えて，ジョブを実行する機能を具備し，サーバ側の処理能力を拡張するための方法であって，前記サーバ側の処理能力を拡張するための装置が，前記サーバ側のコンピュータ装置で実行すべきであったジョブであって，前記サーバ側からオフロードすべきジョブを決定し，前記ジョブを１つ以上のタスクに分割すること，すなわち，上記相違点１，２に係る構成とすることは，当業者が容易に想到し得たことである。
２　相違点３，５について
　引用発明では，「サーバ」が「ホームページへのアクセス要求を行った端末に，エージェントと未処理の小ジョブとを送信」し，「複数の端末から小ジョブの処理結果である回答を受信して，それらの回答を集めて大規模ジョブの処理結果とする」ところ，引用例１の上記Ｄの段落【００４２】の「また，上記実施形態では，ホームページへのアクセスをトリガとして小ジョブ＃１〜＃ｎの配信を実行しているが，このトリガは，必ずしもホームページへのアクセスである必要はなく，端末２ａ〜２ｅからサーバ１に対して要求が伝えられるものであれば何でも良い。」との記載から，分割された「小ジョブ」を複数の「端末」に送信する契機は他の態様でも良いことが示唆されている。
　また，サーバがクライアントの処理能力を利用するシステムにおいて，クライアントからサーバへのジョブの要求，及び，クライアントからサーバへのジョブの結果の送出に，ＨＴＴＰリクエストを利用する旨の技術は，例えば，引用例２（上記Ｅを参照）に記載されるように，本願の優先日前には当該技術分野における周知技術であった。さらに，クライアントからサーバへのログオンを伴うアクセスも，本願の優先日前には当該技術分野の周知慣用技術であり，クライアントからサーバへのアクセス時にログオンをするか否かは，必要に応じて適宜選択し得た設計的事項である。
　そして，引用発明と上記周知技術は，クライアントの要求によって，サーバがクライアントへジョブを割り当てるシステムである点で技術的課題が共通するといえ，周知技術の引用発明への適用に阻害要因は認められない。
　したがって，引用発明に上記周知技術を適用し，端末のエージェントによるサーバへのジョブの要求に代えて，端末からサーバ側へのアクセス要求にＨＴＴＰ要求を利用してログオンすると，サーバ側の処理能力を拡張するための装置が，サーバの応答として端末にタスクを割り振るとともに，端末からサーバ側への処理結果の送信にＨＴＴＰ要求を利用すること，すなわち，上記相違点３，５に係る構成とすることは，当業者が容易に想到し得たことである。
３　相違点４について
　引用発明では，「サーバ」が「端末に，エージェントと未処理の小ジョブとを送信する」ところ，サーバがクライアントの処理能力を利用するシステムにおいて，クライアントからサーバへのジョブの要求に応じて，サーバからクライアントへジョブ記述を送出する旨の技術は，例えば，引用例２（上記Ｅを参照）に記載されるように，本願の優先日前には当該技術分野における周知技術であった。
　そうすると，引用発明において上記周知技術を適用し，適宜，サーバ側の処理能力を拡張するための装置が，タスクに対応するタスク記述及び処理すべきデータを端末に送信すること，すなわち，上記相違点４に係る構成とすることは，当業者が容易に想到し得たことである。
　
４　小括
　
　上記で検討したごとく，相違点１乃至５に係る構成は当業者が容易に想到し得たものであり，そして，これらの相違点を総合的に勘案しても，本願発明の奏する作用効果は，引用発明，及び，引用例２，３に記載の当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず，格別顕著なものということはできない。
　
　
第６　むすび 
　
　以上のとおり，本願の請求項１に係る発明は，特許法第２９条第２項の規定により特許を受けることができないものであるから，その余の請求項に係る発明について検討するまでもなく，本願は拒絶すべきものである。 
　
　よって，結論のとおり審決する。