DETAILED ACTION
Remarks
This communication is in response to the amendment/arguments filed on May 14, 2026 and RCE June 5, 2026 has been fully considered. Claims 1-20 are pending for examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. 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 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.
The examiner requests, in response to this Office action, supports are shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application.
When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111(c).
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on June 5, 2026 has been entered.
Response to Arguments
Applicant's arguments filed May 14, 2026 have been fully considered but they are not persuasive.
In response to Applicant’s argument on pages 9-15 about claims 1, 8 and 15 that ATHAVALE does not disclose or suggest receiving data request information that includes a combination of business requirement information, pipeline information, and dataset information, as recited in claims 1, 8 and 15 is acknowledged but not deemed to be persuasive.
Athavale [0035-0036], [0055-0056] discloses that a network configured to provide democratized metadata collection and analysis, in accordance with some embodiments. The network includes a plurality of data sources providing streaming data including metadata. The streaming data (i.e., a data pipeline) may be related to services and/or products provided by an online portal, such as an e-commerce platform (i.e., a business platform) or other interface. The plurality of data sources (i.e., dataset information) provides streaming data (e.g., a data pipeline) to a data ingestion system. The data ingestion system is configured to receive the streaming data from the plurality of data sources (i.e., receiving pipeline and dataset information)… the data ingestion system is configured to store metadata associated with each event in the data pipeline in a combined metadata repository (i.e., business requirement information). The combined metadata repository is configured to store all metadata for events received by the data ingestion system (i.e., data request information that includes business requirement information, pipeline information, and dataset information), regardless of the platform used to ingest the metadata, source of the metadata/events. Therefore, Athavale discloses the above limitation of claims 1, 8 and 15.
Applicant’s arguments with respect to claim(s) 1, 8 and 15 that “wherein the business requirement information comprises information about one or more performance indicators that measure success of a data pipeline” have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Athavale et al. (US Patent Publication No. 2020/0379987 A1, ‘Athavale’, hereafter) in view of Krishnan et al. (US Patent No. 11,537,592 B1, ‘Krishnan’, hereafter) and further in view of Palmer et al. (US Patent Publication No. 2011/0166883 A1, ‘Palmer’, hereafter).
Regarding claim 1. Athavale teaches a method, comprising:
receiving, by a device, data request information that includes business requirement information, pipeline information, and dataset information (a network configured to provide democratized metadata collection and analysis, in accordance with some embodiments. The network includes a plurality of data sources providing streaming data including metadata. The streaming data (i.e., a data pipeline) may be related to services and/or products provided by an online portal, such as an e-commerce platform (i.e., a business platform) or other interface. The plurality of data sources (i.e., dataset information) provides streaming data (e.g., a data pipeline) to a data ingestion system. The data ingestion system is configured to receive the streaming data from the plurality of data sources (i.e., receiving pipeline and dataset information)… the data ingestion system is configured to store metadata associated with each event in the data pipeline in a combined metadata repository (i.e., business requirement information). The combined metadata repository is configured to store all metadata for events received by the data ingestion system (i.e., data request information that includes business requirement information, pipeline information, and dataset information), regardless of the platform used to ingest the metadata, source of the metadata/events, Athavale [0035-0036], [0055-0056]);
processing, by the device, the data request information to generate metadata using a metadata schema included in the data request information (Athavale [0038] and [0048] teaches each result set identified by the platform-agnostic query, the query system identifies a platform associated with the event that generated the metadata. Athavale [0057] teaches that the query system is configured to perform metadata schema validation. FIG. 8 illustrates a method 400 of metadata schema validation, in accordance with some embodiments. At step 402, the query system extracts data from one or more deployed metric calculators (i.e., obtains data from a messaging system). At step 404, the query system generates a schema for the extracted metadata. The schema may be generated based on one or more schema generation rules stored by the query system. The schema generation rules may be user defined (i.e., customized metadata schema));
storing, by the device, the metadata in a repository (Each event in the data pipeline includes metadata associated with the event. In some embodiments, the data ingestion system is configured to store metadata associated with each event in the data pipeline in a combined metadata repository, Athavale [0036]. The metadata stored in the combined metadata repository and/or any sub-repository may be extracted from the data pipeline using one or more processing platforms … The combined metadata repository collects metadata from all potential sources in single location enabling cross-platform searching of metadata during exploration, Athavale [0056]); and
Athavale does not teach
validating, by the device, the metadata in the repository based on validation rules and to generate validated metadata;
determining, by the device and based on applying approval criteria to the validated metadata, whether the validated metadata is approved or disapproved;
selectively: merging, by the device, the validated metadata to the repository based on the validated metadata being approved; or
notifying, by the device, a requester based on the validated metadata being disapproved.
However, Krishnan teaches
validating, by the device, the metadata in the repository based on validation rules and to generate validated metadata (the memory 204 may be configured to store data, data structures, and electronic information associated with one or more metadata change consensus notification messages, metadata change messages, metadata change approval messages, smart contract, metadata change validation messages, Krishnan, Col 17, lines 20-60. … the governance circuitry 220 may be configured to generate a smart contract in response to receipt, by the communications circuitry of the metadata change approval message from each node device impacted by the change in the metadata data structure. In some embodiments, the governance circuitry 220 may be configured to generate, based on the smart contract, a metadata change validation message indicating validity of the change in the metadata data structure, Krishnan, Col 21, lines 51-65);
determining, by the device and based on applying approval criteria to the validated metadata, whether the validated metadata is approved or disapproved (Krishnan Col 26, line 57 – Col 27, line 24 teaches (2) send consensus notifications (e.g., metadata change consensus notification messages) to all parties involved (e.g., impacted node devices); (3) invoke a smart contract if approval (e.g., metadata change approval messages) received from all parties involved or, if the requested changes are not approved by all of the parties involved, reject the requested changes. Krishnan, Col 10, lines 49-56 teaches a metadata change validation message may be a receipt produced to indicate that: (1) a metadata change approval message has been received from all parties involved (e.g., all of the impacted node devices); (2) checks on the database side are performed to verify the changes; (3) a confirmation has been made that the requested changes have been performed on the database side with all of the parties involved (i.e., items (1), (2) and (3) are considered criteria to be met before the validated metadata is approved or disapproved));
selectively: merging, by the device, the validated metadata to the repository based on the validated metadata being approved (Krishnan, Col 17, lines 20-60, Col 26, line 57 – Col 27, line 24, Col 6, lines 5-30); or
notifying, by the device, a requester based on the validated metadata being disapproved ((2)send consensus notifications (e.g., metadata change consensus notification messages) to all parties involved (e.g., impacted node devices); (3) invoke a smart contract if approval (e.g., metadata change approval messages) received from all parties involved or, if the requested changes are not approved by all of the parties involved, reject the requested changes, Col 26, line 57 – Col 27, line 24).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention was made having the teachings of Athavale and Krishnan before him/her, to modify Athavale with the teaching of Krishnan’s metadata management through blockchain technology. One would have been motivated to do so for the benefit of providing a metadata management (MDM) system provided herein solves the above problems by identifying and validating changes in metadata data structures in metadata blocks advantageously eliminating metadata repository storage to a larger extent; automatically documenting and discovering the data relationship; and enabling the performance of analytics at the transaction level with the block information (Krishnan, Abstract, Col 1, lines 25-28, Col 5, lines 15-19).
Athavale and Krishnan do not teach
wherein the business requirement information comprises information about one or more performance indicators that measure success of a data pipeline.
However, Palmer teaches
wherein the business requirement information comprises information about one or more performance indicators that measure success of a data pipeline (Palmer [0070] discloses continuous tracking of key performance indicators crucial to identifying deviations from plan as well as enabling the celebration of successes where performance exceeds plan, a reliable stream of performance data (i.e., performance indicators) that enables the organization (i.e., business requirement information comprises information about one or more performance indicators that measure success of a data pipeline) to focus on the right areas of development and that is also useable for performance-based conversations, efficient data collection processes and reliable data storage and management solutions, and user-friendly access to the information).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention was made having the teachings of Athavale, Krishnan and Palmer before him/her, to further modify Athavale with the teaching of Palmer’s system and methods for modeling healthcare costs, predicting same, and targeting improved healthcare quality and profitability. One would have been motivated to do so for the benefit of obtaining data from multiple sources, and historical data is also obtained and stored in the database. Once the data is obtained and coalesced into a coherent single data source, the data is analyzed to produce metrics which correspond to best practices for outcomes and financial success (Palmer, Abstract, [0071]).
Regarding claim 2. Athavale as modified teaches, further comprising: performing one or more launch procedures based on merging the validated metadata to the repository (Krishnan, Col 17, lines 20-60, Col 6, lines 5-30).
Regarding claim 3. Athavale as modified teaches, wherein performing the one or more launch procedures comprises: loading the validated metadata in a data warehouse associated with a big data application for query and analysis (Krishnan, Col 17, lines 20-60, Col 20, lines 12-23, Col 6, lines 5-30).
Regarding claim 6. Athavale as modified teaches, wherein processing the data request information to generate the metadata comprises: processing the data request information, the metadata schema, to generate the metadata in a standardized format (Athavale [0036], [0048], [0057]).
Claims 4-5 and 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Athavale et al. (US Patent Publication No. 2020/0379987 A1, ‘Athavale’, hereafter) in view of Krishnan et al. (US Patent No. 11,537,592 B1, ‘Krishnan’, hereafter) in view of Palmer et al. (US Patent Publication No. 2011/0166883 A1, ‘Palmer’, hereafter) and further in view of Sankar et al. (US Patent Publication No. 2017/0220426 A1, ‘Sankar’, hereafter).
Regarding claim 4. Athavale, Krishnan, Palmer do not teach
wherein performing the one or more launch procedures comprises: executing a retention policy to delete or retain data in a data pipeline based on the validated metadata.
However, Sankar teaches
wherein performing the one or more launch procedures comprises: executing a retention policy to delete or retain data in a data pipeline based on the validated metadata (Sankar [0009-0010]).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention was made having the teachings of Athavale, Krishnan, Palmer and Sankar before him/her, to further modify Athavale with the teaching of Sankar’s maintaining files in a related file system. One would have been motivated to do so for the benefit of providing a system for maintaining files in a retained file system (FS) is disclosed. A restoration system of the present subject matter automatically recovers an original version of a corrupted retained file from a trusted backup system that may be associated with the retained FS. A retained file may be understood as a file on which a retention policy is applied and is therefore retained in the retained FS (Sankar, Abstract, [0010]).
Regarding claim 5. Athavale as modified teaches, wherein performing the one or more launch procedures comprises: updating schema definitions for datasets in a data pipeline based on the validated metadata (Sankar [0014], [0024]).
Regarding claim 10. Athavale as modified teaches, wherein the one or more processors, to validate the metadata in the repository, are configured to: validate the metadata for compliance with data retention policies (Sankar [0024]).
Regarding claim 11. Athavale as modified teaches, wherein the one or more processors, to validate the metadata in the repository, are configured to: validate the metadata for compliance with predefined naming conventions (Sankar [0024]).
Claims 7-9, 12 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Athavale et al. (US Patent Publication No. 2020/0379987 A1, ‘Athavale’, hereafter) in view of Krishnan et al. (US Patent No. 11,537,592 B1, ‘Krishnan’, hereafter) in view of Palmer et al. (US Patent Publication No. 2011/0166883 A1, ‘Palmer’, hereafter) and further in view of Li et al. (US Patent Publication No. 2008/0072217A1, ‘Li’, hereafter).
Regarding claim 7. Athavale as modified teaches, wherein the repository is a centralized, protected repository with version control (customized policy for version control configured to set a version control customized policy; a version control repository; and the above-mentioned apparatus for performing version control customized policy configured to perform said version control customized policy with said version control repository, Li [0013], [0023]).
Regarding claim 8. Athavale teaches a device, comprising:
one or more processors (The instructions, when executed by a processor cause a device to perform operations, Athavale [0005]. The system 2 is a representative device and may comprise a processor subsystem, Athavale [0018-0021], [0031]) configured to:
receive data request information that includes business requirement information, pipeline information, and dataset information (a network configured to provide democratized metadata collection and analysis, in accordance with some embodiments. The network includes a plurality of data sources providing streaming data including metadata. The streaming data may be related to services and/or products provided by an online portal, such as an e-commerce platform or other interface. The plurality of data sources provides streaming data (e.g., a data pipeline) to a data ingestion system… the data ingestion system is configured to store metadata associated with each event in the data pipeline in a combined metadata repository. The combined metadata repository is configured to store all metadata for events received by the data ingestion system, regardless of the platform used to ingest the metadata, source of the metadata/events, Athavale [0035-0036], [0055-0056]);
process the data request information to generate metadata using a customized metadata schema included in the data request information (Athavale [0038] and [0048] teaches each result set identified by the platform-agnostic query, the query system identifies a platform associated with the event that generated the metadata. Athavale [0057] teaches that the query system is configured to perform metadata schema validation. FIG. 8 illustrates a method 400 of metadata schema validation, in accordance with some embodiments. At step 402, the query system extracts data from one or more deployed metric calculators (i.e., obtains data from a messaging system). At step 404, the query system generates a schema for the extracted metadata. The schema may be generated based on one or more schema generation rules stored by the query system. The schema generation rules may be user defined (i.e., customized metadata schema));
store the metadata in a repository (Each event in the data pipeline includes metadata associated with the event. In some embodiments, the data ingestion system is configured to store metadata associated with each event in the data pipeline in a combined metadata repository, Athavale [0036]. The metadata stored in the combined metadata repository and/or any sub-repository may be extracted from the data pipeline using one or more processing platforms … The combined metadata repository collects metadata from all potential sources in single location enabling cross-platform searching of metadata during exploration, Athavale [0056]),
Athavale does not teach
validate the metadata in the repository based on validation rules and to generate validated metadata;
determining, based on applying approval criteria to the validated metadata, whether the validated metadata is approved or disapproved;
selectively: merge the validated metadata to the repository based on the validated metadata being approved; or
notify a requester based on the validated metadata being disapproved.
However, Krishnan teaches
validate the metadata in the repository based on validation rules and to generate validated metadata (the memory 204 may be configured to store data, data structures, and electronic information associated with one or more metadata change consensus notification messages, metadata change messages, metadata change approval messages, smart contract, metadata change validation messages, Krishnan, Col 17, lines 20-60. … the governance circuitry 220 may be configured to generate a smart contract in response to receipt, by the communications circuitry of the metadata change approval message from each node device impacted by the change in the metadata data structure. In some embodiments, the governance circuitry 220 may be configured to generate, based on the smart contract, a metadata changes validation message indicating validity of the change in the metadata data structure, Krishnan, Col 21, lines 51-65);
determining, based on applying approval criteria to the validated metadata, whether the validated metadata is approved or disapproved (Krishnan Col 26, line 57 – Col 27, line 24 teaches (2) send consensus notifications (e.g., metadata change consensus notification messages) to all parties involved (e.g., impacted node devices); (3) invoke a smart contract if approval (e.g., metadata change approval messages) received from all parties involved or, if the requested changes are not approved by all of the parties involved, reject the requested changes. Krishnan, Col 10, lines 49-56 teaches a metadata change validation message may be a receipt produced to indicate that: (1) a metadata change approval message has been received from all parties involved (e.g., all of the impacted node devices); (2) checks on the database side are performed to verify the changes; (3) a confirmation has been made that the requested changes have been performed on the database side with all of the parties involved (i.e., items (1), (2) and (3) are considered criteria to be met before the validated metadata is approved or disapproved));
selectively: merge the validated metadata to the repository based on the validated metadata being approved (Krishnan, Col 17, lines 20-60, Col 26, line 57 – Col 27, line 24, Col 6, lines 5-30); or
notify a requester based on the validated metadata being disapproved ((2)send consensus notifications (e.g., metadata change consensus notification messages) to all parties involved (e.g., impacted node devices); (3) invoke a smart contract if approval (e.g., metadata change approval messages) received from all parties involved or, if the requested changes are not approved by all of the parties involved, reject the requested changes, Col 26, line 57 – Col 27, line 24).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention was made having the teachings of Athavale and Krishnan before him/her, to modify Athavale with the teaching of Krishnan’s metadata management through blockchain technology. One would have been motivated to do so for the benefit of providing a metadata management (MDM) system provided herein solves the above problems by identifying and validating changes in metadata data structures in metadata blocks advantageously eliminating metadata repository storage to a larger extent; automatically documenting and discovering the data relationship; and enabling the performance of analytics at the transaction level with the block information (Krishnan, Abstract, Col 1, lines 25-28, Col 5, lines 15-19).
Athavale and Krishnan do not teach
wherein the business requirement information comprises information about one or more performance indicators that measure success of a data pipeline.
However, Palmer teaches
wherein the business requirement information comprises information about one or more performance indicators that measure success of a data pipeline (Palmer [0070] discloses continuous tracking of key performance indicators crucial to identifying deviations from plan as well as enabling the celebration of successes where performance exceeds plan, a reliable stream of performance data (i.e., performance indicators) that enables the organization (i.e., business requirement information comprises information about one or more performance indicators that measure success of a data pipeline) to focus on the right areas of development and that is also useable for performance-based conversations, efficient data collection processes and reliable data storage and management solutions, and user-friendly access to the information).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention was made having the teachings of Athavale, Krishnan and Palmer before him/her, to further modify Athavale with the teaching of Palmer’s system and methods for modeling healthcare costs, predicting same, and targeting improved healthcare quality and profitability. One would have been motivated to do so for the benefit of obtaining data from multiple sources, and historical data is also obtained and stored in the database. Once the data is obtained and coalesced into a coherent single data source, the data is analyzed to produce metrics which correspond to best practices for outcomes and financial success (Palmer, Abstract, [0071]).
Athavale, Krishnan and Palmer do not teach
wherein the repository is a centralized, protected repository with version control;
However, Li teaches
wherein the repository is a centralized, protected repository with version control (customized policy for version control configured to set a version control customized policy; a version control repository; and the above-mentioned apparatus for performing version control customized policy configured to perform said version control customized policy with said version control repository, Li [0013], [0023]);
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention was made having the teachings of Athavale, Krishnan, Palmer and Li before him/her, to further modify Athavale with the teaching of Li’s technology of setting customized policy for version control. One would have been motivated to do so for the benefit of customized policy for version control by generating at least one version control customized policy by selecting or setting a version control option; associating the version control customized policy generated with one project or user; and saving the version control customized policy and information of its associated project or user (Li, Abstract).
Regarding claim 9. Athavale as modified teaches, wherein the one or more processors, to merge the validated metadata to the repository, are configured to: generate a branch in the repository; and store the validated metadata in the branch (Krishnan, Col 17, lines 20-60).
Regarding claim 12. Athavale as modified teaches, wherein the one or more processors are further configured to: receive subsequent data requests to change attributes of a data pipeline; and modify the validated metadata based on the subsequent data requests to change the attributes of the data pipeline (Krishnan, Col 17, lines 20-60, Col 26, line 57 – Col 27, line 24).
Regarding claim 14. Athavale as modified teaches, wherein the requester generated the data request information (Krishnan, Col 17, lines 20-60, Col 26, line 57 – Col 27, line 24).
Claims 13 and 15, 17, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Athavale et al. (US Patent Publication No. 2020/0379987 A1, ‘Athavale’, hereafter) in view of Krishnan et al. (US Patent No. 11,537,592 B1, ‘Krishnan’, hereafter) in view of Zhang et al. (Chinese Patent Publication No. CN 202310229463 A, ‘Zhang’, hereafter) and further in view of Palmer et al. (US Patent Publication No. 2011/0166883 A1, ‘Palmer’, hereafter).
Regarding claim 13. Athavale as modified teaches, wherein the data request information includes a request to add a data pipeline to a big data platform utilizing a Data-as-a-Service model (the large data sub-platform is used for providing data service including data collection, data collection, data cleaning, data storage, data management, data analysis and data visualization; Specifically, a large data sub-platform (DaaS): It provides other sub-platform data collection, data collection, data cleaning, data storage, data management, data analysis, data visualization and so on, Zhang, page 9, lines 32-37, page 14, line 38 – page 15, line 5).
Regarding claim 15. Athavale teaches a non-transitory computer-readable medium storing a set of instructions (at least one non-transitory computer-readable storage medium is provided having computer-executable instructions embodied thereon, wherein, when executed by at least one processor, the computer-executable instructions cause the at least one processor to perform embodiments of the methods described herein, Athavale [0031]), the set of instructions comprising:
one or more instructions that, when executed by one or more processors of a device (at least one non-transitory computer-readable storage medium is provided having computer-executable instructions embodied thereon, wherein, when executed by at least one processor, the computer-executable instructions cause the at least one processor to perform embodiments of the methods described herein, Athavale [0031]), cause the device to:
receive data request information that includes business requirement information, pipeline information, and dataset information (a network configured to provide democratized metadata collection and analysis, in accordance with some embodiments. The network includes a plurality of data sources providing streaming data including metadata. The streaming data may be related to services and/or products provided by an online portal, such as an e-commerce platform or other interface. The plurality of data sources provides streaming data (e.g., a data pipeline) to a data ingestion system… the data ingestion system is configured to store metadata associated with each event in the data pipeline in a combined metadata repository. The combined metadata repository is configured to store all metadata for events received by the data ingestion system, regardless of the platform used to ingest the metadata, source of the metadata/events, Athavale [0035-0036], [0055-0056]);
process the data request information to generate metadata using a customized metadata schema included in the data request information (Athavale [0038] and [0048] teaches each result set identified by the platform-agnostic query, the query system identifies a platform associated with the event that generated the metadata. Athavale [0057] teaches that the query system is configured to perform metadata schema validation. FIG. 8 illustrates a method 400 of metadata schema validation, in accordance with some embodiments. At step 402, the query system extracts data from one or more deployed metric calculators (i.e., obtains data from a messaging system). At step 404, the query system generates a schema for the extracted metadata. The schema may be generated based on one or more schema generation rules stored by the query system. The schema generation rules may be user defined (i.e., customized metadata schema));
store the metadata in a repository (Each event in the data pipeline includes metadata associated with the event. In some embodiments, the data ingestion system is configured to store metadata associated with each event in the data pipeline in a combined metadata repository, Athavale [0036]. The metadata stored in the combined metadata repository and/or any sub-repository may be extracted from the data pipeline using one or more processing platforms … The combined metadata repository collects metadata from all potential sources in single location enabling cross-platform searching of metadata during exploration, Athavale [0056]),
Athavale does not teach
validate the metadata in the repository based on validation rules and to generate validated metadata;
determining, based on applying approval criteria to the validated metadata, whether the validated metadata is approved or disapproved;
selectively: merge the validated metadata to the repository based on the validated metadata being approved; or
notify a requester based on the validated metadata being disapproved.
However, Krishnan teaches
Validate the metadata in the repository based on validation rules and to generate validated metadata (the memory 204 may be configured to store data, data structures, and electronic information associated with one or more metadata change consensus notification messages, metadata change messages, metadata change approval messages, smart contract, metadata change validation messages, Krishnan, Col 17, lines 20-60. … the governance circuitry 220 may be configured to generate a smart contract in response to receipt, by the communications circuitry of the metadata change approval message from each node device impacted by the change in the metadata data structure. In some embodiments, the governance circuitry 220 may be configured to generate, based on the smart contract, a metadata change validation message indicating validity of the change in the metadata data structure, Krishnan, Col 21, lines 51-65);
determining, based on applying approval criteria to the validated metadata, whether the validated metadata is approved or disapproved (Krishnan Col 26, line 57 – Col 27, line 24 teaches (2) send consensus notifications (e.g., metadata change consensus notification messages) to all parties involved (e.g., impacted node devices); (3) invoke a smart contract if approval (e.g., metadata change approval messages) received from all parties involved or, if the requested changes are not approved by all of the parties involved, reject the requested changes. Krishnan, Col 10, lines 49-56 teaches a metadata change validation message may be a receipt produced to indicate that: (1) a metadata change approval message has been received from all parties involved (e.g., all of the impacted node devices); (2) checks on the database side are performed to verify the changes; (3) a confirmation has been made that the requested changes have been performed on the database side with all of the parties involved (i.e., items (1), (2) and (3) are considered criteria to be met before the validated metadata is approved or disapproved));
selectively: merge the validated metadata to the repository based on the validated metadata being approved (Krishnan, Col 17, lines 20-60, Col 26, line 57 – Col 27, line 24, Col 6, lines 5-30); or
notify a requester based on the validated metadata being disapproved ((2) send consensus notifications (e.g., metadata change consensus notification messages) to all parties involved (e.g., impacted node devices); (3) invoke a smart contract if approval (e.g., metadata change approval messages) received from all parties involved or, if the requested changes are not approved by all of the parties involved, reject the requested changes, Col 26, line 57 – Col 27, line 24).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention was made having the teachings of Athavale and Krishnan before him/her, to modify Athavale with the teaching of Krishnan’s metadata management through blockchain technology. One would have been motivated to do so for the benefit of providing a metadata management (MDM) system provided herein solves the above problems by identifying and validating changes in metadata data structures in metadata blocks advantageously eliminating metadata repository storage to a larger extent; automatically documenting and discovering the data relationship; and enabling the performance of analytics at the transaction level with the block information (Krishnan, Abstract, Col 1, lines 25-28, Col 5, lines 15-19).
Athavale and Krishnan do not teach
wherein the data request information includes a request to add a data pipeline to a big data platform utilizing a Data-as-a-Service model;
However, Zhang teaches
wherein the data request information includes a request to add a data pipeline to a big data platform utilizing a Data-as-a-Service model (the large data sub-platform is used for providing data service including data collection, data collection, data cleaning, data storage, data management, data analysis and data visualization; Specifically, a large data sub-platform (DaaS): It provides other sub-platform data collection, data collection, data cleaning, data storage, data management, data analysis, data visualization and so on, Zhang, page 9, lines 32-37, page 14, line 38 – page 15, line 5);
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention was made having the teachings of Athavale, Krishnan and Zhang before him/her, to further modify Athavale with the teaching of Zhang’s letter-wound ecological service cloud platform, interaction method and drifting method. One would have been motivated to do so for the benefit of providing an information innovation ecological service cloud platform, interaction method and drifting method … the cloud platform can provide research and development environment, software and hardware adaptation verification evaluation environment for personnel in the information industry through the sub-platform with micro-service such as data processing, safe operation and maintenance, adaptation and arbitration, application shop, information innovation knowledge base, solution and so on (Zhang, Abstract).
Athavale, Krishnan and Zhang do not teach
wherein the business requirement information comprises information about one or more performance indicators that measure success of a data pipeline.
However, Palmer teaches
wherein the business requirement information comprises information about one or more performance indicators that measure success of a data pipeline (Palmer [0070] discloses continuous tracking of key performance indicators crucial to identifying deviations from plan as well as enabling the celebration of successes where performance exceeds plan, a reliable stream of performance data (i.e., performance indicators) that enables the organization (i.e., business requirement information comprises information about one or more performance indicators that measure success of a data pipeline) to focus on the right areas of development and that is also useable for performance-based conversations, efficient data collection processes and reliable data storage and management solutions, and user-friendly access to the information).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention was made having the teachings of Athavale, Krishnan, Zhang and Palmer before him/her, to further modify Athavale with the teaching of Palmer’s system and methods for modeling healthcare costs, predicting same, and targeting improved healthcare quality and profitability. One would have been motivated to do so for the benefit of obtaining data from multiple sources, and historical data is also obtained and stored in the database. Once the data is obtained and coalesced into a coherent single data source, the data is analyzed to produce metrics which correspond to best practices for outcomes and financial success (Palmer, Abstract, [0071]).
Regarding claim 17. Athavale as modified teaches, wherein the one or more instructions, that cause the device to process the data request information to generate the metadata, cause the device to: process the data request information, using the customized metadata schema, to generate the metadata in a standardized format (Athavale [0036], [0048], [0057]).
Regarding claim 18. Athavale as modified teaches, wherein the one or more instructions, that cause the device to merge the validated metadata to the repository, cause the device to: generate a branch in the repository; and store the validated metadata in the branch (Krishnan, Col 17, lines 20-60).
Regarding claim 20. Athavale as modified teaches, wherein the one or more instructions further cause the device to: receive subsequent data requests to change attributes of a data pipeline; and modify the validated metadata based on the subsequent data requests to change the attributes of the data pipeline (Krishnan, Col 17, lines 20-60, Col 26, line 57 – Col 27, line 24).
Claims 16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Athavale et al. (US Patent Publication No. 2020/0379987 A1, ‘Athavale’, hereafter) in view of Krishnan et al. (US Patent No. 11,537,592 B1, ‘Krishnan’, hereafter) in view of Zhang et al. (Chinese Patent Publication No. CN 202310229463 A, ‘Zhang’, hereafter) in view of Palmer et al. (US Patent Publication No. 2011/0166883 A1, ‘Palmer’, hereafter) and further in view of Sankar et al. (US Patent Publication No. 2017/0220426 A1, ‘Sankar’, hereafter).
Regarding claim 16. Athavale as modified teaches wherein the one or more instructions further cause the device to one or more of:
load the validated metadata in a data warehouse associated with a big data application for query and analysis (Krishnan, Col 17, lines 20-60, Col 20, lines 12-23, Col 6, lines 5-30);
Athavale as modified do not teach
execute a retention policy to delete or retain data in a data pipeline based on the validated metadata;
update schema definitions for datasets in a data pipeline based on the validated metadata
However, Sankar teaches
execute a retention policy to delete or retain data in a data pipeline based on the validated metadata (Sankar [0009-0010]); or
update schema definitions for datasets in a data pipeline based on the validated metadata (Sankar [0014], [0024]).
Therefore, it would have been obvious to one ordinary skill in the art before the effective filing date of the claimed invention was made having the teachings of Athavale, Krishnan, Zhang, Palmer and Sankar before him/her, to further modify Athavale with the teaching of Sankar’s maintaining files in a related file system. One would have been motivated to do so for the benefit of providing a system for maintaining files in a retained file system (FS) is disclosed. A restoration system of the present subject matter automatically recovers an original version of a corrupted retained file from a trusted backup system that may be associated with the retained FS. A retained file may be understood as a file on which a retention policy is applied and is therefore retained in the retained FS (Sankar, Abstract, [0010]).
Regarding claim 19. Athavale as modified teaches, wherein the one or more instructions, that cause the device to validate the metadata in the repository cause the device to: validate the metadata for compliance with data retention policies or predefined naming conventions (Sankar [0024]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HASANUL MOBIN whose telephone number is (571)270-1289. The examiner can normally be reached on 9:30AM to 6:00PM EST M-F.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Charles Rones can be reached at 571-272-4085. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HASANUL MOBIN/
Primary Examiner, Art Unit 2168
Prosecution Insights