DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on May 12, 2026, and is made 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
Interviews are “indispensable to advance the prosecution of a patent application.” MPEP § 713. Accordingly, the following Examiner’s guidance and suggested workflow maximizes this benefit to Applicant by: (1) avoiding back and forth telephone calls for scheduling, (2) permitting Examiner out-of-office notifications to the Applicant when emailing the agenda, and (3) permitting real-time document collaboration and screen sharing.
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. If an interview is needed more quickly than permitted by the AIR scheduling tool, note this in the AIR remarks for consideration. The Examiner routinely considers such urgent requests when practicable.
An agenda submitted when filing the AIR is strongly encouraged, because Examiners use agendas when determining whether to grant an interview. The AIR has character limits, so send the agenda contemporaneously to James.Miller1@uspto.gov and reference the AIR.
After-Final Interviews Requests are granted only at the Examiner’s discretion and only if disposal or clarification for appeal may be accomplished with only nominal further consideration. MPEP § 713.09. An advance agenda explaining how the interview advances prosecution—e.g., through targeted arguments, identified Examiner error, or proposed claim amendments—is strongly suggested.
For GRANTED requests, expect an email within two (2) business days confirming a date/time slot and collaboration tool access instructions. For DENIED requests, the record will include an explanation for the denial.
The examiner is generally available for interviews, Monday through Friday, 10:00 a.m. to 4:00 p.m. ET.
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 .
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, 7, 11, 17, 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’s arguments with respect to Claims 1–20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Examiner’s Statement of Eligibility Under 35 U.S.C. § 101
The pending claims are directed to a statutory category and recite an abstract idea of evaluating transaction data using rules and presenting results of the evaluation. However, the claims as a whole integrate the judicial exception into a practical application because they recite a particular technological implementation for configuring, querying, and updating a multi-table data cube system. MPEP §§ 2106.04(d); 2106.05(a).
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 including increased accuracy of analysis, reduced errors from table set up differences, reduced computer processing resources and decreased complexity in analyzing significant amounts of data. Spec. ¶ 33. The specification describes a computer-based solution using a dynamic rule query server and engine to process and analyze datasets in reduced time. Spec. ¶ 35.
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;
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;
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;
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;
based on a communication from the user computing device indicating that the result did not include manipulated first data as intended by the DAX query, cause a portion of the one or more of the data fields of the one or more data elements to be dynamically updated to consolidate column data from the plurality of data tables; generate an updated DAX query based on the dynamically updated portion of the one or more data fields of the one or more data elements.
These are meaningful limitations that are more than applying the use of the abstract idea to a computer. As a whole and in combination, the limitations apply the recited data evaluation through a particular data cube and DAX query architecture that configures, links, and updates data fields/elements across multiple tables for analysis of large multi-party datasets, rather than merely reciting data evaluation using generic computer components. MPEP §§ 2106.04(d), 2106.05(a); Spec. ¶¶ 33, 35.
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–6, 8–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”] and further in view of Fagin et al. (U.S. Pat. Pub. No. 2003/0217069) [“Fagin”]
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.”).
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, wherein each of the one or more data elements includes one or more data fields;
(Lorenz discloses the cube is used to build queries using “various combinations of customer types and transactions methods for different rules (e.g., rules approved by regulators)” and contains customer data “mapped to CID/ICA/BIN/Product/Transaction Type, etc.” ¶ 51. “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. The query data elements are represented by and include one ore more transaction data fields. See also, ¶¶ 57, 58.)
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”. The “database may refer to … a relational database management system (RDBMS).” ¶ 31. Alternatively, see Cherwonka, infra, ¶¶ 45, 46, 50, 51, which discloses adding selected tables/data elements to the data cube and linking the added table data to current cube data by a join transform.).
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."
[…]
execute the updated [ ] query on the plurality of information stored in the data cube to determine whether one or more predetermined thresholds associated with the first party have been satisfied
(This limitation is mapped for the same reasons as in the prior limitation, supra. See at least ¶ 55, “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.” ¶ 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,” and that “different rules are satisfied by transaction data 302 from different entities.” ¶ 61. ¶ 67, “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.” ¶ 62, SAD computing device 102 generates an alert that Bank C satisfied "Both" (shown in Alert column) portions of Rule 1A.” See also ¶ 24, Figs. 4A, 4B (“Alert” column).
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 rule-based queries but does not identify “DAX” as the query language. 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 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.
Lorenz discloses “an operator of user computing device 106 may provide feedback regarding SAD output 312 … [that] some of the alerts … did not accurately identify money laundering activity” and when this happens, the “SAD computing device 102 is configured to modify rules and or rule data 310 based on the feedback data (e.g., by using artificial intelligence techniques). Lorenz, ¶ 69. Lorenz does not disclose that the result did not include manipulated first data as intended by the [DAX] query (missing data). Thus, Lorenz does not disclose but Fagin discloses:
based on a communication from the user computing device indicating that the result did not include manipulated first data as intended by the [ ] query, cause a portion of the one or more of the data fields of the one or more data elements to be dynamically updated to consolidate column data from the plurality of data tables; generate an updated [ ] query based on the dynamically updated portion of the one or more data fields of the one or more data elements;
(Fagin teaches “[t]he ultimate goal of schema mapping is … to extract the correct data from the source to populate the target schema … If a query or transformation is incomplete or incorrect, there is typically no support for refining and correcting it. The user is expected to have a thorough understanding of the data source and to debug complicated SQL queries or procedural transformation programs by hand.” ¶ 11. Fagin uses visual “illustrations” or “schema mappings” (¶¶ 18, 113) and “[a]fter examining an illustration of a mapping, a user may invoke a mapping modification operator which creates a new mapping or set of new alternative mappings.” ¶ 114. Fagin “provides a set of data linking operators, which directly change the query graph of the mapping. … However, the user does not need to undertake the daunting task of specifying the structure of the new query graph or changes to the current graph. Rather, the user may use data to invoke these operators by indicating what source 205 data is missing from the current illustration.” ¶ 115. “[When] the user knows where the missing data resides in the source 205 or what source 205 relation(s) specifically contain this data … system 10 infers possible ways of augmenting the query graph to include the new data and illustrates each new mapping alternative, for example, each alternative join path.” ¶ 116. Thus, Lorenz discloses user feedback concerning inaccurate output and Fagin discloses user identification of source data missing from a current mapping and augmentation of the query to include that data.
Fagin also discloses the claimed “consolidate column data from the plurality of data tables” by mapping data from “multiple source rows in multiple source tables to a combined row in the target table.” ¶ 31. The user may invoke “data linking operators” “by indicating what source 205 data is missing from the current illustration” (¶ 115) and that when a user knows where the missing data is located, the system “infers possible ways of augmenting the query graph to include the new data and illustrates each new mapping alternative, for example, each alternative join path.” ¶ 116.
Bedard discloses the DAX-specific implementation of Fagin’s revised mapping/query. “[T]he report designer may allow a user to dynamically set up the structure of a report/template, such as rows, columns, slicers, filters, properties, or the like … [and] allow input of one or more dimensions and/or hierarchies to be included in the analytical data report.” ¶ 75. “[C]onstructing, by the report generator in conjunction with a Data Analysis Expression (DAX) query builder, one or more DAX queries based on the received one or more analytical report parameters and/or the one or more structural component inputs of the requested analytical report; querying one or more tabular databases and/or one or more relational star schemas using the constructed DAX queries.” ¶ 8; see also ¶ 78. “[T]he reporting service communicates the elements of a report request (including, e.g. report parameters, format, data structure, etc.) to the report generator and/or a DAX query builder, which may construct one or more DAX queries for querying the underlying databases to generate the requested report.” ¶ 78. “[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.” ¶ 84.
Cherwonka discloses adding new data elements to a data cube by adding new or modifying existing transforms, including join transforms, to link the new data to an existing data cube. Cherwonka ¶¶ 45–48.
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 Fagin’s user directed mapping and data refinement technique for identifying source data missing from a current mapping with the multi-table data cube system of Cherwonka and the dynamic DAX query generation system of Bedard, as applied to Lorenz’s party specific transaction analysis. Lorenz discloses user feedback concerning inaccurate output. Lorenz, ¶ 69. Fagin discloses user identification of source data missing from a current mapping and augmentation of the query to include that data. Fagin, ¶¶ 114–116. Lorenz discloses user feedback concerning inaccurate output. Lorenz, ¶ 69. Cherwonka discloses adding new data elements to a data cube by adding new or modifying existing transforms, including join transforms, to link the new data to an existing data cube. Cherwonka, ¶¶ 45–48. Bedard discloses dynamically constructing DAX queries from user-selected report data; querying databases with DAX queries and producing the result of those queries. Bedard, ¶¶ 8, 75, 78, 84. A person of ordinary skill would have been motivated to combine these teachings to enable a user, after determining that the current output is incomplete or inaccurate, to identify needed or desired source data, integrate that data into a cube, and generate a revised DAX query for obtaining a revised result. The predictable result would be an updated DAX query that retrieves and combines data from the applicable tables for Lorenz’s party-specific rule and threshold analysis.
Regarding Claim 2, Lorenz, Bedard, Cherwonka, and Fagin 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, Cherwonka, and Fagin 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, Cherwonka, and Fagin 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, Cherwonka, and Fagin 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 8, Lorenz, Bedard, Cherwonka, and Fagin 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, Cherwonka, and Fagin 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, Cherwonka, and Fagin 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, Cherwonka, and Fagin 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, and 18, Lorenz, Bedard, Cherwonka, and Fagin disclose:
The method of Claim 11.
The remaining limitations of Claims 12, 14, 15, 16, and 18, are not substantively different than those presented in Claims 2, 4, 5, 6, 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, and 8, respectively, supra.
Regarding Claim 19, Lorenz, Bedard, Cherwonka, and Fagin 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, Cherwonka, and Fagin 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 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Lorenz, Bedard, Cherwonka, Fagin and further in view of Thomas (U.S. Pat. Pub. No. 2007/0203922) [“Thomas”]
Regarding Claim 7, Lorenz, Bedard, Cherwonka, and Fagin disclose:
The system of Claim 1 and the at least one processor, the updated DAX query of the set of DAX queries generated from dynamically updated data fields, and the communication from the user computing device,
wherein the at least one processor is further programmed to: cause the updated DAX query of the set of DAX queries to include additional data fields in response to the communication from the user computing device, wherein the communication includes a selection by the user of the additional fields, the additional fields being selected to assist with the consolidation of the column data from the plurality of data tables,
(The Lorenz, Bedard, Cherwonka, and Fagin combination teaches this limitation as set forth in Claim 1 and the following additional remarks. Fagin discloses that a user may identify “what source 205 data is missing from the current illustration” (Fagin, ¶ 115) and “augmenting the query graph to include the new data.” Fagin, ¶ 116. Fagan teaches combining (consolidating) column data from multiple “different relations” (tables). Fagin, ¶¶ 31, 67, 115, 116. Bedard discloses dynamically constructing DAX queries from user-selected report data; querying databases with DAX queries and producing the result of those queries. Bedard, ¶¶ 8, 75, 78, 84. Cherwonka discloses adding new data elements to a data cube by adding new or modifying existing transforms, including join transforms, to link the new data to an existing data cube. Cherwonka, ¶¶ 45–48. Lorenz discloses user feedback concerning inaccurate output. Lorenz, ¶ 69.
The Lorenz, Bedard, Cherwonka, and Fagin combination does not expressly teach, but Thomas teaches:
wherein the column data includes different column name data configured for consolidation by the updated DAX query.
(See at least ¶ 8, displaying to a user, with a graphical user interface (GUI), layouts of the first and second documents simultaneously, the first and second documents having different data schemas and being instantiated with elements containing data values … [and] map[ping] at least a first element of the first document to at least a second element of the second document, wherein each of the first and second elements contains layout data, and storing the association including the layout data corresponding to the first and
second elements.” “A source representation 410 on the left side of the user interface is based on an instance of the source schema (e.g., source schema 550), and a target representation 420 on the right side of the user interface is based on an instance of the target schema (e.g., target schema 580). Source representation 410 may be created by laying out the content of the source instance according to the source schema, including labels (e.g., "orderDate," "shipTo," "country," etc., as illustrated in source representation 410), elements, attributes, and the values of elements and attributes (e.g., country 430, item 450, etc.). Target representation 420 may be created by laying out the content of the target instance according to the target schema, including labels (e.g., "bestelldat," "Lieferaddress," "land," etc., as illustrated in target representation 420), elements, attributes, and the values of elements and attributes (e.g., target slots 440 and 460, etc.). ¶ 53; see also Fig. 4. Thus Thomas discloses corresponding source and target fields/elements having different names, which correspond to the claimed different column name data under BRI.
“Next, the user maps the source instance to the target instance … Server 100 may provide automated mapping suggestion(s) to the user. … For example, if the source schema has a complex type called Address, and the user maps its sub-elements to the sub-elements of the target complex-type PostalAddress, then server 100 searches for other elements of type Address and creates suggestions to map them to other unmapped PostalAddress targets.” ¶ 73. “Automated suggestions may be prioritized by applying matching algorithms to compute the degree of match between pairs of elements for the source and target. Matching may be based on such features as similarity of names, complex types, annotation, attributes and other relations. The automated suggestions may be included in the target slot (the slot is the place where the target value is displayed in the representation) as a drop-down list, ordered from most likely to least likely.” ¶ 74. “[I]f server 100 has provided automated suggestions, the user may choose or reject the automated mapping suggestions for the selected target slots.” ¶ 77. “[A] set of instances of various schemas may be transformed and merged into one instance of a schema (e.g., one of the various schemas or a schema different from the various schemas).” ¶ 100.
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 Thomas’s known field schema mapping and data transformation technique for differently named schema fields (e.g., the claimed “column names”) with the Lorenz, Bedard, Cherwonka, and Fagin combination, with the motivation to permit a user who identifies missing or incompletely mapped data to select additional corresponding fields having different names from relevant tables, and include those fields in a revised DAX query for consolidation. Fagin discloses user identification of source data missing from a current mapping and augmentation of the query graph to include that data. Fagin, ¶¶ 114–116. Cherwonka discloses adding new data elements to a data cube by adding new or modifying existing transforms, including join transforms, to link the new data to an existing data cube. Cherwonka, ¶¶ 45–48. Bedard discloses dynamically constructing DAX queries from user-selected report data; querying databases with DAX queries and producing the result of those queries. Bedard, ¶¶ 8, 75, 78, 84. Thomas discloses selecting and mapping source and target fields having different names. Thomas, ¶¶ 8, 53, 73, 74, 77, 100, Fig. 4. The predictable result would be an updated DAX query that retrieves and combines data from the applicable tables despite different corresponding fields for Lorenz’s party-specific rule and threshold analysis. Thomas, ¶ 6.
Regarding Claim 17, Lorenz, Bedard, Cherwonka, and Fagin disclose:
The computer-implemented method of Claim 11,
The remaining limitations of Claim 17 are not substantively different than those presented in Claim 7 and are therefore, rejected, mutatis mutandis, based on Lorenz, Bedard, Cherwonka, Fagin, and Thomas for the same rationale presented in Claim 7 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 7 supra, and is incorporated in its entirety herein, mutatis mutandis, to support the rejection of Claim 17.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Lorenz, Bedard, Cherwonka, and Fagin, and further in view of Groarke et al. (U.S. Pat. Pub. No. 2015/0026070) [“Groarke”]
Regarding Claim 3, Lorenz, Bedard, Cherwonka, and Fagin 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, Cherwonka, and Fagin 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, Fagin, 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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights