EXHIBIT B-1
`Defendant’s Preliminary Invalidity Contentions
`Orckit Corporation v. Cisco Systems, Inc., 2:22-cv-00276-JRG-RSP
`____________________________________________________________________________________________________________
`
`Chart for U.S. Patent 8,830,821 (“the ’821 Patent”)
`Cisco IOS Multiprotocol Label Switching
`Cisco IOS Release 12.2SR (“Cisco IOS System”)
`
`As shown in the chart below, all claims of the ’821 Patent are invalid (1) under 35 U.S.C. §§ 102 (a) and (g) based on Cisco IOS
`System, (2) under 35 U.S.C. §§ 102 (a) and (b) because the references describing the Cisco IOS System disclose every limitation of
`every Asserted Claim, and (3) under 35 U.S.C. § 103 as obvious based on Cisco IOS Multiprotocol Label Switching Configuration
`Guide Release 12.2SR alone, or in combination with the knowledge of a person of ordinary skill in the art alone, and in further
`combination with references specifically identified in the following claim chart and/or one or more other references identified in
`Cisco’s Preliminary Invalidity Contentions. The Cisco IOS System comprises the Cisco IOS Release 12.2SR operating system, as it
`ran on various Cisco switches and routers from before June 22, 2011. The Cisco IOS System was invented, known and used by others
`in the United States, and on sale in the United States before the claimed invention, rendering the claims invalid. Publications
`describing the Cisco IOS System, including those cited in this chart, were publicly disclosed and available more than a year before the
`purported filing date of the provisional application identified on the face of the ’821 Patent, rendering the claims invalid. For
`example, Cisco IOS Multiprotocol Label Switching Configuration Guide Release 12.2SR was published in 2010 and discloses all
`elements of the Asserted Claims, thereby anticipating the Asserted Claims. Moreover, as identified in this chart, it would have been
`obvious to combine the disclosures in the publications regarding the Cisco IOS System with each other and with disclosures in other
`publications known in the art, as explained in this chart, well before the claimed invention and the effective filing date of the ’821
`Patent, rendering the claims invalid.
`
`The quotations and diagrams regarding the Cisco IOS System in this chart come from the following sources:
` Cisco IOS Multiprotocol Label Switching Configuration Guide Release 12.2SR (“Cisco IOS Guide”); and
` Cisco Press Release titled “Cisco Systems’ MPLS-TE ‘Fast Reroute’” Function Introduced To NTT Communications’ Arcstart
`IP-VPN” (“Cisco Press Release”); and
` Open-Shortest Path First (OSPF) Protocol, Defined in RFC 2328, https://www.ietf.org/rfc/rfc2328.txt (“RFC 2328”).
`
`Motivations to combine the disclosures in these references with disclosures in other publications known in the art, as explained in this
`chart, include at least the similarity in subject matter between the references to the extent they concern methods of selecting paths in a
`
`1
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 1 of 698
`
`

`

`network and/or determining the cost of potential paths in a network. Insofar as the references cite other patents or publications, or
`suggest additional changes, one of ordinary skill in the art would look beyond a single reference to other references in the field.
`
`These invalidity contentions are based on Defendant’s present understanding of the Asserted Claims, and Orckit’s apparent construction
`of the claims in its November 3, 2022 Disclosure of Asserted Claims and Infringement Contentions Pursuant to P.R. 3-1, and Orckit’s
`January 19, 2023 First Amended Disclosure of Asserted Claims and Infringement Contentions Pursuant to P.R. 3-1 (Orckit’s
`“Infringement Disclosures”), which is deficient at least insofar as it fails to cite any documents or identify accused structures, acts, or
`materials in the Accused Products with particularity. Defendant does not agree with Orckit’s application of the claims, or that the claims
`satisfy the requirements of 35 U.S.C. § 112. Defendant’s contentions herein are not, and should in no way be seen as, admissions or
`adoptions as to any particular claim scope or construction, or as any admission that any particular element is met by any accused product
`in any particular way. Defendant objects to any attempt to imply claim construction from this chart. Defendant’s prior art invalidity
`contentions are made in a variety of alternatives and do not represent Defendant’s agreement or view as to the meaning, definiteness,
`written description support for, or enablement of any claim contained therein.
`
`The following contentions are subject to revision and amendment pursuant to Federal Rule of Civil Procedure 26(e), the Local Rules,
`and the Orders of record in this matter subject to further investigation and discovery regarding the prior art and the Court’s construction
`of the claims at issue.
`
`ʼ821 Patent Claim 1
`No.
`1[preamble] An entity selection
`method performed by a
`network device,
`comprising the steps of:
`
`Cisco IOS System
`Cisco IOS System discloses an entity selection method performed by a network device,
`comprising the steps of.
`
`For example, Cisco IOS Guide discloses a cisco router supporting Cisco IOS Release 12.2SR
`which supports MPLS traffic engineering. Cisco IOS Guide further discloses that a Cisco
`router can act as the headend router of a TE tunnel, by controlling the path its traffic takes to
`a particular destination.
`
`Cisco IOS Guide at Page No. 15 (“[Cisco IOS documentation describes the tasks and
`commands available to configure and maintain Cisco networking devices.]”)
`
`Cisco IOS Guide at Page No. 15 (“[The Cisco IOS documentation set is intended for users
`who configure and maintain Cisco networking devices (such as routers and switches) but who
`may not be familiar with the configuration and maintenance tasks, the relationship among
`
`2
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 2 of 698
`
`

`

`No.
`
`ʼ821 Patent Claim 1
`
`1[a]
`
`providing a plurality of
`multi protocol label
`switching (MPLS)
`transport entities
`
`Cisco IOS System
`tasks, or the Cisco IOS commands necessary to perform particular tasks. The Cisco IOS
`documentation set is also intended for those users experienced with Cisco IOS software who
`need to know about new features, new configuration options, and new software characteristics
`in the current Cisco IOS release.]”)
`
`Cisco IOS Guide at Page No. 15 (“[In Cisco IOS documentation, the term router may be used
`to refer to various Cisco products; for example, routers, access servers, and switches.]”)
`
`Cisco IOS Guide at Page No. 603 (“[Traffic Engineering Tunnels
`MPLS TE lets you build label switched paths (LSPs) across your network for forwarding
`traffic.
`MPLS TE LSPs let the headend of a TE tunnel control the path its traffic takes to a particular
`destination.
`This method is more flexible than forwarding traffic based only on a destination address.
`Interarea tunnels allow you to do the following:
`• Build TE tunnels between areas (interarea tunnels)
`• Build TE tunnels that start and end in the same area, on multiple areas on a router (intra-
`area tunnels)
`Some tunnels are more important than others. For example, you may have tunnels carrying
`VoIP traffic and tunnels carrying data traffic that are competing for the same resources. MPLS
`TE allows you to have some tunnels preempt others. Each tunnel has a priority, and more-
`important tunnels take precedence over less-important tunnels.]”)
`
`Cisco IOS Guide at Page No. 633 (“[router—A network layer device that uses one or more
`metrics to determine the optimal path along which network traffic should be forwarded.
`Routers forward packets from one network to another based on network layer information.]”)
`
`Cisco IOS System discloses providing a plurality of multi protocol label switching (MPLS)
`transport entities between a first endpoint and a second endpoint.
`
`For example, Cisco IOS Guide discloses that Cisco IOS Release 12.2SR supports MPLS
`traffic engineering tunnels with enhanced path protection, including by providing support of
`
`3
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 3 of 698
`
`

`

`No.
`
`ʼ821 Patent Claim 1
`between a first endpoint
`and a second endpoint;
`
`Cisco IOS System
`multiple backup path options (up to eight backup paths) per primary path option terminating
`at the same destination.
`
`Cisco IOS Guide at Page No. 601 (“[The MPLS Traffic Engineering (TE): Path Protection
`feature provides an end-to-end failure recovery mechanism (that is, full path protection) for
`Multiprotocol Label Switching (MPLS) traffic engineering (TE) tunnels.
`Note Cisco IOS Release 12.3(33)SRE and later releases support enhanced path protection,
`which is the ability to configure up to eight secondary path options for a given primary path
`option.]”)
`
`Cisco IOS Guide at Page No. 603 (“[Enhanced Path Protection
`Enhanced path protection provides support of multiple backup path options per primary path
`option. You can configure up to eight backup path options for a given primary path option.
`Only one of the configured backup path options is actively signaled at any time.
`After you enter the mpls traffic-eng path-option list command, you can enter the backup path
`priority in the number argument of the path-option command. A lower identifier represents a
`higher priority. Priorities are configurable for each backup path option. Multiple backup path
`options and a single backup path option cannot coexist to protect a primary path option.]”)
`
`Cisco IOS Guide at Page No. 623 (“[Configuration Examples for MPLS Traffic Engineering
`(TE): Enhanced Path Protection]”)
`
`
`
`4
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 4 of 698
`
`

`

`No.
`
`ʼ821 Patent Claim 1
`
`Cisco IOS System
`
`
`
`Fig. 6 (annotation added)
`
`Cisco IOS Guide at Page No. 640 (“[Backup Tunnel Support
`Backup tunnel support has the following capabilities:
`• Backup Tunnels Can Terminate at the Next-Next Hop to Support FRR, page 6
`• Multiple Backup Tunnels Can Protect the Same Interface, page 6
`• Backup Tunnels Provide Scalability, page 7
`Backup Tunnels Can Terminate at the Next-Next Hop to Support FRR Backup tunnels that
`terminate at the next-next hop protect both the downstream link and node. This provides
`protection for link and node failures. For more detailed information, see the “Node
`Protection” section on page 4.
`Multiple Backup Tunnels Can Protect the Same Interface
`There is no limit (except memory limitations) to the number of backup tunnels that can protect
`a given interface. In many topologies, support for node protection requires supporting
`multiple backup tunnels per protected interface. These backup tunnels can terminate at the
`same destination or at different destinations. That is, for a given protected interface, you can
`
`5
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 5 of 698
`
`

`

`No.
`
`ʼ821 Patent Claim 1
`
`Cisco IOS System
`configure multiple NHOP or NNHOP backup tunnels. This allows redundancy and load
`balancing.]”)
`
`Cisco IOS Guide at Page No. 643 (“[Backup Tunnels Terminating at the Same Destination
`Figure 4 shows how backup tunnels terminating at the same location can be used for
`redundancy and load balancing. Redundancy and load balancing work for both NHOP and
`NNHOP backup tunnels.]”)
`
`
`
`
`
`Fig. 4 (annotation added)
`
`Cisco IOS Guide at Page No. 644 (“[In this illustration, there are three routers: R1, R2, and
`R3. At R1 two NNHOP backup tunnels (T1 and T2) go from R1 to R3 without traversing R2.
`Redundancy—If R2 fails or the link from R1 to R2 fails, either backup tunnel can be used. If
`one backup tunnel is down, the other can be used. LSPs are assigned to backup tunnels when
`the LSPs are first established. This is done before a failure.
`Load balancing—If neither backup tunnel has enough bandwidth to back up all LSPs, both
`tunnels can be used. Some LSPs will use one backup tunnel, other LSPs will use the other
`backup tunnel. The router decides the best way to fit the LSPs onto the backup tunnels.]”)
`
`
`6
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 6 of 698
`
`

`

`No.
`1[b]
`
`ʼ821 Patent Claim 1
`determining an overall
`cost for each entity pair
`of said plurality of
`entities;
`
`Cisco IOS System
`Cisco IOS System discloses determining an overall cost for each entity pair of said plurality
`of entities.
`
`For example, Cisco IOS Guide discloses that the path an LSP uses is determined by the LSP
`resource requirements and network resources, such as bandwidth. Cisco IOS Guide further
`discloses the MPLS TE SRLG feature that enhances backup tunnel path selection so a backup
`tunnel can avoid using links that are in the same SRLG as the interfaces it is protecting. Thus,
`at least under the apparent claim scope alleged by Orckit’s Infringement Disclosures, this
`limitation is met. To the extent that the Cisco IOS System is found to not meet this limitation,
`determining an overall cost for each entity pair of said plurality of entities would have been
`obvious to a person having ordinary skill in the art, as explained below.
`
`Cisco IOS Guide at Page No. 253 (“[Path Option Selection for MPLS TE Tunnel LSPs
`This section contains the following topics about path option selection for MPLS TE Tunnel
`LSPs:
`• Constraint-Based Routing and Path Option Selection, page 5
`• Tunnel Reoptimization and Path Option Selection, page 5
`• Path Option Selection with Bandwidth Override, page 6
`Constraint-Based Routing and Path Option Selection
`MPLS traffic engineering automatically establishes and maintains LSPs across the backbone
`by using the Resource Reservation Protocol (RSVP). The path that an LSP uses is determined
`by the LSP resource requirements and network resources, such as bandwidth. Traffic
`engineering tunnels are calculated at the LSP head based on a fit between required and
`available resources (constraint-based routing).
`Without the Path Option for Bandwidth Override feature, a TE tunnel establishes an LSP
`based on dynamic or explicit path options in order of preference. However, the bandwidth
`and other attributes configured on the TE tunnel allow the setup of an LSP only if LSP path
`options satisfy the constraints. If a path cannot be found that satisfies the configured path
`options, then the tunnel is not set up.]”)
`
`Cisco IOS Guide at Page No. 639 (“[Bandwidth Protection
`
`7
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 7 of 698
`
`

`

