DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Claims 1-20 are presented for examination.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) is acknowledged.
Internet Communication Authorization
The examiner recommends filling a written authorization for internet communication in response to the present action. Doing so permits the USPTO to communicate with applicant using internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
Claims Objections
Claims 1, 9, 17 objected to because of the following informalities:
The Limitation “mapping the first multicast group to a second multicast group…by applying a mapping rule” is indefinite. The claim language never specifies what entity performs the mapping, where the mapping rule is stored, whether the mapping is deterministic, static or dynamic? Also its not clear whether multiple second multicast groups are possible for the same first group creating an ambiguity for an ordinary artisan.
The Limitation “encapsulating the multicast packet…..whose destination address is a multicast address of the second multicast group” is indefinite. The claim language does not clarify whether the encapsulation header carries multicast address or the encapsulated packet itself is modified or the destination address is inner vs. outer header. VXLAN systems have two destination addresses (overlay + underlay), it needs to distinguish between them. Appropriate corrections are required.
The Limitation “determining a third multicast group….for carrying multicast traffic to a multicast querier of a VLAN” is indefinite. The “multicast querier” is a role, not a destination, traffic is not carried to querier, and it’s not clear whether the third group is per VLAN, per querier or per-receiver set. Applicant need to clarify what topology this steps creates. Appropriate corrections are required.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-8, 11, 12, 13, 14, 15, 18, 19 and 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Regula (US pub, 2014/0237156 A1)
Referring to claim 1, Regula teaches a switch, comprising:
a plurality of physical ports (see¶ [076]-[079], downstream port, host port, fabric port):
a plurality of virtual switches including a plurality of virtual ports corresponding to the plurality of physical ports (see ¶ [077], “Virtual PCI-PCI bridges below each host port”, i.e. Regula explicitly teaches virtual PCI_PCI bridges synthesized per port and per host by management software),
a virtual switch of the plurality of virtual switches configured to provide a translated routing structure (TRS) corresponding to a local identifier of a source device coupled with a corresponding physical port (Regula [003],[040]-[042]; ID routing prefix, global ID space, i.e. ID routing prefixes added to packets that translate local identifier into global IDs for routing), the TRS being unique to the source device for the switch [041], “TRS” ~ “ID Routing Prefix/Global ID translation” performs TRS functionality); and
a switch fabric that interconnects the plurality of physical ports (see ¶ [078]-079] Regula explicitly describes a PCIe switch fabric interconnecting ports).
Referring to claim 2, Regula teaches the switch of claim 1, wherein the switch is a Compute Express Link (CXL) switch [249], “extended to other switch fabrics beyond PCIe”, i.e. CXL is a PCIe-derived fabric Regula expressly states applicability to any PCIe-like fabric).
Referring to claim 3, Regula teaches the switch of claim 1, wherein a management host is coupled to the switch, the management host intercepting initial communications of the source device and configuring the virtual port based on the initial communications (see ¶ [075], [077], management software intercepts redirected TLPs i.e. disclosing a mgmt CPU (MCPU) that intercepts and redirects traffic and configures routing).
Referring to Claim 4, Regula teaches the switch of claim 3, wherein the management host configuring the virtual switch includes mapping the local identifier of the source device to a location in the virtual switch indicated by a corresponding virtual port ([040], [042], lookup tables indexed by end point function, i.e. it maps endpoint functions to virtual bridges and global IDs via lookup tables).
Referring to claim 5, Regula teaches the switch of claim 3, wherein the management host determines a global address space for devices connected to the switch (see ¶ [081], “Global Space is defined…”.i.e. it explicitly defines and manages a Global Space)
Referring to claim 6, Regula teaches the switch of claim 3, wherein the virtual switch omits the TRS for a transaction between the source device and the management host (see ¶ [012], “If packet contains a destination ID routing proceeds without prefix”...therefore it teaches bypassing ID routing when packets already contain destination ID).
Referring to claim 7, Regula teaches the switch of claim 1, wherein the virtual switch provides a translation of a local address for a destination to a global address for the destination (see ¶ [003],[040]-[042], ID routing prefix[Wingdings font/0xE0] global ID translation of a local address to a global address).
Referring to claim 8, Regula teaches the system of claim 7, wherein the virtual switch associates a portion of a downstream device with a global address unique to the portion of the downstream device for the switch (see ¶ [042],[043],Regula Assigns Global ID’s per endpoint function / BAR).
Referring to claim 11, Regula teaches the switch of claim 7, wherein the switch routes a response from the destination based at least in part on the TRS ([036], “Completion routed back using ID routing”.
Referring to claim 12, Regula teaches the switch of claim 1, wherein a source device comprises a second switch (see ¶ [078] – [079], Regula discloses switch to switch fabric links).
Referring to claim 13, Regula teaches the switch of claim 1, wherein the TRS further comprises: an indicator of whether the TRS is in use in a transaction (see ¶ [012], [036], Regula discloses conditional insertion / removal of routing prefix).
Referring to claim 14, Regula teaches the switch of claim 1, wherein a portion of a packet is overwritten by the TRS (see ¶ [003], “adding the ID routing prefix to the packet”, i.e. it adds a routing prefix into packet header fields).
Referring to claim 15, Regula teaches the switch of claim 14, wherein the portion of the packet overwritten by the TRS is stored on the switch ([046], In the NIC mode, messages are received and stored into the memory of the receiving host).
Referring to claim 18, Regula teaches the switch of claim 1, wherein the plurality of physical ports includes a first downstream port and a second downstream port, the first downstream port being connected to a first device and the second downstream port being connected to a second device, wherein the first device can exchange peer-to-peer communications with the second device via the switch fabric (Regula [027], [078], supports host to host and end point to end point routing via fabric).
Referring to claim 19, Regula teaches a method, comprising:
receiving, at a virtual switch ([003], Packets (TLP) enter a switch fabric via ingress ports, which may be virtualized via virtual PCI-PCI bridges and managed per port),
a communication from a source device to a destination device (Fig. 1, teaches a communication from source to the destination devices),
the source device being coupled to a physical port corresponding to the virtual switch (see ¶ [077], each host port includes…multiple virtual PCI-PCI bridges below which endpoint functions assigned to the host appear), the physical port being one of a plurality of physical ports (¶ [076], “A downstream port is where an endpoint may be attached”, ingress/downstream port association with endpoint devices); and
providing, for the communication, a translated routing structure (TRS) corresponding to a local identifier of the source device (see ¶ [003], Regula expressly teaches adding an ID routing prefix to a packet by performing a table lookup, where the ID corresponds to the source or destination function see [003], converting the routing from address based routing to ID based routing by performing table lookup to define an ID routing prefix …and adding the ID routing prefix to the packet”),
the TRS being unique to the source device (see ¶ [016]-[020], lookup is performed …includes entry for each BAR of each endpoint function”, i.e. it shows end point functions (local identifiers) to global IDs using lookup table indexed by end point function and BARs—ID routing prefix = source devices local identifier function/BAR & see ¶ [041] “A global ID space is defined …in which each node and device function have a unique Global ID” -- Uniqueness of routing Identifier),
the TRS being usable in routing a response from the destination device to the source device (see ¶ [007], “routing the packet to a destination in the multipath switch based on the ID routing prefix”, i.e. routing responses completion using the same ID-based routing mechanism [036], removing the routing ID prefix at the destination fabric edge switch port)
Referring to claim 20, Regula teaches a method, comprising: intercepting, by a management host coupled with a switch, initial communications of a host device coupled with a physical port of a plurality of physical ports of the switch (see ¶ [075], Management CPU host that intercepts and processes redirected TLP communication “management application software running on an MCPU…processes redirected TLP from hosts and provides responses to them” & see ¶ [080], Fabric ports are hidden during MCPU enumeration, all are examples of early configuration-stage communication);
configuring a virtual switch corresponding to the physical port based on the initial communications (see ¶ [077], “additional bridges…are synthesized by the MCPU using CSR redirection”, i.e. virtual PCI_PCI bridges synthesized per port by management software), the configuring including:
determining a global identifier for the host device (see ¶ [041] “Each node and device function have a unique Global ID” [081] “the global space is defined as the virtual hierarchy of the management processor”); and
configuring the virtual switch to provide a translated routing structure (TRS) corresponding to a local identifier of the host device (see ¶ [003], [040], “define an ID routing prefix defining a destination ID….in a global space of the switch fabric”) the TRS being unique to the host device for the switch and based on the global identifier (see ¶ [016], TRS = ID routing prefix, based on the Global ID and configured by management software).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 9, 10 are rejected under 35 U.S.C. 103 as being unpatentable over Regula (US pub, 2014/0237156 A1) in view of Malwankar (US pub, 2009/0248947)
Referring to claim 9, Regula taches the system of claim 8, with features of virtual or logical switch, packet modification for routing purposes and bidirectional routing behavior in a switch fabric but expressly lacks a physical port of the plurality of physical ports is connected to a device comprising multiple logical devices.
However Malwankar teaches bidirectional packet handling symmetry. Furthermore, Malwankar teaches a physical port of the plurality of physical ports is connected to a device comprising multiple logical devices ([016], Fig.5, , Malwankar discloses multiple functions of an end point device shared independently).
It would have been obvious to an ordinary artisan at the time invention was made to modify the system of Regula to incorporate the response-side handling techniques of Malkanwar in order to improve bidirectional consistency that ensures that packets modified for routing purposes are properly handled when responses return which is known and expected requirement in packet switch systems.
Referring to claim 10, Malwankar teaches the system of claim 9, wherein the TRS further comprises: an identifier of a logical device of the multiple logical devices (see ¶ [021], wherein each individual function of an endpoint device may be accessed independently in a multi-root system using a proxy mechanism).
Claims 16, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Regula (US pub, 2014/0237156 A1) in view Parker (US 2005/0220094 A1)
Referring to claim 16, Regula teaches the switch of claim 15, that modifies packets at ingress by adding a routing structure (ID routing prefix) to packets entering fabric and the routing structure being used to control packet routing through the fabric but expressly lacks further comprises an address of the portion of the packet overwritten by the TRS (Parker see ¶ [181], [182], overwrite upto 64 bits or 32 bits, i.e. portion of the packet overwritten).
However, Parker teaches an address of the portion of the packet overwritten by the TRS (Parker see ¶ [181], [182], overwrite upto 64 bits or 32 bits, i.e. portion of the packet overwritten).
It would have been obvious to an ordinary artisan at the time invention was made to modify the system of Regula to incorporate Packet header modification in which portion of a packet header is overwritten or replaced during packet processing (e.g. address or identifier fields) of Parker in order to improve stateful packet processing when sufficient information is retained to enable reverse or complementary processing of response packets thereby facilitating correct restoration or reverse processing.
Referring to claim 17, The switch of claim 16, wherein the virtual switch receives a response to the packet, the response including the TRS, the virtual switch being configured to replace the TRS in the response with the portion of the packet stored on the switch (Parker see ¶ [185], [186], [188], Operation--replaces the MAC DA field in the packet with 6 byes of data taken from the data set).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Additional relevant prior art can be found in the included form PTO-892 (Notice of Cited References).
The examiner also requests, when responding to this office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line no(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application. Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111 (c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AFTAB N. KHAN whose telephone number is (571)270-5172. The examiner can normally be reached on Monday-Friday 8AM-5PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Glenton Burgess can be reached on 571-272-3949. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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 http://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). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AFTAB N. KHAN/
Primary Examiner, Art Unit 2454