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 .
DETAILED ACTION
1. This Office Action is in response to the application filed on 08/12/2025.
Claims 1-20 are pending.
Priority
2. This application is a Continuation-In-Part of 18/664,014 (Patent US 12,681,999), which was filed on 05/14/2024, was acknowledged and considered
Information Disclosure Statement
3. The information disclosure statement (IDS) filed on 04/16/2026, 04/16/2026, 12/02/2025 and 10/14/2025 comply with the provisions of M.P.E.P. 609. The examiner has considered it.
Claim Rejections - 35 USC § 101
4. 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.
5. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
At Step 1:
Independent claims 1, 9 and 15 directed to a "method", a “system” and a “program product” and thus directed to a statutory category
At Step 2A, Prong One:
The claim recites the following limitations directed to an abstract idea:
• " maintaining enterprise-specific context learned from data sources independent of data objects analyzed by a data security posture management (DSPM) solution" as drafted this recites a mentally performable process as an evaluation or judgement. This is also consistent with the specification as in Fig. 6 and paragraph 142 where one can mentally visualizing maintaining enterprise-specific context information.
• " determining, based at least in part on the enterprise-specific context, an action to be performed by the DSPM solution" as drafted this recites a mentally performable process as an evaluation or judgement. This is also consistent with the specification as in Fig. 6 and paragraph 143 where one can mentally visualizing determining an action to be performed by the DSPM solution.
• " performing the action by the DSPM solution" as drafted this recites a mentally performable process as an evaluation or judgement. This is also consistent with the specification as in Fig. 6 and paragraph 144 where one can mentally visualizing performing the action by the DSPM solution.
At Step 2A, Prong Two:
• The claim recites no additional elements. At most one might consider that a "a memory … a processing device" as claimed might be considered to represent a computer-implemented system and method consistent with Fig. 1 even though the claim does not recite any computer. At most this would be a high-level recitation of a generic computer components and represents mere instructions to apply the abstract idea on a computer as in MPEP 2106.05(f), which does not provide integration into a practical application.
• Viewing the additional limitations together and the claim as a whole, nothing provides integration into a practical application.
At Step 2B:
• The conclusions for the mere implementation using a computer are carried over and does not provide significantly more.
• Looking at the claim as a whole does not change this conclusion and the claim is ineligible.
Dependent Claims 2-8, 10-14 and 16-20
The limitations as recited in dependent claims 2, 10 and 16 recite, “wherein determining the action to be performed by the DSPM solution comprises determining, based on the enterprise-specific context, whether to permit a request to access a data object.”, which further describes the concept is mere gathered data under prong 2 (insignificant extra solution activity— MPEP 2106.06g) and WURC under 2b (using gather data - MPEP 2106.05d).
The limitations as recited in dependent claims 3, 11 and 17 recite, “wherein performing the action further comprises permitting the request to access the data object, denying the request to access the data object, or generating a security alert in response to determining that the request is not to be permitted” which further describes the concepts performed in the human mind including an observation, evaluation, judgment, and opinion, in step 2A prong one.
The limitations as recited in dependent claims 4, 12 and 18 recite, “wherein performing the action further comprises setting a permission associated with the data object”, which further describes the concept is mere gathered data under prong 2 (insignificant extra solution activity— MPEP 2106.06g) and WURC under 2b (using gather data - MPEP 2106.05d).
The limitations as recited in dependent claims 5, 13 and 19 recite, “evaluating the enterprise-specific context against a policy defined by an administrator, wherein performing the action by the DSPM solution is based at least in part on whether the enterprisc-specific context satisfics the policy” which further describes the concepts performed in the human mind including an observation, evaluation, judgment, and opinion, in step 2A prong one.
The limitations as recited in dependent claim 6 recites, “wherein performing the action further comprises assigning a classification to the data object based on the enterprisc-specific context”, which further describes the concept is mere gathered data under prong 2 (insignificant extra solution activity— MPEP 2106.06g) and WURC under 2b (using gather data - MPEP 2106.05d).
The limitations as recited in dependent claim 7 recites, “generating a human-readable explanation of the action determined by the DSPM solution” which further describes the concepts performed in the human mind including an observation, evaluation, judgment, and opinion, in step 2A prong one.
The limitations as recited in dependent claims 8, 14 and 20 recite, “wherein the enterprise-specific context comprises inferred relationships among users, documents, or systems within an enterprise”, which further describes the concept is mere gathered data under prong 2 (insignificant extra solution activity— MPEP 2106.06g) and WURC under 2b (using gather data - MPEP 2106.05d).
Examiner’s Note
6. Enterprise-specific context (According to Google): “Enterprise-specific context refers to the unique, proprietary knowledge, business rules, and organizational memory that define a specific company. Unlike public data that an AI model naturally learns from, this context gives AI systems the background needed to make decisions that align with a company's exact goals, structure, and policies.”
Data Security Posture Management (DSPM) (According to Google): “Data Security Posture Management (DSPM) is a data-centric cybersecurity approach that automatically discovers, classifies, and continuously monitors sensitive data across cloud and hybrid environments. It answers fundamental questions: Where is our sensitive data? Who has access to it? And how is it being exposed or used? Why DSPM is Different: Traditionally, cybersecurity focused on protecting the "box" (the network perimeters, devices, and servers). DSPM flips this model by protecting the "contents" (the data itself), following its movement across databases, data lakes, SaaS applications, and even modern AI training workflows. Key Capabilities: (1) Automated Discovery & Classification: Automatically scans environments to locate structured and unstructured data (e.g., PII, PHI, financial records, and AI models) and categorizes it by sensitivity. (2) Access Governance & Contextual Risk: Maps data flows and identifies over-privileged accounts, dormant users, or shadow databases to ensure only authorized entities can access sensitive information. (3) Vulnerability & Misconfiguration Detection: Pinpoints exposed storage buckets, unencrypted data, and security "drift" that creates attack paths.(4) Compliance & Remediation: Automates security policies to align with data privacy mandates like GDPR, HIPAA, or CCPA, and assists security teams in remediating risks.”
Perez Alvarez et al, US 20180349778, [Alvarez: Abstract (“The data model includes a set of business objects, at least some of the business objects being linked to a domain-specific activity type by a business object relation. A database is generated from the data model which is accessible through an application program interface. Provision is made for a user to generate a domain-specific process model with links to business objects in the domain specification. The domain-specific process model is transformed to a domain-independent process model which has access to the database through the application program interface at runtime.”)] [Alvarez: Paragraphs 14 and 27 (“a method for externalizing data includes extracting a data model from a domain specification. The data model includes a set of business objects, at least some of the business objects being linked to a domain-specific activity type by a business object relation. A database is generated from the data model which is accessible through an application program interface. Provision is made for a user to generate a domain-specific process model with links to business objects in the domain specification. The domain-specific process model is transformed to a domain-independent process model which has access to the database through the application program interface”, i.e., ‘enterprise-specific context’ or ‘enterprise-aware’)] [Alvarez: Paragraphs 32, 40, 42 and 64 (“A “domain meta-model” (DomainMM) describes the formal structure of a business domain in a domain-specific language (DSL), and incorporates business object definitions for creating domain-specific business objects (e.g., documents) that are used in that domain as well as formalizing the relations which can exist between activity types (e.g., CREATE and UPDATE), and the business objects” and “A “business object relation” (BORelation) represents a dependency relation between a domain-specific activity type and a business object” and “ncludes domain-specific business objects 20, domain-specific services (DSServices) 22, and domain-specific activity types (DSActivityTypes) 24 and links between them”, i.e., ‘an action to be performed by the DSMP solution’)] [Alvarez: Paragraph 45 (“A domain-specific process model (DSPM) 36 is built in a domain-specific language, e.g., by a business analyst 38, as an instance of the ProcessMM 12. The DSPM 36 defines the process and includes links to the domain specification 16 to describe the business objects 20, services 22, and activity types 24 that are involved in the process. The building of the DSPM 36, representing a domain-specific process (DSP), includes connecting the different steps that refer to the DSActivityTypes 24 previously defined in the domain model 16. The link to the DSActivityTypes gathers the information about the related DSServices 22 and DSBusinessObjects 20. Custom activities can be defined in the domain-specific process model 36.”, i.e., ‘DSPM solution’)] [Alvarez: Paragraph 65 (“Each data relation 170 includes a set of features including a source cardinality, a target cardinality, and a containment property. The source cardinality is the number of source business objects in the relation (e.g., selected from 1, 2, and many). The target cardinality is the number of target business objects in the relation (e.g., selected from 1, 2, and many). The containment property defines whether the target business object is contained in the source business object. As an example, a specific data relation between a one business object and another may have source cardinality of one, and a target cardinality of one, indicating that there is only one source document and one target document in the relation”, i.e., ‘data sources’)].
Cook et al, US 20150161210, [Cook: Paragraph 23 (“a data warehouse 104 that may be coupled to data sources 102A, 102B, and 102C through a network 103. The term "data source" can refer to the company that is the source of the data (e.g. PII data, business data, customer data, other data, or any combination thereof), but can also refer to a "data owner". A data owner may own rights to data that it did not generate, does not possess, or does not host. Each data source (or a user having administrative privileges for the data source) may configure its data sharing permissions, which define how much, with whom, and/or under what conditions its PII and/or NPI data may be shared. In an example, the data source may choose to permit sharing of its PII and/or NPI data with some data requesters, but not others, or may choose to permit sharing of limited portions of its PII and/or NPI data with some data requesters. The permissions and the data may be stored by the data warehouse 104”, i.e., ‘data source’ and ‘enterprise-specific context learned from data source’)].
Claim Rejections - 35 USC § 102
7. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
8. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
9. Claims 1-2, 6-10, 14-16 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Perez Alvarez et al (US 20180349778).
Claim 1:
Alvarez suggests a method of enterprise-aware data security posture management using contextualized access intelligence, comprising: maintaining enterprise-specific context learned from data sources independent of data objects analyzed by a data security posture management (DSPM) solution [Alvarez: Paragraphs 14 and 27 (“a method for externalizing data includes extracting a data model from a domain specification. The data model includes a set of business objects, at least some of the business objects being linked to a domain-specific activity type by a business object relation. A database is generated from the data model which is accessible through an application program interface. Provision is made for a user to generate a domain-specific process model with links to business objects in the domain specification. The domain-specific process model is transformed to a domain-independent process model which has access to the database through the application program interface”, i.e., ‘enterprise-specific context’ or ‘enterprise-aware’)] [Alvarez: Paragraph 65 (“Each data relation 170 includes a set of features including a source cardinality, a target cardinality, and a containment property. The source cardinality is the number of source business objects in the relation (e.g., selected from 1, 2, and many). The target cardinality is the number of target business objects in the relation (e.g., selected from 1, 2, and many). The containment property defines whether the target business object is contained in the source business object. As an example, a specific data relation between a one business object and another may have source cardinality of one, and a target cardinality of one, indicating that there is only one source document and one target document in the relation”, i.e., ‘data sources’)] [Alvarez: Paragraphs 32, 40, 42 and 64 (“A “domain meta-model” (DomainMM) describes the formal structure of a business domain in a domain-specific language (DSL), and incorporates business object definitions for creating domain-specific business objects (e.g., documents) that are used in that domain as well as formalizing the relations which can exist between activity types (e.g., CREATE and UPDATE), and the business objects” and “A “business object relation” (BORelation) represents a dependency relation between a domain-specific activity type and a business object” and “ncludes domain-specific business objects 20, domain-specific services (DSServices) 22, and domain-specific activity types (DSActivityTypes) 24 and links between them”, i.e., ‘an action to be performed by the DSMP solution’)]. Alvarez suggests determining, based at least in part on the enterprise-specific context, an action to be performed by the DSPM solution [Alvarez: Paragraph 45 (“A domain-specific process model (DSPM) 36 is built in a domain-specific language, e.g., by a business analyst 38, as an instance of the ProcessMM 12. The DSPM 36 defines the process and includes links to the domain specification 16 to describe the business objects 20, services 22, and activity types 24 that are involved in the process. The building of the DSPM 36, representing a domain-specific process (DSP), includes connecting the different steps that refer to the DSActivityTypes 24 previously defined in the domain model 16. The link to the DSActivityTypes gathers the information about the related DSServices 22 and DSBusinessObjects 20. Custom activities can be defined in the domain-specific process model 36.”, i.e., ‘DSPM solution’)]. Alvarez suggests performing the action by the DSPM solution [Alvarez: Paragraph 45 (“A domain-specific process model (DSPM) 36 is built in a domain-specific language, e.g., by a business analyst 38, as an instance of the ProcessMM 12. The DSPM 36 defines the process and includes links to the domain specification 16 to describe the business objects 20, services 22, and activity types 24 that are involved in the process. The building of the DSPM 36, representing a domain-specific process (DSP), includes connecting the different steps that refer to the DSActivityTypes 24 previously defined in the domain model 16. The link to the DSActivityTypes gathers the information about the related DSServices 22 and DSBusinessObjects 20. Custom activities can be defined in the domain-specific process model 36.”, i.e., ‘DSPM solution’)].
Claim 2:
Alvarez suggests wherein determining the action to be performed by the DSPM solution comprises determining, based on the enterprise-specific context, whether to permit a request to access a data object [Alvarez: Paragraph 45 (“A domain-specific process model (DSPM) 36 is built in a domain-specific language, e.g., by a business analyst 38, as an instance of the ProcessMM 12. The DSPM 36 defines the process and includes links to the domain specification 16 to describe the business objects 20, services 22, and activity types 24 that are involved in the process. The building of the DSPM 36, representing a domain-specific process (DSP), includes connecting the different steps that refer to the DSActivityTypes 24 previously defined in the domain model 16. The link to the DSActivityTypes gathers the information about the related DSServices 22 and DSBusinessObjects 20. Custom activities can be defined in the domain-specific process model 36.”, i.e., ‘DSPM solution’)] [Alvarez: Paragraph 81 (“At S110, a REST-API 34 or other suitable API is generated. The REST-API permits interactions with the database 34 in an easy and platform-independent way”)].
Claim 6:
Alvarez suggests wherein performing the action further comprises assigning a classification to the data object based on the enterprise-specific context [Alvarez: Paragraphs 14-16 (“externalizing data includes extracting a data model from a domain specification. The data model includes a set of business objects, at least some of the business objects being linked to a domain-specific activity type by a business object relation. A database is generated from the data model which is accessible through an application program interface. Provision is made for a user to generate a domain-specific process model with links to business objects in the domain specification. The domain-specific process model is transformed to a domain-independent process model which has access to the database through the application program interface.”)].
Claim 7:
Alvarez suggests generating a human-readable explanation of the action determined by the DSPM solution [Alvarez: Paragraphs 27 and 29 (“a Domain Specific Language (DSL) is used as an effective means to cope with application domains, providing improvements in expressiveness and ease of use. Mernik, M., et al., “When and how to develop domain-specific languages,” ACM computing surveys (CSUR), vol. 37, no. 4, pp. 316-344 (2005). A generative approach is used to generate a business object database automatically, from a domain-specific model, and to expose it as an application program interface (API), such as a Representational State Transfer (REST) interface.”)].
Claim 8:
Alvarez suggests wherein the enterprise-specific context comprises inferred relationships among users, documents, or systems within an enterprise [Alvarez: Paragraphs 27 and 29 (“allows users to define a data-model in a simple way and connect it to domain-specific activities. Then, they are able to consistently and repetitively reuse the externally-stored data across business processes with all the advantages enjoyed by the domain-specific activity types such as sweeping changes of document properties across processes, consistent connections between behavior and data for domain activities, and extensible generation patterns when targeting specific deployment platforms. This is advantageous when different users employ different BPM platform”)].
Claim 9:
Claim 9 is essentially the same as claim 1 except that it sets forth the claimed invention as a system rather than a method and rejected under the same reasons as applied above.
Claim 10:
Claim 10 is essentially the same as claim 2 except that it sets forth the claimed invention as a system rather than a method and rejected under the same reasons as applied above.
Claim 14:
Claim 14 is essentially the same as claim 8 except that it sets forth the claimed invention as a system rather than a method and rejected under the same reasons as applied above.
Claim 15:
Claim 15 is essentially the same as claim 1 except that it sets forth the claimed invention as a program product rather than a method and rejected under the same reasons as applied above.
Claim 16:
Claim 16 is essentially the same as claim 2 except that it sets forth the claimed invention as a program product rather than a method and rejected under the same reasons as applied above.
Claim 20:
Claim 20 is essentially the same as claim 8 except that it sets forth the claimed invention as a program product rather than a method and rejected under the same reasons as applied above.
Claim Rejections - 35 USC § 103
10. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
11. 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.
12. Claims 3-4, 11-12 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Perez Alvarez et al (US 20180349778), in view of Prettejohn et al (US 20220164465).
Clam 3:
The combined teachings of Alvarez and Prettejohn suggest wherein performing the action further comprises permitting the request to access the data object, denying the request to access the data object, or generating a security alert in response to determining that the request is not to be permitted [Prettejohn: Paragraph 169 (“In some embodiments, the system may automatically generate alerts based on certain criteria; for example, if a certain data asset access request is routinely being denied, the system may automatically generate an alert with a suggestion to create a derived data asset”)] [Prettejohn: Paragraph 130 (“a purpose sponsor user may review and approve (or deny) purpose access requests, generate data access requests, investigate relationships among various objects, and/or the like, (3) a data asset owner user may review and approve (or deny) data access requests, investigate relationships among various objects, and/or the like, and (4) a governance administrator user and/or a purpose sponsor user may review, analyze, and change, and otherwise interact with various policies, data assets, purposes, requests, approvals, denials, alerts, and/or the like”)].
Both references (Alvarez and Prettejohn) taught features that were directed to analogous art and they were directed to the same field of endeavor, such as data processing. It would have been obvious to one of ordinary skill in the art at the time the invention was made, having the teachings of Alvarez and Prettejohn before him/her, to modify the system of Alvarez with the teaching of Prettejohn in order to generate alert when denying [Prettejohn: Paragraph 169].
Clam 4:
The combined teachings of Alvarez and Prettejohn suggest wherein performing the action further comprises setting a permission associated with the data object [Prettejohn: Paragraphs 8-9 (“to change these, an administrator may have to manually change each permission of each data asset”)].
Both references (Alvarez and Prettejohn) taught features that were directed to analogous art and they were directed to the same field of endeavor, such as data processing. It would have been obvious to one of ordinary skill in the art at the time the invention was made, having the teachings of Alvarez and Prettejohn before him/her, to modify the system of Alvarez with the teaching of Prettejohn in order to setting permissions to data [Prettejohn: Paragraphs 8-9].
Claim 11:
Claim 11 is essentially the same as claim 3 except that it sets forth the claimed invention as a system rather than a method and rejected under the same reasons as applied above.
Claim 12:
Claim 12 is essentially the same as claim 4 except that it sets forth the claimed invention as a system rather than a method and rejected under the same reasons as applied above.
Claim 17:
Claim 17 is essentially the same as claim 3 except that it sets forth the claimed invention as a program product rather than a method and rejected under the same reasons as applied above.
Claim 18:
Claim 18 is essentially the same as claim 4 except that it sets forth the claimed invention as a program product rather than a method and rejected under the same reasons as applied above.
13. Claims 5, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Perez Alvarez et al (US 20180349778), in view of Jain (US 20170099176).
Claim 5:
The combined teachings of Alvarez and Jain suggest evaluating the enterprise-specific context against a policy defined by an administrator, wherein performing the action by the DSPM solution is based at least in part on whether the enterprise-specific context satisfies the
Policy [Jain: Paragraph 6 (“Sensor drivers 224 each may comprise a specialized app that performs security, admin, and management functions beyond those performed by traditional driver software. In various embodiments, sensor drivers 224 are configured to provide access to a corresponding one or more of sensors 226 via a consistent, easy-to-use, well-published API or other interface. Sensor drivers 224 may provide to apps 222 secure and/or managed access to sensors 226 and/or data provided by sensors 226. In various embodiments, sensor drivers 224 may prevent apps 222 from altering a configuration or operation of sensors 226. For example, edge agent 220 may configure sensor drivers 224 to configure, operate, and/or manage access to sensors 226 in a manner specified by a policy or other configuration data, such as administrative commands entered via an interface of management server 202. Sensor drivers 224 may serve as an input/output multiplexer for physical port (not shown in FIG. 2) of gateway 210. Sensor drivers 224 may allow administrative commands, policies, etc. to be used to control which business apps are allowed to communicate with which sensors. In some embodiments, sensor drivers such as sensor drivers 224 may be downloaded from an authorized (e.g., enterprise-managed) app store, and may be updated and/or managed in the same manner as other apps”)].
Both references (Alvarez and Jain) taught features that were directed to analogous art and they were directed to the same field of endeavor, such as data processing. It would have been obvious to one of ordinary skill in the art at the time the invention was made, having the teachings of Alvarez and Jain before him/her, to modify the system of Alvarez with the teaching of Jain in order to allow administrator to set data based on policy [Jain: Paragraph 6].
Claim 13:
Claim 13 is essentially the same as claim 5 except that it sets forth the claimed invention as a system rather than a method and rejected under the same reasons as applied above.
Claim 19:
Claim 19 is essentially the same as claim 5 except that it sets forth the claimed invention as a program product rather than a method and rejected under the same reasons as applied above.
14. Any inquiry concerning this communication or earlier communications from the examiner should be directed to [Hung D. Le], whose telephone number is [571-270-1404]. The examiner can normally be communicated on [Monday to Friday: 9:00 A.M. to 5:00 P.M.].
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Apu Mofiz can be reached on [571-272-4080]. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, contact [800-786-9199 (IN USA OR CANADA) or 571-272-1000].
Hung Le
07/28/2026
/HUNG D LE/Primary Examiner, Art Unit 2161
Prosecution Insights