DETAILED ACTION
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 .
This Office Action has been issued in response to Applicant’s Communication of application S/N 18/745,216 filed on May 15, 2025. Claims 1-20 are pending with the application.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
Claim(s) 1, 2, 7-17, and 20 and is/are rejected under 35 U.S.C. 103 as being unpatentable over Mishra et al. (U.S. Publication No.: US 20200177475 A1) hereinafter Mishra, in view of Boyter et al. (U.S. Publication No.: US 20030212779 A1) hereinafter Boyter, and further in view of Osaka et al. (U.S. Publication No.: US 20040107191 A1) hereinafter Osaka.
As to claim 1:
Mishra discloses:
A method comprising: storing, within a first database, (i) identifiers of a set of active cloud resources within a cloud environment [Paragraph 0036 teaches the purpose of provisioner database 330 is to hold the information about all the existing alive instances, tenants, and information related to them. Paragraph 0043 teaches the provisioner generates “unique identifier’, otherwise known as a UUID, for the new instance at S614. This UUID should be unique for each instance. Note: Storing information associated with alive tenants in the provisioner database (first database) reads on the claims.], and (ii) for each active cloud resource within the set of active cloud resources, an identifier of a corresponding tenancy of the cloud environment [Paragraph 0035 teaches if a create instance operation is being executed, an entry for the new instance (including the “instanceinfo”) is written onto the databases 330, 340. Similarly, the tenant where this instance should be placed in is determined by a read-operation of the tenant info from the databases 330, 340. Paragraph 0055 teaches information could include tenant ID (UUID), tenant name, etc. Note: For each created tenant instance (each active cloud resource within the set of active cloud resources), there is a tenant ID and tenant name reads on the claims.]; storing, within a second database, (i) identifiers of a set of tenancies within the cloud environment [Paragraph 0036 teaches if any restore recovery operation has to be performed on instance/tenant, the orphaned database 340 holds the needed information. Paragraph 0051 teaches the provisioner searches the orphaned database for any entry of “tenant” whose UUID… Note: Storing and searching for UUIDs in an orphaned database (second database) reads on the claims.], and (ii) for each tenancy within the set of tenancies, a corresponding tenancy status [Paragraph 0036 teaches the orphaned database 340 holds the information about all the deleted instances, tenants, and the information related to them. If any restore or recovery operation has to be performed on an instance/tenant, the orphaned database 340 holds the needed information according to some embodiments. Paragraph 0064 teaches a table is shown that represents the orphaned data store 1000 that may be stored at the platform 900 according to some embodiments… The fields 1002, 1004, 1006, 1008, 1010 may, according to some embodiments, specify: a UUID 1002, a resource name, an organization name, an organization UUID, and a deletion date and time. Note: Storing deletion date and time (tenancy status) reads on the claims.],
querying the first database and the second database to identify a first active cloud resource within a first tenancy, such that the first tenancy has a tenancy status of being terminated from the cloud environment [Paragraph 0055 teaches the provisioner may first search the orphaned database for ‘tenatninfo’. Paragraph 0056 teaches the provisioner may then trigger the creation of ‘tenantinfo’ with the same name and ID (UUID)… if a tenant of same name already exists, it will generate an ‘ERROR’. Note: Checking both the provisioner database and the orphaned database for information about the tenant reads on the claims. The examiner further notes searching for an existing in the provisioner database is interpreted to be querying the provisioner database.];
Mishra discloses some of the limitations as set forth in claim 1 but does not appear to expressly disclose wherein within the second database, each of a first subset of the set of tenancies has a status of being active in the cloud environment, and wherein within the second database, each of a second subset of the set of tenancies has a status of being terminated from the cloud environment, tagging the first tenancy with an unaccounted tag; and responsive at least in part to the first tenancy being tagged with the unaccounted tag, performing one or more of (i) terminating the first tenancy, (ii) terminating one or more active cloud resources within the first tenancy, including terminating the first active cloud resource, or (iii) changing a status of the first tenancy from terminated to active.
Boyter discloses:
wherein within the second database, each of a first subset of the set of tenancies has a status of being active in the cloud environment, and wherein within the second database, each of a second subset of the set of tenancies has a status of being terminated from the cloud environment [Paragraph 0013 teaches for scanning all network nodes within designated address ranges may comprise a host scanner daemon for accessing a control database, for storing the status of each active host and inactive host in the control database, for removing a host designated as inactive from the control database, and adding a new host designated as active to the control database when first detected.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Mishra, by incorporating scanning all network nodes within designated address ranges storing the status of each active host and inactive host in the control database (see Boyter Paragraph 0013), because both applications are directed to database analysis; incorporating scanning all network nodes within designated address ranges storing the status of each active host and inactive host in the control database provides a significant performance advantage (see Boyter Paragraph 0030).
Mishra and Boyter discloses most of the limitations as set forth in claim 1 but does not appear to expressly disclose tagging the first tenancy with an unaccounted tag; and responsive at least in part to the first tenancy being tagged with the unaccounted tag, performing one or more of (i) terminating the first tenancy, (ii) terminating one or more active cloud resources within the first tenancy, including terminating the first active cloud resource, or (iii) changing a status of the first tenancy from terminated to active.
Osaka discloses:
tagging the first tenancy with an unaccounted tag; and responsive at least in part to the first tenancy being tagged with the unaccounted tag, performing one or more of (ii) terminating one or more active cloud resources within the first tenancy, including terminating the first active cloud resource [Paragraph 0025 teaches when a flag is set to indicate that a terminal is missing, transmitting a signal instructing erasure of the information to that operation instructing terminal.], (i) terminating the first tenancy, or (iii) changing a status of the first tenancy from terminated to active. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Mishra and Boyter, by incorporating a flag is set to indicate that a terminal is missing transmitting a signal instructing erasure of the information to that operation instructing terminal (see Osaka Paragraph 0025), because the three applications are directed to database analysis; incorporating a flag is set to indicate that a terminal is missing transmitting a signal instructing erasure of the information to that operation instructing terminal improves visibility can support quick and efficient searching, and can improve security of provided information (see Osaka Paragraph 0011).
Claims 9,12, and 16 are similarly rejected because they are similar in scope.
As to claim 2:
Mishra, Boyter, and Osaka discloses all of the limitations as set forth in claim 1.
Osaka also discloses:
The method of claim 1, further comprising: periodically or intermittently querying the first database and the second database, to identify whether any active cloud resource of the first database is within a tenancy having a status of being terminated in the second database [Paragraph 0099 teaches the instruction server 28 repeatedly and periodically transmits an instruction to carry out deletion to search terminals having this flag set until an instruction to delete stored content is conveyed to the missing search terminal 3. Here, if the search terminal 3 receives this instruction, operation content being stored is deleted by this instruction.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Mishra and Boyter, by incorporating periodically checking for a flag is set to indicate that a terminal is missing transmitting a signal instructing erasure of the information to that operation instructing terminal (see Osaka Paragraph 0025), because the three applications are directed to database analysis; incorporating a flag is set to indicate that a terminal is missing transmitting a signal instructing erasure of the information to that operation instructing terminal improves visibility can support quick and efficient searching, and can improve security of provided information (see Osaka Paragraph 0011).
Claim 17 is similarly rejected because it is similar in scope.
As to claim 7:
Mishra discloses:
The method of claim 1, wherein the set of active cloud resources within the cloud environment include one or more of (i) one or more active compute instances, [Paragraph 0036 teaches the purpose of provisioner database 330 is to hold the information about all the existing alive instances, tenants, and information related to them. Paragraph 0043 teaches the provisioner generates “unique identifier’, otherwise known as a UUID, for the new instance at S614. This UUID should be unique for each instance. Note: Storing information associated with alive tenants in the provisioner database (first database) reads on the claims.]and (ii) one or more active software agents operating within an active compute instance.
Claim 20 is similarly rejected because it is similar in scope.
As to claim 8:
Mishra discloses:
The method of claim 1, wherein the first database lacks a status of each tenancy, whose identifiers are included within the first database. [Paragraph 0051 teaches provisioner searches the orphaned database for any entry of “tenant” whose UUID matches the same as the “tenant” to be deleted at S726. Note: The provisioner databases search the orphaned database for status information it does not have (lacks) reads on the claims.]
As to claim 10:
Mishra discloses:
The method of claim 9, wherein the second tenancy including the second active cloud resource is identified from the first database. [Paragraph 0036 teaches the purpose of provisioner database 330 is to hold the information about all the existing alive instances, tenants, and information related to them. Paragraph 0043 teaches the provisioner generates “unique identifier’, otherwise known as a UUID, for the new instance at S614. This UUID should be unique for each instance. Note: Storing information associated with alive tenants in the provisioner database (first database) reads on the claims.]
As to claim 11:
Mishra discloses:
The method of claim 9, wherein the status of the second tenancy is determined from the second database [Paragraph 0055 teaches the provisioner may first search the orphaned database for ‘tenatninfo’. Paragraph 0056 teaches the provisioner may then trigger the creation of ‘tenantinfo’ with the same name and ID (UUID)… if a tenant of same name already exists, it will generate an ‘ERROR’. Note: Checking both the provisioner database and the orphaned database for information about the tenant reads on the claims. The examiner further notes searching for an existing in the provisioner database is interpreted to be querying the provisioner database.];
As to claim 13:
Mishra discloses:
The non-transitory computer-readable medium of claim 12, wherein the communication is in the form of data [Paragraph 0036 teaches the purpose of provisioner database 330 is to hold the information about all the existing alive instances, tenants, and information related to them. Paragraph 0043 teaches the provisioner generates “unique identifier’, otherwise known as a UUID, for the new instance at S614. This UUID should be unique for each instance. Note: Storing information associated with alive tenants in the provisioner database (first database) reads on the claims.] or a service request, or a log message
As to claim 14:
Mishra discloses:
The non-transitory computer-readable medium of claim 12, the operations include: storing, within a database, (i) identifiers of a set of active cloud resources within the cloud environment, and (ii) for each active cloud resource within the set of active cloud resources, an identifier of a corresponding tenancy of the cloud environment; wherein the tenancy including the active cloud resource is identified from the database [Paragraph 0036 teaches the purpose of provisioner database 330 is to hold the information about all the existing alive instances, tenants, and information related to them. Paragraph 0043 teaches the provisioner generates “unique identifier’, otherwise known as a UUID, for the new instance at S614. This UUID should be unique for each instance. Note: Storing information associated with alive tenants in the provisioner database (first database) reads on the claims.]
As to claim 15:
Mishra discloses:
The non-transitory computer-readable medium of claim 12, the operations include: storing, within a database, (i) identifiers of a set of tenancies within the cloud environment, and (ii) for each tenancy within the set of tenancies, a corresponding tenancy status, wherein the status of the tenancy is determined to be terminated from the database [Paragraph 0036 teaches the orphaned database 340 holds the information about all the deleted instances, tenants, and the information related to them. If any restore or recovery operation has to be performed on an instance/tenant, the orphaned database 340 holds the needed information according to some embodiments. Paragraph 0064 teaches a table is shown that represents the orphaned data store 1000 that may be stored at the platform 900 according to some embodiments… The fields 1002, 1004, 1006, 1008, 1010 may, according to some embodiments, specify: a UUID 1002, a resource name, an organization name, an organization UUID, and a deletion date and time. Note: Storing deletion date and time (tenancy status) reads on the claims.]
Claim(s) 3 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mishra et al. (U.S. Publication No.: US 20200177475 A1) hereinafter Mishra, in view of Boyter et al. (U.S. Publication No.: US 20030212779 A1) hereinafter Boyter, and further in view of Osaka et al. (U.S. Publication No.: US 20040107191 A1) hereinafter Osaka, and further in view Nawrocke et al. (U.S. Publication No.: US 20200356873 A1) hereinafter Nawrocke.
As to claim 3:
Mishra, Boyter, and Osaka discloses all of the limitations as set forth in claim 1 but does not appear to expressly disclose wherein the first database and the second database are queried using a multiple joins query that joins data of the first database and the second database.
Nawrocke discloses:
The method of claim 1, wherein the first database and the second database are queried using a multiple joins query that joins data of the first database and the second database [Paragraph 0135 teaches the query… may indicate one or more joins of table T1 from source S1 and table T2 from source S2, where S1 and S2 could be the same source or different sources.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Mishra, Boyter, and Osaka, by incorporating a query indicates joins of table T1 from source S1 and table T2 from source S2, where S1 and S2 could be the same source or different sources (see Nawrocke Paragraph 0135), because the four applications are directed to database analysis; incorporating a query indicates joins of table T1 from source S1 and table T2 from source S2, where S1 and S2 could be the same source or different sources provide and advantageous methodology (see Nawrocke Paragraph 0123).
Claim 18 is similarly rejected because it is similar in scope.
Claim(s) 4-6 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mishra et al. (U.S. Publication No.: US 20200177475 A1) hereinafter Mishra, in view of Boyter et al. (U.S. Publication No.: US 20030212779 A1) hereinafter Boyter, and further in view of Osaka et al. (U.S. Publication No.: US 20040107191 A1) hereinafter Osaka, and further in view Schmiedehausen et al. (U.S. Publication No.: US 20190370258 A1) hereinafter Schmiedehausen.
As to claim 4:
Mishra, Boyter, and Osaka discloses all of the limitations as set forth in claim 1 but does not appear to expressly disclose wherein the status of the first tenancy is changed from terminated to active, and wherein the method further comprises: adding the first tenancy to an account database that is used to bill customers of one or more active tenancies of the cloud environment.
Schmiedehausen discloses:
The method of claim 1, wherein the status of the first tenancy is changed from terminated to active, and wherein the method further comprises: adding the first tenancy to an account database that is used to bill customers of one or more active tenancies of the cloud environment [Paragraph 0035 teaches the tenant data 120 may include subscription information, such as billing data and/or subscription status (e.g., active, canceled, suspended, re-activated). ]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Mishra, Boyter, and Osaka, by incorporating tenant data that includes subscription information, such as billing data and/or subscription status (e.g., active, canceled, suspended, re-activated) (see Schmiedehausen Paragraph 0035), because the three applications are directed to database analysis; incorporating tenant data that includes subscription information, such as billing data and/or subscription status (e.g., active, canceled, suspended, re-activated) improves the functionality of a computing device (see Schmiedehausen Paragraph 0078).
Claim 19 is similarly rejected because it is similar in scope.
As to claim 5:
Mishra, Boyter, Osaka, and Schmiedehausen discloses all of the limitations as set forth in claims 1 and 4.
Schmiedehausen also discloses:
The method of claim 1, wherein the status of the first tenancy is changed from terminated to active, and wherein the method further comprises: subsequent to changing the status of the first tenancy from terminated to active, determining that one or more critical information of the first tenancy is missing from one or both the first database and the second database; and generating a report that the one or more critical information of the first tenancy is missing [Paragraph 0035 teaches the tenant data 120 may include subscription information, such as billing data and/or subscription status (e.g., active, canceled, suspended, re-activated)… the tenant data 120 may include usage data (e.g., account activity data), such as new subscriptions, changes to subscribed products and/or services, cancellation of one or more products and/or services, subscriptions to new products and/or services, application of discounts, loyalty program package changes (e.g., additional programs and/or services, special rates, and/or the like for loyal customers), reduction or increase of rates for products and/or services, and/or cancellation of the application.]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Mishra, Boyter, and Osaka, by incorporating tenant data that includes subscription information, such as billing data and/or subscription status (e.g., active, canceled, suspended, re-activated) (see Schmiedehausen Paragraph 0035), because the three applications are directed to database analysis; incorporating tenant data that includes subscription information, such as billing data and/or subscription status (e.g., active, canceled, suspended, re-activated) improves the functionality of a computing device (see Schmiedehausen Paragraph 0078).
As to claim 6:
Mishra, Boyter, Osaka, and Schmiedehausen discloses all of the limitations as set forth in claims 1, 4 and 5.
Schmiedehausen also discloses:
The method of claim 5, wherein the one or more critical information of the first tenancy comprises one or more of (i) billing information associated with the first tenancy, and/or (ii) contact information associated with the first tenancy Paragraph 0035 teaches the tenant data 120 may include subscription information, such as billing data and/or subscription status (e.g., active, canceled, suspended, re-activated). ]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to combine the teaching of the cited references and modify the invention as taught by Mishra, Boyter, and Osaka, by incorporating tenant data that includes subscription information, such as billing data and/or subscription status (e.g., active, canceled, suspended, re-activated) (see Schmiedehausen Paragraph 0035), because the three applications are directed to database analysis; incorporating tenant data that includes subscription information, such as billing data and/or subscription status (e.g., active, canceled, suspended, re-activated) improves the functionality of a computing device (see Schmiedehausen Paragraph 0078).
Response to Arguments
Applicant presents the following arguments in May 15, 2026 remarks page 8-9:
“…Mishra, however, does not disclose or suggest querying multiple databases to identify an active cloud resource within a tenancy having a tenancy status of being terminated. Rather, Mishra is directed to recovery of deleted tenant information, not querying to identify active cloud resources within a terminated tenancy.”
Examiner presents the following response to Applicant’s arguments:
Applicant’s arguments have been fully considered but they are not persuasive. Mishra’s disclosure of recovering from any form of disaster-based deletion or loss of resource for a provisioner in a PaaS offering deployed on a cloud sufficiently discloses the current claim 1 and 16 recitation of querying the first database and the second database to identify a first active cloud resource within a first tenancy, such that the first tenancy has a tenancy status of being terminated from the cloud environment. The provisioner 350 may access (e.g., read from and write to) a provisioner database 330 and an orphaned database 340 (see Paragraph 0028). Note that the architecture maintains two forms of databases: the provisioner database 330 and the orphaned database 340. The purpose of provisioner database 330 is to hold the information about all the existing alive instances, tenants, and information related to them. The orphaned database 340 holds the information about all the deleted instances, tenants, and the information related to them (see Paragraph 0036). The provisioner may first search the orphaned database for ‘tenatninfo’ (see Paragraph 0055). Therefore, the examiner maintains reading from (querying) both the provisioner database and the orphaned database (plurality of databases) for information about the tenant, wherein the alive is interpreted to be the claimed active and the cited deleted tenants and information related to them (see Paragraph 0036) is interpreted to be the claimed terminated tenancy reads on the claims. The instant application Specification also supports the examiner interpretation that tenancy termination includes deleting tenancy information (see Specification Paragraph 0084).
The examiner further notes searching and receiving data from either the provisioner database and orphaned database reads on the claimed receiving communication from an active cloud resource, where the tenancy including the active cloud resource is determined to have a status of being terminated as recited in claim 12. As noted above, the data includes tenancy info shown as alive (active) or deleted (terminated).
Further clarification through the amendments to the claim language may aid in differentiating from the current prior art citations.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 EARL LEVI ELIAS whose telephone number is (571)272-9762. The examiner can normally be reached Monday - Friday (IFP).
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, Sherief Badawi can be reached at 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 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.
/EARL LEVI ELIAS/Examiner, Art Unit 2169
/SHERIEF BADAWI/Supervisory Patent Examiner, Art Unit 2169
Prosecution Insights