2022-010023

第２ 原査定の概要

原査定（令和４年４月１４日付け拒絶査定）の概要は次のとおりである。

（進歩性）この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。

記 （引用文献等については引用文献等一覧参照）

・請求項 １、３－５、７－９

・引用文献等 １－４

＜拒絶の理由を発見しない請求項＞

令和 ３年１１月３０日付け手続補正書による補正後の請求項（２，６）に係る発明については、現時点では、拒絶の理由を発見しない。

＜引用文献等一覧＞

１．加藤 純 ほか、Ａｌｌ－Ｆｌａｓｈ Ｈｙｐｅｒ－Ｃｏｎｖｅｒｇｅｄ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅに向けたアーキテクチャーの提案、情報処理学会研究報告、システムソフトウェアとオペレーティング・システム（ＯＳ）、２０１７－ＯＳ－１４１［ｏｎｌｉｎｅ］、日本、情報処理学会、２０１７年０７月１９日、ｐ．１－７

２．特表２０１５－５２０８７６号公報

３．特開２０１３－１６４８２２号公報

４．特表２０１６－５３６７１４号公報

第３ 審判請求時の補正（本件補正）について

審判請求時の補正（以下、「本件補正」という。）は、以下に示すとおり、特許法１７条の２第３項から第６項までの要件に違反しているものとはいえない。（下線は当審で付加。）

本件補正によって請求項１に「、並びに、前記第１処理要求及び前記第２処理要求の発行数」という事項を追加する補正事項（以下、「補正事項１」という。）は、本件補正前の「情報収集部」について限定的に減縮するものである。

また、本件補正によって、本件補正前の請求項１に「前記情報収集部により収集された前記第１処理要求の前記ＩＯＰＳが、前記第１仮想化部におけるレイテンシが悪化する境界にあたる判定閾値以上の場合に、前記第２仮想環境の性能の低下を抑制するための性能低下抑制処理について、前記第１仮想化部を前記処理対象とすると判定し、前記アプリケーション実行部毎のスロットリング量の分担を決定して、前記分担にしたがって各前記アプリケーション処理実行部から出力される第１処理要求の出力を抑制する判定部」とあったものを、本件補正後に「前記第１処理要求の発行数が少なくとも前記第１仮想化部のレイテンシが悪化する前記第１処理要求の発行数の境界にあたるＶＭ閾値以上で且つ前記第２処理要求の発行数が少なくとも前記第２仮想化部のレイテンシが悪化する前記第２処理要求の発行数の境界にあたるコンテナ閾値以上の場合であって、前記情報収集部により収集された前記第１処理要求の前記ＩＯＰＳが、前記第１処理要求に対する処理が前記第２処理要求に対する処理を低下させると判定される基準となる対象判定閾値以上の場合に、前記第２仮想環境の性能の低下を抑制するための性能低下抑制処理について、前記第１仮想化部を処理対象とすると判定し、前記第１処理要求の前記ＩＯＰＳが前記対象判定閾値未満の場合に、前記第２仮想化部を前記処理対象とすると判定し、前記アプリケーション実行部毎のスロットリング量の分担を決定して、前記分担にしたがって各前記アプリケーション実行部から出力される第１処理要求の出力を抑制する判定部」とする補正事項（以下、「補正事項２」という。）は、概ね、本件補正前の「判定閾値」及び「前記第２仮想環境の性能の低下を抑制するための性能低下抑制処理」について限定的に減縮するとともに、「処理対象」が「第１仮想化部」又は「第２仮想化部」と判定される条件についても限定して、本件補正前の「判定部」について限定的に減縮するものである。

また、補正事項１については、当初明細書段落【００２７】に、「統計情報取得部２０３は、Ｉ／Ｏ受付部２０２が出力したＩ／Ｏ要求に関する情報をＩ／Ｏ受付部２０２から取得する。例えば、統計情報取得部２０３は、Ｉ／Ｏ受付部２０２が出力したＩ／Ｏ要求のサイズ、出力の通知及び応答の受信の通知をＩ／Ｏ受付部２０２から取得する。そして、統計情報取得部２０３は、各Ｉ／Ｏ要求について、Ｉ／Ｏサイズの分布や、所定時間毎のＩ／Ｏ発行数及びＩＯＰＳ（Input/output Operations Per Second）といったＩ／Ｏ要求のレイテンシに影響を与える情報を取得する。そして、統計情報取得部２０３は、取得した各Ｉ／Ｏ要求に関する情報をＩ／Ｏ要求の送信元の情報とともにＩ／Ｏスケジューラ１０の統計情報管理部１０３へ出力する。」と記載されているから、当初明細書等に新規事項を追加するものとはいえない。

補正事項２については、本件補正前の請求項２に「前記判定部は、前記第１処理要求の発行数が少なくとも前記第１仮想化部のレイテンシが悪化する前記第１処理要求の発行数の境界にあたるＶＭ閾値以上で且つ前記第２処理要求の発行数が少なくとも前記第２仮想化部のレイテンシが悪化する前記第２処理要求の発行数の境界にあたるコンテナ閾値以上の場合であって、前記第１処理要求の前記ＩＯＰＳが、前記第１処理要求に対する処理が前記第２処理要求に対する処理を低下させると判定される基準となる対象判定閾値以上の場合に、前記第１仮想化部を前記処理対象とし、前記第１処理要求の前記ＩＯＰＳが前記対象判定閾値未満の場合に、前記第２仮想化部を前記処理対象とする」と記載されているから、当初明細書等に新規事項を追加するものとはいえない。

本件補正前の請求項７～９（本件補正後の請求項６～８）に対する補正も同様に、限定的減縮を目的とする補正であって、かつ、当初明細書等に新規事項を追加するものではない。

そして、以下、第４～第６に示すように、本件補正後の請求項１～８に係る発明は、独立特許要件を満たすものである。

第４ 本願発明

本願請求項１～８に係る発明（以下、「本願発明１」～「本願発明８」といい、これらをまとめて「本願発明」ということがある。）は、令和４年６月２９日付け手続補正書の特許請求の範囲の請求項１～８に記載された、次のとおりのものと認める。（下線は、補正箇所を示すとものとして、審判請求人が付加したものである。）

「 【請求項１】

仮想的なストレージコントローラにより形成される第１共有ストレージを有し、前記第１共有ストレージを用いてアプリケーションを実行する複数のアプリケーション実行部を含む第１仮想環境を提供する第１仮想化部と、

物理的なストレージコントローラにより形成される第２共有ストレージを有する第２仮想環境を提供する第２仮想化部と、

データを格納する記憶部と、

続きを表示（全37行）

前記記憶部に対する前記第１仮想化部からの第１処理要求及び前記第２仮想化部からの第２処理要求を処理する処理実行部と、

前記第１処理要求の１秒あたりの入出力操作数（ＩＯＰＳ）、並びに、前記第１処理要求及び前記第２処理要求の発行数を収集する情報収集部と、

前記第１処理要求の発行数が少なくとも前記第１仮想化部のレイテンシが悪化する前記第１処理要求の発行数の境界にあたるＶＭ閾値以上で且つ前記第２処理要求の発行数が少なくとも前記第２仮想化部のレイテンシが悪化する前記第２処理要求の発行数の境界にあたるコンテナ閾値以上の場合であって、前記情報収集部により収集された前記第１処理要求の前記ＩＯＰＳが、前記第１処理要求に対する処理が前記第２処理要求に対する処理を低下させると判定される基準となる対象判定閾値以上の場合に、前記第２仮想環境の性能の低下を抑制するための性能低下抑制処理について、前記第１仮想化部を処理対象とすると判定し、前記第１処理要求の前記ＩＯＰＳが前記対象判定閾値未満の場合に、前記第２仮想化部を前記処理対象とすると判定し、前記アプリケーション実行部毎のスロットリング量の分担を決定して、前記分担にしたがって各前記アプリケーション実行部から出力される第１処理要求の出力を抑制する判定部と

を備えたことを特徴とする情報処理装置。

【請求項２】

前記第１仮想化部は、仮想マシンが動作する前記第１仮想環境を提供し

前記第２仮想化部は、オペレーティングシステム（ＯＳ）における仮想的な動作環境である前記第２仮想環境を提供する

ことを特徴とする請求項１に記載の情報処理装置。

【請求項３】

前記判定部は、決定した処理対象からの前記第１処理要求の前記処理実行部による処理数を抑制することを特徴とする請求項１又は２に記載の情報処理装置。

【請求項４】

前記判定部は、前記第１仮想化部に対して前記第１処理要求の出力数を抑制する指示することで、前記処理実行部による前記第１処理要求の処理数を抑制することを特徴とする請求項１～３のいずれか一つに記載の情報処理装置。

【請求項５】

前記判定部は、前記処理実行部に対して前記第２処理要求を処理する割合の低下を指示することで、前記処理実行部による前記第２処理要求の処理数を抑制することを特徴とする請求項１に記載の情報処理装置。

【請求項６】

演算処理を行う演算処理装置及びデータを格納する記憶装置を有する情報処理システムであって、

前記演算処理装置は、

仮想的なストレージコントローラにより形成される第１共有ストレージを有し、前記第１共有ストレージを用いてアプリケーションを実行する複数のアプリケーション実行部を含む第１仮想環境を提供する第１仮想化部と、

物理的なストレージコントローラにより形成される第２共有ストレージを有する第２仮想化部と、

前記記憶装置に対する前記第１仮想化部からの第１処理要求及び前記第２仮想化部からの第２処理要求を処理する処理実行部と、

前記第１処理要求のＩＯＰＳ、並びに、前記第１処理要求及び前記第２処理要求の発行数を収集する情報収集部と、

前記第１処理要求の発行数が少なくとも前記第１仮想化部のレイテンシが悪化する前記第１処理要求の発行数の境界にあたるＶＭ閾値以上で且つ前記第２処理要求の発行数が少なくとも前記第２仮想化部のレイテンシが悪化する前記第２処理要求の発行数の境界にあたるコンテナ閾値以上の場合であって、前記情報収集部により収集された前記第１処理要求の前記ＩＯＰＳが、前記第１処理要求に対する処理が前記第２処理要求に対する処理を低下させると判定される基準となる対象判定閾値以上の場合に、前記第２仮想化部の性能の低下を抑制するための性能低下抑制処理について、前記第１仮想化部を処理対象とすると判定し、前記第１処理要求の前記ＩＯＰＳが前記対象判定閾値未満の場合に、前記第２仮想化部を前記処理対象とすると判定し、前記アプリケーション実行部毎のスロットリング量の分担を決定して、前記分担にしたがって各前記アプリケーション実行部から出力される第１処理要求の出力を抑制する判定部と

を備えたことを特徴とする情報処理システム。

【請求項７】

データを格納する記憶装置に対する、仮想的なストレージコントローラにより形成される第１共有ストレージを有し、前記第１共有ストレージを用いてアプリケーションを実行する複数のアプリケーション実行部を含む第１仮想環境からの第１処理要求及び物理的なストレージコントローラにより形成される第２共有ストレージを有する第２仮想環境からの第２処理要求を処理し、

前記第１処理要求のＩＯＰＳ、並びに、前記第１処理要求及び前記第２処理要求の発行数を収集し、

前記第１処理要求の発行数が少なくとも前記第１仮想環境のレイテンシが悪化する前記第１処理要求の発行数の境界にあたるＶＭ閾値以上で且つ前記第２処理要求の発行数が少なくとも前記第２仮想環境のレイテンシが悪化する前記第２処理要求の発行数の境界にあたるコンテナ閾値以上の場合であって、収集された前記第１処理要求の前記ＩＯＰＳが、前記第１処理要求に対する処理が前記第２処理要求に対する処理を低下させると判定される基準となる対象判定閾値以上の場合に、前記第２仮想環境の性能の低下を抑制するための性能低下抑制処理について、前記第１仮想環境を処理対象とすると判定し、前記第１処理要求の前記ＩＯＰＳが前記対象判定閾値未満の場合に、前記第２仮想環境を前記処理対象とすると判定し、前記アプリケーション実行部毎のスロットリング量の分担を決定して、前記分担にしたがって各前記アプリケーション実行部から出力される第１処理要求の出力を抑制する

ことを特徴とする情報処理装置制御方法。

【請求項８】

データを格納する記憶装置に対する、仮想的なストレージコントローラにより形成される第１共有ストレージを有し、前記第１共有ストレージを用いてアプリケーションを実行する複数のアプリケーション実行部を含む第１仮想環境からの第１処理要求及び物理的なストレージコントローラにより形成される第２共有ストレージを有する第２仮想環境からの第２処理要求を処理し、

前記第１処理要求のＩＯＰＳ、並びに、前記第１処理要求及び前記第２処理要求の発行数を収集し、

