DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to Applicant’s communication filed on 08/21/2025. Claims 1-20 have been examined.
Response to Arguments
Applicant’s arguments, see Remarks – Pages 8-9 , filed on 08/21/2025, with respect to the rejections of claims 1, 9, 18 under 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of Doshi.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1,7 are rejected under 35 U.S.C. 103 as being unpatentable over Merchant et al. Publication No. US 7,310,664 A1 (Merchant hereinafter) in view of Nixon et al. Publication No. US 2022/0078238 A1 (Nixon hereinafter) further in view of Doshi et al. Publication No. US 2022/0012042 A1 ( Doshi hereinafter) .
Regarding claim 1,
Merchant teaches a method, comprising:
storing a first software image for a pluggable interface module connected to a network communication device in a first memory region of the network communication device; storing a second software image for the pluggable interface module in a second memory region of the network communication device, (Col.2, lines 55-65 - the Switch includes a memory for storing a software image corresponding to the wireless edge device. The Software image is code
that is executable on the wireless edge device. When the edge device is connected to the port, the Switch automatically downloads the image to the edge device, along with the configuration information; Col.5, lines 50-65 - The voice over IP phones can store the configuration data and images in volatile memory so that when they are powered down, disconnected from the port 24, or lose the signal from the edge devices 18a, the configuration data and images are erased – Col.7, lines 10-20 - The application software 26 is stored in the compact flash (CF) memory 33 and executable by the processor 29. The configuration database 28 is also stored in the CF memory The CF memory 33 also stores at least one access point (AP) software image 34, at least one AP bootrom image 36 and configuration data. The CF memory 33 can also store Software and bootrom images and configuration data for voice over IP phones that are managed like the APs– Col.14, lines 5-15 - The compact flash memory 33 has FAT16 file system structure on it. Thus, the AP image 34, AP bootrom 36, as well as other images and data can be stored as separate files on the compact flash file system. Using standard programming techniques, the flash file system can be registered with the VxWorks OS so that the files can be accessed by the OS and applications, such as the TFTP server 16, using standard OS calls – Note: memory has file system structure that allow the images to be stored separately in different space/portion of memory );
programming the pluggable interface module with the first software image from the first memory region of the network communication device responsive to determining the pluggable interface module requires updating (Col.13, lines 55-65 - Before being connected to the switch 12, the APs 18a are not fully functional. They lack runtime device image (software) and configuration information that is required for them to be fully operational. This software and information is stored on the switch 12 in the network 10 and downloaded to the devices 18a when they are connected to the switch 12. This bootup procedure is described more fully below, in connection with FIG. 10. – Col.15,lines 30-40- While executing, the AP bootstrap program sends the AP Announce Message (FIG. 12) to the switch 12 (step 108) and waits for a response (step 110). If the response is not forthcoming, a retry will be used by the AP18a, if necessary, to avoid the loss of the Announce Message (step 112). If authentication is successful, the switch 12 will decide the corresponding image(s) for the AP 18a to receive and send out an Announce Reply Message (FIG. 13). Until it receives the Announce Message, the switch 12 waits (step 114). Upon receiving the Announce Message, the Switch 12 determines whether a bootrom upgrade is necessary If switch 12 determines that a bootrom upgrade is required from the contents of the Announce Message, the TFTP path and filename in the Reply Message is for the bootrom image (step 118), instead of the executable image (step 120). The switch 12 determines whether an
upgrade is needed by comparing the bootrom version in the AP Announce Message with the version of the current bootrom program stored on the Switch 12.).
setting, by the network communication device, a first active indicator for the first software image responsive to validating the programming of the pluggable interface module with the first software image (Co.15, lines 50-60 the switch 12 sends one or more TFTP data packets to the AP 18a containing the
requested image (step 128) and the goes into a “Wait TFTP ACK' state (step 146). The TFTP data packets are encapsulated in the packet format shown in FIG. 11.
The new bootrom image is initially downloaded into the APDRAM 26 and its checksum is computed (step 130) by the AP18.a. If the checksum fails, the AP18a resets and the bootup sequence restarts.- Col.16,lines 1-20 -The AP 18a can verify the checksum of the image received from the TFTP server and send out a TFTP ACK (FIG. 15) back to switch 12. When the switch 12 receives the ACK, the switch 12 transits to the “Wait for Image ACK state (step 148). Next, the signature in the header is tested to see if it is the signature of a bootrom image or AP image (step 132). If it is the bootrom image, the AP 18a writes the bootrom image from the DRAM into the flash ROM, sends an acknowledge (ACK) to the switch 12 and then resets itself to start the process over, using the newly installed bootrom image to
download the executable image (step 134). The ACK to the Switch 12 can be sent using a keepalive message that identifies the AP 18a (FIG. 16))
However, Merchant does not explicitly teach
wherein a committed indicator is set for the second software image, after the validating the programming of the pluggable interface module with the first software image, verifying, by the network communication device, an operation of the first software image by the pluggable interface module; and responsive to a failure of the verifying the operation of the first software image, programming, by the network communication device, the pluggable interface module with the second software image from the second memory region of the network communication device
Nixon teaches
wherein a committed indicator is set for the second software image, (¶0028 - the processor may derive internal keys from the unique device identity, and the processor may execute self-tests and code validation to verify the code identity and to establish a set of keys for use in performing secured communications with the external devices via the communication interface. The processor may execute the boot firmware using a secure or trusted boot loader or a security microprocessor and/or using boot file encryption. The processor may check the validity of the boot firmware using the root of trust component and may perform a secure firmware update by validating incoming communication payloads intended to replace existing firmware images prior to being stored or applied in the computer readable memory. Moreover, the processor may perform a secure firmware update by performing a rollback to a known verified boot firmware image if there is a failure to validate new boot image code, ¶0085 – the boot firmware may be stored and executed directly from a non-writable location in the computer readable memory. the device can include a root of trust component 302 that enable updates and patches to be made to start-up code by allowing the start-up code to be loaded from a protected memory region into a protected memory store of some sort set aside for firmware execution. The important aspect for a root of trust component is to be sure that the initial code is what the manufacturer intended, before execution and this root of trust component protects the manufacturer code ( or updated code) from being able to be tampered with by third parties See ¶0087, Claim 12 - Note: the examiner interprets the committed indicator is set for second software image as equivalent to setting the software images as known verified software images stored).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Nixon. The motivation for doing so is to allow the system to validate incoming payloads intended to replace existing firmware images, which is critical to maintaining device integrity throughout the system lifecycle (Nixon – ¶0087).
Doshi teaches
after the validating the programming of the pluggable interface module with the first software image, verifying, by the network communication device, an operation of the first software image by the pluggable interface module; and responsive to a failure of the verifying the operation of the first software image, programming, by the network communication device, the pluggable interface module with the second software image from the second memory region of the network communication device (¶0128 - At operation 1114, the update is applied and tested. The update image may include a set of tests that validate successful installation or application of the update. Alternatively, tests may be obtained from a remote site. The tests are executed. If the tests fail, the system hangs, or a runaway computation is observed, then a sentinel process in the RSI transitions the system to the IBF mode where a reverse update is applied. Optionally, the system may be restored from the snapshot S context – ¶130 – ¶ 0131 - Using these mechanisms and others described in this document, the update process is managed so that if a problem arises during the update process, previously-known verifiable states may be restored. Measurements are obtained before and after a stage of an update is completed to ensure that the update is proceeding as expected. As such, the updates are transactional and reversable sequences of operations. Proofs are provided for each stage of an upgrade. Proofs may be provided for an entire upgrade. This testing before and after each stage (e.g., safe point) during an upgrade allows for automated controlled rollback – ¶ 0139 – During the completion of a stage of the plurality of stages, the method 1300 includes verifying application of the update and performing a function depending on whether the application was verified. In a further embodiment, performing the function includes if the verification fails, rolling back to a previous safe point. In a related embodiment, performing the function includes if the verification succeeds, committing the stage to a safe point– See Also ¶0101, ¶ 0121, 0123, ¶ 0142).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Doshi. The motivation for doing so is to allow the system to ensure that a complex sequence of software updates to be applied to the host partition do not cause the host partition's data or code to become corrupted such that recovery to a stable state becomes very cumbersome or impossible. It is also useful to obtain fine-grained traces of modifications, events, etc. at the host so that one can perform time-travel ( e.g., view a history of software/firmware updates and configuration changes) over a bug and identify what caused it to be a bug. (Doshi – ¶0121).
Regarding claim 7,
Merchant further teaches
storing the first software image in the first memory region responsive to detecting the pluggable interface module being plugged into the network communication device (Col.13, lines 55-65- Before being connected to the switch 12, the APs 18a are not fully functional. They lack runtime device image (software) and configuration information that is required for them to be fully operational. This software and information is stored on the switch 12 in the network 10 and downloaded to the devices 18a when they are connected to the switch 12.).
Claims 2,3 are rejected under 35 U.S.C. 103 as being unpatentable over Merchant in view of Nixon further in view of Doshi further in view of Kwak et al. Publication No. US 2021/0127294 A1 (Kwak hereinafter)
Regarding claim 2,
Merchant does not explicitly teach
extracting the first software image from a software bundle comprising the first software image and a network communication device software image.
However, Kwak teaches
extracting the first software image from a software bundle comprising the first software image and a network communication device software image (¶0076 – ¶0077 - In this case, the firmware package including the firmware image for the master unit 200 and the firmware image for the radio unit 300 may be uploaded to a file transfer protocol (FTP) server of the base station management server 100 to be provided to the master unit 200. However, the embodiment is not limited thereto, and the firmware package may be stored in various ways as long as the firmware package may be provided to the master unit 200. when the master unit 200 receives the firmware update notification from the base station management server 100, the master unit 200 may download the firmware package after accessing to the base station management server 100 using the FTP scheme. When the downloading of the firmware package is completed, the master unit 200 decompresses the firmware package and performs a firmware update of the master unit 200 by using the first firmware image for the master unit. After the firmware update of the master unit 200 is completed, the master unit 200 transmits a firmware update notification to each radio unit 30 when each radio unit 300 receives the firmware update notification from the master unit 200, each radio unit 300 downloads the second firmware image for the radio unit after accessing to the master unit 200 by using the FTP scheme).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Kwak. The motivation for doing so is to allow the system to download images within a package in order to update different components ( Kwak - ¶0076)
Regarding claim 3,
Merchant does not explicitly teach
programming the network communication device with the network communication device software image
However, Kwak teaches
programming the network communication device with the network communication device software image (¶0077 – ¶0079-. When the downloading of the firmware package is completed, the master unit 200 decompresses the firmware package and performs a firmware update of the master unit 200 by using the first firmware image for the master unit. After the firmware update of the master unit 200 is completed, the master unit 200 transmits a firmware update notification to each radio unit 30 when each radio unit 300 receives the firmware update notification from the master unit 200, each radio unit 300 downloads the second firmware image for the radio unit after accessing to the master unit 200 by using the FTP scheme each radio unit 300 performs the firmware update by using the second firmware image downloaded ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Kwak. The motivation for doing so is to allow the system to download different set of images in order update different components ( Kwak - ¶0076).
Claims 4 are rejected under 35 U.S.C. 103 as being unpatentable over Merchant in view of Nixon further in view of Doshi further in view of Zhang et al. Publication No. CN 100421071C ( Zhang hereinafter)
Regarding claim 4,
Merchant teaches pluggable interface module (Col.2, lines 55-65), However, Merchant does not explicitly teach
rebooting the network communication device responsive to the failure of the verifying the operation of the first software image, wherein: programming, by the network communication device, a module with the second software image, comprises programming, by the network communication device, the pluggable interface module with the second software image during the rebooting of the network communication device.
Zhang teaches
rebooting the network communication device responsive to the failure of the verifying the operation of the first software image, wherein: programming, by the network communication device, the pluggable interface module with the second software image, comprises programming, by the network communication device, a module with the second software image during the rebooting of the network communication device (Claim 1 After the described remote equipment of C loaded described legacy version software, if the operation failure, then by described state parameter collection is set, the indication remote equipment loaded the software of secure version when restarting; Page 4 - the base station high layer software is revised state parameter, specifically be that Ver Selected is labeled as 2, revise active Flag and be labeled as 1,revise safe Flag and be labeled as 0, represent from spare memory area 12, to load base station software respectively, issue the base station software activation command and current operation version is dangerous. Revising state parameter in this step, is for after making Node B restart to reset, and can correctly guide the base station software version according to these parameters. State parameter enters step 304 after revising and finishing, and Node B is restarted and resetted. After Node re-powers, enter step 305, check the active Flag sign in the state parameter, because the modification of step 303, this moment, active Flag should be 1.Then enter Step= 306, bottom BSP software is revised as 0 with the active Flag sign, and expression does not issue the base station software activation command. Because Ver Selected is masked as 2, so in follow-up step 307, bottom BSP software loads the base station software and the operation of redaction from spare memory area 12. By above each step, utilized Ver Selected, active Flag, the safe Flag parameter set system of having identified to be in and attempted the upgrading stage, the indication base station loads new version software when restarting)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Zhang. The motivation for doing so is to allow the system to ensure the new image is loaded and properly integrated into the system.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Merchant in view of Nixon further in view of Doshi further in view of Allu et al. Publication No.US 2016/0070625 A1 ( Allu hereinafter)
Regarding claim 5,
Merchant teaches pluggable interface module (Col.2, lines 55-65), However, Merchant does not explicitly teach
generating a first unsupported network interface indicator on the network communication device for the first software image responsive to a failure of at least one of: the validating the programming of the pluggable interface module, or the verifying the operation of the first software image.
Allu teaches
generating a first unsupported network interface indicator on the network communication device for the first software image responsive to a failure of at least one of: the validating the programming of the pluggable interface module, or the verifying the operation of the first software image (¶0039,
– ¶0051 - The manager RMM looks up the problem code in a list of problem codes stored in a memory of the manager RMM (e.g., stored in a file or database of problem codes). The list of problem codes indicates whether the problem code from the message pertains to a hardware failure or software failure. In some examples, the list of problem codes also indicates whether the problem code from the message means that a software application or firmware file is outdated – ¶0052- the target RMM may have a list of current version identifiers for software, firmware, or other items that should be stored in the target boot device. The target RMM can compare the current version identifiers to existing version identifiers from the software, firmware, or other items actually stored on the target boot device. If the current version identifiers do not match the version identifiers for the items stored on the target boot device, then the target RMM can specify in the message which items from the target boot device are outdated – See ¶0071).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Allu. The motivation for doing so is to allow the system to remotely perform diagnostics, repairs, and monitoring of the components of the nodes (Allu – ¶0018).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Merchant in view of Nixon further in view of Doshi further in view of Henseler et al. Publication No. US 2007/0168919 A1 ( Henseler hereinafter)
Regarding claim 6,
Merchant does not explicitly teach
determining a type indicator of the pluggable interface module; and selecting the first software image from a library of software images based on the type indicator.
However, Henseler teaches
determining a type indicator of the pluggable interface module; and selecting the first software image from a library of software images based on the type indicator (¶0046 - administration software executing on control node 12 may automatically identify the appropriate software images to be deployed to application nodes 14 based on the input received from system administrator 20. For example, control node 12 may determine the type of software image to load onto an application node 14 based on the functions assigned to the node by system administrator 20. Application nodes 14 may be divided into a number of groups based on their assigned functionality. As one example, application nodes 14 may be divided into a first group to provide web server functions, a second group to provide business application functions and a third group to provide database functions. The application nodes 14 of each group may be associated with different software images – ¶0135 – ¶0136 - user interface 120 lists the type of software image currently deployed to application nodes for each of the tiers. In the example illustrated, image "applone (1.0.0)" is deployed to the nodes of test tier 1 and image "appltwo (1.0.0)" is deployed to the nodes of test tier 2. System administrator 20 may add one or more tiers to the domain by clicking on new tier button 122 – ¶0142 FIG. 10 is a screen illustration of an exemplary user interface 150 for viewing software images. User interface 150 presents to a system administrator or another user a list of images maintained by control node 12 within image repository 26 ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Henseler. The motivation for doing so is to allow the system to control deployment of instances of the software application to the application nodes. (Henseler – ¶0007).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Merchant in view of Nixon further in view of Doshi further in view of Meilstrup et al. Publication No. US 2012/0096453 A1 ( Meilstrup hereinafter)
Regarding claim 8,
Merchant further teaches wherein: programming the pluggable interface module with the first software image (Col.13, lines 55-65), However, Merchant does not explicitly teach
programming the pluggable interface module with the first software image responsive to processing an activate command in the network communication device for the first software image.
Meilstrup teaches
programming the interface module with the first software image responsive to processing an activate command in the network communication device for the first software image (¶0019 - EPK file 210 also includes a prerequisites file used during installation of the software package files. The prerequisites included in the prerequisites file establish the interdependency of the software package files in which certain files dependent on one or more other files cannot be installed until after the files from which it depends. In a further embodiment, EPK file 210 includes a post installation command script that is activated upon installation of EPK file 210 – Claims 1,4 - wherein the EPK file further comprises a post installation command script that is activated upon installation of the EPK file) .
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Meilstrup. The motivation for doing so is to allow the system to activate software package file upon installation ( ¶0019 – Meilstrup).
Claims 9,15 are rejected under 35 U.S.C. 103 as being unpatentable over Merchant
in view of Doshi et al. Publication No. US 2022/0012042 A1 ( Doshi hereinafter) .
Regarding claim 9,
Merchant teaches a system, comprising:
non-volatile memory having a first memory region and a second memory region; a first connector that is pluggable with a pluggable interface module connector; and a processor configured to, (Col.2, lines 55-65 - the Switch includes a memory for storing a software image corresponding to the wireless edge device. The Software image is code that is executable on the wireless edge device. When the edge device is connected to the port, the Switch automatically downloads the image to the edge device, along with the configuration information; Col.5, lines 50-65 - The voice over IP phones can store the configuration data and images in volatile memory so that when they are powered down, disconnected from the port 24, or lose the signal from the edge devices 18a, the configuration data and images are erased – Col.7, lines 10-20 - The application software 26 is stored in the compact flash (CF) memory 33 and executable by the processor 29. The configuration database 28 is also stored in the CF memory The CF memory 33 also stores at least one access point (AP) software image 34, at least one AP bootrom image 36 and configuration data. The CF memory 33 can also store Software and bootrom images and configuration data for voice over IP phones that are managed like the APs– Col.14, lines 5-15 - The compact flash memory 33 has FAT16 file system structure on it. Thus, the AP image 34, AP bootrom 36, as well as other images and data can be stored as separate files on the compact flash file system. Using standard programming techniques, the flash file system can be registered with the VxWorks OS so that the files can be accessed by the OS and applications, such as the TFTP server 16, using standard OS calls. Note: memory has file system structure that allow the images to be stored separately in different space/portion of memory);
program the pluggable interface module with a first software image stored in the first memory region responsive to determining the pluggable interface module requires updating (Col.13, lines 55-65 - Before being connected to the switch 12, the APs 18a are not fully functional. They lack runtime device image (software) and configuration information that is required for them to be fully operational. This software and information is stored on the switch 12 in the network 10 and downloaded to the devices 18a when they are connected to the switch 12. This bootup procedure is described more fully below, in connection with FIG. 10. – Col.15,lines 30-40- While executing, the AP bootstrap program sends the AP Announce Message (FIG. 12) to the switch 12 (step 108) and waits for a response (step 110). If the response is not forthcoming, a retry will be used by the AP18a, if necessary, to avoid the loss of the Announce Message (step 112). If authentication is successful, the switch 12 will decide the corresponding image(s) for the AP 18a to receive and send out an Announce Reply Message (FIG. 13). Until it receives the Announce Message, the switch 12 waits (step 114). Upon receiving the Announce Message, the Switch 12 determines whether a bootrom upgrade is necessary If switch 12 determines that a bootrom upgrade is required from the contents of the Announce Message, the TFTP path and filename in the Reply Message is for the bootrom image (step 118), instead of the executable image (step 120). The switch 12 determines whether an upgrade is needed by comparing the bootrom version in the AP Announce Message with the version of the current bootrom program stored on the Switch 12. ).
set a first active indicator for the first software image responsive to validating the programming of the pluggable interface module with the first software image; (Co.15, lines 50-60 the switch 12 sends one or more TFTP data packets to the AP 18a containing the requested image (step 128) and the goes into a “Wait TFTP ACK' state (step 146). The TFTP data packets are encapsulated in the packet format shown in FIG. 11. The new bootrom image is initially downloaded into the APDRAM 26 and its checksum is computed (step 130) by the AP18.a. If the checksum fails, the AP18a resets and the bootup sequence restarts.- Col.16,lines 1-20 -The AP 18a can verify the checksum of the image received from the TFTP server and send out a TFTP ACK (FIG. 15) back to switch 12. When the switch 12 receives the ACK, the switch 12 transits to the “Wait for Image ACK state (step 148). Next, the signature in the header is tested to see if it is the signature of a bootrom image or AP image (step 132). If it is the bootrom image, the AP 18a writes the bootrom image from the DRAM into the flash ROM, sends an acknowledge (ACK) to the switch 12 and then resets itself to start the process over, using the newly installed bootrom image to download the executable image (step 134). The ACK to the Switch 12 can be sent using a keepalive message that identifies the AP 18a (FIG. 16))
However, Merchant does not explicitly teach
after the validating the programming of the pluggable interface module with the first software image, verify an operation of the first software image by the pluggable interface module; and responsive to a failure of the verifying the operation of the first software image, program the pluggable interface module with a second software image stored in the second memory region.
Doshi teaches
after the validating the programming of the pluggable interface module with the first software image, verify an operation of the first software image by the pluggable interface module; and responsive to a failure of the verifying the operation of the first software image, program the pluggable interface module with a second software image stored in a second memory region.(¶ 0128 - At operation 1114, the update is applied and tested. The update image may include a set of tests that validate successful installation or application of the update. Alternatively, tests may be obtained from a remote site. The tests are executed. If the tests fail, the system hangs, or a runaway computation is observed, then a sentinel process in the RSI transitions the system to the IBF mode where a reverse update is applied. Optionally, the system may be restored from the snapshot S context – ¶ 130 – ¶ 0131 - Using these mechanisms and others described in this document, the update process is managed so that if a problem arises during the update process, previously-known verifiable states may be restored. Measurements are obtained before and after a stage of an update is completed to ensure that the update is proceeding as expected. As such, the updates are transactional and reversable sequences of operations. Proofs are provided for each stage of an upgrade. Proofs may be provided for an entire upgrade. This testing before and after each stage (e.g., safe point) during an upgrade allows for automated controlled rollback – ¶ 0139 – During the completion of a stage of the plurality of stages, the method 1300 includes verifying application of the update and performing a function depending on whether the application was verified. In a further embodiment, performing the function includes if the verification fails, rolling back to a previous safe point. In a related embodiment, performing the function includes if the verification succeeds, committing the stage to a safe point– See Also ¶ 0101, ¶ 0121, 0123,¶ 0142).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Doshi. The motivation for doing so is to allow the system to ensure that a complex sequence of software updates to be applied to the host partition do not cause the host partition's data or code to become corrupted such that recovery to a stable state becomes very cumbersome or impossible. It is also useful to obtain fine-grained traces of modifications, events, etc. at the host so that one can perform time-travel ( e.g., view a history of software/firmware updates and configuration changes) over a bug and identify what caused it to be a bug. (Doshi – ¶0121).
Regarding claim 15,
Merchant further teaches
wherein: the processor is configured to store the first software image in the first memory region responsive to detecting the pluggable interface module being plugged into the first connector (Col.13, lines 55-65- Before being connected to the switch 12, the APs 18a are not fully functional. They lack runtime device image (software) and configuration information that is required for them to be fully operational. This software and information is stored on the switch 12 in the network 10 and downloaded to the devices 18a when they are connected to the switch 12.),
Claims 10,11 are rejected under 35 U.S.C. 103 as being unpatentable over Merchant in view of Doshi further in view of Kwak et al. Publication No. US 2021/0127294 A1 (Kwak hereinafter)
Regarding claim 10,
Merchant does not explicitly teach
wherein: the processor is configured to extract the first software image from a software bundle comprising the first software image and a network communication device software image.
However, Kwak teaches
wherein: the processor is configured to extract the first software image from a software bundle comprising the first software image and a network communication device software image (¶0076 – ¶0077 - In this case, the firmware package including the firmware image for the master unit 200 and the firmware image for the radio unit 300 may be uploaded to a file transfer protocol (FTP) server of the base station management server 100 to be provided to the master unit 200. However, the embodiment is not limited thereto, and the firmware package may be stored in various ways as long as the firmware package may be provided to the master unit 200. when the master unit 200 receives the firmware update notification from the base station management server 100, the master unit 200 may download the firmware package after accessing to the base station management server 100 using the FTP scheme. When the downloading of the firmware package is completed, the master unit 200 decompresses the firmware package and performs a firmware update of the master unit 200 by using the first firmware image for the master unit. After the firmware update of the master unit 200 is completed, the master unit 200 transmits a firmware update notification to each radio unit 30 when each radio unit 300 receives the firmware update notification from the master unit 200, each radio unit 300 downloads the second firmware image for the radio unit after accessing to the master unit 200 by using the FTP scheme).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Kwak. The motivation for doing so is to allow the system to download images within a package in order to update different components ( Kwak - ¶0076).
Regarding claim 11,
Merchant does not explicitly teach
wherein: the processor is configured to program the network communication device with the network communication device software image.
However, Kwak teaches
wherein: the processor is configured to program the network communication device with the network communication device software image (¶0077 – ¶0079-. When the downloading of the firmware package is completed, the master unit 200 decompresses the firmware package and performs a firmware update of the master unit 200 by using the first firmware image for the master unit. After the firmware update of the master unit 200 is completed, the master unit 200 transmits a firmware update notification to each radio unit 30 when each radio unit 300 receives the firmware update notification from the master unit 200, each radio unit 300 downloads the second firmware image for the radio unit after accessing to the master unit 200 by using the FTP scheme each radio unit 300 performs the firmware update by using the second firmware image downloaded.. ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Kwak. The motivation for doing so is to allow the system to download different set of images in order update different components ( Kwak - ¶0076).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Merchant in view of Doshi further in view of Zhang et al. Publication No. CN 100421071C ( Zhang hereinafter)
Regarding claim 12,
Merchant teaches pluggable interface module (Col.2, lines 55-65), However, Merchant does not explicitly teach
wherein: the processor is configured to facilitate a reboot operation responsive to the failure of the verifying the operation of the first software image, wherein: programming the pluggable interface module with the second software image, comprises programming the pluggable interface module with the second software image during the reboot operation
Zhang teaches
wherein: the processor is configured to facilitate a reboot operation responsive to the failure of the verifying the operation of the first software image, wherein: programming the interface module with the second software image, comprises programming a module with the second software image during the reboot operation (Claim 1 After the described remote equipment of C loaded described legacy version software, if the operation failure, then by described state parameter collection is set, the indication remote equipment loaded the software of secure version when restarting; Page 4 - the base station high layer software is revised state parameter, specifically be that Ver Selected is labeled as 2, revise active Flag and be labeled as 1,revise safe Flag and be labeled as 0, represent from spare memory area 12, to load base station software respectively, issue the base station software activation command and current operation version is dangerous. Revising state parameter in this step, is for after making Node B restart to reset, and can correctly guide the base station software version according to these parameters. State parameter enters step 304 after revising and finishing, and Node B is restarted and resetted. After Node re-powers, enter step 305, check the active Flag sign in the state parameter, because the modification of step 303, this moment, active Flag should be 1.Then enter Step= 306, bottom BSP software is revised as 0 with the active Flag sign, and expression does not issue the base station software activation command. Because Ver Selected is masked as 2, so in follow-up step 307, bottom BSP software loads the base station software and the operation of redaction from spare memory area 12. By above each step, utilized Ver Selected, active Flag, the safe Flag parameter set system of having identified to be in and attempted the upgrading stage, the indication base station loads new version software when restarting)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Zhang. The motivation for doing so is to allow the system to ensure the new image is loaded and properly integrated into the system.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Merchant in view of Doshi further in view of Allu et al. Publication No.US 2016/0070625 A1 ( Allu hereinafter)
Regarding claim 13,
Merchant teaches pluggable interface module (Col.2, lines 55-65), However, Merchant does not explicitly teach
wherein: the processor is configured to generate a first unsupported network interface indicator for the first software image responsive to a failure of at least one of: the validating the programming of the pluggable interface module, or the verifying the operation of the first software image.
Allu teaches
wherein: the processor is configured to generate a first unsupported network interface indicator for the first software image responsive to a failure of at least one of: the validating the programming of the pluggable interface module, or the verifying the operation of the first software image. (¶0039,¶0051 - The manager RMM looks up the problem code in a list of problem codes stored in a memory of the manager RMM (e.g., stored in a file or database of problem codes). The list of problem codes indicates whether the problem code from the message pertains to a hardware failure or software failure. In some examples, the list of problem codes also indicates whether the problem code from the message means that a software application or firmware file is outdated – ¶0052- the target RMM may have a list of current version identifiers for software, firmware, or other items that should be stored in the target boot device. The target RMM can compare the current version identifiers to existing version identifiers from the software, firmware, or other items actually stored on the target boot device. If the current version identifiers do not match the version identifiers for the items stored on the target boot device, then the target RMM can specify in the message which items from the target boot device are outdated – See ¶0071).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Allu. The motivation for doing so is to allow the system to remotely perform diagnostics, repairs, and monitoring of the components of the nodes (Allu – ¶0018).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Merchant in view of Doshi further in view of Henseler et al. Publication No. US 2007/0168919 A1 ( Henseler hereinafter)
Regarding claim 14,
Merchant does not explicitly teach
wherein: the processor is configured to determine a type indicator of the pluggable interface module; and the processor is configured to select the first software image from a library of software images based on the type indicator.
However, Henseler teaches
wherein: the processor is configured to determine a type indicator of the pluggable interface module; and the processor is configured to select the first software image from a library of software images based on the type indicator. (¶0046 - administration software executing on control node 12 may automatically identify the appropriate software images to be deployed to application nodes 14 based on the input received from system administrator 20. For example, control node 12 may determine the type of software image to load onto an application node 14 based on the functions assigned to the node by system administrator 20. Application nodes 14 may be divided into a number of groups based on their assigned functionality. As one example, application nodes 14 may be divided into a first group to provide web server functions, a second group to provide business application functions and a third group to provide database functions. The application nodes 14 of each group may be associated with different software images – ¶0135 – ¶0136 - user interface 120 lists the type of software image currently deployed to application nodes for each of the tiers. In the example illustrated, image "applone (1.0.0)" is deployed to the nodes of test tier 1 and image "appltwo (1.0.0)" is deployed to the nodes of test tier 2. System administrator 20 may add one or more tiers to the domain by clicking on new tier button 122 – ¶0142 FIG. 10 is a screen illustration of an exemplary user interface 150 for viewing software images. User interface 150 presents to a system administrator or another user a list of images maintained by control node 12 within image repository 26 ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Henseler. The motivation for doing so is to allow the system to control deployment of instances of the software application to the application nodes. (Henseler – ¶0007).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Merchant in view of Doshi further in view of Meilstrup et al. Publication No. US 2012/0096453 A1 ( Meilstrup hereinafter)
Regarding claim 16,
Merchant further teaches wherein: programming the pluggable interface module with the first software image (Col.13, lines 55-65), However, Merchant does not explicitly teach
wherein: the processor is configured to program the interface module with the first software image responsive to processing an activate command for the first software image.
Meilstrup teaches
wherein: the processor is configured to program the interface module with the first software image responsive to processing an activate command for the first software image (¶0019 - EPK file 210 also includes a prerequisites file used during installation of the software package files. The prerequisites included in the prerequisites file establish the interdependency of the software package files in which certain files dependent on one or more other files cannot be installed until after the files from which it depends. In a further embodiment, EPK file 210 includes a post installation command script that is activated upon installation of EPK file 210 – Claims 1,4 - wherein the EPK file further comprises a post installation command script that is activated upon installation of the EPK file) .
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Meilstrup. The motivation for doing so is to allow the system to activate software package file upon installation ( ¶0019 – Meilstrup).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Merchant in view of Doshi further in view of Glendinning et al. Publication No. US 2023/0125616 A1 ( Glendinning hereinafter)
Regarding claim 17,
Merchant does not explicitly teach
wherein: the processor is configured to ignore a version mismatch associated with the first software image responsive to an experimental indicator being set.
However, Glendinning teaches
the processor is configured to ignore a version mismatch associated with the first software image responsive to an experimental indicator being set (Abstract , ¶ 0017 The processing circuitry 14 or means for processing 14 is to compare the expected system configuration with the current system configuration. The processing circuitry 14 or means for processing 14 is to provide information on a mismatch via the output device 105 of the computer system if there is a mismatch between the expected system configuration and the current system configuration – ¶ 0029 - mismatches may be detected and used to trigger one or more subsequent operations. In particular, in many cases, a mismatch does not necessarily have a large impact, in particular if driver versions and/or firmware versions are also compared. Therefore, the likely (i.e., projected, predicted) impact of the mismatch may be determined in a first operation. For example, the processing circuitry may determine, based on a data storage with known impacts (which may be stored in the storage circuitry 16), information on a likely impact of the mismatch- ¶ 0031 - For example, the user may be provided with an option to ignore the mismatch, to manually take corrective action ( e.g., by rebooting the computer system or reinstalling an earlier driver – ¶ 0068 - If the daemon has detected a problem, one or more of an impact prediction, problem solution and post problem correction (if successful) are performed. In impact prediction, the impact of the problem may be notified by the daemon to the user via a log entry, a user interface or a notification mechanism. In problem solution, three different courses of action can be taken - the user can ignore the problem)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Glendinning. The motivation for doing so is to allow the system to provide information on a mismatch via an output device of the computer system (Glendinning – Abstract) .
Claims 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Merchant in view of Gupta et al. Publication No. US 2020/0249646 A1 (Gupta hereinafter) further in view of Nixon further in view of Doshi
Regarding claim 18,
Merchant teaches a system , comprising:
a first connector providing a local area network interface; a second connector providing a pluggable interface for a pluggable interface module to a[..] network (Col.3, lines 50-60 - The network architecture shown in FIG. 1 provides a unified, adaptive access paradigm for wired and wireless LAN access, management, and configuration. This is achieved by treating wireless edge devices 18a, such as wireless access points (APs), as extensions of the wired LAN switch port 24. The configuration and management of each AP18a is abstracted to the configuration and management of the wired LAN access switch 12 that the AP 18a is plugged into.; Col.5, lines 60-70 - Each network switch 12 includes one or more ports 24 corresponding to each of the networked devices 18a-b. The ports 24 permit network communications between the devices 18a-b and the network 16. The network switch 12 can be a commercially-available LAN switch i.e., it can be the network connection point for multiple edge devices an user stations 18a-b, Such as an Ethernet Switch, programmed with software to conform with the principles the unified);
and a processor configured to: receive a software bundle package; extract a first software image for the pluggable interface module from the software bundle package (Col.13, lines 65-68 - The AP software images 34, 36 and AP configuration data can be bundled with self-extracting switch software. During initialization of the switch 12, the bundled software can be loaded onto the switch 12. The bundled software can be compressed and wrapped so that it is self-extracting using a commercially-available software utility. When the bundled software is loaded onto the switch, the images 34, 36 and configuration data are self-extracted and stored in the flash memory).
a non-volatile memory system having a first portion and a second portion; store the first software image in the first portion of the non-volatile memory system, wherein the second portion of the non-volatile memory system stores a second software image, (Col.2, lines 55-65 - the Switch includes a memory for storing a software image corresponding to the wireless edge device. The Software image is code that is executable on the wireless edge device. When the edge device is connected to the port, the Switch automatically downloads the image to the edge device, along with the configuration information; Col.5, lines 50-65 - The voice over IP phones can store the configuration data and images in volatile memory so that when they are powered down, disconnected from the port 24, or lose the signal from the edge devices 18a, the configuration data and images are erased – Col.7, lines 10-20 - The application software 26 is stored in the compact flash (CF) memory 33 and executable by the processor 29. The configuration database 28 is also stored in the CF memory The CF memory 33 also stores at least one access point (AP) software image 34, at least one AP bootrom image 36 and configuration data. The CF memory 33 can also store Software and bootrom images and configuration data for voice over IP phones that are managed like the APs– Col.14, lines 5-15 - The compact flash memory 33 has FAT16 file system structure on it. Thus, the AP image 34, AP bootrom 36, as well as other images and data can be stored as separate files on the compact flash file system. Using standard programming techniques, the flash file system can be registered with the VxWorks OS so that the files can be accessed by the OS and applications, such as the TFTP server 16, using standard OS calls Note: memory has file system structure that allow the images to be stored separately in different space/ portion of memory)..;
responsive to a trigger event, execute an upgrade procedure to upgrade the pluggable interface module with the first software image, the upgrade procedure comprising: validating the first software image, (Col.13, lines 55-65 - Before being connected to the switch 12, the APs 18a are not fully functional. They lack runtime device image (software) and configuration information that is required for them to be fully operational. This software and information is stored on the switch 12 in the network 10 and downloaded to the devices 18a when they are connected to the switch 12. This bootup procedure is described more fully below, in connection with FIG. 10. – Col.15,lines 30-40- While executing, the AP bootstrap program sends the AP Announce Message (FIG. 12) to the switch 12 (step 108) and waits for a response (step 110). If the response is not forthcoming, a retry will be used by the AP18a, if necessary, to avoid the loss of the Announce Message (step 112). If authentication is successful, the switch 12 will decide the corresponding image(s) for the AP 18a to receive and send out an Announce Reply Message (FIG. 13). Until it receives the Announce Message, the switch 12 waits (step 114). Upon receiving the Announce Message, the Switch 12 determines whether a bootrom upgrade is necessary If switch 12 determines that a bootrom upgrade is required from the contents of the Announce Message, the TFTP path and filename in the Reply Message is for the bootrom image (step 118), instead of the executable image (step 120). The switch 12 determines whether an upgrade is needed by comparing the bootrom version in the AP Announce Message with the version of the current bootrom program stored on the Switch 12. ).
setting a state of the first software image to active when the first software image has been validated, uploading the first software image to the pluggable interface module when the first software image is in the active state (Co.15, lines 50-60 the switch 12 sends one or more TFTP data packets to the AP 18a containing the requested image (step 128) and the goes into a “Wait TFTP ACK' state (step 146). The TFTP data packets are encapsulated in the packet format shown in FIG. 11. The new bootrom image is initially downloaded into the APDRAM 26 and its checksum is computed (step 130) by the AP18.a. If the checksum fails, the AP18a resets and the bootup sequence restarts.- Col.16,lines 1-20 -The AP 18a can verify the checksum of the image received from the TFTP server and send out a TFTP ACK (FIG. 15) back to switch 12. When the switch 12 receives the ACK, the switch 12 transits to the “Wait for Image ACK state (step 148). Next, the signature in the header is tested to see if it is the signature of a bootrom image or AP image (step 132). If it is the bootrom image, the AP 18a writes the bootrom image from the DRAM into the flash ROM, sends an acknowledge (ACK) to the switch 12 and then resets itself to start the process over, using the newly installed bootrom image to download the executable image (step 134). The ACK to the Switch 12 can be sent using a keepalive message that identifies the AP 18a (FIG. 16))
However, Merchant does not explicitly teach that the network is Wide area network, receiving a software bundle package from the wide area network.
stores a second software image that has a committed state; after the validating the first software image, verifying an operation of the first software image after the uploading of the first software image to the pluggable interface module, and responsive to a failure of the verifying the operation of the first software image, programming the pluggable interface module with the second software image from the second portion
Gupta teaches
network is Wide area network, receiving a software bundle package from the wide area network (¶ 0046 – device 210 and any other HVAC device described herein may be a zone coordinator, rooftop unit (RTU) controller, or any other device within HVAC system 100. Device 210 may receive a complete software package from network 208 and update accordingly using the software package. Finally, device 210 may provide a portion of the software package necessary to update device 212-214 to device 212. In an exemplary embodiment, device 210 is a thermostat controller configured to receive a new update package. Device 210 receives the update package from network 208 and updates accordingly – ¶ 0044 – network 208 is a cloud network and various software packages are provided and stored thereon. In other embodiments, network 208 is a local area network (LAN) or variations thereof (e.g., WLAN, HAN, SAN). In other embodiments, network 208 may be any known area network (AN) type, including: cloud (IAN), wide (WAN), campus (CAN), local (LAN), near-me (NAN), or the Internet).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Gupta . The motivation for doing so is to allow the system to receive an update software package using the WAN network to facilitate communication and resource sharing between geographically dispersed location.
Nixon teaches
stores a second software image that has a committed state; (¶0028 - the processor may derive internal keys from the unique device identity, and the processor may execute self-tests and code validation to verify the code identity and to establish a set of keys for use in performing secured communications with the external devices via the communication interface. The processor may execute the boot firmware using digitally signed binaries or digitally signed boot files and may verify the boot files using a digital key verified using the root of trust component. The processor may execute the boot firmware using a secure or trusted boot loader or a security microprocessor and/or using boot file encryption. The processor may check the validity of the boot firmware using the root of trust component and may perform a secure firmware update by validating incoming communication payloads intended to replace existing firmware images prior to being stored or applied in the computer readable memory. Moreover, the processor may perform a secure firmware update by performing a rollback to a known verified boot firmware image if there is a failure to validate new boot image code, ¶0085 – the boot firmware may be stored and executed directly from a non-writable location in the computer readable memory. the device can include a root of trust component 302 that enable updates and patches to be made to start-up code by allowing the start-up code to be loaded from a protected memory region into a protected memory store of some sort set aside for firmware execution. The important aspect for a root of trust component is to be sure that the initial code is what the manufacturer intended, before execution and this root of trust component protects the manufacturer code ( or updated code) from being able to be tampered with by third parties See ¶0087, Claim 12 - Note: the examiner interprets the committed indicator is set for second software image as equivalent to setting the software images as known verified software images stored) . .
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Nixon. The motivation for doing so is to allow the system to validate incoming payloads intended to replace existing firmware images, which is critical to maintaining device integrity throughout the system lifecycle (Nixon – ¶0087).
Doshi teaches
after the validating the first software image, verifying an operation of the first software image after the uploading of the first software image to the pluggable interface module, and responsive to a failure of the verifying the operation of the first software image, programming the pluggable interface module with the second software image from the second portion (¶ 0128 - At operation 1114, the update is applied and tested. The update image may include a set of tests that validate successful installation or application of the update. Alternatively, tests may be obtained from a remote site. The tests are executed. If the tests fail, the system hangs, or a runaway computation is observed, then a sentinel process in the RSI transitions the system to the IBF mode where a reverse update is applied. Optionally, the system may be restored from the snapshot S context – ¶ 130 – ¶ 0131 - Using these mechanisms and others described in this document, the update process is managed so that if a problem arises during the update process, previously-known verifiable states may be restored. Measurements are obtained before and after a stage of an update is completed to ensure that the update is proceeding as expected. As such, the updates are transactional and reversable sequences of operations. Proofs are provided for each stage of an upgrade. Proofs may be provided for an entire upgrade. This testing before and after each stage (e.g., safe point) during an upgrade allows for automated controlled rollback – ¶ 0139 – During the completion of a stage of the plurality of stages, the method 1300 includes verifying application of the update and performing a function depending on whether the application was verified. In a further embodiment, performing the function includes if the verification fails, rolling back to a previous safe point. In a related embodiment, performing the function includes if the verification succeeds, committing the stage to a safe point– See Also ¶ 0101, ¶ 0121, 0123,¶ 0142).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Doshi. The motivation for doing so is to allow the system to ensure that a complex sequence of software updates to be applied to the host partition do not cause the host partition's data or code to become corrupted such that recovery to a stable state becomes very cumbersome or impossible. It is also useful to obtain fine-grained traces of modifications, events, etc. at the host so that one can perform time-travel ( e.g., view a history of software/firmware updates and configuration changes) over a bug and identify what caused it to be a bug. (Doshi – ¶0121).
Regarding claim 19,
Merchant does not explicitly teach
wherein the trigger event comprises at least one of: an insertion of the pluggable interface module into the second connector, or an activate command for the first software image
However, Gupta teaches
wherein the trigger event comprises at least one of: an insertion of the pluggable interface module into the second connector, or an activate command for the first software image (Gupta - ¶ 0086- . In some embodiments, the HVAC device 402 installs the updates immediately upon extraction from the update package. In other embodiments, the HVAC device 402 may store the update until a later installation period. The installation period may be scheduled or triggered by a certain event (e.g., a technician entering a command to update device firmware).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Gupta. The motivation for doing so is to allow the system to update device firmware (Gupta – ¶ 0086).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Merchant in view of Gupta further in view of Nixon further in view of Doshi further in view of Ling et al. Publication No. US 2007/0233894 A1 ( Ling hereinafter) .
Regarding claim 20 ,
Merchant further teaches
wherein: the local area network interface comprises at least one of an optical interface or an Ethernet interface (Col.13, lines 35-45 Each AP18a includes a network interface (NI) 23, a boot ROM (read only memory) 24, and a volatile memory 26. The network interface 23 can be any suitable component for permitting network communication between the Switch 12 and the device 18a, and is preferably a commercially available Ethernet card, See Claim 7)-; and
However, Merchant does not explicitly teach
the pluggable interface module provides an interface to a wide area optical network
Ling teaches
the pluggable interface module provides an interface to a wide area optical network (Fig.1&2, ¶ 0004, ¶ 0009 - FIG. 1 is a block diagram of a an interface between a network of local area network clients and a cross-connect to a wide area optical network according to an embodiment of the invention; ¶ 0018 - The interface of FIG. 1 may form part of a communication system, in which Fiber Channel client data is transported over SONET or OTN (Open Transport Network) through a TDM Cross-Connect Switch. Between these two data formats, there is a Client Adaptation FPGA 114 coupled to the client data network through a set of SFP (Small Form Factor Pluggable) modules 113-1 to 113-n. The SFP modules translate optical signals into electrical signals) .
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Merchant to include the teachings of Ling. The motivation for doing so is to allow the system to use Wide area optical network for higher bandwidth , faster speeds and enhanced security.
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 YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 PM.
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, Oscar A Louie can be reached at (571) 270-1684. 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445
Prosecution Insights