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 .
Response to Arguments
The present office action is responsive to communication on 11/26/2025. Claims 1, 8, and 15 have been amended. Claims 5, 12, and 19 have been cancelled. Claims 1-4, 6-11, 13-18, and 20 are currently pending.
Applicant’s arguments and amendments filed on 11/26/2025 with respect to rejection of claims 1-20 under 35 USC 112(a) and 35 USC 112(b), as seen in pages 7-8, have been considered and persuasive. Additionally Applicant’s arguments and amendment with respect to claim 1, 6, 8, 13, and 15, and 20 over Ponnuswamy et al. (US PGPub No. 20230009739-A1) in view of Larsson et al. (US PGPub No. 20130340063-A1) and Isles et al. (US PGPub No. 20230137767-A1) have been fully considered and are persuasive. Therefore, the rejection have been withdrawn. However, upon further consideration, new grounds of rejection in view of Hayes et al. (US Pat No.10057225-B1).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claims 1, 6, 8,13, 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ponnuswamy et al. (US PGPub No. 20230009739-A1) in view of Larsson et al. (US PGPub No. 20130340063-A1), Isles et al. (US PGPub No. 20230137767-A1), and Hayes et al. (US Pat No.10057225-B1).
With respect to claim 1, Ponnuswamy teaches a non-transitory computer-readable medium comprising machine-readable instructions, wherein the instructions, when executed by at least one processor, cause the at least one processor to at least: (¶0013: It should be appreciated that the described embodiments can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer-readable medium such as a computer-readable storage medium containing computer-readable instructions or computer program code, or as a computer program product, comprising a computer-usable medium having a computer-readable program code embodied therein. In the context of this disclosure, a computer-usable medium or computer-readable medium may be any physical medium that can contain or store the program for use by or in connection ; with the instruction execution system, apparatus or device. );
transmit, from a first client device to a second client device, verification data comprising: a public key verification certificate of the first client device, and a time-based session token generated by the first client device, (¶0031-0033: Figure 2 illustrates a sequence of operations for a backup process using a short-term token for user authentication, under some embodiments. Diagram 200 of FIG. 2 illustrates some of the processing steps among a backup server 202, a backup client 204, and a storage system 206. The process starts (step 21) with the backup server 202 sending a request to the storage system 206 to create a directory. For starting the backup, the backup server 202 creates the JWT (step 22) and signs it with the private key that is associated with the public key that is used in step 21. The contents of the JWT are: (a) the directory name where the backup files will be created, (b) the backup client 204 name, and (c) permissions and privileges for the backup client on the directory for more granular access, and (d) an expiration time. In an embodiment, the backup client name corresponds to the common name (CN) or subject alternative name (SAN) of the backup client’s X.509 certificate, where X.509 is a standard for a format of public key certificates, such as used in TLS (transport layer security) or SSL (secure sockets layer). An X.509 certificate contains its own public key and an identity (a hostname, or an organization, or an individual), and is either signed by a certificate authority or self-signed.);
wherein the second client device sends the verification data to a management service for verification, and (¶0034: The backup server 202 requests the backup client 204 to start the backup and passes the directory name and the JWT (step 23). In an embodiment, the connection between the server 202 and client 204 for step 23 is over a secure link, such as a TLS connection. The TLS connection requires authentication, such as typically done using an X.509 certificate for the client.);
receive, by the first client device from the second client device, a preliminary cross- comparison package comprising: the spoof-check token received by the second client device from the management service, and peer device context data of the second client device; (¶0035: The backup client sends a backup request to the storage system 206 and passes the JWT it received from the backup server 202 (step 24) (from the second device). The storage system 206 uses the public key that was associated in step 21 to ensure that the backup server 202 has valid access to the directory (step 25). The storage system will then extract the backup client name from the JWT and will compare it with the X.509 certificate’s CN or SAN values. As stated above, the TLS connection requires a X.509 certificate for the client, and this is used to provide the information that is compared to the JWT information. This allows the system to prove that the client presenting the token is the client that is identified in the token. The appearance of the client name in the token by itself proves that the backup server has given permission to the named client, thus proving that this the valid client (step 26).).
generate, by the first client device, a cross-comparison package based on the preliminary cross-comparison package and (¶0039: To avoid the possibility of any interception or theft of the JWT or of a man-in-the-middle (MITM) attack all communications between and among the server 202, client 204, and storage system 306 occur over a mutually authenticated encrypted connection, such as a Transport Layer Security (TLS) or other Internet encrypted connection between the backup server and backup client. Thus, the links for steps 21,23, and 24 can all be implemented using TLS (or similar) connections.);
transmit, by the first client device, the cross-comparison package to the management service for cross-comparison , (¶0037: As further seen in Figure 3, the backup server defines and generates a short-term token specifying relevant parameters such as storage unit directory, client name, client permissions, job type or backup operation, token expiry time, and so on, 304. The token is then encrypted with the private key of the public/private key pair. The server sends to the client 204 the token and directory name, and the client passes the token on to the storage system, 306.)
wherein the management service performs the cross-comparison by checking for differences between the local device context data of the first client device and the peer device context data of the second client device. (¶0037: The storage system 206 then uses the public key provided by the server to verify that both the server and client have access to the storage unit, and the data path access to the directory is valid, 308. If any of these verification checks fails, as determined in decision block 309, the client is denied access to the directory, 312. If the verification checks all pass, the client is free to access the directory, 310.).
It is noted that Ponnuswamy teaches a certificate as illustrated in ¶0031-0033 and Figure 2, but the prior does not disclose sending over the certificate for verification of the first device. However, Larsson teaches transmit, from a first client device to a second client device, verification data comprising: a public key verification certificate of the first client device, and a time-based session token generated by the first client device, (¶0020-0022: As seen in Figure 1 and Figure 2 wherein the user, through client 104 (first client device) , requests access to virtual desktop 120 (second client device) by transmitting a connection request to connection sever 204. Connection server 204 verifies the user's access permissions with directory service 214, and uses the authentication token to determine whether the user is trusted. If the user is trusted, connection server 204 generates a private key, a digital certificate, and a personal identification number (PIN) for the user. In an embodiment, the private key, the digital certificate, and the PIN are "one-off" credentials that are only valid for a single connection session with the user. In an embodiment, connection server 204 stores the private key, the digital certificate, and the PIN in a virtual smartcard 216. Client 104 connects to virtual desktop 120 (as seen in Figure 1) and uses virtual smartcard 216 (first client device sending verification data comprising of: public key verification certificate (digital certificate) and time-based session token (PIN))) in lieu of providing access credentials, such as a username and password, to virtual desktop 120. Virtual desktop 120 authenticates the user via virtual smartcard 216 (e.g., using the private key, the digital certificate, and the PIN) with directory service 214 and certificate server 206.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Larsson with regards to the public key verification certificate to the method of Ponnuswamy in order to provide authentication of the computing device (Larsson : ¶0004).
Although, Ponnuswamy in view of Larsson does disclose the inclusion of tokens, but the prior art does not explicitly disclose peer device context data. However, Isles teaches the verification of peer device context data (¶0059: As seen in Figure 2, at operation 230, authorizing data service 124 may, optionally, determine that primary client device 205 and secondary client device 210 are physically co-located. In some embodiments, authorizing data service 124 may determine physical co-location by using the location data appended to the authentication tokens received from primary client device 205 and secondary client device 210. For example, authorizing data service 124 may compare the location data appended to each respective token and determine whether the IP address, MAC address, or GPS data appended to the authentication token received from primary client device 205 matches the IP address, MAC address, or GPS data, respectively, appended to the authentication token received from secondary client device 210. In embodiments, where the location data does not match, authorizing data service 124 may deny the pending service request. It is noted that operation 230 is optional because, in other embodiments, the physical co-location of client devices 205, 210 may be established by receiving the authentication token from secondary client device 210 since in these other embodiments, secondary client device 210 is configured to send the authentication token only if it confirms that it is co-located with primary client device 205 (which may be confirmed if, for example, secondary client device 210 is able to communicate with primary client device 205 using short range communication technology).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Isles with regards to the peer device context to the method of Ponnuswamy in view of Larsson in order to prevent fraudulent actions such as falsifying information (Isles : ¶0003).
Ponnuswamy in view of Larsson and Isles does not disclose:
wherein the management service verifies the verification data, generates a spoof-check token by encrypting the time-based session token with a spoof-check private encryption key of the management service and sends the spoof-check token to the second client device;
the cross-comparison package containing the spoof-check token, the peer device context data of the second client device, and local device context data of the first client device;
However, Hayes teaches wherein the management service verifies the verification data, generates a spoof-check token by encrypting the time-based session token with a spoof-check private encryption key of the management service and sends the spoof-check token to the second client device; (¶0087: Once MW2 and MW2 got connected they need to know whether they can speak the same language. This may be accomplished by exchanging the information Tables 1 and 2. For example, the protocol name and version, level/type or financial services they can perform, and the like. They can exchange the encrypted UUID so that their respective mobile wallet service provider’s authenticate the other wallet. UUID can be encrypted using the banks private key so that the wallet can’t get the UUID of the wallet. To increase security one time can be generated that will represent the UUID and other parameters can be exchange (exchanging to the second client).);
the cross-comparison package containing the spoof-check token, the peer device context data of the second client device, and local device context data of the first client device; (¶0031-0035: Tables 1 and 2 defines a new Wallet Service Profile that a mobile wallet application would use to search for other wallet client services and select specific wallet services, using attributes and attributes values from table 2, to perform P2PMW (peer to peer mobile wallet) communications. The table also defines attributes that would need to be used by wallet clients to manage communication methods and perform object management operations . Tables 2 is an expanded version of Table 1 showing additional information on possible values of the various fields. Wallet holder can include one or more of a name, wallet address, personal email, phone number, or the like. Wallet receiver is the receiver of the transaction and can include one or more of a name, phone number, wallet address, personal email, or the like. Transfer Data may include information on a wallet transaction. Transfer Type may specify a type of transaction. The Protocol specifies the protocol used in communicating with the other mobile wallet. (the peer device context data of the second client device and local device context data of the first client device). For example, the mobile wallets may initially exchange one or more of the fields (e.g., protocol, encryption information, and authentication methods), authenticate themselves, and exchange the remaining items. During the authentication process they may exchange an encrypted UUID (spoof-check token) to allow their respective wallet issuer systems to authenticate the other mobile wallet.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Hayes with regards to spoof-check token and items of the cross-comparison package to the method of Ponnuswamy in view of Larsson and Isles in order to provide additional security such as application integrity checking and confidentiality (Hayes: ¶0021).
With respect to claim 6, the combination of Ponnuswamy in view of Larsson, Isles, and Hayes teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose wherein the local device context data comprises at least one of: location data of the first client device, sensor data of the first client device, and network data of the first client device. (Isles ¶0021: In some embodiments, the physical co-location of both client devices may be established using location data such as, for example, Internet Protocol (IP) addresses, media access control (MAC) addresses, Global Positioning System (GPS) data, etc. In particular, the primary client device and the secondary client device may send, to the service provider platform, the authentication token appended with respective location data.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Isles with regards to the peer device context to the method of Ponnuswamy in view of Larsson and Hayes in order to prevent fraudulent actions such as falsifying information (Isles : ¶0003).
With respect to claim 8, Ponnuswamy teaches a system, comprising: a first client device comprising at least one processor; and a memory comprising machine-readable instructions, wherein the instructions, when executed by the at least one processor, (¶0013: It should be appreciated that the described embodiments can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer-readable medium such as a computer-readable storage medium containing computer-readable instructions or computer program code, or as a computer program product, comprising a computer-usable medium having a computer-readable program code embodied therein. In the context of this disclosure, a computer-usable medium or computer-readable medium may be any physical medium that can contain or store the program for use by or in connection with the instruction execution system, apparatus or device. );
cause the first client device to at least: transmit, to a second client device, verification data comprising: a public key verification certificate of the first client device, and a time-based session token generated by the first client device, (¶0031-0033: Figure 2 illustrates a sequence of operations for a backup process using a short-term token for user authentication, under some embodiments. Diagram 200 of FIG. 2 illustrates some of the processing steps among a backup server 202, a backup client 204, and a storage system 206. The process starts (step 21) with the backup server 202 sending a request to the storage system 206 to create a directory. For starting the backup, the backup server 202 creates the JWT (step 22) and signs it with the private key that is associated with the public key that is used in step 21. The contents of the JWT are: (a) the directory name where the backup files will be created, (b) the backup client 204 name, and (c) permissions and privileges for the backup client on the directory for more granular access, and (d) an expiration time. In an embodiment, the backup client name corresponds to the common name (CN) or subject alternative name (SAN) of the backup client’s X.509 certificate, where X.509 is a standard for a format of public key certificates, such as used in TLS (transport layer security) or SSL (secure sockets layer). An X.509 certificate contains its own public key and an identity (a hostname, or an organization, or an individual), and is either signed by a certificate authority or self-signed.);
wherein the second client device sends the verification data to a management service for verification, and (¶0034: The backup server 202 requests the backup client 204 to start the backup and passes the directory name and the JWT (step 23). In an embodiment, the connection between the server 202 and client 204 for step 23 is over a secure link, such as a TLS connection. The TLS connection requires authentication, such as typically done using an X.509 certificate for the client.);
receive, from the second client device, a preliminary cross-comparison package comprising: the spoof-check token received by the second client device from the management service, and peer device context data of the second client device; (¶0035: The backup client sends a backup request to the storage system 206 and passes the JWT it received from the backup server 202 (step 24) (from the second device). The storage system 206 uses the public key that was associated in step 21 to ensure that the backup server 202 has valid access to the directory (step 25). The storage system will then extract the backup client name from the JWT and will compare it with the X.509 certificate’s CN or SAN values. As stated above, the TLS connection requires a X.509 certificate for the client, and this is used to provide the information that is compared to the JWT information. This allows the system to prove that the client presenting the token is the client that is identified in the token. The appearance of the client name in the token by itself proves that the backup server has given permission to the named client, thus proving that this the valid client (step 26).);
generate a cross-comparison package based on the preliminary cross-comparison package, (¶0039: To avoid the possibility of any interception or theft of the JWT or of a man-in-the-middle (MITM) attack all communications between and among the server 202, client 204, and storage system 306 occur over a mutually authenticated encrypted connection, such as a Transport Layer Security (TLS) or other Internet encrypted connection between the backup server and backup client. Thus, the links for steps 21,23, and 24 can all be implemented using TLS (or similar) connections.);
and transmit the cross-comparison package to the management service for cross- comparison, (¶0037: As further seen in Figure 3, the backup server defines and generates a short-term token specifying relevant parameters such as storage unit directory, client name, client permissions, job type or backup operation, token expiry time, and so on, 304. The token is then encrypted with the private key of the public/private key pair. The server sends to the client 204 the token and directory name, and the client passes the token on to the storage system, 306.);
wherein the management service performs the cross- comparison by checking for differences between the local device context data of the first client device and the peer device context data of the second client device. (¶0037: The storage system 206 then uses the public key provided by the server to verify that both the server and client have access to the storage unit, and the data path access to the directory is valid, 308. If any of these verification checks fails, as determined in decision block 309, the client is denied access to the directory, 312. If the verification checks all pass, the client is free to access the directory, 310.);
It is noted that Ponnuswamy teaches a certificate as illustrated in ¶0031-0033 and Figure 2, but the prior does not disclose sending over the certificate for verification of the first device. However, Larsson teaches transmit, from a first client device to a second client device, verification data comprising: a public key verification certificate of the first client device, and a time-based session token generated by the first client device, (¶0020-0022: As seen in Figure 1 and Figure 2 wherein the user, through client 104 (first client device) , requests access to virtual desktop 120 (second client device) by transmitting a connection request to connection sever 204. Connection server 204 verifies the user's access permissions with directory service 214, and uses the authentication token to determine whether the user is trusted. If the user is trusted, connection server 204 generates a private key, a digital certificate, and a personal identification number (PIN) for the user. In an embodiment, the private key, the digital certificate, and the PIN are "one-off" credentials that are only valid for a single connection session with the user. In an embodiment, connection server 204 stores the private key, the digital certificate, and the PIN in a virtual smartcard 216. Client 104 connects to virtual desktop 120 (as seen in Figure 1) and uses virtual smartcard 216 (first client device sending verification data comprising of: public key verification certificate (digital certificate) and time-based session token (PIN))) in lieu of providing access credentials, such as a username and password, to virtual desktop 120. Virtual desktop 120 authenticates the user via virtual smartcard 216 (e.g., using the private key, the digital certificate, and the PIN) with directory service 214 and certificate server 206.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Larsson with regards to the public key verification certificate to the method of Ponnuswamy in order to provide authentication of the computing device (Larsson : ¶0004).
Although, Ponnuswamy in view of Larsson does disclose the inclusion of tokens, but the prior art does not explicitly disclose peer device context data. However, Isles teaches the verification of peer device context data (¶0059: As seen in Figure 2, at operation 230, authorizing data service 124 may, optionally, determine that primary client device 205 and secondary client device 210 are physically co-located. In some embodiments, authorizing data service 124 may determine physical co-location by using the location data appended to the authentication tokens received from primary client device 205 and secondary client device 210. For example, authorizing data service 124 may compare the location data appended to each respective token and determine whether the IP address, MAC address, or GPS data appended to the authentication token received from primary client device 205 matches the IP address, MAC address, or GPS data, respectively, appended to the authentication token received from secondary client device 210. In embodiments, where the location data does not match, authorizing data service 124 may deny the pending service request. It is noted that operation 230 is optional because, in other embodiments, the physical co-location of client devices 205, 210 may be established by receiving the authentication token from secondary client device 210 since in these other embodiments, secondary client device 210 is configured to send the authentication token only if it confirms that it is co-located with primary client device 205 (which may be confirmed if, for example, secondary client device 210 is able to communicate with primary client device 205 using short range communication technology).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Isles with regards to the peer device context to the method of Ponnuswamy in view of Larsson in order to prevent fraudulent actions such as falsifying information (Isles : ¶0003).
Ponnuswamy in view of Larsson and Isles does not disclose:
wherein the management service verifies the verification data, generates a spoof-check token by encrypting the time-based session token with a spoof-check private encryption key of the management service and sends the spoof-check token to the second client device;
the cross-comparison package containing the spoof-check token, the peer device context data of the second client device, and local device context data of the first client device;
However, Hayes teaches wherein the management service verifies the verification data, generates a spoof-check token by encrypting the time-based session token with a spoof-check private encryption key of the management service and sends the spoof-check token to the second client device; (¶0087: Once MW2 and MW2 got connected they need to know whether they can speak the same language. This may be accomplished by exchanging the information Tables 1 and 2. For example, the protocol name and version, level/type or financial services they can perform, and the like. They can exchange the encrypted UUID so that their respective mobile wallet service provider’s authenticate the other wallet. UUID can be encrypted using the banks private key so that the wallet can’t get the UUID of the wallet. To increase security one time can be generated that will represent the UUID and other parameters can be exchange (exchanging to the second client).);
the cross-comparison package containing the spoof-check token, the peer device context data of the second client device, and local device context data of the first client device; (¶0031-0035: Tables 1 and 2 defines a new Wallet Service Profile that a mobile wallet application would use to search for other wallet client services and select specific wallet services, using attributes and attributes values from table 2, to perform P2PMW (peer to peer mobile wallet) communications. The table also defines attributes that would need to be used by wallet clients to manage communication methods and perform object management operations . Tables 2 is an expanded version of Table 1 showing additional information on possible values of the various fields. Wallet holder can include one or more of a name, wallet address, personal email, phone number, or the like. Wallet receiver is the receiver of the transaction and can include one or more of a name, phone number, wallet address, personal email, or the like. Transfer Data may include information on a wallet transaction. Transfer Type may specify a type of transaction. The Protocol specifies the protocol used in communicating with the other mobile wallet. (the peer device context data of the second client device and local device context data of the first client device). For example, the mobile wallets may initially exchange one or more of the fields (e.g., protocol, encryption information, and authentication methods), authenticate themselves, and exchange the remaining items. During the authentication process they may exchange an encrypted UUID (spoof-check token) to allow their respective wallet issuer systems to authenticate the other mobile wallet.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Hayes with regards to spoof-check token and items of the cross-comparison package to the method of Ponnuswamy in view of Larsson and Isles in order to provide additional security such as application integrity checking and confidentiality (Hayes: ¶0021).
With respect to claim 13, the combination of the combination of Ponnuswamy in view of Larsson, Isles, and Hayes teaches the method of claim 8 (see rejection of claim 8 above) but does not disclose wherein the peer device context data comprises at least one of: location data of the second client device, sensor data of the second client device, and network data of the second client device. (Isles ¶0021: In some embodiments, the physical co-location of both client devices may be established using location data such as, for example, Internet Protocol (IP) addresses, media access control (MAC) addresses, Global Positioning System (GPS) data, etc. In particular, the primary client device and the secondary client device may send, to the service provider platform, the authentication token appended with respective location data.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Isles with regards to the peer device context to the method of Ponnuswamy in view of Larsson and Hayes in order to prevent fraudulent actions such as falsifying information (Isles : ¶0003).
With respect to claim 15, Ponnuswamy teaches a method comprising: (¶0013: It should be appreciated that the described embodiments can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer-readable medium such as a computer-readable storage medium containing computer-readable instructions or computer program code, or as a computer program product, comprising a computer-usable medium having a computer-readable program code embodied therein. In the context of this disclosure, a computer-usable medium or computer-readable medium may be any physical medium that can contain or store the program for use by or in connection with the instruction execution system, apparatus or device. )
transmitting, from a first client device to a second client device, verification data comprising: a public key verification certificate of the first client device, and a time-based session token generated by the first client device, (¶0031-0033: Figure 2 illustrates a sequence of operations for a backup process using a short-term token for user authentication, under some embodiments. Diagram 200 of FIG. 2 illustrates some of the processing steps among a backup server 202, a backup client 204, and a storage system 206. The process starts (step 21) with the backup server 202 sending a request to the storage system 206 to create a directory. For starting the backup, the backup server 202 creates the JWT (step 22) and signs it with the private key that is associated with the public key that is used in step 21. The contents of the JWT are: (a) the directory name where the backup files will be created, (b) the backup client 204 name, and (c) permissions and privileges for the backup client on the directory for more granular access, and (d) an expiration time. In an embodiment, the backup client name corresponds to the common name (CN) or subject alternative name (SAN) of the backup client’s X.509 certificate, where X.509 is a standard for a format of public key certificates, such as used in TLS (transport layer security) or SSL (secure sockets layer). An X.509 certificate contains its own public key and an identity (a hostname, or an organization, or an individual), and is either signed by a certificate authority or self-signed.);
wherein the second client device sends the verification data to a management service for verification, and (¶0034: The backup server 202 requests the backup client 204 to start the backup and passes the directory name and the JWT (step 23). In an embodiment, the connection between the server 202 and client 204 for step 23 is over a secure link, such as a TLS connection. The TLS connection requires authentication, such as typically done using an X.509 certificate for the client.);
wherein the management service verifies the verification data, generates a spoof-check token by encrypting the time-based session token with a spoof-check private encryption key of the management service and sends the spoof-check token to the second client device;
receiving, by the first client device from the second client device, a preliminary cross- comparison package comprising: the spoof-check token received by the second client device from the management service, and peer device context data of the second client device; (¶0035: The backup client sends a backup request to the storage system 206 and passes the JWT it received from the backup server 202 (step 24) (from the second device). The storage system 206 uses the public key that was associated in step 21 to ensure that the backup server 202 has valid access to the directory (step 25). The storage system will then extract the backup client name from the JWT and will compare it with the X.509 certificate’s CN or SAN values. As stated above, the TLS connection requires a X.509 certificate for the client, and this is used to provide the information that is compared to the JWT information. This allows the system to prove that the client presenting the token is the client that is identified in the token. The appearance of the client name in the token by itself proves that the backup server has given permission to the named client, thus proving that this the valid client (step 26).);
generating, by the first client device, a cross-comparison package based on the preliminary cross-comparison package, the cross-comparison package containing the spoof-check token, the peer device context data of the second client device and local device context data of the first client device; and (¶0039: To avoid the possibility of any interception or theft of the JWT or of a man-in-the-middle (MITM) attack all communications between and among the server 202, client 204, and storage system 306 occur over a mutually authenticated encrypted connection, such as a Transport Layer Security (TLS) or other Internet encrypted connection between the backup server and backup client. Thus, the links for steps 21,23, and 24 can all be implemented using TLS (or similar) connections.).
transmitting, by the first client device, the cross-comparison package to the management service for cross-comparison, (¶0037: As further seen in Figure 3, the backup server defines and generates a short-term token specifying relevant parameters such as storage unit directory, client name, client permissions, job type or backup operation, token expiry time, and so on, 304. The token is then encrypted with the private key of the public/private key pair. The server sends to the client 204 the token and directory name, and the client passes the token on to the storage system, 306.)
wherein the management service performs the cross-comparison by checking for differences between the local device context data of the first client device and the peer device context data of the second client device. (¶0037: The storage system 206 then uses the public key provided by the server to verify that both the server and client have access to the storage unit, and the data path access to the directory is valid, 308. If any of these verification checks fails, as determined in decision block 309, the client is denied access to the directory, 312. If the verification checks all pass, the client is free to access the directory, 310.).
It is noted that Ponnuswamy teaches a certificate as illustrated in ¶0031-0033 and Figure 2, but the prior does not disclose sending over the certificate for verification of the first device. However, Larsson teaches transmit, from a first client device to a second client device, verification data comprising: a public key verification certificate of the first client device, and a time-based session token generated by the first client device, (¶0020-0022: As seen in Figure 1 and Figure 2 wherein the user, through client 104 (first client device) , requests access to virtual desktop 120 (second client device) by transmitting a connection request to connection sever 204. Connection server 204 verifies the user's access permissions with directory service 214, and uses the authentication token to determine whether the user is trusted. If the user is trusted, connection server 204 generates a private key, a digital certificate, and a personal identification number (PIN) for the user. In an embodiment, the private key, the digital certificate, and the PIN are "one-off" credentials that are only valid for a single connection session with the user. In an embodiment, connection server 204 stores the private key, the digital certificate, and the PIN in a virtual smartcard 216. Client 104 connects to virtual desktop 120 (as seen in Figure 1) and uses virtual smartcard 216 (first client device sending verification data comprising of: public key verification certificate (digital certificate) and time-based session token (PIN))) in lieu of providing access credentials, such as a username and password, to virtual desktop 120. Virtual desktop 120 authenticates the user via virtual smartcard 216 (e.g., using the private key, the digital certificate, and the PIN) with directory service 214 and certificate server 206.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Larsson with regards to the public key verification certificate to the method of Ponnuswamy in order to provide authentication of the computing device (Larsson : ¶0004).
Although, Ponnuswamy in view of Larsson does disclose the inclusion of tokens, but the prior art does not explicitly disclose peer device context data. However, Isles teaches the verification of peer device context data (¶0059: As seen in Figure 2, at operation 230, authorizing data service 124 may, optionally, determine that primary client device 205 and secondary client device 210 are physically co-located. In some embodiments, authorizing data service 124 may determine physical co-location by using the location data appended to the authentication tokens received from primary client device 205 and secondary client device 210. For example, authorizing data service 124 may compare the location data appended to each respective token and determine whether the IP address, MAC address, or GPS data appended to the authentication token received from primary client device 205 matches the IP address, MAC address, or GPS data, respectively, appended to the authentication token received from secondary client device 210. In embodiments, where the location data does not match, authorizing data service 124 may deny the pending service request. It is noted that operation 230 is optional because, in other embodiments, the physical co-location of client devices 205, 210 may be established by receiving the authentication token from secondary client device 210 since in these other embodiments, secondary client device 210 is configured to send the authentication token only if it confirms that it is co-located with primary client device 205 (which may be confirmed if, for example, secondary client device 210 is able to communicate with primary client device 205 using short range communication technology).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Isles with regards to the peer device context to the method of Ponnuswamy in view of Larsson in order to prevent fraudulent actions such as falsifying information (Isles : ¶0003).
Ponnuswamy in view of Larsson and Isles does not disclose:
wherein the management service verifies the verification data, generates a spoof-check token by encrypting the time-based session token with a spoof-check private encryption key of the management service and sends the spoof-check token to the second client device;
the cross-comparison package containing the spoof-check token, the peer device context data of the second client device, and local device context data of the first client device;
However, Hayes teaches wherein the management service verifies the verification data, generates a spoof-check token by encrypting the time-based session token with a spoof-check private encryption key of the management service and sends the spoof-check token to the second client device; (¶0087: Once MW2 and MW2 got connected they need to know whether they can speak the same language. This may be accomplished by exchanging the information Tables 1 and 2. For example, the protocol name and version, level/type or financial services they can perform, and the like. They can exchange the encrypted UUID so that their respective mobile wallet service provider’s authenticate the other wallet. UUID can be encrypted using the banks private key so that the wallet can’t get the UUID of the wallet. To increase security one time can be generated that will represent the UUID and other parameters can be exchange (exchanging to the second client).);
the cross-comparison package containing the spoof-check token, the peer device context data of the second client device, and local device context data of the first client device; (¶0031-0035: Tables 1 and 2 defines a new Wallet Service Profile that a mobile wallet application would use to search for other wallet client services and select specific wallet services, using attributes and attributes values from table 2, to perform P2PMW (peer to peer mobile wallet) communications. The table also defines attributes that would need to be used by wallet clients to manage communication methods and perform object management operations . Tables 2 is an expanded version of Table 1 showing additional information on possible values of the various fields. Wallet holder can include one or more of a name, wallet address, personal email, phone number, or the like. Wallet receiver is the receiver of the transaction and can include one or more of a name, phone number, wallet address, personal email, or the like. Transfer Data may include information on a wallet transaction. Transfer Type may specify a type of transaction. The Protocol specifies the protocol used in communicating with the other mobile wallet. (the peer device context data of the second client device and local device context data of the first client device). For example, the mobile wallets may initially exchange one or more of the fields (e.g., protocol, encryption information, and authentication methods), authenticate themselves, and exchange the remaining items. During the authentication process they may exchange an encrypted UUID (spoof-check token) to allow their respective wallet issuer systems to authenticate the other mobile wallet.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Hayes with regards to spoof-check token and items of the cross-comparison package to the method of Ponnuswamy in view of Larsson and Isles in order to provide additional security such as application integrity checking and confidentiality (Hayes: ¶0021).
With respect to claim 20, the combination of Ponnuswamy in view of Larsson, Isles, and Hayes teaches the method of claim 15 (see rejection of claim 15 above) but does not disclose wherein the local device context data and the peer device context data comprise at least one of: location data, sensor data, and network data.
However, Isles teaches wherein the local device context data and the peer device context data comprise at least one of: location data, sensor data, and network data. (¶0021: In some embodiments, the physical co-location of both client devices may be established using location data such as, for example, Internet Protocol (IP) addresses, media access control (MAC) addresses, Global Positioning System (GPS) data, etc. In particular, the primary client device and the secondary client device may send, to the service provider platform, the authentication token appended with respective location data.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Isles with regards to the peer device context to the method of Ponnuswamy in view of Larsson and Hayes in order to prevent fraudulent actions such as falsifying information (Isles : ¶0003).
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over in view of Ponnuswamy et al. (US PGPub No. 20230009739-A1) in view of Larsson et al. (US PGPub No. 20130340063-A1), Isles et al. (US PGPub No. 20230137767-A1), Hayes et al. (US Pat No.10057225-B1), and Schultz et al. (US PGPub No. 20160337127-A1) .
With respect to claim 2, the combination of Ponnuswamy in view of Larsson, Isles, and Hayes teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose wherein the instructions, when executed by the at least one processor, cause the at least one processor to at least: detect, by the first client device, that the second client device is accessible for peer-to-peer communications over a network.
However, Schultz teaches wherein the instructions, when executed by the at least one processor, cause the at least one processor to at least: detect, by the first client device, that the second client device is accessible for peer-to-peer communications over a network. ( ¶0013: Implementations described herein may permit endpoints to communicate asynchronously and securely by using a combination of digital certificates and associated tokens. An endpoint association (or a trust relationship between endpoints) may be created using digital certificates, endpoint fingerprinting, and context information for client-server and P2P communications.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Schultz with regards to a peer to peer network to the method of Ponnuswamy in view of Larsson, Isles, and Hayes in order to ensure secure communications (Schultz: ¶0013).
With respect to claim 9, the combination of Ponnuswamy in view of Larsson, Isles, and Hayes teaches the method of claim 8 (see rejection of claim 8 above) wherein the instructions, when executed by the at least one processor, cause the first client device to at least: detect that the second client device is accessible for peer-to-peer communications over a network.
However, Schultz wherein the instructions, when executed by the at least one processor, cause the first client device to at least: detect that the second client device is accessible for peer-to-peer communications over a network. ( ¶0013: Implementations described herein may permit endpoints to communicate asynchronously and securely by using a combination of digital certificates and associated tokens. An endpoint association (or a trust relationship between endpoints) may be created using digital certificates, endpoint fingerprinting, and context information for client-server and P2P communications.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Schultz with regards to a peer to peer network to the method of Ponnuswamy in view of Larsson, Isles, and Hayes in order to ensure secure communications (Schultz: ¶0013).
With respect to claim 16, the combination of Ponnuswamy in view of Larsson, Isles, and Hayes teaches the method of claim 15 (see rejection of claim 15 above) but does not disclose further comprising: detecting, by the first client device, that the second client device is accessible for peer-to- peer communications over a network.
However, Schultz teaches further comprising: detecting, by the first client device, that the second client device is accessible for peer-to- peer communications over a network. (¶0013: Implementations described herein may permit endpoints to communicate asynchronously and securely by using a combination of digital certificates and associated tokens. An endpoint association (or a trust relationship between endpoints) may be created using digital certificates, endpoint fingerprinting, and context information for client-server and P2P communications.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Schultz with regards to a peer to peer network to the method of Ponnuswamy in view of Larsson, Isles, and Hayes in order to ensure secure communications (Schultz: ¶0013).
Claims 3-4, 10-11, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Ponnuswamy et al. (US PGPub No. 20230009739-A1) in view of Larsson et al. (US PGPub No. 20130340063-A1), Isles et al. (US PGPub No. 20230137767-A1), Hayes et al. (US Pat No.10057225-B1), and Kumar et al. (US PGPub No.20190163912-A1).
With respect to claim 3, the combination of Ponnuswamy in view of Larsson, Isles, and Hayes teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose wherein the preliminary cross-comparison package is encrypted using a private key uniquely assigned to the second client device by the management service.
However, Kumar teaches wherein the preliminary cross-comparison package is encrypted using a private key uniquely assigned to the second client device by the management service. (¶0075: As seen in Figure 8 and 9, at step 902, a developer 901 of provider 903 builds an update package. At step 904, a release manager of provider 903 signs the update package using the provider private key and encrypts the update package using a publisher public key to build a provider package 833.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Kumar with regards to the preliminary cross-comparison package to the method of Ponnuswamy in view of Larsson, Isles, and Hayes in order to ensure data confidentiality for devices within a system (Kumar: ¶0007).
With respect to claim 4, the combination of the combination of Ponnuswamy in view of Larsson, Isles, and Hayes teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose wherein the cross-comparison package is encrypted using a private key uniquely assigned to the first client device by the management service.
However, Kumar teaches wherein the cross-comparison package is encrypted using a private key uniquely assigned to the first client device by the management service. (¶0075: At step 916, the administrator decrypts the provider package, re-signs the update package using the publisher private key (preserving the first signing by the provider at step 904), and re-encrypts the update package using the publisher public key for secure storage.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to utilize the teachings of Kumar with regards to the cross-comparison package to the method of Ponnuswamy in view of Larsson, Isles, and Hayes in order to ensure data confidentiality for devices within a system (Kumar: ¶0007).
With respect to claim 10, the combination of Ponnuswamy in view of Larsson, Isles, and Hayes teaches the method of claim 8 (see rejection of claim 8 above) wherein the preliminary cross-comparison package is encrypted using a private key uniquely assigned to the second client device by the management service.
However, Kumar teaches wherein the preliminary cross-comparison package is encrypted using a private key uniquely assigned to the second client device by the management service. (¶0075: As seen in Figure 8 and 9, at step 902, a developer 901 of provider 903 builds an update package. At step 904, a release manager of provider 903 signs the update package using the provider private key and encrypts the update package using a publisher public key to build a provider package 833.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Kumar with regards to the preliminary cross-comparison package to the method of Ponnuswamy in view of Larsson, Isles, and Hayes in order to ensure data confidentiality for devices within a system (Kumar: ¶0007).
With respect to claim 11, the combination of Ponnuswamy in view of Larsson, Isles, and Hayes teaches the method of claim 8 (see rejection of claim 8 above) but does not disclose wherein the cross-comparison package is encrypted using a private key uniquely assigned to the first client device by the management service.
However, Kumar teaches wherein the cross-comparison package is encrypted using a private key uniquely assigned to the first client device by the management service. (¶0075: At step 916, the administrator decrypts the provider package, re-signs the update package using the publisher private key (preserving the first signing by the provider at step 904), and re-encrypts the update package using the publisher public key for secure storage.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to utilize the teachings of Kumar with regards to the cross-comparison package to the method of Ponnuswamy in view of Larsson, Isles, and Hayes in order to ensure data confidentiality for devices within a system (Kumar: ¶0007).
With respect to claim 17, the combination of Ponnuswamy in view of Larsson, Isles, and Hayes teaches the method of claim 15 (see rejection of claim 15 above) but does not disclose wherein the preliminary cross-comparison package is encrypted using a private key uniquely assigned to the second client device by the management service.
However, Kumar teaches wherein the preliminary cross-comparison package is encrypted using a private key uniquely assigned to the second client device by the management service. (¶0075: As seen in Figure 8 and 9, at step 902, a developer 901 of provider 903 builds an update package. At step 904, a release manager of provider 903 signs the update package using the provider private key and encrypts the update package using a publisher public key to build a provider package 833.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Kumar with regards to the preliminary cross-comparison package to the method of Ponnuswamy in view of Larsson, Isles, and Hayes in order to ensure data confidentiality for devices within a system (Kumar: ¶0007).
With respect to claim 18, the combination of Ponnuswamy in view of Larsson, Isles, and Hayes teaches the method of claim 15 (see rejection of claim 15 above) but does not disclose wherein the cross-comparison package is encrypted using a private key uniquely assigned to the first client device by the management service.
However, Kumar teaches wherein the cross-comparison package is encrypted using a private key uniquely assigned to the first client device by the management service. (¶0075: At step 916, the administrator decrypts the provider package, re-signs the update package using the publisher private key (preserving the first signing by the provider at step 904), and re-encrypts the update package using the publisher public key for secure storage.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to utilize the teachings of Kumar with regards to the cross-comparison package to the method of Patne in view of Tharoor, Bravo, and Soundararajan in order to ensure data confidentiality for devices within a system (Kumar: ¶0007).
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Ponnuswamy et al. (US PGPub No. 20230009739-A1) in view of Larsson et al. (US PGPub No. 20130340063-A1), Isles et al. (US PGPub No. 20230137767-A1), Hayes et al. (US Pat No.10057225-B1), and Vas et al. (US PGPub No. 20170039388-A1).
With respect to claim 7, the combination of Ponnuswamy in view of Larsson, Isles, and Hayes teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose wherein the instructions, when executed by the at least one processor, cause the at least one processor to at least: receive, from the management service, a command to perform a remedial action.
However, Vas teaches wherein the instructions, when executed by the at least one processor, cause the at least one processor to at least: receive, from the management service, a command to perform a remedial action. (¶0031: As seen in Figure 1, if it is determined that the client device 106 is not in compliance with one or more compliance rules 121, the management agent 145 or the management service 118 initiates a remedial action.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to utilize the teachings of Vas with regards to management service to the method of Ponnuswamy in view of Larsson, Isles, and Hayes in order to protect against access by unauthorized users (Vas: ¶0002-0004).
With respect to claim 14, the combination of Ponnuswamy in view of Larsson, Isles, and Hayes teaches the method of claim 8 (see rejection of claim 8 above) but does not disclose wherein the instructions, when executed by the at least one processor, cause the first client device to at least: receive, from the management service, a command to perform a remedial action.
However, Vas teaches wherein the instructions, when executed by the at least one processor, cause the first client device to at least: receive, from the management service, a command to perform a remedial action. (¶0031: As seen in Figure 1, if it is determined that the client device 106 is not in compliance with one or more compliance rules 121, the management agent 145 or the management service 118 initiates a remedial action.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to utilize the teachings of Vas with regards to management service to the method of Ponnuswamy in view of Larsson, Isles, and Hayes in order to protect against access by unauthorized users (Vas: ¶0002-0004).
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 TAYLOR P VU whose telephone number is (703)756-1218. The examiner can normally be reached MON - FRI (7:30 - 5:00).
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, Alexander Lagor can be reached at (571) 270-5143. 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.
/T.P.V./Examiner, Art Unit 2437
/MENG LI/Primary Examiner, Art Unit 2437