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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of U.S. Patent No. 12,572,674. Although claims 7, 14, and 20 are not identical to the corresponded patented depended claims, they are not patentably distinct from each other because the claims of the ‘674 patent already include all the limitations of the instant claims.
Instant Application
U.S. Patent No. 12,572,674
Claim (1). A system comprising:
an enterprise computing device hosting at least one data repository;
a neuro-symbolic assessment platform, comprising:
a processor; and memory storing computer-readable instructions that, when executed by the processor, cause the neuro-symbolic assessment platform to:
receive, from a data consuming application, an API function call;
receive, based on the API function call, user information from at least one user device;
determine, based on neuro-symbolic analysis of the user information, a data access level; and
build, based on the data access level and from the at least one data repository of the enterprise computing device, a consolidated data repository, wherein the consolidated data repository comprises data associated with a response to the API function call; and
return, to the data consuming application, at least one portion of data stored in the consolidated data repository.
Claim (1). A system comprising:
an enterprise computing device hosting at least one data repository;
one or more Internet of things (IoT) edge devices; a neuro-symbolic assessment platform, comprising:
a processor; and memory storing computer-readable instructions that, when executed by the processor, cause the neuro-symbolic assessment platform to:
receive, from a data consuming application, an API function call;
receive, based on the API function call, user information from the one or more loT edge devices;
generate a neuro-symbolic rule set based on the user information;
determine, based on neuro-symbolic analysis of the user information and the neuro-symbolic rule set, a data access level; and
build, based on the data access level and from the at least one data repository of the enterprise computing device, a consolidated data repository, wherein the consolidated data repository comprises data associated with a response to the API function call; and
return, to the data consuming application, at least one portion of data stored in the consolidated data repository.
Claim (2). The system of claim 1, wherein the instructions further cause the cause the neuro-symbolic assessment platform to receive, from the API function call, a user identifier and wherein the user information is received based on the user identifier.
Claim (2). The system of claim 1, wherein the instructions further cause the cause the neuro-symbolic assessment platform to receive, from the API function call, a user identifier and wherein the user information is received based on the user identifier.
Claim (3). The system of claim 1, wherein the data consuming application is operational on a third-party computing system external to an enterprise computing network comprising the enterprise computing device.
Claim (3). The system of claim 1, wherein the data consuming application is operational on a third-party computing system external to an enterprise computing network comprising the enterprise computing device.
Claim (4). The system of claim 1, wherein the user device comprises an internet of things (IoT) device.
Claim (4). The system of claim 1, wherein the one or more IoT edge devices collect information from IoT devices in proximity to a user.
Claim (5). The system of claim 1, wherein the neuro-symbolic analysis of the user information comprises identifying a user access pattern.
Claim (5). The system of claim 1, wherein the neuro-symbolic analysis of the user information comprises identifying a user behavioral pattern.
Claim (6). The system of claim 1, wherein the instructions cause the neuro-symbolic assessment platform to:
iteratively build each data object stored in the consolidated data repository.
Claim (6). The system of claim 1, wherein the instructions cause the neuro-symbolic assessment platform to dynamically build each data object stored in the consolidated data repository.
Claim (7). The system of claim 6, wherein the instructions further cause the neuro-symbolic assessment platform to:
retrieve, from the at least one data repository of the enterprise computing device based on a first access level, a first portion of a data record; and
retrieve, from the at least one data repository of the enterprise computing device based on a second access level a second portion of the data record, wherein the at least one portion of the data stored in the consolidated data repository comprises the first portion of the data record and the second portion of the data record.
Claim (7). The system of claim 6, wherein the instructions further cause the neuro-symbolic assessment platform to dynamically adjust the neuro-symbolic rule set based on geographic locations associated with the one or more IoT edge devices.
Claim (8). A neuro-symbolic assessment platform, comprising:
a processor; and
memory storing computer-readable instructions that, when executed by the processor, cause the neuro-symbolic assessment platform to:
receive, from a data consuming application, an API function call;
receive, based on the API function call, user information from at least one user device;
determine, based on neuro-symbolic analysis of the user information, a data access level; and
build, based on the data access level and from at least one data repository of an enterprise computing device, a consolidated data repository, wherein the consolidated data repository comprises data associated with a response to the API function call; and
return, to the data consuming application,
at least one portion of data stored in the consolidated data repository.
Claim (8). A neuro-symbolic assessment platform, comprising:
a processor; and
memory storing computer-readable instructions that, when executed by the processor, cause the neuro-symbolic assessment platform to:
receive, from a data consuming application, an API function call;
receive, based on the API function call, user information from one or more IoT edge devices; generate a neuro-symbolic rule set based on the user information;
determine, based on neuro-symbolic analysis of the user information and the neuro-symbolic rule set, a data access level; and build, based on the data access level and from at least one data repository of an enterprise computing device, a consolidated data repository, wherein the consolidated data repository comprises data associated with a response to the API function call; and return, to the data consuming application,
at least one portion of data stored in the consolidated data repository.
Claim (9). The neuro-symbolic assessment platform of claim 8, wherein the instructions further cause the cause the neuro-symbolic assessment platform to receive, from the API function call, a user identifier and wherein the user information is received based on the user identifier.
Claim (9). The neuro-symbolic assessment platform of claim 8, wherein the instructions further cause the cause the neuro-symbolic assessment platform to receive, from the API function call, a user identifier and wherein the user information is received based on the user identifier.
Claim (10). The neuro-symbolic assessment platform of claim 8, wherein the data consuming application is operational on a third-party computing system external to an enterprise computing network comprising the enterprise computing device.
Claim (10). The neuro-symbolic assessment platform of claim 8, wherein the data consuming application is operational on a third-party computing system external to an enterprise computing network comprising the enterprise computing device.
Claim (11). The neuro-symbolic assessment platform of claim 8, wherein the user device comprises an internet of things (IoT) device.
Claim (11). The neuro-symbolic assessment platform of claim 8, wherein the one or more IoT edge devices collect information from IoT devices in proximity to a user.
Claim (12). The neuro-symbolic assessment platform of claim 8, wherein the neuro-symbolic analysis of the user information comprises identifying a user access pattern.
Claim (12). The neuro-symbolic assessment platform of claim 8, wherein the neuro-symbolic analysis of the user information comprises identifying a user behavioral pattern.
Claim (13). The neuro-symbolic assessment platform of claim 8, wherein the instructions cause the neuro-symbolic assessment platform to iteratively build each data object stored in the consolidated data repository.
Claim (13). The neuro-symbolic assessment platform of claim 8, wherein the instructions cause the neuro-symbolic assessment platform to iteratively build each data object stored in the consolidated data repository.
Claim (14). The neuro-symbolic assessment platform of claim 13, wherein the instructions further cause the neuro-symbolic assessment platform to:
retrieve, from the at least one data repository of the enterprise computing device based on a first access level, a first portion of a data record; and
retrieve, from the at least one data repository of the enterprise computing device based on a second access level a second portion of the data record, wherein the at least one portion of the data stored in the consolidated data repository comprises the first portion of the data record and the second portion of the data record.
Claim (14). The neuro-symbolic assessment platform of claim 13, wherein the instructions further cause the neuro-symbolic assessment platform to dynamically adjust the neuro-symbolic rule set based on geographic locations associated with the one or more IoT edge devices.
Claim (15). Non-transitory computer readable media storing instructions that, when executed by a processor, cause a neuro-symbolic assessment platform to:
receive, from a data consuming application, an API function call; receive, based on the API function call, user information from at least one user device;
determine, based on neuro-symbolic analysis of the user information, a data access level; and
build, based on the data access level and from at least one data repository of an enterprise computing device, a consolidated data repository, wherein the consolidated data repository comprises data associated with a response to the API function call; and return, to the data consuming application, at least a portion of data stored in the consolidated data repository.
Claim (15). Non-transitory computer readable media storing instructions that, when executed by a processor, cause a neuro-symbolic assessment platform to:
receive, from a data consuming application, an API function call; receive, based on the API function call, user information from one or more IoT edge devices;
generate a neuro-symbolic rule set based on the user information;
determine, based on neuro-symbolic analysis of the user information and the neuro-symbolic rule set, a data access level; and build, based on the data access level and from at least one data repository of an enterprise computing device, a consolidated data repository, wherein the consolidated data repository comprises data associated with a response to the API function call; and return, to the data consuming application, at least one portion of data stored in the consolidated data repository.
Claim (16). The non-transitory computer readable media of claim 15, wherein the instructions further cause the cause the neuro-symbolic assessment platform to receive, from the API function call, a user identifier and wherein the user information is received based on the user identifier.
Claim (16). The non-transitory computer readable media of claim 15, wherein the instructions further cause the cause the neuro-symbolic assessment platform to receive, from the API function call, a user identifier and wherein the user information is received based on the user identifier.
Claim (17). The non-transitory computer readable media of claim 16, wherein the data consuming application is operational on a third-party computing system external to an enterprise computing network comprising the enterprise computing device
Claim (17). The non-transitory computer readable media of claim 16, wherein the data consuming application is operational on a third-party computing system external to an enterprise computing network comprising the enterprise computing device.
Claim (18). The non-transitory computer readable media of claim 15, wherein the user device comprises an internet of things (IoT) device.
Claim (18). The non-transitory computer readable media of claim 15, wherein the one or more IoT edge devices collect information from IoT devices in proximity to a user.
Claim (19). The non-transitory computer readable media of claim 15, wherein the neuro-symbolic analysis of the user information comprises identifying a user access pattern.
Claim (19). The non-transitory computer readable media of claim 15, wherein the neuro-symbolic analysis of the user information comprises identifying a user behavioral pattern.
Claim (20). The non-transitory computer readable media of claim 15, wherein the instructions cause the neuro-symbolic assessment platform to iteratively build each data object stored in the consolidated data repository.
Claim (20). The non-transitory computer readable media of claim 15, wherein the instructions further cause the neuro-symbolic assessment platform to dynamically adjust the neuro-symbolic rule set based on geographic locations associated with the one or more IoT edge devices.
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 are 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.
Claims 1 recite that “receive, based on the API function call, user information from at least one user device” and “determine, based on neuro-symbolic analysis of the user information, a data access level.” Claim 8 recites similar limitations. Claim 15 also recites similar limitations in computer-readable-media form.
The specification describes a more particular implementation in which the neuro-symbolic assessment, enables system performs assessment using information received from IoT edge devices, neural network processing, symbolic reasoning, and a neuro-symbolic rule set. The specification further describes the neuro symbolic assessment engine and symbol validation system dynamically building and processing a rule set for verification of the user, and adapting that rule set based on information such as geographic location and user validation information.
However, claims 1, 8, and 15 do not require the user information to be received from the IoT edge devices, do not require generating or processing a neuro-symbolic rule set, and do not recite the particular disclosed relationship between the neural network component, symbolic reasoning component, rule set, and access level determination. Instead, the claims broadly recite determining “a data access level” based on “neuro symbolic analysis of the user information” received from “at least one user device.”
The specification, as originally filed does not reasonably convey possession of the full scope of using any “at least one user device” and any “neuro symbolic analysis of the user information” to determine “a data access level,” absent the more specific disclosed rule set and IoT edge device framework. While the specification provides examples of neuro symbolic assessment engine operating with IoT device edge information, symbolic validation, and dynamically built and adapted rule set, the claims are boarder than the disclosure and encompass implementations not described with sufficient detail in the specification.
As per MPEP § 2161.01, problems satisfying the written description requirement for original claims often occur when claim language is generic or functional, or both. Ariad, 593 F.3d at 1349, 94 USPQ2d at 1171 ("The problem is especially acute with genus claims that use functional language to define the boundaries of a claimed genus. In such a case, the functional claim may simply claim a desired result, and may do so without describing species that achieve that result. But the specification must demonstrate that the applicant [inventor] has made a generic invention that achieves the claimed result and do so by showing that the applicant [inventor] has invented species sufficient to support a claim to the functionally-defined genus.").
As explained in Lizardtech, a disclosure of particular way of achieving a result does not necessarily provide written description support for claims covering all ways of achieving that result. LizardTech, 424 F.3d at 1345-46. Similarly, in this application, the specification describes particular neuro-symbolic assessment implementation involving IoT edge device information and neuro symbolic rule set processing, but the claims encompass broader implementations that are not reasonably conveyed by the original disclosure.
Accordingly, one skilled in the art would not understand from the originally filed disclosure that applicant was in possession of the full scope of claims 1, 8, and 15, including the broadly recited limitation of determining “a data access level” based on “neuro symbolic analysis of the user information” received from “at least one user device,” without requiring the disclosed IoT edge device and neuro symbolic rule set implementation.
Claims depending from the rejected independent claims inherit the written description deficiency of their respective base claims. Accordingly, claim 2-7 depend directly or indirectly from claim 1 and inherit the written description deficiency of claim 1; claim 9-14 depend directly or indirectly from claim 8 and inherit the written description deficiency of claim 8; and claim 16-20 depend directly or indirectly from claim 15 and inherit the written description deficiency of claim 15.
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 2, 7, 9, 14, 16, and 17 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.
Claim 2 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “wherein the instructions further cause the cause the neuro-symbolic assessment platform to receive, from the API function call, a user identifier and wherein the user information is received based on the user identifier” does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claims. Claim 2 recites “cause the cause the neuro-symbolic assessment platform, “which is grammatically unclear. It is unclear whether the claim intends to recite “cause the neuro-symbolic assessment platform” or some other limitation. Therefore, the scope of claim 2 is unclear.
Claim 7 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “retrieve, from the at least one data repository of the enterprise computing device based on a second access level a second portion of the data record” does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claims. Claim 7 recites “based on a second access level a second portion of the data record,” which is grammatically unclear. It is unclear whether the claim intends to recite retrieving “a second portion of data record based on a second access level,” or some other limitation. Therefore, the scope of claim 7 is unclear.
Claim 9 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “wherein the instructions further cause the cause the neuro-symbolic assessment platform to receive, from the API function call, a user identifier and wherein the user information is received based on the user identifier” does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claims. Claim 9 recites “cause the cause the neuro-symbolic assessment platform,” which is grammatically unclear. It is unclear whether the claim intends to recite retrieving “cause the neuro-symbolic assessment platform” or some other limitation. Therefore, the scope of claim 9 is unclear.
Claim 14 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “retrieve, from the at least one data repository of the enterprise computing device based on a second access level a second portion of the data record” does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claims. Claim 14 recites “based on a second access level a second portion of the data record,” which is grammatically unclear. It is unclear whether the claim intends to recite retrieving “a second portion of data record based on a second access level,” or some other limitation. Therefore, the scope of claim 14 is unclear.
Claim 16 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “wherein the instructions further cause the cause the neuro-symbolic assessment platform to receive, from the API function call, a user identifier and wherein the user information is received based on the user identifier” does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claims. Claim 16 recites “cause the cause the neuro-symbolic assessment platform,” which is grammatically unclear. It is unclear whether the claim intends to recite retrieving “cause the neuro-symbolic assessment platform” or some other limitation. Therefore, the scope of claim 16 is unclear.
Claim 17 depends from claim 16 and therefore inherits the indefiniteness of claim 16.
Claims depending from the rejected claims inherit the indefiniteness of their respective base claims. Accordingly, claim 17 depends directly from claim 16 and inherits the indefiniteness of claim 16.
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 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding claims 1, 8, and 15:
Applying Step 1 of the Subject Matter Eligibility Test (SMET), does the claim as a whole fall within one of the four statutory categories of invention? Yes.
Claims 1 is directed to “a system comprising: an enterprise computing device hosting at least one data repository” and “a neuro-symbolic assessment platform” including “a processor” and “memory storing computer-readable instructions,” and therefore fall within the machine category. Claims 8 is directed to “a neuro-symbolic assessment platform” including “a processor” and “memory storing computer-readable instructions,” and therefore fall within the machine category., and therefore fall within the process category. Claims 15 is directed to “non-transitory computer readable media storing instructions that, when executed by a processor, cause a neuro-symbolic assessment platform to” perform the recited operations, and therefore falls within the manufacture category.
Applying Step 2A of the SMET, also known at this stage as the Alice/Mayo Test, Prong One, is the claim as a whole directed to a law of nature, a natural phenomenon (product of nature) or an abstract idea? Yes.
The claim recites the abstract steps of:
Receive, from a data consuming application;
An API function call;
Receive, based on the API function call;
User information from at least one user device;
Determine, based on neuro-symbolic analysis of the user information;
A data access level;
Build, based on the data access level and from the at least one data repository of the enterprise computing device, a consolidated data repository; and
Return, to the data consuming application, at least one portion of data stored in the consolidated data repository, and amount to collecting information, analyzing information, determining an access authorization or access level, organizing information, preparing responsive information, and reporting or returning permitted information, which falls within the mental process grouping. The limitations are also directed to data organization and data manipulation because the claimed invention uses user information to determine what data may be accessed and then builds and returns selected data based on that access determination. (see MPEP 2106.04(a)(2)(iii)(C)).
It should be noted that a person either with or without a physical aid, review user information, review an API request, determine whether a user should have a certain access level, identify what information may be shared with that user, organize the permitted information, and provide the permitted information to the requesting party. Therefore, the claimed concept can be practically performed in the human mind or with pen and paper.
Applying Step 2A, Prong Two, does the claim recite additional elements that integrate the judicial exception into a practical application? No.
The claim recites the additional elements of:
An enterprise computing device;
At least one data repository;
A neuro-symbolic assessment platform;
A processor;
Memory storing computer-readable instructions;
A data consuming application;
An API function call;
At least one user device;
A data access level; and
A consolidated data repository.
A claim reciting a judicial exception is not directed to the judicial exception if it also recites additional elements demonstrating that the claim as a whole integrates the exception into a practical application One way to demonstrate such integration is when the claimed invention improves the functioning of a computer or improves another technology or technical field. However, the additional elements recited above do no such thing and do not improve the functioning of the computer, processor, memory, API, data repository, user device or enterprise computing device. The claimed invention merely uses off the generic computer components to gather, user/API information, analyze the information to determine an access level, organize data for a response, and returning selected data. The memory stores instructions, the processor execute the instructions, and the functional platform performs high-level information processing. The claim does not recite any particularized data structure, specialized API architecture, improved computer security protocol, improved neural network architecture, improved symbolic reasoning structure, improved database operation, improved processor performance, or improvement to computer functionality itself. However, courts have indicated that gathering and analyzing information using conventional techniques and displaying the result may not be sufficient to show an improvement to technology (see TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48; Electric Power group, 830 F.3d at 1353-54).
Although the claims recite “neuro-symbolic analysis,” the claims do not recite a particular neural network architecture, a particular symbolic reasoning architecture, a particular rule-generation algorithm, a particular training method, or a specific improvement to computer functionality. Rather the claims recite “neuro-symbolic analysis” at a high level as part of determining “a data access level.” Thus, the recited artificial-intelligence terminology merely describes the type of analysis used to perform the abstract access-control determination and does not integrate the judicial exception into a practical application.
Thus, this judicial exception is not integrated into a practical application and the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception as argued above.
Applying Step 2B, do the additional elements amount to an inventive concept? No.
Simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1982-83, is not enough to supply an inventive concept. The additional elements are generic computer components carrying out routine computer functions, such as receiving data, storing data, processing data, determining an authorization or access level, building or organizing responsive data, and returning data. These additional elements are not enough to qualify as “significantly more” when recited in a claim with a judicial exception.
Because claims 1, 8, and 15 fails Step 2B, the claim as a whole is found ineligible for being drawn to an abstract idea and therefore is non-statutory under 35 U.S.C. § 101.
Regarding claims 2-7, 9-14, and 16-20:
The dependent claims do not alter the analysis applied to independent claims 1, 8, and 15.
Claim 2 merely recites “receive, from the API function call, a user identifier” and that “the user information is received based on the user identifier.”
Claim 3 merely recites that “the data consuming application is operational on a third-party computing system external to an enterprise computing network comprising the enterprise computing device.”
Claim 4 merely recites that “the user device comprises an internet of things (IoT) device.”
Claim 5 merely recites that “the neuro-symbolic analysis of the user information comprises identifying a user access pattern.”
Claim 6 merely recites that “iteratively build each data object stored in the consolidated data repository.”
Claim 7 merely recites retrieving “a first portion of data record” based on “a first access level” and retrieving “a second portion of the data record” based on “a second access level.”
Claim 9 merely recites “receive, from the API function call, a user identifier” and that “the user information is received based on the user identifier.”
Claim 10 merely recites that “the data consuming application is operational on a third-party computing system external to an enterprise computing network comprising the enterprise computing device.”
Claim 11 merely recites that “the user device comprises an internet of things (IoT) device.”
Claim 12 merely recites that “the neuro-symbolic analysis of the user information comprises identifying a user access pattern.”
Claim 13 merely recites that “iteratively build each data object stored in the consolidated data repository.”
Claim 14 merely recites retrieving “a first portion of data record” based on “a first access level” and retrieving “a second portion of the data record” based on “a second access level.”
Claim 16 merely recites “receive, from the API function call, a user identifier” and that “the user information is received based on the user identifier.”
Claim 17 merely recites that “the data consuming application is operational on a third-party computing system external to an enterprise computing network comprising the enterprise computing device.”
Claim 18 merely recites that “the user device comprises an internet of things (IoT) device.”
Claim 19 merely recites that “the neuro-symbolic analysis of the user information comprises identifying a user access pattern.”
Claim 20 merely recites that “iteratively build each data object stored in the consolidated data repository.
These additional limitations either further narrow the abstract idea, specify the type of information being received or analyzed, specify the type of user device, specify the location of the data consuming application, identify an access pattern, recite iterative data object building, or recite returning different portions of data based on different access levels. None of these limitations integrates the abstract idea into a practical application or adds significantly more than the abstract idea itself. Accordingly, claims 2-7, 9-14, and 16-20 are also rejected under 35 U.S.C. 101.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Coffing et al, (U.S. PGPub. No. 2022/0224535 A1, hereinafter Coffing) in view of Chen et al (U.S. PGPub. No. 2024/0069994 A1, hereinafter Chen).
As to Claim 1, Coffing teaches:
A system comprising: an enterprise computing device hosting at least one data repository; (see Coffing, [¶¶0030, 0040]: “FIG. 3 is a block diagram of an exemplary authentication and authorization system with a network architecture. As illustrated, an exemplary network environment 300 may include a variety of different entities, including a user device 301, a client application 210, an identity provider and authenticator 303, an authorization control plane 304, an API management 305, one or more APIs 306, and an enterprise service 307. Referring to FIG. 3, the enterprise service 307 is an external source of data and may be queried by the authorization control plane 304 to provide the user an access to the data stored in the enterprise service 307.”);
(Coffing teaches an enterprise service/data source accessible through an API-based authorization architecture.)
a neuro-symbolic assessment platform, comprising: a processor; and memory storing computer-readable instructions that, when executed by the processor, cause the neuro-symbolic assessment platform to: (see Coffing, [¶¶0067, 0068, 0055]: “Such computing devices may include end-user computing devices (e.g., mobile phones, tablets, laptops, desktop computers), servers, relays, routers, network access points, base stations, and the like. The components contained in the computing systems performing the methods and functions disclosed herein are those typically found in computer systems that may be suitable for use with embodiments of the present invention and are intended to represent a broad category of such computer components that are well known in the art. Such computing components may include any variety of computing components known in the art, including memory, processors, and network communication interfaces. Further, the authorization engine 630 may include dynamic rules services 640, machine learning 645, behavioral baseline services 650, authentication services 655, an authorization policy information point 660, and audit services 665.”);
(Coffing teaches a computer-implemented authorization platform having processing hardware, memory, and stored instruction/services for performing dynamic access assessment.)
receive, from a data consuming application, an API function call; (see Coffing, [¶¶0042, 0046]: “The client application 210 receives the intent of the user to access its information and sends an authorization request to authorize the user to the authorization control plane 304 at step 420. At step 470, the client application 210 sends a request to access the desired information to the API management 305 that serves as an entry point to a particular one of the API(s) 306. This request includes the enriched token from step 450 and an API call to the particular API, referred to as an API endpoint. For example, the request may include an API path, such as “/account/123/transactions,” for the API management 305 to search for transactions at an account 123.”);
(Receiving a request from a client application, where the request includes an API call to a particular API.)
receive, based on the API function call, user information from at least one user device; (see Coffing, [¶¶0031, 0044]: “A user may utilize the user device 301 to request access to secured data retrieved from the protected API(s) 306 in the network environment 300. At step 450, the identity provider and authenticator 303 returns stored user details to the authorization control plane 304. For example, the user detail may include a profile information of the user, user attributes, location of the user, originator of the transaction, and frequency at which the user accesses the desired information.”);
(Obtaining user details, including user profile information, attributes, location, transaction originator, and access frequency, in connection with the API access request.)
determine, based on neuro-symbolic analysis of the user information, a data access level; and: (see Coffing, [¶¶0037, 0055-0057, 0059, 0063]: “The microperimeter authorizer 308 defines different factors to authenticate and authorize the user for accessing each of the API(s) 306 that can be utilized by the respective security sidecar (e.g., security sidecar 160 of FIG.1) of each of the associated API(s) 306. The factors may include user attributes, roles, relationships, session attributes, current location, device information, authentication methods used, and risk factor of a transaction user or a device. Moreover, the scope of access may be varied by the microperimeter authorizer 308 according to different user attributes, roles, relationships, session attributes, current location, device information, authentication methods used, and risk factor of a transaction user or a device to provide for the enforcement of rich policies. Further, the authorization engine 630 may include dynamic rules services 640, machine learning 645, behavioral baseline services 650, authentication services 655, an authorization policy information point 660, and audit services 665. The dynamic rules services 640, machine learning 645, and behavioral baseline services 650 may collectively provide for artificial intelligence (AI“)” refinement of the rules or policies applied over time as more data and feedback is received. The relationship fabric (identity grid) 635 may be associated with profile information, such as user names, passwords, contact information, biometric information, user authorization levels, user roles, user behavior metrics, user access history logs. The user access history logs may also be used to determine access patterns to protected resources by particular users and/or particular devices. The authorization policy information point 660 may store user authorization level information representing a plurality of different policies governing permission to access a protected resource or microservice. A behavioral baseline may be established with identified patterns and trends that allow for application of machine learning/AI in evaluation of future risk profiles.);
(Coffing teaches deciding user authorization/access scope using user attributes, location, device information, risk factors, user behavior metrics, access history. Coffing further teaches using dynamic rules, machine learning, and behavioral baseline services to refine authorization rules or policies over time. This teaches/suggests determining a data access level using machine-learning analysis combined with rule-based authorization logic.)
Coffing does not teach but, Chen teaches:
build, based on the data access level and from the at least one data repository of the enterprise computing device, a consolidated data repository, wherein the consolidated data repository comprises data associated with a response to the API function call; and: (see Chen, [¶¶0014, 0023, 0027]: “Each query that is received by the system is handled by the fixed set of APIs by reference to data held in containers in the ADH based on the client's access identifier and selected parameters. The fixed set of Intelligent APIs allow all users and/or channels to query any information that may be available from its API Inquiry DataHub (ADH), increasing a velocity of development, and providing aggregation of multiple systems of records within a scalable and flexible cloud environment. During the fourth stage 140, client access permission levels that have been identified by the authorization module are also provided to the fixed set of predefined intelligent APIs. The API service provider looks up data at the cloud-based datahub, accessing information stored in a cached request-response reference table 152 for backend data source container information as well as cached metadata reference table 154 for the available API metadata (for all of the APIs in the set of fixed APIs). In addition, use of a memory-cache allows for the system to adapt in real-time to changes in access permissions for each user, and limits the flow of data in response to the person's corresponding access level.”);
(Chen teaches using access permissions to retrieve and organize enterprise data from an API inquiry DataHub that aggregates multiple systems of record, so that permitted data is prepared for the API response.)
return, to the data consuming application, at least one portion of data stored in the consolidated data repository. (see Chen, [¶¶0027-0028, 0033]: “Only the data that is designated as accessible for the current permission will be outputted, regardless of whether the request sought information that was outside of that permission scope. In a sixth stage 160, the API service returns its response comprising the relevant data based on a client access permission and input. The API service 270 receives and provides a first response targeted to the customer demographics inquiry that includes customerStatus, customerType, personData, and postAddress, and for the second query 220, the same API service 270 receives and provides a second response targeted to the account list inquiry that includes customerDate, customerType, and accounts, and also for the third query 230, the API service 270 receives and provides a third response targeted to the customer alerts inquiry that includes deliveryChannel, businessFunction, and alerts.”);
(Returning relevant data through the API based on client access permission and outputting only the data is accessible under the current permission.)
It would have been obvious to one of ordinary skill in the art to modify Coffing’s dynamic API authorization system to incorporate Chen’s API inquiry DataHub and cached-reference-table retrieval technique. Coffing already teaches API requests, obtaining user information, and determining the permitted scope of access using user context, dynamic rules machine learning, behavioral baseline services, user authorization levels, user behavioral metrics, and risk-based access decisions. Chen teaches an enterprise API DataHub that aggregates enterprise data and limits returned data based on access permissions. One of the ordinary skill in the art would have been motivated to combine Chen’s enterprise DataHub with Coffing’s authorization system so that authorized API request could be fulfilled by retrieving and returning only permitted portions of enterprise data from a scalable consolidated enterprise data source. The combination would have yielded the predictable benefit of improving API security, scalability, and privacy-controlled enterprise data retrieval.
As to claim 2, Coffing teaches:
wherein the instructions further cause the cause the neuro-symbolic assessment platform to receive, from the API function call, a user identifier and wherein the user information is received based on the user identifier. (see Coffing, [¶¶0027, 0032-0033, 0044, 0046, 0056]: “The client application 210 may be a web application that may be accessible and visible via a web browser. Such a client application 210 may trigger a request (e.g., by a button click). Such request may contain a payload and the access token (e.g., in the request header). The API gateway 130 may authenticate the call and perform authorization, not only checking the scope of authorizations but also invoking all other policies associated with the API. The user device 301 may express intent to access certain information via the client application 210. To access the information, the user may be required to authenticate the identity of the user via the identity provider and authenticator and authenticator 303, such as Okta, OAuth OpenID, FIDO, biometric signatures, and Facebook. The identity provider and authenticator 303 creates, maintains, and manages identity information of users. The identity provider and authenticator 303 may store user credentials, such as login ID and password, and a user profile that includes information relevant to granting access to the user. At step 450, the identity provider and authenticator 303 returns stored user details to the authorization control plane 304. For example, the user detail may include a profile information of the user, user attributes, location of the user, originator of the transaction, and frequency at which the user accesses the desired information. This request includes the enriched token from step 450 and an API call to the particular API, referred to as an API endpoint. As such, the relationship fabric (identity grid) 635 may maintain unique identifiers for each of the users/services/things 605 and may be associated with profile information, such as user names, passwords, contact information, biometric information, user authorization levels, user roles, user behavior metrics, user access history logs.”);
It would have been obvious to one of ordinary skill in the art to use Coffing’s user identification and enriched token teachings in the Coffing-Chen combination because Coffing already uses user identity, user credentials, user profile information, unique identifiers, and enriched tokens to determine whether a user may access requested API data. Using the user identifier to retrieve corresponding user details would have predictably improved the accuracy and security of Coffing’s API authorization process by ensuring that access decisions are based on the correct user context before Chen’s enterprise DataHub returns permitted enterprise data.
As to claim 3, Coffing teaches:
wherein the data consuming application is operational on a third-party computing system external to an enterprise computing network comprising the enterprise computing device. (see Coffing, [¶¶0027, 0030, 0040]: “The client application 210 may be a web application that may be accessible and visible via a web browser. The API gateway 130 may authenticate the call and perform authorization, not only checking the scope of authorizations but also invoking all other policies associated with the API. An exemplary network environment 300 may include a variety of different entities, including a user device 301, a client application 210, an identity provider and authenticator 303, an authorization control plane 304, an API management 305, one or more APIs 306, and an enterprise service 307. Referring to FIG. 3, the enterprise service 307 is an external source of data and may be queried by the authorization control plane 304 to provide the user an access to the data stored in the enterprise service 307.”);
(A client application operating separately from the enterprise service and accessing enterprise data through an API gateway/authorization architecture. Coffing’s web-based client application and separate enterprise service suggest the claimed third-party/external computing arrangement.)
It would have been obvious to one of ordinary skill in the art to configure Coffing’s client application on a computing system external to the enterprise computing network so that outside users or applications could securely request enterprise data through the API gateway while preserving authorization control. Coffing already teaches a web-based client application, public API access, and an enterprise service storing protected data. Such an arrangement would have yielded the predictable benefit of allowing secure external access to enterprise data without exposing the enterprise service directly.
As to claim 4, Coffing teaches:
wherein the user device comprises an internet of things (IoT) device. (see Coffing, [¶¶0031, 0054]: “The user device 301 may be any number of different electronic devices, such as general purpose computers, mobile phones, smartphones, smartwatches, wearable devices, personal digital assistants (“PDAs”), portable computing devices (e.g., laptop, netbook, tablets), desktop computing devices, handheld computing device, smart sensors, smart appliances, loT devices, devices networked to controllers for smart control, servers and server systems (including cloud-based servers and server systems), or any other type of computing device capable of communicating over a communication network. An authorization engine 600 (e.g., Cloudentity TRUST EngineTM) may be executed to evaluate risks in transactions conducted by various users, services, and things (e.g., loT devices) 605.”);
It would have been obvious to one of ordinary skill in the art to use an IoT device as Coffing’s user device because Coffing expressly identifies IoT devices, smart sensors, and smart appliances as examples of user devices capable of requesting access to protected API data. Using such devices would have predictably allowed authorization system to support secure access requests from modern connected devices in the same API-based authorization environment.
As to claim 5, Coffing teaches:
The system of claim 1, wherein the neuro-symbolic analysis of the user information comprises identifying a user access pattern. (see Coffing, [¶¶0056-0057, 0063]: “The relationship fabric (identity grid) 635 refers to an interwoven collection of discrete identity elements for each user that may be collectively used to track and infuse identity attributes (and rights) throughout the distributed infrastructure. As such, the relationship fabric (identity grid) 635 may maintain unique identifiers for each of the users/services/things 605 and may be associated with profile information, such as user names, passwords, contact information, biometric information, user authorization levels, user roles, user behavior metrics, user access history logs. The user access history logs may also be used to determine access patterns to protected resources by particular users and/or particular devices. The user behavior information may include data representing a plurality of different user behavior metrics, including access patterns. A behavioral baseline may be established with identified patterns and trends that allow for application of machine learning/AI in evaluation of future risk profiles.”);
It would have been obvious to one of ordinary skill in the art to use Coffing’s access-history and behavioral baseline teachings in the Coffing-Chen combination because Coffing already uses user behavior metrics, access history logs, and access patterns to evaluate risk and determine access permissions. Identifying a user access pattern would have predictably improved the accuracy of the access decision before Chen’s enterprise DataHub returns permitted data.
As to claim 6, the combination Coffing in view of Chen teaches:
wherein the instructions cause the neuro-symbolic assessment platform to: iteratively build each data object stored in the consolidated data repository. (see Coffing, [¶¶0028-0029, 0035, 0053]: “The proxy may use a security plugin to validate each incoming request and to transform each outgoing request. Outgoing requests may likewise be proxied. The proxy may call the security sidecar 160 to transform an outgoing request. The authorization control plane 304 may also store security policies regarding accessing APIs, store user context received from the identity provider and authenticator 303, store user requests for data from APIs and user consents. User data associated with a user requesting endpoints may be received by the system from the user device 301, the identity provider and authenticator 303, the enterprise service 307, or other database to access the endpoints. Only some portions of this user data may be needed by each microservice. Microservice 5 may have access to Portions D, E, and F of the user data, whereas Microservice 6 may only have access to Portions D and F of the user data. The system may further keep a record of the data lineage regarding where the user data was received from (e.g., identity provider or enterprise service) and which microservices are consuming such user data and display the data lineage in the API management interface.”);
(Coffing teaches receiving data from multiple sources, transforming outgoing requests, storing user context/request information, and controlling which portions of user data are provided to different microservices. Coffing further teaches tracking data lineage showing where the data was received from and which microservices consumed the data.)
It would have been obvious to one of ordinary skill in the art to apply Coffing’s microservice-based data portioning and data-lineage process in the Coffing-Chen combination so that the enterprise data prepared for an authorized API response could be assembled from only the permitted data portions. Coffing already teaches using different microservices to consume different portions of data and tracking the source and consumption of that data. Chen teaches a consolidated enterprise DataHub used to prepare API response data based on access permissions. Combining these teaching would have predictably improved security and efficiency by allowing the system to build authorized response data step by step while preventing unauthorized data portions from being included.
As to claim 7, the combination Coffing in view of Chen teaches:
wherein the instructions further cause the neuro-symbolic assessment platform to: retrieve, from the at least one data repository of the enterprise computing device based on a first access level, a first portion of a data record; and retrieve, from the at least one data repository of the enterprise computing device based on a second access level a second portion of the data record, wherein the at least one portion of the data stored in the consolidated data repository comprises the first portion of the data record and the second portion of the data record. (see Coffing, [¶¶0037, 0050, 0053]: “Moreover, the scope of access may be varied by the microperimeter authorizer 308 according to different user attributes, roles, relationships, session attributes, current location, device information, authentication methods used, and risk factor of a transaction user or a device to provide for the enforcement of rich policies. User123, has access to microservices 1, 2, 3, and 4, including all protected functions. Another sample individual user, User456, has access to all functions of microservices 1, 2, and 4, and Functions A and C of microservice 3. User456 does not have access to Function B of microservice 3. Only some portions of this user data may be needed by each microservice. Microservice 5 may have access to Portions D, E, and F of the user data, whereas Microservice 6 may only have access to Portions D and F of the user data.”);
(see Chen, [¶¶0015, 0027-0028]: “A third step includes retrieving, by a first microservice associated with the API and from the datahub, a first data document associated with the first data container, and a fourth step includes selecting, by the first microservice, a first value for an endpoint stored in the first data document based on the first parameter via the cached reference table. During the fourth stage 140, client access permission levels that have been identified by the authorization module are also provided to the fixed set of predefined intelligent APIs. Only the data that is designated as accessible for the current permission will be outputted, regardless of whether the request sought information that was outside of that permission scope. In a sixth stage 160, the API service returns its response comprising the relevant data based on a client access permission and input.”);
(Coffing teaches varying the scope of access based on user attributes, roles, location, device information, authentication methods, and risk factors. Coffing also teaches that different users and microservices receive different portions of user data, such as microservice receiving portions D, E, and F while another receives only portions D, and E. Chen teaches retrieving data documents from an enterprise DataHub and selecting values from those documents based on access permission.)
It would have been obvious to one of ordinary skill in the art to apply Coffing’s varied access scope and data portioning teachings to Chen enterprise DataHub retrieval process so that different access levels would result in retrieval of different permitted portions of the same enterprise data record. Coffing already teaches that different users or microservices may receive different portions of data based on authorization scope. Chen teaches retrieving selected values from data documents in a DataHub and outputting only data accessible under the current permission. The combination would have yielded to predictable benefit of improving privacy-controlled data retrieval by allowing the system to return only the data portions authorized for user’s current access level.
As to Claim 8, Coffing teaches:
A neuro-symbolic assessment platform, comprising: a processor; and memory storing computer-readable instructions that, when executed by the processor, cause the neuro-symbolic assessment platform to: (see Coffing, [¶¶0055, 0067-0068]: “Further, the authorization engine 630 may include dynamic rules services 640, machine learning 645, behavioral baseline services 650, authentication services 655, an authorization policy information point 660, and audit services 665. Data may be received directly from another computing device or may be received indirectly via one or more intermediary computing devices. Such computing devices may include end-user computing devices (e.g., mobile phones, tablets, laptops, desktop computers), servers, relays, routers, network access points, base stations, and the like. The components contained in the computing systems performing the methods and functions disclosed herein are those typically found in computer systems that may be suitable for use with embodiments of the present invention and are intended to represent a broad category of such computer components that are well known in the art. Such computing components may include any variety of computing components known in the art, including memory, processors, and network communication interfaces. Further, the present invention may be implemented in an application that may be operable using a variety of devices. Non-transitory computer-readable storage media refer to any medium or media that participate in providing instructions to a central processing unit (“CPU”) for execution.”);
(A computer implemented authorization/assessment platform having computing devices, processors, memory, and stored instructions for performing dynamic authorization and access assessment.)
receive, from a data consuming application, an API function call; (see Coffing, [¶¶0042, 0046]: “The client application 210 receives the intent of the user to access its information and sends an authorization request to authorize the user to the authorization control plane 304 at step 420. At step 470, the client application 210 sends a request to access the desired information to the API management 305 that serves as an entry point to a particular one of the API(s) 306. This request includes the enriched token from step 450 and an API call to the particular API, referred to as an API endpoint. For example, the request may include an API path, such as “/account/123/transactions,” for the API management 305 to search for transactions at an account 123.”);
(Receiving a request from a client application, where the request includes an API call to a particular API.)
receive, based on the API function call, user information from at least one user device; (see Coffing, [¶¶0031, 0044]: “A user may utilize the user device 301 to request access to secured data retrieved from the protected API(s) 306 in the network environment 300. At step 450, the identity provider and authenticator 303 returns stored user details to the authorization control plane 304. For example, the user detail may include a profile information of the user, user attributes, location of the user, originator of the transaction, and frequency at which the user accesses the desired information.”);
(Obtaining user details, including user profile information, attributes, location, transaction originator, and access frequency, in connection with the API access request.)
determine, based on neuro-symbolic analysis of the user information, a data access level; (see Coffing, [¶¶0037, 0055-0057, 0059, 0063]: “The microperimeter authorizer 308 defines different factors to authenticate and authorize the user for accessing each of the API(s) 306 that can be utilized by the respective security sidecar (e.g., security sidecar 160 of FIG.1) of each of the associated API(s) 306. The factors may include user attributes, roles, relationships, session attributes, current location, device information, authentication methods used, and risk factor of a transaction user or a device. Moreover, the scope of access may be varied by the microperimeter authorizer 308 according to different user attributes, roles, relationships, session attributes, current location, device information, authentication methods used, and risk factor of a transaction user or a device to provide for the enforcement of rich policies. Further, the authorization engine 630 may include dynamic rules services 640, machine learning 645, behavioral baseline services 650, authentication services 655, an authorization policy information point 660, and audit services 665. The dynamic rules services 640, machine learning 645, and behavioral baseline services 650 may collectively provide for artificial intelligence (AI“)” refinement of the rules or policies applied over time as more data and feedback is received. The relationship fabric (identity grid) 635 may be associated with profile information, such as user names, passwords, contact information, biometric information, user authorization levels, user roles, user behavior metrics, user access history logs. The user access history logs may also be used to determine access patterns to protected resources by particular users and/or particular devices. The authorization policy information point 660 may store user authorization level information representing a plurality of different policies governing permission to access a protected resource or microservice. A behavioral baseline may be established with identified patterns and trends that allow for application of machine learning/AI in evaluation of future risk profiles.);
(Coffing teaches deciding user authorization/access scope using user attributes, location, device information, risk factors, user behavior metrics, access history. Coffing further teaches using dynamic rules, machine learning, and behavioral baseline services to refine authorization rules or policies over time. This teaches/suggests determining a data access level using machine-learning analysis combined with rule-based authorization logic.)
Coffing does not teach but, Chen teaches:
and build, based on the data access level and from at least one data repository of an enterprise computing device, a consolidated data repository, wherein the consolidated data repository comprises data associated with a response to the API function call; (see Chen, [¶¶0014, 0023, 0027]: “Each query that is received by the system is handled by the fixed set of APIs by reference to data held in containers in the ADH based on the client's access identifier and selected parameters. The fixed set of Intelligent APIs allow all users and/or channels to query any information that may be available from its API Inquiry DataHub (ADH), increasing a velocity of development, and providing aggregation of multiple systems of records within a scalable and flexible cloud environment. During the fourth stage 140, client access permission levels that have been identified by the authorization module are also provided to the fixed set of predefined intelligent APIs. The API service provider looks up data at the cloud-based datahub, accessing information stored in a cached request-response reference table 152 for backend data source container information as well as cached metadata reference table 154 for the available API metadata (for all of the APIs in the set of fixed APIs). In addition, use of a memory-cache allows for the system to adapt in real-time to changes in access permissions for each user, and limits the flow of data in response to the person's corresponding access level.”);
(Chen teaches using access permissions to retrieve and organize enterprise data from an API inquiry DataHub that aggregates multiple systems of record, so that permitted data is prepared for the API response.)
and return, to the data consuming application, at least one portion of data stored in the consolidated data repository. (see Chen, [¶¶0027-0028, 0033]: “Only the data that is designated as accessible for the current permission will be outputted, regardless of whether the request sought information that was outside of that permission scope. In a sixth stage 160, the API service returns its response comprising the relevant data based on a client access permission and input. The API service 270 receives and provides a first response targeted to the customer demographics inquiry that includes customerStatus, customerType, personData, and postAddress, and for the second query 220, the same API service 270 receives and provides a second response targeted to the account list inquiry that includes customerDate, customerType, and accounts, and also for the third query 230, the API service 270 receives and provides a third response targeted to the customer alerts inquiry that includes deliveryChannel, businessFunction, and alerts.”);
(Returning relevant data through the API based on client access permission and outputting only the data is accessible under the current permission.)
It would have been obvious to one of ordinary skill in the art to modify Coffing’s dynamic API authorization system to incorporate Chen’s API inquiry DataHub and cached-reference-table retrieval technique. Coffing already teaches API requests, obtaining user information, and determining the permitted scope of access using user context, dynamic rules machine learning, behavioral baseline services, user authorization levels, user behavioral metrics, and risk-based access decisions. Chen teaches an enterprise API DataHub that aggregates enterprise data and limits returned data based on access permissions. One of the ordinary skill in the art would have been motivated to combine Chen’s enterprise DataHub with Coffing’s authorization system so that authorized API request could be fulfilled by retrieving and returning only permitted portions of enterprise data from a scalable consolidated enterprise data source. The combination would have yielded the predictable benefit of improving API security, scalability, and privacy-controlled enterprise data retrieval.
As to claim 9, Coffing teaches:
wherein the instructions further cause the cause the neuro-symbolic assessment platform to receive, from the API function call, a user identifier and wherein the user information is received based on the user identifier. (see Coffing, [¶¶0027, 0032-0033, 0044, 0046, 0056]: “The client application 210 may be a web application that may be accessible and visible via a web browser. Such a client application 210 may trigger a request (e.g., by a button click). Such request may contain a payload and the access token (e.g., in the request header). The API gateway 130 may authenticate the call and perform authorization, not only checking the scope of authorizations but also invoking all other policies associated with the API. The user device 301 may express intent to access certain information via the client application 210. To access the information, the user may be required to authenticate the identity of the user via the identity provider and authenticator and authenticator 303, such as Okta, OAuth OpenID, FIDO, biometric signatures, and Facebook. The identity provider and authenticator 303 creates, maintains, and manages identity information of users. The identity provider and authenticator 303 may store user credentials, such as login ID and password, and a user profile that includes information relevant to granting access to the user. At step 450, the identity provider and authenticator 303 returns stored user details to the authorization control plane 304. For example, the user detail may include a profile information of the user, user attributes, location of the user, originator of the transaction, and frequency at which the user accesses the desired information. This request includes the enriched token from step 450 and an API call to the particular API, referred to as an API endpoint. As such, the relationship fabric (identity grid) 635 may maintain unique identifiers for each of the users/services/things 605 and may be associated with profile information, such as user names, passwords, contact information, biometric information, user authorization levels, user roles, user behavior metrics, user access history logs.”);
It would have been obvious to one of ordinary skill in the art to use Coffing’s user identification and enriched token teachings in the Coffing-Chen combination because Coffing already uses user identity, user credentials, user profile information, unique identifiers, and enriched tokens to determine whether a user may access requested API data. Using the user identifier to retrieve corresponding user details would have predictably improved the accuracy and security of Coffing’s API authorization process by ensuring that access decisions are based on the correct user context before Chen’s enterprise DataHub returns permitted enterprise data.
As to claim 10, Coffing teaches:
wherein the data consuming application is operational on a third-party computing system external to an enterprise computing network comprising the enterprise computing device. (see Coffing, [¶¶0027, 0030, 0040]: “The client application 210 may be a web application that may be accessible and visible via a web browser. The API gateway 130 may authenticate the call and perform authorization, not only checking the scope of authorizations but also invoking all other policies associated with the API. An exemplary network environment 300 may include a variety of different entities, including a user device 301, a client application 210, an identity provider and authenticator 303, an authorization control plane 304, an API management 305, one or more APIs 306, and an enterprise service 307. Referring to FIG. 3, the enterprise service 307 is an external source of data and may be queried by the authorization control plane 304 to provide the user an access to the data stored in the enterprise service 307.”);
(A client application operating separately from the enterprise service and accessing enterprise data through an API gateway/authorization architecture. Coffing’s web-based client application and separate enterprise service suggest the claimed third-party/external computing arrangement.)
It would have been obvious to one of ordinary skill in the art to configure Coffing’s client application on a computing system external to the enterprise computing network so that outside users or applications could securely request enterprise data through the API gateway while preserving authorization control. Coffing already teaches a web-based client application, public API access, and an enterprise service storing protected data. Such an arrangement would have yielded the predictable benefit of allowing secure external access to enterprise data without exposing the enterprise service directly.
As to claim 11, Coffing teaches:
wherein the user device comprises an internet of things (IoT) device. (see Coffing, [¶¶0031, 0054]: “The user device 301 may be any number of different electronic devices, such as general purpose computers, mobile phones, smartphones, smartwatches, wearable devices, personal digital assistants (“PDAs”), portable computing devices (e.g., laptop, netbook, tablets), desktop computing devices, handheld computing device, smart sensors, smart appliances, loT devices, devices networked to controllers for smart control, servers and server systems (including cloud-based servers and server systems), or any other type of computing device capable of communicating over a communication network. An authorization engine 600 (e.g., Cloudentity TRUST EngineTM) may be executed to evaluate risks in transactions conducted by various users, services, and things (e.g., loT devices) 605.”);
It would have been obvious to one of ordinary skill in the art to use an IoT device as Coffing’s user device because Coffing expressly identifies IoT devices, smart sensors, and smart appliances as examples of user devices capable of requesting access to protected API data. Using such devices would have predictably allowed authorization system to support secure access requests from modern connected devices in the same API-based authorization environment.
As to claim 12, Coffing teaches:
wherein the neuro-symbolic analysis of the user information comprises identifying a user access pattern. (see Coffing, [¶¶0056-0057, 0063]: “The relationship fabric (identity grid) 635 refers to an interwoven collection of discrete identity elements for each user that may be collectively used to track and infuse identity attributes (and rights) throughout the distributed infrastructure. As such, the relationship fabric (identity grid) 635 may maintain unique identifiers for each of the users/services/things 605 and may be associated with profile information, such as user names, passwords, contact information, biometric information, user authorization levels, user roles, user behavior metrics, user access history logs. The user access history logs may also be used to determine access patterns to protected resources by particular users and/or particular devices. The user behavior information may include data representing a plurality of different user behavior metrics, including access patterns. A behavioral baseline may be established with identified patterns and trends that allow for application of machine learning/AI in evaluation of future risk profiles.”);
It would have been obvious to one of ordinary skill in the art to use Coffing’s access-history and behavioral baseline teachings in the Coffing-Chen combination because Coffing already uses user behavior metrics, access history logs, and access patterns to evaluate risk and determine access permissions. Identifying a user access pattern would have predictably improved the accuracy of the access decision before Chen’s enterprise DataHub returns permitted data.
As to claim 13, the combination Coffing in view of Chen teaches:
wherein the instructions cause the neuro-symbolic assessment platform to iteratively build each data object stored in the consolidated data repository. (see Coffing, [¶¶0028-0029, 0035, 0053]: “The proxy may use a security plugin to validate each incoming request and to transform each outgoing request. Outgoing requests may likewise be proxied. The proxy may call the security sidecar 160 to transform an outgoing request. The authorization control plane 304 may also store security policies regarding accessing APIs, store user context received from the identity provider and authenticator 303, store user requests for data from APIs and user consents. User data associated with a user requesting endpoints may be received by the system from the user device 301, the identity provider and authenticator 303, the enterprise service 307, or other database to access the endpoints. Only some portions of this user data may be needed by each microservice. Microservice 5 may have access to Portions D, E, and F of the user data, whereas Microservice 6 may only have access to Portions D and F of the user data. The system may further keep a record of the data lineage regarding where the user data was received from (e.g., identity provider or enterprise service) and which microservices are consuming such user data and display the data lineage in the API management interface.”);
(Coffing teaches receiving data from multiple sources, transforming outgoing requests, storing user context/request information, and controlling which portions of user data are provided to different microservices. Coffing further teaches tracking data lineage showing where the data was received from and which microservices consumed the data.)
It would have been obvious to one of ordinary skill in the art to apply Coffing’s microservice-based data portioning and data-lineage process in the Coffing-Chen combination so that the enterprise data prepared for an authorized API response could be assembled from only the permitted data portions. Coffing already teaches using different microservices to consume different portions of data and tracking the source and consumption of that data. Chen teaches a consolidated enterprise DataHub used to prepare API response data based on access permissions. Combining these teaching would have predictably improved security and efficiency by allowing the system to build authorized response data step by step while preventing unauthorized data portions from being included.
As to claim 14, the combination Coffing in view of Chen teaches:
wherein the instructions further cause the neuro-symbolic assessment platform to: retrieve, from the at least one data repository of the enterprise computing device based on a first access level, a first portion of a data record; and retrieve, from the at least one data repository of the enterprise computing device based on a second access level a second portion of the data record, wherein the at least one portion of the data stored in the consolidated data repository comprises the first portion of the data record and the second portion of the data record. (see Coffing, [¶¶0037, 0050, 0053]: “Moreover, the scope of access may be varied by the microperimeter authorizer 308 according to different user attributes, roles, relationships, session attributes, current location, device information, authentication methods used, and risk factor of a transaction user or a device to provide for the enforcement of rich policies. User123, has access to microservices 1, 2, 3, and 4, including all protected functions. Another sample individual user, User456, has access to all functions of microservices 1, 2, and 4, and Functions A and C of microservice 3. User456 does not have access to Function B of microservice 3. Only some portions of this user data may be needed by each microservice. Microservice 5 may have access to Portions D, E, and F of the user data, whereas Microservice 6 may only have access to Portions D and F of the user data.”);
(see Chen, [¶¶0015, 0027-0028]: “A third step includes retrieving, by a first microservice associated with the API and from the datahub, a first data document associated with the first data container, and a fourth step includes selecting, by the first microservice, a first value for an endpoint stored in the first data document based on the first parameter via the cached reference table. During the fourth stage 140, client access permission levels that have been identified by the authorization module are also provided to the fixed set of predefined intelligent APIs. Only the data that is designated as accessible for the current permission will be outputted, regardless of whether the request sought information that was outside of that permission scope. In a sixth stage 160, the API service returns its response comprising the relevant data based on a client access permission and input.”);
(Coffing teaches varying the scope of access based on user attributes, roles, location, device information, authentication methods, and risk factors. Coffing also teaches that different users and microservices receive different portions of user data, such as microservice receiving portions D, E, and F while another receives only portions D, and E. Chen teaches retrieving data documents from an enterprise DataHub and selecting values from those documents based on access permission.)
It would have been obvious to one of ordinary skill in the art to apply Coffing’s varied access scope and data portioning teachings to Chen enterprise DataHub retrieval process so that different access levels would result in retrieval of different permitted portions of the same enterprise data record. Coffing already teaches that different users or microservices may receive different portions of data based on authorization scope. Chen teaches retrieving selected values from data documents in a DataHub and outputting only data accessible under the current permission. The combination would have yielded to predictable benefit of improving privacy-controlled data retrieval by allowing the system to return only the data portions authorized for user’s current access level.
As to claim 15, Coffing teaches:
Non-transitory computer readable media storing instructions that, when executed by a processor, cause a neuro-symbolic assessment platform to: (see Coffing, [¶¶0068]: “The components contained in the computing systems performing the methods and functions disclosed herein are those typically found in computer systems that may be suitable for use with embodiments of the present invention and are intended to represent a broad category of such computer components that are well known in the art. Such computing components may include any variety of computing components known in the art, including memory, processors, and network communication interfaces. Further, the present invention may be implemented in an application that may be operable using a variety of devices. Non-transitory computer-readable storage media refer to any medium or media that participate in providing instructions to a central processing unit (“CPU”) for execution.”);
receive, from a data consuming application, an API function call; (see Coffing, [¶¶0042, 0046]: “The client application 210 receives the intent of the user to access its information and sends an authorization request to authorize the user to the authorization control plane 304 at step 420. At step 470, the client application 210 sends a request to access the desired information to the API management 305 that serves as an entry point to a particular one of the API(s) 306. This request includes the enriched token from step 450 and an API call to the particular API, referred to as an API endpoint. For example, the request may include an API path, such as “/account/123/transactions,” for the API management 305 to search for transactions at an account 123.”);
(Receiving a request from a client application, where the request includes an API call to a particular API.)
receive, based on the API function call, user information from at least one user device; (see Coffing, [¶¶0031, 0044]: “A user may utilize the user device 301 to request access to secured data retrieved from the protected API(s) 306 in the network environment 300. At step 450, the identity provider and authenticator 303 returns stored user details to the authorization control plane 304. For example, the user detail may include a profile information of the user, user attributes, location of the user, originator of the transaction, and frequency at which the user accesses the desired information.”);
(Obtaining user details, including user profile information, attributes, location, transaction originator, and access frequency, in connection with the API access request.)
determine, based on neuro-symbolic analysis of the user information, a data access level; (see Coffing, [¶¶0037, 0055-0057, 0059, 0063]: “The microperimeter authorizer 308 defines different factors to authenticate and authorize the user for accessing each of the API(s) 306 that can be utilized by the respective security sidecar (e.g., security sidecar 160 of FIG.1) of each of the associated API(s) 306. The factors may include user attributes, roles, relationships, session attributes, current location, device information, authentication methods used, and risk factor of a transaction user or a device. Moreover, the scope of access may be varied by the microperimeter authorizer 308 according to different user attributes, roles, relationships, session attributes, current location, device information, authentication methods used, and risk factor of a transaction user or a device to provide for the enforcement of rich policies. Further, the authorization engine 630 may include dynamic rules services 640, machine learning 645, behavioral baseline services 650, authentication services 655, an authorization policy information point 660, and audit services 665. The dynamic rules services 640, machine learning 645, and behavioral baseline services 650 may collectively provide for artificial intelligence (AI“)” refinement of the rules or policies applied over time as more data and feedback is received. The relationship fabric (identity grid) 635 may be associated with profile information, such as user names, passwords, contact information, biometric information, user authorization levels, user roles, user behavior metrics, user access history logs. The user access history logs may also be used to determine access patterns to protected resources by particular users and/or particular devices. The authorization policy information point 660 may store user authorization level information representing a plurality of different policies governing permission to access a protected resource or microservice. A behavioral baseline may be established with identified patterns and trends that allow for application of machine learning/AI in evaluation of future risk profiles.);
(Coffing teaches deciding user authorization/access scope using user attributes, location, device information, risk factors, user behavior metrics, access history. Coffing further teaches using dynamic rules, machine learning, and behavioral baseline services to refine authorization rules or policies over time. This teaches/suggests determining a data access level using machine-learning analysis combined with rule-based authorization logic.)
Coffing does not teach but, Chen teaches:
and build, based on the data access level and from at least one data repository of an enterprise computing device, a consolidated data repository, wherein the consolidated data repository comprises data associated with a response to the API function call; (see Chen, [¶¶0014, 0023, 0027]: “Each query that is received by the system is handled by the fixed set of APIs by reference to data held in containers in the ADH based on the client's access identifier and selected parameters. The fixed set of Intelligent APIs allow all users and/or channels to query any information that may be available from its API Inquiry DataHub (ADH), increasing a velocity of development, and providing aggregation of multiple systems of records within a scalable and flexible cloud environment. During the fourth stage 140, client access permission levels that have been identified by the authorization module are also provided to the fixed set of predefined intelligent APIs. The API service provider looks up data at the cloud-based datahub, accessing information stored in a cached request-response reference table 152 for backend data source container information as well as cached metadata reference table 154 for the available API metadata (for all of the APIs in the set of fixed APIs). In addition, use of a memory-cache allows for the system to adapt in real-time to changes in access permissions for each user, and limits the flow of data in response to the person's corresponding access level.”);
(Chen teaches using access permissions to retrieve and organize enterprise data from an API inquiry DataHub that aggregates multiple systems of record, so that permitted data is prepared for the API response.)
and return, to the data consuming application, at least a portion of data stored in the consolidated data repository. (see Chen, [¶¶0027-0028, 0033]: “Only the data that is designated as accessible for the current permission will be outputted, regardless of whether the request sought information that was outside of that permission scope. In a sixth stage 160, the API service returns its response comprising the relevant data based on a client access permission and input. The API service 270 receives and provides a first response targeted to the customer demographics inquiry that includes customerStatus, customerType, personData, and postAddress, and for the second query 220, the same API service 270 receives and provides a second response targeted to the account list inquiry that includes customerDate, customerType, and accounts, and also for the third query 230, the API service 270 receives and provides a third response targeted to the customer alerts inquiry that includes deliveryChannel, businessFunction, and alerts.”);
(Returning relevant data through the API based on client access permission and outputting only the data is accessible under the current permission.)
It would have been obvious to one of ordinary skill in the art to modify Coffing’s dynamic API authorization system to incorporate Chen’s API inquiry DataHub and cached-reference-table retrieval technique. Coffing already teaches API requests, obtaining user information, and determining the permitted scope of access using user context, dynamic rules machine learning, behavioral baseline services, user authorization levels, user behavioral metrics, and risk-based access decisions. Chen teaches an enterprise API DataHub that aggregates enterprise data and limits returned data based on access permissions. One of the ordinary skill in the art would have been motivated to combine Chen’s enterprise DataHub with Coffing’s authorization system so that authorized API request could be fulfilled by retrieving and returning only permitted portions of enterprise data from a scalable consolidated enterprise data source. The combination would have yielded the predictable benefit of improving API security, scalability, and privacy-controlled enterprise data retrieval.
As to claim 16, Coffing teaches:
wherein the instructions further cause the cause the neuro-symbolic assessment platform to receive, from the API function call, a user identifier and wherein the user information is received based on the user identifier. (see Coffing, [¶¶0027, 0032-0033, 0044, 0046, 0056]: “The client application 210 may be a web application that may be accessible and visible via a web browser. Such a client application 210 may trigger a request (e.g., by a button click). Such request may contain a payload and the access token (e.g., in the request header). The API gateway 130 may authenticate the call and perform authorization, not only checking the scope of authorizations but also invoking all other policies associated with the API. The user device 301 may express intent to access certain information via the client application 210. To access the information, the user may be required to authenticate the identity of the user via the identity provider and authenticator and authenticator 303, such as Okta, OAuth OpenID, FIDO, biometric signatures, and Facebook. The identity provider and authenticator 303 creates, maintains, and manages identity information of users. The identity provider and authenticator 303 may store user credentials, such as login ID and password, and a user profile that includes information relevant to granting access to the user. At step 450, the identity provider and authenticator 303 returns stored user details to the authorization control plane 304. For example, the user detail may include a profile information of the user, user attributes, location of the user, originator of the transaction, and frequency at which the user accesses the desired information. This request includes the enriched token from step 450 and an API call to the particular API, referred to as an API endpoint. As such, the relationship fabric (identity grid) 635 may maintain unique identifiers for each of the users/services/things 605 and may be associated with profile information, such as user names, passwords, contact information, biometric information, user authorization levels, user roles, user behavior metrics, user access history logs.”);
It would have been obvious to one of ordinary skill in the art to use Coffing’s user identification and enriched token teachings in the Coffing-Chen combination because Coffing already uses user identity, user credentials, user profile information, unique identifiers, and enriched tokens to determine whether a user may access requested API data. Using the user identifier to retrieve corresponding user details would have predictably improved the accuracy and security of Coffing’s API authorization process by ensuring that access decisions are based on the correct user context before Chen’s enterprise DataHub returns permitted enterprise data.
As to claim 17, Coffing teaches:
wherein the data consuming application is operational on a third-party computing system external to an enterprise computing network comprising the enterprise computing device. (see Coffing, [¶¶0027, 0030, 0040]: “The client application 210 may be a web application that may be accessible and visible via a web browser. The API gateway 130 may authenticate the call and perform authorization, not only checking the scope of authorizations but also invoking all other policies associated with the API. An exemplary network environment 300 may include a variety of different entities, including a user device 301, a client application 210, an identity provider and authenticator 303, an authorization control plane 304, an API management 305, one or more APIs 306, and an enterprise service 307. Referring to FIG. 3, the enterprise service 307 is an external source of data and may be queried by the authorization control plane 304 to provide the user an access to the data stored in the enterprise service 307.”);
(A client application operating separately from the enterprise service and accessing enterprise data through an API gateway/authorization architecture. Coffing’s web-based client application and separate enterprise service suggest the claimed third-party/external computing arrangement.)
It would have been obvious to one of ordinary skill in the art to configure Coffing’s client application on a computing system external to the enterprise computing network so that outside users or applications could securely request enterprise data through the API gateway while preserving authorization control. Coffing already teaches a web-based client application, public API access, and an enterprise service storing protected data. Such an arrangement would have yielded the predictable benefit of allowing secure external access to enterprise data without exposing the enterprise service directly.
As to claim 18, Coffing teaches:
wherein the user device comprises an internet of things (IoT) device. (see Coffing, [¶¶0031, 0054]: “The user device 301 may be any number of different electronic devices, such as general purpose computers, mobile phones, smartphones, smartwatches, wearable devices, personal digital assistants (“PDAs”), portable computing devices (e.g., laptop, netbook, tablets), desktop computing devices, handheld computing device, smart sensors, smart appliances, loT devices, devices networked to controllers for smart control, servers and server systems (including cloud-based servers and server systems), or any other type of computing device capable of communicating over a communication network. An authorization engine 600 (e.g., Cloudentity TRUST EngineTM) may be executed to evaluate risks in transactions conducted by various users, services, and things (e.g., loT devices) 605.”);
It would have been obvious to one of ordinary skill in the art to use an IoT device as Coffing’s user device because Coffing expressly identifies IoT devices, smart sensors, and smart appliances as examples of user devices capable of requesting access to protected API data. Using such devices would have predictably allowed authorization system to support secure access requests from modern connected devices in the same API-based authorization environment.
As to claim 19, Coffing teaches:
wherein the neuro-symbolic analysis of the user information comprises identifying a user access pattern. (see Coffing, [¶¶0056-0057, 0063]: “The relationship fabric (identity grid) 635 refers to an interwoven collection of discrete identity elements for each user that may be collectively used to track and infuse identity attributes (and rights) throughout the distributed infrastructure. As such, the relationship fabric (identity grid) 635 may maintain unique identifiers for each of the users/services/things 605 and may be associated with profile information, such as user names, passwords, contact information, biometric information, user authorization levels, user roles, user behavior metrics, user access history logs. The user access history logs may also be used to determine access patterns to protected resources by particular users and/or particular devices. The user behavior information may include data representing a plurality of different user behavior metrics, including access patterns. A behavioral baseline may be established with identified patterns and trends that allow for application of machine learning/AI in evaluation of future risk profiles.”);
It would have been obvious to one of ordinary skill in the art to use Coffing’s access-history and behavioral baseline teachings in the Coffing-Chen combination because Coffing already uses user behavior metrics, access history logs, and access patterns to evaluate risk and determine access permissions. Identifying a user access pattern would have predictably improved the accuracy of the access decision before Chen’s enterprise DataHub returns permitted data.
As to claim 20, the combination Coffing in view of Chen teaches:
wherein the instructions cause the neuro-symbolic assessment platform to iteratively build each data object stored in the consolidated data repository. (see Coffing, [¶¶0028-0029, 0035, 0053]: “The proxy may use a security plugin to validate each incoming request and to transform each outgoing request. Outgoing requests may likewise be proxied. The proxy may call the security sidecar 160 to transform an outgoing request. The authorization control plane 304 may also store security policies regarding accessing APIs, store user context received from the identity provider and authenticator 303, store user requests for data from APIs and user consents. User data associated with a user requesting endpoints may be received by the system from the user device 301, the identity provider and authenticator 303, the enterprise service 307, or other database to access the endpoints. Only some portions of this user data may be needed by each microservice. Microservice 5 may have access to Portions D, E, and F of the user data, whereas Microservice 6 may only have access to Portions D and F of the user data. The system may further keep a record of the data lineage regarding where the user data was received from (e.g., identity provider or enterprise service) and which microservices are consuming such user data and display the data lineage in the API management interface.”);
(Coffing teaches receiving data from multiple sources, transforming outgoing requests, storing user context/request information, and controlling which portions of user data are provided to different microservices. Coffing further teaches tracking data lineage showing where the data was received from and which microservices consumed the data.)
It would have been obvious to one of ordinary skill in the art to apply Coffing’s microservice-based data portioning and data-lineage process in the Coffing-Chen combination so that the enterprise data prepared for an authorized API response could be assembled from only the permitted data portions. Coffing already teaches using different microservices to consume different portions of data and tracking the source and consumption of that data. Chen teaches a consolidated enterprise DataHub used to prepare API response data based on access permissions. Combining these teaching would have predictably improved security and efficiency by allowing the system to build authorized response data step by step while preventing unauthorized data portions from being included.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARHAM AHMED whose telephone number is (571)272-8950. The examiner can normally be reached Monday-Friday 7:30 am - 5 pm. Alternate Friday off..
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 at (571) 270-5143. 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.
/A.N.A./Examiner, Art Unit 2437
/ALI S ABYANEH/Primary Examiner, Art Unit 2437
Prosecution Insights