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
Status of Claim
The claims are not Amended as filed on 11/21/2025 for consideration.
Claims 21-40, are pending.
Claims 1-20, originally filed are cancelled, therefore
Claims 21-40, are hereby examined.
Examiner’s Response to Amendment/Remarks
35 USC § 103
Applicant’s argument and remarks filed in the response filed on 11/21/2025 is hereby acknowledged and argument/remarks have been found unpersuasive by the Examiner. In page 6 of the response, Applicant asserts that […identifying the second payment platform, wherein the second payment platform is different than the first payment platform." Applicant respectfully disagrees. Specifically, Applicant respectfully submits that the full claim recitation recites "based on determining that the sending user is associated with the first payment platform ... identifying the second payment platform, wherein the second payment platform is different than the first payment platform."… Although Qian briefly discloses a second payment platform, and although Qian's first and second payment platforms appear to be different payment platforms, Applicant respectfully submits that …Qian fails to disclose a step of determining that the sending user is associated with the first payment platform, much less identifying the second payment platform based on the determination that the sending user is associated with the first payment platform, as required by independent Claim 21].
Examiner respectfully, disagrees with this argument as this limitation was taught by the combination of Oliynyk in view of Qian. Oliynyk teaches the step of “determining, by the service computing device, the sending user is associated with the first payment platform in col 14: 50-53 , based on Oliynyk teachings of determining that the sending user is associated with the first payment platform, Qian teaches “identifying the second payment platform, wherein the second payment platform is different than the first payment platform” in ¶¶ 0020, 0028-0033, as disclosed below. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Further on page 7 of the response, [Applicant respectfully submits that Qian merely discloses transferring a payment, which is substantially different from communicating a payment request, as required by independent Claim 21. For example, communicating a payment request merely conveys a request for action. The communication of the payment request itself does not perform nor require a transfer of payment. Alternatively, the transfer of payment is a distinct operation from the communication of the payment request. Although Qian briefly discloses transferring a payment, Applicant respectfully submits that Qian fails to disclose communicating the payment request to the second payment platform based on the determination that the sending user is associated with the first payment platform, as required by independent Claim 21].
This argument is not persuasive, Examiner assert that firstly, Qian teachings is all about a system and method for making payment with payment request all over the prior art. Secondly, examiner has already addressed above the need to not argue against references individually in piecemeal, which the Applicant is conveying in this argument. And lastly, in further response to this argument, see Qian ¶¶ 0028-0029, 0032-0033, and to further support Examiner’s mapping, see also Fig. 3, step 301-307, and also ¶¶ 0078-0079 “The first user 321 sends a request for making a payment to the first payment platform 331. The request includes the first user (321)'s identification, the second user (322)’s federation user ID and the amount of payment” and subsequently, ¶¶ 0080-0083 “…The central account registration system 340 uses the second user's federation user ID to inquire about the second user's federation user account and obtain the related information of the second payment platform 332, Such as information of a system account of the second payment platform 332 and/or information of the platform user account corresponding to the federation user ID of the second user322…” Therefore, Qian discloses a payment request as disclosed.
Therefore, the 103 rejection is hereby maintained.
Claim Interpretation
Finally, the Applicant’s recitation of “…the unique payment token to the first
payment platform for redemption with the second payment platform…” This is intended use. In this case, although the nature of the redeemable element doesn't matter because "for redemption" is an intended use, as the "generating" step isn't complete unless the token has all of the "elements" recited. The recitation of the intended use of the claimed invention does not serve to differentiate the claim from the prior art. See MPEP 2103 I C. This claim interpretation objection has not been addressed yet by the Applicant.
Claim Interpretation
Intended Use
The recitation of the intended use of the claimed invention does not serve to differentiate the claim from the prior art. See MPEP 2103 I C, “… Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation. The following types of claim language may raise a question as to its limiting effect: (A) statements of intended use or field of use...”
Claims 21 and 38, recites “…the unique payment token to the first payment platform for redemption with the second payment platform…”
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 3
U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 21-33, 35 and 37-40 is rejected under 35 U.S.C. 103 as being unpatentable over Kyrylo Oliynyk (US Pat. 10846679 B2) in view of Qian et al., (US 20080082434 A1).
With respect to claims 21 and 38, Oliynyk teaches a method and a computer system
comprising a processor and a memory wherein the memory stores computer executable
instructions and the processor are configured execute the computer executable instructions (Fig. 2-3, item 110 and 120, col 5 line 56-col 6 line 8) for:
receiving, by a service computing device (Fig. 1 item 110, “service provider terminal”), a payment request from the first payment platform, wherein the payment request is generated by a sending user (Fig. 1 item 120, “sender computing device”) via the first payment platform [third-party payment mechanisms (e.g., Zelle, PayPal, or Venmo)] and intended for a receiving user (Fig. 1 item 130, “Recipient computing device”) associated with the second payment platform [third-party payment mechanisms (e.g., Zelle, PayPal, or Venmo)], (Fig. 7, col 12 lines 32-37“… At 725, the service provider terminal 110 parses the message to retrieve instructions for a transfer request. As discussed above, the instructions may direct the service provider terminal 110 to initiate a transfer from the sender (i.e., a user of the sender computing device 120) to the recipient (i.e., a recipient computing device 130)”).
determining, by the service computing device, the sending user is associated with the first payment platform [The service provider terminal 110 (i.e., service computing device) may identify (i.e., determine) a third-party payment mechanism (i.e., payment platform) with which both the sender and receiver have an account” col 14:50–53].
based on determining that the sending user is associated with the first payment platform:
based on identifying the second payment platform, generating, by the service computing device, a unique payment token comprising a redeemable element [verification code 524 may be a hash value (i.e., payment token) created based on one or more … recipient contact information 516 (col 9:32–36); The verification code 524 may be a hash value (i.e., payment token) calculated based on, as non-limiting examples … the recipient computing device 130. (i.e., based on identifying the second payment platform) (col 10:50–59 [For example, the validation code may be generated … [and] received by the sender computing device 120 from the financial institution associated with the service provider terminal 110 (i.e., generated by the service computing device”. As discussed above, in some cases, the validation code may be a hash value (i.e., payment token) of one or more aspects associated with the request. col 12:51–56)], and
communicating, from the service computing device, the unique payment token to the first payment platform for redemption with the second payment platform based on the redeemable element [For example, the validation code may be generated … [and] received by the sender computing device 120 from the financial institution associated with the service provider terminal 110 (i.e., communicated to the sender computer device by the service computing device). As discussed above, in some cases, the validation code may be a hash value (i.e., payment token) of one or more aspects
associated with the request. (col 12:51–56)].
Oliynyk does not explicitly disclose, however, Qian discloses identifying the second payment platform, wherein the second payment platform is different than the first payment platform (see at least ¶ 0020 “…For example, the account information of the second payment platform provided to the first payment platform may include information of a system account of the second payment platform, and/or information of a platform user account of the second user in the second payment platform corresponding to the second user's federation user ID. If the first payment platform only needs to contact a system account of the second payment platform, the information of the second user's platform user account in the second payment platform may not be needed. Likewise, if the first payment platform only needs to contact the second user's platform user account in the second payment platform, the information of the system account of the second payment platform may not be needed. In either case, it is preferred that the second user's federation user ID and its corresponding platform user ID or platform account information in the second payment platform be made available, such that an item (such as a payment deposit) sent by the first payment platform to the second payment platform may be properly identified and associated with the correct user (the second user in this example)” and also , ¶¶ 0028-0033), and
communicating the payment request to the second payment platform (see at least ¶¶ 0028-0029 “transferring the payment from the system account of the first payment platform to a system account of the second payment platform”, and also ¶ 0031 “The second payment platform is adapted for transferring the payment from a system account of the second payment platform to an account of the second user. The
account of the second user may be either a platform user account”, and ¶¶ 0032-0033, see also Fig. 3, step 301-307, and also ¶¶ 0078-0079 “The first user 321 sends a request for making a payment to the first payment platform 331. The request includes the first user (321)'s identification, the second user (322)’s federation user ID and the amount of payment” and subsequently, ¶¶ 0080-0083 “…The central account registration system 340 uses the second user's federation user ID to inquire about the second user's federation user account and obtain the related information of the second payment platform 332, Such as information of a system account of the second payment platform 332 and/or information of the platform user account corresponding to the federation user ID of the second user322…”).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Oliynyk to include the elements of Qian. One would have been motivated to do so, in order to have separate payment platforms involve in a payment transaction between a sender and a receiver. Furthermore, Oliynyk discloses having a peer-to-peer payment transaction system. Qian is merely relied upon to illustrate the functionality of involving separate payment platforms in a payment transaction between a sender and a receiver, in the same or similar context. Because both having a peer-to-peer payment transaction system, as well as involving separate payment platforms in a payment transaction between a sender and a receiver, are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Oliynyk, as well as Qian would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Oliynyk/Qian.
With respect to claim 22, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 21 above.
Furthermore, Oliynyk discloses further comprising: receiving, at the service
computing device from the second payment platform, a request for validation including
the unique payment token (col 15 line 50 “...the service provider terminal 110 may identify a third-party payment mechanism with which both the sender and receiver have an account, the service provider terminal 110 may generate a private message (and contact the recipient using the private message) that inquires whether the recipient would like to receive payment using the identified third-party payment mechanism...” col 14 line 46-col 15 line 12).
validating the unique payment token at the service computing device (col 12 line 56-60 “…the validation code (i.e., payment token) may be a hash value of one or more aspects associated with the request. The service provider terminal 110 may parse the group message 500 to identify the validation code and verify the code , for example , by comparing the code to a stored or calculated value”, col 14 line 46-col 15 line 12), and
communicating the validation from the service computing device to the second payment platform (col 14 line 46-col 15 line 12).
With respect to claim 23, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 21 above.
Furthermore, Oliynyk discloses, wherein the payment request is translated into a protected payment request (col 9 lines 32-36, “…the verification code 524 may be a hash value created based on one or more of a time of submission, a transfer amount, sender contact information 512, recipient contact information 516, and an account associated with the sender contact information 512”, col 10 lines 45-59, col 12 lines 1-14).
With respect to claim 24, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 21 above.
Furthermore, Oliynyk discloses, wherein the payment request comprises at least one of: a payment amount, a receiver ID, a sender ID, or a payment platform ID (“a transfer amount”, col 2 lines 5-7).
With respect to claim 25, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 21 above.
Furthermore, Oliynyk discloses, wherein the sender ID comprises at least one of an email address, a phone number and an account number (col 9 lines 22-42).
With respect to claim 26, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 21 above.
Furthermore, Oliynyk discloses, wherein confirming that the sending user is associated with the first payment platform comprises comparing the sender ID to known user IDs that are associated with the first payment platform (Fig. 4 step 410-415, col 9 lines 10-63).
With respect to claim 27, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 21 above.
Furthermore, Qian discloses, wherein identifying the second payment platform
comprises searching a user database for the receiver ID, the user database including
matches of known users with a plurality of additional payment platforms including the second payment platform (see at least ¶ 0025 “…a payment system which has multiple payment platforms including a first platform and a second platform, and a central account registration system connecting the payment platforms to form an account federation. The central account registration system stores account mapping information between a federation user account and a platform user account, and assigns a federation user ID to each federation user account. Upon receiving from the first payment platform an operation request of a first user, the central account registration system provides account information of the second payment platform to the first payment platform according to a second user's federation user ID included with the operation request of the first user. The payment system then makes a payment according to the provided account information of the second payment platform”}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Oliynyk to include the elements of Qian. One would have been motivated to do so, in order to have separate payment platforms involve in a payment transaction between a sender and a receiver. Furthermore, Oliynyk discloses having a peer-to-peer payment transaction system. Qian is merely relied upon to illustrate the functionality of involving separate payment platforms in a payment transaction between a sender and a receiver, in the same or similar context. Because both having a peer-to-peer payment transaction system, as well as involving separate payment platforms in a payment transaction between a sender and a receiver, are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Oliynyk, as well as Qian would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Oliynyk/Qian.
With respect to claim 28, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 21 above.
Furthermore, Oliynyk discloses, wherein the unique payment token comprises at least the receiver ID and the payment amount of the payment request (col 9 lines 32-36, “…the verification code 524 may be a hash value created based on one or more of a time of submission, a transfer amount, sender contact information 512, recipient contact information 516, and an account associated with the sender contact information 512”, col 10 lines 45-59, col 12 lines 1-14).
With respect to claims 29 and 40, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 21 and 38 above, respectively.
Furthermore, Oliynyk discloses, wherein communicating the unique payment token to the first payment platform is for delivery to a first computing device associated with the sending user, wherein the first computing device communicates the unique payment token to a second computing device associated with the receiving user and the second computing device redeems the token (col 12 line 56-60, col 10 lines 45-59, col 12 lines 1-14).
With respect to claim 30, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 21 above.
Furthermore, Oliynyk discloses, further comprising communicating the payment amount to a second computing device associated with the receiving user (col 10 lines 45-59).
With respect to claim 31, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 21 above.
Furthermore, Oliynyk discloses, wherein the token is configured to be communicated to a second computing device using a different communication channel (col 10 lines 45-59, col 12 lines 1-14).
With respect to claim 32, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 21 above.
Furthermore, Oliynyk discloses, wherein the token is configured for submission by the receiving user to the second payment platform for payment (col 13 lines 22-38).
With respect to claim 33, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 21 above.
Furthermore, Qian discloses, further comprising determining, by the service computing device, whether the receiving user is an authorized user of the second payment platform (see at least ¶¶ 0028-0029 “transferring the payment from the system account of the first payment platform to a system account of the second payment platform”, and also ¶ 0031 “The second payment platform is adapted for transferring the payment from a system account of the second payment platform to an account of the second user. The account of the second user may be either a platform user account”, and ¶¶ 0032-0033).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Oliynyk to include the elements of Qian. One would have been motivated to do so, in order to have separate payment platforms involve in a payment transaction between a sender and a receiver. Furthermore, Oliynyk discloses having a peer-to-peer payment transaction system. Qian is merely relied upon to illustrate the functionality of involving separate payment platforms in a payment transaction between a sender and a receiver, in the same or similar context. Because both having a peer-to-peer payment transaction system, as well as involving separate payment platforms in a payment transaction between a sender and a receiver, are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Oliynyk, as well as Qian would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Oliynyk/Qian.
With respect to claim 35, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 21 above.
Furthermore, Oliynyk discloses, further comprising offering the receiving user a debit card for a payment amount associated with the payment request (col 13 lines 22-38, line 59-col 14 line 2).
With respect to claim 37, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 21 above.
Furthermore, Oliynyk discloses, wherein the sender ID further comprises at least one of: a hash of an email registered with a payment platform; a hash of a phone number registered with the payment platform; a single digit to indicate when users registered with the payment platform for a first time; a county indication; a state indication; a transaction location of a user; or a know your customer indication (col 9 lines 20-36).
With respect to claim 39, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 38 above.
Furthermore, Oliynyk discloses, further comprising: receiving, from the second payment platform, a request for validation including the unique payment token and a
receiver ID (col 13 lines 22-38 “At 750 the service provider terminal 110 receives payment reception information from the recipient according to the instructions in the private message. In some cases, the recipient navigates to the dynamic webpage using the recipient computing device 130 and enters payment information into the dedicated fields . As non - limiting examples, the recipient may request… the funds be received through one or more third - party payment mechanisms (e.g., Zelle, Pay-Pal, or Venmo) or platforms)…”).
validating the unique payment token; and communicating the validation to the second payment platform (col 12 line 56-60).
Claim 34, is rejected under 35 U.S.C. 103 as being unpatentable over Kyrylo Oliynyk (US Pat. 10846679 B2) in view of Qian et al., (US 20080082434 A1), and further in view of Bouey et al., (US 2013/0238488 A1).
With respect to claim 34, Oliynyk in view Qian teaches all the subject matter as disclosed in claim 33 above, but does not explicitly disclose further comprising: determining, by the service computing device, the receiving user is an unauthorized user of the second payment platform; and based on determining that the receiving user is an unauthorized user of the second payment platform, inviting the receiving user to join a payment platform.
However, Bouey discloses further comprising: determining, by the service computing device, the receiving user is an unauthorized user of the second payment platform; and based on determining that the receiving user is an unauthorized user of
the second payment platform, inviting the receiving user to join a payment platform (¶ 0057 “If, after the search of other payment networks is completed, no other payment network is identified at which the recipient is registered, then the recipient is presumed to not be a registered user of any payment network. Accordingly, at step 341, an invitation is sent to the recipient to invite the recipient to join the payment network...” and also ¶ 0058).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Oliynyk in view of Qian to include the elements of Bouey. One would have been motivated to do so, in order to have payment network registration interface. Furthermore, Oliynyk discloses having a peer-to-peer payment transaction system, and Qian discloses involving separate payment platforms in a payment transaction between a sender and a receiver. Bouey is merely relied upon to illustrate the functionality of having a payment network registration interface, in the same or similar context. Because both having a peer-to-peer payment transaction system, and involving separate payment platforms in a payment transaction between a sender and a receiver as well as, having a payment network registration interface, are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Oliynyk in view of Qian, as well as Bouey would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Oliynyk/Qian/Bouey.
Claim 36, is rejected under 35 U.S.C. 103 as being unpatentable over Kyrylo Oliynyk (US Pat. 10846679 B2) in view of Qian et al., (US 20080082434 A1), and further in view of Bouey et al., (US 2013/0238488 A1) and Burgess et al., (US
20170116615 A1).
With respect to claim 36, the combination of Oliynyk and Qian in view of Bouey discloses all the subject matter as disclosed in claim 21.
Furthermore, Bouey discloses further comprising “adding a payment platform to the service computing device...” (¶¶ 0057-0058).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Oliynyk in view of Qian to include the elements of Bouey. One would have been motivated to do so, in order to have payment network registration interface. Furthermore, Oliynyk discloses having a peer-to-peer payment transaction system, and Qian discloses involving separate payment platforms in a payment transaction between a sender and a receiver. Bouey is merely relied upon to illustrate the functionality of having a payment network registration interface, in the same or similar context. Because both having a peer-to-peer payment transaction system, and involving separate payment platforms in a payment transaction between a sender and a receiver as well as, having a payment network registration interface, are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Oliynyk in view of Qian, as well as Bouey would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over
Oliynyk/Qian/Bouey.
The combination of Oliynyk and Qian, in view of Bouey does not explicitly disclose “...using key exchange encryption to communicate necessary on-boarding information”
However, Burgess discloses “...using key exchange encryption to communicate necessary on-boarding information” (¶¶ 0051-0052, 0067).
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify Oliynyk and Qian in view of Bouey to include the elements of Burgess. One would have been motivated to do so, in order to add other payment network (“IdM”) associated with sender’s payment platform, using key encryption. Furthermore, Oliynyk discloses having a peer-to-peer payment transaction system, Qian discloses involving separate payment platforms in a payment transaction between a sender and a receiver, and Bouey discloses having a payment network registration interface. Burgess is merely relied upon to illustrate the functionality of adding other payment network (“IdM”) associated with sender’s payment platform, using key encryption. Because both having a peer-to-peer payment transaction system, involving separate payment platforms in a payment transaction between a sender and a receiver, and having a payment network registration interface, as well as, add other payment network (“IdM”) associated with sender’s payment platform, using key encryption, are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Oliynyk and Qian in view of Bouey, as well as Burgess would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Oliynyk/Qian/Bouey/Burgess.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon:
1) (US 20130211967 A1) – Ian Charles Ogilvy, Ordering and Payment systems – relates to improved ordering and payment systems for ordering and paying for products, and, particularly, but not exclusively, to improved ordering and payment systems for facilitating retailing via computer networks, ouch as the Internet.
2) (US 20200013028 A1) – Black et al., Peer-To-Peer Money Transfer – relates to financial transactions, and more specifically, to a peer-to-peer
money transfer system.
3) (US 20220020016 A1) – Scott et al., Secure Processing of Electronic Payments – relates generally to the secure execution of electronic signal exchanges, and more particularly to improved systems, methods, and programming structures for the secure negotiation, authorization, execution, and confirmation of multi-party and multi-device data processes.
4) (US 20050222961 A1) – Staib et al., System And Method Of Facilitating Contactless Payment Transactions Across Different Payment Systems Using A Common Mobile Device Acting As A Stored Value Device - relates to mobile commerce, and more particularly electronic payment systems for portable devices that act as smart cards. Abstract – “…A service application running in a service operator computer communicates with the various contactless payment systems to facilitate the settlement of the amount owed to various payment systems by the one payment system associated with the mobile device”.
5) (US 20150286997 A1) - Zimmerman et al., Routing Payments to payment Aggregators – relate generally to processing payments. More specifically, one or more embodiments relate to methods and systems of processing payments using payment aggregators.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT IDIAKE whose telephone number is (571)272-1284. The examiner can normally be reached on Mon-Fri from 10:30AM to
7:30PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICK MCATEE, can be reached at telephone number (571)272-7575. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form.
/V.I./Examiner, Art Unit 3698 /PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698