Without requiringDETAILED ACTION
Summary and Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to Applicant’s reply filed 9/29/2025.
Claims 6 and 19 are cancelled.
Claims 32 and 33 are new.
Claims 1-3, 7-9, 13, 20-25, and 27-33 are pending.
Claims 1-3, 7-9, 13, 21-25, and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Oracle (“Database Live Migration with Oracle Multitenant and the Oracle Universal Connection Pool (UCP) on Oracle Real Application Clusters (RAC)”, October 2014) of record, in view of Mordani et al. (US Patent Pub 2015/0207758), and Duan et al. (US Patent Pub 2011/0055151), further in view of de Lavarene et al. (US Patent Pub 2014/0324911) of record.
Claims 20, 27, 29, 30, 32, and 33 are rejected under 35 U.S.C. 103 as being unpatentable over Oracle (“Database Live Migration with Oracle Multitenant and the Oracle Universal Connection Pool (UCP) on Oracle Real Application Clusters (RAC)”, October 2014) of record, in view of Mordani et al. (US Patent Pub 2015/027758), Duan et al. (US Patent Pub 2011/0055151), and de Lavarene (US Patent Pub 2014/0324911) of record, further in view of Hussain et al. (“Expert Oracle RAC 12c”, 2013) of record.
Claim 31 is rejected under 35 U.S.C. 103 as being unpatentable over Oracle (“Database Live Migration with Oracle Multitenant and the Oracle Universal Connection Pool (UCP) on Oracle Real Application Clusters (RAC)”, October 2014) of record, in view of Mordani et al. (US Patent Pub 2015/027758), Duan et al. (US Patent Pub 2011/0055151), and de Lavarene (US Patent Pub 2014/0324911) of record, further in view of Shivarudraiah et al. (US Patent Pub 2014/0379756)1.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim Objections
Claims 1 and 7 are objected to because of the following informalities:
In claim 1, second limitation, line 3, “use” should be “uses.”
In claim 1, limitation starting “wherein the system maintains…”, line 3, “a tenant’s data source” should be “the particular tenant’s data source” for consistency.
Claim 7 recites the same limitations and is objected to for the same reasons.
Appropriate correction is required.
Note on Prior Art Rejections
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 7-9, 13, 21-25, and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Oracle (“Database Live Migration with Oracle Multitenant and the Oracle Universal Connection Pool (UCP) on Oracle Real Application Clusters (RAC)”, October 2014) of record, in view of Mordani et al. (US Patent Pub 2015/0207758) (Mordani), and Duan et al. (US Patent Pub 2011/0055151) (Duan), further in view of de Lavarene et al. (US Patent Pub 2014/0324911) (de Lavarene) of record.
In regards to claim 1, Oracle discloses a system for providing access to a database in a multi-tenant environment, including the use of a connection pool, and support for dynamic relocation of tenants (Oracle at pg. 4), comprising:
a. a computer including a processor, and at least one of an application server or database environment executing thereon (Oracle at pg. 4);
b. wherein the computer controls creation and use of connection objects in a connection pool that receives requests from software applications to request a connection from the connection pool, and use a provided connection to access a database (Oracle at pg. 4)2, wherein the database environment includes a container database and a plurality of database locations provided as pluggable databases, wherein the database locations are associated with one or more listeners that provide access via the connections to the database locations (Oracle at pg. 43, pgs. 6-74);
c. wherein the application server or database environment hosts a multi-tenant software application that provides access to the database environment through one or more services associated with the database locations (Oracle at pgs. 4-5)5 and a database driver (Oracle at pgs. 6-7)6;
d. wherein each database location, of the plurality of database locations, is associated with one or more tenants accessing the multi-tenant software application via one or more of the services, wherein each particular tenant is associated with its own particular pluggable database at the container database, and can use connections provided by the connection pool to access the particular pluggable database associated with that tenant, via a database service associated with the particular pluggable database (Oracle at pgs. 4-5)7;
e. wherein, in response to receiving an instruction to migrate a data source associated with a tenant, from a first database location within the plurality of database locations to a second database location within the plurality of database locations, the connection pool causes the tenant associated with the client application, to be relocated within the plurality of database locations (Oracle at pg. 6)8 including:
i. controlling draining of existing connections to the first database location originally associated with the tenant, including draining connections that are associated with an original pluggable database location and its associated database service and relocating the availability of those connections to a new pluggable database location and associated database service (Oracle at pgs. 4, 7-8)9, and
ii. forwarding requests associated with the existing or new connections to the second database location associated with the tenant (Oracle at pgs. 7-8)10,
iii. wherein during migration of the data source, the connection pool operates to route the connection requests to database locations associated with the client applications, including that a listener associated with the plurality of database locations including the first and second database locations is configured to send redirects to the connection pool to send the requests associated with the existing or new connections to the second database location, without requiring the client application to change the request (Oracle at pgs. 6-7)11;
Oracle does not expressly disclose (1) wherein client applications specify connections to the database by associating connect strings with connection requests, (2) a mapping of tenants to the services, wherein the system maintains a mapping of each particular tenant to a particular data source at the database locations and wherein the multi-tenant software application is adapted to make connection results associated with a tenant’s data source, (3) maintains a topology layer which over a period of time learns and caches key ranges associated with the tenants database locations for use with the connection pool, (4) wherein a client application associated with a tenant operates to provide, as part of the connect string associated with a connection request, one or more keys to the connection pool in association with the connection request, (5) wherein based on comparing the one or more keys provided by the client application as part of the connect string associated with the connection request, with the key range cached in the topology layer, the connection pool routes the connection request to a database location associated with that client application, without requiring the client application to change the connect string associated with the data source during a migration, and (6) topology layer to send connection requests using the connect string having one or more keys, and wherein the client application associated with the tenant continues to use its connect string to connect to the tenant’s data source upon its relocation to the second database location. It is noted that Oracle discloses each database has at least a default service. Additional services are also created for each database. Oracle at pg. 5. Oracle does not expressly disclose the topology layer and one or more cached keys feature and using them to request new connections with the connect string.
Mordani discloses and system and method for supporting a multitenant database system for access by tenants using applications over the cloud of another environment. Mordani at abstract. Mordani discloses resources, such as databases, are partitioned and a mapping is provided that maps particular partitions to particular tenants for services (i.e., mapping of tenants to the services, wherein the system maintains a mapping of each particular tenant to a particular data source at the database locations and wherein the multi-tenant software application is adapted to make connection results associated with a tenant’s data source). Mordani at paras. 0015-16, 0018, 0051. As discussed, Mordani discloses a mapping (i.e., maintains a topology layer), which is maintained (i.e., over a period of time learns and caches) with partition IDs (i.e., one or more keys) and connections for a particular tenant (i.e., maintains a topology layer which over a period of time learns and caches key ranges associated with the tenants database locations). The mapping also allows the system to provide an existing connection already associated with the tenant to service the request, but can create a new one if one does not exist. Mordani at para. 0101. Mordani further discloses tenants making a connection request provide a partition ID (i.e., one or more keys), which is used to connect a tenant user to the correct partition (i.e., wherein a client application associated with a tenant is operable to provide one or more keys to the connection pool in association with a connection request, and based on comparison with the one or more keys cached in the topology layer, the connection pool routes the connection request to a database location associated with that client application; the connect string having one or more keys). Mordani at para. 0073. In this way, the same “connect string” is used to connect to a tenant’s data source. Mordani also provides connection switching (i.e., a feature to switch services to utilize connections to the database locations). Mordani at para. 0073. Since there is a mapping to determine the appropriate database partition, services for that database are also mapped to the tenant for that database, which is in accordance with services assigned to a database as disclosed by Oracle. Thus, Mordani discloses a partition mapping (i.e. topology layer) and partition IDs (i.e., one or more keys), which are both used in requesting new connections (i.e., connection string having one or more keys associated with the tenant’s data source) and reusing connections.
Oracle and Mordani are analogous art because they are both directed to the same field of endeavor of database systems and handling of database connection requests.
At a time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Oracle by adding the features of (1) wherein client applications specify connections to the database by associating connect strings with connection requests, (2) a mapping of tenants to the services, wherein the system maintains a mapping of each particular tenant to a particular data source at the database locations and wherein the multi-tenant software application is adapted to make connection results associated with a tenant’s data source, (3) maintains a topology layer which over a period of time learns and caches key ranges associated with the tenants database locations for use with the connection pool, (4) wherein a client application associated with a tenant operates to provide, as part of the connect string associated with a connection request, one or more keys to the connection pool in association with the connection request, (5) wherein based on comparing the one or more keys provided by the client application as part of the connect string associated with the connection request, with the key range cached in the topology layer, the connection pool routes the connection request to a database location associated with that client application, without requiring the client application to change the connect string associated with the data source during a migration, and (6) topology layer to send connection requests using the connect string having one or more keys, and wherein the client application associated with the tenant continues to use its connect string to connect to the tenant’s data source upon its relocation to the second database location, as disclosed by Mordani.
The motivation for doing so would have been to provide service to a large number of users or tenants over distributed environments. Mordani at para. 0014.
Oracle in view of Mordani does not expressly disclose (1) a database driver that maintains the topology layer and database driver specifically manages all connection requests, as it operates with the connection pool, such as during a migration, where connection requests are redirected to the database driver to cause the connection pool to send requests to the second database location. It is noted that both Oracle and Mordani disclose database drivers, such as JDBC (Oracle at pg 8; Mordani at paras. 0042, 0047, 0049). However, it is not expressly disclosed that the database driver manages the topology and manages connection requests.
Duan discloses a system and method for managing connection requests to a partitioned database. The system is at least partially implemented using a database driver, such as JDBC. The system manages a metadata repository that stores a partition key mapping table that maps partitions to tenants. The request processing is performed by the database driver. Duan at Fig. 1; paras. 0017-18, 0035.
Oracle, Mordani, and Duan are analogous art because they are directed to the same field of endeavor of database request management.
At the time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Oracle in view of Mordani by adding the features of a database driver that maintains the topology layer and database driver specifically manages all connection requests, as it operates with the connection pool, such as during a migration, where connection requests are redirected to the database driver to cause the connection pool to send requests to the second database location, as disclosed by Duan.
The motivation for doing so would have been because database drivers, such as JDBC, are software that is used for communications with a database system and since they are meant to handle requests, as disclosed by Duan above, it would be efficient to also have it maintain the mapping table, which it uses to handle the requests.
Oracle in view of Mordani and Duan does not expressly disclose wherein the client application attaches labels to connections indicative of connect strings, so that the client application can request a connection with a particular label indicative of a particular connect string from the connection pool and (2) wherein the software application switches services to utilize connections to the database locations. However, it is noted that Oracles does disclose service relocation from one node to another. Oracle at pg. 7. de Lavarene is further relied upon here because it is unclear whether Oracle is disclosing the switching of services to connections.
de Lavarene discloses a system and method for connection labeling for use with connection pools. Particular labels are associated with particular connection states, allowing an application to retrieve an already initialized connection from the pool and avoid the cost of re-initialization. De Lavarene at abstract; para. 0022. de Lavarene further discloses particular applications are able to use a callback to specify or set a container, to repurpose a particular connection from one of the tenants or tenant applications to another of the tenants or tenant applications, which has the effect of switching the tenant. de Lavarene at para. 0046.
Oracle, Mordani, Duan, and de Lavarene are analogous art because they are all directed to the same field of endeavor of database systems using a connection pool.
At the time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Oracle in view of Mordani and Duan by adding the features of (1) wherein the client application attaches labels to connections indicative of connect strings, so that the client application can request a connection with a particular label indicative of a particular connect string from the connection pool and (2) wherein the software application switches services to utilize connections to the database locations., as disclosed by de Lavarene.
The motivation for doing so would have been to allow an application to retrieve an already initialized connection from the pool and avoid the cost of re-initialization (De Lavarene at para. 0022) and to repurpose a connection, which saves on connection costs.
In regards to claim 2, Oracle in view of Mordani, Duan, and de Lavarene discloses the system of claim 1, wherein during the draining of existing connections, and a migration of new connections from a first pluggable database at a first container database, to a new location at a second container database, a second pluggable database is opened at the second container database, and client sessions are terminated on the first pluggable database, and are enabled to reconnect to a migrated service associated with the new location. Oracle at pgs. 6-7.12
In regards to claim 3, Oracle in view of Mordani, Duan, and de Lavarene discloses the system of claim 1, wherein a system event is used to inform the connection pool that the database location originally associated with the tenant is shutting down, and to close its associated connections and prepare for migration to a new database service associated with the new database location. Oracle at pgs. 7, 12.13
In regards to claim 7, Oracle discloses a method for providing access to a database in a multi-tenant environment, including the use of a connection pool, and support for dynamic relocation of tenants (Oracle at pg. 4), comprising:
a. providing, at a computer including a processor, and at least one of an application server or database environment executing thereon (Oracle at pg. 4), a connection pool that includes connection objects and that receives requests from software applications to request a connection from the connection pool, and use a provided connection to access a database (Oracle at pg. 4)14, wherein the database environment includes a container database and a plurality of database locations provided as pluggable databases, wherein the database locations are associated with one or more listeners that provide access via the connections to the database locations (Oracle at pg. 415, pgs. 6-716);
b. wherein the application server or database environment hosts a multi-tenant software application that provides access to the database environment through one or more services associated with the database locations (Oracle at pgs. 4-5)17 and a database driver (Oracle at pgs. 6-7)18;
d. wherein each database location, of the plurality of database locations, is associated with one or more tenants accessing the multi-tenant software application via one or more of the services, wherein each particular tenant is associated with its own particular pluggable database at the container database, and can use connections provided by the connection pool to access the particular pluggable database associated with that tenant, via a database service associated with the particular pluggable database (Oracle at pgs. 4-5)19;
e. wherein, in response to receiving an instruction to migrate a data source associated with a tenant, from a first database location within the plurality of database locations to a second database location within the plurality of database locations, the connection pool causes the tenant associated with the client application, to be relocated within the plurality of database locations (Oracle at pg. 6)20 including:
i. controlling draining of existing connections to the first database location originally associated with the tenant, including draining connections that are associated with an original pluggable database location and its associated database service and relocating the availability of those connections to a new pluggable database location and associated database service (Oracle at pgs. 4, 7-8)21, and
ii. forwarding requests associated with the existing or new connections to the second database location associated with the tenant (Oracle at pgs. 7-8)22,
iii. wherein during migration of the data source, the connection pool operates to route the connection requests to database locations associated with the client applications, including that a listener associated with the plurality of database locations including the first and second database locations is configured to send redirects to the connection pool to send the requests associated with the existing or new connections to the second database location (Oracle at pgs. 6-7)23;
Oracle does not expressly disclose (1) wherein client applications specify connections to the database by associating connect strings with connection requests, (2) a mapping of tenants to the services, wherein the system maintains a mapping of each particular tenant to a particular data source at the database locations and wherein the multi-tenant software application is adapted to make connection results associated with a tenant’s data source, (3) maintains a topology layer which over a period of time learns and caches key ranges associated with the tenants database locations for use with the connection pool, (4) wherein a client application associated with a tenant operates to provide, as part of the connect string associated with a connection request, one or more keys to the connection pool in association with the connection request, (5) wherein based on comparing the one or more keys provided by the client application as part of the connect string associated with the connection request, with the key range cached in the topology layer, the connection pool routes the connection request to a database location associated with that client application, and (6) topology layer to send connection requests using the connect string having one or more keys, and wherein the client application associated with the tenant continues to use its connect string to connect to the tenant’s data source upon its relocation to the second database location. It is noted that Oracle discloses each database has at least a default service. Additional services are also created for each database. Oracle at pg. 5. Oracle does not expressly disclose the topology layer and one or more cached keys feature and using them to request new connections with the connect string.
Mordani discloses and system and method for supporting a multitenant database system for access by tenants using applications over the cloud of another environment. Mordani at abstract. Mordani discloses resources, such as databases, are partitioned and a mapping is provided that maps particular partitions to particular tenants for services (i.e., mapping of tenants to the services, wherein the system maintains a mapping of each particular tenant to a particular data source at the database locations and wherein the multi-tenant software application is adapted to make connection results associated with a tenant’s data source). Mordani at paras. 0015-16, 0018, 0051. As discussed, Mordani discloses a mapping (i.e., maintains a topology layer), which is maintained (i.e., over a period of time learns and caches) with partition IDs (i.e., one or more keys) and connections for a particular tenant (i.e., maintains a topology layer which over a period of time learns and caches key ranges associated with the tenants database locations). The mapping also allows the system to provide an existing connection already associated with the tenant to service the request, but can create a new one if one does not exist. Mordani at para. 0101. Mordani further discloses tenants making a connection request provide a partition ID (i.e., one or more keys), which is used to connect a tenant user to the correct partition (i.e., wherein a client application associated with a tenant is operable to provide one or more keys to the connection pool in association with a connection request, and based on comparison with the one or more keys cached in the topology layer, the connection pool routes the connection request to a database location associated with that client application; the connect string having one or more keys). Mordani at para. 0073. In this way, the same “connect string” is used to connect to a tenant’s data source. Mordani also provides connection switching (i.e., a feature to switch services to utilize connections to the database locations). Mordani at para. 0073. Since there is a mapping to determine the appropriate database partition, services for that database are also mapped to the tenant for that database, which is in accordance with services assigned to a database as disclosed by Oracle. Thus, Mordani discloses a partition mapping (i.e. topology layer) and partition IDs (i.e., one or more keys), which are both used in requesting new connections (i.e., connection string having one or more keys associated with the tenant’s data source) and reusing connections.
Oracle and Mordani are analogous art because they are both directed to the same field of endeavor of database systems and handling of database connection requests.
At a time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Oracle by adding the features of (1) wherein client applications specify connections to the database by associating connect strings with connection requests, (2) a mapping of tenants to the services, wherein the system maintains a mapping of each particular tenant to a particular data source at the database locations and wherein the multi-tenant software application is adapted to make connection results associated with a tenant’s data source, (3) maintains a topology layer which over a period of time learns and caches key ranges associated with the tenants database locations for use with the connection pool, (4) wherein a client application associated with a tenant operates to provide, as part of the connect string associated with a connection request, one or more keys to the connection pool in association with the connection request, (5) wherein based on comparing the one or more keys provided by the client application as part of the connect string associated with the connection request, with the key range cached in the topology layer, the connection pool routes the connection request to a database location associated with that client application, and (6) topology layer to send connection requests using the connect string having one or more keys, and wherein the client application associated with the tenant continues to use its connect string to connect to the tenant’s data source upon its relocation to the second database location, as disclosed by Mordani.
The motivation for doing so would have been to provide service to a large number of users or tenants over distributed environments. Mordani at para. 0014.
Oracle in view of Mordani does not expressly disclose (1) a database driver that maintains the topology layer and database driver specifically manages all connection requests, as it operates with the connection pool, such as during a migration, where connection requests are redirected to the database driver to cause the connection pool to send requests to the second database location. It is noted that both Oracle and Mordani disclose database drivers, such as JDBC (Oracle at pg 8; Mordani at paras. 0042, 0047, 0049). However, it is not expressly disclosed that the database driver manages the topology and manages connection requests.
Duan discloses a system and method for managing connection requests to a partitioned database. The system is at least partially implemented using a database driver, such as JDBC. The system manages a metadata repository that stores a partition key mapping table that maps partitions to tenants. The request processing is performed by the database driver. Duan at Fig. 1; paras. 0017-18, 0035.
Oracle, Mordani, and Duan are analogous art because they are directed to the same field of endeavor of database request management.
At the time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Oracle in view of Mordani by adding the features of a database driver that maintains the topology layer and database driver specifically manages all connection requests, as it operates with the connection pool, such as during a migration, where connection requests are redirected to the database driver to cause the connection pool to send requests to the second database location, as disclosed by Duan.
The motivation for doing so would have been because database drivers, such as JDBC, are software that is used for communications with a database system and since they are meant to handle requests, as disclosed by Duan above, it would be efficient to also have it maintain the mapping table, which it uses to handle the requests.
Oracle in view of Mordani and Duan does not expressly disclose wherein the client application attaches labels to connections indicative of connect strings, so that the client application can request a connection with a particular label indicative of a particular connect string from the connection pool and (2) wherein the software application switches services to utilize connections to the database locations. However, it is noted that Oracles does disclose service relocation from one node to another. Oracle at pg. 7. de Lavarene is further relied upon here because it is unclear whether Oracle is disclosing the switching of services to connections.
de Lavarene discloses a system and method for connection labeling for use with connection pools. Particular labels are associated with particular connection states, allowing an application to retrieve an already initialized connection from the pool and avoid the cost of re-initialization. De Lavarene at abstract; para. 0022. de Lavarene further discloses particular applications are able to use a callback to specify or set a container, to repurpose a particular connection from one of the tenants or tenant applications to another of the tenants or tenant applications, which has the effect of switching the tenant. de Lavarene at para. 0046.
Oracle, Mordani, Duan, and de Lavarene are analogous art because they are all directed to the same field of endeavor of database systems using a connection pool.
At the time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Oracle in view of Mordani and Duan by adding the features of (1) wherein the client application attaches labels to connections indicative of connect strings, so that the client application can request a connection with a particular label indicative of a particular connect string from the connection pool and (2) wherein the software application switches services to utilize connections to the database locations., as disclosed by de Lavarene.
The motivation for doing so would have been to allow an application to retrieve an already initialized connection from the pool and avoid the cost of re-initialization (De Lavarene at para. 0022) and to repurpose a connection, which saves on connection costs.
Claims 8 and 9 are essentially the same as claims 2 and 3, respectively, in the form of a method. Therefore, they are rejected for the same reasons.
Claim 13 is essentially the same as claim 7 in the form of a non-transitory computer readable storage medium including instructions (Oracle at pg. 4 “memory”). Therefore, it is rejected for the same reasons.
In regards to claim 21, Oracle in view of Mordani, Duan, and de Lavarene discloses the system of claim 1, wherein the connection pool operates with a sharded database (Duan at para. 0017)24, including that:
a. the client application provides the one or more keys, said one or more keys including a shard key, during connection checkout or at a later time (Duan at paras. 0017-18, 0035)25; and
b. the shard key is used by the connection pool to provide a connection by the client application to a particular shard or chunk at the sharded database. Duan at paras. 0017-18, 0035.26
In regards to claim 22, Oracle in view of Mordani, Duan, and de Lavarene discloses the system of claim 21, wherein the connection pool identifies a connection to a particular shard or chunk by its shard key, and allows re-use of a connection when a request associated with a same shard key is received from a particular client application. Mordani at para. 0101; Duan at paras. 0017-18, 0035, 0047.27
In regards to claim 23, Oracle in view Mordani, Duan, and de Lavarene discloses the method of claim 7, wherein the connection pool operates with a sharded database, including that:
a. the client application provides the one or more keys, said one or more keys including a shard key during connection checkout or at a later time (Duan at paras. 0017-18, 0035)28; and
b. the shard key is used by the connection pool to provide a connection by the client application to a particular shard or chunk at the sharded database (Duan at paras. 0017-18, 0035)29;
c. wherein the connection pool identifies a connection to a particular shard or chunk by its shard key, and allows re-use of a connection when a request associated with a same shard key is received from a particular client application (Mordani at para. 0101; Duan at paras. 0017-18, 0035, 0047)30;
d. wherein the database driver maintains the topology layer as a shard topology layer which over a period of time learns and caches shard key ranges to the location of each shard in a sharded database (Duan at paras. 0017-18)31; and
e. wherein the client application provides one or more shard keys to the connection pool during the connection request, and based on the one or more shard keys, and information provided by the shard topology layer, the connection pool routes the connection request to a correct or appropriate shard.
In regards to claim 24, Oracle in view of Mordani, Duan, and de Lavarene discloses the system of claim 21, wherein the database driver maintains a shard topology layer which over a period of time learns and caches shard key ranges to the location of each shard in a sharded database. (Duan at paras. 0017-18)32.
In regards to claim 25, Oracle in view of Mordani, Duan, and de Lavarene, discloses the system of claim 24, wherein the client application can provide one or more shard keys to the connection pool during a connection request, and, based on the one or more shard keys, and information provided by the shard topology layer, the connection pool routes the connection request to a correct or appropriate shard. Duan at paras. 0017-18, 0035, 0047.33
In regards to claim 28, Oracle in view of Mordani, Duan, and de Lavarene discloses the system of claim 1, wherein the database locations are associated with a plurality of listeners that provide access via the connections to a sharded database (Mordani at para. 0073)34, including:
a. a first shard director or listener associated with a first database region (Mordani at para. 0073); and
b. a second shard director or listener associated with the second database region (Mordani at para. 0073) 35;
c. wherein the database driver maintains a shard topology layer which over a period of time learns and caches shard key ranges to the location of each shard in the sharded database comprising the first and second database regions, to provide re-use of a connection when a request associated with a same shard key is received from a particular client application. (Mordani at para. 0101; Duan at paras. 0017-18, 0035, 0047)36
Claims 20, 27, 29, 30, 32, and 33 are rejected under 35 U.S.C. 103 as being unpatentable over Oracle (“Database Live Migration with Oracle Multitenant and the Oracle Universal Connection Pool (UCP) on Oracle Real Application Clusters (RAC)”, October 2014) of record, in view of Mordani et al. (US Patent Pub 2015/027758) (Mordani), Duan et al. (US Patent Pub 2011/0055151) (Duan), and de Lavarene (US Patent Pub 2014/0324911) (de Lavarene) of record, further in view of Hussain et al. (“Expert Oracle RAC 12c”, 2013) (Hussain) of record.
In regards to claim 20, Oracle in view of Mordani, Duan, and de Lavarene discloses the system of claim 2, but does not expressly disclose wherein the multi-tenant software application identifies the string which points to a listener associated with the first container database; wherein the listener is configured to redirect connection requests to the new location at the second container database; whereupon the connect string is included in requests for new connections to the new location at the second container database.
It is noted that Mordani does disclose providing a partition ID in the connection request. Mordani at para. 0073. It is also noted Oracle discloses multiple container databases and a service listener. Oracle at pg. 7.
Hussain discloses and Oracle database RAC implementation, which can be used with multi-tenant database RAC nodes. Hussain at pg. 195, third bullet. Hussain further discloses an application providing a connection string that specifies a service as a connection property, which is received by a listener associated with the database system. Hussain at pg. 70. The listener redirects the connection to a difference instance (i.e., new location at the second container database), where a new database connection process is created and application processing continues by communicating to the connection process (i.e., whereupon the connection string is included in requests for new connections). Hussain at pg. 70.
Oracle, Mordani, Duan, de Lavarene, and Hussain are analogous art because they are all directed to the same field of endeavor of database systems utilizing a connection pool.
As discussed above, Oracle discloses the first and second container databases and a listener associated with both. Mordani discloses using partition ID in a connection request as discussed above. Hussain discloses the features of a listener receiving a connection string as part of a request from a multi-tenant software application, the listener redirecting the connection to the new location at the second container database, where the connection string is included in requests for new connections to the new location at the second container database.
At the time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Oracle in view of Mordani, Duan, and de Lavarene by adding the features of wherein the multi-tenant software application identifies the connect string which points to a listener associated with the first container database; wherein the listener is configured to redirect connection requests to the new location at the second container database; whereupon the connect string is included in requests for new connections to the new location at the second container database, as disclosed by Hussain.
The motivation for doing so would have been because Oracle already discloses migrating pluggable databases from one container database to another and in doing so, relocating services and reconnecting clients to the target node (i.e., new location at the second container database). Oracle at pgs. 6-7. Hussain adds more disclosure with regard to the connection string and a listener that is expressly disclosed to redirect connections. As a result, the combination of Oracle in view of Mordani, de Lavarene, and Hussain discloses the limitations recited in claim 20.
In regards to claim 27, Oracle in view of Mordani, Duan, and de Lavarene discloses the system of claim 1,
a. wherein the client application is a shard-aware client application (Mordani at paras. 0073, 0101)37;
b. wherein when a database operation is required, the shard-aware client application determines a shard to which it needs to connect (Mordani at paras. 0016, 0073, 0101)38;
c. wherein the connection pool identifies a connection to a particular shard or chunk by its shard keys, and allows re-use of a connection when a request associated with a same shard key is received from a particular client application, including when the shard-aware client application provides one or more shard keys to the connection pool, in association with a connection request; then, if the connection pool or database driver has a mapping for the shard keys, the connection request is directly forwarded to the appropriate shard and chunk (Mordani at paras. 0016, 0073, 0101)39; and
Oracle in view of Mordani, Duan, and de Lavarene does not expressly disclose wherein upon an instruction received to migrate a pluggable database associated with a tenant, from a first container database instance, to a new location at a second container database instance, the shard-aware client application operates to reconnect to a migrated service associated with the new location, without a need to change their connect string.
Hussain discloses and Oracle database RAC implementation, which can be used with multi-tenant database RAC nodes. Hussain at pg. 195, third bullet. Hussain further discloses an application providing a connection string that specifies a service as a connection property, which is received by a listener associated with the database system. Hussain at pg. 70. The listener redirects the connection to a difference instance (i.e., new location at the second container database), where a new database connection process is created and application processing continues by communicating to the connection process (i.e., whereupon the connection string is included in requests for new connections). Hussain at pg. 70.
Oracle, Mordani, Duan, de Lavarene, and Hussain are analogous art because they are all directed to the same field of endeavor of database systems utilizing a connection pool.
As discussed above, Oracle discloses the first and second container databases and a listener associated with both. Mordani discloses using partition ID in a connection request as discussed above. Hussain discloses the features of a listener receiving a connection string as part of a request from a multi-tenant software application, the listener redirecting the connection to the new location at the second container database, where the connection string is included in requests for new connections to the new location at the second container database.
At the time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Oracle in view of Mordani, Duan, and de Lavarene by adding the features of wherein upon an instruction received to migrate a pluggable database associated with a tenant, from a first container database instance, to a new location at a second container database instance, the shard-aware client application operates to reconnect to a migrated service associated with the new location, without a need to change their connect string, as disclosed by Hussain.
The motivation for doing so would have been because Oracle already discloses migrating pluggable databases from one container database to another and in doing so, relocating services and reconnecting clients to the target node (i.e., new location at the second container database). Oracle at pgs. 6-7. Hussain adds more disclosure with regard to the connection string and a listener that is expressly disclosed to redirect connections. As a result, the combination of Oracle in view of Mordani, de Lavarene, and Hussain discloses the limitations recited in claim 27.
In regards to claim 29, Oracle in view of Mordani, Duan, and de Lavarene disclose the system of claim 28, but does not expressly disclose wherein upon a service associated with a tenant data source being migrated from the first database location to the second database location, client applications can reconnect to the second database location and migrated service by requesting connections associated with the same connect string.
Hussain discloses and Oracle database RAC implementation, which can be used with multi-tenant database RAC nodes. Hussain at pg. 195, third bullet. Hussain further discloses an application providing a connection string that specifies a service as a connection property, which is received by a listener associated with the database system. Hussain at pg. 70. The listener redirects the connection to a difference instance (i.e., new location at the second container database), where a new database connection process is created and application processing continues by communicating to the connection process (i.e., whereupon the connection string is included in requests for new connections). Hussain at pg. 70.
Oracle, Mordani, Duan, de Lavarene, and Hussain are analogous art because they are all directed to the same field of endeavor of database systems utilizing a connection pool.
As discussed above, Oracle discloses the first and second container databases and a listener associated with both. Mordani discloses using partition ID in a connection request as discussed above. Hussain discloses the features of a listener receiving a connection string as part of a request from a multi-tenant software application, the listener redirecting the connection to the new location at the second container database, where the connection string is included in requests for new connections to the new location at the second container database.
At the time before the effective filing date of the instant application, it would have been obvious to one of ordinary skill in the art to modify Oracle in view of Mordani, Duan, and de Lavarene by adding the features of wherein upon a service associated with a tenant data source being migrated from the first database location to the second database location, client applications can reconnect to the second database location and migrated service by requesting connections associated with the same connect string, as disclosed by Hussain.
The motivation for doing so would have been because Oracle already discloses migrating pluggable databases from one container database to another and in doing so, relocating services and reconnecting clients to the target node (i.e., new location at the second container database). Oracle at pgs. 6-7. Hussain adds more disclosure with regard to the connection string and a listener that is expressly disclosed to redirect connections.
In regards to claim 30, Oracle in view of Mordani, Duan, and de Lavarene discloses the system of claim 1, but does not expressly disclose wherein upon migration, for an application that is currently using a connect string which points to a listener of an original container database, the listener is configured to redirect connection requests to a new container database, which causes the listener to send a redirect to the da