Unified Patents Inc. v. Silver State Intellectual Technologies Inc., IPR2017-01531 (PTAB June 7, 2017)

Petition for Inter Partes Review, IPR2017-01531
U.S. Patent No. 7,650,234

Filed on behalf of Unified Patents Inc.
By: Ashraf A. Fawzy, Reg. 67,914
Jonathan Stroud, Reg. 72,518
Unified Patents Inc.
1875 Connecticut Ave. NW, Floor 10
Washington, DC, 20009
Tel: (202) 871-0110
Email: afawzy@unifiedpatents.com
Email: jonathan@unifiedpatents.com
UNITED STATES PATENT AND TRADEMARK OFFICE
____________________________
BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________________________
UNIFIED PATENTS INC.

Petitioner
v.
SILVER STATE INTELLECTUAL TECHNOLOGIES, INC.

Patent Owner
____________________________
Case IPR2017-01531
Patent 7,650,234
____________________________
PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 7,650,234

TABLE OF CONTENTS
I. Introduction ....................................................................................................... 1
II. Mandatory Notices Under 37 C.F.R. 42.8 ..................................................... 1
III. Payment of Fees Under 37 C.F.R. 42.15(a) and 42.103 .......................... 3
IV. Grounds for Standing .................................................................................... 3
V. Identification of Challenge and Relief Requested ............................................ 3
A. Claims for Which Review Is Requested ....................................................... 3
B. Statutory Grounds of Challenge .................................................................... 3
C. The Proposed Grounds Are Not Redundant ................................................. 5
VI. Background and Overview of the 234 Patent .............................................. 7
VII. Claim Construction ....................................................................................... 9
A. searching the database ............................................................................. 10
B. navigation coverage ................................................................................. 11
C. coverage area ........................................................................................... 12
D. Means-Plus-Function Claim Terms ............................................................ 13
VIII. Detailed Explanation of Grounds for Unpatentability ................................ 16
A. Ground 1: Xu Anticipates Claims 1-7, 9-15, 17-21, 23-28, and 30 ............ 16
1. Claim 1 .................................................................................................... 16
2. Claim 2 .................................................................................................... 26
3. Claim 3 .................................................................................................... 28
4. Claim 4 .................................................................................................... 28
5. Claim 5 .................................................................................................... 29
6. Claim 6 .................................................................................................... 30
7. Claim 7 .................................................................................................... 31
8. Claim 9 .................................................................................................... 32
9. Claim 10 .................................................................................................. 35
10. Claim 11 .............................................................................................. 35
11. Claim 12 .............................................................................................. 35
12. Claim 13 .............................................................................................. 35
13. Claim 14 .............................................................................................. 36
14. Claim 15 .............................................................................................. 36
15. Claim 17 .............................................................................................. 36
16. Claim 18 .............................................................................................. 40
17. Claim 19 .............................................................................................. 40
18. Claim 20 .............................................................................................. 40
19. Claim 21 .............................................................................................. 41
i
20. Claim 23 .............................................................................................. 41
21. Claim 24 .............................................................................................. 41
22. Claim 25 .............................................................................................. 43
23. Claim 26 .............................................................................................. 43
24. Claim 27 .............................................................................................. 44
25. Claim 28 .............................................................................................. 44
26. Claim 30 .............................................................................................. 44
B. Ground 2: Xu and Trovato Render Claims 8, 16, 22, and 29 Obvious ...... 44
1. Claims 8 and 16 ...................................................................................... 44
2. Claims 22 and 29 .................................................................................... 47
C. Ground 3: Xu and Golding Render Claims 1-7, 9-15, 17-21, 23-28, and 30
Obvious ............................................................................................................... 48
D. Ground 4: Xu, Golding, and Trovato Render Claims 8, 16, 22, and 29
Obvious ............................................................................................................... 53
IX. Conclusion .................................................................................................. 54
ii
TABLE OF AUTHORITIES
Cases
Brose N. Am., Inc. v. Uusi, LLC,

IPR2014-00417, Paper No. 49 (July 20, 2015) .................................................. 14
Ex parte Erol,
No. 2011-001143, 2013 WL 1341107 (PTAB Mar. 11, 2013) ........................... 14
Ex parte Lakkala,
No. 2011-001526, 2013 WL 1341108 (PTAB Mar. 11, 2013) ........................... 14
Ex parte Smith,
No. 2012-007631, 2013 WL 1341109 (PTAB Mar. 12, 2013)........................... 14
KSR Intl Co. v. Teleflex, Inc.,

550 U.S. 398 (2007) ...................................................................................... 47, 53
Williamson v. Citrix Online, LLC,

No. 2013-1130, 2015 U.S. App. LEXIS 10082 (Fed. Cir. June 16, 2015) ......... 14
Statutes
35 U.S.C. 102(a) .................................................................................................... 4
35 U.S.C. 102(e) .................................................................................................... 4
35 U.S.C. 103(a) .................................................................................................... 4
Regulations
37 C.F.R. 42.8 ........................................................................................................ 1
37 C.F.R. 42.15 ...................................................................................................... 3
37 C.F.R. 42.104 .............................................................................................. 3, 13
37 C.F.R. 42.103 .................................................................................................... 3
37 C.F.R. 42.100 .................................................................................................... 9
iii
LIST OF EXHIBITS
1001 U.S. Patent No. 7,650,234 (the 234 patent)
1002 File History of the 234 Patent
1003 Assignment of the 234 Patent
1004 U.S. Patent No. 6,401,027 to Xu et al. (Xu)
1005 U.S. Patent No. 5,835,881 to Trovato et al. (Trovato)
1006 U.S. Patent No. 5,933,100 to Golding (Golding)
1007 Order in Silver State Intellectual Techs, Inc. v. Garmin Intl Inc., 2:11-
cv-1578 (Nev. Aug. 13, 2013)
1008 Declaration of Dr. William R. Michalson, Ph.D. (Aug. 14, 2015)
1009 UK Patent Application GB 2079453 A
1010 Wootton et al., The Experience of Developing and Providing Driver

Route Information Systems, IEEE 1989 Vehicle Navigation and
Information Systems Conference, pp. 71-75
1011 Saito et al., Automobile Navigation System Using Beacon

Information, IEEE 1989 Vehicle Navigation and Information Systems
Conference, pp. 139-145
1012 Second Declaration of William R. Michalson, Ph.D. (June 5, 2017)
1013 Petitioners Voluntary Interrogatory Responses
iv
P

I. INTRODUCTION
Unified Patents Inc. (Petitioner) requests inter partes review of claims 1-30
of U.S. Patent No. 7,650,234 (the 234 patent) (Ex. 1001) assigned on its face to
American Calcar, Inc., but reassigned to Silver State Intellectual Technologies, Inc.
(Patent Owner). (See Ex. 1003). This Petition shows that there is a reasonable
likelihood that Petitioner will prevail on claims 1-30 of the 234 patent based on
prior art that the Office did not have before it during original prosecution. This
Petition also shows by a preponderance of the evidence that the prior art anticipates
and renders obvious claims 1-30 of the 234 patent. Claims 1-30 of the 234 patent
should be found unpatentable and cancelled.
The 234 patent was also the subject of an inter partes review petition filed
on August 17, 2015: Google Inc. v. Silver State Intellectual Technologies, Inc.,
IPR2015-01738. Prior to a decision on institution, the parties filed a joint motion to
terminate in view of settlement, which was granted. This petition is substantively
similar to that earlier-filed petition. Further, this petition relies on a second
declaration from Dr. William R. Michalson, Ph.D. (Ex. 1012) that reaffirms and
swears that he supports his earlier-filed declaration (Ex. 1008) in IPR2015-01738.
II. MANDATORY NOTICES UNDER 37 C.F.R. 42.8
Real Party-in-Interest: Pursuant to 37 C.F.R. 42.8(b)(1), Petitioner certifies
that Unified Patents Inc. is the real party-in-interest, and further certifies that no other
1
P

information is Unified Patents Inc., 1875 Connecticut Ave. NW, Floor 10,
Washington, D.C. 20009, Telephone: 202-871-0110, E-mail:
afawzy@unifiedpatents.com and jonathan@unifiedpatents.com. Petitioner consents
to electronic service.
III. PAYMENT OF FEES UNDER 37 C.F.R. 42.15(a) AND 42.103
Petitioner submits the required fees with this Petition. Please charge any
additional fees required during this proceeding to Deposit Account No. 50-6990.
IV. GROUNDS FOR STANDING
Petitioner certifies that, under 37 C.F.R. 42.104(a), the 234 patent is
available for inter partes review, and that Petitioner is not barred or estopped from
requesting inter partes review of the 234 patent on the grounds identified.
V. IDENTIFICATION OF CHALLENGE AND RELIEF REQUESTED
A. Claims for Which Review Is Requested
Petitioner respectfully requests review of claims 1-30 of the 234 patent, and
cancellation of these claims as unpatentable.
B. Statutory Grounds of Challenge
Claims 1-30 should be cancelled as unpatentable in view of the following prior
art1:
1
For purposes of this Petition, Petitioner has assumed that the 234 patent is entitled
to a priority date of October 19, 1999.
3
P

Reference 1: U.S. Patent No. 6,401,027 to Xu et al. (Xu) (Ex. 1004) was
filed on May 24, 1999, and is prior art to the 234 patent at least under pre-AIA 35
U.S.C. 102(e).
Reference 2: U.S. Patent No. 5,835,881 to Trovato et al. (Trovato) (Ex.
1005) was filed on January 16, 1996 and issued on November 10, 1998, and is prior
art to the 234 patent at least under pre-AIA 35 U.S.C. 102(a) and (e).
Reference 3: U.S. Patent No. 5,933,100 to Golding (Golding) (Ex. 1006)
was filed on December 27, 1995 and issued on August 3, 1999, and is prior art to the
234 patent at least under pre-AIA 35 U.S.C. 102(a) and (e).
Claims 1-30 of the 234 patent should be cancelled as unpatentable on the
following grounds:
Ground 1: Claims 1-7, 9-15, 17-21, 23-28, and 30 are invalid under 35 U.S.C.
102(e) in view of Xu.
Ground 2: Claims 8, 16, 22, and 29 are invalid under 35 U.S.C. 103(a)
based on Xu in view of Trovato.
Ground 3: Claim 1-7, 9-15, 17-21, 23-28, and 30 are invalid under 35 U.S.C.
103(a) based on Xu in view of Golding.
Ground 4: Claims 8, 16, 22, and 29 are invalid under 35 U.S.C. 103(a)
based on Xu in view of Golding and Trovato.
4
P

C. The Proposed Grounds Are Not Redundant
Petitioners proposed grounds for institution are not redundant because there
are several significant differences between the grounds. For example, whereas
Ground 1 relies on anticipation, Ground 3 relies on obviousness. Therefore, different
defenses may be available to the Patent Owner during the course of this proceeding
for each Ground.
In addition, Ground 1 addresses the claims in a different way than Ground 3.
For example, in Ground 1, Xu addresses the claimed searching the database
limitations, as recited in independent claims 1, 9, 17, and 24, because of its block
flagging operations performed at a client-side in-vehicle device. (See infra Parts
VIII.A.1.f, VIII.A.8.f, VIII.A.15.e, VIII.A.21.e.) On the other hand, Ground 3 relies
on a disclosure in Golding that renders obvious performing the claimed searching
the database limitations at a database, remote from the clients device. (See infra
Part VIII.C.) Thus, in one way, the strength of Ground 1 is that it addresses the
searching the database limitations to the extent such searching features are
interpreted in a way that includes searching the database client-side or the like. On
the other hand, the strength of Ground 3 is that it addresses the searching the
database limitations to the extent such searching features are interpreted in a way
that includes searching the database database-side.
The differences in the strengths of the prior art identified in these grounds
5
P

warrant institution of both grounds given that finding redundancy in the grounds
may detrimentally affect Petitioners ability to demonstrate the unpatentability of the
claims. For instance, should the Board institute inter partes review based on an
initial interpretation of the searching the database limitations that include client-
side type operations and thus decline to institute Ground 3, but then later changes its
construction to preclude such features, Petitioner may not be able to demonstrate
fully why non-client-side type searching would have been obvious as presented in
Ground 3. The same situation arises should the Board decline to institute review on
Ground 1 as being redundant to Ground 3. Adopting both grounds will allow the
Board to consider positions from both Patent Owner and Petitioner after institution
regarding how the prior art discloses the searching the database limitations.2
Ground 2 stems from the rejections in Ground 1, and Ground 4 stems from
the rejections in Ground 3. Therefore, Grounds 2 and 4 are not redundant for the
same reasons set forth for Grounds 1 and 3. For at least these reasons, Petitioner
respectfully requests the Board adopt all proposed Grounds.
2
Indeed, Patent Owner may reserve positions from a Preliminary Response that the
Board may not see until after any institution that may have bearing on the prior art
and the interpretation of the searching the database limitations.
6
P

VI. BACKGROUND AND OVERVIEW OF THE 234 PATENT
The 234 patent issued from U.S. Application No. 11/971,193 (the 193
application) and is directed to a navigation device [that] utilizes stored user
profiles to navigate a user who may be driving in a vehicle, on foot, or in other mode
of transportation. (Ex. 1001 at Abstract.)
The 234 patent discloses that a system that includes a navigator arrangement
100 that may be docked or connected to another device or system to enhance its
functionality, which may include a terminal, workstation, computer system, or an
automobile system. (Id., 3:29-33.) The navigator arrangement 100 includes
processor 103, memory 108, display driver 111, display 113, user interface 115,
external interfaces 117, GPS receiver 119, communication unit 120. (Id., 3:36-39.)
To the extent possible, databases in arrangement 100 are pre- populated with data.
(Id., 4:30-32.) However, arrangement 100 allows for downloading of data from a
remote source to supplement and update the databases in arrangement 100, and to
provide thereto just-in-time information, including, e.g., latest traffic, weather, map
and other information. (Id., 4:33-37.)
The 234 patent discloses a NAVIGATE option 657 for navigation by
arrangement 100. (Id., 9:56-57.) The NAVIGATE option provides the user with an
interface to enter an origination and destination address, with the users current
location being the default origination: the user adopts the default response to query
7
P

903 which is the location identified by the GPS data in section 511 of record 400.
Otherwise, the user may enter a different origination address. The user is also
prompted to enter a destination address at query 905. (Id., 10:5-10.) After learning
the origination address and destination address . . . processor 103 determines
whether a geographic area called the navigation coverage includes the
origination and destination addresses, and whether the stored map and related
information is fresh. (Id., 10:27-34.) If the navigation coverage includes the
origination and destination addresses in question . . . processor 103 at step 1006
selects the route from the origination address to the destination address which is the
most time-efficient, i.e., fastest by automobile in this instance, taking into account
the relevant weather, traffic, and road conditions along the selected route, together
with any roadblocks set up by the user in a manner to be described. (Id., 10:35-46.)
Otherwise, if the navigation coverage area does not cover the origination and/or
destination address in question, and/or if the map and related information is not
fresh, processor 103 . . . establishes a communication connection to navigation server
630 [and] causes a transmission of a request for fresh map and related information
for an appropriate navigation coverage through the established connection. (Id.,
10:55-61.) (See also Ex. 1008, 16-24 (discussing Exs. 1009, 1010, 1011).)
Only one office action issued during prosecution of the 193 application, and
that office action only noted that the applications abstract was improper. (Ex. 1002
8
P

at 61-65.) The office action did not include a single prior art rejection, and in fact
did not cite a single prior art reference. (Id.) The only prior art explicitly considered
during prosecution of the 193 application was prior art that the applicant made of
record. (Id., 67-77.) None of the references relied upon for grounds in this Petition
were ever considered during prosecution of the 193 application. (See Ex. 1001 at
References Cited.)
VII. CLAIM CONSTRUCTION
A claim subject to inter partes review receives the broadest reasonable
construction in light of the specification of the patent in which it appears.
37 C.F.R. 42.100(b). Throughout this Petition, as required by the rules governing
it, Petitioner applies the broadest reasonable interpretation (BRI) of claim terms
appropriate for these proceedings, including claim terms for which a claim
construction is not explicitly discussed. Claim constructions appropriate for these
proceedings may be different than claim constructions appropriate in a federal
district court. Thus, claim constructions relied upon in this Petition do not
necessarily reflect the claim constructions that Petitioner believes should be adopted
by a district court. Any term not construed below should be interpreted in accordance
with its plain and ordinary meaning under the broadest reasonable construction.
Petitioner applies this understanding in its analysis of the claims of the 234 patent.
9
P

