Prosecution Insights
Last updated: October 02, 2026
Application No. 19/009,857

DYNAMIC DATA ACCESS OBJECTS FOR DATA BACKUP AND RECOVERY

Non-Final OA §102§103
Filed
Jan 03, 2025
Examiner
SKHOUN, HICHAM
Art Unit
2164
Tech Center
2100 — Computer Architecture & Software
Assignee
Rubrik Inc.
OA Round
1 (Non-Final)
77%
Grant Probability
Favorable
1-2
OA Rounds
1y 5m
Est. Remaining
83%
With Interview

Examiner Intelligence

Grants 77% — above average
77%
Career Allowance Rate
276 granted / 358 resolved
+22.1% vs TC avg
Moderate +6% lift
Without
With
+5.5%
Interview Lift
resolved cases with interview
Typical timeline
3y 2m
Avg Prosecution
21 currently pending
Career history
384
Total Applications
across all art units

Statute-Specific Performance

§101
15.7%
-24.3% vs TC avg
§103
44.3%
+4.3% vs TC avg
§102
24.9%
-15.1% vs TC avg
§112
8.5%
-31.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 358 resolved cases

Office Action

§102 §103
DETAILED ACTION 1. Applicant provisionally elects Group I, identified above as corresponding to claims 1-13 and 20, with traverse, for examination on the merits. Therefore, claims 14-19 will be withdrawn should the restriction requirement remain. 2. This office action is in response to the claims filed 04/27/2026. 3. Claims 1 and 20 are independent claims. 4. The office action is made Non-Final. Examiner Note 5. The Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the Applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. Claim Rejections - 35 USC § 102 6. 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. 7. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) The claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention; 8. Claims 1, 2, 4-13 and 20 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by Gibbons, JR.et al (US 20180314603 A1) hereinafter as Gibbons. 9. Regarding claim 1, Gibbons teaches A method, comprising: obtaining, by a data management system (DMS), a source data table from a software-as-a-service (SaaS) application via an application programming interface (API) associated with the SaaS application, the source data table comprising one or more rows of data values (Figs 4 &5, [0016-0017], “the ingestion of SaaS data by a cloud-based Multi-Scheme/API Management Server (a data management system (DMS)),”, [0102], [0116], “the ingestion of SaaS data can be executed by a Backup Definition vendor, for example, the Multi-Scheme/API Management Server 400 (a data management system (DMS)).”, [0118], “The Multi-Scheme/API Management Server 400 can utilize numerous protocols and the routines included in the API Tree of a Backup Definition. As such, the API Tree routines and content can be utilized by the Multi-Scheme/API Management Server 400 to upload files, data fields, meta-data and the like types of information from the SaaS server 500. After receiving the SaaS data request 4007, the SaaS Server 500 can retrieve the requested data, for example, from memory, and send the data, in a SaaS data response 4009, to the Multi-Scheme/API Management Server 400 (a data management system (DMS)).”, [0144], “a HF dataset request 11001 can request a dataset composed by data from multiple SaaS applications… two tables or datasets (e.g., SaaS_Music datasets and SaaS_eBooks datasets)”, [0198], “Relational databases consist of a series of related tables. The tables are interconnected via a key field… Primary keys represent fields that uniquely identify the rows of a table in a relational database. More precisely, they uniquely identify rows of a table on the “one” side of a one-to-many relationship.”, [0200]); detecting, by the DMS, a schema of the source data table, the schema comprising a set of fields ([0094], “the secure cloud-based Multi-Scheme/API Management Server 400… A Backup Definition response 2009 can include one or more API tree data structures, with nodes defining a collection of Application Program Interface (API) routines, Endpoints, Application Data Schemes, Trigger Fields, protocols”, [0102], , [0109], “Once a High-Fidelity Format is determined for a particular type of file, respective Application Data Schemes can be established to convert native data for files of this type from different applications to the High-Fidelity Format for that type of file.” [0112], “the Backup Definition can include multiple data structures, API routines in an API Tree Structure, Endpoint locations, protocol information, and/or data scheme specific to an application hosted in a SaaS server… Additionally, a Backup Definition can include one or more Trigger Fields and logic to traverse or walk an API Tree Structure, e.g. the /folders Endpoint can trigger the /files Endpoint for all files contained within a folder.”, [0131], “verify if a SaaS data scheme (e.g., an Application Data Scheme for the particular SaaS application that generated the dataset)”, [0144], “multiple Application Data Schemes describing how different SaaS applications respectively organize and represent data content.”, [0200], “The Data Schemes table 1419d may include fields such as, but not limited to:…”); converting, by the DMS and based at least in part on detecting the schema, the one or more rows of the source data table into one or more respective data access objects that map the set of fields to corresponding data values per row of the one or more rows ([0031], “Data Scheme can include rules to convert native data into a high-fidelity format (data access objects) (e.g., representational state transfer or REST format), such that the data can be viewed, transferred between entities with no data lost, combined with data from another data source or application, and backed up and restored to a native format.”, [0108], “For different file types, a particular High-Fidelity Format (data access objects) may be determined in part by the content of metadata generally associated with a particular type of file by different applications (i.e., the various attributes of a file that are catalogued in the metadata associated with the file may be used to determine the High-Fidelity Format)… the metadata content may include information relating to:… an access control list (e.g., read, write and execute permissions),”, [0109], “a High-Fidelity Format of a particular type of file provides a canonical format for file metadata, which canonical format in turn may be stored together with the underlying binary for the substantive file contents as the backed-up data for the file.”, [0116-0107], “convert native data to an application-independent High-Fidelity Format.”, [0119], “The Multi-Scheme/API Management Server 400 can contain the Application Data Scheme to convert a SaaS dataset received in the response 4009 into a High-Fidelity Format.”); and causing, by the DMS, backup information for the SaaS application to be stored in a storage environment accessible to the, wherein the backup information for the SaaS application is based at least in part on the one or more respective data access objects ([0027], “The LI Server can also store multiple versions of backup data, each version of backup data corresponding to a state of data stored at a SaaS application server, a cloud storage server, and/or a client terminal at a particular point in time.”, [0028], “the backup copies stored in the LI Server can remain intact and accessible.”, [0031], “An Application Data Scheme can include rules to convert native data into a high-fidelity format (e.g., representational state transfer or REST format), such that the data can be viewed, transferred between entities with no data lost, combined with data from another data source or application, and backed up and restored to a native format.”, [0103], [0106], [0114], [0131], [0139]). 10. Regarding claim 2, Gibbons teaches the invention as claimed in claim 1 above and further teaches converting, by the DMS, the one or more respective data access objects into one or more backup tables having a second schema, wherein causing the backup information to be stored in the storage environment comprises causing the one or more backup tables having the second schema to be stored in the storage environment ([0031], “backed up and restored to a native format”, [0114], “decrypt the SaaS dataset for restoring the dataset to the originating application”, [0118], [0124], “FIG. 6A-6B illustrate an example data flow to restore a backed-up SaaS dataset, file or document from an LI Server 100 to a SaaS application running on a SaaS server 500. One advantage provided by having backed-up SaaS datasets stored in the LI Server 100 in a High-Fidelity Format in some implementations is that the datasets can be converted into their native or original SaaS format through a Native Format Converter (e.g., NFC Component 7000) further described with respect to FIG. 7. A dataset in a SaaS native format can be restored seamlessly into a SaaS application such that all data, metadata and original properties of the original SaaS data remain intact through format conversions.”, [0139]) ([0018], [0030]). 11. Regarding claim 4, Gibbons teaches the invention as claimed in claim 1 above and further teaches claim 4 limitations (Brajkovic discloses a cloud-based Multi-Scheme/API Management Server applied to different source tables obtained from the SaaS application via different APIs associated with the SaaS application). 12. Regarding claim 5, Gibbons teaches the invention as claimed in claim 1 above and further teaches claim 5 limitations (Brajkovic discloses a cloud-based Multi-Scheme/API Management Server applied to different source tables obtained from the SaaS application via different APIs associated with the SaaS application). 13. Regarding claim 6, Gibbons teaches the invention as claimed in claim 1 above and further teaches claim 6 limitations (Brajkovic discloses a cloud-based Multi-Scheme/API Management Server using different snapshots [0130], [0142]). 14. Regarding claim 7, Gibbons teaches the invention as claimed in claim 6 above and further teaches wherein: the second set of fields comprises a first additional field with respect to the set of fields; or the set of fields comprises a second additional field with respect to the second set of fields ([0052], “analyze data holistically, and any additional data generated as a result of this process”, [0085], [0114], “each of the converted fields ($HF_SField) can be appended into a data structure”). 15. Regarding claim 8, Gibbons teaches the invention as claimed in claim 1 above and further teaches wherein the one or more respective data access objects indicate respective field types and respective field names for the set of fields ([0108], “a particular High-Fidelity Format (one or more respective data access objects)”). 16. Regarding claim 9, Gibbons teaches the invention as claimed in claim 1 above and further teaches detecting, by the DMS, relationship metadata associated with the source data table, wherein the relationship metadata is indicative of a hierarchical relationship between a row of the one or more rows and a second data table, wherein converting the one or more rows comprises indicating the relationship metadata in a respective data access object for the row of the one or more respective data access objects ([0031], “Data Scheme can include rules to convert native data into a high-fidelity format (data access objects) (e.g., representational state transfer or REST format), such that the data can be viewed, transferred between entities with no data lost, combined with data from another data source or application, and backed up and restored to a native format.”, [0108], “For different file types, a particular High-Fidelity Format (data access objects) may be determined in part by the content of metadata generally associated with a particular type of file by different applications (i.e., the various attributes of a file that are catalogued in the metadata associated with the file may be used to determine the High-Fidelity Format)… the metadata content may include information relating to:… an access control list (e.g., read, write and execute permissions),”, [0109], “a High-Fidelity Format of a particular type of file provides a canonical format for file metadata, which canonical format in turn may be stored together with the underlying binary for the substantive file contents as the backed-up data for the file.”, [0116-0107], “convert native data to an application-independent High-Fidelity Format.”, [0119], “The Multi-Scheme/API Management Server 400 can contain the Application Data Scheme to convert a SaaS dataset received in the response 4009 into a High-Fidelity Format.”). 17. Regarding claim 10, Gibbons teaches the invention as claimed in claim 1 above and further teaches claim 10 limitations (Brajkovic discloses restoring the SaaS dataset , See Fig 6A-6B, [0018], [0031], “backed up and restored to a native format”, [0057], “the LI Server can periodically receive and store data generated through the use of any number of SaaS applications as backed-up SaaS data, thereby creating restore points in time from which users can recover SaaS data.”). 18. Regarding claim 11, Gibbons teaches the invention as claimed in claim 10 above and further teaches performing, by the DMS, a query to the SaaS application for the target restore data table via the second API; and receiving, by the DMS, a response to the query via the second API associated with the SaaS application, wherein the second schema is detected based at least in part on the response (Fig 6A-6B, [0018]). 19. Regarding claim 12, Gibbons teaches the invention as claimed in claim 10 above and further teaches receiving, by the DMS and via a user interface associated with the DMS, a request to restore the target restore data table of the SaaS application to a state corresponding to the target restore time (Fig 6A-6B, [0018], [0031], “backed up and restored to a native format”, [0057], “the LI Server can periodically receive and store data generated through the use of any number of SaaS applications as backed-up SaaS data, thereby creating restore points in time from which users can recover SaaS data.”, [0126], [0128-0130], “send a Restore SaaS Dataset Version (DV) request 6011 to the LI server 100. ”). 20. Regarding claim 13, Gibbons teaches the invention as claimed in claim 1 above and further teaches receiving, by the DMS and via a user interface associated with the DMS, a request to back up the source data table of the SaaS application at a first time, wherein obtaining the source data table is at the first time and is based at least in part on the request (Fig 3A, 5, [0060-0074], “backup request”, [0084-0086], [0093], “send a Backup Definition request 2007”). 21. Regarding claim 20, this claim recites a non-transitory computer-readable medium storing code, the code comprising instructions executable by one or more processors to performs the method of claim and is rejected under the same rationale. Claim Rejections - 35 USC § 103 22. 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. 23. 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) A patent may not be obtained through the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made. 24. Claim 3 is rejected under 35 U.S.C.103 as being unpatentable over Gibbons, JR.et al (US 20180314603 A1) hereinafter as Gibbons in view of Seal et al (US 20200159413 A) hereinafter as Seal. 25. Regarding claim 3, Gibbons teaches the invention as claimed in claim 3 above, Gibbons did not specifically teach wherein the one or more backup tables having the second schema are Postgres tables. However, Seal teaches wherein the one or more backup tables having the second schema are Postgres tables ([0018], [0030]). It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the concept of teachings suggested in Seal’s system into Gibbons’s and by incorporating Seal into Gibbons because both systems are related to data management would performing an incremental backup in a way to overcome the perform unnecessary backups or generate incremental backup data that are larger in size than needed. CONCLUSION 26. The prior art made of record and not relied upon is considered pertinent to applicant s disclosure. Derryberry et al (US 20210389883 A1) discloses cloud object storage and versioning. Zimmermann et al (US 20200137097 A1) discloses data security relating to use of various computing platforms and applications and services deployed on or in connection with such platforms. Brajkovic et al (US 20240273226 A1) Singh et al (US 20240086416 A1) Cella et al (US 11181893 B2) Amano et al (US 20110246732 A1) NGO (US 20250061377 A1) Pinski et al (US 11928044 B1) Yadav et al (US 20230065486 A1) Esposito et al (US 20230188431 A1) Zhao et al (US 20200050608 A1) Syed et al (US 9836332 B2) Mccormack et al (US 20210304369 A1) Prahlad (AU 2010266433 A1) CELLA (WO 2024025863 A1) Khirman (WO 2023119270 A1) Any inquiry concerning this communication or earlier communications from the examiner should be directed to HICHAM SKHOUN whose telephone number is (571)272-9466. The examiner can normally be reached Normal schedule: Mon-Fri 10am-6:30pm. 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, Amy Ng can be reached at 5712701698. 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. /HICHAM SKHOUN/Primary Examiner, Art Unit 2164
Read full office action

Prosecution Timeline

Jan 03, 2025
Application Filed
Jul 08, 2026
Non-Final Rejection mailed — §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12725111
MODELING AND STRUCTURING SYSTEM FOR PROCESSING BUSINESS PROCESS MODELING NOTATIONS
2y 12m to grant Granted Sep 01, 2026
Patent 12711146
TECHNIQUES FOR UPGRADING AND ACCESSING METADATA
1y 9m to grant Granted Aug 18, 2026
Patent 12705225
Compaction of Documents in a High Density Data Storage System
1y 4m to grant Granted Aug 11, 2026
Patent 12687979
OFFLOADING DATA COMPRESSION DURING RESTORES TO A DATA PROCESSING UNIT IN A DEDUPLICATION BACKUP SYSTEM
3y 3m to grant Granted Jul 21, 2026
Patent 12681991
PROACTIVE DETERMINATION OF DATA INSIGHTS
2y 6m to grant Granted Jul 14, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
77%
Grant Probability
83%
With Interview (+5.5%)
3y 2m (~1y 5m remaining)
Median Time to Grant
Low
PTA Risk
Based on 358 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month