DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Remarks
This communication is considered fully responsive to the Amendment filed on 1/15/26.
Interview Summary
The examiner called attorney of record (John D Damron, reg no 74.534) to discuss 1/15/26 amendment that is seen by examiner as new matter. The examiner and attorney did not come to an agreement.
Response to Arguments
Applicant's arguments filed 1/15/26 have been fully considered but they are not persuasive.
1] applicant argues: (emphasis added)
Regarding claim 1, no cited reference, whether considered alone or in combination with any other cited reference, discloses, teaches, or suggests, "in response to receiving [a] request to wake one or more egress ports, identify the one or more egress ports based on the ingress port via which the request was received; [and] activate the one or more egress ports" as claimed. Because no cited reference, whether considered alone or in combination with any other cited reference, discloses, teaches, or suggests, such a feature, the rejection of claim 1 under§ 103 should be withdrawn.
The Office Action alleges Karl teaches identifying one or more egress ports in response to receiving a request to wake one the one or more egress ports. Office Action, at 3. The cited portions of Karl, which include five figures and eight columns of text, describe a wake-up engine which monitors packets being transferred from ingress ports to egress ports and detects wake-up events generated by a "wakening system." See Office Action, at 3 (citing Karl, Figs. 1-5 and Col. 2, L1 25 - Col. 10, L1 35). In particular, Karl describes identifying different wake-up events on different ingress ports and using those identified wake-up events to wake up the different ingress ports and also identifying different wake-up events on different egress ports and using those identified wake-up events to wake up the different egress ports. See, for example, Karl, at Col. 7, Lines 55-60. Karl does not, however, disclose, teach, or suggest, "in response to receiving [a] request to wake one or more egress ports, identify the one or more egress ports based on the ingress port via which the request was received; [and] activate the one or more egress ports" as claimed. No other reference overcomes this deficiency of Karl. Because no cited reference, whether considered alone or in combination with any other cited reference, discloses, teaches, or suggests, such a feature, the rejection of claim 1 under§ 103 should be withdrawn.
The examiner respectfully disagrees.
As cited in the previous office action and further revised here, Karl and Gabbay disclose in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports based on the ingress port via which the request was received (Karl: fig 1-5, col 2 ll 25-67 - col 10 ll 1-35:
wake-up engine 250 may be utilized in forwarding engine 255 as a wake-up engine 220 ... the wake-up engine 250 includes a wake-up event detector 260 configured to monitor packets being transferred from ingress ports 230 to egress ports 240 and detect wake-up events generated by wakening system 120 ... wake-up detector 260 configured to receive a data unit e.g. packet and determine whether the received data unit includes data indicative of a wake-up event (see with col 7 ll 47-60 below - receive, via an ingress port, a request to wake one or more egress && in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports associated/based on the ingress port via which the request was received) ... wake-up engine 250 further includes a wake-up signal generator 270 generates a wake-up signal on one or more egress ports 230 (col 3 ll 65-67 & col 3 ll 1-24) ... wake-up engine 250 further includes a wake-up signal generator 270 generates a wake-up signal on one or more egress ports 230 (see with col 3 ll 65-67 & col 3 ll 1-24 above - in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports ... ) (col 3 ll 65-67 & col 3 ll 1-24) ... switching system 200 may be configured to identify wake-up events only on specific ingress ports 230 and/or egress ports 240 ... to identify different wake-up events on different ingress/egress ports e.g. magic packet on port 1 (associated/based on the ingress port via which the request was received) and a predefined pattern related to IP address of target system on port 2 (egress port) (identify the one or more egress ports based on the ingress port based on the ingress port via which the request was received) (see with col 3 ll 65-67 & col 3 ll 1-24 - in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports associated/based on the ingress port via which the request was received) (col 7 ll 47-60));
activate the one or more egress ports (Karl: fig 1-5, col 2 ll 25-67 - col 10 ll 1-35: switching system 200 may be configured to identify wake-up events only on specific ingress ports 230 and/or egress ports 240 ... to identify different wake-up events on different ingress/egress ports e.g. magic packet on port 1 (associated/based on the ingress port via which the request was received) and a predefined pattern related to IP address of target system on port 2 (the one or more egress ports) (col 7 ll 47-60) ... if switching system 200 determines that a received packet indicative of a wake-up event for target system 300 “YES” branch 420 (see with (col 7 ll 47-60) – a wake event for the one or more egress ports), then wake-up signal generator 270 of switching system may change power state of communication link 150 associated with target system 300 (see with (col 7 ll 47-60) – activate the one or more egress ports) (col 7 ll 61-67 & col 8 ll 1-3)).
Furthermore, see new 112 new matter rejection based on amendments.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.\
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
It is noted that the Applicant has failed to point to the specification in order to show the support for such amendments that have been made to the claims. Therefore, the Examiner will rely on the wording and possible synonyms of the amended subject matter within the specification to determine proper support for these amendments. A general search for this wording and possible synonyms within the specification for limitations in amendments was not found including the following:
claims 1,14,20 (claim 1 exemplary below)
A device comprising one or more circuits to:
receive, via an ingress port, a request to wake one or more egress ports;
in response to receiving the request to wake the one or more egress ports, identify the one
or more egress ports based on the ingress port via which the request was received;
activate the one or more egress ports;
receive data via the ingress port;
in response to receiving the data, select an egress port from the one or more egress ports;
and schedule the data to be forwarded from the selected egress port.
Specifically, IFW specification discloses more broadly ‘identifying one or more egress ports associated with data received via ingress port; activating the one or more egress ports associated with data received via ingress port’ (see at least IFW abstract, fig 6 block 609, [0085;69] & fig 4-5, [0066;77-78 (PGPub abstract, fig 6 black 609, [0085;69]; fig 4-5, [0066;77-78])) and not ‘in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports based on the ingress port via which the request was received’ as amended and, therefore, amendments are new matter.
Therefore, the Examiner submits that the amendments lack proper support within the specification. However, the Examiner will assume that these amendments have proper support in order to advance prosecution. The Applicant is requested to specifically point out the specific page and line and/or paragraph numbers and/or figures where such support for these amendments are disclosed within the specification. For purposes of examination, amendment will be interpreted consistent with IFW specification as ‘... associated with data received via ingress port’ and prior art applied accordingly.
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, 14-15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 8219691 to Karl et al. (“Karl”) in view of U.S. Patent Publication No. 2016/0197736 to Shvarzberg et al. (“Shvarzberg”) and further in view of U.S. Patent Publication No. 2017/0201468 to Gabbay et al. (“Gabbay”).
As to claim 1, Karl discloses a device comprising one or more circuits (Karl: fig 1-5, col 10 ll 1-35: apparatus ... for example, a custom integrated circuit (IC), ASIC, FPGA, PLA etc .... software or firmware includes machine readable instructions capable of causing one or more processors to perform various acts ...) to:
receive, via an ingress port, a request to wake one or more egress (Karl: fig 1-5, col 10 ll 1-35: ... wake-up engine 250 may be utilized in forwarding engine 255 as a wake-up engine 220 ... the wake-up engine 250 includes a wake-up event detector 260 configured to monitor packets being transferred from ingress ports 230 to egress ports 240 and detect wake-up events generated by wakening system 120 ... wake-up detector 260 configured to receive a data unit e.g. packet and determine whether the received data unit includes data indicative of a wake-up event (see with col 7 ll 47-60 - receive, via an ingress port, a request to wake one or more egress) ... wake-up engine 250 further includes a wake-up signal generator 270 generates a wake-up signal on one or more egress ports 230 (col 3 ll 65-67 & col 3 ll 1-24) ... switching system 200 may be configured to identify wake-up events only on specific ingress ports 230 and/or egress ports 240 ... to identify different wake-up events on different ingress/egress ports e.g. magic packet on port 1 (ingress port) and a predefined pattern related to IP address of target system on port 2 (egress port) (col 7 ll 47-60)).
Karl may be interpreted as not explicitly disclose in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports based on the ingress port via which the request was received (emphasis added).
Specifically, Karl discloses in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports associated/based with the ingress port via which the request was received (emphasis added) (Karl: fig 1-5, col 2 ll 25-67 - col 10 ll 1-35: wake-up engine 250 may be utilized in forwarding engine 255 as a wake-up engine 220 ... the wake-up engine 250 includes a wake-up event detector 260 configured to monitor packets being transferred from ingress ports 230 to egress ports 240 and detect wake-up events generated by wakening system 120 ... wake-up detector 260 configured to receive a data unit e.g. packet and determine whether the received data unit includes data indicative of a wake-up event (see with col 7 ll 47-60 below - receive, via an ingress port, a request to wake one or more egress && in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports associated/based on the ingress port via which the request was received ) ... wake-up engine 250 further includes a wake-up signal generator 270 generates a wake-up signal on one or more egress ports 230 (col 3 ll 65-67 & col 3 ll 1-24) ... wake-up engine 250 further includes a wake-up signal generator 270 generates a wake-up signal on one or more egress ports 230 (see with col 3 ll 65-67 & col 3 ll 1-24 above - in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports ... ) (col 3 ll 65-67 & col 3 ll 1-24) ... switching system 200 may be configured to identify wake-up events only on specific ingress ports 230 and/or egress ports 240 ... to identify different wake-up events on different ingress/egress ports e.g. magic packet on port 1 (associated/based on the ingress port via which the request was received) and a predefined pattern related to IP address of target system on port 2 (egress port) (identify the one or more egress ports based on the ingress port based on the ingress port via which the request was received) (see with col 3 ll 65-67 & col 3 ll 1-24 - in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports associated/based on the ingress port via which the request was received) (col 7 ll 47-60)).
Nonetheless, Karl may be interpreted as not explicitly disclose in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports based on the ingress port via which the request was received (emphasis added).
For clarity, Shvarzberg discloses in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports based on the ingress port via which the request was received (emphasis added) (Shvarzberg: fig 1-5, [0008-71]: fig 1- 2 ... uplink control unit 240 may be circuitry responsible for receiving incoming data at the switch 100 from a source device, such as the data packet 126 [0023] ... downlink control unit 230 may be circuitry
responsible for transmitting outgoing data from the switch 100 to corresponding destination device [0027] ... switch fabric 122 may provide connections between the input ports 102-108 and the output ports 110-116 ... a packet 126 may arrive at the input port 102 (see with [0023;27] - ... based on the request received at ingress port) and the switch 100 may determine the egress port 112 as a destination output port for the communication packet 126 based on a destination address associated with the communication packet 126 (see with [0023;27] - ... identify the one or more egress ports ...) [0016] ... in the deep sleep mode, the power management unit 250 monitors sources that trigger a wake-up process, and, for example, the switch 100 may receive a wake command from an upstream device, or an uplink link partner that may initiate the wake-up process (see with [0023;27] - in response to receiving the request to wake ... based on the ingress port via which the request was received) [0040] ... the power management unit 250 may maintain power of one or more of the memory to enable fast wake-up from the deep sleep mode [0055] ... for example, a default configuration of the switch fabric control unit 220, over time, may be modified ... and may identify and record steps to be taken in response to particular events, for example, in response to a packet for a particular destination communication device, the switch fabric control unit 220 may be programmed forward the received packet via a particular output port, different than a default output port (see with [0023;27;40] above - in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports based on the ingress port via which the request was received) [0056] ... switch 100 may continue to stay in the deep sleep mode until it detects a change in the status of the communication link (465) and power management unit 250 may continue to monitor the status of the communication link in the deep sleep mode ... may detect a resumption in transmission from the upstream device 320U, for example, the upstream device 320U may enable the optical transmitter (see with [0023;27]- one or more egress ports) connected to the communication link ... alternatively or in addition, the upstream device 320U may enable the port (see with [0023;27]- one or more egress ports) at which the communication link is connected (see with [0023;27;40;56] above - in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports based on the ingress port via which the request was received) [0057] ... switch 100 may initiate a wake up process ( 475) in response to the change in the status of the RxLOS terminal 252 and/or the interrupt on INT L interrupt terminal 254 and the wake up process may include powering ON the components (see with [0023;27]- one or more egress ports) that the power management unit 250 powered OFF for the deep sleep mode ... power management unit 250 may power ON a component of the switch 100 by enabling the corresponding circuit breaker (see with [0023;27]- one or more egress ports) (see with [0023;27;40;56-57] above - in response to receiving the request to wake the one or more egress ports, identify the one or more egress ports based on the ingress port via which the request was received) [0058] ... the switch 100 may determine that the communication link is to be enabled in response to receipt of data that is to be communicated to the downstream device 320D (see with [0023;27;40;56-57;66] above - in response to receiving the request to wake the one or more egress ports ...) [0066] ... in response to the determination that the communication link with the downstream device 320D is to be enabled (see with [0023;27;40;56-57;66] above - in response to receiving the request to wake the one or more egress ports ...), the switch 100 may enable the communication link (565) with the downstream device 320D (see with [0023;27;40;56-57;66] above - ... identify the one or more egress ports based on the ingress port via which the request was received) [0067])
Karl and Shvarzberg are analogous art because they are from the same field of endeavor with respect to network switches.
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Shvarzberg into the device by Karl. The suggestion/motivation would have been to provide for identifying an inactive state of the loss of signal terminal, and in response, initiating, a wake-up procedure to put the network switch in an active mode (Shvarzberg: [0005])
Karl and Shvarzberg further disclose activate the one or more egress ports (Karl: fig 1-5, col 2 ll 25-67 - col 10 ll 1-35: switching system 200 may be configured to identify wake-up events only on specific ingress ports 230 and/or egress ports 240 ... to identify different wake-up events on different ingress/ egress ports e.g. magic packet on port 1 (based on the ingress port via which the request was received) and a predefined pattern related to IP address of target system on port 2 (the one or more egress ports) (col 7 ll 47-60) ... if switching system 200 determines that a received packet indicative of a wake-up event for target system 300 “YES” branch 420 (see with (col 7 ll 47-60) – a wake event for the one or more egress ports), then wake-up signal generator 270 of switching system may change power state of communication link 150 associated with target system 300 (see with (col 7 ll 47-60) – activate the one or more egress ports) (col 7 ll 61-67 & col 8 ll 1-3)).
Karl did not explicitly disclose receive data via the ingress port.
Gabbay discloses receive data via the ingress port (Gabbay: fig 1-4, [0005-0041]: ... details of switch 20 ... only two ports shown: ingress port labeled 241 at which packet 32 is received and egress port labeled 24E from which packet 34 is transmitted to network 22 [0026] ... port logic 40 associated with ingress port 241 (receive data via the ingress port) receives incoming packet 32 and performs physical and logical processing before placing packet in packet buffer 42 to await forwarding by switching core 26 and port logic 40 signals switching logic 28 with a descriptor based on values in packet header fields to indicate packet is awaiting transfer [0027] ...).
Gabbay further discloses in response to receiving the data, select an egress port from the one or more egress ports (Gabbay: fig 1-4, [0005-0041]: ... details of switch 20 ... only two ports shown: ingress port labeled 241 at which packet 32 is received and egress port labeled 24E from which packet 34 is transmitted to network 22 [0026] ... port logic 40 associated with ingress port 241 (receive data via the ingress port) receives incoming packet 32 and performs physical and logical processing before placing packet in packet buffer 42 to await forwarding by switching core 26 and port logic 40 signals switching logic 28 with a descriptor based on values in packet header fields to indicate packet is awaiting transfer [0027] ... switching logic instructs switching core to transfer data packets to respective egress ports (in response to receiving the data ...) ... coupling switch to plurality of ports configured to serve as ingress and egress ports and switching core ... coupled to transfer packets between the ingress and egress ports to receive and transmit data packets from and to a network ... upon receiving packet at given ingress port, corresponding descriptor is placed in descriptor queue (in response to receiving the data , select an egress port from the one or more egress ports) [0010-11]); and
schedule the data to be forwarded from the selected egress port (Gabbay: fig 1-4, [0005-0041]: ... switching logic reads descriptors and in turn thus schedules and instructs switching core to transfer queued data packets between the ports (schedule the data to be forwarded from the egress port associated with the destination of the data) [0018]).
Karl, Shvarzberg and Gabbay are analogous art because they are from the same field of endeavor with respect to packet switching.
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Gabbay into the device by Karl and Shvarzberg. The suggestion/motivation would have been to provide low-latency packet switching.
As to claim 2, Karl, Shvarzberg and Gabbay disclose wherein the request to wake the one or more egress ports is further a request to wake the ingress port (Karl: fig 1-5, col 2 ll 25-67 - col 10 ll 1-35: ... example network adapter 320 also referred to as ... network card ... network adapter 320 generally allows target system 300 to communicate with switching system 200 via network link 150 ... like other devices included in target system 300, network adapter 320 may operate in and shift between different device power states ... power states include full on (D0), full off (D3) and a number of intermediate states (D1, D2) (col 5 ll 44-67 & col 6 ll 1-6) ... for example, if network adapter is in low-power state, a wake-up event may wake up network adapter 320 (see with col 7 ll 47-60 - wherein the request to wake the one or more egress ports is further a request to wake the ingress port) ... moreover, the shift in power state of neatwork adapter 320 may itself serve as a wake-up event for target system 300 ... wake up of target system 300 is a change in the power state of network link 150 (see with col 7 ll 47-60 - wherein the request to wake the one or more egress ports is further a request to wake the ingress port) (col 6 ll 41-60)
switching system 200 may be configured to identify wake-up events only on specific ingress ports 230 and/or egress ports 240 (see with col 6 ll 41-60 - wherein the request to wake the one or more egress ports is further a request to wake the ingress port) ... to identify different wake-up events on different ingress/egress ports e.g. magic packet on port 1 (ingress port) and a predefined pattern related to IP address of target system on port 2 (egress port) (see with col 6 ll 41-60 - wherein the request to wake the one or more egress ports is further a request to wake the ingress port) (col 7 ll 47-60)).
For motivation, see rejection of claim 1.
As to claims 14-15, see similar rejection to claims 1-2, respectively, where the switch is taught by the device.
As to claim 20, see similar rejection to claim 1 where the method is taught by the device.
Claims 3-6, 9-13 and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 8219691 to Karl et al. (“Karl”), U.S. Patent Publication No. 2016/0197736 to Shvarzberg et al. (“Shvarzberg”) in view of U.S. Patent Publication No. 2017/0201468 to Gabbay et al. (“Gabbay”) and further in view of U.S. Patent Publication No. 2012/0044948 to Nachum et al. (“Nachum”).
As to claim 3, Karl, Shvarzberg and Gabbay disclose the device of claim 1.
For motivation, see rejection of claim 1.
Karl did not explicitly disclose wherein the one or more circuits are further to wake the ingress port in parallel with activating the one or more egress ports in response to the request.
Nachum discloses wherein the one or more circuits are further to wake the ingress port in parallel with activating the one or more egress ports in response to the request (Nachum: fig 1-5, [0007-83]: ... fig 3A-B ... each activated processing core forwards packets or data corresponding to packets in conjunction with other activated processing cores (one or more circuits are further to ...), for example, a packet forwarded using an activated ingress processing pipeline of a first core and an activated egress processing pipeline of the first core or another core ... their common base configuration (wake the ingress port in parallel with activating the one or more egress ports in response to the request) with each switch core having respective ingress (... wake the ingress port in parallel with ...) processing module or pipeline and a respective egress processing module or pipeline (... activating the one or more egress ports in response to the request) [0061] ... each switch core 310a-h includes an egress pipeline and ingress pipeline communicatively coupled via respective core interface ... a particular switch core selected or designated to be the interface (one or more circuits are further to ...) ... coupled to a respective set of one or more network ports 315a-n from which packets are received (... wake the ingress port in parallel with ...) and through which packets are transmitted (... activating the one or more egress ports in response to the request) to other locations in a network [0062] ... upon power up of the IC the controller determines a configuration ID that indicates the active switch cores of IC 302 and the inactive switch cores of IC 302 or both the active and inactive switch cores of IC 302 ... on example, the controller reads a register of IC 302 that stores the configuration ID or determines configuration ID from an external source ... based on the switching device identification determines active cores 310 ... in one scenario, configuration ID indicates all cores 310 are active and thus all network ports 315a-n are available ... deactivator 318 determines, based on communication with controller, which switch cores are to be activated or deactivated (one or more circuits are further to wake the ingress port in parallel with activating the one or more egress ports in response to the request) [0064-65; 67]).
Karl, Shvarzberg, Gabbay and Nachum are analogous art because they are from the same field of endeavor with respect to switching devices
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Nachum into the device by Karl, Shvarzberg and Gabbay. The suggestion/motivation would have been to provide an activator and deactivator to selectively deactivate/activate switch cores and portions thereof (Nachum: [0016;67]).
As to claim 4, Karl, Shvarzberg, Gabbay and Nachum disclose wherein the ingress port is deactivated and unable to receive data when the one or more egress ports are activated (Nachum: fig 1-5, [0007-83]: ... deactivator configured to initiate deactivation of one or more independent switch cores 104 or at least a portion of one or more independent switch cores 104 such as an entire switch core, the ingress pipeline 114, the egress pipeline 116 or another portion, in other words, deactivator 122 initiates a placement of at least a portion of one or more independent switch cores 104 into a deactivated state (see with [0050] - wherein the ingress port is deactivated and unable to receive data ...) ... deactivator 122 determines the one or more switch cores or portions thereof e.g. the ingress processing pipeline or the egress processing pipeline to be deactivated or to be placed into a deactivated state based on information generated or communicated by CPU 120 [0047] ... as a result, the routing of processing performed on packets is redefined (see with [0047] - wherein the ingress port is deactivated and unable to receive data ...) so that the remainder of fully qualified switch cores 104 and/or portions thereof remain active, functional and operational (see with [0047] - when the one or more egress ports are activated) and, thus, with the techniques herein, the entire IC 102 is not wasted but instead remains at least partially useable ... in which a subset of active cores is sufficient (see with [0047] - the ingress port is deactivated and unable to receive data when the one or more egress ports are activated) [0050]).
For motivation, see rejection of claim 1.
As to claim 5, see similar rejection to claim 1 where the device is taught by the device.
As to claim 5, Karl, Shvarzberg, Gabbay and Nachum further disclose wherein the ingress port is associated with a cache in memory, and the one or more circuits identify the one or more egress ports by reading the cache (Gabbay: fig 1-4, [0005-0041]: ... ports (ingress and/or egress ports) include a forwarding cache (... is associated with a cache in memory ...) which contains entries indicating respective egress ports for incoming packets having header fields containing certain predefined values and the port logic (one or more circuits) is configured to identify the packet for immediate transfer to an egress port responsively to a corresponding entry in the forwarding cache (... one or more circuits identify the one or more egress ports by reading the cache) [0009]).
For motivation, see rejection of claim 1.
As to claim 6, see similar rejection to claim 5.
As to claim 6, Karl, Shvarzberg, Gabbay and Nachum further disclose wherein the one or more circuits are further to save an identification of the one or more egress ports in the cache (Gabbay: fig 1-4, [0005-0041]: ... ports (ingress and/or egress ports) include a forwarding cache (... is associated with a cache in memory ...) which contains entries indicating respective egress ports (save an identification of the one or more egress ports in the cache) for incoming packets having header fields containing certain predefined values and the port logic (one or more circuits) is configured to identify the packet for immediate transfer to an egress port responsively to a corresponding entry in the forwarding cache (save an identification of the one or more egress ports in the cache) [0009] ... Turbopath (TP) forwarding ... upon identifying an incoming packet as meeting criteria for TP forwarding based on information cached by the port (see with [0009] - save an identification of the one or more egress ports in the cache) [0020] ... ).
For motivation, see rejection of claim 1.
As to claim 9, see similar rejection to claim 3.
As to claim 9, Karl, Shvarzberg, Gabbay and Nachum further disclose wherein the one or more circuits activate the one or more egress ports in parallel with performing an input negotiation associated with the ingress port (Nachum: fig 1-5, [0007-83]: ... in one embodiment, the configuration ID corresponds to a plurality of bit signals (see with [0061;64-67] - ... in parallel with performing an input negotiation) [0029] ... fig 3A-B ... each activated processing core forwards packets or data corresponding to packets in conjunction with other activated processing cores (one or more circuits are further to ...), for example, a packet forwarded using an activated ingress processing pipeline of a first core and an activated egress processing pipeline of the first core or another core ... their common base configuration (the one or more circuits activate the one or more egress ports in parallel with performing an input negotiation associated with the ingress port) with each switch core having respective ingress (... activate the one or more egress ports in parallel ...) processing module or pipeline and a respective egress processing module or pipeline (... activate the one or more egress ports associated with the ingress port in parallel) [0061] ... each switch core 310a-h includes an egress pipeline and ingress pipeline communicatively coupled via respective core interface ... a particular switch core selected or designated to be the interface (one or more circuits are further to ...) ... coupled to a respective set of one or more network ports 315a-n from which packets are received (... activate the one or more egress ports in parallel ...) and through which packets are transmitted (... activate the one or more egress ports in parallel) to other locations in a network [0062] ... upon power up of the IC the controller determines a configuration ID that indicates the active switch cores of IC 302 and the inactive switch cores of IC 302 or both the active and inactive switch cores of IC 302 ... on example, the controller reads a register of IC 302 that stores the configuration ID or determines configuration ID from an external source ... based on the switching device identification determines active cores 310 ... in one scenario, configuration ID indicates all cores 310 are active and thus all network ports 315a-n are available ... deactivator 318 determines, based on communication with controller, which switch cores are to be activated or deactivated (the one or more circuits activate the one or more egress ports in parallel with performing an input negotiation associated with the ingress port) [0064-65; 67]).
For motivation, see rejection of claim 1.
As to claim 10, see similar rejection to claim 1.
As to claim 11, see similar rejection to claim 2-3.
As to claim 11, Karl, Shvarzberg, Gabbay and Nachum further disclose wherein the one or more circuits activate the one or more egress ports by exiting the one or more egress ports from a low power state port (Nachum: fig 1-5, [0007-83]: fig 1-2 ... another example, power to particular independent switch core(s) is/are shut down to deactivate particular switch core and prevent data frames from being processed while power is delivered to other independent switch core(s) so that other independent switch core(s) continue to process data frames (see with [0035-37;62;64-65] - activate the one or more egress ports by exiting the one or more egress ports from a low power state port) [0045-47] ... fig 3A-B ... each activated processing core forwards packets or data corresponding to packets in conjunction with other activated processing cores, for example, a packet forwarded using an activated ingress processing pipeline of a first core and an activated egress processing pipeline of the first core or another core ... their common base configuration with each switch core having respective ingress processing module or pipeline and a respective egress processing module or pipeline (see with [0035-37;62;64-65] - activate the one or more egress ports) [0061] ... each switch core 310a-h includes an egress pipeline and ingress pipeline communicatively coupled via respective core interface ... a particular switch core selected or designated to be the interface (activated) ... coupled to a respective set of one or more network ports 315a-n from which packets are received (ingress port) and through which packets are transmitted (egress ports) to other locations in a network (see with [0035-37;61;64-65;67] - activate the one or more egress port) [0062] ... upon power up of the IC the controller determines a configuration ID that indicates the active switch cores of IC 302 and the inactive switch cores of IC 302 or both the active and inactive switch cores of IC 302 ... on example, the controller reads a register of IC 302 that stores the configuration ID or determines configuration ID from an external source ... based on the switching device identification determines active cores 310 ... in one scenario, configuration ID indicates all cores 310 are active and thus all network ports 315a-n are available (see with [0061-62] - activate the one or more egress ports by exiting the one or more egress ports from a low power state port) ... deactivator 318 determines, based on communication with controller, which switch cores are to be activated or deactivated (see with [0061-62] - activate the one or more egress ports by exiting the one or more egress ports from a low power state port) [0064-65; 67]).
For motivation, see rejection of claim 1.
As to claim 12, see similar rejection to claim 1-6.
As to claim 12, Karl, Shvarzberg, Gabbay and Nachum further disclose wherein the one or more circuits activate the one or more egress ports prior to or in parallel with performing an output link decoding (Nachum: fig 1-5, [0007-83]: fig 1-2 ... another example, power to particular independent switch core(s) is/are shut down to deactivate particular switch core and prevent data frames from being processed while power is delivered to other independent switch core(s) so that other independent switch core(s) continue to process data frames (see with [0035-37;62;64-65] - activate the one or more egress ports prior to or in parallel with performing an output link decoding) [0045-47] ... fig 3A-B ... each activated processing core forwards packets or data corresponding to packets in conjunction with other activated processing cores, for example, a packet forwarded using an activated ingress processing pipeline of a first core and an activated egress processing pipeline of the first core or another core ... their common base configuration with each switch core having respective ingress processing module or pipeline and a respective egress processing module or pipeline (see with [0035-37;62;64-65] - activate the one or more egress ports prior to or in parallel with performing an output link decoding) [0061] ... each switch core 310a-h includes an egress pipeline and ingress pipeline communicatively coupled via respective core interface ... a particular switch core selected or designated to be the interface (activated) ... coupled to a respective set of one or more network ports 315a-n from which packets are received (ingress port) and through which packets are transmitted (egress ports) to other locations in a network (see with [0035-37;61;64-65;67] - activate the one or more egress ports) [0062] ... upon power up of the IC the controller determines a configuration ID that indicates the active switch cores of IC 302 and the inactive switch cores of IC 302 or both the active and inactive switch cores of IC 302 ... on example, the controller reads a register of IC 302 that stores the configuration ID or determines configuration ID from an external source ... based on the switching device identification determines active cores 310 ... in one scenario, configuration ID indicates all cores 310 are active and thus all network ports 315a-n are available (see with [0061-62] - - activate the one or more egress ports prior to or in parallel with performing an output link decoding) ... deactivator 318 determines, based on communication with controller, which switch cores are to be activated or deactivated (see with [0061-62] - activate the one or more egress ports prior to or in parallel with performing an output link decoding) [0064-65; 67]).
For motivation, see rejection of claim 1.
As to claim 13, see similar rejection to claim 1-6.
As to claims 16-19, see similar rejection to claims 3-6, respectively, where the switch is taught by the device.
Claims 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 8219691 to Karl et al. (“Karl”), U.S. Patent Publication No. 2016/0197736 to Shvarzberg et al. (“Shvarzberg”), U.S. Patent Publication No. 2017/0201468 to Gabbay et al. (“Gabbay”), U.S. Patent Publication No. 2012/0044948 to Nachum et al. (“Nachum”) and further in view of U.S. Patent Publication No. 2022/0200932 to Tsiaflakis et al. (“Tsiaflakis”).
As to claim 7, Karl, Shvarzberg, Gabbay and Nachum further disclose the device of claim 3.
For motivation, see rejection of claim 3.
Karl did not explicitly disclose wherein the one or more circuits identify the one or more egress ports by receiving an output from a reinforcement learning model.
Tsiaflakis discloses wherein the one or more circuits identify the one or more egress ports by receiving an output from a reinforcement learning model (Tsiaflakis: fig 1-12, [0004-]: fig 3-4 ... resource 310 may comprise one or more buffer queues whose egress rates (one or more egress ports) can be controlled by DRA(dynamic resource allocation) controller 320 comprising resource monitor 330, DRA mapper 340 and learning agent 350 (one or more circuits identify the one or more egress ports by receiving an output ...) ... in response to control signal 342, DRA mapper 340 selects an action and communicates selection to resource 310 ... for example, control parameter may be the egress rate of at least one buffer queue (one or more circuits identify the one or more egress ports ...) ... DRA mapper 340 may employ an artificial neural network (ANN) to implement state-to-action mapping ... ANN refers to distributed and typically nonlinear training circuit or machine constructed and ANN may be dynamically adaptive ... DRA control method 400 ... generally adheres to conventional terminology used in field of reinforcement learning (one or more circuits identify the one or more egress ports by receiving an output from a reinforcement learning model) [0071-75] ... buffer queue(1-4) with corresponding ingress and egress flows labeled 501(1-4) and 503(1-4) respectively [0125-126]).
Karl, Shvarzberg, Gabbay, Nachum and Tsiaflakis are analogous art because they are from the same field of endeavor with respect to dynamic resource allocation (DRA).
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Tsiaflakis into the device by Karl, Shvarzberg, Gabbay and Nachum. The suggestion/motivation would have been to provide for dynamically controlling egress sates using RL (reinforcement learning) techniques (Tsiaflakis: [0004]).
As to claim 8, see similar rejection to claim 7 where the device is taught by the device.
As to claim 8, Karl, Shvarzberg, Gabbay, Nachum and Tsiaflakis further disclose wherein the one or more circuits are further to train the reinforcement learning model based on the one or more egress ports associated with the destination of the data (Tsiaflakis: fig 1-12, [0004-]: fig 3-4 ... resource monitor 330 operates to obtain resource-metering information of operates to use information 312 by monitoring selected performance metrics of resource 310 ... resource 310 comprises one or more buffer queues whose egress rates (one or more egress ports associated with the destination of the data) can be controlled by DRA controller 320 ... resource monitor 330 communicates the determined state of resource 310 (see with [0071 - based on the one or more egress ports associated with the destination of the data) by way of control signal 332 to DRA mapper 340 and learning agent 350 [0072] ... DRA mapper 340 may employ ANN to implement state-to-action mapping ... ANN refers to distributed and typically nonlinear training circuit or machine constructed using plurality of processing elements (PEs) (the one or more circuits are further to train the reinforcement learning model ...) ... ANN may have one or more intermediate PE layers referred to as hidden layers and an example PE may scale, sum and bias incoming signals and use an activation function to produce an output signal ... ANN outputs ... the respective weights and/or bias applied by individual PEs can be changed during training or learning mode of operation (to train the reinforcement learning model ...) ... ANN may be dynamically adaptive ... DRA control method 400 ... generally adheres to conventional terminology used in field of reinforcement learning (the one or more circuits are further to train the reinforcement learning model based on the one or more egress ports associated with the destination of the data) [0075]).
For motivation, see rejection of claim 7.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNE SISON whose telephone number is (571)270-5693. The examiner can normally be reached 9:00 am - 5:00 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, Emmanuel Moise can be reached at 571-272-3865. 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.
/JUNE SISON/Primary Examiner, Art Unit 2455