`571-272-7822
`
`
`
`
`
`
` Paper No. 8
`Entered: October 2, 2018
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`Apple Inc.,
`Petitioner,
`
`v.
`
`Uniloc 2017 LLC,1
`Patent Owner.
`
`____________
`
`Case IPR2018-00884
`Patent 8,539,552 B1
`____________
`
`
`
`
`Before SALLY C. MEDLEY, KARL D. EASTHOM, and
`SEAN P. O’HANLON, Administrative Patent Judges.
`
`O’HANLON, Administrative Patent Judge.
`
`
`
`
`DECISION
`Institution of Inter Partes Review
`35 U.S.C. § 314(a)
`
`
`
`
`1 Per an assignment recorded on July 12, 2018, the Patent Owner is Uniloc
`2017 LLC. Patent Owner may wish to consider whether an updated power
`of attorney is warranted.
`
`
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`
`I. INTRODUCTION
`
`
`
`Apple Inc. (“Petitioner”) filed a Petition for inter partes review of
`
`claims 1–25 of U.S. Patent No. 8,539,552 B1 (Ex. 1001, “the ’552 patent”).
`
`Paper 2 (“Pet.”), 1. Uniloc Luxembourg S.A., a predecessor in interest of
`
`Uniloc 2017 LLC (“Patent Owner”), filed a Preliminary Response. Paper 6
`
`(“Prelim. Resp.”).
`
`
`
`Institution of an inter partes review is authorized by statute only when
`
`“the information presented in the petition . . . and any 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). For the reasons set forth below, upon considering the Petition,
`
`Preliminary Response, and evidence of record, we conclude the information
`
`presented shows there is a reasonable likelihood that Petitioner would
`
`prevail in establishing the unpatentability of claims 1–25 of the ’552 patent.
`
`A. Related Matters
`
`
`
`The parties indicate that the ’552 patent is not involved in any federal
`
`district court litigations or any other challenges before the Board. Pet. i;
`
`Paper 7, 2.
`
`B. The Challenged Patent
`
`
`
`The ’552 patent discloses a system and method for network based
`
`policy enforcement of intelligent client features. Ex. 1001, 1:7–10.
`
`In packet-based networks, intelligent end-user clients
`
`with little or no support and/or knowledge of the network can
`deliver many features and services. For networks to retain
`control over the features and services used by subscribers that
`use intelligent end-user clients, the networks need to be able to
`
`2
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`
`recognize signaling and call control messages and transactions
`that implement these features and services within the network.
`This is particularly important in next-generation IP telephony
`and IP multimedia networks where many basic and advanced
`services may be signaled, controlled, and/or delivered by
`intelligent end-user clients which are not owned or controlled
`by the network or service providers, thereby enabling the
`potential bypassing by the end user of service agreements or
`other subscription accounting mechanisms.
`
`Id. at 2:61–3:7.
`
`
`
`The ’552 patent provides network-based policy enforcement to control
`
`access to and use of features and services. Id. at 3:20–23. A policy
`
`enforcement point within the core network, to which local networks seek
`
`access, is used to provide such enforcement. Id. at 7:32–34; see also id. at
`
`3:48–61 (discussing an exemplary network architecture). The policy
`
`enforcement point is in the communications path of every call control and
`
`signaling message between any end-user client and any call control and
`
`signaling entity of the core network, and uses information regarding the
`
`sender and/or the intended recipient to determine whether access to the
`
`services and features of the core network is authorized. Id. at 7:34–52,
`
`7:66–8:11.
`
`
`
`Figure 3, which is a flowchart depicting one embodiment of a method
`
`of network-based policy enforcement of intelligent client features (id. at
`
`2:44–46), is reproduced below:
`
`3
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Figure 3 is a flowchart depicting one embodiment of a method 300 of
`
`network-based policy enforcement of intelligent client features. Id. at 8:54–
`
`56. Initially, the policy enforcement point receives or intercepts signaling
`
`and call control messages. Id. at 8:56–58. At block 302, the method
`
`associates each signaling and/or call control message with a known service
`
`or feature. Id. at 8:60–63. The policy enforcement point then determines
`
`whether the sender and/or the intended recipient of the message is authorized
`
`to use and/or invoke the identified service or feature (block 304), and filters
`
`each signaling and/or call control message according to whether or not the
`
`identified service or feature is authorized for the sender and/or intended
`
`recipient (block 306). Id. at 8:63–9:3. Finally, the policy enforcement point
`
`4
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`communicates with and/or controls one or more network entities responsible
`
`for monitoring and regulating media data flow across network boundaries in
`
`order to ensure compliance with the usage authorization at block 308. Id. at
`
`9:3–8.
`
`C. The Challenged Claims
`
`
`
`Petitioner challenges claims 1–25 of the ’552 patent. Claims 1, 6, 18,
`
`23, and 24 are independent. Claim 1 is illustrative of the challenged claims
`
`and is reproduced below:
`
`A method for controlling a plurality of services in packet-
`1.
`based networks, the method comprising:
`
`[1A] a network entity intercepting a signaling message
`associated with a call between a sender device of the message
`and an intended recipient device of the message, [1B] wherein
`the signaling message includes an indication of one type of the
`plurality of services which the signaling message is intended to
`invoke;
`
`[1C] the network entity making a determination of
`whether either the sender device or the intended recipient
`device is authorized to invoke the type of service indicated in
`the signaling message based in part on a device profile
`maintained in part on a remote enforcement point, [1D] wherein
`the type of service comprises at least one of caller-ID, call
`waiting, multi-way calling, multi-line service, and codec
`specification; and
`
`[1E] the network entity filtering the signaling message
`based on the determination such that the signaling message is
`transmitted to the intended recipient device if either the sender
`device or the intended recipient device is authorized to invoke
`the type of service indicated in the signaling message.
`
`Ex. 1001, 19:60–20:14.
`
`5
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`
`D. Asserted Grounds of Unpatentability
`
`
`
`Petitioner asserts the following grounds of unpatentability:
`
`No.
`
`Reference(s)
`
`Basis2
`
`Challenged
`Claim(s)
`
`1
`
`2
`
`3
`
`4
`
`Kalmanek3
`
`35 U.S.C. § 103(a) 1–4, 6–10, 12–20,
`22, and 23
`
`Kalmanek and Shaffer4 35 U.S.C. § 103(a) 5 and 11
`
`Kalmanek and
`Strathmeyer5
`
`Kalmanek and
`Gleichauf6
`
`35 U.S.C. § 103(a) 21, 24, and 25
`
`35 U.S.C. § 103(a) 17
`
`Pet. 6–7. Petitioner submits a declaration of Dr. Aviel Rubin (Ex. 1003,
`
`“Rubin Declaration” or “Rubin Decl.”) in support of its contentions.
`
`II. ANALYSIS
`
`A. Level of Ordinary Skill in the Art
`
`
`
`Petitioner contends that a person having ordinary skill in the art
`
`(“POSITA”) would “hav[e] at least a bachelor’s degree in electrical
`
`engineering, computer science or engineering, or in a related field, with at
`
`
`2 The ’552 patent was filed on September 25, 2003, prior to the date when
`the Leahy-Smith America Invents Act (“AIA”) took effect.
`3 US 6,324,279 B1 (issued Nov. 27, 2001) (Ex. 1004, “Kalmanek”).
`4 US 7,023,839 B1 (filed Aug. 19, 1999, issued Apr. 4, 2006) (Ex. 1005,
`“Shaffer”).
`5 US 2001/0026548 A1 (published Oct. 4, 2001) (Ex. 1006, “Strathmeyer”).
`6 US 7,412,598 B1 (filed Dec. 29, 2000, issued Aug. 12, 2008) (Ex. 1007,
`“Gleichauf”).
`
`6
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`least 2 years of industry or research experience with packet-based
`
`telecommunications systems.” Pet. 5 (citing Ex. 1003 ¶¶ 31–33).
`
`
`
`“Patent Owner does not offer a competing definition for POSITA
`
`. . . .” Prelim. Resp. 2. Patent Owner’s declarant, Mr. William C. Easttom
`
`II, defines a POSITA in a manner substantially similar to that of Petitioner.
`
`See Ex. 2001 ¶¶ 20–21.
`
`
`
`We find Petitioner’s definition reasonable, and for purposes of this
`
`Decision, adopt it as our own.
`
`B. Claim Construction
`
`
`
`In an inter partes review, a claim in an unexpired patent shall be given
`
`its broadest reasonable construction in light of the specification of the patent
`
`in which it appears. 37 C.F.R. § 42.100(b); Cuozzo Speed Techs., LLC v.
`
`Lee, 136 S. Ct. 2131, 2144–46 (2016) (upholding the use of the broadest
`
`reasonable interpretation standard). Consistent with the broadest reasonable
`
`construction, claim terms are presumed to have their ordinary and customary
`
`meaning as understood by a person of ordinary skill in the art in the context
`
`of the entire patent disclosure. In re Translogic Tech., Inc., 504 F.3d 1249,
`
`1257 (Fed. Cir. 2007). The presumption may be overcome by providing a
`
`definition of the term in the specification with reasonable clarity,
`
`deliberateness, and precision. See In re Paulsen, 30 F.3d 1475, 1480 (Fed.
`
`Cir. 1994). In the absence of such a definition, limitations are not to be read
`
`from the specification into the claims. See In re Van Geuns, 988 F.2d 1181,
`
`1184 (Fed. Cir. 1993). Only those terms which are in controversy need be
`
`construed, and only to the extent necessary to resolve the controversy. Vivid
`
`Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999).
`
`7
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`
`
`Petitioner proposes constructions for two claim terms. Pet. 8–10.
`
`Patent Owner asserts that no claim construction is needed and disagrees with
`
`Petitioner’s proposed constructions. Prelim. Resp. 3–6. We discuss each of
`
`the terms identified by Petitioner below.
`
`1. intercepting
`
`
`
`Petitioner argues that the broadest reasonable interpretation of
`
`“intercepting” as used in claims 1, 6, 18, and 23 means “receiving,” and that
`
`“[a] POSITA would readily understand that intercepting signaling messages,
`
`as described by the ’552 Patent, is used to indicate the signaling is received
`
`by a network entity located between the endpoints of the call (i.e., between
`
`the caller and callee).” Pet. 8–9 (citing Ex. 1003 ¶ 35).
`
`
`
`Patent Owner disputes Petitioner’s interpretation that “intercepting”
`
`means “receiving,” but does not offer a competing definition. Prelim. Resp.
`
`4–6. Relying on its declarant, Patent Owner argues the entity intercepting a
`
`message would be a third party to the message, and would not be one of the
`
`intended recipients of that message. Id. at 5; see also id. at 9 (“the claim
`
`language makes clear the ‘intended recipient’ and the ‘intercepting’ device
`
`are not the same”). Patent Owner’s declarant cites several dictionary
`
`definitions of intercept and states “[a]ll the definitions I found, both in
`
`standard dictionaries and in engineering and telecommunications
`
`dictionaries[,] all define intercepting as someone other than the intended
`
`recipient getting the message.” Ex. 2001 ¶¶ 5–15.
`
`
`
`Petitioner’s and Patent Owner’s arguments assert the same
`
`interpretation of intercepting, namely that “a network entity intercepting a
`
`signaling message associated with a call between a sender device of the
`
`message and an intended recipient device of the message” means that the
`
`8
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`network entity receives the message and the network entity is not the
`
`intended end recipient device. This interpretation is consistent with the
`
`ordinary usage of term, as set forth by Patent Owner’s declarant. This
`
`interpretation is consistent also with how “intercepting” is used in the ’552
`
`patent, which uses the terms interchangeably. See, e.g., Ex. 1001 8:56–58
`
`(“Initially, signaling and call control messages are received or intercepted by
`
`the policy enforcement point.” (emphasis added)); see also id. at 7:32–42
`
`(explaining that the “policy enforcement point . . . is . . . in the
`
`communications path of substantially each and every call control and
`
`signaling message between any end-user client and any call control and
`
`signaling entity of the network 202 (including, possibly, another client
`
`device).”). We fail to see a distinction between a network entity, positioned
`
`intermediate the sender device and the intended end recipient device,
`
`“receiving” the message (see Pet. 9) and “getting” the message (see Ex.
`
`2001 ¶ 15).
`
`
`
`Accordingly, for purposes of this Decision, we adopt Petitioner’s
`
`proposed construction of “intercepting” a message to mean the signal is
`
`received by a network entity located between the endpoints of the call.
`
`2. device profile
`
`
`
`Petitioner argues that although claim 1 recites “whether either the
`
`sender device or the intended recipient device is authorized to invoke the
`
`type of service indicated in the signaling message based in part on a device
`
`profile,” “there is no ‘device profile’ described in the ’552 Patent. Instead,
`
`there is a user profile for a user of a particular device.” Pet. 9. According to
`
`Petitioner, “the ’552 Patent consistently describes an authorization process
`
`that is (1) based on a user profile and (2) wherein services authorized for a
`
`9
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`device are in fact services authorized for the user of that device.” Id. at 10.
`
`Thus, Petitioner reasons, the broadest reasonable interpretation of “device
`
`profile,” as used in claim 1, refers to the profile of the user using the device
`
`such that “making a determination of whether either the sender device or the
`
`intended recipient device is authorized to invoke the type of service
`
`indicated in the signaling message based in part on a device profile” means
`
`“determining whether a user of a particular device is authorized to invoke a
`
`service based on that user’s profile.” Id. (citing Ex. 1003 ¶ 57).
`
`
`
`“Patent Owner does not submit a competing definition.” Prelim.
`
`Resp. 6; see also Ex. 2001 ¶ 17.
`
`
`
`We determine that, at this stage of the proceeding, we need not
`
`explicitly construe “device profile” to resolve the parties’ controversies. See
`
`Vivid Techs., 200 F.3d at 803 (construing explicitly only those claim terms in
`
`controversy and only to the extent necessary to resolve the controversy).
`
`C. Challenge 1 – Kalmanek
`
`
`
`Petitioner argues that claims 1–4, 6–10, 12–20, 22, and 23 would have
`
`been unpatentable over Kalmanek. Pet. 18–56. In support of its showing,
`
`Petitioner relies upon the Rubin declaration. Id. (citing Ex. 1003). We have
`
`reviewed Petitioner’s assertions and supporting evidence. For the reasons
`
`discussed below, and based on the record before us, Petitioner demonstrates
`
`a reasonable likelihood of prevailing in showing that the challenged claims
`
`would have been obvious over Kalmanek.
`
`1. Overview of Kalmanek
`
`
`
`Kalmanek discloses a communications system in which resources are
`
`reserved and committed based on an authorized quality of service. Ex. 1004,
`
`10
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`1:26–28. Kalmanek recognizes shortcomings in the known signaling
`
`architecture H.323, which is a signaling architecture appropriate for use in
`
`networks using connectionless best-effort delivery models. Id. at 1:30–67.
`
`Such shortcomings include the need for equipment associated with
`
`gatekeepers to be extremely reliable, difficulty in cost-effective scalability of
`
`gatekeeper-related equipment, and possible theft of service by bypassing the
`
`gatekeeper. Id. at 1:56–67.
`
`
`
`Kalmanek uses a two-phase signal process in which messages for
`
`setting up the call are exchanged in one phase and messages for connecting
`
`the call are exchanged in a separate and distinct second phase. Id. at 12:39–
`
`45. “By separating the messages for setting up the call from the messages
`
`for connecting the call, the [latter] messages can be exchanged end to end
`
`without being routed through the gate controllers that set up the call.” Id. at
`
`12:45–48. Because “the gate controllers are involved only during the initial
`
`start of the call but not during the call duration,” the message load is reduced
`
`such that “the amount of memory need[ed] in the gate controllers is greatly
`
`reduced” and “the gate controllers can be constructed without the typically
`
`stringent requirements for reliability.” Id. at 14:39–46.
`
`
`
`Theft of service can occur when a telephone interface unit fails to
`
`acknowledge that a call has been initiated or a call has been terminated. Id.
`
`at 16:15–21, 43–52. Kalmanek overcomes these potential problems by
`
`using network edge devices to control call setup and termination. Id. at
`
`16:21–27, 52–56.
`
`
`
`The gate controllers can authenticate signaling messages and
`
`authorize requests for service so that communication services and certain
`
`service features are only provided to authorized subscribers. Id. at 6:49–52.
`
`11
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`Upon receiving a setup request message from a calling party, the gate
`
`controller can authenticate the identity of the calling party and authorize the
`
`service sought by the calling party. Id. at 6:52–55.
`
`2. Claims 1–4
`
`a. Petitioner’s Contentions
`
`
`
`Petitioner relies on Kalmanek to teach or suggest all of the limitations
`
`of claim 1, and the Petition provides a mapping of claim 1 to Kalmanek. Id.
`
`at 18–41. Regarding the preamble, Petitioner argues that “Kalmanek
`
`discloses a method of using a ‘gate controller’ for controlling services such
`
`as codec specification and caller ID within ‘packet telephony’ networks.”
`
`Pet. 18 (citing Ex. 1004, 3:40–45, 6:49–55, 10:13–19, 46:49–52). We find
`
`that the cited portions of Kalmanek support Petitioner’s contentions.
`
`
`
`Regarding limitation 1A, Petitioner argues that Kalmanek’s gate
`
`controllers 110, 111 in conjunction with network edge devices (“NEDs”)
`
`120, 121 correspond to the recited network entity. Id. at 21–22. Petitioner
`
`argues that “[t]he NED provides access to a particular service based on
`
`authorization provided by that NED’s corresponding gate controller.” Id. at
`
`21 (citing Ex. 1004, 5:9–28; Ex. 1003 ¶ 54). Petitioner relies on Kalmanek’s
`
`originating telephone interface unit (“TIU”) and terminating TIU to
`
`correspond to the recited sender device and intended recipient device,
`
`respectively. Id. at 22–23 (citing Ex. 1004, 9:40–43; Ex. 1003 ¶ 55).
`
`Petitioner argues that “the gate controller and NED work together to
`
`intercept or receive a message, authorize a service level for the message, and
`
`implement the service level according to the message,” and identifies “a call
`
`setup message” as the message that is intercepted. Id. at 23 (citing Ex. 1003
`
`¶¶ 50, 52–56). Petitioner argues that a person having ordinary skill in the art
`
`12
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`would understand Kalmanek’s SETUP message to be a signaling message,
`
`the intended recipient of which is the device associated with the callee. Id.
`
`at 24 (citing Ex. 1003 ¶ 73). For the reasons set forth in section II.C.2.b
`
`below, we find that Kalmanek supports Petitioner’s contentions.
`
`
`
`Regarding limitations 1B and 1D, Petitioner argues that Kalmanek
`
`discloses that its signaling message includes an indication of codec
`
`specification and caller ID. Id. at 26–31, 38–39.
`
`
`
`Regarding codec specification, Petitioner notes that, as used in
`
`Kalmanek, “quality of service” is a measurement of communication service
`
`during a call and can include the bandwidth associated with the call. Id. at
`
`27 (citing Ex. 1004, 1:36–39, 3:61–64). Petitioner further notes that
`
`Kalmanek’s SETUP message includes a CODING parameter that, according
`
`to Petitioner, identifies the codec. Id. at 27–28 (citing Ex. 1004, 21:23–29,
`
`29:18, 30:1–8). Petitioner argues that “the chosen codec also dictates the
`
`bandwidth required for the call” because “each standardized codec utilizes a
`
`different amount of data to encode a given amount of voice data.” Id. at 28
`
`(citing Ex. 1003 ¶ 27).
`
`
`
`Petitioner further notes that Kalmanek discloses a GATESETUP
`
`message that is sent from the gate controllers to the edge routers and that
`
`includes an indication of the bandwidth to be implemented by the edge
`
`routers. Id. at 28–29 (citing Ex. 1004, 34:46–35:22). Petitioner argues that
`
`the bandwidth specified in the GATESETUP message is “the same
`
`bandwidth dictated by the coding algorithm identified in the SETUP
`
`message sent from the BTI to the gate controller.” Id. at 29 (citing Ex. 1003
`
`¶¶ 27, 53). Thus, Petitioner argues, “Kalmanek teaches that the SETUP
`
`message sent from the TIU/BTI to the corresponding [gate controller]
`
`13
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`includes an indication of a service, such as a codec . . ., the SETUP message
`
`is intended to invoke.” Id. at 31. For the reasons set forth in section II.C.2.b
`
`below, on this preliminary record, Kalmanek supports Petitioner’s
`
`contentions.
`
`
`
`Regarding caller ID, Petitioner notes that Kalmanek discloses that,
`
`upon receiving the SETUP message from the terminating gate controller, the
`
`terminating broadband telephony interface (“BTI”) can request caller ID
`
`information by including a caller ID flag in its SETUPACK message that
`
`confirms receipt of the SETUP message. Id. at 30 (citing Ex. 1004, 56:18–
`
`24, Fig. 23). Petitioner notes that Kalmanek discloses that the terminating
`
`gate controller will then verify that the customer is subscribed to the caller
`
`ID service, and, if the customer is verified, return the caller ID to the
`
`customer. Id. at 30–31 (citing Ex. 1004, 56:22–24; Ex. 1003 ¶ 56).
`
`Petitioner further notes that Kalmanek discloses an alternative
`
`implementation whereby the terminating gate controller checks whether the
`
`terminating BTI subscribes to caller ID service on receipt of every call rather
`
`than waiting for the terminating BTI to request caller ID information. Id. at
`
`31 (citing Ex. 1004, 56:36–44). Thus, Petitioner argues, “Kalmanek teaches
`
`that the SETUP message sent from the TIU/BTI to the corresponding [gate
`
`controller] includes an indication of a service, such as . . . caller ID, the
`
`SETUP message is intended to invoke.” Id. at 31. On this preliminary
`
`record, the cited portions of Kalmanek support Petitioner’s contentions.
`
`
`
`Regarding limitation 1C, Petitioner argues that “Kalmanek teaches
`
`that the network entity, namely the gate controller, determines whether the
`
`user of a sender device and the user of an intended recipient device are
`
`authorized to invoke a service indicated in the signaling message based on
`
`14
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`the users’ respective profiles.” Id. at 32. According to Petitioner,
`
`“Kalmanek teaches that the gate controllers have access to authentication
`
`databases with customer profile information,” and “‘[t]he gate controllers
`
`can authenticate signaling messages and authorize requests for service so
`
`that communication services and certain service features are only provided
`
`to authorized subscribers.’” Id. at 32–33 (quoting Ex. 1004, 6:51–53, citing
`
`Ex. 1004, 10:13–19). Petitioner argues that Kalmanek’s SETUP message
`
`includes a CALLER field, which provides called ID information, and that
`
`Kalmanek’s terminating gate controller determines whether the intended
`
`recipient line is authorized to receive caller ID information. Id. at 34–36
`
`(citing Ex. 1004, 7:19–21, 21:53–61, 25:25–29, 25:37–43, 56:22–24; Ex.
`
`1003 ¶ 59). Petitioner argues that Kalmanek’s SETUP message also
`
`includes a CODING field identifying one or more coding algorithms, which
`
`correspond to a desired quality of service/bandwidth to be implemented, and
`
`that the gate controllers determine if both the sender and recipient devices
`
`are authorized to invoke the codec specification. Id. at 36–38 (citing Ex.
`
`1004, 7:29–34, 9:6–21, 10:13–19, 13:55–63, 21:22–29, 22:32–53, 35:6–12;
`
`Ex. 1003 ¶ 62). Petitioner also argues that a person having ordinary skill in
`
`the art “would have understood that, to the extent not already part of the
`
`described Kalmanek system, both users’ customer profiles could be
`
`referenced as a means of authorizing the specifically requested codec.” Id.
`
`at 38 (citing Ex. 1003 ¶ 63). On this preliminary record, the cited portions
`
`of Kalmanek support Petitioner’s contentions.
`
`
`
`Regarding limitation 1E, Petitioner relies on Kalmanek’s discussion
`
`of caller ID and called ID blocking as corresponding to the recited filtering
`
`of the signaling message. Id. at 39–41. Kalmanek discloses that the SETUP
`
`15
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`message will contain a CALLER field, which “is the caller-id information,”
`
`“only . . . if the customer has subscribed to some variant of caller-id
`
`service.” Ex. 1004, 25:37–39; see also Pet. 39–40. Kalmanek further
`
`discloses that, “[i]f the originator of the call has specified caller-id blocking,
`
`the first parameter [of the CALLER field] will contain ‘anonymous.’” Ex.
`
`1004, 25:41–43. According to Petitioner, the terminating gate controller
`
`transmits the SETUP message to the terminating broadband telephony
`
`interface and filters the CALLER field of the signaling message based on
`
`whether caller ID services and caller ID blocking services have been
`
`invoked and authorized. Pet. 40–41 (citing Ex. 1003 ¶ 64). On this
`
`preliminary record, Kalmanek supports Petitioner’s contentions.
`
`b. Patent Owner’s Contentions
`
`
`
`Patent Owner argues that the gate controllers in Kalmanek do not
`
`intercept the call setup messages because the gate controllers are the
`
`intended recipients of the setup messages. Prelim. Resp. 7–10.
`
`
`
`Kalmanek discloses that signaling messages, including setup
`
`messages, are exchanged between the sender device and the intended
`
`recipient device, and may be sent through the gate controller: “Signaling
`
`messages are exchanged for a call between a calling party to a called party.
`
`A setup message for the call is exchanged through at least one gate
`
`controller.” Ex. 1004, 2:3–5; see also id. at 21:23–24 (explaining that
`
`“SETUP is the basic message sent by a BTI to initiate a connection to
`
`another endpoint” (emphasis added)). We additionally note that Kalmanek
`
`discusses the H.323 signaling architecture, and states that “the gatekeeper is
`
`not necessary within the H.323 standard.” Id. at 1:49–50. However, “when
`
`a gatekeeper is present in a network, network terminals must make use of its
`
`16
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`services” such that “all call signaling must pass through the gatekeepers.”
`
`Id. at 1:50–54 (emphasis added). Patent Owner’s argument is inconsistent
`
`with disclosure of Kalmanek and, therefore, is unpersuasive.
`
`
`
`Nor are we persuaded by Patent Owner’s citation to Kalmanek Figure
`
`3 as supporting its contention that Kalmanek’s gate controllers are the
`
`intended recipients of the setup messages. Prelim. Resp. 8. Figure 3
`
`“illustrates a flow chart for performing two-phase signaling in call
`
`connection, according to an embodiment of the present invention.” Ex.
`
`1004, 2:17–19 (emphasis added). Thus, Figure 3 illustrates how Kalmanek’s
`
`setup messages are passed through, or intercepted by, the gate controllers.
`
`At step 350, the setup message is received by the terminating telephone
`
`interface unit. Id. at Fig. 3, 13:27–29. Thus, Figure 3 supports Petitioner’s
`
`interpretation that “the ‘intended recipient device’ of a call setup signaling
`
`message is the device associated with the callee.” Pet. 24.
`
`
`
`Next, Patent Owner asserts that “[t]he claim language requires that the
`
`required ‘signaling message’ be between a sender and intended recipient.”
`
`Prelim. Resp. 11. Patent Owner argues that “Kalmanek’s ‘setup’ and/or
`
`‘GATESETUP’ messages are not sent by the sender to the ‘intended
`
`recipient device.’” Id.
`
`
`
`As explained above, Kalmanek’s setup messages are exchanged
`
`between the sender device and the intended (end) recipient device.
`
`Kalmanek discloses that “[t]he GATESETUP message is sent by the Gate
`
`Controller to the Edge Router” (Ex. 1004, 34:47–49), and, thus, we agree
`
`with Patent Owner that the GATESETUP message is not sent between the
`
`sender device and the intended recipient device. This is of no import,
`
`however, because Petitioner relies on Kalmanek’s SETUP message, not the
`
`17
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`GATESETUP message, to correspond to the recited “signaling message.”
`
`See Pet. 24–26. Petitioner refers to Kalmanek’s GATESETUP message to
`
`explain how the system implements the services (i.e., bandwidth) indicated
`
`by the setup message. See id. at 28–29.
`
`
`
`Next, Patent Owner argues that “the SETUP message of Kalmanek . . .
`
`fails to disclose the alleged ‘services’ in the SETUP message.” Prelim.
`
`Resp. 13. Regarding caller ID, Patent Owner argues that “Petitioner merely
`
`speculates that the SETUP message of Kalmanek could contain ‘caller-id
`
`blocking’, but neither Petitioner nor its expert provides any of the required
`
`evidence or explanation as to why a person of ordinary skill in the art at the
`
`time of the invention would modify Kalmanek as such.” Id. at 14–15.
`
`Continuing, Patent Owner argues that “Kalmanek itself states that ‘caller-id
`
`blocking’ is an inherent feature of the gate controllers in the Kalmanek
`
`system, and therefore ‘caller-id blocking’ is not part of the SETUP message
`
`of Kalmanek.” Id. at 15 (citing Ex. 1004 7:19–21).
`
`
`
`Kalmanek discloses that the CALLER portion of the SETUP message
`
`will contain an “anonymous” parameter if the originator has specified caller
`
`ID blocking. Ex. 1004, 25:25–43. Thus, Kalmanek discloses that the
`
`SETUP message includes an indication of caller ID blocking. Kalmanek,
`
`therefore, appears to contradict Patent Owner’s argument on this preliminary
`
`record. Additionally, the portion of Kalmanek cited by Patent Owner reads
`
`“[s]ervice features that depend on the privacy of the calling information,
`
`such as caller-ID blocking, are implemented by the gate controllers.” Ex.
`
`1004, 7:19–21 (emphasis added). This language indicates that gate
`
`controllers implement the caller ID blocking service, but does not support
`
`Patent Owner’s contention that the SETUP message does not include caller
`
`18
`
`
`
`IPR2018-00884
`Patent 8,539,552 B1
`
`ID blocking. Moreover, Patent Owner does not address Petitioner’s
`
`discussion of caller ID—as opposed to caller ID blocking—as corresponding
`
`to a service that the signaling message is intended to invoke.
`
`
`
`Regarding codec specification, Patent Owner argues that “the term
`
`‘codec’ never even appears once in Kalmanek” and that Kalmanek’s
`
`“CODING parameter is merely message originator encapsulation.” Prelim.
`
`Resp. 16–17 (citing Ex. 1004, 25:54–60; Ex. 2001 ¶¶ 45–46).
`
`
`
`The portion of Kalmanek reproduced by Patent Owner (see id. at 16)
`
`states that “CODING specifies a list of possible encapsulations and coding
`
`methods that the originator will perform.” Ex. 1004, 25:54–55 (emphasis
`
`added). Thus, Patent Owner’s argument that Kalmanek’s CODING
`
`parameter refers to “merely originator encapsulation” is in conflict with
`
`Kalmanek’s explicit disclosure that such parameter also refers to coding
`
`methods. Furthermore, the portion of Kalmanek reproduced by Patent
`
`Owner further explains that the CODING parameter includes a “third item
`
`[that] gives the coding algorithm.” Id. at 25:58–59. Patent Owner’s
`
`arguments fail to explain why Kalmanek’s indication of the coding
`
`algorithm does not qualify as the recited codec specification. See, e.g., Ex.
`
`1005, 1:19–25 (equating “coding algorithms” and “codec”).
`
`
`
`Finally, Patent Owner asserts that Petitioner’s failure to mention
`
`filtering of the codec specification equates to an admission that Kalmanek
`
`does not disclose codec specification as a type of service the signaling
`
`message is intended to invoke. Prelim. Resp. 19.
`
`
`
`This argument does not address Petitioner’s contentions regarding
`
`filtering of caller ID information, and, thus, fails to apprise us of error in
`
`Petitioner’s contentions.
`
`19