Systems and methods for reducing power consumption during communication between link partners
Summary by NHIP
Active Idle Ethernet Controller
The Ethernet controller alternates between active and low power states to reduce energy consumption during data transmission and reception. It signals link partners to enter specific low power modes, waits for predefined periods, and then resumes operations at negotiated speeds using 10GBASE-T or 1000BASE-T PHYs.
Claim Score by NHIP
Abstract
Generally, this disclosure describes an energy-efficient Ethernet communications approach. In at least one embodiment described herein, an Ethernet controller may be configured to operate in an active power state to transmit or receive data packets at a maximum available link speed. The maximum available link speed may be determined by a negotiation between the Ethernet controller and a link partner coupled to the Ethernet controller. Once the data packets are transmitted or received, the Ethernet controller may be configured to operate in an idle power state to reduce energy consumption.

Term
3.6 yearsleft in the term
Expires 14 May 2030, including 919 days of term adjustment.
- Priority and filed
- Granted
- Today
- Expires
37 claims: 4 independent, 33 dependent
- 1An Ethernet controller, comprising:at least one Media Access Controller (MAC);at least one interface to at least one PHY;and circuitry arranged to, when operational: cause generation of a signal for a first link partner signaling a first low power state;enter the first low power state, the first low power state to cause a reduction in power consumed by transmit circuitry during the first low power state;cause generation of a signal for the first link partner signaling end of the first low power state;await a first predefined period of time;after the first predefined period of time, cause transmission, in a first active power state, of at least one Ethernet data frame to the first link partner, the first active power state being a higher power consumption state of the transmit circuitry than the first low power state;receive an indication of a signal of the first link partner signaling a second low power state;enter the second low power state, the second low power state to cause a reduction in power consumed by receive circuitry during the second low power state;receive an indication of a signal of the first link partner signaling end of the second low power state;and enter a second active power state, the second active power state being a higher power consumption state of the receive circuitry than the second low power state and after a second predefined period of time, receive at least one Ethernet data frame from the first link partner.
- 11Broadest claimClaim Score 43, average(NHIP)A system comprising:network controller circuitry arranged to, when operational: cause generation of a signal for a first link partner signaling a first low power state;cause generation of a signal for the first link partner signaling end of the first low power state;await a first predefined period of time;after the first predefined period of time, cause transmission of at least one Ethernet data frame to the first link partner;receive indication of a signal from a the first link partner signaling a second low power state;receive indication of a signal from the first link partner indicating end of the second low power state;and after a second predefined period of time, receive at least one Ethernet data frame from the first link partner;wherein the network controller circuitry comprises receive circuitry and transmit circuitry.
- 24A method, comprising, at a network controller:causing generation of a signal for a first link partner signaling a first low power state;causing entering of the first low power state, the first low power state to cause a reduction in power consumed by the transmit circuitry during the first low power state;causing generation a signal for the first link partner signaling end of the first low power state;causing awaiting a first predefined period of time;after the first predefined period of time, causing transmission, in a first active power state, of at least one Ethernet data frame to the first link partner, the first active power state being a higher power consumption state of the transmit circuitry than the first low power state;receiving an indication of a signal of the first link partner signaling a second low power state;causing entering of the second low power state, the second low power state to cause a reduction in power consumed by the receive circuitry during the second low power state;receiving an indication of a signal of the first link partner signaling end of the second low power state;and causing entering a second active power state, the second active power state being a higher power consumption state of the receive circuitry than the second low power state and after a second predefined period of time, receive at least one Ethernet data frame.
- 35An article comprising a non-transitory storage medium having stored thereon instructions that when executed by a processor results in the following:causing generation of a signal for a first link partner signaling a first low power state;causing entering of the first low power state, the first low power state to cause a reduction in power consumed by the transmit circuitry during the first low power state;causing generation a signal for the first link partner signaling end of the first low power state;causing awaiting a first predefined period of time;after the first predefined period of time, causing transmission, in a first active power state, of at least one Ethernet data frame to the first link partner, the first active power state being a higher power consumption state of the transmit circuitry than the first low power state;receiving an indication of a signal of the first link partner signaling a second low power state;causing entering of the second low power state, the second low power state to cause a reduction in power consumed by the receive circuitry during the second low power state;receiving an indication of a signal of the first link partner signaling end of the second low power state;and causing entering a second active power state, the second active power state being a higher power consumption state of the receive circuitry than the second low power state and after a second predefined period of time, receive at least one Ethernet data frame.
Independent claims4
41 paragraphs in 4 sections, as filed
FIELD
The present disclosure relates to Ethernet communications, and, more particularly, to energy efficient Ethernet using active/idle toggling.
BACKGROUND
Current Ethernet solutions either remain operating at a given speed, e.g. 1000BASE-T, regardless of the bandwidth utilization, and thus consume more power than necessary, or they require software drivers to drop the link and auto-negotiate to a new, lower speed to save power, but losing link for several seconds in the process making that option unsuitable for many applications. IEEE 802.3 Working Group has recently formed an Energy-Efficient Ethernet (EEE) Task Force, officially named 802.3az, to define a solution for reducing the average power consumption of Ethernet by addressing the issues noted above with current solutions. So far there have been two proposals to the IEEE Task Force for EEE, both of which recommend rate-shifting to track the bandwidth utilization demand. Rate-shifting, as proposed by the EEE Task Force, is a technique where the Ethernet communication speed may be up-shifted or down-shifted, depending on bandwidth demand. For example, during periods of low demand, the speed may be shifted down from a fast communication speed to a slower communication speed (e.g., 1000BASE-T to 100BASE-TX). As demand increases, the speed may be shifted up.
BRIEF DESCRIPTION OF THE DRAWINGS
Features and advantages of embodiments of the claimed subject matter will become apparent as the following Detailed Description proceeds, and upon reference to the Drawings, wherein like numerals depict like parts, and in which:
<figref idrefs="DRAWINGS">FIG. 1</figref> depicts a graph of power vs. time consistent with one exemplary embodiment of the present disclosure;
<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates a system embodiment consistent with the present disclosure;
<figref idrefs="DRAWINGS">FIG. 3</figref> depicts a flowchart of exemplary data transmission operations consistent with the present disclosure;
<figref idrefs="DRAWINGS">FIG. 4</figref> depicts a flowchart of exemplary data reception operations consistent with the present disclosure;
<figref idrefs="DRAWINGS">FIG. 5A</figref> depicts a power profile graph according to a rate-shifting Ethernet communications technique; and
<figref idrefs="DRAWINGS">FIG. 5B</figref> depicts a power profile graph consistent with the present disclosure.
Although the following Detailed Description will proceed with reference being made to illustrative embodiments, many alternatives, modifications, and variations thereof will be apparent to those skilled in the art. Accordingly, it is intended that the claimed subject matter be viewed broadly, and be defined only as set forth in the accompanying claims.
DETAILED DESCRIPTION
Generally, this disclosure describes an energy-efficient Ethernet communications approach. In at least one embodiment described herein, an Ethernet controller may be configured to operate in an active power state to transmit or receive data packets (when available) at a maximum available link speed. The maximum available link speed (e.g., 1000BASE-T (GbE), 10 GBASE-T, etc.) may be determined by a negotiation between the Ethernet controller and a link partner coupled to the Ethernet controller. Once the data packets are transmitted or received, the Ethernet controller may be configured to operate in an idle power state to reduce energy consumption. The “idle power state”, as used herein, may be defined as a power state that is sufficient to maintain an open link with the link partner, but insufficient to transmit or receive data. In other words, the “idle power state”, as used herein, is a threshold power consumption state that is below a power consumption state to transmit at least one data packet, while maintaining the Ethernet communications link between the Ethernet controller and the link partner. The “active power state”, as used herein, may include an “active data transmission power state” defined as a power state to transmit data at a maximum available link speed, and an “active data receive power state” defined as a power state to receive data at a maximum available link speed.
<figref idrefs="DRAWINGS">FIG. 1</figref> depicts a graph <b>100</b> of power vs. time consistent with one exemplary embodiment of the present disclosure. In this embodiment, data packets <b>102</b><i>a</i>, <b>102</b><i>b</i>, <b>102</b><i>c </i>may be transmitted or received in a burst fashion at a maximum active power state <b>104</b> (e.g., a maximum available link speed). When data packets are available to be transmitted or received, an Ethernet controller (not shown in this Figure) may toggle power between an idle power state <b>108</b> and an active state <b>104</b>. In this example, the active power state <b>104</b> is a power state associated with the maximum available data transmission or reception speed. The idle power state <b>108</b> is a power state that is sufficient to maintain an open link with the link partner, but insufficient to transmit or receive data. The idle power state <b>108</b>, in this example, represents a power consumption that is slightly larger than an off state <b>106</b> and significantly lower than the active power state <b>104</b>.
During a transition from idle power state <b>108</b> to active power state <b>104</b>, there may be a first delay period <b>110</b>. Likewise, during a transition between the active power state <b>104</b> to the idle power state <b>108</b>, there may be a second delay period <b>112</b>. The idle interval <b>114</b> between packet bursts (e.g., between burst <b>102</b><i>a </i>and <b>102</b><i>b</i>) may be based on bandwidth considerations and/or the amount of data available in a data buffer.
<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates a system embodiment <b>200</b> consistent with the present disclosure. The system <b>200</b> includes a host system <b>202</b> and an Ethernet controller <b>220</b>. The host system <b>202</b> may include a host processor <b>204</b>, chipset circuitry <b>206</b> and system memory <b>208</b>. The host processor <b>204</b> may include one or more processor cores and may be configured to execute system software <b>210</b>. System software <b>210</b> may include, for example, operating system code <b>212</b> (e.g., OS kernel code) and local area network (LAN) driver code <b>214</b>. LAN driver code <b>214</b> may be configured to control, at least in part, the operation of the Ethernet controller <b>220</b> operation, as will be described in greater detail below. System memory <b>208</b> may include I/O memory buffers <b>216</b> configured to store one or more data packets that are to be transmitted by, or received by, Ethernet controller <b>220</b>. Chipset circuitry <b>206</b> may generally include “North Bridge” circuitry (not shown) to control communication between the processor <b>204</b>, Ethernet controller <b>220</b> and system memory <b>208</b>. Also, chipset circuitry <b>206</b> may include “South Bridge” circuitry (not shown) to control I/O communications between the host system <b>202</b> and the Ethernet controller <b>220</b>. “South Bridge” circuitry may include I/O bus circuitry which may comply, or is compatible, with PCI-Express communications protocol to provide communications between chipset circuitry <b>206</b> and the Ethernet controller <b>220</b>.
Ethernet controller <b>220</b> may be logically and/or physically divided into a transmit path <b>221</b>A and a receive path <b>221</b>B. The Ethernet controller may generally include Ethernet media access control (MAC) circuitry <b>222</b> and physical interface (PHY) circuitry <b>224</b>. MAC circuitry <b>222</b> may include transmit MAC circuitry <b>222</b>A configured to assemble data to be transmitted into frames, or packets, that include destination and source addresses along with network control information and error detection hash values. MAC circuitry <b>222</b> may also include receive MAC circuitry <b>222</b>B configured to remove data from received frames and place the data in system memory <b>208</b>. PHY circuitry <b>224</b> may include encoding circuitry <b>240</b>A configured to encode data packets and decoding circuitry <b>240</b>B configured to decode data packets. Encoding circuitry <b>240</b>A and decoding circuitry <b>240</b>B may collectively be embodied as a processor (for example, a digital signal processor) configured to perform analog-to-digital and digital-to-analog conversion, encoding and decoding of data, analog parasitic cancellation (for example, cross talk cancellation), and recovery of received data. PHY circuitry <b>224</b> may also include transmit (Tx) circuitry <b>226</b> configured to transmit one or more data packets and receive (Rx) circuitry <b>228</b> configured to receive one or more data packets. Rx circuitry <b>228</b> may include phase lock loop circuitry (PLL, not shown) configured to coordinate timing of data reception. The PHY circuitry <b>224</b> may be coupled to an Ethernet communications link <b>230</b>. The Ethernet communications link <b>230</b> may comprise, for example, a media dependent interface which may include, for example Category 6 (Cat6) Ethernet cable.
Transmit MAC circuitry <b>222</b>A may include a controllable clock input <b>242</b> and a controllable power input <b>244</b>. Clock input <b>242</b> may generally include a clock signal that controls the clocking of the MAC circuitry <b>222</b>A. Power input <b>244</b> may generally include a power supply signal to supply power to one or more components of the MAC circuitry <b>222</b>A. Similarly, Receive MAC circuitry <b>222</b>B may include a controllable clock input <b>246</b> and a controllable power input <b>248</b>. Clock input <b>246</b> may generally include a clock signal that controls the clocking of the MAC circuitry <b>222</b>B. Power input <b>248</b> may generally include a power supply signal to supply power to one or more components of the MAC circuitry <b>222</b>B. Encoding circuitry <b>240</b>A may include a controllable clock input <b>254</b> and a controllable power input <b>256</b>, and decoding circuitry <b>240</b>B may include a controllable clock input <b>258</b> and a controllable power input <b>260</b>. Transmit circuitry <b>226</b> may include a controllable clock input <b>262</b> and a controllable power input <b>264</b>. In one embodiment, clocking of the transmit path <b>221</b>A and receive path <b>221</b>B may be independently controlled. Also, in one embodiment, the power of transmit path <b>221</b>A and receive path <b>221</b>B may be independently controlled.
The Ethernet controller <b>220</b> may be configured to exchange commands and data with a link partner <b>232</b>, via communications link <b>230</b>. “Link partner” as used herein, means any device that is configured to communicate with the Ethernet controller <b>220</b> using an Ethernet communications protocol. In at least one embodiment, the link partner <b>232</b> may include a switch, bridge, router and/or other Ethernet controller (which may be associated with a host system similar to host system <b>202</b>) that may be configured and operate in a manner consistent with the description of the Ethernet controller <b>220</b> provided herein.
Ethernet controller <b>220</b> may be configured to transmit at least one data packet to the link partner <b>232</b>, or receive at least one data packet from the link partner <b>232</b>. As stated, the Ethernet controller <b>220</b> may be configured to operate, at least in part, in an idle power state and an active power state. In one embodiment, to transition into the idle state from the active data transmission power state, the Ethernet controller <b>220</b> may be configured to control the clock input <b>242</b>, <b>254</b> and/or <b>262</b>. To transition into the idle power state from an active data reception power state, the Ethernet controller <b>220</b> may be configured to control the clock input <b>246</b> and/or <b>258</b>. To that end, the clock inputs <b>242</b>, <b>254</b>, <b>262</b>, <b>246</b> and/or <b>258</b> may be gated (clock gating) to turn the clock signal OFF to the corresponding circuitry.
To permit asymmetric power management, the clock inputs of the transmit path circuitry may be controlled independently of the clock inputs of the receive path circuitry. This may allow, for example, the circuitry in that transmit path <b>221</b>A to be in the idle power state while the circuitry in the receive path <b>221</b>B is in the active state (or, vice-versa). Clock gating, as used herein, may provide a mechanism to achieve idle power state, as defined herein, in which the power consumption of the circuitry that is clock gated is sufficient to maintain an open link with the link partner <b>232</b> (via communications link <b>230</b>), but insufficient for the Ethernet controller <b>220</b> to transmit or receive data. To transition from the idle power state to the active power state, the Ethernet controller <b>220</b> may be configured to turn the clock signals <b>242</b>, <b>254</b>, <b>262</b>, <b>246</b> and/or <b>258</b> to an ON state to permit, for example, the Ethernet controller <b>220</b> to transmit and/or receive data.
Operations of the Ethernet controller <b>220</b> during data transmission and data reception, in conjunction with other features of the system of <figref idrefs="DRAWINGS">FIG. 2</figref>, are described below:
Tx Active Transition
As stated, the Ethernet controller <b>220</b> may be configured to transition, at least in part, from an idle power state to an active data transmission power state to transmit data. To that end, the LAN driver code <b>214</b>, as may be executed by host processor <b>204</b>, may be configured to determine the presence of at least one data packet, as may be stored in the I/O memory buffer <b>216</b>, to be transmitted. The driver <b>214</b> may generate a transmit active control signal to control the Ethernet controller <b>220</b> to transition from the idle power state into an active data transmission power state. The clock signals <b>242</b> may be applied to the transmit MAC circuitry <b>222</b>A, and clock signals <b>254</b> and <b>262</b> may be applied to the encoding circuitry <b>240</b>A and transmit circuitry <b>226</b>, respectively. If the link partner <b>232</b> is configured in a similar manner, transmit circuitry <b>226</b> may be configured to generate a receive active control signal to “wake up” the corresponding receive circuitry and MAC circuitry of the link partner <b>232</b> in order to prepare the link partner <b>232</b> to receive data from the Ethernet controller <b>220</b>. After a specified delay period (e.g., delay period <b>110</b> depicted in <figref idrefs="DRAWINGS">FIG. 1</figref>), the Ethernet controller <b>220</b> may begin to transmit data to the link partner <b>232</b>.
Tx Idle Transition
As stated, the Ethernet controller <b>220</b> may be configured to transition from an active data transmission power state to an idle power state. To that end, the LAN driver code <b>214</b>, as may be executed by host processor <b>204</b>, may be configured to determine that there are no data packets ready for transmission, for example, by monitoring the I/O memory buffer <b>216</b>, to determine if the buffer is empty. The driver <b>214</b> may generate an idle control signal to control the Ethernet controller <b>220</b> to transition from the active data transmission power state into the idle power state. The clock signal <b>242</b> may be gated to the MAC circuitry <b>222</b>A to permit the MAC circuitry <b>222</b>A to drop to an idle power consumption mode. Likewise, clock signals <b>254</b> and/or <b>262</b> may be gated to the encoding circuitry <b>240</b>A and/or transmit circuitry <b>226</b>, respectively, to permit the encoding circuitry <b>240</b>A and/or the transmit circuitry <b>226</b> to drop to an idle power consumption mode. If the link partner <b>232</b> is configured in a similar manner, transmit circuitry <b>226</b> may be configured to generate a receive idle control signal to transition the corresponding decoding circuitry and MAC circuitry of the link partner <b>232</b> into an idle power state.
Rx Active Transition
The Ethernet controller <b>220</b> may also be configured to transition, at least in part, from an idle power state to an active data reception power state to receive data from the link partner <b>232</b>. To that end, the link partner <b>232</b> may generate a receive active control signal to the receive circuitry <b>228</b>. To that end, while the decoding circuitry <b>240</b>B and the receive MAC circuitry <b>222</b>B may each be in an idle power state, the receive circuitry <b>228</b> may be in an active power state so that link <b>230</b> between the PHY circuitry <b>224</b> and the link partner <b>232</b> remains open. The receive active control signal generated by the link partner <b>232</b> may comprise a burst signal that can be received and recognized by the receive circuitry <b>228</b>. In response thereto, the PHY circuitry <b>224</b> may transition the decoding circuitry <b>240</b>B from an idle power state to an active power state, and PHY circuitry <b>224</b> may also generate a receive active control signal to transition the receive MAC circuitry <b>222</b>B from an idle power state to the active power state. To that end, the clock signals <b>258</b> and <b>246</b> may be applied (e.g., ungated) to the encoding circuitry <b>240</b>B and MAC circuitry <b>222</b>B, respectively, to permit the MAC circuitry <b>222</b>B and decoding circuitry <b>240</b>B to receive data from the link partner <b>232</b>. After a defined delay period (e.g., delay period <b>110</b> depicted in <figref idrefs="DRAWINGS">FIG. 1</figref>), the Ethernet controller <b>220</b> may begin to receive data from the link partner <b>232</b>. The data may be stored in the buffer memory <b>216</b>.
Rx Idle Transition
As stated, the Ethernet controller <b>220</b> may be configured to transition, at least in part, from an active data reception power state to an idle power state. To that end, PHY circuitry <b>224</b> may be configured to receive a receive idle control signal from the link partner <b>232</b>. In response thereto, the PHY circuitry <b>224</b> may transition the decoding circuitry <b>240</b>B from an active power state to the idle power state (which, as noted above, may include clock gating of the decoding circuitry <b>240</b>B). PHY circuitry <b>224</b> may also generate a receive idle control signal to transition the receive MAC circuitry <b>222</b>B from an active data reception power state to the idle power state.
The control signals exchanged between the Ethernet controller <b>220</b> and the link partner <b>232</b>, as described above, may include, for example, control frames generated by respective PHY circuitry that include encoded signals to transition to the active power state or the idle power state. Alternatively, the control signals may comprise analog burst signals having predefined characteristics that may be interpreted by respective PHY circuitry as control signals to transition into the active power state or the idle power state. Further alternatively, such control signals may be generated by MAC circuitry <b>222</b> in the form of, for example, header or footer data within a data packet.
<figref idrefs="DRAWINGS">FIG. 3</figref> depicts a flowchart <b>300</b> of exemplary data transmission operations consistent with the present disclosure. Operations may include determining if data packets are in memory and available for transmissions <b>302</b>. Operations may also include generating a transmit active control signal to transition an Ethernet controller, at least in part, from an idle power state to an active data transmission power state <b>304</b>. If a link partner, coupled to the Ethernet controller is similarly configured, operations may also include generating a receive active control signal to the link partner to cause the link partner to transition, at least in part, from an idle power state to an active data reception power state <b>306</b>. Operations may also include transmitting data packets to the link partner using a maximum negotiated speed <b>308</b>. Once the data packets are transmitted, operations may further include generating an idle control signal to transition the Ethernet controller from the active data transmission power state to the idle power <b>310</b>. Again, if the link partner is similarly configured, operations may also include generating a receive idle control signal to the link partner to cause the link partner to transition from the active data reception power state to the idle power state <b>312</b>.
<figref idrefs="DRAWINGS">FIG. 4</figref> depicts a flowchart <b>400</b> of exemplary data reception operations consistent with the present disclosure. Operations may include receiving, by an Ethernet controller, a receive active control signal from a link partner <b>402</b>. Operations may also include transitioning, at least in part and in response to the receive active control signal, the Ethernet controller from an idle power state to an active data reception power state <b>404</b>. Operations may also include receiving, by the Ethernet controller, data packets from the link partner <b>406</b>. The data packets may be stored in memory <b>408</b>. Operations may also include receiving, by the Ethernet controller, a receive idle control signal from the link partner <b>410</b>. Operations may also include transitioning, at least in part and in response to the receive idle control signal, the Ethernet controller from the active data reception power state to the idle power state <b>412</b>.
The foregoing description of idle power state in connection with an Ethernet controller offer significant power savings over other approaches. <figref idrefs="DRAWINGS">FIG. 5A</figref> depicts a power profile graph <b>502</b> according to a rate-shifting Ethernet communications technique, and <figref idrefs="DRAWINGS">FIG. 5B</figref> depicts a power profile graph <b>504</b> consistent with the present disclosure. In general, power consumption (energy consumption) may be expressed as the area under the power curve, i.e.,
<maths id="MATH-US-00001" num="00001"><math overflow="scroll"><mrow><msubsup><mo>∫</mo><mrow><mi>t</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mn>1</mn></mrow><mrow><mi>t</mi><mo></mo><mstyle><mspace width="0.3em" height="0.3ex" /></mstyle><mo></mo><mn>2</mn></mrow></msubsup><mo></mo><mrow><mrow><mi>power</mi><mo></mo><mrow><mo>(</mo><mi>t</mi><mo>)</mo></mrow></mrow><mo></mo><mstyle><mspace width="0.2em" height="0.2ex" /></mstyle><mo></mo><mrow><mo>ⅆ</mo><mi>t</mi></mrow></mrow></mrow></math></maths>
Average power may be defined as energy consumption over a given time interval. As shown, the power profile <b>502</b> of the rate-shifting technique starts at a first power level <b>506</b> where data transmission or reception is possible but at a relatively low bandwidth, for example 1/10<sup>th </sup>or 1/100<sup>th </sup>the maximum rate, and, based on increased bandwidth utilization or other considerations, increases power to a second higher level <b>508</b> for faster data transmission or reception. Thus, the energy consumption is defined as both the area under region <b>506</b> and under region <b>508</b>. In contrast, the power profile <b>504</b> according to the present disclosure, data is transmitted or received at a maximum available speed, as depicted as the area in regions <b>510</b> and <b>511</b>. Once data is transmitted or received, the power is reduced to the idle power state <b>108</b>. The average power utilized by the rate shifting technique is greater than the average power utilized by the active/idle toggle technique of the present disclosure, especially when long-term usage is considered. Unexpectedly, the applicant herein has determined that while the operating power is greater at the fastest available speed, total energy consumption is reduced, by completing the transmission more quickly and transitioning to the idle power state after data transmission or reception.
The foregoing examples are described in reference to power gating of one or more components of the Ethernet controller to achieve an idle power state. In other embodiments, additionally or as an alternative to clock gating, the Ethernet controller may also be configured to discontinue power (e.g., power gating) to the MAC circuitry <b>222</b> and/or the PHY circuitry <b>224</b>. While power gating may achieve the appropriate idle power state as defined herein, this technique may cause an additional delay between idle to active transition.
Ethernet controller <b>220</b> may also include I/O bus circuitry (not shown) to provide I/O communications between the Ethernet controller <b>220</b> and the chipset circuitry <b>206</b> (such bus circuitry may comply with the aforementioned PCI-Express communications protocol). Ethernet controller may also include MAC/PHY interface circuitry (not shown) configured to provide I/O communications between the MAC circuitry <b>220</b> and the PHY circuitry <b>224</b> (which may include, for example SGMII or XAUI).
Memory <b>208</b> and/or memory associated with the Ethernet controller <b>220</b> (not shown) may comprise one or more of the following types of memory: semiconductor firmware memory, programmable memory, non-volatile memory, read only memory, electrically programmable memory, random access memory, flash memory, magnetic disk memory, and/or optical disk memory. Either additionally or alternatively, memory <b>208</b> and/or memory associated with the Ethernet controller <b>220</b> (not shown) may comprise other and/or later-developed types of computer-readable memory. Embodiments of the methods described herein may be implemented in a computer program that may be stored on a storage medium having instructions to program a system to perform the methods. The storage medium may include, but is not limited to, any type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic and static RAMs, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), flash memories, magnetic or optical cards, or any type of media suitable for storing electronic instructions. Other embodiments may be implemented as software modules executed by a programmable control device.
The Ethernet communications protocol, described herein, may be capable permitting communication using a Transmission Control Protocol/Internet Protocol (TCP/IP). The Ethernet protocol may comply or be compatible with the Ethernet standard published by the Institute of Electrical and Electronics Engineers (IEEE) titled “IEEE 802.3 Standard”, published in March, 2002 and/or later versions of this standard.
As used herein, a “PHY” may be defined as an object and/or circuitry used to interface to one or more devices, and such object and/or circuitry may be defined by one or more of the communication protocols set forth herein. The PHY may comprise a physical PHY comprising transceiver circuitry to interface to the applicable communication link. The PHY may alternately and/or additionally comprise a virtual PHY to interface to another virtual PHY or to a physical PHY. PHY circuitry <b>224</b> may comply or be compatible with, the aforementioned IEEE 802.3 Ethernet communications protocol, which may include, for example, 100BASE-TX, 100BASE-T, 10GBASE-T, 10GBASE-KR, 10GBASE-KX4/XAUI, 40 GbE and or 100 GbE compliant PHY circuitry, and/or PHY circuitry that is compliant with an after-developed communications protocol.
“Circuitry”, as used in any embodiment herein, may comprise, for example, singly or in any combination, hardwired circuitry, programmable circuitry, state machine circuitry, and/or firmware that stores instructions executed by programmable circuitry.
The terms and expressions which have been employed herein are used as terms of description and not of limitation, and there is no intention, in the use of such terms and expressions, of excluding any equivalents of the features shown and described (or portions thereof), and it is recognized that various modifications are possible within the scope of the claims. Accordingly, the claims are intended to cover all such equivalents.
Contents4
7 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7
Every citation, both waysCites: the store holds 11 of 12
| Document | Relation | Office | Cited during |
|---|---|---|---|
| USRE49652E | Cited by | United States of America | Applicant |
| US10860079B2 | Cited by | United States of America | Applicant |
| US10386908B2 | Cited by | United States of America | Applicant |
| US8839015B2 | Cited by | United States of America | Search report |
| US2013039363A1 | Cited by | United States of America | Pre-grant |
| US9877286B2 | Cited by | United States of America | Applicant |
| USRE45600E | Cited by | United States of America | Applicant |
| US2013031395A1 | Cited by | United States of America | Pre-grant |
| US11656671B2 | Cited by | United States of America | Applicant |
| US9489033B2 | Cited by | United States of America | Search report |
| US11340681B2 | Cited by | United States of America | Applicant |
| US2012045202A1 | Cited by | United States of America | Pre-grant |
| USRE49591E | Cited by | United States of America | Applicant |
| US11570123B2 | Cited by | United States of America | Applicant |
| US10291542B2 | Cited by | United States of America | Applicant |
| US8898497B2 | Cited by | United States of America | Applicant |
| US8977877B2 | Cited by | United States of America | Search report |
| USRE45600E1 | Cited by | United States of America | Applicant |
| US2015046731A1 | Cited by | United States of America | Pre-grant |
| USRE50641E | Cited by | United States of America | Applicant |
| US2005128990A1 | Cites | United States of America | Applicant |
| US2005190709A1 | Cites | United States of America | Search report |
| WO2007049203A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| WO2009061880A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| US2009164821A1 | Cites | United States of America | Search report |
| US5802305A | Cites | United States of America | Search report |
| US6292831B1 | Cites | United States of America | Search report |
| US6463542B1 | Cites | United States of America | Search report |
| US7039430B2 | Cites | United States of America | Search report |
| US7313712B2 | Cites | United States of America | Search report |
| US7577857B1 | Cites | United States of America | Search report |
| International Preliminary Report on Patentability for PCT Patent Application No. PCT/US2008/082577 mailed on May 20, 2010, 2 pages. | Non-patent | – | Applicant |
| Agarwal, Y. et al., "Dynamic power management using on demand paging for networked embedded system.", Proceedings of the 2005 Asia and South Pacific Design Automation Conference, Jan. 18-21, 2005, pp. 755-759, vol. 2. | Non-patent | – | Applicant |
| Shih, E. et al., "Physical layer driven protocol and algorithm design for energy efficient wireless sensor networks.", Proceedings of the 7th annual international conference on Mobile computing and networking; Rome, Italy, Jul. 15-21, 2001, pp. 272-286. | Non-patent | – | Applicant |
| "Magic Packet Technology", AMD, Publication No. 20213, Rev: A, Amendment/0, Nov. 1995, pp. 1-6. | Non-patent | – | Applicant |
| International Search Report and Written Opinion received for PCT Patent Application No. PCT/US2008/082577, mailed on May 25, 2009, 10 pages. | Non-patent | – | Applicant |
| Office Action Received for Chinese Patent Application No. 200880115221.6, mailed on Apr. 6, 2012, 6 Pages of Chinese Office Action and 11 Pages of English Translation. | Non-patent | – | Applicant |
| Grow, Bob, "802.1 and Energy Efficient Ethernet", IEEE 8021.3 EEESG Interim, Seoul, Korea, Sep. 11, 2007. | Non-patent | – | Applicant |
| Haran, Onn, "Applicability of EEE to fiber PHYs", IEEE 802.3 EEE meeting, Seoul, Korea, Sep. 2007, pp. 1-12. | Non-patent | – | Applicant |
| Koenen, David, "EEE for Backplane PHYs in Blade Server Environment", IEEE 802.3 EEE SG, Mar. 2007, pp. 1-8. | Non-patent | – | Applicant |
| Koenen, David, "Potential Ethernet Controller Power Savings", EEE, Geneva, May 2007, pp. 1-5. | Non-patent | – | Applicant |
| "10GBASE-T Power Budget Summary", Tehuti Networks, Mar. 2007, pp. 1-3. | Non-patent | – | Applicant |
| Law et al., "Scope components for Rapid PHY selection", 2 pages. | Non-patent | – | Applicant |
| Law, David, "Transmit disable time in a packet based speed change protocol Impact on objectives", IEEE 802.3 EEE SG Interim Meeting, May 2007, pp. 1-8. | Non-patent | – | Applicant |
| Law, David, "Packet loss in protocol based speed change", IEEE 8023 EEE SG Interim Meeting, Sep. 2007, pp. 1-12. | Non-patent | – | Applicant |
| Holt et al., "Observations and Thoughts on Rate Switching", Mar. 31, 2001, pp. 1-8. | Non-patent | – | Applicant |
| "IEEE Energy Efficient Ethernet Study Group", Unapproved Minutes, Orlando, FL, Mar. 13-15, 2006, 10 pages. | Non-patent | – | Applicant |
| Nordman, Bruce, "Energy Efficient Ethernet: Outstanding Questions", IEEE 802 interim meeting, Monterey, California, Jan. 15-16, 2007, pp. 1-10. | Non-patent | – | Applicant |
| Nordman, Bruce, "Energy Efficient Ethernet: Outstanding Questions-Update: Mar. 2007", IEEE 802 interim meeting, Orlando, Florida, Mar. 13-15, 2007, pp. 1-5. | Non-patent | – | Applicant |
| Nordman, Bruce, "EEE Savings Estimates", IEEE 802 Plenary Meeting, San Francisco, Jul. 18, 2007, 9 pages. | Non-patent | – | Applicant |
| Nordman, Bruce, "EEE Savings Estimates", May 25, 2007, pp. 1-11. | Non-patent | – | Applicant |
| Nordman, Bruce, "Energy Efficient Ethernet: Outstanding Questions", Mar. 12, 2007, 3 pages. | Non-patent | – | Applicant |
| Nordman, Bruce, "Energy Efficient Ethernet: Outstanding Questions", Mar. 19, 2007, 3 pages. | Non-patent | – | Applicant |
| Paxson, Vern, "Some Perspectives on the Perfomance Impact of Link-Speed Switching Outages", Jul. 18, 2007, 10 pages. | Non-patent | – | Applicant |
| Powell et al., "Technical Considerations and Possible Solution Sets for EEE", IEEE 802.3 Energy Efficient Ethernet Study Group Interim Meeting, Broadcom, May 2007, pp. 1-7. | Non-patent | – | Applicant |
| Thompson, Geoff, "0-Base-T Possibilities", Presented to Energy Efficient Ethernet Study Group, Jul. 2007, 10 pages. | Non-patent | – | Applicant |
| Woodruff, "10GEEE-Time to Switch", Mar. 2007, pp. 1-8. | Non-patent | – | Applicant |
| Woodruff et al., "Efficiency and EEE-Technical Feasibility", May 29, 2007, pp. 1-15. | Non-patent | – | Applicant |
| Zimmerman, George, "Considerations for Technical Feasibility of EEE with 10GBASE 10GBASE-T", Mar. 7, 2007, pp. 1-10. | Non-patent | – | Applicant |
| "Magic Packet Technology", AMD, Publicaiton No. 20213, Rev: A, Amendment/0, Nov. 1995, pp. 1-6. | Non-patent | – | Applicant |
| Zimmerman et al., "Update on Technical Feasibility of EEE with 10GBASE 10GBASE-T", Solarfare Communication, Jul. 16, 2007, pp. 1-9. | Non-patent | – | Applicant |
| Bennett, Mike, "IEE 802.3 Energy Efficient Ethernet Study Group", Agenda and general information, San Francisco, California, Jul. 2007, pp. 1-31. | Non-patent | – | Applicant |
| Barnette et al., "Speed Switching without Communication Interruption", VITESSE, Prepared for the IEEE 802.3 Study Group, pp. 1-15. | Non-patent | – | Applicant |
| Barrass, Hugh, "IEEE Backplane Architecture", IEEE 802.3az EEE Task Force, Vancouver, British Columbia, Mar. 2009, pp. 1-10. | Non-patent | – | Applicant |
| Kasturia, "Generating the EEE Draft", 10 pages. | Non-patent | – | Applicant |
| Koenen, "Conditions for Backploane PHY EEE Transitions", HP, IEEE 802.3az, Nov. 2007, pp. 1-10. | Non-patent | – | Applicant |
| Law, "IEEE P802.3az Wait Time (Tw) From a System Design Perspective", IEEE P802.3az, IEEE Task Force, Version 3.0, pp. 1-18. | Non-patent | – | Applicant |
| Law, "IEEE 802.3 Clause 30 Management, MIB, Registers and Function", IEEE P802.3az, Energy-efficient Ethernet Task Force, Plenary Week Meeting, Nov. 2007, pp. 1-13. | Non-patent | – | Applicant |
| Nedevschi et al., "Reducing Network Energy Consumption via Sleeping and Rate-Adaptation", 12 pages. | Non-patent | – | Applicant |
| Parnaby, "10GBASE-T Parameter Values", 1 page. | Non-patent | – | Applicant |
| Powell, "A Gigabit "Subset PHYSubset PHY" Approach for 10GBASE for 10GBASE-T Energy Efficient Ethernet", BROADCOM, IEEE 802.3az EEE, Nov. 2007, 11 pages. | Non-patent | – | Applicant |
| Ratnasamy et al., "Reducing Network Energy Consumption Via Sleeping and Rate-Adaptation", pp. 1-29. | Non-patent | – | Applicant |
| Diab, Wael W., "Energy Efficient Ethernet and 802.1", IEEE 802 Plenary, Altanta, GA, Nov. 16, 2007, 23 pages. | Non-patent | – | Applicant |
| Hays, Robert, "ACtive/Idle Toggling with 0BASE-x for Energy Efficient Ethernet", IEEE 802.3az Task Force, Nov. 2007, pp. 1-22. | Non-patent | – | Applicant |
| Teener, Michael D., "Joint ITU-T/IEEE Workshop on Carrier-class Ethernet", AudioNideo Bridging for Home Networks, IEEE 802.1 AV Bridging Task Group, Geneva, May 31, 2007-Jun. 1, 2007, 35 pages. | Non-patent | – | Applicant |
| Taich et al., "Alert Signal Proposal for 10GBASE-T FEE ", Energy Efficient Ethernet (802.3az), Seoul, Korea, Sep. 2007, pp. 1-7. | Non-patent | – | Applicant |
| Thompson, Geoff, "Another Piece of EEE", An additional requirement for Energy Efficient Ethernet, Atlanta, Nov. 2007, 7 pages. | Non-patent | – | Applicant |
| Woodruff et al., "10GBASE T EEE Proposal xLPI", Aquantia, pp. 1-11. | Non-patent | – | Applicant |
| Zimmerman et al., "Deep Sleep Idle Concept for PHYs", Energy Efficient Ethernet, Solarflare Communication, Nov. 6, 2007, pp. 1-14. | Non-patent | – | Applicant |
| Barrass, Hugh, "EEE control protocol proposal", IEEE 802.3az EEE Task Force, Atlanta, Georgia, Nov. 2007, pp. 1-11. | Non-patent | – | Applicant |
| Bennett, Mike, "IEEE 802.3az Energy Efficient Ethernet", Open Questions for the Task Force, IEEE Plenary Meeting, Atlanta, GA, Nov. 2007, pp. 1-13. | Non-patent | – | Applicant |
| Diminico, Chris, "Physical Layer Considerations for Link Speed Transitions", EEE Study Group, pp. 1-8. | Non-patent | – | Applicant |
| "Broad Market Potential", IEEE interim meeting, Geneva, CH, May 2007, pp. 1-5. | Non-patent | – | Applicant |
| "Energy Efficient Ethernet Call Call-For For-Interest summary and Motion", IEEE 802.3 Working Group, Dallas, TX, Nov. 16, 2006, pp. 1-8. | Non-patent | – | Applicant |
| Bennett, Mike, "IEEE 802.3 Energy Efficient Ethernet Study Group", Agenda and general Information, Monterey, CA, Jan. 2007, pp. 1-25. | Non-patent | – | Applicant |
| Bennett, Mike, "IEEE 802.3 Energy Efficient Study Group", Agenda and general information, Orlando, FL, Mar. 2007, pp. 1-26. | Non-patent | – | Applicant |
| Bennet, Mike, "IEEE 802.3 Energy Efficient Ethernet Study Group", Agenda and general information, Ottawa, ON, Apr. 2007, pp. 1-27. | Non-patent | – | Applicant |
| Bennet, Mike, "IEEE 802.3 Energy Efficient Ethernet Study Group", Agenda and general information, Geneva, Switzerland, May 2007, pp. 1-31. | Non-patent | – | Applicant |
| "IEEE Energy Efficient Ethernet Study Group", Unapproved Minutes, Ottawa, ON, Canada, Apr. 17-18, 2007, 5 pages. | Non-patent | – | Applicant |
| Barrass, Hugh, "Energy Efficient Ethernet Objectives & 5 Criteria", A strawman to spur discussion and drive towards consensus, IEEE 802.3 Energy Efficient Ethernet, Monterey, CA, Jan. 2007, pp. 1-12. | Non-patent | – | Applicant |
| Barrass, Hugh, "Energy Efficient Ethernet Setting the bar", A system developer's view of neew PHY proposals, IEEE 802.3 Energy Efficient Ethernet, Orlando, Florida, Mar. 2007, pp. 1-7. | Non-patent | – | Applicant |
| Barrass, Hugh, "Energy Efficient Ethernet Beyond the PHY", Power savings in networked systems, IEEE 802.3 Energy Efficient Ethernet, Geneva, Switzerland, May 2007, pp. 1-12. | Non-patent | – | Applicant |
| Barrass, Hugh, "Energy Efficient Ethernet Transparent-not invisible", Some important considerations for management of EEE, IEEE 802.3 Energy Efficient Ethernet, San Francisco, Jul. 2007, pp. 1-8. | Non-patent | – | Applicant |
| Bennett, Mike, "IEEE 802.3 Energy Efficient Ethernet Study Group, " Server Bandwidth Utilization plots, Orlando, FL, Mar. 2007, pp. 1-13. | Non-patent | – | Applicant |
| Booth, Brad, "802.3 Standards Development Lessons Learned", AMCC, Jan. 2007, pp. 1-19. | Non-patent | – | Applicant |
| Chadha et al., "Feasibility of 1000-Base-T RPS Restart", Vitesse, IEEE 802.3 EEE SG, Interim Meeting, Apr. 2007, pp. 1-9. | Non-patent | – | Applicant |
| Chadha et al., "10BT Amplitude Optimization", Vitesse, IEEE 802.3 EEE SG, Interim Meeting, Apr. 2007, pp. 1-5. | Non-patent | – | Applicant |
| Chalupsky et al., "A Brief Tutorial on Power Management in Computer Systems", Intel Corporation, Mar. 11, 2007, pp. 1-28. | Non-patent | – | Applicant |
| Christensen, Ken, "Rapid PHY Selection (RPS): A Performance Evaluation of Control Policies Policies", IEEE 802.3 EEE Study Group, Monterey CA Jan. 15, 2007, pp. 1-45. | Non-patent | – | Applicant |
| Christensen, Ken "Rapid PHY Selection (RPS): Emulation and Experiments using PAUSE", IEEE 802.3 Eee Study Group, Orlando, FL, Mar. 13, 2007, pp. 1-16. | Non-patent | – | Applicant |
14 members in 4 offices
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 93632707 | United States of America | A | |
| US20070936327 | – | – | – |
Members14
| Document | Office | Kind | |
|---|---|---|---|
| US2009119524A1 | United States of America | A1 | |
| WO2009061880A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2009061880A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP2210368A2 | European Patent Office (EPO) | A2 | |
| CN101855865A | China | A | |
| US8312307B2This record | United States of America | B2 | |
| CN102843239A | China | A | |
| US2013039363A1 | United States of America | A1 | |
| EP2210368A4 | European Patent Office (EPO) | A4 | |
| US8839015B2 | United States of America | B2 | |
| US2015046731A1 | United States of America | A1 | |
| EP2210368B1 | European Patent Office (EPO) | B1 | |
| US9489033B2 | United States of America | B2 | |
| CN102843239B | China | B |
90 transactions on the USPTO file
Allowed after 2 non-final rejections, 1 final rejection and 1 RCE.
- Non-final rejections
- 2
- Final rejections
- 1
- RCEs
- 1
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Payment of Maintenance Fee, 12th Year, Large EntityM1553 | M1553 | |
| Payment of Maintenance Fee, 8th Year, Large EntityM1552 | M1552 | |
| Email NotificationEML_NTR | EML_NTR | |
| Change in Power of Attorney (May Include Associate POA)PA.. | PA.. | |
| Correspondence Address ChangeC.AD | C.AD | |
| Email NotificationEML_NTR | EML_NTR | |
| Change in Power of Attorney (May Include Associate POA)PA.. | PA.. | |
| Correspondence Address ChangeC.AD | C.AD | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Email NotificationEML_NTR | EML_NTR | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Examiner's Amendment CommunicationEX.A | EX.A | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Response after Non-Final ActionA... | A... | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Email NotificationEML_NTR | EML_NTR | |
| Change in Power of Attorney (May Include Associate POA)PA.. | PA.. | |
| Correspondence Address ChangeC.AD | C.AD | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Response after Non-Final ActionA... | A... | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Email NotificationEML_NTR | EML_NTR | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| IFW TSS Processing by Tech Center CompleteTSSCOMP | TSSCOMP | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Sent to Classification ContractorPGPC | PGPC | |
| Filing Receipt - UpdatedFLRCPT.U | FLRCPT.U | |
| Application Is Now CompleteCOMP | COMP | |
| Additional Application Filing FeesADDFLFEE | ADDFLFEE | |
| A statement by one or more inventors satisfying the requirement under 35 USC 115, Oath of the ApplicOATHDECL | OATHDECL | |
| Filing ReceiptFLRCPT.O | FLRCPT.O | |
| Notice Mailed--Application Incomplete--Filing Date AssignedINCD | INCD | |
| Cleared by OIPE CSRL194 | L194 | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| Initial Exam Team nnIEXX | IEXX |
6 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Maintenance fee paymentMAFP | MAFP | |
| Maintenance fee paymentMAFP | MAFP | |
| Fee paymentFPAY | FPAY | |
| Fee payment procedurePAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYFEPP | FEPP | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| AssignmentAS | AS |
Numbers
- Publication
- 08312307
- Publication, DOCDB
- 8312307
- Publication, EPODOC
- US8312307
- Application
- 11936327
- Application, DOCDB
- 93632707
- Application, EPODOC
- US20070936327
Titles
- English
- Systems and methods for reducing power consumption during communication between link partners
Patent term adjustment
- A delay
- +734 daysthe office missed an examination deadline
- B delay
- +384 dayspendency past three years
- Overlap
- −65 daysdelays counted once
- Applicant delay
- −134 days
- Net adjustment
- 919 days
Classification
- CPC, 3
- H04L12/10
- G06F1/324
- G06F1/3293
- IPC, 1
- G06F1 00
- USPC, 2
- 713323000
- 713320000