DETAILED ACTION
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 01/06/2026 has been entered.
Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the RCE filed on 01/06/2026.
Claim 19 has been cancelled.
Claim 21 has been added.
Claims 1, 8, 15, and 18 have been amended are hereby entered.
Claims 1-18, and 20-21 are currently pending and have been examined.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-18, and 20-21 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.
Applicant's arguments filed 01/06/2026 with respect to the 35 USC 101 have been fully considered but they are not persuasive.
Applicant argues #1:
Step 2A Prong One: Claims 1, 8, and 15 are not directed to an abstract idea:
In the Office Action, the Examiner asserts that independent claims 1, 8, and 15 are directed to an abstract idea falling within the category of organizing human activity, such as managing commercial or legal interactions, on the basis that the claim relates to enforcing financial regulatory compliance and halting transactions. Applicant respectfully traverses this characterization.
Step 2A, Prong 1 of the test for patent eligibility outlined in the MPEP asks whether the claim recites a judicial exception, which includes a law of nature, a natural phenomenon, or an abstract idea. See MPEP § 2106.04. Applicant respectfully submits that claims 1, 8, and 15 do not merely cover performance of the claim elements as certain methods of organizing human activity or performance using generic computer components, as suggested by the Examiner. Instead, the claims recite specific, technical operations performed by a computer system that generates, structurally updates, and executes a transaction-specific configurable transaction array to control jurisdiction-dependent transaction processing.
As amended, claim 1 is directed to a specific computer-implemented mechanism for structuring and processing transaction data, rather than to the abstract concept of regulatory compliance itself. In particular, claim 1 requires a jurisdictional definition system that generates a jurisdictional definition file comprising regulatory data for multiple jurisdictions and, in response to a transaction request, generates a configurable transaction array as a subset of that definition file for the specific transaction. The system maps sender and receiver information into the configurable transaction array and updates that array based on the mapping, thereby embedding jurisdiction-specific regulatory parameters into the transaction array. Regulatory requirements are then enforced based on the updated configurable transaction array. The transaction is halted based on the enforcement using a decision tree populated by the configurable transaction array such that compliance evaluation is driven by the updated transaction array rather than by application of external rules.
These steps do not recite a mental process or a method of organizing human activity. The generation of a configurable transaction array, the updating of that transaction array, and the execution of enforcement logic driven by the updated array are computer-centric operations that cannot practically be performed in the human mind.
The Federal Circuit in Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016), held that claimed data structures were "not directed to an abstract idea within the meaning of Alice. Rather, they are directed to a specific improvement to the way computers operate." Keeping this in mind, Applicant respectfully submits that the configurable transaction array recited in amended claim 1 likewise constitutes a data structure that provides a specific improvement to the way computers operate. For example, the configurable transaction array is generated as a transaction-specific data structure whose structure is updated based on sender and receiver jurisdictional mapping, and is subsequently used to drive enforcement logic through a populated decision tree. This approach improves computer-based transaction processing by restructuring transaction data prior to enforcement, rather than merely applying regulatory rules to static transaction data, thereby enhancing determinism, scalability, and consistency of jurisdiction-dependent transaction evaluation.
Applicant respectfully submits that these claim elements, as recited by independent claim 1, which include at least one computer system or processor configured to generate a jurisdictional definition file, construct a transaction-specific configurable transaction array, map sender and receiver information into the array, update one or more parameter fields in the transaction array based on that mapping, and enforce regulatory requirements using a decision tree populated by the updated array, cannot be reasonably interpreted as an abstract idea nor as an implementation of an abstract idea. Rather, the recitations necessarily involve specific computer-implemented operations that facilitate and enable the generation, modification, and execution of transaction-specific data structures for jurisdiction-dependent transaction processing, which cannot practically be performed without a computer system.
Examiners response:
Examiner respectfully disagrees, with regards to the human mind test, as an initial matter, just because an idea cannot be performed with a pen and paper or in the human mind does not mean it’s not directed towards an abstract idea and the Examiner did not rely on grouping the claims into the Mental Processes grouping of abstract ideas for the analysis. Furthermore Examiners are directed to continue to use the Mayo Alice framework (as laid out in MPEP 2106 which incorporates Steps 2A and Step 2B of the 2019 PEG) as guidance in evaluating subject matter eligibility, which the Examiner has properly applied and has shown the limitations which recite abstract the idea in the rejection below.
With respect to Enfish, in Enfish, the courts applied the distinction to reject the § 101 challenge at stage one because the claims in Enfish focused not on asserted advances in uses to which existing computer capabilities could be put, but on a specific improvement — a particular database technique — in how computers could carry out one of their basic functions of storage and retrieval of data. Enfish, 822 F.3d at 1335-36; see Bascom, 827 F.3d at 1348-49, 2016 WL 3514158, at *5; cf. Alice, 134 S.Ct. at 2360 (noting basic storage function of generic computer). The present case is different: the focus of the claims is not on such an improvement in computers as tools, but on certain independently abstract ideas that use computers as tools. Arranging the configurable transaction array, generated based on transaction-specific data which is updated based on sender and receiver jurisdictional mapping, and subsequently used to drive enforcement logic through a populated decision tree is not akin to Enfish, as this is akin to Intellectual Ventures I v. Capital One Fin. Corp., 850 F.3d 1332, 121 USPQ2d 1940 (Fed. Cir. 2017), in which the steps in the claims described "the creation of a dynamic document based upon ‘management record types’ and ‘primary record types.’" 850 F.3d at 1339-40; 121 USPQ2d at 1945-46. The claims were found to be directed to the abstract idea of "collecting, displaying, and manipulating data." 850 F.3d at 1340; 121 USPQ2d at 1946, and amounted to no more than instructions to apply the abstract idea, similar to the instant application which is collecting, analyzing, and manipulating data related to create a jurisdictional file and transaction array for analyzing transactions and financial regulatory requirements of countries and halting the transaction (a commercial interaction). See also Providing historical usage information to users while they are inputting data, in order to improve the quality and organization of information added to a database, because "an improvement to the information stored by a database is not equivalent to an improvement in the database’s functionality," BSG Tech LLC v. Buyseasons, Inc., 899 F.3d 1281, 1287-88, 127 USPQ2d 1688, 1693-94 (Fed. Cir. 2018); and Generating a second menu from a first menu and sending the second menu to another location as performed by generic computer components, Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1243-44, 120 USPQ2d 1844, 1855-57 (Fed. Cir. 2016); in which the courts found the additional elements to be mere instructions to apply an exception and not be sufficient to show an improvement in computer-functionality.
Applicant argues #2:
Step 2A Prong Two: Claims 1, 8, and 15 integrate the alleged judicial exception into a practical application:
The Office Action asserts that the judicial exception is not integrated into a practical application because the claims allegedly recite only a "jurisdictional definition system comprising a processor" at a high level of generality, amounting to mere instructions to apply the abstract idea using generic computer components. Applicant respectfully disagrees.
Assuming, arguendo, that independent claim 1 is directed to a judicial exception, Applicant respectfully submits that the claim integrates the recited judicial exception into a practical application of that exception. See MPEP § 2106.04(JJ)(A)(2). As explained in MPEP § 2106, examiners must evaluate whether the claim as a whole integrates the exception into a practical application. If the additional elements in the claim integrate the alleged judicial exception into a practical application, then the claim is not directed to the exception.
With this framework in mind, Applicant respectfully submits that any alleged judicial exception recited in independent claim 1 is integrated into a practical application of computer- implemented, jurisdiction-dependent transaction processing using a transaction-specific configurable transaction array whose parameter fields are updated prior to enforcement and which halts the transaction upon enforcement of regulatory requirements.
With respect to independent claim 1, the practical application includes jurisdictional definition system that receives a transaction request, determines applicable jurisdictions based on sender and receiver information, generates a transaction-specific configurable transaction array incorporating jurisdiction-specific regulatory parameters, updates parameter fields in the configurable transaction array, and executes enforcement logic using a decision tree populated from the updated array to determine whether the transaction should proceed or be halted.
The MPEP explains that examiners should evaluate integration into a practical application by: (a) identifying whether there are additional elements beyond the alleged judicial exception; and (b) evaluating those additional elements individually and in combination to determine whether they integrate the exception into a practical application. See MPEP § 2106.07(a). The MPEP further recognizes that an additional element may integrate an exception into a practical application when the element reflects an improvement in the functioning of a computer or an improvement to another technical field. See MPEP § 2106.04(d)(1).
Here, the additional elements recited in claim 1 include specific computer-implemented operations directed to generating, structurally updating, and executing a transaction-specific data structure, including jurisdictional data extraction, selective inclusion of regulatory parameters, updating of a configurable transaction array, enforcement driven by the updated array, and halting the transaction upon enforcement. These elements are integral to the claim and cannot be performed mentally or abstractly, as they require automated data-structure generation and manipulation performed by a computer system.
With these features in mind, Applicant respectfully submits that the additional elements recited in claims 1, 8, and 15 integrate any alleged judicial exception into the practical application of structuring and processing transaction data in a jurisdiction-aware manner using updated transaction-specific data structures. Further, these elements provide a technical improvement by enabling deterministic, scalable, and consistent transaction evaluation through data-structure-driven enforcement, rather than reliance on external rules engines applied to static transaction data. Accordingly, independent claims 1, 8, and 15 integrate the alleged judicial exception into a practical application and therefore are not directed to patent-ineligible subject matter under 35 U.S.C. § 101.
Examiners response:
The Examiner respectfully disagrees, with regards to the prong two, and applicants arguments that the claims are integrated into a practical application, Examiner respectfully disagrees, the Examiner fails to see how the claims indicative of a practical application, as laid out in MPEP 2106.04(d), as they fail to provide:
Improvements to the functioning of a computer, or to any other technology or technical field - see MPEP 2106.05(a)
Applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition – see Vanda Memo
Applying the judicial exception with, or by use of, a particular machine - see MPEP 2106.05(b)
Effecting a transformation or reduction of a particular article to a different state or thing - see MPEP 2106.05(c)
Applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception - see MPEP 2106.05(e) and Vanda Memo
Here the claims only recite abstract steps being applied with generic computer components. Mere instructions to apply the judicial exception using generic computer components is not indicative of a practical application (see MPEP 20106.05(f)). Further with respect to the claims enable deterministic, scalable, and consistent transaction evaluation through data-structure-driven enforcement, this does not amount to technical improvement or practical application as per MPEP 2106.05(f) Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone);, and as shown in MPEP 2106.05, Mere automation of manual processes, such as using a generic computer to process an application for financing a purchase, Credit Acceptance Corp. v. Westlake Services, 859 F.3d 1044, 1055, 123 USPQ2d 1100, 1108-09 (Fed. Cir. 2017) and Performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims."); is not a technical improvement similar the instant application which arranges the configurable transaction array, generated based on transaction-specific data and updated based on sender and receiver jurisdictional mapping to enforce logic through a populated decision tree for analyzing a transaction.
Applicant argues #3:
Step 2B: Claims 1, 8, and 15 Recite Significantly More Than The Judicial Exception:
The Office Action concludes that independent claim 1 does not recite significantly more than the alleged abstract idea because the additional elements allegedly amount to no more than instructions to apply the exception using generic computer components, whether considered individually or as an ordered combination. Applicant respectfully disagrees, as this conclusion is based on an improper focus on the generic nature of the hardware rather than on the specific technical operations and system architecture required by the claim.
The inquiry in Step 2B is whether the additional claim elements, individually and in combination, amount to an inventive concept, i.e., whether they transform the nature of the claim into a patent-eligible application. As clarified by the Federal Circuit in Berkheimer v. HP Inc., whether claim elements are well-understood, routine, and conventional is a factual determination.
Here, amended claim 1 recites far more than the use of a generic processor to perform compliance analysis. The claim requires generating a configurable transaction array as a subset of a jurisdictional definition file, mapping sender and receiver information into that array, and update one or more parameter fields of the configurable transaction array based on the mapping. Enforcement is then performed based on the updated configurable transaction array, such that the structure of the array itself governs downstream compliance processing. The transaction is then processed or halted based on the enforcement using a decision tree populated by the configurable transaction array.
This sequence of operations reflects a non-conventional data-processing architecture. Conventional compliance systems apply regulatory rules externally to transaction data without altering/updating the structure of the transaction data itself. In contrast, claim 1 requires that jurisdiction-specific regulatory parameters be embedded into and reflected by the transaction- specific array prior to enforcement. This structural update is not a routine or generic computer operation, it changes how the computer represents, organizes, and processes transaction data.
When the claim is considered as an ordered combination, the inventive concept becomes even clearer. The coordinated steps of (i) generating a transaction-specific configurable transaction array, (ii) updating parameter fields of the array based on jurisdictional mapping, (iii) executing enforcement logic based on the updated array, and (iv) halting a transaction based on the enforcement using a decision tree populated by the updated array represent a departure from conventional rules-engine-based approaches. This ordered combination enables deterministic, data-structure-driven transaction evaluation and meaningfully improves computer-based processing of jurisdiction-dependent transactions.
Applicant respectfully submits that these recitations add specific, non-generic limitations that are not well-understood, routine, or conventional in the field. The claims do not merely recite evaluating or enforcing regulatory requirements in the abstract. Instead, they require coordinated computer-implemented operations as above. When considered as an ordered combination, these elements provide a technical solution to the problem of reliably and deterministically processing jurisdiction-dependent transactions by restructuring transaction data prior to enforcement, rather than applying external rules to static data.
Accordingly, at least these additional elements recited in independent claim 1 constitute an inventive concept under Step 2B, as they amount to significantly more than any alleged judicial exception. For at least these reasons, Applicant respectfully submits that independent claims 1, 8, and 15 and the claims depending therefrom, are directed to patent-eligible subject matter under MPEP § 2106. Applicant therefore respectfully requests withdrawal of the rejection under 35 U.S.C. § 101.
Examiners response:
The Examiner respectfully disagrees, (i) generating a transaction-specific configurable transaction array, (ii) updating parameter fields of the array based on jurisdictional mapping, (iii) executing enforcement logic based on the updated array, and (iv) halting a transaction based on the enforcement using a decision tree populated by the updated array represent a departure from conventional rules-engine-based approaches further describes commercial and legal interactions but for the recitation of generic computer components. As per MPEP 2106.05(f) and for the same reasons as shown in the Court decisions above, Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone);
For the reasons above, the 101 rejection is hereby maintained.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18, and 20-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more, and fails step 2 of the analysis because the focus of the claims is not on the devices themselves or a practical application but rather directed towards an abstract idea, the analysis is provided below.
Step 1 (Statutory Categories) - The claims pass step 1 of the subject matter eligibility test (see MPEP 2106(III)) as the claims are directed towards a system, and two methods.
Step 2A – Prong One (Do the claims recite an abstract idea?)
The idea is recited in the claims 1 and 8, in part, by:
generating a jurisdictional definition file based on a plurality of financial regulatory requirements for a plurality of countries;
responsive to receiving a transaction request, generating a configurable transaction array for the transaction request that is a subset of the jurisdictional definition file based on a sender information and a receiver information;
mapping the sender information and the receiver information into the configurable transaction array;
the configurable transaction array comprises jurisdiction-specific regulatory parameters selectively mapped to the transaction request;
updating one or more parameter fields in the configurable transaction array based on the selectively mapped jurisdiction-specific regulatory parameters;
enforcing the one or more financial regulatory requirements defined by the configurable transaction array based on the updated configurable transaction array;
halting a transaction based on the enforcing using a decision tree that is populated by the configurable transaction array.
While varying in scope, claim 15 recites an idea, in part by:
generating a jurisdictional definition file based on a plurality of financial regulatory requirements for a plurality of countries;
responsive to receiving a transaction request, generating transaction data comprising one or more questions that are based on a sender information and a receiver information of the transaction request, the transaction data further comprising jurisdiction-specific regulatory parameters selectively mapped to the transaction request;
updating one or more parameter fields in the transaction data based on the selectively mapped jurisdiction-specific regulatory parameters;
enforcing the one or more financial regulatory requirements based on the updated transaction data
halting a transaction based on the enforcing using a decision tree that is generated from the transaction data.
The steps recited above under Step 2A Prong One of the analysis under the broadest reasonable interpretation covers commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations) but for the recitation of generic computer components for halting a transaction based on financial regulatory requirements. That is other than reciting a jurisdictional definition system comprising a processor, nothing in the claim elements are directed towards anything other than commercial or legal interactions. If a claim limitation, under its broadest reasonable interpretation, covers commercial or legal interactions, then it falls within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas. Accordingly, the claims recite an abstract idea.
Step 2A – Prong Two (Does the claim recite additional elements that integrate the judicial exception into a practical application?) - This judicial exception is not integrated into a practical application. In particular, the claims only recite the additional elements of a jurisdictional definition system comprising a processor. The jurisdictional definition system comprising a processor is recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply the judicial exception using generic computer components is not indicative of a practical application (see MPEP 20106.05(f)). The specification does not provide any indication that the jurisdictional definition system comprising a processor is other than generic computer components and acknowledges that the “The jurisdictional system 100 may include one or more computer hardware systems… The jurisdictional definition system 105 includes a processor 125,memory 130,data extraction module 135” describing a highly generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed towards an abstract idea.
Step 2B (Does the claim recite additional elements that amount to significantly more than the judicial exception?) - The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, with respect to integration of the abstract idea into a practical application, using the additional elements of a jurisdictional definition system comprising a processor to perform the steps recited in Step 2A Prong One of the analysis amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components does not provide an inventive concept. The additional elements have been considered separately, and as an ordered combination, and do not add significantly more (also known as an “inventive concept”) to the judicial exception. Further, similar to Intellectual Ventures I v. Capital One Fin. Corp., 850 F.3d 1332, 121 USPQ2d 1940 (Fed. Cir. 2017), in which the steps in the claims described "the creation of a dynamic document based upon ‘management record types’ and ‘primary record types.’" 850 F.3d at 1339-40; 121 USPQ2d at 1945-46. The claims were found to be directed to the abstract idea of "collecting, displaying, and manipulating data." 850 F.3d at 1340; 121 USPQ2d at 1946, and amounted to no more than instructions to apply the abstract idea, similar to the instant application which is collecting, analyzing, and manipulating data related to create a jurisdictional file and transaction array for analyzing transactions and financial regulatory requirements of countries and halting the transaction (a commercial interaction). Additionally, MPEP 2106.05(d)(ii) provides that receiving and transmitting data over a network (see buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), and Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); are well-understood routine and conventional, similar to the instant application claims which recites and sending and receiving data over network, and mapping the transaction information to perform the commercial and legal interactions of halting the transaction. The claims are not patent eligible.
The dependent claims have been given the full analysis including analyzing the additional limitations both individually and in combination as a whole. For instance, claims 2-7, 9-14, 16-18, and 20-21 are all steps that fall within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas, further defining abstract ideas, amounting to more than instructions to apply the idea. The Dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 for the same reasoning as above and the additional recited limitations fail to establish that the claims are not directed to an abstract idea. The additional limitations of the dependent claims when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
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-3, 6-10, 13-15, and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Jinnett (US Patent Application Publication 20020120477), “Jinnett” in view of Hernandez, et al. (US Patent Application 20210073819), “Hernandez”.
As per claims 1, and 8, Jinnett discloses:
A method for automating financial regulatory compliance, comprising: [0002]
generating, by a jurisdictional definition system, a jurisdictional definition file based on a plurality of financial regulatory requirements for a plurality of countries; [0036], [0050], [0106-0107] For example, where U.S. federal standards for any of the three elements preempt a state standard, the federal standard governs. Where a state standard is not preempted but exceeds the federal standard, the state standard would apply. In the event that two or more states have matching standards in terms of the three elements relating to network, database and security features, one extranet may be used the transaction in the matching states. This information is compiled into one or more databases, preferably on a jurisdictional and/or industry basis (S58), and preferably employing a data manipulation language… It is another feature and advantage of the present invention to provide a system and method for providing a communications network customized to the laws of individual legal jurisdictions, that is adaptable to meet the needs of other regulated industries, such as the financial services industry… A jurisdiction includes a state, country or member country, region, territory, commonwealth and/or a district.
responsive to receiving a transaction request, generating, by the jurisdictional definition system, a configurable transaction array for the transaction request that is a subset of the jurisdictional definition file based on a sender information and a receiver information; [0042], [0051], [0086] In another aspect of the present invention, a system configured to provide customized insurance services and products in real time, is disclosed. The system comprises one or more networks that performs the steps of: determining a transaction for processing; identifying either a user's jurisdiction or a primary jurisdiction relevant to the transaction; detecting user input data; applying to the transaction, one or more laws of a jurisdiction identified as either the user's jurisdiction or the primary jurisdiction relevant to the transaction… The method includes the steps of: providing one or more databases of legal requirements governing each service and/or product; providing one or more rules engines for establishing a hierarchy of how to apply legal requirements for each service and/or product; creating one or more networks linking each database and rules engine such that each service transaction and each product transaction is customized with the legal requirements relevant to the service/product transaction; and outputting a transaction result. The legal requirements may be organized on a jurisdiction-by-jurisdiction basis… Referring now to FIG. 3, there is shown an exemplary embodiment of a decision tree describing application of a plurality of rules engines to a multi-state transaction, such as a multi-state insurance transaction. As depicted, application begins with box 34, identifying one or more legal jurisdictions that may be applicable to the desired transaction. Factors may include the location of each of the insured, health insurer, hospital and the clearinghouse. The rules engine(s) identify/identifies the sets of laws and/or regulations of each jurisdiction that may be involved or mapped in an insurance transaction.
mapping, by the jurisdiction definition system, the sender information and the receiver information into the configurable transaction array, [0086-0087], [0096-0098] Referring now to FIG. 3, there is shown an exemplary embodiment of a decision tree describing application of a plurality of rules engines to a multi-state transaction, such as a multi-state insurance transaction. As depicted, application begins with box 34, identifying one or more legal jurisdictions that may be applicable to the desired transaction. Factors may include the location of each of the insured, health insurer, hospital and the clearinghouse. The rules engine(s) identify/identifies the sets of laws and/or regulations of each jurisdiction that may be involved or mapped in an insurance transaction. These laws may include federal privacy laws 36, such as HIPAA and the Fair Credit Reporting Act (FCRA), state privacy laws 38, federal electronic signature regulations 40, and state electronic signature regulations 42… The choice of law analysis 44 indicates an identification of laws from the identified jurisdictions that may apply to the transaction… Here, for instance, the decision logic is developed whereby in instances where an insurer requests patient information from the hospital, a business rule requires a minimum analysis prior to disclosure unless the health insurer is a covered entity. If the hospital determines that the health insurer is a covered entity, the minimum necessary analysis is not conducted. In this regard, the rules engine is based on an "if x, then do y" type of logic and comprises such decision trees for a particular law, such as HIPAA.
enforcing, by the jurisdictional definition system, one or more financial regulatory requirements defined by the configurable transaction array based on the updated configurable transaction array; and; [0086-0087], [0101] The rules engine(s) identify/identifies the sets of laws and/or regulations of each jurisdiction that may be involved or mapped in an insurance transaction. These laws may include federal privacy laws 36, such as HIPAA and the Fair Credit Reporting Act (FCRA), state privacy laws 38, federal electronic signature regulations 40, and state electronic signature regulations 42… The choice of law analysis 44 indicates an identification of laws from the identified jurisdictions that may apply to the transaction… If a transaction is identified as being violative of the applicable law(s) or, alternatively, if the rules engine is unable to determine compliance or non-compliance, transaction processing is halted and a message is sent notifying the user or system operator of its suspended status and/or the details why. At this juncture, the user consults the master query database and/or other relevant sources in order to identify what additional steps are necessary to bring the transaction into compliance. Once the legal issue is resolved for a particular transaction, a knowledge repository database maintains a record of the transaction for future reference by the rules engine, in order to avoid flagging and/or suspending a future similar transaction.
halting, by the jurisdictional definition system, a transaction based on the enforcing using a decision tree that is populated by the configurable transaction array. [0086-0087], [0096-0098], [0101] The choice of law analysis 44 indicates an identification of laws from the identified jurisdictions that may apply to the transaction… Finally, with respect to FIG. 3, ranking 48 of the laws by level of stringency, and application 50 of the ranked laws (or subset of laws) that is most stringent and which, if imposed, satisfies substantially all less stringent applicable laws, completes the decision tree. For instance, if more than one law remains in the group after the preemption analysis 46, all remaining laws in the group are ranked hierarchically from the least stringent to the most stringent. The most stringent law is applied, provided that the most stringent law satisfies substantially all less stringent laws in the group… If a transaction is identified as being violative of the applicable law(s) or, alternatively, if the rules engine is unable to determine compliance or non-compliance, transaction processing is halted and a message is sent notifying the user or system operator of its suspended status and/or the details why. At this juncture, the user consults the master query database and/or other relevant sources in order to identify what additional steps are necessary to bring the transaction into compliance. Once the legal issue is resolved for a particular transaction, a knowledge repository database maintains a record of the transaction for future reference by the rules engine, in order to avoid flagging and/or suspending a future similar transaction… For example, a use case may be the request by a health insurer to a hospital for a patient's full medical record. Under the HIPAA Privacy Rule, a hospital must conduct a "minimum necessary" analysis prior to disclosing protected health information, unless it determines that the entity requesting the information is a "covered entity" under HIPAA. A decision logic corresponding to the use case is developed. Here, for instance, the decision logic is developed whereby in instances where an insurer requests patient information from the hospital, a business rule requires a minimum analysis prior to disclosure unless the health insurer is a covered entity. If the hospital determines that the health insurer is a covered entity, the minimum necessary analysis is not conducted. In this regard, the rules engine is based on an "if x, then do y" type of logic and comprises such decision trees for a particular law, such as HIPAA.
Jinnett is silent on the following, Hernandez, however discloses:
the configurable transaction array comprises jurisdiction-specific regulatory parameters selectively mapped to the transaction request see fig 5B, [0011], [0067], [0074], [0120-0121], see also fig. 9A-C FIG. 5B shows an exemplary cyber-fraud portal 233B according to one embodiment. The user interface 501 can include a window 509 for navigating through various portals and user interfaces. For example, a selection at the window 509 causes an application database portal 237 (FIG. 7) to be accessed and an associated user interface 701 to be rendered. The user interface 501 can include one or more fields 513A-F for initiating the rendering of various category-specific interfaces or for accessing other portals and user interfaces associated therewith. For example, a selection of the field 513A causes the user interface 501 to be updated to include data associated potential fraud events (e.g., anomalous transaction patterns, suspicious login events, etc.). In the same example, a selection of the field 513B causes the under interface 501 to be updated with data associated with alerts generated or received at the monitoring system 200. A selection of the field 513C can cause a ticket portal 243A (FIG. 10A) to be accessed… An external system 203 can include one or more systems associated with an entity, such as a financial institution… The external system 203 can include one or more databases 208 that can be accessible to the computing environment 201. The database 208 can store, for example, historical monitoring data, user account data, policies, and configurations. The external system 203 can include a monitor service 210, such as, for example, a native fraud detection service configured for analyzing activities occurring within the external system 203… For example, the EDS service 213 analyze monitoring data 209, including e-banking activities initiated in foreign countries and/or via web proxy services, to identify unusual usage patterns and/or attempted or successful fraudulent actions.
updating one or more parameter fields in the configurable transaction array based on the selectively mapped jurisdiction-specific regulatory parameters; see fig 5B, [0011], [0067], [0074], [0120-0121], see also fig. 9A-C FIG. 5B shows an exemplary cyber-fraud portal 233B according to one embodiment. The user interface 501 can include a window 509 for navigating through various portals and user interfaces. For example, a selection at the window 509 causes an application database portal 237 (FIG. 7) to be accessed and an associated user interface 701 to be rendered. The user interface 501 can include one or more fields 513A-F for initiating the rendering of various category-specific interfaces or for accessing other portals and user interfaces associated therewith. For example, a selection of the field 513A causes the user interface 501 to be updated to include data associated potential fraud events (e.g., anomalous transaction patterns, suspicious login events, etc.). In the same example, a selection of the field 513B causes the under interface 501 to be updated with data associated with alerts generated or received at the monitoring system 200. A selection of the field 513C can cause a ticket portal 243A (FIG. 10A) to be accessed… An external system 203 can include one or more systems associated with an entity, such as a financial institution… The external system 203 can include one or more databases 208 that can be accessible to the computing environment 201. The database 208 can store, for example, historical monitoring data, user account data, policies, and configurations. The external system 203 can include a monitor service 210, such as, for example, a native fraud detection service configured for analyzing activities occurring within the external system 203… For example, the EDS service 213 analyze monitoring data 209, including e-banking activities initiated in foreign countries and/or via web proxy services, to identify unusual usage patterns and/or attempted or successful fraudulent actions.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Jinnett with the ability to update the interface with data associated with the alerts as taught by Hernandez, doing so further allows the visualization of the fraud activity and accounts ([0120-0121]).
As per claims 2, and 9 Jinnett discloses:
wherein the sender information further comprises a sender identification information, a sender country, and a type of transaction. [0020], [0047] As to the step of providing one or more databases of legal requirements, it includes providing jurisdiction-specific content on federal laws, state laws, country laws, regional laws, online access and administration requirements, licensing requirements, privacy requirements, general online requirements, advertising requirements, and electronic signatures and records requirements governing each service/product… After development of the business templates, individuals involved in the business or insurance transaction, such as a health insurer or hospital, are identified, after which a use case is developed. For example, a use case may be the request by a health insurer to a hospital for a patient's full medical record. Under the HIPAA Privacy Rule, a hospital must conduct a "minimum necessary" analysis prior to disclosing protected health information, unless it determines that the entity requesting the information is a "covered entity" under HIPAA. A decision logic corresponding to the use case is developed. Here, for instance, the decision logic is developed whereby in instances where an insurer requests patient information from the hospital, a business rule requires a minimum analysis prior to disclosure unless the health insurer is a covered entity. If the hospital determines that the health insurer is a covered entity, the minimum necessary analysis is not conducted. In this regard, the rules engine is based on an "if x, then do y" type of logic and comprises such decision trees for a particular law, such as HIPAA… For example, if industry regulations fall along geographic lines, as in the insurance industry, then the extranets of the present invention are preferably configured for user accessibility on a geographical basis, which may include along physical boundary lines. In these instances, the present invention encompasses configuring/using extranets to cover jurisdictions inside as well as outside the United States, on a state, regional, country or other jurisdictional basis, in order to create a secure network for servicing customers locally, regionally and/or worldwide.
As per claims 3, and 10, Jinnett discloses:
wherein the receiver information further comprises a receiver identification information, and a receiver country. [0020], [0047] As to the step of providing one or more databases of legal requirements, it includes providing jurisdiction-specific content on federal laws, state laws, country laws, regional laws, online access and administration requirements, licensing requirements, privacy requirements, general online requirements, advertising requirements, and electronic signatures and records requirements governing each service/product… After development of the business templates, individuals involved in the business or insurance transaction, such as a health insurer or hospital, are identified, after which a use case is developed. For example, a use case may be the request by a health insurer to a hospital for a patient's full medical record. Under the HIPAA Privacy Rule, a hospital must conduct a "minimum necessary" analysis prior to disclosing protected health information, unless it determines that the entity requesting the information is a "covered entity" under HIPAA. A decision logic corresponding to the use case is developed. Here, for instance, the decision logic is developed whereby in instances where an insurer requests patient information from the hospital, a business rule requires a minimum analysis prior to disclosure unless the health insurer is a covered entity. If the hospital determines that the health insurer is a covered entity, the minimum necessary analysis is not conducted. In this regard, the rules engine is based on an "if x, then do y" type of logic and comprises such decision trees for a particular law, such as HIPAA… For example, if industry regulations fall along geographic lines, as in the insurance industry, then the extranets of the present invention are preferably configured for user accessibility on a geographical basis, which may include along physical boundary lines. In these instances, the present invention encompasses configuring/using extranets to cover jurisdictions inside as well as outside the United States, on a state, regional, country or other jurisdictional basis, in order to create a secure network for servicing customers locally, regionally and/or worldwide.
As per claims 6, and 13, Jinnett discloses:
determining that the transaction will succeed; and performing the transaction request responsive to determining that the transaction will succeed. [0100] Accordingly, each transaction is routed to the rules engine for analysis. The rules engine either approves the transaction as in compliance with applicable law(s), or prohibit the transaction as in violation of the law(s). If approved for further processing, the transaction proceeds as depicted in FIG. 3.
As per claims 7, and 14, Jinnett discloses:
further comprising periodically updating the jurisdictional definition file as the underlying configurable transaction array files are modified when there is a change in the financial regulatory requirement. [0024], [0099] Additionally, each extranet allows for periodic updating as federal and state laws and regulations change. In this regard, compliance with each jurisdiction's insurance regulatory requirements for doing business over a global communications network, such as the Internet, is satisfied… In another application of the query databases and rules engines, for example, a master query database is maintained and updated so as to keep the legal content current. The master query database is preferably accessible over a local (e.g. an extranet) or global communications network. A user or subscriber determines which transaction processing gives rise to the legal issues covered by the master query database and rules engines, and links its computer system, at appropriate transactional nodes, to the rules engine.
As per claim 15, Jinnett discloses:
A method for automating financial regulatory compliance, the method comprising: [0002]
generating, by a jurisdictional definition system, a jurisdictional definition file based on a plurality of financial regulatory requirements for a plurality of countries; [0036], [0050], [0106-0107] For example, where U.S. federal standards for any of the three elements preempt a state standard, the federal standard governs. Where a state standard is not preempted but exceeds the federal standard, the state standard would apply. In the event that two or more states have matching standards in terms of the three elements relating to network, database and security features, one extranet may be used the transaction in the matching states. This information is compiled into one or more databases, preferably on a jurisdictional and/or industry basis (S58), and preferably employing a data manipulation language… It is another feature and advantage of the present invention to provide a system and method for providing a communications network customized to the laws of individual legal jurisdictions, that is adaptable to meet the needs of other regulated industries, such as the financial services industry… A jurisdiction includes a state, country or member country, region, territory, commonwealth and/or a district.
responsive to receiving a transaction request, generating, by the jurisdictional definition system, transaction data comprising one or more questions that are based on a sender information and a receiver information of the transaction request, [0042], [0051], [0086], [0098] In another aspect of the present invention, a system configured to provide customized insurance services and products in real time, is disclosed. The system comprises one or more networks that performs the steps of: determining a transaction for processing; identifying either a user's jurisdiction or a primary jurisdiction relevant to the transaction; detecting user input data; applying to the transaction, one or more laws of a jurisdiction identified as either the user's jurisdiction or the primary jurisdiction relevant to the transaction… The method includes the steps of: providing one or more databases of legal requirements governing each service and/or product; providing one or more rules engines for establishing a hierarchy of how to apply legal requirements for each service and/or product; creating one or more networks linking each database and rules engine such that each service transaction and each product transaction is customized with the legal requirements relevant to the service/product transaction; and outputting a transaction result. The legal requirements may be organized on a jurisdiction-by-jurisdiction basis… Referring now to FIG. 3, there is shown an exemplary embodiment of a decision tree describing application of a plurality of rules engines to a multi-state transaction, such as a multi-state insurance transaction. As depicted, application begins with box 34, identifying one or more legal jurisdictions that may be applicable to the desired transaction. Factors may include the location of each of the insured, health insurer, hospital and the clearinghouse. The rules engine(s) identify/identifies the sets of laws and/or regulations of each jurisdiction that may be involved or mapped in an insurance transaction… After development of the business templates, individuals involved in the business or insurance transaction, such as a health insurer or hospital, are identified, after which a use case is developed. For example, a use case may be the request by a health insurer to a hospital for a patient's full medical record. Under the HIPAA Privacy Rule, a hospital must conduct a "minimum necessary" analysis prior to disclosing protected health information, unless it determines that the entity requesting the information is a "covered entity" under HIPAA. A decision logic corresponding to the use case is developed. Here, for instance, the decision logic is developed whereby in instances where an insurer requests patient information from the hospital, a business rule requires a minimum analysis prior to disclosure unless the health insurer is a covered entity. If the hospital determines that the health insurer is a covered entity, the minimum necessary analysis is not conducted. In this regard, the rules engine is based on an "if x, then do y" type of logic and comprises such decision trees for a particular law, such as HIPAA.
enforcing, by the jurisdictional definition system, one or more financial regulatory requirements based on the updated transaction data; and [0086-0087], [0101] The rules engine(s) identify/identifies the sets of laws and/or regulations of each jurisdiction that may be involved or mapped in an insurance transaction. These laws may include federal privacy laws 36, such as HIPAA and the Fair Credit Reporting Act (FCRA), state privacy laws 38, federal electronic signature regulations 40, and state electronic signature regulations 42… The choice of law analysis 44 indicates an identification of laws from the identified jurisdictions that may apply to the transaction… If a transaction is identified as being violative of the applicable law(s) or, alternatively, if the rules engine is unable to determine compliance or non-compliance, transaction processing is halted and a message is sent notifying the user or system operator of its suspended status and/or the details why. At this juncture, the user consults the master query database and/or other relevant sources in order to identify what additional steps are necessary to bring the transaction into compliance. Once the legal issue is resolved for a particular transaction, a knowledge repository database maintains a record of the transaction for future reference by the rules engine, in order to avoid flagging and/or suspending a future similar transaction.
halting a transaction based on the enforcing using a decision tree that is generated from the transaction data. [0086-0087], [0096-0098], [0101] The choice of law analysis 44 indicates an identification of laws from the identified jurisdictions that may apply to the transaction… Finally, with respect to FIG. 3, ranking 48 of the laws by level of stringency, and application 50 of the ranked laws (or subset of laws) that is most stringent and which, if imposed, satisfies substantially all less stringent applicable laws, completes the decision tree. For instance, if more than one law remains in the group after the preemption analysis 46, all remaining laws in the group are ranked hierarchically from the least stringent to the most stringent. The most stringent law is applied, provided that the most stringent law satisfies substantially all less stringent laws in the group… If a transaction is identified as being violative of the applicable law(s) or, alternatively, if the rules engine is unable to determine compliance or non-compliance, transaction processing is halted and a message is sent notifying the user or system operator of its suspended status and/or the details why. At this juncture, the user consults the master query database and/or other relevant sources in order to identify what additional steps are necessary to bring the transaction into compliance. Once the legal issue is resolved for a particular transaction, a knowledge repository database maintains a record of the transaction for future reference by the rules engine, in order to avoid flagging and/or suspending a future similar transaction… For example, a use case may be the request by a health insurer to a hospital for a patient's full medical record. Under the HIPAA Privacy Rule, a hospital must conduct a "minimum necessary" analysis prior to disclosing protected health information, unless it determines that the entity requesting the information is a "covered entity" under HIPAA. A decision logic corresponding to the use case is developed. Here, for instance, the decision logic is developed whereby in instances where an insurer requests patient information from the hospital, a business rule requires a minimum analysis prior to disclosure unless the health insurer is a covered entity. If the hospital determines that the health insurer is a covered entity, the minimum necessary analysis is not conducted. In this regard, the rules engine is based on an "if x, then do y" type of logic and comprises such decision trees for a particular law, such as HIPAA.
Jinnett is silent on the following, Hernandez, however discloses:
the transaction data further comprising jurisdiction-specific regulatory parameters selectively mapped to the transaction request; see fig 5B, [0011], [0067], [0074], [0120-0121], see also fig. 9A-C FIG. 5B shows an exemplary cyber-fraud portal 233B according to one embodiment. The user interface 501 can include a window 509 for navigating through various portals and user interfaces. For example, a selection at the window 509 causes an application database portal 237 (FIG. 7) to be accessed and an associated user interface 701 to be rendered. The user interface 501 can include one or more fields 513A-F for initiating the rendering of various category-specific interfaces or for accessing other portals and user interfaces associated therewith. For example, a selection of the field 513A causes the user interface 501 to be updated to include data associated potential fraud events (e.g., anomalous transaction patterns, suspicious login events, etc.). In the same example, a selection of the field 513B causes the under interface 501 to be updated with data associated with alerts generated or received at the monitoring system 200. A selection of the field 513C can cause a ticket portal 243A (FIG. 10A) to be accessed… An external system 203 can include one or more systems associated with an entity, such as a financial institution… The external system 203 can include one or more databases 208 that can be accessible to the computing environment 201. The database 208 can store, for example, historical monitoring data, user account data, policies, and configurations. The external system 203 can include a monitor service 210, such as, for example, a native fraud detection service configured for analyzing activities occurring within the external system 203… For example, the EDS service 213 analyze monitoring data 209, including e-banking activities initiated in foreign countries and/or via web proxy services, to identify unusual usage patterns and/or attempted or successful fraudulent actions.
updating one or more parameter fields in the transaction data based on the selectively mapped jurisdiction-specific regulatory parameters; see fig 5B, [0011], [0067], [0074], [0120-0121] FIG. 5B shows an exemplary cyber-fraud portal 233B according to one embodiment. The user interface 501 can include a window 509 for navigating through various portals and user interfaces. For example, a selection at the window 509 causes an application database portal 237 (FIG. 7) to be accessed and an associated user interface 701 to be rendered. The user interface 501 can include one or more fields 513A-F for initiating the rendering of various category-specific interfaces or for accessing other portals and user interfaces associated therewith. For example, a selection of the field 513A causes the user interface 501 to be updated to include data associated potential fraud events (e.g., anomalous transaction patterns, suspicious login events, etc.). In the same example, a selection of the field 513B causes the under interface 501 to be updated with data associated with alerts generated or received at the monitoring system 200. A selection of the field 513C can cause a ticket portal 243A (FIG. 10A) to be accessed… An external system 203 can include one or more systems associated with an entity, such as a financial institution… The external system 203 can include one or more databases 208 that can be accessible to the computing environment 201. The database 208 can store, for example, historical monitoring data, user account data, policies, and configurations. The external system 203 can include a monitor service 210, such as, for example, a native fraud detection service configured for analyzing activities occurring within the external system 203… For example, the EDS service 213 analyze monitoring data 209, including e-banking activities initiated in foreign countries and/or via web proxy services, to identify unusual usage patterns and/or attempted or successful fraudulent actions.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Jinnett with the ability to update the interface with data associated with the alerts as taught by Hernandez, doing so further allows the visualization of the fraud activity and accounts ([0120-0121]).
As per claim 20, Jinnett discloses:
wherein the transaction request comprises an array of two or more transactions. [0053], [0086] In Re Harza, In yet another aspect of the present invention, in a method for providing electronic access to regulated services and/or products, a system of protocols, which is imposed on one or more transactions involving regulated services and/or products, is disclosed… Referring now to FIG. 3, there is shown an exemplary embodiment of a decision tree describing application of a plurality of rules engines to a multi-state transaction, such as a multi-state insurance transaction. As depicted, application begins with box 34, identifying one or more legal jurisdictions that may be applicable to the desired transaction. Factors may include the location of each of the insured, health insurer, hospital and the clearinghouse. The rules engine(s) identify/identifies the sets of laws and/or regulations of each jurisdiction that may be involved or mapped in an insurance transaction. These laws may include federal privacy laws 36, such as HIPAA and the Fair Credit Reporting Act (FCRA), state privacy laws 38, federal electronic signature regulations 40, and state electronic signature regulations 42.
As per claim 21, Jinnett is silent on the following, Hernandez, however, discloses:
wherein updating the configurable transaction array comprises adding or omitting the one or more parameter fields in the configurable transaction array based on the selectively mapped jurisdiction-specific regulatory parameters associated with the sender information and the receiver information. see fig 5B, [0008-0011], [0067], [0074], [0120-0121], see also fig. 9A-C, FIG. 5B shows an exemplary cyber-fraud portal 233B according to one embodiment. The user interface 501 can include a window 509 for navigating through various portals and user interfaces. For example, a selection at the window 509 causes an application database portal 237 (FIG. 7) to be accessed and an associated user interface 701 to be rendered. The user interface 501 can include one or more fields 513A-F for initiating the rendering of various category-specific interfaces or for accessing other portals and user interfaces associated therewith. For example, a selection of the field 513A causes the user interface 501 to be updated to include data associated potential fraud events (e.g., anomalous transaction patterns, suspicious login events, etc.). In the same example, a selection of the field 513B causes the under interface 501 to be updated with data associated with alerts generated or received at the monitoring system 200. A selection of the field 513C can cause a ticket portal 243A (FIG. 10A) to be accessed… Continuing the scenario, the system identifies typical transaction patterns with which the particular account is associated. In this example, the system determines that deposits and transactions from the customer account typically occur via an e-banking system, and also occur biweekly. In the same example, the system detects that a transaction from the newly-created checking account was processed via a teller system, and that the transaction occurred outside of the identified biweekly interval… An external system 203 can include one or more systems associated with an entity, such as a financial institution… The external system 203 can include one or more databases 208 that can be accessible to the computing environment 201. The database 208 can store, for example, historical monitoring data, user account data, policies, and configurations. The external system 203 can include a monitor service 210, such as, for example, a native fraud detection service configured for analyzing activities occurring within the external system 203… For example, the EDS service 213 analyze monitoring data 209, including e-banking activities initiated in foreign countries and/or via web proxy services, to identify unusual usage patterns and/or attempted or successful fraudulent actions.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Jinnett with the ability to update the interface with data associated with the alerts as taught by Hernandez, doing so further allows the visualization of the fraud activity and accounts ([0120-0121]).
As per claims 8-10, 13 and 14, claims 8-10, 13 and 14 recite substantially similar limitations to those found in claims 1-3, 6, and 7, respectively. Therefor claim(s) 8-10, 13 and 14 are rejected under the same art and rationale as claims 1-3, 6, and 7. Furthermore, Jinnett discloses a system and processor for implementing the method [0051-0052].
Claims 4 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Jinnett (US Patent Application Publication 2002120477), “Jinnett” in view of Hernandez, et al. (US Patent Application 20210073819), “Hernandez” in view of Mulhim, et al. (US Patent Application Publication 20110258115), “Mulhim”.
As per claim 4, and 11, Jinnett does not expressly disclose the following, Mulhim, however discloses:
wherein the configurable transaction array further comprises a series of logic step questions to extract information regarding a sender country, receiving country, reason of the transaction, type of currency, and other details associated with the transaction. [0032-0033], [0112] According to an aspect of an embodiment, data structures 400, 402, 404 are established by the service hub 102 among the sending MNO 120, the server hub 102 and a bank 130, where the data structures are a current representation of remittance legal and computer interface burden for the MNO 120 by including one or more of authenticated MNO subscriber name according to KYC standard, a remittance amount subject to a certain threshold, remittance occurrence subject to a certain threshold, sending MNO subscriber mobile device number, beneficiary MNO subscriber mobile device number, remittance transaction security code, local currency and destination currency, and target bank information for the remittance beneficiary that is recognized/approved within the financial industry. According to an aspect of an embodiment, the target bank 130 can be approved on remittance transaction basis. The data structure 400, 402, 404 is dynamic by allowing changes on a country by country and/or financial regulation basis. The financial regulatory compliance obligation of the MNO 120 is dynamic as well as automatic based upon the data structures 400, 402, 404 via validation, remittance transaction filtering, profiling and reporting of/on MNO 120, authenticated MNO subscriber name, sender mobile device number, target bank for remittance to beneficiary, beneficiary mobile device number and remittance transaction details basis. According to an aspect of an embodiment, liability boundaries for a remittance among the MNO 120, the server hub 102 and the bank 130 is maintained and/or can by dynamically shifted along the financial regulatory burden continuum (see FIG. 10E) based upon configuration of the data structures 400, 402, 404 and via validation, filtering, profiling and reporting of/on MNO 120, authenticated MNO subscriber name, sender mobile device number, target bank for remittance to beneficiary, beneficiary mobile device number and/or remittance transaction details basis. For example, the data structures 400, 402 and 404 include financial regulatory compliance such as AML, CFT, etc., status information (warnings, yes, no, etc.) as associated with a mobile device number… According to an aspect of an embodiment of the invention, the customer 122 mobile number is used as an account number in the profiling system for AML/CFT along with other parameters and the remitter 122 does not need to have an account number with a bank to benefit from the mobile payment process. According to an aspect of an embodiment, the remitter 122 would register with the MNO 120 for a remittance service to meet the KYC regulations, where the remitter 122 submits evidence artifacts to prove the personal identify and supply cash to any of the MNO 120 service centers or certified partners for remittance purposes. According to an aspect of an embodiment, an end-user 122, 126 subscription with an MNO 120 meets the KYC regulations, and thereby assignment of a mobile device number to a mobile device 124, 128 of the end-user 122, 126 by the MNO 120 implicitly meets KYC regulations for both the remittance sender 122 and the remittance beneficiary 126. According to an aspect of an embodiment, an MNO 120 can be an MNO 120a-n in one or more countries for the remittance sender 122 and/or the remittance beneficiary 126. In other words, by imposing KYC obligations on the MNO 120 according to financial regulations (country and/or international), the mobile device number is useable as an implicit KYC authentication factor. According to another aspect of an embodiment, the beneficiary of the remittance does not need a bank account, but would claim the remittance at a bank 130 by a security code generated by the server hub 102 (discussed in more detail herein). Other form of authentication mechanism for the beneficiary could be required according to the bank 130 country financial regulations and/or the MNO country financial regulations. According to an aspect of an embodiment the bank 130 activates KYC, including the beneficiaries mobile device number in the second country, providing implicit KYC authentication factor for the beneficiary of a remittance transaction to the bank 130. According to an aspect of an embodiment, the KYC that is activated by the MNO 120 and/or bank 130 is based upon one or more of a country passport or other identification recognized internationally or among the first and second countries involved in the remittance transaction as proof of citizenship, residency, and/or person, of the sending subscriber 122 and/or the beneficiary 126.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Jinnett with the ability to use Know Your Customer (KYC) for processing transactions as taught by Mulhim, doing so further ensures transactions are compliant with financial regulatory rules across different countries with different file formats based on a Know Your Customer process for meeting the regulations as dictated [see Abstract, [0112], [0128]].
As per claim 11, claim 11 recites substantially similar limitations to those found in claim 4. Therefor claim 11 is rejected under the same art and rationale as claim 4. Furthermore, Jinnett discloses a system and processor for implementing the method [0051-0052].
Claim 5, 12, 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Jinnett (US Patent Application Publication 2002120477), “Jinnett” in view of Hernandez, et al. (US Patent Application 20210073819), “Hernandez” in view of Levine, et al. (US Patent Application Publication 20200357000), “Levine”.
As per claim 5, and 12, Jinnett does not expressly disclose the following, Levine, however discloses:
determining that the transaction will fail; and determining remediation steps that will be required for the transaction to proceed. [0040], [0061] For example, one of the prediction components 128 may perform a keyword search for hazardous chemicals and their acronyms and equivalents thereof in free text portions of the request 12. When a hazardous chemical is identified, an associated concentration of the chemical may be identified from the request, if present. If the concentration exceeds an applicable regulatory maximum, the prediction component 128 may indicate that the request should be denied. Keyword searches for other items that are likely to impact a regulatory decision may also be performed. Another prediction component 130 may predict whether required data is missing from the request. Another prediction component 132 may input a set of features extracted from the request into a classifier that has been trained on sets of features extracted from prior requests 12 and corresponding agency decisions 26. The classifier outputs a recommended decision and/or a probability for a decision. The number and types of prediction component is not limited to those illustrated… For a particular request to a particular regulator or regulatory body, the system can describe what information is missing from rejected requests. Further, reviewers can use the system 10 to determine what information is most frequently missing from requests and can communicate this to the private sector requestors so that more initial requests are approved.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Jinnett with the ability to describe what information is missing for a request as taught by Levine, doing so further aides in completing the transaction [see Abstract, [0040], [0061]].
As per claim 12, claim 12 recites substantially similar limitations to those found in claim 5. Therefor claim 12 is rejected under the same art and rationale as claim 5. Furthermore, Jinnett discloses a system and processor for implementing the method [0051-0052].
As per claim 17, Jinnett does not expressly disclose the following, Levine, however discloses:
determining that the transaction request will succeed or fail; and determining whether the transaction request can be remedied responsive to a determination that the transaction request will fail. [0040], [0061] For example, one of the prediction components 128 may perform a keyword search for hazardous chemicals and their acronyms and equivalents thereof in free text portions of the request 12. When a hazardous chemical is identified, an associated concentration of the chemical may be identified from the request, if present. If the concentration exceeds an applicable regulatory maximum, the prediction component 128 may indicate that the request should be denied. Keyword searches for other items that are likely to impact a regulatory decision may also be performed. Another prediction component 130 may predict whether required data is missing from the request. Another prediction component 132 may input a set of features extracted from the request into a classifier that has been trained on sets of features extracted from prior requests 12 and corresponding agency decisions 26. The classifier outputs a recommended decision and/or a probability for a decision. The number and types of prediction component is not limited to those illustrated… For a particular request to a particular regulator or regulatory body, the system can describe what information is missing from rejected requests. Further, reviewers can use the system 10 to determine what information is most frequently missing from requests and can communicate this to the private sector requestors so that more initial requests are approved.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Jinnett with the ability to describe what information is missing for a request as taught by Levine, doing so further aides in completing the transaction [see Abstract, [0040], [0061]].
As per claim 18, Jinnett does not expressly disclose the following, Levine, however, discloses:
further comprising determining one or more remedial steps based on the determination that the transaction request will fail, wherein the one or more remedial steps comprise providing additional transaction information for the transaction request. [0040], [0044-0048] [0061] For example, one of the prediction components 128 may perform a keyword search for hazardous chemicals and their acronyms and equivalents thereof in free text portions of the request 12. When a hazardous chemical is identified, an associated concentration of the chemical may be identified from the request, if present. If the concentration exceeds an applicable regulatory maximum, the prediction component 128 may indicate that the request should be denied. Keyword searches for other items that are likely to impact a regulatory decision may also be performed. Another prediction component 130 may predict whether required data is missing from the request. Another prediction component 132 may input a set of features extracted from the request into a classifier that has been trained on sets of features extracted from prior requests 12 and corresponding agency decisions 26. The classifier outputs a recommended decision and/or a probability for a decision. The number and types of prediction component is not limited to those illustrated… For a particular request to a particular regulator or regulatory body, the system can describe what information is missing from rejected requests. Further, reviewers can use the system 10 to determine what information is most frequently missing from requests and can communicate this to the private sector requestors so that more initial requests are approved… For a particular request to a particular regulator or regulatory body, the system can describe what information is missing from rejected requests. Further, reviewers can use the system 10 to determine what information is most frequently missing from requests and can communicate this to the private sector requestors so that more initial requests are approved… In some embodiments, the RCS interface 110 may omit requestor data from the new request 12 that is not required by the regulatory agency for a particular type of request and/or may prompt a requestor to supply additional data 14 that is determined, by the system, to have been omitted. The RCS interface 110 may determine what types of request 12 are needed for the requestor to be able to use a new composition/process and may generate two or more individualized requests 12 for submitting to different regulatory agencies, based on the same set of requestor data 14.
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Jinnett with the ability to describe what information is missing for a request as taught by Levine, doing so further aides in completing the transaction [see Abstract, [0040], [0061]].
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Jinnett (US Patent Application Publication 2002120477), “Jinnett” in view of Hernandez, et al. (US Patent Application 20210073819), “Hernandez” in further view of Song, et al. (US Patent Application Publication 20200311736), “Song”.
As per claim 16, Jinnett does not expressly disclose the following, Song, however, discloses
identifying one or more customers in the transaction data; [0064-0065], [0077] In another aspect of the present disclosure, a computer system also records the identity of the person that decides not to report the detected case. The computer system may compare the decisions made by multiple persons for not reporting suspicious activities of the same suspect(s) to determine whether an investigator is attempting to hide a detected suspect or case… In the above example, if a BSA Officer compares a client's current activities with the client's historical activities to detect any change of behavior, the BSA Officer does not detect anything unusual because the clients have consistently conducted similar transactions each month. If the bank tellers ask the clients about the purpose of the fund transfers, the clients can easily lie. Because these clients conduct their transactions on different days throughout the month, a BSA Officer would not be able to detect any risk on any given day of the month.
performing a source wealth analysis on the one or more customers; [0054] In one aspect of the present disclosure, for fraud detection, a computer system calculates a risk score associated with a transaction based on different factors associated with the transaction. These factors may include historical activities of the account, deviations from the expected activities, location, time, amount, frequency and nature of the transaction, relationships between multiple accounts, type, nature and structure of the account holder, etc.
determining a risk score based on the source wealth analysis for the one or more customers; and [0054] In one aspect of the present disclosure, for fraud detection, a computer system calculates a risk score associated with a transaction based on different factors associated with the transaction. These factors may include historical activities of the account, deviations from the expected activities, location, time, amount, frequency and nature of the transaction, relationships between multiple accounts, type, nature and structure of the account holder, etc.
determining that the risk score is below a threshold to proceed with the transaction request. [0054], [0238-0239] In one aspect of the present disclosure, for fraud detection, a computer system calculates a risk score associated with a transaction based on different factors associated with the transaction. These factors may include historical activities of the account, deviations from the expected activities, location, time, amount, frequency and nature of the transaction, relationships between multiple accounts, type, nature and structure of the account holder, etc… According to aspects of the present disclosure, the intelligent anti-money laundering alert system uses a risk-scoring approach. Each risk factor or a degree of a risk factor may be similar to a branch in a rule-based system. As such, the risk scoring process for producing a total risk score from many risk factors, as described in the present disclosure, may consolidate the information from many rules into the total risk score. For example, if a total risk score is generated from 10,000 risk factors, a user only needs to pay attention to those alerts that have the total risk score over a threshold without the need to evaluate each of the 10,000 risk factors. If a rule-based approach is used, each risk factor may have two possible outcomes, matched or not-matched. The total number of possible combinations of outcomes for 10,000 risk factors is two (2) to the power 10,000 (e.g., 2.sup.10,000). Therefore, an evaluation based on the total risk score has effectively replaced the need to evaluate each of the two (2) to the power 10,000 (e.g., 2.sup.10,000) possible outcomes. Because these 2.sup.10,000 outcomes could potentially generate 2.sup.10,000 different types of alerts, the intelligent anti-money laundering alert system can avoid at least 2.sup.10,000 alerts. Therefore, the intelligent anti-money laundering alert system is an improvement in view of the conventional rule-based system..
It would have been obvious to one having ordinary skill in the art at the time the invention was filed to modify Jinnett with the ability to process transactions based on the users accounts and transactions processing transactions as taught by Song, doing so further helps in identifying money laundering and fraud [0009], [0054].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY S CUNNINGHAM II whose telephone number is (313)446-6564. The examiner can normally be reached Mon-Fri 8:30am-4pm.
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 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.
GREGORY S. CUNNINGHAM II
Primary Examiner
Art Unit 3694
/GREGORY S CUNNINGHAM II/Primary Examiner, Art Unit 3694