throbber
Trials@uspto.gov
`571-272-7882
`
`
`
`
`Paper No. 7
`Entered: December 4, 2019
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`MICROSOFT CORP.,
`Petitioner,
`
`v.
`
`UNILOC 2017 LLC,
`Patent Owner.
`____________
`
`IPR2019-01026
`Patent 6,993,049 B2
`____________
`
`Before SALLY C. MEDLEY, JEFFREY S. SMITH, and GARTH D. BAER,
`Administrative Patent Judges.
`
`BAER, Administrative Patent Judge.
`
`
`
`DECISION
`Instituting Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`
`

`

`IPR2019-01026
`Patent 6,993,049 B2
`
`
`I.
`INTRODUCTION
`Microsoft Corporation (“Petitioner”) filed a Petition (Paper 1, “Pet.”),
`requesting an inter partes review of claims 11 and 12 (the “challenged
`claims”) of U.S. Patent No. 6,993,049 B2 (Ex. 1001, “the ’049 Patent”).
`Uniloc 2017 LLC (“Patent Owner”) filed a Preliminary Response to the
`Petition (Paper 6, “Prelim. Resp.”).
`We have authority to determine whether to institute an inter partes
`review. For the reasons discussed below, we grant the Petition and institute
`an inter partes review.
`
`A. THE ’049 PATENT
`The ’049 patent is directed to a communication system comprising a
`primary station and one or more secondary stations. Ex. 1001, Abstract.
`The primary station broadcasts a series of inquiry messages and adds to the
`inquiry messages an additional data field for polling secondary stations. Id.
`This system is useful for communications between the stations without
`requiring a permanently active link, such as is common with the Bluetooth
`communications protocol. Id.
`
`B. ILLUSTRATIVE CLAIM
`Petitioner challenges claims 11 and 12 of the ’049 Patent. Claim 11 is
`the only independent challenged claim and is reproduced below:
`
`11. A method of operating a communication system comprising
`a primary station and at least one secondary station, the method
`comprising the primary station broadcasting a series of inquiry
`messages, each in the form of a plurality of predetermined data
`fields arranged according to a first communications protocol,
`and adding to an inquiry message prior to transmission an
`additional data field for polling at least one secondary station,
`and further comprising the at least one polled secondary station
`
`2
`
`

`

`IPR2019-01026
`Patent 6,993,049 B2
`determining when an additional data field has been added to the
`plurality of data fields, determining whether it has been polled
`from the additional data field and responding to a poll when it
`has data for transmission to the primary station.
`Ex. 1001, 8:35–47.
`
`C. ASSERTED GROUNDS OF UNPATENTABILITY
`Petitioner asserts the following grounds of unpatentability. Pet. 2.
`
`References/Basis
`Claims Challenged 35 U.S.C. §
`Larsson1, Bluetooth Specification2,
`11, 12
`103
`RFC8263
`802.114
`11, 12
`103
`II. DISCUSSION
`A. CLAIM CONSTRUCTION
`In inter partes reviews, we interpret claims “using the same claim
`construction standard that would be used to construe the claim in a civil
`action under 35 U.S.C. 282(b).” 37 C.F.R. § 42.100(b). Under this
`standard, we construe claims “in accordance with the ordinary and
`customary meaning of such claim as understood by one of ordinary skill in
`the art and the prosecution history pertaining to the patent.” Id. Only claim
`terms that are in controversy need to be construed and only to the extent
`
`                                                            
`1 U.S. Patent No. 6,704,293 B1 (iss. Dec. 6, 1999) (Ex. 1004, “Larsson”).
`2 Bluetooth™ Core Specification Vol. 1, ver. 1.0 B (pub. Dec. 1, 1999)
`(Ex. 1005, “Bluetooth Specification”).
`3 David C. Plummer, An Ethernet Address Resolution Protocol,
`IETF Request for Comments No. 826 (Pub. Nov. 1982) (Ex. 1006,
`“RFC826”).
`4 ANSI/IEEE Std 802.11, Part 11: Wireless LAN Medium Access
`Control (MAC) and Physical Layer (PHY) Specifications
`(pub. Aug. 20, 1999) (Ex. 1007, “802.11”).
`
`3
`
`

`

`IPR2019-01026
`Patent 6,993,049 B2
`necessary to resolve the controversy. See Nidec Motor Corp. v. Zhongshan
`Broad Ocean Motor Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017).
`Petitioner does not propose any terms for claim construction. See
`Pet. 11–12. Patent Owner proposes we construe “additional data field” as
`“an extra data field appended to an inquiry message.” Prelim. Resp. 5–7.
`We disagree with Patent Owner’s construction. Independent claim 11
`already has language that accounts for the language Patent Owner seeks to
`add through claim construction. Specifically, we do not need to construe an
`“additional data field” as “an extra data field appended to an inquiry
`message” because the challenged claims already recite “adding to an inquiry
`message . . . an additional data field.” Ex. 1001, 8:39–40. To the extent
`Patent Owner seeks to distinguish “appending” from “adding,” on this
`record and for purposes of this Decision, we do not view those two terms as
`meaningfully distinct. To the extent Patent Owner wishes to develop its
`argument in subsequent briefing, we will revisit the issue. However, based
`on the current record and for purposes of this decision, we decline to adopt
`Patent Owner’s proposed construction of “additional data field.”
`B. ASSERTED PRIOR ART
`
`1. Larsson (Ex. 1004)
`Larsson discloses a:
`
`method and/or an apparatus which places a broadcast message
`which the source expects a reply message in a broadcast message
`for route discovery. The combined message is broadcast
`throughout the ad-hoc network. When the combined broadcast
`message is received at the destination node, the destination node
`generates a response message including a reply message to the
`broadcast message including a reply message that the source
`node expects a reply. The response message is sent back to the
`source node over the route which the combined broadcast
`message traveled to the destination node.
`
`4
`
`

`

`IPR2019-01026
`Patent 6,993,049 B2
`Ex. 1004, Abstract.
`2. Bluetooth Specification (Ex. 1005)
`Bluetooth Specification defines requirements for a transceiver
`operating the Bluetooth wireless communication protocol. Ex. 1014, 18.
`Section 4.4 discusses different data packet types, id. at 55, and Section 4.5
`provides detail of the payload within a packet, including a data field, id. at
`62.
`3. RFC826 (Ex. 1006)
`Relevant to this case, RFC826 describes the structure and content of
`Ethernet Address Resolution Protocol (ARP) messages. Ex. 1006, 1.
`4. 802.11 (Ex. 1007)
`802.11 is an IEEE standard that specifies “[t]he medium access
`control (MAC) and physical characteristics for wireless local area networks
`(LANs).” Ex. 1007, iii. The network includes a basic service set (BSS),
`which is “[a] set of stations controlled by a single coordination function.”
`Id. at 3. To communicate with other stations, a station uses a scan function
`to “determin[e] the characteristics of the available BSSs.” Id. at 101.
`“Active scanning involves the generation of Probe frames and the
`subsequent processing of received Probe Response frames.” Id. at 126. A
`typical broadcast probe request message seeks a response from any BSS and
`does not include the address of a specific SSID. Ex. 1003 ¶ 43 (citing
`Ex. 1007, 126, Fig.66). If a device wishes to probe a specific BSS, however,
`then it includes the SSID of the specifically-targeted BSS during the active
`scanning process. Id. (citing Ex. 1007, 126).
`
`5
`
`

`

`IPR2019-01026
`Patent 6,993,049 B2
`
`C. UNPATENTABILITY
`1. First Ground: Obviousness over Larsson, Bluetooth Specification, and
`RFC826
`Petitioner asserts that claims 11 and 12 would have been obvious in
`view of Larsson, Bluetooth Specification, and RFC826. Pet. 2. Based on
`the current record and as explained below, we find Petitioner has made an
`adequate showing that claims 11 and 12 would have been obvious over
`Larsson, Bluetooth Specification, and RFC826. See id. at 12–39.
`Petitioner relies primarily on Larsson for disclosing the claimed
`method of adding additional data fields to broadcast messages. See id. at
`24–39. As Petitioner notes, “Larsson implements a route discovery
`technique that piggybacks certain types of broadcast messages onto a route
`discovery broadcast messages.” Id. at 13 (internal quotation marks omitted).
`Petitioner identifies “using ‘ARP [Address Resolution Protocol] broadcast
`messages’ in a Bluetooth scatternet” as “an ‘exemplary method’ for
`‘triggering route discovery.’” Id. at 22 (citing Ex. 1004, 7:37–46, 7:15–38,
`Fig. 7); see also id. at 5, 13. Petitioner emphasizes that Larsson uses the
`same “piggyback” language as the ’049 patent to describe adding an
`additional field onto a broadcast message prior to transmission. Id. at 1; see,
`e.g., id. at 13, 14, 15, 22, 24, 32.
`Petitioner explains that although “Larsson discloses broadcasting
`messages using the Bluetooth protocol,” it “does not explicitly disclose the
`structure of these messages.” Id. at 18 (citing Ex. 1005, 5:35–50). Thus,
`Petitioner relies on Bluetooth Specification for teaching that the Bluetooth
`packet general format includes three fields. Id. at 16 (citing Ex. 1005,
`Fig. 4.1). Petitioner explains, with support from its declarant Mr. Rysavy,
`that “a POSITA implementing Larsson would have naturally turned to the
`
`6
`
`

`

`IPR2019-01026
`Patent 6,993,049 B2
`then-current Bluetooth Specification (Ex. 1005), to insure proper
`implementation and use of the underlying Bluetooth protocol.” Id. at 18
`(citing Ex. 1003 ¶ 45). Petitioner further notes that although Larsson teaches
`“generating ARP broadcast messages and then piggybacking them onto
`route request messages,” “Larsson does not, however, provide details on the
`formatting or contents of ARP messages.” Id. at 22. Thus, Petitioner relies
`on RFC826 to fill in those details, including “that ADDRESS
`RESOLUTION packets (ARP messages) contain the Internet address of the
`destination node.” Id. at 34 (citing Ex. 1006, 3–4); see id. at 22. Petitioner
`explains, again with support from its declarant, that a skilled artisan would
`have combined RFC826 with Larsson because “RFC826 was well-known as
`the standard for ARP messaging” and “[a] POSITA . . . would have
`recognized the importance of implementing a system that fully complied
`with ARP messaging formats and contents.” Id. at 22–23 (citing Ex. 1003
`¶¶ 53–55).
`Based on the current record and for purposes of this Decision, we
`agree with Petitioner’s analysis. Specifically, Petitioner has explained
`sufficiently where the asserted combination of Larsson, Bluetooth
`Specification, and RFC826 teaches each limitation recited in claims 11 and
`12. See id. at 24–39. In addition, with the analysis outlined above,
`Petitioner has articulated sufficient reasoning with rational underpinning to
`support the legal conclusion that its proffered combination of Larsson,
`Bluetooth Specification, and RFC826 would have been obvious to one
`skilled in the art. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 418
`(2007). Patent Owner’s contests Petitioner’s showing related to a single
`limitation. We address Patent Owner’s argument below.
`
`7
`
`

`

