DETAILED ACTION
Claims 1-20 are pending and have been examined.
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 .
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 1-20 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1-20 recite multiple instances of the limitation "a request" to then refer back to “the request”, making it indefinite which request is being referenced. There is insufficient antecedent basis for this limitation in the claim.
This is not intended to be a complete list of such indefiniteness issues.
The dependent claims included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. Therefore, they are rejected based on the same rationale as applied to their parent claims above.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Jacobs (20250225506).
Regarding claim 1, Jacobs teaches A method, comprising (abstract, fig.1-2, par.52-61):
receiving, by a first service provider system, a request to provide a first network token that is usable by a second service provider system to request performance of a first operation at an operations system on behalf of a first user, wherein the request includes operation information associated with the first operation (fig.1-2, par.85-89, request token for transaction processing);
based on the operation information, the first service provider system sending a request to the operations system to generate and return the first network token, wherein the first network token is usable with a first cryptogram to collectively cause the operations system to perform the first operation (par.46-51, provide token later used for transaction processing);
providing, by the first service provider system, the first network token to a first web service system associated with the first user (par.49-53, token service gets token in pending state);
subsequent to providing the first network token, the first service provider system receiving a request indicative that the first web service system seeks to initiate the first operation; and providing, by the first service provider system, the first cryptogram to the first web service system to enable the first web service system to initiate the first operation via the second service provider system using the first network token and the first cryptogram (par.52-61, provide token and cryptogram and other information to process transaction).
Regarding claim 12, Jacobs teaches A non-transitory computer-readable medium having program instructions stored thereon that are executable by a first service provider system to cause the first service provider system to perform operations comprising (abstract, fig.1-2, par.52-61):
receiving a request to provide a first network token usable by a second service provider system to facilitate a first operation between a first entity and a second entity, wherein the request includes operation information about the first operation (fig.1-2, par.85-89, request token for transaction processing);
based on the operation information, identifying a first operations system capable of facilitating the first operation between the first and second entities; sending a request to the first operations system to return the first network token, wherein the first network token is usable with a first cryptogram to collectively cause the first operations system to perform the first operation (par.46-51, provide token later used for transaction processing);
providing the first network token to a first web service system associated with the first entity (par.49-53, token service gets token in pending state);
after the providing of the first network token to the first web service system, receiving a request indicative that the first web service system seeks to initiate the first operation; and providing the first cryptogram to the first web service system to enable the first web service system to initiate the first operation via the second service provider system using the first network token and the first cryptogram (par.52-61, provide token and cryptogram and other information to process transaction).
Regarding claim 17, Jacobs teaches A first service provider system, comprising: at least one processor; and memory having program instructions stored thereon that are executable by the at least one processor to cause the first service provider system to perform operations comprising (abstract, fig.1-2, par.52-61):
receiving a request to provide a first network token usable by a second service provider system to facilitate a first operation at an operations system on behalf of a first user (fig.1-2, par.85-89, request token for transaction processing);
sending a request to the operations system to return the first network token, wherein the first network token is usable with a first cryptogram to collectively cause the operations system to perform the first operation (par.46-51, provide token later used for transaction processing);
providing the first network token to a first web service system associated with the first user (par.49-53, token service gets token in pending state);
after the providing of the first network token to the first web service system, receiving a request indicative that the first web service system seeks to initiate the first operation; and providing the first cryptogram to the first web service system to enable the first web service system to initiate the first operation via the second service provider system using the first network token and the first cryptogram (par.52-61, provide token and cryptogram and other information to process transaction).
Regarding claim 2, Jacobs teaches storing, by the first service provider system, a plurality of network tokens for a plurality of web service systems, wherein the plurality of network tokens includes the first network token and a second network token that enables the first web service system to initiate a second operation for a second user via the second service provider system (fig.1-2, par.52-61).
Regarding claim 3, Jacobs teaches providing, by the first service provider system to a second web service system that is associated with a second user, a second network token usable by a third service provider system to facilitate a second operation for the second user; after the providing of the second network token to the second web service system, the first service provider system receiving a request indicative that the second web service system seeks to initiate the second operation; and providing, by the first service provider system, a second cryptogram to the second web service system to enable the second web service system to initiate the second operation via the third service provider system using the second network token and the second cryptogram (par.52-61).
Regarding claim 4, Jacobs teaches wherein the first network token is service provider system independent such that the first network token is usable by a third service provider system to request performance of the first operation at the operations system on behalf of the first user (fig.1-2, par.44-50).
Regarding claim 5, Jacobs teaches wherein the first network token is usable for conducting a plurality of operations but the first cryptogram is usable for conducting a single operation (par.53-60, token corresponds to card used for payments, cryptogram correspond to codes for individual transactions).
Regarding claim 6, Jacobs teaches subsequent to completion of the first operation, the first service provider system receiving a request from the first web service system to provide a second cryptogram that is usable with the first network token to initiate a second operation for the first user; obtaining, by the first service provider system, the second cryptogram from the operations system; and providing, by the first service provider system, the second cryptogram to the first web service system (par.52-61).
Regarding claim 7, Jacobs teaches wherein the first network token is usable without a cryptogram to perform, after completion of the first operation, one or more subsequent operations for the first user (par.53-60).
Regarding claim 8, Jacobs teaches revoking, by the first service provider system, the first network token in response to receiving, from the first user via a user device, a request to revoke the first network token on behalf of the first user (par.62-67).
Regarding claim 9, Jacobs teaches wherein the request to provide the first network token is received from the first web service system (fig.1-2, par.85-89).
Regarding claim 10, Jacobs teaches wherein the request to provide the first network token is received from a user device of the first user (fig.1-2, par.48-54, 85-89).
Regarding claim 11, Jacobs teaches wherein the providing of the first network token to the first web service system includes routing the first network token through the user device (fig.1-2, par.48-54, 85-89).
Regarding claim 13, Jacobs teaches storing a plurality of network tokens for a plurality of web service system, including the first network token and a second network token that is associated with the first web service system but with a third entity; and deleting at least one of the plurality of network tokens in response to determining that the at least one network token has become invalid (par.42-44, 108-110).
Regarding claims 14 and 19, Jacobs teaches receiving a request from the first web service system to provide a second cryptogram so that the first web service system is able to initiate a second operation between the first and second entities; obtaining the second cryptogram from the first operations system; and providing the second cryptogram to the first web service system. / receiving a request from the first web service system to provide a second cryptogram so that the first web service system is able to initiate a second operation at the operations system on behalf of the first user; obtaining the second cryptogram from the operations system; and providing the second cryptogram to the first web service system (fig.1-2, par.52-61).
Regarding claim 15, Jacobs teaches sending a set of requests to a second operations system to return a second network token and a second cryptogram that are collectively usable by the first web service system to initiate a second operation between the first and second entities; and providing the second network token and the second cryptogram to the first web service system (par.42-44, 108-110).
Regarding claim 16, Jacobs teaches wherein the first cryptogram is associated with an expiration time that is indicative of when the first cryptogram is no longer usable with the first network token to initiate the first operation at the first operations system (par.42-44, 108-110).
Regarding claim 18, Jacobs teaches storing a plurality of network tokens for a plurality of web service systems, including the first network token and a second network token that is associated with the first web service system but with a second user (fig.1-2, par.44-50).
Regarding claim 20, Jacobs teaches providing, to a second web service system, a second network token and a second cryptogram usable by a third service provider system to facilitate a second operation at the operations system on behalf of a second user (fig.1-2, par.44-50).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: the remaining references put forth on the PTO-892 form are directed to federated interworking between different providers, Leyva (20220376914), Cassin (20220231851), Patterson (20230318832), Collinge (20230327863), Rule (20230316275).
Gerban (20260228715) teaches the payment service provider 6 sends this virtual payment card or the virtual payment token, in particular and preferably with a cryptogram, to the mobile phone provider 5, which couples it with the SIM or eSIM and the user-related and the user-specific vehicle-related parameter set. Moreover, the virtual payment card or the virtual payment token can preferably be transmitted to the ecosystem of the vehicle manufacturer, in this case to the server 4 external to the vehicle, which also stores the data. A virtual payment card or a virtual payment token can here be generated individually for each payment process or it can be generated or renewed periodically, depending on the security requirements placed on the system.
Chitalia (20210176062 ) teaches a process for token-requestor-based key management may include generating, by a processor computer, a first master key for a token requestor, the first master key being generated based on (a) a second master key managed by the processor computer and (b) an identifier of the token requestor; transmitting, by the processor computer to a token requestor computer corresponding to the token requestor, the first master key; receiving, by the processor computer from the token requestor computer, a request for a token; responsive to receiving the request for the token, transmitting, by the processor computer, the token to the token requestor computer; and receiving, by the processor computer from the token requestor computer, an authorization request message comprising the token and a cryptogram generated by the token requestor computer using the first master key and the token.
Wind (12333525) teaches optimizing transaction authorization conversion rates based on the use of network tokens may include receiving, at an acquirer processor, a payment transaction from a merchant, determining whether the payment transaction includes a network token, upon determining that the payment transaction does not include a network token, determining whether the payment transaction should be modified to include a network token based on a likelihood that the payment transaction will be authorized by a financial institution will be increased when the payment transaction includes a network token, upon determining whether the payment transaction should be modified to include a network token, obtaining a network token for the payment transaction, and modifying the payment transaction to include the obtained network token, and submitting the modified payment transaction to the financial institution for processing.
Abouelenin (20250148457) teaches generating, by a token service provider, a token for a payment account based on a request from a user, where the token includes an indicator of a type of transaction for which the token is available for use, and provisioning, by the token service provider, the token to a third party. In doing so, in response to use of the token in a transaction to the payment account, the indicator is included at a first data element of an authorization request for the transaction to the payment account thereby identifying the type of the transaction in the authorization request.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to David García Cervetti whose telephone number is (571)272-5861. The examiner can normally be reached Monday-Friday 8AM-5PM.
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, HADI S ARMOUCHE can be reached at (571)270-3618. 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.
/David Garcia Cervetti/Primary Examiner, Art Unit 2409
Prosecution Insights