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 .
Priority
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed application, Application No. 17/542156, 17/040949, PCT/US2019/041871 and 62/698644 fail to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. The independent claims are not supported in any of the parent applications, and therefore do receive the earlier filing date for any of the claims.
Response to Arguments
Applicant’s arguments have been carefully considered and are moot in view of the new grounds of rejection presented below.
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.
Claims 1, 2, and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Aarnio et al. (US 2018/0013571) in view of Lakshmana et al. (US 2016/0259932), and further in view of Pathan et al. (US 2005/0143065), and further in view of in view of Koushik et al. (US 2016/0134616), and further in view of Branigan et al. (US 2002/0090089).
Regarding claim 1, Aarnio teaches a method programmed into a non-transitory memory of a device comprising:
Querying an authentication server to authorize an incoming connection from an endpoint (When the component endpoint 108 returns a candidate response that matches the valid response 276, the controller circuit 250 (i.e., authentication server) determines that the component endpoint 108 represents an authorized component – see [0065]).
Receiving an acknowledgement record for the endpoint from the authentication server (In connection there with, the controller circuit 250 adds an identification of the component endpoint 108 to the authorized component endpoint 108 list 280 – see [0065]).
Updating a list of authorized notes to include a name of the endpoint server (For example, the authorized component endpoint 108 list 280 and unauthorized component endpoint 108 list 282 may include corresponding lists of serial numbers, Mac addresses, or other unique identification information for component endpoints 108 that have been determined to be authorized. The controller circuit 250 may periodically reference the authorized and unauthorized component endpoint 108 lists 280, 282 in connection with verifying whether incoming communications are from an authorized component endpoint 108 – see [0067])
Aarnio does not explicitly recite completing the incoming connection with the endpoint or allowing network traffic with the endpoint. However, Aarnio teaches referencing the authorized endpoint list in connection with whether incoming communications are from an authorized component endpoint. This suggests and implies the that the connection is completed and network traffic is allowed.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio by completing the connection and allowing network traffic from the endpoint, in order to provide secure communications.
Aarnio does not teach that the authentication server comprises an embedded system.
Lakshmana teaches that the authentication server comprises an embedded system (the coordinator 210 can send a control signal to the authorized IoT devices 205 instructing them to enter into an authorization mode, where each of the authorized IoT devices can individually, or in combination with other authorized IoT devices 205, be used to authenticate the new IoT device 205 – see [0041]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio by the device having the authentication server comprise an embedded system, in order that devices may have the ability to securely authenticate one another, based upon the beneficial teachings provided by Lakshmana. These modifications would result in increased functionality across various systems.
Aarnio and Lakshmana do not teach wherein querying the authentication server occurs when the incoming connection is from the endpoint not in a local endpoint stored list.
Pathan teaches: If valid client authentication information (e.g., a valid base transient key associated with the client) is stored in a local memory of wireless domain service 341 (i.e., authorized endpoint), the mobile node 331 is authenticated and authorized to communicate on network 300. Mobile node 331 is also tracked as registered with wireless domain service 341. If valid client authentication information (e.g., a valid base transient key associated with the client) is not stored in a local memory of wireless domain service 341 the client request for access to communication network 300 from mobile node 331 is forwarded to main authentication and authorization server 301(i.e., sent to authentication server when not on list) for participation in a full authentication process – see [0041].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio and Lakshama by querying the authentication server when endpoint is not on local endpoint stored list, in order to save time and resources by checking authentication locally, based upon the beneficial teachings provided by Pathan. These modifications would result in increased speed to the system.
Aarnio, Lakmasha, and Pathan do not teach wherein the local endpoint stored list contains a time-to-live value and periodically expires a record.
Koushik teaches: In one example, an end-user may launch the desktop application management module, which may display the login page hosted by an external identity service (e.g., a domain controller). The end user may provide their domain credentials to login there. As a result, the desktop application management module may receive an authorization code (e.g., one that conforms to the OAuth open source standard). The desktop application management module may then call the application delivery agent, providing the authorization code, in order to get a security token. The agent may then call the identity broker service of the application fulfillment platform, passing the authorization code, along with user and device information, and may get back the security token and, in some embodiments, multiple refresh tokens. In some embodiments, the security token may be a temporary token that expires after a pre-determined time-to-live of between 1 hour and 36 hours) and the refresh tokens may be valid for a pre-determined period of between 30 days and 365 days). The application delivery agent may store the security token (and the refresh tokens) in protected local storage (e.g., encrypted storage) for further reference, e.g., so that the desktop application management module will be able to get it later without requiring the end user to login each time. All subsequent calls to retrieve the security token may simply return the security token stored by the application delivery agent. After this point the desktop application management module may use the security token to communicate with the proxy service, and the local service (e.g., a thread of the application delivery agent) may be responsible for storing and refreshing the security token – see [0166].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio, Lakshama, and Pathan by the local endpoint stored list containing a time-to-live value a periodically expiring a record, in order to keep authorizations fresh and current, based upon the beneficial teachings provided by Koushik. These modifications would result in increased security to the system.
Aarnio, Lakshama, Pathan, and Koushik do not teach wherein the authentication server logs a failed connection attempt.
Branigan teaches If authentication fails, the process proceeds to step 350, the connection is rejected and the connection attempt is logged - see [0024] and figure 3.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio, Lakshama, Pathan, and Koushik by logging failed authentication connection attempts, in order to document failed authenticaiton, based upon the beneficial teachings provided by Branigan. These modifications would result in increased security to the system.
Regarding claim 2, Pathan further teaches wherein the device and the endpoint contain a stored list of authorized endpoints (If valid client authentication information (e.g., a valid base transient key associated with the client) is stored in a local memory of wireless domain service 341 (i.e., authorized endpoint), the mobile node 331 is authenticated and authorized to communicate on network 300. Mobile node 331 is also tracked as registered with wireless domain service 341. If valid client authentication information (e.g., a valid base transient key associated with the client) is not stored in a local memory of wireless domain service 341 the client request for access to communication network 300 from mobile node 331 is forwarded to main authentication and authorization server 301 (i.e., sent to authentication server when not on list) for participation in a full authentication process – see [0041]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio and Lakshama by querying the authentication server when endpoint is not on local endpoint stored list, in order to save time and resources by checking authentication locally, based upon the beneficial teachings provided by Pathan. These modifications would result in increased speed to the system.
Regarding claim 5, Koushik further teaches refreshing authorization based on an expired record (In one example, an end-user may launch the desktop application management module, which may display the login page hosted by an external identity service (e.g., a domain controller). The end user may provide their domain credentials to login there. As a result, the desktop application management module may receive an authorization code (e.g., one that conforms to the OAuth open source standard). The desktop application management module may then call the application delivery agent, providing the authorization code, in order to get a security token. The agent may then call the identity broker service of the application fulfillment platform, passing the authorization code, along with user and device information, and may get back the security token and, in some embodiments, multiple refresh tokens. In some embodiments, the security token may be a temporary token that expires after a pre-determined time-to-live of between 1 hour and 36 hours) and the refresh tokens may be valid for a pre-determined period of between 30 days and 365 days). The application delivery agent may store the security token (and the refresh tokens) in protected local storage (e.g., encrypted storage) for further reference, e.g., so that the desktop application management module will be able to get it later without requiring the end user to login each time. All subsequent calls to retrieve the security token may simply return the security token stored by the application delivery agent. After this point the desktop application management module may use the security token to communicate with the proxy service, and the local service (e.g., a thread of the application delivery agent) may be responsible for storing and refreshing the security token – see [0166]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio, Lakshama, and Pathan by refreshing the authorization based on an expired record, in order to keep authorizations fresh and current, based upon the beneficial teachings provided by Koushik. These modifications would result in increased security to the system.
Regarding claim 7, Lakshmana further teaches that the embedded system is an IoT device (the coordinator 210 can send a control signal to the authorized IoT devices 205 instructing them to enter into an authorization mode, where each of the authorized IoT devices can individually, or in combination with other authorized IoT devices 205, be used to authenticate the new IoT device 205 – see [0041].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio by the device having an IoT device, in order that IoT devices may have the ability to securely authenticate one another, based upon the beneficial teachings provided by Lakshmana. These modifications would result in increased functionality across various systems.
Claims 8, 9, 12, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Aarnio et al. (US 2018/0013571) in view of Lakshmana et al. (US 2016/0259932), and further in view of Pathan et al. (US 2005/0143065), and further in view of in view of Koushik et al. (US 2016/0134616).
Regarding claim 8, Aarnio teaches a method programmed into a non-transitory memory of a device comprising:
Querying an authentication server to authorize an incoming connection from an endpoint (When the component endpoint 108 returns a candidate response that matches the valid response 276, the controller circuit 250 (i.e., authentication server) determines that the component endpoint 108 represents an authorized component – see [0065]).
Receiving an acknowledgement record for the endpoint from the authentication server (In connection there with, the controller circuit 250 adds an identification of the component endpoint 108 to the authorized component endpoint 108 list 280 – see [0065]).
Updating a list of authorized notes to include a name of the endpoint server (For example, the authorized component endpoint 108 list 280 and unauthorized component endpoint 108 list 282 may include corresponding lists of serial numbers, Mac addresses, or other unique identification information for component endpoints 108 that have been determined to be authorized. The controller circuit 250 may periodically reference the authorized and unauthorized component endpoint 108 lists 280, 282 in connection with verifying whether incoming communications are from an authorized component endpoint 108 – see [0067])
Aarnio does not explicitly recite completing the incoming connection with the endpoint or allowing network traffic with the endpoint. However, Aarnio teaches referencing the authorized endpoint list in connection with whether incoming communications are from an authorized component endpoint. This suggests and implies the that the connection is completed and network traffic is allowed.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio by completing the connection and allowing network traffic from the endpoint, in order to provide secure communications.
Aarnio does not teach that the authentication server comprises an embedded system.
Lakshmana teaches that the authentication server comprises an embedded system (the coordinator 210 can send a control signal to the authorized IoT devices 205 instructing them to enter into an authorization mode, where each of the authorized IoT devices can individually, or in combination with other authorized IoT devices 205, be used to authenticate the new IoT device 205 – see [0041]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio by the device having the authentication server comprise an embedded system, in order that devices may have the ability to securely authenticate one another, based upon the beneficial teachings provided by Lakshmana. These modifications would result in increased functionality across various systems.
Aarnio and Lakshmana do not teach wherein querying the authentication server occurs when the incoming connection is from the endpoint not in a local endpoint stored list.
Pathan teaches: If valid client authentication information (e.g., a valid base transient key associated with the client) is stored in a local memory of wireless domain service 341 (i.e., authorized endpoint), the mobile node 331 is authenticated and authorized to communicate on network 300. Mobile node 331 is also tracked as registered with wireless domain service 341. If valid client authentication information (e.g., a valid base transient key associated with the client) is not stored in a local memory of wireless domain service 341 the client request for access to communication network 300 from mobile node 331 is forwarded to main authentication and authorization server 301(i.e., sent to authentication server when not on list) for participation in a full authentication process – see [0041].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio and Lakshama by querying the authentication server when endpoint is not on local endpoint stored list, in order to save time and resources by checking authentication locally, based upon the beneficial teachings provided by Pathan. These modifications would result in increased speed to the system.
Aarnio, Lakmasha, and Pathan do not teach wherein the local endpoint stored list contains a time-to-live value and periodically expires a record.
Koushik teaches: In one example, an end-user may launch the desktop application management module, which may display the login page hosted by an external identity service (e.g., a domain controller). The end user may provide their domain credentials to login there. As a result, the desktop application management module may receive an authorization code (e.g., one that conforms to the OAuth open source standard). The desktop application management module may then call the application delivery agent, providing the authorization code, in order to get a security token. The agent may then call the identity broker service of the application fulfillment platform, passing the authorization code, along with user and device information, and may get back the security token and, in some embodiments, multiple refresh tokens. In some embodiments, the security token may be a temporary token that expires after a pre-determined time-to-live of between 1 hour and 36 hours) and the refresh tokens may be valid for a pre-determined period of between 30 days and 365 days). The application delivery agent may store the security token (and the refresh tokens) in protected local storage (e.g., encrypted storage) for further reference, e.g., so that the desktop application management module will be able to get it later without requiring the end user to login each time. All subsequent calls to retrieve the security token may simply return the security token stored by the application delivery agent. After this point the desktop application management module may use the security token to communicate with the proxy service, and the local service (e.g., a thread of the application delivery agent) may be responsible for storing and refreshing the security token – see [0166].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio, Lakshama, and Pathan by the local endpoint stored list containing a time-to-live value a periodically expiring a record, in order to keep authorizations fresh and current, based upon the beneficial teachings provided by Koushik. These modifications would result in increased security to the system.
Regarding claim 9, Pathan further teaches wherein the device and the endpoint contain a stored list of authorized endpoints (If valid client authentication information (e.g., a valid base transient key associated with the client) is stored in a local memory of wireless domain service 341 (i.e., authorized endpoint), the mobile node 331 is authenticated and authorized to communicate on network 300. Mobile node 331 is also tracked as registered with wireless domain service 341. If valid client authentication information (e.g., a valid base transient key associated with the client) is not stored in a local memory of wireless domain service 341 the client request for access to communication network 300 from mobile node 331 is forwarded to main authentication and authorization server 301 (i.e., sent to authentication server when not on list) for participation in a full authentication process – see [0041]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio and Lakshama by querying the authentication server when endpoint is not on local endpoint stored list, in order to save time and resources by checking authentication locally, based upon the beneficial teachings provided by Pathan. These modifications would result in increased speed to the system.
Regarding claim 12, Koushik further teaches refreshing authorization based on an expired record (In one example, an end-user may launch the desktop application management module, which may display the login page hosted by an external identity service (e.g., a domain controller). The end user may provide their domain credentials to login there. As a result, the desktop application management module may receive an authorization code (e.g., one that conforms to the OAuth open source standard). The desktop application management module may then call the application delivery agent, providing the authorization code, in order to get a security token. The agent may then call the identity broker service of the application fulfillment platform, passing the authorization code, along with user and device information, and may get back the security token and, in some embodiments, multiple refresh tokens. In some embodiments, the security token may be a temporary token that expires after a pre-determined time-to-live of between 1 hour and 36 hours) and the refresh tokens may be valid for a pre-determined period of between 30 days and 365 days). The application delivery agent may store the security token (and the refresh tokens) in protected local storage (e.g., encrypted storage) for further reference, e.g., so that the desktop application management module will be able to get it later without requiring the end user to login each time. All subsequent calls to retrieve the security token may simply return the security token stored by the application delivery agent. After this point the desktop application management module may use the security token to communicate with the proxy service, and the local service (e.g., a thread of the application delivery agent) may be responsible for storing and refreshing the security token – see [0166]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio, Lakshama, and Pathan by refreshing the authorization based on an expired record, in order to keep authorizations fresh and current, based upon the beneficial teachings provided by Koushik. These modifications would result in increased security to the system.
Regarding claim 14, Lakshmana further teaches that the embedded system is an IoT device (the coordinator 210 can send a control signal to the authorized IoT devices 205 instructing them to enter into an authorization mode, where each of the authorized IoT devices can individually, or in combination with other authorized IoT devices 205, be used to authenticate the new IoT device 205 – see [0041].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio by the device having an IoT device, in order that IoT devices may have the ability to securely authenticate one another, based upon the beneficial teachings provided by Lakshmana. These modifications would result in increased functionality across various systems.
Claims 15, 16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Aarnio et al. (US 2018/0013571) in view of Lakshmana et al. (US 2016/0259932), and further in view of Pathan et al. (US 2005/0143065), and further in view of in view of Koushik et al. (US 2016/0134616).
Regarding claim 15, Aarnio teaches a method programmed into a non-transitory memory of a device comprising:
Querying an authentication server to authorize an incoming connection from an endpoint (When the component endpoint 108 returns a candidate response that matches the valid response 276, the controller circuit 250 (i.e., authentication server) determines that the component endpoint 108 represents an authorized component – see [0065]).
Receiving an acknowledgement record for the endpoint from the authentication server (In connection there with, the controller circuit 250 adds an identification of the component endpoint 108 to the authorized component endpoint 108 list 280 – see [0065]).
Updating a list of authorized notes to include a name of the endpoint server (For example, the authorized component endpoint 108 list 280 and unauthorized component endpoint 108 list 282 may include corresponding lists of serial numbers, Mac addresses, or other unique identification information for component endpoints 108 that have been determined to be authorized. The controller circuit 250 may periodically reference the authorized and unauthorized component endpoint 108 lists 280, 282 in connection with verifying whether incoming communications are from an authorized component endpoint 108 – see [0067])
Aarnio does not explicitly recite completing the incoming connection with the endpoint or allowing network traffic with the endpoint. However, Aarnio teaches referencing the authorized endpoint list in connection with whether incoming communications are from an authorized component endpoint. This suggests and implies the that the connection is completed and network traffic is allowed.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio by completing the connection and allowing network traffic from the endpoint, in order to provide secure communications.
Aarnio does not teach wherein querying the authentication server occurs when the incoming connection is from the endpoint not in a local endpoint stored list.
Pathan teaches: If valid client authentication information (e.g., a valid base transient key associated with the client) is stored in a local memory of wireless domain service 341 (i.e., authorized endpoint), the mobile node 331 is authenticated and authorized to communicate on network 300. Mobile node 331 is also tracked as registered with wireless domain service 341. If valid client authentication information (e.g., a valid base transient key associated with the client) is not stored in a local memory of wireless domain service 341 the client request for access to communication network 300 from mobile node 331 is forwarded to main authentication and authorization server 301(i.e., sent to authentication server when not on list) for participation in a full authentication process – see [0041].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio by querying the authentication server when endpoint is not on local endpoint stored list, in order to save time and resources by checking authentication locally, based upon the beneficial teachings provided by Pathan. These modifications would result in increased speed to the system.
Aarnio and Pathan do not teach wherein the local endpoint stored list contains a time-to-live value and periodically expires a record.
Koushik teaches: In one example, an end-user may launch the desktop application management module, which may display the login page hosted by an external identity service (e.g., a domain controller). The end user may provide their domain credentials to login there. As a result, the desktop application management module may receive an authorization code (e.g., one that conforms to the OAuth open source standard). The desktop application management module may then call the application delivery agent, providing the authorization code, in order to get a security token. The agent may then call the identity broker service of the application fulfillment platform, passing the authorization code, along with user and device information, and may get back the security token and, in some embodiments, multiple refresh tokens. In some embodiments, the security token may be a temporary token that expires after a pre-determined time-to-live of between 1 hour and 36 hours) and the refresh tokens may be valid for a pre-determined period of between 30 days and 365 days). The application delivery agent may store the security token (and the refresh tokens) in protected local storage (e.g., encrypted storage) for further reference, e.g., so that the desktop application management module will be able to get it later without requiring the end user to login each time. All subsequent calls to retrieve the security token may simply return the security token stored by the application delivery agent. After this point the desktop application management module may use the security token to communicate with the proxy service, and the local service (e.g., a thread of the application delivery agent) may be responsible for storing and refreshing the security token – see [0166].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio and Pathan by the local endpoint stored list containing a time-to-live value a periodically expiring a record, in order to keep authorizations fresh and current, based upon the beneficial teachings provided by Koushik. These modifications would result in increased security to the system.
Regarding claim 16, Pathan further teaches wherein the device and the endpoint contain a stored list of authorized endpoints (If valid client authentication information (e.g., a valid base transient key associated with the client) is stored in a local memory of wireless domain service 341 (i.e., authorized endpoint), the mobile node 331 is authenticated and authorized to communicate on network 300. Mobile node 331 is also tracked as registered with wireless domain service 341. If valid client authentication information (e.g., a valid base transient key associated with the client) is not stored in a local memory of wireless domain service 341 the client request for access to communication network 300 from mobile node 331 is forwarded to main authentication and authorization server 301 (i.e., sent to authentication server when not on list) for participation in a full authentication process – see [0041]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio by querying the authentication server when endpoint is not on local endpoint stored list, in order to save time and resources by checking authentication locally, based upon the beneficial teachings provided by Pathan. These modifications would result in increased speed to the system.
Regarding claim 19, Koushik further teaches refreshing authorization based on an expired record (In one example, an end-user may launch the desktop application management module, which may display the login page hosted by an external identity service (e.g., a domain controller). The end user may provide their domain credentials to login there. As a result, the desktop application management module may receive an authorization code (e.g., one that conforms to the OAuth open source standard). The desktop application management module may then call the application delivery agent, providing the authorization code, in order to get a security token. The agent may then call the identity broker service of the application fulfillment platform, passing the authorization code, along with user and device information, and may get back the security token and, in some embodiments, multiple refresh tokens. In some embodiments, the security token may be a temporary token that expires after a pre-determined time-to-live of between 1 hour and 36 hours) and the refresh tokens may be valid for a pre-determined period of between 30 days and 365 days). The application delivery agent may store the security token (and the refresh tokens) in protected local storage (e.g., encrypted storage) for further reference, e.g., so that the desktop application management module will be able to get it later without requiring the end user to login each time. All subsequent calls to retrieve the security token may simply return the security token stored by the application delivery agent. After this point the desktop application management module may use the security token to communicate with the proxy service, and the local service (e.g., a thread of the application delivery agent) may be responsible for storing and refreshing the security token – see [0166]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio and Pathan by refreshing the authorization based on an expired record, in order to keep authorizations fresh and current, based upon the beneficial teachings provided by Koushik. These modifications would result in increased security to the system.
Claims 20 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Aarnio et al. (US 2018/0013571) and further in view of Pathan et al. (US 2005/0143065), and further in view of in view of Koushik et al. (US 2016/0134616) and further in view of Lakshmana et al. (US 2016/0259932).
Regarding claims 20 and 21, Aarnio, Pathan, and Koushik do not teach, but Lakshmana teaches that the device comprises an embedded system, wherein the embedded system is an IoT device (the coordinator 210 can send a control signal to the authorized IoT devices 205 instructing them to enter into an authorization mode, where each of the authorized IoT devices can individually, or in combination with other authorized IoT devices 205, be used to authenticate the new IoT device 205 – see [0041].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Aarnio, Pathan, and Koushik by the device being an embedded system having an IoT device, in order that IoT devices may have the ability to securely authenticate one another, based upon the beneficial teachings provided by Lakshmana. These modifications would result in increased functionality across various systems.
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 LISA C LEWIS whose telephone number is (571)270-7724. The examiner can normally be reached Monday - Thursday 7am-2pm.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
/LISA C LEWIS/Primary Examiner, Art Unit 2495