U.S. patent application number 14/024352 was filed with the patent office on 2014-03-20 for systems and methods for implementing mobile bill payment functionality in mobile commerce.
This patent application is currently assigned to FIRST DATA CORPORATION. The applicant listed for this patent is FIRST DATA CORPORATION. Invention is credited to Jerome Wendell Myers, Vijay Kumar Royyuru, J. Scott Sanchez.
Application Number | 20140081853 14/024352 |
Document ID | / |
Family ID | 50232232 |
Filed Date | 2014-03-20 |
United States Patent
Application |
20140081853 |
Kind Code |
A1 |
Sanchez; J. Scott ; et
al. |
March 20, 2014 |
SYSTEMS AND METHODS FOR IMPLEMENTING MOBILE BILL PAYMENT
FUNCTIONALITY IN MOBILE COMMERCE
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.
Inventors: |
Sanchez; J. Scott; (Atlanta,
GA) ; Royyuru; Vijay Kumar; (Norristown, PA) ;
Myers; Jerome Wendell; (Douglasville, GA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
FIRST DATA CORPORATION |
Greenwood Village |
CO |
US |
|
|
Assignee: |
FIRST DATA CORPORATION
Greenwood Village
CO
|
Family ID: |
50232232 |
Appl. No.: |
14/024352 |
Filed: |
September 11, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61699728 |
Sep 11, 2012 |
|
|
|
61799676 |
Mar 15, 2013 |
|
|
|
Current U.S.
Class: |
705/40 |
Current CPC
Class: |
G06Q 20/204 20130101;
G06Q 40/025 20130101; G06Q 30/0625 20130101; G06Q 20/3265 20200501;
G06Q 30/0222 20130101; G06Q 20/102 20130101; G06Q 20/3278 20130101;
G06Q 20/3276 20130101; B60S 3/00 20130101; G06Q 30/0633 20130101;
G06Q 30/0267 20130101; G06Q 20/02 20130101; G06Q 20/42 20130101;
G06Q 20/4037 20130101; G06Q 20/3224 20130101; G06Q 20/40 20130101;
G06Q 20/3223 20130101; H04L 63/083 20130101; G06Q 20/24 20130101;
G06Q 30/0233 20130101 |
Class at
Publication: |
705/40 |
International
Class: |
G06Q 20/10 20060101
G06Q020/10 |
Claims
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 of claim 1, wherein the action
is an authorization to facilitate the payment of the bill.
3. The computer implemented method of claim 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 of claim 3, wherein the payment
details comprise an amount, a payment date, and a payment
method.
5. The computer-implemented method of claim 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 of claim 1, wherein the action
is a postponement of payment of the bill.
7. The computer-implemented method of claim 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 of claim 1, wherein the action
is to view further details associated with the bill.
9. The computer-implemented method of claim 8, further comprising:
retrieving, by the user device, the bill from the financial
institution.
10. The computer-implemented method of claim 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 of claim 11, wherein the action is an authorization
to facilitate the payment of the bill.
13. The system of claim 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 of claim 13, wherein the payment details comprise an
amount, a payment date, and a payment method.
15. The system of claim 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 of claim 11, wherein the action is a postponement of
payment of the bill.
17. The system of claim 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 of claim 11, wherein the action is to view further
details associated with the bill.
19. The system of claim 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 of claim 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.
Description
RELATED APPLICATIONS
[0001] 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
[0002] The disclosure generally relates to mobile commerce, and
more particularly, to systems and methods for implementing mobile
bill payment functionality in mobile commerce.
BACKGROUND
[0003] 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
[0004] The disclosure relates to systems and methods for
implementing mobile bill payment functionality in mobile
commerce.
[0005] 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.
[0006] In one aspect of an embodiment, the action may be an
authorization to facilitate the payment of the bill.
[0007] 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.
[0008] In one aspect of an embodiment, the payment details may
include an amount, a payment date, and a payment method.
[0009] 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.
[0010] In one aspect of an embodiment, the action may be a
postponement of payment of the bill.
[0011] 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.
[0012] In one aspect of an embodiment, the action may be to view
further details associated with the bill.
[0013] In one aspect of an embodiment, the user device may retrieve
the bill from the financial institution.
[0014] In one aspect of an embodiment, the user device may transmit
the bill to an email associated with the user.
[0015] 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.
[0016] In one aspect of an embodiment, the action may be an
authorization to facilitate the payment of the bill.
[0017] 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.
[0018] In one aspect of an embodiment, the payment details may
include an amount, a payment date, and a payment method.
[0019] 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.
[0020] In one aspect of an embodiment, the action may be a
postponement of payment of the bill.
[0021] 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.
[0022] In one aspect of an embodiment, the action may be to view
further details associated with the bill.
[0023] 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.
[0024] 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
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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
[0030] Certain embodiments of the disclosure will now be described
more fully hereinafter with accompanying drawings and corresponding
description in FIGS. 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
[0031] 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).
[0032] 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.
[0033] 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.
[0034] 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 in FIG.
1, and each may have similar or different functionality, such as
described in FIG. 2, according to various embodiments and
implementations as described herein.
Certain Example Implementations and Embodiments
[0035] An example architecture or environment for a system 100
according various embodiments of the disclosure is shown in and
described with respect to FIG. 1. A mobile commerce application
program or module, such as 102, can be stored in memory 104 at a
server device 106. In certain embodiments, a mobile commerce
application program or module, such as 108, can be stored in memory
110 at a merchant system computer 112 or associated merchant device
114. In certain embodiments, a mobile commerce application program
or module, such as 116(1), can be stored in memory 118(1) at a
mobile device 120(1) associated with a consumer 122(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.
[0036] As shown in FIG. 1, the system 100 may include or otherwise
support one or more merchant system computers 112 and/or associated
merchant devices 114, one or more consumer or mobile devices
120(1)-120(N), one or more server transaction processing systems
106, and one or more issuer or financial institution systems 124. A
wide variety of different types of consumer or mobile devices
120(1)-120(N) may be provided or otherwise supported, such as
consumer computers and/or mobile communication devices. As desired,
the system 100 may provide or otherwise support a wide variety of
other entities associated with payment transactions, such as one or
more server transaction processing systems 106. Any number of
suitable networks and/or communication channels, such as the
illustrated networks 126, may facilitate communication between
various components of the system 100.
[0037] With reference to FIG. 1, any number of merchant system
computers 112 and/or associated merchant devices 114 may be
provided or otherwise supported. In certain embodiments, these
merchant system computers 112 and/or associated merchant devices
114 may include one or more point-of-sale (POS) devices or
terminals. As desired, each merchant system computer 112 and/or
associated merchant device 114 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.
[0038] A merchant system computer 112 and/or associated merchant
device 114 may be any suitable device that facilitates purchase
transactions, such as those in retail establishments, e-commerce
and/or mobile transactions. In operation, the merchant system
computer 112 and/or associated merchant device 114 may utilize one
or more processors 128 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.
[0039] In addition to having one or more processors 128, the
merchant system computer 112 and/or associated merchant device 114
may further include and/or be associated with one or more memory
devices 110, input/output ("I/O") interface(s) 130, network
interface(s), and/or location services 132. The memory 110 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. The memory 110 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 mobile
commerce application program 108. The data files may include any
suitable data that facilitates the operation of the merchant system
computer 112 and/or associated merchant device 114, and/or
interaction of the merchant system computer 112 and/or associated
merchant device 115 with one or more other components (e.g., one or
more one or more consumer or mobile devices 120(1)-120(N), one or
more server transaction processing systems 106, one or more
merchant acquiring platforms, one or more issuer systems, one or
more financial institution systems 124, etc.) of the system 100.
For example, the data files may include information associated with
one or more websites 134 (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.
[0040] 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.RTM., Apple OSX.TM., 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 the merchant system
computer 112 and/or associated merchant device 114, and external
devices, such as the consumer or mobile devices 120(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 as 134, 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 devices
120(1)-120(N).
[0041] The transaction modules or applications, such as the mobile
commerce application program 108, 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 device 120(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").
[0042] In one example embodiment, a transaction module, such as the
mobile commerce application program 108, 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
server transaction processing system 106 invoke one or more
suitable applications on the mobile device, such as 120(1), (e.g.,
a wallet application, a mobile commerce application program, a
transaction module, etc.) in order to receive validation
information from the mobile device 120(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 or financial institution system
124 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 or financial institution
system 124 may verify the validation information and determine
whether a card present e-commerce transaction will be allowed.
[0043] 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.
[0044] Similarly, in some embodiments, a payment device, such as
135(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 as 122(1)-122(N). The payment device,
such as 135(1), can be used to request a purchase and/or
loyalty/reward transaction when presented to a merchant system
computer 112 and/or merchant computer device 114, either directly
by the consumer 135(1) or via a consumer's mobile device, such as
120(1)-120(N). In these instances, an associated transaction
module, such as the mobile commerce application program 108
associated with the merchant computer system 112 and/or merchant
computer device 114, can receive payment device information, such
as an account number and/or other payment device information, and
communicate, via one or more networks 126, some or all of the
payment device information to an issuer system or financial
institution system 124 with the proposed transaction information
for processing.
[0045] Example application programs or modules associated with the
operations that may be performed by a transaction module or mobile
commerce application program 108 and/or the merchant system
computer 112 and/or associated merchant device 114 are described in
greater detail below with reference to FIG. 2.
[0046] With continued reference to the merchant system computer 112
and/or associated merchant device 114, the one or more I/O
interfaces 130 may facilitate communication between the merchant
system computer 112 and/or associated merchant device 114 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 the merchant system computer 112
and/or associated merchant device 114. The one or more network
interfaces may facilitate connection of the merchant system
computer 112 and/or associated merchant device 114 to one or more
suitable networks, such as 126, and/or communication links. In this
regard, the merchant system computer 112 and/or associated merchant
device 114 may receive and/or communicate information to other
components of the system 100, such as the consumer or mobile
devices, for example 120(1)-120(N), the server transaction
processing systems 106, and/or the issuer or financial institution
systems 124.
[0047] In certain embodiments, a merchant computer system 112
and/or associated merchant computer device 114 can be associated
with a merchant location 136, such as a retail store or "bricks and
mortar"-type establishment. The merchant location 136 may include a
code 138, 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.
[0048] In certain embodiments, a bill 139 can be generated by a
merchant computer system 112 and/or merchant system device 114 and
transmitted to a consumer's mobile device, such as 120(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.
[0049] Additionally, with continued reference to FIG. 1, any number
of consumer or mobile devices 120(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 as 120(1) may be a
suitable device that is capable of interaction with other
components of the system 100 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 as 134, including those hosted by the merchant
system computer, such as 112, identify products and/or services to
be purchased, request a purchase and/or loyalty/reward transaction,
and/or interact with the merchant system computer 112, merchant
system device 114, and/or other components of the system 100 (e.g.,
the server transaction processing system 106, etc.) during the
completion of a payment and/or loyalty/reward transaction. In one
example embodiment, a mobile device, such as 120(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 as 120(1), in order to
facilitate provision of validation information.
[0050] As desired, a consumer or mobile device, such as 120(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 as 120(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 device
120(1), the mobile device 120(1) may utilize one or more processors
140(1) to execute computer-readable instructions that facilitate
the general operation of the mobile device 120(1) (e.g., call
functionality, etc.) and/or communication with a merchant system
computer 112, merchant system device 114, and/or other components
of the system 100 (e.g., the server transaction processing system
106) 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.
[0051] In addition to having one or more processors, the mobile
device, such as 120(1)-120(N), may further include and/or be
associated with one or more memory devices 118(1)-118(N),
input/output ("I/O") interface(s) 142(1)-142(N), network
interface(s), and/or location services 144(1)-144(N). The memory
118(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
memory 118(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 program 116(1)-116(N). In certain embodiments,
a mobile device, such as 120(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 memory 118(1) and/or included
as a separate component of the mobile device 120(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 program 116(1), may be stored on a
secure element. The transaction modules may be invoked by other
components of the mobile device 120(1) and/or by one or more other
components of the system 100, such as the merchant system computer
112, merchant system device 114, and/or the server transaction
processing system 106.
[0052] The data files may include any suitable data that
facilitates the operation of the mobile device, such as 120(1),
and/or interaction of the mobile device 120(1) with one or more
other components (e.g., a merchant system computer 112, merchant
system device 114, a server transaction processing system 106,
etc.) of the system 100. 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 as
120(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
device 120(1) may also include one or more suitable browser
applications that facilitate the access of one or more webpages
hosted by the merchant system computer 112, and/or third party or
merchant websites, such as 134.
[0053] 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 as 120(1). In
certain embodiments, a transaction module or mobile commerce
application program, such as 116(1), may also facilitate
communication with a server transaction processing system, such as
106, or a trusted service manager. A wide variety of suitable
techniques may be utilized to install a transaction module on the
mobile device, such as 120(1). For example, a transaction module
may be provisioned to the mobile device 120(1) by a server
transaction processing system 106 and/or by an issuer or financial
institution system 124. 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 as 122(1) may be prompted to enter an
mPIN, such as a multi-character and/or multi-numeral code, to an
associated mobile device, such as 120(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 as 124, 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.
[0054] 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 a merchant system computer 112, merchant system
device 114, or by a server transaction processing system 106 at the
request of the merchant system computer 112 and/or merchant system
device 114. 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 as 120(1), by the merchant system computer 112,
merchant system device 114, or server transaction processing system
106. 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 as 122(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.
[0055] If, however, the entered mPIN value is authenticated, then
the transaction module may provide payment account data and
associated validation data to the merchant system computer 112,
merchant system device 114, or server transaction processing system
106. 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 consumer 122(1), an indication
that the entered mPIN was authenticated by the mobile device 120(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 as 124, for authentication and/or risk
analysis purposes.
[0056] 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.
[0057] The one or more I/O interfaces, such as 142(1)-142(N), may
facilitate communication between the mobile device, such as 120(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 device 120(1). Further, the one or more
network interfaces may facilitate connection of the mobile device,
such as 120(1), to one or more suitable networks, for example, the
network(s) 126 illustrated in FIG. 1. In this regard, the mobile
device, such as 120(1), may receive and/or communicate information
to other components of the system 100.
[0058] With continued reference to FIG. 1, as desired in various
embodiments, any number of server transaction processing systems,
such as 106, may be provided or otherwise supported. A server
transaction processing system 106 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
the merchant system computer 112 and/or merchant system device 114.
For example, server transaction processing system 106 may include
any number of processors 146, memories, I/O interfaces 148, and/or
network interfaces. In certain embodiments, a server transaction
processing system 106 can include one or more transaction modules,
such as a mobile commerce application program 102 and/or a social
network integration program application 150. In any instance, the
transaction modules can facilitate communications and/or
interactions with any number of consumer or mobile devices such as
120(1)-120(N), merchant computer systems such as 112, merchant
computer devices 114, data stores 151, third party websites such as
134, and financial institution systems such as 124. In certain
embodiments, a service transaction processing system, such as 106,
can host a social network integration program application, such as
150, 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/or service data 152 on a
third party or merchant website, such as 134.
[0059] Furthermore, as desired, a server transaction processing
system, such as 106, may provide a wide variety of transaction
module provisioning services. Additionally, a server transaction
processing system, such as 106, 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 as 106, may include similar components as those discussed
above for the merchant system computer, such as 112, and/or
merchant system device, such as 114. For example, a server
transaction processing system, such as 106, may include any number
of processors, memories, I/O interfaces, and/or network
interfaces.
[0060] With continued reference to FIG. 1, as desired in various
embodiments, any number of issuer or financial institution systems,
such as 124, may be provided or otherwise supported. An issuer or
financial institution system, such as 124, 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 as 124, may host a
payment processing application program, such as 154, 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 as
124, via a suitable transaction network (e.g., a debit network, a
credit network, etc.), and the issuer or financial institution
system, such as 124, may evaluate the payment transaction via the
payment processing application program, such as 154, or module. An
approval or rejection of the payment transaction may then be output
for communication to a merchant system computer, such as 112,
and/or merchant system device 114. The issuer or financial
institution system, such as 124, may then facilitate the settlement
of the payment transaction. In certain embodiments, an issuer or
financial institution system, such as 124, may include similar
components as those discussed above for the merchant system
computer 112 and/or merchant system device 114. For example, an
issuer or financial institution system, such as 124, may include
any number of processors 156, memories 158, I/O interfaces 160,
and/or network interfaces.
[0061] In certain embodiments of the disclosure, an issuer or
financial institution system, such as 124, may receive validation
information in association with a purchase and/or loyalty/reward
transaction.
[0062] A wide variety of suitable networks, individually and/or
collectively shown as 126 in FIG. 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.
[0063] The system 100 shown in and described with respect to FIG. 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
in FIG. 1. Accordingly, embodiments of the disclosure should not be
construed as being limited to any particular operating environment,
system architecture, or device configuration.
[0064] FIG. 2 shows an example mobile commerce application program
200, similar to the mobile commerce application programs 102, 108,
and 116(1)-116(N) in FIG. 1 that can operate with respect to the
system 100 shown in FIG. 1. The mobile commerce application program
200 shown in FIG. 2 can include, for example, a loyalty/rewards
module 202, a check-in-to-pay module 204, an interruptive alert
module 206, a share redeemed offer module 208, a notification or
messaging module 210, a restaurant mobile payment module 212, a
check-in-to-pay at QSR module 214, a split the bill module 216, a
lifecycle shopping module 218, a linking transaction module 220, a
mobile device login module 222, a bill payment module 224, a
multi-consumer remote payment module 226, an instant issuance
module 228, a check-in to pump gas module 230, a buy car wash
module 232, a drive consumer inside module 234, a tokenization
module 236, and a code generation module 238. Some or all of the
modules 202-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 mobile commerce application program
200 in FIG. 2.
[0065] While the various modules 202-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
[0066] In some instances, consumers may desire to make bill
payments using a mobile device 120(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 device 120(1) acts as a first decision
point for each bill payment. For example, a notification can arrive
on a consumer's mobile phone 120(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 device 120(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.
[0067] In one embodiment, by way of a mobile device 120(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 device 120(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 device 120(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.
[0068] 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.
[0069] 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 devices 120(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 device
120(1) in communication with one or more financial institution
servers 124. In some embodiments, the system may include one or
more intermediary servers where the mobile device 120(1)
communicates with the intermediary servers and the intermediary
servers may communicates with the financial institution
servers.
[0070] FIG. 3 is a flow diagram of a method 300 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 in FIGS. 1 and
2. In brief overview, at block 302, a bill payment module 224 of a
mobile device 120(1) may receive a notification. At block 304, the
bill payment module 224 of the mobile device 120(1) may display the
notification to the user. At block 306, the bill payment module 224
of the mobile device 120(1) may receive an indication from a user.
At block 308, a determination may be made by the bill payment
module 224 of the mobile device 120(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. At block 310, in
response to determining a user approved the bill payment, the bill
payment module 224 of the mobile device 120(1) may transmit a
message authorizing bill payment. At block 312, in response to
determining the user selected to postpone bill payment, the bill
payment module 224 of the mobile device 120(1) may transmit a
message to schedule a reminder. At block 314, in response to
determining that the user selected to view more details of the
bill, the bill payment module 224 of the mobile device 120(1) may
retrieve additional bill details. At block 316, the user may select
to approve or postpone bill payment. If the user chooses to
authorize bill payment, then the method may proceed to block 310.
If the user chooses to postpone bill, payment, then the method may
proceed to block 312.
[0071] At block 302, the bill payment module 224 of the mobile
device 120(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.
[0072] At block 304, the bill payment module 224 of the mobile
device 120(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.
[0073] At block 306, the bill payment module 224 of the mobile
device 120(1) may receive an indication from a user. In some
embodiments, the bill payment module 224 of the mobile device
120(1) may receive an indication from the user via a selection of a
presented button.
[0074] At block 308, the bill payment module 224 of the mobile
device 120(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.
[0075] At block 310, in response to determining a user approved the
bill payment, the bill payment module 224 of the mobile device
120(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. The bill payment module 224 of the mobile
device 120(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, the bill payment module 224 of
the mobile device 120(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,
the bill payment module 224 of the mobile device 120(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.
[0076] At block 312, in response to determining the user selected
to postpone bill payment, the bill payment module 224 of the mobile
device 120(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 the
bill payment module 224 of the mobile device 120(1) requesting a
date for the reminder. In some embodiments, in response to the user
selecting to postpone payment of the bill, the bill payment module
224 of the mobile device 120(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, the bill payment module 224 of the mobile device
120(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, the bill payment module 224 of the
mobile device 120(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.
[0077] At block 314, in response to determining that the user
selected to view more details of the bill, the bill payment module
224 of the mobile device 120(1) may retrieve additional bill
details. In some embodiments, if the user selects to view more
details, the bill payment module 224 of the mobile device 120(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 device 120(1).
The message may display more details of the bill. In some
embodiments, if the user selects to view more details, the bill
payment module 224 of the mobile device 120(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, the bill payment
module 224 of the mobile device 120(1) may generate a message
containing a hyperlink which, when selected, may open a web browser
to display the bill or statement.
[0078] At block 316, the user may select to approve or postpone
bill payment. If the user chooses to authorize bill payment, then
the method may proceed to block 310. If the user chooses to
postpone bill, payment, then the method may proceed to block
312.
[0079] In some embodiments, the bill payment module 224 of the
mobile device 120(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. The
bill payment module 224 of the mobile device 120(1) may obtain a
current balance of the account. The bill payment module 224 of the
mobile device 120(1) may determine, based at least in part
user-specified preferences and/or thresholds, whether there are
sufficient funds to pay the bill. If the bill payment module 224 of
the mobile device 120(1) determines that there is sufficient funds
to pay the bill, then the bill payment module 224 of the mobile
device 120(1) will facilitate the bill payment. If the bill payment
module 224 of the mobile device 120(1) determines there are not
sufficient funds, based at least in part on the user-specified
preferences and/or thresholds, then the bill payment module 224 of
the mobile device 120(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. The bill payment module 224 of the mobile device 120(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 the bill payment module 224 of the mobile device 120(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, the bill payment module 224 of
the mobile device 120(1) may generate a notification to the user,
alerting them of the situation.
[0080] 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.
The bill payment module 224 of the mobile device 120(1) may
determine that based on the user-specified preferences, the bill
should not be automatically paid. The bill payment module 224 of
the mobile device 120(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.
[0081] In some embodiments, the bill payment module 224 of the
mobile device 120(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, the
bill payment module 224 of the mobile device 120(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.
[0082] In some embodiments, the bill payment module 224 of the
mobile device 120(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.
[0083] Now referring to FIG. 4, a series of user interfaces 400 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 to FIGS. 1 and 2, and
the methods shown and described with respect to FIG. 3. Turning to
FIG. 4, a user interface 420 generated by the bill payment module
224 of the mobile device 120(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 display 430, 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 the bill payment module 224 of the mobile
device 120(1) that displays upcoming bills and permits the user to
manage bills via the mobile device 120(1).
[0084] 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.
[0085] 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
[0086] 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.
[0087] 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.
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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.
* * * * *