前記第１処理要求の発行数が少なくとも前記第１仮想環境のレイテンシが悪化する前記第１処理要求の発行数の境界にあたるＶＭ閾値以上で且つ前記第２処理要求の発行数が少なくとも前記第２仮想環境のレイテンシが悪化する前記第２処理要求の発行数の境界にあたるコンテナ閾値以上の場合であって、収集された前記第１処理要求の前記ＩＯＰＳが、前記第１処理要求に対する処理が前記第２処理要求に対する処理を低下させると判定される基準となる対象判定閾値以上の場合に、前記第２仮想環境の性能の低下を抑制するための性能低下抑制処理について、前記第１仮想環境を処理対象とすると判定し、前記第１処理要求の前記ＩＯＰＳが前記対象判定閾値未満の場合に、前記第２仮想環境を前記処理対象とすると判定し、前記アプリケーション実行部毎のスロットリング量の分担を決定して、前記分担にしたがって各前記アプリケーション実行部から出力される第１処理要求の出力を抑制する

処理をコンピュータに実行させることを特徴とする情報処理装置制御プログラム。」

第５ 引用例

１ 引用例１に記載された事項及び引用発明

（１）原査定の拒絶の理由において引用した、本願の出願前に既に公知である、加藤 純 ほか、Ａｌｌ－Ｆｌａｓｈ Ｈｙｐｅｒ－Ｃｏｎｖｅｒｇｅｄ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅに向けたアーキテクチャーの提案、情報処理学会研究報告、システムソフトウェアとオペレーティング・システム（ＯＳ）、２０１７－ＯＳ－１４１［ｏｎｌｉｎｅ］、日本、情報処理学会、２０１７年０７月１９日、ｐ．１－７（以下、「引用例１」という。）には、次の事項が記載されている。

ア 「概要：従来の仮想化基盤にストレージ機能を統合したＨｙｐｅｒ－Ｃｏｎｖｅｒｇｅｄ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ（ＨＣＩ）では、ストレージデバイスをすべてＳＳＤとするＡｌｌ－Ｆｌａｓｈが注目されている。本稿では、 ＨＣＩのアーキテクチャーをストレージの構成から２種類に分類して分析を行い、Ａｌｌ－Ｆｌａｓｈ化に伴うデバイス性能の向上によってＩ／Ｏ仮想化がオーバーヘッドとなることを明らかにした。このオーバーヘッドを解決するため、従来の仮想マシンとＩ／Ｏ仮想化のないコンテナをハイブリッドしたアーキテクチャーを提案する。仮想マシンとコンテナでＩ／Ｏ性能が異なるため、このようなアーキテクチャーを活用するためにはＩ／Ｏ性能差を前提としたＩ／Ｏスケジューリングが課題であり、今後はこの課題に取り組む予定である。」（１ページ１～７行）

イ 「２．１ アーキテクチャーの分類

ＨＣＩでは、クラスター内の複数のサーバーにまたがって、サーバー内蔵のストレージデバイスをバックエンドデバイスとして仮想的な共有ストレージを提供するコントローラーがあり、このコントローラーが仮想マシンで実現されているか、ホスト内のコンポーネントとして実現されているかによりアーキテクチャーが異なる。本稿では、前者を仮想マシン型、後者をホスト型と定義することにより、ＨＣＩのアーキテクチャーを２つに分類する。

本稿で定義する仮想マシン型のアーキテクチャーは図１である。このアーキテクチャーでは、クラスターに参加するホスト１つにつきコントローラーＶＭ（ＣＶＭ）と呼ばれるシステム用の仮想マシンが１つあり、クラスター内の複数のコントローラーＶＭがホスト間ネットワークを通して協調することで、仮想的な共有ストレージを提供する。ユーザーのＶＭはこの共有ストレージに対してｉＳＣＳＩ、ＮＦＳ、 ＣＩＦＳなどのストレージプロトコルを通じてアクセスできる。これらのプロトコルを通じて共有ストレージに対してＩ／Ｏが発行されると、まずユーザーのＶＭと同一のホスト上にあるＣＶＭに対してＶＭ間通信でＩ／Ｏが送られる。Ｉ／Ｏを受け取ったＣＶＭはクラスター内でのデータレイアウトを考慮してこのＩ／Ｏ処理を担当するＣＶＭを決定して、必要であれぼホスト間通信でＩ／Ｏを転送する。ＣＶＭにはストレージデバイスであるＳＳＤがパススルーで接続されており、Ｉ／Ｏ処理を担当するＣＶＭはこのＳＳＤに対してＩ／Ｏを行う。

ホスト型のアーキテクチャーは図２が示すように仮想マシン型のようなＣＶＭはなく、ホスト内のストレージコントローラーと呼ばれるコンポーネントによって共有ストレージを実現する。共有ストレージはハイパーバイザーによって仮想化され、ユーザーのＶＭからは仮想デバイスとしてアクセスできる。この仮想デバイスに対してＩ／Ｏが発行されると、ハイパーバイザーがＩ／Ｏをハンドリングしてストレージコントローラーに対してＩ／Ｏを通知する。ストレージコントローラーでの処理は仮想マシン型のＣＶＭと同様に、データのレイアウトからこのＩ／Ｏ処理を担当するストレージコントローラーを決定して、必要ならホスト間通信でＩ／Ｏを転送した後に、Ｉ／Ｏ処理を担当するストレージコントローラーでＳＳＤに対してＩ／Ｏを行う。

仮想マシン型とホスト型の違いは、共有ストレージを扱うコントローラーとハイパーバイザーの結合性である。仮想マシン型のようにコントローラーをＶＭとして独立させてハイパーバイザーとの結合を疎にすることで、ハイパーバイザーを問わない可搬性の高いＨＣＩが実現できる。これに対して、ホスト型のように密結合にすると可搬性が犠牲になる代わりにＶＭ間通信がなくなるため高いＩ／Ｏ性能を発揮できる。このように仮想マシン型とホスト型では可搬性とＩ／Ｏ性能がトレードオフの関係にあり、Ａｌｌ－Ｆｌａｓｈに向けたＨＣＩのアーキテクチャーを検討する上では定性的な可搬性比較に加えて定量的なＩ／Ｏ性能比較が必要である。そのため、以下では仮想マシン型とホスト型でＩ／Ｏ性能比較を行い、定量的な面からも検討を行う。」（２ページ左欄２行～右欄下から５行）

ウ 「２．３ Ａｌｌ－Ｆｌａｓｈ ＨＣＩに向けた考察

仮想マシン型はハイパーバイザーを問わない点で可搬性に優れるが、２．２節の性能比較からレイテンシーと１０ＰＳのどちらにおいてもホスト型の３分の１以下の性能であり、ＣＶＭによって１０ＰＳが律速されることが分かった。ＣＶＭはユーザーＶＭが動作するホスト上での動作を前提とするため、ＣＶＭにＣＰＵやＭｃｍｏｒｙなどのリソースを大量に割くことはユーザーＶＭに提供するリソースの削減につながるため期待できない。今後のハードウェアの進歩に伴うＣＰＵコア数やメモリー容量の増加によりホスト当たりのＶＭ数が増加したとしても、同様にＣＶＭにリソースを大量に割くことができず、逆にＶＭ数が増えることでＣＶＭがボトルネックになりやすく、性能面で将来性が乏しい。複数の異なるハイパーバイザーを前提とするＨＣＩであれば、仮想マシン型の可搬性を活かして１つだけの実装でハイパーバイザーに依存せずＨＣＩを構築できる点を評価しつつも、本稿では、Ａｌｌ－Ｆｌａｓｈ ＨＣＩとしては性能面の懸念が大きいためホスト型を採用する。

ホスト型は仮想マシン型と比較すると３倍近い性能でありスケーラビリティー上のボトルネックもないが、ストレージデバイスであるＳＳＤと比較すると仮想マシンからストレージコントローラーまでの処理に当たるＩ／Ｏ仮想化のオーバーヘッドが大きい。図３のレイテンシーの内訳に注目すると、ＲｅａｄはＳＳＤのレイテンシーが９９マイクロ秒とＩ／Ｏ仮想化の１８マイクロ秒に比べて十分大きいが、ＷｒｉｔｅはＳＳＤのレイテンシーが２０マイクロ秒とＩ／Ｏ仮想化の１６マイクロ秒とほぼ同程度であり、Ｉ／Ｏ仮想化に伴いレイテンシーが２倍近くに伸びていることがわかる。１０ＰＳに関しても、合計１０ＰＳはＶＭ数に比例してスケールするが、１つのＶＭあたりの平均１０ＰＳに着目すると、ＶＭ間でＩ／Ｏが競合しない１ＶＭ時が最もよく、このときのＲｅａｄの１０ＰＳは図４によると２４８Ｋ ＩＯＰＳであるが、本評価で使用したＳＳＤの諸元は４ＫｉＢ Ｒｅａｄが４６０ＫＩＯＰＳ［２０］であるため、 ＶＭあたりではＳＳＤ１本の半分程度の１０ＰＳが限度である。２．２節で述べた準仮想化ブロックデバイスだけでも４ＫｉＢ Ｒｅａｄで３９５Ｋ ＩＯＰＳとＳＳＤ１本分の性能にも達しておらず、Ｉ／Ｏ仮想化がストレージデバイスの性能を引き出す上でのボトルネックとなっている。

このようにホスト型でもＩ／Ｏ仮想化がボトルネックとして顕在化するため、ＨＣＩ基盤にＩ／Ｏ－ｉｎｔｅｎｓｉｖｅなアプリケーションを集約することは困難である。これを解決するために、４節で述べる仮想Ｉ／Ｏ処理の高速化［１４］、［１５］、［２１］、［２２］がこれまで提案されてきたが、２倍に改善してようやくＳＳＤ１本の性能に到達する現状を踏まえると、この改善だけでは複数のＳＳＤを束ねた場合に匹敵する性能を引き出すことは難しく、高速化と直交してＩ／Ｏ仮想化自体を課題と捉えてアーキテクチャーレベルで改善に取り組むのが望ましい。本稿では、Ｉ／Ｏ仮想化のないコンテナ［２３］に着目して、従来のホスト型にコンテナを組み合わせたハイブリッドアーキテクチャーを提案する。」（３ページ右欄１７行～４ページ左欄末行）

エ 「３．仮想マシンとコンテナのハイブリッド

コンテナは仮想マシンのようなＯＳレベルの仮想化ではなく、ホストＯＳからプロセスＩＤやファイルシステムのマウントポイントなどの名前空間を分離［２４］させ、ｃｇｒｏｕｐｓ［２５］などでＣＰＵやメモリーなどのリソースを制約することで実現するプロセスレベルの仮想化である。ゲストがホストＯＳに密結合してしまうためＯＳを選べないというデメリットがあるものの、Ｉ／Ｏ仮想化のような処理がないため軽量［２６］、［２７］である。実際に、表１の環境において仮想マシンと同等の諸元のコンテナをＤｏｃｋｅｒ［２８］で配備を行い、１から２冪で１２８多重で４ＫｉＢのＲｅａｄ／Ｗｒｉｔｅを行った結果が図５である。Ｉ／Ｏ仮想化がないコンテナでは２．３節で述べたような低多重度におけるＷｒｉｔｅのレイテンシーの増加はなく、仮想マシンと比較して半分近くに短縮とストレージデバイスであるＳＳＤと同等の値となった。ＩＯＰＳに関しても同様の理由によって改善しており、コンテナを活用することでＩ／Ｏ－ｉｎｔｅｎｓｉｖｅなアプリケーションの性能要件を満たしやすくなり、これまで以上のＨＣＩ基盤への集約が期待できる。

コンテナを扱うハイブリッド型における課題は、仮想マシンとのＩ／Ｏ競合時の性能低下である。図６は同一ホスト上の仮想マシンとコンテナから同一のＳＳＤに対して、同時に１から２冪で１２８多重でＲｅａｄ負荷をかけてＩ／Ｏを競合させた場合の結果である（なお、この評価ではｄａｔａ－ｐｌａｎｅの設定により挙動が不安定になったため、標準でｄａｔａ－ｐｌａｎｅのコードが含まれるＱＥＭＵ ２．９．０を用いた）。仮想マシンとコンテナのどちらも３２多重以上の場合にＩ／Ｏの競合による単体時との性能差が読み取れるが、このような高多重時の性能低下の傾向は仮想マシンとコンテナで異なっており、仮想マシンではレイテンシーが、コンテナではＩＯＰＳが大幅に低下していることがわかる。コンテナ側のＩＯＰＳの低下幅はＶＭ側のＩＯＰＳ値に等しいことから、コンテナのＩＯＰＳが低下するのはＶＭのＩ／Ｏを処理する分だけコンテナのＩ／Ｏが処理できないためであり、逆に仮想マシン側はＩ／Ｏ仮想化のオーバーヘッドがないコンテナからの高速なＩ／Ｏが高多重度で混じったことによりＩ／Ｏの処理待ちが増えたため、レイテンシーが増加したと考えられる。本稿の提案するハイブリッド型の狙いからコンテナには高Ｉ／Ｏ性能が期待されるが、このように競合する仮想マシンからのＩ／Ｏによる影響を受けやすく、実際に期待されるＩ／Ｏ性能を提供できるかどうかはワークロード依存である。

そのような課題を解決するために、本稿ではハイブリッド型向けのＩ／Ｏスケジューラーを提案する。ハイブリッド型では図５が示すようにＩ／Ｏの発行元が仮想マシンかコンテナかによって大きくＩ／Ｏ性能が異なるため、従来のＩ／Ｏスケジューラーが目指した公平の方向ではなく、アーキテクチャーとしてＩ／Ｏ性能差があることを前提としてシステムの全休最適化を目指す。図６のＩ／Ｏ競合の結果から、仮想マシンからのＩ／Ｏはコンテナからの高多重なＩ／ＯがあるとＩ／Ｏ待ちになりやすい傾向があり、スロットリングを行ったとしてもそれによる性能低下は小さい。このことを利用して、コンテナからの高多重なＩ／Ｏ発行により高いＩ／Ｏ性能が求められる場合には仮想マシンからのＩ／Ｏに対してはスロットリングを行い、代わりにコンテナからのＩ／Ｏを優先して処理することでコンテナ側のＩ／Ｏ性能を向上させることができる。また、仮想マシンからのＩ／Ｏ負荷に応じてスロットリングを行うことでワークロードによる依存度合いを減らし、仮想マシン側がどのようなワークロードであったとしてもコンテナ側は安定した高いＩ／Ｏ性能が期待できる。

仮想マシンからのＩ／ＯのスロットリングはＩ／Ｏのスケジューリングを行うホストではなく仮想マシン内で行うことにより、ホストと仮想マシン間のコンテキストスイッチの回数が減少してＣＰＵ使用率を削減できる。スロットリングはＩ／Ｏ待ちによるレイテンシーの増加という欠点があるものの、Ｉ／Ｏ待ち中にＩ／Ｏをまとめることができるという利点もある。実際に、複数のＩ／Ｏをまとめて１つのシーケンシャルなＩ／Ｏにすることでデバイスの性能を引き出す最適化［２９］、［３０］もあるが、このような最適化と直交して仮想マシン内の準仮想化ブロックデバイスでスロットリングを行い、ホストへのＩ／Ｏをまとめることでホストへのコンテキストスイッチを引き起こすＩ／Ｏ発行の回数を削減できる。」（４ページ右欄１行～５ページ左欄下から７行）

オ 「図２

［図：0001393915000001.jpg］

」

カ 「図６

［図：0001393915000002.jpg］

」

（２）上記（１）の記載から、それぞれ次の事項を読取ることができる。

ア 上記（１）アの「（ＨＣＩ）では、ストレージデバイスをすべてＳＳＤとするＡｌｌ－Ｆｌａｓｈが注目されている。本稿では、…中略…仮想マシンとＩ／Ｏ仮想化のないコンテナをハイブリッドしたアーキテクチャーを提案する」との記載から、引用例１には、“仮想マシンとＩ／Ｏ仮想化のないコンテナをハイブリッドしたアーキテクチャーであるストレージデバイスをすべてＳＳＤとするＡｌｌ－Ｆｌａｓｈ ＨＣＩ”が記載されているといえる。

イ 上記（１）イの「クラスター内の複数のサーバーにまたがって、サーバー内蔵のストレージデバイスをバックエンドデバイスとして仮想的な共有ストレージを提供するコントローラーがあり、このコントローラーが仮想マシンで実現されているか、ホスト内のコンポーネントとして実現されているかによりアーキテクチャーが異なる。本稿では、前者を仮想マシン型、後者をホスト型と定義することにより、ＨＣＩのアーキテクチャーを２つに分類する」との記載、及び上記（１）ウの「本稿では、Ａｌｌ－Ｆｌａｓｈ ＨＣＩとして…中略…ホスト型を採用する」との記載から、引用例１には、“クラスター内の複数のサーバーにまたがって、サーバー内蔵のストレージデバイスをバックエンドデバイスとして仮想的な共有ストレージを提供するコントローラーがあり、このコントローラーが仮想マシンで実現されている仮想マシン型のアーキテクチャーと、ホスト内のコンポーネントとして実現されているホスト型のアーキテクチャーとに分類されるＨＣＩアーキテクチャーを有”することが記載されているといえる。

ウ 上記（１）イの「ホスト型のアーキテクチャーは図２が示すように…中略…ホスト内のストレージコントローラーと呼ばれるコンポーネントによって共有ストレージを実現する。共有ストレージはハイパーバイザーによって仮想化され、ユーザーのＶＭからは仮想デバイスとしてアクセスできる。」との記載、及び上記（１）オ（図２）並びに上記イの認定から、引用例１には、“ホスト型のＨＣＩアーキテクチャーは、ホスト内のストレージコントローラーと呼ばれるコンポーネントによって共有ストレージを実現し、共有ストレージはハイパーバイザーによって仮想化され、ユーザーのＶＭからは仮想デバイスとしてアクセスでき”ることが記載されているといえる。

エ 上記（１）ウの「本稿では、Ｉ／Ｏ仮想化のないコンテナ…に着目して、従来のホスト型にコンテナを組み合わせたハイブリッドアーキテクチャーを提案する」との記載、及び上記（１）エの「コンテナは仮想マシンのようなＯＳレベルの仮想化ではなく、ホストＯＳからプロセスＩＤやファイルシステムのマウントポイントなどの名前空間を分離…させ…中略…プロセスレベルの仮想化である」との記載、並びに上記ウの認定から、引用例１には、“仮想マシンのようなＯＳレベルの仮想化ではなく、ホストＯＳからプロセスＩＤやファイルシステムのマウントポイントなどの名前空間を分離させる、Ｉ／Ｏ仮想化のない、プロセスレベルの仮想化であるコンテナと、前記ホスト型のＨＣＩアーキテクチャーとを組み合わせ”ることが記載されているといえる。

オ 上記（１）エの「図６は同一ホスト上の仮想マシンとコンテナから同一のＳＳＤに対して、同時に１から２冪で１２８多重でＲｅａｄ負荷をかけてＩ／Ｏを競合させた場合の結果である…中略…仮想マシンとコンテナのどちらも３２多重以上の場合にＩ／Ｏの競合による単体時との性能差が読み取れる」との記載、及び上記（１）カ（図６）から、引用例１には、“同一ホスト上の仮想マシンとコンテナから同一のＳＳＤに対して、同時に１から２冪で１２８多重でＲｅａｄ負荷をかけてＩ／Ｏを競合させた場合、仮想マシンとコンテナのどちらも３２多重以上の場合にＩ／Ｏの競合による単体時との性能差が生じる”ことが記載されているといえる。

