DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 08/14/2026 has been entered.
Status of Claims
The following is a Non-Final Office Action in response to Applicant’s amendments filed on 08/14/2026.
a. Claims 11, 16 are amended
b. Claims 1-10, 15, 19-20 were previously cancelled
Overall, Claims 11-14, 16-18 are pending and have been considered below.
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.
Claim 17 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.
Claim 17 recites “wherein rendering the first sub-screen further includes rendering the first sub-screen further includes rendering the first sub-screen alongside options and information of the transaction splash screen”. The claim recitation “further includes rendering the first sub-screen further includes rendering” creates a grammatically incomplete limitation. It is unclear whether Applicant intends to recite a single additional rendering step, multiple rendering steps or the relationship between the first sub-screen and the information on the transaction splash-screen. Additionally, one of skilled in the art would not be able to determine the metes and bounds of the claimed subject matter.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 17 rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Claim 17 recites “wherein rendering the first sub-screen further includes rendering the first sub-screen further includes rendering the first sub-screen alongside options and information of the transaction splash screen”. And claim 16 recites the limitation “wherein rendering the first sub-screen further includes rendering the first sub-screen alongside options and information of the transaction splash screen”. Claim 17, which depends on claim 16, recites the same limitation and does not further limit claim 16. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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 (i.e., changing from AIA to pre-AIA ) 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 should not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claims 11, 14, 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Jain (WO 2023012530 A1) in view of Bagdonas (US 20150019356 A1), in further view of Rose (US 20210176340 A1).
Regarding Claim 11. Jain discloses:
A method, comprising: receiving a wallet identifier for a charity wallet and a link to a summary page for a charity associated with the charity wallet; [(00152) The system 10 may also include the following feature: News Feed - this will show information from the charitable or religious organisations the user is following and donating to, providing insight into the usage of their donated funds and other updates]
rendering, by a donation agent, donation screens associated with donating to the charity on a display of a terminal overlaid on top of transaction screens during a transaction at the terminal, … of the terminal that identifies the charity or a type of charity, and …[see at least (0024) Preferably, the donation device is adapted to execute a POS terminal application for donation transactions and communication with the server 16.(0063) Figure 2 schematic diagram of a donation device in the donation system of Figure 1. (0064) Figure 3 schematic diagram of another donation device in the donation system of Figure 1. (00109) The donation device 200 … enable the end-user (Donors) to make a purchase and can then round up the purchase amount to $1, $5, $10 so the round-up amount can be donated to the charity or religious organization. (reads on: the donation screen is rendered after the user makes the selection to round-up the purchase amount)]
wherein rendering further includes: overlaying, by the donation agent, a donation entry screen on top of the transaction screens in response to selection of the first sub-screen, [see at least Fig. 3, (0079) the donation device 200 as shown in Figure 3 is adapted to execute a POS terminal application for donation transactions and communication with the server 16.]
… the donation entry screen including a touch keypad for entry of a donation amount [(00103) the donation device 100, 200 comprises a touch screen. In one embodiment, the donation device 100, 200 comprises a keypad. In another embodiment, the donation device 100, 200 comprises one or more Camera and/or Scanners for scanning images, barcodes, or carry out facial recognition. Further, the donation device 100, 200 may comprise an in-display 2D / 3D fingerprints scanner for reading fingerprints from the touchscreen]
processing, by the donation agent, one or more options of the donation entry screen to receive a customer selection accepting payment of a particular donation amount entered using the touch keypad; [see at least Fig. 3 (0095) Figure 3, there is provide a schematic diagram of a donation device 200. (00103) the donation device 100, 200 comprises a keypad. The donation device 200 will then prompt the user to enter the donation amount in step 252. After receiving the amount, the donation device 200 will prompt the user to select the donation frequency. The user can select either a one-off donation in step 254 or a recurrent donation frequency such as such as weekly, fortnightly, monthly, quarterly or yearly in 256.]
Note: MPEP 2144.01 sets forth that it is proper to take into account not only specific
teachings of the reference but also the inferences which one skilled in the art would reasonably be expected to draw therefrom. Here, it is reasonable to infer that in order for the user to enter donation amount, the user would need to use the keypad to enter the donation amount. And therefore, one of skill in the art would have understood the reference to teach the limitation.
reporting the particular donation amount received from the donation entry screen to a transaction manager of the terminal, wherein the donation agent communicates with the transaction manager through an API call to add a line item to a transaction running total for a charitable donation; and [see at least (0096) The donation device 100, 200 and server 16 may exchange and access data using an API gateway authorisation with JWT tokenisation. (reads on: the donation device uses an API) (00121) the donation device 200 will calculate the final purchase price based on both the purchase amount and the donation amount and display the final price along with other payment details on the donation device 200 in Step 285. The user may then proceed or amend the payment details.]
Jain discloses performing donation during the POS transaction; however, Jain does not disclose:
wherein the donation screens are rendered independent and separate from transaction workflow screens of the terminal,
wherein rendering the donation screens includes rendering a first sub-screen on a transaction splash screen …
maintaining the first sub-screen within a transaction interface to occupy unused space of the transaction screens as the transaction screens change during the transaction;
wherein rendering further includes: overlaying …, a … screen on top of the transaction screens in response to selection of the first sub-screen,
and displaying a transaction fee and an automatically converted equivalent amount of cryptocurrency for the transaction fee; and
providing the wallet identifier and the particular donation amount to a server, the server purchasing a second amount of cryptocurrency using a fiat currency associated with the particular donation amount
and the server transferring the second amount of cryptocurrency from a server wallet to the charity wallet over a blockchain.
Nonetheless, Bagdonas discloses rendering an independent overlay on a POS transaction screen:
wherein the donation screens are rendered independent and separate from transaction workflow screens of the terminal, [(0013) These systems and methodologies create an overlay or floating window which floats over the main screen in a POS, and which provides a platform for the display of additional business data. Advantageously, the overlay is movable about the screen, and the user may interact with features on the main window of the POS which are not covered by the overlay without causing the overlay to close or to lose focus. Moreover, the software which creates the overlay operates independently of other applications running on the POS system, and hence does not require any customization to the POS system software or hardware.]
wherein rendering the donation screens includes rendering a first sub-screen on a transaction splash screen … [see at least Fig. 4 (0016) the POS terminal 101 depicted includes a touch screen 103 having a main window 105 rendered thereon within which may be found the typical contents of a POS terminal. Thus, for example, the main window 105 may comprise various buttons, text, links, images, or other features which allow the user to interact with the POS terminal]
maintaining the first sub-screen within a transaction interface to occupy unused space of the transaction screens as the transaction screens change during the transaction; [(0018) The button 107 is repositionable to any desired position on the on the main window 105. The button 107 … may be dynamically repositioned by the software (e.g., by analyzing features in the underlying window). As an example of the later, the software may be configured to reposition the button 107 as necessary so that it avoids overlapping objects on the underlying screen, or by positioning the button 107 as necessary so that any such overlap is minimal.]
wherein rendering further includes: overlaying …, a … screen on top of the transaction screens in response to selection of the first sub-screen, [(0019) the button 107 launches or expands into an overlay 109 or floating window within which content may be displayed. The overlay may be any desired size, and may even be larger than the apparent size of the physical screen. The overlay and/or any content contained therein may be displayed immediately upon selection of the button 107, or an animation may be provided to transition from the button 107 to the final appearance of the overlay 109.]
In addition, 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 the POS donation service of Jain to include the screen overlaying features of Bagdonas. A person a having the ordinary skill in the art would have been motivated to implement Jain’s charitable functionality using the independent POS overlay technique of Bagdonas in order to provide the additional charitable options while allowing the underlaying POS transaction interface to remain available to the user. Accordingly, the claimed subject matter is obvious over Jain in view of Bagdonas.
The combination of Jain in view of Bagdonas discloses performing charitable donation through a POS transaction. However, the above combination of Jain, Bagdonas does not disclose:
and displaying a transaction fee and an automatically converted equivalent amount of cryptocurrency for the transaction fee; and
providing the wallet identifier and the particular … amount to a server, the server purchasing a second amount of cryptocurrency using a fiat currency associated with the … amount
and the server transferring the second amount of cryptocurrency from a server wallet to the … wallet over a blockchain.
Nonetheless, Rose discloses determining and converting fiat currency to equivalent amount of cryptocurrency:
and displaying a transaction fee and an automatically converted equivalent amount of cryptocurrency for the transaction fee; and [see at least (0464) the operator terminals or points of sale may be associated with a virtual currency wallet address. (0466) when a transaction occurs for USD $100, a vendor may be owed a fee of USD $1.00. A virtual currency exchange may be queried at the time of the transaction to determine, for example, the exchange rate for the virtual currency. In one example, Bitcoin may be the virtual currency. If a virtual currency exchange is queried and it is determined that the exchange rate for Bitcoin is $10,000, then a $1.00 fee would be equal to $1.00/$10,000.00 Bitcoin, or 0.0001 Bitcoin, for example. This fee value may be stored in a database or datastore, for example. The fee may be charged immediately, or at a later point in time. (0470) if a virtual currency exchange is queried and it is determined that the exchange rate for Bitcoin is $10,000, then a $10.00 fee amount would be equal to $10.00/$10,000.00 Bitcoin, or 0.001 Bitcoin, for example. Therefore, to purchase 0.01 Bitcoin, a customer may be required to deposit USD $110.00 at the given time]
providing the wallet identifier and the particular … amount to a server, [see at least (0101) multi-signature wallets, wallet balance listing/querying, transaction listing/querying, transaction creation and/or signing, transaction monitoring, transaction notifications, secure user authentication, multi-user workflows for use in enterprise environments, policies, spending limits, etc. Multi-signature wallets require the cooperation of multiple parties to approve a transaction by requiring signing and/or keys from each party. (0105) an operator may be allowed to enter credentials and/or authentication or access information in, for example, an operator GUI and/or account portal, that allows a software service provider to access the credentials and/or information to orchestrate transactions. In some examples, credentials and/or authentication or access information may include one or more of any of API keys, wallet credentials … wallet identifiers, account identifiers, or other identifying information, etc.]
… the server purchasing a second amount of cryptocurrency using a fiat currency … [see at least (0100) a user may be prompted, requested, or given the opportunity or option to provide a credit card, or a debit card connected to the user's bank account, for example, to fund the purchase of a virtual currency or cryptocurrency … cash from the user's bank account may then be debited and utilized to allow the purchase of cryptocurrency. (0103) a software service may request the purchase of an appropriate virtual or digital currency from an exchange. Payment may be delivered directly, or through the software service provider, to the exchange.]
and the server transferring the second amount of cryptocurrency from a server wallet to the … wallet over a blockchain. [see at least (0104) a transaction may request an operator to deliver virtual or digital currency from an operator wallet to a customer wallet. (0154) virtual currency transactions may use wallets and services to record and/or execute transactions using the blockchain and allowing the transfer of virtual currency.]
In addition, 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 POS donation service of Jain in view of Bagdonas to include currency conversion of Rose. A person a having the ordinary skill in the art would have been motivated to incorporate the conversion from fiat currency to cryptocurrency of Rose into the charitable donation transaction of Jain in view of Bagdonas, in order to permit the charitable donation to be settled using cryptocurrency. Accordingly, the claimed subject matter is obvious over Jain, in view of Bagdonas, in further view of Rose.
Regarding Claim 14. Jain, Bagdonas, Rose discloses the limitations of Claim 11. Jain further discloses:
wherein receiving further includes obtaining the summary page using the link and rendering the summary page in the donation screens. [(00152) The system 10 may also include the following feature: News Feed - this will show information from the charitable or religious organisations the user is following and donating to, providing insight into the usage of their donated funds and other updates.]
Regarding Claim 16. Jain, Bagdonas, Rose discloses the limitations of Claim 11. Bagdonas further discloses:
wherein rendering the first sub-screen further includes rendering the first sub-screen alongside options and information of the transaction splash screen. [see at least Fig. 4 and (0016) the POS terminal 101 depicted includes a touch screen 103 having a main window 105 rendered thereon within which may be found the typical contents of a POS terminal. Thus, for example, the main window 105 may comprise various buttons, text, links, images, or other features which allow the user to interact with the POS terminal for a particular purpose such as, for example, managing a restaurant.]
In addition, 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 the POS donation service of Jain, in view Bagdonas, in further view of Rose to include the screen overlaying features of Bagdonas. A person a having the ordinary skill in the art would have been motivated to implement Jain’s charitable functionality using the independent POS overlay technique of Bagdonas in order to provide the additional charitable options while allowing the underlaying POS transaction interface to remain available to the user. Accordingly, the claimed subject matter is obvious over Jain, in view of Bagdonas, in further view of Rose.
Regarding Claim 17. Jain, Bagdonas, Rose discloses the limitations of Claim 11. Bagdonas further discloses:
wherein rendering the first sub-screen further includes rendering the first sub-screen further includes rendering the first sub-screen alongside options and information of the transaction splash screen [see at least Fig. 4 and (0016) the POS terminal 101 depicted includes a touch screen 103 having a main window 105 rendered thereon within which may be found the typical contents of a POS terminal. Thus, for example, the main window 105 may comprise various buttons, text, links, images, or other features which allow the user to interact with the POS terminal for a particular purpose such as, for example, managing a restaurant.]
In addition, 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 the POS donation service of Jain, in view Bagdonas, in further view of Rose to include the screen overlaying features of Bagdonas. A person a having the ordinary skill in the art would have been motivated to implement Jain’s charitable functionality using the independent POS overlay technique of Bagdonas in order to provide the additional charitable options while allowing the underlaying POS transaction interface to remain available to the user. Accordingly, the claimed subject matter is obvious over Jain, in view of Bagdonas, in further view of Rose.
Claims 12-13, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Jain, in view of Bagdonas, in further view of Rose, as applied to claim 11 above, and further in view of Sobhani (US 20150006426 A1).
Regarding Claim 12. Jain, Bagdonas, Rose discloses the limitations of Claim 11. The combination of Jain, in view of Bagdonas, in further view of Rose discloses performing donation on a POS machine. However, the above combination Jain, Bagdonas, Rose does not disclose:
receiving a new wallet identifier for a new wallet of a new charity and a new link to a new summary page for the new charity from the server; and
replacing the wallet identifier and the link with the new wallet identifier and the new link for subsequent transactions on the terminal.
However, Sobhani discloses receiving wallet identifier:
receiving a new wallet identifier for a new wallet of a new charity and a new link to a new summary page for the new charity from the server; and [see at least (0174) FIG. 1 is for one embodiment, as an example, for method of consumer/user choosing a charity for directing donation. The user can add more to the donation. The money comes from the store or merchant. The user is sent an invitation to join our charity network.]
replacing the wallet identifier and the link with the new wallet identifier and the new link for subsequent transactions on the terminal. [see at least (0174) FIG. 1 is for one embodiment, as an example, for method of consumer/user choosing a charity for directing donation. The user can add more to the donation. The money comes from the store or merchant. The user is sent an invitation to join our charity network.]
In addition, 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 the POS donation features of Jain, in view of Bagdonas, in further view of Rose to include the selectable charities feature of Sobhani, in order to allow the user to donate to the charity of their choosing. Accordingly, the claimed subject matter is obvious over Jain, in view Bagdonas, in further view of Rose, in further view of Sobhani.
Regarding Claim 13. Jain, Bagdonas, Rose, Sobhani discloses the limitations of Claim 12. Sobhani further discloses:
iterating to the rendering for each subsequent transaction. [see at least (0181) An embodiment, as for example depicted in FIG. 7b, a donation interface is displayed to the customer after the checkout confirmation. (0181) In one embodiment, as for example depicted in FIG. 7 c, the donation interface is displayed after the checkout process]
In addition, 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 the POS donation features of Jain, in view of Bagdonas, in further view of Rose, in further view of Sobhani to include additional selectable charities feature of Sobhani, in order to allow the user to donate to the charity of their choosing. Accordingly, the claimed subject matter is obvious over Jain, in view Bagdonas, in further view of Rose, in further view of Sobhani.
Regarding Claim 18. Jain, Bagdonas, Rose discloses the limitations of Claim 11. The combination of Jain, in view of Bagdonas, in further view of Rose discloses performing donation. However, the above combination of Jain, Bagdonas, Rose does not disclose:
wherein rendering the donation entry screen further includes rendering a predefined number of recent donation amounts made to the charity within the donation entry screen.
Nonetheless, Sobhani discloses:
wherein rendering the donation entry screen further includes rendering a predefined number of recent donation amounts made to the charity within the donation entry screen. [see at least (0177) FIG. 4 is for one embodiment … It shows the recent activities and dates for donations and transactions]
In addition, 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 the POS donation features of Jain, in view of Bagdonas, in further view of Rose to include the selectable charities feature of Sobhani, in order to allow the user to donate to the charity of their choosing. Accordingly, the claimed subject matter is obvious over Jain, in view Bagdonas, in further view of Rose, in further view of Sobhani.
Response to Amendments/Arguments
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 101.
Applicant submits: “in does not teach or suggest these features. Jain describes a donation device that executes a POS terminal application (Jain Figure 3). However, Jain's interface is integrated directly into the sequential steps of the terminal's payment workflow. Lindsay does not disclose a separate donation agent that renders a first sub-screen on a splash screen and maintains that sub-screen in the unused space of the transaction screens as those transaction screens change during the transaction. In Jain, the option to round up or donate is presented as a sequential prompt after the purchase amount is entered (Jain [00120]-[00121]). Furthermore, Jain does not teach or suggest overlaying a donation entry screen that displays a transaction fee and an automatically converted equivalent amount of cryptocurrency for that transaction fee. Jain's donation flow does not involve cryptocurrency conversion at the terminal interface; instead, Jain's server exchanges collected assets or payments for electronic funding that is deposited into a bank account of a charity (Jain Claim 1). Benkreira describes a cryptocurrency wallet management system with cost basis tracking. The interface in Benkreira is a graphical user interface displayed on a user's smartphone, which is invoked by scanning a QR code at a point-of-sale terminal (Benkreira [0060]). Benkreira does not describe a transaction terminal display architecture, let alone a donation agent that renders and maintains a first sub-screen on a terminal's transaction screens as those screens change. Additionally, the cryptocurrency conversion in Benkreira is functionally and structurally distinct from the conversion recited in Claim 11. Benkreira performs a cryptocurrency-to-fiat conversion to enable a user to spend pre-existing cryptocurrency from their own wallet and to compute a taxable gain against a per-unit cost basis (Benkreira [0011], [0048]). In contrast, Claim 11 performs a fiat-to-cryptocurrency conversion. The customer pays fiat currency as a line item in a retail transaction, and the server uses that fiat currency to purchase cryptocurrency into a server wallet for onward wallet-to-wallet transfer to the charity's wallet over a blockchain. The customer in Claim 11 does not hold cryptocurrency, does not have a cryptocurrency wallet, and does not trigger a taxable disposition. Benkreira does not teach or suggest displaying a transaction fee and its automatically converted cryptocurrency equivalent on a terminal's donation entry screen prior to donation entry. A person of ordinary skill in the art would not have been motivated to combine these references to arrive at the claimed invention. Lindsay's terminal operates in a secure kiosk mode where only one application operates at any given time, preventing the execution of separate, concurrent applications on the terminal (Lindsay [0045]). This teaches away from the claimed architecture where an independent donation agent renders and maintains screens overlaid on top of changing transaction screens managed by a distinct transaction manager. Because Benkreira's interface is located on a separate user device rather than the terminal itself, Benkreira provides no guidance on how to implement a non-interfering, persistent overlay interface on a terminal display.”
Examiner Responds: Examiner has fully considered, but does not find Applicant’s argument persuasive. Examiner points out, in light of Applicant’s amendments, the Examiner has cited two new references (i.e., Bagdonas, Rose). The updated rejection of claim 11 now cites Jain, in view of Bagdonas, in further view of Rose. The Jain reference expressly discloses performing donation in a POS terminal. The Bagdonas reference expressly discloses user selectable objects on the display, and further discloses the overlays operate independently of the other application. Although, the Examiner does not concede to Applicant’s summary of the Benkreira reference, Examiner cites the Rose reference. The Rose reference discloses converting (i.e., purchasing) fiat currency to cryptocurrency. The combination of Jain, in view Bagdonas, in further view of Rose discloses the claim limitations of claim 11. Thus, the rejection has been maintained.
Applicant submits: “Accordingly, Claim 11 is patentable over the combination of Jain and Benkreira. Claims 14, 16, and 17 depend from Claim 11 and are patentable for the same reasons. Claims 12-13 and 18 stand rejected under 35 U.S.C. 103 over Jain in view of Benkreira, and further in view of Sobhani (US 2015/0006426 Al). Claims 12-13 and 18 were rejected under 35 U.S.C. § 103 over Jain (W02023012530) in view of Benkreira (U.S. 2022/0067675) in view of Sobhani (U.S. 2015/0006426). Based on the amendments and remarks presented above with the corresponding independent claims to these rejected dependent claims, Applicant believes that these rejected dependent claims are now in condition for allowance and respectfully requests an indication of the same from the Examiner.”
Examiner response: Examiner has fully considered, but does not find Applicant’s argument persuasive. The dependent claims 12-14, 16-18 remain by virtue of dependency, and art rejection. See updated rejection above. The rejection has been maintained.
Relevant Prior Art Not Relied Upon
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20200311790 A1 Keren; Yoav System, Device, and Method of Protected Electronic Commerce and Electronic Financial Transactions - [0159] In some embodiments, the method comprises: (i) analyzing content and meta-data of an online venue that receives cryptocurrency payments into a cryptocurrency wallet; and detecting a mismatch between (I) the actual identity of the real-life holder of said cryptocurrency wallet, and (II) the identity of the real-life owner of said online venue; (ii) based on said mismatch, notifying an end-user that said online venue, which receives cryptocurrency payments into said cryptocurrency wallet, is fraudulent. For example, the system may examine the website “My-Best-Coin.com” which publishes an ICO for a new coin, and requests payment into a particular crypto wallet; and may further obtain data that this particular crypto wallet is actually owned in real life by “Tai Ching”, whereas that website is owned by “John Smith”; and the mismatch may (in some implementations) be sufficient to raise a possible-fraud flag and to notify the end-user that the crypto wallet may not necessarily belong to the true owner of that website or domain.
US 20050021353 A1 Aviles, Karen et al. DONATION SYSTEM AND METHOD - The present invention includes an automatic bill payment enrollment system for recurring donations, which allows donors to automatically charge charitable donations on a recurring basis to a financial account. In one embodiment, the invention uses a donation portal having various webpages to allow a donor to donate to all U.S. 501(c)(3) organizations. In an alternative embodiment, a donor may donate to any other desired organizations. The system may also incorporate a filter for restricting monies being sent to terrorist organizations. The invention also includes a loyalty point system, wherein loyalty points may be donated to a charity. In another exemplary embodiment, the invention also facilitates employee gift matching.
US 20240119792 A1 TIETZEN; Terrance Patrick et al. Wagerer Directed Donee Donation Defined By Bookmaker Donor - If a wagerer places a wager with a booking entity and if the possible outcome actually occurs such that the wagerer wins the wager, and if the possible outcome actually occurred at a time when the probability of the possible outcome actually occurring as set by the booking entity did not exceed a predetermined winning odds threshold, then the booking entity makes a donation to an affinity entity selected by the wagerer, where the donation is an amount derived using a currency amount of the wager, and at least one of the probability of the outcome actually occurring at the time when the outcome actually occurred and the predetermined winning odds threshold.
US 20160034936 A1 BRYANT, III; Thomas et al. SOCIAL-REFERRAL NETWORK METHODS AND APPARATUS - A computer implemented method, apparatus and computer readable medium for monetizing online referral social networks. The online referral social network system confirms a particular online referral social network member indicated in one or more communications for registering a user as having referred the user to the online referral social network is a member of said online referral social network. A referral commission is determined and paid the particular identified referring member.
US 20210166279 A1 LOUW; Elizabeth Katherine et al. SYSTEM AND METHOD FOR IMPLEMENTING A DONATION APPLICATION ON A MOBILE DEVICE - The invention relates to a mobile device that enables a user to send a digital charitable donation to a charity as a standalone transaction. The mobile device comprises: a memory that stores data associated with an account and a user; a microprocessor, executing a mobile application, the processor coupled to memory and programmed to: identify whether the mobile device is near the charitable organization based on location proximity (e.g., geofence or other boundary); display a prompt on the mobile device to send a digital donation to a receiving device associated with the charitable organization in response to the mobile device's proximity to the charitable organization; identify a donation amount for the charitable organization; receive a confirmation message informing the charitable organization of the donation; and debit the donation amount from an account associated with the user.
US 20220327529 A1 WILLIAMS; RICHARD K. et al. Advanced Transactional Protocols And Ecosystem For Smart Contract Authoring And Deployment - [0170] Because of indistinguishability, tokens do not bestow personal ownership rights or involve identity registration. Tokens used for riding a train or bus do not have the rider's name on them. Anyone can use them. Accordingly, tokens offer the convenience of transferability, easily swapped among friends, bartered for favors, or donated for charitable purposes. Indistinguishability has one downside—it is impossible to determine if a token has been stolen and from whom. For this reason, the security and privacy provisions of crypto wallets holding tokens are of paramount importance to protect token assets from cybertheft.
US 20220067675 A1 Benkreira; Abdelkader et al. SYSTEMS CONFIGURED TO MANAGE CRYPTOCURRENCY WALLETS HAVING COST BASIS TRACKING AND METHODS OF USE THEREOF - Cryptocurrency can be stored in a plurality of cryptocurrency wallets associated with a plurality of respective users and managed by establishing a unit cost basis value for each cryptocurrency unit in a fiat currency. For example, a purchase request is received by a server computer from a user device. The purchase request is associated with a merchant to be paid in a cryptocurrency chosen by a user and stored in a cryptocurrency wallet of the user. A cryptocurrency exchange from multiple cryptocurrency exchanges having the best cryptocurrency exchange rate is identified for converting the chosen cryptocurrency to the fiat currency. A gain for the purchase transaction is calculated when the best cryptocurrency exchange rate is greater than the unit cost basis value of the chosen cryptocurrency stored in the cryptocurrency wallet of the user. The fiat currency converted in the identified cryptocurrency exchange is received from the cryptocurrency exchange to pay the merchant.
US 20210398104 A1 Yan; Jun SYSTEMS AND METHODS FOR STREAMLINING CREDIT AND/OR DEBIT CARD TRANSACTIONS UTILIZING BLOCKCHAIN SUPPORTED CREDIT TOKENS AND/OR DEBIT TOKENS - [0144] FIG. 3E illustrates an example interactive interface of an example web application dashboard including a digital wallet, as may be presented via a display of a node (e.g., a UNode), in accordance with one or more embodiments of the present disclosure. As noted above in connection with FIG. 3D, as shown in FIG. 3E the overview of recent transactions displayed through the web application dashboard 305 may remove certain information from immediate viewing. For instance, in FIG. 3E, the recent transactions shown within the window do not display the wallet ID address of the other party with whom the user was transacting.
US 20140136300 A1 Tietzen; Terrance Patrick et al. AUTHORIZED TRANSACTION INCENTED BY MERCHANT DONATION - [0112] For screen shots 402-504, input and selection of data for each charity can be via a typical user experience including but not limited to keyboard data entry, pull down menus, pictograph optical scanning with a cellular telephony device as read from print or electronic media rendering, etc. Horizontal 418, 518 and vertical 420, 520 panning icons can be user activated to move the rendered display, respectively, on screen shots 402-504.
US 20180182000 A1 Cook; Angela Ray et al. Systems and Methods for Use in Facilitating Donation Transactions to Payment Accounts - [0021] In addition, the computing device 200 includes an input device 208 that receives inputs from the user (i.e., user inputs) such as, for example, selections of charities (e.g., charities 106a-b, etc.), donation amounts, etc. The input device 208 is coupled to (and is in communication with) the processor 202 and may include, for example, one or more of a keyboard, a pointing device, a mouse, a stylus, a camera, a touch sensitive panel (e.g., a touch pad or a touch screen, etc.), and/or other suitable input device. Further, in various exemplary embodiments, a touch screen may behave as both a presentation unit 206 and an input device 208.
US 20230005027 A1 TIETZEN; Terrance Patrick et al. DETECTING AND TRIGGERING A PREVENTATIVE OPERATION MODE CHANGE IN A LOYALTY PROGRAM - [0979] Each participant in the blockchain system has been issued a certificate by a certificate authority server 7102. Each participant is issued a wallet which must be re-authenticated and re-set prior to connecting with an authentication server 7104. These wallets, named after their associated participants, include a consumer (e.g., account holder) wallet 7102, a merchant wallet 7104, and a charity wallet 7106. Each wallet can have settings which limit the type and kind of transaction that is permissible.
US 20210240923 A1 MARTINOV; Vladimir et al. SEAMLESS ADDITION AND REMOVAL OF FORM FIELDS - [0073] FIG. 15 illustrates a previous donations screen 1500 according to an example embodiment. The previous donations screen 1500 may be rendered in response to selecting the link to previous donations shown in FIG. 14. The previous donations screen 1500 may indicate unpaid-pledged donations made by a person/entity. The previous donations screen 1500 may include closed donations section 1502. The closed donations section 1502 may include a closed donation 1510. The closed donation section 1502 may include information about the closed donation such as the amount of the donation and other information about the donation such as donation status, date, account name, or the like. A closed donation corresponds with a donation that corresponds with a signed pledged agreement even if it has not yet been paid. The previous donations screen 1500 may include a prospecting donation section 1504. The prospecting donation section 1504 may include a prospecting donation that may be selected as an expected donation from the person/entity to indicate that the form being filled out corresponds with the prospecting donation. A prospecting donation may be at an earlier stage of donation solicitation (for example a pledge agreement has not yet been signed). In response to the selection of the prospecting donation, the amount of the prospecting donation may be automatically populated in the form.
US 20210366004 A1 KAWASAKI; Takamasa MONEY MANAGEMENT SYSTEM, MONEY MANAGEMENT METHOD, DONATION MANAGEMENT SYSTEM, DONATION MANAGEMENT METHOD AND PROGRAM - [0081] FIG. 2 is a diagram illustrating the management of the flow of donations in the donation management system 10 according to the present embodiment. The donation from the donor 1 is assumed to be deposited into the account 41 of the charity organization 2 at a financial institution (although bank 4 is assumed in this embodiment, it may be another type of financial institution if the institution is able to manage the legal currency). In the donation management system 10 of this embodiment, tokens of the blockchain 5 corresponding to the amount of donation are issued, and the tokens corresponding to the amount of money received in the account 41 in the bank 4 are placed in the wallet of the charity organization 2 (in this embodiment, the account in the blockchain 5 is referred to as a wallet). In this embodiment, regarding the tokens issued in the block chain 5, one unit of the legal currency received by the charity organization 2 is equal to one token (i.e. the token may be a stable coin pegged to a legal currency). The tokens according to the amount of money provided by the charity organization 2 to the beneficiary 3 are transferred from the wallet 51 of the charity organization 2 to the wallet 52 of the beneficiary 3, and the actual remittance of the legal currency to the beneficiary 3 is obtained as a trade information indicating the remittance of money from the account 41 of the charity organization 2 to the account 42 of the beneficiary 3 to verify that the token transfer coincides with the remittance of the legal currency. In this manner, the donation management system 10 of the embodiment allows the flow of the tokens to be managed in conjunction with the flow of the legal currency.
US 20220036323 A1 Sasaki; Yu et al. ELECTRONIC WALLET ALLOWING VIRTUAL CURRENCY EXPIRATION DATE - [0256] FIG. 10 further shows the rightmost transaction 920 as being a transaction in which Bob transfers 2 VCU to Erin. However, in this case, the 2 VCU to are in EVCs having expiration information stored in the optional information 950. The optional information 950 contains an area, such as the 80-byte area called OP_RETURN in Bitcoin™, for which free description is allowed in the virtual currency script. An expiration date may be specified in the optional information 950, and transferee destination(s) such as a donation destination(s) may be specified in the destination information 960, which may or may not constitute a part of the transaction 920. The dedicated wallet application described herein may be configured to carry out the restriction(s)/VCUR(s) and automated transfers to the transferee address upon expiration. This transaction 920 using the EVC may allow an automatic transfer, such as a donation of an expired amount of the EVC, to a designated transferee, such as a charity organization. In FIG. 10, in an illustrative example, if the expiration date is Aug. 1, 2020, and the transferee destination is the Red Cross®, then if the EVC has not been spent on or before Aug. 1, 2020, the EVC may then be transferred to a wallet of the Red Cross® automatically. In some embodiments, the EVC, upon initial use, either before or after expiration, reverts to a normal virtual currency and free of the VCURs. When the EVC is sent to an address other than the EVC wallet or when it is sent to the automatic destination due to expiration, the recipient uses the received amount in the normal virtual currency wallet, so there is no restriction on the deadline or destination—thus, the recipient can send regular virtual currency.
US 20150317668 A1 TIETZEN; Terrance Patrick CUSTOMER VOICE ORDER TRIGGERED MUTUAL AFFINITY MERCHANT DONATION - [0095] To conduct the transaction that triggers the donation by merchant (m) 510 to Affinity Entity (k) 596, as shown in FIG. 5, Account holder (p) 508 may present its issued account to a Merchant (m) 510 as tender for a financial transaction such as a purchase of goods and/or services. As part of the transaction, the Account Holder (p) 508a may offer a physical or virtue token bearing an identifier with which the Account Holder (p) 508 is associated. The token can be a credit, debit, pre-paid, or gift card. The token can also be a school or government identification card, social security number card, driver's license, credit card, debit card, prepaid card, cellular telephone number, etc. The token can be read by a reader operated by the Merchant (m) 510, which as a reader associated with a Point of Service terminal (POS). For example, the reader might read the identifier for the Account Holder (p) 508a from a magnetic strip on a plastic card, a computer chip or computer readable medium on a card, a rendering on a display screen of a cellular telephone or Personal Digital Assistant (PDA), a Near Field Communication (NFC) transmission for a card (e.g., a Visa Pay Wave® card) or from smart phone, etc.
US 20210406864 A1 Gardiner; Ari et al. CONTACTLESS PAYMENT SYSTEM - [0081] In FIG. 17(e), there is shown a sample screen display 301 of a modified version of the main, or home, screen for initiating certain user transaction controls. As can be seen, screen display 301 additionally includes a gratitude button 303. Upon activation of button 303, a charity screen display 311 is generated of the type shown in FIG. 17(f). As can be seen, charity screen display 311 includes a charity selection dropdown button 313 for designating a charity to receive automated donations, an amount selection dropdown button 315 for designating the amount of each automated donation, and a frequency selection dropdown button 317 for designating when automated donations are to be rendered.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MD S HYDER whose telephone number is (571)270-1820. The examiner can normally be reached Monday - Friday 8:30am - 6:00pm.
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, Patrick McAtee can be reached at (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 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.
/M.S.H./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
