Offers (e.g., coupons) are a useful marketing tool to enhance brand loyalty and introduce new products. By allowing customization of the effective duration and value of an offer, an offer provides a flexible incentive for a user to purchase a particular product or line of products.
Conventionally, offers have been available in printed form from sources such as newspapers. Increased adoption of electronic sources of information such as the world-wide-web, however, has led to the increase in popularity of electronic offers. Further, due to the nature of electronic content, it is possible for such offers to be forwarded from one user to another.
In addition, many users now own and operate a mobile phone or other mobile communication device. This renders such users accessible to the distribution of electronic coupons as they do their shopping, and moreover allows such distributed electronic coupons to be redeemed directly at the store location.
Accordingly, there is a need in the art for methods and systems allowing for the distribution and use of electronic coupons by mobile electronic devices.
Embodiments can relate to systems and methods involving viral offers. In one embodiment, a viral offer is sent to a communication device associated with a first user enrolled with a viral offer program operated by a viral offer server computer. After the viral offer is sent, an authorization request message for a transaction conducted by a second user is received. After receiving the authorization request message, a viral offer record associated with the viral offer is accessed. The viral offer record includes a velocity limit, and if the velocity limit has not been met, the velocity limit is updated.
In another embodiment, a first user enrolls with the viral offer server computer before the viral offer is received. Enrolling with the viral offer server computer involves associating the user with a financial account.
In yet another embodiment, before receiving the authorization request message for the transaction conducted by the second user, a relevant set of users including the second user is sent to the communication device associated with the first user.
These and other embodiments of the invention are described in further detail below.
a)-(c) are diagrams that show how various records relating to a viral offer are updated, according to example embodiments.
Embodiments of the invention relate to methods and systems of using a payment processing network to track and process viral offers. As described below, a “viral offer” may refer to an electronic offer that can be transferred or copied between users. To track viral offers, embodiments of the invention may require the recipient of a viral offer to enroll in a cross-merchant or cross-issuer viral offer program before the viral offer can be used. Processing viral offers through a payment processing network provides a number of advantages, such as leveraging existing transaction equipment, providing multiple merchant or issuer viral offers, and tracking the effectiveness of viral offers.
Additionally, in embodiments of the invention, methods and systems can control the effects of viral offers in a number of ways. For example, the system may limit the number of times a viral offer can be redeemed (e.g., a “velocity limit” as described below). The velocity limit may be a global limit tied to the viral offer. The velocity limit may also be tied to an enrolled account associated with the system. Such control over viral offers may limit the risk to merchants or issuers by preventing a viral offer from being transferred to and redeemed by an undesirably large number of users. At the same time, such control over viral offers may provide sufficient but reasonable exposure to the viral offer campaign. By tying viral offers to an enrolled account associated with the system, embodiments of the invention may limit the ways fraudsters can circumvent velocity limits (e.g., by preventing the creation of fake accounts to receive additional offers).
To illustrate, a user may enroll in a viral offer program. A viral offer may then be sent to a mobile communication device (e.g., a smart phone) of the user, in the form of a Short Message Service (SMS) message, e-mail message, or any other suitable mode of communication over the Internet, a cellular network, or other wireless network. Once received, the user may want to send the viral offer to a second user. The viral offer may be forwarded to a viral offer server computer contained within or associated with a payment processing network. The viral offer server computer may determine whether the second user is enrolled in the viral offer program, and if so, send the viral offer to the second user. If the second user is not enrolled in the viral offer program, the viral offer server computer can send an enrollment request message in the form of an SMS, e-mail message, or any other suitable mode of communication over the Internet, a cellular network, or other wireless network, to a mobile communication device (e.g., a smart phone) associated with the second user prior to sending the viral offer. When the second user attempts to redeem the viral offer using the smart phone, or a credit card, debit card, or other portable consumer device, an authorization request message can be sent through the payment processing network and received by the viral offer server computer. After receiving the authorization request message, the viral offer server computer can access a record associated with the viral offer to determine if the velocity limit has been met. If the velocity limit has not been met, the viral offer server computer can update the velocity limit contained in the record. The viral offer can then be applied to the transaction by the payment processing network, the merchant conducting the transaction with the second user, or by the issuer associated with the payment account used by the second user to make the transaction.
Prior to discussing the example embodiments of the invention, a further description of some terms is provided below for a better understanding of the described embodiments.
As used herein, an “authorization request message” can refer to a message, or sequence of messages, that requests an issuer of a payment card or payment account to authorize a transaction. An authorization request message according to an embodiment of the invention may comply with ISO (International Organization for Standardization) 8583, which is a standard for systems that exchange electronic transactions made by cardholders or account holders using their payment accounts. An authorization request message according to other embodiments may comply with other suitable standards.
As used herein, an “authorization response message” can refer to a message, or sequence of messages, that responds to a merchant's and/or acquirer's request to authorize a transaction. An authorization response message according to an embodiment of the invention may comply with ISO 8583, which, as described above, is a standard for systems that exchange electronic transactions made by cardholders or account holders using their payment accounts.
As used herein, a “viral offer” can refer to an electronic offer that can be transferred or copied between users. A viral offer may be in the form of an electronic coupon, and may be redeemed directly at the store location or website of the merchant associated with the offer.
As used herein, a “viral offer program” can refer to program offered by a merchant or issuer that allows enrolled users to transfer or copy viral offers subject to merchant or issuer-defined restrictions.
As used herein, a “viral offer server computer” can refer to a server computer that performs functions related to the operation of a viral offer program. As described below, a server computer can be a powerful computer or cluster of computers. For example, a server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. A server computer may also be a database server coupled to a Web server. The viral offer server computer may use a payment processing network to transmit and receive messages associated with viral offers. Additionally, the viral offer server computer may have access to a number of databases and may include a number of modules used for performing functions relating to the operation of a viral offer program.
As used herein, “transaction data” can include data contained in an authorization request message. For example, transaction data can include a transaction amount, a credit card or payment account number, cardholder or account holder information (name, date of birth, address, phone number, etc.), a card verification value, a bank identification number (BIN), expiration date, loyalty account information, etc. Additionally, transaction data may include viral offer data. For example, transaction data may include a viral offer identifier. The viral offer data can be contained in an authorization request message or in a standalone message.
As used herein, a “payment processing network” can include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™. Payment processing networks such as VisaNet™ are able to process credit card transactions, debit card transaction, and other types of commercial transactions. VisaNet™, in particular, includes a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services.
As used herein, a “viral offer record” can include a record that stores information relating to a viral offer. In particular, a viral offer record may include a velocity limit field, a viral offer chain, and other information.
As used herein, “viral offer data” can include data describing a viral offer. For example, viral offer data can include a viral offer identifier.
As used herein, a “velocity limit” can include a limit on the number of times a viral offer can be redeemed. A velocity limit may allow a provider of a viral offer program (e.g., a merchant or issuer) to limit the potential costs of the viral offer program. A velocity limit may allow the offer provider to deterministically define a maximum number of viral offers that can be redeemed during the lifetime of the viral offer program. A velocity limit can be a global limit on the total number of redemptions allowed across multiple users, or can be a limit applied in a more localized context. For example, a velocity limit can be tied to a specific user so that the number of redemptions is not disproportionately consumed by the user. Additionally, a velocity limit can be tied to a time period, so that the offer provider can gauge the success and costs of the viral offer program.
As used herein, a “viral offer chain” can define the path of a viral offer. As used herein, a “path” can refer to the sequence of users that a viral offer passes.
As used herein, a “relevancy filter” can limit the users that can receive viral offers to those users that are most relevant. For example, a relevancy filter can limit the users that can receive viral offers based on the users' transaction history, viral offer forwarding history, location, and third-party data.
As used herein, an “enrollment request” can include a message, from a user to a viral offer server computer, containing certain pieces of information allowing the user's participation in a viral offer program. For example, in an enrollment form supplied electronically to the user, the prospective user can provide information such as the telephone number of their mobile communication device, a financial account identifier, a security password, preferences regarding the types of viral offers that the user wishes to receive, and other information.
As used herein, a “settlement message” can include a message sent to an issuer and/or an acquirer including data describing the net financial position of the entities involved in a payment transaction.
As used herein, a “communication device” can include a mobile communication device such as a smart phone, smart card, cellular phones, personal digital assistant (PDAs), pager, smart media, transponders, tablet computers, and the like. A communication device can also include a personal computer, a laptop computer, a television, etc.
Embodiments of the invention are directed to the use of mobile communication devices, and methods and systems employing them.
The acquirer computer 104 may be operated by a bank that has a merchant account. The issuer computer 128 may also be operated by a bank, but can also be operated by a business entity such as a retail store. Some entities are both acquirer computers and issuer computers, and embodiments of the invention may include such entities. The issuer computer 128 may operate as a server computer, which may have a computer readable medium comprising code for performing the functions that the issuer computer 128 performs. The issuer computer 128 may also store payment account information and other information.
The first user 130 and a second users 131 may be individuals, or organizations such as businesses that are capable of purchasing goods or services.
As seen in
As seen in
To illustrate,
In some embodiments, information in the memory may also be in the form of data tracks that are traditionally associated with credit cards. Such tracks include Track 1 and Track 2. Track 1 (“International Air Transport Association”) stores more information than Track 2, and contains the cardholder's name as well as account number and other discretionary data. This track is sometimes used by the airlines when securing reservations with a credit card. Track 2 (“American Banking Association”) is currently most commonly used. This is the track that is read by ATMs and credit card checkers. The ABA (American Banking Association) designed the specifications of this track and all world banks abide by it. It contains the cardholder's account, encrypted PIN, plus other discretionary data.
The mobile communication device 132 may further include a contactless element 132(g), which may typically be implemented in the form of a semiconductor chip (or other data storage element) with an associated wireless transfer (e.g., data transmission) element, such as an antenna. Contactless element 132(g) may be associated with (e.g., embedded within) mobile communication device 132 and data or control instructions transmitted via a cellular network may be applied to contactless element 132(g) by means of a contactless element interface (not shown). The contactless element interface functions to permit the exchange of data and/or control instructions between the mobile device circuitry (and hence the cellular network) and an optional contactless element 132(g).
Contactless element 132(g) may be capable of transferring and receiving data using a near field communications (“NFC”) capability (or near field communications medium) typically in accordance with a standardized protocol or data transfer mechanism (e.g., ISO 14443/NFC). Near field communications capability is a short-range communications capability, such as RFID, Bluetooth™, infra-red, or other data transfer capability that can be used to exchange data between the mobile communication device 132 and an interrogation device. Thus, the mobile communication device 132 may be capable of communicating and transferring data and/or control instructions via both cellular network and near field communications capability.
The mobile communication device 132 may also include a processor 132(c) (e.g., a microprocessor) for processing the functions of the mobile communication device 132 and a display 132(d) to allow a user to see phone numbers and other information and messages. The mobile communication device 132 may further include input elements 132(e) to allow a user to input information into the device, a speaker 132(f) to allow the user to hear voice communication, music, etc., and a microphone 132(i) to allow the user to transmit her voice through the mobile communication device 132. The mobile communication device 132 may also include an antenna 132(a) for wireless data transfer (e.g., data transmission).
A communication device may be associated with a first user, and may comprise a processor, and a computer readable medium coupled to the processor, wherein the computer readable medium comprises code executable by the processor for implementing a method comprising: sending an enrollment request message to a viral offer server computer, wherein the enrollment request message associates the first user with a financial account, receiving a viral offer, and forwarding the viral offer to a communication device associated with a second user.
A communication device may also comprise a processor, and a computer readable medium coupled to the processor, wherein the computer readable medium comprises code executable by the processor for implementing a method comprising: receiving a viral offer, and interacting with an access device to conduct a transaction, wherein conducting the transaction comprises sending transaction data to the access device, and wherein the access device is configured to generate and send an authorization request message comprising the transaction data to a viral offer server computer configured to: receive the authorization request message, after receiving the authorization request message, accessing a viral offer record associated with the viral offer, wherein the viral offer record includes a velocity limit, and if the velocity limit has not been met, updating the velocity limit.
Returning to
The payment processing network 126 may operate as a server computer. A server computer is typically a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The payment processing network 126 may use any suitable wired or wireless network, including the Internet.
The merchant computer 102 may also have, or may receive communications from, an access device 134 that can interact with the mobile communication device 132. In an embodiment of a system of
The access device 134 according to embodiments of the invention can be in any suitable form. Examples of access devices include point of sale (POS) devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, and the like.
While not shown in
In a typical purchase transaction, the first user 130 purchases a good or service through the merchant computer 102 using a portable consumer device 140 or a mobile communication device 132 such as a cellular phone. The first user's mobile communication device 132 can interact with an access device 134 such as a POS (point of sale) terminal communicatively coupled to the merchant computer 102. For example, the POS terminal may be a contactless reader, and the mobile communication device 132 may be a contactless device. In certain embodiments, the mobile communication device may be a mobile communication device such as shown in
The access device 134 may then send an authorization request message to the merchant computer 102 for forwarding to the acquirer computer 104. After receiving the authorization request message, the authorization request message may then be sent by the acquirer computer 104 to the payment processing network 126. The payment processing network 126 may then forward the authorization request message to the issuer computer 128 associated with the issuer of mobile communication device 132.
After the issuer computer 128 receives the authorization request message, the issuer computer 128 may send an authorization response message back to the payment processing network 126 to indicate whether the current transaction is authorized (or not authorized). The payment processing network 126 may then forward the authorization response message back to the acquirer computer 104. The acquirer computer 104 may then send the response message back to the merchant computer 102.
After the merchant computer 102 receives the authorization response message, the access device 134 at the merchant site may then provide the authorization response message for the user 130. The response message may be displayed by the access device 134, or may be printed out on a receipt.
At the end of the day, a normal clearing and settlement process can be conducted by the payment processing network 126. A clearing process is a process of exchanging financial details between and acquirer computer and an issuer computer to facilitate posting to a user's account and reconciliation of the user's settlement position.
The payment processing network 126 may be communicatively coupled to a viral offer server computer 127. The viral offer server computer 127 may perform functions related to the operation of a viral offers program. For example, the viral offer server computer 127 may comprise a server computer including a processor, and a computer readable medium coupled to the processor, wherein the computer readable medium comprises code executable by the processor for implementing a method comprising: sending a viral offer to a mobile communication device associated with a first user, wherein the first user is enrolled with a viral offer program operated by a viral offer server computer, receiving an authorization request message for a transaction conducted by a second user, after receiving the authorization request message, accessing a viral offer record associated with the viral offer, wherein the viral offer record includes a velocity limit, and if the velocity limit has not been met, updating the velocity limit. In some embodiments, the viral offer server computer 127 operates separately and independently from the payment processing network 126, while in other embodiments the viral offer server computer and the payment processing network 126 are incorporated in a server, as shown by the dotted box 129.
As shown in
With reference to
Enrollment module 202 may provide an interface for potential users to enroll in a viral offer program. Enrollment module 206 may be configured to receive from potential users certain pieces of information allowing their participation in the viral offer program. For example, in an enrollment form supplied electronically to the user, the user can provide information such as the telephone number of their mobile communication device, an alias, an e-mail address, a financial account identifier, a security password, preferences regarding the types of viral offers that they wish to receive, and other information.
The viral offer generator module 204 may generate viral offers based on a number of factors. For example, a viral offer can be generated based on a triggering condition defined, for example, by a merchant or issuer sponsoring the viral offer program. In another example, the viral offer generator module 204 can generate an offer based on a first user requesting the viral offer server computer 127 to forward a viral coupon to a second user, as further described below. When the viral offer generator module 204 generates a viral offer, the viral offer generator module 204 may perform operations that associate the generated viral offer with the user. For example, the viral offer generator module 204 may store a viral offer record identifier in a user record associated with the user receiving the viral offer.
The viral offer tracking module 206 can track how a viral offer is forwarded from one user to another. For example, as described below, the offer tracking module 206 may maintain a dependency graph to prevent the first user from forwarding a copy of the viral offer to a second user when the second user has already received the viral offer. In some embodiments, the dependency graph can also be used to award reward points to users that have sent viral offers to other users that ultimately redeem the viral offer.
The relevancy module 208 may use a relevancy filter to return a list of relevant users. The relevancy filter can be used to identify a set of users that are relevant to the merchant or issuer conducting the viral offer campaign. The relevancy filter can also be used to identify a set of users that are interested in receiving the viral offer. The relevancy filter is further described below.
The viral offer server computer 127 may be a server computer that executes the various modules. As described above, a server computer is typically a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The viral offer server computer 127 may use the payment processing network 180 to transmit and receive viral offer messages. As described herein, the viral offer server computer 127 may also be contained within the payment process network 180.
The viral offer server computer 127 may also have access to a number of databases. In particular, the viral offer server 127 may have access to a user database 212 to store information regarding a user's involvement in the viral offer program, a viral offer database 214 to store viral offer criteria and attributes, and a transaction database 216 to store transaction data received from the payment processing network 126.
Some of the embodiments described below may use a viral offer system like the one described above, or any suitable combination of components in the viral offer system.
Example embodiments of the present invention relate to methods and apparatuses which allow distribution, sharing, and/or redemption of viral offers using a mobile communication device. Various embodiments of such a system are described in the following figures.
In step 302, a user enrolls with a viral offer program operated by the viral offer server computer 127. For example, the user can navigate to the enrollment website of the viral offer server computer 127 utilizing a web browser on a mobile communication device. Upon visiting the enrollment website of the viral offer server computer 127, the user can select a link or button causing an enrollment request message to be sent from the mobile communication device to the viral offer server computer 127 indicating that the user requests to enroll in the viral offer program. After receiving the enrollment request message, the viral offer server computer 127 can request the user to submit identification and validation information by sending a validation request message to the mobile communication device. Examples of such requested identification information include the user's name, the telephone number of the user's mobile communication device, an e-mail address, financial account identifiers, and optional aliases. The enrollment module 202 can also send a validation request message to the mobile communication device to verify that the user has read the appropriate disclaimers and affirmatively indicate that they seek to opt-in to the viral offer program. Throughout the enrollment process, messages passed between the mobile communication device and viral offer server computer 127 can be in any suitable electronic form, including SMS, e-mail, or any other suitable mode of communication over the Internet, a cellular network, or other wireless network.
Identification and validation information entered by the user can be sent as a validation response message from the mobile communication device to the viral offer server computer 127 and then verified by the enrollment module 202. Examples of such verification include confirming that the user identified is actually in possession of the mobile communication device, that the mobile communication device belongs to the user, and that any identified financial account belongs to the user. The enrollment module 202 can confirm that an identified financial account belongs to the user by requesting confirmation from an issuer computer 128. For example, the enrollment module 202 can send a financial account verification request message to the issuer computer 128 over the Internet or any other suitable channel for exchanging electronic information. In turn, the issuer computer 128 can search a financial account database maintained by the issuer to confirm that the enrollment information is accurate by matching the financial account and identification information provided by the user with information stored on the financial account database. The issuer computer 128 can then send a financial account verification response message back to the enrollment module 202 indicating whether or not the financial account of the user has been verified.
Verifying enrollment based on a financial account associated with an issuer has a number of advantages. For example, as compared to traditional verification processes that verify a working email, verifying a financial account is a comparatively trusted source of verification. Such is the case because, unlike creating a new email address, opening a financial account is relatively difficult. Thus, it is unlikely that a user would open a financial account just to obtain an additional viral offer account. Further, the viral offer server computer 127 can leverage the verification process used by the issuer.
Once the enrollment information for the user is verified, the enrollment module 202 can create a user record in the user database 212. The enrollment module 202 can also store the enrollment information in the user record. For example, the user record can be used to associate the user with the wireless phone number, financial account identifiers, e-mail address, potential aliases, etc. When a user record is created, the enrollment module 202 may assign a user record identifier to the user record. The user record identifier can uniquely identify a user record.
According to step 304, a viral offer may then be sent to the first viral offer client 103 of the first mobile communication device 132 associated with the first user 130. The viral offer may be sent by the viral offer server computer 127 utilizing any one of several types of communications methods. For example, the viral offer server computer 127 may send the viral offer to the first user 130 as an SMS message, an E-mail message, or any other suitable mode of communication over the Internet, a cellular network, or other wireless network.
Upon sending the viral offer to the first user 130, the viral offer generator module 204 can update the user record associated with the first user 130 to link the user record to the viral offer record associated with the viral offer sent to the first user 130. This linking is described in greater detail below.
Once the first user 130 receives a viral offer (e.g., those shown in
In an embodiment, a forwarding request message containing the contact information for the second user 131 can be transmitted from the first viral offer client 103 to the viral offer server computer 127. This is shown as step 306. Upon receipt, the viral offer generator module 204 can forward the viral offer to the second viral offer client 105 of the second mobile communication device 133 associated with the second user 131. This is shown as step 308. The viral offer may be forwarded to the second user 131 utilizing any one of several types of communications methods. For example, the viral offer generator module 204 can send the viral offer to the second viral offer client 105 utilizing an SMS message, an E-mail message, or any other suitable mode of communication over the Internet, a cellular network, or other wireless network.
In an embodiment, prior to forwarding of the viral offer to the second user 131 (step 308), the viral offer server computer 127 can first perform enrollment verification steps to determine whether the second user is enrolled in the viral offer program. For example, the viral offer server computer 127 can attempt to match the contact information of the second user 131 with a user record contained in the user database 212. If a user record for the second user 131 exists, the viral offer server computer can update the user record to link it to the viral offer record associated with the viral offer. The viral offer can then be forwarded to the second user 131 (step 308). If no matching user record is found (e.g., if the second user 131 is not enrolled in the viral offer program), the enrollment module 202 can send a validation request message (not shown) to the second user 131 requesting identification and validation information for enrollment. The enrollment process for the second user 131 may involve the same steps as described above for the enrollment of the first user 130. Once enrolled in the viral offer program, the viral offer server computer can create a user record for the second user 131, link the user record to the viral offer record associated with the viral offer, and forward the viral offer (step 308) to the second mobile communication device 133 associated with the second user 131.
In another embodiment, as seen in
The viral offer tracking module 206 of the viral offer server computer 127 may track various measurements related to the viral offer during the lifecycle of a viral offer. For example, the viral offer tracking module 206 may track the users who have received the viral offer.
In particular,
User record 602 is a record that may store information relating to the first user 130. As shown in
User record 606 is a record that may store information relating to the second user 131. Similar to user record 602, user record 606 may also include a viral offer identifier field 606(a). However, in comparison to user record 602, the viral offer identifier field 606(a) does not store an viral offer identifier, as is identified by the NIL value. Thus, the viral offer identifier field 606(a) does not link the second user 131 to a viral offer. This indicates that the second user 131 has not received any viral offers.
Viral offer record 604 may be a record that stores information relating to a viral offer. In particular, the viral offer record 604 may include a velocity limit field 604(a) and a viral offer chain 604(b).
The velocity limit field 604(a) may allow a provider or administrator of a viral offer program (e.g., a merchant or issuer) to limit the potential costs of a viral offer program. In particular, the velocity limit may allow the viral offer provider to deterministically define a maximum number of viral offers that can be redeemed during the lifetime of a viral offer program. Although the velocity limit field 604(a) is described herein as a global number that limits the total number of redemptions allowed across multiple users, it is to be understood that a velocity limit can be applied in a more localized context. For example, in some embodiments, a velocity limit can be tied to a specific user so that the number of redemptions is not disproportionately consumed by one or more users. Additionally, it is to be understood that the velocity limit can be tied to a time period, so that the viral offer provider can gauge the success and costs of the viral offer program.
The viral offer chain field 604(b) may define the path of the viral offer. As used herein, a “path” can refer to the sequence of users that a viral offer passes. Specific structures of a viral offer chain field 604(b) is described in greater detail below. According to
Whereas
With reference back to
In the embodiments described above, viral offer data may be contained in the authorization request message transmitted from the access device 134. If the transaction is contactless and conducted with a mobile communication device (as seen in
If the transaction is conducted with a portable consumer device (as seen in
The viral offer program database can be part of the merchant computer 102, the acquirer computer 104, the payment processing network 126, or other entity. The viral offer program database may also be the same as the viral offer database 214 (see
In the embodiments described above, the transaction data contained in the authorization response message may include the viral offer data. Alternatively, the viral offer data may be communicated prior to, or following, communication between the payment card or mobile communication device and the access device 134 of the merchant. Still further, in some embodiments, some portion of the viral offer data may be transmitted to the viral offer server computer 127 using over the air transmission, such as a cellular network, the Internet, or other wireless network.
Upon receiving the authorization request message including the transaction data, the payment processing network 126 may route the authorization request message to the viral offer server computer 127. Alternatively, if the viral offer server computer 127 is the same entity as the payment processing network 126, the viral offer server computer 127 may receive the transaction data directly from the acquirer computer 104, merchant computer 102, or access device 134.
When the viral offer server computer 127 receives the authorization request message, the viral offer server computer 127 can determine whether the transaction involves a viral offer. This is shown as decision block 312. In an example embodiment, the viral offer server computer 127 can process portions of the received authorization request message. For example, in some embodiments, the authorization request message may store viral offer data in a field of the message. A viral offer identifier is an example of viral offer data that may be stored in the authorization request message to indicate that a viral offer is involved in the transaction. In alternate embodiments discussed above, the viral offer server computer may receive the viral offer data using over the air transmission by the mobile communication device. If the transaction involves a viral offer, step 314 is performed. Otherwise, step 322 is performed.
In another embodiment, the transaction data contained in the authorization response message may include no viral offer data. Instead, the viral offer server computer 127 may have access to one or more database with data tables including viral offer data, user payment account numbers, and identification information for the users associated with the payment account numbers. For example, a merchant or issuer conducting a viral offer program may register with the viral offer system and provide viral offer data to the viral offer server 127. Additionally, a user may register with the viral offer system to provide a payment account number, information about the user's communication device, and other identification information. In an embodiment, the viral offer data, user payment account numbers, and identification information for the user may be stored on the user database 212 and the viral offer database 214. When the viral offer server 127 receives an authorization request message containing the payment account number and merchant information, the viral offer server computer 127 can match the information with the data tables stored on the user database 212 and viral offer database 214 to determine whether the transaction involves a viral offer. If the transaction involves a viral offer, step 314 is performed. Otherwise, step 322 is performed.
According to step 314, the viral offer server computer 127 accesses a viral offer record associated with the viral offer being used in the transaction. In some embodiments, the viral offer server computer 127 can utilize the viral offer data to search the viral offer database 214 to identify information regarding the viral offer being redeemed by the user. For example, the transaction data may include a viral offer identifier that can be used to locate the viral offer record. With reference to
In some embodiments, the viral offer server computer also verifies that the user is authorized to redeem the viral offer. For example, the viral offer server computer 127 may query the user database 212 to determine if the user is linked with the viral offer being redeemed. For example, the transaction data may include user specific data that the viral offer server computer 127 can use to locate the user record corresponding to the user making the purchase. For example, the transaction data can include a user identifier assigned to the user record or the primary account number (e.g., a credit card number or debit card number) used in the transaction. Once the user record is located, the viral offer server computer 127 can process the user record to determine if the user record includes a viral offer identifier field (e.g., see 602(a) of
If the viral offer server computer 127 is unable to locate a user record associated with the user attempting to redeem the viral offer (e.g., the second user 131 is not enrolled in the viral offer program), then step 322 may be performed and the transaction may be processed without application of the viral offer, Alternatively, in some embodiments, the enrollment module 202 in the viral offer server computer 127 may send a validation request message (not shown) to the second user 131 requesting identification and validation information for enrollment. This validation request message may be sent to the second user 131 in the form of an SMS message, e-mail message, or utilizing any other suitable means of communication over the Internet, cellular network, or other wireless network. The enrollment process for the second user 131 may involve the same steps as described above for the enrollment of the first user 130. Once enrolled in the viral offer program, the viral offer server computer can create a user record for the second user 131, and link the user record to the viral offer record associated with the viral offer.
Once the viral offer record is accessed, and the viral offer server computer verifies that the user can redeem the viral offer, the viral offer server computer 127 then can determine if a velocity limit is met. This is shown as decision block 314. For example, the viral offer server computer 127 may process the accessed viral offer record to determine if the velocity limit field has reached a predetermined number. For example,
Step 318 involves updating the velocity limit associated with the viral offer being redeemed. In this step, the viral offer may update the velocity limit to reflect that the viral offer is being redeemed by the user. For example,
After the velocity limit is updated, the benefit associated with the viral offer may then be applied to the transaction. This is shown as step 320. Application of the benefit associated with the viral offer can occur in a number of different ways by the viral offer server 127, merchant, or issuer. In one embodiment, the viral offer server computer 127 may forward the authorization request message with the viral offer data to the issuer computer 128 for authorization of the transaction. After authorization and completion of the transaction, the issuer may then provide the user redeeming the viral offer with a statement credit reflecting the benefit of the viral offer. In another embodiment, the viral offer server computer may send a message to the merchant indicating that the merchant should apply the viral offer to the transaction. For example, after receiving an authorization response message indicating authorization of the transaction by the issuer, the viral offer server computer 127 may modify the authorization response message to indicate that the merchant should apply the benefit of the viral offer. The viral offer server computer 127 may then forward the modified authorization response message to the acquirer computer 104 for forwarding to the merchant computer 102. Upon receipt of the modified authorization response message, the merchant may apply the benefit of the viral offer. Alternatively, the viral offer server computer 127 may send a message, separate from the authorization response message, to the merchant indicating that the viral offer should be redeemed. This message can be sent to the acquirer computer 104 for forwarding to the merchant computer 102, or may be sent to the merchant via any other means of transmitting electronic information, including the Internet for example. In another embodiment, after determining that the viral offer is redeemable, the viral offer server computer 127 may modify the authorization request message to apply the benefit of the viral offer. The modified authorization request message may then be forwarded to the issuer computer 128. After receiving an authorization response message reflecting application of the benefit of the viral offer from the issuer computer 128, the viral offer server computer can then forward the authorization response message to the acquirer computer 104 for forwarding back to the merchant computer 102. The application of the benefit of the viral offer may cause, for example, a reduction in the dollar amount associated with the transaction being conducted by the user.
After step 320 or step 312, the payment processing network 126 may process the transaction. As described above, this may involve sending an authorization request message to the issuer computer 128. In this step, transaction data can be stored in the transaction database 216. The transaction database may link the user with details of the transaction. Details of processing a payment transaction are described above.
In some embodiments, after the viral offer is redeemed, the viral offer server computer 127 may trace the viral offer path stored in the user record to reward the users who forwarded the viral offer to users who ultimately redeemed the viral offer.
As described above, a viral offer can be forwarded from a first viral offer client 103 to a second viral offer client 105 through the viral offer server computer 127. This technique has the advantage of being able to track the path of the viral offer directly because the viral offer server computer 127 sits in between the two viral offer clients during the exchange. As also described above, a viral offer can be forwarded from a first viral offer client 103 to a second viral offer client 105 without utilizing the viral offer server computer 127 to forward the offer. To track the path of the viral offer, a message can be sent from either mobile communication device to the viral offer server computer 127 indicating that the transfer has occurred.
To begin, a user may interact with a viral offer displayed by the viral offer client running on the mobile communication device to cause the viral offer client to forward the viral offer to a second user. For example, the first user 130 may enter the contact information relating to the second user 131 in contact field 402 (see FIG. 4) and then may select the send field 404 (see
Once the viral notice message is generated, the first viral offer client 103 may send the viral notice message to the second viral offer client 105. This is shown as message 704. It is to be noted that in
For the purpose of illustration,
As described above, selecting links of viral notice messages 800, 900, may cause the second viral offer client 105 to retrieve the viral offer from the viral offer server computer 127 by sending a viral offer request message 706 to the viral offer server computer 127. Viral offer request message 706 may include data stored in the viral notice message, such as a viral offer identifier and a first user identifier. Responsive to receiving the viral offer request message 706, the viral offer server computer 127 may verify that the first user 130 is linked with the viral offer and, if so, update the user record of the second user 131 to link the second user with the viral offer. Further, the viral offer server computer 127 may update the viral offer record to indicate that the first user 130 forwarded the viral offer to the second user 131. These updates may use the data received in the viral offer request message 706.
After updating the user record and the viral offer record, the viral offer server computer 127 may send the viral offer (e.g., as shown in
Although traditional electronic offers can be forwarded across multiple users, such current approaches lack the ability to control the viral nature of offers to those user that are most relevant. In an example embodiment, the relevancy module 208 of the viral offer server computer 127 may limit the users that can receive the viral offers based on a relevancy filter.
The transaction history filter 1002 is a relevancy filter that limits the forwarding of a viral offer based on transaction data that passes through the payment processing network. Such transaction data may be stored in the transaction database 216 shown in
The forwarding history filter 1004 is a relevancy filter that limits the forwarding of a viral offer based on the forwarding history of a user. For example, the forwarding history filter 1004 may filter out users that have a low frequency of forwarding viral offers to other users. Further, the forwarding history filter 1004 may take into account the success of a user's forwards. For example, a user that forwards a viral offer that is ultimately redeemed may be considered more relevant than a user that forwards a viral offer that is not redeemed. In measuring the success of a user's forwards, the forwarding history filter 1004 may take into account the user's absolute number of redemptions or the ratio of redemptions to forwards.
The location filter 1006 may be a relevancy filter that limits the forwarding of a viral offer based on the location of a user. For example, the location filter 1006 may filter out users that are not currently located within a determinable distance from a merchant store or within a specified zip code. To provide location based filtering, a mobile communication device running a viral offer client may periodically transmit location information to the viral offer server computer 127. The location information may be determined using cellular triangulation, a Global Positioning System (GPS), POS Terminal Location, or any other suitable means of determining the location of the mobile communication device,
The third-party data filter 1010 may be a relevancy filter that limits the forwarding of a viral offer based on data from third-party sources. For example, in one embodiment, the viral offer client may receive information from a user's set-top box, such as the channels, programs, or any other information relating to the interaction between the user and the set-top box. For example, third-party data filter 1010 may determine that the user watched a commercial and then, within a determinable time, visited a specified web-site or television channel. Such an interaction can be evidence of a user's interest in a product, and the relevancy filter may limit the forwarding of a viral offer to those interested users.
Although the relevancy module 208 may be described in terms of filtering out users that may receive a viral offer, it is to be appreciated that the relevancy module 208 can similarly rank users based on the relevancy of the user. Further, the relevancy module 208 can filter out users that have already received a viral offer based on the viral path field on a particular viral offer. Still further, a user may set preferences based on the criteria of the viral offer, such as whether the viral offer is over a specified amount or for a particular product, whether the viral offer is sent through a specified channel (email, SMS text message, application PUSH, etc), or whether the user forwarding a viral offer is a friend or contact according to a social networking platform. Lastly, a user may set preferences regarding the number of offers they want to receive within a determinable period of time. Consequently, each viral offer may be assigned a priority value. For example, if a viral offer is assigned a low priority value, the relevancy module 208 may filter out those users who have set their preferences to receive only a small number of viral offers to ensure that these users receive only high priority viral offers.
Any of the elements in figures described herein can use any suitable number of subsystems to facilitate the functions described herein. System 1100 in
For example, the computer may be a desktop, portable, rack-mounted or tablet configuration. Additionally, the computer may be a series of networked computers. Further, the use of other micro processors are contemplated, such as Xeon™, Pentium™ or Core™ microprocessors; Turion™ 64, Opteron™ or Athlon™ microprocessors from Advanced Micro Devices, Inc; and the like. Further, other types of operating systems are contemplated, such as Windows®, WindowsXP®, WindowsNT®, or the like from Microsoft Corporation, Solaris from Sun Microsystems, LINUX, UNIX, and the like. In still other embodiments, the techniques described above may be implemented upon a chip or an auxiliary processing board. Various embodiments may be based upon systems provided by daVinci, Pandora, Silicon Color, or other vendors.
In one embodiment, computer system 1100 may include a monitor 1110, computer 1120, keyboard 1130, user input device 1145, network interface 1150, and the like. In various embodiments, monitor 1110 may be embodied as a CRT display, LCD display, plasma display, direct-projection or rear-projection DLP, microdisplay, or the like. In various embodiments, display 1110 may be used to display user interfaces and rendered images.
In various embodiments, user input device 1145 may be embodied as a computer mouse, trackball, track pad, joystick, wireless remote, drawing tablet, voice command system, and the like. User input device 1145 may allow a user to select objects, icons, text and the like that appear on the display 1110 via a command such as a click of a button or the like. An additional specialized user input device 1145, such a magnetic stripe, RFID transceiver or smart card reader may also be provided in various embodiments. In other embodiments, user input device 1145 may include additional computer system displays (e.g. multiple monitors). Further user input device 1145 may be implemented as one or more graphical user interfaces on such a display.
Embodiments of network interface 1150 may include an Ethernet card, a modem (telephone, satellite, cable, ISDN), (asynchronous) digital subscriber line (DSL) unit, FireWire interface, USB interface, and the like. For example, network interface 1150 may be coupled to a computer network, to a FireWire bus, or the like. In other embodiments, network interface 1150 may be physically integrated on the motherboard of computer, may be a software program, such as soft DSL, or the like.
RAM 1170 and disk drive 1180 are examples of computer-readable tangible media configured to store data such user, account and transaction level data, calculated aggregated data, super keys, sub keys and other executable computer code, human readable code, or the like. Other types of tangible media include magnetic storage media such as floppy disks, networked hard disks, or removable hard disks; optical storage media such as CD-ROMS, DVDs, holographic memories, or bar codes; semiconductor media such as flash memories, read-only-memories (ROMS); battery-backed volatile memories; networked storage devices, and the like.
In the present embodiment, computer system 1100 may also include software that enables communications over a network such as the HTTP, TCP/IP, RTP/RTSP protocols, and the like. In alternative embodiments of the present invention, other communications software and transfer protocols may also be used, for example IPX, UDP or the like.
In various embodiments, computer 1120 may include familiar computer components such as a processor 1160, and memory storage devices, such as a random access memory (RAM) 1170, disk drive 1180, and system bus 1190 interconnecting the above components.
In some embodiments, computer 1120 may include one or more Xeon™ microprocessors from Intel Corporation. Further, in the present embodiment, computer 1120 may include a UNIX-based operating system.
It should be understood that embodiments of the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement the present invention using hardware and a combination of hardware and software
Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a non-transitory computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such non-transitory computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.
The above descriptions are illustrative and are not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.
This application claims the benefit of U.S. Provisional Application No. 61/374,405, filed Aug. 17, 2010, entitled “VIRAL OFFERS,” which is herein incorporated by reference in its entirety for all purposes.
Number | Date | Country | |
---|---|---|---|
61374405 | Aug 2010 | US |