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
`
`_________________
`
`SECOND DECLARATION OF PETER RYSAVY
`Dated: May 19, 2020
`
`
`
`

`

`
`
`TABLE OF CONTENTS
`
`Page(s)
`
`I.
`
`INTRODUCTION AND ENGAGEMENT .................................................... 3
`
`II.
`
`BACKGROUND AND QUALIFICATIONS ................................................. 3
`
`III. MATERIALS CONSIDERED
`AND INFORMATION RELIED UPON ........................................................ 3
`
`IV. CLAIM CONSTRUCTION AND LEVEL OF SKILL .................................. 5
`
`A.
`
`Inquiry Message .................................................................................... 6
`
`V. GROUND 1: LARSSON-BASED COMBINATION ..................................... 9
`
`VI. GROUND 2: 802.11 ......................................................................................21
`
`VII. SIGNATURE .................................................................................................23
`
`
`
`
`
`
`
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 2
`
`

`

`
`
`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. This Second Declaration is in addition to the first declaration that I
`
`prepared for the ’049 patent PTAB proceedings, signed and dated May 6, 2019
`
`(“First Declaration” or “Rysavy Declaration”). In this Second Declaration, I
`
`refer back to and incorporate analysis provided in the First Declaration. For
`
`brevity’s sake, I aim to not repeat analysis provided in that First Declaration.
`
`II. BACKGROUND AND QUALIFICATIONS
`
`3. The First Declaration lays out my education and professional
`
`background in paragraphs 3-11. With this declaration, I attach an updated
`
`version of my CV, as Appendix 1.
`
`III. MATERIALS CONSIDERED AND INFORMATION RELIED UPON
`
`4. In addition to the materials identified in paragraph 13 of the First
`
`Declaration, in connection with my work on this matter, I have reviewed the
`
`following materials and references in forming my opinions. Throughout, this
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 3
`
`

`

