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 .
Detailed Action
Claims 1, 4, 11, 12, 15, 17, 18-20 are amended
The objection to claim 17 has been overcome due to Applicant’s amendment
USC 112(b) rejection for claims 4-7, 11-14, and 17-19 has been overcome due to Applicant’s amendment
Claims 1-20 are pending.
Priority
The present application claims the benefit of U.S. Provisional Patent Application No. 63/613,707, filed Dec. 21, 2023. Therefore, the effective filing date of this application is 12/21/2023.
Response to Arguments
Applicant’s arguments filed on 07/05/2026 have been fully considered.
With respect to the objection to claim 17. The objection has been overcome due to Applicant’s amendment.
With respect to the USC 112(b) rejection for claims 4-7, 11-14, and 17-19. The rejection has been overcome due to Applicant’s amendments.
With respect to the USC 103 rejection Applicant has argued that SKELTON-MORITA fail to teach the newly amended limitation of “determine whether to disconnect the external storage device in response to detecting the insertion of the external storage device by performing a first authentication check on the external storage device, wherein the external storage device is disconnected in response to a determination that the external storage device did not pass the first authentication check”. Examiner is now no longer relying on MORITA to teach the limitations of claim 1. Examiner is now relying on a new reference REGUPATHY to teach this limitation. REGUPATHY teaches ([REGUPATHY, para. 0021] “Still with reference to FIG. 1, during normal operation of the client system, at block 120 the cloud server may detect connection of a peripheral device coupled to the client system. For example, a given USB or other peripheral device may be coupled to the client system”) ([REGUPATHY, para. 0022] “Next at block 130, the cloud server issues an authentication request to the client system. This request may be in the form of a GET_DIGESTS request according to a USB Type-C authentication protocol (e.g., according to the USB-C Authentication Specification, revision 1.0, or any other version, modification or variation thereof)”) ([REGUPATHY, para. 0024] “Control next passes to block 150 where an authentication protocol may be performed with the client system to obtain authentication information of the peripheral device.”) ([REGUPATHY, para. 0025] “Otherwise, the peripheral device is not authenticated, and control passes to block 170 where the cloud server may send an authorization failure message to the client system. In response to this authorization failure message, the client system may disconnect from the peripheral device.”) ([REGUPATHY, para. 0031] “Otherwise if it is determined that the authentication was not successful, control passes to block 280 where the peripheral device may be disconnected, e.g., by disabling the USB or other connection between the devices.”). As can be seen from these citations REGUPATHY teaches of detecting a connection of client device and a USB. Performing authentication of the USB and if the authentication fails disconnecting the USB device from the client device. Therefore, REGUPATHY teaches this newly amended limitation.
Additional arguments are moot in view of new grounds of rejection necessitated by the claim amendments.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 4-10, 15-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over SKELTON (US-20220181012-A1) in view of REGUPATHY (US-20200329040-A1), hereinafter SKELTON-REGUPATHY.
Regarding claim 1, SKELTON teaches “A device comprising: an external storage device interface; ([SKELTON, para. 0016] “FIG. 1 illustrates an example system 100 including a device 102 that is receiving a software update from an external device 104. The device 102 shown in FIG. 1 is a defibrillator (e.g., an external defibrillator), but it is to be appreciated that, in other examples, the device 102 may represent a different type of medical device, such as a patient monitor, or a similar medical device.”) ([SKELTON, para. 0018] “As shown in FIG. 1, the device 102 is configured to communicate with external devices 104 over any suitable communication medium. For example, FIG. 1 shows the device 102 as communicating with a server computer(s) 104(1) over a computer network 110. … server computer(s) 104(1) is configured to collect data from devices, such as the device 102, and is configured to send data to devices, such as the device 102. FIG. 1 also depicts a PC 104(2) that is communicatively coupled to the device 102 over a wired connection 112. Accordingly, the device 102, in some examples, is equipped with one or more physical ports (e.g., an access port(s)) to facilitate the wired connection to a collocated external device 104 and/or to a communication network(s) 110.”) a processor; and a memory storing computer-executable instructions that, when executed by the processor, cause the processor to: perform one or more device-specific tasks while operating in a first mode of operation; ([SKELTON, para. 0015] “The first software application is sometimes referred to herein as a “clinical application” that is used while the defibrillator is in a main mode of operation, sometimes referred to herein as the “patient mode.” The second software application, in some examples, is a “setup application” that is used while the defibrillator is in a “setup mode.” Another example of a second software application is an “install application” that is used while the defibrillator is in an “install mode” to install new software on the defibrillator. … separately-compiled software applications are executed independently on a given processor of the defibrillator. In other words, two separately-compiled software applications may be prevented from executing on the same processor contemporaneously, which provides independence of the execution of a given software application that is executed by the processor. Among other things, isolating the execution of the clinical application from the setup application—e.g., through separately-compiled code—allows the defibrillator to be “brought online” quickly after the defibrillator is powered on (from a powered off state). The ability to ready the defibrillator quickly after powering on the defibrillator is due, at least in part, to the ability of a processor of the defibrillator”) detect an insertion of an external storage device into the external storage device interface; ([SKELTON, para. 0020] “The BootROM of the processor(s) can then wait for the connected external device 104 (e.g., a personal computer (PC)) to deliver the QnxIPL and QnxAltOS (See detail below) directly into RAM of the device 102, and then issue a jump command to trigger QnxIPL. That in turn boots QnxAltOS. At this time, a connection (e.g., openssl connection) to the device 102 is available. The external device 104 is now able to execute commands on the device 102 to download software and initiate the install.”) ([SKELTON, para. 0030] “FIG. 2 illustrates a schematic diagram 200 of an example software update process. … At 204, an external device 104 starts executing an application (abbreviated to “app” in FIG. 2), to facilitate the software update for the device 102. The external device 104 possesses the new software 114 that is to be installed on the device 102. … the device 102 and the external device 104 are communicatively connected via any suitable communication medium, such as a communication network(s) 110. In the example of FIG. 2, the device 102 and the external device 104 use a suitable communication protocol for real-time data exchange during the software update process, and the external device 104 is communicatively connected to the device 102 via a communications interface(s) of the device 102, such as via a physical access port over a wired connection 112, or via Bluetooth and/or WiFi radio(s) over a wireless connection.) ([SKELTON, para. 0018] “Accordingly, the device 102, in some examples, is equipped with one or more physical ports (e.g., an access port(s)) to facilitate the wired connection to a collocated external device 104 and/or to a communication network(s) 110.”) perform a first … check on the external storage device; ([SKELTON, para. 0031] “the external device 104 and the device 102 exchange the current and desired software configuration for the device's 102 hardware configuration at 206 to determine if an update is needed. This force configuration check instruction designates the device 102 as the communication master between the two devices 102, 104, and the device 102 provides the external device 104 with information about the current configuration of the device 102 and the status of the device. Through this communications dialog (denoted by 206 in FIG. 2), the device 102 determines if a software update is needed, and the device 102 requests a software update”) transition from the first mode of operation to a second mode of operation in response to the external storage device passing the first … check, wherein the one or more device-specific tasks are suspended during the second mode of operation; ([SKELTON, para. 0031] “The installation phase of the software update is triggered if the verification at 210 passes for each file of the stored/downloaded software 114 package. According to some examples, an install application of the device 102 is included as part of an alternate operating system (OS) (e.g., safe mode in a Windows® OS), which is a minimalistic version of the OS that includes tools for installing software. The alternate OS with such install tools may allow for omitting the same install tools from the main OS, thereby preventing any accidental or intentional invocation of installation software when another program is running on the device 102.”) ([SKELTON, para. 0036] “the device 102 may set an “install lock” into the firmware to disable the device 102 from performing tasks other than completing an install of the software 114. The firmware lock is to be cleared after verification of a successful install.”) perform a second authentication check on content stored on the external storage device during the second mode of operation; and ([SKELTON, para. 0066] “At 512, the device 102 (e.g., a processor(s) of the device 102) performs a second integrity check 116(2) on the installed software 114. As described herein, the second integrity check 116(2) is performed after rebooting the device 102 into a test mode and as part of running one or more Auto-Tests on the installed software 114. In some examples, the second integrity check 116(2) is similar to the first integrity check 116(1). In some examples, the second integrity check 116(2) is performed during the installation phase as part of a software application that is separate from an install software application.”) ([SKELTON, para. 0063] “the performing of the first integrity check 116(1) involves performing the first integrity check 116(1) on all files in the working folder 302(1) of the staging area 300, which, in some scenarios, includes a copy(ies) of a file(s) that was previously copied to the working folder 302(1) as opposed to being downloaded from the external device 104.”) ([SKELTON, para. 0013] “the stored software was received over a wired connection from an external device (e.g., a PC) … the first memory in which the software is initially stored is used as a staging area to “hold” the stored software while a first integrity check is performed on the stored software.”) mount the content stored on the external storage device in response to the content stored on the external storage device passing the second authentication check. ([SKELTON, para. 0067] “At 514, the device 102 (e.g., a processor(s) of the device 102) determines whether the installed software 114 passed the second integrity check 116(2).”) ([SKELTON, para. 0068] “At 516, the device 102 is enabled for use based at least in part on the installed software 114 having passed the second integrity check 116(2). In some examples, enabling the device 102 at 516 represents, or includes, clearing the firmware lock that was set at block 509. Clearing the firmware lock enables using the device 102 to boot any of the installed applications. In examples where the device 102 is a medical device, such as a defibrillator, the device 102 can boot an application for use in association with a patient”)
However, SKELTON does not teach “… determine whether to disconnect the external storage device in response to detecting the insertion of the external storage device by performing a first authentication check on the external storage device, wherein the external storage device is disconnected in response to a determination that the external storage device did not pass the first authentication check …”
In analogous teaching REGUPATHY teaches “… determine whether to disconnect the external storage device in response to detecting the insertion of the external storage device by performing a first authentication check on the external storage device, wherein the external storage device is disconnected in response to a determination that the external storage device did not pass the first authentication check … “ ([REGUPATHY, para. 0021] “Still with reference to FIG. 1, during normal operation of the client system, at block 120 the cloud server may detect connection of a peripheral device coupled to the client system. For example, a given USB or other peripheral device may be coupled to the client system”) ([REGUPATHY, para. 0022] “Next at block 130, the cloud server issues an authentication request to the client system. This request may be in the form of a GET_DIGESTS request according to a USB Type-C authentication protocol (e.g., according to the USB-C Authentication Specification, revision 1.0, or any other version, modification or variation thereof)”) ([REGUPATHY, para. 0024] “Control next passes to block 150 where an authentication protocol may be performed with the client system to obtain authentication information of the peripheral device.”) ([REGUPATHY, para. 0025] “Otherwise, the peripheral device is not authenticated, and control passes to block 170 where the cloud server may send an authorization failure message to the client system. In response to this authorization failure message, the client system may disconnect from the peripheral device.”) ([REGUPATHY, para. 0031] “Otherwise if it is determined that the authentication was not successful, control passes to block 280 where the peripheral device may be disconnected, e.g., by disabling the USB or other connection between the devices.”)
Thus, given the teaching of REGUPATHY, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of performing a first authentication check by REGUPATHY into the teaching of a device comprising an external storage device interface, operating in a first mode and transitioning to second mode to perform authentication of content and mounting content based on passing authentication by SKELTON. One of ordinary skill in the art would have been motivated to do so because REGUPATHY recognizes the need to improve security while reducing cost ([REGUPATHY, para. 0003] “enabling newer devices connected through USB ports in future compute ecosystems. This includes devices for use in a corporate environment that implement secure access or access with policy enforcement.”) ([REGUPATHY, para. 0016] “ an authentication sequence defined by a USB-C authentication protocol can be used to authenticate, e.g., USB PD products originating from different vendors. In this way, since USB is an open standard, embodiment may help protect a host platform from security vulnerabilities. ”)
Regarding claim 15, this claim recites of a method claim that performs the features of device claim 1. Therefore, claim 15 is rejected in a similar manner as in the rejection of claim 1.
Regarding claim 20, this claim recites of a non-transitory computer-readable medium comprising instructions that, when executed by a processor of a device performs the features of device claim 1. Therefore, claim 20 is rejected in a similar manner as in the rejection of claim 1.
Regarding claims 2 and 16, SKELTON-REGUPATHY teach all limitations of claims 1 and 15. REGUPATHY further teaches “wherein, to perform the first authentication check on the external storage device, the computer-executable instructions cause the processor to: identify one or more attributes of the external storage device; and ([REGUPATHY, para. 0024] “Control next passes to block 150 where an authentication protocol may be performed with the client system to obtain authentication information of the peripheral device. In an embodiment, this information may be appended to or otherwise included with authentication information of the client system itself. In an embodiment, this authentication information may include digest information, certificate information and challenge response information. Of course, additional or different information may be received in other embodiments.”) perform a first verification process to verify an identity of the external storage device based on the one or more attributes, wherein the external storage device passes the first authentication check in response to verification of the identity of the external storage device. ([REGUPATHY, para. 0025] “Based at least in part on this information, the cloud server may determine at diamond 160 whether the peripheral device is authenticated. For example, if all of the digests, certificate and challenge response information indicate that the device is what it says is, e.g., by way of computed results matching expected results, the peripheral device may be authenticated. If so, control passes to block 180 where the cloud server may send an authorization success message to the client system. In response to this authorization success message, the client system may enable connection with the peripheral device, and can begin communicating with the peripheral device.”)
The same motivation and rejection to modify SKELTON with REGUPATHY as in the rejection of claim 1 applies.
Regarding claims 4 and 17, SKELTON-REGUPATHY teach all limitations of claims 1 and 15. SKELTON further teaches “wherein, to perform the second authentication check on the content stored on the external storage device, the computer-executable instructions cause the processor to: identify a content manifest associated with the external storage device, the content manifest indicating a list of content items that should be stored on the external storage device; ([SKELTON, para. 0046] “The device 102, in some examples, uses a manifest file 304 that describes a complete valid configuration to determine what file(s) is/are not going to change during the software update so that the device 102 is able to refrain from downloading that/those file(s) from the external device 104. A manifest file, as used herein, is a file describing corresponding content as well as one or more elements thereof. The manifest file 304 is digitally signed with a digital signature for security purposes.”) and perform a second verification process to verify the content stored on the external storage device matches the list of content items, wherein the content stored on the external storage device passes the second authentication check in response to verification that the content stored on the external storage device matches the list of content items. ([SKELTON, para. 0066] “At 512, the device 102 (e.g., a processor(s) of the device 102) performs a second integrity check 116(2) on the installed software 114. As described herein, the second integrity check 116(2) is performed after rebooting the device 102 into a test mode and as part of running one or more Auto-Tests on the installed software 114. In some examples, the second integrity check 116(2) is similar to the first integrity check 116(1). In some examples, the second integrity check 116(2) is performed during the installation phase as part of a software application that is separate from an install software application.”) ([SKELTON, para. 0063] “the performing of the first integrity check 116(1) involves performing the first integrity check 116(1) on all files in the working folder 302(1) of the staging area 300, which, in some scenarios, includes a copy(ies) of a file(s) that was previously copied to the working folder 302(1) as opposed to being downloaded from the external device 104.”) ([SKELTON, para. 0063] “At 504, the device 102 (e.g., a processor(s) of the device 102) performs a first integrity check 116(1) on the stored software 114, as described herein. In an illustrative example, the device 102, at 504, executes the following checks for each file of the stored/downloaded software 114 in the staging area 300 of the first memory 106: (i) the computed SHA-256 hash code of the file matches what is listed in the manifest file 304; (ii) the software component's part number and software version number (which is integrated in a version file) matches the version number specified in the manifest file 304”)
Regarding claim 5, SKELTON-REGUPATHY teach all limitations of claim 4. SKELTON further teaches “wherein the content stored on the external storage device matches the list of content items if each content item in the list of content items has associated content stored on the external storage device. ([SKELTON, para. 0047] “Accordingly, in some instances, the new software (SW2) 114 downloaded to the device 102 excludes one or more files, such as the file 310 if the file 310 matches a file listed in the manifest file 304 and if the file 310 passes the preliminary integrity check. Refraining from downloading files that are already installed on the device 102 allows for completing a software update process faster, as described herein. In some examples, the manifest file 304 may include a clean/fresh flag, which causes the device 102 to download and install every file without comparing the files to the previous version of the software.”) ([SKELTON, para. 0033] “the computed SHA-256 hash code of the file matches what is listed in the manifest file; (ii) the software component's part number and software version number (which is integrated in a version file) matches the version number specified in the manifest file; and (iii) the CRC for each image in the file matches the CRC listed in the corresponding version file for that image. As each file succeeds in the verification at 210 (e.g., as each file passes the first integrity check 116(1))”)
Regarding claim 6, SKELTON-REGUPATHY teach all limitations of claim 4. SKELTON further teaches “wherein the content stored on the external storage device matches the list of content items if all of the content stored on the external storage device is included in the list of content items. ([SKELTON, para. 0047] “Accordingly, in some instances, the new software (SW2) 114 downloaded to the device 102 excludes one or more files, such as the file 310 if the file 310 matches a file listed in the manifest file 304 and if the file 310 passes the preliminary integrity check. Refraining from downloading files that are already installed on the device 102 allows for completing a software update process faster, as described herein. In some examples, the manifest file 304 may include a clean/fresh flag, which causes the device 102 to download and install every file without comparing the files to the previous version of the software.”) ([SKELTON, para. 0033] “the computed SHA-256 hash code of the file matches what is listed in the manifest file; (ii) the software component's part number and software version number (which is integrated in a version file) matches the version number specified in the manifest file; and (iii) the CRC for each image in the file matches the CRC listed in the corresponding version file for that image. As each file succeeds in the verification at 210 (e.g., as each file passes the first integrity check 116(1))”)
Regarding claim 7, SKELTON-REGUPATHY teach all limitations of claim 4. SKELTON further teaches “wherein the content manifest is digitally signed. ([SKELTON, para. 0046] “The device 102, in some examples, uses a manifest file 304 that describes a complete valid configuration to determine what file(s) is/are not going to change during the software update so that the device 102 is able to refrain from downloading that/those file(s) from the external device 104. A manifest file, as used herein, is a file describing corresponding content as well as one or more elements thereof. The manifest file 304 is digitally signed with a digital signature for security purposes.”)
Regarding claim 8, SKELTON-REGUPATHY teach all limitations of claim 1. SKELTON further teaches “wherein the external storage device interface, the processor, and the memory are integrated into a medical device. ([SKELTON, para. 0016] “FIG. 1 illustrates an example system 100 including a device 102 that is receiving a software update from an external device 104. The device 102 shown in FIG. 1 is a defibrillator (e.g., an external defibrillator), but it is to be appreciated that, in other examples, the device 102 may represent a different type of medical device, such as a patient monitor, or a similar medical device.”)
Regarding claim 9, SKELTON-REGUPATHY teach all limitations of claim 8. SKELTON further teaches “wherein the medical device corresponds to a defibrillator or a patient monitor. ([SKELTON, para. 0016] “FIG. 1 illustrates an example system 100 including a device 102 that is receiving a software update from an external device 104. The device 102 shown in FIG. 1 is a defibrillator (e.g., an external defibrillator), but it is to be appreciated that, in other examples, the device 102 may represent a different type of medical device, such as a patient monitor, or a similar medical device.”)
Regarding claim 10, SKELTON-REGUPATHY teach all limitations of claim 1. SKELTON further teaches “wherein the external storage device corresponds to a thumb drive or a universal serial bus (USB) drive. ([SKELTON, para. 0020] “A processor(s) of the device 102 may support a boot-mode feature to boot remotely over USB. This feature can be leveraged through an access port of the device 102, and a general purpose input/output (GPIO) controlled by a power management processor. A remote boot, sometimes referred to herein as an “unbrick boot”, may involve having the power management processor of the device 102 activate that GPIO when it powers on the processor(s) of the device 102. This feature can be triggered in one of two ways.”) ([SKELTON, para. 0107] “the processor(s) 812 is operably connected to one or more transceivers 844 and/or a wired universal serial bus (USB) connection/port 850 to transmit and/or receive data over one or more communication networks 846. … The wired USB port 850 may be used for the initial software load as part of a ‘locked’ (e.g., secure) software installation.”)
Claims 3, 11-13, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over SKELTON-REGUPATHY in view of JIN (US-20220092011-A1), hereinafter SKELTON-REGUPATHY-JIN.
Regarding claim 3, SKELTON-REGUPATHY teach all limitations of claim 2. However, SKELTON-REGUPATHY does not teach “wherein the one or more attributes comprise a product identifier of the external storage device, a vendor identifier of the external storage device, or both.”
In analogous teaching JIN teaches “wherein the one or more attributes comprise a product identifier of the external storage device, a vendor identifier of the external storage device, or both. ([JIN, abstract] “In embodiments of the present disclosure, there is provided a solution for managing a USB connection between a USB device and a host device. … USB ID information for identifying a USB device that is plugged into the host device. Whether the USB ID information is valid is determined based on an authentication policy for authenticating the USB device. If the USB ID information is valid, the USB management client is instructed to permit a connection between the USB device and the host device.”) ([JIN, para. 0025] “FIG. 4 illustrates a block diagram of example types of USB ID information according to embodiments of the present disclosure. In some embodiments, the USB ID information 212 may comprise any of: a USB descriptor hash code (UDHC) 410, a time hash code (THC) 420, a USB certification (UC) 430, and a USB identifier hash code (UIHC) 440.”).
Thus, given the teaching of JIN, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of one or more attributes comprise a product identifier of the external storage device by JIN into the teaching of a device comprising an external storage device interface, operating in a first mode and transitioning to second mode to perform authentication of content and mounting content based on passing authentication by SKELTON-REGUPATHY. One of ordinary skill in the art would have been motivated to do so because JIN recognizes the need to improve authentication and manage USB devices in a more effective manner. ([JIN, para. 0022] “Compared with existing solutions for configuring each host device and distributing a certification to each authenticated USB device, embodiments of the present disclosure greatly reduce manual operations of the IT engineer. Meanwhile, the authentication policy 244 may provide more customizable security strategies, such that host devices and USB devices may be managed in a more effective and easy way.”)
Regarding claims 11 and 18, SKELTON-REGUPATHY teach all limitations of claims 1 and 15. SKELTON further teaches “further comprising an accessory device interface, wherein the computer-executable instructions further cause the processor to: detect an insertion of an accessory device into the accessory device interface; ([SKELTON, para. 0020] “The BootROM of the processor(s) can then wait for the connected external device 104 (e.g., a personal computer (PC)) to deliver the QnxIPL and QnxAltOS (See detail below) directly into RAM of the device 102, and then issue a jump command to trigger QnxIPL. That in turn boots QnxAltOS. At this time, a connection (e.g., openssl connection) to the device 102 is available. The external device 104 is now able to execute commands on the device 102 to download software and initiate the install.”) ([SKELTON, para. 0030] “FIG. 2 illustrates a schematic diagram 200 of an example software update process. … At 204, an external device 104 starts executing an application (abbreviated to “app” in FIG. 2), to facilitate the software update for the device 102. The external device 104 possesses the new software 114 that is to be installed on the device 102. … the device 102 and the external device 104 are communicatively connected via any suitable communication medium, such as a communication network(s) 110.”) transition from the first mode of operation to the second mode of operation in response to detecting insertion of the accessory device into the accessory device interface; ([SKELTON, para. 0030] “FIG. 2. At 202, the device 102 reboots into a setup mode as part of initiating a software update for the device 102. The setup mode is an exemplary name of a mode in which the device 102 operates to download software and perform the first integrity check 116(1), as described herein, which is a different mode than a mode in which the device 102 operates to carry out the core functionality of the device 102”) ([SKELTON, para. 0031] “To initiate the software update process, the device 102 boots into setup mode at 202, and the device 102 executes an existing setup application (SW1: Setup Mode) to perform various operations. According to some examples, the external device 104 and the device 102 exchange the current and desired software configuration for the device's 102 hardware configuration at 206 to determine if an update is needed.”)
However, SKELTON-REGUPATHY does not teach “… and perform, during the second mode of operation, an accessory device authentication check on the accessory device based on information from a remote server.”
In analogous teaching JIN teaches “… and perform, during the second mode of operation, an accessory device authentication check on the accessory device based on information from a remote server.” ([JIN, para. 0020] “A USB management server 242 is provided at an authentication device 240, and the USB management server 242 receives via a cloud 250 the USB ID information 212, 222, . . . , and 232, respectively. Here, the USB management server 242 determines a validity of the received USB ID information based on an authentication policy 244 and sends an instruction to the management client. If the USB ID information is valid, the USB device is allowed to establish a connection”) ([JIN, para. 0024] “As illustrated in FIG. 3, the USB device 114 is plugged 310 into the host device 110. Upon a detection of the USB device 114, the management client 210 obtains 312 USB ID information associated with the USB device 114 and the host device 110. ”) ([JIN, para. 0032] “the authentication device 240 determines 316 a validity of the USB ID information 212 according to the authentication policy 244.”)
The same motivation to modify SKELTON-REGUPATHY with JIN as in the rejection of claim 3 applies.
Regarding claims 12 and 19, SKELTON-REGUPATHY-JIN teach all limitations of claims 11 and 18. JIN further teaches “wherein, to perform the accessory device authentication check on the accessory device, the computer-executable instructions cause the processor to: identify one or more attributes of the accessory device; ([JIN, para. 0002] “According to a first aspect of the present disclosure, there is provided a method implemented at a USB management server. In the method, USB ID information for identifying a USB device that is plugged into the host device is received from a USB management client at a host device.”) send the one or more attributes to the remote server, ([JIN, para. 0030] “Referring back to FIG. 3, once the USB ID information 212 is obtained, the host device 110 may transmit 314 it to the management server 242 via the management client 210.”) and receive, from the remote server and in response to sending the one or more attributes to the remote server, an indication of whether the accessory device passed the accessory device authentication check. ([JIN, para. 0032] “the authentication device 240 determines 316 a validity of the USB ID information 212 according to the authentication policy 244. In the present disclosure, the authentication policy 244 may comprise multiple types, where FIG. 5 illustrates a block diagram 500 of example types of an authentication policy according to embodiments of the present disclosure.”) ([JIN, para. 0049] “Having described how to determine the validity of the USB ID information, reference will be made back to FIG. 3 for further operations of the USB connection management. In FIG. 3, the authentication device 240 returns 318 the determined validity to the host device 110.”)
The same motivation to modify SKELTON-REGUPATHY with JIN as in the rejection of claim 3 applies.
Regarding claim 13, SKELTON-REGUPATHY-JIN teach all limitations of claim 11. JIN further teaches “wherein, to perform the accessory device authentication check on the accessory device, the computer-executable instructions cause the processor to: identify one or more attributes of the accessory device; and ([JIN, para. 0002] “According to a first aspect of the present disclosure, there is provided a method implemented at a USB management server. In the method, USB ID information for identifying a USB device that is plugged into the host device is received from a USB management client at a host device.”) verify, based on the one or more attributes, whether the accessory device is on a list of approved accessory devices from the remote server, ([JIN, para. 0032] “the authentication device 240 determines 316 a validity of the USB ID information 212 according to the authentication policy 244. In the present disclosure, the authentication policy 244 may comprise multiple types, where FIG. 5 illustrates a block diagram 500 of example types of an authentication policy according to embodiments of the present disclosure.”) ([JIN, para. 0033] “ the authentication policy 244 may comprise the simple policy 510. Here, a list of authenticated identifications may be predefined at the management server 242. The predefined list may comprise any of the UDHC, THC, UC or UIHC. At this point, only USB ID information that matches the predefined identification is considered as valid. “) wherein the accessory device passes the accessory device authentication check in response to verification that the accessory device is on the list of approved accessory devices. ([JIN, para. 0035] “With these embodiments, the USB devices and host devices may be managed in a centralized manner at the management server 242 by defining an authenticated list. By using the authenticated list, all the USB devices and host devices that match the authenticated list may be allowed to create USB connections without a need to configure the USB devices and host devices one by one.”) ([JIN, para. 0049] “Next, the host device 110 permits/forbids 320 the USB connection based on the received validity. If the validity from the authentication device 240 indicates that the USB ID information 212 is valid based on the authentication policy 244, the management client 210 may permit the host device 110 to establish a connection with the USB device 114.”)
The same motivation to modify SKELTON-REGUPATHY with JIN as in the rejection of claim 3 applies.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over SKELTON-REGUPATHY-JIN in view of NOVA (US-20150209594-A1).
Regarding claim 14, SKELTON-REGUPATHY-JIN teach all limitations of claim 11. However, SKELTON-REGUPATHY-JIN does not teach “wherein the accessory device comprises a cardiopulmonary resuscitation (CPR) puck, a vital sensor, a video laryngoscope, or an ultrasound probe.”
In analogous teaching NOVA teaches “wherein the accessory device comprises a cardiopulmonary resuscitation (CPR) puck, a vital sensor, a video laryngoscope, or an ultrasound probe. ([NOVA, para. 0051] “In some embodiments, the accessory 477 or 577 may be a non-invasive blood pressure hose, a non-invasive blood pressure cuff, an ECG cable, an ECG electrode, pulse oximetry sensor, a respiration sensor, a communication accessory for transferring patient data, a communication accessory for notification of an event, or a communication accessory for interaction with medical personnel, for instance. If the accessory 477 is a patient parameter collecting accessory, the parameter may include capnography, pulse oximetry, non-invasive blood pressure, ECG with three or more leads, invasive blood pressure, temperature, heart rate, respiration rate or CPR performance monitoring, for example.”)
Thus, given the teaching of NOVA, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of o accessory device comprises a cardiopulmonary resuscitation (CPR) puck, a vital sensor, a video laryngoscope, or an ultrasound probe by NOVA into the teaching of a device comprising an external storage device interface, operating in a first mode and transitioning to second mode to perform authentication of content and mounting content based on passing authentication by SKELTON-REGUPATHY-JIN. One of ordinary skill in the art would have been motivated to do so because NOVA recognizes the need to identify unauthorized devices to improve patient care ([NOVA, para. 0016] “Some companies may make accessories that are not authorized by the device manufacturer but still may work with the device. These accessories are known as unauthorized accessories. Sometimes unauthorized accessories are made to lower quality standards than authorized accessories. … Thus, there is no way to tell from looking at an accessory whether it will operate properly, in the case of an authorized accessory, or may comprise patient care, in the case of an unauthorized accessory.”) ([NOVA, para. 0021] “An advantage over the prior art is that users of such devices can be secure knowing that patient care is not being compromised by using unauthorized, and perhaps inferior, accessories.”)
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
SOFFER (US-20160196454-A1): This prior art teaches of devices and system for enhancing computer information security by physically blocking unused USB ports with self-locking devices, or by providing USB port self-locking device with internal circuitry that qualifies and secures user peripheral device attached to the computer, and by continuously communicating with a management software application that provides real-time monitoring and warnings when any USB self-locking device is being removed or tampered. The self-locking devices use a spring loaded teeth in the USB plug that lock into tab spaces in the USB jack. Visual indicator provides positive assurance when all ports are secure. Each self-locking devices include a security circuit which is uniquely paired with the protected port. Some self-locking devices include data filters that only enable connecting authorized peripheral devices.
MATSUSHIBA (US-20130132739-A1): This prior art teaches of a storage device started when connected to a computer so as to be able to communicate. The storage device includes: an interface for controlling communication with the computer, a data storage unit for storing data received from the computer via the interface, a radio signal processing unit for receiving radio signals including ID information at a predetermined timing and for authenticating the received ID information, and a control unit for encrypting data using the authenticated ID information as a key, for sending the encrypted data to a data storage unit, and for disabling communication with the computer via the interface when radio signals including the authenticated ID information are not received by the radio signal processing unit within a predetermined period of time.
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 AFAQ ALI whose telephone number is (571)272-1571. The examiner can normally be reached Mon - Fri 7:30am - 5:30pm EST.
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, ALI SHAYANFAR can be reached at (571) 270-1050. 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.
/A.A./
07/09/2026
/AFAQ ALI/Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights