Systems and methods for device ecosystem disruption notification following an accident

Patent metadata

Field	Value
Publication number	US-12596605-B2
Application number	US-202318505176-A
Country	US
Kind code	B2
Filing date	Nov 9, 2023
Priority date	Nov 9, 2023
Publication date	Apr 7, 2026
Grant date	Apr 7, 2026

Abstract

Systems and methods for device ecosystem disruption notification following an accident are described. In some embodiments, an Information Handling System (IHS) may include an Embedded Controller (EC) and a memory coupled to, or integrated into, the EC, where the memory comprises program instructions that, upon execution by the EC, cause the EC to, in response an accident, take inventory of IHS components and, in response to a difference between the inventory and a previous inventory, perform an action.

First claim

The invention claimed is:

1 . An Information Handling System (IHS), comprising that comprises:
an Embedded Controller (EC) operably connected to an always-on power rail; and a memory coupled to, or integrated into, the EC, wherein the memory comprises program instructions that, upon execution by the EC while the IHS is in an off or modern standby state, cause the EC to:
receive sensor data from a sensor;
determine if an accident occurred, based, at least in part, upon the sensor data;
in response to a determination that an accident occurred, determine an accident severity and an accident type based at least in part on the sensor data, and take inventory of IHS components;
in response to a difference between the inventory and a previous inventory, perform an action that comprises at least a first portion of an accident mitigation plan;
notify a backend service of the accident via an Out-of-Band (OOB) connection while the IHS remains in the off or modern standby state;
wake the IHS from the off or modern standby state; and
provide at least a second portion of the accident mitigation plan to a Basic Input/Output System (BIOS).

2 . The IHS of claim 1 , wherein the program instructions, upon execution by the EC, further cause the EC to determine an accident subtype based, at least in part, upon an accident duration determined based at least in part on the sensor data.

3 . The IHS of claim 1 , wherein the sensor comprises at least one of: an accelerometer, a gyroscope, or an Inertial Measurement Unit (IMU).

4 . The IHS of claim 1 , wherein the accident type comprises at least one of: a drop, a fall, a throw, a hit, a crash, an impact, or a collision that involves the IHS.

5 . The IHS of claim 1 , wherein the action comprises at least one of: issue a notification, or run a diagnostics of an IHS component.

6 . The IHS of claim 5 , wherein the notification comprises at least one of: a notification to a user of the IHS, to an Information Technology Decision Maker (ITDM) responsible for maintenance of the IHS, or to an Original Equipment Manufacturer (OEM) service.

7 . The IHS of claim 5 , wherein the diagnostics further comprises a Built-In Self-Test (BIST) performable by firmware.

8 . The IHS of claim 1 , wherein the difference further comprises an indication of at least one of: a disconnected cable, internal device damage, or a port malfunction.

9 . The IHS of claim 1 , wherein the program instructions, upon execution by the EC, further cause the EC to perform the action in response to a determination that the difference is unexpected.

10 . The IHS of claim 9 , wherein the program instructions, upon execution by the EC, further cause the EC to execute an Artificial Intelligence/Machine Learning (AI/ML) model configured to determine whether the difference is unexpected.

11 . The IHS of claim 9 , wherein the program instructions, upon execution by the EC, further cause the EC to determine whether the difference is unexpected based upon context information.

12 . The IHS of claim 11 , wherein the context information comprises at least one of: whether or how the IHS has moved, a location of the IHS, a time of day, a bag state, or calendar information of a user of the IHS.

13 . The IHS of claim 1 , wherein the program instructions, upon execution by the EC, further cause the EC to report an indication of the accident to a remote service over a sideband connection.

14 . The IHS of claim 1 , wherein the program instructions, upon execution by the EC, further cause the EC to select the action based, at least in part, upon an accident policy.

15 . The IHS of claim 1 , wherein the program instructions, upon execution by the EC, further cause the EC to report an indication of the difference to a remote service over a sideband connection.

16 . The IHS of claim 15 , wherein the program instructions, upon execution by the EC, further cause the EC to receive a command to perform the action from the remote service over the sideband connection.

17 . The IHS of claim 1 , wherein the program instructions, upon execution by the EC, further cause the EC to send a command to an Operating System (OS) of the IHS to take the inventory upon reboot or wake of the IHS in response to the accident that occurred while the IHS was in the off or modern standby state.

18 . The IHS of claim 1 , wherein the program instructions, upon execution by the EC, further cause the EC to take the previous inventory periodically in an absence of any detected accident.

19 . An Information Handling System (IHS), that comprises:
a processor operably connected to an always-on power rail of the IHS; and a memory coupled to the processor, the memory configured with program instructions stored thereon that, upon execution by the processor, cause the IHS, while in an off or modern standby state, to perform operations that comprise:
receive sensor data from a sensor;
determine if an accident occurred, based, at least in part, upon the sensor data;
in response to a determination that an accident occurred, determine an accident severity, an accident type, and whether the accident was a compound accident, based at least in part on a duration of the accident determined from the sensor data, and enumerate IHS components;
in response to a difference between the enumerated IHS components and a previously collected list of IHS components, perform an action that comprises at least a first portion of an accident mitigation plan;
notify a backend service of the accident via an Out-of-Band (OOB) connection while the IHS remains in the off or modern standby state;
wake the IHS from the off or modern standby state; and
provide at least a second portion of the accident mitigation plan to a Basic Input/Output System (BIOS).

20 . A method, comprising:
receiving, by an Embedded Controller (EC) operably connected to an always-on power rail configured in an Information Handling System (IHS) while the IHS is in an off or modern standby state, sensor data from a sensor; determining, by the EC using a trained Artificial Intelligence (AI)/Machine Learning (ML) model and the sensor data, if an accident involving the IHS occurred; in response to determining that an accident occurred, determining, by the EC, an accident severity, an accident type, and whether the accident comprised a bounce, using at least a duration of the accident determined from the sensor data, and collecting, by the EC, a current inventory of components coupled to IHS; performing an action that comprises at least a first portion of an accident mitigation plan, by the EC while the IHS remains in the off or modern standby state, in response to a difference between the current inventory and a previous inventory of IHS components; notifying a backend service of the accident via an Out-of-Band (OOB) connection, by the EC while the IHS remains in the off or modern standby state; waking, by the EC, the IHS from the off or modern standby state; and providing, by the EC, at least a second portion of the accident mitigation plan to a Basic Input/Output System (BIOS).

Assignees

• Dell Products L P

Inventors

• Sayyed Ibrahim
• Hamlin Daniel L
• Samuel Balasingh P
• Abdelhalim Alan H

Classifications

• G06F11/3055

  Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available (error or fault processing without redundancy G06F11/0703; error detection or correction by redundancy in data representation G06F11/08; error detection or correction of the data by redundancy in operations G06F11/14; error detection or correction by redundancy in hardware G06F11/16) · CPC title

• G06F11/3089

  Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents (software debugging using additional hardware using a specific debug interface G06F11/3656; performance evaluation by tracing or monitoring G06F11/3466) · CPC title

• G06F11/0751

  Error or fault detection not based on redundancy (power supply failures G06F1/30; network fault management H04L41/06) · CPC title

• G06F11/0793 Primary

  Remedial or corrective actions (recovery from an exception in an instruction pipeline G06F9/3861; by retry G06F11/1402; for recovering from a failure of a protocol instance or entity H04L69/40) · CPC title

• G06F11/079

  Root cause analysis, i.e. error or fault diagnosis (in a hardware test environment G06F11/22; in a software test environment G06F11/36) · CPC title