DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
Claims 1-5, 7-12, 14-17, & 19-23 were previously pending in this application. The amendment filed 03 February 2026 has been entered and the following has occurred: Claims 1, 12, & 17 have been amended. No Claims have been added or cancelled.
Claims 1-5, 7-12, 14-17, & 19-23 remain pending in the application.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-5, 7-12, 14-17, & 19-23 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
The claims recite subject matter within a statutory category as a process (claims 1-5 & 7-11), machine (claims 12, 14-16, & 21), and manufacture (claims 17, 19-20, & 22-23) which recite steps of:
parsing, by one or more processors configured for natural language processing (NLP) that is trained to identify predicates, a set of rules into at least a discretionary predicate and a non-discretionary predicate to granting access to the data;
the set of rules comprises a set of non-discretionary rules and a set of discretionary rules, and the parsing comprises:
identifying at least one area for which the set of non-discretionary rules lacks provision;
generating a second discretionary predicate associated with the at least one area based on the lack of provision, wherein
the second discretionary predicate is different than the first discretionary predicate;
determining, by the one or more processors configured for NLP and based at least in part on the set of rules, a hierarchical relationship between the discretionary predicate and the non-discretionary predicate, wherein the hierarchical relationship indicates that the non-discretionary predicate has a higher precedence level than the discretionary predicate;
determining, by the one or more processors and based at least in part on the hierarchical relationship, a restriction to an extent of access to the data permitted by the discretionary predicate;
configuring, by the one or more processors, the discretionary predicate but not the non-discretionary predicate to be modifiable;
generating, by the one or more processors, an access filter based on the hierarchical relationship, the discretionary predicate and the non-discretionary predicate, including:
determining whether the discretionary predicate is in conflict with the non-discretionary predicate;
when the discretionary predicate is not in conflict with the non-discretionary predicate, generating the access filter based on the discretionary predicate and the non-discretionary predicate; and
when the discretionary predicate is in conflict with the non-discretionary predicate, generating the access filter based on the non-discretionary predicate and disregarding the discretionary predicate;
receiving, by the one or more processors and a requesting source, a request to access the data; and
blocking, by the one or more processors, the requesting source from accessing at least a portion of the data based at least in part on the requesting source and the access filter;
receiving, by the one or more processors, a user input for modifying the discretionary predicate;
modifying, by the one or more processors and in response to the user input, the discretionary predicate;
updating, by the one or more processors, the access filter based on the hierarchical relationship, the modified discretionary predicate, and the non-discretionary predicate; and
unblocking, by the one or more processors, the requesting source from accessing at least the portion of the data at least in part on the requesting source and the updated access filter.
These steps of parsing a set of rules into at least a discretionary predicate and a non-discretionary predicate, containing non-discretionary and discretionary rules, identifying an area where the non-discretionary rules lacks provision, generating a second discretionary predicate associated with the area lacking provision, determining a hierarchical relationship between the discretionary predicate and the non-discretionary predicate, determining, based at least in part on the hierarchical relationship, a restriction to an extent of access to the data permitted by the discretionary predicate configuring the discretionary predicate but not the non-discretionary predicate to be modifiable, receiving a user input for modifying the discretionary predicate, modifying the discretionary predicate, generating access filter computer readable program code based on the predicates and conflicts therebetween, and receiving, by the one or more processors and from a second computing device, a request to access the data, and determining to restrict access to the data based at least in part on the access filter, as drafted, under the broadest reasonable interpretation, includes performance of the limitation in the mind but for recitation of generic computer components. That is, other than reciting steps as performed by the generic computer components, nothing in the claim element precludes the step from practically being performed in the mind. For example, but for the receiving discretionary and non-discretionary predicates language, receiving predicates in the context of this claim encompasses a mental process of the user receiving a set of rules that define whether a person should gain access to a document or information, the rules either being modifiable, i.e. discretionary, or non-modifiable, i.e. non-discretionary. For example, but for the determining a hierarchical relationship between the discretionary predicate and the non-discretionary predicate, determining, based at least in part on the hierarchical relationship, a restriction to an extent of access to the data permitted by the discretionary predicate configuring the discretionary predicate but not the non-discretionary predicate to be modifiable, receiving a user input for modifying the discretionary predicate, modifying the discretionary predicate language, configuring the discretionary predicate to be modifiable, receiving user input for modifying said predicate, and modifying the discretionary predicate in the context of this claim encompasses a mental process of determining an initial set of rules/guidelines and relationships of those rules for accessing electronic content according to user input and applying said guidelines/rules. For example, but for the generating access filter computer readable program code based on the modified discretionary predicate and the non-discretionary predicate and controlling electronic access to the data language, generating access filter computer readable program code based on the predicates and conflicts therebetween and controlling electronic access to the data in the context of this claim encompasses a user utilizing a computer as a generic tool to either manually, or by means of the generic computer itself, to implement the modified and static security rules to a database and thereby controlling access to said database. Lastly, blocking the requesting source and/or modifying the discretionary predicates and thereby also updating the generated access filter to unblock the requesting source according to user input/discretion encompasses a mental process of the user determining whether a requesting source should have access to an electronic database based on the rules/guidelines and relationships of those rules for accessing the electronic content. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Dependent claims recite additional subject matter which further narrows or defines the abstract idea embodied in the claims (such as claims 2-5, 7-11, 14-16, & 19-23, reciting particular aspects of how the steps of using varying received information/rules (and relationships thereof) to determine whether a person should have access to a patient’s healthcare information/documentation may be performed in the mind but for recitation of generic computer components).
This judicial exception is not integrated into a practical application. In particular, the additional elements do not integrate the abstract idea into a practical application, other than the abstract idea per se, because the additional elements amount to no more than limitations which:
amount to mere instructions to apply an exception (such as recitation of one or more processors, a memory, a non-transitory computer readable storage medium, NLP, amounts to invoking computers as a tool to perform the abstract idea, see applicant’s specification [0051], [0052], & [0056], [0047], respectively, see MPEP 2106.05(f));
add insignificant extra-solution activity to the abstract idea (such as recitation of parsing/receiving discretionary and non-discretionary predicate/security access rules, receiving user input and receiving generated computer readable program code, receiving, by the one or more processors and from a second computing device, a request to access the data, receiving amounts to mere data gathering; recitation of configuring the discretionary predicate to be modifiable and the non-discretionary predicate to be static, modifying the discretionary predicate according to the received user input, generating computer-readable code according to the predicates, identifying an area where the non-discretionary rules lacks provision, generating a second discretionary predicate associated with the area lacking provision, determining, by the one or more processors configured for NLP and based at least in part on the set of rules, a hierarchical relationship between the discretionary predicate and the non-discretionary predicate, determining, by the one or more processors and based at least in part on the hierarchical relationship, a restriction to an extent of access to the data permitted by the discretionary predicate, determining to restrict access to the data based at least in part on executing the access filter computer readable program code at the one or more processors, determining whether the discretionary predicate is in conflict with the non-discretionary predicate, generating the security access filter based on the predicates and certain conflicts between the predicates, blocking the requesting source and/or modifying the discretionary predicates and thereby also updating the generated access filter to unblock the requesting source according to user input/discretion amounts to selecting a particular data source or type of data to be manipulated; recitation of controlling electronic access to the data, such as by blocking or unblocking the requesting source from access the data amounts to insignificant application, see MPEP 2106.05(g));
generally link the abstract idea to a particular technological environment or field of use (such as discretionary and non-discretionary predicates, recitation of NLP, recitation of controlling electronic access to data, see MPEP 2106.05(h)).
Dependent claims recite additional subject matter which amount to limitations consistent with the additional elements in the independent claims (such as claims 2-5 & 7-11 reciting a computer-implemented method, claims 9, 15, & 20 reciting an application program executable by one or more computer processors, claims 14-16 & 21, reciting a computerized system, claims 19-20 & 22-23, reciting a computer program product/computer readable media, i.e. additional limitations which amount to invoking computers as a tool to perform the abstract idea; claims 2-3, 7-8, 10-11, 14-16, 19-23, which disclose receiving healthcare patient information, generating healthcare information access rules, receiving identification of entities and a permissions-to-access list, receiving input that identifies information access rules, receiving/parsing predicates, or specifying data types such as the discretionary predicate taking precedence over the non-discretionary predicate, i.e. additional limitations which add insignificant extra-solution activity to the abstract idea which amounts to mere data gathering; claims 4-5, 8, 10, 11, 15, & 21-22, which disclose determining whether restrict access to the data based on the access filter and/or the source of the data,, converting information to format compatible with FHIR protocol, generating the first health care information access rules responsive to input from the patient or an agent of the patient, modifying the discretionary predicate to indicate the information type, parsing predicate using a policy language to generate logic expressions, verifying logic expressions, and generating access filter computer readable program code i.e. additional limitations which add insignificant extra-solution activity to the abstract idea by selecting a particular data source or type of data to be manipulated; claims 9, 11, 15-16, & 20-23, which recite specific delegate entities such as a person, business entity, or an application program, the governmental administrative authority comprising a federal government administrative authority and/or state government administrative authority, and utilizing generic parsing or NLP efforts additional limitations which generally link the abstract idea to a particular technological environment or field of use). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation and do not impose a meaningful limit to integrate the abstract idea into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to discussion of integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply an exception, add insignificant extra-solution activity to the abstract idea, and generally link the abstract idea to a particular technological environment or field of use. Additionally, the additional limitations, other than the abstract idea per se, amount to no more than limitations which:
amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields (such parsing/receiving discretionary and non-discretionary predicate/security access rules, receiving user input and receiving generated computer readable program code, receiving, by the one or more processors and from a second computing device, a request to access the data, e.g., receiving or transmitting data over a network, Symantec, MPEP 2106.05(d)(II)(i); configuring the discretionary predicate to be modifiable and the non-discretionary predicate to be static, modifying the discretionary predicate according to the received user input, generating computer-readable code according to the predicates, identifying an area where the non-discretionary rules lacks provision, generating a second discretionary predicate associated with the area lacking provision, determining, by the one or more processors configured for NLP and based at least in part on the set of rules, a hierarchical relationship between the discretionary predicate and the non-discretionary predicate, determining, by the one or more processors and based at least in part on the hierarchical relationship, a restriction to an extent of access to the data permitted by the discretionary predicate, determining to restrict access to the data based at least in part on executing the access filter computer readable program code at the one or more processors, determining whether the discretionary predicate is in conflict with the non-discretionary predicate, generating the security access filter based on the predicates and certain conflicts between the predicates, blocking the requesting source and/or modifying the discretionary predicates and thereby also updating the generated access filter to unblock the requesting source according to user input/discretion, e.g., performing repetitive calculations, Flook, MPEP 2106.05(d)(II)(ii); upkeeping or maintaining one or more rulesets/predicates for creating/maintaining a patient information access filter and/or discretionary predicate according to user input/discretion, maintaining one or more databases of electronic information to be accessed by a requesting source, e.g., electronic recordkeeping, Alice Corp., MPEP 2106.05(d)(II)(iii); storing a patient information access filter, storing one or more rulesets/predicates, storing varying patient information, storing information related to a request and/or requesting source, storing computerized instructions for performing the computerized method, e.g., storing and retrieving information in memory, Versata Dev. Group, MPEP 2106.05(d)(II)(iv); under broadest reasonable interpretation, determining whether to grant a request and controlling electronic access to data based on information could include electronic scanning or extracting of content from an electronic document/set of information, NLP efforts for scanning predicates, e.g., electronic scanning or extracting data from a physical document, Content Extraction, MPEP 2106.05(d)(II)(v); generating subsequent discretionary predicates iteratively based on shortcomings of one or more non-discretionary predicates, e.g. Chandrashekhar Par [0092] & [0101]-[0103] which suggests the well-known nature of an analysis server iteratively removing one or more data elements from the aggregated data and re-processing the remaining set until a satisfactory aggregated set of data elements is found, such that it is understood that iterative discretionary predicates are generated).
Dependent claims recite additional subject matter which, as discussed above with respect to integration of the abstract idea into a practical application, amount to invoking computers as a tool to perform the abstract idea. Dependent claims recite additional subject matter which amount to limitations consistent with the additional elements in the independent claims (such as claims 2-5, 7-11, 14-16, & 19-23, additional limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields; claims 2-3, 7-8, 10-11, 14-16, 19-23, which disclose receiving healthcare patient information, generating healthcare information access rules, receiving identification of entities and a permissions-to-access list, receiving input that identifies information access rules, receiving/parsing predicates, or specifying data types such as the discretionary predicate taking precedence over the non-discretionary predicate, such as over a computer network or computerized storage medium, e.g., receiving or transmitting data over a network, Symantec, MPEP 2106.05(d)(II)(i); claims 4-5, 8, 10, 11, 15, & 21-22, which disclose determining whether restrict access to the data based on the access filter and/or the source of the data, converting information to format compatible with FHIR protocol, generating the first health care information access rules responsive to input from the patient or an agent of the patient, modifying the discretionary predicate to indicate the information type, parsing predicate using a policy language to generate logic expressions, verifying logic expressions, and generating access filter computer readable program code, e.g., performing repetitive calculations, Flook, MPEP 2106.05(d)(II)(ii); claims 4-5, 10, 11, 21 & 22 which recite maintaining/upkeeping an access restriction record generated in response to input from a patient or agent and/or maintain/upkeeping healthcare information access rules, e.g., electronic recordkeeping, Alice Corp., MPEP 2106.05(d)(II)(iii); claims 2-5, 7-11, 14-16, & 19-23,, which disclose storing computerized instructions for performing computerized methods/steps, storing received healthcare patient information, storing received identification of entities and a permissions-to-access list, storing received health care services information associated with a patient, storing inputs that identify information access rules, e.g., storing and retrieving information in memory, Versata Dev. Group, MPEP 2106.05(d)(II)(iv); claims 4-5, 10, 11, 21 & 22, which disclose determining whether to grant access to a user and under broadest reasonable interpretation could include parsing rules/information from electronic documents, converting varying information to format compatible with FHIR protocol which constitutes parsing or scanning through information/data in a document to properly format the information therein and NLP efforts, e.g., electronic scanning or extracting data from a physical document, Content Extraction, MPEP 2106.05(d)(II)(v)). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 7-12, 14-17, & 19-23 are rejected under 35 U.S.C. 103 as being unpatentable over Mynhier et al. (U.S. Patent Publication No. 2016/0210427), hereinafter “Mynhier”, in view of Jain et al. (U.S. Patent Publication No. 2012/0042395), hereinafter “Jain”, further in view of Chandrashekhar et al. (U.S. Patent Publication No. 2021/0165901), hereinafter “Chandrashekhar”.
Claim 1 –
Regarding Claim 1, Mynhier discloses a computer-implemented method for authorizing electronic access to data, the computer-implemented method comprising:
parsing, by one or more processors configured for natural language processing (NLP) that is trained to identify predicates, a set of first rules into at least a discretionary predicate and a non-discretionary predicate (See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a processor; See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a memory, computer readable program code, and storage for computer readable code; “Discretionary and non-discretionary” predicates under broadest reasonable interpretation includes a set of rules that is either up to the discretion, i.e. configurable/modifiable, or not up to the discretion of an entity; therefore, therefore See Mynhier Par [0094]-[0099] which discloses the server determining whether a request for receiving data is granted by accessing each request based on three checks: 1) Regulatory Compliance, i.e. HIPAA and HITRUST™ regulations, understood to read on non-discretionary access rules, i.e. these rules must be met without discretion or modification (i.e. non-discretionary), 2) Security, i.e. the health data server ensures authentication and authorization, and 3) Market Rules, i.e. the health data server implements organization-specific controls that govern data access results (can be modified or configured such as by the configuration file specified in Mynhier Par [0059]); See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by discretion of an entity; While Mynhier seems to disclose discretionary and non-discretionary rules for security access, Mynhier does not seem to explicitly disclose “natural language processing (NLP)” and “predicate” verbiage as they may be understood in view of the prior art, i.e. security rules may be deconstructed or parsed using Natural Language Processing (NLP), which can be trained to identify the variables and predicates in the rules) to granting access to the data, wherein
the set of rules comprises a set of non-discretionary rules and a set of discretionary rules (See Mynhier Par [0153]-[0154] discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set, i.e. discretionary and non-discretionary rules, that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol), and the parsing comprises:
determining, by the one or more processors configured for NLP and based at least in part on the set of rules, a hierarchical relationship between the first discretionary predicate and the non-discretionary predicate (While not performed by one or more processors configured for NLP, Mynhier Par [0153]-[0154] discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol, and further discloses in Mynhier Par [0151]-[0152] that the security module provides a role based dynamic, multi-form authentication such that amount of data access is granted based on said market rules, e.g. in the form of a role-based dynamic, that roles are provided/assigned to users to access certain screens, reports, module, and code pieces dependent on their role and thereby restricting an extent of access/data that can be received based on said role), wherein
the hierarchical relationship indicates the non-discretionary predicate has a higher precedence level than the first discretionary predicate (see Mynhier Par [0153]-[0154] which discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol);
determining, by the one or more processors and based at least in part on the hierarchical relationship, a restriction to an extent of access to the data permitted by the first discretionary predicate (See Mynhier Par [0153]-[0154] which discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol, and further discloses in Mynhier Par [0151]-[0152] that the security module provides a role based dynamic, multi-form authentication such that amount of data access is granted based on said market rules, e.g. in the form of a role-based dynamic, that roles are provided/assigned to users to access certain screens, reports, module, and code pieces dependent on their role and thereby restricting an extent of access/data that can be received based on said role);
configuring, by the one or more processors, the first discretionary predicate but not the non-discretionary predicate to be modifiable (See Mynhier Par [0094]-[0099] which discloses the server determining whether a request for receiving data is granted by accessing each request based on three checks: 1) Regulatory Compliance, i.e. HIPAA and HITRUST™ regulations, understood to read on non-discretionary access rules, i.e. these rules must be met without discretion or modification, 2) Security, i.e. the health data server ensures authentication and authorization, and 3) Market Rules, i.e. the health data server implements organization-specific controls that govern data access results (can be modified or configured such as by the configuration file specified in Mynhier Par [0059]); See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by discretion of an entity; therefore, there are security rules that are configured to be discretionary, i.e. modifiable, and non-discretionary);
generating, by the one or more processors, an access filter based on the hierarchical relationship, the first discretionary predicate and the non-discretionary predicate (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules that are modified or discretionary, and these rules actively being implemented by the system at hand, which is understood to include the generation of access filter computer readable program code; See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a memory, computer readable program code, and storage/generation of computer readable code, and it is understood by Examiner that the electronic access to said data would comprise implementing instructions for access to said data), including:
when the first discretionary predicate is not in conflict with the non-discretionary predicate, generating the access filter based on the first discretionary predicate and the non-discretionary predicate (See Mynhier Par [0094]-[0099] which discloses the server determining whether a request for receiving data is granted by accessing each request based on three checks: 1) Regulatory Compliance, i.e. HIPAA and HITRUST™ regulations, understood to read on non-discretionary access rules, i.e. these rules must be met without discretion or modification, 2) Security, i.e. the health data server ensures authentication and authorization, and 3) Market Rules, i.e. the health data server implements organization-specific controls that govern data access results; See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on controlling electronic access to the data; See Mynhier Par [0059] & [0062] which discloses validating a request for data by a user device, i.e. secondary or remote computing device, such that a rules module that is local to the primary computing system processes and checks if said request is allowed according to data access rules, called market rules; See Mynhier Par [0017]-[0019] which discloses one or more data sources, such as a variety of stakeholders and/or entities, and that each of the one or more data sources or data source devices may have varying consents, access rights, source information at Par [0019]; because these rules are all applied, it is understood by Examiner that this would fit the scenario of the discretionary predicate is not in conflict with the non-discretionary predicate and generating the access filter based on both predicates); and
receiving, by the one or more processors and from a requesting source, a request to access the data (See Mynhier Par [0062] which discloses validating a request for data by a user device, i.e. secondary or remote computing device, such that a rules module that is local to the primary computing system processes and checks if said request is allowed);
blocking, by the one or more processors, the requesting source from accessing at least a portion of the data based at least in part on the requesting source and the access filter (See Mynhier Par [0092]-[0093] which discloses blocking access for certain requests, based on the level of access associated with each request e.g. if the requesting user (or user's organization/role type) has not been granted rights by the original data source or patient who shared that data);
receiving, by the one or more processors, a user input for modifying the first discretionary predicate (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, which is thereby understood to include a received user input for defining the access rules, however Mynhier does not necessarily seem to disclose updating or modifying the discretionary predicate aside from the initial security protocol being defined);
modifying, by the one or more processors and in response to the user input, the first discretionary predicate (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, which is thereby understood to include a received user input for defining the access rules, however Mynhier does not necessarily seem to disclose updating or modifying the discretionary predicate aside from the initial security protocol being defined).
As discussed above, Mynhier seems to disclose the use of discretionary and non-discretionary security protocols/rules, and it should be further noted that Mynhier discloses the use of an NLP engine at Par [0075] & [0115] but does not necessarily disclose “NLP” and “predicate” verbiage as they pertain to the claims above, i.e. security rules and hierarchical relationships therebetween may be deconstructed or parsed using NLP, which can be trained to identify the variables and predicates in the rules. Additionally, Mynhier seems relatively silent on determining whether individual security layers of an SSL protocol conflict with one another and if there are layers in conflict, implementing the non-discretionary layer instead of the discretionary layer. Finally, Mynhier does not seem to disclose updating or modifying the discretionary predicate, such as in an iterative manner, aside from the initial security protocol being defined.
Therefore, Jain discloses training and using NLP efforts to identify security predicates in the rules and determining, by the one or more processors configured for NLP and based at least in part on the set of rules, a hierarchical relationship between the discretionary predicate and the non-discretionary predicate (See Jain Abstract & Par [0011]-[0012] which discloses the use of one or more semantic security labels, e.g. security predicates; See Jain Par [0027]-[0029] which discloses the use of a policy module that comprises defining security and/or access control policy, i.e. code, represented using a policy language having different language constructs; See Jain Par [0030]-[0036] which discloses the use of ontology-based policies (e.g. semantic policies which define security policy elements such as subjects, resources, credentials, and other obligations between ontological elements and further includes security labeling information such as security predicates, constituting the use of language processing efforts to determine predicates in the security rules; See Jain Par [0035] which specifically discloses that a secure ontology may be extracted, such as by NLP as described in [0030], that comprises a plurality of security patterns, including a default security pattern, which may leave no data within the ontology library unclassified and/or without a security label, such that the security label applied to the data within the ontology library may be periodically updated as the security policies of the semantic framework are revised and therefore, a relationship between the policies and framework is determined, and Jain Par [0075] which discloses security labels indicating only certain information available to particular entities, such that particular requesters or roles have access to certain information) determining whether the discretionary predicate is in conflict with the non-discretionary predicate (See Jain Par [0016] which discloses security labels (e.g. security predicates); See Jain Par [0020] which discloses security policy being checked for consistency by the system and may detect direct and inferred conflicts within a security policy and following this, security policy may be automatically modified to remove the direct and/or inferred conflicts); when the discretionary predicate is in conflict with the non-discretionary predicate, generating the access filter based on the non-discretionary predicate and disregarding the discretionary predicate (See Jain Par [0008] further discloses the use of “discretionary access control”, understood to constitute access rules that may or may not be up to the discretion of one or more entities; See Jain Par [0016] which discloses security labels (e.g. security predicates); See Jain Par [0020] which discloses security policy being checked for consistency by the system and may detect direct and inferred conflicts within a security policy and following this, security policy may be automatically modified to remove the direct and/or inferred conflicts; See Jain Par [0018] which, while not “discretionary” and “non-discretionary” per se, discloses security predicates with or policies in violation of one another, e.g. if the existing RDF statement has a higher, i.e. nondiscretionary, level than the inferred RDF statement, discretionary, then a security policy violation may be identified and further specifically discloses in Jain Par [0019] that upon said inferred conflict being identified, the security label of the inferred statement, i.e. discretionary, may be completely subsumed (e.g., replaced) by the original, "higher", i.e. nondiscretionary, security label); updating, by the one or more processors, the access filter based on the hierarchical relationship, the modified discretionary predicate, and the non-discretionary predicate (See Jain Par [0038]-[0041] which discloses the use of a negotiation module for negotiating security and/or access control policy such that multiple iterations or an iterative updating/modification of security rules may be implemented and/or Jain Par [0035] which discloses the security label applied to the data within the ontology library may be periodically updated as the security policies of the semantic framework are revised); and unblocking, by the one or more processors, the requesting source from accessing at least the portion of the data based at least in part on the requesting source and the updated access filter (See Jain Par [0038]-[0041] which discloses the use of a negotiation module for negotiating security and/or access control policy such that multiple iterations or an iterative updating/modification of security rules may be implemented; See Jain Par [0043] which discloses an identification and trust management service to allow the evaluation module and/or other components within the semantic framework to verify (e.g., authenticate) the identity of external, third-party entities (e.g., agent) and/or authentication message transmitted by the entities to determine whether the information sharing arrangement negotiated with the agent should allow access to the requested information; See Jain Par [0058] which discloses a requester may be granted increased access by allowing access to information managed and/or controlled by the requesting entity after the access level of the entity has been modified according to a negotiation process). The disclosure of Jain is directly applicable to the disclosure of Mynhier because both disclosures share limitations and capabilities, such as being directed towards securing/managing access and retrieval to sensitive electronic data found within data stores.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Mynhier which already discloses the use of discretionary and non-discretionary security protocols/rules and the use of an NLP engine to further specifically include training and using NLP efforts to identify security predicates and hierarchical relationships in the security rules/predicates and updating or modifying the discretionary predicate, such as in an iterative manner, as disclosed by Jain. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Mynhier with the teachings from Jain, because by implementing ontology/language-based policies, the policies may define policy elements, such as subjects, resources, credentials, and obligations between particular data elements which can be used by the system to dynamically determine accessibility by users to specific portions of data that are stored (See Jain Par [0030]-[0031]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Mynhier to further include determining whether the discretionary predicate is in conflict with the non-discretionary predicate and when the discretionary predicate is in conflict with the non-discretionary predicate, generating the access filter based on the non-discretionary predicate and disregarding the discretionary predicate because an access filter, i.e. overall security policy, may comprise multiple rules that can conflict one another and in the event of a conflict, the violation needs to be resolved and in that event, the rules with higher precedence/restriction should be applied (See Jain Par [0018]-[0019]). Additionally, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Mynhier to further include updating or modifying the discretionary predicate in an iterative manner allows for negotiation to securely share information with other entities via the network such that the discretionary predicate can allow the system to further dynamically determine accessibility by users to specific portions of data based on updated information, such as an increased trust level between entities that interact with the system over time (See Jain Par [0038]-[0041]).
While Mynhier and Jain generally disclose efforts regarding creating market rules, i.e. discretionary predicates, based on shortcomings of previous market rules and/or other security measures, Mynhier and Jain seem to focus on lack of discretionary predicates instead of non-discretionary predicates, as required by the following limitations:
identifying at least one area for which the set of non-discretionary rules lacks provision; and
generating a second discretionary predicate associated with the at least one area based on the lack of provision, .
Therefore, Chandrashekhar discloses identifying at least one area for which the set of non-discretionary rules lacks provision (See Chandrashekhar Par [0092] which discloses the analysis server iteratively removing one or more data elements from the aggregated data and re-processing the remaining set until a satisfactory aggregated set of data elements is found, such that it is understood that iterative discretionary predicates are generated; See Chandrashekhar Par [0101]-[0103] which provides specific examples of the situation described in Chandrashekhar Par [0092] of a government official requesting information, such that a non-discretionary predicate that defines certain access rules for said government official existing to gather certain eligible information like coverage, names, and the like, but does not cover necessary sensitive data such as data regarding social security numbers, age, marital status, and the like); and generating a second discretionary predicate associated with the at least one area based on the lack of provision (See Chandrashekhar Par [0092] which discloses the analysis server iteratively removing one or more data elements from the aggregated data and re-processing the remaining set until a satisfactory aggregated set of data elements is found, such that it is understood that iterative discretionary predicates are generated; See Chandrashekhar Par [0101]-[0103] which provides specific examples of the situation described in Chandrashekhar Par [0092] of a government official requesting information, such that a non-discretionary predicate that defines certain access rules for said government official existing to gather certain eligible information like coverage, names, and the like, but does not cover necessary sensitive data such as data regarding social security numbers, age, marital status, and the like, such that upon a request from the government official regarding said sensitive data, the system iteratively removes said sensitive data, via the iterative discretionary predicates that are generated in Chandrashekhar Par [0092]). The disclosure of Chandrashekhar is directly applicable to the combined disclosure of Mynhier and Jain, because the disclosures share limitations and capabilities, such as being directed towards maintaining and updating one or more security protocols for access to electronic information.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Mynhier and Jain which already discloses creating discretionary predicates, based on shortcomings of previous market rules and/or other security measures to further specifically include identifying at least one area for which the set of non-discretionary rules lacks provision and generating a second discretionary predicate associated with the at least one area based on the lack of provision, as disclosed by Chandrashekhar, because certain sensitive data, including data regarding social security numbers, age, marital status, and the like can be harmful to individuals, even when accessed by entities with official statuses (See Chandrashekhar Par [0101]-[0103]).
While Chandrashekhar generally discloses that each time the system re-processes whether the data elements pass the discretionary rules, a subsequent discretionary predicate is applied in each processing instance until the discretionary predicate is satisfied (see Chandrashekar Fig. 6, method 600), albeit each of these discretionary predicates may be identical to a previously applied discretionary predicate and does not explicitly delineate said predicates as being unique from one another. Therefore, Mynhier, Jain, and Chandrashekhar are relatively silent on:
the second discretionary predicate is different than the first discretionary predicate
However, Cummins discloses the second discretionary predicate is different than the first discretionary predicate (See Cummins Par [0055]-[0062] & [0065]which discloses configurable, i.e. discretionary, predicates that can be configured to enable a user to modifying one or more firewall configuration parameters for any of the rings that represent said access policies; See Cummins Par [0068]-[0070] which discloses certain firewall configurations and may include one or more rules represented visually as concentric rings, such that each of the rings represent one or more rules/parameters defining an access policy, and concentric rings representing one or more security layers stacked on top of each other, constituting two or more discretionary predicates that are modifiable, and different from one another). The disclosure of Cummins is directly applicable to the disclosures of Mynhier, Jain, and Chandrashekhar because the disclosures share limitations and capabilities, such as all being directed towards maintaining and updating one or more security protocols for access to electronic information.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Mynhier, Jain, and Chandrashekhar which already discloses iteratively changing a discretionary predicate, such that the second discretionary predicate is different than the first discretionary predicate, as disclosed by Cummins, because this allows for users to change one or more security layers with varying rules, i.e. different from one another, to delete or modify one or more firewall configuration parameters so as to further or no longer limit traffic to or from certain nodes/based on certain rules/parameters (See Cummins Par [0061]-[0062]).
Claim 2 –
Regarding Claim 2, Mynhier, Jain, Chandrashekhar, and Cummins disclose the computer-implemented method of Claim 1 in its entirety. Mynhier further discloses a method, wherein:
data comprises at least one of claim information, encounter information, clinical information, pharmacy information, formulary information, and wearable information (See Mynhier Par [0017] & [0114] which discloses varying data sources for acquiring information/data to the health data system, including electronic medical records (EMR), lab data, health insurers/payers including claims record data, i.e. claim information, for associated medical services, pharmaceutical and medical device companies including data associated with clinical trials and/or adverse event, research, government/community health programs, and/or individual patients for biometric and/or activity/behavior data, i.e. clinical information; See Mynhier Par [0186] which discloses the patient data including patient’s medical data, lab results, radiology images and reports, i.e. encounter information, prescription data, i.e. pharmacy/formulary information, and wearable device information).
Claim 3 –
Regarding Claim 3, Mynhier, Jain, Chandrashekhar, and Cummins disclose the computer-implemented method of Claim 2 in its entirety. Mynhier further discloses a method, wherein:
the claim information comprises claim information associated with a current payor for a patient and a former payor for the patient (See Mynhier Par [0017], [0089], [0102]-[0103], & [0109] which discloses data sources including health insurers/payers such as claim records, i.e. records are understood to include both current and former payers for the patient).
Claim 4 –
Regarding Claim 4, Mynhier, Jain, Chandrashekhar, and Cummins disclose the computer-implemented method of Claim 1 in its entirety. Mynhier further discloses a method, wherein:
blocking the requesting source from accessing at least a portion of the data is further based on a source of the data (See Mynhier Par [0092]-[0093] which discloses blocking access for certain requests, based on the level of access associated with each request e.g. if the requesting user (or user's organization/role type) has not been granted rights by the original data source or patient who shared that data, i.e. the source of the data).
Claim 5 –
Regarding Claim 5, Mynhier, Jain, Chandrashekhar, and Cummins disclose the computer-implemented method of Claim 1 in its entirety. Mynhier further discloses a method, further comprising:
converting, by one or more processors data into a format compatible with Fast Healthcare Interoperability Resource (FHIR) protocol (See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a processor; See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a memory, computer readable program code, and storage for computer readable code; See Mynhier Par [0085] which discloses the common information standardizing information in accordance with terminologically robust standards such as Fast Healthcare Interoperability Resources (FHIR), and other varying standards recited).
Claim 7 –
Regarding Claim 7, Mynhier, Jain, Chandrashekhar, and Cummins disclose the computer-implemented method of Claim 1 in its entirety. Mynhier further discloses a method, wherein modifying the first discretionary predicate comprises:
receiving, by one or more processors, an identification of a delegate entity (See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a processor; See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a memory, computer readable program code, and storage for computer readable code; See Mynhier Par [0093] which discloses only certain users being able to see identifiable data, while all others may only receive access to identified versions or subsets of the organization’s data depending on the nature of the access restriction); and
receiving, by the one or more processors, a set of the data of the delegate entity is permitted to access (See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a processor; See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a memory, computer readable program code, and storage for computer readable code; See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by a patient or stakeholder; See Mynhier Par [0093] which discloses only certain users being able to see identifiable data, while all others may only receive access to identified versions or subsets of the organization’s data depending on the nature of the access restriction; See Mynhier Par [0098] which discloses the patient request that specific parties only can see their data).
Claim 8 –
Regarding Claim 8, Mynhier, Jain, Chandrashekhar, and Cummins disclose the computer-implemented method of Claim 7 in its entirety. Mynhier further discloses a method, wherein modifying the first discretionary predicate comprises:
generating the first health care information access rules further comprises:
receiving, by the one or more processors, input indicating an information type associated with the data (See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a processor; See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a memory, computer readable program code, and storage for computer readable code; See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by a patient or stakeholder; See Mynhier Par [0093] which discloses only certain users being able to see identifiable data, while all others may only receive access to identified versions or subsets of the organization’s data depending on the nature of the access restriction); and
modifying, by the one or more processors, the first discretionary predicate to indicate the information type (See Mynhier Par [0017]-[0019] which discloses one or more data sources, such as a variety of stakeholders and/or entities, and that each of the one or more data sources or data source devices can be associated with or be the source of any type of data such as data from healthcare providers (e.g., data can be electronic medical records, lab data), health insurers/payers (e.g., data can be claims records), pharmaceutical and medical device companies (e.g., data can be clinical trial records, adverse event data), research (e.g., data can be a genomic profile), government/community health programs (e.g., data can be population health statistics) partnership databases), and/or individual patients (e.g., data can be biometrics, activity/behavior, and each of these data types or data sources may have varying consents, access rights, source information as specified at Mynhier Par [0019]).
Claim 9 –
Regarding Claim 9, Mynhier, Jain, Chandrashekhar, and Cummins disclose disclose the computer-implemented method of Claim 7 in its entirety. Mynhier further discloses a method, wherein:
the delegate entity comprises a person, a business entity, or an application program executable by a computer processor (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by a patient or stakeholder; See Mynhier Par [0093] which discloses only certain users being able to see identifiable data, while all others may only receive access to identified versions or subsets of the organization’s, i.e. business entity, data depending on the nature of the access restriction).
Claim 10 –
Regarding Claim 10, Mynhier, Jain, Chandrashekhar, and Cummins disclose the computer-implemented method of Claim 1 in its entirety. Mynhier further discloses a method, wherein:
the non-discretionary predicate takes precedence over the first discretionary predicate (See Mynhier Par [0094]-[0097] the server determining whether a request for receiving data is granted by accessing each request based on three security checks: 1) Regulatory Compliance, i.e. HIPAA and HITRUST™ regulations, understood to read on non-discretionary access rules, rules and regulations set by the federal government and/or state government, respectively; See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by a patient; See Mynhier Par [0151] & [0153]-[0157] which discloses a pre-established security tunnel, that which utilizes a combination of multiple rules/layers sitting on top of baseline SSL protocols such that, different layers of security and access control must be satisfied to gain access to the information, and while Mynhier does not explicitly state that the first or second health care information access rules have priority level/layer over one another, it is understood that if the system described in Mynhier placed a second health care information layer, i.e. government regulation, before the first health care information access rules layer, i.e. patient-defined regulation, then the second heath care information would, in fact, take priority since each preceding layer has to be satisfied before moving to the next; Therefore, see MPEP 2144.05(II)(A) which describes optimization within prior art conditions or through routine experimentation, such that when the general conditions of a claim are disclosed in the prior art, generally it is not inventive to discover the optimum or workable ranges by routine experimentation; As such, because Mynhier discloses the first and second health care information access rules and each security layer needing to be satisfied before moving to the next, the general conditions of the claim are disclosed and placing priority on the first and/or second health care information access rule/layer constitutes optimization within prior art conditions or through routine experimentation) with respect to the granting of access to the data based on the non-discretionary predicate indicating a more restrictive predicate than the first discretionary predicate (See Mynhier Par [0153]-[0154] which discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol, and further discloses in Mynhier Par [0151]-[0152] that the security module provides a role based dynamic, multi-form authentication such that amount of data access is granted based on said market rules, e.g. in the form of a role-based dynamic, that roles are provided/assigned to users to access certain screens, reports, module, and code pieces dependent on their role and thereby restricting an extent of access/data that can be received based on said role; See MPEP 2144.05(II)(A) which describes optimization within prior art conditions or through routine experimentation, such that when the general conditions of a claim are disclosed in the prior art, generally it is not inventive to discover the optimum or workable ranges by routine experimentation; As such, because Mynhier discloses the first and second health care information access rules and each security layer needing to be satisfied before moving to the next, the general conditions of the claim are disclosed and placing priority on the first and/or second health care information access rule/layer constitutes optimization within prior art conditions or through routine experimentation, such that one predicate is more restrictive than the discretionary predicate); or
Claim 11 –
Regarding Claim 11, Mynhier, Jain, Chandrashekhar, and Cummins disclose the computer-method of Claim 10 in its entirety. Jain further discloses a method, wherein:
parsing, by the one or more processors, the first discretionary predicate and the non-discretionary predicate using a policy logic language to generate logic expressions for the first discretionary predicate and the non-discretionary predicate, respectively (See Jain Abstract & Par [0011]-[0012] which discloses the use of one or more semantic security labels, e.g. security predicates; See Jain Par [0027]-[0029] which discloses the use of a policy module that comprises defining security and/or access control policy, i.e. code, represented using a policy language having different language constructs; See Jain Par [0030]-[0036] which discloses the use of ontology-based policies (e.g. semantic policies which define security policy elements such as subjects, resources, credentials, and other obligations between ontological elements and further includes security labeling information such as security predicates, constituting the use of language processing efforts to determine predicates in the security rules);
verifying, by the one or more processors and the policy logic language, that the logic expressions accurately represent logic in the modified discretionary predicate and the non-discretionary predicate, respectively (See Jain Par [0016]-[0020] which discloses the system being able to determine or check for conflicting security labels/policies and associated mappings such); and
wherein generating the access filter comprises generating, using the one or more processors, the access filter based on the logic expressions (See Jain Par [0016]-[0020] which discloses the system being able to determine or check for conflicting security labels/policies and associated mappings such ; See Jain Par [0027]-[0029] which discloses the use of a policy module that comprises defining security and/or access control policy following determination/elimination of any conflicting security policies, i.e. code, represented using a policy language having different language constructs; See Jain Par [0030]-[0036] which discloses the use of ontology-based policies (e.g. semantic policies which define security policy elements such as subjects, resources, credentials, and other obligations between ontological elements and further includes security labeling information such as security predicates, constituting the use of language processing efforts to determine predicates in the security rules).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the combined disclosure of Mynhier, Jain, and Chandrashekhar to further include verifying, by the one or more processors and the policy logic language, that the logic expressions accurately represent the logic in the modified discretionary predicate and the non-discretionary predicate, as disclosed by Jain, because sometimes multiple security patterns, labels, etc., may conflict one another and lead to violations of the multiple security policies involved, so checking and resolving these conflicts allows for eliminating said violations (See Jain Par [0016]-[0020]).
Claim 12 –
Regarding Claim 12 Mynhier discloses a system for authorizing electronic access to data, comprising:
one or more processors (See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain one or more processors); and
at least one memory storing processor-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising (See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain one or more processors, a memory, computer readable program code, and storage for computer readable code) comprising:
parsing, by natural language processing (NLP) that is trained to identify predicates, a set of rules into at least a discretionary predicate and a non-discretionary predicate (See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a processor; See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a memory, computer readable program code, and storage for computer readable code; “Discretionary and non-discretionary” predicates under broadest reasonable interpretation includes a set of rules that is either up to the discretion, i.e. configurable/modifiable, or not up to the discretion of an entity; therefore, therefore See Mynhier Par [0094]-[0099] which discloses the server determining whether a request for receiving data is granted by accessing each request based on three checks: 1) Regulatory Compliance, i.e. HIPAA and HITRUST™ regulations, understood to read on non-discretionary access rules, i.e. these rules must be met without discretion or modification, 2) Security, i.e. the health data server ensures authentication and authorization, and 3) Market Rules, i.e. the health data server implements organization-specific controls that govern data access results; See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by discretion of an entity; While Mynhier seems to disclose discretionary and non-discretionary rules for security access, Mynhier does not seem to explicitly disclose “natural language processing (NLP)” and “predicate” verbiage as they may be understood in view of the prior art, i.e. security rules may be deconstructed or parsed using Natural Language Processing (NLP), which can be trained to identify the variables and predicates in the rules) to granting access to the data, wherein
the set of rules comprises a set of non-discretionary rules and a set of discretionary rules (See Mynhier Par [0153]-[0154] discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set, i.e. discretionary and non-discretionary rules, that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol), and the parsing comprises:
determining, by NLP and based at least in part on the set of rules, a hierarchical relationship between the first discretionary predicate and the non-discretionary predicate (While not performed by one or more processors configured for NLP, Mynhier Par [0153]-[0154] discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol, and further discloses in Mynhier Par [0151]-[0152] that the security module provides a role based dynamic, multi-form authentication such that amount of data access is granted based on said market rules, e.g. in the form of a role-based dynamic, that roles are provided/assigned to users to access certain screens, reports, module, and code pieces dependent on their role and thereby restricting an extent of access/data that can be received based on said role), wherein
the hierarchical relationship indicates that the non-discretionary predicate has a higher precedence level than the first discretionary predicate (see Mynhier Par [0153]-[0154] which discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol);
determining, based at least in part on the hierarchical relationship, a restriction to an extent of access to the data permitted by the first discretionary predicate (See Mynhier Par [0153]-[0154] which discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol, and further discloses in Mynhier Par [0151]-[0152] that the security module provides a role based dynamic, multi-form authentication such that amount of data access is granted based on said market rules, e.g. in the form of a role-based dynamic, that roles are provided/assigned to users to access certain screens, reports, module, and code pieces dependent on their role and thereby restricting an extent of access/data that can be received based on said role);
configuring the first discretionary predicate but not the non-discretionary predicate to be modifiable (See Mynhier Par [0094]-[0099] which discloses the server determining whether a request for receiving data is granted by accessing each request based on three checks: 1) Regulatory Compliance, i.e. HIPAA and HITRUST™ regulations, understood to read on non-discretionary access rules, i.e. these rules must be met without discretion or modification, 2) Security, i.e. the health data server ensures authentication and authorization, and 3) Market Rules, i.e. the health data server implements organization-specific controls that govern data access results; See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by discretion of an entity; therefore, there are security rules that are configured to be discretionary, i.e. modifiable, and non-discretionary);
generating an access filter based on the hierarchical relationship, the first discretionary predicate and the non-discretionary predicate (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules that are modified or discretionary, and these rules actively being implemented by the system at hand, which is understood to include the generation of access filter computer readable program code; See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a memory, computer readable program code, and storage/generation of computer readable code, and it is understood by Examiner that the electronic access to said data would comprise implementing instructions for access to said data), including:
when the first discretionary predicate is not in conflict with the non-discretionary predicate, generating the access filter based on the first discretionary predicate and the non-discretionary predicate (See Mynhier Par [0094]-[0099] which discloses the server determining whether a request for receiving data is granted by accessing each request based on three checks: 1) Regulatory Compliance, i.e. HIPAA and HITRUST™ regulations, understood to read on non-discretionary access rules, i.e. these rules must be met without discretion or modification, 2) Security, i.e. the health data server ensures authentication and authorization, and 3) Market Rules, i.e. the health data server implements organization-specific controls that govern data access results; See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on controlling electronic access to the data; See Mynhier Par [0059] & [0062] which discloses validating a request for data by a user device, i.e. secondary or remote computing device, such that a rules module that is local to the primary computing system processes and checks if said request is allowed according to data access rules, called market rules; See Mynhier Par [0017]-[0019] which discloses one or more data sources, such as a variety of stakeholders and/or entities, and that each of the one or more data sources or data source devices may have varying consents, access rights, source information at Par [0019]; because these rules are all applied, it is understood by Examiner that this would fit the scenario of the discretionary predicate is not in conflict with the non-discretionary predicate and generating the access filter based on both predicates); and
receiving from a requesting source, a request to access the data (See Mynhier Par [0062] which discloses validating a request for data by a user device, i.e. secondary or remote computing device, such that a rules module that is local to the primary computing system processes and checks if said request is allowed); and
blocking the requesting source from accessing at least a portion of the data based at least in part on the requesting source and the access filter (See Mynhier Par [0092]-[0093] which discloses blocking access for certain requests, based on the level of access associated with each request e.g. if the requesting user (or user's organization/role type) has not been granted rights by the original data source or patient who shared that data);
receiving a user input for modifying the first discretionary predicate (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, which is thereby understood to include a received user input for defining the access rules, however Mynhier does not necessarily seem to disclose updating or modifying the discretionary predicate aside from the initial security protocol being defined);
modifying, in response to the user input, the first discretionary predicate (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, which is thereby understood to include a received user input for defining the access rules, however Mynhier does not necessarily seem to disclose updating or modifying the discretionary predicate aside from the initial security protocol being defined).
As discussed above, Mynhier seems to disclose the use of discretionary and non-discretionary security protocols/rules, and it should be further noted that Mynhier discloses the use of an NLP engine at Par [0075] & [0115] but does not necessarily disclose “NLP” and “predicate” verbiage as they pertain to the claims above, i.e. security rules and hierarchical relationships therebetween may be deconstructed or parsed using NLP, which can be trained to identify the variables and predicates in the rules. Additionally, Mynhier seems relatively silent on determining whether individual security layers of an SSL protocol conflict with one another and if there are layers in conflict, implementing the non-discretionary layer instead of the discretionary layer. Finally, Mynhier does not seem to disclose updating or modifying the discretionary predicate, such as in an iterative manner, aside from the initial security protocol being defined.
Therefore, Jain discloses training and using NLP efforts to identify security predicates in the rules and determining, by the one or more processors configured for NLP and based at least in part on the set of rules, a hierarchical relationship between the discretionary predicate and the non-discretionary predicate (See Jain Abstract & Par [0011]-[0012] which discloses the use of one or more semantic security labels, e.g. security predicates; See Jain Par [0027]-[0029] which discloses the use of a policy module that comprises defining security and/or access control policy, i.e. code, represented using a policy language having different language constructs; See Jain Par [0030]-[0036] which discloses the use of ontology-based policies (e.g. semantic policies which define security policy elements such as subjects, resources, credentials, and other obligations between ontological elements and further includes security labeling information such as security predicates, constituting the use of language processing efforts to determine predicates in the security rules; See Jain Par [0035] which specifically discloses that a secure ontology may be extracted, such as by NLP as described in [0030], that comprises a plurality of security patterns, including a default security pattern, which may leave no data within the ontology library unclassified and/or without a security label, such that the security label applied to the data within the ontology library may be periodically updated as the security policies of the semantic framework are revised and therefore, a relationship between the policies and framework is determined, and Jain Par [0075] which discloses security labels indicating only certain information available to particular entities, such that particular requesters or roles have access to certain information) determining whether the discretionary predicate is in conflict with the non-discretionary predicate (See Jain Par [0016] which discloses security labels (e.g. security predicates); See Jain Par [0020] which discloses security policy being checked for consistency by the system and may detect direct and inferred conflicts within a security policy and following this, security policy may be automatically modified to remove the direct and/or inferred conflicts); when the discretionary predicate is in conflict with the non-discretionary predicate, generating the access filter based on the non-discretionary predicate and disregarding the discretionary predicate (See Jain Par [0008] further discloses the use of “discretionary access control”, understood to constitute access rules that may or may not be up to the discretion of one or more entities; See Jain Par [0016] which discloses security labels (e.g. security predicates); See Jain Par [0020] which discloses security policy being checked for consistency by the system and may detect direct and inferred conflicts within a security policy and following this, security policy may be automatically modified to remove the direct and/or inferred conflicts; See Jain Par [0018] which, while not “discretionary” and “non-discretionary” per se, discloses security predicates with or policies in violation of one another, e.g. if the existing RDF statement has a higher, i.e. nondiscretionary, level than the inferred RDF statement, discretionary, then a security policy violation may be identified and further specifically discloses in Jain Par [0019] that upon said inferred conflict being identified, the security label of the inferred statement, i.e. discretionary, may be completely subsumed (e.g., replaced) by the original, "higher", i.e. nondiscretionary, security label); updating, by the one or more processors, the access filter based on the hierarchical relationship, the modified discretionary predicate, and the non-discretionary predicate (See Jain Par [0038]-[0041] which discloses the use of a negotiation module for negotiating security and/or access control policy such that multiple iterations or an iterative updating/modification of security rules may be implemented and/or Jain Par [0035] which discloses the security label applied to the data within the ontology library may be periodically updated as the security policies of the semantic framework are revised); and unblocking, by the one or more processors, the requesting source from accessing at least the portion of the data based at least in part on the requesting source and the updated access filter (See Jain Par [0038]-[0041] which discloses the use of a negotiation module for negotiating security and/or access control policy such that multiple iterations or an iterative updating/modification of security rules may be implemented; See Jain Par [0043] which discloses an identification and trust management service to allow the evaluation module and/or other components within the semantic framework to verify (e.g., authenticate) the identity of external, third-party entities (e.g., agent) and/or authentication message transmitted by the entities to determine whether the information sharing arrangement negotiated with the agent should allow access to the requested information; See Jain Par [0058] which discloses a requester may be granted increased access by allowing access to information managed and/or controlled by the requesting entity after the access level of the entity has been modified according to a negotiation process).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Mynhier which already discloses the use of discretionary and non-discretionary security protocols/rules and the use of an NLP engine to further specifically include training and using NLP efforts to identify security predicates and hierarchical relationships in the security rules/predicates and updating or modifying the discretionary predicate, such as in an iterative manner, as disclosed by Jain. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Mynhier with the teachings from Jain, because by implementing ontology/language-based policies, the policies may define policy elements, such as subjects, resources, credentials, and obligations between particular data elements which can be used by the system to dynamically determine accessibility by users to specific portions of data that are stored (See Jain Par [0030]-[0031]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Mynhier to further include determining whether the discretionary predicate is in conflict with the non-discretionary predicate and when the discretionary predicate is in conflict with the non-discretionary predicate, generating the access filter based on the non-discretionary predicate and disregarding the discretionary predicate because an access filter, i.e. overall security policy, may comprise multiple rules that can conflict one another and in the event of a conflict, the violation needs to be resolved and in that event, the rules with higher precedence/restriction should be applied (See Jain Par [0018]-[0019]). Additionally, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Mynhier to further include updating or modifying the discretionary predicate in an iterative manner allows for negotiation to securely share information with other entities via the network such that the discretionary predicate can allow the system to further dynamically determine accessibility by users to specific portions of data based on updated information, such as an increased trust level between entities that interact with the system over time (See Jain Par [0038]-[0041]).
While Mynhier and Jain generally disclose efforts regarding creating market rules, i.e. discretionary predicates, based on shortcomings of previous market rules and/or other security measures, Mynhier and Jain seem to focus on lack of discretionary predicates instead of non-discretionary predicates, as required by the following limitations:
identifying at least one area for which the set of non-discretionary rules lacks provision; and
generating a second discretionary predicate associated with the at least one area based on the lack of provision.
Therefore, Chandrashekhar discloses identifying at least one area for which the set of non-discretionary rules lacks provision (See Chandrashekhar Par [0092] which discloses the analysis server iteratively removing one or more data elements from the aggregated data and re-processing the remaining set until a satisfactory aggregated set of data elements is found, such that it is understood that iterative discretionary predicates are generated; See Chandrashekhar Par [0101]-[0103] which provides specific examples of the situation described in Chandrashekhar Par [0092] of a government official requesting information, such that a non-discretionary predicate that defines certain access rules for said government official existing to gather certain eligible information like coverage, names, and the like, but does not cover necessary sensitive data such as data regarding social security numbers, age, marital status, and the like); and generating a second discretionary predicate associated with the at least one area based on the lack of provision (See Chandrashekhar Par [0092] which discloses the analysis server iteratively removing one or more data elements from the aggregated data and re-processing the remaining set until a satisfactory aggregated set of data elements is found, such that it is understood that iterative discretionary predicates are generated; See Chandrashekhar Par [0101]-[0103] which provides specific examples of the situation described in Chandrashekhar Par [0092] of a government official requesting information, such that a non-discretionary predicate that defines certain access rules for said government official existing to gather certain eligible information like coverage, names, and the like, but does not cover necessary sensitive data such as data regarding social security numbers, age, marital status, and the like, such that upon a request from the government official regarding said sensitive data, the system iteratively removes said sensitive data, via the iterative discretionary predicates that are generated in Chandrashekhar Par [0092]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Mynhier and Jain which already discloses creating discretionary predicates, based on shortcomings of previous market rules and/or other security measures to further specifically include identifying at least one area for which the set of non-discretionary rules lacks provision and generating a second discretionary predicate associated with the at least one area based on the lack of provision, as disclosed by Chandrashekhar, because certain sensitive data, including data regarding social security numbers, age, marital status, and the like can be harmful to individuals, even when accessed by entities with official statuses (See Chandrashekhar Par [0101]-[0103]).
Claim 14 –
Regarding Claim 14, Mynhier, Jain, Chandrashekhar, and Cummins disclose the system of Claim 12 in its entirety. Mynhier further discloses a system, wherein:
modifying the first discretionary predicate comprises:
receiving an identification of a delegate entity (See Mynhier Par [0093] which discloses only certain users being able to see identifiable data, while all others may only receive access to identified versions or subsets of the organization’s data depending on the nature of the access restriction); and
receiving a set of the data the delegate entity is permitted to access (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by a patient or stakeholder; See Mynhier Par [0093] which discloses only certain users being able to see identifiable data, while all others may only receive access to identified versions or subsets of the organization’s data depending on the nature of the access restriction; See Mynhier Par [0098] which discloses the patient request that specific parties only can see their data).
Claim 15 –
Regarding Claim 15, Mynhier, Jain, Chandrashekhar, and Cummins disclose the system of Claim 14 in its entirety. Mynhier further discloses a system, wherein:
modifying the first discretionary predicate further comprises:
receiving input indicating an information type associated with the data (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by a patient or stakeholder; See Mynhier Par [0093] which discloses only certain users being able to see identifiable data, while all others may only receive access to identified versions or subsets of the organization’s data depending on the nature of the access restriction); and
modifying the first discretionary predicate to indicate the information type (See Mynhier Par [0017]-[0019] which discloses one or more data sources, such as a variety of stakeholders and/or entities, and that each of the one or more data sources or data source devices can be associated with or be the source of any type of data such as data from healthcare providers (e.g., data can be electronic medical records, lab data), health insurers/payers (e.g., data can be claims records), pharmaceutical and medical device companies (e.g., data can be clinical trial records, adverse event data), research (e.g., data can be a genomic profile), government/community health programs (e.g., data can be population health statistics) partnership databases), and/or individual patients (e.g., data can be biometrics, activity/behavior, and each of these data types or data sources may have varying consents, access rights, source information as specified at Mynhier Par [0019]); wherein
the delegate entity comprises a person, a business entity, or an application program executable by a computer processor (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by a patient or stakeholder; See Mynhier Par [0093] which discloses only certain users being able to see identifiable data, while all others may only receive access to identified versions or subsets of the organization’s, i.e. business entity, data depending on the nature of the access restriction).
Claim 16 –
Regarding Claim 16, Mynhier, Jain, Chandrashekhar, and Cummins disclose the system of Claim 12 in its entirety. Mynhier further discloses a system, wherein:
the non-discretionary predicate takes precedence over the first discretionary predicate (See Mynhier Par [0094]-[0097] the server determining whether a request for receiving data is granted by accessing each request based on three security checks: 1) Regulatory Compliance, i.e. HIPAA and HITRUST™ regulations, understood to read on non-discretionary access rules, rules and regulations set by the federal government and/or state government, respectively; See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by a patient; See Mynhier Par [0151] & [0153]-[0157] which discloses a pre-established security tunnel, that which utilizes a combination of multiple rules/layers sitting on top of baseline SSL protocols such that, different layers of security and access control must be satisfied to gain access to the information, and while Mynhier does not explicitly state that the first or second health care information access rules have priority level/layer over one another, it is understood that if the system described in Mynhier placed a second health care information layer, i.e. government regulation, before the first health care information access rules layer, i.e. patient-defined regulation, then the second heath care information would, in fact, take priority since each preceding layer has to be satisfied before moving to the next; Therefore, see MPEP 2144.05(II)(A) which describes optimization within prior art conditions or through routine experimentation, such that when the general conditions of a claim are disclosed in the prior art, generally it is not inventive to discover the optimum or workable ranges by routine experimentation; As such, because Mynhier discloses the first and second health care information access rules and each security layer needing to be satisfied before moving to the next, the general conditions of the claim are disclosed and placing priority on the first and/or second health care information access rule/layer constitutes optimization within prior art conditions or through routine experimentation) with respect to the granting access to the data based on the non-discretionary predicate indicating a first more restrictive predicate than the first discretionary predicate (See Mynhier Par [0153]-[0154] which discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol, and further discloses in Mynhier Par [0151]-[0152] that the security module provides a role based dynamic, multi-form authentication such that amount of data access is granted based on said market rules, e.g. in the form of a role-based dynamic, that roles are provided/assigned to users to access certain screens, reports, module, and code pieces dependent on their role and thereby restricting an extent of access/data that can be received based on said role; See MPEP 2144.05(II)(A) which describes optimization within prior art conditions or through routine experimentation, such that when the general conditions of a claim are disclosed in the prior art, generally it is not inventive to discover the optimum or workable ranges by routine experimentation; As such, because Mynhier discloses the first and second health care information access rules and each security layer needing to be satisfied before moving to the next, the general conditions of the claim are disclosed and placing priority on the first and/or second health care information access rule/layer constitutes optimization within prior art conditions or through routine experimentation, such that one predicate is more restrictive than the discretionary predicate).
Claim 17 –
Regarding Claim 17, Mynhier discloses one or more non- transitory computer-readable media for authorizing electronic access to data, the one or more non-transitory computer-readable media storing processor-executable instructions that, when executed by one or more processors, cause the one or more processors to perform operations (See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain one or more processors, a non-transitory computer readable storage medium/memory, and/or computer readable program code) comprising:
parsing by natural language processing (NLP) that is trained to identify predicates, a set of rules into at least a first discretionary predicate and a non-discretionary predicate (See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a processor; See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a memory, computer readable program code, and storage for computer readable code; “Discretionary and non-discretionary” predicates under broadest reasonable interpretation includes a set of rules that is either up to the discretion, i.e. configurable/modifiable, or not up to the discretion of an entity; therefore, therefore See Mynhier Par [0094]-[0099] which discloses the server determining whether a request for receiving data is granted by accessing each request based on three checks: 1) Regulatory Compliance, i.e. HIPAA and HITRUST™ regulations, understood to read on non-discretionary access rules, i.e. these rules must be met without discretion or modification, 2) Security, i.e. the health data server ensures authentication and authorization, and 3) Market Rules, i.e. the health data server implements organization-specific controls that govern data access results; See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by discretion of an entity; While Mynhier seems to disclose discretionary and non-discretionary rules for security access, Mynhier does not seem to explicitly disclose “natural language processing (NLP)” and “predicate” verbiage as they may be understood in view of the prior art, i.e. security rules may be deconstructed or parsed using Natural Language Processing (NLP), which can be trained to identify the variables and predicates in the rules) to granting access to the data,
wherein the set of rules comprises a set of non-discretionary rules and discretionary rules (See Mynhier Par [0153]-[0154] discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set, i.e. discretionary and non-discretionary rules, that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol), and the parsing comprises:
determining, by NLP and based at least in part on the set of rules, a hierarchical relationship between the first discretionary predicate and the non-discretionary predicate (While not performed by one or more processors configured for NLP, Mynhier Par [0153]-[0154] discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol, and further discloses in Mynhier Par [0151]-[0152] that the security module provides a role based dynamic, multi-form authentication such that amount of data access is granted based on said market rules, e.g. in the form of a role-based dynamic, that roles are provided/assigned to users to access certain screens, reports, module, and code pieces dependent on their role and thereby restricting an extent of access/data that can be received based on said role), wherein
the hierarchical relationship indicates that the non-discretionary predicate has a higher precedence level than the first discretionary predicate (see Mynhier Par [0153]-[0154] which discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol);
determining, based at least in part on the hierarchical relationship, a restriction to an extent of access to the data permitted by the first discretionary predicate (See Mynhier Par [0153]-[0154] which discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol, and further discloses in Mynhier Par [0151]-[0152] that the security module provides a role based dynamic, multi-form authentication such that amount of data access is granted based on said market rules, e.g. in the form of a role-based dynamic, that roles are provided/assigned to users to access certain screens, reports, module, and code pieces dependent on their role and thereby restricting an extent of access/data that can be received based on said role);
configuring the first discretionary predicate but not the non-discretionary predicate to be modifiable (See Mynhier Par [0094]-[0099] which discloses the server determining whether a request for receiving data is granted by accessing each request based on three checks: 1) Regulatory Compliance, i.e. HIPAA and HITRUST™ regulations, understood to read on non-discretionary access rules, i.e. these rules must be met without discretion or modification, 2) Security, i.e. the health data server ensures authentication and authorization, and 3) Market Rules, i.e. the health data server implements organization-specific controls that govern data access results; See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by discretion of an entity; therefore, there are security rules that are configured to be discretionary, i.e. modifiable, and non-discretionary);
generating an access filter based on the hierarchical relationship, the first discretionary predicate and the non-discretionary predicate (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules that are modified or discretionary, and these rules actively being implemented by the system at hand, which is understood to include the generation of access filter computer readable program code; See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a memory, computer readable program code, and storage/generation of computer readable code, and it is understood by Examiner that the electronic access to said data would comprise implementing instructions for access to said data),
when the first discretionary predicate is not in conflict with the non-discretionary predicate, generating the access filter based on the first discretionary predicate and the non-discretionary predicate (See Mynhier Par [0094]-[0099] which discloses the server determining whether a request for receiving data is granted by accessing each request based on three checks: 1) Regulatory Compliance, i.e. HIPAA and HITRUST™ regulations, understood to read on non-discretionary access rules, i.e. these rules must be met without discretion or modification, 2) Security, i.e. the health data server ensures authentication and authorization, and 3) Market Rules, i.e. the health data server implements organization-specific controls that govern data access results; See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on controlling electronic access to the data; See Mynhier Par [0059] & [0062] which discloses validating a request for data by a user device, i.e. secondary or remote computing device, such that a rules module that is local to the primary computing system processes and checks if said request is allowed according to data access rules, called market rules; See Mynhier Par [0017]-[0019] which discloses one or more data sources, such as a variety of stakeholders and/or entities, and that each of the one or more data sources or data source devices may have varying consents, access rights, source information at Par [0019]; because these rules are all applied, it is understood by Examiner that this would fit the scenario of the discretionary predicate is not in conflict with the non-discretionary predicate and generating the access filter based on both predicates)
receiving, from a requesting source, a request to access the data (See Mynhier Par [0062] which discloses validating a request for data by a user device, i.e. secondary or remote computing device, such that a rules module that is local to the primary computing system processes and checks if said request is allowed); and
blocking the requesting source from accessing at least a portion of the data based at least in part on the requesting source and the access filter (See Mynhier Par [0092]-[0093] which discloses blocking access for certain requests, based on the level of access associated with each request e.g. if the requesting user (or user's organization/role type) has not been granted rights by the original data source or patient who shared that data);
receiving a user input for modifying the first discretionary predicate (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, which is thereby understood to include a received user input for defining the access rules, however Mynhier does not necessarily seem to disclose updating or modifying the discretionary predicate aside from the initial security protocol being defined);
modifying, in response to the user input, the first discretionary predicate (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, which is thereby understood to include a received user input for defining the access rules, however Mynhier does not necessarily seem to disclose updating or modifying the discretionary predicate aside from the initial security protocol being defined).
As discussed above, Mynhier seems to disclose the use of discretionary and non-discretionary security protocols/rules, and it should be further noted that Mynhier discloses the use of an NLP engine at Par [0075] & [0115] but does not necessarily disclose “NLP” and “predicate” verbiage as they pertain to the claims above, i.e. security rules and hierarchical relationships therebetween may be deconstructed or parsed using NLP, which can be trained to identify the variables and predicates in the rules. Additionally, Mynhier seems relatively silent on determining whether individual security layers of an SSL protocol conflict with one another and if there are layers in conflict, implementing the non-discretionary layer instead of the discretionary layer. Finally, Mynhier does not seem to disclose updating or modifying the discretionary predicate, such as in an iterative manner, aside from the initial security protocol being defined.
Therefore, Jain discloses training and using NLP efforts to identify security predicates in the rules and determining, by the one or more processors configured for NLP and based at least in part on the set of rules, a hierarchical relationship between the discretionary predicate and the non-discretionary predicate (See Jain Abstract & Par [0011]-[0012] which discloses the use of one or more semantic security labels, e.g. security predicates; See Jain Par [0027]-[0029] which discloses the use of a policy module that comprises defining security and/or access control policy, i.e. code, represented using a policy language having different language constructs; See Jain Par [0030]-[0036] which discloses the use of ontology-based policies (e.g. semantic policies which define security policy elements such as subjects, resources, credentials, and other obligations between ontological elements and further includes security labeling information such as security predicates, constituting the use of language processing efforts to determine predicates in the security rules; See Jain Par [0035] which specifically discloses that a secure ontology may be extracted, such as by NLP as described in [0030], that comprises a plurality of security patterns, including a default security pattern, which may leave no data within the ontology library unclassified and/or without a security label, such that the security label applied to the data within the ontology library may be periodically updated as the security policies of the semantic framework are revised and therefore, a relationship between the policies and framework is determined, and Jain Par [0075] which discloses security labels indicating only certain information available to particular entities, such that particular requesters or roles have access to certain information) determining whether the discretionary predicate is in conflict with the non-discretionary predicate (See Jain Par [0016] which discloses security labels (e.g. security predicates); See Jain Par [0020] which discloses security policy being checked for consistency by the system and may detect direct and inferred conflicts within a security policy and following this, security policy may be automatically modified to remove the direct and/or inferred conflicts); when the discretionary predicate is in conflict with the non-discretionary predicate, generating the access filter based on the non-discretionary predicate and disregarding the discretionary predicate (See Jain Par [0008] further discloses the use of “discretionary access control”, understood to constitute access rules that may or may not be up to the discretion of one or more entities; See Jain Par [0016] which discloses security labels (e.g. security predicates); See Jain Par [0020] which discloses security policy being checked for consistency by the system and may detect direct and inferred conflicts within a security policy and following this, security policy may be automatically modified to remove the direct and/or inferred conflicts; See Jain Par [0018] which, while not “discretionary” and “non-discretionary” per se, discloses security predicates with or policies in violation of one another, e.g. if the existing RDF statement has a higher, i.e. nondiscretionary, level than the inferred RDF statement, discretionary, then a security policy violation may be identified and further specifically discloses in Jain Par [0019] that upon said inferred conflict being identified, the security label of the inferred statement, i.e. discretionary, may be completely subsumed (e.g., replaced) by the original, "higher", i.e. nondiscretionary, security label); updating, by the one or more processors, the access filter based on the hierarchical relationship, the modified discretionary predicate, and the non-discretionary predicate (See Jain Par [0038]-[0041] which discloses the use of a negotiation module for negotiating security and/or access control policy such that multiple iterations or an iterative updating/modification of security rules may be implemented and/or Jain Par [0035] which discloses the security label applied to the data within the ontology library may be periodically updated as the security policies of the semantic framework are revised); and unblocking, by the one or more processors, the requesting source from accessing at least the portion of the data based at least in part on the requesting source and the updated access filter (See Jain Par [0038]-[0041] which discloses the use of a negotiation module for negotiating security and/or access control policy such that multiple iterations or an iterative updating/modification of security rules may be implemented; See Jain Par [0043] which discloses an identification and trust management service to allow the evaluation module and/or other components within the semantic framework to verify (e.g., authenticate) the identity of external, third-party entities (e.g., agent) and/or authentication message transmitted by the entities to determine whether the information sharing arrangement negotiated with the agent should allow access to the requested information; See Jain Par [0058] which discloses a requester may be granted increased access by allowing access to information managed and/or controlled by the requesting entity after the access level of the entity has been modified according to a negotiation process).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Mynhier which already discloses the use of discretionary and non-discretionary security protocols/rules and the use of an NLP engine to further specifically include training and using NLP efforts to identify security predicates and hierarchical relationships in the security rules/predicates and updating or modifying the discretionary predicate, such as in an iterative manner, as disclosed by Jain. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Mynhier with the teachings from Jain, because by implementing ontology/language-based policies, the policies may define policy elements, such as subjects, resources, credentials, and obligations between particular data elements which can be used by the system to dynamically determine accessibility by users to specific portions of data that are stored (See Jain Par [0030]-[0031]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Mynhier to further include determining whether the discretionary predicate is in conflict with the non-discretionary predicate and when the discretionary predicate is in conflict with the non-discretionary predicate, generating the access filter based on the non-discretionary predicate and disregarding the discretionary predicate because an access filter, i.e. overall security policy, may comprise multiple rules that can conflict one another and in the event of a conflict, the violation needs to be resolved and in that event, the rules with higher precedence/restriction should be applied (See Jain Par [0018]-[0019]). Additionally, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the disclosure of Mynhier to further include updating or modifying the discretionary predicate in an iterative manner allows for negotiation to securely share information with other entities via the network such that the discretionary predicate can allow the system to further dynamically determine accessibility by users to specific portions of data based on updated information, such as an increased trust level between entities that interact with the system over time (See Jain Par [0038]-[0041]).
While Mynhier and Jain generally disclose efforts regarding creating market rules, i.e. discretionary predicates, based on shortcomings of previous market rules and/or other security measures, Mynhier and Jain seem to focus on lack of discretionary predicates instead of non-discretionary predicates, as required by the following limitations:
identifying at least one area for which the set of non-discretionary rules lacks provision; and
generating a second discretionary predicate associated with the at least one area based on the lack of provision.
Therefore, Chandrashekhar discloses identifying at least one area for which the set of non-discretionary rules lacks provision (See Chandrashekhar Par [0092] which discloses the analysis server iteratively removing one or more data elements from the aggregated data and re-processing the remaining set until a satisfactory aggregated set of data elements is found, such that it is understood that iterative discretionary predicates are generated; See Chandrashekhar Par [0101]-[0103] which provides specific examples of the situation described in Chandrashekhar Par [0092] of a government official requesting information, such that a non-discretionary predicate that defines certain access rules for said government official existing to gather certain eligible information like coverage, names, and the like, but does not cover necessary sensitive data such as data regarding social security numbers, age, marital status, and the like); and generating a second discretionary predicate associated with the at least one area based on the lack of provision (See Chandrashekhar Par [0092] which discloses the analysis server iteratively removing one or more data elements from the aggregated data and re-processing the remaining set until a satisfactory aggregated set of data elements is found, such that it is understood that iterative discretionary predicates are generated; See Chandrashekhar Par [0101]-[0103] which provides specific examples of the situation described in Chandrashekhar Par [0092] of a government official requesting information, such that a non-discretionary predicate that defines certain access rules for said government official existing to gather certain eligible information like coverage, names, and the like, but does not cover necessary sensitive data such as data regarding social security numbers, age, marital status, and the like, such that upon a request from the government official regarding said sensitive data, the system iteratively removes said sensitive data, via the iterative discretionary predicates that are generated in Chandrashekhar Par [0092]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Mynhier and Jain which already discloses creating discretionary predicates, based on shortcomings of previous market rules and/or other security measures to further specifically include identifying at least one area for which the set of non-discretionary rules lacks provision and generating a second discretionary predicate associated with the at least one area based on the lack of provision, as disclosed by Chandrashekhar, because certain sensitive data, including data regarding social security numbers, age, marital status, and the like can be harmful to individuals, even when accessed by entities with official statuses (See Chandrashekhar Par [0101]-[0103]).
While Chandrashekhar generally discloses that each time the system re-processes whether the data elements pass the discretionary rules, a subsequent discretionary predicate is applied in each processing instance until the discretionary predicate is satisfied (see Chandrashekar Fig. 6, method 600), albeit each of these discretionary predicates may be identical to a previously applied discretionary predicate and does not explicitly delineate said predicates as being unique from one another. Therefore, Mynhier, Jain, and Chandrashekhar are relatively silent on:
the second discretionary predicate is different than the first discretionary predicate
However, Cummins discloses the second discretionary predicate is different than the first discretionary predicate (See Cummins Par [0055]-[0062] & [0065]which discloses configurable, i.e. discretionary, predicates that can be configured to enable a user to modifying one or more firewall configuration parameters for any of the rings that represent said access policies; See Cummins Par [0068]-[0070] which discloses certain firewall configurations and may include one or more rules represented visually as concentric rings, such that each of the rings represent one or more rules/parameters defining an access policy, and concentric rings representing one or more security layers stacked on top of each other, constituting two or more discretionary predicates that are modifiable, and different from one another).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Mynhier, Jain, and Chandrashekhar which already discloses iteratively changing a discretionary predicate, such that the second discretionary predicate is different than the first discretionary predicate, as disclosed by Cummins, because this allows for users to change one or more security layers with varying rules, i.e. different from one another, to delete or modify one or more firewall configuration parameters so as to further or no longer limit traffic to or from certain nodes/based on certain rules/parameters (See Cummins Par [0061]).
While Chandrashekhar generally discloses that each time the system re-processes whether the data elements pass the discretionary rules, a subsequent discretionary predicate is applied in each processing instance until the discretionary predicate is satisfied (see Chandrashekar Fig. 6, method 600), albeit each of these discretionary predicates may be identical to a previously applied discretionary predicate and does not explicitly delineate said predicates as being unique from one another. Therefore, Mynhier, Jain, and Chandrashekhar are relatively silent on:
the second discretionary predicate is different than the first discretionary predicate
However, Cummins discloses the second discretionary predicate is different than the first discretionary predicate (See Cummins Par [0055]-[0062] & [0065]which discloses configurable, i.e. discretionary, predicates that can be configured to enable a user to modifying one or more firewall configuration parameters for any of the rings that represent said access policies; See Cummins Par [0068]-[0070] which discloses certain firewall configurations and may include one or more rules represented visually as concentric rings, such that each of the rings represent one or more rules/parameters defining an access policy, and concentric rings representing one or more security layers stacked on top of each other, constituting two or more discretionary predicates that are modifiable, and different from one another). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Mynhier, Jain, and Chandrashekhar which already discloses iteratively changing a discretionary predicate, such that the second discretionary predicate is different than the first discretionary predicate, as disclosed by Cummins, because this allows for users to change one or more security layers with varying rules, i.e. different from one another, to delete or modify one or more firewall configuration parameters so as to further or no longer limit traffic to or from certain nodes/based on certain rules/parameters (See Cummins Par [0061]).
Claim 19 –
Regarding Claim 19, Mynhier, Jain, Chandrashekhar, and Cummins disclose the one or more non-transitory computer readable media of Claim 17 in its entirety. Mynhier further discloses a non-transitory computer readable media, wherein:
modifying the discretionary predicate comprises:
receiving an identification of a delegate entity (See Mynhier Par [0093] which discloses only certain users being able to see identifiable data, while all others may only receive access to identified versions or subsets of the organization’s data depending on the nature of the access restriction); and
receiving a set of the data the respective one of the delegate entity is permitted to access (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by a patient or stakeholder; See Mynhier Par [0093] which discloses only certain users being able to see identifiable data, while all others may only receive access to identified versions or subsets of the organization’s data depending on the nature of the access restriction; See Mynhier Par [0098] which discloses the patient request that specific parties only can see their data).
Claim 20 –
Regarding Claim 20, Mynhier, Jain, Chandrashekhar, and Cummins disclose the one or more non-transitory computer readable media of Claim 19 in its entirety. Mynhier further discloses a non-transitory computer readable media, wherein:
modifying the first discretionary predicate further comprises:
receiving input indicating an information type associated with the data (See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a processor; See Mynhier Par [0013]-[0014] which discloses the use of a computer which is understood to contain a memory, computer readable program code, and storage for computer readable code; See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by a patient or stakeholder; See Mynhier Par [0093] which discloses only certain users being able to see identifiable data, while all others may only receive access to identified versions or subsets of the organization’s data depending on the nature of the access restriction); and
modifying the first discretionary predicate to indicate the information type (See Mynhier Par [0017]-[0019] which discloses one or more data sources, such as a variety of stakeholders and/or entities, and that each of the one or more data sources or data source devices can be associated with or be the source of any type of data such as data from healthcare providers (e.g., data can be electronic medical records, lab data), health insurers/payers (e.g., data can be claims records), pharmaceutical and medical device companies (e.g., data can be clinical trial records, adverse event data), research (e.g., data can be a genomic profile), government/community health programs (e.g., data can be population health statistics) partnership databases), and/or individual patients (e.g., data can be biometrics, activity/behavior, and each of these data types or data sources may have varying consents, access rights, source information as specified at Mynhier Par [0019]); wherein
the delegate entity comprises a person, a business entity, or an application program executable by a computer processor (See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by a patient or stakeholder; See Mynhier Par [0093] which discloses only certain users being able to see identifiable data, while all others may only receive access to identified versions or subsets of the organization’s, i.e. business entity, data depending on the nature of the access restriction).
Claim 21 –
Regarding Claim 21, Mynhier, Jain, Chandrashekhar, and Cummins disclose the system of Claim 12 in its entirety. Jain discloses a system wherein the operations further comprise:
parsing the first modified discretionary predicate and the non- discretionary predicate using a policy logic language to generate logic expressions for the modified discretionary predicate and the non-discretionary predicate, respectively (See Jain Abstract & Par [0011]-[0012] which discloses the use of one or more semantic security labels, e.g. security predicates; See Jain Par [0027]-[0029] which discloses the use of a policy module that comprises defining security and/or access control policy, i.e. code, represented using a policy language having different language constructs; See Jain Par [0030]-[0036] which discloses the use of ontology-based policies (e.g. semantic policies which define security policy elements such as subjects, resources, credentials, and other obligations between ontological elements and further includes security labeling information such as security predicates, constituting the use of language processing efforts to determine predicates in the security rules);
verifying, by the policy logic language, that logic expressions accurately represent the logic in the modified discretionary predicate and the non-discretionary predicate, respectively (See Jain Par [0016]-[0020] which discloses the system being able to determine or check for conflicting security labels/policies and associated mappings such); and
wherein generating the access filter comprises generating the access filter based on the logic expressions (See Jain Par [0016]-[0020] which discloses the system being able to determine or check for conflicting security labels/policies and associated mappings such ; See Jain Par [0027]-[0029] which discloses the use of a policy module that comprises defining security and/or access control policy following determination/elimination of any conflicting security policies, i.e. code, represented using a policy language having different language constructs; See Jain Par [0030]-[0036] which discloses the use of ontology-based policies (e.g. semantic policies which define security policy elements such as subjects, resources, credentials, and other obligations between ontological elements and further includes security labeling information such as security predicates, constituting the use of language processing efforts to determine predicates in the security rules).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the combined disclosure of Mynhier, Jain, and Chandrashekhar to further include verifying, by the one or more processors and the policy logic language, that the logic expressions accurately represent the logic in the modified discretionary predicate and the non-discretionary predicate, as disclosed by Jain, because sometimes multiple security patterns, labels, etc., may conflict one another and lead to violations of the multiple security policies involved, so checking and resolving these conflicts allows for eliminating said violations (See Jain Par [0016]-[0020]).
Claim 22 –
Regarding Claim 22, Mynhier, Jain, Chandrashekhar, and Cummins disclose the one or more non-transitory computer readable media of Claim 17 in its entirety. Jain further discloses a non-transitory computer readable media, wherein the operations further comprise:
parsing the modified discretionary predicate and the non- discretionary predicate using a policy logic language to generate logic expressions for the modified discretionary predicate and the non-discretionary predicate, respectively (See Jain Abstract & Par [0011]-[0012] which discloses the use of one or more semantic security labels, e.g. security predicates; See Jain Par [0027]-[0029] which discloses the use of a policy module that comprises defining security and/or access control policy, i.e. code, represented using a policy language having different language constructs; See Jain Par [0030]-[0036] which discloses the use of ontology-based policies (e.g. semantic policies which define security policy elements such as subjects, resources, credentials, and other obligations between ontological elements and further includes security labeling information such as security predicates, constituting the use of language processing efforts to determine predicates in the security rules);
verifying, by the policy logic language, that logic expressions accurately represent the logic in the modified discretionary predicate and the non-discretionary predicate, respectively (See Jain Par [0016]-[0020] which discloses the system being able to determine or check for conflicting security labels/policies and associated mappings such); and
wherein generating the access filter comprises generating, using the one or more processors, the access filter based on the logic expressions (See Jain Par [0016]-[0020] which discloses the system being able to determine or check for conflicting security labels/policies and associated mappings such ; See Jain Par [0027]-[0029] which discloses the use of a policy module that comprises defining security and/or access control policy following determination/elimination of any conflicting security policies, i.e. code, represented using a policy language having different language constructs; See Jain Par [0030]-[0036] which discloses the use of ontology-based policies (e.g. semantic policies which define security policy elements such as subjects, resources, credentials, and other obligations between ontological elements and further includes security labeling information such as security predicates, constituting the use of language processing efforts to determine predicates in the security rules).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the combined disclosure of Mynhier, Jain, and Chandrashekhar to further include verifying, by the one or more processors and the policy logic language, that the logic expressions accurately represent the logic in the modified discretionary predicate and the non-discretionary predicate, as disclosed by Jain, because sometimes multiple security patterns, labels, etc., may conflict one another and lead to violations of the multiple security policies involved, so checking and resolving these conflicts allows for eliminating said violations (See Jain Par [0016]-[0020]).
Claim 23 –
Regarding Claim 23, Mynhier, Jain, Chandrashekhar, and Cummins disclose disclose the one or more non-transitory computer readable media Claim 17 in its entirety. Mynhier further discloses a non-transitory computer readable media, wherein the operations further comprise:
the non-discretionary predicate takes precedence over the first discretionary predicate (See Mynhier Par [0094]-[0097] the server determining whether a request for receiving data is granted by accessing each request based on three security checks: 1) Regulatory Compliance, i.e. HIPAA and HITRUST™ regulations, understood to read on non-discretionary access rules, rules and regulations set by the federal government and/or state government, respectively; See Mynhier Par [0113] which discloses the health data system acting as an interchange, where the system administrator does not own data or determine access rights/rules, rather data owners, i.e. patients, clients and/or stakeholders, can dictate which users and services the data will flow, i.e. patients/clients/stakeholders provide and receive data that is governed by relevant regulations and/or client-defined access rules, understood to read on access rules defined by a patient; See Mynhier Par [0151] & [0153]-[0157] which discloses a pre-established security tunnel, that which utilizes a combination of multiple rules/layers sitting on top of baseline SSL protocols such that, different layers of security and access control must be satisfied to gain access to the information, and while Mynhier does not explicitly state that the first or second health care information access rules have priority level/layer over one another, it is understood that if the system described in Mynhier placed a second health care information layer, i.e. government regulation, before the first health care information access rules layer, i.e. patient-defined regulation, then the second heath care information would, in fact, take priority since each preceding layer has to be satisfied before moving to the next; Therefore, see MPEP 2144.05(II)(A) which describes optimization within prior art conditions or through routine experimentation, such that when the general conditions of a claim are disclosed in the prior art, generally it is not inventive to discover the optimum or workable ranges by routine experimentation; As such, because Mynhier discloses the first and second health care information access rules and each security layer needing to be satisfied before moving to the next, the general conditions of the claim are disclosed and placing priority on the first and/or second health care information access rule/layer constitutes optimization within prior art conditions or through routine experimentation) with respect to the granting of access to the data based on the non-discretionary predicate indicating a first more restrictive predicate than the first discretionary predicate (See Mynhier Par [0153]-[0154] which discloses requested data traveling through a pre-established secured tunnel, such that the secured tunnel is a combination of multiple rules sitting on top of baseline SSL protocol, i.e. a hierarchy of rules, e.g. market rules that are discretionary, since multiple rules sit on top of baseline SSL protocol (non-discretionary), such that each layer of the platform (corresponding to ISO model) has its own distinct rule-set that augment the core SSL protocols, i.e. non-discretionary baseline SSL protocol takes precedence over discretionary ruleset that sits on top of said baseline SSL protocol, and further discloses in Mynhier Par [0151]-[0152] that the security module provides a role based dynamic, multi-form authentication such that amount of data access is granted based on said market rules, e.g. in the form of a role-based dynamic, that roles are provided/assigned to users to access certain screens, reports, module, and code pieces dependent on their role and thereby restricting an extent of access/data that can be received based on said role; See MPEP 2144.05(II)(A) which describes optimization within prior art conditions or through routine experimentation, such that when the general conditions of a claim are disclosed in the prior art, generally it is not inventive to discover the optimum or workable ranges by routine experimentation; As such, because Mynhier discloses the first and second health care information access rules and each security layer needing to be satisfied before moving to the next, the general conditions of the claim are disclosed and placing priority on the first and/or second health care information access rule/layer constitutes optimization within prior art conditions or through routine experimentation, such that one predicate is more restrictive than the discretionary predicate).
Response to Arguments
Applicant's arguments filed 03 February 2026 have been fully considered but they are not persuasive.
Regarding 35 U.S.C. 101 rejections of claims 1-5, 7-12, 14-17, & 19-23, Applicant argues on p. 11-12 of Arguments/Remarks, assuming arguendo that the amended independent claims do recite a judicial exception, they are not directed towards said judicial exception because the claims are integrated into a practical application. More specifically, Applicant argues in view of the prior art not being able to identify where there are gaps in non-discretionary rules and do not address and resolve the gaps, thereby representing a technological improvement over prior art systems and/or amounting to significantly more than just well-understood, routine, and/or conventional activity in prior art systems. Examiner respectfully disagrees with Applicant’s arguments. Identifying gaps in security and modifying security rules/policies accordingly is amounts to data gathering, data manipulation, and/or insignificant application. Furthermore, it is understood by Examiner that this serves as the basis for electronic security. That is, gaps and/or holes in secure data transmission are effectively covered and/or mitigated by electronic security policies, in order to mitigate said security holes. Therefore, merely specifying that this happens one or more times via one or more discretionary predicates, i.e. modifiable security rules/parameters, does not necessarily represent an improvement to prior art systems, which already identifies the problem of gaps and/or holes in secure data transmission. That is, specifying the amount or performing iterative instances of said securing merely amounts to further optimization and/or repetitive calculations, thereby not representing a practical application/technological improvement. Furthermore, Applicant argues against the steps in the dependent claims reciting well-understood, routine, and/or conventional activity in the prior art, each of the limitations found therein were determined to be thoroughly described in prior art systems to be well-understood and/or represent activities that the courts have found to constitute well-understood, routine, and conventional activity in the prior art. For instance, identifying areas where non-discretionary rules lack provision and then generating a discretionary predicate to provide or make up for said area that lacks provision amounts to efforts of data manipulation, performing repetitive calculations, electronic recordkeeping of one or more security policies for digital communications, and/or generating subsequent discretionary predicates iteratively based on shortcomings of one or more non-discretionary predicates all describe WURC in view of the courts reasonings and/or prior art. Furthermore, the prior art generally renders said aspects of tailoring discretionary predicates to cover gaps in non-discretionary predicates well-understood, routine, and/or conventional. In view of the reasons mentioned above, amended Claim 1 does not amount to a practical application and/or significantly more than the recited abstract idea. Therefore, the 35 U.S.C. 101 rejections of claims 1-5, 7-12, 14-17, & 19-23 are maintained.
Regarding 35 U.S.C. 101 rejections of claims 1-5, 7-12, 14-17, & 19-23, Applicant argues on p. 12 of Arguments/Remarks that independent claims 12 & 17 are substantially similar to independent claim 1 and is therefore purportedly patent-eligible for the same or substantially similar reasons. Examiner respectfully disagrees with Applicant’s arguments. It was determined above that amended claim 1 did not represent patent-eligible subject matter. As such, because claim 1 was determined to not represent patent-eligible subject matter, Applicant’s arguments regarding independent claims 12 & 17 being substantially similar to independent claim 1 and claim 1 being patent-eligible are rendered moot. Therefore, the 35 U.S.C. 101 rejections of claims 1-5, 7-12, 14-17, & 19-23 are maintained.
Regarding 35 U.S.C. 101 rejections of claims 1-5, 7-12, 14-17, & 19-23, Applicant argues on p. 12 of Arguments/Remarks that because dependent claims 2-5, 7-11, 14-16, & 19-23 are dependent from claim 1, and claim purportedly represents patent-eligible subject matter, dependent claims 2-5, 7-11, 14-16, & 19-23 are also patent-eligible by virtue of dependency. Examiner respectfully disagrees with Applicant’s arguments. It was determined above that amended claim 1 did not represent patent-eligible subject matter. As such, because claim 1 was determined to not represent patent-eligible subject matter, Applicant’s arguments regarding dependent claims 2-5, 7-11, 14-16, & 19-23 being patent-eligible by virtue of dependency from patent-eligible claim 1 are thereby rendered moot. Therefore, the 35 U.S.C. 101 rejections of claims 1-5, 7-12, 14-17, & 19-23 are maintained.
Regarding 35 U.S.C. 103 rejections of claims 1-20, Applicant argues on p. 10-11 of Arguments/Remarks that amended independent claims 1, 12, & 17 overcoming previous 35 U.S.C. 103 rejections made over Mynhier in view of Jain further in view of Chandrashekhar. More specifically, Applicant argues that independent claim 1 has been amended in the manner discussed during the interview and agreed upon as overcoming the previous 35 U.S.C. 103 rejections at least by specifying that the second discretionary predicate is different from the first discretionary predicate Examiner agrees with Applicant’s arguments. Therefore, the previous 35 U.S.C. 103 rejections of claims 1, 12, & 17 and claims dependent therefrom have been withdrawn. However, upon further consideration, a new ground of rejection is made under 35 U.S.C. 103 over newly cited/reasoned portions of Mynhier in view of Jain et al, in view of Chandrashekhar, further in view of Cummins. Newly cited Cummins is relied upon for disclosing one or more iterative discretionary predicates that are modified and different from one another. As such, independent claims 1, 12, & 17 remain rejected under 35 U.S.C. 103 over Mynhier in view of Jain, in view of Chandrashekhar, further in view of Cummins.
Regarding 35 U.S.C. 103 rejections of claims 1-20, Applicant argues on p. 11 of Arguments/Remarks that because Claims 1, 12, & 17 are purportedly patentable over the prior art, claims dependent therefrom, i.e. claims 2-5, 7-11, 14-16, & 19-23, should also be allowable over the prior art by virtue of dependency. Examiner respectfully disagrees with Applicant’s arguments. As discussed above, a new ground of rejection has been issued for independent claims 1, 12, & 17 and, as such, the independent claims remain rejected under 35 U.S.C. 103 over Mynhier in view of Jain, in view of Chandrashekhar, further in view of Cummins. By virtue of dependency, claims dependent from independent claims 1, 12, & 17, i.e. claims 2-5, 7-11, 14-16, & 19-23, also remain rejected under 35 U.S.C. 103 over Mynhier in view of Jain, in view of Chandrashekhar, further in view of Cummins.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure:
McCarthy et al. (U.S. Patent Publication No. 2015/0163206) discloses a secure data exchange system in which said data exchange environment can have customizable rules or access parameters/permissions;
Ginter et al. (U.S. Patent No. 8,639,625) discloses a system for electronic information distribution capabilities and security management thereof, so as to create an “electronic highway” of permissions for accessing said data;
Hoffer (U.S. Patent Publication No. 9,928,379) discloses methods of mediation software, i.e. security software, for rapid health care support, such that one or more security rules may be established or modified for allowing data access for health care support purposes.
Applicant's amendment necessitated the new ground of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUNTER J RASNIC whose telephone number is (571)270-5801. The examiner can normally be reached M-F 8am-5:30pm.
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, Shahid Merchant can be reached on (571) 270-1360. 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.
/H.R./
Examiner, Art Unit 3684
/Shahid Merchant/Supervisory Patent Examiner, Art Unit 3684
Prosecution Insights