DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the application filed on 26 November 2024
Claims 12-20 are hereby withdrawn.
Claims 1-20 are currently pending and Claims 1-11 have been examined below.
Election/Restrictions
Applicant’s election without traverse of Group I Claims 1-11 in the reply filed on 7 April 2026 is acknowledged.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 3 December 2024 and 13 March 2026 (2) were filed after the mailing date of the initial disclosure. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
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.
Claims 1-11 are rejected under 35 U.S.C. 101 because the claimed invention, “Vehicle-Based Work Application with Virtual Assistant”, is directed to an abstract idea, specifically Certain Methods of Organizing Human Activity, without significantly more. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements individually or in combination provide mere instructions to implement the abstract idea on a computer.
Step 1: Claims 1-11 are directed to a statutory category, namely a machine/system.
Step 2A (1): Independent claim 1 is directed to an abstract idea of Certain Methods of Organizing Human Activity, based on the following paraphrased claim limitations: receiving a selection of a work item, generating work item information, providing the work item information, obtaining work item progress information and performing an action based on the information. These claims describe gathering or observing data and information and performing an action. Dependent claims 2-11 further narrow the recited abstract idea by describing additional determining, starting and obtaining functions. Selecting work items and providing routing, access, and equipment instructions for the work location reflect certain methods of organizing human activity. Therefore, these limitations, under the broadest reasonable interpretation, fall within the abstract grouping of Certain Methods of Organizing Human Activity which encompasses managing personal behavior or relationships or interactions between people including social activities, teaching, and following rules or instructions. Certain Methods of Organizing Human Activity can encompass the activity of a single person (e.g. a person following a set of instructions), activity that involve multiple people (e.g. a commercial interaction), and certain activity between a person and a computer (e.g. a method of anonymous loan shopping). Therefore, claims 1-11 are directed to an abstract idea and are not patent eligible.
Step 2A (2): This judicial exception is not integrated into a practical application. In particular, claims 1-11 recite additional elements of performing steps “by a machine learning application”, interfacing with an external system, generating a geofence, providing a notification, using an AI model or LLM, performing steps automatically, transmitting information externally and receiving from devices.
These additional elements do not integrate the abstract idea into a practical application because the claims do not recite (a) an improvement to another technology or technical field and (b) an improvement to the functioning of the computer itself and (c) implementing the abstract idea with or by use of a particular machine, (d) effecting a particular transformation or reduction of an article, or (e) applying the judicial exception in some other meaningful way beyond generally linking the use of an abstract idea to a particular technological environment. These additional elements evaluated individually and in combination are viewed as computing and display devices that are used to perform the abstract process identified in Step 2A (prong 1). The use of machine learning models, AI and performing steps automatically are considered instructions to apply or implement a model on a computer. Limitations that recite mere instructions to implement an abstract idea on a computer or merely uses a computer as a tool to perform an abstract idea are not indicative of integration into a practical application (see MPEP 2106.05(f)). Also limitations that amount to merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application (see MPEP 2106.05(h)). The ability to receive, interface, generate/output/provide/transmit are considered insignificant extra solution activity because they recite mere data gathering and transmission. Therefore, claims 1-11 do not include individual or a combination of additional elements that integrate the judicial exception into a practical application and thus are not patent eligible.
Step 2B: The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Claims 1-11 recite additional elements as stated above in Step 2A(2). These additional elements evaluated individually and in combination are viewed as mere instructions to apply or implement the abstract idea on a computer. Applying an abstract idea on a computer does not integrate a judicial exception into a practical application or provide an inventive concept (see MPEP 2106.05(f)). Therefore, claims 1-11 do not include individual or a combination of additional elements that are sufficient to amount to significantly more than the judicial exception and thus are not patent eligible.
For the steps that were considered extra solution activity in Step 2A, these have been re-evaluated in Step 2B and determined to be well-understood, routine and conventional activities in the field. The specification does not provide any indication that the system and network comprise anything other then generic off the shelf computer components and the Symantec, TLI and OIP Techs. court decisions in MPEP 2106.05d indicate that the mere collection, receipt and transmission of data over a network is a well-understood, routine and conventional function when claimed in a merely generic manner as it is here. Accordingly, Claims 1-11 do not recite an invention concept and are not patent eligible.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 4-5 and 8 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Beth et al. (US 2022/0156665 A1).
As per Claim 1 Beth teaches:
A vehicle system comprising: at least one processing circuit having at least one processor and at least one memory having instructions stored thereon that, when executed by the at least one processor (Beth in at least FIG. 1 teaches an example system/platform 100 may integrate various software modules for representing and controlling manned and unmanned vehicles and provide them to a user such that they are available for mission planning, building, simulation or execution [0045], FIGS. 7-25, the platform 100 may provide a user interface, e.g., as a web application graphical user interface (GUI) provided in an internet browser, to permit a user to build a workflow or streamline together multiple tasks for multiple agents for a mission into a template (“workflow”, “maneuver” and/or “mission”) [0064]. In embodiments, one or more machine learning techniques, e.g., back propagation, may be used to tune the parameters of a service and/or microservice for scheduling efficiency with respect to the scheduling of agents [0055], the platform 100 provides scheduling and routing to devices in one or more locations to deconflict traffic, reduce congestion, prioritize certain traffic, missions or tasks, or otherwise facilitate coordinated and regulated movement for the devices [0056].), cause the at least one processor to:
receive a selection of a work item (Beth e.g. In embodiments, one or more machine learning techniques, e.g., back propagation, may be used to tune the parameters of a service and/or microservice for scheduling efficiency with respect to the scheduling of agents [0055]. In embodiments, following the obtaining at 402, a vehicle is identified at 404, e.g., vehicle 102 is identified by the platform due to the coded information scanned and transmitted via the mobile application running on the operator's mobile phone [0059]. This may provide for the platform 100 to identify mission part(s) associated with the vehicle 102, as indicated at 406 [0059]. For example, a predetermined mission may be planned for a manned vehicle, e.g., vehicle 102, on the basis of one or more factors present when the scanned code data is obtained by the platform 100. Non-limiting examples of the one or more factors include time, location, last mission, last mission status, mission imported from an external system, etc. [0059]. During the planning, the platform 100 may act to facilitate the formation of the business workflow or process, e.g., by identifying one or more vehicles, e.g., vehicles 102, 103, 104 or 106, that are available for use in the location 108, capable of performing the business workflow or process, etc. [0087].);
generate, by a machine learning application, work item information associated with the work item (Beth e.g. The mission may be built using a platform via a workflow designer tool [0008]. In some embodiments, missions are for manned and/or unmanned vehicles in private locations, such as ports, where the mission includes performance of tasks such as container or asset location, pickup, and relocation, with reporting to a back-end system such as a logistics tracking and reporting software [0008]. As used herein, the terms “workflow” and “maneuver” refer to the collection of tasks and/or processes forming part of a mission, i.e., an objective, e.g., inspecting one or more towers on a power line, loading a vessel with cargo and/or unloading the cargo from the vessel, etc. [0008]. Non-limiting examples of a task include: navigating to a waypoint; taking an image of an object; picking up an object; dropping off an object; etc.[0008]. Embodiments of the platform may provide for a user to enter in basic information about a workflow, wherein the platform is able to generate and/or otherwise determine the details for executing the workflow. For example, a user may specify a few details for a workflow such as Ship A needs to be unloaded by time X [0008]. Referring to FIGS. 1 and 4, collectively, mission data may be obtained by the platform 100. In other aspects, mission data may be obtained at 402 in other ways. For example, mission data may be obtained automatically as a subtask within a mission protocol or workflow, may be created by an intelligent process, such as an automated process that detects a vehicle is incompatible or conditionally incompatible, such as low on fuel, and automatically suggests a substitute vehicle, as further described herein [0058].);
provide, by the machine learning application, the work item information to a user of a vehicle (Beth e.g. The workflow designer tool may permit a user to plan a mission via selecting vehicles and mission parts or tasks. The platform may provide listings of vehicles that are compatible with one another and the platform, along with listing the vehicles' capabilities, to facilitate mission planning [0008]. The platform may have access to one or more agents, e.g., vehicles, that may be electrically powered, wherein the system automatically generates and coordinates a schedule for the agents to unload Ship A by time X with the agents performing electrical recharges [0008]. In some embodiments, the platform 100 provides scheduling and routing to devices in one or more locations to deconflict traffic, reduce congestion, prioritize certain traffic, missions or tasks, or otherwise facilitate coordinated and regulated movement for the devices [0056].);
obtain, by the machine learning application, work item progress information associated with the work item; and perform, by the machine learning application, an action based on one of the work item information or the work item progress information (Beth e.g. Referring to FIGS. 1 and 4, collectively, mission data may be obtained by the platform 100. As shown in FIG. 4, in the non-limiting example of routing for a manned vehicle, mission data may be obtained at 402 by the platform in a variety of ways [0058]. In embodiments, following the obtaining at 402, a vehicle is identified at 404, e.g., vehicle 102 is identified by the platform due to the coded information scanned and transmitted via the mobile application running on the operator's mobile phone [0059]. This may provide for the platform 100 to identify mission part(s) associated with the vehicle 102, as indicated at 406 [0059]. In a non-limiting example of a multi-vehicle mission, a vehicle may be determined to be incompatible or conditionally incompatible, such as low on fuel. In such a circumstance, the platform 100 may automatically suggest a substitute vehicle as indicated at 404, respond to a vehicle's request for assistance, etc. [0059]. During performance, the platform 100 may act to track and update the progress of the business workflow or process, e.g., by providing updated map state information that corresponds to performance or completion of a mission part, a workflow, and/or a stage thereof [0087]. As such, users and/or subscribers of the ERP or logistics application provided by remote device 128 may be notified or kept up to date with the mission progress, any difficulties encountered, etc. [0087]. In a manned vehicle routing non-limiting example, a manned vehicle's routing instructions may be adjusted or modified based on real-time or near real-time data, such as obtained from other vehicles in the environment [0063]. As will be appreciated, this may provide for adjustment or modification to the mission protocol or part thereof, such as updated routing guidance based on human operator inputs (e.g., human operator deviating from a location of the route or timing thereof), based on unmanned vehicle locations or behaviors (e.g., movement to avoid one another or the manned vehicle, vehicle requests or offers assistance, etc.) [0063]. As further described herein, adjustments or modifications to routing or other mission data may be accomplished using a variety of inputs from vehicles, human operators, or a combination thereof, which are provided as input to intelligent processes that are configured for dynamic mission updates, e.g., for handling complex traffic and congestion management tasks [0063]. In certain aspects, identifying the manned vehicle may be performed via scanning a manned vehicle identification number in a bar-code attached to or associated with the manned vehicle [0159]. In certain aspects, identifying the manned vehicle may further include obtaining GPS position data of the manned vehicle and/or geographic data surrounding the manned vehicle. In certain aspects, the manned vehicle is a car, truck, or drone [0159].).
As per Claim 2 Beth further teaches:
wherein generating the work item information includes generating a route from a vehicle location to a location of the work item (Beth e.g. In an embodiment, the data of the location 108 and its content (vehicles, assets, environmental information, etc.) may be made available for display by the platform 100 to an end user device, such as a mobile device of an operator of a vehicle, e.g., vehicle 102, at the location 108. In certain aspects, a routing for manned vehicle, e.g., vehicle 102, is provided by the platform 100 [0057]. In the non-limiting example of providing routing for a manned vehicle, the platform 100 obtains routing data at 412. Here, the platform 100 may have access to data indicating a route 116 leading from vehicle 102 to container 114. This routing data may be associated with a mission part, e.g., the picking part of the mission, as indicated at 414 [0060]. Further, because platform 100 may continually, periodically, or intermittently update its mapping information or state for the location 108, the platform 100 may have access to additional data that is useful in scheduling and/or routing [0060]. For example, in generating routing data and/or scheduling data, e.g., for vehicle 102, the platform 100 may be able to perform a check to determine that the route 116 is currently occupied by another vehicle, e.g., vehicle 106, according to the platform's current map state. Therefore, platform may choose a different or alternative route 126 for the vehicle 102 to complete its mission so as to avoid other vehicles, e.g., vehicle 106, and zones that are prohibited, e.g., 118, 120. The platform 100 may then generate the routing data at 416 for the mission [0060]. In embodiments, the routing data may be provided to the operator's mobile phone for display of routing guidance in the mobile application, as indicated at 424. In one non-limiting example, the platform 100 may provide or output at 424 displayable data or coordinate data that is combined with displayable data resident at the mobile phone application of the operator in the form of a map to provide turn-by-turn directions for guiding the operator of vehicle 102 to container 114 and any other part of the mission, e.g., to the delivery location [0062]. The routing device may be further configured to display the specific mission and the recommended routing data for the identified manned vehicle on a screen of the routing device. In certain aspects, the routing device may display this data along with moving statuses of other manned vehicle(s) and/or the unmanned vehicle(s) on the map of the private or the closed location [0159].).
As per Claim 4 Beth further teaches:
wherein generating the work item information further includes creating, by the machine learning application, a geofence around the location of the work item (Beth e.g. Additional environmental information may be available to the platform 100, e.g., preferred or required routes, paths or roads 116, designated areas where vehicles are not permitted 118, 120, physical boundaries 122, e.g., between land and water, geofence location 124, etc. [0045]. In certain aspects, a mobile application running on the mobile device of the operator may be authenticated once during sign on or authenticated via the location of the mobile device, e.g., within a geofence such as 124, in proximity to vehicle 102, etc. [0058].).
As per Claim 5 Beth further teaches:
wherein obtaining the work item progress information includes: determining, by the machine learning application, that the vehicle has reached the location of the work item based on crossing the geofence around the location of the work item (Beth e.g. Additional environmental information may be available to the platform 100, e.g., preferred or required routes, paths or roads 116, designated areas where vehicles are not permitted 118, 120, physical boundaries 122, e.g., between land and water, geofence location 124, etc. [0045]. This environmental information may be provided to the platform from the owner or operator of the location 108, from a site visit to the location 108, from an external source (e.g., satellite imagery or mapping service data), produced synthetically, e.g., for a simulated location, or a combination of the foregoing [0045]. In an embodiment, the data of the location 108 and its content (vehicles, assets, environmental information, etc.) may be made available for display by the platform 100 to an end user device, such as a mobile device of an operator of a vehicle, e.g., vehicle 102, at the location 108 [0057]B. In certain aspects, a mobile application running on the mobile device of the operator may be authenticated once during sign on or authenticated via the location of the mobile device, e.g., within a geofence such as 124, in proximity to vehicle 102, etc. [0058].); and starting a tracking timer to track a duration of the work item (Beth e.g. During the planning, the platform 100 may act to facilitate the formation of the business workflow or process, e.g., by identifying one or more vehicles, e.g., vehicles 102, 103, 104 or 106, that are available for use in the location 108, capable of performing the business workflow or process, etc. [0087]. During performance, the platform 100 may act to track and update the progress of the business workflow or process, e.g., by providing updated map state information that corresponds to performance or completion of a mission part, a workflow, and/or a stage thereof [0087]. For example, upon completion of a mission part, e.g., sending a vehicle to pick a container such as container 114, the platform 100 may update its map state, as outlined for example in FIG. 5, and thereafter trigger a data output, such as in indication or an alert, to an external system, e.g., remote device 128, which may be an ERP or logistics application server hosting associated software [0087]. In some embodiments, workflows or missions may be scheduled, e.g., to take place at a specific time, to recur, to begin after completion of a related mission or detection of the presence of an object such as cargo being situated in a given location, such as detected using computer vision and object detection [0088].).
As per Claim 8 Beth further teaches:
wherein the machine learning application includes one or more of a generative artificial intelligence model or a large language model configured to provide a voice-based or text-based chat-bot or virtual assistant (Beth in at least [0055] describes machine learning techniques and [0117] describes including artificial intelligence, [0147] describes voice assistants)
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, 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 3 is rejected under 35 U.S.C. 103 as being unpatentable over Beth et al. (US 2022/0156665 A1) in view of Beaurepaire (US 2017/0146350 A1).
As per Claim 3 Beth further teaches determining using machine learning models a route that includes both public and private locations. Embodiments of the system provide an interface for accessing mapping, routing and scheduling data, including for use indoors, at private or campus locations, and/or other areas/locations that typically are not mapped [0007]. The platform may provide listings of vehicles that are compatible with one another and the platform, along with listing the vehicles' capabilities, to facilitate mission planning In some embodiments, missions are for manned and/or unmanned vehicles in private locations, such as ports, where the mission includes performance of tasks such as container or asset location, pickup, and relocation, with reporting to a back-end system such as a logistics tracking and reporting software [0008]. Still yet other embodiments may provide for a routing device for a manned vehicle in a private or a closed location, e.g., a campus [0159]. In certain aspects, the specific mission may include: a mission to deliver an asset, cargo or luggage from a first position to a second position in the private or closed location; recommended routing data from the first to the second position, wherein, in certain aspects, the moving of the manned vehicle can be traced/updated live/real-time; map data of the location, which may be stored in an application installed and/or executing at the routing device; and/or moving statuses of other manned vehicle(s) and/or unmanned/autonomous vehicle(s) in the location [0159]. In embodiments, the recommended routing data may be determined at the cloud server so that a specific project may be effectively orchestrated in a manned and an unmanned/autonomous vehicles mixed situation by a routing algorithm (potentially using AI/ML) [0159].)
Beth does not explicitly recite but Beaurepaire further teaches:
wherein generating the work item information includes: determining, by the machine learning application, that the route requires access credentials for entering an area of a building; and interfacing, by the machine learning application, with an external system to request the access credentials for the user (Beaurepaire e.g. In one embodiment, the access management platform 109 may identify one or more restricted access area(s) along the route. Then, the access management platform 109 may query whether the at least one user has the required permission to access the at least one access restricted location. The access management platform 109 may determine that the at least one user does not have the required permission, whereupon the access management platform 109 requests for access rights from an authorized user before the user embarks towards a particular destination and/or when the navigation starts [0041]. In one example embodiment, when a visitor (User A) enters the destination information (e.g., home location of user B) in a navigation application, the routing algorithm checks whether there is any area with restricted access on the suggested route. If restricted areas exist, and user A does not have access rights, the application automatically sends a request to the authorizing party (User B) for access rights to enter the restricted area. Subsequently, after receiving the access rights from authorizing party, the visitor can view indoor map data of the building. In another embodiment, the access management platform 109 may determine whether the at least one user is authorized to share the at least one route within a private venue and/or grant access right to a private venue [0041]. In another example embodiment, at least one building may be public during office hours (e.g., 9 a.m.-5 p.m.) but requires access rights beyond the office hours. The access management platform 109 may take into consideration the contextual parameters of the building, and may request for access rights for any users trying to access the building beyond regular office hours [0085].)
It would be obvious to one of ordinary skill in the art to modify Beth’s routing system to include determining that the route requires access credentials for entering an area of a building and interface with an external system to request the access credentials for the operator as taught by Beaurepaire in order to improve service providers timeliness (Beaurepaire e.g. [0001]).
Claims 6-7 and 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over Beth et al. (US 2022/0156665 A1) in view of Breaux, III et al. (US 2023/0156569 A1).
As per Claim 6 Beth teaches determine, using the one or more machine learning models, that the route passes through a hazard area (Beth e.g. In embodiments, the recommended routing data may be determined at the cloud server so that a specific project may be effectively orchestrated in a manned and an unmanned/autonomous vehicles mixed situation by a routing algorithm (potentially using AI/ML) [0159]. In certain aspects, non-limiting examples of data that may be referenced by the routing algorithm (with AI/ML system) include: live hazard or vehicle congestion in the location; statistic congestion data, e.g., by time; typical route(s) between position A and B;…[0159].)
Beth does not explicitly teach, however, Breaux teaches
wherein generating the work item information further includes: determining, by the machine learning application, that the route passes through an area requiring personal protection equipment; and providing, by the machine learning application, a notification to the user indicating that the area requires the personal protection equipment. (Breaux, III e.g. Yet another embodiment discloses a system having a processor and a memory storing program code, which, when executed on the processor, performs an operation for managing mobile device usage based on context [0007]. The operation itself includes detecting, by an application executing in the mobile device, an event to trigger context-based management of the mobile device [0007]. As used herein, the term “context” may include an environment, setting, or specific circumstances that surround an event, a sequence of events, or a collection of events. Context may include a location or relative location using technology such as GPS, GNSS, cell tower triangulation, BLUETOOTH beacons, WIFI, dead reckoning, image recognition, audio signatures, atmospheric pressure values, and other sensors known by those skilled in the art for understanding location or relative location [0031]. Context may also include attributes about an individual using a mobile device, such as age, job function, safety history, risk assessment, certification, security clearance, activity level, gait, heart rate, breathing rate, position (e.g. crouched, sitting, standing), exposure to hazardous chemicals, presence of personal protective equipment (PPE), presence of high sound levels, state of personal lighting devices [0031]. Context may also include attributes about the environment, such as time of day, lighting, current weather conditions, presence of hazardous chemicals or substances, high sound levels, presence of water, nearby active equipment, attributes of people, places, or things nearby, and sudden hazards or emergency situations [0031]. The management server 114 may be embodied as any physical computer (e.g., a desktop computer, workstation, laptop computer, and the like), a virtual server instance executing on the cloud, and the like, that is capable of performing the functions described herein, such as defining and managing network policies, generating one or more machine learning models for determining usage context, generating one or more machine learning models for determining user behavior and usage patterns, etc. [0033]. The management service 116 may send notifications such as reminders and alerts to the messaging component 514 based on a current usage context, such as reminders for required personal protective equipment (PPE), known hazard or risk alerts, relevant safety reminders, emergency and/or evacuation alert information, and the like [0059]. Further, the control application 104 may generate a prompt to ensure that a user acknowledges the determined policies. For example, the control application 104 may prompt the user to ensure that a personal protective equipment (PPE) is being worn, to ensure that job safety requirements are acknowledged, and the like [0084]. Yet another context may be triggered when the user and mobile device arrives at a given work site and enters a specified context domain [0085].)
It would be obvious to one of ordinary skill in the art to modify Beth’s routing system to determine that the route passes through an area requiring personal protection equipment and providing a notification to the work vehicle as taught by Breaux, III in order to ensure operator/driver safety.
As per Claim 7 Beth in at least [0149 and 0159] describes communicating using common spoken and written languages and the ability to provide audio data. Beth teaches selecting a work item is shown in Claim 1 above. Beth does not explicitly recite that the selection is received via verbal indication. However, Breaux further teaches:
wherein the selection of the work item is received via a verbal indication received from the user (Breaux in at least [0070] the ability to incorporate audio-in and audio-out devices such as a microphone and speaker devices used to receive and emit audio information).
It would be obvious to one of ordinary skill in the art to modify Beth’s selection receipt to include techniques for receiving verbal indications, audio and spoken audio input taught by Breaux, III in order to enable hands free interacts while operating a vehicle.
As per Claim 9 Beth in at least [0149 and 0159] describes communicating using common spoken and written languages and the ability to provide audio data. Beth teaches obtaining work item progress data is shown above. Beth does not explicitly recite that the obtained progress includes a verbal description. However, Breaux further teaches:
wherein obtaining work item progress includes receiving a verbal description of the work item progress from the user (Breaux in at least [0070] the ability to incorporate audio-in and audio-out devices such as a microphone and speaker devices used to receive and emit audio information).
Breaux is combined based on the reasons and rationale set forth in the rejection of Claim 7 above.
As per Claim 10 Beth further teaches:
wherein performing the action based on the work item progress information includes: automatically populating, by the machine learning application, at least one form associated with the work item and transmitting, by the machine learning application, the at least one form to an external system (Beth teaches that during performance, the platform 100 may act to track and update the progress of the business workflow or process, e.g., by providing updated map state information that corresponds to performance or completion of a mission part, a workflow, and/or a stage thereof [0087]. As such, users and/or subscribers of the ERP or logistics application provided by remote device 128 may be notified or kept up to date with the mission progress, any difficulties encountered, etc. [0087]. In a manned vehicle routing non-limiting example, a manned vehicle's routing instructions may be adjusted or modified based on real-time or near real-time data, such as obtained from other vehicles in the environment [0063]. As will be appreciated, this may provide for adjustment or modification to the mission protocol or part thereof, such as updated routing guidance based on human operator inputs (e.g., human operator deviating from a location of the route or timing thereof), based on unmanned vehicle locations or behaviors (e.g., movement to avoid one another or the manned vehicle, vehicle requests or offers assistance, etc.) [0063]. As further described herein, adjustments or modifications to routing or other mission data may be accomplished using a variety of inputs from vehicles, human operators, or a combination thereof, which are provided as input to intelligent processes that are configured for dynamic mission updates, e.g., for handling complex traffic and congestion management tasks [0063]. [0064-0069] describes the ability to provide a template that is preconfigured to include multiple tasks for a specific mission and can be further customized and using the templates so that certain information is pulled and input, then displayed and transmitted/output externally, In certain aspects, identifying the manned vehicle may be performed via scanning a manned vehicle identification number in a bar-code attached to or associated with the manned vehicle [0159]. In certain aspects, identifying the manned vehicle may further include obtaining GPS position data of the manned vehicle and/or geographic data surrounding the manned vehicle. In certain aspects, the manned vehicle is a car, truck, or drone [0159], .
Beth does not explicitly recite that the input is based on verbal descriptions of progress. However, Breaux in at least [0070] the ability to incorporate audio-in and audio-out devices such as a microphone and speaker devices used to receive and emit audio information.
Breaux is combined based on the reasons and rationale set forth in the rejection of Claim 7 above.
As per Claim 11 Beth in at least [0149 and 0159] describes communicating using common spoken and written languages and the ability to provide audio data. Beth does not explicitly recite progress received from remote communicating including an earpiece or mobile user device. However, Breaux further teaches:
wherein the verbal description of the work item progress is received from a remote communication device including at least one of an earpiece or a mobile user device (Breaux in at least [0070] the ability to incorporate audio-in and audio-out devices such as a microphone and speaker devices used to receive and emit audio information).
Breaux is combined based on the reasons and rationale set forth in the rejection of Claim 7 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHANIE Z DELICH whose telephone number is (571)270-1288. The examiner can normally be reached on Monday - Friday 7-3:30.
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, Rutao Wu can be reached on 571-272-6045. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/STEPHANIE Z DELICH/Primary Examiner, Art Unit 3623
Prosecution Insights