This Order presents the Court's construction of the parties' disputed claim terms. The Court has reviewed the Joint Claim Construction and Prehearing Statement (dkt. no. 297), the Joint Amended Exhibit A to the prehearing statement (dkt. no. 351), and the parties' claim construction briefs (dkt. nos. 353, 354, 356, 376, 378). The parties presented a technology tutorial to the Court on August 15, 2014, in preparation for a Markman hearing held on August 20 and 21, 2014. (Dkt. nos. 388, 393, 394.)

The Markman hearing transcripts are filed as dkt. nos. 428 and 429.

II. BACKGROUND

Plaintiff Unwired Planet, LLC ("Unwired") initiated this action in September 2012, alleging that Defendant Google Inc. ("Google") infringed on ten patents. (Dkt. no. 1 at 5-7.) Unwired has since elected to assert thirty-two claims across seven patents. (See dkt. no. 296 at 2.) In January 2014, the Court stayed discovery and case management deadlines for two of those patents (U.S. Patent Nos. 7,204,205 and 7,463,151) pending review by the U.S. Patent and Trademark Office. (See dkt. no. 233 at 7-12; dkt. no. 380; dkt. no. 439.) In the remaining five patents that Unwired has elected to assert, the parties dispute the construction of twenty-three terms. (See dkt. no. 297; dkt. no. 351-1.) Unwired contends that eleven terms do not need construction because their plain meaning should control, but proposes alternative constructions for several of those terms. (See dkt. no. 351-1; dkt. no. 353.) Google argues that each of the disputed terms must be construed because even if the terms have plain meanings, the parties dispute their scope and import. (Dkt. no. 378 at 6-7.)

The stay also covers U.S. Patent No. 7,203,752. (See dkt. no. 205 at 6; dkt. no. 233 at 12.) This patent, however, was not included in Unwired's May 2014 election of claims. (See dkt. no. 296.)

Initially, the parties' amended Joint Claim Construction and Prehearing Statement listed twenty-five disputed claim terms. (Dkt. no. 351-1.) During the Markman hearing, the parties agreed that the Court's construction of "proxy server" would control the construction of "proxy server module." (Tr. at 23:25-24:9, 65:13-16.) In light of this agreement, and because the parties agreed to a construction of "image" (dkt. no. 404 at 2), twenty-three terms remain in dispute.

For some terms, Unwired proposed a construction for the first time at the Markman hearing.

The five patents at issue are: (1) U.S. Patent No. 6,292,657 ("'657"), (2) U.S. Patent No. 6,895,240 ("'240"), (3) U.S. Patent No. 6,944,760 ("'760"), (4) U.S. Patent No. 6,684,087 ("'087"), and (5) U.S. Patent No. 6,662,016 ("'016"). The parties agree that the '657 Patent and the '240 Patent (together the "Fleet Patents") share the same specification because the '240 Patent is a continuation of the '657 Patent. (Dkt. no. 297 at 2.) The Court considers disputed terms in the Fleet Patents together. Disputed terms in the remaining three patents are considered in turn.

The patents are filed with the parties' opening claim construction briefs. (See dkt.
nos. 3532 to 3536; dkt. nos. 3545 to 3549.)

III. LEGAL STANDARD

Patent claim construction is a question of law for the court. Markman v. Westview Instruments, Inc., 517 U.S. 370, 372 (1996). When interpreting claims, a court's primary focus should be on the intrinsic evidence of record, which consists of the claims, the specification, and the prosecution history. Phillips v. AWH Corp., 415 F.3d 1303, 1314-17 (Fed. Cir. 2005) (en banc). The court should begin by examining the claim language. Id. at 1312. Claim language should be viewed through the lens of a person of "ordinary skill in the relevant art at the time of the invention." SanDisk Corp. v. Memorex Prods., Inc., 415 F.3d 1278, 1283 (Fed. Cir. 2005). If the claim language is clear on its face, then consideration of the other intrinsic evidence is limited "to determining if a deviation from the clear language of the claims is specified." Interactive Gift Express, Inc. v. Compuserve Inc., 256 F.3d 1323, 1331 (Fed. Cir. 2001).

A court should give the claim's words their "ordinary and customary meaning." Phillips, 415 F.3d at 1312-13 (citation and internal quotation marks omitted). In construing a claim term's ordinary meaning, the context in which a term is used must be considered. ACTV, Inc. v. Walt Disney Co., 346 F.3d 1082, 1088 (Fed. Cir. 2003). Both asserted and unasserted claims of the patent can add meaning to claim terms, which are normally used consistently throughout the patent. Phillips, 415 F.3d at 1314. But where a "term has more than one 'ordinary' meaning or when reliance on a term's 'ordinary' meaning does not resolve the parties dispute," determining that "a claim term 'needs no construction' or has the 'plain and ordinary meaning' may be inadequate." O2 Micro Int'l Ltd. v. Beyond Innovation Tech. Co., 521 F.3d 1351, 1361 (Fed. Cir. 2008). Even if a claim term has a "well-understood definition," a court may construe the term if the parties dispute its scope. Id.

Additionally, "claims must be read in view of the specification, of which they are a part." Phillips, 415 F.3d at 1315 (citation and internal quotation marks omitted). The specification can offer "practically incontrovertible directions about claim meaning." Abbott Labs. v. Sandoz, Inc., 566 F.3d 1282, 1288 (Fed. Cir. 2009). The patentee may act as its own "lexicographer and give a specialized definition of claim terms" either explicitly or implicitly, in which case the specification acts as a dictionary for the patent. Id.; see also Phillips, 415 F.3d at 1321. "Likewise, inventors and applicants may intentionally disclaim, or disavow, subject matter that would otherwise fall within the scope of the claim." Abbott Labs., 566 F.3d at 1288.

"When consulting the specification to clarify the meaning of claim terms, courts must take care not to import limitations into the claims from the specification." Id. "[A]lthough the specification may well indicate that certain embodiments are preferred, particular embodiments appearing in the specification will not be read into claims when the claim language is broader than such embodiments." Tate Access Floors, Inc. v. Maxcess Techs., Inc., 222 F.3d 958, 966 (Fed. Cir. 2000) (citation and internal quotation marks omitted). "By the same token, the claims cannot enlarge what is patented beyond what the inventor has described in the invention." Abbott Labs., 566 F.3d at 1288 (citation and internal quotation marks omitted).

In addition to the specification, a court also should consider the patent's prosecution history, which consists of "the complete record of the proceedings before the PTO and includes the prior art cited during the examination of the patent." Phillips, 415 F.3d at 1317. However, because the prosecution represents an "ongoing negotiation" rather than the "final product" of the negotiation, "it often lacks the clarity of the specification and thus is less useful for claim construction purposes." Id. Consulting the prosecution history can, however, be helpful in determining whether the patentee disclaimed an interpretation during prosecution. Research Plastics, Inc. v. Fed. Packaging Corp., 421 F.3d 1290, 1296 (Fed. Cir. 2005). "Under the doctrine of prosecution disclaimer, a patentee may limit the meaning of a claim term by making a clear and unmistakable disavowal of scope during prosecution." Purdue Pharma L.P. v. Endo Pharm. Inc., 438 F.3d 1123, 1136 (Fed. Cir. 2006).

If the claim language is not clear after reviewing all intrinsic evidence, then the Court may refer to extrinsic evidence such as expert testimony, inventor testimony, dictionaries, or treatises. See Phillips, 415 F.3d at 1317-19. "Relying on extrinsic evidence to construe a claim is proper only when the claim language remains genuinely ambiguous after consideration of the intrinsic evidence. Such instances will rarely, if ever, occur." Interactive Gift Exp., Inc., 256 F.3d at 1332 (citation and internal quotation marks omitted).

IV. DISCUSSION

A. Agreed Constructions

Before claim construction briefing and the Markman hearing, the parties agreed to construe two formerly disputed claim terms that appear in the '087 Patent. First, the parties agree to construe "the reduced image transformed from the image with respect to a set of parameters associated with the screen" as "the reduced image modified from the image, at least with respect to parameters describing the mobile device's screen." (Dkt. no. 297 at 2.) Second, the parties agree to construe "fetch[ing] the image . . . according to a request from the mobile device" as "fetch[ing] the image . . . in response to a request from the mobile device." (Dkt. no. 351 at 2.) The Court adopts both constructions.

Additionally, after the Markman hearing, the parties agreed to the following construction of the disputed claim term of "image": "a stored description of a graphic picture." (Dkt. no. 404 at 2.) This construction resolves the parties' dispute over how an image must be stored, and whether raw data may be an image — the construction does not exclude certain forms of stored images, nor does the construction allow raw data to be construed as an image. The Court adopts the parties' construction.

B. '657 and '240 Patents (Fleet Patents)

The Fleet Patents disclose technology that allows an entity to disseminate information to a group of mobile devices. Although their claims differ, the patents share a specification. The following disputed terms appear in asserted Claim 16 of the '657 Patent and in asserted Claims 1, 2, 3, 5, 6, 13, 15, 16, 17, 18, 27, 28, and 30 of the '240 Patent. The Court cites to the '657 Patent in referencing the specification.

1. "Proxy server" and "Proxy server module"

Unwired's Revised Proposed Construction	Google's Proposed Construction
"a computer that enables communication between two networks" or "a bridge that enables communication between two networks" (Tr. at 70:22-71:1)	"a computer that performs mapping or translation functions to enable communication between two networks that could otherwise not communicate"

Unwired indicated it would agree to this construction, which the Court proposed during the Markman hearing. Initially, Unwired proposed: "server(s) that allow communication between a mobile station and a landnet." (Dkt. no. 351-1 at 7.) The Court's proposal attempted to bridge the parties' proposed constructions, taking into account the relevant claims and the specification, which discus the proxy server's function in enabling communication between two networks. See, e.g., '240 Claim 1; '657 at Fig. 1.

During the Markman hearing, the parties agreed that the Court's construction of "proxy server" would dictate its construction of "proxy server module." (Tr. at 24:1-9; 65:13-16.) The following analysis focuses on "proxy server," but applies to both terms.

"Proxy server" appears in Claims 1, 5-6, 13, 15, and 18 of the '240 Patent. According to one embodiment, the proxy server sits between a "landnet" (such as the Internet) and an "airnet" (such as a wireless network). See '657:5:27-31; see also id. at 4:35-37 (defining landnet); id. at 5:5-8 (describing airnet). The parties dispute two aspects of the term. First, Google contends that a proxy server must perform mapping or translation functions, whereas Unwired argues that the server need only enable communication. Second, Google argues that the proxy server interacts with networks that cannot communicate with each other, while Unwired contends that they may. More broadly, Unwired accuses Google of unnecessarily limiting the term by referencing a preferred embodiment and citing extrinsic evidence. Unwired also argues that Google's proposal violates the doctrine of claim differentiation because it reads limitations that appear in dependent claims into an independent claim. See Phillips, 415 F.3d at 1314-15 ("[T]he presence of a dependent claim that adds a particular limitation gives rise to a presumption that the limitation in question is not present in the independent claim."); (see also dkt. no. 353 at 19-20 (citing '240 Claim 7 and '657 Claim 2)). Google contends that Unwired's proposal impermissibly broadens the term. The Court agrees and adopts Google's proposed construction.

The intrinsic evidence suggests that Unwired's proposed construction broadens the term beyond the relevant claims by failing to account for the "proxy" functions the proxy server performs. Claim 1 of the '240 Patent, for example, describes "a proxy server coupled to a wireless network, to enable a plurality of mobile stations on the wireless network to communicate with processing systems on the landnet." '240:13:49-52. Unwired's revised proposal seems to restate the proxy server's enabling function described in Claim 1, but drops any description of why or how the enabling function is carried out. Unwired assumes that a reference in the specification to "traditional server processing" suffices to define the functions that its proposed construction omits. (See Tr. at 30:21-31:20 (citing '657:8:44-54).) In asserting that its proposed construction implicitly encompasses "traditional server processing," however, Unwired fails to explain what "proxy" means in the context of the disputed term. Unwired insists that that the difference between a proxy server and a traditional server is that the proxy server enables communication, performs traditional server functions, and may — but need not — perform mapping or translation functions. (See Tr. at 41:6-14, 42:1-11.)

