US20140081853A1 - Systems and methods for implementing mobile bill payment functionality in mobile commerce - Google Patents

Abstract

This disclosure describes systems, methods, and computer-readable media related to facilitating mobile bill payment functionality in mobile commerce. In some embodiments, a user device comprising one or more processors may receive a notification from a financial institution, wherein the notification comprises information associated with a bill. The user device may display the notification. The user device may receive, from a user, an indication for an action associated with a payment of the bill. In some embodiments, the user device may process the action associated with the payment of the bill.

Description

RELATED APPLICATIONS
• This application claims priority to U.S. Ser. No. 61/699,728, titled “Systems and Methods for Implementing Mobile Commerce,” filed on Sep. 11, 2012, and to U.S. Ser. No. 61/799,676, titled “Systems and Methods for Implementing Mobile Commerce,” filed on Mar. 15, 2013, the entire contents of both are hereby incorporated by reference.
FIELD OF THE DISCLOSURE
• The disclosure generally relates to mobile commerce, and more particularly, to systems and methods for implementing mobile bill payment functionality in mobile commerce.
BACKGROUND
• Commercial transactions to purchase certain goods and services are being implemented by consumers using mobile devices, such as smartphones. However, many commercial transactions are still cumbersome to implement since many conventional point-of-sale (POS) terminals and devices, payment processing systems, and smartphone interfaces are not configured for user-friendly transactions.
BRIEF DESCRIPTION OF THE DISCLOSURE
• The disclosure relates to systems and methods for implementing mobile bill payment functionality in mobile commerce.
• In one embodiment, a method may be provided. A user device comprising one or more processors may receive a notification from a financial institution, wherein the notification comprises information associated with a bill. The user device may display the notification. The user device may receive, from a user, an indication for an action associated with a payment of the bill. The user device may process the action associated with the payment of the bill.
• In one aspect of an embodiment, the action may be an authorization to facilitate the payment of the bill.
• In one aspect of an embodiment, the user device may display payment details associated with the payment of the bill. The user device may receive a confirmation from the user to facilitate payment of the bill. The user device may transmit to the financial institution the payment details associated with the payment of the bill.
• In one aspect of an embodiment, the payment details may include an amount, a payment date, and a payment method.
• In one aspect of an embodiment, the user device may receive from a user a date to pay the bill. The user device may schedule payment of the bill based at least in part on the date received from the user.
• In one aspect of an embodiment, the action may be a postponement of payment of the bill.
• In one aspect of an embodiment, the user device may schedule, based at least in part on a user-specified preference, a reminder to pay the bill.
• In one aspect of an embodiment, the action may be to view further details associated with the bill.
• In one aspect of an embodiment, the user device may retrieve the bill from the financial institution.
• In one aspect of an embodiment, the user device may transmit the bill to an email associated with the user.
• In another embodiment, a system may be provided. The system may include at least one memory storing computer-executable instructions and at least one processor, wherein the at least one processor may be configured to access the at least one memory and to execute the computer-executable instructions to receive a notification from a financial institution, wherein the notification comprises information associated with a bill; display the notification; receive, from a user, an indication for an action associated with a payment of the bill; and process the action associated with the payment of the bill.
• In one aspect of an embodiment, the action may be an authorization to facilitate the payment of the bill.
• In one aspect of an embodiment, the at least one processor may be further configured to execute the computer-executable instructions to display payment details associated with the payment of the bill; receive a confirmation from the user to facilitate payment of the bill; and transmit, to the financial institution, the payment details associated with the payment of the bill.
• In one aspect of an embodiment, the payment details may include an amount, a payment date, and a payment method.
• In one aspect of an embodiment, the at least one processor may be further configured to execute the computer-executable instructions to receive, from the user, a date to pay the bill and schedule payment of the bill based at least in part on the date received from the user.
• In one aspect of an embodiment, the action may be a postponement of payment of the bill.
• In one aspect of an embodiment, the at least one processor may be further configured to execute the computer-executable instructions to schedule, based at least in part on a user-specified preference, a reminder to pay the bill.
• In one aspect of an embodiment, the action may be to view further details associated with the bill.
• In one aspect of an embodiment, the at least one processor may be further configured to execute the computer-executable instructions to retrieve the bill from the financial institution.
• In one aspect of an embodiment, the at least one processor may be further configured to execute the computer-executable instructions to transmit the bill to an email associated with the user.
BRIEF DESCRIPTION OF THE DRAWINGS
• The detailed description is set forth with reference to the accompanying drawings. The use of the same reference numerals indicates similar or identical components or elements; however, different reference numerals may be used as well to indicate components or elements which may be similar or identical. Various embodiments of the disclosure may utilize elements and/or components other than those illustrated in the drawings, and some elements and/or components may not be present in various embodiments. Depending on the context, singular terminology used to describe an element or a component may encompass a plural number of such elements or components and vice versa.
• FIG. 1 is a block diagram including various hardware and software components a system for implementing mobile bill payment functionality in mobile commerce in accordance with one or more embodiments of the disclosure.
• FIG. 2 is a block diagram that illustrates an example mobile commerce program application or module in accordance with one or more embodiments of the disclosure.
• FIG. 3 is a process flow diagram of an illustrative method for implementing mobile bill payment functionality in mobile commerce in accordance with one or more embodiments of the disclosure.
• FIG. 4 is a diagram that depicts example user interfaces for implementing bill payment functionality in mobile commerce in accordance with one or more embodiments of the disclosure.
DETAILED DESCRIPTION
• Certain embodiments of the disclosure will now be described more fully hereinafter with accompanying drawings and corresponding description inFIGS. 1-4. This disclosure may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein.
Overview
• The disclosure relates to systems and methods for implementing mobile bill payment functionality in mobile commerce. In one implementation, a mobile commerce application program, also known as a mobile wallet or wallet app, can be downloaded or other otherwise implemented by a consumer and/or merchant via a mobile device or client device, such as a smartphone, cellphone, wearable computer, or tablet computer. The mobile commerce application program can integrate both payment and loyalty functionality for use by merchants and consumers to facilitate payment and/or loyalty/reward transactions for goods and/or services, administer loyalty/reward programs, and receive loyalty/reward credit for a variety of activities, including, for instance, visiting certain merchants during certain days and/or times as well as purchasing goods and/or services. For example, according to certain embodiments of the disclosure, a consumer can download a wallet app to his or her smartphone or other mobile device, input and store payment device information in the wallet app, and then use the wallet app to pay a merchant for a movie ticket by transmitting an indication from the smartphone or other mobile device to the merchant. Using the payment device information, loyalty/reward credit can be generated by the merchant and credited to the consumer via a loyalty/reward program account for visiting the movie theater during an off-peak date/time as well as purchasing the movie ticket. The wallet app can generate an output via the consumer's smartphone or mobile device to reflect the loyalty/reward credit to the consumer's associated loyalty/reward program account as well as an electronic receipt for the consumer's movie ticket purchase. In this manner, loyalty/reward programs can become easier to use for consumers since the mobile commerce application can electronically track credits and various activities by the consumer can earn the consumer additional loyalty/reward credits. Further, different types of consumer loyalty can be rewarded, such as based on visits, spending, performing any number of activities (e.g., sending a friend an email or text, joining a loyalty/reward program, trying something new or different, etc.), or for ad-hoc reasons (e.g., late merchant service).
• In another implementation, one or more tools can be provided by a mobile commerce application program to merchants and consumers to build closer ties between them or otherwise connect them through increased and more focused communications. For example, according to certain embodiments of the disclosure, a restaurant merchant can access, via a point of sale (POS) device or client device, a customized mobile commerce application or wallet app that has been downloaded to a consumer's mobile device or client device. When the restaurant merchant wants to communicate with its customers about news, upcoming events, and new menu items, such as announcing a special wine and cheese event for frequent customers. The restaurant merchant can access one or more tools to send notifications or messages to certain selected consumers via the wallet app on consumer's mobile devices or client devices. The tools can facilitate access to demographic and consumer data (spending, visits, etc.); filter data based on the demographic data, consumer data, and demographic and/or consumer groups; manage communication preferences (email, texts, notifications, etc.); and apply consumer preferences to selected communications Consumers could be selected based on, for instance, the number of restaurant visits in the past 30 days. In this manner, the merchant can target certain groups of consumers with focused messages and marketing campaigns, and thereby increase or otherwise improve merchant-consumer contact.
• In yet another implementation, a mobile commerce application program can provide customized merchant applications to different merchants. For example, a local restaurant merchant may want to customize a wallet app or mobile commerce application program for downloading to or otherwise accessing via a consumer's mobile device or client device. The merchant can access another mobile commerce application program and utilize one or more tools to, for example, upload a merchant business logo, select parameters for a loyalty/reward program, and select data fields for obtaining consumer information or asking consumer questions. In any instance, after the merchant has customized a wallet app, consumers can access or otherwise download the app to their respective mobile devices or client devices, and initiate communications with the merchant via the customized wallet app. In certain other embodiments, a multi-merchant app can be provided to consumers for download to or access by a mobile device or client device. In that instance, consumers can have the ability to select from a list of merchants that communicate via the multi-merchant app. In certain other embodiments, a mobile commerce application program can provide services to any number of merchants who may have their own respective apps, and the mobile commerce application program can provide a variety of payment, communication, advertising, and loyalty/reward services through, for example, one or more application plug-ins that can interface between the merchant apps and the mobile commerce application program. In this manner, a merchant can customize consumers' payment and/or loyalty/rewards experiences through a wallet app or mobile commerce application program.
• In the above implementations and other embodiments described herein, a mobile commerce application program, sometimes referred to as a wallet app, can be hosted or otherwise stored on a mobile device, client device, server device, or any other processor-based device. Multiple instances of mobile commerce application programs can operate within a network environment, such as described inFIG. 1, and each may have similar or different functionality, such as described inFIG. 2, according to various embodiments and implementations as described herein.
Certain Example Implementations and Embodiments
• An example architecture or environment for asystem100 according various embodiments of the disclosure is shown in and described with respect toFIG. 1. A mobile commerce application program or module, such as102, can be stored inmemory104 at aserver device106. In certain embodiments, a mobile commerce application program or module, such as108, can be stored inmemory110 at amerchant system computer112 or associatedmerchant device114. In certain embodiments, a mobile commerce application program or module, such as116(1), can be stored in memory118(1) at a mobile device120(1) associated with a consumer122(1) or user. In any instance, one or more mobile commerce application programs or modules operating on respective computers, servers and/or mobile devices can implement some or all of the functionality described herein.
• As shown inFIG. 1, thesystem100 may include or otherwise support one or moremerchant system computers112 and/or associatedmerchant devices114, one or more consumer or mobile devices120(1)-120(N), one or more servertransaction processing systems106, and one or more issuer orfinancial institution systems124. A wide variety of different types of consumer or mobile devices120(1)-120(N) may be provided or otherwise supported, such as consumer computers and/or mobile communication devices. As desired, thesystem100 may provide or otherwise support a wide variety of other entities associated with payment transactions, such as one or more servertransaction processing systems106. Any number of suitable networks and/or communication channels, such as the illustratednetworks126, may facilitate communication between various components of thesystem100.
• With reference toFIG. 1, any number ofmerchant system computers112 and/or associatedmerchant devices114 may be provided or otherwise supported. In certain embodiments, thesemerchant system computers112 and/or associatedmerchant devices114 may include one or more point-of-sale (POS) devices or terminals. As desired, eachmerchant system computer112 and/or associatedmerchant device114 may include any number of processor-driven devices, including but not limited to, a server computer, a mainframe computer, one or more networked computers, a desktop computer, a personal computer, a laptop computer, a mobile computer, a smartphone, a tablet computer, a wearable computer device, an application-specific circuit, or any other processor-based device.
• Amerchant system computer112 and/or associatedmerchant device114 may be any suitable device that facilitates purchase transactions, such as those in retail establishments, e-commerce and/or mobile transactions. In operation, themerchant system computer112 and/or associatedmerchant device114 may utilize one ormore processors128 to execute computer-readable instructions that facilitate the hosting of one or more mobile commerce application program services, the receipt of purchase transaction requests, and/or the processing of payment and/or loyalty/reward transactions. As a result of executing these computer-readable instructions, a special purpose computer or particular machine may be formed that facilitates the purchase and/or loyalty/reward transactions.
• In addition to having one ormore processors128, themerchant system computer112 and/or associatedmerchant device114 may further include and/or be associated with one ormore memory devices110, input/output (“I/O”) interface(s)130, network interface(s), and/orlocation services132. Thememory110 may be any computer-readable medium, coupled to the processor(s)128, such as random access memory (“RAM”), read-only memory (“ROM”), and/or removable storage devices. Thememory110 may store a wide variety of data files and/or various program modules, such as an operating system (“OS”), one or more host modules, and/or one or more transaction modules or transaction applications, such as mobilecommerce application program108. The data files may include any suitable data that facilitates the operation of themerchant system computer112 and/or associatedmerchant device114, and/or interaction of themerchant system computer112 and/or associated merchant device115 with one or more other components (e.g., one or more one or more consumer or mobile devices120(1)-120(N), one or more servertransaction processing systems106, one or more merchant acquiring platforms, one or more issuer systems, one or morefinancial institution systems124, etc.) of thesystem100. For example, the data files may include information associated with one or more websites134 (hosted by either a third party and/or merchant), webpages, inventory information associated with available products, acquiring platform information, service provider information, information associated with the generation of payment and/or loyalty/reward transactions and/or routing information for payment and/or loyalty/reward transactions.
• The OS may be suitable module that facilitates the general operation of the merchant system computer, as well as the execution of other program modules. For example, the OS may be, but is not limited to, Microsoft Windows®, Apple OSX™, Unix, a mainframe computer operating system (e.g., IBM z/OS, MVS, OS/390, etc.), or a specially designed operating system. The host modules may include any number of suitable host modules that manage interactions and communications between themerchant system computer112 and/or associatedmerchant device114, and external devices, such as the consumer or mobile devices120(1)-120(N). For example, the host modules may include one or more Web server modules that facilitate the hosting of merchant websites and/or third party websites, such as134, webpages, and/or transaction processing webpages. As another example, the host modules may include one or more cellular modules and/or systems that facilitate cellular communication with one or more mobile devices120(1)-120(N).
• The transaction modules or applications, such as the mobilecommerce application program108, may include any number of suitable software modules and/or applications that facilitate the collection and/or processing of information association with a purchase transaction, such as one or more identifiers of desired products (e.g., UPC identifiers) and/or services, a desired payment account, a desired type of transaction (e.g., a card present transaction, a card not present transaction, etc.), consumer identification information, and/or an identifier of a consumer or mobile device120(1)-120(N) (e.g., a mobile device identifier, etc.). Based at least in part upon the collected information, the transaction modules or applications may generate and/or communicate a wide variety of transaction-related requests, such as payment processing and/or authorization requests and/or requests for one or more value added services (“VAS”).
• In one example embodiment, a transaction module, such as the mobilecommerce application program108, may receive a request for a purchase and/or loyalty/reward transaction (e.g., a request provided via a web page, etc.). As desired, the transaction module may identify available payment options that are presented to a consumer (e.g., credit account payment options, debit account payment options, stored value account payment options, card present e-commerce payment options, etc.), and a consumer selection of a payment option may be received. In the event that a card present transaction is requested, the transaction module may obtain a mobile device identifier, for example, via an established communications session with a consumer's mobile device or in response to requesting the mobile device identifier from the consumer. The transaction module may then invoke or request that a servertransaction processing system106 invoke one or more suitable applications on the mobile device, such as120(1), (e.g., a wallet application, a mobile commerce application program, a transaction module, etc.) in order to receive validation information from the mobile device120(1), such as an mPIN and/or a message (e.g., an encrypted message, etc.) derived from an mPIN and/or other information (e.g., a secure element identifier, an encryption key, etc.). The transaction module (or server transaction processing system) may then associate the validation information with a proposed transaction that is output for communication to an issuer system orfinancial institution system124 associated with a selected payment account. For example, the transaction module may append and/or incorporate the validation information into a transaction authorization and/or settlement request. In this regard, the issuer system orfinancial institution system124 may verify the validation information and determine whether a card present e-commerce transaction will be allowed.
• As desired, prior to the output of a proposed transaction, the transaction module may invoke and/or request (e.g., request a server transaction processing system, etc.) the invocation of a wide variety of VAS associated with a transaction, such as the application of coupons, the award and/or redemption of loyalty rewards, etc. Additionally, in the event that the transaction is authorized, the transaction module may invoke and/or request the invocation of a wide variety of VAS following the transaction, such as receipt delivery services, product registration services, etc. Indeed, a wide variety of suitable operations may be performed by the transaction module.
• Similarly, in some embodiments, a payment device, such as135(1)-135(N), for example a payment card, credit card, debit card, stored value card, smart card, etc., may be associated with a respective consumer, such as122(1)-122(N). The payment device, such as135(1), can be used to request a purchase and/or loyalty/reward transaction when presented to amerchant system computer112 and/ormerchant computer device114, either directly by the consumer135(1) or via a consumer's mobile device, such as120(1)-120(N). In these instances, an associated transaction module, such as the mobilecommerce application program108 associated with themerchant computer system112 and/ormerchant computer device114, can receive payment device information, such as an account number and/or other payment device information, and communicate, via one ormore networks126, some or all of the payment device information to an issuer system orfinancial institution system124 with the proposed transaction information for processing.
• Example application programs or modules associated with the operations that may be performed by a transaction module or mobilecommerce application program108 and/or themerchant system computer112 and/or associatedmerchant device114 are described in greater detail below with reference toFIG. 2.
• With continued reference to themerchant system computer112 and/or associatedmerchant device114, the one or more I/O interfaces130 may facilitate communication between themerchant system computer112 and/or associatedmerchant device114 and one or more input/output devices; for example, one or more user interface devices, such as a display, a keypad, a mouse, a pointing device, a gesture detection device, an eye movement detection device, a control panel, a touch screen display, a remote control, a microphone, a speaker, a consumer device reader, etc., that facilitate user interaction with themerchant system computer112 and/or associatedmerchant device114. The one or more network interfaces may facilitate connection of themerchant system computer112 and/or associatedmerchant device114 to one or more suitable networks, such as126, and/or communication links. In this regard, themerchant system computer112 and/or associatedmerchant device114 may receive and/or communicate information to other components of thesystem100, such as the consumer or mobile devices, for example120(1)-120(N), the servertransaction processing systems106, and/or the issuer orfinancial institution systems124.
• In certain embodiments, amerchant computer system112 and/or associatedmerchant computer device114 can be associated with amerchant location136, such as a retail store or “bricks and mortar”-type establishment. Themerchant location136 may include acode138, such as a QR code, bar code, or other machine readable code, wherein consumers can utilize a respective consumer or mobile device to scan or read the code to obtain information associated with a merchant, such as a merchant loyalty/rewards program.
• In certain embodiments, abill139 can be generated by amerchant computer system112 and/ormerchant system device114 and transmitted to a consumer's mobile device, such as120(1). The bill can include bill information, such as a merchant name, merchant account number or code, list of goods sold, list of services rendered, an itemized amount for a good and/or service, service charge or tip, a suggested service charge or tip, and a total amount.
• Additionally, with continued reference toFIG. 1, any number of consumer or mobile devices120(1)-120(N) may be provided or otherwise supported. Examples of suitable consumer or mobile devices can include, but are not limited to, personal computers and/or mobile communication devices (e.g., mobile phones, smart phones, wearable devices, etc.), etc. According to an aspect of the disclosure, a consumer or mobile device, such as120(1) may be a suitable device that is capable of interaction with other components of thesystem100 during the request and/or completion of an e-commerce transaction. For example, a personal computer or mobile device may be utilized to access one or more e-commerce websites, such as134, including those hosted by the merchant system computer, such as112, identify products and/or services to be purchased, request a purchase and/or loyalty/reward transaction, and/or interact with themerchant system computer112,merchant system device114, and/or other components of the system100 (e.g., the servertransaction processing system106, etc.) during the completion of a payment and/or loyalty/reward transaction. In one example embodiment, a mobile device, such as120(1), may be utilized to request a payment and/or loyalty/reward transaction and/or to provide validation information during the processing of the payment and/or loyalty/reward transaction. In another example embodiment, a personal computer may be utilized to request a payment and/or loyalty/reward transaction, and communication may be established with a mobile device, such as120(1), in order to facilitate provision of validation information.
• As desired, a consumer or mobile device, such as120(1), may be any number of processor-driven devices, including but not limited to, a personal computer, a mobile computer, an application-specific circuit, a minicomputer, a microcontroller, and/or any other processor-based device. The components of an example mobile device, such as120(1), will now be described in greater detail, and it will be appreciated that a personal computer may include similar components. With reference to the mobile device120(1), the mobile device120(1) may utilize one or more processors140(1) to execute computer-readable instructions that facilitate the general operation of the mobile device120(1) (e.g., call functionality, etc.) and/or communication with amerchant system computer112,merchant system device114, and/or other components of the system100 (e.g., the server transaction processing system106) for payment and/or loyalty/reward transaction purposes. As a result of executing these computer-readable instructions, a special purpose computer or particular machine may be formed that facilitates the completion of payment and/or loyalty/reward transactions.
• In addition to having one or more processors, the mobile device, such as120(1)-120(N), may further include and/or be associated with one or more memory devices118(1)-118(N), input/output (“I/O”) interface(s)142(1)-142(N), network interface(s), and/or location services144(1)-144(N). The memory118(1)-118(N) may be any computer-readable medium, coupled to the processor(s)140(1)-140(N), such as random access memory (“RAM”), read-only memory (“ROM”), and/or removable storage devices. The memory118(1)-118(N) may store a wide variety of data files and/or various program modules, such as an operating system (“OS”) and/or one or more transaction modules or applications, such as a mobile commerce application program116(1)-116(N). In certain embodiments, a mobile device, such as120(1), may include one or more secure elements configured to securely store and/or access information, such as payment applications, payment account information, validation information (e.g., a stored mPIN, etc.), encryption information, and/or other transaction-related information. The secure elements may be stored in the memory118(1) and/or included as a separate component of the mobile device120(1). For example, a secure element may be a separate chip that is configured to communicate with primary computing functionality for the mobile device. As desired, one or more of the transaction modules, such as the mobile commerce application program116(1), may be stored on a secure element. The transaction modules may be invoked by other components of the mobile device120(1) and/or by one or more other components of thesystem100, such as themerchant system computer112,merchant system device114, and/or the servertransaction processing system106.
• The data files may include any suitable data that facilitates the operation of the mobile device, such as120(1), and/or interaction of the mobile device120(1) with one or more other components (e.g., amerchant system computer112,merchant system device114, a servertransaction processing system106, etc.) of thesystem100. For example, the data files may include information associated with accessing the secure elements, information associated with invoking transaction modules, and/or information associated with accessing and/or processing validation data (e.g., an mPIN, etc.). The OS may be a suitable module that facilitates the general operation of the mobile device, such as120(1), as well as the execution of other program modules. For example, the OS may be, but is not limited to, a suitable mobile OS or a specially designed operating system. As desired, the mobile device120(1) may also include one or more suitable browser applications that facilitate the access of one or more webpages hosted by themerchant system computer112, and/or third party or merchant websites, such as134.
• The transaction modules may include one or more suitable software modules and/or applications configured to facilitate purchase transactions, such as payment and/or loyalty/reward transactions, on behalf of the mobile device, such as120(1). In certain embodiments, a transaction module or mobile commerce application program, such as116(1), may also facilitate communication with a server transaction processing system, such as106, or a trusted service manager. A wide variety of suitable techniques may be utilized to install a transaction module on the mobile device, such as120(1). For example, a transaction module may be provisioned to the mobile device120(1) by a servertransaction processing system106 and/or by an issuer orfinancial institution system124. Additionally, during the installation and/or registration of the transaction module, a wide variety of validation information may be generated and/or identified. For example, a consumer, such as122(1) may be prompted to enter an mPIN, such as a multi-character and/or multi-numeral code, to an associated mobile device, such as120(1). As desired, the mPIN may be stored on a secure element. Additionally, the PIN and/or a wide variety of information derived from the mPIN (e.g., an encrypted mPIN, etc.) may be provided to one or more issuer or financial institution systems, such as124, or an issuer system associated with an issuer of a payment account (e.g., a credit account, a debit account, a stored value account, etc.) that is associated with the transaction module.
• According to an aspect of the disclosure, following registration and/or activation of the transaction module, the transaction module may be invoked during a payment and/or loyalty/reward transaction. For example, the transaction module may be invoked by amerchant system computer112,merchant system device114, or by a servertransaction processing system106 at the request of themerchant system computer112 and/ormerchant system device114. In certain embodiments, the transaction module may be invoked following a consumer request to conduct a payment and/or loyalty/reward transaction and the identification of the mobile device, such as120(1), by themerchant system computer112,merchant system device114, or servertransaction processing system106. Following the invocation of the transaction module, a request for validation data and/or payment and/or loyalty/reward account data may be received. As desired, the transaction module may prompt the consumer for entry of an mPIN, and an mPIN value entered by the consumer, such as122(1), (e.g., by a keypad, touchscreen, etc.) may be identified. A stored mPIN value may then be accessed from the secure element and compared to the entered mPIN value. In this regard, the entered mPIN value may be authenticated. If the entered mPIN value is not authenticated, then the transaction module may reject a proposed transaction and direct the output of a suitable error message.
• If, however, the entered mPIN value is authenticated, then the transaction module may provide payment account data and associated validation data to themerchant system computer112,merchant system device114, or servertransaction processing system106. A wide variety of different types of validation data may be provided as desired in various embodiments, including but not limited to, an mPIN entered by the consumer122(1), an indication that the entered mPIN was authenticated by the mobile device120(1) and/or the secure element, an encrypted version of the entered mPIN, and/or an encrypted version of the stored mPIN. In one example embodiment, an entered mPIN may be authenticated, encrypted, and provided to the merchant system computer (or a server transaction processing system). In this regard, the encrypted mPIN may be provided to the issuer or financial institution system, such as124, for authentication and/or risk analysis purposes.
• Examples of the operations of the transaction module and/or the mobile device are described in greater detail below with reference to the other figures.
• The one or more I/O interfaces, such as142(1)-142(N), may facilitate communication between the mobile device, such as120(1) and one or more input/output devices; for example, one or more user interface devices, such as a display, a keypad, a touch screen display, a microphone, a speaker, etc., that facilitate user interaction with the mobile device120(1). Further, the one or more network interfaces may facilitate connection of the mobile device, such as120(1), to one or more suitable networks, for example, the network(s)126 illustrated inFIG. 1. In this regard, the mobile device, such as120(1), may receive and/or communicate information to other components of thesystem100.
• With continued reference toFIG. 1, as desired in various embodiments, any number of server transaction processing systems, such as106, may be provided or otherwise supported. A servertransaction processing system106 may facilitate the backend processing of a purchase transaction, such as a payment and/or loyalty/reward transaction. In certain embodiments, an issuer system may include similar components as those discussed above for themerchant system computer112 and/ormerchant system device114. For example, servertransaction processing system106 may include any number ofprocessors146, memories, I/O interfaces148, and/or network interfaces. In certain embodiments, a servertransaction processing system106 can include one or more transaction modules, such as a mobilecommerce application program102 and/or a social networkintegration program application150. In any instance, the transaction modules can facilitate communications and/or interactions with any number of consumer or mobile devices such as120(1)-120(N), merchant computer systems such as112,merchant computer devices114,data stores151, third party websites such as134, and financial institution systems such as124. In certain embodiments, a service transaction processing system, such as106, can host a social network integration program application, such as150, configured to communicate via any number of social network services and/or websites to obtain information from the services and/or websites, for example, product and/orservice data152 on a third party or merchant website, such as134.
• Furthermore, as desired, a server transaction processing system, such as106, may provide a wide variety of transaction module provisioning services. Additionally, a server transaction processing system, such as106, may provide a wide variety of transaction-related and/or value added services (“VAS”) in association with transactions, such as coupon redemption services, loyalty/reward services, location-based services, electronic receipt services, product registration services, warranty services, coupon issuance services, and/or the routing of a proposed transaction to an issuer for approval and/or settlement purposes. In certain embodiments, a server transaction processing system, such as106, may include similar components as those discussed above for the merchant system computer, such as112, and/or merchant system device, such as114. For example, a server transaction processing system, such as106, may include any number of processors, memories, I/O interfaces, and/or network interfaces.
• With continued reference toFIG. 1, as desired in various embodiments, any number of issuer or financial institution systems, such as124, may be provided or otherwise supported. An issuer or financial institution system, such as124, may facilitate the backend processing of a payment and/or loyalty/reward transaction, such as a payment for an e-commerce transaction. For example, an issuer or financial institution system, such as124, may host a payment processing application program, such as154, or module to facilitate the approval, authentication, and/or settlement of a payment transaction. In certain embodiments, a payment transaction may be routed to an issuer or financial institution system, such as124, via a suitable transaction network (e.g., a debit network, a credit network, etc.), and the issuer or financial institution system, such as124, may evaluate the payment transaction via the payment processing application program, such as154, or module. An approval or rejection of the payment transaction may then be output for communication to a merchant system computer, such as112, and/ormerchant system device114. The issuer or financial institution system, such as124, may then facilitate the settlement of the payment transaction. In certain embodiments, an issuer or financial institution system, such as124, may include similar components as those discussed above for themerchant system computer112 and/ormerchant system device114. For example, an issuer or financial institution system, such as124, may include any number ofprocessors156,memories158, I/O interfaces160, and/or network interfaces.
• In certain embodiments of the disclosure, an issuer or financial institution system, such as124, may receive validation information in association with a purchase and/or loyalty/reward transaction.
• A wide variety of suitable networks, individually and/or collectively shown as126 inFIG. 1, may be utilized in association with embodiments of the disclosure. Certain networks may facilitate use of a wide variety of e-commerce-related communication. For example, one or more telecommunication networks, cellular networks, wide area networks (e.g., the Internet), and/or other networks may be provided or otherwise supported. Other networks may facilitate communication of transaction-related communications. For example, one or more transaction networks, such as branded networks (e.g., a VISA network, etc.), debit and/or PIN networks, and/or a wide variety of other suitable transaction networks may facilitate communication of transaction-related communications, such as e-commerce transactions. Due to network connectivity, various methodologies as described herein may be practiced in the context of distributed computing environments. It will also be appreciated that the various networks may include a plurality of networks, each with devices such as gateways and routers for providing connectivity between or among networks. Additionally, instead of, or in addition to, a network, dedicated communication links may be used to connect various devices in accordance with an example embodiment.
• Thesystem100 shown in and described with respect toFIG. 1 is provided by way of example only. Numerous other operating environments, system architectures, and device configurations are possible. Other system embodiments can include fewer or greater numbers of components and may incorporate some or all of the functionality described with respect to the system components shown inFIG. 1. Accordingly, embodiments of the disclosure should not be construed as being limited to any particular operating environment, system architecture, or device configuration.
• FIG. 2 shows an example mobilecommerce application program200, similar to the mobilecommerce application programs102,108, and116(1)-116(N) inFIG. 1 that can operate with respect to thesystem100 shown inFIG. 1. The mobilecommerce application program200 shown inFIG. 2 can include, for example, a loyalty/rewardsmodule202, a check-in-to-pay module204, aninterruptive alert module206, a share redeemedoffer module208, a notification ormessaging module210, a restaurantmobile payment module212, a check-in-to-pay atQSR module214, a split thebill module216, alifecycle shopping module218, a linkingtransaction module220, a mobiledevice login module222, abill payment module224, a multi-consumerremote payment module226, aninstant issuance module228, a check-in to pumpgas module230, a buycar wash module232, a drive consumer insidemodule234, a tokenization module236, and acode generation module238. Some or all of the modules202-238 are described herein with respect to certain mobile commerce functionality, associated processes, and features.FIG. 3 illustrates certain processes associated with some or all of the modules comprising the example mobilecommerce application program200 inFIG. 2.
• While the various modules202-238 are shown by way of example, fewer or greater numbers of modules can be present in various embodiments of a mobile commerce application program. Furthermore, various functionality described with respect to one module may be performed by multiple modules in other embodiments of the disclosure.
Approve/Postpone Bill Payments
• In some instances, consumers may desire to make bill payments using a mobile device120(1). Certain embodiments of the disclosure can provide systems and processes for facilitating bill payments, such as setting up bill payments for utilities, etc. where a consumer's mobile device120(1) acts as a first decision point for each bill payment. For example, a notification can arrive on a consumer's mobile phone120(1) with notification of a new bill and amount of the bill. If the consumer reviews the bill and the amount is correct, the consumer can input a command to “approve and pay” using the mobile device120(1) without doing anything further, which can trigger the bill to be paid. However, if the amount is not correct, the consumer can “defer” or “postpone” paying the bill, and pay the bill later via a website, after the consumer has had a chance to review the bill. In this manner, the “approve”/“defer” decisioning by the consumer for bill payment can provide a relatively easy and quick methodology for consumer bill payments.
• In one embodiment, by way of a mobile device120(1) or other client device, such as a laptop computer or tablet, a consumer can initiate a bill payment feature in a payment application program or app accessible via the consumer's mobile device120(1) or other client device. For example, in a payment application or app accessible via the consumer's mobile device or other client device, a set of computer-executable instructions can be configured to receive an indication from the consumer for bill payment decisions to be routed to the consumer via a user interface associated with the consumer's mobile device120(1) or other client device. In certain embodiments, the set of computer-executable instructions can be configured to receive bills on behalf of the consumer, and to transmit a message or generate a user interface requesting consumer authorization for payment of the bill and bill amount. In certain embodiments, the set of computer-executable instructions can be configured to, after receiving consumer approval, to provide payment instructions to a billing entity associated with the bill. In any instance, the set of computer-executable instructions can be configured to provide the consumer with bill information including the bill amount, and the option to pay the bill or decline to pay the bill with single click or command.
• Using some or all of the above systems and processes, functionality for providing facilitating bill payments can be enabled. In this manner, consumers can better manage bill payments and can provide relatively quick payment instructions, which can enhance the consumer bill payment and mobile commerce experience.
• The systems and methods described herein may be directed to mobile bill management. In some embodiments, mobile bill management may enable users to use their mobile devices120(1) to receive a notification when bills become available, view details associated with the bill, and approve or postpone payment of the bill. The system for mobile bill management may include a mobile device120(1) in communication with one or morefinancial institution servers124. In some embodiments, the system may include one or more intermediary servers where the mobile device120(1) communicates with the intermediary servers and the intermediary servers may communicates with the financial institution servers.
• FIG. 3 is a flow diagram of amethod300 for mobile bill management in accordance with an embodiment of the disclosure. Various operations of the methods described below can be performed by the system components described above and shown inFIGS. 1 and 2. In brief overview, atblock302, abill payment module224 of a mobile device120(1) may receive a notification. Atblock304, thebill payment module224 of the mobile device120(1) may display the notification to the user. Atblock306, thebill payment module224 of the mobile device120(1) may receive an indication from a user. Atblock308, a determination may be made by thebill payment module224 of the mobile device120(1) as to whether the indication from the user was to approve the bill payment, postpone the bill payment, or to show more details of the bill. Atblock310, in response to determining a user approved the bill payment, thebill payment module224 of the mobile device120(1) may transmit a message authorizing bill payment. Atblock312, in response to determining the user selected to postpone bill payment, thebill payment module224 of the mobile device120(1) may transmit a message to schedule a reminder. Atblock314, in response to determining that the user selected to view more details of the bill, thebill payment module224 of the mobile device120(1) may retrieve additional bill details. Atblock316, the user may select to approve or postpone bill payment. If the user chooses to authorize bill payment, then the method may proceed to block310. If the user chooses to postpone bill, payment, then the method may proceed to block312.
• Atblock302, thebill payment module224 of the mobile device120(1) may receive a notification. In some embodiments, the notification may contain a message indicating that a bill is ready, the amount of the bill, and a due date of the bill. In some embodiments, the message may be received from a financial institution. In some embodiments, the message may be received from an intermediary in communication with the financial institution.
• Atblock304, thebill payment module224 of the mobile device120(1) may display the notification to the user. In some embodiments, the notification may display the information associated with the bill, such as the amount due, due date, and financial institution that generated the bill. In some embodiments, the notification may display one or more buttons for selection, which may enable the user to indicate an action in association with the bill. For example, the notification may include one or more of an “Authorize Payment” button, a “Review Details” button, or “Postpone” button.
• Atblock306, thebill payment module224 of the mobile device120(1) may receive an indication from a user. In some embodiments, thebill payment module224 of the mobile device120(1) may receive an indication from the user via a selection of a presented button.
• Atblock308, thebill payment module224 of the mobile device120(1) may determine whether the indication from the user was to approve the bill payment, postpone the bill payment, or to show more details of the bill.
• Atblock310, in response to determining a user approved the bill payment, thebill payment module224 of the mobile device120(1) may transmit a message authorizing bill payment. If the user selects to approve payment of the bill, the process may facilitate the payment of the bill. Thebill payment module224 of the mobile device120(1) may display an interface that permits the user to view further details of the bill, confirm or change payment methods for the bill, select and confirm an amount to pay, and/or a date to pay the bill. In some embodiments, thebill payment module224 of the mobile device120(1) may generate a confirmation notification to the user indicating that a payment will be made on a particular date, for the specified amount, from a specified account. The confirmation notification may require the user to confirm the authorization before facilitating payment by transmitting a message to the financial institution to pay the bill. In some embodiments, thebill payment module224 of the mobile device120(1) enables the user to specify a later date on which the bill may be paid. The user may be requested to specify a specific date on which the payment should be made.
• Atblock312, in response to determining the user selected to postpone bill payment, thebill payment module224 of the mobile device120(1) may transmit a message to schedule a reminder. In some embodiments, in response to the user selecting to postpone payment of a bill, a message to the user may be generated by thebill payment module224 of the mobile device120(1) requesting a date for the reminder. In some embodiments, in response to the user selecting to postpone payment of the bill, thebill payment module224 of the mobile device120(1) may mark the bill for a reminder for a later date. The later date may be specified in a user preference (e.g., remind after 1 day) or may be pre-determined at time of manufacture. In some embodiments, if the user selects to postpone payment, thebill payment module224 of the mobile device120(1) may schedule a reminder for the bill in accordance to one or more user-specified preferences. For example, if a user selects to postpone payment of a bill, thebill payment module224 of the mobile device120(1) may determine, based at least in part on the user-specified preferences, to remind the user in 2 days. In some embodiments, the user-specified preferences may include mode of reminder (e.g., push notification, email, etc.), time of reminder, number of days after initial postponement for reminder, and the like.
• Atblock314, in response to determining that the user selected to view more details of the bill, thebill payment module224 of the mobile device120(1) may retrieve additional bill details. In some embodiments, if the user selects to view more details, thebill payment module224 of the mobile device120(1) associated with mobile bill management may retrieve more details from the financial institute or third party intermediary and generate another message to transmit to the mobile device120(1). The message may display more details of the bill. In some embodiments, if the user selects to view more details, thebill payment module224 of the mobile device120(1) may retrieve the statement or bill and display the information to the user. In some embodiments, the retrieved statement or bill may be transmitted to the user's email address. In some embodiments, thebill payment module224 of the mobile device120(1) may generate a message containing a hyperlink which, when selected, may open a web browser to display the bill or statement.
• Atblock316, the user may select to approve or postpone bill payment. If the user chooses to authorize bill payment, then the method may proceed to block310. If the user chooses to postpone bill, payment, then the method may proceed to block312.
• In some embodiments, thebill payment module224 of the mobile device120(1) associated with the mobile bill management system may be trigger a communication with the financial institute (e.g., a bank) associated with an account used to pay the bill. Thebill payment module224 of the mobile device120(1) may obtain a current balance of the account. Thebill payment module224 of the mobile device120(1) may determine, based at least in part user-specified preferences and/or thresholds, whether there are sufficient funds to pay the bill. If thebill payment module224 of the mobile device120(1) determines that there is sufficient funds to pay the bill, then thebill payment module224 of the mobile device120(1) will facilitate the bill payment. If thebill payment module224 of the mobile device120(1) determines there are not sufficient funds, based at least in part on the user-specified preferences and/or thresholds, then thebill payment module224 of the mobile device120(1) may generate a notification to the user indicating that there are insufficient funds, based at least in part on the user-specified preferences and/or thresholds, to pay the bill. Thebill payment module224 of the mobile device120(1) may receive an indication from the user to postpone the payment to a later date, to schedule a reminder to review the account on a certain date, or to proceed with the payment. In some embodiments, the user-specified preferences may specify multiple criteria for payment. For example, the user-specified preferences may indicate that the bill should be paid using a particular bank account prior to the due date and only facilitate payment when the bank account reaches a specified threshold. For example, the user may authorize payment of the bill, specifying that the bill should be paid prior to the due date whenever the bank account reaches a certain balance. If thebill payment module224 of the mobile device120(1) determines that the bill has not been paid a pre-determined number of days before the due date because the balance of the bank account did not reach the specified amount, thebill payment module224 of the mobile device120(1) may generate a notification to the user, alerting them of the situation.
• For example, the user may receive a bill in the amount of $67.00. The user-specified preferences may indicate that the bill should not be paid unless there is over $100.00 in the user's bank account. The user may have $90.00 currently in the bank account. Thebill payment module224 of the mobile device120(1) may determine that based on the user-specified preferences, the bill should not be automatically paid. Thebill payment module224 of the mobile device120(1) may generate a notification to the user indicating the bill amount ($67.00), the current balance of the bank account ($90.00), and the threshold indicated by the user ($100.00). The message may comprise links that may be presented to the user in the form of buttons.
• In some embodiments, thebill payment module224 of the mobile device120(1) may be for a specific merchant or vendor, in which case the application may only retrieve and facilitate bill management and payment for the merchant or vendor. For example, thebill payment module224 of the mobile device120(1) may be specific to a cellular service provider and only bills for the cellular service provider may be retrieved and paid using the application.
• In some embodiments, thebill payment module224 of the mobile device120(1) may enable the user to aggregate bills from multiple vendors or merchants. For example, a user may add all their utility bills for management by the mobile bill management application. Notifications may be received from each of the multiple vendors or may be received from a third party financial institute that has facilitated mobile bill management for the vendors.
• Now referring toFIG. 4, a series ofuser interfaces400 for mobile bill management are depicted in accordance with an embodiment of the disclosure. For example, some or all of the user interfaces can be used to implement the system and system components shown and described with respect toFIGS. 1 and 2, and the methods shown and described with respect toFIG. 3. Turning toFIG. 4, auser interface420 generated by thebill payment module224 of the mobile device120(1) can display a notification to a user. The notification indicates that a bill for PG&E is available, the amount due is $98.12, and the due date is Mar. 10, 2013. The interface also displays several buttons and hyperlinks, including the View button, the Verify & Pay button, a Remind Me Later link and a Manage Alerts link. By selecting the Verify & Pay button, the mobile device may display430, which displays a snapshot view of the bill.430 permits the user to View Details of the bill, Change the payment method of the bill, Verify an amount and date for the payment.430 also permits the user to select an option to set-up automatic payments.440 displays further details of the bill by displaying a line item breakdown of the bill.450 is an interface generated by thebill payment module224 of the mobile device120(1) that displays upcoming bills and permits the user to manage bills via the mobile device120(1).
• Using some or all of the above systems and processes, a technical solution implementing bill payment functionality in mobile commerce can be enabled. For example, technical solutions involving approving and/or rejecting a bill payment using a mobile device can be implemented. In this manner, technical solutions can be implemented such that consumers can better manage budgets as well as consumer spending, and be better informed about information that may affect the consumer's decision to complete a purchase transaction.
• Some embodiments of the disclosure can have other aspects, elements, features, operations, acts, and steps in addition to or in place of what is described above. These potential additions and replacements are described throughout the rest of the specification.
CONCLUSION
• The operations and processes described and shown above may be carried out or performed in any suitable order as desired in various implementations. Additionally, in certain implementations, at least a portion of the operations may be carried out in parallel. Furthermore, in certain implementations, less than or more than the operations described may be performed.
• Certain aspects of the disclosure are described above with reference to block and flow diagrams of systems, methods, apparatuses, and/or computer program products according to various implementations. It will be understood that one or more blocks of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and the flow diagrams, respectively, can be implemented by computer-executable program instructions Likewise, some blocks of the block diagrams and flow diagrams may not necessarily need to be performed in the order presented, or may not necessarily need to be performed at all, according to some implementations.
• These computer-executable program instructions may be loaded onto a special-purpose computer or other particular machine, a processor, or other programmable data processing apparatus to produce a particular machine, such that the instructions that execute on the computer, processor, or other programmable data processing apparatus create means for implementing one or more functions specified in the flow diagram block or blocks. These computer program instructions may also be stored in a computer-readable storage media or memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage media produce an article of manufacture including instruction means that implement one or more functions specified in the flow diagram block or blocks. As an example, certain implementations may provide for a computer program product, comprising a computer-readable storage medium having a computer-readable program code or program instructions implemented therein, said computer-readable program code adapted to be executed to implement one or more functions specified in the flow diagram block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational elements or steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide elements or steps for implementing the functions specified in the flow diagram block or blocks.
• Accordingly, blocks of the block diagrams and flow diagrams support combinations of means for performing the specified functions, combinations of elements or steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and flow diagrams, can be implemented by special-purpose, hardware-based computer systems that perform the specified functions, elements or steps, or combinations of special-purpose hardware and computer instructions.
• Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain implementations could include, while other implementations do not include, certain features, elements, and/or operations. Thus, such conditional language is not generally intended to imply that features, elements, and/or operations are in any way required for one or more implementations or that one or more implementations necessarily include logic for deciding, with or without user input or prompting, whether these features, elements, and/or operations are included or are to be performed in any particular implementation.
• Many modifications and other implementations of the disclosure set forth herein will be apparent having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the disclosure is not to be limited to the specific implementations disclosed and that modifications and other implementations are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims (20)

What is claimed is:

1. A computer-implemented method comprising:

receiving, by user device comprising one or more processors, a notification from a financial institution, wherein the notification comprises information associated with a bill;

displaying, by the user device, the notification;

receiving, by the user device from a user, an indication for an action associated with a payment of the bill; and

processing, by the user device, the action associated with the payment of the bill.

2. The computer-implemented method ofclaim 1, wherein the action is an authorization to facilitate the payment of the bill.

3. The computer implemented method ofclaim 2, further comprising:

displaying, by the user device, payment details associated with the payment of the bill;

receiving, by the user device, a confirmation from the user to facilitate payment of the bill; and

transmitting, by the user device to the financial institution, the payment details associated with the payment of the bill.

4. The computer-implemented method ofclaim 3, wherein the payment details comprise an amount, a payment date, and a payment method.

5. The computer-implemented method ofclaim 2, further comprising:

receiving, by the user device from the user, a date to pay the bill; and

scheduling, by the user device, payment of the bill based at least in part on the date received from the user.

6. The computer-implemented method ofclaim 1, wherein the action is a postponement of payment of the bill.

7. The computer-implemented method ofclaim 6, further comprising:

scheduling, by the user device based at least in part on a user-specified preference, a reminder to pay the bill.

8. The computer-implemented method ofclaim 1, wherein the action is to view further details associated with the bill.

