【事件の表示】
　特願２０１６−５１４１４４「データベース作業負荷に対する入出力の優先順位付け」拒絶査定不服審判事件〔平成２６年１１月２０日国際公開、ＷＯ２０１４／１８６７５６、平成２８年　９月１５日国内公表、特表２０１６−５２８５７８、請求項の数（１３）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本件審判請求に係る出願（以下，「本願」という。）は，２０１４年５月１６日（パリ条約による優先権主張外国庁受理２０１３年５月１７日（以下，「優先日」という。），米国）を国際出願日として出願したものであって，その手続の経緯は以下のとおりである。
　　平成２７年１１月１７日　　　：国内書面の提出
　　平成２７年１２月１０日　　　：翻訳文の提出
　　平成２９年　１月２６日付け　：拒絶理由の通知
　　平成２９年　７月１１日　　　：意見書，手続補正書の提出
　　平成２９年１２月１９日付け　：拒絶査定（原査定）
　　平成３０年　５月　９日　　　：審判請求書，手続補正書の提出
　　平成３０年１０月２９日　　　：上申書の提出
　　平成３１年　１月３１日付け　：拒絶理由の通知（当審）
　　令和 元 年　５月３０日　　　：意見書，手続補正書の提出
第２　本願発明
　本願請求項１−１３に係る発明（以下，それぞれ「本願発明１」−「本願発明１３」という。）は，令和元年５月３０日付けの手続補正で補正された特許請求の範囲の請求項１−１３に記載された事項により特定される発明であり，本願発明１は以下のとおりの発明である。
「　　【請求項１】
　容量消費を管理するためのデータベース管理システム用のプログラムであって，
　前記プログラムは，コンピュータ可読命令が記憶されている１つ以上のメモリを有する１つ以上のコンピューティングノード上で動作し，
　前記コンピュータ可読命令は，前記１つ以上のコンピューティングノードによって実行される時に，前記データベース管理システムに，少なくとも，
　顧客のために遂行される動作を，前記データベース管理システム上で遂行させる要求であって，要求クラスを示す情報を含む要求を受信するステップと，
　関連付けられた第１の容量表示を有する第１のトークンバケットを，複数のトークンバケットを含む１つ以上のデータ構造から，前記要求クラスに少なくとも部分的に基づいて選択するステップと，
　前記第１の容量表示が，前記動作を遂行するための容量に十分であると示すことを決定するステップと，
　前記第１の容量表示が，前記容量に十分であると示す場合，前記動作を遂行するステップと，
　前記動作を遂行するステップにより利用された容量を，前記第１のトークンバケットから引き出し，前記第１の容量表示を更新するステップと，
　前記動作を遂行するステップにより利用された前記容量に少なくとも部分的に基づいて，前記複数のトークンバケットのうちの第２のトークンバケットから利用された前記容量を引き出し，前記第２のトークンバケットに関連付けられた第２の容量表示を更新するステップと，
を行わせ，
　前記第２のトークンバケットは，前記第１のトークンバケットとトークンを共有する親バケットである，
プログラム。」
　なお，本願発明２−１３の概要は以下のとおりである。
　本願発明２−３は，本願発明１を減縮した発明である。
　本願発明４は，本願発明１に対応する「容量消費を管理するための，コンピュータにより実行される方法」の発明であり，本願発明１とカテゴリ表現が異なるだけの発明である。
　本願発明５−９は，本願発明４を減縮した発明である。
　本願発明１０は，「容量消費を管理するためのシステム用のプログラム」の発明であり，本願発明１に対応する発明である。
　本願発明１１−１３は，本願発明１０を減縮した発明である。
第３　引用文献，引用発明等
１　引用文献１について
　原査定の拒絶の理由に引用された引用文献１（米国特許出願公開第２０１１／００１０４２７号明細書）には，図面とともに次の事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。）
Ａ　「[0044] A.2.1. 
Hierarchical QoS Management
[0045] 
The present invention manages QoS of I/O subsystems in virtual I/O servers by hierarchical decomposition. The hierarchy is based on partitioning of network interfaces and I/O subsystems transaction types, with QoS allocation decisions made on each hierarchy independently. That is, QoS is performed on I/O communications from application servers  102  in various hierarchical tiers in virtual I/O server  106 .
　当審仮訳；　「[0044] A.2.1. 
階層的QoS管理
[0045] 
本発明は，階層的な分析によって仮想I/OサーバにおけるI/Oサブシステムのサービス品質(QoS)を管理する。この階層はネットワークインタフェース及びI/Oサブシステムのトランザクションタイプの区分に基づくものであり，階層毎に独立になされるQoS割当ての決定を用いる。すなわち，QoSが，仮想I/Oサーバ106において様々な階層のアプリケーションサーバ102からのI/O通信について行われる。
Ｂ　「[0051] A.2.2 First Hierarchical QoS Manager
[0052] The first hierarchical ingress QoS process is provided in fabric receive QoS manager  414  along with fabric receive process  416  and fabric receive buffer  412 . 
…（中略）…
[0053] 
Hierarchical token bucket can be considered as a class-based scheduling mechanism. HTB includes hierarchical classes where three class types exist: root, non-leaf and leaf.
 Incoming traffic is first classified to identify a leaf class.
 Each class or node in the hierarchy has a bucket of tokens associated with it.
 Scheduling a message or packet for transmission results in deducting an amount of tokens from. a corresponding bucket, and is permitted when the corresponding bucket includes a sufficient number of tokens. In one implementation, each class has a guaranteed rate, a maximum rate, an actual or observed rate, and a priority level. High priority classes might borrow excess resource allocation (such as bandwidth) from low priority classes. For example, when the actual rate of a given class reaches its guaranteed rate, it may borrow tokens from its parent class. When a class reaches its maximum rate, packets may be queued until sufficient tokens are available. In certain implementations, the fabric receive QoS manager  414 , which implements the hierarchical token bucket mechanism, acts as a permissions layer.
　当審仮訳；　「[0051] A.2.2 第１階層QoSマネージャ
[0052] 第１階層の入力QoSプロセスは，ファブリック受信プロセス416とファブリック受信バッファ412に繋がるファブリック受信QoSマネージャ414に提供される。
…（中略）…
[0053] 
階層的トークンバケットは，クラスベースのスケジューリング機構と見なすことができる。HTBは，ルート，非リーフおよびリーフといった３つのクラスタイプが存在する階層的なクラスを含む。
入力トラフィックは，リーフクラスを識別するよう最初に分類される。
階層中の各クラスまたはノードは，それに関連付けられたトークンバケットを備えている。
送信用のメッセージまたはパケットをスケジューリングすることで，対応するバケットからトークンを減算することになり，送信用のメッセージまたはパケットは，対応するバケットが十分な数のトークンを有する場合に許可される。一実施形態では，各クラスは，保証レート，最高レート，実測のまたは観測されたレート，および優先度レベルを有している。優先度の高いクラスが優先度の低いクラスから，超過リソース割り当て量(帯域幅)を借りてもよい。例えば，所与のクラスの実測のレートがその保証レートに到達すると，その所与のクラスはその親クラスからトークンを借用してもよい。クラスがその最大レートに達すると，十分なトークンが利用可能になるまで，パケットを待ち行列に入れてもよい。いくつかの実装形態では，階層的トークン・バケット機構を実装するファブリック受信QoSマネージャ414は許可層として機能する。
Ｃ　「[0057] A.2.2.1 Fabric Receive QoS Management
[0058] FIG. 5  is a flow chart illustrating the operations of fabric receive QoS manager  414  along with fabric receive process  416  and fabric receive buffer  412 . 
In step  502 , fabric receive process  416  receives and aggregates virtual I/O communications from any of the I/O fabric interfaces  110 .
Fabric receive process  416  might use prioritization, weighted round-robin or lottery scheduler scheme to determine the service priority of any of the present I/O fabric interfaces. In step  504 , fabric receive QoS manager  414  classifies the received virtual I/O communication using a QoS mechanism such as hierarchical token bucket (HTB).
In step  510 , it is determined if the application sever  102  virtual device associated with the virtual I/O communication has sufficient tokens to be forwarded.
In step  514 , if there are sufficient tokens to proceed, the corresponding tokens are deducted in fabric receive QoS manager  414 .
　当審仮訳；　「[0057] A.2.2.1 ファブリック受信QoS管理
[0058] 図5は，ファブリック受信プロセス416，ファブリック受信バッファ412に繋がるファブリック受信QoSマネージャ414の動作を示すフローチャートである。
ステップ502では，ファブリック受信プロセス416は，I/Oファブリックインタフェース110のいずれかから仮想I/O通信を受信し，収集する。
ファブリック受信プロセス416は，優先順位付け，重み付けラウンドロビンまたは抽選スケジューラ方式を用いて，任意のこのI/Oファブリックインターフェースのサービス優先度を決定してもよい。ステップ504において，ファブリック受信QoSマネージャ414は，階層的トークンバケット(HTB)のようなQoS機構を使用して，受信した仮想I/O通信を区分する。
ステップ510では，仮想I/O通信に関連する仮想デバイスであるアプリケーションサーバ102が，転送されるのに十分なトークンを有しているかどうかが判断される。
ステップ514において，処理を進めるのに十分なトークンがある場合，ファブリック受信QoSマネージャ414において相応のトークンが減算される。
　したがって，上記引用文献１には次の発明（以下，「引用発明」という。）が記載されていると認められる。
「アプリケーションサーバからのI/O通信について，ネットワークインタフェース及びI/Oサブシステムのトランザクションタイプの区分に基づく階層的な分析によって，I/Oサブシステムのサービス品質(QoS)を管理する階層的QoS管理方法を仮想I/Oサーバが実行するためのプログラムであって，
　階層的トークンバケット(HTB)は，３つのクラスベースのスケジューリング機構とみなされ，入力トラフィックはリーフクラスを識別すべく分類され，階層の各クラスまたはノードは関連付けられたトークンバケットを有し，メッセージまたはパケットを送信のためにスケジューリングすると対応するバケットから所定量のトークンが減算され，対応する前記バケットが十分なトークンを含む場合には送信が許可され，各クラスは，保証レート，最高レート，実測レート及び優先度レベルを有し，優先度の高いクラスは優先度の低いクラスから超過リソース割り当てを借用してもよく，例えば，あるクラスの実測レートが保証レートに達した場合，前記クラスはその親クラスからトークンを借用してもよく，あるクラスが最高レートに到達した場合には，十分なトークンが利用可能になるまでパケットは待ち行列に入れられてもよく，実施例におけるファブリック受信QoSマネージャは，HTB機構を備え，許可層として機能すること，
　前記仮想I/Oサーバで実行されるファブリック受信プロセスは，I/Oファブリックインタフェースのいずれかから仮想I/O通信を受信し，優先順位付けを用いて前記I/Oファブリックインタフェースのサービス優先度を決定し，前記ファブリック受信QoSマネージャは，HTBを利用して前記仮想I/O通信を区分し，前記仮想I/O通信と関連する仮想デバイスである前記アプリケーションサーバが，処理を進めるのに十分なトークンを有していると判断した場合には，相応のトークンを減算すること，
を含むプログラム。」
２　引用文献２について
　原査定の拒絶の理由に引用された引用文献２（特表２００９−５０６５９８号公報）には，図面とともに次の事項が記載されている。
（当審注：下線は，参考のために当審で付与したものである。）
Ｄ　「【００４１】
　下記において，本発明のさらなる実施形態を図２に関して記述しよう。図２は，
通信ネットワーク内でのリソース予約の方法の動作を図解する図である。
【００４２】
　
第１の動作２０１において，新規データフローのためのリソース予約要求が検出されるが，リソース予約要求は，ネットワークノードで要求される通信リソースを指定する複数のリソース記述子を含む。
…（中略）…
【００４６】
　
要求されたリソースを指定する記述子は，根底にあるアプリケーションの要件を満たすための最小限の必要リソースを指定することが好ましい。例えば，記述子は，必要な帯域幅や，中程度に必要な帯域幅や，ピークレートや，平均レートや，最大許容送信遅延などを指定してもよい。さらに，記述子は，リーキーバケットやトークンバケットを指定してもよい。
　したがって，上記引用文献２には，「処理要求を受信した手段が，処理要求の一部に含まれる情報（記述子）に基づいて必要リソースを識別し，トークンバケットを指定する」という技術的事項が記載されていると認められる。
３　引用文献３について
　原査定の拒絶の理由に引用された引用文献３（米国特許出願公開第２００２／０１０１８２０号明細書）の段落［０１６５］−［０１６７］，［０２３４］，［０２６７］−［０２６８］，図１９−２０，３０の記載からみて，当該引用文献３には，「パケットを受信した手段が，パケットの一部に含まれるヘッダ情報に基づいてQoSクラスを識別し，当該クラスに応じたトークンバケットを割り当てる」という技術的事項が記載されているものと認められる。
第４　対比・判断
１　本願発明１について
（１）対比
　本願発明１と引用発明とを対比すると，次のことがいえる。
ア　引用発明は，「アプリケーションサーバからのI/O通信について，ネットワークインタフェース及びI/Oサブシステムのトランザクションタイプの区分に基づく階層的な分析によって，I/Oサブシステムのサービス品質(QoS)を管理する階層的QoS管理方法を仮想I/Oサーバが実行するためのプログラム」であるところ，「仮想I/Oサーバ」は，「アプリケーションサーバからのI/O通信」に対する「I/Oサブシステムのサービス品質(QoS)を管理」するものであり，「階層的トークンバケット(HTB)」のモデルにしたがって，「アプリケーションサーバからのI/O通信」に対する「リソース割り当て」を，対応する「バケット」からの「トークン」の量の減算によって行うと解される。
　そうすると，引用発明の「仮想I/Oサーバ」上では，「アプリケーションサーバからのI/O通信」に対するリソースの“容量消費”を管理する“管理システム”が動作しているとみることができるから，引用発明は，“容量消費を管理するための管理システム用のプログラム”であるといえる。
　また，本願発明１は，「容量消費を管理するためのデータベース管理システム用のプログラム」であり，「データベース管理システム」は，上位概念では，システムリソースの容量消費を管理する“管理システム”であるといえる。
　したがって，引用発明と本願発明１とは，後記する点で相違するものの，“容量消費を管理するための管理システム用のプログラム”である点で共通するといえる。
イ　引用発明は，「I/Oサブシステムのサービス品質(QoS)を管理する階層的QoS管理方法を仮想I/Oサーバが実行するためのプログラム」であり，「仮想I/Oサーバ」上で「プログラム」が動作し，「仮想I/Oサーバ」は“コンピュータ可読命令が記憶されている１つ以上のメモリを有する”ことは明らかであるから，引用発明の「仮想I/Oサーバ」は本願発明１の「コンピューティングノード」に相当するといえる。
　また，上記アでの検討より，引用発明の「仮想I/Oサーバ」上では，「アプリケーションサーバからのI/O通信」に対するリソースの“容量消費”を管理する“管理システム”が動作しているとみることができ，「仮想I/Oサーバ」の有するメモリが記憶する“コンピュータ可読命令”は“管理システムに所定のステップを行わせる”ことは明らかであるから，引用発明では，“コンピュータ可読命令は，前記１つ以上のコンピューティングノードによって実行される時に，前記管理システムに所定のステップを行わせる”といえる。
　そうすると，上記アでの検討より，本願発明１の「データベース管理システム」は，上位概念では，システムリソースの容量消費を管理する“管理システム”であるといえるから，引用発明と本願発明１とは，後記する点で相違するものの，
“前記プログラムは，コンピュータ可読命令が記憶されている１つ以上のメモリを有する１つ以上のコンピューティングノード上で動作し，
　前記コンピュータ可読命令は，前記１つ以上のコンピューティングノードによって実行される時に，前記管理システムに所定のステップを行わせる”点で共通するといえる。
ウ　引用発明は，「仮想I/Oサーバ」において「入力トラフィックはリーフクラスを識別すべく分類され」るとともに，「前記仮想I/Oサーバで実行されるファブリック受信プロセスは，I/Oファブリックインタフェースのいずれかから仮想I/O通信を受信」するところ，引用発明の「仮想I/O通信」は「クラス」が識別可能な入力トラフィックであり，上記アでの検討より，引用発明の「仮想I/O通信」は“管理システム上で容量消費が管理される”ことから，“管理システム上で容量消費が管理される”「仮想I/O通信」であって，「クラス」を識別可能な「仮想I/O通信」を受信するといえる。
　一方，本願発明１は，「顧客のために遂行される動作を，前記データベース管理システム上で遂行させる要求であって，要求クラスを示す情報を含む要求を受信するステップ」を有するところ，上記アでの検討より，「データベース管理システム」で遂行される「要求」は“管理システム上で容量消費が管理される”ものであり，「要求クラス」を示す情報を含む「要求」は，上位概念である“クラス”を識別可能な「要求」と解されることから，本願発明１の「要求」は，“管理システム上で容量消費が管理される”ものであって，“クラスを識別可能”な「要求」を受信するといえる。
　そうすると，引用発明の「仮想I/O通信」は本願発明１の「要求」に対応するといえ，引用発明と本願発明１とは，後記する点で相違するものの，“管理システム上で容量消費が管理される要求であって，クラスを識別可能な要求を受信するステップ”を行わせる点で共通するといえる。
エ　引用発明は，「仮想I/Oサーバ」において「階層の各クラスまたはノードは関連付けられたトークンバケットを有し，メッセージまたはパケットを送信のためにスケジューリングすると対応するバケットから所定量のトークンが減算され」るところ，「トークンバケット」を「クラス」に少なくとも基づいて決定すること，「トークンバケット」が減算される前に“第１の容量”を有することは明らかであり，引用発明の「トークンバケット」は本願発明１の「第１のトークンバケット」に相当するから，引用発明では，“関連付けられた第１の容量を有する第１のトークンバケットを，クラスに少なくとも部分的に基づいて決定する”といえる。
　それに対して，本願発明１は，「関連付けられた第１の容量表示を有する第１のトークンバケットを，複数のトークンバケットを含む１つ以上のデータ構造から，前記要求クラスに少なくとも部分的に基づいて選択するステップ」を有するところ，「要求」に含まれる「要求クラス」は上位概念では“クラス”とみることができるから，本願発明１では，“関連付けられた第１の容量を有する第１のトークンバケットを，クラスに少なくとも部分的に基づいて決定する”といえる。
　そうすると，引用発明と本願発明１とは，後記する点で相違するものの，“関連付けられた第１の容量を有する第１のトークンバケットを，前記クラスに少なくとも部分的に基づいて決定するステップ”を行わせる点で共通するといえる。
オ　引用発明は，「仮想I/Oサーバ」において「メッセージまたはパケットを送信のためにスケジューリングすると対応するバケットから所定量のトークンが減算され，対応する前記バケットが十分なトークンを含む場合には送信が許可され」るとともに，「仮想I/O通信と関連する仮想デバイスである前記アプリケーションサーバが，処理を進めるのに十分なトークンを有していると判断した場合には，相応のトークンを減算する」ところ，上記エでの検討より，「トークンバケット」が減算される前に“第１の容量”を有することは明らかであるから，「トークンバケット」の“第１の容量”が「仮想I/O通信」の処理を進めるのに十分であるかどうかを判断し，十分と判断された場合には，“利用された容量を，第１のトークンバケットから引き出し，第１の容量を更新する”と解することができる。
　そうすると，上記ウでの検討より，引用発明の「仮想I/O通信」は本願発明１の「要求」に対応することから，引用発明は“第１の容量が，要求を処理するための容量に十分であると示すことを決定する”とともに，“前記第１の容量が，前記容量に十分であると示す場合，前記要求を処理する”，さらに，“前記要求を処理するステップにより利用された容量を，前記第１のトークンバケットから引き出し，前記第１の容量を更新する”といえる。
　一方，本願発明１は，「前記第１の容量表示が，前記動作を遂行するための容量に十分であると示すことを決定するステップと，前記第１の容量表示が，前記容量に十分であると示す場合，前記動作を遂行するステップと，前記動作を遂行するステップにより利用された容量を，前記第１のトークンバケットから引き出し，前記第１の容量表示を更新するステップと，」を有するところ，上記ウでの検討より，「要求」は「顧客のために遂行される動作を，前記データベース管理システム上で遂行させる」ものであり，「要求」により動作が遂行されることから，「動作を遂行するため」とは“要求を処理するため”と同義であるといえる。
　したがって，引用発明と本願発明１とは，後記する点で相違するものの，
　“前記第１の容量が，前記要求を処理するための容量に十分であると示すことを決定するステップと，
　前記第１の容量が，前記容量に十分であると示す場合，前記要求を処理するステップと，
　前記要求を処理するステップにより利用された容量を，前記第１のトークンバケットから引き出し，前記第１の容量を更新するステップと，”
を行わせる点で共通するといえる。
カ　引用発明は，「仮想I/Oサーバ」において「対応する前記バケットが十分なトークンを含む場合には送信が許可され，各クラスは，保証レート，最高レート，実測レート及び優先度レベルを有し，優先度の高いクラスは優先度の低いクラスから超過リソース割り当てを借用してもよく，例えば，あるクラスの実測レートが保証レートに達した場合，前記クラスはその親クラスからトークンを借用してもよ」いものであるところ，上記ウでの検討より，引用発明の「仮想I/O通信」は本願発明１の「要求」に対応し，上記オでの検討より，引用発明は“前記要求を処理するステップにより利用された容量を，前記第１のトークンバケットから引き出し，前記第１の容量を更新する”ことから，“前記要求を処理するステップにより利用された容量”のうち，“第１のトークンバケット”の有する“第１の容量”からの「超過リソース」分を“親”の関係にある「トークンバケット」から「借用する」といえる。そして，引用発明の“親”の関係にある「トークンバケット」は本願発明１の「第２のトークンバケット」に対応し，引用発明において，“利用された容量”のうち，「超過リソース」分を「借用する」ことは，“利用された容量に少なくとも部分的に基づいて，所定の容量を引き出す”ことといえるから，引用発明では，“要求を処理するステップにより利用された容量に少なくとも部分的に基づいて，第１のトークンバケットの親の第２のトークンバケットから所定の容量を引き出す”といえる。
　それに対し，本願発明１は，「前記動作を遂行するステップにより利用された前記容量に少なくとも部分的に基づいて，前記複数のトークンバケットのうちの第２のトークンバケットから利用された前記容量を引き出し，前記第２のトークンバケットに関連付けられた第２の容量表示を更新するステップ」を行わせ，「前記第２のトークンバケットは，前記第１のトークンバケットとトークンを共有する親バケットである」ところ，「第２のトークンバケット」は，「第１のトークンバケット」の“親”であると解され，「利用された前記容量に少なくとも部分的に基づいて」，「第１のトークンバケット」の“親”の「第２のトークンバケット」から“所定の容量”を引き出すといえる。
　そうすると，引用発明と本願発明１とは，後記する点で相違するものの，
　“前記要求を処理するステップにより利用された前記容量に少なくとも部分的に基づいて，前記第１のトークンバケットの親の第２のトークンバケットから所定の容量を引き出すステップ”
を行わせる点で共通するといえる。
　したがって，本願発明１と引用発明との間には，次の一致点，相違点があるといえる。
（一致点）
「容量消費を管理するための管理システム用のプログラムであって，
　前記プログラムは，コンピュータ可読命令が記憶されている１つ以上のメモリを有する１つ以上のコンピューティングノード上で動作し，
　前記コンピュータ可読命令は，前記１つ以上のコンピューティングノードによって実行される時に，前記管理システムに，少なくとも，
　前記管理システム上で容量消費が管理される要求であって，クラスを識別可能な要求を受信するステップと，
　関連付けられた第１の容量を有する第１のトークンバケットを，前記クラスに少なくとも部分的に基づいて決定するステップと，
　前記第１の容量が，前記要求を処理するための容量に十分であると示すことを決定するステップと，
　前記第１の容量が，前記容量に十分であると示す場合，前記要求を処理するステップと，
　前記要求を処理するステップにより利用された容量を，前記第１のトークンバケットから引き出し，前記第１の容量を更新するステップと，
　前記要求を処理するステップにより利用された前記容量に少なくとも部分的に基づいて，前記第１のトークンバケットの親の第２のトークンバケットから所定の容量を引き出すステップと，
を行わせるプログラム。」
（相違点）
（相違点１）
　本願発明１は，「容量消費を管理するためのデータベース管理システム用のプログラム」であるのに対して，
　引用発明は，容量消費を管理するための管理システム用のプログラムであるものの，「データベース管理システム」であることは特定されていない点。
（相違点２）
　コンピュータ可読命令に関し，本願発明１は，「コンピューティングノード」のメモリに記憶されている「コンピュータ可読命令」は，「データベース管理システム」に所定のステップを行わせるのに対して，
　引用発明では，「仮想I/Oサーバ」に記憶されているコンピュータ可読命令は，「データベース管理システム」に所定のステップを行わせることは特定されていない点。
（相違点３）
　要求を受信するステップに関し，本願発明１は，「顧客のために遂行される動作を，前記データベース管理システム上で遂行させる要求であって，要求クラスを示す情報を含む要求を受信する」のに対して，
　引用発明は，クラスを識別可能な仮想I/O通信を受信するものの，そのような要求は特定されていない点。
（相違点４）
　第１のトークンバケットを決定するステップに関し，本願発明１は，「関連付けられた第１の容量表示を有する第１のトークンバケットを，複数のトークンバケットを含む１つ以上のデータ構造から，前記要求クラスに少なくとも部分的に基づいて選択する」のに対して，
　引用発明は，トークンバケットを，クラスに少なくとも基づいて決定するものの，そのように選択されることは特定されていない点。
（相違点５）
　要求の処理に係る第１の容量の更新に関し，本願発明１は，「前記第１の容量表示が，前記動作を遂行するための容量に十分であると示すことを決定」し，「前記容量に十分であると示す場合，前記動作を遂行」し，「利用された容量を，前記第１のトークンバケットから引き出し，前記第１の容量表示を更新する」のに対して，
　引用発明は，要求（仮想I/O通信）の「処理を進めるのに十分なトークンを有していると判断した場合には，相応のトークンを減算する」ものの，「動作を遂行するための容量」を引き出し，「容量表示」を更新することは特定されていない点。
（相違点６）
　第２のトークンバケットに関し，本願発明１は，「前記動作を遂行するステップにより利用された前記容量に少なくとも部分的に基づいて，前記複数のトークンバケットのうちの第２のトークンバケットから利用された前記容量を引き出し，前記第２のトークンバケットに関連付けられた第２の容量表示を更新するステップ」を行わせ，「前記第２のトークンバケットは，前記第１のトークンバケットとトークンを共有する親バケットである」のに対して，
　引用発明では，利用された容量のうち，第１のトークンバケットの有する第１の容量からの超過リソース分を親の関係にある第２のトークンバケットから借用するものの，第２のトークンバケットは，第１のトークンバケットとトークンを共有する親バケットであること，第２のトークンバケットから第１のトークンバケットで利用された容量を引き出し，前記第２のトークンバケットに関連付けられた第２の容量表示を更新することは特定されていない点。
（２）相違点についての判断
ア　相違点６について
　事案に鑑みて，上記相違点６を先に検討すると，引用発明は，「仮想I/Oサーバ」において「対応する前記バケットが十分なトークンを含む場合には送信が許可され」，「優先度の高いクラスは優先度の低いクラスから超過リソース割り当てを借用してもよく，例えば，あるクラスの実測レートが保証レートに達した場合，前記クラスはその親クラスからトークンを借用してもよ」いと特定され，要求を処理するステップにより利用された容量のうち，第１のトークンバケットの有する第１の容量からの超過リソース分を親の関係にある第２のトークンバケットから借用することができると解されるものの，第１のトークンバケットとトークンを共有する親バケットであること，加えて，第１のトークンバケットの第１の容量表示が，動作を遂行するための容量に十分であると示すことを決定した場合に，利用された容量を，第１のトークンバケットから引き出し，第１の容量表示を更新した上で，第２のトークンバケットからも第１のトークンバケットで利用された容量を引き出し，前記第２のトークンバケットに関連付けられた第２の容量表示も更新することは特定されておらず，そのように設計変更することの動機付けもない。
　そして，階層型トークンバケットを用いた容量消費を管理するためのシステムにおいて，第１のトークンバケットとトークンを共有する親バケットである第２のトークンバケットを設定し，第１のトークンバケットの第１の容量表示が，動作を遂行するための容量に十分であると示すことを決定した場合に，第２のトークンバケットから第１のトークンバケットで利用された容量を引き出し，前記第２のトークンバケットに関連付けられた第２の容量表示を更新する旨の技術は，上記引用文献２，３には記載されておらず，本願の優先日前に当該技術分野において周知技術であったとまではいえず，当業者が適宜に選択し得た設計的事項であるとすることもできない。
　そうすると，引用発明において，第１のトークンバケットとトークンを共有する親バケットである第２のトークンバケットを設定し，動作を遂行するステップにより利用された容量に少なくとも部分的に基づいて，複数のトークンバケットのうちの第２のトークンバケットから利用された前記容量を引き出し，前記第２のトークンバケットに関連付けられた第２の容量表示を更新すること，すなわち，本願発明１の上記相違点６に係る構成とすることは，当業者が適宜なし得たものであるとすることはできない。
イ　まとめ
　したがって，他の相違点について判断するまでもなく，本願発明１は，当業者であっても，引用発明，引用文献２，３に記載された技術的事項に基づいて容易に発明できたものとはいえない。
２　本願発明２−３について
　本願発明２−３は本願発明１を減縮した発明であり，本願発明１の
「前記動作を遂行するステップにより利用された前記容量に少なくとも部分的に基づいて，前記複数のトークンバケットのうちの第２のトークンバケットから利用された前記容量を引き出し，前記第２のトークンバケットに関連付けられた第２の容量表示を更新するステップ」を行わせ，「前記第２のトークンバケットは，前記第１のトークンバケットとトークンを共有する親バケットである」（以下，「相違点６に係る構成」という。）
と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献２，３に記載された技術的事項に基づいて容易に発明できたものとはいえない。
３　本願発明４−９について
　本願発明４は本願発明１とカテゴリ表現が異なるだけの「容量消費を管理するための，コンピュータにより実行される方法」の発明であり，本願発明５−９は本願発明４を減縮した発明であり，本願発明１の「相違点６に係る構成」と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献２，３に記載された技術的事項に基づいて容易に発明できたものとはいえない。
４　本願発明１０−１３について
　本願発明１０は本願発明１に対応する「容量消費を管理するためのシステム用のプログラム」の発明であり，本願発明１１−１３は本願発明１０を減縮した発明であり，本願発明１の「相違点６に係る構成」と同一の構成を備えるものであるから，本願発明１と同じ理由により，当業者であっても，引用発明，引用文献２，３に記載された技術的事項に基づいて容易に発明できたものとはいえない。
第５　原査定の概要及び原査定についての判断
　原査定は，
●理由１（特許法第３６条第６項第２号）について
　 請求項１−４，１２−１５のそれぞれに係る発明は明確でないから，特許法第３６条第６項第２号の規定により特許を受けることができない。
●理由３（特許法第２９条第２項）について
　請求項１−１５について上記引用文献１−３に記載された発明及び周知技術に基づいて，当業者が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
というものである。
　しかしながら，令和元年５月３０日付け手続補正により補正された請求項１−３，１０−１３は，それぞれ「プログラム」の発明として特定されており，明確である。
　また，令和元年５月３０日付け手続補正により補正された請求項１−１３は，それぞれ「相違点６に係る構成」に対応する構成を有するものとなっており，
　上記のとおり，本願発明１−１３は，引用発明，引用文献２，３に記載された技術的事項に基づいて，当業者が容易に発明できたものではない。
　したがって，原査定を維持することはできない。
第６　当審拒絶理由について
１　特許法第３６条第６項第１号について
（１）当審では，請求項１−１３の課題解決手段としての「第２のトークンバケット」について，「第１のトークンバケット」との関係を「前記第１のトークンバケットの親バケットである，」と特定するにとどまり，「第１のトークンバケットとトークンを共有する」ことなどの発明の課題を解決するための手段が反映されていないため，発明の詳細な説明に記載した範囲を超えて特許を請求することになっているから，発明の詳細な説明に記載したものではないとの拒絶の理由を通知しているが，令和元年５月３０日付けの手続補正により，
「前記第２のトークンバケットは，前記第１のトークンバケットとトークンを共有する親バケットである」
と補正された結果，この拒絶の理由は解消した。
２　特許法第３６条第６項第２号について
（１）当審では，請求項１−１３の「前記第１の容量表示が，前記動作を遂行するための容量に十分であることを決定するステップと，前記第１の容量表示が十分の場合，前記動作を遂行するステップと，」が特定する事項が不明確であるとの拒絶の理由を通知しているが，令和元年５月３０日付けの手続補正により，
「前記第１の容量表示が，前記動作を遂行するための容量に十分であると示すことを決定するステップと，前記第１の容量表示が，前記容量に十分であると示す場合，前記動作を遂行するステップと，」
と補正された結果，この拒絶の理由は解消した。
（２）当審では，請求項１−１３の「前記動作を遂行するステップにより利用された容量を，前記第１のトークンバケットから引き出すステップと，前記動作を遂行するステップにより利用された前記容量に少なくとも部分的に基づいて，前記複数のトークンバケットのうちの第２のトークンバケットに関連付けられた第２の容量表示を更新するステップと，を行わせ，」が特定する事項が不明確であるとの拒絶の理由を通知しているが，令和元年５月３０日付けの手続補正により，
「前記動作を遂行するステップにより利用された前記容量に少なくとも部分的に基づいて，前記複数のトークンバケットのうちの第２のトークンバケットから利用された前記容量を引き出し，前記第２のトークンバケットに関連付けられた第２の容量表示を更新するステップと，を行わせ，」
と補正された結果，この拒絶の理由は解消した。
（３）当審では，請求項１−１３の「前記第２のトークンバケットは，前記第１のトークンバケットの親バケットである，」が特定する事項が不明確であるとの拒絶の理由を通知しているが，令和元年５月３０日付けの手続補正により，
「前記第２のトークンバケットは，前記第１のトークンバケットとトークンを共有する親バケットである，」
と補正された結果，この拒絶の理由は解消した。
第７　むすび
　以上のとおり，本願発明１−１３は，当業者が引用発明，引用文献２，３に記載された技術的事項に基づいて容易に発明をすることができたものではない。
　したがって，原査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　よって，結論のとおり審決する。