US20070194881A1

US20070194881A1 - Enforcing payment schedules

Info

Publication number: US20070194881A1
Application number: US11/349,523
Authority: US
Inventors: Stanley Schwarz; Christopher Macheca; Michael Glancy
Original assignee: Individual
Current assignee: GORDON HOWARD ASSOCIATES Ltd; Gordon and Howard Associates Inc
Priority date: 2006-02-07
Filing date: 2006-02-07
Publication date: 2007-08-23
Also published as: US9183530B2; US20160026982A1; US10576927B2; WO2007092272A2; WO2007092272A3; US20070185728A1; US20160023635A1

Abstract

A payment schedule enforcement system and method cause various actions to be taken in response to nonpayment by the debtor. Such actions include remotely activating an alert message, disabling a vehicle or other product, or the like. Upon occurrence of a specified event, a message is sent to a remotely located device, such as one installed in a vehicle or other product. The remotely located device is configured so that it can disable the vehicle (for example by disabling the starter circuitry) upon receipt of the message from the operations center.

Description

CROSS-REFERENCE TO RELATED APPLICATION

This invention is related to U.S. patent application Ser. No. 10/856,968 for “Encoding Data in a Password”, filed May 28, 2004, the disclosure of which is incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention
The present invention relates to enforcement of payment schedules by remote disablement of a device in response to a missed payment or other event.
2. Description of the Related Art
Lenders have various mechanisms for enforcing payment of debt obligations, particularly those obligations that arise from the sale of goods or property on credit. For example, mortgagees can foreclose on real property if a mortgagor defaults. Vehicle finance companies can repossess a vehicle in the event the purchaser fails to make timely payment.
In some cases, payment schedule enforcement mechanisms based on foreclosure and/or repossession are expensive and cumbersome to implement. Accordingly, lenders often refuse to extend credit when the likelihood of default exceeds some amount, because of the expense or impracticality of repossessing or otherwise enforcing payment obligations. In particular, potential buyers with bad credit history may be denied credit when attempting to purchase a vehicle or other item because of the relatively high likelihood of default. In addition, payments on less expensive items such as appliances, computers, and the like are often difficult to enforce because repossession is far too expensive in relation to the value of the item itself, and because the item loses much of its value once it is used.
Payment enforcement systems exist whereby a vehicle (or other purchased property) is equipped with a device capable of disabling the vehicle in the event of non-payment. Whenever the purchaser makes a timely payment, he or she is given a password to enter on a keypad installed in the vehicle. Entry of the password enables the vehicle for some limited period of time (usually until the next payment due date, plus some grace period). Failure to enter the password causes the vehicle to be disabled, for example by interrupting the starter circuitry. Usually, the purchaser is given some warning of impending disablement, and may also be provided with a limited number of emergency starts whereby the vehicle can be used a few times even if a code has not been entered. In some variations, the password is transmitted wirelessly to the vehicle so that the purchaser need not enter it manually.
Such systems, available for example from PassTime USA of Littleton, Colo., are effective in reducing the incidence of default. However, significant human intervention (and thereby expense) is involved, which can reduce the efficiency of such mechanisms. In addition, such systems are decentralized, with timer logic and password authentication at the vehicles themselves rather than centrally located. In addition, there is often some burden and stigma associated with having a payment disablement system installed in a vehicle, which limits the feasible application of such devices. In addition, such devices are usually configured as “fail-safe to disable”, meaning that if no code is entered or no other communication is received, the vehicle will be disabled.
What is needed is an improved system and method for enforcing payment schedules in a centralized, flexible manner. What is further needed is a payment enforcement mechanism that is practical to install in many different types of products and devices. What is further needed is a payment enforcement mechanism that is capable of responding to various types of events. What is further needed is a payment enforcement mechanism that reduces the amount of effort and burden imposed on the owner (end purchaser) and minimizes or eliminates the need for code entry.

SUMMARY OF THE INVENTION

According to the techniques of the present invention, an improved payment schedule enforcement system and method are provided. Various types of events can be configured via software running at an operations center. Upon occurrence of a specified event, a message is sent to a remotely located device, such as one installed in a vehicle or other product. The remotely located device is configured so that it can disable the vehicle (for example by disabling the starter circuitry) upon receipt of the message from the operations center. In implementations involving products other than vehicles, other mechanisms for disabling the product (such as cutting off power to the product) can be used. The remotely located device can be instructed to allow a certain number of emergency uses, or to accept an override password that re-enables use of the vehicle.
For example, the system of the present invention can be configured with a payment schedule. If a buyer of a vehicle fails to make payment by a certain date, the system of the present invention automatically sends messages to a device installed in the vehicle to take appropriate action such as output a series of warning alerts and/or disable the starter mechanism for the vehicle.
In one embodiment, the remotely located device is implemented as part of existing communicatively enabled components of the vehicle (such as a navigation system and/or Global Positioning System (GPS)). In another embodiment, it is implemented as an add-on device that can be installed in any vehicle. In another embodiment, the driver of the vehicle can communicate with the remotely located device via voice communication. In addition to triggering disablement, the operations center can send messages that cause the device to alert the customer as to certain conditions (such as a warning of impending disablement, or availability of product updates, or receipt of payment, or the like). Messages from the operations center can be sent in accordance with a predefined schedule or in response to manually entered instructions from a system operator. In one embodiment, the operations center can also receive messages from remotely located devices, including for example acknowledgments, marketing data, position information, usage information, or the like.
In one embodiment, the operations center can also send messages to external agents such as repossession agents, roadside assistance providers, or the like. Depending on the circumstances, these external agents can be provided with additional information (such as, for example, GPS data specifying the location of the vehicle). In such a manner, the present invention provides a technique for initiating third-party response to the triggering event where appropriate.
The present invention thus provides a system and method for enforcing payment schedules that avoids the limitations of prior art systems. Improved flexibility and ease-of-use are provided by the use of an operations center that transmits messages instructing remotely controlled devices to disable products or to perform other functions. The present invention thus enables payment enforcement with less reliance on decentralized components and without requiring repeated transmission of codes (or manual entry of codes) to keep a vehicle from shutting down.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an overall architecture for an embodiment of the invention.
FIG. 2 is a flow diagram depicting operation of the invention according to one embodiment.
FIG. 3 depicts an example of a user interface screen for setting up customer information and payment schedule according to one embodiment.
FIG. 4 depicts an example of a user interface screen for viewing GPS information, customer information, and payment history, according to one embodiment.
FIG. 5 depicts an example of a user interface screen for specifying warning periods, shutdown periods, payment information, and the like, according to one embodiment.
FIG. 6 depicts an example of a user interface screen for displaying a location of a vehicle, according to one embodiment.

DETAILED DESCRIPTION OF THE EMBODIMENTS

According to one embodiment, the present invention is implemented as a software application running at an operations center. The software application detects events and generates messages in response to the events. These messages are received by remotely located devices installed in vehicles or other products. Upon receiving a message, the remotely located device takes appropriate action, such as issuing an alert, disabling the vehicle, or the like.
For purposes of the following description, the invention is set forth in terms of a system for disabling vehicles in the event of nonpayment by the owner (purchaser) of the vehicle. One skilled in the art will recognize, however, that the techniques of the present invention can be used in many other contexts as well. For example, the invention can be used to disable any product remotely in response to certain trigger events. In addition, the invention can be used to generate messages and alerts, either to the purchaser or to a third party, in response to events. Accordingly, the following description is intended to be exemplary of one particular embodiment, and is not intended to limit the scope of the invention.
Referring now to FIG. 1, there is shown a block diagram depicting an overall architecture for an embodiment of the invention. Software 102 running at operations center 101 performs much of the functionality of the present invention. In one embodiment, operations center 101 is situated at some central location and is operated by or on behalf of a lender, seller, or loan service company. Appropriate communications infrastructure, such as Internet, wireless, and/or telecommunications connectivity is provided, so as to allow operations center 101 to communicate with other elements of the overall system.
System administrator 104 interacts with software 102 via user interface 103, which allows system administrator 104 to specify options, schedules, alert conditions, and the like, and also allows system administrator 104 to view reports, monitor system operations, and the like. System administrator 104 may be located at or near operations center 101, or may be remotely located, in which case interactions with software 102 may take place over a computer network such as the Internet, virtual private network, or the like, according to techniques that are well known to those of skill in the art.
Payment schedule 105 for a particular debtor is stored, for example, in a database or other data store at operations center 101 or at some other location. Software 102 enforces payment schedule 105 by sending appropriate messages 107A, 107B to vehicle 109 and/or to external agent 108, respectively. Software 102 is communicatively coupled with accounting systems (not shown) or other sources of data that inform software 102 when a payment is late or when other relevant events take place that require messages 107A, 107B to be sent.
In one embodiment, software 102 invokes event management middleware 106 to send messages 107A to device 111 at vehicle 109. In one embodiment, middleware 106 can also be used for sending messages 107B to external agent 108, although in other embodiments messages 107B are sent directly by software 102. Middleware 106 provides an interface by which software 102 can communicate with many different types of devices, systems, computers, vehicles, nodes, and the like, via a variety of protocols. Essentially, middleware 106 acts a protocol translation module between software 102 and whatever entities software 102 communicates with. For example, for certain devices 111, Internet Protocol (IP) may be an appropriate communication medium, whereas cell or pager messages may be the appropriate mechanism for other devices 111. Examples of other communication protocols that can be used include GPRS, SMS Edge, Java, SQL and the like. In one embodiment, the present invention is implemented using mobile device middleware available from Intellimatics of Coppell, Tex. Standard ODBC protocols can be used to communicate with Intellimatics databases (via SQL).
In addition to sending messages 107A and/or 107B, in one embodiment, middleware 106 can also receive messages. For example, middleware 106 may receive acknowledgement messages from device 111 and/or agent 108 to confirm receipt of messages 107A and/or 107B. Also, vehicle 109 may have GPS tracking capability, in which case GPS data can be sent to operations center 101 via middleware 106 when it is deemed appropriate or useful to do so. Other information that may be usefully transmitted to middleware 106 includes: mileage (for example to enforce mileage limits on rented or leased vehicles, or to determine whether preventative maintenance schedules are being followed).
Event management middleware 106 sends messages 107A to remotely located device 111 installed in vehicle 109. Such messages 107A instruct device 111 to perform various operations, such as disabling vehicle starter circuitry 112 in order to prevent operation of vehicle 109, outputting alerts or other information to owner 110 via output mechanism 113, or the like. Output mechanism 113 may be a speaker for issuing beeps and spoken information, or it may be a display screen for showing visual alerts, or some combination thereof. In one embodiment, output mechanism 113 is a standalone output device connected to or part of device 111; in another embodiment, output mechanism 113 can be implemented as part of an existing component of vehicle 109 such as a GPS navigation system, onboard trip computer, or other component. In this manner, the techniques of the present invention can be implemented in a manner that is well integrated with existing input and output mechanisms already present in vehicle 109.
In one embodiment, software 102 also sends messages 107B to one or more external agents 108 when appropriate, either via middleware 106 or directly or by some other means. For example, certain events may cause a message 107B to be sent to a repossession agent or company, so that vehicle 109 can be repossessed. Alternatively, certain events may warrant notifying a credit card company, lender, or even a roadside assistance provider. In one embodiment, middleware 106 can query device 111 for GPS information regarding vehicle 109, and cause GPS data to be sent to agent 108 so that agent 108 can quickly locate vehicle 109.
In one embodiment, software 102 can also receive messages 107C from technology trigger 121. Technology trigger 121 can be any source of information that is relevant to the payment schedule enforcement mechanism of the present invention. For example, technology trigger 121 may be a data stream providing information from a payment system, so that upon receipt of messages 107C from technology trigger 121, software causes payment schedule 105 and/or other information to be updated.
As indicated above, the system of the present invention can be used with products other than vehicles as well, in which case device 111 might be located in or attached to whatever product is subject to being remotely disabled according to the methods provided herein. In one embodiment, device 111 is communicatively coupled to vehicle starter circuitry 112; in other embodiments, device 111 is configured and situated so that it is capable of disabling the subject product when it receives a message instructing it to do so. For example, device 111 can be configured to be able to shut off a power source (such as 110-volt AC) to an appliance or other product.
In one embodiment, device 111 receives communications from middleware 106 via the same physical medium as is used to power the product (such as AC power lines). Such an arrangement prevents owner 110 (or some other individual) from disabling communications with middleware 106 without also cutting off power to the product. Such an embodiment may be effective for payment enforcement on appliances that run on AC power.
Device 111 can include additional components to enhance functionality. In one embodiment, device 111 includes a WiFi repeater to enable communication with vehicle 109 or other products. The repeater is capable of enabling and/or disabling certain actions within the vehicle such as fuel, ignition, or other components. Device 111 can communicate with middleware 106 using any wireless or wired communication channel, including for example Internet, cellular, radio, GSM, pager, or the like. In one embodiment, device 111 periodically polls middleware 106 for messages; alternatively, device 111 is passive and only responds when middleware 106 sends messages. In one embodiment, device 111 has an IP address so that it can be directly addressed via the Internet protocol.
Messages 107A and 107B may be encoded using any known encoding scheme or protocol. In one embodiment, messages 107A and 107B are password-protected and/or encrypted to reduce the possibility of interception and/or tampering.
Referring now to FIG. 2, there is shown a flowchart depicting a method of practicing the present invention according to one embodiment. Software 102 receives 201 payment schedule 105. In one embodiment, schedule 105 is provided via a computer-readable file such as a database file, which software 102 is able to read and interpret. In another embodiment, payment schedule 105 is transmitted to or otherwise conveyed to software 102. The operations by which software 102 receives 201 payment schedule 105 may take place under the control of system administrator 104 via user interface 103. In addition, administrator 104 can specify, via user interface 103, the characteristics of payment schedule 105 and the various actions that should be taken in response to various conditions.
Software 102 detects 202 events relevant to payment schedule 105. In one embodiment, software 202 is communicatively coupled with automated software modules (not show) that make software 102 aware of such events. In another embodiment, software 202 logs into Internet websites or other sources of information, providing appropriate authentication credentials when needed, to “scrape” or otherwise extract information relevant to events. In yet another embodiment, system administrator 104 or another individual performs manual data entry (for example via user interface 103) to inform software 102 that an event has occurred.
For example, one event is the fact that owner 110 is late on a payment. The occurrence of such an event can be provided to software 102 in any of several different ways. Software 102 may interact with accounting software that outputs a list of accounts that are in default, so that software 102 can interpret such a list as indicating a set of nonpayment events. Alternatively, software 102 may log onto a secure website to check the status of various accounts and thereby determine that a nonpayment event has taken place. Alternatively, system administrator 104 may manually enter a nonpayment event via user interface 103.
In one embodiment, the lack of occurrence of a certain event can be interpreted as the occurrence of a second event. For example, the system of the present invention can be configured so that software 102 is informed when a payment has occurred. In this case, failure to make a payment would not generate an event to be sent to software 102; rather, software 102 determines that since it has not received a payment event within a specified time period, it should assume that a nonpayment event has taken place. In other words, software 102 can infer certain events based on certain conditions.
Software 102 is configured to determine what types of messages are appropriate for different types of events. Based on such determination software 102 transmits 203 message 107A to remotely located device 111. In addition, if appropriate, software 102 transmits 204 message 107B to external agent 108. For example, software 102 may transmit a message 107B to any or all of the following:

- a repossession agent to initiate repossession proceedings;
- a dealer or loan servicing agent to inform them of the nonpayment event;
- a roadside assistance provider in case of emergency;
- a payment center and/or credit card processing operation to arrange for payment; and/or
- an interactive voice response (IVR) system to call owner 110 by telephone to inform him/her of the event and action taken, and to give owner 110 an opportunity to communicate with an individual at operations center 101 and/or to enter payment information directly.

As indicated above, messages 107A and 107B contain instructions as to what type of action should be taken. In addition, messages 107A and 107B can contain additional information as may be useful: for example, message 107B to external agent 108 can contain GPS data for vehicle 109 so as to assist external agent 108 in finding vehicle 109.
For example, software 102 may be configured to do the following:

- send an alert to owner 110 upon detecting a nonpayment event;
- send a second, more urgent alert after some number of days have passed after a nonpayment event;
- send a message 107 A instructing device 111 to disable vehicle starter circuitry 112 after some number of additional days have passed; and
- send a message 107B to a repossession agent or other external agent 108 after some number of additional days have passed.

Any or all of these actions may take place automatically. Alternatively, software 102 can prompt administrator 104 to approve or deny the taking of a particular action before the corresponding message is sent. For example, before causing a vehicle's starter circuitry 112 to be disabled, software 102 may prompt system administrator 104 to approve the sending of such a message; thus, the message 107A is sent only if the administrator 104 approves of such action.
In one embodiment, software 102 (via middleware 106) sends such messages 107A, 107B at the time that action is needed or desired. For example, software 102 tells device 111 to disable starter circuitry 112 now, and the action is taken immediately. Additional messages are sent if and when additional action is to be taken. In another embodiment, software 102 sends messages 107A, 107B that initiate a chain of actions according to a particular schedule. Thus, message 107A may instruct device 111 to send an alert now, send a second alert after a certain number of days, and disable starter circuitry 112 after some additional days. In the absence of further messages 107A from software 102, device 111 proceeds to take the specified actions according to the specified schedule. Thus, no further communications with operations center 101 are required in order for device 111 to perform the chain of actions. Of course, software 102 can issue a later message 107A countermanding the original message 107A (for example if payment is received after the first alert is output), so that the additional actions are not performed. In some embodiments, administrator 104 can configure whether actions should be performed at device 111 in direct response to messages 107A or according to a schedule specified in messages 107A, or some combination thereof.
At any time, system administrator 104 can monitor payment status and other information, and can change or reconfigure actions taken under the direction of software 102.
Messages 107A can specify any type of additional information and/or instructions for device 111, including for example emergency override procedures and parameters to allow owner 110 to operate vehicle 109 a limited number of times by entering an emergency code on a keypad. In addition, once payment has been received, a previous disablement can be reversed by sending a new message 107A indicating that vehicle operation should be re-enabled.
Vehicle 109 can also be equipped with a mechanism for communicating with personnel at operations center 101 so as to inquire as to the reason for an action having been taken. Thus, for example, owner 110 can request additional time to make a payment, or explain that payment has already been made, or the like. Vehicle 109 can also be equipped with a keypad, if desired, for entry of an enablement code as is known in the prior art, although such keypad is not necessary to practice the present invention. Such keypad may be provided as an emergency alternative if direct communication between operations center 101 and device 111 fails. In one embodiment, a password entered via keypad encodes additional information such as expiry date or the like, according to techniques described in related U.S. patent application Ser. No. 10/856,968 for “Encoding Data in a Password”, filed May 28, 2004, the disclosure of which is incorporated herein by reference.
Vehicle 109 can also be equipped with a credit card reader (not shown) to take payments. Device 111 then sends a message to software 102, via middleware 106, to let software 102 know that payment has been received. Software 102 can be equipped to acknowledge that payment has been made and can cause records to be updated accordingly.
Vehicle 109 can also be equipped with a user interface allowing owner 110 to receive alerts and messages, and further allowing owner 110 to communicate with operations center 101. The user interface can be implemented as part of device 111 or it can be communicatively coupled with device 111. The user interface can include any of a screen, touch-screen, keyboard, trackball, mouse, voice communication system, or any combination thereof.
Accordingly, the present invention provides a mechanism by which payment schedules can be enforced via remote disablement of vehicles 109 and other products. The present invention provides improved flexibility, automation, and reliability over prior art schemes. In addition, the present invention reduces the number of messages that need be transmitted, since messages need only be transmitted upon occurrence of nonpayment events, as opposed to each time a payment is received: as long as owner 110 makes timely payments, no messages need be sent. In addition, the present invention avoids false alarms that can occur when systems rely on receipt of payment codes; thus, the invention reduces the likelihood that an owner 110 making timely payments will be erroneously prevented from using his or her vehicle 109.
The system described herein is less obtrusive than existing systems that rely on entry of codes to keep a vehicle from being disabled. The system described herein also reduces the stigma associated with payment enforcement mechanisms, since it does not do anything unless a payment default occurs. Accordingly, the system described herein is suitable for use in connection with sales to good-credit customers as well as poor-credit customers.
Many variations will be apparent to one skilled in the art. For example, the present invention can be implemented with slight variations to inhibit or disable use of a vehicle based on its location. An event can be detection that the vehicle is being taken outside a specified permitted geographic zone (such as a state, or municipal boundary). A series of warnings can be issued, followed by a message to disable the vehicle. Appropriate procedures are followed to ensure that the safety of the driver is not compromised. Various consumer applications are possible: for example, a parent could check on the location of his or her child based on the GPS reading on the vehicle. Upon determining that the child is in a safe location, the parent could remotely disable the vehicle so as to prevent the child from driving further.
In one embodiment, device 111 can cause certain features to be enabled or disabled based on various events. For example, if owner 110 makes timely payments, enhanced navigation functionality might be enabled on an onboard navigation system. If owner 110 fails to make timely payments, an onboard entertainment unit can be disabled. Accordingly, in some embodiments, device 111 is communicatively coupled with other features and components of vehicle 109 such as GPS, navigation, or entertainment systems, so as to enable and/or disable such features in response to certain events.
User Interface
FIGS. 3-6 depict various examples of user interface screens for software 102. In one embodiment, these screens are presented as part of user interface 103 for use by system administrator 104 in configuring and operating the system of the present invention. Of course, one skilled in the art will recognize that these screens are merely exemplary and that other layouts, components, and arrangements can be used.
FIG. 3 depicts an example of a user interface screen 300 for setting up customer information and payment schedule according to one embodiment. Screen 300 can be used when a new vehicle owner 110 is being added to the system, for example in response to a new vehicle purchase.
Personal information about owner 110 can be entered in fields 301. Information about the vehicle can be entered in fields 302, 304, and 305. Payment scheduling information can be entered in fields 303, including start date, number of payments, purchase price, payment amount, payment schedule, account number, and grace days. In one embodiment, the payment scheduling information entered in fields 303 is used to update payment schedule 105 and is then used by software 102 in generating events, as described above. Payment information for received payments can be entered in fields 307. Right to cure information can be entered in fields 308. System administrator 104 clicks on button 309 to submit the entered information for entry in the appropriate databases, including for example payment schedule 105.
FIG. 4 depicts an example of a user interface screen 400 for viewing GPS information 403, customer information 405, and payment history 409, according to one embodiment. GPS information 403 is presented in latitude and longitude format; clicking on View Map link 404 causes map 600 to be displayed, as shown in FIG. 6. Clicking on Send Warning link 401 causes software 102 to instruct middleware 106 to send a message 107A to device 111, for example to alert owner 110 that payment has not yet been received. Clicking on Send Starter Disable link 402 causes software 102 to instruct middleware 106 to send a message 107A to device 111 to disable vehicle 109. Such messages can be initiated from screen 400 as a manual supplement to automatic generation of such messages that is described above.
Payment history 409 includes a list of recently received payments. In one embodiment, system administrator 104 can click on View links 410 in history 409 to see more information about a particular payment, and/or can also click on Print links 411 to print receipts of payments.
Also shown in screen 400 are vehicle information 406, payment schedule information 407, and email contact information 408.
FIG. 5 depicts an example of a user interface screen 500 for specifying warning periods, shutdown periods, payment information, and the like, according to one embodiment. Administrator 104 can enter a number of days until shutdown in field 501 or a shutdown date in field 502. Administrator 104 can enter a number of warning days in field 503 or a warning date in field 503A. Administrator 104 can also enter a number of emergency days in field 504. Payment information can be entered in fields 505, 506, and 507.
In the above description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention can be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to avoid obscuring the invention.
Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other such information storage, transmission or display devices.
The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
The algorithms and displays presented herein are not inherently related to any particular computer, network of computers, or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the required method steps. The required structure for a variety of these systems appears from the description. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.
As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. For example, the particular architectures depicted above are merely exemplary of one implementation of the present invention. The functional elements and method steps described above are provided as illustrative examples of one technique for implementing the invention; one skilled in the art will recognize that many other implementations are possible without departing from the present invention as recited in the claims. Likewise, the particular capitalization or naming of the modules, protocols, features, attributes, or any other aspect is not mandatory or significant, and the mechanisms that implement the invention or its features may have different names or formats. In addition, the present invention may be implemented as a method, process, user interface, computer program product, system, apparatus, or any combination thereof. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Claims

1. A method for remotely disabling a product in response to an event, comprising:

detecting a trigger event; and

responsive to detection of the trigger event, transmitting a message to a device coupled to the product in order to disable the product.

2. The method of claim 1, wherein disabling the product comprises preventing the product from operating.

3. The method of claim 1, wherein disabling the product comprises preventing a feature of the product from operating.

4. The method of claim 1, wherein the trigger event comprises a payment deadline.

5. The method of claim 1, wherein transmitting the message to a device comprises transmitting the message wirelessly.

6. The method of claim 1, wherein transmitting the message to a device comprises transmitting the message via the Internet.

7. The method of claim 1, wherein transmitting the message to a device comprises transmitting the message via a power line.

8. The method of claim 1, wherein the product comprises a vehicle.

9. The method of claim 1, wherein the product comprises one selected from the group consisting of:

an appliance;

a computing device;

a telecommunication device;

a handheld computer; and

a personal digital assistant.

10. The method of claim 1, wherein the transmitted message causes the device to output a warning concerning disablement.

11. The method of claim 1, further comprising, responsive to detection of the trigger event, transmitting a message to an external agent.

12. The method of claim 11, wherein the external agent comprises at least one selected from the group consisting of:

a repossession agent;

a credit issuer;

a credit reporting agency;

a lender;

a roadside assistance provider; and

a seller of the product.

13. The method of claim 1, further comprising receiving a message from the device.

14. The method of claim 13, wherein the received message was entered by the operator of the product associated with the device.

15. The method of claim 1, further comprising receiving location information from the device.

16. The method of claim 15, further comprising, responsive to detection of the trigger event, transmitting a message to an external agent, the message comprising the received location information.

17. The method of claim 1, wherein the message instructs the device to disable the product at a specified time in the event no additional messages are received by the device.

18. The method of claim 1, further comprising, outputting by the device an alert to indicate disablement of the product.

19. The method of claim 18, wherein the alert comprises one selected from the group consisting of a visual alert, an auditory alert, and a voice alert.

20. The method of claim 1, wherein the device is able to receive input from a user and provide output to a user.

21. The method of claim 1, wherein the device is able to receive voice input from a user and provide voice output to a user.

22. The method of claim 1, further comprising:

responsive to detection of a second trigger event, transmitting a message to a device coupled to the product in order to re-enable the product.

23. The method of claim 22, wherein the second trigger event represents user entry of payment information.

24. The method of claim 22, wherein the second trigger event represents user entry of payment information at a credit card reader.

25. The method of claim 24, wherein the credit card reader is coupled to the product.

26. A method for remotely enabling a feature of a product in response to an event, comprising:

detecting a trigger event; and

responsive to detection of the trigger event, transmitting a message to a device coupled to the product in order to enable the feature of the product.

27. The method of claim 26, wherein the product comprises a vehicle, and the feature of the product is associated with an onboard device installed in the vehicle.

28. A method for enforcing a payment schedule for a product, comprising:

receiving a payment schedule;

detecting a trigger event associated with the payment schedule;

responsive to detection of the event, transmitting a message to a device coupled to the product.

29. The method of claim 28, wherein the trigger event comprises an impending payment deadline, and wherein the message instructs the device to output a warning.

30. The method of claim 29, wherein the warning comprises an auditory warning.

31. The method of claim 29, wherein the warning comprises a visual warning.

32. The method of claim 31, wherein the trigger event comprises a payment deadline, and wherein the message instructs the device to disable the product.

33. The method of claim 31, wherein the trigger event comprises a payment deadline, and wherein the message instructs the device to output a warning and further to disable the product after a predefined period of time if no additional message is received.

34. A method for transmitting a message to a remotely located product, comprising:

at an operations center, detecting a trigger event associated with the product;

responsive to detection of the event, transmitting a message to a device coupled to the product, wherein the transmitted message causes the device to perform at least one selected from the group consisting of:

disabling the product; and

outputting a message concerning operation of the product.

35. The method of claim 34, wherein the message comprises at least one selected from the group consisting of:

a warning of possible disablement;

notification of available enhancement;

notification of available upgrade;

notification of available additional product; and

instructions regarding the use of the product.

36. The method of claim 34, further comprising, responsive to detection of the event, transmitting a message to an external agent concerning the trigger event for the product.

37. The method of claim 34, further comprising, responsive to detection of the event:

detecting a location of the product; and

transmitting a message to an external agent concerning the trigger event for the product, the message to the external agent comprising location information for the product.

38. A method for remotely disabling a product in response to an event, comprising:

receiving, at a device coupled to the product, a message from an operations center; and

responsive to receiving the message, disabling the product.

39. The method of claim 38, wherein the product comprises a vehicle.

40. The method of claim 38, wherein the product comprises one selected from the group consisting of:

an appliance;

a computing device;

a telecommunication device;

a handheld computer; and

a personal digital assistant.

41. The method of claim 38, further comprising, prior to disabling the product, outputting a warning concerning impending disablement.

42. The method of claim 38, further comprising, responsive to receiving the message, transmitting location information to the operations center.

43. The method of claim 38, further comprising:

receiving a second message from the operations center; and

responsive to receiving the second message, re-enabling the product.

44. The method of claim 38, further comprising:

receiving payment information; and

transmitting payment information to the operations center.

45. The method of claim 44, wherein receiving payment information comprises receiving payment information via a credit card reader.

46. The method of claim 45, wherein the credit card reader is coupled to the device.

47. A computer program product for remotely disabling a product in response to an event, comprising:

a computer-readable medium; and

computer program code, encoded on the medium, for:

detecting a trigger event; and

48. The computer program product of claim 47, wherein the computer program code for disabling the product comprises computer program code for preventing the product from operating.

49. The computer program product of claim 47, wherein the computer program code for disabling the product comprises computer program code for preventing a feature of the product from operating.

50. The computer program product of claim 47, wherein the trigger event comprises a payment deadline.

51. The computer program product of claim 47, wherein the transmitted message causes the device to output a warning concerning disablement.

52. The computer program product of claim 47, further comprising computer program code for, responsive to detection of the trigger event, transmitting a message to an external agent.

53. The computer program product of claim 52, wherein the external agent comprises at least one selected from the group consisting of:

a repossession agent;

a credit issuer;

a credit reporting agency;

a lender;

a roadside assistance provider; and

a seller of the product.

54. A system for remotely disabling a product in response to an event, comprising:

a device coupled to the product, for disabling the product in response to receiving a message;

processing logic for detecting a trigger event; and

a messaging component, coupled to the processing logic, for responsive to detection of the trigger event, transmitting a message to the device to disable the product.

55. The system of claim 54, wherein the trigger event comprises a payment deadline.

56. The system of claim 54, wherein the messaging component transmits the message to the device wirelessly.

57. The system of claim 54, wherein the messaging component transmits the message to the device via the Internet.

58. The system of claim 54, wherein the messaging component transmits the message to the device via a power line.

59. The system of claim 54, wherein the product comprises a vehicle.

60. The system of claim 54, wherein the product comprises one selected from the group consisting of:

an appliance;

a computing device;

a telecommunication device;

a handheld computer; and

a personal digital assistant.

61. The system of claim 54, wherein the transmitted message causes the device to output a warning concerning disablement.

62. The system of claim 54, wherein the messaging component further transmits a message to an external agent.

63. The system of claim 62, wherein the external agent comprises at least one selected from the group consisting of:

a repossession agent;

a credit issuer;

a credit reporting agency;

a lender;

a roadside assistance provider; and

a seller of the product.

64. The system of claim 54, wherein the messaging component further receives location information from the device.

65. The system of claim 64, wherein the messaging component further transmits a message to an external agent, the message comprising the received location information.

66. The system of claim 54, further comprising:

a payment component installed at the product, for receiving payment information; and

a second messaging component, installed at the product, for transmitting payment information to the processing logic.

67. The system of claim 66, wherein the payment component comprises a credit card reader.