throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_________________
`
`MICROSOFT CORPORATION,
`Petitioner,
`
`v.
`
`UNILOC 2017 LLC,
`Patent Owner.
`
`U.S. Patent No.: 6,993,049
`Issued: January 31, 2006
`Application No.: 09/876,514
`Filed: June 7, 2001
`Title: COMMUNICATION SYSTEM
`
`_________________
`
`DECLARATION OF PETER RYSAVY
`Dated: May 6, 2019
`
`
`
`Page 1
`
`

`

`TABLE OF CONTENTS
`
`Patent 6,993,049
`
`Page(s)
`
`I.
`
`INTRODUCTION AND ENGAGEMENT .................................................... 4
`
`II.
`
`BACKGROUND AND QUALIFICATIONS ................................................. 4
`
`III. MATERIALS CONSIDERED AND
`INFORMATION RELIED UPON REGARDING ’049 PATENT ................. 7
`
`IV. SUMMARY OF CONCLUSIONS ...............................................................10
`
`V.
`
`LEGAL UNDERSTANDING .......................................................................10
`
`VI. THE ’049 PATENT .......................................................................................13
`
`VII. RELEVANT FIELD AND LEVEL OF
`ONE OF ORDINARY SKILL IN THE ART ...............................................14
`
`VIII. CLAIM CONSTRUCTION ..........................................................................15
`
`IX. OVERVIEW OF REFERENCES ..................................................................16
`
`A.
`
`Larsson (U.S. Pat. No. 6,704,293) ......................................................16
`
`B.
`
`C.
`
`The Bluetooth Specification ................................................................19
`
`RFC826 ...............................................................................................22
`
`D.
`
`802.11 (Ex. 1007) ................................................................................23
`
`X. A POSITA WOULD HAVE NATURALLY
`COMBINED LARSSON, THE BLUETOOTH
`SPECIFICATION, AND RFC826 TO CARRY OUT A
`METHOD SATISFYING THE ELEMENTS OF CLAIMS 11-12 ..............27
`
`A.
`
`Combining Larsson With The Bluetooth Specification ......................27
`
`B.
`
`Combining Larsson With RFC826 ......................................................31
`
`C.
`
`Larsson, The Bluetooth Specification, and
`RFC826 Would Have Naturally Been Combined In A
`Manner That Satisfies Claims 11-12 Of The ’049 Patent ...................33
`
`DECLARATION OF PETER RYSAVY
`
`Page 2
`
`

`

`Patent 6,993,049
`
`1.
`
`2.
`
`Claim 11 ....................................................................................33
`
`Claim 12 ....................................................................................53
`
`XI. A POSITA WOULD HAVE NATURALLY
`IMPLEMENTED THE NETWORK SPECIFIED BY 802.11 IN A
`MANNER THAT SATISFIED THE ELEMENTS OF CLAIMS 11-12 ......54
`
`A.
`
`Claim 11 ..............................................................................................54
`
`B.
`
`Claim 12 ..............................................................................................64
`
`XII. SIGNATURE .................................................................................................65
`
`
`
`
`
`
`
`
`DECLARATION OF PETER RYSAVY
`
`Page 3
`
`

`

`Patent 6,993,049
`
`I, Peter Rysavy, do hereby declare as follows:
`
`I.
`
`INTRODUCTION AND ENGAGEMENT
`
`1.
`
`I have been retained as an independent expert by attorneys at
`
`Klarquist Sparkman, LLP, who I understand to represent Microsoft Corporation in
`
`connection with Inter Partes Review (“IPR”) of U.S. Patent No. 6,993,049
`
`(hereinafter “the ’049 Patent”). In this report I provide my analyses and opinions
`
`on certain technical issues related to the ’049 patent.
`
`2.
`
`I am being compensated at my usual and customary rate for the time
`
`spent in connection with this IPR. My compensation is not affected by the outcome
`
`of this IPR.
`
`II. BACKGROUND AND QUALIFICATIONS
`
`3.
`
`I graduated with BSEE and MSEE degrees from Stanford University
`
`in 1979.
`
`4.
`
`From 1988 to 1993, I was vice president of engineering and
`
`technology at Traveling Software (later renamed LapLink), at which projects
`
`included LapLink, LapLink Wireless, and connectivity solutions for a wide variety
`
`of mobile platforms. During this period, I was responsible for evaluating wireless
`
`technologies for use with the LapLink file transfer and synchronization product
`
`family. I also managed the development of a short-range wireless modem called
`
`LapLink Wireless that replaced a serial-data cable connection between computers.
`
`DECLARATION OF PETER RYSAVY
`
`Page 4
`
`

`

`Patent 6,993,049
`
`Prior to Traveling Software, I spent seven years at Fluke Corporation, where I
`
`worked on data-acquisition products and touch-screen technology.
`
`5.
`
`I am the president of the consulting firm Rysavy Research LLC and
`
`have worked as a consultant in the field of wireless technology since 1993. As a
`
`consultant I specialize in wireless technology. One of my clients in 1994 was
`
`McCaw Cellular (which later became AT&T Wireless), the leading U.S. cellular
`
`company at the time. I did multiple projects for McCaw Cellular, helping me
`
`develop my expertise in wireless and cellular technology.
`
`6.
`
`Beginning in 1994, I began teaching public wireless courses,
`
`including courses that I taught at Portland State University and the University of
`
`California, Los Angeles. These courses included content about paging networks,
`
`cellular networks (1G to 5G), mobile-data networks, Wi-Fi (IEEE 802.11),
`
`Bluetooth, IR-based technologies (IEEE 802.11 and IRDA), satellite systems, and
`
`mobile-application architectures. Particularly relevant courses include:
`
`• UCLA, 2001, "Wireless Data Systems," one‐day course
`
`• CMP Web 2000, "Wireless Data Networks," one‐day course
`
`• UCLA, 2000, "Wireless Data Systems," two‐day course
`
`• Portable Design Conference, 1999, "Wireless Data Integration," one‐
`
`day course.
`
`DECLARATION OF PETER RYSAVY
`
`Page 5
`
`

`

`Patent 6,993,049
`
`• Northcon, 1998, "Wireless Data Networking Advances," one‐day
`
`course.
`
`7.
`
`Past projects have included evaluation of wireless technology
`
`capabilities, reports on the evolution of wireless technology, strategic
`
`consultations, system design, articles, courses and webcasts, network performance
`
`measurement, test reports, and involvement in multiple patent litigation cases. My
`
`past and current clients include more than ninety-five organizations.
`
`8.
`
`I have written more than one hundred and eighty articles, reports, and
`
`papers, and have taught more than forty public courses and webcasts, on wireless
`
`technology, including both RF- and IR-based systems. I have also performed
`
`technical evaluations of many wireless technologies including mobile browser
`
`technologies, wireless e-mail systems, municipal/mesh Wi-Fi networks, Wi-Fi
`
`hotspot networks, cellular-data services, and social networking applications.
`
`9.
`
`From 2000 to 2016, as part of my consulting practice, I was the
`
`executive director of the Portable Computer and Communications Association
`
`(PCCA), which was formally incorporated in May of 1993 then operated as the
`
`Wireless Technology Association. The PCCA’s mission was to promote the
`
`interoperability of wireless-data systems, and its initial work was to develop
`
`interfaces between computer and wireless modems, as described, for example, at
`
`http://www.pcca.org.
`
`DECLARATION OF PETER RYSAVY
`
`Page 6
`
`

`

`Patent 6,993,049
`
`10.
`
`In the over twenty years of my consulting career, I have studied or
`
`worked with nearly every major wireless technology related to cellular networks
`
`and wireless local-area networks. I have also worked with mobile device
`
`peripherals and have examined the various ways that mobile devices can connect
`
`with other devices, including wireless and wired connections.
`
`11. Further detail on my background and work experience, along with a
`
`list of my publications and the cases in which I have given testimony in the past
`
`four years, is contained in my CV in Appendix 1.
`
`12.
`
`I am being compensated for my time expended in connection with this
`
`case at the rate of $400 per hour, plus expenses. My compensation is for my time
`
`and is in no way dependent or based on the content of my opinions or testimony
`
`offered in this matter, the outcome of any issues in this matter, or the timing of
`
`when issues in this matter or this matter as a whole are resolved.
`
`III. MATERIALS CONSIDERED AND
`INFORMATION RELIED UPON REGARDING ’049 PATENT
`
`13.
`
`In forming my opinions, I consulted the following materials bearing
`
`exhibit numbers that I understand are being used in the IPR. Additional items that I
`
`considered are noted in my declaration. Throughout my declaration I often refer to
`
`certain exhibits by the shorthand name indicated in parentheticals in the below
`
`exhibit list.
`
`DECLARATION OF PETER RYSAVY
`
`Page 7
`
`

`

`Patent 6,993,049
`
`Ex. No. Description
`
`1001
`
` U.S. Patent No. 6,993,049 (“the ’049 Patent”)
`
`1002
`
` File History of U.S. Patent No. 6,993,049
`
`1003
`
` N/A
`
`1004
`
` U.S. Pat. No. 6,704,293 to Larsson et al. (“Larsson”)
`
`1005
`
`1006
`
`1007
`
` Specification of the Bluetooth System, Vol. 1, Bluetooth, v1.0B
`(Dec. 1, 1999) (“Bluetooth Specification”)
`
` David C. Plummer, An Ethernet Address Resolution Protocol,
`IETF Request For Comments No. 826 (Nov. 1982) (“RFC826”)
`
` ANSI/IEEE Std 802.11, Part 11: Wireless LAN Medium Access
`Control (MAC) and Physical Layer (PHY) Specifications (Aug.
`20, 1999) (“802.11”)
`
`1008
`
` Not considered.
`
`1009
`
` Not considered.
`
`1010
`
` Not considered.
`
`1011
`
` Not considered.
`
`1012
`
` Not considered.
`
`1013
`
` U.S. Pat. No. 6,255,800 to Bork
`
`1014
`
` U.S. Pat. No. 6,975,205 to French et al.
`
`DECLARATION OF PETER RYSAVY
`
`Page 8
`
`

`

`Patent 6,993,049
`
`1015
`
` Not considered.
`
`1016
`
` U.S. Pat. No. 5,907,540 to Hayashi
`
`1017
`
` U.S. Pat. No. 6,058,421 to Fijolek et al.
`
`1018
`
` U.S. Pat. No. 6,982,953 to Swales
`
`1019
`
`1020
`
`1021
`
`1022
`
` S. Cheshire, IPv4 Address Conflict Detection, IETF Request For
`Comments No. 5227 (July 2008) (“RFC5227”)
`
` Peter Rysavy, Wireless Wonders Coming Your Way, Network
`Magazine (May 2000).
`
` Peter Rysavy / Rysavy Research, Wireless Data Networks,
`Cover Material For Course Delivered at WEB2000 (October
`2000)
`
` Peter Rysavy / Rysavy Research, Wireless Data Systems:
`Making Sense of Wireless, Cover Material For Course Taught at
`UCLA (2001)
`
`1023
`
` U.S. Pat. No. 6,683,886 to Tuijn
`
`DECLARATION OF PETER RYSAVY
`
`Page 9
`
`

`

`Patent 6,993,049
`
`IV. SUMMARY OF CONCLUSIONS
`
`14. As explained below, my opinion is that a POSITA would have viewed
`
`claims 11 and 12 of the ’049 patent as being obvious based on the references listed
`
`in the following grounds:
`
`
`
`Reference(s)
`
`Ground 1 Larsson (Ex. 1004), Bluetooth Specification (Ex. 1005), and
`
`RFC826 (Ex. 1006).
`
`Ground 2 802.11 (Ex. 1007)
`
`V. LEGAL UNDERSTANDING
`
`15.
`
`I understand that a claim is unpatentable for obviousness under 35
`
`U.S.C. § 103 “if the differences between the subject matter sought to be patented
`
`and the prior art are such that the subject matter as a whole would have been
`
`obvious at the time the invention was made to a person having ordinary skill in the
`
`art to which said subject matter pertains.” 35 U.S.C. § 103. I am informed by
`
`counsel for the Petitioner and understand that obviousness may be based upon a
`
`single reference or a combination of references. I am informed by counsel for the
`
`Petitioner and understand that the combination of familiar elements according to
`
`known methods is likely to be obvious when it does no more than yield predictable
`
`results. However, I am informed by counsel for the Petitioner and understand that a
`
`DECLARATION OF PETER RYSAVY
`
`Page 10
`
`