This argument hinges on the assumption that the networks linked by a proxy server may communicate without mapping or translation. Unwired relies on a reference in the specification to "Cellular Digital Packet Data (CDPD)" to support this argument, contending that CDPD wireless networks may communicate with the Internet. (See Tr. at 26:16-27:13 (citing '657:8:39-43).) But aside from its attorneys' arguments, it is not clear that CDPD, as described in the Fleet Patents, could facilitate communication between an airnet and a landnet absent mapping or translation.

Unwired additionally cites to the '087 Patent and the '760 Patent to argue that at the time the Fleet Patents were filed, available technology allowed wireless networks to use the same communication protocol as the landnet. (Tr. at 25:9-26:15.) Both the '087 Patent and the '760 Patent were filed after the July 1998 filing date of the '657 Patent. Thus, although these references suggest that the same communication protocols for the airnet and landnet existed after the first Fleet Patent was filed, they do not clarify the ordinary meaning of "proxy server" as it appears in the Fleet Patents.

Google's proposal, on the other hand, clarifies how and why the proxy server enables communication between two networks. Google's proposal accounts for the specification's description of a proxy server, which notes that "[g]enerally, the communication protocol in airnet 102 is different from that in landnet 100," and, "[h]ence, one of the functions proxy server 114 performs is to map or translate one communication protocol to another." '657:5:32-35. When read in sequence, these sentences suggest that the proxy server must perform mapping or translation to facilitate communication between the airnet and the landnet. The specification further states that "[s]erver module 226," a component of a proxy server, "performs traditional server processing as well as protocol conversion processing from one communication protocol to another communication protocol." Id. at 8:44-46. Considered alongside the former excerpt, this latter language indicates that a proxy server may perform other functions in addition to the mapping or translation described above. By defining the proxy server's functions to include mapping or translating, but not to exclude other functions, Google's construction encompasses both descriptions in the specification.

Unwired analogizes Google's proposed construction to a term disputed in Acumed LLC v. Stryker Corp., 483 F.3d 800, 807-09 (Fed. Cir. 2007), where the Federal Circuit rejected the defendant's attempt to limit the term using a preferred embodiment. In affirming the district court's construction, the Acumed court reasoned that the claim term — "transverse holes" — was broader than the defendant's proposed construction, which sought to limit the term to holes appearing at a right angle. Id. at 807-08. The court noted that "the plain meaning of Claim 1 covers more than the particular embodiment" at issue because the term "transverse" "does not necessarily imply right angles." Id. at 807. Although the specification consistently and exclusively referred to transverse holes as perpendicular to another element of the invention, the court concluded that qualifying the holes as perpendicular would impermissibly narrow the claim term. Id. at 808-09.

Here, the plain meaning of "proxy server" is not clear from the face of the claims. The claims state that the proxy server enables communication, pushes fleet data, or performs both functions. See '240 Claims 1, 4-6, 12, 15, 20-21, 26, 29. Google's proposed construction defines the actions required to carry out those functions. Whereas the term "transverse holes" encompassed more orientations than right angles, here, it is not clear which functions a proxy server must perform to enable communication. See Acumed, 483 F.3d at 807-08. Unwired is correct that Google cites passages describing preferred embodiments — a practice the Acumed court admonished — but, in light of the claims' ambiguity, the Court cannot construe this term without considering the specification. See id. at 808. As noted above, the specification describes mapping or translating as functions carried out by the proxy server in enabling communication. Accordingly, Google's proposed construction does not import limitations from the specification into the claim term; rather, it properly reads the claims "in view of the specification, of which they are a part." Phillips, 415 F.3d at 1315 (citation and internal quotation marks omitted).

Nor does Google's proposal exclude a preferred embodiment. Unwired stresses language in the specification stating that the landnet and the airnet "generally" have different communication protocols. See '657:5:32-33. Unwired reads this language as indicating that the landnet and the airnet may share a communication protocol, an embodiment that would be excluded by Google's construction. But, as discussed above, the next sentence states: "[h]ence, one of the functions proxy server 114 performs is to map or translate one communication protocol to another." Id. at 5:34-38. The specification suggests that even if the landnet and airnet have the same communication protocol, the proxy server enables communication between the two through mapping or translation. This embodiment is encompassed in Google's construction.

Finally, the Court finds Unwired's claim differentiation arguments unavailing. The claim differentiation doctrine dictates that "the presence of a dependent claim that adds a particular limitation raises a presumption that the limitation in question is not found in the independent claim." Liebel-Flarsheim Co. v. Medrad, Inc., 358 F.3d 898, 910 (Fed. Cir. 2004). This presumption "is at its strongest" where "the limitation that is sought to be 'read into' an independent claim already appears in a dependent claim." Id. Unwired identifies Claims 4 and 7 of the '240 Patent as examples of dependent claims that Google reads into independent Claim 1. (Tr. at 38:4-39:10.)

Claim 4 refers to the system noted in Claim 1, but specifies that "the proxy server communicates with the mobile stations over the wireless network using a first communication protocol, and the fleet server communicates with the proxy server using a second communication protocol." '240 Claim 4. Unwired argues that Claim 4 narrows Claim 1 to a system involving two different communication protocols, which Google weaves into its proposed construction. Google's proposal, however, only specifies that the proxy server enables communication between "two networks that could not otherwise communicate" — the construction leaves open the specific communication protocols required of each network. Claim 4 limits each network to only one communication protocol, a limitation that is absent from Google's proposed construction.

Claim 7 builds on Claim 4 by requiring a proxy server to comprise a "mapper to perform protocol mapping from the first communication protocol to the second communication protocol" and vice versa. '240 Claim 7. Unwired contends that by defining a proxy server as performing mapping or translation, Google reads Claim 7's limitation into Claim 1. As with Claim 4, Google's construction does not render Claim 7 superfluous — it says nothing about a mapper or protocol mapping. The specification describes a mapper as "a separate module" able to perform "protocol conversion processing." '657:8:47-51. Moreover, Google acknowledges that, under its proposed construction, the proxy server may perform mapping other than protocol mapping. (Dkt. no. 378 at 12.) The Court finds that claim differentiation does not bar Google's proposed construction because both Claim 4 and Claim 7 would further narrow it.

The Court construes "proxy server" as "a computer that performs mapping or translation functions to enable communication between two networks that could otherwise not communicate." The Court further construes "proxy server module" as "a module that performs mapping or translation functions to enable communication between two networks that could not otherwise communicate."

2. "Challenge response"

Unwired's Proposed Construction	Google's Proposed Construction
"security prompt to authorize the provisioning entity"	"a message requiring the provisioning entity to enter identification establishing the provisioning entity's authorization to access the fleet managing system/fleet server"

This dispute centers on the type of information a provisioning entity must provide to a challenge response, and whether the term describes what a provisioning entity may access upon obtaining authorization. Google argues that in both the claims and the specification, a challenge response requires a provisioning entity to identify itself. Google further contends that the intrinsic evidence defines that a provisioning entity may access a fleet managing system and fleet server after receiving authorization through a challenge response. Because Unwired's proposed construction omits these details, Google argues that it impermissibly broadens the claim term. Unwired objects to Google's proposal because it unnecessarily defines — and renders superfluous — terms found elsewhere in the claims, limits the scope of the disputed term, and risks jury confusion. The Court disagrees and adopts Google's proposal.

The disputed term appears in Claim 16 of the '657 Patent and Claims 2, 16, and 30 of the '240 Patent. Broadly, these claims describe a challenge response as a mechanism to provide authorization to a provisioning entity. See '657 Claim 16 ("accessing said fleet managing system by supplying correct credential information to said challenge response"); '240 Claims 2, 16 ("the fleet server prompting the provisioning entity with a challenge response for credential information"); id. at Claim 30 (claiming an authenticating method that involves "sending a challenge response" and "allowing the provisioning entity to access the fleet managing system" upon "receiving correct credential information from the provisioning entity responsive to the challenge response"). Unwired acknowledged during the Markman hearing that both parties' proposals account for this basic function. (See Tr. at 71:25-72:8.)

Unwired argues, however, that it is improper to define what authorization provided by a challenge response allows a provisioning entity to do because this construction would render other claim terms superfluous. Claim 16 in the '657 Patent and Claim 30 in the '240 Patent disclose that such authorization provides access to the fleet managing system or fleet server as part of a process to push data to mobile devices. Claims 2 and 16 in the '240 Patent do not describe access, but rather disclose scenarios where a provisioning entity is "coupled directly" to a fleet server, and where the fleet server prompts the provisioning entity with a challenge response. The independent claims to which Claims 2 and 16 correspond — Claims 1 and 15, respectively — both disclose mechanisms for pushing data to mobile devices. Together, these claims suggest that authorization allows access to the fleet managing system or fleet server. Rather than render these claims superfluous, Google's construction clarifies how the challenge response fits within the processes they describe.

The Court finds Unwired's reliance on Digital-Vending Services International, LLC v. University of Phoenix, Inc, 672 F.3d 1270 (Fed. Cir. 2012), to be misplaced. There, the district court construed a "registration server" as being free of certain content. Id. at 1274. But because several asserted claims explicitly described a "registration server" as "being further characterized in that it is free of content managed by the architecture," the Federal Circuit refused to read that limitation into the disputed term. Id. at 1274-75, 1277. Here, conversely, the claims do not "further characterize[]" a challenge response. Instead, they disclose that the challenge response authorizes access to the fleet server for fleet managing system.

The parties' remaining dispute involves the information that must be provided to a challenge response. The specification indicates that a challenge response verifies a provisioning entity's identity. The invention's abstract, for instance, states that "access to the fleet managing system is guarded with a challenge response every time there is a request arriving at the system." '657 Abstract. The embodiments similarly depict a provisioning entity that prompts a challenge response by requesting to send fleet data. See id. at 7:24-33, 11:37-45. The specification further offers a "username or a password" as an exemplary prompt from and answer to a challenge response. Id. at 11:37-43; see also id. at 7:38-42. These descriptions suggest that a person of ordinary skill in the art would understand the challenge response as a mechanism to verify the identity of an entity requesting to send information. (See also dkt. no. 354-1 ¶ 48 (extrinsic expert testimony suggesting that, as used in the Fleet Patents, challenge response "means a response that is generated by the fleet managing system to a request to push fleet data that requires the provisioning entity to identify itself and establish its authorization to access the fleet server").)

Unwired contends that the phrase "security prompt" captures the disputed term's breadth because the specification notes several types of information that may be used to respond to a challenge response. Unwired is correct that in addition to a username and password, the specification describes special codes, device IDs, and encryption keys. These references, however, describe authentication processes that do not involve a challenge response. See, e.g., '657:9:29-33 (a special code may transform a mobile station into a mobile station manager terminal capable of pushing fleet data); id. at 10:51-55 (a special code allows a mobile station to request to push fleet data); id. at 10:63-11:5 (device ID authorizes a commanding mobile station); id. at 11:5-10 (encryption keys are exchanged between a commanding mobile station and a proxy server to establish a secure communication session). Unwired's citations to the specification do not support its broad proposed construction. Based on the intrinsic evidence, the Court adopts Google's proposed construction.

3. "Fleet data"

Unwired's Revised Proposed Construction	Google's Revised Proposed Construction
"mobile data for distribution or transmission to a set of mobile stations" (Tr. at 93:10-14)	"mobile data for distribution or transmission to a selective set of mobile stations" (Tr. at 95:11-18)

Prior to the Markman hearing, the parties approached this construction with different focuses: Unwired's proposal described types of fleet data, while Google defined the fleet to which fleet data is transmitted. Drawing on both parties' constructions, as well as the intrinsic evidence, the Court offered "mobile data for distribution or transmission to a set of mobile stations" as a compromise construction. (Tr. at 92:22-24); Although both parties agreed to this revision, they continue to dispute whether fleet data involves a "set" or a "selective set" of mobile stations.

Initially, Unwired proposed: "mobile data, including messages or other information for distribution, such as alphanumeric messages and promotion information." (Dkt. no. 351-1 at 3.) Google offered "mobile data shared by and transportable to a selective set of mobile stations or devices." (Id.)

The Court finds that including "selective set" in its construction is appropriate. The Court's revised construction is based on the specification, which explains that because "the present invention concerns" information delivery "to a selective set of mobile stations or devices," fleet data "means mobile data or information transportable in the secure communication system." '657:4:49-53; see also id. at 1:8-11 (the invention "relates to a method and architecture for managing a selective set of mobile devices or stations via secure communication systems"). The specification also notes that "the selective set of mobile stations is sometimes referred to as a fleet of mobile stations sharing the same fleet data." Id. at 4:53-55. Because the specification describes the invention as involving a selective set of mobile stations and equates a selective set with a fleet of mobile stations, the Court construes the "fleet data" as "mobile data for distribution or transmission to a selective set of mobile stations."

During the Markman hearing, Unwired indicated that it did not find "selective set" to be "necessarily problematic." (Tr. at 96:17.) To the extent Unwired objects to this construction, the Court disagrees with its arguments about claim differentiation and juror confusion. (Dkt. no. 353 at 14; Tr. at 96:19-97:1) Unwired contends that dependent Claim 25 of the '657 Patent describes a process for grouping mobile stations, reading "group" as synonymous with "selective set." (Dkt. no. 353 at 14.) Claim 25, however, discloses a method of "determining the plurality of mobile stations" by grouping them using an identification and associating fleet data with that group. '657 Claim 25. While the Court's construction includes "selective set," it says nothing about how a group of mobile stations is determined. Claim 25 is not rendered superfluous by — and claim differentiation should not bar — the Court's construction.

4. "Cause said fleet data pushed by said proxy server module to the plurality of mobile stations"

Unwired's Proposed Construction	Google's Proposed Construction
"cause the fleet data to be pushed by the proxy server module to the plurality of mobile stations"	Indefinite

This dispute turns on the Court's power to correct an error in the claim term, and the term's alleged indefiniteness. Claim 16 of the '657 Patent discloses "[a] method for securely managing a plurality of mobile stations serviced by a carrier infrastructure." The error appears in Claim 16's last clause, which provides: "executing said request to cause said fleet data pushed by said proxy server module to the plurality of the mobile stations." '657:15:29-31. Characterizing the error as "obvious, administrative," "inadvertent [and] typographical" (dkt. no. 353 at 21), Unwired argues that the Court may correct it by adding "to be" between "cause the fleet data" and "pushed." Google disagrees, arguing that the Court cannot correct the error because it is neither inadvertent nor minor. Even assuming that the error is minor, Google contends that it is subject to reasonable debate, such that correction is inappropriate. See Novo Indus., L.P. v. Micro Molds Corp., 350 F.3d 1348, 1354 (Fed. Cir. 2003). Without correction, Google argues that the claim is indefinite.

In construing a patent, district courts may correct "certain obvious errors," id. at 1355, including "minor typographical and clerical errors." Id. at 1357. Such corrections may occur, however, "only if (1) the correction is not subject to reasonable debate based on consideration of the claim language and the specification and (2) the prosecution history does not suggest a different interpretation of the claims." Id. at 1354. Any proposed correction must be considered "from the point of view of one skilled in the art." CBT Flint Partners, LLC v. Return Path, Inc., 654 F.3d 1353, 1358 (Fed. Cir. 2011) (citation and internal quotation marks omitted). District courts should not correct a claim where "the nature of the error is not apparent from the face of the patent." Novo Indus., 350 F.3d at 1357.

Assuming the Court may correct the error, the Court finds that it is subject to reasonable debate, such that it cannot satisfy the Novo Industries standard. See id. at 1354. First, the specification offers some support to Unwired's proposed correction, noting in one embodiment that a mobile station may obtain "an entry to access a command to cause a selective set of fleet data to be pushed to a fleet of mobile stations." '657:10:51-55 (emphasis added). Claim 12 of the '657 Patent similarly discloses an architecture in which "said commanding mobile station execut[es] said request that causes said fleet data to be pushed to the plurality of mobile stations." '657 Claim 12 (emphasis added). Other passages in the specification, however, support one of Google's alternative corrections, which would change Claim 16 to read "executing said request to cause said fleet data pushed by said proxy server module to [be received by] the plurality of the mobile stations." (Dkt. no. 378 at 19.) The specification describes "[o]ne of the key features of the present invention" as ensuring that "fleet data can be securely obtained and pushed to a selective set of mobile stations such that the mobile stations upon receiving the fleet data will act accordingly." '657:7:17-20. Claim 16 of the '657 Patent could encompass this aspect of the invention by disclosing a method to ensure the receipt of fleet data, rather than a method for pushing the data.

It is not clear to the Court that this term suffers from a minor, typographical error. For example, Claim 26 of the '657 Patent repeats the allegedly erroneous language, disclosing a method "wherein said executing said request to cause said fleet data pushed by said proxy server module to the plurality of mobile stations." Similar wording appears in the specification, which summarizes the invention as including a step of "executing the request to cause the fleet data pushed by the proxy server module to the plurality of the mobile stations." '657:3:5-7. Because nearly identical phrasing appears elsewhere in the patent, the error does not appear to be obvious or inadvertent. For this analysis, however, the Court assumes that it may correct the error.

Unwired argues that Google's alternative corrections fail to give rise to a reasonable debate. (See Tr. at 103:5-23 (citing Cree, Inc. v. SemiLEDs Corp., No. 10-866-RGA, 2012 WL 975697, at *14-15 (D. Del. Mar. 21, 2012).) Unwired asserts that the error at issue in Cree is almost identical to the disputed term here. (Tr. at 104:13-14). Cree is distinguishable. There, a court in the District of Delaware found that no reasonable debate existed over a claim term error. Cree, 2012 WL 975697 at *15. The court reasoned that the defendant's alternative constructions found no support in the claims or in the specification. Id. Here, conversely, the specification supports an alternative correction, giving rise to a reasonable debate.

Accordingly, the Court declines to correct the error or otherwise construe the term. The Court will address the indefiniteness issue when it considers Google's pending motion for summary judgment (dkt. no. 389). (See Tr. at 113:18-114:17.)

5. "Push," "Pushes," and "Pushed"

Unwired's Revised Proposed Construction	Google's Proposed Construction
plain meaning or "delivering data initiated from a server to a mobile device" (Tr. at 126:22-24; see Tr. at 124:17-18)	"delivering data from a server to a mobile device absent a request for the data from the mobile device"

Unwired suggested this revised proposal during the Markman hearing as a modification of Google's proposed construction.

The parties dispute this term's scope. Google argues that a person of ordinary skill in the art would distinguish the term from a pull, a process through which a mobile device requests specific data. Google insists that Unwired's understanding of the term's plain meaning could encompass a pull. Unwired contends that Google limits the term's plain meaning by excluding any and all data that a mobile device may have requested. (Dkt. no. 376 at 14.) Because adopting the plain meaning would not resolve this dispute, the Court will construe the term. See O2 Micro, 521 F.3d at 1361.

Google concedes that its construction is not intended to exclude a scenario where a mobile device initially authorizes an entity to push data. (Tr. at 116:21-118:25.) Information that is sent after an initial authorization — calendar reminders, for example — would constitute pushes because the mobile device did not specifically request them. (Tr. at 118:15-25.) To ensure that the term captures this scenario, the Court adopts a modified version of Google's proposed construction: "delivering data from a server to a mobile device absent a request for that specific data from the mobile device."

Neither the claims nor the specification define the term. The asserted claims almost uniformly refer to the term in the context of a "request from a provisioning entity to push fleet data to the plurality of the mobile stations." '657 Claim 16; see '240 Claims 1, 5, 15, 27. Several claims also describe a mechanism to authenticate and carry out a provisioning entity's request to push the data. See '240 Claims 1, 5, 6, 15, 27. No asserted claim suggests that the term encompasses data deliveries prompted by a specific request from a mobile device. The specification similarly describes the need for "a secure communication means through which the authorized entity can disseminate or push mobile data," '657:1:60-61, and a process of executing a request to push data "by transferring or pushing the desired fleet data to the fleet of the desired mobile stations." Id. at 7:49-50. These pushes occur after an entity — not a mobile device — requests them. The intrinsic evidence thus supports the Court's construction.

6. "Provisioning entity"

Unwired's Revised Proposed Construction	Google's Proposed Construction
plain meaning or "a business, corporation, or a user that has access to a fleet managing system, must be capable of sending fleet data, and sends fleet data to a set of mobile stations" (Tr. at 147:14-19)	"an entity that enables telecommunications capabilities on a mobile device"

Unwired offered two revised constructions during the Markman hearing: first, "a business, corporation, or a user that sends fleet data to its fleet of mobile stations," or second, "a user that interacts with the fleet managing system." (Tr. at 146:3-147:6.) Because neither construction captured how a provisioning entity interacts with the fleet managing system or mobile stations, the Court suggested adding that a provisioning entity must have access to the fleet managing system and must be capable of disseminating information. (Tr. at 147:2-5.) Unwired's revised proposed construction captures these details.

The parties dispute the import "provisioning" has on the disputed term. Google asserts that Unwired reads "provisioning" out of the term; relying on extrinsic evidence, Google argues that a person of ordinary skill in the art would understand that a provisioning entity enables telecommunications capabilities. Unwired contends that in the context of the patent, "provisioning" does not involve enabling telecommunications capabilities. Rather, "provisioning entity" describes an entity capable of accessing and engaging with fleet data, where provisioning indicates that the entity interacts with a provisioning system. (Tr. at 141:7-142:8.) The Court agrees and adopts Unwired's revised proposed construction.

Google admits that its proposal derives from extrinsic evidence, but contends that the intrinsic evidence fails to define the term. (Tr. at 138:4-14.) The Court finds that the intrinsic evidence supports a broader construction. First, none of the asserted claims suggests that a provisioning entity must furnish telecommunications capabilities. Several claims describe a provisioning entity as requesting to push fleet data, see '657 Claim 16; '240 Claims 1, 27; while others describe the various forms a provisioning entity may take, ranging from "a computing device coupled directly to the fleet server," '240 Claims 2, 16; to a "mobile station coupled to the proxy server," id. at Claims 13, 18; to a "mobile station on the wireless network." Id. at Claim 28. These claims do not limit the content a provisioning entity may request to push.

Second, the Court disagrees with Google's contention that the specification fails to define the term. (See dkt. no. 356 at 16.) Like the claims, the specification offers examples of the types of devices that may serve as a provisioning entity. See, e.g., '657:10:21-23 ("[P]rovisioning entity 502 can be a fleet management terminal, a computing device, a mobile station or an electronic device providing access means to fleet server 506."). The embodiments further describe a process for "accepting a request from a provisioning entity 212 to push a set of fleet data to a fleet of mobile stations" in which a "user sends the request, or fleet data request, from provisioning entity 212." Id. at 7:24-33. The users envisioned by the Fleet Patents include a "corporation [that] wants to propagate an urgent proprietary message," id. at 1:52-54, and a "business [that] has a product promotion that is only available to certain users at a specific time in a specific geographic area." Id. at 6:65-67. The specification also states that fleet data "affecting the operation of a mobile station[] may not be pushed to a set of restrictive mobile stations," suggesting that a provisioning entity need not enable telecommunications capabilities. Id. at 6:60-62. The specification thus indicates that a provisioning entity requests to send — and is capable of sending — data to a fleet of mobile stations.

Google's construction could eliminate these embodiments, a solution that "is rarely, if ever, correct and [that] would require highly persuasive evidentiary support." Hill-Rom Servs., Inc. v. Stryker Corp., 755 F.3d 1367, 1379 (Fed. Cir. 2014) (citation and internal quotation marks omitted). Google's construction lacks such evidentiary support. Google's extrinsic evidence includes a telecommunications dictionary and expert testimony. The dictionary defines provisioning as "[t]he act of acquiring telecommunications service from submission of the requirement through the activation of service." (Dkt. no. 354-12 at 6.) Google's expert agrees. (Dkt. no. 354-1 ¶ 41.) Each of these extrinsic references suggests that the provisioning entity works with only a narrow scope of data involving telecommunications. But the specification clarifies that "the contents or functions in the fleet data" — which, according to the claims, a provisioning entity requests to send — "do not affect the operations of the present invention." '657:4:60-61. Google's extrinsic evidence focuses too heavily on "provisioning," and "poses the risk [of] . . . chang[ing] the meaning of claims." Phillips, 415 F.3d at 1319.

Nor is the Court persuaded by a recent claim construction order from a court in the Northern District of California, which construed "provisioning" based on the term's use in U.S. Patent Number 6,647,260 ("'260"). See Unwired Planet, LLC v. Apple Inc., No. 13-cv-04134 VC (dkt. no. 442-1). First, the '260 Patent is not at issue in this case. Indeed, Google cites the '260 Patent to suggest that "provisioning" involves telecommunications capabilities. (See dkt. no. 356 at 17.) Google concedes, however, that unlike the Fleet Patents, the '260 Patent "provides a clear explanation of 'provisioning'" as enabling communications capabilities. (Id.) The Unwired Planet court agreed, construing "provisioning" as "enabling or modifying communication capabilities." (Dkt. no. 442-1 at 8.) The court cited the same language that Google quotes, where the specification states that "[b]efore a consumer can use one of these devices, a number of parameters must be provisioned in order to enable communication services and applications and in order to distinguish the device from others within the communications network." (Id. at 7 (internal quotation marks omitted).) Here, as discussed above, no such language appears in the Fleet Patents; rather, the specification describes a provisioning entity in broader terms.

The Court therefore construes "provisioning entity" as "a business, corporation, or a user that has access to a fleet managing system, must be capable of sending fleet data, and sends fleet data to a set of mobile stations."

7. "Fleet managing system" and "Fleet server"

Unwired's Revised Proposed Construction	Google's Proposed Construction
Fleet managing system: plain meaning Fleet server: plain meaning or "a gatekeeper that sits between the provisioning entity and the fleet of mobile stations or mobile devices" (Tr. at 165:17-25)	Fleet managing system: "a system for managing a fleet that includes at least a fleet server and a proxy server" Fleet server: "a server that includes an interface to a provisioning entity, an interface to a proxy server, a memory for storing fleet data, and a fleet server module to control access to the fleet data in memory and to communicate with a proxy server"

Unwired offered a definition of the plain meaning of "fleet server" for the first time during the Markman hearing.

With regard to "fleet managing system," Unwired argues that the plain meaning should control, but Google contends that the term is not a term of art. The Court will construe the term because the parties dispute its plain meaning. See O2 Micro, 521 F.3d at 1361. Although Unwired has not defined the term's plain meaning, it objects to Google's proposed construction as limited to a preferred embodiment, in violation of claim differentiation, and confusing. The Court disagrees and adopts Google's proposed construction.

"Fleet managing system" appears in Claim 16 of the '657 Patent and Claim 30 of the '240 Patent. These claims describe a fleet managing system that transmits a challenge response, and that may be accessed after correct credential information is provided to the challenge response. Claim 16 also discloses several components included in a fleet managing system, such as an account manager, a proxy server module, a memory, and a provisioning interface. See '657 Claim 16.

The specification offers a clearer description of a fleet managing system, noting that Figures 2A and 2B "demonstrate[] the system architecture of the fleet managing system of the present invention," '657:3:25-26, and further clarifies that "[Figures] 2A and 2B illustrate block diagrams of the essential components in the present invention." Id. at 6:12-13. The "essential components" depicted in Figure 2A include a fleet server and a proxy server. Id. at Fig. 2A. Unwired contends that the following sentence — which states that Figure 2A depicts "functional block diagrams of fleet server 200 and proxy server 230 in the present invention according to one embodiment thereof" — suggests that Google's construction reflects a preferred embodiment. Id. at 6:14-16. Unwired seems to misconstrue this sentence. Rather than indicate that a fleet managing system need not contain a fleet server and a proxy server, the sentence suggests that Figure 2A depicts one way to organize the various components included in the fleet server and the proxy server. See id. Furthermore, Unwired's argument overlooks the "essential components" statement, which limits a fleet managing system "to a particular form of the invention." Hill-Rom Servs., Inc., 755 F.3d at 1372 (citation omitted) ("[W]e have held that disclaimer applies when the patentee makes statements such as 'the present invention requires . . .' or 'the present invention is . . .' or 'all embodiments of the present invention are . . . .'") The specification supports Google's proposed construction.

Unwired's claim differentiation argument is similarly unavailing. Dependent Claim 18 in the '657 Patent discloses "[t]he method as recited in Claim 16, wherein said fleet managing system comprises a proxy server and a fleet server." Because Claim 16 does not state that a fleet managing system must contain a proxy server and a fleet server, Unwired contends that Google's construction renders Claim 18 superfluous. But Claim 18 further discloses that the proxy server and fleet server are securely coupled, as well as certain components that the proxy server and fleet server include. Claim 18 thus adds limitations to Claim 16 other than the fact that the fleet managing system includes a proxy server and a fleet server. The Court finds that claim differentiation does not bar Google's proposed construction. The Court construes "fleet managing system" as "a system for managing a fleet that includes at least a fleet server and a proxy server."

The parties also dispute whether "fleet server" has a plain and ordinary meaning. Google contends that it does not, and urges the Court to construe the term by defining certain components that a fleet server must include. Unwired, on the other hand, argues that the term's plain meaning is clear, such that construing it amounts to an "exercise in redundancy." (Dkt. no. 376 at 20 (citation and internal quotation marks omitted).) In light of the parties' dispute, the Court will construe the term. See O2 Micro, 521 F.3d at 1361. The Court adopts Google's proposed construction.

"Fleet server" appears in asserted Claims 1-3, 5, 15-18, and 27 of the '240 Patent. The claims describe various functions a fleet server might carry out, such as communicating with a proxy server, authenticating a request to push fleet data, and more specific permutations of those actions. See '240 Claim 1; see also id. at Claims 2, 16 (fleet server prompts a provisioning entity with a challenge response); id. at Claims 3, 17 ("the fleet server enables the provisioning entity to determine the fleet data and the plurality of the mobile stations"). Other claims disclose components that a fleet server may include, like storage, a mechanism for accessing fleet data, and an authenticating mechanism. See id. at Claims 5, 15. Together, these claims suggest that a fleet server must include certain components that allow it to interact with a proxy server and authenticate requests to push fleet data.

The specification similarly describes specific components that may be included in a fleet server. As noted above, Figure 2A "illustrate[s] block diagrams of the essential components of the present invention," '657:6:13-14; it depicts a fleet server that comprises "a provisioning interface 202, a database 204, memory 206 and fleet server module 208." Id. at 6:41-43. Google's construction takes cue from this passage, which describes components that "generally" appear in a fleet server. Id. at 6:41. Unwired stresses that the specification also notes that this "description is based on fleet server 200 and proxy server 230 being separate apparatus but implies no limitations to the particular configurations thereof." Id. 6:33-36. Based on these passages, Unwired contends that Google's proposed construction limits the claim term to a preferred embodiment. Google's construction, however, depicts the functionality of the components that comprise a fleet server, rather than dictating a particular configuration. Moreover, the specification describes the fleet server's functions in terms of its components, noting, for example, that "[m]emory 206 provides necessary space for fleet server module 208 to function as designated" and that "[p]rovisioning interface 202 provides necessary security means for accepting a request from a provisioning entity 212 to push a set of fleet data." '657:7:23-27. Because the specification "usually supplies the best context for deciphering claim meaning," the Court finds that Google's construction is appropriate. Honeywell Int'l Inc. v. Universal Avionics Sys. Corp., 488 F.3d 982, 991 (Fed. Cir. 2007).

The Court construes "fleet server" as "a server that includes an interface to a provisioning entity, an interface to a proxy server, a memory for storing fleet data, and a fleet server module to control access to the fleet data in memory and to communicate with a proxy server."

8. "Providing secure access to said memory" / "control access to fleet data" / "control access to the fleet data in the storage device"

Unwired's Revised Proposed Construction	Google's Revised Proposed Construction
plain meaning or "allowing an authorized provisioning entity to store, retrieve, navigate, or otherwise interact" (Tr. at 177:22-23)	"allowing an authorized provisioning entity the ability to store or retrieve fleet data in the memory on the fleet server" (Tr. at 186:6-8)

Unwired agreed to offer an alternative construction during the Markman hearing. Google similarly modified its proposal by adding the phrase "the ability to."

The terms appear in three claims. Claim 16 of the '657 Patent discloses a "provisioning interface providing secure access to said memory," while Claim 1 of the '240 Patent describes "a fleet server coupled to communicate with the proxy server, to store and control access to fleet data," and Claim 15 of the '240 Patent includes "a fleet server module to control access to the fleet data in the storage device." Unwired contends that the Court need not construe these terms, while Google disagrees with Unwired's understanding of the scope of the terms' plain meaning. Unwired raises three objections to Google's proposed construction: (1) whether the three terms should be construed separately; (2) how "access" should be defined; and (3) whether the memory at issue must be on the fleet server. During the Markman hearing, both parties agreed to construe the three terms separately, resolving Unwired's first objection to Google's proposed construction. (Tr. at 173:13-19, 179:4-6.) Construed separately, the remaining term in dispute is "access." The Court will construe "access" because "determin[ing] that [the] claim term 'needs no construction' or has the 'plain and ordinary meaning'" would not resolve the parties' dispute. O2 Micro, 521 F.3d at 1361.

Google contends that Unwired's plain meaning proposal is too broad. Analogizing the claim term to a PO box, Google argues that Unwired understands "access" to encompass sending mail to the PO box. Google contends that a person of ordinary skill in the art would not understand "access" so broadly; rather, a person has access to the PO box if she has a key and "can put things in and take things out." (Dkt. no. 356 at 23.) Unwired clarified during the Markman hearing that it does not read "access" to include sending a letter to the PO box. (Tr. at 182:8-10.) Indeed, the parties nearly reached an agreement during the Markman hearing, acknowledging that "access" involves the ability to store or retrieve data. (See Tr. at 181:8-13, 186:2-11.) Unwired, however, argues that the construction should include navigating, pointing to language in the specification that describes a user navigating fleet data in a fleet server. See '657:11:18-22. Google does not dispute that the specification discusses navigating data, but argues that navigating data is implicit in retrieving it.

Because the specification explicitly discusses navigation as an action that a user may carry out if the user has access to fleet data, the Court includes navigation in its construction. See id. The Court therefore construes "access" as "allowing an authorized provisioning entity the ability to store or retrieve or navigate."

9. "User account"

Unwired's Revised Proposed Construction	Google's Proposed Construction
plain meaning or "an established account with a user of a mobile device" (Tr. at 200:23-24)	"an established relationship between a user of a mobile device and a wireless carrier authorizing the mobile device to use the carrier's network"

Unwired offered this definition of the term's plain meaning during the Markman hearing.

Google contends that "user account" is "a broad term that can mean different things in different contexts," and argues that the Fleet Patents employ the term to refer to a user's relationship with a wireless carrier. (Dkt. no. 356 at 23.) Unwired suggests that the Court need not construe the term because it is clear on its face. Unwired further argues that Google's proposal improperly limits the Fleet Patents to "wireless carrier environments" and excludes preferred embodiments. (Dkt. no. 376 at 24.) Given the parties' dispute over the term's scope, the Court will construe the term. See O2 Micro, 521 F.3d at 1361.

The Court finds that the intrinsic evidence supports Google's proposed construction and adopts it. The term appears in Claim 16 of the '657 Patent and Claims 6 and 27 of the '240 Patent. In Claim 16 and Claim 6, the user account is associated with an account manager that is involved in a verification process. Claim 27 similarly involves "verifying the plurality of the mobile stations against a plurality of user accounts using the fleet server." '240 Claim 27. Citing its expert testimony, Google argues that a person of ordinary skill in the art would understand these claims to describe user accounts associated with a wireless carrier because the verification process ensures that the mobile stations may receive data sent over a wireless network. (Dkt. no. 356 at 24 (citing dkt. no. 354-1 ¶ 58).) The Court agrees.

First, the Fleet Patents disclose technology that operates in the context of wireless carrier infrastructures. Claim 16, for example, provides for "[a] method for securely managing a plurality of mobile stations serviced by a carrier infrastructure." '657 Claim 16. The abstract also notes that "[t]he present invention discloses a fleet managing system in which fleet data can be securely managed and disseminated to a selective group of mobile stations serviced by a carrier infrastructure." '657 Abstract.

Against this backdrop, the specification describes the elements of an exemplary verification process where mobile stations are "determined if all are authorized and serviced by the proxy server." Id. at 13:26-27. This process "[t]ypically" occurs where "the selected mobile stations are examined against their corresponding user accounts." Id. at 13:28-29. The specification additionally states that a user account includes a device ID, see id. at 8:57-59, which "is further associated with a subscriber ID 404 that is typically initiated and authorized by a carrier in proxy server device 240 as part of the procedures to activate a subscriber account for a mobile station." Id. at 8:63-67. The device ID appears in "each of mobile stations serviced by" a proxy server and "corresponds to a respective user account therein." Id. at 9:3-5. The specification also describes device IDs as identifying, for example, "a mobile phone that is pre-configured for a CDPD network." Id. at 9:22. Together, these descriptions suggest that the process required to "determine a fleet of mobile station[s]" involves verifying a user account that includes information generated by a wireless carrier serving the mobile device. '657 Fig. 7B. Google's proposed construction reflects this process.

The Court disagrees with Unwired's contention that Google's proposal limits the claim term to an embodiment. Although the cited descriptions contain permissive language, they account for the wireless carrier environment noted in the abstract. Ignoring these descriptions would allow a "user account" to assume a meaning divorced from the Fleet Patents' context. Because the term is so broad, the Court cannot construe it without turning to the specification, which indicates that a user account involves a wireless carrier.

Unwired also argues that Google's construction excludes an embodiment involving user accounts serviced by a service device or proxy server because those descriptions do not require the user account to be associated with a wireless carrier. (Dkt. no. 376 at 25 (citing '657:8:55-9:5, 13:21-30).) Google's proposed construction, however, is derived from one of Unwired's cited passages — Unwired focuses on the first sentence of a paragraph that later clarifies that a user account includes a device ID that is associated with a carrier. See '657:8:55-9:18. Google's proposal does not exclude this embodiment. Unwired also points to a group ID embodiment: "[p]referably, each user account is also assigned a group ID 406 to facilitate the fleet management." Id. at 9:6-7. But Google's proposed construction would not eliminate this embodiment because a user account could include a group ID along with carrier information.

