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 .
Claims 1-20 have been examined.
P = paragraph 5; e.g. p5 = paragraph 5.
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.
[FP 7.05 and 7.05.016 with explanation provided]
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites performing by an information processor, detecting an event, acquiring information, generating a prompt, inputting the prompt to a language model and executing an action.
The limitations of detecting an event, acquiring information, generating a prompt, inputting the prompt to a language model and executing an action as drafted, are processes that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components such as a generic processor. That is, other than reciting “by a processor,” nothing in the claim element precludes the step from practically being performed in the mind. For example, but for the “by a processor” language, “detecting an event, acquiring information, generating a prompt, inputting the prompt to a language model and executing an action” in the context of this claim encompasses the user, under its broadest reasonable interpretation, detecting in the mind, acquiring information, generating a prompt, inputting the prompt and executing the prompt covers performance of the limitation in the mind but for the recitation of generic computer components such as a generic processor. For example, but for the “by a processor” language, “detecting events, acquiring information” in the context of this claim encompasses the user detecting an event by eye, acquiring information by the mind and generating a prompt by the human mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components/processor, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claim only recites one additional element – using a processor to perform detecting an event, acquiring information, generating a prompt, inputting the prompt to a language model and executing an action. The processor is recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of detecting an event, acquiring information, generating a prompt, inputting the prompt to a language model and executing an action) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a processor to perform detecting an event, acquiring information, generating a prompt, inputting the prompt to a language model and executing an action amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claim is not patent eligible.
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(2) as being disclosed by Shetty et al. USPAP 2025/0136134.
As per claims 1, 8 and 15 Shetty discloses a method/apparatus/system performed by an information processing apparatus, the method comprising: detecting, based on vehicle information acquired from a vehicle, an occurrence of any of one or more events; acquiring user information and prompt generation information corresponding to the detected event; generating, using the acquired user information and the acquired
prompt generation information, a prompt to cause a first language model to output an action against the detected event (ab; p’s 7, 34, 114, 82-83, 98, 251; figures 3, 8);
paragraph 114 of Shetty discloses:
[0114] Additionally or alternatively, the operator alertness level detector 206 detects, again at a second time, the alertness level of the operator 502 as is illustrated in FIG. 5B. For example, using the DMS, the operator alertness level detector 206 may detect that the KSS level is now 4 “rather alert” (e.g., somewhat alert), which means that the driver 502 is now more alert relative to the state of the driver 502 in FIG. 5A. Such new KSS level 4 may also be provided to the language model(s) 226 as input. Responsively, the natural language response generator 232 generates a natural language response “Excellent! I'll also point out different tourist destinations along your route based on your interests.” Such natural language response may also be based on ingesting the personalized information 212 as an input (or partial input) from the personalized information extractor 210 (e.g., included in the “personalized information prompt” of input(s) 301) and/or the destination/travel route data 124 from the destination/travel route information extractor 122 (e.g., included in the “destination/travel route prompt” of the input(s) 301). Responsively, the natural language response generator 132 transmits such natural language response to the text-to-speech component 134, which converts, via the audio device 506, such response to the corresponding audio response 510. Responsively, in some embodiments, the personalized information extractor 210 searches in the personalized information 212 and/or contacts a music service to retrieve the operator 502's favorite upbeat music and/or user's interests with respect to tourist destinations (e.g., the operator may like the Grand Canyon). When such music and/or other interests are retrieved, the audio device 506 may then automatically play audio data representing the operator 502's favorite upbeat music. Additionally or alternatively the destination/travel route information extractor 122 and/or the personalized information extractor 210 may provide input travel route/destination and/or personalized information so that the operator 502 is notified of different tourist destinations along a route based on interests (e.g., notifying operator 502 that the next tourist area on his route is the Grand Canyon, which he is interested in).
inputting the prompt to the first language model; and executing the action based on output of the first language model in response to the prompt (p’s 114, 4, 28, 71, 94, 111, 154, 247; figures 1, 6).
Shetty discloses via figure 1:
PNG
media_image1.png
643
1000
media_image1.png
Greyscale
As per claims 2, 9 and 16 Shetty discloses creating, using a second language model stored in the information processing apparatus, the prompt generation information corresponding to the detected event (ab; p’s 7, 34, 82-83, 98, 251; figures 3, 8; p’s 114, 4, 28, 71, 94, 111, 154, 247; figures 1, 6) as per the discussion above and the rejection of corresponding parts of the claims above incorporated herein and further paragraph 4 of Shetty discloses:
[0004] Embodiments of the present disclosure relate to operator (e.g., driver) assistance using one or more language models (e.g., a Large Language Model (LLM)). For instance, some embodiments relate to providing-context specific information to an operator as part of a natural language dialogue or other natural language output. In an illustrative example, particular embodiments generate a natural language utterance (e.g., “as a reminder, there are lots of deer in this area”) based on extracting natural language text in a nearby traffic sign (e.g., a sign that reads “deer Xing”). Additionally or alternatively, some embodiments relate to engaging the operator (e.g., via a relevant conversation) based on operator monitoring. For instance, during long drives, a driver may become drowsy or may not otherwise be alert. As such, particular embodiments have the capability of engaging (e.g., starting or continuing a conversation) with the driver based on driver interests and/or in response to detecting a likelihood that the driver is getting drowsy.
As per claims 3, 10 and 17 Shetty discloses wherein the vehicle information includes an image of a user, voice of the user, a state of the vehicle, and route information on the vehicle (figures 1, 6; ab; p’s 7, 34, 82-83, 98, 251; figures 3, 8; p’s 114, 4, 28, 71, 94, 111, 154, 247) as per the discussion above and the rejection of corresponding parts of the claims above incorporated herein and further, Shetty discloses via p154:
[0154] One or more of the controller(s) 1036 may receive inputs (e.g., represented by input data) from an instrument cluster 1032 of the vehicle 1000 and provide outputs (e.g., represented by output data, display data, etc.) via a human-machine interface (HMI) display 1034, an audible annunciator, a loudspeaker, and/or via other components of the vehicle 1000. The outputs may include information such as vehicle velocity, speed, time, map data (e.g., the High Definition (“HD”) map 1022 of FIG. 10C), location data (e.g., the vehicle's 1000 location, such as on a map), direction, location of other vehicles (e.g., an occupancy grid), information about objects and status of objects as perceived by the controller(s) 1036, etc. For example, the HMI display 1034 may display information about the presence of one or more objects (e.g., a street sign, caution sign, traffic light changing, etc.), and/or information about driving maneuvers the vehicle has made, is making, or will make (e.g., changing lanes now, taking exit 34B in two miles, etc.).
As per claims 4, 11 and 18 Shetty discloses wherein the action includes: playing specific music; playing specific video; and displaying route guidance to a rest area (p’s 114, 4, 28, 71, 94, 111, 154, 247; figures 1, 6; ab; p’s 7, 34, 82-83, 98, 251; figures 3, 8) as per the discussion above and the rejection of corresponding parts of the claims above incorporated herein and further, Shetty discloses via p247:
[0247] The vehicle 1000 may further include the infotainment SoC 1030 (e.g., an in-vehicle infotainment system (IVI)). Although illustrated and described as a SoC, the infotainment system may not be a SoC, and may include two or more discrete components. The infotainment SoC 1030 may include a combination of hardware and software that may be used to provide audio (e.g., music, a personal digital assistant, navigational instructions, news, radio, etc.), video (e.g., TV, movies, streaming, etc.), phone (e.g., hands-free calling), network connectivity (e.g., LTE, Wi-Fi, etc.), and/or information services (e.g., navigation systems, rear-parking assistance, a radio data system, vehicle related information such as fuel level, total distance covered, brake fuel level, oil level, door open/close, air filter information, etc.) to the vehicle 1000. For example, the infotainment SoC 1030 may radios, disk players, navigation systems, video players, USB and Bluetooth connectivity, carputers, in-car entertainment, Wi-Fi, steering wheel audio controls, hands free voice control, a heads-up display (HUD), an HMI display 1034, a telematics device, a control panel (e.g., for controlling and/or interacting with various components, features, and/or systems), and/or other components. The infotainment SoC 1030 may further be used to provide information (e.g., visual and/or audible) to a user(s) of the vehicle, such as information from the ADAS system 1038, autonomous driving information such as planned vehicle maneuvers, trajectories, surrounding environment information (e.g., intersection information, vehicle information, road information, etc.), and/or other information.
As per claims 5, 12 and 19 Shetty discloses acquiring a reaction of a user to the action performed; and updating the user information based on the reaction of the user (figures 3, 8; p’s 114, 4, 28, 71, 94, 111, 154, 247; figures 1, 6; ab; p’s 7, 34, 82-83, 98, 251) as per the discussion above and the rejection of corresponding parts of the claims above incorporated herein and further, Shetty discloses via paragraph 7:
[0007] In order to produce natural language responses, the language model may ingest or receive various inputs (or portions of an input). For instance, the inputs may be or include various prompts that have been subject to prompt engineering, prompt-tuning, and/or fine-tuning to elicit suitable natural language responses using a Large Language Model (LLM). For example, where a natural language response concerns an operator's alertness level, the prompt that is provided to the language model may include personalized information (e.g., an indication that the driver likes sports team X), a representation of a detected (e.g., computed, inferred, etc.) alertness level of the operator (e.g., “the operator is extremely sleepy”), a natural language instruction, such as “start a conversation with the driver that aligns with the driver's interests,” a one-shot or few shot prompt example of representative inputs and/or outputs (e.g., example conversations initiated at the KSS level), and/or “send a control signal to honk the horn.” In response to the language model ingesting such prompt, the language model may output a natural language response, such as “I've just honked the horn because you are falling asleep. Can you name some players that have played for team X that have made it to the Hall of Fame?”
As per claims 6, 13 and 20 Shetty discloses wherein the controller is configured to: acquire a reaction of a user to the action performed; and when the reaction of the user is negative, generate, further using the reaction of the user, the prompt to cause the first language model to output the action against the detected event (p’s 7, 34, 82-83, 98, 251; figures 3, 8; p’s 114, 4, 28, 71, 94, 111, 154, 247; figures 1, 6; ab) as per the discussion above and the rejection of corresponding parts of the claims above incorporated herein and further, Shetty discloses via p111:
[0111] Responsively, the operator alertness level detector 206 sends such natural language phrase to the language model(s) 226, at which the prompt construction block(s) 226 generate the “operator alertness level prompt” of the input(s) 301, which includes the KSS level score natural language phrase. Responsively, the natural language response generator 132 generates a natural language response, such as “You appear to be very drowsy! May I play your favorite upbeat music?” Responsively, the natural language response generator 132 automatically transmits such response to the text-to-speech component 134, which converts such natural language response to the audio data response 504, such that the audio device 506 (e.g., a car speaker) outputs the audio data response 504 in the form of sound waves, which mirrors the response generated by the natural language response generator 232.
As per claims 7 and 14 Shetty discloses wherein each of the one or more events includes a priority level, and when two or more events of the one or more events have occurred simultaneously, the information processing apparatus is configured to generate the prompt based further on the priority level of each of the two or more events (p’s 96, 94, 93, ab; p’s 7, 34, 82-83, 98, 251; figures 3, 8; p’s 114, 4, 28, 71, 111, 154, 247; figures 1, 6) as per the discussion above and the rejection of corresponding parts of the claims above incorporated herein and further, Shetty discloses via p96:
[0096] Prompt tuning is the process of taking or learning the most effective prompts or cues (among a larger pool of prompts) and feeding them to the encoder/decoder block(s) 306 as task-specific context. For example, a common question or phrase—“What is my account balance?”—could be taught to the encoder/decoder block(s) 306 to help optimize the model and guide it toward the most desirable decision or corresponding outputs in 308. Unlike prompt engineering, prompt tuning is not about a user formulating a better question or making a more specific request. Prompt tuning means identifying more frequent or important prompts (e.g., which have higher node activation weight values) and training the encoder/decoder block(s) 306 to respond to those common prompts more effectively. The benefit of prompt tuning is that it may be used to modestly train models without adding any more input(s) 301 or prompts (unlike fine-tuning), resulting in considerable time and cost savings.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Shetty et al. USPAP 2025/0136134, and further in view of Wheeler et al. USPAP 2019/0279613.
As per claims 1, 8 and 15 Shetty discloses a method/apparatus/system performed by an information processing apparatus, the method comprising: detecting, based on vehicle information acquired from a vehicle, an occurrence of any of one or more events; acquiring user information and prompt generation information corresponding to the detected event; generating, using the acquired user information and the acquired
prompt generation information, a prompt to cause a first language model to output an action against the detected event (ab; p’s 7, 34, 114, 82-83, 98, 251; figures 3, 8);
paragraph 114 of Shetty discloses:
[0114] Additionally or alternatively, the operator alertness level detector 206 detects, again at a second time, the alertness level of the operator 502 as is illustrated in FIG. 5B. For example, using the DMS, the operator alertness level detector 206 may detect that the KSS level is now 4 “rather alert” (e.g., somewhat alert), which means that the driver 502 is now more alert relative to the state of the driver 502 in FIG. 5A. Such new KSS level 4 may also be provided to the language model(s) 226 as input. Responsively, the natural language response generator 232 generates a natural language response “Excellent! I'll also point out different tourist destinations along your route based on your interests.” Such natural language response may also be based on ingesting the personalized information 212 as an input (or partial input) from the personalized information extractor 210 (e.g., included in the “personalized information prompt” of input(s) 301) and/or the destination/travel route data 124 from the destination/travel route information extractor 122 (e.g., included in the “destination/travel route prompt” of the input(s) 301). Responsively, the natural language response generator 132 transmits such natural language response to the text-to-speech component 134, which converts, via the audio device 506, such response to the corresponding audio response 510. Responsively, in some embodiments, the personalized information extractor 210 searches in the personalized information 212 and/or contacts a music service to retrieve the operator 502's favorite upbeat music and/or user's interests with respect to tourist destinations (e.g., the operator may like the Grand Canyon). When such music and/or other interests are retrieved, the audio device 506 may then automatically play audio data representing the operator 502's favorite upbeat music. Additionally or alternatively the destination/travel route information extractor 122 and/or the personalized information extractor 210 may provide input travel route/destination and/or personalized information so that the operator 502 is notified of different tourist destinations along a route based on interests (e.g., notifying operator 502 that the next tourist area on his route is the Grand Canyon, which he is interested in).
inputting the prompt to the first language model; and executing the action based on output of the first language model in response to the prompt (p’s 114, 4, 28, 71, 94, 111, 154, 247; figures 1, 6).
Shetty discloses all the limitations of the invention, however, arguendo, if Shetty is or might be interpreted such that it might not explicitly disclose inputting prompt/voice command/request, then Wheeler discloses inputting prompt/voice command/request (p’s 33, 20, 23, 41, 31, 19, 6; ab; fig’s 4, 3). If this interpretation is taken, then it would have been obvious, before the effective filing date of the claimed invention, to modify Shetty to include inputting prompt/voice command/request such as that taught by Wheeler in order to identify the voice command 118 by utilizing the selected language and acoustic models to apply speech recognition (e.g., via speech-recognition software) to the audio signal 114. For example, the language controller 122 identifies that the voice command 118 includes a request for information and/or an instruction to perform a vehicle function. Example requested information includes directions to a desired location, information within an owner's manual of the vehicle 100 (e.g., a factory-recommended tire pressure), vehicle characteristics data (e.g., fuel level), and/or data stored in an external network (e.g., weather conditions). Example vehicle instructions include instructions to start a vehicle engine, lock and/or unlock vehicle doors, open and/or close vehicle windows, add an item to a to-do or grocery list, send a text message via the communication module 120, initiate a phone call, etc. (Wheeler, p33).
Wheeler discloses via p20:
[0020] Example methods and apparatus disclosed herein (1) utilize machine learning (e.g., a deep neural network) to identify a language and a dialect of a voice command provided by a user of a vehicle, (2) download a corresponding language model and a corresponding dialect acoustic model from a remote server to reduce an amount of vehicle memory dedicated to language and dialect acoustic models, and (3) performs speech recognition utilizing the downloaded language and dialect acoustic models to process the voice command of the user. Examples disclosed herein include a controller that receives a voice command from a user via a microphone of a vehicle. Based on the voice command, the controller identifies a language and a dialect that corresponds to the voice command. For example, the controller utilizes deep neural network model to identify the language and dialect corresponding to the voice command. Upon identifying the language and dialect of the voice command, the controller determines whether a corresponding language model and a corresponding dialect acoustic model is stored within memory of a computing platform of the vehicle. If the language model and/or the dialect acoustic model is not stored in the vehicle memory, the controller downloads the language model and/or the dialect acoustic model from a remote server and stores the downloaded language model and/or dialect acoustic model in the vehicle memory. Further, the controller utilizes the language model and the dialect acoustic model to perform speech recognition on the voice command. The vehicle provides requested information and/or performs a vehicle function based on the voice command. In some examples, the controller is configured to adjust default settings (e.g., a default language, radio settings, etc.) of the vehicle based on the identified language and dialect.
Shetty discloses via figure 1:
PNG
media_image1.png
643
1000
media_image1.png
Greyscale
As per claims 2, 9 and 16 Shetty discloses creating, using a second language model stored in the information processing apparatus, the prompt generation information corresponding to the detected event (ab; p’s 7, 34, 82-83, 98, 251; figures 3, 8; p’s 114, 4, 28, 71, 94, 111, 154, 247; figures 1, 6) as per the discussion above and the rejection of corresponding parts of the claims above incorporated herein and further paragraph 4 of Shetty discloses:
[0004] Embodiments of the present disclosure relate to operator (e.g., driver) assistance using one or more language models (e.g., a Large Language Model (LLM)). For instance, some embodiments relate to providing-context specific information to an operator as part of a natural language dialogue or other natural language output. In an illustrative example, particular embodiments generate a natural language utterance (e.g., “as a reminder, there are lots of deer in this area”) based on extracting natural language text in a nearby traffic sign (e.g., a sign that reads “deer Xing”). Additionally or alternatively, some embodiments relate to engaging the operator (e.g., via a relevant conversation) based on operator monitoring. For instance, during long drives, a driver may become drowsy or may not otherwise be alert. As such, particular embodiments have the capability of engaging (e.g., starting or continuing a conversation) with the driver based on driver interests and/or in response to detecting a likelihood that the driver is getting drowsy.
As per claims 3, 10 and 17 Shetty discloses wherein the vehicle information includes an image of a user, voice of the user, a state of the vehicle, and route information on the vehicle (figures 1, 6; ab; p’s 7, 34, 82-83, 98, 251; figures 3, 8; p’s 114, 4, 28, 71, 94, 111, 154, 247) as per the discussion above and the rejection of corresponding parts of the claims above incorporated herein and further, Shetty discloses via p154:
[0154] One or more of the controller(s) 1036 may receive inputs (e.g., represented by input data) from an instrument cluster 1032 of the vehicle 1000 and provide outputs (e.g., represented by output data, display data, etc.) via a human-machine interface (HMI) display 1034, an audible annunciator, a loudspeaker, and/or via other components of the vehicle 1000. The outputs may include information such as vehicle velocity, speed, time, map data (e.g., the High Definition (“HD”) map 1022 of FIG. 10C), location data (e.g., the vehicle's 1000 location, such as on a map), direction, location of other vehicles (e.g., an occupancy grid), information about objects and status of objects as perceived by the controller(s) 1036, etc. For example, the HMI display 1034 may display information about the presence of one or more objects (e.g., a street sign, caution sign, traffic light changing, etc.), and/or information about driving maneuvers the vehicle has made, is making, or will make (e.g., changing lanes now, taking exit 34B in two miles, etc.).
As per claims 4, 11 and 18 Shetty discloses wherein the action includes: playing specific music; playing specific video; and displaying route guidance to a rest area (p’s 114, 4, 28, 71, 94, 111, 154, 247; figures 1, 6; ab; p’s 7, 34, 82-83, 98, 251; figures 3, 8) as per the discussion above and the rejection of corresponding parts of the claims above incorporated herein and further, Shetty discloses via p247:
[0247] The vehicle 1000 may further include the infotainment SoC 1030 (e.g., an in-vehicle infotainment system (IVI)). Although illustrated and described as a SoC, the infotainment system may not be a SoC, and may include two or more discrete components. The infotainment SoC 1030 may include a combination of hardware and software that may be used to provide audio (e.g., music, a personal digital assistant, navigational instructions, news, radio, etc.), video (e.g., TV, movies, streaming, etc.), phone (e.g., hands-free calling), network connectivity (e.g., LTE, Wi-Fi, etc.), and/or information services (e.g., navigation systems, rear-parking assistance, a radio data system, vehicle related information such as fuel level, total distance covered, brake fuel level, oil level, door open/close, air filter information, etc.) to the vehicle 1000. For example, the infotainment SoC 1030 may radios, disk players, navigation systems, video players, USB and Bluetooth connectivity, carputers, in-car entertainment, Wi-Fi, steering wheel audio controls, hands free voice control, a heads-up display (HUD), an HMI display 1034, a telematics device, a control panel (e.g., for controlling and/or interacting with various components, features, and/or systems), and/or other components. The infotainment SoC 1030 may further be used to provide information (e.g., visual and/or audible) to a user(s) of the vehicle, such as information from the ADAS system 1038, autonomous driving information such as planned vehicle maneuvers, trajectories, surrounding environment information (e.g., intersection information, vehicle information, road information, etc.), and/or other information.
As per claims 5, 12 and 19 Shetty discloses acquiring a reaction of a user to the action performed; and updating the user information based on the reaction of the user (figures 3, 8; p’s 114, 4, 28, 71, 94, 111, 154, 247; figures 1, 6; ab; p’s 7, 34, 82-83, 98, 251) as per the discussion above and the rejection of corresponding parts of the claims above incorporated herein and further, Shetty discloses via paragraph 7:
[0007] In order to produce natural language responses, the language model may ingest or receive various inputs (or portions of an input). For instance, the inputs may be or include various prompts that have been subject to prompt engineering, prompt-tuning, and/or fine-tuning to elicit suitable natural language responses using a Large Language Model (LLM). For example, where a natural language response concerns an operator's alertness level, the prompt that is provided to the language model may include personalized information (e.g., an indication that the driver likes sports team X), a representation of a detected (e.g., computed, inferred, etc.) alertness level of the operator (e.g., “the operator is extremely sleepy”), a natural language instruction, such as “start a conversation with the driver that aligns with the driver's interests,” a one-shot or few shot prompt example of representative inputs and/or outputs (e.g., example conversations initiated at the KSS level), and/or “send a control signal to honk the horn.” In response to the language model ingesting such prompt, the language model may output a natural language response, such as “I've just honked the horn because you are falling asleep. Can you name some players that have played for team X that have made it to the Hall of Fame?”
As per claims 6, 13 and 20 Shetty discloses wherein the controller is configured to: acquire a reaction of a user to the action performed; and when the reaction of the user is negative, generate, further using the reaction of the user, the prompt to cause the first language model to output the action against the detected event (p’s 7, 34, 82-83, 98, 251; figures 3, 8; p’s 114, 4, 28, 71, 94, 111, 154, 247; figures 1, 6; ab) as per the discussion above and the rejection of corresponding parts of the claims above incorporated herein and further, Shetty discloses via p111:
[0111] Responsively, the operator alertness level detector 206 sends such natural language phrase to the language model(s) 226, at which the prompt construction block(s) 226 generate the “operator alertness level prompt” of the input(s) 301, which includes the KSS level score natural language phrase. Responsively, the natural language response generator 132 generates a natural language response, such as “You appear to be very drowsy! May I play your favorite upbeat music?” Responsively, the natural language response generator 132 automatically transmits such response to the text-to-speech component 134, which converts such natural language response to the audio data response 504, such that the audio device 506 (e.g., a car speaker) outputs the audio data response 504 in the form of sound waves, which mirrors the response generated by the natural language response generator 232.
As per claims 7 and 14 Shetty discloses wherein each of the one or more events includes a priority level, and when two or more events of the one or more events have occurred simultaneously, the information processing apparatus is configured to generate the prompt based further on the priority level of each of the two or more events (p’s 96, 94, 93, ab; p’s 7, 34, 82-83, 98, 251; figures 3, 8; p’s 114, 4, 28, 71, 111, 154, 247; figures 1, 6) as per the discussion above and the rejection of corresponding parts of the claims above incorporated herein and further, Shetty discloses via p96:
[0096] Prompt tuning is the process of taking or learning the most effective prompts or cues (among a larger pool of prompts) and feeding them to the encoder/decoder block(s) 306 as task-specific context. For example, a common question or phrase—“What is my account balance?”—could be taught to the encoder/decoder block(s) 306 to help optimize the model and guide it toward the most desirable decision or corresponding outputs in 308. Unlike prompt engineering, prompt tuning is not about a user formulating a better question or making a more specific request. Prompt tuning means identifying more frequent or important prompts (e.g., which have higher node activation weight values) and training the encoder/decoder block(s) 306 to respond to those common prompts more effectively. The benefit of prompt tuning is that it may be used to modestly train models without adding any more input(s) 301 or prompts (unlike fine-tuning), resulting in considerable time and cost savings.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Michel et al. (U.S. patent application publication 2026/0105785) discloses
techniques relate to generating vehicle condition reports at least in part using trained large language models (LLMs). An example method includes, using at least one computer processor, to perform: obtaining natural language text transcribed from an audio recording of a user speaking about a vehicle and its condition, identifying a first portion of the natural language text containing information about a condition of a part of the vehicle using a vehicle part condition dictionary, generating, using the first portion and portions of the natural language text that provide semantic context to the first portion, a prompt for prompting the trained LLM to generate output text identifying the part and describing its condition, providing the prompt as input to the trained LLM, receiving the output text from the trained LLM, and generating the vehicle condition report using the output text.
Eberhardt et al. (U.S. patent 12,327,445) discloses an inspection application display, on a user device, a user interface including at least a portion of
a vehicle inspection report including a plurality of inspection categories. The inspection application may configure the user device to obtain inspection information associated
with a vehicle, the inspection information comprising photographs, videos, audio, and/or text. The inspection application and/or a network-accessible inspection assistant system may generate a prompt including at least a portion of the inspection information and information indicating potential vehicle defects. The prompt may be transmitted to a large language model that returns a response indicating any potential vehicle defects identified in the inspection information. The vehicle inspection report may then be updated to indicate the potential vehicle defects identified by the language model.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BEHRANG BADII whose telephone number is (571)272-6879. The examiner can normally be reached Monday-Friday.
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, Hunter Lonsberry can be reached at 571-272-7298. 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.
/Behrang Badii/
Primary Examiner
Art Unit 3665
Prosecution Insights