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 .
DETAILED ACTION
1. The following is a non-Final Office Action in response to applicant’s arguments/filing filed on December 19, 2024
Claim 1 is cancelledclaims 2-21 are pending
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 4/10/2025 was filed prior to the mailing date of the first office action. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
The information disclosure statement (IDS) submitted on 4/8/2025 was filed prior to the mailing date of the first office action. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
Acknowledgment is made of applicant’s drawings submitted on 12/19/2024.
Oath/Declaration
Acknowledgment is made of applicant’s oath submitted on 12/19/2024
Application Data Sheet
Acknowledgment is made of applicant’s application data sheet submitted on 12/19/2024.
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 claims at issue 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this 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/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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 2, 14 and 19 are rejected on the ground of nonstatutory double patenting over claims 1, 8 and 15 of U. S. Patent No. 11/010,730 and claims 1, 9 and 16 of U.S. Patent No. 12/205,085 since the claims, if allowed, would improperly extend the "right to exclude" already granted in the patent.
The subject matter claimed in the instant application is fully disclosed in the patent and is covered by the patent since the patent and the application are claiming common subject matter, as follows:
Instant Application
Patent
11/010,730, 12205085
(New) A method, comprising: accessing a request from a first party, wherein the request is associated with a user request to conduct one or more transactions with one or more third parties through a platform provided by the first party, and wherein the request indicates a payment method of the user for the one or more transactions; generating, based on the request, a first token that comprises an encoding of the payment method, wherein the first token indicates a scope of a usage of the payment method; sending the first token to the first party; accessing, after the first token has been sent to the first party, a transaction request from a particular one of the one or more third parties, wherein the transaction request comprises the first token and a request to process a first transaction of the one or more transactions; and processing the first transaction based on the first token in the transaction request.
(New) The method of claim 2, further comprising providing a status of the first transaction to the particular one of the one or more third parties.
(New) The method of claim 2, further comprising: receiving, from the first party, a request associated with invalidating the first token; invalidating the first token based on the request associated with invalidating the first token; and providing a notification to the first party after the first token has been invalidated
(New) The method of claim 2, wherein: the first party comprises an entity associated with a social network, a referral network, a discount website, or a coupon website; and the one or more third parties comprise one or more merchants that offer goods or services through an interface provided by the first party.
(New) The method of claim 2, wherein the scope of the usage of the payment method comprises a time of usage, a transaction amount, or a merchant with whom the first token can be used.
(New) The method of claim 2, wherein: the request comprises a second token that contains encoded information associated with the one or more third parties; and the encoded information comprises one or more identifiers of the one or more third parties.
(New) The method of claim 2, wherein the request indicates whether a given one of the one or more third parties is allowed to store the first token.
(New) The method of claim 2, wherein the scope of the usage of the payment method enables a first one of the one or more third parties to accept the payment method to conduct transactions but restricts an ability of the first one of the one or more third parties to transfer the payment method to a second one of the one or more third parties.
10. (New) The method of claim 2, further comprising, before the accessing the request: receiving a request from the first party to store the payment method; generating a payment token corresponding to the payment method; and sending the payment token to the first party that enables the first party to store the
payment method.
11. (New) The method of claim 2, wherein the first token indicates an expiration time of the payment method, after which the payment method automatically expires after the expiration time.
12. (New) The method of claim 2, wherein the scope of the usage of the payment method is definable via an electronic interface provided by the first party.
13. (New) The method of claim 2, wherein one or more of the accessing the request, the generating, the sending, the accessing the transaction request, or the processing are performed via one or more hardware processors of a service provider that is different from the first party and the one or more third parties.
14. (New) A system, comprising: a non-transitory memory storing instructions; and one or more processors configured to execute the instructions to cause the system to perform operations comprising: receiving, from a first party that hosts a platform through which a plurality of third parties offer products or services, a first request that includes providing sensitive data associated with a user of the first party; generating, in response to the first request, a shareable token that comprises an encoding of the sensitive data, wherein the shareable token defines a set of criteria for a usage of sensitive data; sending the shareable token to the first party; receiving, after the shareable token has been sent to the first party, a second request from a particular one of the plurality of third parties, wherein the second request comprises a request to conduct a transaction with the user that requires the sensitive data, and wherein the second request is accompanied by the shareable token; determining whether one or more criteria associated with the transaction match the set of criteria defined by the shareable token; and processing the transaction based on the determining.
15. (New) The system of claim 14, wherein operations further comprise: receiving, from the first party, a third request to revoke the shareable token; and revoking the shareable token based on the third request.
16. (New) The system of claim 14, wherein: the shareable token further indicates an expiration time of the shareable token; and the shareable token automatically expires after the expiration time.
17. (New) The system of claim 14, wherein the first request comprises identification information of one or more of the third parties of the plurality of third parties.
18. (New) The system of claim 14, wherein set of criteria is user-definable via an electronic user interface of the platform of the first party.
19. (New) A non-transitory machine-readable medium having instructions stored thereon, the instructions executable to cause a machine to perform operations comprising: receiving, from an entity associated with a platform, a first request to provide a token that comprises encoded payment instrument data associated with a first user of a plurality of users of the entity, wherein the entity hosts a platform through which a plurality of merchant entities offer goods or services to the plurality of users; generating the token based on the first request, wherein the token further defines one or more conditions under which the token can be shared and used; providing the token to the entity; receiving, after the token has been provided to the entity, a second request from a first merchant of the plurality of merchant entities to conduct a transaction with the first user based the token; and processing the transaction based on a determination that the transaction meets the one or more conditions defined by the token.
20. (New) The non-transitory machine-readable medium of claim 19wherein operations further comprise revoking the token based on a request from the entity.
21. (New) The non-transitory machine-readable medium of claim 19, wherein the one or more conditions were received from the first user via an interface of the entity.
1. A system of a service provider for providing a scope-delimited encoding of sensitive data, comprising: 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 perform operations comprising: receiving, by the service provider and from a first party in response to a request from a user to provide payment information of the user to a third party, a grant request to an application programming interface to provide a scope-delimited encoding of the payment information, wherein the grant request includes an encoding of the payment information, wherein the user is different from the first party and the third party, wherein the first party includes a first merchant that offers a platform, wherein the third party includes a second merchant offering goods or services through the platform, and wherein the grant request includes an access token that contains encoded information that identifies the third party; generating, by the service provider, the scope-delimited encoding of the payment information based on the encoding of the payment information; providing, by the service provider and to the first party, the scope-delimited encoding of the payment information; receiving, by the service provider and from the third party, a transaction request, the transaction request including the scope-delimited encoding of the payment information; processing, by the service provider, the transaction request; and in response to a revocation request from the first party, revoking, by the service provider, an access of the third party to the scope-delimited encoding of the payment information.
2. The system of claim 1, wherein the operations further comprise: storing, by the service provider, the payment information in a vault, and wherein the grant request specifies whether the second merchant can store the scope-delimited encoding of the payment information.
3. The system of claim 1, wherein the operations further comprise deleting the scope-delimited encoding of the payment information in response to the revocation request.
4. The system of claim 1, wherein the revocation request is an HTTP POST request to the application programming interface, and wherein the revocation request includes the scope-delimited encoding of the payment information.
5. The system of claim 1, wherein the grant request to provide the scope-delimited encoding of the payment information includes one or more of a time expiry or a specific amount for the scope-delimited encoding, and wherein the operations further comprise generating the scope-delimited encoding of the payment information according to the time expiry or the specific amount.
6. The system of claim 1, wherein the operations further comprise: transmitting an error code response to the third party when the access to the scope-delimited encoding of the payment information to the third party is revoked.
7. The system of claim 1, wherein the operations further comprise receiving, from the first party, an update to a scope-delimited encoding of the payment information, and transmitting a notification of the update to the third party.
8. A computer-implemented method, comprising: receiving, by a service provider and from a first party in response to a request from a user to provide payment information of the user to a third party, a grant request to an application programming interface to provide a scope-delimited encoding of the payment information of the user associated with the first party, wherein the grant request includes an encoding of the payment information, wherein the user is different from the first party and the third party, wherein the first party includes a first merchant that offers a platform offered by a first merchant, and wherein the third party includes a second merchant offering goods or services through the platform and wherein the grant request includes an access token that contains encoded information that identifies the third party; generating, by the service provider, the scope-delimited encoding of the payment information based on the encoding of the payment information in the grant request; providing, by the service provider and to the first party, the scope-delimited encoding of the payment information; receiving, by the service provider and from the third party, a transaction request, the transaction request including the scope-delimited encoding of the payment information; processing, by the service provider, the transaction request; and in response to a revocation request from the first party, revoking an access by the third party to the scope-delimited encoding of the payment information.
9. The method of claim 8, further comprising: storing, by the service provider, the payment information.
10. The method of claim 8, further comprising deleting the scope-delimited encoding of the payment information in response to the revocation request.
11. The method of claim 8, wherein the revocation request is an HTTP POST request to the application programming interface, and wherein the revocation request includes the scope-delimited encoding of the payment information.
12. The method of claim 8, wherein the grant request to provide the scope-delimited encoding of the payment information includes one or more of a time expiry or a specific amount for the scope-delimited encoding, and wherein the method further comprises generating the scope-delimited encoding of the payment information according to the time expiry or the specific amount.
13. The method of claim 8, further comprising: transmitting an error code response to the third party when the access to the scope-delimited encoding associated with the third party is revoked.
14. The method of claim 8, further comprising receiving, from the first party, an update to a scope-delimited encoding of the payment information, and transmitting a notification of the update to the third party.
15. A non-transitory machine-readable medium having stored thereon machine-readable instructions executable to cause a machine to perform operations comprising: receiving, by a service provider and from a first party in response to a request from a user to provide a payment information of the user to a third party, a grant request to an application programming interface to provide a scope-delimited encoding of the payment information, wherein the grant request includes an encoding of the party payment information, wherein the user is different from the first party and the third party, wherein the first party includes a first merchant that offers a platform, wherein the third party includes a second merchant offering goods or services through the platform, and wherein the grant request includes an access token that contains encoded information that identifies the third party; generating, by the service provider, the scope-delimited encoding of the payment information based on the encoding of the payment information in the grant request; providing, by the service provider and to the first party, the scope-delimited encoding of the payment information; receiving, by the service provider and from the third party, a transaction request, the transaction request including the scope-delimited encoding of the payment information; processing, by the service provider, the transaction request; and in response to a revocation request from the first party, revoking, by the service provider, an access by the third party to the scope-delimited encoding of the payment information.
16. The machine-readable medium of claim 15, wherein the operations further comprise: storing, by the service provider, the payment information.
17. The machine-readable medium of claim 15, wherein the operations further comprise deleting the scope-delimited encoding of the payment information in response to the revocation request.
18. The machine-readable medium of claim 15, wherein the revocation request is an HTTP POST request to an application programming interface, and wherein the revocation request includes the scope-delimited encoding of the payment information.
19. The machine-readable medium of claim 15, wherein the grant request to provide the scope-delimited encoding of the payment information includes one or more of a time expiry or a specific amount for the scope-delimited encoding, and wherein the operations further comprise generating the scope-delimited encoding of the payment information according to the time expiry or the specific amount.
20. The machine-readable medium of claim 15, wherein the operations further comprise receiving, from the first party, an update to the scope-delimited encoding of the payment information, and transmitting a notification of the update to the third party.
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 –
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.
(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
1.) Claims 14, 16, 17, 19 and 21 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US 20190272545, Ozvat
In regards to claim 14, Ozvat teaches a system, comprising: a non-transitory memory storing instructions(US 20190272545, Ozvat, para. 0099, Attached to System Bus 920 are a wide variety of subsystems. Processor(s) 922 (also referred to as central processing units, or CPUs)); and one or more processors configured to execute the instructions to cause the system to perform operations(US 20190272545, Ozvat, para. 0099, Attached to System Bus 920 are a wide variety of subsystems. Processor(s) 922 (also referred to as central processing units, or CPUs) are coupled to storage devices, including Memory 924. Memory 924 includes random access memory (RAM) and read-only memory (ROM). As is well known in the art, ROM acts to transfer data and instructions uni-directionally to the CPU and RAM is used typically to transfer data and instructions in a bi-directional manner.) comprising: receiving, from a first party that hosts a platform through which a plurality of third parties offer products or services, a first request that includes providing sensitive data associated with a user of the first party(US 20190272545, Ozvat, para. 0063, To facilitate this discussion, FIGS. 8A and 8B provide example block diagrams for methods for securely handling transaction payments, in accordance with some embodiments. In FIG. 8A, the point of sale terminal 102 may collect credit card information (or other sensitive payment information) and transfer the data securely to the payment system(s) 106, at 800a. Intermediary in this transaction is a payment processor which ensures validity of the request, and generates a multi-merchant token.); generating, in response to the first request, a shareable token that comprises an encoding of the sensitive data, wherein the shareable token defines a set of criteria for a usage of sensitive data; sending the shareable token to the first party(US 20190272545, Ozvat, para. 0065, In contrast to current tokenization systems, the presently disclosed systems and methods transfer a token with a unique makeup (including encrypted card data) that enables distributed storage of sensitive information, as well as the ability for multiple merchants to share the token for transactions. This may be of particular use in franchise or related businesses, where a customer's payment information may be processed by multiple merchants); receiving, after the shareable token has been sent to the first party, a second request from a particular one of the plurality of third parties, wherein the second request comprises a request to conduct a transaction with the user that requires the sensitive data(US 20190272545, Ozvat, para. 0127, Similar to a multi-merchant token exchanged between a POS terminal system 102 and the payment management system 120, a PES token may be utilized in subsequent related transaction request(s) and transaction response(s)), and wherein the second request is accompanied by the shareable token(US 20190272545, Ozvat, para. 0127, wherein the PES token is exchanged between payment management system 120 and VEP entity system(s)); determining whether one or more criteria associated with the transaction match the set of criteria defined by the shareable token(US 20190272545, Ozvat, para. 0078, When a token is supplied to the system during a later transaction, the GID in the token is compared against the merchant ID listed in the data tier 114.); and processing the transaction based on the determining(US 20190272545, Ozvat, para. 0078, If they match, then the tokenization and payment management system 120 may process the token.).
In regards to claim 16, Ozvat teaches the system of claim 14, wherein: the shareable token further indicates an expiration time of the shareable token(US 20190272545, Ozvat, para. 0074, The token includes a primary account number (PAN), a group ID (GID), an expiration date for the token, and an expiration date for the card); and the shareable token automatically expires after the expiration time(US 20190272545, Ozvat, para. 0075, In some embodiments, the expiration date of the token may be varied depending upon if the token is designated as a single use token, or for recurring transactions (i.e., a subscription). For example, a 1 year and 2 year expiration may be provided for a single use and recurring token, respectively.).
In regards to claim 17, Ozvat teaches the system of claim 14, wherein the first request comprises identification information of one or more of the third parties of the plurality of third parties(US 20190272545, Ozvat, para. 0078, Additionally, unlike other token based systems, the present system includes a GID (group ID) which enables more than one merchant to utilize the token. The data tier 114 maintains a cop of merchant IDs and correlates them with one or more GIDs.).
In regards 19, Ozvat teaches a non-transitory machine-readable medium having instructions stored thereon, the instructions executable to cause a machine to perform operations comprising: receiving, from an entity associated with a platform, a first request to provide a token that comprises encoded payment instrument data associated with a first user of a plurality of users of the entity, wherein the entity hosts a platform through which a plurality of merchant entities offer goods or services to the plurality of users(US 20190272545, Ozvat, para. 0065, In contrast to current tokenization systems, the presently disclosed systems and methods transfer a token with a unique makeup (including encrypted card data) that enables distributed storage of sensitive information, as well as the ability for multiple merchants to share the token for transactions. This may be of particular use in franchise or related businesses, where a customer's payment information may be processed by multiple merchants); generating the token based on the first request, wherein the token further defines one or more conditions under which the token can be shared and used(US 20190272545, Ozvat, para. 0253, The EPMS 120 may verify the appropriate construct and other characteristics (e.g., uniqueness) of such identifiers and if acceptable to the payment management service provider may record the identifiers (say in data tier 114) such that they may be created/assigned utilizing the reserved values at such time as the merchant may be subsequently boarded. Reserving such identifiers also serves to prevent them from being assigned to other merchants.); providing the token to the entity(US 20190272545, Ozvat, para. 0073, The point of sale terminal 102 may be capable of providing the collected account information (and other sensitive information) to a payment service(s) 104 in the tokenization and payment management system 120 (payment processor).); receiving, after the token has been provided to the entity, a second request from a first merchant of the plurality of merchant entities to conduct a transaction with the first user based the token(US 20190272545, Ozvat, para. 0127, Similar to a multi-merchant token exchanged between a POS terminal system 102 and the payment management system 120, a PES token may be utilized in subsequent related transaction request(s) and transaction response(s)); and processing the transaction based on a determination that the transaction meets the one or more conditions defined by the token(US 20190272545, Ozvat, para. 0078, When a token is supplied to the system during a later transaction, the GID in the token is compared against the merchant ID listed in the data tier 114. If they match, then the tokenization and payment management system 120 may process the token.). In regards to claim 21, Ozvat teaches the non-transitory machine-readable medium of claim 19, wherein the one or more conditions were received from the first user via an interface of the entity(US 20190272545, Ozvat, para. 0253, Identifiers including but not limited to merchant ID, group ID, POS terminal system ID, POS operator identifiers and POS system lane IDs may be transmitted by the EPMS 120 to the POS system 120 so that such identifiers may be utilized subsequently in payment transactions and other communications exchanged between the POS system and the EPMS.).
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 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.
1.) Claims 2, 3, 6, 7, 9, 11, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over US 20140032283, Bradford in view of US 20130191289, Cronic
In regards to claim 2, Bradford teaches a method, comprising: accessing a request from a first party, wherein the request is associated with a user request to conduct one or more transactions with one or more third parties through a platform provided by the first party(US 20140032283, Bradford, para. 0035, A system that incents consumers to make more purchases[i.e. note: inherently requesting] at physical or virtual merchant locations who may be geographically nearby one another and provides an approved sale of Merchant-2 goods while the consumer is at Merchant-1's location (physical or electronic commerce). By using this separate incentive system, there is proof provided to Merchant-1 that the Merchant-2's deal offered at Merchant-1 was consumed and that Merchant-2 will pay Merchant-1 a fee for the Merchant-2 transaction that was initiated through Merchant-1's location.), and wherein the request indicates a payment method of the user for the one or more transactions(US 20140032283, Bradford, para. 0110, In this preferred embodiment a person 10 holding an electronic device, like a cell phone 12, will pay using any method (credit card, debit, cash, etc. . . . ) for the first merchant's 20 product or service.); generating, based on the request, a first token that comprises an encoding of the payment method, wherein the first token indicates a scope of a usage of the payment method(US 20140032283, Bradford, para. 0179, the product or service being offered can be purchased right there in real time by the consumer from his phone, and payment can be made for the product or service of Merchant-2, using payments procedures well known in the art. This system tracks the fact that a purchase has been made storing data elements such as a onetime code, or barcode, or unique system transaction number[i.e. note: token] that would provide evidence that the system is tracking the purchase and the purchase has been entered into the system, and approved or denied[i.e. note: scope of usage being allowed or denied], and if approved, a transaction code or receipt as proof of purchase is given back to the consumer on his phone); sending the first token to the first party(US 20130191289, Cronic, para. 0004, the tokenization system may be configured to electronically transmit the token to the first merchant so as to enable the first merchant to perform a first transaction for the cardholder without having to store the CHD.); Bradford does not teach accessing, after the first token has been sent to the first party, a transaction request from a particular one of the one or more third parties, wherein the transaction request comprises the first token and a request to process a first transaction of the one or more transactions; and processing the first transaction based on the first token in the transaction request However, Cronic teaches accessing, after the first token has been sent to the first party, a transaction request from a particular one of the one or more third parties, wherein the transaction request comprises the first token and a request to process a first transaction of the one or more transactions(US 20130191289, Cronic, para. 0036, providing the second merchant with access to the token and/or the CHD associated with the token comprises providing the second merchant with an authorization factor. This authorization factor is associated with one or more of the token, the CHD, and the second merchant. In one embodiment, to access the token and/or CHD, the tokenization provider system can request that the second merchant present the authorization factor as part of the user authentication process.); and processing the first transaction based on the first token in the transaction request(US 20130191289, Cronic, para. 0040, The merchant environment 104 can generally include any product or service provider that accepts credit cards, or other types of payment cards, for payment and utilizes the tokenization provider system 102 for payment processing.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Bradford with the teaching of Cronic because a user would have been motivated to tokenize user information, taught by Cronic, in order to protect cardholder information, taught by Bradford, in order to enhance user security when conducting transactions (Cronic, para. 0031)
In regards to claim 3, the combination of Bradford and Cronic teach the method of claim 2, further comprising providing a status of the first transaction to the particular one of the one or more third parties(US 20140032283, Bradford, para. 0179, his system tracks the fact that a purchase has been made storing data elements such as a onetime code, or barcode, or unique system transaction number that would provide evidence that the system is tracking the purchase and the purchase has been entered into the system, and approved or denied[i.e. note: status of the transaction],).
In regards to claim 6, the combination of Bradford and Cronic teach the method of claim 2, wherein the scope of the usage of the payment method comprises a time of usage, a transaction amount, or a merchant with whom the first token can be used(US 20140032283, Bradford, para. 0100, This previous merchant sales agent fee is paid by the current merchant to an agreed system number of previous merchants who using system criteria such as time or distance or other mutually agreed criteria are considered to have helped the consumer visit the Current-Merchant. This payment amount for previous merchants is taken out of/from the sales agent fee amount the Current-Merchant receives from the Next-Merchant for the consumer purchase transaction at the Next-Merchant.).
In regards to claim 7, the combination of Bradford and Cronic teach the method of claim 2, wherein: the request comprises a second token that contains encoded information associated with the one or more third parties(US 20130191289, Cronic, para. 0046, The token access system 122 can generally include any system that can generate tokens associated with CHD and provide the tokens to a merchant environment 104.); and the encoded information comprises one or more identifiers of the one or more third parties(US 20130191289, Cronic, para. 0062, to provide the third-party merchant 162 with access to the CHD, the merchant 142 can send the token and a merchant identifier associated with the third-party merchant 162 to the token access system 122.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Bradford with the teaching of Cronic because a user would have been motivated to tokenize user information, taught by Cronic, in order to protect cardholder information, taught by Bradford, in order to enhance user security when conducting transactions (Cronic, para. 0031)
In regards to claim 9, the combination of Bradford and Cronic teach the method of claim 2, wherein the scope of the usage of the payment method enables a first one of the one or more third parties to accept the payment method to conduct transactions but restricts an ability of the first one of the one or more third parties to transfer the payment method to a second one of the one or more third parties(US 20130191289, Cronic, para. 0109, if the pre-defined event is a time-limit or time-period, the CHD access system 124 can disassociate the set of random words from the token at the expiration of the time-limit or time-period whether or not the third-party merchant 162 accessed the CHD. In addition, if the owner of the token (e.g. the merchant 142) ceases to trust the third-party merchant 162, the token owner can access the tokenization provider system 102 and remove the third-party merchant's 162 authorization to access the token, and thus the CHD associated with the token.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Bradford with the teaching of Cronic because a user would have been motivated to tokenize user information, taught by Cronic, in order to protect cardholder information, taught by Bradford, in order to enhance user security when conducting transactions (Cronic, para. 0031)
In regards to claim 11, the combination of Bradford and Cronic teach the method of claim 2, wherein the first token indicates an expiration time of the payment method, after which the payment method automatically expires after the expiration time(US 20130191289, Cronic, para. 0109, if the pre-defined event is a time-limit or time-period, the CHD access system 124 can disassociate the set of random words from the token at the expiration of the time-limit or time-period whether or not the third-party merchant 162 accessed the CHD. ). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Bradford with the teaching of Cronic because a user would have been motivated to tokenize user information, taught by Cronic, in order to protect cardholder information, taught by Bradford, in order to enhance user security when conducting transactions (Cronic, para. 0031)
In regards to claim 13, the combination of Bradford and Cronic teach the method of claim 2, wherein one or more of the accessing the request, the generating, the sending, the accessing the transaction request, or the processing are performed via one or more hardware processors of a service provider that is different from the first party and the one or more third parties(US 20130191289, Cronic, para. 0227, Each such computing device typically includes a processor (or multiple processors) that executes program instructions or modules stored in a memory or other non-transitory computer-readable storage medium). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Bradford with the teaching of Cronic because a user would have been motivated to tokenize user information, taught by Cronic, in order to protect cardholder information, taught by Bradford, in order to enhance user security when conducting transactions (Cronic, para. 0031)
2.) Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over US 20140032283, Bradford in view of US 20130191289, Cronic and further in view of US 20160224782, Miyakawa
In regards to claim 4, the combination of Bradford and Cronic teach the method of claim 2. The combination of Bradford and Cronic do not teach further comprising: receiving, from the first party, a request associated with invalidating the first token; invalidating the first token based on the request associated with invalidating the first token; and providing a notification to the first party after the first token has been invalidated However, Miyakawa teaches further comprising: receiving, from the first party, a request associated with invalidating the first token(US 20160224782, Miyakawa, para. 0097, The invalidation request receiving unit 214 receives a request for invalidating an old access token from the scanner 3); invalidating the first token based on the request associated with invalidating the first token(US 20160224782, Miyakawa, para. 0098, The token invalidating unit 215 invalidates the old access token when an invalidation request is received.); and providing a notification to the first party after the first token has been invalidated(US 20160224782, Miyakawa, para. 0105, When the invalidation request is received, the token invalidating unit 215 invalidates the old access token at the image data processing server 1 (step S516) and the invalidation notifying unit 216 transmits a notification of the invalidation to the scanner 3 (step S517).). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of the combination of Bradford and Cronic with the teaching of Miyakawa because a user would have been motivated to monitor the remaining time to expiration, taught by Miyakawa, in order to update an access token, used in the system taught by the combination of Bradford and Cronic, when the expiration time remaining falls below a predetermined threshold value(Miyakawa, para. 0005)
3.) Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over US 20140032283, Bradford in view of US 20130191289, Cronic and further in view of US 9177174, Shoemaker
In regards to claim 5, the combination of Bradford and Cronic teach the method of claim 2, wherein: the one or more third parties comprise one or more merchants that offer goods or services through an interface provided by the first party(US 20140032283, Bradford, para. 0035, A system that incents consumers to make more purchases at physical or virtual merchant locations who may be geographically nearby one another and provides an approved sale of Merchant-2 goods while the consumer is at Merchant-1's location (physical or electronic commerce).); and the combination of Bradford and Cronic do not teach the first party comprises an entity associated with a social network, a referral network, a discount website, or a coupon website However, Shoemaker teaches the first party comprises an entity associated with a social network, a referral network, a discount website, or a coupon website(see US 9177174, Shoemaker, col. 11, col. 5-7, In some implementations, devices 905-920 may be considered user devices (e.g., devices used by users to access services and/or issue requests, such as on a social network).); It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of the combination of Bradford and Cronic with the teaching of Shoemaker because a user would have been motivated to enhance content security in the system taught by the combination of Bradford and Cronic by using an identifier, taught by Shoemaker, in order to obfuscate content purchases of users(Shoemaker, col. 1, lines 35-44) .
4.) Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over US 20140032283, Bradford in view of US 20130191289, Cronic and further in view of US 20160269360, Gluck
In regards to claim 8, the combination of Bradford and Cronic teach the method of claim 2. The combination of Bradford and Cronic do not teach wherein the request indicates whether a given one of the one or more third parties is allowed to store the first token However, Gluck teaches wherein the request indicates whether a given one of the one or more third parties is allowed to store the first token(US 20160269360, Gluck, para. 0046, the firewall and/or the event correlator may operate to generate a token to be associated with the request, 325. Information corresponding to the token (e.g., policies, limits, identifiers) may be stored with the token in the event correlator, 335.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of the combination of Bradford and Cronic with the teaching of Gluck because a user would have been motivated to use an event correlator, taught by Gluck, to enable processing of tokens in the system taught by the combination of Bradford and Cronic, in order to enable a firewall to process traffic to initiate an action(Gluck, para. 0034)
5.) Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over US 20140032283, Bradford in view of US 20130191289, Cronic and further in view of US 20130091061, Caulkett
In regards to claim 10, the combination of Bradford and Cronic teach the method of claim 2, further comprising, before the accessing the request: sending the payment token to the first party that enables the first party to store the payment method(US 20130191289, Cronic, para. 0004, the tokenization system may be configured to electronically transmit the token to the first merchant so as to enable the first merchant to perform a first transaction for the cardholder without having to store the CHD.); and The combination of Bradford and Cronic do not teach receiving a request from the first party to store the payment method; generating a payment token corresponding to the payment method; However, Caulkett teaches receiving a request from the first party to store the payment method(US 20130091061, Caulkett, para. 0027, requesting the payment token engine 12 to collect a payment from the card represented by the returned token (this is done through another XML API) and/or store the token against the user's details for future use.); generating a payment token corresponding to the payment method(US 20130091061, Caulkett, para. 0026, a token is generated representing the card data stored in the payment token engine 12. This token is stored in the payment token database.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of the combination of Bradford and Cronic with the teaching of Caulkett because a user would have been motivated to enhance data security in the system taught by the combination of Bradford and Cronic by utilizing a secure data entry screen, taught by Caulkett, to enter secure user data(Caulkett, para. 0003) .
6.) Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over US 20140032283, Bradford in view of US 20130191289, Cronic and further in view of US 20040249753, Blinn
In regards to claim 12, the combination of Bradford and Cronic teach the method of claim 2. The combination of Bradford and Cronic do not teach wherein the scope of the usage of the payment method is definable via an electronic interface provided by the first party However, Blinn teaches wherein the scope of the usage of the payment method is definable via an electronic interface provided by the first party(US 20040249753, Blinn, para. 0009, restrictions limit the ability of funds to be transferred into payment accounts or transferred to other payment accounts. The payment account is limited so that funds can be added to (or withdrawn from) the payment account only from (or to) certain individuals. Such limitations prevent the user from transferring funds to particular other individuals, or receiving funds from particular other individuals (e.g., a parent may establish a child's payment account so that only the parent can add funds to it, not other individuals the child may encounter on the Internet)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of the combination of Bradford abd Cronic with the teaching of Blinn because a user would have been motivated to initiate usage security, taught by Blinn, by placing account usage restrictions, in the system taught by Bradford and Cronic, in order to restrict transactions to certain merchants(Blinn, para. 0008)
7.) Claims 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190272545, Ozvat in view of US 20160224782, Miyakawa
In regards to claim 15, Ozvat teaches the system of claim 14. Ozvat does not teach wherein operations further comprise: receiving, from the first party, a third request to revoke the shareable token; and revoking the shareable token based on the third request However, Miyakawa teaches wherein operations further comprise: receiving, from the first party, a third request to revoke the shareable token(US 20160224782, Miyakawa, para. 0097, The invalidation request receiving unit 214 receives a request for invalidating an old access token from the scanner 3); and revoking the shareable token based on the third request(US 20160224782, Miyakawa, para. 0098, The token invalidating unit 215 invalidates the old access token when an invalidation request is received.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Ozvat with the teaching of Miyakawa because a user would have been motivated to monitor the remaining time to expiration, taught by Miyakawa, in order to update an access token, used in the system taught by Ozvat, when the expiration time remaining falls below a predetermined threshold value(Miyakawa, para. 0005) In regards to claim 20, Ozvat teaches the non-transitory machine-readable medium of claim 19. Ozvat does not teach wherein operations further comprise revoking the token based on a request from the entity However, Miyakawa teaches wherein operations further comprise revoking the token based on a request from the entity(US 20160224782, Miyakawa, para. 0097, The invalidation request receiving unit 214 receives a request for invalidating an old access token from the scanner 3). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Ozvat with the teaching of Miyakawa because a user would have been motivated to monitor the remaining time to expiration, taught by Miyakawa, in order to update an access token, used in the system taught by Ozvat, when the expiration time remaining falls below a predetermined threshold value(Miyakawa, para. 0005)
8.) Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over US 20190272545, Ozvat in view of US 20110113488, Schultz
In regards to claim 18, Ozvat teaches the system of claim 14. Ozvat does not teach wherein set of criteria is user-definable via an electronic user interface of the platform of the first party However, Schultz teaches wherein set of criteria is user-definable via an electronic user interface of the platform of the first party (US 20110113488, Schultz, para. 0010, In one exemplary implementation, a user may interface with an access management system to set policies and/or criteria associated with allowing others to access his/her information.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Ozvat with the teaching of Schultz because a user would have been motivated to utilize an access manager, taught by Schultz, to enable users to set policies, criteria and preferences in order to allow a user to customize access control to private information in the system taught by Ozvat(Schultz, para. 0014)
CONCLUSION
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY LANE whose telephone number is (571)270-7469. The examiner can normally be reached on 571 270 7469 from 8:00 AM to 6:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Taghi Arani, can be reached on 571 272 3787. 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).
/GREGORY A LANE/Examiner, Art Unit 2438
/TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438
Prosecution Insights