DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Applicant filed a response dated October 2, 2025 in which claims 1, 4-9, 11, 17, and 20 have been amended; claims 2, 3, 16, 18, and 19 have been canceled; and claims 21-24 have been added. Therefore, claims 2, 3, 16, 18, and 19 are currently pending in the application.
Priority
Application 18/275,272 was filed on August 1, 2023 and is a 371 of PCT/US22/14588 January 31, 2022 and claims benefit of SINGAPORE 10202101039T February 1, 2021.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. § 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. § 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 22 and 24 are rejected under 35 U.S.C. § 112(b) or 35 U.S.C. § 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claims 22 and 24 are rejected because they are not written in a single sentence. The claims must be in one sentence form only. See MPEP 2171-2175.
Examiner interprets the claims as: “the at least one processor further configured to: associate the virtual card with a merchant; receive a control from a user that specifies a limitation on transactions performed at the merchant using the virtual card; and associate the control with the virtual card.”
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 4-15, 17, and 20-24 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. (MPEP 2106). The claims are directed to a method, system, and apparatus which is one of the statutory categories of invention (Step 1: YES). The recitation of the claimed invention is analyzed as follows, in which the abstract elements are boldfaced.
Claim 1 recites the limitations of:
A method for generating a virtual card number used to process transactions from a card account having a primary account number (PAN), comprising: receiving, by one or more processors and from a plugin accessing a website, a request to generate the virtual card number, wherein the plugin operates in a browser and generates the request upon recognizing a card number field in the website;
retrieving, by the one or more processors, a trailing identifier that matches a trailing quantity of digits in the PAN such that the trailing quantity of digits are used by a consumer to identify the card account without revealing the PAN, wherein at least one of the trailing quantity of digits are a checksum value;
selecting, by the one or more processors, a bank identification number (BIN) from a plurality of available BINs;
selecting, by the one or more processors, an account identifier from a data structure of valid account identifiers built by:
(1) traversing the plurality of available BINs to determine a current BIN;
(2) traversing all trailing identifiers to determine a current trailing identifier;
(3) traversing all account identifiers to determine a current account identifier;
(4) running a checksum algorithm and when the combination of the current BIN, the current trailing identifier, and the current account identifier satisfies the checksum algorithm, adding the current account identifier to the data structure of valid account identifiers,
wherein the data structure of valid account identifiers is keyed using the current BIN and the current trailing identifier;
concatenating, by the one or more processors, the selected BIN, the account identifier, and the trailing identifier to generating the virtual card number, wherein the selecting the BIN and determining the account identifier occur such that, when concatenated, the virtual card number (i) is unique and (ii) satisfies the checksum value when a checksum algorithm is applied to the virtual card number;
linking, by the one or more processors, a virtual card having the virtual card number with the card account; and
returning, by the one or more processors, the virtual card to the plugin, wherein the plugin displays a graphical representation of the virtual card that indicates the virtual card number and the card account and auto-populates the card number field in the website with the virtual card number.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate management of financial information. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Moreover, the judicial exception is not integrated into a practical application. Other than reciting a “one or more processors”, to perform the steps of “selecting”, “traversing”, “concatenating”, and “linking”, nothing in the claim elements preclude the steps from practically being a certain method for organizing human activity. The claim as a whole does not integrate the exception into a practical application. The claim merely describes how to generally “apply” the concept of covers collecting, analyzing, and transmitting data to facilitate management of financial information in a computer environment. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the Specification discloses “[0117] Computer system 900 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof. [0118] Computer system 900 may be a client or server, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software ("on- premise" cloud-based solutions); "as a service" models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); and/or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms. [0119] Any applicable data structures, file formats, and schemas in computer system 600 may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XM/IL), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.”
Additionally, the claimed “plugin” and the “control from a user that specifies a limitation on transactions” are merely adding pre-solution activity to the judicial exception, as merely data gathering and displaying means of the VCN data, and the plugin is generally linking the judicial exception to a particular technological environment (facilitating communication between a website and a backend service). The specification says no more than the [0060] “Generating agent 300A may be operate as part of browser extension 107, as part of website offered by general services 124, independently, or in other suitable fashion”. “[0067] FIG 4 is a screen display of a checkout page 400 incorporating a VCN plugin/interface/browser extension, according to some embodiments.” “[0068] Plugin 402 provides an exemplary illustration of a generating agent, such as generating agent 300A.Plugin 402 may operate in a web browser or as a standalone component. In one embodiment, plugin 402 may operate as browser extension 107.”
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using “one or more processors”, to perform the steps of “selecting”, “traversing”, “concatenating”, and “linking”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate management of financial information in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”.
Claims 17 and 20 are substantially similar to claim 1, thus, they are rejected on similar grounds.
Claim 17 recites the additional elements of “A system for generating a virtual card number used to process transactions from a card account having a primary account number (PAN), comprising: a memory; and at least one processor coupled to the memory configured to:”.
Claim 20 recites the additional elements of “A non-transitory computer-readable storage medium having computer-executable instructions stored thereon that, in response to being executed by a computing device, cause the computing device to perform operations for”.
For similar reasons as explained above with regard to claim 1, under Step 2A, prong two, these additional elements are merely applying generic computer components to implement the abstract idea. Under Step 2B, when viewing the additional elements individually and in combination, the additional elements do not amount to an inventive concept amounting to significantly more than the judicial exception itself as the claimed computer-related technologies are mere tools for implementing the abstract idea as explained with regard to claim 1.
Dependent claims 4-15, and 21-24 merely limit the abstract idea and do not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Therefore, claims 1, 4-15, 17, and 20-24 are not patent-eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 12, 17, 20, 22, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Johnson, U.S. Patent Application Publication Number 2016/0350746; in view of Fortney, U.S. Patent Application Publication Number 2022/0188825; in view of Rausaria, U.S. Patent Application Publication Number 2016/0048913; in view of Collinge, U.S. Patent Application Publication Number 2023/0164122; in view of Scipioni, U.S. Patent Application Publication Number 2009/0132405.
As per claim 1,
Johnson explicitly teaches:
retrieving, by the one or more processors, a trailing identifier that matches a trailing quantity of digits in the PAN such that the trailing quantity of digits are used by a consumer to identify the card account without revealing the PAN, wherein at least one of the trailing quantity of digits are a checksum value;
(Johnson US20160350746 at paras. 17-20) ("[0018] With regard to FIG. 1, some issuer FIs and/or other entities may utilize the seventh digit 109 (which is a “1” in the illustrated example) or a number of additional digits to differentiate between financial products, such as between a credit card account and a debit card account. In the example shown in FIG. 1, the first seven digits are utilized to identify the issuer and payment product. Thus, when allocating a Token Number (i.e., performing tokenization) a determination must be made as to what type of payment product the PAN represents to ensure that the Token Number that is allocated will match the payment product associated with that PAN. This is important to ensure that, for example, when the tokenized proximity payment card is used in a purchase transaction it is correctly identified so that the merchant is charged the correct fee and/or the issuer FI receives the correct Interchange fee(s), as well as for other reasons, such as post-processing concerns. In some embodiments, as mentioned above, additional digits may be utilized to differentiate between financial products and such additional digits may also be utilized, for example, by an issuer FI to indicate a subsidiary company or a branch of their business to which the cardholder is associated. [0019] Furthermore, in novel embodiments described herein, a Token Number is allocated to a proximity payment device such that the last four (4) digits of the Token Number match the last four digits 110 (including the final check digit 108) of the cardholder's PAN. This is important to facilitate merchant post-processing needs which may occur, for example, to process a payment card account holder request for a refund, or to process merchandise returns, and/or for record management purposes. In particular, the last four digits of the cardholder's PAN are typically required by a merchant to identify the cardholder's payment account so that a return or exchange of merchandise can be processed such that the cardholder's payment account can be credited and/or charged-back.")
selecting, by the one or more processors, a bank identification number (BIN) from a plurality of available BINs;
(Johnson US20160350746 at paras. 21-23) ("[0022] The system 200 of FIG. 2 includes a Token Service Provider computer 204 that is operably connected to a token vault 206 (which may be a storage device and/or database) and to a payment network 208. Token Service Providers (TSPs) are entities that are authorized to generate and provide Tokens to registered token requestors and in some embodiments may be owned and/or operated by the operator of the payment network 208. Token Service Providers are responsible for a number of functions including, but are not limited to ongoing operation and maintenance of the Token Vault 206, Token Number generation and issuance, application of security and controls, payment token provisioning and token requestor registry functions. In some embodiments, the Token Service Provider 204 builds and manages its own proprietary token requestor application programming interfaces (APIs), Token Vaults, token provisioning platforms, and token registries. The individual functional requirements that comprise such platforms and related systems are not described in detail herein, however, the TSP 204 ensures that the Token Numbers (or token Bank Identification Number (BIN) ranges) are managed distinctly from traditional bank identification numbers BINs (or BIN ranges), in part to avoid any inadvertent overlap of PANs and payment Token Numbers.")
selecting, by the one or more processors, an account identifier from a data structure of valid account identifiers built by:
(Johnson US20160350746 at paras. 27-30) ("[0028] FIG. 3 is a flowchart illustrating a tokenization process 300 that provides a unique Token Number with the last 4 digits equal to the last 4 digits of a cardholder's PAN in accordance with the systems and methods described herein. In particular, a TSP receives 302 a token request from a requester, which token request includes the primary account number (PAN) of a payment card account holder or consumer or cardholder. As mentioned above, the token requester may be an entity such as an issuer FI or merchant or cardholder. Next, the TSP then begins the tokenization process by allocating 304 a token prefix number (which is either an issuer-defined value or a Token Vault defined value) that is at least six (6) digits in length and comprises the most significant digits of the Token Number. In some embodiments, the token prefix number includes a payment product type identifier (for example, one or more digits that identify the payment product as being a credit card account, loyalty card account, or debit card account). Next, the TSP sets 306 the least significant four (4) digits of the Token Number to match the last four (4) digits of the PAN. The TSP then determines 308 the middle digits or middle portion of the Token Number, which may consist of six (6) digits up to nine (9) digits. [0029] In particular, the middle digits if a Token Number are determined such that the completed or full Token Number (which may be up to nineteen (19) digits long) is unique (i.e, there is no other Token Number currently in circulation that is the same), and so that it satisfies a Checksum or check digit algorithm, such as the LUHN formula.")
concatenating, by the one or more processors, the selected BIN, the account identifier, and the trailing identifier to generating the virtual card number, wherein the selecting the BIN and determining the account identifier occur such that, when concatenated, the virtual card number (i) is unique and (ii) satisfies the checksum value when a checksum algorithm is applied to the virtual card number;
(Johnson US20160350746 at paras. 27-30) ("[0028] FIG. 3 is a flowchart illustrating a tokenization process 300 that provides a unique Token Number with the last 4 digits equal to the last 4 digits of a cardholder's PAN in accordance with the systems and methods described herein. In particular, a TSP receives 302 a token request from a requester, which token request includes the primary account number (PAN) of a payment card account holder or consumer or cardholder. As mentioned above, the token requester may be an entity such as an issuer FI or merchant or cardholder. Next, the TSP then begins the tokenization process by allocating 304 a token prefix number (which is either an issuer-defined value or a Token Vault defined value) that is at least six (6) digits in length and comprises the most significant digits of the Token Number. In some embodiments, the token prefix number includes a payment product type identifier (for example, one or more digits that identify the payment product as being a credit card account, loyalty card account, or debit card account). Next, the TSP sets 306 the least significant four (4) digits of the Token Number to match the last four (4) digits of the PAN. The TSP then determines 308 the middle digits or middle portion of the Token Number, which may consist of six (6) digits up to nine (9) digits. [0029] In particular, the middle digits if a Token Number are determined such that the completed or full Token Number (which may be up to nineteen (19) digits long) is unique (i.e, there is no other Token Number currently in circulation that is the same), and so that it satisfies a Checksum or check digit algorithm, such as the LUHN formula.")
linking, by the one or more processors, a virtual card having the virtual card number with the card account; and
(Johnson US20160350746 at paras. 18-20) ("[0019] Furthermore, in novel embodiments described herein, a Token Number is allocated to a proximity payment device such that the last four (4) digits of the Token Number match the last four digits 110 (including the final check digit 108) of the cardholder's PAN.")
Johnson does not explicitly teach, however, Fortney does teach:
(2) traversing all trailing identifiers to determine a current trailing identifier; (3) traversing all account identifiers to determine a current account identifier; (4) running a checksum algorithm and when the combination of the current BIN, the current trailing identifier, and the current account identifier satisfies the checksum algorithm, adding the current account identifier to the data structure of valid account identifiers,
(Fortney US20220188825 at paras. 84-87) ("[0085] According to an embodiment, issuer vault system 120 generates temporary identification value 460 so that the rightmost or last four spaces or digits are made to correspond to the last four digits of the actual or real PAN. For example, where the last four digits of the actual account number or PAN are 1212, issuer vault system 120 identifies the last four digits of the generated payment item as 1212. [0086] With respect to the remaining digits, those between the leftmost digits identifying the BIN and the rightmost identifying the last four digits of the actual account number, issuer vault system 120 formats the data so as to create a unique identifier for the payment item and so that any format checking normally undertaken during transaction processing will be satisfied. Depending upon the length of the PAN field, the middle digits may vary in length from 4 to 8 characters in length. In an example embodiment, the middle digits comprise 6 characters or digits. In such a scenario, issuer vault system 120 selects the leftmost five digits of the middle six digits so that the five digits identify a unique identifier for those payment items that are currently being used for the particular issuer. The sixth digit of the middle six digits is selected so that a requirement of a check digit operation performed on the temporary identification number is satisfied. In an example embodiment, the check digit operation may be a checksum operation. More particularly, the checksum operation may be a modulus 10 operation. Issuer vault system 120 may perform a check sum operation by performing the following or similar operations: beginning with the second right most digit of the temporary identification number, doubling every other digit; for every digit wherein doubling the digit generates a number that is more than one digit, adding the digits of the number to obtain a single digit number; adding the digits of the temporary identification number to arrive at a sum; dividing the sum by 10 to arrive at a quotient; determining the temporary identification number is valid when the quotient is a whole number; and determining the temporary identification number is invalid when the quotient is not a whole number.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson and Fortney because it allows for improved methods for secure payment processing such as when a consumer uses a payment item in a payment transaction and the transaction undergoes authorization processing. (Fortney at Abstract and paras. 2-10).
Johnson and Fortney do not explicitly teach, however, Rausaria does teach:
(1) traversing the plurality of available BINs to determine a current BIN;
(Rausaria US20160048913 at paras. 27-30) ("[0027] At step 306, the payment service provider 106 then selects a BIN length based on the payment account demand associated with the issuer 108. For example, for an issuer that provides a 16-digit PAN, the BIN length may be selected according to TABLE 1 for the particular payment account demand. . . . As shown, when the payment account demand associated with the issuer 108 is less than 10,000, the payment service provider 106 may select, for example, a BIN length of 11 digits. Alternatively, when the demand associated with the issuer is 10,000,000, the payment service provider may select, for example, a BIN length of 8 digits. It should be appreciated that the BIN length may be any BIN length based on the demand, and may further be based on other factors, such as, for example, the PAN length, the type of issuer, or other factors that indicate more or less payment accounts may be needed, or other information.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, and Rausaria because it allows for improved method to provide the payment service provider, for example, the ability to vary the length of the BIN, so that the resulting number of possible account numbers is more aligned with the anticipated demand of the issuer. In this manner, a standard 6-digit BIN may be expanded into several BINs, which may then be assigned to various different issuers. (Rausaria at Abstract and paras. 2-12).
Johnson, Fortney, and Rausaria do not explicitly teach, however, Collinge does teach:
wherein the data structure of valid account identifiers is keyed using the current BIN and the current trailing identifier;
(Collinge US20230164122 at paras. 176-181) ("[0178] Reuse of transaction fields in the legacy case can thus be as follows. For PAN, 14 digits can be used for full identification of the token, with 1 digit for the counter associated to the token for a given number, and one to the Luhn number (which needs to be retained as a checksum to ensure valid numbers are used). The 6 bits of the expiry date can be repurposed with x bits used to identify the node and y bits used to refer to the relevant key list for that node. CVC2 provides three digits which can be used for the cryptogram. [0179] For security, it is desirable to change key lists on a regular basis to ensure system security against attacks. It is also important to be able to allow validation of credentials for a period after they have been created—a suggested approach is to allow validation of credentials for up to 24 hours after creation. If this is combined with a key rotation process that operates every 24-36 hours, this means that while the generation process will only ever have one active key list for a given node, the validation process will only need to consider two key lists (the one currently active for credential generation and the one active immediately before it). Using the established deterministic process based on the transaction counter thus establishes the key to be used. This type of binary information (i.e. one or the other) can be typically coded using one bit of information. The cryptogram plays a key role in protecting the integrity of the transaction—successful validation of a cryptogram computed over a given set of data using a correct key confirms that data originally used in credential generation is genuine. Any failure in the validation process can come from the use of wrong cryptographic material and/or corrupted transaction data. [0180] In each node, each generation (G) and validation (V) service has access to a local database. Any generation of transaction credentials for a given token is associated to a unique transaction identifier for each transaction. As discussed above, the local transaction counter (LTC) is managed by “G” for a given token in a given node using a given key list associated to a given use case. The same process applies at the time of validation by “V”. This information can be carried in the PAN field (digit 15, or digits 14 and 15) as shown in FIG. 20 or using the CVC2 field as shown in FIG. 21 with a retry flag in the expiry date field, with a “full counter” generated if necessary if LTC is at a higher value. It is however important to set a limit on the number of cryptograms that can be generated by G and validated by V for a given token for a given node for a given key list to ensure effective access control—this value “MaxTransactionCounter” may be stored in the key list and protected by the key list seal.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, and Collinge because it allows for improved method of effectively identifying in a transaction how credentials have been generated in order to enable their subsequent validation and to ensure system security against attacks and allow validation of credentials. (Collinge at Abstract and paras. 169-181).
Johnson, Fortney, Rausaria, and Collinge do not explicitly teach, however, Scipioni does teach:
A method for generating a virtual card number used to process transactions from a card account having a primary account number (PAN), comprising: receiving, by one or more processors and from a plugin accessing a website, a request to generate the virtual card number, wherein the plugin operates in a browser and generates the request upon recognizing a card number field in the website;
(Scipioni US20090132405 at paras. 46-53) ("[0046] In one implementation, the user 102 utilizes the browser application 122 to open the browser window 210 and access at least one of the merchant servers 140 via a merchant site 214 to view one or more items for purchase. When selected, the plug-in toolbar feature 220 is adapted to provide a menu item list 230 (e.g., drop-down selection menu or dashboard) on the desktop 200 so that the user 102 may select at least one of a plurality of menu items 232a-232n to execute a related command, which is described in greater detail herein. In one aspect, the drop-down window shade or dashboard of the plug-in toolbar feature 220 may be adapted to slide up or down from the toolbar 212 of the browser 210, which may be more aesthetically pleasing to the user 102 than a conventional pop-up window. In another aspect, the window shade or dashboard of the plug-in toolbar feature 220 may be adapted to drop down from the toolbar automatically when the plug-in module 126 detects a merchant site that may be requesting input from the user 102. The plug-in module 126 may detect this by analyzing the contents of the web page as displayed in the browser or by detecting a URL (i.e., uniform resource locator) corresponding to a known checkout page. For example, the plug-in module 126 may detect a checkout page on the merchant site requesting input of a bilking of shipping address or the input of a secure card number (e.g., debit card number or credit card number) to complete a purchase." "[0051] In one implementation, FIG. 2B shows an example of screen shot of a browser 250 displaying various functions 252 that may be provided by the plug-in module 126 via the plug-in toolbar feature 220. These functions 252 may include generating a secure card (e.g., secure credit card number), auto-filling one or more forms and/or form fields (e.g., user-generated information including billing and/or shipping address information), saving one or more receipts (including storing and generating receipts), viewing previous secure cards, viewing receipts, checking the balance of one or more user accounts, etc. As shown in FIG. 2B, these functions 252 may be selected by the user 102 from a pull-down menu 254. As described in reference to FIG. 2A, the plug-in toolbar feature 220 of the plug-in module 126 may be positioned in the toolbar 212 of the browser 210 for accessibility. In various implementations, the plug-in toolbar feature 220 facilitates online financial transactions on a communication network, such as the Internet.")
returning, by the one or more processors, the virtual card to the plugin, wherein the plugin displays a graphical representation of the virtual card that indicates the virtual card number and the card account and auto-populates the card number field in the website with the virtual card number.
(Scipioni US20090132405 at paras. 46-53) ("[0046] In one implementation, the user 102 utilizes the browser application 122 to open the browser window 210 and access at least one of the merchant servers 140 via a merchant site 214 to view one or more items for purchase. When selected, the plug-in toolbar feature 220 is adapted to provide a menu item list 230 (e.g., drop-down selection menu or dashboard) on the desktop 200 so that the user 102 may select at least one of a plurality of menu items 232a-232n to execute a related command, which is described in greater detail herein. In one aspect, the drop-down window shade or dashboard of the plug-in toolbar feature 220 may be adapted to slide up or down from the toolbar 212 of the browser 210, which may be more aesthetically pleasing to the user 102 than a conventional pop-up window. In another aspect, the window shade or dashboard of the plug-in toolbar feature 220 may be adapted to drop down from the toolbar automatically when the plug-in module 126 detects a merchant site that may be requesting input from the user 102. The plug-in module 126 may detect this by analyzing the contents of the web page as displayed in the browser or by detecting a URL (i.e., uniform resource locator) corresponding to a known checkout page. For example, the plug-in module 126 may detect a checkout page on the merchant site requesting input of a bilking of shipping address or the input of a secure card number (e.g., debit card number or credit card number) to complete a purchase." "[0051] In one implementation, FIG. 2B shows an example of screen shot of a browser 250 displaying various functions 252 that may be provided by the plug-in module 126 via the plug-in toolbar feature 220. These functions 252 may include generating a secure card (e.g., secure credit card number), auto-filling one or more forms and/or form fields (e.g., user-generated information including billing and/or shipping address information), saving one or more receipts (including storing and generating receipts), viewing previous secure cards, viewing receipts, checking the balance of one or more user accounts, etc. As shown in FIG. 2B, these functions 252 may be selected by the user 102 from a pull-down menu 254. As described in reference to FIG. 2A, the plug-in toolbar feature 220 of the plug-in module 126 may be positioned in the toolbar 212 of the browser 210 for accessibility. In various implementations, the plug-in toolbar feature 220 facilitates online financial transactions on a communication network, such as the Internet.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, and Scipioni because it allows for an improved process of purchasing items in online transactions in a more efficient and less time consuming manner. (Scipioni at Abstract and paras. 2-14).
As per claim 12,
Johnson explicitly teaches:
further comprising: associating, by the one or more processors, the virtual card with a merchant.
(Johnson US20160350746 at paras. 26-28) ("[0027] In an electronic commerce (or E-commerce) scenario, a payment card account holder can initiate payment to an E-commerce site or merchant website 218 using a mobile wallet (or digital wallet) to transfer payment and other order information. Such mobile wallets may be operated by payment account issuers FIs 210, the payment network 208, and/or third parties, and in many embodiments the digital wallet operator will likely be the token requestor. In this use case, the wallet operator uses tokenization to avoid the need to store the cardholder's PAN in the wallet platform for security or other business reasons. Thereafter, when a payment account holder initiates payment at a merchant website 218 that supports the electronic wallet, the electronic wallet will pass a payment token (instead of the PAN) along with additional payment token-related fields through a mobile wallet application programming interface (API) to the merchant website. Merchants will initiate authorizations using the payment Token Number and accompanying token expiration date in the same manner described above. In some embodiments, the merchant may store the unique Token Numbers of customers so that processing can occur using “card-on-file” processing without the need to store each customer's PAN. In addition, the stored tokens may be designated as only being recognized for purchase transactions involving that merchant's website.")
As per claim 22,
Johnson, Fortney, Rausaria, and Collinge do not explicitly teach, however, Scipioni does teach:
the at least one processor further configured to: associate the virtual card with a merchant. receive a control from a user that specifies a limitation on transactions performed at the merchant using the virtual card; and associate the control with the virtual card.
(Scipioni US20090132405 at paras. 46-53) ("[0046] In one implementation, the user 102 utilizes the browser application 122 to open the browser window 210 and access at least one of the merchant servers 140 via a merchant site 214 to view one or more items for purchase. When selected, the plug-in toolbar feature 220 is adapted to provide a menu item list 230 (e.g., drop-down selection menu or dashboard) on the desktop 200 so that the user 102 may select at least one of a plurality of menu items 232a-232n to execute a related command, which is described in greater detail herein. In one aspect, the drop-down window shade or dashboard of the plug-in toolbar feature 220 may be adapted to slide up or down from the toolbar 212 of the browser 210, which may be more aesthetically pleasing to the user 102 than a conventional pop-up window. In another aspect, the window shade or dashboard of the plug-in toolbar feature 220 may be adapted to drop down from the toolbar automatically when the plug-in module 126 detects a merchant site that may be requesting input from the user 102. The plug-in module 126 may detect this by analyzing the contents of the web page as displayed in the browser or by detecting a URL (i.e., uniform resource locator) corresponding to a known checkout page. For example, the plug-in module 126 may detect a checkout page on the merchant site requesting input of a bilking of shipping address or the input of a secure card number (e.g., debit card number or credit card number) to complete a purchase." "[0051] In one implementation, FIG. 2B shows an example of screen shot of a browser 250 displaying various functions 252 that may be provided by the plug-in module 126 via the plug-in toolbar feature 220. These functions 252 may include generating a secure card (e.g., secure credit card number), auto-filling one or more forms and/or form fields (e.g., user-generated information including billing and/or shipping address information), saving one or more receipts (including storing and generating receipts), viewing previous secure cards, viewing receipts, checking the balance of one or more user accounts, etc. As shown in FIG. 2B, these functions 252 may be selected by the user 102 from a pull-down menu 254. As described in reference to FIG. 2A, the plug-in toolbar feature 220 of the plug-in module 126 may be positioned in the toolbar 212 of the browser 210 for accessibility. In various implementations, the plug-in toolbar feature 220 facilitates online financial transactions on a communication network, such as the Internet.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, and Scipioni because it allows for an improved process of purchasing items in online transactions in a more efficient and less time consuming manner. (Scipioni at Abstract and paras. 2-14).
Claims 17 and 20 are substantially similar to claim 1, thus, they are rejected on similar grounds.
Claim 24 is substantially similar to claim 22, thus, it is rejected on similar grounds.
Claims 4 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Johnson, U.S. Patent Application Publication Number 2016/0350746; in view of Fortney, U.S. Patent Application Publication Number 2022/0188825; in view of Rausaria, U.S. Patent Application Publication Number 2016/0048913; in view of Collinge, U.S. Patent Application Publication Number 2023/0164122; in view of Scipioni, U.S. Patent Application Publication Number 2009/0132405; in view of Grassadonia, U.S. Patent Application Publication Number 2018/0005231.
As per claim 4,
Johnson explicitly teaches:
wherein the virtual card number is a sixteen-digit number,
(Johnson US20160350746 at paras. 15-17) ("[0016] In some implementations, the PAN is a sixteen to nineteen (19) digit number, and in some embodiments this is the number that is tokenized in accordance with methods described herein.")
wherein the BIN is a six-digit number,
(Johnson US20160350746 at paras. 27-30) ("[0028] Next, the TSP then begins the tokenization process by allocating 304 a token prefix number (which is either an issuer-defined value or a Token Vault defined value) that is at least six (6) digits in length and comprises the most significant digits of the Token Number.")
wherein the trailing identifier is a four-digit number, and
(Johnson US20160350746 at paras. 27-30) ("[0028] Next, the TSP sets 306 the least significant four (4) digits of the Token Number to match the last four (4) digits of the PAN.")
wherein the checksum value is a single-digit number.
(Johnson US20160350746 at paras. 16-18) ("[0017] The next ten digits 106 of the PAN may be used to identify the cardholder's account, wherein the final digit 108 (which is six (“6”) in the example depicted in FIG. 1) is typically a check digit. In some implementations, the check digit may be calculated, for example, using the “LUHN” algorithm (also known as the “modulus 10” or “mod 10” algorithm), but it should be understood that other types of checksum algorithms can be used as well.")
Johnson, Fortney, Rausaria, Collinge, and Scipioni do not explicitly teach, however, Grassadonia does teach:
wherein the account identifier is a five-digit number,
(Grassadonia US20180005231 at paras. 51-53) ("[0052] In a next step 205, the CCS server may generate a payment card number and a token representing the payment card number. The CCS server may generate the payment card number by appending together several sets of digits, including a predetermined bank identification number (BIN) prefix, a set of randomly generated digits representing a randomly generated number generated according to a random number generator algorithm, and one or more checksum digits generated and applied according to a checksum algorithm that confirms the uniqueness and accuracy of the new payment card number as a whole. Generally, the BIN prefix is a set of digits, typically six digits, associated with a bank or card issuer. The issuer processor or other entity may provide the BIN prefix to the CCS server; the CCS server may store the BIN prefix digits and may be configured to apply the BIN prefix digits to new payment cards generated by the CCS server, in accordance with the issuer processor or other entity. The CCS server may also generate a set of digits for the random number portion of the card number using a random number generator algorithm and generate a set of one or more digits based on a Luhn check algorithm (or other checksum algorithm) dictated by the issuer processor or other entity. The CCS server may append the set of one or more Luhn check digits to the randomly generated set of digits.")
Claim 4 recites “wherein the account identifier is a five-digit number”. Grassadonia discloses that a server may “generate the payment card number by appending together several sets of digits”, for example, “typically six digits”. Additionally, Grassadonia discloses an account identifier as “a random number portion”, which is one of the several sets of digits. (Grassadonia at para. [0052]). Although Grassadonia does not explicitly disclose a five-digit number, Grassadonia indicates that the six-digit identifiers may be preferred, the reference does not exclude the possibility of using identifiers with fewer digits, such as the claimed five-digit number.
Pursuant to MPEP 2144.05, “where the general conditions of a claim are disclosed in the prior art, it is not inventive to discover the optimum or workable ranges by routine experimentation.” In re Aller, 220 F.2d 454, 456, 105 USPQ 233, 235 (CCPA 1955). Here, Grassadonia discloses the general condition of using a multi-digit number, which is typically six digits. Thus, a person of ordinary skill in the art would be able to adjust the number of digits from six to five through routine optimization. In re Williams, 36 F.2d 436, 438, 4 USPQ 237 (CCPA 1929) ("It is a settled principle of law that a mere carrying forward of an original patented conception involving only change of form, proportions, or degree, or the substitution of equivalents doing the same thing as the original invention, by substantially the same means, is not such an invention as will sustain a patent, even though the changes of the kind may produce better results than prior inventions.")
Furthermore, pursuant to MPEP 2144.04, “the particular placement of a contact in a conductivity measuring device was held to be an obvious matter of design choice.” In re Kuhle, 526 F.2d 553, 188 USPQ 7 (CCPA 1975). Additionally, in Gardner v. TEC Syst., Inc., 725 F.2d 1338, 220 USPQ 777 (Fed. Cir. 1984), cert. denied, 469 U.S. 830, 225 USPQ 232 (1984), the Federal Circuit held that, where the only difference between the prior art and the claims was a recitation of relative dimensions of the claimed device and a device having the claimed relative dimensions would not perform differently than the prior art device, the claimed device was not patentably distinct from the prior art device. Likewise, in the instant application, changing the number of digits from six to five represents a minor modification of a known structure, used for the same purpose, and would have been considered an obvious design choice by a person of ordinary skill in the art.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, and Grassadonia to provide for “wherein the account identifier is a five-digit number”, because it allows for improved methods to protect consumers from fraud through improved, intelligent server behaviors. (Grassadonia at Abstract and paras. 2-13).
As per claim 5,
Johnson explicitly teaches:
wherein the virtual card number is a sixteen-digit number,
(Johnson US20160350746 at paras. 15-17) ("[0016] In some implementations, the PAN is a sixteen to nineteen (19) digit number, and in some embodiments this is the number that is tokenized in accordance with methods described herein.")
wherein the BIN is an eight-digit number,
(Johnson US20160350746 at paras. 27-30) ("[0028] Next, the TSP then begins the tokenization process by allocating 304 a token prefix number (which is either an issuer-defined value or a Token Vault defined value) that is at least six (6) digits in length and comprises the most significant digits of the Token Number.")
Similar to the rejection of claim 4, although Johnson does not explicitly disclose an eight-digit number, Johnson indicates that the six-digit bank identification numbers may be preferred, and the reference does not exclude the possibility of using numbers with more digits, such as the claimed eight-digit number. A person of ordinary skill in the art would be able to adjust the number of digits from six to eight through routine optimization and further a person of ordinary skill in the art would have considered the change to eight digits as an obvious design choice, as changing the number of digits from six to eight represents a minor modification of a known structure, used for the same purpose.
wherein the trailing identifier is a four-digit number, and
(Johnson US20160350746 at paras. 27-30) ("[0028] Next, the TSP sets 306 the least significant four (4) digits of the Token Number to match the last four (4) digits of the PAN. ")
wherein the checksum value is a single-digit number.
(Johnson US20160350746 at paras. 16-18) ("[0017] In the example payment card shown in FIG. 1, the first six (6) digits 104 of the PAN typically identify the issuer financial institution (FI) of the payment card account (for example, an issuer bank). The next ten digits 106 of the PAN may be used to identify the cardholder's account, wherein the final digit 108 (which is six (“6”) in the example depicted in FIG. 1) is typically a check digit. In some implementations, the check digit may be calculated, for example, using the “LUHN” algorithm (also known as the “modulus 10” or “mod 10” algorithm), but it should be understood that other types of checksum algorithms can be used as well.")
Johnson, Fortney, Rausaria, Collinge, and Scipioni do not explicitly teach, however, Grassadonia does teach:
the account identifier is a three-digit number,
(Grassadonia US20180005231 at paras. 51-53) ("[0052] In a next step 205, the CCS server may generate a payment card number and a token representing the payment card number. The CCS server may generate the payment card number by appending together several sets of digits, including a predetermined bank identification number (BIN) prefix, a set of randomly generated digits representing a randomly generated number generated according to a random number generator algorithm, and one or more checksum digits generated and applied according to a checksum algorithm that confirms the uniqueness and accuracy of the new payment card number as a whole. Generally, the BIN prefix is a set of digits, typically six digits, associated with a bank or card issuer. The issuer processor or other entity may provide the BIN prefix to the CCS server; the CCS server may store the BIN prefix digits and may be configured to apply the BIN prefix digits to new payment cards generated by the CCS server, in accordance with the issuer processor or other entity. The CCS server may also generate a set of digits for the random number portion of the card number using a random number generator algorithm and generate a set of one or more digits based on a Luhn check algorithm (or other checksum algorithm) dictated by the issuer processor or other entity. The CCS server may append the set of one or more Luhn check digits to the randomly generated set of digits.")
Similar to the rejection of claim 4, although Grassadonia does not explicitly disclose a three-digit number, Grassadonia indicates that the six-digit identifiers may be preferred, and the reference does not exclude the possibility of using identifiers with fewer digits, such as the claimed three-digit number. A person of ordinary skill in the art would be able to adjust the number of digits from six to three through routine optimization and further a person of ordinary skill in the art would have considered the change to three digits as an obvious design choice, as changing the number of digits from six to three represents a minor modification of a known structure, used for the same purpose.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, and Grassadonia to provide for “the account identifier is a three-digit number”, because it allows for improved methods to protect consumers from fraud through improved, intelligent server behaviors. (Grassadonia at Abstract and paras. 2-13).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Johnson, U.S. Patent Application Publication Number 2016/0350746; in view of Fortney, U.S. Patent Application Publication Number 2022/0188825; in view of Rausaria, U.S. Patent Application Publication Number 2016/0048913; in view of Collinge, U.S. Patent Application Publication Number 2023/0164122; in view of Scipioni, U.S. Patent Application Publication Number 2009/0132405; in view of Quentin, U.S. Patent Application Publication Number 2018/0025343.
As per claim 6,
Johnson explicitly teaches:
wherein the BIN is an eight-digit number,
(Johnson US20160350746 at paras. 27-30) ("[0028] Next, the TSP sets 306 the least significant four (4) digits of the Token Number to match the last four (4) digits of the PAN. The TSP then determines 308 the middle digits or middle portion of the Token Number, which may consist of six (6) digits up to nine (9) digits. [0029] In particular, the middle digits if a Token Number are determined such that the completed or full Token Number (which may be up to nineteen (19) digits long) is unique (i.e, there is no other Token Number currently in circulation that is the same), and so that it satisfies a Checksum or check digit algorithm, such as the LUHN formula.")
wherein the account identifier is a seven-digit number,
(Johnson US20160350746 at paras. 27-30) ("[0028] Next, the TSP sets 306 the least significant four (4) digits of the Token Number to match the last four (4) digits of the PAN. The TSP then determines 308 the middle digits or middle portion of the Token Number, which may consist of six (6) digits up to nine (9) digits.")
wherein the trailing identifier is a four-digit number, and
(Johnson US20160350746 at paras. 27-30) ("[0028] Next, the TSP sets 306 the least significant four (4) digits of the Token Number to match the last four (4) digits of the PAN. The TSP then determines 308 the middle digits or middle portion of the Token Number, which may consist of six (6) digits up to nine (9) digits. [0029] In particular, the middle digits if a Token Number are determined such that the completed or full Token Number (which may be up to nineteen (19) digits long) is unique (i.e, there is no other Token Number currently in circulation that is the same), and so that it satisfies a Checksum or check digit algorithm, such as the LUHN formula.")
wherein the checksum value is a single-digit number.
(Johnson US20160350746 at paras. 16-18) ("[0017] In the example payment card shown in FIG. 1, the first six (6) digits 104 of the PAN typically identify the issuer financial institution (FI) of the payment card account (for example, an issuer bank). The next ten digits 106 of the PAN may be used to identify the cardholder's account, wherein the final digit 108 (which is six (“6”) in the example depicted in FIG. 1) is typically a check digit. In some implementations, the check digit may be calculated, for example, using the “LUHN” algorithm (also known as the “modulus 10” or “mod 10” algorithm), but it should be understood that other types of checksum algorithms can be used as well.")
Johnson, Fortney, Rausaria, Collinge, and Scipioni do not explicitly teach, however, Quentin does teach:
wherein the virtual card number is a twenty-digit number,
(Quentin US20180025343 at paras. 74-76) ("[0075] Each type of service pre-defined within a secure element is associated with a unique identifier (PAN_S) built in the same format as a bank card number (or PAN from “Primary Account Number”). Such a number comprises at least 16 digits: six first digits which constitute an issuer identification number (or IIN) followed by a variable number of digits (often 9 digits and up to 12 digits) identifying the card within the bank; and finally a last checksum digit. Each of these identifiers (PAN_S) is not only unique within a same secure element but also unique within all the commercially distributed secure elements.")
Similar to the rejection of claim 4, although Quentin does not explicitly disclose a twenty-digit number, Quentin indicates that the sixteen-digit numbers may be preferred, the reference does not exclude the possibility of using numbers with more digits, such as the claimed twenty-digit number. A person of ordinary skill in the art would be able to adjust the number of digits from sixteen to twenty through routine optimization and further a person of ordinary skill in the art would have considered the change to twenty digits as an obvious design choice, as changing the number of digits from sixteen to twenty represents a minor modification of a known structure, used for the same purpose.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, and Quentin to provide for “wherein the virtual card number is a twenty-digit number”, because it allows for improved online processing of transactions, and more particularly to the processing of transactions using a communications terminal in a secured form. (Quentin at Abstract and paras. 1-13).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Johnson, U.S. Patent Application Publication Number 2016/0350746; in view of Fortney, U.S. Patent Application Publication Number 2022/0188825; in view of Rausaria, U.S. Patent Application Publication Number 2016/0048913; in view of Collinge, U.S. Patent Application Publication Number 2023/0164122; in view of Scipioni, U.S. Patent Application Publication Number 2009/0132405; in view of Grassadonia, U.S. Patent Application Publication Number 2018/0005231; in view of Quentin, U.S. Patent Application Publication Number 2018/0025343.
As per claim 7,
Johnson explicitly teaches:
wherein the BIN is an eight-digit number,
(Johnson US20160350746 at paras. 27-30) ("Next, the TSP then begins the tokenization process by allocating 304 a token prefix number (which is either an issuer-defined value or a Token Vault defined value) that is at least six (6) digits in length and comprises the most significant digits of the Token Number")
Similar to the rejection of claim 4, although Johnson does not explicitly disclose an eight-digit number, Johnson indicates that the six-digit bank identification numbers may be preferred, and the reference does not exclude the possibility of using identification numbers with more digits, such as the claimed eight-digit number. A person of ordinary skill in the art would be able to adjust the number of digits from six to eight through routine optimization and further a person of ordinary skill in the art would have considered the change to eight digits as an obvious design choice, as changing the number of digits from six to eight represents a minor modification of a known structure, used for the same purpose.
wherein the account identifier is a six-digit number,
(Johnson US20160350746 at paras. 27-30) ("[0028] Next, the TSP sets 306 the least significant four (4) digits of the Token Number to match the last four (4) digits of the PAN. The TSP then determines 308 the middle digits or middle portion of the Token Number, which may consist of six (6) digits up to nine (9) digits. [0029] In particular, the middle digits if a Token Number are determined such that the completed or full Token Number (which may be up to nineteen (19) digits long) is unique (i.e, there is no other Token Number currently in circulation that is the same), and so that it satisfies a Checksum or check digit algorithm, such as the LUHN formula.")
wherein the trailing identifier is a four-digit number, and
(Johnson US20160350746 at paras. 27-30) ("[0028] Next, the TSP sets 306 the least significant four (4) digits of the Token Number to match the last four (4) digits of the PAN.")
Johnson, Fortney, Rausaria, Collinge, and Scipioni do not explicitly teach, however, Grassadonia does teach:
wherein the checksum value is a two-digit number.
(Grassadonia US20180005231 at paras. 51-53) ("[0052] The CCS server may also generate a set of digits for the random number portion of the card number using a random number generator algorithm and generate a set of one or more digits based on a Luhn check algorithm (or other checksum algorithm) dictated by the issuer processor or other entity. The CCS server may append the set of one or more Luhn check digits to the randomly generated set of digits.")
Similar to the rejection of claim 4, although Grassadonia does not explicitly disclose a two-digit number, Grassadonia indicates that the one-digit checksum numbers may be preferred, and the reference does not exclude the possibility of using checksum values with more digits, such as the claimed two-digit number. A person of ordinary skill in the art would be able to adjust the number of digits from one to two through routine optimization and further a person of ordinary skill in the art would have considered the change to two digits as an obvious design choice, as changing the number of digits from one to two represents a minor modification of a known structure, used for the same purpose.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, and Grassadonia to provide for “wherein the checksum value is a two-digit number”, because it allows for improved methods to protect consumers from fraud through improved, intelligent server behaviors. (Grassadonia at Abstract and paras. 2-13).
Johnson, Fortney, Rausaria, Collinge, Scipioni, and Grassadonia do not explicitly teach, however, Quentin does teach:
wherein the virtual card number is a twenty-digit number,
(Quentin US20180025343 at paras. 74-76) ("[0075] Each type of service pre-defined within a secure element is associated with a unique identifier (PAN_S) built in the same format as a bank card number (or PAN from “Primary Account Number”). Such a number comprises at least 16 digits: six first digits which constitute an issuer identification number (or IIN) followed by a variable number of digits (often 9 digits and up to 12 digits) identifying the card within the bank; and finally a last checksum digit. Each of these identifiers (PAN_S) is not only unique within a same secure element but also unique within all the commercially distributed secure elements.")
Similar to the rejection of claim 4, although Quentin does not explicitly disclose a twenty-digit number, Quentin indicates that the sixteen-digit numbers may be preferred, and the reference does not exclude the possibility of using numbers with more digits, such as the claimed twenty-digit number. A person of ordinary skill in the art would be able to adjust the number of digits from sixteen to twenty through routine optimization and further a person of ordinary skill in the art would have considered the change to twenty digits as an obvious design choice, as changing the number of digits from sixteen to twenty represents a minor modification of a known structure, used for the same purpose.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, Grassadonia, and Quentin to provide for “wherein the virtual card number is a twenty-digit number”, because it allows for improved online processing of transactions, and more particularly to the processing of transactions using a communications terminal in a secured form. (Quentin at Abstract and paras. 1-13).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Johnson, U.S. Patent Application Publication Number 2016/0350746; in view of Fortney, U.S. Patent Application Publication Number 2022/0188825; in view of Rausaria, U.S. Patent Application Publication Number 2016/0048913; in view of Collinge, U.S. Patent Application Publication Number 2023/0164122; in view of Scipioni, U.S. Patent Application Publication Number 2009/0132405; in view of Quentin, U.S. Patent Application Publication Number 2018/0025343; in view of Kurani, U.S. Patent Application Publication Number 2024/0354745.
As per claim 8,
Johnson explicitly teaches:
wherein the BIN is an eight-digit number,
(Johnson US20160350746 at paras. 27-30) ("[0028] Next, the TSP then begins the tokenization process by allocating 304 a token prefix number (which is either an issuer-defined value or a Token Vault defined value) that is at least six (6) digits in length and comprises the most significant digits of the Token Number.")
Similar to the rejection of claim 4, although Johnson does not explicitly disclose an eight-digit number, Johnson indicates that the six-digit bank identification numbers may be preferred, and the reference does not exclude the possibility of using numbers with more digits, such as the claimed eight-digit number. A person of ordinary skill in the art would be able to adjust the number of digits from six to eight through routine optimization and further a person of ordinary skill in the art would have considered the change to eight digits as an obvious design choice, as changing the number of digits from six to eight represents a minor modification of a known structure, used for the same purpose.
wherein the account identifier is a six-digit number,
(Johnson US20160350746 at paras. 27-30) ("[0028] Next, the TSP sets 306 the least significant four (4) digits of the Token Number to match the last four (4) digits of the PAN. The TSP then determines 308 the middle digits or middle portion of the Token Number, which may consist of six (6) digits up to nine (9) digits. [0029] In particular, the middle digits if a Token Number are determined such that the completed or full Token Number (which may be up to nineteen (19) digits long) is unique (i.e, there is no other Token Number currently in circulation that is the same), and so that it satisfies a Checksum or check digit algorithm, such as the LUHN formula.")
wherein the checksum value is a single-digit number.
(Johnson US20160350746 at paras. 16-18) ("[0017] In the example payment card shown in FIG. 1, the first six (6) digits 104 of the PAN typically identify the issuer financial institution (FI) of the payment card account (for example, an issuer bank). The next ten digits 106 of the PAN may be used to identify the cardholder's account, wherein the final digit 108 (which is six (“6”) in the example depicted in FIG. 1) is typically a check digit. In some implementations, the check digit may be calculated, for example, using the “LUHN” algorithm (also known as the “modulus 10” or “mod 10” algorithm), but it should be understood that other types of checksum algorithms can be used as well.")
Johnson, Fortney, Rausaria, Collinge, and Scipioni do not explicitly teach, however, Quentin does teach:
wherein the virtual card number is a twenty-digit number,
(Quentin US20180025343 at paras. 74-76) ("[0075] Each type of service pre-defined within a secure element is associated with a unique identifier (PAN_S) built in the same format as a bank card number (or PAN from “Primary Account Number”). Such a number comprises at least 16 digits: six first digits which constitute an issuer identification number (or IIN) followed by a variable number of digits (often 9 digits and up to 12 digits) identifying the card within the bank; and finally a last checksum digit. Each of these identifiers (PAN_S) is not only unique within a same secure element but also unique within all the commercially distributed secure elements.")
Similar to the rejection of claim 4, although Quentin does not explicitly disclose a twenty-digit number, Quentin indicates that the sixteen-digit numbers may be preferred, the reference does not exclude the possibility of using numbers with more digits, such as the claimed twenty-digit number. A person of ordinary skill in the art would be able to adjust the number of digits from sixteen to twenty through routine optimization and further a person of ordinary skill in the art would have considered the change to twenty digits as an obvious design choice, as changing the number of digits from sixteen to twenty represents a minor modification of a known structure, used for the same purpose.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Quentin to provide for “wherein the virtual card number is a twenty-digit number”, because it allows for improved online processing of transactions, and more particularly to the processing of transactions using a communications terminal in a secured form. (Quentin at Abstract and paras. 1-13).
Johnson, Fortney, Rausaria, Collinge, Scipioni, and Quentin do not explicitly teach, however, Kurani does teach:
wherein the trailing identifier is a five-digit number, and
(Kurani US20240354745 at paras. 3-5) ("[0004] One embodiment relates to a computer-implemented method performed by a mobile wallet computer system. The method comprises receiving, comprises receiving a fund access request from a user device. The fund access request is made in connection with a payment transaction. The method further comprises generating a tokenized card number. At least the last four digits of the tokenized card number match an actual credit card account number of the user.")
Similar to the rejection of claim 4, although Kurani does not explicitly disclose a five-digit number, Kurani indicates that the four-digit numbers may be preferred, the reference does not exclude the possibility of using numbers with more digits, such as the claimed five-digit number. A person of ordinary skill in the art would be able to adjust the number of digits from four to five through routine optimization and further a person of ordinary skill in the art would have considered the change to five digits as an obvious design choice, as changing the number of digits from four to five represents a minor modification of a known structure, used for the same purpose.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, Quentin, and Kurani to provide for “wherein the trailing identifier is a five-digit number”, because it allows for improved system for generating a tokenized card number and authenticating a payment transaction based on a match of the identification number transmitted to the user device and the identification number received from the card network computer system. (Kurani at Abstract and paras. 1-13).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Johnson, U.S. Patent Application Publication Number 2016/0350746; in view of Fortney, U.S. Patent Application Publication Number 2022/0188825; in view of Rausaria, U.S. Patent Application Publication Number 2016/0048913; in view of Collinge, U.S. Patent Application Publication Number 2023/0164122; in view of Scipioni, U.S. Patent Application Publication Number 2009/0132405; in view of Grassadonia, U.S. Patent Application Publication Number 2018/0005231; in view of Quentin, U.S. Patent Application Publication Number 2018/0025343; in view of Kurani, U.S. Patent Application Publication Number 2024/0354745.
As per claim 9,
Johnson explicitly teaches:
wherein the BIN is an eight-digit number,
(Johnson US20160350746 at paras. 27-30) ("[0028] Next, the TSP then begins the tokenization process by allocating 304 a token prefix number (which is either an issuer-defined value or a Token Vault defined value) that is at least six (6) digits in length and comprises the most significant digits of the Token Number.")
Similar to the rejection of claim 4, although Johnson does not explicitly disclose an eight-digit number, Johnson indicates that the six-digit bank identification numbers may be preferred, and the reference does not exclude the possibility of using numbers with more digits, such as the claimed eight-digit number. A person of ordinary skill in the art would be able to adjust the number of digits from six to eight through routine optimization and further a person of ordinary skill in the art would have considered the change to eight digits as an obvious design choice, as changing the number of digits from six to eight represents a minor modification of a known structure, used for the same purpose.
wherein the checksum value is a single-digit number.
(Johnson US20160350746 at paras. 16-18) ("[0017] In the example payment card shown in FIG. 1, the first six (6) digits 104 of the PAN typically identify the issuer financial institution (FI) of the payment card account (for example, an issuer bank). The next ten digits 106 of the PAN may be used to identify the cardholder's account, wherein the final digit 108 (which is six (“6”) in the example depicted in FIG. 1) is typically a check digit. In some implementations, the check digit may be calculated, for example, using the “LUHN” algorithm (also known as the “modulus 10” or “mod 10” algorithm), but it should be understood that other types of checksum algorithms can be used as well.")
Johnson, Fortney, Rausaria, Collinge, and Scipioni do not explicitly teach, however, Grassadonia does teach:
wherein the account identifier is a five-digit number,
(Grassadonia US20180005231 at paras. 51-53) ("[0052] In a next step 205, the CCS server may generate a payment card number and a token representing the payment card number. The CCS server may generate the payment card number by appending together several sets of digits, including a predetermined bank identification number (BIN) prefix, a set of randomly generated digits representing a randomly generated number generated according to a random number generator algorithm, and one or more checksum digits generated and applied according to a checksum algorithm that confirms the uniqueness and accuracy of the new payment card number as a whole. Generally, the BIN prefix is a set of digits, typically six digits, associated with a bank or card issuer. The issuer processor or other entity may provide the BIN prefix to the CCS server; the CCS server may store the BIN prefix digits and may be configured to apply the BIN prefix digits to new payment cards generated by the CCS server, in accordance with the issuer processor or other entity. The CCS server may also generate a set of digits for the random number portion of the card number using a random number generator algorithm and generate a set of one or more digits based on a Luhn check algorithm (or other checksum algorithm) dictated by the issuer processor or other entity. The CCS server may append the set of one or more Luhn check digits to the randomly generated set of digits.")
Similar to the rejection of claim 4, although Grassadonia does not explicitly disclose a five-digit number, Grassadonia indicates that the six-digit identifiers may be preferred, and the reference does not exclude the possibility of using identifiers with fewer digits, such as the claimed five-digit number. A person of ordinary skill in the art would be able to adjust the number of digits from six to five through routine optimization and further a person of ordinary skill in the art would have considered the change to five digits as an obvious design choice, as changing the number of digits from six to five represents a minor modification of a known structure, used for the same purpose.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, and Grassadonia to provide for “wherein the account identifier is a five-digit number”, because it allows for improved methods to protect consumers from fraud through improved, intelligent server behaviors. (Grassadonia at Abstract and paras. 2-13).
Johnson, Fortney, Rausaria, Collinge, Scipioni, and Grassadonia do not explicitly teach, however, Quentin does teach:
wherein the virtual card number is a twenty-digit number
(Quentin US20180025343 at paras. 74-76) ("[0075] Each type of service pre-defined within a secure element is associated with a unique identifier (PAN_S) built in the same format as a bank card number (or PAN from “Primary Account Number”). Such a number comprises at least 16 digits: six first digits which constitute an issuer identification number (or IIN) followed by a variable number of digits (often 9 digits and up to 12 digits) identifying the card within the bank; and finally a last checksum digit. Each of these identifiers (PAN_S) is not only unique within a same secure element but also unique within all the commercially distributed secure elements.")
Similar to the rejection of claim 4, although Quentin does not explicitly disclose a twenty-digit number, Quentin indicates that the sixteen-digit numbers may be preferred, the reference does not exclude the possibility of using numbers with more digits, such as the claimed twenty-digit number. A person of ordinary skill in the art would be able to adjust the number of digits from sixteen to twenty through routine optimization and further a person of ordinary skill in the art would have considered the change to twenty digits as an obvious design choice, as changing the number of digits from sixteen to twenty represents a minor modification of a known structure, used for the same purpose.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, Grassadonia, and Quentin to provide for “wherein the virtual card number is a twenty-digit number”, because it allows for improved online processing of transactions, and more particularly to the processing of transactions using a communications terminal in a secured form. (Quentin at Abstract and paras. 1-13).
Johnson, Fortney, Rausaria, Collinge, Scipioni, Grassadonia, and Quentin do not explicitly teach, however, Kurani does teach:
wherein the trailing identifier is a six-digit number, and
(Kurani US20240354745 at paras. 3-5) ("[0004] One embodiment relates to a computer-implemented method performed by a mobile wallet computer system. The method comprises receiving, comprises receiving a fund access request from a user device. The fund access request is made in connection with a payment transaction. The method further comprises generating a tokenized card number. At least the last four digits of the tokenized card number match an actual credit card account number of the user.")
Similar to the rejection of claim 4, although Kurani does not explicitly disclose a five-digit number, Kurani indicates that the four-digit numbers may be preferred, the reference does not exclude the possibility of using numbers with more digits, such as the claimed six-digit number. A person of ordinary skill in the art would be able to adjust the number of digits from four to six through routine optimization and further a person of ordinary skill in the art would have considered the change to six digits as an obvious design choice, as changing the number of digits from four to six represents a minor modification of a known structure, used for the same purpose.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, Grassadonia, Quentin, and Kurani to provide for “wherein the trailing identifier is a six-digit number”, because it allows for improved system for generating a tokenized card number and authenticating a payment transaction based on a match of the identification number transmitted to the user device and the identification number received from the card network computer system. (Kurani at Abstract and paras. 1-13).
Claims 10, 11, 13-15, 21, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Johnson, U.S. Patent Application Publication Number 2016/0350746; in view of Fortney, U.S. Patent Application Publication Number 2022/0188825; in view of Rausaria, U.S. Patent Application Publication Number 2016/0048913; in view of Collinge, U.S. Patent Application Publication Number 2023/0164122; in view of Scipioni, U.S. Patent Application Publication Number 2009/0132405; in view of Wilson, WIPO Patent Application Publication Number 2017/127868.
As per claim 10,
Johnson, Fortney, Rausaria, Collinge, and Scipioni do not explicitly teach, however, Wilson does teach:
wherein the card account further comprises a PAN card verification value (CVV), further comprising: generating, by the one or more processors, a virtual CVV based on the virtual card number; and linking, by the one or more processors, the virtual CVV and the PAN CVV with the virtual card.
(Wilson WO2017127868A1 at paras. 73-75) ("[0074] In other embodiments, the further data contained in an LDTDP may include a security code associated with the unique ID of the document, and may also include a number of other different security codes associated with one or more tokens also contained in the LDTDP. For example, where the digital transaction document is a credit card, the security codes may be Card Verification Value 2 (CVV2) security codes, or similar. In this example, the unique ID is a PAN, which has an associated CVV2 security code, and the PAN has, perhaps, five associated tokens, each token also having an associated [CVV2].")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, and Wilson to provide for “wherein the card account further comprises a PAN card verification value (CVV), further comprising: generating, by the one or more processors, a virtual CVV based on the virtual card number; and linking, by the one or more processors, the virtual CVV and the PAN CVV with the virtual card”, because it allows for improved methods to use tokens for security for an associated digital transaction document (and its containing LDTDP), and for the transactions. (Wilson at Abstract and paras. 130, 157, 161, 231, 242).
As per claim 11,
Johnson, Fortney, Rausaria, Collinge, and Scipioni do not explicitly teach, however, Wilson does teach:
further comprising: verifying, by the one or more processors, an authenticity of a subsequent transaction that uses the virtual card by performing a security verification algorithm against the virtual card number and matching the output of the security verification algorithm to either of the virtual CVV and the PAN CVV.
(Wilson WO2017127868A1 at paras. 159-161) ("[0160] In some embodiments, the tokens are generated only by a third party provider who issues the tokens to users (optionally already contained in respective LDTDPs). The tokens may also be issued by another third party provider in other embodiments. Alternatively, in an embodiment, the tokens may be generated locally by the user, for example, by the DAD and stored into the LDTDP storage memory contained in LDTDPs. The locally generated tokens could be securely copied to a third party to be matched during a transaction to thereby authorize the transaction. A cryptogram may be created containing a token, along with one or more of the associated document's unique ID, expiry date, unique ID of the DAD, time, date, location, and various other random, pseudo-random or non-random inputs. A cryptogram may also be created using, for example, a public key from the DTC, a public key from the LDTDP (for example, if it is a credit card LDTDP), and/or a public key from the digital transaction device (for example, a POS/EFTPOS terminal). The cryptogram may also be created using public keys from other sources. A cryptogram created using one or more public keys will contain the one or more tokens, and other IDs and data.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, and Wilson to provide for “further comprising: verifying, the one or more processors, an authenticity of a subsequent transaction that uses the virtual card by performing a security verification algorithm against the virtual card number and matching the output of the security verification algorithm to either of the virtual CVV and the PAN CVV”, because it allows for improved methods to use tokens for security for an associated digital transaction document (and its containing LDTDP), and for the transactions. (Wilson at Abstract and paras. 130, 157, 161, 231, 242).
As per claim 13,
Johnson, Fortney, Rausaria, Collinge, and Scipioni do not explicitly teach, however, Wilson does teach:
further comprising: receiving, by the one or more processors, a control from a user that specifies a limitation on transactions performed at the merchant using the virtual card; and associating, by the one more processors, the control with the virtual card.
(Wilson WO2017127868A1 at paras. 146-148) ("[0147] In yet other embodiments, the DAD may include an e-wallet, which can be configured to operate with one or more of the LDTDPs containing logical digital transaction documents and associated token(s) stored on the DAD. This arrangement can be used to top up funds where the associated digital transaction document is a debit card or a credit card. Further, the DAD may include functionality to allow a user to view transactions that are completed with the DTC (or by other means, such as online transactions) in real time. This may allow the user to monitor all transactions made by all LDTDPs associated with digital transaction documents in the apparatus (which may include a plurality of DTCs linked or linkable with the DAD) in, a single screen or with a single smartphone application. Further, the user could be shown the associated digital token that was used for a transaction. This may further allow the user to cancel, stop, pause or otherwise appropriately deal with one or more digital transaction documents if the user detects or perceives that one or more digital transaction documents have been misused or fraudulently used. The apparatus could also be adapted to allow the user to cancel, stop, pause or otherwise appropriately deal with one or more digital transaction documents on a token-by-token basis, so that only certain tokens associated with a document are disabled, but the document is still useable with other associated tokens. The user could also cancel, stop, pause or otherwise appropriately deal with one or more logical digital transaction documents if the user seeks to limit, for example, spending, or other financial or non-financial transactions occurring with one or more logical digital transaction documents. This may also be performed on a token-by-token basis.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, and Wilson to provide for “further comprising: receiving, by the one or more processors, a control from a user that specifies a limitation on transactions performed at the merchant using the virtual card; and associating, by the one more processors, the control with the virtual card”, because it allows for improved methods to use tokens for security for an associated digital transaction document (and its containing LDTDP), and for the transactions. (Wilson at Abstract and paras. 130, 157, 161, 231, 242).
As per claim 14,
Johnson, Fortney, Rausaria, Collinge, and Scipioni do not explicitly teach, however, Wilson does teach:
the linking further comprising: retrieving, by the one or more processors, a first expiration date associated with the card account; and setting, by the one or more processors, a second expiration date associated with the virtual card to the retrieved first expiration date.
(Wilson WO2017127868A1 at paras. 71-74) ("[0072] In some embodiments, an LDTDP may also contain further data associated with a digital transaction document, such as an expiry date for the document. It may also be desirable in some circumstances to have multiple expiry dates in an LDTDP, for example, one expiry date for the unique ID (or for the associated digital transaction document) and another expiry date for a token associated with the unique ID. It will be understood that, where a digital transaction document has a number of associated tokens, each token may have a different expiry date, which will be contained in the respective LDTDP. [0073] Further, the LDTDP for some digital transaction documents may include a commencement date, so that the period between commencement of validity and expiry of validity of the document (and/or one or more tokens associated therewith) can be controlled. For example, it may be desirable to have the digital transaction document valid for only one day if the document is a door pass, or some other card or pass, with a short validity requirement. Moreover, the commencement and expiry in the LDTDP could include times as well as dates for finer control of the validity period of the digital transaction document (and/or one or more tokens associated therewith).")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, and Wilson to provide for “the linking further comprising: retrieving, by the one or more processors, a first expiration date associated with the card account; and setting, by the one or more processors, a second expiration date associated with the virtual card to the retrieved first expiration date”, because it allows for improved methods to use tokens for security for an associated digital transaction document (and its containing LDTDP), and for the transactions. (Wilson at Abstract and paras. 130, 157, 161, 231, 242).
As per claim 15,
Johnson, Fortney, Rausaria, Collinge, and Scipioni do not explicitly teach, however, Wilson does teach:
the linking further comprising: setting, by the one or more processors, an expiration date associated with the virtual card to a distant date.
(Wilson WO2017127868A1 at paras. 71-74) ("[0072] In some embodiments, an LDTDP may also contain further data associated with a digital transaction document, such as an expiry date for the document. It may also be desirable in some circumstances to have multiple expiry dates in an LDTDP, for example, one expiry date for the unique ID (or for the associated digital transaction document) and another expiry date for a token associated with the unique ID. It will be understood that, where a digital transaction document has a number of associated tokens, each token may have a different expiry date, which will be contained in the respective LDTDP. [0073] Further, the LDTDP for some digital transaction documents may include a commencement date, so that the period between commencement of validity and expiry of validity of the document (and/or one or more tokens associated therewith) can be controlled. For example, it may be desirable to have the digital transaction document valid for only one day if the document is a door pass, or some other card or pass, with a short validity requirement. Moreover, the commencement and expiry in the LDTDP could include times as well as dates for finer control of the validity period of the digital transaction document (and/or one or more tokens associated therewith).")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, and Wilson to provide for “the linking further comprising: setting, by the one or more processors, an expiration date associated with the virtual card to a distant date”, because it allows for improved methods to use tokens for security for an associated digital transaction document (and its containing LDTDP), and for the transactions. (Wilson at Abstract and paras. 130, 157, 161, 231, 242).
As per claim 21,
Johnson, Fortney, Rausaria, Collinge, and Scipioni do not explicitly teach, however, Wilson does teach:
the at least one processor further configured to: generate a virtual CVV based on the virtual card number; and link the virtual CVV and the PAN CVV with the virtual card.
(Wilson WO2017127868A1 at paras. 73-75) ("[0074] In other embodiments, the further data contained in an LDTDP may include a security code associated with the unique ID of the document, and may also include a number of other different security codes associated with one or more tokens also contained in the LDTDP. For example, where the digital transaction document is a credit card, the security codes may be Card Verification Value 2 (CVV2) security codes, or similar. In this example, the unique ID is a PAN, which has an associated CVV2 security code, and the PAN has, perhaps, five associated tokens, each token also having an associated [CVV2].")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Johnson, Fortney, Rausaria, Collinge, Scipioni, and Wilson to provide for “the linking further comprising: setting, by the one or more processors, an expiration date associated with the virtual card to a distant date”, because it allows for improved methods to use tokens for security for an associated digital transaction document (and its containing LDTDP), and for the transactions. (Wilson at Abstract and paras. 130, 157, 161, 231, 242).
Claim 23 is substantially similar to claim 21, thus, it is rejected on similar grounds.
Response to Arguments
Applicant’s arguments filed on October 2, 2025 have been fully considered but are not persuasive for the following reasons:
With respect to Applicant’s arguments as to the § 101 rejections for now pending claims 1, 4-15, 17, and 20-24, Examiner notes the following:
Applicant argues that the claims integrate the abstract idea into a practical application, the examiner respectfully disagrees. In particular, the applicant argues that “The Specification describes a technical problem pertaining to cryptographic algorithms implemented by online merchants, online payment services, and financial institutions” and “In view of these technical problems, claim 1 recites a technical solution for transactional cryptography that consolidates disparate e-commerce computing systems to a single computing system with improved cryptographic functionalities.”
Examiner notes that, unlike in Example 35, the stated problems of inefficiencies and inadequacies of conventional transactional cryptographic systems is not a technical problem, and the claimed solution is not a technical solution. In the claim, the solution of enhancing how VCNs are generated and communicated to a user is part of the abstract idea, as it is merely involves data manipulation and analysis to facilitate management of financial information. Furthermore, the data manipulation and analysis could be completed mentally or manually by paper or pen.
Finally, the Applicant argues that the claims are directed to significantly more than the abstract idea.
Examiner disagrees, however, and notes that, as explained above in the instant rejection under 35 U.S.C. § 101, that the additional elements do not amount to an inventive concept. The additional elements of the computer system - a “one or more processors”, are merely generic computer components performing their well-known basic functions of collecting, analyzing, and transmitting data to facilitate management of financial information. Per the specification, the recited computer elements and machine learning steps and model are described only at a high level of generality, (see Spec. at paras. [0117]–[0120]). In view of the specification, the application of the computer elements and machine learning is merely being applied to the abstract idea.
The other limitations which are simply supporting the abstract idea correspond to insignificant extra-solution activity which do not transform the abstract idea into a patent eligible subject matter. Also, the functionality here is already present in the recited hardware, which is merely routine and conventional. Collecting, analyzing, and transmitting data is routine and conventional. There is no technological problem or solution identified. This is merely a business solution to transfer data between devices. (MPEP 2106.05 (f))
Furthermore, unlike DDR Holdings, the instant claims do not solve a problem rooted in computer technology. The claims do not solve a problem with a solution “that specifically arises in the realm of the near-instantaneous online cryptography systems that exist only in computer networks”, rather, the claims recite utilizing generic computer components -- “one or more processors” to perform collecting, analyzing, and transmitting data to facilitate management of financial information in a computer environment. Such automation of a commercial payment practice using routine computer functions does not constitute a technological improvement and therefore is not directed to patent-eligible subject matter.
With respect to Applicant’s arguments as to the § 103 rejections for now pending claims 1, 4-15, 17, and 20-24, Examiner notes that the arguments are moot in light of the new grounds for rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is available for review on Form PTO-892 Notice of References Cited.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MERRITT J HASBROUCK whose telephone number is (571)272-3109. The examiner can normally be reached M-F 9:00-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christine Tran can be reached on 571-272-8103. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MERRITT J HASBROUCK/Examiner, Art Unit 3695
/HAO FU/Primary Examiner, Art Unit 3695