• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F
審判 査定不服 2項進歩性 取り消して特許、登録 G06F
管理番号 1353520
審判番号 不服2018-6341  
総通号数 237 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-09-27 
種別 拒絶査定不服の審決 
審判請求日 2018-05-09 
確定日 2019-08-05 
事件の表示 特願2016-514144「データベース作業負荷に対する入出力の優先順位付け」拒絶査定不服審判事件〔平成26年11月20日国際公開、WO2014/186756、平成28年 9月15日国内公表、特表2016-528578、請求項の数(13)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本件審判請求に係る出願(以下,「本願」という。)は,2014年5月16日(パリ条約による優先権主張外国庁受理2013年5月17日(以下,「優先日」という。),米国)を国際出願日として出願したものであって,その手続の経緯は以下のとおりである。

平成27年11月17日 :国内書面の提出
平成27年12月10日 :翻訳文の提出
平成29年 1月26日付け :拒絶理由の通知
平成29年 7月11日 :意見書,手続補正書の提出
平成29年12月19日付け :拒絶査定(原査定)
平成30年 5月 9日 :審判請求書,手続補正書の提出
平成30年10月29日 :上申書の提出
平成31年 1月31日付け :拒絶理由の通知(当審)
令和 元 年 5月30日 :意見書,手続補正書の提出

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

「 【請求項1】
容量消費を管理するためのデータベース管理システム用のプログラムであって,
前記プログラムは,コンピュータ可読命令が記憶されている1つ以上のメモリを有する1つ以上のコンピューティングノード上で動作し,
前記コンピュータ可読命令は,前記1つ以上のコンピューティングノードによって実行される時に,前記データベース管理システムに,少なくとも,
顧客のために遂行される動作を,前記データベース管理システム上で遂行させる要求であって,要求クラスを示す情報を含む要求を受信するステップと,
関連付けられた第1の容量表示を有する第1のトークンバケットを,複数のトークンバケットを含む1つ以上のデータ構造から,前記要求クラスに少なくとも部分的に基づいて選択するステップと,
前記第1の容量表示が,前記動作を遂行するための容量に十分であると示すことを決定するステップと,
前記第1の容量表示が,前記容量に十分であると示す場合,前記動作を遂行するステップと,
前記動作を遂行するステップにより利用された容量を,前記第1のトークンバケットから引き出し,前記第1の容量表示を更新するステップと,
前記動作を遂行するステップにより利用された前記容量に少なくとも部分的に基づいて,前記複数のトークンバケットのうちの第2のトークンバケットから利用された前記容量を引き出し,前記第2のトークンバケットに関連付けられた第2の容量表示を更新するステップと,
を行わせ,
前記第2のトークンバケットは,前記第1のトークンバケットとトークンを共有する親バケットである,
プログラム。」

なお,本願発明2-13の概要は以下のとおりである。

本願発明2-3は,本願発明1を減縮した発明である。

本願発明4は,本願発明1に対応する「容量消費を管理するための,コンピュータにより実行される方法」の発明であり,本願発明1とカテゴリ表現が異なるだけの発明である。

本願発明5-9は,本願発明4を減縮した発明である。

本願発明10は,「容量消費を管理するためのシステム用のプログラム」の発明であり,本願発明1に対応する発明である。

本願発明11-13は,本願発明10を減縮した発明である。

第3 引用文献,引用発明等
1 引用文献1について
原査定の拒絶の理由に引用された引用文献1(米国特許出願公開第2011/0010427号明細書)には,図面とともに次の事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

A 「[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 . The hierarchical tiers are partitioned according to network interface and I/O subsystems transaction types. QoS process at each hierarchical tier operates independently with its own QoS scheme and buffer to best optimized network performance in its perspective hierarchy. This hierarchical technique divides the QoS process into sub-processes, providing the flexibility to scale and fine tune the granularity of QoS as necessary without affecting other sub-processes. The number of hierarchies in this multi-tier QoS management process can vary in virtual I/O server 106 . In one implementation, a two-tier QoS management process is illustrated in FIG. 4 . The advantages of the present hierarchical QoS management process will become more evident in the following description.」
当審仮訳; 「[0044] A.2.1. 階層的QoS管理
[0045] 本発明は,階層的な分析によって仮想I/OサーバにおけるI/Oサブシステムのサービス品質(QoS)を管理する。この階層はネットワークインタフェース及びI/Oサブシステムのトランザクションタイプの区分に基づくものであり,階層毎に独立になされるQoS割当ての決定を用いる。すなわち,QoSが,仮想I/Oサーバ106において様々な階層のアプリケーションサーバ102からのI/O通信について行われる。階層は,ネットワークインタフェース及びI/Oサブシステムのトランザクションタイプにしたがって区分される。各階層でのQoSプロセスは,視点階層内の最適化されたネットワーク性能のための独自のQoS方式およびバッファを用いて,独立して動作する。この階層的な手法は,QoSプロセスをサブプロセスに分割し,他のサブプロセスに影響を及ぼすことなく,必要に応じて,規模の柔軟性とQoSの最適な粒度を提供する。多階層QoS管理プロセスの階層数は,仮想I/Oサーバ106内で変更することができる。一実施形態では,2層QoS管理プロセスが図4に示される。この階層QoS管理プロセスの利点は,以下の説明によってより明白となる。」

B 「[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. Root classes are at the top of the hierarchy, and all traffic essentially goes through them. Non-leaf classes have parent and child classes, while leaf classes have only parent classes. Incoming traffic is first classified to identify a leaf class. HTB uses the concept of tokens and buckets to schedule and shape traffic. Each class or node in the hierarchy has a bucket of tokens associated with it. HTB mechanisms allocate so-called tokens for the buckets at regular intervals. 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. That is, receipt of packets or frames at I/O fabric interface I/O generates interrupts that cause the fabric receive process 416 to be called. When fabric receive process 416 selects a packet, it accesses fabric receive QoS manager 414 for permission to send the packet. Fabric receive manager 414 can determine based on the state of one or more token bucket data structures and the size of the packet whether the packet can be forwarded, or whether the packet should be queued. In one implementation, if the packet is to be queued, the corresponding pointer remains on the I/O fabric interface receive buffer 404 . If the I/O fabric receive buffer 404 becomes full, this may signal the application server 102 to stop transmitting data. In some implementations, the packets may be enqueued in a different buffer space, such as fabric receive buffer 412 .」
当審仮訳; 「[0051] A.2.2 第1階層QoSマネージャ
[0052] 第1階層の入力QoSプロセスは,ファブリック受信プロセス416とファブリック受信バッファ412に繋がるファブリック受信QoSマネージャ414に提供される。
…(中略)…
[0053] 階層的トークンバケットは,クラスベースのスケジューリング機構と見なすことができる。HTBは,ルート,非リーフおよびリーフといった3つのクラスタイプが存在する階層的なクラスを含む。ルートクラスは,階層の最上部に位置するものであり,全てのトラフィックは基本的にそれらを通過する。非リーフ・クラスは,親クラス及び子クラスを有するが,リーフ・クラスは,親クラスのみを有している。入力トラフィックは,リーフクラスを識別するよう最初に分類される。HTBは,トラフィックをスケジュールし,整理するためにトークン・バケットの概念を使用する。階層中の各クラスまたはノードは,それに関連付けられたトークンバケットを備えている。HTB機構は,規則的な間隔でいわゆるバケットのためのトークンを割り当てる。送信用のメッセージまたはパケットをスケジューリングすることで,対応するバケットからトークンを減算することになり,送信用のメッセージまたはパケットは,対応するバケットが十分な数のトークンを有する場合に許可される。一実施形態では,各クラスは,保証レート,最高レート,実測のまたは観測されたレート,および優先度レベルを有している。優先度の高いクラスが優先度の低いクラスから,超過リソース割り当て量(帯域幅)を借りてもよい。例えば,所与のクラスの実測のレートがその保証レートに到達すると,その所与のクラスはその親クラスからトークンを借用してもよい。クラスがその最大レートに達すると,十分なトークンが利用可能になるまで,パケットを待ち行列に入れてもよい。いくつかの実装形態では,階層的トークン・バケット機構を実装するファブリック受信QoSマネージャ414は許可層として機能する。すなわち,I/Oファブリックインターフェースでパケットまたはフレームを受信すると,I/Oはファブリック受信プロセス416が呼び出される原因となる割り込みを生成する。ファブリック受信プロセス416がパケットを選択した場合には,パケットを送信する許可のためにファブリック受信QoSマネージャ414にアクセスする。ファブリック受信QoSマネージャ414は,パケットが転送できるかどうか,またはパケットが待ち行列に入れられるべきかどうか,1つまたは複数のトークン・バケット・データ構造の状態およびパケットのサイズに基づいて決定することができる。一実施形態では,パケットが待ち行列に入れられるべきであれば,対応するポインタは,I/Oファブリックインターフェース受信バッファ404上に残る。I/Oファブリックインターフェース受信バッファ404が満杯になった場合,これにより,データ送信を停止するためにアプリケーションサーバ102に信号を送信してもよい。いくつかの実施形態では,パケットはファブリック受信バッファ412のような,異なるバッファにエンキューされてもよい。」

C 「[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 . These virtual I/O communications may have been stored in I/O fabric interface: receive buffer 404 if fabric receive process 416 cannot immediately service them. 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). FIG. 12 illustrates one hierarchical configuration against which I/O communications can be classified. 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 512 , if there are insufficient tokens, the virtual I/O communication is stored in fabric receive buffer 412 and the corresponding timer is set. At the expiration of such time, fabric receive QoS manager 414 re-evaluates the status of the stored virtual I/O communication. 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通信は,I/Oファブリックインタフェース:受信バッファ404に格納されてもよい。ファブリック受信プロセス416は,優先順位付け,重み付けラウンドロビンまたは抽選スケジューラ方式を用いて,任意のこのI/Oファブリックインターフェースのサービス優先度を決定してもよい。ステップ504において,ファブリック受信QoSマネージャ414は,階層的トークンバケット(HTB)のようなQoS機構を使用して,受信した仮想I/O通信を区分する。図12は,I/O通信を区分することができる1つの階層構成を示す図である。ステップ510では,仮想I/O通信に関連する仮想デバイスであるアプリケーションサーバ102が,転送されるのに十分なトークンを有しているかどうかが判断される。ステップ512では,トークンが不十分な場合,仮想I/O通信はファブリック受信バッファ412に格納され,相応のタイマが設定される。この時間の終了時に,ファブリック受信QoSマネージャ414は,格納された仮想I/O通信の状態を再評価する。ステップ514において,処理を進めるのに十分なトークンがある場合,ファブリック受信QoSマネージャ414において相応のトークンが減算される。 …(後略)… 」

したがって,上記引用文献1には次の発明(以下,「引用発明」という。)が記載されていると認められる。
「アプリケーションサーバからのI/O通信について,ネットワークインタフェース及びI/Oサブシステムのトランザクションタイプの区分に基づく階層的な分析によって,I/Oサブシステムのサービス品質(QoS)を管理する階層的QoS管理方法を仮想I/Oサーバが実行するためのプログラムであって,
階層的トークンバケット(HTB)は,3つのクラスベースのスケジューリング機構とみなされ,入力トラフィックはリーフクラスを識別すべく分類され,階層の各クラスまたはノードは関連付けられたトークンバケットを有し,メッセージまたはパケットを送信のためにスケジューリングすると対応するバケットから所定量のトークンが減算され,対応する前記バケットが十分なトークンを含む場合には送信が許可され,各クラスは,保証レート,最高レート,実測レート及び優先度レベルを有し,優先度の高いクラスは優先度の低いクラスから超過リソース割り当てを借用してもよく,例えば,あるクラスの実測レートが保証レートに達した場合,前記クラスはその親クラスからトークンを借用してもよく,あるクラスが最高レートに到達した場合には,十分なトークンが利用可能になるまでパケットは待ち行列に入れられてもよく,実施例におけるファブリック受信QoSマネージャは,HTB機構を備え,許可層として機能すること,
前記仮想I/Oサーバで実行されるファブリック受信プロセスは,I/Oファブリックインタフェースのいずれかから仮想I/O通信を受信し,優先順位付けを用いて前記I/Oファブリックインタフェースのサービス優先度を決定し,前記ファブリック受信QoSマネージャは,HTBを利用して前記仮想I/O通信を区分し,前記仮想I/O通信と関連する仮想デバイスである前記アプリケーションサーバが,処理を進めるのに十分なトークンを有していると判断した場合には,相応のトークンを減算すること,
を含むプログラム。」

2 引用文献2について
原査定の拒絶の理由に引用された引用文献2(特表2009-506598号公報)には,図面とともに次の事項が記載されている。
(当審注:下線は,参考のために当審で付与したものである。)

D 「【0041】
下記において,本発明のさらなる実施形態を図2に関して記述しよう。図2は,通信ネットワーク内でのリソース予約の方法の動作を図解する図である。
【0042】
第1の動作201において,新規データフローのためのリソース予約要求が検出されるが,リソース予約要求は,ネットワークノードで要求される通信リソースを指定する複数のリソース記述子を含む。一例において,要求は,2つの通信エンティティ間のパスに沿った各ネットワークノードで受信される。リソース予約要求は,通信ネットワーク内でのメッセージ交換用の通信プロトコルに従って送信されてもよく,そして,例えば,通信の発信元から通信の着信先までの所望のまたは適切な通信パスに沿って1つのネットワークノードから次のネットワークノードへと転送されてもよい。リソース予約要求は,ネットワークノードでの新規データフローの承認を要求する。
…(中略)…
【0046】
要求されたリソースを指定する記述子は,根底にあるアプリケーションの要件を満たすための最小限の必要リソースを指定することが好ましい。例えば,記述子は,必要な帯域幅や,中程度に必要な帯域幅や,ピークレートや,平均レートや,最大許容送信遅延などを指定してもよい。さらに,記述子は,リーキーバケットやトークンバケットを指定してもよい。」

したがって,上記引用文献2には,「処理要求を受信した手段が,処理要求の一部に含まれる情報(記述子)に基づいて必要リソースを識別し,トークンバケットを指定する」という技術的事項が記載されていると認められる。

3 引用文献3について
原査定の拒絶の理由に引用された引用文献3(米国特許出願公開第2002/0101820号明細書)の段落[0165]-[0167],[0234],[0267]-[0268],図19-20,30の記載からみて,当該引用文献3には,「パケットを受信した手段が,パケットの一部に含まれるヘッダ情報に基づいてQoSクラスを識別し,当該クラスに応じたトークンバケットを割り当てる」という技術的事項が記載されているものと認められる。

第4 対比・判断
1 本願発明1について
(1)対比
本願発明1と引用発明とを対比すると,次のことがいえる。
ア 引用発明は,「アプリケーションサーバからのI/O通信について,ネットワークインタフェース及びI/Oサブシステムのトランザクションタイプの区分に基づく階層的な分析によって,I/Oサブシステムのサービス品質(QoS)を管理する階層的QoS管理方法を仮想I/Oサーバが実行するためのプログラム」であるところ,「仮想I/Oサーバ」は,「アプリケーションサーバからのI/O通信」に対する「I/Oサブシステムのサービス品質(QoS)を管理」するものであり,「階層的トークンバケット(HTB)」のモデルにしたがって,「アプリケーションサーバからのI/O通信」に対する「リソース割り当て」を,対応する「バケット」からの「トークン」の量の減算によって行うと解される。
そうすると,引用発明の「仮想I/Oサーバ」上では,「アプリケーションサーバからのI/O通信」に対するリソースの“容量消費”を管理する“管理システム”が動作しているとみることができるから,引用発明は,“容量消費を管理するための管理システム用のプログラム”であるといえる。
また,本願発明1は,「容量消費を管理するためのデータベース管理システム用のプログラム」であり,「データベース管理システム」は,上位概念では,システムリソースの容量消費を管理する“管理システム”であるといえる。
したがって,引用発明と本願発明1とは,後記する点で相違するものの,“容量消費を管理するための管理システム用のプログラム”である点で共通するといえる。

イ 引用発明は,「I/Oサブシステムのサービス品質(QoS)を管理する階層的QoS管理方法を仮想I/Oサーバが実行するためのプログラム」であり,「仮想I/Oサーバ」上で「プログラム」が動作し,「仮想I/Oサーバ」は“コンピュータ可読命令が記憶されている1つ以上のメモリを有する”ことは明らかであるから,引用発明の「仮想I/Oサーバ」は本願発明1の「コンピューティングノード」に相当するといえる。
また,上記アでの検討より,引用発明の「仮想I/Oサーバ」上では,「アプリケーションサーバからのI/O通信」に対するリソースの“容量消費”を管理する“管理システム”が動作しているとみることができ,「仮想I/Oサーバ」の有するメモリが記憶する“コンピュータ可読命令”は“管理システムに所定のステップを行わせる”ことは明らかであるから,引用発明では,“コンピュータ可読命令は,前記1つ以上のコンピューティングノードによって実行される時に,前記管理システムに所定のステップを行わせる”といえる。
そうすると,上記アでの検討より,本願発明1の「データベース管理システム」は,上位概念では,システムリソースの容量消費を管理する“管理システム”であるといえるから,引用発明と本願発明1とは,後記する点で相違するものの,
“前記プログラムは,コンピュータ可読命令が記憶されている1つ以上のメモリを有する1つ以上のコンピューティングノード上で動作し,
前記コンピュータ可読命令は,前記1つ以上のコンピューティングノードによって実行される時に,前記管理システムに所定のステップを行わせる”点で共通するといえる。

ウ 引用発明は,「仮想I/Oサーバ」において「入力トラフィックはリーフクラスを識別すべく分類され」るとともに,「前記仮想I/Oサーバで実行されるファブリック受信プロセスは,I/Oファブリックインタフェースのいずれかから仮想I/O通信を受信」するところ,引用発明の「仮想I/O通信」は「クラス」が識別可能な入力トラフィックであり,上記アでの検討より,引用発明の「仮想I/O通信」は“管理システム上で容量消費が管理される”ことから,“管理システム上で容量消費が管理される”「仮想I/O通信」であって,「クラス」を識別可能な「仮想I/O通信」を受信するといえる。
一方,本願発明1は,「顧客のために遂行される動作を,前記データベース管理システム上で遂行させる要求であって,要求クラスを示す情報を含む要求を受信するステップ」を有するところ,上記アでの検討より,「データベース管理システム」で遂行される「要求」は“管理システム上で容量消費が管理される”ものであり,「要求クラス」を示す情報を含む「要求」は,上位概念である“クラス”を識別可能な「要求」と解されることから,本願発明1の「要求」は,“管理システム上で容量消費が管理される”ものであって,“クラスを識別可能”な「要求」を受信するといえる。
そうすると,引用発明の「仮想I/O通信」は本願発明1の「要求」に対応するといえ,引用発明と本願発明1とは,後記する点で相違するものの,“管理システム上で容量消費が管理される要求であって,クラスを識別可能な要求を受信するステップ”を行わせる点で共通するといえる。

エ 引用発明は,「仮想I/Oサーバ」において「階層の各クラスまたはノードは関連付けられたトークンバケットを有し,メッセージまたはパケットを送信のためにスケジューリングすると対応するバケットから所定量のトークンが減算され」るところ,「トークンバケット」を「クラス」に少なくとも基づいて決定すること,「トークンバケット」が減算される前に“第1の容量”を有することは明らかであり,引用発明の「トークンバケット」は本願発明1の「第1のトークンバケット」に相当するから,引用発明では,“関連付けられた第1の容量を有する第1のトークンバケットを,クラスに少なくとも部分的に基づいて決定する”といえる。
それに対して,本願発明1は,「関連付けられた第1の容量表示を有する第1のトークンバケットを,複数のトークンバケットを含む1つ以上のデータ構造から,前記要求クラスに少なくとも部分的に基づいて選択するステップ」を有するところ,「要求」に含まれる「要求クラス」は上位概念では“クラス”とみることができるから,本願発明1では,“関連付けられた第1の容量を有する第1のトークンバケットを,クラスに少なくとも部分的に基づいて決定する”といえる。
そうすると,引用発明と本願発明1とは,後記する点で相違するものの,“関連付けられた第1の容量を有する第1のトークンバケットを,前記クラスに少なくとも部分的に基づいて決定するステップ”を行わせる点で共通するといえる。

オ 引用発明は,「仮想I/Oサーバ」において「メッセージまたはパケットを送信のためにスケジューリングすると対応するバケットから所定量のトークンが減算され,対応する前記バケットが十分なトークンを含む場合には送信が許可され」るとともに,「仮想I/O通信と関連する仮想デバイスである前記アプリケーションサーバが,処理を進めるのに十分なトークンを有していると判断した場合には,相応のトークンを減算する」ところ,上記エでの検討より,「トークンバケット」が減算される前に“第1の容量”を有することは明らかであるから,「トークンバケット」の“第1の容量”が「仮想I/O通信」の処理を進めるのに十分であるかどうかを判断し,十分と判断された場合には,“利用された容量を,第1のトークンバケットから引き出し,第1の容量を更新する”と解することができる。
そうすると,上記ウでの検討より,引用発明の「仮想I/O通信」は本願発明1の「要求」に対応することから,引用発明は“第1の容量が,要求を処理するための容量に十分であると示すことを決定する”とともに,“前記第1の容量が,前記容量に十分であると示す場合,前記要求を処理する”,さらに,“前記要求を処理するステップにより利用された容量を,前記第1のトークンバケットから引き出し,前記第1の容量を更新する”といえる。
一方,本願発明1は,「前記第1の容量表示が,前記動作を遂行するための容量に十分であると示すことを決定するステップと,前記第1の容量表示が,前記容量に十分であると示す場合,前記動作を遂行するステップと,前記動作を遂行するステップにより利用された容量を,前記第1のトークンバケットから引き出し,前記第1の容量表示を更新するステップと,」を有するところ,上記ウでの検討より,「要求」は「顧客のために遂行される動作を,前記データベース管理システム上で遂行させる」ものであり,「要求」により動作が遂行されることから,「動作を遂行するため」とは“要求を処理するため”と同義であるといえる。
したがって,引用発明と本願発明1とは,後記する点で相違するものの,
“前記第1の容量が,前記要求を処理するための容量に十分であると示すことを決定するステップと,
前記第1の容量が,前記容量に十分であると示す場合,前記要求を処理するステップと,
前記要求を処理するステップにより利用された容量を,前記第1のトークンバケットから引き出し,前記第1の容量を更新するステップと,”
を行わせる点で共通するといえる。

カ 引用発明は,「仮想I/Oサーバ」において「対応する前記バケットが十分なトークンを含む場合には送信が許可され,各クラスは,保証レート,最高レート,実測レート及び優先度レベルを有し,優先度の高いクラスは優先度の低いクラスから超過リソース割り当てを借用してもよく,例えば,あるクラスの実測レートが保証レートに達した場合,前記クラスはその親クラスからトークンを借用してもよ」いものであるところ,上記ウでの検討より,引用発明の「仮想I/O通信」は本願発明1の「要求」に対応し,上記オでの検討より,引用発明は“前記要求を処理するステップにより利用された容量を,前記第1のトークンバケットから引き出し,前記第1の容量を更新する”ことから,“前記要求を処理するステップにより利用された容量”のうち,“第1のトークンバケット”の有する“第1の容量”からの「超過リソース」分を“親”の関係にある「トークンバケット」から「借用する」といえる。そして,引用発明の“親”の関係にある「トークンバケット」は本願発明1の「第2のトークンバケット」に対応し,引用発明において,“利用された容量”のうち,「超過リソース」分を「借用する」ことは,“利用された容量に少なくとも部分的に基づいて,所定の容量を引き出す”ことといえるから,引用発明では,“要求を処理するステップにより利用された容量に少なくとも部分的に基づいて,第1のトークンバケットの親の第2のトークンバケットから所定の容量を引き出す”といえる。
それに対し,本願発明1は,「前記動作を遂行するステップにより利用された前記容量に少なくとも部分的に基づいて,前記複数のトークンバケットのうちの第2のトークンバケットから利用された前記容量を引き出し,前記第2のトークンバケットに関連付けられた第2の容量表示を更新するステップ」を行わせ,「前記第2のトークンバケットは,前記第1のトークンバケットとトークンを共有する親バケットである」ところ,「第2のトークンバケット」は,「第1のトークンバケット」の“親”であると解され,「利用された前記容量に少なくとも部分的に基づいて」,「第1のトークンバケット」の“親”の「第2のトークンバケット」から“所定の容量”を引き出すといえる。
そうすると,引用発明と本願発明1とは,後記する点で相違するものの,
“前記要求を処理するステップにより利用された前記容量に少なくとも部分的に基づいて,前記第1のトークンバケットの親の第2のトークンバケットから所定の容量を引き出すステップ”
を行わせる点で共通するといえる。

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

(一致点)
「容量消費を管理するための管理システム用のプログラムであって,
前記プログラムは,コンピュータ可読命令が記憶されている1つ以上のメモリを有する1つ以上のコンピューティングノード上で動作し,
前記コンピュータ可読命令は,前記1つ以上のコンピューティングノードによって実行される時に,前記管理システムに,少なくとも,
前記管理システム上で容量消費が管理される要求であって,クラスを識別可能な要求を受信するステップと,
関連付けられた第1の容量を有する第1のトークンバケットを,前記クラスに少なくとも部分的に基づいて決定するステップと,
前記第1の容量が,前記要求を処理するための容量に十分であると示すことを決定するステップと,
前記第1の容量が,前記容量に十分であると示す場合,前記要求を処理するステップと,
前記要求を処理するステップにより利用された容量を,前記第1のトークンバケットから引き出し,前記第1の容量を更新するステップと,
前記要求を処理するステップにより利用された前記容量に少なくとも部分的に基づいて,前記第1のトークンバケットの親の第2のトークンバケットから所定の容量を引き出すステップと,
を行わせるプログラム。」

(相違点)
(相違点1)
本願発明1は,「容量消費を管理するためのデータベース管理システム用のプログラム」であるのに対して,
引用発明は,容量消費を管理するための管理システム用のプログラムであるものの,「データベース管理システム」であることは特定されていない点。

(相違点2)
コンピュータ可読命令に関し,本願発明1は,「コンピューティングノード」のメモリに記憶されている「コンピュータ可読命令」は,「データベース管理システム」に所定のステップを行わせるのに対して,
引用発明では,「仮想I/Oサーバ」に記憶されているコンピュータ可読命令は,「データベース管理システム」に所定のステップを行わせることは特定されていない点。

(相違点3)
要求を受信するステップに関し,本願発明1は,「顧客のために遂行される動作を,前記データベース管理システム上で遂行させる要求であって,要求クラスを示す情報を含む要求を受信する」のに対して,
引用発明は,クラスを識別可能な仮想I/O通信を受信するものの,そのような要求は特定されていない点。

(相違点4)
第1のトークンバケットを決定するステップに関し,本願発明1は,「関連付けられた第1の容量表示を有する第1のトークンバケットを,複数のトークンバケットを含む1つ以上のデータ構造から,前記要求クラスに少なくとも部分的に基づいて選択する」のに対して,
引用発明は,トークンバケットを,クラスに少なくとも基づいて決定するものの,そのように選択されることは特定されていない点。

(相違点5)
要求の処理に係る第1の容量の更新に関し,本願発明1は,「前記第1の容量表示が,前記動作を遂行するための容量に十分であると示すことを決定」し,「前記容量に十分であると示す場合,前記動作を遂行」し,「利用された容量を,前記第1のトークンバケットから引き出し,前記第1の容量表示を更新する」のに対して,
引用発明は,要求(仮想I/O通信)の「処理を進めるのに十分なトークンを有していると判断した場合には,相応のトークンを減算する」ものの,「動作を遂行するための容量」を引き出し,「容量表示」を更新することは特定されていない点。

(相違点6)
第2のトークンバケットに関し,本願発明1は,「前記動作を遂行するステップにより利用された前記容量に少なくとも部分的に基づいて,前記複数のトークンバケットのうちの第2のトークンバケットから利用された前記容量を引き出し,前記第2のトークンバケットに関連付けられた第2の容量表示を更新するステップ」を行わせ,「前記第2のトークンバケットは,前記第1のトークンバケットとトークンを共有する親バケットである」のに対して,
引用発明では,利用された容量のうち,第1のトークンバケットの有する第1の容量からの超過リソース分を親の関係にある第2のトークンバケットから借用するものの,第2のトークンバケットは,第1のトークンバケットとトークンを共有する親バケットであること,第2のトークンバケットから第1のトークンバケットで利用された容量を引き出し,前記第2のトークンバケットに関連付けられた第2の容量表示を更新することは特定されていない点。

(2)相違点についての判断
ア 相違点6について
事案に鑑みて,上記相違点6を先に検討すると,引用発明は,「仮想I/Oサーバ」において「対応する前記バケットが十分なトークンを含む場合には送信が許可され」,「優先度の高いクラスは優先度の低いクラスから超過リソース割り当てを借用してもよく,例えば,あるクラスの実測レートが保証レートに達した場合,前記クラスはその親クラスからトークンを借用してもよ」いと特定され,要求を処理するステップにより利用された容量のうち,第1のトークンバケットの有する第1の容量からの超過リソース分を親の関係にある第2のトークンバケットから借用することができると解されるものの,第1のトークンバケットとトークンを共有する親バケットであること,加えて,第1のトークンバケットの第1の容量表示が,動作を遂行するための容量に十分であると示すことを決定した場合に,利用された容量を,第1のトークンバケットから引き出し,第1の容量表示を更新した上で,第2のトークンバケットからも第1のトークンバケットで利用された容量を引き出し,前記第2のトークンバケットに関連付けられた第2の容量表示も更新することは特定されておらず,そのように設計変更することの動機付けもない。
そして,階層型トークンバケットを用いた容量消費を管理するためのシステムにおいて,第1のトークンバケットとトークンを共有する親バケットである第2のトークンバケットを設定し,第1のトークンバケットの第1の容量表示が,動作を遂行するための容量に十分であると示すことを決定した場合に,第2のトークンバケットから第1のトークンバケットで利用された容量を引き出し,前記第2のトークンバケットに関連付けられた第2の容量表示を更新する旨の技術は,上記引用文献2,3には記載されておらず,本願の優先日前に当該技術分野において周知技術であったとまではいえず,当業者が適宜に選択し得た設計的事項であるとすることもできない。
そうすると,引用発明において,第1のトークンバケットとトークンを共有する親バケットである第2のトークンバケットを設定し,動作を遂行するステップにより利用された容量に少なくとも部分的に基づいて,複数のトークンバケットのうちの第2のトークンバケットから利用された前記容量を引き出し,前記第2のトークンバケットに関連付けられた第2の容量表示を更新すること,すなわち,本願発明1の上記相違点6に係る構成とすることは,当業者が適宜なし得たものであるとすることはできない。

イ まとめ
したがって,他の相違点について判断するまでもなく,本願発明1は,当業者であっても,引用発明,引用文献2,3に記載された技術的事項に基づいて容易に発明できたものとはいえない。

2 本願発明2-3について
本願発明2-3は本願発明1を減縮した発明であり,本願発明1の
「前記動作を遂行するステップにより利用された前記容量に少なくとも部分的に基づいて,前記複数のトークンバケットのうちの第2のトークンバケットから利用された前記容量を引き出し,前記第2のトークンバケットに関連付けられた第2の容量表示を更新するステップ」を行わせ,「前記第2のトークンバケットは,前記第1のトークンバケットとトークンを共有する親バケットである」(以下,「相違点6に係る構成」という。)
と同一の構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献2,3に記載された技術的事項に基づいて容易に発明できたものとはいえない。

3 本願発明4-9について
本願発明4は本願発明1とカテゴリ表現が異なるだけの「容量消費を管理するための,コンピュータにより実行される方法」の発明であり,本願発明5-9は本願発明4を減縮した発明であり,本願発明1の「相違点6に係る構成」と同一の構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献2,3に記載された技術的事項に基づいて容易に発明できたものとはいえない。

4 本願発明10-13について
本願発明10は本願発明1に対応する「容量消費を管理するためのシステム用のプログラム」の発明であり,本願発明11-13は本願発明10を減縮した発明であり,本願発明1の「相違点6に係る構成」と同一の構成を備えるものであるから,本願発明1と同じ理由により,当業者であっても,引用発明,引用文献2,3に記載された技術的事項に基づいて容易に発明できたものとはいえない。

第5 原査定の概要及び原査定についての判断
原査定は,
●理由1(特許法第36条第6項第2号)について
請求項1-4,12-15のそれぞれに係る発明は明確でないから,特許法第36条第6項第2号の規定により特許を受けることができない。
●理由3(特許法第29条第2項)について
請求項1-15について上記引用文献1-3に記載された発明及び周知技術に基づいて,当業者が容易に発明できたものであるから,特許法第29条第2項の規定により特許を受けることができない。
というものである。
しかしながら,令和元年5月30日付け手続補正により補正された請求項1-3,10-13は,それぞれ「プログラム」の発明として特定されており,明確である。
また,令和元年5月30日付け手続補正により補正された請求項1-13は,それぞれ「相違点6に係る構成」に対応する構成を有するものとなっており,
上記のとおり,本願発明1-13は,引用発明,引用文献2,3に記載された技術的事項に基づいて,当業者が容易に発明できたものではない。
したがって,原査定を維持することはできない。

第6 当審拒絶理由について
1 特許法第36条第6項第1号について
(1)当審では,請求項1-13の課題解決手段としての「第2のトークンバケット」について,「第1のトークンバケット」との関係を「前記第1のトークンバケットの親バケットである,」と特定するにとどまり,「第1のトークンバケットとトークンを共有する」ことなどの発明の課題を解決するための手段が反映されていないため,発明の詳細な説明に記載した範囲を超えて特許を請求することになっているから,発明の詳細な説明に記載したものではないとの拒絶の理由を通知しているが,令和元年5月30日付けの手続補正により,
「前記第2のトークンバケットは,前記第1のトークンバケットとトークンを共有する親バケットである」
と補正された結果,この拒絶の理由は解消した。

2 特許法第36条第6項第2号について
(1)当審では,請求項1-13の「前記第1の容量表示が,前記動作を遂行するための容量に十分であることを決定するステップと,前記第1の容量表示が十分の場合,前記動作を遂行するステップと,」が特定する事項が不明確であるとの拒絶の理由を通知しているが,令和元年5月30日付けの手続補正により,
「前記第1の容量表示が,前記動作を遂行するための容量に十分であると示すことを決定するステップと,前記第1の容量表示が,前記容量に十分であると示す場合,前記動作を遂行するステップと,」
と補正された結果,この拒絶の理由は解消した。

(2)当審では,請求項1-13の「前記動作を遂行するステップにより利用された容量を,前記第1のトークンバケットから引き出すステップと,前記動作を遂行するステップにより利用された前記容量に少なくとも部分的に基づいて,前記複数のトークンバケットのうちの第2のトークンバケットに関連付けられた第2の容量表示を更新するステップと,を行わせ,」が特定する事項が不明確であるとの拒絶の理由を通知しているが,令和元年5月30日付けの手続補正により,
「前記動作を遂行するステップにより利用された前記容量に少なくとも部分的に基づいて,前記複数のトークンバケットのうちの第2のトークンバケットから利用された前記容量を引き出し,前記第2のトークンバケットに関連付けられた第2の容量表示を更新するステップと,を行わせ,」
と補正された結果,この拒絶の理由は解消した。

(3)当審では,請求項1-13の「前記第2のトークンバケットは,前記第1のトークンバケットの親バケットである,」が特定する事項が不明確であるとの拒絶の理由を通知しているが,令和元年5月30日付けの手続補正により,
「前記第2のトークンバケットは,前記第1のトークンバケットとトークンを共有する親バケットである,」
と補正された結果,この拒絶の理由は解消した。

第7 むすび
以上のとおり,本願発明1-13は,当業者が引用発明,引用文献2,3に記載された技術的事項に基づいて容易に発明をすることができたものではない。
したがって,原査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。

よって,結論のとおり審決する。
 
審決日 2019-07-18 
出願番号 特願2016-514144(P2016-514144)
審決分類 P 1 8・ 537- WY (G06F)
P 1 8・ 121- WY (G06F)
最終処分 成立  
前審関与審査官 圓道 浩史  
特許庁審判長 仲間 晃
特許庁審判官 須田 勝巳
辻本 泰隆
発明の名称 データベース作業負荷に対する入出力の優先順位付け  
代理人 二宮 浩康  
代理人 前川 純一  
代理人 上島 類  
代理人 大谷 令子  
代理人 アインゼル・フェリックス=ラインハルト  

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