DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on Jan. 12, 2026, and is made Non-Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
Examiner interviews are available by telephone or, preferably, by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. Interviews conducted solely for the purpose of “sounding out” the examiner, including by local counsel acting only as a conduit for another practitioner, are not permitted under MPEP § 713.03. The Office is strictly enforcing established interview practice, and applicants should ensure that every interview request is directed toward advancing prosecution on the merits in compliance with MPEP §§ 713 and 713.03.
For after-final Interview requests, supervisory approval is required before an interview may be granted. Each AIR should specifically explain how the After-Final Interview request will advance prosecution—for example, by identifying targeted arguments responsive to the rejection of record, alleged defects in the examiner’s analysis, proposed claim amendments, or another concrete basis for discussion. See MPEP § 713. If the AIR form’s character limits prevent inclusion of all pertinent details, Applicants may send a contemporaneous email to the examiner at James.Miller1@uspto.gov.
The examiner is generally available Monday through Friday, 10:00 a.m. to 4:00 p.m. EST.
For any GRANTED Interview Request, Applicant can expect an email within 24 hours confirming an interview slot from the dates/times proposed and providing collaboration tool access instructions. For any DENIED Interview Request, the record will include a communication explaining the reason for the denial.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on Jan. 12, 2026, has been entered.
Claim Status
The status of claims is as follows:
Claims 1–20 are pending and examined with Claims 1, 11, and 20 in independent form.
Claims 1, 10, 11, 19 and 20 are presently amended.
No Claims are presently cancelled or added.
Response to Amendment
Applicant's Amendment has been reviewed against Applicant’s Specification filed Aug. 30, 2023, [“Applicant’s Specification”] and accepted for examination.
Response to Arguments
35 U.S.C. § 103 Argument
Applicant recites the amended claims verbatim, asserts “[t]he combination of features in amended claim 1 is submitted to overcome the rejection under Lorenz, Bedard, and Cherwonka,” provide no analysis of what the cited references tach or fail to teach, and offers no explanation of how the amendments distinguish the prior art of record. 37 CFR 1.111(b).
Examiner respectfully disagrees.
The amended imitation, “wherein the plurality of information includes multi-party data associated with a plurality of parties within a processing network” is taught by prior art Lorenz. ¶ 21 (“the customer may include at least one of an issuer bank, an acquirer bank, and a third party representing either the issuer bank or the acquirer bank depending on the context of the transaction”); ¶ 48 (data warehouse 104 stores transaction data generated over the processing network including data relating to merchants, consumers, account holders, prospective customers, issuers, acquirers, and/or purchases made”); ¶ 51 (“cube allows SAD computing device 102 to receive aggregate customer data to facilitate network level monitoring” with data “mapped to CID/ICA/BIN/Product/Transaction Type, etc.”).
The amended imitation to require "join-based relationships" including "a primary join and one or more user-defined secondary joins” is taught by prior art Cherwonka. ¶ 47 (“In terms of precedence, in one example implementation native or foreign key relationships take precedence over user relationships which take precedence over system relationships.” This establishes a hierarchical join system with a primary join (foreign key) and secondary user-defined joins.); ¶ 46 (when data is added, "the system may create a join transform 216 prior to the result transform for linking the data"); ¶ 48 (“System relationships may be modified by users to correct or alter the basis for a joinder, which results in a 'user relationship'.”). Bedard at ¶ 63 similarly teaches relational models that " provide a basis for high level data languages" and at ¶ 48 describes providing " additional insight regarding the relationships between data."
The amended limitation to specify that "the results include a result corresponding to the DAX query being executed on the first data" where the first data is associated with a first party is taught by Lorenz. Lorenz clearly teaches analyzing and returning results associated with specific parties. Lorenz at ¶ 60 describes, "for Bank C, SAD computing device 102 is configured to detect money laundering activity" and at ¶ 61 states "Rule 4A is satisfied by Bank A, Rule 5A is satisfied by Bank B, and Rule 1A is satisfied by Bank C." The system generates party-specific results as shown in Lorenz at ¶ 66: "for High Risk Country Cross border activity, alerts are generated when a customer's activity at/from high risk countries exceeds the set thresholds." Bedard at ¶ 67 teaches using "DAX queries to dynamically generate a report" and at ¶ 76 teaches "input of one or more dimensions and/or hierarchies to be included in the analytical data report" which would include party-specific data.
The amended limitation that replaced "thresholds associated with the results" with "thresholds associated with the first party" is taught by Lorenz. Lorenz teaches thresholds that are specifically associated with and applied to individual parties (customers/banks). Lorenz at ¶ 55 discloses, "thresholds are finalized by a compliance team and/or SAD computing device 102 for each rule by customer type/service provider and by network type (Clearing/Debit) and are applied to rules for alert generation." Further, Lorenz at ¶ 67 teaches, "alerts are generated by SAD computing device 102 when a customer's activity exceeds set thresholds (percentage, amount, count, increase over time) for each of the rules." The alerts are customer/party-specific as shown at ¶ 98: "Customer Name: Name of the alerted customer; Customer Type: The type of customer.”
The amended limitation in Dependent Claims 10 and 19 to specify that "the first party is an issuer bank" associated with transactions in the data cube is taught by Lorenz. Lorenz explicitly teaches that the parties analyzed include issuer banks. Lorenz at ¶ 21 states, “the customer may include at least one of an issuer bank, an acquirer bank, and a third party representing either the issuer bank or the acquirer bank." The system specifically monitors issuer banks as shown in FIGS. 4A and 4B of Lorenz, which include entries for "BANK A" with "Type: Issuer" and Lorenz at ¶ 37 describes how "a financial institution called the 'issuer' or 'issuing bank' issues an account." Lorenz at ¶ 87 further teaches the system is "tailored to monitor activity specific to different types of financial institutions, such as issuers, acquirers." The issuer banks are directly associated with transaction data stored in the system as described at ¶ 48.
Examiner’s Statement of Eligibility Under 35 U.S.C. § 101
The pending claims are directed to a statutory category, recite an abstract idea exception, but integrate the abstract idea exception into a practical application. MPEP § 2106.05(e). Claims 1–20 are directed to a dynamic rule query system using DAX queries with primary and secondary join relationships to efficiently analyze multi-party transaction data within a data cube architecture. The specification explicitly identifies technical problems (¶ 33) and technical improvements (¶ 35) realized by the invention and those improvement would be recognized by a person of ordinary skill in the art. See also, ¶¶ 22, 26, 28, 34, 50, 66, 70 93. The Independent claims reflect the improvements in the following limitations:
generate a data cube including a plurality of information stored in the data cube, wherein the plurality of information includes multi-party data associated with a plurality of parties within a processing network; (reduces errors from table difference)
receive, from a user computing device associated with a user, selection data corresponding to a selection by the user of one or more rules and one or more data elements of the data cube to define a configuration and a build of the data cube; (decreased complexity and reduces processing resources)
generate a set of DAX (data analysis expressions) queries based on the one or more rules and the one or more data elements of the data cube, wherein the one or more rules and the one or more data elements represent a plurality of user- selectable options for defining a DAX query; (decreased complexity and reduces processing resources)
electronically connect the data cube to a plurality of data tables via a plurality of join-based relationships between the data cube and the plurality of data tables, wherein the plurality of join-based relationships include a primary join and one or more user-defined secondary joins, and wherein the primary join is configured to provide access to first data of the multi-party data that is present within a first data table of the plurality of data tables and associated with a first party of the plurality of parties; (reduces errors form table setup and increased accuracy)
These are meaningful limitations that are more than applying the use of the abstract idea to a computer. These limitations, in combination, are indicative of practical application. MPEP § 2106.05(e). Claims 1–20, in ordered combination, are integrated into a practical application by specifying a dynamic rule query system using DAX queries with primary and secondary join relationships to efficiently analyze multi-party transaction data within a data cube architecture. MPEP § 2106.05(e). Furthermore, as an ordered combination, the clam limitations are also not well-understood routine or conventional.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 4–12, and 14–20 are rejected under 35 U.S.C. 103 as being unpatentable over Lorenz et al. (U.S. Pat. Pub. No. 2022/0138754) [“Lorenz”] in view of Bedard (U.S. Pat. Pub. No. 2019/0286636) [“Bedard”] and further in view of Cherwonka et al. (U.S. Pat. Pub. No. 2016/0378843) [“Cherwonka”]
Regarding Claim 1, Lorenz discloses:
A dynamic rule query system for updating and generating queries, the dynamic rule query system comprising: a memory device; and at least one processor communicatively coupled to the memory device, the at least one processor programmed to:
(See at least Fig. 2A, discloses a “system”. Fig. 5 disclosing “an example configuration of a client system shown in FIG. 2A.” ¶ 13. Fig 5 further discloses a “processor 505” coupled to the “memory 510” via the indicated double arrow. Claim 1 discloses the “processor” is “programmed”. The “system” in Fig 2A contains a “transaction data warehouse 104.” The “transaction data warehouse 104 includes a plurality of databases that transmit data to SAD computing device 102 from aggregated data cubes via an automated transfer process that is also included in transaction data warehouse 104 … The cube serves as a source to build queries on SAD computing device 102 with various combinations of customer types and transactions methods for different rules (e.g., rules approved by regulators) … queries with rules logic and calculations are embedded into a layer of SAD computing device to process and generate monthly alerts which will help identify customers (e.g., issuing and/or acquiring banks) that are prone to money laundering risk.” ¶ 51.)
[ ] a data cube including a plurality of information stored in the data cube, wherein the plurality of information includes multi-party data associated with a plurality of parties within a processing network;
(See at least ¶ 21, “the customer may include at least one of an issuer bank, an acquirer bank, and a third party representing either the issuer bank or the acquirer bank depending on the context of the transaction”); ¶ 48, “data warehouse 104 stores transaction data generated over the processing network including data relating to merchants, consumers, account holders, prospective customers, issuers, acquirers, and/or purchases made”); ¶ 51, “cube allows SAD computing device 102 to receive aggregate customer data to facilitate network level monitoring” with data “mapped to CID/ICA/BIN/Product/Transaction Type, etc.”).
receive, from a user computing device associated with a user, selection data corresponding to a selection by the user of one or more rules and one or more data elements of the data cube […];
(See at least ¶ 51, “The cube serves as a source to build queries on SAD computing device 102 with various combinations of customer types and transactions methods for different rules (e.g., rules approved by regulators).” See also, ¶ 57 (SAD computing device 102 is configured to then request rule data 310 via a rule data request 308 and receive rule data 310 from database 110.” See also, Figs. 4A and 4B)
generate a set of […] queries based on the one or more rules [rule data 310] and the one or more data elements [transaction data 302/customer types] of the data cube,
(See at least ¶ 57, “SAD computing device 102 is configured to then request rule data 310 via a rule data request 308 and receive rule data 310 from database 110. In the example embodiment, rule data 310 includes data indicating and including rules to be applied to transaction data 302 in batch of transaction data 306. In some embodiments, SAD computing device 102 is configured to determine which rules included in rule data 310 are applied to which portions of batch of transaction data 306.” “The cube serves as a source to build queries on SAD computing device 102 with various combinations of customer types and transactions methods for different rules (e.g., rules approved by regulators) … queries with rules logic and calculations are embedded into a layer of SAD computing device,” ¶ 51. See also, ¶ 58.)
wherein the one or more rules and the one or more data elements represent a plurality of […] options for defining a […] query;
(See at least ¶ 57, “different rules may be applied to different portions of batch of transaction data 306.” “[A]s shown in FIGS. 4A and 4B, SAD computing device 102 may determine to apply Rule 1A (shown in FIG. 4C) to at least a portion of batch of transaction data 306. SAD computing device 102 may determine which rules to apply to which portions of batch of transaction data 306.”)
electronically connect the data cube to a plurality of data tables […];
(See at least Fig. 2B, where the data cube is connected to “a rule table” and “detail tracker table” in “a database 110”. “In one embodiment, data warehouse 104 is stored on SAD computing device 102.” ¶ 48. “In one embodiment, centralized database 110 is stored on SAD computing device 102.” ¶ 49. The data warehouse 104 and centralized database 110 being stored in the SAD is the claimed “electrically connect.” The “database may refer to … a relational database management system (RDBMS).” ¶ 31. Relational databases provide information or data relating to relationships between data in a database in their structure. Alternatively, see the rejection by Bedard infra.).
execute a […] query of the set of […] queries on the plurality of information stored in the data cube to receive results,
(See at least ¶ 58, “as shown in FIGS. 4A and 4B, SAD computing device 102 may determine to apply Rule 1A (shown in FIG. 4C) to at least a portion of batch of transaction data 306.” “When Rule 1A, as shown in FIG. 4C, is applied to transaction data by SAD computing device 102, SAD computing device 102 is configured to determine if transaction data 302 in batch of transaction data 306 satisfies Rule 1A (e.g., indicates potential money laundering activity).” ¶ 59. Figs. 4A, 4B, and 4C describe different types of possible queries. See also, ¶¶ 60, 61.)
wherein the results include a result corresponding to the DAX query being executed on the first data;
(Lorenz clearly teaches analyzing and returning results associated with specific parties (i.e., the claimed first party). Lorenz at ¶ 60 describes, "for Bank C, SAD computing device 102 is configured to detect money laundering activity" and at ¶ 61 states "Rule 4A is satisfied by Bank A, Rule 5A is satisfied by Bank B, and Rule 1A is satisfied by Bank C." The system generates party-specific results as shown in Lorenz at ¶ 66, "for High Risk Country Cross border activity, alerts are generated when a customer's activity at/from high risk countries exceeds the set thresholds."
analyze the results to determine whether one or more predetermined thresholds associated with the first party have been satisfied [alert]; and
(See at least ¶ 60, “In the example shown in FIGS. 4A and 4B, three portions of transaction data 302 (for Bank A, Bank B, and Bank C) included in batch of transaction data 306 are analyzed by SAD computing device 102.” “SAD computing device 102 generates an alert that Bank C satisfied "Both" (shown in Alert column) portions of Rule 1A.” ¶ 62; see also ¶ 24, Figs. 4A, 4B (“Alert” column).
Lorenz teaches thresholds that are specifically associated with and applied to individual parties (customers/banks). Lorenz at ¶ 55 discloses, "thresholds are finalized by a compliance team and/or SAD computing device 102 for each rule by customer type/service provider and by network type (Clearing/Debit) and are applied to rules for alert generation." Further, Lorenz at ¶ 67 teaches, "alerts are generated by SAD computing device 102 when a customer's activity exceeds set thresholds (percentage, amount, count, increase over time) for each of the rules." The alerts are customer/party-specific as shown at ¶ 98: "Customer Name: Name of the alerted customer; Customer Type: The type of customer.”)
based on a determination that at least one of the one or more predetermined thresholds have been satisfied, activate and transmit one or more alerts associated with the at least one of the one or more predetermined thresholds being satisfied to the user computing device for processing of the one or more alerts at the user computing device.
(See at least ¶ 65, “Upon determining transaction data 302 does not comply with rule data 310, SAD computing device 102 is configured to transmit an SAD output 312 (e.g., similar to or more complex than the charts shown in FIGS. 4A and 4B) to database 110. In the example embodiment, SAD computing device 102 is configured to generate a detailed report and a summarized report (as shown in FIGS. 2B and 2C).” For example, the detailed report includes all the alert outputs generated for all rules for different combination of customer types, transaction types etc. Reports and logic have been built in such a way that alerts are generated when a customer's activity exceeds the set thresholds for each of the rules. For example, for High Risk Country Cross border activity, alerts are generated when a customer's cross border activity at/from high risk countries exceeds the set thresholds. Similarly, activity is compared against customer's peer's average, to its own 3 months average and the users will be presented with the detail tracker which shows consolidated list of all alerts for past 16 months in a single master detail tracker.”)
Lorenz discloses generating a set of queries based upon the one or more rules and the one or more elements of the data cube wherein the one or more rules and the one or more data elements represent a plurality of options for defining a query and executing a query of the set of queries on the data cube to receive results. Lorenz does not disclose the query being a “DAX”-type of query. Lorenz discloses the SAD computer determines the options for defining a “DAX”-type query. E.g., Lorenz, ¶ 58. Lorenz does not disclose “user-selectable” type options for defining a “DAX”-type query. Therefore, Lorenz does not disclose but Bedard discloses:
generate a set of DAX (data analysis expressions) queries
(See at least ¶ 78, “a DAX query builder, which may construct one or more DAX queries for querying the underlying databases to generate the requested report.” See also, Title.)
wherein the one or more rules and the one or more data elements represent a plurality of user-selectable options for defining a DAX query; […] execute a DAX query of the set of DAX queries […];
(See at least ¶ 83, “the client service application may comprise a DAX/SQL service call operation that runs from a Visual Basic for applications (VBA) macro in Excel for example to invoke custom queries defined in the client service application and return the results to the macro-operation for rendering to the end user in Excel or other tabular data engine.” See also Fig. 5 and associated text ¶ 210; ¶ 66).
Primary reference Lorenz discloses the SAD device generating a query based upon the one or more rules and the one or more elements of the data cube and executing the query on the data cube to receive results. Lorenz, ¶¶ 57, 58, 59 (cited supra). The sole difference between primary reference Lorenz and the claimed subject matter is that Lorenz does not disclose the query being a “DAX”-type query or “user-selectable” type options for defining a “DAX”-type query. Lorenz is silent on the type of queries generated and executed but specifies the “SAD computing device 102 is configured to determine which rules included in rule data 310 are applied to which portions of batch of transaction data 306.” Lorenz, ¶ 57.
Secondary reference Bedard discloses generating and executing custom (user-selectable) DAX queries. Bedard, ¶¶ 78, 83, Title (cited supra). Secondary reference Bedard demonstrates that generating and executing custom (user-selectable) DAX queries was known in the prior art at the time of the invention.
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself—that is, in the substitution of the custom (user-selectable) DAX-type query of secondary reference Bedard for the generic query of primary reference Lorenz. Thus, this simple substitution of one known element for another producing a predictable result renders the claim obvious.
Lorenz discloses electronically connecting the data cube to a plurality of data tables. Lorenz does not disclose doing so via a plurality of join-based relationships between the data cube and the plurality of data tables, wherein the plurality of join-based relationships include a primary join and one or more user-defined secondary joins, and wherein the primary join is configured to provide access to first data of the multi-party data that is present within a first data table of the plurality of data tables and associated with a first party of the plurality of parties. Lorenz discloses a data cube including a plurality of information stored in a data cube. Lorenz does not disclose generating a data cube including a plurality of information stored in a data cube. Lorenz discloses receiving a selection by the user of one or more rules and one or more data elements of the data cube but not to define a configuration and a build of the data cube. Therefore, Lorenz does not disclose Cherwonka discloses:
generate a data cube including a plurality of information stored in the data cube;
(See at least Fig. 3 and associated text ¶ 35, which describes “an example data-cube builder GUI 200”.)
receive, from a user computing device associated with a user, selection data […] to define a configuration and a build of the data cube;
(See at least Fig 3 and associated text ¶ 44, “Referring still to FIG. 3, as an example of use, a user that intends to create a new data cube may drag and drop one of the tables 210a to the data cube builder interface 204, whereupon the system generates a first select transform 212a for extracting that table from the data source.”)
electronically connect the data cube to a plurality of data tables via a plurality of join-based relationships [join transform] between the data cube and the plurality of data tables [210a, 210b],
(See at least Fig. 3 and associated text ¶ 46, “Each of the selected tables 210a 210b, or other types of data from a data source, may include one or more measures and/or one or more hierarchies. Using a set of logical rules, the system may attempt, in some embodiments, to determine how best to incorporate the newly added second select transform 212b to the data cube being edited. In many cases, it is likely to be incorporated using a join transform to connect it with other data. Accordingly, in some embodiments the system may create a join transform 216 prior to the result transform for linking the data of the second select transform 212b to the current data of the data cube.”)
wherein the plurality of join-based relationships include a primary join and one or more user-defined secondary joins; and
(See at least ¶ 51, “In many cases, this involves creating a transform to link the data element to one or more other data elements already in the data cube. In some example cases, the transform may be a join, union, intersect or other such set transform.” See also, ¶ 37. See also Bedard, ¶50)
wherein the primary join is configured to provide access to first data of the multi-party data that is present within a first data table of the plurality of data tables and associated with a first party of the plurality of parties;
(See at least ¶ 47, “In terms of precedence, in one example implementation native or foreign key relationships take precedence over user relationships which take precedence over system relationships.” This establishes a hierarchical join system with a primary join (foreign key) and secondary user-defined joins. ¶ 46, when data is added, "the system may create a join transform 216 prior to the result transform for linking the data." ¶ 48 “System relationships may be modified by users to correct or alter the basis for a joinder, which results in a 'user relationship'.”. See also, Bedard at ¶ 63 similarly teaches relational models that " provide a basis for high level data languages" and at ¶ 48 describes providing " additional insight regarding the relationships between data." For Bedard, The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of this imitations.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined generate a data cube including a plurality of information stored in the data cube; receive, from a user computing device associated with a user, selection data … to define a configuration and a build of the data cube; electronically connect the data cube to a plurality of data tables via a plurality of join-based relationships between the data cube and the plurality of data tables, wherein the plurality of join-based relationships include a primary join and one or more user-defined secondary joins, wherein the primary join is configured to provide access to first data of the multi-party data that is present within a first data table of the plurality of data tables and associated with a first party of the plurality of parties as explained in Cherwonka, to the known invention of Lorenz, in the same field of invention, with the motivation to allow “real-time data visualization,” Cherwonka, ¶ 14, and “generate the data visualization requested by a user.” Cherwonka, ¶ 22. Lorentz describes the need for “collect[ing] a large amount of transaction data … [and] identif[ing] trends within the data that are indicative of money laundering activities … in real-time.” Lorenz, ¶ 4. The solution of Lorenz, in part, uses “an online analytical processing cube … to facilitate detection of money laundering and/or other suspicious activity[ ].” Lorenz, ¶ 51. The visualization system of Cherwonka would enhance understanding of the of money laundering detection system of Lorenz because it turns large amount of data into intuitive visual formats, such as visual charts or graphs making it easier to interpret patterns, relationships, and trends for money laundering activities. Cherwonka, ¶¶ 21, 86, 87, 88.
Regarding Claim 2, Lorenz, Bedard, and Cherwonka disclose:
The system of Claim 1 and the at least one processor
Lorenz does not disclose but Cherwonka discloses:
wherein the at least one processor is further programmed to: based on the configuration of the data cube, dynamically add or remove one or more of a plurality of filters associated with the one or more rules for filtering the plurality of information.
(See at least Fig. 4 and associated text ¶ 60, “the visualization 320 may be generated using an existing data cube 312 by dragging and dropping that data cube onto the visualization page 304. The user may then select a subset of the measures/hierarchies from that data cube, certain visualization parameters (filters, type of graph/chart, which elements on which axis of a graph, etc.) or manipulations (slice/dice, aggregate, etc.).” See also ¶ 58. “[B]ased on the configuration of the data cube” is met because “certain … filters” are “from that data cube.” Filters are associated with one or more rules because filters allow precise selection or exclusion of items or data based on clearly defined rules.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined the at least one processor is further programmed to: based on the configuration of the data cube, dynamically add or remove one or more of a plurality of filters associated with the one or more rules for filtering the plurality of information as explained in Cherwonka, to the known invention of Lorenz, in the same field of invention, with the motivation to allow “real-time data visualization,” Cherwonka, ¶ 14, and “generate the data visualization requested by a user.” Cherwonka, ¶ 22. Lorentz describes the need for “collect[ing] a large amount of transaction data … [and] identif[ing] trends within the data that are indicative of money laundering activities … in real-time.” Lorenz, ¶ 4. The solution of Lorenz, in part, uses “an online analytical processing cube … to facilitate detection of money laundering and/or other suspicious activity[ ].” Lorenz, ¶ 51. The visualization system of Cherwonka would enhance understanding the of money laundering detection system of Lorenz because it turns large amount of data into intuitive visual formats, such as visual charts or graphs making it easier to interpret patterns, relationships, and trends for money laundering activities. Cherwonka, ¶¶ 21, 86, 87, 88. Filters to allow precise selection or exclusion of data would enhance the detection of money laundering activities of Lorenz.)
Regarding Claim 4, Lorenz, Bedard, and Cherwonka disclose:
The system of Claim 1 and the data cube
Lorenz further discloses
wherein the data cube includes a concatenation of data from the plurality of data tables.
(See at least ¶ 31, “A database may include any collection of data including hierarchical databases, relational databases, flat file databases, object-relational databases, object oriented databases, and any other structured collection of records or data that is stored in a computer system.” A relational database is interconnected data (concatenation) stored in tables. “[B]atch of transaction data 306 may be stored as a data cube (e.g., a multi-dimensional array of values). For example, batch of transaction data 306 may include all transaction data 302 received by database 110 over a predetermined time period (e.g., one month).” ¶ 57. “[T]ransaction data includes any account, transaction, merchant, issuer, authorization, and/or clearing data associated with a transaction. Transaction data may include account identifiers (e.g., payment account numbers (PANs), bank identifier numbers (BINs), customer identification numbers (CIDs), etc.), account information (e.g., whether accounts are in good standing or bad standing), payment card types, transaction amounts, item identifiers, merchant identifiers, merchant locations, merchant category codes, issuing bank, authorization messages and/or clearing messages, transaction identifiers, etc.” ¶ 33; see also Figs. 4A, 4B.
Alternatively, see also, Cherwonka, ¶ 63, “The data cube, as described above, specifies a data process (i.e. a set of interconnected transforms), including one or more select transforms for extracting data from one or more data sources. The data cube is capable of producing a data cube result having a plurality of measures and hierarchies. The visualization request identifies a subset of those measures and hierarchies with specified parameters (e.g., filtering, sorting, and paging) and associated properties, such as missing data points.)”
For Cherwonka, the resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 4.
Regarding Claim 5, Lorenz, Bedard, and Cherwonka disclose:
The system of Claim 1, the one or more rules, and the DAX query
Lorenz further discloses
wherein the one or more rules includes a combination of rules associated with filtering, comparing, and performing calculations on the plurality of information, and the DAX query analyzes the results to determine whether or not to activate the one or more alerts.
(See at least ¶ 51 (calculations), “The cube serves as a source to build queries on SAD computing device 102 with various combinations of customer types and transactions methods for different rules (e.g., rules approved by regulators), as described herein. In some embodiments, queries with rules logic and calculations are embedded into a layer of SAD computing device to process and generate monthly alerts which will help identify customers (e.g., issuing and/or acquiring banks) that are prone to money laundering risk.” “SAD computing device 102 may determine a rule is satisfied by, as examples, comparing transaction data to predetermined thresholds (e.g., X % and Y % as described above, stored in data warehouse 104), comparing transaction data of an entity to its peer group's (e.g., similar entities) transaction data, and/or comparing transaction data of an entity to that entity's previous transaction data.” ¶ 61 (comparing). “[A]bility to refine rules using artificial intelligence and machine learning for identifying money laundering activities.” ¶ 26 (filtering).)
Regarding Claim 6, Lorenz, Bedard, and Cherwonka disclose:
The system of Claim 1 and the one or more alerts
Lorenz further discloses
wherein the one or more alerts are activated when the results exceed the one or more predetermined thresholds.
(See at least ¶ 60, “for Bank C, SAD computing device 102 is configured to detect money laundering activity based on one of processing volume (e.g., a dollar amount) in high risk countries being greater than a percentage (Min X % Threshold) of total cross border volume with a total volume in high risk countries greater than a minimum amount (Z or Min Amount) and cross border count (e.g., a number of processed transactions) percentage in high risk countries greater than or equal to a percentage (Min Y % Threshold) of total cross border count with a total cross border count in high risk countries greater than a minimum amount (V or Min Count).” Figs. 4A and 4B and associated ¶ 62, discloses in the “Alert” column whether data exceeds a threshold.)
Regarding Claim 7, Lorenz, Bedard, and Cherwonka disclose:
The system of Claim 1, the at least one processor, the user computing device, the plurality of user-selectable options, the existing DAX query
Lorenz further discloses
wherein the at least one processor is further programmed to: update an existing DAX query [dynamically generate] of the set of DAX queries in response to a communication from the user computing device, wherein the communication includes a selection by the user of one or more of the plurality of user-selectable [user’s input] options and the existing DAX query is updated based on the selection.
(See at least ¶ 84, “the client service application comprises a data manager service call operation that can be used by the client service application (e.g. Excel add-in) to dynamically generate a DAX query based on a user's input in the data manager and render the results of the Extract Query in Excel or other tabular data engine.” See also, ¶ 84; ¶¶ 109, 209 (refresh report).)
Regarding Claim 8, Lorenz, Bedard, and Cherwonka disclose:
The system of Claim 1 and the DAX query
Lorenz further discloses
wherein the DAX query is configured to determine if one or more patterns are present in transaction data included within the plurality of information stored in the data cube.
(See at least ¶ 61, “In this example, different rules are satisfied by transaction data 302 from different entities. Rule 4A is satisfied by Bank A, Rule SA is satisfied by Bank B, and Rule lA is satisfied by Bank C. In some embodiments, SAD computing device 102 is configured to apply any number of rules to any amount of transaction data 302.Different rules may be applied by SAD computing device 102 to detect, for example, high risk cross border activity, high risk merchant categories, unusual patterns, change in behavior, and/or high risk customers.”)
Regarding Claim 9, Lorenz, Bedard, and Cherwonka disclose:
The system of Claim 8 and the one or more patterns
Lorenz further discloses
wherein the one or more patterns indicate the potential presence of money laundering activity.
(See at least ¶ 60, “for Bank C, SAD computing device 102 is configured to detect money laundering activity based on one of processing volume (e.g., a dollar amount) in high risk countries being greater than a percentage (Min X % Threshold) of total cross border volume with a total volume in high risk countries greater than a minimum amount (Z or Min Amount) and cross border count (e.g., a number of processed transactions) percentage in high risk countries greater than or equal to a percentage (Min Y % Threshold) of total cross border count with a total cross border count in high risk countries greater than a minimum amount (V or Min Count).” The pattern identified is high risk cross border activity which is a potential indication of money laundering as indicated in ¶ 60.)
Regarding Claim 10, Lorenz, Bedard, and Cherwonka disclose:
The system of Claim 9, the first party, and the potential presence of money laundering activity
Lorenz further discloses
wherein the first party is an issuer bank, and the potential presence of money laundering activity is at the issuer bank, the issuer bank being associated with a plurality of transactions associated with the transaction data stored in the data cube.
(See at least ¶ 87, “the systems and methods may be tailored to monitor activity specific to different types of financial institutions, such as issuers, acquirers, Corporate and Government Institutions (CGIs), and service providers.” “[T]he data cube may be an online analytical processing cube specifically configured for SAD computing system 100 (e.g., to facilitate detection of money laundering and/or other suspicious activity). The cube allows SAD computing device 102 to receive aggregate customer data to facilitate network level monitoring.” ¶ 51.
Lorenz explicitly teaches that the parties analyzed include issuer banks. Lorenz at ¶ 21 states, “the customer may include at least one of an issuer bank, an acquirer bank, and a third party representing either the issuer bank or the acquirer bank." The system specifically monitors issuer banks as shown in FIGS. 4A and 4B of Lorenz, which include entries for "BANK A" with "Type: Issuer" and Lorenz at ¶ 37 describes how "a financial institution called the 'issuer' or 'issuing bank' issues an account." Lorenz at ¶ 87 further teaches the system is "tailored to monitor activity specific to different types of financial institutions, such as issuers, acquirers." The issuer banks are directly associated with transaction data stored in the system as described at ¶ 48.)
Regarding Claim 11, Lorenz discloses
A computer-implemented method
(See at least ¶ 6, “a computer-implemented method”.)
The remaining limitations of Claim 11 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Lorenz, Bedard, and Cherwonka for the same rationale presented in Claim 1 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 11.
Regarding Claims 12, 14, 15, 16, 17, and 18, Lorenz, Bedard, and Cherwonka disclose:
The method of Claim 11.
The remaining limitations of Claims 12, 14, 15, 16, 17, and 18, are not substantively different than those presented in Claims 2, 4, 5, 6, 7, and 8, respectively, and are therefore, rejected, mutatis mutandis, based on Lorenz, Bedard, and Cherwonka for the same rationale presented in Claims 2, 4, 5, 6, 7, and 8, respectively, supra.
Regarding Claim 19, Lorenz, Bedard, and Cherwonka disclose:
The method of Claim 18.
The remaining limitations of Claim 19 are not substantively different than those presented in the combination of Claims 9 and 10, and are therefore, rejected, mutatis mutandis, based on Lorenz, Bedard, and Cherwonka for the same rationale presented in Claims 9 and 10, supra.
Regarding Claim 20, Lorenz discloses
At least one non-transitory computer-readable storage media having computer-executable instructions embodied thereon for updating and generating queries, wherein when executed by at least one processor, the computer-executable instructions cause the at least one processor to:
(See at least Claim 16, “A non-transitory computer-readable storage medium having computer-executable instructions embodied thereon, wherein when executed by at least one suspect activity detection (SAD) computing device, including at least one processor in communication with at least one database, the computer-executable instructions cause the SAD computing device to:”
The remaining limitations of Claim 20 are not substantively different than those presented in Claim 1 and are therefore, rejected, mutatis mutandis, based on Lorenz, Bedard, and Cherwonka for the same rationale presented in Claim 1 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 1 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 20.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Lorenz, Bedard, and Cherwonka, and further in view of Groarke et al. (U.S. Pat. Pub. No. 2015/0026070) [“Groarke”]
Regarding Claim 3, Lorenz, Bedard, and Cherwonka disclose:
The system of Claim 1, the plurality of information, and the at least one processor
Lorentz further discloses
wherein the plurality of information includes historical transaction data, and
(See at least ¶ 51, “the cube includes 16 months of data relating to clearing and debit networks mapped to CID/ICA/BIN/Product/Transaction Type, etc. The cube serves as a source to build queries on SAD computing device 102 with various combinations of customer types and transactions methods for different rules (e.g., rules approved by regulators).”
Lorenz discloses a database configured to store historical transaction data. Lorenz, ¶¶ 48, 51. Lorenz further discloses the database storing historical transaction data transmitting data to an “aggregated data cube.” Lorenz, ¶ 51; Fig. 2B. Lorenz is silent on whether the historical transaction data in the database is “hashed to protect personally identifiable information included within the historical transaction data,” as claimed. Therefore, Lorenz does not disclose but Groarke discloses:
the at least one processor is further programmed to: hash the historical transaction data prior to the generation of the data cube to protect personally identifiable information included within the historical transaction data.
(See at least ¶ 5, “storing at a central store [database], personally identifiable information from an issuer for a plurality of payment card cardholders, the personally identifiable information encrypted to prevent payment card transaction data from being associated with the personally identifiable information.” See also, ¶ 18. “Examples of methods of maintaining cardholder identity data in the CIS include storing a primary account number (PAN) with a corresponding list-of-lists of one-way hashed cardholder attributes.” ¶ 19; see also ¶ 62 (“Method 600 further includes extracting 606 the PANs and other cardholder attributes from the messages and hash them. The hashed PANs and other cardholder attributes are compared 608 to local or remote stored hashed cardholder attributes.” Historical transaction data is stored and hashed in database 120. ¶ 40.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have combined hash the historical transaction data prior to the generation of the data cube to protect personally identifiable information included within the historical transaction data as explained in Groarke, to the known invention of Lorenz, in the same field of invention, with the motivation “to prevent payment card transaction data from being associated with the personally identifiable information [PII],” Groarke, ¶ 5, and to comply with “[p]rivacy laws” for PII. Groarke, ¶ 18.
Regarding Claim 13, Lorenz, Bedard, and Cherwonka disclose:
The computer-implemented method of Claim 11
The remaining limitations of Claim 13 are not substantively different than those presented in Claim 3 and are therefore, rejected, mutatis mutandis, based on Lorenz, Bedard, Cherwonka, and Groarke for the same rationale presented in Claim 3 supra.
The resolution of the remaining Graham factual inquiries to support a conclusion of obviousness that a particular known technique was recognized as part of the ordinary skill in the pertinent art is substantively the same as that presented in Claim 3 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 13.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 PM (EST).
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, Bennett M Sigmond can be reached at (303) 297-4411. 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.
/JAMES H MILLER/Primary Examiner, Art Unit 3694