Patent Description:
Modern systems, especially compute systems are providing increasing levels of functionality to support modern life including additional status monitoring and connectivity services. Technology has enabled increased tracking of vehicle usage. Theft is often reported long after the vehicle has already been stolen.

Thus, a need still remains for a compute system with a theft alert mechanism. In view of the ever-increasing commercial competitive pressures, along with growing consumer expectations and the diminishing opportunities for meaningful product differentiation in the marketplace, it is increasingly critical that answers be found to these problems. Additionally, the need to reduce costs, improve efficiencies and performance, and meet competitive pressures adds an even greater urgency to the critical necessity for finding answers to these problems.

Solutions to these problems have been long sought but prior developments have not taught or suggested any solutions and, thus, solutions to these problems have long eluded those skilled in the art.

In the related art, <CIT> discusses methods of theft prevention or mitigation.

Certain embodiments of the invention have other steps or elements in addition to or in place of those mentioned above. The steps or elements will become apparent to those skilled in the art from a reading of the following detailed description when taken with reference to the accompanying drawings.

The following embodiments are described in sufficient detail to enable those skilled in the art to make and use the invention. It is to be understood that other embodiments would be evident based on the present disclosure, and that system, process, or mechanical changes may be made without departing from the scope of an embodiment of the present invention.

In the following description, numerous specific details are given to provide a thorough understanding of the invention. However, it will be apparent that the invention can be practiced without these specific details. In order to avoid obscuring an embodiment of the present invention, some well-known circuits, system configurations, and process steps are not disclosed in detail.

The drawings showing embodiments of the system are semi-diagrammatic, and not to scale and, particularly, some of the dimensions are for the clarity of presentation and are shown exaggerated in the drawing figures. Similarly, although the views in the drawings for ease of description generally show similar orientations, this depiction in the figures is arbitrary for the most part. Generally, the invention can be operated in any orientation. The embodiments have been numbered first embodiment, second embodiment, etc. as a matter of descriptive convenience and are not intended to have any other significance or provide limitations for an embodiment of the present invention. The terms first, second, etc. can be used throughout as part of element names and are used as a matter of descriptive convenience and are not intended to have any other significance or provide limitations for an embodiment.

The term "module" referred to herein can include or be implemented as software, hardware, or a combination thereof in the present invention in accordance with the context in which the term is used. For example, the software can be machine code, firmware, embedded code, and application software. The software can also include a function, a call to a function, a code block, or a combination thereof. Also for example, the hardware can be gates, circuitry, processor, computer, integrated circuit, integrated circuit cores, a pressure sensor, an inertial sensor, a microelectromechanical system (MEMS), passive devices, physical non-transitory memory medium including instructions for performing the software function, a portion therein, or a combination thereof to control one or more of the hardware units or circuits. Further, if a module is written in the apparatus claims section below, the modules are deemed to include hardware circuitry for the purposes and the scope of apparatus claims.

The modules in the following description of the embodiments can be coupled to one other as described or as shown. The coupling can be direct or indirect without or with, respectively, intervening items between coupled items. The coupling can be physical contact or by communication between items.

Referring now to <FIG>, therein is shown a compute system <NUM> with a theft alert mechanism in an embodiment of the present invention. The compute system <NUM> includes a first device <NUM>, such as a client or a server, connected to a second device <NUM>, such as a client or server. The first device <NUM> can communicate with the second device <NUM> with a communication path <NUM>, such as a wireless or wired network.

For example, the first device <NUM> can be of any of a variety of devices, such as a vehicle, a telematics system in a vehicle, a computing device, a cellular phone, a tablet computer, a smart phone, a notebook computer, vehicle embedded navigation system, or a dongle or device that plugs into a vehicle. The first device <NUM> can couple, either directly or indirectly, to the communication path <NUM> to communicate with the second device <NUM> or can be a stand-alone device.

The second device <NUM> can be any of a variety of centralized or decentralized computing devices, sensor devices to take measurements or record environmental information, such as sensor instruments, sensor equipment, or a sensor array. For example, the second device <NUM> can be a multimedia computer, a laptop computer, a desktop computer, grid-computing resources, a virtualized computer resource, cloud computing resource, routers, switches, peer-to-peer distributed computing devices, a vehicle, or a combination thereof.

The second device <NUM> can be mounted externally or internally to a vehicle, centralized in a single room or within a vehicle, distributed across different rooms, distributed across different geographical locations, embedded within a telecommunications network. The second device <NUM> can couple with the communication path <NUM> to communicate with the first device <NUM>.

For illustrative purposes, the compute system <NUM> is described with the second device <NUM> as a computing device, although it is understood that the second device <NUM> can be different types of devices, such as a standalone sensor or measurement device. Also for illustrative purposes, the compute system <NUM> is shown with the second device <NUM> and the first device <NUM> as end points of the communication path <NUM>, although it is understood that the compute system <NUM> can have a different partition between the first device <NUM>, the second device <NUM>, and the communication path <NUM>. For example, the first device <NUM>, the second device <NUM>, or a combination thereof can also function as part of the communication path <NUM>.

The communication path <NUM> can span and represent a variety of networks and network topologies. For example, the communication path <NUM> can include wireless communication, wired communication, optical, ultrasonic, or the combination thereof. Satellite communication, cellular communication, Bluetooth, Infrared Data Association standard (lrDA), wireless fidelity (WiFi), and worldwide interoperability for microwave access (WiMAX) are examples of wireless communication that can be included in the communication path <NUM>. Ethernet, digital subscriber line (DSL), fiber to the home (FTTH), and plain old telephone service (POTS) are examples of wired communication that can be included in the communication path <NUM>. Further, the communication path <NUM> can traverse a number of network topologies and distances. For example, the communication path <NUM> can include direct connection, personal area network (PAN), local area network (LAN), metropolitan area network (MAN), wide area network (WAN), or a combination thereof.

Referring now to <FIG>, therein is shown an example a top plan view of various a vehicle <NUM> of the compute system <NUM> of <FIG>. As an example, the compute system <NUM> can include or interact with the vehicle <NUM> as the first device <NUM> of <FIG>. The vehicle <NUM> can also include one or more of vehicle sensors <NUM>. The vehicle <NUM> is an object or a machine used for transporting people or goods. The vehicle <NUM> can also be capable of providing assistance in maneuvering or operating the object or the machine.

The vehicle <NUM> can represent a transportation mechanism of different or similar types. For example, the vehicle <NUM> can be only one instance or only one type of the transportation mechanism, such as an automobile. Also for example, the vehicle <NUM> can represent more than one vehicle, such as in a fleet or rental car scenario or the number of automobiles on the road or at a location. Further for example, the vehicle <NUM> can represent different types of the transportation mechanism, such as automobiles, trucks, motorcycles, bicycles, or seqways.

The vehicle <NUM> can include or represent different types of vehicles. For example, the vehicle <NUM> can be an electric vehicle, a combustion vehicle, or a hybrid vehicle. Also for example, the vehicle <NUM> can be an autonomous vehicle or non-autonomous vehicle. As a specific example, the vehicle <NUM> can include a car, a truck, a cart, or a combination thereof.

The vehicle <NUM> can include a device, a circuit, one or more specific sensors, or a combination thereof for providing assistance or additional information to control, maneuver, or operate the vehicle <NUM>. The vehicle <NUM> can include a vehicle communication circuit <NUM>, a vehicle control circuit <NUM>, a vehicle storage circuit <NUM>, other interfaces, or a combination thereof.

The vehicle <NUM> can also include on-board diagnostics <NUM> (OBD) that can be accessed by the vehicle control circuit <NUM>. As an example, the vehicle control circuit <NUM> can access the on-board diagnostics <NUM> with the vehicle communication circuit <NUM>. The vehicle <NUM> can store and retrieve the on-board diagnostics <NUM> to and from the vehicle storage circuit <NUM>.

The on-board diagnostics <NUM> represent information about the vehicle <NUM>. For example, the on-board diagnostics <NUM> can provide status or the state of the vehicle <NUM> or a portion thereof.

The vehicle storage circuit <NUM> can include a functional unit or circuit integral to the vehicle <NUM> and configured to store and recall information. The vehicle storage circuit <NUM> can be a volatile memory, a nonvolatile memory, an internal memory, an external memory, or a combination thereof. For example, the vehicle storage circuit <NUM> can be a nonvolatile storage such as non-volatile random access memory (NVRAM), Flash memory, disk storage, or a volatile storage such as static random access memory (SRAM).

The vehicle storage circuit <NUM> can store vehicle software, other relevant data, such as input information, information from sensors, processing results, information predetermined or preloaded by the compute system <NUM> or vehicle manufacturer, or a combination thereof. The vehicle storage circuit <NUM> can store the information for the on-board diagnostics <NUM>.

The vehicle control circuit <NUM> can include a function unit or circuit integral to the vehicle <NUM> and configured to execute or implement instructions. The vehicle control circuit <NUM> can execute or implement the vehicle software to provide the intelligence of the vehicle <NUM>, the compute system <NUM>, or a combination thereof. The vehicle control circuit <NUM> can respond to requests for the on-board diagnostics <NUM>. The request can be from other parts of the vehicle <NUM>, the compute system <NUM>, or a combination thereof or external to the compute system <NUM>.

The vehicle control circuit <NUM> can be implemented in a number of different manners. For example, the vehicle control circuit <NUM> can be a processor, an application specific integrated circuit (ASIC) an embedded processor, a microprocessor, a hardware control logic, a hardware finite state machine (FSM), a digital signal processor (DSP), or a combination thereof. As a more specific example, the vehicle control circuit <NUM> can include an engine control unit, one or more central processing unit, or a combination thereof.

The vehicle communication circuit <NUM> can include a function unit or circuit integral to the vehicle <NUM> and configured to enable external communication to and from the vehicle <NUM>. For example, the vehicle communication circuit <NUM> can permit the vehicle <NUM> to communicate with the first device <NUM>, the second device <NUM> of <FIG>, the communication path <NUM> of <FIG>, or a combination thereof. The vehicle communication circuit <NUM> can provide the on-board diagnostics <NUM> to other portions of the vehicle <NUM>, the compute system <NUM>, or a combination thereof or external to the compute system <NUM>.

The vehicle communication circuit <NUM> can also function as a communication hub allowing the vehicle <NUM> to function as part of the communication path <NUM> and not limited to be an end point or terminal circuit to the communication path <NUM>. The vehicle communication circuit <NUM> can include active and passive components, such as microelectronics or an antenna, for interaction with the communication path <NUM>. For example, the vehicle communication circuit <NUM> can include a modem, a transmitter, a receiver, a port, a connector, or a combination thereof for wired communication, wireless communication, or a combination thereof.

The vehicle communication circuit <NUM> can couple with the communication path <NUM> to send or receive information directly between the vehicle communication circuit <NUM> and the first device <NUM>, the second device <NUM>, or a combination thereof as endpoints of the communication, such as for direct line-of-sight communication or peer-to-peer communication. The vehicle communication circuit <NUM> can further couple with the communication path <NUM> to send or receive information through a server or another intermediate device in between endpoints of the communication.

The vehicle <NUM> can further include various interfaces. The vehicle <NUM> can include one or more interfaces for interaction or internal communication between functional units or circuits of the vehicle <NUM>. For example, the vehicle <NUM> can include one or more interfaces, such as drivers, firmware, wire connections or buses, protocols, or a combination thereof, for the vehicle storage circuit <NUM>, the vehicle control circuit <NUM>, or a combination thereof.

The vehicle <NUM> can further include one or more interfaces for interaction with an occupant, an operator or a driver, a passenger, or a combination thereof relative to the vehicle <NUM>. For example, the vehicle <NUM> can include a user interface including input or output devices or circuits, such as a screen or touch screen, a speaker, a microphone, a keyboard or other input devices, an instrument panel, or a combination thereof.

The vehicle <NUM> can further include one or more interfaces along with switches or actuators for physically controlling movable components of the vehicle <NUM>. For example, the vehicle <NUM> can include the one or more interfaces along with the controlling mechanisms to physically perform and control the maneuvering of the vehicle <NUM>, such as for automatic driving or maneuvering features.

The functional units or circuits in the vehicle <NUM> can work individually and independently of the other functional units or circuits. The vehicle <NUM> can work individually and independently from the first device <NUM>, the communication path <NUM>, the second device <NUM>, other devices or vehicles, or a combination thereof.

The functional units or circuits described above can be implemented in hardware. For example, one or more of the functional units or circuits can be implemented using the a gate, circuitry, a processor, a computer, integrated circuit, integrated circuit cores, a pressure sensor, an inertial sensor, a microelectromechanical system (MEMS), a passive device, a physical non-transitory memory medium containing instructions for performing the software function, a portion therein, or a combination thereof.

The vehicle sensors <NUM> are each a device for detecting or identifying environment of the vehicle <NUM>. The vehicle sensors <NUM> can detect, identify, determine, or a combination thereof for the vehicle <NUM> itself, such as for status or movement thereof through a vehicle-related sensor reading <NUM>. The vehicle-related sensor reading <NUM> can provide information about what is detected, identified, determined, or a combination thereof for environment within a cabin of the vehicle <NUM>, an environment external to and surrounding the vehicle <NUM>, or a combination thereof.

For example, the vehicle sensors <NUM> can include a location-movement sensor <NUM>, a visual sensor <NUM>, a radar sensor <NUM>, an accessory sensor <NUM>, a volume sensor <NUM>, or a combination thereof. The location-movement sensor <NUM> can identify or calculate a geographic location of the vehicle <NUM>, determine a movement of the vehicle <NUM>, or a combination thereof. Examples of the location-movement sensor <NUM> can include an accelerometer, a speedometer, a GPS receiver or device, a gyroscope or a compass, or a combination thereof. The vehicle <NUM> can include the vehicle sensors <NUM> other than or in addition to the location-movement sensor <NUM> such as thermal sensor. The thermal sensor can capture and provide temperature readings for portions of the vehicle <NUM>. The thermal sensor can also capture and provide temperature readings external to the vehicle <NUM>.

The visual sensor <NUM> can include a sensor for detecting or determining visual information representing the environment external to and surrounding the vehicle <NUM>. The visual sensor <NUM> can include a camera attached to or integral with the vehicle <NUM>. For example, the visual sensor <NUM> can include a camera, such as forward facing camera, a rear-view or backup camera, a side-view or a blind-spot camera, or a combination thereof. Also for example, the visual sensor <NUM> can include an infrared sensor or a night vision sensor.

The visual sensor <NUM> can further include a camera on the first device <NUM> connected to and interacting with the vehicle <NUM>. The visual sensor <NUM> can further include a cabin camera for detecting or determining visual information inside the vehicle or cabin of the vehicle.

The radar sensor <NUM> can include an object-detection system, device, or circuit. The radar sensor <NUM> can determine or identify an existence of an object or a target, such as an obstacle or another vehicle, external to the vehicle <NUM> a relative location or a distance between the object or the target and the vehicle <NUM>, or a combination thereof.

The radar sensor <NUM> can utilize radio waves to determine or identify an existence of the object or the target, the relative location or a distance from the vehicle <NUM>, or a combination thereof. For example, the radar sensor <NUM> can include a proximity sensor or warning system, such as for an area in front of, behind, adjacent to or on a side of, or a combination thereof geographically or physically relative to the vehicle <NUM>.

The accessory sensor <NUM> can include a sensor for determining or detecting a status of a subsystem or a feature of the vehicle <NUM>. The accessory sensor <NUM> can determine or detect the status or a setting for windshield wipers, turn signals, gear setting, headlights, or a combination thereof.

The volume sensor <NUM> can include a sensor for detecting or determining sounds for the vehicle <NUM>. The volume sensor <NUM> can include a microphone for detecting or determining sounds within a cabin of the vehicle <NUM>. The volume sensor <NUM> can further include a circuit for detecting or determining a volume level or an output level of speakers within the vehicle <NUM>.

The vehicle <NUM> can use one or more of the vehicle sensors <NUM> to generate the on-board diagnostics <NUM> describing or representing information regarding the environment within or surrounding the vehicle <NUM>. The on-board diagnostics <NUM> can be further processed with the vehicle control circuit <NUM>, stored in the vehicle storage circuit <NUM>, communicated to another device through the vehicle control circuit <NUM>, or a combination thereof.

The vehicle <NUM> can further include a user device or a mobile device illustrated in <FIG>. For example, the vehicle <NUM> can include the first device <NUM>.

As a more specific example, the vehicle communication circuit <NUM>, the vehicle control circuit <NUM>, the vehicle storage circuit <NUM>, the vehicle sensors <NUM>, one or more interfaces, or a combination thereof can be included in or make up the first device <NUM> included in or integral with the vehicle <NUM>. Also as a more specific example, the vehicle <NUM> can include or be integral with the first device <NUM> including an embedded compute system, an infotainment system, a smart driving or a driver assistance system, a self-driving or a maneuvering system for the vehicle, or a combination thereof.

Referring now to <FIG>, therein is shown an example of a block diagram of the compute system <NUM>. The compute system <NUM> can include the first device <NUM>, the communication path <NUM>, and the second device <NUM>. The first device <NUM>, the second device <NUM>, or a combination thereof can provide a nonvehicle reading <NUM>. The nonvehicle reading <NUM> provides information from and to various circuits shown as an example in <FIG> and not embedded in the vehicle <NUM> of <FIG>. The first device <NUM> can send information in a first device transmission <NUM> over the communication path <NUM> to the second device <NUM>. The second device <NUM> can send information in a second device transmission <NUM> over the communication path <NUM> to the first device <NUM>. The nonvehicle reading <NUM> can be sent with the first device transmission <NUM>, the second device transmission <NUM>, or a combination thereof.

For illustrative purposes, the compute system <NUM> is shown with the first device <NUM> as a client device, although it is understood that the compute system <NUM> can include the first device <NUM> as a different type of device. For example, the first device <NUM> can be a server including a display interface. Also for example, the first device <NUM> can represent the vehicle <NUM> of <FIG>.

Also for illustrative purposes, the compute system <NUM> is shown with the second device <NUM> as a server, although it is understood that the compute system <NUM> can include the second device <NUM> as a different type of device. For example, the second device <NUM> can be a client device. Also for example, the second device <NUM> can represent the vehicle <NUM>.

Further, for illustrative purposes, the compute system <NUM> is shown with interaction between the first device <NUM> and the second device <NUM>, although it is understood that the first device <NUM> can similarly interact another instance of the first device <NUM>. Similarly, the second device <NUM> can similarly interact with another instance of the second device <NUM>.

For brevity of description in this embodiment of the present invention, the first device <NUM> will be described as a client device and the second device <NUM> will be described as a server device. The embodiment of the present invention is not limited to this selection for the type of devices. The selection is an example of an embodiment of the present invention.

The first device <NUM> can include a first control circuit <NUM>, a first storage circuit <NUM>, a first communication circuit <NUM>, and a first user interface <NUM>, and a first location circuit <NUM>. The first control circuit <NUM> can include a first control interface <NUM>. The first control circuit <NUM> can execute a first software <NUM> o to provide the intelligence of the compute system <NUM>.

The circuits in the first device <NUM> can be the circuits discussed in the vehicle <NUM>. For example, the first control circuit <NUM> can represent the vehicle control circuit <NUM> of <FIG> or vice versa. Also for example, the first storage circuit <NUM> can represent the vehicle storage circuit <NUM> of <FIG> or vice versa. Further, for example, the first communication circuit <NUM> can represent the vehicle communication circuit <NUM> of <FIG> or vice versa.

