MasterCard International Incorporated

[2022] APO 80

IP AUSTRALIA

AUSTRALIAN PATENT OFFICE

MasterCard International Incorporated [2022] APO 80

Patent Application:                2019272056

Title:A system and method of managing data injection into an executing data processing system

Patent Applicant:                   MasterCard International Incorporated

Delegate:  Dr A. Lim

Decision Date:  7 December 2022

Hearing Date:  Written submissions filed on 04 April 2022

Catchwords:  PATENTS – examiner objection – whether the invention is a manner of manufacture – claim language does not definitively claim a way in which the method is carried out by the computer – defining an idea of using computer technologies without further definition of how the technologies facilitate performing the claimed method remains an idea – balance of considerations indicates that the substance of the invention as claimed is an idea – possibility of disturbing the balance of considerations due to the way the invention is described in the specification – opportunity to amend

Representation:  Patent attorney for the applicant:  Spruson & Ferguson

IP AUSTRALIA

AUSTRALIAN PATENT OFFICE

Patent Application:                2019272056

Title:A system and method of managing data injection into an executing data processing system

Patent Applicant:                   MasterCard International Incorporated

Date of Decision:                   7 December 2022

DECISION

I find the invention claimed in each of claims 1-20 of patent application 2019272056 is not for a manner of manufacture.  However, it may be possible to amend the claims to correct this deficiency.  In accordance with regulation 13.4, the final date of acceptance of this application is six (6) months from the date of this decision.

REASONS FOR DECISION

Background

1. Patent application 2019272056 (the present application) was filed by MasterCard International Incorporated (the applicant) on 29 November 2019.  The patent request claims divisional status from patent application 2016291639 (the parent) which has lapsed because of failure to gain acceptance by the final date for acceptance.  The parent is a national phase entry of international patent application PCT/US2016/041964 filed on 13 July 2016.  The present application claims priority from US patent application 14/798,191, filed on 13 July 2015.

2. Since the present application was filed after 15 April 2013, this application is governed by the Patents Act 1990 (the Act) as amended by the Intellectual Property Laws Amendment (Raising the Bar) Act 2012.  Accordingly, the standard of proof that applies to the examination of the present application is the balance of probabilities.  I must accept the present application if satisfied on the balance of probabilities that the application complies with the Act.[1]  If I am not so satisfied, then I can refuse the application.[2]

   [1] Section 49 of the Act as amended.

   [2] Explanatory Memorandum to the Raising the Bar Bill, item 14.

3. A first examination report was issued on 14 December 2020 raising a lack of manner of manufacture, regarding all the claims, as the only objection.  The Examiner noted in the first examination report that the applicant’s submissions and amendments in the parent application had been considered and the Examiner maintained the objection from the second examination report (which was also the last examination report) of the parent.  For completeness, I note that the Examiner had raised two objections in the first examination report of the parent.  These objections were for a lack of manner of manufacture and a lack of inventive step in regard of all claims.  The applicant responded to the first examination report of the parent by filing amendments to the claims on 9 July 2019.  The Examiner considered these amendments to overcome the lack of inventive step objection but maintained the lack of manner of manufacture objection as the sole objection in the second examination report of the parent.  The claims of the present application that were originally filed on 29 November 2019 are the same claims filed for the parent on 9 July 2019.

4. The applicant responded to the first examination report of the present application on 29 September 2021 with submissions explaining why the claimed inventions are directed to patentable subject matter.  A second examination report was issued for the present application on 25 October 2021 maintaining the objection of lack on manner of manufacture.  The applicant responded to the second examination report on 8 November 2021 with further submissions as to a technical problem addressed by the present application and a technical solution provided by the claimed invention.  A third examination report was issued on 6 December 2021 maintaining the objection of lack of manner of manufacture.  The applicant requested to be heard in relation to the outstanding objection on 8 December 2021.

5. While the final date of acceptance of the present invention was 14 December 2021, when the Commissioner makes a decision in writing in relation to an examiner’s report, the time of gaining acceptance is extended by way of reg 13.4(1)(g) and, if appropriate, reg 13.4(3).

   The specification

6. In this decision, I am considering the specification as filed on 29 November 2019 since no amendments have been proposed up to the present point in time.

   The invention as described

7. The specification relates generally to processing data and, more particularly, to a system and method that manages an injection of external data into a processing system during execution.[3]

   [3] The specification at page 1, lines 6-8.

8. The specification describes some known processing systems to operate on data that is readily available to the processing system; for example, data that has been stored in a known accessible location.  The specification notes that in some instances, a better processing result could be realised if additional data were available, particularly data that may be stored in locations external to the processing system.  However, the additional data stored in a location external to the processing system may only become available at certain periodic intervals.[4]

   [4] The specification at page 1, lines 9-15.

9. The specification describes the problem encountered by known processing systems to be the feasibility and effort involved in making additional data available to the systems, particularly data located external to the system.  The specification states:

   “If the current processing system is already executing, it may not be feasible to suspend execution, make changes to the processing system that would identify the new data and communicate a location of the new data to the processing system, and start-up the processing system again.  Additionally, some amount of modification to the processing system may be required for the processing system to handle the new data.  Such modification to the processing system may involve many people and many organizations, many of whom are already involved in other tasks.” (emphasis added) [5]

   [5] The specification at page 1, lines 15-22.

10. An example of such a processing system is a system for handling fraud prevention in a payment card network.  The specification describes that an ability of a processing system to quickly detect fraud “attacks” on payment card issuers may result in timely servicing of the issuers’ system and minimise monetary losses caused by the attacks.[6]  The specification states:

    “Often, specific off-line analytics or data provide insight as to how to prevent future instances of that particular fraud attack from occurring, but the off-line analytic data needs to be loaded into the fraud processing engine so that actions can be taken to block the future fraudulent transactions.

    Current processes to extract and load this off-line data into the fraud processing engine take an excessive amount of time to plan and implement.  The need to create code, modify jobs and the use of a ‘waterfall’ methodology does not provide for an easy solution to this problem.  Additionally, resources needed to perform these tasks are often already working on other tasks.  Placing the tasks in queue for the resources to become available further delays the time it takes to implement changes that permit this off-line data to be made accessible to the fraud processing engine system.” (emphasis added)[7]

    [6] The specification at page 1, lines 23-26.

    [7] The specification at page 1, line 26 to page 2, lines 1-8.

11. I understand that, at the priority date of the present application, a problem for processing systems used in a payment card network was the feasibility and effort (in terms of time and human resources) involved in suspending the system that is already in operation, making changes to the system that would identify new data relevant for detecting and preventing fraudulent transactions, communicating the new data to the system, adjusting the system to handle the new data and starting the system up again.

12. The specification describes three aspects of the invention each of which I will elaborate on.  The first aspect of the invention is a computer-implemented method of modifying an execution of a processing system during runtime which uses a computing device with at least one processor and at least one memory device.  The computer-implemented method is described to have the following steps:

    ·receiving an indication of data or instructions being available for modifying the execution of the processing system during runtime;

    ·determining at least one data element associated with the indication of data or instructions;

    ·generating metadata based on at least one of the indication and the determined at least one data element; and

    ·periodically executing a job, the job reads the metadata and modifies a workflow of the processing system based on the metadata.[8]

    [8] The specification at page 2, lines 13-19.

13. The second aspect of the invention is a system of modifying an execution of a fraud risk management system on a payment card network during runtime which includes one or more memory devices and one or more processors communicatively coupled to the one or more memory devices, the one or more memory devices including computer-executable instructions that when executed by the one or more processors cause the one or more processors to perform programmed steps of:

    ·receiving an indication of a fraud attack on the payment card network;

    ·determining at least one data element associated with the fraud attack;

    ·generating metadata based on at least one of the fraud attack and the at least one data element; and

    ·periodically executing a job, the job reads the metadata and modifies a workflow of the fraud risk management system based on the metadata.[9]

    [9] The specification at page 2, lines 20-30.

14. The third aspect of the invention is a non-transitory computer-readable storage media having computer-executable instructions embodied on the media which cause a processor to implement the above-mentioned computer-implemented method when executed by the processor.[10]

    [10] The specification at page 2, line 31 to page 3, line 5.

15. The specification describes embodiments of the methods and systems that have the following capabilities:

    ·Using an automated job building module to generate tasks needed to locate data external to an executing processing system;

    ·Building a defined table that can be read by an online or batch run process;

    ·Supplying metadata to the executing processing system indicating an updated defined table is available and should be used; and

    ·Periodically executing a job configured to read the metadata and modify a workflow or the processing system based on the metadata.[11]

    [11] The specification at page 4, lines 10-14, and page 4 line 32 to page 5 line 2.

16. The embodiment exemplified relates to fraud prevention data in a fraud risk management (FRM) system that is operating in combination with a payment processing system.  The specification states that:

    “[r]ather than generating new code to inject off-line analytic data used to detect new fraud attacks, many of the tasks and processes can be re-used as new fraud attacks are detected...  Using this approach, off-line analytic data can be injected into, for example, a business rule engine of a fraud risk management system in a shorter time than currently possible.” (emphasis added)[12]

    [12] The specification at page 4, lines 15-22.

17. I understand that in an embodiment of the computer-implemented method a job building module automates the generation of tasks which locates additional data.  Therefore, I understand the specification to describe an embodiment that facilitates the location and introduction of additional data into the processing system using reusable programming code.  This embodiment provides an advantage of introducing the additional data into the processing system in a shorter time than is possible with the prior art systems.

18. The specification states that although described in relation to a FRM system that is used in combination with a payment processing system, the techniques described may relate to any data processing system.  For example, financial transaction processing may be enhanced using a data element that may indicate who is a “good” customer, who spends in the top 10% of all customers, or what state or location does a customer normally transact in.[13]

    [13] The specification at page 4, lines 22-28, and page 17, lines 13-17.

19. The specification states that the methods and systems described provide a framework for injecting off-line analytics and other data into a real-time business rule engine.  The framework is described as utilising reusable jobs configured to generate a user defined table of metadata for altering an execution of a running processing system.  This approach is described to be a cost-effective and reliable means to alter the execution of a processing system during runtime.[14]

    [14] The specification at page 25, lines 13-22.

    A payment card processing system for detecting fraudulent transactions

20. An example of a multi-party payment card system 20 which enables payment-by-card transactions between merchants 24 and cardholder 22 is shown in Figure 1 of the present application.[15]  Figure 1 is reproduced here for convenience.

    [15] The specification at page 6, lines 22-23; Figure 1.

21. The specification describes one embodiment being a financial transaction card system, such as a payment card network 28 operated by MasterCard International Incorporated.[16]

    [16] The specification at page 6, lines 24-27.

22. Payment card network 28 is described as including a plurality of special purpose processors and data structures stored in one or more memory devices communicatively coupled to the processors, and a set of proprietary communications standards promulgated by MasterCard International Incorporated for the exchange of financial transaction data and the settlement of funds between financial institutions that are members of the payment card network.  The specification states that the use of the phrase “financial transaction data” includes a unique account number associated with a cardholder using a payment card issued by an issuer, purchase data representing a purchase made by the cardholder, the purchase data including a type of merchant, amount of purchase, date of purchase, and other data.  The account number and purchase data may be transmitted between any parties of the payment card system 20.[17]

    [17] The specification at page 6, line 27, to page 7, line 4.

23. The specification describes that in a typical payment card system, a financial institution called the “issuer” issues a payment card, such as a credit card, to a consumer, or cardholder, 22 who uses the payment card to offer payment for a purchase from a merchant 24.  To accept payment with the payment card, merchant 24 must normally establish an account with a financial institution that is part of the financial payment card network.  This financial institution is usually called the “merchant bank”, the “acquiring bank”, or the “acquirer”.[18]

    [18] The specification at page 7, lines 5-11.

24. When cardholder 22 offers payments for a purchase with a payment card, merchant 24 requests authorisation from a merchant bank 26 for the purchase.  The request may be performed over the telephone but is usually performed using a point-of-sale terminal, which reads the cardholder’s account information from a magnetic stripe, a chip, or embossed characters on the payment card, and communicates electronically with the transaction processing computers of merchant bank 26.  Alternatively, merchant bank 26 may authorise a third party to perform transaction processing on its behalf.  In this case, the point-of-sale terminal will be configured to communicate with the third party.  Such a third party is usually called a “merchant processor”, an “acquiring processor”, or a “third party processor”.[19]

    [19] The specification at page 7, lines 11-21.

25. The specification describes that by using payment card network 28, computers of merchant bank 26 or merchant processor will communicate with computers of an issuer bank 30 to determine whether the cardholder’s account 32 is in good standing and whether the purchase is covered by the cardholder’s available credit line.  Based on these determinations, the request for authorisation will be declined or accepted.  If the request is accepted, an authorisation code is issued to merchant 24.[20]

    [20] The specification at page 7, lines 22-27.

26. The specification describes that after a purchase has been made, a clearing process occurs to transfer additional transaction data related to the purchase among the parties to the transaction, such as merchant bank 26, payment card network 28, and issuer bank 30.  More specifically, during and/or after the clearing process, additional data, such as a time of purchase, a merchant name, a type of merchant, purchase information, cardholder account information, a type of transaction, product or service for sale information, information regarding the purchased item and/or service, and/or other suitable information, is associated with a transaction and transmitted between parties as transaction data, and may be stored by any of the parties to the transaction.[21]

    [21] The specification at page 8, lines 15-24.

27. After a transaction is authorised and cleared, the specification describes a settlement process to occur among the merchant 24, merchant bank 26 and issuer bank 30.  Settlement is described as the transfer of financial data or funds among the merchant’s account, merchant bank 26, and issuer bank 30.[22]  The specification states that usually transactions are captured and accumulated into a “batch”, which is settled as a group.  The specification describes that, more specifically, a transaction is typically settled between issuer bank 30 and payment card network 28, and then between payment card network 28 and merchant bank 26, and then between merchant bank 26 and merchant 24.[23]

    [22] The specification at page 8, lines 25-28.

    [23] The specification at page 8, lines 28-32.

28. I understand that at the priority date of the present application, the normal setup of a payment card processing system included the following parties:

    ·a financial institution, an issuer, which issues a payment card, such as a credit card;

    ·a cardholder who uses the payment card to offer payment for purchases;

    ·a merchant who offers goods or services for purchases; and

    ·a merchant bank which is a financial institution that is part of the payment card processing system

29. I also understand that, at the priority date of the present application, when the cardholder offers payment for a purchase with their payment card, the merchant normally requests authorisation from a merchant bank for the purchase.  The authorisation is usually done using a point-of-sale terminal which reads the cardholder’s account information on the payment card and communicates electronically with computers of the merchant bank or a third-party processor.  The computers of the merchant bank, or third-party processor, will then communicate with computers of the issuer bank, using a payment card network, to determine whether the cardholder’s account is in good standing and whether the purchase is covered by the cardholder’s available credit line.

1. After the purchase has been authorised, additional data associated with the purchase transaction is normally transmitted between parties as transaction data and may be stored by any of the parties to the transaction.  The transaction is normally settled between the issuer bank and payment card network, and then between payment card network and merchant bank, and then between merchant bank and merchant.  Usually, transactions are accumulated and settled as a batch.

2. The specification also describes that payment card network 28 is configured to interface with FRM (fraud risk management) module 34.  FRM module 34 is configured to monitor the activity of payment card system 20, determine potential fraudulent transactions and alert or log such transactions.[24]  FRM module 34 operates in conjunction with an off-line data injection module 36.  Off-line injection module 36 is described as “configured to receive metadata in a user defined table (UDT) and format an update file from the data in the UDT.”[25]  The update file is described to be “loaded into system 20 to modify the execution of system 20 to, for example, process data that may be used to thwart a particular fraud attack or to provide additional data to an issuer or merchant as requested.”[26]

   [24] The specification at page 8, line 33 to page 9, line 1.

   [25] The specification at page 9, lines 3-4.

   [26] The specification at page 9, lines 4-7.

3. I understand the specification as describing the (a) FRM module 34 to be a component of a processing system that monitors the payment card system 20, determines potential fraudulent transactions and alerts such transactions; and (b) off-line injection module 36 to be a component of the processing system that receives metadata that is used to build an update file and consequently introduce additional data into the payment card system.  I further understand this additional data may be used by the processing system to thwart a particular fraud attack or provided to an issuer or merchant, who I infer will use the additional data to assess whether a fraudulent transaction has occurred.

4. Payment card network system 28 or issuer bank 30, or both, store financial transaction data, such as a type of merchant, amount of purchase, date of purchase, in a database 120 shown in Figure 2 of the present application.[27]  Figure 2 is reproduced here for convenience.

   [27] The specification at page 8, lines 6-8.

5. Figure 2 is a simplified block diagram of an example payment processing system 100 including the exemplified FRM module 34 of the present invention.  The payment processing system 100 is described as having a plurality of computer devices which include the server system 112, client systems 114, 115, FRM module 34, an off-line data injection module 36 and merchant point-of-sale (POS) terminals 118.  The specification describes that FRM module 34, which is in communication with server system 112, is configured to receive information relating to data to be injected into payment card system 20 (of Figure 1) during the execution of system 20 and store the information in a memory device.  FRM module 34 is also configured to operate with off-line data injection module 36.[28]

   [28] The specification at page 9, lines 8-19; Figure 2.

6. Client systems 114 are described as a plurality of computers including a web browser, such that server system 112 is accessible to client systems 114 using the internet.  Client systems 114 are interconnected to the Internet through many interfaces including a network, such as a local area network (LAN) or a wide area network (WAN), dial-in-connections, cable modems, and special high-speed Integrated Services Digital Network (ISDN) lines.  Client systems 114 could be any device capable of interconnecting to the Internet including a web-based phone, personal digital assistant (PDA), or other web-based connectable equipment.[29]

   [29] The specification at page 9, lines 20-30.

7. POS terminals 118 are described to be any device capable of interconnecting to the Internet and includes an input device 119 capable of reading information from a consumer’s financial transaction card.[30]  Examples of input device 119 include a web-based phone, PDA, or other web-based connectable equipment associated with, or controlled by, a merchant managing a customer making a purchase.[31]  POS terminals 118 are connected to client systems 114 and may be connected to server system 112.[32]

   [30] The specification at page 10, lines 2-4.

   [31] The specification at page 10, lines 7-14.

   [32] The specification at page 9, lines 31-34.

8. Database server 116 is described as connected to database 120.  Database 120 stores different types of data including:

   ·Transaction data, generated as part of the sales activities, such as data relating to merchants, account holders or customers, issuers, acquirers or purchases made;

   ·Account data, such as a cardholder name, cardholder address, primary account number (PAN) associated with the cardholder’s name or other account identifier;

   ·Merchant data, such as a merchant identifier which identifies each merchant registered to use the network, and instructions for settling transactions including merchant bank account information; and

   ·Store purchase data associated with items being purchased by a cardholder, authorisation request data, picture files associated with the item or service for sale, name, price, description, shipping and delivery information or instructions for facilitating the transaction.[33]

   [33] The specification at page 10, line 19 to page 11, line 5.

9. In one embodiment, database 120 is a centralised database stored on server system 112 and can be accessed by potential users when they log onto server system 112 through one of the client systems 114.  In another embodiment, database 120 is stored remotely from server system 112 and not centralised.[34]

   [34] The specification at page 10, lines 19-23.

10. The specification describes that in the example embodiment, server system 112 is associated with the payment card network 28 (shown in Figure 1) and is referred to as an interchange computer system.  Server system 112 is used for processing transaction data.[35]  In the example embodiment, one of the client systems 114 may be associated with acquirer bank 26 (shown in Figure 1) while another one of the client systems 114 may be associated with issuer bank 30 (shown in Figure 1).  POS terminal 118 may be associated with a participating merchant 24 (shown in Figure 1) or may be a computer system, or mobile system, used by a cardholder making an on-line purchase or payment.[36]  Each party involved in processing transaction data is associated with a computer system shown in payment processing system 100 such that the parties can communicate with one another.[37]

    [35] The specification at page 11, lines 12-15.

    [36] The specification at page 11, lines 6-11.

    [37] The specification at page 11, lines 23-25.

11. The specification defines payment cards to be cards or devices that can be used as a method of payment for performing a transaction.  Examples of payment cards include credit cards, debit cards, prepaid cards, gift cards and any device that can hold payment account information, such as mobile phones, PDAs, key fobs, or other devices.[38]

    [38] The specification at page 11, lines 26-33.

12. The specification describes a configuration of database 120 within database server 116 of server system 112.  This embodiment is shown in Figure 3B which is reproduced here for convenience.  Server system 112 can receive requests from client system 114 via the internet.

13. Database 120 is coupled to several separate components within server system 112 which perform specific tasks.  Server system 112 includes:

    ·A receiving component 164 for receiving an indication of data or instructions being available for modifying the execution of the processing system during runtime;

    ·A determining component 166 for determining at least one data element associated with the indication of data or instructions;

    ·A generating component 168 for generating metadata based on at least one of the indication and the determined at least one data element; and

    ·An execution component 170 for periodically executing a job, the job reads metadata and modifies a workflow of the processing system based on the metadata.[39]

    [39] The specification at page 13, lines 7-20.

14. The specification describes storage device 134 as any computer-operated hardware suitable for storing or retrieving data or performing both functions.  The storage device 134 includes one or more hard disk drives.  In some embodiments, the storage device 134 is integrated in the server system.  In other embodiments, the storage device 134 is external to the server system.  For example, storage device 134 may include storage area network (SAN) or network attached storage (NAS) system[40]

    [40] The specification at page 15, lines 22-30.

15. The specification describes that database 120 is divided into a plurality of sections, including but not limited to, a transaction and purchase data section 194, a merchant data section 196, and a cardholder account data section 198.  These sections within database 120 are interconnected to update and retrieve the information as required.[41]

    [41] The specification at page 13, lines 26-30.

    Modifying the execution of the processing system

16. The specification describes that during processing of payment card transaction in real-time, rules that specify how each transaction is to be processed are executed by payment processing system 100.  Some rules use one or more sets of data points that are stored, retrieved, or otherwise accessible from sources external to the payment processing system 100 or the multi-party payment card system 20.  Each set of data points can include many hundreds of data points.  Some rules are executed for each payment card transaction.  Other rules are executed upon a threshold or trigger event.[42]  I understand the rules being referred to in this portion of the specification to be rules which describe the process of administering the payment card transactions.

    [42] The specification at page 16, lines 12-19.

17. The specification then explains that “when… a fraud attack or other need for additional rules occurs, new rules are implemented to receive new data related to remediating the fraud attack or fulfilling the other need for initiating the new rules”.  The specification also describes that “the new rules are specified as metadata for one or more of the [UDTs]”.[43]  I will discuss what UDTs include shortly.

    [43] The specification at page 16, lines 19-23.

18. As the specification states that “new rules are implemented to receive new data…”, I infer one aspect of the term “new rules” relates to the operation of a computer (of the processing system) itself.  That is, I understand that the new rules relate to the operation of the computer to introduce additional data into the processing system, rather than the process of administering a payment card transaction.  Therefore, I understand the term “new rules” as used in the specification refers to two different aspects of up-to-date rules.  Firstly, I understand “new rules” can mean up-to-date rules relating to the administrative processes of the payment card transaction, with the “new rules” being implemented to manage the fraud attack.  Secondly, I understand “new rules” can mean up-to-date rules relating to the operation of a computer (of the processing system), with the “new rules” being implemented to introduce additional data into the processing system.  I further understand that the introduction of additional data into the processing system by the “new rules” consequently affects how a fraud attack is managed.  My understanding is consistent with the examples I previously discussed regarding how the execution of system 20 is described to be modified.  This understanding is also consistent with how UDTs are built as will be explained shortly.

19. Figure 6 of the specification schematically shows the process for modifying the execution of a processing system.  I understand the embodiment shown in Figure 6 to be a processing system that includes a FRM module 34 and an offline data injection module 36.[44]  Figure 6 is reproduced here:

    [44] The specification at page 3, lines 21-22, and page 16, line 10 to page 17, line 10.

20. The specification describes that a set of data points are determined 602 which facilitate writing rules for the processing system.  The rules may increase acceptance of payment card transactions or reduce fraud in the payment card network 28 shown in Figure 1.[45]

    [45] The specification at page 16, lines 24-28.

21. A proper source of all data points is determined 604 and business requirements for the data points are created and tracked.  Code, such as, but not limited to, SQL, is used to generate 606 the data points based on the business requirements.  Validation (QA) 608 of a data result set is performed.  A user defined table (UDT) 610 is defined 612 in the processing system.  The new UDT configurations are automatically included in the runtime during the next scheduled batch execution 616.[46]

    [46] The specification at page 17, lines 4-6.

22. UDT 610 includes metadata, data source, change data capture (CDC) type, SQL commands to extract the data and an automation indicator.[47]  The specification describes the metadata to be in the form of UDT data elements.  The metadata is stored in a run-time server (RTS) database 615.[48]  A custom job is built 614 if the extraction of data is too complex for a simple SQL job.[49]

    [47] The specification at page 16, line 29 to page 17, line 2.

    [48] The specification at page 16, line 34; page 17, lines 2-3.

    [49] The specification at page 17, lines 3-4.

23. A CDC type indicates an amount of data that will be updated.  Example CDC types include FULL, indicating the entire file will be updated, and DELTA, indicating only a portion of the file will be updated and the remainder left unchanged.  A DELTA update can conserve resources due to the much smaller file that is used in the update; for example, just a few records versus many millions of records.[50] 

    [50] The specification at page 18, lines 24-28.

24. The specification describes a tool architecture 700, shown in Figure 7, for producing jobs for updating UDT 610 to consequently inject updated data or instructions into the process which is executing on offline data injection module 36 (shown in Figure 1).  Figure 7 is reproduced here.

25. Tool architecture 700 includes a business environment 702, a technical environment 704, a production environment 706 and a rule execution environment 708.  In the example embodiment using the offline data injection module 36 communicatively coupled to network 28, data from production environment 706 is continuously monitored during operation to detect events that may evidence fraud in one or more transactions.  Such data may be located in data sources, for example, Fraud DataMart 710, Expert Monitoring System (EMS) 712 and SAFE 714.[51]

    [51] The specification at page 17, lines 20-27.

26. Evidence of fraud is transmitted to the fraud analysis systems in the business environment 702.  For example, fraud evidence may be received from production environment 706 and automatically analysed or analysed using a human fraud analyst or analysed using a combination of both to verify a fraud attack has occurred.[52]

    [52] The specification at page 17, lines 27-31.

27. The data resulting from the fraud analyses is sent on to a rule analyst which determines what data is needed to generate a solution to the fraud attack and where the data resides.[53]  The specified data is described as being used to define UDTs and the metadata to be captured.  Additionally, database code used to extract the data is generated that includes the data location, frequency of extraction of the data, and a location to return the data to.[54]

    [53] The specification at page 17, lines 31-33.

    [54] The specification at page 17, line 33 to page 18, line 2.

28. The specification describes that jobs are prepared based on the specified data.  When the jobs are executed in, for example, a batch run process, data is extracted and made available to offline data injection module 36 during runtime without stopping the execution of offline data injection module 36.  Offline data injection module 36 operates to completely automate the building, extraction, transformation and loading of data out to the rule execution environment 708.[55]

    [55] The specification at page 18, lines 2-8.

29. Figure 8 of the specification, reproduced here, illustrates the process of building UDTs in offline data injection module 36.  Figure 8 represents the process of building UDTs as a batch process workflow.

30. A UDT is configured to have a header, detail record, trailer record and any CDC needed.[56]  The header includes, for example, an identification ID for identifying the UDT to the system, a customer identity and CDC type.[57]  The trailer is a mechanism for indicating, from an audit perspective, how many records are in the file.  Cross-checking of the number of records indicated in the trailer to the actual number of records in the file enables validation of the data transfer process.[58]

    [56] The specification at page 17, lines 2-8.  The header-detail-trailer format of a UDT is illustrated in Figure 12 of the specification and discussed in more detail later in the decision.

    [57] The specification at page 18, lines 24-25; page 20, lines 29-30.

    [58] The specification at page 21, lines 26-29.

31. At the start 802 of batch process workflow 800, initialization 804 occurs, parameters are read in 806, for example, passwords are retrieved from crypto vault 810, and metadata 812 that is used to guide the operation of batch process workflow 800 is received.  The metadata includes an identification and connection to databases needed during the execution of batch process workflow 800.[59]  I understand the specification to be describing that metadata is used to guide the process of building the UDTs in the batch process workflow.  I also understand that some of the functions of the metadata are to (a) identify a database (data source) needed to execute the batch process workflow and (b) provide a means of connecting to the databases.  My interpretation is consistent with a description in the specification that the metadata contains instructions for building UDT 610.[60]

    [59] The specification at page 18, lines 9-14.

    [60] The specification at page 19, lines 6-8.

32. Each database may be associated with a separate UDT.  For example, in some embodiments, UDT A is from an Oracle® database, UDT B is from a data warehouse appliance, and UDT C is from IBM® DB2 database.  Batch process workflow 800 checks for more records to be processed.  Where no more records are available, clean-up processing is conducted 816 and the batch process ends 818.[61]

    [61] The specification at page 18, lines 15-21.

33. If more records 820 are available, batch process workflow generates 822 a header using from real-time server.  The header includes for example a customer identity and a CDC type.  UDT details are added 826 from various sources specified in the metadata, such as SQL script 828, FDM (Fraud DataMart) 830 and RDR (an Oracle® database) 832.  If the update is indicated 834 as being a DELTA change, batch process workflow 800 reads the previous file 836 and adds 838 the DELTA changes.  The updated file is delivered 840 as the completed UDT 610 and archived.  If the update will be a FULL update, the updated file is delivered 840 as the completed UDT 610 and archived.  The UDT is then pushed to rule execution environment 708 (shown in Figure 7).[62]

    [62] The specification at page 18, line 22 to page 19, line 2.

34. An example of a listing of UDT 610 is shown in Figure 10 which is reproduced below.  The UDT includes job designs built to implement the automation of UDT data injection by offline data injection module 36.  All the metadata needed by the jobs are stored in, for example, Oracle®, EMS (Expert Monitoring System) or RTS (run-time server) schema.  UDT 610 is described as linked to data source table 1002 and another table 1004 with data on the customer.[63]

    [63] The specification at page 19, lines 10-14.

1. The specification describes a formatting module 1200 for automating the building process of UDT 610.  Figure 12, reproduced below, is a schematic diagram of the jobs handled by formatting module 1200 when formatting UDT 610 so that the update file can be uploaded by the batch process workflow previously described.[64]  I consider that a skilled person would understand “job” to mean a set of computer instructions specifying a unit of work to be performed by a computer system.

   [64] The specification at page 20, lines 1-12.

2. The specification describes UDT 610 as a file which is formatted with different header lines, data in a detailed section and a trailer.  UDT 610 includes off-line analytics that is to be loaded into an executing process.[65]

   [65] The specification at page 20, lines 9-10.

3. The specification describes that at block 1202, formatting module 1200 connects to a database and extracts the metadata for UDT 610 from the database.[66]  I understand the job represented by block 1202 as the instructions to connect to a database and extract metadata from the database for building a UDT.  This database, for example a FRM repository, is described to have been created by rule authors.  The metadata in the database is described to have been entered into the database by the rule authors.[67]  The metadata, for example, includes column names for UDT 610, when UDT 610 should be run and whether UDT 610 needs to do any type of change data capture between the last time it ran and the current run time.[68]  Each UDT 610 is designed by a FRM analyst with metadata specific for the job task.  For example, a merchant risk UDT can include a merchant ID, a merchant location, and a merchant risk score.[69]

   [66] The specification at page 20, line 12-13.

   [67] The specification at page 20, lines 10-12 and 16-17.

   [68] The specification at page 20, lines 13-16.

   [69] The specification at page 20, lines 20-22.

