Verifying proximity during payment transactions

Description

TECHNICAL FIELD

This disclosure relates to payment processing using a mobile device.

BACKGROUND

In a conventional electronic credit card transaction at an online store, the transaction is authorized and captured over a network connection. In the authorization stage, credit card information is entered into an interface of the online store, e.g., a payment form. A payment request is sent electronically from a computing device running the online store to a credit card processor. The credit card processor routes the payment request to a card network, e.g., Visa or Mastercard, which in turn routes the payment request to the card issuer, e.g., a bank. Assuming the card issuer approves the transaction, the approval is then routed back to the online store. In the capture stage, the approved transaction is again routed from the online store to the credit card processor, card network and card issuer. The capture stage can trigger the financial transaction between the card issuer and the merchant, and optionally creates a receipt. There can also be other entities, e.g., the card acquirer, in the route of the transaction. Debit card transactions have a different routing, but also require entry of card information.

SUMMARY

A customer can purchase items for sale at an online store of the merchant. Generally, the customer enters in financial payment information, e.g., credit card information, when completing the online transaction. If a hacker steals the financial payment information, the hacker can fraudulently conduct online transactions.

Merchants can increase security of the online transaction by requiring a two factor authentication before completing an online transaction. The customer can select items for purchase on a first device, e.g., a desktop computer. The online store can request a unique identifier, e.g., a mobile phone number, associated with a second device owned by the customer. The customer can enter the unique identifier to receive a notification of the purchase at the second device, e.g., the mobile device of the customer. The customer can confirm the purchase using the second device.

The second device can determine whether it is in proximity to the first device. In some implementations, a payment service system considers the determination of proximity as a factor in approving or rejecting the transaction. In some other implementations, if the second device is not in proximity to the first device, the customer is unable to complete the transaction at the second device.

In one aspect, a method of processing a transaction for a customer using a first device and a second device, comprising: receiving a notification from the first device, where the notification includes a selection of one or more items for purchase, where the notification includes an identifier, and where the identifier uniquely identifies both the customer and a second device; determining that the second device is in proximity to the first device as an authentication measure; in response to the determining, sending the determination to the second device, where the second device displays details regarding the selection of the one or more items for purchase; receiving, from the second device, user input indicating a confirmation of the purchase of the one or more items; submitting, to a payment processor, the details for authentication.

Implementations can include one or more of the following. Determining that the second device is in proximity to the first device comprises: determining a first location of the first device; determining a second location of the second device; and determining the distance between the first location and the second location is within a predetermined distance. Sending, to both the first and second devices, confirmation of the authentication from the payment processor. The details include, for each item, a respective description and a respective price. The unique identifier is one of the following: a phone number, a pay phrase, or a password. Receiving the user input comprises receiving a swipe, at the second device, that confirms the purchase of the one or more items.

In another aspect, a method of processing a transaction for a customer using a first device and a second device, comprising: receiving, at the first device, first user input to purchase one or more items for sale; receiving an identifier for the customer, where the identifier uniquely identifies both the customer and the second device; sending, from the first device to the second device, a notification of the one or more items selected for purchase; determining that the second device is in proximity to the first device as an authentication measure; in response to the determining, displaying, at the second device, details regarding the one or more items selected for purchase; receiving, at the second device, second user input to confirm the purchase of the one or more items; and submitting, to a payment processor, the details for authentication.

Implementations can include one or more of the following features. Sending the notification to the second device comprises: sending the notification from the first device to a server; and forwarding the notification from the server to the second device. Sending the notification to the second device comprises broadcasting the notification to the second device using a short range communication protocol. The short range communication protocol is one of the following: Near Field Communication, Bluetooth, or sound. Determining that the second device is in proximity to the first device comprises: determining a first location of the first device; determining a second location of the second device; and determining the distance between the first location and the second location is within a predetermined distance. Receiving, at both the first and second devices, confirmation of the authentication from the payment processor and displaying the confirmation. The details include, for each item, a respective description and a respective price. Receiving the unique identifier comprises: displaying an input field; receiving, through the input field, the unique identifier based on input of the customer. The customer is logged into the first device, and where receiving the unique identifier comprises accessing the unique identifier from an account of the customer. The unique identifier is one of the following: a phone number, a pay phrase, or a password. Receiving the second user input comprises receiving a swipe that confirms the purchase of the one or more items.

In another aspect, a system for processing a transaction for a customer, comprising: a first device, where the first device receives first user input to purchase one or more items for sale, and where the first device receives an identifier for the customer; a second device, where the identifier uniquely identifies both the customer and the second device; and a payment processor, where one of the first device, the second device, or the payment processor determines that the second device is in proximity to the first device as an authentication measure, where in response to the determining, the second device is configured to perform operations comprising: displaying details regarding the one or more items selected for purchase; receiving second user input to confirm the purchase of the one or more items; and submitting the details for authentication to the payment processor.

In another aspect, a method of processing a transaction for a customer using a first device and a second device, comprising: receiving a notification from the first device, where the notification includes a selection of one or more items for purchase, where the notification includes an identifier, and where the identifier uniquely identifies both the customer and a second device; sending the notification to the second device, where the second device displays details regarding the selection of the one or more items for purchase; receiving, from the second device, user input indicating a confirmation of the purchase of the one or more items; determining whether the first device is in proximity to the second device as an authentication measure; submitting, to a payment processor, the details and the determination of proximity for authentication, where the payment processor determines whether to approve the transaction based at least on the determination of proximity.

Implementations can include one or more of the following features. Determining that the second device is in proximity to the first device comprises: determining a first location of the first device; determining a second location of the second device; and determining the distance between the first location and the second location is within a predetermined distance. Sending, to both the first and second devices, confirmation of the authentication from the payment processor. The details include, for each item, a respective description and a respective price. The unique identifier is one of the following: a phone number, a pay phrase, or a password. Receiving the user input comprises receiving a swipe, at the second device, that confirms the purchase of the one or more items.

In another aspect, a method of processing a transaction for a customer using a first device and a second device, comprising: receiving, at the first device, first user input to purchase one or more items for sale; receiving a unique identifier for the customer, where the unique identifier identifies both the customer and the second device; sending, from the first device to the second device, a notification of the one or more items selected for purchase; displaying, at the second device, details regarding the one or more items selected for purchase; receiving, at the second device, second user input to confirm the purchase of the one or more items; determining whether the first device is in proximity to the second device as an authentication measure; submitting, to a payment processor, the details and the determination of proximity for authentication, where the payment processor determines whether to approve the transaction based at least on the determination of proximity.

Implementations can include one or more of the following features. Sending the notification to the second device comprises: sending the notification from the first device to a server; and forwarding the notification from the server to the second device. Sending the notification to the second device comprises broadcasting the notification to the second device using a short range communication protocol. The short range communication protocol is one of the following: Near Field Communication, Bluetooth, or sound. Determining that the second device is in proximity to the first device comprises: determining a first location of the first device; determining a second location of the second device; and determining the distance between the first location and the second location is within a predetermined distance. Receiving, at both the first and second devices, confirmation of the authentication from the payment processor and displaying the confirmation. The details include, for each item, a respective description and a respective price. Receiving the unique identifier comprises: displaying an input field; receiving, through the input field, the unique identifier through input of the customer. The customer is logged into the first device, and where receiving the unique identifier comprises accessing the unique identifier from an account of the customer. The unique identifier is one of the following: a phone number, a pay phrase, or a password. Receiving the second user input comprises receiving a swipe that confirms the purchase of the one or more items.

Advantages may include one or more of the following. Online transactions can be conducted with two factor authentication, thereby increasing security for both the merchant and the customer. In particular, a payment service system can ensure the transaction is conducted using two devices that are in proximity with each other, where one of the devices is owned by the customer.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic illustration of an example payment system architecture.

FIG. 2 is a flow chart of an example process of verifying proximity when conducting a transaction using a first device and a second device.

FIGS. 3A-B are illustrations of an example user interface of the first device when conducting the transaction.

FIGS. 4A-B are illustrations of an example user interface of the second device when conducting the transaction.

FIG. 5 is a flow chart of another example process of verifying proximity when conducting a transaction using the first device and the second device.

FIG. 6 is a block diagram of an exemplary architecture of a mobile device capable of running a customer application that conducts the transaction.

Like reference numbers and designations in the various drawings indicate like elements.

DETAILED DESCRIPTION

FIG. 1 is a schematic illustration of an example payment system architecture 100. The overall system 100 includes a first device 104, e.g., a desktop computer, connected to a network, e.g., the Internet 106. The first device 104 is a computing device capable of running an Internet browser. For example, the first device 104 can be a smartphone, tablet, a desktop computer, a laptop computer, or other data processing apparatus. The second device 103 is also a computing device connected to the Internet 106. The second device 103 can be a mobile device, e.g., a smartphone, tablet, or other portable data processing apparatus. When conducting a transaction, a customer can select items for sale from a merchant's online store using the first device 104 and confirm purchase of the selected items for sale using the second device 103. This will be described further below in reference to FIGS. 2-5.

A payment processor operates a payment service system 108. The payment processor processes transactions conducted using the first and second devices 103, 104. The first device 104 can receive selection of items for purchase and card information, e.g., through user input at an online form, for the transaction at an online store 122. The online store 122 will be described further below. The second device 103 can send confirmation of the purchases to the payment service system 108. The first and second devices 103, 104 communicate with the payment service system 108 using the network 106. The payment service system 108 includes one or more servers 112, at least some of which can handle secure transactions (e.g., using a secure server), to process all transactions with the mobile device 104. In general, servers 112 can store public merchant information such as the merchant's address or phone number. The servers 112 also handle secure information such as credit card numbers, debit card numbers, bank accounts, user accounts, user identifying information or other sensitive information.

The payment service system 108 can communicate with a computer system 116 of a card payment network, e.g., Visa or MasterCard. The payment service system 108 can communicate with a computer system 116 over the same network 106 used to communicate with the mobile device 104, or over a different network. The computer system 116 of the card payment network can communicate in turn with a computer system 118 of a card issuer, e.g., a bank. There can also be computer systems of other entities, e.g., the card acquirer, between the payment service system 108 and the card issuer.

Eventually, in order to receive funds from the transaction, the merchant will need to enter financial account information into the payment service system 108 sufficient to receive funds. For example, in the case of a bank account, the merchant can enter the bank account number and routing number. The merchant's financial account can also be associated with a credit card account or another third party financial account. In addition, in some implementations, if the merchant has not entered the financial account information, the payment processor can hold the received funds until the financial account information is provided.

The payment service system 108 can also include an inventory management system 120. The inventory management system 120 manages items for sale by the merchant, e.g., using one or more databases. For example, the inventory management system 120 can store details for each item. The details can include a title, a price, quantity, or a description of the item. Therefore, the payment service system 108 can not only process financial transactions but can also manage inventory for the merchant.

The payment service system 108 can also include the online store 122. In some implementations, a merchant operates the online store 122 using the merchant's own external systems. Inventory data for the online store 122 can be pulled from the inventory management system 120. For example, the online store 122 can host one or more resources that are accessible by browser running on a device connected to the network 106. The one or more resources can include details of the inventory owned by the merchant, e.g., pulled from a database of the inventory management system 120.

FIG. 2 is a flow chart of an example process of verifying proximity when conducting a transaction using a first device and a second device. For convenience, the process will be described with respect to the first device and the second device as described above in reference to FIG. 1.

The first device receives first user input to purchase one or more items for sale in an electronic transaction (step 202). The one or more items can be listed in inventory of the merchant, as described above in reference to FIG. 1. The first user input can be received at a user interface, e.g., an online storefront of the merchant or a mobile device at a physical location of the merchant, that is displayed at the first device. The first user input can include a mouse click, keyboard input, a tap, or a swipe. An example of the user interface is described further below in reference to FIGS. 3A-B.

The first device receives a unique identifier from the customer, e.g., through additional input from the customer (step 204). For example, the first device can display an input field on the user interface and instruct the customer to enter the unique identifier. The first device can receive the unique identifier through the input field based on customer input. The unique identifier can be a phone number, a unique pay phrase, e.g., “John Smith Pay Phrase”, a time-based token, or a password. In some implementations, the customer can be logged into the online storefront on the first device, e.g., through an Internet cookie. For example, the customer can have previously registered a user account at the online storefront. In some implementations, the unique identifier can be stored in the Internet cookie. The unique identifier can also be stored, e.g., in a database of a payment service system, as a customized setting on a profile of the user account.

