DETAILED ACTION
This communication is responsive to the applicant’s arguments for application number 18/007,395 filed on 03/12/2026. Claim(s) 1-6,11-17,19-20,22-23 and 25-27 are pending examination.
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 .
Response to arguments
Applicant’s arguments with respect to claim(s) 1-6,11-17,19-20,22-23 and 25-27 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant argues that Sauerwald does not teach (1) a remote service invoking request comprising all of (a) an invoking device identifier (ID), (b) an invoking application ID of an invoking application, and (c) target service information, (2) the invoking device ID indicating the invoking device, (3) the invoking application ID indicating the invoking application, among a plurality of applications in the invoking device, that requests to invoke a target service of the target device.
Examiner disagrees. Sauerwald teaches that the device includes an application processor, user land and kernel and that user land can facilitate the operations of third-party applications on the device. Further, the kernel manages the I/O requests from the applications. Thus, Sauerwald teaches applications on the invoking device making I/O requests through the device operating system. Further, Sauerwald discloses that the remote operation is performed between specifically identified devices. In particular, Sauerwald states that a device key Kd can be unique to each device and used for identifying the device and that Kd1 can be a key identifying the first device and Kd2 can be a key identifying the second device. This is analogous to the invoking device identifier indicating the invoking device. Further, Sauerwald teaches sending information from the first device to the second device to perform a remote operation. Also, target service information is broadly taught because the requested remote operation is unlocking the second device. The first device can unlock the second device in response to a user input on the first device and the master key M can allow the second device to be unlocked. Thus, the target service is the second device’s unlocking and access service and the transmitted keys and authentication information identify and authorize that target service. Hence, Sauerwald discloses an invoking device identifier, because Kd1 uniquely identifies the first invoking device and an invoking request context because the first device supports third party applications and manages I/O requests from applications and target service information because the transmitted authentication secret-key information is used to invoke the target device’s unlocking service.
To the extent applicant argues that Sauerwald does not disclose the invoking application ID for identifying one application among multiple applications the new grounds of rejection rely on a new reference Plagemann et al. (US 20140123208 A1) in place of Radulov for the newly argued application and service permission features. Plagemann teaches that a device may receive a command from a remoter device to launch video communications software, and that the command requires access to camera and microphone data. The video communications software corresponds to the claimed invoking application and the camera and microphone data corresponds to the claimed target service information. Plagemann also teaches identifying which application is requesting access among multiple applications. It describes different software consumers, including a computer, a communications program and an electronic program. Thus, the digital signature and application identifying information of the system identifies the application amongst plurality of applications. Hence, the rejection is maintained.
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, 6, 11-13, 15, 19,20,22,23, 25-27 is/are rejected under 35 U.S.C 103 as being unpatentable over Sauerwald et al. (US 20160065374 A1) hereinafter referred to as Sauerwald, in view of Plagemann et al. (US 20140123208 A1), hereinafter referred to as Plagemann
As per claim 1, Sauerwald discloses a remote service invoking method executed on an invoking device, comprising:
sending, by the invoking device, a remote service invoking request to a target device, wherein a same login account is used for the invoking device and the target device, wherein the remote service invoking request comprises an invoking device identifier (ID), an invoking application ID of an invoking application, and target service information, (Transmitting the received secret key to the second device to unlock the second device in response to receiving the user input, Sauerwald, para [0005]. Pairing with the second device and establishing a trusted relationship with the second device; mutually authenticating both devices using a distinct device key in each device, Sauerwald, para [0006])
receiving, by the invoking device, a permission information invoking instruction sent by the target device, wherein the permission information invoking instruction comprises the invoking application ID, the target service information, and (Mutually authenticating both devices using a distinct device key in each device, Sauerwald, para [0006]. The mutual authentication and device key exchange act as the permission information invoking instruction)
sending, by the invoking device, corresponding permission information to the target device according to the permission information invoking instruction, wherein the permission information is used to reflect whether the invoking application has an invoking permission of [[a]] the target service (Transmitting the received secret key to the second device to unlock the second device in response to the user input. To unlock the second device in response to receiving the user input, Sauerwald, para [0007]. The first device sends back the secret key to prove authorization and permit the requested action (unlock). The second device executes the service only when permission information is validated)
However, Sauerwald does not explicitly disclose the limitation:
wherein the invoking device ID indicates the invoking device, wherein the invoking application ID indicates the invoking application, among a plurality of applications in the invoking device, that requests to invoke a target service of the target device, wherein the invoking application includes a video call application, and wherein the target service information includes camera access information and microphone access information;
whether the invoking application has access to a camera and a microphone of the target device; and
Plagemann discloses:
wherein the invoking device ID indicates the invoking device, wherein the invoking application ID indicates the invoking application, among a plurality of applications in the invoking device, that requests to invoke a target service of the target device, wherein the invoking application includes a video call application, and wherein the target service information includes camera access information and microphone access information; (A user may launch video communications software on a laptop computer (e.g., remote device). The command to activate the video communications software may require access to camera and microphone data, Plagemann, para [0029]. Three different consumers are represented by a computer game 810, a video communications program 815, and an electronic program guide 820, Plagemann, para [0055]. Verifying a digital signature of an application, type of application, or mode of the application with which the command is associated, Plagemann, para [0032]. Video communications software is analogous to the video call application. The requested target service is access to camera and microphone data. Here, multiple software consumers/applications including the video communications program are distinguished. A digital signature is used as application identifying information of the requesting application)
whether the invoking application has access to a camera and a microphone of the target device; and (A command to launch a video chat application may be blocked or the application may be denied access to camera and/or microphone data. if the user indicates that the command should be executed (e.g., gives permission to send video data from the camera via an identified application), then the command can be executed, Plagemann, para [0042]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined the process of using one device to unlock another device (Sauerwald) and privacy aware camera and device status indicator system (Plagemann) in order to secure computing systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sauerwald and Plagemann as the motivation would be to reduce complex authorization actions and enable better user interaction experience (See Plagemann, para [0042]).
As per claim 2, Sauerwald and Plagemann discloses the method according to claim 1, wherein before the sending a remote service invoking request to a target device, the method further comprises:
Furthermore, Sauerwald discloses:
in response to the remote service invoking request, determining whether the invoking application requests to invoke the target service for a first time; and (A fixed secret and escrow record can be established during setup, and in an alternative embodiment, a random secret and a temporary escrow record can be established in response to a device unlock during registration, Sauerwald, para [0036]. The first time the user attempts to perform the remote unlock (the target service), the devices must perform a set up process (pairing with key exchange)).
if the invoking application requests to invoke the target service for the first time, performing a permission determining process, wherein performing the permission determining process comprises determining the permission information based on a user and locally storing the permission information; or if the invoking application does not request to invoke the target service for the first time, performing the sending a remote service invoking request to a target device (Mutually authenticating both devices on the trusted relationship using a distinct device key in each device. Receiving a secret key from the second device during setup. Receiving a secret key and storing it, Sauerwald, para [0006]. Here, the user authentication and the device keys are analogous to the permission basis and the secret key is the permission information).
As per claim 3, Sauerwald and Plagemann discloses the method according to claim 2, wherein the determining the permission information based on a user and locally storing the permission information comprises:
Furthermore, Sauerwald discloses:
generating an authorization determining interface, wherein the user selects, based on the authorization determining interface, whether the invoking application has the invoking permission of the target service (Transmitting the received secret key to the second device to unlock the second device in response to receiving the user input, Sauerwald, para [0006]. This shows there is an interface requiring a user input and this user input determines whether the remote action (unlock) is allowed. The permission information (secret key) is sent only after the user authorizes).
As per claim 4, Sauerwald discloses a remote service invoking method executed on a target device, comprising:
receiving, by the target device, a remote service invoking request sent by an invoking device, wherein a same login account is used for the invoking device and the target device, wherein the remote service invoking request comprises an invoking device identifier (ID), an invoking application ID of an invoking application, and target service information, (Some examples of the disclosure are directed to a method performed at a second device for being unlocked by a first device, comprising: receiving a public device key from the first device, Sauerwald, para [0052]. K.sub.du. prove it is still under the control of the same user, Sauerwald, para [0031]. The first device can initially contact the second device. The second device receives data (public device key) from the first device as part of a remote unlocking protocol. This is analogous to receiving a remote service invoking request sent by an invoking device. The request is effectively the first device's authenticated contact and key exchange)
sending, by the target device, a permission information invoking instruction to the invoking device, wherein the permission information invoking instruction comprises the invoking application ID, the target service information, and (Receiving a public device key from the first device, signing the received public device key and sending a secret key to the first device. The second device can send random secret key S, to the first device, Sauerwald, para [0006], [0008], [0036]. Here, the second device sends a secret key S to the first device. This secret key is later used as proof that the first device is authorized to request unlocking)
receiving, by the target device, permission information sent by the invoking device, wherein the permission information is used to reflect whether the invoking application has an invoking permission of [[a]] the target service; (Receiving the secret key from the first device and retrieving the master key using the received secret key and using the master key to perform an unlocking operation. The first device can send the secret key S that it received from the second device back to the second device (step 412), Sauerwald, para [0037] and [0052]. Functionally, the secret key S is permission proof that only the correct, previously registered first device, with valid user input, can provide the right S).
determining, by the target device and based on the permission information, whether the invoking application has the invoking permission of the target service; and (The second device can determine that a device using K.sub.du1, pub to authenticate during an unlocking operation can be a trusted device, Sauerwald, para [0036]. Here, the second device receives the secret information and uses it to decide whether the first device is trusted and under the same user's control. If the check is passed, it proceeds to unlock).
if the invoking application has the invoking permission of the target service, performing, by the target device, invoking of the target service by the invoking application in the invoking device (Using the master key to perform an unlocking operation and the secret key can then be used to unlock the second device 112. Fig 7 describes method of using the first device to unlock the second device. The first device can send key A to the second device, Sauerwald, para [0006], [0015], [0027], [0044]. After the checks, the second device performs the unlock, this is analogous to the target service being invoked remotely. First device proves itself via a key and the second device accepts the proof and the second device invokes the unlock).
However, Sauerwald does not explicitly disclose the limitation:
wherein the invoking device ID indicates the invoking device, wherein the invoking application ID indicates the invoking application, among a plurality of applications in the invoking device, that requests to invoke a target service of the target device, wherein the invoking application includes a video call application, and wherein the target service information includes camera access information and microphone access information;
whether the invoking application has access to a camera and a microphone of the target device;
Plagemann discloses:
wherein the invoking device ID indicates the invoking device, wherein the invoking application ID indicates the invoking application, among a plurality of applications in the invoking device, that requests to invoke a target service of the target device, wherein the invoking application includes a video call application, and wherein the target service information includes camera access information and microphone access information; (A user may launch video communications software on a laptop computer (e.g., remote device). The command to activate the video communications software may require access to camera and microphone data, Plagemann, para [0029]. Three different consumers are represented by a computer game 810, a video communications program 815, and an electronic program guide 820, Plagemann, para [0055]. Verifying a digital signature of an application, type of application, or mode of the application with which the command is associated, Plagemann, para [0032]. Video communications software is analogous to the video call application. The requested target service is access to camera and microphone data. Here, multiple software consumers/applications including the video communications program are distinguished. A digital signature is used as application identifying information of the requesting application)
whether the invoking application has access to a camera and a microphone of the target device; (A command to launch a video chat application may be blocked or the application may be denied access to camera and/or microphone data. if the user indicates that the command should be executed (e.g., gives permission to send video data from the camera via an identified application), then the command can be executed, Plagemann, para [0042]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined the process of using one device to unlock another device (Sauerwald) and privacy aware camera and device status indicator system (Plagemann) in order to secure computing systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sauerwald and Plagemann as the motivation would be to reduce complex authorization actions and enable better user interaction experience (See Plagemann, para [0042])
As per claim 6, Sauerwald and Plagemann discloses the method according to claim 4, further comprising:
Furthermore, Sauerwald discloses:
if the invoking application does not have the invoking permission of the target service, rejecting the invoking of the target service by the invoking application in the invoking device, and returning invoking failure information to the invoking device (The first device can rely on the presence of K.sub.du2 to make sure that it does not unlock the second device when the second device is no longer in the possession of the user and has been rebooted, Sauerwald, para [0031]. Here, the second device can determine that a device using an incorrect key cannot be a trusted device. In such a case, the second device refuses to unlock. This aligns with the rejection of the requested target service which is unlocking).
As per claim 11, Sauerwald discloses a system, wherein the system comprises an invoking device and a target device; wherein the invoking device is configured to perform operations comprising:
sending a remote service invoking request to the target device, wherein a same login account is used for the invoking device and the target device, wherein the remote service invoking request comprises an invoking device identifier (ID), an invoking application ID of an invoking application, and target service information, (Transmitting the received secret key to the second device to unlock the second device in response to receiving the user input, Sauerwald, para [0005]. Pairing with the second device and establishing a trusted relationship with the second device; mutually authenticating both devices using a distinct device key in each device, Sauerwald, para [0006]).
receiving a permission information invoking instruction sent by the target device, wherein the permission information invoking instruction comprises the invoking application ID, the target service information, and (Mutually authenticating both devices using a distinct device key in each device, Sauerwald, para [0006]. The mutual authentication and device key exchange act as the permission information invoking instruction)
sending corresponding permission information to the target device according to the permission information invoking instruction, wherein the permission information is used to reflect whether the invoking application has an invoking permission of [[a]] the target service; (Transmitting the received secret key to the second device to unlock the second device in response to the user input. To unlock the second device in response to receiving the user input, Sauerwald, para [0007]. The first device sends back the secret key to prove authorization and permit the requested action (unlock). The second device executes the service only when permission information is validated)
wherein the target device is configured to perform operations comprising: receiving the remote service invoking request sent by the invoking device; (Some examples of the disclosure are directed to a method performed at a second device for being unlocked by a first device, comprising: receiving a public device key from the first device, Sauerwald, para [0052]. K.sub.du. prove it is still under the control of the same user, Sauerwald, para [0031]. The first device can initially contact the second device. The second device receives data (public device key) from the first device as part of a remote unlocking protocol. This is analogous to receiving a remote service invoking request sent by an invoking device. The request is effectively the first device's authenticated contact and key exchange).
sending the permission information invoking instruction to the invoking device; (Receiving a public device key from the first device, signing the received public device key and sending a secret key to the first device. The second device can send random secret key S, to the first device, Sauerwald, para [0006], [0008], [0036]. Here, the second device sends a secret key S to the first device. This secret key is later used as proof that the first device is authorized to request unlocking)
receiving the permission information sent by the invoking device; (Receiving the secret key from the first device and retrieving the master key using the received secret key and using the master key to perform an unlocking operation. The first device can send the secret key S that it received from the second device back to the second device (step 412), Sauerwald, para [0037] and [0052]. Functionally, the secret key S is permission proof that only the correct, previously registered first device, with valid user input, can provide the right S)
determining, based on the permission information, whether the invoking application has the invoking permission of the target service; and (The second device can determine that a device using K.sub.du1, pub to authenticate during an unlocking operation can be a trusted device, Sauerwald, para [0036]. Here, the second device receives the secret information and uses it to decide whether the first device is trusted and under the same user's control. If the check is passed, it proceeds to unlock).
if the invoking application has the invoking permission of the target service, performing invoking of the target service by the invoking application in the invoking device (Using the master key to perform an unlocking operation and the secret key can then be used to unlock the second device 112. Fig 7 describes method of using the first device to unlock the second device. The first device can send key A to the second device, Sauerwald, para [0006], [0015], [0027], [0044]. After the checks, the second device performs the unlock, this is analogous to the target service being invoked remotely. First device proves itself via a key and the second device accepts the proof and the second device invokes the unlock).
However, Sauerwald does not explicitly disclose the limitation:
wherein the invoking device ID indicates the invoking device, wherein the invoking application ID indicates the invoking application, among a plurality of applications in the invoking device, that requests to invoke a target service of the target device, wherein the invoking application includes a video call application, and wherein the target service information includes camera access information and microphone access information;
whether the invoking application has access to a camera and a microphone of the target device; and
Plagemann discloses:
wherein the invoking device ID indicates the invoking device, wherein the invoking application ID indicates the invoking application, among a plurality of applications in the invoking device, that requests to invoke a target service of the target device, wherein the invoking application includes a video call application, and wherein the target service information includes camera access information and microphone access information; (A user may launch video communications software on a laptop computer (e.g., remote device). The command to activate the video communications software may require access to camera and microphone data, Plagemann, para [0029]. Three different consumers are represented by a computer game 810, a video communications program 815, and an electronic program guide 820, Plagemann, para [0055]. Verifying a digital signature of an application, type of application, or mode of the application with which the command is associated, Plagemann, para [0032]. Video communications software is analogous to the video call application. The requested target service is access to camera and microphone data. Here, multiple software consumers/applications including the video communications program are distinguished. A digital signature is used as application identifying information of the requesting application)
whether the invoking application has access to a camera and a microphone of the target device; and (A command to launch a video chat application may be blocked or the application may be denied access to camera and/or microphone data. if the user indicates that the command should be executed (e.g., gives permission to send video data from the camera via an identified application), then the command can be executed, Plagemann, para [0042]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined the process of using one device to unlock another device (Sauerwald) and privacy aware camera and device status indicator system (Plagemann) in order to secure computing systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sauerwald and Plagemann as the motivation would be to reduce complex authorization actions and enable better user interaction experience (See Plagemann, para [0042])
As per claim 12, Sauerwald and Plagemann discloses the system according to claim 11, wherein
Furthermore, Sauerwald discloses:
before the sending a remote service invoking request to a target device, the invoking device is further configured to perform: when the invoking application requests to invoke the target service for a first time, determining the permission information based on a user and locally storing the permission information (The algorithm for the remote unlocking process (e.g., using the first device to unlock the second device) can include three main steps. First, the first device and the second device can be paired (step 201). Next the second device can authorize remote unlocking by the first device (step 202). Finally, the first device can unlock the second device in response to a user input, Sauerwald, para [0033]. The second device can also perform an authorization, which can include receiving a passcode from the user and optionally an out-of-band verification when the user unlocks the second device locally (step 302). The first device can store the secret key (step 405), Sauerwald, para [0036]. The initial pairing and authorization step is effectively when the invoking entity/ first device first requests to have the target service (unlock) available. The authorization is user-based i.e., it depends on user entering the correct passcode. The authorization result (trusted/untrusted) is analogous to permission information based on a user. After user- based authorization, the first device stores S, the second device stores an escrow record/signed public key. These stored artifacts encode the permission state which essentially means the first device is authorized to unlock the second device and is analogous to locally storing the permission information)
As per claim 13, Sauerwald and Plagemann disclose the system according to claim 12, wherein the determining the permission information based on a user and locally storing the permission information comprises:
Furthermore, Sauerwald discloses:
generating an authorization determining interface, wherein the user selects, based on the authorization determining interface, whether the invoking application has the invoking permission of the target service (The second device can receive a password entered by a user (step 601). The second device can also perform an authorization, which can include receiving a passcode from the user, Sauerwald, para [0036] and [0042]. If the device is receiving a passcode entered by a user, it is understood that there is a UI entry for it which is analogous to authorization determining interface).
As per claim 15, Sauerwald and Plagemann disclose the system according to claim 14, wherein the target device is further configured to perform:
Furthermore, Sauerwald discloses:
if the invoking application does not have the invoking permission of the target service, rejecting the invoking of the target service by the invoking application in the invoking device, and returning invoking failure information to the invoking device (If the registration fails, a message can be sent back to the first device, which can cause the first device to delete Key 4 (step 615), Sauerwald, para [0043]).
As per claim 19, Sauerwald and Plagemann disclose the method according to claim 4, wherein
Furthermore, Sauerwald discloses:
the invoking device includes a smartphone (The first device 100 can be used for unlocking the second device 112. The first device can be, for example, a smartphone, tablet PC, laptop, desktop PC, Mac, electronic reader, smart TV, or game console, or any other devices capable of communicating with another device, Sauerwald, para [0021]).
As per claim 20, Sauerwald and Plagemann disclose the method according to claim 4, wherein
Furthermore, Sauerwald discloses:
the target device includes a smart TV (The first device 100 can be used for unlocking the second device 112. The first device can be, for example, a smartphone, tablet PC, laptop, desktop PC, Mac, electronic reader, smart TV, or game console, or any other devices capable of communicating with another device, Sauerwald, para [0021]).
As per claim 22, Sauerwald and Plagemann disclose the system according to claim 11, wherein
Furthermore, Sauerwald discloses:
the invoking device includes a smartphone (The first device 100 can be used for unlocking the second device 112. The first device can be, for example, a smartphone, tablet PC, laptop, desktop PC, Mac, electronic reader, smart TV, or game console, or any other devices capable of communicating with another device, Sauerwald, para [0021])
As per claim 23, Sauerwald and Plagemann disclose the system according to claim 11, wherein
Furthermore, Sauerwald discloses:
the target device includes a smart TV (The first device 100 can be used for unlocking the second device 112. The first device can be, for example, a smartphone, tablet PC, laptop, desktop PC, Mac, electronic reader, smart TV, or game console, or any other devices capable of communicating with another device, Sauerwald, para [0021])
As per claim 25, Sauerwald and Plagemann disclose the method according to claim 1, wherein
Furthermore, Sauerwald discloses:
the invoking device and the target device belong to a same user (K.sub.du. prove it is still under the control of the same user, Sauerwald, para [0031])
As per claim 26, Sauerwald and Plagemann disclose the method according to claim 4, wherein
Furthermore, Sauerwald discloses:
the invoking device and the target device belong to a same user (K.sub.du. prove it is still under the control of the same user, Sauerwald, para [0031]).
As per claim 27, Sauerwald and Plagemann disclose the method according to claim 1, wherein the method further comprises:
Furthermore, Plagemann discloses:
invoking, by the target device, the camera and the microphone for the invoking application (A command to launch a video chat application may be blocked or the application may be denied access to camera and/or microphone data. if the user indicates that the command should be executed (e.g., gives permission to send video data from the camera via an identified application), then the command can be executed, Plagemann, para [0042]).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined the process of using one device to unlock another device (Sauerwald) and privacy aware camera and device status indicator system (Plagemann) in order to secure computing systems. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sauerwald and Plagemann as the motivation would be to reduce complex authorization actions and enable better user interaction experience (See Plagemann, para [0042])
Claim(s) 5 and 14 is/are rejected under 35 U.S.C 103 as being unpatentable over Sauerwald et al. (US 20160065374 A1) hereinafter referred to as Sauerwald, in view of Plagemann et al. (US 20140123208 A1), hereinafter referred to as Plagemann in further view of Ochmanski et al. (US 9621355 B1), hereinafter referred to as Ochmanski
As per claim 5, Sauerwald and Plagemann 0disclose the method according to claim 4, wherein before the sending a permission information invoking instruction to the invoking device, the method further comprises:
However, Sauerwald in view of Plagemann does not disclose:
obtaining an invoking body ID based on the invoking device ID and the invoking application ID;
determining a type of the invoking body ID; and
if the type of the invoking body ID is a distributed user ID, performing the sending a permission information invoking instruction to the invoking device; or if the type of the invoking body ID is a local ID, performing local invoking permission verification
Ochmanski discloses:
obtaining an invoking body ID based on the invoking device ID and the invoking application ID; (The permissions database 210 contains data indicating permissions according to device identifier and client application identifier per Resource API. The identities are 1. A client application identifier and 2. An identifier of the device. The device identifier and the client application identifier together are used for authorization, Ochmanski, col 8, lines 4-17 and col 10, lines 19-25)
determining a type of the invoking body ID; and (The device identity is derived from the IEEE 1AR (also known as IDevID or LDevID) standard. Both are for the term Device Identifier/DevID, Ochmanski, col 5, lines 36-46. Here IDevID is of type manufacturer/global identity and LDevID is a local device identity type)
if the type of the invoking body ID is a distributed user ID, performing the sending a permission information invoking instruction to the invoking device; or if the type of the invoking body ID is a local ID, performing local invoking permission verification (The authorization server 30 will seek authentication of the device 20 using a device identifier DevID. The authorization server sends to the device an access token that enables the client application to access a resource. The authorization server may further determine a scope of authorization permissions based on the device identifier and a client application identifier, generates the access token based on the scope of authorization permissions, Ochmanski, col 9, lines 24-50. Here the IDevID and external validation servers which are identified by device domain are treated as distributed type. After the flow succeeds, the authorization server sends the access token back to the device. That token encodes permission information such as scope and allowed APIs and is used by the client application to invoke target services)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined the process of using one device to unlock another device (Sauerwald) and privacy aware camera and device status indicator system (Plagemann) in order to secure computing systems with securely authorizing client applications on devices to hosted services (Ochmanski). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sauerwald and Plagemann with Ochmanski as the motivation would be effective authorization of devices and applications (See Ochmanski, col 9, lines 24-50)
As per claim 14, Sauerwald and Plagemann discloses the system according to claim 11, wherein before the sending the permission information invoking instruction to the invoking device, the target device is further configured to perform:
However, Sauerwald in view of Plagemann does not explicitly disclose the limitation:
obtaining an invoking body ID based on the invoking device ID and the invoking application ID;
determining a type of the invoking body ID; and
if the type of the invoking body ID is a distributed user ID, performing the sending the permission information invoking instruction to the invoking device; or if the type of the invoking body ID is a local ID, performing local invoking permission verification
Ochmanski discloses:
obtaining an invoking body ID based on the invoking device ID and the invoking application ID; (The permissions database 210 contains data indicating permissions according to device identifier and client application identifier per Resource API. The identities are 1. A client application identifier and 2. An identifier of the device. The device identifier and the client application identifier together are used for authorization, Ochmanski, col 8, lines 4-17 and col 10, lines 19-25)
determining a type of the invoking body ID; and (The device identity is derived from the IEEE 1AR (also known as IDevID or LDevID) standard. Both are for the term Device Identifier/DevID, Ochmanski, col 5, lines 36-46. Here IDevID is of type manufacturer/global identity and LDevID is a local device identity type)
if the type of the invoking body ID is a distributed user ID, performing the sending the permission information invoking instruction to the invoking device; or if the type of the invoking body ID is a local ID, performing local invoking permission verification (The authorization server 30 will seek authentication of the device 20 using a device identifier DevID. The authorization server sends to the device an access token that enables the client application to access a resource. The authorization server may further determine a scope of authorization permissions based on the device identifier and a client application identifier, generates the access token based on the scope of authorization permissions, Ochmanski, col 9, lines 24-50. Here the IDevID and external validation servers which are identified by device domain are treated as distributed type. After the flow succeeds, the authorization server sends the access token back to the device. That token encodes permission information such as scope and allowed APIs and is used by the client application to invoke target services).
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined the process of using one device to unlock another device (Sauerwald) and privacy aware camera and device status indicator system (Plagemann) in order to secure computing systems with securely authorizing client applications on devices to hosted services (Ochmanski). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine Sauerwald and Plagemann with Ochmanski as the motivation would be effective authorization of devices and applications (See Ochmanski, col 9, lines 24-50)
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 RAGHAVENDER CHOLLETI whose telephone number is (571) 272-0179. The examiner can normally be reached Monday - Thursday 8AM-5PM EST & Friday variable.
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, RUPAL DHARIA can be reached on (571) 272-3880. 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.
Respectfully Submitted
/RAGHAVENDER NMN CHOLLETI/Examiner, Art Unit 2492
/RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492
Prosecution Insights