カ 以上、ア～オの認定から、引用例１には次の発明（以下、「引用発明」という。）が記載されているといえる。

「仮想マシンとＩ／Ｏ仮想化のないコンテナをハイブリッドしたアーキテクチャーであるストレージデバイスをすべてＳＳＤとするＡｌｌ－Ｆｌａｓｈ ＨＣＩであって、

クラスター内の複数のサーバーにまたがって、サーバー内蔵のストレージデバイスをバックエンドデバイスとして仮想的な共有ストレージを提供するコントローラーがあり、このコントローラーが仮想マシンで実現されている仮想マシン型のアーキテクチャーと、ホスト内のコンポーネントとして実現されているホスト型のアーキテクチャーとに分類されるＨＣＩアーキテクチャーを有し、

ホスト型のＨＣＩアーキテクチャーは、ホスト内のストレージコントローラーと呼ばれるコンポーネントによって共有ストレージを実現し、共有ストレージはハイパーバイザーによって仮想化され、ユーザーのＶＭからは仮想デバイスとしてアクセスでき、

仮想マシンのようなＯＳレベルの仮想化ではなく、ホストＯＳからプロセスＩＤやファイルシステムのマウントポイントなどの名前空間を分離させる、Ｉ／Ｏ仮想化のない、プロセスレベルの仮想化であるコンテナと、前記ホスト型のＨＣＩアーキテクチャーとを組み合わせ、

同一ホスト上の仮想マシンとコンテナから同一のＳＳＤに対して、同時に１から２冪で１２８多重でＲｅａｄ負荷をかけてＩ／Ｏを競合させた場合、仮想マシンとコンテナのどちらも３２多重以上の場合にＩ／Ｏの競合による単体時との性能差が生じる

Ａｌｌ－Ｆｌａｓｈ ＨＣＩ。」

２ 引用例２に記載された事項

（１）原査定の拒絶の理由において引用した、本願の出願前に既に公知である、特表２０１５－５２０８７６号公報（平成２７年７月２３日公表。以下、これを「引用例２」という。）には、関連する図面と共に、次の事項が記載されている。（下線は当審で付加。以下同様。）

ア 「【０１２４】

ＩＯＰＳ／レスポンス時間の性能閾値が予め決定されており、その閾値を基準に階層の負荷状態が定義されている。ＩＯＰＳの値とレスポンス時間の値は一対一の関係である。したがって、モニタされているＩＯＰＳ又はレスポンス時間が閾値を超えると、その階層の負荷状態は高負荷であり、閾値以下であれば低負荷である。本例は階層のＩ／Ｏ回数（ＩＯＰＳ）をモニタするため、再配置速度決定プログラム４０６は、ＩＯＰＳの値から階層の負荷状態を決定する。ストレージコントローラ１５５は、ＩＯＰＳとレスポンス時間をモニタし、それらの値からレスポンスカーブを作成し、性能閾値を決定してもよい。」

イ 「図１８

［図：0001393915000003.jpg］

」

３ 引用例３に記載された事項

（１）原査定の拒絶の理由において引用した、本願の出願前に既に公知である、特開２０１３－１６４８２２号公報（平成２５年８月２２日公開。以下、これを「引用例３」という。）には、関連する図面と共に、次の事項が記載されている。

ア 「【００８０】

ここで、ＩＯＰＳ（ＸRup）は、第ｊ階層のＲＡＩＤグループのリード要求に対する応答性能が、要求される応答性能を満たす場合のリード要求の平均ＩＯＰＳである。すなわち、ＲＡＩＤグループにかかる負荷であるＩＯＰＳ（ｘR）がＩＯＰＳ（ＸRup）を下回れば、ＲＡＩＤグループが要求される応答性能を十分に満たすと判断することができる。

【００８１】

換言すれば、ＲＡＩＤグループにかかる負荷であるＩＯＰＳ（ｘR）がＩＯＰＳ（ＸRup）を上回る場合は、ＲＡＩＤグループ内のいずれかのＳｕｂ－ＬＵＮを、第ｊ階層よりもＩ／Ｏ要求に対する応答性能が高い第（ｊ＋１）階層に移動したほうがよいと判断することができる。

【００８２】

そこで、第１の算出部６０３は、算出したＩＯＰＳ（ＸRup）をＲＡＩＤグループ内のＳｕｂ－ＬＵＮの個数で除算することにより、Ｓｕｂ－ＬＵＮへのＩ／Ｏ要求の平均ＩＯＰＳの上限値を表す上方ＩＯＰＳ閾値（Ｘup）を算出することにしてもよい。これにより、リード要求に対する平均応答時間（Ｗ）が最大応答時間（Ｗmax）の場合にＳｕｂ－ＬＵＮにかかる負荷であるリード要求の平均ＩＯＰＳを上方ＩＯＰＳ閾値（Ｘup）として算出することができる。」

４ 引用例４に記載された事項

（１）原査定の拒絶の理由において引用した、本願の出願前に既に公知である、特表２０１６－５３６７１４号公報（平成２８年１１月２４日公表。以下、これを「引用例４」という。）には、関連する図面と共に、次の事項が記載されている。

ア 「【００７１】

[0082] 第２に、施行である。コントローラーは、ＶＭｐ、ｑ、ｒからシェアＸ、Ｙまでの全てのＩＯの合計レートが、総帯域幅Ｂを保証することを確認する。この総帯域幅制限は、グラフにおける任意のカット(cut)において施行することができる。この例は、顧客の１人だけの視点からのものである。図８に示すように、ＶＭがホストされているハイパーバイザーまたはストレージ・サーバーにおいてこれを施行することができる。この例では、コントローラーがハイパーバイザー内部のあるステージにおいて帯域幅制限を施行することを選択したと仮定する。これを行うためには、制限の総和がＢに等しくなるように、ＶＭ毎に帯域幅制限を決定する必要がある。つまり、コントローラー・アプリケーションは、分散型レート制限を行う必要がある。即ち、１組のＮ個のＶＭ（この例では、Ｎ＝３）を想定し、これらの間で帯域幅Ｂを分散することがタスクになる。これは、各ソースにリンクのその最大－最小公正シェアを与えることによって行うことができる。最大－最小分配（sharing)では、ＶＭのトラフィック要求量、即ち、これらがトラフィックを送ることができるレートに基づいて、ＶＭにレートを割り当てる(assign)。具体的には、ＶＭがその要求量よりも大きなレートを得ることがなく、要求量が満たされないＶＭが等しいレートを得るように、要求量が少ない順にレートが割り当てられる。つまり、ＶＭに対して要求量の集合Ｄを想定すると、コントローラーは、最大－最小公正シェアｆを決定し、次いで個々のＶＭに割り当てられるレートを指定し、これらのレートの合計が前述の帯域幅となることを確保する。」

