• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1334194
審判番号 不服2016-10841  
総通号数 216 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-12-28 
種別 拒絶査定不服の審決 
審判請求日 2016-07-19 
確定日 2017-11-08 
事件の表示 特願2013-540363「サーバ側の処理能力を拡張するための方法及び装置」拒絶査定不服審判事件〔平成24年 6月 7日国際公開、WO2012/072486、平成26年 1月16日国内公表、特表2014-501010〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由
第1 手続の経緯

本件審判請求に係る出願(以下,「本願」という。)は,2011年11月24日(パリ条約による優先権主張外国庁受理2010年11月29日(以下,「優先日」という。),中国)を国際出願日とする出願であって,その手続の経緯は以下のとおりである。

平成25年 1月 8日 :国内書面の提出
平成26年 6月10日 :出願審査請求書の提出
平成27年 7月24日付け :拒絶理由の通知
平成27年10月27日 :意見書,手続補正書の提出
平成28年 3月24日付け :拒絶査定
平成28年 7月19日 :審判請求書の提出


第2 本願発明

本願の請求項に係る発明は,上記平成27年10月27日付け手続補正により補正された特許請求の範囲の請求項1乃至18に記載されたとおりのものであると認められるところ,その請求項1に係る発明(以下,「本願発明」という。)は,以下のとおりのものである。

「 【請求項1】
サーバ側の処理能力を拡張するための方法であって,
(a)前記サーバ側の処理能力を拡張するための装置が,前記サーバ側のコンピュータ装置で実行すべきであった一のジョブであって,前記サーバ側からオフロードすべき一のジョブを決定するステップと,
(b)前記装置が,前記ジョブを1つ以上のタスクに分割するステップと,
(c)前記装置が,1つ以上のクライアントから送信されたHTTP要求に応答して,前記1つ以上のタスクを前記1つ以上のクライアントに割り振るステップと,
(d)前記装置が,前記1つ以上のクライアントから送信された前記HTTP要求から,前記1つ以上のタスクに対する前記1つ以上のクライアントの応答を受信するステップを有し,
前記ステップ(c)が,前記1つ以上のクライアントが前記サーバ側にログオンすることに応答して,前記1つ以上のタスクに対応するタスク記述及び処理すべきデータを前記1つ以上のクライアントに送信するステップを含む,方法。」


第3 引用例

1 引用例1に記載されている技術的事項および引用発明

(1)本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,原審の拒絶査定の理由である平成27年7月24日付けの拒絶理由通知において引用された,特開2000-242614号公報(2000年9月8日出願公開,以下,「引用例1」という。)には,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

A 「【0005】そのため,1台の計算機で処理をさせるには負荷が大き過ぎると考えられる大規模な計算処理を複数の小さなジョブに分割し,これらをネットワーク上の複数の計算機が備えるCPU群を用いて分散して行うようにすれば,ネットワーク上の余った計算機資源を有効に活用することが可能となる。そこで従来,インターネット上に分散して存在する複数の計算機を協調して動作させることにより,大規模な並列計算を行わせようとするシステムが提案されてきている。
…(中略)…
【0007】本発明は,このような実情に鑑みて成されたものであり,1台の計算機で処理するには負荷が大き過ぎる大規模な処理を,ネットワーク上で密結合された各計算機のCPU群を有効に利用して少ない負荷で実行できるようにすることを目的とする。また,本発明は,ネットワーク上に接続された計算機自体に余計な負担をかけないようにすることをも目的とする。」

B 「【0016】
【発明の実施の形態】(第1の実施形態)図1は,第1の実施形態による分散処理システムの構成を示すブロック図である。図1に示すように,本実施形態の分散処理システムでは,LANやWANあるいはインターネット等のネットワーク上に,複数の計算機が分散して存在している。すなわち,ジョブの管理を行うジョブ管理端末装置であるサーバ1と,ユーザが通常使用する端末2a,2b,2c,2d,2e,…とがネットワークを介して相互に接続されており,互いにデータの送受信を行うことができるようになっている。なお,図1では端末を5つのみ示しているが,実際にはこれより多くの端末が存在している。
【0017】本実施形態において,上記サーバ1は,分割可能な大規模ジョブ3を適宜分割し,ネットワーク上に存在する複数の端末2a?2eに対して分割済の小さなジョブ#1?#nを割り当てて解いてもらう。そして,それぞれの端末2a?2eから小ジョブ#1?#nの処理結果である回答を集めて,最初の大規模ジョブ3の解答とする。このような動作の実現方法として,第1の実施形態では,Applet方式を採用する。以下に,上記サーバ1および各端末2a?2eの構成を詳しく説明する。」

