DETAILED ACTION
Claim Objections
Claims 2-4 objected to because of the following informalities: the claim recites “AI”. It is unclear what the abbreviation stands for. Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier.
Such claim limitation(s) is/are: “an instruction text generation unit that summarizes”, “a correction work generation unit that reads” and “a correction application unit that updates” as in claim 1, and 7-9.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
As per claims 1-9, Claim limitations “an instruction text generation unit that summarizes”, “a correction work generation unit that reads” and “a correction application unit that updates” as in claim 1, and 7-9 have been evaluated under the three-prong test set forth in MPEP § 2181, subsection I, but the result is inconclusive. Thus, it is unclear whether this limitation should be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because there is ambiguity to whether “an instruction text generation unit that summarizes”, “a correction work generation unit that reads” and “a correction application unit that updates” are generic placeholder (nonce term or non-tructural term having no specific structural meaning) for performing the claimed function. The boundaries of this claim limitation are ambiguous; therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
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.
Claims 1-9 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an attract idea without significantly more.
Per claim 1, 7-9 recite “a work reception device”, “a work reception method”, “a work reception system” and “a work reception” and “a computer readable storage medium”: which fall within a statutory category under Step 1.
The claims recite the limitations of “work related to a room as a work list for each room number identifying the room”; “an instruction text generation unit that summarizes text to generate instruction text related to the work”; “a correction work generation unit that reads the instruction text to identify the changes in the work”; and “a correction application unit that updates the work list using the changes in the work” as in claims 1 and 7-9.
These limitations, under its broadest reasonable interpretation, recite the abstract idea of certain methods of organizing human activity (in particular managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions)) and/or the limitations as drafted are sequence of steps that, under its broadest reasonable interpretation, recite the abstract idea of mental processes. The limitations encompass a human mind carrying out the functions through observation, evaluation, judgment and /or opinion, or even with the aid of pen and paper, nothing in these limitations that would prevent to be done mentally with the aid of pen and paper even with the recitation of generic computer components.
If the claim under broadest reasonable interpretation covers limitation that is drawn to certain methods of organizing human activity and/or mental processes but for recitation of a generic computer and/or generic computer components described at a high level of generality or linking the use of the judicial exception to a particular technological environment or field of use, then it falls within the grouping of abstract ideas. Thus, these limitations fall within the “Certain Methods of Organizing Human Activity” and/or “Mental Processes” grouping of abstract ideas under Step 2A Prong I.
The claims further recite additional elements including “a work reception device”, “a storage unit that stores”, “a computer-readable storage medium”, “a memory”, and “a processor” as in claims 1 and 7-9.
However, the additional elements “a work reception device”, “a storage unit that stores”, “a computer-readable storage medium”, “a memory”, and “a processor” are recited at a high-level of generality such that it amounts to mere instructions to implement the abstract idea on a generic computer and/or adding the words “apply it”(or an equivalent) with the judicial exception and/or uses a generic computer or generic computer components as a tool to perform the abstract idea. see MPEP 2106.05(f). Accordingly, these additional elements do not integrate the recited judicial exception into a practical application, and the claims are therefore directed to the judicial exception under Step 2A Prong II.
These claims do 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, there are insignificant additional elements including “a work reception device”, “a storage unit that stores”, “a computer-readable storage medium”, “a memory”, and “a processor” as in claim 1 and 7-9.
However, the additional elements “a work reception device”, “a storage unit that stores”, “a computer-readable storage medium”, “a memory”, and “a processor” are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, or merely using a generic computer or generic computer components to perform the judicial exception, see MPEP 2106.05(f). Mere instructions to apply the exception cannot provide an inventive concept. Accordingly, the claim does not appear to be patent eligible under 35 USC 101 under Step 2B.
Per claims 2-6, these claims are also similar rejected for being directed to an attract idea of “Certain Methods of Organizing Human Activity” and/or “Mental Processes” without significantly more as detailed in the rejection of independent claims above. In particular, there are additional elements in these claims such as using generative AI. However, these additional elements are merely linking the use of the judicial exception to a particular technological environment or field of use, in this case to generative AI environment. Such limitation are not enough to add significantly more to the claimed method and/or is an attempt to limit the use of the abstract idea to a particular technological environment for which to apply the underlying abstract concept, which does not add significantly more. The claims are directed to an abstract idea and merely links the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h)) and/or are at best applying/mere instructions to implement an abstract idea on a computer which is insignificant and not indicative of integration into a practical application. See MPEP 2106.05(f).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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-9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ichikawa et al. (“Ichikawa”, Pub. No. 2009/0240519), Billman et al. (“Billman”, Pub. No. US 20250147954).
Per claim 1, Ichikawa teaches a work reception device comprising:
a storage unit that stores work related to a room as a work list for each room number identifying the room (fig. 9A; [0195]…Based on the display screen, the maintenance/repair subcontract company inputs the work content (step S704). For example, an order number written on a work instruction, the name of a maintenance/repair target equipment associated with the order number, condominium building identification information of a dwell unit having the maintenance/repair target equipment, a room number, a maintenance/repair work content performed on the maintenance/repair target equipment, a manufacturer name of a replaced part, a model number thereof when a part is replaced, and a maintenance/repair date are input. [0196]…The control unit 110 of the dwell unit information server 1 registers the transmitted work content in the maintenance/repair history information storing unit 135 based on the transmitted order number (step S706). More specifically, the control unit 110 searches a record having the same order number as the transmitted order number among records stored in the maintenance/repair history information storing unit 135, and adds and registers the transmitted information to the searched record.);
Ichikawa does not specifically teach an instruction text generation unit that summarizes text to generate instruction text related to the work; an instruction text generation unit that summarizes text to generate instruction text related to the work; and a correction work generation unit that reads the instruction text to identify the changes in the work.
However, Billman teaches a storage unit that stores work/task as a work list/task list for each identifying user ([0016]... The customer client device 100 presents an ordering interface to the customer. The ordering interface is a user interface that the customer can use to place an order with the online system 140. The ordering interface may be part of a client application operating on the customer client device 100. [0018]…Additionally, the customer client device 100 includes a communication interface that allows the customer to communicate with a picker that is servicing the customer's order. This communication interface allows the user to input a text-based message to transmit to the picker client device 110 via the network 130);
an instruction text generation unit that summarizes text to generate instruction text related to the work ([0040]… one objective may be to perform various types of queries on the external data in order to perform any task that the machine-learned model of the model serving system 150 could perform. For example, the task may be to perform question-answering, text summarization, text generation, and the like based on information contained in an external dataset. [0090]…The first LLM classifies the extracted text for each message into a request type. In one or more instances, the request type indicates one or more types of API calls the first LLM determines should be invoked to perform the desired change described in the communication history of the user.);
a correction work generation unit that reads the instruction text to identify the changes in the work ([0085]…The order adjustment module 225 tracks adjustments to an order made by the user and updates the order to reflect those updates. The order adjustment module 225 stores and maintains a communication history regarding each order between users of the online system 140 and the picker fulfilling the order. A user initiates communication with a picker by submitting an order to the online system 140, which the picker accepts. The order supplies initial instructions to the user, for example which items to select and how many of each item to select. If the user makes no other updates or modifications to a pending order, the communication history for that order is limited to the order placed by the user. Alternatively, if the user does send additional messages to the picker via the communication interface, the communication history for that order is updated to reflect the additional messages. [0087]… Alternatively, the user may message the picker assigned to the order to further modify the order through, for example, a chat window. For example, a user may message a picker that they would like to replace the requested brand of cereal with a different brand. [0088]… In one or more embodiments, the order adjustment module 225 automatically generates one or more API calls or requests from free text (e.g., chat history between user and picker) in conjunction with one or more trained LLM's deployed by the model serving system 150. The free text includes information by the user on desired changes to the user's order—the generated API calls when processed modify the user's order with the desired changes. The order adjustment module 225 executes the series of API requests necessary to perform the change or update based on text in the communication history of the order. Because a user and a picker may freely communicate with each other regarding an order, the communication history for the order may be a freeform string of messages. [0089]… Accordingly, in one or more embodiments, the order adjustment module 225 transmits (i) the communications history (e.g., chat history) for the given order, (ii) order context, (iii) information describing the expected picker action, (iv) communication history for a population of historical orders, and/or (v) other contextual information, and a request to infer one or more types of API calls to invoke for order modification to the model serving system 150 in the form of a prompt. A first LLM analyzes the communication history and extracts requests, modifications, or adjustments to the order made by the user. The trained LLM extracts text from each message sent by the user. [0090]…The first LLM classifies the extracted text for each message into a request type. In one or more instances, the request type indicates one or more types of API calls the first LLM determines should be invoked to perform the desired change described in the communication history of the user. For example, an example request type might be to update replacement items for an item in the order, and an example API call type may be the “user_choice_replacements” API call. As another example, an example request type might be to change the quantity of an item in the order, and an example API call type may be the “change_item_quantity” API call.); and
a correction application unit that updates the work list using the changes in the work ([0085]…The order adjustment module 225 tracks adjustments to an order made by the user and updates the order to reflect those updates. The order adjustment module 225 stores and maintains a communication history regarding each order between users of the online system 140 and the picker fulfilling the order. A user initiates communication with a picker by submitting an order to the online system 140, which the picker accepts. The order supplies initial instructions to the user, for example which items to select and how many of each item to select. If the user makes no other updates or modifications to a pending order, the communication history for that order is limited to the order placed by the user. Alternatively, if the user does send additional messages to the picker via the communication interface, the communication history for that order is updated to reflect the additional messages. [0087]… Alternatively, the user may message the picker assigned to the order to further modify the order through, for example, a chat window. For example, a user may message a picker that they would like to replace the requested brand of cereal with a different brand. [0088]… In one or more embodiments, the order adjustment module 225 automatically generates one or more API calls or requests from free text (e.g., chat history between user and picker) in conjunction with one or more trained LLM's deployed by the model serving system 150. The free text includes information by the user on desired changes to the user's order—the generated API calls when processed modify the user's order with the desired changes. The order adjustment module 225 executes the series of API requests necessary to perform the change or update based on text in the communication history of the order. Because a user and a picker may freely communicate with each other regarding an order, the communication history for the order may be a freeform string of messages. [0089]… Accordingly, in one or more embodiments, the order adjustment module 225 transmits (i) the communications history (e.g., chat history) for the given order, (ii) order context, (iii) information describing the expected picker action, (iv) communication history for a population of historical orders, and/or (v) other contextual information, and a request to infer one or more types of API calls to invoke for order modification to the model serving system 150 in the form of a prompt. A first LLM analyzes the communication history and extracts requests, modifications, or adjustments to the order made by the user. The trained LLM extracts text from each message sent by the user. [0090]…The first LLM classifies the extracted text for each message into a request type. In one or more instances, the request type indicates one or more types of API calls the first LLM determines should be invoked to perform the desired change described in the communication history of the user. For example, an example request type might be to update replacement items for an item in the order, and an example API call type may be the “user_choice_replacements” API call. As another example, an example request type might be to change the quantity of an item in the order, and an example API call type may be the “change_item_quantity” API call.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the teaching of Billman in the invention of Ichikawa because doing so would enhance/improve efficiency by providing an improved user interface for accessing structured data stored in a catalog/task list and providing high degree of accuracy of results obtained from structured catalog/task list data using natural language queries.
Per claim 2, the modified Ichikawa teaches the work reception device according to claim 1, wherein the instruction text generation unit has a summary generative Al that has learned to extract change instructions for the work content for each room included in the text (Billman, [0085]…The order adjustment module 225 tracks adjustments to an order made by the user and updates the order to reflect those updates. The order adjustment module 225 stores and maintains a communication history regarding each order between users of the online system 140 and the picker fulfilling the order. A user initiates communication with a picker by submitting an order to the online system 140, which the picker accepts. The order supplies initial instructions to the user, for example which items to select and how many of each item to select. If the user makes no other updates or modifications to a pending order, the communication history for that order is limited to the order placed by the user. Alternatively, if the user does send additional messages to the picker via the communication interface, the communication history for that order is updated to reflect the additional messages. [0087]… Alternatively, the user may message the picker assigned to the order to further modify the order through, for example, a chat window. For example, a user may message a picker that they would like to replace the requested brand of cereal with a different brand. [0088]… In one or more embodiments, the order adjustment module 225 automatically generates one or more API calls or requests from free text (e.g., chat history between user and picker) in conjunction with one or more trained LLM's deployed by the model serving system 150. The free text includes information by the user on desired changes to the user's order—the generated API calls when processed modify the user's order with the desired changes. The order adjustment module 225 executes the series of API requests necessary to perform the change or update based on text in the communication history of the order. Because a user and a picker may freely communicate with each other regarding an order, the communication history for the order may be a freeform string of messages. [0089]… Accordingly, in one or more embodiments, the order adjustment module 225 transmits (i) the communications history (e.g., chat history) for the given order, (ii) order context, (iii) information describing the expected picker action, (iv) communication history for a population of historical orders, and/or (v) other contextual information, and a request to infer one or more types of API calls to invoke for order modification to the model serving system 150 in the form of a prompt. A first LLM analyzes the communication history and extracts requests, modifications, or adjustments to the order made by the user. The trained LLM extracts text from each message sent by the user. [0090]…The first LLM classifies the extracted text for each message into a request type. In one or more instances, the request type indicates one or more types of API calls the first LLM determines should be invoked to perform the desired change described in the communication history of the user. For example, an example request type might be to update replacement items for an item in the order, and an example API call type may be the “user_choice_replacements” API call. As another example, an example request type might be to change the quantity of an item in the order, and an example API call type may be the “change_item_quantity” API call.)). See claim 1 for motivation.
Per claim 3, Ichikawa teaches the work reception device according to claim 1, wherein the instruction text generation unit has a summary generative Al that has learned to identify the boundaries of dialogues included in the text and extract change instructions for the work content (Billman, [0085]…The order adjustment module 225 tracks adjustments to an order made by the user and updates the order to reflect those updates. The order adjustment module 225 stores and maintains a communication history regarding each order between users of the online system 140 and the picker fulfilling the order. A user initiates communication with a picker by submitting an order to the online system 140, which the picker accepts. The order supplies initial instructions to the user, for example which items to select and how many of each item to select. If the user makes no other updates or modifications to a pending order, the communication history for that order is limited to the order placed by the user. Alternatively, if the user does send additional messages to the picker via the communication interface, the communication history for that order is updated to reflect the additional messages. [0087]… Alternatively, the user may message the picker assigned to the order to further modify the order through, for example, a chat window. For example, a user may message a picker that they would like to replace the requested brand of cereal with a different brand. [0088]… In one or more embodiments, the order adjustment module 225 automatically generates one or more API calls or requests from free text (e.g., chat history between user and picker) in conjunction with one or more trained LLM's deployed by the model serving system 150. The free text includes information by the user on desired changes to the user's order—the generated API calls when processed modify the user's order with the desired changes. The order adjustment module 225 executes the series of API requests necessary to perform the change or update based on text in the communication history of the order. Because a user and a picker may freely communicate with each other regarding an order, the communication history for the order may be a freeform string of messages. [0089]… Accordingly, in one or more embodiments, the order adjustment module 225 transmits (i) the communications history (e.g., chat history) for the given order, (ii) order context, (iii) information describing the expected picker action, (iv) communication history for a population of historical orders, and/or (v) other contextual information, and a request to infer one or more types of API calls to invoke for order modification to the model serving system 150 in the form of a prompt. A first LLM analyzes the communication history and extracts requests, modifications, or adjustments to the order made by the user. The trained LLM extracts text from each message sent by the user. [0090]…The first LLM classifies the extracted text for each message into a request type. In one or more instances, the request type indicates one or more types of API calls the first LLM determines should be invoked to perform the desired change described in the communication history of the user. For example, an example request type might be to update replacement items for an item in the order, and an example API call type may be the “user_choice_replacements” API call. As another example, an example request type might be to change the quantity of an item in the order, and an example API call type may be the “change_item_quantity” API call.) See claim 1 for motivation.
Per claim 4, Ichikawa teaches the work reception device according to claim 1, wherein the correction work generation unit has a change content specifying Al that has learned to ignore instruction texts when the change content has already been indicated in the work list (Billman, [0085]…The order adjustment module 225 tracks adjustments to an order made by the user and updates the order to reflect those updates. The order adjustment module 225 stores and maintains a communication history regarding each order between users of the online system 140 and the picker fulfilling the order. A user initiates communication with a picker by submitting an order to the online system 140, which the picker accepts. The order supplies initial instructions to the user, for example which items to select and how many of each item to select. If the user makes no other updates or modifications to a pending order, the communication history for that order is limited to the order placed by the user. Alternatively, if the user does send additional messages to the picker via the communication interface, the communication history for that order is updated to reflect the additional messages. [0087]… Alternatively, the user may message the picker assigned to the order to further modify the order through, for example, a chat window. For example, a user may message a picker that they would like to replace the requested brand of cereal with a different brand. Often times, pickers have significant discretion in following the user's instructions that are not officially part of the order. For example, the picker may ignore the user's messages in the communication history or refrain from reading the communication. [0088]… In one or more embodiments, the order adjustment module 225 automatically generates one or more API calls or requests from free text (e.g., chat history between user and picker) in conjunction with one or more trained LLM's deployed by the model serving system 150. The free text includes information by the user on desired changes to the user's order—the generated API calls when processed modify the user's order with the desired changes. The order adjustment module 225 executes the series of API requests necessary to perform the change or update based on text in the communication history of the order. Because a user and a picker may freely communicate with each other regarding an order, the communication history for the order may be a freeform string of messages. [0089]… Accordingly, in one or more embodiments, the order adjustment module 225 transmits (i) the communications history (e.g., chat history) for the given order, (ii) order context, (iii) information describing the expected picker action, (iv) communication history for a population of historical orders, and/or (v) other contextual information, and a request to infer one or more types of API calls to invoke for order modification to the model serving system 150 in the form of a prompt. A first LLM analyzes the communication history and extracts requests, modifications, or adjustments to the order made by the user. The trained LLM extracts text from each message sent by the user. [0090]…The first LLM classifies the extracted text for each message into a request type. In one or more instances, the request type indicates one or more types of API calls the first LLM determines should be invoked to perform the desired change described in the communication history of the user. For example, an example request type might be to update replacement items for an item in the order, and an example API call type may be the “user_choice_replacements” API call. As another example, an example request type might be to change the quantity of an item in the order, and an example API call type may be the “change_item_quantity” API call.) See claim 1 for motivation.
Per claim 5, Ichikawa teaches the work reception device according to claim 1, wherein the text is a dialogue log made in a text chat or voice chat, and the correction application unit outputs the changes in the work to the text chat or voice chat and updates the work list upon receiving a positive response (Billman, [0085]…The order adjustment module 225 tracks adjustments to an order made by the user and updates the order to reflect those updates. The order adjustment module 225 stores and maintains a communication history regarding each order between users of the online system 140 and the picker fulfilling the order. A user initiates communication with a picker by submitting an order to the online system 140, which the picker accepts. The order supplies initial instructions to the user, for example which items to select and how many of each item to select. If the user makes no other updates or modifications to a pending order, the communication history for that order is limited to the order placed by the user. Alternatively, if the user does send additional messages to the picker via the communication interface, the communication history for that order is updated to reflect the additional messages. [0087]… Alternatively, the user may message the picker assigned to the order to further modify the order through, for example, a chat window. For example, a user may message a picker that they would like to replace the requested brand of cereal with a different brand. [0088]… In one or more embodiments, the order adjustment module 225 automatically generates one or more API calls or requests from free text (e.g., chat history between user and picker) in conjunction with one or more trained LLM's deployed by the model serving system 150. The free text includes information by the user on desired changes to the user's order—the generated API calls when processed modify the user's order with the desired changes. The order adjustment module 225 executes the series of API requests necessary to perform the change or update based on text in the communication history of the order. Because a user and a picker may freely communicate with each other regarding an order, the communication history for the order may be a freeform string of messages. [0089]… Accordingly, in one or more embodiments, the order adjustment module 225 transmits (i) the communications history (e.g., chat history) for the given order, (ii) order context, (iii) information describing the expected picker action, (iv) communication history for a population of historical orders, and/or (v) other contextual information, and a request to infer one or more types of API calls to invoke for order modification to the model serving system 150 in the form of a prompt. A first LLM analyzes the communication history and extracts requests, modifications, or adjustments to the order made by the user. The trained LLM extracts text from each message sent by the user. [0090]…The first LLM classifies the extracted text for each message into a request type. In one or more instances, the request type indicates one or more types of API calls the first LLM determines should be invoked to perform the desired change described in the communication history of the user. For example, an example request type might be to update replacement items for an item in the order, and an example API call type may be the “user_choice_replacements” API call. As another example, an example request type might be to change the quantity of an item in the order, and an example API call type may be the “change_item_quantity” API call.) See claim 1 for motivation.
Per claim 6, Ichikawa teaches the work reception device according to claim 1, wherein the correction work generation unit reads the instruction text for each room to identify the changes in the work (Ichikawa, fig. 9A; [0195]…Based on the display screen, the maintenance/repair subcontract company inputs the work content (step S704). For example, an order number written on a work instruction, the name of a maintenance/repair target equipment associated with the order number, condominium building identification information of a dwell unit having the maintenance/repair target equipment, a room number, a maintenance/repair work content performed on the maintenance/repair target equipment, a manufacturer name of a replaced part, a model number thereof when a part is replaced, and a maintenance/repair date are input. [0196]…The control unit 110 of the dwell unit information server 1 registers the transmitted work content in the maintenance/repair history information storing unit 135 based on the transmitted order number (step S706). More specifically, the control unit 110 searches a record having the same order number as the transmitted order number among records stored in the maintenance/repair history information storing unit 135, and adds and registers the transmitted information to the searched record.; Billman, [0085]…The order adjustment module 225 tracks adjustments to an order made by the user and updates the order to reflect those updates. The order adjustment module 225 stores and maintains a communication history regarding each order between users of the online system 140 and the picker fulfilling the order. A user initiates communication with a picker by submitting an order to the online system 140, which the picker accepts. The order supplies initial instructions to the user, for example which items to select and how many of each item to select. If the user makes no other updates or modifications to a pending order, the communication history for that order is limited to the order placed by the user. Alternatively, if the user does send additional messages to the picker via the communication interface, the communication history for that order is updated to reflect the additional messages. [0087]… Alternatively, the user may message the picker assigned to the order to further modify the order through, for example, a chat window. For example, a user may message a picker that they would like to replace the requested brand of cereal with a different brand. [0088]… In one or more embodiments, the order adjustment module 225 automatically generates one or more API calls or requests from free text (e.g., chat history between user and picker) in conjunction with one or more trained LLM's deployed by the model serving system 150. The free text includes information by the user on desired changes to the user's order—the generated API calls when processed modify the user's order with the desired changes. The order adjustment module 225 executes the series of API requests necessary to perform the change or update based on text in the communication history of the order. Because a user and a picker may freely communicate with each other regarding an order, the communication history for the order may be a freeform string of messages. [0089]… Accordingly, in one or more embodiments, the order adjustment module 225 transmits (i) the communications history (e.g., chat history) for the given order, (ii) order context, (iii) information describing the expected picker action, (iv) communication history for a population of historical orders, and/or (v) other contextual information, and a request to infer one or more types of API calls to invoke for order modification to the model serving system 150 in the form of a prompt. A first LLM analyzes the communication history and extracts requests, modifications, or adjustments to the order made by the user. The trained LLM extracts text from each message sent by the user. [0090]…The first LLM classifies the extracted text for each message into a request type. In one or more instances, the request type indicates one or more types of API calls the first LLM determines should be invoked to perform the desired change described in the communication history of the user. For example, an example request type might be to update replacement items for an item in the order, and an example API call type may be the “user_choice_replacements” API call. As another example, an example request type might be to change the quantity of an item in the order, and an example API call type may be the “change_item_quantity” API call.) See claim 1 for motivation.
Claims 7, 8, and 9 individually is rejected under the same rationale as claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Gudla et al. (Pub. No. 2025/0139681) discloses a user provides a query to the online concierge system. The online concierge system extracts query features from the query and obtains additional contextual features (e.g., user features, retailer features, or item features). The features are input into the contextual bandit model which outputs a weight vector comprising a weight for each ranking parameter. A ranking parameter may be a characteristic evaluated in the ranking of query results, e.g., relevance of the query result to the query, and dependability of dependability of the query result.
Colalancia et al. (pub. No. US 2004/0019513) discloses A system and method are provided for managing hotel operations through a wireless communications network. A central computer includes software for organizing and prioritizing data regarding desired room usage based upon input from arriving hotel guests. The data is organized into shift orders which take into account particular hotel guests needs.
Inquiries
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THANH T VU whose telephone number is (571)272-4073. The examiner can normally be reached M-F: 7AM - 3:30PM.
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, Fred Ehichioya can be reached at (571) 272-4034. 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.
/THANH T VU/ Primary Examiner, Art Unit 2179
