`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`___________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`___________________
`
`
`TCT MOBILE (US), INC.; TCT MOBILE (US) HOLDINGS, INC.;
`HUIZHOU TCL MOBILE COMMUNICATION CO. LTD.; AND
`TCL COMMUNICATION, INC.
`
`Petitioner,
`
`v.
`
`Fundamental Innovation Systems International LLC,
`Patent Owner.
`___________________
`
`Case IPR2021-00395
`Patent No. 7,239,111
`___________________
`
`
`DECLARATION OF DR. KENNETH FERNALD IN SUPPORT OF
`PATENT OWNER'S RESPONSE
`
`10928705
`
`
`
`
`
`
`Fundamental Ex 2009-p 1
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`TABLE OF CONTENTS
`
`I.
`II.
`
`Page
`Introduction ............................................................................................ 1
`Technology Background ........................................................................ 5
`A.
`USB Topology ............................................................................. 5
`B.
`USB Hub ...................................................................................... 6
`Device States and Enumeration ................................................. 14
`C.
`Speed Detection ......................................................................... 23
`D.
`III. Use of SE1 in Cited Prior Art ............................................................... 26
`The '550 Inventions .............................................................................. 33
`IV.
`Level And Knowledge Of Skill In The Art .......................................... 35
`V.
`VI. Use of SE1 in Morita's System ............................................................. 37
`A. Morita ......................................................................................... 37
`TCT's modification would disable the USB-hub
`B.
`controllable charger's primary functionality .............................. 46
`There is no conceivable reason for Morita's charger to
`generate a signal that identifies a power source type ................. 56
`There were other known methods to enable charging or
`inform power source type that would not interfere with
`normal USB communications .................................................... 60
`
`C.
`
`D.
`
`10928705
`
`- i -
`
`Fundamental Ex 2009-p 2
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`I.
`
`Introduction
`1. My name is Kenneth Fernald, Ph.D. My qualifications are
`
`summarized below and are addressed more fully in my CV attached as
`
`EXHIBIT A.
`
`2.
`
`For over 35 years I have been involved in the design of integrated
`
`circuits. A large portion of my work has involved the design of integrated
`
`circuits that involve power management, battery charging and USB control. I
`
`have designed USB controllers that have sold in the hundreds of millions of
`
`units, and I was intimately involved in this field during the time of the patents
`
`at issue in this case.
`
`3.
`
`I earned my Bachelor of Science and Master of Science degrees in
`
`Electrical Engineering from North Carolina State University (NCSU) in 1985
`
`and 1987. During this period I worked for the Space Electronics Group
`
`developing software for predicting the effects of radiation environments on
`
`integrated circuits. I also consulted for the Naval Research Laboratory (NRL).
`
`My services to NRL included the design of dosimetry instrumentation and the
`
`execution of radiation studies on electronic devices at various facilities around
`
`the United States. I joined NASA Langley Research Center in 1987 where I
`
`designed motor control instruments and firmware for ground and space station
`
`experiments.
`
`4.
`
`I returned to NCSU in 1988 to earn my Ph.D. in Electrical
`
`10928705
`
`
`- 1 -
`
`
`
`Fundamental Ex 2009-p 3
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`Engineering. My doctoral research efforts were funded by the National
`
`Science Foundation and focused on the development of medical systems
`
`utilizing wireless digital telemetry. My work included a thorough investigation
`
`of medical telemetry technology and design of a microprocessor-based system
`
`for the fast prototyping of implantable medical instruments. I also completed
`
`the design and testing of various components of this system, including a
`
`bidirectional digital telemetry integrated circuit (IC) and a general-purpose
`
`sensor interface and conversion IC. I completed my Ph.D. in 1992, after which
`
`I joined Intermedics Inc. in Angleton, Texas.
`
`5. My responsibilities at Intermedics included system and circuit
`
`design of telemetry, signal-processing, and control ICs for medical devices.
`
`Examples include the design of a sensor acquisition, compression, and storage
`
`IC for implantable pacemakers and defibrillators. I also worked on advanced
`
`wireless digital telemetry technology, control ICs for therapy delivery in
`
`defibrillators, and software development for sensor waveform compression and
`
`recovery. I left Intermedics in 1998 to join Analog Devices Inc. in Greensboro,
`
`NC.
`
`6. My work at Analog Devices included the design of advanced ICs
`
`for wireless digital communication devices. Specific projects included the
`
`design, debug, and testing of a base-band receiver IC for digital satellite
`
`systems. This IC performed QPSK demodulation, symbol recovery, and
`- 2 -
`
`
`10928705
`
`
`Fundamental Ex 2009-p 4
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`forward-error correction for high-bandwidth wireless video signals. I also
`
`performed system design for a CDMA base-band transceiver IC for personal
`
`communication devices.
`
`7.
`
`I rejoined Intermedics in 1998 as the first employee of an IC
`
`design group in Austin, Texas. I continued to work on next-generation medical
`
`telemetry ICs until Intermedics was acquired by Guidant in 1999. At that time
`
`I joined Cygnal Integrated Products, a startup company in Austin, Texas. My
`
`responsibilities at Cygnal included the design and development of mixed-signal
`
`embedded products for industrial and instrumentation applications. Specific
`
`projects included the design of a proprietary communication system for in-
`
`system debug, a proprietary clock recovery method for USB devices, and the
`
`design of numerous analog and digital circuits and systems. I remained at
`
`Cygnal until its acquisition by Silicon Laboratories Inc. in 2003, at which time
`
`I joined Zilker Labs, a start-up company in Austin, Texas, as their first VP of
`
`Engineering and later became their Chief Technical Officer.
`
`8. My responsibilities at Zilker Labs included the development of
`
`advanced IC technologies for power management and delivery for board-level
`
`electronic systems. Specific duties included architecture design and firmware
`
`development for all Zilker Labs products. I left Zilker Labs in 2006 to join
`
`Keterex as their first VP of Engineering. My responsibilities at Keterex
`
`included management of engineering resources, design and layout of
`- 3 -
`
`
`10928705
`
`
`Fundamental Ex 2009-p 5
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`application-specific integrated circuits, and development of software and
`
`firmware for Keterex products. I joined Silicon Laboratories in 2010 as a
`
`Principal Design Engineer and I held the title of Fellow when I retired in 2017.
`
`My responsibilities included architecture development and design of 8-bit and
`
`32-bit microcontrollers. Projects included microcontrollers for metrology,
`
`motor control, and low-power and USB applications.
`
`9.
`
`I hold over 70 patents on technologies such as wireless telemetry
`
`for medical devices, low-power analog-to-digital converters, security in
`
`embedded systems, clock recovery in communication systems, serial
`
`communication protocols, and power management and conversion. I have
`
`authored or co-authored over 25 articles, presentations, and seminars on topics
`
`including radiation effects in microelectronics, wireless medical devices, low-
`
`power circuit design, circuit design for digital communications,
`
`microcontrollers and embedded systems, and power management. I am also a
`
`co-author of the PMBus™ Power System Management Protocol Specification.
`
`10.
`
`I have been asked by Fundamental Innovation Systems
`
`International LLC to explain the technologies involved in U.S. Patent Nos.
`
`7,239,111, 6,936,936 and 8,624,550, the technologies described in the cited
`
`references, the knowledge of a person of ordinary skill in the art at the time of
`
`the invention, and other pertinent facts and opinions regarding IPR2021-00395,
`
`IPR2021-00410 and IPR2021-00428.
`- 4 -
`
`10928705
`
`
`
`
`Fundamental Ex 2009-p 6
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`11.
`
`I am being compensated for my work on this case at a fixed,
`
`hourly rate, plus reimbursement for expenses. My compensation does not
`
`depend on the outcome of this case or any issue in it, and I have no interest in
`
`these proceedings. The testimony below is provided from the perspective of a
`
`person of ordinary skill in the art at the time of the inventions.
`
`II. Technology Background
`12.
`I provide below an overview of the pertinent parts of the Universal
`
`Serial Bus ("USB") technology. Because TCT's petitions cite predominantly
`
`from the USB 1.1 Specification ("USB 1.1"), the figures I reproduce below are
`
`also from USB 1.1. The page numbers cited below are the original page
`
`numbers of the USB specifications.
`
`A. USB Topology
`13. USB has a tiered star bus topology as shown below. USB 1.1 at
`
`16; USB 2.0 at 16. USB 1.1 permits up to 4 tiers below the root tier while
`
`USB 2.0 permits up to 7 tiers. Id.
`
`10928705
`
`
`- 5 -
`
`
`
`Fundamental Ex 2009-p 7
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`
`
`14. A USB host at the top of the tier is connected to a node (or a
`
`function) through the tiered star topology shown above. The host/roothub may
`
`be connected directly to a hub or a function. A hub "provide[s] additional
`
`attachment points to the USB"; and a function—"such as an ISDN connection,
`
`a digital joystick, or [a] speaker[]"—"provide[s] capabilities to the system."
`
`USB 1.1 at 16, § 4.1.1.2; USB 2.0 at 17, § 4.1.1.2.
`
`15. Because TCT's primary reference Morita concerns a USB "hub-
`
`controllable charger" (see Morita, Abstract), I provide below some basic facts
`
`about a USB hub.
`
`B. USB Hub
`16. At the center of each star in the above topology is a USB hub. A
`
`hub connects to either a host or another hub in the upstream direction and to
`
`another hub or one or more nodes (functions) in the downstream direction. See
`
`USB 1.1 at 230, Fig. 11-1 (reproduced below); USB 2.0 at 298, Fig. 11-1.
`
`10928705
`
`
`- 6 -
`
`
`
`Fundamental Ex 2009-p 8
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`
`
`17.
`
`"The Hub Repeater is responsible for managing connectivity on a
`
`per-packet basis, while the Hub Controller provides status and control and
`
`permits host access to the hub." USB 1.1 at 230; see also USB 2.0 at 297
`
`("The Hub Repeater is responsible for managing connectivity between
`
`upstream and downstream facing ports which are operating at the same speed.
`
`… The Hub Controller provides status and control and permits host access to
`
`the hub.").
`
`18. The Hub Repeater has one and only one upstream port that
`
`connects in the upstream direction to a host or an upper-level hub. USB 1.1 at
`
`231; USB 2.0 at 298. The Hub Repeater also has one or more downstream
`
`ports facing towards a function or a lower-level hub. Id.
`
`19. Packets sent in an upstream direction are sent to the upstream port
`
`only and not to any of the other downstream ports. In contrast, packets sent in
`
`10928705
`
`
`- 7 -
`
`
`
`Fundamental Ex 2009-p 9
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`a downward direction are broadcast to all enabled downstream ports. USB 1.1
`
`at 231, Fig. 11-2; USB 2.0 at 298-99, Fig. 11-2.
`
`
`
`20. When a hub is in a suspended mode and resume signaling comes
`
`from an upstream port, that signaling is reflected to all downstream ports. In
`
`contrast, resume signaling from a downstream port is reflected to the upstream
`
`port and all other non-disabled or non-suspended ports. USB 1.1 at 232, Fig.
`
`11-3; USB 2.0 at 299, Fig. 11-3.
`
`21. Because hubs "are the essential USB component for establishing
`- 8 -
`
`
`10928705
`
`
`
`
`Fundamental Ex 2009-p 10
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`connectivity between the host and other devices," it is "vital that any
`
`connectivity faults, especially those that might result in a deadlock, be detected
`
`and prevented from occurring." USB 1.1 at 232; USB 2.0 at 300.
`
`22. A hub can be classified as a bus-powered hub or a self-powered
`
`hub based on the source of its power supply. USB 1.1 at 134; USB 2.0 at 171.
`
`
`
`23. As is clear from the USB specification reproduced above, a bus-
`
`powered hub draws all of its energy for downstream ports and any internal
`
`functions from the VBUS line of the hub's upstream port. In contrast, a self-
`
`powered hub has an alternate power source for its internal functions and
`
`downstream ports. Id.; see also USB 1.1 at 18 ("USB devices that rely totally
`
`on power from the cable are called bus-powered devices. In contrast, those that
`
`have an alternate source of power are called self-powered devices."); USB 2.0
`
`at 18 (same).
`
`24. An annotated schematic of a self-powered hub is shown below
`
`("compound" refers to the fact the hub also has internal or non-removable
`
`10928705
`
`
`- 9 -
`
`
`
`Fundamental Ex 2009-p 11
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`functions in addition to downstream ports). USB 1.1 at 136, Fig. 7-33; USB
`
`2.0 at 172-73, Fig. 7-33. As seen below, "Local Power Supply" supplies power
`
`to both the downstream ports and the non-removable function via a power
`
`regulator (which may include over-current protection). USB 1.1 at 134, 136;
`
`USB 2.0 at 171, 172-73. A self-powered hub may (but need not) draw up to 1
`
`unit load, or 100 mA, of current from its upstream port to supply power to the
`
`USB hub controller (but not to supply power to the downstream ports or the
`
`internal functions). Id.
`
`
`
`25.
`
`In contrast to a bus-powered hub, each downstream port of a self-
`
`powered hub can supply 500 mA or 5 unit loads of current. This is particularly
`
`the case when the alternate or local power supply is a non-battery power, such
`
`as an AC power from an outlet. See USB 1.1 at 134 ("Hubs that obtain
`- 10 -
`
`
`10928705
`
`
`Fundamental Ex 2009-p 12
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`operating power externally (from the USB) must supply five unit loads to each
`
`port. Battery-powered hubs may supply either one or five unit loads per port.");
`
`USB 2.0 at 171 (same).
`
`26. The USB specification also requires that a hub "be able to provide
`
`the maximum current per port (one unit load of current per port for bus-
`
`powered hubs and five unit loads per port for self-powered hubs)" even
`
`"[w]hen [the] hub is in the Suspend state." USB 1.1 at 139; USB 2.0 at 176.
`
`"This is necessary to support remote wakeup-capable devices that will power-
`
`up while the remainder of the system is still suspended." Id.
`
`27. A downstream port in a self-powered hub that is powered by an
`
`AC power source would be considered a High-power Hub Port, because the
`
`port can meet the power demand of a High-power function requiring up to
`
`500mA of current. USB 1.1 at 142, Table 7-5; USB 2.0 at 178, Table 7-5.
`
`10928705
`
`
`- 11 -
`
`
`
`
`
`Fundamental Ex 2009-p 13
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`28. Of note, there is no inconsistency between Table 7-5's requirement
`
`of a "Min." output from a High-power Hub port and the reference of
`
`"maximum current per port" (e.g., USB 1.1 at 139) in other parts of the
`
`reference. As seen in Table 7-5, a USB function is limited to draw up to
`
`500mA of current per port. USB 1.1 at 142, Table 7-5; USB 2.0 at 178, Table
`
`705. The amount of current drawn by a connected USB device determines the
`
`current that is supplied from the port. The "Min." 500mA requirement in Table
`
`7-5 is to make sure that the port has enough capacity to furnish the maximum
`
`500mA of current that a high-power function is allowed to draw from the port.
`
`It does not mean, however, in a USB-compliant system, more than 500 mA of
`
`current is allowed to be drawn or supplied from a High-Power Hub port.
`
`29. Were a USB port to supply as much current as it can without
`
`regard to the current demand of the device drawing the current, the limit of 100
`
`mA of current draw before configuration would be meaningless: Even while
`
`completing enumeration, the device would be supplied with much more current
`
`than the 100mA it is allowed to draw. A POSITA also would not design a
`
`USB port to supply more current than that drawn by the downstream cables
`
`and devices because that over-supply of current would result in wasted
`
`power/energy and the excess current would be converted into excess heat that
`
`would raise the operating temperature of the USB connection, hub, cable
`
`and/or device, degrade electrical performance (such as signal integrity) and
`- 12 -
`
`
`10928705
`
`
`Fundamental Ex 2009-p 14
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`even damage the USB connections and cables. Furthermore, forcing excess
`
`current into a device could raise the supply voltage to levels that would damage
`
`the device's circuitry.
`
`30. An example of a self-powered hub is Morita's USB hub-
`
`controllable charger, whose annotated Figure 1 with matching color to USB
`
`specification's Figure 7-33 is provided below. (Note, the arrows and texts are
`
`by TCT).
`
`31.
`
`In this hub charger, the USB-hub controller 27, downstream ports
`
`24 for external peripherals and USB port 21 for connecting to the dual-role
`
`mobile device (i.e., one that can operate both as a host and as a device) all
`
`
`
`10928705
`
`
`- 13 -
`
`
`
`Fundamental Ex 2009-p 15
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`receive their power from the external power supply unit 22 via the power
`
`regulator (charging control unit) 23. Morita at [0014] ("A power supply
`
`voltage supplied from a power supply source is supplied from the charging
`
`control unit 23 to the USB hub control unit 27 and the second USB port 21.");
`
`[0016] (p. 9, col. 5, ll. 1-5) ("The power supply cable 22 is connected to an
`
`outlet or the like connected to a commercial power supply, and the supplied
`
`power supply voltage is supplied to the mobile videophone device 100 via the
`
`USB port 21 to charge an internal battery and supply power supply voltage
`
`from the USB port 24 to an external peripheral").
`
`C. Device States and Enumeration
`32. When a USB device is connected to a USB host, the host and the
`
`device undergo a series of handshakes in order for the host to access the
`
`device's functions. This process—which involves "initial exchange of
`
`information that enables the host's device driver to communicate with the
`
`device"—is called enumeration. Ex. 2003 ["USB Complete" 1st] at 74.
`
`Because a hub is also a USB device, "the host enumerates a newly attached hub
`
`in exactly the same way it enumerates a device. If the hub has devices
`
`attached, the host also enumerates each of these after the hub informs the host
`
`of their presence." Id., at 79-80.
`
`33. The enumeration process involves a series of steps. First, when a
`
`user plugs the device in to the powered port of a USB hub, the device enters
`
`10928705
`
`
`- 14 -
`
`
`
`Fundamental Ex 2009-p 16
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`the "powered" state. Ex. 2003 at 76; Ex. 2006 [USB Complete 2nd ed.] at 96.
`
`In this state, the device may receive power from the USB hub—however, it
`
`may not draw more than 100 mA from VBUS until it is configured. USB 1.1
`
`at 178; USB 2.0 at 242. Furthermore, the USB port to which the device is
`
`attached is disabled (USB 1.1 at 179; USB 2.0 at 243), and the USB device
`
`cannot respond to any requests from the USB bus until it receives a "reset"
`
`command from the bus. USB 1.1 at 178-79; USB 2.0 at 242-43.
`
`34. Next, the hub detects the device by "monitor[ing] the voltages on
`
`the signal lines of each of its ports." Ex. 2003 at 76; Ex. 2006 at 96. In this
`
`step, the USB device sends a high voltage on either the D+ or D- line. Id. The
`
`USB hub detects the voltage and determines that the device is either a full-
`
`speed device (if D+ is high) or a low-speed device (if D- is high). Ex. 2003 at
`
`76, 77; Ex. 2006 at 96, 97 (detecting whether a full-speed device supports high
`
`speed); USB 1.1 at 179; USB 2.0 at 243. Upon detecting the device, the hub
`
`"continues to provide power but doesn't transmit USB traffic to the device."
`
`Ex. 2003 at 76; Ex. 2006 at 96. The hub then reports to the host that one of its
`
`ports (and indicates which port) has experienced an event. Id.
`
`35. The host learns of the nature of the event, and of the attachment of
`
`the new device, by sending a "Get_Port_Status" request. Ex. 2003 at 76; Ex.
`
`2006 at 96.
`
`36. Then, the host issues a port enable and reset command to the port,
`- 15 -
`
`
`10928705
`
`
`Fundamental Ex 2009-p 17
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`which puts the port into the "enabled" state. USB 1.1 at 179; USB 2.0 at 243;
`
`Ex. 2003 at 76; Ex. 2006 at 97. In an enabled state, the host can now signal the
`
`connected USB device with control packets.
`
`37. After the reset, the USB device enters the "default" state and can
`
`still draw no more than 100 mA from the VBUS line. Id. In this state, the
`
`USB device uses the "default address" of 0 to receive control requests. USB
`
`1.1 at 179; USB 2.0 at 243; Ex. 2003 at 77; Ex. 2006 at 97.
`
`38. The USB host then reads the device's device descriptor to
`
`determine the maximum data payload the USB device can use. Id. Maximum
`
`data payload refers to the maximum packet size. Id. Either before or after the
`
`USB host requests the device's device descriptor to determine the maximum
`
`payload, the host assigns a unique address to the USB device, such that it is in
`
`the "Address" state. USB 1.1 at 179; USB 2.0 at 243; Ex. 2003 at 77-78; Ex.
`
`2006 at 98.
`
`39. The host then "sends a Get_Descriptor" request to the new address
`
`to learn about the device's abilities. Ex. 2003 at 78; Ex. 2006 at 98. The
`
`standard USB descriptors include the following fields (see USB 1.1 at 197-98,
`
`USB 2.0 at 263-64, Table 9-8):
`
`10928705
`
`
`- 16 -
`
`
`
`Fundamental Ex 2009-p 18
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`
`
`10928705
`
`
`- 17 -
`
`
`
`Fundamental Ex 2009-p 19
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`
`
`40. The descriptor description above matches that listed in U.S.
`
`5,884,086 ("Amoni"), Table II. As noted by Amoni, the descriptors can
`
`include information unique to a device, including its nonstandard voltage or
`
`current configurations. For example, such information can be encoded by
`
`10928705
`
`
`- 18 -
`
`
`
`Fundamental Ex 2009-p 20
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`"assign[ing] a vendor specific Device Class . . . and designat[ing] a unique
`
`device sub-class assignment with unique encoded voltage and power
`
`requirements." Ex. 2004 [Amoni] at 7:16-19. Alternatively, the information
`
`can be encoded with "a Product String Index [iProduct] pointing to a string
`
`containing voltage and current requirements." Id. at 7:27-29. Additionally, the
`
`USB specification provides that the "assignment of class, subclass, and
`
`protocol codes must be coordinated but is beyond the scope of this
`
`specification." USB 1.1 at 181; USB 2.0 at 245. Hence, the USB Specification
`
`does not restrict the content or values that may be associated with Device Class
`
`or device sub-class. Additionally, the USB specification does not limit the
`
`content of the string descriptor associated with iProduct.
`
`41. The host continues to learn about the device "by requesting the
`
`one or more configuration descriptors specified in the device descriptor." Ex.
`
`2003 at 78. The configuration descriptor has the following fields (USB 1.1 at
`
`199-200, Table 9-8; USB 2.0 at 265-66, Table 9-10). As Amoni noted, the
`
`iConfiguration field can also be used to encode a device's nonstandard voltage
`
`or current configuration, e.g., with the index "point[ing] to the location of a text
`
`string of UNICODE format" as specified in section 9.6.7 of USB 2.0. Ex. 2004
`
`[Amoni] at 7:37-44. Again, the USB specification does not limit the content of
`
`the text string descriptor associated with iConfiguration.
`
`10928705
`
`
`- 19 -
`
`
`
`Fundamental Ex 2009-p 21
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`10928705
`
`
`- 20 -
`
`
`
`
`
`
`
`Fundamental Ex 2009-p 22
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`42. The host then reads the "configuration" information from the
`
`device, which contains information about the device's capabilities. USB 1.1 at
`
`179; USB 2.0 at 243; USB 2.0 at 243; Ex. 2003 at 77; Ex. 2006 at 98-99.
`
`Finally, the host assigns a configuration value to the USB device, which puts
`
`the device into the "configured" state. USB 1.1 at 179; USB 2.0 at 244; Ex.
`
`2003 at 79; Ex. 2006 at 99-100. Before this step, since the host does not yet
`
`know what additional functionality the device can support, the host will only
`
`issue standard device requests, and hence the device will only respond to
`
`standard device requests. See USB 1.1 at 185-87; USB 2.0 at 250-51
`
`(describing the various standard device requests and noting that "USB devices
`
`must respond to standard device requests, even if the device has not yet been
`
`assigned an address or has not been configured"); Ex. 2003 at 37 (application
`
`communications begin after enumeration); Ex. 2006 at 41 (same). After it is
`
`configured, however, the device can participate in additional USB
`
`communications, and draw an amount of current, as defined by MaxPower,
`
`across the VBUS according to its configuration. USB 1.1 at 179; USB 2.0 at
`
`244; Ex. 2003 at 79; Ex. 2006 at 99-100.
`
`43. Shortly after the enumeration process has been completed, the
`
`device transitions from being unrecognized by the USB host, to being
`
`identified, configured, and ready for operation. This configuration is critical to
`
`normal operation of the USB device, because "[a] USB device must be
`- 21 -
`
`
`10928705
`
`
`Fundamental Ex 2009-p 23
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`configured before its function(s) may be used." USB 1.1 at 179; USB 2.0 at
`
`243. The USB device may now also draw power over the VBUS line
`
`according to the configuration information set by the USB host. Id.
`
`44. When a hub instead of a device is connected to a host, the host
`
`also undergoes enumeration with the hub (as well as any devices attached to
`
`the hub) using the same procedures as described above. Ex. 2003 at 79-80; Ex.
`
`2006 at 100.
`
`45. A host's USB system software "examines hub descriptor
`
`information to determine the hub's characteristics" to reject illegal power
`
`topologies. USB 1.1 at 261-62; USB 2.0 at 340-41. The Hub power operating
`
`modes include the following. Id.
`
`10928705
`
`
`- 22 -
`
`
`
`
`
`Fundamental Ex 2009-p 24
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`46. Thus, if a high-power function is connected to e.g., a bus-power
`
`hub or otherwise low-power hub, the host will reject the proposed
`
`configuration or select a lower-power configuration in order to ensure that the
`
`maxPower set for a device does not exceed the hub's power capability. USB
`
`1.1 at 179 (enumeration process); Cf., USB Complete 2nd Ed. at 447-48. If a
`
`configuration is not accepted, the device can only draw 100mA per port. USB
`
`1.1 at 142, Table 7-5.
`
`D.
`Speed Detection
`47. One step in USB communication is for a hub to detect the speed
`
`of an attached device. USB 1.1 at 251-52. That determination is made "by the
`
`placement of a pull-up resistor on the device." Id. Two illustrations are shown
`
`below, as reproduced from USB 1.1 at 113-114.
`
`48.
`
`I understand that TCT and its expert, Dr. Baker, suggests instead
`
`connecting the pull-down resistors on the hub side high, as annotated below, to
`
`generate the SE1 state. See, e.g., IPR2021-00395 Pet. 48.
`
`10928705
`
`
`- 23 -
`
`
`
`Fundamental Ex 2009-p 25
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`
`
`49. TCT is probably proposing that with the pull-down resistors on
`
`the hub side being pulled high, the USB transceiver in the mobile device would
`
`observe high on both D+ and D-. In USB, if speed evaluation is performed "on
`
`entry to the Resetting state from the Disabled state" and "both D+ and D- are
`
`high at [the time of speed valuation]," a hub "may stay in the Disabled state
`
`and set the C_PORT_ENABLE bit to indicate that the hub could not determine
`
`the speed of the device." USB 1.1 at 252. But often, the hub simply
`
`"assume[s] that the device is low speed" and sets the PORT_LOW_SPEED
`
`status accordingly. Id. Another possibility is "to do speed valuation on exit
`
`from the Resetting sate." Id.
`
`50. But it appears that TCT is of the view that with the port disabled,
`
`no reset is possible and the device can continue to draw power from the VBUS
`
`10928705
`
`
`- 24 -
`
`
`
`Fundamental Ex 2009-p 26
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`line. See, e.g., IPR2021-00395 at 22-23. Yet, if there is no detected
`
`communication or bus activity from the host or hub for a preset period of time
`
`(3 milliseconds), the attached device will enter into a suspend mode, during
`
`which mode, it can draw no more than 0.5 mA of current in a low-power mode
`
`and 2.5 mA of current in a high-power mode. USB 1.1 at 176-77; USB 2.0 at
`
`240-41. This amount of current does not provide sufficient power to charge a
`
`battery. The following diagram shows the ability to enter a Suspended state
`
`from any state where the device is powered. Id.
`
`
`
`10928705
`
`
`
`
`- 25 -
`
`
`
`Fundamental Ex 2009-p 27
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`III. Use of SE1 in Cited Prior Art
`51. As in earlier petitioners, TCT alleges that "a POSITA would have
`
`understood that the SE1 condition would be a logical choice for signaling
`
`information about a device without interfering with USB signaling because the
`
`SE1 is an abnormal condition outside the USB specification's teaching on USB
`
`communications." E.g., IPR2021-00395 Pet. 24; IPR2021-00410 Pet. 25-26.
`
`52. As before, I disagree with this conclusion. As TCT appears to
`
`acknowledge, SE1 is used when there is no USB communication and an SE1
`
`sent to a mobile device "would confirm and indicate that communication will
`
`not happen." E.g., IPR2021-00395 at 45. Disabling USB communication
`
`would be considered a severe interference with USB signaling.
`
`53. TCT's understanding of course comports with the USB
`
`specification's description that a USB hub disable the USB port when SE1
`
`signaling is observed to avoid "errors that are very difficult to isolate and
`
`correct":
`
`Each port is required to have a timer used for detecting disconnect
`when a full-/low-speed device is attached to the port. This timer is
`used to constantly monitor the port's single-ended receivers to
`detect a disconnect event. The reason for constant monitoring is
`that a noise event on the bus can cause the attached device to
`detect a reset condition on the bus after 2.5 µs of SE0 or SE1 on
`the bus. If the hub does not place the port in the disconnect state
`
`10928705
`
`
`- 26 -
`
`
`
`Fundamental Ex 2009-p 28
`TCT et al v Fundamental
`IPR2021-00395
`
`
`
`
`
`before the device resets, then the device can be at the Default
`Address state with the port enabled. This can cause errors that
`are very difficult to isolate and correct.
`
`USB 2.0 at 316, § 11.5.2.2.
`
`54. TCT cites Zyskowski and Kerai to argue that using SE1 "for
`
`charging a battery and no communication" was well-known. See, e.g.,
`
`IPR2021-00395 at 24-27, 46-47.
`
`55. Zyskowski has nothing to do with battery charging. Instead,
`
`Zyskowski is concerned with waking up a power supply, like a host computer,
`
`from its reduced state. Zyskowski, [0019]-[0020].
`
`56. Zyskowski does not disclose using or observing SE1 condition to
`
`determine whether the host computer is powered on (e.g., in a "full power
`
`state") or in standby mode ("reduced power state"). Id. Specifically,
`
`Zyskowski explains:
`
`On USB, device 106 may detect that the host 104 is in a reduced
`power state by monitoring the state of one or both of the data
`paths D1 and D2. When the host 104 is in a full power state, data
`lines D1 and D2 may be raised to a predefined DC voltage level,
`for example, 5 volts (systems operating at lower voltages might