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 database driver at the application server, which in turn causes the database driver to send the new connection requests to the new 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 upon migration, for an application that is currently using a connection 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 database driver at the application server, which in turn causes the database driver to send the new connection requests to the new 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 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 30.
Claim 32 is essentially the same as claim 27 in the form of a method. Therefore, it is rejected for the same reasons.
In regards to claim 33, 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)40, 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) 41;
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)42
Oracle in view of Mordani, Duan, and de Lavarene 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.
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) (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 Shivarudraiah et al. (US Patent Pub 2014/0379756) (Shivarudraiah).
In regards to claim 31, Oracle in view of Mordani, Duan, and de Lavarene discloses the system of claim 1, but does not expressly disclose wherein the system utilizes server-side connection pool tagging that allows application to selectively obtain a connection to a database environment based on use of a tag that is understood by that database environment, wherein the tag is associated per connection, which is matched by the database server.
Shivarudraiah discloses a system and method for managing a connection pool for database access. The system provides a server side connection pool that enables tagging of connections, which allow the tagged connection to be made available for subsequent use by the same or other applications. Shivarudraiah at Fig. 1; paras. 0028, 0045, 0063.
Oracle, Mordani, Duan, de Lavarene, and Shivarudraiah are analogous art because they are directed to the same field of endeavor of database connection 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, Duan, and de Lavarene by adding the features of wherein the system utilizes server-side connection pool tagging that allows application to selectively obtain a connection to a database environment based on use of a tag that is understood by that database environment, wherein the tag is associated per connection, which is matched by the database server, as disclosed by Shivarudraiah.
The motivation for doing so would have been to enable connection reuse with a tag, even if the requester is a different client or application. Shivarudraiah at para. 0045.
Response to Amendment
Rejection of Claims 6 and 19 under 35 U.S.C 112(d)
Claims 6 and 19 are cancelled rendering their rejections moot.
Response to Arguments
Rejection of claims 1-3, 6-9, 13, 19, 21-25, and 28 under 35 U.S.C. 103
Claims 6 and 19 are cancelled rendering their rejections moot.
Applicant’s arguments in regards to the rejections to claims 1-3, 7-9, 13, 21-25, and 28 under 35 U.S.C. 103, have been fully considered but they are not persuasive. In regards to claim 1, Applicant alleges Oracle in view of Mordani, Duan, and de Lavarene fails to disclose (1) “wherein an application server or database environment hosts a multi-tenant software application that provides access to the application server or database environment through one or more services associated with the database locations,” (2) “a mapping of tenants to the services,” (3) “the use of a connection pool that operates with a database driver to route connection requests to database locations associated with client applications”, and (4) “the database driver maintains a topology layer which over a period of time learns and caches key ranges associated with the tenants database locations.” Remarks at 19. Applicant argues that while Duan describes the use of a metadata repository for routing a database operation to a particular data partition, it does so by comparing SQL statements of a current request to SQL statements registered in the metadata repository, whereas the claim recites key ranges are associated with tenant database locations, for use with a connection pool, wherein a client application associated with a tenant operates to provide, as part of a connect string associated with a connection request, one or more keys to the connection pool in association with the connection request, and 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 a key range cached in the topology layer, the connection pool routes the connection request to a database location associated with that client application. Remarks at 19. Examiner respectfully disagrees.
Examiner is required to give claim limitations their broadest reasonable interpretation in light of the specification. However, limitations from the specification are not read into the claims. MPEP 2111.
In regards to limitation (1), Applicant does not seem to explain why the limitation is not disclosed by Duan. Duan discloses a system that serves multiple tenants. The system comprises an application server and a partitioned database system that is managed by a database driver or some other type of database wrapper. Duan at para. 0017. The system provides tenants with the ability to make database operations to their data on a particular partition. Duan at paras. 0018, 0023. In this way, Duan discloses providing access to a service associated with database locations. Thus, Duan discloses either of the application server or the database environment that hosts a multi-tenant software application to provide access to services associated with the database locations. It is also noted that Oracle and Mordani discloses much of these limitations as well, as set forth in the rejection above.
In regards to limitation (2), Applicant argues with regards to Duan but the limitation is rejected by Mordani as set forth in the rejection above. Mordani discloses partitions, which include a resource group. A resource group has a resource group template, which defines what applications and resources are associated with the resource group and associated partition. This can include pluggable databases, which can be assigned to specific partitions. In doing so, the partition specific PDB can be used by the application server to configure resources, such as a container database, and for use by the partition. Mordani at paras. 0032-33. Duan also discloses a mapping stored in a metadata repository. The mapping maps partition keys and database partitions. The metadata repository can also include an affected data scope table and a special tenants list, which maps tenants and their data to particular partitions. Duan at paras. 0017-18. For these reasons, both Mordani and Duan disclose a mapping of tenants to services.
In regards to limitation (3), Applicant does not seem to present specific arguments to distinguish this limitation from the cited art. All of the cited references disclose some form of connection management to route requests to the appropriate destination. Oracle discloses a connection pool to provide connections access to a database. Oracle at pg. 4. Mordani also provides a connection pool in a multi-tenant database system where requests can be routed to particular partitions based on keys included within the request. Mordani at para. 0101. Both Oracle and Mordani disclose some use of a JDBC driver (i.e., database driver) as set forth in the rejection above. Lastly, Duan discloses a database system that is managed by a database driver or wrapper, such as JDBC. Duan at para. 0017. As discussed above, Duan discloses a mapping that is used to route tenant requests to the appropriate partition. As explained in the rejection above, Duan is relied upon for express disclosure of a database system being managed by a database driver. This includes handling its requests and routing them to appropriate locations.
In regards to limitation (4), as discussed in the rejection above Mordani discloses a topology layer that learns over time and caches key ranges associated with tenants database locations. Mordani at paras. 0073, 0101. Duan is relied upon for expressly disclosing a database driver that manages the topology. Duan discloses a database system managed by a database driver. Duan at para. 0017. Duan also discloses a metadata repository in the database system that stores a partition mapping table, a tenant list, and an affected data scope table, which determines which partition a tenant is associated with (i.e., tenant location) based on their request, history of requests, and data. Duan at paras. 0018, 0020-21. Since the mappings and tables stored in the metadata repository changes as requests are received or based on analyzed statistics (e.g., history of requests), it is interpreted that the mapping (i.e., topology layer) learns over a period of time and stores (i.e., caches) partition key associations with tenants and tenant data. In response to Applicant’s argument that Duan does not route requests 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 a key range cached in the topology layer, the connection pool routes the connection request to a database location associated with that client application, Duan does compare an assigned key to route a request to the appropriate partition after analyzing the tenant request. Duan at paras. 0022-23. It is further noted that Mordani also discloses a mapping that is utilized to route a tenant request using a key included in the tenant request. Mordani at paras. 0073, 0101. As discussed in the rejection above, Duan is primarily relied upon for its disclosure of managing the database system with a database driver, where the database system is multitenant and includes mappings of partitions to tenants, which is utilized to route tenant requests.
For at least the reasons explained above, Examiner asserts Oracle in view of Mordani, Duan, and de Lavarene discloses the limitations at issue. Applicant does not present additional arguments with regards to the remaining limitations. Therefore, Examiner asserts the cited prior art discloses all the limitations of claim 1 for the reasons explained above. In regards to the remaining claims, Applicant refers to the arguments presented in regards to claim 1, which are addressed above. Consequently, the rejection to claims 1-3, 7-9, 13, 21-25, and 28 under 35 U.S.C. 103 is maintained.
Rejection of claims 20, 27, 29, and 30 under 35 U.S.C. 103
Applicant does not present specific arguments in regards to the rejections to claims 20, 27, 29, and 30 under 35 U.S.C. 103. Therefore, their rejections are maintained for at least the same reasons explained above.
Rejection of claim 31 under 35 U.S.C. 103
Applicant does not present specific arguments in regards to the rejection to claim 31 under 35 U.S.C. 103. Therefore, their rejections are maintained for at least the same reasons explained above.
Additional Prior Art
Additional relevant prior art are listed on the attached PTO-892 form. Some examples are:
Hutchinson et al. (US Patent Pub 2008/0319967) discloses a system and method for executing a database query in a database having a partition schema.
Joshi et al. (US Patent Pub 2016/0292236) discloses a system and method for supporting multi-tenant applications in a sharded database.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Examiner Michael Le whose telephone number is 571-272-7970 and fax number is 571-273-7970. The examiner can normally be reached Mon-Fri 9:30 AM – 6 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Tony Mahmoudi can be reached on 571-272-4078. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL LE/Examiner, Art Unit 2163
/TONY MAHMOUDI/Supervisory Patent Examiner, Art Unit 2163
1 Previously cited on PTO-892 form mailed 4/30/2021.
2 The connection pool enables connection management for providing connections to databases.
3 Oracle 12c discloses a new database consolidation model which uses multiple pluggable databases consolidated within a container database.
4 New incoming connection requests are automatically established at the new database location after migration, instead of the original location. This is interpreted as the system having a listener that automatically redirects requests to the new database location. Oracle also discloses JDBC, which is a database driver. Oracle discloses the process is transparent to the application/user.
5 Oracle discloses a multi-tenant environment with software to access the database environment. Access is through the use of Oracle Net Services (i.e., services).
6 Oracle discloses JDBC (i.e., database driver).
7 Oracle discloses a RAC, which includes a cluster of nodes running databases (i.e., a plurality of database locations). Oracle also discloses the system is multi-tenant, which would mean that each tenant is associated with at least one database source (i.e., … can be associated with one or more tenants). The system also utilizes pluggable databases in a container database. The RAC allows service relocation capabilities for tenants among the PDBs (i.e., each tenant associated with a particular pluggable database … use connections provided by the connection pool … via a database service associated with the particular PDB).
8 Live migration and service relocation uses the connection pool to relocate tenants to another database location on a target node. Therefore, it is “in response” to database migration.
9 Service relocation involves draining of existing connections to the current database location and relocating them to a new database location.
10 Service relocation migrates new connections to the new database, which has been migrated to the target node.
11 New incoming connection requests are automatically established at the new database location after migration, instead of the original location. This is interpreted as the system having a listener that automatically redirects requests to the new database location. Oracle also discloses JDBC, which is a database driver. Oracle discloses the process is transparent to the application/user (i.e., application is not required to change the request).
12 As outlined on pgs. 6-7, the pluggable database is migrated from a source node to the target node, while connections are managed and service is relocated to the new database locations.
13 The notification service allows clients to receive notifications of system events, such as when a service is shutting down and is migrated to a new database location.
14 The connection pool enables connection management for providing connections to databases.
15 Oracle 12c discloses a new database consolidation model which uses multiple pluggable databases consolidated within a container database.
16 New incoming connection requests are automatically established at the new database location after migration, instead of the original location. This is interpreted as the system having a listener that automatically redirects requests to the new database location. Oracle also discloses JDBC, which is a database driver. Oracle discloses the process is transparent to the application/user (i.e., application is not required to change the connect string with the data source instance).
17 Oracle discloses a multi-tenant environment with software to access the database environment. Access is through the use of Oracle Net Services (i.e., services).
18 Oracle discloses JDBC (i.e., database driver).
19 Oracle discloses a RAC, which includes a cluster of nodes running databases (i.e., a plurality of database locations). Oracle also discloses the system is multi-tenant, which would mean that each tenant is associated with at least one database source (i.e., … can be associated with one or more tenants). The system also utilizes pluggable databases in a container database. The RAC allows service relocation capabilities for tenants among the PDBs (i.e., each tenant associated with a particular pluggable database … use connections provided by the connection pool … via a database service associated with the particular PDB).
20 Live migration and service relocation uses the connection pool to relocate tenants to another database location on a target node. Therefore, it is “in response” to database migration.
21 Service relocation involves draining of existing connections to the current database location and relocating them to a new database location.
22 Service relocation migrates new connections to the new database, which has been migrated to the target node.
23 New incoming connection requests are automatically established at the new database location after migration, instead of the original location. This is interpreted as the system having a listener that automatically redirects requests to the new database location. Oracle also discloses JDBC, which is a database driver. Oracle discloses the process is transparent to the application/user (i.e., application is not required to change the request).
24 The database is partitioned (i.e., sharded database).
25 A partition key is provided during processing of the request
26 The partition key is utilized to direct a client’s request to a connection to the appropriate partition of the database.
27 The partition key enables mapping to a particular partition (i.e., shard), which is a resource of the database. Mordani’s partitioning allows mapping of particular PDBs (i.e., database locations) and reuse of partition IDs to reuse connections.
28 A partition key is provided during processing of the request
29 The partition key is utilized to direct a client’s request to a connection to the appropriate partition of the database.
30 The partition key enables mapping to a particular partition (i.e., shard), which is a resource of the database. Mordani’s partitioning allows mapping of particular PDBs (i.e., database locations) and reuse of partition IDs to reuse connections.
31 A database driver is used to partially implement the environment including a metadata repository that stores partition key mappings between partitions and tenants.
32 A database driver is used to partially implement the environment including a metadata repository that stores partition key mappings between partitions and tenants.
33 Based on the provided partition key, the request is directed to the appropriate shard based on the partition key mapping (i.e., shard topology layer).
34 A request is made to the system and based on partition ID, the system is able to relocate a request to the correct connection before performing a request.
35 The system is able to route requests based on contextual partition ID (i.e., connect string). Therefore it is interpreted as having some type of listener.
36 The partition key enables mapping to a particular partition (i.e., shard), which is a resource of the database. Mordani’s partitioning allows mapping of particular PDBs (i.e., database locations) and reuse of partition IDs to reuse connections.
37 The client makes a request providing a partition ID so it can be routed to the correct partition (i.e., shard). Therefore it is interpreted as being shard aware.
38 The mapping is used to route a request to the correct partition (i.e., determines a share to which it needs to connect).
39 The mapping provides an existing connection or creates a new one if needed.
40 A request is made to the system and based on partition ID, the system is able to relocate a request to the correct connection before performing a request.
41 The system is able to route requests based on contextual partition ID (i.e., connect string). Therefore it is interpreted as having some type of listener.
42 The partition key enables mapping to a particular partition (i.e., shard), which is a resource of the database. Mordani’s partitioning allows mapping of particular PDBs (i.e., database locations) and reuse of partition IDs to reuse connections.
Prosecution Insights