Claims:CLAIMS
We claim:

1. A computer-implemented method, comprising:
in response to receipt of a wireless signal at a user device associated with a user from a payment wireless access point, receiving, by a server system, an authentication token from the user device to access a wireless network associated with the payment wireless access point, the payment wireless access point configured to facilitate payment transactions for a plurality of merchants located in proximity to a geographic location of the payment wireless access point;
determining, by the server system, authenticity of the user based, at least in part, on the authentication token;
upon determining that the user is authentic, displaying, by the server system, unique merchant identifiers associated with the plurality of merchants on a user interface of an application accessible on the user device;
receiving, by the server system via the payment wireless access point, an indication of consent of the user to perform a payment transaction with a merchant of the plurality of merchants;
receiving, by the server system, payment transaction data associated with the payment transaction from the user device via the payment wireless access point; and
processing, by the server system, the payment transaction data associated with the payment transaction for facilitating the payment transaction between the merchant and the user.

2. The computer-implemented method as claimed in claim 1, wherein the payment transaction data comprises a merchant private key associated with the merchant, a user private key associated with the user, and a transaction amount.

3. The computer-implemented as claimed in claim 2, further comprising:
generating, by the server system, a payment transaction request based, at least in part, on the payment transaction data and merchant information retrieved based at least on the merchant private key and an access point identifier of the payment wireless access point;
encrypting, by the server system, the payment transaction request based, at least in part, on a combination of the merchant private key and the user private key; and
transmitting, by the server system, the payment transaction request to a payment server associated with a payment network via an acquirer server associated with the merchant.

4. The computer-implemented method as claimed in claim 1, further comprising:
receiving, by the server system, a data structure from an acquirer server associated with the merchant upon receiving a request for registration by the acquirer server for accepting payment transactions via the payment wireless access point, the data structure comprising an association between a unique merchant identifier of the merchant with an access point identifier corresponding to the payment wireless access point.

5. The computer-implemented method as claimed in claim 1, wherein the plurality of merchants is registered under the payment wireless access point.

6. The computer-implemented method as claimed in claim 1, further comprising:
comparing, by the server system, the received authentication token against user records stored within a database; and
authenticating, by the server system, the user to access the wireless network of the payment wireless access point based at least on the comparing step.

7. The computer-implemented method as claimed in claim 1, wherein the wireless network is implemented using Wi-Fi based technology.

8. The computer-implemented method as claimed in claim 1, wherein the indication of consent of the user is generated upon selection of the merchant from the plurality of merchants.

9. The computer-implemented method as claimed in claim 1, wherein the server system is a part of a payment network.

10. A server system configured to perform the computer-implemented method as claimed in any of the claims 1-9.
, Description:
FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules 2003
COMPLETE SPECIFICATION
(refer section 10 & rule 13)

1. TITLE OF THE INVENTION:
METHODS AND SYSTEMS FOR PAYMENT TRANSACTIONS THROUGH A WIRELESS ACCESS POINT SHARED AMONG MERCHANTS

2. APPLICANT(S):

(a) Name:

(b) Nationality:

(c) Address:

MASTERCARD INTERNATIONAL INCORPORATED

United States of America

2000 Purchase Street, Purchase, NY 10577, United States of America

3. PREAMBLE TO THE DESCRIPTION

The following specification particularly describes the invention and the manner in which it is to be performed.

4. DESCRIPTION
(See next page)

 
METHODS AND SYSTEMS FOR PAYMENT TRANSACTIONS THROUGH A WIRELESS ACCESS POINT SHARED AMONG MERCHANTS

TECHNICAL FIELD
[0001] The present disclosure relates to electronic payment systems and, more particularly relates to, electronic methods and systems for facilitating payment transactions at a merchant through a payment wireless access point shared among merchants.

BACKGROUND
[0002] Customers visit at a merchant store and make purchases at a merchant location via various ways. In one way, the customers purchase goods and transact with the merchants using payment cards through Point of Sale (POS) machines at the merchant store. In another way, the customers can use digital wallets linked with their bank account numbers that require strong internet connection in the customer devices. Further, the payment transactions at the merchant store can also be performed by scanning merchant QR codes using customer devices. Now-a-days, it is evident that chances of fraud have been quite increased due to QR cloning methods for QR based payment transactions. The QR cloning methods were used by a local merchant intentionally to steal the payment card information of the customers visiting at his/her store. This leads to lack of credibility on the digital wallet and QR based transactions since wallet identifiers and QR codes are public in nature which can be easily compromised. Further, there are no single prerequisite security check while reading the QR codes and Wallet identifiers.
[0003] Thus, there exists a technological need to overcome the above-stated limitations.

SUMMARY
[0004] Various embodiments of the present disclosure provide methods and systems for performing wireless payment transactions at a merchant through a shared payment wireless access point.
[0005] In an embodiment, a computer-implemented method is disclosed. The computer-implemented method performed by a server system includes receiving an authentication token from a user device to access a wireless network associated with a payment wireless access point in response to the receipt of a wireless signal at the user device associated with a user from the payment wireless access point. The payment wireless access point is configured to facilitate payment transactions for a plurality of merchants located in proximity to a geographic location of the payment wireless access point. The method includes determining authenticity of the user based, at least in part, on the authentication token and displaying unique merchant identifiers associated with the plurality of merchants on a user interface of an application accessible on the user device upon determining that the user is authentic. The method includes receiving, via the payment wireless access point, an indication of consent of the user to perform a payment transaction with a merchant of the plurality of merchants. The method further includes receiving payment transaction data associated with the payment transaction from the user device via the payment wireless access point and processing the payment transaction data associated with the payment transaction for facilitating the payment transaction between the merchant and the user.

BRIEF DESCRIPTION OF THE FIGURES
[0006] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
[0007] FIG. 1 is an example representation of an environment, related to at least some example embodiments of the present disclosure;
[0008] FIG. 2A represents a sequence flow diagram for merchant enrolment process for accepting payment transactions via shared payment wireless access point, in accordance with an example embodiment of the present disclosure;
[0009] FIG. 2B represents a sequence flow diagram for customer enrolment process for performing payment transactions to a merchant via shared payment wireless access point, in accordance with an embodiment of the present disclosure;
[0010] FIG. 3 represents a sequence flow diagram for a process flow for performing payment transactions to a merchant via shared payment wireless access point, in accordance with an embodiment of the present disclosure;
[0011] FIG. 4 represents a flowchart illustrating a method of authorizing an electronic payment transaction through a shared payment wireless access point, in accordance with an embodiment of the present disclosure;
[0012] FIGS. 5A, 5B, and 5C, collectively, represent a series of exemplary graphical user interfaces (GUIs) implemented on a user device to initiate payment transactions to merchants via shared payment wireless access point, in accordance with an embodiment of the present disclosure;
[0013] FIG. 6 represents a flow diagram of a computer-implemented method for performing payment transactions between a user and a merchant using a wireless network associated with a payment wireless access point, in accordance with an embodiment of the present disclosure;
[0014] FIG. 7 is a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure;
[0015] FIG. 8 is a simplified block diagram of an acquirer server, in accordance with an embodiment of the present disclosure;
[0016] FIG. 9 is a simplified block diagram of an issuer server, in accordance with one embodiment of the present disclosure; and
[0017] FIG. 10 is a simplified block diagram of a user device capable of implementing the various embodiments of the present disclosure.
[0018] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.

