DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to Application No. 18/789,160 filed on 07/30/2024.
Claims 1-20 have been examined and are pending in this application.
Specification
The disclosure is objected to because of the following informalities: Para [96], [117] of the specification recite "data lake 508" and in para [121], it recites "data security/governance platform 508".
Appropriate correction is required.
Claim Objections
Claims 1-20 are objected to because of the following informalities:
Claims 1, 19-20: Several terms are introduced such as: a data catalog, a data store, a looped configuration, that appear to provide antecedent basis and context for limitations in the body of the claims, but the claims does not clearly indicate which preamble terms are intended to be limiting and how such terms are structurally and functionally related to the claimed steps.
Appropriate corrections are required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more.
The claim(s) recite(s)
detecting…..the change in the data store, wherein the change in the data store involves a change in a data object stored in the data store;
automatically pulling…via the data catalog, first metadata corresponding to the change in the data store, wherein the first metadata includes one or more attributes corresponding to the data object stored in the data store for which the change was detected;
automatically generating…..second metadata corresponding to the change in the data store, wherein the second metadata control access to the data object stored in the data store for which the change was detected;
updating…..third metadata stored in the data catalog to incorporate information included in the first metadata and the second metadata for providing updated metadata; and
updating…a data schema library to reflect the updated metadata, wherein the updated metadata and the updated data schema library modify access control to allow a user group to access the data object in the data store for which the change was detected, and wherein the data schema library manages changes to data schemas.
Regarding claim 1:
Applying the Alice/Mayo framework:
Step 1 – Statutory Category:
Claims 1, 19, and 20 are drafted as a method, a non-transitory, and a system claim (“a method for dynamically updating information in a data catalog”) and the dependent claims also include computer-readable medium and method forms. These fall within the statutory categories of “machine”,” manufacture”, and “process”. Accordingly, the claim meets the threshold requirements of being directed to a statutory class of invention under §101. Analysis proceeds to determine whether the claim is directed to a judicial exception.
Step 2A, Prong One — Whether the Claim is Directed to a Judicial Exception:
Under Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 110 USPQ2d 1976 (2014), and Mayo Collaborative Services v. Prometheus Labs., Inc., 566 U.S. 66, 101 USPQ2d 1961 (2012), the first inquiry is whether the claim is directed to a law of nature, natural phenomenon, or abstract idea. The present claim recites the steps of detecting a change in a data store, pulling first metadata, generating second metadata, updating third metadata, and updating data schema library. The present claim recites the abstract idea of a mental process, namely observing, comparing, and making determinations about metadata, tags, and corresponding data objects, and then deciding how access-control information should be updated in response to a detected change. These limitations involve judgments and evaluations that can be performed in the human mind (also known as mental processes), or with pen and paper, even though the claim recites execution by one or more processors. Courts have found such information processing concepts to be abstract in Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 119 USPQ2d 1739 (Fed. Cir. 2016)(collecting and analyzing information), and CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011).
Step 2A, Prong Two —Whether the Claim Integrates the Judicial Exception into a Practical Application
The claim’s additional elements do not integrate the abstract idea into a practical application. The recited “a processor; and a memory ; data catalog, schema library” are invoked at a high level of generality and perform their conventional functions of processing, storing, and organizing data. The claim does not modify or improve these functions. Rather, the claimed computer components are invoked as generic tools to automate the abstract idea. The additional elements do not integrate the abstract idea into a practical application because the Specification describes the claimed data store, data catalog, and data schema library as generic data-management components performing their ordinary functions of storing, organizing, and updating information. The “looped configuration” is described only functionally, i.e., that a change in one component automatically triggers updates in other components, but the Specification does not disclose any specific technical mechanism for implementing that loop, such as a particular synchronization protocol, trigger architecture, propagation technique, conflict-resolution scheme, or database-control logic. Likewise, the claimed automatic pulling of metadata, automatic generation of second metadata, and updating of the schema library are described in terms of desired results—keeping metadata and access control current in real time or near real time—rather than a specific improvement to database structures, schema management, or computer operation. The computer and network discussion in the Specification is also generic, describing conventional processors, memory, servers, databases, and networked devices. Accordingly, the claim uses generic computer components as tools to carry out the abstract idea of collecting, generating, and updating metadata/access information, rather than integrating that abstract idea into a practical application. Thus, consistent with Alice Corp.. v. CLS Bank International. Unlike eligible claims found in Enfish, LLC v. Microsoft Corp., the present claim does not recite a specific improvement to database technology, but instead uses a generic data catalog and schemas library in their ordinary capacity. Accordingly,, the claim does not integrate the abstract idea in a practical application.
Step 2B — Inventive Concept or “Significantly More”
Under the second step of the Alice/Mayo test, consideration is given to whether any additional element, individually or as an ordered combination, amounts to significantly more than the abstract idea itself. Here, the additional elements include a generic “hardware processor,” “non-transitory memory,” “data catalog” and “schema library”. The Specification describes the processor, memory, networked computer environment, and related components at a high level of generality as conventional computing components performing ordinary functions such as processing, storing, transmitting, organizing, and updating data. The data catalog and schema library are likewise described functionally, i.e., as components for storing metadata, managing schema changes, and updating access information, without any specific unconventional architecture, synchronization technique, control logic, or specialized algorithm.
Considered individually, these elements merely perform routine computer functions. Considered as an ordered combination, they likewise do not add significantly more, because the claim simply uses generic computer components to automate the abstract idea of collecting, generating, and updating metadata and access-control information in response to changes in a data store. The recited automation (e.g. “automatically pulling”, “automatically generating”) does not supply an inventive concept, because merely automating an abstract idea using generic computer implementation is insufficient. See Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 216, 110 USPQ2d 1976, 1980 (2014); Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A. Accordingly, the claim lacks an inventive concept sufficient to transform the abstract idea into a patent eligible application.
Regarding claim 2:
Claim 2 adds only wherein the data catalog, the data store, and the data schema library are included in the looped configuration, such that a modification in one component in the looped configuration will automatically trigger updates to other components in the looped configuration. This is still the abstract idea of propagating updates between related data. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 3:
Claim 3 adds only wherein the change in the data store in the looped configuration automatically triggers a change in the data catalog in the looped configuration. This is still the abstract idea of sequence the propagation of updates across components. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 4:
Claim 4 adds only wherein the change in the data catalog in the looped configuration triggers a change in the data schema library in the looped configuration. This is still the abstract idea of sequence the propagation of updates across components. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 5:
Claim 5 adds only wherein the change in the data store includes adding of the data object that is new to the data store. This is still the abstract idea of merely define types of data changes. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 6:
Claim 6 adds only wherein the change in the data store includes modifying of the data object that was previously existing in the data store. This is still the abstract idea of merely define types of data changes. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 7:
Claim 7 adds only pulling, by the one or more processors, the updated metadata from the data catalog; feeding, by the one or more processors, the updated metadata into a data security/governance platform; deleting, by the one or more processors, reference to a data source corresponding to the data object that was previously existing in the data store; and inserting, by the one or more processors, reference to a data source corresponding to the modified data object. This is still the abstract idea of collecting, organizing and modifying information. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 8:
Claim 8 adds only determining, by the one or more processors, an existence of a tag in the updated metadata pulled from the data catalog; and determining, by the one or more processors, an existence of a data object corresponding to the tag in the data store. This is still the abstract idea of basic data evaluation and conditional logic, which are well understood, routine, and conventional activity in data management. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 9:
Claim 9 adds only wherein, when the one or more processors determine that the tag does not exist in the updated metadata pulled from the data catalog, executing a create tag function for creating the tag. This is still the abstract idea of basic data evaluation and conditional logic, which are well understood, routine, and conventional activity in data management. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 10:
Claim 10 adds only wherein, when the one or more processors determine that the data object corresponding to the tag exists in the datastore, executing, by the one or more processors, a data source delete function for deleting a data source corresponding to the data object corresponding to the tag. This is still the abstract idea of basic data evaluation and conditional logic, which are well understood, routine, and conventional activity in data management. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 11:
Claim 11 adds only wherein, when the one or more processors determine that the data object corresponding to the tag does not exist or when the data source delete function is executed, executing a data source create function for adding a data source for the modified data object. This is still the abstract idea of creating and updating data records, and applying rules and policies to information. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 12:
Claim 12 adds only executing, by the one or more processors, a map tags function for mapping the tag to the added data source. This is still the abstract idea of creating and updating data records, and applying rules and policies to information. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 13:
Claim 13 adds only executing, by the one or more processors, a refresh tags by data source name function for updating the third metadata stored in the data catalog to include the tag corresponding to the modified data object for allowing access to the modified data object by approved user groups. This is still the abstract idea of creating and updating data records, and applying rules and policies to information. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 14:
Claim 14 adds only enforcing, by the data security/governance platform, one or more data security policies reflecting the updated metadata. This is still the abstract idea of creating and updating data records, and applying rules and policies to information. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 15:
Claim 15 adds only wherein the second metadata is generated via a machine learning algorithm model. It merely invokes ML as a toll to generate data. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 16:
Claim 16 adds only wherein the first metadata or the second metadata includes a tag corresponding to the data object. This is still the abstract idea of data labels, type of data object and timing updates. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 17:
Claim 17 adds only wherein the data object is a table. This is still the abstract idea of data labels, type of data object and timing updates. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Regarding claim 18:
Claim 18 adds only wherein the second metadata is inputted to the data catalog in real-time, according to a predetermined frequency or in response to a predetermined event. This is still the abstract idea of data labels, type of data object and timing updates. It adds no specific algorithm or improvement to computer or data analysis and management. The step remains a result-oriented instruction performed on generic hardware and, under Enfish, LLC v. Microsoft Corp. and Content Extraction & Transmission LLC V. Wells Fargo Bank, N.A., does not supply an inventive concept or render the claim eligible under §101.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Issue #1: Looped configuration / lack of technical architecture
Claims 1–20 are rejected under 35 U.S.C. §112(a) because the Specification does not provide adequate written-description for the full scope of the claimed “looped configuration.” Applicant’s Specification e.g. para [112-116], states that “the data catalog 503, the data schema library 504, the data store 505 and the metadata 506 may provide a looped configuration for chaining of related operations,” and further states that “the four connected components create an internal loop where a signal drives operations of the connected components.” However, the Specification does not describe the specific technical architecture of the loop, the directionality of the connections, the structure/content of the signal, the update-propagation logic, or whether the loop is implemented by polling, database triggers, API calls, callbacks, event queues, webhooks, or another synchronization mechanism. Therefore, the Specification describes the desired result of automatic updating among components, but does not reasonably convey possession of, or enable, the full breadth of the claimed looped configuration.
Issue #2: Metadata pulling/updating / lack of metadata-selection and update logic
Claims 1-20 are rejected under 35 U.S.C. §112(a) because the Specification does not adequately describe how the system determines which first metadata is pulled or how the third metadata stored in the data catalog is updated to incorporate the first and second metadata. Applicant’s Specification states that “the data catalog 503 may pull corresponding metadata for the modification,” and that the pulled metadata “may indicate a person responsible for the detected modification, date of modification, source of the modification and other relevant information.” The Specification further states that “the data catalog 503 integrates the metadata received with the modified data objects and feeds the information back to the data schema library 504 and the data store 505.” However, the Specification does not disclose the metadata-selection rules, query logic, metadata schema, merge logic, overwrite rules, validation logic, or conflict-resolution process used to determine what metadata is pulled, generated, incorporated, or updated for different data-store changes. Accordingly, the disclosure is functional and result-oriented, and is not commensurate with the full scope of the claimed metadata update process.
Issue #3:Access-control metadata generation / lack of concrete rules or decision criteria
Claims 1-20 are rejected under 35 U.S.C. §112(a) because the Specification does not provide adequate written-description or enablement support for automatically generating second metadata that controls access to the data object. Applicant’s Specification states that “an automated workflow may be initiated for generating corresponding tags, protection groups, access groups or similar metadata for updating access information,” and that “metadata 506 may include, without limitation, access control metadata corresponding to the data objects and/or groupings of the data objects.” However, the Specification does not disclose the inputs to the workflow, the access-control rules, user-group selection criteria, policy-mapping logic, approval criteria, tag-generation logic, or output format used to generate the claimed second metadata. Thus, the Specification describes the desired access-control result, but does not describe how the claimed access-control metadata is generated across the full breadth of the claims.
Issue #4: Data schema library / lack of schema-management implementation
Claims 1-20 are rejected under 35 U.S.C. §112(a) because the Specification does not adequately describe how the claimed data schema library manages changes to data schemas or how it interacts with the data catalog and data store across the full scope of the claims. Applicant’s Specification states that “the data schema library 504 may refer to a database schema change management platform, which allows for tracking, managing and applying database schema changes,” and that the data catalog and data schema library “may provide the updated information and apply corresponding database schema changes in generating the data schemas 507.” However, the Specification does not disclose schema-change records, schema-diff logic, versioning, validation, migration logic, rollback handling, compatibility checks, or the interface by which catalog metadata is converted into schema-library changes. Therefore, the Specification recites the function of managing and applying schema changes, but does not enable or show possession of the technical implementation for the full claimed scope.
Issue #5: ML-generated second metadata / lack of training data, features, labels, and outputs
Claim 15 is rejected under 35 U.S.C. §112(a) because the Specification does not provide adequate written-description or enablement support for generating the second metadata via a machine-learning algorithm model. Applicant’s Specification e.g. para [103-107], lists generic machine-learning techniques, including supervised learning, unsupervised learning, reinforcement learning, regression, decision trees, random forests, k-nearest neighbors, logistic regression, clustering, neural networks, support vector machines, Bayesian networks, and genetic algorithms. The Specification also states that a training model may be further trained and evaluated using holdout, K-fold cross-validation, bootstrap methods, and error/true-positive/false-positive rates. However, the Specification does not identify the training data, input features, labels, target outputs, access-control classes, confidence thresholds, policy-mapping logic, or post-processing steps used by the ML model to generate the claimed second metadata that controls access. It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015). Merely listing known ML algorithms does not reasonably convey possession of the claimed ML-based access-control metadata generation, nor does it enable one of ordinary skill to practice the full scope of claim 15 without undue experimentation .
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Regarding claims 1-4, 19-20, claims 1, 19-20 recite “a loop configuration”, the term is indefinite, because it is recited in functional terms without reciting a specific structure, topology, or operational mechanism. Although the specification references that updates may occur “based on the looped configuration” (see para [88], [101-102],), the specification does not provide a definition or description of the structure or arrangement that constitute the “looped configuration”. The specification merely describes that updates occur in response to changes or events, but does not explain what form the loop, how components are connected, or how the loop operates. Accordantly, the term fails to inform, with reasonable certainty, the scope of the claimed invention.
Regarding claims 2-4, claims 2-4 recite “automatically trigger updates”, the term is indefinite. While the specification describes that a workflow may be initiated upon detection of a change in the data store (see para [85]), it does not disclose the mechanism by which such triggering is implemented, such as how the detection occurs or how updates are propagated between components. A such, the claim recites a result without sufficient structural or procedural detail to inform the scope reasonable certainty.
Regarding claims 7, 14, claims 7, 4 recite “data security/ governance platform”, the term is indefinite. The specification only references a conventional data security platform” in the background (see para [03]), but does not provide a definition or description of structure or functionality of the claimed “data security/governance platform”. The term encompass a broad range of possibly systems and lacks sufficient detail to inform, with reasonable certainty the claimed invention.
Regarding claims 9-13, claims 9-13 recite “tag function, data source delete function, data source create function, map tags function, data source name function”, the terms are indefinite because they are described solely in terms of their intended results without specifying the underlying structure, algorithm, or steps for performing the functions. Although the specification lists such functions (see para [118]), it does not define how these functions are implemented.
Regarding claim 15, claim 15 recites “machine learning algorithm model”. While the specification provides general examples of machine learning algorithms and training techniques (see para [103-106]), the claim does not specify the inputs, outputs, or operational characteristics of the machine learning model in the context of the claimed invention. As such, it is unclear what distinguishes the recited machine learning based generation of metadata from other forms of metadata generation, and the scope of the limitation lacks clear boundaries. Accordingly, the claim fails particularly point out and the distinctly claim the subject matter regarded as the invention.
Regarding claims 5-6, 8, 16-18, claims 5-6, 8, 16-18 are rejected under 35 U.S.C. § 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention, as they depend from claim 1 and incorporate the same limitations for which claim 1 has been rejected. The same reasoning and factual bases set forth for the rejection of claim 1 is equally applicable to claims 5-6, 8, 16-18.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 5-7, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mckinnon et al. (U.S Pat. No. 8,881,129 B1; Hereinafter “McKinnon”) in view of James et al. (U.S. Pat. No. 11,392,578 B1; Hereinafter “James”).
As per claims 1, 12, and 20, McKinnon teaches a method for dynamically updating of information in a data catalog for a change in a data store via a looped configuration by utilizing one or more processors along with allocated memory, the method comprising (McKinnon: fig. 1, 10, col. 14-15, “FIG. 10 is flow diagram showing an embodiment of a process for detecting a change and updating metadata in a multi-tenant system.”, “This provides the flexibility for dynamic and more frequent and/or rapid updating of systems”, col. 2 line 1-5, “/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor”):
detecting, by the one or more processors, the change in the data store, wherein the change in the data store involves a change in a data object stored in the data store (McKinnon: fig. 1, 10, col. 15 step 1002, “A change detected at 1002 that warrants an update to the existing metadata can be due to various reasons….In a fourth example, a new required data attribute field is added at an interface associated with the service provider for which the existing metadata does not include a mapping to (e.g., the mapping prescribed by the existing metadata does not map a value to the new field).” Col. 7, line 38-45, “metadata 304 includes metadata to be used with one or more service providers. In some embodiments, metadata 304 includes a database. In some embodiments, a different database is used to store the metadata to be used with each service provider.”);
automatically pulling, by the one or more processors, first metadata corresponding to the change in the data store, wherein the first metadata includes one or more attributes corresponding to the data object stored in the data store for which the change was detected (McKinnon: fig. 1, 10, col. 15-16, step 1004, “At 1004, it is determined whether code associated with the metadata needs to be updated….a change that occurs at a service provider requires that information (e.g., values of data attribute fields) be passed in a manner different than was required before the change…For example, for a canonical feature of a central point creation of a user account, the services management server uses metadata that collects information from an end user (e.g., at a user interface associated with the services management server) that maps to various required data attribute fields at an interface associated with a service provider. In this example, to create a user account at the service provider Salesforce.com, data values were required for the fields of name, address, company, and birthday. Also, in this example, a change at Salesforce.com occurs such that to create a user account with the service provider, an additional data field of gender is now required”);
automatically generating, by the one or more processors, second metadata corresponding to the change in the data store, wherein the second metadata control access to the data object stored in the data store for which the change was detected (McKinnon: fig. 1, 10, col. 16, step 1006, “As a consequence, code needs to be generated at 1006 and added to the existing set of metadata for the Salesforce.com service provider to ensure that the data value of gender_id is appropriately passed to the new gender data field required by the service provider.”, col. 4, “services management server 114 may be configured to provide to different individual end users of a customer different levels of access to a service”);
updating, by the one or more processors, third metadata stored in the data catalog to incorporate information included in the first metadata and the second metadata for providing updated metadata (McKinnon: fig. 1, 10, col. 16-17 step 1008-1010, “At 1008, attribute mapping associated with the metadata is updated, if appropriate….a change that occurs at a service provider requires that information (e.g., values of data attribute fields) be mapped in a manner different than was required before the change. In some embodiments, attribute mappings are included in a XML file… At 1010, the updated metadata is propagated across the multi-tenant system”).
McKinnon does not explicitly teach data catalog; updating, by the one or more processors, a data schema library to reflect the updated metadata, wherein the updated metadata and the updated data schema library modify access control to allow a user group to access the data object in the data store for which the change was detected, and wherein the data schema library manages changes to data schemas.
However, in the related art, James teaches data catalog (James: fig. 1, 10, 3.8 “FIG. 6 is a block diagram illustrating an embodiment of a metadata catalog 221…. the metadata catalog 221 stores one or more dataset association records 602, one or more dataset configuration records 604, and one or more rule configuration records 606”);
updating, by the one or more processors, a data schema library to reflect the updated metadata (James: fig. 1, 10, col. 68 “the annotations can be added to the dataset configuration records 604, the rule configuration records 606… as changes are made to the metadata catalog 221 or as queries are executed on the data, the system 108 can infer information or learn about the datasets and rules and update the dataset configuration records 604 and rule configuration records 606 with this information…. the system 108 can provide an incrementally evolving schema or map of the data and can enable more efficient queries and/or reduce the amount of processing resources used during query execution.”),
wherein the updated metadata and the updated data schema library modify access control to allow a user group to access the data object in the data store for which the change was detected (James: col. 67-68, 3.8.3, “The rule configuration records 606 can include the rules, actions, and instructions for executing the rules and actions for the rules referenced of the dataset association records 602 or otherwise used or supported by the data intake and query system 108… The rule configuration record 606N can include the specific parameters and instructions for the “shared.X” rule 610A. For example, the rule configuration record 606N can identify the data that satisfies the rule (sourcetype:foo of the “main” dataset 608A). In addition, the rule configuration record 606N can include the specific parameters and instructions for the actions associated with the rule.”), and
wherein the data schema library manages changes to data schemas (James: col. 67-68, 3.8.4, “The updated datasets configuration records 604 (or annotation entries) can be used by the system 108 to propagate annotations to related datasets, protect datasets from deletion, improve portability, and make recommendations to a user and/or process additional queries as they are received, etc.”).
Therefore, It would have been obvious, to incorporate the structure data catalog and schema management of James into the metadata update and propagation framework of McKinnon to improve organization, consistency, and accessibility of metadata across systems, to ensure synchronization between metadata updates and underlying database schema changes (James; col. 7, line 18-22).
Furthermore, McKinnon also teaches the hardware components of claims 19 and 20 such as a non-transitory computer readable medium configured to store instructions; a processor; and a memory operatively connected to the processor via a communication interface, the memory storing computer readable instructions, when executed, causes the processor to (McKinnon: col. 2, “the computer program product being embodied in a non-transitory computer readable storage medium and comprising computer instructions for”).
As per claim 5, McKinnon in view of James teaches the independent claim 1. McKinnon teaches wherein the change in the data store includes adding of the data object that is new to the data store (McKinnon: fig. 1, 10, col. 15 step 1002, “A change detected at 1002 that warrants an update to the existing metadata can be due to various reasons….In a fourth example, a new required data attribute field is added at an interface associated with the service provider for which the existing metadata does not include a mapping to (e.g., the mapping prescribed by the existing metadata does not map a value to the new field).”).
As per claim 6, McKinnon in view of James teaches the independent claim 1. McKinnon teaches wherein the change in the data store includes modifying of the data object that was previously existing in the data store (McKinnon: fig. 1, 10, col. 15 step 1002, “A change detected at 1002 that warrants an update to the existing metadata can be due to various reasons….In a third example, the return value that indicates a successful performance of an action (e.g., associated with a canonical feature provided by the services management server) has changed to another value such that it is unrecognizable as an indication of a successful performance according to the instructions or data attribute mappings of the existing metadata”).
As per claim 7, McKinnon in view of James teaches the dependent claim 6. McKinnon teaches pulling, by the one or more processors, the updated metadata from the data catalog; feeding, by the one or more processors, the updated metadata into a data security/governance platform; deleting, by the one or more processors, reference to a data source corresponding to the data object that was previously existing in the data store; and inserting, by the one or more processors, reference to a data source corresponding to the modified data object (McKinnon: fig. 10, , col. 11 line 39-67, “the third example canonical feature is one button user account deactivation. For example, when an employee leaves a company, a system administrator is able to deactivate all user accounts (for all services for which that employee has an account) from a single point, using a single interaction…One button user account deactivation is more convenient than (for example) figuring out which services an employee has an account with, going to each of those service providers (e.g., their website), and deactivating or deleting the account locally and/or individually at each service provider.”).
As per claim 15, McKinnon in view of James teaches the independent claim 1. James teaches wherein the second metadata is generated via a machine learning algorithm model (James: col. 89. line 2-7, “For example, a processing sub-rule of the applicable rule may specify that data or metadata of the message be converted from one format to another via an algorithmic transformation.”, col. 178, “A notable event represents one or more anomalous incidents, the occurrence of which can be identified based on one or more events (e.g., time stamped portions of raw machine data) fulfilling pre-specified and/or dynamically-determined (e.g., based on machine-learning) criteria defined for that notable event.”).
Therefore, It would have been obvious, to incorporate the structure data catalog and schema management of James into the metadata update and propagation framework of McKinnon to improve organization, consistency, and accessibility of metadata across systems, to ensure synchronization between metadata updates and underlying database schema changes.
As per claim 16, McKinnon in view of James teaches the independent claim 1. McKinnon teaches wherein the first metadata or the second metadata includes a tag corresponding to the data object (McKinnon: col 7, line 20-37, “For example, with respect to sign in the metadata may indicate for a service provided by a particular service provider to a customer using …a mapping of end user credential values (e.g., user name and/or password) as stored on and provided by end users to the service management platform (e.g., in connection with single sign on) to corresponding fields and/or other attributes or variables as named and understood by the service provider.”).
As per claim 17, McKinnon in view of James teaches the independent claim 1. James teaches wherein the data object is a table (James: col. 68, “the annotations can be stored as a separate entry or data structure. For example, the system 108 can update or create an annotation entry for each annotation and store the annotations in a database, such as a relational database or table of the metadata catalog 221”).
Therefore, It would have been obvious, to incorporate the structure data catalog and schema management of James into the metadata update and propagation framework of McKinnon to improve organization, consistency, and accessibility of metadata across systems, to ensure synchronization between metadata updates and underlying database schema changes.
As per claim 18, McKinnon in view of James teaches the independent claim 1. James teaches wherein the second metadata is inputted to the data catalog in real-time, according to a predetermined frequency or in response to a predetermined event (James: col. 7, “The SPLUNK® ENTERPRISE system is the leading platform for providing real-time operational intelligence that enables organizations to collect, index, and search machine data from various websites, applications, servers, networks, and mobile devices that power their businesses.’, col. 93, “the bucket merge policy can indicate which buckets are candidates for a merge (e.g., based on time ranges, size, tenant/partition or other identifiers, etc.), the number of buckets to merge, size or time range parameters for the merged buckets, a frequency for creating the merged buckets, etc.”, ).
Therefore, It would have been obvious, to incorporate the structure data catalog and schema management of James into the metadata update and propagation framework of McKinnon to improve organization, consistency, and accessibility of metadata across systems, to ensure synchronization between metadata updates and underlying database schema changes.
Claims 2-3 are rejected under 35 U.S.C. 103 as being unpatentable over Mckinnon et al. (U.S Pat. No. 8881129 B1; Hereinafter “McKinnon”) in view of James et al. (U.S. Pat. No. 11392578 B1; Hereinafter “James”) and Weisman et al. (U.S. Pub. No. 2022/0245125 A1; Hereinafter “Weisman”).
As per claim 2, McKinnon in view of James teaches the independent to claim 1.
Weisman teaches wherein the data catalog, the data store, and the data schema library are included in the looped configuration, such that a modification in one component in the looped configuration will automatically trigger updates to other components in the looped configuration (Weisman: para[83-84], [178] “the dataset multiplexer, applications can be written and executed without the applications having knowledge of the format (e.g., record format or schema) supported by data stores accessed by the applications, or even physical location, of these data stores….The dataset multiplexer may automatically supply connections between the applications and the appropriate data stores storing the physical datasets represented by the logical datasets, avoiding the need for the application and the user to have knowledge of the implementation of the data stores. The catalog of datasets may be updated in response to events indicating changes to the storage of the datasets, such as physical datasets represented by the logical dataset.”).
Therefore, It would have been obvious, to incorporate the dynamic dataset catalog updating of Weisman into the metadata update and propagation framework of McKinnon so that, when a change event associated with a physical dataset causes the catalog information to be updated to improve consistency between stored datasets and catalog metadata (Weisman: para[237])
As per claim 3, McKinnon in view of James and Weisman teaches the independent to claim 2. Weisman teaches wherein the change in the data store in the looped configuration automatically triggers a change in the data catalog in the looped configuration (Weisman: para[83-84], [178] “The catalog of datasets may be updated in response to events indicating changes to the storage of the datasets, such as physical datasets represented by the logical dataset.”).
Therefore, It would have been obvious, to incorporate the dynamic dataset catalog updating of Weisman into the metadata update and propagation framework of McKinnon so that, when a change event associated with a physical dataset causes the catalog information to be updated to improve consistency between stored datasets and catalog metadata (Weisman: para[237])
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Mckinnon et al. (U.S Pat. No. 8881129 B1; Hereinafter “McKinnon”) in view of James et al. (U.S. Pat. No. 11392578 B1; Hereinafter “James”), Weisman et al. (U.S. Pub. No. 2022/0245125 A1; Hereinafter “Weisman”), and Reyal (U.S. Pub. No. 2020/0301945 A1; Hereinafter “Reyal”).
As per claim 4, McKinnon in view of James and Weisman teaches the independent to claim.
Rehal teaches wherein the change in the data catalog in the looped configuration triggers a change in the data schema library in the looped configuration (Rehal: para[150-153], “Then the Metadata Generation and Schema Evolution process is triggered, the Metadata Generator 302 queries the RDBMS system at the data source 102 to gather metadata for one or more specified tables. Collected metadata is compared with existing metadata for the same tables in the metadata repository 310 by Schema Differentiator 304. If existing metadata is not found for a table, then it will be treated as if the table is being imported into the data lake for the first time and a signal is sent to the Scoop Generator 306 and Data Lake Schema Generator 308 to generate Sqoop scripts and the data lake schema (including table information files, and initial load and delta load Hive query language (HQL) scripts). Once required scripts have been generated they are stored in a local directory (specified in the configuration data), and can then be used to generate the data lake environment for the tables (i.e. the table structure, directory structure, and collection of files making up the tables). These scripts can also be used to transfer tables between Hadoop clusters. If existing metadata is found for a table, then the Schema Differentiator 304 identifies the difference between the new table schema (as defined in the presently extracted metadata) and the old table schema (as defined by the metadata stored in the metadata repository) and applies the changes to the data lake data representation, regenerating scripts as needed.”).
Therefore, It would have been obvious, to incorporate the metadata repository and schema evolution of Rehal into the metadata update and propagation framework of McKinnon so that, when a change event associated with the catalog information cause the schema to be updated to improve consistency between stored datasets, catalog metadata, and downstream schema representations (Rehal: para[84])
Claims 8-14 are rejected under 35 U.S.C. 103 as being unpatentable over Mckinnon et al. (U.S Pat. No. 8881129 B1; Hereinafter “McKinnon”) in view of James et al. (U.S. Pat. No. 11392578 B1; Hereinafter “James”) and Brenner et al. (U.S. Pub. No. 2024/0143812A1; Hereinafter “Brenner”).
As per claim 8, McKinnon in view of James teaches the dependent claim 7.
Brenner teaches determining, by the one or more processors, an existence of a tag in the updated metadata pulled from the data catalog (Brenner: para [65-67], “FIG. 5 illustrates protection policies composed of one or many data queries that find data in a data catalogs based off the files' metadata, under some embodiments. The example of FIG. 5 includes two data queries as part of this protection policy, data query 1, 504, and data query 2, 506, which are each unique as to a particular backup. The data queries access certain tag filters 506, 508 and volume filters 507, 509, as shown, where the filters process file timestamp and size filters..”); and
determining, by the one or more processors, an existence of a data object corresponding to the tag in the data store (Brenner: para [115-123], “As shown in FIG. 21, process 2100 starts by determining how the system is to behave or treat data objects referenced by a particular dataset, for data that may be affected by changes in the network, 2102. It then derives and associates a corresponding behavior tag to the dataset, 2104. The system processes the referenced data objects in accordance with the classifier tag as modified by any behavior tag, 2106… the behavior tag is used to modify the classification and classifier tags in the event of changes of the system that may affect the membership of data objects in a dataset..”).
As per claim 9, The method according to claim 8, wherein, when the one or more processors determine that the tag does not exist in the updated metadata pulled from the data catalog, executing a create tag function for creating the tag (Brenner: para[66-67], “of the dataset management process 115 leverage any data catalog and produces a change file list from a catalog that does not have one and improves the current protection policy design by moving away from protecting assets to a model where it uses the tags, metadata and filesystem attributes to create a dataset that will be used by data protection software to create protection policies. This results in a content-based data protection as opposed to location or asset based data protection”).
As per claim 10, The method according to claim 8, wherein, when the one or more processors determine that the data object corresponding to the tag exists in the datastore, executing, by the one or more processors, a data source delete function for deleting a data source corresponding to the data object corresponding to the tag (Brenner: para [46], [68-69], claim 11-12, “determining if the new data objects are classified to an existing dataset for the edge network, and if not, forwarding the new data objects to the central cloud network for new classification; and transmitting the new classification to the edge network to allow the edge network to recognize the classified new data objects….maintaining tags and classifiers received by the edge network from the central cloud network in a cache memory of the edge network; and deleting cached tags and classifiers using a periodic or least recently used cache clearing mechanism.”).
As per claim 11, The method according to claim 10, wherein, when the one or more processors determine that the data object corresponding to the tag does not exist or when the data source delete function is executed, executing a data source create function for adding a data source for the modified data object (Brenner: para [46], [68-69], “This simplifies the protection model by protecting data based on data types so that projects dispersed many multiple filesystems, storages, object stores, etc. may be dealt with as a single protection construct, i.e., the ‘dataset.’ Moreover, the dataset automatically tracks project data added, removed or relocated and so data protection will always be up to date on asset location changes even in the largest systems. In other words, datasets define content-based data protection as opposed to the location-based schemas of present systems.”).
As per claim 12, The method according to claim 11, further comprising: executing, by the one or more processors, a map tags function for mapping the tag to the added data source (Brenner: para[100], “As shown in FIG. 17, system 1700 includes a dataset 1702 having metadata elements that reference corresponding content data objects 1701, 1703, and 1705 through respective metadata (metadata 1, metadata 2, metadata 3). The classifier process 1706 defines a classifier 1704 for the dataset 1702, and this classifier is appended to or associated with the dataset as an alphanumeric label or function parameter, or similar mechanism. The classifier process 1706 also processes the content data to determine which data objects should belong to dataset 1702 based on the classifier, and appends the same classifier 1704 to these data objects, as shown.”).
As per claim 13, The method according to claim 12, further comprising: executing, by the one or more processors, a refresh tags by data source name function for updating the third metadata stored in the data catalog to include the tag corresponding to the modified data object for allowing access to the modified data object by approved user groups (Brenner: para[100], “As shown in FIG. 17, system 1700 includes a dataset 1702 having metadata elements that reference corresponding content data objects 1701, 1703, and 1705 through respective metadata (metadata 1, metadata 2, metadata 3). The classifier process 1706 defines a classifier 1704 for the dataset 1702, and this classifier is appended to or associated with the dataset as an alphanumeric label or function parameter, or similar mechanism. The classifier process 1706 also processes the content data to determine which data objects should belong to dataset 1702 based on the classifier, and appends the same classifier 1704 to these data objects, as shown.”).
As per claim 14, The method according to claim 13, further comprising: enforcing, by the data security/governance platform, one or more data security policies reflecting the updated metadata (Brenner: para[65-67], fig. 5, “FIG. 5 illustrates protection policies composed of one or many data queries that find data in a data catalogs based off the files' metadata, under some embodiments…..the dataset management process 115 leverage any data catalog and produces a change file list from a catalog that does not have one and improves the current protection policy design by moving away from protecting assets to a model where it uses the tags, metadata and filesystem attributes to create a dataset that will be used by data protection software to create protection policies.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US- , Access Control Rights Assignment Capabilities Utilizing a New Context-Based Hierarchy of Data Based on New forms of Metadata.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LYDIA L NOEL whose telephone number is (571)272-1628. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
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, Alexander Lagor can be reached on (571)-270-5143. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information As regarding 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.
/L.L.N./Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights