Systems, methods, and computer program products for managing contactless transactions

Information

  • Patent Grant
  • 10733596
  • Patent Number
    10,733,596
  • Date Filed
    Friday, October 6, 2017
    6 years ago
  • Date Issued
    Tuesday, August 4, 2020
    3 years ago
Abstract
Systems, methods, and computer program products are provided for managing contactless transactions. A tap notification including at least a first identifier is received. A first counter in a first data set associated with the first identifier is incremented. It is determined if the first counter matches one of a plurality of thresholds. If it is determined that the first counter matches one of a plurality of thresholds, a first status level in the first data set is updated. A first set of benefits from a plurality of benefits stored in a memory based on the first status level is identified. The first set of benefits is associated with the first identifier.
Description
BACKGROUND
Field

The present invention generally relates to systems, methods, and computer program products for managing contactless transactions.


Related Art

Wireless technologies such as near field communications (NFC) standards are increasingly being used to exchange data between devices when placed within a predetermined distance from each other. One use of such technologies is for making contactless transactions including for payments, offers, ticketing, and the like. For example, an NFC-enabled mobile device can include or store information such as payment credentials, commerce benefits (e.g., offers, coupons, loyalty awards, vouchers, rewards, discounts, promotions), and tickets (e.g., train tickets, movie tickets), which are issued by corresponding service providers (e.g., credit card company, merchant, transit authority). Such information can be managed by one or more applets and/or applications (e.g., mobile wallet application) deployed on the mobile device.


The mobile device can, in turn, use the NFC technology to communicate with other NFC-enabled devices such as reader terminals on point-of-sale (PoS) or admissions systems. For example, to redeem an offer and/or make a payment, a mobile device is placed (e.g., by its user) within approximately ten centimeters (or another predetermined and technologically feasible distance) of the reader terminal. Upon being placed within the predetermined distance, the mobile device and reader terminal become communicatively coupled and exchange a number of communications and information to process the requested contactless transaction. Placing the mobile device within a predetermined proximity to the reader terminal so that they can be communicatively coupled is often referred to as performing a “tap” or “wave”. Performing a “tap” or “wave” is described in more detail in U.S. Patent Application Publication Nos. US 2013/0317924 A1 and US 2013/0317927 A1, the contents of which are incorporated herein by reference in their entirety.


Mobile wallet applications on mobile devices are used to centrally manage contactless transactions from a mobile device. For example, mobile wallet applications can manage other applets (e.g., payment applets, security applets) and data (e.g., payment credentials, offers, loyalty rewards) that are used during contactless transactions. That is, mobile wallet applications can control when a certain applet is to be used and when certain credentials or data are communicated with other devices (e.g., reader terminals).


Typically, data such as benefits (e.g., coupons, loyalty rewards, promotions, discounts, certificates, gifts) that are stored on mobile devices for use by mobile wallet applications are openly available to mobile wallet applications and their users. For example, an offer issued by a merchant can be obtained and used by any mobile wallet application.


Given the foregoing, it would be beneficial to distinguish between mobile wallet applications and distribute offers to certain mobile wallet applications based on predetermined criteria. Further, it would be beneficial to assign and manage a status for applications based on the frequency of use of those applications.


BRIEF DESCRIPTION

The example embodiments presented herein meet the above-identified needs by providing systems, methods, and computer program products for managing contactless transactions.


In one example embodiment, a system for managing contactless transactions comprises at least one memory and a processor. The memory is operable to store a plurality of benefits and a plurality of data sets associated with a corresponding identifier. Each data set includes at least a counter and a status level. The processor is coupled to the at least one memory. A tap notification including at least a first identifier is received. A first counter in a first data set associated with the first identifier is incremented. It is determined if the first counter matches one of a plurality of thresholds. A first status level in the first data set is incremented, if it is determined that the first counter matches one of the plurality of thresholds. A first set of benefits from the plurality of benefits based on the first status level is identified. The first set of benefits is associated with the first identifier.


In another example embodiment, a method for managing contactless transactions comprises steps of: receiving a tap notification, the tap notification including at least a first identifier; incrementing a first counter in a first data set associated with the first identifier; determining if the first counter matches one of a plurality of thresholds; updating a first status level in the first data set, if it is determined that the first counter matches one of a plurality of thresholds; identifying a first set of benefits from a plurality of benefits stored in a memory based on the first status level; and associating the first set of benefits with the first identifier.


In yet another example embodiment, a non-transitory computer-readable medium has stored thereon sequences of instructions which when executed by a computer system cause the computer system to: receive a tap notification, the tap notification including at least a first identifier; increment a first counter in a first data set associated with the first identifier; determine if the first counter matches one of a plurality of thresholds; update a first status level in the first data set, if it is determined that the first counter matches one of a plurality of thresholds; identify a first set of benefits from a plurality of benefits stored in a memory based on the first status level; and associate the first set of benefits with the first identifier.





BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the example embodiments presented herein will become more apparent from the detailed description set forth below when taken in conjunction with the following drawings.



FIG. 1 is a diagram of a system for managing contactless transactions, according to an exemplary embodiment.



FIG. 2 is a flow chart illustrating a process for managing contactless transactions, according to an exemplary embodiment.



FIG. 3 is a diagram of a system including an interface for providing membership level information, according to an exemplary embodiment.



FIG. 4 is a block diagram of an exemplary system useful for implementing the present invention.





DETAILED DESCRIPTION

I. Overview


The example embodiments presented herein are directed to systems, methods, and computer program products for managing contactless transactions, which are described herein in terms providing offers based on numbers of contactless transactions performed. This description is not intended to limit the application of the example embodiments presented herein. In fact, after reading the following description, it will be apparent to one skilled in the relevant art(s) how to implement the following example embodiments in alternative embodiments in which other types of data (e.g., loyalty rewards, spending points, admissions tickets, transportation tickets, gaming lives) are assigned and/or provided based on other criteria (e.g., spend, duration of visit).


The terms “tap,” “tap event” and/or the plural form of these terms are used interchangeably herein to refer to the act of placing an NFC-enabled device (e.g., mobile device) within a predetermined proximity of another NFC-enabled device (e.g., terminal reader).


The terms “benefit,” “commerce benefit,” and/or the plural form of these terms are used interchangeably herein to refer to a benefit that may be stored, used and/or applied by a mobile wallet application during a contactless transaction, including offers, loyalty awards, discounts, promotions, certificates gifts, multipliers, and the like.


II. System



FIG. 1 is a diagram of a system 100 for managing contactless transactions, according to an exemplary embodiment. As shown in FIG. 1, system 100 includes a reader terminal 110, mobile devices 120-1, 120-2, . . . , 120-n (collectively “120” or “mobile device(s) 120”), a mobile commerce (MoCom) platform 130, and merchant system 140-1, 140-2, . . . , 140-n (collectively “140” or “merchant systems 140”).


Mobile devices 120 may be, for example, a cellular phone, tablet or the like. Although not illustrated in FIG. 1, each mobile device 120 includes a processor, memory, a contactless frontend (CLF), a baseband modem, and a user interface such as a display screen. A baseband modem is a digital modem that is used for mobile network communications. A CLF is circuitry which handles the analog aspect of contactless or NFC communications and the communication protocol layers of a contactless transmission link. A CLF also is used to exchange data between reader 110 and other storage devices in and/or associated with mobile devices. For example, a CLF may be used to communicate with a secure element (e.g., subscriber identity module (SIM) card) on a mobile device. A secure element may be implemented as a Universal Integrated Circuit Card (UICC), embedded SE card, secure micro secure digital (microSD) card, and the like. A secure element may also be implemented as a virtual system such as a cloud-based architecture or host card emulation (HCE).


Mobile devices 120-1, 120-2, . . . , 120-n include or have stored in their memory, mobile wallet applications 120a-1, 120a-2, . . . , 120a-n, respectively, (collectively “120a” or “mobile wallet applications 120a”), which include instructions that when executed by the processor of the corresponding mobile device 120, cause the mobile device to act as an instrument, for example, for processing contactless transactions.


Contactless transactions may be performed between mobile devices 120 and reader terminal 110, using wireless communications technologies such as NFC. The reader terminal 110 is an NFC-enabled system located, for example, at a point of sale (PoS) terminal and which is used to process a contactless transaction. In one exemplary embodiment, the reader terminal 110 receives a contactless transaction request when a mobile device (e.g., mobile device 120-1) is tapped, waved or placed within a predetermined proximity of the reader terminal 110. The reader terminal 110, in turn, exchanges data over one or more communications with the mobile device 120-1 to complete the contactless transaction. In one exemplary embodiment, during a contactless transaction, a mobile device initiates a tap event and, in turn, transmits offer data to the reader terminal 110 to be applied to the transaction. That is, if the offer data includes a discount, that discount is applied to the balance and the transaction is finalized with a modified (e.g., reduced) balance.


Although only one reader terminal (reader terminal 110) is shown, it should be understood that system 100 may comprise any number of reader terminals.


Commerce benefits (e.g., offers) used during a contactless transaction may be managed by the MoCom platform 130. In one example embodiment, The MoCom platform 130 may include one or more servers, which in turn may include one or more databases (e.g., offer database), for storing offers or offer data, and is configured to manage (e.g., transmit, receive, request, process) offers and their related data. In one exemplary embodiment, the MoCom platform 130 may store and manage mobile commerce data (e.g., offer data, loyalty data, rewards data), merchant data (e.g., information related to merchants associated with commerce data), and rules and/or means for processing redeemed offers, distributing offers to mobile wallet applications, and the like. Examples of data that may be stored by the MoCom platform 130 are described below in further detail with reference to FIG. 2.


The MoCom platform 130 may be a standalone platform, or may be part of a mobile wallet system and/or architecture. The mobile wallet system and/or architecture may include other systems such as a trusted service manager (TSM) and an enterprise service bus (ESB). An ESB and TSM are systems that provide interfaces and/or communications means between multiple systems. For example, an ESB can be used by a MoCom platform 130 to communicate with mobile wallet applications 120a on mobile devices 120. In one exemplary embodiment, the MoCom platform 130 may transmit an offer and/or offer data to a mobile wallet application 120a-1.


The MoCom platform 130 is communicatively coupled to merchant systems 140 over a communications network 150. A merchant system is a system, platform, computer architecture or the like, managed by a merchant (e.g., business, retailer). The merchant system may include a customer relationship marketing (CRM) system, which is used to analyze, manage and distribute offers. In one exemplary embodiment, a merchant system creates an offer and transmits that offer to the MoCom platform 130 to be certified, configured, stored and/or distributed to mobile wallet applications 120a. The creation and management of offers is described in further detail in U.S. Patent Application Publication Nos. US 2014/0032312 and US 2014/0074616, which are incorporated herein by reference in their entirety.


III. Process



FIG. 2 is a flow chart illustrating a process 200 for managing contactless transactions, according to an exemplary embodiment. In particular, managing contactless transactions includes assigning status levels and providing offers to mobile wallet applications based on a number of taps performed by each mobile wallet application.


At block 250, a MoCom platform (e.g., FIG. 1, MoCom platform 130) receives a tap notification from a mobile device (e.g., FIG. 1, mobile device 120-1). The tap notification indicates that a contactless transaction has been initiated, processed and/or completed by a mobile wallet application (e.g., FIG. 1, mobile wallet application 120a-1), for example, at a reader terminal (e.g., FIG. 1, reader terminal 110). The tap notification includes information identifying the mobile device and/or mobile wallet application used to perform the tap. Such identifying information may be, for example, an application identifier (ID) (e.g., mobile wallet ID) corresponding to the mobile wallet application, or other information used to identify the mobile device (e.g., mobile device ID) on which the mobile wallet application is stored. A mobile device ID may be an international mobile equipment identity (IMEI), a mobile equipment identifier (MEID), a Media Access Control (MAC) address, or a similar unique serial number associated with hardware of a mobile device. The tap notification may include other information identifying, for example, a location, reader terminal, merchant, and time where the tap occurred.


It should be understood that the tap notification received by the MoCom platform at block 250 may alternatively and/or additionally be received from a merchant system (e.g., merchant system 140-1) or the reader terminal.


In turn, at block 252, the MoCom platform uses the information included in the tap notification to identify a set (or sets) of data (e.g., offer data) associated with the mobile wallet applications. In one exemplary embodiment, the MoCom platform queries one or more of its databases to locate a counter of a data set associated with the mobile wallet ID included in the tap notification. At block 254, the MoCom platform increments the counter when the tap notification is received from a mobile wallet application or mobile device. When other tap notifications are received from a mobile wallet application or mobile device the MoCom platform similarly increments the counter.


In one exemplary embodiment, a value n of a counter associated with the mobile wallet application x is incremented by one, as shown in the following formula:

counter(x)=++n


At block 256, the MoCom platform determines whether the incremented counter has reached a predetermined threshold. A threshold may be a predetermined value corresponding to a status level or membership level. Table 1 below illustrates a threshold table in accordance with an exemplary embodiment:












TABLE 1





Threshold
Threshold
Status
Membership


Ref. No.
Value
Level
Level


















1
100
1
Gold


2
1,000
2
Silver


3
10,000
3
Platinum









As shown in Table 1, a threshold is a numeric value identifying the number of taps needed to reach a status level or membership level. For example, when a mobile wallet application is used to perform 1000 taps (e.g., counter(x)==1000), the status level and membership level of a mobile wallet application are modified accordingly. Table 2 below illustrates a mobile wallet application record which may be stored by the MoCom platform to track and manage, among other things, the status and membership levels of a mobile wallet application, in accordance with an exemplary embodiment:













TABLE 2







Application ID
Status Level
Membership Level









001
1
Gold



002
1
Gold



003
2
Silver










As shown in Table 2, the mobile wallet application with application ID “001” has been used to perform at least 100 taps (but less than 1000) and has been assigned a status level “1” and “gold” membership level. Although not illustrated in Table 2, a mobile wallet record may also include information such as a mobile device ID (e.g., IMEI, MEID, MAC Address) or any other information that may be used to identify the mobile device associated with the application ID, as well as a date and time when a status level and/or membership level is reached.


To determine, at block 256, whether a mobile wallet application has reached a threshold, the MoCom platform compares the counter of the mobile wallet application to the threshold values in the threshold table. In one exemplary embodiment, determining whether a mobile wallet application has reached (e.g., matches) a threshold is performed in accordance with the following process described below using pseudocode:

















while y < thresholdMAX



   if counter(x) == threshold(y)



      statuslevel(x) = y



   else



      ++y










As illustrated above, y represents the reference number of a threshold; thresholdMAX represents the reference number of the last (e.g., highest) threshold in a list of predetermined thresholds (e.g., 3 in Table 1); counter represents the counter value of a mobile wallet application; x represents the application ID corresponding to a mobile wallet application; and statuslevel represents the value of the status level associated with a mobile wallet application.


If the MoCom platform determines, at block 256, that the counter of the mobile wallet application has not reached a threshold, the process ends (block 258) and the status level and membership levels of the mobile wallet application are not modified. On the other hand, if the MoCom platform determines, at block 256, that the counter of the mobile wallet application has reached a threshold (e.g., the threshold value equals the counter value), the MoCom platform identifies, at block 260, benefits (e.g., offers) associated with the threshold level reached.


That is, at block 260, the MoCom platform uses the threshold reference number and/or status level to identify benefits that are associated with the threshold reached. This may be accomplished by performing a query in an offer database to identify offers having a threshold reference number or status level equal to the threshold reference number or status level, respectively, of the mobile wallet application having reached a threshold. In one exemplary embodiment, if a mobile wallet application reaches the first threshold shown in Table 1, the MoCom platform, at block 260, identifies offers in the offers database that (1) have a threshold reference number equal to “1”, or (2) have a status level equal to “1”.


If the MoCom platform identifies, at block 260, any offers in the offer database that are associated with the threshold reached by the mobile wallet application, the MoCom platform associates the mobile wallet application with those offers. In one exemplary embodiment, the set of offers identified at block 260 may be flagged using the application identifier of the mobile wallet application or a mobile device identifier of the mobile device on which the mobile wallet application is stored.


At block 264, the mobile wallet application may transmit the offers associated with the mobile wallet application at block 262, to the mobile device on which the mobile wallet application is stored. The offers may be transmitted to and stored on (e.g. pushed) the mobile device at a time determined by the MoCom platform. Alternatively, the offers may be transmitted to the mobile device upon receipt of a request front the mobile wallet application (e.g., pulled). Data may be transmitted to the mobile device over a communications network either directly, or via a supplementary system (e.g., ESB).


Transmitting an offer includes sending at least a portion of offer data associated with an offer. Table 3 below illustrates data stored in association with an offer (e.g., data that makes up an offer), in accordance with an exemplary embodiment:










TABLE 3





Element
Description







OFFER_ID
Unique identifier associated with



an offer, assigned by a MoCom


EXT_OFFER_ID
Unique identifier associated with



an offer, assigned by a merchant



or merchant system associated



with the offer


OFFER_NAME
Label or caption associated with



an offer


TITLE
Title associated with an offer


SHORT_DESCRIPTION
Brief description of an offer and



its terms


LONG_DESCRIPTION
Detailed description of an offer



and its terms


SMALL_IMAGE_URI
Unique identifier associated with



an small-size image corresponding



to an offer


LARGE_IMAGE_URI
Unique identifier associated with



a large-size image corresponding



to an offer


BARCODE_ID
Identifier associated with a



barcode (or QR code) corresponding



to an offer


UPCCODE
Type of barcode


TERMS_AND_CONDITIONS
Terms and conditions associated



with an offer


IS_REDEEMABLE
Indicator of whether an offer is in



a state in which it can be used/



redeemed in a transaction


STATUS
State of an offer (e.g., ready for



review, live, expired)


USER_ID
Unique identifier associated with



a user of a mobile device


CREATE_TSTMP
Date and time a record is created


UPDATE_TSTMP
Date and time a record is created


THRESHOLD_REF_ID
Value of one or more membership



levels of a mobile wallet application



at which an offer may be obtained



and/or redeemed


STATUS_LEVEL
Value of one or more status levels



of a mobile wallet application at



which an offer may be obtained and/



or redeemed









The threshold reference number (e.g. THRESHOLD_REF_ID) and status level (e.g., STATUS_LEVEL) associated with an offer may be assigned either by the merchant or merchant system that created the offer, or by the MoCom platform during the lifecycle of the offer, which is managed by the MoCom platform. That is, offers that are stored on the MoCom platform and ready to be deployed to mobile devices may be modified so as to assign and/or edit their respective information, including threshold reference number and status level. In one exemplary embodiment, an offer may have multiple threshold reference numbers and status levels, so that the offer may be assigned and transmitted to a mobile wallet application when the mobile wallet application reaches one of multiple thresholds.


In turn, the mobile device receives and stores the received offers (e.g., offer data) and makes those offers available for use in a contactless transaction.



FIG. 3 is a diagram of a mobile device 300 including an interface for providing membership level information, according to an exemplary embodiment. The mobile device 300 (e.g., FIG. 1, mobile device 120) may be a cellular phone, tablet and/or the like. Mobile devices are described above in detail with reference to FIG. 1. The mobile device 300 includes a processor and memory. A mobile wallet application may be installed on the memory of the mobile device 300, and can be used to manage the membership program and information related to the membership program. Membership programs are discussed above in more detail with reference to FIG. 2.


The mobile device 300 also includes an interface (e.g., user interface) 301, which may be used to display (e.g., output) and/or receive (e.g., input) information. In one example embodiment, the interface displays a card 302 (e.g., membership program card) corresponding to a membership program. The displayed card 302 may be in the shape of a credit, debit, loyalty card and/or the like. The displayed card 302 may include the name of the membership program (e.g., Tap Card), name of the user associated with the membership program and/or mobile wallet application (e.g., John Smith), and the membership level of the mobile wallet application in the membership program (e.g., Gold Member). The card 302 is displayed in accordance with membership program information received and stored by the mobile device.


The mobile device 300 receives membership program information from a system such as a MoCom platform (e.g., FIG. 1, MoCom platform 130). The membership program information includes an application identifier corresponding to the mobile wallet stored on the mobile device. The membership program information also includes the membership level to be associated with the mobile wallet application. As discussed in more detail above with reference to FIG. 2, the membership level corresponds to a status level and/or threshold level assigned by reaching predefined criteria (e.g., number of taps). In one example embodiment, the membership program information is transmitted by the MoCom platform to the mobile device when the mobile wallet application reaches a threshold.


