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.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 1/21/2026 has been entered.
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 20-21 have been added.
Claims 1-9 and 16-19 have been amended.
This Non-Final Office Action is in response to the “Request for Continued Examination with Amendments and Remarks” received on 1/21/2026.
Response to Arguments
With respect to applicant’s “Amendments and Remarks or Request for Continued Examination” filed on 1/21/2026: Applicant’s remarks have been fully considered and are found persuasive. Applicants remarks will be addressed in the order they were presented.
With respect to the Objection to Claim 8, applicant’s “Amendments and Remarks” have been fully considered and are persuasive. The Objection to Claim 8 has been withdrawn.
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 not persuasive.
Applicant remarks “A No new matter is introduced; the amendments track the Specification's disclosed implementations” and the Office respectfully disagrees. As the Office stated earlier, the specification states “it is also possible to calculate an optimal agreement between agents by high-speed negotiation several tens of thousands of times that cannot be performed manually” but this does not set the limit on how few iterations much be calculated. The specification clearly uses exemplary language demonstrating that these negotiations are carried out by a computer, but again, sets no minimal limits. Therefore this appears to be new matter and the Office respectfully disagrees.
Applicant remarks “Several tens of thousands" is claimed as capability/up-to, not as a minimum required Condition To avoid any implication that the invention requires a minimum iteration count, Applicant claims iteration scale as a capability: the processors are configured to support performing iterative exchanging up to several tens of thousands of iterations. This formulation is consistent with the Specification's teaching that the negotiation process may be repeated many times and that machine execution enables repetition beyond manual feasibility, without improperly elevating an example into a mandatory minimum” and the Office respectfully disagrees.
The claims as currently presented clearly state a minimum amount, “at least a plurality of tens of thousands” and again, this setting of a minimum threshold is new matter and not supported in specification, thus the claims fail their written description requirement. Therefore the Office respectfully disagrees.
The rejections under 35 U.S.C. § 112 (a) for Claims 17-19 remain.
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.
Office Note: Due to applicant’s amendments, further claim rejections appear on the record as stated in the above Office Action.
With respect to the claim rejections on Claims 1-9 and 16-19 under 35 U.S.C. § 101, applicant’s “Amendments and Remarks” have been fully considered and are persuasive. The rejections under 35 U.S.C. § 101 for Claims 1-9 and 16-19 have been withdrawn.
With respect to the previous claim rejections under 35 U.S.C. § 103, applicant has amended the independent claim and these amendments have changed the scope of the original application and the Office has supplied new grounds for rejection attached below in the Non-FINAL office action and therefore the prior arguments are considered moot.
It is the Office’s stance that all of applicant arguments have been considered and the rejections remain.
Non-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 § 112
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 17-19 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) contains 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.
Claims 17-19 state “implementing negotiation with the own agent and the other agent at least a plurality of a thousand of times” and this limitation appears to be new matter. While the Office has found examples of negotiations in the specification, for example ¶ 0059. Nowhere does it state that there is a minimum value or threshold value of negotiations, rather ¶ 0059 states could be one, more than one, or plurality of thousands. Therefore the requirement of “at least a plurality of a thousand” appears new matter and further, the claims now fail their written description requirement. Appropriate action is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2, 6-7, and 17-19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 2 states “a value function which has a function of calculating a value of a state of the own agent” and later states “an execution plan configured to maximize a value of the value function” and are these two “values” calculated by the value function the same of different? If they are the same, there are antecedent issues with the second value that is maximized. If these are the different what value is being maximized and how does this relate to the vehicle state? As currently presented, Claim 2 fails to clearly recite the metes and bounds of the claimed subject matter, thus it is indefinite. Further, Claim 2 is claiming functions that contain functions with inputs, outputs, and states but does not actually state what is being carried out. When attempting to address what the metes and bounds for these values are, again it becomes unclear what is meant, what is required, and what is being done. The Office will interpret any maximization of a value based on accepted offers and preferences based on route to a destination, where the offers and bids are agreed upon, as reading on this. Appropriate action is required.
Claim 6 states “and calculate a value based on the utility function” and then states “which is further configured to calculate a difference between the second value and the first value as a utility” it is unclear if this “a value” is the difference between the first value and second value” or just a value and this is another function of the utility function. As currently presented Claim 6 fails to clearly recite the metes and bounds of the claimed subject matter, thus it is indefinite. After looking into the specification, this appears to be a typo and the Office will interpret “a value” to be based on the difference between the second and first value”. Appropriate action is required.
Claim 7 states “determine whether or not a value calculated by the utility function” and then states “a difference between the first value and a second value” it is unclear if this “a value” is the difference between the first value and a second value” or just a value and this is another function of the utility function. As currently presented Claim 7 fails to clearly recite the metes and bounds of the claimed subject matter, thus it is indefinite. After looking into the specification, this appears to be a typo and the Office will interpret “a value” to be based on the difference between a second and the first value”. Appropriate action is required.
Claim 17 states “comprises repeatedly implementing negotiation with the own
agent and the other agent at least a plurality of a thousand of times” and the metes and bounds of this limitation are unclear. Is the claim requiring a minimum of a plurality of a thousand of negotiations must be carried out, or that this is merely possibility? Further, when the Office looks into the specification, this appears to be an example of what “could” happen, but not what must happen. And further the number was never a threshold value. In fact, it appears, the negotiation could be way less, even one based on the example. So what is actually required for this claim? Is applicant actually claiming that this only works when multiples of thousands of negotiations are carried out, and not when less? For example, if we only get 999 negotiations, we do not work? Thus, as currently presented, Claim 17 fails to clearly define the metes and bounds of the claimed subject matter, thus it is indefinite. The Office is going to interpret any amount of negotiations as reading on this. Appropriate action is required.
Claim 18 is rejected under the same rational as Claim 17.
Claim 19 is rejected under the same rational as Claim 17.
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 learned policy of an own agent and a state transition function, an optimal route execution plan up to achievement of a destination while enforcing the route offer as a collision-avoidance constraint” [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 optimal route execution plan comprises a trajectory including 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 optimal route execution plan generated under the collision-avoidance constraint” [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 learned policy and the state transition function, the optimal route execution plan without enforcing the route offer as the collision-avoidance constraint” [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 obtain a second route value associated with the optimal route execution plan generated without the collision-avoidance constraint” [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 the second route value and the first route value, 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 own agent and 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 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” [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 route execution plan from a current state of the vehicle toward the destination” [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)];
“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” [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 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 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 a 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 a 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 on 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 a value based on the utility function which is further configured to calculate a 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 value 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)].
Office Note: The terms in Claim 6, which depends on Claim 1 state “a value based on the utility function” , where “a second value”, which is “a value” of an optimal execution plan” yet in Claim 1, there is also “a first route value”, “second route value” and “a utility value” which are extremely broad and confusing as to what is exactly being claimed, what is being carried out, and finally what would and would not read on all these “values” Simply saying “values” 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 value used in calculations or use of calculated variables would read on these values. The Office strongly suggests positively reciting what these values are, what applicants intended for the boundaries to be, to make the claims more clear and move prosecution forward.
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 a 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 value calculated by the utility function defining, as a utility, a 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)].
Office Note: The terms in Claim 7, which depends on Claim 1 state “a value calculated by the utility function” , where “a second value”, which is “a value” of an optimal execution plan” yet in Claim 1, there is also “a first route value”, “second route value” and “a utility value” which are extremely broad and confusing as to what is exactly being claimed, what is being carried out, and finally what would and would not read on all these “values” Simply saying “values” 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 value used in calculations or use of calculated variables would read on these values. The Office strongly suggests positively reciting what these values are, what applicants intended for the boundaries to be, to make the claims more clear and move prosecution forward.
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 learned policy of an own agent and a state transition function, an optimal route execution plan up to achievement of a destination while enforcing the route offer as a collision-avoidance constraint” [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 optimal route execution plan comprises a trajectory including 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 optimal route execution plan generated under the collision-avoidance constraint” [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 learned policy and the state transition function, the optimal route execution plan without enforcing the route offer as the collision-avoidance constraint” [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 obtain a second route value associated with the optimal route execution plan generated without the collision-avoidance constraint” [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 the second route value and the first route value, 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 own agent and 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 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” [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 route execution plan from a current state of the vehicle toward the destination” [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)];
“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” [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 the offer comprises repeatedly implementing negotiation with the own agent and an other agent at least a plurality of a thousand of times” [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 the other agent at least a plurality of a thousand of times” [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 at least a plurality of a thousand of times, 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 at least the plurality of the thousands of times” [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
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JESS G WHITTINGTON whose telephone number is (571)272-7937. The examiner can normally be reached on 7-5.
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