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 .
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 3/9/2026 has been entered.
As per instant Amendment, claims 1, 14, 19, and 27 have been amended; claims 1, 14 and 27 are independent claims. Claims 1-30 have been examined and are pending. This Action is made Non-Final.
The examiner notes the IDS filed on 2/19/2026 has been considered.
Response to Arguments
The Claim Objection to claim 1 has been withdrawn as the claim has been amended.
The rejection of claims 1-13 under 35 U.S.C. 112(b) are withdrawn as the claims have been amended.
Applicant's arguments filed 3/9/2026 with respect to the 35 U.S.C. 103 rejection have been fully considered but are not persuasive and/or moot in view of the new ground(s) of rejection.
Re: Claim 1 and/or 14
Applicant Argues: [...]Accordingly, Jain fails to teach or suggest transmitting a context state relating to an activity between co-provisioned peer devices registered with a server.
Examiner’s Response: The examiner respectfully notes this argument is moot in view of new grounds of rejection.
Applicant Argues: “In Baek, the authentication flow operates as follows: Device 1000 receives a terminal verification code that is output from the target device 1005, then relays that code to the account server 1010, and the server responds with a logout key. In other words, the credential that Device 1000 sends to the server originates from the target device. Device 1000 is merely a relay or conduit for the target device's own verification code.
The amended claims require the associated device to transmit its own pass key, one that was provisioned to that device during the co-provisioning process, to the server in association with a log-off request. The server then validates that pass key against the credentials it issued during provisioning and returns a pass key authentication to the associated device. This is the associated device's own credential being validated, not a code relayed from the target. The server is confirming that the requesting device is authorized to act on the target device, not merely processing a code that the target device generated.
Additionally, the amended claims tie the log off request to the context state of the target device. The associated device initiates the log-off sequence in response to receiving a context state indicating a security risk (such as inactivity, loss of proximity, or a scheduled log-off condition).
Baek contains no teaching or suggestion of any context-state exchange between the devices that would trigger the log-off sequence. In Baek, the remote logout is initiated by a deliberate user action. The user on Device 1000 affirmatively decides to log out the target device. There is no monitoring of the target device's ongoing activity state, no broadcast of context information between co-provisioned peer devices, and no automated or context-driven security response. Reconsideration and withdrawal of the § 103 rejection are respectfully requested”
Examiner’s Response: The examiner respectfully disagrees. Beak discusses that the logout key is transmitted to electronic device 1000, in [0193]. The examiner further notes that key electronic device 1000 transmits the logout key to target device 1005, in [0195]. Logout processing is then performed at the target device based on the logout key in [0196]. The examiner notes this reads on the claim lanague as [receiving from the associated device] a log off request, the log off request [including a passkey authentication] validated by the server in response to a request from the associated device and associated with [a] context state ([0193] and [0195]) logging off an operating system associated with the wireless communication device in response to receiving the log off request, including the pass key authentication ([0195]-[0196]). Further, in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., The associated device initiates the log-off sequence in response to receiving a context state indicating a security risk (such as inactivity, loss of proximity, or a scheduled log-off condition)) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. Thus, the context state can be reasonably construed to be in Beak FIG. 9 – logged in with user account. Therefore, the examiner finds this argument not permissive.
Further, The examiner respectfully notes that Alduaiji is shown to teach “any context-state exchange between the devices that would trigger the log-off sequence”, see Alduaiji ([0063] - At S1118, the server 50 transmits a notification to the second computer device 30 when the type of the personal account A is the specific type of account to control the login status (e.g., bank account, company intranet) and the distance between the first computer device 20 and the second computer device 30 exceeds the predetermined distance. This notification may include a text message, such as "May the first computer device 20 logoff the personal account A?" inquiring a permission to logoff the personal account A). Therefore, the examiner finds this argument not persuasive.
Re: Claim 27
Applicant Argues: Mahaffey teaches a server-managed remote device control system where a user authenticates directly to a server using credentials such as a username, password, or biometric data, and the server then issues remote commands (lock, wipe, locate) to a target device. This is a user- to-server authentication model, not a device-to-server pass key validation model. The pass key in Mahaffey, to the extent it can be characterized as such, is a user's login credential presented to gain access to server functionality. It is not a device-specific pass key provisioned to one peer device and subsequently presented back to the server by that device to obtain authorization to alter the state of another peer device.
Jain does not remedy this deficiency. Jain's contribution to the combination, as mapped by the Office Action, relates to proximity-based biometric authentication for communal device access. Jain does not teach a server that provisions two peer devices with a shared pass key framework, receives that pass key back from one device in the context of a log-off request for the other, validates the pass key, and returns an authentication authorizing the requesting device to log off the target. Jain's server (the cloud-based provider) facilitates biometric identity matching for accessing a communal device. It does not perform the pass key provisioning, validation, and authentication cycle recited in Claim 27.
The amended claim further requires that the log-off request be associated with a context state of the second device that relates to an activity of the second device and that the second device is proximate to the first. Neither Mahaffey nor Jain teaches a server that processes log-off requests tied to context-state information exchanged between co-provisioned proximate peer devices. Reconsideration and withdrawal of the § 103 rejection are respectfully requested.
Examiner’s Response: Further, in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., . It is not a device-specific pass key provisioned to one peer device and subsequently presented back to the server by that device to obtain authorization to alter the state of another peer device) are not recited in the rejected claim(s). The examiner respectfully notes as currently claimed there is no recitation of a device specific pass key. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims.
The examiner respectfully notes this argument towards Jain are moot in view of new grounds of rejection.
Therefore, the examiner finds this argument not permissive.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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) 1-4, 8-17, and 21-26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mahaffey et al. (US 2010/0210240 A1) in view of Alduaiji (US 2015/0067803 A1) and Baek (US 2024/019300 A1).
Regarding Claim 1;
Mahaffey discloses a method for wireless communication performable at a wireless communication device, comprising:
transmitting a context state of the wireless communication device to an associated device ([0035] - In an embodiment, an application or widget loaded on the client computer is used to present a user interface to the user. The user interface may provide some or all of the functionality provided by the web page displayed on the client computer. The application or widget contains presentation logic and communicates with the server via an API... For example, the information requested by the application or widget and returned by the server may contain data such as: a list of devices accessible by the user, status information relating to a device, or a list of devices in a group managed by the user that are determined to be lost or stolen. The application or widget may also send a request to the server to perform actions on a device, change settings relating to a device, or access any other functionality provided by the server and [0036] - Some of the remote access controls include locating the mobile device 101 by providing the location of the mobile device 101 on a map, making the mobile device 101 play a sound, backing up the data on the mobile device 101, locking or unlocking the mobile device 101, monitoring audio or video near from the mobile device 101, monitoring any actions taken on the mobile device 101, and wiping any memory in the mobile device 101);
receiving, from the associated device, a [lock] request, the [lock] request including a pass key authentication... ([0035] - In an embodiment, an application or widget loaded on the client computer is used to present a user interface to the user. The user interface may provide some or all of the functionality provided by the web page displayed on the client computer. The application or widget contains presentation logic and communicates with the server via an API... For example, the information requested by the application or widget and returned by the server may contain data such as: a list of devices accessible by the user, status information relating to a device, or a list of devices in a group managed by the user that are determined to be lost or stolen. The application or widget may also send a request to the server to perform actions on a device, change settings relating to a device, or access any other functionality provided by the server and [0036] - The server 111 may require authentication information such as a user name, password, biometric data, or other security-related information. If the user is authorized, the server 111 retrieves previously stored information about the mobile device 101 for which remote access is sought... Some of the remote access controls include locating the mobile device 101 by providing the location of the mobile device 101 on a map, making the mobile device 101 play a sound, backing up the data on the mobile device 101, locking or unlocking the mobile device 101, monitoring audio or video near from the mobile device 101, monitoring any actions taken on the mobile device 101, and wiping any memory in the mobile device 101 and [0114]); and
[locking] the wireless communication device ([0035] - In an embodiment, an application or widget loaded on the client computer is used to present a user interface to the user. The user interface may provide some or all of the functionality provided by the web page displayed on the client computer. The application or widget contains presentation logic and communicates with the server via an API... For example, the information requested by the application or widget and returned by the server may contain data such as: a list of devices accessible by the user, status information relating to a device, or a list of devices in a group managed by the user that are determined to be lost or stolen. The application or widget may also send a request to the server to perform actions on a device, change settings relating to a device, or access any other functionality provided by the server and [0036] - The server 111 may require authentication information such as a user name, password, biometric data, or other security-related information. If the user is authorized, the server 111 retrieves previously stored information about the mobile device 101 for which remote access is sought... Some of the remote access controls include locating the mobile device 101 by providing the location of the mobile device 101 on a map, making the mobile device 101 play a sound, backing up the data on the mobile device 101, locking or unlocking the mobile device 101, monitoring audio or video near from the mobile device 101, monitoring any actions taken on the mobile device 101, and wiping any memory in the mobile device 10 and [0087]).
Mahaffey fails to explicitly disclose:
... the wireless communication device and the associated device being co-provisioned on a server as a part of a list of user devices associated with a user and the associated device being proximate to the wireless communication device, wherein the context relates to an activity associated with the wireless communication device.
[receiving from the associated device] a log off request, the log off request [including a passkey authentication] validated by the server in response to a request from the associated device and associated with the context state; and
logging off an operating system associated with the wireless communication device in response to receiving the log off request including the pass key authentication.
However, in an analogous art, Alduaiji teaches
...the wireless communication device and the associated device being co-provisioned on a server as a part of a list of user devices associated with a user and the associated device being proximate to the wireless communication device ([0020] – the user may preregister the address where it is located to the first computer device 20 and [0033] - A user may preregister the contact information of the second computer device 30 (e.g., the user's smartphone or tablet computer) to the server 50 and [0060]-[0061] and [0062] - At S1116 the server 500 analyzes distance between the first computer device 20 and the second computer device 30 based on the received location information), wherein the context relates to an activity associated with the wireless communication device ([0061] - Then, at S1114, the server 50 analyzes the type of the personal account A and judges whether the personal account A is a type of a personal account to control the login status or not. For example, a user may preregister the personal account to control a login status by inputting whether or not the user wants a login status control on the website of personal account A. The server 500 analyzes whether the user preregistered the personal account as an account to control a login status)
[receiving from the associated device] a log off request... validated by the server in response to a request from the associated device and associated with the context state ([0063] - At S1118, the server 50 transmits a notification to the second computer device 30 when the type of the personal account A is the specific type of account to control the login status (e.g., bank account, company intranet) and the distance between the first computer device 20 and the second computer device 30 exceeds the predetermined distance. This notification may include a text message, such as "May the first computer device 20 logoff the personal account A?" inquiring a permission to logoff the personal account A); and
logging off an operating system the wireless communication device in response to receiving the log off request... ([0024] - Stored on any one or on a combination of computer readable medium, the present disclosure includes software for controlling the first computer device 20. Such software may include, but is not limited to, device drivers, operating systems, development tools, and applications software and [0063]-[0065] - At S1122, when the server 50 receives the permission signal from the second computer device 30, the server 50 performs logoff processing. Other steps perform a similar function to those described in FIG. 4.)
A person of ordinary skill in the art would have the technical skills to make the mere substitution and the outcome would be predictable. Mainly, substituting one for the other achieves a predictable result because Alduaiji uses a log off/context in a similar role as Mahaffey’s lock/contact for the wireless communication device. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute log off/context of Alduaiji for lock/context of Mahaffey to arrive at the claimed invention because such a step is known and results of the substitution would have been predictable (i.e., performing log off of the wireless communication device).
However, in an analogous art, Baek teaches:
[receiving from the associated device] a log off request, the log off request [including a passkey authentication] validated by the server in response to a request from the associated device and associated with [a] context state (FIG. 9 – logged in with user account and FIG. 10 and [0192]-[0193] - According to an embodiment, in operation S1045, the electronic device 1000 may receive, from the user 1015, the terminal verification code output from the target device 1005. As described above, the screen displayed by the electronic device 1000 to receive the terminal verification code from the user 1015 may vary according to the remote logout method or the terminal verification code. According to an embodiment, in operation S1050, the electronic device 1000 may transmit the terminal verification code to the account server 1010. In operation S1050, the electronic device 1000 may request the account server 1010 for a logout key); and
logging off an operating system associated with the wireless communication device in response to receiving the log off request, including the pass key authentication (FIG. 10 and [0194]-[0196] - According to an embodiment, in operation S1055, the account server 1010 may transmit the logout key to the electronic device 1000 According to an embodiment, in operation S1060, the electronic device 1000 may request the target device 1005 for remote logout and transmit the received logout key to the target device 1005... The account server 1010 may perform user authorization using the logout key received from the target device 1005 and allow the target device 1005 that is logged in with the user account to be logged out.)
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Beak to the logoff of Mahaffey in view of Alduaiji to include [receiving from the associated device] a log off request, the log off request [including a passkey authentication] validated by the server in response to a request from the associated device and associated with [a] context state; and logging off an operating system associated with the wireless communication device in response to receiving the log off request including the pass key authentication.
One would have been motivated to combine the teachings of Baek to Mahaffey in view of Alduaiji to do so as it provides / allows remote authorization [for] remote logout of target devices (Baek, [0007] and [0015]).
Regarding Claim 2;
Mahaffey in view of Alduaiji and Baek disclose the method to Claim 1.
Alduaiji further teaches wherein the context state relates to login of the operating system associated with the wireless communication device ([0024] - Stored on any one or on a combination of computer readable medium, the present disclosure includes software for controlling the first computer device 20. Such software may include, but is not limited to, device drivers, operating systems, development tools, and applications software. Such computer readable medium further includes the computer program product of the present disclosure for performing all or a portion (if processing is distributed) of the processing performed in implementing the disclosure and [0042] - ...by remotely logging off the first computer device 20 from the personal account A.)
Similar rationale and motivation is noted for the combination of Alduaiji to Mahaffey in view of Alduaiji and Baek, as per claim 1, above.
Regarding Claim 3;
Mahaffey in view of Alduaiji and Baek disclose the method to Claim 1.
Mahaffey further discloses further comprising further comprising: receiving, from the server, a pass key for pass key authentication with the associated device prior to transmitting the context state ([0036] - The server 111 may require authentication information such as a user name, password, biometric data, or other security-related information. Some of the remote access controls include locating the mobile device 101 by providing the location of the mobile device 101 on a map, making the mobile device 101 play a sound, backing up the data on the mobile device 101, locking or unlocking the mobile device 101, monitoring audio or video near from the mobile device 101, monitoring any actions and [0073] and [0114]).
Regarding Claim 4;
Mahaffey in view of Alduaiji and Baek disclose the method to Claim 1.
Mahaffey further discloses wherein the wireless communication device is a type of device selected from a group consisting of a laptop, a smartphone, a tablet, a smart watch, and a smart television (FIG. 1 and [0027] - As used herein, the term "mobile communications device" refers to mobile phones, PDAs and smartphones... However, a person having skill in the art will appreciate that while the present invention is disclosed herein as being used on mobile communications devices, the present invention may also be used on other computing platforms, including desktop, laptop, notebook, netbook or server computers).
Regarding Claim 8;
Mahaffey in view of Alduaiji and Baek disclose the method to Claim 1.
Mahaffey further discloses wherein the context state indicates an activity performed on the wireless communication device ([0035] - For example, the information requested by the application or widget and returned by the server may contain data such as: a list of devices accessible by the user, status information relating to a device, or a list of devices in a group managed by the user that are determined to be lost or stolen and [0037] - In an embodiment, the server 111 can display the communications status, including attempted communications with the mobile device, on the remote access web page 271. If the mobile device is not able to receive or process the command(s), the remote access web page can indicate that communication with the device is being attempted.)
Regarding Claim 9;
Mahaffey in view of Alduaiji and Baek disclose the method to Claim 1.
Mahaffey further discloses wherein the context state includes an indication of an activity performed on the wireless communication device ([0035] - For example, the information requested by the application or widget and returned by the server may contain data such as: a list of devices accessible by the user, status information relating to a device, or a list of devices in a group managed by the user that are determined to be lost or stolen and [0037] - In an embodiment, the server 111 can display the communications status, including attempted communications with the mobile device, on the remote access web page 271. If the mobile device is not able to receive or process the command(s), the remote access web page can indicate that communication with the device is being attempted.)
Regarding Claim 10;
Mahaffey in view of Alduaiji and Baek disclose the method to Claim 1.
Mahaffey further discloses wherein the wireless communication device transmits the context state within a secure network ([0044] - With reference to FIG. 1, specific communication protocols are used between the server 111 and the local software component 175 on the mobile device 101 to facilitate secure communications).
Regarding Claim 11;
Mahaffey in view of Alduaiji and Baek disclose the method to Claim 1.
Mahaffey further discloses further comprising: transmitting the context state via a broadcast using a Bluetooth Low Energy (BLE) transmission ([0030]).
Regarding Claim 12;
Mahaffey in view of Alduaiji and Baek disclose the method to Claim 1.
Mahaffey further discloses further comprising: provisioning the wireless communication device on the server ([0095] - The device migration web page contains a list of existing devices associated with the user's account and gives the user the option of adding a new device. If the user installs software on a new device, the process waits for that device to backup its information to the server before proceeding. After the source device is identified by the server, the server presents, via the device migration web page, an interface for the user to select the destination device 1802. The device migration web page contains a list of existing devices associated with the user's account and gives the user the option of adding a new device. If the user chooses to install software on a new device, the process waits for the new device to become active on the server before proceeding)
Regarding Claim 13;
Mahaffey in view of Alduaiji and Baek disclose the method to Claim 12.
Mahaffey further discloses wherein the provisioning the wireless communication device on the server further comprises: transmitting an identity and security credentials associated with the wireless communication device to the server ([0090] - The backup data command 544 causes the mobile device 101 to transmit some or all of its stored data to the server 111 where it is securely stored in a mobile device backup database. The stored data may include documents, pictures, call history, text messages, videos, audio, notes, internet favorites, contacts, calendar appointments, to do list items, applications, settings, credentials, and other data that may be stored on a mobile device and [0093] and [0095] and [0114] - In order to protect user privacy, the inventive system may be configured so that the local software component 175 on the device 101 only accepts commands from the server that are accompanied with special remote access authentication credentials. In an embodiment with reference to FIG. 16, the server 111 can only generate the remote access authentication credentials in a short period of time with information supplied by the user. The local software component on the device is initially configured with its special remote access authentication credentials. The credentials themselves are not sent to the server. The device generates verification information and a "challenge" token and transmits them to the server 1602); and receiving, from the server, a device identification associated with pass key authentication ([0036] - The server 111 may require authentication information such as a user name, password, biometric data, or other security-related information. If the user is authorized, the server 111 retrieves previously stored information about the mobile device 101 for which remote access is sough);
Regarding Claim 14;
Mahaffey discloses wireless communication device (FIG. 1 and [0029] and [0031]) comprising:
one or more memories that store processor-executable code (FIG. 1 and [0029] and [0031]); and
one or more processors coupled with the one or more memories and individually or collectively configured to, in association with executing the code, cause the wireless communication device to (FIG. 1 and [0029] and [0031]):
receive a context state of an associated device... ([0035] - In an embodiment, an application or widget loaded on the client computer is used to present a user interface to the user. The user interface may provide some or all of the functionality provided by the web page displayed on the client computer. The application or widget contains presentation logic and communicates with the server via an API... For example, the information requested by the application or widget and returned by the server may contain data such as: a list of devices accessible by the user, status information relating to a device, or a list of devices in a group managed by the user that are determined to be lost or stolen. The application or widget may also send a request to the server to perform actions on a device, change settings relating to a device, or access any other functionality provided by the server and [0036]);
transmit, to the server, a pass key associated with a [lock] request, wherein the [lock] request relates to the context state of the associated device ([0035] - In an embodiment, an application or widget loaded on the client computer is used to present a user interface to the user. The user interface may provide some or all of the functionality provided by the web page displayed on the client computer. The application or widget contains presentation logic and communicates with the server via an API... For example, the information requested by the application or widget and returned by the server may contain data such as: a list of devices accessible by the user, status information relating to a device, or a list of devices in a group managed by the user that are determined to be lost or stolen. The application or widget may also send a request to the server to perform actions on a device, change settings relating to a device, or access any other functionality provided by the server and [0036] - The server 111 may require authentication information such as a user name, password, biometric data, or other security-related information. If the user is authorized, the server 111 retrieves previously stored information about the mobile device 101 for which remote access is sought... Some of the remote access controls include locating the mobile device 101 by providing the location of the mobile device 101 on a map, making the mobile device 101 play a sound, backing up the data on the mobile device 101, locking or unlocking the mobile device 101, monitoring audio or video near from the mobile device 101, monitoring any actions taken on the mobile device 101, and wiping any memory in the mobile device 101 and [0114]);
transmit, to the associated device the [lock] request ([0035] - In an embodiment, an application or widget loaded on the client computer is used to present a user interface to the user. The user interface may provide some or all of the functionality provided by the web page displayed on the client computer. The application or widget contains presentation logic and communicates with the server via an API... For example, the information requested by the application or widget and returned by the server may contain data such as: a list of devices accessible by the user, status information relating to a device, or a list of devices in a group managed by the user that are determined to be lost or stolen. The application or widget may also send a request to the server to perform actions on a device, change settings relating to a device, or access any other functionality provided by the server and [0036] - The server 111 may require authentication information such as a user name, password, biometric data, or other security-related information. If the user is authorized, the server 111 retrieves previously stored information about the mobile device 101 for which remote access is sought... Some of the remote access controls include locating the mobile device 101 by providing the location of the mobile device 101 on a map, making the mobile device 101 play a sound, backing up the data on the mobile device 101, locking or unlocking the mobile device 101, monitoring audio or video near from the mobile device 101, monitoring any actions taken on the mobile device 101, and wiping any memory in the mobile device 10 and [0087]).
Mahaffey fails to explicitly disclose:
receive a context state of an associated device, the associated device being proximate to the wireless communication device and co-provisioned with the wireless communication device on a server as part of a list of user devices associated with a user, the context state relating to an activity associated with the associated device;
[transmit, to the server, a pass key associated with] a log off [request, wherein] the log off request [relates to the context state of the associated device];
receive, from the server, in response to the transmit, a pass-key authentication validating the pass key; and
[transmit, to the associated device, the] log off [request] including the pass-key authentication to cause an operating system associated with the associated device to log off.
However, in an analogous art, Alduaiji teaches
receive a context state of an associated device, the associated device being proximate to the wireless communication device and co-provisioned with the wireless communication device on a server as part of a list of user devices associated with a user ([0020] – the user may preregister the address where it is located to the first computer device 20 and [0033] - A user may preregister the contact information of the second computer device 30 (e.g., the user's smartphone or tablet computer) to the server 50 and [0060]-[0061] and [0062] - At S1116 the server 500 analyzes distance between the first computer device 20 and the second computer device 30 based on the received location information), the context state relating to an activity associated with the associated device; ([0061] - Then, at S1114, the server 50 analyzes the type of the personal account A and judges whether the personal account A is a type of a personal account to control the login status or not. For example, a user may preregister the personal account to control a login status by inputting whether or not the user wants a login status control on the website of personal account A. The server 500 analyzes whether the user preregistered the personal account as an account to control a login status)
[transmit, to the associated device, the] log off [request]... to cause an operating system associated with the associated device to log off ([0024] - Stored on any one or on a combination of computer readable medium, the present disclosure includes software for controlling the first computer device 20. Such software may include, but is not limited to, device drivers, operating systems, development tools, and applications software and [0063]-[0065] - At S1122, when the server 50 receives the permission signal from the second computer device 30, the server 50 performs logoff processing. Other steps perform a similar function to those described in FIG. 4.)
A person of ordinary skill in the art would have the technical skills to make the mere substitution and the outcome would be predictable. Mainly, substituting one for the other achieves a predictable result because Alduaiji uses a log off/context in a similar role as Mahaffey’s lock/contact for the wireless communication device. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute log off/context of Alduaiji for lock/context of Mahaffey to arrive at the claimed invention because such a step is known and results of the substitution would have been predictable (i.e., performing log off of the wireless communication device).
However, in an analogous art, Baek teaches:
[transmit, to the server, a pass key associated with] a log off [request, wherein] the log off request [relates to the context state of the associated device] (FIG. 9 – logged in with user account (i.e., as noted context state) and FIG. 10 and [0192]-[0193] - According to an embodiment, in operation S1045, the electronic device 1000 may receive, from the user 1015, the terminal verification code output from the target device 1005. As described above, the screen displayed by the electronic device 1000 to receive the terminal verification code from the user 1015 may vary according to the remote logout method or the terminal verification code. According to an embodiment, in operation S1050, the electronic device 1000 may transmit the terminal verification code to the account server 1010. In operation S1050, the electronic device 1000 may request the account server 1010 for a logout key);
receive, from the server, in response to the transmit, a pass-key authentication validating the pass key (FIG. 9 – logged in with user account (i.e., as noted context state) and FIG. 10 and [0192]-[0194] - According to an embodiment, in operation S1045, the electronic device 1000 may receive, from the user 1015, the terminal verification code output from the target device 1005. As described above, the screen displayed by the electronic device 1000 to receive the terminal verification code from the user 1015 may vary according to the remote logout method or the terminal verification code. According to an embodiment, in operation S1050, the electronic device 1000 may transmit the terminal verification code to the account server 1010. In operation S1050, the electronic device 1000 may request the account server 1010 for a logout key. According to an embodiment, in operation S1055, the account server 1010 may transmit the logout key to the electronic device 1000.); and
[transmit, to the associated device, the] log off [request] including the pass-key authentication to cause an operating system associated with the associated device to log off (FIG. 10 and [0194]-[0196] - According to an embodiment, in operation S1055, the account server 1010 may transmit the logout key to the electronic device 1000 According to an embodiment, in operation S1060, the electronic device 1000 may request the target device 1005 for remote logout and transmit the received logout key to the target device 1005... The account server 1010 may perform user authorization using the logout key received from the target device 1005 and allow the target device 1005 that is logged in with the user account to be logged out.)
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Beak to the logoff of Mahaffey in view of Alduaiji to include [transmit, to the server, a pass key associated with] a log off [request, wherein] the log off request [relates to the context state of the associated device]; receive, from the server, a pass key authentication for the log off request and in response to the transmit of the pass key, a pass-key authentication validating the pass key; and [transmit, to the associated device, the] log off [request] including the pass-key authentication to cause an operating system associated with the associated device to log off
One would have been motivated to combine the teachings of Baek to Mahaffey in view of Alduaiji to do so as it provides / allows remote authorization [for] remote logout of target devices (Baek, [0007] and [0015]).
Regarding Claim(s) 14-17 and 21-26; claim(s) 14-17 and 21-26 is/are directed to a/an device associated with the method claimed in claim(s) 2-4 and 8-13. Claim(s) 14-17 and 21-26 is/are similar in scope to claim(s) 2-4 and 8-13, and is/are therefore rejected under similar rationale.
Claim(s) 5 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mahaffey et al. (US 2010/0210240 A1) in view of Alduaiji (US 2015/0067803 A1) and Baek (US 2024/019300 A1) further in view of Tran et al. (US 2022/0400012 A1).
Regarding Claim 5;
Mahaffey in view of Alduaiji and Baek disclose the method to Claim 1.
Mahaffey and Alduaiji and Baek disclose wherein the [lock]/log off request is associated with the context state (Mahaffey, [0035-[0036] and Alduaiji, [0061] and Baek, FIG. 9 and FIG. 10).
Mahaffey in view of Alduaiji and Baek fails to exactly disclose further discloses wherein the log off request is associated with the context state indicating an inactivity on the wireless communication device.
However, in an analogous art, Tran teaches wherein the log off request is associated with the context state indicating an inactivity on the wireless communication device ([0056] and [0057] - According to various embodiments, the data obtained by and presented through remote management console 501 comprises, per profile metadata of user profiles (for example, user profile 901 in FIG. 9A) maintained at each shared device. The per-profile metadata may include root hash values for profiles maintained at the device, timestamp data (for example, data indicating a last update, last login, last logoff, etc.), credential indices (for example, metadata indicating which users have credentials maintained on a particular device), and metadata identifying devices at which a particular user profile is available and [0057] - For example, remote device management console 501 may be able to push out, over a network, a command to perform a forced logout of the current user on a shared device. In some embodiments, remote device management console 501 may be able to push out, over the network, a command to delete a user profile on a shared device or set of shared devices, thereby causing the deletion of the user profile across all of the devices of shared device group 551 as a result of device-to-device synchronization).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Tran to the context state of Mahaffey in view of Alduaiji and Baek to include wherein the log off request is associated with the context state indicating an inactivity on the wireless communication device.
One would have been motivated to combine the teachings of Tran to Mahaffey in view of Alduaiji and Baek to do so as it provides / allows opportunities and improvements in the domains of device security and device-to-device synchronization (Tran, [0005]).
Regarding Claim(s) 18; claim(s) 18 is/are directed to a/an device associated with the method claimed in claim(s) 5. Claim(s) 18 is/are similar in scope to claim(s) 5, and is/are therefore rejected under similar rationale.
Claim(s) 6 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mahaffey et al. (US 2010/0210240 A1) in view of Alduaiji (US 2015/0067803 A1) and Baek (US 2024/019300 A1) and further in view of Choi (US 2020/0301720 A1).
Regarding Claim 6;
Mahaffey in view of Alduaiji and Baek disclose the method to Claim 1.
Mahaffey in view of Alduaiji and Baek fails to explicitly disclose further discloses wherein the log off request is associated with the associated device disconnecting from a secure network.
However, in an analogous art, Choi teaches wherein the log off request is associated with the associated device disconnecting from a secure network ([0098] - The server 108 may directly control a logoff operation of the first electronic device 102. That is, when the network connection between the first electronic device 102 and the second electronic device 101 is terminated, the second electronic device 101 may transmit a request for logoff of the first electronic device 102 from the device account of the second electronic device 101 to the server 108, and the server 108 may transmit a command to the first electronic device 102 in response to the request so that the first electronic device 102 logs off the device account of the second electronic device 101 and [0104] - [0104] The first electronic device 102 and the second electronic device 101 may be connected through a P2P-based short-range communication network. The short-range communication network may be established through Wi-Fi Direct, Wi-Fi Aware, Bluetooth, UWB, NFC, ZigBee, Z-wave, LTE-Direct, FlashLinQ, DataSpotting, or relay-by-smartphone. The first electronic device 102 and the second electronic device 101 may be connected through a wired connection based on HDMI or USB.)
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Choi to the log off request state of Mahaffey in view of Alduaiji and Baek to include wherein the log off request is associated with the associated device disconnecting from a secure network.
One would have been motivated to combine the teachings of Choi to Mahaffey in view of Alduaiji and Baek to do so as it provides / allows a user of the second electronic device to temporarily use the first electronic device with the same user experience (Choi, [0056]).
Regarding Claim(s) 19; claim(s) 19 is/are directed to a/an device associated with the method claimed in claim(s) 6. Claim(s) 19 is/are similar in scope to claim(s) 6, and is/are therefore rejected under similar rationale.
Claim(s) 7 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mahaffey et al. (US 2010/0210240 A1) in view of Alduaiji (US 2015/0067803 A1) and Baek (US 2024/019300 A1) and further in view of Childs et al. (US 2014/0157378 A1).
Regarding Claim 7;
Mahaffey in view of Alduaiji and Baek disclose the method to Claim 1.
Mahaffey and Alduaiji and Baek disclose wherein the [lock]/log off request is associated with the context state (Mahaffey, [0035-[0036] and Alduaiji, [0061] and Baek, FIG. 9 and FIG. 10).
Mahaffey in view of Alduaiji and Baek fails to exactly disclose wherein the log off request is associated with the context state indicating a required log-off state associated with a predetermined schedule of the wireless communication device.
However, in an analogous art, Childs teaches wherein the log off request is associated with the context state indicating a required log-off state associated with a predetermined schedule of the wireless communication device ([0017] - If they are not, a policy may be implemented wherein certain of the client device application(s) of the client device may be permitted to log a first user out, and log the current user (i.e., the one logging into the cloud service) in, with an additional provision for unbinding of that temporary credential at the conclusion of a session, on receipt of an unbinding/re-binding instruction, based on a validity time out, etc.)
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Childs to the context state of Mahaffey in view of Alduaiji and Baek to include wherein the log off request is associated with the context state indicating a required log-off state associated with a predetermined schedule of the wireless communication device
One would have been motivated to combine the teachings of Childs to Mahaffey in view of Alduaiji and Baek to do so as it provides / allows delivering an enhanced end user experience to individuals and businesses regardless of location, e.g., at home, at work or on the move (Childs, [0002]).
Regarding Claim(s) 20; claim(s) 20 is/are directed to a/an device associated with the method claimed in claim(s) 7. Claim(s) 20 is/are similar in scope to claim(s) 7, and is/are therefore rejected under similar rationale.
Claim(s) 27-30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mahaffey et al. (US 2010/0210240 A1) in view of Alduaiji (US 2015/0067803 A1).
Regarding Claim 27;
Mahaffey discloses a method for wireless communication performable at a server, comprising:
provisioning a first wireless communication device and a second wireless communication device... with a pass key for authenticating and approving action requests between the first wireless communication device and the second wireless communication device ([0036] - The server 111 may require authentication information such as a user name, password, biometric data, or other security-related information. If the user is authorized, the server 111 retrieves previously stored information about the mobile device 101 for which remote access is sough) and [0114] - In order to protect user privacy, the inventive system may be configured so that the local software component 175 on the device 101 only accepts commands from the server that are accompanied with special remote access authentication credentials. In an embodiment with reference to FIG. 16, the server 111 can only generate the remote access authentication credentials in a short period of time with information supplied by the user. The local software component on the device is initially configured with its special remote access authentication credentials. The credentials themselves are not sent to the server. The device generates verification information and a "challenge" token and transmits them to the server 1602. The verification information and "challenge" token are stored by the server 1603. When user-supplied authentication information is received by the server, the server uses the verification information to check whether the user-supplied authentication information is correct 1604. If the authentication information is correct, the server combines the user-supplied authentication information with the "challenge" token to generate the remote access authentication credentials 1605. If the authentication information is not correct, the server does not generate the remote access credentials 1606. When the server has valid authentication credentials, it transmits a command to the device along with the valid credentials 1607.);
receiving, from the first wireless communication device, the pass key associated with a [lock] request for the second wireless communication device, the [lock] request being associated with a context state of the second communication device... ([0035] - In an embodiment, an application or widget loaded on the client computer is used to present a user interface to the user. The user interface may provide some or all of the functionality provided by the web page displayed on the client computer. The application or widget contains presentation logic and communicates with the server via an API... For example, the information requested by the application or widget and returned by the server may contain data such as: a list of devices accessible by the user, status information relating to a device, or a list of devices in a group managed by the user that are determined to be lost or stolen. The application or widget may also send a request to the server to perform actions on a device, change settings relating to a device, or access any other functionality provided by the server and [0036] - The server 111 may require authentication information such as a user name, password, biometric data, or other security-related information. If the user is authorized, the server 111 retrieves previously stored information about the mobile device 101 for which remote access is sought... Some of the remote access controls include locating the mobile device 101 by providing the location of the mobile device 101 on a map, making the mobile device 101 play a sound, backing up the data on the mobile device 101, locking or unlocking the mobile device 101, monitoring audio or video near from the mobile device 101, monitoring any actions taken on the mobile device 101, and wiping any memory in the mobile device 101 and [0114]);
validating the pass key is the pass key provisioned to the first wireless communication device ([0035] and [0036] - The server 111 may require authentication information such as a user name, password, biometric data, or other security-related information. If the user is authorized, the server 111 retrieves previously stored information about the mobile device 101 for which remote access is sought... Some of the remote access controls include locating the mobile device 101 by providing the location of the mobile device 101 on a map, making the mobile device 101 play a sound, backing up the data on the mobile device 101, locking or unlocking the mobile device 101, monitoring audio or video near from the mobile device 101, monitoring any actions taken on the mobile device 101, and wiping any memory in the mobile device 101 and [0114] - In order to protect user privacy, the inventive system may be configured so that the local software component 175 on the device 101 only accepts commands from the server that are accompanied with special remote access authentication credentials. In an embodiment with reference to FIG. 16, the server 111 can only generate the remote access authentication credentials in a short period of time with information supplied by the user. The local software component on the device is initially configured with its special remote access authentication credentials. The credentials themselves are not sent to the server. The device generates verification information and a "challenge" token and transmits them to the server 1602. The verification information and "challenge" token are stored by the server 1603. When user-supplied authentication information is received by the server, the server uses the verification information to check whether the user-supplied authentication information is correct 1604. If the authentication information is correct, the server combines the user-supplied authentication information with the "challenge" token to generate the remote access authentication credentials 1605. If the authentication information is not correct, the server does not generate the remote access credentials 1606. When the server has valid authentication credentials, it transmits a command to the device along with the valid credentials 1607); and
transmitting a pass key authentication to the first wireless communication device authorizing the [lock] request ([0035] - ...the widget may request for the server to return the status of the command (i.e., as noted a form of pass key authentication) and [0036] and [0114])
Mahaffey fails to explicitly disclose:
provisioning a first wireless communication device and a second wireless communication device as part of a list of user devices associated with a user, the first wireless communication device and the second wireless communication device...
[a/the] logoff request... the log-off request being associated with a context state of the second wireless communication device that relates to an activity of the second wireless communication device and the second wireless communication device being proximate to the first wireless communication device.
However, in an analogous art, Alduaiji teaches
provisioning a first wireless communication device and a second wireless communication device as part of a list of user devices associated with a user, the first wireless communication device and the second wireless communication device...([0020] – the user may preregister the address where it is located to the first computer device 20 and [0033] - A user may preregister the contact information of the second computer device 30 (e.g., the user's smartphone or tablet computer) to the server 50 and [0060]-[0061] and [0062] - At S1116 the server 500 analyzes distance between the first computer device 20 and the second computer device 30 based on the received location information), wherein the context relates to an activity associated with the wireless communication device ([0061] - Then, at S1114, the server 50 analyzes the type of the personal account A and judges whether the personal account A is a type of a personal account to control the login status or not. For example, a user may preregister the personal account to control a login status by inputting whether or not the user wants a login status control on the website of personal account A. The server 500 analyzes whether the user preregistered the personal account as an account to control a login status)
[a/the] logoff request... the log-off request being associated with a context state of the second wireless communication device that relates to an activity of the second wireless communication device and the second wireless communication device being proximate to the first wireless communication device. (([0024] - Stored on any one or on a combination of computer readable medium, the present disclosure includes software for controlling the first computer device 20. Such software may include, but is not limited to, device drivers, operating systems, development tools, and applications software and [0063] - At S1118, the server 50 transmits a notification to the second computer device 30 when the type of the personal account A is the specific type of account to control the login status (e.g., bank account, company intranet) and the distance between the first computer device 20 and the second computer device 30 exceeds the predetermined distance. This notification may include a text message, such as "May the first computer device 20 logoff the personal account A?" inquiring a permission to logoff the personal account A and [0063]-[0065] - At S1122, when the server 50 receives the permission signal from the second computer device 30, the server 50 performs logoff processing. Other steps perform a similar function to those described in FIG. 4.)
A person of ordinary skill in the art would have the technical skills to make the mere substitution and the outcome would be predictable. Mainly, substituting one for the other achieves a predictable result because Alduaiji uses a log off/context in a similar role as Mahaffey’s lock/contact for the wireless communication device. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute log off/context of Alduaiji for lock/context of Mahaffey to arrive at the claimed invention because such a step is known and results of the substitution would have been predictable (i.e., performing log off of the wireless communication device).
Regarding Claim 28;
Mahaffey in view of Alduaiji disclose the method to Claim 27.
Mahaffy further discloses wherein the server is a distributed context fabric (DCF) server (FIG. 1 and [0032])
Regarding Claim 29;
Mahaffey in view of Alduaiji disclose the method to Claim 28.
Mahaffy further discloses wherein provisioning the first wireless communication device and the second wireless communication device includes further comprises: creating a DCF identity ([0036] - The server 111 may require authentication information such as a user name, password, biometric data, or other security-related information. If the user is authorized, the server 111 retrieves previously stored information about the mobile device 101 for which remote access is sought); and creating security credentials for the DCF identity ([0036] - The server 111 may require authentication information such as a user name, password, biometric data, or other security-related information. If the user is authorized, the server 111 retrieves previously stored information about the mobile device 101 for which remote access is sought);
Regarding Claim 30;
Mahaffey in view of Alduaiji disclose the method to Claim 28.
Mahaffy further discloses wherein provisioning the first wireless communication device and the second wireless communication device includes further comprises: adding the first wireless communication device and the second wireless communication device to an existing DCF identity ([0095] - The device migration web page contains a list of existing devices associated with the user's account and gives the user the option of adding a new device).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KARI L SCHMIDT whose telephone number is (571)270-1385. The examiner can normally be reached Monday-Friday 10am - 6pm (MDT).
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, Luu Pham can be reached at (571)270-5002. 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.
/KARI L SCHMIDT/Primary Examiner, Art Unit 2439