• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 取り消して特許、登録 G06F
審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F
管理番号 1332201
審判番号 不服2016-16156  
総通号数 214 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-10-27 
種別 拒絶査定不服の審決 
審判請求日 2016-10-28 
確定日 2017-09-26 
事件の表示 特願2015- 84200「サーバ・クラウドにおけるキャパシティ・オン・デマンドを管理するための装置、コンピュータ実装方法、および製造品(サーバ・クラウドにおけるキャパシティ・オン・デマンドの管理)」拒絶査定不服審判事件〔平成27年 8月20日出願公開、特開2015-149097、請求項の数(9)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は,2013年3月21日(パリ条約による優先権主張外国庁受理2012年3月27日 米国)を国際出願日とする特願2014-557954号の一部を,特許法44条1項の規定により,平成27年4月16日に新たな特許出願としたものであって,
同年4月16日付けで審査請求がされ,
平成28年3月22日付けで審査官により拒絶理由が通知され,これに対して
同年4月18日付けで意見書が提出されると共に手続補正がなされ,
同年7月29日付けで審査官により拒絶査定(原査定)がなされ,これに対して
同年10月28日付けで審判請求がなされると共に手続補正がなされ,
同年12月28日付けで審査官により特許法164条3項の規定に基づく報告がなされ,
平成29年7月12日付けで拒絶理由通知(当審)がされ,
同年7月20日付けで意見書が提出されると共に手続補正がなされたものである。


第2 本願発明
本願請求項1-9に係る発明(以下,それぞれ「本願発明1」-「本願発明9」という。)は,平成29年7月20日付けの手続補正で補正された特許請求の範囲の請求項1-9に記載された事項により特定される,以下のとおりの発明である。

「【請求項1】
サーバ・クラウド中の複数のサーバのために複数のリソースのキャパシティを管理するための、少なくとも1つのプロセッサによって実行されるコンピュータ実装方法であって、
(A)前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも1つのサーバから、前記複数のリソースのうちの少なくとも1つのリソースのキャパシティを借りるステップと、
(B)前記サーバ・クラウドが完全な状態である限り、前記借りたキャパシティを前記サーバ・クラウド中の前記複数のサーバのうちの異なるサーバに貸すステップと、
(C)前記複数のサーバのうちの1つのサーバがもはや前記サーバ・クラウド中になく、前記複数のサーバのうちの1つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないとき、クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収するステップと
を含む方法。

【請求項2】
前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも1つのサーバ中のクラウド永続キャパシティを、前記サーバ・クラウド中の別のサーバと共有するステップをさらに含み、前記クラウド永続キャパシティが、前記サーバ・クラウド中の前記複数のサーバのうちの前記1つのサーバ上で永続的にイネーブルにされるキャパシティであって前記サーバ・クラウド中の他のサーバと共有できるキャパシティである、請求項1に記載の方法。

【請求項3】
前記複数のリソースがプロセッサを含む、請求項1に記載の方法。

【請求項4】
前記複数のリソースがメモリを含む、請求項1に記載の方法。

【請求項5】
ステップ(C)が、前記複数のサーバのうちの1つのサーバがもはや前記サーバ・クラウド中にないせいで前記サーバ・クラウドがもはや完全な状態でないときに、前記複数のサーバ全てからの全ての借りたキャパシティをディセーブルにするステップと、前記複数のサーバ全てからの全ての貸したキャパシティを回収するステップとを含む、請求項1に記載の方法。

【請求項6】
ステップ(C)が、前記複数のサーバのうちの1つのサーバがもはや前記サーバ・クラウド中にないせいで前記サーバ・クラウドがもはや完全な状態でないときに、前記1つのサーバから借りた、借りたキャパシティをディセーブルにするステップと、前記1つのサーバ上の貸したキャパシティを回収するステップと、まだ前記サーバ・クラウド中にある複数のサーバについての他の借りたキャパシティおよび貸したキャパシティを保持するステップとを含む、請求項1に記載の方法。

【請求項7】
サーバ・クラウド中の複数のサーバのために複数のリソースのキャパシティを管理するための、少なくとも1つのプロセッサによって実行されるコンピュータ実装方法であって、前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも1つのサーバから、前記複数のリソースのうちの少なくとも1つのリソースのクラウド永続キャパシティを借りるステップであって、前記複数のリソースがプロセッサおよびメモリを含み、前記クラウド永続キャパシティが、前記サーバ・クラウド中の前記複数のサーバのうちの前記1つのサーバ上で永続的にイネーブルにされるキャパシティであって前記サーバ・クラウド中の他のサーバと共有できるキャパシティである、前記借りるステップと、前記サーバ・クラウドが完全な状態である限り、前記借りたキャパシティを前記サーバ・クラウド中の前記複数のサーバのうちの異なるサーバに貸すステップと、前記複数のサーバのうちの1つのサーバがもはや前記サーバ・クラウド中になく、前記複数のサーバのうちの1つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないときに、前記1つのサーバから借りた、借りたキャパシティをディセーブルにするステップ、前記1つのサーバ上の貸したキャパシティを回収するステップ、ならびに、まだ前記サーバ・クラウド中にある複数のサーバについての他の借りたキャパシティおよび貸したキャパシティを保持するステップを実施するステップとを含む方法。

