2016-016156

特願２０１５－　８４２００「サーバ・クラウドにおけるキャパシティ・オン・デマンドを管理するための装置、コンピュータ実装方法、および製造品（サーバ・クラウドにおけるキャパシティ・オン・デマンドの管理）」拒絶査定不服審判事件〔平成２７年　８月２０日出願公開、特開２０１５－１４９０９７、請求項の数（９）〕について、次のとおり審決する。

【結　論】 原査定を取り消す。 本願の発明は、特許すべきものとする。

【理　由】 第１　手続の経緯 本願は，２０１３年３月２１日（パリ条約による優先権主張外国庁受理２０１２年３月２７日　米国）を国際出願日とする特願２０１４－５５７９５４号の一部を，特許法４４条１項の規定により，平成２７年４月１６日に新たな特許出願としたものであって， 同年４月１６日付けで審査請求がされ， 平成２８年３月２２日付けで審査官により拒絶理由が通知され，これに対して 同年４月１８日付けで意見書が提出されると共に手続補正がなされ， 同年７月２９日付けで審査官により拒絶査定（原査定）がなされ，これに対して 同年１０月２８日付けで審判請求がなされると共に手続補正がなされ， 同年１２月２８日付けで審査官により特許法１６４条３項の規定に基づく報告がなされ， 平成２９年７月１２日付けで拒絶理由通知（当審）がされ， 同年７月２０日付けで意見書が提出されると共に手続補正がなされたものである。 第２　本願発明 本願請求項１－９に係る発明（以下，それぞれ「本願発明１」－「本願発明９」という。）は，平成２９年７月２０日付けの手続補正で補正された特許請求の範囲の請求項１－９に記載された事項により特定される，以下のとおりの発明である。 「【請求項１】 サーバ・クラウド中の複数のサーバのために複数のリソースのキャパシティを管理するための、少なくとも１つのプロセッサによって実行されるコンピュータ実装方法であって、 （Ａ）前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも１つのサーバから、前記複数のリソースのうちの少なくとも１つのリソースのキャパシティを借りるステップと、 （Ｂ）前記サーバ・クラウドが完全な状態である限り、前記借りたキャパシティを前記サーバ・クラウド中の前記複数のサーバのうちの異なるサーバに貸すステップと、 （Ｃ）前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中になく、前記複数のサーバのうちの１つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないとき、クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収するステップと を含む方法。 【請求項２】 前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも１つのサーバ中のクラウド永続キャパシティを、前記サーバ・クラウド中の別のサーバと共有するステップをさらに含み、前記クラウド永続キャパシティが、前記サーバ・クラウド中の前記複数のサーバのうちの前記１つのサーバ上で永続的にイネーブルにされるキャパシティであって前記サーバ・クラウド中の他のサーバと共有できるキャパシティである、請求項１に記載の方法。 【請求項３】 前記複数のリソースがプロセッサを含む、請求項１に記載の方法。 【請求項４】 前記複数のリソースがメモリを含む、請求項１に記載の方法。 【請求項５】 ステップ（Ｃ）が、前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中にないせいで前記サーバ・クラウドがもはや完全な状態でないときに、前記複数のサーバ全てからの全ての借りたキャパシティをディセーブルにするステップと、前記複数のサーバ全てからの全ての貸したキャパシティを回収するステップとを含む、請求項１に記載の方法。 【請求項６】 ステップ（Ｃ）が、前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中にないせいで前記サーバ・クラウドがもはや完全な状態でないときに、前記１つのサーバから借りた、借りたキャパシティをディセーブルにするステップと、前記１つのサーバ上の貸したキャパシティを回収するステップと、まだ前記サーバ・クラウド中にある複数のサーバについての他の借りたキャパシティおよび貸したキャパシティを保持するステップとを含む、請求項１に記載の方法。 【請求項７】 サーバ・クラウド中の複数のサーバのために複数のリソースのキャパシティを管理するための、少なくとも１つのプロセッサによって実行されるコンピュータ実装方法であって、前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも１つのサーバから、前記複数のリソースのうちの少なくとも１つのリソースのクラウド永続キャパシティを借りるステップであって、前記複数のリソースがプロセッサおよびメモリを含み、前記クラウド永続キャパシティが、前記サーバ・クラウド中の前記複数のサーバのうちの前記１つのサーバ上で永続的にイネーブルにされるキャパシティであって前記サーバ・クラウド中の他のサーバと共有できるキャパシティである、前記借りるステップと、前記サーバ・クラウドが完全な状態である限り、前記借りたキャパシティを前記サーバ・クラウド中の前記複数のサーバのうちの異なるサーバに貸すステップと、前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中になく、前記複数のサーバのうちの１つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないときに、前記１つのサーバから借りた、借りたキャパシティをディセーブルにするステップ、前記１つのサーバ上の貸したキャパシティを回収するステップ、ならびに、まだ前記サーバ・クラウド中にある複数のサーバについての他の借りたキャパシティおよび貸したキャパシティを保持するステップを実施するステップとを含む方法。 【請求項８】 請求項１から７のいずれか一項に記載された方法の各ステップを実行するための手段を備える、システム。 【請求項９】 請求項１から７のいずれか一項に記載された方法の各ステップをコンピュータに実行させる、プログラム。」 第３　引用文献，引用発明等 １．引用文献１について 原査定の拒絶の理由に引用された文献， 河井　保博，新紀年企画・日本型ＩＴ革命の将来　ブロードバンド時代のサイト構築　大容量のトラフィックをさばき切るシステムを求めて，日経インターネットテクノロジー，日本，日経ＢＰ社，２００１年　８月２２日，第50号，pp.46-49 には，図面とともに次の事項が記載されている。 「そこで重要になってくるのが「キャパシティ・オンデマンド」（ＣｏＤ）の考え方。トラフィック，あるいはサーバーの処理量の増加にあわせて，ＣＰＵ数などサーバー・リソースをオンデマンドで提供するアイデアである。もちろん，サーバー価格は使ったリソースの量に応じて変わる従量制。万一に備えていつも余分なサーバー・リソースを抱え，その費用を払い続けるといった問題を解決できる（図１）。」（４６ページ右欄下から７行－４７ページ左欄上から４行） 「こうした限界を考えると，サーバー・ベンダーがＣＰＵ数を増減させつつ，従量制で課金するというモデルはなかなかユーザーのニーズに馴染まない。そこで注目したいのが，ホスティング・サービス事業者，いわゆるマネージド・サービス・プロバイダ（ＭＳＰ）によるサービスである。実際，ＭＳＰがキャパシティ・オンデマンドに取り組む動きは国内でも出始めている。例えばクールサイトは，すでにピーク対策を考慮したホスティング・サービスとして，キャパシティ・オンデマンドを実践している。 仕組みはこうだ。まず，４～５サイトを単位に，１つの大規模システムを共有させる。１サイトごとに必要なキャパシティを見積もり，その２０倍のトラフィックに耐えられるだけのリソースを割り当てる。これで急激なトラフィック増加にある程度耐えられる（図３）。 しかし，ピークが２０倍の容量の範囲に収まるかどうかはわからない。そこで同社は，あえて４～５サイトで１システムを共有させるスタイルを選んだ。「２０倍の容量でさばききれないほどトラフィックが増加した場合，他社用に割り当てているサーバー・リソースのうち，空いているリソースを貸し出す」（クールサイト社長の北原穂高氏）のである。 ただ，クールサイトのサービスの場合，トラフィックの増加に伴って自動的にサーバー・リソースを増やしてくれるわけではない。クールサイトのエンジニアがトラフィックを監視し，状況に応じて手作業でロード・バランサーの設定を変えることで，キャパシティ・オンデマンドを実現している。」（４８ページ左欄下から５行－４９ページ左欄上から２行） 図３ したがって，上記引用文献１には次の発明（以下，「引用発明」という。）が記載されていると認められる。 「トラフィック，あるいはサーバーの処理量の増加にあわせて，ＣＰＵ数などサーバー・リソースをオンデマンドで提供するアイデアである，キャパシティ・オンデマンドシステムであって， サーバー価格は使ったリソースの量に応じて変わる従量制であり，万一に備えていつも余分なサーバー・リソースを抱え，その費用を払い続けるといった問題を解決するものであり， ４～５サイトを単位に，１つの大規模システムを共有させ，１サイトごとに必要なキャパシティを見積もり，その２０倍のトラフィックに耐えられるだけのリソースを割り当て， トラフィックを監視し，状況に応じて手作業でロード・バランサーの設定を変えることで，キャパシティ・オンデマンドを実現する キャパシティ・オンデマンドシステム。」 ２．引用文献２について また，原査定の拒絶の理由に引用された引用文献２（特開２０１０－１７８３８１号公報）には，図面とともに次の事項が記載されている。 「【００２４】 図３は、リソース・マネージャ１２４の一例のブロック図であり、リソース・マネージャ１２４の、レンダリング・デバイス１２０を含む他のシステムとの対話の一例を示している。リソース・マネージャ１２４には、リソース割当サブシステム２０４，ユーザ対話サブシステム２０６，リソース監視サブシステム２０８，および共有リソース・データベース２１２が含まれる。リソース・マネージャ１２４には、レンダリング・デバイス１２０およびマルチデバイス・プロクシ・サーバ１１２など他のシステムと通信するための、通信エージェント２１６も含まれる。他のシステムと通信するために、任意の型の適切なプロトコルが用いられてよい。例えば、セッション・インビテーション・プロトコル（ＳＩＰ）、ハイパー・テキスト・トランスファー・プロトコル（ＨＴＴＰ）、シンプル・メール・トランスファー・プロトコル（ＳＭＴＰ）などのプロトコル、または同様のプロプライエタリな（proprietary ）プロトコルが用いられる。」 「【００２６】 リソース監視サブシステム２０８は、近傍のデバイスと通信して、どのリソースがユーザに利用可能かを判定する。例えば、会議室には、フル・サイズのディスプレイと音響システムとを有するコンピュータが存在する場合がある。リソース監視サブシステム２０８は、ディスプレイおよび音響システムなど、使用に利用可能なリソースをこのコンピュータが有することを確かめるため、このコンピュータと通信する。リソース・マネージャ１２４は、デバイスを構成要素のリソース（component resource）の集合体として扱う。したがって、多様なユーザが単一のデバイスを共有することが可能である。」 「【００５２】 ブロック３８８にて、ブロック３８６で送信された選択リソースをユーザが予約取消したことを、リソース・マネージャ１２４が確認したか否かが判定される。確認が受信された場合、フローはブロック３９０へ進む。ブロック３９０では、方法３５０を実装するレンダリング・デバイス１２０がマルチデバイス・プロクシ・サーバ１１２へ通知を送信し、ブロック３８４で選択されたリソースをユーザに関連する利用可能なリソース・プールから取り除くべきことを示す。これに代えて、後に説明するように、そうした通知をリソース・マネージャ１２４が送信してもよい。」 「【００５５】 ブロック４０４にて、特定の近傍の利用可能なリソースが判定される。これには、近傍に存在するリソースを判定することと、それに続いてそれらのうち利用可能なリソースを判定することとが含まれる。ユーザ対話サブシステム２０６は、共有リソース・データベース２１２に問い合わせることによって、近傍の利用可能なリソースを判定する。さらに、リソースが貸与可能なリソースの場合、ユーザ対話サブシステム２０６は、リソース割当サブシステム２０４によって強制される、アクセス制御ポリシー、課金ポリシーなどに基づいて、利用可能なリソースを判定する。」 したがって，上記引用文献２には， 「リソース・マネージャ１２４には，共有リソース・データベース２１２が含まれ， 選択リソースをユーザが予約取消したことを、リソース・マネージャ１２４が確認したら，選択されたリソースをユーザに関連する利用可能なリソース・プールから取り除き， 近傍に存在するリソースのうち利用可能なリソースを判定し， 共有リソース・データベース２１２に問い合わせることによって、近傍の利用可能なリソースを判定する」という技術的事項が記載されていると認められる。 第４　対比・判断 １．本願発明１について （１）対比 本願発明１と引用発明とを対比すると，次のことがいえる。 引用発明における「大規模システム」は，本願発明１における「サーバ・クラウド」に，以下，「ＣＰＵ数などサーバー・リソース」は，「リソース」に，それぞれ相当する。 引用発明の「キャパシティ・オンデマンドシステム」は，「トラフィック，あるいはサーバーの処理量の増加にあわせて，ＣＰＵ数などサーバー・リソースをオンデマンドで提供するアイデアである」ことから，本願発明１と“（Ａ）前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも１つのサーバから、前記複数のリソースのうちの少なくとも１つのリソースのキャパシティを借りるステップ”及び“（Ｂ）前記サーバ・クラウドが完全な状態である限り、前記借りたキャパシティを前記サーバ・クラウド中の前記複数のサーバのうちの異なるサーバに貸すステップ”を有する点で一致するといえる。 また，引用発明は「トラフィックを監視し，状況に応じて手作業でロード・バランサーの設定を変えることで，キャパシティ・オンデマンドを実現する」ものであるが，当該設定が変更された後，リソースの貸借の手続が，コンピュータによって行われることは当業者に自明であるから，本願発明１とは“サーバ・クラウド中の複数のサーバのために複数のリソースのキャパシティを管理するための、少なくとも１つのプロセッサによって実行されるコンピュータ実装方法”である点で一致するといえる。 したがって，本願発明１と引用発明との間には，次の一致点，相違点があるといえる。 （一致点） 「サーバ・クラウド中の複数のサーバのために複数のリソースのキャパシティを管理するための、少なくとも１つのプロセッサによって実行されるコンピュータ実装方法であって、 （Ａ）前記サーバ・クラウド中の前記複数のサーバのうちの少なくとも１つのサーバから、前記複数のリソースのうちの少なくとも１つのリソースのキャパシティを借りるステップと、 （Ｂ）前記サーバ・クラウドが完全な状態である限り、前記借りたキャパシティを前記サーバ・クラウド中の前記複数のサーバのうちの異なるサーバに貸すステップと、 を含む方法。」 （相違点） 本願発明１は「（Ｃ）前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中になく、前記複数のサーバのうちの１つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないとき、クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収するステップ」という構成を備えるのに対し，引用発明はそのような構成を備えていない点。 （２）相違点についての判断 上記相違点について検討すると，引用文献２には，「リソース・マネージャ１２４には，共有リソース・データベース２１２が含まれ， 選択リソースをユーザが予約取消したことを、リソース・マネージャ１２４が確認したら，選択されたリソースをユーザに関連する利用可能なリソース・プールから取り除き， 近傍に存在するリソースのうち利用可能なリソースを判定し， 共有リソース・データベース２１２に問い合わせることによって、近傍の利用可能なリソースを判定する」という技術的事項が記載されているものの，ユーザの判断に基づいてリソース・マネージャが利用不可能とするものであり，相違点に係る本願発明１の「（Ｃ）前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中になく、前記複数のサーバのうちの１つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないとき、クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収するステップ」という構成は上記引用文献２には記載されていない。 したがって，本願発明１は，当業者であっても引用発明，引用文献２に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 ２．本願発明２－６について 本願発明２－６も，本願発明１の「（Ｃ）前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中になく、前記複数のサーバのうちの１つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないとき、クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収するステップ」と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献２に記載された技術的事項に基づいて容易に発明できたものとはいえない。 ３．本願発明７－９について 本願発明７は，本願発明１の「前記複数のリソースのうちの少なくとも１つのリソースのキャパシティを借りるステップ」における，「リソースのキャパシティ」つき，「前記複数のリソースがプロセッサおよびメモリを含み、前記クラウド永続キャパシティが、前記サーバ・クラウド中の前記複数のサーバのうちの前記１つのサーバ上で永続的にイネーブルにされるキャパシティであって前記サーバ・クラウド中の他のサーバと共有できるキャパシティである」との限定事項を付し，さらに，「まだ前記サーバ・クラウド中にある複数のサーバについての他の借りたキャパシティおよび貸したキャパシティを保持するステップを実施するステップ」をも有する方法の発明であるが，本願発明１と同様，「（Ｃ）前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中になく、前記複数のサーバのうちの１つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないとき、クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収するステップ」に対応する構成を備えるものであるから，本願発明１と同様の理由により，当業者であっても，引用発明，引用文献２に記載された技術的事項に基づいて容易に発明できたものとはいえない。 また，本願発明８及び９は，本願発明１－７に対応するそれぞれ，システム及びプログラムの発明であって，カテゴリーのみ異なる発明であるから，本願発明１と同様の理由により，当業者であっても，引用発明，引用文献２に記載された技術的事項に基づいて容易に発明できたものとはいえない。 第５　原査定の概要及び原査定についての判断 原査定は，請求項１－９について上記引用文献１，２に基づいて，当業者が容易に発明できたものであるから，特許法２９条２項の規定により特許を受けることができないというものである。しかしながら，平成２９年７月２０日付け手続補正により補正された請求項１，７は，それぞれ「（Ｃ）前記複数のサーバのうちの１つのサーバがもはや前記サーバ・クラウド中になく、前記複数のサーバのうちの１つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないとき、クラウド・キャパシティ・オン・デマンド・マネージャが、借りたキャパシティをディセーブルにし、貸したキャパシティを回収するステップ」という事項を有するものとなっており，上記のとおり，本願発明１－９は，上記引用文献１に記載された発明及び上記引用文献２に記載された技術的事項に基づいて，当業者が容易に発明できたものではない。したがって，原査定を維持することはできない。 第６　当審拒絶理由について １．特許法３６条６項２号について 当審では，請求項１，７の「サーバ・クラウドがもはや完全な状態でないとき」のうち，「完全な状態」がどのような状態のことを指すものか不明であるとの拒絶の理由を通知しているが，平成２９年７月２０日付けの補正において，「前記複数のサーバのうちの１つのサーバが正しく機能していないことにより又は適切な応答をしないことにより前記サーバ・クラウドがもはや完全な状態でないとき」と補正された結果，この拒絶の理由は解消した。 第７　むすび 以上のとおり，本願発明１－９は，当業者が引用発明及び引用文献２に記載された技術的事項に基づいて容易に発明をすることができたものではない。 したがって，原査定の理由によっては，本願を拒絶することはできない。 また，他に本願を拒絶すべき理由を発見しない。 よって，結論のとおり審決する。