DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on September 3, 2025 has been entered.
Response to Arguments
The amendment filed September 3, 2025 has been entered with the RCE filed on the same day. Claims 13 and 17 have been amended. The remaining claims are in original or previously presented form. Therefore, claims 1-20 are pending in the application. Claims 1, 13, and 17 are the independent claims.
The applicant’s Remarks, filed September 3, 2025, has been fully considered. The applicant makes a number of arguments which will be taken in order. The applicant is responding to the last detailed action, which was the Final Rejection dated March 3, 2025. The application argues on page 6 that “The Office Action equates the recited ‘virtual rail’ with Hansen et al’s fixed route between various stations.” The applicant argues that “In the context of Hansen’s disclosure, Hansen’s shuttle’s processing arrangement does not deviate from a virtual rail; rather, a remote computer calculates a new route and sends the shuttle the new route to follow.”
The examiner respectfully does not find this argument persuasive. As cited in the last detailed action Hansen et al. (US2019/0156254 A1) teaches in paragraph 0051 a system in which “one or more of the shuttles run on a fixed route between various stations”. Paragraph 0051 also teaches a system in which “one or more of the shuttles run on a fixed route between various stations”. Yet this “fixed route” is still flexible. Paragraph further teaches 0085 a system that has “knowledge of fixed route schedules” yet can “provide integration between fixed route systems (which run on a loop, or a fixed schedule) and a dynamic transportation network, matching schedule times with dynamic pick-ups and drop-offs.” According to paragraph 0051, the system schedules in “buffer times 328” which includes “time for re-routing to other stations (e.g., in a fixed route model) to increase system efficiency…or…to account for traffic or other unexpected delays”. See paragraph 0046 in which a shuttle is on an assigned route provided by the shuttle assignment module 304. This module can update the shuttle route information 332 based on a change to at least one shuttle reservation request 318. This may thereby “modify previously transmitted shuttle route information 324”. By using terms such as “modify” to refer to changes to a “fixed route,” Hansen implies deviating from a fixed route (analogous to deviating from a virtual rail); rather than generating a new route and sending it to the shuttle.
Furthermore, Hansen, paragraph 0056, teaching that the system “may perform shuttle selection and/or route assignment based on weather conditions, traffic conditions, and/or fixed route transportation state information associated with the geographic region 414 encompassing the pick-up location (and, in some instances, additionally, or alternatively, encompassing the destination location).” See paragraph 0071 and Fig. 6 for a shuttle that makes the rounds according to table 603 in Fig. 6, which the shuttle stops at the stations A-D according to an earliest arrival time and last arrival time, seen in the center and right column of the table, respectively. See paragraph 0075 for, based on a shuttle stop request the system “decides to add the stop to the end of the route”. See paragraph 0076 for another reservation, in response to which, the system “decides to re-route the shuttle and add a stop at F between station C and station D”. So according to paragraph 0085, the system has “knowledge of fixed route schedule” yet can “provide integration between fixed route systems (which run on a loop, or a fixed schedule) and a dynamic transportation network, matching schedule times with dynamic pick-ups and drop-offs.” See paragraph 0090 for the “autonomous…shuttles” that “follow predetermined routes and make predetermined stops.” The system can add or remove stops along its flexible route. These stops are at known stations with known arrival times, according to paragraph 0071 and Fig. 6. The system can adjust to “‘trouble’ locations” and can adjust to time of day, weather, and other factors, according to paragraphs 0094-0095. The system includes campus shuttles. Considering that the system already knows the stops, and then choses to add or subtract them based on requests, schedules, or other issues such as weather and traffic, means that the system does not generate wholly new routes but rather deviates from what present claim 1 calls a “virtual rail.”
Also, as discussed in the “Response to Arguments” section of the last detailed action, MacNeille et al. (US2021/0088341 A1) is also a very strong reference in teaching a shuttle that deviates from a virtual rail when necessary.
The applicant further argues in the Remarks, on the bottom of page 6 and top of page 7, that Hansen uses “a remote computer” to calculate routes and that “Hansen’s ‘shuttle assignment module’ 304 is part of a centralized shuttle management computing device”. The system in Hansen, the applicant argues “acts more like a dispatcher that dispatches all of the different shuttles in the shuttle fleet 104.” The applicant continues that argument by stating that “In contrast, applicant’s disclosed example embodiment provide, on board the shuttle itself” a processing system including a CPU and GPU “which provide the shuttle with significantly higher/different capability than Hansen’s just-follow-instructions shuttle.” The applicant cites the present disclosure, paragraphs 0030 and 0343 for support. Paragraph 0343 teaches an AI supercomputer 100 that detects obstacles and can cause the shuttle to deviate from the rail. Furthermore, lane lines, poles, and pedestrians can “justify a departure from the rail”.
The applicant states regarding this CPU and GPU and hardware accelerator that “The Office Action does not rely on Nix for the missing teaching.” The examiner is not sure he understands the applicant correctly here, but the last detailed action did rely on Nix et al. (U.S. 10,768,621 B1) to teach claim 1’s recitation of:
a processing arrangement comprising
at least one hardware accelerator, and at least one graphics processing unit (GPU) communicatively coupled to the sensors.
As the examiner wrote: “see [Nix] Fig. 3 and col. 14, lines 34-49 for a processor 304 for a CPU and GPU. See col. 14, lines 58 and 62 for component 310, which is connected to the processor, including a sensor. See col. 14, lines 19-23 for device 300 shown in Fig. 3 corresponding to device 106. See Fig. 2 for device 106 being the “vehicle computing system” and including a “perception system 210, which according to col. 12, lines 10-26, includes lidar, cameras, and other sensors. These references show that the GPU is connected to sensors. See also in particular, Nix. col. 14, lines 38-40, for a processor with a GPU and “accelerated processing unit (APU), etc.” Here a CPU, GPU, and APU are all taught. An APU generally contains a hardware accelerator, and meets this limitation.
The examiner is here attaching below a copy of Nix, Fig. 3 as figure 1 of this detailed action. Nix Fig. 3 shows a processor 304. Nix col. 14, lines 34-49 states that processor 304 “includes a…CPU…a…GPU…and/or any processing component” including an APU. See col. 14, lines 58 and 62 for component 310, which is connected to the processor, including a sensor. The parts in Fig. 3, including the CPU, GPU, and accelerator, are all part of device 300. See col. 14, lines 19-23 for device 300 corresponding to device 106. See Fig. 2 for device 106 being the “vehicle computing system”. Therefore the CPU, GPU, and accelerator, and sensors are all onboard the vehicle, thus meeting the present limitation. The sensors include a “perception system 210, which according to col. 12, lines 10-26, includes lidar, cameras, and other sensors. These references show that the GPU is connected to sensors and is onboard the vehicle.
PNG
media_image1.png
754
1096
media_image1.png
Greyscale
Figure 1 - Fig. 3 of Nix (U.S. 10,768,621 B1)
The applicant further argues in the Remarks on page 9 that MacNeille also does not teach what Hansen was cited as teaching. The examiner respectfully disagrees for the reasons given in the last detailed action, but notes that MacNeille was not cited in the claim rejections of claim 1. The applicant seems to argue that if Hansen teaches a centralized server then it cannot also teaching deviating from the virtual rail using the GPU and other components that exist onboard the shuttle, as cited in Nix. The examiner respectfully disagrees. Hansen (see paragraph 0009) and Nix both teach autonomous vehicles. At least the vehicle in Nix can detect other vehicles and pedestrians and contextualize these obstacles within map data, according to col. 12, lines 59-67. The system then tracks these obstacles and then determines whether “Deviating from the motion plan to avoid a collision with an object” is a good idea. This is done using the onboard sensors.
This obstacle avoidance in Nix can also reasonably meet the present limitation about deviating from a virtual rail when conditions exist to do so. In the present filed specification, paragraph 00343 teaches that the shuttle “is able to deviate from the base rail based on changing road conditions and dynamic objects. For example, software running on AI supercomputer (100) detects obstacles such as pedestrians, car, structs, bikes, or other dynamic objects, the shuttle (50) may deviate from the rail.” Curbs can also cause a deviation. Nix teaches this. A POSITA at the time of the application’s filing would understand that autonomous vehicles generally perform obstacle avoidance using on-board sensors and controllers, as evidenced by the disclosure of Nix. The examiner does not think that a POSITA would read the phrase “autonomous vehicle” in paragraph 0009 of Hansen and, considering the general context of the high-tech vehicle in Hansen, think that the vehicle in Hansen does not have the ability to deviate from the motion plan to avoid a collision with an object. Nix simply makes this capability explicit. To the degree that deviating from a virtual rail means avoiding obstacles, at least Nix teaches this.
Regarding claims 2 and 4, the applicant argues in the Remarks starting on the bottom of 9 that although Hansen teaches changing a route based on weather, the end result is to deliver a different route to the shuttle for the shuttle to follow. In contrast, present claim 2 recites that the system can change conditions based on dynamic detection of objects.
It seems to the examiner that one of the main arguments the applicant is trying to make is that the shuttle in the present disclosure contains on the vehicle itself everything needed to generate a virtual rail and deviate from it. All of this equipment including sensors and computers are installed on-board the shuttle itself. To support this idea, the applicant heavily relies on Fig. 33 and paragraphs 0030 and 00343 of the present specification. As previously mentioned, paragraph 00343 teaches that the shuttle “is able to deviate from the base rail based on changing road conditions and dynamic objects. For example, software running on AI supercomputer (100) detects obstacles such as pedestrians, car, structs, bikes, or other dynamic objects, the shuttle (50) may deviate from the rail.”
To what extent does the specification and claims teach that the shuttle can generate and deviate from a virtual rail without the help from the cloud? Present claim 5 recites that the “machine learning component” of claim 1 “receives information concerning the virtual rail from…[an]other source.” That is a huge addition to the system. Its importance can hardly be understated. The applicant argues that Hansen uses a cloud-based system to receive information concerning the virtual rail, but then claims that very idea in claim 5. The applicant argues that Hansen uses a centralized dispatcher, yet the present disclosure in Fig. 2A shows centralized “AI Dispatch,” though this could admittedly by just one embodiment. Yet the overall disclosure is generally aimed at such a system and claim 5 teaches such a system. The independent method claim of claim 13 recites performing operations comprising defining a virtual rail and using the cloud is nowhere excluded.
Independent claim 17 along with claims 17-20 will be discussed here as well as in a separate 35 USC 112(b) rejection. Claim 17 begins by defining “A control system for a shuttle” and teaches that “a control system on the shuttle comprising” a GPU capable of “defining a virtual rail comprising a predefined route and one or more stopping points” and also capable of “deviation from the virtual rail”. The last claim in this group, claim 20, notes that the shuttle can be used with “on-demand transportation or ride-sharing service.” This is not as big of an inclusion as claim 5.
Does such as system as defined in claims 17-20 have written description? Paragraph 0030 of the present disclosure teaches that “the vehicle may be trained on a virtual rail by a human driver and/or receive information concerning the virtual rail definition from another vehicle or other source. However, in some embodiments it is desirable for the vehicle to calibrate, explore/discover, and map its own virtual rail”. This does support the claim that the system can develop its own virtual rail because the paragraph teaches that the vehicle itself can “discover, and map its own virtual rail.” The paragraph also teaches that “The vehicle may generate the virtual rail itself based on stored, previous routes it has followed in the past.” This sentence only somewhat supports the concept of a self-contained rail-developing shuttle, mostly supporting the idea that the route can be predefined. In some ways this supports the idea that a shuttle has a pre-defined route programmed into it by an engineer and then the shuttle can perform obstacle avoidance when needed. Paragraph 0031 teaches that “In other embodiments, the shuttle dynamically develops a ‘virtual rail’ by performing a high definition dynamic mapping process while surveying the environment.” This supports the idea of the shuttle itself generating the virtual rail.
Other sections of the disclosure support claiming a system that uses cloud-based technology for developing the virtual rail. Paragraph 00117, citing Figs. 1A-1C, teach that “systems may develop a virtual rail, or such a virtual rail may be predefined for the vehicle.” Here the word “systems” is not defined and can reasonably be referring to cloud-based systems. Paragraph 00124 teaches that “Once the mapping process generates a high definition map, the vehicle may use the dynamic map to perform route planning within the environment. The example non-limiting embodiment plots a ‘rail’ and navigates the vehicle along the virtual rail will ensuring the vehicle does not collide with any dynamic objects.” Overall, the strongest support the examiner can find in the disclosure for claims 17-20 is paragraph 0030 where it recites that “the vehicle…[can] discover, and map its own virtual rail” and paragraph 00124 where it recites that “the vehicle…plots a ‘rail’ and navigates the vehicle along the virtual rail will ensuring the vehicle does not collide with any dynamic objects.”
Overall, the examiner thinks that claims 17-20 have written description as interpreted in the USC 112(b) section below.
Returning to the discussion of claims 2 and 4, the examiner thinks that Hansen teaches a central computer that generates the virtual rail. So does present claim 5 because the system in claim 5 “receives information concerning the virtual rail from another vehicle or other source.” So the system in claims 1-12 the inclusion of some “other source” reasonably means a centralized cloud-based dispatch and route-generation system.
The examiner also thinks that the conditions for deviating from the virtual rail in the present disclosure, as recited in present claim 2, such as “changing environment conditions or dynamic detection of objects” are common reasons for deviating from a planned path in the autonomous vehicle art.
Present claim 1 now recites:
A shuttle comprising:
a body comprising a compartment to accommodate at least one passenger;
a propulsion, drive train, and steering system to propel the body;
sensors disposed on the body including
at least one light detection and ranging (LIDAR) sensor,
at least one camera, and
at least one global positioning system (GPS) sensor; and
a processing arrangement comprising
at least one central processing unit (CPU),
at least one hardware accelerator, and
at least one graphics processing unit (GPU) communicatively coupled to the sensors,
the processing arrangement to:
define a virtual rail comprising a predefined route and one or more stopping points;
control the propulsion, drive train, and steering system to propel the body along at least one of the virtual rail or a deviation from the virtual rail, the deviation from the virtual rail being used when one or more conditions are satisfied;
identify passengers to ride in the shuttle; and
selectively stop the shuttle at individual stopping points of the one or more stopping points to at least one of take on or discharge passengers.
In the present disclosure “a predefined route” is a route that is defined ahead of time and has “one or more stopping points.” The examiner notes that there is a difference between a virtual rail with just one stopping point and a regular autonomous vehicle traveling to its single destination. A virtual rail is a route that a vehicle travels back and forth on, or around and around on. The vehicle deviates from this route when it needs to avoid an obstacle but otherwise does not. Occasionally, map data or changes to lanes can cause an update to a virtual rail, but this does not happen on every trip. A virtual rail is generally a route in which the passengers go to meet the vehicle not the other way around. The shuttle expects to make the same trip along the virtual rail basically all the time. In the present filed specification, paragraph 0030 teaches that the shuttle “may follow a predefined route, which may be termed a ‘virtual rail’.” The idea is like a campus shuttle that travels on a set route but can drive around obstacles. The paragraph cites figure 33. Figure 33 teaches a “base rail” at the base. But the main point is that claim 5 allows the entire system as defined in claims 1-12 to include a cloud computer.
The applicant argues in the Remarks at the bottom of page 9 in regards to claim 4 that the system of Hansen “does not ‘know’ whether it has followed a particular route in the past” therefore Hansen does not teach claim 4. The examiner is respectfully not persuaded by this argument. Claim 4 teaches that a virtual rail is based on “stored” routes not knowing whether it has followed a particular route in the past. Hansen, as cited in the rejection, teaches that the shuttle uses a “fixed route” and Fig. 6 showed route tables. So in Hansen, the previous route is stored. The system can be flexible though. This meets the limitation.
The applicant argues in the Remarks regarding claim 5 at the top of page 10 that the selection of canonical routes in Nix cannot be combined with the centralized dispatch system of Hansen. The examiner gave as motivation to combine in claim 5 “to detect the environment, identify a route for traveling, and navigate the route, as recognized by Nix (see col. 1, lines 22-27).” In Nix, col. 16, lines 20-34, the “service system 102 and/or vehicle computing system 106 receive request data from user device 108” which is a “request to modify a current canonical route”. The vehicle can then alter the route. Hansen teaches much the same system in which riders can ask for riders from particular stops. The shuttle might not have been planning on stopping at the stop, but since there is a passenger there, the shuttle can try to squeeze the stop in to its regular route and still stay on schedule. Those are very similar ideas. The examiner thinks the combination is valid.
The applicant disputes the rejection of claim 6. The examiner is respectfully not persuaded. The applicant argues that Nix does not use “a high-definition dynamic mapping process.” Whether or not that is true, it is not found in claim 6.
The applicant disputes the rejection of claim 7. The examiner is respectfully not persuaded. The applicant argues that Nix does not teach updating the virtual rail based on changes to the environment. In paragraph 00121 of the present disclosure, it teaches that the mapping related to predetermined route can be updated as needed, because “some mapped features may change day by day or even minute by minute (e.g., a procession of pedestrians walking across a crosswalk to and from the cafeteria only at certain times of day) whereas other such features (e.g., buildings, trees, etc) will remain relatively constant”. Paragraph 0030 teaches that the system can “update a predefined virtual rail (if necessary, to take environmental changes into account)” but what those changes are is not defined here. If the applicant wants to claim that road changes or lane line changes can be detected and impact the virtual route, that will have to be claimed more precisely and shown where written description exists. The examiner does not known right now whether or not that is in the prior art.
The applicant disputes the rejection of claim 9. The examiner is respectfully not persuaded. The applicant argues that the stopping in Hansen is “not made by a processing arrangement on the shuttle”. But as previously discussed, claim 5 allows cloud-based route generation.
The applicant disputes the rejection of claim 10. The examiner is respectfully not persuaded. The applicant argues that Singh “may mention a security layer but not of the applied references appear to specifically disclose a ‘hardware computer vision accelerator’ on a shuttle as claimed.” The examiner cited Nix as teaching a computer vision accelerator. The examiner wrote “see Nix see col. 14, line 40 for a GPU. Nix also teaches here a GPU and accelerated processing unit (APU).” A GPU is a computer vision accelerator. GPUs are used by autonomous vehicles to process the extensive camera data streaming into the system.
In summary, the examiner maintains the rejections of claims 1-16 for the reasons given above. The examiner has issued non-art rejections for claims 17-20. Please see the rejections below.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 17-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claims 17-20 are rejected because claim 17 is not distinctly claimed.
Claim 17 currently recites:
A control system for a shuttle comprising
a propulsion, drive train, and steering system to propel the shuttle, and
sensors disposed on the shuttle including
at least one light detection and ranging (LIDAR) sensor,
at least one camera, and
at least one global positioning system (GPS) sensor,
a control system on the shuttle comprising
at least one central processing unit (CPU),
at least one hardware accelerator, and
at least one graphics processing unit (GPU) communicatively coupled to the sensors,
the control system performing operations comprising:
defining a virtual rail comprising a predefined route and one or more stopping points;
controlling the propulsion, drive train, and steering system to propel the shuttle along at least one of the virtual rail or a deviation from the virtual rail, the deviation from the virtual rail being used when one or more conditions are satisfied;
identify passengers to ride in the shuttle; and
selectively stopping the shuttle at individual stopping points of the one or more stopping points to at least one of take on or discharge passengers.
On the one had the claim recites “A control system for a shuttle” and on the other hand the claim later recites “a control system on the shuttle”. These could potentially be different. “For a shuttle” could include a cloud that is used for a shuttle. Later the claim recites: “the control system performing operations comprising”. Which of the two control systems is this referring to? Should this last clause be interpreted as: “the control system [on the shuttle] performing operations comprising”?
For examination purposes, the clause in question will be interpreted as follows, with the examiner’s addition in bold: “the control system [on the shuttle] performing operations comprising:”
The rest of the claims do not recite a cloud-based routing system. Therefore, the embodiment being claimed in claims 17-20 is the one described in the following paragraphs of the present disclosure: paragraph 0030 where it recites that “the vehicle…[can] discover, and map its own virtual rail,” and paragraph 00124 where it recites that “the vehicle…plots a ‘rail’ and navigates the vehicle along the virtual rail will ensuring the vehicle does not collide with any dynamic objects.” Claim 20 states that the shuttle claimed in claim 17 can be used with a ride-hailing system. The claim actually is defining the type of vehicle that works with claim 17. Claim 20 recites in its entirety: “The control system of claim 17, wherein the shuttle comprises a van, a bus, a robo- taxi, a sedan, a limousine, or any vehicle able to be adapted for on-demand transportation or ride- sharing service.” The vehicle defined in claim 20 can be “able to be adapted to on-demand transportation or ride- sharing service”. The vehicle in claim 17 therefore could be one that allows for recognizing on-demand “hailing gestures,” such as those described in paragraph 00128 of the present spec. These gestures be used to request a ride from the shuttle. The examiner thinks that the kiosks described in the present disclosure probably need a cloud computer to operate and are therefore excluded from claim 17. Claim 20 can also be read as stating that the vehicle of claim 20 is not a motorcycle or e-scooter because those are not “adapted to…ride-sharing” because they are too small. Also, they cannot recognize hailing gestures because they do not generally have cameras and GPUs. But claim 20 cannot reasonably open the door to all kinds of centralized AI dispatch. If that were the intention the set of claims would need something akin to current claim 5 and that is specifically not in the claim set of claims 17-20.
The shuttle in claims 17-20 can reasonably drive around, map an area, discover places that look like good shuttle-stop locations, generate a virtual rail that includes those stops, and then drive to stops along the virtual rail once it has defined its virtual rail. The shuttle can deviate from the virtual rail to avoid obstacles, such as pedestrians. After that, the shuttle gets back on its defined virtual rail. The shuttle does not use a central server to process or analyze any of this. It does not use a centralized server to determine where passengers are requesting rides from nor does the shuttle receive commands from a centralized AI dispatch, as in other disclosed embodiments in the present disclosure. In a broad reasonable interpretation, claims 17-20 exclude any and all centralized dispatch or route-generation computers or cloud-based systems. No fleet management central computer is allowed by the claims because, as recited in claim 17, it is the only the “the control system [on the shuttle] performing operations”.
In a second rejection for not being distinctly claimed, claim 17 recites: “defining a virtual rail comprising a predefined route and one or more stopping points”. How can the control system on the shuttle define a virtual rail if the virtual rail is already predefined? In the disclosure, a route, which is synonymous with a virtual rail, can be predefined, the teaching being that an engineer or programmer defines where the shuttle should go and programs that route into the shuttle. Then the shuttle is released to drive that route, for example, around a college campus. This is not an embodiment in which the shuttle discovers its own virtual rail, plots it, and drives along it, as claimed in claims 17-20.
For examination purposes, and incorporate both of the above rejections and interpretations, claim 17 will be interpreted as follows, with the examiner’s deletions in bolded double-strike through and additions in underline and bold and brackets:
A control system for a shuttle comprising
a propulsion, drive train, and steering system to propel the shuttle, and
sensors disposed on the shuttle including
at least one light detection and ranging (LIDAR) sensor,
at least one camera, and
at least one global positioning system (GPS) sensor,
a control system on the shuttle comprising
at least one central processing unit (CPU),
at least one hardware accelerator, and
at least one graphics processing unit (GPU) communicatively coupled to the sensors,
the control system [on the shuttle] performing operations comprising:
defining a virtual rail comprising one or more stopping points;
controlling the propulsion, drive train, and steering system to propel the shuttle along at least one of the virtual rail or a deviation from the virtual rail, the deviation from the virtual rail being used when one or more conditions are satisfied;
identify passengers to ride in the shuttle; and
selectively stopping the shuttle at individual stopping points of the one or more stopping points to at least one of take on or discharge passengers.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-7, 9, and 12-16 are rejected under 35 U.S.C. 103 as being unpatentable over Hansen et al. (US2019/0156254 A1) in view of Nix et al. (U.S. 10,768,621 B1).
Regarding claim 1, Hansen teaches:
A shuttle comprising (see paragraph 0003):
a body comprising a compartment to accommodate at least one passenger (see paragraph 0003 and Fig. 1 item 104);
a propulsion, drive train, and steering system to propel the body (see paragraph 0090);
sensors disposed on the body including
at least one global positioning system (GPS) sensor (see paragraph 0040); and
a processing arrangement comprising
at least one central processing unit (CPU) (see paragraph 0035 and Fig. 1 for a CPU 170),
the processing arrangement to:
define a virtual rail comprising a predefined route and one or more stopping points (see paragraph 0051 for a system in which “one or more of the shuttles run on a fixed route between various stations”. See paragraph 0085 for a system that has “knowledge of fixed route schedules” and can “provide integration between fixed route systems (which run on a loop, or a fixed schedule) and a dynamic transportation network, matching schedule times with dynamic pick-ups and drop-offs.” See paragraph 0090 for the “autonomous…shuttles” that “follow predetermined routes and make predetermined stops.” The starting point is station A, whose minimum and maximum time are the same.);
control the propulsion, drive train, and steering system to propel the body along at least one of the virtual rail or a deviation from the virtual rail, the deviation from the virtual rail being used when one or more conditions are satisfied (see paragraph 0051 for a system in which “one or more of the shuttles run on a fixed route between various stations”. Yet this “fixed route” is still flexible. The system schedules in “buffer times 328” which includes “time for re-routing to other stations (e.g., in a fixed route model) to increase system efficiency…or…to account for traffic or other unexpected delays”. See paragraph 0046 in which a shuttle is on an assigned route provided by the shuttle assignment module 304. This module can update the shuttle route information 332 based on a change to at least one shuttle reservation request 318. This may thereby “modify previously transmitted shuttle route information 324”. See paragraph 0056 for the teaching that “according to some implementations, the system described herein (e.g., as implemented via the computing device 108) may perform shuttle selection and/or route assignment based on weather conditions, traffic conditions, and/or fixed route transportation state information associated with the geographic region 414 encompassing the pick-up location (and, in some instances, additionally, or alternatively, encompassing the destination location).” See paragraph 0071 and Fig. 6 for a shuttle that makes the rounds according to table 603 in Fig. 6, which the shuttle stops at the stations A-D according to an earliest arrival time and last arrival time, seen in the center and right column of the table, respectively. See paragraph 0085 for a system that has “knowledge of fixed route schedule and can “provide integration between fixed route systems (which run on a loop, or a fixed schedule) and a dynamic transportation network, matching schedule times with dynamic pick-ups and drop-offs.” See paragraph 0090 for the “autonomous…shuttles” that “follow predetermined routes and make predetermined stops.” The system can adjust to “ ‘trouble’ locations” and can adjust to time of day, weather, and other factors, according to paragraphs 0094-0095. The system includes campus shuttles.);
identify passengers to ride in the shuttle (see paragraph 0085 for a system that has “knowledge of fixed route schedule and can “provide integration between fixed route systems (which run on a loop, or a fixed schedule) and a dynamic transportation network, matching schedule times with dynamic pick-ups and drop-offs.” See paragraph 0089 for sensors that detect passengers. See paragraph 0031-0032 for identifying passengers using the passenger’s user device.); and
selectively stop the shuttle at individual stopping points of the one or more stopping points to at least one of take on or discharge passengers (see paragraph 0030 for making stops based on instructions. See paragraph 0031 for making stops based on reservations. See paragraph 0070 for receiving shuttle request cancellations. See paragraph 0085 for canceling stops.).
Yet Hansen does not further teach:
sensors disposed on the body including
at least one light detection and ranging (LIDAR) sensor,
at least one camera, and
a processing arrangement comprising
at least one hardware accelerator, and at least one graphics processing unit (GPU) communicatively coupled to the sensors.
However, Nix teaches:
sensors disposed on the body including
at least one light detection and ranging (LIDAR) sensor (see Nix, col. 12, line 15 for lidar.),
at least one camera (see Nix, col. 12, lines 16 for a camera), and
a processing arrangement comprising
at least one hardware accelerator, and at least one graphics processing unit (GPU) communicatively coupled to the sensors (see Fig. 3 and col. 14, lines 34-49 for a processor 304 for a CPU and GPU. See col. 14, lines 58 and 62 for component 310, which is connected to the processor, including a sensor. See col. 14, lines 19-23 for device 300 shown in Fig. 3 corresponding to device 106. See Fig. 2 for device 106 being the “vehicle computing system” and including a “perception system 210, which according to col. 12, lines 10-26, includes lidar, cameras, and other sensors. These references show that the GPU is connected to sensors. See also in particular, Nix. col. 14, lines 38-40, for a processor with a GPU and “accelerated processing unit (APU), etc.))”.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Hansen, to add the additional features of sensors disposed on the body including at least one light detection and ranging (LIDAR) sensor, at least one camera, and a processing arrangement comprising at least one hardware accelerator, and at least one graphics processing unit (GPU) communicatively coupled to the sensors, as taught by Nix. The motivation for doing so would be to detect the environment, identify a route for traveling, and navigate the route, as recognized by Nix (see col. 1, lines 22-27).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 2, Hansen and Nix teach the shuttle of claim 1.
Hansen further teaches:
The shuttle of claim 1, wherein
the one or more conditions include at least one of changing environment conditions or dynamic detection of objects (see paragraph 0056 for the teaching that “the system …may perform shuttle selection and/or route assignment based on weather conditions, traffic conditions, and/or fixed route transportation state information associated with the geographic region 414 encompassing the pick-up location (and, in some instances, additionally, or alternatively, encompassing the destination location).”).
Regarding claim 3, Hansen and Nix teach the shuttle of claim 1.
Yet Hansen does not further teach:
The shuttle of claim 1, wherein
the sensors provide sensor data to the processing arrangement, and the processing arrangement analyzes the sensor data to monitor locations at least one of in front of the body, behind the body, to the left of the body, to the right of the body, above the body, or below the body.
However, Nix teaches:
The shuttle of claim 1, wherein
the sensors provide sensor data to the processing arrangement, and the processing arrangement analyzes the sensor data to monitor locations at least one of
in front of the body, behind the body, to the left of the body, to the right of the body, above the body, or below the body (see col. 12, lines 10-67).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Hansen and Nix, to add the additional features of the sensors provide sensor data to the processing arrangement, and the processing arrangement analyzes the sensor data to monitor locations at least one of in front of the body, behind the body, to the left of the body, to the right of the body, above the body, or below the body, as taught by Nix. The motivation for doing so would be to detect the environment, identify a route for traveling, and navigate the route, as recognized by Nix (see col. 1, lines 22-27).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 4, Hansen and Nix teach the shuttle of claim 1.
Hansen further teaches:
The shuttle of claim 1, wherein
the processing arrangement is further to generate the virtual rail based at least on stored, previous routes the shuttle has followed in the past (see paragraph 0051 for a system in which “one or more of the shuttles run on a fixed route between various stations” See paragraph 0070 for a “fixed route”. See paragraph 0071 and Fig. 6 tables 602 and 604 for a route table, which is essentially a bus route schedule. The system according to paragraph 0080 directs a shuttle to run this route.).
Regarding claim 5, Hansen and Nix teach the shuttle of claim 1.
Yet Hansen does not further teach:
The shuttle of claim 1, wherein
the processing arrangement includes a machine learning component trained on the virtual rail by a human driver and/or which receives information concerning the virtual rail from another vehicle or other source.
However, Nix teaches:
The shuttle of claim 1, wherein
the processing arrangement includes a machine learning component trained on the virtual rail by a human driver and/or which receives information concerning the virtual rail from another vehicle or other source (in the present disclosure, see paragraph 00192 and Fig. 8 for the Ai Dispatch that “determines the routes for each shuttle”.
With that in mind, see Nix col. 13, lines 39-41 for the prediction system using machine learning techniques to make predictions about objects along a route. See col. 17, lines 2-13 for generating a route based on machine learning techniques. See col. 25, lines 2950 for processing routing data to turn it into training data which can be used for making a prediction model for one or more routes. See also col. 16, lines 20-34, the “service system 102 and/or vehicle computing system 106 receive request data from user device 108” which is a “request to modify a current canonical route”.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Hansen and Nix, to add the additional features of a processing arrangement comprising at least one central processing unit (CPU) and at least one graphics processing unit (GPU) connected to the sensors, as taught by Nix. The motivation for doing so would be to detect the environment, identify a route for traveling, and navigate the route, as recognized by Nix (see col. 1, lines 22-27).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 6, Hansen and Nix teach the shuttle of claim 1.
Yet Hansen does not further teach:
The shuttle of claim 1, wherein
the processing arrangement is to use sensor data obtained using the sensors to survey an environment and update the virtual rail based at least on detected changes in the environment.
However, Nix teaches:
The shuttle of claim 1, wherein
the processing arrangement is to use sensor data obtained using the sensors to survey an environment and update the virtual rail based at least on detected changes in the environment (in the present disclosure, paragraph 0030 teaches that the host vehicle can “explore/discover, and map its own virtual rail”. This is the only use of the term “discovery” or “discover” in the discloser as far as the examiner can tell. Based on this paragraph, the phrase “use discovery” will be broadly and reasonably interpreted to mean that the host vehicle can obtain data on its own using its sensors, for example, and that this discovery of the vehicle’s environment can be used to map the virtual rail. With that in mind, see Nix col. 12, lines 59-67).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Hansen and Nix, to add the additional features of the processing arrangement is to use sensor data obtained using the sensors to survey an environment and update the virtual rail based at least on detected changes in the environment, as taught by Nix. The motivation for doing so would be to detect the environment, identify a route for traveling, and navigate the route, as recognized by Nix (see col. 1, lines 22-27).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 7, Hansen and Nix teach the shuttle of claim 1.
Yet Hansen does not further teach:
The shuttle of claim 1, wherein
the processing arrangement is to use sensor data obtained using the sensors to survey an environment and update the virtual rail based at least on detected changes in the environment.
However, Nix teaches:
The shuttle of claim 1, wherein
the processing arrangement is to use sensor data obtained using the sensors to survey an environment and update the virtual rail based at least on detected changes in the environment (see col. 13, lines 42-53. Although the vehicle travels on a canonical route, it can make adjustments based on detected obstacles.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Hansen and Nix, to add the additional features of the processing arrangement is to use sensor data obtained using the sensors to survey an environment and update the virtual rail based at least on detected changes in the environment, as taught by Nix. The motivation for doing so would be to detect the environment, identify a route for traveling, and navigate the route, as recognized by Nix (see col. 1, lines 22-27).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 9, Hansen and Nix teach the shuttle of claim 1.
Hansen further teaches:
The shuttle of claim 1, wherein
the processing arrangement is to stop the shuttle at individual stopping points of the one or more stopping points along the virtual rail in response to passenger or prospective passenger requests (see paragraph 0030 for making stops based on instructions. See paragraph 0031 for making stops based on reservations. See paragraph 0070 for receiving shuttle request cancellations. See paragraph 0085 for canceling stops.).
Regarding claim 12, Hansen and Nix teach the shuttle of claim 1.
Hansen further teaches:
The shuttle of claim 1, wherein
the shuttle comprises a van, a bus, a robo-taxi, a sedan, a limousine, or any vehicle able to be adapted for on-demand transportation or ride-sharing service (see paragraph 0003).
Regarding claim 13, Hansen teaches:
A method of operating a shuttle including (see Fig. 7)
performing, using
at least one central processing unit (CPU) (see paragraph 0035 and Fig. 1 for a CPU 170),
operation