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 . 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.
DETAILED ACTION
The following NON-FINAL Office action is in response to App# 19216152 filed 05/22/2025.
37 CFR § 1.105 - Requirement for Information
Applicant and the assignee of this application are required under 37 CFR 1.105 to provide the following information that the examiner has determined is reasonably necessary to the examination of this application. Examiner’s search appears to suggest Applicant sold or publicly used the following products or services: #1 Anecdotes.ai, Continuous OS, #2 Anecdotes.ai, Continuous Compliance and #3 Anecdotes.ai, Continuous Risk management, as demonstrated at least the following evidence:
I. Anecdotes.ai, LTD webpages, way back machine, May19, 2023, noting annotated p.1
PNG
media_image1.png
1470
884
media_image1.png
Greyscale
II. Anecdotes.ai, LTD webpages, way back machine, May 22, 2024, noting annotated p.1
PNG
media_image2.png
1376
898
media_image2.png
Greyscale
III. Make continuous compliance easy with anecdotes Compliance OS youtube excerpt, Feb 28 2024, noting annotated transcript extracted immediately below:
PNG
media_image3.png
1472
848
media_image3.png
Greyscale
The information is required to identify products and services embodying the disclosed subject matter of cross mapping of evidence to frameworks for security compliance and identify the properties of similar products and services found in the prior art.
-> In response to this requirement, please provide any additional citation and a copy of each publication that any of the applicants relied upon to develop the disclosed subject matter that describes the applicant’s invention, particularly as to developing
For each publication, please provide a concise explanation of the reliance placed on that publication in the development of the disclosed subject matter. Specifically, the Examiner requests brochures, manuals, white papers, training materials, demos, sales presentations or the like related to the aforementioned product(s) software and/or other software directed to the cross mapping of evidence to frameworks for security compliance.
-> In response to this requirement, please provide the citation and a copy of each publication that any of the applicants relied upon to draft the claimed subject matter. For each publication, please provide a concise explanation of the reliance placed on that publication in distinguishing the claimed subject matter from the prior art.
-> In response to this requirement, please provide the names of any products or services that have incorporated the disclosed prior art of cross mapping of evidence to frameworks for security compliance.
-> In response to this requirement, please provide the names of any products or services that have incorporated the claimed subject matter.
In responding to those requirements that require copies of documents, where the document is a bound text or a single article over 50 pages, the requirement may be met by providing copies of those pages that provide the particular subject matter indicated in the requirement, or where such subject matter is not indicated, the subject matter found in applicant’s disclosure. The fee and certification requirements of 37 C.F.R. § 1.97 are waived for those documents submitted in reply to this requirement. This waiver extends only to those documents within the scope of this requirement under 37 C.F.R. § 1.105 that are included in the applicant’s first complete communication responding to this requirement. Any supplemental replies subsequent to the first communication responding to this requirement and any information disclosures beyond the scope of this requirement under 37 C.F.R. § 1.105 are subject to the fee and certification requirements of 37 C.F.R. § 1.97. The applicant is reminded that the reply to this requirement must be made with candor and good faith under 37 CFR 1.56. Where the applicant does not have or cannot readily obtain an item of required information, a statement that the item is unknown or cannot be readily obtained will be accepted as a complete response to the requirement for that item. This requirement is an attachment of the enclosed Office action. A complete response to the enclosed Office action must include a complete response to this requirement. The time period for reply to this requirement coincides with the time period for reply to the enclosed Office action, which is 3 months.
/PATRICIA H MUNSON/Supervisory Patent Examiner, Art Unit 3624
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Status of Claims
Claims 1-19 are currently pending and have been rejected as follows.
Priority
Examiner noted Applicants claiming Priority from Provisional 63651072 filled 05/23/2024.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 4,8,14,18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claims 4,14 are dependent and each recite, among others: “the criterion of the at least one control” rendering each of said claims vague and indefinite because it is unclear if
- “the criterion of the at least one control” subsequently recited in said claims 4,14 relate back to
- “a criterion” represent[ed] [by] “each” [of] “a plurality of requirements” at parent Claims 1,11.
Claims 4,14 are recommended to be amended to each recite, among others, and as an example only: a specific criterion of the at least one control.
Claims 8,18 each recite, among others: “wherein the mapping is a cross mapping of the evidence data to the plurality of frameworks in near real-time”. [bolded emphasis added].
The term “near” in the expression “near real-time” in said claims 8,18 is a relative term which renders the claim indefinite. The term “near” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree [of nearness], and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Specifically, here, one of ordinary skill in the art would not be reasonably apprised of the degree of temporal proximity or chorological nearness in the scope of the invention.
Claims 8,18 are recommended to be amended to each recite, among others, and as an example only: wherein the mapping is a cross mapping of the evidence data to the plurality of frameworks in real-time.
Clarification and/or correction is/ are required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-19 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, here abstract idea) without significantly more. The claim(s) recite(s) describe or set forth the abstract idea. Examiner points to MPEP 2106.04(a): “…examiners should identify at least one abstract idea grouping, but preferably identify all groupings to the extent possible…”.
Here, the claims recite, describe or set forth the abstract grouping of mental processes of MPEP 2106.04(a)(2) III for implementing the equally abstract methods of organizing human activities of MPEP 2106.04(a)(2) II. This is because here, the claims recite, describe or set forth computer-aided evaluation and judgement for a subsequent observation of abstract, mental processes as enumerated by MPEP 2106.04(a)(2) III ¶2 and 2106.04(a)(2) III C, such as, through the combination of collecting information, analyzing it, and displaying certain results of the collection and analysis1 as listed by MPEP 2106.04(a)(2) III A, 5th bullet point. These abstract, evaluation and judgement or analysis for subsequent observation or display are used to implement equally abstract fundamental practices and/or principles of risk mitigation, as broadly defined by MPEP 2106.04(a)(2) II A, based on legal interactions and obligations according to business relations, as broadly defined by MPEP 2106.04(a)(2) II B.
More specifically, here, the abstract evaluation or analysis and subsequent judgement of MPEP 2106.04(a)(2) III ¶2 and MPEP 2106.04(a)(2) III A, 5th bullet point are described or set forth as: “identifying a matching requirement for a first data element of the evidence data by matching the first data element to a requirement”; “mapping the matching requirement to at least one control in more than one framework of a plurality of frameworks”, narrowed by “a plurality of requirements that each represent a criterion and are shared across the plurality of frameworks”; and “determining, based on the mapping, a control state for the at least one control in more than one framework of the plurality of frameworks in response to the evidence data” at independent Claims 1,10,11, “the mapping of the matching requirement to at least one control indicates that the first data element defined by the matching requirement fulfills the criterion of the at least one control” at dependent Claims 4,14, “determining a compliance score for each of the plurality of frameworks, wherein the compliance score represents a degree of overall compliance based on a plurality of controls and their control states for each of the plurality of frameworks” at dependent Claims 5,15, “wherein the mapping is a cross mapping of the evidence data to the plurality of frameworks” at dependent Claims 8,18, “measuring a vector distance between a new criterion in the new control to the plurality of requirements” at dependent Claims 9,19.
Also here, the abstract observation or displaying certain results of the collection and analysis is described or set forth as: “generating a notification of compliance with respect to the plurality of frameworks, wherein the notification of compliance indicates a compliance and risk assessments for a tenant; and causing a display of the notification” at dependent Claims 6,16.
Further still, MPEP 2106.04(a)(2) III C is clear that:
# 1. Performing a mental process on a generic computer,
#2. Performing a mental process in a computer environment,
# 3. Using a computer as a tool to perform a mental process,
-> are still considered to recite a mental process.
It then follows that here, recitations of “a centralized requirement layer of a multi-layer data architecture” in which to perform the “matching the first data element to a requirement” as recited at independent Claims 1,10,11, and which is also recited to have equally abstract “established relationships between the plurality of requirements and a plurality of controls across the plurality of frameworks” at dependent Claims 3,13, would at most represent, along with “the multi-layer data architecture” in which to perform abstract “matching the first data element to a requirement” of independent Claims 1,10,11, and in which to icorporate[] “a new control by measuring a vector distance between a new criterion in the new control to the plurality of requirements in the centralized requirement layer in the multi-layer data architecture” at dependent Claims 9,19, computer environment, upon which the aforementioned abstract mental processes are processed which according to MPEP 2106.04(a)(2) III C #2 does not preclude the claims to recite, describe or set forth the abstract exception. The same computer-aided principle would apply to the broad recitation of “constructing a normalized data structure for a raw data of the evidence data, wherein the normalized data structure organizes criteria in the raw data as data elements” given the breadth of dependent Claims 2,12.
Also, according to MPEP 2106.04(a)(2) III D, the abstract processes also include the wide-area real-time performance monitoring system for monitoring and assessing dynamic stability of [a technological environment], as was the case in Electric Power Group, 830 F.3d at 1351 and n.1, 119 USPQ2d at 1740 and n.1. Indeed, looking closer at Electric Power Group supra, the Examiner finds that its claims were found ineligible despite accumulating and updating the measurements from the data streams and the dynamic stability metrics, grid data, and non-grid data in real time as to wide area and local area portions of the interconnected electric power.
It then follows that here recitations of “near real-time” in the expression “wherein the mapping is a cross mapping of the evidence data to the plurality of frameworks in near real-time” at dependent Claims 8,18, would similar to the legal findings in “Electric Power Group”, not preclude the current claims 8,18 to recite, describe or set forth the abstract exception.
Also, the Federal Circuit ruled in Electric Power Group, that requirement of displaying concurrent visualization of two or more types of information, '710 patent, col. 31, line 37, even if it is understood to require time-synchronized display, would still offer anything but readily available computer components. For example, MPEP 2106.04(a)(2) III C.#2. cites FairWarning IP, LLC v. Iatric Sys., Inc., 839 F.3d 1089, 120 USPQ2d 1293 (Fed. Cir. 2016) to submit that detecting misuse [interpreted as an example of lack compliance] in a computer environment, in which information regarding accesses of a patient’s personal health information was analyzed according to one of several rules (i.e., related to accesses in excess of a specific volume, accesses during a pre-determined time interval, or accesses by a specific user) to determine if the activity indicates improper access (839 F.3d. at 1092, 120 USPQ2d at 1294) was an example of performing a mental process in a computer environment. Specifically, it was found in “FairWarning” supra, that merely accessing, compiling and combining disparate information sources in a healthcare setting to make it possible to generate a full picture of a user's [i.e. patient] activity, identity, frequency of activity, and the like in a computer environment does not save the claims from patent ineligibility
In would follow that here, recitations of “via a tenant device” as in “causing a display of the notification via a tenant device”, at dependent Claims 6,16, when tested per MPEP 2106.04(a)(2) III C.#2,#3, Electric Power Group, and FairWarning would similarly represent a tool to perform the mental processes of observation or display of certain results of the collection and analysis for analogous “compliance” in a manner to meaningfully different than FairWarning supra.
Further still2, it appears that here such cross mapping as computer aided of the evaluation / analysis, judgment and observation/display and the computer environment upon which said computer aided evaluation / analysis, judgment and observation/display, are being performed for equally abstract fundamental practices and concepts, including the risk mitigating, as broadly defined by MPEP 2106.04(a)(2) II A, and/or the relationships, legal interactions and obligations, as broadly defined by MPEP 2106.04(a)(2) II B, which are summarized as “an evidence data for risk management” at preamble of independent Claims 1,10,11, and further referring to “the matching requirement to at least one control in more than one framework of a plurality of frameworks” [read in light of Original Specification ¶ [0003] 2nd-3rd sentences as guidelines or standards, i.e. SOC, HIPAA, PCI DSS], and [with respect to] “a plurality of requirements that each represent a criterion and are shared across the plurality of frameworks” [interpreted supra]; “and determining, based on the mapping, a control state for the at least one control in more than one framework of the plurality of frameworks in response to the evidence data” at independent Claims 1,10,11. Such business or regulatory relationships of MPEP 2106.04(a)(2) II B, are further set forth here as “established relationships between the plurality of requirements and a plurality of controls across the plurality of frameworks” at dependent Claims 3,13, and the mitigation of MPEP 2106.04(a)(2) II A is further set forth here as the “suggestion to mitigate risks, a suggestion to mitigate a violation, a mitigation action” at dependent Claims 7,17, “wherein the multi-layer data architecture incorporates a new control by measuring a vector distance between a new criterion in the new control to the plurality of requirements in the centralized requirement layer in the multi-layer data architecture” at dependent Claims 9,19.
The degree of computerization or automation to implement such functions, will be further and more granularly, scrutinized, granularly at the subsequent steps below. For now, for the purpose of Step 2A prong one, it is clear that, given the preponderance of legal evidence as demonstrated above, the claims’ character as a whole is undeniably abstract. Step 2A prong one.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This judicial exception is not integrated into a practical application because per Step 2A prong two, the individual, or combination, of the additional, computer-based elements are/is found, per MPEP 2106.05(f), to merely apply the above abstract idea and/or narrow the abstract idea to a field of use or technological environment per MPEP 2106.05(h).
Here, the Examiner identified the computer aids above as tools, computer environments etc. to aid performing the abstract processes as recognized above. Now, even when more granularly testing the aforementioned computerization as representative of additional, computer-based elements, the Examiner finds that its underlining “a centralized requirement layer of a multi-layer data architecture” and “the multi-layer data architecture” at Claims 1,3,9-11,13,19, “tenant device” of dependent Claims 6,16 and possibly the memory instructed processing circuity of independent Claims 10,11, when further tested per MPEP2106.05(f)(2)(i) as additional computer-based elements would merely apply, the already identified abstract, business method and its respective algorithm(s) on a computer3, including performing economic tasks [here identified above] and other tasks to receive and transmit data4. For example, MPEP 2106.05(f)(2) cited TLI Communications LLC v. AV Auto, LLC,823 F.3d 607,613,118 USPQ2d 1744, 1748 (Fed. Cir. 2016), to state that a combination of the computerized functions of a server and telephone unit, merely applies the abstract idea. The same “apply it” considerations MPEP2106.05(f)(2)(iii), (v) further refer to the capabilities of computer elements to monitor audit log data executed on a general-purpose computer [MPEP 2106.05(f)(2) iii5] tailor information and provide it to the user on a generic computer [MPEP 2106.05(f)(2)v]6.
Additionally or alternatively, the “a centralized requirement layer of a multi-layer data architecture” and “the multi-layer data architecture” of Claims 1,3,9-11,13,19, when similarly tested per MPEP 2106.05(h), could also be viewed as forms a technological environment narrowing the combination of collecting information, analyzing it, and displaying certain results of the collection and analysis7, as identified and mapped at the prior prong above.
Based on such preponderance of legal evidence, the Examiner submits that, none of the above additional elements, when tested per MPEP 2106.05(f), and/or (h), integrate the abstract idea into a practical application. Step 2A prong two.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as shown above, the additional computer-based elements merely apply the already recited abstract idea [MPEP 2106.05(f)] and/ or narrow it to a field of use or technological environment [MPEP 2106.05(h)]. Specifically, Examiner points to MPEP 2106.05 (d) II and carries over the finings tested per MPEP 2106.05 (f) and (h), and submits that here, the additional computer-based elements also do not provide significantly more. Examiner submits that the above tests show the applying of the abstract idea [MPEP 2106.05 (f)] and narrowing the abstract idea to a field of use or technological environment [MPEP 2106.05 (h)], suffice in showing that the additional computer-based elements also do not provide significantly more without having to rely on the conventionality test [MPEP 2106.05(d)]. Yet, assuming arguendo, further evidence would be required to demonstrate conventionality of the additional, computer-based elements, Examiner would further point to MPEP 2106.05(d)II demonstrating conventionality of the additional computer-based elements as follows:
- record customer’s order8 / electronic recordkeeping9, receiving or transmitting data 10
- electronically extract data11
- arranging a hierarchy of groups and sorting the information12.
Additionally, or alternatively, in the arguendo, and if necessary, the Examiner would also follow MPEP 2106.05(d) I 2. and point to the high level of generality of the claimed additional computer elements when read in light of Original Disclosure:
- Original Specification ¶ [0033] 1st sentence: “One of ordinary skill in the art would understand that the embodiments disclosed herein enable accurate and efficient compliance analysis while improving computing efficiency”.
- Original Specification ¶ [0094] reciting at high level: “The processing circuitry 510 may be realized as one or more hardware logic components and circuits. For example, and without limitation, illustrative types of hardware logic components that can be used include field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), Application-specific standard products (ASSPs), system-on-a-chip systems (SOCs), graphics processing units (GPUs), tensor processing units (TPUs), general-purpose microprocessors, microcontrollers, digital signal processors (DSPs), and the like, or any other hardware logic components that can perform calculations or other manipulations of information”.
- Original Specification ¶ [0095] reciting at high level: “The memory 520 may be volatile (e.g., random access memory, etc.), non-volatile (e.g., read only memory, flash memory, etc.), or a combination thereof”.
- Original Specification ¶ [0100] reciting: “The various embodiments disclosed herein can be implemented as hardware, firmware, software, or any combination thereof. Moreover, the software may be implemented as an application program tangibly embodied on a program storage unit or computer readable medium consisting of parts, or of certain devices and/or a combination of devices. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units ("CPUs"), a memory, and input/output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU, whether or not such a computer or processor is explicitly shown. In addition, various other peripheral units may be connected to the computer platform such as an additional data storage unit and a printing unit. Furthermore, a non-transitory computer readable medium is any computer readable medium except for a transitory propagating signal”.
In conclusion, Claims 1-19 although directed to statutory categories (“method” or process at Claims 1-9, “non-transitory medium” or computer product or article of manufacture Claims 10, and “system” or machine at Claims 11-19,) they still recite or set forth the abstract idea (Step 2A prong one), with their additional, computer-based elements not integrating the abstract idea into a practical application (Step 2A prong two) or providing significantly more than what was already found to be the abstract idea itself (Step 2B). Therefore, Claims 1-19 are patent ineligible.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claim Rejections - 35 USC § 102
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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.
Claims 1-5 and 10-15 are rejected under 35 U.S.C. 102(a)(1) based upon a public use or sale or other public availability of the invention as disclosed by:
Field et al, US 9043793 B1 by Applicant EMC Corp, hereinafter Field. As per,
Claims 1,10,11 Field teach “A method for cross mapping an evidence data for risk management, comprising”: / “A non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process, the process comprising:” / “A system for cross mapping an evidence data for risk management” (Fig.2, column 5 lines 23-62), comprising:”
- “identifying a matching requirement for a first data element of the evidence data by matching the first data element to a requirement in a centralized requirement layer of a multi-layer data architecture” (Field Figs.3-4,6,8 and column 6 lines 50-52: Associated with tenant 108 are up to N obligations for verifying up to K corresponding controls 302 of the service provider IT infrastructure 106. Each obligation is associated with the implementation of one or more controls, and each control may be associated with one or more obligations. column 8 lines 9-15: the obligation processing predicate logic can be used as mechanism to identify an application to the infrastructure, so the infrastructure can be informed of presence of the application and thereby learn its requirements, and in turn the infrastructure ensure that the application is receiving the required service level. For example, at column 9 lines 43-52: The enterprise assigns service requirements 608 for the control procedure 606. in case of cloud storage services, the service requirements specify a minimum number of copies of stored data and their respective storage locations. The service requirements 608 also identify service key performance indicators (KPIs) that indicate desired service levels or other service obligations to be enforced. These KPIs allow service delivery description without dependence on underlying technologies and products. The KPIs can thereby be decoupled from the underlying technologies and products and evolve independently of those technologies and products. column 10 lines 15-24: The obligation management system 120 is responsible for mapping the service types 612 to observation of specific infrastructure functions by obligation fulfillment element 620. The obligation fulfillment element 620 is also referred as an obligation fulfiller. The purpose of obligation fulfiller is to serve as proxy for associated control 605. It tests or otherwise checks for presence and performance of the control, and provides leverage for tenant verification of the presence and performance of that control. column 6 lines 52-57: Each obligation is associated with implementation of one or more controls, and each control may be associated with one or more obligations. Thus, there may be one-to-many or many-to-one relationships between obligations and controls. Specifically per Fig.6 below and column 11 lines 42-50: The obligation management system serve as interface between relying party and claimant, performing functions such as inference and dependency management across different obligations, across different layers of the stack)
- “mapping the matching requirement to at least one control in more than one framework of a plurality of frameworks according to the multi-layer data architecture”
(Field Fig.4 & column 7 lines 27-35 and similarly Fig.6, 608->610-1,610-2,…,610-n and
Field column 9 lines 60-65 mapping of control procedure 606 to service requirements 608, and other enterprise portions of the operations in Fig.6, implemented using an enterprise IT infrastructure management or GRC management system i.e. Archer eGRC system commercially available from RSA column 6 lines 52-57: Each obligation is associated with implementation of one or more controls, and each control may be associated with one or more obligations. Thus, there may be one-to-many or many-to-one relationships between obligations and controls.
Field column 11 lines 42-50: The obligation management system serve as interface between relying party and claimant, performing functions such as inference and dependency management across different obligations, across different layers of the stack),
- “wherein the centralized requirement layer of the multi-layer data architecture has a plurality of requirements that each represent a criterion and are shared across the plurality of frameworks”
(Field column 9, lines 43-50, 55-59: The enterprise assigns service requirements 608 for control procedure 606. For example, in the case of cloud storage services, the service requirements may specify a minimum number of copies of stored data and their respective storage locations. The service requirements 608 may also or alternatively identify service key performance indicators (KPIs) that indicate desired service levels or other service obligations to be enforced. The service requirements in Fig.6 arrangement are organized into non-overlapping service types 610-1,610-2…610-n. The service types comprise, lines of service, service packages, service offerings, or portions or combinations thereof, and associated KPIs.
Field column 11 lines 35-59: discloses example where the task of collecting, correlating, maintaining, administering and communicating the set of obligations fulfilled within the service provider environment may be performed by an obligation management system at the service provider. This system would serve to aggregate the obligations fulfilled in the service provider IT infrastructure, before these are communicated back to the relying party, in this case the tenant 108 associated with enterprise 104. The obligation management system may also serve as an interface between the relying party and the claimant. In addition, it can perform other functions such as inference and dependency management across different obligations, potentially within the same layer of the stack and also across different layers of the stack. The obligation management system may also serve to provide logical partitioning across the different tenants that are being serviced within a service provider environment. For example, if there are many tenants that are sharing resources in a multi-tenant cloud and each of these tenants wishes to verify that they can trust that service provider to fulfill a specific and possibly distinct set of obligations, then the obligation management system can perform a function of collecting the asserted obligations from the infrastructure, and correlating these according to the needs of each tenant, while also maintaining the privacy and integrity of the data for the individual tenants. Field column 11 line 64-column 12 line 4: the obligation management system provide a function of collecting the obligation info from any shared infrastructure components and combining this with any obligation assertions specific to the tenant in question, before reporting out obligation fulfillment results to tenant. other tenants in multi-tenant environment are similarly handled. column 13 line 65-column 14 line 3: a single such obligation management system is implemented on the service provider or enterprise side of boundary 112, or different portions of the single obligation management system implemented on each side, in a distributed implementation. column 6 lines 52-55: each obligation is associated with the implementation of one or more controls, and each control is associated with one or more obligations. column 7 lines 16-22: In information processing system 100, each of obligations 300 or 304 has an associated obligation fulfiller inserted or otherwise deployed as a component within the IT infrastructure of the claimant and is configured to provide evidence of the implementation of one or more of the controls responsive to an obligation assertion to establish an associated trust aspect of claimant); “and”
- “determining, based on the mapping, a control state for the at least one control in more than one framework of the plurality of frameworks in response to the evidence data”.
(Field column 6 lines 52-57: each obligation is associated with implementation of one or more controls, each control associated with one or more obligations. Thus, there may be one-to-many or many-to-one relationships between obligations and controls. column 10 lines 21-24: tests or checks for the presence and performance of the control and provides leverage for tenant verification of the presence and performance of that control. Similar column 12 lines 23-25:
Field column 10 lines 1-14: Associated with these service provider service types are 2 separate sets of service state information, configured service state 614 and current service state 616, each organized into same non-overlapping service types specific to the corresponding tenant 108. The configured service state 614 captures the intended behavior of the service provider IT infrastructure 106 based on configuration of hardware & software elements of that infrastructure. The current service state 616 captures the actual behavior of the delivered service based on observed behavior. The service states 614 and 616 reflect control evidence 618 gathered by an obligation fulfillment component 620 to verify the corresponding control 605. column 10 lines 19-24: The purpose of obligation fulfiller is to serve as a proxy for the associated control 605. It tests or otherwise checks for the presence and performance of the control, and provides leverage for tenant verification of presence and performance of that control. The obligation management system 120 is responsible for mapping the service types 612 to observation of specific infrastructure functions by the obligation fulfillment element 620.
Field column 11 lines 1-19: Referring now to Fig.8, exemplary interactions between obligations, controls and other components of information processing system 100 are shown. More specifically, a given obligation 800 is utilized to verify controls 802 using obligation fulfiller 804, to establish trust aspect 806. In this example, the obligation fulfiller utilizes two different types of control evidence 808-1 and 808-2, also denoted Control Evidence 1 and Control Evidence 2, to generate evidence 810 of obligation fulfillment. The control evidence 808-1 may be directly provided by the one or more controls 802, while the control evidence 808-2 is not directly provided by those controls. The obligation fulfiller 804 in this embodiment therefore combines different types of evidence in determining obligation fulfillment. As shown, combined evidence 810 utilizes only a subset of the two different types of control evidence 808-1 and 808-2. Although only a single trust aspect 806 is shown in the figure, it should be noted that establishment of a given level of trust in the service provider may require aggregation of multiple trust aspects
Field column 14 lines 9-11: The obligation fulfillers ensure that the relying party is receiving the service level they expect and require on an on-going basis).
PNG
media_image4.png
736
578
media_image4.png
Greyscale
Field Fig.6 in support of rejection arguments
Claims 2,12 Field teaches all the limitations at claims 1,11 above. Field further teaches:
- “constructing a normalized data structure for a raw data of the evidence data, wherein the normalized data structure organizes criteria in the raw data as data elements”.
(Field column 9 lines 36-42: control standard 604 may be a normalized expression of control 605 that satisfies regulatory controls 600 or corporate policies 602, while control procedure 606 is a specific expression of process that implements control standard 604 specific to one or more applications, information sets, or other resources. For example, at column 4 lines 38-42: An Obligation is specific to details of an application without modifying the underlying application code, which is read in light of Specification ¶ [0069] last sentence as example of raw data).
Claims 3,13 Field teaches all the limitations at claims 1,11 above. Field further teaches:
- “wherein the centralized requirement layer has established relationships between the plurality of requirements and a plurality of controls across the plurality of frameworks”
(Field column 13 line 65-column 14 line 3: a single such obligation management system is implemented on the service provider or enterprise side of boundary 112, or different portions of the single obligation management system implemented on each side, in a distributed implementation. column 10 lines 15-24: obligation management system 120 is responsible for mapping the service types 612 to observation of specific infrastructure functions by the obligation fulfillment element 620. The obligation fulfillment element 620 is also referred as an obligation fulfiller. The purpose of the obligation fulfiller in the present embodiment is to serve as a proxy for the associated control 605. It tests or otherwise checks for the presence and performance of the control, and provides leverage for tenant verification of the presence and performance of that control. column 6 lines 52-57: Each obligation is associated with implementation of one or more controls, and each control may be associated with one or more obligations. Thus, there may be one-to-many or many-to-one relationships between obligations and controls).
Claims 4,14 Field teaches all the limitations at claims 1,11 above. Field further teaches:
- “wherein the mapping of the matching requirement to at least one control indicates that the first data element defined by the matching requirement fulfills the criterion of the at least one control” (Field column 6 lines 50-52: Associated with the tenant 108 are up to N obligations for verifying up to K corresponding controls 302 of the service provider IT infrastructure 106. Each obligation is associated with implementation of controls, and each control may be associated with one or more obligations. Similarly, column 6 line 66- column 7 line 6. Also, column 7 lines 26-29: In Fig.4, obligation processing predicate logic 400 controls a mapping between obligation assertions 402-1,2…N and corresponding trust aspects 404-1,2…N of the claimant. Similarly, column 10 lines 14-19: obligation management system 120 responsible for mapping the service types 612 to observation of specific infrastructure functions by the obligation fulfillment element 620. The obligation fulfillment element 620 is also referred to herein as obligation fulfiller. column 11 lines 51-59: if there are many tenants sharing resources in a multi-tenant cloud and each of these tenants wishes to verify that they can trust that service provider to fulfill a specific and possibly distinct set of obligations, then the obligation management system perform a function of collecting the asserted obligations from the infrastructure, and correlating these according to the needs of each tenant, while also maintaining the privacy and integrity of the data for the individual tenants. column 12 lines 23-26: obligation management system tracks obligation fulfillers known to produce good results. Thus the system maintain white list of obligation fulfiller components).
Claims 5,15 Field teaches all the limitations at claims 1,11 above. Field further teaches:
- “determining a compliance score for each of the plurality of frameworks, wherein the compliance score represents a degree of overall compliance based on a plurality of controls and their control states for each of the plurality of frameworks”.
(Field column 3 lines 43-49: The control verification functionality allows the enterprise to establish a quantified level [or score] of trust in the service provider, so as to facilitate satisfaction of compliance requirements of the enterprise as well as other operating goals of the enterprise such as verifying the proper provisioning of services in accordance with established service level agreements. column 7 lines 39-47: The specific logic for computing what combination or sequence of obligation assertions is required to establish a specific level [or score] or aspect of trust in the service provider may vary depending upon the requirements of a given embodiment.
In alternative embodiments, the obligation processing predicate logic 400 may be replaced with other types of rules or algorithms for describing the criteria for a combination of obligations to satisfy a defined trust aspect. column 11 lines 17-19: establishment of a given level [or score] of trust in the service provider may require aggregation of multiple trust aspects. For example, at column 11 lines 6-16: the obligation fulfiller utilizes two different types of control evidence 808-1 and 808-2, also denoted Control Evidence 1 and Control Evidence 2, to generate evidence 810 of obligation fulfillment. The control evidence 808-1 may be directly provided by the one or more controls 802, while the control evidence 808-2 is not directly provided by those controls. The obligation fulfiller 804 in this embodiment therefore combines different types of evidence in determining obligation fulfillment. As shown, the combined evidence 810 utilizes only a subset of the two different types of control evidence 808-1 and 808-2. Although only a single trust aspect 806 is shown in the figure, it should be noted that establishment of a given level [or degree] of trust in the service provider may require aggregation of multiple trust aspects).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Rejections under 35 § U.S.C. 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 6-7 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over
Field as applied to claims 1,11, and in view of
Cabrera et al, US 20150347759 A1 hereinafter Cabrera. As per,
Claims 6,16 Field teaches all limitations at claims 1,11 above. Field further teaches or suggests:
- “generating a notification of compliance with respect to the plurality of frameworks, wherein the notification of compliance indicates a compliance and risk assessments for a tenant”;
(Field column 1 lines 30-31: perform governance, risk management and compliance (GRC) audits. column 9 lines 57-63: The service types comprise, for example, lines of service, service packages, service offerings, or portions or combinations thereof, and any associated KPIs. The mapping of control procedure 606 to the service requirements 608, and other enterprise portions of the operations in Fig.6, implemented the GRC [governance, risk management and compliance] management system. Specifically, per column 10 lines 19-24: obligation fulfiller tests or otherwise checks for presence and performance of the control, and provides leverage for tenant verification of presence and performance of that control and provide the tenant with required representations [or notifications] for the presence and performance of the control(s). column 11 lines 51-59: if there are many tenants sharing resources in a multi-tenant cloud and each of these tenants wishes to verify they can trust that service provider to fulfill a specific and possibly distinct set of obligations, then the obligation management system perform collecting the asserted obligations from the infrastructure, and correlating these according to the needs of each tenant, while also maintaining privacy and integrity of the data for individual tenants. column 11 line 65- column 12 line 4: the obligation management system collecting obligation information from any shared infrastructure components and combining this with any obligation assertions that are specific to the tenant in question, before reporting out obligation fulfillment results to that tenant. The other tenants in the multi-tenant environment are handled in a similar manner. column 12 lines 23-26: The obligation management system configured to track obligation fulfillers known to produce good results. Thus, the system may maintain a white list of obligation fulfiller components
Field Figs.11A-D, column11 lines 35-42: The task of collecting, correlating, maintaining, administering and communicating the set of obligations fulfilled within the service provider environment may be performed by an obligation management system at the service provider. This system would serve to aggregate the obligations fulfilled in the service provider IT infrastructure, before these are communicated back to the relying party, in this case tenant 108) “and”
* However *
Field might suggest but does not explicitly recite:
- “causing a display of the notification via a tenant device” as claimed.
* Nevertheless *
Cabrera in analogous matching potential security or risk threats with solutions and providing subsequent notifications of compliance teaches or suggest:
- “causing a display of the notification via a tenant device”
(Cabrera ¶ [0039] 1st sentence: An asset service provider may require that a tenant of the service provider's assets comply with one or more security-related criteria before or while hosting an application on the surface provider's assets. ¶ [0062] last sentence: The threat model generator 141, while hosted by the security service provider computing environment 160, can be configured to communicate with the security threat policy manager 142 and other components within the asset service provider computing environment 140, to provide a fully integrated threat modeling product to users, such as the tenant 121 and/or the developer 122. For example, at
Cabrera Fig.3, ¶ [0082] At block 410, the computing environment provides a threat model includes a report that identifies components of the application that have been sufficiently secured, and identifies components of the application that have been insufficiently secured, from the security threats. The report include one or more tables, graphs, diagrams, charts, or other visual displays or representations of: the application (or components thereof); the security threats; and the security status of the application with regard to each of the security threats. In other embodiments, the report include a list of components of the application and suggested or recommended remedial actions for improving the security of the components against attack from one or more particular security threats. As will be understood by those of skill in the art, other implementations of the threat model may include various other combinations of the application, components of the application, indications of the level of security for the components of the application, suggested remedial actions, modifications or fixes to the application to improve its security, and/or a list of security threats to which the application may be susceptible.
Cabrera mid- ¶ [0071]: example entries in the security status column 312 include: pass, fail, weak, strong, secured, not secured, and the like, according to various embodiments. The suggested action column 313 can be used by the asset service provider computing environment 140 to assist the developer 122 to update or modify the application to satisfy the standards or requirements set forth by the asset service provide. Similarly, ¶ [0072] The threat strength indicators 329 include: pass, fail, weak, strong, okay, sufficient, insufficient, adequate”, inadequate, or the like. In some embodiments, threat model diagram 320 is color-coordinated so that: security threats that have been sufficiently protected against are highlighted in green; security threats that have been insufficiently protected against are highlighted in red; and/or security threats that are marginally protected against are highlighted in yellow),
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention to have modified Field’s method/system to have included Cabrera’s teaching or suggestion in order to have further enable automating threat model generation for application developers (Cabrera ¶ [0002] in view of MPEP 2143 G) while mitigating the time-consuming procedure that adds procedural burdens or distractions that are above and beyond the substantive need to develop the application itself (Cabrera ¶ [0001] in view of MPEP 2143 G).
The predictability of such modification would have been further corroborated by the broad level of skill of one of ordinary skills in the art as further articulated by Field column 14 lines 36-50 in view of Cabrera ¶ [0011]-¶ [0012], ¶ [0082], ¶ [0087]-¶ [0088], ¶ [0092], ¶ [0096].
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of endeavor dealing with matching of threats, requirements etc.. In such combination each element would have merely performed same analytical and reporting or display function as separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Field in view of Cabrera, the to be combined elements would have fitted together like puzzle pieces in logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
Claims 7,17. Field / Cabrera teaches all the limitations at claims 6,16 above. Furthermore,
Field does not explicitly recite: “wherein the notification includes at least one of: a suggestion to mitigate risks, a suggestion to mitigate a violation, a mitigation action, a compliance score, a list of controls, and their control state” as claimed. However,
Cabrera in analogous matching potential security or risk threats with solutions teaches/suggest: “wherein the notification includes at least one of: a suggestion to mitigate risks, a suggestion to mitigate a violation, a mitigation action” (Cabrera Fig.3 and ¶ [0071] 2nd sentence: threat model table 310 includes, multiple columns and rows that identify parts of the application, the sufficiency of the security of each part of the application, and recommended or suggested actions to take for insufficiently secured parts of the application. ¶ [0071] 10th sentence: the suggested action column 313 for the API D includes a recommendation for adding support for multiple connections to the application to provide additional protection against denial of service attacks. ¶ [0082] 3rd sentence: the report can include a list of components of the application and suggested or recommended remedial actions for improving the security of one or more of the components against attack from one or more particular security threats), “a compliance score, a list of controls, and their control state” (Cabrera Fig.3, ¶ [0071] 6th sentence: as shown, example entries in the security status column 312 include, pass, fail, weak, strong, secured, not secured. ¶ [0072] 4th-6th sentences: Associated with each illustrated security threat and the application are threat strength indicators 329. The threat strength indicators 329 can include, but are not limited to, pass, fail, weak, strong, okay, sufficient, insufficient, adequate, inadequate, or the like. In some embodiments, the threat model diagram 320 is color-coordinated so that: security threats that have been sufficiently protected against are highlighted in green; security threats that have been insufficiently protected against are highlighted in red; and/or security threats that are marginally protected against are highlighted in yellow, according to one embodiment.
Rationales to have modified/combined Field / Cabrera are above and reincorporated.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 8-9 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over:
Field as applied to claims 1,11, and in view of
Duchin et al US 20200143388 A1 by Applicant EMC Corp hereinafter Duchin. As per
Claims 8,18 Field teaches all the limitations at claims 1,11 above.
Field teaches: “wherein the mapping is a cross mapping of the evidence data to the plurality of frameworks in
(Field Fig.4,column 7 lines 27-35 and similarly Fig.6, 608->610-1,610-2,…,610-n and
Field column 9 lines 60-65 map control procedure 606 to service requirements 608, and other enterprise portions of the operations in Fig.6, implemented using an enterprise IT infrastructure management or GRC management system i.e. Archer eGRC system commercially available from RSA column 6 lines 52-57: Each obligation is associated with implementation of one or more controls, and each control may be associated with one or more obligations. Thus, there may be one-to-many or many-to-one relationships between obligations and controls.
Field column 11 lines 35-59: collecting, correlating, and communicating the set of obligations fulfilled within the service provider environment… if there are many tenants that are sharing resources in a multi-tenant cloud and each of these tenants wishes to verify that they can trust that service provider to fulfill a specific and possibly distinct set of obligations, then the obligation management system can perform a function of collecting the asserted obligations from the infrastructure, and correlating these according to the needs of each tenant, while also maintaining the privacy and integrity of the data for the individual tenants)
* However *
Field does not explicitly recite: “wherein the mapping is a cross mapping of the evidence data to the plurality of frameworks in near real-time” as claimed [emphasis added].
* Nevertheless *
Duchin in analogous mapping between regulations and controls teach/suggest:
- “wherein the mapping is a cross mapping of the evidence data to the plurality of frameworks in near real-time” (Duchin ¶ [0048] 2nd-3rd sentences: … the servers 205 perform the required algorithms, analytics and training herein (high level step 2) and calculate probability of mapping each new authoritative source 206 to existing control 231. Recommendations for mapping the new authoritative sources 206 to existing controls 231 and/or determinations that new controls must be developed for one or more of the new authoritative sources are transmitted to the client device 202 (high level step 3). Specifically, per ¶ [0051] the recommendation services performed by the compliance management platform 110 can be performed based on real-time data from multiple sources retrieved over the network(s) 104, so that the information processing system can react to events as they happen. For example, the input data sources may include new authoritative sources captured in real-time, which may be processed by the compliance management platform 110 to generate recommendations for the end users of the client devices 102 reflecting real-time authoritative source updates).
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modified Field’s teachings to have included Duchin’s teachings in order to have allowed for more efficient and accurate analysis of new or updated authoritative sources in connection with the current controls of an enterprise (Duchin ¶ [0005] in view of ¶ [0083]-¶ [0087], MPEP 2143 G and/or F). The predictability of such modification would have been further corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Field column 14 lines 36-50 in view of Duchin ¶ [0114].
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of endeavor dealing with mapping between regulations, controls etc. In such combination each element would have merely performed same analytical, correlation or mapping function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements as evidenced by Field in view of Duchin, the to be combined elements would have fitted together, like puzzle pieces in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the combination results would have been predictable (MPEP 2143 A).
Claims 9,19. Field teaches all the limitations at claims 1,11 above.
Field does not recite: wherein the multi-layer data architecture incorporates a new control by measuring a vector distance between a new criterion in the new control to the plurality of requirements in the centralized requirement layer in the multi-layer data architecture as claimed
Duchin however in analogous mapping between regulations & controls teach/suggest
- “wherein the multi-layer data architecture incorporates a new control by measuring a vector distance between a new criterion in the new control to the plurality of requirements in the centralized requirement layer in the multi-layer data architecture”
(Duchin ¶ [0034] 1st, 4th sentences: using the existing mapping between authoritative sources and controls, training module 122 generates a mapping training set and a mapping validation set. the features include, but not necessarily limited to: (i) similarities between existing authoritative sources to which the determined controls are mapped; (ii) a ranking based on similarities in …(viii) a total number of existing authoritative sources to which a determined control has been mapped; and (ix) a total length (e.g., in words) of a determined control. For example,
Duchin Fig.3 steps 353, and 354 find similar authoritative sources and controls to select control candidates at step 356. To this end at ¶ [0067] 1st sentence: new authoritative sources… are converted into vector representations (352). For example, per ¶ [0041]: similarity computation module 125 computes a final similarity score between the new authoritative source and each existing control from the respective similarity scores corresponding to each level. In accordance with an embodiment, the similarity computation module 125 uses the similarity score between the existing controls and the lowest level available in the new authoritative source as the final similarity score. For example, vectorization module 121 converts a lowest level of the new authoritative source into a vector representation using a controls vector conversion module that was constructed during training. Then, similarity computation module 125 computes a similarity score between the vector representation of the lowest level of the new authoritative source and the vector representations of the existing controls as the final similarity scores. Alternatively, in other non-limiting examples, the similarity computation module 125 computes the average of the similarity scores between the existing controls and the authoritative source levels, uses the median similarity score between the existing controls and the authoritative source levels or uses the maximum similarity score as the final similarity score).
Rationales to have modified/combined Field / Duchin are above and reincorporated.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Conclusion
This Office action has an attached requirement for information under 37 C.F.R. § 1.105. A complete response to this Office action must include a complete response to the attached requirement for information. The time period for reply to the attached requirement coincides with the time period for reply to this Office action.
Following art is made of record and considered pertinent to Applicant’s disclosure:
- Christopher Michael, FISMA Management, Getting Value from Compliance, Computer Associates, august 2006
- WO 2015183697 A1 teaching Automating the building of threat models for the public cloud
- US 20230177435 A1 reciting at ¶ [0059] 1st sentence: The conventional end-to-end continuous compliance processing as depicted in FIG. 7 is augmented according to this disclosure to enable the system to seamlessly integrate customer-specified requirements and their associated artifacts,
- US 20090265209 A1 reciting at ¶ [0085] last sentence: As an example and not by way of limitation, such a directory of requirements 126 could be the "Unified Compliance Framework" provided by Network Frontiers, LLC.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OCTAVIAN ROTARU whose telephone number is (571)270-7950. The examiner can normally be reached on 571.270.7950 from 9AM to 6PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICIA H MUNSON, can be reached at telephone number (571)270-5396. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/OCTAVIAN ROTARU/
Primary Examiner, Art Unit 3624 A
July 12th, 2026
1 Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016);
2 MPEP 2106.04(a): “…examiners should identify at least one abstract idea grouping, but preferably identify all groupings to the extent possible…”.
3 Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 573 U.S. 208, 223, 110 USPQ2d 1976, 1983 (2014);
Versata Dev Group, Inc v SAP Am Inc 793 F.3d 1306,1334,115 USPQ2d 1681, 1701 (Fed Cir 2015)
4 Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone);
TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016)
Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015).
5 FairWarning IP, LLC v. Iatric Sys., 839 F.3d 1089, 1095, 120 USPQ2d 1293, 1296 (Fed. Cir. 2016);
6 Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370-71, 115 USPQ2d 1636, 1642 (Fed. Cir. 2015)
7 Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016);
8 Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1244, 120 USPQ2d 1844, 1856 (Fed. Cir. 2016)
9 Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755
10 Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362; TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014)
11 Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014)
12 Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1331, 115 USPQ2d 1681, 1699 (Fed. Cir. 2015).
Prosecution Insights