US9697013B2 - Systems and methods for providing technical support and exporting diagnostic data - Google Patents
Systems and methods for providing technical support and exporting diagnostic data Download PDFInfo
- Publication number
- US9697013B2 US9697013B2 US14/736,100 US201514736100A US9697013B2 US 9697013 B2 US9697013 B2 US 9697013B2 US 201514736100 A US201514736100 A US 201514736100A US 9697013 B2 US9697013 B2 US 9697013B2
- Authority
- US
- United States
- Prior art keywords
- ihs
- user
- service
- interface
- audio
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active, expires
Links
Images
Classifications
-
- G06F9/4446—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/451—Execution arrangements for user interfaces
- G06F9/453—Help systems
Definitions
- This disclosure relates generally to computer systems, and more specifically, to systems and methods for providing technical support and exporting diagnostic data.
- IHS Information Handling System
- An IHS generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes. Because technology and information handling needs and requirements may vary between different applications, IHSs may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in IHSs allow for IHSs to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, global communications, etc. In addition, IHSs may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
- an IHS may need to be serviced or supported.
- the IHS may have hardware and/or software that needs to be fixed, updated, removed, installed, or replaced from time to time.
- certain systems and methods described herein may enable a computer manufacturer or service provider to allow customers to have access to automated, simplified support actions or operations, for example, even when an IHS is not otherwise able to boot to its main Operating System (OS) or has other serious hardware or software failures.
- OS Operating System
- an Information Handling System may include a processor; and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution by the processor, cause the IHS to identify a video failure in response to executing a Basic I/O System (BIOS)/Unified Extensible Firmware Interface (UEFI) diagnostics routine prior to the booting of a main Operating System (OS), wherein the video failure renders the IHS incapable of providing a video interface; and in response to the identification, provide an audio interface to a user, wherein the audio interface enables the user to perform a troubleshooting operation in the absence of the video interface.
- BIOS Basic I/O System
- UEFI Unified Extensible Firmware Interface
- the video failure may include a video card or controller failure.
- the audio interface may be configured to provide a series of one or more voice instructions to the user via a loudspeaker coupled to or part of the IHS, and the voice instructions may be part of the troubleshooting operation.
- the one or more voice instructions may include one or more error codes configured to be reproduced via the audio interface.
- the audio interface may be configured to receive a user command or response to the voice instructions via a microphone coupled to or part of the IHS. Also, the audio interface may be configured to receive a user command or response to the voice instructions via a keyboard, touchscreen, or pointing device coupled to or part of the IHS.
- the program instructions upon execution by the processor, may further cause the IHS to detect a distinct secondary device in physical proximity to the IHS via a wireless interface, and to request that the secondary device provide a user interface to the user.
- the user interface as provided by the secondary device enables to the user to perform the troubleshooting operation with respect to the IHS.
- the IHS may be configured to transmit one or more voice instructions received from the user to the secondary device over the wireless interface.
- the program instructions may cause the IHS to transmit a mayday beacon to the secondary device, where the mayday beacon includes at least a device identification, fault data, or warranty data associated with the IHS.
- the program instructions may further cause the IHS to initiate a connection with a backend service or support personnel via a network, and the troubleshooting operation may involve one or more audio interactions between the user and the backend service or support personnel.
- a method may include identifying, by an IHS, a failure in the IHS, wherein the identification is in response to execution of a BIOS/UEFI diagnostics routine and prior to the booting of a main OS; transmitting, by the IHS, a mayday beacon, where the mayday beacon includes at least a device identification, fault data, or warranty data associated with the IHS; and providing, via a secondary device configured to receive the mayday beacon, an interface for troubleshooting the IHS, wherein the interface enables a user to cause the IHS to perform a troubleshooting operation upon the IHS.
- the failure may include a video card or controller failure that renders the IHS incapable of providing any graphical user interface (GUI) to the user.
- the method may include transmitting, by the IHS, one or more voice instructions received from the user to the secondary device.
- the secondary device may be configured to transmit a user instruction received at the secondary device back to the IHS.
- the method may also include initiating, via the secondary device, a connection with a remotely located backend service or support personnel.
- the troubleshooting operation may involve one or more interactions between the user and the backend service or support personnel.
- a memory device may have program instructions stored thereon that, upon execution by an IHS, cause the IHS to identify a software or hardware fault in the IHS; transmit, to a secondary device in a physical proximity with respect to the IHS, a mayday beacon, wherein the mayday beacon includes at least one of: IHS identification, fault data, or warranty data; and perform one or more troubleshooting operations upon the IHS in response to an interaction between a user of the IHS and a backend service or live technical support personnel accessible remotely via a user interface provided by the secondary device.
- the fault may include a video fault that renders the IHS incapable of providing any video-based user interface to the user, and the user interface provided to the user by the secondary device may be a video or audio interface.
- the warranty data may include a level of service identification associated with the IHS.
- the program instructions may further cause the IHS to select the live technical support personnel to provide the interaction with the user via the secondary device in response to the level of service identification indicating a premium user account.
- one or more of the techniques described herein may be performed, at least in part, by an IHS operated by a user. In other embodiments, these techniques may be performed by an IHS having a processor and a memory coupled to the processor, the memory including program instructions stored thereon that, upon execution by the processor, cause the IHS to execute one or more operations. In yet other embodiments, a non-transitory computer-readable medium or memory device may have program instructions stored thereon that, upon execution by an IHS, cause the IHS to execute one or more of the techniques described herein.
- FIG. 1 is a diagram illustrating an example of an environment where systems and methods for providing service and support to computing devices may be implemented according to some embodiments.
- FIG. 2 is a block diagram of an example of an Information Handling System (IHS) according to some embodiments.
- IHS Information Handling System
- FIG. 3 is a block diagram of an example of a service Basic I/O System (BIOS) according to some embodiments.
- BIOS Basic I/O System
- FIG. 4 is a flowchart of a method for providing service and support in a computing device according to some embodiments.
- FIG. 5 is a flowchart of a method for providing backend services and support to a computing device according to some embodiments.
- FIG. 6 is a is a flowchart of a method for providing technical support and exporting diagnostic data according to some embodiments.
- FIG. 7 is a diagram of a system for using a mayday beacon according to some embodiments.
- IHS Information Handling System
- OS main Operating System
- embodiments described herein provide Basic I/O System (BIOS) and/or service OS-level intelligence to enable a client device to self-diagnose and to receive automated service and support.
- BIOS Basic I/O System
- the main OS may be modified to implement one of more of the foregoing features.
- degraded state refers to the state of an IHS that is not capable of booting a main OS (e.g., WINDOWS®, MAC OS®, LINUX®, etc.), either fully or partially (e.g., in WINDOWS®'s “safe mode” or the like).
- main OS e.g., WINDOWS®, MAC OS®, LINUX®, etc.
- SOS service OS
- BIOS refers to a type of firmware used during an IHS's booting process (e.g., power-on, or reset).
- the BIOS initializes and tests an IHS' hardware components, and loads a boot loader or an OS from a memory device.
- the BIOS additionally provides an abstraction layer for the hardware which enables software executed by the IHS to interact with certain I/O devices such as keyboards, displays, etc.
- UEFI Unified Extensible Firmware Interface
- service OS refers to one or more program instructions or scripts distinct from an IHS's “main OS” such that, upon execution by an IHS (e.g., upon failure by the IHS to load the main OS), enable one or more support, diagnostics, or remediation operations to be performed independently of the state of the main OS.
- the service OS may include one or more service and support applications, as described in more detail below.
- an SOS may be stored in a recovery partition of a hard drive. Additionally or alternatively, an SOS may be stored in a Non-Volatile Memory (NVM) or flash memory built into the client system. Additionally or alternatively, the SOS may be stored in a remote location so as to allow an IHS to boot remotely “from the cloud.”
- NVM Non-Volatile Memory
- service capabilities may be invoked either “pre-boot” or “pre-OS.”
- Pre-boot capabilities may be built into the BIOS/UEFI, and pre-OS capabilities may be provided by a service OS.
- pre-boot services may include using enhanced BIOS diagnostics tools to detect hardware failure, providing a Quick Response (QR) code to simplify access to support services, etc.
- pre-OS services may include enabling a service OS to provide customer automated assistance, using built-in remediation scripts to help diagnose and remediate the device, improve support efficiency using live chat, remote control support, etc.
- pre-boot services may be focused on “no-boot” scenarios, whereas pre-OS services may be focused on operations such as remediation, boot from web, re-imaging from web, etc.
- each of any number of client devices 102 A-N may be an IHS or other computing device (generically referred to as “IHS 102 ,” “client 102 ,” “client device 102 ,” or “device 102 ”) including, for example, desktops, laptops, tablets, smartphones, and any other all-in-one (AIO) data processing device.
- IHS 102 IHS or other computing device
- client 102 client device 102
- device 102 any other all-in-one data processing device.
- devices 102 may be located in geographically distributed or remote locations, such as offices, homes, etc.
- Each device 102 may be operated by an individual end-consumer (e.g., lay person) or customer of a computer manufacturer or software provider, for instance.
- two or more of client devices 102 A-N may be deployed within or managed by the same organization (e.g., a business).
- Tools intended to facilitate service and/or support of client devices 102 include service technicians 103 , live support operators 104 , and/or backend service 105 .
- Service technicians 103 include trained employees or contractors that can travel to the site of device 102 or that can receive the physical device 102 (e.g., at a retail store, by mail, etc.) or part(s) thereof in order to make repairs, for example.
- Live support operator(s) 104 may be available, for instance, when device 102 fails but it is sufficiently operational that it can still connect the user to operator(s) 104 via chat, email, text messages, Voice-Over-Internet Protocol (VoIP) call, etc.
- VoIP Voice-Over-Internet Protocol
- client device 102 may place a conventional phone call to live support operator(s) 104 (e.g., using a 1-800 number or the like).
- live support operator(s) 104 may interactively guide the user in an effort to correct problems with client device 102 (e.g., troubleshooting).
- Backend service 105 may include one or more servers and/or IHSs configured to perform one or more automated operations with respect to device 102 .
- backend service 105 may be configured to communicate with a service OS prior to and/or independently of IHS 102 being able to boot a main OS, and it may enable one or more support, diagnostics, or remediation operations to be performed remotely including, but not limited to, telemetry, error reporting, tracking, chat, etc.
- telecommunications network 101 may include one or more wireless networks, circuit-switched networks, packet-switched networks, or any combination thereof to enable communications between two or more of IHSs.
- network 101 may include a Public Switched Telephone Network (PSTN), one or more cellular networks (e.g., third generation (3G), fourth generation (4G), or Long Term Evolution (LTE) wireless networks), satellite networks, computer or data networks (e.g., wireless networks, Wide Area Networks (WANs), metropolitan area networks (MANs), Local Area Networks (LANs), Virtual Private Networks (VPN), the Internet, etc.), or the like.
- PSTN Public Switched Telephone Network
- 3G third generation
- 4G fourth generation
- LTE Long Term Evolution
- an IHS may include any instrumentality or aggregate of instrumentalities operable to compute, calculate, determine, classify, process, transmit, receive, retrieve, originate, switch, store, display, communicate, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes.
- an IHS may be a personal computer (e.g., desktop or laptop), tablet computer, mobile device (e.g., Personal Digital Assistant (PDA) or smart phone), server (e.g., blade server or rack server), a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price.
- An IHS may include Random Access Memory (RAM), one or more processing resources such as a Central Processing Unit (CPU) or hardware or software control logic, Read-Only Memory (ROM), and/or other types of NVMs.
- RAM Random Access Memory
- CPU Central Processing Unit
- ROM Read-Only Memory
- Additional components of an IHS may include one or more disk drives, one or more network ports for communicating with external devices as well as various I/O devices, such as a keyboard, a mouse, touchscreen, and/or a video display.
- An IHS may also include one or more buses operable to transmit communications between the various hardware components.
- FIG. 2 is a block diagram of an example of an IHS.
- IHS 200 may be used to implement any of computer systems or devices 102 A-N and/or 105 .
- IHS 200 includes one or more CPUs 201 .
- IHS 200 may be a single-processor system including one CPU 201 , or a multi-processor system including two or more CPUs 201 (e.g., two, four, eight, or any other suitable number).
- CPU(s) 201 may include any processor capable of executing program instructions.
- CPU(s) 201 may be general-purpose or embedded processors implementing any of a variety of Instruction Set Architectures (ISAs), such as the x86, POWERPC®, ARM®, SPARC®, or MIPS® ISAs, or any other suitable ISA. In multi-processor systems, each of CPU(s) 201 may commonly, but not necessarily, implement the same ISA.
- ISAs Instruction Set Architectures
- Northbridge controller 202 may be configured to coordinate I/O traffic between CPU(s) 201 and other components.
- northbridge controller 202 is coupled to graphics device(s) 204 (e.g., one or more video cards or adaptors) via graphics bus 205 (e.g., an Accelerated Graphics Port or AGP bus, a Peripheral Component Interconnect or PCI bus, or the like).
- Northbridge controller 202 is also coupled to system memory 206 via memory bus 207 , and to hard disk drive (HDD) 218 .
- Memory 206 may be configured to store program instructions and/or data accessible by CPU(s) 201 .
- memory 206 may be implemented using any suitable memory technology, such as static RAM (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of memory.
- SRAM static RAM
- SDRAM synchronous dynamic RAM
- HDD 218 may include any magnetic, solid-state (SSD), or hybrid data storage device capable of storing an OS and other applications.
- Northbridge controller 202 is coupled to southbridge controller or chipset 208 via internal bus 209 .
- southbridge controller 208 may be configured to handle various of IHS 200 's I/O operations, and it may provide interfaces such as, for instance, Universal Serial Bus (USB), audio, serial, parallel, Ethernet, or the like via port(s), pin(s), and/or adapter(s) 216 over bus 217 .
- USB Universal Serial Bus
- southbridge controller 208 may be configured to allow data to be exchanged between IHS 200 and other devices, such as other IHSs attached to a network (e.g., network 101 ).
- southbridge controller 208 may support communication via wired or wireless general data networks, such as any suitable type of Ethernet network, for example; via telecommunications/telephony networks such as analog voice networks or digital fiber communications networks; via storage area networks such as Fiber Channel SANs; or via any other suitable type of network and/or protocol.
- wired or wireless general data networks such as any suitable type of Ethernet network, for example; via telecommunications/telephony networks such as analog voice networks or digital fiber communications networks; via storage area networks such as Fiber Channel SANs; or via any other suitable type of network and/or protocol.
- Southbridge controller 208 may also enable connection to one or more keyboards, keypads, touch screens, scanning devices, voice or optical recognition devices, or any other devices suitable for entering or retrieving data. Multiple I/O devices may be present in IHS 200 . In some embodiments, I/O devices may be separate from IHS 200 and may interact with IHS 200 through a wired or wireless connection. As shown, southbridge controller 208 is further coupled to one or more PCI devices 210 (e.g., modems, network cards, sound cards, or video cards) and to one or more SCSI controllers 214 via parallel bus 211 .
- PCI devices 210 e.g., modems, network cards, sound cards, or video cards
- Southbridge controller 208 is also coupled to BIOS/UEFI 212 and to Super I/O Controller 213 via Low Pin Count (LPC) bus 215 .
- BIOS/UEFI 212 includes non-volatile memory having program instructions stored thereon. Those instructions may be usable by CPU(s) 201 to initialize and test other hardware components and/or to load an OS onto IHS 200 .
- Super I/O Controller 213 combines interfaces for a variety of lower bandwidth or low data rate devices. Those devices may include, for example, floppy disks, parallel ports, keyboard and mouse, temperature sensor and fan speed monitoring/control, among others.
- southbridge controller 208 may be configured to allow data to be exchanged between BIOS/UEFI 212 and another IHS attached to network 101 (e.g., a remote server or other source of technical service) using wired or wireless capabilities of network adapter 216 .
- IHS 200 may be configured to provide access to different types of computer-accessible media separate from memory 206 .
- a computer-accessible medium may include any tangible, non-transitory storage media or memory media such as electronic, magnetic, or optical media—e.g., magnetic disk, a hard drive, a CD/DVD-ROM, a Flash memory, etc. coupled to IHS 200 via northbridge controller 202 and/or southbridge controller 208 .
- tangible and “non-transitory,” as used herein, are intended to describe a computer-readable storage medium (or “memory”) excluding propagating electromagnetic signals; but are not intended to otherwise limit the type of physical computer-readable storage device that is encompassed by the phrase computer-readable medium or memory.
- non-transitory computer readable medium” or “tangible memory” are intended to encompass types of storage devices that do not necessarily store information permanently, including, for example, RAM.
- Program instructions and data stored on a tangible computer-accessible storage medium in non-transitory form may afterwards be transmitted by transmission media or signals such as electrical, electromagnetic, or digital signals, which may be conveyed via a communication medium such as a network and/or a wireless link.
- IHS 200 is merely illustrative and is not intended to limit the scope of the disclosure described herein.
- any computer system and/or device may include any combination of hardware or software capable of performing certain operations described herein.
- the operations performed by the illustrated components may, in some embodiments, be performed by fewer components or distributed across additional components. Similarly, in other embodiments, the operations of some of the illustrated components may not be performed and/or other additional operations may be available.
- northbridge controller 202 may be combined with southbridge controller 208 , and/or be at least partially incorporated into CPU(s) 201 .
- one or more of the devices or components shown in FIG. 2 may be absent, or one or more other components may be added. Accordingly, systems and methods described herein may be implemented or executed with other IHS configurations.
- BIOS/UEFI 212 includes NVM mailbox 301 configured to store program instructions that, upon execution, provide and/or receive one or more service and support parameters or information 302 to or from control logic 303 of CPU(s) 201 to implement one or more service and support applications described in detail below.
- NVM mailbox 301 may serve as a “mailbox” to track issues and other information persistently.
- At least a part of the aforementioned service capabilities may be provided via a service OS that is stored at least in part within a designated a partition of HDD 318 , and/or on a remote IHS accessible to BIOS/UEFI 212 via network 101 .
- BIOS/UEFI 212 may be at least partially embedded into BIOS/UEFI 212 and/or NVM mailbox 301 , as described below.
- Systems and methods described herein may include a service and support application configured to provide automated services.
- client device BIOS level intelligence may be provided to execute self-diagnosis and to assist in automated services.
- Service capabilities are built into client device BIOS diagnostics pre-boot, service OS on disk, or boot from cloud. Moreover, these capabilities may be integrated with a services backend for automated client device error reporting, tracking, chat, remediation, etc.
- an automated diagnostics procedure of an automated service and support application may include performing a BIOS diagnostics to discriminate hardware from software issues (e.g., broken HDD or corrupt OS). Then, BIOS/UEFI 212 's NVM mailbox 301 may be used to track issues persistently from BIOS, pre-OS, OS, and/or backend sources.
- BIOS diagnostics to discriminate hardware from software issues (e.g., broken HDD or corrupt OS). Then, BIOS/UEFI 212 's NVM mailbox 301 may be used to track issues persistently from BIOS, pre-OS, OS, and/or backend sources.
- QR Quick Response
- the client device may connect directly with a backend service Application Programming Interface (API) to initiate a warranty check (e.g., via hardware service tag as hardware ID), generate a service case, update debug data, initiate recovery or remediation operations, etc.
- API Application Programming Interface
- the automated service and support application may trigger an automatic dispatch of customer replaceable units (CRUs), parts, or components within the client device.
- the automated service and support application may make service offers based on failure diagnoses.
- service offers may include an out of warranty upsell, warranty upgrade, additional service offers (e.g., HDD recovery for dead drive upsell), warranty carry in capability (e.g., report closest repair facilities for carry in service), etc.
- the automated service and support application may provide remote control, remote scripting/diagnostics, live customer support, backup, re-imaging and OS re-install via local factory image or via web, and the like.
- Systems and methods described herein may include a service and support application configured to provide technical support in no-video situations, which are otherwise difficult to troubleshoot.
- client device 102 when client device 102 is not capable of outputting a video signal, users have no other option but to place a phone call to the manufacturer, because the device itself can provide no help.
- a service and support application as described herein may include a audio-only support system, for example, similar to an automated phone support system or Interactive Voice Response (IVR), but that is local to client device 102 and capable of running in a pre-OS or pre-Boot environment. While a customer is interacting with the service and support application, client device 102 can run a diagnostics procedure. When appropriate, the service and support application may handoff the local automated audio support to online voice support from the IHS manufacturer. If network 101 is unavailable, client device 102 may prompt the user to connect directly to a nearby device distinct from client device 102 to perform one or more of these operations.
- IVR Interactive Voice Response
- the service and support application may include pre-OS availability of audio-based troubleshooting, offline audio support concurrent with diagnostics, and/or merging or handover between offline and online audio support.
- the service and support application may also prompt the user to make peer-to-peer (P2P) connection to a nearby device, readout codes for diagnosis/dispatch verification, and/or prompt the user to add or insert external storage to which to output diagnostic results.
- P2P peer-to-peer
- Systems and methods described herein may include a service and support application configured to provide an automated and authenticated mayday beacon, with a cost-effective 1-to-1 support for verified client device 102 's failures.
- a wireless signal beacon (e.g., Bluetooth, Wi-Fi, etc.) may be sent (e.g., on a periodic basis) containing verification of the device credentials issued at the time of manufacture, details regarding the fault and a direct link to the manufacturer's support, decision tree location, and/or whether a premium account is linked.
- the beacon may be authenticated directly to a support representative with all failure information logged and available. This technique may prevent erroneous support calls by verifying the user has actually experienced a failure and authenticating that the proper support level has been funded, which promotes a low cost, one-on-one support service.
- the service and support application may be configured to broadcast a distress signal with credentials to make authenticated jump to a support site provided by backend services 105 from a secondary device or infrastructure.
- a certificate may be issued from the manufacturer containing client device 102 's platform, user information, and/or service level. Such a certificate and a landing page for service may be passed automatically while client device 102 is out of service.
- the service may be rendered utilizing secondary device or infrastructure via authenticated and verified client device 102 experiencing failure.
- Systems and methods described herein may include a service and support application configured to provide network (e.g., Internet) recovery and service.
- network e.g., Internet
- BIOS/UEFI 212 may include, for example, a boot loader, where to go (e.g., an IP address), booting proper image for machine, and/or a service application.
- the service and support application may provide a smarter BIOS/UEFI 212 , smart diagnostics in BIOS/UEFI 212 , intelligent boot selection to local drive or web, and IP-awareness, among other features.
- the service OS may be supported on many platforms and on many versions of those platforms.
- a single platform e.g., having a model name or number
- different hardware configurations e.g., different CPUs, etc.
- the service and support application may be configured to provide a Unified Extensible Firmware Interface (UEFI) BIOS module with smart diagnostics and IP support intelligently controls boot to a service OS.
- Client device 102 connects to backend services 105 to get proper and latest service OS for that particular device.
- Backend service or server 105 may receive a client manifest, and it may dynamically serve a service OS kernel, drivers, and a service application to client device 102 for recovery and/or remediation.
- UEFI Unified Extensible Firmware Interface
- Systems and methods described herein may include a service and support application configured to improve customer experience while downloading a recovery OS by reducing the perception of wait time.
- client device 102 When client device 102 has a malfunction, it can boot to an alternate OS.
- the alternate OS is downloaded via network 101 before client device 102 is able to boot.
- the download time is variable, often nontrivial, and may negatively affect customer perception.
- the service and support application may estimate the download time of the alternate OS and, based on an assessment of the delay, may “pull forward” one or more low-bandwidth activities and/or options that the customer may need or desire to do anyway (e.g., updating contact information), thus helping save customer time and reducing the perception of delay.
- the service and support application may be configured to prioritize lower-bandwidth tasks based on estimated OS load time. Prioritization of activities may be based, for example, upon data about malfunction.
- the application may enable user input or interaction while OS is downloading (e.g., updating contact information, describing the problem that happened before failure, etc.).
- the application may also submit a phone number for text alerts when failed client device 102 is ready, and it may start a local interactive debug troubleshooting operation while the OS is being downloaded.
- Systems and methods described herein may include a service and support application configured to provide identity continuity in the servicing of a failed client device 102 .
- a user may need to enter service credentials on a service web portal provided by backend service or server 105 , whether accessing the portal directly or via a service OS. However, the user may not recall such infrequently-used credentials at the point of need.
- a service and support application can authenticate the user, and then automatically submit the service portal token to log user into the service portal without manual entry of customer credentials. This method may also be used to allow access to customers Wi-Fi profiles, and other type of data that needs protection.
- the service and support application may be configured to use a BIOS's “mailbox” to communicate one or more services token(s) to enable a single-sign-on procedure, while protecting the token(s) with user credentials.
- Systems and methods described herein may include a service and support application configured to perform smart diagnosis and triage of client device failures.
- the application may provide an automated method of hardware exoneration, identifying software versus hardware issues with targeted debug.
- POST may be used to detect issues during power on sequence, then those results may be used for firmware-based diagnostics for next level of hardware diagnostics.
- Main OS, POST and firmware based diagnostic results may be stored on the client device's BIOS's NVM or “mailbox” as device health data.
- a service OS may be started and uses health data to either run even more extensive hardware diagnostics or to run software fault detection and remediation test.
- Cloud connection to client device 102 's manufacturer or backend service 105 may facilitate the download of updated tests, reporting of issues, and initiation of replacement parts dispatch.
- the service and support application may be configured to use a BIOS's NVM or “mailbox” to aggregate device health data.
- the application may use firmware and/or a service OS. Each stage of diagnostics may use information from previous diagnostics results to target more detailed but specific subsequent tests.
- Systems and methods described herein may include a service and support application configured to perform smart diagnosis using hosted resources.
- client device 102 When client device 102 cannot boot after repeated attempts, it may begin a process to perform self-evaluation and potentially self-repair operations. Because having all executable diagnostics and repair modules present in the non-bootable system would be costly, operations may involve successively loading software modules from a remote support source 105 . But, modules loaded through internet/wireless networks 101 are likely slow to download, and therefore should be reduced or minimized to be tailored exactly as needed for a given process.
- a service and support application may be configured to upload test results to backend service 105 , which automatically determines a subsequent module to be downloaded based on client device data and/or historic analysis of other client devices.
- the application may provide a remote boot of diagnostic and repair software modules. Appropriate modules may be selected and/or minimized to the next diagnosis stage in order to facilitate transfer over slow communications channels.
- a service may provide a reverse proxy for a hosted module to be loaded so that client device 102 may boot from a single Uniform Resource Locator (URL) for each process.
- URL Uniform Resource Locator
- Systems and methods described herein may include a service and support application configured to intelligently alter a boot order to aid in automated client device diagnosis and repair.
- client device 102 fails to completely boot, it does not move on to another component, as set in the boot order, if a previously attempted component remains available for boot. Often the process gets stuck trying to boot and repair the main OS indefinitely. The pre-set boot order remains static and unaltered.
- a service and support application may be configured to break out of a failing sequence and load alternative OSs and/or repair and diagnostic modules from various local or remotely available resources selected by their availability, performance, or content.
- client device 102 may change the boot order again to try another source.
- a successful repair may lead back to booting the main OS as the primary boot resource.
- An alternative or service OS may result as the final stage if the main OS cannot be made bootable.
- the service and support application may be configured to dynamically change a boot order based upon conditions of client device 102 .
- the application may also set client device 102 in temporary or “permanent” boot orders based upon the completion stage of the diagnosis and repair.
- Systems and methods described herein may include a service and support application configured to export failure and diagnostic data from a malfunctioning client device.
- Client device 102 may sometimes malfunction such that it cannot provide output or accept input from a user. It may still function at a low level, however, in order to capture its own failure codes and run diagnostics. These codes and diagnostic results are written to internal storage and are useful for system remediation, but unfortunately remain captive on the malfunctioning client device.
- a service and support application may create an embedded capability that is triggered by a malfunction, identifies the failure/diagnostics data, and exports the data upon insertion of an external storage device.
- the external device may then be taken to a functioning IHS or other client device, which can receive the data for local analysis and/or upload it for analysis or recordkeeping.
- the service and support application may be configured to export the data to an external device having a marker file.
- the marker file may be generated by an IHS manufacturer or software provider, and identifies the external device as belonging to an authorized service technician or other party.
- a service mode may be provided for malfunction situations in which a user cannot interact with or extract data from failed client device 102 . Normal behavior that occurs when inserting an external storage device may be overridden in the service mode, and instead client device 102 may export related failure/debug data to the external device.
- the service mode may be independent of the main OS.
- Systems and methods described herein may include a service and support application configured to provide technician access to only services data on an encrypted drive.
- client device 102 may use services data (e.g., system telemetry, failure and diagnostics data, services history, etc.). If a system has OS volume encryption (e.g., BitLocker) and fails over to a service OS, the service OS cannot typically access the services data due to encryption. That is, the latest and most valuable services data is trapped.
- OS volume encryption e.g., BitLocker
- service and support application may create a separate services data partition in local storage (e.g., client device 102 's own hard drive), also encrypted for consistency with user intent.
- the key for the services data partition may be different than the key used for the remainder of the volume encryption, and may be stored by backend service 105 with user permission to allow service technician 103 access in controlled support situations.
- services data may be kept outside the inaccessible encrypted OS partition while still protected.
- the service and support application may be configured to create a services data partition that is encrypted differently (e.g., different key and/or encryption algorithm) than client device 102 's main OS volume for purposes of services access. Access to the separately encrypted data may be useful to services applications and only visible to an authorized technician. Also, the application may provide the ability to pull encryption key from cloud and decrypt service data on device distinct from the client device, for example, using technician credentials (e.g., when network 101 is not accessible by client device 102 ).
- Systems and methods described herein may include a service and support application configured to protect the service OS administrator's password while allowing technician one-time execution with elevated privileges.
- An initial password for a service OS may be created using a One-Time Password (OTP) technique and a seed stored on client device 102 's BIOS/UEFI 212 's NVM mailbox 301 .
- the seed and a hardware service tag may be sent to backend services 105 to provide a mechanism for service technician 103 or live support operator(s) 104 to run privileged applications in the service OS without using a master password.
- OTP One-Time Password
- application of OTP in a support scenario may enable higher security for remote management and debug operations.
- NVM mailbox 301 may be used for storing initial seed at factory tied to the client hardware service tag.
- a service technician at failure time may generate a code to request administrator permissions.
- Systems and methods described herein may include a service and support application configured to provide automatic system stop and boot to a service OS for forensics analysis.
- detection of suspicious activity for secure systems may result in automated boot to service OS with automated forensics lockdown and analysis outside the potentially compromised main OS.
- the application may combine security intrusion or behavior capabilities with a service OS to provide new forensics features. For example, detection of intrusion or malware in client device 102 may initiate lock down mode boot to the service OS.
- the service OS then connects or phones home to backend services 105 report a potential security incident, and initiates data forensics collection.
- Client device 102 may maintain a lockdown mode at BIOS level controlled by policy to maintain security of network 101 and data for forensic analysis.
- Systems and methods described herein may include a service and support application configured to migrate contents of an internal storage partition to a replacement storage device.
- data contained on a secondary partition of client device 102 's internal drive storage may be migrated from an old or existing drive to a replacement or upgraded drive by storing it in Dynamic RAM (DRAM) while the drive is hot-swapped. If DRAM capacity is insufficient, overflow may be handled by external storage (e.g., USB drive), for example.
- DRAM Dynamic RAM
- a Solid State Drive (SSD) portion may instead be a secondary partition on a standard hard drive.
- an application may migrate a specified drive partition into DRAM, use external storage for data that exceeds the capacity of DRAM, and/or recognize and provisions replacement storage with contents of drive partition.
- Systems and methods described herein may include a service and support application configured to increase the effectiveness of a service OS by utilizing a custom hypervisor.
- a conventional service OS may be configured to run on client device 102 only when the main OS is suspended. Such a conventional service OS may not be able to effectively monitor real-time events in the main OS as they occur. For example, a conventional service OS may only be able to examine the state of the primary disk, data, etc. using residual data collected by the main OS when the main OS was running. To address these, and other concerns, a service OS as described herein may run in a hypervisor (in a first tier next to the main OS, or in a second tier), and the hypervisor may allow the service OS full access to the resources of the primary OS. Accordingly, dynamic state of the primary OS may be monitored either constantly or periodically and actions and reports may occur immediately (a “watchdog” OS).
- a hypervisor environment may provide a service OS of client device 102 with full access to the resources of the main OS (but not necessarily vice-versa, for example, to keep the main OS from being corrupted).
- the service OS may run as a peer of the primary OS.
- the peer, service OS may be configured to monitor for process, memory, disk and other resources of the main OS, and may be allowed to alter them as required.
- FIG. 4 is a flowchart of a method for providing service and support in a computing device.
- method 400 may be performed, at least in part, by BIOS/UEFI 212 and/or CPU(s) 201 of client device 102 , for example, when client device 102 is operating in degraded state (e.g., no video, hard drive fault, etc.).
- degraded state e.g., no video, hard drive fault, etc.
- method 400 includes attempting to boot client device 102 .
- block 401 may be executed in response to a power-on or reset event.
- Block 402 determines whether a Power-On-Self-Test (POST) procedure has been successfully performed upon client device 102 by BIOS/UEFI 212 . If so, then block 404 determines whether a main OS has been successfully booted. In some cases, a successful boot of the main OS may include a complete success; in other cases, however, a “successful” boot may include cases where the main OS is booted in safe mode, or the like, with less than all of its functionality available to a user. If block 404 detects successful boot of the main OS, then control of client device 102 is passed to the main OS at block 406 , and the method ends. In that case, support and/or service issues may be handled by the main OS.
- POST Power-On-Self-Test
- service and support may be provided in a pre-boot environment at block 403 .
- Examples of service and support procedures available to client device 102 in such a scenario include, but is not limited to, detecting network availability, use of QR codes or the like (with or without network connections), collection and transmission of telemetry data and/or event logs, alerts and indications of failures, and procedures for dealing with no-video scenarios, as outlined above.
- block 405 determines whether a service OS can be booted.
- the service OS may be initiated from a memory local to the client device.
- the service OS may be stored in NVRAM or in a designated partition of HDD 218 .
- the service OS may be loaded from a backend service 105 over network 101 (e.g., cloud boot). If the service OS is not capable of being booted at block 405 , then service and support may again be provisioned within the pre-boot environment at block 403 . Otherwise, service and support operations may be provided in a pre-OS environment at block 407 , before method 400 ends.
- BIOS/UEFI 212 may be configured to use a “boot strike count” as part of a failure detection procedure. That is, the number of unsuccessful main OS and/or service OS boot attempts may be kept by BIOS/UEFI 212 , and that information may be used by one or more of the aforementioned service and support operations in subsequent boot attempts.
- FIG. 5 is a flowchart of a method for providing backend services and support to a computing device.
- method 500 may be performed, at least in part, by BIOS/UEFI 212 and/or CPU(s) 201 of client device 102 in cooperation with backend services 105 , for example, when client device 102 is operating in degraded state (e.g., no video, hard drive fault, etc.), either in pre-boot environment 402 or pre-OS environment 407 of FIG. 4 .
- degraded state e.g., no video, hard drive fault, etc.
- method 500 includes determining whether access to network 101 is available to client device 102 . If not, then service and support operations may be provided as local remediation operations (e.g., QR code services, etc.) at block 502 . If there is network access, however, block 503 includes client device 102 “phoning home” to reach backend services 105 , which in turn may perform one or more checks. Examples of such checks include, but are not limited to, warranty and service entitlement checks performed using the client device 102 's service tag or other identifying information such as the customer account token.
- method 500 includes uploading client device telemetry and/or debug data to backend services 105 .
- the telemetry and/or debug data may be used by backend service 105 to iteratively improve diagnostics and fault isolation.
- method 500 includes any number of remote remediation and service operations performed by backend services 105 . Examples of such operations include, but are not limited to, auto dispatch for CRUs, point of need services (such as warranty upsells, warranty upgrades, service offers, etc.), and HDD recovery (with optional reporting of closest location, office, or store available for carry-in service by the user). Other operations may include remote control of one or more components of client device 102 , chat support, backup, re-imaging, OS re-install via local factory image or cloud, etc.
- Client device 102 may fail in ways that prevent the user or technical support staff from troubleshooting that device, even though the device may still be capable of providing useful diagnostic information. Examples of these situations include instances of POST or video failures (e.g. a video controller or graphics card fails and cannot provide a video interface to the user), including the failure of a client device to boot a primary or main OS. Remote troubleshooting and support in scenarios like these are difficult. Generally, a customer has no option but to call live support operators 104 , because the faulty client device cannot provide help in any way (e.g., through a graphical user interface or the like).
- systems and methods described herein may include a service and support application configured to provide technical support and exporting diagnostic data, for example, from a malfunctioning client device in a no-video situation.
- a local audio support system built into client devices 102 may allow a user to interact with the device no-POST and/or no-video failure situations.
- Various automated service and support actions may be provided via the local audio support system, including, for example, a handoff to live audio support via Voice-Over-IP (VoIP). While the customer is interacting with the local audio support system, the malfunctioning client device may be executing self-diagnostics operations.
- VoIP Voice-Over-IP
- the local audio support system may prompt the user to connect directly to a distinct nearby device other than malfunctioning client device (e.g., another one of client devices 102 , a tablet or mobile phone, an intelligent appliance, etc.), referred to herein as “secondary devices,” and which are generally not subject to the same failures (e.g., no video) being currently addressed for the malfunctioning client device.
- a distinct nearby device other than malfunctioning client device e.g., another one of client devices 102 , a tablet or mobile phone, an intelligent appliance, etc.
- the local audio support system may be used regardless of the status of the network (e.g., the network is available), for example, in no-video situations so that a user can employ a secondary device (e.g., another client device in close physical proximity to the malfunctioning device) as a user interface proxy or intermediary.
- a secondary device e.g., another client device in close physical proximity to the malfunctioning device
- a client device 102 may include a mayday beacon system configured to send out a wireless signal or message, referred to herein as a “mayday beacon,” which may be received the secondary device.
- the mayday beacon may contain client device credentials, fault data, support entitlements, and other useful information.
- the secondary device may then serve as a connectivity and/or user interface intermediary between or among the malfunctioning client device, the end user, and support staff.
- the secondary device may be configured to make contact with backend service 105 , for example, and to forward diagnostic data obtained from client device 102 .
- systems and methods described herein may facilitate the capture and secure export of diagnostic data to external media (e.g., a USB drive or the like) for debug purposes.
- a local audio support system and a mayday beacon system may each be configured operate in parallel or concurrently.
- client device 102 may be capable of responding to whichever method the user is able to interact with.
- the local audio support system may guide the user towards the secondary device, which can sometimes provide a richer and more useful user experience.
- the mayday beacon system may provide additional support capabilities when the secondary device has network connectivity that is otherwise lacking in the malfunctioning client device.
- the local audio support system in the malfunctioning device may inform the user that an interface via a secondary device is available. For instance, the malfunctioning device may tell the user that a mayday beacon system exists, and that they should use it.
- FIG. 6 is a flowchart of method 600 for providing technical support and exporting diagnostic data.
- block 600 may be performed, at least in part, by a malfunctioning client device (e.g., client device 102 B) in conjunction with a secondary device (e.g., client device 102 A), for example, when the malfunctioning client device is operating in a pre-boot or pre-OS environment under control of BIOS/UEFI 212 .
- a malfunctioning client device e.g., client device 102 B
- a secondary device e.g., client device 102 A
- the client device detects a malfunction and enters a pre-boot or pre-OS environment for diagnostics or troubleshooting purposes using a local audio support system and/or mayday beacon system. At least initially, such an environment may be provided, for example, by BIOS/UEFI 212 within the malfunctioning client device.
- the malfunctioning client device determines whether it is capable of displaying video (e.g., a graphical user interface) to a user. If so, block 603 employs a full standard pre-boot or pre-OS support environment to attempt to address the malfunction and method 600 ends.
- block 604 may initiate the local audio support system and advise the user of the malfunctioning client device's state, for example, via one or more audio prompts.
- an audio prompt may explain the detected or suspected cause of the malfunction, if known.
- the audio prompt may provide technical support contact information (e.g., phone numbers), system information (e.g., model, identification, tag, technical specifications, or the like), identification of an electronic part within the malfunctioning client device to be replaced, ordered, or dispatched, etc.
- the audio prompt may ask that the user insert external storage into the malfunctioning client device to automatically output diagnostics results (e.g., fault codes, crash dump, etc.), which may then be accessed using another device.
- responses to audio prompts may be provided by the user via a microphone coupled to the malfunctioning client device.
- responses may be provided via a keyboard, touchscreen, or pointing device coupled to the malfunctioning client device.
- responses may be provided via any suitable interface of a secondary device.
- the malfunctioning client device determines whether network(s) 101 is available. If so, the malfunctioning client device may provide another audio prompt to connect and forward diagnostic data to backend services 105 or live support 104 , for instance.
- the malfunctioning client device may determine whether the user has interacted with it via the audio support system. If so, block 608 conducts any additional local troubleshooting via a series of audio prompts, and block 609 enables a user to handoff control of the device to support personnel 104 via a Voice-Over-IP (VoIP) connection or the like.
- VoIP Voice-Over-IP
- Block 610 indicates that method 600 continues to provide technical support to the user until it reaches a resolution and/or before method 600 ends. It should be noted that, in some cases, while the user is interacting with the local audio support system, the system may continue to run diagnostic operations in the “background.”
- block 607 determines that the user has not interacted with the client device, control returns to block 604 . Moreover, if the network is not available at block 605 , then block 611 provides yet another audio prompt to the user to connect the malfunctioning client device to a nearby, secondary device, or plug-in storage device, in order to output diagnostics or forensics data from the malfunctioning device.
- the malfunctioning client device may transmit or broadcast a mayday beacon, for example, using a wireless interface (e.g., Bluetooth, Wi-Fi, etc.).
- the mayday beacon may include an identification of the user or client device, fault data, and/or warranty data.
- the warranty data may include a level of service identification associated with the malfunctioning client device. For instance, a lower or standard level of service may only enable a user to reach backend service 105 (e.g., a technical support website or repository) to obtain information that would then allow the user to fix the malfunction on his or her own; whereas a higher or premium level of service may enable the user to reach live support 104 and/or to surrender control of the malfunctioning device to a remote operator for support purposes.
- backend service 105 e.g., a technical support website or repository
- the level of service or support of the malfunctioning client device may be different than another level associated with the secondary device (e.g., the secondary device may not be entitled to any service on its own). In other cases, the ability to use the secondary device may itself be available to certain levels of service and not others. Moreover, in some cases, the secondary device may receive the mayday beacon and interact with the user and/or backed support, even if the malfunctioning IHS is incapable of receiving a response from the secondary device.
- Block 613 determines whether a secondary device has responded to the mayday beacon. If not, control returns to block 612 . Otherwise, at block 614 , the secondary device may receive diagnostic or forensics data from the malfunctioning client device, and block 615 may display technical support portions (related to the malfunctioning client device) to the user via the secondary device. The user can then interact with the secondary device using the secondary device's available interfaces, including any audio or video interfaces, to reach block 610 , where method 600 continues support to resolution before it ends.
- the local audio support system and the mayday beacon system may be configured operate in parallel or concurrently.
- the malfunctioning device may begin broadcasting the mayday beacon (that is, block 601 leads to both blocks 602 and 612 in parallel).
- the secondary device may be verified by backend service 105 prior to it being able to receive or decode the diagnostics data of block 614 from the malfunctioning device. For example, upon receiving the mayday beacon via a local wireless interface, the client device may forward information about the mayday beacon and/or about itself to backend service 105 via network 101 , and the backend service 105 may then authenticate the secondary device as trusted to provide mayday beacon services to the malfunctioning client device prior to the secondary device being able to. As part of the authentication process, the secondary device may receive an encryption key or the like from backend service 105 that allows it to examine certain parts of the mayday beacon and/or to continue interacting with the malfunctioning client device to obtain additional information or to guide the user to perform additional operations.
- the method of claim 600 may provide pre-OS availability of audio-only based troubleshooting and offline audio support concurrently with diagnostics. Method 600 may also merge or handover between offline (local) and online (remote or live) audio support. Method 600 may prompt user to make peer-to-peer (P2P) connection to another nearby device. Moreover, method 600 may provide a readout of codes for diagnosis/dispatch verification and may prompt user to put insert external storage to output diagnostics and forensics results.
- P2P peer-to-peer
- FIG. 7 is a diagram of system 700 for using a mayday beacon according to some embodiments.
- malfunctioning client device 701 e.g., client device 102 B
- Malfunctioning client device 701 may also detect the presence of secondary device 704 (e.g., client device 102 A) and/or may attempt to reach it using mayday beacon 705 .
- secondary device 704 e.g., client device 102 A
- malfunctioning device 701 may be configured to broadcast mayday beacon 705 regardless of whether the malfunctioning device can detect the presence of secondary device 704 . Then, secondary device 704 may provide a video interface and/or an audio interface for end user 702 in order to provide service and support 707 from resource 706 (e.g., live operators 104 , backend service 105 , etc.).
- resource 706 e.g., live operators 104 , backend service 105 , etc.
- the mayday beacon may be sent on a periodic basis containing verification of the device credentials issued at the time of manufacture, details regarding the fault, and a direct link to a support website, a decision tree location and, if a premium account can link, authenticated directly to a support representative with all failure information logged and available.
- these implementations may prevent, among other problems, erroneous support calls by verifying the user has actually experienced a failure and authenticating that the proper support level has been funded.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Abstract
Description
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/736,100 US9697013B2 (en) | 2015-06-10 | 2015-06-10 | Systems and methods for providing technical support and exporting diagnostic data |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/736,100 US9697013B2 (en) | 2015-06-10 | 2015-06-10 | Systems and methods for providing technical support and exporting diagnostic data |
Publications (2)
Publication Number | Publication Date |
---|---|
US20160364250A1 US20160364250A1 (en) | 2016-12-15 |
US9697013B2 true US9697013B2 (en) | 2017-07-04 |
Family
ID=57516984
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/736,100 Active 2035-12-25 US9697013B2 (en) | 2015-06-10 | 2015-06-10 | Systems and methods for providing technical support and exporting diagnostic data |
Country Status (1)
Country | Link |
---|---|
US (1) | US9697013B2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10977022B2 (en) * | 2017-03-21 | 2021-04-13 | Hewlett-Packard Development Company, L.P. | Operating system retrieval |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9830213B2 (en) * | 2015-10-01 | 2017-11-28 | Quest Software Inc. | Collecting and transmitting diagnostics information from problematic devices |
US10142208B1 (en) | 2015-12-23 | 2018-11-27 | EMC IP Holding Company LLC | Auto selection of applications based on resource capacity |
US10896440B2 (en) | 2015-12-23 | 2021-01-19 | EMC IP Holding Company LLC | Offsite data analysis for appliances |
US10275651B2 (en) * | 2017-05-16 | 2019-04-30 | Google Llc | Resolving automated assistant requests that are based on image(s) and/or other sensor data |
US10877845B2 (en) | 2018-08-02 | 2020-12-29 | Dell Products, L.P. | Apparatus and method for diagnostic use of BIOS attributes to remediate configuration issues |
US11341436B2 (en) * | 2018-09-21 | 2022-05-24 | FanTazTech LLC | Dynamic live connections for on-demand technical support |
US11231940B2 (en) | 2019-09-26 | 2022-01-25 | Dell Products L.P. | System and method for automatic recovery of information handling systems |
WO2022197362A1 (en) * | 2021-03-16 | 2022-09-22 | Arris Enterprises Llc | Diagnostic testing or analysis of elements of network devices |
US20230064398A1 (en) * | 2021-08-27 | 2023-03-02 | Dell Products L.P. | Uefi extensions for analysis and remediation of bios issues in an information handling system |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040041832A1 (en) * | 2002-08-28 | 2004-03-04 | Nguyen Tuyet-Huong Thi | Method and system for displaying information at a remote display device |
US20040125757A1 (en) * | 2002-12-30 | 2004-07-01 | Martti Mela | Streaming media |
US20050216784A1 (en) * | 2004-03-19 | 2005-09-29 | Karamadai Srinivasan | Method and system for providing information for remote device support |
US20080101468A1 (en) * | 2006-11-01 | 2008-05-01 | Kazunobu Ishikawa | Test system of digital video data and semiconductor device |
US20100313072A1 (en) * | 2009-06-03 | 2010-12-09 | International Business Machines Corporation | Failure Analysis Based on Time-Varying Failure Rates |
US20140115392A1 (en) * | 2012-10-18 | 2014-04-24 | GM Global Technology Operations LLC | Self-diagnostic non-bussed control module |
US20140195864A1 (en) * | 2011-09-29 | 2014-07-10 | Cellco Partnership D/B/A Verizon Wireless | Remote issue logging and reporting of mobile station issues and diagnostic information to manufacturer |
US20140344627A1 (en) * | 2013-05-16 | 2014-11-20 | Advantest Corporation | Voice recognition virtual test engineering assistant |
US20150149835A1 (en) * | 2013-11-26 | 2015-05-28 | International Business Machines Corporation | Managing Faults in a High Availability System |
US20160019134A1 (en) * | 2014-07-21 | 2016-01-21 | Bank Of America Corporation | Error assessment tool |
US20160077905A1 (en) * | 2014-09-12 | 2016-03-17 | Intel Corporation | Low Power Debug Architecture For System-On-Chips (SoCs) And Systems |
US20160147604A1 (en) * | 2014-11-25 | 2016-05-26 | Inventec (Pudong) Technology Corporation | Server system |
-
2015
- 2015-06-10 US US14/736,100 patent/US9697013B2/en active Active
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040041832A1 (en) * | 2002-08-28 | 2004-03-04 | Nguyen Tuyet-Huong Thi | Method and system for displaying information at a remote display device |
US20040125757A1 (en) * | 2002-12-30 | 2004-07-01 | Martti Mela | Streaming media |
US20050216784A1 (en) * | 2004-03-19 | 2005-09-29 | Karamadai Srinivasan | Method and system for providing information for remote device support |
US20080101468A1 (en) * | 2006-11-01 | 2008-05-01 | Kazunobu Ishikawa | Test system of digital video data and semiconductor device |
US20100313072A1 (en) * | 2009-06-03 | 2010-12-09 | International Business Machines Corporation | Failure Analysis Based on Time-Varying Failure Rates |
US20140195864A1 (en) * | 2011-09-29 | 2014-07-10 | Cellco Partnership D/B/A Verizon Wireless | Remote issue logging and reporting of mobile station issues and diagnostic information to manufacturer |
US20140115392A1 (en) * | 2012-10-18 | 2014-04-24 | GM Global Technology Operations LLC | Self-diagnostic non-bussed control module |
US20140344627A1 (en) * | 2013-05-16 | 2014-11-20 | Advantest Corporation | Voice recognition virtual test engineering assistant |
US20150149835A1 (en) * | 2013-11-26 | 2015-05-28 | International Business Machines Corporation | Managing Faults in a High Availability System |
US20160019134A1 (en) * | 2014-07-21 | 2016-01-21 | Bank Of America Corporation | Error assessment tool |
US20160077905A1 (en) * | 2014-09-12 | 2016-03-17 | Intel Corporation | Low Power Debug Architecture For System-On-Chips (SoCs) And Systems |
US20160147604A1 (en) * | 2014-11-25 | 2016-05-26 | Inventec (Pudong) Technology Corporation | Server system |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10977022B2 (en) * | 2017-03-21 | 2021-04-13 | Hewlett-Packard Development Company, L.P. | Operating system retrieval |
Also Published As
Publication number | Publication date |
---|---|
US20160364250A1 (en) | 2016-12-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9529602B1 (en) | Systems and methods for internet recovery and service | |
US9870282B2 (en) | Systems and methods for providing service and support to computing devices with boot failure | |
US9665452B2 (en) | Systems and methods for smart diagnoses and triage of failures with identity continuity | |
US9697013B2 (en) | Systems and methods for providing technical support and exporting diagnostic data | |
US9798606B2 (en) | Systems and methods for smart diagnosis using hosted resources with intelligent altering of boot order | |
US10102073B2 (en) | Systems and methods for providing automatic system stop and boot-to-service OS for forensics analysis | |
US11050765B2 (en) | Security system for managed computer system | |
JP6668314B2 (en) | System, method, apparatus, and computer program product for providing mobile device support services | |
JP6396887B2 (en) | System, method, apparatus, and non-transitory computer readable storage medium for providing mobile device support services | |
US9798624B2 (en) | Automated fault recovery | |
US10489232B1 (en) | Data center diagnostic information | |
US9734015B2 (en) | Pre-boot self-healing and adaptive fault isolation | |
US9959127B2 (en) | Systems and methods for exporting diagnostic data and securing privileges in a service operating system | |
US9465643B1 (en) | Systems and methods for monitoring a primary operating system (OS) and/or migrating data using an OS hypervisor | |
US11153149B2 (en) | System and method for proactive distributed agent based network diagnosis | |
US10055280B2 (en) | Discovery and remediation of a device via a peer device | |
WO2018095414A1 (en) | Method and apparatus for detecting and recovering fault of virtual machine | |
US10049009B2 (en) | Remediation of a device using an embedded server | |
US20150067402A1 (en) | Providing a remote diagnosis for an information appliance via a secure connection | |
US9798625B2 (en) | Agentless and/or pre-boot support, and field replaceable unit (FRU) isolation | |
US10061683B2 (en) | Systems and methods for collecting error data to troubleshoot product errors | |
US9846640B2 (en) | System and method for retrieving wireless access point credentials from a BIOS NVRAM | |
US9755922B2 (en) | Minimized installation of point of presence software agents by use of pre-installed browser | |
US10102008B2 (en) | Managed boot process system | |
US10754753B1 (en) | Performance of virtual machine instances using machine recognition of screenshot images |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: DELL PRODUCTS, L.P., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LO, YUAN-CHANG;ANDREWS, CARLTON A.;SEIBERT, PHILIP M.;AND OTHERS;REEL/FRAME:035886/0121 Effective date: 20150610 |
|
AS | Assignment |
Owner name: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT, NORTH CAROLINA Free format text: SUPPLEMENT TO PATENT SECURITY AGREEMENT (ABL);ASSIGNORS:DELL PRODUCTS L.P.;DELL SOFTWARE INC.;WYSE TECHNOLOGY, L.L.C.;REEL/FRAME:036502/0206 Effective date: 20150825 Owner name: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT, TEXAS Free format text: SUPPLEMENT TO PATENT SECURITY AGREEMENT (NOTES);ASSIGNORS:DELL PRODUCTS L.P.;DELL SOFTWARE INC.;WYSE TECHNOLOGY L.L.C.;REEL/FRAME:036502/0291 Effective date: 20150825 Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH CAROLINA Free format text: SUPPLEMENT TO PATENT SECURITY AGREEMENT (TERM LOAN);ASSIGNORS:DELL PRODUCTS L.P.;DELL SOFTWARE INC.;WYSE TECHNOLOGY L.L.C.;REEL/FRAME:036502/0237 Effective date: 20150825 Owner name: BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT, NO Free format text: SUPPLEMENT TO PATENT SECURITY AGREEMENT (ABL);ASSIGNORS:DELL PRODUCTS L.P.;DELL SOFTWARE INC.;WYSE TECHNOLOGY, L.L.C.;REEL/FRAME:036502/0206 Effective date: 20150825 Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH Free format text: SUPPLEMENT TO PATENT SECURITY AGREEMENT (TERM LOAN);ASSIGNORS:DELL PRODUCTS L.P.;DELL SOFTWARE INC.;WYSE TECHNOLOGY L.L.C.;REEL/FRAME:036502/0237 Effective date: 20150825 Owner name: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., A Free format text: SUPPLEMENT TO PATENT SECURITY AGREEMENT (NOTES);ASSIGNORS:DELL PRODUCTS L.P.;DELL SOFTWARE INC.;WYSE TECHNOLOGY L.L.C.;REEL/FRAME:036502/0291 Effective date: 20150825 |
|
AS | Assignment |
Owner name: DELL SOFTWARE INC., CALIFORNIA Free format text: RELEASE OF REEL 036502 FRAME 0206 (ABL);ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:040017/0204 Effective date: 20160907 Owner name: WYSE TECHNOLOGY L.L.C., CALIFORNIA Free format text: RELEASE OF REEL 036502 FRAME 0206 (ABL);ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:040017/0204 Effective date: 20160907 Owner name: DELL PRODUCTS L.P., TEXAS Free format text: RELEASE OF REEL 036502 FRAME 0206 (ABL);ASSIGNOR:BANK OF AMERICA, N.A., AS ADMINISTRATIVE AGENT;REEL/FRAME:040017/0204 Effective date: 20160907 |
|
AS | Assignment |
Owner name: DELL SOFTWARE INC., CALIFORNIA Free format text: RELEASE OF REEL 036502 FRAME 0237 (TL);ASSIGNOR:BANK OF AMERICA, N.A., AS COLLATERAL AGENT;REEL/FRAME:040028/0088 Effective date: 20160907 Owner name: DELL SOFTWARE INC., CALIFORNIA Free format text: RELEASE OF REEL 036502 FRAME 0291 (NOTE);ASSIGNOR:BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS COLLATERAL AGENT;REEL/FRAME:040027/0637 Effective date: 20160907 Owner name: WYSE TECHNOLOGY L.L.C., CALIFORNIA Free format text: RELEASE OF REEL 036502 FRAME 0291 (NOTE);ASSIGNOR:BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS COLLATERAL AGENT;REEL/FRAME:040027/0637 Effective date: 20160907 Owner name: DELL PRODUCTS L.P., TEXAS Free format text: RELEASE OF REEL 036502 FRAME 0291 (NOTE);ASSIGNOR:BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS COLLATERAL AGENT;REEL/FRAME:040027/0637 Effective date: 20160907 Owner name: DELL PRODUCTS L.P., TEXAS Free format text: RELEASE OF REEL 036502 FRAME 0237 (TL);ASSIGNOR:BANK OF AMERICA, N.A., AS COLLATERAL AGENT;REEL/FRAME:040028/0088 Effective date: 20160907 Owner name: WYSE TECHNOLOGY L.L.C., CALIFORNIA Free format text: RELEASE OF REEL 036502 FRAME 0237 (TL);ASSIGNOR:BANK OF AMERICA, N.A., AS COLLATERAL AGENT;REEL/FRAME:040028/0088 Effective date: 20160907 |
|
AS | Assignment |
Owner name: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT, TEXAS Free format text: SECURITY AGREEMENT;ASSIGNORS:ASAP SOFTWARE EXPRESS, INC.;AVENTAIL LLC;CREDANT TECHNOLOGIES, INC.;AND OTHERS;REEL/FRAME:040136/0001 Effective date: 20160907 Owner name: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH, AS COLLATERAL AGENT, NORTH CAROLINA Free format text: SECURITY AGREEMENT;ASSIGNORS:ASAP SOFTWARE EXPRESS, INC.;AVENTAIL LLC;CREDANT TECHNOLOGIES, INC.;AND OTHERS;REEL/FRAME:040134/0001 Effective date: 20160907 Owner name: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH, AS COLLAT Free format text: SECURITY AGREEMENT;ASSIGNORS:ASAP SOFTWARE EXPRESS, INC.;AVENTAIL LLC;CREDANT TECHNOLOGIES, INC.;AND OTHERS;REEL/FRAME:040134/0001 Effective date: 20160907 Owner name: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., A Free format text: SECURITY AGREEMENT;ASSIGNORS:ASAP SOFTWARE EXPRESS, INC.;AVENTAIL LLC;CREDANT TECHNOLOGIES, INC.;AND OTHERS;REEL/FRAME:040136/0001 Effective date: 20160907 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., T Free format text: SECURITY AGREEMENT;ASSIGNORS:CREDANT TECHNOLOGIES, INC.;DELL INTERNATIONAL L.L.C.;DELL MARKETING L.P.;AND OTHERS;REEL/FRAME:049452/0223 Effective date: 20190320 Owner name: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., TEXAS Free format text: SECURITY AGREEMENT;ASSIGNORS:CREDANT TECHNOLOGIES, INC.;DELL INTERNATIONAL L.L.C.;DELL MARKETING L.P.;AND OTHERS;REEL/FRAME:049452/0223 Effective date: 20190320 |
|
AS | Assignment |
Owner name: THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., TEXAS Free format text: SECURITY AGREEMENT;ASSIGNORS:CREDANT TECHNOLOGIES INC.;DELL INTERNATIONAL L.L.C.;DELL MARKETING L.P.;AND OTHERS;REEL/FRAME:053546/0001 Effective date: 20200409 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
AS | Assignment |
Owner name: WYSE TECHNOLOGY L.L.C., CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: SCALEIO LLC, MASSACHUSETTS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: MOZY, INC., WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: MAGINATICS LLC, CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: FORCE10 NETWORKS, INC., CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: EMC IP HOLDING COMPANY LLC, TEXAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: EMC CORPORATION, MASSACHUSETTS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: DELL SYSTEMS CORPORATION, TEXAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: DELL SOFTWARE INC., CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: DELL PRODUCTS L.P., TEXAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: DELL MARKETING L.P., TEXAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: DELL INTERNATIONAL, L.L.C., TEXAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: DELL USA L.P., TEXAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: CREDANT TECHNOLOGIES, INC., TEXAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: AVENTAIL LLC, CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 Owner name: ASAP SOFTWARE EXPRESS, INC., ILLINOIS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:058216/0001 Effective date: 20211101 |
|
AS | Assignment |
Owner name: SCALEIO LLC, MASSACHUSETTS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (040136/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061324/0001 Effective date: 20220329 Owner name: EMC IP HOLDING COMPANY LLC (ON BEHALF OF ITSELF AND AS SUCCESSOR-IN-INTEREST TO MOZY, INC.), TEXAS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (040136/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061324/0001 Effective date: 20220329 Owner name: EMC CORPORATION (ON BEHALF OF ITSELF AND AS SUCCESSOR-IN-INTEREST TO MAGINATICS LLC), MASSACHUSETTS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (040136/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061324/0001 Effective date: 20220329 Owner name: DELL MARKETING CORPORATION (SUCCESSOR-IN-INTEREST TO FORCE10 NETWORKS, INC. AND WYSE TECHNOLOGY L.L.C.), TEXAS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (040136/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061324/0001 Effective date: 20220329 Owner name: DELL PRODUCTS L.P., TEXAS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (040136/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061324/0001 Effective date: 20220329 Owner name: DELL INTERNATIONAL L.L.C., TEXAS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (040136/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061324/0001 Effective date: 20220329 Owner name: DELL USA L.P., TEXAS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (040136/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061324/0001 Effective date: 20220329 Owner name: DELL MARKETING L.P. (ON BEHALF OF ITSELF AND AS SUCCESSOR-IN-INTEREST TO CREDANT TECHNOLOGIES, INC.), TEXAS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (040136/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061324/0001 Effective date: 20220329 Owner name: DELL MARKETING CORPORATION (SUCCESSOR-IN-INTEREST TO ASAP SOFTWARE EXPRESS, INC.), TEXAS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (040136/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061324/0001 Effective date: 20220329 |
|
AS | Assignment |
Owner name: SCALEIO LLC, MASSACHUSETTS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (045455/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061753/0001 Effective date: 20220329 Owner name: EMC IP HOLDING COMPANY LLC (ON BEHALF OF ITSELF AND AS SUCCESSOR-IN-INTEREST TO MOZY, INC.), TEXAS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (045455/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061753/0001 Effective date: 20220329 Owner name: EMC CORPORATION (ON BEHALF OF ITSELF AND AS SUCCESSOR-IN-INTEREST TO MAGINATICS LLC), MASSACHUSETTS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (045455/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061753/0001 Effective date: 20220329 Owner name: DELL MARKETING CORPORATION (SUCCESSOR-IN-INTEREST TO FORCE10 NETWORKS, INC. AND WYSE TECHNOLOGY L.L.C.), TEXAS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (045455/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061753/0001 Effective date: 20220329 Owner name: DELL PRODUCTS L.P., TEXAS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (045455/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061753/0001 Effective date: 20220329 Owner name: DELL INTERNATIONAL L.L.C., TEXAS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (045455/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061753/0001 Effective date: 20220329 Owner name: DELL USA L.P., TEXAS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (045455/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061753/0001 Effective date: 20220329 Owner name: DELL MARKETING L.P. (ON BEHALF OF ITSELF AND AS SUCCESSOR-IN-INTEREST TO CREDANT TECHNOLOGIES, INC.), TEXAS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (045455/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061753/0001 Effective date: 20220329 Owner name: DELL MARKETING CORPORATION (SUCCESSOR-IN-INTEREST TO ASAP SOFTWARE EXPRESS, INC.), TEXAS Free format text: RELEASE OF SECURITY INTEREST IN PATENTS PREVIOUSLY RECORDED AT REEL/FRAME (045455/0001);ASSIGNOR:THE BANK OF NEW YORK MELLON TRUST COMPANY, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:061753/0001 Effective date: 20220329 |