2016-010940

特願２０１３－５２９２７４「アプリケーションサーバとクラスタ化されたデータベースとを接続するためのシステムおよび方法」拒絶査定不服審判事件〔平成２４年　３月２２日国際公開、ＷＯ２０１２／０３７１６３、平成２５年１１月１４日国内公表、特表２０１３－５４１７６４〕について、次のとおり審決する。

【結　論】 本件審判の請求は、成り立たない。

【理　由】 第１　手続の経緯 本願は、２０１１年（平成２３年）９月１３日（パリ条約による優先権主張外国庁受理２０１０年（平成２２年）９月１５日　米国、２０１０年（平成２２年）９月１７日　米国、２０１１年（平成２３年）６月２４日　米国）を国際出願日とする出願であって、平成２７年７月１４日付けで拒絶理由が通知され、平成２７年１０月１９日付けで手続補正がされ、平成２８年３月２３日付けで拒絶査定がされ、これに対し、平成２８年７月２０日に拒絶査定不服審判が請求され、同時に手続補正がされたものである。 第２　補正却下の決定 ［補正却下の決定の結論］ 平成２８年７月２０日付けの手続補正（以下、「本件補正」という。）を却下する。 ［理由］ １．補正後の本願発明 本件補正により、補正前の特許請求の範囲の請求項１は、 「【請求項１】 アプリケーションサーバとクラスタ化されたデータベースとの接続をサポートするためのシステムであって、 前記クラスタ化されたデータベース内の複数のデータベースインスタンスに関連付けられた通知サービス構成要素を備え、前記複数のデータベースインスタンスは単一の記憶装置に接続され、前記通知サービス構成要素は、前記クラスタ化されたデータベースの状態変化を表わす通知を一斉送信するように前記クラスタ化されたデータベースによって用いられ、前記システムはさらに、 前記アプリケーションサーバに関連付けられたデータソースを備え、データソースは、前記クラスタ化されたデータベース内の前記複数のデータベースインスタンスとの接続の組を管理する接続プールに関連付けられ、 前記データソースは、前記クラスタ化されたデータベースの変化についての通知を受取るように前記通知サービス構成要素に登録するように動作し、前記アプリケーションサーバは、ランタイム時の前記クラスタ化されたデータベースの状態変化に従って、前記アプリケーションサーバ内のアプリケーションと前記接続プールとの接続状態を変更することなく、前記クラスタ化されたデータベースと前記接続プールとの接続を適応的に構築して管理するように動作する、システム。」（下線部は補正箇所を示す。） と補正された。 ２．新規事項の有無、シフト補正の有無、補正の目的要件について 本件補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内において、補正前の特許請求の範囲の請求項１に記載された「前記アプリケーションサーバ内のアプリケーションと前記接続プールとの接続」について、「接続状態を変更することなく」との限定を付加して特許請求の範囲を減縮するものであるから、特許法第１７条の２第３項（新規事項）及び第５項第２号（補正の目的）の規定に適合している。 また、特許法第１７条の２第４項（シフト補正）に違反するものでもない。 ３．独立特許要件について 上記本件補正は特許請求の範囲の減縮を目的とするものであるから、補正後の請求項１に係る発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。 （１）補正発明 本件補正により補正された請求項１に係る発明（以下、「補正発明」という。）は、上記「１．補正後の本願発明」に記載したとおりのものである。 （２）引用例の記載事項 原審の拒絶理由に引用された米国特許出願公開第２００５／００３８８０１号明細書（以下、「引用例」という。）には図面とともに以下の事項が記載されている。 ア　「[0030] Operating Environment [0031] FIG. 1 is a block diagram that illustrates an operating environment in which an embodiment can be implemented. Embodiments of the invention may be implemented using a connection pool manager that is associated with a clustered computing system, such as a clustered database server comprising multiple database server instances executing on multiple host nodes to access and manipulate shared data stored on a data storage mechanism. [0032] Use of element identifiers ranging from a to n, for example, clients 102a-102n, services 106a-106n, instances 108a-108n, and nodes 110a-110n, does not mean that the same number of such components are required. In other words, n is not necessarily equal for the respective components. Rather, such identifiers are used in a general sense in reference to multiple similar components. [0033] One or more clients 102a-102n are communicatively coupled to a server 104. Server 104 refers to database server instances 108a-108n and nodes 110a-110n on which the instances execute. Other components may also be considered as part of the server 104 , such as a connection pool manager 114 , connection pools 116a-116n, a notification service daemon 118 and an event handler 120. The actual architecture in which the foregoing components are configured may vary from implementation to implementation. [0034] In FIG. 1, connection pool manager 114 and connection pools 116a-116n are depicted as components not within server 104 for purposes of example. Connection pool manager 114 is communicatively coupled to and utilized by an application server or, generally, a middle tier application 122. In addition, connection pool manager 114 is logically coupled to connection pools 116a-116n, which are logically coupled to server 104. Notification service daemon 118 and event handler 120 are also depicted as not within server 104, and are communicatively coupled to server 104. [0035] Clients 102a-102n may be applications executed by computers interconnected to an application server or some other middleware component between the clients and server 104 via, for example, a network. [0036] Database 112 comprises data and metadata that is stored on a persistent memory mechanism, such as a set of hard disks that are communicatively coupled to nodes 110a-110n, each of which is able to host one or more instances 108a-108n, each of which hosts at least a portion of one or more services. Such data and metadata may be stored in database 112 logically, for example, according to relational database constructs, multidimensional database constructs, or a combination of relational and multidimensional database constructs. Nodes 110a-110n can be implemented as a conventional computer system, such as computer system 400 illustrated in FIG. 4. [0037] As described, a database server, such as each of instances 108a-108n, is a combination of integrated software components and an allocation of computational resources (such as memory and processes) for executing the integrated software components on a processor, where the combination of the software and computational resources are used to manage a particular database, such as database 112. Among other functions of database management, a database server typically governs and facilitates access to database 112 by processing requests from clients to access the database 112 . Therefore, connection pool manager 114 , which manages connections to server 104 , can be implemented as a processing layer between clients 102a-102n and instances 108a-108n, which manage access to database 112 . Instances 108a-108n, in conjunction with respective nodes 110a-110n, host services, described hereafter. [0038] Services 106 [0039] As described, services are a logical abstraction for managing workloads. A service, such as service 106a-106n, is the performance of work of a particular type or category, where the work performed is for the benefit of one or more clients of one or more servers, and where a level or quality of performance is prescribed for the particular type or category of work. The work performed as part of a service includes any use or expenditure of computer resources, including, for example, CPU processing time, storing and accessing data in volatile memory, read and writes from and/or to persistent storage (i.e. disk space), and use of network or bus bandwidth. [0040] In general, a service is work that is performed by a database server and typically includes the work performed to process and/or compute queries that require access to a particular database. The term query as used herein refers to a statement that conforms to a database language, such as SQL, and includes statements that specify operations to add, delete, or modify data and create and modify database objects, such as tables, objects views, and executable routines. [0041] A single database may support many services. For a non-limiting example, services may be divided into a FIN service and a PAY service, where the FIN and PAY services share the clustered database. The FIN service is the database service performed by server 104 for a FIN application. Typically, the FIN service involves accessing database objects on database 112 that store data for FIN applications. The PAY service is the service performed by server 104 for PAY applications. Typically, the PAY service involves accessing database objects on database 112 that store data for PAY applications. [0042] Database instances of a database cluster are allocated to supporting one or more services. When a database instance (or node) is allocated to perform a service, the database instance is referred to herein as hosting, running, or providing the service, and the service is referred to herein as running or being placed on the database instance. [0043] Services can be provided by one or more database server instances. The service on each instance is referred to as a master of that service. Thus, multiple server instances may work together to provide a service to a client. In FIG. 1, service 106a (e.g., FIN) is depicted, with dashed brackets, as being provided by instance 108a, service 106b (e.g., PAY) is depicted as being provided by instances 108a and 108b, and service 106n is depicted as being provided by instances 108a-108n. [0044] Generally, the techniques described herein are service-centric, where events occurring within server 104 can be identified and/or characterized based on the service(s) which is affected by the event. [0045] Connection Pool Manager 114 and Connection Pools 116 [0046] The connection pool manager 114 is a software component, which manages connection pools 116a-116n and requests for connections for sessions with server 104, including the routing of connection requests to the appropriate connection pool 116a-116n, based on the pool setup and configuration. Each connection pool 116a-116n is a set of connections to database sessions. Each session, for which communications between a client 102a-102n and an instance 108a-108n are transmitted through one of the connections from a respective connection pool 116a-116n, is considered a session with an instance 108a-108n. [0047] Each connection can be instantiated as a connection object and for each connection object, the following information is recorded when a session connection is established: (1) the service that the session is using; (2) the name of the cluster node on which the associated service is available and to which this connection belongs; (3) the unique name of the database in use; and (4) the name of the instance to which this connection's database session belongs. Thus, the location (at times referred to as the“signature”) of each session is uniquely identified. The manner in which the signature is recorded may vary from implementation to implementation. For non-limiting examples, a signature may be recorded to a “bulletin board” mechanism that is accessible to various subscribers, or the signature may be stored in an indexed table or a hash table. The signature is also returned to the connection in various ways. In one embodiment, a handle is used as part of a connection conversation. Detailed actions that various subscribers may perform in response to notification events are beyond the scope of this description. [0048] Methods for managing session connections, which are performed by connection pool manager 114 in conjunction with associated worker threads, are described in reference to FIG. 2. [0049] Generally, connection pool manager 114 is responsible for creation, maintenance and removal of connections and connection pools 116a-116n. For example, connection pool manager 114 may be used to manage connection pools 116a-116n through use of a set of APIs. In addition, connection pool manager 114 binds a connection pool 116a-116n to its corresponding data source object. In this context, a data source object is an abstraction of an interface to the database 112. Hence, binding a connection pool to a data source object may include mapping the connection pool to the data source object via a URL that identifies the associated service and the port through which the database 112 is accessed for the service.」（段落[0030]-[0049]） （当審訳： [0030]動作環境 [0031]図１は、本実施形態を実施することができる動作環境を示すブロック図である。発明の実施例は、データ記憶機構に記憶されている共有データにアクセスし操作するために複数のホストノード上で実行する複数のデータベースサーバインスタンスを含むクラスタ化されたデータベースサーバなどのクラスタコンピュータシステムと関連付けられた接続プールマネージャを使用して実装することができる。 [0032]ａ～ｎの要素識別子の使用、例えば、クライアント１０２ａ～１０２ｎ、サービス１０６ａ～１０６ｎ、インスタンス１０８ａ～１０８ｎ、及びノード１１０ａ～１１０ｎは、同数のそのような構成要素が必要であることを意味するものではない。換言すれば、ｎはそれぞれの構成要素と必ずしも等しくない。そうではなく、このような識別子は、複数の同様の構成要素を参照して一般的な意味で使用されている。 [0033]１つ又は複数のクライアント１０２ａ～１０２ｎは、サーバ１０４に通信可能に結合されている。サーバ１０４は、データベースサーバインスタンス１０８ａ～１０８ｎと、インスタンスがその上で動作するノード１１０ａ～１１０ｎと、を参照する。接続プールマネージャ１１４、接続プール１１６ａ～１１６ｎ、通知サービスデーモン１１８及びイベントハンドラ１２０などのその他の構成要素は、サーバ１０４の一部として考えることができる。以上の構成要素が構成される実際のアーキテクチャは、実施ごとに変化し得る。 [0034]図１において、接続プールマネージャ１１４および接続プール１１６ａ～１１６ｎは、例示のためにサーバ１０４内にない構成要素として示されている。接続プールマネージャ１１４は、アプリケーションサーバ、または一般的に、中間層アプリケーション１２２に通信可能に結合され、利用される。接続プールマネージャ１１４は、サーバ１０４に論理的に結合された接続プール１１６ａ～１１６ｎに論理的に結合される。通知サービスデーモン１１８及びイベントハンドラ１２０もまた、サーバ１０４内にないように描かれており、サーバ１０４に通信可能に結合されている。 [0035]クライアント１０２ａ～１０２ｎは、クライアントとサーバ１０４との例えばネットワークを介して間にある、アプリケーションサーバ又はそれ以外の何らかの他のミドルウェア構成要素に相互接続されたコンピュータで実行されるアプリケーションであってもよい。 [0036]データベース１１２は、それぞれが１つ又は複数のサービスの少なくとも一部をホストをする１つ又は複数のインスタンス１０８ａ～１０８ｎをホストするノード１１０ａ～１１０ｎに通信可能に結合されている、ハードディスクの組などの永続的記憶機構に記憶されているデータ及びメタデータを含む。そのようなデータ及びメタデータは、例えばリレーショナルデータベース構築物、多次元データベース構築物、又はリレーショナル及び多次元データベースの構築物の組み合わせによれば、論理的にデータベース１１２に格納することができる。ノード１１０ａ～１１０ｎは、図４に示すコンピュータシステム４００のような従来のコンピュータシステムとして実現することができる。 [0037]上述のように、インスタンス１０８ａ～１０８ｎの各々のようなデータベースサーバは、統合されたソフトウェア構成要素と、プロセッサ上で統合されたソフトウェア構成要素を実行するための計算機リソース（メモリやプロセス等）の割り当て、との組合せであって、ソフトウェアと計算機リソースの組合せは、データベース１１２などの特定のデータベースを管理するために使用される。データベース管理の他の機能の中で、データベースサーバは、典型的には、クライアントからのデータベース１１２へアクセスするための要求を処理することによって、データベース１１２へのアクセスを制御し、促進する。したがって、サーバ１０４への接続を管理する接続プールマネージャ１１４は、データベース１１２へのアクセスを管理するクライアント１０２ａ～１０２ｎおよびインスタンス１０８ａ～１０８ｎとの間の処理層として実施することができる。インスタンス１０８ａ～１０８ｎは、各ノード１１０ａ～１１０ｎに連動して、後述するサービスをホストする。 [0038]サービス１０６ [0039]上述のように、サービスは、作業負荷を管理するための論理的抽象化である。サービス１０６ａ～１０６ｎなどのサービスは、特定のタイプまたはカテゴリの作業の性能であり、実行される作業は、１つ又は複数のサーバの１つ又は複数のクライアントのためのものであり、性能のレベルまたは品質が作業の特定のタイプまたはカテゴリについて規定される。サービスの一部として行われる作業は、コンピュータ資源のいかなる使用又は消費をも含み、例えば、ＣＰＵ処理時間、揮発性メモリ内のデータの格納及びアクセス、永続的ストレージ(つまりディスク・スペース)からの及び／又はへの読み出し及び書き込み、ネットワークやバス帯域の使用を含む。 [0040]一般に、サービスは、データベースサーバによって実行される作業であり、典型的には、処理及び/又は特定のデータベースへのアクセスを必要とするクエリを算出する作業を含む。本明細書で使用されるクエリという語は、ＳＱＬなどのデータベース言語に準拠したステートメントを指し、データを追加、削除、又は変更し、テーブル、オブジェクトビュー、及び実行可能なルーチンなどのデータベースオブジェクトを作成、修正する動作を指定するステートメントを含んでいる。 [0041]単一データベースは、多数のサービスをサポートすることができる。非限定的な例として、サービスは、ＦＩＮサービスとＰＡＹサービスに分けることができ、ＦＩＮ及びＰＡＹサービスは、クラスタ化されたデータベースを共有する。ＦＩＮサービスは、ＦＩＮアプリケーションのために、サーバ１０４によって実行されるデータベースサービスである。通常、ＦＩＮサービスは、ＦＩＮアプリケーションのためのデータを格納するデータベース１１２上のデータベースオブジェクトにアクセスすることを含む。ＰＡＹサービスはＰＡＹアプリケーションのために、サーバ１０４によって実行されるサービスである。通常、ＰＡＹサービスは、ＰＡＹアプリケーションのためのデータを格納するデータベース１１２上のデータベースオブジェクトにアクセスすることを含む。 [0042]データベースクラスタのデータベースインスタンスは、１つ又は複数のサービスをサポートするように配置されている。データベースインスタンス（又はノード）が、サービスを実行するために割り当てられている場合、データベースインスタンスは、ホストする、実行する、又はサービスを提供するものとして本明細書で参照され、サービスは、データベースインスタンスにおいて、実行する又は載置されるものとして参照される。 [0043]サービスは、１つ又は複数のデータベースサーバインスタンスによって提供することができる。各インスタンス上のサービスは、そのサービスのマスターと呼ばれる。このように、複数のサーバインスタンスが協働して、クライアントにサービスを提供することができる。図１では、サービス１０６ａ（例えば、ＦＩＮ）は、破線のブラケットで図示されるように、インスタンス１０８ａによって提供され、サービス１０６ｂ（例えば、ＰＡＹ）は、インスタンス１０８ａ及び１０８ｂによって提供されるように図示されており、サービス１０６ｎは、インスタンス１０８ａ～１０８ｎが提供しているものとして図示されている。 [0044]一般的に、ここに記載された技術は、サービス中心であり、イベントに影響を受けるサービスに基づいて、サーバ１０４内で発生したイベントが、識別及び/又は特徴付けられるものである。 [0045]接続プールマネージャ１１４および接続プール１１６ [0046]接続プールマネージャ１１４は、接続プール１１６ａ～１１６ｎを管理するとともに、プール設定および構成に基づいて適切な接続プール１１６ａ～１１６ｎに接続要求をルーティングすることを含むサーバ１０４とのセッションのための接続を要求する、ソフトウェア構成要素である。各接続プール１１６ａ～１１６ｎは、データベースセッションへの接続の集合である。各セッションは、クライアント１０２ａ～１０２ｎとインスタンス１０８ａ～１０８ｎとの間の通信は、各接続プール１１６ａ～１１６ｎからの接続のいずれかを介して送信される、インスタンス１０８ａ～１０８ｎとのセッションと考えられる。 [0047]各接続は、接続オブジェクトとして例示化され、各接続オブジェクトについて、セッション接続が確立されると以下の情報が記録されている：（１）セッションが使用しているサービス；（２）に関連付けられたサービスが利用可能でありこの接続が属するクラスタノードの名称；（３）使用中のデータベースの固有名；（４）この接続のデータベースセッションが属するインスタンスの名称。このように、各セッションの位置（ときに「署名」という）は、一意に識別される。署名が記録される態様は、実施ごとに変化し得る。非限定的な例として、署名は、様々な加入者にアクセス可能である「掲示板」機構に記録してもよいし、署名をインデックステーブル又はハッシュテーブルに格納することができる。署名はまた、様々な方法で接続に戻される。一実施形態では、ハンドルは、接続の会話の一部として使用される。様々な加入者は、通知イベントに応答して実行することができるが、詳細な動作は本明細書の範囲を超えている。 [0048]、ワーカースレッドに関連して接続プールマネージャ１１４によって実行されるセッション接続の管理方法について、図２を参照して説明する。 [0049]接続プールマネージャ１１４は、接続及び接続プール１１６ａ～１１６ｎを、作成、保守、及び除去する働きをする。例えば、接続プールマネージャ１１４は一組のＡＰＩを利用して接続プール１１６ａ～１１６ｎを管理するために使用することができる。加えて、接続プールマネージャ１１４は、接続プール１１６ａ～１１６ｎをその対応するデータソースオブジェクトに結合する。これに関連して、データソースオブジェクトは、データベース１１２へのインターフェースを抽象化したものである。したがって、接続プールをデータソースオブジェクトに結合することは、関連付けられたサービスとそのサービスのためにデータベース１１２へのアクセスが介されるポートとを識別するＵＲＬを介して、接続プールをデータソースオブジェクトへマッピングすることを含んでもよい。）（下線は当審で付した。以下同様。） イ　「[0053] In general, a daemon is a process that runs in the background and that performs a specified operation at predefined times or in response to certain events. In general, an event is an action or occurrence whose posting is detected by a process. Notification service daemon 118 is a process that receives event information from server 104, such as from clusterware that is configured to manage the cluster of instances 106a-106n. Such event information may include, for example, service, instance and node up or down event information. The database server 104 posts events when conditions change (i.e., UP, DOWN, NOT RESTARTING), as described in more detail herein. [0054] Notification service daemon 118 has a publisher/subscriber relationship with event handler 120, through which certain event information that is received by daemon 118 from server 104 is transmitted to event handler 120. In general, an event handler is a function or method containing program statements that are executed in response to an event. In response to receiving event information from daemon 118, event handler 120 invokes a method of connection pool manager 114, passing along the event type and property, which are described hereafter. In turn, a worker thread is created, per event, to process information between connection pool manager 114 and one or more relevant connection pools 116a-116n, for managing connections to sessions with server 104. 」（段落[0053]-[0054]） （当審訳： [0053]一般に、デーモンはバックグラウンドで実行し、所定の時刻に又はあるイベントに応答して所定の動作を行う処理である。一般に、イベントは、処理によって検出する動作又は発生である。通知サービスデーモン１１８は、インスタンス１０６ａ～１０６ｎ（当審注：「インスタンス１０６ａ～１０６ｎ」は「インスタンス１０８ａ～１０８ｎ」の誤記と認める。）のクラスタを管理するように構成されるクラスタウェアなどの、サーバ１０４からイベント情報を受信する処理である。このイベント情報は、例えば、サービスインスタンスとノードアップ又はダウンイベント情報を含んでいてもよい。データベースサーバ１０４は、本明細書でより詳細に説明するように、条件が変化した場合にイベントを通知する（すなわち、アップ、ダウン、再開しない）。 [0054]通知サービスデーモン１１８は、デーモン１１８によってサーバ１０４から受信される特定のイベント情報がイベントハンドラ１２０に伝達されることを通じて、イベントハンドラ１２０と発行者／加入者関係を有している。一般に、イベントハンドラは、イベントに応答して実行されるプログラムステートメントを含む機能又は方法である。デーモン１１８からイベント情報を受信したことに応答して、イベントハンドラ１２０は、後述するイベントタイプとプロパティに沿って実行する、接続プールマネージャ１１４のメソッドを呼び出す。ワーカースレッドは、サーバ１０４とのセッションへの接続を管理するための接続プールマネージャ１１４と１つ又は複数の関連する接続プール１１６ａ～１１６ｎとの間の情報を処理するために、イベントごとに作成される。） ウ　「[0067] Down Event Processing [0068] If a specific service is down at a specific instance, then the specific connections connected to this instance for this service are removed from the pool. If a node is down, then all connections associated with that node are removed from the pool. [0069] The number of connections that are authenticated as the default user of a data source object and those connections that are stateless (described hereafter), which are removed from the connection pool, is tracked. This number can be used during up event processing by the connection pool manager 114, as described hereafter. If the number of connections falls below a specified minimum connection pool limit for a given connection pool 116a-116n, then upon the first successful connection to the server 104, the connections are populated back to the minimum limit. [0070] Stateless connections are associated with connection objects that have no connection attributes or tagging specified by a client. For example, a client may tag a connection object with session state information (e.g., a transaction isolation level), and identify the tagged connection, so that the client does not have to reinitialize the session each time it uses the connection. Hence, the client can borrow the tagged connection from the connection pool, use it to perform some work, place it back in the connection pool and borrow it again for further work, without having to waste resources on round trips to the database to reinitialize the session state. [0071] The connection pools 116a-116n can include both stateless connections and connections with state information. However, in an embodiment, only the number of stateless connections is tracked by the connection pool manager 114, rather than also connections with state.[0072] According to one embodiment, when processing for connection recovery, the connections in the connection pool's “checked out” list are processed after claiming the connections from the application that is using such connections, and then the connections that are available for use from a given connection pool are processed. Applications, such as clients 102a-102n, that have connections to the down instance checked out (or borrowed) from the relevant connection pool 116a-116n, receive an error (i.e., node with service down or instance down) and immediately the checked out connection are identified (e.g., via the hash table) and cleaned up. In one embodiment, the application is expected to borrow another connection from the connection pool, determine the last result and resubmit the request. [0073] The connections that are affected by such an event can be identified by a state having only a socket connection value, without a corresponding session value. Generally, upon a service down event, connections in a relevant connection pool are aborted as quickly as possible. In addition, applications that request connections from the pool are prevented from receiving invalid or bad connections. [0074] Service Down at an Instance Event [0075] FIG. 2 is a flow diagram that illustrates a method for managing connections in response to a “service down at an instance” event, according to an embodiment. At block 202, a notification of an event, which identifies a termination of a service on a particular instance, is received. For example, connection pool manager 114 receives event information from event handler 120, wherein the relevant instance and service are identified. [0076] Once connection pool manager 114 receives event information that is associated with a service down at an instance event from event handler 120, connection pool manager 114 handles the event by matching the service and instance names that are identified in the event information with the session location information that was provided when the session connected. Hence, at block 204, based on the notification, a connection pool that is associated with the particular service is identified. [0077] One or more connections from the identified connection pool are processed as follows. In one embodiment, at block 206, one or more connections are identified which are associated with the instance and the connection pool identified in the event information. For example, connection pool manager 114 handles the event by matching the instance name that is identified in the event information with the instance name that is set in each session location information that is associated with a respective connection, e.g., via a hash table. [0078] At block 208, each connection that is identified at block 206 is marked as invalid. While invalid, the particular connection cannot be assigned to a requesting process. In one embodiment, a variable is maintained for the relevant connection pool, which indicates whether the connection pool has been processed for a down event. Hence, if a subsequent down event is received which identifies the down service that is associated with the previously processed connection pool, and which identifies a particular down instance, then no processing is performed and computational resources are not wasted. [0079] At block 210, each connection that is marked down is aborted. A specific method on the connection pool may be invoked for removal of the connections, where the method actually performs the removal processing, for example, by calling each connection's abort( ) method. Aborting the connection interrupts the blocked application thread, which is typically blocked (i.e., waiting for read/write on a socket) when the service or node goes down, and enables release of client side resources. Upon successful completion of the abort, the connection is effectively eliminated from the pool, thereby ensuring removal of the stale connection. In general, affected sessions blocked in I/O are aborted and affected sessions that are idle or checked out and between calls are redistributed across the cluster. In one embodiment, the abort process is a low level TCP implementation to interrupt the session. [0080] One example of how the one or more connections from the identified connection pool are processed, according to embodiments, is as follows. If a service-connection pool match is made at block 204, then relevant event information is posted on a FIFO queue that the matching connection pool manages. Connection pool manager 114 determines whether a worker thread already exists for processing connections from the identified connection pool. If such a worker thread does not already exist, then connection pool manager 114 spawns a worker thread to work on the failover processing of connections that are associated with the connection pool. For high availability purposes, threads should be cached and kept open. [0081] The database instance name is hashed or used as the index to locate the relevant connections quickly. For each connection for which a match is found, the connection is marked down, e.g., marked as invalid, thereby allowing for fast processing and preventing bad or invalid connections from being handed out of the connection pool. The number of connections that are authenticated as the default user of a data source object, and those connections that are stateless and that are removed from the connection pool, is tracked. This number can be used during up event connection processing, as described hereafter. The worker thread can continue to process events as long as there are events in the queue. 」（段落[0067]-[0081]） （当審訳： [0067]ダウンイベント処理 [0068]特定のインスタンスにおける特定のサービスがダウンしている場合、このサービスのためにこのインスタンスに接続された特定の接続は、プールから除去される。ノードがダウンしている場合、このノードに関連する全ての接続がプールから除去される。 [0069]データソースオブジェクトののデフォルトユーザとして認証される接続及び接続プールから除去されたステートレス（後述する）であるそれらの接続の数を追跡する。この数は、後述するように接続プールマネージャ１１４によってアップイベント処理中に使用することがでる。接続の数が、所与の接続プール１１６ａ～１１６ｎの特定の最小接続プール限度以下に低下する場合には、サーバ１０４に最初に成功した接続の際に、接続が最小限度にポピュレートされる。 [0070]ステートレス接続は、クライアントによって指定された属性またはタグ付けがされていない接続オブジェクトに関連付けられている。例えば、クライアントは、接続を使用するたびにセッションを再初期化する必要がなくなるように、セッション状態情報（例えば、トランザクション分離レベル）で接続オブジェクトをタグ付けし、タグ付けされた接続を識別することができる。したがって、クライアントは、データベースとのセッション状態を再初期化するための無駄なリソースを持つことなく、接続プールからタグ付けされた接続を借り、いくつかの作業を実行するためにそれを使用して接続プールに返し、さらなる作業のために再び借りることができる。 [0071]接続プール１１６ａ～１１６ｎは、ステートレス接続と状態情報を有する接続の両方を含むことができる。ただし、実施形態において、ステートレス接続の数だけが接続プールマネージャ１１４によって追跡され、状態を有する接続についてはこの限りではない。 [0072]一実施形態によれば、接続復旧を処理するとき、接続プールの「チェックアウト」リスト内の接続は、そのような接続を使用しているアプリケーションからの接続を主張した後処理され、次いで、所与の接続プールから使用可能な接続が処理される。ダウンしているインスタンスへの、関連する接続プール１１６ａ～１１６ｎからチェックアウトした（又は借りた）接続を有するクライアント１０２ａ～１０２ｎなどのアプリケーションは、エラー（すなわち、サービスダウン又はインスタンスダウンのあるノード）を受信し、直ちにチェックアウト接続が識別され（例えば、ハッシュテーブルを介して）、クリーンアップされる。一実施形態では、アプリケーションは、接続プールから別の接続を借りて、最終結果を決定し、要求を再提出することが期待されている。 [0073]このようなイベントによって影響を受ける接続は、ソケット接続値のみを持ち、対応するセッション値がない状態によって識別される。一般に、サービスダウンイベントにおいて、関連する接続プールの接続は、可能な限り迅速に中止される。加えて、プールからの接続を要求するアプリケーションは、無効又は不良接続を受け取ることが防止される。 [0074]インスタンスイベントにおけるサービスダウン [0075]図２は、「インスタンスイベントにおけるサービスダウン」イベントに応じて接続を管理する方法を示しているフロー図である。ブロック２０２では、特定のインスタンス上のサービスの終了を識別するイベントの通知を受信する。例えば、接続プールマネージャ１１４は、イベントハンドラ１２０から、関連するインスタンス及びサービスが識別されるイベント情報を受信する。 [0076]接続プールマネージャ１１４は、イベントハンドラ１２０からインスタンスイベントにおけるサービスダウンに関連するイベント情報を受信すると、接続プールマネージャ１１４は、セッションが接続されたときに提供されるセッション位置情報を伴うイベント情報において識別されるサービス及びインスタンス名とのマッチングによってイベントを取り扱う。ここで、ブロック２０４で、通知に基づいて、特定のサービスに関連する接続プールが識別される。 [0077]識別された接続プールからの１つ又は複数の接続は次のように処理される。一実施形態では、ブロック２０６において、イベント情報で識別されたインスタンスと接続プールに関連付けられている１つ又は複数の接続が識別される。例えば、接続プールマネージャ１１４は、例えばハッシュテーブルを介して、各接続に関連付けられている各セッションの位置情報に設定されているインスタンス名とイベント情報で識別されたインスタンス名をマッチングすることにより、イベントを取り扱う。 [0078]ブロック２０８では、ブロック２０６で識別された各接続は無効とマークされる。無効である間、特定の接続が要求処理へ割り当てることができない。一実施形態では、関連する接続プールについて、接続プールがダウンイベントを処理しているか否かを示す変数が維持される。したがって、以前に処理された接続プールに関連付けられているダウンサービスを識別し、特定のダウンインスタンスを識別する、後続のダウンイベントが受信された場合、処理は行われず、計算資源が無駄にならない。 [0079]ブロック２１０では、マークされた各接続が中止される。接続プールにおいて特定の方法は、接続を除去するために呼び出すことができ、この方法は、例えば、実際に各接続のabort( )メソッドを呼出すことによって、除去処理を行う。接続を中止することは、サービス又はノードがダウンしたときに典型的にはブロックされる（すなわち、ソケットにおける読み出し/書き込み待ち）ブロックされたアプリケーションスレッドを中断し、クライアント側の資源を解放することができる。中止が首尾よく完了すると、接続は効果的にプールから排除され、これによって、ステート接続を除去することを確保している。一般に、I/Oのブロックされた影響セッションは中止され、アイドル状態又はチェックアウト、及び呼の間の影響セッションは、クラスタに亘って再分配される。一実施形態では、中止処理はセッションを中断する低レベルＴＣＰ実装である。 [0080]実施形態によれば、特定された接続プールからの１つ又は複数の接続を処理する方法の一例は以下のとおりである。サービス－接続プールのマッチがブロック２０４で行われる場合、関連するイベント情報は、マッチング接続プールが管理するＦＩＦＯキューに記載されている。接続プールマネージャ１１４は、特定された接続プールからの接続の処理のためのワーカースレッドが既に存在するか否かを判定する。ワーカースレッドがまだ存在しない場合には、接続プールマネージャ１１４は接続プールに関連付けられている接続のフェイルオーバ処理に対して働くようにワーカースレッドを生成する。高可用性の目的のために、スレッドがキャッシュされ、開いたままにすべきである。 [0081]データベースインスタンス名は、迅速に関連する接続を特定するため、インデックスとしてハッシュされ又は使用される。一致が発見された接続ごとに、その接続がマーク、例えば、無効としてマークされ、それによって高速な処理が可能となり、接続プールのうち無効な接続を防止することができる。データソースオブジェクトのデフォルトのユーザとして認証された接続の数と、ステートレスであり接続プールから除去される接続の数は追跡される。この数はアップイベント接続処理中に使用することができ、以下に説明する。ワーカースレッドがキュー内のイベントであればイベントを処理し続けることができる。） 上記引用例の記載、引用例のＦＩＧ．１、ＦＩＧ．２及びこの分野の技術常識を考慮すると次のことがいえる。 ア　段落[0031]の「データ記憶機構に記憶されている共有データにアクセスし操作するために（・・・中略・・・）クラスタ化されたデータベースサーバ」との記載、段落[0041]の「クラスタ化されたデータベース」との記載、及びＦＩＧ．１の「DATABASE SERVER 104」との記載から、引用例に記載の「サーバー１０４」は、クラスタ化されたデータベースサーバといえる。 イ　段落[0034]の「接続プールマネージャ１１４は、アプリケーションサーバ、または一般的に、中間層アプリケーション１２２に通信可能に結合され、利用される。」との記載、及び段落[0035]の「クライアント１０２ａ～１０２ｎは、クライアントとサーバ１０４との例えばネットワークを介して間にある、アプリケーションサーバ又はそれ以外の何らかの他のミドルウェア構成要素に相互接続されたコンピュータで実行されるアプリケーション」との記載から、段落[0034]の「中間層アプリケーション１２２」と段落[0035]の「それ以外の何らかの他のミドルウェア構成要素」は同じもの（ＦＩＧ．１でいう「MID-TIER APPLICATION 122」）を指しており、「アプリケーションサーバ」の均等物といえる。 以上を総合すると、引用例には、以下の発明（以下、「引用発明」という。）が記載されている。 「サーバ１０４に通信可能に結合され、サーバ１０４との間にあるアプリケーションサーバ又は中間層アプリケーション１２２に相互接続されたコンピュータで実行されるアプリケーションである、１つ又は複数のクライアント１０２ａ～１０２ｎと、クライアント１０２ａ～１０２ｎからのデータベース１１２へアクセスするための要求を処理する、クラスタ化されたデータベースサーバであるサーバ１０４と、クライアントにサービス１０６ａ～１０６ｎを提供する、サーバ１０４内の複数のサーバインスタンス１０８ａ～１０８ｎと、インスタンス１０８ａ～１０８ｎのクラスタを管理するように構成され、サーバ１０４からイベント情報を受信する処理である、通知サービスデーモン１１８と、それぞれが１つ又は複数のサービス１０６ａ～１０６ｎの少なくとも一部をホストをする１つ又は複数のインスタンス１０８ａ～１０８ｎをホストするノード１１０ａ～１１０ｎに通信可能に結合されている、ハードディスクの組などの永続的記憶機構に記憶されているデータ及びメタデータを含むデータベース１１２と、イベントハンドラ１２０と、接続プール１１６ａ～１１６ｎと、接続プールマネージャ１１４と、を有するシステムにおいて、 通知サービスデーモン１１８は、デーモン１１８によってサーバ１０４から受信される特定のイベント情報がイベントハンドラ１２０に伝達されることを通じて、イベントハンドラ１２０と発行者／加入者関係を有しており、 接続プールマネージャ１１４は、アプリケーションサーバ又は中間層アプリケーション１２２に通信可能に結合され、利用されるものであり、接続プール１１６ａ～１１６ｎを管理するとともに、プール設定および構成に基づいて適切な接続プール１１６ａ～１１６ｎに接続要求をルーティングすることを含むサーバ１０４とのセッションのための接続を要求する、ソフトウェア構成要素であり、 各接続プール１１６ａ～１１６ｎは、データベースセッションへの接続の集合であり、各セッションは、クライアント１０２ａ～１０２ｎとインスタンス１０８ａ～１０８ｎとの間の通信は、各接続プール１１６ａ～１１６ｎからの接続のいずれかを介して送信される、インスタンス１０８ａ～１０８ｎとのセッションであり、 接続プールマネージャ１１４は、イベントハンドラ１２０からインスタンスイベントにおけるサービスダウンに関連するイベント情報を受信すると、接続プールマネージャ１１４は、イベントを取り扱い、ここで、ブロック２０４で、通知に基づいて、特定のサービスに関連する接続プールが識別され、ブロック２０６において、イベント情報で識別されたインスタンスと接続プールに関連付けられている１つ又は複数の接続が識別され、ブロック２０８では、ブロック２０６で識別された各接続は無効とマークされ、ブロック２１０では、マークされた各接続が中止され、ダウンしているインスタンスへの、関連する接続プール１１６ａ～１１６ｎからチェックアウトした（又は借りた）接続を有するクライアント１０２ａ～１０２ｎなどのアプリケーションは、エラー（すなわち、サービスダウン又はインスタンスダウンのあるノード）を受信し、直ちにチェックアウト接続が識別され（例えば、ハッシュテーブルを介して）、クリーンアップされ、アプリケーションは、接続プールから別の接続を借りて、最終結果を決定し、要求を再提出する、システム。」 （３）対比・判断 補正発明と引用発明とを対比する。 ア　引用発明の「アプリケーションサーバ又は中間層アプリケーション１２２」は、後述する相違点を除き、補正発明の「アプリケーションサーバ」に相当する。 イ　引用発明の「クラスタ化されたデータベースサーバであるサーバ１０４」は、補正発明の「クラスタ化されたデータベース」に相当する。 ウ　引用発明の「システム」は、全体として、「アプリケーションサーバ又は中間層アプリケーション１２２」と「クラスタ化されたデータベースサーバであるサーバ１０４」との接続をサポートするためのものといえる。 エ　したがって、引用発明の「システム」は、後述する相違点を除き、補正発明と、「アプリケーションサーバとクラスタ化されたデータベースとの接続をサポートするためのシステム」である点で一致する。 オ　引用発明の「通知サービスデーモン１１８」、「インスタンス１０８ａ～１０８ｎ」は、それぞれ補正発明の「通知サービス構成要素」、「データベースインスタンス」に相当する。 カ　引用発明の「通知サービスデーモン１１８」は、「インスタンス１０８ａ～１０８ｎのクラスタを管理するように構成され」るから、「通知サービスデーモン１１８」が「インスタンス１０８ａ～１０８ｎ」と関連付けられていることは明らかである。 キ　したがって、引用発明の「インスタンス１０８ａ～１０８ｎのクラスタを管理するように構成され、サーバ１０４からイベント情報を受信する処理である、通知サービスデーモン１１８」の構成は、補正発明の「前記クラスタ化されたデータベース内の複数のデータベースインスタンスに関連付けられた通知サービス構成要素を備え」る構成に相当する。 ク　引用発明の「データベース１１２」は、補正発明の「単一の記憶装置」と、「記憶装置」である点で共通する。 ケ　引用発明の「データベース１１２」は、「１つ又は複数のインスタンス１０８ａ～１０８ｎをホストするノード１１０ａ～１１０ｎに通信可能に結合されている」、すなわち、物理的な実体であるノード１１０ａ～１１０ｎがソフトウェアであるインスタンス１０８ａ～１０８ｎをホストしているのであるから、「データベース１１２」は、物理的にはノード１１０ａ～１１０ｎに接続される一方、論理的にはインスタンス１０８ａ～１０８ｎに接続されるといえる。 コ　したがって、引用発明の「それぞれが１つ又は複数のサービス１０６ａ～１０６ｎの少なくとも一部をホストをする１つ又は複数のインスタンス１０８ａ～１０８ｎをホストするノード１１０ａ～１１０ｎに通信可能に結合されている、ハードディスクの組などの永続的記憶機構に記憶されているデータ及びメタデータを含むデータベース１１２」の構成は、補正発明の「前記複数のデータベースインスタンスは単一の記憶装置に接続され」る構成と、「前記複数のデータベースインスタンスは記憶装置に接続され」る点で共通する。 サ　上記オのとおり、引用発明の「通知サービスデーモン１１８」は、補正発明の「通知サービス構成要素」に相当する。 シ　また、引用発明の「通知サービスデーモン１１８」は、「デーモン１１８によってサーバ１０４から受信される特定のイベント情報がイベントハンドラ１２０に伝達されることを通じて、イベントハンドラ１２０と発行者／加入者関係を有して」いるから、「サーバ１０４」（上記イのとおり、補正発明の「クラスタ化されたデータベース」に相当する。）の「特定のイベント情報」を送信するよう「サーバ１０４」に用いられているといえる。 ス　さらに、引用発明における、上記シの「特定のイベント情報」とは、具体的には「インスタンスイベントにおけるサービスダウンに関連するイベント情報」などを指しており、これは「サーバ１０４」の「状態変化」にほかならない。 セ　したがって、引用発明の「インスタンス１０８ａ～１０８ｎのクラスタを管理するように構成され、サーバ１０４からイベント情報を受信する処理である、通知サービスデーモン１１８」の構成は、補正発明の「前記通知サービス構成要素は、前記クラスタ化されたデータベースの状態変化を表わす通知を一斉送信するように前記クラスタ化されたデータベースによって用いられ」る構成と、「前記通知サービス構成要素は、前記クラスタ化されたデータベースの状態変化を表わす通知を送信するように前記クラスタ化されたデータベースによって用いられ」る点で共通する。 ソ　引用発明の「接続プールマネージャ１１４」は、補正発明の「データソース」に相当する。 タ　また、引用発明の「接続プールマネージャ１１４」は、「アプリケーションサーバ又は中間層アプリケーション１２２に通信可能に結合され、利用されるものであ」るから、「アプリケーションサーバ又は中間層アプリケーション１２２」（上記アのとおり、後述する相違点を除き、補正発明の「アプリケーションサーバ」に相当する。）に関連付けられてるといえる。 チ　したがって、引用発明の「接続プールマネージャ１１４は、アプリケーションサーバ又は中間層アプリケーション１２２に通信可能に結合され、利用されるものであり」との構成は、後述する相違点を除き、補正発明の「前記アプリケーションサーバに関連付けられたデータソースを備え、」との構成に相当する。 ツ　引用発明の「接続プールマネージャ１１４」は、「接続プール１１６ａ～１１６ｎを管理するとともに、プール設定および構成に基づいて適切な接続プール１１６ａ～１１６ｎに接続要求をルーティングすることを含むサーバ１０４とのセッションのための接続を要求する、ソフトウェア構成要素であり、」そして「各接続プール１１６ａ～１１６ｎは、データベースセッションへの接続の集合であり、各セッションは、クライアント１０２ａ～１０２ｎとインスタンス１０８ａ～１０８ｎとの間の通信は、各接続プール１１６ａ～１１６ｎからの接続のいずれかを介して送信される、インスタンス１０８ａ～１０８ｎとのセッション」である。すなわち、「接続プールマネージャ１１４」は、インスタンス１０８ａ～１０８ｎとの間の通信（セッション）のための「接続」の集合（組）である「接続プール１１６ａ～１１６ｎ」を管理しているのであるから、「接続プール１１６ａ～１１６ｎ」と関連付けられているといえる。 テ　したがって、引用発明の「接続プールマネージャ１１４は、」「接続プール１１６ａ～１１６ｎを管理するとともに、プール設定および構成に基づいて適切な接続プール１１６ａ～１１６ｎに接続要求をルーティングすることを含むサーバ１０４とのセッションのための接続を要求する、ソフトウェア構成要素であり、各接続プール１１６ａ～１１６ｎは、データベースセッションへの接続の集合であり、各セッションは、クライアント１０２ａ～１０２ｎとインスタンス１０８ａ～１０８ｎとの間の通信は、各接続プール１１６ａ～１１６ｎからの接続のいずれかを介して送信される、インスタンス１０８ａ～１０８ｎとのセッションであり、」との構成は、補正発明の「データソースは、前記クラスタ化されたデータベース内の前記複数のデータベースインスタンスとの接続の組を管理する接続プールに関連付けられ、」との構成に相当する。 ト　引用発明の「通知サービスデーモン１１８」は、「デーモン１１８によってサーバ１０４から受信される特定のイベント情報がイベントハンドラ１２０に伝達されることを通じて、イベントハンドラ１２０と発行者／加入者関係を有して」おり、「接続プールマネージャ１１４」は、「イベントハンドラ１２０からインスタンスイベントにおけるサービスダウンに関連するイベント情報を受信する」のであるから、引用発明の「接続プールマネージャ１１４」は、「イベントハンドラ１２０」を介して、サーバ１０４の状態変化についての通知を受け取るよう、前記「通知サービスデーモン１１８」に登録しているといえる。 ナ　したがって、引用発明の「通知サービスデーモン１１８は、デーモン１１８によってサーバ１０４から受信される特定のイベント情報がイベントハンドラ１２０に伝達されることを通じて、イベントハンドラ１２０と発行者／加入者関係を有しており、」及び「接続プールマネージャ１１４は、イベントハンドラ１２０からインスタンスイベントにおけるサービスダウンに関連するイベント情報を受信する」との構成は、補正発明の「前記データソースは、前記クラスタ化されたデータベースの変化についての通知を受取るように前記通知サービス構成要素に登録するように動作し、」との構成と、引用発明のように、接続プールマネージャ１１４がイベントハンドラ１２０を介して間接的に通知サービスデーモン１１８への登録を行うか、補正発明のように「データソース」が直接「通知サービス構成要素」への登録を行うか、という点で相違する一方、両構成は、「前記クラスタ化されたデータベースの変化についての通知を受取るように前記通知サービス構成要素に登録するように動作し、」との構成で共通する。 ニ　引用発明の「クライアント１０２ａ～１０２ｎ」は、「サーバ１０４との間にあるアプリケーションサーバ又は中間層アプリケーション１２２に相互接続されたコンピュータで実行されるアプリケーション」であるから、後述する相違点を除き、補正発明の「アプリケーション」に相当する。 ヌ　引用発明において、「接続プールマネージャ１１４は、イベントハンドラ１２０からインスタンスイベントにおけるサービスダウンに関連するイベント情報を受信すると、接続プールマネージャ１１４は、イベントを取り扱い、ここで、ブロック２０４で、通知に基づいて、特定のサービスに関連する接続プールが識別され、ブロック２０６において、イベント情報で識別されたインスタンスと接続プールに関連付けられている１つ又は複数の接続が識別され、ブロック２０８では、ブロック２０６で識別された各接続は無効とマークされ、ブロック２１０では、マークされた各接続が中止され、ダウンしているインスタンスへの、関連する接続プール１１６ａ～１１６ｎからチェックアウトした（又は借りた）接続を有するクライアント１０２ａ～１０２ｎなどのアプリケーションは、エラー（すなわち、サービスダウン又はインスタンスダウンのあるノード）を受信し、直ちにチェックアウト接続が識別され（例えば、ハッシュテーブルを介して）、クリーンアップされ、アプリケーションは、接続プールから別の接続を借りて、最終結果を決定し、要求を再提出する」のであるから、この間、引用発明の「アプリケーション」と「接続プール１１６ａ～１１６ｎ」との接続状態は常に維持されている、すなわち「接続状態を変更することがない」。また、この間、サーバ１０４と接続プール１１６ａ～１１６ｎとの「接続を適応的に構築して管理」しているといえる。 ネ　したがって、引用発明の上記構成と、補正発明の「前記アプリケーションサーバは、ランタイム時の前記クラスタ化されたデータベースの状態変化に従って、前記アプリケーションサーバ内のアプリケーションと前記接続プールとの接続状態を変更することなく、前記クラスタ化されたデータベースと前記接続プールとの接続を適応的に構築して管理するように動作する、」との構成とは、「ランタイム時の前記クラスタ化されたデータベースの状態変化に従って、アプリケーションと前記接続プールとの接続状態を変更することなく、前記クラスタ化されたデータベースと前記接続プールとの接続を適応的に構築して管理するように動作する、」点で共通する。 以上を総合すると、補正発明と引用発明とは、次の一致点、相違点を有する。 （一致点） 「アプリケーションサーバとクラスタ化されたデータベースとの接続をサポートするためのシステムであって、 前記クラスタ化されたデータベース内の複数のデータベースインスタンスに関連付けられた通知サービス構成要素を備え、前記複数のデータベースインスタンスは記憶装置に接続され、前記通知サービス構成要素は、前記クラスタ化されたデータベースの状態変化を表わす通知を送信するように前記クラスタ化されたデータベースによって用いられ、前記システムはさらに、 前記アプリケーションサーバに関連付けられたデータソースを備え、データソースは、前記クラスタ化されたデータベース内の前記複数のデータベースインスタンスとの接続の組を管理する接続プールに関連付けられ、 前記クラスタ化されたデータベースの変化についての通知を受取るように前記通知サービス構成要素に登録するように動作し、ランタイム時の前記クラスタ化されたデータベースの状態変化に従って、アプリケーションと前記接続プールとの接続状態を変更することなく、前記クラスタ化されたデータベースと前記接続プールとの接続を適応的に構築して管理するように動作する、システム。」 （相違点１） 一致点の「複数のデータベースインスタンスは記憶装置に接続され、」の構成に関し、補正発明は、「単一の記憶装置」に接続されているのに対し、引用発明は、単一か否かが特定されていない点。 （相違点２） 一致点の「前記通知サービス構成要素は、前記クラスタ化されたデータベースの状態変化を表わす通知を送信するように前記クラスタ化されたデータベースによって用いられ、」の構成に関し、補正発明は、「一斉送信」であるのに対し、引用発明は、一斉送信か否かが特定されていない点。 （相違点３） 一致点の「前記クラスタ化されたデータベースの変化についての通知を受取るように前記通知サービス構成要素に登録するように動作し、」の構成に関し、補正発明は、「データソース」が直接「通知サービス構成要素」への登録を行うのに対し、引用発明は、「接続プールマネージャ１１４」が「イベントハンドラ１２０」を介して間接的に「通知サービスデーモン１１８」への登録を行う点。 （相違点４） 一致点の「ランタイム時の前記クラスタ化されたデータベースの状態変化に従って、アプリケーションと前記接続プールとの接続状態を変更することなく、前記クラスタ化されたデータベースと前記接続プールとの接続を適応的に構築して管理するように動作する、」の構成に関し、補正発明は、「アプリケーションサーバ」が「クラスタ化されたデータベースと前記接続プールとの接続を適応的に構築して管理する」のに対して、引用発明は、「アプリケーション」が対応する動作を行っている点。 （相違点５） 上記一致点の「ランタイム時の前記クラスタ化されたデータベースの状態変化に従って、アプリケーションと前記接続プールとの接続状態を変更することなく、前記クラスタ化されたデータベースと前記接続プールとの接続を適応的に構築して管理するように動作する、」の構成に関し、補正発明は、「アプリケーションサーバ内」に「アプリケーション」が存在するのに対し、引用発明の「クライアント１０２ａ～１０２ｎ」は、「サーバ１０４に通信可能に結合され、サーバ１０４との間にあるアプリケーションサーバ又は中間層アプリケーション１２２に相互接続されたコンピュータ」、すなわち、アプリケーションサーバ又は中間層アプリケーション１２２の外部にあるコンピュータで「実行される」点。 （４）判断 上記相違点につき検討する。 （相違点１）について 引用例のＦＩＧ．１を参照すると、ｎ個のインスタンス１０８ａ～１０８ｎに、１つのデータベース１１２が接続されている。すなわち、複数のインスタンス１０８ａ～１０８ｎは単一のデータベース１１２に接続されているにほかならず、相違点１は実質的な相違点とはいえない。 仮に、補正発明の「単一の記憶装置」が、例えば、複数台のハードディスク装置のアレイなどによって実現されるものではなく、物理的に１台のハードディスク装置によって実現されていることを意味するとしても、記憶装置の台数は、性能や費用等を考慮して、当業者が適宜決定すべきものである。 （相違点２）について 引用発明において、サーバ１０４の複数の状態変化が、間を置かず立て続けに発生する場合が想定される。このような場合に、これら状態変化に対応する通知を別々にではなく、まとめて、すなわち一斉に、送信するようにすることは、当業者であれば容易に想到し得たものである。 （相違点３）について 一般に、複数の機能を、それぞれ別の構成要素に担当させるか、１つの構成要素にまとめるかは、当業者が適宜決定すべき事項であるから、引用発明において、「接続プールマネージャ１１４」に「イベントハンドラ１２０」の機能をも持たせ、補正発明の相違点３に係る構成とすることは、当業者であれば容易に想到し得たものである。 （相違点４及び５）について 一般に、複数の機能を、複数台のコンピュータにそれぞれ担当させるか、１台のコンピュータに集約して担当させるかは、当業者が適宜決定すべき事項であるから、引用発明の「アプリケーションサーバ又は中間層アプリケーション１２２」において、クライアント１０２ａ～１０２ｎをも実行することとし、補正発明の相違点４及び５に係る構成とすることは、当業者であれば容易に想到し得たものである。 （５）まとめ 以上のとおり、補正発明は、引用発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許出願の際独立して特許を受けることができないものである。 したがって、本件補正は、特許法第１７条の２第６項において準用する特許法第１２６条第７項の規定に違反するので、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 第３　本願発明について １．本願発明 平成２８年７月２０日付けの手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成２７年１０月１９日付けで提出された手続補正書により補正された特許請求の範囲の請求項１に記載された以下のとおりのものである。 「【請求項１】 アプリケーションサーバとクラスタ化されたデータベースとの接続をサポートするためのシステムであって、 前記クラスタ化されたデータベース内の複数のデータベースインスタンスに関連付けられた通知サービス構成要素を備え、前記複数のデータベースインスタンスは単一の記憶装置に接続され、前記通知サービス構成要素は、前記クラスタ化されたデータベースの状態変化を表わす通知を一斉送信するように前記クラスタ化されたデータベースによって用いられ、前記システムはさらに、 前記アプリケーションサーバに関連付けられたデータソースを備え、データソースは、前記クラスタ化されたデータベース内の前記複数のデータベースインスタンスとの接続の組を管理する接続プールに関連付けられ、 前記データソースは、前記クラスタ化されたデータベースの変化についての通知を受取るように前記通知サービス構成要素に登録するように動作し、前記アプリケーションサーバは、ランタイム時の前記クラスタ化されたデータベースの状態変化に従って、前記アプリケーションサーバ内のアプリケーションと前記接続プールとの接続を維持したまま、前記クラスタ化されたデータベースと前記接続プールとの接続を適応的に構築して管理するように動作する、システム。」 ２．引用例の記載事項 引用例の記載事項は、上記「第２　補正却下の決定」の項中の「３．独立特許要件について」の項中の「（２）引用例の記載事項」の項で認定したとおりである。 ３　対比・判断 本願発明は上記補正後の発明から当該本件補正に係る限定を省いたものである。 そうすると、本願発明の構成に当該本件補正に係る限定を付加した補正後の発明が、上記「第２　補正却下の決定」の項中の「３．独立特許要件について」の項で検討したとおり、引用発明に基づいて容易に発明できたものであるから、本願発明も同様の理由により、容易に発明できたものである。 ４　むすび 以上のとおり、本願発明は、引用発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 したがって、他の請求項に係る発明について審理するまでもなく、本願は拒絶すべきものである。 よって、結論のとおり審決する。