第６ 対比・判断

１ 本願発明１について

（１）対比

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

ア 引用発明の「仮想的な共有ストレージを提供するコントローラー」及び「仮想的な共有ストレージ」は、それぞれ本願発明１の「仮想的なストレージコントローラ」及び「第１共有ストレージ」に相当する。

また、引用発明では、所定のアプリケーションが実行されるのは自明であり、また、「同一ホスト上の仮想マシンとコンテナから同一のＳＳＤに対して、同時に１から２冪で１２８多重でＲｅａｄ負荷をかけてＩ／Ｏを競合させ」ることができることから、本願発明１の「複数のアプリケーション実行部」に相当する構成を有することは明らかである。

してみれば、引用発明の「クラスター内の複数のサーバーにまたがって、サーバー内蔵のストレージデバイスをバックエンドデバイスとして仮想的な共有ストレージを提供するコントローラーがあり、このコントローラーが仮想マシンで実現されている仮想マシン型のアーキテクチャー」は、本願発明１の「仮想的なストレージコントローラにより形成される第１共有ストレージを有し、前記第１共有ストレージを用いてアプリケーションを実行する複数のアプリケーション実行部を含む第１仮想環境を提供する第１仮想化部」に相当するものといえる。

イ 引用発明は、「コンテナと、前記ホスト型のＨＣＩアーキテクチャーとを組み合わせ」るものであって、そのうち、「コンテナ」は、「Ｉ／Ｏ仮想化のない、プロセスレベルの仮想化である」ところ、ホスト型のＨＣＩアーキテクチャーは、物理的なストレージコントローラによって共有ストレージにアクセスするものと認められるから、引用発明の「仮想マシンのようなＯＳレベルの仮想化ではなく、ホストＯＳからプロセスＩＤやファイルシステムのマウントポイントなどの名前空間を分離させる、Ｉ／Ｏ仮想化のない、プロセスレベルの仮想化であるコンテナ」は、本願発明１の「物理的なストレージコントローラにより形成される第２共有ストレージを有する第２仮想環境を提供する第２仮想化部」に相当するものといえる。

ウ 引用発明の「ストレージデバイスをすべてＳＳＤとするＡｌｌ－Ｆｌａｓｈ ＨＣＩ」における、「ＳＳＤ」は、本願発明１の「データを格納する記憶部」に相当する。

エ 引用発明は、「コンテナと、前記ホスト型のＨＣＩアーキテクチャーとを組み合わせ」た上、「同一ホスト上の仮想マシンとコンテナから同一のＳＳＤに対して、同時に１から２冪で１２８多重でＲｅａｄ負荷をかけてＩ／Ｏを競合させ」ることができるものであるから、本願発明１の「前記記憶部に対する前記第１仮想化部からの第１処理要求及び前記第２仮想化部からの第２処理要求を処理する処理実行部」に相当する構成を有するといえる。

オ 引用発明は、「同一ホスト上の仮想マシンとコンテナから同一のＳＳＤに対して、同時に１から２冪で１２８多重でＲｅａｄ負荷をかけてＩ／Ｏを競合させた場合、仮想マシンとコンテナのどちらも３２多重以上の場合にＩ／Ｏの競合による単体時との性能差が生じる」ものであるところ、当該「Ｒｅａｄ負荷をかけてＩ／Ｏを競合させ」るにあたって、「ＶＭ」側のＩＯＰＳ及び「仮想マシンとコンテナ」の処理要求の発行数を取得する構成を有するものといえ、上記ア及びエの認定を踏まえれば、本願発明１の「前記第１処理要求の１秒あたりの入出力操作数（ＩＯＰＳ）、並びに、前記第１処理要求及び前記第２処理要求の発行数を収集する情報収集部」に相当する構成を有するといえる。

カ 引用発明の「Ａｌｌ－Ｆｌａｓｈ ＨＣＩ」は、“情報処理装置”によって実現されていることは明らかであるから、上記ア～オの検討を踏まえると、引用発明と本願発明１とは、次の一致点及び相違点を有する。

〈一致点〉

仮想的なストレージコントローラにより形成される第１共有ストレージを有し、前記第１共有ストレージを用いてアプリケーションを実行する複数のアプリケーション実行部を含む第１仮想環境を提供する第１仮想化部と、

物理的なストレージコントローラにより形成される第２共有ストレージを有する第２仮想環境を提供する第２仮想化部と、

データを格納する記憶部と、

前記記憶部に対する前記第１仮想化部からの第１処理要求及び前記第２仮想化部からの第２処理要求を処理する処理実行部と、

前記第１処理要求の１秒あたりの入出力操作数（ＩＯＰＳ）、並びに、前記第１処理要求及び前記第２処理要求の発行数を収集する情報収集部と、

を備えたことを特徴とする情報処理装置。

〈相違点〉

本願発明１が、「前記第１処理要求の発行数が少なくとも前記第１仮想化部のレイテンシが悪化する前記第１処理要求の発行数の境界にあたるＶＭ閾値以上で且つ前記第２処理要求の発行数が少なくとも前記第２仮想化部のレイテンシが悪化する前記第２処理要求の発行数の境界にあたるコンテナ閾値以上の場合であって、前記情報収集部により収集された前記第１処理要求の前記ＩＯＰＳが、前記第１処理要求に対する処理が前記第２処理要求に対する処理を低下させると判定される基準となる対象判定閾値以上の場合に、前記第２仮想環境の性能の低下を抑制するための性能低下抑制処理について、前記第１仮想化部を処理対象とすると判定し、前記第１処理要求の前記ＩＯＰＳが前記対象判定閾値未満の場合に、前記第２仮想化部を前記処理対象とすると判定し、前記アプリケーション実行部毎のスロットリング量の分担を決定して、前記分担にしたがって各前記アプリケーション実行部から出力される第１処理要求の出力を抑制する判定部」を備えるのに対し、引用発明は、そのような構成を有しない点。

（２）相違点についての判断

上記相違点について検討する。