`IPR2019-01026
`Patent 6,993,049 B2
`a. “adding to an inquiry message prior to transmission an additional
`data field for polling at least one secondary station,”
`Independent claim 11 requires “adding to an inquiry message prior to
`transmission an additional data field for polling at least one secondary
`station.” Petitioner asserts that Larsson teaches this limitation because
`“Larsson discloses ‘piggybacking’ other broadcast messages (adding
`additional data fields for polling) onto an [request for route] message.”
`Pet. 32 (citing Ex. 1004, Fig. 6a, 6:3–7, 7a, 7:50–53; Ex. 1003 ¶ 74). As
`Petitioner notes, “‘piggybacking’ is the same term used by the ’049 Patent to
`describe the process of adding an additional data field to an inquiry
`message.” Id. (quoting Ex. 1001, 4:15–18). Based on the current record and
`for purposes of this Decision, we agree with Petitioner that Larsson teaches
`the “adding . . . an additional data field” limitation.
`Patent Owner argues that Larsson does not adequately account for the
`“adding . . . an additional data field.” Prelim. Resp. 8–11. According to
`Patent Owner, Larsson “at most merely indicates that there is additional data
`within the message, not that there is an additional data field, as required by
`the claim language.” Id. at 9. We disagree. Larsson discloses more than
`just additional data. Larsson teaches that “the source node piggybacks the
`broadcast message.” Ex. 1004, 6:5 (emphasis added). Larsson’s
`“piggybacks the broadcast message” disclosure parallels closely the ’049
`patent’s description of adding a data field—i.e. “piggy-back[ing] a
`broadcast channel.” Ex. 1001, 4:16.
`Patent Owner further contends that Petitioner is wrong to equate
`Larsson’s piggy backing with adding an additional data field. See Prelim.
`Resp. 8. According to Patent Owner, the ’049 patent’s “piggy-back”
`passage does not characterize the adding-an-additional-data-field step.
`
`8
`
`

`

`IPR2019-01026
`Patent 6,993,049 B2
`See id. Instead, Patent Owner argues, the ’049 patent describes adding an
`additional data field later in the Specification, in a passage that uses the term
`“append[ing]” instead of piggy-backing. Id. (citing Ex. 1001, 4:59–62); see
`Ex. 1001, 4:60–62. We disagree with Patent Owner’s argument because the
`’049 patent’s “piggy-back” passage and the subsequent “append[ing]”
`passage clearly address the same adding-a-data-field step. See Ex. 1001,
`4:15–17 (explaining that “it is possible to piggy-back a broadcast channel on
`the inquiry messages” and “[t]he broadcast channel can be used to poll
`HIDs”) (emphasis added), id. at 4:59–62 (“As mentioned above and shown
`in FIG. 5, the applicants propose that the inquiry messages issued by the
`base station have an extra field 504 appended to them, capable of carrying a
`HID poll message.”) (emphasis added). In short, we agree with Petitioner
`that the Specification explicitly characterizes the additional data field as
`“piggy-back[ed].” See Pet. 32.
`2. Second Ground: Obviousness over 802.11
`Petitioner asserts that claims 11 and 12 would have been obvious in
`view of 802.11. Pet. 40. Based on the current record and for the reasons
`explained below, we find that Petitioner has shown sufficiently that Larsson
`renders obvious claims 11 and 12. See id. at 40–53.
`Petitioner Explains that 802.11 describes a local wireless network
`with different stations (STAs) communicating with one another according to
`a protocol. Id. at 40. “802.11 specifies that, as part of the active scanning
`process used to join a network, an STA broadcasts ‘Probe Requests,’” that
`include “predetermined data fields arranged according to the 802.11 wireless
`LAN protocol.” Id. at 46 (quoting Ex. 1007, 126); id. at 46–47 (citing
`Ex. 1007, 45, Fig. 23). Petitioner explains that 802.11 teaches the key
`“adding . . . an additional data field” limitation because it teaches
`
`9
`
`

`

`IPR2019-01026
`Patent 6,993,049 B2
`[a] Probe Request message is one of two types. A “broadcast”
`type seeks responses from all available access point stations, and
`is indicated by a “0 length” or null SSID. Another type of Probe
`Request, used when the station polls a specific access point, adds
`an additional data field, namely the SSID of that AP. In the latter
`type of probe request, which might be called a “targeted” probe
`request, the added SSID of the targeted station is “an additional
`data field for polling” that station.
`Id. at 48 (citing Ex. 1003 ¶¶ 101–104).
`Patent Owner argues that 802.11 does not teach the adding-an-
`additional-data-field step because “even when [the SSID information field’s]
`length is zero, [it] is nonetheless an existing field in 802.11’s probe request.”
`Prelim. Resp. 11. “[T]herefore,” Patent Owner contends, “merely pointing
`to the times when the ‘SSID information field’ is of non-zero length does not
`disclose adding ‘an additional data field’ as required by the claim language.”
`Id. Patent Owner further notes that a previous claim limitation recites
`“broadcasting a series of inquiry messages, each in the form of a plurality of
`predetermined data fields arranged according to a first communications
`protocol.” Id. at 13. The SSID information field is one the predetermined
`data fields, Patent Owner reasons, rather than an additional data field to be
`added to the inquiry message. Id. at 13.
`We find that the parties’ competing positions creates a genuine issue
`of material fact—i.e., whether a zero-length SSID information field is an
`existing field. According to Petitioner’s declarant, “[a] POSITA would
`understand that ‘0 length’ means that nothing is included for this SSID field,
`i.e., there is no SSID field.” Ex. 1003 ¶ 102. At this stage of the
`proceeding, we view evidence in the light most favorable to Petitioner. See
`37 C.F.R. § 42.108(c). Although we encourage the parties to develop this
`issue further during trial, on this record, Petitioner provides adequate
`
`10
`
`

`

`IPR2019-01026
`Patent 6,993,049 B2
`evidence that 802.11’s targeted request teaches the claimed additional data
`field.
`
`D. DISCRETION TO DENY INSTITUTION UNDER § 325(d)
`35 U.S.C. § 325(d) provides that “[i]n determining whether to institute
`or order a proceeding . . . the Director may take into account whether, and
`reject the petition or request because, the same or substantially the same
`prior art or arguments previously were presented to the Office.”
`Patent Owner asserts that we should exercise our § 325(d) discretion
`to decline institution because the Petition relies on “the same art and
`substantially the same arguments” “already before the Board pending IPR
`proceeding IPR2019-00251.” Prelim. Resp. 13. Patent Owner notes that
`“just as in the previously-filed petition, the instant Petition presents Larsson
`and [Bluetooth Specification] as prior art” in its challenge to claims 11 and
`12. Id. at 14–15. Patent Owner further asserts that “Petitioner’s reliance and
`introduction of 802.11 is also immaterial” because 802.11 does not teach the
`additional data field limitation. Id. at 15.
`We decline to exercise discretion to deny the Petition under § 325(d).
`First, we disagree with Patent Owner’s substantive 802.11 argument for the
`reasons explained above. Petitioner’s meritorious challenge based solely on
`802.11, which was not cited in IPR2019-00251, weighs against denying the
`Petition under § 325(d). In addition, we agree with Petitioner that “while
`[Petitioner] relies on some of the same art applied in the other third-party
`petition, Larsson, it presents that art in a different light and relies on other art
`not cited in that petition.” Pet. 4–5. Specifically, the present Petition relies
`on Larsson’s ARP messages to satisfy the claims, including the additional-
`data-field limitations. See id. at 34. The Petition further relies on RFC826
`to show the format of those ARP messages. See id. at 34–35. The IPR2019-
`
`11
`
`

`

`IPR2019-01026
`Patent 6,993,049 B2
`00251 petition, in contrast, focused on Larsson’s Bluetooth polling packets
`without addressing ARP messages or RFC826. See Apple Inc. v. Uniloc
`2017 LLC, IPR2019-00251, Paper 2 at 15–25 (PTAB Nov. 12, 2018).
`Petitioner’s challenge presents Larsson in a new and different light because
`it relies on different aspects of Larsson, a different overall combination of
`references, and a different supporting declaration to show obviousness. For
`these reasons, we decline to deny the Petition under 35 U.S.C. § 325(d).
`
`III. CONCLUSION
`For the foregoing reasons, we determine that the information
`presented in the Petition establishes a reasonable likelihood that Petitioner
`would prevail in showing claims 11 and 12 are unpatentable. We therefore
`institute an inter partes review of claims 11 and 12.
`
`IV. ORDER
`
`Accordingly, it is:
`ORDERED that pursuant to 35 U.S.C. § 314(a), an inter partes
`review of claims 11 and 12 of the ’049 patent is hereby instituted on the
`grounds presented in the Petition;
`FURTHER ORDERED that no other grounds are authorized for inter
`partes review; and
`FURTHER ORDERED that pursuant to 35 U.S.C. § 314(c) and 37
`C.F.R. § 42.4, notice is hereby given of the institution of a trial.
`
`
`
`
`
`
`12
`
`

`

`IPR2019-01026
`Patent 6,993,049 B2
`
`PETITIONER:
`Andrew M. Mason
`Todd M. Siegel
`Joseph T. Jakubek
`John M. Lunsford
`KLARQUIST SPARKMAN, LLP
`andrew.mason@klarquist.com
`todd.siegel@klarquist.com
`joseph.jakubek@klarquist.com
`john.lunsford@klarquist.com
`
`PATENT OWNER:
`James Etheridge
`Jeffrey Huang
`James Etheridge
`Jeffrey Huang
`ETHERIDGE LAW GROUP
`jim@etheridgelaw.com
`jeff@etheridgelaw.com
`jim@etheridgelaw.com
`jeff@etheridgelaw.com
`
`13
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket