Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status
This instant application, No. 19/342,275 has claims 21-40 pending based on the preliminary amendment filed on November 25, 2025.
Priority / Filing Date
Applicant’s claims for priority of parent applications No. 18/753,970 (now pat. No. US 12450261), No. 18/820,079 (now Pat. No. 12468734), No. 18/049,117 (now Pat. No. US 12056138), No. 16/853,572 (now Pat. No. US 11507589) and No. 14/542,353 (now Pat. No. US 10628387) which claim priority of provisional applications No. 61/905439, 61/905460, 61/905457, 61/905826, and 61/905822 are acknowledged. The effective filing date for this application is November 15, 2013.
Abstract
The abstract of the disclosure is acceptable for examination purposes.
Drawings
The drawings filed on September 26, 2025 are acceptable for examination purposes.
Information Disclosure Statement
As required by M.P.E.P. 609(C), the Applicant’s submission of the Information Disclosure Statement filed on November 26, 2025 is acknowledged by the Examiner and the cited references have been considered in the examination of the claims now pending. As required by M.P.E.P. 609 C(2), a copy of each of the PTOL-1449s initialed and dated by the Examiner is attached to the instant Office action.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/forms/. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 21-40 are rejected on the ground of nonstatutory double patenting over claims 1-20 of Pat. No. US 12468734, claims 1-20 of Pat. No. US 12450261, claims 1-12 of Pat. No. US 12056138, claims 1-14 of Pat. No. US 11507589, claims 1-20 of Pat. No. US 10628387, and claims 1-12 of Pat. No. US 10176235.
a. Claims 21-40 of the instant application recite similar limitations and claims 1-20 of ‘734 as being compared in the table below. For the purpose of illustration, only claims 21-27 of the instant application is compared with other conflicting claims (underlining is used to indicate conflicting limitations). The remaining claims of the instant application are different variations (system and non-transitory medium claims) and are therefore not compared in the table below:
Instant Application
Pat. No. US 12.468,734
Claim 21
A method, comprising:
obtaining, by a data retention system implemented via a database system, a data retention policy associated with a tenant of a multitenant computing environment, the data retention policy indicating one or more parameters associated with temporal attributes of data to be copied from a relational database to a non-relational database;
copying at least a portion of first data, identified from the relational database based on the data retention policy, to the non-relational database, wherein the copying continues until backup of the first data in the non-relational database is complete;
obtaining a query received via a user interface, the query being received in a relational database language;
using the query received in the relational database language to scan the non-relational database using data of the relational database and data of the non-relational database;
combining results of the query on the non-relational database; and
providing the combined results via the user interface.
Claim 1
A method, comprising:
obtaining a data retention configuration associated with a tenant of a managed relational database service, the data retention configuration indicating one or more parameters defining data to be copied from a relational database to a non-relational database;
processing a job corresponding to first data, the job including the one or more parameters;
copying the first data, identified from the relational database based on the processed job, to the non-relational database;
obtaining a query received via a user interface, the query being received in a relational database language, the query being associated with a plurality of data sources;
running the query, received in the relational database language, to perform multiple parallel scans across the plurality of data sources including the non-relational database;
joining results of the multiple scans on the non-relational database; and
providing the joined results via the user interface.
See Eidson and Harrison below for mapping and motivation(s) to combine with the claims of ‘734.
Claim 22
The method of claim 21, wherein the one or more parameters include: daily backup retention, twice daily backup retention, weekly backup retention, and/or monthly backup retention.
See Blood below for mapping and motivation to combine with the claims of ‘734.
Claim 23
The method of claim 21, wherein the data retention policy specifies how frequently backups are created.
Claim 3
The method of claim 2, further comprising:
automatically storing backup data associated with a first one of the organizations for a retention period specified by an authorized user affiliated with the first organization.
See further Blood below for mapping and motivation to combine with the claims of ‘734.
Claim 24
The method of claim 21, wherein the backup is a background job that is independent of the database system.
Claim 3
The method of claim 2, further comprising:
automatically storing backup data associated with a first one of the organizations for a retention period specified by an authorized user affiliated with the first organization.
See Taylor below for mapping and motivation to combine with the claims of ‘734.
Claim 25
The method of claim 21, further comprising: performing, in parallel, multiple scans of the non-relational database.
Claim 1
…running the query, received in the relational database language, to perform multiple parallel scans across the plurality of data sources including the non-relational database…
Claim 26
The method of claim 21, further comprising: providing, to an application, access to application data stored on a server system of the data retention system, the application data being stored in a non-relational format.
Claim 5
The method of claim 1, wherein the plurality of data sources are stored in relational, non-relational, object, and custom data sources.
Claim 27
The method of claim 21, wherein the non-relational database is stored in a columnar format.
Claim 4
The method of claim 1, wherein the non-relational database is stored in a columnar format.
Although the conflicting claims are not identical, they are not patentably distinct from each other because they are substantially similar in scope and they use the similar limitations to produce the same end result of managing data retention in a multi-tenant environment.
It would have been obvious to a person with ordinary skills in the art at the time of the invention was effectively filed to modify or to omit the additional claim elements of claims 1-20 of ‘734 with the teachings of the cited references below to arrive at the pending claims of the instant application because the person would have realized that the remaining element would perform the same functions as before. “Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before.” See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
b. Claims 21-40 of the instant application recite similar limitations and claims 1-20 of ‘261 as being compared in the table below. For the purpose of illustration, only claims 21-27 of the instant application is compared with other conflicting claims (underlining is used to indicate conflicting limitations). The remaining claims of the instant application are different variations (system and non-transitory medium claims) and are therefore not compared in the table below:
Instant Application
Pat. No. US 12,450,261
Claim 21
A method, comprising:
obtaining, by a data retention system implemented via a database system, a data retention policy associated with a tenant of a multitenant computing environment, the data retention policy indicating one or more parameters associated with temporal attributes of data to be copied from a relational database to a non-relational database;
copying at least a portion of first data, identified from the relational database based on the data retention policy, to the non-relational database, wherein the copying continues until backup of the first data in the non-relational database is complete;
obtaining a query received via a user interface, the query being received in a relational database language;
using the query received in the relational database language to scan the non-relational database using data of the relational database and data of the non-relational database;
combining results of the query on the non-relational database; and
providing the combined results via the user interface.
Claim 1
A method, comprising:
obtaining, by a data retention system implemented via a database system, a data retention policy associated with a tenant of a multitenant computing environment, the data retention policy indicating one or more parameters associated with temporal attributes of data to be copied from a relational database to a non-relational database;
enqueuing a job corresponding to first data, the job including the one or more parameters;
copying at least a portion of the first data, identified from the relational database based on the enqueued job, to the non-relational database, wherein the job is enqueued again until backup of the first data in the non-relational database is complete;
obtaining a query received via a user interface, the query being received in a relational database language;
using the query received in the relational database language to scan the non-relational database using data of the relational database and data of the non-relational database;
combining results of the query on the non-relational database; and
providing the combined results via the user interface.
See Eidson and Harrison below for mapping and motivation(s) to combine with the claims of ‘261.
Claim 22
The method of claim 21, wherein the one or more parameters include: daily backup retention, twice daily backup retention, weekly backup retention, and/or monthly backup retention.
Claim 2
The method of claim 1, wherein the one or more parameters include: daily backup retention, twice daily backup retention, weekly backup retention, and/or monthly backup retention.
Claim 23
The method of claim 21, wherein the data retention policy specifies how frequently backups are created.
Claim 3
The method of claim 1, wherein the data retention policy specifies how frequently backups are created.
Claim 24
The method of claim 21, wherein the backup is a background job that is independent of the database system.
Claim 4
The method of claim 1, wherein the job is a background job that is independent of the database system.
Claim 25
The method of claim 21, further comprising: performing, in parallel, multiple scans of the non-relational database.
Claim 5
The method of claim 1, further comprising:
performing, in parallel, multiple scans of the non-relational database.
Claim 26
The method of claim 21, further comprising: providing, to an application, access to application data stored on a server system of the data retention system, the application data being stored in a non-relational format.
Claim 6
The method of claim 1, further comprising:
providing, to an application, access to application data stored on a server system of the data retention system, the application data being stored in a non-relational format.
Claim 27
The method of claim 21, wherein the non-relational database is stored in a columnar format.
Claim 7
The method of claim 1, wherein the non-relational database is stored in a columnar format.
Although the conflicting claims are not identical, they are not patentably distinct from each other because they are substantially similar in scope and they use the similar limitations to produce the same end result of managing data retention in a multi-tenant environment.
It would have been obvious to a person with ordinary skills in the art at the time of the invention was effectively filed to modify or to omit the additional claim elements of claims 1-20 of ‘261 with the teachings of the cited references below to arrive at the pending claims of the instant application because the person would have realized that the remaining element would perform the same functions as before. “Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before.” See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
c. Claims 21-40 of the instant application recite similar limitations and claims 1-12 of ‘138 as being compared in the table below. For the purpose of illustration, only claims 21-27 of the instant application is compared with other conflicting claims (underlining is used to indicate conflicting limitations). The remaining claims of the instant application are different variations (system and non-transitory medium claims) and are therefore not compared in the table below:
Instant Application
Pat. No. US 12,056,138
Claim 21
A method, comprising:
obtaining, by a data retention system implemented via a database system, a data retention policy associated with a tenant of a multitenant computing environment, the data retention policy indicating one or more parameters associated with temporal attributes of data to be copied from a relational database to a non-relational database;
copying at least a portion of first data, identified from the relational database based on the data retention policy, to the non-relational database, wherein the copying continues until backup of the first data in the non-relational database is complete;
obtaining a query received via a user interface, the query being received in a relational database language;
using the query received in the relational database language to scan the non-relational database using data of the relational database and data of the non-relational database;
combining results of the query on the non-relational database; and
providing the combined results via the user interface.
Claim 1
A method, comprising:
obtaining a data retention configuration associated with a tenant of a multitenant computing environment, the data retention configuration indicating one or more parameters defining data to be copied from a relational database to a non-relational database;
enqueuing a message corresponding to first data, the message including the one or more parameters;
copying at least a chunk of the first data, identified from the relational database based on the enqueued message, to the non-relational database, wherein the message is enqueued again until all of the first data has been copied to the non-relational database;
obtaining a query received via a user interface, the query being received in a relational database language;
transforming the query received in the relational database language to multiple scans using one or more keys of the query; performing the multiple scans on the non-relational database;
merging results of the performed multiple scans on the non-relational database; and
providing the merged results via the user interface.
See further Eidson and Harrison below for mapping and motivation to combine with the claims of ‘138.
Claim 22
The method of claim 21, wherein the one or more parameters include: daily backup retention, twice daily backup retention, weekly backup retention, and/or monthly backup retention.
See Blood below for mapping and motivation to combine with the claims of ‘138.
Claim 23
The method of claim 21, wherein the data retention policy specifies how frequently backups are created.
See Blood below for mapping and motivation to combine with the claims of ‘138.
Claim 24
The method of claim 21, wherein the backup is a background job that is independent of the database system.
See Taylor below for mapping and motivation to combine with the claims of ‘138.
Claim 25
The method of claim 21, further comprising: performing, in parallel, multiple scans of the non-relational database.
Claim 1
…transforming the query received in the relational database language to multiple scans using one or more keys of the query; performing the multiple scans on the non-relational database…
See Harrison below for mapping and motivation to combine with the claims of ‘138.
Claim 26
The method of claim 21, further comprising: providing, to an application, access to application data stored on a server system of the data retention system, the application data being stored in a non-relational format.
See Taylor below for mapping and motivation to combine with the claims of ‘138.
Claim 27
The method of claim 21, wherein the non-relational database is stored in a columnar format.
See Oberhofer below for mapping and motivation to combine with the claims of ‘138.
Although the conflicting claims are not identical, they are not patentably distinct from each other because they are substantially similar in scope and they use the similar limitations to produce the same end result of managing data retention in a multi-tenant environment.
It would have been obvious to a person with ordinary skills in the art at the time of the invention was effectively filed to modify or to omit the additional claim elements of claims 1-12 of ‘138 with the teachings of the cited references below to arrive at the pending claims of the instant application because the person would have realized that the remaining element would perform the same functions as before. “Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before.” See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
d. Claims 21-40 of the instant application recite similar limitations and claims 1-14 of ‘589 as being compared in the table below. For the purpose of illustration, only claims 21-27 of the instant application is compared with other conflicting claims (underlining is used to indicate conflicting limitations). The remaining claims of the instant application are different variations (system and non-transitory medium claims) and are therefore not compared in the table below:
Instant Application
Pat. No. US 11,507,589
Claim 21
A method, comprising:
obtaining, by a data retention system implemented via a database system, a data retention policy associated with a tenant of a multitenant computing environment, the data retention policy indicating one or more parameters associated with temporal attributes of data to be copied from a relational database to a non-relational database;
copying at least a portion of first data, identified from the relational database based on the data retention policy, to the non-relational database, wherein the copying continues until backup of the first data in the non-relational database is complete;
obtaining a query received via a user interface, the query being received in a relational database language;
using the query received in the relational database language to scan the non-relational database using data of the relational database and data of the non-relational database;
combining results of the query on the non-relational database; and
providing the combined results via the user interface.
Claim 1
A method, comprising:
obtaining a data retention configuration associated with a tenant of a multitenant computing environment, the data retention configuration indicating one or more parameters defining data to be copied from a relational database to a non-relational database;
identifying, using the data retention configuration, first data associated with the tenant;
copying the first data from the relational database;
storing the copied first data to the non-relational database in association with a tenant identifier of the tenant;
obtaining a query received via a user interface, the query being received in a relational database language;
transforming the query received in the relational database language to multiple scans, each scan corresponding to a row key range of multiple row key ranges of the non-relational database;
performing the multiple scans on the non-relational database;
merging results of the performed multiple scans on the non-relational database; and
providing the merged results via the user interface.
See Eidson and Harrison below for mapping and motivation(s) to combine with the claims of ‘589.
Claim 22
The method of claim 21, wherein the one or more parameters include: daily backup retention, twice daily backup retention, weekly backup retention, and/or monthly backup retention.
See Blood below for mapping and motivation to combine with the claims of ‘589.
Claim 23
The method of claim 21, wherein the data retention policy specifies how frequently backups are created.
See Blood below for mapping and motivation to combine with the claims of ‘589.
Claim 24
The method of claim 21, wherein the backup is a background job that is independent of the database system.
See Taylor below for mapping and motivation to combine with the claims of ‘589.
Claim 25
The method of claim 21, further comprising: performing, in parallel, multiple scans of the non-relational database.
Claim 1
…transforming the query received in the relational database language to multiple scans, each scan corresponding to a row key range of multiple row key ranges of the non-relational database;
performing the multiple scans on the non-relational database…
See Harrison below for mapping and motivation to combine with the claims of ‘589.
Claim 26
The method of claim 21, further comprising: providing, to an application, access to application data stored on a server system of the data retention system, the application data being stored in a non-relational format.
See Taylor below for mapping and motivation to combine with the claims of ‘589.
Claim 27
The method of claim 21, wherein the non-relational database is stored in a columnar format.
See Oberhofer below for mapping and motivation to combine with the claims of ‘589.
Although the conflicting claims are not identical, they are not patentably distinct from each other because they are substantially similar in scope and they use the similar limitations to produce the same end result of managing data retention in a multi-tenant environment.
It would have been obvious to a person with ordinary skills in the art at the time of the invention was effectively filed to modify or to omit the additional claim elements of claims 1-14 of ‘589 with the teachings of the cited references below to arrive at the pending claims of the instant application because the person would have realized that the remaining element would perform the same functions as before. “Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before.” See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
e. Claims 21-40 of the instant application recite similar limitations and claims 1-20 of ‘387 as being compared in the table below. For the purpose of illustration, only claims 21-27 of the instant application is compared with other conflicting claims (underlining is used to indicate conflicting limitations). The remaining claims of the instant application are different variations (system and non-transitory medium claims) and are therefore not compared in the table below:
Instant Application
Pat. No. US 10,628,387
Claim 21
A method, comprising:
obtaining, by a data retention system implemented via a database system, a data retention policy associated with a tenant of a multitenant computing environment, the data retention policy indicating one or more parameters associated with temporal attributes of data to be copied from a relational database to a non-relational database;
copying at least a portion of first data, identified from the relational database based on the data retention policy, to the non-relational database, wherein the copying continues until backup of the first data in the non-relational database is complete;
obtaining a query received via a user interface, the query being received in a relational database language;
using the query received in the relational database language to scan the non-relational database using data of the relational database and data of the non-relational database;
combining results of the query on the non-relational database; and
providing the combined results via the user interface.
Claim 1
A method of managing data in a multitenant computing environment having a relational database and a non-relational database, the multitenant computing environment having multiple tenants where data for multiple tenants is stored in a single physical database object and tenant data is arranged so that data of one tenant is kept logically separate from that of other tenants so that one tenant does not have access to another tenant's data unless such data is expressly shared, the method comprising:
identifying static data for a plurality of tenants in the multitenant computing environment to be maintained beyond a preselected threshold length of time with one or more server computing devices, wherein parameters to define the static data and the preselected threshold length of time are different for each of the plurality of tenants of the multitenant computing environment, wherein each tenant is a different organization comprising a plurality of users;
copying the static data corresponding to the plurality of tenants from the relational database to the non-relational database;
storing the static data in the non-relational database, wherein the static data in the non-relational database have the same logical separation for each tenant as the tenant data in the relational database;
providing access to the static data from the non-relational database via a user interface that accesses both the relational database and the non-relational database;
transforming a query received via the user interface in a relational database language to a scan for each row key range of multiple row key ranges thereby performing multiple parallel scans of the non-relational database to retrieve result data from the non-relational database corresponding to the query in the relational database language to perform a search of the static data stored in the non-relational database; and
merging results of the multiple parallel scans of data in the non-relational database to present a combined result corresponding to the query received in the relational database language via the user interface.
See Eidson and Harrison below for mapping and motivation(s) to combine with the claims of ‘387.
Claim 22
The method of claim 21, wherein the one or more parameters include: daily backup retention, twice daily backup retention, weekly backup retention, and/or monthly backup retention.
See Blood below for mapping and motivation to combine with the claims of ‘387.
Claim 23
The method of claim 21, wherein the data retention policy specifies how frequently backups are created.
See Blood below for mapping and motivation to combine with the claims of ‘387.
Claim 24
The method of claim 21, wherein the backup is a background job that is independent of the database system.
See Taylor below for mapping and motivation to combine with the claims of ‘387.
Claim 25
The method of claim 21, further comprising: performing, in parallel, multiple scans of the non-relational database.
Claim 1
…transforming a query received via the user interface in a relational database language to a scan for each row key range of multiple row key ranges thereby performing multiple parallel scans of the non-relational database to retrieve result data from the non-relational database corresponding to the query in the relational database language to perform a search of the static data stored in the non-relational database…
Claim 26
The method of claim 21, further comprising: providing, to an application, access to application data stored on a server system of the data retention system, the application data being stored in a non-relational format.
See Taylor below for mapping and motivation to combine with the claims of ‘387.
Claim 27
The method of claim 21, wherein the non-relational database is stored in a columnar format.
See Oberhofer below for mapping and motivation to combine with the claims of ‘387.
Although the conflicting claims are not identical, they are not patentably distinct from each other because they are substantially similar in scope and they use the similar limitations to produce the same end result of managing data retention in a multi-tenant environment.
It would have been obvious to a person with ordinary skills in the art at the time of the invention was effectively filed to modify or to omit the additional elements of claims 1-20 of ‘387 with the teachings of the references cited below to arrive at the pending claims of the instant application for the purpose of allowing static data to be backed up according to an activity policy and providing redundancy for file systems requiring the static data. Further, a person skilled in the art would have realized that the remaining element would perform the same functions as before. “Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before.” See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
f. Claims 21-40 of the instant application recite similar limitations and claims 1-12 of ‘235 as being compared in the table below. For the purpose of illustration, only claims 21-27 of the instant application is compared with other conflicting claims (underlining is used to indicate conflicting limitations). The remaining claims of the instant application are different variations (system and non-transitory medium claims) and are therefore not compared in the table below:
Instant Application
Pat. No. US 10,176,235
Claim 21
A method, comprising:
obtaining, by a data retention system
implemented via a database system, a data retention policy associated with a tenant of a multitenant computing environment, the data retention policy indicating one or more parameters associated with temporal attributes of data to be copied from a relational database to a non-relational database;
copying at least a portion of first data, identified from the relational database based on the data retention policy, to the non-relational database, wherein the copying continues until backup of the first data in the non-relational database is complete;
obtaining a query received via a user interface, the query being received in a relational database language;
using the query received in the relational database language to scan the non-relational database using data of the relational database and data of the non-relational database;
combining results of the query on the non-relational database; and
providing the combined results via the user interface.
Claim 1
A method of managing data in a multitenant environment having a relational database and a non-relational database, the method comprising:
receiving, with one or more server computing systems that provide the multitenant environment, a set of one or more policies for field history data retention corresponding to data stored in a history table in the relational database environment, wherein the policies for data retention are defined on a tenant-by-tenant basis within the multitenant environment, wherein the one or more policies for data retention define what data is to be copied from the relational database to the non-relational database…
storing the data to be copied in the non-relational database while maintaining tenant isolation so that data belonging to the respective tenants is not accessible by other tenants when stored in the non-relational database…; and
providing access to the data from the non-relational database via a user interface that accesses both the relational database and the non-relational database,
wherein searching of the data stored in the non-relational database comprises transforming a query in a relational database language to multiple parallel scans of the non-relational database to retrieve result data and
merging results of the multiple parallel scans to present the result data.
See Eidson and Harrison below for mapping and motivation(s) to combine with the claims of ‘235.
Claim 22
The method of claim 21, wherein the one or more parameters include: daily backup retention, twice daily backup retention, weekly backup retention, and/or monthly backup retention.
See Blood below for mapping and motivation to combine with the claims of ‘235.
Claim 23
The method of claim 21, wherein the data retention policy specifies how frequently backups are created.
See Blood below for mapping and motivation to combine with the claims of ‘235.
Claim 24
The method of claim 21, wherein the backup is a background job that is independent of the database system.
See Taylor below for mapping and motivation to combine with the claims of ‘235.
Claim 25
The method of claim 21, further comprising: performing, in parallel, multiple scans of the non-relational database.
Claim 1
…wherein searching of the data stored in the non-relational database comprises transforming a query in a relational database language to multiple parallel scans of the non-relational database to retrieve result data…
Claim 26
The method of claim 21, further comprising: providing, to an application, access to application data stored on a server system of the data retention system, the application data being stored in a non-relational format.
See Taylor below for mapping and motivation to combine with the claims of ‘235.
Claim 27
The method of claim 21, wherein the non-relational database is stored in a columnar format.
See Oberhofer below for mapping and motivation to combine with the claims of ‘235.
Although the conflicting claims are not identical, they are not patentably distinct from each other because they are substantially similar in scope and they use the similar limitations to produce the same end result of managing data retention in a multi-tenant environment.
It would have been obvious to an ordinary person skilled in the art at the time of the invention was effectively filed to modify or to omit the additional claim elements of ‘235 with the teachings of the references cited below to arrive at the pending claims of the instant application for the purpose of allowing static data to be backed up according to an activity policy and providing redundancy for file systems requiring the static data. Further, a person skilled in the art would have realized that the remaining element would perform the same functions as before. “Omission of element and its function in combination is obvious expedient if the remaining elements perform same functions as before.” See In re Karlson (CCPA) 136 USPQ 184, decide Jan 16, 1963, Appl. No. 6857, U.S. Court of Customs and Patent Appeals.
Notes
Claim 21 recites a method for managing data retention in a multi-tenant environment. The ordered combination of claim elements does not recite mathematical formulas, algorithms, or calculation; it does not manage commercial or financial interactions, legal relations, or fundamental economic practices; nor it is not practically implemented by a human mind with the aid of pen/paper. Specifically, the following claimed elements require concrete, hardware driven database execution that cannot be mentally performed:
Copying selected relational database records to a non-relational database structure until backup completion is verified.
Executing a database scan on the non-relational database using both relational and non-relational data structures in response to a query received in a relational database language.
Combining cross-database query execution results and returning them via a database user interface.
Further, per step 2A (prong 2) of the abstract idea analysis, the ordered combination of claim elements is not directed to an abstract idea because it at least can be integrated into a practical application to solve a technical problem of relational databases suffer performance degradation when forced to maintain large volumes of static data ([0011]-[0015] of instant specification) because the combination of limitations improves database operations and system scalability rather than merely displaying or rearranging data (i.e., by searching and retrieving data from a non-relational database based on a query received in relational database language using multiple scans including the non-relational database). Thus, claim 21 and its dependent claims qualify as eligible subject matters under 35 U.S.C. 101.
Claim 28 recites a database system implemented using at least a server computing device (i.e., hardware-implemented per [0048] of instant specification) for implementing the steps of claim 21. Thus, claim 28 and its dependent claims qualify as eligible subject matters under 35 U.S.C. 101.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 35-40 are rejected under 35 U.S.C. 101 because the claimed invention is directed to nonstatutory subject matters.
Regarding claim 35, a “computer program product comprising computer-readable program code…from a non-transitory computer-readable medium…” is being recited. However, it appears that the non-transitory computer-readable medium is recited as a conditional or contextual clause, i.e., when retrieved from…, rather than as the primary structural limitation of the claim. As such, the claim is interpreted to direct to software per se or raw computer code. Applicant is noted that, to be statutory under 35 U.S.C. 101, a software product claim must be explicitly tied to a physical, non-transitory storage medium. Applicant is suggested to amend the claim to explicitly claim the non-transitory computer-readable medium as the main structural element to overcome the issue raised. One example is as follows:
“A computer program product comprising a non-transitory computer-readable medium having stored thereon computer-readable program code capable of being executed by one or more processors configured to cause…”
Claims 36-40 fail to resolve the deficiencies of claim 35 since they only further limit the scope of claim 35. Hence, claims 26-40 are also rejected under 35 U.S.C. 101.
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, 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.
Claims 21, 25, 28, 32, 35, and 39 are rejected under 35 U.S.C. 103 as being unpatentable over Eidson et al. (Pub. No. US 2011/0258178, published on October 20, 2011; hereinafter Eidson) in view of Harrison et al. (Pat. No. US 9886483, filed on April 29, 2011; hereinafter Harrison).
Regarding claims 21, 28, and 35, Eidson clearly shows and discloses a method; a data retention system, comprising: a database system implemented using at least a server computing device, the database system configurable to cause the method; a computer program product comprising computer-readable program code capable of being executed by one or more processors when retrieved from a non-transitory computer-readable medium, the program code comprising computer-readable instructions configurable to cause the method (Abstract, Figures 1-5 and corresponding texts) comprising:
obtaining, by a data retention system implemented via a database system, a data retention policy associated with a tenant of a multitenant computing environment, the data retention policy indicating one or more parameters associated with temporal attributes of data to be copied from a relational database to a non-relational database (The determination to replicate or synchronize data from one data store to another data store may be based on various considerations. For example, the decision to replicate from the relational data store 155 to the non-relational data store 150 may be based upon a determination or a policy to replicate a smaller dataset from its primary location to the location having the larger dataset, [0038]. The option of synchronizing the updates at specific intervals is provided (for example, via optimizer agent 245 and the hardware based query layer agent 501 and 734 discussed below). In such an embodiment, a policy that allows updates at specific intervals provides for more efficient writes and updates, [0043]-[0047]);
copying at least a portion of the first data, identified from the relational database based on the data retention policy, to the non-relational database (host system 110 triggers a flush of the append log 410, thus flushing the new data 416 written to the append log 410 of the relational data store 155 to the non-relational data store 150 when the append log 410 reaches a flush threshold, resulting in, for example, new data then residing in non-relational data store 150 as flushed data 417 and corresponding to new data 416 which previously resided in append log 410 of relational data store 155, [0062]), wherein the copying continues until backup of the first data in the non-relational database is complete (Such Enterprise level data protections further enable, through transaction processing, the ability to "redo" a particular transaction in the event of a failure in contrast to a direct insertion model that may feasibly leave a data store lacking transaction processing in an inconsistent state should a database transaction fail or be interrupted before final completion, [0046]);
obtaining a query received via a user interface (web server 210 may be responsible for receiving requests 115 from various customer organizations 105A-C via network 125. Web server 210 may provide a web-based interface to an end-user client machine originating the request 115 (e.g., such as an end-user client device located within a customer organization 105A-C), [0026]);
using the query to scan the non-relational database using data of the relational database and data of the non-relational database (The host system 110 generates a database query 217 based on the request 115, in which the database query 217 specifies a plurality of data elements to be retrieved, the plurality of data elements including one or more data elements residing within the non-relational data store 150 and one or more other data elements residing within the relational data store 155, [0029]. The database query 217 includes a plurality of sub-queries. In such an embodiment, at least one of the plurality of sub-queries are directed toward retrieving the one or more data elements residing within the non-relational data store 150 from the non-relational data store 150 and at least a second one of the plurality of sub-queries are directed toward retrieving the one or more other data elements residing within the relational data store 155 from the relational data store 155, [0031]. It is clear that the generated query 217 is the database-system representation of user request 115 formulated to execute the user’s intent across the data stores, thus, user request 115 received via GUI is being used to search using data from both relational and non-relational data stores).
Harrison then discloses:
obtaining a query received via a user interface, the query being received in a relational database language (the client 102 can generate one or more user interfaces that enable the user to query the database system 110 with SQL, [Column 3, Lines 57-67]);
combining results of the query on the non-relational database (the database system 110 described above can join tables from multiple databases 920 and 930, including relational and/or non-relational data stores. The proxy layer 912 of the database system can improve join performance by performing dynamic, on-the-fly join processing. This dynamic processing can include the creation of one or more proxy tables, hash indexes, or the like, [Column 9, Line 62 – Column 10, Line 44]. The query translator 126 can store the parameters of the SQL WHERE clause and dynamically generate the results for the column corresponding to the WHERE clause. In the example above, the query translator 126 can store “Australia” as the value to include in a row corresponding to a “country” column. Upon receiving the sum of revenue measure from the cube, the query translator 126 can combine the stored “Australia” value and the sum of revenue value to form a row in the mapped table, [Column 30, Lines 1-20]); and
providing the combined results via the user interface (A SELECT query 720 has been created using the user interface 700 to select data from the products table 710. Partial results 730 of the query are shown in the user interface 700, and additional results 830 are shown in the user interface 800, [Column 9, Lines 45-61]).
It would have been obvious to an ordinary person skilled in the art at the time of the invention was effectively filed to incorporate the teachings of Harrison with the teachings of Eidson for the purpose of efficiently processing data query in a non-relational database by decomposing the query into multiple sub-query components and integrating results from all sub-query components as part of retrieved data corresponding to the query.
Regarding claims 25, 32, and 39, Harrison further discloses performing, in parallel, multiple scans of the nonrelational database (Some data stores are capable of performing optimizations for joining data sets, and the proxy layer 912 can leverage this capability to improve join performance. For instance, the Hive™ non-relational database system that interfaces with the Hadoop™ storage system is capable of performing massively parallel join operations which execute across an entire Hadoop cluster, which may include hundreds or even thousands of machines. The proxy layer 912 can leverage these capabilities to cause joins to be performed by the data stores whenever possible, [Column 10, Lines 13-22]).
Claims 22-23, 29-30, and 36-37 are rejected under 35 U.S.C. 103 as being unpatentable over Eidson in view of Harrison and further in view of Blood et al. (Pub. No. US 2012/0311377, published on December 6, 2012; hereinafter Blood).
Regarding claims 22, 29, and 36, Blood then discloses the one or more parameters include: weekly backup retention, monthly backup retention, yearly backup retention, and/or week of the year backup retention (one data store may be used to store tenant data and one or more other data stores may be used to store the corresponding backup data. Generally, the data in data store 212' is a mirror of the data in data store 212. Changes made to data that is associated with the primary service 210 (i.e. data relating to administrative changes and tenant data) is mirrored to the secondary service 220. According to an embodiment, full backups (e.g. weekly), incremental backups (e.g. hourly, daily) and transaction logs are used in maintaining the changes made, [0041]).
It would have been obvious to an ordinary person skilled in the art at the time of the inventio was effectively filed to incorporate the teachings of Blood with the teachings of Eidson, as modified by Harrison, for the purpose of preparing data in fail-over events by maintaining data copies on separate storage locations.
Regarding claims 23, 30, and 37, Blood further discloses the data retention policy specifies how frequently backups are created (one data store may be used to store tenant data and one or more other data stores may be used to store the corresponding backup data. Generally, the data in data store 212' is a mirror of the data in data store 212. Changes made to data that is associated with the primary service 210 (i.e. data relating to administrative changes and tenant data) is mirrored to the secondary service 220. According to an embodiment, full backups (e.g. weekly), incremental backups (e.g. hourly, daily) and transaction logs are used in maintaining the changes made, [0041]).
Claims 24, 26, 31, 33, and 38 are rejected under 35 U.S.C. 103 as being unpatentable over Eidson in view of Harrison and further in view of Taylor et al. (Pub. No. US 2011/0258225, published on October 20, 2011; hereinafter Taylor).
Regarding claims 24, 31, and 38, Taylor then discloses the backup is a background job that is independent of the database system (performing transparent object migration across storage tiers will be described with reference to example embodiments. In one example implementation, the operation of an API (Application Programming Interface) is controlled in a combined data repository having a relational data store portion and a non-relational data store portion. A CustomEntityOption bit is set that determines (at object creation time) where the object is stored, either in the relational or the non-relational data store portion. The CustomEntityOption bit is loaded in a cached CustomEntityDefinition. The CustomEntityOption bit as is shown as EntityInfo, and custom object definition and Metadata API functionality is allowed when the bit is shown, [0030]).
It would have been obvious to an ordinary person skilled in the art at the time of the inventio was effectively filed to incorporate the teachings of Taylor with the teachings of Eidson, as modified by Harrison, for the purpose of storing and organizing data for multiple disparate storage tiers to facilitate rapid and efficient retrieval of accurate information and subsequent delivery of this information to system users.
Regarding claims 26, and 33, Taylor further discloses providing, to an application, access to application data stored on a server system of the data retention system, the application data being stored in a non-relational format (incremental DML goes through the relational database and participates in real ACID transactions. Writes are temporarily written to the AppendLog but for query purposes this data is blended correctly with non-relational storage so that the results are correct in real time transactionally, [0119]).
Claims 27, 34, and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Eidson in view of Harrison and further in view of Oberhofer (Pub. No. US 2014/0059311, filed on June 6, 2013; hereinafter Oberhofer).
Regarding claims 27, 34, and 40, Oberhofer then discloses the non-relational database is stored in a columnar format (A `columnar database` as used herein is a database wherein data is organized in the form of one or more columns respectively comprising one or more distinct parameter values, e.g. in the form of an ordered list. Each of the distinct parameter values is stored in association with one or more object-IDs of data objects being characterized by the parameter value, [0021]).
It would have been obvious to an ordinary person skilled in the art at the time of the inventio was effectively filed to incorporate the teachings of Oberhofer with the teachings of Eidson, as modified by Harrison, for the purpose of enabling quick and efficient retrieval of backup data using columnar format.
Relevant Prior Art
The following references are deemed relevant to the claims:
Elnikety et al. (Pub. No. US 2014/0172914) teaches graph queries are processed using a plurality of independent query execution engines. A graph query submitted to a graph database which is modeled by an attributed graph is received. The graph query is decomposed into a plurality of query components. For each of the query components, a one of the query execution engines that is available to process the query component is identified, a sub-query representing the query component is generated, the sub-query is sent to the identified query execution engine for processing, and results for the sub-query are received from the identified query execution engine. The results received are then combined to generate a response to the graph query.
Banerjee et al. (Pub. No. US 2013/0024484) teaches the combined use of a relational database with a non-relational database to selectively store systems management data based on predefined selection criteria. The relational database, if included, comprises a table-based data store that can be queried using a SQL variant. The non-relational database may comprise a file-based data store and consumes UNIX operating system utilities to make faster retrievals from the file-based data store. The novel use of a non-relational database at the core of a systems management application increases performance and scalability in systems management applications.
Contact Information
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to Son Hoang whose telephone number is (571) 270-1752. The Examiner can normally be reached on Monday – Friday (7:00 AM – 4:00 PM).
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Sherief Badawi can be reached on (571) 272-9782. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SON T HOANG/Primary Examiner, Art Unit 2169 August 8, 2026
Prosecution Insights