C 「【0034】図3において,まず最初に,サーバ1は所定の管理情報をセットする(ステップS1)。ここでは,例えば図2に示したような回答管理テーブルを初期状態にセットする。次に,本実施形態のフレームワークにひも付いたWebのホームページがサーバ1上で立ち上がっているかどうかを判断し(ステップS2),立ち上がっていない場合は立ち上げる(ステップS3)。そして,サーバ1内のジョブ分割部11が,大規模ジョブ3に記述された分割方法に従って,当該大規模ジョブ3を複数の小ジョブ#1?#nに分割する(ステップS4)。
【0035】以上のようにして,大規模ジョブ3が複数の小ジョブ#1?#nに分割されてOODB4に格納されることによって事前準備が完了すると,稼働しているフレームワークのプログラムによってジョブ配信が実行される(ステップS5)。すなわち,図4に示すように,まず,各端末2a?2eの要求/回答送信部21からサーバ1のアクセス受信部12に対して,ホームページへのアクセスがあったかどうかを判断する(ステップS11)。このアクセスがない場合は,所定のディレイ時間を待った後(ステップS13),ステップS11に戻る。
【0036】一方,ホームページへのアクセスがあった場合は,OODB4内に未処理の小ジョブがあるかどうかを判断する(ステップS12)。ここで,小ジョブ#1?#nの配信が全て終わるなどして未処理の小ジョブが残っていない場合は,所定のディレイ時間を待った後(ステップS13),ステップS11に戻る。また,未処理の小ジョブがまだ残っている場合は,ホームページへのアクセスを行った端末に対してその未処理の小ジョブを送信する(ステップS14)。
【0037】このステップS14では,まず,ホームページのアクセスを行った端末に対してサーバ1からエージェント(Applet)をダウンロードする。そして,そのエージェントが当該端末に常駐して,定められたプログラムに従ってサーバ1に対してジョブ取得要求を与えることにより,未処理の小ジョブをサーバ1から取得する。小ジョブの配信を受けた端末では,その取得した小ジョブの処理を実行し,その処理結果である回答をサーバ1に返すことになる。サーバ1内の回答管理部15は,受け取った回答をOODB4内に格納するとともに,図2に示した回答管理テーブルを更新する。」

D 「【0042】なお,上記実施形態では,ジョブの管理を行うサーバ1が,ユーザが通常使用する端末2a?2eとは別に設けられているが,このサーバ1が持つ機能を,ネットワーク上に分散して存在する各端末2a?2eのうちの1つが備えるようにしても良い。また,上記実施形態では,ホームページへのアクセスをトリガとして小ジョブ#1?#nの配信を実行しているが,このトリガは,必ずしもホームページへのアクセスである必要はなく,端末2a?2eからサーバ1に対して要求が伝えられるものであれば何でも良い。
【0043】また,上記実施形態では詳しく説明していないが,大規模ジョブ3を複数の小ジョブ#1?#nに分割して分散処理し,それぞれの端末2a?2eから得た回答をどのように処理するかについては,アプリケーションの内容に応じて適宜決めれば良い。各端末2a?2eから得られた個々の回答をそのまま利用しても良いし,それらを1つの回答にまとめ上げるようにしても良い。どのようにまとめ上げるかについては,大規模ジョブ3のプログラム中に分割方法を記述したのと同様,大規模ジョブ3のプログラム中に記述される。」

(2)ここで,引用例1に記載されている事項を検討する。

