Opinion
2020-1403, 2020-1404
05-12-2021
UNILOC 2017 LLC, Appellant v. APPLE INC., Cross-Appellant Andrew Hirshfeld, Performing the Functions and Duties of the Under Secretary of Commerce for Intellectual Property and Director of the United States Patent and Trademark Office, Intervenor
Brian Matthew Koide, Etheridge Law Group, Southlake, TX, argued for appellant. Also represented by James Etheridge, Ryan S. Loveless, Brett Mangrum, Jeffrey A. Stephens. Kevin Scott Prussia, Wilmer Cutler Pickering Hale and Dorr LLP, Boston, MA, argued for cross-appellant. Also represented by Mark Christopher Fleming ; Cristina Salcedo, Los Angeles, CA. Mary L. Kelly, Office of the Solicitor, United States Patent and Trademark Office, Alexandria, VA, for intervenor. Also represented by Sarah E. Craven, Michael S. Forman, Daniel Kazhdan, Thomas W. Krause, Farheena Yasmeen Rasheed.
Brian Matthew Koide, Etheridge Law Group, Southlake, TX, argued for appellant. Also represented by James Etheridge, Ryan S. Loveless, Brett Mangrum, Jeffrey A. Stephens.
Kevin Scott Prussia, Wilmer Cutler Pickering Hale and Dorr LLP, Boston, MA, argued for cross-appellant. Also represented by Mark Christopher Fleming ; Cristina Salcedo, Los Angeles, CA.
Mary L. Kelly, Office of the Solicitor, United States Patent and Trademark Office, Alexandria, VA, for intervenor. Also represented by Sarah E. Craven, Michael S. Forman, Daniel Kazhdan, Thomas W. Krause, Farheena Yasmeen Rasheed.
Before Prost, Chief Judge, Bryson and Reyna, Circuit Judges.
Bryson, Circuit Judge.
Uniloc 2017 LLC appeals from a decision of the Patent Trial and Appeal Board in an inter partes review of Uniloc's U.S. Patent No. 8,539,552 ("the ’552 patent"). The Board held claims 1–17 and 23–25 of the ’552 patent invalid for obviousness in view of U.S. Patent No. 6,324,279 to Kalmanek et al. ("Kalmanek"). Uniloc argues that the Board's decision as to those claims resulted from an erroneous construction of a claim term. In its cross-appeal, Apple Inc. argues that the Board erred by holding that Apple failed to show that the remaining claims of the ’552 patent, claims 18–22, would have been obvious in view of Kalmanek. We affirm.
I
A
Modern telecommunications systems using Voice over Internet Protocol ("VoIP") offer clients various optional features, such as caller-ID, call waiting, multi-line service, and different levels of service quality known as the "codec specification." The ’552 patent is directed to a system and method to police the use of those features. ’552 patent, Abstract; id. at col. 13, ll. 66–67; id. at col. 18, ll. 17–31.
The patent recognizes that the proliferation of intelligent client devices in communication networks requires providers to maintain control over the use of their networks’ features in order to continue generating revenue. Id. at col. 1, ll. 31–55. To achieve that control, the patented system employs an enforcement mechanism within the provider's core network through which clients send "signaling messages" for setting up their communication sessions. Id. at col. 7, ll. 32–42. Because the enforcement point sits between the sender of the communication and the intended recipient, the provider can inspect the signaling messages sent between the two and ensure that both are authorized to use particular features. See id. at col. 7, line 53, through col. 8, line 11. The ’552 patent has five independent claims: claims 1, 6, 18, 23, and 24. Claim 1 recites the following:
A method for controlling a plurality of services in packet-based networks, the method comprising:
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, wherein the signaling message includes an indication of one type of the plurality of services which the signaling message is intended to invoke;
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, wherein the type of service comprises at least one of caller-ID, call waiting, multi-way calling, multi-line service, and codec specification; and
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.
Id. at col. 19, line 60, through col. 20, line 15.
The independent claims are similar in many respects. Each requires "determining" whether a client device is authorized to invoke or receive a particular service and "filtering" the signaling message based on that authorization. See, e.g. , id. at col. 22, ll. 34–54 (claim 24) (requiring that a "border element" transmit a signaling message "if either of the end devices associated with that SIP signaling message is authorized for a service"). In addition, claims 1, 6, 18, and 23 require "intercepting" the signaling message before the determining and filtering steps are completed. Claim 24 does not recite an intercepting step. See id. at col. 22, ll. 34–54.
Claims 1, 6, 23, and 24 require an authorization related to at least one service type. Claim 18 requires authorizations related to at least two service types. The services relevant to this appeal are caller-ID and codec specification.
Kalmanek discloses a system for exchanging signaling messages between a calling party and a called party, both of which are outside the direct control of the service provider. Kalmanek, col. 2, ll. 3–4; id. at col. 6, ll. 13–17. The signaling messages are routed through at least one "gate controller" that has access to authentication databases and customer profile information. Id. at col. 2, ll. 4–5; id. at col. 6, ll. 41–48. The gate controller can authenticate the identity of the calling party and authorize the service sought by the calling party. Id. at col. 6, ll. 49–55. Similar actions can be taken with respect to the called party. See, e.g. , id. at col. 56, ll. 17–25. The services covered by Kalmanek include caller-ID, see id. at col. 21, ll. 53–59, and enhanced levels of call quality, see id. at col. 3, ll. 60–64.
Across Kalmanek's various embodiments, the calling party is sometimes referred to as the originating broadband telephony interface ("BTIO") or the originating telephone interface unit ("TIUO"). See, e.g. , Kalmanek, col. 46, ll. 55–64. The called party is sometimes referred to as the terminating broadband telephony interface ("BTIT") or the terminating telephone interface unit ("TIUT"). See, e.g. , id. at col. 9, ll. 33–39.
Kalmanek divides its call network into two parts—the originating side and the terminating side. See id. at col. 5, ll. 54–67; see also id. at Figs. 1 and 6. There is a gate controller on the originating side (the "originating gate controller" or "GCO") and a gate controller on the terminating side ("terminating gate controller" or "GCT"). Id. at col. 9, ll. 33–39; id. at Fig. 1. To initiate a call, the calling party creates a message referred to as the "SETUP message." The calling party sends that message along a path, first to the originating gate controller, then to the terminating gate controller, and finally to the called party. See id. at col. 13, ll. 18–24. The called party responds by creating an acknowledgment message referred to as the "SETUPACK message." The called party sends that message along a return path, first to the terminating gate controller, then to the originating gate controller, and finally to the calling party. See id. at col. 13, ll. 33–41; see also id. at Fig. 6. The SETUP and SETUPACK messages contain various parameters pertaining to the call and the clients on the call; those parameters are summarized in columns 21 and 22 of Kalmanek.
B
In April 2018, Apple filed a petition for inter partes review, alleging that all 25 claims of the ’552 patent were unpatentable. Apple Inc. v. Uniloc 2017 LLC , No. IPR2018-00884, Petition at 1 (P.T.A.B.), 2018 WL 1875465 (filed Apr. 10, 2018) (" Petition for IPR "). Apple asserted that the "intercepting" term in the independent claims should be construed to mean "the signaling [message] is received by a network entity located between the endpoints of the call." Id. at 8. Uniloc disagreed, arguing that the term "intercepting" should be construed to exclude the receipt of a signaling message by the intended recipient of that message. Apple Inc. v. Uniloc 2017 LLC , No. IPR2018-00884, 2018 WL 3493937, Patent Owner's Preliminary Response at 4–6 (P.T.A.B.) (filed July 20, 2018).
Apple alleged that claim 1 would have been obvious over Kalmanek in view of the knowledge of a person of ordinary skill in the art of packet-based telecommunication systems. Petition for IPR , at 5, 18. For claim 1's intercepting step, Apple pointed to Kalmanek's description of the gate controller receiving the SETUP message on that message's path to the called party. See id. at 24–25 ; see also id. at 26. For claim 1's service-type limitation, Apple pointed to the caller-ID parameter in Kalmanek's SETUP and SETUPACK messages. Id. at 29–31. Apple identified the "CODING" parameter in the SETUP message as embodying a codec specification. Id. at 27–28.
The service-type limitation in claim 1 provides: "wherein the signaling message includes an indication of one type of the plurality of services which the signaling message is intended to invoke ... wherein the type of service comprises at least one of caller-ID, call waiting, multi-way calling, multi-line service, and codec specification."
For claim 1's step of determining an authorization relating to the service type, Apple pointed to Kalmanek's description of the originating and terminating gate controllers’ receipt of the SETUP and SETUPACK messages and verification of the caller-ID information in those messages. Id. at 34–36. Apple also alleged that Kalmanek "teaches that the gate controller determines if both the sender and recipient devices are authorized to invoke a codec specification." Id. at 36. Apple explained:
BTIO sends a SETUP message to GCOO that includes one or more requested coding algorithms, which correspond to a desired quality of service/bandwidth to be implemented by [the originating router]. ... After the SETUP message reaches the called party, the BTIT sends a SETUPACK message that includes an acceptable CODING parameter from those requested by the BTIO.... Kalmanek
further teaches that the service provider then authorizes the requested quality of service for the call. ... This authorization process is performed by the gate controllers utilizing the customer profile information.
Id. at 36–37.
For claim 1's filtering step, Apple asserted that Kalmanek's "network entity, namely GCT, filters the signaling message, including transmitting the SETUP message to BTIT, if BTIT has subscribed to the indicated service, namely caller ID indicated by the CID flag." Id. at 40–41. Apple made that assertion under a bolded section heading for claim 1's filtering step. See id. at 39–41. Apple did not, however, make an explicit assertion in that section that Kalmanek teaches the filtering step with respect to the codec service. See id.
With respect to claim 18, Apple incorporated by reference its mappings of Kalmanek to the various steps in claim 1. Id. at 51–53. For claim 18's filtering step, Apple incorporated by reference its allegations concerning claim 1's filtering step.
In its reply brief before the Board, Apple shifted positions regarding claim 18. As to the codec service, Apple argued that Kalmanek's gate controllers perform claim 18's determining-an-authorization step when they act on the SETUP message, not just when they act on the SETUPACK message. See, e.g. , Apple Inc. v. Uniloc 2017 LLC , No. IPR2018-00884, 2019 WL 1645897, Petitioner's Reply at 15–17 (P.T.A.B.) (filed Apr. 16, 2019). Apple also argued that Kalmanek teaches that the SETUP message is filtered with respect to the codec service because that message is forwarded unaltered to the called party following an authorization. Id. at 15.
In its final written decision, the Board construed the term "intercepting" to mean that "the signaling message is received by a network entity located between the endpoints of the call." Apple Inc. v. Uniloc 2017 LLC , No. IPR2018-00884, 2019 WL 4492895, at *5 (P.T.A.B. Sept. 18, 2019). The Board concluded that Kalmanek "explicitly discloses that the called party's device, not the gate controller, is the intended end recipient of the setup message" and that "Kalmanek's setup messages are passed through, or intercepted by, the gate controllers." Id. at *9. In view of its claim construction, the Board held all claims in the ’552 patent unpatentable except for claim 18 and its dependent claims.
With respect to claim 18 and its dependent claims, the Board ruled that Apple had not proved by a preponderance of the evidence that those claims were unpatentable. Id. at *16–18. The Board first noted that claim 18 and claim 1 require similar steps, but that claim 18 requires those steps to be completed with respect to two services, such as caller-ID and codec specification. Id. at *16. The Board then noted that Apple's petition had relied entirely on its allegations as to claim 1's filtering step when asserting that Kalmanek teaches claim 18's filtering step. Id. The Board reasoned that because Apple's allegations as to claim 1's filtering step did not address the codec service, Apple's petition failed to raise a viable invalidity theory against claim 18. Id. at *16–17. The Board rejected Apple's attempt in its reply brief to "re-characterize" its assertions in its petition concerning claim 18's filtering step. Id. at *17.
The Board further held that even if Apple had addressed the codec service in its allegations as to claim 18's filtering step, it would still lose on the merits. Id. at *17–18. That was because claim 18 requires that the step of determining whether a user is authorized to invoke or receive at least two services be performed in response to a single message, while Apple's petition relied on two separate messages in Kalmanek to perform the determining step. Id.
II
On appeal, Uniloc contends that the Board's construction of "intercepting" in the independent claims was erroneous and that the Board incorrectly held claims 1–17 and 23–25 invalid as a result. In its cross-appeal, Apple argues that the Board erroneously rejected its challenge to claims 18–22.
Uniloc also lodged a constitutional challenge to the Board's decision based on Arthrex, Inc. v. Smith & Nephew, Inc. , 941 F.3d 1320 (Fed. Cir. 2019). Uniloc has since withdrawn that challenge. See Dkt. No. 61, Uniloc 2017 LLC v. Apple, Inc. , No. 20-1403 (Fed. Cir. Feb. 16, 2021).
A
Uniloc argues that under the plain and ordinary meaning of "intercepting," the entity that "intercepts" a message cannot be an intended recipient of the message. To support that argument, Uniloc cites various dictionary definitions and relies on the following analogy: A player making an interception in football is not the intended receiver of the ball but instead seizes the ball on its way to the intended receiver. Uniloc contends that the Board's construction improperly permits the network entity intercepting the signaling message to be an intended recipient of the message even if there is an additional intended recipient downstream.
Uniloc is correct that the signaling message can have only one true "intended recipient," as the claims of the ’552 patent use that term. Claim 1 specifies that the intercepted signaling message is "associated with a call between a sender device of the message and an intended recipient device." Claim 1 later refers to "the intended recipient," making clear that the client device on the other end of the impending call is the one true "intended recipient."
However, just because the receiving client device is the ultimate "intended recipient" does not mean that the sending client device cannot intentionally direct the message to the intercepting entity. To the contrary, the patent contemplates that the sending client device will purposely direct the message through an intermediate recipient. For example, in one embodiment, the patent describes "a caller send[ing] an INVITE message to a callee by way of a proxy server," ’552 patent, col. 6, ll. 1–2 (emphasis added), where the proxy server effectively performs the intercepting, determining, and filtering steps recited by the claims, see id. at col. 6, ll. 17–25.
We hold that the claims encompass the situation in which a sending client device intentionally sends a signaling message to the intermediate network entity that performs the interception. Contrary to Uniloc's contention, that construction is not at odds with the plain meaning of the claims. The receiving client device is still "the intended recipient" of the message because it is the ultimate, intended destination of that message; the intermediate network entity is not "the intended recipient," even though it is intended to intercept the message on its way to the intended recipient. In that situation, "intercepting" retains a meaning distinct from merely "receiving." The network entity "intercepts" the message, rather than merely "receiving" the message, because the network entity sits between the two client devices and processes the message during its passage from its source to its ultimate destination.
The Board made a similar observation in its decision, concluding that "[b]y the language of claim 1, the recited ‘intended recipient device’ must be the called device, not an intermediate network entity." Apple , 2019 WL 4492895, at *5. Thus, any device sitting between the two end-clients cannot be "the intended recipient" of the signaling message, at least as the patent uses that term. See id. The Board concluded that "intercepting" means "the signaling message is received by a network entity located between the endpoints of the call." Id. at *5. That construction captures the idea that "intercepting" involves an entity, other than a client device, that receives and acts on the signaling message before it reaches its final destination.
The Board's construction is supported by the prosecution history of U.S. Patent Application No. 10/671,375 ("the ’375 application"), which matured into the ’552 patent. In a non-final office action dated March 31, 2011, the examiner rejected certain independent claims of the ’375 application based in part on U.S. Patent Publication No. 2003/0177363 to Yokota et al. ("Yokota"). At that time, "intercepting" was absent from the independent claims. See ’375 application, Response to Office Action dated June 24, 2011, at 2–8. Claim 1, for example, required "a network entity receiving a signaling message within a communication path between a sender device and an intended recipient device." See id. at 2 (emphasis added). To support the rejection, the examiner stated that Yokota teaches receiving a signaling message "within a communication path between a sender device and an intended recipient device." ’375 application, Non-Final Office Action dated March 31, 2011, at 2 (citing Yokota, ¶ 16).
As the applicants subsequently argued in their response to the March 31 office action, Yokota discloses a user sending a request for service (e.g., video or music) to a provider that verifies the authenticity of the request and provides the service to the user in response. Response to Office Action at 11–12. Thus, "Yokota never discloses an intermediate entity intercepting any communication between two other [user] devices, let alone a message associated with a call between two other devices." Id. at 12–13. "Instead, Yokota at best discloses a [provider] receiving a service request from the [user]. But this service request is sent from the [user] directly to the [provider], not to some other [user] apparatus." Id. at 13.
In their response to the office action, the applicants amended their claims by replacing the word "receiving" with "intercepting" and adding that the signaling message was "associated with a call" between two end users. Id. at 2. According to the applicants, the amendment was entered at the recommendation of the examiner to "overcome the art of record" by "clarify[ing] that the independent claims involve a network entity intercepting messages that are associated with a call between two end users ." Id. at 10. The applicants emphasized that their claims were now patentably distinguishable from Yokota because they "involve[d] a network entity receiving and filtering messages that are sent between two end users ." Id. at 9.
The prosecution history indicates that the relevant distinction between "receiving" and "intercepting" is that "intercepting" involves an entity other than a client device acting on the signaling message before it reaches its ultimate destination. The prosecution history thus supports the Board's construction of "intercepting" as meaning that a signaling message is received by a network entity located between the endpoints of the call. Like the Board, we arrive at that construction by focusing on the prosecution history, the specification, and the context of the particular claims in which the term "intercepting" appears. Those pieces of intrinsic evidence outweigh Uniloc's reliance on dictionary definitions, see Finisar Corp. v. DirecTV Grp., Inc. , 523 F.3d 1323, 1328 (Fed. Cir. 2008) ; analogies, see Driessen v. Sony Music Ent. , 640 F. App'x 892, 895 (Fed. Cir. 2016) ; and the purported plain meaning of "intercepting" in isolation, see Jansen v. Rexall Sundown, Inc. , 342 F.3d 1329, 1333 (Fed. Cir. 2003).
Uniloc also relies on statements from its expert witness, Dr. William C. Easttom, II, in support of its claim construction position. The Board, however, declined to credit that testimony over the intrinsic evidence in the record, both because Dr. Easttom failed to consider the full disclosure and prosecution history of the ’552 patent and because Uniloc hindered or prevented Apple from cross-examining him. See Apple , 2019 WL 4492895, at *5 n.9. We uphold the Board's decision not to give substantial weight to Dr. Easttom's declaration for those reasons.
Consistent with the Board's construction of "intercepting," Kalmanek discloses the "intercepting" limitation because it teaches that its gate controller receives a signaling message from one party to a call, wherein the message is intended for another party to the call. In particular, Kalmanek teaches that "[s]ignaling 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." Kalmanek, col. 2, ll. 2–5; see also id. at col. 13, ll. 8–29 ("FIG. 3 illustrates a flow chart for performing two-phase signaling in call connection .... At step 330, the originating TIU 170 sends a setup message to the originating gate controller 110.... At step 340, the setup message is forwarded from the originating gate controller 110 to the terminating gate controller 111. At step 350, the setup message is forwarded from the terminating gate controller 111 to the terminating TIU 171.").
We therefore affirm the Board's construction of "intercepting" and the Board's holding that claims 1–17 and 23–25 of the ’552 patent would have been obvious in view of Kalmanek.
B
On cross-appeal, Apple challenges the Board's holding that Apple failed to raise a viable invalidity theory as to claim 18. Apple also contends that its invalidity theory for claim 18 is correct on the merits and that the Board erred by holding that Apple failed to show that claim 18 would have been obvious over Kalmanek.
The Board held that Apple's petition failed to raise a viable invalidity theory against claim 18 because it relied entirely on its allegations as to claim 1's filtering step when asserting that Kalmanek teaches claim 18's filtering step. Apple , 2019 WL 4492895, *16–17. That was fatal, according to the Board, because claim 18 requires its filtering step to be performed in relation to at least two services (e.g., caller-ID and the codec specification), and Apple's allegations as to claim 1's filtering step were silent as to the codec specification, discussing only caller-ID. Id. Although Apple argued in reply that Kalmanek teaches filtering relating to the codec specification, the Board declined to credit that argument, viewing it as an improper attempt by Apple to re-characterize its petition. Id. at *17.
We find it unnecessary to reach the procedural issue of whether Apple raised a viable invalidity theory against claim 18 in its petition. That is because even assuming there was no defect in Apple's petition with respect to claim 18's filtering step, Apple would still lose on the merits of whether it showed that claim 18 would have been obvious in view of Kalmanek.
Apple acknowledged at oral argument that claim 18 prohibits two separate messages from satisfying the steps in that claim with respect to the caller-ID and codec services. That is, claim 18 does not permit one message to satisfy those steps with respect to caller-ID and another message to satisfy those steps with respect to codec.
In its petition, Apple identified two separate messages as satisfying the steps of claim 18. With respect to caller-ID, Apple identified the SETUP message as the message on which Kalmanek's gate controllers perform the intercepting and filtering steps. See Petition for IPR , at 21–26, 40–41, 52–53. With respect to codec specification, Apple identified the SETUPACK message as the message on which Kalmanek's gate controllers perform the step of determining an authorization. See id. at 36–37, 52.
To be sure, when discussing claim 18's determining step in its petition, Apple mentioned that the SETUP message "includes one or more requested [codec] algorithms" and that the SETUP message is sent to the originating gate controller. Id. at 36–37, 52. In that portion of Apple's petition, however, Apple was not asserting that the gate controllers’ handling of the SETUP message satisfies the determining step with respect to the codec specification. The sentences following the quoted portion of Apple's petition make clear that Apple understood that the gate controllers cannot determine an authorization regarding codec until after (1) the SETUP message has been delivered to the called party, (2) the called party selects a codec for the call, and (3) the called party sends the SETUPACK message. See id. at 37 ("After the SETUP message reaches the called party, the [called party] sends a SETUPACK message that includes an acceptable CODING parameter from those requested by the [calling party]. ... Kalmanek further teaches that the service provider then authorizes the requested quality of service for the call." (emphasis added)).
Apple suggests that the Board interpreted that portion of its petition differently. Apple points to the following statement in the Board's decision: "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." Apple , 2019 WL 4492895, *11 (citing Petition for IPR , at 36–38 ). According to Apple, that statement reflects that the Board endorsed Apple's theory that the gate controller's handling of the SETUP message satisfies the step of determining an authorization relating to codec specification.
We disagree. As a preliminary matter, in the cited passage the Board was merely recounting Apple's assertions, not endorsing them. See id. Moreover, the most reasonable reading of pages 36 through 38 of Apple's petition is that the gate controllers of Kalmanek cannot determine an authorization of codec level using just the SETUP message. Supporting that interpretation is Apple's statement in that section of its petition that "the [called party] sends a SETUPACK message that includes an acceptable CODING parameter," followed by the statement that the "service provider then authorizes the requested quality of service for the call." Petition for IPR , at 37 (emphasis added).
Apple also argues that other sections of its petition asserted that Kalmanek's gate controllers perform claim 18's determining step on the SETUP message in relation to codec specification. Specifically, Apple points to its allegations concerning the service-type limitation in claim 1, id. at 27–29, which Apple cross-referenced in its allegations concerning the service-type limitation in claim 18, id. at 52. Concerning claim 1's service-type limitation, Apple stated in its petition that "Kalmanek teaches that the gate controller receives the setup message ([Kalmanek, col. 9, ll. 40–43]), authorizes a quality of service for the call using authentication databases and customer profile information ([id. at col. 10, ll. 13–19]), and sets up a gate at the edge router based on the authorized quality of service." Petition for IPR , at 29.
We first note that the above statement is from the portion of Apple's petition addressing the service-type limitation, not the determining step. Setting that aside, we find nothing in Kalmanek that supports Apple's argument. Column 10, lines 13 through 19 of Kalmanek generally describe the process of verifying that "the quality of service desired by a [called or calling party] is no greater than the quality of service authorized by the corresponding gate controller," and the function of the gate controller in accomplishing that authorization using "authentication databases and customer profile information."
That passage does not describe when the authorization is performed. Nor does it connect that authorization to the SETUP message. On the contrary, that passage follows directly after Kalmanek's discussion of the "reservation process." Kalmanek, col. 10, ll. 6–13. In "step 240" of that reservation process, "a reserve message is sent from the [calling party] to the originating NED 120." Id. And in "step 250," "a reserve message is sent from the [called party] to the terminating NED 121." Id. As step 210 of Figure 2 makes clear, those "reservation message[s]" are distinct from the SETUP message, undercutting Apple's reliance on column 10 of Kalmanek. See id. at col. 9, ll. 40–50.
Beyond that, the premise of Apple's statement is incorrect. As the Board explained, "the determination of what codec is authorized [in Kalmanek] is made by the [called party] rather than the [gate controllers], and the determination is made after the SETUP message has already been forwarded to the [called party]." Apple , 2019 WL 4492895, *17. Hence, Kalmanek does not disclose that the originating gate controller determines an authorization regarding codec when receiving the SETUP message, because when the gate controller receives the SETUP message for a particular call, a codec has yet to be selected for that call. See Kalmanek, col. 22, ll. 25–53 ("[SETUP message] CODING specifies a list of possible encapsulations and coding methods that the originator will perform. ... [SETUPACK message] CODING gives the single encapsulation and coding method, of the choices presented in the SETUP message, that is acceptable to the destination BTI.").
Even if it were possible for the originating gate controller to anticipate which codec will be used before the called party selects a codec, such as if the calling party's list of codecs contains only one option, see id. at col. 21, l. 29, there is no discussion in Kalmanek regarding how the gate controller would use that information to provision bandwidth and/or regulate call quality before the SETUPACK message has been sent by the called party. Portions of Kalmanek that discuss the provisioning of bandwidth and regulation of call quality describe those actions as occurring after the SETUPACK message has been sent by the called party, and thus well after the SETUP message has passed through the gate controllers. See, e.g. , id. at col. 13, ll. 18–47 ("At step 330, the originating TIU 170 sends a setup message to the originating gate controller 110.... At step 350, the setup message is forwarded from the terminating gate controller 111 to the terminating TIU 171.... At step 360, ... a setup acknowledgment message is sent to the TIU 170.... At step 370, the network resources for the call are reserved. ... [A] reserve message is sent from the originating TIU 170 to the originating NED 120 and from the terminating TIU 170 to the terminating NED 121 ...."); id. at col. 28, ll. 2–12 ("The RESERVE message is sent by the BTI in the first stage of resource allocation. ... BANDWIDTH is the specification of the actual bandwidth desired at this time.").
Apple asserted an alternative obviousness theory in its petition, contending that it would have been obvious for a person of ordinary skill to modify Kalmanek's system such that its gate controllers would determine authorizations of codec levels for the calling party and the called party. See Petition for IPR , at 38. On appeal, Apple has not argued that the Board erred in its consideration of that alternative theory, and Apple has not advanced the substance of that theory in its briefing.
--------
We conclude, therefore, that Apple's petition fails to establish that Kalmanek renders claim 18 obvious because Apple pointed to—and could only point to—both the SETUP and SETUPACK messages in Kalmanek when alleging invalidity of claim 18 of the ’552 patent. The Board came to the same conclusion, reasoning that Apple's allegations with respect to claim 18 were insufficient because Apple asserted that "the gate controllers authorize the codec specified in the SETUPACK message" but separately asserted that "the message " for purposes of claim 18's filtering step was "the initial SETUP message." Apple , 2019 WL 4492895, *18. That conclusion was not erroneous.
III
We affirm the Board's construction of "intercepting" and the Board's related holding that claims 1–17 and 23–25 of the ’552 patent are unpatentable. We also affirm the Board's holding that Apple failed to demonstrate by a preponderance of the evidence that claims 18–22 are unpatentable.
AFFIRMED
COSTS
No costs.