【請求項8】
請求項1から7のいずれか一項に記載された方法の各ステップを実行するための手段を備える、システム。

【請求項9】
請求項1から7のいずれか一項に記載された方法の各ステップをコンピュータに実行させる、プログラム。」


第3 引用文献,引用発明等
1.引用文献1について
原査定の拒絶の理由に引用された文献,

河井 保博,新紀年企画・日本型IT革命の将来 ブロードバンド時代のサイト構築 大容量のトラフィックをさばき切るシステムを求めて,日経インターネットテクノロジー,日本,日経BP社,2001年 8月22日,第50号,pp.46-49

には,図面とともに次の事項が記載されている。

「そこで重要になってくるのが「キャパシティ・オンデマンド」(CoD)の考え方。トラフィック,あるいはサーバーの処理量の増加にあわせて,CPU数などサーバー・リソースをオンデマンドで提供するアイデアである。もちろん,サーバー価格は使ったリソースの量に応じて変わる従量制。万一に備えていつも余分なサーバー・リソースを抱え,その費用を払い続けるといった問題を解決できる(図1)。」(46ページ右欄下から7行-47ページ左欄上から4行)

「こうした限界を考えると,サーバー・ベンダーがCPU数を増減させつつ,従量制で課金するというモデルはなかなかユーザーのニーズに馴染まない。そこで注目したいのが,ホスティング・サービス事業者,いわゆるマネージド・サービス・プロバイダ(MSP)によるサービスである。実際,MSPがキャパシティ・オンデマンドに取り組む動きは国内でも出始めている。例えばクールサイトは,すでにピーク対策を考慮したホスティング・サービスとして,キャパシティ・オンデマンドを実践している。
仕組みはこうだ。まず,4?5サイトを単位に,1つの大規模システムを共有させる。1サイトごとに必要なキャパシティを見積もり,その20倍のトラフィックに耐えられるだけのリソースを割り当てる。これで急激なトラフィック増加にある程度耐えられる(図3)。
しかし,ピークが20倍の容量の範囲に収まるかどうかはわからない。そこで同社は,あえて4?5サイトで1システムを共有させるスタイルを選んだ。「20倍の容量でさばききれないほどトラフィックが増加した場合,他社用に割り当てているサーバー・リソースのうち,空いているリソースを貸し出す」(クールサイト社長の北原穂高氏)のである。
ただ,クールサイトのサービスの場合,トラフィックの増加に伴って自動的にサーバー・リソースを増やしてくれるわけではない。クールサイトのエンジニアがトラフィックを監視し,状況に応じて手作業でロード・バランサーの設定を変えることで,キャパシティ・オンデマンドを実現している。」(48ページ左欄下から5行-49ページ左欄上から2行)

図3


したがって,上記引用文献1には次の発明(以下,「引用発明」という。)が記載されていると認められる。

「トラフィック,あるいはサーバーの処理量の増加にあわせて,CPU数などサーバー・リソースをオンデマンドで提供するアイデアである,キャパシティ・オンデマンドシステムであって,
サーバー価格は使ったリソースの量に応じて変わる従量制であり,万一に備えていつも余分なサーバー・リソースを抱え,その費用を払い続けるといった問題を解決するものであり,
4?5サイトを単位に,1つの大規模システムを共有させ,1サイトごとに必要なキャパシティを見積もり,その20倍のトラフィックに耐えられるだけのリソースを割り当て,
トラフィックを監視し,状況に応じて手作業でロード・バランサーの設定を変えることで,キャパシティ・オンデマンドを実現する
キャパシティ・オンデマンドシステム。」

2.引用文献2について
また,原査定の拒絶の理由に引用された引用文献2(特開2010-178381号公報)には,図面とともに次の事項が記載されている。

「【0024】
図3は、リソース・マネージャ124の一例のブロック図であり、リソース・マネージャ124の、レンダリング・デバイス120を含む他のシステムとの対話の一例を示している。リソース・マネージャ124には、リソース割当サブシステム204,ユーザ対話サブシステム206,リソース監視サブシステム208,および共有リソース・データベース212が含まれる。リソース・マネージャ124には、レンダリング・デバイス120およびマルチデバイス・プロクシ・サーバ112など他のシステムと通信するための、通信エージェント216も含まれる。他のシステムと通信するために、任意の型の適切なプロトコルが用いられてよい。例えば、セッション・インビテーション・プロトコル(SIP)、ハイパー・テキスト・トランスファー・プロトコル(HTTP)、シンプル・メール・トランスファー・プロトコル(SMTP)などのプロトコル、または同様のプロプライエタリな(proprietary )プロトコルが用いられる。」

「【0026】
リソース監視サブシステム208は、近傍のデバイスと通信して、どのリソースがユーザに利用可能かを判定する。例えば、会議室には、フル・サイズのディスプレイと音響システムとを有するコンピュータが存在する場合がある。リソース監視サブシステム208は、ディスプレイおよび音響システムなど、使用に利用可能なリソースをこのコンピュータが有することを確かめるため、このコンピュータと通信する。リソース・マネージャ124は、デバイスを構成要素のリソース(component resource)の集合体として扱う。したがって、多様なユーザが単一のデバイスを共有することが可能である。」

「【0052】
ブロック388にて、ブロック386で送信された選択リソースをユーザが予約取消したことを、リソース・マネージャ124が確認したか否かが判定される。確認が受信された場合、フローはブロック390へ進む。ブロック390では、方法350を実装するレンダリング・デバイス120がマルチデバイス・プロクシ・サーバ112へ通知を送信し、ブロック384で選択されたリソースをユーザに関連する利用可能なリソース・プールから取り除くべきことを示す。これに代えて、後に説明するように、そうした通知をリソース・マネージャ124が送信してもよい。」

「【0055】
ブロック404にて、特定の近傍の利用可能なリソースが判定される。これには、近傍に存在するリソースを判定することと、それに続いてそれらのうち利用可能なリソースを判定することとが含まれる。ユーザ対話サブシステム206は、共有リソース・データベース212に問い合わせることによって、近傍の利用可能なリソースを判定する。さらに、リソースが貸与可能なリソースの場合、ユーザ対話サブシステム206は、リソース割当サブシステム204によって強制される、アクセス制御ポリシー、課金ポリシーなどに基づいて、利用可能なリソースを判定する。」

したがって,上記引用文献2には,
「リソース・マネージャ124には,共有リソース・データベース212が含まれ,
選択リソースをユーザが予約取消したことを、リソース・マネージャ124が確認したら,選択されたリソースをユーザに関連する利用可能なリソース・プールから取り除き,
近傍に存在するリソースのうち利用可能なリソースを判定し,
共有リソース・データベース212に問い合わせることによって、近傍の利用可能なリソースを判定する」という技術的事項が記載されていると認められる。


第4 対比・判断
1.本願発明1について
(1)対比
本願発明1と引用発明とを対比すると,次のことがいえる。

引用発明における「大規模システム」は,本願発明1における「サーバ・クラウド」に,以下,「CPU数などサーバー・リソース」は,「リソース」に,それぞれ相当する。
引用発明の「キャパシティ・オンデマンドシステム」は,「トラフィック,あるいはサーバーの処理量の増加にあわせて,CPU数などサーバー・リソースをオンデマンドで提供するアイデアである」ことから,本願発明1と“(A)前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも1つのサーバから、前記複数のリソースのうちの少なくとも1つのリソースのキャパシティを借りるステップ”及び“(B)前記サーバ・クラウドが完全な状態である限り、前記借りたキャパシティを前記サーバ・クラウド中の前記複数のサーバのうちの異なるサーバに貸すステップ”を有する点で一致するといえる。
また,引用発明は「トラフィックを監視し,状況に応じて手作業でロード・バランサーの設定を変えることで,キャパシティ・オンデマンドを実現する」ものであるが,当該設定が変更された後,リソースの貸借の手続が,コンピュータによって行われることは当業者に自明であるから,本願発明1とは“サーバ・クラウド中の複数のサーバのために複数のリソースのキャパシティを管理するための、少なくとも1つのプロセッサによって実行されるコンピュータ実装方法”である点で一致するといえる。

したがって,本願発明1と引用発明との間には,次の一致点,相違点があるといえる。

(一致点)
「サーバ・クラウド中の複数のサーバのために複数のリソースのキャパシティを管理するための、少なくとも1つのプロセッサによって実行されるコンピュータ実装方法であって、
(A)前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも1つのサーバから、前記複数のリソースのうちの少なくとも1つのリソースのキャパシティを借りるステップと、
(B)前記サーバ・クラウドが完全な状態である限り、前記借りたキャパシティを前記サーバ・クラウド中の前記複数のサーバのうちの異なるサーバに貸すステップと、
を含む方法。」

(相違点)
本願発明1は「(C)前記複数のサーバのうちの1つのサーバがもはや前記サーバ・クラウド中になく、前記複数のサーバのうちの1つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないとき、クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収するステップ」という構成を備えるのに対し,引用発明はそのような構成を備えていない点。

(2)相違点についての判断
上記相違点について検討すると,引用文献2には,「リソース・マネージャ124には,共有リソース・データベース212が含まれ,
選択リソースをユーザが予約取消したことを、リソース・マネージャ124が確認したら,選択されたリソースをユーザに関連する利用可能なリソース・プールから取り除き,
近傍に存在するリソースのうち利用可能なリソースを判定し,
共有リソース・データベース212に問い合わせることによって、近傍の利用可能なリソースを判定する」という技術的事項が記載されているものの,ユーザの判断に基づいてリソース・マネージャが利用不可能とするものであり,相違点に係る本願発明1の「(C)前記複数のサーバのうちの1つのサーバがもはや前記サーバ・クラウド中になく、前記複数のサーバのうちの1つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないとき、クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収するステップ」という構成は上記引用文献2には記載されていない。
したがって,本願発明1は,当業者であっても引用発明,引用文献2に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

2.本願発明2-6について
本願発明2-6も,本願発明1の「(C)前記複数のサーバのうちの1つのサーバがもはや前記サーバ・クラウド中になく、前記複数のサーバのうちの1つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないとき、クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収するステップ」と同一の構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献2に記載された技術的事項に基づいて容易に発明できたものとはいえない。

3.本願発明7-9について
本願発明7は,本願発明1の「前記複数のリソースのうちの少なくとも1つのリソースのキャパシティを借りるステップ」における,「リソースのキャパシティ」つき,「前記複数のリソースがプロセッサおよびメモリを含み、前記クラウド永続キャパシティが、前記サーバ・クラウド中の前記複数のサーバのうちの前記1つのサーバ上で永続的にイネーブルにされるキャパシティであって前記サーバ・クラウド中の他のサーバと共有できるキャパシティである」との限定事項を付し,さらに,「まだ前記サーバ・クラウド中にある複数のサーバについての他の借りたキャパシティおよび貸したキャパシティを保持するステップを実施するステップ」をも有する方法の発明であるが,本願発明1と同様,「(C)前記複数のサーバのうちの1つのサーバがもはや前記サーバ・クラウド中になく、前記複数のサーバのうちの1つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないとき、クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収するステップ」に対応する構成を備えるものであるから,本願発明1と同様の理由により,当業者であっても,引用発明,引用文献2に記載された技術的事項に基づいて容易に発明できたものとはいえない。
また,本願発明8及び9は,本願発明1-7に対応するそれぞれ,システム及びプログラムの発明であって,カテゴリーのみ異なる発明であるから,本願発明1と同様の理由により,当業者であっても,引用発明,引用文献2に記載された技術的事項に基づいて容易に発明できたものとはいえない。


第5 原査定の概要及び原査定についての判断
原査定は,請求項1-9について上記引用文献1,2に基づいて,当業者が容易に発明できたものであるから,特許法29条2項の規定により特許を受けることができないというものである。しかしながら,平成29年7月20日付け手続補正により補正された請求項1,7は,それぞれ「(C)前記複数のサーバのうちの1つのサーバがもはや前記サーバ・クラウド中になく、前記複数のサーバのうちの1つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないとき、クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収するステップ」という事項を有するものとなっており,上記のとおり,本願発明1-9は,上記引用文献1に記載された発明及び上記引用文献2に記載された技術的事項に基づいて,当業者が容易に発明できたものではない。したがって,原査定を維持することはできない。


第6 当審拒絶理由について
1.特許法36条6項2号について
当審では,請求項1,7の「サーバ・クラウドがもはや完全な状態でないとき」のうち,「完全な状態」がどのような状態のことを指すものか不明であるとの拒絶の理由を通知しているが,平成29年7月20日付けの補正において,「前記複数のサーバのうちの1つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないとき」と補正された結果,この拒絶の理由は解消した。


第7 むすび
以上のとおり,本願発明1-9は,当業者が引用発明及び引用文献2に記載された技術的事項に基づいて容易に発明をすることができたものではない。
したがって,原査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。
よって,結論のとおり審決する。
 
審決日 2017-09-08 
出願番号 特願2015-84200(P2015-84200)
審決分類 P 1 8・ 121- WY (G06F)
P 1 8・ 537- WY (G06F)
最終処分 成立  
前審関与審査官 漆原 孝治  
特許庁審判長 辻本 泰隆
特許庁審判官 山崎 慎一
須田 勝巳
発明の名称 サーバ・クラウドにおけるキャパシティ・オン・デマンドを管理するための装置、コンピュータ実装方法、および製造品(サーバ・クラウドにおけるキャパシティ・オン・デマンドの管理)  
代理人 上野 剛史  
復代理人 松井 光夫  
復代理人 村上 博司  
代理人 太佐 種一  
  • この表をプリントする

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