Patent Description:
Enterprises can have a variety of different devices that can be used by employees. For example, various devices can be at an enterprise location to help improve the productivity of the employees. For example, enterprises may have large printers or multi-function devices (MFDs) that can be shared by employees at an office location.

MFDs are devices that can perform a variety of different functions. The MFDs can provide a variety of different options to perform various job requests, such as different colors, different paper sizes, changing a print quality, changing a size of an image and/or text to be printed, stapling, collating, providing different email addresses, selecting which network storage service to which to send a scanned document, and the like.

<CIT> discloses removal of program licensed to user. <CIT> discloses secure authentication using memory cards. <CIT> discloses an image forming method, image forming apparatus and program and recording medium. <CIT> discloses a system and method for updating printer location information field.

According to aspects illustrated herein, there are provided an enterprise owned multi-function device (MFD) and a method for authenticating and controlling the enterprise owned MFD. One disclosed feature of the embodiments is an enterprise owned MFD that comprises a communication interface to establish a communication session with an authentication server, a re-activation timer, a processor and a non-transitory computer readable medium storing instructions, which when executed by the processor, cause the processor to authenticate the enterprise owned MFD over the communication session when the enterprise owned MFD is activated at a remote location of an employee, create a local account of the employee for local authentication, authorize access to the employee via the local account of the employee until the re-activation timer expires, determine an expiration of a de-activation timer, delete the local account of the employee from the enterprise owned MFD in response to the expiration of the de-activation timer, and transmit a notification to the authentication server to schedule a pick-up of the enterprise owned MFD from the remote location of the employee.

Another disclosed feature is a method for authenticating and controlling an enterprise owned MFD. The method executed by a processor of the enterprise owned MFD comprises detecting activation, transmitting a request for authentication of an employee in response to the activation, receiving a confirmation of authentication of the employee, creating a local account of the employee for local authentication, authorizing access of the enterprise owned MFD to the employee via the local account of the employee until a re-activation timer expires, starting a de-activation timer in response to the re-activation timer expiring, determining that the de-activation timer has expired, deleting the local account of the employee from the enterprise owned MFD in response to the determining that the de-activation timer has expired, and transmitting a notification to the authentication server to schedule a pick-up of the enterprise owned MFD from the remote location of the employee.

The teaching of the present disclosure can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:.

The present disclosure broadly discloses enterprise owned MFDs that can be configured for remote authentication and local control at an employee location and methods for performing the same. As discussed above, enterprises can have a variety of different devices that can be used by employees. For example, various devices can be at an enterprise location to help improve the productivity of the employees. For example, enterprises may have large printers or multi-function devices (MFDs) that can be shared by employees at an office location.

However, as more employees begin to work remotely from home, the employees may not have access to these enterprise MFDs that are shared in the office location. The employees may still need access to the job functions and features at their home office while working remotely.

MFDs may be relatively expensive devices, and employees may not want to pay for their own MFDs. Enterprises may not want to provide enterprise owned MFDs to the employees without restrictions. Otherwise, other family members in the employees' homes may use the MFDs and drive up usage and maintenance costs for the MFDs.

The present disclosure provides MFDs that can be configured to allow an enterprise to remotely authenticate use of the MFDs at the employees' remote locations. The MFDs may also be configured to locally control authentication after the MFDs are initially activated and authenticated with the enterprises. Thus, the MFDs may prevent unauthorized family members from using the MFDs and limit use of the MFDs to the employees.

In addition, the MFDs include a de-activation timer. When the de-activation timer expires, the associated MFD is de-activated, and a notification is transmitted to the associated enterprise for pick up. The enterprise may then send a logistics courier to the employee's location to pick up the MFD when no longer needed by the employee or if the employee is returning to the office regularly.

<FIG> illustrates an example network <NUM> of the present disclosure. The network <NUM> may include a home <NUM> of an employee <NUM>, an enterprise location <NUM>, and an internet protocol (IP) network <NUM>. In one embodiment, the IP network <NUM> may include an authentication server (AS) <NUM> and a database (DB) <NUM>. The AS <NUM> may also be referred to as the remote server or authentication server. The AS <NUM> may perform remote authentication of a multi-function device (MFD) <NUM>, as described in further detail below.

In one embodiment, the DB <NUM> may store authentication information for each MFD <NUM> that is sent to a remote location. The AS <NUM> may perform authentication by matching authentication information received from the employee <NUM> via the MFD <NUM> to the authentication information stored in the DB <NUM> that was registered by the enterprise <NUM> when the MFD <NUM> was configured.

It should be noted that the IP network <NUM> has been simplified for ease of explanation and may include additional network elements or devices that are not shown. For example, the IP network <NUM> may include additional gateways, firewalls, access networks, routers, switches, and the like.

In one embodiment, the enterprise <NUM> may be a company that owns the MFD <NUM>. The enterprise <NUM> may allow the employee <NUM> to work remotely from the employee's home <NUM>. As noted above, the employee <NUM> may want access to the MFD <NUM> for productivity. The MFD <NUM> may be relatively expensive to own and maintain. For example, replacement ink or toner for the MFD <NUM> may be expensive, as well as paper and overall maintenance. Thus, the enterprise <NUM> may not want the MFD <NUM> to be accessed for personal use by other family members in the home <NUM> who may drive up the overall costs to operate and maintain the MFD <NUM> at a remote location.

In one embodiment, the enterprise <NUM> may configure or modify the MFD <NUM> to enable remote administration with a self-managed account ability. For example, the enterprise <NUM> may create and load a configuration file that may perform the functions described herein on the MFD <NUM>. The enterprise <NUM> may also add a de-activation timer to the MFD <NUM>, a global positioning system (GPS) radio to the MFD <NUM>, and the like. The configuration file may allow the MFD <NUM> to be remotely authenticated when activated at the home <NUM> of the employee <NUM>. Once authenticated, the configuration file may create a local account for the employee <NUM> and limit access to the MFD <NUM> to the employee <NUM>.

After the MFD <NUM> is configured by the enterprise <NUM>, a courier <NUM> may deliver the enterprise owned MFD <NUM> to the home <NUM> of the employee <NUM>. The employee <NUM> may then activate the MFD <NUM>. When the enterprise owned MFD <NUM> is activated in the employee's home <NUM>, the employee <NUM> may provide authentication information of the employee's account with the enterprise <NUM> via the user interface <NUM> of the MFD <NUM>. The authentication information may be transmitted to the AS <NUM> via the IP network <NUM>. The AS <NUM> may perform the authentication.

In one embodiment, the MFD <NUM> may also transmit GPS coordinates to the AS <NUM>. This may ensure that the enterprise owned MFD <NUM> was delivered to the correct address of the employee <NUM> and that another user is not attempting to use the enterprise owned MFD <NUM>. In addition, the GPS coordinates may ensure that the employee <NUM> is not taking the enterprise owned MFD <NUM> to another location or allowing another family member to "borrow" the enterprise MFD <NUM>.

In one embodiment, the GPS coordinates may also be provided to the MFD <NUM> from a mobile endpoint device <NUM>. For example, if the MFD <NUM> is not equipped with a GPS radio or the GPS radio of the MFD <NUM> is malfunctioning, the mobile endpoint device <NUM> may provide the GPS coordinates to the MFD <NUM> to be transmitted to the AS <NUM>.

After the employee <NUM> is authenticated, the AS <NUM> may also transmit customized settings to the MFD <NUM>. For example, the employee <NUM> may have customized user interfaces, workflows, authorized features, and the like. For example, the employee <NUM> may have a customized user interface with icons arranged in a certain order or location on the user interface <NUM>. The employee <NUM> may have custom workflows that have been pre-programmed to allow the employee <NUM> to select a single icon to execute multiple steps for a particular job request on the MFD <NUM>.

In addition, the configuration file loaded onto the MFD <NUM> may prompt the employee <NUM> to create a local account via the user interface <NUM>. The local account may perform local authentication on the MFD <NUM> without having to communicate with the AS <NUM> each time the employee <NUM> wants to use the MFD <NUM>.

The local account may also allow the employee <NUM> to select desired authorization methods. For example, the employee <NUM> may create a local account using a username and password or create an authorization associated with a proximity card, a mobile endpoint device <NUM> of the employee, and the like. For example, rather than entering a local username and password on the user interface <NUM>, the employee <NUM> may be able to scan a proximity card or transmit authorization information from the mobile endpoint device <NUM> to access the MFD <NUM>.

In one embodiment, once the enterprise owned MFD <NUM> is activated and authenticated, a re-activation timer and a de-activation timer may be activated. The re-activation timer may control a time limit that controls how frequently the employee <NUM> may be required to re-authenticate the MFD <NUM>. For example, the re-activation timer may be one week, one month, six months, one year, and the like. When the re-activation timer expires, the employee <NUM> may be required to re-authenticate the MFD <NUM> with the AS <NUM>, as described above.