本願発明は、情報処理装置等に関するものであって（【０００１】）、近年、仮想化技術は、目覚ましい発展を遂げていて、仮想化技術とは、サーバやストレージなど物理的な構成を論理的に扱えるようにしてリソースプールを構成し、リソースプールの中の資源を自由に利用して情報処理システムを構築する技術であり、例えば、サーバの仮想化では、１台の物理マシン上で複数の仮想マシン（ＶＭ：Virtual Machine）が稼働し、この仮想化技術を利用することで、リソースの効率的な活用、ハードウェアの初期投資コストの抑制、省電力及び省スペースなどが実現でき（【０００２】）、このような仮想化技術として、ハイパーバイザー型仮想化やコンテナ型仮想化といった技術が提案されており、ハイパーバイザー型仮想化は、上述した仮想マシンを管理するハイパーバイザーが存在し、各仮想マシン上でそれぞれ異なるＯＳ（Operating System）やアプリケーションが動作し、ハイパーバイザー型仮想化では、仮想マシンはハイパーバイザーを介して動作することになるのに対し、コンテナ型仮想化は、１つのＯＳ上でコンテナ管理ソフトウェアが動作し、そのコンテナ管理ソフトウェアが複数のアプリケーションをそれぞれ独立したプロセス空間や名前空間を有する異なる環境で動作させるものであり、アプリケーション毎の異なる環境のそれぞれがコンテナと呼ばれ（【０００３】）、また、最近では、情報処理システムに対して、用途に応じた柔軟且つ迅速な拡張が求められるようになってきており、この要望に応えるために、シンプルな構成をとり管理が容易なＨＣＩ（Hyper Converged Infrastructure）という技術が注目を集めていて、ＨＣＩは、複数のサーバを有する情報処理システムにおいて、各サーバの内蔵ストレージをその情報処理システム内の全てのサーバからアクセスできる仮想的な共有ストレージとする技術であり、ＨＣＩにより、サーバなどの情報処理装置上に、仮想化技術を用いて構成した仮想化基盤を用いて演算処理機能とストレージ機能とを統合した仮想化インフラが実現され（【０００４】）、さらに、ＳＳＤ（Solid State Drive）などのＮＡＮＤ型フラッシュメモリの低価格化により、ストレージデバイスのＨＤＤ（Hard Disk Drive）からＮＡＮＤ型フラッシュ型メモリへの移行が増加していて、ＮＡＮＤ型フラッシュメモリは、ＨＤＤと比較して動作速度が速く、ＮＡＮＤ型フラッシュメモリへの移行により、情報処理システムにおける一層の性能向上が見込まれることを背景とし（【０００５】）、記憶装置に対するデータの読み出し及び書き込みの技術として、レイテンシの長さに応じてＳＳＤに行わせる動作を第１タイプと第２タイプとに分け、第１タイプの動作を優先して行わせるようにスケジューリングする従来技術や、各プログラムから出力されたデータを一時的に記憶域に格納し、プログラムの重要度に応じて優先的に記憶装置へデータを出力する従来技術があり（【０００６】）、コンテナ型仮想化には、各コンテナは異なるＯＳ上で動作することは困難であるなどの制約が存在するため、異なるＯＳで動作させたい場合など運用上の理由などによりハイパーバイザー型仮想化を利用することが望ましい場合が存在するが（【０００８】）、ハイパーバイザー型仮想化ではハイパーバイザーを介して記憶装置に対するデータの読み出し及び書き込みが行われ、ハイパーバイザーは、仮想マシンから送信された命令の物理的な記憶装置への書き込み命令への変換や物理的な記憶装置から読み出したデータを仮想マシンへ送信するための変換といった仮想化のための処理を行うため、ハイパーバイザー型仮想化では、記憶装置に対するデータの読み出し及び書き込み時に、仮想化のためのオーバヘッドが発生し、ＮＡＮＤ型フラッシュメモリの性能を生かし切れず、コンテナ型仮想化による環境とハイパーバイザー型仮想化による環境とを共存させる場合、記憶装置に対するデータの読み出し及び書き込みの性能を向上させることが困難であり（【０００９】）、また、レイテンシの長さに応じて動作を第１タイプと第２タイプとに分けて一方を優先的に処理する従来技術を用いても、コンテナ型仮想化による環境とハイパーバイザー型仮想化による環境のいずれからもそれぞれのタイプの動作は指示されるため、この従来技術を用いても、仮想化のオーバヘッドは発生するおそれがあり、記憶装置に対するデータの読み出し及び書き込みの性能を向上させることが困難であり（【００１０】）、また、プログラムの重要度に応じて記憶装置へ送信するデータの優先度を決定する従来技術を用いても、ハイパーバイザー型仮想化による環境のプログラムの重要度が高いことは考えられるため、この従来技術を用いても、記憶装置に対するデータの読み出し及び書き込みの性能を向上させることが困難であることを解決しようとする課題とし（【００１０】）、当該課題に対し、データの読み出し及び書き込みの性能を向上させる情報処理装置などを提供することを目的としてなされたものである。（【００１２】）

一方で引用発明は、単に「仮想マシンとＩ／Ｏ仮想化のないコンテナをハイブリッドしたアーキテクチャー」であって、「同一ホスト上の仮想マシンとコンテナから同一のＳＳＤに対して、同時に１から２冪で１２８多重でＲｅａｄ負荷をかけてＩ／Ｏを競合させた場合、仮想マシンとコンテナのどちらも３２多重以上の場合にＩ／Ｏの競合による単体時との性能差が生じる」ものではあるが、上記相違点に係る構成は有さず、また引用例２～４のいずれにも、当該構成は記載されておらず、この点が本願出願前周知であったということもできない。

したがって、本願発明１は、当業者であっても、引用発明及び引用例２～４に記載された技術的事項に基づいて容易に発明できたものとはいえない。

２ 本願発明６～８について

本願発明６～８は、概ね本願発明１とそのカテゴリーのみ異なるものであり、また、本願発明１の上記相違点に係る「判定部」と同一の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明及び引用例２～４に記載された技術的事項に基づいて容易に発明できたものとはいえない。

３ 本願発明２～５について

本願発明２～５は、本願発明１を直接又は間接的に引用するものであり、本願発明１の上記相違点に係る「判定部」と同一の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明及び引用例２～４に記載された技術的事項に基づいて容易に発明できたものとはいえない。

第７ 原査定について

＜特許法２９条２項について＞

本件補正により、本願発明１～８は、上記第４に示すとおりのものとなり、上記第６に示したとおり、当業者であっても、拒絶査定において引用された引用文献１～４（上記第５の引用例１～４）に基づいて、容易に発明できたものとはいえない。したがって、原査定の理由を維持することはできない。

第８ むすび

以上のとおり、原査定の理由によっては、本願を拒絶することはできない。

また、他に本願を拒絶すべき理由を発見しない。

よって、結論のとおり審決する。