DETAILED ACTION
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.
This Office Action is in response to the communication filed on 01/02/2026.
Claims 1, 11, 17 and 18 have been amended.
Claims 12 and 19 have been cancelled.
Claims 21 and 22 have been added.
Claims 1-11, 13-18, and 20-22 are pending for consideration.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claims 1, 6, 11, and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Mayo in view of Beck et al. (U.S. 11,121,864)(hereinafter Beck).
Regarding claim 1, Mayo teaches intercepting, by a Universal Serial Bus (USB) firewall (Mayo: see Figure 3 item 340; Col 5 lines 41-46, “The security agent 340 interacts with functions of OS 310, e.g. intercepts requests to execute files, which are accessible through the file system 320, wherein the requests are made by e.g. applications running on the OS 310 and/or are requests made to access files by e.g. users of the computing device 110A”) of a USB device (Mayo: see Figure 4 item 410; Col 14 lines 47-53, Although FIG. 10 shows a computer device, the examples described herein may be used with a variety of network devices, including but not limited to, smartphones, tablets, network-coupled sensors, gateways, routers, switches, bridges, hubs, repeaters, proxy servers, border controllers, file servers, network-coupled storage devices, firewall devices etc”) connected to a host, a file access request for a file (Mayo: see Col 5 lines 30-34, "The security agent 340 is a software application which is arranged to intercept requests made to (or, in certain implementations, by) the OS 310 to access and execute files on the file system 320");
wherein the authorization server determines whether the file access request for the file is permitted based on a hash of the file (Mayo: see Col 13 lines 33-37, “Step 910 comprises determining if the file is included on a whitelist from a file hash. According to one method, the file hash is used as an index to determine if the file is indicated in whitelist data comprising a list of allowed files”); and
receiving a cryptographically signed message from the authorization server based on the hash of the file (Mayo: see Col 13 lines 37-40, “If it is determined that the file is included on the whitelist then at step 920 a cryptographic code is sent to the computing device 110A-110C that sent a request”), wherein the cryptographically signed message indicates whether the file access request for the file is permitted (Mayo: see Col 6 lines 35-41, “As noted, the security agent 340 is arranged to determine if the metadata 380 comprises a cryptographic code. The particular cryptographic code which allows the executable file 370 to be executed on the computing device 110A comprises a cryptographic function of at least a private key of the security server 140 in communication with the computing device and a first hash value”).
However, Mayo fails to teach transmitting the file access request for the file to an authorization server and the cryptographically signed message is generated using an Elliptic Curve Digital Signature Algorithm (ECDSA) with a private key, a name of the file, and an indication of indicates whether the file access request for the file is permitted.
Nevertheless, Beck-which is in the same field of endeavor-teaches transmitting the file access request for the file to an authorization server (Beck: see Col 4 lines 19-21, "An authorization instance can request the private signature key from the signature key leader instance") and
the cryptographically signed message is generated using an Elliptic Curve Digital Signature Algorithm (ECDSA) with a private key, a name of the file, and an indication of indicates whether the file access request for the file is permitted (Beck: see Col 6 lines 7-13, "These cryptographic algorithms are typically keyed-hash message authentication code (HMAC) algorithms. HMAC algorithms include, but are not limited to, Secure Hash Algorithm 2 (SHA-2), Rivest-Shamir-Adleman (RSA), and JSON Web Algorithms (JWA). RSA algorithms can additionally be used to encrypt the signature portion of the JWT").
Mayo and Beck are analogous art because they are from the same field of endeavor. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize Mayo’s firewall and authorization server to determine if a file access request sent using Beck’s use of an Elliptic Curve Digital Signature Algorithm to generate the authorization key and transmission of a request to an authorization server. The suggestion/motivation for doing so would be to promote consistent and centralized authorization decisions and strengthen security posture of the system.
Regarding claim 6, Mayo and Beck teach storing the cryptographically signed message in the USB device (Mayo: see Col 7 Lines 51-61, “If the metadata 380 does not comprise the cryptographic code, the security agent 340 will attempt to send a request to the security server 140; the request being for a cryptographic code of the kind previously described for the executable file 370. If the cryptographic code is generated, the code will be stored against the file in the associated metadata 380”);
intercepting, by the USB firewall of the USB device connected to the host, a subsequent file access request for the file (Mayo: see Col 5 lines 30-34, "The security agent 340 is a software application which is arranged to intercept requests made to (or, in certain implementations, by) the OS 310 to access and execute files on the file system 320"); and
utilizing the cryptographically signed message associated with the file and the host to authorize the subsequent file access request (Mayo: see Col 7 Lines 51-61, “If the metadata 380 does not comprise the cryptographic code, the security agent 340 will attempt to send a request to the security server 140; the request being for a cryptographic code of the kind previously described for the executable file 370. If the cryptographic code is generated, the code will be stored against the file in the associated metadata 380. However, if there is no response to the request then the OS 310 prevents execution of the file “m” 370 on the basis that the computing device 110A-110C has not been in communication with the security server 140, or alternatively, the security server 140 denied the request”). Motivation to combine Mayo and Beck, in the instant claim, is the same as that in claim 1.
Regarding claim 11, Mayo and Beck teach teaches receiving, at an authorization server communicatively coupled to a Universal Serial Bus (USB) device (Mayo: see Col 10 lines 17-19, “The computing device 410 is coupled to the security server 420 via a network in a similar way to the security server 140 and computing devices 110A-110B shown in FIG. 1”; see Col 14 lines 47-53, “Although FIG. 10 shows a computer device, the examples described herein may be used with a variety of network devices, including but not limited to, smartphones, tablets, network-coupled sensors, gateways, routers, switches, bridges, hubs, repeaters, proxy servers, border controllers, file servers, network-coupled storage devices, firewall devices etc”), a file access request for a file between the USB device and a host (Mayo: see Col 10 lines 26-29, “The security server 420 is arranged to receive a request from the computing device 410 over the network 495. The request comprises a file hash 450 for a file “m” stored on the computing device 410 accessible through a file system 460”);
determining that the file access request for the file is permitted based on a hash of the file (Mayo: see Col 13 lines 33-37, “Step 910 comprises determining if the file is included on a whitelist from a file hash. According to one method, the file hash is used as an index to determine if the file is indicated in whitelist data comprising a list of allowed files”);
generating a cryptographically signed message that allows the file to be shared with the host; and transmitting the cryptographically signed message to the USB device (Mayo: see Col 6 lines 35-41, “As noted, the security agent 340 is arranged to determine if the metadata 380 comprises a cryptographic code. The particular cryptographic code which allows the executable file 370 to be executed on the computing device 110A comprises a cryptographic function of at least a private key of the security server 140 in communication with the computing device and a first hash value; see Col 13 lines 37-40, If it is determined that the file is included on the whitelist then at step 920 a cryptographic code is sent to the computing device 110A-110C that sent a request”).
wherein the cryptographically signed message is generated using an Elliptic Curve Digital Signature Algorithm (ECDSA) with a private key, a name of the file, and an indication that the file is allowed to be shared with the host (Beck: see Col 6 lines 7-13, "These cryptographic algorithms are typically keyed-hash message authentication code (HMAC) algorithms. HMAC algorithms include, but are not limited to, Secure Hash Algorithm 2 (SHA-2), Rivest-Shamir-Adleman (RSA), and JSON Web Algorithms (JWA). RSA algorithms can additionally be used to encrypt the signature portion of the JWT");
and transmitting the cryptographically signed message to the USB device (Mayo: see Col 13 lines 37-40, “If it is determined that the file is included on the whitelist then at step 920 a cryptographic code is sent to the computing device 110A-110C that sent a request”). Motivation to combine Mayo and Beck, in the instant claim, is the same as that in claim 1.
Regarding claim 15, Mayo teaches determining that the hash of the file matches at least one hash in a database of allowed file hashes (Mayo: see Col 13 lines 35-41).
Regarding claim 16, Mayo teaches determining that the hash of the file does not match any hash in a database of blocked file hashes (Mayo: see Col 13 lines 42-47).
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Mayo and Beck, as applied to claims 1, 6, 11, and 15-16 above, and in further view of Farber et al. (U.S. 2012/0131058)(hereinafter Farber).
Regarding claim 21, Mayo and Beck teach the invention detailed above.
However, Mayo and Beck do not teach the cryptographically signed message selectively enables permissions for a portion of the file, wherein the portion of the file is identified based on a starting offset and an ending offset in the file that is covered by the permissions, and wherein the permissions are selected from a group consisting of: read, write, and delete.
Nevertheless, Farber-which is in the same field of endeavor-teaches the cryptographically signed message selectively enables permissions for a portion of the file, wherein the portion of the file is identified based on a starting offset and an ending offset in the file that is covered by the permissions, and wherein the permissions are selected from a group consisting of: read, write, and delete (Farber: see Page 21 Claim 1 lines 13-24, "to determine at least one signature for said particular sequence of bits, the at least one signature for the particular sequence of bits being based at least in part on the given function of at least some of the particular sequence of bits; to determine, based at least in part on said at least one signature for said particular sequence of bits, and using said list of multiple signatures, whether said device may access the particular sequence of bits; and if it is determined that said device may not access the particular sequence of bits, to cause access to the particular sequence of bits to be denied").
Mayo, Beck, and Farber are analogous art because they are from the same field of endeavor. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize Mayo and Beck’s authentication request with Farber’s signature of the sequence of bits to control fundamental and basic permissions of read, write, and delete, of the file. The suggestion/motivation for doing so would be to allow the system to provide granular control of different partitions or portions of a file.
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Mayo and Beck, as applied to claims 1, 6, 11, and 15-16 above, and in further view of Danziger et al. (U.S. 2018/0232394)(hereinafter Danziger).
Regarding claim 22, Mayo and Beck teach the invention detailed above.
However, Mayo and Beck do not teach the file access request includes an ID, a workstation name, a user name, a second factor token, a start time, an end time, a filename, an MD5 hash of the file, an SHA-256 hash of the file, and a file operation.
Nevertheless, Danziger-which is in the same field of endeavor- teaches the file access request includes an ID, a workstation name, a user name, a second factor token, a start time, an end time, a filename, an MD5 hash of the file, an SHA-256 hash of the file, and a file operation, and wherein the file operation is selected from a group consisting of: read, write, and delete (Danziger: see Page 5 paragraph 0042 lines 6-9, "The file access request can include a data file identifier, a storage server identifier, a type of the data file, a user identifier, a user device identifier, token (TPAT), and/or the like, as discussed at 201 in FIG. 2"; Page 2 paragraph 0020 lines 8-19, "Example metadata properties associated with the data file include, but are not limited to: file type, file identification, file name, Multipurpose Internet Mail Extensions (MIME) type, whether the file is starred or flagged by the file system, parent file or folder, application properties, file version, create time, modified time, last-modified user name, user identifier (ID) and email address of the owner, the requester, and the creator, full file extension, file checksum (used for comparison, the storage server can choose the encoding method (e.g. MD5, SHA1, SHA2, etc.), file size, access/editing privilege, status as to whether the file has an edit lock, or the like").
Mayo, Beck, and Danziger are analogous art because they are from the same field of endeavor. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize Mayo and Beck’s authentication request with Danziger’s request metadata. Mayo, Beck and Danziger do not explicitly teach the file operations of read, write, and delete. However, these file operations are fundamental and basic permissions of a file. The suggestion/motivation for doing so would be to allow transmit data that could be used in the validation of the access request.
Claims 2-5 are rejected under 35 U.S.C. 103 as being unpatentable over Mayo and Beck, as applied to claims 1, 6, 11, and 15-16 above, and in further view of Smith et al. (US 8,578,161)(hereinafter Smith).
Regarding claim 2, Mayo and Beck teach wherein the cryptographically signed message indicates that the file access request for the file is permitted (Mayo: see Col 6 lines 35-41, “As noted, the security agent 340 is arranged to determine if the metadata 380 comprises a cryptographic code. The particular cryptographic code which allows the executable file 370 to be executed on the computing device 110A comprises a cryptographic function of at least a private key of the security server 140 in communication with the computing device and a first hash value”), and
wherein the method further comprises: in response to receiving the cryptographically signed message (Mayo: see Col 13 lines 37-40, “If it is determined that the file is included on the whitelist then at step 920 a cryptographic code is sent to the computing device 110A-110C that sent a request”).
However, Mayo and Beck fail to teach copying the file to the host.
Nevertheless, Smith-which is in the same field of endeavor- teaches copying the file to the host (Smith: see Col 3 lines 46-50, “Thus, the peripheral device presents its private key to a connected computing device, which then authorizes functionality for its connection based on whether the peripheral device is validly authenticated and authorized”).
Mayo, Beck, and Smith are analogous art because they are from the same field of endeavor. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize Mayo and Beck’s cryptographic code for indicating validity of a file to also allow a function of the device to be executed. The suggestion/motivation for doing so would be to allow the system to authorize actions granularly.
Regarding claim 3, Mayo, Beck, and Smith teach authenticating the USB device using a hardware-generated token of a hardware authentication device (Smith: see Col 8 lines 59-62, “As illustrated, peripheral device 430 includes private key 432. In one embodiment, private key 432 is embedded on an application specific integrated circuit (ASIC) 434, which is in turn embedded on peripheral device 430; Smith: see Col 4 lines 41-48, The verifier receives a signed message from a peripheral device over a bus to which the peripheral device is connected. The verifier authenticates the signed message with the public key, and identifies device and functionality characteristics of the peripheral device responsive to the authenticating the signed message. If the peripheral device properly authenticates, the verifier can authorize the peripheral device for the identified functionality”); and
wherein the copying the file to the host occurs in further response to authenticating the USB device using the hardware-generated token of the hardware authentication device (Smith: see Col 3 lines 46-50, “Thus, the peripheral device presents its private key to a connected computing device, which then authorizes functionality for its connection based on whether the peripheral device is validly authenticated and authorized”). Motivation to combine Mayo, Beck, and Smith in the instant claim, is the same as that in claim 2.
Regarding claim 4, Mayo, Beck, and Smith teach transmitting the hardware-generated token (Beck: see Col 2 lines 2-5, “The method includes registering a plurality of authorization instances in a configuration file. The authorization instances participate in a common service. The common service being access token generation and validation”; Col 2 lines 11-17, “The method includes generating, by the signature key leader instance, a signature key pair. The signature key pair includes a public signature key and a private signature key. The method also includes storing the public signature key in the shared database and transmitting an encrypted private signature key to a requesting authorization instance within the common service of the authorization instances”). Motivation to combine Mayo, Beck, and Smith in the instant claim, is the same as that in claim 2.
Regarding claim 5, Mayo, Beck, and Smith teach the authorization server determining whether the file access request for the file is permitted is further based on the hardware-generated token (Smith: see Col 8 lines 59-62, As illustrated, peripheral device 430 includes private key 432. In one embodiment, private key 432 is embedded on an application specific integrated circuit (ASIC) 434, which is in turn embedded on peripheral device 430) and permission information associated with the file (Mayo: see Col 6 lines 35-38; Col 8 lines 45-53). Motivation to combine Mayo, Beck, and Smith, in the instant claim, is the same as that in claim 2.
Claims 7-8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Mayo and Beck, as applied to claims 1, 6, 11, and 15-16 above, and in further view of Secatch et al. (US 10,715,509)(hereinafter Secatch).
Regarding claim 7, Mayo and Beck teach the invention detailed above.
However, Mayo and Beck fail to teach automatically deleting the cryptographically signed message after a predetermined period of time.
Nevertheless, Secatch-which is in the same field of endeavor- teaches automatically deleting the cryptographically signed message after a predetermined period of time (Secatch: see Col 1 lines 66-67-Col 2 lines 1-3, “In some embodiments, the controller may be configured to identify a lapsing of the expiration time and delete the expiring encryption key upon identifying the lapsing of the expiration time”).
Mayo, Beck, and Secatch are analogous art because they are from the same field of endeavor. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize Secatch’s method for removing the authorization code from memory after an expired time period with Mayo and Beck’s authorization protocol. The suggestion/motivation for doing so would be to prevent the authorization information from being compromised and used in system attacks.
Regarding claim 8, Mayo, Beck, and Secatch teach automatically deleting the cryptographically signed message in response to disconnecting the USB device from the host (Secatch: Col 2 lines 12-15, “In some embodiments, the controller may be configured to power off the storage drive and delete the encryption key upon powering off the storage drive”). Motivation to combine Mayo, Beck, and Secatch, in the instant claim, is the same as that in claim 7.
Regarding claim 17, Mayo, Beck, and Secatch teach a USB firewall (Mayo: see Figure 3 item 340; Col 5 lines 41-46) configured to intercept a file access request for a file between the USB device and a host (Mayo: see Col 5 lines 30-34);
a USB communication subsystem (Mayo: see Figure 4 item 410; Col 14 lines 47-53) configured to transmit the file access request for the file to an authorization server (Beck: see Col 4 lines 19-21, "An authorization instance can request the private signature key from the signature key leader instance") and receive a cryptographically signed message from the authorization server that allows the file to be shared with the host (Beck: Col 4 lines 21-24, "Upon receiving the request, the signature key leader instance can validate the request and encrypt the private signature key before transmitting it to the requesting authorization instance"; Mayo: see Col 13 lines 37-40); and
a cache for storing the cryptographically signed message for a predetermined period of time (Secatch: see Col 3 lines 43-49, “In some configurations, a drive cache may be configured on a storage medium of a storage drive. For example, a storage cache may be configured on a hard disk of a hard disk drive and/or on flash memory of a solid state drive. Additionally, or alternatively, a drive cache may be configured on a storage chip separate from a storage medium of a storage drive”; Col 1 lines 66-67-Col 2 lines 1-3, “In some embodiments, the controller may be configured to identify a lapsing of the expiration time and delete the expiring encryption key upon identifying the lapsing of the expiration time”); and the authorization server communicatively coupled to the USB device (Mayo: see Col 10 lines 17-19; Col 14 lines 47-53), wherein the authorization server is configured to determine that the file access request for the file is permitted based on a hash of the file (Mayo: see Col 13 lines 33-37), and wherein the authorization server is configured to generate the cryptographically signed message based on the hash of the file (Mayo: see Col 8 lines 45-49);
wherein the cryptographically signed message is generated using an Elliptic Curve Digital Signature Algorithm (ECDSA) with a private key, a name of the file, and an indication that the file access request is permitted (Beck: see Col 6 lines 7-13, "These cryptographic algorithms are typically keyed-hash message authentication code (HMAC) algorithms. HMAC algorithms include, but are not limited to, Secure Hash Algorithm 2 (SHA-2), Rivest-Shamir-Adleman (RSA), and JSON Web Algorithms (JWA). RSA algorithms can additionally be used to encrypt the signature portion of the JWT"). Motivation to combine Mayo, Beck, and Secatch, in the instant claim, is the same as that in claim 7.
Claims 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Mayo and Beck, as applied above, and in further view of Beitler et al. (US 11,520,939)(hereinafter Beitler).
Regarding claim 9, Mayo and Beck teach the invention detailed above.
However, Mayo and Beck fail to teach the USB firewall is implemented by USB adapter hardware.
Nevertheless, Beitler-which is in the same field of endeavor- teaches the USB firewall is implemented by USB adapter hardware (Beitler: see FIG. 2A Item 200-2; Col 7 lines 51-62, “In FIG. 2A, the USB firewall 200 is illustrated as a USB firewall device 200-2. The USB firewall device 200-2 contains similar elements to those elements in the software-based USB firewall 200-1, but is physically separate from the user PC 105-2. The USB firewall device 200-2 is between the user USB device (D) 195 and the user PC 105-2. The USB firewall device 200-2 could have a female USB connector as port 111, and the user USB device 195 could have a mating female USB connector as port 108, and the user PC 105-2 could have a female USB connector as USB port 109, into which a male USB connector as USB port 112 would fit”).
Mayo, Beck, and Beitler are analogous art because they are from the same field of endeavor, securing peripheral device operations Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize Beitler’s USB firewall with Mayo and Beck’s authorization protocol. The suggestion/motivation for doing so would be to protect the host device and peripheral device from attacks that may be initiated via hardware ports.
Regarding claim 10, Mayo, Beck, and Beitler teach the USB firewall is implemented by USB driver software (Beitler: see Col 4 lines 56-59, “The software-based USB firewall 200-1 comprises a USB firewall driver 210 and controller 255, a USB packet filter 215, and a USB sanitizer 220”). Motivation to combine Mayo, Beck, and Beitler, in the instant claim, is the same as that in claim 9.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Mayo and Beck, as applied to claims 1, 6, 11, and 15-16 above, in view of Kinghorn et al. (US 7,921,284)(hereinafter Kinghorn).
Regarding claim 13, Mayo and Beck teach the invention detailed above.
However, Mayo and Beck fail to teach determining that a first authorization level associated with information stored in the file is compatible with a second authorization level associated with the host; and wherein the cryptographically signed message is further based on determining that the first authorization level is compatible with the second authorization level.
Nevertheless, Kinghorn-which is in the same field of endeavor-teaches determining that a first authorization level associated with information stored in the file (Kinghorn: see Col 6 lines 11-16, “In addition, security clearance information 107 is added to the header 106 if the secured file 108 is classified. In general, the security clearance information 107 is used to determine a level of access privilege or security level of a user who is attempting to access the contents in the secured file 108”) is compatible with a second authorization level associated with the host (Kinghorn: see Col 6 lines 22-27, “According to one embodiment, the security clearance information 107 includes another layer of encryption of the file key with another key referred to herein as a clearance key. An authorized user must have a clearance key of proper security level in addition to an authenticated user key and proper access privilege to retrieve the file key”); and wherein the cryptographically signed message is further based on determining that the first authorization level is compatible with the second authorization level (Kinghorn: see Col 3 lines 7-13, “The header includes security information that points to or includes access rules, a protection key and a file key. The access rules facilitate restrictive access to the encrypted data portion and essentially determine who/how and/or when/where the secured document can be accessed. The file key is used to encrypt/decrypt the encrypted data portion and protected by the protection key”).
Mayo, Beck, and Kinghorn are analogous art because they are from the same field of endeavor. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize Kinghorn’s file classification level and host clearance key comparison to determine access to a cryptographic file key with Mayo and Beck’s firewall authorization method. The suggestion/motivation for doing so would be to centralize access policy assignments and management within the authorization system.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Mayo, Beck, and Kinghorn, as applied to claim 13 above, and in further view of Smith.
Regarding claim 14, Mayo, Beck, and Kinghorn teach the invention detailed above.
However, Mayo, Beck and Kinghorn fail to teach the first authorization level is based on a hardware-generated token from a hardware authentication device and wherein the second authorization level is based on a second hardware-generated token from a second hardware authentication device.
Nevertheless, Smith-which is in the same field of endeavor-teaches the first authorization level is based on a hardware-generated token from a hardware authentication device (Smith: see Col 4 lines 56-64, “In one embodiment, the verifier sends an authentication request, to which the peripheral responds with a signed message, signed with the private key. The verifier then determines with the public key whether the message was validly signed. If authentication is successful, full functionality in the connection may be provided to the peripheral device (e.g., higher-speed data exchange, enhanced security features, or even allowing a secure boot from the device, or other features) instead of standard functionality when authentication fails”) and wherein the second authorization level is based on a second hardware-generated token from a second hardware authentication device (Smith: see Col 6 lines 66-67 - Col 7 lines1-6, "The assumption in system 200 is that each private key 232-234 is presented to be authenticated by public key 240. In one embodiment, computing device 210 includes additional public keys (not shown). Each peripheral device 222-224 is assigned a private key unique to the device or a group of devices to which it belongs. Peripheral devices 222-224 send signed messages 252-254, respectively, to computing device 210 for verification").
Mayo, Beck, Kinghorn, and Smith are analogous art because they are from the same field of endeavor. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to base the two-way authentication levels of Kinghorn from trusted hardware authentication tokens of Smith’s multiple peripheral devices. The suggestion/motivation for doing so would be to strengthen the security posture and prevent an attacker’s ability to compromise either device and execute an attack since the authentication will be dependent on both devices.
Claims 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mayo, Beck, and Secatch as applied to claims 7-8 and 17 above, and in further view of Smith.
Regarding claim 18, Mayo, Beck, and Secatch teach the invention detailed above.
However, Mayo, Beck, and Secatch fail to teach a hardware authentication device communicatively coupled to the USB device and configured to generate a hardware-generated token associated with the file access request; wherein the USB communication subsystem is further configured to transmit the hardware-generated token to the authorization server; and wherein the authorization server is further configured determine that the file access request for the file is permitted based on the hardware-generated token.
Nevertheless, Smith-which is in the same field of endeavor-teaches a hardware authentication device (Smith: see Col 8 lines 59-62, “As illustrated, peripheral device 430 includes private key 432. In one embodiment, private key 432 is embedded on an application specific integrated circuit (ASIC) 434, which is in turn embedded on peripheral device 430”) communicatively coupled to the USB device and configured to generate a hardware-generated token associated with the file access request (Smith: see Col 4 lines 56-58, “... the verifier sends an authentication request, to which the peripheral responds with a signed message, signed with the private key”);
wherein the USB communication subsystem is further configured to transmit the hardware-generated token to the authorization server (Smith: see Col 4 lines 41-46, "The verifier receives a signed message from a peripheral device over a bus to which the peripheral device is connected. The verifier authenticates the signed message with the public key, and identifies device and functionality characteristics of the peripheral device responsive to the authenticating the signed message");
and wherein the authorization server is further configured determine that the file access request for the file is permitted based on the hardware-generated token (Smith: see Col 4 lines 56-59, " In one embodiment, the verifier sends an authentication request, to which the peripheral responds with a signed message, signed with the private key. The verifier then determines with the public key whether the message was validly signed").
Mayo, Beck, Secatch, and Smith are analogous art because they are from the same field of endeavor. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize the authentication token of Smith’s peripheral device with the request of Mayo, Beck, and Secatch. The suggestion/motivation for doing so would be to enable to prevent spoof and replay attacks by verifying/authenticating an authorized device.
Regarding claim 20, Mayo, Beck, Secatch, and Smith teach copy the file to the host in response to receiving the cryptographically signed message (Smith: see Col 3 lines 46-50, “Thus, the peripheral device presents its private key to a connected computing device, which then authorizes functionality for its connection based on whether the peripheral device is validly authenticated and authorized”). Motivation to combine Mayo, Beck, Secatch, and Smith in the instant claim, is the same as that in claim 18.
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 KELAH JANAE MCFARLAND-BARNES whose telephone number is (571)272-5953. The examiner can normally be reached Monday through Friday 8:00am until 4:00pm Central Time.
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, Lynn D Feild can be reached at 571-272-2092. 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.
/KELAH JANAE MCFARLAND-BARNES/Examiner, Art Unit 2431
/SARAH SU/Primary Examiner, Art Unit 2431 `