IN THE UNITED STATES PATENT AND TRADEMARK OFFICE

Transcription

1 IN THE UNITED STATES PATENT AND TRADEMARK OFFICE In re Patent of: Myr U.S. Pat. No.: 6,480,783 Attorney Docket No.: IP3 Issue Date: Nov. 12, 2002 Appl. Serial No.: 09/528,134 Filing Date: Mar. 17, 2000 Title: REAL TIME VEHICLE GUIDANCE AND FORECASTING SYSTEM UNDER JAM CONDITIONS Mail Stop Patent Board Patent Trial and Appeal Board U.S. Patent and Trademark Office P.O. Box 1450 Alexandria, VA PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 6,480,783 PURSUANT TO 35 U.S.C , 37 C.F.R. 42

2 TABLE OF CONTENTS IPR of U.S. Pat. No.: 6,480,783 I. INTRODUCTION... 1 II. MANDATORY NOTICES UNDER 37 C.F.R A. Real Parties-In-Interest Under 37 C.F.R. 42.8(b)(1)... 2 B. Related Matters Under 37 C.F.R. 42.8(b)(2)... 2 C. Lead And Back-Up Counsel Under 37 C.F.R. 42.8(b)(3)... 3 D. Service Information... 3 III. PAYMENT OF FEES 37 C.F.R IV. REQUIREMENTS FOR IPR UNDER 37 C.F.R A. Grounds for Standing Under 37 C.F.R (a)... 4 B. Challenge Under 37 C.F.R (b) and Relief Requested... 4 V. SUMMARY OF THE 783 PATENT AND PROSECTUTION HISTORY... 6 VI. Claim Construction under 37 C.F.R (b)(3)... 8 VII. THERE IS A REASONABLE LIKELIHOOD THAT AT LEAST ONE CLAIM OF THE 783 PATENT IS UNPATENTABLE A. Ground 1: Claim 4 is Obvious under 103 over TravTek in view of Smith B. Ground 2: Claim 6 is Obvious under 103 over TravTek in view of Smith and Roozemond C. Ground 3: Claims 4 and 6 are Obvious under 103 over Xu in view of Vemuri and Peterson VIII. CONCLUSION i

3 EXHIBITS IPR of U.S. Pat. No.: 6,480,783 GOOGLE1001 U.S. Patent No. 6,480,783 to Myr ( the 783 patent ) GOOGLE1002 Prosecution History of the 783 patent (Serial No. 09/528,134) GOOGLE1003 GOOGLE1004 GOOGLE1005 GOOGLE1006 GOOGLE1007 GOOGLE1008 GOOGLE1009 GOOGLE1010 GOOGLE1011 GOOGLE1012 Declaration of Dr. Michael S. Braasch TravTek System Architecture Evaluation by U.S. Department of Transportation, Publication No. FHWA-RD (July 1995) ( TravTek ) Forecasting Travel Times Based on Actuated and Historic Data by Roozemond (1997) ( Roozemond ) U.S. Patent No. 6,401,027 to Xu et al. ( Xu ) U.S. Patent No. 5,845,227 to Peterson ( Peterson ) Definition of exponential smoothing from Dictionary of Statistics & Methodology by W. Paul Vogt (1999). Complaint in Makor Issues & Rights Ltd. v. Google Inc. et al., 1:16-cv (Feb. 19, 2016) Screen capture of WorldCat listing for TravTek Screen capture of University of Washington Library listing for TravTek Screen capture of WorldCat listing for Roozemond ii

4 GOOGLE1013 GOOGLE1014 GOOGLE1015 GOOGLE1016 GOOGLE1017 GOOGLE1018 GOOGLE1019 GOOGLE1020 GOOGLE1021 Screen capture of University of California, Berkeley Library listing for Roozemond Probe Vehicle Sample Sizes for Real-Time Information: The Houston Experience by Turner et al. (1995) ( Turner ). Determination of Number of Probe Vehicles Required for Reliable Travel Time Measurement in Urban Network by Srinivasan et al., Transportation Research Record vol. 1537, (1996) ( Srinivasan ). U.S. Patent No. 6,680,694 to Knockeart et al. ( Knockeart ) U.S. Patent No. 5,808,566 to Behr et al. ( Behr ) First Declaration of Lisa Rowlison de Ortiz, Head of Catalog and Metadata Services - University of California at Berkeley Library (dated August 2, 2016) Short-Term Traffic Flow Prediction: Neural Network Approach by Brian L. Smith and Michael J. Demetsky, Transportation Research Record (1994) ( Smith ) Short-Term Forecasting of Traffic Delays in Highway Construction Zones Using On-Line Approximators, by A.T. Vemuri and M. M. Polycarpou, Mathematical and Computer Modelling Vol. 27 (1998) Screen capture of WorldCat listing for Smith iii

5 GOOGLE1022 GOOGLE1023 GOOGLE1024 GOOGLE1025 GOOGLE1026 GOOGLE1027 Screen capture of University of California, Berkeley Library listing for Smith Screen capture of WorldCat listing for Vemuri Screen capture of Truman State Library listing for Vemuri Second Declaration of Lisa Rowlison de Ortiz, Head of Catalog and Metadata Services - University of California at Berkeley Library (dated January 18, 2017) Declaration of Stephen Wynn, Interim Associate Library Dean for Technical Services and Systems Truman State University (dated January 13, 2017) U.S. Patent No. 5,225,842 to Brown et al. ( Brown ) iv

6 I. INTRODUCTION Google Inc. ( Petitioner ) petitions for Inter Partes Review ( IPR ) of claims 4 and 6 of U.S. Patent 6,480,783 ( the 783 patent ). The 783 patent relates to a navigation system that allegedly computes the optimal route between the present position of a vehicle and a destination, and displays that route to a driver. GOOGLE1001, 2: Independent claim 4 the only independent claim challenged in this Petition recites a collection of route-computation features that were not new by the relatively-late time frame of March Indeed, a number of prior art references (TravTek and Xu) describe similar route-computing systems that are nearly identically to the preferred embodiment described in the 783 patent, yet none of those references were considered during prosecution. As a first example, TravTek describes a system that much like the 783 patent used probe vehicles to measure current and historical travel times, and then used those travel times to provide motorists with optimal driving routes. A secondary reference (Smith) teaches that it was known to use the current traffic data to perform short-term traffic predictions (e.g., 5 minutes into the future using time-series trend analysis), and multiple reasons would have prompted a POSITA to modify TravTek s system based on Smith s suggestion for short-term traffic predictions. Infra, Section VII.A. As a second example, Xu also describes a system that uses probe vehicles to 1

7 measure current and historical vehicle travel times, and utilizes these travel times to provide motorists with optimal routes. A secondary reference (Vemuri) teaches that it was known to use current travel times to perform short-term traffic predictions using time-series trend analysis. Infra, Section VII.B. Another secondary reference (Peterson) teaches the commonly known benefits for calculating the route server-side rather than at on-vehicle computers. The prior art combinations described below in Grounds 1-3 were never considered during prosecution of the 783 patent. If they had been, the 783 patent would not have issued. Petitioner therefore requests IPR of claims 4 and 6. II. MANDATORY NOTICES UNDER 37 C.F.R 42.8 A. Real Parties-In-Interest Under 37 C.F.R. 42.8(b)(1) Google Inc. and Waze Inc. are the real parties-in-interest. No other party had access to the Petition, and no other party had any control over, or contributed to any funding of, the preparation or filing of the present Petition. B. Related Matters Under 37 C.F.R. 42.8(b)(2) Patent Owner is a non-practicing entity that filed a complaint alleging infringement of the 783 patent and U.S. Patent 6,615,130 ( the 130 patent ) against Google and Waze in the District of Delaware (Makor Issues & Rights Ltd. v. Google Inc. et al., 1:16-cv-00100) (GOOGLE1009). Petitioner filed a previous IPR petition on August 5, 2016, challenging claims 12-16, 18, and 19 of the 783 2

8 patent (IPR ), and is concurrently filing two other IPR petitions challenging other claims of the 783 patent (one challenging claims 1 and 3, and the other challenging claims 20, 22, and 23). Regarding the 130 patent, Petitioner previously filed two IPR petitions on August 5, 2016 to challenge claims 1-4 of the 130 patent (IPR and IPR ), and is concurrently filing an IPR petition challenging claim 6 of the 130 patent. C. Lead And Back-Up Counsel Under 37 C.F.R. 42.8(b)(3) Petitioner provides the following designation of counsel. LEAD COUNSEL Michael T. Hawkins, Reg. No. 57, RBC Plaza, 60 South Sixth Street Minneapolis, MN Tel: / Fax BACK-UP COUNSEL Patrick J. Bisenius, Reg. No. 63,893 Tel: Andrew L. Dommer, Reg. No. 65,758 Tel: D. Service Information Please address all correspondence to the address above. Petitioner consents to electronic service by at IPR IP3@fr.com (referencing No IP3 and cc ing PTABInbound@fr.com, hawkins@fr.com, bisenius@fr.com, and dommer@fr.com). III. PAYMENT OF FEES 37 C.F.R Petitioner authorizes the Office to charge Deposit Account No for the petition fee set in 37 C.F.R (a) and for any other required fees. 3

9 IV. REQUIREMENTS FOR IPR UNDER 37 C.F.R A. Grounds for Standing Under 37 C.F.R (a) Petitioner certifies that the 783 patent is available for IPR and Petitioner is not barred or estopped from requesting IPR. B. Challenge Under 37 C.F.R (b) and Relief Requested Petitioner requests IPR of claims 4 and 6 on the grounds listed below. Ground Claims Basis for Rejection Ground 1 4 TravTek in view of Smith Ground 2 6 TravTek in view of Smith and Roozemond Ground 3 4, 6 Xu in view of Vemuri and Peterson The earliest possible priority date of the 783 patent is March 17, Xu is a patent that was filed March 24, 1999, and thus qualifies as prior art under 102(e). TravTek s date stamp indicating 1995 publication, its WorldCat listing, a University of Washington Library listing, and the First Rowlison de Ortiz Declaration s indication of public availability by January 1997 confirm that TravTek is 102(b) prior art. GOOGLE1004, 2 (listing 1995 date stamp); GOOGLE1010 (WorldCat listing); GOOGLE1011 (library listing); GOOGLE1018, 4-10 (testimony confirming public library availability). 4

10 Roozemond s 1997 copyright notice, its WorldCat listing, a University of California-Berkeley Library listing, and the First Rowlison de Ortiz Declaration s indication of public availability by May 1998 confirm that Roozemond is 102(b) prior art. GOOGLE1005, 1 (listing 1997 copyright); GOOGLE1012 (WorldCat listing); GOOGLE1013 (library listing); GOOGLE1018, 4-6, (testimony confirming public library availability). Smith s WorldCat listing, its University of California-Berkeley library listing, and the Second Rowlison de Ortiz Declaration s indication of public availability by August 1995 affirm that Smith is 102(b) prior art. GOOGLE1021 (World- Cat listing); GOOGLE1022 (library listing); GOOGLE1025 (testimony confirming library availability in August 1995). Vemuri s 1998 copyright notice, its WorldCat listing, its Truman State University Library listing, and the Wynn Declaration s indication of June 1998 public availability affirm that Roozemond is 102(b) prior art. GOOGLE1020, 1 (copyright notice); GOOGLE1023 (WorldCat listing); GOOGLE1024 (library listing); GOOGLE1026 (testimony confirming library availability in June 1998). The individual grounds below are not redundant as they meaningfully differ in the statutory types of prior art (a combination of 102(b) references versus a combination based on a 102(e) reference) and how those references are applied to the claims (e.g., the primary references address different sets of elements of claim 5

11 4). Additionally, this Petition is not redundant with the previously-filed petitions against the 783 patent (IPR ) and with the two concurrently-filed petitions against the 783 patent all of which address different subsets of claims based on different prior art combinations. Each of these petitions are worthy of independent consideration on the merits. Importantly, the present petition challenges only claims 4 and 6. These claims could not have been challenged in the earlier petition (IPR ) due to the space constraints that prevented the addition of Grounds 1-4 listed above and the requisite analysis for each of those Grounds (as described in detail below). Additionally, these claims were specifically (and surprisingly) asserted for the first time in infringement contentions in the above-mentioned litigation only a few days before the earlier petition (IPR ) was filed, and thus Petitioner required additional time to analyze claims 4 and 6 and the relevant prior art, to confer with Dr. Braasch (GOOGLE1003), and to prepare the present Petition. V. SUMMARY OF THE 783 PATENT AND PROSECTUTION HISTORY The 783 patent describes a navigation system that includes a Central Traffic Unit (CTU) that receives vehicle location data from a fleet of vehicles that are traveling on roads, uses that data to determine the level of congestion on the roads, and then transmits that congestion data to vehicles for optimal route-calculation. 6

12 GOOGLE1001, 5:16-24, 2:56-59; GOOGLE1003, 25. While much of the 783 patent discusses route calculation at in-vehicle computers, the 783 patent mentions alternative server-side implementations in which the data processing and route planning previously executed at [client vehicles] are now transferred to the Internet server database. Compare GOOGLE1001, 3:15-28 to 18:11-36; GOOGLE1003, 28. Claim 4 of the 783 patent refers to computing units that are capable of updating current travel times tables, predicted or estimated travel times tables and statistical travel times data tables. These different types of travel times are referenced in different ways throughout the 783 patent, as explained below: Current travel times: A section titled Current Travel Times refers to actual travel times registered for a number of vehicles that have recently traveled along various road links. GOOGLE1001, 12: Predicted/estimated travel times: The 783 patent does not refer to predicted travel times or estimated travel times, but does explain how the term Current Travel Times (CTT) can alternatively refer to travel times estimated using a linear-regression trend-analysis technique for short-term travel time prediction (e.g., 5 minutes into the future). GOOGLE1001, 12:52-59 ( [T]he CTT is estimated as a predicted value. This prediction is based on linear regression. ); 12:60-14:22. 7

13 Statistical/empirical/regular travel times: The 783 patent refers to statistical, empirical, and regular travel times interchangeably. GOOGLE1001, 3:36-37, 8:57-58, 10:26-32, 11:6-27. The patent explains that these travel times are statistical averages of previously-recorded travel times. GOOGLE1001, 11:59-12:10 ( averaged and stored ). GOOGLE1003, 26. During prosecution, Applicant added application claim 17 (which matured into issued claim 4) in response to the first office action. GOOGLE1002, 106. The added claim only included four lines of text (only elements [4.P] and [4.1]). The examiner rejected application claim 17 as being anticipated by US6,150,961. GOOGLE1002, 130. In response, Applicant amended claim 17 by adding elements [4.2]-[4.9]. GOOGLE1002, 153. Applicant argued that amended claim provides optimized routes to the client, rather than merely providing traffic data as is shown in the prior art. GOOGLE1002, This was the only feature of claim 17 explicitly argued as allegedly missing from the art. Id. The examiner issued no further rejections and provided a Notice of Allowance in June GOOGLE1002, VI. Claim Construction under 37 C.F.R (b)(3) For the purposes of IPR only, Petitioner submits that terms of the 783 patent are to be given their broadest reasonable interpretation as understood by a 8

14 POSITA at the time in view of the specification ( BRI ). 37 CFR (b). Also, for purposes of IPR only, Petitioner provides the following construction where the BRI may not be entirely clear. GPS data data that was determined using signals received from GPS satellites or that is related to use of such signals. GOOGLE1003, 37. This interpretation is consistent with the 783 patent specification and with the extrinsic evidence addressing the BRI standard. See GOOGLE1001, 2:67-3:3; GOOGLE1003, 37. The 783 patent describes GPS data for vehicles as such things as present positions, the position time, their IDs, and their speed vectors at specific time intervals (e.g., a broad category encompassing more than mere GPS coordinates or information determined therefrom). GOOGLE1001, 2:67-3:3. These examples of GPS data make clear that various types of information that are either generated from a GPS signal (e.g., present positions ), derived from multiple GPS signals over time (e.g., speed vectors ) or that are related to use of such signals (e.g., vehicle position time and IDs ) all qualify as GPS data. Accordingly, under the BRI standard, information sent from the vehicles to a centralized computer system that are related to GPS location services qualify as GPS data. GOOGLE1003, 37. A number of claim elements addressed below may be, under the narrower Phillips standard, subject to construction under 35 U.S.C. 112, 6 due to a lack of recited structure. Additionally or alternatively, a number of elements recite purely 9

15 functional software/data untethered from any tangible medium (e.g., at least elements [4.3], [4.5]-[4.8]), thereby reciting mere non-functional descriptive material that is not entitled to patentable weight. In re Ngai, 367 F.3d 1336, 1339 (Fed. Cir. 2004); Ex parte Nehls, 88 USPQ2d 1883, (BPAI 2008) (precedential); Mobotix Corp. v. E-Watch, Inc., IPR , Pap. 20 at pp As described in Section VII below, the prior art addresses these elements in a manner highly similar to the preferred embodiment of the 783 patent, so no further express constructions are necessary here because claim terms need only be construed to the extent necessary to resolve the controversy. Wellman, Inc. v. Eastman Chem. Co., 642 F.3d 1355, 1361 (Fed. Cir. 2011). VII. THERE IS A REASONABLE LIKELIHOOD THAT AT LEAST ONE CLAIM OF THE 783 PATENT IS UNPATENTABLE As detailed below, each of claims 4 and 6 is rendered obvious by at least two grounds. GOOGLE1003, 39. A. Ground 1: Claim 4 is Obvious under 103 over TravTek in view of Smith As previously described, claim 4 was allowed after Applicant argued that the claimed subject matter provides optimized routes to the client, rather than merely providing traffic data as is shown in the prior art. GOOGLE1002, TravTek, however, discloses this feature. TravTek describes a US Department of Transportation project that installed navigation systems in 100 vehicles in Orlando. 10

16 GOOGLE1004, 8, 20, 31. These [p]robe vehicles monitored the time it takes to traverse a link, in order to provide TravTek s system with real-time travel times. GOOGLE1004, In addition to measuring travel times, the system provided motorists with route selection and guidance. GOOGLE1004, 8. TravTek explains that in a Central Architecture embodiment, the Route calculation is Performed at the TMC, and the calculated route is then transferred to the vehicle. GOOGLE1004, As such, TravTek discloses the feature that Applicant explained to be missing from the prior art. As described below, the predictable combination of TravTek and Smith provides not only this purportedly missing feature, but every element of claim 4. [4.P] Client mobile unit guidance system for motor vehicles, Even if this preamble were treated as a limitation, TravTek in view of Smith provides such a system. GOOGLE1003, 45. For example, TravTek s system provided route guidance to operators of 100 test vehicles equipped with invehicle TravTek devices. GOOGLE1004, 20-22; infra, analysis of Element [4.1]. [4.1] the system comprising computing units capable of updating current travel times tables, predicted or estimated travel times tables and statistical travel times data tables continuously or according to predetermined time intervals from a central traffic unit, Regarding the functional/intended use recitation capable of, TravTek s computing units are plainly capable of achieving this function (under the BRI 11

17 standard; GOOGLE1003, 46) and, indeed, the predictable combination of TravkTek and Smith would have actually performed this function. GOOGLE1003, TravTek is clear that its system includes computing units that update current and statistical travel times. GOOGLE1003, Smith suggests the traditional practice of updating predicted/estimated travel times in such systems, and there were multiple reasons (articulated below) that would have prompted a POSI- TA to modify TravTek s system based on this predictable option. GOOGLE1003, Current travel times tables. TravTek explains that its server-side systems stored current travel times in a database that was updated on a minute by minute basis. GOOGLE1004, 61, 76 ( the vehicle transmitted its current travel times on a minute by minute basis back to the TMC for integration in the current link travel time data base. ), 78-79; GOOGLE1003, 48. Statistical travel times data tables. As described in Section V (supra), the 783 patent refers to statistical, empirical, and regular travel times interchangeably. GOOGLE1001, 3:36-37, 8:57-58, 10:26-32, 11:6-27. TravTek explains how it s system updates historical times using times from travel time runs over major thoroughfares, just like with the 783 patent s statistical travel times. GOOGLE1004, Regarding storage of these travel times, TravTek s system included a historical data base of measured link travel times, 12

18 which was actually several data bases corresponding to different times of day and days of the week. GOOGLE1004, 38, ; GOOGLE1003, 49. Predicted or Estimated travel times tables. As described in Section V (supra), the 783 patent does not refer to predicted travel times or estimated travel times, but does explain how Current Travel Times (CTT) are generated using a linear regression trend-analysis technique to predict travel times minutes into the future. GOOGLE1001, 12:52-59 ( [T]he CTT is estimated as a predicted value. based on linear regression. ); 12:60-14:22. To the extent that the claimed predicted or estimated travel times refers to this form of prediction, the 783 patent describes its regression techniques in a math-intensive section from 12:26 through 16:22. That section describes how current travel times are being used as a basis for forecasting future travel times. GOOGLE1001, 14:7-9. An example of Regression-Based Prediction of Current Travel Times [is] presented in FIG. 20, shown below: 13

19 GOOGLE1001, FIG. 20, 13: This figure shows a graph of travel times (vertical axis) for a given road link, plotted based on vehicle entry times (horizontal axis) for that road link, with a linear regression technique used to predict the travel time at any future time t. GOOGLE1001, 13:50-63; GOOGLE1003, 50. Although TravTek may not discuss regression prediction techniques, such techniques were well known throughout 1990s to predict future traffic conditions, as evidenced by repeated examples in Smith. Smith refers to intelligent vehiclehighway systems (IVHS) and explains how it is imperative in such systems to predict traffic rather than simply monitoring it: It is imperative that surveillance data be used to manage the system in a proactive rather than a reactive manner. Proactive traffic management will require the ability to predict traffic conditions. Previous predictive modeling approaches can be grouped into three categories: 14

20 (a) historical, data-based algorithms; (b) time-series models; and (c) simulations. GOOGLE 1019, 1. Although Smith notes that IVHS systems used traffic predictions to optimize traffic signal timing and ramp metering, Smith explains that traffic predictions can also be used for route guidance. GOOGLE1019, 1 ( the rationale behind using predictive information (for route guidance) is that travelers decisions are affected by future traffic conditions expected to be in effect when they reach downstream sections of the network. ); GOOGLE1003, 51. Smith explains multiple different ways to predictively model traffic conditions. First, Smith refers to UTCS-2 and LISB, two examples that used both historical and current traffic data to predict traffic. GOOGLE1019, 2. Second, Smith discusses the traditional use of time-series modeling to predict traffic: [Traffic] measurements can easily be stored for use in predicting the systems condition at time t + D, where D is the prediction interval. As such, the prediction problem boils down to forecasting x(t + D), given x(t), x(t - D), x(t - 2D), and so on. This representation of the prediction problem describes a time series. Transportation researchers have applied many of these time series analysis techniques to traffic prediction. 15

21 GOOGLE1019, 2 (emphasis added). Time-series modeling is what the 783 patent describes and shows in Figure 20. Indeed, the 783 patent s preferred prediction technique is regression, and a time-series technique described by Smith is the autoregressive integrated moving average (ARIMA) method. GOOGLE1019, 2 (emphasis added); GOOGLE1003, 52. Although Smith notes that ARIMA models have not shown great promise in traffic applications due to unsatisfactory goodness of fit and high errors, and that the ARIMA model was less accurate and tended to lag and overpredict values when compared against historical and neural network models (GOOGLE1019 at 2, 5-6), Smith is clear that all three of the [historic, time-series, and neural network] models did an excellent job of predicting future volumes in the short term. GOOGLE1019, 5 (emphasis added), 2. Moreover, ARIMA models require very little computational time for execution, which makes them useful for applications in real-time traffic management. GOOGLE1019, 2; GOOGLE1003, Third, Smith discusses using neural network models to predict traffic, explaining that such models are excellent candidates for application to the traffic flow prediction problem. GOOGLE1019, 4. These models function as a sophisticated form of regression, similar to the 783 patent s use of regression. GOOGLE1019, 3; GOOGLE1003, 53. While Smith notes that Zhang et al. and 16

22 the University of Leeds previously used neural network models to predict traffic, Smith advocates using neural network backpropagation, and details the results of his study that compared backpropagation to time-series and historical modeling on traffic data from an Alexandria, Virginia section road in GOOGLE1019, 4. Smith explained that the neural network backpropagation model does the best job of modelling the underlying relationship between the state of the system and future traffic volume during peak conditions. GOOGLE1019, 6. A POSITA would have been prompted to modify TravTek s system (based on Smith s suggested benefits) to use already-collected current traffic data to generate real-time short-term prediction of traffic conditions, using any of the prediction models described in Smith, especially because Smith explains that all three of the models did an excellent job. GOOGLE1019, 5; GOOGLE1003, First, a POSITA would have been prompted to make this modification because Smith explains that real-time short-term prediction of traffic conditions will enhance the performance of current systems, and it would be beneficial to enhance TravTek s system because TravTek s objective is to minimize route travel times. GOOGLE1004, 38; GOOGLE1019, 1; GOOGLE1003, 55. Second, TravTek already provides limited short-term predictive modeling for incident conditions using a computer model (FREFLOW) to predict free- 17

23 way link travel times under incident conditions, and modifying TravTek to also provide short-term predictive modeling for probe vehicle data is just an extension of a predictive technique that TravTek is already using to a different data set. GOOGLE1004, 38; GOOGLE1003, 56. Third, a POSITA would have been prompted to make this modification because Smith explains that it is imperative that current travel data be used in a proactive rather than a reactive manner. GOOGLE1004, 38; GOOGLE1019, 1. Indeed, Smith explains that special attention should be given to the ability to make short-term traffic predictions with real-time sensor data. GOOGLE1019, 1; GOOGLE1003, 57. Fourth, a POSITA would have been prompted to make this modification because doing so would be merely the application of a known technique (e.g., Smith s suggestion to generate short-term predictions from current traffic condition data) to a known system (e.g., TravTek s system) ready for improvement to yield predictable results. Indeed, when a patent simply arranges old elements with each performing the same function it had been known to perform and yields no more than one would expect from such an arrangement, the combination is obvious. KSR Int l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007); GOOGLE1003,

24 Smith describes that short-term traffic predictions can be used in various types of systems, but is clear that such traffic predictions can be and have been used for route guidance. GOOGLE1019, 1. Moreover, Smith describes that its prediction modeling can use different types of surveillance data such as vehicle counts, vehicle locations, vehicle speeds and link times, and therefore a POSITA would have been prompted to modify TravTek s link travel time based system based on Smith s suggestions. GOOGLE1019, 1 ( The ability to make and continuously update predictions of traffic flows and link times for several minutes into the future using real-time data is a major requirement for providing dynamic traffic control. (emphasis added)); GOOGLE1003, The modified TravTek system would use current travel times (e.g., those already calculated using probe vehicles) in any of the above-described time-series or neural network models to provide real-time short-term prediction of traffic conditions, since both models are described as doing an excellent job. GOOGLE 1019, 5. Indeed, TravTek already provides limited short-term predictive modeling for incident conditions using a computer model (FREFLOW) to predict freeway link travel times under incident conditions. GOOGLE1004, 38. Modifying TravTek to use short-term forecasts generated from current travel times rather than using the current travel times themselves would enhance TravTek s traffic prediction system. GOOGLE1019, 1. Moreover, Smith notes that the rationale be- 19

25 hind using predictive information (for route guidance) is that travelers decisions are affected by future traffic conditions expected to be in effect when they reach downstream sections, and short-term travel time forecasts are more likely to be in effect once a vehicle reaches a road than current travel times that are actually minutes old. GOOGLE1019, 1 (emphasis added); GOOGLE1003, In TravTek s modified system, the predicted travel times would be stored in a data base. GOOGLE1003, 63. Indeed, TravTek is clear that [e]ach [source of travel times] contributed in small part to the traffic information data base and that all travel times were pulled from a link travel time data base. GOOGLE1004, 50, 61. Moreover, TravTek explains that its data base computer controlled the data fusion process, which combined travel times from different sources. GOOGLE1004, 31. Database tables. Although the above discussion explains that TravTek stores travel times in databases, element [4.1] recites that travel times are stored in tables. In this regard, TravTek is clear that its databases store data in database tables. GOOGLE1004, 69, 239 (both referring to data base tables ), 29, 51; GOOGLE1003, 64 (database obviously had tables). Updated continuously or according to predetermined time intervals. Element [4.1] recites that the travel times are updated continuously or according to predetermined time intervals. TravTek also discloses this feature, explaining how 20

26 the current link travel time data base. was updated on a minute by minute basis (GOOGLE1004, 61; see 39, 65, 128 (emphasis added)), and how [a]n exponential smoothing algorithm was used to constantly update the historical data base (GOOGLE1004, 95; see 65, 230 (emphasis added)). With regard to predicted travel times, Smith explains that [a] 15-min prediction interval was utilized (GOOGLE1019, 4-6), and a POSITA would have been prompted to similarly implement a prediction interval in TravTek s modified system. GOOGLE1003, 65. [4.2] wherein the systems further includes [sic]: receiving device for allowing collection of GPS data at predetermined time intervals from sample vehicles moving within a predefined geographical region; Regarding the functional/intended use recitation for allowing, TravTek s TMC is plainly able to allow[] achieving this function (under the BRI standard) and indeed actually performed this function. Accordingly, TravTek in view of Smith discloses this element. GOOGLE1003, Regarding the requirement that the system include a receiving device for allowing collection of location data, TravTek s system included a TMC at which [t]raffic related information from a variety of sources was combined and sorted (fused). GOOGLE1004, 31. The TMC received Incoming Probe Reports from each vehicle that provided, inter alia, that vehicle s Vehicle ID, Latitude, longitude, and Last link traversed and travel time. GOOGLE1004,

27 Regarding the requirement that the location data be GPS data, this petition construes GPS data to mean data that was determined using signals received from GPS satellites or that is related to use of such signals. See Section VI, supra. TravTek discloses GPS data under either portion of this construction (i.e. either determined using or related to ). For example, TravTek notes that its navigation system used a GPS system as part of its dead-reckoning system, with the GPS system being used to recover from dead-reckoning errors. GOOGLE1004, 78; 31-33, 62-64, 223. As such, at least TravTek s Latitude, longitude, and heading and Last link traversed and travel time portions of the incoming probe reports disclose GPS data, because both types of data is either determined using signals received from GPS satellites or that is related to use of such signals, as the construction of GPS data recites. GOOGLE1003, Even under a construction of GPS data that would exclude dead reckoning, TravTek discloses the GPS data feature when TravTek used GPS coordinates exclusively because the dead reckoning system was not working well. TravTek s system can also use Differential GPS (DGPS) (GOOGLE1004 at 223), and a POSITA would have considered it an obvious and straightforward modification to use GPS exclusively for all location determinations because GPS can provide greater accuracy than dead reckoning when differential GPS (DGPS) is 22

28 employed, in which case TravTek clearly discloses using GPS data. GOOGLE1003, Regarding the requirement that GPS data is collected at predetermined time intervals from sample vehicles, TravTek teaches that [e]ach vehicle transmitted its probe report once each minute. ), GOOGLE1004, 55, 29, 39, 95. Regarding the requirement that sample vehicles move within a predefined geographical region, TravTek discloses that in-vehicle devices were installed in vehicles operating in a 1900 km2 area surrounding Orlando, as illustrated in the below figure. GOOGLE1004, 8, , FIGS. 1, 21; GOOGLE1003,

29 [4.3] map database containing digital road maps of a predefined geographical region together with predetermined relevant data on road factors; To the extent that the map database recitation is considered a structural limitation entitled to patentable weight (which it is not because it is merely nonfunctional descriptive data in a system claim), 1 TravTek in view of Roozemond discloses this element. GOOGLE1003, 70. For example, TravTek is clear that its vehicles each included a map database. GOOGLE1004, 47 ( maintained the map data base in the vehicles ), 31. As described in greater detail infra, element [4.9] recites that client mobile units are provided with optimal travel routes, presumably from server-side systems. The discussion at element [4.9] explains how TravTek notes that a central architecture variation of TravTek s system could calculate routes server-side and transmit those routes to vehicles. Although it is unnecessary to discuss various aspects of the central architecture variation with regard to this map database fea- 1 Under the BRI standard, the recitation of mere data/software untethered from any storage medium/structure is nothing more than non-functional descriptive material that is not entitled to any patentable weight under the BRI standard. Ngai, 367 F.3d at 1339; Nehls, 88 USPQ2d at (precedential); Mobotix, IPR , Pap. 20 at pp

30 ture (that will be done at element [4.9]), it is worth noting here that [t]he map data base would have resided at the TMC in a central architecture implementation. GOOGLE1004, 218. This map database element is satisfied regardless whether the routes are calculated server-side or client-side. The claimed relevant data on road factors feature is not entitled to patentable weight because the feature does not have a functional relationship to a specifically recited structure. Praxair v. Mallinckrodt, IPR , Pap. 53, p. 16 (citing to Miller, 418 F.2d at 1396 and Ngai, 367 F.3d at 1339), see supra, Section VI. Even if the relevant data on road factors is entitled to patentable weight, TravTek discusses that [o]ther information associated with network link records in the data base consisted of data such as zip code, name, length, lane restriction information, link type [p]osition. GOOGLE1004, 48, 39-41, 53, 58-59, 95, , , ; GOOGLE1003, [4.4] said computer system operatively connected to the communications system capable of processing in real time said GPS data and transforming them into appropriately structured data suitable for being stored on the computer; As an initial point, this claim does not include antecedent basis for said computer system, the communications system, or the computer. Moreover, regarding the functional/intended use recitation capable of, TravTek s computer system is plainly capable of achieving this function (under the BRI standard) and 25

31 indeed actually performed this function. TravTek discloses at least two examples of the claim element. GOOGLE1003, In a first example, TravTek s computer system that processes vehicle location GPS data and transforms that GPS data into link travel times discloses this feature. For example, TravTek explains how the time required for the TravTek vehicle to travel a link was determined by monitoring the time it crossed the beginning and end of the link. GOOGLE1004, 88. The transformation of beginning and ending times into link travel times is performed at each vehicle in the clientside implementations, and is performed at the TMC in the centralized architecture implementations because TravTek explains how in the centralized architecture implementation all major processing functions that are not simply data transfer and formatting would be performed at the TMC. GOOGLE1004, 88, 215. TravTek s disclosure is similar to that of the 783 patent, which describes that GPS signals received from sample vehicles (Unit 1) are utilized for processing statistical database times (Unit 2) and current travel times (Unit 3). GOOGLE1001, 10:55-58, 11:4-9. In this first example, the TMC Host Computer illustrated in TravTek s Figure 22 discloses the recited computing system. GOOGLE1004, 67. This TMC computing system is operatively connected to a radio communications system. GOOGLE1004, 66 ( [t]he TMC Communicated to 26

32 and from the vehicles via a Motorola data radio system ), 74; see 28-45; GOOGLE1003, 74. In a second example, TravTek s computer system that processes link travel times and transforms those travel times to ratios discloses this feature: [L]ink travel times were encoded as 1 of 32 ratios. The ratios were calculated in the TMC data base computer as: (Current link time) / (Free flow link time). GOOGLE1004, 63; see 95 (combining travel times to create historical travel times). TravTek s travel times were expressed as a ratio with respect to a reference time, where the reference times... generally corresponded to the speed limit. GOOGLE1004, 150, 63. This transformation of GPS data (travel times) is similar to that set forth in the 783 patent, which describes how obtained empirical, or regular, travel times are averaged, transformed into empirical speed coefficients and stored in the central database. GOOGLE1001, 11: The 783 patent s speed coefficients represent a fraction of the maximum allowed travel speed. GOOGLE1001, 9:48-52; GOOGLE1003, 75. [4.5] a database suitable for storing and updating statistical data on traffic loads on individual roads; Regarding the functional/intended use recitation suitable for, multiple of TravTek s databases are plainly suitable for achieving this function (under the BRI standard) and indeed actually performed this function. Thus, to the extent that 27

33 this recitation is entitled to patentable weight (which it is not because it is nonfunctional descriptive material in a system claim), 2 TravTek in view of Smith discloses multiple databases suitable for storing such statistical data, as discussed below. GOOGLE1003, In a first example, the storing and updating of statistical data on traffic loads on individual roads is disclosed by TravTek storing and updating vehicle travel times for each link. TravTek s system includes an in-vehicle historical data base of link travel times that was updated by dynamic link travel times broadcast from the TMC. GOOGLE1004, 22. In the centralized architecture, this database would be stored server-side, because TravTek explains that Link travel times would Remain at TMC for route calculation. GOOGLE1004, 215, see also ( centralized data bases are easier to manage. ); GOOGLE1003, In a second example, the storing and updating of statistical data is disclosed by TravTek s discussion that [t]he initial set of minimum link travel times in the reference data base were then augmented by a series of travel time runs over major thoroughfares, which established the historical data base. GOOGLE1004, ; see analysis of element [4.7]. These databases would be stored server-side, as discussed above. GOOGLE1003, Supra, footnote 1. 28

34 [4.6] statistical application for collecting structured GPS data, computing individual statistical travel time estimates (regular times) for predetermined roads, and storing the results; To the extent that the statistical application for recitation is entitled to patentable weight (which it is not because it is non-functional descriptive material in a system claim), 3 TravTek in view of Smith discloses this feature. GOOGLE1003, Regarding collecting structured GPS data, TravTek explains that its centralized computers collect GPS data from probe vehicles (as described supra regarding element [4.4]). GOOGLE1004, 55; see 29-33, 38, 65, 223. TravTek discloses at least two examples of its system computing individual statistical travel time estimates for predetermined roads and storing the results. In a first example, TravTek s TMC computes statistical travel times by combining probe vehicle travel times for various roads. GOOGLE1004, 95, 121; GOOGLE1003, 75 (explaining that an exponential smoothing algorithm includes a function that accesses time-series data and computes a weighted moving average by assigning exponentially decreasing weights over time to generate an estimate. This is similar to an averaging process but with different weights given to each value in the time-series. ). This disclosure is like that in the 783 patent, which explains how vehicle travel times are averaged and stored. 3 Supra, footnote 1. 29

