U.S. patent application number 13/934008 was filed with the patent office on 2014-01-09 for systems, methods, and computer program products for integrating third party services with a mobile wallet.
The applicant listed for this patent is JVL Ventures, LLC. Invention is credited to Kai P. Johnson, Stephen Kuhn, Daniel L. Lipton, Ryan Watkins.
Application Number | 20140012750 13/934008 |
Document ID | / |
Family ID | 48782669 |
Filed Date | 2014-01-09 |
United States Patent
Application |
20140012750 |
Kind Code |
A1 |
Kuhn; Stephen ; et
al. |
January 9, 2014 |
SYSTEMS, METHODS, AND COMPUTER PROGRAM PRODUCTS FOR INTEGRATING
THIRD PARTY SERVICES WITH A MOBILE WALLET
Abstract
Systems, methods, and computer program products are provided for
providing a message via a mobile wallet. A structured data object
message is received from one of a plurality of service provider
systems via a communication network. A payment product associated
with the structured data object message is identified based on
service provider data stored in a wallet database. A wallet client
associated with the payment product is identified based on
synchronization data stored in the wallet database. The structured
data object message is transmitted to the identified wallet client,
thereby causing the identified wallet client to display the
notification in association with the identified payment
product.
Inventors: |
Kuhn; Stephen; (Tarrytown,
NY) ; Lipton; Daniel L.; (New York, NY) ;
Johnson; Kai P.; (San Diego, CA) ; Watkins; Ryan;
(Brooklyn, NY) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
JVL Ventures, LLC |
New York |
NY |
US |
|
|
Family ID: |
48782669 |
Appl. No.: |
13/934008 |
Filed: |
July 2, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61669576 |
Jul 9, 2012 |
|
|
|
61669915 |
Jul 10, 2012 |
|
|
|
61816488 |
Apr 26, 2013 |
|
|
|
Current U.S.
Class: |
705/41 |
Current CPC
Class: |
H04W 4/60 20180201; G06Q
40/00 20130101; G06Q 20/36 20130101; G06Q 20/32 20130101; H04L
67/141 20130101; G06Q 20/3674 20130101; G06Q 20/02 20130101; G06Q
20/40 20130101; G06Q 20/367 20130101; G06Q 20/3829 20130101; G06Q
2220/00 20130101 |
Class at
Publication: |
705/41 |
International
Class: |
G06Q 20/36 20060101
G06Q020/36 |
Claims
1. A system for integrating third party services in a mobile
wallet, the system comprising: a wallet database operable to store
service provider data and synchronization data; and a wallet server
communicatively coupled to the wallet database and including at
least one processor operable to: receive, via a communication
network from one of a plurality of service provider systems, a
structured data object message; identify, based on the service
provider data, a payment product associated with the structured
data object message; identify, based on the synchronization data, a
wallet client associated with the payment product; and transmit the
structured data object message to the identified wallet client,
thereby causing the identified wallet client to display the
notification in association with the identified payment
product.
2. The system of claim 1, the at least one processor being further
operable to, in response to the notification being selected, cause
the wallet client to present additional information based on the
structured data object message.
3. The system of claim 2, the at least one processor being further
operable to cause the additional information to be presented in a
context of the wallet client, and in a custom format including a
plurality of sections defined by a service provider system via one
or more elements of the structured data object message.
4. The system of claim 2, the at least one processor being further
operable to: cause the wallet client to present an interactive user
interface element corresponding to an offer that; and cause the
wallet client to launch, when the user interface element is
selected, at least one of a service provider website, a service
provider web application, a service provider mobile device
application, or a mobile device application store application.
5. The system of claim 4, the at least one processor being further
operable to cause a wallet client database to store a uniform
resource locator corresponding to at least one of the service
provider website, the service provider web application, the service
provider mobile device application, or the mobile device
application store application.
6. The system of claim 1, the at least one processor being further
operable to receive the service provider data from a plurality of
service providers via a wallet administration tool.
7. The system of claim 1, further comprising a step of periodically
synchronizing the structured data object message between the
identified wallet client and a wallet server.
8. A method for providing a message via a mobile wallet, the method
comprising steps of: receiving, via a communication network from
one of a plurality of service provider systems, a structured data
object message; identifying, based on service provider data stored
in a wallet database, a payment product associated with the
structured data object message; identifying, based on
synchronization data stored in the wallet database, a wallet client
associated with the payment product; and transmitting the
structured data object message to the identified wallet client,
thereby causing the identified wallet client to display the
notification in association with the identified payment
product.
9. The method of claim 8, further comprising steps of: receiving a
selection of the notification; and causing the wallet client to
present additional information based on the structured data object
message, in response to the receiving of the selection.
10. The method of claim 9, wherein the additional information is
presented, in a context of the wallet client, and in a custom
format including a plurality of sections defined by a service
provider system via one or more elements of the structured data
object message.
11. The method of claim 9, wherein the presenting the additional
information further includes presenting an interactive user
interface element corresponding to an offer that, when selected,
causes the wallet client to launch at least one of a service
provider website, a service provider web application, a service
provider mobile device application, or a mobile device application
store application.
12. The method of claim 11, further comprising launching at least
one of the service provider website, the service provider web
application, the service provider mobile device application, or the
mobile device application store application, based on a uniform
resource locator stored in a wallet client database.
13. The method of claim 8, further comprising steps of: receiving
the service provider data from a plurality of service providers via
a wallet administration tool; and storing portions of the service
provider data in the wallet database in association with
corresponding ones of the plurality of service providers.
14. The method of claim 8, further comprising a step of
periodically synchronizing the structured data object message
between the identified wallet client and a wallet server.
15. A non-transitory computer-readable medium having stored thereon
sequences of instructions that, when executed by a computer
processor, cause the computer processor to: receive, via a
communication network from one of a plurality of service provider
systems, a structured data object message; identify, based on
service provider data stored in a wallet database, a payment
product associated with the structured data object message;
identify, based on synchronization data stored in the wallet
database, a wallet client associated with the payment product; and
transmit the structured data object message to the identified
wallet client, thereby causing the identified wallet client to
display the notification in association with the identified payment
product.
16. The non-transitory computer-readable medium of claim 15,
wherein, when executed by the computer processor, the sequences of
instructions further cause the computer processor to: receive a
selection of the notification; and cause the wallet client to
present additional information based on the structured data object
message, in response to the receiving of the selection.
17. The non-transitory computer-readable medium of claim 16,
wherein, when executed by the computer processor, the sequences of
instructions further cause the computer processor to present the
additional information in a context of the wallet client, and in a
custom format including a plurality of sections defined by a
service provider system via one or more elements of the structured
data object message.
18. The non-transitory computer-readable medium of claim 16,
wherein, when executed by the computer processor, the sequences of
instructions further cause the computer processor to: present an
interactive user interface element corresponding to an offer that,
when selected, and launch at least one of a service provider
website, a service provider web application, a service provider
mobile device application, or a mobile device application store
application.
19. The non-transitory computer-readable medium of claim 18,
wherein, when executed by the computer processor, the sequences of
instructions further cause the computer processor to launch at
least one of the service provider website, the service provider web
application, the service provider mobile device application, or the
mobile device application store application, based on a uniform
resource locator stored in a wallet client database.
20. The non-transitory computer-readable medium of claim 15,
wherein, when executed by the computer processor, the sequences of
instructions further cause the computer processor to: receive the
service provider data from a plurality of service providers via a
wallet administration tool; and store portions of the service
provider data in the wallet database in association with
corresponding ones of the plurality of service providers.
21. The non-transitory computer-readable medium of claim 15,
wherein, when executed by the computer processor, the sequences of
instructions further cause the computer processor to periodically
synchronize the structured data object message between the
identified wallet client and a wallet server.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] The present application claims priority to U.S. Provisional
Application Nos. 61/669,576, filed on Jul. 9, 2012; 61/669,915,
filed on Jul. 10, 2012; and 61/816,488, filed on Apr. 26, 2013. The
entire contents of these applications are hereby incorporated by
reference herein.
BACKGROUND
[0002] 1. Field
[0003] Example aspects described herein relate generally to mobile
wallets in mobile devices for use in mobile commerce, and more
particularly to systems, methods, and computer program products for
integrating a mobile wallet with third party services.
[0004] 2. Related Art
[0005] Mobile devices are becoming more and more versatile, and are
being used in an increasing number of ways to make various everyday
tasks simpler and/or more efficient. One area where mobile devices
are being used is the mobile commerce environment. For example,
mobile devices are being augmented to include mobile wallets that
can be used to conduct financial (e.g., payments) and/or
non-financial (e.g., venue admissions) transactions, without the
need for physical cash, checks, credit cards, tickets, and/or the
like.
[0006] Some mobile wallets include payment products, in some cases
provided by different service providers, that a consumer (also
referred to herein as a "user") can use to conduct financial
transactions using a corresponding one or more accounts held by the
consumer at the service providers. A service provider (SP) is a
company (e.g., a credit card account issuer), organization, entity,
and/or the like that provides one or more services to customers or
consumers. Service providers often interact with consumers, for
example, to provide information regarding their accounts, their
payment product, loyalty offers, and/or the like. Service providers
have several means by which to communicate with consumers of their
services. For example, service providers may communicate with
consumers via postal mail, email, telephone, and/or the like.
However, these means are not always the most efficient way to
communicate with consumers. For example, postal mail can be slow,
and consumers may seldom check their email, or may be difficult to
reach by telephone.
[0007] Mobile wallets provide an additional means for service
providers to provide communicate with, and provide services to,
their consumers. Providing services via a mobile wallet, however,
can carry increased security risks, for example, by exposing
sensitive information to possible exploitation by hackers. In
addition, consumers may hold numerous accounts at numerous service
providers, each of which uses one or more different means of
communicating with the consumer. This can make for a fragmented and
inconsistent user experience.
[0008] Given the foregoing, it would be beneficial to enable
consumers to utilize multiple services provided by multiple service
providers via mobile wallets in a secure, efficient, integrated,
and consistent manner. It would also be beneficial to enable the
multiple service providers to provide notifications and/or other
communications to consumers via the mobile wallets in a targeted,
efficient, integrated, and consistent manner.
SUMMARY
[0009] The example embodiments herein provide systems, methods, and
computer program products for integrating a mobile wallet with
third party services.
[0010] In accordance with one example aspect herein, a structured
data object message is received from one of a plurality of service
provider systems via a communication network. A payment product
associated with the structured data object message is identified
based on service provider data stored in a wallet database. A
wallet client associated with the payment product is identified
based on synchronization data stored in the wallet database. The
structured data object message is transmitted to the identified
wallet client, thereby causing the identified wallet client to
display the notification in association with the identified payment
product.
[0011] In another example embodiment, a selection of the
notification is received and, in response to receiving the
selection, the wallet client is caused to present additional
information based on the structured data object message.
[0012] In one example herein, the additional information is
presented, in a context of the wallet client, and in a custom
format including a plurality of sections defined by a service
provider system via one or more elements of the structured data
object message.
[0013] In accordance with some example aspects herein, the method
further includes presenting an interactive user interface element
corresponding to an offer that, when selected, causes the wallet
client to launch at least one of a service provider website, a
service provider web application, a service provider mobile device
application, or a mobile device application store application.
[0014] In another example herein, the at least one of the service
provider website, the service provider web application, the service
provider mobile device application, and/or the mobile device
application store application are launched based on a uniform
resource locator (URL) stored in a wallet client database.
[0015] The service provider data is received, in one example, from
a plurality of service providers via a wallet administration tool.
Portions of the service provider data are stored in the wallet
database in association with corresponding ones of the plurality of
service providers.
[0016] The structured data object message is periodically
synchronized between the identified wallet client and a wallet
server, in accordance with another example aspect herein.
BRIEF DESCRIPTION OF THE DRAWINGS
[0017] The features and advantages of the example embodiments
presented herein will become more apparent from the detailed
description set forth below when taken in conjunction with the
following drawings.
[0018] FIG. 1 is a diagram of an exemplary system for integrating a
mobile wallet with third party (e.g., service provider) services,
in accordance with various exemplary embodiments herein.
[0019] FIG. 2 shows example options for providing access to third
party services by way of a wallet client, in accordance with an
example embodiment herein.
[0020] FIG. 3 shows an example procedure for inputting and/or
utilizing one or more data elements to support servicing
environment options, in accordance with an example embodiment
herein.
[0021] FIG. 4 shows a representative interface for exchanging data
between a wallet client, a wallet server, an ESB, and an SP system,
in accordance with an example embodiment herein.
[0022] FIG. 5 shows a representative interface for exchanging data
between a wallet client, a mobile device operating system, a mobile
device web browser, and an SP website, in accordance with an
example embodiment herein.
[0023] FIG. 6 shows a representative interface for exchanging data
between a wallet client, a mobile device operating system, and a
service provider mobile application, in accordance with an example
embodiment herein.
[0024] FIG. 7 shows a representative interface for exchanging data
between a wallet client, a mobile device operating system, and a
mobile application store, in accordance with an example embodiment
herein.
[0025] FIG. 8 shows example payment product functions or use cases
supported by an SP servicing environment, in accordance with an
example embodiment herein.
[0026] FIG. 9 shows an exemplary procedure for establishing a
session between a wallet client and an SP system using an SSO
authentication procedure, in accordance with an example embodiment
herein.
[0027] FIG. 10 shows an exemplary procedure for invoking an SP
servicing environment by a wallet client, in accordance with an
example embodiment herein.
[0028] FIG. 11 shows exemplary pages that a wallet client may
present, in accordance with various example embodiments herein.
[0029] FIG. 12 shows how custom SP notifications and/or information
may be provided via a wallet client, in accordance with an example
embodiment herein.
[0030] FIG. 13 shows how an example structured data object document
can be rendered, in accordance with an example embodiment
herein.
[0031] FIG. 14 shows how another example structured data object
document can be rendered, in accordance with an example embodiment
herein.
[0032] FIG. 15 is a block diagram of a general and/or special
purpose computer that may be employed in accordance with various
example embodiments herein.
DETAILED DESCRIPTION
I. Overview
[0033] The terms "payment product" and "card" may be used
interchangeably herein to refer to a product, such as, for example,
a credit card, a general purpose reloadable (GPR) card, and/or the
like, that may be used to conduct financial transactions.
[0034] The term "service provider data" as used herein generally
refers to data relating to one or more service providers, service
provider systems, and/or services provided by one or more service
providers. In some example embodiments herein, service provider
data refers to any data that is stored in a wallet database and/or
in a wallet client database.
[0035] The term "synchronization data" as used herein generally
refers to data communicated to and/or from a wallet client and/or a
wallet server. In some example embodiments herein, synchronization
data is communicated between a wallet client and a wallet server
during a periodic synchronization procedure.
[0036] Presented herein are novel and inventive systems, methods,
and computer program products for integrating a mobile wallet with
third party services. In accordance with some aspects described
herein, a mobile wallet client provides a platform that enables NFC
mobile payment channel as an alternative to traditional plastic
based payment solutions. The wallet client enables a third party
service provider (e.g., an issuer of a credit, debit, charge,
and/or prepaid card) to offer any payment instrument that is
traditionally offered as a plastic magnetic stripe product. The
wallet client provides a secure servicing environment that provides
the user with unique user experience features appropriate to the
specific payment product type and customizable services offered by
a service provider.
[0037] In one example aspect herein, the wallet client supports
mobile web and/or mobile application servicing environments and
enhances the user experience by enabling interaction with the
service provider's online and/or mobile banking services either
within or outside of the wallet client context. These services, in
one example, are launched by invoking uniform resource locators
(URLs) stored securely within a database of the wallet client.
[0038] In another example aspect herein, the servicing environment
enables the user to perform multiple functions such as, for
example, (1) adding a payment product; (2) viewing payment product
details, which, in one example, may include accessing a mobile
website and/or a mobile application of a service provider; (3)
activating a payment product; (4) upgrading a general purpose
reloadable (GPR) account; (5) adding funds to one or more accounts;
and (6) removing a payment product.
[0039] In yet another example aspect herein, systems, methods, and
computer program products are provided that enable multiple service
providers to deliver custom notifications to mobile devices of
their customers efficiently and effectively.
II. System
[0040] FIG. 1 is a diagram of an exemplary system 100 for
integrating a mobile wallet with third party services (e.g.,
service provider services). The system 100 includes a plurality of
mobile devices 101-1, 101-2 . . . 101-n (collectively "101"), each
of which may be a cellular phone, a tablet computer, or another
type of electronic device with connectivity to one or more mobile
networks. Each of the mobile devices 101 includes multiple
components, which will be described in more detail below. In
particular, each of the mobile devices 101 includes corresponding
ones of mobile operating systems 102-1, 102-2 . . . 102-n
(collectively "102"); mobile web browsers 103-1, 103-2 . . . 103-n
(collectively "103"); mobile application stores 104-1, 104-2 . . .
104-n (collectively "104"); wallet clients 105-1, 105-2 . . . 105-n
(collectively "105"); secure elements 106-1, 106-2 . . . 106-n
(collectively "106"); service provider (SP) mobile applications
107-1, 107-2 . . . 107-n (collectively "107"); and wallet client
databases 108-1, 108-2 . . . 108-n (collectively "108").
[0041] In the various example embodiments herein, the functionality
of components will be described in the context of individual
components (e.g., 101-1, 101-2 . . . 101-n) or in the context of
plural components (e.g., 101). This is for convenience only, and
should not be construed as limiting.
[0042] The mobile operating systems 102 manage hardware resources
of the mobile devices 101 and provide common services for executing
applications and/or programs on the mobile devices 101.
[0043] The mobile web browsers 103 are applications that retrieve
content (e.g., websites and/or the webpages of websites) from the
Internet, for example, and present the content via the mobile
devices 101.
[0044] The mobile application stores 104 are applications that can
be used to download and install mobile applications onto the mobile
devices 101.
[0045] The wallet clients 105 (which may also be referred to as
"mobile wallets") are interactive applications stored in
non-transitory memories of a corresponding ones of the mobile
devices 101. Each of the wallet clients 105 includes instructions
that, when executed by a processor (not shown in FIG. 1) of the
corresponding mobile device 101, enable a user to (1) access or use
one or more services provided by service providers, (2) communicate
with service providers, and/or (3) interact with contactless
services and/or control the operation of contactless hardware of
the mobile device 101, for example, to conduct contactless
transactions and/or process commerce information such as offer
and/or loyalty information.
[0046] The secure elements 106 are platforms onto which service
account information and corresponding applications may be added and
stored. The secure elements 106 include hardware and software, and
implement interfaces and protocols that enable the secure storage
of service account information and applications that may be used
for conducting transactions. The secure elements 106 may be
implemented in different form factors, such as, for example,
Universal Integrated Circuit Cards (UICC), embedded secure
elements, and/or a separate chips or secure devices (e.g., a
near-field communication (NFC) enabler) that can be inserted into
slots on the mobile devices 101. In one example embodiment, the
wallet clients 105 communicate with the corresponding secure
elements 106 using ISO 7816 commands, in order to conduct
contactless transactions.
[0047] The SP mobile applications 107 are applications provided by
service providers and stored in non-transitory memories of
corresponding ones of the mobile devices 101. Each of the SP mobile
applications 107 includes instructions that, when executed by a
processor (not shown in FIG. 1) of the corresponding mobile device
101, enable a user of the mobile device 101 to communicate with,
and/or utilize one or more services provided by, the service
provider. For example, an SP mobile application 107 provided by a
payment product issuer, may enable the user to check a balance of
the user's account, view transaction history and/or other
notifications regarding the user's account, and/or the like.
[0048] The wallet client databases 108 store data (e.g., service
provider data) that the wallet clients 105 utilize to perform
certain functions. For instance, the wallet client databases 108
may store SP mobile application data regarding one or more SP
mobile application(s) (e.g., the SP mobile applications 107
described above) that the wallet clients 105 use to access and/or
interact with the SP mobile applications 107. The wallet client
databases 108 may also store SP mobile website data regarding one
or more SP mobile website(s) (e.g., the SP mobile websites 116
described below) that the wallet clients 105 use to access and/or
interact with the SP mobile websites 116. In one example
embodiment, the wallet client databases 108 store preference data
regarding one or more preferences for whether to launch the SP
mobile applications 107, the SP mobile websites 116, or the mobile
application stores 104 in response to options being selected via
the mobile devices 101 (e.g., via hard or soft buttons).
[0049] Storing data (e.g., service provider data, such as SP mobile
application data, SP mobile website data, and/or preference data)
in the databases 108 in this manner enables the wallet clients 105
to execute certain functions (e.g., accessing the SP mobile
applications 107 and/or the SP mobile websites 116) without the
need to obtain certain information (e.g., URLs) from the wallet
server 109 (described below), the SP systems 114 (described below),
and/or other systems each time the functions are executed.
[0050] Although not shown in FIG. 1 for purposes of convenience,
the mobile devices 101 may also include corresponding user
interfaces, such as interactive touchscreen displays and/or
keyboards.
[0051] The system 100 also includes a wallet server 109 (which may
also be referred to as a "mobile wallet server" or a "server") and
a wallet database 110, which are mutually communicatively coupled.
The wallet server 109 is also communicatively coupled to each of
the plurality of mobile devices 101-1, 101-2 . . . 101-n by way of
a corresponding one of a plurality of mobile networks 111-1, 111-2
. . . 111-n (collectively "111"). The mobile networks 111 may be
mobile phone cellular networks, radio networks, and/or other types
of networks, each of which may be operated by a corresponding
mobile network operator (MNO) (not shown in FIG. 1).
[0052] The wallet server 109 manages communications with the wallet
clients 105, tracks the states of the wallet clients 105 (e.g., by
storing states of the wallet client 105 in the wallet database
110), and provides interfaces for communication with other computer
systems. The wallet server 109 communicates with the mobile devices
101 via the mobile networks 111 using, for example, security
protocols such as GlobalPlatform secure channel protocol, secure
sockets layer (SSL), transport layer security (TLS), and/or another
security protocol.
[0053] The wallet database 110 stores data that the wallet server
109 utilizes to perform one or more functions. For instance, the
wallet database 110 may store wallet client state data that
indicates the states of each of the wallet clients 105. In one
example embodiment, one or more SP systems 114 (described below)
can query the wallet server 109 for wallet client state data
corresponding to a particular one of the wallet clients 105. In
response to receiving the query for wallet client state data from
one or more SP systems 114, the wallet server 109 retrieves wallet
client state data from the wallet database 110 and provides the
retrieved wallet client state data to the SP system(s) 114 from
which the query was received.
[0054] In some example embodiments, the wallet database 110 stores
the data (e.g., service provider data) that, as mentioned above, is
also stored in the plurality of wallet client databases 108. In
this manner, the wallet database 110 can serve as a backup of the
wallet client databases 108, and can be used to reconfigure one or
more of the wallet client databases 108 in the event of the failure
of one or more of the wallet client databases 108.
[0055] In one example embodiment, the system 100 also includes a
wallet administration tool 112 that is communicatively coupled to
the wallet database 110. The wallet administration tool 112
provides an interface for inputting and/or storing data in the
database 110 that the wallet server 109 may utilize to perform one
or more functions, such as, for instance, launching the SP mobile
applications 107 and/or the SP mobile websites 116. An example
procedure for inputting (e.g., via the administration tool 112)
and/or utilizing (e.g., by the wallet client 105 and/or another
component of the mobile device 101) data that may be used to launch
the SP mobile applications 107 and/or the SP mobile websites 116
will be described below in the context of FIG. 3.
[0056] The system 100 also includes an enterprise service bus (ESB)
113 and a plurality of service provider (SP) systems 114-1, 114-2 .
. . 114-n (collectively "114"). The ESB 113 is communicatively
coupled to each of the SP systems 114 by way of a communications
network 115, and is communicatively coupled to the wallet server
109 by a secured communication channel. The communications network
115 may be a virtual private network (VPN), a network using
Hypertext Transfer Protocol (HTTP) standards, the Internet, and/or
another type of network.
[0057] The ESB 113 acts as an intermediary between the mobile
devices 101 and the SP systems 114. In particular, the ESB 113
routes service requests from one or more first systems (e.g.,
mobile devices 101) to one or more second systems (e.g., SP systems
114), and orchestrates processes among such systems, for example,
to provide integrated access to third party services via the wallet
clients 102. In some example embodiments, the system 100 does not
include the ESB 113 and the functions implemented by the ESB 113
are implemented by the wallet server 109 instead.
[0058] In some example embodiments, the SP systems 114 are systems
owned, operated, maintained, and/or provided by service providers
to enable customers or consumers to utilize one or more services of
the service provider. In one example, the SP systems 114 support a
defined set of messages for communication with the ESB 113. In
another example, the SP systems 114 include and/or host an
interactive SP website (e.g., a conventional website and/or a
mobile version of a website, such as the SP mobile websites 116
described below) that responds to HTTP requests and delivers
webpages formatted for display on the mobile devices 101.
[0059] The system 100 includes, in one example embodiment, a
plurality of SP mobile websites 116-1, 116-2 . . . 116-n
(collectively "116") communicatively coupled to corresponding ones
of the SP systems 114-1, 114-2 . . . 114-n (collectively "114").
The SP mobile websites 116 are hosted by corresponding service
providers and include one or more mobile webpages (e.g., URLs)
accessible by the mobile devices 101.
III. Procedure
[0060] Having described an exemplary system for integrating a
mobile wallet with one or more third party (e.g., service provider)
services, reference will now be made to FIG. 2 to describe options
for providing access to third party services by way of the wallet
client 105.
[0061] In accordance with various example embodiments herein,
several servicing environment options (i.e., options for providing
access to third party services by way of the wallet client 105) are
provided, each of which can be configured and/or customized
according to service provider preferences and/or according to the
types and/or capabilities of the mobile devices 101. Four exemplary
options for providing access to third party services by way of the
wallet client 105 are shown in FIG. 2: [0062] (1) Publishing
customer care telephone numbers via the wallet clients 105 (option
201); [0063] (2) Providing access to service provider websites 116
via the wallet clients 105 (option 202); [0064] (3) Providing
access to service provider web applications (e.g., as part of
websites 116) within the context of the wallet clients 105 (option
203); and [0065] (4) Providing access to mobile device applications
107 of the service provider, if the mobile device applications 107
are installed on the mobile devices 101 (option 204).
[0066] In one example, if the SP mobile device applications 107 are
not installed on the mobile devices 101, then the mobile
application stores 104 of the mobile devices 101 are launched and
the SP mobile applications 107 are downloaded and installed onto
the mobile devices 101.
[0067] Providing these servicing environment options via the wallet
clients 105 provides users with an integrated and unique user
experience including access to features that may be tailored to a
specific payment product type as well as customizable services
offered by service providers. By supporting mobile web and/or
mobile application servicing environments, the mobile wallets 105
enables user interaction with the service providers' online and/or
mobile banking services either within or outside of the wallet
client context, thus enhancing the user experience.
[0068] In one example embodiment, in order to support the
above-mentioned servicing environment options, one or more of the
data elements shown below in Table 1, Table 2, and/or Table 3 are
provided to, or by, each of the service providers associated with
the service provider systems 114, for example, during an onboarding
process (e.g., during an initial configuration of one or more
payment products on one or more of the components 101, 102, 103,
104, 105, 106, 107, 109, 113, and 114 (FIG. 1)):
TABLE-US-00001 TABLE 1 Data Element Mandatory/Optional Description
Service Provider Name Mandatory Text used to identify service
provider in directory Service Provider Optional Additional text
field Listing within service provider listing in directory Card
Program Name Mandatory for each Name of the payment unique payment
product product Card Concise Name Optional Abbreviated name of the
payment product used on the post tap summary screen Customer Care
All optional Displayed on the card Phone Number(s) details page;
contact Account Online URL information may appear E-mail on the
back of the card page if the card is in a blocked or other non-
active state URL to Card Registra- Mandatory Links to service tion
Webpage or (static or dynamic provider registration Mobile App Link
URL integration) page where consumers onboard cards into the mobile
wallet URL to Card Activa- Conditional (if service Link to service
provider tion Service provider requires card activation tool
activation of newly added cards) URL to Card Servicing Optional
Link to account online (Account Online or servicing tool Mobile
App) Card Art Mandatory Card image displayed in the wallet to
represent the service provider's payment product Service Provider
Logo Mandatory Logo to identify service provider in the directory
Return to Wallet URL To be provided to Links the consumer service
provider back to the mobile wallet
TABLE-US-00002 TABLE 2 Soft Card Data Mandatory/ Element Optional
Description Card Ending Digits Mandatory Must be provided for Last
4 or 5 each payment card provisioned Expiry Date Optional Placed on
card rear Current Balance Optional Placed on card rear Available
Credit Optional Placed on card rear Card State Mandatory Represents
the status of the corresponding card
TABLE-US-00003 TABLE 3 Platform Platform-based Data Element Android
App package name (e.g., com.bankx.mobile) App activity class name
(e.g., com.bankx.mobile.MainActivity) Preference: mobile website or
mobile app Mobile website URL (if preference is mobile website) iOS
URL schema name (e.g., bankx) App name (e.g., bankx-mobile-app)
Preference: mobile website or mobile application Mobile website URL
(if preference is mobile website
[0069] Although Table 3 shows different URL schemes for Android and
iOS platforms, in one example embodiment, both Android and iOS
platforms support the same URL scheme (e.g., the scheme shown in
Table 3 for the iOS platform). In this manner, a structured data
object ("SDO"; described in further detail below) may be used to
link to a mobile application, independently of any platform.
[0070] In another example embodiment, during the onboarding process
the service providers associated with the service provider systems
114 may provide to the wallet administration tool 112 automatic
login information and/or user context information. This may enable
the user to automatically login to a website 116, mobile website
116, and/or mobile application 107 of the service provider, without
having to enter the information manually. This may also enable the
service provider to present the website 116, mobile website 116,
and/or mobile application 107 to the user in a user context that
the user and/or the service provider have predefined.
[0071] FIG. 3 shows an example procedure 300 (e.g., including an
example onboarding process) for inputting and/or utilizing one or
more of the data elements (e.g., the data elements shown above in
Table 1, Table 2, and/or Table 3) to support the above-mentioned
servicing environment options.
[0072] At block 301 one or more data elements (e.g., the data
elements shown above in Table 1, Table 2, and/or Table 3) is
inputted (e.g., by a system administrator) into the wallet
administration tool 112. At block 302, the wallet administration
tool 112 stores the data elements inputted at block 301 in the
wallet database 110.
[0073] At block 303, a setup service account process is launched
via the wallet client 105, for example, when a user selects an
option to add a payment product to the wallet client 105 is
selected.
[0074] The wallet client 105, at block 304, requests the wallet
server 109 to fetch one or more data elements (e.g., the data
elements shown above in Table 1, Table 2, and/or Table 3) from the
wallet database 110. At block 305, the wallet server 109 fetches
from the wallet database 110 the one or more data elements
requested by the wallet client 105 at block 304. At block 306, the
wallet server 109 transmits to the wallet client 105 the one or
more data elements fetched at block 305. At block 307, the wallet
client 105 stores, in the wallet client database 108, the one or
more data elements transmitted by the wallet server 109 at block
306.
[0075] The wallet client 105, at block 308, initiates the SP mobile
application 107 or the mobile website 116. At block 309, the wallet
client 105 retrieves the data stored at block 307 in the wallet
client database 108.
[0076] At block 310, the wallet client 105 makes preference
determinations based on the data retrieved at block 309. For
instance, the wallet client 105 may determine whether the data
retrieved at block 309 includes preference data indicating a
preference for launching the SP mobile application 107 or the
mobile website 116. If, the wallet client 105 determines at block
310 that the preference data indicates a preference for launching
the mobile SP mobile application 107, then the wallet client 105
launches the SP mobile application 107 at block 311. If, on the
other hand, the wallet client 105 determines at block 310 that the
preference data indicates a preference for launching the SP mobile
website 116, then the wallet client 105 launches the SP mobile
website 116 at block 311. If the wallet client 105 determines at
block 310 that the data retrieved at block 309 does not include any
preference data (or that the SP mobile application 107 is not
installed on the wallet client 105), then the wallet client 105
launches the mobile application store 104 at block 312.
A. Interfaces Used for SP Servicing Environment
[0077] Having described an example procedure for inputting data
elements to support servicing environment options, reference will
now be made to FIGS. 3 through 6 to describe example interfaces
that may be employed, in accordance with various example
embodiments herein, to provide such servicing environment
options.
1. SP System Interface
[0078] FIG. 4 shows a representative interface 400 for exchanging
data between the wallet client 105, the wallet server 109, the ESB
113, and the SP system 114, in accordance with various example
embodiments herein. Three exemplary data flows 401, 402, and 403
shown in FIG. 4 demonstrate ways in which the wallet client 105,
the wallet server 109, the ESB 113, and the SP system 114 may
communicate data such as messages, requests, and/or responses via
the interface 400. In the data flow 401, the service provider
system 114 transmits a message to the wallet client 105 by way of
the ESB 113 and the wallet server 109.
[0079] In the data flow 402, the wallet client 105 transmits a
request to the service provider system 114 by way of the wallet
server 109 and the ESB 113. In reply, the service provider system
114 transmits a response to the wallet client 105 by way of the ESB
113 and the wallet server 109.
[0080] In the data flow 403, the service provider system 114
transmits a request to the wallet server 109 by way of the ESB 113.
In reply, the wallet server 109 transmits a response to the service
provider system 114 by way of the ESB 113. In one example
embodiment, the request is a request to update a state of
contactless services tracked and stored by the wallet server 109.
In another example embodiment, the request is a query of the state
of one or more of the wallet clients 105 tracked and stored by the
wallet server 109. The wallet server 109 may also communicate data
from these messages to one or more of the wallet clients 105, in
accordance with some example aspects herein.
2. SP Mobile Website Interface
[0081] FIG. 5 shows a representative interface 500 for exchanging
data between the wallet client 105, the mobile device operating
system 102, the mobile device web browser 103, and the SP website
114, in accordance with various example embodiments herein. In one
exemplary embodiment, data is communicated via the interface 500 to
enable the wallet client 105 to invoke the mobile device web
browser 103 and to provide a URL to the web browser 103 directing
the web browser 103 to load and present one or more SP webpages via
the mobile device 101.
[0082] Two exemplary data flows 501 and 502 are shown in FIG. 5 to
demonstrate ways in which the wallet client 105, the mobile device
operating system 102, the mobile device web browser 103, and the SP
website 114 may communicate data such as URLs and/or webpages via
the interface 500. In the data flow 501, the wallet client 105
transmits a URL to the SP website 114 by way of the mobile device
operating system 102 and the mobile device web browser 103. As
described above in the context of FIG. 3, this URL may be stored in
the wallet client database 108 and/or in the wallet database 110.
In reply, the SP website 114 transmits a webpage (e.g., a website
corresponding to the URL transmitted by the wallet client 105) to
the mobile device web browser 103.
[0083] In the data flow 502, the SP website 114 transmits a webpage
to the mobile device web browser 103, which, in turn, transmits a
URL (e.g., a URL corresponding to the webpage transmitted by the SP
website 114) to the wallet client 105 by way of the mobile device
operating system 102. In one example embodiment, this URL directing
the web browser 103 to load and display a webpage from the SP
mobile website 114 is delivered to the wallet client 102 via the
interface 400 (FIG. 4) and is stored in the wallet client database
108. In another example embodiment, the interface 500 defines a set
of parameters that the wallet client 105 may embed in the URL to be
passed by the web browser 103 to the SP mobile website 114.
[0084] In another example aspect, the wallet client 105 registers a
predefined URL format with the mobile device operating system 102,
so that any request made using the predefined URL format causes the
mobile device operating system 102 to invoke the wallet client 105.
The wallet client 105 also may register with the mobile device
operating system 102 predefined parameters that may be embedded in
the URL. Upon receiving the URL, the wallet client 105 interprets
any predefined parameters embedded therein. In another example
embodiment, the SP mobile website 114 includes the URL in a link on
a webpage that the SP mobile website 114 delivers to the mobile
device 101. In this manner, when a user selects the link, the
mobile device operating system 102 switches contexts from a context
of the web browser 103 to a context of the wallet client 105, and
delivers the URL to the wallet client 105.
3. SP Mobile Application Interface
[0085] FIG. 6 shows a representative interface 600 for exchanging
data between the wallet client 105, the mobile device operating
system 102, and the service provider mobile application 107, in
accordance with various example embodiments herein. In one
exemplary embodiment, data is communicated via the interface 600 to
(1) enable the wallet client 105 to invoke the SP mobile
application 107, if the SP mobile application 107 has been
installed on the wallet client 105; and/or (2) to enable the mobile
device operating system 102 to switch between a context of the
wallet client 105 and a context of the SP mobile application
107.
[0086] Two exemplary data flows 601 and 602 are shown in FIG. 6 to
demonstrate ways in which the wallet client 105, the mobile device
operating system 102, and the SP mobile application 107 may
communicate data such as URLs via the interface 600. In the data
flow 601, the wallet client 105 transmits a URL (e.g., a URL of the
wallet client 105) to the SP mobile application 107 by way of the
mobile device operating system 102. In the flow 602, the SP mobile
application 107 transmits a URL (e.g., a URL of the SP mobile
application 107) to the wallet client 105 by way of the mobile
device operating system 102. As described above in the context of
FIG. 3, the URL(s) transmitted in the flow 601 and/or the flow 602
may be stored in the wallet client database 108 and/or in the
wallet database 110.
[0087] In one example embodiment, the SP mobile application 107
registers a predefined URL format (a format of the URL of the SP
mobile application 107) with the mobile device operating system
102, so that any request made using the predefined URL format
causes the mobile device operating system 102 to invoke the SP
mobile application 107. The SP system 114 provides the predefined
URL format to the wallet client 102 via the interface 400 described
above in the context of FIG. 4, in one example.
[0088] The SP mobile application 107 may also register with the
mobile device operating system 102 predefined parameters that the
wallet client 105 may embed in the URL of the SP mobile application
107. Upon receiving the URL of the SP mobile application 107 from
the wallet client 105 (by way of the mobile device operating system
102), the SP mobile application 107 interprets any predefined
parameters embedded therein. In another example embodiment, the
mobile device 101 displays a link corresponding to the URL of the
SP mobile application 107. When a user selects the link, the mobile
device operating system 102 switches contexts from a context of the
wallet client 105 to a context of the SP mobile application
107.
[0089] In another example embodiment, the wallet client 105
registers a predefined URL format (e.g., a format of a URL of the
wallet client 105) with the mobile device operating system 102, so
that any request made using the predefined URL format causes the
mobile device operating system 102 to invoke the wallet client
105.
[0090] The wallet client 102 may also register with the mobile
device operating system 102 predefined parameters that the SP
mobile application 107 may embed in the URL of the wallet client
105. Upon receiving the URL of the wallet client 105 from the SP
mobile application 105, the wallet client 105 interprets any
predefined parameters embedded therein. In another example
embodiment, the mobile device 101 displays a link corresponding to
the URL of the wallet client 105. When a user selects the link, the
mobile device operating system 102 switches contexts from a context
of the SP mobile application 107 to a context of the wallet client
105, and delivers the URL of the wallet client 105 to the wallet
client 105.
4. Application Store Interface
[0091] FIG. 7 shows a representative interface 700 for exchanging
data between the wallet client 105, the mobile device operating
system 102, and the mobile application store 104, in accordance
with various example embodiments herein. In one exemplary
embodiment, if the SP mobile application 104 has not yet been
installed on the mobile device 101, then data is communicated via
the interface 700 to enable the wallet client 102 to invoke the
mobile application store 104 provided by the mobile device
operating system 102 and to download and/or install the SP mobile
application 104 therefrom.
[0092] An exemplary data flow 701 is shown in FIG. 7 to demonstrate
a way in which the wallet client 105, the mobile device operating
system 102, and the mobile device application store 104 may
communicate data such as an SP mobile application identifier via
the interface 600. In the data flow 601, the wallet client 105
transmits an SP mobile application identifier (e.g., an identifier
corresponding to the SP mobile application 107) to the mobile
application store 104 by way of the mobile device operating system
102. In one example, the SP system 114 transmits the SP mobile
application identifier to the wallet client 102 via the interface
400 described above (FIG. 4), to enable the wallet client to invoke
the mobile application store 104.
5. SP System-to-Mobile Website Interface and SP System-to-SP
Application Interface
[0093] In some example embodiments herein, the service provider(s)
systems 114 implement proprietary interfaces for communicating data
between the SP systems 114 and the SP mobile website(s) (not shown
in FIGS. 1 through 6) and/or SP mobile applications 107. The
interfaces 400, 500, 600, and 700 may be used together in
conjunction with the proprietary interfaces implemented by service
provider systems 114 to perform complex operations. For example,
the wallet client 105 may provide a parameter to the SP mobile
website via the interface 500 (FIG. 5), and the parameter can be
passed to the SP system 114 and used by the SP system 114 to query
the wallet server 109 via the interface 400 (FIG. 4) to return
additional data about the wallet client 105. The SP system 114 may
return this additional data to the SP mobile website to allow it to
generate a webpage that relates to the specific wallet client 105
that initiated the process.
B. Payment Product Functions/Use Cases supported by SP Servicing
Environment
[0094] Having described example interfaces that may be employed to
provide servicing environment options by way of the wallet client
105, reference will now be made to FIG. 8 to describe example
payment product functions or use cases supported by the SP
servicing environment.
[0095] As shown in FIG. 8, example use cases or payment product
functions supported by the SP servicing environment include the
following: [0096] (1) Creating a session (801); [0097] (2) Adding a
payment product (e.g., a card) to the wallet client 105 (802);
[0098] (3) Activating a payment product on the wallet client 105
(803); [0099] (4) Obtaining/presenting card details via the wallet
client 105 (804); [0100] (5) Upgrading a general purpose reloadable
(GPR) payment product on the wallet client 105 (805); [0101] (6)
Adding funds to a payment product (806); and [0102] (7) Calling
back to the wallet client 105 (807).
C. SP Servicing Environment Lifecycle
[0103] Having described example use cases or payment product
functions supported by the SP servicing environment, an exemplary
SP servicing environment lifecycle will now be described. In one
example embodiment, the SP servicing environment lifecycle proceeds
according to the following steps: (1) authentication; (2) session
establishment; (3) invocation of the SP servicing environment by
the wallet client 105 (e.g., to execute one or more of the payment
product functions described above in connection with FIG. 8); and
(4) callback to the wallet client 105.
1. Authentication
[0104] Having described example use cases or payment product
functions supported by the SP servicing environment, exemplary
procedures will now be described for authenticating a user via the
wallet client 105 to provide the SP servicing environment.
[0105] In one example embodiment, a user can be authenticated by
using one of two authentication procedures, and each of a plurality
of service providers may select and/or configure the authentication
procedures to be used for their customers, for example, based on
the platforms (such as the operating systems 102) of the mobile
devices 101 of the customers.
[0106] In a first authentication procedure, no session information
is created or shared among the wallet client 105, the wallet server
109, the ESB 113, the wallet administration tool 112, and/or the
wallet database 110. The wallet client 105 statically signs
servicing URLs (i.e., URLs used for providing SP services via the
wallet client 105) and provides a context to the SP system 114. The
SP system 114 authenticates the user within an SP servicing
environment.
[0107] In a second authentication procedure, referred to as a
single-sign-on (SSO) authentication procedure, for each servicing
request, a session key is created between the SP system 114 and one
or more of the wallet client 105, the wallet server 109, the ESB
113, the wallet administration tool 112, and/or the wallet database
110. A session handle is provided by the SP system 114 to link the
servicing request to a particular wallet client 105. The wallet
client 105 statically signs servicing URLs and transmits an
authenticated and secure context to the SP system 114. The SP
system 114 manages the duration of the session.
[0108] In one example embodiment, during an onboarding process each
of the service providers associated with the service provider
systems 114 provide, to the wallet server 109 and/or the ESB 113,
authentication configuration data, such as one or more base URLs,
authentication procedures, and/or URL signatures, for each handset
platform type (e.g., for each type of operating system 102). The
base URLs are signed and stored, for example, in the wallet
database 110. Table 4 shows exemplary authentication configuration
data (e.g., URLs, authentication procedures, and/or URL signatures)
that service providers may provide during an onboarding
process.
TABLE-US-00004 TABLE 4 Mobile Device Authenti- Service Operating
cation URL Provider System Base URL Procedure Signature SP 1 OS 1
https://www.SP SSO a0bc1def2a3a4b 1.com/mobilew 5b6cc7dd8ee9ff
allet/OS1 a0bc1def2a3a4b 5b6cc7dd8ee9ff a0bc1def SP 1 OS 2
https://www.SP SSO c34d45e56f7a6b 1.com/mobilew 78c3cd48d5446
allet/OS2 e4e323fff4f5fa6 a34b2b54c569c d4d3aa6c5 SP 2 OS 1
https://www.SP No 9adafcd3dbd7ca 2.com/mobilew Authenti-
54ecbea6cb58ca allet/OS1 cation 3fb8365a839ff2 7a463a829a473
9a36ab7fc SP 2 OS 2 https://www.SP No 7ffcfabb3fcb6a3 2.com/
Authenti- 8a54a6b7aa38ca mobilewallet/O cation c37593bb6d2d5 S2
e6ee284639464 a92a6fabf
[0109] When invoked, the wallet client 105 validates the URL
signature and creates a request based on the base URL and a context
related to the requested action (for instance, whether the
requested action is a request for card details, a GPR upgrade,
and/or another function supported by the wallet client 105). The
wallet client 105 adds parameters to the request based on the
authentication procedure configured by the service provider (e.g.,
no authentication or an SSO authentication procedure). The use of
URL signatures and URL validation by the wallet provides security
by ensuring that the URL provided by the service provider during
the onboarding process is invoked, unmodified.
2. Session Establishment
[0110] Having described exemplary procedures for authenticating a
user via the wallet client 105, an exemplary procedure for
establishing a session between the wallet client 105 and the SP
system 114 using the SSO authentication procedure will now be
described, with reference to FIG. 9. Establishing a session in the
following manner provides security for the wallet client 105 and
the SP system 114 during interactions that occur over untrusted
networks (e.g., the communications network 115 and/or the mobile
networks 111). In particular, the establishment of a session
between the wallet client 105 and the SP system 114 provides a
basis for trust in subsequent interactions between the wallet
client 105 and the SP system 114. It establishes the identity of
the wallet client 105 and establishes shared secrets that may be
required to secure privacy, identity, and/or integrity of
subsequent communications.
[0111] In one example embodiment, prior to step 901, (1) the wallet
client 105 is in an authenticated state (e.g., by having executed
one of the authentication procedures described above), (2) the
wallet client 105 is synchronized with the wallet server 109, and
(3) a secure communication channel has been established between the
wallet server 109 and the SP system 114.
[0112] At step 901, when a user selects a payment product
associated with the service provider system 114, the wallet client
105 requests that a session be established. This allows session
keys to be immediately available when the user selects a specific
function such as launching the SP mobile website 116 or adding
funds to the selected payment product.
[0113] At step 902, the wallet client 105 generates two
cryptographically strong nonces (e.g., nonce A and nonce B), which
are arbitrary and/or pseudorandom numbers each used only once in a
communication. In one example embodiment, the wallet client 105
uses an API for generating a pseudorandom number to generate a 32
bit nonce, as shown in the following example code segment:
TABLE-US-00005 Nonce :=SecureRandom( ):32B
[0114] At step 903, the wallet client 105 transmits a request for
session establishment (e.g., in connection with a request to
implement a function such as the functions/use cases described
above in the context of FIG. 8) to the wallet server 109. In one
example embodiment, the request for session establishment includes
(1) the nonces generated at step 902, (2) a cryptographic ticket
scheme, (3) a wallet identifier corresponding to the wallet client
105, (4) a mobile device number corresponding to the mobile device
101, (5) a service provider identifier, and/or (6) a timestamp
indicating when the wallet server 109 receives the request. The
wallet client 105 and the wallet server 109 set up and validate the
cryptographic ticket scheme based on secret information stored
within the secure element 106. The wallet client 105 making the
request for session establishment can be identified based on the
cryptographic ticket scheme and the wallet identifier.
[0115] In one example embodiment, the wallet client 105 generates
and sends the nonces to the SP system 114 through secured
communication channels. For improved security, the session secrets
(e.g., the encryption key and the signing key) that are shared
between the wallet client 105 and the SP system 114 to encrypt and
secure URLs are not sent in any message payloads. In this way, an
attacker must defeat network and transport security and observe the
first request of the session initialization workflow in order to
generate valid session credentials. These secrets are protected by
the security of the existing wallet client 105 to wallet server 109
secured communication channel and the VPN (e.g., 115) that exists
between the ESB 113 and the SP system 114. This scheme does not
require transmission of user-identifying information between the
wallet client 105 and the SP system 114, thus reducing the exposure
of the mobile device number (MDN) and other user information to a
possible network attack.
[0116] At step 904, the wallet server 109 validates the request
received at step 903 and, if the validation is successful, forwards
the request to the SP system 114 over a secure VPN channel, for
example, by way of the ESB 113 and the communications network 115.
In one example embodiment, the request for a new session
transmitted at step 904 includes (1) the wallet identifier
corresponding to the wallet client 105; (2) handset information
about the mobile device 101 and/or its components (e.g., a handset
identifier, such as an international mobile station equipment
identity (IMEI), a mobile equipment identifier (MEID), and/or a
media access control (MAC) address); (3) a mobile device number
corresponding to the mobile device 101; (4) the nonces generated at
step 902; and/or (5) a wallet server timestamp generated by the
wallet server 109.
[0117] In one example embodiment, the wallet identifier, mobile
device number, and handset information included in the request
transmitted by the wallet server 109 at step 904 enable the service
provider corresponding to the SP system 114 to map a particular
consumer to their SP account(s). The wallet server time stamp
allows for policy compliant session timeout and similar workflows.
The following is an exemplary structure of the request transmitted
by the wallet server 109 at step 904:
TABLE-US-00006 Message := <Nonce (encrypting key)> ||
<Nonce (signing key)> || <Wallet ID> || <MDN> ||
<IMEI/MEID> || <CIN> || <optional PRN> ||
<Time stamp>
[0118] At step 905, the SP system 114 executes one or more
functions for establishing a session, based on the information
received in the request at step 904. For instance, the SP system
114 may (1) determine which SP services are available based on the
wallet identifier received from the wallet server 109 at step 904,
(2) determine whether any sessions are already established for the
wallet identifier, (3) set a session duration or window, and/or (4)
derive keys from the nonces received at step 904.
[0119] In one example embodiment, the SP system 114 computes a
signing key based on nonce A and computes an encryption key based
on nonce B. As will be described below in the context of step 908,
the wallet client 105 also computes the signing key and the
encryption key, in the same manner as the SP system 114. By using
the same key derivation procedure, the SP system 114 and the wallet
client 105 create interoperable encryption and signing keys. The
encryption key and the signing key are used to protect the privacy
and integrity of data communicated throughout the duration of the
session. In one example embodiment, the SP system 114 generates the
encryption key and the signing key by executing a key derivation
function known as password-based key derivation function 2
(PBKDF2), using the nonces as input. The following is an example
segment of pseudocode that the SP system 114 may employ to generate
the encryption key and/or the signing key based on the nonces.
TABLE-US-00007 AES-256(key) := PBKDF2(HMAC-SHA-256, input, c=10000,
dK=256b) HMAC-SHA-256(key) := PBKDF2(HMAC-SHA-256, input, c=10000,
dK=256b) Input:= <split the nonce into two equal halves, passing
the first half as `salt` and the second half as `password` to
PBKDF2
[0120] In one example embodiment, for improved security, the wallet
client 105 and the SP system 114 are not permitted to use a single
key (e.g., from a single nonce) for the purpose of both signing and
encryption. Instead, the SP system 114 uses one nonce to generate
the signing key and another nonce to generate the encryption
key.
[0121] At step 906, the SP system 114 transmits a session result
response to the wallet server 109 by way of the communication
network 115 (and optionally the ESB 113). In one example
embodiment, the session result response does not include any
end-user information, device information, or service
provider-specific information. Because the SP system 114 and the
wallet client 105 compute the encryption key and the signing key in
a distributed manner (i.e., separately), neither the encryption key
nor the signing key is transmitted between the SP system 114 and
the wallet client 105, thus reducing exposure to the sensitive
encryption key and signing key. In another example embodiment
herein, an identifier from the SP system 114 is included in the
session result response to enable the encrypted and/or signed URL
invocation to be matched to the particular wallet client 105 that
invoked the URL.
[0122] In one example embodiment, SP system 114 forms the session
result response according to a predetermined structure that, if the
session result response indicates that the session is successfully
established, includes a data element created based on a shared
static value encrypted and signed by the derived encryption key and
signing key, respectively. This enables the wallet client 105 to
verify that the distributed encryption and signing key computation,
cipher selection, and configuration occurred properly. The
following is an example structure of the session result
response:
TABLE-US-00008 Message := <Response Code Structure> ||
Signed/Encrypted<Value = 0x1122334455667788>
[0123] The wallet server 109, at step 907, transmits the session
result response to the wallet client 105, and the wallet client 105
executes, at step 908, one or more functions for establishing a
session, based on the information received in the session result
response at step 907. For instance, the wallet client 105 may (1)
check the session result response code and/or derive a signing key
and an encryption key based on the nonces generated at step 902. In
one example embodiment herein, the wallet client 105 computes a
signing key based on nonce A and computes an encryption key based
on nonce B, in a manner similar to that described above in
connection with step 905.
[0124] In one example, if the SP system 114 is not available to
fulfill the session establishment requested at step 903 and/or
returns an error in the session result response, the wallet client
105 indicates to the user that the requested payment product
function (e.g., in connection with a request to implement a
function such as the functions/use cases described above in the
context of FIG. 8) is unavailable and does not invoke the URL of
the SP system 114.
[0125] In accordance with another example embodiment herein, the
wallet client 105 invalidates the session keys (i.e., the
encryption key and the signing key) when the user is no longer
authenticated or PINed into the wallet client 105. For example, the
wallet client 105 may become automatically locked after the session
has been established for a predetermined time duration (e.g.,
thirty minutes), regardless of user activity. In this case, the SP
system 114 may maintain the duration of the session keys for a
period no longer than the predetermined time duration after which
the wallet client 105 becomes locked.
[0126] In another example embodiment, the SP system 114 invalidates
the session keys and establishes a new session when the wallet
client 105, the wallet server 109, and/or the ESB 113 initiate a
new session request.
3. SP Servicing Environment Invocation by Wallet Client
[0127] Reference will now be made to FIG. 10 to describe an
exemplary procedure for invoking a SP servicing environment by the
wallet client 105, for example, after a session has been
established in the manner described above in connection with FIG.
9.
[0128] In one example embodiment, in order to invoke the SP
servicing environment, the wallet client 105 employs only a single
identifier (i.e., the wallet identifier) and the URL
encryption/signing scheme described above in the context of FIG. 9.
For requests for to implement functions, other than adding a
payment product, that involve a particular payment account, the
wallet client 105 also uses an additional identifier, a payment
product reference number (PRN), which uniquely identifies a
particular payment product. In this manner, service providers are
provided with robust protection during interactions over network
topologies that incorporate third party systems.
[0129] After the SP system 114 and the wallet client 105 have
agreed upon session secrets (e.g., the encryption key and the
signing key described above in connection with FIG. 9), the wallet
client 105 can successfully launch functions to be serviced by the
SP system 114 (e.g., the payment product function(s) described
above in the context of FIG. 8). For purposes of convenience, the
procedure 1100 will be described in the context of a request to
access the SP mobile website 116, although this should not be
construed as limiting. Requests to execute payment product
functions other than accessing the SP mobile website 116 (e.g., any
of the payment product functions described above in the context of
FIG. 8) are also contemplated and are within the scope of the
example embodiments herein.
[0130] In one example embodiment, prior to step 1001, the wallet
client 105 is in an authenticated state (e.g., by having executed
one of the authentication procedures described above), and a secure
communication channel has been established between the wallet
server 109 and the SP system 114.
[0131] At step 1001, in response to a user requesting to launch the
SP mobile website 116 (e.g., by selecting a button via the mobile
device 101), the wallet client 105 retrieves an SP servicing
environment request base URL from the wallet client database 108
and validates the integrity of the base URL against a URL signature
also stored in the wallet client database 108. The wallet client
105 generates an SP servicing environment request URL using a
request action (e.g., a unique identifier that can be used to
generate a deep link into one or more specific functions in the SP
servicing environment) and the wallet identifier, and encrypts any
sensitive values in the URL. The wallet client 105 then signs the
SP servicing environment request URL to enable the wallet server
109, the ESB 113, and/or the SP system 114 to detect any tampering
of the URL that may occur in transit.
[0132] In one example embodiment, the service provider supports the
SP servicing environment by providing commands, in the form of
URLs, for executing SP functions (e.g., presenting payment product
details, adding a payment product to the wallet client 105, etc.)
into the wallet server 109 via the controlled secure interface, the
wallet administration tool 112 (FIG. 1) described above. The wallet
server 109 pushes these command URLs to the wallet client database
108 as part of the secured procedure for synchronizing/updating the
wallet client 105 and the wallet server 109.
[0133] The following is an exemplary format of the SP servicing
environment request URL:
TABLE-US-00009 URL := <protocol> <url base> `/`
<action> <parameter block>
where:
TABLE-US-00010 protocol := `https` url base :=
`https://www.ic_issuer.com/isis/android/` action := `card_details`
parameter block := ?<parameter>+ parameter :=
<name>=<value> |
<parameter>&<parameter> name | value :=
<text>
[0134] In one example embodiment, the wallet client 105 constructs
the request URL by executing a request construction algorithm
including the following steps: [0135] (1) Formatting the request as
a URL template (such as, for example, a parameterized SQL query),
complete with parameter delimiters; [0136] (2) Encoding URL
parameters; [0137] (3) Verifying each parameter used at most once;
[0138] (4) Placing parameters in a predetermined order (e.g.,
wallet identifier and an optional PRN); [0139] (5) Prepending a
request-specific nonce to the parameter block; [0140] (6)
Encrypting the parameter block, including the nonce; [0141] (7)
Replacing the parameter block with the nonce and cipher text;
[0142] (8) Signing the entire request; and [0143] (9) Appending a
signature to the request.
[0144] The above request construction algorithm produces, in one
example, a message having the following format:
TABLE-US-00011 URL := <protocol> <url base> `/`
<action> <protected block> protected block :=
<signed params> `:` <signature> signed params :=
<nonce> `:` <encrypted block> nonce := `?nonce=`
<PRNG> `&` PRNG := Cryptographically-strong PRNG: 32B
output encrypted block := <nonce> ENC(<parameter
block>) ENC := AES-256(ISR-WC-SHARED-SECRET-KEY1, <parameter
block> parameter block := <nonce> `walletID=`<value>
[<parameter>+] parameter := `&`<name>=<value>
| <parameter>+ name | value := <text> signature :=
HMAC-SHA2-256(ISR-WC-SHARED-KEY2, <signed>) signed :=
<protocol> <url base> `/` <action> <signed
params>
[0145] In one example embodiment, the URL is constructed by using
two keys--an encryption key and a signing key, which, in one
example, are generated as described above in connection with step
905 (FIG. 9) and/or the SSO authentication procedure.
[0146] In one example embodiment, if multiple interactions with the
SP system 114 are required after the initial SP servicing
environment is invoked, the wallet client 105 continues to
construct and sign SP servicing environment request URLs using the
agreed-upon encryption and signing keys until either the wallet
client 105 or the SP system 114 invalidates the session. When the
session terminates, the sequence of operations restarts with the
establishment of a new session with the SP system 114, for example,
in the manner described above in connection with FIG. 9.
[0147] At step 1002, the wallet client 105 invokes the mobile
device web browser 103 and passes the encoded URL as the
destination URL.
[0148] At step 1003, the wallet client 105 transmits to the SP
system 114 a request to launch the SP mobile website 116. In one
example embodiment, the request includes a source URL including
data of the encoded URL generated at step 1001.
[0149] In some example embodiments, the wallet client 105 encrypts
an entire parameter block of the request transmitted at step 1003.
Thus, based on the plaintext of the request alone, the SP system
114 is unable to match the particular wallet client 105 to the
encryption key and the signing key. The SP system 114, therefore,
stores and maintains mapping information that maps each session
initiated by a particular wallet client 105 to corresponding
encryption and signing keys.
[0150] At step 1004, the SP system 114 executes one or more web
application controls and/or filters. In addition, the SP system 114
drops the nonce reply and the unsigned requests from the request
received at step 1003. In one example embodiment, the SP system 114
detects a type of user agent implemented by the mobile web browser
103.
[0151] At step 1005, the SP system 114 breaks down the encoded URL
received as part of the request at step 1003. For instance, the SP
system 114 may break down the encoded URL by separating the URL
into (1) a URL protocol and base, (2) a browser action, (3) a
nonce, (4) an encrypted block, and/or (5) a signature.
[0152] At step 1006, the SP system 114 verifies the signature with
which the wallet client 105 signed the URL at step 1001. In one
example embodiment, the SP system 114 verifies the signature by (1)
detaching the signature from the request, (2) re-computing and
verifying that the re-computed signature matches the detached
signature, (3) removing the nonce from the encrypted parameter
block, (4) decrypting the parameter block, (5) verifying the
detached nonce with a first parameter in decrypted plaintext, (6)
verifying that no more than one instance of each parameter exists,
(7) if necessary, decoding parameters and re-encoding them for a
target, and (8) dispatching the request. The SP system 114 compares
the signature received as part of the request at step 1003 with the
signature generated at step 1006 to determine whether they
match.
[0153] At step 1007, if the SP system 114 determines that the
signature received as part of the request at step 1003 matches the
signature generated at step 1006, then the SP system 114 decrypts
the encrypted block, for example, by (1) fetching an encryption
key, (2) removing a nonce from the encryption block, (3) decrypting
the parameter block (e.g., including parameters such as a wallet
identifier and/or a payment product identifier) by using the
encryption key, and (4) verifying that the plaintext nonce matches
the deciphered nonce.
[0154] At optional step 1008, the SP system 114 transmits to the
wallet server 109 and/or the ESB 113 a request for a status of a
wallet identified included in the parameter block decrypted at step
1007. The wallet server 109 and/or the ESB 113 retrieve a status of
the wallet identifier from the wallet database 110 and, at step
1009, transmit the status of the wallet identifier to the SP system
114.
[0155] At step 1010, the SP system 114 acts upon the URL request
based on the parameters (e.g., the wallet identifier and/or a
payment product identifier) decrypted at step 1007. At step 1011,
the SP system 114 transmits to the wallet client 105 a web server
response by way of the wallet server 109 and/or the ESB 113.
[0156] In one example embodiment, if the SP system 114 fails to
resolve the URL or the SP system 114 is unavailable, the mobile web
browser 103 presents to the user an HTTP error message and/or a
platform-dependent message if the URL does not launch.
[0157] In one example embodiment, if the SP system 114 fails to
verify the signature at step 1006, or determines, after decoding
the message, that the message includes multiple instances of the
same parameter, or that parameters include illegal and/or
suspicious characters, then it is assumed that the message has been
tampered with. In this case, the SP system 114 executes an
alternative error handling procedure and provides an error message
to the user within the mobile website 116 and/or the mobile
application 107.
4. Callback to Wallet Client
[0158] The SP system 114, after completing an authenticated
servicing request, invokes a callback procedure to provide the
wallet client 105 with a result of the servicing request, such as,
for instance, success or failure.
[0159] In one example embodiment, the callback procedure described
herein is similar to the procedure 1100 (FIG. 10) for invoking the
SP servicing environment by the wallet client 105. The callback
procedure utilizes the same encryption and signing keys as those
used in procedure 1100.
[0160] In one example, if the user's authentication with the wallet
client 105 has not timed out, then the callback procedure results
in the user being returned to the page in the wallet client 105
from which the SP servicing environment was invoked. If the user's
authentication has timed out, then the callback procedure causes
the mobile device 101 to present the user with a PIN entry page of
the wallet client 105, where the user is requested to enter a
personal identification number (PIN) in order to obtain access to
the wallet client 105.
[0161] After the SP system 114 launches the callback procedure, the
SP system 114 generates a wallet request URL using a result code,
encrypting any sensitive data therein. The SP system 114 signs the
generated wallet request URL to enable the wallet client 105, the
wallet server 109, and/or the ESB 113 to detect any tampering of
the request that may have occurred in transit.
[0162] The following is an exemplary format of the wallet request
URL:
TABLE-US-00012 URL := <protocol> <url base> `/`
<action> <parameter block>
where:
TABLE-US-00013 protocol := `Isis` url base :=
`Isis://MobileWallet/` action := `card_details` parameter block :=
?<parameter>+ parameter := <name>=<value> |
<parameter>&<parameter> name | value :=
<text>
[0163] In one example embodiment, the SP system 114 constructs the
wallet request URL by executing a request construction algorithm
including the following steps: [0164] (1) Formatting the request as
a URL template (such as, for example, a parameterized SQL query),
complete with parameter delimiters; [0165] (2) Encoding URL
parameters; [0166] (3) Verifying each parameter used at most once;
[0167] (4) Placing parameters in a predetermined order (e.g.,
wallet identifier and an optional PRN); [0168] (5) Prepending a
request-specific nonce to the parameter block; [0169] (6)
Encrypting the parameter block, including the nonce; [0170] (7)
Replacing the parameter block with the nonce and cipher text;
[0171] (8) Signing the entire request; and [0172] (9) Appending a
signature to the request.
[0173] The above request construction algorithm produces, in one
example, a message having the following format:
TABLE-US-00014 URL := <protocol> <url base> `/`
<action> <protected block> protected block :=
<signed params> `:` <signature> signed params :=
<nonce> `:` <encrypted block> nonce := `?nonce=`
<PRNG> `&` PRNG := Cryptographically-strong PRNG: 32B
output encrypted block := <nonce> ENC(<parameter
block>) ENC := AES-256(ISR-WC-SHARED-SECRET-KEY1, <parameter
block> parameter block := <nonce> `walletID=`<value>
[<parameter>+] parameter := `&`<name>=<value>
| <parameter>+ name | value := <text> signature :=
HMAC-SHA2-256(ISR-WC-SHARED-KEY2, <signed>) signed :=
<protocol> <url base> `/` <action> <signed
params>
[0174] The wallet client 105 verifies the signature with which the
SP system 114 signed the URL. In one example embodiment, the wallet
client 105 verifies the signature by (1) detaching the signature
from the request, (2) re-computing and verifying that the
re-computed signature matches the detached signature, (3) removing
the nonce from the encrypted parameter block, (4) decrypting the
parameter block, (5) verifying the detached nonce with a first
parameter in decrypted plaintext, (6) verifying that no more than
one instance of each parameter exists, (7) if necessary, decoding
parameters and re-encoding them for a target, and (8) dispatching
the request. The wallet client 105 compares the signature received
as part of the request with the signature that the wallet client
105 generated to determine whether they match.
[0175] If the wallet client 105 fails to verify the signature with
which the SP system 114 signed the URL, then the wallet client 105
causes the mobile device 101 to display an error message to the
user and to enter an unauthenticated state.
[0176] If, when the URL launch is attempted, the URL fails to
resolve, then the mobile device 101 presents to the user a
platform-dependent error message indicating that the URL failed to
resolve. If signature and/or decryption verification fails, the
wallet client 105 presents to the user via the mobile device 101 a
page requesting that the user enter a PIN.
D. Providing Custom SP Notifications/Information via Wallet
Client
[0177] An example procedure for providing custom SP notifications
and/or information via the wallet client 105 (e.g., on a card
details page) will now be described.
1. Custom Notifications Overview
[0178] In one example embodiment, the procedure, through the use of
a service provider structured data model, enables the SP system 114
to cause custom service provider information (e.g., a custom brief
message, interactive menu of offers, and/or the like) to be
displayed to a user via the wallet client 105 (e.g., on a card
details page). In some example embodiments, the SP system 114 is
enabled to present an indicator (such as, for example, a flag on a
front of card page of the wallet client 105) that indicates when
new content is available on a back of the card page of the wallet
client 105. This enables provides service providers to push
notifications and/or other communications to their users in a
targeted, efficient, integrated, and consistent manner.
[0179] A service provider provides a structured data object ("SDO")
describing content to be presented via the wallet client 105 for a
particular payment product, for an individual account of the wallet
client 105. In one example, the content is a JavaScript Object
Notation (JSON) document sent to the wallet server 109 and/or the
ESB 113, and synchronized with the wallet client 105. In another
example, the wallet client 105 requests the content from the SP
system 114.
[0180] The service provider structured data model is a generic
model with a simple description format that enables service
provider-specific information to be presented on the card details
page(s) of the wallet client 105. In some examples, the service
provider-specific information includes one or more interactive
elements (e.g., buttons) that enable the user to select an offer.
The model renders a variety of content in a consistent manner,
while also allowing additional deep links into the SP website 116
and/or the SP mobile application 107 thus enabling the user to
execute and/or launch additional more service provider-specific
functions from the wallet client 105. In addition, by allowing the
SDO to reference additional content by URL, the wallet client 105
and the SP system(s) 114 can communicate directly without having to
interact with the wallet server 109 and/or the ESB 113.
[0181] FIG. 11 shows exemplary pages 1101, 1102, and 1103 that the
wallet client 105 may present, in accordance with some example
embodiments. In particular, the page 1101 is an example of a front
of card page, the page 1102 is an example of a back of card page,
and the page 1103 is an example of a card details page.
[0182] According to one example embodiment, the SDO mentioned above
defines a message structure that the service provider may use to
present a message via the back of card page 1102, and defines a
structure of one or more sections of the card details page 1103
that the service provider may populate with additional
information.
[0183] For instance, in one example embodiment the SP system 114
may cause a flag 1104 to be presented on the front of card page
1101 in connection with a particular payment product, to indicate
that new information is available for that payment product.
[0184] The user may select the flag 1104, for example, by touching
a portion of a touchscreen of the mobile device 101 where the flag
1104 is located, to cause the mobile device 101 to present the back
of card page 1102. The back of card page 1102 displays to the user
a short message 1105 (e.g., defined by the SP system 114) such as
an offer to enroll in a 5% cash back discount program on gasoline
purchases. In some example embodiments, the SP system 114 targets a
particular user, a particular wallet client account, and/or a
particular payment product to provide a suitable targeted
offer.
[0185] The user may select an icon 1106 associated with the message
1105 and/or may select a card details button 1107 to cause the
mobile device 101 to display the card details page 1103 associated
with the message 1105. The card details page displays additional
information 1108 regarding the message 1105 based on additional
data included in the corresponding SDO. The SP system 114 defines,
via the SDO, one or more sections in which to divide the card
details page 1103. In the example card details page 1103, the
sections include (1) a title section 1109, (2) a heading section
1110, (3) a textual body section 1111, (4) a button section 1112,
(5) an image section 1113, and (6) a help section 1116. The SP
system 114 defines, in each section, one or more items to be
displayed. SP system 114 may select the items from multiple user
interface elements (e.g., text, headers, images, icons, buttons,
etc.) and may select to arrange the items in one of multiple layout
options. This provides service providers with the flexibility to
provide to its users custom messages, in formats of its choosing,
by way of the wallet client 105.
2. Front of Card/Flag
[0186] As described above, if new content is available for a
particular user, for a particular payment product, the wallet
client 105 displays a flag 1104 adjacent to an image associated
with the payment product. In one example embodiment, the wallet
client 105 displays the flag 1104 when the payment product comes
into the foreground in a rotatable carousel of payment products in
the wallet client 105. This indicates to the user that a new
message 1105 is available for the user to view by simply launching
the back of card page 1102. The message 1105 presented via the back
of card page 1102 may prompt the user to select the icon 1106 or
the card details button 1107 to cause additional information (e.g.,
the information provided in sections 1109 through 1116 described
above) related to the message 1105 to be displayed via the card
details page 1103.
[0187] The display of the flag 1104 is controlled by a belgian text
property of the SDO. When the belgian text property changes, and is
not empty, the flag 1104 is displayed for that card when the
payment product is in the foreground. In some example embodiments,
the flag 1104 disappears or slides away after a predetermined time
period, and reappears any time the carousel slides that payment
product into focus. If the user flips to the back of card page 1102
the belgian text property for that payment product is marked as
`seen` and the flag 1104 no longer appears. If the content of the
belgian property later changes, the wallet client 105 fetches a new
SDO and the belgian property is again marked `new,` until the user
selects the flag 1104 and views the back of card page 1102.
[0188] In one example embodiment, whether the flag 1104 is
displayed is dependent upon whether the message 1105 on the back of
card page 1102 has changed, not whether content (e.g., the
information provided in sections 1109 through 1116 described above)
on the card details page 1103 has changed. In this way, it is
possible to modify the contents of the card details page 1103,
without causing the wallet client 105 to display a new flag
1104.
3. Back of Card
[0189] The belgian property of the SDO defines a plaintext message
1105 to display on the back of card page 1102 with the icon 1106
(e.g., a bell icon) above it. In some example embodiments, the text
of the message 1105 is provided as a simple, unformatted string
and, for consistency, the same icon is used for each of the
plurality of SP systems 114.
[0190] The text of the message 1105 appears on back of card page
1102, unless the belgian property is empty or not defined, or the
payment product is in a non-active state, such as a blocked state.
For payment products in non-active states such as a blocked state,
instead of the text of the message 1105, a payment product status
message regarding a card status issue is shown on the back of card
page 1102, thus prompting the user to address the card status
issue.
4. Card Details
[0191] In one example embodiment, the wallet client 105 renders on
the card details page 1103 the sections defined in the SDO (e.g.,
the sections 1109 through 1116 described above) and the items
defined in each section, in the order that they appear in the SDO.
The wallet client 105 renders the sections and items after
rendering any default information. If the sections and items are
not included in the SDO, then the wallet client 105 leaves the
corresponding sections of card details page 1103 blank. This is the
fallback behavior for legacy service providers and/or service
providers that do not implement the custom notification
function.
5. Interaction
[0192] In some example embodiments, the back of card page 1102
and/or the card details page 1103 can present interactive user
interface elements, such as, for example, a link or a button that,
when selected, launches a website (e.g., the SP mobile website 116)
or an application (e.g., the SP mobile application 107) based on an
associated URL (e.g., http://www.chase.com/ or
chase://balance).
[0193] In one example, the wallet client 105 attempts to determine
whether the mobile device 101 includes an application that is
registered to handle the particular URL, which may be for an
application or a website. If the wallet client 105 determines that
the mobile device 101 does not include any application that is
registered to handle the URL, then the wallet client 105 attempts
to use an alternative URL, if provided. The following is an example
definition of an interactive user interface element, a
corresponding URL, and a corresponding alternative URL:
TABLE-US-00015 type: "button", url:
"chase://isis/balance?token=abc123", alt_url:
http://m.chase.com/go/isis/balance?token=abc123
[0194] Using the above example, the wallet client 105 determines
whether a protocol handler is registered to handle the protocol
"chase://" (which, if true, would imply that the mobile device 101
includes an application corresponding to the URL). If the wallet
client 105 determines that a protocol handler is registered to
handle the protocol "chase://", the wallet client 105 calls the
URL. If the wallet client 105 determines that no protocol handler
is registered to handle the protocol "chase://", the wallet client
105 calls the alternate URL instead, by invoking the mobile web
browser 103. If no alternate URL is provided in connection with the
user interface element, then the primary URL is called, regardless
of whether it can be handled. In one example, the wallet client 105
launches the application and/or mobile website associated with the
URL as a separate instance, not in a context of the wallet client
105.
[0195] In accordance with some example embodiments, the interactive
user interface elements presented via the back of card page 1102
and/or the card details page 1103 neither contains specific logic,
nor dynamically change the user interface. The SP system 114
responds to the selection of the user interface element by
providing an update to the SDO for the user (e.g., to show
alternate content after the user signs up for a rewards program)
based on other external events.
6. Communication
[0196] FIG. 12 illustrates how certain components of the system 200
(FIG. 2) may communicate to provide custom SP notifications and/or
information via the wallet client 105, in accordance with various
example embodiments herein.
a. SP to Wallet Client
[0197] At step 1201, the SP system 114 pushes an SDO document to
the wallet server 109 by way of the communication network 115 (not
shown in FIG. 12) and the ESB. The SDO document is provided to the
wallet client 105, for example, via the mobile network 111 (not
shown in FIG. 12) as part of a periodic synchronization procedure
that synchronizes the states of the wallet server 109 and the
wallet client 105. Along with the SDO document, the SP system 114
provides (step 1201) a wallet identifier and a card identifier
corresponding to the particular wallet client 105. To provide the
wallet client 105 with updated content, the SP system 114 can push
a new SDO document to the wallet server 109 by way of the ESB 113.
The wallet server 109 provides the updated content to the wallet
client 105 during the synchronization procedure described
above.
b. SP to ESB/Wallet Server
[0198] In one example embodiment, the SP system 114 send an SDO to
multiple users by providing to the wallet server 109 (e.g., by way
of the ESB 113) multiple wallet identifiers with the SDO document.
In another example embodiment, the SP system 114 provides the
wallet server 109 with only a particular type of payment product
(e.g., "Chase Freedom"), which causes the wallet server 109 to
synchronize the SDO document with all of the wallet clients 105
having that particular payment product.
c. Wallet Server to Wallet Client
[0199] As described above, the SDO document is provided to the
wallet clients 105 through the periodic synchronization process
between the wallet server 109 and the wallet clients 105. In some
example embodiments, the wallet server 109 provides an additional
API to synchronize only the SDO, so that interactions with the
content in the user interface can trigger additional requests from
the wallet client 105 to pull the wallet server 109 for possible
updates. For example, scenarios where the wallet client 105 pulls
additional updates from the wallet server 109 include: [0200] (1)
Flipping to the back of card page 1102, [0201] (2) Viewing the card
details page 1103, [0202] (3) Selecting the button 1112 on the card
details page 1103, and [0203] (4) Returning the wallet client 105
to the foreground when on card details page 1103.
7. SDO Document Format
[0204] In some example embodiments, during the onboarding process
described above, a service provider can provide a default document
for all users (e.g., an SDO including contact information of all
payment products associated with the service provider). In another
example, the service provider can provide a default document for
all users of a particular payment product associated with the
service provider (e.g., an SDO including card features to all users
of a particular payment product offered by the service
provider).
[0205] The SDO is defined in the JSON format and is validated by
the wallet server 109 and the wallet client 105. The SP systems 114
provide JSON-formatted SDO objects on a per-product and/or a
per-user basis, for example, via the wallet administration tool
112. Thus, the SP systems 114 can provide content specific to a
user and/or a product.
[0206] If the SP system 114 uses URLs, whether as links to a
website or an application, or as a reference for the wallet client
105 to fetch further structured data, the SP system 114 can pass
context including a user identifier and/or a product identifier in
the URL.
[0207] In one example embodiment, when an SDO document is updated,
the updated SDO document replaces the entire previous SDO document
on the wallet server 109 and the wallet client 105.
[0208] The SDO document defines data and behavior for a particular
payment product. The protocol for receiving updates from the SP
system 114 to the ESB 113, and between the wallet server 109 and
the wallet client 105, includes a wallet identifier and a payment
product identifier enable to the association of the SDO document
with a particular wallet client 105 and payment product.
[0209] The root SDO, in some example aspects, is a JSON object, and
any additional content fetched by the wallet client 105 to augment
the data in the root SDO takes the same JSON format. The wallet
server 109 and/or the wallet client 105 validate the JSON-formatted
SDO document, and the document is not rendered if the document is
determined to be not valid. If only an individual section or item
of the SDO document is determined to be invalid, only that section
or item is not rendered.
a. URL References/Root Document Elements
[0210] Table 5 below shows elements of the root SDO document.
TABLE-US-00016 TABLE 5 Format Property Required/ Default tags Max
name Type Optional value allowed Length Notes belgian String
Optional No 80 version Integer Required No version 1 timestamp Time
Required No Seconds since Unix epoch url URL Optional No cache
Boolean Optional true No sections Array Optional No 6 Array of
section objects
[0211] The root SDO document, as well as individual sections of the
SDO document can define a URL property (as shown in Table 5 below)
that refers to another location for additional data. The service
provider defines the URL property, and, when the URL is launched,
the wallet client 105 fetches additional JSON content for the SDO.
The wallet client 105 caches the content of any response, and this
can be disabled by setting the cache property (shown in Table 5
below) to false.
[0212] The belgian property in Table 5 defines text of the message
1105 that appears on the back of card page 1102 and indicates to
the wallet client 105 when a flag 1104 should appear on the front
of card page 1101. When the value for the belgian property changes
from one SDO to the next, the flag 1104 will be displayed on the
front of card page 1101 to indicate that new information is
available on the back of card page 1102. By changing the contents
of the belgian property, the service provider can cause the wallet
client 105 to notify the user that something on the card details
page 1103 has changed.
[0213] In some example embodiments, the `version` property in Table
5 is required, and represents a version of the SDO document format.
This provides backward compatibility, in that legacy service
providers can ignore properties they are unaware of and/or do not
support, and only process properties that they do support.
[0214] The `timestamp` property in Table 5 represents the time the
SDO document was last updated in seconds since the UNIX epoch.
[0215] The `url` property in Table 5, if provided, represents a
location for fetching an additional JSON SDO document, and is used
to define all properties of the SDO document--other than the
timestamp property, the URL property, and the cache property.
Formatting requirements are the same as the default SDO. If the URL
fails to load or parse, any values defined in the document are
rendered using default values. The default values for the timestamp
property, the url property, and the cache property in the initial
SDO are not overridden by the additional SDO fetched using the URL
property. In some example embodiments, valid values for a URL are
checked against a whitelist of permitted URLs, and URLs that do not
match the whitelist are invalid and ignored.
[0216] The cache property in Table 5 controls the caching of the
content fetched by the URL property. If the cache property is set
to false, any data fetched by the URL property is not cached on the
wallet client 105 and is fetched each time for display on the back
of card page 1102 and the card details page 1103. An inline spinner
should be rendered on the back of card page 1102 and the card
details page 1103 while content is being fetched. If the cache
property is set to true, the document can be cached to the device,
and those values are displayed immediately, but any rendering
triggers the wallet client 105 to check the URL again for an
updated version. If an updated version is available, the wallet
client 105 immediately renders any contents that were modified
during the update.
[0217] The sections property in Table 5 is an array of section
objects. Each of the section objects is either an array of items or
a URL location from which to fetch the array of items. The section
objects are rendered in order. In one example aspect, the URL
property of the root node can be used to define all sections
externally. If undefined, no sections are rendered on the card
details page 1103, and the back of card message 1105 and flag 1104
operate in the manner described above. That is, selecting the icon
1106 or the button 1107 on back of card page causes the wallet
client 105 to launch the card details page 1103.
b. Sections
[0218] Table 6 shows example properties that may be included in
each of the section objects described above in connection with
Table 5. The section objects are required to render any user
interface elements on the card details page 1103. Each section
object appears on the card details page 1103 in the order
represented in the SDO document. Some sections include an item that
is displayed in the corresponding section on the card details page
1103.
TABLE-US-00017 TABLE 6 Format Property Required/ Default tags Max
name Type Optional value allowed Length Notes Label String Required
No 40 Items Array Required No 12 Array of item objects Cache
Boolean Optional true No
[0219] The label property in Table 6 is the text label to apply for
that section. In some example aspects herein, no formatting of the
label property is permitted and the value of the label property
must be non-empty.
[0220] The items property in Table 6 is an array of item objects
(described below), which are rendered in the order defined in the
SDO document. If the items property is a URL rather than an array,
the URL is fetched and a JSON array of the items is displayed. If
there are no items defined in the section object, then no section
header is rendered. The service provider can construct the URL to
call any customer specific item data desired.
[0221] The cache property in Table 6 enables the service provider
to control whether the URL for the items collection is locally
cached (e.g., by the wallet client 105). If the cache property is
set to false, then the URL is not cached in the wallet client 105
and is dynamically fetched each time the card details page 1103 is
rendered. An inline spinner is rendered for each section while its
content is being fetched. If the cache property is set to true,
then the data is cached by the wallet client 105, the contents are
rendered immediately, and the URL is checked for updated content
each time the card details page 1103 is rendered.
c. Items
[0222] The item objects of the item property in Table 6 are
individual user interface elements rendered in a section. In one
example embodiment, there are four item types: (1) text, (2)
button, (3) link, and (4) block, although this example should not
be construed as limiting. Additional item types are contemplated
and are within the scope of the example embodiments herein. Each
item type has a corresponding set of valid properties. For
instance, a headline property may only be valid for a block item
type. In one example embodiment, each item object displays the full
width of the card details page 1103 and the item objects are
rendered in the order defined for the corresponding section. There
are no visual dividers between user interface elements, thus
multiple items can be rendered in sequence for a visual group.
i. Item Type=Text
[0223] Table 7 shows an example item object of the text item type.
A block of text is displayed when the item type is set to the text
item type. In some example aspects herein, the SP system 114 can
optionally format the block of text, but cannot include embedded
links.
TABLE-US-00018 TABLE 7 Property Required/ Default Format tags Max
name Type Optional value allowed Length Text String Required Yes
320
[0224] The text property in Table 7 renders lines of text in a
default color, wrapping as necessary. In one example embodiment,
the text property can include one or more formatting tags
(described below), and does not contain embedded links.
ii. Item Type=Button
[0225] Table 8 shows an example item object of the button item
type, which causes a button to be displayed. The button can
optionally trigger a URL link when selected by a user.
TABLE-US-00019 TABLE 8 Property Required/ Default Format tags Max
name Type Optional value allowed Length text String Required No 30
url URL Required No alt_url URL Optional No
[0226] The text property in Table 8 represents is the label that is
displayed for the button. In some embodiments, the text is
formatting tags are not permitted for the text property.
[0227] The URL property in Table 8 represents the URL to be
launched when the button is selected. In some embodiments, a
corresponding application or webpage is launched as a new
application instance, not rendered framed in a context of the
wallet client 105. Other applications can call a callback URL to
bring the wallet client 105 back to the foreground.
[0228] The alt_url property in Table 8 is optional and, if
provided, is called when the wallet client 105 determines that
there is no registered protocol handler available for the URL
property.
III. Item Type=Link
[0229] Table 9 shows an example item object of the link item type,
which causes text of a link to be displayed in an alternative
color. When the link is selected, a corresponding URL is
launched.
TABLE-US-00020 TABLE 9 Property Required/ Default Format tags Max
name Type Optional Value allowed Length text String Required Yes
240 label String Optional Yes 30 url URL Required No alt_url URL
Optional No
[0230] The text property in Table 9 represents a block of text to
be rendered in an alternative color, wrapping as necessary. The
text property can include one or more formatting tags (defined
below). If a URL is provided in connection with the link, then,
when the text is selected, the URL is launched in web browser 103
or application 107.
[0231] The label property in Table 9 represents a short text label
to be rendered to the left of the actual link text.
[0232] The URL property in Table 9 represents the URL to be
launched when the link is selected, in a similar manner as that
described above for the button item.
[0233] The alt_url property in Table 9 represents an alternative
URL to be launched in a similar manner as that described above for
the button item.
iv. Item Type=Block
[0234] Table 10 shows an example item object of the block item
type, which is includes optional properties that can be used to
render items in different ways. All of the elements of the block
item type elements are optional.
TABLE-US-00021 TABLE 10 Format Property Required/ Default tags Max
name Type Optional value allowed Length Notes headline String
Optional Yes 30 text String Optional Yes 240 image URL Optional No
URL to img. 360.times.360 px square. align "left" Optional "left"
No "right" "center"
[0235] The headline property in Table 10 represents a line of text
to be displayed at a font size larger than normal text. The
headline property can include formatting tags (described
below).
[0236] The text property in Table 10, which can also include light
formatting tags, defined below, represents a block of text to be
displayed, wrapping as necessary.
[0237] The image property in Table 10 represents a URL to an image
to be rendered. The image, in some examples, is square (e.g.,
360.times.360 pixels in a portable network graphics (PNG) format).
The image can be rendered one-to-one on an "xxhdpi" (1080p) device,
or can scaled appropriately on smaller devices. The image follows
the same caching rules as those that apply to the section in which
it is defined.
[0238] The align property in Table 10 represents a position of the
image. If the align property is set to right or left, then the
image is aligned with the right or left side of the screen,
respectively, and any headline and/or text content is constrained
to the other side, creating a two column layout. If the align
property is set to center, then the image is positioned with
matching right and left margins, and any headline and/or text entry
is positioned below the image.
d. Text Formatting
[0239] As described above, certain text elements for some items can
include formatting. In one example embodiment, formatting is
embedded in the string itself through the use of tags. The < and
> tokens define the tags. If a tag is not matched, or is missing
its closing tag, it is rendered literally. Tags cannot be nested or
overlap. If tags are nested or overlap, then formatting is ignored.
In some embodiments, the following exemplary tags are
supported:
TABLE-US-00022 <br /> (line break) <b> </b>
(bold) <i> </i> (italic) <h> </h>
(highlight color)
[0240] FIG. 13 shows an example of how the following example SDO
document can be rendered.
TABLE-US-00023 { belgian: "5% Cash Back this month on Gas!",
timestamp: 1357341010, version: 1, sections: [ { label: "Summer
Savings", items: [ { type: "block", headline: "Earn 5% Cash Back
this month on Gas!", image: "http://www.amex.com/go/card.png",
align: "right", text: "Lorem ipsum dolor sit amet, consetetur
sadipscing ..." }, { type: "button", text: "Enroll Now", url:
"http://www.amex.com/go/enroll", } ] } { label: "Help", items: [ {
type: "link", text: "www.americanexpress.com", url:
"http://www.americanexpress.com/" }, { type: "link", text:
"help@americanexpress.com", url: "mailto:help@americanexpress.com"
}, { type: "link", text: "1-800-555-1112", url: "tel:18005551112" }
] } ] }
[0241] FIG. 14 shows an example of the rendering of the following
example SDO document.
TABLE-US-00024 { belgian: "You've earned 600 more reward points.",
timestamp: 1357344321, version: 1, sections: [ { label: "Available
Balance, items: "http://api.chase.com/isis/bal?id=abc" } { label:
"Ultimate Rewards", items: "http://api.chase.com/isis/rew?id=abc" }
] } http://api.chase.com/isis/bal?id=abc : [ { type: "block",
headline: "$741.26", text: "Last updated today at 2:34pm" } ]
http://api.chase.com/isis/rew?id=abc : [ { type: "text", text:
"Congratulations! <b>You can earn $75 in Cash Back</b>
using your reward points. <br /> Your current balance is
<b>7723 points</b>." }, { type: "button", text: "Redeem
to Cash", url: "chase://isis/rewards?id=chs123", alt_url:
"http://m.chase.com/isis/r?i=chs" ]
IV. Example Computer-Readable Medium Implementations
[0242] The example embodiments described above, such as, for
example, the systems and procedures depicted in or discussed in
connection with FIGS. 1 through 14 or any part or function thereof,
may be implemented by using hardware, software or a combination of
the two. The implementation may be in one or more computers or
other processing systems. While manipulations performed by these
example embodiments may have been referred to in terms commonly
associated with mental operations performed by a human operator, no
human operator is needed to perform any of the operations described
herein. In other words, the operations may be completely
implemented with machine operations. Useful machines for performing
the operation of the example embodiments presented herein include
general-purpose digital computers or similar devices.
[0243] FIG. 15 is a block diagram of a general and/or special
purpose computer 1500 that may be employed in accordance with
various example embodiments herein. The computer 1500 may be, for
example, a user device, a user computer, a client computer, and/or
a server computer, among other things.
[0244] The computer 1500 may include without limitation a processor
device 1510, a main memory 1525, and an interconnect bus 1505. The
processor device 1510 may include without limitation a single
microprocessor, or may include a plurality of microprocessors for
configuring the computer 1500 as a multi-processor system. The main
memory 1525 stores, among other things, instructions and/or data
for execution by the processor device 1510. The main memory 1525
may include banks of dynamic random access memory (DRAM), as well
as cache memory.
[0245] The computer 1500 may further include a mass storage device
1530, peripheral device(s) 1540, portable storage medium device(s)
1550, input control device(s) 1580, a graphics subsystem 1560,
and/or an output display 1570. For explanatory purposes, all
components in the computer 1500 are shown in FIG. 15 as being
coupled via the bus 1505. However, the computer 1500 is not so
limited. Devices of the computer 1500 may be coupled via one or
more data transport means. For example, the processor device 1510
and/or the main memory 1525 may be coupled via a local
microprocessor bus. The mass storage device 1530, peripheral
device(s) 1540, portable storage medium device(s) 1550, and/or
graphics subsystem 1560 may be coupled via one or more input/output
(I/O) buses. The mass storage device 1530 may be a nonvolatile
storage device for storing data and/or instructions for use by the
processor device 1510. The mass storage device 1530 may be
implemented, for example, with a magnetic disk drive or an optical
disk drive. In a software embodiment, the mass storage device 1530
is configured for loading contents of the mass storage device 1530
into the main memory 1525.
[0246] The portable storage medium device 1550 operates in
conjunction with a nonvolatile portable storage medium, such as,
for example, a compact disc read only memory (CD-ROM), to input and
output data and code to and from the computer 1500. In some
embodiments, the software for storing an internal identifier in
metadata may be stored on a portable storage medium, and may be
inputted into the computer 1500 via the portable storage medium
device 1550. The peripheral device(s) 1540 may include any type of
computer support device, such as, for example, an input/output
(I/O) interface configured to add additional functionality to the
computer 1500. For example, the peripheral device(s) 1540 may
include a network interface card for interfacing the computer 1500
with a network 1520.
[0247] The input control device(s) 1580 provide a portion of the
user interface for a user of the computer 1500. The input control
device(s) 1580 may include a keypad and/or a cursor control device.
The keypad may be configured for inputting alphanumeric characters
and/or other key information. The cursor control device may
include, for example, a mouse, a trackball, a stylus, and/or cursor
direction keys. In order to display textual and graphical
information, the computer 1500 may include the graphics subsystem
1560 and the output display 1570. The output display 1570 may
include a cathode ray tube (CRT) display and/or a liquid crystal
display (LCD). The graphics subsystem 1560 receives textual and
graphical information, and processes the information for output to
the output display 1570.
[0248] Each component of the computer 1500 may represent a broad
category of a computer component of a general and/or special
purpose computer. Components of the computer 1500 are not limited
to the specific implementations provided here.
[0249] Portions of the example embodiments of the invention may be
conveniently implemented by using a conventional general-purpose
computer, a specialized digital computer and/or a microprocessor
programmed according to the teachings of the present disclosure, as
is apparent to those skilled in the computer art. Appropriate
software coding may readily be prepared by skilled programmers
based on the teachings of the present disclosure.
[0250] Some embodiments may also be implemented by the preparation
of application-specific integrated circuits, field programmable
gate arrays, or by interconnecting an appropriate network of
conventional component circuits.
[0251] Some embodiments include a computer program product. The
computer program product may be a storage medium or media having
instructions stored thereon or therein which can be used to
control, or cause, a computer to perform any of the procedures of
the example embodiments of the invention. The storage medium may
include without limitation a floppy disk, a mini disk, an optical
disc, a Blu-Ray Disc, a DVD, a CD-ROM, a micro-drive, a
magneto-optical disk, a ROM, a RAM, an EPROM, an EEPROM, a DRAM, a
VRAM, a flash memory, a flash card, a magnetic card, an optical
card, nanosystems, a molecular memory integrated circuit, a RAID,
remote data storage/archive/warehousing, and/or any other type of
device suitable for storing instructions and/or data.
[0252] Stored on any one of the computer readable medium or media,
some implementations include software for controlling both the
hardware of the general and/or special computer or microprocessor,
and for enabling the computer or microprocessor to interact with a
human user or other mechanism utilizing the results of the example
embodiments of the invention. Such software may include without
limitation device drivers, operating systems, and user
applications. Ultimately, such computer readable media further
includes software for performing example aspects of the invention,
as described above.
[0253] Included in the programming and/or software of the general
and/or special purpose computer or microprocessor are software
modules for implementing the procedures described above.
[0254] While various example embodiments of the invention have been
described above, it should be understood that they have been
presented by way of example, and not limitation. It is apparent to
persons skilled in the relevant art(s) that various changes in form
and detail can be made therein. Thus, the invention should not be
limited by any of the above described example embodiments, but
should be defined only in accordance with the following claims and
their equivalents.
[0255] In addition, it should be understood that the figures are
presented for example purposes only. The architecture of the
example embodiments presented herein is sufficiently flexible and
configurable, such that it may be utilized and navigated in ways
other than that shown in the accompanying figures.
[0256] Further, the purpose of the Abstract is to enable the U.S.
Patent and Trademark Office and the public generally, and
especially the scientists, engineers and practitioners in the art
who are not familiar with patent or legal terms or phraseology, to
determine quickly from a cursory inspection the nature and essence
of the technical disclosure of the application. The Abstract is not
intended to be limiting as to the scope of the example embodiments
presented herein in any way. It is also to be understood that the
procedures recited in the claims need not be performed in the order
presented.
* * * * *
References