The first control circuit <NUM> can be implemented in a number of different manners. For example, the first control circuit <NUM> can be a processor, an application specific integrated circuit (ASIC) an embedded processor, a microprocessor, a hardware control logic, a hardware finite state machine (FSM), a digital signal processor (DSP), or a combination thereof. The first control interface <NUM> can be used for communication between the first control circuit <NUM> and other functional units or circuits in the first device <NUM>. The first control interface <NUM> can also be used for communication that is external to the first device <NUM>.

The first control interface <NUM> can receive information from the other functional units/circuits or from external sources, or can transmit information to the other functional units/circuits or to external destinations. The external sources and the external destinations refer to sources and destinations external to the first device <NUM>.

The first control interface <NUM> can be implemented in different ways and can include different implementations depending on which functional units/circuits or external units/circuits are being interfaced with the first control interface <NUM>. For example, the first control interface <NUM> can be implemented with a pressure sensor, an inertial sensor, a microelectromechanical system (MEMS), optical circuitry, waveguides, wireless circuitry, wireline circuitry, or a combination thereof.

The first storage circuit <NUM> can store the first software <NUM>. The first storage circuit <NUM> can also store the relevant information, such as data representing incoming images, data representing previously presented image, sound files, or a combination thereof.

The first storage circuit <NUM> can be a volatile memory, a nonvolatile memory, an internal memory, an external memory, or a combination thereof. For example, the first storage circuit <NUM> can be a nonvolatile storage such as non-volatile random access memory (NVRAM), Flash memory, disk storage, or a volatile storage such as static random access memory (SRAM).

The first storage circuit <NUM> can include a first storage interface <NUM>. The first storage interface <NUM> can be used for communication between the first storage circuit <NUM> and other functional units or circuits in the first device <NUM>. The first storage interface <NUM> can also be used for communication that is external to the first device <NUM>.

The first storage interface <NUM> can receive information from the other functional units/circuits or from external sources, or can transmit information to the other functional units/circuits or to external destinations. The external sources and the external destinations refer to sources and destinations external to the first device <NUM>.

The first storage interface <NUM> can include different implementations depending on which functional units/circuits or external units/circuits are being interfaced with the first storage circuit <NUM>. The first storage interface <NUM> can be implemented with technologies and techniques similar to the implementation of the first control interface <NUM>.

The first communication circuit <NUM> can enable external communication to and from the first device <NUM>. For example, the first communication circuit <NUM> can permit the first device <NUM> to communicate with the second device <NUM> of <FIG>, an attachment, such as a peripheral device or a desktop computer, and the communication path <NUM>.

The first communication circuit <NUM> can also function as a communication hub allowing the first device <NUM> to function as part of the communication path <NUM> and not limited to be an end point or terminal circuit to the communication path <NUM>. The first communication circuit <NUM> can include active and passive components, such as microelectronics or an antenna, for interaction with the communication path <NUM>.

The first communication circuit <NUM> can include a first communication interface <NUM>. The first communication interface <NUM> can be used for communication between the first communication circuit <NUM> and other functional units or circuits in the first device <NUM>. The first communication interface <NUM> can receive information from the other functional units/circuits or can transmit information to the other functional units or circuits.

The first communication interface <NUM> can include different implementations depending on which functional units or circuits are being interfaced with the first communication circuit <NUM>. The first communication interface <NUM> can be implemented with technologies and techniques similar to the implementation of the first control interface <NUM>.

The first user interface <NUM> allows a user (not shown) to interface and interact with the first device <NUM>. The first user interface <NUM> can include an input device and an output device. Examples of the input device of the first user interface <NUM> can include a keypad, a touchpad, soft-keys, a keyboard, a microphone, an infrared sensor for receiving remote signals, or any combination thereof to provide data and communication inputs.

The first user interface <NUM> can include a first display interface <NUM>. The first display interface <NUM> can include an output device. The first display interface <NUM> can include a display, a projector, a video screen, a speaker, or any combination thereof.

The first control circuit <NUM> can operate the first user interface <NUM> to display information generated by the compute system <NUM>. The first control circuit <NUM> can also execute the first software <NUM> for the other functions of the compute system <NUM>, including receiving location information from the first location circuit <NUM>. The first location circuit <NUM> can also be or function as the location-movement sensor <NUM> of <FIG>. The first control circuit <NUM> can further execute the first software <NUM> for interaction with the communication path <NUM> via the first communication circuit <NUM>.

The first location circuit <NUM> can generate location information, current heading, current acceleration, and current speed of the first device <NUM>, as examples. The first location circuit <NUM> can be implemented in many ways. For example, the first location circuit <NUM> can function as at least a part of the global positioning system, an inertial compute system, a cellular-tower location system, a pressure location system, or any combination thereof. Also, for example, the first location circuit <NUM> can utilize components such as an accelerometer or global positioning system (GPS) receiver.

The first location circuit <NUM> can include a first location interface <NUM>. The first location interface <NUM> can be used for communication between the first location circuit <NUM> and other functional units or circuits in the first device <NUM>. The first location interface <NUM> can also be used for communication external to the first device <NUM>.

The first location interface <NUM> can receive information from the other functional units/circuits or from external sources, or can transmit information to the other functional units/circuits or to external destinations. The external sources and the external destinations refer to sources and destinations external to the first device <NUM>.

The first location interface <NUM> can include different implementations depending on which functional units/circuits or external units/circuits are being interfaced with the first location circuit <NUM>. The first location interface <NUM> can be implemented with technologies and techniques similar to the implementation of the first control circuit <NUM>.

The second device <NUM> can be optimized for implementing an embodiment of the present invention in a multiple device embodiment with the first device <NUM>. The second device <NUM> can provide the additional or higher performance processing power compared to the first device <NUM>. The second device <NUM> can include a second control circuit <NUM>, a second communication circuit <NUM>, a second user interface <NUM>, and a second storage circuit <NUM>.

The second user interface <NUM> allows a user (not shown) to interface and interact with the second device <NUM>. The second user interface <NUM> can include an input device and an output device. Examples of the input device of the second user interface <NUM> can include a keypad, a touchpad, soft-keys, a keyboard, a microphone, or any combination thereof to provide data and communication inputs. Examples of the output device of the second user interface <NUM> can include a second display interface <NUM> of <FIG>. The second display interface <NUM> can include a display, a projector, a video screen, a speaker, or any combination thereof.

The second control circuit <NUM> can execute a second software <NUM> of <FIG> to provide the intelligence of the second device <NUM> of the compute system <NUM>. The second software <NUM> can operate in conjunction with the first software <NUM>. The second control circuit <NUM> can provide additional performance compared to the first control circuit <NUM>.

The second control circuit <NUM> can operate the second user interface <NUM> to display information. The second control circuit <NUM> can also execute the second software <NUM> for the other functions of the compute system <NUM>, including operating the second communication circuit <NUM> to communicate with the first device <NUM> over the communication path <NUM>.

The second control circuit <NUM> can be implemented in a number of different manners. For example, the second control circuit <NUM> can be a processor, an embedded processor, a microprocessor, hardware control logic, a hardware finite state machine (FSM), a digital signal processor (DSP), or a combination thereof.

The second control circuit <NUM> can include a second control interface <NUM> of <FIG>. The second control interface <NUM> can be used for communication between the second control circuit <NUM> and other functional units or circuits in the second device <NUM>. The second control interface <NUM> can also be used for communication that is external to the second device <NUM>.

The second control interface <NUM> can receive information from the other functional units/circuits or from external sources, or can transmit information to the other functional units/circuits or to external destinations. The external sources and the external destinations refer to sources and destinations external to the second device <NUM>.

The second control interface <NUM> can be implemented in different ways and can include different implementations depending on which functional units/circuits or external units/circuits are being interfaced with the second control interface <NUM>. For example, the second control interface <NUM> can be implemented with a pressure sensor, an inertial sensor, a microelectromechanical system (MEMS), optical circuitry, waveguides, wireless circuitry, wireline circuitry, or a combination thereof.

The second storage circuit <NUM> can store the second software <NUM>. The second storage circuit <NUM> can also store the information such as data representing incoming images, data representing previously presented image, sound files, or a combination thereof. The second storage circuit <NUM> can be sized to provide the additional storage capacity to supplement the first storage circuit <NUM>.

For illustrative purposes, the second storage circuit <NUM> is shown as a single element, although it is understood that the second storage circuit <NUM> can be a distribution of storage elements. Also for illustrative purposes, the compute system <NUM> is shown with the second storage circuit <NUM> as a single hierarchy storage system, although it is understood that the compute system <NUM> can include the second storage circuit <NUM> in a different configuration. For example, the second storage circuit <NUM> can be formed with different storage technologies forming a memory hierarchal system including different levels of caching, main memory, rotating media, or off-line storage.

The second storage circuit <NUM> can be a volatile memory, a nonvolatile memory, an internal memory, an external memory, or a combination thereof. For example, the second storage circuit <NUM> can be a nonvolatile storage such as non-volatile random access memory (NVRAM), Flash memory, disk storage, or a volatile storage such as static random access memory (SRAM).

The second storage circuit <NUM> can include a second storage interface <NUM>. The second storage interface <NUM> can be used for communication between the second storage circuit <NUM> and other functional units or circuits in the second device <NUM>. The second storage interface <NUM> can also be used for communication that is external to the second device <NUM>.

The second storage interface <NUM> can receive information from the other functional units/circuits or from external sources, or can transmit information to the other functional units/circuits or to external destinations. The external sources and the external destinations refer to sources and destinations external to the second device <NUM>.

The second storage interface <NUM> can include different implementations depending on which functional units/circuits or external units/circuits are being interfaced with the second storage circuit <NUM>. The second storage interface <NUM> can be implemented with technologies and techniques similar to the implementation of the second control interface <NUM>.

The second communication circuit <NUM> can enable external communication to and from the second device <NUM>. For example, the second communication circuit <NUM> can permit the second device <NUM> to communicate with the first device <NUM> over the communication path <NUM>.

The second communication circuit <NUM> can also function as a communication hub allowing the second device <NUM> to function as part of the communication path <NUM> and not limited to be an end point or terminal unit or circuit to the communication path <NUM>. The second communication circuit <NUM> can include active and passive components, such as microelectronics or an antenna, for interaction with the communication path <NUM>.

The second communication circuit <NUM> can include a second communication interface <NUM>. The second communication interface <NUM> can be used for communication between the second communication circuit <NUM> and other functional units or circuits in the second device <NUM>. The second communication interface <NUM> can receive information from the other functional units/circuits or can transmit information to the other functional units or circuits.

The second communication interface <NUM> can include different implementations depending on which functional units or circuits are being interfaced with the second communication circuit <NUM>. The second communication interface <NUM> can be implemented with technologies and techniques similar to the implementation of the second control interface <NUM>.

The first communication circuit <NUM> can couple with the communication path <NUM> to send information to the second device <NUM> in the first device transmission <NUM>. The second device <NUM> can receive information in the second communication circuit <NUM> from the first device transmission <NUM> of the communication path <NUM>.

The second communication circuit <NUM> can couple with the communication path <NUM> to send information to the first device <NUM> in the second device transmission <NUM>. The first device <NUM> can receive information in the first communication circuit <NUM> from the second device transmission <NUM> of the communication path <NUM>. The compute system <NUM> can be executed by the first control circuit <NUM>, the second control circuit <NUM>, or a combination thereof. For illustrative purposes, the second device <NUM> is shown with the partition containing the second user interface <NUM>, the second storage circuit <NUM>, the second control circuit <NUM>, and the second communication circuit <NUM>, although it is understood that the second device <NUM> can include a different partition. For example, the second software <NUM> can be partitioned differently such that some or all of its function can be in the second control circuit <NUM> and the second communication circuit <NUM>. Also, the second device <NUM> can include other functional units or circuits not shown in <FIG> for clarity.

The functional units or circuits in the first device <NUM> can work individually and independently of the other functional units or circuits. The first device <NUM> can work individually and independently from the second device <NUM> and the communication path <NUM>.

The functional units or circuits in the second device <NUM> can work individually and independently of the other functional units or circuits. The second device <NUM> can work individually and independently from the first device <NUM> and the communication path <NUM>.

For illustrative purposes, the compute system <NUM> is described by operation of the first device <NUM> and the second device <NUM>. It is understood that the first device <NUM> and the second device <NUM> can operate any of the modules and functions of the compute system <NUM>.

Referring now to <FIG>, therein is shown a display example of a travel route <NUM>. In this example, the display example shown in <FIG> can represent a display on a fleet manager screen or security monitoring screen of the compute system <NUM> of <FIG>. As a specific example, <FIG> can be rendered on the first display interface <NUM> of <FIG> or on the second display interface <NUM> of <FIG> where the fleet management function or security monitoring function is running on the first device <NUM> of <FIG>, the second device <NUM> of <FIG>, or a combination thereof. For brevity, clarity, and convenience, the example display will be described as being rendered on the first device <NUM> or the second device <NUM> while the vehicle <NUM> of <FIG> is traversing the travel route <NUM> or after traversing the travel route <NUM>.

The compute system <NUM> can monitor the vehicle <NUM> and perform the security functions for the theft alert mechanism without require the driver, owner, or operator of the vehicle <NUM> to actively turn on the security function once the embodiment has been installed. The compute system <NUM> operates based on authorization or lack of authorization for the vehicle <NUM> being monitored.

The first device <NUM> can show a time clock <NUM>, a current location <NUM>, or a combination thereof. The time clock <NUM> provide a demarcation to denote a particular moment. As examples, the time clock <NUM> can be based on a system clock, a time zone, a server clock, a universal clock, a global clock, a global positioning clock, or a combination thereof. The current location <NUM> can represent a geographic location for the vehicle <NUM>.

The compute system <NUM> of <FIG> can further include a navigation session <NUM> for the vehicle <NUM>. The navigation session <NUM> is provides information associated to travel, services, point-of-interest, or a combination thereof. For example, the navigation session <NUM> can include an instance of invoking or utilizing the navigational guidance, map, travel-related features or functionalities of the compute system <NUM>, or a combination thereof. The navigation session <NUM> can be utilized in autonomous driving mode, non-autonomous driving mode, or a combination thereof.

For the security function for the theft alert mechanism of the compute system <NUM>, the navigation session <NUM> is not required to be entered. Continuing this example, the theft alert mechanism of the compute system <NUM> can utilize the navigation session <NUM> for an authorized use of the vehicle <NUM> to help distinguish between authorized and non-authorized use, which will be further described later. The compute system <NUM> can use the navigation session <NUM>, portion of the navigation session <NUM>, or a combination thereof for the theft alert mechanism.

The navigation session <NUM> can include the travel route <NUM>, a travel destination <NUM>, a travel direction <NUM>, a travel purpose <NUM>, a route segment <NUM>, or a combination thereof. The travel route <NUM> can include a series of connected paths for traversing to the travel destination <NUM>. The travel route <NUM> can include one or more travel paths joined by one or more nodes forming a path to the travel destination <NUM>. The travel route <NUM> can include maneuvers corresponding to the nodes to follow or traverse the travel route <NUM>.

The travel route <NUM> can also include a starting location <NUM>, a waypoint <NUM>, or a combination thereof in addition to the travel destination <NUM>. The waypoint <NUM> can represent a stop of the navigation session <NUM> and a location different from and before reaching the travel destination <NUM>. The waypoint <NUM> can also be considered the starting location <NUM>.

For illustrative purposes, the travel route <NUM> is described as included as part of the navigation session <NUM>, although the travel route <NUM> can be independent of the navigation session <NUM>. For example, the navigation session <NUM> can represent an active guidance or commands for autonomous or non-autonomous driving with navigation instructions to traverse the travel route <NUM>. Also for example, the travel route <NUM> can also be for a free-drive mode where there is no predefined instance of the travel destination <NUM>, the waypoint <NUM>, the travel direction <NUM>, or a combination thereof. The travel route <NUM> can be recorded as the vehicle <NUM> traverses a travel path while in free-drive mode. The travel route <NUM> can trace the travel path and past readings of the current location <NUM>. In free-drive mode, the compute system <NUM> can estimated potential instances of the starting location <NUM>, the travel destination <NUM>, the waypoint <NUM>, the travel direction <NUM>, or a combination thereof.

The travel route <NUM> can be from the current location <NUM>, from the starting location <NUM> of the navigation session <NUM>, from an arbitrary location as the starting location <NUM> such as the waypoint <NUM>, or a combination thereof. The starting location <NUM> can be the initial location for the travel route <NUM>. The travel route <NUM> can end at the travel destination <NUM> or include an instance of the travel destination <NUM> as a stop or an intermediate objective, such as the waypoint <NUM>, within the travel route <NUM>. The travel destination <NUM> can be an intended location or an objective of the traveling activity.

The travel direction <NUM> can be information regarding a bearing for a movement or an orientation of the vehicle <NUM>. The travel direction <NUM> can include the bearing or the orientation relative to the travel route <NUM>.

The travel purpose <NUM> can be a representation of a reason, a goal, an activity, an objective, or a combination thereof associated with the navigation session <NUM> or traversing the travel route <NUM>. For example, the travel purpose <NUM> can include medical stops to pick up medical supplies, treatments, or organs for the travel destination <NUM> or the travel route <NUM>. Also for example, the travel purpose <NUM> can include one or more scheduled events or activities at or within a predetermined distance from the travel destination <NUM>.

The route segment <NUM> can be a unit or a grouping of paths within the travel route <NUM>. The route segment <NUM> can include paths with common designations, such as a highway number or a street name. The route segment <NUM> can further be divisions or groupings based on distance or speed, exits or cross streets, number of occupants or travelers, geographical characteristic, such as for region or orientation of the path, path characteristic, such as number of lanes, or traffic regulation, or a combination thereof. The route segment <NUM> can be unique to each ingress or egress for each of the waypoint <NUM>, the starting location <NUM>, the travel destination <NUM>, or a combination thereof.

In this example, <FIG> also depicts a participant identification <NUM>. The participant identification <NUM> can include a name, a screen name, a contact information, such as phone number of email address, a vehicle information, or a combination thereof. The participant identification <NUM> can further include a temporary or an anonymous moniker. As a specific example, the participant identification <NUM> can represent either a person interacting with the compute system <NUM>, a device operating with the compute system <NUM>, the vehicle <NUM> operating with the compute system <NUM>, or a combination thereof. Further to the specific example, the device or the vehicle operating with the compute system <NUM> can be associated with the person interacting with the compute system <NUM>, such as a mobile phone or a vehicle assigned or owned by the person.

The participant identification <NUM> can represent an authorized user <NUM> for the vehicle <NUM>. A vehicle owner can identify additional authorized users by sharing account credentials or adding multiple accounts associated with a fleet of vehicles.

The authorized user <NUM> represents a unique identification associated with an operator. The authorized user <NUM> can be provided an authorization <NUM> for the vehicle <NUM>. The authorized user <NUM> can represent an individual or a group of individuals with account credentials to operate the vehicle <NUM>.

The authorization <NUM> provides operational or interaction privileges for the authorized user <NUM> of the vehicle <NUM>. The authorization <NUM> can be implemented in a number of ways. For example, the authorization <NUM> can include a code to enable operation or interaction with the vehicle <NUM>. Also for example, the authorization <NUM> can be a physical device in addition to or separate from a non-physical device to enable operation or interaction with the vehicle <NUM>. Further for example, the authorization <NUM> can be by association with the authorized user <NUM>, such as the first device <NUM> as a cellular or smartphone. The authorization <NUM> can also include a number of items or combination of items such as those iterated as well as others.

Returning to the travel route <NUM> and for example, the compute system <NUM> can be identify or assign a trip identification <NUM> for the particular instance of the travel route <NUM>. The trip identification <NUM> can represent a unique instance, invocation, or traversal of the travel route <NUM>. The trip identification <NUM> can be different and unique for each and different traversal of the travel route <NUM>.

As a specific example, each instance of the route segment <NUM> can be designated with a trip identification <NUM>. The trip identification <NUM> can represent a label for the travel route <NUM> or a portion of the travel route <NUM>, such as the route segment <NUM>. The travel route <NUM> can be labeled with a number of different values or labels for the trip identification <NUM>. In other words, the travel route <NUM> can be labeled with a number of different labels or values of the trip identification <NUM>.

A recurrence <NUM> represents repeated traversal or stop within the travel route <NUM>. The recurrence <NUM> can be a portion of the travel route <NUM>, as shown as an example as a dashed portion of the travel route <NUM> in <FIG>. The recurrence <NUM> can also apply repeated presence at or a repeated traversal for the starting location <NUM>, the travel destination <NUM>, the waypoint <NUM>, the navigation session <NUM>, the route segment <NUM>, or a combination thereof. The recurrence <NUM> can be delineated or uniquely identified with the additional information with the participant identification <NUM>. The recurrence <NUM> can be further unique per the trip identification <NUM>.

Further, regarding the travel route <NUM>, each traversal to the waypoint <NUM> can be considered a portion of the travel route <NUM>, a portion of the navigation session <NUM>, or a combination thereof. The waypoint <NUM> can represent an intermediate destination or the travel destination <NUM> if the navigation session <NUM> terminates at the waypoint <NUM>.

Referring now to <FIG>, therein is shown an example of a graphical depiction of an operation of a theft risk model <NUM> by the compute system <NUM> of <FIG>. The theft risk model <NUM> can include a representation for each of the authorized user <NUM>, the vehicle <NUM>, or a combination thereof as well as other type of factors <NUM> described later.

The example shown in <FIG> depicts the factors <NUM> utilized by the theft risk model <NUM>. <FIG> depicts three axis, each represent one of the factors <NUM> or can be a combination of a selected types of the factors <NUM>. <FIG> is shown for clarity and brevity depicting the three axes, although it is understood that the depiction can include more number of axes for the number of the factors <NUM> or can be represented differently.

The theft risk model <NUM> processes the factors <NUM> to determine what is consider a normal utilization <NUM> for the authorized user <NUM>, the vehicle <NUM>, or a combination thereof. The normal utilization <NUM> can be broken down and separate for the authorized user <NUM> and the vehicle <NUM> or can be combined, as described further in <FIG>. For simplicity and brevity, the example shown if <FIG> as a volume labeled "USER", although it is understood that the labeling is for clarity and can also apply for the vehicle <NUM> and not only for the authorized user <NUM>.

The example shown in <FIG> also depicts another volume to represent an outlier <NUM> to the normal utilization <NUM>. The outlier <NUM> represents deviations for the vehicle <NUM>, the authorized user <NUM>, or a combination thereof.

The example shown in <FIG> also depicts another volume to represent an aggregation <NUM> to the utilization of the vehicle <NUM> or related to the vehicle <NUM>. The aggregation <NUM> provides information relating to the factors <NUM> relating to more than one of the authorized user <NUM>, operators who are not the authorized user <NUM>, or a combination thereof for the theft risk model <NUM>. The theft risk model <NUM> can determine or contribute to the determination for the outlier <NUM>, the normal utilization <NUM>, or a combination thereof based on the aggregation <NUM>. In this example, the theft risk model <NUM> can analyze the factors <NUM> and can determine the outlier <NUM> is not enough of a deviation beyond the normal utilization <NUM> or to not notify the owner of the vehicle <NUM> of a theft.

The example shown in <FIG> also depicts a number of overlaps of at least two of the volumes of the normal utilization <NUM>, the outlier <NUM>, and the aggregation <NUM>. Continuing this example, the theft risk model <NUM> can analyze the factors <NUM> and can determine the overlapped volumes of the normal utilization <NUM> and the aggregation <NUM> is not a deviation beyond the normal utilization <NUM> or not to notify the owner of the vehicle <NUM> of a theft, labeled in <FIG> with "TH". Also continuing this example, the theft risk model <NUM> can analyze the factors <NUM> and can determine the overlapped volumes of the outlier <NUM> and the aggregation <NUM> is not enough of a deviation beyond the normal utilization <NUM> or not to notify the owner of the vehicle <NUM> of a theft. Further continuing this example, the theft risk model <NUM> can analyze the factors <NUM> and can determine the overlapped volumes of the outlier <NUM>, the aggregation <NUM>, and the normal utilization <NUM> is enough of a deviation beyond the normal utilization <NUM> or to notify the owner of the vehicle <NUM> of a theft.

Referring now to <FIG>, therein is shown a control flow of the compute system <NUM>. The control flow in <FIG> depicts and describes an example of the theft alert mechanism by the compute system <NUM>.

The compute system <NUM> can include the following modules: an installation module <NUM>, a training module <NUM>, a monitor module <NUM>, an alert module <NUM>, or a combination thereof. The aforementioned modules can be included in the first software <NUM> of <FIG>, the second software <NUM> of <FIG>, or a combination thereof. The first software <NUM>, the second software <NUM>, or a combination thereof can be executed with the first control circuit <NUM> of <FIG>, the second control circuit <NUM> of <FIG>, the vehicle control circuit <NUM> of <FIG>, or a combination thereof.

In the example shown in <FIG>, the installation module <NUM> can be coupled to the training module <NUM>. The training module <NUM> can be coupled to the monitor module <NUM>. The monitor module <NUM> can be coupled to the alert module <NUM>.

The modules can be coupled using wired or wireless connections, by including an output of one module as an input of the other module, by including operations of one module influence operation of the other module, or a combination thereof. The modules can be directly coupled with no intervening structures or objects other than the connector there-between, or indirectly coupled. The modules can be coupled as function calls or procedural calls within the first software <NUM>, the second software <NUM>, or a combination thereof.

The installation module <NUM> ensure the various components of the compute system <NUM> is in place and connected for the operation of the theft alert mechanism. The installation module <NUM> receives a list of the authorized user <NUM> of <FIG>, the vehicle <NUM> of <FIG>, the authorized user <NUM> of <FIG> for the vehicle <NUM>, or a combination thereof to be processed by the compute system <NUM>.

As an example, a vehicle owner can identify additional authorized users by sharing account credentials or adding multiple accounts associated with a fleet of vehicles. The theft risk model <NUM> of <FIG> can include a representation for each of the authorized user <NUM>, the vehicle <NUM>, or a combination thereof.

The theft risk model <NUM> operates on an entry associated with the authorized user <NUM> of the vehicle <NUM>, each instance of the vehicle <NUM>, or a combination thereof. The theft risk model <NUM> determines or is part of making the determination of a probability <NUM> that an operator of the vehicle <NUM> is one of the authorized user <NUM> for the instance of the vehicle <NUM>. The theft risk model <NUM> also determines or is part of making the determination of the probability <NUM> that an operator of the vehicle <NUM> is not one of the authorized user <NUM> for the instance of the vehicle <NUM>.

As an example, the theft risk model <NUM> can be an artificial intelligence model. The artificial intelligence model can be implemented in a number of ways. For example, the artificial intelligence model be implemented with machine learning, deep learning, or a combination thereof. Examples of machine learning include supervised learning, unsupervised learning, semi-supervised learning, or a combination thereof. As a specific example, the machine learning can be a classifier to determine if the received input is within normal usage of the by the authorized user <NUM>, the vehicle <NUM>, or a combination thereof. Examples of deep learning can include long short-term memory (LSTM) learning, recurrent neural network (RNN), as well as other neural network architectures, or a combination thereof.

The probability <NUM> represents the likelihood that that operator is one of the authorized user <NUM> or not. The probability <NUM> can be calculated in based on the learning mechanism for the artificial intelligence model. For example, if the artificial intelligence model is implemented as a classifier then the probability <NUM> can be based on a threshold to output within normal or not normal usage. Also for example, if the artificial intelligence model is implemented as a neural network, then output can be based on the cost function for the neural network learning mechanism.

The theft risk model <NUM> determines the output based on the factors <NUM> of <FIG> for the artificial intelligence model. The factors <NUM> can include a user normal usage <NUM>, a vehicle normal usage <NUM>, a concurrent normal usage <NUM>, or a combination thereof. The factors <NUM> can also include a priority event <NUM>, a schedule <NUM>, a caution <NUM>, the aggregation <NUM>, or a combination thereof.

The user normal usage <NUM> is a past pattern or instances for the authorized user <NUM>. For example, the user normal usage <NUM> can be associated with the vehicle <NUM>, the first device <NUM>, or a combination thereof.

As specific examples, the user normal usage <NUM> can include a driver signature for the authorized user <NUM>. For example, the driver signature can be determined by the vehicle-related sensor reading <NUM> of <FIG> for patterns typical from accelerometer from the vehicle <NUM>, the first device <NUM>, or a combination thereof. Also for example, the driver signature can also include the vehicle-related sensor reading <NUM> for braking, acceleration, and cornering with the vehicle <NUM> or associated with the pattern for the authorized user <NUM> of any instance of the vehicle <NUM>.

The vehicle normal usage <NUM> is a past pattern or instances for the vehicle <NUM>. For example, the vehicle normal usage <NUM> can relate to past routes, stops, timeframe, or a combination thereof associated with the vehicle <NUM>.

As a specific examples, the vehicle normal usage <NUM> can determined by past patterns of the travel route <NUM> of <FIG>, the starting location <NUM> of <FIG>, the travel destination <NUM> of <FIG>, the waypoint <NUM> of <FIG>, or a combination thereof for the vehicle <NUM>. Continuing the example, the vehicle normal usage <NUM> can also include the time clock <NUM> of <FIG> in association with the travel route <NUM> and portions of the travel route <NUM>.

The concurrent normal usage <NUM> is the past pattern or instances where the user normal usage <NUM> and the vehicle normal usage <NUM> coincides. For example, the concurrent normal usage <NUM> can relate the nonvehicle reading <NUM> of <FIG> regarding the first device <NUM> associated with the authorized user <NUM> that concurrently coincides with the vehicle-related sensor reading <NUM> associated with the vehicle <NUM>. As specific example, the authorized user <NUM> of the vehicle <NUM> can drive to work, which is a typical route and time to be within the vehicle normal usage <NUM>. Continuing with this specific example, the first device <NUM> associated with the authorized user <NUM> can provide the nonvehicle reading <NUM> of <FIG> for geographic location that indicates a typical geographic location at a given time, which is the same as the route and time for the vehicle normal usage <NUM>, to be the user normal usage <NUM>. Also as a specific example, the first device <NUM> can connect to the communication or entertainment system in the vehicle <NUM> at times and days that are typical, such as weekday mornings while traveling to work. In such an example, the vehicle-related sensor reading <NUM> from the vehicle <NUM> and the first device <NUM> indicates both the user normal usage <NUM> and the vehicle normal usage <NUM> resulting in the concurrent normal usage <NUM>.

Further for example, the interaction between the authorized user <NUM> and the vehicle <NUM> can also represent the user normal usage <NUM> and the vehicle normal usage <NUM> resulting in the concurrent normal usage <NUM>. As a specific example, the vehicle-related sensor reading <NUM> can detect the interaction with the authorized user <NUM>, such as voice command or voice patterns, from the volume sensor <NUM> of <FIG> to determine if such an interaction falls within the user normal usage <NUM>, the vehicle normal usage <NUM>, the concurrent normal usage <NUM>, or a combination thereof. Also as a specific example, the vehicle-related sensor reading <NUM> can detect the interaction with the first device <NUM> associate with the authorized user <NUM> with the vehicle <NUM>, such as a communication link for music, message, playlist, to determine if such an interaction falls within the user normal usage <NUM>, the vehicle normal usage <NUM>, the concurrent normal usage <NUM>, or a combination thereof.

The priority event <NUM> indicates potentially impactful triggers or occurrence indicative of an unwanted disturbance or theft related to the vehicle <NUM>. As an example, the priority event <NUM> can include the vehicle-related sensor reading <NUM> from the vehicle sensors <NUM> of <FIG> within the vehicle <NUM> for a glass breakage to a window of the vehicle <NUM>. Also for example, the priority event <NUM> can include multiple triggers including the vehicle-related sensor reading <NUM> for a glass breakage following by an ignition start for the vehicle <NUM>. The priority event <NUM> can be based on the vehicle-related sensor reading <NUM> for a single event or based on for concurrent or sequential multiple events. Further for example, the priority event <NUM> can include disconnection or unplugging of select devices within the vehicle <NUM>. As a specific example, the select devices can include car alarm devices, the first location circuit <NUM> of <FIG>, a device or dongle provide the on-board diagnostics <NUM> of <FIG>, or a combination thereof.

The schedule <NUM> provides information about expected events, locations, routes, information, or a combination thereof related to the authorized user <NUM>, the vehicle <NUM>, or a combination thereof. The schedule <NUM> can be associated based on time or activities that are upcoming in the future, past, or a combination thereof.

For example, the schedule <NUM> can be based on a calendar for the authorized user <NUM>. Also for example, the schedule <NUM> can be based on a rental schedule or a fleet schedule for the vehicle <NUM>. Further for example, the schedule <NUM> can include information overlapping occurrence for the authorized user <NUM> and the vehicle <NUM>. The overlapping occurrence can be the same type of information, such as time and location of pickup of a rental car, or can be related information, such as the vehicle <NUM> takes the travel route <NUM> passing or stopping at the waypoint <NUM> that is noted as a meeting location on the calendar for the authorized user <NUM>.

The caution <NUM> provides information related to known or potential risk to the authorized user <NUM>, the vehicle <NUM>, or a combination thereof. As an example, the travel route <NUM> that shows the vehicle <NUM> near a high crime rate for car theft or auto shops for stolen cars and not within the user normal usage <NUM>, the vehicle normal usage <NUM>, the concurrent normal usage <NUM>, the schedule <NUM>, or a combination thereof, then the probability <NUM> is much higher that the driver of the vehicle <NUM> is not the authorized user <NUM>. The operation of the artificial intelligence model can generate information for the caution <NUM> based on the probability <NUM> and the factors <NUM> contributing the generation of the probability <NUM>.

The aggregation <NUM> provides information relating to the factors <NUM> relating to more than one of the authorized user <NUM>, operators who are not the authorized user <NUM>, or a combination thereof for the artificial intelligence model to determine the probability <NUM>. The aggregation <NUM> can provide information that would be the factors <NUM> but not limited to those that are the authorized user <NUM>. For example, the aggregation <NUM> can provide the travel route <NUM> driven to go to the waypoint <NUM>, such as a mall or airport, even if choices for the travel route <NUM> are not within the user normal usage <NUM>, the vehicle normal usage <NUM>, the concurrent normal usage <NUM>, or a combination thereof. As a specific example, the aggregation <NUM> can include cross user big data patterns of reasonable routes as the travel route <NUM> to take, such as going to the airport or the mall. The artificial intelligence model can remove situations where the authorized user <NUM>, the vehicle <NUM>, or a combination thereof travels to the waypoint <NUM> that is a normal location but the travel to the waypoint <NUM> is the first time over a holiday. The artificial intelligence model can utilize the aggregation <NUM> concurrently with the other types of the factors <NUM> or sequentially or intermixed.

The theft risk model <NUM> can utilize the factors <NUM> simultaneously, sequentially, weighted equally or non-equally, or a combination thereof in a static configuration or in a changing or dynamic configuration. The artificial intelligence model can utilize the factors <NUM> as features or inputs and the factors <NUM> utilization can be based on the learning mechanism utilized. For example, the weighting for the factors <NUM> can be non-equally weighted depending on the training and can depend on each of the authorized user <NUM>. The factors <NUM> can also be dynamically changing or adjusting if the artificial intelligence model utilizes some form of reinforcement learning to improve the accuracy of the probability <NUM> output as new inputs are available.

For example, the theft risk model <NUM> can utilize the priority event <NUM> only to determine the probability <NUM> whether or not the operation of the vehicle <NUM> is by the authorized user <NUM>. Also for example, the theft risk model <NUM> can utilize the priority event <NUM> in conjunction with the user normal usage <NUM>, the vehicle normal usage <NUM>, the concurrent normal usage <NUM>, the schedule <NUM>, the caution <NUM>, or a combination thereof to determine the probability <NUM>. Further for example, the theft risk model <NUM> can utilize the user normal usage <NUM>, the vehicle normal usage <NUM>, the concurrent normal usage <NUM>, or a combination thereof without the priority event <NUM> to determine the probability <NUM>.

Returning to the overall description of the installation module <NUM>, the compute system <NUM> can also ensure the vehicle sensors <NUM> for the vehicle <NUM> are connection access to the communication path <NUM> of <FIG>. The compute system <NUM> enable a real-time <NUM> communication of the vehicle-related sensor reading <NUM> from the vehicle sensors <NUM> embedded in the vehicle <NUM> and processing by the theft risk model <NUM>.

The real-time <NUM> communication refers to the transmission of the vehicle-related sensor reading <NUM> as generated by the vehicle sensors <NUM> with the purpose to store as needed for transmission for processing by the theft risk model <NUM>. The real-time <NUM> communication refers to transmission of the vehicle-related sensor reading <NUM> as generated by the vehicle sensors <NUM> without the purpose to store and hold for later transmission for later processing.

The real-time <NUM> processing by the artificial intelligence model of the theft risk model <NUM> inputs the vehicle-related sensor reading <NUM> from the vehicle sensors <NUM> and processes the input as received. The inputs are not stored to start processing at a later time by the artificial intelligence model.

As an example, the artificial intelligence model of the theft risk model <NUM> utilizes the vehicle-related sensor reading <NUM> sent in the real-time <NUM> from the vehicle sensors <NUM> as inputs simultaneously, sequentially, or intermixed. Continuing with this example, the theft risk model <NUM> monitors the vehicle-related sensor reading <NUM> received in the real-time <NUM> from the vehicle <NUM> or from the vehicle sensors <NUM> built into the vehicle <NUM>. As specific examples, the vehicle sensors <NUM> can provide as the vehicle-related sensor reading <NUM> the accelerometer data, ignition status as on or off, GPS location data, disturbance of the vehicle <NUM> in a short period, glass break detection, removal of the dongle for the on-board diagnostics <NUM> of <FIG>, and driver behavior data.

The flow can progress from the installation module <NUM> to the training module <NUM>.

The training module <NUM> performs the training of the theft risk model <NUM> including the artificial intelligence model based on the factors <NUM> as part of the features.

The features for training the artificial intelligence model can be based on the user normal usage <NUM>, the vehicle normal usage <NUM>, the concurrent normal usage <NUM>, the priority event <NUM>, the schedule <NUM>, the caution <NUM>, or a combination thereof. A non-priority event <NUM> represent the level of urgency based on the vehicle-related sensor reading <NUM> not rising to the level of the priority event <NUM>. For example the non-priority event <NUM> can be based on a deviation from the user normal usage <NUM>, the vehicle normal usage <NUM>, the concurrent normal usage <NUM>, the priority event <NUM>, the schedule <NUM>, or a combination thereof. The caution <NUM> can be included in the non-priority event <NUM> or the priority event <NUM> depending on the other types of the factors <NUM>.

The features for training can also be based on specific instance of the vehicle <NUM>, the authorized user <NUM>, or a combination thereof. The features can also include a combination of the examples as described earlier.

The features for training can also be based on the non-priority event <NUM>, the priority event <NUM>, or a combination thereof. For examples, the features can be based on not being within the user normal usage <NUM>, the vehicle normal usage <NUM>, the concurrent normal usage <NUM>, the schedule <NUM>, or a combination thereof. Also for example, the features can be based on the caution <NUM>. Continuing with this example, the features for training can also be based on specific instance of the vehicle <NUM>, the authorized user <NUM>, or a combination thereof. The features can also include a combination of the examples as described earlier.

As an example, the theft risk model <NUM> can be trained with various sequences of the factors <NUM>, including events, to learn to recognize the outlier <NUM>, a theft level indicator <NUM>, or a combination thereof in the series of the factors <NUM> as the features.

The outlier <NUM> represents deviations for the vehicle <NUM>, the authorized user <NUM>, or a combination thereof. As examples, the outlier <NUM> can be based on the non-priority event <NUM>, the priority event <NUM>, or a combination thereof.

The theft level indicator <NUM> represents an indication of the vehicle <NUM> being stolen or has been stolen. For example, the theft level indicator <NUM> can be based on the outlier <NUM>, the non-priority event <NUM>, the priority event <NUM>, or a combination thereof.

Depending on the probability <NUM> indicating an instance of the outlier <NUM>, the compute system <NUM> can determine the theft level indicator <NUM> based on the outlier <NUM>. For example, the outlier <NUM>, the theft level indicator <NUM>, or a combination thereof can trigger a signal an operator of the vehicle <NUM> as possible new user or a user that is not one of the authorized user <NUM> through to a theft alert <NUM>, such as a stolen vehicle warning.

If the theft risk model <NUM> determines the probability <NUM> as the outlier <NUM>, such as a trained or learned threshold, or the theft level indicator <NUM>, the compute system <NUM> can notify the owner of the vehicle <NUM> with the theft alert <NUM>. The theft alert <NUM>, such as a mobile app notification, a text message, a phone call, can sent and displayed on the first device <NUM>. Optionally, the compute system <NUM> can send the theft alert <NUM> to others, such as a security or police services.

The training module <NUM> can train the theft risk model <NUM> for each of the authorized user <NUM> in a number of ways. For example, the compute system <NUM> can store the patterns for the authorized user <NUM>, for the vehicle <NUM>, or a combination thereof. Continuing this example, the compute system <NUM> can record the time, the waypoint <NUM>, the travel route <NUM>, and other items for the authorized user <NUM>. The theft risk model <NUM> can also record adherence to or deviations to the schedule <NUM> for the authorized user <NUM>. The theft risk model <NUM> can store proximity, if any, to geographic locations or activities associated with the caution <NUM>. The theft risk model <NUM> can be stored as an anonymized model of likely usage by the authorized user <NUM>.

As a specific example, the compute system <NUM> can operate the theft risk model <NUM> for a new user as one the authorized user <NUM>. The training module <NUM> can undergo a training or learning period, T, for the theft risk model <NUM>. Continuing the example, the new member as the authorized user <NUM> undergo the installation process, such as with the installation module <NUM>. The compute system <NUM> monitors the authorized user <NUM> operates or interacts with the instances or types of the vehicle <NUM> and how. The compute system <NUM>, the training module <NUM>, or a combination thereof can develop a profile for the authorized user <NUM>, both for new as well as for existing. The profile can include information for the factors <NUM>, such as time, location, routes, driving styles or driver signature.

Continuing with the specific example for a new or existing person as the authorized user <NUM>, the compute system <NUM> can record or monitor the authorized user <NUM> in a number of ways. As an example, the compute system <NUM> can perform the monitor and record function with the vehicle sensors <NUM> in the vehicle <NUM>, the first device <NUM> as a smart phone with the authorized user <NUM>, or a combination thereof. The monitoring, recording, and developing the profiles is used to help build the theft risk model <NUM>. Optionally, the theft risk model <NUM> can be collect and anonymize the monitored and recorded information for the factors <NUM>. The theft risk model <NUM> can represent a model for the authorized user <NUM> as an individual or for a collection of individuals.

The flow can progress from the training module <NUM> to the monitor module <NUM>.

The compute system <NUM> operate without the need to turn on or activate the theft alert mechanism. As long as communication between the vehicle <NUM> and the compute system <NUM> is available, the theft alert mechanism is operating and the theft risk model <NUM> is operating. As the compute system <NUM> operates, the monitor module <NUM> determines if the operator of one of the vehicle <NUM> monitored by the theft risk model <NUM> is one person to be the authorized user <NUM> to determine if the owner of the vehicle or others need to be notified.

The monitor module <NUM> can determine the operator in a number of ways. For example, the monitor module <NUM> can operation the theft risk model <NUM> as well as monitor the priority event <NUM> in the real-time <NUM>. As an example, the priority event <NUM> alone can cause the monitor module <NUM>, the theft risk model <NUM>, or a combination thereof issue the theft alert <NUM> to the owner of the vehicle with the alert module <NUM>. Also as an example, the monitor module <NUM>, the theft risk model <NUM>, or a combination thereof can utilize the priority event <NUM> along with other type of the factors <NUM> to determine whether the theft alert <NUM> should be sent. As described earlier, the theft alert <NUM> can be generated with the priority event <NUM> analyzed concurrently with the other type of the factors <NUM>, sequentially, intermixed, or a combination thereof.

The monitor module <NUM> can utilized the factors <NUM> from the vehicle-related sensor reading <NUM> of the vehicle sensors <NUM> embedded within the vehicle <NUM>, the first device <NUM> associated with the authorized user <NUM>, or a combination thereof. The authorized user <NUM> can be the driver of the vehicle <NUM> or a passenger of the vehicle <NUM> and monitors by the first device <NUM>.

As the vehicle <NUM> start moving, the operation module, the theft risk model <NUM>, or a combination thereof can operate as embedded as part of the vehicle <NUM>, the first device <NUM>, or a combination thereof to monitor and record data.

The theft risk model <NUM> receives the real-time <NUM> reading from the vehicle <NUM>, the first device <NUM>, or a combination thereof to determine the probability <NUM> that the operator of the vehicle <NUM> determined to be the authorized user <NUM> or a passenger in the vehicle <NUM> is the authorized user <NUM>. The theft risk model <NUM> determines the probability <NUM> for the operation of the vehicle <NUM> as within the factors <NUM> such as the user normal usage <NUM>, the vehicle normal usage <NUM>, the concurrent normal usage <NUM>, or combination thereof. The theft risk model <NUM> can also determine the probability <NUM> as being with the schedule <NUM> for the vehicle <NUM>, the authorized user <NUM>, or a combination thereof. The theft risk model 502can further determine the probability <NUM> including the caution <NUM>.

The theft risk model <NUM> performs the real-time <NUM> processing of the vehicle-related sensor reading <NUM>, the nonvehicle reading <NUM>, or a combination thereof received in the real-time <NUM> relating to the factors <NUM>. The theft risk model <NUM> can detect the outlier <NUM>, the theft level indicator <NUM>, or a combination thereof in the real-time <NUM>.

As an example, the outlier <NUM> or the theft level indicator <NUM> can be based on the priority event <NUM>, such as a glass break of the vehicle <NUM>. The outlier <NUM> of this type can represent the priority event <NUM> for the theft level indicator <NUM> and the theft alert <NUM> can be generated and issued with the alert module <NUM>. If the outlier <NUM> is not determined to be one as the priority event <NUM>, the theft risk model <NUM> still monitors the other types of the factors <NUM> as the non-priority event <NUM> to calculate the probability <NUM> and to detect the outlier <NUM>.

Also as an example, the theft risk model <NUM> can detect a change in the behavior or pattern for the authorized user <NUM>, the vehicle <NUM>, or a combination thereof. As a specific example, the theft risk model <NUM> can determine that the probability <NUM> is within the user normal usage <NUM>, the vehicle normal usage <NUM>, the concurrent normal usage <NUM>, within the schedule <NUM>, or a combination thereof for a portion of the travel route <NUM>.

As a further example, as the theft risk model <NUM> continues to monitor the vehicle <NUM> along the travel route <NUM> or over time, the vehicle <NUM> can change course to the point of the probability <NUM> determined to be the outlier <NUM> but not necessarily as the theft level indicator <NUM>. Continuing the example, the theft risk model <NUM> can determine a situation of a car theft after the vehicle-related sensor reading <NUM> includes the priority event <NUM> of glass breakage followed by a deviation from the travel route <NUM> outside the user normal usage <NUM>, the vehicle normal usage <NUM>, not within the schedule <NUM> or a combination thereof. The change and detection for the outlier <NUM> can be determined to be the theft level indicator <NUM> and can trigger the theft alert <NUM> with the alert module <NUM>.

Further for example, as the theft risk model <NUM> monitors the vehicle <NUM>, the authorized user <NUM>, or a combination thereof and does not receive the priority event <NUM> but lesser deviations for the other types of the factors <NUM>, the outlier <NUM> can be detected but the probability <NUM> can be a value such that the outlier <NUM> is not large deviation and would not necessarily be determined to be the theft level indicator <NUM>. In other words, the outlier <NUM> is not too far off or for too long from the vehicle normal usage <NUM>, the user normal usage <NUM>, the schedule <NUM>, or a combination thereof. Throughout the operation of the theft risk model <NUM>, there can be a number of different instances of the outlier <NUM> or multiple detection of the same type of the outlier <NUM> for different days and the probability <NUM> is below a threshold such that the monitor module <NUM> does not determine the outlier <NUM> to be the theft level indicator <NUM> and does not generate the theft alert <NUM>.

Yet further for example, the monitor module <NUM> can generate the theft alert <NUM> without the theft risk model <NUM> detecting the outlier <NUM>. Continuing the example, some of the factors <NUM> that are not considered with the priority event <NUM> can quickly elevated to the priority event <NUM> even if still with the user normal usage <NUM>, the vehicle normal usage <NUM>, the concurrent normal usage <NUM>, the schedule <NUM>, or a combination thereof.

As a specific example, the theft risk model <NUM> can monitor the authorized user <NUM> within the vehicle normal usage <NUM>, the concurrent normal usage <NUM>, the schedule <NUM>, or a combination thereof but suddenly starts traveling at dangerously high speeds. The theft risk model <NUM> processes the vehicle-related sensor reading <NUM>, the nonvehicle reading <NUM>, or a combination thereof for the sudden increase in the speed and elevates to the level of the priority event <NUM> for the monitor module <NUM> to determine the theft level indicator <NUM> and to generate the theft alert <NUM> with the alert module <NUM>. This is an example of the overlap labeled as "TH" in <FIG>.

Also as a specific example, the theft risk model <NUM> has learned and been trained that one person as the authorized user <NUM> rarely driver the vehicle <NUM> after midnight. Continuing this example, the theft risk model <NUM> one day monitors the vehicle <NUM> to receive the vehicle-related sensor reading <NUM> from the vehicle sensors <NUM> in the vehicle <NUM> indicating a bump at <NUM>:<NUM> am, followed by an ignition on, and the driver behavior does not match the driver signature of the authorized user <NUM> or another other person as the authorized user <NUM> for the vehicle <NUM>. In this example, the theft risk model <NUM> can determine the probability <NUM> such that there is a high likelihood that the car is being stolen.

The monitor module <NUM> can also return or loop back to the training module <NUM> for reinforcement learning to improve the accuracy of the theft risk model <NUM>. The reinforcement learning can be utilized to improve the accuracy for new users, as seasonal changes can change the normal utilization <NUM>, as the aggregation <NUM> can also change, the handling of the priority event <NUM> or the non-priority event <NUM>, or a combination thereof.

The alert module <NUM> provides the notification for the theft alert <NUM>. As an example, the notification can be to the owner of the vehicle <NUM>, law enforcement, security service, any number of the authorized user <NUM>, or a combination thereof.

It has been discovered that the compute system <NUM> improves the accuracy and performance without the need for active turn-on or activation after installation for providing the theft alert <NUM> by receiving the vehicle-related sensor reading <NUM>, nonvehicle reading <NUM>, or a combination thereof in the real-time <NUM> for the priority event <NUM>, the non-priority event <NUM>, or a combination thereof. An additional the effectiveness and the usefulness for action to be taken is provided by the compute system <NUM> by processing the vehicle-related sensor reading <NUM>, nonvehicle reading <NUM>, or a combination thereof in the real-time <NUM> to generate the theft alert <NUM> to be actionable, such as stop the operation of the vehicle <NUM>, sound alarm at the vehicle <NUM>, even auto-drive the vehicle <NUM> to a safe stop, or a combination thereof.

It has also been discovered that the compute system <NUM> improves the accuracy and performance without the need for active turn-on or activation after installation for providing the theft alert <NUM> based on the normal utilization <NUM> including the user normal usage <NUM>, the vehicle normal usage <NUM>, the concurrent normal usage <NUM>, or a combination thereof. The compute system <NUM> improves accuracy by utilization the schedule <NUM> and the aggregation <NUM> of other drivers to help filter to false trigger of the theft alert <NUM>.

It has further been discovered that the compute system <NUM> improves the accuracy and performance without the need for active turn-on or activation after installation for providing the theft alert <NUM> based on the elevation of the non-priority event <NUM> to the priority event <NUM> based on sudden deviation. The elevation provides an improved response time to generate the theft alert <NUM>.

The modules described in this application can be hardware implementation or hardware accelerators, including passive circuitry, active circuitry, or both, in the first storage circuit <NUM>, the second storage circuit <NUM>, the first control circuit <NUM>, the second control circuit <NUM>, or a combination thereof. The modules can also be hardware implementation or hardware accelerators, including passive circuitry, active circuitry, or both, within the first device <NUM>, the second device <NUM>, or a combination thereof but outside of the first storage circuit <NUM>, the second storage circuit <NUM>, the first control circuit <NUM>, the second control circuit <NUM>, or a combination thereof.

The compute system <NUM> has been described with module functions or order as an example. The compute system <NUM> can partition the modules differently or order the modules differently. For example, the loops can be different or be eliminated. Also for example, the training module <NUM> can be eliminated with the use of the aggregation <NUM>, unsupervised learning, transfer learning from other drivers in the area or the class of the vehicle <NUM>, or a combination thereof.

For illustrative purposes, the various modules have been described as being specific to the first device <NUM>, the second device <NUM>, the vehicle <NUM>, or a combination thereof. However, it is understood that the modules can be distributed differently. For example, the various modules can be implemented in a different device, or the functionalities of the modules can be distributed across multiple devices. Also as an example, the various modules can be stored in a non-transitory memory medium.

As a more specific example, one or more modules described above can be stored in the non-transitory memory medium for distribution to a different system, a different device, a different user, or a combination thereof, for manufacturing, or a combination thereof. Also as a more specific example, the modules described above can be implemented or stored using a single hardware unit or circuit, such as a chip or a processor, or across multiple hardware units or circuits.

The modules described in this application can be stored in the non-transitory computer readable medium. The first storage circuit <NUM>, the second storage circuit <NUM>, or a combination thereof can represent the non-transitory computer readable medium. The first storage circuit <NUM>, the second storage circuit <NUM>, the vehicle storage circuit <NUM>, or a combination thereof, or a portion therein can be removable from the first device <NUM>, the second device <NUM>, the vehicle <NUM>. Examples of the non-transitory computer readable medium can be a non-volatile memory card or stick, an external hard disk drive, a tape cassette, or an optical disk.

The physical transformation of the function of the theft risk model <NUM> to generate the theft alert <NUM> based on the normal utilization <NUM>, the vehicle-related sensor reading <NUM>, the nonvehicle reading <NUM>, the priority event <NUM>, the non-priority event <NUM>, the schedule <NUM>, the caution <NUM>, the outlier <NUM>, the aggregation <NUM>, the theft level indicator <NUM>, or a combination thereof leads action in the real world. Examples of real world actions or impacts include stop the operation of the vehicle <NUM>, sound alarm at the vehicle <NUM>, even auto-drive the vehicle <NUM> to a safe stop, or a combination thereof. In turn, the real-world interactions with the compute system <NUM> provides a more improved accuracy with the normal utilization <NUM>, the outlier <NUM>, the aggregation <NUM>, or a combination thereof with or without reinforcement learning.

Referring now to <FIG>, therein is shown a flow chart of a method <NUM> of operation of a compute system <NUM> in an embodiment of the present invention. The method <NUM> includes: receiving a vehicle-related sensor reading in a real-time in a box <NUM>; determining in the real-time a theft level indicator for a vehicle based on the vehicle-related sensor reading in a box <NUM>; generating a theft alert based on the theft level indicator being a priority event in a box <NUM>; analyzing the vehicle-related sensor reading with a theft risk model to generate the theft alert when the theft level indicator is a non-priority event in a box <NUM>; and communicating the theft alert for displaying on a device in a box <NUM>.

As an example, the method <NUM> further includes receiving a nonvehicle reading in the real-time; and wherein determining in the real-time the theft level indicator includes determining the theft level indicator based on the nonvehicle reading. Further as an example, the method <NUM> includes wherein determining in the real-time the theft level indicator includes determining the theft level indicator based on a deviation a user normal usage, a vehicle normal usage, a concurrent normal usage, a schedule or a combination thereof.

Also as an example, the method <NUM> includes receiving a nonvehicle reading in the real-time; wherein analyzing the vehicle-related sensor reading with the theft risk model includes: analyzing the nonvehicle reading; determining an outlier based on a deviation a user normal usage, a vehicle normal usage, a concurrent normal usage, a schedule or a combination thereof; and generating the theft level indicator based on the outlier.

Yet further as an example, the method <NUM> includes analyzing the vehicle-related sensor reading with the theft risk model includes: detecting a sudden deviation in a vehicle normal usage based on the vehicle-related sensor reading without determining an outlier for the vehicle normal usage; and generating the theft alert without the determination of the outlier.

Still further as an example, the method <NUM> includes analyzing the vehicle-related sensor reading with the theft risk model includes detecting a deviation in a vehicle normal usage based on the vehicle-related sensor reading but within a schedule without determining an outlier for the vehicle normal usage.

The resulting method, process, apparatus, device, product, and/or system is straightforward, cost-effective, uncomplicated, highly versatile, accurate, sensitive, and effective, and can be implemented by adapting known components for ready, efficient, and economical manufacturing, application, and utilization. Another important aspect of an embodiment of the present invention is that it valuably supports and services the historical trend of reducing costs, simplifying systems, and increasing performance.

These and other valuable aspects of an embodiment of the present invention consequently further the state of the technology to at least the next level.

Claim 1:
A method (<NUM>) of operation for a compute system (<NUM>) comprising:
receiving a vehicle-related sensor reading (<NUM>) in a real-time (<NUM>);
determining in the real-time (<NUM>) a theft level indicator (<NUM>) for a vehicle (<NUM>) based on the vehicle-related sensor reading (<NUM>);
generating a theft alert (<NUM>) based on the theft level indicator (<NUM>) being a priority event (<NUM>) indicative of an unwanted disturbance related to a vehicle (<NUM>) without analysing the vehicle-related sensor reading (<NUM>) with a theft risk model (<NUM>);
analyzing the vehicle-related sensor reading (<NUM>) with a theft risk model (<NUM>), comprising determining an outlier (<NUM>) based on a deviation of at least one or a combination of a vehicle normal usage (<NUM>), a concurrent normal usage (<NUM>), and a schedule (<NUM>), , wherein vehicle normal usage is based on at least one or a combination of past routes, stops, and timeframe, associated with the vehicle (<NUM>), and generating the theft alert (<NUM>) being a non-priority event (<NUM>) based on the outlier (<NUM>); and
communicating the theft alert (<NUM>) for displaying on a device (<NUM>).