ア 上記Aの段落【0007】の「本発明は,このような実情に鑑みて成されたものであり,1台の計算機で処理するには負荷が大き過ぎる大規模な処理を,ネットワーク上で密結合された各計算機のCPU群を有効に利用して少ない負荷で実行できるようにすることを目的とする。」との記載,上記Bの段落【0016】の「図1に示すように,本実施形態の分散処理システムでは,LANやWANあるいはインターネット等のネットワーク上に,複数の計算機が分散して存在している。すなわち,ジョブの管理を行うジョブ管理端末装置であるサーバ1と,ユーザが通常使用する端末2a,2b,2c,2d,2e,…とがネットワークを介して相互に接続されており,互いにデータの送受信を行うことができるようになっている。」との記載からすると,「サーバ」と複数の「端末」とが「ネットワーク」を介して相互に接続されることにより「分散処理システム」が構成され,当該「分散処理システム」において,1台の計算機で処理するには負荷が大き過ぎる大規模な処理を分散して実行する方法が読み取れるから,引用例1には,
“サーバと複数の端末とがネットワークを介して相互に接続される分散処理システムにおいて,1台の計算機で処理するには負荷が大き過ぎる大規模な処理を分散して実行する方法”
が記載されていると解される。

イ 上記Bの段落【0017】の「本実施形態において,上記サーバ1は,分割可能な大規模ジョブ3を適宜分割し,ネットワーク上に存在する複数の端末2a?2eに対して分割済の小さなジョブ#1?#nを割り当てて解いてもらう。」との記載,上記Cの段落【0034】の「そして,サーバ1内のジョブ分割部11が,大規模ジョブ3に記述された分割方法に従って,当該大規模ジョブ3を複数の小ジョブ#1?#nに分割する(ステップS4)。」との記載からすると,端末で処理可能な大きさとするため,「大規模ジョブ」を複数の「小ジョブ」に分割することが読み取れるから,引用例1には,
“サーバは,大規模ジョブを複数の小ジョブに分割すること”
が記載されていると解される。

ウ 上記Cの段落【0035】の「以上のようにして,大規模ジョブ3が複数の小ジョブ#1?#nに分割されてOODB4に格納されることによって事前準備が完了すると,稼働しているフレームワークのプログラムによってジョブ配信が実行される(ステップS5)。すなわち,図4に示すように,まず,各端末2a?2eの要求/回答送信部21からサーバ1のアクセス受信部12に対して,ホームページへのアクセスがあったかどうかを判断する(ステップS11)。」,段落【0036】の「一方,ホームページへのアクセスがあった場合は,OODB4内に未処理の小ジョブがあるかどうかを判断する(ステップS12)。」との記載からすると,サーバは,各端末からホームページへのアクセスがあったかどうかを判断し,ホームページへのアクセスがあった場合は,未処理の小ジョブがあるかどうかを判断することが読み取れる。
また,上記Cの段落【0036】の「また,未処理の小ジョブがまだ残っている場合は,ホームページへのアクセスを行った端末に対してその未処理の小ジョブを送信する(ステップS14)。」,段落【0037】の「このステップS14では,まず,ホームページのアクセスを行った端末に対してサーバ1からエージェント(Applet)をダウンロードする。そして,そのエージェントが当該端末に常駐して,定められたプログラムに従ってサーバ1に対してジョブ取得要求を与えることにより,未処理の小ジョブをサーバ1から取得する。」との記載からすると,サーバは,未処理の小ジョブがまだ残っている場合は,ホームページへのアクセス要求を行った端末に,エージェントと未処理の小ジョブとを送信することが読み取れるから,引用例1には,
“サーバは,各端末からホームページへのアクセスがあったかどうかを判断し,前記ホームページへのアクセスがあった場合は,未処理の小ジョブがあるかどうかを判断し,未処理の小ジョブがまだ残っている場合は,前記ホームページへのアクセス要求を行った端末に,エージェントと未処理の小ジョブとを送信すること”
が記載されていると解される。

エ 上記Bの段落【0017】の「そして,それぞれの端末2a?2eから小ジョブ#1?#nの処理結果である回答を集めて,最初の大規模ジョブ3の解答とする。」との記載,上記Cの段落【0037】の「小ジョブの配信を受けた端末では,その取得した小ジョブの処理を実行し,その処理結果である回答をサーバ1に返すことになる。サーバ1内の回答管理部15は,受け取った回答をOODB4内に格納するとともに,図2に示した回答管理テーブルを更新する。」との記載からすると,サーバは,複数の端末からの回答,すなわち,小ジョブの処理結果を受信して,それら回答を集めることは明らかであり,それら回答を集めたものが大規模ジョブの処理結果となることが読み取れるから,引用例1には,
“サーバは,複数の端末から小ジョブの処理結果である回答を受信して,それらの回答を集めて大規模ジョブの処理結果とすること”
が記載されていると解される。

