Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
2. Claims 1-20 are presented for examination.
3. This office action is in response to the REM filed 10/28/2025.
4. Claims 1, 16 and 20 are independent claims.
5. The office action is made Final.
Examiner Note
6. 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 § 103
9. 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.
10. 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.
1. Claims 1-20 are rejected under 35 U.S.C.103 as being unpatentable over Buchmann et al (US 20230091845 A1) hereinafter as Buchmann in view of Chatterjee et al (US 20040210582 A1) hereinafter as Chatterjee.
10. Regarding claim 1, Buchmann teaches A method for data management, comprising:
receiving a request to access a subset of metadata stored in a distributed metadata repository of a data management system (Abstract, “A client request is received that includes a relevancy identifier. The relevancy identifier is useable to determine a subset of metadata that should be provided in response to the request.” Fig 1, central metadata repository 104 (a distributed metadata repository of a data management system), [0043-0044], “The central metadata repository 104 can include an import/export manager 128. The import/export manager 128 can process requests to read, add, change, or remove metadata in the standardized format 120”, [0044], “The import/export manager 128 can also access various rules 136 useable to determine what metadata is relevant to a particular client request.”),
wherein the request has a first semantic format compatible with a first version of the distributed metadata repository ([0041-0043], “The central metadata repository 104 includes metadata 120, which can be metadata in a standardized format. While in some cases a standardized format can be a format that is common to the client systems 108, 112, in other cases the standardized format can be a format that is more specifically an interchange/exchange/serialized format…SQL statements enriched with annotations or semantic information”, [0043], “The import/export manager 128 can process requests to read, add, change, or remove metadata in the standardized format 120”, [0056], “The converter 168 can be configured to convert metadata in the standard format 120 into a format specific to the client system 108 (e.g., ABAP).”, [0063], “The selection of data 372 can be a query, such as a SQL query. The contents 370 can include metadata elements 376a, 376b, such as elements that provide semantic information about the data elements 374a, 374b.” [0104], “The metadata model 700 can include instructions 708, in this case a SQL statement 710, defining a core metadata model/object having an identifier 712 (which can be used, for example to later access or activate, such as to instantiate, the metadata model).”, [0115], “a SQL statement defining the views.”, [0129], “A group ID field 1260 and a grouping ordinal number field 1262 can be used to preserve the semantics of the conditions as originally expressed (e.g., in SQL).”);
Further Buchmann explicitly teaches translating the first semantic format of the request to a second semantic format compatible with a second version of the distributed metadata repository ([0043], “The import/export manager 128, in some cases, accesses a metadata converter 132 that can convert metadata between formats, such as between the standardized format and another format (e.g., definitions in ABAP).”, [0056-0057] [0115]),
wherein the first semantic format of the request is translated according to a label in the request ([0071], [0063], “The selection of data 372 can be a query, such as a SQL query. The contents 370 can include metadata elements 376a, 376b, such as elements that provide semantic information about the data elements 374a, 374b. The contents 370 can further comprise annotations 378a, 378b, 378c, where an annotation can indicate properties of the artefact 308 or control the use of the artefact, such as defining whether the artefact is exposed to an end user.”, [0090]);
identifying a first set of metadata changes to be applied to the request ([0043], “The import/export manager 128 can process requests to read, add, change, or remove metadata in the standardized format 120 (either directly or indirectly, such as by making changes to the relational database tables 124 that are propagated to the metadata 120).”, [0051]);
applying the first set of metadata changes to the request based on a current version of the subset of metadata ([0036], [0120], “When a metadata model is changed, the version associated with the identifier in the field 1066 can be linked to a prior version of the metadata model, which can be stored in a field 1068.”, [0125], “A field 1212 can store an object version identifier value for the object associated with each record. In some cases, the value stored in the field 1212 can be unique to the given object, and can be incremented when a change is made to the object. For example, record 1216 is shown as having an object version identifier of 56 for the DDLS1 object. If the DDLS1 object is changed again, the object version identifier can be incremented to 57.”); and
accessing the subset of metadata in the distributed metadata repository based at least in part on the current version of the subset of metadata ([0043], [0055], “The user interface 156 or application 160 can be presented with the results of a metadata request, or other information, such as notifications that metadata has changed or regarding the status of a CRUD request. Similarly, the user interface 156 or the application 160 can initiate a CRUD request.”).
Per definition: A rolling upgrade for a distributed metadata repository is a zero-downtime strategy that updates nodes sequentially, one by one (or in small batches), allowing the system to remain available by keeping old and new versions coexisting temporarily, relying on features like data replication, backward compatibility, and graceful failover, common in systems like Oracle Data Guard, Kubernetes Deployments, or distributed databases (e.g., YugabyteDB, OpenSearch). It ensures continuity by upgrading standby nodes first, switching traffic, then upgrading the primary, minimizing disruption compared to traditional big-bang upgrades.
Buchmann implicitly teaches wherein the request is received during a rolling upgrade of the distributed metadata repository ([0034], “it may be desirable to replicate or transfer data from one system to another, such as when migrating from an on-premise database solution to a cloud-based solution. Or, it may be desirable to make data available to another platform, such as through data federation.”, [0036], “Updates that result in creation of a new version of the metadata or otherwise do not affect the availability of the original metadata can be permitted by a larger number of clients.”, [0039], “providing updated metadata (which can be by a push mechanism or a pull mechanism).”, [0079], “the package 510 can be replicated or deployed to various database systems.”);
However, Chatterjee explicitly teaches wherein the request is received during a rolling upgrade of the distributed metadata repository ([0057], [0125-0126], claim 5).
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 Chatterjee’s system into Buchmann’s and by incorporating Chatterjee into Buchmann because both systems are related to organizing and upgrading data in data systems would manage and access static and dynamic data.
11. Regarding claim 2, Buchmann and Chatterjee teach the invention as claimed in claim 1 above and further Buchmann teaches routing the request to a label handling component based at least in part on the label in the request, wherein the first set of metadata changes are based at least in part on the label ([0036], Fig 1, Import/export manager 128 (label handling component), [0043-0045], “The import/export manager 128 can also access various rules 136 useable to determine what metadata is relevant to a particular client request.”, [0051], [0054], “The client system 108 includes a metadata manager 152. The metadata manager 152 can send requests to retrieve (or optionally create, update, or delete) metadata to the import/export manager 128, In particular, the metadata manager 152 can receive metadata from the import/export manager 128, either in response to a request sent by the metadata manager 152 or in response to push of such information by the import/export manager 128. The metadata manager 152 can also receive from the import/export manager 128 information such as notices that metadata 120 indicated as relevant to the client system 108 has been updated, created, or deleted, or status messages (such as error message) relating to a request to retrieve metadata or processing of an action related to metadata (e.g., create, update, delete).”.).
12. Regarding claim 3, Buchmann and Chatterjee teach the invention as claimed in claim 2 above and further Buchmann teaches wherein the request is translated by the label handling component of an intermediate protocol proxy that interfaces with the distributed metadata repository ([0054], [0056], “the metadata can first be processed, such as by sending the metadata to a converter 168. The converter 168 can be configured to convert metadata in the standard format 120 into a format specific to the client system 108 (e.g., ABAP). Or, the converter 168 can maintain the metadata in the same overall format, but can convert the metadata to a different schema. Converted metadata can be stored at the metadata repository 164.”, [0152], “the information can be accessed via an API, such as a web-based API using REST services. In a particular example, the API can use the OData protocol.”).
13. Regarding claim 4, Buchmann and Chatterjee teach the invention as claimed in claim 1 above and further Buchmann teaches wherein an access type of the request is based at least in part on the label, the access type of the request comprising a select operation, an update operation, a read operation, a write operation, or a combination thereof ([0036], [0043-0045], [0054], access type (label in the request) such as select, update, etc.).
14. Regarding claim 5, Buchmann and Chatterjee teach the invention as claimed in claim 1 above and further Buchmann teaches applying, during the rolling upgrade, one or more upgrades to the distributed metadata repository associated with the second version of the distributed metadata repository, wherein the request is received while the distributed metadata repository is in a partially upgraded state ([0003], [0034], “metadata from one system may be useful in another system. For example, it may be desirable to replicate or transfer data from one system to another, such as when migrating from an on-premise database solution to a cloud-based solution. Or, it may be desirable to make data available to another platform, such as through data federation.”, [0036], “Updates that result in creation of a new version of the metadata”, [0039]. Examiner interpretation: the objective of the invention is Upgrading or otherwise modifying attributes of this metadata without disrupting the applications and services that rely on this metadata, resulting in no service outages, errors, data loss, etc.).
15. Regarding claim 6, Buchmann and Chatterjee teach the invention as claimed in claim 5 above and further Buchmann teaches refraining from applying a second set of metadata changes to the request based at least in part on applying the one or more upgrades to the distributed metadata repository ([0036], “a first set of one or more clients may be allowed to read metadata, a second set of one or more clients may be allowed to update metadata, and a third set of one or more clients may be allowed to delete metadata. In at least some cases, only the client which created/provided the metadata to the central repository is permitted to delete the metadata, or to perform updates which overwrite the metadata. Updates that result in creation of a new version of the metadata or otherwise do not affect the availability of the original metadata can be permitted by a larger number of clients.”, Examiner interpretation: the objective of the invention is Upgrading or otherwise modifying attributes of this metadata without disrupting the applications and services that rely on this metadata, resulting in no service outages, errors, data loss, etc.).
16. Regarding claim 7, Buchmann and Chatterjee teach the invention as claimed in claim 1 above and further Buchmann teaches wherein the first set of metadata changes are based at least in part on a current version of a branch of the data management system associated with the subset of metadata ([0036], “Updates that result in creation of a new version of the metadata”, [0061], “Having the original name mapping element 216 can help identify when changes should be propagated to a metadata listing that references a given database artefact/listing, or when two listings should be compared for conflicts.”, [0112-0113], [0261], “The cloud computing services 2410 can be centrally located (e.g., provided by a data center of a business or organization) or distributed (e.g., provided by various computing resources located at different locations, such as different data centers and/or located in different cities or countries).”).
17. Regarding claim 8, Buchmann and Chatterjee teach the invention as claimed in claim 1 above and further Buchmann teaches upgrading all metadata in the distributed metadata repository prior to upgrading one or more applications or services that utilize the metadata in the distributed metadata repository ((0003], [0034], “metadata from one system may be useful in another system. For example, it may be desirable to replicate or transfer data from one system to another, such as when migrating from an on-premise database solution to a cloud-based solution. Or, it may be desirable to make data available to another platform, such as through data federation.”, [0039]. Examiner interpretation: the objective of the invention is Upgrading or otherwise modifying attributes of this metadata without disrupting the applications and services that rely on this metadata, resulting in no service outages, errors, data loss, etc.).
18. Regarding claim 9, Buchmann and Chatterjee teach the invention as claimed in claim 1 above and further Buchmann teaches receiving a second request to access the subset of metadata after upgrading the distributed metadata repository to the second version; and executing the second request without translating the second request or applying representational changes to the subset of metadata if a semantic format of the second request is compatible with the second version of the distributed metadata repository (Fig 1, [0008], “processing metadata requests from multiple clients, where information relevant to different client requests can differ and can be determined based at least in part on relevance identifiers. “Different request from different client is applied).
19. Regarding claim 10, Buchmann and Chatterjee teach the invention as claimed in claim 1 above and further Buchmann teaches wherein accessing the subset of metadata comprises: accessing a first table of the distributed metadata repository while a second table of the distributed metadata repository is upgraded, wherein the first table includes the subset of metadata (Fig 1, central Metadata repository 104 (a distributed metadata repository of a data management system) comprises Tabular representation of entities and related metadata 124, [0043], “The import/export manager 128 can process requests to read, add, change, or remove metadata in the standardized format 120 (either directly or indirectly, such as by making changes to the relational database tables 124 that are propagated to the metadata 120).”, [0119], “FIG. 10B illustrates tables 1050, 1052, 1054, 1056, which can store additional information about the metadata models, including about the systems from which the metadata models, or updates (including deletions) were received.”).
20. Regarding claim 11, Buchmann and Chatterjee teach the invention as claimed in claim 1 above and further Buchmann teaches wherein accessing the subset of metadata comprises: retrieving the subset of metadata from the distributed metadata repository; and transmitting an indication of the subset of metadata to an application or service associated with the request (Fig 1, [0035], retrieve/access and transmitting metadata, [0054], see also Fig 18, 19 and 20, “a data access service”, [0154], [0156-0157], “an OData read request like: [0157]…/sap/opu/odata/sap/CdsMetadataService...”, [0168-0169], “The API can allow all related information for a given object version to be searched. For example, a search request for “cust” can have the form: [0169] . . ./sap/opu/odata/sap/CdsMetadataService/Ddls/?search=cust” and [0246]).
21. Regarding claim 12, Buchmann and Chatterjee teach the invention as claimed in claim 1 above and further Buchmann teaches wherein receiving the request comprises: receiving a request to read or write to one or more rows or columns of a table stored in the distributed metadata repository, wherein the one or more rows or columns comprise the subset of metadata (Figs 7-17, “metadata model information stored in a relational format (table with rows and column).”, [0089], [0156-0168], OData read request).
22. Regarding claim 13, Buchmann and Chatterjee teach the invention as claimed in claim 1 above and further Buchmann teaches identifying a second set of metadata changes that depend on the first set of metadata changes; and applying the second set of metadata changes after applying the first set of metadata changes ([0103], [0107], “the metadata model 700 can include dependencies on how elements are defined”, [0109], Fig 9, [0112-0115], Fig 11, [0181], A metadata repository can be queried to determine whether a new version of the metadata model needs to be created, and, if so, can convert the uploaded model toa persistency format used by the metadata service. In at least some cases, it can be determined whether any metadata models depend on the updated model and, if so, such dependent models can be updated to provide new model versions.”).
23. Regarding claim 14, Buchmann and Chatterjee teach the invention as claimed in claim 13 above and further Buchmann teaches generating a dependency graph that indicates one or more rows, columns, or tables impacted by the first set of metadata changes, wherein identifying the second set of metadata changes is based at least in part on the dependency graph (Fig 9, [0112-0115], Fig 11, 13 (dependency graph), [0122], “a view with reference to metadata models”).
24. Regarding claim 15, Buchmann and Chatterjee teach the invention as claimed in claim 1 above and further Buchmann teaches identifying a second set of metadata changes that are independent of the first set of metadata changes; and applying the second set of metadata changes in parallel with the first set of metadata changes ([0049]).
25. Regarding claims 16-19, those claims recite a system performs the method of claims 1, 2, 5 and 6 respectively and are rejected under the same rationale.
26. Regarding claim 20, this claim recites a non-transitory computer-readable medium storing code for data management, the code comprising instructions executable by at least one processor to perform the method of claim 1 and is rejected under the same rationale.
Respond to Amendments and Arguments
8. In the remarks, applicant amended claims 1, 5, 16, 18, and 20 to recite new features “wherein the request is received during a rolling upgrade of the distributed metadata repository”, and argued that " Buchmann " did not teach the invention recited in Claim 1 as amended.
Applicant's arguments received on 10/28/2025 have been fully considered and is persuasive but it is moot in view of a new rejection based on Buchmann in view of Chatterjee presented above, 35 USC § 103.
CONCLUSION
The Applicant’s amendment necessitated a new ground of rejection. Therefore, THIS ACTION IS MADE FINAL. Applicants are reminded of the extension of time policy as set forth in 37 C.F.R. § 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 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