9. The computer-implemented method ofclaim 8, further comprising:

retrieving, by the user device, the bill from the financial institution.

10. The computer-implemented method ofclaim 9, further comprising:

transmitting, by the user device, the bill to an email associated with the user.

11. A system comprising:

at least one memory storing computer-executable instructions; and

at least one processor, wherein the at least one processor is configured to access the at least one memory and to execute the computer-executable instructions to:

receive a notification from a financial institution, wherein the notification comprises information associated with a bill;

display the notification;

receive, from a user, an indication for an action associated with a payment of the bill; and

process the action associated with the payment of the bill.

12. The system ofclaim 11, wherein the action is an authorization to facilitate the payment of the bill.

13. The system ofclaim 12, wherein the at least one processor is further configured to execute the computer-executable instructions to:

display payment details associated with the payment of the bill;

receive a confirmation from the user to facilitate payment of the bill; and

transmit, to the financial institution, the payment details associated with the payment of the bill.

14. The system ofclaim 13, wherein the payment details comprise an amount, a payment date, and a payment method.

15. The system ofclaim 12, wherein the at least one processor is further configured to execute the computer-executable instructions to:

receive, from the user, a date to pay the bill; and

schedule payment of the bill based at least in part on the date received from the user.

16. The system ofclaim 11, wherein the action is a postponement of payment of the bill.

17. The system ofclaim 16, wherein the at least one processor is further configured to execute the computer-executable instructions to:

schedule, based at least in part on a user-specified preference, a reminder to pay the bill.

18. The system ofclaim 11, wherein the action is to view further details associated with the bill.

19. The system ofclaim 18, wherein the at least one processor is further configured to execute the computer-executable instructions to:

retrieve the bill from the financial institution.

20. The system ofclaim 19, wherein the at least one processor is further configured to execute the computer-executable instructions to:

transmit the bill to an email associated with the user.

Images