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:
Response to Arguments and Amendments
Applicant's arguments filed have been fully considered. The Examiner proceeds below with a response.
Regarding Claims rejected under 35 U.S.C. § :
Applicant's arguments have been fully considered but they are not persuasive,
Applicant presents the following arguments:
Quite simply, the analogy to the patent in Ariad is not applicable here. The Court in Ariad held that "a vague functional description and an invitation for further research does not constitute written description of a specific inhibitor." Ariad involved biological pathway regulation in a highly unpredictable art and the patentee did not know any operative species at filing. Ariad's patent contained broad genus claims covering "the use of all substances that achieve the desired result of' inhibiting NF-xB activity. Accordingly, Ariad addressed a situation where the specification identified a biological result without disclosing any operative means for achieving that result in an unpredictable art.
The written description requirement is satisfied when the specification reasonably conveys to a person of ordinary skill in the art that the inventor had possession of the claimed subject matter as of the filing date. The test is not whether the specification discloses source code, mathematical formulas, or every implementation detail that could be used to perform a recited function. Rather, the inquiry is whether the disclosure demonstrates possession of the claimed invention.
Here, the specification describes a vehicle-control architecture that includes, among other components, an offline engine, an online engine, identification functionality, sensor fusion functionality, localization functionality, state estimation functionality, trajectory planning functionality, and control functionality. The specification further describes the interactions among these components, the data utilized by these components, and example techniques that may be employed to implement the disclosed functionality. The specification therefore conveys to a person of ordinary skill in the art that Applicant was in possession of the claimed architecture and its associated operations.
In particular, in claim 10 (and with similar reference to claim 21), the Office Action asserts that the limitations "offline engine" and "sensor fusion module" are not supported by the Specification. (Office Action, pp. 3-6.) Applicant respectfully disagrees. In contrast to Ariad, theSpecification describes an offline engine that a POSITA would understand operates in relation to achieving a goal such as minimum lap time by slip angles steering control relative to a racing line, "[i]n 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." (Application as Published, [0086].) "[O]ffline 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." (Application as Published, [0073]; see also [0002], [0060] ("compute optimal steering angles based on current car dynamic state and prior information about the vehicle's environment... an optimal steering angle for a given wheel is determined for various moments in time"), [0075] ("track surface angles: roll, pitch, yaw of racing line"); [0081] ("control the vehicle at future points in time."); [0091], ("offline engine 506 is configured for preparation operations to solve for ideal steering, (e.g. "what should the vehicle do?") in light of future "online" data. In an embodiment, offline engine 506 creates an optimal ideal plan 520 for the car by solving the optimal control problem (e.g. individual steering controls problem)").)
Nevertheless, without waiver or disclaimer, and solely in an effort to further prosecution, claim 10 has been amended to recite, in combination with the other limitations of the claim, with respect to the offline engine, clarifying amendments, "wherein the at least one system goal comprises at least a minimum lap time for the vehicle in a lap around a track and the ideal plan comprises at least a racing line and steering controls for the vehicle to place the vehicle on theracing line throughout the track at future points in time according to a plurality of racing line slip angles" and "a control module configured to generate a command according to the slip angle to update at least one of the plurality of racing line slip angles to the slip angle for at least one of the future points in time." Support can be found throughout the application as filed, including the above-referenced paragraphs.
The Examiner respectfully disagrees.
Although applicant contends " in regards to amended claim limitation: , this is insufficient to satisfy the written description requirement.
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).
Applicant's arguments amount to an assertion that it would be common practice for a person skilled in the art to implement an AI subsystem utilizing and output an
Contrary to Applicant’s assertion, Applicant’s failure to disclose any meaningful structure / algorithm, mathematical formula, complete sequence of operations, or flow chart to sufficiently describe how the claimed function is performed or how the claimed result is achieved raises questions whether applicant truly had possession of the claimed subject matter at the time of filing.
Although a person skilled in the art may arguably have familiarity with some parameters associated with achieving a minimum lap time, such a person would not understand that the Applicant had possession of the claimed invention.
Stated differently, the specification fails to disclose technical implementation of the artificial intelligence implemented in the offline engine sufficient to demonstrated that the inventor was in possession of the claimed invention at the time of filing. The scope of the claimed subject matter fails to disclose type or architecture of the model, training methodology, optimization procedure, learned parameter relationships, weighting or utilization of the claimed factors, inference procedure, or any algorithm by which the claimed result is generated. Absent such information, the specification merely identifies inputs to be supplied to an unspecified AI model while leaving entirely unexplained the mechanism by which the claimed functions are performed.
Absent knowledge of how models are developed, utilized, or how factors are employed with respect to , to achieve an , a person skilled in the art would be faced with a vast amount of inputs, algorithms, model training, and data sets that would confound the process of implementing Applicant's actual invention.
Moreover, Applicant does not direct Examiner to meaningful structure / algorithm, mathematical formula, complete sequence of operations, or flow chart to sufficiently describe how the claimed function is performed or how the claimed result is achieved any language, steps or flow charts in the disclosure to show particular hardware or an algorithm, such that a skilled artisan would understand how to performing the claimed limitation and achieve the result thereof. 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 value. 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.)
Absent from the Specification is any discussion as to the particular steps, i.e., algorithm, necessary to perform the claimed functions. As such, the rejection is maintained as the instant Specification does not disclose sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention. Stated differently, the steps, procedure or algorithm taken to perform the claimed functions are not described in sufficient detail in the instant Specification to demonstrate that the inventor was in possession of that knowledge.
Therefore, the rejection has been maintained.
Regarding Claim rejected under 35 U.S.C. § :
Applicant's arguments have been fully considered and are persuasive in view of the amendments made on 06/03/2026.
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 ,
The claim recites “.”
The specification does not provide adequate written description support for the recited limitation because the Specification fails to disclose sufficient detail such that one of ordinary skill in the art would understand how the inventor intended to perform claimed limitation or achieve the result thereof. In particular, the Specification does not disclose any meaningful algorithm, mathematical formula, sequence of operations, or flow chart to sufficiently describe how the function is performed or the result is achieved.
To satisfy the written description requirement under 35 U.S.C. § 112(a), the Specification must describe the claimed invention in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. 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:
[0065] In an embodiment, system 400 further comprises desired steering data 408. System 400 inputs as desired steering data 408 can include a desired steering angle/desired path curvature, one or more system goals, such as minimum possible time, tire saving, tire warm-up. In an embodiment, and as will be explained further, a goal can be chosen by a system administrator (team manager, car operator, driver etc.). In another embodiment, a goal can be determined by AI subsystem 402 based on one or more: first principles models, optimization-based models, machine learning models trained by prior knowledge data (e.g. a racing strategy with a goal to get the highest position (highest points) in the race).
[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.
[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. Instead, the claimed limitation is set forth as result oriented black box to which inputs are provided and output(s) result as follows:
Inputs:
Outputs: .
As noted in the MPEP § 2161.01 I, “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”. 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 with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended to perform claimed limitation or achieve the result thereof. The specification does not describe the steps / procedure involved in performing the claimed limitation and achieving the result thereof 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 disclose any meaningful structure / algorithm, mathematical formula, complete sequence of operations, or flow chart to sufficiently describe how the claimed function is performed or how the claimed result is achieved raises questions whether applicant truly had possession of the claimed subject matter 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 support for the recited limitation because the Specification fails to disclose sufficient detail such that one of ordinary skill in the art would understand how the inventor intended to perform claimed limitation or achieve the result thereof. In particular, the Specification does not disclose any meaningful algorithm, mathematical formula, sequence of operations, or flow chart to sufficiently describe how the function is performed or the result is achieved.
To satisfy the written description requirement under 35 U.S.C. § 112(a), the Specification must describe the claimed invention in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. 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. Instead, the claimed limitation is set forth as result oriented black box to which inputs are provided and output(s) result as follows:
Inputs:
Outputs: .
As noted in the MPEP § 2161.01 I, “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”. 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 with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended to perform claimed limitation or achieve the result thereof. The specification does not describe the steps / procedure involved in performing the claimed limitation and achieving the result thereof 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 disclose any meaningful structure / algorithm, mathematical formula, complete sequence of operations, or flow chart to sufficiently describe how the claimed function is performed or how the claimed result is achieved raises questions whether applicant truly had possession of the claimed subject matter at the time of filing.
Regarding Claim ,
The claim recites “.”
The specification does not provide adequate written description support for the recited limitation because the Specification fails to disclose sufficient detail such that one of ordinary skill in the art would understand how the inventor intended to perform claimed limitation or achieve the result thereof. In particular, the Specification does not disclose any meaningful algorithm, mathematical formula, sequence of operations, or flow chart to sufficiently describe how the function is performed or the result is achieved.
To satisfy the written description requirement under 35 U.S.C. § 112(a), the Specification must describe the claimed invention in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. 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. Instead, the claimed limitation is set forth as result oriented black box to which inputs are provided and output(s) result as follows:
Inputs:
Outputs: .
As noted in the MPEP § 2161.01 I, “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”. 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 with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended to perform claimed limitation or achieve the result thereof. The specification does not describe the steps / procedure involved in performing the claimed limitation and achieving the result thereof 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 disclose any meaningful structure / algorithm, mathematical formula, complete sequence of operations, or flow chart to sufficiently describe how the claimed function is performed or how the claimed result is achieved raises questions whether applicant truly had possession of the claimed subject matter at the time of filing.
Regarding Claim ,
The claim recites “.”
The specification does not provide adequate written description support for the recited limitation because the Specification fails to disclose sufficient detail such that one of ordinary skill in the art would understand how the inventor intended to perform claimed limitation or achieve the result thereof. In particular, the Specification does not disclose any meaningful algorithm, mathematical formula, sequence of operations, or flow chart to sufficiently describe how the function is performed or the result is achieved.
To satisfy the written description requirement under 35 U.S.C. § 112(a), the Specification must describe the claimed invention in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. 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:
[0065] In an embodiment, system 400 further comprises desired steering data 408. System 400 inputs as desired steering data 408 can include a desired steering angle/desired path curvature, one or more system goals, such as minimum possible time, tire saving, tire warm-up. In an embodiment, and as will be explained further, a goal can be chosen by a system administrator (team manager, car operator, driver etc.). In another embodiment, a goal can be determined by AI subsystem 402 based on one or more: first principles models, optimization-based models, machine learning models trained by prior knowledge data (e.g. a racing strategy with a goal to get the highest position (highest points) in the race).
[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.
[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. Instead, the claimed limitation is set forth as result oriented black box to which inputs are provided and output(s) result as follows:
Inputs:
Outputs: .
As noted in the MPEP § 2161.01 I, “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”. 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 with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended to perform claimed limitation or achieve the result thereof. The specification does not describe the steps / procedure involved in performing the claimed limitation and achieving the result thereof 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 disclose any meaningful structure / algorithm, mathematical formula, complete sequence of operations, or flow chart to sufficiently describe how the claimed function is performed or how the claimed result is achieved raises questions whether applicant truly had possession of the claimed subject matter 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 support for the recited limitation because the Specification fails to disclose sufficient detail such that one of ordinary skill in the art would understand how the inventor intended to perform claimed limitation or achieve the result thereof. In particular, the Specification does not disclose any meaningful algorithm, mathematical formula, sequence of operations, or flow chart to sufficiently describe how the function is performed or the result is achieved.
To satisfy the written description requirement under 35 U.S.C. § 112(a), the Specification must describe the claimed invention in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. 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. Instead, the claimed limitation is set forth as result oriented black box to which inputs are provided and output(s) result as follows:
Inputs:
Outputs: .
As noted in the MPEP § 2161.01 I, “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”. 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 with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended to perform claimed limitation or achieve the result thereof. The specification does not describe the steps / procedure involved in performing the claimed limitation and achieving the result thereof 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 disclose any meaningful structure / algorithm, mathematical formula, complete sequence of operations, or flow chart to sufficiently describe how the claimed function is performed or how the claimed result is achieved raises questions whether applicant truly had possession of the claimed subject matter at the time of filing.
Regarding Claim ,
The claim recites “.”
The specification does not provide adequate written description support for the recited limitation because the Specification fails to disclose sufficient detail such that one of ordinary skill in the art would understand how the inventor intended to perform claimed limitation or achieve the result thereof. In particular, the Specification does not disclose any meaningful algorithm, mathematical formula, sequence of operations, or flow chart to sufficiently describe how the function is performed or the result is achieved.
To satisfy the written description requirement under 35 U.S.C. § 112(a), the Specification must describe the claimed invention in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. 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. Instead, the claimed limitation is set forth as result oriented black box to which inputs are provided and output(s) result as follows:
Inputs:
Outputs: .
As noted in the MPEP § 2161.01 I, “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”. 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 with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended to perform claimed limitation or achieve the result thereof. The specification does not describe the steps / procedure involved in performing the claimed limitation and achieving the result thereof 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 disclose any meaningful structure / algorithm, mathematical formula, complete sequence of operations, or flow chart to sufficiently describe how the claimed function is performed or how the claimed result is achieved raises questions whether applicant truly had possession of the claimed subject matter 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.
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: ¶¶
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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
Prosecution Insights