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.
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.
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,
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 "GC
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, 2018 WL 1875465, Petition at 1 (P.T.A.B.) (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,
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:
Id. at 36-37.
For claim 1's filtering step, Apple asserted that Kalmanek's "network entity, namely GC
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
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.
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
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
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.
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
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
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
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.
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.