Patent ID: 12236405

DETAILED DESCRIPTION

Before turning to the figures, which illustrate example embodiments, it should be understood that the application is not limited to the details or methodology set forth in the following description or illustrated in the figures. It should also be understood that the phraseology and terminology employed herein is for the purpose of description only and should not be regarded as limiting.

The access, or gig, economy has created a tremendous amount of jobs in the last decade. The rise of access based services, such as ride-sharing, home rentals, consumer directed services, etc., has created sources of income for supplier's goods and/or services within the access economy and allowed many consumers to reap the benefits of access to the supplied goods and/or services. As the access economy has grown, many access service providers, such as Uber® and Airbnb®, have come onto the market to create entry points into the access economy. These service providers not only serve to connect consumers to suppliers but also to provide support to the suppliers, such as by providing payment services (e.g. facilitating payments between the consumers and the suppliers), payrolls services (e.g. tax withholding), scheduling services, and other services. While these services make many aspects of participating in the access economy more practical for suppliers, it can often be the case that payment is not provided until after the requested services or good rental is completed, sometimes a significant amount of time after completion.

Financial institutions (FIs) are generally involved with the access economy by facilitating the transfer of funds from the consumer to the supplier. Often, FIs control the transfer of money from a consumer account to a service provider associated with the requested service or good. The service provider then facilitates payment to the supplier, often with taxes as well as any fees (regulatory or internal to the service provider) withheld by the service provider. The remaining funds are then transferred to an account associated with the supplier. Accordingly, FIs and the service providers interact with each other to control the flow of payment from the consumer to the supplier. This system is functional but may create issues where the service takes place over a certain period of time or where there are expenses associated with the rental of the services or goods that may be required to be borne by the supplier until payment is received from the service provider.

Referring generally to the figures, systems and methods for providing a real-time trickle payment for an access economy based interaction are shown. According to various embodiments, a work events monitoring system can provide an interface between a user (via a user device) and a supplier (via a service monitoring device). The work events monitoring system may be further in communication with FIs associated with the supplier and the consumer to facilitate the transfer of funds between the respective FIs. Further, the work events monitoring system can generate one or more smart contracts associated with the service or good being provided to the consumer by the supplier. The smart contracts may be used to establish which service or good will be provided to the consumer and what price the consumer will pay for access to the good or service. In some embodiments, the work events monitoring system can configure the smart contracts such that payments are made in real time based on the usage of the good by the consumer and/or the amount of service provided by the supplier to the consumer. This can allow the supplier to be paid nearly contemporaneously with the performance of a service and/or rental of a good.

According to various embodiments, described in further detail below, utilizing smart contracts in combination with constantly monitoring the performance of a service for the duration of a rental can provide an improved interface between consumers and suppliers in an access economy transaction by allowing for real-time payments to be made to the supplier based on the terms set by the smart contract. By allowing payments to be automatically allocated to the supplier based on the performance of a service (trickle payments), additional value-add functionality can be achieved as the supplier can receive payments throughout the performance of the service, or rental of the good, thereby allowing the supplier to have access to funds which may be needed to complete the service. This can reduce hesitation by suppliers to provide goods or services due to timing issues with receiving payment for supplying the access economy goods and/or services. Further, utilizing real-time trickle payments can allow the consumer to be sure that they will not be charged or be required to pay for a service not rendered by the supplier. Accordingly, the embodiments described herein solve the technical and internet-centric problems of providing real-time trickle payments to a user based on the services or goods actually utilized at a given moment.

FIG.1is a block diagram of an access economy service system100, according to an embodiment. The access economy service system100may include a work event monitoring system102, a supplier FI104, a consumer FI106, a supplier108, a consumer110, a work mechanism112, and a user device114. In some embodiments, the work mechanism112may include a service monitoring device116. In one embodiment, the work event monitoring system102may be a service provider associated with an access economy service. For example, the work event monitoring system102may be associated with an access economy service, such as a ride share service (e.g. Uber®, Lyft®, etc.). In other examples, the work event monitoring system102may be associated with other access economy services, such as home rental services (e.g. Airbnb®), plane sharing services, boat sharing services, etc. Other services, such as flexible employment services (e.g. Amazon® Flex), IT timeshare services, legal services, mechanic services, food delivery services, medical services, etc., may be further examples of access economy services provided by the work event monitoring system102. The above-listed access economy services are for illustrative purposes only and do not limit the number or type of access economy services that may be provided via the work event monitoring system102.

The work event monitoring system102, the user device114and the service monitoring device116may each include a computer system (e.g., one or more servers, each with one or more processing circuits), each including a processor and a memory. The processors may be implemented as application specific integrated circuits (ASICs), one or more field programmable gate arrays (PFGAs), a group of processing components, or other suitable electronic processing components. The memory may be one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage, etc.) for storing data and/or computer code for completing and/or facilitating the various processes described herein. The memory may be, or include, non-transient volatile memory, non-volatile memory, and non-transitory computer storage media. The memory may include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described herein. The memory may be communicably connected to the processor and may include computer code or instructions for executing one or more processes described herein. The work event monitoring system102may include a server-based computing system, comprising, for example, one or more networked computer servers that are programmed to perform the operations described herein. The work event monitoring system102may be implemented as a distributed computer system where each function is spread over multiple computer systems.

The work event monitoring system102may be a centralized server connected to one or more of the other listed components within the access economy service system100via a network. In some embodiments, the network may be an internet based network. For example, all components of access economy service system100may be in communication with a cloud-based network, as will be described in more detail below. In some embodiments, the network connections between the components are wired network connections, such as a TCP/IP network. In other embodiments, the network connections may be wireless network, such as Wi-Fi, Wi-Max, cellular (3G, 4G, LTE, CDMA), LORA, Zigbee, Near Field Communication (NFC), Bluetooth, or any other applicable wireless network protocols. In some embodiments, the work event monitoring system102is hosted by a third party, such as a access economy service provider. In other embodiments, the work event monitoring system102may be associated with one or more FIs within the access economy service system100. For example, the work event monitoring system102may be associated with one or more of the supplier FI104and the consumer FI106.

The supplier FI104is an FI associated with the supplier108of an access economy good or service, such as those described above. In one embodiment, the supplier FI104is a bank. However, in other examples, the supplier FI104may be a credit union, a brokerage house, or other applicable type of FI that the supplier108may use to perform financial transactions. Similarly, the consumer FI106is an FI associated with the consumer110of an access economy good or service, such as those described above. In one embodiment, the consumer FI106is a bank. However, in other examples, the consumer FI106may be a credit union, a brokerage house, or other applicable type of FI that the supplier108may use to perform financial transactions. As shown inFIG.1, the supplier FI104and the consumer FI106are separate entities; however, it is contemplated that the supplier FI104and the consumer FI106may be the same entity in some embodiments.

For purposes of this disclosure, the supplier108is understood to be a supplier of a good or service in an access economy, and the consumer110is understood to be a consumer, or purchaser, of the goods or services supplied by the supplier108in the access economy. In some examples, the supplier108and/or consumer110may be institutions, groups of persons, co-ops, partnerships, or other groups either suppling or consuming the goods or services.

In one embodiment, the supplier108may be in communication with the work mechanism112. In one embodiment, the work mechanism112is a physical embodiment of the good or service supplied by the supplier108. For example, where the supplier108is supplying a service, such as a ride-sharing service, the work mechanism112may be the supplier's108vehicle. In other examples, such as where the service is a home sharing service, the work mechanism112may be the home itself. In a further example, the work mechanism112may be a plane (plane sharing service), a boat (boat sharing service), or simply labor, such as where the contracted service is for professional services (e.g. mechanic services, legal services, medical services, caregiver services, food preparation services, etc.). In general, the work mechanism112can be any device and/or service provided to a consumer110by the supplier108.

In some embodiments, the work mechanism112includes the service monitoring device116. The service monitoring device116may be any device that provides monitoring of the supplied good or/service. For example, where the access economy service is a ride sharing service, the service monitoring device116may be a device that monitors the distance travelled for a particular ride, as well as the duration of a given ride. In some examples, the service monitoring device116may monitor other parameters associated with a ride, such as fuel expended, number of passengers, time of day, tolls or other required fees that were paid during the duration of the trip, etc., In some examples, the service monitoring device116may be a device that can be plugged into a communication port of the work mechanism112. For example, where the work mechanism112is a vehicle, the service monitoring device116may plug into the vehicle's OBD-II port. In other embodiments, the service monitoring device116may connect to the vehicle via a wireless connection, such as via Bluetooth. In still other embodiments, the service monitoring device116may be able to communicate with the vehicle via a Universal Serial Bus (USB) port.

In some embodiments, the service monitoring device116may be a software application associated with a personal device of the supplier108, such as a smartphone. For example, where the access economy service is a ride sharing service, the supplier108may have a software application on their smartphone, or other portable smart device, which can utilize sensors within the smartphone to monitor the work being performed. For example, the application may use a GPS sensor associated with the device of the supplier108to monitor the distance travelled. In other examples, a software application may be used as the service monitoring device116for other types of access economy services, such as home rentals, professional services, or any other type of access economy service. For example, where the access economy service is a home rental service, a software application may be provided to a user device associated with the consumer110, such as user device114. The consumer110may check into and out of the home using the software application on the user device114. Similarly, where the access economy service is related to rental of other goods, such as cars, boats, planes, etc., the consumer110may have a software application on the user device114, allowing the consumer110to “check-in” when they begin using the good and “check-out” when they finish. In some embodiments, sensors within the user device114may be used to provide an indication when the consumer110starts and stops using the good. In other embodiments, the supplier108may install one or more service monitoring devices116in the goods to be used that can monitor when the consumer110starts and stops using the good. In some embodiments, the service monitoring device may be one or more internet of things (IoT) devices. For example, where the access economy service is a home rental, a connect smart-lock may monitor when the consumer enters or leaves the property. Further, other IoT devices, such as connected sensors, cameras, thermostats, lights, appliances, and the like may be used to monitor the use of the supplied good or service.

In some embodiments, the service monitoring device116may be a simple interface that can allow the supplier108to indicate when they begin and end the provision of a service. For example, where the access economy service is a professional service, such as legal services, the supplier108may be able to indicate on a software application when the work is being done. In further embodiments, the supplier108may use the service monitoring device116, such as a smartphone with a software application, to initiate communications with the consumer110. For example, where the professional service is a counseling service (e.g., medical counseling, legal counseling, etc.), the service monitoring device116may provide the interface between the supplier108and the consumer110, such as by providing a video conference between the parties. In some embodiments, the service monitoring device116is associated with the work event monitoring system102. For example, where the service monitoring device116is a physical device, such as a monitoring device for plugging into a vehicle, the service monitoring device116may be supplied by the work event monitoring system102(i.e. the access economy service provider) as part of participating in the service. In other embodiments, the work event monitoring system102may provide a software application, such as those described above, for download by the supplier108and/or the consumer110.

The user device114may be any device associated with the consumer110that can communicate with one or more of the work event monitoring system102, the work mechanism112, and/or the service monitoring device116. In some embodiments, the user device114may be a user interface on an internet accessible website. In other embodiments, the user device114may be a mobile device associated with the consumer110. Example mobile devices can include smartphones (iphone, Android phones, Windows phones, etc.), tablet computers (iPad, Android tablet, Microsoft Surface, etc.), laptop computers, wearable devices, or any other device capable of communicating with the work event monitoring system102. In one embodiment, the user device114is used to provide access to the work event monitoring system102.

In some embodiments, the work event monitoring system102may be configured to generate one or more smart contracts118. The smart contracts118may be computer protocols that facilitate, verify, or enforce the performance of a contract. In one embodiment, the work event monitoring system102may generate the smart contracts118based on terms agreed upon by the supplier108and the consumer110as related to an access economy service. For example, where the access economy service is a ride sharing service, the smart contracts118may include terms such as rate per unit of distance, responsibility of fees (i.e. tolls, parking fees, etc.), surcharges, responsibility of the driver, etc. In other examples, the smart contracts118may include retainers or advance payments for certain services, such as legal or medical services. In one embodiment, the supplier108and the consumer110may review and accept the terms of the smart contract using personal devices, such as service monitoring device116, and/or user device114. However, other devices or methods, such as via a web-portal, may be used to review and accept the terms of the smart contract between the supplier108and the consumer110. The supplier108and the consumer110may generally agree to the terms of a smart contract during the initial sign-up to participate in the access economy service. As will be described in more detail below, the smart contracts118can provide for real-time trickle payments to be made within an access economy service by establishing the terms as to how the payments will be made during performance of the service.

Turning now toFIG.2, real-time trickle payment system200is shown, according to an embodiment. In one embodiment, the real-time trickle payment system200can be configured for use by the access economy service system100described above. For purposes of brevity, the system200is discussed below in connection with the access economy service system100ofFIG.1. However, it should be understood that the real-time trickle payment system200can be configured for use with other access economy service systems as well.

As shown inFIG.2, the consumer110may be associated with the user device114. The user device114may have a network interface circuit202and an application manager204. The network interface circuit202facilitates data communications to and from a network206. The network interface circuit202may be configured to communicate wirelessly with the network206, such as via Wi-Fi, Bluetooth, NFC, Zigbee, IR, RF, Cellular (3G, 4G, LTE, CDMA), etc. In other embodiments, the network interface circuit202may communicate with the network206via a wired connection, such as via Ethernet, a LAN, a WAN, Firewire, USB, or other applicable wired interface. In some embodiments, data passing through the network interface circuit202is encrypted.

The application manager204is configured to manage one or more software applications (apps) associated with the user device114. For example, the application manager204may manage an FI app208and an access service app210. The FI app208may be a mobile banking application associated with an FI used by the consumer110, such as consumer FI106. In one embodiment, the FI app208allows for direct communication between the user device114and the consumer FI106. In further examples, the FI app208may be a mobile wallet application. The access service app210may be configured to allow for an interface into an access economy service via the user device114. For example, the access service app210may be an application for use in connection with the work event monitoring system102. For example, the consumer110may download the access service app210from the work event monitoring system102in order to access the access economy service. Further, as described above, the access service app210may serve as a service monitoring device116by allowing the consumer110to interact with the work event monitoring system102as a service is being performed. In one embodiment, the application manager204processes requests from the network interface circuit202to execute one or more applications. For example, the network interface circuit202may receive a request to open the access service app210to allow an access economy service transaction to occur. In a further embodiment, the application manager204controls access between applications, such as the FI app208and the access service app210.

The supplier108may be associated with a work mechanism112. The work mechanism112may be any work mechanism112as described above. For example, the work mechanism112can be a vehicle, a home, or any other good or service within the access based economy. The work mechanism112may be in communication with the service monitoring device116, as described above. The service monitoring device116may include a network interface circuit212and an access service app214. The network interface circuit212facilitates data communications to and from the network206. The network interface circuit212may be configured to communicate wirelessly with the network206, such as via Wi-Fi, Bluetooth, NFC, Zigbee, IR, RF, Cellular (3G, 4G, LTE, CDMA), etc. In other embodiments, the network interface circuit212may communicate with the network206via a wired connection, such as via Ethernet, a LAN, a WAN, Firewire, USB, or other applicable wired interface. In some embodiments, data passing through the network interface circuit212is encrypted.

The access service app214may be configured to allow an interface into an access economy service via the user device114. For example, the access service app214may be an application to be used in connection with the work event monitoring system102. For example, the supplier108may download the access service app210from the work event monitoring system102in order to access the access economy service. Further, as described above, the access service app214may work with the service monitoring device122to interact with the work event monitoring system102as a service is being performed. In some embodiments, the access service app214interfaces directly with the work event monitoring system102via the network interface circuit212.

The supplier FI104may include a supplier FI computing system216. The supplier FI computing system216may process transaction requests presented to the supplier FI104. For example, the supplier FI computing system216may process all payments associated with the supplier108supplying access economy goods and/or services. The supplier FI computing system216may include a network interface circuit218and a supplier FI sub-account generation circuit220. The network interface circuit218facilitates data communications to and from the network206. The network interface circuit218may be configured to communicate wirelessly with the network206, such as via Wi-Fi, Bluetooth, NFC, Zigbee, IR, RF, Cellular (3G, 4G, LTE, CDMA), etc. In other embodiments, the network interface circuit218may communicate with the network206via a wired connection, such as via Ethernet, a LAN, a WAN, Firewire, USB, or other applicable wired interface. In some embodiments, data passing through the network interface circuit218is encrypted.

The supplier FI sub-account generation circuit220may be configured to generate one or more sub-accounts associated with a specific transaction performed by the supplier108. As will be discussed in more detail below, these sub-accounts may be used to provide real-time trickle payments to the supplier108from the consumer110as the supplier108supplies access economy goods or services. In some embodiments, the supplier FI sub-account generation circuit220may create a sub-account associated with a specific access economy service transaction between the supplier108and the consumer110. The sub-account may have funds deposited to it from the consumer FI106with an amount associated with the transaction. A hold may be placed on the funds in the sub-account until the access economy service transaction is complete. In some embodiments, the hold may be released based on a percentage of the transaction having been completed. For example, where the access economy service is a ride-sharing service, an amount may be estimated by the work event monitoring system102based on an expected time and distance required to deliver the consumer110to their desired destination. Funds may then be transferred to a supplier sub-account within the supplier FI104and a hold placed on the funds. As the ride progresses, the hold may be removed in proportion to the percentage of the trip that has occurred. In other examples, funds may be directly transferred in real time between the consumer FI106and the supplier FI104in proportion to the percentage of the trip that has occurred.

Similar to the supplier FI104, the consumer FI106may include a consumer FI computing system222. The consumer FI computing system222may process transaction requests presented to the consumer FI106. For example, the consumer FI computing system222may process all payments associated with the consumer110utilizing an access economy good and/or service. The consumer FI computing system222may include a network interface circuit224and a consumer FI sub-account generation circuit226. The network interface circuit224facilitates data communications to and from the network206. The network interface circuit224may be configured to communicate wirelessly with the network206, such as via Wi-Fi, Bluetooth, NFC, Zigbee, IR, RF, Cellular (3G, 4G, LTE, CDMA), etc. In other embodiments, the network interface circuit218may communicate with the network206via a wired connection, such as via Ethernet, a LAN, a WAN, Firewire, USB, or other applicable wired interface. In some embodiments, data passing through the network interface circuit218is encrypted.

The consumer FI sub-account generation circuit226may be configured to generate one or more sub-accounts associated with a specific transaction requested by the consumer110. As will be discussed in more detail below, these sub-accounts may be used to provide real-time trickle payments to the supplier108from the consumer110, as the consumer110consumes access economy goods or services. In some embodiments, the consumer FI sub-account generation circuit226may create a sub-account associated with a specific access economy service transaction between the supplier108and the consumer110. The sub-account may have funds deposited to it from the consumer FI106with an amount associated with the transaction. A hold may be placed on the funds in the sub-account once the access economy service transaction is completed. In some embodiments, the hold may be increased based on a percentage of the transaction having been completed. For example, where the access economy service is a ride-sharing service, an amount may be estimated by the work event monitoring system102based on an expected time and distance required to deliver the consumer110to their desired destination. Funds may then be transferred to a supplier sub-account within the supplier FI104and a hold placed on the funds. As the ride progresses, the hold may be increased in proportion to the percentage of the trip that has occurred. The process for providing real-time trickle payments will be discussed in more detail below.

The real-time trickle payment system200further includes the work event monitoring system102. As described above, the work event monitoring system102can provide access to the access based economy for both the supplier108and the consumer110. The work event monitoring system102may include a network interface circuit228, a third party interface circuit230, a smart contract generation circuit232, and a work monitoring circuit234. The network interface circuit228facilitates data communications to and from a network206. This can allow the work event monitoring system102to be in communication with the user device114, the service monitoring device116, the supplier FI104, the consumer FI106, as well as other systems and devices in communication with the network206. The network interface circuit228may be configured to communicate wirelessly with the network206, such as via Wi-Fi, Bluetooth, NFC, Zigbee, IR, RF, Cellular (3G, 4G, LTE, CDMA), etc. In other embodiments, the network interface circuit202may communicate with the network206via a wired connection, such as via Ethernet, a LAN, a WAN, Firewire, USB, or other applicable wired interface. In some embodiments, data passing through the network interface circuit228is encrypted.

The third party interface circuit230can allow a third party, such as an access economy service provider to interface with the work event monitoring system102. For example, the service provider may want to directly interface with the work event monitoring system102to ensure proper service is being provided. In other examples, the service provider may interface with the work event monitoring system102via the third party interface circuit230to determine what, if any, fees are due to be paid to the service provider as part of providing access to the access economy service. In some embodiments, the third party interface circuit230may be in communication with a service provider FI236to process payments allocated to the service provider. For example, the third party interface circuit230may be in contact with the consumer FI106to coordinate payments between the consumer FI106and an FI associated with the service provider.

The smart contract generation circuit232can generate one or more smart contracts associated with a transactions, such as the smart contracts118described above. In one embodiment, the smart contract generation circuit232may be in communication with both the user device114and the service monitoring device116and can provide terms and conditions associated with the requested access economy good or service to the supplier108and the consumer110. For example, basic terms and conditions may be set by the work event monitoring system102(i.e. the service provider) and transmitted to both the supplier108and the consumer110. The supplier108and consumer110can then choose to accept or reject the proposed terms and conditions. If the supplier108and consumer110accept the terms and conditions, then the smart contract can be generated and executed. In other examples, the supplier108and the consumer110may be able to establish terms and conditions between themselves. The supplier108and the consumer110can then provide terms and conditions to the smart contract generation circuit232. In some embodiments, the smart contract generation circuit232automatically generates the smart contract. For example, the smart contract generation circuit232may include various algorithms to determine if a contract if the terms and/or conditions would be acceptable to a service provider. If the smart contract generation circuit232determines that the terms and conditions meet the criteria set out by the service provider, the smart contract may be generated. In other embodiments, a service provider may be required to evaluate each potential smart contract before the smart contract generation circuit232is allowed to generate the smart contract. The smart contract generation circuit232may further be able to determine if a smart contract is permitted based on parameters associated with the supplier108and the consumer110. For example, if the supplier FI104and/or the consumer FI106associated with both the supplier108and the consumer110are not configured to allow for certain terms and conditions set forth by the supplier108and consumer110, the smart contract generation circuit232may not allow the smart contract to be generated. Further, other factors, such as available balance, fee agreements, or other terms and/or conditions, may be deemed unsatisfactory to the smart contract generation circuit232based on information related to the supplier108and the consumer110. In some embodiments, the smart contract generation circuit232is structured to generate and deploy smart contracts on a blockchain-based system.

The work monitoring circuit234may be configured to interface with the service monitoring device116to evaluate the amount of work performed related to the access economy good or service that has been contracted between the supplier108and the consumer110. In some embodiments, the work monitoring circuit234can determine what work has been performed and update the smart contracts118accordingly. For example, the work monitoring circuit234may receive an indication of work performed from the service monitoring device116via the network interface circuit228. The work monitoring circuit234can then update the actual performance within the smart contracts118. The work monitoring circuit234may then provide the updated performance to both the supplier FI104and the consumer FI106to allow payments to be processed accordingly. In some embodiments, the work monitoring circuit234may update the supplier FI104and the consumer FI106in real time to allow real-time trickle payments to be made between the supplier108and the consumer110.

The work monitoring circuit234may be an application on a user device, such as user device114. The work monitoring circuit234may have access to various data related to the work being performed via the application. For example, the work monitoring circuit may have access to a Global Positioning Satellite (GPS) application on the user device114, which allows for a location of the consumer110to be determined. In one embodiment, the work monitoring circuit234is a GPS transponder associated with the work mechanism112and/or the consumer110, via user device114. In other embodiments, the work monitoring circuit234may be a sensing device for sensing one or more consumers110using a good or service provided by the supplier108. For example, a good or service provided by the supplier108may have one or more sensors to determine when a consumer110is using the goods or services. In some embodiments, the sensors are integrated or a part of the work mechanism112. In some embodiments, the sensors can determine an identity of the consumer110using the good or service. For example, the sensors may be an RFID sensor for sensing an RFID chip associated with the consumer110. In other embodiments, the sensors may be cameras or other optical sensors in combination with facial recognition system for determining an identity of the consumer110. These sensors can determine that a consumer110is using the good or service, and when the consumer110is no longer using the goods or service. Other sensors may include audio sensors, motion sensors, etc.

In some embodiments, the work monitoring circuit234may be in communication with user device114. The user device114may include one or more communication mechanisms, such as Wi-Fi, Bluetooth, Cellular, etc. The work monitoring circuit234may be configured to communicate with the user device via one of the communication mechanisms. The work monitoring circuit234may use that connection to determine an identity of the consumer110, and whether the consumer110is currently using a good or service of the supplier108. In other embodiments, the work monitoring circuit is a dedicated device for monitoring the use of a good or service by a consumer110. The dedicated device may monitor identities of the consumer, location of the consumer and/or the work mechanism, elapsed time the consumer110has used the good or service, and the like. The dedicated device may include a microprocessor and a memory for executing one or more programs configured to monitor the use of the good or service by the consumer110. The dedicated device may further have one or more sensors, or other inputs for monitoring the consumer's110usage, as well as allowing either the consumer110or the supplier to interface with the work monitoring circuit234. In some embodiments, the work monitoring circuit234may be a software application installed on a computing device. Computing devices may include laptop computers, smart phones, tablet computers, dedicated work monitoring device, and the like.

Turning now toFIG.3, a process300for providing real-time trickle payments between a supplier108and a consumer110is shown, according to some embodiments. For clarity and brevity, the method300is discussed below in connection with the systems described above inFIGS.1-2. At process block302, the consumer110can request an access economy service. For example, where the access economy service is a ride share service, the consumer110may use their user device, such as user device114, to request a ride. The request may be processed by the work event monitoring system102, which can inform one or more suppliers108of the request. In other embodiments, the consumer110may use their user device114to request a service. The work event monitoring system102may receive the request and provide the request to any supplier108associated with the access economy service. A supplier108may then be able to respond, indicating that they will provide the access economy service requested by the consumer110.

At process block304, a smart contract can be generated. In one embodiment, the work event monitoring system102can generate a smart contract using the smart contract generation circuit232. The smart contract can be generated based on the requirements of both the consumer110and the supplier108. As described above, the smart contract terms and conditions can be provided to both the supplier108and the consumer110for approval. Once the consumer110and the supplier108agree on the terms and conditions, the smart contract can be established. At process block306, a consumer sub-account is generated. The consumer sub-account may be associated with a financial account of the consumer110. The financial account of the consumer110may be a financial account designated to provide payment to the supplier108under the previously established smart contract. At process block308, a supplier sub-account is generated. The supplier sub-account may be associated with a financial account of the supplier108. The financial account of the supplier108may be a financial account designated to receive payment from the consumer110under the previously established smart contract.

These financial accounts of the consumer110and the supplier108may be provided by both the consumer110and the supplier108and may be related to the consumer FI106and the supplier FI104, as described above. In some embodiments, the consumer110and the supplier108may both designate accounts with the service provider when initially setting up an account associated with the access economy service. For example, the consumer110may designate a financial account from which the service provider can remove funds related to the access economy service, and the supplier108can designate an account to receive funds from the consumer FI106as payment for services rendered. In some embodiments, the accounts are checking accounts associated with the supplier108and the consumer110, respectively. However, other accounts such as savings accounts, credit card accounts, money market accounts, etc. may also be designated by the supplier108and/or consumer110.

At process blocks306and308, a consumer sub-account and a supplier sub-account are generated. In one example, the work event monitoring system102may communicate with both the supplier FI computing system216and the consumer FI computing system222to provide the criteria required to generate the consumer and supplier sub-accounts. For example, the work event monitoring system102may estimate a cost to perform the requested access economy service and provide the estimate to both the consumer FI106and the supplier FI104. Provided that the consumer110and the supplier108had previously agreed to the smart contract, the consumer sub-account and the supplier sub-account may be generated and an estimated amount of funds entered into both sub accounts. At process block310, financial holds are placed on the funds allocated to the supplier sub-account and the consumer sub-account. For example, the funds placed into the consumer sub-account may be available to the consumer110when initially placed into the consumer sub-account, and the funds placed into the sub-account associated with the supplier108may have a hold on the entire amount when initial placed into the supplier sub-account. In further embodiments, the funds in the consumer sub-account may have a hold over a portion of the funds which will be transferred to the supplier108if the consumer110breaches the contract. The amount that may be held due to a potential breach of contract may be determined in process block304during the establishment of the smart contract. However, in other embodiments, the amount that may be held may be established by the service provider or via state or local ordinances.

At process block312, the performance of the requested access economy service is monitored by the work event monitoring system102. Upon receiving an indication that the performance has begun, the smart contract associated with the transaction is activated For example, the supplier108and/or the consumer110may indicate that the service has been initiated using a service monitoring device, such as service monitoring device116. In some embodiments, the service monitoring device116may be able to automatically determine when the performance has started and activate the contract without any input from the supplier108or the consumer110. The work event monitoring system102, upon determining that the smart contract has been activated, may inform other systems or devices that the contract is active. For example, the supplier FI computing system216and/or the consumer FI computing system222may be notified that the contract has been activated. Further, the work event monitoring system102may provide an indication that the contract has been activated to both the consumer110and the supplier108. For example, the consumer110may receive a notification that the contract has been activated via the user device114, and the supplier108may receive a notification that the contract has been activated via the service monitoring device116.

In one embodiment, the work event monitoring system102may monitor the progress of the access economy service performance. In other embodiments, the service monitoring device116provides performance-related data to the work event monitoring system102. The work monitoring circuit234may process the received data to determine what percentage (or other metric, such as distance travelled, duration of service, etc.) of the contracted service has been completed. In some embodiments, the work monitoring circuit234may communicate the percentage, or other metric, to the supplier FI computing system216and/or the consumer FI computing system222. In some embodiments, the supplier FI104and the consumer FI106may receive data related to the performance of the access economy service directly from the service monitoring device116. The supplier FI computing system216and the consumer FI computing system222may receive the percentage or other metric associated with the performance and transfer funds between the consumer FI106and the supplier FI104at process block314.

At process block314the financial holds on the funds in the consumer sub-account and the funds in the supplier sub-account are adjusted in real-time based on the monitored performance. For example, as the percentage of the performance performed increases, the hold on the funds in the consumer sub-account may be increased, and the hold on the funds in the supplier sub-account may be decreased. In some embodiments, the rate of adjustment of the financial holds in the consumer sub-account and the supplier sub-account are dictated by the terms and conditions in the activated smart contract described above. In other embodiments, funds may be transferred in real-time between the sub-account of the consumer110and the sub-account of the supplier108.

At process block316, funds are transferred from the consumer sub-account to the consumer FI106and from the supplier sub-account to the supplier FI104. For example, the funds not under a financial hold in the consumer sub-account may be transferred to the designated consumer account, and the funds not under a financial hold in the supplier sub-account may be transferred to the designated supplier account. Finally, the funds remaining on hold in both the consumer sub-account and the supplier sub-account can be netted against each other when the performance has been completed. In one embodiment, funds may also be transferred from the consumer FI106to the service provider FI236once the service has been completed. The amount of funds transferred to the service provider FI236may be controlled by the smart contract associated with the requested access economy service. In other embodiments, the amount of funds transferred to the service provider FI236may be determined based on a supplier agreement between the supplier108and the work event monitoring system102. In some instances, the funds may be allocated to the service provider FI236from the supplier FI104during the performance of the access economy service or after the requested access economy service is completed.

In some embodiments, the consumer110may also be a supplier of one access economy good or service at the same time that they are the consumer of a second access economy good or service. For example, a consumer110of a ride sharing service may, during the performance of the ride sharing service, provide a separate access economy service. In one example, the consumer110may provide a translation or other transactional service while being a consumer of a ride share service. However, other services or goods may be supplied by, the consumer110, such as those access economy goods and services described above. Accordingly, the process300described above may be applied to a service provided by the consumer110. For example, a financial hold on funds in a supplier sub-account associated with the consumer110may be released as the consumer110provides an access economy service. As the funds in the consumer110supplier sub-account are released, they may be made available to the consumer sub-account for use in the payment of the supplier108supplied access economy good or service. Thus, the consumer110may be able to generate funds for payment of the service economy good or service provided by the supplier108in real-time by performing an access economy service, or providing an access economy good, contemporaneously with the service provided by the supplier108.

Turning now toFIG.4, an example implementation400of the above process300is shown, according to an embodiment.FIG.4is presented as a ride sharing implementation of the process300. However, the implementation400is applicable to other types of services provided by the supplier108, as described above. At process block402, the consumer110may request a ride from a ride-sharing service. In some embodiments, the consumer110may request the ride using a software application located on a user device, such as user device114, associated with the consumer110. In other embodiments, the consumer110may request the ride using an internet-based interface, such as via a website associated with the ride sharing service. The above examples of the consumer110requesting the ride from the ride sharing service are not intended to be limiting, as other methods may be used to request the ride by the consumer110.

At process block404, the work event monitoring system102receives the request from the consumer110. The work event monitoring system102can then process the request and send the request to available suppliers108at process block406. In one embodiment, the work event monitoring system102may determine which suppliers108are in a particular geographic location in relation to the consumer110. The supplier108receives the processed request at process block408. At process block410, the supplier108accepts the request. At process block412, upon a supplier108accepting the request, the work event monitoring system102generates a smart contract for review and acceptance by the supplier108and the consumer110. The smart contract may contain terms and conditions associated with the requested service. For example, the smart contract may include terms and conditions, such as agreed upon origin and destination, rate per unit of distance (e.g. $0.25 per 0.1 miles), rate per duration of trip in time (e.g. $0.25 per minute), base charges (e.g. minimum service fees), fees (e.g. payment responsibility for tolls, etc.), surcharges (fuel, maintenance), taxes, additional passenger fees, additional stop fees, etc. The smart contract may further include a percentage of the payment required to be paid to the service provider. The smart contract may further include terms regarding penalties for terminating the service, either by the supplier108or the consumer110, prior to the agreed upon destination being reached. Other terms and conditions may also be included in the smart contract, as applicable for a particular service.

At process block414, the consumer110may approve the smart contract. In some embodiments, the consumer110may have an ability to modify the smart contract if there are certain terms or conditions they wish to change. For example, the consumer110may be able to use a software application on their user device114. Where the consumer110modifies one or more terms or conditions of the smart contract, the smart contract may be returned to the work event monitoring system102for approval. Once the consumer110approves the smart contract, a consumer sub-account associated with the transaction is established at the consumer FI106at process block416. For example, the sub-account may be generated by the consumer FI sub-account generation circuit226. In one embodiment, the consumer sub-account is used for a single transactions. In other embodiments, the sub-account may be used for all transactions associated with a particular access economy service, such as a ride sharing service. In some embodiments, the smart contract may include an estimate of the cost for providing the ride. This amount may be deposited to the sub-account to provide payment associated with the transaction. In some examples, an additional amount may be deposited to the sub-account to account for potential errors in the estimation due to unexpected delays, such as traffic jams. In one example, the additional amount may be 10% of the estimated cost; however, additional amounts of more than 10% or less than 10% are also contemplated. In some embodiments, if the actual cost exceeds the amount placed into the sub-account, the consumer110may have the option to allow additional funds to be placed into the consumer sub-account to continue the transaction. In other embodiments, the smart contract lays out the maximum cost which is the amount that is transferred into the consumer sub-account.

Similarly, the supplier108may receive the smart contract and approve the smart contract at process block418. In some embodiments, the supplier108may have an ability to modify the smart contract if there are certain terms or conditions they wish to change. For example, the supplier108may be able to use a software application on the service monitoring device116. Where the supplier108modifies one or more terms or conditions of the smart contract, the smart contract may be returned to the work event monitoring system102for approval. Once the supplier108approves the smart contract, a supplier sub-account associated with the transaction is established at the supplier FI104at process block420. In one embodiment, the supplier sub-account is used for a single transaction. In other embodiments, the sub-account may be used for all transactions associated with a particular access economy service, such as a ride sharing service. In other embodiments, the smart contract may include an estimate of the cost for providing the ride. This amount may be allocated into the supplier sub-account to provide payment associated with the transaction. In some examples, an additional amount may be allocated to the supplier sub-account to account for potential errors in the estimation due to unexpected delays, such as traffic jams. In one example, the additional amount may be 10% of the estimated cost; however, additional amounts of more than 10% or less than 10% are also contemplated. In some embodiments, if the actual cost exceeds the amount placed into the sub-account, the supplier108may have the option to allow additional funds to be placed into the consumer sub-account to continue the transaction. In other embodiments, the smart contract lays out the maximum cost which is the amount that is transferred into the consumer sub-account. In some embodiments, the supplier FI104may deposit actual funds into the supplier sub-account and place a hold on the funds until the transaction, or a portion of the transaction, is performed. In some embodiments, the supplier FI104can communicate with the consumer FI106to ensure that the consumer FI106has enough funds to cover the estimated cost of the transaction.

Once the sub accounts for both the consumer110and the supplier108have been established, the ride may be approved at process block422, and the progress of the transaction may be monitored at process block424. In one embodiment, the transaction may be monitored by the work event monitoring system102. The work event monitoring system102may receive data related to the progress of the transaction from the service monitoring device116. As described above, the service monitoring device116may be a device, such as smartphone, associated with the supplier108that is capable of tracking the progress of the transaction. In some embodiments, the consumer110may be in possession of the service monitoring device116or a supplemental service monitoring device. The supplemental service monitoring device may be capable of providing similar data to that of the service monitoring device116associated with the service monitoring device116associated with the supplier108.

The work event monitoring system102may provide the status of the performance of the service to the consumer FI106. For example, the work event monitoring system102may monitor the distance travelled and provide that data to the consumer FI106. In some embodiments, the work event monitoring system102may transmit the progress to the consumer FI106as a function of the cost of the ride at a given point of time. The consumer FI106can then increase the hold on the funds in the consumer sub-account at process block426. In some embodiments, the consumer FI106simply increases the hold placed on the funds in the sub-account in an amount equal to the current percentage of the transaction that is complete. In some embodiments, the work event monitoring system102can be in constant communication with the consumer FI106to allow for real-time allocation of the financial hold of the funds in consumer sub-account for the duration of the transaction. At process block428, the supplier FI104decreases the hold on the funds in the supplier sub-account. In one embodiment, the supplier FI104decreases the hold by the amount the hold is increased in the consumer sub-account. In some embodiments, the consumer FI106and the supplier FI104are in communication to allow for continuous modifications of the financial holds for the duration of the transaction. In further embodiments, the supplier FI104is also in communication with the work event monitoring system102to ensure that the proper amount of payment is being allocated to the supplier sub-account via modifying the hold on the funds in the supplier sub-account. At process block430, the ride can be concluded, and funds are transferred from the consumer sub-account to the consumer FI106and from the supplier sub-account to the supplier FI104. For example, the funds not under a financial hold in the consumer sub-account may be transferred to the designated consumer account, and the funds not under a financial hold in the supplier sub-account may be transferred to the designated supplier account. Finally, the funds remaining on hold in both the consumer sub-account and the supplier sub-account can be netted against each other when the performance has been completed. In some embodiments, the consumer110may further be able to allocate additional funds to the supplier sub-account for a tip or for other services rendered. Further, any remaining fees due to the service provider may also be transferred from the consumer sub-account at the end of the ride. In one example, the consumer FI106may transfer the funds to the service provider FI236.

Turning now toFIG.5, a further example implementation500of the above process300is shown, according to an embodiment.FIG.5is presented as a goods sharing implementation of the process300. For example, the implementation500may be used for car sharing, home sharing, boat sharing, plane sharing, or sharing of any other real or tangible property. At process block502, the consumer110may request a good from a goods sharing service. In some embodiments, the consumer110may request to rent a good using a software application located on a user device, such as user device114, associated with the consumer110. In other embodiments, the consumer110may request to rent the good using an internet-based interface, such as via a website associated with a goods sharing service provider. The above examples of the consumer110requesting to rent a good from the good rental service are not intended to be limiting, as other methods may be used to request the good by the consumer110.

At process block504, the work event monitoring system102receives the request from the consumer110. The work event monitoring system102can then process the request and send the request to available suppliers108at process block506. In one embodiment, the work event monitoring system102may determine which suppliers108are in a particular geographic location in relation to the consumer110. In other embodiments, the work event monitoring system102may evaluate which suppliers108have a good that meets a criteria set forth by the consumer110and send the request to suppliers108who have a good that meets the consumer's110requirements. A supplier108receives the processed request at process block508. At process block510, the supplier108can accept the request. Upon a supplier108accepting the request, the work event monitoring system102generates a smart contract for review and acceptance by the supplier108and the consumer110at process block512. The smart contract may contain terms and conditions associated with the requested service. For example the smart contract may include terms and conditions such as rental duration, cost per unit of time (e.g. $20.00 per hour, $200 per day, etc.), rate per unit of use (e.g. $0.25 per mile), base charges, fees, surcharges (cleaning, maintenance, wear and tear, etc.), taxes, additional passenger fees, insurance costs, security deposits, etc. The smart contract may further include a percentage of the payment required to be paid to the service provider. The smart contract may further include terms regarding penalties for terminating the service, either by the supplier108or the consumer110, prior to the agreed upon duration of the rental. Other terms and conditions may also be included in the smart contract, as applicable for a particular service.

At process block514, the consumer110may approve the smart contract. In some embodiments, the consumer110may have an ability to modify the smart contract if there are certain terms or conditions they wish to change. For example, the consumer110may be able to use a software application on the user device114. Where the consumer110modifies one or more terms or conditions of the smart contract, the smart contract may be returned to the work event monitoring system102for approval. Once the consumer110approves the smart contract, a consumer sub-account is established at the consumer FI106at process block516. In one embodiment, the consumer sub-account is used for a single transaction. In other embodiments, the sub-account may be used for all transactions associated with a particular access economy service, such as a goods rentals service. In some embodiments, the smart contract may include an estimate of the cost for renting the good for a time agreed upon by the consumer110and the supplier108. This amount may be deposited to the sub-account to provide payment associated with the transaction. In some examples, an additional amount may be deposited to the sub-account to account for potential errors in the estimation due to unexpected costs, such as additional rental time required, damage to the goods, fees incurred, etc. In one example, the additional amount may be 10% of the estimated cost; however, additional amounts of more than 10% or less than 10% are also contemplated. In some embodiments, if the actual cost exceeds the amount placed into the sub-account, the consumer110may have the option to allow additional funds to be placed into the consumer sub-account to continue the transaction. In other embodiments, the smart contract lays out the maximum cost which is the amount that is transferred into the consumer sub-account. In still further embodiments, the consumer110may be required to allocate additional funds to the sub-account to cover any additional incidental costs which may arrive. However, these funds will not be transferred to the supplier FI104unless incidental costs arise.

Similarly, the supplier108may receive the smart contract and approve the smart contract at process block518. In some embodiments, the supplier108may have an ability to modify the smart contract if there are certain terms or conditions they wish to change. For example, the supplier108may be able to use a software application on the service monitoring device116. Where the supplier108modifies one or more terms or conditions of the smart contract, the smart contract may be returned to the work event monitoring system102for approval. Once the supplier108approves the smart contract, a supplier sub-account associated with the transaction is established at the supplier FI104at process block520. In one embodiment, the supplier sub-account is used for a single transaction. In other embodiments, the supplier sub-account may be used for all transactions associated with a particular access economy service, such as a goods sharing service. In other embodiments, the smart contract may include an estimate of the cost for supplying the good to the consumer110. This amount may be allocated into the supplier sub-account to provide payment associated with the transaction. In some examples, an additional amount may be allocated to the supplier sub-account to account for potential errors in the estimation due to unexpected events, incidental costs, etc. In one example, the additional amount may be 10% of the estimated cost; however, additional amounts of more than 10% or less than 10% are also contemplated. In some embodiments, if the actual cost exceeds the amount placed into the sub-account, the supplier108may have the option to request additional funds to be placed into the consumer sub-account to continue the transaction. In other embodiments, the smart contract lays out the maximum cost which is the amount that is transferred into the supplier sub-account. In some embodiments, the supplier FI104may deposit actual funds into the supplier sub-account and place a hold on the funds until the transaction, or a portion of the transaction, is performed. In some embodiments, the supplier FI104can communicate with the consumer FI106to ensure that the consumer FI106has enough funds to cover the estimated cost of the transaction.

Once the sub accounts for both the consumer110and the supplier108have been established, the rental may begin at process block522, and the progress of the transaction may be monitored at process block524. In one embodiment, the transaction may be monitored by the work event monitoring system102. The work event monitoring system102may receive data related to the progress of the transaction from the service monitoring device116. As described above, the service monitoring device116may be a device, such as smartphone, associated with the supplier108or the work mechanism112that is capable of tracking the progress of the transaction. In some embodiments, the consumer110may be in possession of the service monitoring device116or a supplemental service monitoring device. The supplemental service monitoring device may be capable of providing similar data to that of the service monitoring device116associated with the service monitoring device116associated with the supplier108. For example, where the service is a home rental, the consumer110may “check-in” using an application on a user device114. Once the consumer110has “checked-in,” the rental is considered to have commenced and the smart contract then governs the allocation of payment between the consumer110and the supplier108.

The work event monitoring system102may provide the status of the performance of the service to the consumer FI106. For example, the work event monitoring system102may monitor the duration of the rental and provide that data to the consumer FI106. In some embodiments, the work event monitoring system102may transmit the progress to the consumer FI106as a function of the cost of the ride at a given point of time. The consumer FI106can then increase the hold on the funds in the consumer sub-account at process block526. In other embodiments, the consumer FI106simply increases the hold placed on the funds in the sub-account in an amount equal to the current percentage of the transaction that is complete. In some embodiments, the work event monitoring system102can be in constant communication with the consumer FI106to allow for real-time allocation of the financial hold of the funds in consumer sub-account for the duration of the transaction. At process block528, the supplier FI104decreases the hold on the funds in the supplier sub-account. In one embodiment, the supplier FI104allocates funds decreases the hold by the amount the hold is increased in the consumer sub-account. In some embodiments, the consumer FI106and the supplier FI104are in communication to allow for continuous modifications of the financial holds for the duration of the transaction. In further embodiments, the supplier FI104is also in communication with the work event monitoring system102to ensure that the proper amount of payment is being allocated to the supplier sub-account via modifying the hold on the funds in the supplier sub-account. In some embodiments, allocating funds to the supplier FI104can include releasing a hold placed on the funds previously allocated to the supplier sub-account that is equal to the hold placed on the funds in the consumer sub-account. At process block530, the rental can be concluded. For example, the consumer110may “check-out” using a software application on a user device114, indicating that the rental is completed. At process block532, funds are transferred from the consumer sub-account to the consumer FI106and from the supplier sub-account to the supplier FI104. For example, the funds not under a financial hold in the consumer sub-account may be transferred to the designated consumer account, and the funds not under a financial hold in the supplier sub-account may be transferred to the designated supplier account. Finally, the funds remaining on hold in both the consumer sub-account and the supplier sub-account can be netted against each other when the performance has been completed. In some embodiments, some funds in the consumer sub-account may continue to have a hold until the supplier108verifies the returned of the rented property, as well as the condition thereof. Once the supplier108verifies the returned property, any remaining hold on funds within the consumer sub-account may be released. Further, any remaining fees due to the service provider may also be transferred from the consumer110sub-account at the end of the ride. In one example, the consumer FI106may transfer the funds to the service provider FI236.

The present disclosure contemplates methods, systems, and program products on any machine-readable media for accomplishing various operations. The embodiments of the present disclosure may be implemented using existing computer processors, or by a special purpose computer processor for an appropriate system, incorporated for this or another purpose, or by a hardwired system. Embodiments within the scope of the present disclosure include program products comprising machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions. Software implementations could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various connection steps, processing steps, comparison steps, and decision steps.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of what may be claimed but rather as descriptions of features specific to particular implementations. Certain features described in this specification in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation can also be implemented in multiple implementations 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 implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated in a single software product or packaged into multiple software products embodied on tangible media.

Thus, particular implementations of the subject matter have been described. Other implementations 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.

The claims should not be read as limited to the described order or elements unless stated to that effect. It should be understood that various changes in form and detail may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims. All implementations that come within the spirit and scope of the following claims and equivalents thereto are claimed.