The mobile device 300 receives the membership program information from the MoCom platform and compares it to previously stored membership program information associated with the mobile wallet application. If indeed there is a change and/or update, the mobile wallet application updates the membership program information and displays the card 302 accordingly. That is, if the membership level of the membership program information is updated from “Gold” to “Silver,” various elements of the card 302 may be displayed differently in accordance with the change. For example, the shape, image and/or text of the card 302 may be modified to show a silver-colored card that reads “Silver Member,” in the event that the mobile wallet application reaches that threshold.


In one example embodiment, performing an action on the card 302 (e.g., tapping the card 302 via the user interface 301) causes the card to flip and display membership program information, status level, date reached, counter value, difference between counter value and the next threshold to be reached, and/or similar information.


Example Computer-Readable Implementation


The example embodiments described above such as, for example, the systems and procedures depicted in or discussed in connection with FIGS. 1-3 or any part or function thereof, may be implemented by using hardware, software or a combination of the two. The implementation may be in one or more computers or other processing systems. While manipulations performed by these example embodiments may have been referred to in terms commonly associated with mental operations performed by a human operator, no human operator is needed to perform any of the operations described herein. In other words, the operations may be completely implemented with machine operations. Useful machines for performing the operation of the example embodiments presented herein include general purpose digital computers or similar devices.



FIG. 4 is a block diagram of a general and/or special purpose computer 400, in accordance with some of the example embodiments of the invention. The computer 400 may be, for example, a user device, a user computer, a client computer and/or a server computer, among other things.


The computer 400 may include without limitation a processor device 430, a main memory 435, and an interconnect bus 437. The processor device 430 may include without limitation a single microprocessor, or may include a plurality of microprocessors for configuring the computer 400 as a multi-processor system. The main memory 435 stores, among other things, instructions and/or data for execution by the processor device 430. The main memory 435 may include banks of dynamic random access memory (DRAM), as well as cache memory.


The computer 400 may further include a mass storage device 440, peripheral device(s) 442, portable storage medium device(s) 446, input control device(s) 444, a graphics subsystem 448, and/or an output display 449. For explanatory purposes, all components in the computer 400 are shown in FIG. 4 as being coupled via the bus 437. However, the computer 400 is not so limited. Devices of the computer 400 may be coupled via one or more data transport means. For example, the processor device 430 and/or the main memory 435 may be coupled via a local microprocessor bus. The mass storage device, 440, peripheral device(s) 442, portable storage medium device(s) 446, and/or graphics subsystem 448 may be coupled via one or more input/output (I/O) buses. The mass storage device 440 may be a nonvolatile storage device for storing data and/or instructions for use by the processor device 430. The mass storage device 440 may be implemented, for example, with a magnetic disk drive or an optical disk drive. In a software embodiment, the mass storage device 440 is configured for loading contents of the mass storage device 440 into the main memory 435.


The portable storage medium device 446 operates in conjunction with a nonvolatile portable storage medium, such as, for example, a compact disc read only memory (CD-ROM), to input and output data and code to and from the computer 400. In some embodiments, the software for storing an internal identifier in metadata may be stored on a portable storage medium, and may be inputted into the computer 400 via the portable storage medium device 446. The peripheral device(s) 442 may include any type of computer support device, such as, for example, an input/output (I/O) interface configured to add additional functionality to the computer 400. For example, the peripheral device(s) 442 may include a network interface card for interfacing the computer 400 with a network 439.


The input control device(s) 444 provide a portion of the user interface for a user of the computer 400. The input control device(s) 444 may include a keypad and/or a cursor control device. The keypad may be configured for inputting alphanumeric characters and/or other key information. The cursor control device may include, for example, a mouse, a trackball, a stylus, and/or cursor direction keys. In order to display textual and graphical information, the computer 400 may include the graphics subsystem 448 and the output display 449. The output display 449 may include a cathode ray tube (CRT) display and/or a liquid crystal display (LCD). The graphics subsystem 448 receives textual and graphical information, and processes the information for output to the output display 449.


Each component of the computer 400 may represent a broad category of a computer component of a general and/or special purpose computer. Components of the computer 400 are not limited to the specific implementations provided here.


Portions of the example embodiments of the invention may be conveniently implemented by using a conventional general purpose computer, a specialized digital computer and/or a microprocessor programmed according to the teachings of the present disclosure, as is apparent to those skilled in the computer art. Appropriate software coding may readily be prepared by skilled programmers based on the teachings of the present disclosure.


Some embodiments may also be implemented by the preparation of application-specific integrated circuits, field programmable gate arrays, or by interconnecting an appropriate network of conventional component circuits.


Some embodiments include a computer program product. The computer program product may be a storage medium or media having instructions stored thereon or therein which can be used to control, or cause, a computer to perform any of the procedures of the example embodiments of the invention. The storage medium may include without limitation a floppy disk, a mini disk, an optical disc, a Blu-ray Disc, a DVD, a CD-ROM, a micro-drive, a magneto-optical disk, a ROM, a RAM, an EPROM, an EEPROM, a DRAM, a VRAM, a flash memory, a flash card, a magnetic card, an optical card, nanosystems, a molecular memory integrated circuit, a RAID, remote data storage/archive/warehousing, and/or any other type of device suitable for storing instructions and/or data.


Stored on any one of the computer readable medium or media, some implementations include software for controlling both the hardware of the general and/or special computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the example embodiments of the invention. Such software may include without limitation device drivers, operating systems, and user applications. Ultimately, such computer readable media further include software for performing example aspects of the invention, as described above.


Included in the programming and/or software of the general and/or special purpose computer or microprocessor are software modules for implementing the procedures described above.


While various example embodiments of the invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It is apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein. Thus, the invention should not be limited by any of the above-described example embodiments, but should be defined only in accordance with the following claims and their equivalents.


In addition, it should be understood that the figures are presented for example purposes only. The architecture of the example embodiments presented herein is sufficiently flexible and configurable, such that it may be utilized and navigated in ways other than that shown in the accompanying figures. Further, the purpose of the Abstract is to enable the U.S. Patent and Trademark Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is not intended to be limiting as to the scope of the example embodiments presented herein in any way. It is also to be understood that the procedures recited in the claims need not be performed in the order presented.

Claims
  • 1. A system to manage information associated with updated status levels, comprising: a mobile computing device comprising a user interface, a mobile storage device, and a mobile processor communicatively coupled to the mobile storage device, the mobile computing device comprising a mobile wallet application; anda computing system comprising a storage device and a processor communicatively coupled to the storage device, wherein the processor executes application code instructions that are stored in the storage device to cause the computing system to: receive a tap transaction notification that describes a contactless transaction performed via the mobile wallet application;increment a counter based on the tap transaction notification, the counter describing a number of contactless transactions;determine that the incremented counter exceeds one of a plurality of contactless transaction thresholds;determine an updated status level associated with the incremented counter that exceeds the one of the plurality of contactless transaction thresholds;associate the new status level with the mobile wallet application; andwherein the mobile processor executes application code instructions that are stored in the mobile storage device to cause the wallet application to: update program information associated with a prior status level to new membership program information associated with the updated status level, wherein updating the program information comprises changing visual elements associated with the prior status level displayed by the mobile computing device.
  • 2. The system claim 1, wherein the processor is further configured to execute application code instructions stored in the storage device to cause the computing system to transmit at least a portion of the new program information associated with the updated status level to the mobile computing device.
  • 3. The system of claim 1, wherein the new program information associated with the updated status level comprises a new membership status level.
  • 4. The system of claim 1, wherein the processor is further configured to execute application code instructions stored in the storage device to cause the computing system to transmit the updated status level to the mobile computing device.
  • 5. The system of claim 1, wherein the processor is further configured to execute application code instructions stored in the storage device to cause the computing system to identify one or more offers that correspond to the updated status level.
  • 6. The system of claim 1, wherein the visual elements comprise one or more of a color and shape of a displayed membership card.
  • 7. The system of claim 1, wherein the tap transaction notification identifies data associated with the mobile wallet application that includes at least one a mobile wallet ID or data identifying a merchant associated with the contactless transaction.
  • 8. The system of claim 1, wherein the determining that the incremented counter exceeds the one of the plurality of contactless transaction thresholds comprises determining that the incremented counter exceeds a mobile wallet threshold defined with respect to the number of contactless transactions performed with the mobile wallet application.
  • 9. A method to manage information associated with updated status levels, comprising: receiving, by a computing device, a tap transaction notification that describes a contactless transaction performed via a mobile wallet application of the computing device;incrementing, by the computing device, a counter based on the tap transaction notification, the counter describing a number of contactless transactions;determining, by the computing device, that the incremented counter exceeds one of a plurality of contactless transaction thresholds;determining, by the computing device, an updated status level associated with the incremented counter exceeding the one of the plurality of contactless transaction thresholds; andupdating, by the computing device, program information associated with a prior status level to new program information associated with the updated status level, wherein updating the program information comprises changing visual elements associated with the prior status level.
  • 10. The method according to claim 9, further comprising transmitting, by the computing device, at least a portion of the new program information associated with the updated status level to a mobile computing device.
  • 11. The method according to claim 9, wherein the new program information associated with the updated status level comprises a new membership status level.
  • 12. The method according to claim 9, further comprising transmitting, by the computing device, the updated status level to a mobile computing device.
  • 13. The method according to claim 11, further comprising determining, by the mobile computing device, that the new membership status level is different than a prior membership status level.
  • 14. The method according to claim 9, wherein the tap transaction notification is received from one of a mobile computing device or a merchant computing device.
  • 15. The method according to claim 9, further comprising identifying, by the computing device, one or more offers that correspond to the updated status level.
  • 16. The method according to claim 9, wherein the visual elements comprise one or more of a color and shape of a displayed membership card.
  • 17. A computer program product, comprising: a non-transitory computer-readable medium having computer-readable program instructions embodied therein that when executed by a computer cause the computer to manage information associated with updated status levels, the computer-readable program instructions comprising: computer-readable program instructions to receive a tap transaction notification that describes a contactless transaction performed via a mobile wallet application of a mobile computing device;computer-readable program instructions to increment a counter based on the tap transaction notification, the counter describing a number of contactless transactions;computer-readable program instructions to determine that the incremented counter exceeds one of a plurality of contactless transaction thresholds;computer-readable program instructions to determine an updated status level associated with the incremented counter exceeding the one of the plurality of contactless transaction thresholds; andcomputer-readable program instructions to update program information associated with a prior status level to new program information associated with the updated status level, wherein updating the program information comprises changing visual elements associated with the prior status level displayed by a mobile computing device.
  • 18. The computer program product of claim 17, further comprising computer-readable program instructions to transmit the updated status level to a mobile computing device.
  • 19. The computer program product of claim 17, further comprising computer-readable program instructions to identify one or more offers that correspond to the updated status level.
  • 20. The computer program product of claim 17, wherein the visual elements comprise one or more of a color and shape of a displayed membership card.
CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims priority to U.S. Non-Provisional patent application Ser. No. 14/508,348, filed Oct. 7, 2014, and entitled “Systems, Methods, and Computer Program Products for Managing Contactless Transactions,” which claims priority to U.S. Provisional Application No. 61/889,244, filed on Oct. 10, 2013; the entire contents of the above-identified priority applications are hereby fully incorporated herein by reference.

US Referenced Citations (158)
Number Name Date Kind
5109409 Bomgardner Apr 1992 A
5590038 Pitroda Dec 1996 A
5640002 Ruppert et al. Jun 1997 A
5748740 Curry et al. May 1998 A
5805702 Curry et al. Sep 1998 A
5884271 Pitroda Mar 1999 A
5901303 Chew May 1999 A
5940510 Curry et al. Aug 1999 A
5949880 Curry et al. Sep 1999 A
6073840 Marion Jun 2000 A
6105013 Curry et al. Aug 2000 A
6116505 Withrow Sep 2000 A
6131811 Gangi Oct 2000 A
6237095 Curry et al. May 2001 B1
6422464 Terranova Jul 2002 B1
6587835 Treyz et al. Jul 2003 B1
6601759 Fife et al. Aug 2003 B2
6671358 Seidman et al. Dec 2003 B1
6732081 Nicholson May 2004 B2
6769607 Pitroda et al. Aug 2004 B1
6813609 Wilson Nov 2004 B2
6837436 Swartz et al. Jan 2005 B2
6925439 Pitroda Aug 2005 B1
7072851 Wilcox Jul 2006 B1
7083094 Cooper Aug 2006 B2
7110792 Rosenberg Sep 2006 B2
7127236 Khan et al. Oct 2006 B2
7155405 Petrovich Dec 2006 B2
7194422 St. John Killick Mar 2007 B1
7216109 Donner May 2007 B1
7249112 Berardi et al. Jul 2007 B2
7286818 Rosenberg Oct 2007 B2
7298271 Sprogis Nov 2007 B2
7308426 Pitroda Dec 2007 B1
7330714 Rosenberg Feb 2008 B2
7349885 Gangi Mar 2008 B2
7469151 Khan et al. Dec 2008 B2
7469381 Ording Dec 2008 B2
7483858 Foran et al. Jan 2009 B2
7494055 Fernandes et al. Feb 2009 B2
7529563 Pitroda May 2009 B1
7571139 Giordano et al. Aug 2009 B1
7581678 Narendra et al. Sep 2009 B2
7613628 Ariff et al. Nov 2009 B2
7631810 Liu et al. Dec 2009 B2
7693752 Jaramillo Apr 2010 B2
7708198 Gangi May 2010 B2
7712658 Gangi May 2010 B2
7775430 Lin Aug 2010 B2
7805615 Narendra et al. Sep 2010 B2
7828214 Narendra et al. Nov 2010 B2
7856377 Cohagan et al. Dec 2010 B2
7864163 Ording et al. Jan 2011 B2
7942337 Jain May 2011 B2
7954715 Narendra et al. Jun 2011 B2
7954716 Narendra et al. Jun 2011 B2
7954717 Narendra et al. Jun 2011 B2
7961101 Narendra et al. Jun 2011 B2
7967215 Kumar et al. Jun 2011 B2
7991158 Narendra et al. Aug 2011 B2
8072331 Narendra et al. Dec 2011 B2
8083145 Narendra et al. Dec 2011 B2
8091786 Narendra et al. Jan 2012 B2
8131645 Lin et al. Mar 2012 B2
8140418 Casey et al. Mar 2012 B1
8396808 Greenspan Mar 2013 B2
8429046 Pitroda Apr 2013 B2
RE45006 Deaton Jul 2014 E
9223297 Nielsen Dec 2015 B2
20020049631 Williams Apr 2002 A1
20020082921 Rankin Jun 2002 A1
20020174025 Hind et al. Nov 2002 A1
20020179703 Allen Dec 2002 A1
20030009382 D'Arbeloff et al. Jan 2003 A1
20030050831 Klayh Mar 2003 A1
20030083042 Abuhamdeh May 2003 A1
20030115126 Pitroda Jun 2003 A1
20030132298 Swartz et al. Jul 2003 A1
20030135793 Craig Jul 2003 A1
20030200489 Hars Oct 2003 A1
20040073519 Fast Apr 2004 A1
20040186768 Wakim et al. Sep 2004 A1
20040211600 Schuller Oct 2004 A1
20050004866 Bonalle et al. Jan 2005 A1
20050171898 Bishop et al. Aug 2005 A1
20050222961 Staib et al. Oct 2005 A1
20050234769 Jain et al. Oct 2005 A1
20050247777 Pitroda Nov 2005 A1
20060168546 Consolatti Jul 2006 A1
20060277100 Parham Dec 2006 A1
20060287004 Fuqua Dec 2006 A1
20070014407 Narendra et al. Jan 2007 A1
20070014408 Narendra et al. Jan 2007 A1
20070150568 Ruiz Jun 2007 A1
20070198432 Pitroda et al. Aug 2007 A1
20070219863 Park Sep 2007 A1
20080201231 Bistriceanu Aug 2008 A1
20080295105 Ozer Nov 2008 A1
20080306849 Johnson, Jr. et al. Dec 2008 A1
20080311894 Klein Dec 2008 A1
20090108064 Fernandes et al. Apr 2009 A1
20090164322 Khan et al. Jun 2009 A1
20100010964 Skowronek Jan 2010 A1
20100082420 Trifiletti Apr 2010 A1
20100239249 Sun Sep 2010 A1
20100241494 Kumar et al. Sep 2010 A1
20100250583 Klemm Sep 2010 A1
20100253556 Biran Oct 2010 A1
20110060637 Sakai et al. Mar 2011 A1
20110073663 Narendra et al. Mar 2011 A1
20110161148 Schmidt Jun 2011 A1
20110166992 Dessert Jul 2011 A1
20110171996 Narendra et al. Jul 2011 A1
20110208576 Durgin Aug 2011 A1
20110218868 Young Sep 2011 A1
20110223972 Narendra et al. Sep 2011 A1
20110231238 Khan et al. Sep 2011 A1
20110244796 Khan Oct 2011 A1
20110269438 Narendra et al. Nov 2011 A1
20110271044 Narendra et al. Nov 2011 A1
20110272468 Narendra et al. Nov 2011 A1
20110272469 Narendra et al. Nov 2011 A1
20120029990 Fisher Feb 2012 A1
20120064828 Khan et al. Mar 2012 A1
20120089471 Comparelli Apr 2012 A1
20120109764 Martin et al. May 2012 A1
20120116840 Omer May 2012 A1
20120130791 Carter May 2012 A1
20120150669 Langley Jun 2012 A1
20120184363 Barclay Jul 2012 A1
20120203610 Grigg Aug 2012 A1
20120215637 Hermann Aug 2012 A1
20120323664 Klems Dec 2012 A1
20120330737 Liberty Dec 2012 A1
20120330830 Mason Dec 2012 A1
20130035036 Fisher Feb 2013 A1
20130054412 Brendell Feb 2013 A1
20130085881 Chary Apr 2013 A1
20130124272 Hohti May 2013 A1
20130159073 Shah Jun 2013 A1
20130218658 Crowe Aug 2013 A1
20130238723 Balannik Sep 2013 A1
20130262214 Baird Oct 2013 A1
20130311900 Schleier-Smith Nov 2013 A1
20130317924 Bush et al. Nov 2013 A1
20130317927 Bush et al. Nov 2013 A1
20140012749 Lee Jan 2014 A1
20140032312 Johnson et al. Jan 2014 A1
20140040125 Kunz Feb 2014 A1
20140047331 Feldman Feb 2014 A1
20140074616 Johnson et al. Mar 2014 A1
20140180826 Boal Jun 2014 A1
20140200973 Webb Jul 2014 A1
20140310089 Cullen Oct 2014 A1
20150032522 Dintenfass Jan 2015 A1
20150106186 Hopkinson Apr 2015 A1
20180033001 Hopkinson Feb 2018 A1
20180130548 Fisher May 2018 A1
Foreign Referenced Citations (10)
Number Date Country
2381614 Mar 2001 CA
1 222 503 Jul 2002 EP
0 766 852 Aug 2004 EP
1 412 890 Nov 2004 EP
1 477 943 Nov 2004 EP
2010-218027 Sep 2010 JP
10-2011-0092470 Aug 2011 KR
2001018629 May 2001 WO
2003012717 Feb 2003 WO
2015054207 Apr 2015 WO
Non-Patent Literature Citations (10)
Entry
STIC NPL Search Report dated Nov. 4, 2019.
Taher, “Australian Office Action issued in Australian Application No. 2014332179”, dated Nov. 2, 2017, 3 Pages.
Adhikari, “Australian Office Action issued in Australian Application No. 2014332179”, dated Aug. 4, 2017, 4 pages.
Adhikari, “Australian Office Action issued in Australian Application No. 2014332179”, dated May 25, 2017, 4 pages.
Adhikari, “Australian Office Action issued in Australian Application No. 2014332179”, dated Dec. 16, 2016, 7 pages.
Park, “International Search Report and Written Opinion issued in International Application No. PCT/US2014/059436”, dated Jan. 14, 2015, 10 pages.
Sittner, “U.S. Office Action issued in copending U.S. Appl. No. 14/508,348, filed Oct. 7, 2014”, dated Feb. 23, 2017, 24 pages.
Wittmann-Regis, “International Preliminary Report on Patentability issued in International Application No. PCT/US2014/059436”, dated Apr. 21, 2016, 7 pages.
Ziaie, “Canada Office Action received for Canada Patent Application No. 2,926,717”, dated Jan. 31, 2017, 3 pages.
U.S. Appl. No. 14/508,348 to Emma K. Hopkinson filed Oct. 7, 2014.
Related Publications (1)
Number Date Country
20180033001 A1 Feb 2018 US
Provisional Applications (1)
Number Date Country
61889244 Oct 2013 US
Continuations (1)
Number Date Country
Parent 14508348 Oct 2014 US
Child 15727537 US