`
`_________________
`
`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