Motorola Mobility, Inc. v. Microsoft Corporation

Filing 129

MOTION in Limine Nos. 1-9 and Brief in Support Thereof by Motorola Mobility, Inc.. (Attachments: #1 Affidavit, #2 Exhibit A to Affidavit in Support, #3 Exhibit B to Affidavit in Support, #4 Exhibit C to Affidavit in Support, #5 Exhibit D to Affidavit in Support, #6 Exhibit E to Affidavit in Support, #7 Exhibit F to Affidavit in Support, #8 Exhibit G to Affidavit in Support, #9 Exhibit H to Affidavit in Support, #10 Exhibit I to Affidavit in Support, #11 Exhibit J to Affidavit in Support, #12 Exhibit K to Affidavit in Support, #13 Exhibit L to Affidavit in Support, #14 Exhibit M to Affidavit in Support)(Mullins, Edward)

E
X
H
I
B
I
T
J

‘460 Patent Infringement Contentions
Motorola’s infringing products (“Accused Devices”) include mobile devices, such as
smartphones, associated software, and components thereof. The Accused Devices include
Motorola’s Android based phones which include, but are not limited to, the Motorola Droid X,
Droid 2, Droid 2 Global, Cliq 2, Defy, Bravo, Droid Pro, Droid 2 R2-D2, Droid X 2, Charm,
Droid, Flipside, Flipout, Atrix, Droid Bionic, Xoom, Devour A555, Backflip, Cliq/Dext, Cliq
XT/Quench, Citrus, Spice, i1 and other Motorola Android based phones incorporating hardware
and/or software that is substantially similar. The figures and illustrations in the infringement
chart below display exemplary devices.

U.S. Patent No. 7,383,460
(‘460 Patent)

Accused Devices

7. A system to configure a
Each Accused Device provides a system to configure a timer
timer in a computing device, in a computing device
the system comprising:
To the extent that this claim's preamble is construed as limiting,
the Motorola Droid X (hereinafter, "Droid X") is a "smartphone"
computing device that runs the Android operating system. (See
http://www.motorola.com/Consumers/US-EN/ConsumerProduct-and-Services/Mobile-Phones/ci.Motorola-DROID-X-USEN.alt, last visited April 12, 2011.) The Droid X operates to
configure a timer. By way of example, applications provided on
the Droid X use the Android MediaPlayer class. (See
http://developer.android.com/reference/android/media/MediaPlay
er.html, last visited April 12, 2011.) The Android MediaPlayer
configures a timer by use of the hrtimer component, which is
described in further detail below.
a timer substantially
guaranteed to expire at a
time certain;

Each Accused Device provides a timer substantially
guaranteed to expire at a time certain
By way of example, the Droid X includes a Texas Instruments
Open Multimedia Application Platform ("OMAP") processor.
(See http://news.cnet.com/8301-13924_3-20008725-64.html, last
visited April 12, 2011.) OMAP includes timers substantially
guaranteed to expire at a time certain. By way of example,
OMAP includes 11 general purpose timers, 2 watchdog timers,
and a synchronized timer. (See Texas Instruments Technical
1

U.S. Patent No. 7,383,460
(‘460 Patent)

Accused Devices
Reference Manual, OMAP36xx Multimedia Device, Silicon
Revision 1.x, Version Q, Public Version, at 2702) (available at
http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM
_vQ.zip, last visited April 12, 2011) ("OMAP documentation.")
These timers are registered with a high resolution hrtimer
component because they are substantially guaranteed to expire at
a time certain.
Other Accused Devices use other types of processors. By way of
example, some Accused Devices — such as the Motorola Xoom
— make use of an Nvidia Tegra processor. (See
http://developer.motorola.com/products/xoom/, last visited April
13, 2011.) Some Accused Devices — such as the Motorola Cliq
— make use of a Qualcomm processor. (See
http://developer.motorola.com/products/cliq/, last visited April
13, 2011.) Other Accused Devices — such as the Motorola i1 —
make use of a Freescale Zeus processor. (See
http://developer.motorola.com/products/i1/.)
The processors of all these devices include a timer which registers
with a high resolution hrtimer component and is substantially
guaranteed to expire at a time certain, as shown in further detail
below.

a hardware-independent
interface to the timer,

Each Accused Device provides a hardware-independent
interface to the timer
The Android operating system provides a hardware-independent
component called hrtimer. (See, e.g., kernel/hrtimer.c;
include/linux/hrtimer.h) The Android documentation references
the following block diagram and indicates that it illustrates
hrtimer:

2

U.S. Patent No. 7,383,460
(‘460 Patent)

Accused Devices

(See kernel/documentation/timers/highres.txt) (citing Thomas
Gleixner and Douglas Neihaus presentation, "hrtimers and
beyond – transformation of the Linux time(r) system," OLS 2006,
at slide 22, currently available at
http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/ols2
006-hrtimers.pdf, last visited April 12, 2011) (see also slides 15,
18, 20.) This figure depicts several hardware architectures on the
right-hand side that can interface with a common hrtimer
component, showing that hrtimer is hardware-independent. In
addition, as will be described in more detail below, hrtimer
includes program code that enables a variety of distinct types of
hardware-dependent components to register with the hrtimer
component, further showing that hrtimer is hardwareindependent.
The Accused Devices provide access to hrtimer through
hardware-independent interfaces to the timer. By way of
example, the Accused Devices provide timer access for
applications residing in the user mode through hardwareindependent interfaces such as nanosleep (see
bionic/libc/include/sys/linux-unistd.h; see also
include/linux/syscalls.h.) and setitimer (see
platform/bionic/libc/include/sys/linux-unistd.h; see also
include/linux/syscalls.h.) Likewise, the Accused Devices provide
timer access for applications residing in the kernel mode through
hrtimer routines such as hrtimer_start(), hrtimer_restart(),
hrtimer_start_expires(), and hrtimer_start_range_ns(). (See
kernel/hrtimer.c; include/linux/hrtimer.h.)
3

U.S. Patent No. 7,383,460
(‘460 Patent)

Accused Devices

The Android documentation indicates that applications residing in
the user mode or applications residing in the kernel mode use
these interfaces to set the timer: "[t]he primary users of precision
timers are user-space applications that utilize nanosleep, posixtimers and itimer interfaces. Also, in-kernel users like drivers and
subsystems which require precise timed events can benefit from
the availability of a separate high-resolution timer subsystem as
well." (See kernel/documentation/timers/hrtimers.txt.)
The manner by which applications interoperate with the hrtimer
component and by which the hrtimer component interoperates
with hardware-dependent components is described in more detail
below.
wherein the hardwareindependent interface is a
kernel mode routine having
a set interrupt timer
application programming
interface (API) for receiving
parameters associated with a
request from the application
to set the timer, and

In Each Accused Device, the hardware-independent interface
is a kernel mode routine having a set interrupt timer
application programming interface (API) for receiving
parameters associated with a request from the application to
set the timer
The Android documentation states that nanosleep, setitimer, and
hrtimer operate in the kernel mode. The hrtimer component is
implemented by program logic located in the file hrtimer.c, which
is a part of the Android operating system's kernel. (See
kernel/hrtimer.c.) The Android states that the hrtimer component
is currently used for "precise in-kernel timing." (See
kernel/hrtimer.c.) The Android documentation further states that
hrtimer provides "kernel logic" that works at a nanosecond-level
resolution and provides a simplification of "timing related kernel
code." (See kernel/documentation/hrtimers.txt.) The Android
documentation also states that "The hrtimer patch converts the
following kernel functionality to use hrtimers: nanosleep[,]
itimers[,] posix-timers[.]" (See
kernel/documentation/timers/hrtimers.txt.)
The hardware-independent interfaces have a set interrupt timer
API for receiving parameters associated with a request to set the
timer. The nanosleep routine receives such parameters from
applications residing in user mode, including a parameter
providing an indication of an expiry interval for the timer. (See
bionic/libc/include/sys/linux-unistd.h); (see also
include/linux/syscalls.h.) The setitimer routine, as another
4

U.S. Patent No. 7,383,460
(‘460 Patent)

Accused Devices
example, receives such parameters from applications residing in
user mode, including a parameter providing an indication of an
expiry interval for the timer. (See
platform/bionic/libc/include/sys/linux-unistd.h); (see also
include/linux/syscalls.h.)
Routines provided by the hrtimer component receive such
parameters from applications residing in kernel mode. For
example, hrtimer_start_expires (see include/linux/hrtimer.h) and
hrtimer_start_range_ns() (see kernel/hrtimer.c) receive
parameters associated with requests from nanosleep, including a
parameter providing an indication of an expiry interval. Also by
way of example, hrtimer_start (see kernel/hrtimer.c) and
hrtimer_restart (see include/linux/hrtimer.h) receive parameters
associated with requests from setitimer, including a parameter
providing an indication of an expiry interval.

validating the request,

Each Accused Device provides for validating the request
By way of example, a request passed to nanosleep is validated
using the timespec_valid function. (See kernel/hrtimer.c.)
By way of another example, a request passed to setitimer is
validated using the timeval_valid function. (See kernel/itimer.c.)
As yet another example, the hrtimer component validates requests
through program logic in the routine
clockevents_program_event(). This routine computes a delta
value based on the requested expiry time and performs
comparisons on delta in order to validate the requested expiry
interval. (See kernel/time/clockevents.c.)

wherein validating the
request includes validating
the parameters by the
hardware-independent
interface;

In each Accused Device, validating the request includes
validating the parameters by the hardware-independent
interface
Continuing with the examples discussed above, timespec_valid
(see kernel/hrtimer.c), timeval_valid (see kernel/itimer.c), and
clockevents_program_event() (kernel/time/clockevents.c) are all
hardware-independent. This program logic is used regardless of
the hardware timer that the hrtimer component interoperates with.

5

U.S. Patent No. 7,383,460
(‘460 Patent)
a hardware-dependent
interface to the timer;

Accused Devices
Each Accused Device provides a hardware-dependent
interface to the timer
The Android documentation references the following block
diagram and states that it illustrates the hrtimer component:

(See kernel/documentation/timers/highres.txt) (citing Thomas
Gleixner and Douglas Neihaus presentation, "hrtimers and
beyond – transformation of the Linux time(r) system," OLS 2006,
at slide 22, currently available at
http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/ols2
006-hrtimers.pdf, last visited March 30, 2011) (see also slides 15,
18, 20.) This figure depicts several hardware architectures on the
right-hand side and shows that each must interoperate with
hardware-dependent components.
The kernel directory /arch/ includes hardware-dependent
components of various types. Interfaces by which the hardwareindependent hrtimer component interoperates with hardwaredependent components will depend on the hardware being used.
By way of example, exemplary Accused Devices using a TI
OMAP processor (such as Droid X) include a hardwaredependent interface. (See, e.g., /arch/arm/mach-omap2/timergp.c.)
By way of another example, exemplary Accused Devices using an
Nvidia Tegra processor (such as Xoom) include a hardware6

U.S. Patent No. 7,383,460
(‘460 Patent)

Accused Devices
dependent interface. (See, e.g., arch/arm/kernel/smp_twd.c.)
By way of another example, exemplary Accused Devices using a
Qualcomm MSM processor (such as Cliq) include a hardwareindependent interface. (See, e.g., arch/arm/mach-msm/timer.c.)
Accused Devices using other processors (e.g., a Freescale Zeus
processor as used by i1) will likewise include a hardwaredependent interface.

and a processor in which the
hardware-independent
interface operates to validate
a request from an
application to set the timer

Each Accused Device provides a processor in which the
hardware-independent interface operates to validate a
request from an application to set the timer

and to relay the validated
request to the hardwaredependent process, and

Each Accused Device provides for relaying the validated
request to the hardware-dependent process

As discussed above, the Accused Devices include processors,
such as TI OMAP processors, Nvidia Tegra processors,
Qualcomm processors, and Freescale Zeus processors. These
processors execute the program logic described above to validate
a request from an application to set a timer.

Hardware-specific information is registered with hardwareindependent components using the data structure
clock_event_device. (See include/clockchips.h.) The
set_next_event member of that data structure provides an
indication of a hardware-dependent process to which the
hardware-independent component should relay the request. At
those times when it is appropriate to set the timer, the hardwareindependent hrtimer component will relay the request to the
hardware-dependent process.
By way of example, in exemplary Accused Devices using a TI
OMAP processor (such as Droid X) the request is relayed to the
hardware-dependent process omap2_gp_timer_set_next_event().
(See /arch/arm/mach-omap2/timer-gp.c.)
By way of another example, in exemplary Accused Devices using
an Nvidia Tegra processor (such as Motorola Xoom), the request
is relayed to the hardware-dependent process
twd_set_next_event(). (See arch/arm/kernel/smp_twd.c.)

7

U.S. Patent No. 7,383,460
(‘460 Patent)

Accused Devices
By way of another example, in exemplary Accused Devices using
a Qualcomm MSM processor (such as Cliq X), the request is
relayed to the hardware-dependent process
msm_timer_set_next_event(). (See arch/arm/mach-msm/timer.c.)
In Accused Devices using other processors (e.g., a Freescale Zeus
processor as used by i1), the request is likewise relayed to
hardware-dependent processes (e.g., clkev_set_next_event()).

further in which the
hardware-dependent
interface operates to set the
timer to expire in
accordance with the
validated request and

In each Accused Device, the hardware-dependent interface
operates to set the timer to expire in accordance with the
validated request
By way of example, in exemplary Accused Devices using a TI
OMAP processor (such as Droid X) the hardware-dependent
interface operates to set the timer through functionality set forth
in /arch/arm/mach-omap2/timer-gp.c and arm/platomap/dmtimer.c.
By way of example, in exemplary Accused Devices using a
Nvidia Tegra processor (such as Motorola Xoom) the hardwaredependent interface operates to set the timer through functionality
set forth in arch/arm/kernel/smp_twd.c and
arch/arm/include/asm/io.h.
By way of example, in exemplary Accused Devices using a
Qualcomm MSM processor (such as Cliq X) the hardwaredependent interface operates to set the timer through functionality
set forth in arch/arm/mach-msm/timer.c and
arch/arm/include/asm/io.h.
In Accused Devices using other processors (e.g., a Freescale Zeus
processor as used in i1), the hardware-dependent interface
likewise operates to set the timer.

to execute a timer interrupt
service routine upon
expiration of the timer.

Each Accused Device executes a timer interrupt service
routine upon expiration of the timer
Upon expiration of the timer, the Accused Devices execute a
timer interrupt service routine.
By way of example, in exemplary Accused Devices running a TI
8

U.S. Patent No. 7,383,460
(‘460 Patent)

Accused Devices
OMAP processor (such as the Droid X), handlers process the
interrupt generated by the timer as to invoke the
hrtimer_interrupt() service routine (see kernel/hrtimer.c) via a
call to omap2_gp_timer_interrupt() (see /arch/arm/machomap2/timer-gp.c.)
Exemplary Accused Devices running an Nvidia Tegra processor,
Qualcomm MSM processor, or other processors (e.g., a Freescale
Zeus processor) similarly handle the interrupt generated by the
timer as to invoke the hrtimer_interrupt() service routine.

8. The system of claim 7,
wherein the timer is a high
precision event timer
(HPET).

In each Accused Device, the timer is a high precision event
timer

9. The system of claim 8,
wherein the hardwaredependent interface operates
to set the timer by writing
an actual time at which the
HPET should expire to a
comparator register
associated with the HPET,
the actual [time] being
determined by the hardwaredependent interface in
accordance with the
validated request.

In each Accused Device, the hardware-dependent interface
operates to set the timer by writing an actual time at which
the HPET should expire to a comparator register associated
with the HPET, the actual tune being determined by the
hardware-dependent interface in accordance with the
validated request

The Accused Devices use timers that are high resolution timers
and that interoperate with the high resolution hrtimer component,
as discussed above. The timers operate at a nanosecond-based
resolution. (See kernel/documentation/timers/hrtimers.txt.)

In the Accused Devices, the hardware-dependent interface
operates to set the timer by writing an actual time at which the
timer should expire to a register associated with the timer. The
actual time is determined by functions in the hardware-dependent
interface. Specifically, the hrtimer component adds the expiry
interval specified by the application to a value representing the
current time. (See, e.g., ktime_add_safe()in
__hrtimer_start_range_ns in kernel/hrtimer.c.) The resulting
value is passed to hardware-dependent components, which
convert it from nanosecond-based units into units representing the
actual clock cycle value at which the timer should expire.
By way of example, exemplary Accused Devices running a TI
OMAP processor (such as Droid X) covert the value into units
representing the actual clock cycle value. (See, e.g., kernel/timergp.c and arch/arm/plat-omap/dmtimer.c.)

9

U.S. Patent No. 7,383,460
(‘460 Patent)

Accused Devices
By way of another example, exemplary Accused Devices running
an Nvidia Tegra processor (such as Motorola Xoom) covert the
value into units representing the actual clock cycle value. (See,
e.g., arch/arm/kernel/smp_twd.c and arch/arm/include/asm/io.h.)
By way of another example, exemplary Accused Devices running
a Qualcomm MSM processor (such as Cliq X) convert the value
into units representing the actual clock cycle value. (See, e.g.,
arch/arm/mach-msm/timer.c and arch/arm/include/asm/io.h.)
Exemplary Accused Devices using other processors (e.g., a
Freescale Zeus processor) likewise convert the value into units
representing the actual clock cycle value.
The time at which the timer should expire is written to a
comparator register. By way of example, according to the OMAP
documentation, GP timers can operate in "compare mode."
"When the compare enable register GPTi.TCLR[6] CE bit is set
to 1, the timer value (GPTi.TCRR[31:0] TIMER_COUNTER
field) is continuously compared to the value held in the timer
match register (GPTi.TMAR). The GPTi.TMAR[31:0]
COMPARE_VALUE value can be loaded at any time (timer
counting or stopped). When the GPTi.TCRR and the
GPTi.TMAR values match, an interrupt is issued, if the
GPTi.TIER[0] MAT_IT_ENA bit is set." (OMAP documentation
at 2718.)

10. The system of claim 7,
wherein the parameters
specify an interval
representing a period of
time after which the
hardware interrupt timer is
requested to expire, and
wherein the processor
operates to validate the
request by determining that
the interval is of
substantially sufficient
duration to set the timer.

In each Accused Device, the parameters specify an interval
representing a period of time after which the hardware
interrupt timer is requested to expire, and wherein the
processor operates to validate the request by determining that
the interval is of substantially sufficient duration to set the
timer
By way of example, the rqtp parameter passed into nanosleep
specifies an interval representing a period of time after which the
hardware interrupt timer is requested to expire. (See
bionic/libc/include/sys/linux-unistd.h); (see also
include/linux/syscalls.h.) Also by way of example, the itimerval
parameter passed into setitimer includes the it_value parameter
which specifies an interval representing a period of time after
which the hardware interrupt timer is requested to expire. (See
platform/bionic/libc/include/sys/linux-unistd.h); (see also
10

U.S. Patent No. 7,383,460
(‘460 Patent)

Accused Devices
include/linux/syscalls.h.)
The parameters passed into routines provided by the hrtimer
component also include a representation of a period of time after
which the hardware interrupt timer is requested to expire. (See,
e.g., timer and mode parameter passed into
hrtimer_start_expires(); timer, tim, and mode parameters passed
into hrtimer_start_range_ns(); and the timer, tim, and mode
parameters passed into hrtimer_start(). (See kernel/hrtimer.c;
include/linux/hrtimer.h.)
The Accused Devices' processors operate to validate the request
by determining that the interval is of substantially sufficient
duration to set the timer.
By way of example, the timespec_valid function determines that
the expiry interval is of substantially sufficient duration. (See
kernel/hrtimer.c.)
By way of another example, the timeval_valid function
determines whether the expiry interval is of substantially
sufficient duration. (See kernel/itimer.c.)
By way of further example, clockevents_program_event() checks
that the expiry interval is of substantially sufficient duration by
computing a delta value based in part on the requested expiry
time and checking that the delta value is greater than 0. This
function further checks that the interval is of substantially
sufficient duration by checking that delta is greater than a
constant min_delta_ns. (See kernel/time/clockevents.c.)

11. The system of claim 7,
wherein the parameters
specify a mode in which the
timer is requested to
operate, and wherein the
processor operates to
validate the request by
determining that the mode is
one of periodic and
aperiodic.

In each Accused Device, the parameters specify a mode in
which the timer is requested to operate, and the processor
operates to validate the request by determining that the mode
is one of periodic and aperiodic
By way of example, the setitimer routine accepts the parameter
itimerval *value, which includes the parameters timeval it_value
and timeval it_interval. (See
platform/bionic/libc/include/sys/linux-unistd.h;
include/linux/syscalls.h.) These parameters specify that the mode
is one of periodic and aperiodic based on whether the it_interval
parameter is greater than 0. If it_interval is greater than 0, the
11

U.S. Patent No. 7,383,460
(‘460 Patent)

Accused Devices
processor determines that the mode is periodic. If it_interval is 0,
the processor determines that the mode is aperiodic. (See
kernel/itimer.c; kernel/hrtimer.c.)

12. The system of claim 7,
wherein the hardwaredependent interface is a
hardware application layer
(HAL) routine having an
interface to receive the
validated parameters
associated with the request
relayed from the hardwareindependent interface.

13. The system of claim 7,
wherein the hardwaredependent interface further
operates to execute an
application service routine
upon expiration of the timer.

In each Accused Device, the hardware-dependent interface is
a hardware application layer (HAL) routine having an
interface to receive the validated parameters associated with
the request relayed from the hardware-independent interface
As described above, the clock_event_device() data structure
includes a member set_next_event that provides an indication of a
hardware-dependent process to which the hardware-independent
component should relay the request. The hardware-dependent
processes identified above serve as hardware application layers.
They further receive as arguments indications of a validated
expiry time associated with the request relayed from the hrtimer
component. By way of example,
omap2_gp_timer_set_next_event() receives the validated
parameter cycles. (See /arch/arm/mach-omap2/timer-gp.c.) By
way of another example, twd_set_next_event() receives the
validated parameter evt. (See arch/arm/kernel/smp_twd.c.) By
way of another example, msm_timer_set_next_event() receives
the validated parameter cycles. (See arch/arm/machmsm/timer.c.) Likewise, Accused Devices using other processors,
such as a Freescale Zeus processor, will include a hardwaredependent interface to receive validated parameters associated
with the request related from the hardware-independent interface.
In each Accused Device, the hardware-dependent interface
further operates to execute an application service routine
upon expiration of the timer
The hardware-dependent components operate to execute an
application service routine upon expiration of the timer. As
discussed above, the Accused Devices handle the interrupt
generated by the timer as to invoke hrtimer_interrupt().
Hrtimer_interrupt() invokes __run_hrtimer which references the
function member of an hrtimer structure. The function member
provides an indication of the application service routine that
should be executed upon expiration of the timer. (See
kernel/hrtimer.c.)

12
CH1 5832221v.1