4. The jobs represented by blocks 1204 and 1206 are described to “pivot the data received from block 1202” so that it can be “put on a record”.[70]  The specification describes that much of the information in databases is organised in a row format and “blocks 1204 and 1206 pivot data up from a row-by-row to a columnar format”.[71]  I understand that the jobs represented by blocks 1204 and 1206 to format the data received from a database so that the data is in a form that can be used to build the UDT and additional data is subsequently uploaded by the batch process workflow.

   [70] The specification at page 20, lines 18-20 and lines 25-26.

   [71] The specification at page 20, lines 19-20 and lines 27-28.

5. At block 1208 three headers are built into the UDT.  One header includes an identification which identifies the UDT to the system and validates where data will be stored when the UDT is uploaded.[72]  Another header includes whether the CDC type is DELTA or FULL.  For example, a country list may be fully replaced each time UDT 610 is executed where it only has 250 listings.  In this case, the list in the source is used to completely replace the list within the target.  However, where there are hundreds or more listings, and only a small portion of the data has changed (for example, 1% of the data), it would be more efficient to perform a DELTA update.[73]  The final header includes a system date that the UDT was generated for the purposes of an audit, for example.[74]

   [72] The specification at page 20, lines 29-33.

   [73] The specification at page 21, lines 1-8.

   [74] The specification at page 21, lines 10-12.

6. The process of determining the data that will be inserted into the target file begins at block 1210.  Where a full replacement is to be performed, the existing information will be replaced when the update executes.  Where only a portion of the existing information will be replaced, that is the CDC is DELTA, the jobs represented by blocks 1210, 1212, 1214 and 1216 compare the existing information to the data currently in the source.  If the existing information will not change in the update, this portion of data will be passed over. If the existing information need changes, this portion of the data will be updated.  Where there is no existing information, additional data will be added.  The specification describes this as a more efficient update which may conserve computing resources and speed up the update process.[75]

   [75] The specification at page 21, lines 13-25.

7. The job represented at block 1218 is the generation and formatting of a trailer for the UDT.  The specification describes the trailer as a mechanism for counting and indicating now many “records are in the file”.  The specification explains that cross-checking the number of records indicated in the trailer to the actual number of records in the file permits validation that all the data was received.  The absence of a trailer record, for example, may indicate that the transfer was incomplete.[76]  I understand “records in the file” to be collections of additional data which the UDT will make available when the UDT is uploaded by the batch process workflow.

   [76] The specification at page 21, lines 26-32.

8. The headers, detail records and trailer are joined at block 1220 to generate the update file, this being the UDT.  The update file (UDT) is copied to a location (block 1222) where the system will upload the UDT.  Cleaning processes, such as deleting temporary files, resetting processing modules used and logging the completed job, are performed in blocks 1224, 1226 and 1228.[77]

   [77] The specification at page 22, lines 2-6.

9. The specification illustrates an embodiment of a rule manager input user interface 1300 in Figure 13, which is reproduced here.

10. The rule manager input user interface 1300 is used to select and schedule a UDT for implementing into the payment card processing system.  In the example embodiment, selecting an Expert Monitoring System (EMS) tab 1302 displays an EMS selection function menu 1304 which allows a user to select a UDT selection 1306.  Selecting UDT selection 1306 opens a UDT input interface 1308 which includes multiple input fields, for example UDT type name 1314, numerical ID 1312, which enables a user to identify the desired UDT that is required for implementing into the processing system.  The content of the UDT can be viewed in the element table.  The schedule field 1320 enables selecting a time for implementing the UDT.  Although shown as daily intervals, the specification explains that schedule field allows any desired temporal or event-based scheduling.[78]

    [78] The specification at page 22, lines 7-25.

11. It is useful to summarise how the specification uses some terms (as explained and discussed above) to understand the invention as described.

    Processing system

12. I understand the specification to describe a “processing system” as including (a) a system that has multiple computing devices which communicate with one another (for example, multi-party processing system 20 and payment processing system 100), or (b) a system that has a single computing device (for example, a computer with an FRM module and offline data injection module 36).

    Workflow

13. I understand the specification to describe a “workflow” as including a series of jobs which are performed by a computer (or component of a computer, or processing system).  In the context of the invention as described, the purpose of the workflow is to build the UDTs.

    UDTs

14. I understand the specification to describe the UDT as including:

    ·metadata “in the form of UDT data elements”;

    ·data source;

    ·change data capture (CDC) type;

    ·SQL commands to extract data; and

    ·an automation indicator.[79]

    I understand from the description that metadata is “in the form of UDT data elements” to the extent that metadata is a component of the UDT as a data element, and the data element is associated with the fraud attack.  My understanding is based on a description in the specification that explains:

    “…computer executable instructions that when executed by the one or more processors cause the one or more processors to perform the programmed steps of receiving an indication of a fraud attack on the payment card network, determining at least one data element associated with the fraud attack, generating metadata based on at least one of the fraud attack and the determined at least one data element, and periodically executing a job, the job reads the metadata and modifies a workflow of the fraud risk management system based on the metadata.”[80]

    I infer that the automation indicator that is included in the UDT (listed above) is a job which automates the injection of additional data (by offline data injection module 36).[81]  I also understand that a combination of the various components of the UDTs as exemplified in the specification (listed above) facilitate a method that makes additional data available to the computer of the processing system.  This additional data consequently affects how a fraud attack is managed.

    [79] The specification at page 16, line 29 to page 17, line 3.

    [80] The specification page 2, lines 23-30.

    [81] The specification at page 19, lines 10-11.

    Metadata

15. I understand the specification to describe metadata as having the following functions:

    ·providing instructions for building the UDT in a batch process workflow, for example, the metadata comprises

    oa description of data for building the UDT – the data is associated with the fraud attack, as I previously discussed;

    oinstructions for when the UDT should be run;

    oinstructions for whether the UDT needs to do any type of change data capture (that is, whether a full or partial replacement of data is needed) between the last time it ran and the current run time

    ·identifying a database (data source) needed to execute the batch process workflow for building the UDT;

    ·providing a means of connecting to the databases; and

    ·indicating an updated UDT is available and should be used.[82]

    [82] The specification at page 4, lines 13-14; page 18, lines 9-14; page 19, lines 6-8; page 20, lines 13-16.

    Jobs

16. I understand the jobs described in the specification as including computer instructions for:

    ·generating a UDT of metadata for modifying an execution of a processing system during runtime;

    ·reading metadata from a database that rule authors have created;

    ·connecting to a database and extracting the metadata for a UDT from a database;

    ·formatting the data received from a database so that the data is in a form that can be used to build the UDT, and additional data is subsequently uploaded by the batch process workflow;

    ·determining whether UDT will execute a full or partial replacement of data;

    ·generating a trailer mechanism which is used to validate data transfer; and

    ·implementing the automation of data injection (by offline data injection module 36).[83]

    [83] The specification at page 19, lines 10-14; page 20, lines 1-26; page 21, lines 1-32; page 25, lines 13-19.

    Summary of the invention as described in the specification

17. I understand an invention described in the specification is a method of modifying the execution of a computer (this being the processing system) while the computer is in operation to manage fraud risks in a payment card network system.  In the exemplified embodiment, the method includes steps performed by a computer that communicates with a payment card network, the computer includes an FRM module 34 and offline data injection module 36, the method comprising the steps of:

    1.Receiving from the payment card network, by the FRM module 34 of the computer, payment card transactions being processed by the payment card network;[84]

    [84] The specification at page 8, line 33 to page 9, line 1.

    2.Processing, by FRM module 34 and/or offline data injection module 36 of the computer, the payment card transactions to detect fraudulent transactions;[85]

    [85] The specification at page page 8, line 33 to page 9, line 1; page 17, lines 22-25.  The way of processing payment card transactions to detect fraudulent transactions does not appear to be explicitly disclosed in the specification.  However, I consider it is reasonable to infer that the person skilled in the art would understand that process involves the use of instructions specified in a computer code.

    3.Receiving an indication, by FRM module 34 of the computer, of a fraud attack on the payment card network system – the indication is an alert that information relating to additional data is available to be injected into payment card network system 20 during the runtime of the computer;[86]

    [86] The specification at page 2, lines 25-26; page 9, lines 15-18; page 13, lines 13-15; page 23, lines 25-28.

    4.Determining, by automated fraud analyses systems or human fraud analysts, the data that is needed to generate a solution to the fraud attack and where the data resides;[87]

    [87] The specification at page 17, lines 27-33.

    5.Building, by offline data injection module 36 of the computer, a user-defined table (UDT) to specify the additional data for generating a solution to the fraud attack wherein:

    a.the UDT includes metadata, data source, change data capture (CDC) type, SQL commands to extract the data and an automation indicator;

    b.the metadata includes instructions which describe the data for building the UDT, when the UDT should be run, and the CDC type required (whether a full or partial replacement of data is needed); and

    c.the metadata identifies a data source that is needed to execute a workflow for building the UDT and includes the means for connecting to the database.[88]

    [88] The specification at figure 8; page 17, line 31 to page 19, line 2.

    6.storing the metadata for the UDT in a run-time server (RTS) database; and

    7.periodically executing, by offline data injection module 36, a job; the job includes;

    a.Building a UDT of metadata for modifying the execution of the computer during the runtime of the computer;

    b.reading metadata stored in the RTS database;

    c.connecting to the RTS database and extracting the metadata for the UDT from the RTS database;

    d.formatting the data received from the RTS database so that the data is in a form that can be used to build the UDT and additional data is subsequently uploaded by a batch process workflow of the computer into payment card network system 20, the formatting includes determining whether UDT will execute a full or partial replacement of data; and

    e.implementing the automation of data injection by the (offline data injection module 36) computer.

    When the steps of the invention as described in the specification are performed, additional data is introduced into the computer and consequently the computer has an altered capacity to detect fraudulent transaction in the payment card network.

18. I understand a second aspect of the invention described in the specification as a fraud management system configured to perform the steps of the method outlined the paragraph [80].

19. I understand the third aspect of the invention described in the specification as a non-transitory computer-readable storage media having computer-executable instructions embodied on the media which cause a processor to implement the method outlined in paragraph [80].

    The invention as claimed

20. The specification as filed has 20 claims.  The entire claims set is reproduced in Annex A to this decision.  Claims 1, 11 and 15 are independent claims.  Claim 1 is reproduced here.

    1. A computer-implemented method of modifying an execution of a processing system during runtime, the processing system including at least one computing device including a fraud risk management (FRM) module and communicatively coupled to a payment card network said method comprising:

    receiving, from the payment card network, by the at least one computing device including the FRM module, at least some of a plurality of payment card transactions being processed by the payment card network;

    processing, by the at least one computing device including the FRM module, the at least some of the plurality of payment card transactions to detect fraudulent transactions using a plurality of rules;

    receiving, by the at least one computing device including the FRM module, an indication of a fraud attack on the payment card network;

    generating, by the at least one computing device including the FRM module, in response to the received indication of the fraud attack, new rules related to remediating the fraud attack;

    defining, by the at least one computing device including the FRM module, a user defined table (UDT) that includes metadata specifying the new rule;

    storing the metadata for the UDT in a run-time server (RTS) database; and

    periodically executing, by the at least one computing device including the FRM module, a job, wherein periodically executing the job includes:

    reading the metadata stored in the RTS database; and

    modifying a workflow of the processing system during runtime to cause the processing system to detect fraudulent transactions using the new rules specified in the metadata.

    “A computer-implemented method of modifying an execution of a processing system during runtime, the processing system including at least one computing device including a fraud risk management (FRM) module and communicatively coupled to a payment card network…”

21. Claim 1 is directed to a method of modifying an execution of a computerised processing system while the system is in operation.  The processing system includes at least one computing device with a FRM module.  While claim 1 is not limited to having one computing device, the simplest processing system has a single computing device with an FRM module.  The processing system communicates with a payment card network.

22. A payment card is defined in the specification as a card used for a payment transaction, and includes credit cards, debit cards, prepaid cards, gift cards and devices which hold payment account information, such as mobile phones, personal digital assistants, key fobs, or other devices.[89]  The plain meaning of “network” in the context of computers is a system of connecting computer systems or peripheral devices, each one remote from the others.[90]  Therefore, I interpret “payment card network” of claim 1 to be a system which includes computers of businesses and financial institutions, and those components the specification recites in the definition of “payment card”, wherein the computers and components communicate to exchange information and perform a payment card transaction.

    [89] The specification at page 11, lines 26-33.

    [90]Macquarie dictionary online, accessed on 25 October 2022.

23. The method of claim 1 is therefore directed to modifying an execution of a processing system that has at least one computing device with a FRM module while the computing device is in operation.  This computing device communicates with a system of connecting computers and components that are part of a payment card network.

    “by the at least one computing device including the FRM module”

24. All steps of the method of claim 1, apart from the step of storing metadata for the UDT, are defined to be performed by “the at least one computing device including the FRM module”.  I interpret a computing device with at least the FRM module performs all but one of the method steps of claim 1.  I consider the inclusive nature of defining the components of the computing device to mean that the computing device can have other components in addition to the FRM module.  I consider “module” is a technical term which a person skilled in the art would interpret to either be a computer hardware component (for example, a stick of Random Access Memory or RAM) or a computer software component (for example, a computer program module).  I also consider that the skilled person would understand that where “module” refers to a hardware component, the component is part of a larger assembly and is not functional on its own.  While the description of the specification appears to use “FRM module” to imply a computer hardware component or even a separate computer device, I consider “module” as understood by a skilled person is not limited to a hardware component and not a separate functional device.[91]  Therefore, I interpret the FRM module of claim 1 can be a computer hardware component or a computer software component which is involved in the management of fraud risk. 

    “receiving, from the payment card network … at least some of a plurality of payment card transactions being processed by the payment card network”

    [91] The specification at page 3, lines 10-12, page 9, lines10-13.

1. I interpret this to mean that the computing device (with the FRM module) receives, from the payment card network, multiple payment card transactions that are being processed by the payment card network.

   “processing … the at least some of the plurality of payment card transactions to detect fraudulent transactions using a plurality of rules”

2. I interpret this to mean that the computing device (with the FRM module) uses instructions specified in a computer code to process payment card transactions received by the computing device to identify fraudulent transactions.

   “receiving … an indication of a fraud attack on the payment card network”

3. I interpret this to mean that the computing device including the FRM module is configured to receive an alert that a fraud attack on the payment card network has occurred.

   “generating … in response to the received indication of the fraud attack, new rules related to remediating the fraud attack”

4. The alert received by the computing device (with the FRM module) triggers the device to generate new rules.  The new rules are defined as “related to remediating the fraud attack”.  Therefore, I interpret this to mean that the new rules are broadly concerned with remediating the fraud attack.  I note here my previous discussion that the term “new rules” as used in the description of the specification includes (1) up-to-date rules related to the administrative processes of a payment card transaction, with the up-to-date rules being implemented to manage the fraud attack, and (2) up-to-date rules related to the operation of a computing device (with the FRM module), with the up-to-date rules being implemented to introduce additional data into the processing system, and the additional data consequently affects how a fraud attack is managed.  I consider the scope of the phrase “new rules related to remediating the fraud attack” in claim 1 does not limit the type of rule to remediate the fraud attack and can be interpreted to include both types of up-to-date rules as used in the specification.  However, the words of claim 1 do not definitively claim the new rules to facilitate the introduction of additional data into the computing device.

   “defining … a user defined table (UDT) … specifying the new rule”

5. I interpret this to mean that the computing device (with the FRM module) specifies the form of a UDT.  In other words, I understand the computing device (with the FRM module) to build a UDT to a specific form.  I consider “UDT” is a technical term which a person skilled in the art would understand as a computing technology for data management and used to perform a specific task according to the user’s need.

   “a user defined table (UDT) that includes metadata specifying the new rule”

6. I interpret the inclusive nature of defining the components of the UDT means that the UDT can have other components in addition to metadata.  I interpret the words of the phrase to mean that the metadata defines the new rule.  I consider “metadata” is a technical term which a skilled person would understand as data that describes other data and is used, for example, to identify, locate, and describe digital objects such as files, images, videos, and websites.  However, I consider the scope of “metadata specifying the new rule” in claim 1 does not limit how the metadata functions to define the new rule and can be interpreted to include the functions as described in the specification which I have previously discussed.  For example, claim 1 does not definitively claim “metadata” as identifying a data source to build a UDT, or having the instructions for building the UDT.

   “storing the metadata for the UDT in a run-time server (RTS) database”

7. Applying the plain meaning of the words, the metadata for the UDT is kept in the RTS database.

   “periodically executing … a job,”

8. Applying the plain meaning of words, I interpret “periodically executing” to mean that at regular times a job is executed by the computing device (with the FRM module).  I consider that, in the context of the words of claim 1, a skilled person would understand “job” to mean a set of computer instructions specifying a unit of work to be performed by the computing device (with the FRM module).

   “wherein periodically executing the job includes: reading the metadata stored in the RTS database; and modifying a workflow of the processing system during runtime”

9. Applying the plain meaning of words, I interpret the last step of claim 1 to mean that when the instructions of the job are executed, the metadata stored in the RTS database is read and a workflow of the computing device (with the FRM module) is modified while the computing device is operating.  I interpret the inclusive nature of defining “executing the job” to mean that, in addition to the instructions recited in the claim, other instructions can be executed.  In the context of the words of this last step of claim 1, I interpret “a workflow of the processing system” to be a series of jobs (and therefore computer instructions) that are performed by the computing device (with the FRM module).  I note that the words of the claim do not limit the scope of “a workflow” and therefore do not limit the series of jobs to a specific purpose.  For example, the workflow can include a series of jobs related to (1) the administrative processes of a payment card transaction which are implemented to manage the fraud attack, and/or (2) the operation of the computing device (with the FRM module) which are implemented to introduce additional data into the processing system, and the additional data consequently affects how the fraud attack is managed.  However, the terms “modifying a workflow of the processing system” do not definitively claim modifying a series of jobs to build UDTs and introducing additional data into the processing system as described in the specification.

   “to cause the processing system to detect fraudulent transactions using the new rules specified in the metadata”

10. Applying the plain meaning of the words, executing the job provides a result of modifying a workflow of the computing device (with the FRM module) during runtime and consequently causes fraudulent transactions to be detected using the new rules specified in the metadata.  However, the words do not definitively claim the way the UDT, metadata and jobs are utilised to carry out the method in the computing device.  As previously discussed, scope of “new rules” in the claim can include the two types of rules described in the specification, the scope of how the metadata defines the rule is not limited in the claim, and the scope of “a workflow” is not limited to a series of jobs towards a specific purpose.  Regardless of which workflow of the computer is modified during runtime, the operation of the computer is modified, and a result is an altered capacity of the computer to detect fraudulent transaction in the payment card network.

    Summary of the invention as claimed in claim 1

11. In summary, I understand the invention as claimed in claim 1 to be a method of modifying an execution of a computerised processing system while the system is in operation to manage fraud risks in a payment card network system.  The processing system which has at least one computing device including a FRM module which communicates with the payment card network system.  The method comprises the steps of:

    1.receiving, by the computing device (with the FRM module), multiple payment card transactions that are being processed by the payment card network;

    2.processing, by the computing device (with the FRM module), payment card transactions to identify fraudulent transactions with the use of instructions specified in a computer code;

    3.receiving, by the computing device (with the FRM module), an alert that a fraud attack on the payment card network has occurred;

    4.generating, by the computing device (with the FRM module) and in response to the alert, new rules that are broadly concerned with remediating the fraud attack – the type of new rules is defined in a non-limiting manner and can include (1) up-to-date rules related to the administrative processes of a payment card transaction which are implemented to manage the fraud attack, and/or (2) up-to-date rules related to the operation of the computing device (with the FRM module) which are implemented to introduce additional data into the processing system;

    5.defining (building), by the computing device (with the FRM module), a UDT – which is a computing technology for data management and used to perform a specific task according to the user’s need (The UDT is defined in a non-limiting manner.  Metadata is a component of the UDT.  The way the metadata functions to specify the new rules is defined in a non-limiting manner);

    6.storing the metadata for the UDT in a RTS database; and

    7.executing at regular times, by the computing device (with the FRM module), a job – which is a set of computer instructions specifying a unit of work to be performed by the computing device (with the FRM module) – where executing the job includes reading the metadata stored in the RTS database and modifying a workflow of the computing device (with the FRM module) during its operation to result in the computing device (with the FRM module) detecting fraudulent transactions using the new rules specified in the metadata.  As previously discussed, the terms “new rules”, “metadata” and “a workflow” in the claim are all defined in a non-limiting manner and the inclusive nature of defining “executing the job” means that in addition to the instructions recited in the claim, other instructions can be executed.

12. Claim 11 is directed to a computerised processing system that performs the method of claim 1.  While the words defining the method steps in claim 11 are very similar to those in claim 1, the step of defining the UDT is specified to be performed by “the at least one computing device including the FRM module”.  While this phrase has no antecedence in the claim, I consider it is reasonable to interpret that a processor of the system that includes the FRM module is performing this step and all the other method steps recited in claim 11 are performed by one of the processors of the system.

100. Claim 15 is directed to one or more non-transitory computer-readable storage media which have the instructions for carrying out the method of claim 1.

101. Appended claims 2-10, 12-14 and 16-20 define further features of the computer-implemented method, processing system and computer program, respectively.  I will discuss the features of some of the appended claims here since I have previously discussed the details of most of these features when I considered the invention as described in the specification.

102. Claim 3 is appended to claim 1 and defines “generating a defined table... ”.  Since claim 1 recites a UDT, it appears “a defined table” of claim 3 may be a different feature and not the UDT.  Claim 4 recites “the generated defined table”, claim 5 recites “a previous defined table”, claim 9 recites “a defined table” and claim 10 recites “the defined table”.  There seems to be a clarity issue as to whether the terms in each claim mean the UDT or another table.

103. There seems to be several clarity issues in the claims which were not addressed during examination.  I will discuss some of these clarity issues but note that my discussion on clarity is not exhaustive.  Since the present hearing is only regarding an objection of manner of manufacture, I will not decide on other grounds of objection.  For reasons that will become fully apparent, I intend to allow time for further assessment of the present application under examination.  It is appropriate for other grounds of objection, should these remain, to be considered during further examination.

104. Claim 4 is appended to claim 1 and defines “an SQL task configured to extract data associated with the at least one data element”.  Claim 7 and claim 8 also recite “at least one data element”.  There is no antecedence for “at least one data element”.  It is not apparent to me from the words of any of the claims what “at least one data element” means.  There seems to be a clarity issue.

105. Claim 6 is appended to claim 1 and defines “receiving an indication of data or instructions comprises receiving an indication of a fraud attack on a payment network”.  I note that claim 1 does not define “receiving an indication of data or instructions”.  Instead claim 1 defines “receiving,.., an indication of a fraud attack…”.  I have reviewed the marked-up copy of the claim amendments filed for the parent on 09 July 2019 and note that claim 1 before the amendments defines a step of “receiving an indication of data or instructions being available for modifying the execution of the processing system during run time”.  Since claim 6 in the claim set filed on 09 July 2019 was not amended, I consider it is reasonable to interpret that the applicant inadvertently did not amend this claim.  I understand the scope of claim 6 to be not different to that of claim 1.  Therefore, I consider claim 6 to be redundant in light of claim 1.

106. Claim 7 defines an additional step for the method of claim 1.  This step requires the method to determine a source storage location of “the at least one data element”.  As discussed previously, there is no antecedence for “the at least one data element” of claim 7.  The words of claim 7 also do not limit what is included in the scope of the data element or how the data element is involved in the method.  Given the non-limiting manner of defining the way metadata functions to specify new rules in claim 1, I can accept a possibility of an intention to include within the scope of claim 7 the use of metadata as a data element of the UDT where the metadata is associated with the fraud attack and the metadata identifies a database (data source) needed to execute a workflow for building the UDT – this being a method of an embodiment described in the specification.  However, the words of claim 7 do not limit the method of determining a source location of a data element.

107. Claim 8 is appended to claim 1 and defines a step of determining a data element that includes offline analytical data indicative of historical transaction data associated with one or more cardholder accounts.  As discussed previously, there is no antecedence for this step.  Given the non-limiting manner of defining the way metadata functions to specify new rules in claim 1, I can accept the possibility of an intention to include within the scope of claim 8 the use of metadata as a data element of the UDT where the metadata is associated with the fraud attack and the metadata identifies offline analytical data indicative of historical transaction data associated with one or more cardholder accounts.  However, the words of claim 8 do not limit the method of using a data element.

108. Claim 9 defines an additional step for the method of claim 1.  This step is recited to automatically define a job which transfers information between “the determined source storage location and a defined table, the defined table accessible by a fraud risk management system in communication with a payment network.”.  As there is no antecedence for a determined source location in claims 1-8, there seems to be a clarity issue in claim 9.  Given the inclusive definition of “executing the job” of claim 1, I can accept a possibility of the intention to include within the scope of claim 9 the execution of a job that automates the transfer of data (information) between a data source (data location), identified by the use of metadata, and the other components of the UDT.  However, the words of claim 9 do not limit the method of transferring information.  I also note that it appears that only the claims, and not the description, specify a transfer of information between a determined source storage location and a defined table.

109. Claim 12 is appended to claim 11. For similar reasons discussed for claim 8, I can accept a possibility of an intention to include within the scope of claim 12 the use of metadata as a data element of the UDT where the metadata is associated with the fraud attack and the metadata identifies offline analytical data indicative of historical transaction data associated with one or more cardholder accounts.  However, the words of claim 12 do not limit the method of using a data element.

110. Claim 13 is appended to claim 11.  Since there is no antecedence for a determined source location in claim 11, there seems to be a clarity issue in claim 13.  For similar reasons discussed for claim 9, I can accept a possibility of the intention to include within the scope of claim 13 the execution of a job that automates the transfer of data (information) between a data source (data location), identified by the use of metadata, and the other components of the UDT.  However, the words of claim 13 do not limit the method of transferring information.

111. Claim 19 is appended to claim 15 and defines computer-executable instructions cause a processor to receive an indication of a fraud attack on the payment card network.  I consider this to repeat a step already defined in claim 15.  I understand the scope of claim 19 to be not different to that of claim 15, and therefore a redundant claim.

112. Claim 20 is appended to claim 15 and defines computer-executable instructions which cause a processor to determine a source storage location of a data element.  There is no antecedence for “the at least one data element” of claim 20.  For similar reasons discussed for claim 7, I can accept a possibility of an intention to include within the scope of claim 20 the use of metadata as a data element of the UDT where the metadata is associated with the fraud attack and the metadata identifies a database (data source) needed to execute a workflow for building the UDT – this being a method of an embodiment described in the specification.  However, the words of claim 20 do not limit the method of determining a source location of a data element.

Observations for the invention as claimed and the invention as described

113. I have already made observations regarding the clarity of claims.  Additionally, it is evident from my interpretation of the claims (independent claims and appended claims) and my analyses of the invention as described in the specification that the scope of the invention as claimed is different to the invention as described.  This is particularly clear when comparing my findings at paragraphs 80 and 98.  For example, the description discloses the fraud attack alert that a computer receives relates to the availability of information regarding additional data to be injected into the payment card system while claim 1 does not specify this.  The description discloses a computer builds a UDT that specifies the additional data for generating a solution to the fraud attack.  The description also specifies the form of the UDT by disclosing the components of the UDT and various functions of the metadata (a component of the UDT).  For example, the metadata identifies a data source that is needed to execute a workflow for building the UDT and includes the means for connecting to the database.  The metadata also includes instructions which describe the data for building the UDT, when the UDT should be run, and the CDC type required (whether a full or partial replacement of data is needed).  Claim 1 does not define how the metadata specifies new rules, what the new rules relate to, or how the metadata interacts with other features of the claim to perform the method.  The description discloses a series of jobs (workflow) that build the UDT and consequently introduce additional data into the payment card system.  Claim 1 does not specify that a purpose of the series of jobs is to introduce additional data into the payment card system.

114. The discrepancies I have outlined in the previous paragraph between what has been disclosed in the description and what has been claimed are not exhaustive.  Relevantly, the discrepancies raise at least questions about whether what has been claimed is supported by subject matter disclosed in the specification.  There seems to be section 40 issues which have not been addressed during examination.  My observations regarding potential section 40 issues indicated in this decision may be considered during further examination.

[115] [2014] FCAFC 150; (2014) 109 IPR 364 (Research Affiliates).

“When the authorities in Australia prior to and including Grant are considered, a

consistent approach emerges as to the relevance of:

·     a distinction between a claim to a business scheme and claims to methods which in practice result in a new machine or process or an old machine giving a new and improved result – that is, a distinction between mere intellectual information and a method that affects the operation of an apparatus in a physical form (Grant at [18]);

·     the fact that the claimed steps are foreign to the normal use of computers, such as the production of an improved curve image (IBM 2 at FCR 225-226; ALR 395; IPR 424);

·     the particular mode or manner of achieving an end result which is an artificially created state of affairs, such as the storage of data as to Chinese characters and retrieval of graphic representations to enable word processing (CCOM at FCR 295; ALR 450; IPR 514);

·     whether part of the invention is an inventive method which includes the application and operation in a physical device (Grant at [30]);

·     the distinction drawn in Catuity, as explained in Grant (at [24]), between ‘a technological innovation which is patentable and a business innovation which is not’. In Catuity, Heerey J did not accept that a physically observable effect was necessarily required (at [128]) but the Full Court in Grant expressed the opinion that a physical effect in the sense of a concrete effect or phenomenon, or manifestation or transformation is required (at [32]).

·     the fact that a physical effect is required does not make it sufficient to confer patentability;

·     the fact that a method may be called a business method does not prevent it being properly the subject of letters patent (Grant at [26] citing Catuity at [125]-[126]);

·     the fact that for claimed computer programs, the courts look to the application of the program to produce a practical and useful result, so that more than ‘intellectual information’ is involved (Grant at [29]). A method that is in the nature of directions for use does not constitute an invention or a manner of manufacture in the absence of some previously unrecognised property of an aspect of the method (Grant at [29]).”[116]

[116] Research Affiliates at [94].

136. In considering the substance of the invention the Full Court went on to say:

“In the context of the claim, the significance lies in the content of the data rather than any specific effect generated by the computer.  The computer-implementation is an essential integer of the claimed process.  That is, of course, important.  It is of particular importance in the assessment of, for example, novelty and infringement.  However, in examining whether a claimed invention is properly the subject of letters patent, it is necessary to look not only at the integers of that claimed invention but also at the substance of that invention.

The claimed method in this case clearly involves what may well be an inventive idea, but it is an abstract idea.  The specification makes it apparent that any inventive step arises in the creation of the index as information and as a scheme.  There is no suggestion in the specification or the claims that any part of the inventive step lies in the computer implementation.  Rather, it is apparent that the scheme is merely implemented in a computer and a standard computer at that.  It is not part of the claimed method that there is an improvement in what might broadly be called ‘computer technology’.”[117]

[117] Research Affiliates at [117]-[118].

137. The Full Court in Encompass Pty Ltd v InfoTrack Pty Ltd[118]did not find it necessary to revisit the correctness of RPL Central or Research Affiliates, explaining that:

[118] [2019] FCAFC 161; 372 ALR 646 (Encompass).

“In each case, the Full Court was seeking to describe the conceptual distinction between a manner of manufacture and an unpatentable abstraction.  In each case, the Full Court was explaining that a claimed method that is unpatentable does not change its legal character merely because the method is implemented by the instrumentality of a computer.”[119]

[119] Encompass at [91].

138. The Full Court in Commissioner of Patents v Aristocrat Technologies Australia Pty Ltd[120] observed in relation to a claim defining an electronic gaming machine (EGM) with a particular feature game:

[120] [2021] FCAFC 202; 163 IPR 231 (Aristocrat ’21).

“What this purpose-specific but extremely common computer does is play the feature game.  Consequently, the substance of the invention disclosed by Claim 1 is that feature game implemented on the computer which is an EGM.  It is therefore a computer-implemented invention.

As we have already observed, integers 1.10-1.12 embody an abstract idea which may be characterised both as a set of rules defining a family of games and as a business scheme for increasing player interest in an EGM.  As such its implementation in the computer which is an EGM cannot constitute patentable subject matter unless it represents an advance in computer technology.”[121]

[121] Aristocrat ’21 at [56]-[57].

139. On appeal to the High Court in Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents,[122] the High Court was evenly split, and via section 23(2)(a) of the Judiciary Act 1903 affirmed the Aristocrat ’21 decision.  However, both sets of reasons appear to have indicated that an inquiry as to whether there is an advance in computer technology is not a useful test for patentability.[123]  The High Court affirmed the importance of properly characterising the claimed invention.[124]  Additionally, the reasons of the High Court confirm that the Full Court decisions in Research Affiliates, RPL Central, Encompass and Rokt were correctly decided.[125]  Therefore, I understand that the law as applied in these Full Court decisions still stands and remains relevant.

[122] [2022] HCA 29, (Aristocrat ’22).

[123] The reasons by Kiefel CJ, Gageler J and Keane J in Aristocrat ’22 (herein referred to as first reasons) expressed the question at [77] as “whether the implementation of what is otherwise an unpatentable idea or plan or game involves some adaptation or alteration of, or addition to, technology otherwise well-known in the common general knowledge to accommodate the exigencies of the new idea or plan or game”. The reasons by Gordon J, Edelman J and Steward J in Aristocrat ’22 (herein referred to as second reasons) expressed the questions at [122] as “whether, properly characterised, the subject matter that is alleged to be patentable is: (i) an abstract idea which is manipulated on a computer; or (ii) an abstract idea which is implemented on a computer to produce an artificial state of affairs and a useful result. The artificial state of affairs and useful result may be a physical change in something, but it need not be. The artificial state of affairs may be an improvement in computer technology, but it need not be. It is enough that the artificial state of affairs and useful result are created by "the way in which the method is carried out in the computer”.

[124] Aristocrat ’22 at [73], [101]-[105].

[125] Aristocrat ’22 at [121]-[122].

140. The delegate in Aristocrat Technologies Australia Pty Ltd[126]summarised the considerations arising from RPL Central which are relevant to assessing whether a computer-implemented invention is in substance a manner of manufacture.  These considerations, which remain relevant in view of the subsequent Full Court decisions, are:

[126] [2016] APO 49 (Aristocrat ’16).

“I conclude that it is relevant to consider a range of matters.  Without seeking to be exhaustive, these include:

· there must be more than an abstract idea, mere scheme or mere intellectual information;
· is the contribution of the claimed invention technical in nature;
· does the invention solve a technical problem within the computer or outside the computer;
· does the invention result in improvement in the functioning of the computer, irrespective of the data being processed;
· does the application of the method produce a practical and useful result;
· can it be broadly described as an improvement in computer technology;
· does the method merely require generic computer implementation;
· is the computer merely an intermediary or tool for performing the method while adding nothing of substance to the idea;
· is there ingenuity in the way in which the computer is utilised;
· does the invention involve steps that are foreign to the normal use of computers;
and
· does the invention lie in the generation, presentation or arrangement of intellectual information.”[127]

[127] Aristocrat ’16 at [35].

What is the subject matter of the claims?

141. I have previously discussed my interpretation of claim 1.  The broad scope of claim 1 means that technical aspects of the method of the invention as described in the specification are possibilities that may be included in an interpretation of the claimed invention.  There is no definitive language, in the claim, of the way in which the technical features carry out the method in a computing device.  For example, the step of “defining … a UDT that includes metadata specifying the new rule” is a step that does not go further than simply saying that a UDT that includes metadata to specify new rules is defined (or built, as previously discussed) by the computing technology.  The words of the claim do not limit how this definition (build) is accomplished and how the UDT and metadata work to carry out one or more steps in the method to achieve a desired result of modifying a workflow of the computer with the consequence of detecting fraudulent transactions in the payment card network.  Additionally, the inclusive language defining a “workflow of the processing system” means that which workflow is being affected by the modifications to the computer is also not definitively claimed.

142. Consequently, I consider the subject matter of the claim 1 to be a set of instructions which are performed by a computer in any way that will achieve the desired result.  The remaining claims also do not limit the way in which the method is carried out by a computer, or is executed by non-transitory computer-readable storage media to achieve the desired result.

143. The subject matter does not automatically dictate the substance of the invention, so it is necessary to examine a full range of considerations.

Does the invention as claimed solve a technical problem in the computer or outside the computer?  Does the invention as claimed provide a technical solution to a problem?

144. As previously discussed, the specification states the problem addressed by the present application is the feasibility and effort involved in suspending a processing system already in operation, introducing additional data into the system so that fraudulent transactions can be detected and starting the system up again.  Due to the non-limiting language of claim 1, I consider the claim to be a high-level or conceptual definition of a solution to the problem stated in the specification.  In my view, claim 1 does not define a technical solution to the stated problem as a matter of substance because the claim words define concepts of using what I understand to be conventional aspects of computing technology (for example, UDT, metadata, jobs) to achieve a desired result, but the way the technologies are utilised (the solution) to solve the problem of the specification is not defined.  Additionally, I note claim 1 does not definitively claim a method that involves the location and introduction of additional data into the computer – a solution outlined by the applicant in their submissions, discussed above.

145. The specification describes embodiments of the invention which use computing technology for data management, including UDTs and jobs, to introduce additional data (relevant for detecting and preventing fraudulent transactions) into a computer during its runtime.  The components of the UDT (metadata, change data capture type, SQL command to extract data, automated jobs) and other jobs (for example, jobs to read the metadata in the RTS database) as described in the specification appear to work together to facilitate the computer to locate the additional data from a data source, extract the additional data and load the additional data into the computer during its runtime.  The specification also describes various forms of automation – an automated building of the UDT, the automated injection of additional data by a computer, the automated transfer of information between a data source and the UDT.  It appears to me that the contribution to the invention as described in the specification may lie in the way additional data is located, extracted and loaded into a computer during its runtime, or the way of automating the location, extraction, and loading additional data into a computer during its runtime.  This is because the method of introducing additional data into a computer using the computing technologies described in the specification appears to provide a technical solution which solves the problem stated in the specification.  However, the words of claim 1 do not capture the contribution I have discussed.

146. I agree with the applicant’s submissions quoted at paragraph 127 of this decision to the extent that the invention as described in the specification may solve a technical problem.  However, I disagree with the applicant that the invention as defined in claim 1 relates to solving a particular technical problem by incorporating additional data into the computer during runtime.  The words of claim 1 simply do not permit this interpretation.

147. I consider the invention as claimed in claim 1 does not solve a technical problem in the computer or outside the computer and does not provide a technical solution as a matter of substance.  I consider these reasons equally apply to the computer system of claim 11 and the computer-readable storage media of claim 15.

Is there an improvement in the functioning of the computer? Is there ingenuity in the way the computer is utilised?

148. Since the words of claim 1 do not limit the way in which the recited computing technologies are utilised by the computer to carry out the method, I am unable to identify subject matter that may be considered towards an improvement in the functioning of the computer.  For the same reason, I am also unable to identify ingenuity in the way the computer is utilised.

149. As discussed previously, the specification describes embodiments which locate additional data from a data source, extract the additional data and load the additional data into the computer.  Additionally, the specification describes automating the (1) building of the UDT, (2) injection of additional data by a computer, and/or (3) transfer of information between a data source and the UDT to consequently introduce additional data into the computer during runtime without suspending the operation of the computer.  Therefore, the specification appears to describe technical means to introduce additional data into a computer which avoids the need to suspend a computer during its runtime and address the issues associated with the prior art systems.  It seems to me that the described technical means may be capable of providing a relevant improvement in the functioning of the computer, or ingenuity in the way the computer is utilised, or both.  However, the words of claim 1, or any other claims, do not definitively claim subject matter which may be considered towards a relevant improvement in the functioning of a computer or ingenuity in the way the computer is utilised.

150. I also note that the specification describes “using a framework of reusable jobs configured to generate a [UDT] of metadata for altering an execution of a running processing system”.[128]  This framework is contrasted with other methods as there is no need for “generating new code to inject new off-line analytic data used to detect new fraud attacks.”[129]  I infer this to mean that, while the components of the UDT may have been created and used for previous fraud attacks, these components may somehow be assembled in a different way to address new fraud attacks thereby providing efficiencies in terms of time and human resources.  How this happens is, however, not apparent from the words of the claims.

[128] The specification at page 25, lines 16-18.

[129] The specification at page 4, lines 17-19.

Does the invention use generic computer technology?

151. The use of UDTs and jobs for data management appear to be conventional.  The way the specification describes metadata appears to assume that the various functions of metadata are known and understood.  Accordingly, I consider the invention as claimed in the claims uses generic computer technology.

Are there any steps which are foreign to the normal use of computers?

152. As previously discussed, the claims do not limit how the UDT, metadata and jobs function to carry out a method which results in modifying a workflow of the computer with the consequence of detecting fraudulent transactions in the payment card network.  The way the steps are presently defined in the claims suggests to me that the steps are performed as part of the normal use of a computer.

153. Turning to the invention as described in the specification, while the use of UDT, metadata and jobs may be known, it is unclear to me whether it was usual to use these technologies in the manner described in the present application to make additional data available to a computer during its runtime at the priority date.  The problem stated in the specification suggests to me that it was not usual for a computer of the prior art systems to locate, extract, and load additional data without first suspending the operation of the computer.  The Examiner assessed run-time modifications to programming code to be widely known and located two prior art citations in the context of hacking a computer program.  Given the broad scope of the claims, the Examiner’s search may have been appropriate.  However, there is insufficient information on file for me to definitively decide whether, at the priority date of the present application, the use of the components of the UDTs and other jobs (for example, use of SQL tasks to extract identified data) described in the specification was conventional use of computing technology for locating, extracting and loading additional data into a computer during its runtime.  Where there is further examination, it would be helpful for an appropriate prior art search to be undertaken to establish the state of the art, at the priority date, regarding the technical means for introducing additional data into a computer during its runtime.

Is there a practical and useful result?

154. As discussed previously, the claims include several possibilities regarding which workflow of the computer is modified during runtime.  One possibility is that the computing technologies described in the specification are used to implement a series of jobs (workflow) which modifies the way additional data is located, extracted, and loaded into the computer.  However, this is not definitively claimed in the claims.  Regardless of which workflow of the computer is modified, there is a modification to the operation of the computer during its runtime and a result is an altered capacity of the computer to detect fraudulent transaction in the payment card network.  I consider this result to be practical and useful.  Additionally, automating the introduction of additional data into a computer as described in the specification would appear to provide a quicker and more efficient way of detecting fraudulent transactions.

155. However, while the presence of a practical and useful result is a useful factor to be considered when weighing up whether there is patentable subject matter, it is not in itself necessarily determinative of a finding of patentability.

Does the invention lie in the generation, presentation, or arrangement of intellectual information?

156. From the previous discussions, I consider it is evident the invention does not lie in the generation, presentation, or arrangement of intellectual information.

Balance of considerations

157. In determining the substance of a claimed invention, I must consider how the claimed invention works.  This requires a consideration of the nature and contribution of the features of the invention as claimed as a whole.  The questions which I have sought to answer in this decision, which are questions derived from judicial authority, provide a framework which I have used for weighing up various considerations that contribute to the substance of the claimed invention.  No single consideration is conclusive in determining the substance of the claimed invention.  Some considerations may be more significant than others.

158. I have discussed the possibilities of the invention as described in the specification to contrast a difference in the substance of the invention as claimed compared to the invention as determined by a reading of the whole of the specification.  However, I note that patentability must be assessed by reference to the claimed invention and not by possibilities described in the specification but not claimed.

159. While claim 1 includes terms that define technical means, for example, UDT, metadata and jobs, these terms do not definitively claim a way the conventional technical means are utilised to facilitate the method in a computer.  Therefore, while I have found claim 1 to define a practical and useful result, the way the method is carried out by the computer to achieve this result is not definitively claimed.  In the present case, defining an idea of using computer technologies, without further definition of how the technologies facilitate performing the claimed method, remains an idea.  There is no suggestion in the claim that a contribution of the invention lies in the way the computer carries out (implements) the method.

160. In the present case, there is a lack of meaningful technical details in the words of claim 1 to ascertain what computing processes are being modified by the UDT, metadata and jobs, and how these computing technologies are modifying the computing processes.  Consequently, I am unable to find, from the words of the claim, (a) ingenuity in the way the computer is utilised, or (b) an improvement in the functioning of the computer.  While a finding of a practical and useful result could suggest an improvement in the functioning of the computer, or an ingenuity in the way the computer is utilised, such an improvement or ingenuity cannot be ascertained from the words of the claim.  I have previously discussed the aspects of the invention as described in the specification which could possibly be considered an improvement in computer function, ingenuity in the way the computer is utilised, or both.  Definitively claiming one or more of these aspects may change the balance of the substance of the claim toward a finding of patentable subject matter.

161. I consider the non-limiting way of defining the method steps of claim 1, and the lack of definition regarding how the recited computing technologies facilitate performing the method, to indicate that these technologies are part of the standard use of a computer.  Therefore, the computer is merely being used as a tool for performing method while adding nothing of substance to the idea of using the recited computing technologies.  I have previously discussed a possibility that the way the specification describes using components of the UDT and other jobs to locate, extract and load additional data into a computer may not be usual at the priority date of the present application.  However, any aspect of a computing technology which is being used in an unconventional way to perform the invention, but which cannot be definitively ascertained on a proper construction of the claim, cannot change the balance of the substance of the claim toward a finding of patentable subject matter.

162. On balance, I consider the substance of claim 1 does not rise above an idea to use computing technologies associated with UDTs, metadata and jobs in a non-limiting manner to modify a workflow of a computer during its runtime to cause an altered capacity of the computer to detect fraudulent transactions in a payment card network.  I also consider the substance of claims 11, 15 and all the appended claims does not rise above an idea for similar reasons as claim 1.

Conclusion

163. The invention claimed in each of claims 1-20 is not for a manner of manufacture.

164. This conclusion follows because the weight given to the practical and useful result is not sufficient to disturb the balance of considerations.  However, it may be possible to amend the claims to tip the balance of considerations in favour of finding patentable subject matter.  I direct that this application be returned to examination to allow the applicant the opportunity to propose amendments in line with this decision that might more definitively link the way the computer technologies are utilised in the method to address the stated problems.  In accordance with sub-regulation 13.4(3), and noting the nature of the objection, I consider it is appropriate that the final date for acceptance of this application be six (6) months from the date of this decision. 

Dr A. Lim
Delegate of the Commissioner of Patents

Annex A

1. A computer-implemented method of modifying an execution of a processing system during runtime, the processing system including at least one computing device including a fraud risk management (FRM) module and communicatively coupled to a payment card network said method comprising:

receiving, from the payment card network, by the at least one computing device including the FRM module, at least some of a plurality of payment card transactions being processed by the payment card network;

processing, by the at least one computing device including the FRM module, the at least some of the plurality of payment card transactions to detect fraudulent transactions using a plurality of rules;

receiving, by the at least one computing device including the FRM module, an indication of a fraud attack on the payment card network;

generating, by the at least one computing device including the FRM module, in response to the received indication of the fraud attack, new rules related to remediating the fraud attack;

defining, by the at least one computing device including the FRM module, a user defined table (UDT) that includes metadata specifying the new rule;

storing the metadata for the UDT in a run-time server (RTS) database; and

periodically executing, by the at least one computing device including the FRM module, a job, wherein periodically executing the job includes:

reading the metadata stored in the RTS database; and
modifying a workflow of the processing system during runtime to cause the processing system to detect fraudulent transactions using the new rules specified in the metadata.

2. The computer-implemented method of Claim 1, wherein modifying an execution of a processing system during runtime comprises modifying an execution of a fraud risk management system in communication with a payment network.

3. The computer-implemented method of Claim 2, further comprising generating a defined table used by the fraud risk management system.

4. The computer-implemented method of Claim 3, wherein the generated defined table includes a data source of defined table elements, a change data capture (CDC) type, an SQL task configured to extract data associated with the at least one data element, and an automation indicator.

5. The computer-implemented method of Claim 4, further comprising performing a change data capture process using a previous defined table when a DELTA CDC type is specified.

6. The computer-implemented method of Claim 1, wherein receiving an indication of data or instructions comprises receiving an indication of a fraud attack on a payment network.

7. The computer-implemented method of Claim 1, further comprising determining a source storage location of the at least one data element.

8. The computer-implemented method of Claim 1, wherein determining at least one data element comprises determining at least one data element that includes offline analytical data indicative of historical transaction data associated with one or more cardholder accounts.

9. The computer-implemented method of Claim 1, further comprising automatically defining a job, the job configured to transfer information between the determined source storage locations and a defined table, the defined table accessible by a fraud risk management system in communication with a payment network.

10. The computer-implemented method of Claim 9, further comprising accessing the defined table at runtime by the fraud risk management system.

11. A processing system including a fraud risk management (FRM) module, the processing system capable of modifying an execution of the processing system during runtime, the processing system communicatively coupled to a payment card network, said the processing system comprising:

one or more memory devices; and
one or more processors communicatively coupled to said one or more memory devices, said one or more memory devices including computer-executable instructions that when executed by the one or more processors cause the one or more processors to perform the programmed steps of:

receiving, from the payment card network, at least some of a plurality of payment card transactions being processed by the payment card network;

processing the at least some of the plurality of payment card transactions to detect fraudulent transactions using a plurality of rules;

receiving an indication of a fraud attack on the payment card network;

generating, in response to the received indication of the fraud attack, new rules related to remediating the fraud attack;

defining, by the at least one computing device including the FRM module, a user defined table (UDT) that includes metadata specifying the new rules;

storing the metadata for the UDT in a run-time server (RTS) database; and

periodically executing a job, wherein periodically executing the job includes:

reading the metadata stored in the RTS database; and modifying a workflow of the processing system during runtime to cause the processing system to detect fraudulent transactions using the new rules specified in the metadata.

12. The system of Claim 11, wherein computer-executable instructions cause the one or more processors to determine at least one data element that includes offline analytical data indicative of historical transaction data associated with one or more cardholder accounts.

13. The system of Claim 11, wherein computer-executable instructions cause the one or more processors to automatically define a job, the job configured to transfer information between the determined source storage locations and a defined table, the defined table accessible by a fraud risk management system in communication with the payment network.

14. The system of Claim 13, wherein computer-executable instructions cause the one or more processors to access the defined table at runtime by the fraud risk management system.

15. One or more non-transitory computer-readable storage media having computer-executable instructions embodied thereon, wherein when executed by at least one processor of a processing system including a fraud risk management (FRM) module, the computer-executable instructions cause the at least one processor to:

receive, from a payment card network, at least some of a plurality of payment card transactions being processed by the payment card network;

process the at least some of the plurality of payment card transactions to detect fraudulent transactions using a plurality of rules;

receive an indication of a fraud attack on the payment card network;

generate, in response to the received indication of the fraud attack, new rules related to remediating the fraud attack;

define a user defined table (UDT) that includes metadata specifying the new rules;

store the metadata for the UDT in a run-time server (RTS) database; and

periodically execute a job, wherein periodically executing the job includes:

reading the metadata stored in the RTS database; and
modifying a workflow of the processing system during runtime to cause the processing system to detect fraudulent transactions using the new rules specified in the metadata.

16. The computer-readable storage media of Claim 15, wherein the computer-executable instructions further cause the processor to modify an execution of a fraud risk management system in communication with a payment network.

17. The computer-readable storage media of Claim 16, wherein the computer-executable instructions further cause the processor to generate a defined table used by the fraud risk management system.

18. The computer-readable storage media of Claim 17, wherein the computer-executable instructions further cause the processor to generate a defined table that includes a data source of defined table elements, a change data capture (CDC) type, an SQL task configured to extract data associated with the at least one data element, and an automation indicator.
19. The computer-readable storage media of Claim 15, wherein the computer-executable instructions further cause the processor to receive an indication of a fraud attack on the payment network.

20. The computer-readable storage media of Claim 15, wherein the computer-executable instructions further cause the processor to determine a source storage location of the at least one data element