DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) each recite(s) a platform comprising physical components and devices and falls into at least one statutory category enumerated in 35 U.S.C. § 101. However, the judicial exception is not integrated into a practical application because claim 18 recites:
Managing a first financial account, financial accounts associated with each one of a plurality of users for integrating multiple sources of currency, wherein the multiple sources of currency include deposits from gift card balances, prepaid debit card balances, cash and coins, accepting deposits of the multiple sources of currency, wherein deposits from gift cards and prepaid cards include an unused balance of the gift cards or prepaid cards,
This is an abstract idea that falls into fundamental economic principles or practices because it recites managing financial accounts, accepting deposits, and integrating different sources of currency into a financial account. (see MPEP 2106.04(a)(2)(II)(A) citing the example of local processing of payments for remotely purchased goods, Inventor Holdings, LLC v. Bed Bath Beyond, 876 F.3d 1372, 1378-79, 125 USPQ2d 1019, 1023 (Fed. Cir. 2017);) or a commercial interaction because the claims recite the use of gift card balances (see MPEP 2106.04(a)(2)(II)(B) citing the example of processing information through a clearing-house, where the business relation is the relationship between a party submitted a credit application (e.g., a car dealer) and funding sources (e.g., banks) when processing credit applications, Dealertrack v. Huber, 674 F.3d 1315, 1331, 101 USPQ2d 1325, 1339 (Fed. Cir. 2012).
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements are:
a mobile application; a website; a server; a communication network; a user device; a plurality of ATMs; an ATM database connected to said server; a web-based service; user device is an electronic device for accessing said mobile application and said website; wherein said server is selected from the group consisting of a centralized server, a distributed server, and a cloud server; a coin inlet and a cash inlet.
The specification at ¶[0031] states that “The server 108 can be […] any other conventional server” and at ¶[0030] states that “A user device 106 […] can be a handheld electronic device or any other computing device “ and at ¶[0032] that “The communication network 110 can be one or more types of wireless communication signals and/or systems, for example, radio frequency (RF), infrared (IR), frequency-division multiplexing (FDM), orthogonal FDM (OFDM), time-division multiplexing (TDM), time-division multiple access (TDMA), extended TDMA (E-TDMA), wideband CDMA (WCDMA), CDMA 2000, discrete multi-tone (DMT), Bluetooth (®), global positioning system (GPS), Wi-Fi, ZigBee (™), global system for mobile communication (GSM), 2G, 2.5G, 3G, 3.5G, 4G, 5G, 6G, or the like.”
The additional elements are computing or networking computers recited at a high level of generality or link the abstract idea to the particular technological environment or field of use of banking equipment (ATMs and coin and cash inlets).
These additional elements are recited at a high-level of generality; and so, generally link the use of the judicial exception to the particular technological environment of networked computers and ATMs. The claimed invention does not improve the functioning of a computer or improve another technology or technical field. Limitations that amount to merely indicating a field of use or technological environment in which to apply a judicial exception cannot integrate a judicial exception into a practical application. See MPEP 2106.05(h).
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately or in combination, they do no more than limit the above-identified abstract idea to the particular technological environment of networked computers and ATMs, as discussed above. Limitations that merely confine the use of the abstract idea to a particular technological environment fail to add an inventive concept to the claims. See MPEP § 2106.05(h) discussing Affinity Labs of Texas v. DirecTV, LLC, 838 F.3d 1253, 120 USPQ2d 1201 (Fed. Cir. 2016) (particular technological environment of cellular telephones).
Claims 1 and 11 are broader independent claims and their subject matter is encompassed by claim 18 and are accordingly rejected for the same reasons provided above.
Claims 2 and 13 recite storing in formation in an account database. Storing information is part of the abstract idea and a database is a generic computer component and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 3 recites ATMs accepting deposits of currency and is part of the abstract idea limited to the field of ATMs and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 4 and 14 recites dispensing a withdrawal and is part of the abstract idea limited to the field of ATMs and does not integrate the abstract idea into a practical application or provide significantly more.
Claims 5 and 15 recite storing a user profile in a database. Storing information is part of the abstract idea and a database is a generic computer component and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 6 and 16 merely specifies that the kind of deposits include unused balances of gift cards. This is part of the abstract idea and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 7 and 17 merely specifies that the kind of deposits include unused balances of prepaid cars. This is part of the abstract idea and does not integrate the abstract idea into a practical application or provide significantly more.
Claims 8 and 12 recite each ATM having a coin inlet and cash inlet which only links the abstract idea to the technological field of ATMs and does not integrate the abstract idea into a practical application or provide significantly more.
Claims 9 and 10 recite transferring funds to another account or an investment account. This is part of the abstract idea and does not integrate the abstract idea into a practical application or provide significantly more.
Claim 19 recites sending information from ATMs to a user device. The devices are recited at a high level of generality and the MPEP at section 2106.05(d)(II)(i) states receiving or transmitting data over a network is a well-understood, routine, and conventional computer function or insignificant extra-solution activity.
Claim 20 recites a user interface for displaying an expert providing financial advice Providing financial advice is part of the abstract idea and the user interface is recited at a high level of generality and does not integrate the abstract idea into a practical application or provide significantly more.
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 shall not be negated by the manner in which the invention was made.
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 nonobviousness.
Claim(s) 1-19 are rejected under 35 U.S.C. 103 as being unpatentable over SALMON (US 20120233073 A1) in view of YAHN (US 20150025987 A1).
Regarding claim(s) 1,
SALMON discloses:
A financial integration platform for integrating different sources of currency (SALMON: ¶[0035]: a user may desire to aggregate purchasing power from a variety of source[s];
¶[0040]: the Universal Value Exchange (“UVE”) provides a single place where points/currencies from various program providers 110 can be managed, redeemed, exchanged 112b, or linked to a wallet),
the financial integration platform comprising: a mobile application (SALMON: ¶[0105]: virtual wallet mobile app facilitate and greatly enhance the shopping experience of consumers; ¶[0046]: The customer may enroll in the exchange program with the loyalty broker by accessing a customer facing portal, a web or mobile application, a wallet having loyalty broker facilities.);
a website (SALMON: ¶[0046]: The customer may enroll in the exchange program with the loyalty broker by accessing a customer facing portal, a web or mobile application, a wallet having loyalty broker facilities);
a server (SALMON: ¶[0050]: The data flow diagram shows flow of data between a user 202a, a client 204a, a UVE server(s) 206a and gift card issuer servers 208a/210a, and target gift card issuer server(s) 207a over a communication network 213a. As shown in the figure, the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server.);
a communication network (SALMON: ¶[0050]: The data flow diagram shows flow of data between a user 202a, a client 204a, a UVE server(s) 206a and gift card issuer servers 208a/210a, and target gift card issuer server(s) 207a over a communication network 213a. As shown in the figure, the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server.);
and a user device to manage a first financial account (SALMON: figure 2A, item 204A and ¶[0050]: In some implementations, the client may include, but is not limited to: a personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, and/or the like (e.g., 204a); ¶[0147]: The user may utilize […] a user wallet device, e.g., 1801b, to access the user's virtual wallet account. For example, the user wallet device may be a personal/laptop computer, cellular telephone, smartphone, tablet, eBook reader, netbook, gaming console, and/or the like);
wherein said website having a web-based service (SALMON: ¶[0207]: Web browsers and like information access tools may be integrated into PDAs, cellular telephones, and/or other mobile devices. A Web browser may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the Web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses; ¶[0202]: The information server provides results in the form of Web pages to Web browsers, and allows for the manipulated generation of the Web pages through interaction with other program components) ;
wherein said financial integration platform is accessible through said web-based service and said mobile application to enable a user to manage at least said first financial account (SALMON: ¶[0050]: the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server. In some implementations, the user may wish to transfer the value from one gift card to another. The user may then input or select a source gift card and a target gift card and request value transfer from the source gift card to the target gift card at 212.; ¶[0084]: At 524, the user may select a source currency/point program to initiate an exchange transaction. The client may communicate the selected source program to the UVE server which may receive the selection at 526. At 528, the UVE server may parse the message received and may query the rules and restrictions database to determine any rules and restrictions associated with the source program.);
wherein said user device is an electronic device for accessing said mobile application and said website (SALMON: ¶[0050]: In some implementations, the client may include, but is not limited to: a personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, and/or the like);
wherein said server accessible by a plurality of users (SALMON: ¶[0049]: For example, a user A may have a gift card for the Apple Store, but the user never shops in the Apple Store, and would instead prefer to exchange the Apple gift card for a Best Buy gift card. Similarly, another user B may have a Best Buy gift card, but would like to exchange for an Apple Store gift card. In such a situation, the UVE may facilitate the exchange of the Apple and Best Buy gift cards such that both users A and B can have their preferred gift cards. Figure 2A and ¶[0050]: The data flow diagram shows flow of data between a user 202a, a client 204a, a UVE server(s) 206a and gift card issuer servers 208a/210a, and target gift card issuer server(s) 207a over a communication network 213a. As shown in the figure, the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server.);
wherein said server is selected from the group consisting of a centralized server, a distributed server, and a cloud server (SALMON: ¶[0193]: distributed network controllers (e.g., Distributed UVE), architectures may similarly be employed to pool, load balance, and/or otherwise increase the communicative bandwidth required by the UVE controller.; ¶[0187]: Should processing requirements dictate a greater amount speed and/or capacity, distributed processors (e.g., Distributed UVE), mainframe, multi-core, parallel, and/or super-computer architectures may similarly be employed; ¶[0127]: save to “a cloud account”);
wherein said plurality of users access said server through said user device and said communication network (SALMON: ¶[0184]: server responds to the requests of remote users across a communications network; ¶[0183]: the UVE controller 2201 may be connected to and/or communicate with entities such as, but not limited to: one or more users from user input devices 2211; peripheral devices 2212; an optional cryptographic processor device 2228; and/or a communications network 2213.; ¶[0193]: [0193] Network interfaces 2210 may accept, communicate, and/or connect to a communications network 2213. Through a communications network 2213, the UVE controller is accessible through remote clients 2233b (e.g., computers with web browsers) by users 2233a.);
wherein said financial integration platform having a financial account associated with each one of said plurality of users for integrating multiple sources of currency (SALMON: ¶[0040]: [0040] From the point of view of a user 118, the UVE provides a single place where points/currencies from various program providers 110 can be managed, redeemed, exchanged 112b, or linked to a wallet.; ¶[0037]: With reference to FIG. 1B, the UVE controller 116 may act as a gateway or a single point of access between program providers 110, point aggregators 114, merchants 120 and users 118.; ¶[0083]: UVE server may query one or more user databases and/or tables using for example the user ID to identify loyalty programs in which the user is currently enrolled; ¶[0096]: the exchange UI (right) may be displayed. The exchange UI may display various options for selecting a source currency. For example, a user may select the loyalty tab 806a as a source currency. When the loyalty tab is selected a loyalty panel 806b may be displayed. As shown, the loyalty panel may include a listing of loyalty cards or accounts. The user may select one or more of these loyalty accounts as a source currency. […] while the exchange button 806e allows the user to initiate the exchange.);
and further wherein said multiple sources of currency including deposits from the group consisting of gift card balances, prepaid debit card balances, cash, and coins (SALMON: ¶[0049]: The user may prefer to combine the value of all the gift cards in one gift card or prepaid card, a bank account or obtain cash; ¶[0113]: . The user interface may clearly identify the amount 1112 and the currency 1113 for the transaction. The amount may be the amount payable and the currency may include real currencies such as dollars and Euros, as well as virtual currencies such as reward points. The amount of the transaction 1114 may also be prominently displayed on the user interface. The user may select the funds tab 1116 to select one or more forms of payment 1117, which may include various credit, debit, gift, rewards and/or prepaid cards.; ¶[0155]: the pay network server may generate a query, e.g., 1824, for issuer server(s) corresponding to the user-selected payment options. For example, the user's account may be linked to one or more issuer financial institutions ("issuers"), such as banking institutions, which issued the account(s) for the user. For example, such accounts may include, but not be limited to: credit card, debit card, prepaid card, checking, savings, money market, certificates of deposit, stored (cash) value accounts and/or the like.).
SALMON does not expressly disclose the following limitations, which YAHN however, teaches:
[…] deposits from […] “coins” (YAHN: figure 11: receive coin, cash, and/or other form of value at step 1102, Count coin, cash, etc, at 1104, Display options E.g., Mobile wallet, voucher, card, etc at 1106; ¶[0016]: [0016] FIG. 11 is a flow diagram of a machine-implemented routine for converting coins, cash, and/or other forms of value to a mobile commerce platform; ¶[0028]: As described in greater detail below, after a user (not shown) has input funds (e.g., loose coins) into the kiosk 100 and the kiosk 100 has counted the coins to determine a value, the user can position a wireless-enabled mobile device 120 (e.g., a mobile computing device such as a smart phone) in proximity of the kiosk (e.g., within a distance suitable for near field communication (NFC)), and the kiosk can wirelessly transfer the funds, or a portion of the funds to the mobile device 120 (e.g., to an application for implementing mobile commerce with the mobile device 120).; ¶[0030]: Referring first to FIG. 2A, a consumer or user 222 inputs funds (e.g., a plurality of loose coins 224) into the kiosk 100 via the coin receiving region 103. The kiosk 100 can then display or otherwise provide the consumer 222 with various options for converting her coins into other forms of value, including an option for transferring the coin value to a mobile wallet or other mobile account; ¶[0016]: the routine begins when the machine (e.g., a consumer-operated coin counting kiosk) receives coin, cash and/or other forms of value from a consumer. In block 1104, the routine counts the received funds to determine a value. In block 1106, the routine displays (e.g., via the display 106 on the kiosk 100 of FIG. 1) one or more options to the consumer for allocating the value of the received funds. The options can include, for example, receiving a redeemable voucher, a prepaid card, and/or having all or a portion of the funds transferred to a mobile wallet account.)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SALMON, which discloses systems and methods of cross-ecosystem currency exchange (SALMON abstract) with the technique of YAHN, in order to provide consumers with additional options for converting loose coins, cash, etc. to other forms (YAHN ¶[0005]).
Regarding claim(s) 2,
The combination of SALMON and YAHN teaches the financial integration platform of claim 1,
SALMON further discloses:
wherein said server having an account database for storing information of said at least said first financial account maintained by said financial integration platform (SALMON: ¶[0062]: In one implementation, at 272 the UVE server may update database 219b with updated balances of the source gift card, the target gift card and destination gift card. In one implementation, the UVE server may provide updated gift card balances 274 to the client such that the user may view the changes in the source and destination gift card balances after the transfer.; ¶[056]: , the UVE may be made part of a payment network which may parse PAN/account identifiers and compare such account identifiers embedded in transaction request/authentication with records in the UVE database, e.g., users 2219a, accounts 2219g, etc., tables. In those instances, the UVE may take a credit and use its points/value equivalence to pay for the consumer's purchase and take direct charge from the consumer's payment source for that value. ¶[0084]: The client may communicate the selected source program to the UVE server which may receive the selection at 526. At 528, the UVE server may parse the message received and may query the rules and restrictions database to determine any rules and restrictions associated with the source program.; ¶[0056]: At 242, the UVE server may store updated pool source gift card balance (e.g., previous balance incremented by the value of the source gift card) and the updated pool target gift card balance (e.g., previous value decremented by the equivalent amount); ¶[0073]: , the value of the source gift card account may be allocated to a UVE account or a UVE pool; ¶[0048]: The customer's UVE points balance is incremented by the total UVE points gained (e.g., +225), his/her miles balance is decremented by the number of miles used in the exchange (e.g., 25,000 miles).; figures 8A and 8J: “My UVE Points” in UI and ¶[0100]: The statement UI (not shown) may allow the user to select a time period and obtain a statement summary of exchanges, UVE points balance, ¶[0215]: The Users table may support and/or track multiple entity accounts on a UVE).
Regarding claim(s) 3,
The combination of SALMON and YAHN teaches the financial integration platform of claim 2
SALMON further discloses:
wherein said plurality of ATMs accept said deposits of said multiple sources of currency (SALMON: ¶[0026]: The schematic diagram illustrates that coins, cash and/or other forms of currency and value 101 can be deposited in, for example, a coin input region; ¶[0061]: the routine begins when the machine (e.g., a consumer-operated coin counting kiosk) receives coin, cash and/or other forms of value from a consumer.; ¶[0018]: a consumer operated kiosk is configured to receive loose coins and/or cash from a consumer, and count the coins and/or cash to determine a total value.; claim 14: coin receiving region configured to receive a plurality of coins from a user; ¶[0068]: As the foregoing disclosure illustrates, there are a number of different ways that a consumer-operated kiosk or other machine, or a network of such machines can convert various forms of consumer currency and other forms of value into a form suitable for paperless electronic commerce from;.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SALMON, which discloses systems and methods of cross-ecosystem currency exchange (SALMON abstract) and interacting with a Universal Value Exchange system via ATMs (SALMON ¶[0050]) with the technique of YAHN, in order to provide consumers with additional options for converting loose coins, cash, etc. to other forms (YAHN ¶[0005]).
SALMON discloses that an ATM maybe a client/device used by the user to communicate with the UVE (Universal Value Exchange) server (SALMON ¶[0050]) and an ability to convert points from traditional rewards programs into cash withdrawn from an ATM-linked account (SALMON ¶[0034]).
SALMON does not expressly disclose the following limitations, which YAHN however, teaches:
further comprising a plurality of ATMs having an ATM database connected to said server (YAHN: ¶[0043]: In the illustrated embodiment, one or more consumer kiosks 100a-n (e.g., consumer coin counting kiosks) can be operably connected to a first host computer 760a via one or more communication links; ¶[0043]: "back-end" accounting systems can be implemented by one or more processing devices operably communicating with one or more databases.; ¶[0054]: The server computer 960 can retrieve and exchange web pages and other content with a database 970. ),
Regarding claim(s) 4,
The combination of SALMON and YAHN teaches the financial integration platform of claim 3,
SALMON further discloses :
wherein said plurality of ATMs dispense a withdrawal from said at least said first financial account of said each one of said plurality of users (SALMON: a kiosk, ATM and/or the like may be a client for interacting with the UVE server (SALMON ¶[0050]) ; users may “convert points from a traditional rewards program into cash withdrawn from an ATM-linked account” (SALMON ¶[0034]).).
Regarding claim(s) 5,
The combination of SALMON and YAHN teaches the financial integration platform of claim 4
SALMON further discloses :
further comprising a user database for storing a user profile of said each one of said plurality of users, wherein said user profile having information selected from the group consisting of a name, a location, an age, a gender, and an authentication (SALMON: ¶[0215]: In one embodiment, the database component 2219 includes several tables 2219a-k. A Users table 2219a may include fields such as, but not limited to: user_id, ssn, dob, first_name, last_name, address, age, state, address_firstline, address_secondline, zipcode, application_id, application_type, exchange_preferences_list, exchange_preferences_values, devices_list, user_accounts_list, user_passwords_list, security_level, and/or the like.).
Regarding claim(s) 6,
The combination of SALMON and YAHN teaches the financial integration platform of claim 5,
SALMON further discloses :
wherein said deposits from said gift cards include an unused balance of each one of said gift cards (SALMON: ¶[0056]: . For example, when source and destination field values in the value card table record reach $o and yet there is residual value left on the card, that residual value may be used to generate such excess balances for the UVE. In one example, the UVE may observe consumers making purchases with merchants accepting such value; ¶[0049]: As another example, a user may have various gift cards in his or her hands or in the wallet. The user may prefer to combine the value of all the gift cards in one gift card or prepaid card, a bank account or obtain cash. In such as situation, the UVE may provide facilities to consolidate the gift card values and automatically apply them in a purchase transaction.; ¶[0062]: the user may execute the transfer request at 270. In one implementation, at 272 the UVE server may update database 219b with updated balances of the source gift card, the target gift card and destination gift card. In one implementation, the UVE server may provide updated gift card balances 274 to the client such that the user may view the changes in the source and destination gift card balances after the transfer; ¶[0067]: In one implementation, the UVE server may update a value card table record (e.g., 2219u) to deallocate the user 202C from the gift card once it has been liquidated and an equivalent value has been provided. In one implementation, upon liquidation at 289, the user may be sent the updated gift card balance message 292 notifying that the gift card has been liquidated with no balance remaining in the gift card. In a further implementation, the user may also be notified of the deposit of the equivalent amount in a user designated account, statement credit, cash, and/or the like. ).
Regarding claim(s) 7,
The combination of SALMON and YAHN teaches the financial integration platform of claim 5,
SALMON further discloses :
wherein said deposits from said prepaid debit cards include an unused balance of each one of said prepaid debit cards (SALMON: ¶[0034]: the user may have retained purchasing power in various currency types across various ecosystems. For example, the user may have access to currencies such as, but not limited to: a financial account (checking, savings, debit card, credit card, open and closed loop gift cards, prepaid cards, current account, money market, etc.) […] and/or the like.; ¶[0034]: In some implementations, the user may desire to convert purchasing power available in one currency ecosystem to another currency utilized in a completely different ecosystem.; ¶[0113]: The user may select the funds tab 1116 to select one or more forms of payment 1117, which may include various credit, debit, gift, rewards and/or prepaid cards; ¶[0151]: the pay gateway server may […] process various types of transactions including, but not limited to: […] prepaid card, B2B and/or like transactions. ¶[0155]: In some embodiments, the pay network server may generate a query, e.g., 1824, for issuer server(s) corresponding to the user-selected payment options. For example, the user's account may be linked to one or more issuer financial institutions ("issuers"), such as banking institutions, which issued the account(s) for the user. For example, such accounts may include, but not be limited to: […] prepaid card; ¶[0056]: The UVE may aggregate such excess balances over time by apportioning value from records in the UVE database, e.g., value card 2219u);
Regarding claim(s) 8,
The combination of SALMON, YAHN, and CHANG teaches the financial integration platform of claim 4,
SALMON does not expressly disclose the following limitations, which YAHN however, teaches:
wherein each one of said plurality of ATMs having a coin inlet and a cash inlet (YAHN: ¶[0026]: The schematic diagram illustrates that coins, cash and/or other forms of currency and value 101 can be deposited in, for example, a coin input region 103 (e.g., a pivoting coin tray) of a consumer operated coin counting kiosk 100. The kiosk 100 can include a coin counting apparatus for counting the deposited coins and determining a value; [0028]: As described in greater detail below, after a user (not shown) has input funds (e.g., loose coins) into the kiosk 100 and the kiosk 100 has counted the coins to determine a value, the user can position a wireless-enabled mobile device 120 (e.g., a mobile computing device such as a smart phone) in proximity of the kiosk (e.g., within a distance suitable for near field communication (NFC)), and the kiosk can wirelessly transfer the funds, or a portion of the funds to the mobile device 120 (e.g., to an application for implementing mobile commerce with the mobile device 120).; ¶[0030]: a consumer or user 222 inputs funds (e.g., a plurality of loose coins 224) into the kiosk 100 via the coin receiving region 103. The kiosk 100 can then display or otherwise provide the consumer 222 with various options for converting her coins into other forms of value, including an option for transferring the coin value to a mobile wallet or other mobile account. Such options may include using the transferred funds to top off an existing mobile wallet or virtual gift card, or to create a new mobile account.; ¶[0042]: In some embodiments, the kiosk 100 can transfer coin, cash and/or other forms of value to virtual gift cards for use in a closed loop marketplace; ¶[0057]: the routine begins when the consumer or other user deposits coins, cash and/or other forms of value […] into a consumer operated kiosk (e.g., the kiosk 100 of FIG. 1) or other suitable machine for counting the deposited funds to determine a value.; ¶[0068]: consumers can use such a kiosk to quickly convert coins and/or cash into "closed loop" virtual gift cards that can be activated, reloaded with funds; ¶[0071]:consumers can top off their existing mobile wallets or virtual gift card accounts using coins, cash and/or other funds deposited in a wirelessly-enabled kiosk).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SALMON, which discloses systems and methods of cross-ecosystem currency exchange (SALMON abstract) and interacting with a Universal Value Exchange system via ATMs (SALMON ¶[0050]) with the technique of YAHN, in order to provide consumers with additional options for converting loose coins, cash, etc. to other forms (YAHN ¶[0005]).
Regarding claim(s) 9,
The combination of SALMON and YAHN teaches the financial integration platform of claim 1,
SALMON further discloses:
wherein said financial integration platform is accessible through said web-based service and said mobile application to enable a user to transfer funds from said at least said first financial account to a second financial account (SALMON: ¶[0050]: As shown in the figure, the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server.; ¶[0054]: in one implementation, the source gift card issuer server may send the client the updated source gift card balance 236 confirming the transfer of the source gift card value. In one implementation, the UVE server may send a target gift card order 238 to the target gift card issuer. The target gift card order may include a request to transfer the determined equivalent value from the pool target gift card to a target gift card.).
Regarding claim(s) 10,
The combination of SALMON and YAHN teaches the financial integration platform of claim 9,
SALMON further discloses:
wherein said second financial account is an investment account (SALMON: ¶[0034]: an electronically tradable financial instrument (e.g., derivative financial products, securities, bonds, etc.); ¶[0230]: various embodiments of the UVE, may be implemented that enable a great deal of flexibility and customization. For example, aspects of the UVE may be adapted for exchanging securities).
Regarding claim(s) 11,
SALMON discloses:
A financial integration platform for integrating different sources of currency (SALMON: ¶[0035]: a user may desire to aggregate purchasing power from a variety of source[s];
¶[0040]: the Universal Value Exchange (“UVE”) provides a single place where points/currencies from various program providers 110 can be managed, redeemed, exchanged 112b, or linked to a wallet),
the financial integration platform comprising:
a mobile application (SALMON: ¶[0105]: virtual wallet mobile app facilitate and greatly enhance the shopping experience of consumers; ¶[0046]: The customer may enroll in the exchange program with the loyalty broker by accessing a customer facing portal, a web or mobile application, a wallet having loyalty broker facilities.);
a website (SALMON: ¶[0046]: The customer may enroll in the exchange program with the loyalty broker by accessing a customer facing portal, a web or mobile application, a wallet having loyalty broker facilities);
a server (SALMON: ¶[0050]: The data flow diagram shows flow of data between a user 202a, a client 204a, a UVE server(s) 206a and gift card issuer servers 208a/210a, and target gift card issuer server(s) 207a over a communication network 213a. As shown in the figure, the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server.);
a communication network (SALMON: ¶[0050]: The data flow diagram shows flow of data between a user 202a, a client 204a, a UVE server(s) 206a and gift card issuer servers 208a/210a, and target gift card issuer server(s) 207a over a communication network 213a. As shown in the figure, the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server.);
and a user device to manage a first financial account (SALMON: figure 2A, item 204A and ¶[0050]: In some implementations, the client may include, but is not limited to: a personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, and/or the like (e.g., 204a); ¶[0147]: The user may utilize […] a user wallet device, e.g., 1801b, to access the user's virtual wallet account. For example, the user wallet device may be a personal/laptop computer, cellular telephone, smartphone, tablet, eBook reader, netbook, gaming console, and/or the like);
and a plurality of ATMs (SALMON: ¶[0050]: the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server; ¶[0050]: In some implementations, the client may include, but is not limited to: a point-of-sale terminal, kiosk, ATM, and/or the like );
[…]
wherein said website having a web-based service (SALMON: ¶[0207]: Web browsers and like information access tools may be integrated into PDAs, cellular telephones, and/or other mobile devices. A Web browser may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the Web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses; ¶[0202]: The information server provides results in the form of Web pages to Web browsers, and allows for the manipulated generation of the Web pages through interaction with other program components) ;
wherein said financial integration platform is accessible through said web-based service and said mobile application to enable a user to manage at least said first financial account (SALMON: ¶[0050]: the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server. In some implementations, the user may wish to transfer the value from one gift card to another. The user may then input or select a source gift card and a target gift card and request value transfer from the source gift card to the target gift card at 212.; ¶[0084]: At 524, the user may select a source currency/point program to initiate an exchange transaction. The client may communicate the selected source program to the UVE server which may receive the selection at 526. At 528, the UVE server may parse the message received and may query the rules and restrictions database to determine any rules and restrictions associated with the source program.);
wherein said user device is an electronic device for accessing said mobile application and said website (SALMON: ¶[0050]: In some implementations, the client may include, but is not limited to: a personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, and/or the like);
wherein said server accessible by a plurality of users (SALMON: ¶[0049]: For example, a user A may have a gift card for the Apple Store, but the user never shops in the Apple Store, and would instead prefer to exchange the Apple gift card for a Best Buy gift card. Similarly, another user B may have a Best Buy gift card, but would like to exchange for an Apple Store gift card. In such a situation, the UVE may facilitate the exchange of the Apple and Best Buy gift cards such that both users A and B can have their preferred gift cards. Figure 2A and ¶[0050]: The data flow diagram shows flow of data between a user 202a, a client 204a, a UVE server(s) 206a and gift card issuer servers 208a/210a, and target gift card issuer server(s) 207a over a communication network 213a. As shown in the figure, the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server.);
wherein said server is selected from the group consisting of a centralized server, a distributed server, and a cloud server (SALMON: ¶[0193]: distributed network controllers (e.g., Distributed UVE), architectures may similarly be employed to pool, load balance, and/or otherwise increase the communicative bandwidth required by the UVE controller.; ¶[0187]: Should processing requirements dictate a greater amount speed and/or capacity, distributed processors (e.g., Distributed UVE), mainframe, multi-core, parallel, and/or super-computer architectures may similarly be employed; ¶[0127]: save to “a cloud account”);
wherein said plurality of users access said server through said user device and said communication network (SALMON: ¶[0184]: server responds to the requests of remote users across a communications network; ¶[0183]: the UVE controller 2201 may be connected to and/or communicate with entities such as, but not limited to: one or more users from user input devices 2211; peripheral devices 2212; an optional cryptographic processor device 2228; and/or a communications network 2213.; ¶[0193]: [0193] Network interfaces 2210 may accept, communicate, and/or connect to a communications network 2213. Through a communications network 2213, the UVE controller is accessible through remote clients 2233b (e.g., computers with web browsers) by users 2233a.);
wherein said financial integration platform having a financial account associated with each one of said plurality of users for integrating multiple sources of currency (SALMON: ¶[0040]: [0040] From the point of view of a user 118, the UVE provides a single place where points/currencies from various program providers 110 can be managed, redeemed, exchanged 112b, or linked to a wallet.; ¶[0037]: With reference to FIG. 1B, the UVE controller 116 may act as a gateway or a single point of access between program providers 110, point aggregators 114, merchants 120 and users 118.; ¶[0083]: UVE server may query one or more user databases and/or tables using for example the user ID to identify loyalty programs in which the user is currently enrolled; ¶[0096]: the exchange UI (right) may be displayed. The exchange UI may display various options for selecting a source currency. For example, a user may select the loyalty tab 806a as a source currency. When the loyalty tab is selected a loyalty panel 806b may be displayed. As shown, the loyalty panel may include a listing of loyalty cards or accounts. The user may select one or more of these loyalty accounts as a source currency. […] while the exchange button 806e allows the user to initiate the exchange.);
and further wherein said multiple sources of currency including deposits from the group consisting of gift card balances, prepaid debit card balances, cash, and coins (SALMON: ¶[0049]: The user may prefer to combine the value of all the gift cards in one gift card or prepaid card, a bank account or obtain cash; ¶[0113]: . The user interface may clearly identify the amount 1112 and the currency 1113 for the transaction. The amount may be the amount payable and the currency may include real currencies such as dollars and Euros, as well as virtual currencies such as reward points. The amount of the transaction 1114 may also be prominently displayed on the user interface. The user may select the funds tab 1116 to select one or more forms of payment 1117, which may include various credit, debit, gift, rewards and/or prepaid cards.; ¶[0155]: the pay network server may generate a query, e.g., 1824, for issuer server(s) corresponding to the user-selected payment options. For example, the user's account may be linked to one or more issuer financial institutions ("issuers"), such as banking institutions, which issued the account(s) for the user. For example, such accounts may include, but not be limited to: credit card, debit card, prepaid card, checking, savings, money market, certificates of deposit, stored (cash) value accounts and/or the like.).
and further wherein said plurality of ATMs accept said deposits of said multiple sources of currency (SALMON: ¶[0026]: The schematic diagram illustrates that coins, cash and/or other forms of currency and value 101 can be deposited in, for example, a coin input region; ¶[0061]: the routine begins when the machine (e.g., a consumer-operated coin counting kiosk) receives coin, cash and/or other forms of value from a consumer.; ¶[0018]: a consumer operated kiosk is configured to receive loose coins and/or cash from a consumer, and count the coins and/or cash to determine a total value.; claim 14: coin receiving region configured to receive a plurality of coins from a user; ¶[0068]: As the foregoing disclosure illustrates, there are a number of different ways that a consumer-operated kiosk or other machine, or a network of such machines can convert various forms of consumer currency and other forms of value into a form suitable for paperless electronic commerce from; ¶[0062]: the user may execute the transfer request at 270. In one implementation, at 272 the UVE server may update database 219b with updated balances of the source gift card, the target gift card and destination gift card. In one implementation, the UVE server may provide updated gift card balances 274 to the client such that the user may view the changes in the source and destination gift card balances after the transfer.)..
SALMON does not expressly disclose the following limitations, which YAHN however, teaches:
wherein said plurality of ATMs having an ATM database connected to said server (YAHN: ¶[0043]: In the illustrated embodiment, one or more consumer kiosks 100a-n (e.g., consumer coin counting kiosks) can be operably connected to a first host computer 760a via one or more communication links; ¶[0043]: "back-end" accounting systems can be implemented by one or more processing devices operably communicating with one or more databases.; ¶[0054]: The server computer 960 can retrieve and exchange web pages and other content with a database 970. );
[…] deposits from […] “coins” (YAHN: figure 11: receive coin, cash, and/or other form of value at step 1102, Count coin, cash, etc, at 1104, Display options E.g., Mobile wallet, voucher, card, etc at 1106; ¶[0016]: [0016] FIG. 11 is a flow diagram of a machine-implemented routine for converting coins, cash, and/or other forms of value to a mobile commerce platform; ¶[0028]: As described in greater detail below, after a user (not shown) has input funds (e.g., loose coins) into the kiosk 100 and the kiosk 100 has counted the coins to determine a value, the user can position a wireless-enabled mobile device 120 (e.g., a mobile computing device such as a smart phone) in proximity of the kiosk (e.g., within a distance suitable for near field communication (NFC)), and the kiosk can wirelessly transfer the funds, or a portion of the funds to the mobile device 120 (e.g., to an application for implementing mobile commerce with the mobile device 120).; ¶[0030]: Referring first to FIG. 2A, a consumer or user 222 inputs funds (e.g., a plurality of loose coins 224) into the kiosk 100 via the coin receiving region 103. The kiosk 100 can then display or otherwise provide the consumer 222 with various options for converting her coins into other forms of value, including an option for transferring the coin value to a mobile wallet or other mobile account; ¶[0016]: the routine begins when the machine (e.g., a consumer-operated coin counting kiosk) receives coin, cash and/or other forms of value from a consumer. In block 1104, the routine counts the received funds to determine a value. In block 1106, the routine displays (e.g., via the display 106 on the kiosk 100 of FIG. 1) one or more options to the consumer for allocating the value of the received funds. The options can include, for example, receiving a redeemable voucher, a prepaid card, and/or having all or a portion of the funds transferred to a mobile wallet account.)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SALMON, which discloses systems and methods of cross-ecosystem currency exchange (SALMON abstract) and interacting with a Universal Value Exchange system via ATMs (SALMON ¶[0050]) with the technique of YAHN, in order to provide consumers with additional options for converting loose coins, cash, etc. to other forms (YAHN ¶[0005]).
Regarding claim(s) 12,
The combination of SALMON and YAHN teaches the financial integration platform of claim 11,
SALMON does not expressly disclose the following limitations, which YAHN however, teaches:
wherein each one of said plurality of ATMs having a coin inlet and a cash inlet (YAHN: ¶[0026]: The schematic diagram illustrates that coins, cash and/or other forms of currency and value 101 can be deposited in, for example, a coin input region 103 (e.g., a pivoting coin tray) of a consumer operated coin counting kiosk 100. The kiosk 100 can include a coin counting apparatus for counting the deposited coins and determining a value; [0028]: As described in greater detail below, after a user (not shown) has input funds (e.g., loose coins) into the kiosk 100 and the kiosk 100 has counted the coins to determine a value, the user can position a wireless-enabled mobile device 120 (e.g., a mobile computing device such as a smart phone) in proximity of the kiosk (e.g., within a distance suitable for near field communication (NFC)), and the kiosk can wirelessly transfer the funds, or a portion of the funds to the mobile device 120 (e.g., to an application for implementing mobile commerce with the mobile device 120).; ¶[0030]: a consumer or user 222 inputs funds (e.g., a plurality of loose coins 224) into the kiosk 100 via the coin receiving region 103. The kiosk 100 can then display or otherwise provide the consumer 222 with various options for converting her coins into other forms of value, including an option for transferring the coin value to a mobile wallet or other mobile account. Such options may include using the transferred funds to top off an existing mobile wallet or virtual gift card, or to create a new mobile account.; ¶[0042]: In some embodiments, the kiosk 100 can transfer coin, cash and/or other forms of value to virtual gift cards for use in a closed loop marketplace; ¶[0057]: the routine begins when the consumer or other user deposits coins, cash and/or other forms of value […] into a consumer operated kiosk (e.g., the kiosk 100 of FIG. 1) or other suitable machine for counting the deposited funds to determine a value.; ¶[0068]: consumers can use such a kiosk to quickly convert coins and/or cash into "closed loop" virtual gift cards that can be activated, reloaded with funds; ¶[0071]:consumers can top off their existing mobile wallets or virtual gift card accounts using coins, cash and/or other funds deposited in a wirelessly-enabled kiosk)
Regarding claim(s) 13,
The combination of SALMON and YAHN teaches the financial integration platform of claim 11,
SALMON further discloses:
wherein said server having an account database for storing information of said at least said first financial account maintained by said financial integration platform (SALMON: ¶[0062]: In one implementation, at 272 the UVE server may update database 219b with updated balances of the source gift card, the target gift card and destination gift card. In one implementation, the UVE server may provide updated gift card balances 274 to the client such that the user may view the changes in the source and destination gift card balances after the transfer.; ¶[056]: , the UVE may be made part of a payment network which may parse PAN/account identifiers and compare such account identifiers embedded in transaction request/authentication with records in the UVE database, e.g., users 2219a, accounts 2219g, etc., tables. In those instances, the UVE may take a credit and use its points/value equivalence to pay for the consumer's purchase and take direct charge from the consumer's payment source for that value. ¶[0084]: The client may communicate the selected source program to the UVE server which may receive the selection at 526. At 528, the UVE server may parse the message received and may query the rules and restrictions database to determine any rules and restrictions associated with the source program.; ¶[0056]: At 242, the UVE server may store updated pool source gift card balance (e.g., previous balance incremented by the value of the source gift card) and the updated pool target gift card balance (e.g., previous value decremented by the equivalent amount); ¶[0073]: , the value of the source gift card account may be allocated to a UVE account or a UVE pool; ¶[0048]: The customer's UVE points balance is incremented by the total UVE points gained (e.g., +225), his/her miles balance is decremented by the number of miles used in the exchange (e.g., 25,000 miles).; figures 8A and 8J: “My UVE Points” in UI and ¶[0100]: The statement UI (not shown) may allow the user to select a time period and obtain a statement summary of exchanges, UVE points balance, ¶[0215]: The Users table may support and/or track multiple entity accounts on a UVE).
Regarding claim(s) 15,
The combination of SALMON and YAHN teaches the financial integration platform of claim 11
SALMON further discloses :
further comprising a user database for storing a user profile of said each one of said plurality of users, wherein said user profile having information selected from the group consisting of a name, a location, an age, a gender, and an authentication (SALMON: ¶[0215]: In one embodiment, the database component 2219 includes several tables 2219a-k. A Users table 2219a may include fields such as, but not limited to: user_id, ssn, dob, first_name, last_name, address, age, state, address_firstline, address_secondline, zipcode, application_id, application_type, exchange_preferences_list, exchange_preferences_values, devices_list, user_accounts_list, user_passwords_list, security_level, and/or the like.)
Regarding claim(s) 16,
The combination of SALMON and YAHN teaches the financial integration platform of claim 11,
SALMON further discloses :
wherein said deposits from said gift cards include an unused balance of each one of said gift cards (SALMON: ¶[0056]: . For example, when source and destination field values in the value card table record reach $o and yet there is residual value left on the card, that residual value may be used to generate such excess balances for the UVE. In one example, the UVE may observe consumers making purchases with merchants accepting such value; ¶[0049]: As another example, a user may have various gift cards in his or her hands or in the wallet. The user may prefer to combine the value of all the gift cards in one gift card or prepaid card, a bank account or obtain cash. In such as situation, the UVE may provide facilities to consolidate the gift card values and automatically apply them in a purchase transaction.; ¶[0062]: the user may execute the transfer request at 270. In one implementation, at 272 the UVE server may update database 219b with updated balances of the source gift card, the target gift card and destination gift card. In one implementation, the UVE server may provide updated gift card balances 274 to the client such that the user may view the changes in the source and destination gift card balances after the transfer; ¶[0067]: In one implementation, the UVE server may update a value card table record (e.g., 2219u) to deallocate the user 202C from the gift card once it has been liquidated and an equivalent value has been provided. In one implementation, upon liquidation at 289, the user may be sent the updated gift card balance message 292 notifying that the gift card has been liquidated with no balance remaining in the gift card. In a further implementation, the user may also be notified of the deposit of the equivalent amount in a user designated account, statement credit, cash, and/or the like. ).
Regarding claim(s) 17,
The combination of SALMON and YAHN teaches the financial integration platform of claim 11,
SALMON further discloses :
wherein said deposits from said prepaid debit cards include an unused balance of each one of said prepaid debit cards (SALMON: ¶[0034]: the user may have retained purchasing power in various currency types across various ecosystems. For example, the user may have access to currencies such as, but not limited to: a financial account (checking, savings, debit card, credit card, open and closed loop gift cards, prepaid cards, current account, money market, etc.) […] and/or the like.; ¶[0034]: In some implementations, the user may desire to convert purchasing power available in one currency ecosystem to another currency utilized in a completely different ecosystem.; ¶[0113]: The user may select the funds tab 1116 to select one or more forms of payment 1117, which may include various credit, debit, gift, rewards and/or prepaid cards; ¶[0151]: the pay gateway server may […] process various types of transactions including, but not limited to: […] prepaid card, B2B and/or like transactions. ¶[0155]: In some embodiments, the pay network server may generate a query, e.g., 1824, for issuer server(s) corresponding to the user-selected payment options. For example, the user's account may be linked to one or more issuer financial institutions ("issuers"), such as banking institutions, which issued the account(s) for the user. For example, such accounts may include, but not be limited to: […] prepaid card; ¶[0056]: The UVE may aggregate such excess balances over time by apportioning value from records in the UVE database, e.g., value card 2219u)
Regarding claim(s) 18,
SALMON discloses:
A financial integration platform for integrating different sources of currency (SALMON: ¶[0035]: a user may desire to aggregate purchasing power from a variety of source[s];
¶[0040]: the Universal Value Exchange (“UVE”) provides a single place where points/currencies from various program providers 110 can be managed, redeemed, exchanged 112b, or linked to a wallet),
the financial integration platform comprising:
a mobile application (SALMON: ¶[0105]: virtual wallet mobile app facilitate and greatly enhance the shopping experience of consumers; ¶[0046]: The customer may enroll in the exchange program with the loyalty broker by accessing a customer facing portal, a web or mobile application, a wallet having loyalty broker facilities.);
a website (SALMON: ¶[0046]: The customer may enroll in the exchange program with the loyalty broker by accessing a customer facing portal, a web or mobile application, a wallet having loyalty broker facilities);
a server (SALMON: ¶[0050]: The data flow diagram shows flow of data between a user 202a, a client 204a, a UVE server(s) 206a and gift card issuer servers 208a/210a, and target gift card issuer server(s) 207a over a communication network 213a. As shown in the figure, the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server.);
a communication network (SALMON: ¶[0050]: The data flow diagram shows flow of data between a user 202a, a client 204a, a UVE server(s) 206a and gift card issuer servers 208a/210a, and target gift card issuer server(s) 207a over a communication network 213a. As shown in the figure, the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server.);
and a user device to manage a first financial account (SALMON: figure 2A, item 204A and ¶[0050]: In some implementations, the client may include, but is not limited to: a personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, and/or the like (e.g., 204a); ¶[0147]: The user may utilize […] a user wallet device, e.g., 1801b, to access the user's virtual wallet account. For example, the user wallet device may be a personal/laptop computer, cellular telephone, smartphone, tablet, eBook reader, netbook, gaming console, and/or the like);
and a plurality of ATMs (SALMON: ¶[0050]: the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server; ¶[0050]: In some implementations, the client may include, but is not limited to: a point-of-sale terminal, kiosk, ATM, and/or the like );
[…]
wherein said website having a web-based service (SALMON: ¶[0207]: Web browsers and like information access tools may be integrated into PDAs, cellular telephones, and/or other mobile devices. A Web browser may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the Web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses; ¶[0202]: The information server provides results in the form of Web pages to Web browsers, and allows for the manipulated generation of the Web pages through interaction with other program components) ;
wherein said financial integration platform is accessible through said web-based service and said mobile application to enable a user to manage at least said first financial account (SALMON: ¶[0050]: the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server. In some implementations, the user may wish to transfer the value from one gift card to another. The user may then input or select a source gift card and a target gift card and request value transfer from the source gift card to the target gift card at 212.; ¶[0084]: At 524, the user may select a source currency/point program to initiate an exchange transaction. The client may communicate the selected source program to the UVE server which may receive the selection at 526. At 528, the UVE server may parse the message received and may query the rules and restrictions database to determine any rules and restrictions associated with the source program.);
wherein said user device is an electronic device for accessing said mobile application and said website (SALMON: ¶[0050]: In some implementations, the client may include, but is not limited to: a personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, and/or the like);
wherein said server accessible by a plurality of users (SALMON: ¶[0049]: For example, a user A may have a gift card for the Apple Store, but the user never shops in the Apple Store, and would instead prefer to exchange the Apple gift card for a Best Buy gift card. Similarly, another user B may have a Best Buy gift card, but would like to exchange for an Apple Store gift card. In such a situation, the UVE may facilitate the exchange of the Apple and Best Buy gift cards such that both users A and B can have their preferred gift cards. Figure 2A and ¶[0050]: The data flow diagram shows flow of data between a user 202a, a client 204a, a UVE server(s) 206a and gift card issuer servers 208a/210a, and target gift card issuer server(s) 207a over a communication network 213a. As shown in the figure, the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server.);
wherein said server is selected from the group consisting of a centralized server, a distributed server, and a cloud server (SALMON: ¶[0193]: distributed network controllers (e.g., Distributed UVE), architectures may similarly be employed to pool, load balance, and/or otherwise increase the communicative bandwidth required by the UVE controller.; ¶[0187]: Should processing requirements dictate a greater amount speed and/or capacity, distributed processors (e.g., Distributed UVE), mainframe, multi-core, parallel, and/or super-computer architectures may similarly be employed; ¶[0127]: save to “a cloud account”);
wherein said plurality of users access said server through said user device and said communication network (SALMON: ¶[0184]: server responds to the requests of remote users across a communications network; ¶[0183]: the UVE controller 2201 may be connected to and/or communicate with entities such as, but not limited to: one or more users from user input devices 2211; peripheral devices 2212; an optional cryptographic processor device 2228; and/or a communications network 2213.; ¶[0193]: [0193] Network interfaces 2210 may accept, communicate, and/or connect to a communications network 2213. Through a communications network 2213, the UVE controller is accessible through remote clients 2233b (e.g., computers with web browsers) by users 2233a.);
wherein said financial integration platform having a financial account associated with each one of said plurality of users for integrating multiple sources of currency (SALMON: ¶[0040]: [0040] From the point of view of a user 118, the UVE provides a single place where points/currencies from various program providers 110 can be managed, redeemed, exchanged 112b, or linked to a wallet.; ¶[0037]: With reference to FIG. 1B, the UVE controller 116 may act as a gateway or a single point of access between program providers 110, point aggregators 114, merchants 120 and users 118.; ¶[0083]: UVE server may query one or more user databases and/or tables using for example the user ID to identify loyalty programs in which the user is currently enrolled; ¶[0096]: the exchange UI (right) may be displayed. The exchange UI may display various options for selecting a source currency. For example, a user may select the loyalty tab 806a as a source currency. When the loyalty tab is selected a loyalty panel 806b may be displayed. As shown, the loyalty panel may include a listing of loyalty cards or accounts. The user may select one or more of these loyalty accounts as a source currency. […] while the exchange button 806e allows the user to initiate the exchange.);
and further wherein said multiple sources of currency including deposits from the group consisting of gift card balances, prepaid debit card balances, cash, and coins (SALMON: ¶[0049]: The user may prefer to combine the value of all the gift cards in one gift card or prepaid card, a bank account or obtain cash; ¶[0113]: . The user interface may clearly identify the amount 1112 and the currency 1113 for the transaction. The amount may be the amount payable and the currency may include real currencies such as dollars and Euros, as well as virtual currencies such as reward points. The amount of the transaction 1114 may also be prominently displayed on the user interface. The user may select the funds tab 1116 to select one or more forms of payment 1117, which may include various credit, debit, gift, rewards and/or prepaid cards.; ¶[0155]: the pay network server may generate a query, e.g., 1824, for issuer server(s) corresponding to the user-selected payment options. For example, the user's account may be linked to one or more issuer financial institutions ("issuers"), such as banking institutions, which issued the account(s) for the user. For example, such accounts may include, but not be limited to: credit card, debit card, prepaid card, checking, savings, money market, certificates of deposit, stored (cash) value accounts and/or the like.).
wherein said plurality of ATMs accept said deposits of said multiple sources of currency (SALMON: ¶[0026]: The schematic diagram illustrates that coins, cash and/or other forms of currency and value 101 can be deposited in, for example, a coin input region; ¶[0061]: the routine begins when the machine (e.g., a consumer-operated coin counting kiosk) receives coin, cash and/or other forms of value from a consumer.; ¶[0018]: a consumer operated kiosk is configured to receive loose coins and/or cash from a consumer, and count the coins and/or cash to determine a total value.; claim 14: coin receiving region configured to receive a plurality of coins from a user; ¶[0068]: As the foregoing disclosure illustrates, there are a number of different ways that a consumer-operated kiosk or other machine, or a network of such machines can convert various forms of consumer currency and other forms of value into a form suitable for paperless electronic commerce from; ¶[0062]: the user may execute the transfer request at 270. In one implementation, at 272 the UVE server may update database 219b with updated balances of the source gift card, the target gift card and destination gift card. In one implementation, the UVE server may provide updated gift card balances 274 to the client such that the user may view the changes in the source and destination gift card balances after the transfer.)..
wherein said deposits from said gift cards include an unused balance of each one of said gift cards (SALMON: ¶[0056]: . For example, when source and destination field values in the value card table record reach $o and yet there is residual value left on the card, that residual value may be used to generate such excess balances for the UVE. In one example, the UVE may observe consumers making purchases with merchants accepting such value; ¶[0049]: As another example, a user may have various gift cards in his or her hands or in the wallet. The user may prefer to combine the value of all the gift cards in one gift card or prepaid card, a bank account or obtain cash. In such as situation, the UVE may provide facilities to consolidate the gift card values and automatically apply them in a purchase transaction.; ¶[0062]: the user may execute the transfer request at 270. In one implementation, at 272 the UVE server may update database 219b with updated balances of the source gift card, the target gift card and destination gift card. In one implementation, the UVE server may provide updated gift card balances 274 to the client such that the user may view the changes in the source and destination gift card balances after the transfer; ¶[0067]: In one implementation, the UVE server may update a value card table record (e.g., 2219u) to deallocate the user 202C from the gift card once it has been liquidated and an equivalent value has been provided. In one implementation, upon liquidation at 289, the user may be sent the updated gift card balance message 292 notifying that the gift card has been liquidated with no balance remaining in the gift card. In a further implementation, the user may also be notified of the deposit of the equivalent amount in a user designated account, statement credit, cash, and/or the like. ).
and further wherein said deposits from said prepaid debit cards include an unused balance of each one of said prepaid debit cards (SALMON: ¶[0034]: the user may have retained purchasing power in various currency types across various ecosystems. For example, the user may have access to currencies such as, but not limited to: a financial account (checking, savings, debit card, credit card, open and closed loop gift cards, prepaid cards, current account, money market, etc.) […] and/or the like.; ¶[0034]: In some implementations, the user may desire to convert purchasing power available in one currency ecosystem to another currency utilized in a completely different ecosystem.; ¶[0113]: The user may select the funds tab 1116 to select one or more forms of payment 1117, which may include various credit, debit, gift, rewards and/or prepaid cards; ¶[0151]: the pay gateway server may […] process various types of transactions including, but not limited to: […] prepaid card, B2B and/or like transactions. ¶[0155]: In some embodiments, the pay network server may generate a query, e.g., 1824, for issuer server(s) corresponding to the user-selected payment options. For example, the user's account may be linked to one or more issuer financial institutions ("issuers"), such as banking institutions, which issued the account(s) for the user. For example, such accounts may include, but not be limited to: […] prepaid card; ¶[0056]: The UVE may aggregate such excess balances over time by apportioning value from records in the UVE database, e.g., value card 2219u);
SALMON does not expressly disclose the following limitations, which YAHN however, teaches:
wherein said plurality of ATMs having an ATM database connected to said server (YAHN: ¶[0043]: In the illustrated embodiment, one or more consumer kiosks 100a-n (e.g., consumer coin counting kiosks) can be operably connected to a first host computer 760a via one or more communication links; ¶[0043]: "back-end" accounting systems can be implemented by one or more processing devices operably communicating with one or more databases.; ¶[0054]: The server computer 960 can retrieve and exchange web pages and other content with a database 970. );
[…] deposits from […] “coins” (YAHN: figure 11: receive coin, cash, and/or other form of value at step 1102, Count coin, cash, etc, at 1104, Display options E.g., Mobile wallet, voucher, card, etc at 1106; ¶[0016]: [0016] FIG. 11 is a flow diagram of a machine-implemented routine for converting coins, cash, and/or other forms of value to a mobile commerce platform; ¶[0028]: As described in greater detail below, after a user (not shown) has input funds (e.g., loose coins) into the kiosk 100 and the kiosk 100 has counted the coins to determine a value, the user can position a wireless-enabled mobile device 120 (e.g., a mobile computing device such as a smart phone) in proximity of the kiosk (e.g., within a distance suitable for near field communication (NFC)), and the kiosk can wirelessly transfer the funds, or a portion of the funds to the mobile device 120 (e.g., to an application for implementing mobile commerce with the mobile device 120).; ¶[0030]: Referring first to FIG. 2A, a consumer or user 222 inputs funds (e.g., a plurality of loose coins 224) into the kiosk 100 via the coin receiving region 103. The kiosk 100 can then display or otherwise provide the consumer 222 with various options for converting her coins into other forms of value, including an option for transferring the coin value to a mobile wallet or other mobile account; ¶[0016]: the routine begins when the machine (e.g., a consumer-operated coin counting kiosk) receives coin, cash and/or other forms of value from a consumer. In block 1104, the routine counts the received funds to determine a value. In block 1106, the routine displays (e.g., via the display 106 on the kiosk 100 of FIG. 1) one or more options to the consumer for allocating the value of the received funds. The options can include, for example, receiving a redeemable voucher, a prepaid card, and/or having all or a portion of the funds transferred to a mobile wallet account.)
further wherein each one of said plurality of ATMs having a coin inlet and a cash inlet (YAHN: ¶[0026]: The schematic diagram illustrates that coins, cash and/or other forms of currency and value 101 can be deposited in, for example, a coin input region 103 (e.g., a pivoting coin tray) of a consumer operated coin counting kiosk 100. The kiosk 100 can include a coin counting apparatus for counting the deposited coins and determining a value; [0028]: As described in greater detail below, after a user (not shown) has input funds (e.g., loose coins) into the kiosk 100 and the kiosk 100 has counted the coins to determine a value, the user can position a wireless-enabled mobile device 120 (e.g., a mobile computing device such as a smart phone) in proximity of the kiosk (e.g., within a distance suitable for near field communication (NFC)), and the kiosk can wirelessly transfer the funds, or a portion of the funds to the mobile device 120 (e.g., to an application for implementing mobile commerce with the mobile device 120).; ¶[0030]: a consumer or user 222 inputs funds (e.g., a plurality of loose coins 224) into the kiosk 100 via the coin receiving region 103. The kiosk 100 can then display or otherwise provide the consumer 222 with various options for converting her coins into other forms of value, including an option for transferring the coin value to a mobile wallet or other mobile account. Such options may include using the transferred funds to top off an existing mobile wallet or virtual gift card, or to create a new mobile account.; ¶[0042]: In some embodiments, the kiosk 100 can transfer coin, cash and/or other forms of value to virtual gift cards for use in a closed loop marketplace; ¶[0057]: the routine begins when the consumer or other user deposits coins, cash and/or other forms of value […] into a consumer operated kiosk (e.g., the kiosk 100 of FIG. 1) or other suitable machine for counting the deposited funds to determine a value.; ¶[0068]: consumers can use such a kiosk to quickly convert coins and/or cash into "closed loop" virtual gift cards that can be activated, reloaded with funds; ¶[0071]:consumers can top off their existing mobile wallets or virtual gift card accounts using coins, cash and/or other funds deposited in a wirelessly-enabled kiosk).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SALMON, which discloses systems and methods of cross-ecosystem currency exchange (SALMON abstract) and interacting with a Universal Value Exchange system via ATMs (SALMON ¶[0050]) with the technique of YAHN, in order to provide consumers with additional options for converting loose coins, cash, etc. to other forms (YAHN ¶[0005]).
Regarding claim(s) 19,
The combination of SALMON and YAHN teaches the financial integration platform of claim 18,
SALMON further discloses:
wherein said financial integration platform is accessible through said web-based service and said mobile application (SALMON: ¶[0050]: As shown in the figure, the user 202a may access the UVE web page or application using the client 204a to communicate with the UVE server.)
SALMON does not expressly disclose the following limitations, which YAHN however, teaches:
to enable a user to send information from said at least said first financial account from said plurality of ATMs to said user device (YAHN: ¶[0019]: If the consumer wishes to have all or a portion of the deposited value transferred to a mobile device, the consumer enters a device address (e.g., a phone number) and positions the device within a suitable range of the kiosk (e.g., within a suitable range for near field communication (NFC)). In some embodiments, the kiosk then wirelessly communicates (via, e.g., a Short Message Service (SMS) text message) the value information to the mobile device. In other embodiments, the kiosk can transfer or otherwise communicate the value information to the mobile device via a temporary wired connection, such as a USB port, electronic docking station, etc. Once transferred, the funds can then be used to make wireless purchases of goods and/or services via, for example, a virtual gift card account and/or other facilities implemented by the mobile device; ¶[0031]: For example, the display page 230 can include a dialogue box 232 instructing the user 222 to enter her mobile phone number so that the kiosk can transfer (e.g., wirelessly transfer) the value (or at least a portion of the value) of the deposited coins to the user's mobile device or other wireless commerce platform; [0033]: In some embodiments, after providing the kiosk 100 with sufficient information so that the kiosk can wirelessly contact the desired mobile device, the consumer 222 positions the mobile device (e.g., the mobile device 120) in sufficient proximity to the kiosk 100 so that the kiosk 100 can wirelessly transfer the fund information to the mobile device 120 (e.g., to an application program operating on the mobile device that uses a wireless application protocol (WAP) as the underlining technology). In addition or alternatively, the kiosk 100 can include a suitable electrical connector, port, or docking station (e.g., a USB port) to which the mobile device 120 can be temporarily connected or placed so that the kiosk 100 can transfer the fund information to the mobile device 120 via a wired data connection. After the mobile device 120 and/or the kiosk 100 provides a visual, audible, and/or other indication that the funds have been sufficiently transferred to the mobile device 120, the funds can be used to pay for various items or services at technology-enabled retailers, to purchase items on-line, to obtain loyalty program points, and/or to conduct other commercially-related transactions as illustrated in FIG. 2D.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SALMON, which discloses systems and methods of cross-ecosystem currency exchange (SALMON abstract) with the technique of YAHN, in order to provide consumers with additional options for converting loose coins, cash, etc. to other forms of readily usable and widely accepted payment instruments. (YAHN ¶[0005]).
Claim(s) 20 is rejected under 35 U.S.C. 103 as being unpatentable over SALMON (US 20120233073 A1) in view of YAHN (US 20150025987 A1) in further view of CHANG (US 20140337213 A1)
Regarding claim(s) 20,
The combination of SALMON and YAHN teaches the financial integration platform of claim 19, although SALMON discloses the Universal Value Exchange system communicating with the user via video chat and initiating a video chat between the user and a customer service representative at SALMON ¶[0140], YAHN does not teach the following, which CHANG teaches:
wherein said financial integration platform having a user interface for displaying an expert providing financial advice to said user. (CHANG: ¶[0003]: The present invention relates to an automated teller machine (ATM) enabling video consultation with a consultant during financial transactions and a transaction method using the same.; ¶[00072]: loan consulting, insurance consulting, financial product consulting are financial transaction requests that are classified as types in which the user needs help; ¶[0098]: customer using online banking need help from a bank teller and after identification of the customer through online banking, the ATM requests a consulting service to the second server and automatically connects to the bank teller via video conferencing.; ¶[0057]: the common interface 220 is provided to display details displayed on the display of the ATM on the display of the terminal of the bank teller and to synchronize the displays when a customer requests a consulting service during a financial transaction.)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of SALMON, which discloses a Universal Value Exchange system communicating with the user via video chat and initiating a video chat between the user and a customer service representative (see SALMON ¶[0140]) with the technique of CHANG, in order to enable users to complete a procedure for financial transactions by requesting consultation when the user does not know information or procedure (CHANG ¶[0007]) or needs help (CHANG ¶[0014]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BOLKO HAMERSKI whose telephone number is (571)270-7621. The examiner can normally be reached Monday-Friday 10:00 AM to 6:00 PM.
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, BENNETT SIGMOND can be reached at (303) 297-4411. 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.
BOLKO HAMERSKI
Examiner
Art Unit 3694
/BOLKO M HAMERSKI/ Examiner, Art Unit 3694
/BENNETT M SIGMOND/ Supervisory Patent Examiner, Art Unit 3694