A. searching the database
Claims 1, 9, 17, and 24 recite the phrase searching the database. (Ex. 1001
at 13:65-67, 14:6-7, 14:35-37, 15:1-3, 15:8-10, 16:3-5 and 16:10-12.) For purposes
of this proceeding, searching the database should be construed as analyzing data
from the database. This understanding is consistent with the claims and
specification of the 234 patent. The 234 patent does not define or even use the term
searching anywhere in its specification. However, the 234 patent does disclose a
scenario in which a server analyzes data from a database (Ex. 1001 at 8:26-55), and
a scenario in which data is transmitted from a database of a server to a processor of
a navigator arrangement and then the data from the database is analyzed at the
navigator arrangement (id., 10:27-11:14). The common factor in both scenarios is
that data from a database is analyzed. Thus, the broadest reasonable interpretation
of the term should reflect the same. This understanding is consistent with the
language of the claims. Claims 1, 9, 17, and 24 do not place any explicit limits on
how or where the searching the database feature is performed. Interpreting the
term as noted above is thus consistent with how the term is used in the specification
and the claims. This understanding is also consistent with how one of ordinary skill
in the art would have understood searching the database in the context of the 234
10
P

3
patent. (See also Ex. 1008 at 26.)
B. navigation coverage
Claims 1, 9, 17, and 24 recite the phrase navigation coverage. (Ex. 1001 at
14:4, 14:41, 15:7, 16:9.) For purposes of this proceeding, navigation coverage
should be construed as the geographic area over which the navigation system
operates. The 234 patent repeatedly refers to a navigation coverage as being a
geographic area over which the navigation system operates. For example, the 234
patent describes a scenario in which processor 103 determines whether the
navigation coverage based on the map layer corresponding to automobile
travelincludes the origination and destination addresses in question. (Ex. 1001 at
10:30-35 (emphasis added).) If so, processor 103selects [a] route from the
origination address to the destination address. (Id., 10:35-42.) However, if the
stored mapdoes not cover the origination and/or destination address in
questionprocessor 103 causes a transmission of a request for fresh map and related
information for an appropriate navigation coverage. (Id., 10:55-62 (emphasis
3
A person of ordinary skill in the art would have been an engineer having at least a
bachelors degree in electrical engineering, computer science, or a degree in a related
field, with approximately two or more years of experience in the design and
implementation of navigation systems and/or routing. (Ex. 1008 at 15.)
11
P

added).) In other words, in the 234 patent, maps associated with an appropriate
navigation coverage are selected to conform to the geographic area over which the
navigation system operates. This understanding of the term navigation coverage
is consistent with a district courts claim construction during litigation involving the
234 patent. (Ex. 1007 at 33.) This understanding is also consistent with how one of
ordinary skill in the art would have understood navigation coverage in the context
of the 234 patent. (See also Ex. 1008 at 27.)
C. coverage area
Claims 1, 9, 17, and 24 recite the phrase coverage area. (Ex. 1001 at 13:66,
14:3, 14:36, 14:40, 15:2, 15:6, 16:4, 16:8.) For purposes of this proceeding,
coverage area should be construed as the geographic area that the vehicle is
located in, which is a subset of the geographic area over which the navigation system
operates. The term coverage area does not appear in the specification of the 234
patent. However, in the context of claims 1, 9, 17, and 24, coverage area is a subset
of the navigation coverage, which is addressed above. For example, claim 1 refers
to a coverage area including the location of the navigation device. (Id., 13:65-67.)
Claim 1 also characterizes a scenario in which the coverage area is different from
one or more areas in navigation coverage defined by the origination and destination,
suggesting that the coverage area is a subset of the overall navigation coverage.
(Id., 14:3-5.) Claims 9, 17, and 24 characterize the coverage area in substantively
12
P

the same manner. This understanding of the term coverage area is consistent with
a district courts claim construction during litigation involving the 234 patent. (Ex.
1007 at 33-34.) This understanding is also consistent with how one of ordinary skill
in the art would have understood coverage area in the context of the 234 patent.
(See also Ex. 1008 at 28.)
D. Means-Plus-Function Claim Terms
The 234 patent includes means-plus-function claim terms. As required by 37
C.F.R. 42.104(b)(3), to the extent disclosed, Petitioner identifies portions of the
234 patent that describe corresponding structure for the recited functions.
Claim 17 recites a processing unit for searching the database for traffic
information specific to a coverage area including the location of the vehicle. (Ex.
1001 at 15:1-3.) Similarly, claim 24 recites a processing unit for searching the
database for weather information specific to a coverage area including the location
of the vehicle. (Id., 16:3-5.) For purposes of this proceeding, both processing unit
for searching the database . . . terms should be interpreted as means-plus- function
terms.
When a claim term lacks the word means, the presumption [that 112,
para. 6 does not apply] can be overcome and 112, para. 6 will apply if the
challenger demonstrates that the claim term fails to recite sufficiently definite
structure or else recites function without reciting sufficient structure for performing
13
P

that function. Williamson v. Citrix Online, LLC, No. 2013-1130, 2015 U.S. App.
LEXIS 10082 at *16 (Fed. Cir. June 16, 2015) (citing Watts v. XL Sys., 232 F.3d
877, 880 (Fed. Cir. 2000)). Claim 17 does not define any structure associated with a
processing unit or its function of searching the database for traffic information
specific to a coverage area including the location of the vehicle. Similarly, claim
24 does not define structure associated with a processing unit or its function of
searching the database for weather information specific to a coverage area
including the location of the vehicle. Moreover, a processing unit is a term that
does not in itself suggest any particular structure. See, e.g., Brose N. Am., Inc. v.
Uusi, LLC, IPR2014-00417, Paper No. 49 at 12 (July 20, 2015) (explaining that unit
for is a non-structural generic placeholder[] that may invoke 112, para. 6); see
also Nintendo of America Inc. v. Motion Games, LLC, IPR2014-00164, Paper No.
12 at 6 (May 19, 2014) (finding a processing means limitation to invoke means-
plus-function). Indeed, in March 2013, a five-judge PTAB panel issued three
decisions, all holding that processor invokes means-plus-function because
processor fails to connote a sufficiently definite structure. Ex parte Erol, No.
2011-001143, 2013 WL 1341107, at *8-9 (PTAB Mar. 11, 2013); Ex parte Lakkala,
No. 2011-001526, 2013 WL 1341108, at * 6-7 (PTAB Mar. 11, 2013); Ex parte
Smith, No. 2012-007631, 2013 WL 1341109, at *7-8 (PTAB Mar. 12, 2013).
Therefore, a processing unit for searching the database . . ., as recited in claims 17
14
P

and 24, should be interpreted under 112, para. 6.
The identified function of the processing unit in claim 17 is searching the
database for traffic information specific to a coverage area including the location of
the vehicle, and the identified function of the processing unit in claim 24 is
searching the database for weather information specific to a coverage area including
the location of the vehicle. (Ex. 1001 at 15:1-3, 16:3-5.)4 The 234 patent discloses
a remote server or a processor of a navigation device called a navigator
arrangement (id., 8:26-55, 10:27-11:14) performs the identified functions of
searching the database (i.e., analyzing data from the database). (See also supra Part
VII.A.) Thus, for purposes of this proceeding, the corresponding structure for the
identified function of searching the database for traffic information specific to a
coverage area including the location of the vehicle, and the identified function of
searching the database for weather information specific to a coverage area including
the location of the vehicle, is a server, a processor of a navigation device, or
equivalents thereof.
4
As discussed above in Part VII.A, searching the database in the context of the
234 patent means analyzing data from the database. (See supra Part VII.A.)
15
P

VIII. DETAILED EXPLANATION OF GROUNDS FOR
UNPATENTABILITY
A. Ground 1: Xu Anticipates Claims 1-7, 9-15, 17-21, 23-28, and 30
1. Claim 1
a) A method for navigation using a navigation device which

includes a location-sensing element therein, the method
comprising:
To the extent the preamble is construed to be limiting, Xu discloses this
limitation. For example, Xu discloses a traffic data remote collection and intelligent
vehicle highway system that performs a method for navigation. (Ex. 1004 at 6:26-
28.) Figure 1 illustrates one example of the system.
16
P

(Id., 6:26-28, Fig. 1.) The system includes a group of vehicles 20 [that] travel a
roadway system 10, wherein [e]ach vehicle 20 is equipped with an in-vehicle
device 21. (Id., 6:28-32.) The in-vehicle device 21 has a vehicle support sub-
system 30, which includes a road network locator 32 (hereinafter locator 32) and
a road explorer 34Also included in the in-vehicle device 21 are a computer system
26 for operating the sub-systems and storing the digitized road network map. (Id.,
7:21-28, Fig. 2.) The locator 32 computes the geographical location of the
vehicle, using data received from the GPS receiver 22, and converts it to a
position on the digitized road network map, which is broadcast from the traffic
service center 60 via the communication station 50 and stored in the computer
system 26. (Id., 7:32-37, Fig. 2 (emphasis added).) A block diagram of in-vehicle
device 21 is shown below:
17
P

(Id., Fig. 2.)
The digitized road network map includes nodes 14 and links 16 indicating a
traffic direction. The node 14 may represent an intersection of two or more roads, an
entry to a parking lot, a junction of a highway with an entry or exit ramp, a starting
or an endpoint of a bridge, a tunnel, an overpass or an arbitrary location on a road.
A link 16 represents a road segment with an orientation indication, which connects
two nodes 14 of the road network. (Id., 8:58-65.)
Xu explains that it uses in-vehicle device 21 for navigation:
From time to time, the mobile radio sub-system 24 transmits

vehicle position data processed by the locator 32 to the
communication station 50 which forwards road traffic data
reported from all vehicles 20 travelling the roadway system 10
to the traffic service center 60 for further processing. The
processed data is used for forecasting road traffic conditions.
The mobile radio system 24 in the vehicle 20 also receives data
broadcast by the communication station 50. The broadcast data
includes digitized road network map and traffic forecasts. The
data received by the mobile radio sub-system 24 is stored by the
computer system 26 and the road network explorer 34 uses the
data in conjunction with driver's instructions received from
the driver interface 28 to provide intelligent route guidance.
The intelligent route guidance, such as an optimum travel
route based on real-time traffic conditions, is displayed on
the screen display (not shown) of the driver interface 28.
18
P

(Id., 7:37-53 (emphasis added).) Therefore, Xu discloses a method for navigation
using a navigation device (in-vehicle device 21) which includes a location-sensing
element (locator 32 and GPS receiver 22). (See also citations and analysis below in
Parts VIII.A.1(b)-(h); Ex. 1008 at 31-35, 41.)
b) forming a database storing traffic information for

extraction thereof with respect to areas;
Xu discloses this limitation. (See Ex. 1008 at 41.) The system in Xu includes
a traffic service center 60, as shown in Figure 3, which includes collections of data
that disclose the claimed database.
(Ex. 1004 at Fig. 3 (depicting the traffic service center 60).)
The traffic service center 60 is formed to store collections of data including
traffic information for extraction thereof with respect to areas. (See Ex. 1008 at
41.) For example, the traffic service center 60 includes [a] data exchange interface
62 [] provided for connection of the communication station 50 for receiving the
19
P

vehicle position data and sending data respecting the digitized road network maps
and real-time traffic forecast data which are to be broadcast. (Id., 8:19-23 (emphasis
added).) In addition, [a]n external party interface 64 is provided to connect the
external party data sources 70 to receive real-time information about weather or
road conditions. The real-time information is processed by an external party data
integrator 65 for incorporation into real-time traffic forecasts. (Id., 8:23-28
(emphasis added).) Xu explains that traffic forecasts are computed by a traffic
forecaster 68 using the collected vehicle position data for normal road conditions.
The collected vehicle position data received from the data exchange interface 62 is
stored in a database 66 to be processed by the traffic forecaster 68. (Id., 8:28-33
(emphasis added).)
Xu further explains that the traffic forecaster 68 retrieves traffic data for two
adjacent nodes from the database 66, and determines a time at which the vehicle was
on the source node of the link and a time the vehicle was on the sink node of the
link, wherein the travel time of the vehicle for the link is determined by calculating
a difference between the two times and the travel speed for the link is determined
by dividing a length of the link by the travel time. (Id., 11:50- 57.) The data
including the travel time, or vehicle travel speed for each link are computed from
time to time from each vehicle 20 to provide a database for forecasting traffic
conditions for the roadway system 10. (Id., 11:57-60 (emphasis added).) A link
20
P

represents a road segment with an orientation indication, which connects two nodes
14 of the road network, wherein a node may represent an intersection of two or
more roads, an entry to a parking lot, a junction of a highway with an entry or exit
ramp, a starting or an endpoint of a bridge, a tunnel, an overpass or an arbitrary
location on a road. (Id., 8:58-65.) In other words, each link is associated with a
respective area. (Id.; see also id., 13:22-65 (explaining that the traffic information is
received by in-vehicle device 21 and can be extracted with respect to block areas of
the digitized road network map).)
c) receiving data concerning a location of the navigation

device which is determined using the location-sensing
element;
Xu discloses this limitation. (See Ex. 1008 at 41.) Xu discloses that [e]ach
vehicle 20 equipped with a GPS receiver [22] aligned to receive global positioning
information from the constellation of satellites 42 uses the GPS positioning
information to determine a vehicles geographical position. (Ex. 1004 at 9:66 -
10:2 (emphasis added).) This determination can be made by locator 32, which
computes the geographical location of the vehicle, using data received from the
GPS receiver 22, and converts it to a position on the digitized road network map.
(Id., 7:32-34.)
21
P

d) searching the database for traffic information specific to
a coverage area including the location of the navigation
device;
Xu discloses this limitation. (See Ex. 1008 at 41.) In particular, Xu discloses
that data from the collections of data at the traffic service center 60 is transmitted to
in-vehicle device 21 to be analyzed for traffic information specific to a coverage area
including the location of the in-vehicle device 21. (Id.)
Xu explains that traffic service center 60 divides the digitized road network
map 13 into smaller blocks (e.g., based on post code zones, or arbitrary street zones)
and associates the traffic information of respective links with a block number for
identifying where each link is located. (See Ex. 1004 at 13:30-37; Ex. 1008 at 41.)
The data is broadcast from the traffic service center 60 as a digitized road network
map 13 and received by the in-vehicle device 21. (Ex. 1004 at 13:48- 50.) Xu
discloses that geographical blocks are flagged based on the location of the in-vehicle
device 21 both before a request for planning a route is entered (id., 13:48-50, 13:66-
14:4) and after a request for planning a route is entered (id., 13:26-58). For example,
with respect to flagging that occurs before a request for planning a route is entered,
Xu explains that where the driver does not enter a destination for the trip, or where
the driver has no clear, determined destination, the locator 32 uses a configurable
radius, and a circle centered at the current vehicles position is made with the
given radius. Blocks within or partly within the circle are flagged. (Id., 13:66-
22
P

14:4 (emphasis added).) In-vehicle device 21 analyzes the received data, Xu
explaining that [t]he travel time forecast is received from the traffic service center
and traffic data relating to the flagged blocks is stored by the computer system 26,
with [t]raffic forecast data not related to the flagged blocks [] discarded. (Id.,
13:58-62.) Therefore, in-vehicle device 21 searches the collections of data of traffic
service center 60 (the database) for traffic forecast data (traffic information)
specific to geographical blocks including the geographic area that the in-vehicle
device 21 is located in, which is a subset of the geographic area over which the
navigation system operates (a coverage area including the location of the navigation
device). (See Ex. 1008 at 41.)
e) receiving a request for planning a route from an

origination to a destination;
Xu discloses this limitation. (See Ex. 1008 at 41.) For example, Xu discloses
that a destination for [a] trip may be entered by a driver using the driver interface
28. (Ex. 1004 at 13:53-55.) The locator 32 executes a program to find a block
chain that starts from the block where the vehicle is currently located, e.g., an
origination, and ends at a block in which the destination is located, e.g., a
destination. (Id., 13:55-58; see also id., 7:28-31, 7:49-50, 13:62-65 (explaining that
the driver can also change the route or destination).)
23
P

f) determining that the coverage area is different from one
or more areas in navigation coverage defined at least by
the origination and the destination;
that [t]he locator 32 executes a program to find a block chain that starts from the
block where the vehicle is currently located, and ends at a block in which the
destination is located. These chained blocks are flagged. (Ex. 1004 at 13:55-58.)
Moreover, Xu also discloses that [i]f the route or destination is changed by the
driver, the chained block list is re-computed and traffic forecast information for any
newly flagged blocks is screened from a traffic forecast at the next [Traffic
Broadcasting Interval]. (Id., 13:62-65.) Therefore, when a route is being planned,
Xu determines whether the initially flagged geographical blocks that included the in-
vehicle device 21s current location (i.e., the coverage area) are different from
newly flagged blocks formed from a new route or changed destination. In other
words, the block flagging process determines geographic areas associated with the
route between the origination and the destination that are different than the
geographic area previously determined to be associated with the location of the in-
vehicle device 21. (See Ex. 1008 at 41; see also supra Part VIII.A.1.c-d.)
g) searching the database for selected traffic information

specific to the one or more areas; and
Xu discloses this limitation. (See Ex. 1008 at 41.) For example, as discussed
above for claim element 1.d, Xu explains that traffic service center 60 divides the
24
P

digitized road network map 13 into smaller blocks (e.g., based on post code zones,
or arbitrary street zones) and associates the traffic information of respective links
with a block number for identifying where each link is located. (See Ex. 1004 at
13:30-37; Ex. 1008 at 41.) The data is broadcast from the traffic service center 60
as a digitized road network map 13 and received by the in-vehicle device 21. (Ex.
1004 at 13:48-50.) Xu discloses that geographical blocks are flagged based on the
location of the in-vehicle device 21 both before a request for planning a route is
entered (see id., 13:66-14:4) and after a request for planning a route is entered (see
id., 13:26-58). In-vehicle device 21 analyzes the received data, explaining that [t]he
travel time forecast is received from the traffic service center and traffic data relating
to the flagged blocks is stored by the computer system 26. Traffic forecast data not
related to the flagged blocks is discarded. (Id., 13:58-62; see also id., 11:43-53 (the
traffic service center 60 uses a simple calculation to compute the travel time of a
vehicle for a specific link or the vehicle travel speed on the link. The traffic
forecaster 68 retrieves traffic data for two adjacent nodes from the database 66, and
determines a time at which the vehicle was on the source node of the link and a time
the vehicle was on the sink node of the link).) Therefore, in-vehicle device 21
searches collections of data of traffic service center 60 (the database) for traffic
forecast data (selected traffic information) specific to the flagged blocks. (See Ex.
1008 at 41.)
25
P

h) planning a route to the destination, taking into
consideration at least traffic conditions derived from the
selected traffic information.
Xu discloses this limitation. (See Ex. 1008 at 41.) For example Xu discloses
that [t]he data received by the mobile radio sub-system 24 is stored by the computer
system 26 and the road network explorer 34 uses the data in conjunction with driver's
instructions received from the driver interface 28 to provide intelligent route
guidance. The intelligent route guidance, such as an optimum travel route based on
real-time traffic conditions, is displayed on the screen display (not shown) of the
driver interface 28. (Ex. 1004 at 7:46-53 (emphasis added).) Xu also discloses that
[t]he in-vehicle device 21 on each vehicle 20 receives the traffic conditions from
traffic service center 60 and processes information included in the traffic condition
broadcasts to provide route planning to the driver by recommending real-time
optimum travel routes based on real-time or forecast traffic conditions. (Id., 7:55-
60.) Xu further discloses that after a destination for the trip [is] entered by a driver
using the driver interface 28, the locator 32 executes a program to find a block
chain that starts from the block where the vehicle is currently located, and ends
at a block in which the destination is located. (Id., 13:50-58 (emphasis added).)
2. Claim 2
a) The method of claim 1 wherein the database is external

to the navigation device.
Xu discloses this limitation. (See Ex. 1008 at 42.) For example, as shown in
26
P

Figure 1, traffic service center 60 is external to in-vehicle device 21.
(Ex. 1004 at Fig. 1 (annotated).) Xu explains that the "in-vehicle device 21
transmits the static road positions of the vehicle as radio frequency data to a
communication station 50 and the communication station 50 in turn transfers
the static vehicle positions through a transfer medium 52 to [the] traffic service
center 60." (Id. , 6:39 -44 ; see also id., 8:17-36 (describing the configuration of
the traffic service center 60).)
27
P

3. Claim 3
a) The method of claim 1 wherein the location of the

navigation device is defined by GPS coordinates.
that [t]he locator 32 computes the geographical location of the vehicle, using data
received from the GPS receiver 22. (Ex. 1004 at 7:32-33; see also id., 7:4-9 (The
GPS satellites 42 transmit global positioning information to the GPS receivers 22
installed in the vehicles 20. Each receiver 22 interprets the signals from three or
more satellites 42 and determines a geographical position with an accuracy within
an average of 20 meters.).)
4. Claim 4
a) The method of claim 1 wherein the navigation device is

used in a vehicle.
that [e]ach vehicle 20 is equipped with an in-vehicle device 21. (Ex. 1004 at 6:30-
31.) Xu further discloses that vehicle support sub-system 30 is provided in the in-
vehicle device 21, which includes a road network locator 32 (hereinafter locator
32) and a road explorer 34. (Id., 7:21-23.) A mobile radio sub-system 24 is
provided for exchanging radio frequency data with the traffic service center 60 via
the communication station 50. Also included in the in-vehicle device 21 are a
computer system 26 for operating the sub-systems and storing the digitized road
network map. A driver interface 28 includes a microphone, data entry pad, screen
28
P

display and loud-speaker to permit drivers to interact with the in-vehicle device 21.
(Id., 7:23-31.)
5. Claim 5
a) The method of claim 1 wherein road conditions are also

taken into consideration in planning the route.
that, prior to broadcasting travel time forecasts, the traffic service center 60 may
weigh [r]eal-time abnormal traffic conditions . . . in a plurality of ways. (Ex. 1004
at 12:54-55.) For example, a closed road segment, for example, may be assigned a
weight factor of 1000, the weight factor being used to calculate a predicted link travel
time. Therefore, a subsequent broadcast will show that link travel time is 1000 times
greater than a normal travel time and the road explorers 34 or drivers will realize the
link is impossible. (Id., 12:55-61.) As another example, a weight factor of 5 . . .
may be used to adjust a travel time for links which are in regions experiencing heavy
snow. (Id., 12:61-63.) A database is preferably established for storing weighting
factors associated with abnormal traffic and inclement weather conditions. (Id.,
12:63-65; see also id., claim 10 (reciting A method as claimed in claim 1 wherein
the predicted travel time is multiplied by a predetermined weighting factor
associated with road or weather conditions to adjust the predicted travel time for
link L1 at the time t on the day D when the road or weather conditions are
abnormal, and/or adjusted by current unusual congestion. (emphasis added).)
29
P

In addition, the current traffic conditions may also affect traffic forecasts,
such that [i]f there is congestion on a link which is not normally congested and the
congestion is completely due to traffic volume, the traffic service center receives a
plurality of traffic data indicating that the link is experiencing an unusual congestion,
by comparing the current traffic status with the normal traffic condition. This
unusual congestion is also used to adjust the next traffic forecast. (Id., 12:66-13:6.)
Xu explains that the in-vehicle device 21 on each vehicle 20 receives the
traffic conditions from traffic service center 60 and processes information included
in the traffic condition broadcasts to provide route planning to the driver by
recommending real-time optimum travel routes based on real-time or forecast traffic
conditions. (Id., 6:55-60.) Thus, the road conditions are taken into consideration
when in-vehicle device 21 is planning a route. (See Ex. 1008 at 45.)
6. Claim 6
a) The method of claim 1 wherein weather conditions are

also taken into consideration in planning the route.
that, prior to broadcasting travel time forecasts, the traffic service center 60 may
weigh [r]eal-time abnormal traffic conditions . . . in a plurality of ways. (Ex. 1004
at 12:54-55.) For example, a weight factor of 5 . . . may be used to adjust a travel
time for links which are in regions experiencing heavy snow. (Id., 12:61-63
(emphasis added).) A database is preferably established for storing weighting
30
P

factors associated with . . . inclement weather conditions. (Id., 12:63- 65
(emphasis added); see also id., claim 10 (reciting A method as claimed in claim 1
wherein the predicted travel time is multiplied by a predetermined weighting factor
associated with road or weather conditions to adjust the predicted travel time for
link L1 at the time t on the day D when the road or weather conditions are
abnormal, and/or adjusted by current unusual congestion.) (emphasis added).)
Xu explains that the in-vehicle device 21 on each vehicle 20 receives the
traffic conditions from traffic service center 60 and processes information included
in the traffic condition broadcasts to provide route planning to the driver by
recommending real-time optimum travel routes based on real-time or forecast traffic
conditions. (Id., 6:55-60.) Thus, the weather conditions are taken into consideration
when in-vehicle device 21 is planning a route. (See Ex. 1008 at 46.)
7. Claim 7
a) The method of claim 1 wherein the navigation device

includes a display element, and at least part of the planned
route is shown on the display element.
Xu discloses this limitation. (See Ex. 1008 at 47.) For example Xu discloses
that [t]he data received by the mobile radio sub-system 24 is stored by the computer
system 26 and the road network explorer 34 uses the data in conjunction with driver's
instructions received from the driver interface 28 to provide intelligent route
guidance. The intelligent route guidance, such as an optimum travel route based on
31
P

real-time traffic conditions, is displayed on the screen display (not shown) of the
driver interface 28. (Ex. 1004 at 7:46-53; see also id., claim 26 (the driver interface
includes a data entry mechanism adapted to enable the driver to enter a destination
point, and a display mechanism for displaying a recommended travel route between
a departure point and the destination point).)
8. Claim 9
a) A method for navigation using a navigation device which

includes a location-sensing element therein, the method
comprising:
To the extent the preamble is limiting, Xu discloses this limitation for at least
the same reasons discussed above for claim element 1.a. (See supra Part VIII.A.1.a;
see also citations and analysis below in Parts VIII.A.8(b)-(h); Ex. 1008 at 48.)
b) forming a database storing weather information for

Xu discloses this limitation for at least the same reasons discussed above for
claim element 1.b and claim 6. (See supra Parts VIII.A.1.b, VIII.A.6; Ex. 1008 at
48.) With respect to weather information, Xu specifically explains that an
external party interface 64 is provided to connect the external party data sources 70
to receive real-time information about weather or road conditions. The real- time
information is processed by an external party data integrator 65 for incorporation
into real-time traffic forecasts. (Ex. 1004 at 8:23-28 (emphasis added).)
Moreover, Xu also explains that the traffic service center 60 may weigh [r]eal-time
32
P

abnormal traffic conditions . . . in a plurality of ways. (Id., 12:54-55.) For example,
a weight factor of 5 . . . may be used to adjust a travel time for links which are in
regions experiencing heavy snow. (Id., 12:61-63 (emphasis added).) A database
is preferably established [by traffic service center 60] for storing weighting factors
associated with . . . inclement weather conditions. (Id., 12:63-65; see also id., claim
10 (reciting A method as claimed in claim 1 wherein the predicted travel time is
multiplied by a predetermined weighting factor associated with road or weather
conditions to adjust the predicted travel time for link L1 at the time t on the day D
when the road or weather conditions are abnormal, and/or adjusted by current
unusual congestion.) (emphasis added).) Therefore, for these reasons, in addition
to the reasons discussed above with respect to claim element 1.b and claim 6, traffic
service center 60 is formed to store weather information for extraction thereof with
respect to areas.
c) receiving data concerning a location of the navigation

device which is determined using the location-sensing
element;
claim element 1.c. (See supra Part VIII.A.1.c; Ex. 1008 at 48.)
d) searching the database for weather information specific

to a coverage area including the location of the navigation
device;
33
P

claim element 1.d. (See supra Part VIII.A.1.d; Ex. 1008 at 48.) In particular, as
discussed for claim element 9.b, the traffic information discussed above for claim
element 1.d includes weather information. (See supra Part 8.b.)
e) receiving a request for planning a route from an

origination to a destination;
claim element 1.e. (See supra Part VIII.A.1.e; Ex. 1008 at 48.)
f) determining that the coverage area is different from one

or more areas in navigation coverage defined at least by
the origination and the destination;
claim element 1.f. (See supra Part VIII.A.1.f; Ex. 1008 at 48.)
g) searching the database for selected weather information

specific to the one or more areas; and
claim element 1.g. (See supra Part VIII.A.1.d; Ex. 1008 at 48.) In particular, as
element 1.g includes weather information. (See supra Part 8.b.)
h) planning a route to the destination, taking into

consideration at least weather conditions derived from the
selected weather information.
claim element 1.h. (See supra Part VIII.A.1.h; Ex. 1008 at 48.) In particular, as
34
P

element 1.g includes weather information. (See supra Part 8.b.)
9. Claim 10
a) The method of claim 9 wherein the database is external

to the navigation device.
claim 2. (See supra Part VIII.A.2; Ex. 1008 at 49.)
10. Claim 11
a) The method of claim 9 wherein the location of the

navigation device is defined by GPS coordinates.
11. Claim 12
a) The method of claim 9 wherein the navigation device is

used in a vehicle.
12. Claim 13
a) The method of claim 9 wherein road conditions are also

35
P

13. Claim 14
a) The method of claim 9 wherein traffic conditions are also

claim 5. (See supra Part VIII.A.5; Ex. 1008 at 53.) In particular, as discussed
above, the road conditions in Xu include traffic conditions.
14. Claim 15
a) The method of claim 9 wherein the navigation device

includes a display element, and at least part of the planned
route is shown on the display element.
15. Claim 17
a) A navigation system for a user traveling in a vehicle,

comprising:
To the extent the preamble is construed to be limiting, Xu discloses this
limitation. For example, Xu discloses a traffic data remote collection and intelligent
vehicle highway system. (Ex. 1004 at 6:26-28.) Figure 1 illustrates one example of
the navigation system.
36
P

(Id., 6:26-28, Fig. 1.) The system includes a group of vehicles 20 [that] travel a
roadway system 10, wherein [e]ach vehicle 20 is equipped with an in-vehicle
device 21. (Id., 6:28-32.) The in-vehicle device 21 has a vehicle support sub-
system 30, which includes includes a road network locator 32 (hereinafter locator
32) and a road explorer 34Also included in the in-vehicle device 21 are a computer
system 26 for operating the sub-systems and storing the digitized road network
map. (Id., 7:21-28, Fig. 2.) The locator 32 computes the geographical location of
the vehicle, using data received from the GPS receiver 22, and converts it to a
position on the digitized road network map, which is broadcast from the traffic
37
P

service center 60 via the communication station 50 and stored in the computer
system 26. (Id., 7:32-37, Fig. 2.) Therefore, Xu discloses a navigation system (e.g.,
a traffic data remote collection and intelligent vehicle highway system) for a user
traveling in a vehicle (e.g., vehicle 20). (See also citations and analysis below in
Parts VIII.A.15(b)-(f); Ex. 1008 at 55.)
b) a database formed to store traffic information for

claim element 1.b. (See supra Parts VIII.A.1.b; Ex. 1008 at 55.)
c) a processing unit for searching the database for traffic

information specific to a coverage area including the
location of the vehicle; and
claim elements 1.c-d. (See supra Parts VIII.A.1.c-d; Ex. 1008 at 55.) As discussed
above in Part VII.D, Petitioner has assumed the corresponding structure for the
identified function of the claimed processing unit is a server, a processor of a
navigation device, or equivalents thereof. (See supra Part VII.D.1.) Consistent with
these structures, Xu discloses that the in-vehicle device 21 includes a computer
system 26 for operating the sub-systems and storing the digitized road network
map, and thus the computer system 26 would perform the claimed searching, as
discussed above for claim element 1.d. (See Ex. 1004 at 7:26-28.) The computer
system 26 is thus a processing unit for searching the database as recited in this claim
38
P

element.
d) an interface for receiving a request for planning a route

from an origination to a destination,
claim element 1.e. (See supra Parts VIII.A.1.e; Ex. 1008 at 55.) In particular, Xu
discloses that a destination for [a] trip may be entered by a driver using the driver
interface 28. (Ex. 1004 at 13:53-55.) The locator 32 executes a program to find a
block chain that starts from the block where the vehicle is currently located, e.g.,
an origination, and ends at a block in which the destination is located, e.g., a
destination. (Id., 13:55-58; see also id., 7:28-31, 7:49-50, 13:62-65 (explaining that
the driver can also change the route or destination); claim 26 (the driver interface
includes a data entry mechanism adapted to enable the driver to enter a destination
point, and a display mechanism for displaying a recommended travel route between
a departure point and the destination point).)
e) wherein when it is determined that the coverage area is

different from one or more areas in navigation coverage
defined at least by the origination and the destination, the
processing unit searches the database for selected traffic
information specific to the one or more areas, and
claim elements 1.f-g. (See supra Parts VIII.A.1.f-g; Ex. 1008 at 55.) In particular,
Xu discloses that the in-vehicle device 21 includes a computer system 26 for
operating the sub-systems and storing the digitized road network map, and thus the
39
P

computer system 26 performs the claimed searching, as discussed above for claim
element 1.g. (See Ex. 1004 at 7:26-28.)
f) wherein a route to the destination is planned, taking into

selected traffic information.
claim element 1.h. (See supra Parts VIII.A.1.h; Ex. 1008 at 55.)
16. Claim 18
a) The system of claim 17 wherein the location of the vehicle

is defined by GPS coordinates.
claim 3. (See supra Parts VIII.A.3; Ex. 1008 at 56.)
17. Claim 19
a) The system of claim 17 wherein road conditions are also

18. Claim 20
a) The system of claim 17 wherein weather conditions are

40
P

19. Claim 21
a) The system of claim 17 wherein at least part of the

planned route is shown on a display.
20. Claim 23
a) The system of claim 17 wherein the database is external

to the vehicle.
21. Claim 24
a) A navigation system for a user traveling in a vehicle,

comprising:
To the extent the preamble is limiting, Xu discloses this limitation for at least
the same reasons discussed above for claim element 17.a. (See supra Part
VIII.A.15.a; see also citations and analysis below in Parts VIII.A.21(b)-(f); Ex. 1008
at 61.)
b) a database formed to store weather information for

claim element 17.b and claim 20. (See supra Parts VIII.A.15.b, VIII.A.18; Ex. 1008
at 61.) With respect to weather information, Xu specifically explains that an
external party interface 64 is provided to connect the external party data sources 70
41
P

to receive real-time information about weather or road conditions. The real-time
information is processed by an external party data integrator 65 for incorporation
into real-time traffic forecasts. (Ex. 1004 at 8:23-28 (emphasis added).)
Moreover, Xu also explains that the traffic service center 60 may weigh [r]eal-time
abnormal traffic conditions . . . in a plurality of ways. (Id., 12:54-55.) For example,
a weight factor of 5 . . . may be used to adjust a travel time for links which are in
regions experiencing heavy snow. (Id., 12:61-63.) A database is preferably
established for storing weighting factors associated with . . . inclement weather
conditions. (Id., 12:63-65.)
c) a processing unit for searching the database for weather

information specific to a coverage area including the
location of the vehicle; and
claim element 17.c. (See supra Part VIII.A.15.c; Ex. 1008 at 61.) In particular, as
element 17.c includes weather information. (See supra Part 21.b.)
d) an interface for receiving a request for planning a route

from an origination to a destination,
claim element 17.d. (See supra Part VIII.A.15.d; Ex. 1008 at 61.)
42
P

e) wherein when it is determined that the coverage area is
different from one or more areas in navigation coverage
defined at least by the origination and the destination, the
processing unit searches the database for selected weather
information specific to the one or more areas, and
claim element 17.e. (See supra Part VIII.A.15.e; Ex. 1008 at 61.) In particular, as
element 17.e includes weather information. (See supra Part 21.b.)
f) wherein a route to the destination is planned, taking into

selected weather information.
claim element 17.f. (See supra Part VIII.A.15.f; Ex. 1008 at 61.)
22. Claim 25
a) The system of claim 24 wherein the location of the vehicle

is defined by GPS coordinates.
23. Claim 26
a) The system of claim 24 wherein road conditions are also

43
P

24. Claim 27
a) The system of claim 24 wherein traffic conditions are

claim 19. (See supra Part VIII.A.17; Ex. 1008 at 64.) In particular, as discussed
above, the road conditions in Xu include traffic conditions.
25. Claim 28
a) The system of claim 24 wherein at least part of the

planned route is shown on a display.
26. Claim 30
a) The system of claim 24 wherein the database is external

to the vehicle.
B. Ground 2: Xu and Trovato Render Claims 8, 16, 22, and 29

Obvious
1. Claims 8 and 16
a) The method of claim [1 or 9] wherein turn-by-turn

instructions are communicated via audio media to a user
of the navigation device when traversing the planned
route.
As discussed above, Xu discloses all of the limitations of claims 1 and 9. (See
supra Part VIII.A.1, VIII.A.8.) In addition, Xu discloses that the driver interface 28
44
P

includes a microphone . . . and loud-speaker to permit drivers to interact with the in-
vehicle device 21. (Ex. 1004 at 7:28-31.) Xu does not explicitly recite turn-by-turn
instructions are communicated via audio media to a user of the navigation device
when traversing the planned route. However, it would have been obvious to one of
ordinary skill in the art at the time of the alleged invention to modify Xu to include
this limitation in view of Trovato.
Trovato is directed to a travel direction speaking system. (Ex. 1005 at
Abstract.) Trovato discloses that a computer prepares driving instructions based on
the route with each driving instruction including the spatial position (longitude and
latitude) of the turn at which the driving instruction applies. (Id., 2:8-11.) Trovato
explains that its system includes a Global Positioning System (GPS) unit that
provides the GPS determined position of the laptop computer. The computer
compares the GPS reading to the spatial position or setpoint and outputs the
instruction when the two positions are within a specified range of each other. (Id.,
2:11-16.) The range can be determined based on a time period required to travel
from the current position to a position associated with a speech initiation point at
which the instructions should be spoken. The time period accounts for the amount
of time required to speak the directions, for the reaction time of the driver at the
speed that the laptop computer is moving, as well as driving conditions, road
conditions, personal preference, etc. (Id., 2:16-27.) The system in Trovato includes
45
P

a text to voice unit that converts the text driving instructions into a voice signal.
(Id., 2:34-35.) Trovato discloses that, by performing its operations, it can ensure that
there is enough time to speak the directions sufficiently in advance of the turn to
allow the driver to make the turn. (Id., 1:58-60.) (See also Ex. 1008 at 38-39, 75-
76.)
It would have been obvious to one of ordinary skill in the art to modify Xu
such that turn-by-turn instructions are communicated via audio media to a user of
the navigation device when traversing the planned route, similar to the manner
disclosed in Trovato. One of ordinary skill would have recognized that both Xu and
Trovato are in the same field of navigation devices (see, e.g., Ex. 1004 at Abstract;
Ex. 1005 at Abstract), including navigation devices that take into account road and
traffic conditions to plan routes (see, e.g., Ex. 1004 at Abstract; Ex. 1005 at 2:26-
27). (See Ex. 1008 at 77-79.) One of ordinary skill would have been motivated to
modify Xu to include such turn-by-turn audio instructions since Trovato suggests
that doing so can help ensure that a driver has enough time to listen to the
instructions and make the change in direction. (Ex. 1005 at 1:35-36.) Moreover,
one of ordinary skill would have recognized that Xu was ready for improvement to
include this feature since Xu already includes a driver interface 28 [that] includes a
microphone . . . and loud-speaker to permit drivers to interact with the in-vehicle
device 21. (Ex. 1004 at 7:28-31.) In addition, one of ordinary skill would have
46
P

recognized that using turn-by-turn audio instructions as in Trovato improves the
usability and safety of the route planning system as drivers can keep their view on
the traffic in front of them, rather than reading text directions. (See Ex. 1008 at
77-79.) Thus, modifying driver interface 28 to also provide turn-by-turn instructions
that are communicated via audio media (e.g., by converting text driving instructions
into a voice signal, as in Trovato) to a user of the navigation device when traversing
the planned route, would have been a predictable modification of Xu that would not
have otherwise affected Xus operation. (See Ex. 1008 at 77-79.) Accordingly,
one of ordinary skill in the art would have understood that implementing such a
modification would have been common sense, predictable, and within the realm of
knowledge of one skilled in the art at the time of the alleged invention. See KSR Intl
Co. v. Teleflex, Inc., 550 U.S. 398, 417, 420, 421 (2007).
2. Claims 22 and 29
a) The system of claim [17 or 24] wherein turn-by-turn

instructions are communicated via audio media to the
user.
As discussed above, Xu discloses all of the limitations of claims 17 and 24.
(See supra Part VIII.A.15, VIII.A.21.) In addition, Xu discloses that the driver
interface 28 includes a microphone . . . and loud-speaker to permit drivers to interact
with the in-vehicle device 21. (Ex. 1004 at 7:28-31.) Xu does not explicitly recite
turn-by-turn instructions are communicated via audio media to a user. However,
47
P

it would have been obvious to one of ordinary skill in the art at the time of the alleged
invention to modify Xu to include this limitation in view of Trovato, for the reasons
discussed above for claims 8 and 16. (See supra Part VIII.B.1; see also Ex. 1008 at
80-81.)
C. Ground 3: Xu and Golding Render Claims 1-7, 9-15, 17-21, 23-28,

and 30 Obvious
As discussed above, Xu discloses all of the limitations of claims 1-7, 9-15, 17-
21, 23-28, and 30. (See supra Parts VIII.A.1-26.) However, during the course of this
proceeding, Patent Owner may argue that Xu does not disclose searching the
database for [traffic information or weather information] specific to a coverage area
including the location of the navigation device, determining that the coverage area
is different from one or more areas in navigation coverage defined at least by the
origination and the destination, and searching the database for selected traffic
information specific to the one or more areas, as recited in independent claims 1
and 9, or similarly recited in independent claims 17 and 24.
In particular, Patent Owner may argue at some point during the course of this
proceeding that the searching the database limitations must be performed at the
database (whereas Xu performs such operations at the client) and/or that the flagged
geographical blocks including the location of in-vehicle device 21 in Xu do not
48
P

5
correspond to a coverage area, as claimed. However, it would have been obvious
to one of ordinary skill in the art at the time of the alleged invention to modify Xu to
include this limitation in view of Golding.
Golding is directed to a system located in an automobile [that] provides
personalized traffic information and route planning capabilities. (Ex. 1006 at
Abstract.) Golding discloses that a central database [2] would collect and store
travel time information for the various street segments [and] when updated, the
travel time information can be transferred from [the] central database to the
individual automobiles. (Id., 3:33-37.) Golding also discloses that a best route
from a starting point to a destination location can be determined by [a] route advisor
13. (Id., 4:49-50.) For example, a route planning system [can] use[] the travel time
information to determine a route having minimum travel time. (Id., 3:29-31.)
5
For example, Patent Owner may attempt to reserve this argument until after
institution should the Board do so. Thus, as explained above in Part V.C, Ground 3
should be instituted even if Patent Owner does not raise this argument in a
Preliminary Response.
49
P

(Id., Fig. 1.) Golding explains that central database 2 includes a database retrieval
procedure 22 (id., 4:31-33, 5:29-31, Fig. 1), and the client-side vehicle navigation
system 1 includes a route advisor 13 (id., 4:31-33, 4:49-50, Fig. 1).
According to Golding, in order to limit the required memory, the route
advisor [13] can have travel time information for only a portion of the map database
in which the automobile is presently located. The route advisory could then obtain
any additional travel time information from the central database, as needed. (Id.,
4:53-58.) For example, [w]hen planning a route, the route advisor 13 can contact
the central database 2 to obtain updated information for the locations of interest.
50
P

(Id., 6:32-34.) (See also Ex. 1008 at 36-37, 67-70.) Thus, like Xu (see, e.g., Ex.
1004 at 13:26-14:4), Golding starts its route planning process by analyzing data from
central database 2 regarding a geographic area within which the vehicle is currently
located (searching the database for traffic information specific to a coverage area
including the location of the navigation device). If the needed information to plan
a route is not in this coverage area (determining that the coverage area is different
from one or more areas in navigation coverage defined at least by the origination
and the destination), Golding discloses retrieving traffic and map data for additional
geographic areas from central database 2 (searching the database for selected traffic
information specific to the one or more areas). (Ex. 1006 at 4:53-58, 6:32-34; see
also Ex. 1001 at 10:35-62 (describing a similar process).)
It would have been obvious to one of ordinary skill in the art to modify Xu to
analyze data from the database for [traffic information or weather information]
specific to a coverage area including the location of the navigation device (at the
database), determine that the coverage area is different from one or more areas in
navigation coverage defined at least by the origination and the destination, and
analyze data from the database for selected traffic information specific to the one or
more areas in the navigation coverage (at the database), similar to the operation
disclosed in Golding. One of ordinary skill would have been motivated to modify
Xu in this way to limit the required memory at in-vehicle device 21, as suggested by
51
P

Golding. (Ex. 1006 at 4:53-58; see also Ex. 1008 at 71-73.) In particular, as
suggested by Golding, to achieve a reduction in required memory at a vehicle
navigation device, a determination is performed to determine that the coverage area
is different from one or more areas in navigation coverage defined at least by the
origination and the destination. (See Ex. 1006 at 4:53-58, 6:32-34; see also Ex. 1008
at 71-73.) This allows the vehicle navigation device to find any additional data
needed after a request for planning a route is received, whereby the database, which
provides the additional data, also searches for and sends the data. (See Ex. 1006 at
4:53-58, 6:32-34; see also Ex. 1008 at 71-73.) One of ordinary skill also would
have been motivated to modify Xu in this way to limit the amount of processing
required to be performed at in-vehicle device 21, limiting the need to determine data
from the database that is or is not applicable to in-vehicle device 21s current
navigation needs. One of ordinary skill would have recognized that the operations
in Golding are similar to the block flagging performed in Xu, and thus that modifying
Xu in this way would have had predictable results. (Ex. 1008 at 71-73.) As
modified, one of ordinary skill would have understood that in-vehicle device 21
would, like in Golding, contact traffic service center 60 to obtain additional and
updated information for the locations of interest. (Ex. 1008 at 71-73; see also Ex.
1006 at 6:32-34) Accordingly, one of ordinary skill in the art would have understood
that implementing such a modification would have been common sense, predictable,
52
P

and within the realm of knowledge of one skilled in the art at the time of the alleged
invention. See KSR, 550 U.S. at 417, 420, 421.
D. Ground 4: Xu, Golding, and Trovato Render Claims 8, 16, 22, and
29 Obvious
As discussed above, the combination of Xu and Trovato discloses all of the
limitations of claims 18, 16, 22, and 29. (See supra Parts VIII.B.1-2.) However,
during the course of this proceeding, Patent Owner may argue that Xu does not
disclose searching the database for [traffic information or weather information]
specific to a coverage area including the location of the navigation device,
determining that the coverage area is different from one or more areas in navigation
coverage defined at least by the origination and the destination, and searching the
database for selected traffic information specific to the one or more areas, as recited
in independent claims 1 and 9, or similarly recited in independent claims 17 and 24.
However, as discussed above in Part VIII.C, it also would have been obvious to one
of ordinary skill in the art at the time of the alleged invention to modify Xu to include
this limitation in view of Golding. It would have been obvious to modify the
combination of Xu and Golding to include the limitations of claims 8, 16, 22, and
29, in view of Trovato, for at least the same reasons discussed above in Part VIII.B.1-
2. The resulting combination of Xu, Golding, and Trovato would thus include a
system that performs the processes recited in claims 8, 16, 22, and 29. (See also Ex.
1008 at 82-84.)
53
P

IX. CONCLUSION
For the reasons given above, Petitioner requests inter partes review of the
234 patent and cancellation of claims 1-30 of the 234 patent.6
Respectfully Submitted,
/s/ Ashraf A. Fawzy

Ashraf A. Fawzy
Registration No. 67,914
6
Petitioner has not necessarily raised all challenges to the 234 patent, given the
limitations placed by the Rules. Petitioner reserves all rights and defenses.
54
CERTIFICATE UNDER 37 CFR 42.24(d)
Under the provisions of 37 CFR 42.24(d), the undersigned hereby certifies
that the word count for the foregoing Petition for Inter Partes Review totals 11,602
which is less than the 14,000 words allowed under 37 CFR 42.24(a)(i).
Respectfully submitted,
Dated: June 7, 2017 /s/ Ashraf A. Fawzy

Ashraf A. Fawzy
Unified Patents Inc.

1875 Connecticut Ave., NW
Washington, DC 20009
Tel: (202) 871-0110
CERTIFICATE OF SERVICE
I hereby certify that on June 7, 2017, I caused a true and correct copy of the
foregoing materials:
Petition for Inter Partes Review of U.S. Patent No. 7,650,234, including
Exhibit list
Exhibits for Petition for Inter Partes Review of U.S. Patent No. 7,650,234
Power of Attorney
Word Count Certification Under 37 CFR 42.24(d)
to be served via Priority Mail Express on the following correspondent of record
as listed on PAIR:
Klein, ONeill & Singh, LLP

c/o Daniel Cavanagh
16755 Von Karman Ave, Suite 275
Irvine, CA 92606
/s/ Ashraf A. Fawzy

Ashraf A. Fawzy

Unified Patents Inc. v. Silver State Intellectual Technologies Inc., IPR2017-01531 (PTAB June 7, 2017)

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Unified Patents Inc. v. Silver State Intellectual Technologies Inc., IPR2017-01531 (PTAB June 7, 2017)

Enviado por

Direitos autorais:

Formatos disponíveis

Petition for Inter Partes Review, IPR2017-01531

U.S. Patent No. 7,650,234

UNITED STATES PATENT AND TRADEMARK OFFICE

BEFORE THE PATENT TRIAL AND APPEAL BOARD