Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This application has been examined. Claims 1-20 are pending.
The Group and/or Art Unit location of your application in the PTO has changed. To aid in correlating any papers for this application, all further correspondence regarding this application should be directed to Group Art Unit 2175.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claim Objections
Claim 1 is objected to because of the following informalities:
Claim 1 recites the clause “receive, at a media access controller block, a message via an application programming interface, from software” in the middle of an apparatus claim. This clause is drafted in imperative/method form and is grammatically disconnected from the surrounding apparatus elements (“a processor; physical layer (PHY) hardware…; PHY management software…”). It is unclear whether this clause is intended to positively recite a structural element (e.g., the media access controller block) or a function performed by such an element. Appropriate correction is required. See the § 112 rejection below, which addresses the substantive indefiniteness arising from the same clause.
Claim Rejections - 35 USC § 112
The following is a quotation of the second paragraph of 35 U.S.C. 112:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-14 are rejected under 35 U.S.C. 112(b) as failing to particularly point out and distinctly claim the subject matter regarded as the invention.
Claim 1:
(a) Claim 1 recites “receive, at a media access controller block, a message via an application programming interface, from software wherein the media access controller block comprises controller firmware and controller hardware….” This limitation renders the claim indefinite for two reasons. First, the “receive…” clause is in method/functional form embedded within an apparatus claim, and it is unclear what structure (if any) is required to perform the recited receiving, or whether the clause is intended to further define the “media access controller block” as a positively-recited element. A single claim which recites both an apparatus and the method steps of using the apparatus is indefinite under IPXL Holdings v. Amazon.com, 430 F.3d 1377 (Fed. Cir. 2005) and MPEP § 2173.05(p)(II), because it is unclear whether infringement occurs when the apparatus is made or when it is used. Second, “the media access controller block” appears in this clause without a prior positive recitation of “a media access controller block” as an element of the apparatus, creating a lack of antecedent basis.
(b) Claim 1 separately recites “the PHY management software is to call on an application programming interface (API)” after having earlier recited “a message via an application programming interface.” It is unclear whether the later-recited “an application programming interface (API)” is the same as, or different from, the “application programming interface” recited in the “receive…” clause. Consistent terminology and clear antecedent basis are required.
(c) Claims 10, 12 and 13 recite “the PHY management application.” Claim 1, from which these claims depend (directly or indirectly), recites “PHY management software” but does not recite a “PHY management application.” There is insufficient antecedent basis for “the PHY management application” in these claims. It is unclear whether “the PHY management application” refers to the previously-recited “PHY management software” or to a distinct element. Claims 2-9, 11 and 14 are rejected as depending from claim 1 and failing to cure its deficiencies.
Examiner's note: For purposes of applying prior art below, and consistent with MPEP § 2173.06, the Examiner interprets “PHY management software” and “PHY management application” as referring to the same element, and interprets the “receive…” clause of claim 1 as a functional recitation of the media access controller block (i.e., that the block is configured to receive, via the API, a message from the PHY management software). Applicant should not construe the art rejection as an indication that the claims are definite.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 15-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claim 15 recites “at least one non-transitory machine readable medium with instructions,” and claims 16-17 depend therefrom. The claims are therefore directed to a statutory category (a manufacture).
With respect to claim 15:
2A Prong 1: the claim recites a judicial exception.
• “determine, using the PHY management application, that an external PHY device is coupled to the Ethernet subsystem” (mental process - observation)
• “determine, using the PHY management application, capabilities of the PHY hardware block” (mental process - evaluation)
• “determine attributes of the external PHY device” (mental process - observation or evaluation)
• “determine configuration parameters for an Ethernet link based on the attributes of the PHY hardware block and the external PHY block” (mental process - evaluation or judgement)
2A Prong 2: This judicial exception is not integrated into a practical application.
• “at least one non-transitory machine readable medium with instructions stored thereon, the instructions executable by a machine to cause the machine to” (generic computer components recited at a high level of generality and used as tools to apply the exception, which does not improve the functioning of the computer itself - see MPEP 2106.05(a); mere instructions to apply an exception - see MPEP 2106.05(f))
• “load a set of APIs for management of a physical layer of an Ethernet subsystem, wherein the Ethernet subsystem comprises a local PHY hardware block to implement a port and a MAC block, wherein the MAC block comprises MAC hardware and MAC firmware” (generic PHY/MAC hardware and firmware used as tools; no improvement to the computer itself - see MPEP 2106.05(a); mere instructions to apply an exception - see MPEP 2106.05(f))
• “load a PHY management application in an application layer, wherein the PHY management application is to use the set of APIs” (mere instructions to apply an exception using a generic software application - see MPEP 2106.05(f))
• “send commands from the PHY management application via the set of APIs to direct the MAC firmware to configure the Ethernet link based on the configuration parameters” (insignificant extra-solution activity - mere data output; and mere instructions to apply an exception - see MPEP 2106.05(f) and (g))
2B: The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
• “at least one non-transitory machine readable medium with instructions stored thereon, the instructions executable by a machine” (generic computer components - see MPEP 2106.05(a), (f); WURC: storing and retrieving information in memory - see MPEP 2106.05(d)(II)(iii))
• “load a set of APIs for management of a physical layer of an Ethernet subsystem... a local PHY hardware block... and a MAC block... comprising MAC hardware and MAC firmware” (configuring a communications link via a MAC/PHY firmware interface using an API is well-understood, routine, and conventional, as evidenced by Dubal (US 10,007,634 B2, col. 4 l. 60 - col. 6 l. 10) and Khan (US 11,398,880 B2, providing an API between PHY-layer and MAC-layer software modules) - see MPEP 2106.05(d)(II))
• “load a PHY management application in an application layer” (generic software performing generic loading functions - see MPEP 2106.05(d)(II))
• “send commands from the PHY management application via the set of APIs to direct the MAC firmware to configure the Ethernet link” (WURC: receiving or transmitting data over a network - see MPEP 2106.05(d)(II)(i))
With respect to claims 16 and 17:
2A Prong 1: the claim recites a judicial exception.
• (claim 17) “perform diagnostics, at the PHY management application, for the Ethernet link based on the status information” (mental process - evaluation or judgement)
2A Prong 2 and 2B: This judicial exception is not integrated into a practical application, and the claims do not include additional elements sufficient to amount to significantly more.
• (claim 16) “receive, at the PHY management application, through the set of APIs, status information for the Ethernet link, wherein the status information comprises information associated with the external PHY device” (insignificant extra-solution activity - mere data gathering - see MPEP 2106.05(g); WURC: receiving or transmitting data over a network - see MPEP 2106.05(d)(II)(i))
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art t which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 7-9, 11-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Dubal et al. (US 10,007,634 B2, hereinafter “Dubal”) in view of Khan et al. (US 11,398,880 B2, hereinafter “Khan”).
In order to expedite and avoid piecemeal prosecution, the following rejection is made to the extent that the claims are understood, by considering those elements which are understood and interpreting their function in a manner which is consistent with the recited goals of the claims, and then applying the best available art.
The examiner relies on the entire teachings of Dubal and Khan references; the applicant should carefully consider the entire teachings of the above-mentioned references to better understand the examiner’s position.
In regard to claim 1, Dubal teaches an apparatus comprising: a processor; physical layer (PHY) hardware, wherein the physical layer hardware comprises circuitry to implement at least a portion of a link (as shown in Fig. 4, which is reproduced below for ease of reference and convenience, Dubal discloses an apparatus, i.e. an integrated circuit / computer platform including a processor SoC 402 with CPU 406 and processor cores 408. (Dubal, col. 6:8-66; FIG. 4, element 406/408). Dubal discloses PHY hardware, i.e. a third-party physical layer part (PHY) 120 comprising circuitry and logic to implement PHY-layer operations for one or more physical media, implementing at least a portion of an Ethernet link. (Dubal, col. 3:38-4:8; FIG. 1, element 120; FIG. 1a, ports 140/142/144/146);
PNG
media_image1.png
919
698
media_image1.png
Greyscale
receive, at a media access controller block, a message via an application programming interface, from software wherein the media access controller block comprises controller firmware and controller hardware, wherein the controller hardware is to interface with the PHY hardware to establish the link (in Dubal, discloses a media access controller (MAC) block 108 comprising controller firmware (FW 112 in MAC NVM 110) and controller hardware, wherein the MAC hardware interfaces (via MAC-to-PHY interface 109 / connector 106) with PHY 120 to establish the link. (Dubal, col. 3:1-4:18; FIG. 1, elements 108/109/110/112); and
PHY management software, executable by the processor, to configure a physical layer of the link, wherein the PHY management software is to call on an application programming interface (API) to send commands to the controller firmware and direct configuration of the physical layer of the link via the controller firmware, wherein the API abstracts functions of the controller firmware to be used to configure the physical layer of the link (in Dubal, discloses firmware-based software that configures the physical layer of the link (firmware 112 selects and executes a PHY configuration script to configure PHY 120 and its ports). (Dubal, col. 4:34-5:50; FIG. 2b, blocks 224/226). Dubal does not expressly teach that the MAC block receives a message via an application programming interface (API) from software (Dubal's MAC firmware is driven by an internal pre-boot process rather than by an application-layer API call) and the PHY management software that calls on an API to send commands to the controller firmware, where the API abstracts functions of the controller firmware (Dubal's configuration logic resides in the firmware/pre-boot layer, not in application-layer software calling through an abstracting API). In the same field of endeavor, Khan expressly disclose the MAC block receives a message via an application programming interface (API) from software (Dubal's MAC firmware is driven by an internal pre-boot process rather than by an application-layer API call) (as shown in Fig. 3, which is reproduced below for ease of reference and convenience, Khan supplies an API through which higher-layer software sends configuration messages to the layer that manages the PHY: Khan provides “an application programming interface between the L1 [PHY] software module and the L2 [MAC] software module for receiving L1 configuration messages,” i.e., the MAC/L2 side receives messages via the API. (Khan, claim 1; col. 4:25-44; col. 9:22-10:18; FIG. 3),
PNG
media_image2.png
857
767
media_image2.png
Greyscale
and the PHY management software that calls on an API to send commands to the controller firmware, where the API abstracts functions of the controller firmware (Dubal's configuration logic resides in the firmware/pre-boot layer, not in application-layer software calling through an abstracting API) (in Khan, supplies application-layer PHY management software that uses an API to direct the MAC/PHY-managing firmware to configure the physical layer, where the API (e.g., a FAPI) abstracts the underlying PHY/MAC functions so that the higher layer need not directly manipulate PHY registers. (Khan, col. 1:28-41; col. 4:6-44; claim 12 (FAPI); FIG. 3). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the firmware-driven PHY-card configuration system of Dubal to be driven by application-layer PHY management software that calls upon an abstracting API to send configuration commands to the controller firmware, as taught by Khan. The motivation to do so is expressly provided by Khan, which teaches that placing PHY management under a software module communicating through an API (i) provides flexibility and the ability to send the “next best known configuration” rather than an invalid one, and (ii) enables faster, more granular debugging and diagnostics by pinpointing configuration errors at the PHY layer.
In regard to claim 2, Dubal teaches wherein the PHY management software is to direct configuration of a local port implemented by the PHY hardware local port (in Dubal, discloses configuration of local ports implemented by the PHY hardware, i.e. PHY 120 implements local ports (e.g., 10 Gb Ethernet ports 140/142 and 40 Gb ports 144/146), and the firmware/PHY configuration script configures these ports of the PHY card. (Dubal, col. 3:45-4:18; FIG. 1a.) In the Dubal/Khan combination, the application-layer PHY management software (Khan) directs this configuration).
In regard to claim 3, Dubal teaches wherein the PHY management software is to identify attributes of an external PHY device coupled to the apparatus by the local port, wherein the external PHY device facilitates a connection with a link partner device over the link and is positioned between the local port and the link partner device on the link (in Dubal, discloses identifying attributes of an external PHY device, i.e. the mezzanine PHY card 104 is an external, field-replaceable PHY device coupled to the IC; firmware reads the PHY card ID and configuration parameters (attributes: number of ports, device/sub-device IDs, connection type, media). The external PHY card facilitates the connection between the SoC/PCH and the physical media / link partner and is positioned between the local MAC/port and the link partner. (Dubal, col. 3:1-57; col. 5:2-38; FIG. 3, elements 300-312; FIGS. 1, 1a). But Dubal’s reading/identifying of the PHY card attributes is performed by firmware; Dubal does not teach that PHY management software (application layer) performs this identification. Khan supplies the application-layer software that, through the API, obtains PHY-layer parameters/capabilities and status. In the combination, the identification of the external PHY device's attributes is directed by the application-layer PHY management software. (Khan, col. 3 l. 55 - col. 5 l. 10; FIG. 3). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the firmware-driven PHY-card configuration system of Dubal to be driven by application-layer PHY management software that calls upon an abstracting API to send configuration commands to the controller firmware, as taught by Khan. The motivation to do so is expressly provided by Khan, which teaches that placing PHY management under a software module communicating through an API (i) provides flexibility and the ability to send the “next best known configuration” rather than an invalid one, and (ii) enables faster, more granular debugging and diagnostics by pinpointing configuration errors at the PHY layer.
In regard to claim 7, Dubal teaches wherein the PHY management software directs configuration of the local port based on the attributes of the external PHY device (in Dubal, discloses configuring the local port/MAC based on attributes read from the external PHY card, i.e. the firmware programs PCIe configuration parameters and selects the PHY configuration script based on the PHY card ID and the read configuration parameters, thereby configuring the ports according to the external PHY card's attributes. (Dubal, col. 5:3-50; FIG. 2b, blocks 220-226.) In the combination, this configuration is directed by the application-layer PHY management software (Khan).
In regard to claim 8, Dubal teaches wherein the PHY management software is to further use the API to direct configuration of one or more ports of the external PHY device (in Dubal, discloses configuring one or more ports of the external PHY device i.e. the selected PHY configuration script is executed over the sideband interface 136 to configure the PHY card's ports, which then initiate link negotiation. (Dubal, col. 5:2-50; FIG. 2b, blocks 226-228). But Dubal performs this configuration via firmware over a sideband channel, not via an application-layer API. However Khan supplies the API through which the application-layer software issues the configuration commands; in the combination the PHY management software uses the API to direct configuration of the external PHY device's ports. (Khan, abstract; col. 3:1-12). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the firmware-driven PHY-card configuration system of Dubal to be driven by application-layer PHY management software that calls upon an abstracting API to send configuration commands to the controller firmware, as taught by Khan. The motivation to do so is expressly provided by Khan, which teaches that placing PHY management under a software module communicating through an API (i) provides flexibility and the ability to send the “next best known configuration” rather than an invalid one, and (ii) enables faster, more granular debugging and diagnostics by pinpointing configuration errors at the PHY layer.
In regard to claim 9, Dubal teaches wherein the attributes of the external PHY device comprise at least one of a type of the external PHY device, port modes supported by the external PHY device, or a media used by the external PHY device (in Dubal, discloses that the attributes read from the external PHY card include a type/ID of the PHY device (PHY card ID / per-implementation ID), the number and type of ports, connection-type IDs, and the media supported by each port (e.g., SFP+, RJ45, QSFP+, 10G/40G media). This reads on “a type of the external PHY device… or a media used by the external PHY device.” (Dubal, col. 4:8-24; col. 5:15-50; FIG. 1, connectors 122/124/126/128; FIG. 3, elements 306/308/310).
In regard to claim 11, Dubal teaches wherein configuration of the physical layer of the link comprises equalization of one or more ports used to establish the link (in Dubal, discloses configuration of the physical layer including link-negotiation/electrical setup of the ports; the PHY 120 implements PMA/PMD sublayers per IEEE 802.3 (e.g., 10GBASE-KR, 40GBASE-KR4), which inherently involve equalization for backplane/copper links, and the PHY card initiates link negotiation for each port. (Dubal, col. 4:8-24). But Dubal does not use the word “equalization” expressly. To the extent Dubal does not use the word “equalization” expressly, the Examiner takes Official Notice that equalization of ports is a well-known and conventional part of establishing high-speed serial/Ethernet links (e.g., KR-type backplane links expressly recited in Dubal require transmitter/receiver equalization per IEEE 802.3 Clause 72/93). It would have been obvious to include equalization as part of the physical-layer configuration to establish a reliable link with a predictable result. See MPEP § 2144.03.
In regard to claim 12, Khan teaches wherein the API is associated with a software development kit (SDK), and the PHY management application is written based on the SDK (in Khan, supplies the API framework (FAPI) which is a standardized application- programming-interface specification against which higher-layer PHY-management software is written, functioning as a software development kit / defined API library for developing PHY-management software. (Khan, col. 3:1-12; col. 4:6-44; claim 12.) It would have been obvious to write the PHY management software of the combination against such a defined API/SDK to enable interoperable development, as taught by Khan). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the firmware-driven PHY-card configuration system of Dubal to be driven by application-layer PHY management software that calls upon an abstracting API to send configuration commands to the controller firmware, as taught by Khan. The motivation to do so is expressly provided by Khan, which teaches that placing PHY management under a software module communicating through an API (i) provides flexibility and the ability to send the “next best known configuration” rather than an invalid one, and (ii) enables faster, more granular debugging and diagnostics by pinpointing configuration errors at the PHY layer.
In regard to claim 13, Dubal teaches wherein the SDK enables development of a plurality of different PHY management applications to interoperate with respective instances of the controller firmware (in Khan, teaches that its API (FAPI) is a standardized interface enabling different vendors' higher-layer software modules to interoperate with different underlying PHY/firmware implementations across 2G/3G/4G/5G/Wi-Fi/multi-RAT, i.e., a plurality of different management applications interoperating with respective firmware instances. (Khan, col. 10:22-12:14). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the firmware-driven PHY-card configuration system of Dubal to be driven by application-layer PHY management software that calls upon an abstracting API to send configuration commands to the controller firmware, as taught by Khan. The motivation to do so is expressly provided by Khan, which teaches that placing PHY management under a software module communicating through an API (i) provides flexibility and the ability to send the “next best known configuration” rather than an invalid one, and (ii) enables faster, more granular debugging and diagnostics by pinpointing configuration errors at the PHY layer.
In regard to claim 14, Dubal teaches wherein the link is to be established based on an Ethernet-based protocol (in Dubal, discloses that the links are Ethernet links established per IEEE 802.3 (10 GbE, 40 GbE, etc.). (Dubal, col. 4:8-24) Khan likewise contemplates Ethernet (Khan, col. 10:22-12:14).
In regard to claim 15, Dubal teaches at least one non-transitory machine readable medium with instructions stored thereon, the instructions executable by a machine to cause the machine to:
load a set of application programming interfaces (APIs) for management of a physical layer of an Ethernet subsystem, wherein the Ethernet subsystem comprises a local physical layer (PHY) hardware block to implement a port and a media access controller (MAC) block, wherein the MAC block comprises MAC hardware and MAC firmware (as shown in Fig. 4, which is reproduced below for ease of reference and convenience, Dubal discloses firmware instructions stored on non-transitory medium (MAC NVM 110 / BIOS/firmware) executable by a processing element. (Dubal, col. 3:1-25; and Dubal's machine-readable-medium disclosure). Dubal discloses the Ethernet subsystem, i.e. a local PHY hardware block (PHY 120) implementing a port, and a MAC block 108 comprising MAC hardware and MAC firmware (FW 112). (Dubal, col. 3:1-57; FIG. 1);
PNG
media_image3.png
426
324
media_image3.png
Greyscale
determine, using the PHY management application, that an external physical layer (PHY) device is coupled to the Ethernet subsystem (in Dubal, discloses determining that an external PHY device (mezzanine PHY card 104) is coupled firmware reads the PHY card ID present on the installed card and validates it against a list. (Dubal, col. 4:43-5:29; FIG. 2a, blocks 208-216.) In the combination, the determination is performed by the application-layer PHY management software);
determine, using the PHY management application, capabilities of the PHY hardware block (in Dubal, discloses determining capabilities/attributes that is reading the number of ports, device/subdevice IDs, connection types, and supported media of the PHY card, and the SoC/PCH's list of supported PHY configurations. (Dubal, col. 5:30-50; FIG. 3, elements 302-312);
determine, using the PHY management application, attributes of the external PHY device; determine, using the PHY management application, configuration parameters for an Ethernet link based on the attributes of the PHY hardware block and the external PHY block (in Dubal, discloses determining configuration parameters based on the read attributes then selecting the PHY configuration script and programming PCIe configuration parameters based on the PHY card ID and read parameters. (Dubal, col. 5:30-50; FIG. 2b, blocks 220-226.)
send commands from the PHY management application via the set of APIs to direct the MAC firmware to configure the Ethernet link based on the configuration parameters (in Dubal, discloses sending commands to configure the link then firmware executes the configuration script to configure the PHY/ports and MAC PCIe space. (Dubal, col. 5:51-6:67; claim 1). But Dubal does not expressly teach loading a set of APIs for physical-layer management and commands from an application-layer PHY management application via an API; load a PHY management application in an application layer, wherein the PHY management application is to use the set of APIs. In the same field of endeavor, Khan expressly teaches loading a set of APIs for physical-layer management (as shown in Fig. 3, which is reproduced below for ease of reference and convenience, Khan expressly supplies loading/providing a set of APIs (FAPI) for management of the PHY layer between the software modules. (Khan, col. 2:47-3:12; claim 1);
PNG
media_image4.png
382
427
media_image4.png
Greyscale
load a PHY management application in an application layer, wherein the PHY management application is to use the set of APIs (in Khan, supplies an application-layer PHY management software module (L2/MAC-side software) that uses the API to manage the PHY. (Khan, col. 2:38-67; col. 10:35-63; FIG. 4, SON/processor modules) and
commands from an application-layer PHY management application via an API (in Khan, supplies sending configuration commands/messages from the application-layer software, via the API, to direct the PHY/MAC-managing firmware to configure the link. (Khan, claim 1; col. 2:38-59; col. 9:22-10:18; FIG. 3).
It would have been obvious to drive Dubal's PHY/MAC configuration from an application-layer management application through Khan's abstracting API to obtain the flexibility and enhanced diagnostic/debug capabilities expressly taught by Khan, with a reasonable expectation of success. See KSR, 550 U.S. 398; MPEP § 2143(A),(C),(D).
In regard to claim 16, Khan teaches wherein the instructions are further executable to: receive, at the PHY management application, through the set of APIs, status information for the Ethernet link, wherein the status information comprises information associated with the external PHY device (in Khan, supplies receiving, through the API, status/error indication information reported from the PHY layer up to the higher-layer software, including component-level information identifying where an error occurred. (Khan, Abstract; col. 2:17-38; FIG. 2). Dubal further discloses propagating error/status information (error codes) associated with the external PHY card. (Dubal, col. 5:3-29). It would have been obvious to drive Dubal's PHY/MAC configuration from an application-layer management application through Khan's abstracting API to obtain the flexibility and enhanced diagnostic/debug capabilities expressly taught by Khan, with a reasonable expectation of success. See KSR, 550 U.S. 398; MPEP § 2143(A),(C),(D).
In regard to claim 17, Khan teaches wherein the instructions are further executable to cause the machine to perform diagnostics, at the PHY management application, for the Ethernet link based on the status information (in Khan, supplies performing diagnostics based on the status information so the higher-layer software uses the progressively-generated enhanced error codes to pinpoint and diagnose configuration errors and to select corrective configurations. (Khan, col. 9:22-10:18). It would have been obvious to drive Dubal's PHY/MAC configuration from an application-layer management application through Khan's abstracting API to obtain the flexibility and enhanced diagnostic/debug capabilities expressly taught by Khan, with a reasonable expectation of success. See KSR, 550 U.S. 398; MPEP § 2143(A),(C),(D).
In regard to claim 18, Dubal teaches a system comprising: a host processor device comprising: a processor; an Ethernet subsystem comprising: a controller; physical layer (PHY) hardware to implement a port (as shown in Fig. 4, which is reproduced below for ease of reference and convenience, Dubal discloses a host processor device (SoC/PCH) with a processor, and an Ethernet subsystem comprising a controller (MAC block 108) and PHY hardware (PHY 120) implementing a port. (Dubal, col. 3:1-57; FIGS. 1, 4, 5));
PNG
media_image3.png
426
324
media_image3.png
Greyscale
a PHY management application to call the set of PHY management APIs to direct one of firmware of the controller or firmware of the PHY hardware to configure a link to couple the port to a link partner device (in Dubal, discloses firmware of the controller/PHY that configures the link to a link partner. (Dubal, col. 5:30-67; col. 6:36-67). Dubal does not expressly teach an application layer comprising: a set of PHY management APIs to abstract details of the controller and PHY hardware; and the application-layer PHY management application calling APIs to direct that firmware. In the same field of endeavor, Khan expressly teaches an application layer comprising: a set of PHY management APIs to abstract details of the controller (as shown in Fig. 3, which is reproduced below for ease of reference and convenience, Khan supplies an application layer with a set of PHY management APIs (FAPI) that abstract the details of the PHY/MAC so higher-layer software need not directly manipulate PHY hardware. (Khan, 9:22-10:18)
PNG
media_image4.png
382
427
media_image4.png
Greyscale
and PHY hardware; and the application-layer PHY management application calling APIs to direct that firmware (in Khan, supplies the PHY management application calling the API to direct the PHY/MAC firmware to configure the link. (Khan, claim 1; col. 2:17-59; col. 9:22-10:18). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the firmware-driven PHY-card configuration system of Dubal to be driven by application-layer PHY management software that calls upon an abstracting API to send configuration commands to the controller firmware, as taught by Khan. The motivation to do so is expressly provided by Khan, which teaches that placing PHY management under a software module communicating through an API (i) provides flexibility and the ability to send the “next best known configuration” rather than an invalid one, and (ii) enables faster, more granular debugging and diagnostics by pinpointing configuration errors at the PHY layer.
In regard to claim 19, Dubal teaches further: an external PHY device to couple to the port, wherein the external PHY device is to implement at least a segment of the link; a management interface device to couple the Ethernet subsystem to the external PHY device by a set of out-of-band control lanes, wherein the set of PHY management APIs enable the PHY management application to at least one of: receive information sent from the external PHY device on the set of control lanes; or send control information to the external PHY device on the set of control lanes (in Dubal, discloses the external PHY device (mezzanine PHY card 104) implementing a segment of the link, and a management/sideband interface coupling the subsystem to the external PHY device by out-of-band control lanes (sideband signals 130/136) over which configuration data and control are exchanged. (Dubal, col. 3:1-57; FIG. 1, sideband signals 130/136; claim 18 (sideband channel)). But Dubal does not teach exchanges the information via application-layer PHY management APIs. However, Khan expressly teaches exchange the information via application-layer PHY management APIs (in Khan, supplies the APIs enabling the application-layer software to send/receive the control and status information; in the combination the PHY management APIs enable the application to communicate with the external PHY device over Dubal's out-of-band control lanes. (Khan, claim 1; col. 5:8-6:49; table 2). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the firmware-driven PHY-card configuration system of Dubal to be driven by application-layer PHY management software that calls upon an abstracting API to send configuration commands to the controller firmware, as taught by Khan. The motivation to do so is expressly provided by Khan, which teaches that placing PHY management under a software module communicating through an API (i) provides flexibility and the ability to send the “next best known configuration” rather than an invalid one, and (ii) enables faster, more granular debugging and diagnostics by pinpointing configuration errors at the PHY layer.
In regard to claim 20, Dubal teaches wherein the external PHY device comprises one of a retimer, media conversion device, or PHY device to support a particular port mode (in Dubal, discloses that the external PHY card is a PHY device supporting particular port modes (e.g., a mezzanine card supporting 10 GbE and 40 GbE port modes with various media). This reads on “a PHY device to support a particular port mode” (and, via the various media connectors SFP+/QSFP+/RJ45, a media-conversion function). (Dubal, col. 4:8-24; col. 5:15-50; FIG. 1a)).
Examiner's note:
Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passages as taught by the prior art or disclosed by the Examiner.
Allowable Subject Matter
Claims 4-6, 10 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112, 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
16. The following is an Examiner's statement of reasons for the indication of allowable subject matter:
Claim 4 recites that the external PHY device comprises a retimer. Neither Dubal nor Khan teaches or suggests a retimer positioned between the local port and the link partner whose configuration is directed by the application-layer PHY management software. Dubal's external device is a PHY card (a media-terminating PHY), not a retimer/repeater on the link between endpoints. The prior art of record does not teach this limitation, and the Examiner has not located a reasonable basis to combine a retimer teaching into the Dubal/Khan combination without impermissible hindsight.
Claim 5 recites the external PHY device comprising a media module that transitions from a first media in a first link segment to a second media in a second link segment (i.e., a media-converting device inserted mid-link between two distinct link segments coupling the local port to the external device and the external device to the link partner). Dubal's PHY card terminates media at the platform edge; it does not disclose an external media module bridging two distinct link segments between the local port and a separate link partner, with its configuration directed by the PHY management software. Not taught or suggested by the art of record.
Claim 6 recites that the external PHY device supports a particular port mode not supported by the PHY hardware and facilitates use of that port mode on the link. The art of record does not teach an external PHY device extending the local PHY's port-mode capability beyond what the local PHY hardware itself supports, under direction of the application-layer PHY management software. Not taught or suggested.
Claim 10 recites receiving fault information comprising information associated with the external PHY device and identifying, from the fault information, a link segment of the link associated with the fault. While Khan teaches pinpointing an error to a component/module within a single PHY, neither reference teaches identifying which link segment (of a multi-segment end-to-end link that includes an external PHY device) is associated with a fault. This per-link-segment fault localization across an external-PHY-inclusive link is not taught or suggested by the art of record.
Applicant is advised that resolving the § 112(b) issues in claim 1 (and the corresponding antecedent-basis issues) is a prerequisite to allowance of any dependent claim in the chain.
Conclusion
All claims are rejected.
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
Langner et al., US11,632,295 B2 teach an Ethernet PHY device that receives a firmware image from a peer PHY over the link and boots/establishes communication accordingly. Pertinent to firmware-based configuration of external Ethernet PHY devices on a link (relevant to claims 1, 3, 8).
Brief et al., US 5,333,270 teach physical-layer controller with configuration registers loaded to configure the PHY without software intervention during a connection-management sequence. Pertinent to physical-layer configuration mechanisms and the contrast between register/hardware-driven and software-driven PHY configuration (relevant to claims 1, 2, 11).
Wong et al., US 8,996,928 B2 teach signaling of a physical-layer error over an interface between electronic devices, where the physical-layer error is not analyzable at higher layers. Pertinent to fault/status reporting for a physical link (relevant to claims 10, 16, 17).
Pfadler et al., US 12,507,083 B2, teach determining a physical-layer configuration for a link based on device state/attributes. Pertinent to the “determine configuration parameters… based on attributes” limitations (relevant to claims 15g, 18).
Linux kernel “PHY Abstraction Layer” documentation (docs.kernel.org/networking/phy.html): Non-patent literature describing a software abstraction layer that decouples PHY management from the network/MAC driver and provides a register/API interface for configuring PHY settings. Highly pertinent to the API-abstraction limitations of claims 1, 12, 13, 18.
Intel FPGA PAC N3000 “Ethernet Group and Retimer API” documentation: Non-patent literature describing an API for managing Ethernet MAC/PHY groups and retimers. Pertinent to claims 4, 8, 19, 20 (API-directed configuration of external retimer/PHY devices).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner Raymond Phan, whose telephone number is (571) 272-3630. The examiner can normally be reached on Monday-Friday from 6:30AM- 3:00PM. The Group Fax No. (571) 273-8300.
Communications via Internet e-mail regarding this application, other than those under 35 U.S.C. 132 or which otherwise require a signature, may be used by the applicant and should be addressed to [raymond.phan@uspto.gov].
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, Andrew Jung can be reached at (571) 270-3779. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
All Internet e-mail communications will be made of record in the application file. PTO employees do not engage in Internet communications where there exists a possibility that sensitive information could be identified or exchanged unless the record includes a properly signed express waiver of the confidentiality requirements of 35 U.S.C. 122. This is more clearly set forth in the Interim Internet Usage Policy published in the Official Gazette of the Patent and Trademark on February 25, 1997 at 1195 OG 89.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see hop://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 central telephone number is (571) 272-2100.
/RAYMOND N PHAN/
Primary Examiner, Art Unit 2175
Prosecution Insights