DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 2-7 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hall et al US 2008/0120716 (IDS filed on 09/26/2024).
As per claim 2. Hall discloses a system for providing security for a device on retail display (0029 Subscriber device 110 comprises a processor 200 and a display 250), the system comprising:
a memory on which security monitoring instructions are stored (0029 Subscriber device 110.sub.1 comprises a processor 200 coupled to a chipset 210. Chipset 210 controls the flow of information between processor 200, a main memory 220 ) ; and a processor configured to execute the security monitoring instructions to implement a security monitoring service for the device ( 0029 Subscriber device 110.sub.1 comprises a processor 200 coupled to a chipset 210. Chipset 210 controls the flow of information between processor 200, a main memory 220 and 0068 the security manager monitors the current state of the subscriber device);
wherein the processor is further configured via execution of the security monitoring instructions to –
send a request to the device that the device send a check-in message to the processor, the check-in message being indicative of whether security instructions are being executed on the device (0046 subscriber to sign in, i.e. request to the subscriber device, i.e. the device , manage his/her account and submit instructions for security manager 290, i.e. the processor of the subscriber device, that has entered into the “Auto-lock State”, i.e. security instruction. And 0064 the security manager of the subscriber device, i.e. the device, may use the APIs to query hardware states/event, i.e. the check in message, the hardware processor received the check message from the subscriber device and fig.6, 0063 a determination is made whether an event (local or remote) has occurred to cause subscriber device 110.sub.1 of FIG. 1 to enter into the Auto-Lock state.);
receive the check-in message from the device ( 0064 the security manager of the subscriber device, i.e. the device , may use the APIs to query hardware states/event, i.e. the check in message, the hardware processor received the check message from the subscriber device, fig.7, numeral 710, checking that the “ has event occurred to trigger “Auto-lock STATE”, i.e. the check in message);
determine whether time elapsed since the check-in message was received exceeds a threshold ( fig.6, numeral 720, 0064-0065 a consumer may choose to activate, i.e. check-in message, the "Auto-Lock" scenario by clicking the "Auto-Lock" radio button under the Activate column and confirming that this scenario change event should be communicated to subscriber device 110.sub.1.[0065] If no events have occurred to cause the subscriber device to enter into the Auto-Lock state, the security component / manager waits, i.e. determined, a predetermined period of time or waits indefinitely until another triggering event has occurred, wherein the security component determined time elapsed has passed the predetermined time for other events, if there were not any event has occurred after the time elapsed form the user, the security manager execute the Auto-lock state. ); and
upon determining that the time elapsed exceeds the threshold, send a command to automatically cause the device to enter into a locked state (fig.6 0050 subscription process for Auto-Lock security and the auto-lock mechanism is adapted to detect signaling from a remote source that may cause subscriber device 110.sub.1 to enter into the Auto-Lock state and 0058 These instructions are carried out by the auto-locking agent in order to disable access to certain components, display messages, delete files or the like when the security manager detects a local or remote event. 0063 a determination is made whether an event (local or remote) has occurred to cause, i.e. sending command, subscriber device 110, i.e. the device, of FIG. 1 to enter into the Auto-Lock state.).
As per claim 3. Hall discloses The system of claim 2, wherein the check-in message is configured as a supervised mode communication used to deliver a command to the device to enter the locked state ( [0047] The enterprise web portal 440 provides access for enterprise administrators, i.e. supervised mode communication, to add/remove subscribers and to activate or deactivate first device 110.sub.1 from the Auto-Lock state. Each enterprise administrator will automatically receive emails with his or her account information and uniform resource locator (URL) to the enterprise web portal 440. Enterprise web portal 440 then gives these administrators full control of the security services for their users.).
As per clam 4. Hall discloses the system of claim 2, wherein the processor is further configured to: receive data indicative of whether a security trigger event has occurred in connection with the device ( 0017 Local and remote events may be reference generically as an "event" or a "triggering event" to the subscriber device. ); and send a command to automatically cause the device to enter into the locked state upon determining that the check-in message is not received within a predetermined time period ( fig.6, numeral 720, 0064-0065 a consumer may choose to activate, i.e. check-in message, the "Auto-Lock" scenario by clicking the "Auto-Lock" radio button under the Activate column and confirming that this scenario change event should be communicated to subscriber device 110.sub.1.[0065] If no events have occurred to cause the subscriber device to enter into the Auto-Lock state, the security component waits a predetermined period of time or waits indefinitely until another triggering event has occurred, wherein the security component determined time elapsed has passed the predetermined time for other events, if there were not any event has occurred after the time elapsed form the user, the security manager execute the Auto-lock state).
As per claim 5. Hall discloses the system of claim 4, wherein the processor is further configured to: send, in response to receiving the data, a command to lock all devices at a retail location at which the device is located (0017] Embodiments of the invention set forth in the following detailed description generally relate to a system, software and method for enhancing security of an electronic device by its placement into an "Auto-Lock" state. The electronic device is implemented with a security component that places the device into the Auto-Lock state in response to local events. In addition, the electronic device may be placed into the Auto-Lock state in response to signaling from an external source (i.e., a remote event). 0072 the security manager detects suspicious activity that triggers (signals) subscriber device 110.sub.1 to enter into the Auto-Lock state (800) ).
As per claim 6. Hall discloses the system of claim 4, wherein the security instructions are being executed on the device in a non-persistent application (0049 Such communications may be established by subscriber accessing the storefront web service interface of security subnet 120).
As per claim 7. Hall discloses the system of claim 4, wherein the command is sent to the device (0072 the security manager detects suspicious activity that triggers (signals) subscriber device 110.sub.1 to enter into the Auto-Lock state (800).).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 8-21 are rejected under 35 U.S.C. 103 as being unpatentable over Mahaffey et al US 2014/0373184 in view of Hall et al US 2008/0120716 (IDS filed on 09/26/2024).
As per claim 8. Mahaffey discloses A system for providing security for a device on retail display, the system comprising: a watchdog server (0078 security mechanism provides for a preloaded app and reactivation via server , i.e. a watch dog sever and 0129 This approach can be implemented by a part of the operating system, or by a "watchdog" program that listens to or intercepts a wipe command and performs the security program installation just in time) computer comprising: a memory on which security monitoring instructions are stored; and a processor configured to execute the security monitoring instructions to implement a security monitoring service for the device; and a mobile device management (MDM) server configured to communicate with the device ( 0080 this device with a security program/app, i.e. mobile device, when the device was first registered with the serve and the unique identifier can be generated by the server and communicated to the device), wherein the processor of the watchdog server computer (0078 security mechanism provides for a preloaded app and reactivation via server , i.e. a watch dog sever )is further configured via execution of the security monitoring instructions to –
send a request to the device that the device send a check-in message to the processor, the check-in message being indicative of whether security instructions are being executed on the device ( 0081 the security app of the device/mobile device, can consider the device as being "stolen" if a configurable amount of time has elapsed with no successful communication with the server, i.e. the processor , as indicated by the value in the file. For example, the frequency of communication check-ins, i.e. check-in message, with the server, i.e. the processor, can be configured as once an hour, once a day, once every other day, once a week , i.e. time elapsed, and so forth);
receive the check-in message from the device ( 0081 the frequency of communication check-ins, i.e. check-in message, with the server, i.e. the processor, wherein the processor is receiving the check-in message frequently);
determine the mobile device based on an ID ( 0090] The content of the communication depends on the result of the server's check, i.e. determine, of the device ID against the registry);
upon determining of the device, direct the MDM server to send a MDM communication to the device to automatically cause the device to enter into a locked state (0090 if the mobile device was reported as stolen, the sever communicates that includes a command to lock the mobile device).
Mahaffey does not explicitly disclose
determine whether time elapsed since the check-in message was received exceeds a threshold; and
upon determining that the time elapsed exceeds the threshold, send a command to the device to automatically cause the device to enter into a locked state (emphasis added on underlined).
However, Hall discloses determine whether time elapsed since the check-in message was received exceeds a threshold ( fig.6, numeral 720, 0064-0065 a consumer may choose to activate, i.e. check-in message, the "Auto-Lock" scenario by clicking the "Auto-Lock" radio button under the Activate column and confirming that this scenario change event should be communicated to subscriber device 110.sub.1.[0065] If no events have occurred to cause the subscriber device to enter into the Auto-Lock state, the security component waits a predetermined period of time or waits indefinitely until another triggering event has occurred, wherein the security component determined time elapsed has passed the predetermined time for other events, if there were not any event has occurred after the time elapsed form the user, the security manager execute the Auto-lock state); and
upon determining that the time elapsed exceeds the threshold, send a command to automatically cause the device to enter into a locked state (fig.6 0050 subscription process for Auto-Lock security and the auto-lock mechanism is adapted to detect signaling from a remote source that may cause subscriber device 110.sub.1 to enter into the Auto-Lock state and 0058 These instructions are carried out by the auto-locking agent in order to disable access to certain components, display messages, delete files or the like when the security manager detects a local or remote event. 0063 a determination is made whether an event (local or remote) has occurred to cause, i.e. sending command, subscriber device 110, i.e. the device, of FIG. 1 to enter into the Auto-Lock state.).
Mahaffey and Hall are both considered to be analogous to the claimed invention because they are in the same field of locking the device. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Mahaffey to incorporate the teachings of Hall and provide locking the device based on the response elapsed time. Doing so would able to protect stored data and/or hinder unauthorized usage of the device (par 00202). thereby reducing risk of data spoofing.
As per claim 9. Mahaffey and Hall discloses The system of claim 8, wherein the MDM server is directed by the processor, via an application programming interface (API) call to the MDM server (Mahaffey discloses 0012 a mobile communications device that has been reported as missing or stolen has communicated with the server, i.e. MDM server, and Hall 0064 the security manager may use the APIs to query hardware states. Optionally, if supporting remote placement of the subscriber device into the Auto-Lock state, the security manager may detect certain events (triggering events) from a remote source or receive signal from another component that detected or received instructions from the remote source.).
As per claim 10. Mahaffey and Hall discloses The system of claim 8, wherein the MDM server is configured to send a supervised mode communication to the device to restart a security application on the device (Mahaffey 0078 security mechanism provides for a preloaded app and reactivation via server , i.e. a watch dog sever and 0129 This approach can be implemented by a part of the operating system, or by a "watchdog" program that listens to or intercepts a wipe command and performs the security program installation just in time ).
As per claim 11. Mahaffey and Hall discloses The system of claim 10, wherein the check-in message is configured as supervised mode communication ( Mahaffey 0081 the frequency of communication check-ins, i.e. check-in message, with the server, i.e. the processor, wherein the processor is receiving the check-in message frequently).
As per claim 12. Mahaffey and Hall discloses The system of claim 8, further comprising a device enrollment program (DEP) server configured to establish supervision by the MDM server computer ( Mahaffey discloses 0012 a mobile communications device that has been reported as missing or stolen has communicated with the server, i.e. MDM server, and Hall [0066] Hence, the security component would commence a timing cycle and halt the timing cycle if the user is authenticated. For instance, according to one embodiment of the invention, the security component provides a user authentication mechanism such as a user interface (e.g., dialog box) that prompts the user to enter his or her credentials (e.g., password, employee number, etc.). Another user authentication mechanism may involve activation of Bluetooth.RTM. transceiver logic and confirmation that a Bluetooth.RTM. compatible device owned by the user or registered with the security component is in the immediate vicinity of the subscriber device.).
As per claim 13. Mahaffey and Hall discloses The system of claim 12, wherein the DEP server has a DEP account in which the device is associated with the MDM server computer (Mahaffey discloses 0012 a mobile communications device that has been reported as missing or stolen has communicated with the server, i.e. MDM server, and Hall [0067] If the subscriber is authenticated, the process returns to wait for another triggering event. If the subscriber was notified of the event but failed to authenticate himself or herself, the auto-locking agent causes the subscriber device to enter into the Auto-Lock state by logging off any currently logged-in users, disabling the normal account(s) and enabling a secure auto-lock account during the Auto-Lock state (block 730). ).
As per claim 14. Mahaffey and Hall discloses The system of claim 12, wherein the DEP server is configured to receive a query from the device to determine whether the device is enrolled in a supervision program (Hall [0066] Hence, the security component would commence a timing cycle and halt the timing cycle if the user is authenticated. For instance, according to one embodiment of the invention, the security component provides a user authentication mechanism such as a user interface (e.g., dialog box) that prompts the user to enter his or her credentials (e.g., password, employee number, etc.). Another user authentication mechanism may involve activation of Bluetooth.RTM. transceiver logic and confirmation that a Bluetooth.RTM. compatible device owned by the user or registered with the security component is in the immediate vicinity of the subscriber device. ).
As per claim 15. Mahaffey and Hall discloses The system of claim 8, wherein the locked state is an operational mode of an application defined by the security instructions in which the application causes the device to run in a single-application mode (Hall [0027] In addition, as shown in FIG. 1, subscriber device 110.sub.1 is in communication with a security subnet 120 that includes a security server 150. According to one embodiment of the invention, security server 150 operates as a back-end server for a subscription service that is provided to enhance device security by downloading security software or activating a preloaded security component that is responsible for determining and placing subscriber device 110.sub.1 into the Auto-Lock state as needed. ).
As per claim 16. Mahaffey and Hall discloses The system of claim 8, further comprising a management computer configured to send a further command to lock or unlock the device, and a command to lock all devices at a retail location at which the device is located ( Hall [0024] A "remote event" is an action by the subscriber or an agent of the subscriber that requests placement of the subscriber device into the Auto-Lock state. Such placement may be in response to a lack of physical access to the subscriber device, which may have been caused by theft, loss or misplacement.).
As per claim 17. Mahaffey and Hall discloses The system of claim 16, wherein the management computer is further configured to provide a remote user interface to manually lock, unlock, and monitor a status of the device (Hall 0017 enhancing security of an electronic device by its placement into an "Auto-Lock" state. The electronic device is implemented with a security component that places the device into the Auto-Lock state in response to local events. In addition, the electronic device may be placed into the Auto-Lock state in response to signaling from an external source (i.e., a remote event). Local and remote events may be reference generically as an "event" or a "triggering event". ).
As per claim 18. Mahaffey and Hall discloses The system of claim 16, wherein the management computer is further configured to communicate through API calls to the MDM server and the watchdog server computer ( Hall Hall 0064 the security manager may use the APIs to query hardware states. Optionally, if supporting remote placement of the subscriber device into the Auto-Lock state, the security manager may detect certain events (triggering events) from a remote source or receive signal from another component that detected or received instructions from the remote source ).
As per claim 19. Mahaffey and Hall discloses The system of claim 18, wherein the management computer is further configured to use the API calls to direct the device to enter into the locked state( Mahaffey discloses 0012 a mobile communications device that has been reported as missing or stolen has communicated with the server, i.e. MDM server, and Hall 0064 the security manager may use the APIs to query hardware states. Optionally, if supporting remote placement of the subscriber device into the Auto-Lock state, the security manager may detect certain events (triggering events) from a remote source or receive signal from another component that detected or received instructions from the remote source).
As per claim 20. Mahaffey and Hall discloses The system of claim 16, wherein the management computer is further configured to issue a storewide locking of all devices within a respective retail location(Hall 0067 0067] If the subscriber is authenticated, the process returns to wait for another triggering event. If the subscriber was notified of the event but failed to authenticate himself or herself, the auto-locking agent causes the subscriber device to enter into the Auto-Lock state by logging off any currently logged-in users, disabling the normal account(s) and enabling a secure auto-lock account during the Auto-Lock state (block 730). ).
As per claim 21. Mahaffey and Hall discloses The system of claim 16, wherein the management computer is further configured to generate a user interface with a list of monitored devices (Hall 0068] After the auto-locking account has been activated and the normal accounts have been disabled, as an optional feature shown in block 735, the user is provided with a prescribed amount of time to authenticate himself or herself based on the subscriber service username and password before performing actions based on the triggering event. If the subscriber failed to authenticate himself or herself, certain actions are performed based on the triggering event (block 740). After these actions have been performed, the security manager monitors the current state of the subscriber device and determines whether access to the normal account is permitted (block 750) ).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, JORGE ORTIZ CRIADO can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ABU S SHOLEMAN/Primary Examiner, Art Unit 2496
Prosecution Insights