Trials@uspto.gov
`571-272-7822
`
`
`
`Paper 11
`Entered: September 22, 2015
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`CISCO SYSTEMS, INC.,
`Petitioner,
`
`v.
`
`SPHERIX PORTFOLIO ACQUISITION II, INC.,
`Patent Owner.
`
`
`
`Case IPR2015-00999
`Patent 7,397,763 B2
`
`
`
`Before JUSTIN BUSCH, LYNNE E. PETTIGREW, and
`MATTHEW R. CLEMENTS, Administrative Patent Judges.
`
`CLEMENTS, Administrative Patent Judge.
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`
`
`
`
`571-272-7822
`
`
`
`Paper 11
`Entered: September 22, 2015
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`CISCO SYSTEMS, INC.,
`Petitioner,
`
`v.
`
`SPHERIX PORTFOLIO ACQUISITION II, INC.,
`Patent Owner.
`
`
`
`Case IPR2015-00999
`Patent 7,397,763 B2
`
`
`
`Before JUSTIN BUSCH, LYNNE E. PETTIGREW, and
`MATTHEW R. CLEMENTS, Administrative Patent Judges.
`
`CLEMENTS, Administrative Patent Judge.
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`
`
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`
`I.
`
`INTRODUCTION
`
`Cisco Systems, Inc. (“Petitioner”) filed a Petition requesting inter
`
`partes review of claims 1–25 (“the challenged claims”) of U.S. Patent No.
`
`7,397,763 B2 (Ex. 1001, “the ’763 patent”). Paper 2 (“Pet.”). Spherix
`
`Portfolio Acquisition II, Inc. (“Patent Owner”) filed a Preliminary Response.
`
`Paper 8 (“Prelim. Resp.”). We have jurisdiction under 35 U.S.C. § 314,
`
`which provides that an inter partes review may be authorized only if “the
`
`information presented in the petition . . . and any [preliminary] response . . .
`
`shows that there is a reasonable likelihood that the petitioner would prevail
`
`with respect to at least 1 of the claims challenged in the petition.” 35 U.S.C.
`
`§ 314(a); 37 C.F.R. § 42.4(a). Upon consideration of the Petition and the
`
`Preliminary Response, we determine that the information presented by
`
`Petitioner establishes that there is a reasonable likelihood that Petitioner
`
`would prevail in showing the unpatentability of claims 1–25 of the ’763
`
`patent. Accordingly, pursuant to 35 U.S.C. § 314, we institute an inter
`
`partes review of claims 1–25 of the ’763 patent.
`
`A. Related Proceedings
`
`The ’763 patent is involved in Spherix Inc. v. Cisco Systems, Inc.,
`
`Case No. 1:14-cv-00393 (D. Del.). Pet. 1. According to Patent Owner, the
`
`following additional proceedings involve the ’763 patent or related U.S.
`
`Patent No. 8,607,323 B2: Spherix Inc. v. Juniper Networks, Inc., Case No.
`
`1:14-cv-00578 (D. Del), and NNTP, LLC v. Huawei Investment & Holding
`
`Co., Ltd., Case No. 2:14-cv-0677 (E.D. Tex.). Paper 5, 2. Related U.S.
`
`Patent No. 8,607,323 B2 also is the subject of IPR2015-01001.
`
`2
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`
`B. The ’763 patent
`
`The ’763 patent relates generally to admissions control in a
`
`connectionless communications network. Ex. 1001, 1:13–15. According to
`
`the ’763 patent, there were “no suitable methods for detecting link over-
`
`utilisation and communicating this to a call server or other management
`
`node in order that link over-utilisation can be prevented.” Id. at 1:60–63.
`
`Therefore, “[i]f a link is already carrying the maximum number of VOIP
`
`calls, or other non-voice traffic, adding additional calls seriously degrades
`
`the voice quality of existing calls using that link,” “[t]he new call added to
`
`the link also has poor voice quality,” and “[c]ontinuing to add calls to the
`
`link degrades the quality of all calls until none of those calls are
`
`recognisable.” Id. at 1:31–37. Known methods of admissions control
`
`require devices to support Middlebox Communication (MIDCOM)
`
`protocols, Packetcable protocols, or Common Open Policy Service (COPS)
`
`with Reservation Protocol (RSVP), but these protocols were not widely
`
`supported. Id. at 2:7–3:37.
`
`To address these problems, the ’763 patent describes a “method of
`
`providing call admission control which does not require using MIDCOM
`
`protocol methods, Packetcable protocols or COPS-RSVP approaches . . .
`
`which is simple to implement, cost-effective and which is able to deal with
`
`particular situations such as conference calls and/or lawful intercept.” Id. at
`
`3:57–62. Figure 3 of the ’763 patent is reproduced below.
`
`3
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`
`
`
`Figure 3 shows Voice over IP (VoIP) communications network 30
`
`comprising a plurality of nodes interconnected by links. Id. at 8:19–21.
`
`Communications network 30 comprises call servers 31, 32 interconnected by
`
`link 38. Id. at 8:21–26. Each call server 31, 32 is associated with one or
`
`more middleboxes 35, and is able to control packet media endpoints that are
`
`behind those middleboxes with which the call server is associated. Id. at
`
`8:26–29. Each middlebox is connected (possibly indirectly) to one or more
`
`packet media endpoints 36, and those packet media endpoints are connected
`
`to one or more terminals via which users are able to access the
`
`communications network. Id. at 8:30–34.
`
`Call server 31 serves realm A and call server 32 serves realm B. Id.
`
`at 8:40–43. Accessible by each call server is a database 33, 34, which
`
`contains pre-specified information about all the middleboxes in that call
`
`server’s realm, including: (1) which packet media endpoints are associated
`
`4
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`with each middlebox; (2) the maximum possible bandwidth of the low-
`
`bandwidth link associated with each middlebox; and (3) the current available
`
`bandwidth on the associated low-bandwidth link. Id. at 8:48–60.
`
`When a call request is made by a user of a terminal, a call request
`
`message, preferable in a form known in the art, is sent from that terminal to
`
`the associated call server via a packet media endpoint and one or more
`
`middleboxes. Id. at 8:63–9:3. If the bandwidth required for the call is less
`
`than each of the available bandwidths for the middleboxes associated with
`
`the origination and destination packet media endpoints, then the call is
`
`accepted. Id. at 9:54–56. Otherwise, the call is refused. Id. at 9:56–57.
`
`“When a call is accepted, the appropriate middlebox database is updated
`
`once the call begins and when the call ends.” Id. at 9:65–66.
`
`C. Illustrative Claim
`
`Of the challenged claims, claims 1, 9, and 11 are independent. Claim
`
`1 is reproduced below:
`
`An admission control server for use in a packet-switched
`1.
`communications network, the network comprising a plurality of
`nodes and a plurality of links interconnecting the nodes, said
`server comprising:
`
`(i) an input configured to receive a call admission request
`in respect of a potential call traversing the network between two
`or more packet media endpoints;
`
`to access predetermined
`input configured
`(ii) an
`information about one or more of the plurality of links to be
`used for carrying packets comprising the potential call, the
`predetermined information comprising an amount of available
`bandwidth on said one or more of the plurality of links;
`
`(iii) a processor configured to determine whether to
`accept the potential call on the basis of the accessed
`predetermined information;
`
`5
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`
`(iv) an output configured to output the result of the
`determination of whether to accept the potential call on the
`basis of the accessed predetermined information..
`
`Ex. 1001, 12:29–47.
`
`D. Evidence Relied Upon
`
`Petitioner relies upon the following references:
`
`Ramsey
`
`US 6,907,004 B1
`
`June 14, 2005
`
`Cisco Media Convergence Server 7830 Data Sheet, available at
`https://web.archive.org, 1–11 (“MCS Data Sheet”)
`
`Scott Keagy, INTEGRATING VOICE AND DATA NETWORKS , Cisco
`Press, 188–89, 377–01 (2000) (“Keagy”)
`
`Ex. 1005
`
`Ex. 1006
`
`Ex. 1007
`
`Abaye
`
`US 7,260,060 B1 Aug. 21, 2007
`
`Ex. 1008
`
`Pet. 10–11. Petitioner also relies upon the Declaration of Dr. Oliver Ibe
`
`(“Ibe Decl.”) (Ex. 1004).
`
`E. The Asserted Grounds of Unpatentability
`
`Petitioner argues that the challenged claims are unpatentable based on
`
`the following grounds:
`
`References
`Ramsey and MCS Data Sheet
`
`Ramsey, MCS Data Sheet, and
`Keagy
`Abaye
`
`Basis Claims challenged
`§ 103 1, 2, 8–12, 16, 17, 20–23,
`and 25
`§ 103 3, 4, 7, 13, 18, 19, and 24
`
`§ 102 1, 5, 6, 11, 14, and 15
`
`II. ANALYSIS
`
`A. Claim Construction
`
`In an inter partes review, claim terms in an unexpired patent are
`
`interpreted according to their “broadest reasonable construction in light of
`
`the specification of the patent” in which they appear. 37 C.F.R. § 42.100(b);
`
`6
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`see also In re Cuozzo Speed Techs., LLC, 793 F.3d 1268, 1278–79 (Fed. Cir.
`
`2015) (“Congress implicitly approved the broadest reasonable interpretation
`
`standard in enacting the AIA,” and “the standard was properly adopted by
`
`PTO regulation.”). Applying that standard, we interpret the claim terms
`
`according to their ordinary and customary meaning in the context of the
`
`patent’s written description. In re Translogic Tech., Inc., 504 F.3d 1249,
`
`1257 (Fed. Cir. 2007).
`
`1. “packet media endpoint” (claims 1, 4–6, 10, 11, 14, 15, 17, 18, and
`21)
`
`Claims 1, 4–6, 10, 11, 14, 15, 17, 18, and 21 recite a “packet media
`
`endpoint.” Petitioner proposes to construe this term to mean a “node that is
`
`at one end of a packet-based communication session.” Pet. 7–9. Patent
`
`Owner does not address the proper construction of “packet media endpoint.”
`
`As Petitioner acknowledges, the ’763 patent states expressly that the
`
`“term ‘packet media endpoint’ is used to refer to a terminal that is suitable
`
`for connection (possibly indirectly) to a middlebox or to refer to a node via
`
`which terminals access a middlebox (e.g. a media gateway).” Ex. 1001,
`
`7:54–57; Pet. 8. Petitioner acknowledges that “[t]his statement is reasonably
`
`viewed as an express definition of the term.” Pet. 8. Nevertheless,
`
`Petitioner contends that, because Applicants amended the claims during
`
`prosecution to remove the word “middlebox,” the term should be construed
`
`“without requiring a connection to a middlebox.” Id. at 8–9.
`
`We are not persuaded that Petitioner’s proposed construction is the
`
`broadest reasonable interpretation. As an initial matter, we are not
`
`persuaded that the explicit definition in the Specification is in tension with
`
`the claims because the definition does not require a “middlebox,” as
`
`7
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`Petitioner contends. To the contrary, the definition requires only that a
`
`“packet media endpoint” be “suitable for connection (possibly indirectly)
`
`to” a middlebox or, alternatively, be “a node via which terminals access” a
`
`middlebox. Ex. 1001, 7:54–57. Even if the second alternative were
`
`construed to require the “packet media endpoint” actually be connected to a
`
`middlebox and providing access to a terminal, rather than merely capable of
`
`doing so, the use of “or” in the definition means that is not required. As
`
`defined in the Specification, “packet media endpoint” encompasses a
`
`terminal that only “is suitable for connection (possibly indirectly) to a
`
`middlebox.” Thus, we are not persuaded that the definition requires
`
`connection to a middlebox.
`
`Moreover, Petitioner’s proposed construction is unduly narrow
`
`because it limits a “packet media endpoint” to a node “that is at one end.”
`
`The definition in the Specification explicitly defines “packet media
`
`endpoint” to encompass nodes that sit not at the end, where the terminal is,
`
`but between a middlebox and a terminal. Ex. 1001, 7:54–57 (“The term
`
`‘packet media endpoint’ is used . . . to refer to a node via which terminals
`
`access a middlebox (e.g. a media gateway).”).
`
`On this record, and for purposes of this Decision, we determine that
`
`the broadest reasonable interpretation of “packet media endpoint” is “a
`
`terminal that is suitable for connection (possibly indirectly) to a middlebox
`
`or a node via which terminals access a middlebox (e.g., a media gateway).”
`
`2. “predetermined information” (claims 1, 2, 6–8, 11, 12, 15, 24, and
`25)
`
`Claims 1, 2, 6–8, 11, 12, 15, 24, and 25 recite “predetermined
`
`information.” Petitioner proposes to construe this term to mean
`
`8
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`“information determined before it is accessed.” Pet. 9–10. Patent Owner
`
`does not address the proper construction of “predetermined information.”
`
`The claims specify that the “predetermined information” comprises
`
`“an amount of available bandwidth on said one or more of the plurality of
`
`links.” See, e.g., claim 1. Apart from the claims, the Specification does not
`
`use or define the term “predetermined information.” Pet. 9. The
`
`Specification does, however, use the term “pre-specified information,”
`
`which it describes as including “the current available bandwidth on the
`
`associated low-bandwidth link,” similar to the “predetermined
`
`information” recited in the claims. According to the Specification, the pre-
`
`specified information is updated when a call is accepted or terminated. Pet.
`
`10 (citing Ex. 1001, 6:48–50).
`
`On this record, and for purposes of this Decision, we determine that
`
`the broadest reasonable interpretation of “predetermined information” is
`
`“information determined before it is accessed.”
`
`B. Claims 1, 2, 8–12, 16, 17, 20–23, and 25 –
`Obviousness over Ramsey and MCS Data Sheet
`
`Petitioner argues that claims 1, 2, 8–12, 16, 17, 20–23, and 25 are
`
`unpatentable under 35 U.S.C. § 103(a) as obvious over Ramsey and MCS
`
`Data Sheet. Pet. 11–34.
`
`Ramsey (Exhibit 1005)
`
`Ramsey describes a method and system for manual call admission
`
`control. Ex. 1005, Title. Figure 1 is reproduced below.
`
`9
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`
`
`
`Figure 1 is a block diagram illustrating phone system 10 using a packet-
`
`based phone system such as Voice over Packet (VoP). Id. at 2:53–55. First
`
`location 12 comprises a plurality of VoP phones 20, call manager 22,
`
`computer-readable storage device 24, and network interface 26. Id. at 2:58–
`
`60; 2:65–3:6. First location 12 uses call manager 22 to manage
`
`communication between first location 12 and second location 14, which also
`
`uses VoP. Id. at 2:60–62. Call manager 22 is hardware and/or software that
`
`receives packetized voice data from phones 20 and may communicate the
`
`packetized voice data over communication links 16 and 17 using network
`
`interface 26 and the VoP protocol. Id. at 3:32–36. Call manager 22 is
`
`capable of controlling the establishment and teardown of phone calls using
`
`the VoP protocol. Id. at 3:36–38. In one embodiment, call manager 22 is a
`
`Cisco 7830 Media Convergence Server. Id. at 3:38–39.
`
`In operation, phone 20 may initiate a call to phone 34. Id. at 4:40.
`
`Call manager 22 then determines whether sufficient bandwidth is available
`
`10
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`over communications link 16 to handle a VoP call between phones 20 and
`
`34. Id. at 4:41–43. Specifically, call manager 22 consults table 28,
`
`illustrated in Figure 2 below, to determine the maximum available
`
`bandwidth and currently available bandwidth on link 16. Id. at 4:43–46.
`
`
`
`If sufficient bandwidth exists on link 16 to support a VoP call between
`
`phones 20 and 34, then call manager 22 enters the call on table 29, which
`
`includes information such as bandwidth used or an encoder/decoder
`
`(CODEC) indicator 114. Id. at 4:48–50, 6:29–34. If insufficient bandwidth
`
`exists on link 16, then call manager 22 may communicate a call denial
`
`message to phone 20 indicating that insufficient bandwidth exists, and phone
`
`20 provides call completion options to the call originator. Id. at 4:53–61.
`
`Figure 6 is reproduced below.
`
`
`
`11
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`Figure 6 is a block diagram illustrating system 310 with more than one call
`
`manager, i.e., first call manager 312 and second call manager 314. Id. at
`
`9:54–55.
`
`MCS Data Sheet (Exhibit 1006)
`
`MCS Data Sheet describes the features and functionality of the Cisco
`
`Media Convergence Server 7830. Ex. 1006, 1. MCS Data Sheet describes
`
`the MCS 7830 having a 500MHz Intel Pentium III processor, an Ethernet
`
`controller, and an Ultra SCSI-3 controller. Id. at 2–3.
`
`Analysis
`
`In light of the arguments and evidence, Petitioner has established a
`
`reasonable likelihood that claims 1, 2, 8–12, 16, 17, 20–23, and 25 are
`
`unpatentable as obvious over the combination of Ramsey and MCS Data
`
`Sheet.
`
`For independent claims 1, 9, and 11, for example, we are persuaded
`
`by Petitioner’s citations that Ramsey teaches each of the recited limitations.
`
`Pet. 11–34. To the extent there is any ambiguity in Ramsey as to whether
`
`call manager 22 necessarily teaches the recited inputs, processor, and output,
`
`we are persuaded that MCS Data Sheet fills any gaps by teaching that the
`
`Cisco Media Convergence Server 7830, described by Ramsey as an
`
`exemplary embodiment of call manager 22 (Ex. 1006, 3:39), includes an
`
`Ethernet controller, Pentium III processor, and Ultra SCSI-3 controller. Pet.
`
`17–18, 20–21. Petitioner contends that a person of ordinary skill in the art
`
`would have combined Ramsey and MCS Data Sheet because “Ramsey
`
`provides an explicit teaching, suggestion, and motivation to use the MCS
`
`7830 as call manager 22 and the MCS Data Sheet describes the features and
`
`functionality of the MCS 7830.” Pet. 14. On the record before us, we are
`
`12
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`persuaded that Petitioner has provided an articulated reasoning with some
`
`rational underpinning sufficient to support the legal conclusion of
`
`obviousness. See KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007)
`
`(citing In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006)).
`
`Petitioner also asserts that dependent claims 2, 8, 10, 12, 16, 17, 20–
`
`23, and 25 would have been obvious over Ramsey and MCS Data Sheet.
`
`Pet. 11–34. We have reviewed the Petition and Preliminary Response, and
`
`are persuaded, at this juncture of the proceeding, that Petitioner has
`
`established a reasonable likelihood that Petitioner would prevail in its
`
`challenge to dependent claims 2, 8, 10, 12, 16, 17, 20–23, and 25.
`
`We are not persuaded by Patent Owner’s argument that we should
`
`deny this ground under 35 U.S.C. § 325(d). Patent Owner argues that
`
`Ramsey was previously before the office during prosecution of the parent
`
`application of the ’763 patent. Prelim. Resp. 9–10. Although the Examiner
`
`allowed the claims pending in the parent application over Ramsey, those
`
`claims differ from the claims of the ’763 patent at least insofar as they recite
`
`a “middlebox,” a term relied upon by the Examiner in the Notice of
`
`Allowance. Ex. 1002, 8. Thus, we are not persuaded that substantially the
`
`same arguments with respect to Ramsey were previously considered during
`
`examination of the ’763 patent. Under the circumstances presented by this
`
`case, we decline to exercise our discretion under § 325(d) to deny this
`
`ground.
`
`Conclusion
`
`On this record, we are persuaded that Petitioner has established a
`
`reasonable likelihood that it would prevail in showing that claims 1, 2, 8–12,
`
`13
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`16, 17, 20–23, and 25 are unpatentable as obvious over the combination of
`
`Ramsey and MCS Data Sheet.
`
`C. Claims 3, 4, 7, 13, 18, 19, and 24 –
`Obviousness over Ramsey, MCS Data Sheet, and Keagy
`
`Petitioner argues that the claims 3, 4, 7, 13, 18, 19, and 24 are
`
`unpatentable under 35 U.S.C. § 103(a) as obvious over Ramsey, MCS Data
`
`Sheet, and Keagy. Pet. 35–45.
`
`Keagy (Exhibit 1007)
`
`Keagy describes protocols that are relevant to VoIP deployment,
`
`including Session Initiation Protocol (SIP), which provides the VoIP call
`
`signaling, and Session Description Protocol (SDP), which provides a format
`
`for exchanging speech codec capabilities. Ex. 1007, 6–7. The SIP protocol
`
`specifies an INVITE message that initiates a VoIP call. Id. at 16, 25–28.
`
`The SDP protocol is designed to identify all attributes of a session, including
`
`bandwidth information and codec information. Id. at 7, 23–24.
`
`Analysis
`
`In light of the arguments and evidence, Petitioner has established a
`
`reasonable likelihood that claims 3, 4, 7, 13, 18, 19, and 24 are unpatentable
`
`as obvious over the combination of Ramsey, MCS Data Sheet, and Keagy.
`
`For claims 3 and 13, we are persuaded by Petitioner that the SIP
`
`INVITE message described in Keagy teaches the recited “call admission
`
`request” and that its “b=” attribute describes the bandwidth required for the
`
`call. Pet. 37–39, 43.
`
`For claims 4 and 19, we are persuaded by Petitioner that the SIP
`
`INVITE message described in Keagy is formatted according to the SDP and
`
`includes a “b=” attribute describing the bandwidth requirement of the
`
`14
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`potential call, and an “m=” attribute describing which codec will be used for
`
`the potential call. Pet. 40–41, 45.
`
`For claims 7 and 24, we are persuaded by Petitioner that available
`
`bandwidth field 56 in table 29 of Ramsey teaches an estimated amount of
`
`available bandwidth on one of the links. Pet. 41–43, 45.
`
`For claim 18, we are persuaded by Petitioner that information about
`
`bandwidth requirements is derived not only from the SIP INVITE message
`
`sent from the origination endpoint to the destination endpoint, but also from
`
`the “m=” attribute of the SIP/2.00 180 Ringing message sent from the
`
`destination endpoint to the origination endpoint, as described in Keagy. Pet.
`
`43–45.
`
`Petitioner contends that “a person of ordinary skill in the art would
`
`have used the SIP/SDP message protocols disclosed in Keagy with
`
`Ramsey’s call manager in order to manage voice-over-packet calls,” and that
`
`“[t]his combination would have been achieved using the known method of
`
`using protocols to manage VoIP call sessions, as taught by Ramsey.” Pet.
`
`36–37 (citing Ex. 1004 (Ibe Decl.) ¶ 65). On the record before us, we are
`
`persuaded that Petitioner has provided an articulated reasoning with some
`
`rational underpinning sufficient to support the legal conclusion of
`
`obviousness. See KSR, 550 U.S. at 418 (citing Kahn, 441 F.3d at 988).
`
`Conclusion
`
`On this record, we are persuaded that Petitioner has established a
`
`reasonable likelihood that it would prevail in showing that claims 3, 4, 7, 13,
`
`18, 19, and 24 are unpatentable as obvious over the combination of Ramsey,
`
`MCS Data Sheet, and Keagy.
`
`15
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`
`D. Claims 1, 5, 6, 11, 14, and 15 –
`Anticipated by Abaye
`
`Petitioner argues that the claims 1, 5, 6, 11, 14, and 15 are
`
`unpatentable under 35 U.S.C. § 102(b) as anticipated by Abaye. Pet. 46–60.
`
`Abaye (Exhibit 1008)
`
`Abaye describes “[a] method and system of managing calls over a
`
`data network includ[ing] admitting a call if a throughput requirement is
`
`met.” Ex. 1008, Abstract. Figure 1 of Abaye is reproduced below.
`
`
`
`Figure 1 depicts a telephony communications system including a number of
`
`endpoints or terminals (14, 16, 30, and 34) that are capable of performing
`
`voice or other audio communication over a packet-based or message-based
`
`data network 20. Id. at 3:36–41. Endpoints or terminals 14, 16, 30, and 34
`
`may include computer systems with speech capability, telephone units that
`
`include interfaces to data network 20, gateways coupled to standard
`
`telephones 34, and other types of devices. Id. at 3:44–50. Connection
`
`manager 50 manages call setup, processing, and termination between or
`
`16
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`among terminals 14, 16, and 30. Id. at 4:6–10. Policy server 60 may be
`
`queried by connection manager 50 to determine the available bandwidth and
`
`other usage policy to control the quality of service on data network 20. Id. at
`
`4:10–14.
`
`To establish a call between two or more terminals, the originating
`
`terminal sends a call request to connection manager 50. Id. at 4:57–60.
`
`“The call request includes the IP address of the originating terminal P1, an
`
`identifier of the destination terminal, a throughput requirement for the call,
`
`and optionally a list of one or more resource elements supported by the
`
`originating terminal to be used during an established call.” Id. at 4:60–65.
`
`During call setup processing, as shown in Figure 3 below, connection
`
`manager 50 may optionally query policy server 60 to determine the available
`
`bandwidth of the data network links over which the call will be established.
`
`Id. at 5:56–60.
`
`
`
`17
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`Specifically, connection manager 50 may send to policy server 60 a
`
`QUERY_BANDWIDTH_POLICY message that includes the IP addresses of
`
`the originating and destination terminals (P1, P2) and a request for the real time
`
`congestion status and linkage usage of appropriate edge routers which may
`
`serve originating and destination terminals (P1, P2). Id. at 10:65–11:5. Policy
`
`server 60 responds to the query “by sending a REPLY_BANDWIDTH-
`
`_POLICY message back to connection manager 50 to indicate the real time
`
`congestion status and linkage usage of network resources which may serve
`
`terminals P1 and P2, and also optionally, the available bandwidth that may
`
`be allocated between the terminals P1 and P2 for the present call session.”
`
`Id. at 11:30–35.
`
`Analysis
`
`In light of the arguments and evidence, Petitioner has established a
`
`reasonable likelihood that claims 1, 5, 6, 11, 14, and 15 are unpatentable as
`
`anticipated by Abaye.
`
`For independent claims 1 and 11, for example, we are persuaded by
`
`Petitioner’s citations that Abaye discloses each of the recited limitations.
`
`Pet. 47–54, 58–59. With respect to the recited “predetermined information,”
`
`Petitioner relies upon the real time congestion status, linkage usage, and
`
`available bandwidth that may be allocated between terminals P1 and P2
`
`returned in Abaye’s REPLY_BANDWIDTH_POLICY message. Id. at 50.
`
`We have construed “predetermined information” to mean “information
`
`determined before it is accessed.” Petitioner does not direct us to any
`
`disclosure in Abaye of how or when policy server 60 determines or updates
`
`the information regarding real time congestion status, linkage usage, or
`
`available bandwidth. We note, however, that this information, obtained by
`
`18
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`querying policy server 60, is disclosed in Abaye as an alternative to a “trace
`
`route” process in which connection manager 50 tests throughput
`
`measurement directly during call setup processing. Id. at 9:65–10:51. On
`
`this record, at this juncture in the proceeding, we are persuaded that
`
`Petitioner has shown sufficiently that Abaye’s information regarding real
`
`time congestion status, linkage usage, and allocated available bandwidth is
`
`determined before it is accessed.
`
`We are not persuaded by Patent Owner’s argument that Abaye’s
`
`processor determines whether to accept a potential call on the basis of
`
`whether a suitable codec is present—not “on the basis of the accessed
`
`predetermined information,” as required. Prelim. Resp. 10–13. Abaye’s
`
`determination of whether a suitable codec is present is based on “the
`
`accessed information,” namely, the available bandwidth in the
`
`REPLY_BANDWIDTH_POLICY message sent from policy server 60 to
`
`connection manager 50. “Based on the received allocated bandwidth, the
`
`connection manager 50 updates (at 118) the candidate list by deleting
`
`unacceptable codecs.” Ex. 1008, 11:36–38. “If at least one codec and at
`
`least one packet size is available in the candidate list, then the call may
`
`proceed.” Id. at 12:26–27. Because the candidate list of codecs is
`
`determined based on allocated available bandwidth—i.e., “the accessed
`
`predetermined information”—Abaye’s determination of whether to accept
`
`the call is “on the basis of the accessed predetermined information.”
`
`Petitioner also asserts that dependent claims 5, 6, 14, and 15 are
`
`anticipated by Abaye. Pet. 55–60. We have reviewed the Petition and
`
`Preliminary Response, and are persuaded, at this juncture of the proceeding,
`
`19
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`that Petitioner has established a reasonable likelihood that Petitioner would
`
`prevail in its challenge to dependent claims 5, 6, 14, and 15.
`
`We are not persuaded by Patent Owner’s argument that we should
`
`deny this ground under 35 U.S.C. § 325(d). Patent Owner argues that
`
`“Abaye has the same relevant teaching as that contained in Ramsey,” which
`
`was previously before the office during prosecution of the parent application
`
`of the ’763 patent. Prelim. Resp. 2–3. First, we are not persuaded that
`
`Ramsey and Abaye have “the same relevant teaching,” as Patent Owner
`
`contends. Ramsey and Abaye were filed by two different companies—Cisco
`
`and Nortel, respectively—and describe two different systems. Ex. 1005;
`
`Ex. 1008. Second, as explained above, we are not persuaded that
`
`substantially the same arguments with respect to Ramsey were previously
`
`considered during examination of the ’763 patent. Although the Examiner
`
`allowed the claims pending in the parent application over Ramsey, those
`
`claims differ from the claims of the ’763 patent at least insofar as they recite
`
`a “middlebox,” a term relied upon by the Examiner in the Notice of
`
`Allowance. Ex. 1002, 8. Under the circumstances presented by this case,
`
`we decline to exercise our discretion under § 325(d) to deny this ground.
`
`Conclusion
`
`On this record, we are persuaded that Petitioner has established a
`
`reasonable likelihood that it would prevail in showing that claims 1, 5, 6, 11,
`
`14, and 15 are unpatentable as anticipated by Abaye.
`
`
`
`20
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`
`III. CONCLUSION
`
`For the foregoing reasons, we determine that Petitioner has
`
`established that there is a reasonable likelihood that Petitioner would prevail
`
`in establishing the unpatentability of claims 1–25 of the ’763 patent.
`
`The Board has not made a final determination on the patentability of
`
`any challenged claims.
`
`Accordingly, it is
`
`IV. ORDER
`
`ORDERED that pursuant to 35 U.S.C. § 314, an inter partes review is
`
`hereby instituted on the following grounds:
`
`1. Claims 1, 2, 8–12, 16, 17, 20–23, and 25 under 35 U.S.C. § 103 as
`
`obvious over Ramsey and MCS Data Sheet;
`
`2. Claims 3, 4, 7, 13, 18, 19, and 24 under 35 U.S.C. § 103 as obvious
`
`over Ramsey, MCS Data Sheet, and Keagy; and
`
`3. Claims 1, 5, 6, 11, 14, and 15 under 35 U.S.C. § 102 as anticipated
`
`by Abaye; and
`
`FURTHER ORDERED that pursuant to 35 U.S.C. § 314(d) and
`
`37 C.F.R. § 42.4, notice is hereby given of the institution of a trial on the
`
`grounds of unpatentability authorized above; the trial commences on the
`
`entry date of this Decision.
`
`
`
`21
`
`
`
`IPR2015-00999
`Patent 7,397,763 B2
`
`For PETITIONER:
`
`David L. McCombs
`Theodore M. Foster
`Michael S. Parsons
`HAYNES AND BOONE LLP
`david.mccombs.ipr@haynesboone.com
`ipr.theo.foster@haynesboone.com
`ipr.michael.parsons@haynesboone.com
`
`For PATENT OWNER:
`
`Donald McPhail
`Carl B. Wischhusen
`COZEN O’CONNOR
`DMcphail@cozen.com
`CWischhusen@cozen.com
`
`
`
`22
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