The de-activation timer may control a time limit that controls how much time after expiration of the re-activation timer the employee <NUM> has to perform the re-authentication. For example, the de-activation timer may expire <NUM> hours after expiration of the re-activation timer, <NUM> week after expiration of the re-activation timer, <NUM> month after expiration of the re-activation timer, and the like. If the employee <NUM> fails to perform the re-authentication before the de-activation timer expires, the MFD <NUM> may be deactivated, and a notification may be transmitted to the enterprise <NUM> to pick up the MFD <NUM> from the home <NUM> of the employee <NUM>. Once the re-authentication is performed, the re-activation timer and the de-activation timer may be reset.

When the re-activation timer expires, the employee <NUM> may request additional time to reset the re-activation timer. For example, the employee <NUM> may send a request to the enterprise <NUM> as part of the re-authentication process. If approved, the enterprise <NUM> may transmit a control signal to the AS <NUM> to have the AS <NUM> send a control signal to the MFD <NUM> to reset the re-activation timer.

If the additional time is not approved, the MFD <NUM> may transmit a notification to the enterprise <NUM> (e.g., via the AS <NUM>, an email, or any other type of communication). The MFD <NUM> may then delete all local accounts of the employee and deactivate itself. The enterprise <NUM> may then schedule the courier <NUM> to pick up the MFD <NUM> from the home <NUM> of the employee <NUM>.

<FIG> illustrates a block diagram of an example MFD <NUM> illustrated in <FIG>. In one embodiment, the MFD <NUM> may include a processor <NUM>, a memory <NUM>, a communication interface <NUM>, a de-activation timer <NUM>, a re-activation timer <NUM>, and a GPS radio <NUM>. The processor <NUM> may be communicatively coupled to the memory <NUM>, the communication interface <NUM>, de-activation timer <NUM>, the re-activation timer <NUM>, and the GPS radio <NUM>. The processor <NUM> may control operation of the communication interface <NUM>, the de-activation timer <NUM>, the re-activation timer <NUM>, and the GPS radio <NUM>. The processor <NUM> may receive and/or transmit authorization or authentication information via the communication interface <NUM>.

In one embodiment, the communication interface <NUM> may be to establish a communication path between the MFD <NUM> and the AS <NUM> via the IP network <NUM>. For example, the communication interface <NUM> may be a wireless or wired communication interface. For example, the communication interface <NUM> may be a WiFi radio, an Ethernet connection, a fax over IP connection that uses an RJ-<NUM> connection, a cellular radio, and the like.

The re-activation timer <NUM> may include an internal clock. The re-activation timer may include a preset amount of time that is set by the enterprise <NUM> (e.g., a configuration file loaded on the MFD <NUM>). The re-activation timer <NUM> may count up to the present amount of time or may count down the preset amount of time using the internal clock. The re-activation timer <NUM> may begin when the MFD <NUM> has been successfully authenticated by the employee <NUM> after delivery. The re-activation timer <NUM> may control when and/or how frequently the employee <NUM> may be required to perform re-authentication to confirm that the employee <NUM> is still actively using the MFD <NUM>.

The de-activation timer <NUM> may include an internal clock. The de-activation timer <NUM> may include a preset amount of time that is set by the enterprise <NUM> (e.g., a configuration file loaded on to the MFD <NUM>). The de-activation timer <NUM> may count up to the preset amount of time or may count down the preset amount of time using the internal clock. The de-activation timer <NUM> may begin once the re-activation timer <NUM> expires. The de-activation timer <NUM> may control an amount of time the employee <NUM> has to perform the re-authentication before the MFD <NUM> is deactivated.

The GPS radio <NUM> may provide location information. For example, the GPS radio <NUM> may provide latitude and longitude coordinates. In another example, the GPS radio <NUM> may translate the coordinates and provide an address of the location (e.g., the address of the home <NUM> of the employee <NUM>).

In one embodiment, the memory <NUM> may be any type of non-transitory computer readable medium. For example, the memory <NUM> may be a hard disk drive, a solid state drive, a random access memory, a read only memory, and the like. The memory <NUM> may store instructions that are executed by the processor <NUM> to perform the functions described herein. For example, the instructions may cause the processor <NUM> to perform operations of the method <NUM> illustrated in <FIG> or the method <NUM> illustrated in <FIG>, and discussed in further detail below.

In one embodiment, the memory <NUM> may store a local account <NUM> and user customizations <NUM>. In one embodiment, the local account <NUM> may include authorization or authentication information for local authentication by the MFD <NUM> of the employee <NUM>. The local account <NUM> may include a username and password. In one embodiment, the local account <NUM> may include authorizations associated with devices of the employee <NUM>. For example, the local account <NUM> may include authorizations associated with a proximity card, a mobile endpoint device, and the like. The local account <NUM> may include a token or key that is stored in the proximity card or mobile endpoint device. The proximity card or mobile endpoint device can be scanned to read the stored token or key to see if it matches the token or key stored in the local account <NUM> for authentication.

In one embodiment, the user customizations <NUM> may include custom user interface settings, custom workflows, and the like, as described above. In one embodiment, the user customizations <NUM> may be transmitted to the MFD <NUM> from the AS <NUM> after the MFD <NUM> is authorized remotely. In one embodiment, the user customizations <NUM> may be stored in memory <NUM> when the enterprise configures the MFD <NUM> for delivery to the employee <NUM>. The user customizations <NUM> may be locked until the MFD <NUM> is remotely authenticated or authorized. Once authorized, the MFD <NUM> may load the user customizations <NUM>.

<FIG> illustrates a flow chart of an example method <NUM> for authenticating and controlling an enterprise owned MFD at an employee location of the present disclosure. In one embodiment, the method <NUM> may be performed by the apparatus <NUM> or by an apparatus such as the apparatus <NUM> illustrated in <FIG> and discussed below.

