DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the communication filed on . The disposition of claims is as follows:
Pending:
Rejected:
Canceled:
Information Disclosure Statement
Acknowledgement is hereby made of receipt of the Information Disclosure Statement(s) filed by the Applicant listed below:
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. § 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contain(s) subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding Claim 0,
The claim recites “.”
The specification does not provide adequate written description of how . There is no written content as to how or what specific algorithms are performed (i.e. formulas, algorithms, sequence of mathematical steps, process of determination, for example)
To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). In addition, the specification must “demonstrate that the patentee possessed the full scope of the invention recited in [the] claim.” LizardTech, Inc. v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1345 (Fed. Cir. 2005). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019).
At best, the Specification vaguely and generically describes the following:
[0072] In an embodiment, system 500 generally comprises an AI layer 502 and a physical layer 504. In an embodiment, AI layer 502 comprises artificial intelligent software configured to compute optimal steering angles based on current car dynamic state and prior information about the vehicle environment. In an embodiment, physical layer 504 is configured to operate on the vehicle. As described herein, system 500 can include various engines or modules.
[0073] AI layer 502 generally comprises an offline engine 506 and an online engine 508. In an embodiment, offline engine 506 is generally configured to collect and process prior information about the environment of the vehicle. Put another way, offline engine 506 obtains and processes data associated with the question of “what is the environment?” in order to develop an ideal plan for the car, thereby solving the optimal control problem.
[0074] In an embodiment, offline engine 506 generally comprises a mapping module 510, a tire identification module 512, a vehicle identification module 514, and an optimal control module 516. Offline engine 506 takes one or more system goals 518 as input and can be further configured to generate an ideal plan 520 for the vehicle.
See at least: Instant PgPub ¶¶
There is no description of what the steps / procedure actually entail. They are simply treated as black boxes that accept certain inputs () and output an . As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I). In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function."
Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. The specification does not at all describe the steps / procedure involved in which would necessarily involve some calculations or steps that have not been described.
It is noted that this is not an enablement rejection. Applicant’s failure to sufficiently describe how the function is performed; how the result is achieved disclose; or any meaningful structure/algorithm raises questions whether applicant truly had possession of the claimed feature(s) at the time of filing.
Regarding Claim ,
The claim recites “.”
The specification does not provide adequate written description of how . There is no written content as to how or what specific algorithms are performed (i.e. formulas, algorithms, sequence of mathematical steps, process of determination, for example)
To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). In addition, the specification must “demonstrate that the patentee possessed the full scope of the invention recited in [the] claim.” LizardTech, Inc. v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1345 (Fed. Cir. 2005). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019).
At best, the Specification vaguely and generically describes the following:
[0096] Sensor fusion module 524 is configured to synthesize data from a plurality of sensors (e.g. sensors 538). By fusing data from multiple sources, the resulting information has less uncertainty than when these sources are used individually. In an embodiment, sensor fusion module 524 is configured according to a mathematical model of the various sensors and data associated with the vehicle. In an embodiment, sensor fusion module 524 can include a machine learning model trained based on sensors and data associated with the vehicle. In an embodiment, sensor fusion module 524 is configured to implement sensor fusion using Kalman filters or particle filters.
[0097] State estimation module 526 is configured to determine the current state of a complex system of a car based on information from different sensors and vehicle response to control inputs. In an embodiment, state estimation module 526 is configured according to a mathematical model of the possible states relative to sensor data. In an embodiment, state estimation module 526 can include a machine learning model trained based on possible states and associated sensor data.
See at least: Instant PgPub ¶¶
There is no description of what the steps / procedure actually entail. They are simply treated as black boxes that accept certain inputs () and output generated . As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I). In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function."
Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. The specification does not at all describe the steps / procedure involved in which would necessarily involve some calculations or steps that have not been described.
It is noted that this is not an enablement rejection. Applicant’s failure to sufficiently describe how the function is performed; how the result is achieved disclose; or any meaningful structure/algorithm raises questions whether applicant truly had possession of the claimed feature(s) at the time of filing.
Regarding Claim ,
The claim recites “.”
The specification does not provide adequate written description of how . There is no written content as to how or what specific algorithms are performed (i.e. formulas, algorithms, sequence of mathematical steps, process of determination, for example)
To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). In addition, the specification must “demonstrate that the patentee possessed the full scope of the invention recited in [the] claim.” LizardTech, Inc. v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1345 (Fed. Cir. 2005). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019).
At best, the Specification vaguely and generically describes the following:
[0085] System goal 518 comprises one or more goals of vehicle operation. In an embodiment, system goal 518 comprises a plurality of goals such that vehicle operation can be dynamically updated or changed. For example, from time T0-T1, system goal 518 can be a first goal G1 from the plurality of goals. From time T1-T2 system goal 518 can be a second goal G2 from the plurality of goals. Certain goals from the plurality of goals can be utilized based on vehicle operation. For example, goals can be implemented based on a vehicle's status during the race, including vehicle and environmental data.
[0086] In one example, system goal 518 can be optimal force generation for the fastest cornering. In racing, one of the most important tasks during the race or race qualification is to achieve a minimal lap time. Accordingly, the vehicle should be controlled at its maximum performance and utilize optimally the friction forces generated by tires. Toe angle can be controlled and changed to give maximum grip during the cornering and reduce friction on the straight segments. It is possible to have maximum possible lateral tire force. Accordingly, cornering speed can be increased compared to the static Ackerman steering configuration.
[0087] In another example, system goal 518 can be associated with tire temperature management. During a race, there are some periods when the tires need to be warmed up to achieve the best performance. A tire warm up procedure can be improved with control by changes of toe angle. Thus, it is possible to control tire temperature by changing tire slip angle. For example, it is possible to change toe angle on a straightaway to increase tire temperature. It is also possible to control part of the tire being warmed; toe in for inside, toe-out for inside.
[0088] In another example, system goal 518 can be associated with tire wearing management. During a race it is also important to control tire degradation to provide desirable grip level during the whole race. At some point of the race, tire utilization can be at its maximum. However, sometimes it is important to keep tire utilization lower to keep tires alive during the whole race. Slip angles play a major role in tire wearing degradation. Thus, reducing slip angle reduces tire degradation.
[0089] In another example, system goal 518 can be associated with car stability management through toe control. During a race it is also important to control car stability. For example, on a straight segment and at high speeds, the vehicle could be less responsive, but during turns, sensitivity of the steering should be higher. “Toe in” makes the car more stable (but reduces steering response time and sensitivity). Accordingly, slip angles can reflect small toe-in on a straight and zero toe during cornering.
[0090] In an embodiment, one or more system goals 518 can be utilized to train various models in an “offline” processing portion; for example, offline engine 506 (e.g. as an input to optimal control module 516). In an embodiment, one or more system goals 518 can be further utilized to actively set slip angles in an “online” processing portion; for example, online engine 508 (e.g. as an input to trajectory planning module 532).
See at least: Instant PgPub ¶¶
There is no description of what the steps / procedure actually entail. They are simply treated as black boxes that accept certain inputs () and output an . As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I). In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function."
Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. The specification does not at all describe the steps / procedure involved in which would necessarily involve some calculations or steps that have not been described.
It is noted that this is not an enablement rejection. Applicant’s failure to sufficiently describe how the function is performed; how the result is achieved disclose; or any meaningful structure/algorithm raises questions whether applicant truly had possession of the claimed feature(s) at the time of filing.
Regarding Claim ,
The claim recites “.”
The specification does not provide adequate written description of how . There is no written content as to how or what specific algorithms are performed (i.e. formulas, algorithms, sequence of mathematical steps, process of determination, for example)
To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). In addition, the specification must “demonstrate that the patentee possessed the full scope of the invention recited in [the] claim.” LizardTech, Inc. v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1345 (Fed. Cir. 2005). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019).
At best, the Specification vaguely and generically describes the following:
In an embodiment, driver input 530 can be received as an input to trajectory planning module 532; for example, a steering wheel input. Driver input 530 can include steering wheel actuator measurement of a driver's expectation on what the vehicle should do. In embodiments, trajectory planning module 532 is further configured to execute based on a driver's intention (e.g via driver input 530).
See at least: Instant PgPub ¶¶
There is no description of what the steps / procedure actually entail. They are simply treated as black boxes that accept certain inputs () and output a . As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I). In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function."
Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. The specification does not at all describe the steps / procedure involved in which would necessarily involve some calculations or steps that have not been described.
It is noted that this is not an enablement rejection. Applicant’s failure to sufficiently describe how the function is performed; how the result is achieved disclose; or any meaningful structure/algorithm raises questions whether applicant truly had possession of the claimed feature(s) at the time of filing.
Regarding Claim ,
The claim recites “.”
The specification does not provide adequate written description of how . There is no written content as to how or what specific algorithms are performed (i.e. formulas, algorithms, sequence of mathematical steps, process of determination, for example)
To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). In addition, the specification must “demonstrate that the patentee possessed the full scope of the invention recited in [the] claim.” LizardTech, Inc. v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1345 (Fed. Cir. 2005). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019).
At best, the Specification vaguely and generically describes the following:
[0074] In an embodiment, offline engine 506 generally comprises a mapping module 510, a tire identification module 512, a vehicle identification module 514, and an optimal control module 516. Offline engine 506 takes one or more system goals 518 as input and can be further configured to generate an ideal plan 520 for the vehicle.
[0075] Mapping module 510 is configured for generating, retrieving, and/or storing information about the environment map in which vehicle is placed. In an embodiment, mapping module 510 can determine on environmental parameters including track configuration, left and right track borders, surface properties (e.g. three-dimensional track surface properties, type of surface, coefficient of friction), track surface angles: roll, pitch, yaw of racing line, and road surface types. In a particular embodiment, mapping module 510 can include track configuration data (e.g. the shape, length, width, etc. of the track) and track friction data (e.g. data capturing the particular interface between the vehicle and the surface of the track). In an embodiment, mapping module 510 is configured to include or interface with sources of information including a GPS map, drone photographs, or other AI to obtain environment map data. In an embodiment, mapping module 510 can be operably coupled to a data storage such as a database for storing raw, synthesized, and intermediate environmental data. In an embodiment, mapping module 510 can implement a machine learning model trained on map data. For example, a mapping model can utilize known map data such as similar tracks, similar environments, similar surfaces, etc., in order to predict or otherwise generate mapping data for the specific environment map in which vehicle is placed.
See at least: Instant PgPub ¶¶
There is no description of what the steps / procedure actually entail. They are simply treated as black boxes that accept certain inputs () and output . As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I). In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function."
Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. The specification does not at all describe the steps / procedure involved in which would necessarily involve some calculations or steps that have not been described.
It is noted that this is not an enablement rejection. Applicant’s failure to sufficiently describe how the function is performed; how the result is achieved disclose; or any meaningful structure/algorithm raises questions whether applicant truly had possession of the claimed feature(s) at the time of filing.
Regarding Claim ,
The claim recites “.”
The specification does not provide adequate written description of how . There is no written content as to how or what specific algorithms are performed (i.e. formulas, algorithms, sequence of mathematical steps, process of determination, for example)
To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). In addition, the specification must “demonstrate that the patentee possessed the full scope of the invention recited in [the] claim.” LizardTech, Inc. v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1345 (Fed. Cir. 2005). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019).
At best, the Specification vaguely and generically describes the following:
In an embodiment, trajectory planning module 532 is configured to dynamically update trajectory based on past performance. For example, a machine learning model can be updated with a feedback loop based on how the vehicle has already performed on those map segments. In another example, trajectory planning module 532 can react to environmental conditions (e.g. from sensor fusion module 524). Consider a case in which it is starting to rain proximate the vehicle. Trajectory planning module 532 can adapt to new conditions to account for the new conditions. Accordingly, trajectory planning module 532 can implement continuous trajectory updating.
See at least: Instant PgPub ¶¶
There is no description of what the steps / procedure actually entail. They are simply treated as black boxes that accept certain inputs () and output an . As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I). In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function."
Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. The specification does not at all describe the steps / procedure involved in which would necessarily involve some calculations or steps that have not been described.
It is noted that this is not an enablement rejection. Applicant’s failure to sufficiently describe how the function is performed; how the result is achieved disclose; or any meaningful structure/algorithm raises questions whether applicant truly had possession of the claimed feature(s) at the time of filing.
Regarding Claim ,
The claim recites “operating on existing information associated with the vehicle including generating an ideal plan as a model for the vehicle based on mapping data, tire dynamics data and vehicle dynamics data.”
The specification does not provide adequate written description of how . There is no written content as to how or what specific algorithms are performed (i.e. formulas, algorithms, sequence of mathematical steps, process of determination, for example)
To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). In addition, the specification must “demonstrate that the patentee possessed the full scope of the invention recited in [the] claim.” LizardTech, Inc. v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1345 (Fed. Cir. 2005). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019).
At best, the Specification vaguely and generically describes the following:
[0072] In an embodiment, system 500 generally comprises an AI layer 502 and a physical layer 504. In an embodiment, AI layer 502 comprises artificial intelligent software configured to compute optimal steering angles based on current car dynamic state and prior information about the vehicle environment. In an embodiment, physical layer 504 is configured to operate on the vehicle. As described herein, system 500 can include various engines or modules.
[0073] AI layer 502 generally comprises an offline engine 506 and an online engine 508. In an embodiment, offline engine 506 is generally configured to collect and process prior information about the environment of the vehicle. Put another way, offline engine 506 obtains and processes data associated with the question of “what is the environment?” in order to develop an ideal plan for the car, thereby solving the optimal control problem.
[0074] In an embodiment, offline engine 506 generally comprises a mapping module 510, a tire identification module 512, a vehicle identification module 514, and an optimal control module 516. Offline engine 506 takes one or more system goals 518 as input and can be further configured to generate an ideal plan 520 for the vehicle.
See at least: Instant PgPub ¶¶
There is no description of what the steps / procedure actually entail. They are simply treated as black boxes that accept certain inputs () and output an . As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I). In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function."
Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. The specification does not at all describe the steps / procedure involved in which would necessarily involve some calculations or steps that have not been described.
It is noted that this is not an enablement rejection. Applicant’s failure to sufficiently describe how the function is performed; how the result is achieved disclose; or any meaningful structure/algorithm raises questions whether applicant truly had possession of the claimed feature(s) at the time of filing.
Regarding Claim ,
The claim recites “synthesizing data from the plurality of sensors associated with the vehicle to generate fused data; determining a current state of the vehicle based on the fused data.”
The specification does not provide adequate written description of how . There is no written content as to how or what specific algorithms are performed (i.e. formulas, algorithms, sequence of mathematical steps, process of determination, for example)
To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). In addition, the specification must “demonstrate that the patentee possessed the full scope of the invention recited in [the] claim.” LizardTech, Inc. v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1345 (Fed. Cir. 2005). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019).
At best, the Specification vaguely and generically describes the following:
[0096] Sensor fusion module 524 is configured to synthesize data from a plurality of sensors (e.g. sensors 538). By fusing data from multiple sources, the resulting information has less uncertainty than when these sources are used individually. In an embodiment, sensor fusion module 524 is configured according to a mathematical model of the various sensors and data associated with the vehicle. In an embodiment, sensor fusion module 524 can include a machine learning model trained based on sensors and data associated with the vehicle. In an embodiment, sensor fusion module 524 is configured to implement sensor fusion using Kalman filters or particle filters.
[0097] State estimation module 526 is configured to determine the current state of a complex system of a car based on information from different sensors and vehicle response to control inputs. In an embodiment, state estimation module 526 is configured according to a mathematical model of the possible states relative to sensor data. In an embodiment, state estimation module 526 can include a machine learning model trained based on possible states and associated sensor data.
See at least: Instant PgPub ¶¶
There is no description of what the steps / procedure actually entail. They are simply treated as black boxes that accept certain inputs () and output generated . As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I). In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function."
Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. The specification does not at all describe the steps / procedure involved in which would necessarily involve some calculations or steps that have not been described.
It is noted that this is not an enablement rejection. Applicant’s failure to sufficiently describe how the function is performed; how the result is achieved disclose; or any meaningful structure/algorithm raises questions whether applicant truly had possession of the claimed feature(s) at the time of filing.
Regarding Claim ,
The claim recites “.”
The specification does not provide adequate written description of how . There is no written content as to how or what specific algorithms are performed (i.e. formulas, algorithms, sequence of mathematical steps, process of determination, for example)
To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). In addition, the specification must “demonstrate that the patentee possessed the full scope of the invention recited in [the] claim.” LizardTech, Inc. v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1345 (Fed. Cir. 2005). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019).
To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019).
At best, the Specification vaguely and generically describes the following:
[0085] System goal 518 comprises one or more goals of vehicle operation. In an embodiment, system goal 518 comprises a plurality of goals such that vehicle operation can be dynamically updated or changed. For example, from time T0-T1, system goal 518 can be a first goal G1 from the plurality of goals. From time T1-T2 system goal 518 can be a second goal G2 from the plurality of goals. Certain goals from the plurality of goals can be utilized based on vehicle operation. For example, goals can be implemented based on a vehicle's status during the race, including vehicle and environmental data.
[0086] In one example, system goal 518 can be optimal force generation for the fastest cornering. In racing, one of the most important tasks during the race or race qualification is to achieve a minimal lap time. Accordingly, the vehicle should be controlled at its maximum performance and utilize optimally the friction forces generated by tires. Toe angle can be controlled and changed to give maximum grip during the cornering and reduce friction on the straight segments. It is possible to have maximum possible lateral tire force. Accordingly, cornering speed can be increased compared to the static Ackerman steering configuration.
[0087] In another example, system goal 518 can be associated with tire temperature management. During a race, there are some periods when the tires need to be warmed up to achieve the best performance. A tire warm up procedure can be improved with control by changes of toe angle. Thus, it is possible to control tire temperature by changing tire slip angle. For example, it is possible to change toe angle on a straightaway to increase tire temperature. It is also possible to control part of the tire being warmed; toe in for inside, toe-out for inside.
[0088] In another example, system goal 518 can be associated with tire wearing management. During a race it is also important to control tire degradation to provide desirable grip level during the whole race. At some point of the race, tire utilization can be at its maximum. However, sometimes it is important to keep tire utilization lower to keep tires alive during the whole race. Slip angles play a major role in tire wearing degradation. Thus, reducing slip angle reduces tire degradation.
[0089] In another example, system goal 518 can be associated with car stability management through toe control. During a race it is also important to control car stability. For example, on a straight segment and at high speeds, the vehicle could be less responsive, but during turns, sensitivity of the steering should be higher. “Toe in” makes the car more stable (but reduces steering response time and sensitivity). Accordingly, slip angles can reflect small toe-in on a straight and zero toe during cornering.
[0090] In an embodiment, one or more system goals 518 can be utilized to train various models in an “offline” processing portion; for example, offline engine 506 (e.g. as an input to optimal control module 516). In an embodiment, one or more system goals 518 can be further utilized to actively set slip angles in an “online” processing portion; for example, online engine 508 (e.g. as an input to trajectory planning module 532).
See at least: Instant PgPub ¶¶
There is no description of what the steps / procedure actually entail. They are simply treated as black boxes that accept certain inputs (unspecified) and output an . As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I). In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function."
Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. The specification does not at all describe the steps / procedure involved in which would necessarily involve some calculations or steps that have not been described.
It is noted that this is not an enablement rejection. Applicant’s failure to sufficiently describe how the function is performed; how the result is achieved disclose; or any meaningful structure/algorithm raises questions whether applicant truly had possession of the claimed feature(s) at the time of filing.
Regarding Claim ,
The claim recites “.”
The specification does not provide adequate written description of how . There is no written content as to how or what specific algorithms are performed (i.e. formulas, algorithms, sequence of mathematical steps, process of determination, for example)
To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). In addition, the specification must “demonstrate that the patentee possessed the full scope of the invention recited in [the] claim.” LizardTech, Inc. v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1345 (Fed. Cir. 2005). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019).
At best, the Specification vaguely and generically describes the following:
In an embodiment, driver input 530 can be received as an input to trajectory planning module 532; for example, a steering wheel input. Driver input 530 can include steering wheel actuator measurement of a driver's expectation on what the vehicle should do. In embodiments, trajectory planning module 532 is further configured to execute based on a driver's intention (e.g via driver input 530).
See at least: Instant PgPub ¶¶
There is no description of what the steps / procedure actually entail. They are simply treated as black boxes that accept certain inputs () and output a . As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I). In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function."
Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. The specification does not at all describe the steps / procedure involved in which would necessarily involve some calculations or steps that have not been described.
It is noted that this is not an enablement rejection. Applicant’s failure to sufficiently describe how the function is performed; how the result is achieved disclose; or any meaningful structure/algorithm raises questions whether applicant truly had possession of the claimed feature(s) at the time of filing.
Regarding Claim ,
The claim recites “.”
The specification does not provide adequate written description of how . There is no written content as to how or what specific algorithms are performed (i.e. formulas, algorithms, sequence of mathematical steps, process of determination, for example)
To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). In addition, the specification must “demonstrate that the patentee possessed the full scope of the invention recited in [the] claim.” LizardTech, Inc. v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1345 (Fed. Cir. 2005). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019).
At best, the Specification vaguely and generically describes the following:
[0074] In an embodiment, offline engine 506 generally comprises a mapping module 510, a tire identification module 512, a vehicle identification module 514, and an optimal control module 516. Offline engine 506 takes one or more system goals 518 as input and can be further configured to generate an ideal plan 520 for the vehicle.
[0075] Mapping module 510 is configured for generating, retrieving, and/or storing information about the environment map in which vehicle is placed. In an embodiment, mapping module 510 can determine on environmental parameters including track configuration, left and right track borders, surface properties (e.g. three-dimensional track surface properties, type of surface, coefficient of friction), track surface angles: roll, pitch, yaw of racing line, and road surface types. In a particular embodiment, mapping module 510 can include track configuration data (e.g. the shape, length, width, etc. of the track) and track friction data (e.g. data capturing the particular interface between the vehicle and the surface of the track). In an embodiment, mapping module 510 is configured to include or interface with sources of information including a GPS map, drone photographs, or other AI to obtain environment map data. In an embodiment, mapping module 510 can be operably coupled to a data storage such as a database for storing raw, synthesized, and intermediate environmental data. In an embodiment, mapping module 510 can implement a machine learning model trained on map data. For example, a mapping model can utilize known map data such as similar tracks, similar environments, similar surfaces, etc., in order to predict or otherwise generate mapping data for the specific environment map in which vehicle is placed.
See at least: Instant PgPub ¶¶
There is no description of what the steps / procedure actually entail. They are simply treated as black boxes that accept certain inputs () and output . As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I). In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function."
Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. The specification does not at all describe the steps / procedure involved in which would necessarily involve some calculations or steps that have not been described.
It is noted that this is not an enablement rejection. Applicant’s failure to sufficiently describe how the function is performed; how the result is achieved disclose; or any meaningful structure/algorithm raises questions whether applicant truly had possession of the claimed feature(s) at the time of filing.
Regarding Claim ,
The claim recites “.”
The specification does not provide adequate written description of how . There is no written content as to how or what specific algorithms are performed (i.e. formulas, algorithms, sequence of mathematical steps, process of determination, for example)
To satisfy the written description requirement, the Specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1562–63 (Fed. Cir. 1991). Specifically, to have “possession,” the Specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and show that the inventor actually invented the claimed invention. Id.; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en banc). In addition, the specification must “demonstrate that the patentee possessed the full scope of the invention recited in [the] claim.” LizardTech, Inc. v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1345 (Fed. Cir. 2005). Original claims may fail to satisfy the written description requirement when the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed function. Id. This can occur when the algorithm or steps for performing the computer function are not explained at all or are not explained in sufficient detail. Additionally, it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681–683 (Fed. Cir. 2015); see also Examining Computer-Implemented Functional Claim Limitations for Compliance with 35 U.S.C. § 112, 84 Fed. Reg. 57, 62 (Jan. 7, 2019).
At best, the Specification vaguely and generically describes the following:
In an embodiment, trajectory planning module 532 is configured to dynamically update trajectory based on past performance. For example, a machine learning model can be updated with a feedback loop based on how the vehicle has already performed on those map segments. In another example, trajectory planning module 532 can react to environmental conditions (e.g. from sensor fusion module 524). Consider a case in which it is starting to rain proximate the vehicle. Trajectory planning module 532 can adapt to new conditions to account for the new conditions. Accordingly, trajectory planning module 532 can implement continuous trajectory updating.
See at least: Instant PgPub ¶¶
There is no description of what the steps / procedure actually entail. They are simply treated as black boxes that accept certain inputs () and output an . As noted in the MPEP, “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved” (See MPEP § 2161.01 I). In particular, the MPEP requires description of “an algorithm or steps/procedure taken to perform the function."
Claimed subject matter should be described in the specification in such a manner as to enable one of ordinary skill in the art to make and use the invention. The specification does not at all describe the steps / procedure involved in which would necessarily involve some calculations or steps that have not been described.
It is noted that this is not an enablement rejection. Applicant’s failure to sufficiently describe how the function is performed; how the result is achieved disclose; or any meaningful structure/algorithm raises questions whether applicant truly had possession of the claimed feature(s) at the time of filing.
Regarding Claims ,
The claims ultimately depend from a claim that fails to comply with the written description requirement and is/are rejected for depending therefrom.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims are rejected under 35 U.S.C. 102 as being by (), hereinafter “”.
Regarding Claim ,
disclose:
A system for controlling a vehicle using at least one system goal, the system comprising:
a plurality of sensors configured to detect data associated with the vehicle; See at least ¶¶
an artificial intelligence (AI) subsystem including:
an offline engine configured to operate on existing information associated with the vehicle, the offline engine including an optimal control module configured to generate an ideal plan as a model for the vehicle based on mapping data, tire dynamics data See at least ¶¶0002, ; “It is desirable to provide this controlled utilization of the tire force capacity by expert humans in a driver-assisted vehicle”, and vehicle dynamics data; See at least ¶¶ and
an online engine configured to operate on dynamic data associated with the vehicle, the online engine including:
an identification module configured to determine static and dynamic vehicle parameters during vehicle operation, See at least ¶¶
a sensor fusion module configured to synthesize data from a plurality of sensors associated with the vehicle to generate fused data, See at least ¶¶
a state estimation module configured to determine a current state of the vehicle based on the fused data, See at least ¶¶
a localization module configured to determine a location of the vehicle, See at least ¶¶
a trajectory planning module configured to determine at least one slip angle for a wheel of the vehicle based on the at least one system goal applied to the ideal plan, according to the static and dynamic vehicle parameters during vehicle operation, the current state of the vehicle, and the location of the vehicle, See at least ¶¶ and
a control module configured to generate a command according to the slip angle; See at least ¶¶ and
a steer-by-wire subsystem including an actuator associated with at least one wheel of the vehicle for independent steering control of the at least one wheel and configured to actuate the at least one wheel according to the command. See at least ¶¶
Regarding Claim ,
disclose:
wherein the model is at least one of:
a mathematical model including a set of variables and a set of equations establishing relationships between the variables; or a machine learning model implemented on neural network. See at least ¶¶0049-0065
Regarding Claim ,
disclose:
wherein the trajectory planning module is further configured to receive a driver input as a driver's expectation for the vehicle and calculate the at least one slip angle based on the driver's expectation. See at least ¶¶
Regarding Claim ,
disclose:
A method of controlling a vehicle using at least one system goal, the method comprising:
detecting data associated with the vehicle using a plurality of sensors; See at least ¶¶
operating on existing information associated with the vehicle including generating an ideal plan as a model for the vehicle based on mapping data, tire dynamics data See at least ¶¶0002, ; “It is desirable to provide this controlled utilization of the tire force capacity by expert humans in a driver-assisted vehicle”, and vehicle dynamics data; See at least ¶¶
operating on dynamic data associated with the vehicle including:
determining static and dynamic vehicle parameters during vehicle operation, See at least ¶¶
synthesizing data from the plurality of sensors associated with the vehicle to generate fused data, See at least ¶¶
determining a current state of the vehicle based on the fused data, See at least ¶¶
determining a location of the vehicle, See at least ¶¶
determine at least one slip angle for a wheel of the vehicle based on the at least one system goal applied to the ideal plan, according to the static and dynamic vehicle parameters during vehicle operation, the current state of the vehicle, and the location of the vehicle, See at least ¶¶and
generating a command according to the slip angle; See at least ¶¶ and
actuating at least one wheel according to the command with an actuator associated with the at least one wheel of the vehicle for independent steering control of the at least one wheel. See at least ¶¶
Regarding Claim ,
disclose:
wherein the model is at least one of:
a mathematical model including a set of variables and a set of equations establishing relationships between the variables; or a machine learning model implemented on neural network. See at least ¶¶0049-0065
Regarding Claim ,
disclose:
receiving a driver input as a driver's expectation for the vehicle; and calculating the at least one slip angle based on the driver's expectation. See at least ¶¶
Special Definitions for Claim Language - MPEP § 2111.01(III)-(IV)
No special definitions are seen as present in the specification regarding the language used in the claims. Consequently, the words and phrases of the claims are given the plain meaning to a person of ordinary skill in the art. (See MPEP §§ 2173.01, 2173.05(a), and 2111.01).
If special definitions are present, Applicant should bring them to the attention of the Examiner and the prosecution history in the next response.
To date, Applicant has provided no indication of special definitions.
Terminology
The Examiner notes that the following terms are utilized in Applicant’s specification as follows:
:
In an embodiment, tire identification module 512 can determine tire dynamic model parameters. In one example, data can include the Magic Formula (Pacejka) tire model for the longitudinal force. In an embodiment, tire identification module 512 is configured to include or interface with sources of information including one or more tire manufacturers. For example, tire identification module 512 can be communicatively coupled to networked sources of information. In an embodiment, tire identification module 512 is configured to implement experiments (ex: tire test stand) to obtain vehicle tire data. In an embodiment, tire identification module 512 is configured to interface with AI configured to determine tire dynamic model parameters. In an embodiment, tire identification module 512 can be operably coupled to a data storage such as a database for storing raw, synthesized, and intermediate tire data. See Instant PgPub: ¶¶
:
Vehicle identification module 514 is configured for generating, retrieving, and/or storing information about the vehicle. In an embodiment, vehicle identification module 514 can determine dynamic model parameters. In one example, data can include vehicle physical dimensions, vehicle mass, vehicle drag coefficient, vehicle aerodynamic downforce, etc. In an embodiment, vehicle identification module 514 is configured to include or interface with sources of information including vehicle manufacturers. For example, vehicle identification module 514 can be communicatively coupled to networked sources of information. In an embodiment, vehicle identification module 514 is configured to implement experiments (ex: aerodynamic tunnel) to obtain vehicle data. In an embodiment, vehicle identification module 514 is configured to interface with AI configured to determine vehicle dynamic model parameters. In an embodiment, vehicle identification module 514 can be operably coupled to a data storage such as a database for storing raw, synthesized, and intermediate vehicle data. See Instant PgPub: ¶¶
:
See Instant PgPub: ¶¶
:
Sensor fusion module 524 is configured to synthesize data from a plurality of sensors (e.g. sensors 538). By fusing data from multiple sources, the resulting information has less uncertainty than when these sources are used individually. In an embodiment, sensor fusion module 524 is configured according to a mathematical model of the various sensors and data associated with the vehicle. In an embodiment, sensor fusion module 524 can include a machine learning model trained based on sensors and data associated with the vehicle. In an embodiment, sensor fusion module 524 is configured to implement sensor fusion using Kalman filters or particle filters. See Instant PgPub: ¶¶
:
See Instant PgPub: ¶¶
:
Optimal control module 516 comprises one or more models configured for solving the optimal control problem. In an embodiment, ideal plan 520 is the model output of optimal control module 516. In an embodiment, optimal control module 516 can include a plurality of dimensions to extract 100% performance of the vehicle. Human limitations of the vehicle are thereby overcome.
The ideal plan can be an optimal control plan based on prior knowledge data 406 as applied to one or more models. In an embodiment, the optimal control plan is implemented as, for example, a neural network or a mathematical model.
See Instant PgPub: ¶¶
:
Mapping module 510 is configured for generating, retrieving, and/or storing information about the environment map in which vehicle is placed. In an embodiment, mapping module 510 can determine on environmental parameters including track configuration, left and right track borders, surface properties (e.g. three-dimensional track surface properties, type of surface, coefficient of friction), track surface angles: roll, pitch, yaw of racing line, and road surface types. In a particular embodiment, mapping module 510 can include track configuration data (e.g. the shape, length, width, etc. of the track) and track friction data (e.g. data capturing the particular interface between the vehicle and the surface of the track). In an embodiment, mapping module 510 is configured to include or interface with sources of information including a GPS map, drone photographs, or other AI to obtain environment map data. In an embodiment, mapping module 510 can be operably coupled to a data storage such as a database for storing raw, synthesized, and intermediate environmental data. In an embodiment, mapping module 510 can implement a machine learning model trained on map data. For example, a mapping model can utilize known map data such as similar tracks, similar environments, similar surfaces, etc., in order to predict or otherwise generate mapping data for the specific environment map in which vehicle is placed. See Instant PgPub: ¶¶
:
System 400 generally comprises an artificial intelligence (AI) subsystem 402 and a steer-by-wire subsystem 404. AI subsystem 402 generally comprises AI algorithms that can implement one or more: first principles models, optimization-based models, machine learning models trained to determine optimal steering angles for implementation on a vehicle by steer-by-wire subsystem 404. More particularly, AI subsystem 402 uses information from different sources (driver steering input, maps, GPS, video cameras, tire pressure sensor, suspension pressure sensor, wheels encoders, temperature sensors, etc.) to compute the optimal steering angle for a given wheel (e,g. each controllable wheel). In an embodiment, AI subsystem 402 is configured to compute optimal steering angles based on current car dynamic state and prior information about the vehicle's environment. In embodiments, an optimal steering angle for a given wheel is determined for various moments in time, including at 1 ms, 2 ms, 3 ms, 4 ms, 5 ms, 10 ms, and so on.. See Instant PgPub: ¶¶
References Cited
R1: ()
Election/Restrictions
Applicant's election with traverse of in the reply filed on is acknowledged. The Examiner notes that Claims have been canceled. Pursuant to the currently pending claims, the restriction has been withdrawn.
Examiner Interviews
Regular Examiner Interview Requests:
Pursuant to USPTO Guidance, one Examiner interview per round of prosecution is available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant may call Examiner Reinbold directly at 313-446-6607 (preferred) or use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Logan Kraft, can be reached on 571-270-5065. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Additional Examiner Interview Requests:
If Applicant needs more than one Examiner interview during a single round of prosecution, applicant may request approval for additional examiner interview(s) from Examiner Reinbold’s Supervisory Patent Examiner (SPE), Logan Kraft, who can be reached at 571-270-5065.
Conclusion
The examiner has pointed out particular references contained in the prior art of record in the body of this action for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. Applicant should consider the entirety of identified prior art references as applicable as to the limitations of the claims. It is noted that any citations to specific pages, paragraph numbers, columns, lines, or figures in the prior art references presented and any interpretation of the reference should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. See MPEP § 2123. It is respectfully requested from the applicant, in preparing the response, to consider fully the entire references as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT A REINBOLD whose telephone number is (313)446-6607. The examiner can normally be reached on MON - FRI: 8AM - 5PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Logan Kraft, can be reached on (571)270-5065. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/SCOTT A REINBOLD/Primary Examiner, Art Unit 3747