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 .
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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 2, 5, 9, 11, 12, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Yu et al (US 2016/0149799 A1) in view of Kamachi et al (US 2015/0358180 A1).
Claim 20 (similarly Claims 1 and 11). Yu shows a computer system (figs. 2, 4 and 5), comprising: a processor (fig. 5: processor); a memory device (fig. 5: memory); a set of ports (fig. 5: Ethernet ports), wherein at least one port participates in a first network ([0031]: an Ethernet port whose type is the second type is an Ethernet port connected to another network device in an internal network); and a non-transitory machine-readable medium comprising instructions (fig. 5: CPU) executable by the processor to: learn a media access control (MAC) address of a packet received from a second network via a first ingress port in the set of ports ([0031]: an Ethernet port between a network device S7 and the network device S9 are the first type; [0074]: the network device S7 receives the loop detection frame using an Ethernet port connected to the network device S9 in the external network; [0073]: a source address of the first loop detection frame is a root MAC address of the first network device, that is, a same root MAC address of all network devices in the internal network), and wherein the MAC address is learned in association with an aggregate virtual local area network (VLAN) configured on the first network for traffic from the second network ([0073]: a source address of the first loop detection frame is a root MAC address of the first network device, that is, a same root MAC address of all network devices in the internal network).Yu does not expressly describe features of: inspecting the packet to determine an external VLAN configured on the second network; and sending, via the first ingress port, a loop detection packet on the external VLAN, wherein a source address and a detector address of the loop detection packet are both a local address of the computer system, and wherein a destination address of the loop detection packet is a multi-destination address; identify the local address as the detector address in an ingress packet received from a second ingress port in the set of ports coupling the second network, wherein the second ingress port is configured with the external VLAN; identifying a loop in the second network in association with the external VLAN; and disabling transmission via the second ingress port.Kamachi teaches features of: inspecting a packet to determine an external VLAN configured on a second network (fig. 1 and [0046]: when the network device 100 has subsequently received the loop detection frame via Port 1 (101) which is a transmission source port of the network device 100 which is the local device through other device 110 in the L2 network 120, it is determined as loop detection – “L2 network 120” is the “external VLAN”); and sending, via a first ingress port, a loop detection packet on the external VLAN ([0046]: it is assumed that the network device 100 has transmitted a loop detection frame from Port 1 (101)), wherein a source address and a detector address of the loop detection packet are both a local address of the computer system ([0058]: in the loop detection frame 30, a MAC address for identifying a network device of a transmission source of the loop detection frame 30, and domain identification information and VLAN identification information which respectively identify a domain and a VLAN with which the port of the transmission source are associated are to be included), and wherein a destination address of the loop detection packet is a multi-destination address ([0044]: ports indicated by Port 1 (101) to Port 6 (106) are associated with a Domain 1 domain and a port indicated by Port 7 (107) is associated with a Domain 2 domain… in Domain 1, Port 2 (102) and Port 3 (103) are associated with the same VLAN (VLAN ID=10) but Port 1 (101), Port 4 (104), Port 5 (105), and Port 6 (106) are associated with different VLANs (VLAN ID=5, 20, 30, 40 respectively) – different VLAN IDs); identify the local address as the detector address in an ingress packet received from a second ingress port in the set of ports coupling the second network ([0046]: when the network device 100 has subsequently received the loop detection frame via Port 1 (101) which is a transmission source port of the network device 100 which is the local device through other device 110 in the L2 network 120, it is determined as loop detection), wherein the second ingress port is configured with the external VLAN (fig. 1: port on other device 110); identifying a loop in the second network in association with the external VLAN ([0046]: when the network device 100 has subsequently received the loop detection frame via Port 1 (101) which is a transmission source port of the network device 100 which is the local device through other device 110 in the L2 network 120, it is determined as loop detection); and disabling transmission via the second ingress port ([0063]: the loop detection unit determines according to a user setting whether to perform blockage of the port which has received the loop occurrence notification and performs port blockage according to the setting wherein when the port blockage is performed, the loop detection unit performs a blockage notification to the MIB trap control unit).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the features as taught by Kamachi in the computer system of Yu to facilitate specifying a VLAN having a loop.
Claim 2 (similarly claim 12). Yu, modified by Kamachi, shows the method of claim 1, wherein disabling transmission via the second ingress port further comprises one of: turning off the second ingress port ([0075]: one of the second Ethernet port and the first Ethernet port is to be blocked… which one of these two Ethernet ports is blocked is determined by loop avoidance priorities of these two Ethernet ports wherein the Ethernet port with a lower loop avoidance priority is blocked); and disabling the external VLAN at the second ingress port ([0079]: an Ethernet port connected to the external network is blocked according to a loop avoidance priority, to avoid change of a topology of the internal network).
Claim 5 (similarly claim 15). Yu, modified by Kamachi, shows the method of claim 1, wherein the local address includes a MAC address allocated to the switch ([0085]: the network device has a MAC address specially used for detecting a loop, referred to as a root MAC address); and wherein the multi-destination address is a multicast address or a broadcast address ([0097]: a value of an EtherType field of a loop detection frame is a special value, and the special value is used to indicate that a broadcast frame or a multicast frame whose value of an EtherType field is the special value is a loop detection frame).
Claim 9. Yu, modified by Kamachi, shows the method of claim 1, further comprising determining the ingress packet as a loop detection packet based on one or more header fields of the ingress packet ([0037]: a value of an EtherType field of a loop detection frame is a special value, and the special value is used to indicate that a broadcast frame or a multicast frame whose value of an EtherType field is the special value is a loop detection frame).
---------- ---------- ----------
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Yu et al in view of Kamachi et al, applied to claims 1 and 11, and in further view of Abdulnour et al (US 2016/0323163 A1).
Claim 3 (similarly claim 13). Yu, modified by Kamachi, shows the method of claim 1; Yu, modified by Kamachi, does not expressly describe the method further comprising selecting one or more packets for inspection based on one or more of: sampling packets belonging to the aggregate VLAN; and mirroring packets belonging to the aggregate VLAN to a processor of the switch.Abdulnour teaches feature of selecting packet for inspection based on sampling packets belonging to an aggregate VLAN ([0044]: the connectivity of each CPE device in each of the samples is monitored and variations in aggregated S-VLAN connectivity from model connectivity levels are interpreted using one or more predetermined rules to decide whether a fault condition is indicated for any S-VLAN).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the packet sampling feature as taught by Abdulnour in the packet inspection selection process of Yu, modified by Kamachi, to facilitate finding particular application in fault detection and diagnosis for Internet Protocol (IP) and Ethernet Protocol networks but it may be arranged to operate in respect of other types of network.
---------- ---------- ----------
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Yu et al in view of Kamachi et al, applied to claims 1 and 11, and in further view of Addanki et al (US 2015/0333967 A1).
Claim 6 (similarly claim 16). Yu, modified by Kamachi, shows the method of claim 1; Yu, modified by Kamachi, does not expressly describe further comprising sending, by the switch via the first network, the packet to a remote site of the second network over the aggregate VLAN.Addanki teaches feature of sending, by a switch of a first network, a packet to a remote site of a second network over an aggregate VLAN ([0019]: the switch is an aggregate switch for one or more aggregate switches in remote networks of interconnected switches wherein the first global VLAN identifier is then an aggregate global VLAN identifier and the aggregate global VLAN identifier corresponds to a plurality of aggregate VLANs of the remote networks).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the feature as taught by Addanki in the VLAN structure of Yu, modified by Kamachi, to efficiently facilitate virtualized networks across multiple networks.
---------- ---------- ----------
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Yu et al in view of Kamachi et al, applied to claims 1 and 11, and in further view of Matsubara et al (US 2012/0020357 A1).
Claim 7 (similarly claim 17). Yu, modified by Kamachi, shows the method of claim 1; Yu, modified by Kamachi, does not expressly describe wherein the first and second ingress ports are configured with Provider Bridging, and wherein the aggregate VLAN is a service VLAN (S-VLAN) configured based on the Provider Bridging.Matsubara teaches ingress ports being configured with Provider Bridging ([0004] and [0061]: Provider Bridging… Ingress Customer Premises Equipment), and wherein an aggregate VLAN is a service VLAN (S-VLAN) configured based on the Provider Bridging (fig. 6 and [0058]: stored in each of the pre-conversion identifier 704 and post-conversion identifier 705 is one or a plurality of pieces of information indicative of types such as, for example, C-TAG (Customer VLAN Tag), user VLAN tag), S-TAG (Service VLAN Tag)).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the provider bridging and S-VLAN features as taught by Matsubara in the ingress ports of Yu, modified by Kamachi, to realize a high reliability, that a route/resource is separated for individual different services to realize virtuality and that a traffic load is dispersed and optimized by traffic engineering.
---------- ---------- ----------
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Yu et al in view of Kamachi et al, applied to claims 1 and 11, and in further view of Lu et al (US 2018/0288602 A1).
Claim 8 (similarly claim 18). Yu, modified by Kamachi, shows the method of claim 1; Yu, modified by Kamachi, does not expressly describe wherein a respective external VLAN of the second network is mapped to the aggregate VLAN in the first network.Lu teaches feature of a respective external VLAN of a second network is mapped to an aggregate VLAN in a first network ([0020]: upon receipt of the packets, the aggregation switch maps the packets to different ports of the PRP switch based on their external VLAN tags and removes the external VLAN tags from the packets).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the mapping feature as taught by Lu in the first and second networks of Yu, modified by Kamachi, to facilitate roaming in a high-speed movement applications.
---------- ---------- ----------
Claims 10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Yu et al in view of Kamachi et al, applied to claims 1 and 11, and in further view of Kuo et al (US 2009/0274153 A1).
Claim 10 (similarly claim 19). Yu, modified by Kamachi, shows the method of claim 1; Yu, modified by Kamachi, does not expressly describe wherein the first network is a provider network and the second network is a customer network.Kuo teaches a method for providing an independent loop free Layer 2 convergence for an interconnected external network and a customer network wherein the external network may be any network that is external to the customer network, including but not limited to a service provider network that provides wide area connectivity to the customer network ([0012]).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement a provider network side and a customer network side as taught by Kuo in the loop detection system/method of Yu, modified by Kamachi, to provide redundancy and eliminate loops in disparate interconnected networks each implementing one or more independent instances of a layer 2 redundancy protocol or protocols.
========== ========== ==========
Allowable Subject Matter
Claims 4 and 14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
---------- ---------- ----------
Conclusion
The prior art made of record is considered pertinent to applicant’s disclosure.
1. Iovanna et al, US 2009/0022070 A1: a method for determining required routes through an Ether based network associated with VLANs by determining a set of spanning trees.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Xavier Szewai Wong whose telephone number is 571.270.1780. The examiner can normally be reached on 11:30 am - 8:30 pm Mon to Fri.
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, Jeffrey Rutkowski can be reached on 571.270.1215. 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.
/XAVIER S WONG/Primary Examiner, Art Unit 2415 20th October 2025