35 GOOGLE1001, 11:60-12:4. In this example, the application that performs the exponential smoothing discloses the recited statistical application. GOOGLE1003, 80. In a second example, TravTek s system compares scores of travel times from various sources (e.g., probe vehicles vs. road sensors) to compute a statistically-preferred travel time estimate. GOOGLE1004, 88. With multiple different sources of travel times, the computing system uses a data fusion process for estimating link travel times. This process assimilated inputs from all relevant sources and chose a winner based on a fuzzy logic algorithm. GOOGLE1004, 230, 126. The application program that executes the data fusion process and its fuzzy logic algorithm discloses the recited statistical application. GOOGLE1004, 31; GOOGLE1003, 80. [4.7] statistical means application for periodical updating of the said statistical data using statistical criteria for determining volumes of data necessary for obtaining valid and reliable estimates; and To the extent that the claimed statistical means application for recitation is entitled to patentable weight (which it is not because it is non-functional descriptive material in a system claim), 4 TravTek in view of Smith shows at least three examples of this application. GOOGLE1003, Supra, footnote 1. 30

36 31 IPR of U.S. Pat. No.: 6,480,783 In a first example, TravTek explains how [a]n exponential smoothing technique was applied to update historical link travel times which were influenced by probe vehicles. GOOGLE1004, 121, 95. As explained by Dr. Braasch, an exponential smoothing function would include a function that accesses time-series data and computes a weighted moving average by assigning exponentially decreasing weights over time to generate an estimate. This process involves use of statistical criteria that are for determining volumes of data necessary for obtaining valid and reliable results. GOOGLE1003, 79. The application performing the exponential smoothing discloses the statistical means application. GOOGLE1003, 85. In a second example, TravTek explains how road segments begin with theoretical travel times, and are then converted to historical travel times once there has been a series of travel time runs: The initial set of minimum link travel times in the reference data base were then augmented by a series of travel time runs over major thoroughfares. This procedure established the historical data base. GOOGLE1004, ; GOOGLE1003, The application that establishes the historical data base discloses the recited statistical means application. GOOGLE1003, In a third example, TravTek explains how the travel times used in route calculations depend on a data fusion process that selects a highest-scoring source of

37 travel times for each link, which discloses updating statistical data (e.g., updating selected travel times for each link) using statistical criteria (e.g., a data fusion process selecting highest-scoring sources). GOOGLE1003, The data fusion process is explained at pages of TravTek. In short, TravTek explains how [o]n any given link in the system, there were a number of competing sources of travel time estimates (e.g., history files, operator inputs, the UTCS system, the FMC, probes, etc.). GOOGLE1004, 126; see The data fusion process selects a highest-scoring source at any given moment, which TravTek illustrates in Figure 62: GOOGLE1004, FIG. 62, 129. This figure shows how, before t1, the only source of information is History data, and thus historical travel times are selected for the 32

38 link. GOOGLE1004, At t1 through t3, Real-Time Sources have been recently received and thus have a higher score than the historical data and are selected over the historical data. Id. At t3, a probe vehicle travel time has been received, and the system uses this travel time until around t4, when its score decays below that for the Real-Time Sources. Id. This selection of travel times discloses that the statistical criteria (the data fusion process) is for determining volumes of data necessary for obtaining valid and reliable estimates, as the claim recites, because the different sources rely on different volumes of data (e.g., the system determines whether to use a travel time from a single probe vehicle, or a historical travel time generated by averaging multiple previous travel times). The application that performs the data fusion discloses the recited statistical means application. GOOGLE1003, [4.8] computational tools for real time traffic jam identification at various locations of the individual roads by utilizing the sample vehicles for measuring time delays, To the extent that the computational tools for recitation is entitled to patentable weight (which it is not because it is non-functional descriptive material in a system claim), 5 TravTek in view of Smith discloses this element. GOOGLE1003, 92. Specifically, TravTek used time delays measured by sample 5 Supra, footnote 1. 33

39 vehicles to compute real-time traffic congestion/jams on the roads. For example, TravTek explains how [t]he vehicle made use of, as well as generated, current (real-time) traffic information. GOOGLE1004, 76. TravTek further notes that [c]ongestion level displays and map color displays in the vehicle were determined both by the types of links represented and the associated ratio, where the ratio is calculated as (Current link time) / (Free flow link time), which represents the time delay with respect to the free flow link time. GOOGLE1004, 44, 20 (identifying link travel times when incidents or unusual traffic conditions occurred. ), 29, 38, 65. TravTek uses this traffic information to compute real time traffic jam identification at various locations of individual roads, as shown by TravTek s disclosure that it provides [c]ongestion level displays and map color displays in the vehicle. GOOGLE1004, 63, 29 (discussing a map with graphic elements highlighted according to the status of each traffic link ). Furthermore, TravTek explains that [w]hen incidents or congestion affected the selected routings, drivers were informed and given the opportunity to accept new routings... which reflected the changed conditions. GOOGLE1004, 22 (emphasis added). TravTek further discloses that the traffic information is used to identify unusual traffic conditions (e.g., traffic jams). GOOGLE1004, 20, 76. In the central architecture embodiment, these computations would have been performed at the TMC. 34