U.S. patent application number 11/349523 was filed with the patent office on 2007-08-23 for enforcing payment schedules.
Invention is credited to Michael Glancy, Christopher M. Macheca, Stanley G. Schwarz.
Application Number | 20070194881 11/349523 |
Document ID | / |
Family ID | 38335123 |
Filed Date | 2007-08-23 |
United States Patent
Application |
20070194881 |
Kind Code |
A1 |
Schwarz; Stanley G. ; et
al. |
August 23, 2007 |
Enforcing payment schedules
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.
Inventors: |
Schwarz; Stanley G.;
(Littleton, CO) ; Macheca; Christopher M.;
(Centennial, CO) ; Glancy; Michael; (Highlands
Ranch, CO) |
Correspondence
Address: |
Amir H. Raubvogel;Attorney at Law
820 Lakeview Way
Redwood City
CA
94062
US
|
Family ID: |
38335123 |
Appl. No.: |
11/349523 |
Filed: |
February 7, 2006 |
Current U.S.
Class: |
340/5.31 ;
340/426.11; 340/5.4; 340/571; 340/6.1; 701/410; 705/400 |
Current CPC
Class: |
B60R 25/04 20130101;
B60R 25/045 20130101; B60R 25/104 20130101; G01S 19/13 20130101;
G06Q 10/06 20130101; G06Q 30/0283 20130101; G06Q 20/102 20130101;
H04W 4/021 20130101; B60R 25/102 20130101; G06Q 40/12 20131203;
G06Q 20/14 20130101; B60R 25/33 20130101; G06Q 10/08 20130101 |
Class at
Publication: |
340/005.31 ;
705/400; 340/005.4; 340/571; 701/207; 340/825.36; 340/426.11 |
International
Class: |
G08B 13/00 20060101
G08B013/00 |
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 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 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.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] 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
[0002] 1. Field of the Invention
[0003] The present invention relates to enforcement of payment
schedules by remote disablement of a device in response to a missed
payment or other event.
[0004] 2. Description of the Related Art
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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
[0015] FIG. 1 depicts an overall architecture for an embodiment of
the invention.
[0016] FIG. 2 is a flow diagram depicting operation of the
invention according to one embodiment.
[0017] FIG. 3 depicts an example of a user interface screen for
setting up customer information and payment schedule according to
one embodiment.
[0018] FIG. 4 depicts an example of a user interface screen for
viewing GPS information, customer information, and payment history,
according to one embodiment.
[0019] 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.
[0020] 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
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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).
[0027] 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).
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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: [0040] a repossession agent to initiate repossession
proceedings; [0041] a dealer or loan servicing agent to inform them
of the nonpayment event; [0042] a roadside assistance provider in
case of emergency; [0043] a payment center and/or credit card
processing operation to arrange for payment; and/or [0044] 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.
[0045] 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.
[0046] For example, software 102 may be configured to do the
following: [0047] send an alert to owner 110 upon detecting a
nonpayment event; [0048] send a second, more urgent alert after
some number of days have passed after a nonpayment event; [0049]
send a message 107A instructing device 111 to disable vehicle
starter circuitry 112 after some number of additional days have
passed; and [0050] send a message 107B to a repossession agent or
other external agent 108 after some number of additional days have
passed.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] 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
[0062] 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.
[0063] 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.
[0064] 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.
[0065] 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.
[0066] 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.
[0067] Also shown in screen 400 are vehicle information 406,
payment schedule information 407, and email contact information
408.
[0068] 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.
[0069] 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.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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.
* * * * *