Finally, Unwired contends that Google's proposal undermines the Fleet Patents' very purpose because businesses, corporations, or other entities would need to rely on a carrier to disseminate information. (Tr. at 197:21-200:2.) Nothing in Google's proposal would require an entity to ask a carrier to send information. Instead, a mobile device's relationship with a carrier enables an entity to send information to the appropriate devices. The Court therefore construes "user account" as "an established relationship between a user of mobile device and a wireless carrier authorizing the mobile device to use the carrier's network."

10. "Coupled directly"

Unwired's Proposed Construction	Google's Revised Proposed Construction
plain meaning	"implemented in a single server computer or connected by a dedicated wire" (Tr. at 214:7-19)

Google initially proposed: "implemented in a single server computer." (Dkt. no. 351-1 at 3.)

This term appears in dependent Claims 2 and 16 of the '240 Patent, which discuss a system where "the provisioning entity is a computing device coupled directly to the fleet server." Google contends that the term lacks a plain meaning and draws its proposed construction from the specification, which states that "[w]hen fleet server 200 and proxy server 230 are implemented in a single server computer, both are directly coupled." '657:6:28-30. Unwired argues that Google's construction is too narrow, and that the patent explains that a server and a computer may be directly coupled with a "direct and/or secure" communication path rather than being implemented on a single server computer. (Dkt. no. 376 at 26.) The Court will construe the term because the parties dispute its scope. See O2 Micro, 521 F.3d at 1361.

