Patent ID: 12236429

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

DETAILED DESCRIPTION

As an overview, the system allows a user (also called a customer or payer) to purchase items from a merchant while physically present at the merchant, e.g., at the point of sale, but using a cardless payment transaction. A cardless payment transaction is one where a user conducts the transaction with a merchant at a point of sale using a financial account without physically presenting a payment card to the merchant at the point of sale. In fact, the merchant need not receive any details about the financial account, e.g., the credit card issuer, credit card number, and the like is not provided to the merchant.

From the user's perspective, the user first signs up for an account with the cardless payment system. The sign-up process requires certain information, such as information about a financial account sufficient to perform a transaction with the account. For example, if the financial account is a credit card account, then credit card information can be provided, e.g., credit card number and expiration date. The user can also sign up with other payment methods such as debit cards, pre-paid cards, bank accounts, or other third party financial accounts. The sign up process can also require contact information for the user, e.g., mailing address and email, and other personal identifying information, e.g., a photograph of the user. After creating an account, the user can select a merchant that also has an account with the cardless payment system. The user can give consent to perform a cardless payment transaction with the merchant if the user is within a predetermined distance from the merchant. After the user gives consent, the merchant can, without a presentment of the physical payment card, charge (in the case of credit cards) or debit (in the case of debit cards) the user's financial account for items the user wants to buy. Because the user's payment card is already on file with the cardless payment system, the user does not need to physically present a credit card to the merchant.

FIG.1is a schematic illustration of the architecture of an example cardless payment system100. The overall system100includes a user device102and merchant device104connected to a network, e.g., the Internet106. The user device102is a mobile computing device, i.e., a hand-held computing device, capable of running a user application. For example, the user device102can be a smartphone or tablet computer. The merchant device104is also a computing device, capable of running a merchant application. The merchant device104can be a mobile device, or it can be a desktop computer, a laptop computer, a dedicated point of sale system, or other data processing apparatus.

A cardless payment processor operates a payment service system108. The user and merchant devices can communicate with the payment service system108using the network106. The payment service system108includes an application server110and a secure server112to processes all transactions between the user device102and merchant device104. In general, the application server110handles non-secure information. For example, it can store public merchant information such as the merchant's address or phone number. The application server110can also be responsible for transferring or updating the user application to the user's mobile device or transferring or updating the merchant application to the merchant's computing device. In particular, the application server112can be responsible for sending information about merchants that have accounts with the cardless payment system to the user device102. The secure server112handles secure information such as credit card numbers, debit card numbers, bank accounts, user accounts, user identifying information or other sensitive information.

The payment service system108can communicate electronically with a card payment network116, e.g., Visa, Mastercard, or the like. The payment service system108can communicate with a computer system116of a card payment network, e.g., Visa or MasterCard. The payment service system108can communicate with a computer system116over the same network106used to communicate with the user device102, or over a different network. The computer system116of the card payment network can communicate in turn with a computer system118of 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 system108and the card issuer.

Before a transaction between the user and the merchant can be performed using the cardless payment system, the user must create a user account with the payment service system108and the merchant must create a merchant account with the payment service system108.

The user can sign up using a mobile application or using an online website, and can use the mobile device102or another computing device, e.g., a home computer. At some point prior to the transaction, a user application is downloaded to the user device102, e.g., through an application store. Creation of the user account can be handled through the user application, or through another application, e.g., a generic web browser. The user enters a name, account password, and contact information, e.g., email address. Before a transaction can be performed, the user also enters financial account information sufficient to conduct the transaction into the payment service system108. For example, in the case of a credit card account, the user can enter the credit card issuer, credit card number and expiration date into the payment service system108; the card validation value and mailing address may also be required. However, the financial account could also be associated with a debit card or pre-paid card, or another third party financial account.

In some implementations, the payment service system108requires additional personal identifying information before a transaction can be performed. For example, the payment service system108may require a photo of the user before a transaction can be performed. The photo of the user would be provided to the merchant so that the merchant can compare the photo to the person. In addition, the payment service system108can require a personal identification number (PIN) be entered by the user. Other requirements can also be added to increase security. The data associated with a user account114can be stored at the secure server112, e.g., in a database.

If the user is signing up with a mobile application, the user's financial account information can be entered by swiping the financial transaction card through a slot of a card reader coupled to the mobile device. Alternatively, the user can enter in financial account information by typing in information at the mobile device102, selecting a card from an application on the mobile device, from an online entity, or others. In some implementations, another external application generates a receipt that is sent to the user. The receipt then includes a hypertext link that allows a user to easily create a user account in the cardless payment system. For example, activating the link in the receipt can automatically create a user account with a payment card prefilled with the card used in the receipt to reduce effort by the user. In effect, activating a new account using a receipt auto-verifies the user into the cardless payment system.

The merchant can sign up for an account using the merchant device104or another device. The merchant enters a name, account password, and contact information, e.g., email address, and physical location information, e.g., an address, into the payment service system108. The merchant can also provide other information, e.g., a list of goods or services available, operating hours, phone number, a small identifying image logo or mark, to the payment service system108. The data associated with the merchant account114can be stored at the secure server112, e.g., in a database.

At some point prior to the transaction, a merchant application is downloaded to the merchant device102, e.g., through an application store. Creation of the merchant account can be handled through the merchant application, or through another application, e.g., a generic web browser.

Eventually, in order to receive funds from the transaction, the merchant will need to enter financial account information into the payment service system sufficient to receive funds. For example, in the case of a bank account, the user can enter the bank account number and routing number. However, 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 cardless payment processor can hold the received funds until the financial account information is provided.

FIG.2is a diagram that outlines an example implementation of the cardless payment system100. A user carries a mobile device102with the user application installed, and a merchant has a device104with the merchant application installed. Users and merchants each have an association, e.g., an account, with the payment service system108.

The system can predetermine a geo-location distance206, e.g., a radius, around the location of the merchant. In some implementations, the geo-location distance206is 500 feet. In some implementations, the geo-location distance206can be set by the merchant, e.g., the payment service system108receives input from the merchant device104or another computer system of the merchant setting the location radius. In some implementations, the payment service system108may limit the radius set by the merchant to a maximum location radius.

If the user device is located outside the geo-location radius206of the merchant, the merchant application does not provide an option to conduct a cardless payment transaction with the user. In this case, the user device102will indicate it is outside the geo-location radius206of the merchant, and the merchant device104will be unable to charge the user's financial account, as further described inFIG.3andFIG.6.

However, a user can create or configure a tab with the merchant at any geographical location using an application on the user device102, or on another device, e.g., another mobile device or on a home computer, that is granted access to the user's account. A tab is a relationship between the user, the payment service system108, and the merchant. Once a tab is created, the user device102saves the merchant's information, e.g., the name and location of the merchant, and the user device102can display information about the merchant a main view of the application as further described inFIG.4when the application is active. If the tab is created by the user using a device other than the user device102, then the payment service system108will provide the merchant information to the user device102.

If the user device102is located within the geo-location radius206of the merchant, the user can “open a tab” with the merchant using an application on the user device102as further described inFIG.3andFIG.5. The user can configure the tab to “auto-open” the tab once the user is within the geo-location radius206of the merchant, which will be further described below. In some implementations, the user can configure a tab to set a maximum amount that can be charged per transaction with the merchant.

Opening a tab with a merchant allows the merchant application to display an option to charge the user's financial account using a cardless payment transaction. In essence, opening the tab constitutes a consent by the user to conducting a cardless transaction with the merchant. This consent differs from actual authorization of the transaction, which the user would provide, e.g., verbally, upon learning the amount of the transaction.

In some implementations, in order to determine whether user device102is within the geo-location radius206of the merchant device104, the merchant's location, e.g., address, and the geo-location radius206for the merchant are provided to the user device102. The user device102can then use a geofencing function. For example, the user device102determines its own location, e.g., based on GPS information, cellphone data, wireless network data, or the like, and then determines whether its own location is within the geo-location radius206of the merchant location.

FIG.3is a diagram of an example flow chart of process conducted with the cardless payment system100. The process conducted with the cardless payment system100involves relationships between a user's mobile device, a server system, and a merchant's device. The server system can reside in the payment service system108and be configured to send and receive communications between the user device and the merchant device. The server system can include the application server110and/or the secure server112. The communications can be encrypted using secure protocols built into the user device, server system, and merchant device. In some implementations, this process is implemented through the applications installed on both the user's mobile device and the merchant's device.

In a typical situation, the user enters a request into the mobile device102to identify a merchant that will perform cardless payment transactions. The mobile device102directs the request to the server system. The request can be accompanied by location information, e.g., as determined by the mobile device102. The server system receives the request, and selects one or more merchants based on the location information from the customer and the stored location information for the merchant. At least an identification of the merchant and the location information for the merchant is sent to the mobile device102.

The user may input a request for further information about a merchant, e.g., press a “details” button on the user interface of the user application. In response, the user device can display further information received from the merchant, e.g., the list of goods or services available, operating hours, and phone number.

The user sends an indication of consent to perform a cardless payment transaction with the merchant to the server system. For example, the user can request to “open a tab” at a merchant by interfacing with the user application on the user device (step302); this request can constitute the indication of consent.

Alternatively, the request to identify a merchant, the display of information concerning the merchant, and/or the indication of consent, could be entered into a computer other than the user device102, e.g., the user's home computer, that is logged in to the user's account on the payment service system108. In any event, should the user indicate consent to perform the transaction, at least an identification of the merchant and the location information for the merchant is sent to the mobile device102.

The mobile device determines whether it is within the predetermined distance from the merchant (step304). In some implementations, if the mobile device does not have the current location of the merchant, or if the merchant updated its location information, the merchant location can be pushed or pulled into the mobile device. Alternatively, if the user opts in to sharing of location information, the location information of the mobile device can be provided to the server of the payment service system108, and the server determines the distance between the merchant and the mobile device.

As described above, if the mobile device determines the user's mobile device is not within a predetermined distance (e.g. 500 feet), the mobile device displays a message indicating its inability to open a tab and rejecting the user's request (step308). In this case, the mobile device can create or configure a tab, but cannot open a tab. In other words, the merchant cannot charge the user's financial account using a cardless payment transaction until the user is within the predetermined distance and the merchant has the user's consent. This is further described inFIG.6.

On the other hand, if the mobile device is within the predetermined distance, the mobile device sends an indication of proximity to the server of the payment service system (step306). In some implementations, the user can “auto-open” a tab. For example, the user first requests that a tab be “auto-opened.” While a tab is configured to be “auto-opened”, the mobile device can automatically detect when it is within the predetermined distance and send the indication of proximity, which will be described further inFIG.5. The indication of proximity can be determined using wireless network geo-fencing or GPS signals. In some implementations, if the mobile device is not within the predetermined distance, the user application will not permit the indication of consent to be input. In some implementations, if the mobile device is not within the predetermined distance when an indication of consent is input, the user application will require that the user again input an indication of consent when the mobile device is within the predetermined distance.

After the server receives this indication of proximity, the server system sends the indication of the mobile device's presence and personal identifying information to the merchant device (step310). In some implementations, personal identifying information includes the user's name and picture. Upon receipt of this information, the merchant device displays a tab (step312) and the user's identifying information (step314) on the graphical user interface (GUI) of the merchant application. In some implementations, through the GUI of the merchant application, the merchant can select items that the user has sought to purchase. The application can be configured to associate individual prices with each of the merchant's items, and the application can automatically sum the total transaction amount that the user owes. In some implementations, the merchant can enter into the application a total sum of prices for all the items the user wishes to purchase, as well as tax or tip. A user can authorize payment for a tab by verbally notifying the merchant. For example, a user named John Smith can tell the merchant, “Put this on John Smith.” Before or after the user authorizes payment for the tab, the merchant verifies the user's identity (step316). In some implementations, the merchant ensures the image displayed on the merchant device matches the user who is present in person. Assuming that the image matches, the merchant selects the user's tab using the GUI of the merchant application. In some implementations, the merchant can ask the user for more identifying information before processing the transaction such as the user's birthday, address, or other personal identifying information. After verifying the user's identity, the merchant interfaces with the merchant application to start processing the transaction.

In some implementations, the amount to be charged exceeds a predetermined amount set by the user, the merchant or the cardless payment processor. In this case, the user enters in a PIN associated with the user's account into the merchant device. The merchant device verifies the PIN with the server. Alternatively, the server system may communicate with the user device and cause the user device to requested that the user enter the PIN into the user device. In yet another alternative, the server system can ask the user to confirm the payment on the user device, removing the need to enter a PIN.

The merchant's device sends a record of the requested transaction to the server (step318). The server system continues processing the requested transaction (step320) by sending the record to the computer system of the card payment network116, e.g., Visa or MasterCard, and the card payment network116then sends the record to the card issuer, e.g., the bank, as described above.

If the transaction fails because it would exceed the credit limit or there are insufficient funds in the financial account, the server notifies the merchant application. In some implementations, the server can notify both the merchant application and user application.

If the transaction succeeds and the server system receives approval from the card payment network116, the server system communicates this to the merchant device. The merchant device then captures the transaction. In the capture stage, the approved transaction is again routed from the merchant to the credit card processor, card network and card issuer. The record of the transaction in the capture stage can the cardholder's signature (if appropriate), or other information. The capture state can trigger the financial transaction between the card issuer and the merchant. On receipt of an indication from the card network that the transaction has been captured, the server system optionally creates receipts to send to the user, e.g., through the user application and/or through the previously provided contact email, and to the merchant (step322). Both devices then display the receipt in each of their applications (steps324,326). Optionally, the user may be permitted to opt out of notification.

FIG.4is a diagram of an example view of the application's main page on the user's mobile device402. In some implementations, each entity (e.g. user or merchant) is represented as a card and relationships between the user and user-selected merchants are represented as cards stored in a card case422. The card case422can display the user's initials424. The edges of the card case422can be a dashed line to mimic stitching of a wallet. Each card can contain a picture representing a logo or a profile picture412,414,416,418. For example, a user named John Smith can access his user account information by tapping the John Smith card404. Each merchant can be represented with a custom-designed card. In some implementations, tapping the card of Merchant 1406, Merchant 2108, or Merchant 3410will cause the mobile device402to display an option to either “Open a tab” or “Show details” regarding the merchant. In some implementations, directing the user device to open a tab will follow the process ofFIG.3. In some implementations, showing more details will display a custom merchant page indicating information regarding the merchant. For example, the mobile device can display a map around the merchant's area, the merchant's phone number, the merchant's operating hours, or other merchant information. The application also allows the user to “Explore Places”420. In some implementations, this opens a list of nearby or featured merchants that are associated with the cardless payment system. A user then has an option to add one of the merchants in the list to the “card case” view of the user's application.

FIG.5is a diagram of an example application view504of a user that has opened a tab at a merchant inside the predetermined distance from the merchant. This view can show the name of the merchant or the merchant's logo506. In some implementations, because the user's credit card is already in the cardless payment system, the user does not need to physically give a credit card to the merchant. For example, once a user named John Smith wants to checkout with a few items, John Smith can pay by verbally telling a cashier “Put it on John Smith”508. The cashier can verify John's identity as described above. A user can also press a “Cancel Payment” button510to close the tab for the merchant. Closing the tab will prevent the merchant and the merchant's device from charging the user using a cardless payment transaction. In some implementations, merchants can also close the tab on the merchant device; information that the tab is closed is transmitted to the server system and then to the mobile device, causing the tab (if being displayed) to close on the mobile device as well. In some implementations, tabs automatically close after a transaction has been approved. In some implementations, tabs automatically close after a preset amount of time, e.g., if no transaction has occurred. In some implementations, a tab can be auto-opened512. If this is turned on, the user has given consent to open a tab automatically whenever the user's mobile device is within the predetermined distance from the merchant. The mobile device then can automatically detect in the background when it is within the predetermined distance and automatically sends, also in the background, an indication of proximity to a server in the payment service system as described above. The user can choose to engage in a cardless payment transaction with the merchant without ever bringing the application to the foreground. Therefore, in some implementations, this removes the need to run the application on a main thread of the device's processor. In other words, the user does not need to start the application when inside the predetermined distance and tap “Open a tab”. In practice, with Auto Open Tab turned on, John Smith, holding his mobile device502, can walk to a merchant from outside the predetermined distance, order an item for sale, and pay using the cardless payment system without interfacing with his mobile device502at the point of sale. In some implementations, the cardless payment system can limit the “auto-open” functionality to merchants with a fixed location for security reasons.

FIG.6is a diagram600of an example application view604with a user that has attempted to open a tab at a merchant outside the predetermined distance from the merchant610. In some implementations, the view shows a map614of the user's current location612and the location of the merchant608with a predetermined distance surrounding the merchant610. In some implementations, the device can provide directions from the user's location612to the merchant's location608. The device can also calculate or display how far away the user's current location612is from the merchant's location608. For example, the text can read “0.4 mi away, too far to open tab”616. In this case, because the user's mobile device602is outside the predetermined distance from the merchant, the user and the merchant cannot engage in a cardless payment transaction. Pressing the Done button can close this view606. In some implementations, this view of the application also allows the user to “Always Auto Open Tab”618as described above.

FIG.7is a diagram of an example view700of a merchant device's application702. If a user is associated with the cardless payment system and is within the predetermined distance from the merchant, the device can display the user's identifying information in the application. In some implementations, the identifying information includes the user's name710, picture708, phone number, email address, or other personal identifying information. In some implementations, after verifying the user's identity using the identifying information, the merchant enters in a tab706into the application using the keypad704, shows the user the amount to be charged, and taps the “Ok” button712to cause the device to process the transaction.

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 components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

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.

Thus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. 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.