`
`
`declaration refers to the references by the shorthand form included in bold text
`
`within the parentheticals.
`
`Ex. No. Description
`
`1029
`
` Modicon Modbus Protocol Reference Guide, PI-MBUS-300, June
`1996 (“Modbus Protocol”).
`
`1030 U.S. Pat. No. 6,434,157 to Dube’ et al. (referencing Modbus Protocol).
`
`1031 ASN.1: Communication Between Heterogeneous Systems, Olivier
`Dubuisson, June 5, 2000, available at
`http://www.oss.com/asn1/resources/books-whitepapers-
`pubs/dubuisson-asn1-book.PDF from
`http://www.oss.com/asn1/resources/books-whitepapers-pubs/asn1-
`books.html (“Dubuisson”).
`
`1032 U.S. Pat. No. 6,687,766 to Casper
`
`1033 Uniloc USA, Inc. v. Samsung Elecs. Am. Inc., No. 2:18-cv-00040-JRG-
`RSP, Dkt. No. 69 (E.D. Tex. Feb. 26, 2019) (“Plaintiff’s Reply Claim
`Construction Brief”).
`
`1034 Qiu et al., A multiple access scheme for multimedia traffic in wireless
`ATM, IEEE/ACM Mobile Networks and Applications 1:259-272 (Jan.
`1996).
`
`1035 U.S. Pat. No. 6,205,498 to Habusha et al.
`
`1036 W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols,
`1994 (“Stevens”)
`
`1037 Webster’s New World Dictionary, 4th Edition, 1999 (“inquiry”)
`
`1038 U.S. Pat. No. 3,523,281 to Willcox et al.
`
`1039 U.S. Pat. No. 5,517,488 to Miyazaki et al.
`
`1040 U.S. Pat. No. 6,119,208 to White et al.
`
`1041 U.S. Pat. No. 6,141,701 to Whitney
`
`1042 U.S. Pat. No. 3,701,971 to Sanner et al.
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 4
`
`

`

`
`
`Ex. No. Description
`
`1043 U.S. Pat. No. 5,812,639 to Bartholomew et al.
`
`1044 David Johnson, David Maltz, Carnegie Mellon University, Dynamic
`Source Routing in Ad Hoc Wireless Networks, 1996,
`https://www.utdallas.edu/~ksarac/Papers/DSR.pdf
`
`1045 Global System for Mobile Communications (GSM) Technical
`Specification: Digital cellular telecommunications system (Phase 2+);
`Mobile radio interface layer 3 specification (GSM 04.08),
`https://www.etsi.org/deliver/etsi_gts/04/0408/05.00.00_60/gsmts_0408
`v050000p.pdf
`
`1046
`
`Federal Standard 1037C, Telecommunications: Glossary of
`Telecommunication Terms, U.S. Federal General Services
`Administration (Aug. 7, 1996)
`
`5. I may also reference other background materials throughout this
`
`declaration.
`
`6. I have also read the December 4, 2019, Institution Decision and the
`
`February 26, 2020, Patent Owner Response submitted in this IPR proceeding.
`
`IV. CLAIM CONSTRUCTION AND LEVEL OF SKILL
`
`7. As stated in my First Declaration, I applied the plain and ordinary
`
`meaning of the challenged claims when rendering my opinion. Since I submitted
`
`my First Declaration, I understand that the Patent Owner has proposed
`
`constructions for the terms “additional data field” and “inquiry message.” I
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 5
`
`

`

`
`
`disagree with the assertions and conclusions that the Patent Owner has stated
`
`with respect to these claim phrases as set forth below.
`
`A.
`
`Inquiry Message
`
`8. In its Response, the Patent Owner proposes that “inquiry message”
`
`should be construed as “a specific type of message used, at least in part, to
`
`discover other devices in the vicinity which may request to join a piconet.” POR,
`
`8-9, 11.
`
`9. A POSITA reading the ’049 patent would have understood the term
`
`“inquiry message” to generally be “a query for information,” or “a message
`
`seeking information.” It is a term that would apply to various networks, and its
`
`exact meaning would depend on the particular context in which it was used. This
`
`understanding is consistent with ordinary dictionary usage of the term “inquiry”:
`
`Webster’s New World College Dictionary (4th ed. 1999).
`
`10. The ’049 patent in its embodiment does not use the inquiry message to
`
`discover other devices in the vicinity which may request to join a piconet. In the
`
`
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 6
`
`

`

`
`
`’049 patent polling mode, in which the additional data field is added, the inquiry
`
`message portion is in fact ignored by the receiver, as explained by the following.
`
`“Since an inquiry mode is necessary to permit access to the host System’s
`
`piconet, it must be provided in the conventional manner for at least some of the
`
`time. There are a range of strategies which may be employed. A first strategy
`
`involves the operation of one radio in two modes, namely set up and polling. In
`
`set up mode the inquiry procedure operates as normal and the HIDs can
`
`establish contact with the host master 100 in the conventional manner. Once all
`
`HIDs have established themselves, the master radio switches to polling mode,
`
`in which the inquiry procedure now operates in polling mode only.” ’049
`
`patent 6:25-35 (emphasis added).
`
`11. In addition, and confirming my understanding that “inquiry message”
`
`would not be understood as a specific type of message, multiple patents use the
`
`term “inquiry message” to refer to a query for information or message seeking
`
`information. These usages of the term do not involve identifying devices with
`
`which to communicate. See the citations from the following patents, going as far
`
`back as 1964. US3523281 (1964 filing) in the abstract, “The changeable portion
`
`of the medium is erased following transmission of each inquiry message, and
`
`means are provided for recording on this erased portion, the reply message
`
`received from the central store.” US5517488 at 6:63-66, “The physical addresses
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 7
`
`

`

`
`
`of the data destinations can be known preliminarily on the basis of
`
`predetermination, inquiry message used in an address resolution protocol, or the
`
`like.” US6119208 at 6:5-7, “The MVS device backup query is implemented via
`
`the use of an ECAM Status Inquiry message, which comprises a status inquiry
`
`message.” US6141701 at 41:1-6, “The master control inquiry queue contains the
`
`response to the known MQF inquiry message. The MQF inquiry response
`
`message describes the current state of the specified MQF queue. There is one
`
`inquiry message response in the master control inquiry queue for every queue in
`
`the MQF describing its properties and state in known MQF format.” US3701971
`
`at 5:9-15, “A poll inquiry message is defined as a message by which the central
`
`data processor 11 interrogates one of a plurality of the addressed remote
`
`terminals and inquires whether the addressed remote terminal has a message
`
`ready for transmission to the central processor.” US5812639 at 10:59-60, “The
`
`trigger causes the SSP to frame a TCAP inquiry message which is directed to the
`
`SCP for instructions.”
`
`12. One example from cellular technology that uses the term “inquiry
`
`message” to refer to a query for information or message seeking information is a
`
`1995 specification for Global System for Mobile Communications (GSM),
`
`which is the predominant 2G cellular technology and still in use today. The
`
`specification, Mobile radio interface layer 3 specification (GSM 04.08)
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 8
`
`

`

`
`
`(https://www.etsi.org/deliver/etsi_gts/04/0408/05.00.00_60/gsmts_0408v050000
`
`p.pdf) describes two different inquiry messages. One is called a CLASSMARK
`
`ENQUIRY message, explained in section 3.4.11.2 on page 58 as, “On receipt of
`
`the CLASSMARK ENQUIRY message the mobile station sends a
`
`CLASSMARK CHANGE message to the network on the main DCCH.” The
`
`other is called a STATUS ENQUIRY message, explained in section 5.5.3.1 on
`
`page 130 as, “Upon receipt of a STATUS ENQUIRY message, the receiver shall
`
`respond with a STATUS message, reporting the current call state and cause
`
`value #30 “response to STATUS ENQUIRY”. Neither of these GSM examples
`
`involve identifying devices with which to communicate.
`
`13. The way the specification uses the word “inquiry” in the specification
`
`passages the Patent Owner cites in its POR—4:23-26, 1:56-57—is consistent
`
`with the plain and ordinary meaning of “seeking information.”
`
`14. Thus, a POSITA would have understood the term “inquiry message”
`
`as simply meaning a message that performs an inquiry to obtain information.
`
`
`
`V. GROUND 1: LARSSON-BASED COMBINATION
`
`15. As explained in my First Declaration, in paragraphs 74-82, the
`
`piggybacking of ARP messages satisfies the “adding … additional data fields”
`
`limitation in claims 11-12. I understand that Patent Owner now argues
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 9
`
`

`

`
`
`otherwise. I explain in the following paragraphs why I disagree with these
`
`arguments.
`
`16. Larsson’s length indicator confirms that there is an additional data
`
`field being added. See Larsson 7:58-61 (“[I]n a protocol where the request for
`
`route message is of a fixed length, a length indicator which indicates a length
`
`longer than the normal fixed length will implicitly indicate that the request
`
`contains piggyback data.”).
`
`17. I understand that the Patent Owner argues that adding data does not
`
`necessarily mean that there is an additional data field. POR, 12-13. But that is
`
`wrong because Larsson’s description of a “normal fixed length” RfR message
`
`means that the message is of fixed length, so any added piggybacked message
`
`would increase the length.
`
`18. It is impossible for the existing fields of the RfR message to carry
`
`more data, because the message would no longer be of the fixed length. So the
`
`presence of the length indicator in Larsson confirms the additional data fields in
`
`the piggybacked ARP (and other) messages.
`
`19. With respect to the length indicator, patent owner states, “it is just
`
`data that accounts for the longer than ‘fixed length’ message” in Larsson. Patent
`
`Owner Response at 13. This statement is incorrect because a “normal fixed
`
`length” means the length is fixed.
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 10
`
`

`

`
`
`20. A POSITA would have understood the end of the RfR message to be
`
`the most logical place to add, or “piggyback,” the additional data. In fact,
`
`placing the additional data anywhere else would have been counter-intuitive.
`
`Because the piggybacked data makes the RfR message “longer than the normal
`
`fixed length,” a POSITA would have recognized that the end of the respective
`
`inquiry message would be the least disruptive place to add the additional
`
`piggybacked data. Nearly all (if not all) communications protocols rely on
`
`predictable field lengths and locations within a packet in order to identify
`
`different message fields and thus compose and process messages in a predictable
`
`fashion. E.g., Ex. 1046, 14 (“The size and content of the various fields in a
`
`[message] packet are defined by a set of rules that are used to assemble the
`
`packet.”). Changing the order and size of these defined fields by placing
`
`additional data in the middle or beginning of a message would have likely
`
`resulted in a lack of protocol compliance and potential transmission errors. Thus,
`
`inserting additional data fields anywhere other than the end would unnecessarily
`
`increase the complexity of the implementation and, in the instance of a
`
`preestablished protocol, increase the likelihood of protocol implementation
`
`errors. For example, Qiu et al., A multiple access scheme for multimedia traffic
`
`in wireless ATM, IEEE/ACM Mobile Networks and Applications, discusses a
`
`piggybacking mechanism and specifically indicates that the authors would
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 11
`
`

`

`
`
`“append a piggyback field to the end of each packet.” Ex. 1034, 262 (emphasis
`
`added). For another example, one patent filed in 1999 describes piggybacking
`
`onto a message packet as “includ[ing] an optional Session Acknowledgment
`
`section 162” at the end of a user message packet 160. Ex. 1035, 8:46-51 and
`
`Fig. 7. That patent explains how the session acknowledgment may piggyback on
`
`a user message packet” and then refers to Fig. 7 (id., 8:46-48), which shows the
`
`session acknowledgment at the end:
`
`
`
`21. The Stevens treatise on TCP/IP confirms how a POSITA would
`
`understand the use of “piggybacking” in Larsson. A POSITA would have known
`
`the term “piggybacking,” which was well understood in networking contexts.
`
`For instance, Stevens, Ex. 1036, is a reference cited by Larsson that describes
`
`the use of piggybacking in TCP/IP communications. “Normally TCP does not
`
`send an ACK the instant it receives data. Instead, it delays the ACK, hoping to
`
`have data going in the same direction as the ACK, so the ACK can be sent along
`
`with the data. (This is sometimes called having the ACK piggyback with the
`
`data.)” Stevens, P265. The citation teaches that the act of combining one
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 12
`
`

`

`
`
`message (the ACK) with another message (the data being sent) constitutes
`
`piggybacking.
`
`22. The IEEE 802.11 specification, Ex. 1007, also refers to
`
`piggybacking. “When polled by the PC, a CFPollable STA may transmit only
`
`one MPDU, which can be to any destination (not just to the PC), and may
`
`‘piggyback’ the acknowledgment of a frame received from the PC using
`
`particular data frame subtypes for this transmission.” 802.11 at 86.
`
`23. Another reference, Dynamic Source Routing in Ad Hoc Wireless
`
`Networks, Ex. 1044, from 1996, discusses source routing in ad hoc wireless
`
`networks, a network similar to Larsson. “4.2. Piggybacking on Route
`
`Discoveries. As described in Section 3.2, when one host needs to send a packet
`
`to another, if the sender does not have a route cached to the destination host, it
`
`must initiate a separate route discovery, either buffering the original packet until
`
`the route reply is returned, or discarding it and relying on a higher-layer protocol
`
`to retransmit it if needed. The delay for route discovery and the total number of
`
`packets transmitted can be reduced by allowing data to be piggybacked on
`
`route request packets.” Ex. 1044, p. 9 (emphasis added).
`
`24. Each of these references makes clear that piggybacking is the
`
`addition of one message to another message. A POSITA would have known that
`
`all networking and communications messages consist of data and this data is
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 13
`
`

`

`
`
`arranged within data fields. An additional message would be carried within a
`
`data field and this data field would constitute an additional data field, relative to
`
`the message to which it is being added. Larsson’s use of term piggybacking is
`
`consistent with the cited examples and means the addition of information within
`
`an additional data field.
`
`25. Larsson’s “request for route” messages (“RfR messages”) are
`
`broadcast by a source node in order to establish communication routes to
`
`destination nodes. See, e.g., Larsson, 2:66-3:25. Using these RfR messages, a
`
`node can establish routes to the various nodes in the network and also reestablish
`
`routes when a route between two nodes is broken. See Larsson, Fig. 3 and 3:12-
`
`29. For example, if a source node cannot communicate with a destination node,
`
`e.g., because the “route to the destination node is not known, … then the source
`
`node broadcasts a request for route message.” Larsson, 2:66-3:2. This allows the
`
`source node to “begin[] sending data over the new route.” Larsson, 8:33-41.
`
`Under the ordinary meaning of “inquiry message” as a query for information or
`
`message seeking information, Larsson satisfies the claim.
`
`26. Larsson’s RfR messages are used to join two unconnected devices
`
`together for communication, thus enabling communications at a higher protocol
`
`layer such as the Internet protocol.
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 14
`
`

`

`
`
`27. The RfR messages in Larsson are used to both “newly establish[]”
`
`network routes between different devices and also re-establish “broken” routes
`
`so that the devices can “begin[] sending data over the new route.” Larsson, Fig.
`
`5, 2:66-3:2 3:12-29, and 8:33-41. Before a source node sends RfR messages and
`
`receives a “route response message” from a destination node, the two devices
`
`cannot communicate because they are not joined to the same network. E.g.,
`
`Larsson, 3:64-68 (“[I]n an ad-hoc network the source node may have to perform
`
`[inter alia] route discovery before the source node can begin to transmit data to
`
`the destination node.”); see also id. 1:33-37 (“[A]d-hoc networking protocols are
`
`based upon the assumption that nodes may not always be located at the same
`
`physical location. Bluetooth is an exemplary ad-hoc networking technology.”);
`
`id., 3:41-45 (“In order to transmit data from a source node to a destination node
`
`the source node may first obtain its own network address, resolve the name of
`
`the destination, obtain the hardware address of the destination node and
`
`determine a route to the destination node.”); see also 4:27-32 and 4:37-43. The
`
`RfR messages in Larsson seek to discover recipient (or destination) devices in
`
`order to join the two devices in network communication.
`
`28. The source node in Larsson is also seeking to identify nodes along the
`
`path to the destination node, so that it can communicate messages through those
`
`intermediary nodes.
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 15
`
`

`

`
`
`29. Like nearly all communications messages, ARP messages contain
`
`numerous data fields. RFC826 describes these data fields, including the “type
`
`field,” “ar$hrd field,” and “Ethernet address field (ar$sha).” See, e.g., RFC826,
`
`3-4, 8 (noting ARP message with a “type field of
`
`ether_type$ADDRESS_RESOLUTION” and “ar$hrd field”). ARP message
`
`creation is also known as “packet generation.” A person of skill in the art would
`
`understand the “type field,” “ar$hrd field,” and “Ethernet address field (ar$sha)”
`
`to be all be fields.
`
`30. RFC826 specifies the “Packet format” for ARP messages, which
`
`includes numerous fields of various lengths, including 48-bit fields for the
`
`destination and sender “Ethernet Address,” and a 16-bit “opcode” field:
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 16
`
`

`

`
`
`RFC826, 3. A person of skill in the art would understand these 48-bit fields for the
`
`destination and sender “Ethernet Address,” and the 16-bit “opcode” field to be
`
`
`
`fields.
`
`31. A person of skill in the art would understand the ar$hrd, ar$hln,
`
`ar$pro, and Ethernet type fields discussed at RCF826, 5, to be fields.
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 17
`
`

`

`
`
`32. RCF826 at 5 explains how ARP message packet buffers may be
`
`“reused” for a reply message because “a reply has the same length as a request,
`
`and several of the fields are the same.” Emphasis added.
`
`33. When an ARP message is piggybacked, all of its fields are necessarily
`
`piggybacked because a failure to do so would result in an incomplete ARP
`
`message being transmitted.
`
`34. While RFC826 specifies the different fields used for ARP messages,
`
`the Stevens textbook provides a clear depiction of these fields along with an
`
`accompanying explanation of the various ARP message fields as can be seen in
`
`Figure 4.3:
`
`Stevens, 56-57.
`
`
`
`35. Piggybacking (or, in other words, adding) ARP messages on the RfR
`
`messages means the addition of data fields, at least because the ARP data fields
`
`are not defined by the underlying protocols associated with the RfR messages
`
`and thus not ordinarily included in the RfR messages.
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 18
`
`

`

`
`
`36. The Address Resolution Protocol (ARP) is not a protocol defined by
`
`the Bluetooth specification. Rather, it is a protocol specified the Internet
`
`Engineering Task Force (IETF) at https://tools.ietf.org/html/rfc826. The fact
`
`that ARP messages are piggybacked in a Bluetooth message does not mean that
`
`ARP is defined or specified by the Bluetooth specification. The Bluetooth
`
`specification does not provide any specification for the composition or
`
`interpretation of this message. Instead it simply delivers the piggybacked
`
`message, much like a UPS delivery person delivers a package to an addressee
`
`without knowing, or needing to know, its contents. Because the ARP messages
`
`are defined by data fields, these data fields are additional data fields to the
`
`Bluetooth message.
`
`37. Even under Patent Owner’s own proposed construction for “inquiry
`
`message” of “a specific type of message used, at least in part, to discover other
`
`devices in the vicinity which may request to join a piconet,” Larsson nonetheless
`
`teaches the recited inquiry messages because in Larsson, the request for route
`
`(RfR) broadcast message is an inquiry message. Larsson RfR messages seek to
`
`establish a route between the source node and the destination node. The
`
`destination node is a node with which a source node wishes to communicate and
`
`the purpose of the RfR messages is for these messages to propagate through the
`
`network, eventually reaching the device which is the destination node. This
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 19
`
`

`

`
`
`destination node sends a response back to the source node and then the source
`
`node can communicate with the destination node over the established route.
`
`Larsson states, “If the node determines that it is not the destination node, in
`
`accordance with the ‘No’ path out of decision step 560, then the node is done
`
`with its processing for this message. However, if the node is the destination
`
`node, in accordance with the ‘Yes’ path out of decision step 560, the node will
`
`send a response back to the source node in accordance with step 565. In step 570
`
`the source node sends the unicast message to the destination node over the newly
`
`established route.” Larsson 3:17-251. Therefore, a POSITA would have
`
`understood the RfR message to seek a response for identifying a device, namely
`
`the destination node, available for joining a piconet.
`
`38. In addition, the route between the source node and destination node in
`
`Larsson involves intermediate nodes, namely the “route.” These intermediate
`
`devices themselves would constitute devices available for communications, ones
`
`identified in response to the RfR inquiry message.
`
`
`1 Note that this citation is in the prior art section of Larsson, but Larsson relies on this
`same request-for-route message mechanism when appending an additional data field. “These and
`other problems, drawbacks and limitations of conventional techniques are overcome according to
`the present invention by placing a broadcast message which the source expects a reply message
`in a broadcast message for route discovery.” Larsson 4:11-15.
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 20
`
`

`

`
`
`VI. GROUND 2: 802.11
`
`39. An 802.11 probe request is an electronic signal comprising an
`
`encoded series of zeroes and ones.
`
`40. The SSID information field box shown in Figure 35 below,
`
`highlighted in yellow, is a field in the SSID element format. When the length
`
`field for a probe request prescribes a zero-length SSID information field—as it
`
`does for “Broadcast” probe requests—the probe request will have nothing after
`
`the octet corresponding to the length field—nothing that corresponds to the
`
`SSID information field.
`
`
`
`
`
`41. Figure 35 is excerpted from 802.11, Ex. 1007 at 55 (highlighting
`
`added).
`
`42. A “Broadcast” probe request itself includes nothing that corresponds
`
`to the SSID information field.
`
`43. The field sequence in the MAC frame proceeds directly from the
`
`Length field of the SSID element to the Element ID field of the Supported rates
`
`element, with no SSID information field, for “Broadcast” probe requests.
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 21
`
`

`

`
`
`44. 802.11 uses the ASN.1 language, which is usually encoded using
`
`Basic Encoding Rules. See, e.g., 802.11, vi-vii (noting use of the ASN.1
`
`language in 802.11 protocol).
`
`45. The null value also has a length of zero, so, under the Basic Encoding
`
`Rules for encoding the ASN.1 language, it is encoded without a value octet, and
`
`may optionally be depicted in a protocol as lacking a third field, as it is in this
`
`excerpt from Dubuisson, Ex. 1031, at 398:
`
`
`
`46. In the excerpt above, the “T” label identifies the tag field, the “L”
`
`label identifies the length field, and the “V” label identifies where the value field
`
`would be if there was a value field. As Dubuisson explains at 398, n.3, the 010
`
`means zero in base 10, which is just zero.
`
`47. Similarly, Dubuisson also discusses the encoding of a value with zero
`
`length, which involves encoding only two octets as there is nothing coded for the
`
`third field (value field) of zero length, at page 397.
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 22
`
`

`

`
`
`48. Similarly, the Modbus Protocol, Ex. 1029, notes how “[t]he data field
`
`can be nonexistent (of zero length) in certain kinds of messages.” Modbus
`
`Protocol, 11.
`
`49. A field “set to zero” has zeros in it and is not the same as a zero-
`
`length field that does not exist. For example, Ex. 1032 (U.S. 6,687,766 B1) at
`
`12:45-50, shows a field with three bits “set to zeros”:
`
`
`
`50. Not every information element must have an information field, even
`
`though information elements generally have the format shown in Figure 34 of
`
`the 802.11 protocol, Ex. 1007 at 55. The SSID element in a “Broadcast” probe
`
`request and the null value in Dubuisson are two examples of information
`
`elements that do not have information fields.
`
`VII. SIGNATURE
`
`51. I, Peter Rysavy, do hereby declare and state that all statements made
`
`herein of my own knowledge are true and that all statements made on
`
`information and belief are believed to be true; and further that these statements
`
`were made with the knowledge that willful false statements and the like so made
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 23
`
`

`

`of the United States Code.
`
`Dated: May 19, 2020
`
`{~ Pct ~C-,
`
`are punishable by fine or imprisonment, or both, under Section 1001 ofTitle 18
`
`Signature
`
`I
`
`SECOND DECLARATION OF PETER RYSAVY
`
`Page 24
`
`

`

`APPENDIX 1
`
`Peter Rysavy – Curriculum Vitae
`
`PO Box 680, Hood River, OR 97031, USA
`+1-541-386-7475, public.temp1@rysavy.com, http://www.rysavy.com
`
`Peter Rysavy is an expert in wireless technology,
`mobile computing, and data networking
`
`Contents
`EDUCATION: .................................................................................................... 2
`WORK EXPERIENCE ......................................................................................... 2
`PATENTS .......................................................................................................... 5
`TESTIFYING AND CONSULTING EXPERIENCE IN LITIGATION.......................... 5
`PUBLIC SPEAKING ........................................................................................... 9
`PUBLISHED ARTICLES AND REPORTS .............................................................. 9
`WIRELESS COURSES ...................................................................................... 18
`
`Education:
`BSEE, MSEE Electrical Engineering, Stanford University, 1979.
`
`Work Experience
`Rysavy Research. 1993 to Present: President
`
`Peter Rysavy is president of Rysavy Research LLC, a consulting firm that has
`specialized in wireless technology and mobile computing since 1993. Projects have
`included evaluation of wireless technology capabilities, network performance
`measurement, reports on the evolution of wireless technology, spectrum analysis for
`broadband services, strategic consultations, system design, articles, courses and
`webcasts, and test reports.
`
`Peter Rysavy has expertise in IEEE 802.11 (Wi-Fi), wireless hotspots, mesh
`networks, metro and municipal Wi-Fi, paging technology, 2G, 3G, 4G, 5G, IMT-
`Advanced, IMT-2020, Global System for Mobile Communications (GSM), General
`Packet Radio Service (GPRS), Enhanced Data Rates for GSM Evolution (EDGE),
`Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access
`(CDMA), Wideband CDMA (WCDMA), High Speed Downlink Packet Access (HSDPA),
`High Speed Uplink Packet Access (HSUPA), High Speed Packet Access (HSPA),
`HSPA+, Long Term Evolution (LTE), LTE-Advanced, LTE-Advanced Pro, LTE-Licensed
`Assisted Access (LAA), LTE-U, CDMA2000, CDMA2000 1XRTT, Evolved Data
`Optimized (EV-DO), Bluetooth, WiMAX, IEEE 802.16 (IEEE 802.16e, IEEE 802.16m),
`wireless security, smartphones, smartphone operating systems, Mobile IP, Evolved
`Packet System (EPS), Evolved Packet Core (EPC), e-mail, wireless e-mail, browsers,
`mobile browsers, media gateways, orthogonal frequency division multiplexing
`(OFDM), orthogonal frequency division multiple access (OFDMA), voice over IP
`(VoIP), mobile video, wireless spectrum, spectrum sharing, spectral efficiency,
`capacity analysis, mobile computing architectures, and TCP/IP networking.
`
`Peter Rysavy Curriculum Vitae
`
`Page 25
`
`

`

`Patent Litigation
`
`Peter Rysavy has worked in numerous cases, both as testifying and consulting
`expert. He has trial experience, reports, and depositions. See section 4 for
`details.
`
`Analysis
`
`Rysavy Research analyzes wireless technologies for capability, compatibility,
`interoperability, and intellectual-property considerations.
`
`Training
`
`Rysavy Research conducts wireless-technology training, both publicly and
`privately.
`
`Testing and Reports
`
`Rysavy Research tests, evaluates, and reports on all major wireless
`technologies.
`
`Application Development and Deployment
`
`Rysavy Research works with companies to define architectures, select
`vendors, perform pilots, and to deploy wireless systems and applications.
`
`Clients (excluding confidential litigation cases) from 1993 to present
`include:
`
`5G Americas, AltaVista, Anchorage Partners, Antenna Software, Apple, Arris,
`AT&T, AT&T Wireless, Aventail, Black Lowe & Graham, Bluetooth SIG,
`Broadbeam, Cingular Wireless, City of Seattle, CMP Media, Compression
`Laboratories, Coinstar, Comverse Network Systems, Cricket Wireless,
`Crosslink Capital, Customer Focused Strategies, Datacomm Research, CTIA –
`The Wireless Association, Data Communications Maga