Unwired suggests that "implemented on a single server computer" is a subset of "coupled directly," which is a subset of "coupled." (Tr. at 209:5-211:22.) To support this reading, Unwired points to a passage that describes the communication between a provisioning entity that is directly coupled to a fleet server as "private," such that "the security of the information exchange therebetween can be guaranteed." '657:10:24-28. This passage describes Figure 5, which "shows an overview of the fleet managing system having multilevel transitive trust between pairs of entities." Id. at 3:35-36. Unwired contends that, when applied to Figure 1 — "a schematic representation of a data network," id. at 3:23-24 — the passage contradicts Google's proposal because Figure 1 shows a server ("server 122") and a computer ("computer 124") that are not in a single server computer, but rather are connected by a private network. (Tr. at 210:22-25.) Thus, Unwired argues, a computer that shares a private network with a server is directly coupled to that server.

To account for server 122 and computer 124 in Figure 1, Google modified its proposal to include a connection through a dedicated wire. (Tr. at 214:7-19.) The Court adopts Google's initial proposal. First, the specification defines "directly coupled" as "implemented in a single server computer." '657:6:28-30. Second, it is not clear that server 122 and computer 124 in Figure 1 are directly coupled — the specification suggests that they are "coupled to the private network." Id. at 8:2-3. Third, aside from the connection between server 122 and computer 124 depicted in Figure 1, Google's revised proposal regarding a dedicated wire does not seem to be grounded in the patent. Google's initial proposed construction reflects the only definition of "directly coupled" in the specification. The Court therefore construes "coupled directly" as "implemented in a single server computer."