The first device can send, to the second device, a notification of the items selected for purchase (step 206). A customer can engage with the notification to start a customer application running on the second device. The notification can include details of the items selected for purchase on the first device. The details can include, for each item, a respective description and a respective price. The customer application can display the details, as will be described further below. In some implementations, the first device sends the notification to a server, e.g., through the Internet to payment service system 108 or a merchant server, and the server forwards the notification to the second device. In some other implementations, the first device broadcasts the notification using a short range communication protocol. For example, the first device can act as a Bluetooth central and the second device can act as a Bluetooth peripheral. The central can detect when the peripheral is in close proximity and can identify it as running the customer application. At that point, the central can have a server, e.g., a payment service system, authenticate the peripheral as belonging to the individual. Other implementations of determining that two devices are in proximity to each other are possible, e.g., sound from a speaker of the first device into a microphone of the second device, or Near Field Communication (NFC).

A determination can be made as to whether the first device is in proximity to the second device (step 208). The first device, the second device, or a server, e.g., a payment service system, can make the determination. The determination can serve as an authentication measure for approving the transaction. In particular, the payment service system can consider the proximity determination when determining whether to authenticate, i.e., approve, the transaction. In some implementations, a location of the first device is obtained, e.g., using a Global Positioning Satellite (GPS) or an Internet Protocol address to location database, by the first device or the server. The location can be included in the notification to the second device. Upon receiving the notification, the second device can obtain its own location, e.g., using GPS or other location methods, and compare its own location with the location included in the notification. If the two locations are within a predetermined distance, e.g., thirty feet, the first device can be determined to be in proximity to the second device. In some other implementations, the server obtains the first device's location and the second device's location, determines whether the devices are in proximity to each other, and sends the determination to the first and second devices.

In some implementations, in response to determining the first device is in proximity to the second device, the second device displays details regarding the purchase of the items selected on the first device (step 210). An example of the details displayed is described below in reference to FIGS. 4A-B. In some implementations, if the first device is not in proximity to the second device, the first or second device receives a notification that indicates the transaction cannot be completed because of the lack of proximity. That is, the second device is unable to complete the transaction if the second device is not in proximity to the first device. If the second device is in proximity to the first device, the second device can display, e.g., using a customer application, an option to confirm the purchase.

After displaying the option to confirm the purchase, the second device can receive second user input to confirm the purchase of the items selected on the first device (step 212). For example, the second device can receive a swipe of a credit card through a user interface of the second device. Upon receiving the second user input, the second device can submit, e.g., to a payment service system, transaction details for authentication. The transaction details can include details regarding the items selected for purchase. The payment service system can approve the transaction based on the confirmation from the second device and can send the approval to both the first and second devices. Upon receiving the approval, the first and second devices can display the approval on a user interface of the online storefront and the customer application, respectively.

FIGS. 3A-B are illustrations of an example user interface of the first device when conducting the transaction. FIG. 3A is an example interface 300 of a shopping cart on a merchant's online storefront. A customer can use the first device to add items to the shopping cart. The shopping cart can include contact information 302 of the merchant. A customer has selected items 304 for purchase, e.g., a mocha and a cookie. The customer can choose to pick up the items in store or to be delivered to a customer's address. The item descriptions 304 include titles, prices, and quantities of the selected items. The shopping cart can display a total price 306 to the customer. The customer can interface with the checkout button 308 to continue purchasing the items.

FIG. 3B is an example interface 310 of the storefront after the customer interfaces with the checkout button 308. The first device can display a user interface, e.g., a text input field, to receive a unique identifier of the customer, as described above in reference to FIG. 2. For example, the online storefront displays a request for a mobile phone number of the customer 314. The customer can enter his or her mobile number 312, and the first device can send a notification to the second device, e.g., a mobile device associated with the mobile number.

FIGS. 4A-B are illustrations of an example user interface of the second device when conducting the transaction. FIG. 4A is an example interface 400 of the second device receiving the notification 402. The customer can interface with the notification, e.g., the customer can swipe the user interface to open an application that can finish conducting the transaction.

FIG. 4B is an example interface 404 of the application running on the second device. The application can display details of the items selected for purchase on the first device 406, e.g., the mocha, the cookie, and their respective quantities and prices. In some implementations, the customer can select an address 408 to ship the order to. However, because the customer previously selected the items for in-store pickup on the first device, the second device displays the already selected shipping option on the interface. After reviewing the items selected for purchase, the customer can swipe the “Swipe to Pay” button 410 to confirm purchase of the items. Upon receiving the swipe through the user interface, the second device can submit the transaction for authentication by a payment service system as described above in reference to FIGS. 1-2.

FIG. 5 is a flow chart of another example process 500 of verifying proximity when conducting a transaction using the first device and the second device. In some implementations, proximity between the first and second devices is not a prerequisite to completing the transaction, as described above. Instead, proximity can be considered as one factor in completing the transaction.

Similar to what is described above in reference to FIG. 2, the first device can receive first input to purchase one or more items for sale (step 502). The first device also receives a unique identifier for the customer (step 504). The first device sends, to the second device, a notification of the items selected for purchase (step 506). The second device displays details regarding the items selected for purchase (step 508). The second device receives second user input to confirm the purchase (step 510).

Then, a determination can be made, e.g., by one of the two devices or a server, as to whether the second device is in proximity to the first device (step 512). The determination can be made in the method described above in reference to FIG. 2. In some implementations, the second device determines whether it is in proximity to the first device and submits the determination along with the transaction details to a payment service system (step 514). In some other implementations, the second device submits the transaction details to the payment service system along with a location of the second device, e.g., obtained using GPS. The payment service system can determine, using the locations of the two devices, whether the first device is in proximity to the second device.

After receiving the determination, the payment service system can consider the proximity determination as a factor in determining whether to approve the transaction. For example, the payment service system can determine whether to approve transactions using a risk analysis system. The risk analysis system can weigh numerous factors, e.g., purchase history of the customer, transaction amount, a location of transaction, etc., before outputting a determination. If the second device is in proximity to the first device, the risk analysis system can determine the transaction is likely to be legitimate. That is, the risk analysis system can weigh the determination of proximity as a positive factor in approving the transaction. However, if the second device is not in proximity to the first device, the risk analysis system can approve the transaction only if certain safeguards are satisfied, e.g., the transaction amount is under a predetermined threshold or the customer has frequently purchased from the merchant. In some implementations, the risk analysis system has an increased purchase threshold if proximity was verified during the transaction. In some implementations, the risk analysis system rejects all transactions that occurred with the second device not being in proximity to the first device.

FIG. 6 is a block diagram of an exemplary architecture of a mobile device capable of running a customer application that conducts a transaction. Architecture 600 can be implemented in any device for generating the features described in reference to FIGS. 1-5, including but not limited to portable or desktop computers, smart phones and electronic tablets, television systems, game consoles, kiosks and the like. Architecture 600 can include memory interface 602, data processor(s), image processor(s) or central processing unit(s) 604, and peripherals interface 606. Memory interface 602, processor(s) 604 or peripherals interface 606 can be separate components or can be integrated in one or more integrated circuits. The various components can be coupled by one or more communication buses or signal lines.

Sensors, devices, and subsystems can be coupled to peripherals interface 606 to facilitate multiple functionalities. For example, motion sensor 610, light sensor 612, and proximity sensor 614 can be coupled to peripherals interface 606 to facilitate orientation, lighting, and proximity functions of the device. For example, in some implementations, light sensor 612 can be utilized to facilitate adjusting the brightness of touch surface 646. In some implementations, motion sensor 610 (e.g., an accelerometer, gyros) can be utilized to detect movement and orientation of the device. Accordingly, display objects or media can be presented according to a detected orientation (e.g., portrait or landscape).

Other sensors can also be connected to peripherals interface 606, such as a temperature sensor, a biometric sensor, or other sensing device, to facilitate related functionalities.

Location processor 615 (e.g., GPS receiver) can be connected to peripherals interface 606 to provide geo-positioning. Electronic magnetometer 616 (e.g., an integrated circuit chip) can also be connected to peripherals interface 606 to provide data that can be used to determine the direction of magnetic North. Thus, electronic magnetometer 616 can be used as an electronic compass.

Camera subsystem 620 and an optical sensor 622, e.g., a charged coupled device (CCD) or a complementary metal-oxide semiconductor (CMOS) optical sensor, can be utilized to facilitate camera functions, such as recording photographs and video clips.

Communication functions can be facilitated through one or more communication subsystems 624. Communication subsystem(s) 624 can include one or more wireless communication subsystems. Wireless communication subsystems 624 can include radio frequency receivers and transmitters and/or optical (e.g., infrared) receivers and transmitters. Wired communication system can include a port device, e.g., a Universal Serial Bus (USB) port or some other wired port connection that can be used to establish a wired connection to other computing devices, such as other communication devices, network access devices, a personal computer, a printer, a display screen, or other processing devices capable of receiving or transmitting data. The specific design and implementation of the communication subsystem 624 can depend on the communication network(s) or medium(s) over which the device is intended to operate. For example, a device may include wireless communication subsystems designed to operate over a global system for mobile communications (GSM) network, a GPRS network, an enhanced data GSM environment (EDGE) network, 802.x communication networks (e.g., WiFi, WiMax, or 3G networks), code division multiple access (CDMA) networks, and a Bluetooth™ network. Communication subsystems 624 may include hosting protocols such that the device may be configured as a base station for other wireless devices. As another example, the communication subsystems can allow the device to synchronize with a host device using one or more protocols, such as, for example, the TCP/IP protocol, HTTP protocol, UDP protocol, and any other known protocol.

Audio subsystem 626 can be coupled to a speaker 628 and one or more microphones 630 to facilitate voice-enabled functions, such as voice recognition, voice replication, digital recording, and telephony functions.

I/O subsystem 640 can include touch controller 642 and/or other input controller(s) 644. Touch controller 642 can be coupled to a touch surface 646. Touch surface 646 and touch controller 642 can, for example, detect contact and movement or break thereof using any of a number 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 touch surface 646. In one implementation, touch surface 646 can display virtual or soft buttons and a virtual keyboard, which can be used as an input/output device by the user.

Other input controller(s) 644 can be coupled to other input/control devices 648, such as one or more buttons, rocker switches, thumb-wheel, infrared port, USB port, and/or a pointer device such as a stylus. The one or more buttons (not shown) can include an up/down button for volume control of speaker 628 and/or microphone 630.

In some implementations, device 600 can present recorded audio and/or video files, such as MP3, AAC, and MPEG files. In some implementations, device 600 can include the functionality of an MP3 player and may include a pin connector for tethering to other devices. Other input/output and control devices can be used.

Memory interface 602 can be coupled to memory 650. Memory 650 can include high-speed random access memory or non-volatile memory, such as one or more magnetic disk storage devices, one or more optical storage devices, or flash memory (e.g., NAND, NOR). Memory 650 can store operating system 652, such as Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or an embedded operating system such as VxWorks. Operating system 652 may include instructions for handling basic system services and for performing hardware dependent tasks. In some implementations, operating system 652 can include a kernel (e.g., UNIX kernel).

Memory 650 may also store communication instructions 654 to facilitate communicating with one or more additional devices, one or more computers or servers. Communication instructions 654 can also be used to select an operational mode or communication medium for use by the device, based on a geographic location (obtained by the GPS/Navigation instructions 668) of the device. Memory 650 may include graphical user interface instructions 656 to facilitate graphic user interface processing; sensor processing instructions 658 to facilitate sensor-related processing and functions; phone instructions 660 to facilitate phone-related processes and functions; electronic messaging instructions 662 to facilitate electronic-messaging related processes and functions; web browsing instructions 664 to facilitate web browsing-related processes and functions and display GUIs; media processing instructions 666 to facilitate media processing-related processes and functions; GPS/Navigation instructions 668 to facilitate GPS and navigation-related processes; camera instructions 670 to facilitate camera-related processes and functions; and instructions 672 for running a customer application that conducts the transaction. The memory 650 may also store other software instructions for facilitating other processes, features and applications, such as applications related to navigation, social networking, location-based services or map displays.

Each of the above identified instructions and applications can correspond to a set of instructions for performing one or more functions described above. These instructions need not be implemented as separate software programs, procedures, or modules. Memory 650 can include additional instructions or fewer instructions. Furthermore, various functions of the mobile device may be implemented in hardware and/or in software, including in one or more signal processing and/or application specific integrated circuits.

Embodiments of the subject matter and the operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on a non-transitory computer storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or in addition, the program instructions can be encoded on an artificially-generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. A computer storage medium can be, or be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially-generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

The operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

The term “data processing apparatus” encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing The apparatus can include special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). The apparatus can also include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of them. The apparatus and execution environment can realize various different computing model infrastructures, such as web services, distributed computing and grid computing infrastructures.

A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language resource), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), to name just a few. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending resources to and receiving resources from a device that is used by the user; for example, by sending web pages to a web browser on a user's client device in response to requests received from the web browser.

Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back-end, middleware, or front-end components.

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server transmits data (e.g., an HTML page) to a client device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device). Data generated at the client device (e.g., a result of the user interaction) can be received from the client device at the server.

A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any inventions or of what may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous.