Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim(s) 1-2, 4-13, and 15-21 are pending for examination.
This Action is made NON-FINAL.
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 3/13/2026 has been entered.
Response to Arguments
With regards to claim(s) 1-2, 4-13, and 15-21 previously rejected under 35 U.S.C. 101 Applicant's arguments have been fully considered, but are not persuasive. Applicant argues
“That is, the claims have been amended to explicitly recite that the requests are executed and serviced (acted upon) by controlling actions of connected vehicles. Per the interview summary above, the examiner agreed that clarifying how vehicles are controlled would integrate the alleged abstract idea into a practical application.”
However, applicant has not clarified what the actions entail. While “control of steering, control of gas and braking” would overcome the 101 rejection, applicant’s specification does not limit the definition of actions para [0057] “specific actions or activities that are requested (e.g., control of steering, control of gas and braking, navigation assistance, phone assistance, combinations thereof, etc.)” thus under broadest reasonable interpretation the actions could merely be data analysis which can be still considered as a mental process.
With regards to claim(s) 1-2, 4-13, and 15-21 previously rejected under 35 U.S.C. 103, applicant's arguments have been fully considered, but are not persuasive. Applicant argues
“Applicant submits that Blanc does not teach that the data ingestion APIs 616 are configured to communicate data in a common format and, in direct contrast, suggests that the data ingestion APIs communicate data in different formats. That is, Blanc teaches that the data mediation unit (not the data ingestion APIS 616) is responsible for normalizing the data received by the APIs and converting the data into a common format. In other words, Blanc suggests that the data from the APIs is not in a common format and is converted into that common format after being communicated by the APIs.”
Examiner respectfully disagrees and apologizes for any miscommunication that may have occurred during the interview. Examiner does not disagree that the “data mediation unit” is responsible for ensuring the data is in a common format. However this does not invalidate the previously made 103 rejection as it was clearly stated in the final rejection dated 12/10/2025 that data mediation unit 620 was being interpreted as an extension of the data ingestion API 616 (i.e. one of the data ingestion API and data mediation in combination can be considered as a single completely API). There are a plurality of data ingestion API and thus there can be considered as a plurality of complete API. Applicant has not made any arguments directed toward this interpretation in either their remarks or during the interview.
The definition of an API according to Wikipedia is “An application programming interface (API) is a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software.” As an API is purely software there is not tangible structure and thus the bounds of software are not clearly defined. For example a number of software modules in combination can be considered as a single software. Thus any set of software instructions that functions as an interface and offers a service to other pieces of software can be considered as an API whether it be one software module or a combination of several software modules. Thus the each data ingestion API 616 in combination with the data mediation unit 620 can be considered as a complete API. It should be noted that 616 and 620 are on the same computing system and thus are expected to be both executed on the same hardware.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim(s) 1-2, 4-13, and 15-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim(s) 1-2 and 4-10 are directed to a process, and 11-13 and 15-21 are directed to an apparatus. Therefore, claim(s) 1-21 are within at least one of the four statutory categories.
Regarding Prong I of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether they recite subject matter that falls within one of the follow groups of abstract ideas: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes.
Independent claims 1, 11, and 12 includes limitations that recite an abstract idea (emphasized below) and claim 12 will be used as a representative claim for the remainder of the 101 rejection. Claim 12 recites:
A system for contextual distribution of remote driving and remote assistance requests, comprising:
a processing circuitry; and
a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to:
translating, via a plurality of application programing interfaces (APIs), a plurality of requests for remote connected vehicle operation into a plurality of translated requests based on criteria defined in at least one request distribution policy, wherein each API of the plurality of APIs is disposed between one of the plurality of vehicles and at least one system, wherein each API of the plurality of APIs is configured to communicate data to the at least one system in a format which is common to the plurality of APIs;
classify, by the at least one system, the plurality of requests for remote connected vehicle operation into a plurality of classifications, wherein each request corresponds to a respective connected vehicle of a plurality of connected vehicles, wherein classifying the plurality of translated requests includes applying a set of request classification rules which are defined with respect to the format which is common to the plurality of APIs;
determine, by the at least one system, a distribution for the plurality of requests based on the plurality of classifications, wherein at least a portion of the plurality of requests is assigned to respective operators of a plurality of operators based on capabilities associated with each of the plurality of operators; and
transmit, by the at least one system to a plurality of remote operator devices, the plurality of requests based on the distribution, wherein the plurality of requests is executed by the plurality of remote operator devices in order to cause the plurality of remote operator devices to service the plurality of requests by controlling a plurality of actions by at least one connected vehicle.
The examiner submits that the foregoing bolded limitation(s) constitute a mental process because under its broadest reasonable interpretation, the claim covers performance of the limitation in the human mind. For example, Translation can be done in the human mind, classifying requests can be done in the human mind as well as coming up with a plan on how to distribute work based on the classification. Additionally the requests of controlling a plurality of actions may merely be deciding a route which can be done in the human mind. Accordingly, the claim recites at least one abstract idea.
Regarding Prong II of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether the claim, as a whole, integrates the abstract into a practical application. As noted in the 2019 PEG, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
In the present case, the additional limitations beyond the above-noted abstract idea are as follows (where the underlined portions are the “additional limitations” while the bolded portions continue to represent the “abstract idea”):
A system for contextual distribution of remote driving and remote assistance requests, comprising:
a processing circuitry; and
a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to:
translating, via a plurality of application programing interfaces (APIs), a plurality of requests for remote connected vehicle operation into a plurality of translated requests based on criteria defined in at least one request distribution policy, wherein each API of the plurality of APIs is disposed between one of the plurality of vehicles and at least one system, wherein each API of the plurality of APIs is configured to communicate data to the at least one system in a format which is common to the plurality of APIs;
classify, by the at least one system, the plurality of requests for remote connected vehicle operation into a plurality of classifications, wherein each request corresponds to a respective connected vehicle of a plurality of connected vehicles, wherein classifying the plurality of translated requests includes applying a set of request classification rules which are defined with respect to the format which is common to the plurality of APIs;
determine, by the at least one system, a distribution for the plurality of requests based on the plurality of classifications, wherein at least a portion of the plurality of requests is assigned to respective operators of a plurality of operators based on capabilities associated with each of the plurality of operators; and
transmit, by the at least one system to a plurality of remote operator devices, the plurality of requests based on the distribution, wherein the plurality of requests is executed by the plurality of remote operator devices in order to cause the plurality of remote operator devices to service the plurality of requests by controlling a plurality of actions by at least one connected vehicle.
For the following reason(s), the examiner submits that the above identified additional limitations do not integrate the above-noted abstract idea into a practical application.
Regarding the additional limitations of “a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to:”, “transmit the plurality of requests based on the distribution.” And using “a plurality of application programing interfaces (APIs)” where “each API of the plurality of APIs is disposed between one of the plurality of vehicles and at least one system, wherein each API of the plurality of APIs is configured to communicate data to the at least one system in a format which is common to the plurality of APIs;” the examiner submits that these limitations are insignificant extra-solution activities that merely use a computer to perform the process. The “processing circuitry” and “memory” merely describes how to generally “apply” the otherwise mental judgements in a generic or general purpose computing environment. Processor and memory is recited at a high level of generality and merely automates the evaluating step. The transmit the plurality of requests based on the distribution amounts to mere data transmission as the transmitted data is not used in anyway. In fact, it is not even claimed that the data is received.
Thus, taken alone, the additional elements do not integrate the abstract idea into a practical application. Further, looking at the additional limitation(s) as an ordered combination or as a whole, the limitation(s) add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, apply or use the above-noted judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, implement/use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (MPEP § 2106.05). Accordingly, the additional limitation(s) do/does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Regarding Step 2B of the 2019 PEG, representative independent claim 12 does not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using “a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to:” and “transmit the plurality of requests based on the distribution” amounts to nothing more than applying the exception using a generic computer component. As stated in MPEP § 2106.05 “…Whether the claim invokes computers or other machinery merely as a tool to perform an existing process. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more.”
Dependent claim(s) 2, 4-10, 13, and 15-21 do not recite any further limitations that cause the claim(s) to be patent eligible. Rather, the limitations of dependent claims are directed toward additional aspects of the judicial exception and/or well-understood, routine and conventional additional elements that do not integrate the judicial exception into a practical application. Claims 2, 4, 6-10, 13, 15, and 17-21 merely elaborate on the mental process recited in the independent claims and claims 5 and 16 merely elaborate on the data transmission which does not integrate a judicial exception into a practical application or provide significantly more.
Therefore, dependent claims 2 and 4-10 are not patent eligible under the same rationale as provided for in the rejection of 1.
Therefore, dependent claims 13 and 15-21are not patent eligible under the same rationale as provided for in the rejection of 12.
Therefore, claim(s) 1-21 is/are ineligible under 35 USC §101.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2, 6, 8-9, 10-13, 17, and 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over by Goldman et al. (US 20240036571 A1, hereinafter known as Goldman) in view of Chen et al. (US 20200272949 A1, hereinafter known as Chen) and Blanc et al. (US 20230189763 A1; hereinafter known as Blanc).
Regarding claim 1, Goldman teaches A method for contextual distribution of remote connected vehicle operation requests, comprising:
classifying, by the at least one system, the plurality of translated requests for remote connected vehicle operation into a plurality of classifications, wherein each request corresponds to a respective connected vehicle of a plurality of connected vehicles, wherein classifying the plurality of translated requests includes applying a set of request classification rules which are defined with respect to the format
{Para [0025] “As will be explained herein, the remote operation system 112 includes a request queue (as may be managed by one or more remote servers) and remote operators (e.g., such as the remote operator 108). The request queue serves to organize requests in response to the vehicle 102, as well as other vehicles, asking for assistance. In some examples, the requests are organized and ordered in the request queue based on a time at which the requests are received, a priority, a geographic location, and the like or any combination thereof. The request queue is used by the remote operation system 112 to organize the requests and assign the requests to the remote operators. Of course, multiple request queues may be implemented simultaneously with an individual queue having differing criteria for ordering inbound requests and different sets of operators to service those requests.”
Para [0065] “In some examples, the queue interface 248 may be implemented on a device that is separate from a device that includes a remote operator interface 306. For example, the queue interface 248 may include a gateway device and an application programming interface (“API”) or similar interface. In some examples, the queue interface 248 is configured to receive the requests and generate a queue for the requests for processing by the remote operators 108. The queue interface 248 may match the requests with corresponding remote operators 108 based on sensor data generated by the vehicles, preference(s) of the remote operators 108, a status of the remote operators 108, and so forth. In such examples, the queue interface 248 may filter available remote operators 108 for assigning requests based on the availability of the remote operators 108. In an example, the queue interface 248 may prioritize requests based on a first come, first served basis, with requests having earlier timestamps prioritized above more recent requests. The queue interface 248 may also apply filters to adjust priority a priority in which the requests are assigned, for example, based on safety determinations (e.g., speed of the vehicle or environmental conditions), passenger status (e.g., occupied versus unoccupied), a proximity of the remote operators to the vehicle, and other such filters.”
}
determining, by the at least one system, a distribution for the plurality of requests based on the plurality of classifications, wherein at least a portion of the plurality of requests is assigned to respective operators of a plurality of operators based on capabilities associated with each of the plurality of operators;
{ Para [0025] “As will be explained herein, the remote operation system 112 includes a request queue (as may be managed by one or more remote servers) and remote operators (e.g., such as the remote operator 108). The request queue serves to organize requests in response to the vehicle 102, as well as other vehicles, asking for assistance. In some examples, the requests are organized and ordered in the request queue based on a time at which the requests are received, a priority, a geographic location, and the like or any combination thereof. The request queue is used by the remote operation system 112 to organize the requests and assign the requests to the remote operators. Of course, multiple request queues may be implemented simultaneously with an individual queue having differing criteria for ordering inbound requests and different sets of operators to service those requests.”
Para [0026] “As part of assigning the request to the remote operators 108, the remote operation system 112 may determine an availability, preference(s), and/or a status of the remote operators 108 at 116. For example, the availability of the remote operators 108, such as whether they are on-duty or off-duty, may be used to filter those remote operators that are connected to the remote operations system 112 and able to provide assistance. The status may further indicate, of those remote operators that are available, whether individual remote operators are on break, in training mode (and unable to provide assistance), whether the remote operators are already providing assistance to a vehicle, and so forth. Here, the status may therefore indicate whether the remote operators are occupied or unoccupied for purposes of providing assistance to the vehicle 102. The preference(s) may be set by the remote operators 108 and correspond to the types of assistance, or instances of assistance, in which the remote operators 108 wish to provide. For example, remote operators 108 may desire to only assist vehicles within a certain geographical region, on certain mission types, vehicles of a certain type, vehicles needing a predetermined assistance (e.g., maneuvering around construction zone, accident, etc.), and so forth. In such instances, the remote operators 108 have the ability to customize the type of incidents that they respond to, or provide assistance to.”
Para [0065] “In some examples, the queue interface 248 may be implemented on a device that is separate from a device that includes a remote operator interface 306. For example, the queue interface 248 may include a gateway device and an application programming interface (“API”) or similar interface. In some examples, the queue interface 248 is configured to receive the requests and generate a queue for the requests for processing by the remote operators 108. The queue interface 248 may match the requests with corresponding remote operators 108 based on sensor data generated by the vehicles, preference(s) of the remote operators 108, a status of the remote operators 108, and so forth. In such examples, the queue interface 248 may filter available remote operators 108 for assigning requests based on the availability of the remote operators 108. In an example, the queue interface 248 may prioritize requests based on a first come, first served basis, with requests having earlier timestamps prioritized above more recent requests. The queue interface 248 may also apply filters to adjust priority a priority in which the requests are assigned, for example, based on safety determinations (e.g., speed of the vehicle or environmental conditions), passenger status (e.g., occupied versus unoccupied), a proximity of the remote operators to the vehicle, and other such filters.”
}
and transmitting, by the at least one system to a plurality of remote operator devices, the plurality of requests based on the distribution, wherein the plurality of requests is executed by the plurality of remote operator devices in order to cause the plurality of remote operator devices to service the plurality of requests by controlling a plurality of actions by at least one connected vehicle.
{Para [0068] “The queue interface 248 communicates with the remote operator interfaces 306 of the remote operation system 112. The queue interface 248 generates the queue of requests and communicates the requests to the remote operators 108 via the remote operator interface 306. Each of the remote operators 108 may include a respective remote operation device (e.g., tablet, complete, phone, etc.) for communicating with the remote operation system 112 and responding to the requests. For example, the first remote operator 108(a) may use a remote operator device 308(a), while the second remote operator 108(b) may use a remote operator device 308(b). In some examples, the network proxy 304 may be communicatively coupled to the remote operator interface 306 via the queue interface 248, and in some examples, the remote operator 108 may be able to access the sensor data, the operation state data, and/or any other data in the communication signals received from the vehicle 302(a), 302(b), . . . 302(n) via the remote operator interface 306.”
Para [0024] “At 114, the vehicle 102 may encounter a construction zone 124 associated with a portion of the road 106, and traffic in the vicinity of the construction zone 124 may be under the direction of a construction worker who provides instructions for traffic to maneuver around the construction zone 124. Due in part to the unpredictable nature of this type of event, the vehicle 102 may request remote assistance from a remote operation system 112. The remote operation system 112 therefore receives, at 114, a request for remote assistance to guide the vehicle 102.”
}
Goldman does not teach, translating, via a plurality of application programing interfaces (APIs), a plurality of requests for remote connected vehicle operation into a plurality of translated requests based on criteria defined in at least one request distribution policy, wherein each API of the plurality of APIs is disposed between one of the plurality of vehicles and at least one system, wherein each API of the plurality of APIs is configured to communicate data to the at least one system in a format which is common to the plurality of APIs;
However, Chen teaches translating, via a plurality of application programing interfaces (APIs), a plurality of requests for remote connected vehicle operation into a plurality of translated requests based on criteria defined in at least one request distribution policy, wherein each API of the plurality of APIs is disposed between one of the plurality of vehicles and at least one system, wherein each API of the plurality of APIs is configured to communicate data to the at least one system in a compatible manner;
{Para [0077] “The service infrastructure 200 can include a private platform 206 to facilitate service provider-specific (e.g., internal, proprietary, etc.) vehicle services (e.g., provided via one or more system clients (228a, 228b) associated with the service provider operations computing system) between the service provider system 204 (e.g., operations computing system, etc.) and autonomous vehicles associated with the service provider (e.g., autonomous vehicles 208a, 208b). For example, in some embodiments, the private platform 206 can provide access to service provider services that are specific to the service provider autonomous vehicle fleet (e.g., vehicles 208a and 208b) such as fleet management services, autonomy assistance services, and/or the like.”
Para [0078] “The private platform 206 can include a gateway API (e.g., gateway API 230) to facilitate communication from the autonomous vehicles 208a, 208b to one or more service provider infrastructure services (e.g., via the public platform 202, via one or more service provider autonomous vehicle backend interfaces 234, etc.) and a vehicle API (e.g., vehicle API 232) to facilitate communication from the service provider infrastructure services (e.g., via the public platform 202, via one or more service provider autonomous vehicle backend interfaces 234, etc.) to the autonomous vehicles 208a, 208b. The private platform 206 can include one or more backend interfaces 234 associated with at least one system client (e.g., service provider vehicle-specific system clients, such as fleet management, autonomy assistance, etc.). In some embodiments, the private platform 206 can include one or more adapters 236, for example, to provide compatibility between one or more service provider autonomous vehicle backend interfaces 234 and one or more private platform APIs (e.g., vehicle API 232, gateway API 230).”
Goldman already teaches that the distribution of request is based on a variety of characteristics. Additionally if the distribution includes the translated requests, the distribution can be said to be based on the translated requests.
The adapters can be said to be extensions of the API as Adapters and APIs are merely software. As software is non-physical the instructions that encompass the adapters (236) and the instructions the encompass the private platform APIs (232, 230) can be considered as two subcomponents of an API as defined by applicant’s claims.
}
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Goldman to incorporate the teachings of Chen to distribute requests in using the methods of Chen because Chen provides techniques that improve the efficiency of assisted autonomy tasks (para [0044] “The systems and methods described herein provide a number of technical effects and benefits. More particularly, the systems and methods of the present disclosure provide improved techniques for the efficient performance of assisted autonomy tasks by computing systems remote from autonomous vehicles. By tracking assisted autonomy tasks, generating operator attributes, and utilizing request parameters in order to select operators for particular remote assistance requests, the amount of computational resources utilized in assisting an autonomy computing system with autonomous computing tasks can be reduced. For instance, as described herein, a remote autonomous vehicle assistance computing system can track assisted autonomy tasks performed by the autonomous vehicle assistance computing system. The assisted autonomy tasks can be facilitated by a plurality of operators including human operators and/or computer-based operators. The autonomous vehicle assistance system can generate operator attributes for individual operators based on tracking assisted autonomy tasks. Request parameters can be determined from future requests for remote operator assistance received by the autonomous vehicle assistance system. The autonomous vehicle assistance system can determine request parameters associated with the requests for autonomous vehicle assistance. The request parameters can be compared with the operator attributes so that an operator having experience or familiarity associated with the request parameters can be selected to facilitate assisted autonomy tasks in response to the request for autonomous vehicle assistance. By correlating operator attributes and request parameters, a remote operator can be selected that is more likely to be able to assist with a request for remote operator assistance. This can minimize downtime where the autonomy computing system of an autonomous vehicle remains idle and is unable to provide vehicle services. Such examples represent a waste of computer resources and/or bandwidth. By more precisely correlating requests for autonomous vehicle assistance with operators, the amount of computing resources and bandwidth required for systems can be reduced. Such techniques may provide a better user experience by reducing the amount of time that an autonomous vehicle remains idle. Moreover, such solutions can alleviate congestion within geographical areas that may be associated with a non-moving vehicle or a vehicle not efficiently proceeding along a route.”)
Goldman in view of Cheh does not teach, wherein each API of the plurality of APIs is configured to communicate data to the at least one system in a format which is common to the plurality of APIs;
Blanc teaches wherein each API of the plurality of APIs is configured to communicate data to the at least one system in a format which is common to the plurality of APIs;
{Para [0155] “As the data arrives at the data management system 596, the data goes into a load balancer 612 that distributes the data to any one of many instances of the data ingestion API 616. The purpose of the load balancer is to ensure that data processing is distributed among a plurality of available data ingestion API instances to achieve high-availability, and to allow the system to scale and be able to process large amounts of inbound API requests. The data ingestion API performs preliminary processing of the data to authenticate the sender, validate that the data conforms to expected syntax, format and ranges, and provide API security functions including authentication, authorization, data validation, rate limiting, threat detection and prevention. From the data ingestion API 616 the data or portions may go to a data mediation unit 620. The data mediation unit is responsible for normalizing the data received by a plurality of APIs and converting the data into a common format that can be stored in a database. From the data mediation unit 620, data or aspects of the data goes to a database 624.”
Once again the data mediation unit can be considered as an extension of each of the pluralities of APIs the APIs and data mediation unit are software the work together and not physically distinct.
}
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Goldman in view of Chen to incorporate the teachings of Blanc to have the APIs communicate data in a format which is common because as is well known in the art using a common format improves compatibility.
Regarding claim 2, Goldman in view of Chen and Blank teaches The method of claim 1, Goldman teaches further comprising: creating at least one queue of the plurality of requests based on the plurality of classifications, where the distribution is determined based further on the at least one queue.
{Para [0025] “As will be explained herein, the remote operation system 112 includes a request queue (as may be managed by one or more remote servers) and remote operators (e.g., such as the remote operator 108). The request queue serves to organize requests in response to the vehicle 102, as well as other vehicles, asking for assistance. In some examples, the requests are organized and ordered in the request queue based on a time at which the requests are received, a priority, a geographic location, and the like or any combination thereof. The request queue is used by the remote operation system 112 to organize the requests and assign the requests to the remote operators. Of course, multiple request queues may be implemented simultaneously with an individual queue having differing criteria for ordering inbound requests and different sets of operators to service those requests.”
Para [0067] “In some examples, the queue interface 248 may maintain multiple different or separate queues that may operate in parallel to one another. In such examples, the separate parallel queues may correspond to different geographic locations of the vehicles, different vehicle types, different request types (e.g., requesting guidance assistance versus a request from a passenger of the vehicle system), and other queues related to different filters for the queues may also be applied. The multiple parallel queues may each be accessible by distinct subsets of remote operators, for example with a queue for a first vehicle type only accessible to remote operators qualified to provide guidance or assistance to that class of vehicle. In some examples, the remote operators may be available to handle requests from one or more of the parallel queues.”
}
Para [0068] “The queue interface 248 communicates with the remote operator interfaces 306 of the remote operation system 112. The queue interface 248 generates the queue of requests and communicates the requests to the remote operators 108 via the remote operator interface 306. Each of the remote operators 108 may include a respective remote operation device (e.g., tablet, complete, phone, etc.) for communicating with the remote operation system 112 and responding to the requests. For example, the first remote operator 108(a) may use a remote operator device 308(a), while the second remote operator 108(b) may use a remote operator device 308(b). In some examples, the network proxy 304 may be communicatively coupled to the remote operator interface 306 via the queue interface 248, and in some examples, the remote operator 108 may be able to access the sensor data, the operation state data, and/or any other data in the communication signals received from the vehicle 302(a), 302(b), . . . 302(n) via the remote operator interface 306.”
}
Regarding claim 6, Goldman in view of Chen and Blank teaches The method of claim 1.
Chen teaches wherein at least one first request of the plurality of requests is assigned to at least two operators of the plurality of operators.
{Para [0097-0098] “For example, the interactive object annotation system, the autonomous vehicle 102 (e.g., vehicle computing system, motion planning system, etc.), etc. can perform an analysis of objects and/or the surrounding environment to ensure that the autonomous vehicle 102 can safely maneuver along a planned path (e.g., the vehicle navigation change 410), regardless of the new/updated classification applied to the group of objects (e.g., unexpected objects 220). For example, if a new/updated classification for a group of objects indicates “static pass right” when it should have been “static pass left,” the autonomous vehicle can recognize that it cannot pass safely on the right and not complete the maneuver. As another example, the interactive object annotation system, the autonomous vehicle 102 (e.g., vehicle computing system, motion planning system, etc.), etc. can identify one or more objects (e.g., vehicle 510) within the surrounding environment of the autonomous vehicle 102 that may have an impact on the safety of initiating a vehicle navigation change 410. By way of example, the interactive object annotation system, the autonomous vehicle 102 (e.g., vehicle computing system, motion planning system, etc.), etc. can identify another object (e.g., vehicle 510) in a lane required for implementing annotation data indicative of a vehicle navigation change 410 (e.g., “static pass left”). In such a case, the interactive object annotation system, the autonomous vehicle 102 (e.g., vehicle computing system, motion planning system, etc.), etc. can disregard and/or postpone the vehicle navigation change 410, for example, until the object (e.g., vehicle 510) has passed.
In addition, or alternatively, the interactive object annotation system can include various safeguards with regard to the classification of groups of objects (e.g., unexpected objects 220) simultaneously. For example, in some implementations, the interactive object annotation system may provide for final confirmation of a new/updated classification of a group of objects by a remote operator before the new/updated classifications are applied (e.g., via confirmation dialogue boxes on a user interface, etc.). As another example, in some implementations, a new/updated classification for a group of objects may be required to be reviewed and/or confirmed by more than one remote operator before the new/updated classifications are applied. In some implementations, an interactive object annotation system may include a confirmation process. For example, the interactive object annotation system may provide indications of the results of a new/updated classification (e.g., a possible vehicle path resulting from the classification) that needs to be confirmed before the new classification is applied to the group of objects (e.g., unexpected object 220). In some implementations, the interactive object annotation system may have the ability to override a new/updated classification selected by a remote operator if there is high-confidence in an alternative decision in a particular scene. For example, the interactive object annotation system may nullify a new/updated classification of “static” from an original classification of “moving” if the object being classified/reclassified moves a certain distance from its original position.”
}
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Goldman in view of Chen and Blank to incorporate the teachings of Chen to distribute requests in using the methods of Chen because Chen provides techniques that improve the efficiency of assisted autonomy tasks (para [0044] “The systems and methods described herein provide a number of technical effects and benefits. More particularly, the systems and methods of the present disclosure provide improved techniques for the efficient performance of assisted autonomy tasks by computing systems remote from autonomous vehicles. By tracking assisted autonomy tasks, generating operator attributes, and utilizing request parameters in order to select operators for particular remote assistance requests, the amount of computational resources utilized in assisting an autonomy computing system with autonomous computing tasks can be reduced. For instance, as described herein, a remote autonomous vehicle assistance computing system can track assisted autonomy tasks performed by the autonomous vehicle assistance computing system. The assisted autonomy tasks can be facilitated by a plurality of operators including human operators and/or computer-based operators. The autonomous vehicle assistance system can generate operator attributes for individual operators based on tracking assisted autonomy tasks. Request parameters can be determined from future requests for remote operator assistance received by the autonomous vehicle assistance system. The autonomous vehicle assistance system can determine request parameters associated with the requests for autonomous vehicle assistance. The request parameters can be compared with the operator attributes so that an operator having experience or familiarity associated with the request parameters can be selected to facilitate assisted autonomy tasks in response to the request for autonomous vehicle assistance. By correlating operator attributes and request parameters, a remote operator can be selected that is more likely to be able to assist with a request for remote operator assistance. This can minimize downtime where the autonomy computing system of an autonomous vehicle remains idle and is unable to provide vehicle services. Such examples represent a waste of computer resources and/or bandwidth. By more precisely correlating requests for autonomous vehicle assistance with operators, the amount of computing resources and bandwidth required for systems can be reduced. Such techniques may provide a better user experience by reducing the amount of time that an autonomous vehicle remains idle. Moreover, such solutions can alleviate congestion within geographical areas that may be associated with a non-moving vehicle or a vehicle not efficiently proceeding along a route.”)
Regarding claim 8, Goldman in view of Chen and Blank teaches The method of claim 1, Goldman teaches further comprising: classifying a plurality of network connectivity statuses into a plurality of network connectivity status classifications, each network connectivity status being associated with a respective remote operator of the plurality of remote operators, wherein the distribution is determined based further on the plurality of network connectivity status classifications.
{Para [0083] “In some examples, the remote operation system 112 may include multiple remote operation centers, with remote operation centers scattered around a geographic region where a fleet of vehicles operate. In such examples, the remote operators may be selected based on proximity to the vehicle requesting assistance. In some examples, the remote operation centers may have different bandwidths and/or availability to handle the requests. To reduce latency, in some examples, a nearest remote operation center and/or remote operator may be selected to process a request.”
Where location of connection can be considered as a “network connectivity status”
}
Regarding claim 9, Goldman in view of Chen and Blank teaches The method of claim 1, Goldman teaches wherein the capabilities associated with the plurality of operators include at least one operating station capability of each of a plurality of operating stations accessible to the plurality of operators.
{ Para [0083] “In some examples, the remote operation system 112 may include multiple remote operation centers, with remote operation centers scattered around a geographic region where a fleet of vehicles operate. In such examples, the remote operators may be selected based on proximity to the vehicle requesting assistance. In some examples, the remote operation centers may have different bandwidths and/or availability to handle the requests. To reduce latency, in some examples, a nearest remote operation center and/or remote operator may be selected to process a request.”
Where low latency based on location can be considered as a capability.
}
Regarding claim 10, Goldman in view of Chen and Blank teaches The method of claim 1.
Chen teaches wherein at least a portion of the requests is assigned to automated remote vehicle operation systems.
{Para [0077] “The remote vehicle assistance system may engage one or more operators (e.g., human or computer) to at least partially facilitate responses to requests for remote assistance. For example, sensor data from the autonomous vehicle may be transmitted to the autonomous vehicle assistance system and viewed by an operator. The operator can provide input to the autonomous vehicle assistance system which can generate control messages for the autonomous computing system to assist with the autonomous computing task.”
}
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Goldman in view of Chen and Blank to incorporate the teachings of Chen to distribute requests in using the methods of Chen because Chen provides techniques that improve the efficiency of assisted autonomy tasks (para [0044] “The systems and methods described herein provide a number of technical effects and benefits. More particularly, the systems and methods of the present disclosure provide improved techniques for the efficient performance of assisted autonomy tasks by computing systems remote from autonomous vehicles. By tracking assisted autonomy tasks, generating operator attributes, and utilizing request parameters in order to select operators for particular remote assistance requests, the amount of computational resources utilized in assisting an autonomy computing system with autonomous computing tasks can be reduced. For instance, as described herein, a remote autonomous vehicle assistance computing system can track assisted autonomy tasks performed by the autonomous vehicle assistance computing system. The assisted autonomy tasks can be facilitated by a plurality of operators including human operators and/or computer-based operators. The autonomous vehicle assistance system can generate operator attributes for individual operators based on tracking assisted autonomy tasks. Request parameters can be determined from future requests for remote operator assistance received by the autonomous vehicle assistance system. The autonomous vehicle assistance system can determine request parameters associated with the requests for autonomous vehicle assistance. The request parameters can be compared with the operator attributes so that an operator having experience or familiarity associated with the request parameters can be selected to facilitate assisted autonomy tasks in response to the request for autonomous vehicle assistance. By correlating operator attributes and request parameters, a remote operator can be selected that is more likely to be able to assist with a request for remote operator assistance. This can minimize downtime where the autonomy computing system of an autonomous vehicle remains idle and is unable to provide vehicle services. Such examples represent a waste of computer resources and/or bandwidth. By more precisely correlating requests for autonomous vehicle assistance with operators, the amount of computing resources and bandwidth required for systems can be reduced. Such techniques may provide a better user experience by reducing the amount of time that an autonomous vehicle remains idle. Moreover, such solutions can alleviate congestion within geographical areas that may be associated with a non-moving vehicle or a vehicle not efficiently proceeding along a route.”)
Regarding claim 11, it recites a non-transitory computer readable medium having limitations similar to those of claim 1 and therefore is rejected on the same basis.
Additionally Goldman teaches A non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process, the process comprising:
{para [0053] “The remote operation system 112 can include processor(s) 234, memory 236, and input/output component(s) 238. The remote operation system 112 is configured to receive information (e.g., data) from vehicles as well as requests for assistance. The remote operation system 112 is configured to receive the data and the requests from a fleet of vehicle systems 202. The fleet of vehicles may convey, at or around the same time, the data and/or the requests for assistance. The data allows the remote operation system 112 to discover all vehicles as well as their status. For example, upon receipt of the data, the remote operation system 112 may understand where the vehicles are located, a current state of vehicle, such as speed, heading, location, whether a remote operator is connected to the vehicle, health status of modems, a mission type of the vehicle, and so forth. In some examples, knowing the location of the vehicle, the remote operation system 112 may determine a geofence of the vehicle, or what geofence the vehicle is in. The geofence, in some examples, may be associated with a city, town, municipal, and the like, a geographical area, blocks, zip codes, and so forth. Discussed herein, the geofence may be used to match requests for assistance with a remote operator, given a familiarity or preference of the remote operator. In some examples, the data may be received on a continual and predetermined basis, such as every 100 milliseconds, every second, and so forth.”
}
Regarding claim 12, it recites A system having limitations similar to those of claim 1 and therefore is rejected on the same basis.
Additionally Goldman teaches A system for contextual distribution of remote driving and remote assistance requests, comprising: a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to:
{para [0053] “The remote operation system 112 can include processor(s) 234, memory 236, and input/output component(s) 238. The remote operation system 112 is configured to receive information (e.g., data) from vehicles as well as requests for assistance. The remote operation system 112 is configured to receive the data and the requests from a fleet of vehicle systems 202. The fleet of vehicles may convey, at or around the same time, the data and/or the requests for assistance. The data allows the remote operation system 112 to discover all vehicles as well as their status. For example, upon receipt of the data, the remote operation system 112 may understand where the vehicles are located, a current state of vehicle, such as speed, heading, location, whether a remote operator is connected to the vehicle, health status of modems, a mission type of the vehicle, and so forth. In some examples, knowing the location of the vehicle, the remote operation system 112 may determine a geofence of the vehicle, or what geofence the vehicle is in. The geofence, in some examples, may be associated with a city, town, municipal, and the like, a geographical area, blocks, zip codes, and so forth. Discussed herein, the geofence may be used to match requests for assistance with a remote operator, given a familiarity or preference of the remote operator. In some examples, the data may be received on a continual and predetermined basis, such as every 100 milliseconds, every second, and so forth.”
}
Regarding claim 13, it recites A system having limitations similar to those of claim 2 and therefore is rejected on the same basis.
Regarding claim 17, it recites A system having limitations similar to those of claim 6 and therefore is rejected on the same basis.
Regarding claim 19, it recites A system having limitations similar to those of claim 8 and therefore is rejected on the same basis.
Regarding claim 20, it recites A system having limitations similar to those of claim 9 and therefore is rejected on the same basis.
Regarding claim 21, it recites A system having limitations similar to those of claim 10 and therefore is rejected on the same basis.
Claim(s) 4-5, 7, 15-16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over by Goldman et al. (US 20240036571 A1, hereinafter known as Goldman) in view of Chen et al. (US 20200272949 A1, hereinafter known as Chen), Blanc et al. (US 20230189763 A1; hereinafter known as Blanc), and Foy et al. (US 20240098464 A1, hereinafter known as Foy).
Regarding claim 4, Goldman in view of Chen and Blank teaches The method of claim 1.
Goldman in view of Chen and Blank does not teach, generating at least one parallel flow for the plurality of requests based on at least one parallel flow trigger, wherein the distribution is determined based further on the at least one parallel flow.
However, Foy teaches generating at least one parallel flow for the plurality of requests based on at least one parallel flow trigger, wherein the distribution is determined based further on the at least one parallel flow.
{Para [0168] “FIG. 8 is a flowchart of a method 800 of selected aspects of providing an onboard assistant. In some embodiments of an onboard assistant, all calls—or at least all calls of a certain type—may be created as conference calls. For example, any rider service calls or calls for remote assistance may be created as conference calls. This allows the AV operator to seamlessly add new participants to the call, such as a different rider service agent, a rider service expert, a rider service manager, or others. The AV operator can also add other parties to the call, such as emergency services, towing services, user contacts, or others without ever having to place the passenger on hold. When calls are created as conference calls, parties can be added and removed from the call seamlessly without interrupting the call. The AV operator in some embodiments is a back-end platform having computing systems implementing functionalities for setting up and managing the conference calls. In those embodiments, the AV operator does not require human intervention or input when managing these conference calls and participants thereof. The AV operator in these embodiments is not intended to be a human rider service representative.”
A conference call can be considered as a parallel flow as it is involving two assisting entities simultaneously.
The operator is a routing system not necessarily the operator that performs the assistance.
If the distribution includes the parallel flow, the distribution can be said to be based on the parallel flow.
}
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Goldman in view of Chen and Blank to incorporate the teachings of Foy to initiate parallel flow with a conference call because as discussed to in para [0127-0128] “To resolve a detected alert condition, the onboard assistant may cause a call to be placed between a rider/or AV and a rider service center, which may be initiated by the AV operator in some cases, as a conference call. The AV operator being the manager and initiator of the conference call can offer benefits of greater control and intelligence for how the alert condition should be resolved, and what data should be exchanged for a given situation. Some benefits are mentioned below. One, the AV operator is in control of who the parties are for the conference call, and rider intervention or initiation is not required. Moreover, the rider does not need to wait to be connected. The conference call can place the passenger in contact with a rider service agent, as well as other services, such as first responders, emergency services, technical support, or others depending on the nature of the alert condition. Two, the AV operator has control over who should be added to or removed from the conference call, and is not limited by the number participants to a call (e.g., from no participants, to 10 participants if needed or desired). Three, the AV operator can control when the call should be terminated. Four, the AV operator manages and has access to the data associated with riders and AVs (including privacy preferences or user settings/contacts of the riders), and can judiciously select what data to share with a given party to the conference call accordingly.”
Regarding claim 5, Goldman in view of Chen and Blank teaches The method of claim 1.
Goldman in view of Chen and Blank does not teach, wherein the plurality of requests is transmitted via a first system, wherein at least a portion of the at least one parallel flow is transmitted via a second system.
However, Foy teaches wherein the plurality of requests is transmitted via a first system, wherein at least a portion of the at least one parallel flow is transmitted via a second system.
{Para [0168] “FIG. 8 is a flowchart of a method 800 of selected aspects of providing an onboard assistant. In some embodiments of an onboard assistant, all calls—or at least all calls of a certain type—may be created as conference calls. For example, any rider service calls or calls for remote assistance may be created as conference calls. This allows the AV operator to seamlessly add new participants to the call, such as a different rider service agent, a rider service expert, a rider service manager, or others. The AV operator can also add other parties to the call, such as emergency services, towing services, user contacts, or others without ever having to place the passenger on hold. When calls are created as conference calls, parties can be added and removed from the call seamlessly without interrupting the call. The AV operator in some embodiments is a back-end platform having computing systems implementing functionalities for setting up and managing the conference calls. In those embodiments, the AV operator does not require human intervention or input when managing these conference calls and participants thereof. The AV operator in these embodiments is not intended to be a human rider service representative.”
Para [0054] “In some cases, a data service 324 may provide information to AV operator 308 and/or service team 314. For example, the passenger may book a ride with a ride-hail vehicle via a ride-hail application. The application may include a user account, wherein the rider opts to provide to provide and share certain information with AV operator 308. Information could include personally identifying information (PII) about the passenger, a phonebook of contacts, an emergency contact, user preferences, common routes and destinations, or similar. AV operator 308 may share information from data service 324 according to the terms of a license agreement, and according to a present need. For example, if service team 314 needs information from data service 324, then AV operator 308 may provide the information to service team 314.”
Para [0055] “In the case of an emergency, it may be desirable to provide other connections. For example, AV operator 308 may communicate with emergency services 316 to dispatch emergency crews to a current location of AV 306 to assess the situation and to provide aid to the passenger as necessary. AV operator 308 may cooperate with emergency response module 228 of FIG. 2 to provide information to emergency services 316 to facilitate dispatch of emergency crews or other emergency services. In some cases, data service 324 may include a list of known passenger contacts 320, or the passenger may use a mobile device such as a cell phone to share emergency contact with the onboard assistant. In the case of an emergency, AV operator 308 may contact an emergency contact on behalf of the passenger.”
A conference call can be considered as a parallel flow as it is involving two assisting entities simultaneously.
Where a service team and emergency services are separate entities and thus would be using separate systems during a conference call.
}
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Goldman in view of Chen and Blank to incorporate the teachings of Foy to initiate parallel flow with a conference call because as discussed to in para [0127-0128] “To resolve a detected alert condition, the onboard assistant may cause a call to be placed between a rider/or AV and a rider service center, which may be initiated by the AV operator in some cases, as a conference call. The AV operator being the manager and initiator of the conference call can offer benefits of greater control and intelligence for how the alert condition should be resolved, and what data should be exchanged for a given situation. Some benefits are mentioned below. One, the AV operator is in control of who the parties are for the conference call, and rider intervention or initiation is not required. Moreover, the rider does not need to wait to be connected. The conference call can place the passenger in contact with a rider service agent, as well as other services, such as first responders, emergency services, technical support, or others depending on the nature of the alert condition. Two, the AV operator has control over who should be added to or removed from the conference call, and is not limited by the number participants to a call (e.g., from no participants, to 10 participants if needed or desired). Three, the AV operator can control when the call should be terminated. Four, the AV operator manages and has access to the data associated with riders and AVs (including privacy preferences or user settings/contacts of the riders), and can judiciously select what data to share with a given party to the conference call accordingly.”
Regarding claim 7, Goldman teaches The method of claim 1.
Goldman in view of Chen and Blank does not teach, further comprising:generating at least one additional instance for each of the at least one first request, wherein the distribution is determined based further on the at least one additional instance generated for each of the at least one first request.
However, Foy teaches further comprising: generating at least one additional instance for each of the at least one first request, wherein the distribution is determined based further on the at least one additional instance generated for each of the at least one first request.
{Para [0168] “FIG. 8 is a flowchart of a method 800 of selected aspects of providing an onboard assistant. In some embodiments of an onboard assistant, all calls—or at least all calls of a certain type—may be created as conference calls. For example, any rider service calls or calls for remote assistance may be created as conference calls. This allows the AV operator to seamlessly add new participants to the call, such as a different rider service agent, a rider service expert, a rider service manager, or others. The AV operator can also add other parties to the call, such as emergency services, towing services, user contacts, or others without ever having to place the passenger on hold. When calls are created as conference calls, parties can be added and removed from the call seamlessly without interrupting the call. The AV operator in some embodiments is a back-end platform having computing systems implementing functionalities for setting up and managing the conference calls. In those embodiments, the AV operator does not require human intervention or input when managing these conference calls and participants thereof. The AV operator in these embodiments is not intended to be a human rider service representative.”
Where each connection in a conference call can be considered as an instance, and in the conference call multiple connections are being established
If the distribution includes additional instance, the distribution can be said to be based on the instance.
}
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Goldman in view of Chen and Blank to incorporate the teachings of Foy to initiate parallel flow with a conference call because as discussed to in para [0127-0128] “To resolve a detected alert condition, the onboard assistant may cause a call to be placed between a rider/or AV and a rider service center, which may be initiated by the AV operator in some cases, as a conference call. The AV operator being the manager and initiator of the conference call can offer benefits of greater control and intelligence for how the alert condition should be resolved, and what data should be exchanged for a given situation. Some benefits are mentioned below. One, the AV operator is in control of who the parties are for the conference call, and rider intervention or initiation is not required. Moreover, the rider does not need to wait to be connected. The conference call can place the passenger in contact with a rider service agent, as well as other services, such as first responders, emergency services, technical support, or others depending on the nature of the alert condition. Two, the AV operator has control over who should be added to or removed from the conference call, and is not limited by the number participants to a call (e.g., from no participants, to 10 participants if needed or desired). Three, the AV operator can control when the call should be terminated. Four, the AV operator manages and has access to the data associated with riders and AVs (including privacy preferences or user settings/contacts of the riders), and can judiciously select what data to share with a given party to the conference call accordingly.”
Regarding claim 15, it recites A system having limitations similar to those of claim 4 and therefore is rejected on the same basis.
Regarding claim 16, it recites A system having limitations similar to those of claim 5 and therefore is rejected on the same basis.
Regarding claim 18, it recites A system having limitations similar to those of claim 7 and therefore is rejected on the same basis.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Keane et al. (US 20160328890 A1) teaches in para [0020] “The digital processors in the diagnostic analysis system 104 execute stored software program instructions to implement servers for communications with the computing devices of customers and third parties, databases to store and index data that are received from the customers and third-parties, and optionally one or more analysis engines that perform data analysis and generate reports, summarizations, and other analysis output for review by the customers and third parties. In one embodiment, the maintenance analysis service implements a public application programming interface (API) that is freely accessible to different customers. Examples of protocols that are suitable for the implementation of the public API between the diagnostic analysis system 104, diagnostic tools, and listeners include the XML-RPC, JSON-RPC, and SOAP protocols, which are examples of web-service protocols, and other middleware protocols including, but not limited to, traditional RPC, Java RMI, CORBA, and the like. In the embodiment of FIG. 1, the public API provides a common data format and interface for transmission of diagnostic data from one or more diagnostic tools from each customer, including the diagnostic tools 116A-116C and 120A-120C for customers 114 and 118, respectively, to the diagnostic analysis system 104 for storage.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALEXANDER MATTA whose telephone number is (571)272-4296. The examiner can normally be reached Mon - Fri 10:00-6:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, James Lee can be reached at (571) 270-5965. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/A.G.M./Examiner, Art Unit 3668
/JAMES J LEE/Supervisory Patent Examiner, Art Unit 3668
Prosecution Insights