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 .
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-5, 7-10, 12-15, and 19-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Note that the courts do not distinguish between mental processes that are performed entirely in the human mind and mental processes that require a human to use a physical aid (e.g., pen and paper or a slide rule) to perform the claim limitation (refer to MPEP 2106.04(a)(2)).
Independent claim 19 recites the following abstract idea limitations: A method comprising:
receiving, by [an entity], a query comprising data that describes integrated acquisition data of an acquisition entity (observation as part of a mental process—e.g., an analyst obtaining structured information in written or verbal form, such as a report or a memo);
querying, by the [entity], using the query, a plurality of predictive models to generate a plurality of outputs, each predictive model in the plurality of predictive models trained (the training is in past tense, and takes place before the scope of the claim; further, the training is specified at a high level of generality which includes an analyst manually adjusting model weights as part of a mental process) using a different data set associated with integrated acquisition entities of a target multitenant platform (evaluation as part of a mental process—e.g., the analyst plugs given values of the structured information into known models and performs the necessary calculations to obtain respective outputs; association with a multitenant platform need not include the platform itself within the claim scope);
aggregating, by the [entity], the plurality of outputs into an aggregated output (evaluation as part of a mental process—e.g., the analyst sums or averages the outputs, or otherwise writes them together into a given format); and
determining, by the [entity], based on the aggregated output, potential data discrepancies in the integrated acquisition entity data by consolidating the plurality of outputs into a consolidated query result (evaluation and judgement as part of a mental process—e.g., the analyst evaluates the aggregate outputs and determines whether they are indicative of a positive or negative determination of discrepancies).
Independent claim 19 recites the following limitations which may comprise additional elements that are sufficient to amount to significantly more than the abstract idea: the method steps further being performed by “a processor.”
With respect to step 2A, the judicial exception is not integrated into a practical application because it is drawn to evaluation by models at a high level of generality, and because adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). The claim does not recite particularly structured models, nor any particular training algorithms. It likewise does not recite a particular machine for performing the method. Instead, it is drawn to “a processor” for performing the steps of receiving, querying, aggregating, and determining. A processor is a base level component of any computer to perform the abstract idea, and the claim steps may be performed by a human analyst as discussed above. As such, the invention is addressing a problem that transcends computing (evaluating information using multiple models) rather than improving the functioning of a computer, or an improvement to other technology or a technical field.
With respect to step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). In this case, a processor is a base level component of any computer which could perform the abstract idea. Merely performing the judicial exception using a base level computer is not considered to be sufficient.
Independent claim 21 is substantially similar to independent claim 19 above, and is therefore rejected under the same analysis (further, a “non-transitory computer-readable storage medium” is a base level component of any computer for performing the abstract idea in the same manner as “a processor”).
Dependent claim 20 recites the following abstract idea limitations: The method of claim 19, further comprising generating, by the processor, a confidence score for the aggregated output, the confidence score indicating a likelihood that the aggregated output accurately identifies potential data discrepancies in the integrated acquisition entity data (evaluation and judgement as part of a mental process—e.g., the analyst further calculating a confidence score to serve as a threshold value). As such, claim 20 is rejected under the same analysis as its parent claim.
Dependent claim 22 is substantially similar to dependent claim 20 above, and is therefore likewise rejected.
Independent claim 1 recites the following abstract idea limitations: A method comprising:
authorizing (authorization as part of certain methods of organizing human activity—e.g., a first analyst gives the go ahead for merging data records to another analyst), by [a first entity], [a second entity] to integrate [second entity] data hosted by a source platform into a target shared data resource of the target (observation and evaluation as part of a mental process—e.g., the second analyst merges data records such as patient health records from different medical offices into a single record);
integrating, by the [first entity], in response to the authorization, [second entity] data with the target shared data resource of the target (observation and evaluation as part of a mental process—e.g., analysts merging data records such as patient health records from different medical offices into a single record);
validating (observation and evaluation as part of a mental process—e.g., the first analyst reviewing the merged record for errors such as typos, improperly formatted information, and being out of compliance with regulatory requirements), by the [first entity], the integrated [second entity] data by:
generating an input vector based on the [second entity] data (observation and evaluation as part of a mental process—e.g., the first analyst identifying a given field in the data record to review); and
generating an output indicating potential data discrepancies in the integrated [second entity] data by inputting the input vector into a predictive mode (evaluation and judgement as part of a mental process—e.g., the first analyst comparing information in the given field to expected information for the given field, and determining whether it matches the expected information; for instance, that the given field has incorrectly formatted information, or that sensitive data should not appear in plaintext for this field);
responding, by the [first entity], to the output indicating potential data discrepancies by:
suggesting resolutions for a subset of the potential data discrepancies based on historical data (observation, evaluation, and judgement as part of a mental process—e.g., the first analyst determines a substitution for the given field based on their experience with such records; for instance, changing the format or obfuscating the information in a preferred manner);
generating a user interface (may be a pen and paper interface at the recited level of generality) displaying the potential data discrepancies and suggested resolutions (e.g., written instructions and suggestions); and enabling (merely “enabling” does not specify the manner of use of the user interface) a user to resolve the potential data discrepancies through the user interface (making editing suggestions as part of certain methods of organizing human activity—e.g., textually alerting users with a notification to edit records, and receiving replies in kind); and
applying at least one of the suggested resolutions across multiple data entries (observation and evaluation as part of a mental process—e.g., someone manually edits all the identified fields as suggested and agreed upon).
Independent claim 1 recites the following limitations which may comprise additional elements that are sufficient to amount to significantly more than the abstract idea: performing the claim steps “by a processor” as the first entity; performing authorization further “via an extension platform of a target multitenant platform;” the source platform further comprising a “cloud platform” the second entity further comprising “an acquisition entity;” the target further comprising “a multitenant platform.”
With respect to step 2A, the judicial exception is not integrated into a practical application because it is drawn to collating and validating data records at a high level of generality. While the claim does recite a multitenant platform and source cloud platform as the environment for obtaining, collating, and validating data, generally linking the use of the judicial exception to a particular technological environment or field of use is not considered to be sufficient—see MPEP 2106.05(h). The claim merely performs the abstract idea of collating and validating information with that particular technological environment serving as source and sink. A different environment could be substituted without materially affecting the claim steps beyond source and sink (for instance, clients and server or any networked computers). Likewise, the same data gathering and analysis may be performed by a human using pen and paper. Where the claim recites a processor, it is noted that adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). A processor is the base component of any computer for performing the abstract idea.
Since the claim steps may analogously be performed by a human using pen and paper, the invention is addressing a problem that transcends computing (collating and validating information) rather than improving the functioning of a computer, or an improvement to other technology or a technical field.
With respect to step 2B, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). In this case, a processor is a base level component of any computer which could perform the abstract idea. An extension platform of a target multitenant platform, the multitenant platform, a cloud platform, and an acquisition entity are likewise substitutes for generic entities in the claim. Specifically, the claim does not recite or rely upon the particular functionality of these elements for performing the claim steps. Rather, the steps may be performed by a human as described above. Thus, these claim elements serve as a base computerization of the claim steps.
Regarding dependent claim 2, it recites the following abstract idea limitations: receiving, by [the first entity], a request to map a target tenant of the target multitenant platform to an acquisition instance of the source cloud platform corresponding to the acquisition entity (requesting tasks as part of certain methods of organizing human activity—e.g., the first analyst receiving a request to map certain elements together); and mapping, by the [first entity], the acquisition instance of the source cloud platform to the target tenant in the target multitenant platform (observation and evaluation as part of a mental process—e.g., the first analyst linking elements in a mapping).
Dependent claim 2 recites the following limitations which may comprise additional elements that are sufficient to amount to significantly more than the abstract idea: the first entity further comprising “the processor;” performing the mapping further “via an internal authentication service of the target multitenant platform.”
With respect to steps 2A and 2B, claim 2 is rejected under the same analysis as claim 1 above since it merely further describes the abstract idea of collating and validating information. The processor and the internal authentication service are not sufficient because adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea is not considered to be sufficient—see MPEP 2106.05(f). These are used as computer substitutes as discussed in the rejection of claim 1.
Regarding claim 3, it is rejected for substantially the same reasons as claim 2 above, since it merely further describes the abstract idea of collating and validating information in view of mapping information and certain methods of organizing human activity (e.g., setting up a team member as the go-to for obtaining stored mapping information).
Regarding dependent claim 4, it recites the following abstract idea limitations: authorizing, by the [first entity], the source platform to transfer data associated with the [second] entity and hosted by the source platform by: receiving a request to send, via the source platform, a credential to the [second] entity; and sending, to the [second] entity via the source platform, the credential (sending and receiving credentials as part of certain methods of organizing human activity—e.g., the first analyst obtains and sends credentials such as written documents, or a verbal description of such, for the purpose of authorization).
Dependent claim 4 recites the same additional elements as those described in claim 1 above. Therefore, claim 4 is rejected under the same analysis as claim 1 above since it merely further describes the abstract idea of collating and validating information.
Regarding claim 5, it is rejected for substantially the same reasons as claim 4 above, since it merely further describes the abstract idea of collating and validating information in view of additional authorization processing as part of certain methods of organizing human activity.
Regarding dependent claim 7, it recites the following abstract idea limitations: allocating, by the [first entity], resources within the target platform to a target tenant in response to a tenant setup request received from the [second] entity via the source platform (allocating tasks to workers as part of certain methods of organizing human activity—e.g., the first analyst sets up a new team of analysts to work for a new customer). Dependent claim 7 recites the same additional elements as those described in claim 1 above.
Therefore, claim 7 is rejected under the same analysis as claim 1 above since it merely further describes the abstract idea of collating and validating information in view of allocating additional employees as part of certain methods of organizing human activity.
Regarding claims 8-9, they are rejected under the same analysis as claim 1 above since they merely further specify the format of the data being encrypted data and the mental process of decryption which is performable by a human (e.g., the first analyst decrypting the received data using a particular algorithm with pen and paper).
Regarding claim 10, it is rejected under the same analysis as claim 1 above since it merely further specifies providing task instructions as part of certain methods of organizing human activity (e.g., the first analyst provides instructions for the required formatting).
Regarding claims 12-15, they are rejected under the same analysis as claim 1 above because they merely further specify the model at a high level of generality (e.g., what data forms the model; updating the model with new data; using a second model alongside the first).
Regarding dependent claims 6 and 11, they are not considered to be directed to an abstract idea without significantly more.
Claim Rejections - 35 USC § 112
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 19-22 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Independent claims 19 and 21 each recite “each predictive model in the plurality of predictive models trained using a different data set,” which renders these claims indefinite because it is not clear whether the training is part of the claim scope. Specifically, the above limitation refers to the predictive models having already been trained in a particular manner. This happens prior to and outside of the rest of the claimed steps of receiving, querying, aggregating, and determining, so it is not clear whether such training is part of the claim scope. Therefore, a person of ordinary skill in the art could not interpret the metes and bounds of the claim so as to understand how to avoid infringement.
The dependent claims do not rectify this issue and are therefore likewise rejected.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-4, 7, and 10 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Dixit (US 2021/0398235 A1).
Regarding claim 1, Dixit discloses: A method comprising:
authorizing (e.g., login and authentication for a request to integrate data as in [0039] of Dixit), by a processor, via an extension platform (e.g., orchestration management components 104 in FIG. 1 of Dixit) of a target multitenant platform (e.g., distributed platform 102 in FIG. 1 of Dixit), an acquisition entity (e.g., 110, 106, and/or 108 as data sources in FIG. 1 of Dixit) to integrate acquisition entity data hosted by a source cloud platform (e.g., domain-specific data to be integrated as in [0012] and [0027] of Dixit) into a target shared data resource of the target multitenant platform (e.g., distributed cache storage 114 in [0035] FIG. 1 of Dixit);
Refer to at least [0039] of Dixit with respect to the request to integrate data.
integrating, by the processor, in response to the authorization, acquisition entity data with the target shared data resource of the target multitenant platform;
Refer to at least [0039]-[0040] and [0037] of Dixit with respect to processing the integration request and generating mappings for the data.
validating, by the processor, the integrated acquisition entity data by:
generating an input vector based on the acquisition entity data; and generating an output indicating potential data discrepancies in the integrated acquisition entity data by inputting the input vector into a predictive model (e.g., artificial intelligence processing 112 in FIG. 112 of Dixit; example models in [0030] of Dixit);
Refer to at least [0017]-[0018], [0030], [0041], and [0051] of Dixit with respect to validation of the integration request and data using the AI. As per [0030], the AI may include use of a neural network, which implements vector input as part of its functionality. The AI processing produces insights and recommendations for an admin user as part of the validation.
responding, by the processor, to the output indicating potential data discrepancies (errors in Dixit) by: suggesting resolutions for a subset of the potential data discrepancies based on historical data (i.e., the trained AI as in [0030] of Dixit, which is necessarily trained using training data); generating a user interface (GUI in Dixit; e.g., FIG. 3D-H) displaying the potential data discrepancies and suggested resolutions; and
Refer to at least [0019]-[0020], [0025], and [0051]-[0052] of Dixit with respect to the AI processing including a GUI for presenting the insights and recommendations to the admin and accepting their selections.
enabling a user to resolve the potential data discrepancies through the user interface; and applying at least one of the suggested resolutions across multiple data entries.
Refer to at least the abstract, FIG.3F, 3I, [0014], [0052], and [0053]-[0056] of Dixit with respect to the admin using the GUI and insights/recommendations for resolving the errors and completing the integration.
Regarding claim 2, Dixit discloses: The method of claim 1, further comprising: receiving, by the processor, a request to map a target tenant of the target multitenant platform to an acquisition instance of the source cloud platform corresponding to the acquisition entity; and mapping, by the processor, via an internal authentication service of the target multitenant platform, the acquisition instance of the source cloud platform to the target tenant in the target multitenant platform.
Refer to at least [0024], [0029], and [0045] of Dixit with respect to mapping data concerning tenants and applications / software vendors.
Regarding claim 3, Dixit discloses: The method of claim 2, further comprising: configuring, by the processor via the internal authentication service of the target multitenant platform, a tenant mapping information endpoint within the source cloud platform that, when queried with information associated with the acquisition entity, returns identifying information of the target tenant; receiving, by the processor via the tenant mapping information endpoint, a query comprising information associated with the acquisition entity; and returning, by the processor via the tenant mapping information endpoint in response to the query, identifying information of the target tenant.
Refer to at least [0055] and [0070] of Dixit with respect to storing mappings (see [0024], [0029], and [0045] concerning tenant information) in the distributed cache storage: i.e., “storage (processing operation 218) of the data mapping may result in the data mapping being stored on a distributed cache storage associated with the education platform service” and “[a] second GUI notification element 394 provides the user with the ability access a stored data mapping (e.g., through the distributed cache storage).”
Regarding claim 4, Dixit discloses: The method of claim 1, further comprising authorizing, by the processor via the extension platform of the target multitenant platform, the source cloud platform to transfer data associated with the acquisition entity and hosted by the source cloud platform by: receiving a request to send, via the source cloud platform, a credential to the acquisition entity; and sending, to the acquisition entity via the source cloud platform, the credential.
Refer to at least [0047] and [0032] of Dixit with respect to integration data including credential / device-specific login data.
Regarding claim 7, Dixit discloses: The method of claim 1, further comprising allocating, by the processor, resources within the target multitenant platform to a target tenant in response to a tenant setup request received from the acquisition entity via the source cloud platform.
Refer to at least [0028] and [0056] of Dixit with respect to assigning resources to and activating features/services for a tenant.
Regarding claim 10, it is rejected for substantially the same reasons as claims 1 and 7 above (e.g., citations concerning feature/services activation).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 19-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Panalkar (US 12,613,761 B1) in view of Dixit (US 2021/0398235 A1).
Regarding claim 19, Panalkar discloses: A method comprising:
receiving, by a processor, [a dataset associated with] integrated acquisition data of an acquisition entity;
Refer to at least 502 in FIG. 5 and Col. 9, Ll. 29-35 of Panalkar with respect to receiving a dataset from one or more data sources for anomaly detection processing.
querying, by the processor, using the [dataset], a plurality of predictive models (e.g., FIG. 2 of Panalkar concerning an example plurality of models) to generate a plurality of outputs;
Refer to at least 504-510 in FIG. 5, Col. 2, Ll. 5-15, Col. 3, Ll. 50-53, Col. 4, Ll. 22-30, and Col. 9, Ll. 36-63 of Panalkar with respect to generating respective anomaly outputs for the dataset using the plurality of models.
aggregating, by the processor, the plurality of outputs into an aggregated output; and
Refer to at least 512 in FIG. 5, Col. 2, Ll. 14-17, Col. 9, Ll. 64-Col. 10, Ll. 3, and Col. 10, Ll. 39-41 of Panalkar with respect to aggregating the model outputs.
determining, by the processor, based on the aggregated output, potential data discrepancies (data anomalies in Panalkar) in the integrated acquisition entity data by consolidating the plurality of outputs into a consolidated query result.
Refer to at least 514 in FIG. 5, Col. 2, Ll. 67-Col. 3, Ll. 5, Col. 8, Ll. 61-Col. 9, Ll. 16, and Col. 10, Ll. 4-7 of Panalkar with respect to a GUI and generating an alert based on the aggregated model outputs indicating an anomaly.
Panalkar is drawn to identifying data anomalies using a plurality of models as above, but does not specify: the dataset further comprising a query comprising data that describes the integrated acquisition data; each predictive model in the plurality of predictive models trained using a different data set associated with integrated acquisition entities of a target multitenant platform. However, Panalkar in view of Dixit discloses: the dataset further comprising a query comprising data that describes the integrated acquisition data;
Refer to at least FIG. 3A-B, [0025], and [0039] of Dixit with respect to a GUI and user request for integration and associated validation.
each predictive model in the plurality of predictive models trained using a different data set associated with integrated acquisition entities of a target multitenant platform.
Refer to at least [0030] of Dixit stating that “trained AI processing is specifically configured to generate data insights pertaining to the data ingestion and data provisioning of domain-specific data (e.g., education data);” with respect to [0027] of Dixit stating that “tenants 106 may be created to respectively manage individual educational institutions (or a specific group of educational institutions). Education/educational data is specific to the one or more educational institutions.”
The teachings of both Panalkar and Dixit concern data validation using machine learning models (among others), and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Panalkar to further implement domain-specific (e.g., associated with particular tenants) trained models for at least the purpose of more accurately predicting errors at that particular granularity (e.g., a domain having an atypical format to account for). It further would have been obvious to implement the GUI features of Dixit for at least the purpose of improving usability as in at least [0021] of Dixit.
Regarding claim 20, Panalkar-Dixit discloses: The method of claim 19, further comprising generating, by the processor, a confidence score for the aggregated output, the confidence score indicating a likelihood that the aggregated output accurately identifies potential data discrepancies in the integrated acquisition entity data.
Refer to at least Col. 10, Ll. 42-48 of Panalkar with respect to anomaly scoring and a threshold.
Refer to at least [0019] and [0031] of Dixit with respect to confidence scoring / ranking for AI models.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Panalkar-Dixit to further implement confidence scoring because particular known technique was recognized as part of the ordinary capabilities of one skilled in the art as per the cited portions of Dixit.
Regarding independent claim 21, it is substantially similar to claim 19 above, and is therefore likewise rejected.
Regarding claim 22, it is substantially similar to claim 20 above, and is therefore likewise rejected.
Claim(s) 5-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dixit as applied to claims 1-4, 7, and 10 above, and further in view of Krishnan (US 2023/0300135 A1).
Regarding claim 5, Dixit does not disclose: authorizing, by the processor via the extension platform of the target multitenant platform, the source cloud platform to transfer data associated with the acquisition entity and hosted by the source cloud platform by: receiving, via an authorization service of the extension platform of the target multitenant platform, a request from the acquisition entity for an authorization token, the request comprising the credential; generating, via the authorization service of the extension platform of the target multitenant platform, an authorization token; and sending, via the source cloud platform, the authorization token to the acquisition entity. However, Dixit in view of Krishnan discloses: authorizing, by the processor via the extension platform of the target multitenant platform, the source cloud platform to transfer data associated with the acquisition entity and hosted by the source cloud platform by: receiving, via an authorization service of the extension platform of the target multitenant platform, a request from the acquisition entity for an authorization token, the request comprising the credential (e.g., [0080] and [0041] of Krishnan concerning a suitable credential);
Refer to at least 152 in FIG. 1E and [0048] of Krishnan with respect to receiving a message requesting token generation.
generating, via the authorization service of the extension platform of the target multitenant platform (e.g., [0069]-[0073] of Krishnan concerning a multitenant cloud environment), an authorization token;
Refer to at least 154 in FIG. 1E and [0049] of Krishnan with respect to generating the requested token(s).
and sending, via the source cloud platform, the authorization token to the acquisition entity.
Refer to at least 156 in FIG. 1E and [0050] of Krishnan with respect to sending the token(s) for use in API authentication.
The teachings of both Dixit and Krishnan concern access control for data access, and are considered to be combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Dixit to further implement access token generation and provision for at least the purpose of ensuring compliance with customer and regulatory privacy and security requirements, as well as to prevent an unmanageable number of requests from being sent.
Regarding claim 6, Dixit-Krishnan discloses: The method of claim 5, further comprising: receiving, by the processor via an application programming interface (API) endpoint hosted by the extension platform of the target multitenant platform, a data integration request comprising the authorization token;
Refer to at least [0046] and [0060] of Dixit with respect to data integration using API.
Refer to at least 1002 in FIG. 10 and [0050] of Krishnan with respect to using the generated token(s) for an API call.
authenticating, by the processor, the authorization token; and authorizing, by the processor, the acquisition entity to integrate acquisition entity data hosted by the source cloud platform into the target shared data resource of the target multitenant platform in response to authenticating the authorization token.
Refer to at least 1016 in FIG. 10 and [0107]-[0108] of Krishnan with respect to using the received token to provide the requested resource.
This claim would have been obvious for substantially the same reasons as claim 5 above, and because the particular known technique (using tokens for authentication to a resource) was recognized as part of the ordinary capabilities of one skilled in the art.
Claim(s) 8-9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dixit as applied to claims 1-4, 7, and 10 above, and further in view of Jamkhedkar (US 2023/0205742 A1).
Regarding claim 8, Dixit does not specify: further comprising integrating, by the processor, acquisition entity data with the target shared data resource of the target multitenant platform by transferring encrypted data associated with the acquisition entity to the multitenant data resource of the target multitenant platform. However, Dixit in view of Jamkhedkar discloses: further comprising integrating, by the processor, acquisition entity data with the target shared data resource of the target multitenant platform by transferring encrypted data associated with the acquisition entity to the multitenant data resource of the target multitenant platform.
Refer to at least [0034] and [0079] of Jamkhedkar with respect to a server data management application decrypting encrypted data transmitted from client applications during ingestion.
The teachings of Dixit and Jamkhedkar both concern data ingestion, management, and analysis. As such, they are considered to be within the same field of endeavor and combinable.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Dixit to further implement encryption and decryption processing during data transfer for at least the purpose of improving security (i.e., privacy and defending against malicious eavesdropping).
Regarding claim 9, it is rejected for substantially the same reasons as claim 8 above (i.e., the citations and obviousness rationale).
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dixit as applied to claims 1-4, 7, and 10 above, and further in view of Nehzati (US 2026/0051378 A1).
Regarding claim 11, Dixit does not specify: further comprising storing, by the processor, generated credentials associated with the acquisition entity in a secure credential store accessible only during runtime and isolated from users, the generated credentials used for authentication during the integration of acquisition entity data with the target shared data resource of the target multitenant platform. However, Dixit in view of Nehzati discloses: further comprising storing, by the processor, generated credentials associated with the acquisition entity in a secure credential store accessible only during runtime and isolated from users, the generated credentials used for authentication during the integration of acquisition entity data with the target shared data resource of the target multitenant platform.
Refer to at least [0057] and [0059] of Nehzati with respect to providing credential and key management using a security module and a hardware security module backed vault through data integration. Credentials may be isolated.
The teachings of Dixit and Nehzati both concern data integration and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Dixit to further implement the security module of Nehzati for at least the purpose of securing encryption keys from malicious tampering and data breaches.
Claim(s) 12-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dixit as applied to claims 1-4, 7, and 10 above, and further in view of Schein (US 2023/0207123 A1).
Regarding claim 12, Dixit discloses general AI training, but does not specify: further comprising training, by the processor, the predictive model using historical data and known data discrepancies to improve accuracy in detecting potential data discrepancies in future integrated data. However, Dixit in view of Schein discloses: further comprising training, by the processor, the predictive model using historical data and known data discrepancies to improve accuracy in detecting potential data discrepancies in future integrated data.
Refer to at least the abstract, [0024], and [0091]-[0093] of Schein with respect to training anomaly models using historical data and analyst feedback (correct/incorrect identification).
The teachings of Dixit and Schein both concern data integration and trained anomaly detection models, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Dixit to further implement training using historical data, determinations, and feedback because the particular known technique was recognized as part of the ordinary capabilities of one skilled in the art.
Regarding claim 13, it is rejected for substantially the same reasons as claim 12 above (i.e., citations and obviousness rationale concerning feedback).
Regarding claim 14, Dixit-Schein discloses: The method of claim 12, further comprising validating, by the processor, the output of the predictive model against known outcomes to improve a performance metric of the predictive model over time.
Refer to at least [0064]-[0065] of Schein with respect to validating the model.
This claim would have been obvious for substantially the same reasons as claim 12 above.
Regarding claim 15, Dixit-Schein discloses: The method of claim 12, further comprising employing a plurality of different machine learning algorithms in the predictive model to optimize detection of potential data discrepancies.
Refer to at least [0030] and [0027] with respect to models trained per domain.
Refer to at least FIG. 1 and [0021] of Schein with respect to a plurality of anomaly detection models.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Dixit to use a plurality of anomaly detection models together for at least the purpose of more accurately evaluating data anomalies at a high granularity (i.e., a more specific model can catch discrepancies for a particular domain that may be missed by a more general model).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432
Prosecution Insights