throbber
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-00428
`Patent No. 8,624,550
`___________________
`
`DECLARATION OF DR. KENNETH FERNALD IN SUPPORT OF
`PATENT OWNER'S RESPONSE
`
`10928705
`
`Fundamental Ex 2009-p 1
`TCT et al v Fundamental
`IPR2021-00428
`
`

`

`TABLE OF CONTENTS
`
`I. 
`II. 
`
`Page
`Introduction ............................................................................................ 1 
`Technology Background ........................................................................ 5 
`A.  USB Topology ............................................................................. 5 
`B. 
`USB Hub ...................................................................................... 6 
`C. 
`Device States and Enumeration ................................................. 14 
`D. 
`Speed Detection ......................................................................... 23 
`III.  Use of SE1 in Cited Prior Art ............................................................... 26 
`IV.  The '550 Inventions .............................................................................. 33 
`V. 
`Level And Knowledge Of Skill In The Art .......................................... 35 
`VI.  Use of SE1 in Morita's System ............................................................. 37 
`A.  Morita ......................................................................................... 37 
`B. 
`TCT's modification would disable the USB-hub
`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-00428
`
`

`

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

`

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

`

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

`

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

`

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

`

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

`

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

`

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

`

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

`

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

`

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

`

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

`

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

`

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

`

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

`

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

`

`
`
`
`
`10928705
`
`
`- 17 -
`
`
`
`Fundamental Ex 2009-p 19
`TCT et al v Fundamental
`IPR2021-00428
`
`

`

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

`

`
`
`"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-00428
`
`

`

`
`
`10928705
`
`
`- 20 -
`
`
`
`
`
`
`
`Fundamental Ex 2009-p 22
`TCT et al v Fundamental
`IPR2021-00428
`
`

`

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

`

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

`

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

`

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

`

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

`

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

`

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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket