US20140012750A1 - Systems, methods, and computer program products for integrating third party services with a mobile wallet - Google Patents
Systems, methods, and computer program products for integrating third party services with a mobile wallet Download PDFInfo
- Publication number
- US20140012750A1 US20140012750A1 US13/934,008 US201313934008A US2014012750A1 US 20140012750 A1 US20140012750 A1 US 20140012750A1 US 201313934008 A US201313934008 A US 201313934008A US 2014012750 A1 US2014012750 A1 US 2014012750A1
- Authority
- US
- United States
- Prior art keywords
- wallet
- service provider
- wallet client
- client
- mobile
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/326—Payment applications installed on the mobile devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/141—Setup of application sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/60—Subscription-based services using application servers or record carriers, e.g. SIM application toolkits
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q2220/00—Business processing using cryptography
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
Definitions
- 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.
- 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.
- 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.
- financial e.g., payments
- non-financial e.g., venue admissions
- 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 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.
- 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.
- the example embodiments herein provide systems, methods, and computer program products for integrating a mobile wallet with third party services.
- 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.
- 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.
- 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.
- 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.
- 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.
- URL uniform resource locator
- 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.
- the structured data object message is periodically synchronized between the identified wallet client and a wallet server, in accordance with another example aspect herein.
- 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.
- third party e.g., service provider
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- FIG. 8 shows example payment product functions or use cases supported by an SP servicing environment, in accordance with an example embodiment herein.
- 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.
- FIG. 10 shows an exemplary procedure for invoking an SP servicing environment by a wallet client, in accordance with an example embodiment herein.
- FIG. 11 shows exemplary pages that a wallet client may present, in accordance with various example embodiments herein.
- FIG. 12 shows how custom SP notifications and/or information may be provided via a wallet client, in accordance with an example embodiment herein.
- FIG. 13 shows how an example structured data object document can be rendered, in accordance with an example embodiment herein.
- FIG. 14 shows how another example structured data object document can be rendered, in accordance with an example embodiment herein.
- 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.
- 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.
- GPR general purpose reloadable
- service provider data generally refers to data relating to one or more service providers, service provider systems, and/or services provided by one or more service providers.
- service provider data refers to any data that is stored in a wallet database and/or in a wallet client database.
- synchronization data 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.
- 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.
- 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 are launched by invoking uniform resource locators (URLs) stored securely within a database of the wallet client.
- URLs uniform resource locators
- 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.
- 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.
- GPR general purpose reloadable
- 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.
- 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.
- 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 .
- SP service provider
- 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 .
- 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 .
- content e.g., websites and/or the webpages of websites
- the mobile application stores 104 are applications that can be used to download and install mobile applications onto the mobile devices 101 .
- the wallet clients 105 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.
- 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 .
- the wallet clients 105 communicate with the corresponding secure elements 106 using ISO 7816 commands, in order to conduct contactless transactions.
- 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.
- 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.
- 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 .
- data e.g., service provider data
- 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 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).
- Storing data e.g., service provider data, such as SP mobile application data, SP mobile website data, and/or preference data
- certain functions e.g., accessing the SP mobile applications 107 and/or the SP mobile websites 116
- certain information e.g., URLs
- the mobile devices 101 may also include corresponding user interfaces, such as interactive touchscreen displays and/or keyboards.
- 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 ).
- MNO mobile network operator
- 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.
- security protocols such as GlobalPlatform secure channel protocol, secure sockets layer (SSL), transport layer security (TLS), and/or another security protocol.
- the wallet database 110 stores data that the wallet server 109 utilizes to perform one or more functions.
- the wallet database 110 may store wallet client state data that indicates the states of each of the wallet clients 105 .
- 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 .
- 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.
- 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 .
- the data e.g., service provider data
- 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 .
- 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.
- VPN virtual private network
- HTTP Hypertext Transfer Protocol
- the ESB 113 acts as an intermediary between the mobile devices 101 and the SP systems 114 .
- 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 .
- 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.
- 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.
- the SP systems 114 support a defined set of messages for communication with the ESB 113 .
- 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 .
- 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
- 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 .
- FIG. 2 describes an exemplary system for integrating a mobile wallet with one or more third party (e.g., service provider) services
- third party e.g., service provider
- servicing environment options i.e., options for providing access to third party services by way of the wallet client 105
- 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 :
- 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 .
- 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.
- 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.
- 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 )):
- 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
- Table 3 shows different URL schemes for Android and iOS platforms
- both Android and iOS platforms support the same URL scheme (e.g., the scheme shown in Table 3 for the iOS platform).
- a structured data object (“SDO”; described in further detail below) may be used to link to a mobile application, independently of any platform.
- 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.
- 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.
- the data elements e.g., the data elements shown above in Table 1, Table 2, and/or Table 3
- 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 .
- the wallet administration tool 112 stores the data elements inputted at block 301 in the wallet database 110 .
- 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.
- the wallet client 105 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 .
- 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 .
- the wallet server 109 transmits to the wallet client 105 the one or more data elements fetched at block 305 .
- 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 .
- the wallet client 105 initiates the SP mobile application 107 or the mobile website 116 .
- the wallet client 105 retrieves the data stored at block 307 in the wallet client database 108 .
- 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 .
- 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 .
- FIGS. 3 through 6 describe example interfaces that may be employed, in accordance with various example embodiments herein, to provide such servicing environment options.
- 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 .
- the service provider system 114 transmits a message to the wallet client 105 by way of the ESB 113 and the wallet server 109 .
- the wallet client 105 transmits a request to the service provider system 114 by way of the wallet server 109 and the ESB 113 .
- the service provider system 114 transmits a response to the wallet client 105 by way of the ESB 113 and the wallet server 109 .
- the service provider system 114 transmits a request to the wallet server 109 by way of the ESB 113 .
- the wallet server 109 transmits a response to the service provider system 114 by way of the ESB 113 .
- the request is a request to update a state of contactless services tracked and stored by the wallet server 109 .
- 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.
- 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.
- 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 .
- FIG. 5 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 .
- 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 .
- this URL may be stored in the wallet client database 108 and/or in the wallet database 110 .
- 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 .
- 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 .
- 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 .
- 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 .
- 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.
- 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 .
- 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.
- 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 .
- 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 .
- 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 .
- 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 .
- 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 .
- 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.
- 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 .
- the SP mobile application 107 interprets any predefined parameters embedded therein.
- the mobile device 101 displays a link corresponding to the URL of the SP mobile application 107 .
- 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 .
- 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 .
- a predefined URL format e.g., a format of a URL of the wallet client 105
- 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 .
- the wallet client 105 interprets any predefined parameters embedded therein.
- the mobile device 101 displays a link corresponding to the URL of the wallet client 105 .
- 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 .
- 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.
- 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.
- 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 .
- 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 .
- 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 .
- 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.
- 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.
- example use cases or payment product functions supported by the SP servicing environment include the following:
- 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 .
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 ).
- untrusted networks e.g., the communications network 115 and/or the mobile networks 111 .
- 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.
- 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 .
- an authenticated state e.g., by having executed one of the authentication procedures described above
- the wallet client 105 is synchronized with the wallet server 109
- a secure communication channel has been established between the wallet server 109 and the SP 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.
- 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.
- 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:
- 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 .
- 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.
- the wallet client 105 generates and sends the nonces to the SP system 114 through secured communication channels.
- the session secrets e.g., the encryption key and the signing key
- the session secrets are not sent in any message payloads.
- 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.
- MDN mobile device number
- 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 .
- 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 .
- IMEI international mobile station equipment identity
- MEID mobile equipment identifier
- MAC media access control
- 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 :
- 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 .
- the SP system 114 computes a signing key based on nonce A and computes an encryption key based on nonce B.
- the wallet client 105 also computes the signing key and the encryption key, in the same manner as the SP system 114 .
- 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.
- 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.
- PBKDF2 password-based key derivation function 2
- Input: ⁇ split the nonce into two equal halves, passing the first half as ‘salt’ and the second half as ‘password’ to PBKDF2
- 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.
- 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 ).
- 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.
- 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.
- 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 wallet server 109 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 .
- 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 .
- 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 .
- 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 .
- 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 .
- 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 .
- 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.
- 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.
- 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.
- FIG. 10 describes 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 .
- the wallet client 105 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 .
- the wallet client 105 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.
- PRN payment product reference number
- 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 ).
- 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.
- the wallet client 105 prior to step 1001 , 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 .
- 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.
- 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 .
- value : ⁇ text>
- the wallet client 105 constructs the request URL by executing a request construction algorithm including the following steps:
- the above request construction algorithm produces, in one example, a message having the following format:
- 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.
- the wallet client 105 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.
- 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 .
- the wallet client 105 invokes the mobile device web browser 103 and passes the encoded URL as the destination URL.
- the wallet client 105 transmits to the SP system 114 a request to launch the SP mobile website 116 .
- the request includes a source URL including data of the encoded URL generated at step 1001 .
- the wallet client 105 encrypts an entire parameter block of the request transmitted at step 1003 .
- 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.
- 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 .
- the SP system 114 breaks down the encoded URL received as part of the request at step 1003 .
- 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.
- the SP system 114 verifies the signature with which the wallet client 105 signed the URL at step 1001 .
- 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.
- 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.
- the parameter block e.g., including parameters such as a wallet identifier and/or a payment product identifier
- 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 .
- 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 .
- 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 .
- the mobile web browser 103 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.
- the SP system 114 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 .
- 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.
- 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 .
- 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 .
- PIN personal identification number
- the SP system 114 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.
- value : ⁇ text>
- the SP system 114 constructs the wallet request URL by executing a request construction algorithm including the following steps:
- the above request construction algorithm produces, in one example, a message having the following format:
- the wallet client 105 verifies the signature with which the SP system 114 signed the URL.
- 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.
- 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.
- 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.
- 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).
- 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.
- 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 .
- 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 .
- the wallet client 105 requests the content from the SP system 114 .
- 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 .
- 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 .
- 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 .
- FIG. 11 shows exemplary pages 1101 , 1102 , and 1103 that the wallet client 105 may present, in accordance with some example embodiments.
- the page 1101 is an example of a front of card page
- the page 1102 is an example of a back of card page
- the page 1103 is an example of a card details page.
- 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.
- 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.
- 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.
- 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.
- 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 .
- 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 .
- multiple user interface elements e.g., text, headers, images, icons, buttons, etc.
- the wallet client 105 displays a flag 1104 adjacent to an image associated with the payment product.
- 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 .
- additional information e.g., the information provided in sections 1109 through 1116 described above
- the display of the flag 1104 is controlled by a belgian text property of the SDO.
- the flag 1104 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.
- 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 .
- 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 .
- 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.
- 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 .
- 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.
- a non-active state such as a blocked state
- 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.
- 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.
- 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).
- a website e.g., the SP mobile website 116
- an application e.g., the SP mobile application 107
- an associated URL e.g., http://www.chase.com/ or chase://balance
- 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:
- 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 .
- 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.
- 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.
- 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 .
- the SP system 114 provides (step 1201 ) a wallet identifier and a card identifier corresponding to the particular wallet client 105 .
- 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.
- 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.
- 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.
- a particular type of payment product e.g., “Chase Freedom”
- 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 .
- 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.
- scenarios where the wallet client 105 pulls additional updates from the wallet server 109 include:
- 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).
- 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).
- 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 .
- the SP systems 114 can provide content specific to a user and/or a product.
- 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.
- the updated SDO document replaces the entire previous SDO document on the wallet server 109 and the wallet client 105 .
- 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.
- 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.
- Table 5 below shows elements of the root SDO document.
- 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.
- 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 .
- 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 .
- the service provider can cause the wallet client 105 to notify the user that something on the card details page 1103 has changed.
- 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.
- the ‘timestamp’ property in Table 5 represents the time the SDO document was last updated in seconds since the UNIX epoch.
- 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.
- 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.
- 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.
- 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 .
- 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 .
- 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.
- 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.
- 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.
- the item objects of the item property in Table 6 are individual user interface elements rendered in a section.
- Each item type has a corresponding set of valid properties. For instance, a headline property may only be valid for a block item type.
- 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.
- 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.
- the SP system 114 can optionally format the block of text, but cannot include embedded links.
- the text property in Table 7 renders lines of text in a default color, wrapping as necessary.
- the text property can include one or more formatting tags (described below), and does not contain embedded links.
- 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.
- 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.
- the URL property in Table 8 represents the URL to be launched when the button is selected.
- 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.
- 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.
- 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.
- a corresponding URL is launched.
- 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 .
- the label property in Table 9 represents a short text label to be rendered to the left of the actual link text.
- 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.
- 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.
- 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.
- 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).
- 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.
- 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 ⁇ 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.
- 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.
- certain text elements for some items can include formatting.
- 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.
- the following exemplary tags are supported:
- FIG. 13 shows an example of how the following example SDO document can be rendered.
- FIG. 14 shows an example of the rendering of the following example SDO document.
- the example embodiments described above may be implemented by using hardware, software or a combination of the two.
- the implementation may be in one or more computers or other processing systems. While manipulations performed by these example embodiments may have been referred to in terms commonly associated with mental operations performed by a human operator, no human operator is needed to perform any of the operations described herein. In other words, the operations may be completely implemented with machine operations.
- Useful machines for performing the operation of the example embodiments presented herein include general-purpose digital computers or similar devices.
- FIG. 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.
- 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.
- DRAM dynamic random access memory
- 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 .
- a mass storage device 1530 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 .
- all components in the computer 1500 are shown in FIG. 15 as being coupled via the bus 1505 .
- the computer 1500 is not so limited.
- Devices of the computer 1500 may be coupled via one or more data transport means.
- 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 .
- 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 .
- a nonvolatile portable storage medium such as, for example, a compact disc read only memory (CD-ROM)
- 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 .
- the peripheral device(s) 1540 may include a network interface card for interfacing the computer 1500 with a network 1520 .
- 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.
- 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 .
- 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.
- Portions of the example embodiments of the invention may be conveniently implemented by using a conventional general-purpose computer, a specialized digital computer and/or a microprocessor programmed according to the teachings of the present disclosure, as is apparent to those skilled in the computer art.
- Appropriate software coding may readily be prepared by skilled programmers based on the teachings of the present disclosure.
- Some embodiments may also be implemented by the preparation of application-specific integrated circuits, field programmable gate arrays, or by interconnecting an appropriate network of conventional component circuits.
- 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.
- 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.
- software may include without limitation device drivers, operating systems, and user applications.
- computer readable media further includes software for performing example aspects of the invention, as described above.
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Computer Networks & Wireless Communication (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Telephonic Communication Services (AREA)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/934,008 US20140012750A1 (en) | 2012-07-09 | 2013-07-02 | Systems, methods, and computer program products for integrating third party services with a mobile wallet |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201261669576P | 2012-07-09 | 2012-07-09 | |
US201261669915P | 2012-07-10 | 2012-07-10 | |
US201361816488P | 2013-04-26 | 2013-04-26 | |
US13/934,008 US20140012750A1 (en) | 2012-07-09 | 2013-07-02 | Systems, methods, and computer program products for integrating third party services with a mobile wallet |
Publications (1)
Publication Number | Publication Date |
---|---|
US20140012750A1 true US20140012750A1 (en) | 2014-01-09 |
Family
ID=48782669
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/934,008 Abandoned US20140012750A1 (en) | 2012-07-09 | 2013-07-02 | Systems, methods, and computer program products for integrating third party services with a mobile wallet |
US13/934,014 Active 2033-11-14 US9563891B2 (en) | 2012-07-09 | 2013-07-02 | Systems, methods, and computer program products for integrating third party services with a mobile wallet |
US15/404,439 Active 2034-07-29 US10387873B2 (en) | 2012-07-09 | 2017-01-12 | Systems, methods, and computer program products for integrating third party services with a mobile wallet |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/934,014 Active 2033-11-14 US9563891B2 (en) | 2012-07-09 | 2013-07-02 | Systems, methods, and computer program products for integrating third party services with a mobile wallet |
US15/404,439 Active 2034-07-29 US10387873B2 (en) | 2012-07-09 | 2017-01-12 | Systems, methods, and computer program products for integrating third party services with a mobile wallet |
Country Status (2)
Country | Link |
---|---|
US (3) | US20140012750A1 (fr) |
WO (2) | WO2014011453A2 (fr) |
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130340043A1 (en) * | 2012-06-13 | 2013-12-19 | Mehrdad (John) Zarei | Distribution of dynamic structured content |
WO2015009529A1 (fr) | 2013-07-17 | 2015-01-22 | Jvl Ventures, Llc | Systèmes, procédés et produits programmes d'ordinateur pour la remise de données de transaction sans contact |
US20150172061A1 (en) * | 2013-12-17 | 2015-06-18 | Samsung Electronics Co., Ltd. | Method and apparatus for registering devices capable of device-to-device communication in server |
US20160021065A1 (en) * | 2014-07-18 | 2016-01-21 | Bank Of America Corporation | Method and apparatus for masking non-public data elements in uniform resource indentifiers ("uri") |
US20160018954A1 (en) * | 2014-07-17 | 2016-01-21 | Samsung Electronics Co., Ltd | Data processing method and electronic device thereof |
CN105357261A (zh) * | 2015-09-29 | 2016-02-24 | 腾讯科技(深圳)有限公司 | 服务处理方法及服务处理装置 |
US20160234330A1 (en) * | 2015-02-11 | 2016-08-11 | Go Daddy Operating Company, LLC | System and method for mobile application deep linking |
US9563891B2 (en) | 2012-07-09 | 2017-02-07 | Google Inc. | Systems, methods, and computer program products for integrating third party services with a mobile wallet |
US9652770B1 (en) | 2014-04-30 | 2017-05-16 | Wells Fargo Bank, N.A. | Mobile wallet using tokenized card systems and methods |
US20180167214A1 (en) * | 2016-12-12 | 2018-06-14 | Sap Portals Israel Ltd. | Client side actions validation |
CN108885651A (zh) * | 2016-04-05 | 2018-11-23 | 开利公司 | 凭证许可服务 |
US10277688B2 (en) | 2017-01-04 | 2019-04-30 | Microsoft Technology Licensing, Llc | Automatic installation activation selection for hosted services |
US10445739B1 (en) | 2014-08-14 | 2019-10-15 | Wells Fargo Bank, N.A. | Use limitations for secondary users of financial accounts |
CN110610360A (zh) * | 2019-09-09 | 2019-12-24 | 飞天诚信科技股份有限公司 | 一种硬件钱包绑定授权的方法及装置 |
WO2020125775A1 (fr) * | 2018-12-20 | 2020-06-25 | 深圳市愚公科技有限公司 | Procédé et appareil de traitement d'informations de service de client en ligne à plusieurs parties de service |
CN111507727A (zh) * | 2020-04-20 | 2020-08-07 | 车主邦(北京)科技有限公司 | 无感支付的安全性控制方法 |
US10997592B1 (en) | 2014-04-30 | 2021-05-04 | Wells Fargo Bank, N.A. | Mobile wallet account balance systems and methods |
US11074577B1 (en) | 2018-05-10 | 2021-07-27 | Wells Fargo Bank, N.A. | Systems and methods for making person-to-person payments via mobile client application |
US11288660B1 (en) | 2014-04-30 | 2022-03-29 | Wells Fargo Bank, N.A. | Mobile wallet account balance systems and methods |
US11295297B1 (en) | 2018-02-26 | 2022-04-05 | Wells Fargo Bank, N.A. | Systems and methods for pushing usable objects and third-party provisioning to a mobile wallet |
US11410161B1 (en) | 2014-04-30 | 2022-08-09 | Wells Fargo Bank, N.A. | Mobile wallet systems and methods |
US11461766B1 (en) | 2014-04-30 | 2022-10-04 | Wells Fargo Bank, N.A. | Mobile wallet using tokenized card systems and methods |
US11468414B1 (en) | 2016-10-03 | 2022-10-11 | Wells Fargo Bank, N.A. | Systems and methods for establishing a pull payment relationship |
US11568389B1 (en) | 2014-04-30 | 2023-01-31 | Wells Fargo Bank, N.A. | Mobile wallet integration within mobile banking |
US11610197B1 (en) | 2014-04-30 | 2023-03-21 | Wells Fargo Bank, N.A. | Mobile wallet rewards redemption systems and methods |
US11615401B1 (en) | 2014-04-30 | 2023-03-28 | Wells Fargo Bank, N.A. | Mobile wallet authentication systems and methods |
US11775955B1 (en) | 2018-05-10 | 2023-10-03 | Wells Fargo Bank, N.A. | Systems and methods for making person-to-person payments via mobile client application |
US11853919B1 (en) | 2015-03-04 | 2023-12-26 | Wells Fargo Bank, N.A. | Systems and methods for peer-to-peer funds requests |
US11948134B1 (en) | 2019-06-03 | 2024-04-02 | Wells Fargo Bank, N.A. | Instant network cash transfer at point of sale |
US11995621B1 (en) | 2021-10-22 | 2024-05-28 | Wells Fargo Bank, N.A. | Systems and methods for native, non-native, and hybrid registration and use of tags for real-time services |
Families Citing this family (50)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9047601B2 (en) * | 2006-09-24 | 2015-06-02 | RFCyber Corpration | Method and apparatus for settling payments using mobile devices |
US9691055B2 (en) | 2010-12-17 | 2017-06-27 | Google Inc. | Digital wallet |
US10084818B1 (en) | 2012-06-07 | 2018-09-25 | Amazon Technologies, Inc. | Flexibly configurable data modification services |
US9286491B2 (en) | 2012-06-07 | 2016-03-15 | Amazon Technologies, Inc. | Virtual service provider zones |
US9590959B2 (en) | 2013-02-12 | 2017-03-07 | Amazon Technologies, Inc. | Data security service |
US10075471B2 (en) | 2012-06-07 | 2018-09-11 | Amazon Technologies, Inc. | Data loss prevention techniques |
US10211977B1 (en) | 2013-02-12 | 2019-02-19 | Amazon Technologies, Inc. | Secure management of information using a security module |
US10467422B1 (en) | 2013-02-12 | 2019-11-05 | Amazon Technologies, Inc. | Automatic key rotation |
US9608813B1 (en) | 2013-06-13 | 2017-03-28 | Amazon Technologies, Inc. | Key rotation techniques |
US9367697B1 (en) | 2013-02-12 | 2016-06-14 | Amazon Technologies, Inc. | Data security with a security module |
US9300464B1 (en) | 2013-02-12 | 2016-03-29 | Amazon Technologies, Inc. | Probabilistic key rotation |
US10210341B2 (en) | 2013-02-12 | 2019-02-19 | Amazon Technologies, Inc. | Delayed data access |
US9705674B2 (en) | 2013-02-12 | 2017-07-11 | Amazon Technologies, Inc. | Federated key management |
US9547771B2 (en) | 2013-02-12 | 2017-01-17 | Amazon Technologies, Inc. | Policy enforcement with associated data |
US20150019417A1 (en) * | 2013-06-26 | 2015-01-15 | Google Inc. | Updating a digital wallet from financial account issuer |
US9456003B2 (en) | 2013-07-24 | 2016-09-27 | At&T Intellectual Property I, L.P. | Decoupling hardware and software components of network security devices to provide security software as a service in a distributed computing environment |
US10778680B2 (en) * | 2013-08-02 | 2020-09-15 | Alibaba Group Holding Limited | Method and apparatus for accessing website |
FR3011418A1 (fr) * | 2013-09-30 | 2015-04-03 | Orange | Technique d'administration a distance d'un dispositif appartenant a un reseau prive |
US10664833B2 (en) * | 2014-03-05 | 2020-05-26 | Mastercard International Incorporated | Transactions utilizing multiple digital wallets |
US9397835B1 (en) | 2014-05-21 | 2016-07-19 | Amazon Technologies, Inc. | Web of trust management in a distributed system |
US9438421B1 (en) | 2014-06-27 | 2016-09-06 | Amazon Technologies, Inc. | Supporting a fixed transaction rate with a variably-backed logical cryptographic key |
US9697298B2 (en) * | 2014-08-07 | 2017-07-04 | Etas Embedded Systems Canada Inc. | ID tag authentication system and method |
US10057240B2 (en) * | 2014-08-25 | 2018-08-21 | Sap Se | Single sign-on to web applications from mobile devices |
US9866392B1 (en) | 2014-09-15 | 2018-01-09 | Amazon Technologies, Inc. | Distributed system web of trust provisioning |
KR102457809B1 (ko) * | 2014-09-24 | 2022-10-24 | 삼성전자주식회사 | 데이터 통신 보안을 위한 방법, 장치 및 시스템 |
US10902423B2 (en) * | 2014-09-29 | 2021-01-26 | Mastercard International Incorporated | Method and apparatus for streamlined digital wallet transactions |
US10469477B2 (en) | 2015-03-31 | 2019-11-05 | Amazon Technologies, Inc. | Key export techniques |
US10489777B2 (en) * | 2016-01-05 | 2019-11-26 | Visa International Service Association | Universal access to an electronic wallet |
SG10202011640TA (en) | 2016-02-23 | 2021-01-28 | Nchain Holdings Ltd | System and method for controlling asset-related actions via a blockchain |
AU2017223129A1 (en) * | 2016-02-23 | 2018-07-12 | nChain Holdings Limited | Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system |
KR20180114942A (ko) | 2016-02-23 | 2018-10-19 | 엔체인 홀딩스 리미티드 | 분산형 해시 테이블 및 블록체인을 사용하여 컴퓨터 소프트웨어를 보호하기 위한 방법 및 시스템 |
CA3013182A1 (fr) | 2016-02-23 | 2017-08-31 | nChain Holdings Limited | Systeme universel de segmentation en jetons pour des monnaies cryptographiques a enchainement de blocs |
EP3860037A1 (fr) | 2016-02-23 | 2021-08-04 | Nchain Holdings Limited | Procédé cryptographique et système d'extraction sécurisée de données d'une chaîne de blocs |
CN113595726A (zh) | 2016-02-23 | 2021-11-02 | 区块链控股有限公司 | 用于控制和分发数字内容的区块链实现的方法 |
GB2561727A (en) | 2016-02-23 | 2018-10-24 | Nchain Holdings Ltd | Blockchain-based exchange with tokenisation |
EP3754901A1 (fr) | 2016-02-23 | 2020-12-23 | Nchain Holdings Limited | Système et procédé de comptage mis en uvre par chaîne de blocs destinés à être utilisés dans un vote et une distribution sécurisés |
EP3420668B1 (fr) | 2016-02-23 | 2023-08-23 | nChain Licensing AG | Procédé et système de transfert efficace de cryptomonnaie associée à une liste de paie sur une chaîne de blocs produisant un procédé et un système de paie automatisée basés sur des contrats intelligents |
KR101999188B1 (ko) | 2016-02-23 | 2019-07-11 | 엔체인 홀딩스 리미티드 | 비밀 공유를 위한 타원 곡선 암호를 사용하는 개인용 장치 보안 |
EP3420517B1 (fr) | 2016-02-23 | 2022-07-06 | nChain Holdings Limited | Procédé et système de transfert sécurisé d'entités sur un enchaînement de blocs |
CA3227439A1 (fr) | 2016-02-23 | 2017-08-31 | nChain Holdings Limited | Registre et procede de gestion automatisee pour contrats intelligents appliques par chaine de blocs |
SG11201805472RA (en) | 2016-02-23 | 2018-07-30 | Nchain Holdings Ltd | Determining a common secret for the secure exchange of information and hierarchical, deterministic cryptographic keys |
SG10202011641RA (en) | 2016-02-23 | 2021-01-28 | Nchain Holdings Ltd | Tokenisation method and system for implementing exchanges on a blockchain |
US10158548B2 (en) * | 2016-08-24 | 2018-12-18 | Facebook, Inc. | Methods and systems for signing resource identifiers |
US10501640B2 (en) * | 2017-01-31 | 2019-12-10 | Arizona Board Of Regents On Behalf Of Arizona State University | Nanoporous materials, method of manufacture and methods of use |
US10853791B1 (en) | 2017-02-14 | 2020-12-01 | Wells Fargo Bank, N.A. | Mobile wallet dynamic interface |
US10757676B1 (en) * | 2019-03-08 | 2020-08-25 | Tile, Inc. | Commissioning electronic devices for use in a tracking system |
US11769132B1 (en) | 2019-05-22 | 2023-09-26 | Wells Fargo Bank, N.A. | P2P payments via integrated 3rd party APIs |
WO2020257657A1 (fr) | 2019-06-19 | 2020-12-24 | FinanceNinja, LLC | Systèmes et procédés de mise en œuvre d'un portail de commanditaire pour la médiation de services à des utilisateurs finaux |
US11729163B2 (en) * | 2021-03-19 | 2023-08-15 | The Toronto-Dominion Bank | System and method for establishing secure communication between applications |
US11935035B2 (en) * | 2021-04-20 | 2024-03-19 | Capital One Services, Llc | Techniques to utilize resource locators by a contactless card to perform a sequence of operations |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020065774A1 (en) * | 1999-11-30 | 2002-05-30 | Alan Young | System and method for performing an electronic transaction using a transaction proxy with an electronic wallet |
US20050187873A1 (en) * | 2002-08-08 | 2005-08-25 | Fujitsu Limited | Wireless wallet |
US20070125838A1 (en) * | 2005-12-06 | 2007-06-07 | Law Eric C W | Electronic wallet management |
US20080010193A1 (en) * | 2006-07-06 | 2008-01-10 | Firethorn Holdings, Llc | Methods and Systems For Payment Method Selection by a Payee in a Mobile Environment |
US20110270748A1 (en) * | 2010-04-30 | 2011-11-03 | Tobsc Inc. | Methods and apparatus for a financial document clearinghouse and secure delivery network |
US20120095852A1 (en) * | 2010-10-15 | 2012-04-19 | John Bauer | Method and system for electronic wallet access |
Family Cites Families (103)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6925439B1 (en) | 1994-06-20 | 2005-08-02 | C-Sam, Inc. | Device, system and methods of conducting paperless transactions |
US5590038A (en) | 1994-06-20 | 1996-12-31 | Pitroda; Satyan G. | Universal electronic transaction card including receipt storage and system and methods of conducting electronic transactions |
US5715314A (en) * | 1994-10-24 | 1998-02-03 | Open Market, Inc. | Network sales system |
US5834747A (en) | 1994-11-04 | 1998-11-10 | Pixel Instruments | Universal credit card apparatus and method |
US5640002A (en) | 1995-08-15 | 1997-06-17 | Ruppert; Jonathan Paul | Portable RF ID tag and barcode reader |
US5805702A (en) | 1995-09-29 | 1998-09-08 | Dallas Semiconductor Corporation | Method, apparatus, and system for transferring units of value |
US5748740A (en) | 1995-09-29 | 1998-05-05 | Dallas Semiconductor Corporation | Method, apparatus, system and firmware for secure transactions |
US5940510A (en) | 1996-01-31 | 1999-08-17 | Dallas Semiconductor Corporation | Transfer of valuable information between a secure module and another module |
US6837436B2 (en) | 1996-09-05 | 2005-01-04 | Symbol Technologies, Inc. | Consumer interactive shopping system |
US5901303A (en) | 1996-12-27 | 1999-05-04 | Gemplus Card International | Smart cards, systems using smart cards and methods of operating said cards in systems |
US6098879A (en) | 1997-09-26 | 2000-08-08 | Gilbarco, Inc. | Fuel dispensing system providing customer preferences |
US6810304B1 (en) | 1997-09-26 | 2004-10-26 | Gilbarco Inc. | Multistage ordering system for a fueling and retail environment |
US6073840A (en) | 1997-09-26 | 2000-06-13 | Gilbarco Inc. | Fuel dispensing and retail system providing for transponder prepayment |
US6735694B1 (en) * | 1997-11-21 | 2004-05-11 | International Business Machines Corporation | Method and system for certifying authenticity of a web page copy |
US6131811A (en) | 1998-05-29 | 2000-10-17 | E-Micro Corporation | Wallet consolidator |
US6116505A (en) | 1998-07-21 | 2000-09-12 | Gilbarco Inc. | Fuel transaction system for enabling the purchase of fuel and non-fuel items on a single authorization |
US6332128B1 (en) | 1998-07-23 | 2001-12-18 | Autogas Systems, Inc. | System and method of providing multiple level discounts on cross-marketed products and discounting a price-per-unit-volume of gasoline |
US7469381B2 (en) | 2007-01-07 | 2008-12-23 | Apple Inc. | List scrolling and document translation, scaling, and rotation on a touch-screen display |
US7571139B1 (en) | 1999-02-19 | 2009-08-04 | Giordano Joseph A | System and method for processing financial transactions |
US7308426B1 (en) | 1999-08-11 | 2007-12-11 | C-Sam, Inc. | System and methods for servicing electronic transactions |
US20020049631A1 (en) | 1999-10-12 | 2002-04-25 | Eric Williams | Process, system and computer readable medium for providing purchasing incentives to a plurality of retail store environments |
US6705520B1 (en) | 1999-11-15 | 2004-03-16 | Satyan G. Pitroda | Point of sale adapter for electronic transaction device |
US6587835B1 (en) | 2000-02-09 | 2003-07-01 | G. Victor Treyz | Shopping assistance with handheld computing device |
ATE355568T1 (de) | 2000-02-11 | 2006-03-15 | Internet Payments Ltd | Ein netzwerk basierendes system |
US20030083042A1 (en) | 2000-02-11 | 2003-05-01 | Maher Abuhamdeh | Remote rechargeable prepaid cellular service peripheral device |
US7194422B1 (en) | 2000-03-08 | 2007-03-20 | The Coca-Cola Company | Disaggregated databases for tracking consumer purchasing data |
KR101015341B1 (ko) * | 2000-04-24 | 2011-02-16 | 비자 인터내셔날 써비스 어쏘시에이션 | 온라인 지불인 인증 서비스 |
GB2364482B (en) * | 2000-06-30 | 2002-10-09 | Motorola Inc | Server-based electronic wallet system |
US7529563B1 (en) | 2000-07-10 | 2009-05-05 | Pitroda Satyan G | System for distribution and use of virtual stored value cards |
US7216109B1 (en) | 2000-07-24 | 2007-05-08 | Donner Irah H | System and method for reallocating and/or upgrading and/or selling tickets, other event admittance means, goods and/or services |
WO2002029702A1 (fr) | 2000-10-04 | 2002-04-11 | American Express Travel Related Services Company, Inc. | Systeme et procede servant a produire une retroaction dans un systeme de paiement interactif |
US7398225B2 (en) | 2001-03-29 | 2008-07-08 | American Express Travel Related Services Company, Inc. | System and method for networked loyalty program |
SE518059C2 (sv) | 2000-12-22 | 2002-08-20 | Payment Security Sweden Ab | Förfarande för att öka säkerheten vid betalning med kredit- och betalkort |
GB0031607D0 (en) | 2000-12-27 | 2001-02-07 | Koninkl Philips Electronics Nv | Credit system and method |
US7856377B2 (en) | 2001-03-29 | 2010-12-21 | American Express Travel Related Services Company, Inc. | Geographic loyalty system and method |
US20030236977A1 (en) * | 2001-04-25 | 2003-12-25 | Levas Robert George | Method and system for providing secure access to applications |
US6671358B1 (en) | 2001-04-25 | 2003-12-30 | Universal Identity Technologies, Inc. | Method and system for rewarding use of a universal identifier, and/or conducting a financial transaction |
WO2002091281A2 (fr) | 2001-05-04 | 2002-11-14 | Outsite Networks, Inc. | Systemes et procedes d'identification et d'affichage d'informations |
US20020174025A1 (en) | 2001-05-17 | 2002-11-21 | Hind John R. | Method and system for providing targeted advertising and personalized customer services |
WO2002101512A2 (fr) | 2001-06-12 | 2002-12-19 | Paytronix Systems, Inc. | Systeme de passerelle de paiement de commerçant, de fidelite et d'identification de client |
US7996324B2 (en) | 2001-07-10 | 2011-08-09 | American Express Travel Related Services Company, Inc. | Systems and methods for managing multiple accounts on a RF transaction device using secondary identification indicia |
US7249112B2 (en) | 2002-07-09 | 2007-07-24 | American Express Travel Related Services Company, Inc. | System and method for assigning a funding source for a radio frequency identification device |
US7463133B2 (en) | 2001-07-10 | 2008-12-09 | American Express Travel Related Services Company, Inc. | Systems and methods for providing a RF transaction device operable to store multiple distinct calling card accounts |
WO2003012717A1 (fr) | 2001-07-30 | 2003-02-13 | C-Sam, Inc. | Systeme de distribution et d'utilisation de cartes de valeurs stockees virtuelles |
US7127236B2 (en) | 2001-12-26 | 2006-10-24 | Vivotech, Inc. | Micropayment financial transaction process utilizing wireless network processing |
GB2386713B (en) * | 2002-03-22 | 2005-08-31 | Hewlett Packard Co | Apparatus for distributed access control |
US6971017B2 (en) * | 2002-04-16 | 2005-11-29 | Xerox Corporation | Ad hoc secure access to documents and services |
US20030200489A1 (en) | 2002-04-18 | 2003-10-23 | Laszlo Hars | Secure method of and system for rewarding customers |
US7494055B2 (en) | 2002-09-17 | 2009-02-24 | Vivotech, Inc. | Collaborative negotiation techniques for mobile personal trusted device financial transactions |
US10176476B2 (en) * | 2005-10-06 | 2019-01-08 | Mastercard Mobile Transactions Solutions, Inc. | Secure ecosystem infrastructure enabling multiple types of electronic wallets in an ecosystem of issuers, service providers, and acquires of instruments |
US7660998B2 (en) * | 2002-12-02 | 2010-02-09 | Silverbrook Research Pty Ltd | Relatively unique ID in integrated circuit |
US7155405B2 (en) | 2002-12-31 | 2006-12-26 | Symbol Technologies, Inc. | System for communicating product and service related information to a user based on direction of movement |
US20040186768A1 (en) | 2003-03-21 | 2004-09-23 | Peter Wakim | Apparatus and method for initiating remote content delivery by local user identification |
WO2004105359A2 (fr) | 2003-05-19 | 2004-12-02 | Einar Rosenberg | Dispositif et procede permettant d'obtenir une securite accrue au cours de transactions par voie hertzienne |
KR100596536B1 (ko) | 2003-10-16 | 2006-07-07 | 주식회사 모빌리언스 | 유알엘(url) 콜백을 포함하는 단문메시지를 이용한전자결제 승인방법 및 시스템 |
US20050222961A1 (en) | 2004-04-05 | 2005-10-06 | Philippe Staib | System and method of facilitating contactless payment transactions across different payment systems using a common mobile device acting as a stored value device |
US10318940B2 (en) | 2004-04-14 | 2019-06-11 | Capital One Services, Llc | System and method for providing personalized customer assistance using a financial card having an RFID device |
US7693752B2 (en) | 2004-05-26 | 2010-04-06 | Hothand, Inc. | Mobile commerce framework |
KR100930457B1 (ko) * | 2004-08-25 | 2009-12-08 | 에스케이 텔레콤주식회사 | 이동통신단말을 이용한 인증 및 결제 시스템과 방법 |
US7581678B2 (en) | 2005-02-22 | 2009-09-01 | Tyfone, Inc. | Electronic transaction card |
US8112354B2 (en) * | 2005-04-08 | 2012-02-07 | Billeo, Inc | Method and system for virtual consolidation of biller direct web sites |
US20060240802A1 (en) * | 2005-04-26 | 2006-10-26 | Motorola, Inc. | Method and apparatus for generating session keys |
US20060274695A1 (en) * | 2005-06-03 | 2006-12-07 | Nokia Corporation | System and method for effectuating a connection to a network |
US20060287004A1 (en) | 2005-06-17 | 2006-12-21 | Fuqua Walter B | SIM card cash transactions |
US7775430B2 (en) | 2005-06-23 | 2010-08-17 | Xerox Corporation | Smart and easy shopping using portable RF transceiver-enabled devices and fixed in-store RF transceivers |
US8477940B2 (en) | 2005-07-15 | 2013-07-02 | Tyfone, Inc. | Symmetric cryptography with user authentication |
US8189788B2 (en) | 2005-07-15 | 2012-05-29 | Tyfone, Inc. | Hybrid symmetric/asymmetric cryptography with user authentication |
US7805615B2 (en) | 2005-07-15 | 2010-09-28 | Tyfone, Inc. | Asymmetric cryptography with user authentication |
US7298271B2 (en) | 2005-09-19 | 2007-11-20 | Peter Sprogis | Method and apparatus for providing awards using transponders |
WO2007044500A2 (fr) | 2005-10-06 | 2007-04-19 | C-Sam, Inc. | Services de transactions |
KR101443612B1 (ko) * | 2006-08-08 | 2014-09-23 | 엘지전자 주식회사 | Ro 이동을 위한 drm 에이전트 간의 인증 방법 및 장치 |
US8165635B2 (en) | 2006-09-01 | 2012-04-24 | Vivotech, Inc. | Methods, systems, and computer readable media for over the air (OTA) provisioning of soft cards on devices with wireless communications capabilities |
US7469151B2 (en) | 2006-09-01 | 2008-12-23 | Vivotech, Inc. | Methods, systems and computer program products for over the air (OTA) provisioning of soft cards on devices with wireless communications capabilities |
US7864163B2 (en) | 2006-09-06 | 2011-01-04 | Apple Inc. | Portable electronic device, method, and graphical user interface for displaying structured electronic documents |
US8060916B2 (en) * | 2006-11-06 | 2011-11-15 | Symantec Corporation | System and method for website authentication using a shared secret |
US7991158B2 (en) | 2006-12-13 | 2011-08-02 | Tyfone, Inc. | Secure messaging |
US7631810B2 (en) | 2006-12-19 | 2009-12-15 | Vivotech, Inc. | Systems, methods, and computer program products for supporting multiple applications and multiple instances of the same application on a wireless smart device |
US20110271044A1 (en) | 2007-03-30 | 2011-11-03 | Tyfone, Inc. | Memory card having one or more secure elements accessed with hidden commands |
US8116678B2 (en) | 2007-06-08 | 2012-02-14 | Vivotech, Inc. | Methods, systems and computer program products for interacting with ISO 14443-4 and MIFARE® applications on the same wireless smart device during a common transaction |
US20090069049A1 (en) | 2007-09-12 | 2009-03-12 | Devicefidelity, Inc. | Interfacing transaction cards with host devices |
US8825999B2 (en) * | 2007-10-20 | 2014-09-02 | Blackout, Inc. | Extending encrypting web service |
US9098844B2 (en) * | 2007-11-20 | 2015-08-04 | Wells Fargo Bank, N.A. | Mobile electronic wallet |
US7967215B2 (en) | 2008-04-18 | 2011-06-28 | Vivotech Inc. | Systems, methods, and computer program products for supporting multiple contactless applications using different security keys |
US8451122B2 (en) | 2008-08-08 | 2013-05-28 | Tyfone, Inc. | Smartcard performance enhancement circuits and systems |
US7961101B2 (en) | 2008-08-08 | 2011-06-14 | Tyfone, Inc. | Small RFID card with integrated inductive element |
US8131645B2 (en) | 2008-09-30 | 2012-03-06 | Apple Inc. | System and method for processing media gifts |
US8140418B1 (en) | 2009-01-09 | 2012-03-20 | Apple Inc. | Cardholder-not-present authorization |
US10992817B2 (en) | 2009-03-18 | 2021-04-27 | Mastercard International Incorporated | Methods, systems and computer readable media for selecting and delivering electronic value certificates using a mobile device |
US8438073B2 (en) | 2009-06-23 | 2013-05-07 | At&T Mobility Ii Llc | Flexible mobile gift cards |
US8396808B2 (en) | 2009-07-31 | 2013-03-12 | Think Computer Corporation | Method and system for transferring an electronic payment |
EP2550634A4 (fr) | 2010-03-22 | 2014-11-12 | Mastercard International Inc | Procédés, systèmes et supports exploitables par ordinateur permettant de suivre un certificat électronique liberé et des données client associées à un dispositif mobile |
EP2556596B1 (fr) | 2010-04-05 | 2018-05-23 | Mastercard International Incorporated | Systèmes, procédés et supports de stockage lisibles par un ordinateur, adaptés pour exécuter une pluralité de transactions via une connexion de communication en champ proche (nfc) unique |
EP2617219B1 (fr) | 2010-09-14 | 2019-02-20 | Mastercard International Incorporated | Communication en champ proche sécurisée de la charge de données utiles d'un élément de mémoire non sécurisé |
US8799087B2 (en) | 2010-10-27 | 2014-08-05 | Mastercard International Incorporated | Systems, methods, and computer readable media for utilizing one or more preferred application lists in a wireless device reader |
KR20150094792A (ko) * | 2010-12-30 | 2015-08-19 | 모지도코화이어코리아 유한회사 | 모바일 지갑 및 그의 관련 정보 관리 시스템 및 방법 |
US8584224B1 (en) * | 2011-04-13 | 2013-11-12 | Symantec Corporation | Ticket based strong authentication with web service |
US20120323664A1 (en) | 2011-06-16 | 2012-12-20 | Apple Inc. | Integrated coupon storage, discovery, and redemption system |
WO2013110084A1 (fr) * | 2012-01-19 | 2013-07-25 | Mastercard International Incorporated | Système et procédé pour activer un réseau de portefeuilles numériques |
US20130311382A1 (en) * | 2012-05-21 | 2013-11-21 | Klaus S. Fosmark | Obtaining information for a payment transaction |
US20130346302A1 (en) * | 2012-06-20 | 2013-12-26 | Visa International Service Association | Remote Portal Bill Payment Platform Apparatuses, Methods and Systems |
WO2014011453A2 (fr) | 2012-07-09 | 2014-01-16 | Jvl Ventures, Llc | Systèmes, procédés et produits programmes d'ordinateur pour intégrer des services tiers avec un portefeuille mobile |
WO2014113183A1 (fr) * | 2013-01-17 | 2014-07-24 | Intel IP Corporation | Authentification d'url de contenu pour un protocole dash |
WO2015066066A1 (fr) * | 2013-10-28 | 2015-05-07 | Futurewei Technologies, Inc. | Système et procédé de signalisation et de vérification de signatures d'url pour à la fois l'authentification d'url et l'autorisation d'accès de contenu à base d'url dans une transmission en continu adaptative |
-
2013
- 2013-07-02 WO PCT/US2013/049137 patent/WO2014011453A2/fr active Application Filing
- 2013-07-02 US US13/934,008 patent/US20140012750A1/en not_active Abandoned
- 2013-07-02 US US13/934,014 patent/US9563891B2/en active Active
- 2013-07-02 WO PCT/US2013/049139 patent/WO2014011454A2/fr active Application Filing
-
2017
- 2017-01-12 US US15/404,439 patent/US10387873B2/en active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020065774A1 (en) * | 1999-11-30 | 2002-05-30 | Alan Young | System and method for performing an electronic transaction using a transaction proxy with an electronic wallet |
US20050187873A1 (en) * | 2002-08-08 | 2005-08-25 | Fujitsu Limited | Wireless wallet |
US20070125838A1 (en) * | 2005-12-06 | 2007-06-07 | Law Eric C W | Electronic wallet management |
US20080010193A1 (en) * | 2006-07-06 | 2008-01-10 | Firethorn Holdings, Llc | Methods and Systems For Payment Method Selection by a Payee in a Mobile Environment |
US20110270748A1 (en) * | 2010-04-30 | 2011-11-03 | Tobsc Inc. | Methods and apparatus for a financial document clearinghouse and secure delivery network |
US20120095852A1 (en) * | 2010-10-15 | 2012-04-19 | John Bauer | Method and system for electronic wallet access |
Cited By (55)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9165125B2 (en) * | 2012-06-13 | 2015-10-20 | Mobilextension Inc. | Distribution of dynamic structured content |
US20130340043A1 (en) * | 2012-06-13 | 2013-12-19 | Mehrdad (John) Zarei | Distribution of dynamic structured content |
US10387873B2 (en) | 2012-07-09 | 2019-08-20 | Google Llc | Systems, methods, and computer program products for integrating third party services with a mobile wallet |
US9563891B2 (en) | 2012-07-09 | 2017-02-07 | Google Inc. | Systems, methods, and computer program products for integrating third party services with a mobile wallet |
WO2015009529A1 (fr) | 2013-07-17 | 2015-01-22 | Jvl Ventures, Llc | Systèmes, procédés et produits programmes d'ordinateur pour la remise de données de transaction sans contact |
US9509515B2 (en) * | 2013-12-17 | 2016-11-29 | Samsung Electronics Co., Ltd. | Method and apparatus for registering devices capable of device-to-device communication in server |
US20150172061A1 (en) * | 2013-12-17 | 2015-06-18 | Samsung Electronics Co., Ltd. | Method and apparatus for registering devices capable of device-to-device communication in server |
US11574300B1 (en) | 2014-04-30 | 2023-02-07 | Wells Fargo Bank, N.A. | Mobile wallet systems and methods using trace identifier using card networks |
US11593789B1 (en) | 2014-04-30 | 2023-02-28 | Wells Fargo Bank, N.A. | Mobile wallet account provisioning systems and methods |
US11935045B1 (en) | 2014-04-30 | 2024-03-19 | Wells Fargo Bank, N.A. | Mobile wallet account provisioning systems and methods |
US11928668B1 (en) | 2014-04-30 | 2024-03-12 | Wells Fargo Bank, N.A. | Mobile wallet using tokenized card systems and methods |
US11748736B1 (en) * | 2014-04-30 | 2023-09-05 | Wells Fargo Bank, N.A. | Mobile wallet integration within mobile banking |
US11663599B1 (en) | 2014-04-30 | 2023-05-30 | Wells Fargo Bank, N.A. | Mobile wallet authentication systems and methods |
US9652770B1 (en) | 2014-04-30 | 2017-05-16 | Wells Fargo Bank, N.A. | Mobile wallet using tokenized card systems and methods |
US11651351B1 (en) | 2014-04-30 | 2023-05-16 | Wells Fargo Bank, N.A. | Mobile wallet account provisioning systems and methods |
US11645647B1 (en) | 2014-04-30 | 2023-05-09 | Wells Fargo Bank, N.A. | Mobile wallet account balance systems and methods |
US11615401B1 (en) | 2014-04-30 | 2023-03-28 | Wells Fargo Bank, N.A. | Mobile wallet authentication systems and methods |
US11610197B1 (en) | 2014-04-30 | 2023-03-21 | Wells Fargo Bank, N.A. | Mobile wallet rewards redemption systems and methods |
US11587058B1 (en) | 2014-04-30 | 2023-02-21 | Wells Fargo Bank, N.A. | Mobile wallet integration within mobile banking |
US11568389B1 (en) | 2014-04-30 | 2023-01-31 | Wells Fargo Bank, N.A. | Mobile wallet integration within mobile banking |
US11461766B1 (en) | 2014-04-30 | 2022-10-04 | Wells Fargo Bank, N.A. | Mobile wallet using tokenized card systems and methods |
US11423393B1 (en) | 2014-04-30 | 2022-08-23 | Wells Fargo Bank, N.A. | Mobile wallet account balance systems and methods |
US11410161B1 (en) | 2014-04-30 | 2022-08-09 | Wells Fargo Bank, N.A. | Mobile wallet systems and methods |
US11295294B1 (en) | 2014-04-30 | 2022-04-05 | Wells Fargo Bank, N.A. | Mobile wallet account provisioning systems and methods |
US11288660B1 (en) | 2014-04-30 | 2022-03-29 | Wells Fargo Bank, N.A. | Mobile wallet account balance systems and methods |
US10997592B1 (en) | 2014-04-30 | 2021-05-04 | Wells Fargo Bank, N.A. | Mobile wallet account balance systems and methods |
US20160018954A1 (en) * | 2014-07-17 | 2016-01-21 | Samsung Electronics Co., Ltd | Data processing method and electronic device thereof |
US20160156600A1 (en) * | 2014-07-18 | 2016-06-02 | Bank Of America Corporation | Methods for universal resource identifier (‘uri’) integration |
US20160140361A1 (en) * | 2014-07-18 | 2016-05-19 | Bank Of America Corporation | Methods for anti-fraud masking of a universal resource indentifier ("uri') |
US20160021065A1 (en) * | 2014-07-18 | 2016-01-21 | Bank Of America Corporation | Method and apparatus for masking non-public data elements in uniform resource indentifiers ("uri") |
US9680800B2 (en) * | 2014-07-18 | 2017-06-13 | Bank Of America Corporation | Methods for universal resource identifier (“URI”) integration |
US9674160B2 (en) * | 2014-07-18 | 2017-06-06 | Bank Of America Corporation | Methods for anti-fraud masking of a universal resource indentifier (“URI”) |
US9344409B2 (en) * | 2014-07-18 | 2016-05-17 | Bank Of America Corporation | Method and apparatus for masking non-public data elements in uniform resource indentifiers (“URI”) |
US11132693B1 (en) | 2014-08-14 | 2021-09-28 | Wells Fargo Bank, N.A. | Use limitations for secondary users of financial accounts |
US10445739B1 (en) | 2014-08-14 | 2019-10-15 | Wells Fargo Bank, N.A. | Use limitations for secondary users of financial accounts |
US10498847B2 (en) * | 2015-02-11 | 2019-12-03 | Go Daddy Operating Company, LLC | System and method for mobile application deep linking |
US20160234330A1 (en) * | 2015-02-11 | 2016-08-11 | Go Daddy Operating Company, LLC | System and method for mobile application deep linking |
US11853919B1 (en) | 2015-03-04 | 2023-12-26 | Wells Fargo Bank, N.A. | Systems and methods for peer-to-peer funds requests |
CN105357261A (zh) * | 2015-09-29 | 2016-02-24 | 腾讯科技(深圳)有限公司 | 服务处理方法及服务处理装置 |
US20190121946A1 (en) * | 2016-04-05 | 2019-04-25 | Carrier Corporation | Credential licensing service |
US11516664B2 (en) * | 2016-04-05 | 2022-11-29 | Carrier Corporation | Credential licensing service |
CN108885651A (zh) * | 2016-04-05 | 2018-11-23 | 开利公司 | 凭证许可服务 |
US11734657B1 (en) | 2016-10-03 | 2023-08-22 | Wells Fargo Bank, N.A. | Systems and methods for establishing a pull payment relationship |
US11468414B1 (en) | 2016-10-03 | 2022-10-11 | Wells Fargo Bank, N.A. | Systems and methods for establishing a pull payment relationship |
US10348503B2 (en) * | 2016-12-12 | 2019-07-09 | Sap Portals Israel Ltd. | Client side actions validation |
US20180167214A1 (en) * | 2016-12-12 | 2018-06-14 | Sap Portals Israel Ltd. | Client side actions validation |
US10277688B2 (en) | 2017-01-04 | 2019-04-30 | Microsoft Technology Licensing, Llc | Automatic installation activation selection for hosted services |
US11295297B1 (en) | 2018-02-26 | 2022-04-05 | Wells Fargo Bank, N.A. | Systems and methods for pushing usable objects and third-party provisioning to a mobile wallet |
US11775955B1 (en) | 2018-05-10 | 2023-10-03 | Wells Fargo Bank, N.A. | Systems and methods for making person-to-person payments via mobile client application |
US11074577B1 (en) | 2018-05-10 | 2021-07-27 | Wells Fargo Bank, N.A. | Systems and methods for making person-to-person payments via mobile client application |
WO2020125775A1 (fr) * | 2018-12-20 | 2020-06-25 | 深圳市愚公科技有限公司 | Procédé et appareil de traitement d'informations de service de client en ligne à plusieurs parties de service |
US11948134B1 (en) | 2019-06-03 | 2024-04-02 | Wells Fargo Bank, N.A. | Instant network cash transfer at point of sale |
CN110610360A (zh) * | 2019-09-09 | 2019-12-24 | 飞天诚信科技股份有限公司 | 一种硬件钱包绑定授权的方法及装置 |
CN111507727A (zh) * | 2020-04-20 | 2020-08-07 | 车主邦(北京)科技有限公司 | 无感支付的安全性控制方法 |
US11995621B1 (en) | 2021-10-22 | 2024-05-28 | Wells Fargo Bank, N.A. | Systems and methods for native, non-native, and hybrid registration and use of tags for real-time services |
Also Published As
Publication number | Publication date |
---|---|
US20170124559A1 (en) | 2017-05-04 |
WO2014011454A3 (fr) | 2014-04-17 |
US20140012751A1 (en) | 2014-01-09 |
WO2014011454A2 (fr) | 2014-01-16 |
WO2014011453A2 (fr) | 2014-01-16 |
WO2014011453A3 (fr) | 2014-04-24 |
US9563891B2 (en) | 2017-02-07 |
US10387873B2 (en) | 2019-08-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10387873B2 (en) | Systems, methods, and computer program products for integrating third party services with a mobile wallet | |
CN107430657B (zh) | 通过代理的认证 | |
EP1710980B1 (fr) | Services d'authentification avec un appareil mobile | |
TWI605397B (zh) | 用於金融交易之安全元件及攜帶型電子裝置 | |
US9799029B2 (en) | Securely receiving data input at a computing device without storing the data locally | |
US8943124B2 (en) | Systems and methods for customizing mobile applications based upon user associations with one or more entities | |
JP2014529964A (ja) | モバイル機器経由の安全なトランザクション処理のシステムおよび方法 | |
CN112789643A (zh) | 用于非接触式卡的密码认证的系统和方法 | |
CN110692073B (zh) | 基于通知的卡账户的配置 | |
EP2928146B1 (fr) | Protection contre les fuites de confidentialité | |
US11176539B2 (en) | Card storage handler for tracking of card data storage across service provider platforms | |
US20150262164A1 (en) | Cloud-based secure storage | |
US10546292B1 (en) | Systems and methods for substitute low-value tokens in secure network transactions | |
US11062098B1 (en) | Augmented reality information display and interaction via NFC based authentication | |
JP2023508051A (ja) | 制限された仮想番号を使用したカード発行 | |
CN115552440A (zh) | 增强现实卡激活体验 | |
EP3767567A1 (fr) | Système, procédé et appareil permettant d'intégrer plusieurs options de paiement sur une page web de commerçant | |
US9871890B2 (en) | Network authentication method using a card device | |
US20220327234A1 (en) | Method, system, and computer program product for securely rendering sensitive data | |
KR102550098B1 (ko) | 피어 거래 시스템 | |
KR20170029940A (ko) | 복수 한도 선택을 지원하는 웹 기반 결제 서비스 제공 장치 및 방법, 그리고 시스템 및 컴퓨터 프로그램이 기록된 기록매체 | |
CN113645239B (zh) | 一种应用登录方法、装置、用户终端及存储介质 | |
US20230394559A1 (en) | Order information for electronic devices | |
KR20170029942A (ko) | 웹 기반 인증을 이용한 결제 서비스 제공 장치 및 방법, 그리고 시스템 및 컴퓨터 프로그램이 기록된 기록매체 | |
KR20170029943A (ko) | 웹 기반 거래 검증을 지원하는 결제 서비스 제공 장치 및 방법, 그리고 시스템 및 컴퓨터 프로그램이 기록된 기록매체 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: JVL VENTURES, LLC, NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KUHN, STEPHEN;LIPTON, DANIEL L.;JOHNSON, KAI P.;AND OTHERS;REEL/FRAME:030731/0318 Effective date: 20130702 |
|
AS | Assignment |
Owner name: GOOGLE INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:JVL VENTURES, LLC;REEL/FRAME:035463/0544 Effective date: 20150220 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: GOOGLE LLC, CALIFORNIA Free format text: CHANGE OF NAME;ASSIGNOR:GOOGLE INC.;REEL/FRAME:044144/0001 Effective date: 20170929 |