`

`Patent 6,993,049
`
`patent claim composed of several elements is not proved obvious merely by
`
`demonstrating that each of its elements was, independently, known in the prior art.
`
`16.
`
`I understand that when a patented invention is a combination of
`
`known elements, a court must determine whether there was an apparent reason to
`
`combine the known elements in the fashion claimed by the patent at issue by
`
`considering the teachings of prior art references, the effects of demands known to
`
`people working in the field or present in the marketplace, and the background
`
`knowledge possessed by a person having ordinary skill in the art.
`
`17.
`
`I understand that a patent claim composed of several limitations is not
`
`proved obvious merely by demonstrating that each of its limitations was
`
`independently known in the prior art. I am informed by counsel for the Petitioner
`
`and understand that identifying a reason those elements would be combined can be
`
`important because inventions in many instances rely upon building blocks long
`
`since uncovered and claimed discoveries almost of necessity tend to be
`
`combinations of what, in some sense, is already known. I am informed by counsel
`
`for the Petitioner and understand that it is improper to use hindsight in an
`
`obviousness analysis, and that a patent's claims should not be used as a “roadmap”
`
`to combine prior art references.
`
`18.
`
`I understand that an obviousness inquiry requires consideration of the
`
`following factors: (1) the scope and content of the prior art; (2) the differences
`
`DECLARATION OF PETER RYSAVY
`
`Page 11
`
`

`

`Patent 6,993,049
`
`between the claims and the prior art; (3) the level of ordinary skill in the pertinent
`
`art; and (4) any objective indicia of non-obviousness, such as commercial success,
`
`long-felt but unresolved need, failure of others, industry recognition, copying, and
`
`unexpected results (sometimes referred to as secondary considerations).
`
`19.
`
`I understand that objective indicia of nonobviousness can be evidence
`
`of nonobviousness in the record and enables the Patent Trial and Appeal Board
`
`(“Board”) and the courts to avoid the trap of hindsight. I am further informed that
`
`such evidence must always be present when considered in connection with an
`
`obviousness determination. Further, to be afforded substantial weight, the objective
`
`indicia of nonobviousness must be tied to the novel elements of the claims at issue,
`
`but the objective indicia need only be reasonably commensurate with the scope of
`
`the claims. I am not aware of evidence of objective indicia of non-obviousness
`
`relevant to the ’049 patent.
`
`20.
`
`I understand that all prior art references are to be looked at from the
`
`viewpoint of a person of ordinary skill in the art. Furthermore, obviousness is
`
`analyzed from the perspective of one of ordinary skill in the art at the time of the
`
`invention.
`
`DECLARATION OF PETER RYSAVY
`
`Page 12
`
`

`

`Patent 6,993,049
`
`VI. THE ’049 PATENT
`
`21. The ’049 patent, entitled “Communication System,” was filed on June
`
`7, 2001, and issued on January 31, 2006. I understand that it alleges priority to two
`
`earlier-filed U.K. patent applications, as reflected on the face of the ’049 patent.
`
`22. The ’049 Patent generally relates to a wireless communication system
`
`in which devices, such as Human/Machine Interface Devices (HIDs), are
`
`connected to a wireless network, such as Bluetooth. Ex. 1001, 1:3-7, 1:27-33. The
`
`’049 Patent describes an HID as “an input device such as a keyboard, mouse,
`
`games controller, graphics pad or the like” that “do[es] not typically require a link
`
`having high data throughput.” Ex. 1001, 1:28-33.
`
`23. The ’049 Patent proposed utilizing an additional data field for polling
`
`HIDs. Ex. 1001, 2:18-35. Specifically, “[t]he applicants … recognized that it is
`
`possible to piggy-back a broadcast channel on the inquiry messages issued by the
`
`master,” where “[t]he broadcast channel can be used to poll HIDs at regular
`
`intervals.” Ex. 1001, 4:15-18.1
`
`24. As shown in Fig. 5 (reproduced below), a “standard inquiry packet is
`
`an ID packet (ID PKT) 502.” Ex. 1001, 5:19-20. In the alleged invention the
`
`“inquiry messages issued by [a] base station have an extra field 504 appended to
`
`them, capable of carrying a HID poll message.” 4:59-62
`
`
`1 All emphasis added, unless otherwise noted.
`
`DECLARATION OF PETER RYSAVY
`
`Page 13
`
`

`

`
`
`
`
`
`
`Patent 6,993,049
`
`additional data field
`for polling
`
`’049 Patent, Fig. 5 (with annotations in red)
`
`25.
`
` “The extended field 504 may carry a header that signifies a HID poll
`
`to distinguish it from other applications of extended field information, such as
`
`context-aware services or broadcast audio.” Ex. 1001, 4:59-5:2. “By adding the
`
`field to the end of the inquiry message, … non-HID receivers can ignore it without
`
`modification” while the HID receiver being polled can respond. Ex. 1001, 5:6-9.
`
`VII. RELEVANT FIELD AND LEVEL OF
`ONE OF ORDINARY SKILL IN THE ART
`
`26. Unless otherwise stated, the opinions expressed in this declaration are
`
`from the perspective of a person of ordinary skill in the art on June 26, 2000
`
`(“POSITA”). In my opinion, a POSITA would have had Master of Science Degree
`
`(or a similar technical master’s degree, or higher degree) in an academic area
`
`emphasizing electrical engineering or computer engineering with a concentration
`
`in communication systems or, alternatively, a Bachelor of Science Degree (or
`
`higher degree) in an academic area emphasizing electrical or computer engineering
`
`and having two or more years of experience in wireless communication systems.
`
`Additional education in a relevant field, or industry experience, may compensate
`
`DECLARATION OF PETER RYSAVY
`
`Page 14
`
`

`

`Patent 6,993,049
`
`for a deficit in one of the other aspects of the requirements stated above. There
`
`would have been no material differences in the skill level, education, knowledge,
`
`and experience of a POSITA between June 2000 and late 2001. The POSITA
`
`would have had working knowledge of at least the more well-known wireless
`
`protocols, especially shorter-range protocols such as Bluetooth and the wireless
`
`LAN specified by the IEEE 802.11 working group. Moreover, the POSITA would
`
`have followed the activities of the organizations developing these protocols,
`
`including the Bluetooth SIG and the IEEE 802 Working Groups, and been aware
`
`of the protocol/standards documents published by these organizations, such as the
`
`Bluetooth Specification (Ex. 1005) and 802.11 (Ex. 1007). Such knowledge would
`
`have allowed the POSITA to implement and maintain common short-range
`
`wireless networks of the 2000-2001 timeframe, including the wireless networks
`
`contemplated by the ’049 patent. During the relevant time period of 2000-2001, I
`
`had at least the level of knowledge, skill, education, and experience of a POSITA.
`
`VIII. CLAIM CONSTRUCTION
`
`27.
`
`I understand that, for purposes of my analysis in this inter partes
`
`review proceeding, the terms appearing in the patent claims should be interpreted
`
`according to their “ordinary and customary meaning” under the Phillips standard.
`
`Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc); 37 C.F.R. §
`
`42.100. In determining the ordinary and customary meaning, the words of a claim
`
`DECLARATION OF PETER RYSAVY
`
`Page 15
`
`

`

`Patent 6,993,049
`
`are first given their plain meaning. Id. According to Phillips, the structure of the
`
`claims may breathe additional meaning into the claims, and the specification and
`
`file history also may be used to better construe a claim insofar as the plain meaning
`
`of the claims cannot be understood. Moreover, Phillips offers that even treatises
`
`and dictionaries may be used, albeit under limited circumstances, to determine the
`
`meaning attributed by a person of ordinary skill in the art to a claim term at the
`
`time of filing. I have followed this approach in my analysis. My opinions below
`
`apply the ordinary and customary meaning that the terms would have been given
`
`by a POSITA.
`
`IX. OVERVIEW OF REFERENCES
`
`A. Larsson (U.S. Pat. No. 6,704,293)
`
`28. Larsson relates to updating and maintaining route information in
`
`wireless ad hoc networks, such as Bluetooth networks. Larsson, 1:14-45. In
`
`particular, Larsson reveals a method to: 1) speed up the signaling required to
`
`configure a route between a source and destination node, and 2) minimize the
`
`“number of broadcast messages required for setting up a route from [the] source
`
`node to [the] destination node when employing reactive protocols currently being
`
`used for transmitting in an ad-hoc network.” Larsson, 2:26-50, 3:64-4:8, 4:32-36.
`
`29. The above-noted objectives are achieved in Larsson by a “route
`
`discovery technique for use in a Bluetooth scatternet” in which “broadcast
`
`DECLARATION OF PETER RYSAVY
`
`Page 16
`
`

`

`Patent 6,993,049
`
`messages [for] which the source node expects a reply message [are combined] with
`
`broadcast messages for route discovery. In so doing, the broadcast messages for
`
`which a source node expects a reply message can also be used to support route
`
`discovery.” Larsson, 5:35-50.
`
`30. Figs. 6A (reproduced below) and 6B provide an overview of one
`
`implementation of Larsson’s route discovery technique. As shown in Fig. 6A, a
`
`source node in a Bluetooth scatternet generates a broadcast message and
`
`determines whether a reply is expected to the broadcast message. Larsson, Fig. 6A,
`
`5:60-6:2. If the source node does expect a reply, “the source node piggybacks the
`
`broadcast message in a request for route broadcast message.” Larsson, Fig. 6A,
`
`6:2-8. Next, the source node broadcasts the request for route message with the
`
`piggybacked broadcast message to its neighbor nodes. Larsson, Fig. 6A, 6:11-15.
`
`DECLARATION OF PETER RYSAVY
`
`Page 17
`
`

`

`Patent 6,993,049
`
`Larsson, Fig. 6A (partly shown)
`
`
`
`31.
`
`“[B]roadcast messages [are] processed by some or all of the neighbor
`
`nodes at the same time or during similar time periods.” Larsson, 10:32-38. In
`
`particular, a neighbor node receives the request for route message and determines
`
`whether the node has already processed the request for route message. Larsson,
`
`Fig. 6A, 6:18-25. Turning to Fig. 6B (reproduced below), after “the node
`
`determines that the request for route message has not been previously processed,”
`
`“the node determines whether the piggybacked data indicates that the node is the
`
`destination node. If the piggybacked data does not indicate that the node is the
`
`destination node,” “the node replaces its address in the request for route message.”
`
`DECLARATION OF PETER RYSAVY
`
`Page 18
`
`

`

`Patent 6,993,049
`
`Larsson, Fig. 6B, 6:45-62. “If the piggybacked data indicates that the node is the
`
`destination node,” “the node will piggyback a reply message in the route response
`
`message.” Larsson, Fig. 6B, 6:45-62.
`
`Larsson, Fig. 6B (partly shown)
`
`
`
`32.
`
`In Figs. 7A and 7B, Larsson discloses a similar method for obtaining
`
`route information in IP networks by piggybacking DHCP, name resolution, or ARP
`
`broadcast messages onto request for route messages. Larsson, 9:13-26, see
`
`generally 7:37-10:31.
`
`B.
`
`The Bluetooth Specification
`
`33. The Bluetooth Specification (Ex. 1005), published by the Bluetooth
`
`Special Interest Group (“SIG”), was a well-known specification in the wireless
`
`industry upon its publication in December 1999. Its full title is “Specification of
`
`the Bluetooth System” and its title page reflects that it is the “Core” specification,
`
`defining implementation details that developers used to create devices that can
`
`DECLARATION OF PETER RYSAVY
`
`Page 19
`
`

`

`Patent 6,993,049
`
`communicate using the Bluetooth Protocol. I recall the Bluetooth Specification
`
`being published in 1999 and personally reviewed it in 2000, before publishing my
`
`article “Wireless Wonders Coming Your Way” in May 2000. Ex. ___
`
`https://rysavyresearch.files.wordpress.com/2017/08/2000_05_wireless_wonders.
`
`pdf. I also presented on the Bluetooth Protocol in October 2000, as part of a full-
`
`day course on “Wireless Data Networks” that I delivered at the WEB2000 industry
`
`conference, further confirming my recollection that I reviewed and consulted the
`
`Bluetooth Specification numerous times in the year after its publication. Ex. 1021.
`
`I recall that the Bluetooth Specification was published and made available for free
`
`download from the Bluetooth website: https://www.bluetooth.com/. This
`
`recollection is confirmed by archived pages from the Bluetooth website, showing
`
`that on December 6, 1999, the “Bluetooth Specification V 1.0 B [was] published
`
`on the Bluetooth.com website.” https://web.archive.org/web/20000517192715/
`
`http://www.bluetooth.com/text/news/archive/archive.asp?news=2; see also
`
`https://web.archive.org/web/20000518114920/http://www.bluetooth.com/text/news
`
`/archive/archive.asp?news=list. It is further confirmed by patents issuing from
`
`applications filed in early 2000. See Ex. 1013, 5:35-39 (patent issuing from
`
`January 2000 application, stating “[t]he communications industry has adopted the
`
`Bluetooth Specification as a recommended communications technique for short
`
`distance wireless RF communication applications. The Bluetooth Specification can
`
`DECLARATION OF PETER RYSAVY
`
`Page 20
`
`

`

`Patent 6,993,049
`
`be found at www.Bluetooth.com or www.Bluetooth.net.”); Ex. 1014, 8:25-38
`
`(patent issued from application filed March 2000 describing Bluetooth and the
`
`Bluetooth 1.0 specification, and noting that “[t]he Specification may be accessed
`
`on the Web at www.bluetooth.com.”). Having reviewed the Bluetooth
`
`Specification (Ex. 1005), I believe it to be a true and correct copy of the Core
`
`Bluetooth Specification that was publicly available by December 1999.
`
`34.
`
`In addition to various other standard features, the Bluetooth
`
`Specification describes the standard Bluetooth packet format (shown below) as
`
`including three fields, namely an access code, header, and payload. Ex. 1005 p.
`
`47.
`
`Standard Bluetooth packet format (Ex. 1005 p. 47)
`
`
`
`35. When BT packets are transmitted from one device to another, a
`
`Bluetooth Device Address (BD_ADDR) is allocated to the transceivers of the
`
`devices. Ex. 1005, p. 143. The standard BD_ADDR (reproduced below) includes a
`
`LAP field, which is the “lower address part consisting of 24 bits;” a UAP field,
`
`which is an “upper address part consisting of 8 bits;” and a NAP field, which is a
`
`“non-significant address part consisting of 16 bits.” Ex. 1005, p. 143.
`
`DECLARATION OF PETER RYSAVY
`
`Page 21
`
`

`

`Patent 6,993,049
`
`Bluetooth Format of BD_ADDR (Ex. 1005, p. 143).
`
`
`
`C. RFC826
`
`36. Request for Comment 826, aka “RFC826,” was published by the
`
`Internet Engineering Task Force (“IETF”) in November 1982. RFC stands for
`
`Request For Comment, which is the phrase used by the Internet Engineering Task
`
`Force (“IETF”) to refer to their Internet specifications. The RFCs published by the
`
`IETF, especially on its website, would have been well-known and often-consulted
`
`by POSITAs implementing different types of networks. These RFCs were a large
`
`and reliable source for those working on different networking implementations. In
`
`my experience, the IETF maintained these RFCs on its website in an easily
`
`searchable manner since at least the late 1990s, with publication dates indicated at
`
`the top of each document. Thus, RFC826 would have been well-known and
`
`publicly available on the IETF (and other) websites at least by the end of 1999.
`
`37. RFC826 describes a method for “Ethernet Address Resolution
`
`Protocol,” otherwise known as “ARP.” RFC826, 1 (italics added). RFC826
`
`explains the structure and content of ARP messages and by the year 2000 would
`
`have been regularly consulted as the standard for ARP messaging. See, e.g., Ex.
`
`1016 (’540 patent), 1:52-54 (“ARP is described in RFC826 ‘An Ethernet Address
`
`Resolution Protocol’ published from Internet Society.”); Ex. 1017 (’421 patent),
`
`DECLARATION OF PETER RYSAVY
`
`Page 22
`
`

`

`Patent 6,993,049
`
`21:62-63 (“ARP is defined in RFC-826.”); Ex. 1018 (’953 patent), Table 1
`
`(showing ARP message information specified by RFC826) and 10:36-37 (noting
`
`“the standard ARP protocol described in RFC 826”).
`
`D.
`
`802.11 (Ex. 1007)
`
`38. The Institute of Electrical and Electronics Engineers (IEEE) published
`
`802.11 (Ex. 1007) in August 1999. Ex. 1007, iii. At the time of its publication and
`
`afterwards, 802.11 was a well-known standard in the wireless industry specifying
`
`aspects of wireless local area networks (“LANs”). Id., i. I recall 802.11 being
`
`published in 1999 and personally reviewed it no later than early 2000, before
`
`publishing my article “Wireless Wonders Coming Your Way” in May 2000. Ex.
`
`1020 (available at https://rysavyresearch.files.wordpress.com/2017/08/
`
`2000_05_wireless_wonders.pdf). In that article, I described the availability of
`
`wireless cards implementing the 802.11b standard. Id. at 1. I also presented on the
`
`802.11 standard in October 2000, as part of a full-day course on “Wireless Data
`
`Networks” that I delivered at WEB2000, further confirming my recollection that I
`
`reviewed and consulted the 802.11 standard (Exhibit 1007) numerous times in the
`
`year after its publication. Ex. 1021; see also Ex. 1022 (listing subjects covered in a
`
`course that I delivered at UCLA in 2001). I recall that 802.11 was published and
`
`made available for download from the IEEE website: http://standards.ieee.org.
`
`This recollection is confirmed by archived pages from the IEEE website, showing
`
`DECLARATION OF PETER RYSAVY
`
`Page 23
`
`

`

`Patent 6,993,049
`
`that on March 24, 2000, 802.11 was available on the IEEE website. Ex. 1026
`
`(https://web.archive.org/web/20000324233339/http:/standards.ieee.org:80/catalog/
`
`IEEE802.11.html). As indicated on that archived webpage, PDF copies of the
`
`standard were “available as part of” several different IEEE standards subscription
`
`packages. A POSITA would have been actively following wireless developments
`
`of the IEEE and other similar organizations and, thus, I would have expected a
`
`POSITA to be aware of and have easy access to the 802.11 standard. Further
`
`supporting my recollection is the timeline provided on the current IEEE website, at
`
`http://www.ieee802.org/11/Reports/802.11_Timelines.htm#tga-128, which shows
`
`that “Part 11 Wireless LAN Medium Access Control MAC and Physical Layer
`
`PHY Specifications,” i.e., Ex. 1007, was approved by IEEE and ANSI in March
`
`and August 1999, respectively, and not superseded until September 30, 2005.
`
`Based on my experience working with and presenting on the 802.11 standard
`
`shortly after its publication in 1999, I believe 802.11 (Ex. 1007) to be a true and
`
`correct copy of the IEEE 802.11 Standard. This standard was publicly available,
`
`well-known, and widely available to POSITAs by late 1999.
`
`39. An IEEE standard, 802.11 specifies “[t]he medium access control
`
`(MAC) and physical characteristics for wireless local area networks (LANs).”
`
`802.11, iii. It describes a local wireless network that contains different “stations”
`
`communicating with one another according to the protocol, including access points
`
`DECLARATION OF PETER RYSAVY
`
`Page 24
`
`

`

`Patent 6,993,049
`
`(APs). 802.11, 10-11. APs have “station functionality and provide[] access to the
`
`distribution services, via the wireless medium (WM) for associated stations.” Id.,
`
`3. The network also includes basic service sets (BSSs) that include “[a] set of
`
`stations controlled by a single coordination function” (id., 3) and distribution
`
`systems (DSs) that “interconnect a set of basic service sets (BSSs) and integrated
`
`local area networks (LANs) to create an extended service set (ESS,)” i.e., an
`
`extended network (id., 4). Figure 2 shows some of these network components:
`
`40. As explained by 802.11, “[d]ata move between a BSS and the DS via
`
`an AP. Note that all APs are also STAs; thus they are addressable entities.” Id., 11.
`
`
`
`DECLARATION OF PETER RYSAVY
`
`Page 25
`
`

`

`Patent 6,993,049
`
`41.
`
`In order to join a BSS and communicate with other stations, a station
`
`uses the scan function to “determin[e] the characteristics of the available BSSs.”
`
`802.11, 101 (Section 10.3.2). “Active scanning involves the generation of Probe
`
`frames and the subsequent processing of received Probe Response frames.” Id.,
`
`126.
`
`42. A typical broadcast probe request message seeks a response from any
`
`BSS and does not include the address of a specific SSID. Id., 126. This is shown,
`
`in part, in Figure 66, which shows the scanning station issuing a broadcast probe
`
`message, and responder stations 1 and 2 issuing probe response messages:
`
`43.
`
`If a device wishes to probe a specific BSS, however, then it appends
`
`to the

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