HK1200233B - An apparatus which a user can pay for over time and a system including the same - Google Patents

Description

Device for user to pay across time and system comprising device

Technical Field

Embodiments of the present invention relate to the operation of a device and include various operational states in the device depending on local and/or remote events or inputs.

Background

Very little money is earned by the vast majority of the population. It is difficult for many people to accumulate sufficient capital to purchase the required assets through low periodic revenues. Various arrangements have been developed to address this challenge. For example, one arrangement allows a person wishing to purchase an asset or service to pay a portion of a price over time in the form of multiple payments. When the price is paid, a person is provided with possession of the asset (permission) or the service is provided. In some cases, use of the asset or service is permitted while payment is still in progress. As an alternative, various credit measures have been developed including mini-financial lease agreements and the like.

One disadvantage with these known arrangements is that it takes a lot of time for the purchaser to pay the purchase price. Financial arrangements have the disadvantage of being expensive to implement and manage and difficult to enforce, particularly in rural environments. Typically, the purchaser eventually pays significantly more than the purchase price to cover the management costs.

There is a further challenge (particularly in developing economies) that once an asset is purchased, an adequate plan is not made to ensure maintenance of the asset. Thus, assets that might otherwise be susceptible to repair are overlooked to the point where the repair becomes more expensive.

Disclosure of Invention

The following description briefly summarizes certain aspects of the disclosure herein. This summary is not intended to identify all features of the implementations disclosed herein, nor is it intended to identify key features or to delineate the scope of the claimed invention.

Disclosed herein are embodiments of devices having various operating states that depend on local and/or remote events or inputs. A device may be an asset purchased or providing a service that may be purchased, the device being controllable by local events or inputs and/or remote events or inputs. For example, the device may include communications circuitry that enables it to connect to a remote transaction processing system via a communications link using, for example, a cellular communications network. The transaction processing system receives payment (possibly via a different communication link) for the user to use the device and communicates with the device to allow use of the device when the user has successfully paid for use. The operating state in the device takes into account communications from the transaction processing system, as well as local inputs received from a user of the device and/or local events, such as a loss of charge of a battery in the device.

Drawings

The foregoing aspects and the attendant advantages of this invention will become better understood and more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:

FIG. 1 illustrates a communication system according to one embodiment of the present invention;

FIG. 2 shows a solar powered light according to an embodiment of the invention;

FIG. 3 shows a portion of the solar powered light of FIG. 2;

FIG. 4 illustrates a transaction processing system according to one embodiment of the invention;

FIG. 5 illustrates a process of setting an operating state of the solar powered light of FIG. 2 according to one embodiment of the invention;

FIG. 6 illustrates a further process according to an embodiment of the invention; and

FIG. 7 illustrates various operating states of a solar powered light according to an embodiment of the present invention.

Detailed Description

In the following description, it is to be understood that the figures are diagrammatic and not drawn to scale, and that the figures are for illustrative purposes.

Fig. 1 illustrates a communication system 10 according to one embodiment of the present invention. The communication system 10 includes a user interface and in this embodiment a mobile communication device in the form of a cellular telephone 100 is configured to communicate via a cellular telephone column (mass) 20. In the illustrated embodiment, the device 200 (in this case a solar powered light) is also configured to communicate via the cellular telephone column 20.

The cellular telephone column 20 may be part of any type of cellular communication network, such as a GSM communication network, indicated generally by the numeral 30 in fig. 1. In a preferred embodiment, the GSM communication network 30 is also configured to communicate via the internet 40. Transaction processing system 300 is configured to communicate with cellular telephone 100 and solar powered light 200 via internet 40 and GSM communication network 30.

In the embodiment shown in fig. 1, cellular telephone 100 and solar powered light 200 communicate with the same cellular telephone column 20, although it should be understood that embodiments of the present invention are not limited in this respect. In other embodiments, the user interface (in this case, cell phone 100) and the device (in this case, solar light 200) communicate with different, separate masts or via other communication hardware or protocols.

Referring again to fig. 1, solar powered lights 200 as indicated communicate via GSM communication network 30. It will therefore be appreciated that the solar powered light 200 has the necessary radio transmitter and receiver, as well as providing the device with a Subscriber Identity Module (SIM) and other necessary hardware and software to enable communication via a GSM network, as will be described in more detail below. The solar powered light 200 interacts with the GSM communication network 30 in a similar way as known cellular devices, such as the cellular telephone 100. In the illustrated embodiment, cellular telephone 100 and solar powered lamp 200 communicate with GSM communication network 30 using General Packet Radio Service (GPRS). However, the method of communication, or any other communication described herein, whose occurrence is not essential to the operation of the described embodiments of the present invention. In further embodiments, other wireless or wired communication protocols and networks may be used including, for example, USSD criteria, XHTML, WiFi, and the like.

Fig. 2 shows the solar powered light 200 in more detail. As will be understood from the following description, the lamp 200 provides a primary function in addition to two-way communication, i.e., the lamp 200 provides light when activated. Solar powered light 200 includes a light portion 202 having an activation switch 204. The lamp portion 202 is connected to a control unit 208. Lamp portion 202 also includes photocell 203. Photocell 203 operates to charge the batteries in solar powered lamp 200 during exposure to sunlight (see below) such that lamp 200 operates with little or no ambient light. The user uses the activation switch 204 as an interface to turn the solar powered light 200 on and off. However, unless the control unit 208 permits as described below, the lamp 200 will not be activated (function is achieved).

The control unit 208 of the solar powered light 200 is shown in more detail in fig. 3. As shown, the control unit 208 comprises an antenna 206 connected to a modem, in which case the radio unit 210 is in turn connected to a SIM 212. Antenna 206, radio unit 210, and SIM 212 operate together in a known manner such that solar powered light 200 (fig. 2) can communicate with a remote computer, such as transaction processing system 300 (fig. 1) at a remote site, via GSM communication network 30. The radio unit 210 is also connected to a processor 214 having a memory 216. In this embodiment, the processor 214 is shown connected to a timer 218.

The control unit 208 is connected to the light portion 202 (shown in dashed outline in this figure) of the solar powered light 200. The processor 214 is connected to the switch 220, and the switch 220 is connected in reverse to the light bulb 226. The activation switch 204 is connected to a battery 222 and to the processor 214 via a switch 220. The battery 222 provides power to the lamp portion 202 and provides power to the light bulb 226. The battery 222 also provides power to the radio unit 210, processor 214, and other components in the solar powered light 200 that require a power source, respectively. The battery 222 is recharged by the photovoltaic cell 203. The battery 222 is not dependent on a wired power source, and thus the lamp 200 is portable and may be used in areas where there is no main power supply or when the main power supply is interrupted or otherwise unavailable.

In the illustrated embodiment, the lamp portion 202 also includes an ammeter 224, the ammeter 224 measuring the current drawn from the battery 222 and the current delivered to the battery 222. The processor 214 is communicatively connected to the ammeter 224 and receives readings of the ammeter 224, which may be stored by the processor 214 in the memory 216. Alternatively, other circuitry known in the art may be used to monitor the charge level of the battery 222.

As will be described in greater detail below, the lamp 200 is configured with various operating states that depend in part on local and remote inputs. In one operational state, the bulb 226 of the light 200 will operate only if the user has activated the switch 204 to place the switch in the "on" position and the processor 214 has activated the switch 220 to place the switch also in the "on" position. In this manner, the processor 214 determines whether the lights are operating even after the user turns on the lights.

Also, processor 214 controls radio unit 210 and thereby controls the manner of communication and content of solar powered light 200 over GSM communication network 30 (fig. 1). The processor 214 uses the memory 216 during its operation in accordance with known methods. In at least one embodiment, the memory 216 is configured to store an indication of an amount of time that the solar powered light can be operated in the form of credit. In the manner disclosed below with reference to fig. 5, the user transfers credit from the transaction processing system 300 to the light 200. The memory 216 maintains a record of the available credits and the processor 214 decrements the available credits as the light 200 is used. The processor 214 uses the timer 218 for tracking the usage of the lamp 200 and for ancillary purposes such as data or time stamp communication. In various embodiments, this timing information is stored in memory 216 along with current information obtained from current meter 224 and transferred as usage information to transaction processing system 300 in a manner described below.

Fig. 4 shows a transaction processing system 300 comprising a connection unit 304, in this case the connection unit 304 having an IP connection socket (socket) 302. The transaction processing system 300 communicates with the internet 40 using a socket 302 and a connection unit 304 in a manner known in the art. In an alternative embodiment, the connection may be made by a communication protocol other than an IP-related protocol (e.g., a GSM connection via a SIM card connected to the mobile network). In the illustrated embodiment, the communication link between the transaction processing system 300 and the light 200 is different than the communication link between the transaction processing system 300 and the cellular telephone 100.

The transaction processing system 300 further comprises a processing unit 306, the processing unit 306 controlling the transaction processing system 300. The processing unit 306 is connected to a memory 308, the memory 308 being used for storing data in the form of a database and associated data storage. It should be understood that the transaction processing system 300 is shown in schematic form in fig. 4, and that numerous alternative methods of implementation are known in the art.

In the illustrated embodiment, the transaction processing system 300 allows a user to have credit in an individual account and transfer money into and out of the account, as well as transfer between the transaction processing system account and an account held elsewhere. As such, transaction processing system 300 is similar to known banking systems. The transaction processing system 300 also allows users to operate their accounts (i.e., transfer amounts and purchase goods or services using money stored in their accounts) through various communication links (e.g., by using a cellular telephone). Such transaction processing systems are known in the art, for example the system of the trade name "M-PESA" run by the GSM mobile operator Safaricom Limited in kenya.

In some embodiments, the transaction processing system 300 may be arranged to enable a user to selectively pay for use of a device (e.g., the solar light 200 previously discussed) or service using funds stored in the transaction processing system. In an alternative embodiment, the transaction processing system 300 is primarily used by the operator of the GSM communication network to allow the user to pay for use of their cellular telephone, in which embodiment, in addition to that, credits primarily used to pay for use of the cellular telephone may be used to pay for use of the device in a similar manner to that described below with reference to fig. 5.

The transaction processing system 300, which communicates via the internet 40 through the IP connection unit 304, is able to control certain operational aspects of the solar powered light 200, which solar powered light 200 may also be connected to the internet 40 via the GSM communication network 30. The manner in which this occurs will be described in detail below with reference to fig. 5.

Fig. 5 illustrates a process 400 in which the transaction processing system 300 controls the operating state of the solar powered lights 200 as needed by a user (not shown) interacting with the transaction processing system 300 via, for example, the cellular telephone 100.

In a preliminary step 402, the device (in this case, the solar powered light 200) is transferred to the user. In the illustrated embodiment, the preliminary step may include the user paying the warranty to the provider in exchange for the provider providing the device to the user. The margin may be less (and in many cases much less) than the capital cost (capital cost) of the equipment.

During a preliminary step 402, the user's possession of the lamp 200 will be registered. The registration includes establishing an association between the device (identified by an identification number in this embodiment) and the user. In the illustrated embodiment, to operate the light 200, a user uses the cellular telephone 100 to interact with the transaction processing system 300. The registration process may include establishing an association between the user's cellular telephone number and the identification number of the lamp 200.

At step 404, the user turns on the solar powered light 200 by activating the activation switch 204 (FIG. 2). Steps 402 and 404 are linked by dashed line 8, which is used to indicate that step 402 is a preliminary step and that step 402 will occur only once, however step 404 may occur multiple times within the expected life span of the device (e.g., solar powered light 200).

At step 406, the processor 214 of the lamp 200 detects the operation of the switch 204 and checks for credit available to operate the device by consulting a credit record in a financial account number stored in the memory 216 (fig. 3). The process then proceeds to step 408, where a determination is made at 408 as to whether the credit stored in memory 216 is sufficient to operate the device.

If the available credit is not sufficient, the process proceeds to step 410 where the lights transmit a message to the transaction processing system 300 in the manner discussed above at 410. The message sent by the lamp 200 to the transaction processing system 300 may include an identification number by which the transaction processing system 300 can identify the lamp 200, and a request to process payment for use of the lamp 200 within a predetermined time. In this embodiment, the predetermined time is 8 hours, but in other embodiments, any time interval may be used.

At step 412, the transaction processing system 300 refers to the identification number of the lamp 200 for account information held by the user determined to be the occupant of the lamp 200. The transaction processing system 300 thus determines the amount of funds the user has available to pay for use of the lamp 200.

At step 414, a determination is made as to whether the user has sufficient funds. If the user does not have sufficient funds, the process moves to step 416 where a message is sent to the user's cellular telephone 100 informing the user that they do not have sufficient funds and alerting the user to transfer additional funds. The process then ends at step 418. If the user subsequently transfers funds to his or her financial account, the user will be able to restart the process by activating switch 204, in which case the process begins again at step 404.

On the other hand, if it is determined at step 414 that the user has sufficient funds to operate the light 200, the process moves to step 420 where the transaction processing system 300 processes payment for the device at 420. This may include debiting the user account in a manner known in the art and not described further herein. In a further embodiment mentioned above, this step may include debiting the credit that is typically used by the user to pay for use of the cellular telephone 100.

At step 422, the transaction processing system 300 sends a message to the light 200 via, for example, the IP connection unit 304 and the socket 302. The message includes the lamp's identification number and an encrypted command to update the credit stored on lamp 200 in memory 216.

At step 424, the light 200 receives a message sent by the transaction processing system 300. The processing unit 214 of the lamp 200 verifies that the message was sent by the transaction processing system 300. In at least one embodiment, this may be done by verifying the encryption key, but in other embodiments this may be done in any known manner for verifying the sender of the message. Once the processing unit 214 of the lamp 200 verifies that the message does in fact originate from the transaction processing system 300, the processing unit 214 executes the command specified in the message by updating the credit record stored in the memory 216.

In this example, the transaction processing system 300 issues a command to update the credits stored in the lights 200. In further embodiments, the transaction processing system 300 may issue other commands relating to the operational state of the device being controlled. For example, the transaction processing system 300 may communicate with the user by flashing lights on and off to indicate that there are not sufficient credits in the user's account. Alternatively, where the device is a device other than a light, the command issued by the transaction processing system may relate to the operation of the device. Once the credit on the light is updated, the process proceeds to step 426 where the light (in this embodiment the device) is activated by activating the switch 220 at 426. Thus, once switch 220 is activated, both switch 204 and switch 220 have been activated to allow lamp operation.

Referring again to step 408, if it is determined in this step that sufficient funds are stored in the device, the process may proceed to step 426 where the lights are activated and allowed to operate 426.

Once the lamp is turned on in step 426, the process moves to step 428, where the lamp 200 monitors the time elapsed since the lamp 200 was turned on in 428. Thereafter, the process flows from step 428 to decision step 430 to compare the elapsed time to a predetermined time. If the elapsed time is less than the predetermined time, the process returns to step 428 and then repeats decision step 430. However, if the elapsed time is equal to or greater than the predetermined time, the process proceeds to step 432.

In this embodiment, the predetermined time is a time that has been stored in a memory 216 (as described above with reference to fig. 3) associated with the processing unit 214 of the solar powered light 200. Each time the light 200 is activated, the light will be activated for a predetermined time unless the user turns off the light during this time by activating the switch 204 again, in which case the process will begin again at step 404. In further embodiments, the predetermined time of activation may form part of the message sent by the transaction processing system 300 in step 416. Alternatively, or in addition, the user may determine the predetermined time period and may designate it as a parameter when communicating with the transaction processing system 300 using the cellular telephone 100.

Once it is determined at step 430 that the predetermined time has elapsed, the process may proceed to step 432 where usage information for the lamp 200 is sent to the transaction processing system 300 at step 432. In this example, because the predetermined time period in step 430 is set to 8 hours, usage information is sent to the transaction processing system 300 every 8 hours. The process then returns to step 406 where a determination is made of the available credits stored in the memory 216 in step 406. In this manner, the lamp 200 keeps track of the continued use of the lamp and ensures that sufficient credit remains for its use. When the lights run out of credit, the process proceeds to step 410 to obtain credit from the transaction processing system 300 in the manner described above.

At any point during the process defined by steps 406, 408, 426, 428, 430, and 432, the user can operate switch 204 to pause the process. When the user reactivates the switch 204, the process continues from the point where it was paused. In other embodiments, activation of the switch 204 causes the process to restart.

In a further embodiment, the operational state of the lamp 200 is changed by having the transaction processing system send further commands to the lamp 200 via messages. In this embodiment, the transaction processing system 300 keeps track of a predetermined time period and once the time period has elapsed, the transaction processing system 300 sends a message to turn off the light 200.

Advantageously, with embodiments of the present invention, a user is given ownership of an asset when paid a deposit that is less than the cost of the device (e.g., solar powered light 200). The user may pay for use of the equipment for a predetermined time and this portion of the cost is due to the capital cost of the equipment. It will be appreciated that as the user continues to use the equipment, more and more of the capital costs are paid back until all of the capital costs are paid off. At this point, ownership of the asset is transferred to the user.

Fig. 6 illustrates a process 500 whereby the transaction processing system 300 determines whether the user pays for the capital cost of the equipment (in this embodiment, the solar powered lights 200). At an initial step 502 of the process 500, the transaction processing system 300 receives a request from a user to activate the lights 200 in the manner described above with reference to the process of FIG. 5.

When an initial request is received, the process may continue to step 504, where a determination is made as to the funds available to the user in step 504, and if the funds are sufficient, the operating state of the lamp 200 may be changed from off to on (also in the manner described above).

At step 506, the amount of capital outstanding by the user on the lamp side is calculated. If in the previous step 504 it is determined that the user has sufficient funds to allow use of the lamp 200, the amount of capital that was not paid in step 506 will be reduced by the portion charged for the user to use the lamp 200 that has been amortized for reimbursing the amount of capital.

At step 508, a determination is made as to whether the user has not paid a capital amount. If the outstanding capital amount is zero, the process continues to step 512 where ownership of the lamp 200 is transferred to the customer in step 512. In this embodiment, the transfer of ownership may include allowing the user to use the light 200 without further payment. To facilitate this, the transaction processing system 300 sends a message to the light 200, after which the light 200 allows use of the light 200 without payment.

In an alternative embodiment, ownership of lamp 200 may authorize the user to continue using lamp 200 at a reduced cost. In this embodiment, the cost of use may be treated as a payment in terms of an insurance or maintenance strategy for covering repairs of the lamp 200. The user has the right to repair the lamp or is provided with a new lamp when the lamp stops working.

Referring again to FIG. 6, if it is determined at step 508 that a portion of the capital quantity is not yet reimbursed, the process proceeds to step 510. At step 510, the transaction processing system waits for the next credit transfer from the user. When a credit transfer is received, the transaction processing system 300 returns to step 504 and verifies that the user has sufficient funds to allow use of the light 200.

The usage information collected by the lights 200 and transferred to the transaction processing system 300 in step 432 of FIG. 5 may be used to track how the user is using the lights 200 or any other device in an implemented embodiment of the invention. Furthermore, this data can be used, in particular when the device relies on "renewable resources" such as solar or wind energy, to calculate the carbon offset and apply it to the user or to an organization having a relationship with the user. In this manner, the transaction processing system 300 can continuously monitor and bill for the use of the lights 200 until such time as the user pays off the cost of the lights.

In the illustrated and described embodiment, the transaction processing system 300 interacts with the solar powered lights 200 to allow activation of the solar powered lights 200. In a further embodiment, the control unit of the solar powered lights 200 operates to collect information relating to the use and status of the solar powered lights 200 and transmit that information to the transaction processing system 300 or a further remote location where it is stored and collated. In this embodiment, the solar powered light 200 will include the necessary memory and storage media to allow data to be collected.

As noted above, the present application describes a device for which a user can make a payment across time. In the illustrated embodiment, the unique user-enabled solar powered light is configured to allow for purchase of the light on a "pay-as-you-go" basis, providing a more affordable method for clean light and energy.

The following description provides more details regarding the operational state of a mobile-enabled device (hereinafter generally referred to as a "system"). In at least one embodiment, the system includes a solar panel, a control unit, a battery, a light, an LCD unit, a clock, a tamper alarm, and an embedded modem component. Each component of the system may have an "on" or "off state. Of course, other embodiments of the system may have more, fewer, or different components with different states required to operate the respective systems.

The operating state of the system and its various components may change based on one or more existing local conditions or inputs (which are specific to each system) and wireless command instructions (e.g., a transported mobile network), either or both of which may trigger a change in the operating state of the system. These interrelated operational states of the system determine the overall effectiveness of the application provided by the service provider to the customer via the system.

Referring now to FIG. 7, in at least one embodiment, the system has three main operating states or modes: a "sleep" mode, an "operation" mode and a "pay-off" mode. In addition, there are sub-states in some of these modes, called "stop", "Constant", "Periodic", and "Request". The system mode or state is determined by the existing/current state plus responses to various types of inputs or commands. These inputs or commands can change preset time intervals or be responsive to a real time clock that generates events based on time of day. These inputs or commands can also be received from remote device management software (e.g., over the air delivery) or by local user-initiated inputs.

Starting with the rest state of the sleep mode (also referred to herein as the "sleep-stop" state) shown in fig. 7, all system components are turned "off. The purpose of this state is to reduce the impact of system components on the battery during transport and to prevent unauthorized use of the system, for example, before the system is deployed and properly activated. In the sleep mode, limited functionality of the system may be available to allow the unit to be ready for delivery to an end user. For example, the sleep mode may be configured to allow delivery of a system with a fully charged battery.

In fig. 7, when a charging event occurs, for example, by providing a voltage input to the system, the system moves from a sleep-stop state to a sleep mode, charging state (also referred to herein as a "sleep-charge" state). Some limited functionality (e.g., indicating to the user that the battery is being charged via an illuminated LED) may become available in the sleep-charge state. However, in this state, other system components including the modem, clock and LCD display remain "off. In this embodiment, events such as the voltage input being removed or the battery charge level becoming too low will cause the system to return to the lowest power state, known as the sleep-stop state, to avoid damaging the battery due to the resulting total discharge.

The system may move from one operating state to another, initiated periodically or by a button press on the equipment, at a frequency determined by the provider of the system/service. For example, as shown in fig. 7, when the system is in a sleep-stop state, a user of the system may request that the system be activated and the system will move to a sleep mode, request state (also referred to herein as a "sleep-request" state). In this state, as previously described, a number of steps (or sub-steps) may be implemented to perform a communication process to determine whether credit is available for operation of the system. Sub-states in this regard may include turning on a modem, verifying network availability, and communicating with a remote server (e.g., transaction processing system 300) that includes details of the user and his account status.

Based on the response from the server, the system may return to other sleep mode states from the sleep-request state or move from the sleep-request state to the operational mode state. In the illustrated embodiment, the system uses a combination of credit and network availability available to (or provided by) the user to move to an operational mode, constant state (also referred to herein as an "operational-constant" state). However, it is contemplated that other options are possible, such as communicating from a server based on time of day or reported system location.

The operating mode has a plurality of sub-states that can be entered according to parameters such as the charge level of the battery to enable maximum use of the system while protecting the chemical characteristics of the battery, for example.

In the illustrated embodiment, the system remains in an operational-constant state when the battery has sufficient charge to make an application (e.g., lamp lighting) provided by the system available to the user. In the operational-constant state, on is present in all system components. In response to a local input to the system, e.g., generated based on, for example, a low battery charge level, the state of the system may be changed from an operational-constant state to an operational mode, periodic state (also referred to herein as an "operational-periodic" state) in which all system components, except for modems requiring periodic communication, are "on". The system may also change state to an operational mode, a stop state (also referred to herein as an "operational-stop" state) in which an excessively low battery condition causes all system components, including the clock and modem, to be set to "off" to prevent the battery from being completely drained.

The device may change state from the operate-stop state back to the operate-periodic state and/or the operate-constant state in response to the battery charge level changing from too low to low and then to normal.

It should be noted that the schema described above does not necessarily map to system availability as is apparent to the user. For example, the battery may be sufficiently charged so that the system is in an operational-constant state, but to conserve a minimum charge for system communications, the application provided by the system may not allow the customer to use the charge in the battery. To the user, the unit does not display operation but rather internally, the system maintains the ability to communicate with, for example, a remote server, such as transaction processing system 300.

There are advantages to conserving some charge in the battery while maintaining the appearance of non-operational equipment to the customer. This allows the service provider to maintain communication with the system for customer service purposes (e.g., send a message to the user when the service provider observes a low battery condition). It also allows for continued tamper alerting when the system encounters improper use (e.g., someone is attempting to open the unit and remove the SIM). If tampering is detected, the system may transmit a message to the service provider.

At some point in time, if the user has paid enough to the service provider to have the system's capital value paid off (see, e.g., FIG. 6), the remote device management software (e.g., transaction processing system 300) may direct the system to move into a paid off mode, application run state (which may also be referred to herein as a "paid off-application run" state). At this point, all components are "on" except for the modem and tamper alarm being "off". While in the paid-off-application running state, the system may change to a paid-off-stop state in response to local data from an event (e.g., low battery), in which all components are "off" for similar reasons as discussed above with respect to the sleep-stop state or the operation-stop state. In response to charging the battery to a level at which the system records that it is no longer too low, the system may return to a payoff-application running state.

If the user decides to purchase a new product or update the system, or in some way re-fund according to a new agreement with the service provider, the system may be instructed (either locally or remotely) to return to the operational mode-constant state. Fig. 7 shows an implementation in which, for example, steps in the pay-off-request state result in the modem being turned "on" and the system being allowed to communicate with the service provider to manage new credits available for new product purchases or system updates.

In the illustrated and above described embodiments, the device (apparatus or system) is shown as a solar powered light. However, embodiments of the invention are not limited in this respect. It is understood that other devices or systems may be substituted for the solar powered lights. For example, a large number of equipment such as generators, cars, radios, etc. may be used. Additionally, services that can be provided by the equipment may be provided in the manner described herein. In the case of solar powered lights, the equipment in the device provides primary functions in addition to communicating with a remote computer such as transaction processing system 300.

As disclosed, various features and advantages may be obtained when configuring a device, such as a solar powered light, according to various embodiments described herein. Moreover, while the invention has been described in connection with certain depicted embodiments, those skilled in the art will recognize that one or more features of a particular embodiment described herein may be used with another embodiment to achieve a similar advantage. Accordingly, the scope of the invention should be determined not with reference to the following claims, but should instead be determined with reference to the above description in specific forms.

Claims (19)

1. An apparatus for a user to make a payment across time, comprising:

an apparatus configured to provide primary functions other than two-way communication;

a computing device configured to control the apparatus; and

a modem configured for wireless communication, wherein the modem is communicatively coupled to the computing device;

wherein the device is configured to operate in a plurality of modes including an operational mode and a pay-off mode;

wherein, when the apparatus is in the operational mode, the computing device is configured to:

communicating with a remote computer via the modem and in response receiving instructions from the remote computer based on the status of the financial account, an

Controlling whether the equipment provides the primary function based on the received instruction;

wherein, when the apparatus is in the payoff mode, the provision of the primary function by the equipment is not controlled by the computing device based on the status of the financial account; and

wherein the device is configured to transition from the operational state to the paid-off state in response to receiving a wireless communication from the remote computer that is generated based on an amount outstanding in the financial account being paid off.

2. The apparatus of claim 1, further comprising an interface communicatively coupled to the computing device, wherein the computing device is configured to:

receiving, via the interface, an input requesting the apparatus to provide the primary function; and

in response to receiving the input, communicating with the remote computer via the modem and receiving an instruction from the remote computer based on the status of the financial account.

3. The apparatus of claim 2, wherein the interface is a user interface configured to receive input of a local user of the apparatus.

4. The apparatus of claim 2, wherein the plurality of modes further comprises a sleep mode in which the equipment is prevented from providing the primary function; and

wherein the apparatus is further configured to transition from the sleep mode to the operational mode in response to receiving a wireless communication from the remote computer generated according to availability of credits in the financial account.

5. The apparatus of claim 4, wherein the apparatus operates only to charge a battery, receive input via the interface, and receive wireless communications from the remote computer when the apparatus is in the sleep mode.

6. The apparatus of claim 4, wherein, when the apparatus is in the sleep mode, the computing device is configured to:

receiving, via the interface, an input requesting the apparatus to provide the primary function; and

in response to receiving the input, communicating with the remote computer via the modem and receiving an instruction from the remote computer based on the status of the financial account.

7. The apparatus of claim 4, wherein the apparatus further comprises a tamper alarm configured to signal unauthorized disposal of the apparatus,

wherein the tamper alarm is operative when the device is in the sleep mode or the operational mode, and if a tamper event is detected, the device is configured to limit the functionality of the device and signal the tamper alarm; and

wherein the tamper alarm is inoperative when the device is in the paid-off mode.

8. The apparatus of claim 1, wherein the apparatus is configured to transition from one mode to another mode in response to an occurrence of an event local to the apparatus.

9. The apparatus of claim 8, wherein the event is based on a time of day.

10. The apparatus of claim 8, wherein the event is based on a location of the apparatus.

11. The apparatus of claim 1, wherein one or more of the plurality of modes has a plurality of sub-states, an

Wherein the apparatus is configured to operate in one of the sub-states based on the parameter determined within the apparatus.

12. The apparatus of claim 11, wherein the parameter is a charge level of a battery local to the apparatus.

13. The apparatus of claim 12, wherein, based on the charge level of the battery, the computing device is configured to prevent the apparatus from providing the primary function when communication with the remote computer via the modem is allowed.

14. The apparatus of claim 11, wherein different functions of the apparatus are allowed or blocked according to the sub-state in which the apparatus is operating.

15. The apparatus of claim 1, wherein the apparatus is configured to transition from the paid-off mode to the operational mode in response to receiving a wireless communication from the remote computer generated based on availability of new credits in the financial account number.

16. A system comprising the apparatus for payment by a user across time of claim 1 and a remote computer configured to wirelessly communicate with the apparatus via a first communication link.

17. The system of claim 16, wherein the remote computer is configured to communicate with a user via a second communication link different from the first communication link.

18. The system of claim 17, wherein the remote computer is configured to receive a request for credit in the financial account from the user via the second communication link; and

wherein, upon making available credit in the financial account, the remote computer is configured to transmit a wireless communication to the apparatus via the first communication link that causes the apparatus to transition to the operational mode.

19. The system of claim 17, wherein the remote computer is configured to receive payment information indicating that an outstanding amount in the financial account has been paid out, and in response, the remote computer is configured to transmit wireless communication to the device via the first communication link that causes the device to transition to the paid-out mode.