DETAILED DESCRIPTION
[0019] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details.
[0020] Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearances of the phrase “in an embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
[0021] Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
[0022] The term “issuer”, used throughout the description, refers to a financial institution normally called as an "issuer bank" or "issuing bank" in which an individual or an institution may have an account. The issuer also issues a payment card, such as a credit card or a debit card, etc. Further, the issuer may also facilitate online banking services such as electronic money transfer, bill payment, etc., to the account holders through a server system called as “issuer server” throughout the description.
[0023] Further, the term "acquirer" is an organization that transmits a purchase transaction to a payment card system for routing to the issuer of the payment card account in question. Typically, the acquirer has an agreement with merchants, wherein the acquirer receives authorization requests for purchase transactions from the merchants, and routes the authorization requests to the issuers of the payment cards being used for the purchase transactions. The terms “acquirer”, “acquiring bank”, “acquiring bank” or “acquirer bank” will be used interchangeably herein. Further, one or more server systems associated with the acquirer are referred to as "acquirer server" to carry out its functions.
[0024] The term "payment account" used throughout the description refers to a financial account that is used to fund the financial transaction (interchangeably referred to as "payment transaction"). Examples of the payment account include, but are not limited to a savings account, a credit account, an e-wallet account, a checking account and a virtual payment account. The payment account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization and the like. In some scenarios, a payment account may be a virtual or temporary payment account that can be mapped or linked to a primary payment account, such as those accounts managed by payment wallet service providers.
[0025] The term "payment network", used throughout the description, refers to a network or collection of systems used for transfer of funds through use of cash-substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. The transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. The payment networks may be operated to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. One example of a payment network includes those operated by Mastercard.
[0026] The term "payment card", used throughout the description, refers to a physical or virtual card linked with a financial or payment account that may be used to fund a financial transaction to a merchant or any such facility via the associated payment account. Examples of the payment card include, but are not limited to, debit cards, credit cards, prepaid cards, virtual payment numbers, virtual card numbers, forex cards, charge cards and stored-value cards. A payment card may be a physical card that may be presented to the merchant for funding the payment. Alternatively, or additionally, the payment card may be embodied in form of data (e.g., a digital token) stored in a user device, where the data is associated with the payment account such that the data can be used to process the financial transaction between the payment account and a merchant's financial account.
[0027] The term "Tokenization", used throughout the description, refers to a process by which data is replaced with substitute data. For example, a payment account identifier (e.g., a primary account number (PAN)) may be tokenized by replacing the primary account identifier with a substitute number (e.g. a token) that may be associated with the payment account identifier. Further, tokenization may be applied to any other-information which may be replaced with a substitute value (i.e., token). Tokenization may be used to enhance transaction efficiency, improve transaction security, increase service transparency, or to provide a method for third-party enablement.
[0028] The term "merchant", used throughout the description, may include a merchant that has a relationship with the payment processing network. The merchant may receive the proceeds from a purchase when the purchase is settled. The merchant is the company that is ultimately responsible for the financial transaction.
[0029] A "token" may include a substitute for an account identifier such as a primary account number. Tokens are used in lieu of the primary account number and can be used to generate original and subsequent transactions for an entire transaction lifecycle. A token may be in a format that is similar to a primary account number. For example, if a real primary account number has 16 digits, then a corresponding payment token may also have 16 digits. In some embodiments, a token may also be in a different format than a primary account number. A token may also be referred to as a “temporary credential.”
OVERVIEW
[0030] Various example embodiments of the present disclosure provide methods, systems, user devices, and computer program products for performing payment transaction through a shared payment wireless access point among a plurality of merchants. The present disclosure allows small merchants to utilize the shared payment wireless access point which emits wireless signals (e.g., Radio QR-specific to each merchant). The term “Radio QR” represents a wireless signal that facilitates a connection between the merchant and a user upon getting access to the wireless network of the payment wireless access point. To perform the payment transactions through the shared payment wireless access point, the user can put his/her user device in an offline mode. In one embodiment, a plurality of merchants located in a geo-graphic location can be registered under an access point identifier of an installed payment wireless access point. Each merchant is assigned a unique merchant identifier (i.e., merchant private key) on the wireless network of the payment wireless access point by associated acquirer in order to provide consent to get their payments facilitated through the wireless network.
[0031] While making the payments for the first time at the merchant, the user switches on his/her devices in Wi-Fi mode and provides issuer public key and user private key to get access to the wireless network of the payment wireless access point. Once the user is connected with the payment wireless access point, the user can select merchant name written adjacent to merchant private key from a list of merchants and establish merchant-user specific payment connection. The user then provides the transaction amount to be paid to the merchant. The user device encrypts payment transaction data with a combination of the merchant private key of the merchant and the user private key of the user. In similar way, the user can make any card based transactions by just being connected through the payment wireless access point to other merchants registered under the payment wireless access point.
[0032] In various example embodiments, the present disclosure describes a method to perform offline payment transactions through payment wireless access points. The method includes at least a server system, a processor and a memory. Upon receiving a wireless signal from a payment wireless access point at a user device, the server system is configured to receive an authentication token from the user device to access a wireless network associated with the payment wireless access point. The payment wireless access point is configured to facilitate payment transactions for a plurality of merchants located in proximity to a geographic location of the payment wireless access point. The plurality of merchants is registered under the payment wireless access point. The server system is configured to determine authenticity of the user based on the authentication token provided by the user. The authenticity is determined by comparing the received authentication token against user records stored within the database and authenticating the user to access the wireless network of the payment wireless access point based at least on the comparison.
[0033] In one embodiment, the server system is configured to display unique merchant identifiers associated with the plurality of merchants on a user interface of an application accessible on the user device upon determining that the user is authentic. The server system is configured to receive an indication of consent of the user to perform a payment transaction with a merchant of the plurality of merchants through the payment wireless access point. The indication of consent of the user is generated upon selection of the merchant from the plurality of merchants.
[0034] Thereafter, the server system is configured to receive payment transaction data associated with the payment transaction from the user device via the payment wireless access point. The payment transaction data includes merchant private key associated with the merchant, user private key associated with the user, and a transaction amount. In one embodiment, the server system is configured to generate a payment transaction request based on payment transaction data and merchant information retrieved based at least on the merchant private key and an access point identifier of the payment wireless access point. The server system is configured to encrypt the payment transaction request based on a combination of the merchant private key and the user private key and transmit the payment transaction request to a payment server associated with a payment network via an acquirer server associated with the merchant.
[0035] During merchant registration for accepting payment transactions through shared payment wireless access points, the server system is also configured to receive a data structure from an acquirer server associated with the merchant. The data structure includes an association between a unique merchant identifier of the merchant with an access point identifier corresponding to the payment wireless access point. Thereafter, server system is configured to process the payment transaction data associated with the payment transaction for facilitating the payment transaction between the merchant and the user.
[0036] Various embodiments of the present disclosure offer multiple technical advantages and technical effects. For instance, the present disclosure provides an intranet of payments which is a closed loop environment facilitating the card payments in a more secured and credible manner. The present disclosure enables one time enrollment where the customer need not go through each step in the enrollment process when the user revisits the merchant locality and the user will automatically be connected to the port by turning on the Wi-Fi mode and can easily transfer the money to any merchant registered under the payment wireless access point. The present disclosure enables registering of plurality of merchants under one access point identifier with different private keys for each merchant which prevents cloning of ID/QR of the merchant. The present disclosure enables easy mapping of fraud in the transaction as the network has the both merchant private key and user private key and it is very easy to know in which bank branch the user is based in. The present disclosure enables non-dependency of any internet connection, physical QR’s, KYC, etc. Further, the present disclosure enables further commercialization to bigger merchants too where they are in a narrow range of distance. For example, installation of wireless access points in shopping malls, Narrow Market chains, etc. which will make the overall transaction experience more seamless, frictionless, and completely contactless.
[0037] Various example embodiments of the present disclosure are described hereinafter with reference to FIGS. 1 to 10.
[0038] FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some example embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, performing payment transactions between a user and a merchant using a wireless network associated with a payment wireless access point. The environment 100 generally includes a server system 102, a user device 104 associated with a user 106, a plurality of merchants 108a, 108b, and 108c positioned at a particular geo-location, a payment wireless access point 110, a payment network 112 including a payment server 114, an issuer server 116, and an acquirer server 118, each coupled to, and in communication with a network 120. The network 120 may include, without limitation, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts illustrated in FIG. 1, or any combination thereof.
[0039] Various entities in the environment 100 may connect to the network 120 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G) communication protocols, Long Term Evolution (LTE) communication protocols, future communication protocols or any combination thereof. For example, the network 120 may include multiple different networks, such as a private network made accessible by the server system 102 and a public network (e.g., the Internet etc.) through which the server system 102, the payment server 114, the plurality of merchants 108a-108c, the issuer server 116, the acquirer server 118 and the user device 104 may communicate.
[0040] In one embodiment, the user 106 may be any individual, representative of a corporate entity, non-profit organization, or any other person. Examples of the user device 104 associated with the user 106 may include, without limitation, smart phone, tablet computer, other handheld computers, wearable devices, laptop computers, desktop computers, servers, portable media players, gaming devices, and so forth. The user device 104 may installed with a banking application associated with the issuer server 116 of the user 106. In one embodiment, the user device 104 may be installed with an application 124 that is configured to integrate various APIs for performing payment transactions via payment wireless access points after successful registration for enabling such payment transactions with the issuer server 116. The term “application” is used broadly to include any software program(s) capable of implementing the features described herein. In one example, the application 124 is an issuer application.
[0041] In some embodiments, the application 124 may include any API, service, application, applet, or other executable code suitable to retrieve payment information from a secure element, generate payment information (e.g., a dynamic value, etc.) for a payment transaction, and communicate with a server system application, merchant application, mobile gateway, and/or any other application in order to securely communicate with a server computer (e.g., remote key manager, mobile gateway, payment processing network, third party service provider, etc.). The application may include or be configured to obtain stored information including user private key, payment credentials, third party keys, mobile gateway credentials, and may be capable of communicating with an issuer to obtain issuer updates.
[0042] In one embodiment, the issuer server 116 is a financial institution that manages accounts of multiple users. Account details of the accounts established with the issuer bank are stored in PAN profiles of the users such as user 106 in a memory of the issuer server 116 or on a cloud server associated with the issuer server 116. The terms “issuer server”, “issuer”, or “issuing bank” will be used interchangeably herein.
[0043] In one embodiment, the plurality of merchants 108a, 108b, and 108c represents authorized accepters of payment cards for the payments for good/services sold by the plurality of merchants. In one embodiment, the acquirer server 118 is associated with a financial institution (e.g., a bank) that processes financial transactions. This can be an institution that facilitates the processing of payment transactions for physical stores, ATM terminals, merchants, or an institution that owns platforms that make online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers). The terms “acquirer”, “acquirer bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
[0044] In one non-limiting example, to initiate a payment transaction, a customer (i.e., user 106) may visit a retail store operated by a merchant, select goods that he/she wishes to purchase, and scans QR code displayed at the merchant for facilitating payment transactions via the banking application on the user device 104. The user device 104 reads the QR code and extracts merchant account information to generate a payment authorization request. The payment authorization request typically includes payment card account number, the amount of the transaction and other information, such as merchant identification and location. The payment authorization request message is routed via the payment network 112 to the issuer server 116 that issued the user's payment card. In addition to QR based transactions, the acquirer server 118 may process payment transactions associated with Automated Teller Machine (“ATM”) withdrawals and Card Present transactions in a similar manner.
[0045] In one embodiment, the payment wireless access point 110 is a physical device that is installed at a nearby location to the plurality of merchants 108a-108c. The payment wireless access point 110 broadcasts wireless signals associated with a wireless network 122. The physical device works as a bridge communication entity between the user device 104 and a merchant 108a for accepting payment transactions for the merchant 108a. In one embodiment, the payment wireless access point 110 may be installed by an administrator associated with the payment network 112. Although described as a unique component, it should be noted that the payment wireless access point 110 could be implemented as a plurality of devices or integrated into other devices. The payment wireless access point 110 includes short-range communication capability (e.g., Wi-Fi mechanisms). Although the present disclosure is described herein with reference to Wi-Fi mechanisms, the invention is not so limited. For example, Wi-Fi is expected to be replaced in the near future with WiMAX, and WiMAX gateways will be deployed as Wi-Fi, not GSM. Thus, a linked network in accordance with the teaching herein has the potential to soon become the largest global network of hotspots in the world and will be able to compete with the large-scaled cellular telephone service providers and hotspot operators.
[0046] In one embodiment, the payment wireless access point 110 includes a network memory containing information of a set of merchants who are registered under the payment wireless access point 110 with their properly allocated merchant private keys by respective acquirers. The payment wireless access point 110 may also store instructions of transmitting data (e.g., API URLs) to the server system 102.
[0047] In one embodiment, the server system 102 is configured to perform one or more operations described herein. In one example, the server system 102 coupled with a database 126 is embodied in the payment network 112. In general, the server system 102 is configured to facilitate accepting payment transactions for the plurality of merchants. The server system 102 is configured in a manner (described in connection with next set of figures) that enables shared Wi-Fi hotspot to operate as a shared Wi-Fi port among the plurality of merchants. Thus, the server system 102 is configured to facilitate the payment transactions with no POS terminal, no physical card, and non-dependency of internet connection in the user device 104 for the merchant 108a to accept the card-based payments in a seamless fashion.
[0048] The server system 102 is a separate part of the environment 100, and may operate apart from (but still in communication with, for example, via the network 120) the payment server 114, the issuer server 116, the acquirer server 118, and any third party external servers (to access data to perform the various operations described herein). However, in other embodiments, the server system 102 may actually be incorporated, in whole or in part, into one or more parts of the environment 100, for example, the payment server 114, the issuer server 116, or the acquirer server 118. In addition, the server system 102 should be understood to be embodied in at least one computing device in communication with the network 120, which may be specifically configured, via executable instructions, to perform as described herein, and/or embodied in at least one non-transitory computer readable media. In one embodiment, the server system 102 is connected with a database 126. The database 126 is configured to store instructions for performing payment transactions through the wireless network 122 of the payment wireless access point 110.
[0049] In one embodiment, the payment network 112 may be used by the payment cards issuing authorities as a payment interchange network. The payment network 112 may include a plurality of payment servers such as, the payment server 114. Examples of payment interchange network include, but are not limited to, Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of financial transactions among a plurality of financial activities that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.).
[0050] The number and arrangement of systems, devices, and/or networks shown in FIG. 1 are provided as an example. There may be additional systems, devices, and/or networks; fewer systems, devices, and/or networks; different systems, devices, and/or networks, and/or differently arranged systems, devices, and/or networks than those shown in FIG. 1. Furthermore, two or more systems or devices shown in FIG. 1 may be implemented within a single system or device, or a single system or device shown in FIG. 1 may be implemented as multiple, distributed systems or devices. Additionally, or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of the environment 100 may perform one or more functions described as being performed by another set of systems or another set of devices of the environment 100.
[0051] FIG. 2A represents a sequence flow diagram 200 for a merchant enrolment process for accepting payment transactions via shared payment wireless access point (e.g., payment wireless access point 110), in accordance with an example embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 200 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
[0052] At 202, the acquirer server 118 receives a request for registration of a merchant 108a for using the services of shared payment wireless access point 110 from a merchant device associated with the merchant 108a. The request for registration may be accompanied by merchant data or merchant information including, for example, merchant name, merchant location, merchant account number, types of goods/services provided by the merchant 108a. In one embodiment, the merchant 108a may access an acquirer application installed on the merchant device for sending the request for registration. In one example, in place of the merchant account number, a unique identifier associated with the merchant is sent to the acquirer server 118.
[0053] At 204, the acquirer server 118 may perform validation process for the merchant 108a based on the merchant data received in the request. The acquirer server 118 identifies identity data corresponding the merchant 108a that is maintained by the acquirer 118 based on the merchant account number or the unique identifier. In one embodiment, the acquirer server 118 may also connect with a third-party identity verification platform and perform a query-response information exchange between the acquirer server 118 and the third-party identity verification platform.
[0054] Responsive to successful validation of the request, at 206, the acquirer server 118 may search for nearby installed payment wireless access points in proximity to the location of the merchant 108a. In one embodiment, the acquirer server 118 sends a request to the server system 102 to identify the nearby payment wireless access points and in response, the server system 102 is configured to provide a unique access point identifier corresponding to a payment wireless access point 110 that is installed within a threshold distance from the location of the merchant 108a.
[0055] At 208, the acquirer server 118 generates a unique merchant identifier i.e., a merchant private key associated with the merchant 108a upon successful identifying the payment wireless access point 110. In other words, the acquirer server 118 provides consent to the merchant 108a to use the services of the payment wireless access point 110. In one embodiment, the acquirer server 118 may identify one or more shared payment wireless access points that the merchant 108a is authorized to use for accepting the payment transactions. In one embodiment, the merchant private key may serve as primary key or secondary key linking various data records associated with the merchant 108a.
[0056] At 210, the acquirer server 118 generates a data structure by associating of the unique merchant identifier of the merchant 108a with the unique access point identifier corresponding to the payment wireless access point 110. The data structure may include one or more of: (a) a data field for the unique merchant identifier, (b) merchant account data such as, merchant name, merchant account number, location, etc., and (c) the unique access point identifier of the payment wireless access point 110.
[0057] In other words, the acquirer server 118 registers the merchant 108a under the payment wireless access point 110.
[0058] At 212, the server system 102 receives the data structure from the acquirer server 118 to store the data structure in a database 126. The data structure represents a mapping of the merchant 108a with the payment wireless access point 110 that is configured to route payment authorization requests for the merchant 108a to the payment network 112. In other words, the data structure represents an association between a unique merchant identifier of the merchant with an access point identifier corresponding to the payment wireless access point
[0059] At 214, the acquirer server 118 transmits a confirmation message of successful registration to the merchant 108a, thereby facilitating accepting payment transactions for the merchant 108a via the shared payment wireless access point 110. The confirmation message includes transmission of the unique merchant identifier to merchant 108a for future access to the merchant account data.
[0060] FIG. 2B represents a sequence flow diagram 220 for customer enrolment process for performing payment transactions to a merchant via shared payment wireless access point (e.g., payment wireless access point 110), in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 220 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
[0061] At 222, the user device 104 associated with the user 106 sends a request for enrolment for enabling payment transactions at multiple merchants through a shared payment wireless access point 110. The enrolment request may include payment credential data and a request for enabling payment transactions via a wireless network 122 of the shared payment wireless access point 110.
[0062] At 224, the user 106 loads payment credential data into the application 124 in the user device 104. The payment credential data includes user information such as, but not limited to, a user id, a password, a primary account number (PAN one or more parameters), a name, an address, a phone number, a city, a postal code, and the like.
[0063] At 226, the issuer server 116 validates the payment credential data of the user 106. The issuer 116 validates to ensure that the user credentials provided by the user 106 is genuine and valid at the time of enrollment.
[0064] At 228, the issuer server 116 set issuer public key and user private key as a pass key for accessing a wireless network 122 of payment wireless access point 110. The private key associated with the user 106 maybe a debit card PIN or a credit card PIN associated with the user 106. In one embodiment, the issuer server 116 may provide a new private key when requested by the user 106. The public key associated with the issuer server 116 maybe a key set by a particular branch of the bank associated with the issuer server 116 of the user 106.
[0065] At 230, issuer server 116 provides issuer public key and user private key to the user 106. At 232, the issuer server 116 provides user details (e.g., user identifier, user private key, issuer public key, etc.) upon successful enrolment of the user 106 with the issuer server 116 to the server system 102.
[0066] FIG. 3 represents a sequence flow diagram 300 for a process flow for performing payment transactions to a merchant via shared payment wireless access point (e.g., payment wireless access point 110), in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 300 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in a sequential manner.
[0067] The sequence flow diagram 300 would be implemented when the user 106 seeking to make a payment transaction at a merchant 108a through a shared payment wireless access point 110 that the merchant 108a intends to use for the purpose of carrying out the proposed payment transaction.
[0068] At 302, the user 106 sets his/her user device 104 in Wi-Fi mode and operates the user device 104 in an offline mode. The term “offline” refers to non-internet, short-range communication distance (less than about 100 meters) based communications, e.g., Wi-Fi or Bluetooth communications. Due to availability of a short-range communication network in offline scenarios, the user device 104 can pair with available payment wireless access points.
[0069] At 304, the user 106 opens an application (e.g., the application 124, merchant application, etc.) on the user device 104 to display nearby payment wireless access points corresponding to a current location of the user 106. In particular, the user 106 switches on wireless payment API integrated with the application 124.
[0070] At 306, the user 106 identifies an access point identifier associated with the payment wireless access point 110 and selects the payment wireless access point 110 by clicking on corresponding selection field associated with the payment wireless access point 110 on the user device 104.
[0071] At 308, the user device 104 displays a user interface to request the user 106 to input issuer public key and user private key associated with the user 106.
[0072] Upon entering the issuer public key and the user private key on the user device 104, at 310, the user device 104 performs tokenization process over the issuer public key and the user private key to generate an authentication token for the user 106. The authentication token represents a hash value of a combination of the issuer public key and the user private key of the user 106.
[0073] At 312, the user device 104 transmits the authentication token to the payment wireless access point 110 to get access of the wireless network 122 associated with the payment wireless access point 110. At 314, the server system 102 receives the authentication token from the payment wireless access point 110.
[0074] At 316, the server system 102 authenticates identity of the user 106 based on the authentication token of the user 106. In one embodiment, the authentication is performed by comparing the received authentication token against user records stored within the database 126. The user 106 is authenticated to access the wireless network 122 if the received authentication token matches with a tokenized data of a stored entry in the database 126.
[0075] Upon successful authentication, at 318, the server system 102 transmits a list of merchant private keys and corresponding merchant names of the plurality of merchants 108a-108c registered under the unique access point identifier of the payment wireless access point 110, to the user device 104 via the wireless network 122.
[0076] At 320, the user device 104 displays a list of merchants registered under the unique access point identifier associated with the payment wireless access point 110. In one example, a merchant private key (for example, ‘12345’) of a merchant is displayed adjacent to the merchant name (for example, “PIZZA EXPRESS”) of the merchant.
[0077] At 322, the user 106 clicks on a selection field associated with the merchant 108a to whom the payment transaction is intended to perform by verifying the unique merchant identifier with the merchant 108a.
[0078] At 324, the user 106 feeds the transaction amount that needs to be paid to the merchant 108a using the stored user credential data at the payment network 112 or the server system 102. In one embodiment, the user 106 may also provide a user consent to utilize the stored user credential data for the payment transaction at the merchant 108a.
[0079] At 326, the user device 104 sends payment transaction data to the server system 102 to route the payment transaction to the issuer server 116 for authorization and authentication.
[0080] FIG. 4 represents a flowchart 400 illustrating a method of authorizing an electronic payment transaction through a shared payment wireless access point, in accordance with an embodiment of the present disclosure. The flowchart 400 would be implemented when the user 106 seeking to make a payment transaction at a merchant 108a through a shared payment wireless access point that the merchant 108a intends to use for the purpose of carrying out the proposed payment transaction. In such a situation, the user 106 associated with the user device 104 which is connected with the shared payment wireless access point 110 would require to be selected the merchant 108a from a list of merchants registered with the shared payment wireless access point. The user 106 enters a transaction amount to be paid to the merchant 108a.
[0081] Moreover, the flowchart 400 explains the authorization process when the user 106 selects the merchant 108a and feeds the transaction amount on a graphical user interface displayed on the user device 104.
[0082] At 402, the server system 102 receives payment transaction data from the user device 104 through the shared payment wireless access point. The payment transaction data includes, but is not limited to, transaction amount, merchant unique identifier (i.e., merchant private key), user private key, etc. The server system 102 also identifies the unique access point identifier associated with shared payment wireless access point.
[0083] At 404, the server system 102 accesses merchant information such as merchant account data based, at least in part, on the merchant unique identifier and the unique access point identifier from the database 126. As used herein, “merchant Information” may include any information that is associated with a merchant, service provider, producer, or other relying party in a transaction. For example, merchant information may include a merchant identifier that was determined during registration for enabling acceptance of payment transactions via shared wireless access points, payment processing network, or other transaction processing entity associated with the remote transaction processing system.
[0084] In one embodiment, the merchant account data may include merchant account number, merchant name, merchant location, product name, etc. In one embodiment, the server system 102 may send a request to the acquirer server 118 to access the merchant information. The request includes the merchant unique identifier. The acquirer server 118 may identify the merchant information based on the merchant unique identifier and send the merchant information as a request response message to the server system 102.
[0085] At 406, the server system 102 may also determine or check user consent associated with the user 106 for the wireless network 122 of the payment wireless access point 110. The user consent may indicate access rights of the user credential data stored at the payment network 112. In other words, the user consent represents access rights for the stored user credential data for the server system 102. In one example, if the user 106 is not registered for payment transactions via payment wireless access points, it means that the user credential data for the wireless network 122 is not available.
[0086] At 408, the server system 102 generates a payment transaction request including the transaction amount, the merchant account data, the user consent, a data field indicating that the payment transaction has been routed through the payment wireless access point.
[0087] At 410, the server system 102 encrypts the payment transaction request based, at least in part, on a combination of the merchant private key and the user private key. In one embodiment, the encrypted payment transaction request may include any payment information that has been made unintelligible to some parties to prevent unauthorized access to the payment information. For example, the encrypted payment transaction request may not be read by a recipient without access to a shared secret or access to a designated encryption key. As such, the encrypted payment transaction request may be made unintelligible through a process that is reversible and repeatable such that two entities can share information using a shared secret or encryption keys without unauthorized entities being able to understand or gain access to the sensitive payment information or sensitive payment credentials within the payment information (unless they gain access to the shared secret or encryption keys).
[0088] In some embodiments, the encrypted payment transaction request may be generated by the application 124 of the user device 104 such that the application 124 may have encryption keys (e.g., user private key and merchant private key) that are used to encrypt stored or received payment credentials and/or other payment information for a payment transaction.
[0089] At 412, the server system 102 sends the encrypted payment transaction request to the payment server 114 associated with the payment network 112 via the acquirer server 118.
[0090] At 414, the payment server 114 decrypts the payment transaction request based, at least in part, on the combination of the merchant private key and the user private key. The payment server 114 has already stored the merchant private key and the user private key during enrolment process.
[0091] At 416, the payment server 114 generates a payment authorization request message based on the decrypted transaction request message and the user credential data associated with the user 106.
[0092] At 418, the issuer server 116 receives the payment authorization request message from the payment server 114. Thereafter, the issuer server 116 may perform authentication and authorization process to complete the payment transaction.
[0093] At 420, responsive to the issuer server 116 authorizing the requested payment transaction, the issuer server 116 sends a transaction authorization confirmation message to the server system 102. It would be understood that authorization of payment transaction may be based on the issuer server 116 authenticating identity of the user 106, ascertaining that the payment card/payment account has sufficient funds to complete the payment transaction, and/or any other conditions associated with the payment card/ payment account.
[0094] At 422, the user 106 and the merchant 108a receive the transaction authorization confirmation message through the payment wireless access point 110 upon processing the payment transaction.
[0095] In one example, a customer 'A' goes to a merchant named as 'ABC Bakers' and wishes to buy a packet of cookies. To perform the purchase transaction, the customer 'A' first puts his/her user device into offline mode. The customer 'A' then opens an issuer application that is integrated with wireless payment APIs. The issuer application requests the customer 'A' to turn-on the Wi-Fi mode. The customer 'A' clicks on wireless access point identifier associated with a payment wireless access point under which the merchant 'ABC Bakers' is registered. The customer 'A' enters his/her issuer public key (e.g., "XYZIN") and user private key (e.g., 3524) in the form of his/her present PIN of the payment card to get access of the wireless network of the payment wireless access point. The issuer application converts the entered information into an authentication token i.e., 'single password hashed token' to get the access of the wireless network associated with the payment wireless access point. Once the authentication token is validated, the issuer application displays a list of merchants registered under the access point identifier of the payment wireless access point. After selecting the correct merchant (e.g., 12433-ABC Bakers), the user inputs the transaction amount associated with the purchase transaction. The user device then performs encryption of payment transaction data using merchant private key and user private key and sends it to the server system. The server system then facilitates further processing of the purchase transaction.
[0096] FIGS. 5A, 5B, and 5C, collectively, represent a series of exemplary graphical user interfaces (GUIs) implemented on a user device 104 to initiate payment transactions to merchants via shared payment wireless access point, in accordance with an embodiment of the present disclosure. As described earlier, to perform a payment transaction at a merchant, the user 106 needs to put the user device 104 into Wi-Fi mode and operate the user device 104 into offline mode. Thereafter, the user 106 opens an application (for example, application 124) to initiate a payment transaction at the merchant.
[0097] The UI 500 includes a select button 502 for turning-on Wi-Fi mode and a list of wireless access points (see, 504a, 504b, 504c) located nearby to a current location of the user 106. After selecting a wireless access point 504a, the UI 520 is displayed on the user device 104.
[0098] The UI 520 includes a password field 522 that requires a combination of issuer public key (e.g., “XYZIN”) and user private key (e.g., “123542”) as input to get access wireless network 122 of the wireless access point 504a. The combination of the issuer public key and the user private key represents an authentication token. The user 106 clicks on 'connect' selection field 524 to submit the authentication token on the wireless network 122. After clicking on the 'connect' selection field 524, the UI 530 is displayed.
[0099] The UI 530 represents merchant selection interface that includes a plurality of merchant selection fields (see, 532, 534, 536, 538). Each merchant selection field includes a merchant private key and the respective merchant name. The user 106 selects the merchant selection field 534 (see, “12456 – Pizza Express”). After selecting the merchant selection field 534, a transaction amount field 540 is shown. The user 106 can enter the transaction amount (see, transaction amount field 540) to be paid to the merchant (e.g., “Pizza Express”) in exchange of goods or services. Thereafter, the user 106 selects 'pay' button 542 to send the payment transaction data via the wireless access point (e.g., 'Wireless_AP1') to the server system 102.
[00100] FIG. 6 represents a flow diagram of a computer-implemented method 600 for performing payment transactions between a user and a merchant using a wireless network 122 associated with a payment wireless access point 110, in accordance with an embodiment of the present disclosure. The method 600 depicted in the flow diagram may be executed by the server system 102 which may be standalone server or a server as whole incorporated in another server system. Operations of the method 600, and combinations of operation in the method 600, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions.
[00101] In certain implementations, the method 600 may be performed by a single processing thread. Alternatively, the method 600 may be performed by two or more processing threads, each processing thread implementing one or more individual functions, routines, subroutines, or operations of the method. In an illustrative example, the processing threads implementing the method 600 may be synchronized (e.g., using semaphores, critical sections, and/or other thread synchronization mechanisms). Alternatively, the processing threads implementing the method 600 may be executed asynchronously with respect to each other. The method 600 starts at operation 602.
[00102] At 602, the method 600 includes receiving, by a server system 102, an authentication token from the user device 104 to access a wireless network 122 associated with the payment wireless access point 110. The step 602 is performed in response to receipt of a wireless signal at the user device 104 associated with the user 106 from the payment wireless access point 110. The payment wireless access point 110 is configured to facilitate payment transactions for a plurality of merchants 108 located in proximity to a geographic location of the payment wireless access point 110.
[00103] At 604, the method 600 includes determining, by the server system 102, authenticity of the user 106 based, at least in part, on the authentication token.
[00104] At 606, the method 600 includes upon determining that the user 106 is authentic, displaying, by the server system 102, unique merchant identifiers associated with the plurality of merchants 108a-108c on a user interface of an application 124 accessible on the user device 104.
[00105] At 608, the method 600 includes receiving, by the server system 102, via the payment wireless access point 110, an indication of consent of the user 106 to perform a payment transaction with a merchant 108a of the plurality of merchants 108a-108c.
[00106] At 610, the method 600 includes receiving, by the server system 102, payment transaction data associated with the payment transaction from the user device 104 via the payment wireless access point 110.
[00107] At 612, the method 600 includes processing, by the server system 102, the payment transaction data associated with the payment transaction for facilitating the payment transaction between the merchant 108a and the user 106.
[00108] FIG. 7 is a simplified block diagram of a payment server 700, in accordance with an embodiment of the present disclosure. The payment server 700 is an example of the payment server 114 of FIG. 1. A payment network may be used by the payment server 700 as a payment interchange network. Examples of payment interchange network include, but not limited to, Mastercard® payment system interchange network. The payment server 700 includes a processing system 705 configured to extract programming instructions from a memory 710 to provide various features of the present disclosure. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment server 700 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00109] Via a communication interface 715, the processing system 705 receives a payment authorization request from a remote device 720 such as the server system 102, the acquirer server 118, or administrators managing server activities. The payment server 700 may also perform similar operations as performed by the server system 102.
[00110] FIG. 8 is a simplified block diagram of an acquirer server 800, in accordance with an embodiment of the present disclosure. The acquirer server 800 is associated with the acquiring bank of a plurality of merchants (e.g., the merchant 108a) where the merchant has established an account to accept the upcoming payment transactions though a wireless network 122. The acquirer server 800 is an example of the acquirer server 118 of FIG. 1, or may be embodied in the acquirer server 118. The acquirer server 800 includes a processing module 805 configured to extract programming instructions from a memory 810 to provide various features of the present disclosure. Further, the acquirer server 800 includes a processing module 805 communicably coupled to a database 815 and a communication module 820. The components of the acquirer server 800 provided herein may not be exhaustive, and the acquirer server 800 may include more or fewer components than that of depicted in FIG. 8. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the acquirer server 800 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[00111] Via the communication module 820, the processing module 805 receives information from a remote device 825 such as the issuer server 116, the server system 102, the payment server 114, and the payment network 112. In particular, the processing module 805 receives the information related to payment transactions between the acquiring bank and the issuing bank. Upon receiving the payment transaction details, the processing module 805 stores and/or records the payment transactions in the database 815. For instance, the payment transactions performed by the user 106 using the mobile application may be stored in the database 815. It is understood that the payment transaction details stored in the database 815 correspond to the historical transaction data.
[00112] In an embodiment, the server system 102 may access the database 815 via the communication module 820 which includes merchant information of a plurality of merchants associated with the acquirer server 800. In one embodiment, the database 815 also stores merchant private keys associated with the plurality of merchants after successful registration for facilitating payment transactions via the wireless network of payment wireless access points. In an embodiment, the communication module 820 is capable of facilitating operative communication with the remote device 825 using API calls. The communication may be achieved over a communication network, such as the network 120.
[00113] FIG. 9 is a simplified block diagram of an issuer server 900, in accordance with one embodiment of the present disclosure. The issuer server 900 is associated with an issuer bank/issuer, in which a user (e.g., the user 106) may have an account. The issuer server 900 is an example of the issuer server 116 of FIG. 1, or may be embodied in the issuer server 116. The issuer server 900 includes a processor 905 communicably coupled to a database 910 and a communication module 915. The components of the issuer server 900 provided herein may not be exhaustive, and the issuer server 900 may include more or fewer components than those of depicted in FIG. 9. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the issuer server 900 may be configured using hardware elements, software elements, firmware elements, and/or a combination thereof.
[00114] The database 910 includes information associated with the user 106, such as, but not limited to, a primary account number (PAN one or more parameters), a name, a city, a postal code, and the like.
[00115] Via a communication module 915, the processor 905 may receive information from a remote device 920 such as the issuer server 116, server system 102, the acquirer server 800, and the payment server 700. In an embodiment, the processor 905 may communicate the information related to the user 106 to the server system 102 for performing offline transactions using payment wireless access network.
[00116] FIG. 10 is simplified blocks diagram of a user device 1000 for example a mobile phone or a desktop computer capable of implementing the various embodiments of the present disclosure. For example, the user device 1000 may correspond to the user device 104 of FIG. 1. The user device 1000 is depicted to include one or more applications such as a mobile application. The mobile application can be an instance of an application downloaded from a third-party server or an issuer server. The mobile application is capable of communicating with the acquirer server 118 or the payment server 700 for facilitating payment transaction processing.
[00117] It should be understood that the user device 1000 as illustrated and hereinafter described is merely illustrative of one type of device and should not be taken to limit the scope of the embodiments. As such, it should be appreciated that at least some of the components described below in connection with that the user device 1000 may be optional and thus in an example embodiment may include more, less or different components than those described in connection with the example embodiment of the FIG. 10. As such, among other examples, the user device 1000 could be any of a mobile electronic device, for example, cellular phones, tablet computers, laptops, mobile computers, personal digital assistants (PDAs), mobile televisions, mobile digital assistants, or any combination of the aforementioned, and other types of communication or multimedia devices.
[00118] The illustrated user device 1000 includes a controller or a processor 1002 (e.g., a signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, image processing, input/output processing, power control, and/or other functions. An operating system 1004 controls the allocation and usage of the components of the user device 1000 and support for one or more payment transaction applications programs (see, the applications 1006) such as the issuer application, that implements one or more of the innovative features described herein. In addition, to the issuer application, the applications 1006 may include common mobile computing applications (e.g., telephony applications, email applications, calendars, contact managers, web browsers, messaging applications) or any other computing application.
[00119] The illustrated user device 1000 includes one or more memory components, for example, a non-removable memory 1008 and/or removable memory 1010. The non-removable memory 1008 and/or the removable memory 1010 may be collectively known as a database in an embodiment. The non-removable memory 1008 can include RAM, ROM, flash memory, a hard disk, or other well-known memory storage technologies. The removable memory 1010 can include flash memory, smart cards, or a Subscriber Identity Module (SIM). The one or more memory components can be used for storing data and/or code for running the operating system 1004 and the applications 1006. The user device 1000 may further include a user identity module (UIM) 1012. The UIM 1012 may be a memory device having a processor built in. The UIM 1012 may include, for example, a subscriber identity module (SIM), a universal integrated circuit card (UICC), a universal subscriber identity module (USIM), a removable user identity module (R-UIM), or any other smart card. The UIM 1012 typically stores information elements related to a mobile subscriber. The UIM 1012 in form of the SIM card is well known in Global System for Mobile Communications (GSM) communication systems, Code Division Multiple Access (CDMA) systems, or with third-generation (3G) wireless communication protocols such as Universal Mobile Telecommunications System (UMTS), CDMA6000, wideband CDMA (WCDMA) and time division-synchronous CDMA (TD-SCDMA), or with fourth-generation (4G) wireless communication protocols such as LTE (Long-Term Evolution).
[00120] The user device 1000 can support one or more input devices 1020 and one or more output devices 1030. Examples of the input devices 1020 may include, but are not limited to, a touch screen / a display screen 1022 (e.g., capable of capturing finger tap inputs, finger gesture inputs, multi-finger tap inputs, multi-finger gesture inputs, or keystroke inputs from a virtual keyboard or keypad), a microphone 1024 (e.g., capable of capturing voice input), a camera module 1026 (e.g., capable of capturing still picture images and/or video images) and a physical keyboard 1028. Examples of the output devices 1030 may include, but are not limited to a speaker 1032 and a display 1034. Other possible output devices can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, the touch screen 1022 and the display 1034 can be combined into a single input/output device.
[00121] A wireless modem 1040 can be coupled to one or more antennas (not shown in the FIG. 10) and can support two-way communications between the processor 1002 and external devices, as is well understood in the art. The wireless modem 1040 is shown generically and can include, for example, a cellular modem 1042 for communicating at long range with the mobile communication network, a Wi-Fi compatible modem 1044 for communicating at short range with an external Bluetooth-equipped device or a local wireless data network or router, and/or a Bluetooth-compatible modem 1046. The wireless modem 1040 is typically configured for communication with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between the user device 1000 and a public switched telephone network (PSTN).
[00122] The user device 1000 can further include one or more input/output ports 1050, a power supply 1052, one or more sensors 1054 for example, an accelerometer, a gyroscope, a compass, or an infrared proximity sensor for detecting the orientation or motion of the user device 1000 and biometric sensors for scanning biometric identity of an authorized user, a transceiver 1056 (for wirelessly transmitting analog or digital signals) and/or a physical connector 1060, which can be a USB port, IEEE 1294 (FireWire) port, and/or RS-232 port. The illustrated components are not required or all-inclusive, as any of the components shown can be deleted and other components can be added.
[00123] The disclosed method with reference to FIG. 6, or one or more operations of the server system 102 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such network) using one or more network computers. Additionally, any of the intermediate or final data created and used during implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means includes, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
[00124] Although the invention has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the invention. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal oxide semiconductor (CMOS) based logic circuitry), firmware, software and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[00125] Particularly, the server system 102 and its various components may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the invention may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (compact disc read only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g., electric wires, and optical fibers) or a wireless communication line.
[00126] Various embodiments of the invention, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which are disclosed. Therefore, although the invention has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the invention.
[00127] Although various exemplary embodiments of the invention are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.