DETAILED ACTION
This is an office action on the merits in response to the communication filed on 5/28/2024.
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 .
Claims’ Status
Claim 1 is canceled. Claims 2-21 are pending and are considered in this office action.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim 2 of the instant application is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 and 3 of Patent No. US12020240B2 (Rule-based token service provider). Although the claims at issue are not identical, they are patentably distinct from each other because claim 3 of the Patent No. US12020240B2 teaches the claim limitations of claim 2. Thus it would have been obvious to one of ordinary skill in the art to combine claim 3 with the independent claim 1 of the Patent No. US12020240B2 to result in claim 2 of the instant application.
Claim 2 of the Instant application
Claim 1 and 3 of Patent No. US12020240B2
receive a token request from a device;
Claim 1: receiving a token request associated with a transaction request,
determine data associated with the token request;
determining context data associated with the transaction request;
determine, from a plurality of token providers, a token provider for the token request based on the data,
determining, from the plurality of token providers, a second token provider for the transaction request based on the context data;
wherein the determined token provider is not specified in the token request;
wherein the token request either fails to identify a token provider or identifies a first token provider from a plurality of token providers;
select, from a plurality of cryptogram protocols, a particular cryptogram protocol for generating a token for the token request based on at least one of the data or the token provider;
selecting, from a plurality of authentication protocols, a particular authentication protocol that comprises a cryptogram protocol for the token request based on at least one of the context data or the second token provider;
generate the token based on the particular cryptogram protocol; and
generating a token based on the particular authentication protocol and a token rule associated with the token request; and
processing the transaction request based on the token, wherein the token is validated without validating any token provider identified in the token request.
transmit the token to the device.
Claim 3: wherein the processing of the transaction request includes transmitting the token to the second token provider.
??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 2-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture or composition of matter? MPEP 2106.03
Per Step 1, Claims 2-8 are drawn to system claims; claims 9-15 are drawn to method claims; claims 16-21 are drawn to a non-transitory computer readable medium which are all within the four statutory categories (i.e., a process).
Independent claim 2 recites: (claims 9 and 16 being similar in scope):
Claim 2:
receive a token request from a device;
determine data associated with the token request;
determine, from a plurality of token providers, a token provider for the token request based on the data, wherein the determined token provider is not specified in the token request;
select, from a plurality of cryptogram protocols, a particular cryptogram protocol for generating a token for the token request based on at least one of the data or the token provider;
generate the token based on the particular cryptogram protocol; and
transmit the token to the device.
Step 2A Prong 1: Does the claim recite an abstract idea, law of nature, or natural phenomenon? MPEP 2106.04
The limitations, as drafted, constitute a process that, under its broadest reasonable interpretation, covers commercial interaction by including agreements in the form of contracts under the Certain methods of organizing human activity, but for the recitation of generic computer components. The abstract idea, recited above, includes: receive a token request from a device; determine data associated with the token request; determine, from a plurality of token providers, a token provider for the token request based on the data, wherein the determined token provider is not specified in the token request; select, from a plurality of cryptogram protocols, a particular cryptogram protocol for generating a token for the token request based on at least one of the data or the token provider; and transmit the token to the device. If a claim limitation, under its broadest reasonable interpretation, covers performance of limitations commercial interactions by including agreements in the form of contracts, but for the recitation of generic computer components, it falls within the Certain methods of organizing human activity, grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong 2: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP 2106.04.
The recited computing elements (claim 2: a non-transitory memory and one or more hardware processors) are recited at a high-level of generality, i.e. as generic computing element performing generic computer functions such that it amounts to no more than mere instructions to apply the exception using generic computer components (see MPEP 2106.05(f)). Simply adding a general purpose computer or computer components after the fact to an abstract idea does not integrate a judicial exception into a practical application or provide significantly more, since it amounts to no more than a recitation of the words "apply it" (or an equivalent) to implement an abstract idea or other exception on a computer, as set forth in MPEP 2106.05(f).
The other additional positive element(s): “generate the token based on the particular cryptogram protocol” in claim 2, which amounts to linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h) or simply “applying it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f)
Accordingly, these additional claim elements, alone and in combination do not integrate the abstract idea into a practical application, because (1) they do not effect improvements to the functioning of a computer, or to any other technology or technical field (see MPEP 2106.05(a)); (2) they do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or a medical condition (see the Vanda memo); (3) they do not apply the abstract idea with, or by use of, a particular machine (see MPEP 2106.05(b)); (4) they do not effect a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05(c)); (5) they do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the identified abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designated to monopolize the exception (see MPEP 2106.05(e) and the Vanda memo). Therefore, per Step 2A, Prong Two, the claim is directed to an abstract idea not integrated into a practical application.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP 2106.05.
Step 2B of the eligibility analysis concludes that the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. Examiner carries over the analysis from Step 2A related to the generic computing elements being no more than a recitation of the words "apply it" (or an equivalent) to implement an abstract idea or other exception on a computer (MPEP 2106.05(f)). The additional claim elements are simply linking the use of the judicial exception to a particular technological environment or field of use” are mere instructions to implement an abstract idea on a computer, are carried over for further analysis in Step 2B.
When the independent claims are considered as a whole, as a combination, the claim elements noted above do not amount to any more than they amount to individually. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified as an abstract idea. Therefore, it is concluded that the elements of the independent claims are directed to one or more abstract ideas and do not amount to significantly more. (MPEP 2106.05)
Further, Step 2B of the analysis takes into consideration all dependent claims as well, both individually and as a whole, as a combination:
Claims 2-8 are further directed to additional abstract ideas because the steps performed are simply narrowing the scope of the abstract idea of claim 2 since their individual and combined significance is still not significantly more than the abstract concept at the core of the claimed invention. For example, claim 3 further describes determining a risk profile for the particular cryptogram; claim 4 describes determining a particular cryptogram based on the device location; claim 5 on determining the bandwidth of the token provider; claim 6 on detecting the device location; claim 7 on detecting the device accessing a merchant’s website; claim 8 on pre-validating the token if the device is approaching a boundary of an area; etc; which all of the limitation are narrowing the steps performed in claim 2. Moreover, the claims in the instant application do not constitute significantly more also because the claims or claim elements only serve to implement the abstract idea using computer components to perform computing functions (Enfish, see MPEP 2106.05(a)). The other dependent claims, claims 10-15 and 17-21 are similar in scope to the claim 3-8 are also rejected for the same reasons provided above.
The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified in the independent claims as an abstract idea. The fact that the associated computing devices are facilitating the abstract concept is not enough to confer statutory subject matter eligibility. In sum, the additional elements do not serve to confer subject matter eligibility to the invention since their individual and combined significance is still not heavier than the abstract concepts at the core of the claimed invention. Therefore, it is concluded that the dependent claims of the instant application do not amount to significantly more either. (see MPEP 2106.05)
In sum, claims 2-21 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 2, 7, 9, 11-13, 16, and 19 are rejected under 35 U.S.C 103 as obvious over in view of Kumnick (US20150112871A1) in view of Patel et al. (US20190228410A1), and further in view of D'AGOSTINO et al. (US20190238517A1).
With respect to claim 2 and 16
Kumnick teaches the limitation:
a non-transitory memory storing instructions; and
one or more hardware processors coupled to the non-transitory memory and configured to execute the instructions from the non-transitory memory to cause the system to (see [0012]):
receive a token request from a device ([0056], In some embodiments, though, the token is generated “on-the-fly” (or, on demand for a particular transaction or transactions) by the payment device 103 (e.g., when receiving, by a receiver of a processing server, transaction data for a proposed payment transaction generation logic).);
determine data associated with the token request ([0057], An authorization request message may also include other transaction information, such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction.);
determine, from a plurality of token providers, a token provider for the token request based on the data ([0008], The method also includes selecting, by the computing device, a first of the plurality of payment processing networks to process the transaction based at least in part upon the transaction information. The method further includes transmitting the transaction information to the selected first payment processing network.), wherein the determined token provider is not specified in the token request ([0008], According to an embodiment, a method is described that includes receiving, at a computing device, a first transaction information for a first transaction. The first transaction information includes a first token value associated with a first account serving as a payment account for the first transaction. The first token value includes a token bank identification number (BIN). The first transaction information does not include any primary account number (PAN) value of the first account.);
Kumnick doesn’t explicitly disclose, but Patel teaches:
select, from a plurality of cryptogram protocols, a particular cryptogram protocol for generating a token for the token request based on at least one of the data or the token provider ([0025], The payment cryptogram may be used only for the associated types of payment transactions, where only the appropriate payment cryptogram may be supplied to a merchant system 110 based on the satisfaction of the proposed payment transaction to the applicable criteria. Such criteria may include, for example, merchant category code, geographic location, transaction time, transaction date, day of the week, month, product category, transaction amount, merchant identity, product identity, etc., or a combination thereof. For instance, a transaction account may have a first payment cryptogram applicable for all electronics merchants, a second payment cryptogram applicable for all merchants in a specific geographic area, and a third payment cryptogram applicable for all other transactions. In some cases, multiple payment cryptograms may be applicable for a payment transaction.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Kumnick with the teaching of Patel as they relate to a system/method of multiple payment processing networks using token. One of ordinary skill in the art before the effective filing date of the claimed invention was made would have modified the system of using multiple payment processing networks to process the transaction in Kumnick to include a method of selecting a particular cryptogram protocol as taught in Patel for the predicated result of efficiently and effectively determining which network should be used for processing a particular transaction.
Kumnick in view of Patel don’t explicitly disclose, but D'AGOSTINO teaches:
generate the token based on the particular cryptogram protocol; and transmit the token to the device ([0059], Authentication cryptogram 232 may also include a tokenized representation of selected portions of cryptogram request 212 and/or customer data records 230. For example, and based on a corresponding tokenization scheme (e.g., as maintained within cryptographic data 126 of FIG. 1), cryptogram generation module 228 may generate authentication cryptogram 232 by replacing sensitive or personal information within the selected portion of input data with corresponding information having no exploitable or extrinsic meaning, e.g., a digital token; see also [0052], In some examples, cryptogram request 212 may include information that instructs merchant system 122 to perform any of the exemplary processes described herein to generate an authentication cryptogram indicative of the successful local authentication of user 101's identity by executed merchant application 106A, and to distribute the authentication cryptogram to client device 102 and to one or more additional computing devices or systems operating within environment system 130, such as call center system 140.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kumnick/Patel with the teaching of D'AGOSTINO as they relate to a system/method of multiple payment processing networks using token. One of ordinary skill in the art before the effective filing date of the claimed invention was made would have modified the combined systems of Kumnick/Patel, for example using multiple payment processing networks to process the transaction in Kumnick, to include a method of generating a token based on a cryptogram as taught in D'AGOSTINO for the predicated result of efficiently and effectively determining which network should be used for processing a particular transaction.
With respect to claim 9
Kumnick teaches the limitation:
detecting, by a computer system, a token generation condition associated with a device for conducting a transaction; determining, by the computer system, a context associated with the device ([0057], An authorization request message may also include other transaction information, such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction. The authorization request message may also include other information such as an identifier of the access device 102 that generated the authorization request message, information about the location of the access device 102, etc.);
determining, by the computer system and from a plurality of token providers, a token provider for the transaction based on the context ([0008], The method also includes selecting, by the computing device, a first of the plurality of payment processing networks to process the transaction based at least in part upon the transaction information. The method further includes transmitting the transaction information to the selected first payment processing network.);
Kumnick doesn’t explicitly disclose, but Patel teaches:
selecting, by the computer system and from a plurality of cryptogram protocols, a particular cryptogram protocol for generating a token usable in the transaction based on at least one of the context or the token provider ([0025], The payment cryptogram may be used only for the associated types of payment transactions, where only the appropriate payment cryptogram may be supplied to a merchant system 110 based on the satisfaction of the proposed payment transaction to the applicable criteria. Such criteria may include, for example, merchant category code, geographic location, transaction time, transaction date, day of the week, month, product category, transaction amount, merchant identity, product identity, etc., or a combination thereof. For instance, a transaction account may have a first payment cryptogram applicable for all electronics merchants, a second payment cryptogram applicable for all merchants in a specific geographic area, and a third payment cryptogram applicable for all other transactions. In some cases, multiple payment cryptograms may be applicable for a payment transaction.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Kumnick with the teaching of Patel as they relate to a system/method of multiple payment processing networks using token. One of ordinary skill in the art before the effective filing date of the claimed invention was made would have modified the system of using multiple payment processing networks to process the transaction in Kumnick to include a method of selecting a particular cryptogram protocol as taught in Patel for the predicated result of efficiently and effectively determining which network should be used for processing a particular transaction.
Kumnick in view of Patel don’t explicitly disclose, but D'AGOSTINO teaches:
generating, by the computer system, the token based on the particular cryptogram protocol; and
processing, by the computer system, the transaction using the token ([0059], Authentication cryptogram 232 may also include a tokenized representation of selected portions of cryptogram request 212 and/or customer data records 230. For example, and based on a corresponding tokenization scheme (e.g., as maintained within cryptographic data 126 of FIG. 1), cryptogram generation module 228 may generate authentication cryptogram 232 by replacing sensitive or personal information within the selected portion of input data with corresponding information having no exploitable or extrinsic meaning, e.g., a digital token; see also [0052], In some examples, cryptogram request 212 may include information that instructs merchant system 122 to perform any of the exemplary processes described herein to generate an authentication cryptogram indicative of the successful local authentication of user 101's identity by executed merchant application 106A, and to distribute the authentication cryptogram to client device 102 and to one or more additional computing devices or systems operating within environment system 130, such as call center system 140.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kumnick/Patel with the teaching of D'AGOSTINO as they relate to a system/method of multiple payment processing networks using token. One of ordinary skill in the art before the effective filing date of the claimed invention was made would have modified the combined systems of Kumnick/Patel, for example using multiple payment processing networks to process the transaction in Kumnick, to include a method of generating a token based on a cryptogram as taught in D'AGOSTINO for the predicated result of efficiently and effectively determining which network should be used for processing a particular transaction.
With respect to claim 7 and 19
The combination of Kumnick, Patel, and D'AGOSTINO teaches the limitation of clam 2 and 16 respectively. Kumnick further teaches: wherein the token request is received based on a detection of the device accessing a website of a merchant ([0052], For example, a user device 112 may include, but is not limited to, a cellular phone, laptop, tablet, wearable computing device, etc., and may interact with an access device 102 (e.g., using NFC) and/or merchant computer 104 (e.g., via the Internet to access a website or utilize an application provided by merchant computer 104) to initiate and/or conduct a financial transaction.)
With respect to claim 11
The combination of Kumnick, Patel, and D'AGOSTINO teaches the limitation of clam 9. Kumnick further teaches: wherein the token generation condition is associated with a website accessed by the device ([0052], For example, a user device 112 may include, but is not limited to, a cellular phone, laptop, tablet, wearable computing device, etc., and may interact with an access device 102 (e.g., using NFC) and/or merchant computer 104 (e.g., via the Internet to access a website or utilize an application provided by merchant computer 104) to initiate and/or conduct a financial transaction.)
With respect to claim 12
The combination of v teaches the limitation of clam 9. Patel further teaches: validating the token with the token provider, wherein the transaction is processed based on the validating the token ([0033], The transaction message may be provided to the issuing institution 104, which may determine approval or denial of the payment transaction using traditional methods, such as basing approval on the amount of the payment transaction and available credit in the applicable transaction account. Approval or denial may be further based on validation of the payment cryptograms, which may be unrelated to the contextual rules and may be performed using traditional cryptogram validation processes. For instance, the issuing institution 104 may generate its own versions of the applicable payment cryptogram(s), which may be compared to the payment cryptograms included in the transaction message (e.g., as provided by the payment instrument) for validation thereof. The approval or denial of the payment transaction may be returned to the payment network 112 in the same or a different transaction message, which may be an authorization response.)
With respect to claim 13
The combination of Kumnick, Patel, and D'AGOSTINO teaches the limitation of clam 9. Kumnick further teaches: transmitting the token to the device, wherein the transaction is processed in response to receiving the token from the device ([0082], In some embodiments, the access device 102 generates the token (at block 306). For example, the user device 112 may present a PAN (at arrow 350) to the access device 102, which may be configured to, possibly based upon that PAN, generate a token for the transaction, and pass the token (at arrow 352) to the merchant computer 104 for payment processing (along with transaction data).)
Claims 3-5, 10, 14, and 21 are rejected under 35 U.S.C 103 as obvious over in view of Kumnick (US20150112871A1) in view of Patel et al. (US20190228410A1) in view of D'AGOSTINO et al. (US20190238517A1), and further in view of Kinagi (US20180006821A1).
With respect to claim 3 and 14
The combination of Kumnick, Patel, and D'AGOSTINO teaches the limitation of clam 2 and 9 respectively. Patel further teaches: wherein the token request is associated with a transaction conducted between a first entity and a second entity (see [0037].)
The combination does not explicitly disclose, but Kinagi teaches:
wherein executing the instructions further causes the system to:
determine a risk profile associated with at least one of the first entity or the second entity based on the data, wherein the particular cryptogram protocol is selected further based on the risk profile ([0018], The issuer computer or the transaction processing computer may then determine a risk level for the transaction by (i) matching the transaction data in the cryptogram and the authorization request message, (ii) ensuring that the device is in a reasonable proximity to the merchant terminal (e.g., POS terminal), and/or (iii) determining whether a recent transaction count associated with the device is reasonable.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kumnick/Patel/ D'AGOSTINO with the teaching of Kinagi as they relate to a system/method of multiple payment processing networks using token. One of ordinary skill in the art before the effective filing date of the claimed invention was made would have modified the combined systems of Kumnick/Patel/D'AGOSTINO, for example using multiple payment processing networks to process the transaction in Kumnick, to include a method of selecing cryptogram protocol based on the risk profile as taught in Kinagi for the predicated result of efficiently and effectively determining which network should be used for processing a particular transaction.
With respect to claim 4, 15, and 21
The combination of Kumnick, Patel, and D'AGOSTINO teaches the limitation of clam 2, 9, and 16 respectively. The combination does not explicitly disclose, but Kinagi teaches: wherein the data represents a location of the device, and wherein the particular cryptogram protocol is selected further based on the location ([0079], The token cryptogram may include the following information: a user's (e.g., device's) GPS location information, a number of purchases in a past time frame (specified by the issuer), a merchant ID, a GPS location of the merchant terminal, transaction initiation timestamp, a transaction amount, token request timestamp, and a mode of QR code scan initiation (e.g., voice initiated, manual screen unlock, manual head mounted display initiation, etc.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kumnick/Patel/ D'AGOSTINO with the teaching of Kinagi as they relate to a system/method of multiple payment processing networks using token. One of ordinary skill in the art before the effective filing date of the claimed invention was made would have modified the combined systems of Kumnick/Patel/D'AGOSTINO, for example using multiple payment processing networks to process the transaction in Kumnick, to include a method of selecting cryptogram based on the location as taught in Kinagi for the predicated result of efficiently and effectively determining which network should be used for processing a particular transaction.
With respect to claim 10
The combination of Kumnick, Patel, and D'AGOSTINO teaches the limitation of clam 9. The combination does not explicitly disclose, but Kinagi teaches: wherein the token generation condition is associated with a location of the device ([0079], The token cryptogram may include the following information: a user's (e.g., device's) GPS location information, a number of purchases in a past time frame (specified by the issuer), a merchant ID, a GPS location of the merchant terminal, transaction initiation timestamp, a transaction amount, token request timestamp, and a mode of QR code scan initiation (e.g., voice initiated, manual screen unlock, manual head mounted display initiation, etc.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kumnick/Patel/ D'AGOSTINO with the teaching of Kinagi as they relate to a system/method of multiple payment processing networks using token. One of ordinary skill in the art before the effective filing date of the claimed invention was made would have modified the combined systems of Kumnick/Patel/D'AGOSTINO, for example using multiple payment processing networks to process the transaction in Kumnick, to include a method of determining the token generation condition based on a location of the device as taught in Kinagi for the predicated result of efficiently and effectively determining which network should be used for processing a particular transaction.
Claims 5 and 17 are rejected under 35 U.S.C 103 as obvious over in view of Kumnick (US20150112871A1) in view of Patel et al. (US20190228410A1) in view of D'AGOSTINO et al. (US20190238517A1), and further in view of Bernstein et al. (US20040221032A1).
With respect to claim 5 and 17
The combination of Kumnick, Patel, and D'AGOSTINO teaches the limitation of clam 2 and 16 respectively. The combination doesn’t explicitly disclose, but Bernstein teaches: wherein the token provider is a first token provider, and wherein executing the instructions further causes the system to:
monitor a plurality of payment networks corresponding to the plurality of token providers ([0032], Some embodiments of the invention include an apparatus for controlling bandwidth utilization of a cable network subscriber. The apparatus is configured to do the following: monitor the cable network subscriber's upstream transmissions during a predetermined time period..); and
determine that a first payment network in the plurality of payment networks and corresponding to the first token provider has a higher network bandwidth than a second payment network in the plurality of payment networks, wherein the first token provider is determined for the token request further based on the first payment network having a higher network bandwidth than the second payment network ([0026], Another method of controlling bandwidth utilization of a network subscriber is provided by the invention. This method includes the following steps: regulating bursty traffic by using a first token bucket having a first capacity B1 for first tokens, each first token authorizing the network subscriber to transmit a first unit of data; and controlling the first token bucket by using a second token bucket having a second capacity B2 for second tokens, each second token authorizing the network subscriber to transmit a second unit of data, the second unit of data being at least 100 times greater than the first unit of data.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kumnick/Patel/ D'AGOSTINO with the teaching of Bernstein as they relate to a system/method of multiple payment processing networks using token. One of ordinary skill in the art before the effective filing date of the claimed invention was made would have modified the combined systems of Kumnick/Patel/D'AGOSTINO, for example using multiple payment processing networks to process the transaction in Kumnick, to include a method of determining payment network bandwidth of payment networks as taught in Bernstein for the predicated result of efficiently and effectively determining which network should be used for processing a particular transaction.
Claims 6 and 18 are rejected under 35 U.S.C 103 as obvious over in view of Kumnick (US20150112871A1) in view of Patel et al. (US20190228410A1) in view of D'AGOSTINO et al. (US20190238517A1), and further in view of Musil et al. (US20220122061A1).
With respect to claim 6 and 18
The combination of Kumnick, Patel, and D'AGOSTINO teaches the limitation of clam 2 and 16 respectively. The combination doesn’t explicitly disclose, but Musil teaches: wherein the token request is received based on a detection of the device located within a geo-fence ([0021], In generating the token, the token provider 116 a, for example, may assign a transactable account number of similar characteristics to that of the PAN for the payment account. Other payment credentials may further be generated and associated with the token, as required for interoperability at a physical point of sale (POS) location or virtual location, and may be loaded to a device (e.g., the communication device 114, etc.) in addition to the token; see also [0042], …..a validation of an incoming cryptogram associated with the token assigned by the token provider (e.g., one of token providers 116 a-b, etc.).)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kumnick/Patel/ D'AGOSTINO with the teaching of Musil as they relate to a system/method of multiple payment processing networks using token. One of ordinary skill in the art before the effective filing date of the claimed invention was made would have modified the combined systems of Kumnick/Patel/D'AGOSTINO, for example using multiple payment processing networks to process the transaction in Kumnick, to include a method of detecting the device location within a geo-fence as taught in Musil for the predicated result of efficiently and effectively determining which network should be used for processing a particular transaction.
Allowable Subject Matter
The following is a statement of reasons for the indication of allowable subject matter. Claim 8 and 20 each contains allowable subject matter: wherein executing the instructions further causes the system to:
detect that the device is approaching a boundary of an area; and cause the device to pre-validate the token using a cryptogram technique, wherein pre-validating the token enables the token to be usable outside of the area.
Conclusion
THIS ACTION IS MADE Non-FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YIN Y CHOI whose telephone number is (571)272-1094 or yin.choi@uspto.gov. The examiner can normally be reached on M-F 7:30 - 5:30pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached on 571-270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/YIN Y CHOI/Examiner, Art Unit 3699 1/2/2026