(3)以上,ア乃至エの検討によれば,引用例1には次の発明(以下,「引用発明」という。)が記載されているものと認める。

「サーバと複数の端末とがネットワークを介して相互に接続される分散処理システムにおいて,1台の計算機で処理するには負荷が大き過ぎる大規模な処理を分散して実行する方法であって,
前記サーバは,大規模ジョブを複数の小ジョブに分割すること,
前記サーバは,各端末からホームページへのアクセスがあったかどうかを判断し,前記ホームページへのアクセスがあった場合は,未処理の小ジョブがあるかどうかを判断し,未処理の小ジョブがまだ残っている場合は,前記ホームページへのアクセス要求を行った端末に,エージェントと未処理の小ジョブとを送信すること,
前記サーバは,複数の端末から小ジョブの処理結果である回答を受信して,それらの回答を集めて大規模ジョブの処理結果とすること,
を有する方法。」


2 引用例2に記載されている技術的事項

本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,原審の拒絶査定の理由である平成27年7月24日付けの拒絶理由通知において引用された,特表2003-515807号公報(2003年5月7日出願公表,以下,「引用例2」という。)には,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

E 「 【0024】
図3は,本発明のプロセスを実行するための模範的ステップを示す図である。このプロセスは,クライアント200がサーバ202からジョブ及びデータを引き出すことにより実行される。図3を参照すると,ステップST1において,第1アイドルスレッドを生成するコードを含むプロセスを開始する。クライアントノードにオペレーティングシステムをロードするときに,このプロセスもクライアントノードにロードすることができる。オペレーティングシステムが開始するとプロセスが自動的に開始するようにしてもよい。サーバからデータを引き出すためのコードをアイドルスレッド上にスケジュールしているため,全てのユーザ優先スレッドが実行されるかスリープしないと,このスレッドは実行しない。オペレーティングシステムがスレッドをスケジュールする模範的なメカニズムを,以下にさらに詳細に説明する。
…(中略)…
【0026】
ステップST4において,クライアントノードが,ジョブが利用可能であるとの応答をサーバから受信した場合,次のステップST5において,クライアントノードはサーバからジョブ記述を引き出す。上記のように,サーバからジョブ記述を引き出すステップは,HTTPにおけるGETリクエストをサーバに送信するステップを含んでいてもよい。ステップST6において,クライアントノードは,ジョブ記述により特定されるジョブを実行するジョブプログラムがクライアントノードにあるかどうかを判断する。必要なプログラムが存在しない場合には,ステップST7において,クライアントノードはジョブプログラムをサーバから引き出す。
【0027】
ステップST8において,クライアントノードはオペレーティングシステムアイドルスレッドを生成してジョブプログラムを実行する。第1スレッド上で実行されるプログラムのmain()関数に含まれる下記の数行のコードによってこれを行ってもよい。
…(中略)…
【0029】
ジョブ実行スレッドを生成した後,オペレーティングシステムがスケジュールするまでこのスレッドは実行されない。これは図3のST9に示すとおりである。ステップST10において,オペレーティングシステムがジョブ実行スレッドをスケジュールすると,ジョブプログラムが実行される。ステップST11において,ジョブプログラムはサーバから入力データを引き出す。ジョブ記述により特定される問題によりこのようなアクションを行うことができ,アイドルスレッドがオペレーティングシステムによりスケジュールされたジョブプログラムを有する場合に,入力データは解決される。問題の解決は,ジョブが完了する(スケジュールST13)か,又は他の高優先度スレッドがスケジュールされるまで続けられる。高優先度スレッドがスケジュールされると,オペレーティングシステムはアイドルスレッドのコンテキストをセーブし,高優先度スレッドを実行した後,アイドルスレッドの実行に復帰する。ステップST14において,ジョブを完了すると,ジョブプログラムは結果をサーバに送出する。HTTP又はFTPにおけるPUTリクエストによりこれを行うことができる。」

3 引用例3に記載されている技術的事項

本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,原審の拒絶査定の理由である平成27年7月24日付けの拒絶理由通知において引用された,特開2006-244146号公報(2006年9月14日出願公開,以下,「引用例3」という。)には,以下の技術的事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

F 「【0014】
本コンテンツ管理システムは,コンテンツ管理サーバ(105)とクライアント(101),から構成され,コンテンツ管理サーバ(105)は,コンテンツデータを保存する機能(109)を有し,それらデータをサーバ内で一意に管理するコンテンツ管理機能(106),コンテンツ登録時にコンテンツを編集する機能(111)を有する。また,クライアントからのリクエストを解析する機能(107),リクエストに応じたレスポンスを生成する機能(110),クライアントとの通信制御機能(108),を有する。クライアント(101)は,サーバとの通信制御機能(104)及び,WebシステムのUIとしてWebブラウザ(102),サーバのコンテンツ編集処理を分担するためのコンテンツ編集機能(103)を有する。
…(中略)…
【0017】
サーバは,各コンテンツファイル毎の登録ジョブとそのジョブリスト生成する(209)。サーバはジョブ処理スレッドを生成する(210)。ジョブ処理スレッド(225)では,サーバの負荷が低いときにはジョブリスト中のまだ実行されていない登録ジョブを実行し(226),登録コンテンツを編集処理していく(227)。ジョブ処理スレッドはジョブリスト中のジョブが全て終了したら自動的に終了する(228)。サーバのメインスレッドは,セッションを維持するために処理結果を表示するページへリダイレクトし,且つページ表示時ジョブ処理スレッドを実行するヘルパアプリが起動される様に記載されたページを生成し(211)クライアントへ返す(212)。
【0018】
クライアントは,上記レスポンスに従いヘルパアプリを起動しジョブ処理スレッドを生成する(213)。クライアントメインスレッドは,上記スレッドを生成後に自動リダイレクト指示されているページへアクセスを繰り返す(216)。サーバ側(215)で処理が終了していない場合には,再度リダイレクトページのレスポンスが戻され(217),全ての処理が終了した場合には,自動リダイレクトページではなく登録終了ページのレスポンスがサーバから戻される(218)。クライアントのジョブ処理スレッド(214)は,サーバへ分担ジョブ取得のリクエストを発行する(219)。
【0019】
サーバは,ジョブリスト中のまだ実行されていないジョブが有る場合には,そのジョブの分担依頼データを作成し(220)クライアントのジョブ処理スレッドへ分担依頼レスポンスを返す(221)。クライアントのジョブ処理スレッドは,サーバのジョブ分担依頼データに従いコンテンツ編集処理を行なう(222)。編集が終了したら編集結果をサーバへアップロードする(229)。この時セッション情報が有る場合(230)に,サーバはクライアントのジョブ処理スレッドからアップロードされたデータを保存し(232),再度,ジョブリスト中のまだ実行されていないジョブをチェックする。ジョブが有る場合には,再度クライアントのジョブ処理スレッドへ分担依頼のレスポンスを返し,無い場合には分担依頼なしのデータを生成し(233),レスポンスを返す(237)。」


第4 対比

1 本願発明と引用発明とを対比する。

(1)引用発明では,「大規模ジョブ」をその負荷に応じた複数の「端末」で分散して処理することから,ジョブの負荷に応じて分散処理システムの処理能力を拡張するとみることができる。
また,引用発明の「分散処理システム」と本願発明の「サーバ」とは,上位概念では,“システム”である点で一致するといえる。
そうすると,引用発明の「サーバと複数の端末とがネットワークを介して相互に接続される分散処理システムにおいて,1台の計算機で処理するには負荷が大き過ぎる大規模な処理を分散して実行する方法」と,
本願発明の「サーバ側の処理能力を拡張するための方法」とは,後記する点で相違するものの,
“システムの処理能力を拡張するための方法”
である点で共通するといえる。

(2)引用発明では,「前記サーバは,大規模ジョブを複数の小ジョブに分割する」ところ,複数の「小ジョブ」に分割された「大規模ジョブ」は複数の「端末」で実行されることは明らかであり,「小ジョブ」は「大規模ジョブ」を分割したものであることから,引用発明の「大規模ジョブ」,「小ジョブ」はそれぞれ,本願発明の「ジョブ」,「タスク」に相当する。
一方,本願発明では,「サーバ側の処理能力を拡張するための装置が,前記サーバ側のコンピュータ装置で実行すべきであった一のジョブであって,前記サーバ側からオフロードすべき一のジョブを決定する」ものの,複数の「タスク」に分割された「ジョブ」は複数の「クライアント」で実行されることは明らかであるから,引用発明の「端末」は本願発明の「クライアント」に相当し,引用発明の「大規模ジョブ」と本願発明の「ジョブ」とは,“クライアントで実行される”点で一致するといえる。
そうすると,引用発明の「前記サーバは,大規模ジョブを複数の小ジョブに分割すること」と,
本願発明の「(a)前記サーバ側の処理能力を拡張するための装置が,前記サーバ側のコンピュータ装置で実行すべきであった一のジョブであって,前記サーバ側からオフロードすべき一のジョブを決定するステップと,
(b)前記装置が,前記ジョブを1つ以上のタスクに分割するステップと,」は,後記する点で相違するものの,
“クライアントで実行されるジョブを1つ以上のタスクに分割するステップ”
である点で共通するといえる。

(3)引用発明では,「前記サーバは,各端末からホームページへのアクセスがあったかどうかを判断し,前記ホームページへのアクセスがあった場合は,未処理の小ジョブがあるかどうかを判断し,未処理の小ジョブがまだ残っている場合は,前記ホームページへのアクセス要求を行った端末に,エージェントと未処理の小ジョブとを送信する」ところ,「端末」から「ホームページ」への「アクセス要求」は,「小ジョブ」の割り付けの要求に他ならず,“タスク実行要求”とみることができるから,「サーバ」は,1つ以上の「端末」から送信された“タスク実行要求”に応答して,1つ以上の「小ジョブ」を1つ以上の「端末」に割り振るといえる。
一方,本願発明では,「前記1つ以上のクライアントが前記サーバ側にログオンすることに応答して,前記1つ以上のタスクに対応するタスク記述及び処理すべきデータを前記1つ以上のクライアントに送信する」ものの,「1つ以上のクライアントから送信されたHTTP要求に応答して,前記1つ以上のタスクを前記1つ以上のクライアントに割り振」っており,「1つ以上のクライアントから送信されたHTTP要求」は,「タスク」割り振りの要求に他ならず,“タスク実行要求”とみることができるから,1つ以上の「クライアント」から送信された“タスク実行要求”に応答して,1つ以上の「タスク」を1つ以上の「クライアント」に割り振るといえる。
そうすると,引用発明の「前記サーバは,各端末からホームページへのアクセスがあったかどうかを判断し,前記ホームページへのアクセスがあった場合は,未処理の小ジョブがあるかどうかを判断し,未処理の小ジョブがまだ残っている場合は,前記ホームページへのアクセス要求を行った端末に,エージェントと未処理の小ジョブとを送信すること」と,
本願発明の「(c)前記装置が,1つ以上のクライアントから送信されたHTTP要求に応答して,前記1つ以上のタスクを前記1つ以上のクライアントに割り振るステップと,」
「前記ステップ(c)が,前記1つ以上のクライアントが前記サーバ側にログオンすることに応答して,前記1つ以上のタスクに対応するタスク記述及び処理すべきデータを前記1つ以上のクライアントに送信するステップを含む」とは,後記する点で相違するものの,
“1つ以上のクライアントから送信されたタスク実行要求に応答して,前記1つ以上のタスクを前記1つ以上のクライアントに割り振るステップ”
である点で共通するといえる。

(4)引用発明では,「前記サーバは,複数の端末から小ジョブの処理結果である回答を受信して,それらの回答を集めて大規模ジョブの処理結果とする」ところ,1つ以上の「端末」から,1つ以上の「小ジョブ」に対する前記1つ以上の「端末」の応答を受信するといえる。
そうすると,引用発明の「前記サーバは,複数の端末から小ジョブの処理結果である回答を受信して,それらの回答を集めて大規模ジョブの処理結果とすること」と,
本願発明の「(d)前記装置が,前記1つ以上のクライアントから送信された前記HTTP要求から,前記1つ以上のタスクに対する前記1つ以上のクライアントの応答を受信するステップ」とは,後記する点で相違するものの,
“前記1つ以上のクライアントから,前記1つ以上のタスクに対する前記1つ以上のクライアントの応答を受信するステップ”
である点で共通するといえる。

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

<一致点>

「システムの処理能力を拡張するための方法であって,
クライアントで実行されるジョブを1つ以上のタスクに分割するステップと,
1つ以上のクライアントから送信されたタスク実行要求に応答して,前記1つ以上のタスクを前記1つ以上のクライアントに割り振るステップと,
前記1つ以上のクライアントから,前記1つ以上のタスクに対する前記1つ以上のクライアントの応答を受信するステップと,
を有する方法。」

<相違点1>
本願発明は,「サーバ側の処理能力を拡張するための方法」であるのに対して,引用発明は,「サーバと複数の端末とがネットワークを介して相互に接続される分散処理システムにおいて,1台の計算機で処理するには負荷が大き過ぎる大規模な処理を分散して実行する方法」である点。

<相違点2>
「ジョブ」と「タスク」の決定に関し,本願発明では,「前記サーバ側の処理能力を拡張するための装置が,前記サーバ側のコンピュータ装置で実行すべきであった一のジョブであって,前記サーバ側からオフロードすべき一のジョブを決定する」とともに,「前記ジョブを1つ以上のタスクに分割する」のに対して,引用発明では,「前記サーバは,大規模ジョブを複数の小ジョブに分割する」ものの,「大規模ジョブ」の決定について言及されていない点。

<相違点3>
「クライアント」への「タスク」の割り振りの契機に関し,本願発明では,「サーバ側の処理能力を拡張するための装置」が「クライアントから送信されたHTTP要求に応答して」行い,かつ「1つ以上のクライアントが前記サーバ側にログオンすることに応答」するのに対して,引用発明では,「サーバ」が「ホームページへのアクセス要求を行った端末に,エージェントと未処理の小ジョブとを送信する」ものの,「端末」から送信される「HTTP要求」,「端末」からの「ログオン」に応答することについて言及されていない点。

<相違点4>
「クライアント」への「タスク」の割り振りに関し,本願発明では,「サーバ側の処理能力を拡張するための装置」が「前記1つ以上のタスクに対応するタスク記述及び処理すべきデータを前記1つ以上のクライアントに送信する」のに対して,引用発明では,「サーバ」が「端末に,エージェントと未処理の小ジョブとを送信する」ものの,「タスクに対応するタスク記述及び処理すべきデータ」を「端末」に送信するかどうか特定されていない点。

<相違点5>
「タスク」に対する「クライアント」からの応答受信の契機に関し,本願発明では,「サーバ側の処理能力を拡張するための装置が,前記1つ以上のクライアントから送信された」「HTTP要求」から受信するのに対して,引用発明では,「サーバ」が「複数の端末から小ジョブの処理結果である回答を受信して,それらの回答を集めて大規模ジョブの処理結果とする」ものの,「端末」から送信される「HTTP要求」から受信することについて言及されていない点。


第5 当審の判断

上記相違点1乃至5について検討する。

1 相違点1,2について

引用発明では,「サーバと複数の端末とがネットワークを介して相互に接続される分散処理システムにおいて,1台の計算機で処理するには負荷が大き過ぎる大規模な処理を分散して実行する」ために,「サーバ」が「大規模ジョブ」を分割し,分割された「小ジョブ」を複数の「端末」に送信するところ,引用例1の上記Dの段落【0042】の「なお,上記実施形態では,ジョブの管理を行うサーバ1が,ユーザが通常使用する端末2a?2eとは別に設けられているが,このサーバ1が持つ機能を,ネットワーク上に分散して存在する各端末2a?2eのうちの1つが備えるようにしても良い。」との記載から,「分散処理システム」において「小ジョブ」を実行する「計算機」のうちの1つが,「大規模ジョブ」を分割し,分割された「小ジョブ」を複数の「端末」に送信する機能を備えることが示唆されている。
また,サーバのジョブ処理をクライアントへ分担するシステムにおいて,クライアントからサーバへ分担ジョブ取得のリクエストがあった際に,サーバの負荷が大きい場合には,サーバは実行されていないジョブをチェックし,実行されていないジョブをクライアントへ分担依頼する旨の技術は,例えば,引用例3(上記Fを参照)に記載されるように,本願の優先日前には当該技術分野における周知技術であった。
すなわち,サーバのジョブ処理をクライアントへ分担するシステムにおいて,サーバで実行すべきであったジョブであって,クライアントへ分担依頼するためにサーバからオフロードすべきジョブを決定することは周知技術であり,引用発明とは,分散処理システムにおいて,サーバがクライアントにジョブ処理を依頼する点で課題が共通するといえる。
そうすると,引用発明において上記周知技術を適用し,適宜,サーバ側に処理能力を拡張するための機能に加えて,ジョブを実行する機能を具備し,サーバ側の処理能力を拡張するための方法であって,前記サーバ側の処理能力を拡張するための装置が,前記サーバ側のコンピュータ装置で実行すべきであったジョブであって,前記サーバ側からオフロードすべきジョブを決定し,前記ジョブを1つ以上のタスクに分割すること,すなわち,上記相違点1,2に係る構成とすることは,当業者が容易に想到し得たことである。

2 相違点3,5について

引用発明では,「サーバ」が「ホームページへのアクセス要求を行った端末に,エージェントと未処理の小ジョブとを送信」し,「複数の端末から小ジョブの処理結果である回答を受信して,それらの回答を集めて大規模ジョブの処理結果とする」ところ,引用例1の上記Dの段落【0042】の「また,上記実施形態では,ホームページへのアクセスをトリガとして小ジョブ#1?#nの配信を実行しているが,このトリガは,必ずしもホームページへのアクセスである必要はなく,端末2a?2eからサーバ1に対して要求が伝えられるものであれば何でも良い。」との記載から,分割された「小ジョブ」を複数の「端末」に送信する契機は他の態様でも良いことが示唆されている。
また,サーバがクライアントの処理能力を利用するシステムにおいて,クライアントからサーバへのジョブの要求,及び,クライアントからサーバへのジョブの結果の送出に,HTTPリクエストを利用する旨の技術は,例えば,引用例2(上記Eを参照)に記載されるように,本願の優先日前には当該技術分野における周知技術であった。さらに,クライアントからサーバへのログオンを伴うアクセスも,本願の優先日前には当該技術分野の周知慣用技術であり,クライアントからサーバへのアクセス時にログオンをするか否かは,必要に応じて適宜選択し得た設計的事項である。
そして,引用発明と上記周知技術は,クライアントの要求によって,サーバがクライアントへジョブを割り当てるシステムである点で技術的課題が共通するといえ,周知技術の引用発明への適用に阻害要因は認められない。
したがって,引用発明に上記周知技術を適用し,端末のエージェントによるサーバへのジョブの要求に代えて,端末からサーバ側へのアクセス要求にHTTP要求を利用してログオンすると,サーバ側の処理能力を拡張するための装置が,サーバの応答として端末にタスクを割り振るとともに,端末からサーバ側への処理結果の送信にHTTP要求を利用すること,すなわち,上記相違点3,5に係る構成とすることは,当業者が容易に想到し得たことである。

3 相違点4について

引用発明では,「サーバ」が「端末に,エージェントと未処理の小ジョブとを送信する」ところ,サーバがクライアントの処理能力を利用するシステムにおいて,クライアントからサーバへのジョブの要求に応じて,サーバからクライアントへジョブ記述を送出する旨の技術は,例えば,引用例2(上記Eを参照)に記載されるように,本願の優先日前には当該技術分野における周知技術であった。
そうすると,引用発明において上記周知技術を適用し,適宜,サーバ側の処理能力を拡張するための装置が,タスクに対応するタスク記述及び処理すべきデータを端末に送信すること,すなわち,上記相違点4に係る構成とすることは,当業者が容易に想到し得たことである。

4 小括

上記で検討したごとく,相違点1乃至5に係る構成は当業者が容易に想到し得たものであり,そして,これらの相違点を総合的に勘案しても,本願発明の奏する作用効果は,引用発明,及び,引用例2,3に記載の当該技術分野の周知技術の奏する作用効果から予測される範囲内のものにすぎず,格別顕著なものということはできない。


第6 むすび

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

よって,結論のとおり審決する。
 
審理終結日 2017-06-12 
結審通知日 2017-06-13 
審決日 2017-06-29 
出願番号 特願2013-540363(P2013-540363)
審決分類 P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 大桃 由紀雄金沢 史明  
特許庁審判長 高木 進
特許庁審判官 辻本 泰隆
須田 勝巳
発明の名称 サーバ側の処理能力を拡張するための方法及び装置  
代理人 上野 剛史  
代理人 太佐 種一  

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