UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`__________
`
`APPLE, INC.
`Petitioner
`v.
`
`MAXELL, LTD.
`Patent Owner
`____________
`
`Case IPR2020-00202
`
`Patent 10,212,586
`
`____________
`
`Declaration of Dr. Victor Shoup
`
`IPR2020-00202
`Apple Inc. EX1056 Page 1
`
`
`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`__________
`
`APPLE, INC.
`Petitioner
`v.
`
`MAXELL, LTD.
`Patent Owner
`____________
`
`Case IPR2020-00202
`
`Patent 10,212,586
`
`____________
`
`Declaration of Dr. Victor Shoup
`
`IPR2020-00202
`Apple Inc. EX1056 Page 1
`
`
`
`TABLE OF CONTENTS
`
`
`BACKGROUND AND QUALIFICATIONS ....................................... 1
`I.
`II. OPINION ................................................................................................. 2
`Level of Skill of a Person Having Ordinary Skill in the Art .......... 2
`A.
`Bidirectional Communication ........................................................... 4
`B.
`1.
`Acknowledgements in 802.11 ......................................................... 7
`2.
`Acknowledgements in Bluetooth .................................................... 9
`C. Kirkup’s one-code and two-code configurations ........................... 10
`
`
`
`
`
`
`
`
`
`ii
`
`IPR2020-00202
`Apple Inc. EX1056 Page 2
`
`
`
`DECLARATION OF DR. VICTOR SHOUP
`
`I, Victor Shoup, Ph.D., hereby declare the following:
`
`I.
`
`BACKGROUND AND QUALIFICATIONS
`1. My name is Victor Shoup, and I am over 21 years of age and otherwise
`
`competent to make this Declaration. I make this Declaration based on facts and
`
`matters within my own knowledge and on information provided to me by others,
`
`and, if called as a witness, I could and would competently testify to the matters set
`
`forth herein.
`
`2.
`
`I have been retained as a technical expert witness in this matter by
`
`Counsel for the Petitioner, Apple Inc. (“Petitioner”) to provide my independent
`
`opinions on certain issues requested by Counsel for Petitioner relating to the
`
`accompanying Petition for Inter Partes Review of U.S. Patent No. 10,212,586 (“the
`
`’586 Patent”), claims 1-2, 6-7, 9-10, 13-14, and 16-18. I am being compensated at
`
`an hourly rate of $500. My compensation in this matter is not based on the substance
`
`of my opinions or on the outcome of this matter. I have been informed that Maxell,
`
`Ltd. is the purported owner of the ’586 Patent. I note that I have no financial interest
`
`in Maxell, Ltd. or Petitioner, and I have no other interest in the outcome of this
`
`matter.
`
`3.
`
`As part of my work and in forming my opinions in connection with this
`
`proceeding, I have reviewed the following materials, each of which I believe experts
`
`
`
`1
`
`IPR2020-00202
`Apple Inc. EX1056 Page 3
`
`
`
`in my field would reasonably rely upon in forming opinions regarding the subject
`
`matter of this proceeding:
`
`• Patent Owner’s Preliminary Response (IPR2020-00202, Paper 6)
`(“POPR”)
`• Decision Granting Institution of Inter Partes Review (IPR2020-00202,
`Paper 11) (“Institution Decision”)
`• Patent Owner’s Response (IPR2020-00202, Paper 17) (“POR”)
`• Deposition Transcript of Dr. Branimir Vojcic (Ex. 1060) (“Vojcic Trans.”)
`• Brent A. Miller & Chatschik Bisdikian, Bluetooth Revealed (2001)
`(“Miller”)
`• Plamen Nedeltchev, Wireless Local Area Networks and the 802.11
`Standard. March 31, 2001 (“Nedeltchev”)
`• Kin K. Leung, et al., Outdoor IEEE 802.11 Cellular Networks: MAC
`Protocol Design and Performance, 1 Proc. IEEE Int’l Conf. on Comm.
`595 (2002) (“Leung”)
`
`These materials are in addition to those previously disclosed in my Declaration
`
`(identified as Ex. 1003 in this proceeding).
`
`II. OPINION
`A. Level of Skill of a Person Having Ordinary Skill in the Art
`4.
`I have reviewed the Board’s preliminary determination as to the level
`
`of ordinary skill in the art at the time of the invention. (“For purposes of this
`
`proceeding, we determine that a person of ordinary skill in the art is a person having
`
`Bachelor’s degree in Electrical Engineering or Computer Science, or an equivalent
`
`degree, with at least two years of working experience in computer or network
`
`security, or wireless communications.”). Institution Decision at 22.
`
`
`
`2
`
`IPR2020-00202
`Apple Inc. EX1056 Page 4
`
`
`
`5.
`
`I have also reviewed Patent Owner’s proposed level of ordinary skill in
`
`the art. (“A person of ordinary skill in the art in the field of the ’586 Patent would
`
`have had a working knowledge of wireless communications, and gained this
`
`knowledge through a Bachelor of Science in Electrical Engineering, and at least one
`
`year of experience working in the field of wireless communications.”) POPR at 23.
`
`6.
`
`For the purposes of this declaration, I have applied the Board’s
`
`preliminary determination as to the level of ordinary skill in the art. However, none
`
`of the opinions expressed herein would change if the Board were instead to adopt
`
`Petitioner’s proposed level of skill in the art (as set forth and discussed in my original
`
`declaration) or Patent Owner’s proposed level of skill in the art.
`
`7.
`
`Based on my education, training, and professional experience in the
`
`field of the claimed invention, I am familiar with the level and abilities of a person
`
`of ordinary skill in the art at the time of the claimed invention. Additionally, I met
`
`at least these minimum qualifications to be a person having ordinary skill in the art
`
`at least as of May 23, 2012. Further, although my qualifications may exceed those
`
`of the hypothetical person having ordinary skill in the art defined above, my analysis
`
`and opinions regarding the ’586 Patent have been rendered from the perspective of
`
`a person having ordinary skill in the art at the time of the invention.
`
`
`
`3
`
`IPR2020-00202
`Apple Inc. EX1056 Page 5
`
`
`
`B.
`8.
`
`Bidirectional Communication
`I have reviewed Patent Owner’s Response, and I understand that Patent
`
`Owner contends that the claimed “short-range wireless communication” performed
`
`by the claimed transceiver while both devices are locked must include both
`
`transmitting and receiving information (i.e., bidirectional communications). As
`
`discussed below, there are two distinct bidirectional communications conducted over
`
`Kirkup’s “wireless communication link 145” while both the HED and PC are locked.
`
`First, as I explained in my original declaration at ¶ 66, establishing link 145
`
`necessarily involves bidirectional communication. Whether the system uses a three-
`
`way handshake as I described in my original declaration or some other connection
`
`establishment process, a POSITA would understand that establishing a wireless
`
`connection necessarily requires bidirectional communications. Indeed, were there
`
`only a single communication (i.e., a transmission with no response), the transmitting
`
`device would have no assurance that the receiving device actually received the
`
`message, and there would be no confirmation that a communication link has been
`
`established. Second, the request for unlocking sent to Kirkup’s HED in response to
`
`activating the PC (repeatedly discussed in my initial declaration, including at ¶¶ 61-
`
`62, 66) would have been acknowledged by the HED, regardless of whether link 145
`
`is implemented using Bluetooth or 802.11 (Wi-Fi)—two wireless standards
`
`expressly contemplated by Kirkup. Accordingly, the HED transceiver both receives
`
`
`
`4
`
`IPR2020-00202
`Apple Inc. EX1056 Page 6
`
`
`
`(the request from the PC) and transmits (an acknowledgment to the PC), satisfying
`
`even Patent Owner’s narrow interpretation of the claim.
`
`9.
`
`I note that wireless communication links are, by their nature, less
`
`inherently reliable than wired communication links. Factors such as noise,
`
`interference, and fading can cause a packet transmitted by a source terminal not to
`
`be received correctly by a destination terminal. See, e.g., Ex. 1057, Miller at p. 153
`
`(“[Bluetooth protocols] reflect the SIG’s objectives to develop simple, cost-effective
`
`communication systems that can operate at low power in noise-susceptible places.”).
`
`In order to build reliable communication protocols using unreliable wireless links,
`
`protocol designers employ (among other approaches) link-layer “acknowledgement”
`
`or “ACK” packets. I note that these wireless, link-layer ACK packets are separate
`
`from (and may be used with or without) end-to-end, transport-layer ACK packets
`
`(such as TCP ACK packets). Different wireless protocols vary in their precise
`
`implementation of ACK packets, as discussed below. However, at a high level, in
`
`systems employing such an approach, whenever a receiving terminal receives a valid
`
`data packet from a sending terminal, the receiving terminal generates and sends an
`
`ACK packet corresponding to the received packet back to the sending terminal. If a
`
`particular data packet or the corresponding ACK packet is lost, the sending terminal
`
`will never receive an ACK packet for that packet and (after an appropriate timeout)
`
`will attempt to retransmit the data packet. This process will continue until either the
`
`
`
`5
`
`IPR2020-00202
`Apple Inc. EX1056 Page 7
`
`
`
`sending terminal receives an appropriate ACK packet or a retransmission threshold
`
`is exceeded and the sending terminal concludes that the wireless connection has been
`
`lost.
`
`10.
`
`I have reviewed Dr. Vojcic’s deposition testimony regarding alleged
`
`support in the ’586 Patent for bidirectional communications. He conceded that the
`
`content of such communications is not expressly described, but that the patent
`
`implies “control message” are exchanged that permit checking whether the devices
`
`have been registered. Ex. 1060, Vojcic Trans., 11:23-12:25. Consistent with Dr.
`
`Vojcic’s description, ACK packets are considered control messages that contain
`
`information sufficient to identify the communicating entities such that a prior
`
`registration could be checked. Indeed, the purpose of exchanging ACKs is to control
`
`the connection, informing a sending device that a prior transmission was
`
`successfully received. As part of this connection control, they necessarily include
`
`some
`
`identifying
`
`information about
`
`the communicating entity. Similarly,
`
`establishing a wireless connection involves exchanging control messages that
`
`identify the communicating entities. As noted above and in my original declaration
`
`at ¶ 66, establishing Kirkup’s wireless communication link 145 would necessarily
`
`involve bidirectional communications. A POSITA would have considered these
`
`bidirectional communications “control messages” and would have understood that
`
`
`
`6
`
`IPR2020-00202
`Apple Inc. EX1056 Page 8
`
`
`
`identifying information is exchanged as part of the establishment process that would
`
`have allowed the devices to check for a prior registration.
`
`1.
`Acknowledgements in 802.11
`I note that both Kirkup and the ’586 Patent give the 802.11 family of
`
`11.
`
`standards (also known generally as WiFi or Wi-Fi) as one example of “short-range
`
`radio frequency communications” and “short-range wireless communications,”
`
`respectively. Ex. 1004, Kirkup at ¶ [0067]; Ex. 1001, ’586 Patent at 2:61-63. A
`
`POSITA would have understood that the 802.11 family of standards employs link-
`
`layer (MAC-level) Acknowledgement packets for reliable transmission. For
`
`example, a 2001 overview of the 802.11 standard explains that “[t]he mechanism is
`
`a simple Send-and-Wait algorithm, where the transmitting station is not allowed
`
`to transmit a new fragment until one of the following happens: it receives an
`
`ACK for the send fragment, or it decides that the fragment was retransmitted too
`
`many times and drops the whole frame.” Ex. 1058, Nedeltchev at 15. The timing for
`
`an ACK to be transmitted in 802.11 is called a “short-interframe spacing” (SIFS),
`
`and varies between 10 and 28 microseconds depending on the variant of 802.11. Id.
`
`(“Short Inter Frame Space (SIFS) is used to separate transmissions belonging
`
`to the single dialog (Fragment-ACK) and it is the minimum inter frame space.
`
`There is, at most, one single station to transmit at any given time, therefore giving it
`
`
`
`7
`
`IPR2020-00202
`Apple Inc. EX1056 Page 9
`
`
`
`priority over all other stations. This value for 802.11 PHY is fixed to 28 ms,1 time
`
`enough for the transmitting station to be able to switch back to receive mode
`
`and be capable of decoding the incoming packet.”); see also Ex. 1059, Leung at 3
`
`(discussing an SIFS interval of 10 µs).
`
`12. Leung, an AT&T Labs Research paper that builds on the 802.11 MAC,
`
`also similarly describes how a receiver is required to send an ACK responsive to
`
`every data packet within this SIFS timing:
`
`The 802.11 specification requires a receiver to send an ACK for
`each packet that is successfully received. Furthermore, to simplify the
`protocol header, an ACK contains no sequence number, and is used to
`acknowledge receipt of the immediately previous packet sent. That is,
`stations exchange data based on a stop-and-go protocol. As shown in
`Figure 2, the sending station is expected to receive the ACK within
`the 10 µs SIFS interval after the packet transmission is completed.
`If the ACK does not arrive at the sending station within a specified
`ACK_timeout period, or it detects transmission of a different packet on
`the channel, the original transmission is considered to have failed and
`is subject to retransmission by the backoff mechanism.
`
`Ex. 1059, Leung at 3. As such, the 802.11 MAC requires that the receiving station
`
`transmit an ACK packet in response to every received data packet.
`
`
`1 Nedeltchev uses the nonstandard “ms” to represent “microseconds.” The more standard,
`
`unambiguous “µs” is used instead in Leung.
`
`
`
`8
`
`IPR2020-00202
`Apple Inc. EX1056 Page 10
`
`
`
`13.
`
` In particular, if Kirkup’s wireless communication link 145 were
`
`established according to the 802.11 standard (as expressly contemplated by Kirkup),
`
`all data packets (such as the data packet in Kirkup sent from PC 110 seeking the
`
`authentication code; see, e.g., Ex. 1004, Kirkup, ¶ [0049]) sent across data link 145
`
`would have been acknowledged by the mandatory ACK packets of the 802.11 MAC.
`
`2.
`Acknowledgements in Bluetooth
`14. Like 802.11, both Kirkup and the ’586 Patent identify the Bluetooth
`
`standard as another example of “short-range radio frequency communications” and
`
`“short-range wireless communications,” respectively. Ex. 1004, Kirkup at ¶ [0067];
`
`Ex. 1001, ’586 Patent at 2:61-63. Also like 802.11, the Bluetooth link layer uses
`
`acknowledgement packets to ensure a reliable data connection in a noisy
`
`environment. See, e.g., Ex. 1057, Miller at p. 153. In particular, Miller describes
`
`how Bluetooth packets2 can be divided into “asynchronous connectionless (ACL)”
`
`packets or “synchronous connection-oriented (SCO)” packets based on the link type.
`
`Id. at 119. SCO links are used for real-time audio (typically voice audio) links. Id.
`
`at 93; see also id. at 123 (“SCO links carry telephony-grade voice audio…”). ACL
`
`links, by contrast, carry asynchronous (non-real-time), normal-priority data. Id at
`
`
`2 Miller, in accordance with the Bluetooth standard refers to Bluetooth packets as
`
`“baseband packet data units,” or BB_PDUs. Ex. 1057, Miller at fn. 5.
`
`
`
`9
`
`IPR2020-00202
`Apple Inc. EX1056 Page 11
`
`
`
`122-23. ACL links are point-to-point, and all ACL data packet exchanges use ACK
`
`packets to perform retransmissions when necessary. Id. (“Point-to-point ACL
`
`BB_PDU exchanges are all acknowledged and retransmitted as appropriate.”).
`
`15.
`
` Because Kirkup uses the short-range wireless connection (here,
`
`Bluetooth) to exchange authentication information rather than real-time voice data,
`
`I would understand the disclosure of Kirkup to teach that, when using Bluetooth,
`
`wireless link 145 between the handheld electronic device and the PC would be a
`
`Bluetooth ACL link, rather than a Bluetooth SCO link. This would be the case both
`
`to establish a reliable link to exchange the authentication information, but also to
`
`avoid consuming the limited number of SCO links available to the PC and handheld
`
`electronic device. See id. (“[A] master may establish up to three SCO links in total
`
`between it and all of its slave.”). If Kirkup’s link 145 were appropriately
`
`implemented as an ACL BB_PDU data link, acknowledgements to data packets
`
`(such as the data packet in Kirkup sent from PC 110 seeking the authentication code;
`
`see, e.g., Ex. 1004, Kirkup, ¶ [0049]) would be mandatory as discussed above for
`
`BB_PDU ACL links.
`
`C. Kirkup’s one-code and two-code configurations
`16.
`I would understand Kirkup’s teachings at ¶¶ [0054]–[0057] to describe
`
`distinct one-code and two-code configurations for unlocking the PC using the HED
`
`as part of method 200.
`
`
`
`10
`
`IPR2020-00202
`Apple Inc. EX1056 Page 12
`
`
`
`17. Kirkup describes the two-code configuration ¶¶ [0054]–[0056]. In such
`
`a two-code configuration, “the user may be required to input the password in order
`
`to unlock the user interface of the handheld electronic device 120, and subsequently
`
`input the PIN code in order to authorize access to the authentication code stored on
`
`the smart-card. Ex 1004, Kirkup at ¶ [0054] (emphasis added). Accordingly, this
`
`configuration requires two distinct coded entries—a first to unlock the HED and a
`
`second to authorize releasing a code to the PC.
`
`18.
`
`In Kirkup’s one-code configuration, “once the handheld electronic
`
`device is unlocked by entry of an appropriate PIN code or password, it may be
`
`configured not to require subsequent entry of any further user identification code.”
`
`Ex. 1004, Kirkup at ¶ [0054]. Accordingly, the single code entry in this one-code
`
`configuration requires a PIN or password to unlock the device, but does not require
`
`a second coded input to release the authorization code from the HED to the PC.
`
`19. Two variants of this one-code configuration are further disclosed—“the
`
`authentication code may be provided to the PC 110 automatically upon
`
`establishment of communication link 115 or in response to a simple authorization
`
`action performed by the user.” Ex. 1004, Kirkup at ¶ [0057]. The first variant, which
`
`I will call one-code-plus-uncoded-user-input, is discussed in detail at ¶¶ [0057] and
`
`[0079]. In both paragraphs, Kirkup describes a further “uncoded” authorization that
`
`may be required, such as the user selecting “yes” or “ok” to a dialog box. As clearly
`
`
`
`11
`
`IPR2020-00202
`Apple Inc. EX1056 Page 13
`
`
`
`explained in ¶ [0054], the one-code configuration always requires an initial coded
`
`input (PIN or password) to unlock the device. So a POSITA would have understood
`
`the uncoded authorization described at ¶¶ [0057] and [0079] assumes the user has
`
`already authenticated herself by unlocking the HED with a PIN or password.
`
`20. The second variant, which I will call one-code-with-no-further-user-
`
`input, is discussed in detail at ¶ [0082]. There, Kirkup describes how (in such a
`
`configuration) “the handheld electronic device 120 is not configured to require any
`
`user input prior to provision of the authentication code to the PC … where the
`
`handheld electronic device has already been unlocked.” Like the variant discussed
`
`in the preceding paragraph, this lack of “any user input” assumes the user has already
`
`authenticated herself by unlocking the HED with a PIN or password. In other words,
`
`this second variant is simply distinguishing what is required after the handheld
`
`electronic device is unlocked from (1) the “uncoded input” of the one-code-plus-
`
`uncoded-user-input and (2) the second “coded input” of the two-code configuration
`
`discussed below. In this one-code-with-no-further-user-input variant of the one-code
`
`configuration, steps 220, 223, and 225 are skipped if the handheld electronic device
`
`is unlocked.
`
`21.
`
`I would not understand Kirkup to teach or suggest a no-code
`
`configuration in which the PC may be unlocked without ever authenticating the user
`
`by unlocking the HED with a PIN or password. Indeed, I would understand such a
`
`
`
`12
`
`IPR2020-00202
`Apple Inc. EX1056 Page 14
`
`
`
`no-code configuration would offer no security whatsoever, allowing any person with
`
`physical possession of the HED to unlock the PC, which a POSITA would
`
`understand is contrary to Kirkup’s focus on secure methods of “authenticating a
`
`user” as stated in Kirkup’s Title and reemphasized in the Abstract: “The handheld
`
`electronic device requires a second authentication code for enabling use thereof.
`
`In order to authenticate the user to the computer, the handheld electronic device is
`
`configured to transmit the first authentication code to the computer over a
`
`communication link between the computer and the handheld electronic device.” Ex.
`
`1004, Kirkup at Abst.; see also ¶ [0006].
`
`
`
`
`
`13
`
`IPR2020-00202
`Apple Inc. EX1056 Page 15
`
`
`
`I declare that all statements made herein of my knowledge are true, and that
`
`all statements made on information and belief are believed to be true, and that these
`
`statements were made with the knowledge that willful false statements and the like
`
`so made are punishable by fine or imprisonment, or both, under Section 1001 of Title
`
`18 of the United States Code.
`
`
`
`/
`Dr. Victor Shoup
`
`,/
`
`Date: (2/; I; all
`
`14
`
`|PR2020-00202
`
`Apple Inc. EX1056 Page 16
`
`IPR2020-00202
`Apple Inc. EX1056 Page 16
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
