DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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.
Information Disclosure Statements
The Information Disclosure Statements (IDS) filed on 4/18/2023 and 4/1/2024 have been acknowledged.
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in Japan on 4/18/2023.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant's cooperation is requested in correcting any errors of which applicant may become aware of, in the specification.
Status of Application
Claims 1-9 and 16-21 are pending.
Claims 1, 8, and 9 are independent.
Claims 1-2, 6-9, and 17-19 have been amended.
This Final Office Action is in response to the “Amendments and Remarks” received on 5/14/2026.
Response to Arguments
With respect to applicant’s “Amendments and Remarks or Request for Continued Examination” filed on 5/14/2026: Applicant’s remarks have been fully considered. Applicants remarks will be addressed in the order they were presented.
With respect to the claim rejections on Claims 17-19 under 35 U.S.C. § 112 (a), applicant’s “Amendments and Remarks” have been fully considered and were persuasive. Therefore the rejections under 35 U.S.C. § 112 (a) for Claims 17-19 have been withdrawn.
With respect to the claim rejections on Claims 1-9 and 16-19 under 35 U.S.C. § 112 (b), applicant’s “Amendments and Remarks” have been fully considered and are persuasive. The rejections under 35 U.S.C. § 112 (b) for Claims 1-9 and 16-19 have been withdrawn.
With respect to the claim rejections on Claims 1-9 and 16-21 under 35 U.S.C. § 103, applicant’s “Amendments and Remarks” have been fully considered and were not persuasive.
Applicant remarks “the references, as cited by the rejection and viewed overall, do not reasonably suggest both "generate, based on a learned policy of an own agent and a state transition function, a first optimal route execution plan up to achievement of a destination while considering the route offer as a constraint condition for path coordination" and the Office respectfully disagrees.
First, in response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Second, the claims as currently presented use multiple variables, such as learned policy, state transition function, first optimal route execution plan, with a route offer as the constraint condition for path coordination, yet these terms are extremely broad, thus is creates issues with what applicant intends the metes and bounds of the terms to be and what the office is interpreting them to be. This is the 4th round of prosecution and the Office has repeatedly encouraged applicant to better define these terms, for proper metes and bounds and a better understanding of what applicant is actually attempting to capture.
Further, these terms appear to be the inputs, outputs and naming conventions of algorithms, yet the algorithms, such as the state transition function are not defined, thus any algorithm, that uses the same inputs would read. Again, the Office strongly suggests clarifying the metes and bounds of the terms, stating what exactly the functions are, with their relationships to variables, for clarity and to move prosecution forward.
Here, the Office is interpreting Varma, which as stated previously, does not specifically state learned policy, rather preferences which is a captured policy which can be updated as stating (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences) [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111].
Varma clearly discloses “generate, based on a policy of an own agent and a state transition function, a first optimal route execution plan up to achievement of a destination while considering the route offer as a constraint condition for path coordination”.
Further Redman was introduced to teach the learned policy aspect of the claimed subject matter [Redman, ¶ 0044-0045, 0068, 0075, and 0079-0083]. Therefore the Office respectfully disagrees.
Applicant further remarks “the references, as cited by the rejection and viewed overall, do not reasonably suggest both "generate, based on the learned policy and the state transition function, a second optimal route execution plan up to achievement of the destination without considering the route offer as the constraint condition" and the Office respectfully disagrees.
Again, in response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Further, the claims as currently presented use multiple variables, such as learned policy, state transition function, first optimal route execution plan, second optimal route execution plan, without a route offer as the constraint condition for path coordination, yet these terms are extremely broad, thus is creates issues with what applicant intends the metes and bounds of the terms to be and what the office is interpreting them to be. This is the 4th round of prosecution and the Office has repeatedly encouraged applicant to better define these terms, for proper metes and bounds and a better understanding of what applicant is actually attempting to capture.
Further, these terms appear to be the inputs, outputs and naming conventions of algorithms, yet the algorithms, such as the state transition function are not defined, thus any algorithm, that uses the same inputs would read. Again, the Office strongly suggests clarifying the metes and bounds of the terms, stating what exactly the functions are, with their relationships to variables, for clarity and to move prosecution forward.
Here, the Office is interpreting Varma, which as stated previously, does not specifically state learned policy, rather preferences which is a captured policy which can be updated as stating (“Navigation systems provide users with information about current traffic conditions and suggests optimal routes to achieve either minimal transit time or minimal cost (by way of example, by avoiding tolls” and a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences) [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111].
Varma clearly discloses “generate, based on a policy of an own agent and a state transition function, multiple optimal route execution plans up to achievement of a destination while considering the route offers and not offers, actually a variety as a constraint condition for path coordination”.
Further Redman was introduced to teach the learned policy aspect of the claimed subject matter [Redman, ¶ 0044-0045, 0068, 0075, and 0079-0083]. Therefore the Office respectfully disagrees.
Applicant further remarks “the first route value being a value calculated by a value function for the first optimal route execution plan generated while considering the route offer as the constraint condition" and “utility value based on a difference between a second route value and the first route value” the Office respectfully disagrees.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Again, in response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Further, the claims as currently presented use multiple variables, such as learned policy, state transition function, first optimal route execution plan, second optimal route execution plan, without a route offer as the constraint condition for path coordination, utility values, utility functions, yet these terms are extremely broad, thus is creates issues with what applicant intends the metes and bounds of the terms to be and what the office is interpreting them to be. This is the 4th round of prosecution and the Office has repeatedly encouraged applicant to better define these terms, for proper metes and bounds and a better understanding of what applicant is actually attempting to capture.
Further, these terms appear to be the inputs, outputs and naming conventions of algorithms, yet the algorithms, such as the state transition function, utility function, to name a few, are not defined, thus any algorithm, that uses the same inputs would read. Again, the Office strongly suggests clarifying the metes and bounds of the terms, stating what exactly the functions are, with their relationships to variables, for clarity and to move prosecution forward.
Here, the Office is interpreting Varma, which as stated previously, does not specifically state learned policy, rather preferences which is a captured policy which can be updated as stating (“Navigation systems provide users with information about current traffic conditions and suggests optimal routes to achieve either minimal transit time or minimal cost (by way of example, by avoiding tolls” and a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences) [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111].
Varma clearly discloses “the first route value being a value calculated by a value function for the first optimal route execution plan generated while considering the route offer as the constraint condition" and “utility value based on a difference between a second route value and the first route value” where the routes are compared based on preferences and costs, therefore the Office respectfully disagrees.
Applicant further argues that the other independent claims which recite similar features are allowable and the dependent claims are also allowable since they depend on allowable subject and the Office respectfully disagrees. It is the Office's stance that all of the claimed subject matter has been properly rejected; therefore the Office's respectfully disagrees with applicant’s arguments.
The rejections under 35 U.S.C. § 103 for Claims 1-9 and 16-21 have been remain.
It is the Office’s stance that all of applicant arguments have been considered and the rejections remain.
Final Office Action
CLAIM INTERPRETATION
During examination, claims are given the broadest reasonable interpretation consistent with the specification and limitations in the specification are not read into the claims. See MPEP §2111, MPEP §2111.01 and In re Yamamoto et al., 222 USPQ 934 10 (Fed. Cir. 1984). Under a broadest reasonable interpretation, words of the claim must be given their plain meaning, unless such meaning is inconsistent with the specification. See MPEP 2111.01 (I). It is further noted it is improper to import claim limitations from the specification, i.e., a particular embodiment appearing in the written description may not be read into a claim when the claim language is broader than the embodiment. See 15 MPEP 2111.01 (II).
A first exception to the prohibition of reading limitations from the specification into the claims is when the Applicant for patent has provided a lexicographic definition for the term. See MPEP §2111.01 (IV). Following a review of the claims in view of the specification herein, the Office has found that Applicant has not provided any lexicographic definitions, either expressly or implicitly, for any claim terms or phrases with any reasonable clarity, deliberateness and precision. Accordingly, the Office concludes that Applicant has not acted as his/her own lexicographer.
A second exception to the prohibition of reading limitations from the specification into the claims is when the claimed feature is written as a means-plus-function. See 35 U.S.C. §112(f) and MPEP §2181-2183. As noted in MPEP §2181, a three prong test is used to determine the scope of a means-plus-function limitation in a claim:
the claim limitation uses the term "means" or "step" or a term used as a substitute for "means" that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function
the term "means" or "step" or the generic placeholder is modified by functional language, typically, but not always linked by the transition word "for" (e.g., "means for") or another linking word or phrase, such as "configured to" or "so that"
the term "means" or "step" or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
The Office has found herein that the claims no longer contain limitations of means or means type language that must be analyzed under 35 U.S.C. §112 (f).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims under pre-AIA 35 U.S.C. 103(a), the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were made absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and invention dates of each claim that was not commonly owned at the time a later invention was made in order for the examiner to consider the applicability of pre-AIA 35 U.S.C. 103(c) and potential pre-AIA 35 U.S.C. 102(e), (f) or (g) prior art under pre-AIA 35 U.S.C. 103(a).
Claims 1-2, 4, 6-9, and 16-20 rejected under 35 USC 103 as being unpatentable over Varma et al. (United States Patent Publication 2017/0358025) in view Redman et al. (United States Patent Publication 2018/0293898) and in further view of Williams et al (United States Patent 11,466,998)
With respect to Claim 1: While Varma discloses “A negotiation device for controlling a vehicle comprising” [Varma, ¶ 0018-0022, 0026-0027, 0035-0039, 0083-0085, 0095, 0097-0098, 0102, and 0111 (allow autonomous, semi-autonomous or user-driven cars, with an appropriate application installed, to bid for faster passage for their journeys)];
“a memory storing instructions” [Varma, ¶ 0012-0013 and Figure 2];
“and one or more processors configured to execute the instructions to” [Varma, ¶ 0012-0013 and Figure 2];
“receive, from another vehicle, a route offer including position and time information for path coordination and optionally a consideration” [Varma, ¶ 0018-0022, 0026-0027, 0035-0039, 0083-0085, 0095, 0097-0098, 0102, and 0111 (In addition, the system and method of the present invention offers monetary compensation/credit to lower bidders or to takers willing to reroute through less desired routes thus freeing more desired routes to the benefit of the higher bidders)];
“generate, based on a policy of an own agent and a state transition function, a first optimal route execution plan up to achievement of a destination while considering the route offer as a constraint condition for path coordination, including collision avoidance” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“wherein the first optimal route execution plan comprises a first trajectory including first time-stamped positions” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0083-0085, 0095, 0097-0098, 0102, and 0111 (requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time)];
“obtain a first route value associated with the first optimal route execution plan, the first route value being a value calculated by a value function for the first optimal route execution plan generated while considering the route offer as the constraint condition” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (The user 102 takes the journey and various transponders and sensors in the car and roadway track the user's travel. This information is then communicated back 114 to the computer 108, which then verifies the journey and debits or credits the user's account 120 via billing server 122. Along the way, the computer may also offer 124 to reroute the user if (s)he is willing to pay more for a faster route, or pay less (or even receive a payment) for a slower route. Similarly, the computer could offer 124 the user a payment to pull off the road at a specified spot for a specified time (to reduce congestion)];
“generate, based on the policy and the state transition function, a second optimal route execution plan up to achievement of the destination without considering the route offer as the constraint condition” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“wherein the second optimal route execution plan comprises a second trajectory including second time-stamped positions” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results)];
“evaluate, using a utility function, a utility value based on a difference between a second route value and the first route value, the difference being between the value calculated by the value function for the second optimal route execution plan generated without considering the route offer as the constraint condition and the value calculated by the value function for the first optimal route execution plan generated while considering the route offer as the constraint condition, and optionally including the consideration in the utility value” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (Navigation systems provide users with information about current traffic conditions and suggests optimal routes to achieve either minimal transit time or minimal cost (by way of example, by avoiding tolls)];
“compare the utility value with a threshold value that varies with a negotiation step” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (Navigation systems provide users with information about current traffic conditions and suggests optimal routes to achieve either minimal transit time or minimal cost (by way of example, by avoiding tolls. In accordance with the present invention, users are not passive receivers of traffic information anymore and can influence and change the traffic patterns by bidding to achieve minimal transit time or cost or any desired combination thereof)];
“in response to the comparing, accept or reject the route offer” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, 0111, and Claim 5 (comprising the steps of: selecting a desired travel route; bidding on the desired travel route; and, receiving a decision on whether the desired travel route was awarded)];
“and control the vehicle to cause the vehicle to execute a trajectory of a selected optimal route execution plan consistent with acceptance or rejection of the route offer” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (the bidding system automatically supplies self-driving cars with routes to best-fit said settings and preferences)];
“wherein the one or more processors are further configured to repeat negotiation iterations with the other vehicle until an agreement is reached,” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (the bidding system automatically supplies self-driving cars with routes to best-fit said settings and preferences)];
“wherein the policy comprises a policy function that, in response to an input state of the own agent, outputs an action to be taken by the own agent or a probability distribution over candidate actions” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“wherein the state transition function, in response to the input state and the action, outputs a next state of the own agent or a probability distribution over candidate next states” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results) and (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences)];
“wherein each of the first route value and the second route value represents an expected cumulative reward or cost associated with executing a corresponding one of the first optimal route execution plan and the second optimal route execution plan from a current state of the vehicle toward the destination, and” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (Navigation systems provide users with information about current traffic conditions and suggests optimal routes to achieve either minimal transit time or minimal cost (by way of example, by avoiding tolls)];
“wherein the utility function maps at least the difference between the second route value and the first route value, and optionally the consideration, to the utility value” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (Navigation systems provide users with information about current traffic conditions and suggests optimal routes to achieve either minimal transit time or minimal cost (by way of example, by avoiding tolls)];
Varma does not specifically a learning, rather using preference of the users, destination of users with current location and predicted locations, optimal time (fastest) for routes, optimal cost (cheapest) for routes, or making money for slower routes, contract preferences for offer and bids during the route, total system cost data, total system congestion data and many other functions or Varma does not specifically state displaying the routes on a map.
Redman, which is also a system to avoid collisions with autonomous vehicles teaches “wherein the learned policy comprises a policy function that, in response to an input state of the own agent, outputs an action to be taken by the own agent or a probability distribution over candidate actions” [Redman, ¶ 0044-0045, 0068, 0075, and 0079-0083].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Redman into the invention of Varma to not only include using vehicles with priorities and rules and ways to negotiate paths as Varma discloses but to also policies to control the bidding and offers as taught by Redman with a reasonable expectation of success. One would be motivated to incorporate aspects of the cited prior art Redman into Varma to create a more robust system that allows for vehicles to quickly define routes to destinations. Additionally, the claimed invention is merely a combination of old, well known elements vehicle control based on negotiations and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the results of the combination would have been predictable.
Office Note: The terms Utility Function, policy function, state transition function, value function, are extremely broad as to what is being carried out, what would and would not read on these functions. As being broad is not indefinite, almost any function or mathematical use of variables would read on these, as input and output states are not clear nor what constitutes an action. The Office strongly suggests positively reciting what these functions are, what applicants intended for the boundaries to be, to make the claims more clear and move prosecution forward.
Williams, which is also a system to that generates routes based on variables teaches “and wherein the utility function maps at least the first route value and the second route value, and optionally the consideration, to the utility value” [Williams, Col 23 lines 17-27 (For example, for each vehicle and/or for an entire vehicle fleet (or a subset thereof), the management hub app displays optimal routes, performance/service status, vehicle usage, location, revenue generated, risk ratings, business reports, and/or recommendations (e.g., to improve revenue, improve performance, reduce risk, reduce costs, etc.)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Williams into the invention of Varma to not only include using vehicles with priorities and rules and ways to negotiate paths as Varma discloses but to also display the possible paths to a user as taught by Williams with a reasonable expectation of success. One would be motivated to incorporate aspects of the cited prior art Williams into Varma to create a more robust system that improves revenue, improve performance, reduce risk, reduce costs, etc. [Williams, Col 23 lines 17-27]. Additionally, the claimed invention is merely a combination of old, well known elements vehicle control based on negotiations and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the results of the combination would have been predictable.
Office Note: Claim 1 states “optionally a consideration”, “optionally including the consideration”, and finally “optionally the consideration”.
Regarding the conditional phrase “optionally”, Applicants are reminded that optional or conditional elements do not narrow the claims because they can always be omitted. See e.g. MPEP §2106 II C: “Language that suggest or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. [Emphasis in original.]”; see also MPEP §2111.04; and In re Johnston, 435 F.3d 1381, 77 USPQ2d 1788, 1790 (Fed. Cir. 2006) (“As a matter of linguistic precision, optional elements do not narrow the claim because they can always be omitted.”). Since the second half of the limitation of Claim 1 are not required, these limitations will be omitted. Appropriate action is required.
With respect to Claim 2: Varma discloses “The negotiation device according to claim 1, wherein the one or more processors are further configured to execute the instructions to accept inputs of the policy function which has a function of determining the action of the own agent in a certain state” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“a value function which has a function of calculating a state value of a state of the own agent” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“the state transition function which has a function of calculating an other state to be obtained next when the action is taken in the state” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“and an offer from an other agent” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“and determine, with the accepted route offer as the constraint condition” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“an execution plan configured to maximize the state value of the value function in a case of following the policy function based on the state transition function” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)].
Office Note: The terms Utility Function, Learned policy function, State transition function, and now a value function with the learned policy function new incorporating “a function”, the state transition function now incorporation “a function” are again, extremely broad as to what is being carried out, what would and would not read on all these functions. Simply saying “function” without what is actually being carried out or how this is being carried out does not further limit the claims. As being broad is not indefinite, almost any function or mathematical use of variables would read on these functions, as input and output states are not clear nor what constitutes an action, state, or value. The Office strongly suggests positively reciting what these functions are, what applicants intended for the boundaries to be, to make the claims more clear and move prosecution forward.
With respect to Claim 4: Varma discloses “The negotiation device according to claim 2, wherein the one or more processors are further configured to execute the instructions to accept the inputs of the policy function, the value function, and the state transition function as generated by machine learning, or the policy function and the value function as defined by a predetermined method” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)].
Office Note: The terms Utility Function, Learned policy function, State transition function, and now a value function with the learned policy function new incorporating “a function”, the state transition function now incorporation “a function” are again, extremely broad as to what is being carried out, what would and would not read on all these functions. Simply saying “function” without what is actually being carried out or how this is being carried out does not further limit the claims. As being broad is not indefinite, almost any function or mathematical use of variables would read on these functions, as input and output states are not clear nor what constitutes an action, state, or value. The Office strongly suggests positively reciting what these functions are, what applicants intended for the boundaries to be, to make the claims more clear and move prosecution forward.
With respect to Claim 6: Varma discloses “The negotiation device according to claim 1, wherein the one or more processors are configured to execute the instructions to: calculate a second value, which is a value of an optimal execution plan in a case an offer from the other agent is not included in the constraint condition;” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“and calculate the utility value based on the utility function which is further configured to calculate the difference between the second value and the first value as a utility” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“and determine whether or not the calculated utility is greater than a predetermined threshold value” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“wherein the utility value is the difference between the second value and the first value” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (Navigation systems provide users with information about current traffic conditions and suggests optimal routes to achieve either minimal transit time or minimal cost (by way of example, by avoiding tolls)].
With respect to Claim 7: Varma discloses “The negotiation device according to claim 1, wherein the one or more processors are configured to execute the instructions to: calculate, with an offer from an other agent including time and position information as the constraint condition, a first value, which is one of optimal route plan values” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“based on the policy function and the state transition function of the own agent” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“and determine whether or not a utility calculated by the utility function defining, as a utility, the difference between the first value and a second value, which is another one of optimal route plan values in a case where the constraint condition is not considered, is greater than a predetermined threshold value” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“wherein the utility value is the difference between the second value and the first value” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (Navigation systems provide users with information about current traffic conditions and suggests optimal routes to achieve either minimal transit time or minimal cost (by way of example, by avoiding tolls)].
With respect to Claim 8: all limitations have been examined with respect to the device in Claims 1-2, 4, and 6-7. The device taught/disclosed in Claim 8 can clearly perform as the device of Claims 1-2, 4, and 6-7. Therefore Claim 8 is rejected under the same rationale.
With respect to Claim 9: While Varma discloses “A negotiation system comprising” [Varma, ¶ 0018-0022, 0026-0027, 0035-0039, 0083-0085, 0095, 0097-0098, 0102, and 0111 (allow autonomous, semi-autonomous or user-driven cars, with an appropriate application installed, to bid for faster passage for their journeys)];
“a first negotiation device configured to determine an execution plan of a first agent based on an offer accepted from another agent” [Varma, ¶ 0018-0022, 0026-0027, 0035-0039, 0083-0085, 0095, 0097-0098, 0102, and 0111 (owner (U1) 132 of a route (R1) 144 earn sell it to another person (U2) 133 (in a way similar to the sale of publicly traded stock))];
“and a second negotiation device configured to output an offer from a second agent to the first negotiation device” [Varma, ¶ 0018-0022, 0026-0027, 0035-0039, 0083-0085, 0095, 0097-0098, 0102, and 0111 (owner (U1) 132 of a route (R1) 144 earn sell it to another person (U2) 133 (in a way similar to the sale of publicly traded stock))];
“wherein the first negotiation device includes: a memory storing instructions” [Varma, ¶ 0012-0013 and Figure 2];
“and one or more processors configured to execute the instructions, stored in the memory to” [Varma, ¶ 0012-0013 and Figure 2];
“generate, based on a policy of an own agent and a state transition function, a first optimal route execution plan up to achievement of a destination while considering the route offer as a constraint condition for path coordination, including collision avoidance” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“wherein the first optimal route execution plan comprises a first trajectory including first time-stamped positions” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0083-0085, 0095, 0097-0098, 0102, and 0111 (requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time)];
“obtain a first route value associated with the first optimal route execution plan, the first route value being a value calculated by a value function for the first optimal route execution plan generated while considering the route offer as the constraint condition” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (The user 102 takes the journey and various transponders and sensors in the car and roadway track the user's travel. This information is then communicated back 114 to the computer 108, which then verifies the journey and debits or credits the user's account 120 via billing server 122. Along the way, the computer may also offer 124 to reroute the user if (s)he is willing to pay more for a faster route, or pay less (or even receive a payment) for a slower route. Similarly, the computer could offer 124 the user a payment to pull off the road at a specified spot for a specified time (to reduce congestion)];
“generate, based on the policy and the state transition function, a second optimal route execution plan up to achievement of the destination without considering the route offer as the constraint condition” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“wherein the second optimal route execution plan comprises a second trajectory including second time-stamped positions” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results)];
“evaluate, using a utility function, a utility value based on a difference between a second route value and the first route value, the difference being between the value calculated by the value function for the second optimal route execution plan generated without considering the route offer as the constraint condition and the value calculated by the value function for the first optimal route execution plan generated while considering the route offer as the constraint condition, and optionally including a consideration in the utility value” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (Navigation systems provide users with information about current traffic conditions and suggests optimal routes to achieve either minimal transit time or minimal cost (by way of example, by avoiding tolls)];
“compare the utility value with a threshold value that varies with a negotiation step” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (Navigation systems provide users with information about current traffic conditions and suggests optimal routes to achieve either minimal transit time or minimal cost (by way of example, by avoiding tolls. In accordance with the present invention, users are not passive receivers of traffic information anymore and can influence and change the traffic patterns by bidding to achieve minimal transit time or cost or any desired combination thereof)];
“in response to the comparing, accept or reject the route offer” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, 0111, and Claim 5 (comprising the steps of: selecting a desired travel route; bidding on the desired travel route; and, receiving a decision on whether the desired travel route was awarded)];
“control the vehicle to cause the vehicle to execute a trajectory of a selected optimal route execution plan consistent with acceptance or rejection of the route offer” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (the bidding system automatically supplies self-driving cars with routes to best-fit said settings and preferences)];
“and, repeat negotiation iterations with the other vehicle until an agreement is reached” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (the bidding system automatically supplies self-driving cars with routes to best-fit said settings and preferences)];
“wherein the policy comprises a policy function that, in response to an input state of the own agent, outputs an action to be taken by the own agent or a probability distribution over candidate actions” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)];
“wherein the state transition function, in response to the input state and the action, outputs a next state of the own agent or a probability distribution over candidate next states” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results) and (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences)];
“wherein each of the first route value and the second route value represents an expected cumulative reward or cost associated with executing a corresponding one of the first optimal route execution plan and the second optimal route execution plan from a current state of the vehicle toward the destination, and” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (Navigation systems provide users with information about current traffic conditions and suggests optimal routes to achieve either minimal transit time or minimal cost (by way of example, by avoiding tolls)];
“wherein the utility function maps at least the difference between the second route value and the first route value, and optionally the consideration, to the utility value” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (Navigation systems provide users with information about current traffic conditions and suggests optimal routes to achieve either minimal transit time or minimal cost (by way of example, by avoiding tolls)];
Varma does not specifically a learning, rather using preference of the users, destination of users with current location and predicted locations, optimal time (fastest) for routes, optimal cost (cheapest) for routes, contract preferences for offer and bids during the route, total system cost data, total system congestion data and many other functions or displaying the routes on a map.
Redman, which is also a system to avoid collisions with autonomous vehicles teaches “wherein the learned policy comprises a policy function that, in response to an input state of the own agent, outputs an action to be taken by the own agent or a probability distribution over candidate actions” [Redman, ¶ 0044-0045, 0068, 0075, and 0079-0083].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Redman into the invention of Varma to not only include using vehicles with priorities and rules and ways to negotiate paths as Varma discloses but to also policies to control the bidding and offers as taught by Redman with a reasonable expectation of success. One would be motivated to incorporate aspects of the cited prior art Redman into Varma to create a more robust system that allows for vehicles to quickly define routes to destinations. Additionally, the claimed invention is merely a combination of old, well known elements vehicle control based on negotiations and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the results of the combination would have been predictable.
Office Note: The terms Utility Function, learned policy function, and state transition function are extremely broad as to what is being carried out, what would and would not read on these functions. As being broad is not indefinite, almost any function or mathematical use of variables would read on these, as input and output states are not clear nor what constitutes an action. The Office strongly suggests positively reciting what these functions are, what applicants intended for the boundaries to be, to make the claims more clear and move prosecution forward.
Williams, which is also a system to that generates routes based on variables teaches “and wherein the utility function maps at least the first route value and the second route value, and optionally the consideration, to the utility value” [Williams, Col 23 lines 17-27 (For example, for each vehicle and/or for an entire vehicle fleet (or a subset thereof), the management hub app displays optimal routes, performance/service status, vehicle usage, location, revenue generated, risk ratings, business reports, and/or recommendations (e.g., to improve revenue, improve performance, reduce risk, reduce costs, etc.)].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Williams into the invention of Varma to not only include using vehicles with priorities and rules and ways to negotiate paths as Varma discloses but to also display the possible paths to a user as taught by Williams with a reasonable expectation of success. One would be motivated to incorporate aspects of the cited prior art Williams into Varma to create a more robust system that improves revenue, improve performance, reduce risk, reduce costs, etc. [Williams, Col 23 lines 17-27]. Additionally, the claimed invention is merely a combination of old, well known elements vehicle control based on negotiations and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the results of the combination would have been predictable.
Office Note: Claim 9 states “optionally a consideration”, “optionally including the consideration”, and finally “optionally the consideration”.
Regarding the conditional phrase “optionally”, Applicants are reminded that optional or conditional elements do not narrow the claims because they can always be omitted. See e.g. MPEP §2106 II C: “Language that suggest or makes optional but does not require steps to be performed or does not limit a claim to a particular structure does not limit the scope of a claim or claim limitation. [Emphasis in original.]”; see also MPEP §2111.04; and In re Johnston, 435 F.3d 1381, 77 USPQ2d 1788, 1790 (Fed. Cir. 2006) (“As a matter of linguistic precision, optional elements do not narrow the claim because they can always be omitted.”). Since the second half of the limitation of Claim 1 are not required, these limitations will be omitted. Appropriate action is required.
With respect to Claim 16: Varma discloses “The negotiation device according to claim 1, wherein the utility is a value obtained by the utility function that derives a magnitude relationship according to preferences regarding different offers, and the more preferable an execution plan, the greater the value” [Varma, ¶ 0018-0022, 0026-0027, 0036-0039, 0083-0085, 0095, 0097-0098, 0102, and 0111].
With respect to Claim 17: Varma discloses “The negotiation device according to claim 1, wherein the one or more processors configured to execute the instructions to control the vehicle to accept or reject an offer comprises repeatedly implementing negotiation with the own agent and an other agent” [Varma, ¶ 0018-0022, 0026-0027, 0036-0039, 0083-0085, 0095, 0097-0098, 0102, and 0111].
With respect to Claim 18: Varma discloses “The negotiation device according to claim 8, wherein one or more processors configured to execute the instructions to control the vehicle to propose or not propose a desired execution state by repeatedly implementing negotiation with an own agent and an other agent” [Varma, ¶ 0018-0022, 0026-0027, 0036-0039, 0083-0085, 0095, 0097-0098, 0102, and 0111].
With respect to Claim 19: Varma discloses “The negotiation system according to claim 9, wherein the one or more processors configured to execute the instructions to at least one of: determine to accept or reject the offer from the second agent repeatedly implementing negotiation with an other agent and the second agent, and determine to propose or not propose a desired execution state from the second agent by repeatedly implementing the negotiation with the other agent and the second agent” [Varma, ¶ 0018-0022, 0026-0027, 0036-0039, 0083-0085, 0095, 0097-0098, 0102, and 0111].
With respect to Claim 20: Varma discloses “The negotiation device according to claim 1, wherein the utility value establishes a preference ordering among different route offers such that one route offer associated with a more preferable route execution plan yields a greater utility value than another route offer associated with a less preferable route execution plan” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences)].
Claim 3 is rejected under 35 USC 103 as being unpatentable over Varma et al. (United States Patent Publication 2017/0358025) in view of Redman et al. (United States Patent Publication 2018/0293898), in view of Williams et al (United States Patent 11,466,998), and in further view of Ebrahimi Afrouzi et al. (EA) (United States Patent 11,144,057).
With respect to Claim 3: While Varma discloses “The negotiation device according to claim 2, wherein the one or more processors are further configured to execute the instructions to accept the inputs of the policy function, the value function, and the state transition function” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences];
Varma does not specifically state using reinforced learning systems.
EA, which is also an autonomous vehicle control system that negotiates between vehicles teaches “wherein the processor is configured to execute the instructions to accept inputs of a policy function, a value function, and a state transition function generated by reinforcement learning” [EA, Col 35 lines 39-55 and Col 36 lines 39-Col 37 line 6].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of EA into the invention of Varma to not only include using vehicles with priorities and rules and ways to negotiate paths as Varma discloses but to also use systems to automate this offer system based on reinforced learning as taught by EA with a reasonable expectation of success. One would be motivated to incorporate aspects of the cited prior art EA into Varma to create a more robust system that results in a reward above a predetermined threshold [EA Col 36 line 39 – Col 37 line 9]. Additionally, the claimed invention is merely a combination of old, well known elements vehicle control based on negotiations and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the results of the combination would have been predictable.
Claim 5 is rejected under 35 USC 103 as being unpatentable over Varma et al. (United States Patent Publication 2017/0358025) in view of Redman et al. (United States Patent Publication 2018/0293898), in view of Williams et al (United States Patent 11,466,998), and in further view of Salter et al. (United States Patent Publication 2022/0194253).
With respect to Claim 5: While Varma discloses “The negotiation device according to claim 1, wherein the one or more processors are configured to execute the instructions to output, to an other agent, a negotiation content corresponding to a determination result” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0102, and 0111 (a user 102 requests a route from Start 124 to Finish 126 across multiple crossroads, intersections, roads, traffic lights, bridges etc. 128 and bids for right to transit that route with the fastest time. The request is processed by the Central Computing Unit 108 that needs to take into consideration other similar or conflicting requests from other vehicles as well as road conditions, known and actual traffic, weather and any other factor influencing said route. The Central Computing Unit allocates a route to user 102 according to the result of the bidding process and acts on Traffic Control Tools 116 represented in FIG. 2 as traffic lights) to allow user 102 to drive his/her route according to the terms of the bidding results), (Car users chose bidding preferences through an ad-hoc App, management tools, through settings and contract preferences), and (dynamically update journey options while the user is en route subject to the user's pre-programmed preferences];
Varma does not specifically state a counter offer.
Salter, which is also a vehicle control system for autonomous vehicles with route/action planning teaches “and output, to the other agent, an alternative offer together with a content indicating rejection when it is determined to reject an offer from the other agent” [Salter,¶ 0020 and 0027-0029].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Salter into the invention of Varma to not only include using vehicles with priorities and rules and ways to negotiate paths as Varma discloses but to also allow counter offers to offers as taught by Salter with a reasonable expectation of success. One would be motivated to incorporate aspects of the cited prior art Salter into Varma to create a more robust system that allows for a true negotiation in price. Additionally, the claimed invention is merely a combination of old, well known elements vehicle control based on negotiations and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the results of the combination would have been predictable.
Claim 21 is rejected under 35 USC 103 as being unpatentable over Varma et al. (United States Patent Publication 2017/0358025) in view of Redman et al. (United States Patent Publication 2018/0293898), in view of Williams et al (United States Patent 11,466,998), and in further view of Solomon (United States Patent Publication 2002/0069134).
With respect to Claim 21: While Varma discloses “The negotiation device according to claim 1, wherein repeating the negotiation iterations comprises iteratively exchanging route offers and responses between the negotiation device and the other vehicle a plurality of times” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0101-0102, and 0111 (a constantly functioning two-way market would be created with buyers and sellers for all routes/intersection priorities, with prices set by whichever mechanism produces the result desired by the municipal authorities/owners of the rights of way along the routes)];
“and wherein the one or more processors are configured to support performing the iteratively exchanging” [Varma, ¶ 0018-0022, 0026-0029, 0035-0039, 0076, 0083-0085, 0095, 0097-0098, 0101-0102, and 0111 (a constantly functioning two-way market would be created with buyers and sellers for all routes/intersection priorities, with prices set by whichever mechanism produces the result desired by the municipal authorities/owners of the rights of way along the routes)].
Varma does not specifically the number of iterations performed by the bid/offer process.
Solomon, which is also a system for using agents to bid/offer teaches “and wherein the one or more processors are configured to support performing the iteratively exchanging for up to several tens of thousands of iterations” [Solomon,¶ 0036 and 0298, with Claim 14 and Claim 48].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Solomon into the invention of Varma to not only include using vehicles with priorities and rules and ways to negotiate bids and offers as Varma discloses but to use agents to bid up to thousands of times taught by Solomon with a reasonable expectation of success. One would be motivated to incorporate aspects of the cited prior art Solomon into Varma to create a more robust system that allows for a true negotiation and “very dynamic scenarios” [Solomon, ¶ 0298]. Additionally, the claimed invention is merely a combination of old, well known elements vehicle control based on negotiations and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the results of the combination would have been predictable.
Prior Art (Not relied upon)
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is disclosed on PTO form 892 attached with this office action.
Conclusion
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JESS WHITTINGTON whose telephone number is (571)272-7937. The examiner can normally be reached on 7am -4pm EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Scott Browne can be reached on (571)-270-0151. 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://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JESS WHITTINGTON/Primary Examiner, Art Unit 3666c
Prosecution Insights