`No.
`
`ʼ821 Patent Claim 1
`
`Cisco IOS System
`NHOP and NNHOP backup tunnels can be used to provide bandwidth protection for rerouted
`LSPs. This is referred to as backup bandwidth. You can associate backup bandwidth with
`NHOP or NNHOP backup tunnels. This informs the router of the amount of backup
`bandwidth a particular backup tunnel can protect. When a router maps LSPs to backup
`tunnels, bandwidth protection ensures that an LSP uses a given backup tunnel only if there is
`sufficient backup bandwidth. The router selects which LSPs use which backup tunnels in
`order to provide maximum bandwidth protection. That is, the router determines the best way
`to map LSPs onto backup tunnels in order to maximize the number of LSPs that can be
`protected. For information about mapping tunnels and assigning backup bandwidth, see the
`“Backup Tunnel Selection Procedure” section on page 10.
`LSPs that have the “bandwidth protection desired” bit set have a higher right to select backup
`tunnels that provide bandwidth protection; that is, those LSPs can preempt other LSPs that do
`not have that bit set. For more information, see the “Prioritizing Which LSPs Obtain Backup
`Tunnels with Bandwidth Protection” section on page 8.]”)
`
`Cisco IOS Guide at Page No. 640 (“[Backup Tunnel Support
`Backup tunnel support has the following capabilities:
`• Backup Tunnels Can Terminate at the Next-Next Hop to Support FRR, page 6
`• Multiple Backup Tunnels Can Protect the Same Interface, page 6
`• Backup Tunnels Provide Scalability, page 7.]”)
`Cisco IOS Guide at Page 640
`(“[Multiple Backup Tunnels Can Protect the Same Interface
`There is no limit (except memory limitations) to the number of backup tunnels that can protect
`a given interface. In many topologies, support for node protection requires supporting
`multiple backup tunnels per protected interface. These backup tunnels can terminate at the
`same destination or at different destinations. That is, for a given protected interface, you can
`configure multiple NHOP or NNHOP backup tunnels. This allows redundancy and load
`balancing.]”)
`
`Cisco IOS Guide at Page No. 603 (“[Traffic Engineering Tunnels
`MPLS TE lets you build label switched paths (LSPs) across your network for forwarding
`traffic.
`
`8
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 8 of 698
`
`

`

`No.
`
`ʼ821 Patent Claim 1
`
`Cisco IOS System
`MPLS TE LSPs let the headend of a TE tunnel control the path its traffic takes to a particular
`destination.
`This method is more flexible than forwarding traffic based only on a destination address.
`Interarea tunnels allow you to do the following:
`• Build TE tunnels between areas (interarea tunnels)
`• Build TE tunnels that start and end in the same area, on multiple areas on a router (intra-
`area tunnels)
`Some tunnels are more important than others. For example, you may have tunnels carrying
`VoIP traffic and tunnels carrying data traffic that are competing for the same resources. MPLS
`TE allows you to have some tunnels preempt others. Each tunnel has a priority, and more-
`important tunnels take precedence over less-important tunnels.]”)
`
`Cisco IOS Guide at Page No. 641 (“[Backup Bandwidth Protection
`Backup bandwidth protection allows you to give LSPs carrying certain kinds of data (such as
`voice) priority for using backup tunnels.]”)
`
`Cisco IOS Guide at Page No. 650 (“[For each protected link AB with a maximum reservable
`subpool value of n, there may be a path from node A to node B such that the difference
`between the maximum reservable global and the maximum reservable subpool is at least the
`value of n. If it is possible to find such paths for each link in the network, you can establish
`all the backup tunnels along such paths without any bandwidth reservations. If there is a single
`link failure, only one backup tunnel will use any link on its path. Because that path has at least
`n available bandwidth (in the global pool), assuming that marking and scheduling is
`configured to classify the subpool traffic into a priority queue, the subpool bandwidth is
`guaranteed.
`This approach allows sharing of the global pool bandwidth between backup tunnels protecting
`independent link failures. The backup tunnels are expected to be used for only a short period
`of time after a failure (until the headends of affected LSPs reroute those LSPs to other paths
`with available subpool bandwidth). The probability of multiple unrelated link failures is very
`small (in the absence of node or shared risk link group (SRLG) failures, which result in
`multiple link failures). Therefore, it is reasonable to assume that link failures are in practice
`independent with high probability. This “independent failure assumption” in combination
`
`9
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 9 of 698
`
`

`

`No.
`
`ʼ821 Patent Claim 1
`
`Cisco IOS System
`with backup tunnels signaled without explicit bandwidth reservation enables efficient
`bandwidth sharing that yields substantial bandwidth savings.]”)
`
`Cisco IOS Guide at Page No. 651 (“[A similar approach can be used for node and SRLG
`protection. However, the decision of where to put the backup tunnels is more complicated
`because both node and SRLG failures effectively result in the simultaneous failure of several
`links. Therefore, the backup tunnels protecting traffic traversing all affected links cannot be
`computed independently of each other.]”)
`
`Cisco IOS Guide at Page No. 579 (“[MPLS Traffic Engineering Shared Risk Link Groups
`SRLGs refer to situations where links in a network share a common fiber (or a common
`physical attribute). If one link fails, other links in the group may fail too. Links in the group
`have a shared risk. Backup tunnels should avoid using links in the same SRLG as interfaces
`they are protecting. Otherwise, when the protected link fails the backup tunnel fails too.
`
`Fig. 1 (annotation added)
`
`Figure 1 shows a primary label-switched path (LSP) from router R1 to router R5. The LSP
`protects against the failure of the R2-R3 link at R2 via a backup tunnel to R4. If the R2-R3
`link fails, link protection reroutes the LSP along the backup tunnel. However, the R2-R3 link
`and one of the backup tunnel links are in the same SRLG. So if the R2-R3 link fails, the
`backup tunnel may fail too.
`
`
`
`10
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 10 of 698
`
`

`

`No.
`
`ʼ821 Patent Claim 1
`
`Cisco IOS System
`The MPLS TE SRLG feature enhances backup tunnel path selection so a backup tunnel can
`avoid using links that are in the same SRLG as the interfaces it is protecting.
`There are two ways for a backup tunnel to avoid the SRLGs of its protected interface:
`• The router does not create the backup tunnel unless it avoids SRLGs of the protected
`interface.]”)
`
`Cisco IOS Guide at Page No. 580 (“[Open Shortest Path First (OSPF) and Intermediate
`System-to-Intermediate System (IS-IS) flood the SRLG membership information (including
`other TE link attributes such as bandwidth availability and affinity) so that all routers in the
`network have the SRLG information for each link. With this topology information, routers
`can compute backup tunnel paths that exclude links having SRLGs in common with their
`protected interfaces. As shown in Figure 2, the backup tunnel avoids the link between R2 and
`R3, which shares an SRLG with the protected interface.]”)
`
`
`Fig. 2 (annotation added)
`
`Cisco IOS Guide at Page No. 587 (“[Step 4 show mpls traffic-eng topology
`Use this command to show the SRLG link membership flooded via the Interior Gateway
`Protocol (IGP).]”)
`Cisco IOS Guide at Page 632
`
`
`
`11
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 11 of 698
`
`

`

`No.
`
`ʼ821 Patent Claim 1
`
`Cisco IOS System
`(“[IS-IS—Intermediate System-to-Intermediate System. Link-state hierarchical routing
`protocol that calls for intermediate system (IS) routers to exchange routing information based
`on a single metric to determine network topology.]”)
`
`Cisco IOS Guide at Page No. 633 (“[OSPF—Open Shortest Path First. A link-state
`hierarchical Interior Gateway Protocol routing algorithm, derived from the IS-IS protocol.
`OSPF features include least-cost routing, multipath routing, and load balancing.]”)
`
`Cisco IOS Guide at Page No. 581 (“[Autotunnel Backup for MPLS TE SRLGs
`Autotunnel backup is the ability of routers to create backup tunnels automatically. Therefore,
`you do not need to preconfigure each backup tunnel and then assign the backup tunnel to the
`protected interface. Only automatically created backup tunnels can avoid SRLGs or their
`protected interfaces.]”)
`
`Cisco IOS Guide at Page No. 583 (“[Configuring the Routers That Automatically Create
`Backup Tunnels to Avoid MPLS TE SRLGs of Their Protected Interfaces
`Perform the following task to configure routers that automatically create backup tunnels to
`avoid MPLS TE SRLGs of their protected interfaces. Backup tunnels provide link protection
`by rerouting traffic to the next hop bypassing failed links or in this instance by avoiding
`SRLGs.]”)
`
`Cisco IOS Guide at Page No. 644 (“[Backup Tunnel Selection Procedure
`When an LSP is signaled, each node along the LSP path that provides FRR protection for the
`LSP selects a backup tunnel for the LSP to use if either of the following events occurs:
`• The link to the next hop fails.
`• The next hop fails.
`By having the node select the backup tunnel for an LSP before a failure occurs, the LSP can
`be rerouted onto the backup tunnel quickly if there is a failure.]”)
`Cisco IOS Guide at Page 646
`(“[NHOP Versus NNHOP Backup Tunnels
`More than one backup tunnel can protect a given LSP, where one backup tunnel terminates
`at the LSP’s NNHOP, and the other terminates at the LSP’s NHOP. In this case, the router
`
`12
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 12 of 698
`
`

`

`No.
`
`ʼ821 Patent Claim 1
`
`Cisco IOS System
`chooses the backup tunnel that terminates at the NNHOP (that is, FRR prefers NNHOP over
`NHOP backup tunnels).Table 1 lists the tunnel selection priorities. The first choice is an
`NNHOP backup tunnel that acquires its bandwidth from a subpool or global pool, and has
`limited bandwidth. If there is no such backup tunnel, the next choice (2) is a next-next hop
`backup tunnel that acquires a limited amount of bandwidth from any pool. The preferences
`go from 1 (best) to 8 (worst), where choice 3 is for an NNHOP backup tunnel with an
`unlimited amount of subpool or global-pool bandwidth.]”)
`
`Cisco IOS Guide at Page No. 647-648 (“[Figure 7 shows an example of the backup tunnel
`selection procedure based on the designated amount of global pool and subpool bandwidth
`currently available.
`
`13
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 13 of 698
`
`

`

`No.
`
`ʼ821 Patent Claim 1
`
`Cisco IOS System
`
`In this example, an LSP requires 20 units (kilobits per second) of sub-pool backup bandwidth.
`The best backup tunnel is selected as follows:
`1. Backup tunnels T1 through T4 are considered first because they terminate at the NNHOP.
`2. Tunnel T4 is eliminated because it has only ten units of sub-pool backup bandwidth.
`3. Tunnel T1 is eliminated because it protects only LSPs using global-pool bandwidth.
`4. Tunnel T3 is chosen over T2 because, although both have sufficient backup bandwidth, T3
`has the least backup bandwidth available (leaving the most backup bandwidth available on
`T2).
`5. Tunnels T5 and T6 need not be considered because they terminate at an NHOP, and
`therefore are less desirable than T3, which terminates at an NNHOP.]”)
`
`In addition, at least under the apparent claim scope alleged by Orckit’s Infringement
`Disclosures, Cisco IOS System in combination with (1) the knowledge of a person of ordinary
`skill in the art, alone or in further combination with (2) each (individually, as well as one or more
`together) of the references identified in element 1[b] of Exhibit E-2 renders the claim, including
`the present limitation, obvious. Below are examples of two such references.
`
`For example, Juniper IOS Guide discloses that through fate sharing, you can configure one
`or more backup paths that minimize the number of shared links with the primary paths.
`Juniper IOS Guide further discloses that fate sharing ensures that a single point of failure will
`
`14
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 14 of 698
`
`

`

`No.
`
`ʼ821 Patent Claim 1
`
`Cisco IOS System
`not affect the primary and backup paths simultaneously. At least based upon Orckit’s
`apparent understanding of this term as reflected in its Infringement Disclosures, this limitation
`is met.
`
`Juniper IOS Guide at Page No. 73 (“[Through fate sharing, you can configure backup paths
`that minimize the number of shared links and fiber paths with the primary paths as much as
`possible, to ensure that if a fiber is cut, the minimum amount of data is lost and a path still
`exists to the destination.
`For a backup path to work optimally, it must not share links or physical fiber paths with the
`primary path, ensuring that a single point of failure will not affect the primary and backup
`paths simultaneously. For more information about fate sharing, see the Junos OS Routing
`Protocols Configuration Guide.]”)
`
`Juniper IOS Guide at Page No. 97 (“[Fate-sharing groups contain three types of objects:
`• Point-to-point links—Identified by the IP addresses at each end of the link. Unnumbered
`point-to-point links are typically identified by borrowing IP addresses from other interfaces.
`Order is not important; from 1.2.3.4 to 1.2.3.5 and from 1.2.3.5 to 1.2.3.4 have the same
`meaning.
`• Non-point-to-point links—Include links on a LAN interface (such as Gigabit Ethernet
`interfaces) or nonbroadcast multiaccess (NBMA) interfaces (such as Asynchronous Transfer
`Mode [ATM] or Frame Relay). You identify these links by their individual interface address.
`For example, if the LAN interface 192.168.200.0/24 has four routers attached to it, each router
`link is individually identified:
`from 192.168.200.1; # LAN interface of router 1
`from 192.168.200.2; # LAN interface of router 2
`from 192.168.200.3; # LAN interface of router 3
`from 192.168.200.4; # LAN interface of router 4
`You can list the addresses in any order.
`• A router node—Identified by its configured router ID.
`An object can be in any number of groups, and a group can contain any number of objects.
`Each group has a configurable cost attributed to it, which represents the level of impact this
`group has on CSPF computations. The higher the cost, the less likely a backup path will share
`
`15
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 15 of 698
`
`

`

`No.
`
`ʼ821 Patent Claim 1
`
`Cisco IOS System
`with the primary path any objects in the group. The cost is directly comparable to traffic
`engineering metrics. By default, the cost is 1. Changing the fate-sharing database does not
`affect established LSPs until the next reoptimization of CSPF. The fate-sharing database does
`influence fast-reroute computations.]”)
`
`For example, RFC 4872 discloses that the plurality of MPLS LSPs, i.e., transport entities, are
`selected in pairs of either working and protection LSPs, or working and restoration LSPs.
`RFC 4872 further discloses that the plurality of MPLS LSPs, i.e., transport entities, are
`selected to necessarily be “resource disjoint,” i.e., where multiple resources, such as links,
`nodes, or Shared Risk Link Groups (SRLGs) do not share common links or failure
`probabilities. Thus, at least under the apparent claim scope alleged by Orckit’s Infringement
`Disclosures, this limitation is met. To the extent that the IETF MPLS-TP System is found to
`not meet this limitation, if said subset comprises at least two entity pairs, selecting an entity
`pair from said subset that minimizes an entity cost function would have been obvious to a
`person having ordinary skill in the art, as explained below.
`
`“When a failure is detected by one or both endpoints of the LSP, both endpoints must select
`traffic from the other LSP. This action must be coordinated between node A and D. From this
`perspective, 1+1 bidirectional protection can be seen as a coordinated protection- switching
`mechanism between both endpoints.
`
`Note: it is necessary that both paths are SRLG disjoint to ensure recoverability; otherwise, a
`single failure may impact both working and protecting LSPs.” RFC 4872 at 11.
`
`“1:1 Protection with Extra-Traffic
`The most common case of end-to-end 1:N protection is to establish, between the same
`endpoints, an end-to-end working LSP (thus, N = 1) and a dedicated end-to-end protecting
`LSP that are mutually link/ node/SRLG disjoint. This protects against working LSP
`failure(s).” RFC 4872 at 13.
`
`“An approach to reduce recovery resource requirements is to have protection LSPs sharing
`network resources when the working LSPs that they protect are physically (i.e., link, node,
`
`16
`
`Orckit Exhibit 2016
`Cisco Systems, Inc. v. Orckit Corp.
`IPR2023-00554, Page 16 of 698
`
`

`

`No.
`
`ʼ821 Patent Claim 1
`
`Cisco IOS System
`SRLG, etc.) disjoint. This mechanism is referred to as shared mesh restoration and is
`described in [RFC4426]. Shared-mesh restoration can be seen as a particular case of pre-
`planned LSP rerouting (see Section 8) that reduces the recovery resource requirements by
`allowing multiple protecting LSPs to share common link and node resources. Here also, the
`recovery resources for the protecting LSPs are pre-reserved during the provisioning phase,
`thus an explicit signaling action is required to activate (i.e., commit resource allocation at the
`data plane) a specific protecting LSP instantiated during the (pre-) provisioning phase. This
`requires restoration signaling along the protecting L