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 .
Remarks
This action is in response to the amendments received on 6/9/25. Claims 1-4 and 6-21 are pending in the application. Applicants' arguments have been carefully and respectfully considered.
Claim(s) 1-4, 6, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Preston–Werner, Tom, Semantic Versioning 2.0.0., Retrieved by the Wayback Machine as of May 29, 2022 and further in view of Chatterjee et al. (US 2023/0259498).
Claim(s) 7-14 are rejected under 35 U.S.C. 103 as being unpatentable over McCauley et al. (US 7,236,989) and further in view of Chatterjee et al. (US 2023/0259498).
Claim(s) 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Chatterjee et al. (US 2023/0259498) and further in view of Gauthier et al. (US 2008/0005182).
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.
Claim(s) 1-6 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Preston–Werner, Tom, Semantic Versioning 2.0.0., Retrieved by the Wayback Machine as of May 29, 2022 and further in view of Chatterjee et al. (US 2023/0259498).
With respect to claim 1, Preston–Werner teaches a system, comprising:
machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least:
versioning model for a schema lifecycle (Preston–Werner, page 1, summary, Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.);
determine a first revision … based at least in part on the versioning model (Preston–Werner, top of page 2, Once you identify your public API, you communicate changes to it with specific increments to your version number);
identify a second revision… (Preston–Werner, top of page 2, Once you identify your public API, you communicate changes to it with specific increments to your version number) based at least in part on a comparison of the plurality of data attributes of the first revision to a plurality of data attributes of the second revision (Preston–Werner, top of page 2, bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.);
determine that the first revision of the schema is compatible with the second revision of the schema based at least in part on one or more compatibility rules (Preston–Werner, page 1, summary, Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. & page 2, 7. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API.);
modify a second classification of the second revision of the schema to indicate that the first revision of the schema is compatible with second revision of the schema (Preston–Werner, page 2, 7. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API.);
initiate installation of the second revision of the schema based at least in part on a determination of compatibility (Preston–Werner, page 3, verify that any package upgrades function as advertised…. What you can do is let Semantic Versioning provide you with a sane way to release and upgrade packages without having to roll new versions of dependent packages, saving you time and hassle.).
Preston–Werner doesn't expressly discuss a computing device comprising a processor and a memory and the schema defining a structure of hey what’s up data.
Chatterjee teaches a computing device comprising a processor and a memory (Chatterjee, Fig. 2); and
obtain a versioning model for a schema lifecycle from a management data store (Chatterjee, pa 0063, producer schemas 324, consumer schemas 328, and/or other metadata 320 associated with data processors 302 is referenced from or stored in the corresponding nodes in pipeline DAG 322. For example, each node in pipeline DAG 322 could include one or more producer schemas 324 for data generated by the corresponding data processor 302 and/or one or more consumer schemas 328 for data consumed by the corresponding data processor 302.)
determine a first revision of the schema based at least in part on the versioning model (Chatterjee, pa 0065, As with other metadata 320, schema changes 318 can be received in real-time or near-real-time from data processors 302 … After a schema change is received, analysis engine 222 validates the schema change, transmits an acknowledgment of the schema change, and updates the corresponding producer schema or consumer schema in metadata 320.) the schema defining a structural data;
identify a second revision of the schema based at least in part on a comparison of the plurality of data attributes of the first revision to a plurality of data attributes of the second revision (Chatterjee, pa 0067, Analysis engine 222 also performs compatibility checks 332 that determine whether the schema change to a producer schema interferes with the consumption of data represented by the producer schema by downstream data processors 302 included in schema dependencies 330. As shown in FIG. 3, compatibility checks 332 are used to classify schema changes 318 as destructive changes 340, incompatible changes 342, and/or compatible changes 344.);
determine that the first revision of the schema is compatible with the second revision of the schema based at least in part on one or more compatibility rules (Chatterjee, pa 0070, When a schema change removes a required field in a producer schema, analysis engine 222 determines that the schema change is compatible with a consumer schema if the field is not included in the consumer schema and incompatible with a consumer schema if the field is included in the consumer schema.);
initiate installation of the second revision of the schema based at least in part on a determination of compatibility (Chatterjee, pa 0081, After schema updates 314 are made to the producer schema for a given data processor 302, management engine 224 redeploys the data processor with schema updates 314 to allow the data processor to operate based on schema updates 314.).
It would have been obvious at the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Preston–Werner with the teachings of Chatterjee because it provides efficient operation and updating of data pipelines that depend on the changed schema data (Chatterjee, pa 0006).
With respect to claim 2, Preston–Werner in view of Chatterjee teaches a system of claim 1, wherein the machine-readable instructions further cause the computing device to modify the classification of a subsequent revision of the schema (Preston–Werner, page 1, summary, Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.).
With respect to claim 3, Preston–Werner in view of Chatterjee teaches a system of claim 1, wherein the machine-readable instructions further cause the computing device to at least generate one or more compatibility notifications (Chatterjee, pa 0118, outputting a notification of the incompatibility to an entity associated with at least one of the first data processor or the second data processor).
With respect to claim 4, Preston–Werner in view of Chatterjee teaches a system of claim 3, wherein the machine-readable instructions further cause the computing device to at least: store the one or more compatibility notifications; send the one or more compatibility notifications; or send a request that directs a client device to display the one or more compatibility notifications (Chatterjee, pa 0118, outputting a notification of the incompatibility to an entity associated with at least one of the first data processor or the second data processor).
With respect to claim 6, Preston–Werner in view of Chatterjee teaches a system of claim 1, wherein the versioning model is based at least in part on a semantic versioning model (Preston–Werner, top of page 2, We call this system “Semantic Versioning.” Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.).
With respect to claim 21, Preston–Werner in view of Chatterjee teaches the system of claim 1, wherein the machine-readable instructions further cause the computing device to at least determine a second classification for a second revision of the schema based at least in part on the versioning model and the one or more classification rules (Preston–Werner, page 1, summary, Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.).
Claim(s) 7-14 are rejected under 35 U.S.C. 103 as being unpatentable over McCauley et al. (US 7,236,989) and further in view of Chatterjee et al. (US 2023/0259498).
With respect to claim 7, McCauley teaches a system, comprising:
a computing device comprising a processor and a memory (McCauley, Col. 24 Li. 15-36); and
machine-readable instructions stored in the memory (McCauley, Col. 24 Li. 15-36) that, when executed by the processor, cause the computing device to at least:
obtain a states model for a schema lifecycle from a data store (McCauley, abstract, providing a lifecycle for information in virtual content repository (VCR) are provided.);
determine a first state for a first revision based at least in part on the states model (McCauley, Col. 13 Li. 17-19, if a lifecycle is associated with a schema, nodes instantiated based on the schema will also be associated with the lifecycle. & Col. 13 Li. 43-44, An exemplary lifecycle for a content node representing a news article is illustrated in Table 6 and FIG. 2 & Col. 14 Li. 32-39, The news article can be modified by user(s) and/or process( es) while in the Draft state and then submitted for approval. By way of an example, a user can check-out the news article (assuming it is under version control), modify it, and then check-in the article with the changes. Before checking the article in, the user can change the state property from "Draft" to "Ready for Approval" in order to bring about a transition to the Ready for Approval 208 state. Examiner Note: edits in Draft state provide a first revision. News article is an example referring to a content node, however as cited, schema nodes are treated the same);
identify a second revision (McCauley, Fig. 2, Published to Draft & Col. 14 Li. 57-60, The D2 decision point specifies that a user/process in the Approver role can cause a transition to the Draft state 204 or to the Published state 212. Examiner note: Approver rejects at D2 to allow creator to edit draft a 2nd time);
determine a first classification of the second revision (McCauley, Col. 23 Li. 34-38, the node /Repo1/FiscalPlan is checked out by a user, which has the effect of creating a new version (version 2) in the VCR, locking the new version, and assigning it to the user.);
evaluate the second revision (McCauley, Col. 14 Li. 54-65, users/processes that are in the assigned users/groups/roles can review it while it is in the Ready for Approval state. From the Ready for Approval state, there is a transition through decision point D2 210. The D2 decision point specifies that a user/process in the Approver role can cause a transition to the Draft state 204 or to the Published state 212. If the transition is to the Draft state, the action associated with the transition will be to Reject the article. A rejected article will repeat the lifecycle path from Draft to Ready for Approval. If the transition is to the Published state, however, the action will be to Accept the article.);
determine a change in the schema between the first revision of the schema and the second revision of the schema (McCauley, Col. 14 Li. 54-65, users/processes that are in the assigned users/groups/roles can review it while it is in the Ready for Approval state. From the Ready for Approval state, there is a transition through decision point D2 210. The D2 decision point specifies that a user/process in the Approver role can cause a transition to the Draft state 204 or to the Published state 212. If the transition is to the Draft state, the action associated with the transition will be to Reject the article. A rejected article will repeat the lifecycle path from Draft to Ready for Approval. If the transition is to the Published state, however, the action will be to Accept the article.); and
perform an automated action based at least in part on the change in the schema (McCauley, Col. 13 Li. 21-24, a node can transition from a current state to a new state. Before, during or after a transition, one or more actions can be performed. Actions can optionally operate on and/or utilize the node. Actions can include any type of processing that can be invoked in the course of the lifecycle.).
McCauley doesn't expressly discuss revision of a schema, the schema defining a structure of data, evaluate the second revision of the schema and determine a change in the schema between the first revision of the schema and the second revision of the schema.
Chatterjee teaches revision of a schema, the schema defining a structure of data (Chatterjee, pa 0064, Schema changes 318 could include (but are not limited to) adding or removing an optional field, adding or removing a required field, renaming a field, changing the field type ( e.g., data type) of a field, and/or changing the primary key in a given producer or consumer schema.), identify a second revision of the schema based at least in part on a comparison of the plurality of data attributes of the first revision to a plurality of data attributes of the second revision (Chatterjee, pa 0065, As with other metadata 320, schema changes 318 can be received in real-time or near-real-time from data processors 302 … After a schema change is received, analysis engine 222 validates the schema change, transmits an acknowledgment of the schema change, and updates the corresponding producer schema or consumer schema in metadata 320.);
determine a first classification of the second revision of the schema (Chatterjee, pa 0067, As shown in FIG. 3, compatibility checks 332 are used to classify schema changes 318 as destructive changes 340, incompatible changes 342, and/or compatible changes 344.);
evaluate the second revision of the schema (Chatterjee, pa 0067, Analysis engine 222 also performs compatibility checks 332 that determine whether the schema change to a producer schema interferes with the consumption of data represented by the producer schema by downstream data processors 302 included in schema dependencies 330. As shown in FIG. 3, compatibility checks 332 are used to classify schema changes 318 as destructive changes 340, incompatible changes 342, and/or compatible changes 344.);
determine a change in the schema between the first revision of the schema and the second revision of the schema based at least in part on an evaluation of the second revision (Chatterjee, pa 0070, When a schema change removes a required field in a producer schema, analysis engine 222 determines that the schema change is compatible with a consumer schema if the field is not included in the consumer schema and incompatible with a consumer schema if the field is included in the consumer schema.).
It would have been obvious at the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified McCauley with the teachings of Chatterjee because it provides efficient operation and updating of data pipelines that depend on the changed schema data (Chatterjee, pa 0006).
With respect to claim 8, McCauley in view of Chatterjee teaches the system of claim 7, wherein the machine-readable instructions that cause the computing device to perform the automated action further cause the computing device to at least: transition the schema lifecycle from the first revision of the schema to the second revision of the schema; and modify the first revision of the schema with the first state to at least one of a deprecated state or retired state (McCauley, Table 6, Published state to Retired state & Col. 17 Li. 34-36, a user/process can navigate to a node and perform a delete action. In one embodiment, deleting a node changes its state ( e.g., to Retired or Deleted).).
With respect to claim 9, McCauley in view of Chatterjee teaches the system of claim 7, wherein the machine-readable instructions that cause the computing device to determine the first state further cause the computing device to at least: determine the first state is a live state; and transition the schema lifecycle from the first state to the live state (McCauley, Col. 14 Li. 63-65, If the transition is to the Published state, however, the action will be to Accept the article.).
With respect to claim 10, McCauley in view of Chatterjee teaches the system of claim 7, wherein the machine-readable instructions that cause the computing device to determine the first state further cause the computing device to at least identify the first state is a draft state (McCauley, Table 6, Draft state & Col. 14 Li. 32-36, The news article can be modified by user(s) and/or process( es) while in the Draft state and then submitted for approval. By way of an example, a user can check-out the news article (assuming it is under version control), modify it, and then check-in the article with the changes).
With respect to claim 11, McCauley in view of Chatterjee teaches the system of claim 7, wherein the machine-readable instructions that cause the computing device to determine the first state further cause the computing device to at least: determine the first state is a deprecated state; and transition the schema lifecycle from the first state to the deprecated state (McCauley, Table 6, Published state to Retired state & Col. 17 Li. 34-36, a user/process can navigate to a node and perform a delete action. In one embodiment, deleting a node changes its state ( e.g., to Retired or Deleted).).
With respect to claim 12, McCauley in view of Chatterjee teaches the system of claim 7, wherein the machine-readable instructions that cause the computing device to determine the first state further cause the computing device to at least: determine the first state is a retired state; transition the schema lifecycle from the first state to a retired state (McCauley, Table 6, Published state to Retired state & Col. 17 Li. 34-36, a user/process can navigate to a node and perform a delete action. In one embodiment, deleting a node changes its state ( e.g., to Retired or Deleted).); and create a second lineage.
With respect to claim 13, McCauley in view of Chatterjee teaches the system of claim 9, wherein the machine-readable instructions that cause the computing device to determine the first state further cause the computing device to at least: determine the first state is a discarded state; and in response to a determination of the discarded state, perform an action based at least in part on one or more state rules (McCauley, Table 6, Published state to Retired state & Col. 17 Li. 34-36, a user/process can navigate to a node and perform a delete action. In one embodiment, deleting a node changes its state ( e.g., to Retired or Deleted).).
With respect to claim 14, McCauley in view of Chatterjee teaches the system of claim 7, wherein the schema comprises one or more data structures (Chatterjee, Fig. 3, metadata 320 with schemas 324, 326, 328).
Claim(s) 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Chatterjee et al. (US 2023/0259498) and further in view of Gauthier et al. (US 2008/0005182).
With respect to claim 15, Chatterjee teaches a system, comprising: a computing device comprising a processor and a memory; and machine-readable instructions stored in the memory (Chatterjee, Fig. 2) that, when executed by the processor, cause the computing device to at least:
determine one or more storage rules (Chatterjee, pa 0068, destructive changes 340 include schema changes 318 to producer schemas 324 that disrupt the consumption of the corresponding data by all downstream data processors 302. & pa 0069, incompatible changes 342 and compatible changes 344 are determined with respect to individual data processors 302 that consume data represented by a change to a producer schema. A schema change to a producer schema is an incompatible change with respect to a downstream data processor 302 when the schema change interferes with the downstream data processor's consumption of the corresponding data.);
identify a schema stored in a data store, the schema defining a structure of data (Chatterjee, pa 0066, analysis engine 222 uses pipeline DAG 322 to determine any schema dependencies 330 associated with the schema change.) and having a schema lineage where the schema lineage is a location to store revisions to the schema (Chatterjee, pa 0047, Analysis engine 222 also stores and tracks schemas for data that is produced or consumed by each source connector 104, intermediate processor 108, and sink connector 110);
identify a first revision in the schema lineage (Chatterjee, pa 0065, As with other metadata 320, schema changes 318 can be received in real-time or near-real-time from data processors 302 … After a schema change is received, analysis engine 222 validates the schema change, transmits an acknowledgment of the schema change, and updates the corresponding producer schema or consumer schema in metadata 320. & pa 0066, analysis engine 222 uses pipeline DAG 322 to determine any schema dependencies 330 associated with the schema change.);
determine a first classification (Chatterjee, pa 0067, As shown in FIG. 3, compatibility checks 332 are used to classify schema changes 318 as destructive changes 340, incompatible changes 342, and/or compatible changes 344.) and a first state of the first revision of the schema (Chatterjee, pa 0074, If the data processor is set to "opt in" to schema propagations 334 and the consumer schema for the data processor is compatible with a given set of schema changes 318 to a topic schema for a topic consumed by the data processor, analysis engine 222 determines that all fields in the topic schema to which the set of schema changes 318 are made are to be propagated to the data processor & pa 0078, management engine 224 discontinues the execution of any data processor with a consumer schema that is determined by analysis engine 222 to be incompatible with a corresponding upstream topic schema. Examiner note: state of revision is propagated or discontinued);
in response to a determination of the first classification and the first state of the first revision, store the first revision, the first classification, and the first state in the data store based at least in part on the one or more storage rules (Chatterjee, pa 0081, After schema updates 314 are made to the producer schema for a given data processor 302, management engine 224 redeploys the data processor with schema updates 314 to allow the data processor to operate based on schema updates 314.).
Chatterjee doesn't expressly discuss perform an automated action based at least in part on storing the first revision and the first classification or the first state.
Gauthier teaches perform an automated action based at least in part on storing the first revision and the first classification or the first state (Gauthier, pa 0054, The upgrade rules 345 specify whether or not to automatically upgrade the document instances 160 that link to the document type definition 162, to make the document instances 160 be compatible with changes that have occurred to the configuration set 172.).
It would have been obvious at the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Chatterjee with the teachings of Gauthier because it ensures updates to documents linked to changed schemas (Gauthier, pa 0004, 0017).
With respect to claim 16, Chatterjee in view of Gauthier teaches the system of claim 15, wherein the machine-readable instructions further cause the computing device to store the first revision in a temporary lineage of the schema (Chatterjee, pa 0065, After a schema change is received, analysis engine 222 validates the schema change, transmits an acknowledgment of the schema change, and updates the corresponding producer schema or consumer schema in metadata 320).
With respect to claim 17, Chatterjee in view of Gauthier teaches the system of claim 16, further comprising: storing a state of the revision based at least in part on the one or more storage rules; and modifying the state of the revision to the first state (Chatterjee, pa 0079, management engine 224 performs schema updates 314 that carry out schema propagations 334 associated with compatible changes 344. As described above, analysis engine 222 determines that all fields from a producer schema for a data processor are to be propagated to a producer schema for a downstream data processor when the downstream data processor "opts in" to schema propagations 334 from the data processor and the topic schema for the topic to which the data processor writes data is compatible with a corresponding consumer schema for the downstream data processor).
With respect to claim 18, Chatterjee in view of Gauthier teaches the system of claim 15, wherein the first state or the first classification of the first revision is transitioned to a second state or second classification (Chatterjee, pa 0078, management engine 224 discontinues the execution of any data processor with a consumer schema that is determined by analysis engine 222 to be incompatible with a corresponding upstream topic schema. Examiner note: a propagated revision can be determined to be incompatible at a downstream consumer schema).
With respect to claim 19, Chatterjee in view of Gauthier teaches the system of claim 15, wherein the first revision is stored in the schema lineage based at least in part on the first state (Chatterjee, pa 0081, After schema updates 314 are made to the producer schema for a given data processor 302, management engine 224 redeploys the data processor with schema updates 314 to allow the data processor to operate based on schema updates 314.).
With respect to claim 20, Chatterjee in view of Gauthier teaches the system of claim 15, wherein the first revision is stored in the schema lineage based at least in part on the first classification (Chatterjee, pa 0081, After schema updates 314 are made to the producer schema for a given data processor 302, management engine 224 redeploys the data processor with schema updates 314 to allow the data processor to operate based on schema updates 314.).
Response to Arguments
35 U.S.C. 103
Claims 1-7:
Applicant argues that Preston-Werner doesn’t expressly teach “obtaining a versioning model for a schema lifecycle from a management data store” because Preston-Werner does not show or suggest application of these rules and the Office is relying on impermissible hindsight. The Examiner respectfully disagrees. The entire point of Preston-Werner is to show that the versioning changes can be managed and labeled for use in applications. While Preston-Werner doesn’t expressly disclose “obtaining” it is clear that this model is referenced when changes to the schema occur. Further, Chatterjee closes that schema changes must be validated when determining how they affect the schema (pa 0065). In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
Applicant argues that the references fail to show that the schema defines the structure of data as in amended claim 1. The Examiner respectfully disagrees. The schema of Chatterjee can change by adding or removing an optional field, adding or removing a required field, renaming a field, changing the field type ( e.g., data type) of a field, and/or changing the primary key in a given producer or consumer schema. (Chatterjee, pa 0064).
Applicant argues that the references fail to disclose “identify a second revision of the schema based at least in part on a comparison of the plurality of data attributes of the first revision to a plurality of data attributes of the second revision” at least without additional hindsight and that Preston-Werner discloses communicating changes rather than identifying revisions. The Examiner respectfully disagrees. The reason for the documents of Preston-Werner and Chatterjee are to identify revisions throughout the lifetime of schemas and software. This inherently provides an identification of more than one revision throughout schema lifetime.
Applicant additionally argues that the references fail to teach “initiate installation of the second revision of the schema based at least in part on a determination of compatibility” without the use of impermissible hindsight as discussed above. The Examiner respectfully disagrees. The upgrades that are managed in the Preston-Werner reference are meant to be used and therefore, they are installed as they are verified. Further, the Chatterjee reference explicitly discloses that the schema updates allow the data processor to operate (pa 0081). The usage of such changes in order to operate the system as normal as described in the cited references equivalent to “installation”, given the ordinary usage of the term.
Claims 7-14:
Applicant argues that McCauley and Chatterjee fails to disclose “obtain a states model for a schema lifecycle from a data store” because the schema node of McCauley is different from the schema of the claims. The examiner agrees however, the lifecycle of the schema nodes discussed in McCauley would be easily applicable to a schema as claimed. Chatterjee discusses schema changes. Therefore the combination of McCauley in Chatterjee teaches the claim.
Applicant argues that the references do not teach “identify a second revision of the schema based at least in part on a comparison of the plurality of data attributes of the first revision to a plurality of data attributes of the second revision” because McCauley discloses that if an article is not approved it can “repeat the lifecycle path from Draft to Ready to Approve” and Chatterjee discloses only receiving a schema change. The reason for the documents of McCauley and Chatterjee are to identify revisions throughout the lifetime of data. This inherently provides an identification of more than one revision throughout data lifetime.
Claims 15-20:
Applicant argues that Chatterjee fails to teach “determine one or more storage rules” because the compatibility checks do not show or suggest storage rules. The Examiner respectfully disagrees. Compatibility checks must utilize storage rules to determine what the rules of schema changes are allowed in view of the producer schema and schema dependencies. When determining destructive, incompatible, and/or compatible changes, storage rules define what changes are destructive, incompatible, and/or compatible. Therefore, Chatterjee teaches determining one or more storage rules by ensuring that schema changes are compatible through compatibility checks.
Applicant argues that Chatterjee fails to teach “identify a schema stored in a data store, the schema defining the structure for data and having a schema lineage where the schema lineage is a location to store revisions to the schema” because using the pipeline DAG to determine any schema dependencies associate with the schemas get change is not equivalent. The Examiner respectfully disagrees. Paragraphs 0064 of Chatterjee teaches that schema changes may be made to producer schemas and/or consumer schemas for individual data processors. When a schema change is received, the pipeline DAG is referenced to determine any schema dependencies (pa 0065-0066). The pipeline DAG includes the schemas therefore providing “identify a schema stored in a data store.” Paragraph 0055 of Chatterjee further defines the producer and consumer schemas which represent data generated or consumed by data processors, respectively. The producer and consumer schemas thus define the structural data as claimed. Chatterjee further discloses that the analysis engine can update the corresponding producer schema and/or consumer schema in metadata 320. As seen in figure 3, this can store the revisions to the schema.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 BRITTANY N ALLEN whose telephone number is (571)270-3566. The examiner can normally be reached M-F 9 am - 5:00 pm EST.
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 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 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.
/BRITTANY N ALLEN/ Primary Examiner, Art Unit 2169