The Court notes that it offered a compromise construction during the Markman hearing. (Tr. at 205:21-23 ("a direct connection that does not go through the landnet").) The Court agrees with Google that this construction is negatively phrased and could create ambiguity. The Court declines to adopt this proposed construction.

11. "Preparing said fleet data to be received in said memory"

Unwired's Proposed Construction	Google's Revised Proposed Construction
plain meaning	"using the fleet managing system to create/edit fleet data, or select from pre-prepared fleet data prior to storing the fleet data in memory" (Tr. at 221:23-25, 227:12-13)

Google initially proposed: "using the fleet server to create fleet data or select from pre-prepared fleet data." (Dkt. no. 351-1 at 4.)

The disputed term is a step in a method for "securely managing a plurality of mobile stations serviced by a carrier infrastructure." '657 Claim 16. Google urges the Court to construe this term because it lacks a plain meaning, and, absent a construction, a jury may misunderstand "preparing" in the Fleet Patent context. Unwired disagrees, suggesting that a jury will understand "the plain words 'preparing,' 'receiving,' and 'memory.'" (Dkt. no. 376 at 27.) In light of this dispute, the Court construes the term and adopts Google's revised proposed construction. See O2 Micro, 521 F.3d at 1361.

Before the Markman hearing, Unwired contended that Google's initial proposed construction omitted "memory" from the claim term and imported "fleet server" into the term. Google resolved Unwired's first objection during the hearing by adding "memory" to its proposed construction. Google also modified its proposal to include "fleet managing system" in lieu of "fleet server." This change tracks the language of Claim 16. Unwired continues to object to this modification because Google's proposed construction of "fleet managing system" includes a "fleet server," and, as discussed above, Unwired argues that reading a fleet server into Claim 16 is improper. (See supra Part IV.B.7.) Finally, Unwired requested that "edit" be included in the construction; Google agreed and revised its construction to read "create/edit fleet data."

The Court adopts Google's revised proposed construction. Unwired rehashes its objections to the Court's construction of "fleet managing system," but has not indicated why its inclusion in this term is objectionable. Including "fleet managing system" in this construction is consistent with Claim 16, which describes a provisioning entity that accesses a fleet managing system to push fleet data. '657 Claim 16. Moreover, Google's revised proposed construction reflects the specification's description of preparing data: "At 718, the user is provided to prepare the fleet data[.] . . . [T]he user may choose from a list of pre-prepared messages or create/edit a new one." Id. at 13:33-35. Accordingly, the Court construes "preparing said fleet data to be received in said memory" as "using the fleet managing system to create/edit fleet data, or select from pre-prepared fleet data prior to storing the fleet data in memory."

C. '760 Patent

The '760 Patent discloses a "method and apparatus for protecting the identities of mobile devices on a wireless network" by regulating the sending of information to a mobile device. '760 Abstract; see id. at 3:13-17, 4:1-4. The parties dispute four terms that appear in Claim 10, the only claim asserted against Google. Claim 10 describes a "method of operating a server" that includes sending and receiving requests to provide information to a mobile device and validating those requests through an encrypted identifier. See id. at Claim 10.

1. "Encrypted identifier of a mobile client device"

Unwired's Proposed Construction	Google's Proposed Construction
"a unique identifier associated with a mobile client device that has been encoded to prevent decoding the identifier without the use of a secret key"	"a unique identifier that is assigned to a mobile device and then encoded, separately from other information, so that it can only be turned back into the original identifier by decoding it with a key"

Unwired clarified during the Markman hearing that it does not think "of a mobile client device" needs to be construed. (See Tr. at 234:10-13, 237:7-15.) If the Court construes the term, Unwired argues that it should read "associated with a mobile client device." (Tr. at 237:7-15.)

The parties agree that this term describes an encoded identifier that may be decoded only with a key. (See Tr. at 233:8-12; 248:19-23.) Unwired, however, contends that Google's proposed construction limits the disputed term by reading an assigning step into the claim and by requiring that the identifier be separately encoded after its assignment. Google argues that Unwired's construction broadens the term beyond the claim's scope in two ways. First, Unwired's construction ignores the fact that a person of ordinary skill in the art would understand that an encrypted identifier cannot uniquely identify a mobile device unless it is assigned to one. (Tr. at 246:3-247:21.) Second, Unwired's proposal would allow an encrypted identifier to be part of a larger block of encrypted data, rather than a separately encoded identifier included in a request to provide information. The Court finds that the patent supports, in part, Google's proposed construction and adopts a modified version of it.

With regard to Unwired's first objection, the Court will construe "of a mobile device" because the parties dispute the term's plain meaning. See O2 Micro, 521 F.3d at 1361. The specification suggests that an identifier is assigned to — not merely associated with — a mobile device because it references exemplary types of identifiers that are "derived from the mobile device, the network, or the proxy gateways," '760:5:13-14, or are "formed by using the server operator's internal account number of the subscriber, or formed by combining provisioning data, user data, and naming authority domain." Id. at 5:21-25. Google's expert testimony clarifies that these identifiers "are assigned to a mobile device, whether by a hardware manufacturer, a carrier network, or a service provider." (Dkt. no. 378-6 ¶ 8.) Without such assignment, it is not clear how the method in Claim 10 could ensure that each identifier is unique.

As to Unwired's second argument, Google's proposed construction does not add a separate encoding step. In referencing "the true (unencrypted) client identity of a mobile device," the specification indicates that encoding occurs after an encrypted identity has been assigned to a device. '760:4:58. The specification additionally illustrates a pull request in which an unencrypted client identifier is encoded and included in the request. See id. at 6:57-7:24. A subsequent push request depicted in the specification involves decoding the encrypted client identifier. See id. at 6:33-67. Together, these references teach that the true client identifier must properly identify the mobile device before it is encoded.

Finally, the Court agrees with Unwired's argument that Google impermissibly narrows the claim term by including "separately from other information" in its construction. Google's construction extrapolates from the patent's exemplary pull and push requests, which depict an encrypted identifier that is separate from other transmitted information. See id. at 7:9-32. Google also relies on the summary of the invention, which states that "[t]he present invention includes a method and apparatus for operating a processing system," and that "[i]n the processing system, an identifier of a mobile device on a wireless network is encrypted." Id. at 3:13-16. Neither reference, however, indicates that the identifier must be separately encrypted. Although the only encryption process described in the embodiment involves a device's identifier, the embodiment does not dictate how other information might be encrypted. The Court would import an unnecessary limitation into the claim term by reading this embodiment to require an encrypted identifier to be separately encoded. Furthermore, while a patentee may disclaim features of an invention by stating that "the present invention requires" or the "present invention is," Hill-Rom Servs., 755 F.3d at 1372 (internal quotation marks omitted), the summary of the invention here notes only that an identifier is encrypted in a processing system that the "present invention includes." '760:3:13. Accordingly, the Court construes "encrypted identifier of a mobile client device" as "a unique identifier that is assigned to a mobile device and then encoded so that it can only be turned back into the original identifier by decoding it with a key."

2. "The encrypted identifier in the request to push the second information is used to validate the request to push the second information"

Unwired's Revised Proposed Construction	Google's Proposed Construction
plain meaning or "the encrypted identifier in the request to push the second information is decrypted and checked against the stored client identifier to determine if there is a match between the decrypted and the stored identifier" (Tr. at 272:9-10)	"the encrypted identifier of the mobile client in the request to push the second information is decrypted and checked against the true (unencrypted) client identifier to verify that the sender is authorized to push the second information to that mobile client"

Unwired initially proposed: "the encrypted identifier in the request to push the second information is decrypted and checked against the stored client identifier." (Dkt. no. 351-1 at 11.)

The parties agree that this term involves decrypting an encrypted identifier that is included in a request to push information. Unwired, however, argues that the construction need not explain why an encrypted identifier is used to validate a request, and that Google's proposal improperly limits the term by including such details. Google contends that its proposed construction reflects the patent's purpose of regulating "unauthorized and or unsolicited push services directed to mobile devices." '760:4:2-3. Because the parties dispute the term's scope, the Court will construe the term. See O2 Micro, 521 F.3d at 1361. The Court adopts Google's proposed construction.

Unwired's proposed construction encompasses how a validation step may be carried out, but stops short of explaining why the request to push must be validated. Unwired — along with Google — cites the following passage to support its construction:

At block 604, the service proxy gateway determines whether the decrypted client identifier matches the true client identifier for the target mobile

device. If the two client identifiers match, then the push request is determined to be invalid [sic] at block 605, and action on the request is allowed to proceed. Otherwise, the request is determined to be invalid and is therefore barred at block 606.

'760:6:33-40. Unwired's proposed construction seems to focus exclusively on the first sentence, ignoring the statement that "the request is allowed to proceed" if a push request is determined to be valid. This passage suggests that the validation process involves both checking a client identifier and verifying the sender. Google's construction accounts for both of these elements.

This sentence erroneously states: "then the push request is determined to be invalid at block 605." '760:6:37-38 (emphasis added). Read in context, this sentence should read: "then the push request is determined to be valid at block 605."

The Court also finds that Google's use of "true (unencrypted) client identifier" is consistent with the specification and provides more clarity than Unwired's "stored identifier." See '760:4:58. The Court therefore adopts Google's proposed construction.

3. "Request to provide first information"

Unwired's Proposed Construction	Google's Revised Proposed Construction
plain meaning	"a message that identifies content to be returned and instructs the server to provide it" (Tr. at 284:14-16)

Google initially proposed: "a message that identifies content on the server and instructs the server to provide it." (Dkt. no. 351-1 at 10.) Google's revision addresses Unwired's objection that Google's initial proposal required requested content to be on a server. (Tr. at 283:7-284:24.)

The parties disagree about this term's plain meaning and its scope. Google contends that the term must be construed because Unwired's reading of the term would cover "any communication that triggers a response," such as receiving a confirmation message after a computer upload. (Dkt. no. 356 at 32.) Unwired disagrees, arguing that the term is clear on its face, and that Google's proposal limits the plain meaning in the absence of lexicography or disavowal. In light of this dispute, the Court will construe the term. See O2 Micro, 521 F.3d at 1361. The Court adopts Google's revised proposed construction.

The intrinsic evidence supports Google's proposal. Claim 10 discloses a three-step method in which a server, among other actions, "receiv[es] a request to provide first information," "send[s] the first information in response to the request," and then "send[s] a request to push second information." '760 Claim 10. Google's construction properly defines the first step, indicating that the request to provide first information identifies particular content to be returned, and that the request prompts a response. Unwired's understanding of the term's plain meaning stretches beyond Claim 10's scope — the claim clarifies that the request for first information prompts the response of sending that information. The specification similarly depicts a process where servers "provide content, such as hypermedia documents, to mobile devices 1 in response to standard (e.g., HTTP) requests from the mobile devices 1." Id. at 1:56-58. The specification uses "pull" to describe this process, and clarifies that in a pull scenario, "a client requests information from an origin server," id. at 3:31-32, or "a mobile device (a 'client') makes a request for content." Id. at 2:5-6. Thus, contrary to Unwired's assertions, Google's construction does not import limitations from the specification into the claim.

The Court therefore construes "request to provide first information" as "a message that identifies content to be returned and instructs the server to provide it."

4. "Wireless network"

Unwired's Revised Proposed Construction	Google's Revised Proposed Construction
plain meaning or "network components for transmitting and/or receiving data wirelessly." (Tr. at 302:13-15, 304:3-5)	"network components for transmitting and/or receiving data wirelessly over a wide area" (Tr. at 305:4-6)

During the Markman hearing, Unwired indicated that it would not object to this construction if the Court decides to construe the term.

In response to one of Unwired's arguments, Google clarified during the Markman hearing that it had no objection to including the word "receiving" in its proposed construction.

The parties contest whether devices connected to the Internet through a local or short-range connection are on a wireless network. Google argues that the '760 Patent would consider devices connected to the Internet through Wi-Fi to be part of a wired network, rather than on a wireless network. Unwired contends that the patent lacks this limitation and urges the Court not to construe the term. Unwired further argues that Google's proposal is improper because the patent lacks lexicography or disavowal. The Court finds that a construction is necessary because the parties dispute the term's plain meaning. See O2 Micro, 521 F.3d at 1361. The Court adopts Google's revised proposed construction.

Claim 10 describes "a mobile client device on a wireless network," but does not further define the term. See '760 Claim 10. The specification offers more clarity, noting that technology at the time of the invention "allows mobile devices operating on wireless networks to access information stored on a separate, wired network, such as the Internet." '760:1:14-16. The specification further states that "[t]he wired network 3 may be, for example, the Internet, a corporate intranet, a wide area network (WAN), a local area network (LAN), a public switched telephone network (PSTN), or a combination thereof." Id. at 1:24-29. A wireless network "is coupled to a conventional wired computer network 3 through a proxy gateway 4," id. at 1:23-24, which "enable[s] communication between the mobile devices 1" and "processing systems . . . operating on the wired network 3." Id. at 1:30-33. The specification's depictions of present technology suggest that a person of ordinary skill in the art would understand a device connected to the Internet through a local wireless connection to be part of the "wired computer network." See id. at 1:24-25.

Google's expert confirms this reading, testifying that devices wirelessly connected to the Internet would employ a communication protocol ("TCP/IP") different than devices on a wireless network. (Dkt. no. 354-1 ¶¶ 70-74.) Because devices using the TCP/IP communication protocol would not need a proxy gateway to enable communication with the wired network, those devices would not be part of the wireless network envisioned by the patent. Even though Wi-Fi technology allowed devices to connect wirelessly to the Internet at the time of the invention, Google's expert clarified that those devices would be part of a wired network. (Id. ¶ 71.) The intrinsic evidence, however, is sufficient to support Google's proposed construction. Accordingly, the Court construes "wireless network" as "network components for transmitting and/or receiving data wirelessly over a wide area."

D. '087 Patent

The '087 Patent discloses technology to facilitate the transmission and display of images on mobile devices. The disputed claim terms appear in Claims 1, 17, 27, and 31. The following proposed constructions appear in a Joint Status Report (dkt. no. 404) the parties submitted after the Markman hearing. The Court notes that neither party had an opportunity to brief their revisions. The Court therefore draws on relevant arguments in the parties' claim construction briefs and from the Markman hearing.

1. "reduced image"

Unwired's Revised Proposed Construction	Google's Revised Proposed Construction
"a version of the image with smaller dimensions"	"an uncropped version of the image with smaller dimensions"

The parties dispute whether a "reduced image" may be cropped. Google argues that a reduced image must preserve the integrity of the original image. (See Tr. at 336:18-337:8.) Unwired disagrees, contending that the specification explicitly discloses reduced images that are cropped. (See Tr. at 432:4-6.) The Court adopts Google's revised proposed construction.

Although the intrinsic evidence does not explicitly define the disputed term, the claims and specification discuss a reduced image in the context of "preprocess[ing]" or "transform[ing]" an original image for display on a mobile device. See '087 Claims 1, 27; id. at 3:9-13, 7:17-23, 8:13-17; see also id. at Claims 17, 31 (disclosing an image hierarchy that begins with a reduced image and that is generated from a larger image). For example, Claim 1 discloses a method that includes a "reduced image transformed from the image with respect to a set of parameters associated with the screen." Id. at Claim 1. The specification further states that "[a]ccording to the principles of this invention, an image being requested by the mobile device is first preprocessed in a server that reduces the dimensions . . . for display on the screen of a mobile device." Id. at 3:9-12. The specification notes that in one embodiment, "[o]ne aspect of the preprocessing is to reduce or decimate image 500 to the size of 70 by 60 pixels," id. at 7:18-20, and in another embodiment, a reduced image "is a transformed image from the original image and preferably fits perfectly in the screen of the mobile device." Id. at 8:15-17. These references suggest that a reduced image has smaller dimensions than an original image. Both parties' revised proposed constructions account for this aspect of the disputed term. The intrinsic evidence, however, does not specify whether a reduced image may be produced by cropping an original image.

Unwired argues that an embodiment depicted in Figures 5A through 5D specifies that a reduced image may be cropped. (Tr. at 342:12-18.) Figure 5A depicts "an exemplary image 500 that may be fetched from a service server on the Internet," '087:7:1-3; Figure 5B, in turn, shows a "reduced image 504 being displayed on screen 502 of mobile device 350," id. at 7:24-25; Figure 5C shows "the detailed version" of an area of the image — a map — displayed in Figure 5B, id. at 7:48; finally, Figure 5D shows "the details" of a particular section of the map area displayed in Figure 5C. Id. at 7:49. Unwired contends that "Figure 5B, a map of the entire United States, is a 'reduced image' of Figure 5C, a map of the western portion of the country." (Dkt. no. 353 at 39.) Unwired points to the specification's brief description of the drawings, which describes Figures 5B, 5C, and 5D as "show[ing] a reduced image being displayed on a screen of a mobile device." '087:2:66-67. But in explaining Figures 5B, 5C, and 5D, the specification uses "reduced image" only to refer to Figure 5B, not Figures 5C and 5D. See id. at 7:23-56. Figures 5C and 5D are distinguished from Figure 5B in terms of the level of detail depicted — the specification describes Figure 5C as "the detailed version" of an area displayed in Figure 5B. Id. at 7:48. Based on Figure 5's description, the Court finds that Google's revised proposed construction encompasses this embodiment.

Additionally, Unwired points to Figure 6B, "a process flowchart of the image navigation process." '087:7:57-58; (Tr. at 342:19-343:3). The flowchart includes steps for "generating" and "forwarding reduced image data." '087 Fig. 6B. Unwired contends that the use of the term "reduced image data" indicates that Figures 5C and 5D are reduced images. The specification, however, clarifies that the generating step described in Figure 6B creates "an image hierarchy that starts with the reduced image." '087:8:50-51. Thus, contrary to Unwired's argument, Figure 6B does not clarify whether reduced images may be cropped.

In light of the ambiguity created by the specification regarding the scope of the disputed term, the Court also considers extrinsic evidence. In testifying to his understanding of the disputed term, an inventor stated that cropping was not meant by "reduced image." (Dkt. no. 354-20 at 14-15.) Considered alongside the intrinsic evidence and the inventor testimony, Google's revised proposed construction captures the meaning of "reduced image" as taught by the patent. The Court therefore adopts the following construction: "an uncropped version of the image with smaller dimensions."

2. "key in the mobile device corresponding to a subarea in the reduced image" and "key in the input means corresponding to a subarea in the reduced image"

Unwired's Revised Proposed Construction	Google's Revised Proposed Construction
"a button or touch input corresponding to a subarea ofJ the reduced image"	"a button, either physical or depicted on the screen, cJorresponding to a subarea of the reduced image"

The parties dispute what form a "key" may take. Unwired argues that a key may be either a button or a touch input, while Google insists that a key must be in the form of a button, but it may be physical or depicted on a screen. The Court agrees with Google.

Both parties' revised proposed constructions appear to acknowledge that a key may be depicted on a screen, absent a physical key. The patent teaches this construction. The disputed term appears in Claims 1 and 27: Claim 1 describes a method involving a "key in the mobile device," and Claim 27 discloses an apparatus that comprises a "key in the input means." Claim 30, a dependent claim of Claim 27, indicates that the apparatus disclosed in Claim 27 may include an "input means" in the form of "soft keys displayed in the screen." '087 Claim 30. Furthermore, the specification states that "some of the mobile devices sometimes have no physical keys at all, such as those palm-size computing devices that . . . use soft keys or icons for users to activate them by using a finger or a pseudo-pen." Id. at 4:40-43. The specification goes on to clarify that "unless otherwise specifically described, keys or buttons are generally referred to as either the physical keys or soft keys." Id. at 4:43-45. Although these statements indicate that "key" covers more than a physical button or physical key, they do not suggest that a "key" includes any form of touch input, as Unwired contends.

The Court finds that Unwired's use of "touch input" imports ambiguity into the term that does not appear in the patent. The only language in the specification that could support this broad construction is the description quoted above, which clarifies that some mobile devices lack physical keys. See '087:4:39-43. Except for devices that may be activated "using a finger or a pseudo-pen," id., the specification does not make clear what, if any, other forms of touch inputs the patent encompasses. Google's revised proposed construction more accurately reflects this passage by specifying that a key, even when depicted on a screen, refers to a particular form of input — a button. The Court therefore adopts Google's revised proposed construction.

3. "A reduced image equally divided into a number of subareas, each of the subareas pointing to a detailed version thereof"

Unwired's Revised Proposed Construction	Google's Revised Proposed Construction
"a reduced image equally divided into a number of subareas, each of which points to a detailed version of that subarea"	"a reduced image equally divided into a number of subareas, each of which provides a link to a detailed version of that subarea"

This dispute centers on the phrase "pointing to." Unwired asks the Court to give the term its plain meaning by construing it as "which points to." Google argues that, based on the specification, the term means "provides a link to." The Court will construe the term because the parties dispute its plain meaning. See O2 Micro, 521 F.3d at 1361. Because Unwired's proposal repeats the disputed term without offering a plain and ordinary meaning, the Court adopts Google's proposal.

Unwired objects to Google's proposed construction because it defines "pointing" with the terms "provide" and "link." Unwired suggests that "pointing" is clear on its face, stating during the Markman hearing that a lay juror would understand the term as "identifying] from a distance." (Tr. at 367:16-17.) Unwired cites several non-asserted claims involving "subareas embedded with a hyperlink," '087 Claims 10, 14, and "subareas being provided with a hyperlink." Id. at Claims 23, 34. Unwired contends that these claims dictate a plain meaning construction because they discuss a hyperlink — if the inventor intended to limit this claim to subareas with a link, then the claim would so specify. Unwired also argues that the specification uses "link" and "hyperlink" interchangeably, such that importing "link" into the disputed term would replicate these non-asserted claims.

Notwithstanding these non-asserted claims, the intrinsic evidence supports construing "pointing" as "provides a link to." The term appears in Claims 17 and 31, which describe "pointing to" in the context of an "image hierarchy starting with a reduced image." In contrast, the claims disclosing hyperlinked subareas involve a reduced image. See id. at Claims 10, 14, 23, 34. This distinction suggests that a hyperlink performs a specific function in the absence of an image hierarchy. Moreover, in describing an embodiment of an image hierarchy, the specification notes that "[e]ach of the subareas" in a reduced image "includes a link to a detailed version thereof." Id. at 8:54-55. The specification also describes a subarea "that points to a detailed version 708." Id. at 8:56-57. In these passages, the specification uses "link" to describe "pointing." See id. at 8:51-63. Additionally, the summary of the invention and the abstract describe a reduced image that is divided into subareas, "each embedded a link to a detailed version thereof." Id. at Abstract, 2:15-18. Given the uniform use of "hyperlink" in Claims 10, 14, 23, and 34, and the fact that the specification uses "link" to broadly describe the subareas of a reduced image, the Court finds that Google's proposal appropriately construes the disputed term. The Court adopts Google's revised proposed construction.

E. '016 Patent

The '016 Patent involves technology for transmitting and displaying location information graphically on a mobile device. The disputed terms appear in Claim 1.

1. "first transmitting in a first message set, said mapping information from said server node to said client node; second transmitting in a second message set, said marker information from said server node to said client node"

Unwired's Proposed Construction

Google's Proposed Construction

For "first transmitting in a first message set, said mapping information from said server node to said client node": "transmitting said portion of a map from said server node to said client node" For "second transmitting in a second message set, said marker information from said server node to said client node": "transmitting said information related to the location of said mobile resource from said server node to said client node"

"first transmitting in a first message set, said mapping information from said server node to said client node; second transmitting, after said mapping information has been transmitted, in a second message set, said marker information from said server node to said client node"

The parties dispute whether the two steps described in this term — transmitting mapping information and transmitting marker information — must be performed in the order in which they appear in Claim 1. Unwired contends that the '016 Patent's technological innovation is allowing such mapping and marker information to be sent separately to a mobile device. Therefore, according to Unwired, the terms "first" and "second" do not require mapping information to be sent before marker information. Rather, the terms are labels conventionally used in patents to distinguish between two steps; here, they distinguish between two transmissions, and the two types of information transmitted. Google argues that the term requires mapping information to be sent before marker information. The Court finds that Unwired's proposed construction gives the terms their "ordinary and customary meaning." Phillips, 415 F.3d at 1312-13.

"Unless the steps of a method actually recite an order, the steps are not ordinarily construed to require one." Interactive Gift Express, 256 F.3d at 1342. Claim terms may, however, "implicitly require that [method steps] be performed in the order written." Id. The Federal Circuit has defined a two-part test for determining whether claim terms must proceed in a particular sequence in the absence of a recited order. Altiris, Inc. v. Symantec Corp., 318 F.3d 1363, 1369 (Fed. Cir. 2003). First, the court examines "the claim language to determine if, as a matter of logic or grammar, they must be performed in the order written." Id. Second, if neither logic nor grammar dictates a particular sequence, the court "look[s] to the rest of the specification to determine whether it directly or implicitly requires such a narrow construction." Id. at 1370 (citation and internal quotation marks omitted) (emphasis omitted).

Here, the terms "first" and "second" do not suggest, either on their face or "as a matter of logic or grammar," that the method requires mapping information to be transmitted before marker information. See id. at 1369. Rather, the terms imply separate transmissions of separate data. Google cites three distinguishable cases to argue otherwise. First, Google relies on Mantech Environmental Corp. v. Hudson Environmental Services, Inc., 152 F.3d 1368, 1376 (Fed. Cir. 1998), to argue that "the sequential nature of the claim steps is apparent from the plain meaning of the claim language." The claim terms in Mantech Environmental, however, described environmental remediation steps that could not occur in the absence of a prior step. See id. at 1375-76. Similarly, in Atmel Corp. v. Information Storage Devices, Inc., 997 F. Supp. 1210, 1223 (N.D. Cal. 1998), a court in the Northern District of California reasoned that the term "first" signified that a step in a seven-part sequence must occur first. Each following step referenced elements of the preceding steps — including the step labeled "first" — indicating that they occurred sequentially. Id. Here, in contrast, the disputed term does not suggest that marker information cannot be transmitted before mapping information. Aside from the word "second," nothing in the latter part of the term references or builds upon the fact that mapping information has been transmitted before marker information.

Citing 3M Innovative Properties Co. v. Avery Dennison Corp., 350 F.3d 1365, 1371-73 (Fed. Cir. 2003), Google suggests that the terms "first" and "second" lend a different meaning to the claim when they appear in a method claim, as opposed to a product claim. There, the Federal Circuit noted that "[t]he use of the terms 'first' and 'second' is a common patent-law convention to distinguish between repeated instances of an element of limitation." Id. at 1371. The court held that the use of "first . . . pattern" and "second . . . pattern" in the disputed term "should not in and of itself impose a serial or temporal limitation onto [the claim at issue]." Id. (internal quotation marks omitted). The court compared the disputed term to a method claim in the patent-in-suit, which distinguished between a "first embossing step" and a "second embossing step." Id. at 1372. Emphasizing that this latter method claim described two serial steps, the court concluded that reading a sequential limitation into the disputed term would be improper. Id. Although the disputed term here includes two steps in a method claim, Claim 1 does not explicitly disclose a sequential "first transmitting step" and a "second transmitting step." See '016 Claim 1. Rather, the term describes "first transmitting" and "second transmitting" as two separate transmission steps. The plain language of Claim 1 thus supports Unwired's proposed construction.

Furthermore, the specification does not suggest that the term implicitly requires a sequential construction. For example, the specification describes transmitting "a first message set including the mapping information" and "a second message set" of marker information as part of the claimed method steps. Id. at 2:49-55. In the following lines, the specification notes the advantages of "separately providing the mapping information and marker information," id. at 2:56-58, and clarifies that "the mapping information and marker information can be transmitted at different times or via different paths." Id. at 3:7-9; see also id. at 10:1-12 (describing separate message sets used to transmit mapping and marker information). These descriptions indicate that although mapping information may precede marker information, it need not.

The prosecution history likewise indicates that the transmissions do not need to be sequential. In initially rejecting Claim 1 of the '016 Patent for obviousness, the patent examiner pointed out three ways to transmit mapping and marker information, and noted that "it makes sense to transmit the mapping information first because the mapping information generated the background of the display." (Dkt. no. 354-10 at 7.) Google argues that this comment suggests that the examiner understood Claim 1 as requiring a sequential transmission of mapping and marker information. In response to these comments, however, the patentee clarified that mapping information may be "sent in a first message set or otherwise separately obtained." (Dkt. no. 354-11 at 12-13.) The patentee does not appear to have amended this portion of Claim 1 in responding to the obviousness issue. (See id. at 18.) Thus, as written, this term does not require mapping information to be transmitted before marker information. The Court adopts Unwired's proposed construction.

2. "processing said network location information regarding said mobile resource location, at said server node, to generate marker information defining a graphical representation of said mobile resource location"

Unwired's Revised Proposed Construction	Google's Revised Proposed Construction
"at said server node, processing said network location information regarding said mobile device location to generate location information that permits rendering on the client node an identifier indicating the position of said mobile device on a map" (Tr. at 391-93, 394:7-10)	"at said server node, processing said network location information regarding said mobile device location to generate graphical location information sufficient to render an identifier and including coordinates indicating the position of said mobile device on a map" (Tr. at 399:1-6)

Unwired initially proposed: "using said network location information regarding said mobile resource location, at said server node, to generate information related to the location of said mobile resource where the information is used in the graphical representation of said mobile resource location at the client mode." (Dkt. no. 351 -1 at 13.)

Google amended its proposal to include "coordinates," which the Court proposed to resolve, in part, the parties' dispute. (Tr. at 398:16-23.)

This term is a step in the "method for use in providing location information regarding mobile resources in a data enabled network" disclosed in Claim 1. The parties dispute three aspects of this term: (1) whether the marker information generated from the network location information must be in graphical form; (2) the extent to which that marker information — in either graphical or non-graphical form — renders an identifier; and (3) whether that rendering occurs on the client node. The Court agrees with Google's proposed construction.

As to the parties' first dispute, Unwired stresses that "marker information" need not appear in graphical form because the specification allows "[s]uch information [to] simply include coordinates, which may be represented by a cursor, crosshairs, a point or other identifier." '016:10:15-17. The specification also states that "the location information may include coordinates with an uncertainty radius or other defined uncertainty region." Id. at 10:17-19. Unwired's proposal, however, ignores the plain language of Claim 1, which states that marker information "defin[es] a graphical representation." Instead, under Unwired's proposal, "network location information" is processed to generate "location information" that permits an identifier to be rendered. (Tr. at 391:4-9). This construction muddles the claim term. Whereas the claim states that marker information "defin[es] a graphical representation," it is not clear from Unwired's proposal whether marker information may appear in graphical form, or whether the rendered identifier may be graphical. '016 Claim 1. As revised, Google's proposal specifies that marker information includes coordinates. Google's proposed construction thus encompasses both the specification and the claim's plain language — graphical location information and coordinates "defin[e] a graphical representation." '016 Claim 1.

The parties' second dispute involves the mechanism through which the location information renders an identifier. Unwired argues that the location information "permits rendering," whereas Google contends that location information must be "sufficient to render." Unwired derived its proposal from a clause that immediately follows the disputed term in Claim 1 and that states: "said marker information represents said network location information so as to permit graphical combination of said marker information with said mapping information." Id. at Claim 1, 13:14-17. This clause — which the parties do not dispute — appears to describe why the marker information "represents said network location information," whereas the disputed term describes what information is encompassed by the term "marker information." See id. at Claim 1. Google's construction focuses on the latter. Google relies on language in the specification explaining that "the marker information includes information sufficient to define a graphical representation of the mobile resource location." Id. at 10:13-15. Google's proposal more appropriately describes the disputed term because it discloses what marker information includes.

Finally, Google objects to Unwired's attempt to insert "client node" into the disputed term. Unwired argues that "client node" will help clarify the term for the jury. (Tr. at 393:21-24.) The disputed term, however, makes no reference to the client node. See '016 Claim 1. Moreover, the references to rendering that appear in both parties' proposals define the type of location information that is created after the network location information is processed. Rather than clarifying this definition, Unwired's proposal refers to a separate rendering process that is not encompassed by the disputed term. Accordingly, the Court adopts Google's revised proposed construction.

3. "network location information regarding a mobile resource location"

Unwired's Proposed Construction	Google's Revised Proposed Construction
"information relating to the location of a mobile resource"	"information providing the location of a mobile device within a network" (Tr. at 412:11-12)

Google initially proposed: "information defining the location of a mobile device within a network" (dkt. no. 351-1 at 12), but replaced "defining" with "providing" to reflect the patent's prosecution history. (Tr. at 409:22-410:12, 412:9-12.)
--------

Unwired's proposal broadens the disputed claim term in two ways. First, Unwired drops the term "network" from its proposed construction, arguing that the claim already specifies that a mobile device must be located in a network. Second, Unwired suggests that "regarding" is clear on its face, or is best defined by "relating to," and that both constructions are broader than "providing." (See Tr. at 401:5-7.) The Court finds these arguments unavailing and adopts Google's revised proposed construction.

Unwired insists that adding "within a network" to this term will cause jury confusion and redundancy because the term is followed by a clause stating that "said network location information is based on the location of said mobile device in relation to at least one fixed ground-based wireless network." '016 Claim 1, 13:3-5. (emphasis added). Even in light of this clause, Unwired's proposal ignores the fact that "network" appears in the disputed term. See id. at Claim 1. Moreover, construing the disputed term to mean "within a network," as Google proposes, does not appear to be inconsistent with the clause that Unwired highlights — the clause indicates how network location information is determined, but the disputed term defines what network location information is. See id. The prosecution history also suggests that "within a network" is not redundant. To avoid an obviousness rejection, the patentee inserted "network" into the phrase "network location information." (See dkt. no. 354-11 at 18.) The patentee distinguished this patent from an earlier patent, which "[could not] provide location information for any non-GPS capable mobile resource in the wireless network." (Id. at 14 (emphasis added).) Reading "network" out of the disputed term thus departs from the term's plain meaning, as indicated by the claim itself and the prosecution history. Accordingly, the Court finds that "within a network" is part of an appropriate construction of the disputed term.

Unwired makes two arguments to support its proposal that information must "regard" or "relate to" a device's location. First, Unwired suggests that the plain language of the disputed term — "regarding a mobile resource location" — is clear. (Tr. at 401:5-7.) Even assuming that "regarding" has one plain meaning, the Court will construe the term because the parties dispute its scope. See O2 Micro, 521 F.3d at 1361. Second, pointing to the same clause in Claim 1 discussed above, Unwired argues that because network location information is merely "based on" a mobile resource's location, there is no need for such information to "provide" a device's location. See '016 Claim 1. As with Unwired's objection to "within a network," this argument focuses too heavily on how network location information is generated, rather than what that information says about a device.

In contrast, Google's proposal finds support in the prosecution history. A patentee may disavow certain constructions by "explicitly characterizing] an aspect of his invention in a specific manner to overcome prior art." Purdue Pharma L.P. v. Endo Pharm. Inc., 438 F.3d 1123, 1136 (Fed. Cir. 2006). Here, to contest an obviousness rejection, the patentee used network location information to distinguish this patent from a prior patent that claimed a GPS-based location system. (Dkt. no. 354-11 at 13-14.) The patentee stated that "network location information provides a mobile resource location that is based at least in part upon the location of that mobile resource relative to one or more fixed ground-based wireless network structures that have a known geographic location." (Id. at 13 (emphasis added).) The patentee further noted that the prior patent "cannot provide location information for any non-GPS capable mobile resource in the wireless network." (Id. at 14 (emphasis added).) Based on this prosecution history, the Court disagrees with Unwired's contention that network location information need not provide a mobile location. The Court adopts Google's revised proposed construction.

4. "a server node"

Unwired's Proposed Construction	Google's Proposed Construction
plain meaning or "one or more computers or programs that provide access to resources to client nodes"	"an individual computer that performs each of the receiving, accessing, processing, and transmitting services specified in the claims"

The parties dispute whether a "server node" may include more than one computer, and whether, if more than one computer is involved, each computer must perform every step of the claimed process. Google argues that Unwired's proposal reads "node" out of the term because it limits a "server node" to only one computer. Moreover, even if a server node contains more than one computer, Google argues that each computer must perform every step described in the claim. Unwired contends that Google excludes embodiments containing multiple computers, and argues that Google's inclusion of "receiving, accessing, and processing" steps is superfluous because Claim 1 specifies which actions must take place at the server node. Although Unwired argues that the plain meaning should control, the parties "raise an actual dispute regarding the proper scope of [the] claim." O2 Micro, 521 F.3d at 1360. The Court will construe the term. See id. at 1361. The Court adopts a modified version of both parties' proposals.

The intrinsic evidence does not resolve the parties' dispute. First, the specification refers to a server and to a server node, but never distinguishes the two. While the specification describes several embodiments involving a server, the term "server node" appears only in the summary of the invention and the claims. See, e.g., '016 Claim 1 (disclosing a server node that communicates with a client node, receives network location information, accesses geographical mapping information, and transmits mapping and marker information); id. at 2:40-55 (specifying that the server node accesses and transmits mapping information and marker information); id. at 10:9-12, 40-42 (describing message sets containing marker and mapping information transmitted by a server); id. at 11:24-41 (describing monitoring parameters defining information that a server may receive). The embodiments, however, describe examples of the communicating, receiving, processing, and transmitting functions disclosed in Claim 1. See id. at 6:19-6:26 (communicating); id. at 7:61-8:22, 9:62-10:26 (transmitting); id. at 9:14-61 (describing components that a server may include, such as a processor); 11:24-41 (receiving). The prosecution history similarly appears to use the terms interchangeably, describing a server that provides location information to a client, and a server node that receives network location information and then provides and transmits mapping and marker information to a client node. (Dkt. no. 354-11 at 13.)

During the Markman hearing, Unwired contended that a "server" is transformed into a "server node" when it is connected to a "data-enabled network." (Tr. at 421:8-18). Unwired also notes that a server that may include several components — including a processor, a mapping database, and an interface module with other sub-components — that would allow more than one computer to carry out the server's functions. See '016:9:13-17. Because the same hardware appears in both a server and a server node connected to a network, Unwired argues that a server node may include more than one computer, and that each computer within the server node need not perform every step described in the patent. (Tr. at 422:10-423:14.) Although Unwired is correct that the term "server node" appears where the patent discusses a "data-enabled network," it is not clear that the network transforms a server into a server node, or that a server's architecture is replicated in the server node. See '016:2:40-43.

For its part, Google points to a claim construction order issued by a court in the Southern District of Indiana, which construed a "server" or "call processing server" as "a computer running software to perform each of the call processing services specified in the claims." One Number Corp. v. Google Inc., No. 1:10-cv-312-RLY-TAB (S.D. Ind. Mar. 31, 2014) (dkt. no. 354-27). The One Number construction is premised on the "general rule [that] the words 'a' or 'an' in a patent claim carry the meaning of 'one or more.'" TiVo, Inc. v. EchoStar Commc'ns Corp., 516 F.3d 1290, 1303 (Fed. Cir. 2008). The One Number court noted that the relevant claims described a "server" or "call processing server" as carrying out "all of the claimed call processing functions." (Dkt. no. 354-27 at 4.) Moreover, the specification at issue did not mention other devices that could perform those call processing functions. (Id.) Finally, the prosecution history included a disclaimer that devices incapable of performing the claimed call processing functions were not "call processing servers." (Id. at 5.) Although the prosecution history here does not appear to contain such a disclaimer, the claims and specification indicate that the server node alone performs the receiving, accessing, processing, and transmitting functions in Claim 1.

Finally, to support its argument that "server node" means a single computer, Google turns to a definition of "node" that appears in a 1999 computer dictionary, which defines "node" as "an individual computer (or occasionally another type of machine) in a network." (Dkt. no. 354-26 at 4.) This definition conflicts with extrinsic evidence cited by Unwired. Unwired points to an alleged implementation of the patent and inventor testimony that explain that a server node may include more than one computer. The inventor, however, also suggested that he used the terms "server" and "node" interchangeably. (See dkt. no. 353-15 at 8-9.) Thus, although Unwired's extrinsic evidence suggests that in the context of this patent, a server node may include more than one computer, it does not clarify whether each computer must perform all the relevant functions.

Considering the intrinsic and extrinsic evidence, the Court adopts, in part, both parties' proposed constructions. The Court construes "a server node" as "one or more computers, each performing the receiving, accessing, processing, and transmitting services specified in the claims."

V. CONCLUSION

It is ordered that the disputed claim terms are to be construed consistent with this Order. It is further ordered that Plaintiff Unwired Planet, LLC's request to correct the following term is denied: "cause said fleet data pushed by said proxy server module to the plurality of mobile stations."

ENTERED THIS 12^th day of December 2014.

/s/_________

MIRANDA M. DU

UNITED STATES DISTRICT JUDGE

Unwired Planet, LLC v. Google Inc.

Summary

Opinion

I. INTRODUCTION

II. BACKGROUND

III. LEGAL STANDARD

IV. DISCUSSION

V. CONCLUSION

Unwired Planet, LLC v. Google Inc.

Unwired Planet, LLC v. Google Inc.

Case Details

Citations

Citing Cases

Unwired Planet, LLC v. Google Inc.

Summary

Opinion

I. INTRODUCTION

II. BACKGROUND

III. LEGAL STANDARD

IV. DISCUSSION

V. CONCLUSION

Unwired Planet, LLC v. Google Inc.

Unwired Planet, LLC v. Google Inc.

Case Details

CitationsCopy Citation

Citing Cases

Citations