Visa International Service Association
[2024] APO 34
•12 August 2024
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Visa International Service Association [2024] APO 34
Patent Application: 2021200807
Title:Systems and methods for interoperable network token processing
Patent Applicant: Visa International Service Association
Delegate: Dr V. Z. Kolev
Decision Date: 12 August 2024
Hearing Date: Written submissions completed on 18 August 2023
Catchwords: PATENTS – sections 45 and 49 – hearing with respect to examiner’s objection – manner of manufacture – payment transaction processing – payment tokens used instead of real account numbers/identifiers – network token processing system and method – assigning a static token issuer identifier to each issuer – incorporating a respective token issuer identifier in each token – sending to participating entities a table of token issuer identifiers and their corresponding real issuer identifiers – the entities identifying the issuers from the tokens and the table – storing token information for each token – assigning a dedicated communication interface to each participating entity – identifying the entity requesting token information from the dedicated interface used by the entity – providing to the identified entity only the token information that the entity is authorised to obtain – assigning a token assurance value to each token following a verification and authentication process – the token assurance value indicating the trust level of token binding to the underlying real account and/or account holder – the claimed invention is not a manner of manufacture – no patentable subject matter described in the specification – application refused
Representation: Patent attorney for the applicant: Phillips Ormonde Fitzpatrick
IP AUSTRALIA
AUSTRALIAN PATENT OFFICE
Patent Application: 2021200807
Title: Systems and methods for interoperable network token processing
Patent Applicant: Visa International Service Association
Date of Decision: 12 August 2024
DECISION
The invention claimed in each one of the claims, as proposed to be amended, is not a manner of manufacture. Furthermore, based on the matter described in the body of the specification, I am of the opinion that no allowable amendment could result in claiming a patentable invention.
I refuse the application.
REASONS FOR DECISION
Throughout this decision, unless explicitly stated otherwise, any reference to the Act, or to a specific section or subsection, refers to the Patents Act 1990, and any reference to the Regulations, or to a specific regulation or subregulation, refers to the Patents Regulations 1991. In addition, any reference to the Commissioner refers to the Commissioner of Patents as per the Act.
Background
The matter relates to patent application 2021200807 (the Application) in the name of Visa International Service Association (the Applicant). The Application was filed on 9 February 2021 as a divisional application of 2019201056 (the Parent), which in turn is divisional of 2014292980 (the Grandparent), which was filed under the Patent Cooperation Treaty as PCT/US2014/048083 and published as WO2015/013548. The earliest claimed priority date is 24 July 2013.
It is worth noting that the Grandparent lapsed for failure to gain acceptance within the prescribed period following four examination reports. The Parent also lapsed for failure to gain acceptance within the prescribed period following four examination reports. Seven of these eight examination reports did not include an objection that the claimed invention is not a manner of manufacture, the exception being the last examination report for the Parent.
The request for examination with respect to the Application was filed on 16 April 2021. Soon after, on 23 April 2021, the Applicant filed amendments to the specification of the Application (the Specification) in anticipation of an examination report. Three examination reports were issued as detailed below.
Examination report No. 1 was issued on 13 April 2022. The report contained objections that the claimed invention is not a manner of manufacture and does not involve an inventive step. A response to the report was filed on 30 August 2022, together with proposed amendments to the description and claims.
Examination report No. 2 was issued on 27 September 2022. In the report, the objection with respect to manner of manufacture was maintained. No other objections were raised or maintained. A response to the report was filed on 31 January 2023, together with proposed amendments to the description and claims.
Examination report No. 3 (the Last Report) was issued on 28 February 2023. In the report, the sole objection with respect to manner of manufacture was maintained.
On 12 April 2023, the Applicant requested a hearing by way of written submissions.
Submissions and evidence
On 2 August 2023, the Applicant filed their written submissions in relation to the hearing (the Applicant’s Submissions or AS). In addition, on 18 August 2023, the Applicant filed a declaration by Mr Glenn Powell dated 18 August 2023. Since Mr Powell is one of the inventors on record, I will refer to this declaration as the Inventor’s Declaration or IDec.
Applicable law
On 15 April 2013, the Intellectual Property Laws Amendment (Raising the Bar) Act 2012 commenced which resulted in significant amendments to the Act and Regulations. The Application was filed on 9 February 2021; hence the amended provisions of the Act and Regulations apply to the examination of the Application and to the instant hearing decision. This means that I must accept the Application if I am satisfied, on the balance of probabilities, that the Application complies with the Act. If I am not so satisfied, I may refuse the Application. In such a situation, the extended period for gaining acceptance provided under reg 13.4(1)(g) will make no difference if the Application is refused. However, I consider that it is only appropriate to refuse the Application if I am satisfied that providing the Applicant with an opportunity to overcome any negative findings would serve no useful purpose; in other words, I will only refuse the Application if I consider that any potential negative findings are inevitably fatal to the Application.
The law on manner of manufacture
The relevant parts of s 18 stipulate:
“(1) Subject to subsection (2), an invention is a patentable invention for the purposes of a standard patent if the invention, so far as claimed in any claim:
(a) is a manner of manufacture within the meaning of section 6 of the Statute of Monopolies; and
…
(2) Human beings, and the biological processes for their generation, are not patentable inventions.”
A number of Court decisions have discussed and determined whether the particular invention in each case “is a manner of manufacture within the meaning of section 6 of the Statute of Monopolies”. These Court decisions constitute a significant body of case law that the Commissioner must follow. For the purpose of this decision, I do not consider it necessary to provide a comprehensive review of the case law and I will only point to Court decisions which I consider pertinent to the instant considerations.
National Research Development Corporation v Commissioner of Patents [1959] HCA 67; (1959) 102 CLR 252 (NRDC) is the seminal authority on the issue, establishing, inter alia, the general approach for deciding the question of manner of manufacture at [14] (at p 269):
“The right question is: ‘Is this a proper subject of letters patent according to the principles which have been developed for the application of s. 6 of the Statute of Monopolies?’”
D’Arcy v Myriad Genetics Inc [2015] HCA 35 (Myriad) is a much more recent High Court decision on manner of manufacture; however, I note that both NRDC and Myriad are not related to inventions implemented on computing devices, hence they do not discuss some of the more specific issues associated with such inventions. In contrast, the decisions of the Full Court of the Federal Court in Research Affiliates LLC v Commissioner of Patents [2014] FCAFC 150 (Research Affiliates) and Commissioner of Patents v RPL Central Pty Ltd [2015] FCAFC 177 (RPL Central) were made with respect to business methods implemented on computing devices. In particular, in RPL Central the Full Court, having considered in some detail the decisions in Research Affiliates and Myriad, developed an approach to determining the issue of manner of manufacture for inventions implemented using computers. This approach of RPL Central was later approved in Encompass Corporation Pty Ltd v InfoTrack Pty Ltd [2019] FCAFC 161 (Encompass), which was a decision by an enlarged bench (consisting of five judges) of the Full Court. The approach was also relied on in subsequent Full Court decisions, including Commissioner of Patents v Rokt Pte Ltd [2020] FCAFC 86 (Rokt) and Repipe Pty Ltd v Commissioner of Patents [2021] FCAFC 223 (Repipe). The cases in Encompass, Rokt, and Repipe also involved inventions implemented using computer technology.
Aristocrat Technologies Australia Pty Ltd v Commissioner of Patents [2022] HCA 29 (Aristocrat’22) is the most recent High Court decision on manner of manufacture. Because, in that decision, the six judges were evenly divided as to the outcome, there was no majority and no usual binding precedent. Importantly however, the outcomes of the above mentioned decisions of the Full Court were not criticised and remain undisturbed. Also, as a result of the operation of s 23(2)(a) of the Judiciary Act 1903, the decision of the Full Court of the Federal Court in Commissioner of Patents v Aristocrat Technologies Australia Pty Ltd [2021] FCAFC 202 that the invention concerned was not for a manner of manufacture was affirmed.
For the present purpose of deciding on manner of manufacture in relation to the Application, I consider it helpful to provide a brief overview of some of the main guiding principles that can be extracted from the above Court decisions. Below, I will present those principles, in italic, as separate paragraphs supported by relevant quotations from the decisions. Where the breadth of some quotations makes them relevant to more than one principle, for brevity, I will not repeat those quotations in different paragraphs (underlining added in all quotations).
A determination on manner of manufacture must be done on a case by case basis, having regard to the substance of the invention not merely the form of the claims; there are no strict rules or a precise formula to be applied mechanistically:
“The purpose of s. 6, it must be remembered, was to allow the use of the prerogative to encourage national development in a field which already, in 1623, was seen to be excitingly unpredictable. To attempt to place upon the idea the fetters of an exact verbal formula could never have been sound. It would be unsound to the point of folly to attempt to do so now, when science has made such advances that the concrete applications of the notion which were familiar in 1623 can be seen to provide only the more obvious, not to say the more primitive, illustrations of the broad sweep of the concept.” (NRDC at [15]; at p 271)
“This Court in NRDCdid not prescribe a well-defined pathway for the development of the concept of ‘manner of manufacture’ in its application to unimagined technologies with unimagined characteristics and implications. Rather, it authorised a case-by-case methodology.” (Myriad at [23])
“Whatever words have been used, the matter must be looked at as one of substance and effect must be given to the true nature of the claim.” (Myriad at [144], reasons by Gageler and Nettle JJ)
“The approach to be taken to deciding whether a claimed method or product is properly the subject of letters patent must be flexible and must allow for new technologies presently unknown … There is no formula to be mechanically applied …
… 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.” (Research Affiliates at [116]-[117])
“The determination … is made not by some mechanistic application of the criterion of artificiality or physical effect, but by an understanding of the claimed invention itself. The invention is to be understood as a matter of substance and not merely as a matter of form.” (Research Affiliates at [106])
The characterisation as “an artificially created state of affairs of economic significance” is useful, but not ultimately determinative for manner of manufacture; to be patentable, a process must belong to the useful arts:
“The point is that a process, to fall within the limits of patentability which the context of the Statute of Monopolies has supplied, must be one that offers some advantage which is material, in the sense that the process belongs to a useful art as distinct from a fine art … that its value to the country is in the field of economic endeavour.” (NRDC at [22]; at p 275)
“… the view which we think is correct in the present case is that the method the subject of the relevant claims has as its end result an artificial effect falling squarely within the true concept of what must be produced by a process if it is to be held patentable … The effect produced by the appellant’s method exhibits the two essential qualities upon which ‘product’ and ‘vendible’ seem designed to insist. It is a ‘product’ because it consists in an artificially created state of affairs, discernible by observing over a period the growth of weeds and crops respectively on sown land on which the method has been put into practice. And the significance of the product is economic; for it provides a remarkable advantage, indeed to the lay mind a sensational advantage, for one of the most elemental activities by which man has served his material needs, the cultivation of the soil for the production of its fruits … It achieves a separate result, and the result possesses its own economic utility consisting in an important improvement in the conditions in which the crop is to grow, whereby it is afforded a better opportunity to flourish and yield a good harvest.” (NRDC at [25]; at p 277)
“If a process is to be patentable, it must offer some advantage which is material, in the sense that the process belongs to a useful art. The characterisation of patentability by reference only to the description in NRDC of a product which consists of an artificially created state of affairs of economic significance was part of the High Court’s reasoning but did not represent a sufficient or exhaustive statement of the circumstances in which a claimed invention is patentable.” (Research Affiliates at [101])
“In this context, their Honours emphasised [in Myriad] (at [20]) that, while satisfaction of an ‘artificially created state of affairs of economic significance’ as stated in NRDC may ‘suffice for a large number of cases in which there are no countervailing considerations’, this terminology is not to be treated as a formula exhaustive of the concept of manner of manufacture, or a formula which alone captures the breadth of the ideas to which effect must be given. Similarly, Gageler and Nettle JJ noted (at [125]) that the holding in NRDCdoes not mean that an ‘artificial state of affairs’ and ‘economic utility’ are the only relevant considerations in this context. However, the majority and Gageler and Nettle JJ acknowledged the usefulness of such characterisation in appropriate circumstances.” (RPL Central at [116])
In deciding on manner of manufacture, it is important to identify where the inventor’s ingenuity lies:
“It is a question of understanding what has been the work of, the output of, and the result of, human ingenuity, and to apply the principles that have been developed and explained so well in NRDC.” (Research Affiliates at [116])
“Recognising that the claims are to a method and system comprising a combination of integers, it is necessary to understand where the inventiveness or ingenuity is said to lie.” (RPL Central at [112])
Technological innovations are patentable, whereas business innovations are not; a business method implemented on computing devices could be patentable if it involves ingenuity in the computer implementation:
“Relevantly, the Full Court in Research Affiliates said (at [94]) that the distinction to be drawn was between the employment of an abstract idea or law of nature and the idea or law itself and that there is a distinction between a technological innovation which is patentable and a business innovation which is not. Their Honours repeated an observation from Grant (at [29]) ‘[a] product of a method is something in which a new and useful effect may be observed. For claimed computer programs, the courts looked to the application of the program to produce a practical and useful result, so that more than “intellectual information” was involved.’ A technological innovation is patentable; a business innovation is not, although a business method may be the subject of letters patent.” (RPL Central at [100])
“A claimed invention must be examined to ascertain whether it is in substance a scheme or plan or whether it can broadly be described as an improvement in computer technology. The basis for the analysis starts with the fact that a business method, or mere scheme, is not, per se, patentable. The fact that it is a scheme or business method does not exclude it from properly being the subject of letters patent, but it must be more than that. There must be more than an abstract idea; it must involve the creation of an artificial state of affairs where the computer is integral to the invention, rather than a mere tool in which the invention is performed. Where the claimed invention is to a computerised business method, the invention must lie in that computerisation. It is not a patentable invention simply to ‘put’ a business method ‘into’ a computer to implement the business method using the computer for its well-known and understood functions.” (RPL Central at [96])
“RPL Central does not claim any invention or ingenuity in any program or operation of a computer, or implementation by a computer to operate the method. Accordingly, the ingenuity of the inventors must be in the steps of the method itself. The method does utilise the speed and processing power and ability of a computer but there is no suggestion that this is other than a standard operation of generic computers with generic software to implement a business method …
The problem may be one of confronting the ‘maze’ of available information concerning the RPL of different Units of Competency in different institutions, but the solution to that problem, to be patentable, must involve more than the utilisation of the well-known search and processing functions of a computer, for example an invention in the way in which the computer is utilised.” (RPL Central at [110]-[111])
“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 no part of the claimed method that there is an improvement in what might broadly be called ‘computer technology’.” (Research Affiliates at [118])
“In Research Affiliates, looking at the claimed method as a matter of substance, the Full Court concluded that, in that case, the computer was merely the means by which the analyst accessed data to generate an index, that being the work of the analyst rather than a technical generation by the computer. There was no suggestion of the utilisation of an unusual technical effect. The inventors made changes to the computer program to cause the program to gather and process data and perform data manipulations and calculations, including macros to manipulate and refine data. Such use of algorithms was not ‘foreign’ to the normal use of computers.” (RPL Central at [102])
“To reiterate some of the matters discussed in Research Affiliates:
·It is necessary to ascertain whether the contribution to the claimed invention is technical in nature. In Aerotel Ltd v Telco Holdings Ltd; Macrossan’s Application [2007] 1 All ER 225, the subject matter was an interactive system whereby questions were asked, the answers incorporated in a draft and, depending on some particular answers, further questions were asked. It was held that, apart from the fact of running a computer program, there was nothing technical about the contribution and the method was for the business of advising upon and creating appropriate company documents.
·One consideration is whether the invention solves a ‘technical’ problem within the computer or outside the computer, or whether it results in an improvement in the functioning of the computer, irrespective of the data being processed.
·Does the claimed method merely require generic computer implementation?
·Is the computer merely the intermediary, configured to carry out the method using a computer readable medium containing program code for performing the method, but adding nothing to the substance of the idea? In Alice Corporation, the method was for exchanging financial obligations in which the computer was used to create records, track multiple transactions and issue simultaneous instructions. The majority in the Supreme Court of the United States concluded that the use of the computer added nothing to the substance of the abstract idea of reducing settlement risk in exchanging financial obligations.” (RPL Central at [99])
Whether a method can or cannot be practically implemented without a computer is not determinative for manner of manufacture:
“Simply putting a business method or scheme into a computer is not patentable unless there is an invention in the way in which the computer carries out the scheme or method. Is the fact that the scheme cannot practically be implemented without a computer, that is, that the computer is integral to the working of the scheme, sufficient to make it patentable? The answer is not straightforward because this is not a case where the computer simply processes the information entered by the user, for example by using an algorithm, or retrieves information from the Internet in response to a user’s question.” (RPL Central at [107])
“Is the mere implementation of an abstract idea in a well-known machine sufficient to render patentable subject matter? Is the artificial effect that arises, because information is stored in RAM and there is communication over the Internet or wifi, sufficient? Does any physical effect give rise to a manner of manufacture? Are the mere presence of an artificial effect and economic utility, without more, sufficient to determine manner of manufacture?
It is not a question of stating precise guidelines but of deciding, in each case, whether the claimed invention, as a matter of substance not form, is properly the subject of a patent.” (RPL Central at [97]-[98])
“It is stated in the specification, and was accepted by the primary Judge, that the method could not be carried out without the use of a computer. This alone cannot render the claimed invention patentable if it involves simply the speed of processing and the creation of information for which computers are routinely used. In those circumstances, the claimed invention is still to the business method itself. A computer-implemented business method can be patentable where the invention lies in the way in which the method is carried out in the computer. This necessitates some ingenuity in the way in which the computer is utilised (Research Affiliates).” (RPL Central at [104])
The case law on manner of manufacture was extensively discussed in prior decisions on the matter by the Australian Patent Office, including in Aristocrat Technologies Australia Pty Limited [2016] APO 49 (Aristocrat’16), where the Delegate provided a general indication, distilled from the case law, as to the matters relevant to a determination on manner of manufacture for inventions implemented on a computer:
“35. 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.” (underlining added)
It is clear from the Delegate’s wording that the above list is not a “check-list” to determine whether a particular claimed invention is a manner of manufacture. Instead, the list includes, in a non-exhaustive manner, relevant considerations or “touch stones” helpful in the decision process. This was also noted in Todd Martin [2017] APO 33:
“47. With this list of points, the delegate in the Aristocrat[’16] case was not intending to indicate a list of conditions, for computer-implemented cases, to be met to define a manner of manufacture. That is evident from the delegate’s statement that the list was not intended to be exhaustive. Moreover, it would appear improper to find there was a manner of manufacture simply on the basis that one or more points could be answered in favour. In the present case for example, it may be that at least the fifth dot-point, regarding whether the application of the method produces a practical and useful result, is satisfied. On the other hand, that consideration on its own would be insufficient in the present case. Conversely it would also appear improper to find there was no manner of manufacture simply on the basis that one or more points could not be answered favourably. Rather than these points being seen as conditions to be met, they should be seen as relevant matters to consider, as the delegate stated at [35]. The substance and contribution of the claimed invention in each case should be considered on its merits overall and various points under the law would appear to have varying degrees of relevance depending on the case.”
As a further observation, it appears that the Court decisions on manner of manufacture for computer-implemented inventions do not always explicitly refer to all of the above relevant considerations, which would appear to suggest that, depending on the circumstances of the case, not all of the relevant matters included in the list need to be considered in order to reach a conclusion. It could also be said that some of the above considerations are somewhat overlapping in their scope.
The Specification
The proposed amendments
While I cannot see any immediate reasons why the proposed amendments would not be allowable, I do not need to decide this conclusively as this will not affect the outcome of my decision. Suffice to say that the amendments were not objected to during examination, and for the benefit of the Applicant, I will consider the Specification as most recently proposed to be amended on 31 January 2023.
The invention as described
The body of the Specification includes 99 pages of description and 12 pages of drawings. In the section “Background”, it is explained that:
“[0003] In a traditional electronic payment transaction, a consumer’s PAN (primary account number) information is exposed to various entities involved during the transaction life-cycle. …
[0004] Because [of that], some have suggested that payment ‘tokens’ be used to conduct payment transactions. A token serves as an additional security layer to the PAN and in effect becomes a proxy/surrogate to the PAN and may be used in place of PAN while submitting transactions. The use of payment tokens instead of PANs can reduce the risk of fraudulent activity since the real PAN is never exposed. It can also reduce or eliminate the need for merchants and other entities to be PCI DSS (Payment Card Industry Data Security Standard) compliant. PCI DSS is a standard that all organizations, including online retailers, must follow when storing, processing and transmitting their customer’s credit card data. …” (underlining, italic, and bold added)
At paragraphs [0005] and [0007], it is noted that, in addition to the payment tokens mentioned above, non-payment tokens can also be utilised, wherein “[n]on-payment tokens can be used by merchant/acquirer systems for analytics, offers and any other [than payment transaction] purpose”, including “to keep track of transactions while avoiding the need to be PCI-DSS compliant” (at [0007]). It is further explained, at paragraphs [0005]-[0006], that the payment tokens can be static tokens, which can have longer life and can be used to submit multiple payment transactions, and dynamic tokens, which “can be short lived tokens, and can be valid until the configured timeline. Once expired, they cannot be reused until reissued. In some cases, one dynamic token can be used to submit only one transaction” (at [0006]).
The description continues by stating that “[w]hile conventional efforts to use payment tokens have been useful, a number of additional problems need to be solved” (at [0008]). These problems are related to the difficulty in “identify[ing] the source of the token or the issuer of the token” (at [0008]), and the fact that “various parties in the payment transaction processing system may need information about the token for various reasons [e.g., fraud analyses]”, but “do not currently have a way to obtain such information” (at [0009]). Hence, “the present invention may overcome, or at least ameliorate, at least one disadvantage of present arrangements” (at [0010]).
The next section “Summary of the invention” contains several paragraphs resembling consistory statements, some of which broadly corresponding to the independent claims. This is followed by a brief description of the drawings, consisting of FIG. 1 to FIG. 12, and by a section titled “Detailed description”. This section begins by stating that “[e]mbodiments are directed at systems, methods, and devices for providing a secure, easily scalable, and flexible network token processing system” (at [0029], underlining and italic added), and reiterating that:
“[0029] … tokenization [some further explanations below] can involve the replacement or exchange of original payment credentials (e.g., a primary account number (PAN)) for substitute data (e.g., a non-financial identifier or a substitute PAN). A token can be used to initiate or manage transaction activity. Tokens can also improve transaction security and increase service transparency. Furthermore, tokenization can reduce merchant and issuer costs by improving data security and reducing or eliminating the need to be PCI-DSS compliant.” (underlining and italic added).
The terminology
Paragraphs [0050]-[0085] provide a “description of some terms [which] may be helpful in understanding embodiments of the invention” (at [0049]). In the following, I will reproduce parts of that description despite their length and the fact that these are not necessarily definitions for the terms. I consider that a detailed discussion of the terms will not only be “helpful in understanding embodiments of the invention”, but will also provide some context to the described invention and insights as to the nature of the elements that constitute important parts of the invention. This, in turn, will be useful for my considerations later in the decision. The description given to the terms is as follows:
·Regarding “real account identifier” and “real issuer identifier”:
“[0064] A ‘real account identifier’ may include an original account identifier associated with a payment account. For example, a real account identifier may be a primary account number (PAN) issued by an issuer for a card account (e.g., credit card, debit card, etc.). For instance, in some embodiments, a real account identifier may include a sixteen digit numerical value such as ‘4147 0900 0000 1234.’ The first six digits of the real account identifier (e.g., ‘414709’), may represent a real issuer identifier (BIN) [i.e., Bank Identification Number (at [0030])] that may identify an issuer associated with the real account identifier.” (underlining and bold added)
·Regarding “tokenisation”, “token exchange”, and “de-tokenisation”:
“[0069] ‘Tokenization’ [see also the part of [0029] quoted above] is a process by which data is replaced with substitute data. … tokenization may be applied to any other-information [i.e., not necessarily PAN] which may be replaced with a substitute value (i.e., token).
[0070] ‘Token exchange’ or ‘de-tokenization’ is a process of restoring the data that was substituted during tokenization. For example, a token exchange may include replacing a payment token with an associated primary account number (PAN) that was associated with the payment token during tokenization of the PAN. …”
·Regarding “token”:
“[0050] A ‘token’ may include any identifier for a payment account that is a substitute for an account identifier. … a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. … a token may be ‘format preserving’ and may have a numeric format that conforms to the account identifiers used in existing payment processing networks (e.g., ISO 8583 financial transaction message format). … a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. ... A lookup table may be used to associate a real PAN and a corresponding random token. …
[0051] … the token format may allow entities in the payment system to identify the issuer associated with the token. … the format of the token may include a token issuer identifier [see below] that allows an entity to identify an issuer. … the token issuer identifier … can be included in an issuer identifier routing table (e.g., BIN routing table). The issuer identifier routing table may be provided to the relevant entities in the payment system (e.g., merchants and acquirers).
[0052] … the non-payment tokens may comprise different token issuer identifiers or may not comprise token issuer identifiers. … a token may pass the basic validation rules of an account number …
[0053] … tokens may be device-specific such that each device associated with an account may be provisioned with a particular token. As such, if a transaction uses a token that is initiated by a different device than the device that the token was provisioned into, the transaction may be fraudulent. Accordingly, device information may be stored in the token vault [some further explanations at [0034]-[0035] as discussed later] and used to ensure that the device used in a transaction is associated with the token that is being used in the transaction. … one PAN or account may have multiple tokens associated with it, where each PAN may have a different token for the different devices … . This provides additional security for transactions because network token systems have additional information to validate in order to control the use of sensitive information in a transaction processing system.” (underlining and italic added)
·Regarding “payment token issuer identifier (range)” and “token BIN”:
“[0065] A ‘payment token issuer identifier’ may include any series of characters, numbers, or other identifiers that may be used to identify an issuer associated with a payment token. For example, a payment token issuer identifier may include a token BIN that identifies a particular issuer associated with an account identified using the token. … a payment token issuer identifier may be mapped to a real issuer identifier (e.g., a BIN) for an issuer. … For example, a payment token issuer identifier ‘490000’ corresponding to a payment token ‘4900 0000 0000 0001’ can be mapped to an issuer identifier ‘414709’ corresponding to a payment account identifier ‘4147 0900 0000 1234.’ … a payment token issuer identifier is static for an issuer. For example, a payment token issuer identifier (e.g., ‘490000’) may correspond to a first issuer and another payment token issuer identifier (e.g., ‘520000’) may correspond to a second issuer, and the first and second payment token issuer identifiers may not be changed or altered without informing all entities within the network token processing system. … a payment token issuer identifier range may correspond to an issuer identifier. For example, payment tokens including payment token issuer identifiers from ‘490000’-‘490002’ may correspond to a first issuer (e.g., mapped to issuer identifier ‘414709’) and payment tokens including payment token issuer identifiers from ‘520000’-‘520002’ may correspond to a second issuer (e.g., mapped to real issuer identifier ‘417548’).” (underlining added)
·Regarding “token presentment mode”:
“[0066] A ‘token presentment mode’ may indicate a method through which a token is submitted for a transaction. Some non-limiting examples of the token presentment mode may include machine readable codes (e.g., QRTM code, bar code, etc.), mobile contactless modes (e.g., near-field communication (NFC) communication), e-commerce remote modes, e-commerce proximity modes, and any other suitable modes in which to submit a token.
…
[0068] The token presentment mode may include any identifier or method for indicating the mode through which a token is provided. For example, the token presentment mode may include a number associated with a particular type of transaction (e.g., 5 for NFC transaction, 3 for QR Code, etc.). … the token presentment mode could be provided through a type of cryptogram or other dynamic data generated for a transaction. … a token presentment mode may be provided by a mobile device or may be populated by a merchant access device (e.g., a POS [i.e., point-of-sale (at [0088])] terminal) or other entity within the transaction processing system (e.g., acquirer computer, merchant processor, etc.).” (underlining and bold added)
·Regarding “token attributes”:
“[0055] ‘Token attributes’ may include any feature or information about a token. … token attributes may include any information that can determine how a token can be used, delivered, issued, or otherwise how data may be manipulated within a transaction system. … the token attributes may include a type of token, frequency of use, token expiration date and/or expiration time, a number of associated tokens, a transaction life-cycle expiration date [these attributes are explained below], and any additional information that may be relevant to any entity within a transaction processing system. … token attributes may include a wallet identifier associated with the token, an additional account alias or other user account identifier (e.g., an email address, username, etc.), a device identifier, an invoice number, etc. … a token requestor [see below] may provide token attributes at the time of generation of tokens. … a network token system, payment processing network associated with the network token system, an issuer, or any other entity associated with the token may determine and/or provide the token attributes associated with a particular token.
[0056] A type of token may include any information or indicator of how a token may be used. … a type of token may be ‘payment’ or ‘non-payment’ …
[0057] Another token type may be a ‘static’ or ‘dynamic’ token type …
[0058] … dynamic tokens can include tokens that are limited or restricted in use (e.g., limited by time, amount threshold (aggregated amount or single-transaction amount), or by number of uses). As such, dynamic tokens can be generated and delivered on a per-transaction or on an as needed basis to the end user [see below] to initiate a payment transaction through a registered and authenticated device and/or channel. …
…
[0060] A ‘frequency of use’ of a token may indicate how many times a token can be used in a transaction. … For example, a token may include a frequency of use of single-use or multiple-use. …
[0061] A token expiration date and/or expiration time can determine a duration (e.g., days/hours/minutes) for which a token is valid. …
[0062] A life-cycle expiration date may include a time or date where the network token system may recycle or reuse a previously issued token. …
[0063] A number of tokens can include a number of dynamic tokens that can be requested for the same account identifier (e.g., PAN) and/or same device at one time. … tokens may be provided with overlapping time to live (TTL) so that one or more tokens may be active at any given time.” (underlining, italic, and bold added)
·Regarding “requestor” and “token requestor”:
“[0074] A ‘requestor’ may be an application, a device, or a system that is configured to perform actions associated with tokens. For example, a requestor can request registration with a network token system, request token generation, token activation. [sic] token de-activation, token exchange, other token life-cycle management related processes, and/or any other token related processes. … a requestor may include third party wallet providers, issuers, acquirers, merchants, and/or payment processing networks. A requestor may be referred to as a token requestor when requesting generation of a new token or requesting a new use of an existing token from a network token system. … Token requestors may include, for example, card-on-file [see below] merchants, acquirers, acquirer processors, and payment gateways acting on behalf of merchants, payment enables (e.g., original equipment manufacturers, mobile network operators, etc.), digital wallet providers, and/or card issuers.” (underlining and italic added)
·Regarding “token requestor identifier”:
[0075] A ‘token requestor identifier’ may include any characters, numerals, or other identifiers associated with an entity associated with a network token system. … a token requestor identifier can identify a pairing of a token requestor (e.g., a mobile device, a mobile wallet provider, etc.) with a token domain (e.g., e-commerce, contactless, etc.). …
[0076] … if a token requestor may request tokens for multiple domains, the token requestor may have multiple token requestor identifiers, one for each domain.
[0077] … For instance, the token requestor identifier may include a code for a token service provider (e.g., first 3 digits) such as the network token system and the remaining digits (e.g., last 8 digits) may be assigned by the token service provider for each requesting entity (e.g., mobile wallet provider) and for each token domain (e.g., contactless, e-commerce, etc.).
[0078] … a token requestor identifier may be used in a transaction during authorization processing. For example, a token requestor identifier may be passed through a transaction request message to validate that the entity that is initiating the transaction is the same as the entity that requested and manages the token. In some embodiments, an entity (e.g., digital or mobile wallet provider, merchant, merchant of record, payment enabler, etc.) can be assigned a token requestor identifier during an on-boarding or registration process. In some embodiments, an acquirer/acquirer processor/payment enabler (i.e., payment service provider) may populate the token requestor identifier for each merchant, mobile wallet provider, consumer [see below], etc. into the authorization message field prior to submitting the authorization request message to a payment processing network.” (underlining and italic added)
·Regarding “card-on-file”:
“[0081] A ‘card-on-file (COF)’ holder may include any entity that stores account details (e.g., card details, payment account identifiers, PANs, etc.) for use in transactions. For example, a COF entity may store payment information on file for various types of periodic payments such as monthly utility payments, periodic shopping transactions, or any other periodic or future transaction. Because payment credentials and/or associated tokens are stored at an entity for a future transaction, the transactions initiated by a COF entity include card-not-present (CNP) transactions. Another type of card-not-present (CNP) transaction includes e-commerce or electronic commerce transactions that are initiated between remote parties (e.g., a consumer device and a merchant web server computer).” (underlining and bold added)
·Regarding “end-user”:
“[0079] An ‘end-user’ may include any application, consumer, process, or system that is configured to interact with a requestor for tokenization/de tokenization/token management services. For example, an end-user may include a consumer, a merchant, a mobile device, or any other suitable entity that may be associated with a requestor in the network token system.” (underlining added)
·Regarding “consumer”:
“[0080] A ‘consumer’ may include an individual or a user that may be associated with one or more personal accounts and/or consumer devices. The consumer may also be referred to as a cardholder, accountholder, or user.” (underlining added)
·Regarding “provisioning”:
“[0054] ‘Provisioning’ may include a process of providing data for use. For example, provisioning may include providing, delivering, or enabling a token on a device. Provisioning may be completed by any entity within or external to the transaction system. …” (underlining added)
·Regarding “authentication”:
“[0071] ‘Authentication’ is a process by which the credential of an endpoint (including but not limited to applications, people, devices, processes, and systems) can be verified to ensure that the endpoint is who they are declared to be.” (underlining and italic added)
·Regarding “authorisation request message” and “authorisation response message”:
“[0082] An ‘authorization request message’ may be an electronic message that is sent to a payment processing network and/or an issuer of a payment account to request authorization for a transaction. An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or a payment account. … an authorization request message may include a payment token, an expiration date, a token presentment mode, a token requestor identifier, an application cryptogram, and an assurance level data [e.g., see item 416 on FIG. 4 and items 702I, 706I on FIG. 7 later in the decision]. … An authorization request message may also comprise additional data elements corresponding to ‘identification information’ including, by way of example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), an expiration date, etc. An authorization request message may also comprise ‘transaction information,’ such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction.
[0083] An ‘authorization response message’ may be an electronic message reply to an authorization request message generated by an issuing financial institution or a payment processing network. The authorization response message may include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the payment processing network) to the merchant’s access device (e.g., POS terminal) that indicates approval of the transaction. The code may serve as proof of authorization. …” (underlining, italic, and bold added)
·Regarding “original transaction” and “substitute transaction”:
“[0072] An ‘original’ transaction may include any transaction including an authorization provided by an issuer or an authorization provided on-behalf-of an issuer.
[0073] A ‘substitute’ transaction may be any transaction that is associated with an original transaction and that takes place after the original transaction, including repeat, refunds, reversals or exceptions (chargebacks, re-presentments, etc.).” (underlining added)
As it can be seen, the above terms describe, in a substantial level of detail, a number of clearly abstract elements generally included in the abstract business process of payment transaction. To the extent any physical entities are involved, these are described solely on the basis of their participation as parties to, or parts of, the abstract transaction process.
The terms “interface” and “server computer” are described as follows:
“[0084] An ‘interface’ may include any software module configured to process communications. For example, an interface may be configured to receive, process, and respond to a particular entity in a particular communication format. Further, a computer, device, and/or system may include any number of interfaces depending on the functionality and capabilities of the computer, device, and/or system. In some embodiments, an interface may include an application programming interface (API) or other communication format or protocol that may be provided to third parties or to a particular entity to allow for communication with a device. Additionally, an interface may be designed based on functionality, a designated entity configured to communicate with, or any other variable. For example, an interface may be configured to allow for a system to field a particular request or may be configured to allow a particular entity to communicate with the system.
[0085] A ‘server computer’ may typically be a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. The server computer may be associated with an entity such as a payment processing network, a wallet provider, a merchant, an authentication cloud, an acquirer or an issuer.” (underlining and bold added)
It appears that, in the context of the Specification, the term “interface” does not necessarily concern the low-level, physical, electronic, or data encoding aspects of the connection between different computing devices, or any such aspects of the human interaction with these devices. Hence different interfaces (as required by the invention) would simply mean different software modules and not necessarily materially different ways to communicate within the payment system.
It is perhaps worth clarifying that, throughout this decision, I have used the terms “low-level” and “high-level” in their common meaning, for example, as explained in Wikipedia® (viewed on 6 August 2024):
“High-level and low-level, as technical terms, are used to classify, describe and point to specific goals of a systematic operation; and are applied in a wide range of contexts, such as, for instance, in domains as widely varied as computer science and business administration.
High-level describe those operations that are more abstract and general in nature; wherein the overall goals and systemic features are typically more concerned with the wider, macro system as a whole.
Low-level describes more specific individual components of a systematic operation, focusing on the details of rudimentary micro functions rather than macro, complex processes. Low-level classification is typically more concerned with individual components within the system and how they operate.” (original bold)
In addition to the above description of the terms, some explanations are provided at paragraphs [0030]-[0047]. Below, I tried to summarise those while avoiding major repetitions (underlining and italic added in all quotations):
·“… a network token system … provides a platform that can be leveraged by external entities (e.g., third party wallets, e-commerce merchants, payment enablers/ payment service providers, etc.) or internal payment processing network systems that have the need to use the tokens to facilitate payment transactions” and “can further provide services such as card registration (e.g., PAN registration), token generation, token issuance, token authentication and activation, token exchange and token life-cycle management” (at [0034]);
·“The network token system can also provide token processing capabilities such as authorization processing, authentication for transactions, capture processing, clearing processing, settlement and reconciliation processing, interchange criteria for payment transactions, liability and dispute processing for token payment transactions, reporting for token transaction processing and other value added services with token” (at [0036]);
·“A token registry (also referred to as a token vault [see the parts of paragraph [0053] quoted earlier] or token database) can provide interfaces for various token requestors (e.g., mobile device, issuers, merchants, mobile wallet providers, etc.), merchants, acquirers, issuers, and payment processing network systems. The interfaces can be used to request, use, manage and request information about tokens” (at [0034]);
·“… the token vaults can also store and manage token BIN/PAN ranges. The token vaults may be managed by an issuer, network or an authorized third party” (at [0035]);
·“… a token can support interoperability and can be accepted, processed and routed by the entities (e.g., merchants, acquirer, issuers, processors, networks, etc.) within the payment system” (at [0035]);
·“… a token may be compatible with the current and further payment technologies, may be interoperable with Bank Identification Number (BIN) enabled payment processing networks (e.g., Visa®, MasterCard®, Discover®, etc.), and may be able to support authentication by different entities (e.g., issuers, wallet providers, merchants, etc.) in the payment system” (at [0030]); and
·“Format preserving tokens are desirable, since they can be used in existing payment systems. This results in minimal infrastructure changes and increases the chance that such tokens will be used by the participants in the payment system” (at [0032]).
It is worth noting that, in relation to the tokens and their parts, the Specification uses the word “format” in its meaning of the set of rules governing the specific number and range of symbols that can be used in a token as well as how the information contained in the token is represented by the symbols in the token. This should not be confused with the meaning of “format”, which could refer to the low-level storing and manipulating of information/data in various computer systems or low-level transferring of information/data electronically between such systems.
The embodiments of the invention
The next two sections are titled “I. Exemplary network token processing systems” and “II. Exemplary methods for network token processing”. In these last sections, exemplary embodiments of the invention are described in high detail by reference to the drawings. In view of my discussion of the Specification so far, including my sufficiently comprehensive discussion of the nature and functionality of the elements denoted by the terms used to describe the invention, I consider that the information contained in the drawings themselves makes them generally self-explanatory. Hence, for the purposes of my decision, I do not consider it necessary to provide a thorough discussion of all drawings and the corresponding detailed explanations in the description.
FIG. 1 (reproduced below) represents a “traditional payment system 100” (at [0096]). It shows “a block diagram of a typical transaction processing system 100 configured to use real issuer identifiers (e.g., bank identification numbers (BINs)) to route authorization request messages during transaction processing” (at [0086]). It is worth mentioning that “[i]n some implementations, different entities in FIG. 1 may communicate with each other using one or more communication networks such as the Internet, a cellular network, a TCP/IP network or any other suitable communication network. Note that one or more entities in the system 100 may be associated with a computer apparatus that may be implemented using some of the components as described with reference to FIG. 11 [it would appear that this should read ‘FIG. 12’]” (at [0087], underlining added). I have reproduced and discussed FIG. 12 later in the decision.
I believe that it will be useful to briefly explain the entities participating in the payment system of FIG. 1:
·The consumer “may be a person or an individual” utilising the consumer device to initiate a transaction with a merchant by interacting with the access device (e.g., a POS device) (at [0088]).
·The consumer device: (i) is associated with a payment account of the consumer; (ii) may be a payment card such as a credit card, debit card, prepaid card, loyalty card, gift card, etc.; (iii) “may be a mobile device such as a mobile phone, a tablet, a PDA, a notebook, a key fob or any suitable mobile device”; (iv) may include a wallet or a payment application; (v) may be configured to display a machine readable code; (vi) may be capable of scanning a machine readable code; and (vii) may be capable of communicating with the access device using a short range communication technology such as NFC (at [0089]).
·The access device: (i) is an access point to a transaction processing system that includes the acquirer computer, the payment processing network computer, and the issuer computer; (ii) may be associated with or operated by the merchant computer (e.g., may be a point of sale device, an electronic cash register, a display device, etc.); (iii) “may be configured to display transaction information in a format that may be read by the consumer device 120 (e.g., mobile phone) including a QR code, bar code, or any other information transfer mechanism”; and (iv) may be a personal computer that may be used by the consumer to initiate a transaction with the merchant computer (e.g., an online transaction) (at [0090]).
·The merchant computer: (i) is associated with a merchant; (ii) may be associated with a card-on-file (COF) merchant; and (iii) may be configured to generate an authorisation request for a transaction initiated by the consumer using the access device (at [0091]).
·The acquirer computer: (i) may represent a traditional acquirer/acquirer processor (the acquirer is typically a system for an entity (e.g., a bank) that has a business relationship with a particular merchant, a wallet provider or another entity); (ii) may be communicatively coupled to the merchant computer and the payment processing network; (iii) may issue and manage a financial account for the merchant; and (iv) may be configured to route the authorisation request for a transaction to the issuer computer via the payment processing network computer, and route an authorisation response received via the payment processing network computer to the merchant computer (at [0092]).
·The payment processing network computer: (i) may be configured to provide authorisation services, and clearing and settlement services for payment transactions; (ii) “may include data processing subsystems, wired or wireless networks, including the internet. An example of the payment processing network computer 160 includes VisaNetTM, operated by Visa®”; (iii) may include a server computer; (iv) may forward an authorisation request received from the acquirer computer to the issuer computer via a communication channel; and (v) may forward an authorisation response message received from the issuer computer to the acquirer computer (at [0093]).
·The issuer computer: (i) may represent an account issuer and/or an issuer processor; (ii) may be associated with a business entity (e.g., a bank) that may have issued an account and/or payment card (e.g., credit account, debit account, etc.) for payment transactions (in some cases, the business entity may also function as an acquirer) (at [0094]).
FIG. 2 (reproduced below) represents “a transaction processing system 200 utilizing a network token system, according to one embodiment of the invention” (at [0095], underlining added). In addition to the elements discussed above with reference to FIG. 1, system 200 includes a network token system 202 (having a token registry database (or token vault) 202A and a token processing server computer 202B) as well as token interfaces 208, 210, 212, 214, and 218. The network token system may (underlining added to all quotations):
·“generate a token that has the same format as a PAN to minimize disruption across the payment system and has a value that does not collide with any real PAN or an active token” (at [0113]);
·“support tokens generated by other entities such as issuers or wallet provider systems” (at [0116]);
·“provide token life-cycle management services [e.g., deactivating or cancelling a token, or updating token attributes such as token validity timeframes or frequencies of use] to the registered entities” (at [0114]);
·allow the registered entities to:
o“allow the consumers to update information about the PAN, e.g., assign a different PAN to a static token” (at [0115]);
o“request CVV2 (Card Verification Value) values (or other types of verification values, cryptograms, etc.) for tokens using their respective interfaces” (at [0117]);
o“provide details of the transactions submitted using tokens using their respective interfaces” (at [0118]);
o“request transactions made using tokens by providing the token requestor identifier, a token or token alias, and a date range (e.g., start and end date)” (at [0119]);
o“request authorization and settlement data for a given token/PAN combination and date range by providing a token requestor identifier, a PAN, a token and a date range” (at [0120]);
o“request all the tokens and their attributes assigned for a given PAN and a date range by providing a token requestor identifier, a PAN and a date range” (at [0121]);
o“request details for a specific token and PAN combination by providing a token requestor identifier, a PAN and a date range” (at [0122]);
·provide an interface for e-commerce merchants to:
o“integrate into their web applications to initiate token generation requests for card-on-file transactions during checkout processes” (at [0123]);
o“provide an option for the consumers to request a token during checkout to use in place of a PAN” (at [0124]);
·“provide a user interface for the consumer … to perform operations such [sic] user registration, payment account registration, token request generation, token deactivation, etc.” (at [0125]); and
·“provide a notification advice message to notify participating issuers or other entities that one of their consumers has requested a token (e.g., requested that their phone be provisioned with a token) using the network token system provisioning service” (at [0126]).
Notably:
“[0106] In some embodiments, the merchant computer 140 and the acquirer computer 150 may be provided with a token in lieu of a real account identifier (e.g., PAN) for various transaction use cases. For example, the merchant computer 140 and/or acquirer computer 150 may receive a token in the traditional PAN field of authorization request message and may forward the authorization request message to the payment processing network computer 160 for processing. The payment processing network computer 160 may replace the token with the real account identifier (e.g., PAN) and send a modified authorization request message to the issuer computer 170. In some embodiments, the authorization request message may further have the token moved to a new field in the authorization message and/or clearing message for the issuer computer 170 to receive so that the issuer may receive both the account identifier (e.g., PAN) and the token in such messages.
[0107] Accordingly, in some embodiments, the issuer computer 170 may be configured to receive both the real account identifier (e.g., PAN) and the token in the authorization request messages and in transaction clearing messages received from the payment processing network computer 160. Chargebacks and chargeback reversal messages may also contain both the token and the real account identifier (e.g., PAN). In some embodiments, the issuer computer 170 may choose to have the payment processing network computer 160 call out to have the issuer computer 170 provision the tokens. In some embodiments, the issuer computer 170 may provide the payment processing network computer 160 with its current token database via a bulk file interface.” (underlining added)
Regarding the communication between the entities of FIG. 2, it is stated that “[i]n some embodiments of the invention, different entities in the system 200 may communicate [utilising unspecified encryption techniques] with one another using one or more communication networks such as TCP/IP, cellular network, etc. In one embodiment, a web service environment for the network token system 202 can provide one or more of the communication interfaces with the network token system and may provide services associated with communication including entity authentication, request authorization, message security, etc.” (at [0096], underlining added).
With respect to the operation of the interfaces, it is explained that: “[i]n some embodiments, the token requestor interface 208 may include an application programming interface (API) or any other relevant messaging formats may be used” (at [0108], underlining added). It is also noted that “the merchant token interface 210 may include an API” (at [0127]), and that “the acquirer token interface 212 (which may be in the form of an API) may allow the acquirer computer 150 to communicate with the network token system 202 for tokenization and de-tokenization services” (at [0128]).
The token registry database 202A is used to store and maintain issued or generated tokens as well as any other information relevant to the tokens (at [0104]), which may include different token states (e.g., active, inactive, suspended, on hold, deactivated, or any other indication of the availability for a token to be used in a transaction) (at [0105]).
FIG. 4 “illustrates exemplary entries for the token registry database 202A, in one embodiment of the invention” (at [0165]). FIG. 4 is reproduced below and followed by a part of Table 1.
Table 1 is titled “Exemplary Token Record Data in Token Registry”, and contains some more detailed explanations about “records and/or data” that “the token vault may comprise” (at [0110]). For brevity, I have reproduced only a part of Table 1 to illustrate the nature of the information that can be included in the table.
It is clear from FIG. 4, Table 1, and the corresponding explanations that the entries, records, and/or data are described only as far as their information content is concerned. Nothing is said about how these are to be represented in the computer system, which strongly suggests that this should be done in the usual standard way.
FIG. 3 (reproduced below) “illustrates components of the token processing server computer 202B [of FIG. 2] in one embodiment of the invention” (at [0135]). The lack of specificity of the computer implementation for the token processing server computer is evident not just from FIG. 3, but also from the corresponding explanations, some of which are reproduced below:
“[0137] The processor can comprise a CPU, which comprises at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. The CPU may be a microprocessor such as AMD’s Athlon, Duron and/or Opteron; IBM and/or Motorola’s PowerPC; IBM’s and Sony’s Cell processor; Intel’s Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s). The CPU interacts with memory through signal passing through conductive conduits to execute stored signal program code according to conventional data processing techniques.
[0138] The network interface 302 may be configured to allow the network token system 202 to communicate with other entities such as the consumer device 120, merchant computer 140, acquirer computer 150, payment processing network computer 160, issuer computer 170, etc. using one or more communications networks. … Network interfaces may employ connection protocols such as, but not limited to: direct connect, Ethernet (thick, thin, twisted pair 10/100/1000 Base T, and/or the like), Token Ring, wireless connection such as IEEE 802.11a-x, and/or the like. A communications network may be any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like.
[0139] The memory 304 may be used to store data. The memory 304 may be coupled to the processor 300 internally or externally (e.g., cloud based data storage) and may comprise any combination of volatile and/or non-volatile memory, for example, RAM, DRAM, ROM, flash, or any other suitable memory device.
[0140] The computer readable medium 306 may be in the form of a memory (e.g., flash, ROM, etc.) and may comprise code, executable by the processor 300 for implementing methods described herein. …”
…
[0142] … a graphical user interface may be used to provide token requestor information to the network token system 202. The user interface may be a conventional graphic user interface as provided by, with, and/or atop operating systems and/or operating environments such as Apple Macintosh OS, e.g., Aqua, GNUSTEP, Microsoft Windows (NT/XP), Unix X Windows (KDE, Gnome, and/or the like), mythTV, and/or the like. The user interface may allow for the display, execution, interaction, manipulation, and/or operation of program components and/or system facilities through textual and/or graphical facilities. The user interface provides a facility through which users may affect, interact, and/or operate a computer system.” (underlining added)
The software modules 308, 310, 312, 314, 316, 318, and 320 are described (e.g., at paragraphs [0143]-[0164]) entirely by reference to their functionality, which would imply that the skilled addressee would be familiar with the way to program these modules without any difficulties.
FIG. 5 is very similar to FIG. 3, and “illustrates components of the payment processing network computer 160 in one embodiment of the invention” (at [0168]). In addition to the “Network interface” and “Memory” of FIG. 3, FIG. 5 shows an extra element “Database” also directly connected to the “Processor”. This database “may store data associated with a plurality of consumers such as consumer personal and payment account information” (at [0172]). As it could be expected, the software modules, stored on the “Computer readable medium” of FIG. 5 are also different, i.e.: “Authorization module”, “Authentication module”, “Capture module”, “Clearing module”, “Settlement and reconciliation module”, “Interchange fee programs module”, “Regulations/exception processing module”, “Reporting module”, and “Value added services module”. The explanations (e.g., at paragraphs [0169]-[0190]) corresponding to FIG. 5 are of very similar nature to the explanations corresponding to FIG. 3. In the interest of brevity, I have not reproduced FIG. 5 and I do not consider it necessary to discuss these explanations.
FIG. 6 (reproduced below) “shows a table 600 illustrating examples of token BIN ranges mapped to issuer BINs, in one embodiment of the invention” (at [0191]). With respect to the first two rows of data, it is explained that “the first six digits of the PAN ‘4147 0900 0000 1234’ include issuer BIN ‘414709.’ The network token ‘4900 0000 0000 0001’ corresponding to this PAN include the token BIN range ‘490000-4900001’ mapped to the issuer BIN ‘414709.’ … the same PAN number may be mapped to different network token numbers as shown” (at [0193]).
As I already mentioned, “the static nature of the tokenized BIN allows the network token system to more effectively manage the assignment and distribution of tokens in the payment system because a distributed routing table including token issuer identifiers may be delivered to existing transaction processing entities within the payment system and may be implemented without extensive infrastructure investment and reconfiguration” (at [0194]). Exemplary token routing table is shown in Table 3, reproduced below.
It appears that there is an error in Table 3, because the token account range for Issuer B includes the token BIN for Issuer A instead of that for Issuer B and, thus, coincides with the token account range for issuer A.
Having the token routing table in their possession, the entities will be able to identify the issuer of any token in the payment system. However, the particular way of delivering the token routing table to the entities is not important for the working of the invention:
“[0198] After updating a routing table file, the routing table file may be distributed or sent to the transaction processing entities (e.g., a merchant computer, an acquirer computer, and/or a payment service provider computer). The routing table file may be sent through any suitable method including a ‘push’ messaging process or a ‘pull’ messaging process. For example, in a push messaging process, a payment processing network or network token system may periodically (e.g., hourly, daily, weekly, etc.) or based on each update to the token routing table (e.g., routing table update based), [sic] the payment processing network or network token system may send the updated routing table to registered entities within the transaction system. Alternatively or in combination, in a pull messaging process, a recipient system (e.g., a merchant, POS device, POS manufacturer, acquirer computer, issuer computer, etc.) may ask for an updated routing table periodically or based on a transaction (e.g., during a token based transaction). In some embodiments, the routing table file may be sent to a central database (BIN routing table manager or other third party) that then forwards the token routing table to the recipients.” (underlining added)
FIG. 7 (reproduced below) “shows a table 700 illustrating exemplary fields of an authorization request message with PAN based values initiated using a portable consumer device (e.g., a credit card) and token based values (initiated using a mobile device with the token provisioned thereon), according to one embodiment of the invention” (at [0200], underlining added).
The authorisation request message “may be generated by the merchant computer 140 in response to a transaction initiation request by a consumer 110” and “the table 700 provides a comparison of the transaction fields 702 included in a traditional transaction initiated using a PAN based value 704 from a credit card (or other portable device) and a transaction initiated using a token based value 706 from a mobile device” (at [0201], underlining added).
The description emphasises that “[a]s can be seen in the table 700, embodiments provide additional data elements [e.g. ‘Token Presentment Mode’ 702C, etc.] to be passed during transaction processing that are not available to traditional payment processing systems using credit, debit, smart cards, or any other traditional account identifier systems” (at [0202], underlining added). However, this simply highlights the fact that the difference with respect to the “traditional transaction” appears to be solely in the “data elements”, i.e., in the information content of the authorisation request message.
FIG. 8 (reproduced below) “illustrates a transaction flow using a payment token according to an embodiment of the invention” (at [0215]). Importantly however, the invention is not limited to the transaction flow of FIG. 8:
“[0215] … In the embodiment shown in FIG. 8, a token requestor requests a token for an account identifier and provisions the token into the consumer device which the consumer then uses to initiate a transaction using the token. However, it is worth noting that other token processing methods may be possible using embodiments of the invention. For example, a token requestor may include a merchant computer and a token may be provided to a merchant and stored as a card-on-file token such that the merchant may perform transactions without providing the token to a consumer device as shown in FIG. 8. Further, an issuer may request a token and provide the token to the consumer device. As such, there are a variety of different methods and processes for obtaining a token and initiating a transaction using a token that are not shown in FIG. 8, as one of ordinary skill in the art would recognize. Embodiments of the invention may be used with any other [sic] these methods of obtaining and provisioning tokens as well as initiating transactions using the tokens.” (underlining added)
I believe that the diagram of FIG. 8 is sufficiently self-explanatory and, given the underlined parts of the above quotation, I do not consider it necessary to go into further details. In addition, I can see certain similarities between FIG. 8 and FIG. 2, which I have already discussed.
FIG. 9 (reproduced below) “illustrates a process flow for token request processing by the network token system according to one embodiment of the invention” (at [0246]). It is further explained that:
“[0246] … The process flow of FIG. 9 may be in reference to any number of different token requests using any number of different token interfaces of the network token system. For example, the first entity may include a token requestor, merchant, issuer, acquirer, or any other entity that may obtain a token through the network token system. Further, the second entity may include any entity that may interface with the network token system to obtain any information or services from the network token system regarding an issued, generated, and/or provisioned token.” (underlining added)
I consider that FIG. 9 is also self-explanatory.
FIG. 10 (reproduced below) “shows a flow diagram for an exemplary transaction flow for NFC at the point-of-sale according to an embodiment of the invention” (at [0026], underlining added).
The authorisation process 1002 includes the consecutive steps 1002A to 1002G, whereas the clearing and exception process 1004 includes the consecutive steps 1004A to 1004D. In every step, the dot-points represent the type of information that is transferred between the respective entities (i.e., items 120, 140, 150, 160, and 170) during the step. It is clear that, in addition to being self-explanatory, FIG. 10 is focused entirely on which entities exchange what information in what order. The corresponding explanations at paragraphs [0266]-[0277] provide further details regarding this process of information exchange. No specifics about the actual way of transferring the data are given, again suggesting a standard implementation.
FIG. 11 “shows an exemplary flow diagram for card-on-file/e-commerce transaction according to one embodiment of the invention” (at [0278], underlining added).
This is, in essence, a variation of FIG. 10 (which, as I mentioned, illustrates the process concerning NFC at the point of-sale transaction). Otherwise, FIG. 11 is very similar to FIG. 10, and in the interest of brevity, I have not reproduced FIG. 11 and I do not see the need to discuss it any further.
Lastly, FIG. 12 (reproduced below) “shows a block diagram of a computer apparatus” (at [0028]).
As I observed with respect to FIG. 1, the description explains that “one or more entities in the system 100 may be associated with a computer apparatus that may be implemented using some of the components as described with reference to FIG. 11” (at [0087], underlining added). I also noted that, apparently, “FIG. 11” should read “FIG. 12”. Below, I have reproduced in full the explanations of FIG. 12 provided in the description:
“[0292] The various participants and elements described herein with reference to FIGS. 1 and 2 may operate one or more computer apparatuses to facilitate the functions described herein. Any of the elements in FIGS. 1 and 2, including any servers or databases, may use any suitable number of subsystems to facilitate the functions described herein.
[0293] Examples of such subsystems or components are shown in FIG. 12. The subsystems shown in FIG. 12 are interconnected via a system bus 1210. Additional subsystems such as a printer 1218, keyboard 1226, fixed disk 1228 (or other memory comprising computer readable media), monitor 1222, which is coupled to display adapter 1220, and others are shown. Peripherals and input/output (I/O) devices, which couple to I/O controller 1212 (which can be a processor or other suitable controller), can be connected to the computer system by any number of means known in the art, such as serial port 1224. For example, serial port 1224 or external interface 1230 can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus allows the central processor 1216 to communicate with each subsystem and to control the execution of instructions from system memory 1214 or the fixed disk 1228, as well as the exchange of information between subsystems. The system memory 1214 and/or the fixed disk 1228 may embody a computer readable medium.
[0294] Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.” (underlining added)
The above quotation is a strong further indication that the Specification is not concerned at all with the actual computer implementation of the invention. All activities related to system design, building, and actual programming, necessary for the working of the described network token system as part of the payment transaction processing system, are delegated to the skilled addressee wishing to perform the invention. The only implied guidance is that the hardware and software modules must have the functionality that is described only through high-level explanations.
In the above discussion of the embodiments of the invention, I have omitted some of the more detailed explanations provided in the Specification. The nature of these explanations merely reflects the general emphasis on the specific use of the tokens in the proposed network token system, including the information content of the tokens, look-up tables, databases, etc. as well as the information content of the messages exchanged, in a specific order, by the entities of the payment transaction processing system. As I already mentioned at the beginning of my consideration of the embodiments, for the purposes of my decision on manner of manufacture and in the interest of brevity, I do not consider it necessary to provide a more detailed discussion of these explanations.
The claimed invention
The Specification ends with 32 claims, from which claims 1, 8, 15, and 24 are independent. Claim 1 defines a method comprising steps that are performed largely by a server computer, whereas claim 8 defines a server computer comprising a processor and a computer readable medium comprising code, executable by the processor, for implementing a method comprising, in essence, the same steps. Similarly, claim 24 defines a method comprising steps performed by a server computer, whereas claim 15 defines a server computer comprising a processor and a non-transitory computer readable medium comprising code that, when executed by the processor, cause the processor to perform, in essence, the same steps. For brevity, I have reproduced below only the method claims 1 and 24 (some formatting added to assist readability):
“1. A method comprising:
assigning, by a server computer, a payment token issuer identifier to an issuer,
wherein the payment token issuer identifier is a substitute for a real issuer identifier for the issuer and is static for the issuer;
storing, by the server computer, a correspondence between the payment token issuer identifier, the issuer and a publicly available real identification number of the issuer at a routing table file,
wherein the routing table file identifies a server computer for processing the payment token issuer identifier;
sending the routing table file to at least one of a merchant computer, an acquirer computer, and a payment service provider computer;
receiving, by the server computer from a token requestor, a token request message requesting a payment token corresponding to a real account identifier identifying an account of a user;
identifying, by the server computer, the payment token comprising the payment token issuer identifier,
the payment token comprising the payment token issuer identifier of the issuer that replaces and obfuscates the publicly available real identification number of the issuer,
wherein the token is provisioned on a user communication device of the user;
executing, by the server computer, a consumer verification and authentication process;
determining, by the server computer, a token assurance level associated with the payment token based on the outcome of the verification and authentication process,
wherein the token assurance level represents a trust level of a binding between the payment token and the real account identifier corresponding to the payment token;
transmitting, by the server computer, the payment token and the token assurance level associated with the payment token to the token requestor;
receiving, by the server computer, an authorization request message comprising the payment token,
wherein the authorization request message is associated with a transaction between the user presenting the payment token provisioned on the user communication device and a second entity receiving the payment token;
processing, by the server computer, the transaction, wherein the processing includes:
determining, by the server computer, the token assurance level and the real account identifier associated with the payment token;
generating, by the server computer, a modified authorization request message comprising the real account identifier and the token assurance level;
accessing, by the server computer, the routing table file,
wherein the server computer has permission to access the routing table file;
identifying, by the server computer, the issuer identified by the payment token issuer identifier at the routing table file; and
transmitting, by the server computer, the modified authorization request message to the issuer identified by the payment token issuer identifier for approval,
wherein the issuer uses the token assurance level code to determine whether to authorize the transaction;
receive, from an entity via a communication interface dedicated to the entity, an information request message comprising the payment token and a token inquiry request associated with the payment token,
wherein the token inquiry request includes a request for one or more features of, or information about, the payment token;
identify a plurality of token attributes associated with the payment token in response to the token inquiry request,
wherein a token attribute represents a feature of, or information about, the payment token;
determine an identity of the entity based on at least a communication format of the communication interface dedicated to the entity;
identify one or more permissions associated with the entity based on the identity of the entity;
determine one or more attributes among the plurality of token attributes that the entity is authorized to obtain based on the permissions associated with the entity,
wherein the one or more attributes includes
a first set of attributes when the entity is determined to have a first identity, and
a second set of attributes different than the first set of attributes when the entity is determined to have a second identity; and
transmit, to the entity over the communication interface dedicated to the entity, a reply message in response to the information request message,
the reply message including the one or more attributes that the entity is authorized to obtain.
…
24. A method comprising:
determining, by a server computer, a token as a substitute for a primary account identifier associated with an account issued by an issuer computer,
wherein the issuer computer and the server computer are part of a transaction processing system,
wherein the server computer is configured to communicate with each entity in the transaction processing system via a dedicated communication interface,
wherein the server computer communicates with the issuer computer via an issuer communication interface provided to the issuer computer by the server computer, and
wherein the server computer communicates with an acquirer computer via an acquirer communication interface provided to the acquirer computer by the server computer;
transmitting, by the server computer, the token to a user communication device of an account holder associated with the account,
wherein the token is provisioned on the user communication device;
receiving, by the server computer from an entity in the transaction processing system via a communication interface dedicated to the entity, an information request message comprising the token and a token inquiry request associated with the token,
wherein the token inquiry request includes a request for one or more features of, or information about, the token;
identifying, by the server computer, a plurality of token attributes associated with the token in response to the token inquiry request,
wherein a token attribute represents a feature of, or information about, the token;
determining, by the server computer, an identity of the entity based on at least a communication format of the communication interface dedicated to the entity;
identifying, by the server computer, one or more permissions associated with the entity based on the identity of the entity;
determining, by the server computer, one or more attributes among the plurality of token attributes that the entity is authorized to obtain based on the permissions associated with the entity,
wherein the one or more attributes includes
a first set of attributes when the entity is determined to have a first identity, and
a second set of attributes different than the first set of attributes when the entity is determined to have a second identity; and
transmitting, by the server computer to the entity over the communication interface dedicated to the entity, a reply message in response to the information request message,
the reply message including the one or more attributes that the entity is authorized to obtain.”
Some additional advantages of the invention are also stated in the Specification, however they are not explicitly presented as solutions to specific problems in the prior art. Mr Powell also explains the advantages of the present invention. I will discuss the advantages as part of my consideration of the effects of the working of the invention.
With respect to the problems, Mr Powell describes “three of the main problems that have been addressed by the subject patent application” (IDec at [3], underlining added). These three problems are considered below.
The first problem
The first problem identified by Mr Powell is, in essence, the problem of paragraph [0008] of the description (quoted above) concerning the difficulties in identifying the source of the token or the issuer of the token, and the difficulties in routing token based messages to the correct issuers. However, Mr Powell also discussed some related secondary problems, namely:
“4. … This results in an overload of the network traffic with messages inquiring about the issuer associated with the token, or misrouted messages to wrong issuers.
5. … merchants and other entities in the tokenization ecosystem were not able to identify the issuer associated with an account because the tokens do not include an identifiable BIN or similar data. In addition to identifying the issuer, the BIN also identifies a type of the underlying account (e.g., a credit account, a debit account, a prepaid account). In absence of a BIN equivalent, some merchants such as can [sic] rental agencies, were not able to accept tokens. For example, in most jurisdictions, it is not possible to rent a car with a debit or prepaid account. If the car rental agency cannot determine whether the token is associated with a credit account, the car rental agency will not accept the token. … Thus, with the conventional tokens, it was not possible to initiate an electronic transaction for a car rental which would include a token. Therefore, there were industries that were not able to enjoy the security benefits provided by tokens.
6. Moreover, certain accounts and/or cards may be restricted for use at particular locations or jurisdictions. The BIN of an account identifies these restrictions. If a merchant cannot identify the BIN, the merchant may not accept the token. Therefore, the use of tokens gets unduly narrowed down, and the security benefits provided by tokens may not be incorporated in real world use.” (IDec, underlining and italic added)
It is important to note that, in the above, alongside the problem identification, Mr Powell clearly states the underlying reason for the first problem, i.e., “the [prior art] tokens do not include an identifiable BIN or similar data”. This is also consistent with the explanations in the Specification.
As I have already discussed, “a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier” (the description at [0050], underlining added). I find it difficult to imagine anything more abstract than a series of alphanumeric characters. What information or meaning (including the issuer’s BIN, the type of the associated account, etc.) is, or can be, expressed by such a series of alphanumeric characters is also an abstract logical (as opposed to technical) consideration. It follows that, at its core, the first problem is not technical.
In addition, the fact that the conventional tokens could not be used in certain jurisdictions and/or industries, due to some possible compliance issues for the merchants as they could not identify, from the token itself, the BIN or whether the token is associated with a credit account, is completely detached from any technical considerations. The same applies to the overload of the network traffic. Such an overload, when caused by inefficient utilisation through heavy and potentially unnecessary traffic, while possibly somewhat exacerbated by limited network throughput capacity, is not, per se, a technical problem. The volume of information exchanged between the entities through the network is governed by the organisation of the payment system and the rules that must be followed by the entities. How the existing network is utilised is ultimately an administrative or business consideration that goes to the efficiency of network utilisation, and not to overcoming some possible genuine technical limitations, e.g., related to the finite throughput capacity. A more efficient utilisation of a network, e.g., by sending fewer and/or shorter messages, while beneficial from a business perspective, does not alter the technical characteristics of the network and does not have a technical character.
I conclude that the first problem is not technical.
The second problem
100. The second problem identified by Mr Powell is, in essence, the problem of paragraph [0009] of the description (quoted above) concerning the parties/entities needing information about the token and having no way to obtain such information, e.g., merchants being unable to do fraud analyses. In addition, Mr Powell also notes that “[s]haring PANs with all entities is not a suitable solution as it pauses [sic] a security and fraud risk by exposing the sensitive information, and defeats the purpose of tokenization” (IDec at [8], underlining added). Mr Powell further notes that:
“9. The same problem caused additional issues with respect to dissemination of sensitive information with digital wallet providers. As explained above, most electronic transactions are performed using tokens. Nowadays, when an account is provisioned on a digital wallet (e.g., Apple Pay, Google Pay, etc.), a token is generated and provisioned on the digital wallet. Visa has been approached by digital wallet providers asking for sensitive information that is being provisioned on the digital wallet. Since the digital wallet providers do not have a role in transaction processing, their access to the account data that is provisioned on the digital wallet has been restricted. Knowing which entity requests what type of information about an account token gives Visa (and other transaction processing networks) complete security over the sensitive data that the consumers trust Visa with. On the other hand, some other entities, for example a transit agency, may be entitled to receive a subset of sensitive information. Visa needs to know which entity is requesting the information, so that Visa can determine the permissions of the entity, and the token data that can be shared with the entity.” (IDec, underlining added)
101. Parties/entities in the payment system needing information about an abstract object (i.e., the token) and having no prescribed way to obtain such information is another problem related to the administrative organisation of the system and the rules for the parties/entities in the system. I cannot see any technical issues in making this information available to the interested parties/entities. Whether this will create “a security and fraud risk by exposing the sensitive information”, while perhaps important for the operation of the payment system, is not a technical consideration. In the present context, the concepts of security, fraud, and risk are all abstract non-technical concepts. Hence, problems expressed in terms of these concepts (e.g., security risk problems, fraud problems) are, prima facie, also non-technical.
102. Further, I cannot see any technical limitations preventing Visa from “know[ing] which entity is requesting the information, so that Visa can determine the permissions of the entity, and the token data that can be shared with the entity”, given that a communication channel with that entity already exists (since the entity is requesting information).
103. I conclude that the second problem is also not technical.
The third problem
104. Mr Powell explains:
“11. A third technical [see my earlier comments on that] problem is authentication and/or validation of account holders. When the tokenization was initially rolled out, issuers were validating the consumers. Therefore, the binding between the token and the account holder (or the account represented by the token) were strong. However, this type of authentication is not possible for all jurisdictions and/or all implementations. For example, during some authentication processes, the account holder provides a subset of personal information (e.g., only their address). The resulting authentication is not a strong one, and needs to be flagged as such. For example, for card-on file transactions where the account holder is not authenticated every time, it is important that a strong authentication is performed initially, and the associated token is flagged to have resulted from the strong authentication.” (IDec, underlining added)
105. It is important to note that “authentication and/or validation of account holders” are also abstract concepts. The evidence does not provide any reasons, which I would consider technical, as to why the particular type of authentication mentioned above “is not possible for all jurisdictions and/or all implementations” (underlining added), and none are, prima facie, apparent to me on fair reading of the Specification. Whether the authentication is strong or not and whether it needs to be flagged are also non-technical considerations.
106. I conclude that the third problem is also not technical.
The solutions to the problems and the effects of the working of the invention
107. Mr Powell discusses each one of the solutions to the three problems (and the effects resulting from that solution) separately, so it will be convenient for me to follow the same structure.
The solution to the first problem and the resulting effects
108. Mr Powell explains:
“7. To solve this problem, we designed a system that assigns token issuer identifiers to issuers. The token issuer identifier replaces the issuer BIN, which is publicly available. This way, issuers cannot be identified merely by reviewing or parsing a token by entities not privy to the token issuer identifier information. Yet, the tokenization system and entities working with the tokenization system will be able to identify the issuer by reviewing or parsing the token. The token issuer identifier is static: that is, the token issuer identifier is the same for all tokens generated for that issuer. The token issuer identifier is incorporated into the generated token. This way, when the token server receives the token in a transaction authorization request message, the token server can identify the issuer based on the token issuer identifier embedded in the token. The tokenization system further generates a lookup table that stores a mapping between the token issuer identifiers and corresponding issuer BIN ranges. The lookup table is distributed to the transaction processing entities (e.g., a merchant computer, an acquirer computer, and/or a payment service provider computer). This way, the transaction processing entities may identifier [sic] the issuer by reviewing a token. This solution eliminates messages on the network from the transaction processing entities to the tokenization server inquiring about the identity of the issuer. The solution further eliminates messages on the network resulting from the requests being routed to wrong issuers. The resulting freed bandwidth may be used to improve the processing of other messages routed through the network.” (IDec, underlining added)
109. I note that, with the exception of the point concerning the freed network bandwidth, it does not appear that the above explanation includes anything beyond the explanations already provided in the Specification.
110. Assigning token issuer identifiers to issuers is a perfect example of an administrative process. As I have noted earlier, a token issuer identifier “may include any series of characters, numbers, or other identifiers that may be used to identify an issuer associated with a payment token” (the description at [0065]). Incorporating one abstract object (i.e., the token issuer identifier) into another abstract object (i.e., the token) does not involve any technical considerations. The same applies to the lookup table (termed “issuer identifier routing table” in the Specification see, e.g., paragraph [0051]) that is generated and “distributed to the transaction processing entities”. All this relates to the high-level rules of generation and distribution of information with no regard to the actual way of doing so via the computer implementation, which, as I have also already noted, is described in the Specification only in general non-specific terms.
111. Regarding the possible effect of “freed bandwidth”, as per my earlier discussion of network utilisation, this cannot be considered a technical effect of the working of the invention. In the same way, a ban on sending non-essential and/or non-work-related messages on a corporate network would not have a technical effect and would not be patentable, despite the fact that this may well “improve the processing of other messages routed through the network”.
112. I conclude that the solution to the first problem is administrative and not technical, and does not produce a technical effect.
The solution to the second problem and the resulting effects
113. Mr Powell states that:
“10. To solve this problem, we designed a system where each entity in the tokenized transaction environment is assigned a dedicated interface to communicate with the tokenization server. Entities involved in a tokenized transaction may request information about the token so that they can assess whether the token is legitimate, and/or whether the transaction is a fraudulent transaction. This is accomplished by using a server computer in communication with all other entities in the payment processing system via a dedicated communication interface. The server computer can determine an identity of the entity requesting the information based on the communication interface used by the entity. The server computer can then identify the permissions of that entity, and determine whether the entity is authorized to receive the information that they requested. … This improves security around the sensitive information. By confirming permissions of entities based on their dedicated communication interfaces, the tokenization server securely exchanges sensitive data with the entities. For example, an ISO or other payment processing network based communication protocol may be beneficial for use during a token request. These communication lines may be more secure than communications sent through the internet or other communications networks and thus, the ISO or payment processing network communication protocol token requests may leverage the security of the payment processing network communication protocols and infrastructure when requesting tokens through the network token system. Less sensitive data may be shared over the internet or other communications networks. This improves overall security of the system, safeguards the sensitive data, and reduces processing power dedicated to identifying and processing fraudulent transactions.” (IDec, underlining added)
114. I am, again, unsure as to how any of the above, at the level of generality of the description in the Specification, could be considered technical in nature. As per my earlier discussion, “[a]n ‘interface’ may include any software module configured to process communications” and “may include an application programming interface (API) or other communication format or protocol that may be provided to third parties or to a particular entity to allow for communication with a device” (the description at [0084]). The mere decision to provide or assign a “dedicated interface” to “each entity in the tokenized transaction environment” is an administrative decision in relation to the high-level organisation of the transaction system. The same applies to the decision to use more secure known communication channels for transmitting sensitive information, and to use less secure known communication channels for sharing less sensitive information.
115. As to the effect of improved security, I already mentioned that security is an abstract concept. Improving security and safeguarding sensitive data by administrative means (as opposed to technical means) does not have a technical character and cannot produce a technical effect. As a simplified example, improving security of a data centre by proposing an improved design for the locking device on the entry door, such that the primary functionality of the locking device will be improved, could be patentable. On the other hand, improving security of the same data centre by employing a security personnel to guard that door would not be patentable. Similarly unpatentable would be increasing security by requiring the selection of a stronger, more complicated password when creating an online access for a user.
116. Reducing processing power dedicated to a specific activity (i.e., “identifying and processing fraudulent transactions”) is not a technical effect either. It is perhaps worth noting that, in general, a computer implemented business method that is well-designed as a method (e.g., having no unnecessary or redundant steps), but with no ingenuity or invention in the computer implementation (see RPL Central at [96] and [112] as quoted earlier), may well reduce the required processing power in comparison to a poorly designed, prior art computer implemented business method performing the same task. However, this, on its own, would not be considered a technical effect, and the well-designed business method would not be considered patentable just because it “reduces processing power dedicated” to its execution.
117. I conclude that the solution to the second problem is also not technical and does not produce a technical effect.
The solution to the third problem and the resulting effects
118. Mr Powell explains that:
“12. To solve this problem, we came up with a token assurance value that is assigned to a token when the token is generated. The token assurance level indicates a trust level of the token to underlying PAN and/or account holder binding. The token assurance level is determined based on which entity performed the authentication of the consumer, as well as an authentication method performed. … Often, when the authentication is performed by Visa or the issuer, the token assurance level will be higher than when the authentication is performed by an intermediary entity. The token assurance level assigned to a token reduces fraud and fraudulent transactions as the entities in the tokenization ecosystem receive an indication of authentication associated with the token.
13. Since this information now has to be transmitted with the token, we also had to modify the data fields of the token registries where the tokens are stored to accommodate the token assurance level data. In addition, we had to modify industry standard transaction message formats (e.g., ISO 8583 financial transaction message format) to allow for a data field that will store the token assurance level data.
14. Moreover, the token assurance level results in a simplified authorization decision process for high token assurance level tokens, thereby reducing the amount of messages transmitted over the network to authenticate a transaction (one performed with a high token assurance level token), reducing the network use, and as a result increasing the network throughput. In addition, the rules-based systems now allow Visa and other processing networks to reject transactions performed with a low / very low token assurance level token before they even reach the issuers, and create fraud investigations.” (IDec, underlining and italic added)
119. I am struggling to see any technicality in the above explanations. The token assurance value (see item 416 on FIG. 4, and items 702I, 706I on FIG. 7) is an abstract concept involving some rules. As I already mentioned, fraud is also an abstract concept. Reducing “fraud and fraudulent transactions” by administrative means cannot produce a technical effect. Similarly, “the data fields of the token registries” and “industry standard transaction message formats”, at this level of generality, are also abstract logical constructs. Modifying them is a purely administrative process. The “authorization decision process” and the process of “reject[ing] transactions performed with a low / very low token assurance level token” are both of the same administrative nature. I have already discussed the effect of “reducing the network use, and as a result increasing the network throughput”.
120. I conclude that the solution to the third problem is also not technical and does not produce a technical effect.
Other possible effects of the working of the invention
121. I will now discuss some other possible effects of the working of the invention that I have not explicitly addressed so far.
122. The Specification notes that “[t]okens can also improve transaction security and increase service transparency. Furthermore, tokenization can reduce merchant and issuer costs by improving data security and reducing or eliminating the need to be PCI-DSS compliant” (at [0029], underlining added). Mr Powell also states that “[t]okens improve transaction security and increase service transparency” (IDec at [3], underlining added). Similarly, the Applicant submits that:
“The correct characterisation of the invention must therefore be one which accounts for at least increased transaction security and service transparency (including improvements in the routing of messages through the payment network).” (original italic, underlining added)
123. While I have already discussed the effect of increased security, I need to comment on the effect of increased service transparency. Even if I am to accept that the working of the present invention results in a further increase of the service transparency in comparison to the “conventional efforts to use payment tokens” (IDec at [3]), the concept of service transparency does not appear to be related to any technical considerations. The only definition for “transparency”, provided by Macquarie Dictionary (online edition, © Pan Macmillan Australia, 2024), that is appropriate in the present context is:
“4. (of a government or other organisation) the policy or practice of making all operations clearly manifest, and of being accountable to the public for all such operations.” (underlining added)
It is clear from the above definition that increasing the service transparency, per se, cannot be considered a technical effect.
124. As to the effect of “improvements in the routing of messages through the payment network”, in light of my earlier discussions of network utilisation, I consider that, in the context of the Specification, the routing of messages is an administrative consideration related to the efficient use of the existing network and unrelated to the low-level routing of data. Hence, the effect cannot be considered technical.
125. Finally, it is worth noting that “reduc[ing] merchant and issuer costs” by administrative means is also not a technical effect.
126. In summary, I have discussed the problems and the proposed solutions, and, from that discussion, it is clear to me that the present invention neither addresses a technical problem, nor provides a technical solution to any problem. I can also conclude that there is no technical effect produced by the working of the invention.
The Applicant’s more specific submissions
127. The Applicant submits that:
“The above remarks made by Powell clearly explain three technical problems and three technical solutions, as well as the advantages of these features and the improvements made to the state of the art by these features. These features, when considered as a whole, clearly provide a technical improvement as they improve the transaction processing systems for tokenized transactions.” (underlining and italic added).
128. Firstly, I have already discussed the three problems and the three solutions as explained by Mr Powell, and found that none of the problems, or corresponding solutions, is technical in nature. It follows that I cannot agree with the Applicant on that point. Secondly, I need to emphasise that features that “improve the transaction processing systems for tokenized transactions” (computer implemented business systems by their nature) do not necessarily provide a technical improvement, despite their commercial potential. In my analysis, I was unable to identify any technical improvements or effects attributable to the present invention.
129. With respect to the “three additional technical features” that I mentioned when discussing the section “Brief Review of Prosecution” of the Applicant’s Submissions, the Applicant explains:
“Throughout prosecution of the present application (and parent application), Applicant has added several additional technical features to the claims. For example, in Applicant’s response dated 31 January 2023, three technical features were added to the claims together with an explanation as to their contribution to the state of the art at the priority date:
1. ‘payment token [issuer] identifier’ and ‘routing table’: assigning a payment token issuer identifier to an issuer, wherein the payment token issuer identifier is a substitute for a real issuer identifier for the issuer and is static for the issuer; storing a correspondence between the payment token issuer identifier, the issuer and a publicly available real identification number of the issuer at a routing table file; and sending the routing table file to at least one of a merchant computer, an acquirer computer, and a payment service provider computer;
2. ‘token assurance level’: determining a token assurance level associated with the payment token based on the outcome of the verification and authentication process, wherein the token assurance level represents a trust level of a binding between the payment token and the real account identifier corresponding to the payment token; and
3. ‘token attributes authorized to be shared based on entity ID’: receiving, from an entity via a communication interface dedicated to the entity, an information request message comprising the payment token and a token inquiry request associated with the payment token; identifying a plurality of token attributes associated with the payment token; determining one or more attributes among the plurality of token attributes that the entity is authorized to obtain based on the permissions associated with the entity; and transmitting, to the entity over the communication interface dedicated to the entity, the one or more attributes that the entity is authorized to obtain.
Applicant described the technical nature of each feature together with an explanation of the advantages provided by each feature in the response dated 31 January 2023.” (underlining and italic added)
130. I have already considered the above features as they were involved in the solutions to the problems as presented by Mr Powell, and concluded that the solutions represented by these features are not technical. In addition, I have reviewed the above mentioned response from 31 January 2023, and I am not satisfied that “the technical nature of each feature” is described convincingly. In essence, in this response, the Applicant asserts that “[t]hese features, when considered as a whole, clearly provide a technical improvement as they improve the transaction processing systems for tokenized transactions” (a statement that I have already addressed), and notes that “[t]okenized transactions not only make the conventional transactions more secure, but also enabled the modern day transactions performed using mobile devices (e.g., the electronic wallets of today are based upon the earlier tokenization principles)” (underlining and italic added).
131. Regarding the latter statement above, even if I am to assume that by “tokenized transactions” the Applicant means the transactions made possible by the instant invention and not the “conventional efforts to use payment tokens” (IDec at [3]), I am not presented with any explanations about possible technical limitations that, at the priority date, prevented mobile devices from being used for performing transactions (if indeed that was the case), and how the present invention overcomes these technical limitations. I am unable to infer any such limitations myself either.
132. The Applicant also submits that:
“Even if the skilled person were to consider that ‘tokenization’ is based on non-technical considerations ‘utilising well-known generic implementations of computers’, the problem of how can card issuers and merchants improve account security and enable new payment experiences (e.g., mobile device payments) through tokenization is a technical problem. Indeed, when the contribution is seen in this way, it has a technical effect on a process carried on inside the computer system … . For example, in the form of increased transaction security without compromising the efficacy of the payment processing system as a whole.” (original underlining, italic added)
133. Firstly, I must re-iterate that it is not up to the skilled person to consider whether a particular process is based on technical or non-technical considerations. Secondly, I completely disagree that the problem, formulated by the Applicant (and emphasised in italic) above, is a technical problem. This is purely an administrative or business problem. It is the solutions to this problem that could potentially be technical, however no such technical solutions are described in the Specification. I have already addressed the issue about increasing security.
134. The Applicant further argues that:
“… the server computer and the steps performed by the server computer are rooted in computer technology in order to overcome a problem specifically arising in the realm of payment systems. When viewed in this way, we respectfully submit the computer cannot be fairly considered as merely an intermediary or tool for performing the method while adding nothing of substance to the idea …” (underlining added)
135. Given the abstract and administrative nature of the described and claimed invention, in combination with the generality and non-prescriptiveness of the described computer implementation and utilisation, I am unable to identify anything that the computer is “adding … of substance to the idea”. Neither the Specification, nor the Applicant’s Submissions (including the evidence) provide any assistance in that respect. The fact that the invention cannot be implemented without the use of computer technology, or as put by the Applicant “the server computer and the steps performed by the server computer are rooted in computer technology”, is insufficient to confer patentability:
“99 In answer to the third question posed to Professor Verspoor, ‘Is the use of a computer (or computers) integral to carrying out the invention, or could the invention be carried out in the absence of a computer (or computers)?’, her view was that the use of computers was integral to carrying out the invention because the data bank which was the source of the engagement objects and the historical/tracking data were critical components of the invention. It was not feasible for there to be an implementation of the invention without the use of computers (see primary judge at [55]). This was adopted by the primary judge as a further reason in support of the conclusion that the invention claimed was a manner of manufacture. However, the question is not simply whether the claimed invention could not be implemented other than by the use of computers. That fact of itself is not sufficient, as the Full Court in Encompass observed at [91]. A claimed method that is unpatentable does not change its legal character merely because the method is implemented by the instrumentality of a computer.” (Rokt, original italic, underlining added)
136. In addition, while the problem may be “specifically arising in the realm of payment systems”, I am unsure as to how this helps the Applicant’s case. For example, it could also be said that the problem in Rokt arose specifically in the realm of online advertising. Importantly, in my earlier analysis, I was unable to identify any problem related to the computer implementation of payment systems or any other technical problem solved by the present invention.
137. Finally, the Applicant also submits that:
“… the claimed invention provides a practical and useful result, as per as per [sic] Grant, paragraph 29, in the form of increased transaction security without compromising the efficacy of the payment processing system as a whole.” (underlining added)
138. I must note that the “practical and useful result” is also insufficient to confer patentability on its own. For example, at paragraph [4] of Repipe, Perram J (Nicholas and Burley JJ agreeing at [13] and [14], respectively) had “no difficulty in accepting that the invention is useful and represents a clever use of mobile devices and a server”, however His Honour still concluded that the invention “does not constitute patentable subject matter”.
The invention defined in claim 1
The substance of the invention defined in claim 1
139. On the basis of my earlier analysis, I consider that, as a matter of substance, the invention claimed in claim 1 is directed to a method implemented in a non-descript way on a standard server computer in communication with other standard computing devices, the method being characterised by the specific administrative arrangements as defined in the claim, including:
·assigning a static payment token issuer identifier to an issuer, and storing a correspondence between the payment token issuer identifier, the issuer, and the publicly available real identification number of the issuer in a routing table file, which is then sent to the computers of relevant entities;
·identifying/determining and providing/transmitting to respective relevant entities:
oa payment token comprising the payment token issuer identifier, and
oa corresponding token assurance level based on the outcome of a consumer verification and authentication process;
·using the token and the token assurance level for the purpose of authorising a transaction; and
·when an entity requests information about the token, using the communication interface dedicated to the entity to determine the identity of the entity, and transmitting to the entity the information that it is authorized to obtain based on the permissions for the entity.
Is the invention defined in claim 1 a manner of manufacture?
140. Having identified the substance of the invention as above, it is clear that, as a matter of substance, the invention defined in claim 1 cannot be characterised as a patentable technological innovation. Instead, I consider that it is properly characterised as a computer implemented administrative scheme for processing electronic payment transactions in a particular way via exchanging data between different entities, the data being characterised entirely by their information content. The scheme operates by utilising well-known computer technology for its well-understood functions, with no inventiveness or ingenuity in the computer implementation.
141. I conclude that the invention claimed in claim 1 is not a manner of manufacture.
Does any of the claims define an invention that is a manner of manufacture?
142. The other independent method claim (i.e., claim 24) defines a somewhat similar method, however some of the features of claim 1 appear to be missing, including:
·all features related to the payment token issuer identifier; and
·all features related to the token assurance level.
143. While this would mean that not all problems that were discussed by Mr Powell are necessarily solved by the invention defined in claim 24, this finding is inconsequential for my present consideration. It is clear that the invention defined in claim 24 is not any different in nature when compared to what is defined in claim 1. Therefore, the invention claimed in claim 24 is also not a manner of manufacture.
144. Earlier in this decision, I observed that claim 8 is very similar to claim 1, and claim 15 is very similar to claim 24. I consider that this similarity clearly extends to the nature of the defined invention. It follows that the invention claimed in claims 8 and 15 is also not a manner of manufacture.
145. The Applicant did not provide any submissions or evidence explicitly directed to the dependent claims. On reviewing these claims, I consider that each one of the dependent claims is still directed, as a matter of substance, to a computer implemented administrative scheme for processing electronic payment transactions in a particular way via exchanging data between different entities, the data being characterised entirely by their information content, the scheme utilising well-known computer technology for its well-understood functions with no inventiveness or ingenuity in the computer implementation. Any differences between each dependent claim and the respective independent claim, to which it is ultimately appended, are merely reflective of further details of the administrative scheme and the corresponding set of rules. In other words, I am not satisfied that any of the additional features defined in the dependent claims involve aspects that could change the nature of the invention as a matter of substance.
146. Therefore, I conclude that none of the claims in the Specification defines an invention that is a manner of manufacture.
Can an allowable amendment overcome the negative finding?
147. Earlier in this decision, I have discussed the body of the Specification in sufficient detail to be able to identify any material that could form the basis for a claim that defines a patentable invention. My discussions revealed no such material. I have placed a particular emphasis on the explanations given for the terminology and the computer implementation to highlight the abstract nature of the objects involved in the described invention and the standard non-descript nature of the computer implementation. Indeed, I can conclude that the disclosure in the Specification is limited to the high-level abstract information generation, storage, and exchange.
148. In the circumstances where I can see no clear way to overcome my negative finding with respect to manner of manufacture, and in view of the public interest in certainty as to the status of the Application, I consider that providing the Applicant with a further opportunity to amend and continuing the examination would serve no useful purpose.
Conclusion
149. I have found that no claim of the Application, as proposed to be amended, defines an invention that is a manner of manufacture. Furthermore, I have formed the view that no allowable amendment could result in claiming a patentable invention.
150. It follows that the Application should be refused.
Dr V. Z. Kolev
Delegate of the Commissioner of Patents