Patent Application
20180374066
The present disclosure generally relates to systems and methods for use in facilitating transactions by transacting users, based on options submitted to the transacting users by originating users and presented to the transacting user through virtual applications.
This section provides background information related to the present disclosure which is not necessarily prior art.
Merchants are known to offer various different products (e.g., goods and services, etc.) for sale to consumers. The products may be offered through virtual merchant locations, for example, in which consumers or others add products to shopping carts, as an initial action toward purchasing the products from the virtual merchant locations. From the shopping carts, consumers are then known to proceed to purchase the products in the shopping carts, or the consumers may save the products for purchase later, or even, save the products to wish lists, which are, in turn, circulated to one or more other consumers of the products. Amazon™ online merchant, for example, offers a wish list feature, in which certain products may be added and then shared from one consumer to another (e.g., via email, etc.).
Later, consumers, in turn, are known to purchase the products with payment accounts, from the shopping carts or wish lists, etc. In so doing, the consumers typically present payment devices to the merchants, where the payment devices are associated with the payment accounts. The payment devices may include, for example, credit cards or debit cards. In addition, the payment devices may include smartphones associated with electronic wallets, or e-wallets (sometimes referred to as virtual wallets, etc.). Regardless of form, upon receipt of the payment devices, the merchants, via point-of-sale terminals, generate and transmit to issuers of the corresponding payment accounts authorization requests relating to the product purchases to confirm that the payment accounts have sufficient funds and/or credit to fund the transactions. If the requests are approved, the merchants continue in the transactions and permit the consumers to leave with the products (or otherwise facilitate delivery of the products to the consumers).
It is also known that payment accounts may have multiple authorized users, who may use the payment accounts to fund different transactions with the merchants. For example, spouses may be authorized users of the same payment accounts.
The drawings described herein are for illustrative purposes only of selected embodiments and not all possible implementations, and are not intended to limit the scope of the present disclosure.
Corresponding reference numerals indicate corresponding parts throughout the several views of the drawings.
Exemplary embodiments will now be described more fully with reference to the accompanying drawings. The description and specific examples included herein are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.
Consumers often use payment accounts to fund transactions for products at merchants (e.g., for goods, services, donations, utilities, etc.). When multiple consumers are involved (e.g., friends, spouses, family members, etc.), one consumer (e.g., an originating consumer, etc.) may communicate, via electronic mail (email) or text message, for example, with another consumer (e.g., a transacting consumer, etc.) to identify a desired product and request that the other consumer perform a transaction for the product. Uniquely, the systems and methods herein permit originating consumers to send options for products to transacting consumers, through virtual wallets associated with the transacting consumers. In particular, for example, upon identifying a desired product at a merchant, an originating consumer requests an option be sent to a transacting consumer for the product. In turn, the merchant contacts an option engine, which solicits a designator of the transacting consumer (in connection with the option request). Upon receipt of the designator, the engine identifies a virtual wallet associated with the transacting consumer and sends the option thereto. The transacting consumer, in turn, is able to view the option, and if desired, select the option, which enables the transacting consumer to interact with the merchant and pay for the product, using payment account credentials provisioned to the transacting consumer's virtual wallet. In this manner, the originating consumer may be able to precisely identify a desired or suggested product for purchase, for example, or other item requiring payment to the merchant, with the transacting consumer then being able to conveniently decide to purchase the product and/or otherwise make payment to the merchant, or not, for example, via his/her virtual wallet. As such, a convenient and/or efficient mechanism for facilitating payment account transactions is provided.
In the illustrated embodiment, the system 100 generally includes a merchant 102, an acquirer 104 associated with the merchant 102, a payment network 106, and an issuer 108 configured to issue payment accounts to consumers, each coupled to (and in communication with) network 110. The network 110 may include, without limitation, a local area network (LAN), a wide area network (WAN) (e.g., the Internet, etc.), a mobile network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts illustrated in
The merchant 102 in the system 100 may include any desired entity associated with products (e.g., associated with goods, services, donations, utilities, etc.) and configured to accept transactions via virtual wallets. As an example, the merchant 102 may include an entity generally associated with offering products for sale to consumers, such as consumers 112 and 114, in exchange for payment. In addition, or alternatively, the merchant 102 may include an entity to which payments are directed (whether in exchange for a product or not), such as, for example, a charity entity, where payments from consumers (such as consumers 112 and 114) to the merchant 102 may be considered donations, etc. Regardless, and as will be described more hereinafter, in association with such products, the merchant 102 is configured to offer options for the products to the consumers to facilitate performance of corresponding transactions by the consumers for the products. And, in connection therewith, the merchant 102 may accept payments for products at one or more merchant locations (e.g., at a brick-and-mortar location, etc.), and/or through one or more virtual locations (e.g., through a network-based application (e.g., a website, etc.), etc.).
The merchant 102 includes a terminal 116 (at its physical location(s)), which may include a point-of-sale, or POS, terminal or other computing device. The terminal 116 includes executable instructions, referred to herein as an application 118, which cause the terminal 116 to operate as described below. In particular, for example, the terminal 116 is configured to identify options for products (e.g., options to purchase goods or services, options to give donations, etc.), as selected by consumers. Such identification is based on inputs/selections at the terminal 116, by the consumers (e.g., manual inputs, product scans, etc.), of the merchant 102 (or potentially of another merchant), of one or more products associated with the merchant 102, of a particular charity associated with the merchant 102, of a donation, etc. The terminal 116 is also configured in some embodiments, at least in part, to perform as a conventional POS terminal, by totaling selected products for a given transaction and an amount to be paid (with tax as applicable), by facilitating payment (e.g., via cash through use of a cash register, via a payment device reader, etc.), and by providing a receipt for the transaction, etc. With that said, the terminal 116 is generally configured to perform one or more operations described herein generally in coordination with the application 118 (even if the application 118 is not specifically referenced), although this is not required in all embodiments.
As indicated above, the illustrated system 100 includes the consumers 112 and 114. As generally used herein, the consumer 112 is an originating consumer, who shops at the merchant 102, for example, and identifies products to be purchased from the merchant 102. Conversely, the consumer 114 is a transacting consumer (or funding user) who often is responsible for initiating and/or providing payment to the merchant 102, for example, for the products identified by the originating consumer 112. In one example, the originating consumer 112 may include a spouse of the transacting consumer 114. In another example, the transacting consumer 114 may include a parent of the originating consumer 112. In still another embodiment, the originating consumer 112 may include a friend or other acquaintance of the transacting consumer 114. Regardless, the originating consumer 112 is generally a person desiring and/or suggesting (to the transacting consumer 114) to purchase a particular product from and/or to make a donation (or other payment) to the merchant 102, and the transacting consumer 114 is a person ultimately deciding whether or not to make payment to the merchant 102 for the particular product (e.g., a decision maker, a permission giver, and/or a decision contributor, etc.).
The transacting consumer 114 is associated with a payment account issued by the issuer 108. In addition, the transacting consumer 114 is associated with a communication device 120, which in the illustrated embodiment generally includes a portable communication device such as a smartphone, a tablet, etc. The communication device 120 includes executable instructions, referred to herein as a virtual wallet 122, that cause the communication device 120 to perform the various operations described herein. In at least one embodiment, the virtual wallet 122 may include a virtual wallet such as, for example, PayPass® from MasterCard®, Apple Pay® from Apple®, PayWave® from Visa®, etc., or other suitable virtual wallet offered by the payment network 106, by the issuer 108, or by other entities. In connection therewith, upon installing the virtual wallet 122 to the communication device 120, the consumer 114 is generally prompted to register his/her payment account (as issued to the consumer 114 by the issuer 108) to the virtual wallet 122 (and provide various payment account credentials, such as, for example, a primary account number (PAN), a card verification codes (CVC), the expiration date, etc.), for subsequent use as described herein (e.g., for use in provisioning his/her payment account to the virtual wallet 122, for use in performing transactions to the payment account through the virtual wallet 122, etc.). With that said, when the communication device 120 is described as configured to perform various operations herein, it should be appreciated that it may be doing so generally in coordination with the virtual wallet 122 (even if the virtual wallet 122 is not specifically referenced), or not. While not shown, the originating consumer 112 may also be associated with a communication device at which a similar virtual wallet is installed.
Referring to
The memory 204, as described herein, is one or more devices that permit data, instructions, etc., to be stored therein and retrieved therefrom. The memory 204 may include one or more computer-readable storage media, such as, without limitation, dynamic random access memory (DRAM), static random access memory (SRAM), read only memory (ROM), erasable programmable read only memory (EPROM), solid state devices, flash drives, CD-ROMs, thumb drives, floppy disks, tapes, hard disks, and/or any other type of volatile or nonvolatile physical or tangible computer-readable media. The memory 204 may be configured to store, without limitation, transaction data, payment credentials, options for products, product/donation descriptions, links to products/donations (and/or merchant network-based applications), and/or other types of data (and/or data structures) suitable for use as described herein. Furthermore, in various embodiments, executable instructions may be stored in the memory 204 for execution by the processor 202 to cause the processor 202 to perform one or more of the operations described herein, such that the memory 204 is a physical, tangible, and non-transitory computer readable storage media. Such instructions often improve the efficiencies and/or performance of the processor 202 that is performing one or more of the various operations herein. It should be appreciated that the memory 204 may include a variety of different memories, each implemented in one or more of the functions or processes described herein.
In addition in the exemplary embodiment, the computing device 200 includes a presentation unit 206 that is coupled to (and is in communication with) the processor 202 (however, it should be appreciated that the computing device 200 could include output devices other than the presentation unit 206, etc.). The presentation unit 206 outputs information (e.g., options, etc.), either visually or audibly, to a user of the computing device 200 such as, for example, to the transacting consumer 114, to users associated with other parts of the system 100, etc. And, various interfaces (e.g., as defined by network-based applications, short message service (SMS) messages, emails, etc.) may be displayed at computing device 200, and in particular at presentation unit 206, to display such information. The presentation unit 206 may include, without limitation, a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic LED (OLED) display, an “electronic ink” display, speakers, etc. In some embodiments, presentation unit 206 includes multiple devices.
The computing device 200 also includes an input device 208 that receives inputs from the user (i.e., user inputs) such as, for example, requests for option selections, etc. The input device 208 is coupled to (and is in communication with) the processor 202 and may include, for example, a keyboard, a pointing device, a mouse, a stylus, a touch sensitive panel (e.g., a touch pad or a touch screen, etc.), a product scanner, another computing device, and/or an audio input device. Further, in various exemplary embodiments, a touch screen, such as that included in a tablet, a smartphone, or similar device (e.g., the communication device 120, etc.), behaves as both a presentation unit and an input device.
In addition, the illustrated computing device 200 also includes a network interface 210 coupled to (and in communication with) the processor 202 and the memory 204. The network interface 210 may include, without limitation, a wired network adapter, a wireless network adapter (e.g., a near field communication (NFC) adapter, a Bluetooth adapter, etc.), a mobile network adapter, or other device capable of communicating to/with one or more different networks, including the network 110. Further, in some exemplary embodiments, the computing device 200 may include the processor 202 and one or more network interfaces (including the network interface 210) incorporated into or with the processor 202.
Referring again to
In general in the system 100, the option engine 124 is configured to expose a service to the merchant 102, as an application programming interface (API), which may be called by the terminal 116 and/or other terminals associated with the merchant 102 (or by a network-based application (e.g., a website, etc.) associated with the merchant 102), to provide for funding of the transaction through one or more virtual wallets (e.g., associated with the originating consumer 112 and/or the transacting consumer 114, etc.). In particular, the API is called to facilitate sending of one or more options to the transacting consumer 114 (and other transacting consumers), as described herein. As such, through the API, the terminal 116, for example, and the option engine 124 are able to communicate, as described herein.
In particular, when the originating consumer 112 decides on a product (or identifies a desired product), for example, to send to the transacting consumer 114, the originating consumer 112 identifies the product to the terminal 116 (e.g., via an input to the terminal 116, etc.) and/or other information related to the purchase of the product (e.g., delivery instructions, etc.). In addition, the originating consumer 112 may provide an instruction to the terminal 116 to fund the transaction with a virtual wallet (e.g., either with his/her virtual wallet or with someone else's wallet, etc.). This may be done prior to or after providing delivery instructions for the product (e.g., an instruction for in-store pickup, a shipping address, etc.) (e.g., directly to the merchant 102, via the option engine 124 as described below, etc.). While the above is described in connection with interaction of the originating consumer 112 with the terminal 116 of the merchant 102, it should be appreciated that the same also applies to interaction of the originating consumer 112 with a network-based application associated with the merchant 102 (e.g., at a computing device 200 accessible by the originating consumer 112 but potentially separate from the merchant 102, etc.).
In turn, in connection with use of a virtual wallet to fund the transaction, the terminal 116 is configured (by the application 118) to call the API, as indicated in
The communication device 120 is configured, via the virtual wallet 122, to then indicate receipt of the option (e.g., by a tone, a vibration, etc.) to the transacting consumer 114. And, in response to an input from the transacting consumer 114, the communication device 120 is configured to launch the virtual wallet 122 and to present the option to the transacting consumer 114 through the virtual wallet 122, for example, by way of a link to a network-based application (e.g., website, etc.) associated with the merchant 102, etc. If the option is selected by the transacting consumer 114 (e.g., if the consumer 114 selects the link, etc.), the communication device 120 is configured to cause the network-based application to display at the communication device 120 in the form of an interface (e.g., via a web browser, etc.), to the transacting consumer 114. The interface may include a description of the product identified/selected by the originating consumer 112, an indication of the merchant 102, an indication of the originating consumer 112, etc., and/or may include a shopping cart with the product included therein (broadly, the interface may include a complete “offer” for the transacting consumer 114 to purchase the product, except for payment account credentials to fund the purchase). Then, upon input from the transacting consumer 114 to provide payment for the product (e.g., selection of a “buy now” input, etc.), the network-based application, and more generally, the merchant 102, is configured to facilitate a purchase transaction for the product, funded by the consumer's payment account via the virtual wallet 122.
In one example transaction for a product (be it for a good, a service, a donation, a utility, etc.) by the transacting consumer 114 (e.g., when the transacting consumer 114 selects the buy now input, etc.), the merchant 102 (e.g., via the terminal 116, via a network-based application associated with the merchant 102, etc.) is configured to retrieve (and/or receive) the payment account credentials for the consumer's payment account from the virtual wallet 122, and to communicate an authorization request for the transaction to the acquirer 104 via the network 110, generally consistent with path B in
Conversely, if the issuer 108 declines the transaction, an authorization message (and, more specifically, an authorization reply) is provided back to the merchant 102 declining the transaction, and the merchant 102 can stop the transaction.
In one example, the originating consumer 112 is shopping at the merchant 102 and identifies a desired product to be purchased by the transacting consumer 114. In doing so, the originating consumer 112 identifies the product to the merchant 102, at 302. In particular, for example, the originating consumer 112 may select the product at a website associated with the merchant 102 (e.g., at the terminal 116 or at another computing device 200 accessible by the originating consumer 112, etc. via a product catalog; etc.), or the originating consumer 112 may obtain the product at the merchant 102 and present the product(s) to the terminal 116 (e.g., scan a barcode or a quick response (QR) code associated with the product, etc.), or the originating consumer 112 may otherwise indicate to the merchant 102 that the product is of interest and, as described herein, should be included in an option to be transmitted to the transacting consumer 114. With that said, it should be appreciated that when the product is presented to the merchant 102, but not specifically identified by the originating consumer 112 to the terminal 116, an employee of the merchant 102 may instead scan or otherwise identify the product to the terminal 116 after it is initially identified by the originating consumer 112 to the merchant 102.
In another example, the originating consumer 112 may identify a donation to be made to the merchant 102 by the transacting consumer 114. In doing so, the originating consumer 112 identifies the donation (broadly, a product) to the merchant 102, at 302. In particular, for example, the originating consumer 112 may select the desired donation at a website associated with the merchant 102 (e.g., at the terminal 116 or at another computing device 200 accessible by the originating consumer 112, etc.), or the originating consumer 112 may otherwise indicate to the merchant 102 that the donation is desired and should be included in an option to be transmitted to the transacting consumer 114.
In either case, when the originating consumer 112 identifies the product to the merchant 102, the originating consumer 112 also requests, at 304, the merchant 102 to send an option to the transacting consumer 114 for the product. This may include an input to the terminal 116 (or other computing device 200 accessible by the originating consumer 112) (e.g., an input requesting to fund a transaction for the product via a virtual wallet, etc.), or this may include a verbal indication to an employee of the merchant 102, etc. With that said, while the above describes the product being identified first and then the request for the option being made, it should be appreciated that in other embodiments the request for the option may be made by the originating consumer 112 prior to or at the same time as identifying the product to the merchant 102. In addition, it should also be appreciated that when the originating consumer 112 identifies a “product,” as referenced herein, the originating consumer 112 may identify any good, service, donation or other interaction with the merchant 102, which then is ultimately associated with a request by the originating consumer 112 for an option for the transacting consumer 114 to make a payment to the merchant 102 (be it in person at the merchant 102, via a website associated with the merchant 102, etc.).
In response to the request by the originating consumer 112 to transmit the option for the product to the transacting consumer 114, the terminal 116 (broadly, the merchant 102) calls an API associated with the option engine 124, at 306 (e.g., the API indicated by line A in
Next in the method 300, the option engine 124 solicits, at 310 (also via the API), from the originating consumer 112 (if not included in the original request from the originating consumer 112), a designator for the transacting consumer 114 who is to ultimately receive the option. The designator may include any suitable indicator for use in contacting the transacting consumer 114 such as, for example, a phone number associated with the communication device 120 of the transacting consumer 114, an email address for the transacting consumer 114, etc. In connection therewith, the option engine 124 may cause an interface to display at the terminal 116 (or other computing device 200 being accessed by the originating consumer 112), via the API, requesting the designator (e.g., from the originating consumer 112, from the employee associated with the merchant 102, etc.).
In addition via the API, the option engine 124 may solicit, from the originating consumer 112, additional information for either (or both) the originating consumer 112 and the transacting consumer 114 (e.g., name, contact information, etc.) (again, if not already included in the original request). For example, as indicated by the dotted box in
The originating consumer 112 then provides the designator for the transacting consumer 114 to the merchant 102, at 314 (e.g., to the terminal 116, etc.). And, as further indicated by the dotted box in
The example interfaces 400 and 500 shown in
Referring again to
Then, once the transacting consumer 114 is identified, the option engine 124 compiles an option for the identified product, at 320. In so doing, for example, the option engine 124 may add the product to a shopping cart for the transacting consumer 114 (along with other products potentially identified by the originating consumer 112), at the virtual wallet 122. Alternatively, the option engine 124 may provide a product link for the product through which the transacting consumer 114 can elect to purchase the product, for example, via the virtual wallet 122 (or otherwise). In either case (and without limitation of the actual form of the option), the compiled option generally includes a complete “offer” for the transacting consumer 114 to purchase the product, but does not include payment account credentials to fund the purchase (e.g., the compiled offer is generally complete except for payment account credentials for a payment account associated with the virtual wallet 122, etc.). Then, the option engine 124 in turn transmits the option (be it through a shopping cart or a particular product link), at 322, to the transacting consumer 114 and, more specifically, to the virtual wallet 122 associated with the transacting consumer 114 (at the communication device 120).
In response, upon receiving the option, the virtual wallet 122 presents the option to the transacting consumer 114, at 324. In particular, in this exemplary embodiment, the virtual wallet 122 causes a ding, tone, vibration, etc. (broadly, a notification), which causes the transacting consumer 114 to become aware of the option. And, when the transacting consumer 114 selects the virtual wallet 122 (to view additional details for the option, etc.), the virtual wallet 122, via the communication device 120 (e.g., via the presentation unit 206, etc.), presents the option to the transacting consumer 114.
Next in the method 300, when the transacting consumer 114 accepts the option, at 326, by selecting the option (e.g., by selecting the link 604 in the option interface 600, etc.), the communication device 120 launches, at 328, a network-based application, which may be generic and directed to a website associated with the selected product or which may be specific to the merchant 102 (e.g., as defined by the link 604 in the option interface 600, etc.). In response, the merchant 102 (and specifically, the launched network-based application) may capture, at 330, the payment account credential(s) for the payment account associated with the transacting consumer 114 from the virtual wallet 122 (such that the payment account credential(s) may then be used to facilitate the purchase transaction for the product identified in the offer (which, as described above, was generally a complete offer for the product but was simply lacking such credential(s)). Alternatively, in response to the acceptance/approval of the purchase option by the transacting consumer 114, the virtual wallet 122 (via the option engine 124) may provide the payment account credential(s) to the merchant 102 (e.g., via the API described above and identified at line A in the system 100, etc.). And, at 332, the merchant 102 presents the product identified by the originating consumer 112 to the transacting consumer 114, in the network-based application. Because the payment account credentials for the transacting consumer's payment account are captured, by the merchant 102, from the virtual wallet 122 (or provided by the virtual wallet 122 to the merchant 102), in this embodiment, the merchant 102 is able to populate the payment account credentials in the website, thereby permitting the transacting consumer 114 to provide payment in connection with the product, as desired, without having to actually enter payment account credentials or provide any details for the transaction (i.e., the transacting consumer 114 merely needs to approve the transaction for it to be funded thereby and proceed).
Finally, when the transacting consumer 114 desires to complete the transaction in connection with the selected product, the transacting consumer 114 selects to provide payment to the merchant 102 via his/her payment account (through the virtual wallet 122), at 334. In various embodiments, the merchant 102 may instead wait to capture the payment account credentials for the payment account associated with the transacting consumer 114, from the virtual wallet 122 (and/or the virtual wallet 122 may wait to provide the payment account credentials to the merchant 102), until the transacting consumer 114 actually selects to provide payment to the merchant 102, at 334 (instead of capturing the credentials in advance, as generally described above). In any case, once the transacting consumer 114 approves the transaction, the merchant 102 then facilitates the transaction for the product, at 336, funded by the transacting consumer's payment account. In other words, the transacting consumer 114 is able to facilitate the transaction for the product by simply selecting the option and/or providing a confirmation to proceed with a transaction for the product identified in the option, without providing any additional information regarding the product or the purchase of the product. The payment account transaction proceeds in substantially the same manner as described for the example transaction in the system 100 (and with reference to path B in
In view of the above, the systems and methods herein provide a mechanism for consumers to suggest products to other consumers, where the other consumers can then make decisions to submit payment for the products, or not. In particular, originating consumers are allowed to identify desired products and transmit options to transacting consumers to selectively provide payment for the products. As such, the methods and systems herein provide convenient manners for the originating consumers to suggest and/or facilitate payment for the products, through collaboration with the transacting consumers (and, for example, in some embodiments, through communication between their virtual wallets, etc.) (and for limiting transactions to their payment accounts to only those approved by the transacting consumers). What's more, the systems and methods herein are applicable to any merchants configured to accept transactions through virtual wallets, and are not necessarily limited to any particular merchants or consumers enrolled in particular merchant accounts. They are also applicable to any desired virtual wallets via communication with the option engine 124.
Again and as previously described, it should be appreciated that the functions described herein, in some embodiments, may be described in computer executable instructions stored on a computer readable media, and executable by one or more processors. The computer readable media is a non-transitory computer readable storage medium. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Combinations of the above should also be included within the scope of computer-readable media.
It should also be appreciated that one or more aspects of the present disclosure transform a general-purpose computing device into a special-purpose computing device when configured to perform the functions, methods, and/or processes described herein.
As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by performing at least one of the following operations: (a) receiving, via an application programming interface (API), from an originating consumer, an identification of a purchase transaction for a product at a merchant; (b) soliciting, from the originating consumer, a designator for a funding user to fund the purchase transaction for the product, the designator indicative of a virtual wallet associated with the funding user; (c) compiling a purchase option for the product including multiple parameters for the purchase transaction, the multiple parameters including a delivery option for the product identified by the originating consumer but not a payment account credential for funding the purchase transaction; (d) transmitting, via the virtual wallet, the purchase option to the funding user; (e) in response to an approval of the purchase option by the funding user, providing a payment account credential associated with the virtual wallet, via the API, to the merchant, thereby permitting the merchant to initiate the purchase transaction for the product; (f) presenting the purchase option to the funding user at a communication device including the virtual wallet; (g) launching a network-based application, at the communication device, in response to a selection of a link by the funding user included in the purchase option; and (g) identifying the funding user in a data structure associated with the computing device based on the designator.
Exemplary embodiments are provided so that this disclosure will be thorough, and will fully convey the scope to those who are skilled in the art. Numerous specific details are set forth such as examples of specific components, devices, and methods, to provide a thorough understanding of embodiments of the present disclosure. It will be apparent to those skilled in the art that specific details need not be employed, that example embodiments may be embodied in many different forms and that neither should be construed to limit the scope of the disclosure. In some example embodiments, well-known processes, well-known device structures, and well-known technologies are not described in detail.
The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. As used herein, the singular forms “a,” “an,” and “the” may be intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms “comprises,” “comprising,” “including,” and “having,” are inclusive and therefore specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is also to be understood that additional or alternative steps may be employed.
When a feature is referred to as being “on,” “engaged to,” “connected to,” “coupled to,” “associated with,” “included with,” or “in communication with” another feature, it may be directly on, engaged, connected, coupled, associated, included, or in communication to or with the other feature, or intervening features may be present. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.
In addition, as used herein, the term product may include, without limitation, a good, a service, a donation, a utility, etc.
Although the terms first, second, third, etc. may be used herein to describe various features, these features should not be limited by these terms. These terms may be only used to distinguish one feature from another. Terms such as “first,” “second,” and other numerical terms when used herein do not imply a sequence or order unless clearly indicated by the context. Thus, a first feature discussed herein could be termed a second feature without departing from the teachings of the example embodiments.
None of the elements recited in the claims are intended to be a means-plus-function element within the meaning of 35 U.S.C. § 112(f) unless an element is expressly recited using the phrase “means for,” or in the case of a method claim using the phrases “operation for” or “step for.”
The foregoing description of exemplary embodiments has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure. Individual elements or features of a particular embodiment are generally not limited to that particular embodiment, but, where applicable, are interchangeable and can be used in a selected embodiment, even if not specifically shown or described. The same may also be varied in many ways. Such variations are not to be regarded as a departure from the disclosure, and all such modifications are intended to be included within the scope of the disclosure.
