Patent Application 18632114 - SYSTEM AND METHOD FOR DETERMINATION OF

Title: SYSTEM AND METHOD FOR DETERMINATION OF RECOMMENDATIONS AND ALERTS IN AN ANALYTICS ENVIRONMENT

Application Information

Invention Title: SYSTEM AND METHOD FOR DETERMINATION OF RECOMMENDATIONS AND ALERTS IN AN ANALYTICS ENVIRONMENT
Application Number: 18632114
Submission Date: 2025-04-10T00:00:00.000Z
Effective Filing Date: 2024-04-10T00:00:00.000Z
Filing Date: 2024-04-10T00:00:00.000Z
National Class: 705
National Sub-Class: 007310
Examiner Employee Number: 88378
Art Unit: 3625
Tech Center: 3600

Rejection Summary

102 Rejections: 0
103 Rejections: 6

Cited Patents

The following patents were cited in the rejection:

Office Action Text

DETAILED ACTION
This communication is a Non-Final Rejection Office Action in response to the 4/10/2024 filling of Application 18/632,114. Claims 1-20 are now presented.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Double Patenting

A rejection based on double patenting of the “same invention” type finds its support in the language of 35 U.S.C. 101 which states that “whoever invents or discovers any new and useful process... may obtain a patent therefor...” (Emphasis added). Thus, the term “same invention,” in this context, means an invention drawn to identical subject matter. See Miller v. Eagle Mfg. Co., 151 U.S. 186 (1894); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Ockert, 245 F.2d 467, 114 USPQ 330 (CCPA 1957).
A statutory type (35 U.S.C. 101) double patenting rejection can be overcome by canceling or amending the claims that are directed to the same invention so they are no longer coextensive in scope. The filing of a terminal disclaimer cannot overcome a double patenting rejection based upon 35 U.S.C. 101.
Claims 1-8 is/are rejected under 35 U.S.C. 101 as claiming the same invention as that of claims 1-10 of prior U.S. Patent No. 11,966,870. This is a statutory double patenting rejection.

Claim Rejections - 35 USC § 101

35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.

Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
When considering subject matter eligibility under 35 U.S.C. 101, in step 1 it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, in step 2A prong 1 it must then be determined whether the claim is recite a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea). If the claim recites a judicial exception, under step 2A prong 2 it must additionally be determined whether the recites additional elements that integrate the judicial exception into a practical application. If a claim does not integrate the Abstract idea into a practical application, under step 2B it must then be determined if the claim provides an inventive concept.

In the Instant case Claims 1-8 are directed toward a system for determination of recommendations and alerts for use within an analytics environment. Claims 9-16 are directed toward a method for determination of recommendations and alerts for use within an analytics environment. Claims 17-20 are directed toward a computer program product for determination of recommendations and alerts for use within an analytics environment. As such, each of the Claims is directed to one of the four statutory categories of invention.
MPEP 2106.04 II. A. explains that in step 2A prong 1 Examiners are to determine whether a claim recites a judicial exception. MPEP 2106.04(a) explains that:
To facilitate examination, the Office has set forth an approach to identifying abstract ideas that distills the relevant case law into enumerated groupings of abstract ideas. The enumerated groupings are firmly rooted in Supreme Court precedent as well as Federal Circuit decisions interpreting that precedent, as is explained in MPEP § 2106.04(a)(2). This approach represents a shift from the former case-comparison approach that required examiners to rely on individual judicial cases when determining whether a claim recites an abstract idea. By grouping the abstract ideas, the examiners’ focus has been shifted from relying on individual cases to generally applying the wide body of case law spanning all technologies and claim types.
The enumerated groupings of abstract ideas are defined as:
1) Mathematical concepts – mathematical relationships, mathematical formulas or equations, mathematical calculations (see MPEP § 2106.04(a)(2), subsection I);
2) Certain methods of organizing human activity – fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) (see MPEP § 2106.04(a)(2), subsection II); and
3) Mental processes – concepts performed in the human mind (including an observation, evaluation, judgment, opinion) (see MPEP § 2106.04(a)(2), subsection III).

As per step 2A prong 1 of the eligibility analysis, claim 1 is directed to the abstract idea of analyzing data to generate recommendations or alerts to a tenant of the plurality of tenants which falls into the abstract idea categories of certain methods of organizing human activity and mental processes.

The elements of Claim 24 that represent the Abstract idea include:

A system for determination of recommendations and alerts for use within an analytics environment, comprising:
an analytic applications environment;
wherein the historical data at each respective tenant schema is aggregated; and
wherein said queries are utilized to generate recommendations or alerts to a tenant of the plurality of tenants, based on the aggregated data warehouse instance.

MPEP 2106.04(a)(2) II. states:
The phrase "methods of organizing human activity" is used to describe concepts relating to:
fundamental economic principles or practices (including hedging, insurance, mitigating risk);
commercial or legal interactions (including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations); and
managing personal behavior or relationships or interactions between people, (including social activities, teaching, and following rules or instructions).
The Supreme Court has identified a number of concepts falling within the "certain methods of organizing human activity" grouping as abstract ideas. In particular, in Alice, the Court concluded that the use of a third party to mediate settlement risk is a ‘‘fundamental economic practice’’ and thus an abstract idea. 573 U.S. at 219–20, 110 USPQ2d at 1982. In addition, the Court in Alice described the concept of risk hedging identified as an abstract idea in Bilski as ‘‘a method of organizing human activity’’. Id. Previously, in Bilski, the Court concluded that hedging is a ‘‘fundamental economic practice’’ and therefore an abstract idea. 561 U.S. at 611–612, 95 USPQ2d at 1010.
In the instant case, the limitations of aggregating historical data and generating recommendations or alerts are directed to commercial or legal interactions including sales activities or behaviors, and business relations and fundamental economic principles such as generating recommendations to improve business operations.

MPEP 2106.04(a)(2) states:
The courts consider a mental process (thinking) that "can be performed in the human mind, or by a human using a pen and paper" to be an abstract idea. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). As the Federal Circuit explained, "methods which can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas the ‘basic tools of scientific and technological work’ that are open to all.’" 654 F.3d at 1371, 99 USPQ2d at 1694 (citing Gottschalk v. Benson, 409 U.S. 63, 175 USPQ 673 (1972)). See also Mayo Collaborative Servs. v. Prometheus Labs. Inc., 566 U.S. 66, 71, 101 USPQ2d 1961, 1965 (2012) ("‘[M]ental processes[] and abstract intellectual concepts are not patentable, as they are the basic tools of scientific and technological work’" (quoting Benson, 409 U.S. at 67, 175 USPQ at 675)); Parker v. Flook, 437 U.S. 584, 589, 198 USPQ 193, 197 (1978) (same).
Accordingly, the "mental processes" abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes include observations, evaluations, judgments, and opinions

In the instant case, the limitations aggregating historical data and generating recommendations or alerts cover performance of the limitations in the mind but for the recitation of generic computer components. That is, other than reciting “a processor” nothing in the claim element precludes the steps from being performed in the human mind.
Under step 2A prong 2 the examiner must then determine if the recited abstract idea is integrated into a practical application. MPEP 2106.04 states:

Limitations the courts have found indicative that an additional element (or combination of elements) may have integrated the exception into a practical application include:
• An improvement in the functioning of a computer, or an improvement to other technology or technical field, as discussed in MPEP §§ 2106.04(d)(1) and 2106.05(a);
• Applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, as discussed in MPEP § 2106.04(d)(2);
• Implementing a judicial exception with, or using a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim, as discussed in MPEP § 2106.05(b);
• Effecting a transformation or reduction of a particular article to a different state or thing, as discussed in MPEP § 2106.05(c); and
• Applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception, as discussed in MPEP § 2106.05(e)

The courts have also identified limitations that did not integrate a judicial exception into a practical application:
• Merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f);
• Adding insignificant extra-solution activity to the judicial exception, as discussed in MPEP § 2106.05(g); and
• Generally linking the use of a judicial exception to a particular technological environment or field of use, as discussed in MPEP § 2106.05(h).

In the instant case, this judicial exception is not integrated into a practical application. In particular, Claim 1 recites the additional elements of:
A system for determination of recommendations and alerts for use within an analytics environment, comprising:
a computer comprising one or more processors;
an analytic applications environment running on the computer, wherein the analytics application environment accesses a data warehouse for storage of data by a plurality of tenants, each of the plurality of tenants being associated with a respective tenant schema at the data warehouse;
wherein an extract, transform, load process stores data, said data comprising historical data, from source applications or transactional database environments of one or more of the plurality of tenants to each respective tenant schema at the data warehouse;
an aggregated data warehouse instance at the data warehouse; and
wherein queries are executed against the aggregated data warehouse instance

However, the computer elements (a computer comprising one or more processors) are recited at a high level of generality and given the broadest reasonable interpretation are simply generic computers performing generic computer functions. Generic computers performing generic computer functions, alone, do not amount to significantly more than the abstract idea and mere instructions to implement an abstract idea on a computer.
Further, the accessing a data warehouse, executing queries and the extract, transform, load process are recited broadly. For example, the claim does not define the tenant schema, the data warehouse instance, or the extract, transform, load process. Under the broadest reasonable interpretation the limitations amounts to data gathering and data storage which the MPEP says is insignificant pre and post solution activity (see MPEP 2106.05(g).
Viewing the generic computer elements in combination with the accessing and storing data does not add anything further than looking at the limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea.
In step 2B, the examiner must determine whether the claim adds a specific limitation other than what is well-understood, routine, conventional activity in the field - see MPEP 2106.05(d).
As discussed with respect to Step 2A Prong Two, the additional element of the processor in the claim amount to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here in 2B, i.e., mere instructions to apply an exception on a generic computer cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Further, nothing in the claim indicates that the retrieval and storage of information is anything other than conventional. See MPEP 2106.05(d) that states “Receiving or transmitting data over a network, e.g., using the Internet to gather data is conventional when claimed in a merely generic manner (see Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
Also see MPEP 2106.05(d) that states storing and retrieving information in memory is conventional when claimed in a merely generic manner (see Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93).
Further Claims 2-8 further limit the abstract idea of an analysis that can be performed mentally or certain methods of human activity that were already rejected in claim 1, but fail to remedy the deficiencies of the parent claim as they do not impose any limitations that amount to significantly more than the abstract idea itself.
Further, Claim 8 further defines the extract, transform, load process, but still amounts to mere data gathering which is insignificant pre solution activity and not beyond what is well known and conventional.
Accordingly, the Examiner concludes that there are no meaningful limitations in claims 2-8 that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself.
The analysis above applies to all statutory categories of invention. As such, the presentment of claim 1 otherwise styled as a method or computer program product, for example, would be subject to the same analysis. Therefore, Claims 9-20 are rejected for the same rational that applied to claims 1-8.
Claim Rejections - 35 USC § 103

The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.

The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 2, 5, 9, 10, 13, 17, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caputo US 20200081991 A1 in view of Siebel US 2017/0006135 A1.

As per Claim 1 Caputo teaches a system for determination of recommendations and alerts for use within an analytics environment, comprising:
a computer comprising one or more processors; (see Caputo para. 3)
an analytic applications environment running on the computer, wherein the analytics application environment accesses a data warehouse for storage of data by a plurality of tenants; (Caputo para. 20 teaches Method 300 may comprise analyzing 302 records of data exchanges of first entity 130 stored in database 140 accessible to processor 240; determining 304 a sector with which the first entity is associated by at least one of: (i) analyzing the stored records of first entity data exchanges; and (ii) analyzing input received from the first entity that identifies the sector; analyzing 306 records of data exchanges of one or more second entities 130 different from the first entity stored in database 140, to determine which of the one or more second entities data exchange records involve other entities associated with the sector, to determine sector associated one or more second entities data exchanges; analyzing 308 the stored records of the sector associated one or more second entities data exchanges to determine one or more data baselines; analyzing 310 the stored records of the first entity data exchanges to determine one or more first entity data baselines, at least one of which corresponds in type to a respective one of the data baseline(s); comparing 312 one of the one or more data baseline(s) to a corresponding one of the first entity one or more data baseline(s); identifying 314 the relevant information based on the comparison; and notifying 316 (e.g., via communication module 210) the first entity 130 of the relevant information.)
wherein an extract, transform, load process stores data, said data comprising historical data, from source applications or transactional database environments of one or more of the plurality of tenants at the data warehouse; (para. 13 teaches institutions, such as blood banks, gather vast amounts of data from various entities (such as patrons, donators, volunteers, and any other personal or business entity that may provide information or data pertaining to the entity to an institution with which it interacts). For example, financial institutions, such as retail banks, gather vast amounts of data on the data exchanges, or financial transactions, of its various personal and business entity customers. Discussed below are methods and computing devices for identifying relevant information for entities, and methods and devices for determining, and identifying information to manage, levels of risk for entities, based on information in data exchange records. Para. 22 teaches in an exemplary aspect, computing device 110 comprises a computing device of a financial institution, and first entity 130 and the one or more second entities 130 comprise customers of the financial institution. In such aspects, the data exchanges comprise financial transactions of the financial institution's customers 130, which are received over time by the computing device 110 of the financial institution over network 120, and stored in database 140. In these aspects, the steps of analyzing 302 and 306 records of data exchanges comprise analyses of historical transaction or data exchange records of the customers of the financial institution that have been stored in the financial institution's database(s) 140. Further, in such aspects, the first entity comprises a customer of the financial institution for which the computing device determines the relevant information (or, with reference to method 400 described below, for which the computing device determines, and identifies information to manage, a level of risk), and the one or more second entities that are different from the first entity comprise all other customers of the financial institution. In such aspects, at step 306, the other entities associated with the sector comprise other business customers of the financial institution that are, e.g., identified by processor 240 as transacting parties in the analyzed data exchange records that are associated with the same sector as the first entity. Further, in such aspects, the sector may comprise a business sector with which the first entity is associated. For example, the first entity may be a retail coffee shop business customer, in which case the sector with which the first entity is associated may comprise “retail”, “food and drink”, and/or “retail coffee”, for example. Further, in such aspects, the “sector associated one or more second entities data exchanges” comprise data exchange or transaction records stored in the financial institution's database 140 that involve personal or business customers other than the first entity (i.e., which do not include the first entity as any of the transacting parties of the data exchange) and which involve as a transacting party a business customer other than the first entity associated with the sector. For example, the sector associated one or more second entities data exchanges may include a transaction record between a patron and Retail Coffee Shop ABC in which the patron purchased a small coffee via a debit transaction (such as an Interac® debit transaction), and a transaction record involving Retail Coffee Shop XYZ's purchase of chairs from a furniture manufacturer; both data exchange or transaction records involve other entities (Retail Coffee Shop ABC and Retail Coffee Shop XYZ) that are not the first entity (e.g., Retail Coffee Shop 123) and belong to the same sector as the first entity (e.g., “retail coffee”). Para. 32 teaches the presently described aspects are expected to allow an institution (such as a financial institution) to identify relevant information for entities (such as the first entity described herein, which may, e.g., be a business customer of the financial institution) from its existing data exchange records, to thereby leverage its data (which may be extensive, and thus comprise “big data”) to cultivate relationships with any such first entity. For example, the identified relevant information may comprise information on the number of coffee shop customers that purchase coffee from Retail Coffee Shop ABC versus the first entity (Retail Coffee Shop 123). As another example, where the baselines compared comprise coffee bean suppliers, the analysis of the data exchange records may reveal that merchants with greater sales than the sales of the first entity are supplied by a particular coffee bean supplier, and so the relevant information may comprise an indication of the coffee bean supplier supplying the more successful coffee retailers.
wherein the historical data at each respective tenant is aggregated into an aggregated data warehouse instance at the data warehouse; and (para. 20 teaches with reference to FIG. 3, in accordance with an exemplary aspect of the present application, instructions, when executed by processor 240, cause the processor to carry out steps of method 300 for identifying relevant information for a first entity. Method 300 may comprise analyzing 302 records of data exchanges of first entity 130 stored in database 140 accessible to processor 240; determining 304 a sector with which the first entity is associated by at least one of: (i) analyzing the stored records of first entity data exchanges; and (ii) analyzing input received from the first entity that identifies the sector; analyzing 306 records of data exchanges of one or more second entities 130 different from the first entity stored in database 140, to determine which of the one or more second entities data exchange records involve other entities associated with the sector, to determine sector associated one or more second entities data exchanges; analyzing 308 the stored records of the sector associated one or more second entities data exchanges to determine one or more data baselines; analyzing 310 the stored records of the first entity data exchanges to determine one or more first entity data baselines, at least one of which corresponds in type to a respective one of the data baseline(s); comparing 312 one of the one or more data baseline(s) to a corresponding one of the first entity one or more data baseline(s); identifying 314 the relevant information based on the comparison; and notifying 316 (e.g., via communication module 210) the first entity 130 of the relevant information.
wherein queries are executed against the aggregated data warehouse instance,
(Caputo para. 26 teaches Still with reference to FIG. 3, in accordance with a further aspect of the present application, method 300 may further comprise: analyzing 320 the stored records of the other entities associated with the sector (which may comprise business entities); and identifying 322, from the analysis of the stored records of the other entities associated with the sector, one or more potential business-to-business opportunities for the first entity (which may comprise a business entity). The relevant information may then comprise the identified one or more potential business-to-business opportunities. For example, an analysis of the data exchange records of the other entities in the sector may reveal other suppliers of products similar to those purchased by the first entity, which suppliers supply the like products at comparable or lower prices than the prices paid by the first entity. As another example, such analysis may reveal that the first entity and another business entity in the sector sell complimentary products and that there may be efficiencies to be gained from a partnership between the entities.)
wherein said queries are utilized to generate recommendations or alerts to a tenant of the plurality of tenants, based on the aggregated data warehouse instance.
(Caputo para. 27 teaches in accordance with a further aspect of the present application, method 300 may further comprise: forming 324 one or more recommendations for the first entity from the analyzed records of the one or more second entities data exchanges. In this case, the relevant information may comprise the one or more recommendations. The recommendations may comprise, e.g., notifications of marketing opportunities. The relevant information may then comprise the identified one or more potential business-to-business opportunities. For example, an analysis of the data exchange records of the other entities in the sector may reveal other suppliers of products similar to those purchased by the first entity, which suppliers supply the like products at comparable or lower prices than the prices paid by the first entity.)
Caputo does not teach each of the plurality of tenants being associated with a respective tenant schema at the data warehouse However, Siebel para. 180 teaches one embodiment, the type system (e.g., in a C3 IoT Platform) may group metadata for types or type definitions into customer specific partitions, which may be referred to herein as tenants. The customer specific partitions may be further divided into sub partitions called tags. For example, a system may include a general or root partition that includes one a system partition (system tenant). The system tenant may include one or more tags. The system tenant and/or the tags of the system tenant may include a master partition for system data and/or platform metadata. As another example, the system may include a customer partition with one or more customer specific partitions (tenant for specific customer) for respective customer's companies or organizations. The tenant for the specific customer may also include one or more tags (sub partitions for the tenant). As yet a further example, a customer partition may include one or more customer tenants and the customer tenants may include one or more tags. The tags or customer tenants may correspond to data partitions to keep data and metadata for different customers. For example, the tenants and tags (with their corresponding partitions) may be used to keep metadata or data for the system or different customers separate for security and/or for access control. In one embodiment, all requests for data or types or request to write data include an identifier that identifies a tenant and/or tag to specify the partition corresponding to the request. Further, para. 445 teaches he systems employ a role based access control (RBAC) security model to enable administration personnel to configure appropriate access to their data. Roles define the functionality that a user may access while a person's group typically defines what level of data they may see. Users have the ability to share content within the organization and delegate responsibility to other individuals. Both Caputo and Siebel are directed to extracting information from data sources. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Caputo to include wherein each tenant of the plurality of tenants is associated with a customer tenancy, and a customer schema for use by the tenant in populating a data warehouse instance, wherein data associated with a particular tenant is provisioned in the data warehouse instance associated with, and accessible to, the particular tenant, in accordance with the analytic applications schema and the customer schema associated with the particular tenant as taught by Siebel to keep metadata or data for the system or different customers separate for security and/or for access control. In one embodiment, all requests for data or types or request to write data include an identifier that identifies a tenant and/or tag to specify the partition corresponding to the request (see para. 180).

As per Claim 2 Caputo does not explicitly disclose the system of claim 1, wherein the data stored from the extract, transform, load process further comprises cost information associated with products of the plurality of tenants. (Caputo para. 27 teaches in accordance with a further aspect of the present application, method 300 may further comprise: forming 324 one or more recommendations for the first entity from the analyzed records of the one or more second entities data exchanges. In this case, the relevant information may comprise the one or more recommendations. The recommendations may comprise, e.g., notifications of marketing opportunities. the relevant information may then comprise the identified one or more potential business-to-business opportunities. For example, an analysis of the data exchange records of the other entities in the sector may reveal other suppliers of products similar to those purchased by the first entity, which suppliers supply the like products at comparable or lower prices than the prices paid by the first entity.)

As per Claim 5 Caputo teaches the system of claim 2, wherein the generated recommendations or alerts comprises an expense alert provided when two entities sharing data have procured or expensed a same or similar product, but one entity has incurred significantly higher costs associated with the product. (Caputo para. 26 teaches Still with reference to FIG. 3, in accordance with a further aspect of the present application, method 300 may further comprise: analyzing 320 the stored records of the other entities associated with the sector (which may comprise business entities); and identifying 322, from the analysis of the stored records of the other entities associated with the sector, one or more potential business-to-business opportunities for the first entity (which may comprise a business entity). The relevant information may then comprise the identified one or more potential business-to-business opportunities. For example, an analysis of the data exchange records of the other entities in the sector may reveal other suppliers of products similar to those purchased by the first entity, which suppliers supply the like products at comparable or lower prices than the prices paid by the first entity. As another example, such analysis may reveal that the first entity and another business entity in the sector sell complimentary products and that there may be efficiencies to be gained from a partnership between the entities. As discussed previously, this step, and any other suitable step discussed herein, may be carried out using AI and/or ML.)

Claims 9, 10, 13 recite similar limitations to those recited in claims 1, 2, 5 and are rejected for similar reasons. Further, Caputo teaches . A method for determination of recommendations and alerts for use within an analytics environment (see Claim 11)

Claim 17, 18 recites similar limitations to those recited in claims 1, 2 and are rejected for similar reasons. Further, Caputo teaches A non-transitory computer readable storage medium having instructions thereon, which when read and executed by a computer including one or more processors cause the computer to perform the recited method (see Claim 19)

Claims 3, 11, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caputo US 20200081991 A1 in view of Siebel US 2017/0006135 A1 as applied to claim 1 and in further view of Rush US 20150213470 A1.

As per Claim 3 Caputo does not explicitly disclose the system of claim 2, wherein the generated recommendations or alerts comprises a negotiate alert provided when two entities sharing data are negotiating for similar products and similar quantities. However, Rush para. 81-84 teaches referring now to FIG. 9, an example of an implementation of a peer group information section 900 is shown. The peer group information section 900 is configured to receive and display information associated with the peer groups that negotiated previous deals the analysis firm uses to perform the competitive pricing analysis. In this way, a buyer may advantageously utilize the pricing analysis template to assess the validity of the competitive pricing analysis performed. It will be appreciated, for example, the validity of a competitive pricing analysis may depend on the age of the data and the number of peer groups used to perform the competitive pricing analysis. A competitive pricing analysis that is based on relatively more recent data may be more valid that a competitive pricing analysis that is based on relatively less recent data. Likewise a competitive pricing analysis based on deals previously negotiated by relatively more peer groups may be more valid than a competitive pricing analysis that is based on relatively fewer peer groups. The peer group information section 900, in this example includes for each component 604 in the set 602 of components input elements that receive input corresponding to: a peer group size 902 used to perform the competitive pricing analysis; a list of the industries 904 represented by the peer groups; a deal size comparison 906 between the negotiated deal and the previously negotiated deals; an age of the data 908 used to perform the competitive pricing analysis; and a deal ranking 910 that is based on the total number of peers 912 at or above the proposed offer and the total number of peers 914 below the proposed offer. The deal ranking 910 may be, for example, a deal ranking percentile. The peer group information section 900, in this example, includes input elements 902a, 902b, and 902c that receive input corresponding to the number of peer groups used to perform the competitive pricing analysis for each component 604. The peer group information section 900 also includes an interface element that displays a composite peer group size 916 which may be the average of each peer group size 902. For some competitive pricing analyses, some buyers may prefer the composite size of the peer group 916 to be around ten. The peer group information section 900, in this example, includes input elements 904a, 904b, and 904c that receive input corresponding to a list of industries represented by the peer groups for each of the components 604. The peer group information section 900, in this example, also includes interface elements that display the total number of industries 918 in each list of industries as well as an interface element that displays the composite number of industries represented 920. The composite number of industries represented 920 may be the average of the total number of industries 918 in each list. For some competitive analyses, a buyer may prefer the analysis firm to perform the competitive pricing analysis based on deals negotiated in multiple industries including the industry the buyer belongs to as well as other industries. Accordingly, a buyer may prefer the composite number of industries represented 920 to be at least two. In this way, the buyer may determine whether buyers in other industries are able to negotiate relatively better deals. Both Caputo and Rush are directed to comparing peer entities to determine cost savings possibilities. Therefore, it would have been obvious to a person having ordinary skill ion the art before the effective filed data of the Applicant’s invention to modify the teachings of Caputo to include wherein the generated recommendations or alerts comprises a negotiate alert provided when two entities sharing data are negotiating for similar products and similar quantities as taught by Rush to enhance an entities analysis of the negotiated deal by comparing it to deals that other entities have negotiated (see Rush para. 4).

Claims 11 recite similar limitations to those recited in claims 3 and are rejected for similar reasons. Further, Caputo teaches . A method for determination of recommendations and alerts for use within an analytics environment (see Claim 11)

Claim 19 recites similar limitations to those recited in claims 3 and are rejected for similar reasons. Further, Caputo teaches A non-transitory computer readable storage medium having instructions thereon, which when read and executed by a computer including one or more processors cause the computer to perform the recited method (see Claim 19)

Claims 4, 12, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caputo US 20200081991 A1 in view of Siebel US 2017/0006135 A1 as applied to claim 1 and in further view of Kadkol US 2012/0232950 A1.

As per Claim 4 Caputo does not explicitly disclose the system of claim 2, wherein the generated recommendations or alerts comprises a trend alert provided based on regular past purchases of an entity indicative of a trend in a price of a product. However, Kadkol para. 34 teaches the present invention compares the cost component model trend with the spending trend. The difference between the cost component model trend and the spending trend can be computed and compared with a pre-determined threshold. When this difference crosses the pre-determined threshold, an alert can be generated. Such an alert facilitates the purchasing professional to initiate actions such as: re-negotiate with the supplier or change the supplier if the cost component model indicates that the spending trend is higher, re-budget for the procurement if the cost component model indicates that the spending trend is below the cost component model etc. In an embodiment of the present invention which utilizes computer apparatus, the comparison can be performed substantially automatically and substantially regularly. In this embodiment the alert can be communicated to the user via email, display on computer screen and so on. Both Caputpo and Kadkol are directed to comparing spend analysis. Therefore, it would have been obvious to a person having ordinary skill ion the art before the effective filed data of the Applicant’s invention to modify the teachings of Caputo to include wherein the generated recommendations or alerts comprises a trend alert provided based on regular past purchases of an entity indicative of a trend in a price of a product as taught by Kadkol to facilitate analysis of the procurement cost vis-a-vis market dynamics of the underlying commodities. This in turn can facilitate optimizing procurement costs, projecting future procurement costs, negotiation leverage with suppliers (see Kadkol para. 5)

Claims 12 recite similar limitations to those recited in claims 4 and are rejected for similar reasons. Further, Caputo teaches . A method for determination of recommendations and alerts for use within an analytics environment (see Claim 11)

Claim 20 recites similar limitations to those recited in claims 4 and are rejected for similar reasons. Further, Caputo teaches A non-transitory computer readable storage medium having instructions thereon, which when read and executed by a computer including one or more processors cause the computer to perform the recited method (see Claim 19)

Claims 6, 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caputo US 20200081991 A1 in view of Siebel US 2017/0006135 A1 as applied to claim 1 and in further view of Nair US 20130332226 A1.

As per Claim 6 Caputo does not explicitly disclose the system of claim 1, wherein the generated recommendations or alerts is provided as an information including a computed savings for a tenant, based on the aggregated data warehouse instance. However, Nair para. 10 teaches the present invention is related to a system containing an integration of cost savings tracker and spend analyzer for calculating actual effective savings of a spend category in a procurement cycle. In the present invention, the cost savings tracker module of the system is meant for calculating different types of savings of a spend category done by the procurement department in a procurement cycle, based upon the baseline cost information, the purchase cost information of the spend category and receiving average price change market information of that spend category. Both Caputo and Rush are directed to comparing peer entities to determine cost savings possibilities. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filed data of the Applicant’s invention to modify the teachings of Caputo to wherein the generated recommendations or alerts is provided as an information including a computed savings for a tenant, based on the aggregated data warehouse instance as taught by Nair to provide users with a clear understanding of potential cost savings.

Claims 14 recite similar limitations to those recited in claims 6 and are rejected for similar reasons. Further, Caputo teaches A method for determination of recommendations and alerts for use within an analytics environment (see Claim 11)

Claims 7, 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caputo US 20200081991 A1 in view of Siebel US 2017/0006135 A1 in view of Nair US 20130332226 A1 as applied to claim 6 and in further view of Frahim US 2018/0167370 A1.

As per Claim 7 Caputo does not explicitly disclose The system of claim 6, wherein an alert service configured to generate the recommendation or alert comprises an opt in option to allow the data pipeline process to extract the data, the alert service being configurable to define an exclude list that prevents one or more tenants from having access to one or more alerts generated using the shared data. However, Frahim para. 64 teaches Each entity authorized to receive the shared data may be connected to data exchange service 500 via its own exchange connector at the edge of its local network, either as a stand-alone device or as a virtual device. For example, as shown in FIG. 5B, an exchange connector that is part of location/entity 306a may contact data exchange service using a secure protocol such as the Secure Socket Layer (SSL), Transport Layer Security (TLS), or the like, to identify itself using a unique identifier. Such an identifier may be provided offline or through another secure mechanism (e.g., to exchange connector 314 or another device associated with the entity of network 302). During use, the identifier may impose the access rules that control which of data streams 506a-506n the exchange connector of location/entity network 306a is authorized to access. Para. 66 teaches y way of example, assume that the exchange connectors of both location/entity 306a and location/entity 306n are authorized to access the information in data stream 506a. However, other locations/entities may be prevented from accessing this information. Similarly, as shown in FIG. 5C, exchange connector 320 of location/entity network 304 and the exchange connector of location/entity network 306n may be authorized to access and decrypt the information in stream 506n, while the exchange connector of location/entity network 306a cannot. In other words, data exchange service 500 may work in conjunction with the exchange connector middleware to control which IoT information is shared, how the information is shared, and with whom the information is shared. Both Caputpo and Frahim are directed to data sharing. Therefore, it would have been obvious to a person having ordinary skill ion the art before the effective filed data of the Applicant’s invention to modify the teachings of Caputo to include wherein an alert service configured to generate the recommendation or alert comprises an opt in option to allow the data pipeline process to extract the data, the alert service being configurable to define an exclude list that prevents one or more tenants from having access to one or more alerts generated using the shared data as taught by Frahim to provide a means to protect user privacy (see para. 54).

Claims 15 recite similar limitations to those recited in claims 7 and are rejected for similar reasons. Further, Caputo teaches A method for determination of recommendations and alerts for use within an analytics environment (see Claim 11)

Claims 8, 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caputo US 20200081991 A1 in view of Siebel US 2017/0006135 A1 as applied to claim 1 and in further view of Agarwal US 2011/0113467 A1.

As per Claim 8 Caputo teaches The system of claim 1,wherein an extract phase of the extract, transform, load process comprises: extracting the data from a plurality of enterprise application or database environments, (para. 13 teaches institutions, such as blood banks, gather vast amounts of data from various entities (such as patrons, donators, volunteers, and any other personal or business entity that may provide information or data pertaining to the entity to an institution with which it interacts). For example, financial institutions, such as retail banks, gather vast amounts of data on the data exchanges, or financial transactions, of its various personal and business entity customers. Discussed below are methods and computing devices for identifying relevant information for entities, and methods and devices for determining, and identifying information to manage, levels of risk for entities, based on information in data exchange records. Para. 32 teaches the presently described aspects are expected to allow an institution (such as a financial institution) to identify relevant information for entities (such as the first entity described herein, which may, e.g., be a business customer of the financial institution) from its existing data exchange records, to thereby leverage its data (which may be extensive, and thus comprise “big data”) to cultivate relationships with any such first entity. For example, the identified relevant information may comprise information on the number of coffee shop customers that purchase coffee from Retail Coffee Shop ABC versus the first entity (Retail Coffee Shop 123). As another example, where the baselines compared comprise coffee bean suppliers, the analysis of the data exchange records may reveal that merchants with greater sales than the sales of the first entity are supplied by a particular coffee bean supplier, and so the relevant information may comprise an indication of the coffee bean supplier supplying the more successful coffee retailers.)
wherein a first subset of the generated recommendations or alerts is determined based on data provided by a first enterprise application or database environment and associated with a first tenant; ; (para. 34 teaches with reference to FIG. 4, method 400 may further comprise: determining 402 the level of risk for the first entity based on the rank determined at step 334; determining 404 an amount of a contribution to the first entity based on the determined level of risk; if it is determined 405 that the rank is below (and/or the level of risk is above) a threshold, determining 406 one or more goals over a time period for the first entity for increasing the rank, the goal(s) corresponding respectively to the factor(s) from step 330 (for determining 330 the sector benchmark index and the first entity index) and relating to respective one or more measurable metrics of the first entity; measuring 408 the one or more metrics at or before expiry of the time period; determining 410 an updated first entity index based on the measured metric(s); determining 412 an updated benchmark index for the sector based on the one or more factors of the other entities; comparing 414 the updated first entity index to the updated sector benchmark index; determining 416 an updated rank against the updated benchmark index for the first entity based on the comparison; determining 418 an updated level of risk for the first entity based on the determined updated rank; and adjusting 420 the amount of the contribution to the first entity based on the determined updated risk.)
wherein a second subset of the generated recommendations or alerts is determined based on data provided by a second enterprise application or database environment and associated with a second tenant; and ; (para. 34 teaches with reference to FIG. 4, method 400 may further comprise: determining 402 the level of risk for the first entity based on the rank determined at step 334; determining 404 an amount of a contribution to the first entity based on the determined level of risk; if it is determined 405 that the rank is below (and/or the level of risk is above) a threshold, determining 406 one or more goals over a time period for the first entity for increasing the rank, the goal(s) corresponding respectively to the factor(s) from step 330 (for determining 330 the sector benchmark index and the first entity index) and relating to respective one or more measurable metrics of the first entity; measuring 408 the one or more metrics at or before expiry of the time period; determining 410 an updated first entity index based on the measured metric(s); determining 412 an updated benchmark index for the sector based on the one or more factors of the other entities; comparing 414 the updated first entity index to the updated sector benchmark index; determining 416 an updated rank against the updated benchmark index for the first entity based on the comparison; determining 418 an updated level of risk for the first entity based on the determined updated rank; and adjusting 420 the amount of the contribution to the first entity based on the determined updated risk.)
wherein an optimality rank of each tenant is determined based on the generated recommendations or alerts resulting from the data provided by each enterprise application or database environment. (see para. 34 that teaches with reference to FIGS. 3 and 4, method 400 may comprise steps 302, 304, 306, 320, 330, 332, and 334 of method 300, and transition at “A” from step 334 to the remaining steps of method 400 shown in FIG. 4. With reference to FIG. 4, method 400 may further comprise: determining 402 the level of risk for the first entity based on the rank determined at step 334; determining 404 an amount of a contribution to the first entity based on the determined level of risk; if it is determined 405 that the rank is below (and/or the level of risk is above) a threshold, determining 406 one or more goals over a time period for the first entity for increasing the rank, the goal(s) corresponding respectively to the factor(s) from step 330 (for determining 330 the sector benchmark index and the first entity index) and relating to respective one or more measurable metrics of the first entity; measuring 408 the one or more metrics at or before expiry of the time period; determining 410 an updated first entity index based on the measured metric(s); determining 412 an updated benchmark index for the sector based on the one or more factors of the other entities; comparing 414 the updated first entity index to the updated sector benchmark index; determining 416 an updated rank against the updated benchmark index for the first entity based on the comparison; determining 418 an updated level of risk for the first entity based on the determined updated rank; and adjusting 420 the amount of the contribution to the first entity based on the determined updated risk.)
Caputo does not teach wherein the data comprises enterprise-critical data extracted from behind a firewall, the enterprise-critical data including one or more of procurement prices, employee salaries, and expense reports; However, Agarwal para. 23 teaches A first level of security associated with system 10 can relate to authentication. Authentication determines whether a user is authorized to access the network and within the network, which particular applications or data the user is allowed to access. Although authentication is typically applied at the operating system level, at least a portion of the authentication process may also be applied through firewall policy modules 34a, 34b, 34c, and 34d. Once an authorized user is granted access to an application within virtual machine 12, 14, 24, or 26, the associated firewall policy module 34a, 34b, 34c, or 34d may restrict what the user can do within the application. In one example embodiment, a policy may be applied to firewall policy module 34a for human resources virtual machine 12, preventing an authorized user from transmitting (e.g., copying, pasting, moving, sending, exporting, emailing, etc.) confidential data, such as employee salary data, from human resources virtual machine 12 to another application or user, such as, for example, application suite virtual machine 24. Both Caputo and Agarwal are directed to sharing data. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the Applicant’s invention to modify the teachings of Caputo to include wherein the data comprises enterprise-critical data extracted from behind a firewall, the enterprise- critical data including one or more of procurement prices, employee salaries, and expense reports as taught by Agarwal to protect sensitive information (as suggested by Agarwal para. 19).

Claims 16 recite similar limitations to those recited in claims 8 and are rejected for similar reasons. Further, Caputo teaches A method for determination of recommendations and alerts for use within an analytics environment (see Claim 11)

Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEIRDRE D HATCHER whose telephone number is (571)270-5321. The examiner can normally be reached Monday-Friday 8-4:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Brian Epstein can be reached on 571-270-5389. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.

/DEIRDRE D HATCHER/Primary Examiner, Art Unit 3625