DETAILED ACTION
Applicant's response with amendments filed on 12/23/2025 has been received and entered. Applicant has amended claims 1, 10, 11, 12 and 14. Claims 1-14 have been examined on the merits.
Response to Amendments/Arguments
Claim objections regarding claim 11 have been withdrawn in view of the amendments.
Claim rejections under 35 U.S.C. 112(a) and (b) for claims 10 and 12 have been withdrawn in view of the amendments.
Claim rejection under 35 U.S.C. 101 for claim 14 has been withdrawn in view of the amendments.
Applicant’s arguments with respect to claims 1-8 and 10-14 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant's arguments regarding claim 9 filed on 12/23/2025, in pages 5-6, have been fully considered but they are not persuasive.
Applicant argues:
"Regarding Claim 8 the Examiner asserts that Power discloses custom protocol data. However, Power discloses in para [0060]: "Upon detecting an attack or faulty USB device 24, mediation module 50 may prevent any unauthorized, unexpected, or malformed data (e.g., packets that do not conform to USB specification)," (i.e., data that does not conform to the USB specification)
The custom transmission protocol set forth in the claimed invention still conforms to the USB specification, but according to the claimed method, if the data transmitted by the protocol itself does not conform to the USB transmission protocol type, transmission is disconnected. That is, the data analyzed in the presently-claimed method is still parsed according to the USB specification; it is not necessarily erroneous data, as proposed by Powers.
Regarding claim 9, similar to the analysis of claim 8, the parsing for resolvable in this invention does not necessarily refer to parsing according to the USB specification, but rather according to commonly predetermined data parsing rules. That is, this invention does not directly determine whether data is resolvable based on whether it conforms with a USB transmission protocol, but rather based on the data itself. This is a fundamental difference."
Powers discloses:
"In addition, mediation module 50 may protect host device 28 against certain software based attacks. For example, mediation module 50 may be capable of detecting device emulation and malware propagation. That is, mediation module 50 may detect device emulation by identifying a change in the functionality of a connected USB device 24 without the USB device 24 being physically removed from apparatus 20. Mediation module 50 may also monitor and analyze the contents of the packets communicated between USB device 24 and host device 28. For example, mediation module 50 may identify malformed packets, or packets that contain known malware.” (Powers, [0059])
“Upon detecting an attack or faulty USB device 24, mediation module 50 may prevent any unauthorized, unexpected, or malformed data (e.g., packets that do not conform to USB specification) from being transmitted to host device 28. In addition, mediation module 50 may disable USB device 24 (e.g., disable by terminating power to USB device 24). According to some examples, as shown and described with respect to FIG. 1H, certain functions described with respect to mediation module 50, such as protecting host device 28 from protocol or software based attacks, may be performed by a software module for configuring mediation module 50 that is executed by host device 28." (Powers, [0060])
Examiner submits that Powers discloses preventing malformed data from being transmitted to the host. Powers discloses "packets that do not conform to USB specification" as a non-limiting example (“e.g.”) of malformed data. Even if the example given by Powers for malformed data is taken as limiting, a person of ordinary skill in the art would recognize that a packet that does not conform to USB specification may not be parseable and effectively non-resolvable. The claim requires determining whether the communication data is non resolvable data; and, if it is, disconnecting the communication between the USB device and the protected device. Powers identifies and prevents unauthorized, unexpected, or malformed data from being transmitted to the host device. Accordingly, Powers discloses the limitations of the claim as presented.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitations use a generic placeholder (i.e., “module”) that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are: “USB communication data analysis module, which is used for monitoring…”, and “communication protocol type determining module, implemented in the USB communication data analysis module, which is used for determining…” in claim 12.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have these limitations interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitations to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitations recite sufficient structure to perform the claimed function so as to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 10 and 12-14 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by Powers et al. (US 20140337558 A1), hereinafter Powers.
Regarding claim 1, Powers discloses a method for controlling communication between a USB device and a protected device, wherein the method is applied to a USB access control device (“mediation module 50” in “apparatus 20” – see FIG. 1A) connected with the protected device through an interface or interfaces (mediation module 50 includes a USB device interface 54 and a USB host interface 56 - see [0045], FIG. 1A), and the method comprises:
connecting a USB device to the USB access control device for authentication according to USB protocol; after the USB device is connected to the USB access control device and authenticated according to USB protocol, monitoring communication data between the USB device and the protected device (to authenticate USB device 24, upon connection to apparatus 20, mediation module 50 may identify USB device 24 using vendor identification data included in a device descriptor associated with USB device 24 – see [0053]; see also [0054-56]; mediation module 50 may also be responsible for enabling apparatus 20 to determine whether USB device 24 is communicating properly with host device 28; that is, for example, mediation module 50 may be responsible for verifying data transfers between host device 28 and USB device 24 – see [0057]; mediation module 50 may perform real-time monitoring and checking of the attached device's USB descriptors and filter potentially dangerous commands – see [0084] and [0221]);
determining a communication protocol type of the communication data according to the USB protocol specification; disconnecting the communication between the USB device and the protected device according to the communication protocol type of the communication data when the communication protocol type does not match a USB device type determined during authentication (mediation module 50 may protect host device 28 against protocol attacks from USB device 24, such as eavesdropping – see [0057]; mediation module 50 may also protect against other protocol attacks, such as a denial of service attack; a malicious USB device may improperly identify itself when sending data to host device 28; mediation module 50 may identify packets that are sent by USB device 24 at an improper time (e.g., before the packets have been requested) and disable USB device 24; mediation module 50 may detect whether USB device 24 is identifying itself appropriately, and disable USB device 24 if USB device 24 is not identifying itself appropriately; that is, for example, mediation module 50 may determine whether USB device 24 is sending the appropriate descriptor data to host device 28, and disable USB device 24 if USB device 24 is [not] using the appropriate descriptor data; mediation module 50 may disable USB device 24 by removing power from USB device 24 – see [0058]; mediation module 50 may protect host device 28 against certain software based attacks; mediation module 50 may be capable of detecting device emulation and malware propagation; that is, mediation module 50 may detect device emulation by identifying a change in the functionality of a connected USB device 24 without the USB device 24 being physically removed from apparatus 20; mediation module 50 may also monitor and analyze the contents of the packets communicated between USB device 24 and host device 28 - see [0059]; upon detecting an attack or faulty USB device 24, mediation module 50 may prevent any unauthorized, unexpected, or malformed data (e.g., packets that do not conform to USB specification) from being transmitted to host device 28; mediation module 50 may disable USB device 24 (e.g., disable by terminating power to USB device 24) see [0060]; if the connected device is not authorized to communicate with the host computing device, mediation module 50 may turn off power to the connected device and indicate that the connected device is not authorized (e.g., using indicators 44 shown in FIG. 1A) – see [0080] and [0136]; see also [0056], [0084-85], [0139], [0166-67], [0220-21], [0233], [0248] and FIGS. 1A, 1K and 10; examiner’s note: mediation module 50 actively monitors the communication between USB device 24 and host device 28 in real-time (see [0084] and [0221]) and prevents certain types of communication from passing; that is, it determines if the communication type is proper based on what it is authorized; it detects device emulation by detecting a change in the functionality of the device; that is, device type not matching the communication protocol – see [0056-60]).
Regarding claim 10, Powers discloses all the claimed subject matter recited in claim 1 above.
Furthermore, Powers discloses the method for controlling the communication between the USB device and the protected device, wherein the method further comprises: when the communication between the USB device and the protected device is disconnected, alarm information is sent to the protected device (if mediation module 50 determines that the attached USB device 24 is not valid or is not authorized to communicate with host device 28, mediation module 50 may power off USB device 24 (328); mediation module 50 may send a message to host device 28 indicating that the attached USB device 24 has been detached (i.e., powered off) (330); mediation module 50 may also send a message to host device 28 indicating why the attached USB device was not authorized or to provide other information regarding the attached USB device 24 and/or the operations of mediation module 50 – see [0136]).
Regarding claim 12, Powers discloses an apparatus (“apparatus 20” including “mediation module 50”; see FIGS. 1A, 1B, 1C) for controlling the communication between a USB device (“USB device 24”) and a protected device (“host device 28”), wherein, the apparatus is applied to a USB access control device, the USB access control device is connected with the protected device through an interface or interfaces (“USB device interface 54” and “USB host interface 56”), and the apparatus comprises:
a USB port (“USB ports 124/144”; FIG. 1D-E) and USB communication data analysis module (“mediation module 50”), which is used for monitoring the communication data between the USB device and the protected device after the USB device is connected to the USB access control device and authenticated (to authenticate USB device 24, upon connection to apparatus 20, mediation module 50 may identify USB device 24 using vendor identification data included in a device descriptor associated with USB device 24 – see [0053]; see also [0054-56]; mediation module 50 may also be responsible for enabling apparatus 20 to determine whether USB device 24 is communicating properly with host device 28; that is, for example, mediation module 50 may be responsible for verifying data transfers between host device 28 and USB device 24 – see [0057]; mediation module 50 may perform real-time monitoring and checking of the attached device's USB descriptors and filter potentially dangerous commands – see [0084] and [0221]);
a communication protocol type determining module, implemented in the USB communication data analysis module (functionality of the “mediation module 50”), which is used for determining the communication protocol type of the communication data according to the USB protocol specification (mediation module 50 may protect host device 28 against protocol attacks from USB device 24, such as eavesdropping – see [0057]; mediation module 50 may also protect against other protocol attacks, such as a denial of service attack; a malicious USB device may improperly identify itself when sending data to host device 28; mediation module 50 may identify packets that are sent by USB device 24 at an improper time (e.g., before the packets have been requested) and disable USB device 24; mediation module 50 may detect whether USB device 24 is identifying itself appropriately, and disable USB device 24 if USB device 24 is not identifying itself appropriately; that is, for example, mediation module 50 may determine whether USB device 24 is sending the appropriate descriptor data to host device 28, and disable USB device 24 if USB device 24 is [not] using the appropriate descriptor data; mediation module 50 may disable USB device 24 by removing power from USB device 24 – see [0058]; mediation module 50 may protect host device 28 against certain software based attacks; mediation module 50 may be capable of detecting device emulation and malware propagation; that is, mediation module 50 may detect device emulation by identifying a change in the functionality of a connected USB device 24 without the USB device 24 being physically removed from apparatus 20; mediation module 50 may also monitor and analyze the contents of the packets communicated between USB device 24 and host device 28 - see [0059]);
an interface control module (“isolation module 48”; see FIG. 1A) comprising a USB port, which is used for disconnecting the communication between the USB device and the protected device according to the communication protocol type of the communication data (isolation module 48 and mediation module 50 may be highly integrated, but illustrated separately for conceptual purposes. Isolation module 48 may be configured to isolate apparatus 20 from USB device 24 in the event that USB device 24 is not authorized to communicate with host device 28, or in the event that USB device 24 is malfunctioning or identified as being a potential security threat; isolation module 48 may be responsible for terminating power to USB device 24 in the event that USB device 24 is not authorized to communicate with host device 28, or in the event that USB device 24 is malfunctioning or identified as being a potential security threat – see [0043]; FIG. 1A; upon detecting an attack or faulty USB device 24, mediation module 50 may prevent any unauthorized, unexpected, or malformed data (e.g., packets that do not conform to USB specification) from being transmitted to host device 28; mediation module 50 may disable USB device 24 (e.g., disable by terminating power to USB device 24) see [0060]; if the connected device is not authorized to communicate with the host computing device, mediation module 50 may turn off power to the connected device and indicate that the connected device is not authorized (e.g., using indicators 44 shown in FIG. 1A) – see [0080] and [0136]; see also [0056], [0084-85], [0139], [0166-67], [0220-21], [0233], [0248] and FIGS. 1A, 1K and 10).
Regarding claim 13, Powers discloses an electronic device (see FIGS. 1A, 1B) comprising: one or more processors (processors 88”); a storage device for storing one or more programs (“memory 92”); wherein, when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in claim 1 (see FIGS. 1A-1E, 1L).
The remaining limitations of claim 13 refer to the method disclosed in claim 1. Therefore, claim 13 is rejected for the same reasons as set forth in the rejection of claim 1 above.
Regarding claim 14, Powers discloses a non-transitory computer-readable medium on which a computer program is stored (memory 92 may include computer-readable storage medium that is configured to store information within mediation module 50 during operation – see [0069]), wherein, when the program is executed by a processor, the method described in claim 1 is implemented.
The remaining limitations of claim 14 refer to the method disclosed in claim 1. Therefore, claim 14 is rejected for the same reasons as set forth in the rejection of claim 1 above.
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 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Powers et al. (US 20140337558 A1), as applied to claim 1 above, and further in view of Guan et al. (CN111382469A; citations based on English translation provided), hereinafter Guan.
Regarding claim 2, Powers discloses all the claimed subject matter recited in claim 1 above.
Furthermore, Powers discloses the method for controlling the communication between the USB device and the protected device, wherein, the step of determining the communication protocol type of the communication data according to the USB protocol specification comprises: according to the USB protocol specification, obtaining the communication protocol information from the communication data (mediation module 50 may be responsible for verifying data transfers between host device 28 and USB device 24 – see [0057]; mediation module 50 may detect whether USB device 24 is identifying itself appropriately, and disable USB device 24 if USB device 24 is not identifying itself appropriately; for example, mediation module 50 may determine whether USB device 24 is sending the appropriate descriptor data to host device 28, and disable USB device 24 if USB device 24 is using the appropriate descriptor data – see [0058]; mediation module 50 may detect device emulation by identifying a change in the functionality of a connected USB device 24 without the USB device 24 being physically removed from apparatus 20; mediation module 50 may also monitor and analyze the contents of the packets communicated between USB device 24 and host device 28 – see [0059]; mediation module 50 may perform real-time monitoring and checking of the attached device's USB descriptors and filter potentially dangerous commands – see [0084]; see also [0167], [0220-21] and [0233]; examiner’s note: mediation module 50 actively monitors the communication between USB device 24 and host device 28 in real-time (see [0084] and [0221]) and prevents certain types of communication from passing; that is, it determines if the communication type is proper based on what it is authorized; it detects device emulation by detecting a change in the functionality of the device; that is, device type not matching the communication protocol – see [0056-60]).
Powers also discloses different types of USB devices connected to the host via mediation unit: storage devices 1024A (bulk), camera 1024B (isochronous), PID 1024C (peripheral input device or human interface device – interrupt) and PC devices 1024D. These devices communicate according to standard USB communication – see [0142-0180], FIG. 1L.
Powers does not explicitly disclose according to the communication protocol information, determining that the communication protocol type of the communication data is batch transmission protocol.
However, Guan discloses a method for signal transmission management and system to ensure information security in USB host devices to effectively prevent USB slave devices from copying data from USB host devices and prevent the use of prohibited devices, thereby ensuring the information security of USB host devices (see [0001-0010]) including determining that the communication protocol type of the communication data is batch transmission protocol (if the host computer device 40 is pre-configured to not support bulk transmission, and the transmission type corresponding to the acquired USB signal is control transmission, then the transmission device 30 controls the transmission of the USB signal; if the transmission type corresponding to the acquired USB signal is bulk transmission, then the transmission device 30 blocks the USB signal so that it cannot be transmitted; the host computer device 40 is pre-configured to support control transmission and interrupt transmission; if the transmission type corresponding to the acquired USB signal is control transmission, then the transmission device 30 controls the transmission of the USB signal; if the transmission type corresponding to the acquired USB signal is bulk transmission, then the transmission device 30 blocks the USB signal so that it cannot be transmitted – see [0039]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method in Powers to include determining that the communication protocol type of the communication data is batch transmission protocol, as taught by Guan. One would have been motivated to make such a combination because if the USB signal meets the transmission type shielding conditions, in this case “bulk”, the user is not able to copy data to the USB storage device effectively improving data security protection levels, as recognized by Guan (see [0077]).
Regarding claim 3, Powers and Guan disclose all the claimed subject matter recited in claim 2 above.
Furthermore, Powers discloses the step of disconnecting the communication between the USB device and the protected device according to the communication protocol type of the communication data (as explained in claim 1 above; see also [0056-60], [0080], [0136] and [0139]).
Powers does not explicitly disclose the method for controlling the communication between the USB device and the protected device, wherein, the step of disconnecting the communication between the USB device and the protected device according to the communication protocol type of the communication data comprises: if the communication protocol type of the communication data is batch transmission protocol, disconnecting the communication between the USB device and the protected device.
However, Guan discloses the step of disconnecting the communication between the USB device and the protected device according to the communication protocol type of the communication data comprises: if the communication protocol type of the communication data is batch transmission protocol, disconnecting the communication between the USB device and the protected device (if the host computer device 40 is pre-configured to not support bulk transmission, and the transmission type corresponding to the acquired USB signal is control transmission, then the transmission device 30 controls the transmission of the USB signal; if the transmission type corresponding to the acquired USB signal is bulk transmission, then the transmission device 30 blocks the USB signal so that it cannot be transmitted; the host computer device 40 is pre-configured to support control transmission and interrupt transmission; if the transmission type corresponding to the acquired USB signal is control transmission, then the transmission device 30 controls the transmission of the USB signal; if the transmission type corresponding to the acquired USB signal is bulk transmission, then the transmission device 30 blocks the USB signal so that it cannot be transmitted – see [0039]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method in Powers to include the step of disconnecting the communication between the USB device and the protected device according to the communication protocol type of the communication data comprises: if the communication protocol type of the communication data is batch transmission protocol, disconnecting the communication between the USB device and the protected device, as taught by Guan. One would have been motivated to make such a combination because if the USB signal meets the transmission type shielding conditions, in this case “bulk”, the user is not able to copy data to the USB storage device effectively improving data security protection levels, as recognized by Guan (see [0077]).
Claims 4-7 are rejected under 35 U.S.C. 103 as being unpatentable over Powers et al. (US 20140337558 A1), as applied to claim 1 above, and further in view of Appleboum et al. (US 20200226298 A1), hereinafter Appleboum.
Regarding claim 4, Powers discloses all the claimed subject matter recited in claim 1 above.
Furthermore, Powers discloses the method for controlling the communication between USB device and protected device, wherein, the step of determining the communication protocol type of the communication data according to the USB protocol specification comprises: according to the USB protocol specification, obtaining the communication protocol information from the communication data (mediation module 50 may be responsible for verifying data transfers between host device 28 and USB device 24 – see [0057]; mediation module 50 may detect whether USB device 24 is identifying itself appropriately, and disable USB device 24 if USB device 24 is not identifying itself appropriately; for example, mediation module 50 may determine whether USB device 24 is sending the appropriate descriptor data to host device 28, and disable USB device 24 if USB device 24 is using the appropriate descriptor data – see [0058]; mediation module 50 may detect device emulation by identifying a change in the functionality of a connected USB device 24 without the USB device 24 being physically removed from apparatus 20; mediation module 50 may also monitor and analyze the contents of the packets communicated between USB device 24 and host device 28 – see [0059]; mediation module 50 may perform real-time monitoring and checking of the attached device's USB descriptors and filter potentially dangerous commands – see [0084]; see also [0167], [0220-21] and [0233]; examiner’s note: mediation module 50 actively monitors the communication between USB device 24 and host device 28 in real-time (see [0084] and [0221]) and prevents certain types of communication from passing; that is, it determines if the communication type is proper based on what it is authorized; it detects device emulation by detecting a change in the functionality of the device; that is, device type not matching the communication protocol – see [0056-60]).
Powers also discloses different types of USB devices connected to the host via mediation unit: storage devices 1024A (bulk), camera 1024B (isochronous), PID 1024C (peripheral input device or human interface device – interrupt) and PC devices 1024D. These devices communicate according to standard USB communication – see [0142-0180], FIG. 1L.
Powers does not explicitly disclose according to the communication protocol information, determining that the communication protocol type of the communication data is synchronous transmission protocol.
However, Appleboum discloses a method for securing a computer system from threats introduced by USB devices and related vulnerabilities (see abstract) including determining that the communication protocol type of the communication data is synchronous transmission protocol (when a USB-Audio Microphone is plugged in, it is expected to provide only audio functionality, while in effect such a device could also impersonate a keyboard or a mouse, capable of injecting malicious commands – see [0018]; Embodiment 30…includes e.g. in combination with any other embodiment described herein, a dongle […] that plugs into a port of a computer (say) and is operative for monitoring and securing the usage of that port, including security of data flowing in and out of the computer from/to a USB (say) device that is attached through the dongle and the port – see [0248-0251]; for example an USB-Audio Microphone device which can also support an HID interface which allows the device to inject key strokes to the end-point; in most cases there may be a perfect matching between what the device is perceived to do (aka ostensibly does) and what it actually does, however, typically, the system's aim is to detect cases where the above do not match; USB Security suite typically deepens understanding by determining what USB device is really connected to the end-point's USB port, as opposed to what is ostensibly connected; a true understanding of the actual functionality that is supported by the connected device provides information which may be used as an input, in logic configured for determining the security scheme – see [0252-0253]; examiner’s note: A/V devices such as microphones use isochronous (synchronous) transfers and Appleboum discloses making the distinction between device functionality by monitoring and securing ports and data flowing between USB devices and the host).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method in Powers to include determining that the communication protocol type of the communication data is synchronous transmission protocol, as taught by Appleboum. One would have been motivated to make such a combination because some device may support extended functionalities (e.g., a microphone, typically isochronous, may support a HID interface (interrupt)), thus it is important to be able to determine the actual functionality and if it poses a potential threat, as recognized by Appleboum (see [0253]).
Regarding claim 5, Powers and Appleboum disclose all the claimed subject matter recited in claim 4 above.
Furthermore, Powers discloses the method for controlling the communication between USB device and protected device, wherein, the step of disconnecting the communication between the USB device and the protected device according to the communication protocol type of the communication data (as explained in claim 1 above; see also [0056-60], [0080], [0136] and [0139]).
Powers does not disclose if the communication protocol type of the communication data is the synchronous transmission protocol, determining the data flow direction of the communication data; if the data flow direction is from the protected device to the USB device, disconnecting the communication between the USB device and the protected device.
However, Appleboum discloses if the communication protocol type of the communication data is the synchronous transmission protocol, determining the data flow direction of the communication data; if the data flow direction is from the protected device to the USB device, disconnecting the communication between the USB device and the protected device (a system according to any of the preceding embodiments wherein the hardware based uni-directional data flow limiter invokes an input-only state, and is used in conjunction with a USB port, thereby to protect the computer system against data leakage, while an input oriented peripheral is communicating with the USB port – see [0214]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method in Powers to if the communication protocol type of the communication data is the synchronous transmission protocol, determining the data flow direction of the communication data; if the data flow direction is from the protected device to the USB device, disconnecting the communication between the USB device and the protected device, as taught by Appleboum. One would have been motivated to make such a combination to protect the computer system against data leakage, as recognized by Appleboum (see [0214]).
Regarding claim 6, Powers discloses all the claimed subject matter recited in claim 1 above.
Furthermore, Powers discloses the method for controlling the communication between the USB device and the protected device, wherein, the step of determining the communication protocol type of the communication data according to the USB protocol specification comprises: according to the USB protocol specification, obtaining the communication protocol information from the communication data (mediation module 50 may be responsible for verifying data transfers between host device 28 and USB device 24 – see [0057]; mediation module 50 may detect whether USB device 24 is identifying itself appropriately, and disable USB device 24 if USB device 24 is not identifying itself appropriately; for example, mediation module 50 may determine whether USB device 24 is sending the appropriate descriptor data to host device 28, and disable USB device 24 if USB device 24 is using the appropriate descriptor data – see [0058]; mediation module 50 may detect device emulation by identifying a change in the functionality of a connected USB device 24 without the USB device 24 being physically removed from apparatus 20; mediation module 50 may also monitor and analyze the contents of the packets communicated between USB device 24 and host device 28 – see [0059]; mediation module 50 may perform real-time monitoring and checking of the attached device's USB descriptors and filter potentially dangerous commands – see [0084]; see also [0167], [0220-21] and [0233]; examiner’s note: mediation module 50 actively monitors the communication between USB device 24 and host device 28 in real-time (see [0084] and [0221]) and prevents certain types of communication from passing; that is, it determines if the communication type is proper based on what it is authorized; it detects device emulation by detecting a change in the functionality of the device; that is, device type not matching the communication protocol – see [0056-60]).
Powers also discloses different types of USB devices connected to the host via mediation unit: storage devices 1024A (bulk), camera 1024B (isochronous), PID 1024C (peripheral input device or human interface device – interrupt) and PC devices 1024D. These devices communicate according to standard USB communication – see [0142-0180], FIG. 1L.
Powers does not explicitly disclose according to the communication protocol information, determining that the communication protocol type of the communication data is the interrupt transmission protocol.
However, Appleboum discloses according to the communication protocol information, determining that the communication protocol type of the communication data is the interrupt transmission protocol (data model, which identifies the composite keyboard as a composite device holding two sub-class HID devices (as indicated in the bNumInterfaces property) […] Transfer Type: Interrupt – see [0142-0173]; Embodiment 30…includes e.g. in combination with any other embodiment described herein, a dongle […] that plugs into a port of a computer (say) and is operative for monitoring and securing the usage of that port, including security of data flowing in and out of the computer from/to a USB (say) device that is attached through the dongle and the port – see [0248-0251]; for example an USB-Audio Microphone device which can also support an HID interface which allows the device to inject key strokes to the end-point; in most cases there may be a perfect matching between what the device is perceived to do (aka ostensibly does) and what it actually does, however, typically, the system's aim is to detect cases where the above do not match; USB Security suite typically deepens understanding by determining what USB device is really connected to the end-point's USB port, as opposed to what is ostensibly connected; a true understanding of the actual functionality that is supported by the connected device provides information which may be used as an input, in logic configured for determining the security scheme – see [0252-0253]; see also [0270-0289]; examiner’s note: HID devices such as keyboards use interrupt transfers and Appleboum discloses making the distinction between device functionality by monitoring and securing ports and data flowing between USB devices and the host).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method in Powers to include determining that the communication protocol type of the communication data is synchronous transmission protocol, as taught by Appleboum. One would have been motivated to make such a combination because it is important to be able to determine the actual functionality of a device and if it poses a potential threat, as recognized by Appleboum (see [0253]).
Regarding claim 7, Powers and Appleboum disclose all the claimed subject matter recited in claim 6 above.
Furthermore, Powers discloses the method for controlling the communication between the USB device and the protected device, wherein, the step of disconnecting the communication between the USB device and the protected device according to the communication protocol type of the communication data (as explained in claim 1 above; see also [0056-60], [0080], [0136] and [0139]).
Powers does not disclose if the communication protocol type of the communication data is the interrupt transmission protocol, determining the data flow direction of the communication data; if the data flow direction is from the protected device to the USB device, disconnecting the communication between the USB device and the protected device.
However, Appleboum discloses if the communication protocol type of the communication data is the interrupt transmission protocol, determining the data flow direction of the communication data; if the data flow direction is from the protected device to the USB device, disconnecting the communication between the USB device and the protected device (a system according to any of the preceding embodiments wherein the hardware based uni-directional data flow limiter invokes an input-only state, and is used in conjunction with a USB port, thereby to protect the computer system against data leakage, while an input oriented peripheral is communicating with the USB port – see [0214]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method in Powers to include if the communication protocol type of the communication data is the interrupt transmission protocol, determining the data flow direction of the communication data; if the data flow direction is from the protected device to the USB device, disconnecting the communication between the USB device and the protected device, as taught by Appleboum. One would have been motivated to make such a combination to protect the computer system against data leakage, as recognized by Appleboum (see [0214]).
Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Powers et al. (US 20140337558 A1), as applied to claim 1 above, and further in view of Quraishi et al. (US 20040254014 A1), hereinafter Quraishi.
Regarding claim 8, Powers discloses all the claimed subject matter recited in claim 1 above.
Furthermore, Powers discloses the method for controlling the communication between the USB device and the protected device, wherein, the step of determining the communication protocol type of the communication data according to the USB protocol specification comprises: according to the USB protocol specification, obtaining the communication protocol information from the communication data (mediation module 50 may be responsible for verifying data transfers between host device 28 and USB device 24 – see [0057]; mediation module 50 may detect whether USB device 24 is identifying itself appropriately, and disable USB device 24 if USB device 24 is not identifying itself appropriately; for example, mediation module 50 may determine whether USB device 24 is sending the appropriate descriptor data to host device 28, and disable USB device 24 if USB device 24 is using the appropriate descriptor data – see [0058]; mediation module 50 may detect device emulation by identifying a change in the functionality of a connected USB device 24 without the USB device 24 being physically removed from apparatus 20; mediation module 50 may also monitor and analyze the contents of the packets communicated between USB device 24 and host device 28 – see [0059]; mediation module 50 may perform real-time monitoring and checking of the attached device's USB descriptors and filter potentially dangerous commands – see [0084]; see also [0167], [0220-21] and [0233]; examiner’s note: mediation module 50 actively monitors the communication between USB device 24 and host device 28 in real-time (see [0084] and [0221]) and prevents certain types of communication from passing; that is, it determines if the communication type is proper based on what it is authorized; it detects device emulation by detecting a change in the functionality of the device; that is, device type not matching the communication protocol – see [0056-60]).
Powers also discloses different types of USB devices connected to the host via mediation unit: storage devices 1024A (bulk), camera 1024B (isochronous), PID 1024C (peripheral input device or human interface device – interrupt) and PC devices 1024D. These devices communicate according to standard USB communication – see [0142-0180], FIG. 1L.
Powers does not explicitly disclose according to the communication protocol information, determining that the communication protocol type of the communication data is a user-defined transmission protocol.
However, Quraishi discloses protocols and standards for USB peripheral communications (see [0020-37]) including according to the communication protocol information, determining that the communication protocol type of the communication data is a user-defined transmission protocol (developers are free to choose standard device class specifications or develop a custom protocol as warranted by the application as long as the communications remain within the realm of the framework provided by the USB standards – see [0196]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method in Powers to include according to the communication protocol information, determining that the communication protocol type of the communication data is a user-defined transmission protocol, as taught by Quraishi. One would have been motivated to make such a combination because in Powers USB device 24 and host device 28 may be configured to communicate according to another USB specification, such as USB 3.0, or other standards or proprietary communication specifications that are currently available or may emerge in the future (see [0035]) and communication between USB device 24 and host device 28 is monitored in real-time (see [0084] and [0221]) to prevent certain types of communication from passing (see [0056-60]) as explained in claim 1 above; thus, identifying a custom communication protocol that remains within the framework of USB standards is necessary to provide robust security.
Regarding claim 9, Powers and Quraishi disclose all the claimed subject matter recited in claim 8 above.
Furthermore, Powers discloses the method for controlling the communication between the USB device and the protected device, wherein, the step of disconnecting the communication between the USB device and the protected device according to the communication protocol type of the communication data comprises: (mediation module 50 may also monitor and analyze the contents of the packets communicated between USB device 24 and host device 28; mediation module 50 may identify malformed packets, or packets that contain known malware – see [0059]; upon detecting an attack or faulty USB device 24, mediation module 50 may prevent any unauthorized, unexpected, or malformed data (e.g., packets that do not conform to USB specification) from being transmitted to host device 28; mediation module 50 may disable USB device 24 (e.g., disable by terminating power to USB device 24) – see [0060]; upon detecting an attack or faulty USB device 1024, proxy/firewall units 1048 may prevent any unauthorized, unexpected, or malformed data (e.g., packets that do not conform to USB specification) from being transmitted to host computing device 1028; proxy/firewall units 1048 may cease communication with the attacking or faulty USB device 1024 (e.g., by causing electronic protection units 1044 to terminate power to USB devices 1024) – see [0169]).
Powers does not explicitly disclose the communication protocol type of the communication data is the user-defined transmission protocol.
However, Quraishi discloses the communication protocol type of the communication data is the user-defined transmission protocol (developers are free to choose standard device class specifications or develop a custom protocol as warranted by the application as long as the communications remain within the realm of the framework provided by the USB standards – see [0196]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method in Powers to include the communication protocol type of the communication data is the user-defined transmission protocol, as taught by Quraishi. One would have been motivated to make such a combination because in Powers USB device 24 and host device 28 may be configured to communicate according to another USB specification, such as USB 3.0, or other standards or proprietary communication specifications that are currently available or may emerge in the future (see [0035]) and communication between USB device 24 and host device 28 is monitored in real-time (see [0084] and [0221]) to prevent certain types of communication from passing (see [0057-60]) as explained in claim 1 above; thus, recognizing a custom communication protocol that remains within the framework of USB standards is necessary to provide robust security.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Powers et al. (US 20140337558 A1), as applied to claim 1 above, and further in view of Takezawa et al. (US 20190278730 A1), hereinafter Takezawa.
Regarding claim 11, Powers discloses all the claimed subject matter recited in claim 1 above.
Furthermore, Powers discloses mediation module 50 having a pushbutton 76; if pushbutton 76 is depressed at power up, but no configuration activity occurs within a specified period of time, apparatus 20 may time out and disable the ability to configure apparatus 20 – see [0062].
Powers does not disclose the method for controlling the communication between the USB device and the protected device, wherein the method further comprises: before the USB access control device is powered on, turning on a switch deployed in the USB access control device, so that the USB device can communicate with the protected device normally; or after the USB access control device is powered on, turning off the switch deployed in the USB access control device and trigger the authentication of the USB device.
However, Takezawa discloses USB management system and method using a USB relay device having a connection switching unit for switching a connection state between a first connector portion to which a USB client is connected and a second connector portion which is connected to a USB host controller (see abstract), wherein the method for controlling the communication between the USB device and the protected device further comprises: before the USB access control device is powered on, turning on a switch deployed in the USB access control device, so that the USB device can communicate with the protected device normally; or after the USB access control device is powered on, turning off the switch deployed in the USB access control device and trigger the authentication of the USB device (in the USB relay device 10 (refer to FIG. 5), when the second connector portion 12 is connected to the USB port of the computer to be an example of the USB host controller 70, power is supplied from the computer to the USB relay device 10 via the second connector portion 12; at this time, as shown in FIG. 2, the movable contact 21_1 of the first switch unit 21 is connected to the side of the fixed contact 21_3 and the movable contact 22_1 of the second switch unit 22 is connected to the side of the fixed contact 22_2; this state is an initial state of the USB relay device 10; since the first connector portion 11 and the second connector portion 12 are not electrically connected, [this] state becomes the “cutoff state” – see [0054]; in the initial state, the pseudo USB host controller 31 of the control unit 23 monitors the connection of the USB device (USB client 60) to the first connector portion (step S21); when the USB device is connected, communication is performed between the pseudo USB host controller 31 and the USB device; by the communication, the pseudo USB host controller 31 acquires information of a type (for example, a device type or an interface type) of the USB device, according to a USB communication protocol (step S22) – see [0055]; then the enumeration process continues with step S23 as discussed in [0056-59] and shown in FIGS. 5 and 6).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to modify the method in Powers to include the method for controlling the communication between the USB device and the protected device, wherein the method further comprises: after the USB access control device is powered on, turning off the switch deployed in the USB access control device and trigger authentication of the USB device, as taught by Takezawa. One would have been motivated to make such a combination to prevent the use of unexpected USB devices by switching control of a connection state, as recognized by Takezawa (see [0010]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Non-Patent Literature
Kharraz et al. (2019): {USBESAFE}: An {End-Point} Solution to Protect Against {USB-Based} Attacks
Neugschwandtner et al. (2016, April): A transparent defense against USB eavesdropping attacks
Shafique et al. (2019, February): Towards protection against a USB device whose firmware has been compromised or turned as ‘BadUSB’
Tian et al. (2016): Making {USB} great again with {USBFILTER}
Tian, J. (2019): Defending Operating Systems from Malicious Peripherals
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 DORIANNE ALVARADO DAVID whose telephone number is (571)272-4228. The examiner can normally be reached 9:00am-5:00pm ET.
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, Philip Chea can be reached at (571) 272-3951. 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.
/DORIANNE ALVARADO DAVID/Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights