Browse Prior Art Database

System and Method for Delaying a Device-Wipe

IP.com Disclosure Number: IPCOM000131924D
Publication Date: 2005-Nov-21
Document File: 1 page(s) / 28K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed Anonymously Currently we have the ability to send a device-wipe command from an e-mail server. As soon as the command is received on the device it is executed. This works really well in most circumstances. There could be situations, though, where you want to give the device/user a chance to either recover or prove that things are OK before you cause the device to wipe itself. This invention addresses that problem. Basically, we add the ability to add a delay to a device-wipe command. This time limit (which could be hard-coded at some amount of time or else could be a value included in the IT command to the device) would tell the device to wait for a period of time before initiating the wipe. But what is the point of having a delay for the wipe unless there is a way to prevent the wipe before the delay is finished? Not much :) So we propose a few ways to stop the wipe from occurring if some action takes place before the time limit completes. (1) The device receives a STOP_WIPE IT command from the e-mail server. This would take place if the user lost their device, so IT issued a wipe, and then the user found it. They could phone their IT Admin to let them know the good news and the admin could issue a STOP_WIPE since the device-wipe is no longer necessary. (2) The user types in their device password correctly. Often the main purpose of the wipe command is to prevent user data from falling into the wrong hands. If the user regains their device, then by authenticating themselves to the device this could be enough to stop the wipe from taking place. If this happened, the device should send a notification to the mail redirection server so that the admin knows what has happened. As a follow-on to (2), the admin may not always want a correct password entry to stop the wipe from taking place. Conceivably this could happen if the user knows their password has been compromised. In that case, the WIPE command coming from the mail redirection server would need to have a parameter in it along the line PASSWORD_DOESN'T_STOP so that the attacker entering the correct password will not stop the wipe from taking place.

This text was extracted from a Microsoft Word document.
This is the abbreviated version, containing approximately 67% of the total text.

Delayed Device-Wipe

System and Method for Delaying a Device-Wipe

Disclosed Anonymously

Currently we have the ability to send a device-wipe command from an e-mail server.  As soon as the command is received on the device it is executed.  This works really well in most circumstances.

There could be situations, though, where you want to give the device/user a chance to either recover or prove that things are OK before you cause the device to wipe itself.  This invention addresses that problem.

Basically, we add the ability to add a delay to a device-wipe command.  This time limit (which could be hard-coded at some amount of time or else could be a value included in the IT command to the device) would tell the device to wait for a period of time before initiating the wipe.

But what is the point of having a delay for the wipe unless there is a way to prevent the wipe before the delay is finished?  Not much :)  So we propose a few ways to stop the wipe from occurring if some action takes place before the time limit completes.

(1) The device receives a STOP_WIPE IT command from the e-mail server.  This would take place if the user lost their device, so IT issued a wipe, and then the user found it.  They could phone their IT Admin to let them know the good news and the admin could issue a STOP_WIPE since the device-wipe is no longer necessary.

(2) The user types in their device password correctly.  Often the main purpose of the wipe command is to prevent user data from fall...