In one embodiment, the method <NUM> begins at block <NUM>. At block <NUM>, the method <NUM> detects activation. For example, an employee may receive the enterprise owned MFD at the employee location (e.g., the employee's home) and power on the MFD. The employee may start the operating system software and make the appropriate wireless or wired connections to the communication interface of the MFD. When the MFD is ready for operation and connected to the network, the MFD may detect that it has been powered on or activated and is now ready to start the authentication/authorization process.

At block <NUM>, the method <NUM> transmits a request for authentication of an employee in response to the activation. For example, the MFD may prompt the employee for an enterprise username and password (e.g., a username and password assigned by the enterprise <NUM> to access accounts and/or networks associated with the enterprise <NUM>). The employee may enter his or her enterprise username and password, and the information may be transmitted to an authentication server.

In one embodiment, additional authentication information may be transmitted with the request. For example, the MFD may have a GPS radio that can detect a location of the MFD. The MFD may also transmit GPS location information to confirm that the MFD is at the location it is intended for. For example, transmitting the GPS location information may allow for detection of cases in which the MFD was delivered to a wrong address and an unauthorized user is trying to access use of the MFD, or cases in which the employee has moved the MFD to another location other than the home of the employee.

At block <NUM>, the method <NUM> receives a confirmation of authentication of the employee. For example, the authentication server may match the enterprise username and password and/or any other authentication information that was transmitted with authentication information stored at the authentication server (e.g., a database that stores authentication information for all employees that will be receiving an enterprise owned MFD). If a match is found, the authentication server may send a confirmation of authentication.

In one embodiment, the confirmation may be a control signal from the authentication server <NUM> that unlocks the MFD for use. For example, the MFD may be unusable until the control signal is received from the authentication server <NUM> in response to authenticating the employee that received the MFD.

At block <NUM>, the method <NUM> creates a local account of the employee for local authentication. In one embodiment, the MFD may prompt the employee to create a local account on the MFD. The local account may allow the MFD to perform local authentication after the initial authentication with the authentication server is performed.

The local account may also allow the employee to customize how the employee would like to perform the local authentication. For example, the local account may be set up to enter a username and password. In another example, the local account may be set up to allow the employee to scan a proximity card or provide a token or key from a mobile endpoint device, and the like.

In one embodiment, when the MFD is authenticated, the MFD may also be configured with customizations associated with the employee. As described above, the employee may have user customizations such as a customized user interface, customized workflows, and the like. The user customizations may be pre-loaded in memory or transmitted from the authentication server as part of the authentication notification.

At block <NUM>, the method <NUM> authorizes access of an enterprise owned MFD to the employee via the local account of the employee until a re-activation timer expires. As described above, the MFD may include a re-activation timer and a de-activation timer. The re-activation timer may be started when the MFD is activated and authenticated. The employee may access the enterprise owned MFD until the re-activation timer expires.

If the re-activation timer expires, the employee may be required to re-authenticate the MFD. The employee may request additional time from the enterprise as part of the re-authentication process. The enterprise may then instruct the authentication server to transmit a control signal to the MFD to restart the re-activation timer.

In one embodiment, when the re-activation timer expires, the de-activation timer may begin to count down. The de-activation timer may provide a time limit to require the employee to perform the re-authentication process. If the de-activation timer expires, the MFD may be deactivated. If the user begins the re-authentication process, the de-activation timer may be reset.

If additional time is not granted to the employee, the MFD may delete all local accounts of the employee, delete all customized settings, and transmit a notification to the authentication server to schedule a pick-up of the enterprise owned MFD from the remote location of the employee (e.g., the home of the employee). The enterprise owned MFD may then deactivate itself until it is returned to the enterprise for re-configuration to be sent to another employee. At block <NUM>, the method <NUM> ends.

<FIG> illustrates a more detailed flow chart for a method <NUM> of authenticating and controlling an enterprise owned MFD at an employee location of the present disclosure. In one embodiment, the method <NUM> may be performed by the apparatus <NUM> or by an apparatus such as the apparatus <NUM> illustrated in <FIG> and discussed below.

In one embodiment, the method <NUM> begins at block <NUM>. At block <NUM>, the method <NUM> configures the enterprise owned MFD. For example, the enterprise may assign the MFD to be delivered to a particular employee at the home address of the employee. The enterprise may load a configuration file to enable the MFD to perform the remote authentication and perform the local self-management. The enterprise may also install a de-activation timer on the MFD and set the de-activation timer for the desired amount of time. The MFD may also be modified with a GPS radio to collect location information to confirm that the MFD has been delivered to the home address of the employee.

At block <NUM>, the enterprise owned MFD may be shipped to the employee location. For example, the employee location may be the home of the employee that is located remotely from the office location of the enterprise.

At block <NUM>, the employee may activate and authenticate the MFD once the MFD is delivered to the employee. For example, the employee may power on the MFD, execute the operating system software, make the wired or wireless connections to endpoint devices, the authentication server for authentication, and the like.

After the MFD is activated, the MFD may prompt the employee for the enterprise username and password. The employee may enter the enterprise username and password to be transmitted to the authentication server for authentication.

In one embodiment, the MFD may also transmit GPS location information obtained by the GPS radio or from the mobile endpoint device of the employee. The GPS location information may be transmitted to ensure that the GPS location information matches the stored GPS location information for the home address of the employee.

If the employee is authenticated, the authentication server may transmit a notification to the MFD that the employee is authenticated. The notification may also include an activation control signal to allow the MFD to operate.

At block <NUM>, the MFD may start the re-activation timer. At block <NUM>, the MFD may prompt the user to create a local account of the employee. As described above, the local account may allow the employee to customize how the employee would like to perform the local authentication. For example, the local account may simply be a local username and password or may store an authorization associated with a proximity card, a mobile endpoint device, and the like.

At block <NUM>, the MFD may be ready for use and the MFD may receive a local authentication request. For example, the employee may provide the local authentication information to execute a job. The MFD may authenticate the employee locally without having to communicate with the authentication server.

At block <NUM>, if the user is not authenticated, the method <NUM> may proceed to block <NUM>. For example, an unauthorized family member may be trying to access the MFD for personal use. At block <NUM>, the MFD may deny access.

However, if the user is authenticated, the method <NUM> may proceed to block <NUM>. At block <NUM>, the method <NUM> may provide access to the MFD. The employee may select the desired functions or workflows to execute the desired number of jobs. In one embodiment, usage information may be collected by the MFD to track the usage of the MFD by the employee. The usage information may be transmitted back to the authentication server and analyzed by the enterprise.

In some instances, if the MFD is being underutilized, the enterprise may suggest that the employee return the MFD. For example, it may be cheaper to simply reimburse the employee to go to a local vendor to pay per use of another MFD, or the enterprise may determine another employee has a greater need for the MFD, and so forth.

At block <NUM>, the MFD determines if the re-activation timer has expired. If the re-activation timer has expired, the method <NUM> may proceed to block <NUM> where access is denied. If the re-activation timer has not expired, then the method <NUM> may return to block <NUM> and continue to allow the employee access to the MFD.

At block <NUM>, the MFD determines if the de-activation timer has expired. For example, the de-activation timer may have expired if the employee did not perform the re-authentication before the de-activation timer expired. If the answer to block <NUM> is no, the method <NUM> may return to block <NUM>. The user may perform re-authentication of the MFD with the remote server and request additional time with the MFD.

If the answer to block <NUM> is yes, then the method <NUM> may proceed to block <NUM>. For example, the re-activation timer and the de-activation timer may have expired, indicating that the employee is not using the MFD <NUM> or not using the MFD <NUM> regularly. At block <NUM>, the MFD may delete all local accounts of the employee. The MFD may also delete any user customizations that were loaded on to the MFD.

At block <NUM>, the MFD transmits a notification for pick-up. For example, the notification may be sent to the authentication server to schedule a pick-up at the home address of the employee where the MFD was delivered.

At block <NUM>, the MFD may be de-activated. For example, the MFD may deactivate itself until the enterprise receives the MFD. The enterprise may then activate the MFD and reconfigure the MFD to be delivered to another employee. At block <NUM>, the method <NUM> ends.

Thus, the present disclosure allows an enterprise to modify an enterprise owned MFD to be used at a remote location (e.g., a home of an employee). The enterprise owned MFD may be remotely authenticated, and account management may be performed locally. The account management may prevent users other than the employee from accessing the enterprise owned MFD. In addition, the enterprise owned MFD may be modified to limit an amount of time that the MFD is at the remote location and to ensure that the enterprise owned MFD is picked up and returned back to the enterprise after a predefined amount of time tracked by the de-activation timer. As a result, enterprises are provided with a way to control use of enterprise owned MFDs that are provided to employees who may be working remotely.

<FIG> depicts a high-level block diagram of a computer that is dedicated to perform the functions described herein. As depicted in <FIG>, the computer <NUM> comprises one or more hardware processor elements <NUM> (e.g., a central processing unit (CPU), a microprocessor, or a multi-core processor), a memory <NUM>, e.g., random access memory (RAM) and/or read only memory (ROM), a module <NUM> for authenticating and controlling an enterprise owned MFD at an employee location, and various input/output devices <NUM> (e.g., storage devices, including but not limited to, a tape drive, a floppy drive, a hard disk drive or a compact disk drive, a receiver, a transmitter, a speaker, a display, a speech synthesizer, an output port, an input port and a user input device (such as a keyboard, a keypad, a mouse, a microphone and the like)). Although only one processor element is shown, it should be noted that the computer may employ a plurality of processor elements.

It should be noted that the present disclosure can be implemented in software and/or in a combination of software and hardware, e.g., using application specific integrated circuits (ASIC), a programmable logic array (PLA), including a field-programmable gate array (FPGA), or a state machine deployed on a hardware device, a computer or any other hardware equivalents, e.g., computer readable instructions pertaining to the method(s) discussed above can be used to configure a hardware processor to perform the steps, functions and/or operations of the above disclosed methods. In one embodiment, instructions and data for the present module or process <NUM> for authenticating and controlling an enterprise owned MFD at an employee location (e.g., a software program comprising computer-executable instructions) can be loaded into memory <NUM> and executed by hardware processor element <NUM> to implement the steps, functions or operations as discussed above. Furthermore, when a hardware processor executes instructions to perform "operations," this could include the hardware processor performing the operations directly and/or facilitating, directing, or cooperating with another hardware device or component (e.g., a co-processor and the like) to perform the operations.

The processor executing the computer readable or software instructions relating to the above described method(s) can be perceived as a programmed processor or a specialized processor. As such, the present module <NUM> for authenticating and controlling an enterprise owned MFD at an employee location (including associated data structures) of the present disclosure can be stored on a tangible or physical (broadly non-transitory) computer-readable storage device or medium, e.g., volatile memory, nonvolatile memory, ROM memory, RAM memory, magnetic or optical drive, device or diskette and the like. More specifically, the computer-readable storage device may comprise any physical devices that provide the ability to store information such as data and/or instructions to be accessed by a processor or a computing device such as a computer or an application server.

Claim 1:
An enterprise owned multi-function device (<NUM>), MFD, comprising:
a communication interface (<NUM>) to establish a communication session with an authentication server (<NUM>);
a re-activation timer (<NUM>);
a de-activation timer (<NUM>), that begins when the re-activation timer expires;
a processor (<NUM>); and
a non-transitory computer readable medium (<NUM>) storing instructions which, when executed by the processor, cause the processor to:
authenticate the enterprise owned MFD over the communication session when the enterprise owned MFD is activated at a remote location of an employee;
create a local account of the employee for local authentication;
authorize access to the employee via the local account of the employee until the re-activation timer expires;
determine an expiration of the de-activation timer;
delete the local account of the employee from the enterprise owned MFD in response to the expiration of the de-activation timer; and
transmit a notification to the authentication server to schedule a pick-up of the enterprise owned MFD from the remote location of the employee.