Patent Publication Number: US-2017372405-A9

Title: Quick transaction completion using mobile device

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims a benefit of U.S. Provisional Patent Application No. 61/937,907, filed Feb. 10, 2014, which is incorporated by reference in its entirety. This application also is a continuation-in-part of U.S. patent application Ser. No. 13/870,856, filed Apr. 25, 2013, which claims the benefit of U.S. Provisional Patent Application No. 61/687,976, filed May 4, 2012, and U.S. Provisional Patent Application No. 61/786,013, filed Mar. 13, 2013, which are incorporated herein by reference in their entirety. 
    
    
     BACKGROUND 
     1. Field of the Disclosure 
     The disclosure relates generally to e-commerce, and more particularly, to systems and methods for using a mobile device to facilitate electronic payments. 
     2. Background 
     Online transactions for selling and buying products are becoming commonplace. To facilitate online transactions, merchants provide commerce websites that include products available for purchase and integrate with payment gateways to enable users to purchase the products through the commerce websites. Merchants often attract customers to their commerce websites via online advertising campaigns, in which an advertisement for a product or service offered by the merchant is displayed to a user while the user is viewing a web page other than a page of the commerce website. To purchase the product, the customer is typically routed away from the current webpage and navigated to the merchant&#39;s commerce site. However, navigating to a different webpage to purchase the product is inconvenient for the customer and decreases security of the transaction. 
     When shopping online via a commerce website, users often create accounts with the website by selecting a user name, entering and verifying an email of the user, entering financial information such as a credit card number or a bank account number, and providing a billing address. A user may log into a user account when the user desires to purchase a product, or the user may enter financial information, billing address, and the like each time the user places an order. 
     While creating an account with an online merchant is more convenient for customers who frequently shop with a particular merchant than re-entering financial information each time the customer desires to make a purchase, many consumers purchase products or services from multiple different merchants. If a consumer creates accounts with each of several merchants, the consumer must remember several different username and password combinations, which can be cumbersome, inconvenient, and prone to security risks, as passwords can be stolen or harvested. Therefore, a need exists for a payment solution that overcomes the disadvantages described above with conventional payment methods. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The disclosed embodiments have other advantages and features which will be more readily apparent from the detailed description, the appended claims, and the accompanying figures (or drawings). A brief introduction of the figures is below. 
         FIGS. 1A and 1B  illustrate block diagrams of systems for implementing some embodiments of the present disclosure. 
         FIG. 2  is a block diagram of a database structure for storing user data, according to one embodiment. 
         FIG. 3  is a flowchart illustrating a process for generating a user interface icon that when selected initiates a financial transaction, according to one embodiment. 
         FIGS. 4A-4C  are flowcharts illustrating embodiments of processes for conducting a financial transaction. 
         FIGS. 5A-5K  are example screenshots displayed by a user computing device or mobile device to conduct a financial transaction, according to one embodiment. 
         FIG. 6  is a flowchart illustrating a user registration process, according to one embodiment. 
         FIG. 7  is a flowchart illustrating a user registration process, according to one embodiment. 
         FIG. 8  is a block diagram of an example machine able to read instructions from a machine-readable medium and execute them in a processor (or controller) 
         FIG. 9  is a block diagram illustrating an example mobile device. 
     
    
    
     DETAILED DESCRIPTION 
     The Figures (FIGS.) and the following description relate to preferred embodiments by way of illustration only. It should be noted that from the following discussion, alternative embodiments of the structures and methods disclosed herein will be readily recognized as viable alternatives that may be employed without departing from the principles of what is claimed. 
     Reference will now be made in detail to several embodiments, examples of which are illustrated in the accompanying figures. It is noted that wherever practicable similar or like reference numbers may be used in the figures and may indicate similar or like functionality. The figures depict embodiments of the disclosed system (or method) for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein. 
     Configuration Overview 
     On embodiment of a disclosed system, method, and computer-readable storage medium includes enabling a financial transaction between a user computing device and a merchant server using a transaction processing server. In one embodiment, the method includes receiving at the transaction processing server, a notification of a selection of a code displayed by the user computing device. Responsive to receiving the selection of the code, one or more user identifiers associated with the user computing device are determined. Each user identifier identifies a user account at an online system and is determined based on a session with the online system active on the user computing device. The transaction processing server accesses, using the one or more user identifiers, a user account including a mobile device identifier and financial information of a user. A request for user input is sent to a mobile device identified by the mobile device identifier. The request for user input includes a request for completion of a physical act on the mobile device by the user. Responsive to receiving an indication that the physical act was provided at the mobile device, the financial information is transmitted to the merchant server for conducting the financial transaction. 
     In another embodiment, a method for enabling a financial transaction comprises providing via a merchant server, advertising content for rendering on a user device by a browser application executing on the user device. An identity of the user is unknown. The advertisement content includes information about one or more products and a code that when selected by a computing device causes the computing device to generate a request to initiate a financial transaction associated with the one or more products. Responsive to receiving a selection of the code, the merchant server transmits a notification of an initiation of the transaction and information about the one or more products to a transaction processing server. The transaction processing server is configured to access a user account using one or more identifiers associated with online sessions active on the user device. The user account includes a mobile device identifier and financial information of a user. The transaction processing server is also configured to send a request for user input to a mobile device identified by the mobile device identifier, where the request for user input comprises a request for completion of a physical act on the mobile device by the user. Responsive to receiving an indication that the physical act was provided at the mobile device, the transaction processing server is configured to transmit the financial information to the merchant server. The merchant server conducts the financial transaction using the financial information received from the transaction processing server. 
     Example System Environment 
       FIG. 1A  illustrates a system environment  100  for conducting online transactions, according to one embodiment. A transaction as described herein refers to any action between a user device and a merchant system, including payments, transfer of information, display of information, new user registration, and the like. Transactions may include the transfer of money from a financial account of a user to a merchant system (e.g., to pay for a product or service offered by the merchant system), or the merchant system may offer products or services free of charge. In one embodiment, as shown in  FIG. 1A , the system environment  100  includes one or more user (or client) devices  110 , a mobile device  120 , an identity server  130 , one or more merchant servers  140 , and a transaction processing server  170  in communication over a network  160 . A user  105  uses the user device  110  to initiate a transaction at a merchant server  140 . 
     User device  110 , merchant server  140 , and transaction processing server  170  may each include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable media to implement the various applications, data, and steps described herein. For example, such instructions may be stored in one or more computer readable media such as memories or data storage devices internal and/or external to various components of system  100 , and/or accessible over network  160 . 
     Network  160  may comprise any combination of local area and/or wide area networks, using both wired and/or wireless communication systems. In one embodiment, the network  160  uses standard communications technologies and/or protocols. For example, the network  160  includes communication links using technologies such as Ethernet, 802.11, worldwide interoperability for microwave access (WiMAX), 3G, 4G, code division multiple access (CDMA), digital subscriber line (DSL), etc. Examples of networking protocols used for communicating via the network  120  include multiprotocol label switching (MPLS), transmission control protocol/Internet protocol (TCP/IP), hypertext transport protocol (HTTP), simple mail transfer protocol (SMTP), and file transfer protocol (FTP). Data exchanged over the network  160  may be represented using any suitable format, such as hypertext markup language (HTML) or extensible markup language (XML). In some embodiments, all or some of the communication links of the network  160  may be encrypted using any suitable technique or techniques. 
     The user device  110  may be implemented using any appropriate hardware and software configured for wired and/or wireless communication over the network  160 . For example, the user device  110  may be implemented as a personal computer (PC), a tablet, personal digital assistant (PDA), laptop computer, a smart television, and/or other types of computing devices capable of transmitting and/or receiving data over network  160 . In some embodiments, the user device  110  may be mobile device such as a tablet or mobile phone, while in other embodiments, as illustrated in  FIG. 1A , the user  105  uses a separate mobile device  120 . The user  105  may use one or more user devices  110 , one or more mobile devices  120 , or both a user device  110  and a mobile device  120 . 
     The user device  110  executes a browser application  115  that enables the user  105  to browse information available over the network  160 . In one embodiment, the browser application  115  is implemented as a web browser configured to view information available over the Internet, including accessing content of a social networking site and a web email client as well as content provided by a merchant server  140 . 
     The mobile device  120  (e.g., a cellular phone or a tablet) communicates with other mobile devices, the user device  110 , the merchant server  140 , and/or the transaction server  170  over a mobile communication network (not shown) or the network  160 . The mobile device  120  has a mobile device identifier  125 , such as a mobile phone number, an integrated digital enhanced network (IDEN) number, or an international mobile station equipment identity (IMEI) number. In one embodiment, the mobile device  120  executes one or more browser applications  122  providing an interface for the user  105  to browse information made available over the network  160 . For example, the browser application  122  may be implemented as a web browser configured to view information available over the Internet, including accessing a social networking site or a web email client as well as accessing content provided by a merchant server  140 . 
     The mobile device  120  may additionally or alternatively execute a client-side payment application  124 . In one embodiment, the client-side payment application is provided by the transaction processing server  170  (e.g., downloaded to the mobile device  120 ) and may be used, for example, to provide client-side processing for performing desired tasks in response to operations selected by the user  105 . In one embodiment, client-side payment application  124  has a unique identifier and is uniquely tied to a mobile device identifier  125  associated with the mobile device  120 . In one embodiment, the client application  124  displays a user interface in connection with a financial transaction initiated by user  105  using the browser application  115  executing on user device  110 . 
     Associated with the user  105  and/or the user device  110  are one or more user identifiers  113  (e.g., username and password pairs) associated with user accounts at one or more online systems accessed via the user device  110  or the mobile device  120 . For example, the user  105  may currently be using a first username and password to access a FACEBOOK account, a second username and password to access a GMAIL account, a third username and password to access an online retailer, and so on. One or more of the identifiers  113  may be stored locally on the user device  110 , for example in cookies or a cache associated with the browser application  115 . 
     The identity server  130  manages the user identifiers  113 . The identity server  130  may be maintained by a third party provider, or the identity server  130  may be incorporated into the transaction processing server  170 . The identity server  130  may authenticate the user  105  across multiple sites and identities using the user identifiers  113 . In one embodiment, the identity server  130  executes an identity aggregation module  135 . The identity aggregation module  135  comprises software configured to aggregate a user&#39;s user identifiers  113  from the user device  110 . The identity aggregation module  135  may execute in the browser  115 , for example as a browser pop-up or overlay, a browser plug-in, or a browser toolbar, to retrieve the identifiers  113  from the online sessions active in the browser  115 . The identity aggregation module  135  communicates with the transaction processing server  170  and merchant server  140  to pass identity information in order to facilitate a registration of the user  105  or to conduct a payment transaction. 
     The merchant server  140  is maintained by a merchant or seller offering various products and/or services online via an online marketplace available over network  160 . The merchant server  140  may be used for point of sale (POS) or online purchases and transactions. Generally, the merchant server  140  may be maintained by any person or entity that provides an Internet-based service for which the person or entity receives money, including charities, traditional retailers, pop-up retailers, and restaurants. However, the merchant server  140  may offer products or services free of charge. The merchant server  140  may additionally or alternatively be an entity listing an advertisement for a product or service. 
     In one embodiment, the merchant server  140  executes a marketplace application  142  and a buy button interface module  144 , and maintains a product information database  146 . The marketplace application  142  is configured to serve information over the network  160  to the browser  115  of the user device  110 . For example, the marketplace application  142  may cause a webpage to be displayed via the browser application  115  on a display of the user device  110 . The webpage may contain content, such as information about a product for sale. In some embodiments, the webpage depicts a popup store. 
     The buy button interface module  144  provides a user interface element (referred to herein as a “buy button”) within the content served by the marketplace application  142  for initiating a checkout or payment function. For example, the buy button module  144  embeds a buy button in an advertisement, in a social media feed, or in email content or application data served by the merchant server  140  and displayed on the user device  110 . In response to a user selection of the buy button, the buy button interface module  144  initiates a financial transaction between the merchant server  140  and the user device  110  (or the mobile device  120 ). In one embodiment, the buy button interface module  144  provides an area within the content served by the marketplace application  142  for a buy button provided by the transaction processor  170 . 
     The product information database  146  contains information about goods, merchandise, content, or services (collectively, “products”) that are available for purchase by users, including identifiers of the products, availability of the products, and price of the products. 
     The transaction processing server  170  uses aggregated user identities to authenticate a user to the merchant server  140  and facilitate transactions between the merchant server  140  and the user device  110  (or the mobile device  120 ). The transaction processing server  170  may be maintained by an online payment service provider, which provides payment to the operator of the merchant server  140  for a transaction initiated by the user  105 . In one embodiment, the transaction processing server  170  executes a payment application  175  and a transaction processing module  172 , and maintains a user information database  180 . Other embodiments of the transaction processing server  170  may execute additional or different modules, and the functionality may be distributed differently among the modules. For example, another embodiment of the transaction processing server  170  may include a product shipping module that performs at least one product shipping-related functionality, such as causing a product to be shipped to the user  105 . 
     The user information database  180  stores a plurality of user accounts, each of which includes user account information associated with an individual user. For example, account information may include private financial information of users of devices such as account numbers, passwords, device identifiers, user names, phone numbers, credit card information, bank information, or other financial information which may be used to facilitate online transactions by user  105 . A user account in the user information database  180  can be accessed using a user identifier of a user associated with the user account. In one embodiment, the information stored in a user account may be provided by the user in creating an account with and registering with server-side payment application  175 , for example when installing client-side payment application  124  on user mobile device  120 . 
     The payment application  175  executed by the transaction processing server  170  communicates with the user device  110  or the mobile device  120  and the merchant server  140  over the network  160  to facilitate the purchase of goods or services, communicate and display information, and send payments by the user  105  to the operator of the merchant server  140 . The payment application  175  may also communicate with the client-side payment application  124  executing on the mobile device  120  to authorize the transaction. In one embodiment, the payment application  175  includes a buy button module  176  and an identity match module  178 , and is in communication with the user information database  180 . 
     The buy button module  176  stores user information in the user database  180 . For new users, the buy button module  176  provides new user registration and cause registration information to be stored in the user database  180 . For example, in response to a user selection of a buy button, the buy button module  176  requests registration information from the user for creating an account with the transaction processor  170 . For existing users, the buy button module  176  invokes the identity aggregation module  135  of the identity server  130  in response to a user selection of the buy button displayed on the user device  110 , which aggregates the user&#39;s provisioned identities  113  from the user device  110 . The identity aggregation module  135  communicates the provisioned identities  113  to the transaction processing server  170 , where the identity match module  178  causes a user record to be created in the user information database  180  or updates an existing user record in the database  180 . 
     In one embodiment, the buy button module  176  provides a buy button for insertion into content in a web page displayed on the user device  110  or the mobile device  120 . For example, the buy button module  176  provides executable code for insertion by the buy button interface module  144  into content served by the marketplace application  142 . In another embodiment, the buy button module  176  receives a notification from the merchant server  140  when a user selects a buy button provided by the buy button interface module  144 . 
     The transaction processing module  172  processes payments to the merchant server  140  on behalf of the user  105 . For example, the transaction processing module  172  sends funding source information, such as a credit card or bank account information, to the merchant server  140  to complete the transaction. 
     As shown in  FIG. 1A , the transaction processing server  170  may facilitate transactions between the user device  110  and each of a plurality of merchant servers  140 . The transaction processing server  170  may act as an identity aggregator for identities that can be used across several merchant servers  140 , obviating the need for the user  105  to recall login information to access accounts created with each of the merchant servers  140 . Instead, in some embodiments, the user  105  may simply need to recall a single login information for a single account associated with the transaction processing server  170 . In some embodiments, the login information for the account associated with the transaction processing server  170  may be an existing social identity, such as a social network identity or email identity for the user. Thus, for example, the user  105  may log into the user account with the transaction processing server  170  using a third-party authentication account, for example, the user&#39;s FACEBOOK identity. Furthermore, as the transaction processing server  170  sends funding source information to a merchant server  140  for conducting a transaction, the merchant servers  140  need not store users&#39; financial information. Storing financial information in a single system (the transaction processing server  170 ) is more secure for users, and reduces cost for the merchant servers  140  to establish and maintain secure databases for storing user financial information. 
       FIG. 1B  illustrates a block diagram of a system  101  for conducting financial transactions, according to another embodiment. System  101  is similar to system  100 , but also includes an advertisement (or “ad”) server  190 . The advertisement server  190  may be operated by an advertiser or ad exchange  197 , or may be a subsystem of the merchant server  140  or the transaction processor  170 . The ad server  190  may include one or more processors, memories, and other components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement various applications, data and steps described herein. For example, such instructions may be stored in one or more computer readable media such as memories or data storage devices internal and/or external to various components of system  101  and/or accessible over network  160 . 
     The advertisement server  190  serves advertisement content, referred to herein as an “ad,” “listing,” or “product listing,” to be included in web content served by merchant server  140 . The ad content may include any type of promotion, promotional message, coupon, or the like, and may advertise a product or service. Furthermore, the ad content may include any type of textual, graphical, video, or audio content. In one embodiment, the advertisement server  190  serves content from an ad database  194  in communication with the advertisement server  190 . 
     The ad server  190  executes a selectable area placement module  192 , which generates a selectable area within an ad served by the ad server  190 . For example, the selectable area placement module  192  defines the selectable area within an ad by specifying coordinates relative to the ad or by designating pixels within the ad as the selectable area. In one embodiment, the selectable area placement module  192  receives a user input (e.g., from the advertiser  197 ) defining the location of the selectable area within the ad. By specifying coordinates or pixels within an ad, the selectable area placement module  192  enables a browser (such as the browser  115  executed by the user device  110 ) to generate an actionable (e.g., clickable or scannable) area within an ad. 
     In one embodiment, the selectable area comprises a buy button, and a user input associated with the selectable area is received as an input to initiate a financial transaction. For example, the buy button enables a user to purchase a product advertised within the ad by adding the product to a shopping cart or invoking a checkout method within the ad in response to a user selection of the buy button. By providing purchase functionality within the ad, the selectable area placement module  192  enables the user to quickly and securely purchase the advertised product without navigating away from the ad. In other embodiments, the selectable area includes a link to additional information about the advertiser  197  or the advertised product or service, or provides other functionality associated with the ad. When the selectable area is selected through a computing device (such as the user device  110  or the mobile device  120 ), the transaction processing server  170  initiates a financial transaction. 
       FIG. 2  is a block diagram of a structure of the user database  180  maintained by the transaction processing server  170 , according to one embodiment. The user database  180  contains a set of user account records. A respective user account record  201  may include such information as: (i) an identifier  202  that uniquely identifies the client-side payment application  124  installed on the user&#39;s mobile device  120 , (ii) one or more user identifiers  211  associated with the user (e.g., user&#39;s login user name and password associated with transaction processing server  170 , user&#39;s login user name and password associated with a social networking site, user&#39;s email login user name and password, and user&#39;s account user name and password associated with merchant servers  140 ), (iii) a mobile device identifier  221  associated with the user, such as a mobile phone number or an IDEN number, (iv) private financial information  231  of the user, such as credit card information, bank information, or other financial information that may be used to facilitate online transactions by the user, (v) attributes and capabilities  241  of the mobile device associated with the device number  221 , (vi) user preferences  251  (such as shipping address), and (vii) transaction records  261  (such as, transaction amounts, dates, etc.) associated with the user record  201 . 
     Turning now to  FIG. 3 , illustrated is a flowchart of a method  300  for generating a user interface icon, such as a “buy button,” for initiating a financial transaction, according to one embodiment. In one embodiment, the process  300  is performed by the merchant server  140 . Other embodiments of the process may include different and/or additional steps. 
     Referring to  FIG. 3 , the merchant server  140  generates  310  a user-selectable icon to serve with content (e.g., content identifying a product for sale). In one embodiment, the selectable icon includes a code encoding a command to initiate a financial transaction, such as initiating purchase of the product identified by the content. For example, the merchant server  140  generates  312  an alphanumeric code, generates  314  a QR code, or generates  316  a barcode. The merchant server  140  may alternatively generate other types of codes to serve with content. When selected by a computing device (such as the user device  110  or the mobile device  120 ), the code directs the computing device to initiate a financial transaction to purchase the product associated with the code. For example, a user scans the code with the mobile device  120  or enters the code at the mobile device  120  to initiate the transaction. 
     The merchant server  140  serves  320  the content and the user-selectable icon for display by a computing device, such as the user device  110 . For example, the merchant server  140  serves the content as a webpage displayed at the user device  110 . In one embodiment, serving  320  the content includes inserting  322  the generated code into the content to be served. The merchant server  140  may alternatively transmit one or both of the content and user-selectable icon to another entity for serving to the user device  110 . For example, the merchant server  140  may transmit the selectable code to the advertising server  190  for embedding into advertising content and serving to the user device  110 . 
     Conducting Financial Transactions 
       FIGS. 4A-4C  illustrate various embodiments of a process for conducting transactions with a merchant server  140  using a transaction processing server  170  acting as a user identity aggregator. The processes shown in  FIGS. 4A-4C  are described with respect to example user interfaces shown in  FIGS. 5A-5K . 
       FIG. 4A  illustrates a process  400  for a single step order confirmation process, according to one embodiment. The merchant server  140  serves  402  content to user device  110 . A user of the user device  110  may interact with marketplace application  142  through the browser application  115  over network  160  in order to view one or more items served by merchant server  140  on the user device  110 , for example as served in the form of a pop-up online store, content being advertised, or content displayed in a social feed. The merchant server  140  may further provide a “buy now” button in the content that invites the user to initiate a transaction.  FIG. 5A  illustrates example content  510  served to the user device  110 . In the example of  FIG. 5A , the content  510  is served as part of a web page having a URL  505 . A buy button  515  is also displayed on the web page, and may be displayed near the content  510  or embedded in the content  510 . For example, as shown in  FIG. 5B , the buy button  515  is embedded in content  516 , which in one example is an advertisement.  FIG. 5C  illustrates an example advertisement  516  including the buy button  515 . As shown in the example of  FIG. 5C , the buy button  515  is a selectable area within the ad  516  defined by a set of coordinates (a,b), (c,d), (a+n, b+n), and (c+n, d+n). The coordinates of the buy button  515  may be specified by an ad server  190  serving the ad  516 . Although  FIG. 5C  illustrates a rectangular buy button  515 , a buy button served with content may take other shapes. 
     In one embodiment, the buy button  515  includes a code, such as an alphanumeric code, a QR code, or a barcode, encoding information for initiating the financial transaction. FIG.  5 D illustrates a QR code  545  served with the content  510 , and  FIG. 5E  illustrates a barcode  555  served with the content  510 . 
     If the user  105  wishes to purchase an item for sale or otherwise initiate a transaction, the user interacts with the device  110  to initiate the transaction. For example, the user device  110  receives  404  a user selection of the buy button  515  displayed on the user device  110 . In one embodiment, the user is not required to create or log into an account associated with the merchant server  140  for the purpose of initiating the transaction. 
     The transaction processor  170  receives  406  an indication of the initiation of the transaction from the user device  110 . In one embodiment, the user device  110  sends the transaction processor  170  an identifier of the user and transaction details such as a transaction amount, identifiers of the products or services being purchased, availability of the products or services being purchased, and an identifier of the merchant server  140  providing the product or services along with the notification of the initiation of the transaction. In some cases, the product or services being purchased may be free of charge, such as a coupon, a promotion, or an advertisement. 
     The transaction processing server  170  determines  408  a plurality of user identifiers identifying user accounts at respective online systems, including social network identities, email identities, or identities of the user with the merchant server  140  with which the user desires to conduct the transaction. As described earlier, the user may not have entered a username and password into the merchant server&#39;s site before selecting the buy button  515 . As such, the merchant server  140  may not be able to identify the user, and an identity of the user at the merchant site  140  is not transmitted to the transaction processing server  170  when the buy button  515  is selected. To determine  408  the user identifiers, one embodiment of the transaction processing server  170  generates an identity framework for the user by retrieving identifiers of the user from one or more other websites for which a session is active on browser  115  and for which the user has provided user identifiers. For example, as discussed above, the user may have logged into an account associated with a social networking site and/or an email site on the user device  110 . The user may leave such sessions running in the background while the user conducts other business online, such as running the sessions in another tab in the browser  115  or leaving cookies storing the user identity in the browser  115 . In one embodiment, the transaction processor  170  receives an aggregated list of the user identities from the identity aggregation module  135 . The transaction processing server  170  may store the aggregated identities in a record for the user in the user database  180 , and retrieve the user&#39;s record when the user selects the buy button  515 . 
     As can be appreciated, it may be desirable to verify the user initiating the transaction is associated with the identities determined by the transaction processor  170 . To verify the user&#39;s identity, the transaction processor  170  identifies  410  a mobile device identifier associated with the determined user identities. The mobile device identifier may be previously stored in the user database  180 , which may be populated, for example, during a user registration process completed when the user  105  installed client-side payment application  124  on the mobile device  120 . In one embodiment, the transaction processor  170  retrieves the mobile device identifier from the user record stored in the user database  180 . 
     The transaction processor  170  sends  412  a request for user input to the identified mobile device  120 . In one embodiment, the request for user input to the mobile device is transmitted via an Unstructured Supplementary Service Data (USSD) session. Other types of communication between transaction processor  170  and mobile device  120  may alternatively be used. In one embodiment, the request for user input into the mobile device  120  is transmitted to client-side payment application  124 , which may be launched or awakened in response to receiving the request for user input from the transaction processing server  170 . 
     The mobile device  120  renders  414  a user interface to request the user input from the user. A variety of different types of user input may be requested from the user. Example user interfaces displayed by the mobile device  120  to request user input are illustrated in  FIGS. 5F-5J . 
     In one embodiment, the request for user input includes a request for completion of a physical act on the mobile device by the user. The completion of the physical act provides some assurance that the user is in possession and control of the mobile device associated with the user&#39;s identity framework. In one embodiment, the request for user input includes a request for selecting a soft button. The request for user input may alternatively include a request for completion of a touch screen gesture other than a selection of a soft button, such as a swipe or a flick.  FIGS. 5F-5I  illustrate examples of a request for user input at a soft button displayed on a mobile device  120 . In the example illustrated in  FIG. 5F , mobile device  120  has a touch screen and displays a message  520 , which in one embodiment is a soft button inviting the user of the mobile device  120  to approve the transaction by providing an input at the message  520 . In the example illustrated in  FIG. 5F , no information is provided in the initial message  520  about the transaction, since it can be assumed that the user has initiated the transaction and therefore has knowledge of it. However, in another embodiment, at least some information can be provided in the message about the transaction, as illustrated in  FIG. 5G , which shows a message  540  asking the user to confirm purchase of concert tickets. Details about the proposed transaction may alternatively be provided in a popup  550  displayed on the mobile device  120  or the user device  110 , as shown for example in  FIG. 5H . In yet another example, as illustrated in  FIG. 5I , the mobile device  120  displays both a soft button  520  enabling the user to approve the transaction and a soft button  522  enabling the user to decline the transaction. 
     In another embodiment, the request for user input includes a request for entry of a password (e.g., a password associated with client-side payment application  124 ). The request may alternatively include a request for entry of a bank ATM pin or other secret pin.  FIG. 5J  illustrates an example of an authorization process requesting user of mobile device  120  to provide a pin  570  to approve a transaction. In one embodiment, the user enters the pin  570  using a soft keyboard  580  displayed by the mobile device  120 . 
     In some embodiments, the type of physical act requested depends on the type and capabilities of the mobile device  120 . Thus, if the mobile device  120  has a touch screen capable of receiving touch input, a requested physical act may include a swipe. Such a physical act would not be requested of a mobile device  120  without a touch screen. Furthermore, in some embodiments, the type of physical act requested depends on the type of financial transaction, a transaction amount, and/or user preferences. For example, a user  105  may cause a preference to be stored, for example, in a user account maintained by the transaction processing server  170 , that the user wishes dual-step authorization for purchases over a particular amount or for transactions with a particular merchant system  140 . For dual-input authorization, in some embodiments, after receiving an initial user input from user mobile device  120 , the transaction processing server  170  sends a request for authorization to mobile device  120 . In some embodiments, the first request for user input may include a request for a simple task to signify that the user is in possession of the mobile device  120 , while the second request for user input may request sensitive user information. The sensitive user information can be matched against stored information for the user or otherwise used for authorization. For example, a first request of user input may require the user to depress a soft button (e.g., depress a “Approve Transaction” or similar button, as illustrated in  FIG. 5F ), while the second request may require the user to enter a pin or password (as illustrated in  FIG. 5J ). In one embodiment, a hash of the pin or password is transmitted by the mobile device  120  to the transaction processing server  170  as indication of authorization. 
     The mobile device  120  receives  416  the user input from the user, and transmits a notification of the received user input or the pin or password entered by the user to the transaction processing server  170 . In some embodiments, depending on the sensitivity of the nature of information being transmitted, it may be protected, for example, using encryption techniques. The client-side payment application  124  executing on the user mobile device  120  may process the user input prior to transmitting the input or the notification to the transaction processing server  170  hash and salt the user-entered password or pin, and transmit the hashed and salted password to transaction processing server  170 , for instance via a USSD session. 
     The transaction processing server  170  uses the received authorization information to authorize  418  the transaction and to make a payment to the merchant server  140 . The user authorization information may be compared to information stored, for example, in user account information  180 , or may be sent to a third party (such as, a bank card or credit card issuing authority) for authorization. 
     In some embodiments, the user input is valid for a limited duration. Accordingly, if the user input is not received at the transaction processing server  170  within a predefined amount of time, transaction processing server  170  deems the transaction unsuccessful. The transaction processing server  170  cancels the unsuccessful transaction, and may send a cancellation message to merchant server  140  and/or may send a message, such as a fraud alert, to the user  105 , for example via an SMS message sent to the mobile device  120 . Similarly, if the user provides an input at the mobile device  120  to cancel the transaction (e.g., selecting the decline button  522  shown in  FIG. 5I ), the transaction processing server  170  cancels the transaction. 
     If the transaction is authorized  418 , the transaction processing server  170  transmits  420  financial information of the user to the merchant server  140 , which conducts  422  the transaction (e.g., requests payment from a financial account of the user and ships purchased goods to the user). In one embodiment, the transaction processor  170  also provides user details, such as shipping preferences, as obtained from user account information  180  to merchant server  140  for conducting the transaction. After conducting  422  the transaction, the merchant server  140  returns a receipt for the transaction to the transaction processing server  170 . In one embodiment, the transaction processing server  170  transmits  424  the receipt to the mobile device  120 , which displays  426  the receipt. An example transaction receipt  590  displayed by the mobile device  120  is shown in  FIG. 5K . In the example of  FIG. 5K , the transaction receipt  590  includes such information as an amount of the transaction and the time the transaction was completed. 
     Thus, process  400  enables authorization of a transaction initiated using a user device  110  and authorized using user mobile device  120 . In one embodiment, no authorization or other input is requested from the user  105  at the user device  110  after the transaction is initiated at the user device  110 . Rather, input is requested at the user&#39;s mobile device  120  to authorize the transaction. 
       FIG. 4B  illustrates a process  430  for a dual step order confirmation, according to one embodiment. The process  430  is similar to process  400 , except after authorizing  418  the financial transaction in response to receiving an indication of the user input provided at the mobile device  120 , the transaction processor  170  requests  421 - 1  authentication information from the mobile device  120 . The mobile device  120  receives  421 - 2  the requested information and returns the information to the transaction processor  170 . In one embodiment, the first request for user input at the mobile device  120  (steps  412 - 416 ) includes a request for a simple task, for example to signify that the user is in possession of the mobile device  120 , while the second request for user input at step  421  requests sensitive user information (e.g., a pin). In response to receiving the second user authentication, the transaction processor  170  authenticates the transaction and transmits  420  the payment information to the merchant server  140 . 
       FIG. 4C  illustrates a process  440  for conducting a transaction initiated from an advertisement, according to one embodiment. As shown in  FIG. 4C , the process  440  comprises interactions between the merchant server  140 , the user device  110 , the ad server  190 , and the transaction processing server  170 . In other embodiments, the steps of the process  440  may be performed in different orders, and the steps may be performed by different entities. For example, one or more of the steps performed by the ad server  190  may instead be performed by the merchant server  140 . 
     Referring to  FIG. 4C , the ad server  190  generates an ad including a buy button. In one embodiment, the ad server  190  specifies a selectable location (e.g., coordinates or pixels) within the ad that corresponds to the buy button. In one embodiment, the ad server  190  provides the ad to the merchant server  190 , which serves  402  the ad content to the user device  110 . In another embodiment, the ad server  190  directly serves the ad to the user device  110 . 
     The user device  110  receives  404  a selection of the buy button from a user. When the buy button is selected, the ad server  190  receives an indication of the initiation of the transaction and initiates  405  the payment authorization process performed by the transaction processing server  170  and described with respect to  FIG. 4A . By initiating a financial transaction in response to a user selection of a buy button displayed within an ad, the transaction processing server  170  provides an efficient method of monetizing the ad. 
     In the system and methods illustrated in  FIGS. 1 and 4A-4C , the client device  110  and mobile device  120  are illustrated as two separate devices. However, in another embodiment, the described functionality may be performed solely by the mobile device  120 . In this case, the user  105  may use the browser application  122  on mobile device  120  to access content served by merchant server  140 , and transaction processing server  170  may use the mobile device  120  for user authorization. 
       FIG. 6  is a flowchart illustrating a registration process  600  used to create a user identity record  201  in the user information database  180 , according to one embodiment. In one embodiment, the process  600  comprises interactions between a mobile device  120  and the transaction processing server  170 . Other embodiments of the process  600  may include fewer, different, or additional steps, and the steps may be performed in different orders. 
     In one embodiment, process  600  begins with the mobile device  120  requesting  610  (e.g., in response to a user input) the client-side payment application  124  from the transaction processing server  170  for execution on the mobile device  120 . In response to the request, the transaction processing server  170  pushes or otherwise provides  620  the client-side payment application  124  to the mobile device  120  using, for example, a mobile communications network. Once executing on mobile device  120 , client-side payment application  124  obtains  630  an identifier associated with the user  105 . In one embodiment, client-side payment application  124  does not require user  105  to create or otherwise log in to client-side payment application  124 . Instead, the client-side payment application  124  determines  632  provisioned identifiers for the user  105  based on the user&#39;s active sessions, for example with social networking accounts, email accounts, or other online accounts active on the mobile device  120 . In another embodiment, where the user  105  does not participate in such sessions, for example, with social networking accounts, email accounts, or other online systems, the user  105  may create a user name and password with which to log into client-side payment application  124 . The payment application  124  receives  634  the user name and passwords, and uses the user name and password as the identifier associated with the user  105 . The client-side payment application  124  transmits  640  the one or more identifiers for the user  105  to the transaction processing server  170 , which creates  650  a record  201  for user  105  associating the mobile device identifier for mobile device  120  and the one or more user identifiers together. The transaction processing server  170  may subsequently modify or update user record  201  based, for example, on transactions completed by the user  105  or changes in the user identifier  211  data. The user  105  may optionally provide user preference data (e.g., preferred shipping address, preferred payment method information, etc.) during (or subsequent to) the registration process. 
       FIG. 7  is a flowchart illustrating a process  700  that may precede process  600  discussed with reference to  FIG. 6 . In particular, process  700  may lead to the user  105  requesting client-side payment application  124  from transaction processing server  170  for execution on mobile device  120 . In one embodiment, the process  700  comprises interactions between a user device  110  and the transaction processing server  170 . Other embodiments of the process  700  may include fewer, different, or additional steps, and the steps may be performed in different orders. 
     The user device  110  obtains  710  an identifier of the user of the user device  110 . In one embodiment, the user device  110  obtains  710  the identifier in response to the user selecting the buy button  415  displayed on the user device  110  to purchase an object for sale. In another embodiment, the user device  110  obtains  710  the identifier in response to the buy button  415  being displayed by the user device  110 , prior to the user selecting the buy button  415 . In an embodiment in which the buy button  415  is embedded or otherwise integrated into advertisement content (e.g., content  416 ), pre-emptive identification of the user can be used to personalize the advertisement content, for example by displaying a greeting to the user  105 . 
     In one embodiment, the user is not required to create or otherwise log into an account associated with the provider of the object for sale. Instead, the user device  110  or an external identity provider determines  712  provisioned identifiers for the user  105  based on the user&#39;s active sessions, for example with social networking accounts, email accounts, or accounts with other online systems that are active on user device  110 . In another embodiment, the user  105  may provide a user name and password with which to log into an account with server-side payment application  175 . In this case, the user device  110  determines  714  the identifiers from the user account. 
     The user device  110  transmits  720  the user identifier to the transaction processing server  170 , which performs a lookup to see if there is a user record  201  in the user information database  180 . If no record exits, user  105  is requested to register with server-side payment application  175  and install client-side payment application  124  on the mobile device  120 . 
     Computing Machine Architecture 
       FIG. 8  is a block diagram of one embodiment of a computing device  800 , which can be used as any one of user device  110 , merchant server  140  and transaction processing server  170 . In one embodiment computing device  800  includes one or more processing units (CPUs)  802 , one or more network or other communications interfaces  808 , memory  806 , and one or more communication buses  808  for interconnecting these components. The communication buses  808  may include circuitry (sometimes called a chipset) that interconnects and controls communications between system components. Computing device  800  may include a user interface  810  comprising an output (e.g. display) device  812  and an input device (e.g., keyboard)  814 . 
     Memory  806  includes high-speed random access memory, such as DRAM, SRAM, DDR RAM or other random access solid state memory devices; and may include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid state storage devices. Memory  806  may optionally include one or more storage devices remotely located from the CPU(s)  802 . Memory  806 , or one or more of the storage devices (e.g., one or more non-volatile storage devices) in memory  806 , includes a computer readable storage medium. In some embodiments, memory  806  or the computer readable storage medium of memory  806  stores the following programs, modules and data structures, or a subset thereof: an operating system  816  that includes procedures for handling various basic system services and for performing hardware dependent tasks; a network communication module  818  that is used for connecting computing device  800  to other computers via the one or more communication network interfaces  808  and one or more communication networks, such as the Internet, other wide area networks, local area networks, or metropolitan area networks. In the case of the user device  110 , memory  806  may further store other applications, such as browser application  115  and word processing applications. In the case of the merchant server  140 , memory  806  may further store a marketplace application  142  and “buy button” interface module  156 . In the case of the transaction processing server  170 , memory  806  may further store server-side payment application  175 , an identity match module  178 , database of user accounts  180  (which may alternatively be stored externally), and transaction processing application  172 . 
       FIG. 9  illustrates one embodiment of a portable electronic device  900 , which can function as user mobile device  120 . The device  900  includes a memory  902 , a memory controller  104 , one or more processing units (CPU&#39;s)  906 , a peripherals interface  908 , RF circuitry  912 , audio circuitry  914 , a speaker  916 , a microphone  918 , an input/output (I/O) subsystem  920 , a touch screen  926 , other input or control devices  928 , and an external port  948 . These components communicate over the one or more communication buses or signal lines  910 . It should be appreciated that the device  900  is only one example of a portable electronic device  900 , and that the device  900  may have more or fewer components than shown, or a different configuration of components. The various components shown in  FIG. 9  may be implemented in hardware, software or a combination of both hardware and software, including one or more signal processing and/or application specific integrated circuits. 
     The memory  902  may include high speed random access memory and may also include non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid state memory devices. In some embodiments, the memory  902  may further include storage remotely located from the one or more processors  906 , for instance network attached storage accessed via the RF circuitry  912  or external port  948  and a communications network (not shown) such as the Internet, intranet(s), Local Area Networks (LANs), Wide Local Area Networks (WLANs), Storage Area Networks (SANs) and the like, or any suitable combination thereof. Access to the memory  902  by other components of the device  900 , such as the CPU  906  and the peripherals interface  908 , may be controlled by the memory controller  904 . 
     The peripherals interface  908  couples the input and output peripherals of the device to the CPU  906  and the memory  902 . The one or more processors  906  run various software programs and/or sets of instructions stored in the memory  902  to perform various functions for the device  900  and to process data. 
     In some embodiments, the peripherals interface  908 , the CPU  906 , and the memory controller  904  may be implemented on a single chip, such as a chip  911 . In some other embodiments, they may be implemented on separate chips. 
     The RF (radio frequency) circuitry  912  receives and sends electromagnetic waves. The RF circuitry  912  converts electrical signals to/from electromagnetic waves and communicates with communications networks and other communications devices via the electromagnetic waves. The RF circuitry  912  may include well-known circuitry for performing these functions, including but not limited to an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a CODEC chipset, a subscriber identity module (SIM) card, memory, and so forth. The RF circuitry  912  may communicate with the networks, such as the Internet, also referred to as the World Wide Web (WWW), an Intranet and/or a wireless network, such as a cellular telephone network, a wireless local area network (LAN) and/or a metropolitan area network (MAN), and other devices by wireless communication. The wireless communication may use any of a plurality of communications standards, protocols and technologies, including but not limited to Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), wideband code division multiple access (W-CDMA), code division multiple access (CDMA), time division multiple access (TDMA), Bluetooth, Wireless Fidelity (Wi-Fi) (e.g., IEEE 802.11a, IEEE 802.11b, IEEE 802.11g and/or IEEE 802.11n), voice over Internet Protocol (VoIP), WiMAX, a protocol for email, instant messaging, and/or Short Message Service (SMS)), or any other suitable communication protocol, including communication protocols not yet developed as of the filing date of this document. 
     The audio circuitry  914 , the speaker  916 , and the microphone  918  provide an audio interface between a user and the device  900 . The audio circuitry  914  receives audio data from the peripherals interface  908 , converts the audio data to an electrical signal, and transmits the electrical signal to the speaker  916 . The speaker converts the electrical signal to human-audible sound waves. The audio circuitry  914  also receives electrical signals converted by the microphone  916  from sound waves. The audio circuitry  914  converts the electrical signal to audio data and transmits the audio data to the peripherals interface  908  for processing. Audio data may be may be retrieved from and/or transmitted to the memory  902  and/or the RF circuitry  912  by the peripherals interface  908 . In some embodiments, the audio circuitry  914  also includes a headset jack (not shown). The headset jack provides an interface between the audio circuitry  914  and removable audio input/output peripherals, such as output-only headphones or a headset with both output (headphone for one or both ears) and input (microphone). 
     The I/O subsystem  920  provides the interface between input/output peripherals on the device  900 , such as the touch screen  926  and other input/control devices  928 , and the peripherals interface  908 . The I/O subsystem  920  includes a touch-screen controller  922  and one or more input controllers  924  for other input or control devices. The one or more input controllers  924  receive/send electrical signals from/to other input or control devices  928 . The other input/control devices  928  may include physical buttons (e.g., push buttons, rocker buttons, etc.), dials, slider switches, sticks, and so forth. 
     The touch screen  926  provides both an output interface and an input interface between the device and a user. The touch-screen controller  922  receives/sends electrical signals from/to the touch screen  926 . The touch screen  926  displays visual output to the user. The visual output may include text, graphics, video, and any combination thereof. Some or all of the visual output may correspond to user-interface objects, further details of which are described below. 
     The touch screen  926  also accepts input from the user based on haptic and/or tactile contact. The touch screen  926  forms a touch-sensitive surface that accepts user input. The touch screen  926  and the touch screen controller  922  (along with any associated modules and/or sets of instructions in the memory  902 ) detects contact (and any movement or break of the contact) on the touch screen  926  and converts the detected contact into interaction with user-interface objects, such as one or more soft keys, that are displayed on the touch screen. In an exemplary embodiment, a point of contact between the touch screen  926  and the user corresponds to one or more digits of the user. The touch screen  926  may use LCD (liquid crystal display) technology, or LPD (light emitting polymer display) technology, although other display technologies may be used in other embodiments. The touch screen  926  and touch screen controller  922  may detect contact and any movement or break thereof using any of a plurality of touch sensitivity technologies, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with the touch screen  926 . However, the touch screen  926  displays visual output from the portable device, whereas touch sensitive tablets do not provide visual output. The touch screen  926  may have a resolution in excess of 800 dpi. In an exemplary embodiment, the touch screen  926  may have a resolution of approximately 868 dpi. The user may make contact with the touch screen  926  using any suitable object or appendage, such as a stylus, finger, and so forth. 
     In some embodiments, in addition to the touch screen, the device  900  may include a touchpad (not shown) for activating or deactivating particular functions. In some embodiments, the touchpad is a touch-sensitive area of the device that, unlike the touch screen, does not display visual output. The touchpad may be a touch-sensitive surface that is separate from the touch screen  926  or an extension of the touch-sensitive surface formed by the touch screen  926 . 
     The device  900  also includes a power system  930  for powering the various components. The power system  930  may include a power management system, one or more power sources (e.g., battery, alternating current (AC)), a recharging system, a power failure detection circuit, a power converter or inverter, a power status indicator (e.g., a light-emitting diode (LED)) and any other components associated with the generation, management and distribution of power in portable devices. 
     In some embodiments, the software components include an operating system  932 , a communication module (or set of instructions)  934 , a contact/motion module (or set of instructions)  938 , a graphics module (or set of instructions)  940 , a user interface state module (or set of instructions)  944 , and one or more applications (or set of instructions)  946 . 
     The operating system  932  (e.g., Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or an embedded operating system such as VxWorks) includes various software components and/or drivers for controlling and managing general system tasks (e.g., memory management, storage device control, power management, etc.) and facilitates communication between various hardware and software components. 
     The communication module  934  facilitates communication with other devices over one or more external ports  948  and also includes various software components for handling data received by the RF circuitry  912  and/or the external port  948 . The external port  948  (e.g., Universal Serial Bus (USB), FIREWIRE, etc.) is adapted for coupling directly to other devices or indirectly over a network (e.g., the Internet, wireless LAN, etc.). 
     The contact/motion module  938  detects contact with the touch screen  926 , in conjunction with the touch-screen controller  922 . The contact/motion module  938  includes various software components for performing various operations related to detection of contact with the touch screen  922 , such as determining if contact has occurred, determining if there is movement of the contact and tracking the movement across the touch screen, and determining if the contact has been broken (i.e., if the contact has ceased). Determining movement of the point of contact may include determining speed (magnitude), velocity (magnitude and direction), and/or an acceleration (including magnitude and/or direction) of the point of contact. In some embodiments, the contact/motion module  926  and the touch screen controller  922  also detects contact on the touchpad. 
     The graphics module  940  includes various known software components for rendering and displaying graphics on the touch screen  926 . Note that the term “graphics” includes any object that can be displayed to a user, including without limitation text, web pages, icons (such as user-interface objects including soft keys), digital images, videos, animations and the like. 
     In some embodiments, the graphics module  940  includes an optical intensity module  942 . The optical intensity module  942  controls the optical intensity of graphical objects, such as user-interface objects, displayed on the touch screen  926 . Controlling the optical intensity may include increasing or decreasing the optical intensity of a graphical object. In some embodiments, the increase or decrease may follow predefined functions. 
     The user interface state module  944  controls the user interface state of the device  900 . The user interface state module  944  may include a lock module  950  and an unlock module  952 . The lock module detects satisfaction of any of one or more conditions to transition the device  900  to a user-interface lock state and to transition the device  900  to the lock state. The unlock module detects satisfaction of any of one or more conditions to transition the device to a user-interface unlock state and to transition the device  900  to the unlock state. 
     The one or more applications  930  can include any applications installed on the device  900 , including without limitation, a browser, address book, contact list, email, instant messaging, word processing, keyboard emulation, widgets, JAVA-enabled applications, encryption, digital rights management, voice recognition, voice replication, location determination capability (such as that provided by the global positioning system (GPS)), a music player (which plays back recorded music stored in one or more files, such as MP3 or AAC files), etc. Client-side payment application  124  may also be installed on device  900 . 
     Additional Configuration Considerations 
     Throughout this specification, plural instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein. 
     Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms, e.g., as shown and described with  FIGS. 1A, 1B . Modules may constitute either software modules (e.g., code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein. 
     In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations. 
     The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules. 
     The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application program interfaces (APIs).) 
     The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the one or more processors or processor-implemented modules may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other example embodiments, the one or more processors or processor-implemented modules may be distributed across a number of geographic locations. 
     Some portions of this specification are presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals within a machine memory (e.g., a computer memory). These algorithms or symbolic representations are examples of techniques used by those of ordinary skill in the data processing arts to convey the substance of their work to others skilled in the art. As used herein, an “algorithm” is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, algorithms and operations involve physical manipulation of physical quantities. Typically, but not necessarily, such quantities may take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is convenient at times, principally for reasons of common usage, to refer to such signals using words such as “data,” “content,” “bits,” “values,” “elements,” “symbols,” “characters,” “terms,” “numbers,” “numerals,” or the like. These words, however, are merely convenient labels and are to be associated with appropriate physical quantities. 
     Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information. 
     As used herein any reference to “one embodiment” or “an embodiment” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment. 
     Some embodiments may be described using the expression “coupled” and “connected” along with their derivatives. For example, some embodiments may be described using the term “coupled” to indicate that two or more elements are in direct physical or electrical contact. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. The embodiments are not limited in this context. 
     As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, “or” refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present). 
     In addition, use of the “a” or “an” are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the invention. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise. 
     Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for a system and a process for conducting a transaction through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.