US20070194881A1 - Enforcing payment schedules - Google Patents

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 toFIG. 1, there is shown a block diagram depicting an overall architecture for an embodiment of the invention.Software102 running atoperations center101 performs much of the functionality of the present invention. In one embodiment,operations center101 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 allowoperations center101 to communicate with other elements of the overall system.
• System administrator104 interacts withsoftware102 viauser interface103, which allowssystem administrator104 to specify options, schedules, alert conditions, and the like, and also allowssystem administrator104 to view reports, monitor system operations, and the like.System administrator104 may be located at ornear operations center101, or may be remotely located, in which case interactions withsoftware102 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 schedule105 for a particular debtor is stored, for example, in a database or other data store atoperations center101 or at some other location.Software102 enforcespayment schedule105 by sendingappropriate messages107A,107B tovehicle109 and/or toexternal agent108, respectively.Software102 is communicatively coupled with accounting systems (not shown) or other sources of data that informsoftware102 when a payment is late or when other relevant events take place that requiremessages107A,107B to be sent.
• In one embodiment,software102 invokesevent management middleware106 to sendmessages107A todevice111 atvehicle109. In one embodiment,middleware106 can also be used for sendingmessages107B toexternal agent108, although inother embodiments messages107B are sent directly bysoftware102.Middleware106 provides an interface by whichsoftware102 can communicate with many different types of devices, systems, computers, vehicles, nodes, and the like, via a variety of protocols. Essentially,middleware106 acts a protocol translation module betweensoftware102 and whateverentities software102 communicates with. For example, forcertain devices111, Internet Protocol (IP) may be an appropriate communication medium, whereas cell or pager messages may be the appropriate mechanism forother devices111. 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 sendingmessages107A and/or107B, in one embodiment,middleware106 can also receive messages. For example,middleware106 may receive acknowledgement messages fromdevice111 and/oragent108 to confirm receipt ofmessages107A and/or107B. Also,vehicle109 may have GPS tracking capability, in which case GPS data can be sent tooperations center101 viamiddleware106 when it is deemed appropriate or useful to do so. Other information that may be usefully transmitted tomiddleware106 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 middleware106 sendsmessages107A to remotely locateddevice111 installed invehicle109.Such messages107A instructdevice111 to perform various operations, such as disablingvehicle starter circuitry112 in order to prevent operation ofvehicle109, outputting alerts or other information toowner110 viaoutput mechanism113, or the like.Output mechanism113 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 mechanism113 is a standalone output device connected to or part ofdevice111; in another embodiment,output mechanism113 can be implemented as part of an existing component ofvehicle109 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 invehicle109.
• In one embodiment,software102 also sendsmessages107B to one or moreexternal agents108 when appropriate, either viamiddleware106 or directly or by some other means. For example, certain events may cause amessage107B to be sent to a repossession agent or company, so thatvehicle109 can be repossessed. Alternatively, certain events may warrant notifying a credit card company, lender, or even a roadside assistance provider. In one embodiment,middleware106 can querydevice111 for GPSinformation regarding vehicle109, and cause GPS data to be sent toagent108 so thatagent108 can quickly locatevehicle109.
• In one embodiment,software102 can also receivemessages107C fromtechnology trigger121.Technology trigger121 can be any source of information that is relevant to the payment schedule enforcement mechanism of the present invention. For example,technology trigger121 may be a data stream providing information from a payment system, so that upon receipt ofmessages107C fromtechnology trigger121, software causespayment schedule105 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 whichcase device111 might be located in or attached to whatever product is subject to being remotely disabled according to the methods provided herein. In one embodiment,device111 is communicatively coupled tovehicle starter circuitry112; in other embodiments,device111 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,device111 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,device111 receives communications frommiddleware106 via the same physical medium as is used to power the product (such as AC power lines). Such an arrangement prevents owner110 (or some other individual) from disabling communications withmiddleware106 without also cutting off power to the product. Such an embodiment may be effective for payment enforcement on appliances that run on AC power.
• Device111 can include additional components to enhance functionality. In one embodiment,device111 includes a WiFi repeater to enable communication withvehicle109 or other products. The repeater is capable of enabling and/or disabling certain actions within the vehicle such as fuel, ignition, or other components.Device111 can communicate withmiddleware106 using any wireless or wired communication channel, including for example Internet, cellular, radio, GSM, pager, or the like. In one embodiment,device111 periodicallypolls middleware106 for messages; alternatively,device111 is passive and only responds whenmiddleware106 sends messages. In one embodiment,device111 has an IP address so that it can be directly addressed via the Internet protocol.
• Messages107A and107B may be encoded using any known encoding scheme or protocol. In one embodiment,messages107A and107B are password-protected and/or encrypted to reduce the possibility of interception and/or tampering.
• Referring now toFIG. 2, there is shown a flowchart depicting a method of practicing the present invention according to one embodiment.Software102 receives201payment schedule105. In one embodiment,schedule105 is provided via a computer-readable file such as a database file, whichsoftware102 is able to read and interpret. In another embodiment,payment schedule105 is transmitted to or otherwise conveyed tosoftware102. The operations by whichsoftware102 receives201payment schedule105 may take place under the control ofsystem administrator104 viauser interface103. In addition,administrator104 can specify, viauser interface103, the characteristics ofpayment schedule105 and the various actions that should be taken in response to various conditions.
• Software102 detects202 events relevant topayment schedule105. In one embodiment,software202 is communicatively coupled with automated software modules (not show) that makesoftware102 aware of such events. In another embodiment,software202 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 administrator104 or another individual performs manual data entry (for example via user interface103) to informsoftware102 that an event has occurred.
• For example, one event is the fact thatowner110 is late on a payment. The occurrence of such an event can be provided tosoftware102 in any of several different ways.Software102 may interact with accounting software that outputs a list of accounts that are in default, so thatsoftware102 can interpret such a list as indicating a set of nonpayment events. Alternatively,software102 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 administrator104 may manually enter a nonpayment event viauser interface103.
• 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 thatsoftware102 is informed when a payment has occurred. In this case, failure to make a payment would not generate an event to be sent tosoftware102; rather,software102 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,software102 can infer certain events based on certain conditions.
• Software102 is configured to determine what types of messages are appropriate for different types of events. Based onsuch determination software102 transmits203message107A to remotely locateddevice111. In addition, if appropriate,software102 transmits204message107B toexternal agent108. For example,software102 may transmit amessage107B 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 callowner110 by telephone to inform him/her of the event and action taken, and to giveowner110 an opportunity to communicate with an individual atoperations center101 and/or to enter payment information directly.
• As indicated above,messages107A and107B contain instructions as to what type of action should be taken. In addition,messages107A and107B can contain additional information as may be useful: for example,message107B toexternal agent108 can contain GPS data forvehicle109 so as to assistexternal agent108 in findingvehicle109.
• For example,software102 may be configured to do the following:
• • send an alert toowner110 upon detecting a nonpayment event;
  • send a second, more urgent alert after some number of days have passed after a nonpayment event;
  • send amessage107A instructing device111 to disablevehicle starter circuitry112 after some number of additional days have passed; and
  • send amessage107B to a repossession agent or otherexternal agent108 after some number of additional days have passed.
• Any or all of these actions may take place automatically. Alternatively,software102 can promptadministrator104 to approve or deny the taking of a particular action before the corresponding message is sent. For example, before causing a vehicle'sstarter circuitry112 to be disabled,software102 may promptsystem administrator104 to approve the sending of such a message; thus, themessage107A is sent only if theadministrator104 approves of such action.
• In one embodiment, software102 (via middleware106) sendssuch messages107A,107B at the time that action is needed or desired. For example,software102 tellsdevice111 to disablestarter circuitry112 now, and the action is taken immediately. Additional messages are sent if and when additional action is to be taken. In another embodiment,software102 sendsmessages107A,107B that initiate a chain of actions according to a particular schedule. Thus,message107A may instructdevice111 to send an alert now, send a second alert after a certain number of days, and disablestarter circuitry112 after some additional days. In the absence offurther messages107A fromsoftware102,device111 proceeds to take the specified actions according to the specified schedule. Thus, no further communications withoperations center101 are required in order fordevice111 to perform the chain of actions. Of course,software102 can issue alater message107A countermanding theoriginal message107A (for example if payment is received after the first alert is output), so that the additional actions are not performed. In some embodiments,administrator104 can configure whether actions should be performed atdevice111 in direct response tomessages107A or according to a schedule specified inmessages107A, or some combination thereof.
• At any time,system administrator104 can monitor payment status and other information, and can change or reconfigure actions taken under the direction ofsoftware102.
• Messages107A can specify any type of additional information and/or instructions fordevice111, including for example emergency override procedures and parameters to allowowner110 to operate vehicle109 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 anew message107A indicating that vehicle operation should be re-enabled.
• Vehicle109 can also be equipped with a mechanism for communicating with personnel atoperations center101 so as to inquire as to the reason for an action having been taken. Thus, for example,owner110 can request additional time to make a payment, or explain that payment has already been made, or the like.Vehicle109 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 betweenoperations center101 anddevice111 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.
• Vehicle109 can also be equipped with a credit card reader (not shown) to take payments.Device111 then sends a message tosoftware102, viamiddleware106, to letsoftware102 know that payment has been received.Software102 can be equipped to acknowledge that payment has been made and can cause records to be updated accordingly.
• Vehicle109 can also be equipped with a userinterface allowing owner110 to receive alerts and messages, and further allowingowner110 to communicate withoperations center101. The user interface can be implemented as part ofdevice111 or it can be communicatively coupled withdevice111. 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 ofvehicles109 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 asowner110 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 anowner110 making timely payments will be erroneously prevented from using his or hervehicle109.
• 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,device111 can cause certain features to be enabled or disabled based on various events. For example, ifowner110 makes timely payments, enhanced navigation functionality might be enabled on an onboard navigation system. Ifowner110 fails to make timely payments, an onboard entertainment unit can be disabled. Accordingly, in some embodiments,device111 is communicatively coupled with other features and components ofvehicle109 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 forsoftware102. In one embodiment, these screens are presented as part ofuser interface103 for use bysystem administrator104 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 auser interface screen300 for setting up customer information and payment schedule according to one embodiment.Screen300 can be used when anew vehicle owner110 is being added to the system, for example in response to a new vehicle purchase.
• Personal information aboutowner110 can be entered infields301. Information about the vehicle can be entered infields302,304, and305. Payment scheduling information can be entered infields303, 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 infields303 is used to updatepayment schedule105 and is then used bysoftware102 in generating events, as described above. Payment information for received payments can be entered infields307. Right to cure information can be entered infields308.System administrator104 clicks onbutton309 to submit the entered information for entry in the appropriate databases, including forexample payment schedule105.
• FIG. 4 depicts an example of auser interface screen400 for viewingGPS information403,customer information405, andpayment history409, according to one embodiment.GPS information403 is presented in latitude and longitude format; clicking on View Map link404 causes map600 to be displayed, as shown inFIG. 6. Clicking onSend Warning link401 causessoftware102 to instructmiddleware106 to send amessage107A todevice111, for example to alertowner110 that payment has not yet been received. Clicking on Send Starter Disable link402 causessoftware102 to instructmiddleware106 to send amessage107A todevice111 to disablevehicle109. Such messages can be initiated fromscreen400 as a manual supplement to automatic generation of such messages that is described above.
• Payment history409 includes a list of recently received payments. In one embodiment,system administrator104 can click on View links410 inhistory409 to see more information about a particular payment, and/or can also click onPrint links411 to print receipts of payments.
• Also shown inscreen400 arevehicle information406,payment schedule information407, andemail contact information408.
• FIG. 5 depicts an example of a user interface screen500 for specifying warning periods, shutdown periods, payment information, and the like, according to one embodiment.Administrator104 can enter a number of days until shutdown infield501 or a shutdown date infield502.Administrator104 can enter a number of warning days infield503 or a warning date in field503A.Administrator104 can also enter a number of emergency days infield504. Payment information can be entered infields505,506, and507.
• 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 (67)

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 ofclaim 1, wherein disabling the product comprises preventing the product from operating.

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

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

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

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

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

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

9. The method ofclaim 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 ofclaim 1, wherein the transmitted message causes the device to output a warning concerning disablement.

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

12. The method ofclaim 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 ofclaim 1, further comprising receiving a message from the device.

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

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

16. The method ofclaim 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 ofclaim 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 ofclaim 1, further comprising, outputting by the device an alert to indicate disablement of the product.

19. The method ofclaim 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 ofclaim 1, wherein the device is able to receive input from a user and provide output to a user.

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

22. The method ofclaim 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 ofclaim 22, wherein the second trigger event represents user entry of payment information.

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

25. The method ofclaim 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 ofclaim 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 ofclaim 28, wherein the trigger event comprises an impending payment deadline, and wherein the message instructs the device to output a warning.

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

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

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

33. The method ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 38, wherein the product comprises a vehicle.

40. The method ofclaim 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 ofclaim 38, further comprising, prior to disabling the product, outputting a warning concerning impending disablement.

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

43. The method ofclaim 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 ofclaim 38, further comprising:

receiving payment information; and

transmitting payment information to the operations center.

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

46. The method ofclaim 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

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

48. The computer program product ofclaim 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 ofclaim 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 ofclaim 47, wherein the trigger event comprises a payment deadline.

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

52. The computer program product ofclaim 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 ofclaim 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 ofclaim 54, wherein the trigger event comprises a payment deadline.

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

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

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

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

60. The system ofclaim 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 ofclaim 54, wherein the transmitted message causes the device to output a warning concerning disablement.

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

63. The system ofclaim 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 ofclaim 54, wherein the messaging component further receives location information from the device.

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

66. The system ofclaim 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 ofclaim 66, wherein the payment component comprises a credit card reader.

Images