Ai-driven integrated grocery optimization, nutrition analysis, meal planning, and pantry management system and related methods

Abstract

A computer-implemented method for facilitating purchases includes receiving a shopping list input from a user, and processing the shopping list input, identifying a plurality of desired products, determining an associated quantity of each of the plurality of desired products, and querying a plurality of distinct retailer data sources to obtain product data for each of the plurality of desired products. The querying is performed in parallel via API integrations with each of the plurality of distinct retailer data sources. The method includes aggregating and normalizing the product data retrieved from the plurality of distinct retailer data sources into a unified data set of a plurality of candidate products for the plurality of desired products. The method includes evaluating the plurality of candidate products using a recommendation algorithm and selecting a plurality of recommended products.

Description

Atty Docket No. 2523.100.01USAI-DRIVEN INTEGRATED GROCERY OPTIMIZATION, NUTRITION ANALYSIS, MEAL PLANNING, AND PANTRY MANAGEMENT SYSTEM AND RELATED METHODSTECHNICAL FIELD

[0001] Embodiments herein are related to grocery optimization and specifically to Al- driven methods therefor.BACKGROUND

[0002] Modern consumers are increasingly relying on digital ecosystems to manage food purchases, nutrition tracking, and household inventory. However, existing technologies remain fragmented and reactive. Traditional e-commerce systems operate within single-retailer boundaries, requiring users to manually compare prices, verify product availability, and align selections with personal dietary preferences. Cross¬ platform optimization across multiple retailers considering nutritional suitability, cost, and quality is unsupported.

[0003] Similarly, diet-tracking applications depend heavily on manual data entry. Users must search individual items, estimate portion sizes, and enter nutritional information, often without integration to shopping or inventory systems. Although barcode scanners and image recognition tools can identify products or meals, they typically provide only superficial analyses such as calorie counts and lack mechanisms to decompose complex dishes or reconcile unit inconsistencies. Furthermore, these systems operate in isolation, without updating inventory or influencing future meal or shopping decisions.

[0004] Household inventory management technologies also remain inadequate. Existing pantry applications require manual updates and lack standardization across brands, units, or packaging. Smart refrigerators and barcode-based systems provide limited visibility and cannot unify data from diverse sources. As a result, inventory records quickly become outdated, leading to redundant purchases, shortages, and increased food waste.

[0005] Meal planning applications generally function as static suggestion tools, independent of pantry contents, nutrition goals, or actual consumption data. TheyAtty Docket No. 2523.100.01USneither synchronize with inventory databases nor dynamically adjust plans when a user's dietary intake or ingredient availability changes. Similarly, retailer recommendation engines focus on promoting products or repeat purchases rather than optimizing cross-retailer selections based on nutritional and household data.

[0006] There thus remains a need for a better way for consumers to optimize purchases, analyze nutrition, plan meals, manage pantry inventories, and / or other new and useful innovations.SUMMARY

[0007] An exemplary computer-implemented method for facilitating purchases includes receiving, via a user interface, a shopping list input from a user in at least one of multiple modalities, the multiple modalities selected from the following: an image containing text, spoken audio, or free-form text. The method includes processing the shopping list input with an artificial intelligence engine, wherein the processing the shopping list input includes: determining at least one of: (a) at least a portion of the shopping list input is an image containing text; (b) at least a portion of the shopping list input is spoken audio; or (c) at least a portion of the shopping list input is free-form text. The method includes, responsive to the determining, identifying a plurality of desired products; determining an associated quantity of each of the plurality of desired products; and querying a plurality of distinct retailer data sources to obtain product data for each of the plurality of desired products. The querying is performed in parallel via API integrations with each of the plurality of distinct retailer data sources. The method includes aggregating and normalizing the product data retrieved from the plurality of distinct retailer data sources into a unified data set of a plurality of candidate products for the plurality of desired products, the unified data set including at least one of price information, product description, or availability. The method includes evaluating the plurality of candidate products using a recommendation algorithm, the recommendation algorithm configured to apply multiple selection criteria, the criteria comprising price, product quality indicator, customer ratings, and at least one user¬ specific preference or constraint. The method includes, responsive to the evaluating,Atty Docket No, 2523.100.01USselecting a plurality of recommended products; adding the plurality of recommended products to a virtual shopping cart associated with the user; receiving a checkout request from the user; and, responsive to the receiving the checkout request, initiating purchase of the plurality of recommended products, wherein the plurality of recommended products originate from a plurality of retailers, and the initiating purchase includes coordinating orders to the plurality of retailers.

[0008] An exemplary system for facilitating purchases includes a user interface; one or more processors; and a non-transitory computer-readable memory storing instructions that, when executed by the one or more processors, cause the system to execute the method described in the preceding paragraph.

[0009] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that solve any or all disadvantages noted in the Background.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1 is a block diagram of an exemplary system with architecture;

[0011] FIG. 2 is a flow diagram of a method of intent analysis, which may be executed by the system in FIG. 1;

[0012] FIG. 3 is a flow diagram of a text-based input processing method, which may be executed by the system in FIG. 1;

[0013] FIG. 4 is a flow diagram of an image processing and OCR-based input method, which may be executed by the system in FIG. 1;

[0014] FIG. 5 is a flow diagram of a voice input parsing method, which may be executed by the system in FIG. 1;

[0015] FIG. 6 is a flow diagram of a user preference and modifier mapping method, which may be part of the system in FIG. 1;Atty Docket No. 2523.100.01US

[0016] FIG. 7 is a block diagram of exemplary retailer API integration architecture, which may be part of the system in FIG. 1;

[0017] FIG. 8 is a flow diagram of a cart management and order linking method, which may be executed by the system in FIG. 1;

[0018] FIG. 9 is a flow diagram of a work flow method, which may be executed by the system in FIG. 1;

[0019] FIG. 10 is a flow diagram of Al shopping method, which may be executed by the system in FIG. 1;

[0020] FIG. 11 is a flow diagram of a nutrition analysis method, which may be executed by the system in FIG. 1;

[0021] FIG. 12 is a flow diagram of a multi-source dietary input method, which may be executed by the system in FIG. 1;

[0022] FIG. 13 is a flow diagram of a food text parsing and NLP normalization method, which may be executed by the system in FIG. 1;

[0023] FIG. 14 is a flow diagram of an ingredient and dish decomposition method, which may be executed by the system in FIG. 1;

[0024] FIG. 15 is a flow diagram of a macro and micro nutrient computation method, which may be executed by the system in FIG. 1;

[0025] FIG. 16 is a flow diagram illustrating an integration method, which may be executed by the system in FIG. 1;

[0026] FIG. 17 is a flow diagram of a food normalization and nutrition computation method, which may be executed by the system in FIG, 1;

[0027] FIG. 18 is a flow diagram of a user preferences and constraints method, which may be executed by the system in FIG. 1;

[0028] FIG. 19 is a flow diagram of a method of nutrition-driven goal translation and target generation, which may be executed by the system in FIG. 1;

[0029] FIG. 20 is a flow diagram illustrating a method of integrating meal planning ingredients with an Al shopping method, which may be executed by the system in FIG.1;Atty Docket No, 2523.100.01US

[0030] FIG. 21 is a flow diagram of an inventory item categorization and product¬ ingredient mapping method, which may be executed by the system in FIG. 1;

[0031] FIG. 22 is a flow diagram of a method of multi-source pantry acquisition, realtime ingredient depletion, and smart replenishment, which may be executed by the system in FIG. 1;

[0032] FIG. 23 is a flow diagram of a method of inventory-aware meal recommendations with recipe feasibility analysis, which may be executed by the system in FIG. 1;

[0033] FIG. 24 is a flow diagram illustrating a pantry management method, which may be executed by the system in FIG. 1;

[0034] FIG. 25 is a schematic of a system for facilitating purchases, which may include the system in FIG. 1; and

[0035] FIG. 26 is a flow chart of a method of facilitating purchases, which may be executed by the system in FIG. 1 and / or FIG. 25.DETAILED DESCRIPTION

[0036] To address various consumer needs, Applicant has developed a unified, intelligent framework that may link grocery shopping, nutritional computation, meal planning, and inventory management. Applicant's system may provide an Al-driven pipeline to interpret user intent through multi-modal inputs, perform granular nutritional analysis, update inventory in real time, and optimize grocery procurement across multiple retailers. Applicant's integrated, automated ecosystem may remove or reduce disjointed workflows, redundant manual tasks, and inefficiencies in both dietary management and household operations.

[0037] Embodiments herein may include a comprehensive, end-to-end platform unifying dietary input capture, nutritional computation, inventory synchronization, meal planning, and intelligent grocery fulfillment within a closed-loop Al architecture.

[0038] As used herein, an Al engine core is a processor-executed software module implemented on one or more computing devices, the module being configured to apply one or more artificial intelligence (Al) models to input data stored in memory to performAtty Docket No. 2523.100.01USdata-processing operations and generate output data that is stored, transmitted, or used to control downstream computational processes. An Al model is a software- implemented, parameterized construct executed by one or more processors, using parameters stored in one or more memory devices, to transform structured or unstructured input data into output data. Machine learning refers to computational techniques in which parameters of the Al model are determined or updated based on training data processed by the one or more processors, thereby enabling automated data-processing operations without requiring explicit rule programming for each possible input.

[0039] For the purpose of this document, the term "engine" shall be understood to reference software logic implemented by one or more sets of executable instructions stored in memory and executed by one or more processors to perform a defined method, function, or set of functions. As used herein, a "pipeline" references multiple processing stages arranged in a defined execution order, each stage implemented by software instructions and associated data structures that, when executed by one or more processors, perform a respective operation on input data and provide output data to a subsequent stage. The stages may operate sequentially, in parallel, asynchronously, or with buffering between stages unless otherwise stated. Any method, process, or step described herein may be implemented, in whole or in part, by software instructions stored in memory and executed by one or more processors, alone or in combination with hardware or firmware components.

[0040] With reference now to FIG. 1, embodiments herein may include a client-server software system 300 with architecture as illustrated. The system 300 may be deployed on cloud infrastructure and designed for scalability and high availability. The client layer 001 may be any user-facing interface through which a user can interact with the core Al engine. This may include web browsers, mobile applications, desktop applications, or even loT devices with a user interface. Clients may communicate with the server over secure HTTP / HTTPS protocols, and the system 300 may also expose RESTful APIs forAtty Docket No. 2523.100.01USprogrammatic access. User authentication and session management may occur at this layer 001 e.g., via login forms or OAuth single sign-on.

[0041] Requests from clients may first reach a load balancer or reverse proxy 002. This component distributes incoming traffic among multiple back-end servers to ensure no single server is overwhelmed. In a Kubernetes or containerized deployment, this load balancing may be handled by a service layer which also monitors the health of instances and performs rolling updates. The load balancer 002 ensures the system can handle many simultaneous users by scaling horizontally.

[0042] Behind the load balancer 002, there may be one or more application server instances 003, 004, 005. These instances run identical copies of the core application and are responsible for executing the business logic. They may have an Al engine core 006 as well as standard web application logic. Each instance 003, 004, 005 may have a WSGI or similar server to handle web requests, and the instances connect to shared resources like the database and cache. The Al engine core 006 may refer to the set of specialized components to perform the unique functions of embodiments herein, including the system illustrated in FIG. 25, the method illustrated in FIG. 26, and / or the architecture illustrated in FIG. 1. In some embodiments, the Al engine core 006 may perform multi¬ modal input processing, interaction with Al models for understanding inputs and making recommendations, orchestrating product searches, running the recommendation algorithms, managing the shopping cart workflow, calorie tracking, nutritional analysis, meal planning, and / or pantry management.

[0043] Continuing with FIG. 1, various data storage and background processing components may support the Al engine core 006. The components may include a relational database 007 such as PostgreSQL to store persistent data including user accounts, saved preferences, orders, items, nutritional profiles, meal plans, user pantry, etc. A cache store 008, like Redis, may be used for session data and cache results of external API queries to speed up searches as discussed herein. The cache store 008 may hold ephemeral data like ongoing chat contexts with the LLM. Asynchronous workers 009 may handle tasks which are better done outside the immediate web request-Atty Docket No. 2523.100.01USresponse cycle - for example, sending an email confirmation, refreshing a token for an API, performing a long-running nutritional analysis, or syncing data periodically. These data storage and background processing components 007, 008, 009 may be managed by a task queue system and / or scale separately.

[0044] The system 300 may include a static file server 010 having means for serving static files such as front-end JavaScript, CSS, and image assets; in production, this might be done via a CDN or a dedicated static server, which may include a web server executing stored instructions that retrieve static digital assets from non-volatile memory and transmit the assets over a network interface.

[0045] In some embodiments, the Al engine core 006 interacts with a plurality of external services or APIs 011 to fulfill its functions. Key external integrations in the system 300 may include: retailer APIs to search products and fetch details; nutritional information and meal recommendations from food databases; Al services, notably a large language model API which has both vision and text capabilities, used for interpreting images and context as well as for making recommendation decisions; a speech-to-text service for transcribing voice inputs; and / or payment gateway APIs to handle secure payment transactions when the user checks out. The system 300 may integrate with any equivalent technology providing the required functionality. For example, in some embodiments, the vision analysis is done by a custom-trained OCR model instead of an API, or the LLM could be self-hosted if available, etc.

[0046] The system 300 may have a modular design architecture to allow upgrades or swaps of components without affecting the overall system workflow.

[0047] USE EXAMPLE:

[0048] In operation, a typical user session might involve the client sending a request such as an image upload or a text submission through the client layer 001. The request goes through the load balancer 002 to one of the server instances 003, 004, 005, which then engages the Al engine core 006 to process the input, query external services, and build a response, such as a set of recommended items or an updated cart state. The server then responds back to the client with results. Because of the robust architectureAtty Docket No, 2523.100.01USwith caching and parallel processing, the system 300 is able to handle these complex tasks efficiently, providing near real-time suggestions despite heavy Al processing and multiple API calls. This architecture may ensure reliability, scalability, and security at each layer, with measures like database encryption, secure communication, TLS for all client-server and server-API interactions, and proper error handling in place.

[0049] Al Engine Core, Al Intent Engine Capability - Multi Modal Input

[0050] With reference now to FIG. 2, a method of intent analysis 302 using an Al intent engine 020, and suitable for use in the system 300, is described in more detail. The method of intent analysis 302 may include a multi-modal input processing flow, such as for transforming heterogeneous user-provided shopping inputs into structured intent outputs consumable by multiple downstream application subsystems. At least a portion of the method of intent analysis 302 may be achieved by the Al engine core 006 and / or the Al engine core 006 may include an Al intent engine 020.

[0051] As shown in FIG. 2, the architecture may include a user input interface 012, which provides a unified interaction layer through which a user may submit shopping- related input using one or more modalities. The user input interface 012 may be implemented via a mobile application, web application, voice assistant interface, or other interactive computing environment, may be configured to route received input to modality-specific processing pipelines. The user input interface 012 may be associated with the client layer 001 and / or application server instances 003, 004, 005.

[0052] From the user input interface 012, user input may be selectively routed to an image input module 013, a voice input module 014, or a text input module 015, depending on the format of the input provided by the user.

[0053] The image input module 013 receives visual representations of shopping intent, including but not limited to handwritten lists, printed receipts, and / or photographic images of items or packaging. The image input module 013 forwards the received image data to an encoding module 016 such as a base64 encoding module, which converts the image data into a standardized encoded representation suitable for machine processing and transmission.Atty Docket No. 2523.100.01US

[0054] The encoded image data is then processed by a vision-based optical character recognition (OCR) engine 018, which applies computer vision and text recognition techniques to extract textual content and candidate item descriptors from the image. The extracted output generated by the OCR engine 018 is forwarded to a downstream normalization stage.

[0055] The voice input module 014 receives audio input representing spoken shopping intent, such as verbally dictated grocery lists or commands, which may be captured in a compressed audio format. The audio input is transmitted to a voice-to-text transcription module 017, which converts the spoken audio into a textual representation.

[0056] The textual output generated by the voice-to-text transcription module 017 is forwarded directly to the same downstream normalization stage as the image-derived text, thereby enabling unified handling of different input modalities.

[0057] The text input module 015 receives typed or otherwise directly entered natural¬ language text representing shopping intent. In contrast to the image and voice pathways, the textual input provided through the text input module 015 may be routed directly to the downstream normalization stage without intermediate conversion.

[0058] Textual outputs from the OCR engine 018, the voice-to-text transcription module 017, and the text input module 015 converge at a normalization engine 019, which performs parsing, cleaning, normalization, and structural alignment of extracted item data. The normalization engine 019 resolves spelling variations, unit inconsistencies, synonyms, and formatting differences to generate a standardized representation of user intent.

[0059] The normalized output may be shared with an Al intent engine 020, which applies machine-learning and large language model-based reasoning to infer higher- level intent associated with the normalized input. The Al intent engine 020 may function as an orchestration and routing layer, which may be implemented as a centralized coordination service, model-context-protocol (MCP) server, or equivalent control mechanism capable of directing structured intent to appropriate downstream engines.Atty Docket No. 2523.100.01US

[0060] Continuing with FIG. 2, the Al intent engine 020 may incorporate a retry logic mechanism, such as a limited number of reprocessing attempts, to improve confidence and accuracy when ambiguous or incomplete intent signals are detected.

[0061] Based on the inferred intent, the Al intent engine 020 may selectively route structured intent outputs to one or more downstream application subsystems, including an Al shopping subsystem 021, a nutrition analysis subsystem 022, a calorie tracking subsystem 023, a meal planning subsystem 024, and a pantry management subsystem 025.

[0062] Each downstream subsystem 021, 022, 023, 024, 025 may be configured to consume the intent output generated by the Al intent engine 020 and perform domain¬ specific processing, such as automated cart construction, nutritional computation, dietary logging, meal recommendation, or inventory management. The internal operation of these downstream subsystems is described in further detail with reference to subsequent figures.

[0063] FIG. 3 illustrates a text-based input processing method 304, providing a detailed view of processing natural-language text received via the text input pathway of the Al engine core 006 or Al intent engine 020 described with reference to FIG. 1 and FIG. 2 and may be suitable for use in the system 300 of FIG. 1.

[0064] Free-form natural language text may be received at a free-form text input module 026 and forwarded to a text pre-processing module 027, which performs sanitation operations including lowercasing, whitespace trimming, punctuation removal, and Unicode normalization. The processed text is then segmented by a tokenization module 028, which parses sentences, words, conjunctions, and delimiters to isolate candidate item expressions.

[0065] The tokenized output may be standardized by a normalization module 029, which resolves singular and plural forms, maps synonyms, removes duplicates, and enforces standard terminology. The resulting structured output 030 represents normalized item data formatted for consumption by the normalization and intentAtty Docket No. 2523.100.01USanalysis layers of FIG. 2, including the normalization engine 019 and Al intent engine 020.

[0066] FIG. 4 is an image processing and optical character recognition (OCR) pipeline 306, which may implement the image input pathway originating from the user input interface 012 and image input module 013 of FIG. 2.

[0067] Image data received at an image upload module 031 may be prepared by an image pre-processing module 032, which performs encoding, format validation, and size optimization. The processed image is analyzed by a vision-based OCR engine 033, which extracts textual content and produces a raw OCR text output 034.

[0068] The raw OCR text output may be subjected to text pre-processing, tokenization, and normalization operations collectively represented by modules 035, 036, 037, corresponding functionally to the text-based input processing method 304 described with reference to FIG. 3. The resulting structured output 038 may be forwarded to an Al intent engine 039, which corresponds to or is unitary with the Al intent engine 020 of FIG. 2 or Al engine core of FIG. 1 and performs intent inference and downstream routing. The image processing and optical character recognition (OCR) pipeline 306 may be suitable for use in the system 300 in FIG. 1.

[0069] FIG. 5 is a flow diagram of a voice input parsing method 308 or pipeline, implementing the voice input pathway originating from the user input interface 012 and voice input module 014 of FIG. 2. Audio input received at a voice input module 040 may be prepared by an audio capture module 041 and transcribed into text by a speech-to- text transcription engine 042, producing a raw transcript 043. The raw transcript undergoes text pre-processing, tokenization, and normalization operations represented by modules 044, 045, 046, corresponding to the processing stages and pipeline 304 described with reference to FIG. 3. The voice input parsing method 308 may be suitable for use in or executed by the system 300 in FIG. 1 or Al engine 006.

[0070] The resulting structured representation may be forwarded to an Al intent engine 047, corresponding to or unitary with the Al intent engine 020 of FIG. 2 or Al engineAtty Docket No, 2523.100.01UScore of FIG. 1, for higher-level intent inference and routing to downstream application subsystems.

[0071] Core Al Engine Capability - Al Shopping

[0072] With reference to FIG. 6, some embodiments may include a user preference and modifier mapping method 310 and for product filtering, which operates downstream of the multi-modal input processing and intent analysis architecture illustrated in FIG. 2. As shown in FIG. 6, normalized user intent data, including extracted items and associated preferences, may be provided as user input and preferences 049 to an Al intent engine 050.

[0073] Based on the inferred intent, the Al intent engine 050 routes the request to an Al shopping algorithm 051 when the intent corresponds to product discovery or purchase fulfillment. The Al shopping algorithm 051 initiates product discovery by requesting product search results from retailer APIs 052, returning a candidate set of products for each identified item. The mechanisms for extracting product data from retailer systems are described in further detail with reference to FIG. 7.

[0074] User preferences and linguistic modifiers associated with the input are processed by a preference parser 053, which extracts modifiers, maps them to predefined categories, assigns priority rankings, and applies constraint rules. The parsed modifiers are classified into modifier categories 054, which may include quality attributes, price constraints, rating thresholds, brand preferences, and retailer preferences.

[0075] These modifier categories are applied across multiple evaluation dimensions, including user preference filters 055, quality filters 056, price analysis 057, and rating criteria 058. Outputs from these dimensions are combined by a filter aggregator 059, which applies logical operations, priority weighting, conflict resolution, and fallback rules to generate a filtered candidate set 060.

[0076] The filtered candidate set is provided to an LLM decision engine 061, which evaluates the remaining products holistically, applies preference weighting, and selectsAtty Docket No. 2523.100.01USan optimal product. The output is generated as a recommended product 062, including selection justification and readiness for cart addition.

[0077] For example, a user may input: "organic spinach, 2 gallons of milk, and a dozen eggs."

[0078] Using the multi-modal pipeline described in FIGS. 2-5, the method 310 extracts items and modifiers, recognizing that "organic" applies to spinach, "2 gallons" represents a quantity and unit for milk, and "a dozen" corresponds to twelve eggs. Equivalent phrasings (e.g., "two gal milk" or "cage-free eggs") are normalized into a structured item list carrying quantities and preferences.

[0079] The Al intent engine 050 may identify the intent as a shopping-related request and route the structured data to the Al shopping algorithm 051. The unified item list, independent of input modality, is then used to initiate product searches and preferencebased filtering beginning at Al shopping algorithm 051.

[0080] In some embodiments, the interpreted item list may be presented to the user for confirmation or correction prior to product search, after which the system proceeds to retrieve and evaluate products satisfying the identified constraints.

[0081] FIG. 7 shows retailer API integration architecture 312 for a multi-platform product search system, which may implement the product discovery stage initiated at Ai shopping algorithm 051 of FIG. 6.

[0082] A product search request 063 may be generated for a normalized item (e.g., "milk") and forwarded to an API orchestrator 064. The API orchestrator 064 functions as a centralized coordination layer responsible for distributing search requests across multiple retailer platforms while managing load balancing, retry logic, rate limiting, and error handling.

[0083] The API orchestrator 064 may route the search request to one or more retailerspecific adapters, including retailer A API adapter 065, retailer B API adapter 066, retailer C API adapter 067, and retailer D API adapter 068. Each adapter may translate the normalized request into a retailer-compatible format and manages authentication and protocol differences, such as OAuth-based authorization, API key authentication,Atty Docket No, 2523.100.01USREST or GraphQL communication, schema conversion, or interaction with third-party aggregation services.

[0084] Responses received from the retailer adapters may be forwarded to a unified schema processor 069, which normalizes heterogeneous retailer data into a common internal representation. The unified schema processor 069 performs operations including data normalization, price conversion, and stock validation, enabling consistent downstream evaluation across retailers.

[0085] In some embodiments, the unified schema processor 069 interacts with a cache layer 070, such as a Redis-based cache, to improve performance through query hashing, response reuse, and cache invalidation strategies.

[0086] The normalized and validated product data may then be output as aggregated results 071, sorted or scored as appropriate, and provided in a format ready for Al- based ranking and decision processing as described in subsequent figures.

[0087] The recommended products may come from different retailers. One key aspect of this embodiment may be to mix and match retailers to get the best combination (though it might also allow users to constrain to one retailer if they prefer a single checkout; this could be a user choice). Once the system has selected specific products for all the user's requested items, it moves into the cart management phase.

[0088] Following the generation of aggregated and ranked product results as described with reference to FIG. 7, the system 300 may select a single optimal product and automatically insert the selected product into a user cart. See FIG. 8.

[0089] Turning now to FIG. 8, a cart management and order linking method 314 and architecture are now described. The recommended product 072, generated by the Al engine core 006 or method 310 and including a product identifier, product details, and session context, is programmatically added to a cart without requiring explicit user action. This automatic cart insertion enables a frictionless, Al-driven purchase flow in which one recommended product is directly staged for checkout.Atty Docket No. 2523.100.01US

[0090] Once the product has been added to the cart, a session manager 073 evaluates the user's authentication state, retrieves or generates a session identifier, and determines the appropriate cart association.

[0091] If the user is unauthenticated, the cart is maintained as an anonymous cart 074, which is session-based, stored using a session key, and not persistently linked to a user account. If the user is authenticated, the cart is maintained as an authenticated cart 075, which is linked to a user identifier and stored in a persistent data store along with order history.

[0092] In embodiments where a user authenticates after the product has already been added to an anonymous cart, a cart merge logic 076 is executed. The cart merge logic 076 transfers the automatically added product to the authenticated cart, resolves duplicate product identifiers if present, preserves item quantities, and clears the anonymous cart state.

[0093] After cart resolution, an order linker 077 associates the cart with an order identifier, applies user association, records timing information, and prepares the order for payment processing and historical tracking.

[0094] The resulting order data is saved as an order record 078, which is linked to the user when authenticated and marked as ready for checkout.

[0095] After merging (or if no merge was needed, e.g., the user was logged in all along), the system 300 or method 310 now has a final order list linked to the user. The order linker creates an order record in the database. This record might contain details such as: a unique order number, references to all the products and their quantities, the total price (if known at this point, which it could calculate by summing item prices), the user's shipping address or pickup method (which the user might have on file), and a status (e.g., " Pending Checkout" or " In Cart"). Essentially, it serializes the cart into a formal order format which can be stored persistently and later retrieved or updated.

[0096] The user is then taken to a checkout interface where they can review the order (the items, prices, fees, etc.). Because the platform or system 300 may deal with multiple retailers, the system 300 could show a breakdown like " These 5 items will beAtty Docket No, 2523.100.01USordered from Store A, and 3 items from Store B" with respective subtotals. The user then confirms and the system 300 triggers the actual purchase process through third- party payment gateways.

[0097] The user can later view their order history in the app, which is possible because the system 300 stored all orders in the database linked to their user profile 074. This order history is useful not just for record-keeping but could feed back into the Al engine core 006. For example, it can learn user preferences from past purchases (if the user always picks a certain brand of yogurt, the Al engine core 006 may favor that brand in future recommendations).

[0098] With cart creation and session handling established as described with reference to FIG. 8, the system supports multiple product-selection modes that determine how items are added to the cart, as shown in FIG. 9.

[0099] FIG. 9 illustrates a work flow method 316 suitable for use in the system 300.Here, a shopping list input 079, representing processed and normalized items derived from the multi-modal pipeline, is provided to a mode selector 080. The mode selector 080 determines whether product selection is performed using an automated Al-driven workflow or a user-controlled manual workflow. Mode selection may be based on user preference, per-item toggles, default configuration, or user override.

[0100] When the automated path is selected, control is directed to an Al mode 081, in which product discovery, evaluation, and selection are performed automatically using the Al engine. In this mode, retailer searches, quality analysis, price evaluation, rating assessment, and best-match determination are executed without further user interaction. The selected product is then automatically added to the cart, as represented by auto-add component 083, enabling immediate progression toward checkout.

[0101] When the manual path is selected, control is directed to a manual mode 082, in which the user interacts with a search interface to browse products, apply filters, compare options, and review product details. Following user review, a user-selected product 084 is added to the cart through an explicit user action.Atty Docket No. 2523.100.01US

[0102] Regardless of selection mode, both workflows converge at a unified shopping cart 085, which contains items added either automatically by the Al engine or manually by the user, and which is prepared for checkout using the cart and order-handling mechanisms described previously.

[0103] Bringing together the individual processing, selection, and fulfillment stages described with reference to FIGS. 2-9, FIG. 10 illustrates the complete end-to-end operational data flow of an Al shopping method 318 or engine, illustrating how user input may be transformed into a completed transaction and how system behavior adapts over time. The Al shopping method 318 may be executed by the system 300 and / or may form part of or communicate with the Al engine core 006. The Al shopping method 318 may include: receive a multi-modal input 086, analyze and understand the input 087, create a normalized list 088, perform a multi-API search 089, aggregate the search results, 090, create an Al recommendation 091, manage a shopping cart 092, complete an order and checkout step 093, and perform a learning loop 094.

[0104] Core Al Engine Capability - Nutrition Analysis

[0105] Turning now to FIG. 11, a nutrition analysis method 320 or engine is described.Following completion of the end-to-end shopping workflow and intent routing described with reference to FIG. 10, the Al intent engine 096 may be further configured to identify and route nutrition-related user intents, as illustrated in FIG. 11. The nutrition analysis engine 320 may be suitable for use in the system 300 of FIG. 1.

[0106] When a user provides a nutrition-focused input, such as a meal name or dietary query, the input may be received through a user interface layer 095 and forwarded to the Al intent engine 096. The Al intent engine 096 classifies the request as a nutrition analysis intent and directs processing to a nutrition analysis engine 097, distinct from the shopping and cart workflows previously described.

[0107] The nutrition analysis engine 097 performs core processing functions including meal name interpretation, database lookup, external data retrieval, and nutritional computation. To support these operations, the engine interfaces with multiple data sources, including a nutrition database 098 containing cached meals, nutrient profiles,Atty Docket No. 2523.100.01USand ingredient data, and a recipe database 099 providing ingredient lists, preparation instructions, and cooking metadata. In some embodiments, additional data is obtained through API-based data sourcing 100 and LLM-based data sourcing 101, enabling structured nutritional analysis and dynamic recipe generation.

[0108] Based on the analyzed nutritional data, the nutrition analysis engine 097 produces structured outputs that may be consumed by multiple downstream systems. These include a meal planner 102, which uses nutritional values to align meals with calorie targets and macronutrient distributions; an inventory system 103, which evaluates ingredient availability and recipe feasibility; and a food logging engine 104, which records meals, tracks caloric intake, and maintains nutritional history. These systems will be later discussed in-depth.

[0109] In addition, nutrition-derived outputs may be routed to the Al shopping engine 105, enabling ingredient discovery, cart integration, and automated or manual product addition when nutrition analysis results in a purchasing intent.

[0110] The system 300 may further support additional dietary input sources that complement the previously described text-, image-, and voice-based inputs, as shown in FIG. 12, which illustrates a multi-source dietary input method 321 or pipeline.

[0111] In the multi-source dietary input method 321, dietary input may be provided through manual text entry 106, such as direct meal name input; image recognition 107, including photo uploads analyzed using vision and language models; and voice input 108, in which natural-language meal descriptions are parsed following speech-to-text conversion. In addition, the system accepts barcode scanning 109, enabling direct lookup of packaged food items using UPC or EAN identifiers, and meal planner outputs 110, which provide system-generated recommended meals as input for downstream nutritional processing.

[0112] Regardless of source, each dietary input is forwarded to an input unification layer 111, which performs format normalization, data validation, entity standardization, and contextual enrichment. This unification step ensures that heterogeneous dietaryAtty Docket No. 2523.100.01USinputs are transformed into a consistent internal representation suitable for further analysis.

[0113] The unified output is generated as a standardized food item entity 112, comprising structured information such as meal name, nutritional attributes, ingredient composition, and associated recipe data. The standardized food item entity 112 may then be consumed by the nutrition analysis engine 320, meal planning subsystem 024, food logging engine 104, or shopping algorithm 051 and inventory subsystems or methods as described herein.

[0114] Following unification of dietary inputs from multiple sources as described with reference to FIG. 12, raw food-related text inputs undergo deeper linguistic and semantic processing to generate a structured representation suitable for nutrition analysis, planning, and downstream actions, as shown in FIG. 13, which illustrates a food text parsing and NLP normalization method 322.

[0115] With the method 322 or engine, a raw text input 113, originating from one of the supported input sources, is first processed by an NLP text parser 114. The NLP text parser 114 performs foundational language processing operations, including tokenization, entity recognition, dependency parsing, semantic analysis, and contextual extraction, to identify relevant food entities and relationships expressed within the text.

[0116] The parsed output is forwarded to an LLM processing engine 115, which operates in coordination with the Al intent engine to interpret higher-level meaning and normalize the extracted information. The LLM processing engine 115 identifies primary dishes, individual ingredients, and portion sizes, analyzes descriptive modifiers such as cooking methods and preparation attributes, and evaluates nutritional implications associated with those descriptors. If an input lists multiple items in one phrase (for example, "toast with butter and jam"), the engine will separate this into distinct entries: "toast - 1 slice", "butter - 1 serving (e.g., 1 pat or 1 tablespoon)", "jam - 1 serving (e.g., 1 tbsp)". This involves understanding "with" in this context indicates additional ingredients / toppings rather than a single complex item. A large language model is adept at this kind of interpretation, using its trained knowledge of common food pairings andAtty Docket No. 2523.100.01USsyntax to split items logically. Ambiguities in phrasing are resolved, and units and representations are standardized.

[0117] The result of this processing is a structured output 116, generated in a machine- interpretable format, such as a structured JSON object, which explicitly represents dishes, ingredients, portions, and modifiers derived from the original text input. This structured output may then be consumed by the nutrition analysis engine, meal planning workflows, food logging systems, or shopping and inventory components described in earlier figures.

[0118] For example, a user may input the raw text: " Grilled chicken breast with low-oil roasted vegetables." Through NLP parsing and LLM-based interpretation, the system 300 or engine 322 identifies: a primary dish ("chicken breast"), associated ingredients ("chicken," "vegetables"), a portion reference ("one breast"), and preparation modifiers indicating a grilled cooking method and reduced oil usage.

[0119] The resulting structured representation may be expressed as:{"dishes": ["chicken breast"],"ingredients": ["chicken", "vegetables"],"portions": ["1 breast"],"modifiers": {"cooking_method": "grilled","oiljevel": "low"}}

[0120] After food-related text has been parsed and normalized into a structured representation as described with reference to FIG. 13, the system 300 may further decompose identified dishes into constituent ingredients and nutritional components, as shown in FIG. 14, which illustrates an ingredient and dish decomposition method 326.

[0121] In this method 326, a dish name 117, such as " Chicken Tikka Masala," is provided to a dish decomposition engine 118. The dish decomposition engine 118 performs dishAtty Docket No. 2523.100.01USdatabase lookup and LLM-based semantic breakdown to identify constituent ingredients, normalize ingredient quantities, and classify preparation methods associated with the dish. The decomposition engine 118 resolves this either by retrieving known compositions or inferring them. In one mode, the engine 118 accesses a recipe database or knowledge base containing standard recipes. When the user's dish name matches an entry, the system 300 or method 326 retrieves the canonical ingredient list and typical quantities and scales these amounts to the user's portion size. This database may be internal or provided by external APIs, including recipe or nutrition services which returns ingredient breakdowns or even complete nutritional analyses. The system 300 may use those results directly or compute nutrients internally after obtaining the ingredient list.

[0122] The output of the dish decomposition engine 118 may include a structured ingredient list 119, specifying individual ingredients and associated quantities, and corresponding nutrient components 120, which represent calculated nutritional values such as protein, carbohydrate, fat content, and serving size.

[0123] In addition, preparation context identified during decomposition may be expressed as cooking method data 121, which may include techniques such as simmering, sauteing, or garnishing, and which may influence nutritional calculations or recipe feasibility.

[0124] Based on the identified ingredients and nutritional constraints, the system 300 or method 326 may further generate substitutable alternatives 122, enabling ingredient replacement while preserving dish intent, dietary goals, or user preferences. For example, animal-based ingredients may be substituted with plant-based alternatives, or dairy component replaced with non-dairy equivalents.

[0125] The outputs of FIG. 14 may be consumed by the nutrition analysis engine, meal planning workflows, inventory feasibility checks, or shopping subsystems described in earlier figures, enabling ingredient-level control across nutrition, planning, and commerce functions.Atty Docket No. 2523.100.01US

[0126] From the ingredient- and nutrient-component outputs produced by the dish decomposition flow of FIG. 14, the platform or system 300 may perform recipe-level and user-level nutritional computation, as shown in FIG. 15, which illustrates a macro and micro nutrient computation method 328 or engine. The macro and micro nutrient computation method 328 may be suitable for use in or executed by the system 300.

[0127] An ingredient list 123 (e.g., ingredients with associated quantities) may be provided as input to a unit converter 124, which normalizes heterogeneous quantity expressions into a common computational unit, such as grams. In some embodiments, the unit converter 124 maps volumetric units (e.g., teaspoons, cups, milliliters) to mass units using ingredient-specific density mappings, converts “count" units (e.g., one onion, one egg) using standard weight profiles, and resolves packaging-based quantities (e.g., "one can," "one packet") using product taxonomy metadata.

[0128] The normalized ingredient quantities may then be combined with preparation context expressed as cooking modifier data 125, which captures cooking-method transformations that can affect nutrient retention, fat uptake, or water loss during preparation. By way of example, the cooking modifier data 125 may specify that boiling reduces vitamin C content, frying increases fat content due to oil absorption, and grilling preserves certain components more directly. The cooking modifier data 125 may be derived from recipe instructions, inferred preparation methods from FIG. 14, user- entered cooking selections, or default cooking assumptions associated with particular dish types. In some embodiments, modifiers are applied as multiplicative retention factors, additive absorption factors, or yield adjustments, and may differ between macronutrients and micronutrients.

[0129] Normalized ingredient data from the unit converter 124 and cooking modifier data 125 may be processed by a nutrient computation engine 126, which determines nutritional values across both macronutrient and micronutrient dimensions. The nutrient computation engine 126 performs macronutrient calculations including calories, protein, carbohydrates, total fat, fiber, and sugar, and may additionally compute derived metrics such as net carbohydrates, saturated fat, or caloric distributionAtty Docket No. 2523.100.01USby macronutrient class. The nutrient computation engine 126 also performs micronutrient calculations including vitamins (e.g., A and B-complex family members, C, D, E, and K) and minerals (e.g., iron, calcium, zinc, magnesium, sodium, and potassium). In some embodiments, the nutrient computation engine 126 aggregates ingredient-level nutrient profiles sourced from one or more nutrition databases (as referenced in FIG. 11) and applies cooking modifier adjustments to generate an updated nutrient profile reflective of the prepared dish rather than raw ingredients alone.

[0130] The nutrient computation engine 126 or method may output a per-recipe total 127, representing aggregated nutritional values for the full recipe batch, including total calories, total protein, and total servings. The total servings value may be supplied directly from a recipe record, inferred from recipe yield, inferred from ingredient scaling, or adjusted according to user-provided serving preferences.

[0131] The per-recipe total 127 may be allocated into a per-serving representation 128, which computes nutrition values for an individual serving based on the recipe yield. In some embodiments, the per-serving representation 128 is computed as a proportional division of the per-recipe total 127, while in other embodiments serving-specific adjustments may be applied when the recipe includes non-uniform distribution elements (e.g., toppings, garnishes, sauces) or when preparation stages create stratification of ingredients.

[0132] Finally, the system 300 or engine 328 may compute a per-user portion representation 129, which adjusts the per-serving values based on a user-specific portion selection. For example, where a user consumes 1.5 servings, the per-user portion representation 129 scales calories and nutrient quantities accordingly. In some embodiments, portion sizing may be user-entered, inferred from meal logging behavior, inferred from historical consumption patterns, inferred from plate / photo analysis, or derived from dietary targets maintained by a meal planner (e.g., the meal planner 102 of FIG. 11).

[0133] The method 328 or engine illustrated in FIG. 15 may enable consistent nutrition computation across heterogeneous inputs by (i) normalizing ingredient quantities, (ii)Atty Docket No. 2523.100.01USincorporating cooking-method effects, (iii) aggregating ingredient-level nutrient profiles into recipe-level totals, and (iv) producing serving- and user-specific nutritional outputs. The outputs of the method 328 or engine may be used by downstream methods or subsystems including nutrition display interfaces, meal planning, calorie tracking, dietary goal enforcement, and ingredient-driven shopping actions described in preceding figures.

[0134] With reference now to FIG. 16, following decomposition of a dish into constituent ingredients and computation of serving-adjusted nutritional quantities as described with reference to FIGS. 14 and 15, the system 300 may enable direct conversion of nutrition-derived ingredients into purchasable products.

[0135] FIG. 16 illustrates an integration method 330 which may be executed by the system 300. A user input 130, such as a dish name and desired serving size (e.g., " Chicken Tikka Masala, serving size 4"), is processed by the nutrition analysis engine 131, which identifies and quantifies the required ingredients based on dish composition, portion scaling, and cooking context. The output of the nutrition analysis engine 131 is an ingredient list with normalized quantities suitable for procurement.

[0136] The identified ingredients are forwarded to an Al shopping engine 132, which initiates product discovery and selection on a per-ingredient basis. For each ingredient, the Al shopping engine 132 performs product search across one or more retailers, applies price comparison, quality filtering, user preference matching, and brand selection logic, as described with reference to earlier shopping figures.

[0137] Responsive to this evaluation, the system 300 may generate a product selection per ingredient 133, determining an optimal product that satisfies availability constraints, pricing considerations, quality scores, and quantity requirements derived from the nutrition analysis. Quantity calculation ensures that selected products align with the ingredient amounts needed for the specified number of servings.

[0138] The selected products may then be automatically added to a user cart 134, enabling seamless transition from nutritional analysis to commerce without requiring the user to manually search for or select individual ingredients.Atty Docket No. 2523.100.01US

[0139] Core Al Engine Capability - Calorie Tracking

[0140] In addition to shopping and nutrition analysis intents, the Al intent engine 020 may be configured to identify and route calorie tracking intents, enabling users to log consumed meals and monitor nutritional intake over time.

[0141] Turning now to FIG. 17, a food normalization and nutrition computation method 332 is now described. A raw log entry 135, derived from parsed user input and intent classification, includes food identifiers, quantities, and contextual metadata such as meal timing (e.g., dinner). The raw log entry 135 may be forwarded to a food normalization and dish decomposition module 136 such as dish decomposition engine 118, which performs standardized food matching and quantity normalization.

[0142] The food normalization module 136 may match the logged food to a canonical food representation using public or proprietary nutrition databases (e.g., USDA references), branded product mappings, or recipe-based dish definitions. Quantity expressions are normalized by converting mass or volume units (e.g., grams, cups, servings) into a standardized unit representation, such as grams, yielding a standardized food entity 137.

[0143] For the example input, "500 gm of chicken tikka masala," the normalization process resolves the dish to a standardized dish entity and confirms the logged quantity as 500 grams.

[0144] The standardized food entity 137 is provided to a nutrition computation engine 138, which calculates nutritional values corresponding to the logged quantity. The nutrition computation engine 138 computes both macronutrients and micronutrients, including calories, protein, carbohydrates, fats, fiber, vitamins, minerals, and sodium, using nutrient profiles and preparation-aware adjustments as described with reference to earlier nutrition figures.

[0145] The computed nutritional data may be recorded as a logged meal 139, which represents a persistent record of the consumed food item, associated nutritional values, and contextual metadata such as meal type and timestamp.Atty Docket No. 2523.100.01US

[0146] The logged meal 139 contributes to daily totals 140, which aggregate nutritional intake across all logged meals within a defined time window, such as a calendar day. Daily totals may include cumulative calories, macronutrient distribution, and micronutrient intake.

[0147] The aggregated daily totals 140 may be evaluated against nutrition goals 141, which may include calorie targets, macronutrient ratios, or other dietary objectives. Progress toward these goals may be tracked over time and presented to the user through reporting or visualization interfaces.

[0148] For the user input: " Log 500 gm of chicken tikka masala for dinner," The Al intent engine 020 may route the request to the calorie tracking method 332. The system 300 may identify "chicken tikka masala" as the food entity and "500 gm" as the consumed quantity; normalize the dish and quantity into a standardized food entity; compute nutritional values corresponding to 500 grams of the dish; record the meal as a logged meal entry; updates the user's daily calorie and nutrient totals; and evaluate progress against predefined nutrition goals.

[0149] As nutritional values are computed and the meal is logged, the system 300 may perform ingredient-level inventory reconciliation based on the same analysis pipeline. Specifically, ingredient quantities derived by the nutrition analysis engine during dish decomposition and portion scaling are provided to the pantry management module 025 for inventory adjustment,

[0150] Core Al Engine Capability - Meal Planning

[0151] Following identification and handling of shopping, nutrition analysis, and calorie tracking intents as described in the preceding figures, the Al intent engine 020 may be configured to support a meal planning intent, which relies on structured intake of user preferences and constraints, as shown in FIG. 18, which illustrates a user preferences and constraints method 334 or pipeline.

[0152] When a user initiates meal planning, the system 300 may present a guided questionnaire through which multiple categories of preferences and constraints areAtty Docket No. 2523.100.01UScollected. These inputs form the basis for generating personalized meal plans aligned with dietary goals, lifestyle constraints, and user tastes.

[0153] User-provided inputs may include dietary patterns 142, such as vegan, vegetarian, ketogenic, or paleo preferences; allergens and dislikes 143, including dietary exclusions such as dairy-free or gluten-free requirements and explicitly disliked foods; and cultural or cuisine preferences 144, for example Italian, Indian, or American cuisines.

[0154] In addition, the questionnaire captures nutrition targets 145, such as calorie goals, macronutrient ratios, protein targets, carbohydrate limits, and fat balance objectives. Practical constraints are further specified through budget and time constraints 146, which may include budget ranges, preferred cooking days, acceptable meal preparation times, and storage duration limits.

[0155] All collected inputs are forwarded to a validation engine 147, which performs conflict detection and constraint checking. The validation engine 147 resolves incompatible inputs (for example, conflicting dietary patterns and ingredient selections), ensures feasibility of nutritional targets, and enforces logical consistency across constraints before meal plan generation proceeds.

[0156] Validated preference data is then stored in a profile storage module 148, which persists user preferences in a database and maintains version tracking to allow historical comparison and rollback if needed.

[0157] Over time, the meal planning profile is refined through a user feedback loop 149, which incorporates signals such as meal skips, logged consumption, recipe ratings, and adherence behavior. These feedback signals are processed to infer evolving preferences and tolerance patterns.

[0158] The updated preference state is continuously refined through continuous updates 150, enabling profile evolution, goal progression tracking, and Al-driven refinement of meal planning outputs. Updates from this stage are written back to the profile storage module 148, ensuring that future meal plans reflect both explicit questionnaire inputs and implicit behavioral learning.Atty Docket No. 2523.100.01US

[0159] With user preferences and constraints captured and validated as described with reference to FIG. 18, the meal planning intent further translates high-level user goals into actionable nutritional targets and optimized meal plans, as illustrated in FIG. 19.

[0160] FIG. 19 illustrates a method 336 of nutrition-driven goal translation and target generation. Meal planning begins with user high-level goals 151, which may include objectives such as weight loss at a specified rate, lean muscle gain, weight maintenance, blood sugar control, or athletic performance optimization. These goals represent outcome-level intent rather than direct nutritional parameters.

[0161] The high-level goals 151 are provided to a nutrition analysis engine 152, which computes individualized baseline requirements and nutritional targets. In some embodiments, the nutrition analysis engine 152 calculates basal metabolic rate (BMR), adjusts caloric needs based on activity level, and derives macronutrient and micronutrient targets aligned with the stated goal.

[0162] Derived nutritional parameters are forwarded to a target generation module 153, which converts goal-level requirements into concrete planning constraints. Target generation may include establishing a daily calorie budget, allocating calories across meals, determining protein-carbohydrate-fat splits, setting micronutrient quotas, and applying timing constraints such as meal spacing or pre- / post-workout nutrition windows.

[0163] Using these targets, candidate recipes are evaluated by a recipe ranking engine 154, which scores available recipes based on nutritional fit, preference alignment, cooking time, and preparation difficulty. The recipe ranking engine 154 may consider both existing recipes and dynamically generated options.

[0164] In some embodiments, the system 300 may use, incorporate, or communicate with an Al recipe generator 156, which uses large language model techniques to create or adapt recipes that satisfy nutritional targets while respecting user preferences and constraints. Generated or selected recipes are then evaluated for feasibility using a pantry inventory system 157, which checks ingredient availability, quantity sufficiency, and substitution options.Atty Docket No. 2523.100.01US

[0165] The ranked and feasible recipe options are provided to a meal plan solver 155, which applies constraint propagation and optimization algorithms to assemble a coherent meal plan over a planning horizon (e.g., daily or weekly). The solver balances nutritional targets, user constraints, ingredient availability, and variety considerations. The Meal Plan Solver may adjust the plan to use up items which are abundant or nearing expiration in the pantry (to reduce waste and extra shopping). If two recipes are nutritionally similar fits, the system may favor the one which uses the chicken already in the freezer.

[0166] The output of the solver is a generated meal plan 158, which may include a daily meal schedule, nutritional breakdowns per meal and per day, an associated shopping list, and cooking instructions. The generated meal plan 158 may be further integrated with shopping, pantry management, nutrition tracking, and feedback systems described in earlier figures.

[0167] Once a meal plan has been generated in accordance with nutritional goals and constraints as described with reference to FIG. 19, the system translates the plan into actionable procurement steps through integration with the Al shopping engine, as shown in FIG. 20, which illustrates a method of integrating meal planning ingredients with an Al shopping method 338.

[0168] A generated meal plan 159, including a recipe list, ingredient requirements, and quantities needed over the planning horizon, is provided to an inventory check module 160. The inventory check module 160 compares required ingredients against the user's existing pantry inventory to identify missing items and calculate net quantities that must be procured.

[0169] For each missing or insufficient ingredient, a structured request builder 161 constructs a standardized shopping request comprising item name, category, required quantity and unit, and applicable user preferences derived from the meal planning profile.

[0170] The structured requests are forwarded to the Al shopping engine 162, which performs product discovery and matching across one or more retailers. The Al shoppingAtty Docket No. 2523.100.01USengine 162 evaluates candidate products using price comparison, quality and nutrition scoring, and retailer availability, consistent with the shopping workflows described in earlier figures.

[0171] An optimization engine 163 further refines product selection by selecting variants that best satisfy health criteria, value metrics (e.g., price per unit or price per nutrient), and store preferences. Where a requested ingredient is unavailable or unsuitable, substitution logic 164 is applied to identify acceptable alternatives, including allergy-safe substitutions, nutrition-matched swaps, or equivalent ingredients that preserve meal plan intent.

[0172] Following substitution resolution, a product selection module 165 finalizes specific brands and SKUs, confirms unit pricing and quantities, and associates nutritional metadata with each selected product.

[0173] The finalized products are then automatically added to a user cart 166, where cart synchronization, quantity adjustments, and checkout readiness are handled in accordance with the cart management architecture described previously.

[0174] Core Al Engine Capability - Pantry Management

[0175] The platform maintains a unified pantry representation that can be referenced by meal planning 024, calorie tracking 023, nutrition analysis 022, and shopping workflows 021. FIG. 21 details an inventory item categorization and product-ingredient mapping method 340 or engine that converts heterogeneous product records into standardized pantry entities usable across the system.

[0176] A raw product input 167 - for example, " Organic Whole Milk (1 gallon), Brand:Horizon" - is received from upstream commerce flows, including selected product records (e.g., product selection 165 and cart / checkout flows described with reference to FIGS. 8 and 20) or other acquisition sources. Because retailer titles frequently contain branding and descriptive adjectives that do not align with recipe ingredient terminology, the raw product input 167 is first processed by a product name parser 168. The product name parser 168 removes brand names, removes or de-prioritizes nonessential adjectives, and extracts a base category term. In the non-limiting example shown, theAtty Docket No. 2523.100.01USparser produces the normalized base term "milk / ' which is more likely to match recipe and nutrition terminology used elsewhere in the platform.

[0177] In parallel, the system 300 or engine 340 may resolve quantity representations into a single computational basis through a unit standardization module 169. The unit standardization module 169 converts a purchased quantity (e.g., "1 gallon") into a standardized unit (e.g., grams) using conversion rules and, where applicable, density profiles or product metadata. This is critical because pantry inventory must be comparable across disparate purchase units (gallon, bottle, bag, "2 lb," "1 dozen," etc.) and also comparable to recipe requirements (often expressed in milliliters, tablespoons, cups, or grams).

[0178] To support ingredient matching beyond direct string equality, the system applies an equivalence engine 170, which maps semantically related products and ingredient descriptors to a base ingredient class. The equivalence engine 170 may perform synonym mapping (e.g., "basmati rice" - "rice"), substitution-aware mapping (e.g., "almond milk" -> "milk" for certain recipes, or to a dairy-free "milk alternative" class depending on constraint rules), and lexical normalization (e.g., "granny smith" -> "apple"). The output of the equivalence engine 170 is a base mapping that enables consistent cross-feature references and prevents fragmentation of pantry items into non-matching labels.

[0179] Once a product is normalized and standardized, it is evaluated against recipe requirements via recipe ingredient lookup 171, which expresses recipe needs using the same base terms used throughout the nutrition and meal planning subsystems (e.g,, the dish decomposition engine 118 and ingredient list outputs described with reference to FIG. 14, and the ingredient requirements 159 described with reference to FIG. 20). In an illustrative example, a recipe may require "milk (250 ml)," and the system may query for the category "milk" to determine whether the user's pantry contains a sufficient amount of a milk-category item, regardless of brand or packaging format.

[0180] A category mapper 172 then generates a standardized pantry entry for storage and downstream computations. The category mapper 172 produces, for eachAtty Docket No. 2523.100.01USstandardized entry, a category label (e.g., "milk"), a standardized quantity value (e.g., grams), an associated unit representation, and a canonical search term or identifier. This standardized entry is the internal form used by multiple downstream subsystems, ensuring that pantry records remain interoperable with nutrition computation, meal planning, and procurement.

[0181] The standardized entries are then consolidated by category aggregation 173, which groups pantry holdings by base category and maintains a total available quantity forthat category. Category aggregation 173 may also preserve item-level detail (e.g., whole milk vs. 2% milk) while still computing category totals for recipe feasibility checks. In the illustrated example, the system aggregates "milk" items and may compute a combined total quantity across multiple milk variants. This aggregation supports both coarse feasibility ("do we have enough milk?") and fine-grained selection ("use 2% milk first because it expires sooner"), without requiring recipe engines to understand retailer packaging details.

[0182] Finally, the aggregated inventory state is persisted in a unified pantry database 174, which is designated as a canonical inventory reference for multiple core features. As shown, the unified pantry database 174 is referenced by downstream systems including meal planning (e.g., pantry inventory system 157 and generated meal plan feasibility described with reference to FIG. 19), food logging and calorie tracking (e.g., logged meal processing described with reference to FIG. 17, including pantry deductions through pantry management module 025), and recipe understanding and nutrition computation (e.g., ingredient decomposition and nutrient computation described with reference to FIGS. 14-15). The unified pantry database 174 may also be consumed by shopping flows to generate replenishment lists or to compute net missing quantities prior to procurement (e.g., inventory check module 160 described with reference to FIG.20).

[0183] Closing the pantry-loop described with reference to FIGS. 17, 20, and 21, FIG. 22 shows how pantry state is (i) acquired from multiple sources, (ii) depleted in real time from logged consumption, and (iii) used to trigger smart replenishment through the Al3.3Atty Docket No, 2523.100.01USshopping workflows previously described. That is, FIG. 22 illustrates a method of multisource pantry acquisition, real-time ingredient depletion, and smart replenishment 342.

[0184] New inventory may enter the system through manual item addition 175 (e.g., user-entered pantry updates) and through auto-add post-checkout 176, in which successfully purchased items are programmatically added to the pantry after completion of an Al shopping or checkout flow (as described with reference to cart and procurement flows in FIGS. 8 and 20). Both sources are ingested by an acquisition hub 177, which normalizes incoming inventory by parsing quantities, converting units into standardized units (e.g., grams), mapping entries into canonical ingredient categories, and applying quantity updates to existing stock records (e.g., incrementing stock by "+ quantity"). This acquisition hub 177 is consistent with the normalization and categorization logic described for product-to-ingredient mapping and unified pantry storage in FIG. 21.

[0185] Normalized inventory is stored in a pantry database 178, which maintains current quantities and supports live tracking of available stock at the standardized category level (e.g., milk, eggs, rice). The pantry database 178 functions as the real-time inventory state referenced across meal planning and consumption workflows.

[0186] When meals are recorded through meal logging 179, the system infers ingredients used, determines quantity consumed, and incorporates portion sizing- consistent with the calorie tracking and logging flow described with reference to FIG. 17 and the ingredient decomposition and scaling flows described with reference to FIGS.14-15. The inferred ingredient usage is provided to a depletion engine 180, which converts quantities into the standardized unit basis, scales consumption according to servings or portion size, and deducts the computed amounts from the pantry database 178 (e.g., quantity"). This depletion mechanism operationalizes the pantry-deduction behavior previously noted in connection with logging and inventory reconciliation.

[0187] As pantry quantities change over time, a low-stock detection module 181 monitors category-level thresholds (e.g., absolute remaining quantity or remaining percentage) and triggers alerts when tracked items fall below configured limits. UponAtty Docket No, 2523.100.01USdetecting low stock, the system may invoke smart replenishment 182 using the Al shopping engine, including generating user alerts, adding replenishment items to a cart, or initiating an automated reorder workflow, consistent with the shopping selection and cart insertion mechanisms described with reference to FIGS. 6-9 and the multi-retailer discovery and optimization flows described with reference to FIGS. 7 and 20.

[0188] FIG. 23 illustrates a method 344 of inventory-aware meal recommendations with recipe feasibility analysis, or how recipe feasibility analysis is performed and how results are routed to the meal planner and Al shopping workflows. The system 300 may execute the method 344.

[0189] A set of candidate recipes 183, obtained from a recipe database, is evaluated against the user's current pantry inventory 184, which reflects normalized and aggregated ingredient quantities as maintained by the unified pantry system described with reference to FIG. 21. These inputs are provided to a recipe feasibility engine 185, which operates as part of the meal plan solver (e.g., solver 155 described with reference to FIG. 19).

[0190] For each candidate recipe, the recipe feasibility engine 185 parses the ingredient list, queries corresponding pantry categories, converts required quantities into standardized units, and computes an availability percentage indicating how much of the recipe can be prepared using existing inventory. This analysis produces three feasibility classes.

[0191] Recipes classified as fully available 186 are those for which all required ingredients are present in sufficient quantity. These recipes are forwarded to the meal planner 189, where they are prioritized for recommendation based on feasibility, nutritional fit, and preference scoring. In the illustrated example, pasta and omelet are identified as fully available and ranked accordingly.

[0192] Recipes classified as partially available 187 are those for which a majority of ingredients are present, but one or more components are missing or insufficient. These recipes remain eligible for recommendation but are accompanied by identified gaps. Missing ingredients associated with partially available recipes are forwarded to theAtty Docket No, 2523.100.01USshopping cart workflow 190, enabling automatic addition of required items while preserving the selected recipe in the meal plan.

[0193] Recipes classified as requiring shopping 188 lack all or most required ingredients.These recipes are not immediately prioritized for meal planning but instead trigger a procurement pathway, in which all required ingredients are routed to the Al shopping workflow for optional or automatic cart generation, consistent with the shopping integration described with reference to FIGS. 20 and 22.

[0194] Building upon the inventory acquisition, depletion, replenishment, and planning flows described with reference to FIGS. 21-23, FIG. 24 illustrates a complete pantry management method 346 or system which may be included in the system 300, such as an end-to-end intelligent lifecycle of the pantry management system and its interaction with meal planning, logging, and Al-driven shopping.

[0195] The lifecycle begins with item acquisition 191, in which pantry items are introduced through manual user entry or automatically following Al shopping orders. Acquired items are normalized and stored 192, with quantities updated and persisted in a core pantry database 193, which maintains real-time inventory state, including stock levels, categories, expiry data, and usage patterns.

[0196] Using this inventory state, the system recommends meals 194 based on feasibility and availability, after which users cook and log meals 195, recording ingredient consumption. Logged consumption drives stock depletion 196, deducting used quantities from the pantry database.

[0197] As inventory levels change, low-stock detection 197 monitors thresholds and expiration conditions. When replenishment is required, the system initiates refill operations 198 through the Al shopping engine, generating carts or automated reorders as previously described.

[0198] The system 300 may optimize and learn 199 by analyzing user behavior and consumption patterns to improve future meal recommendations, replenishment timing, and inventory predictions, thereby completing a continuous closed-loop lifecycle.Atty Docket No. 2523.100.01US

[0199] Turning now to FIG. 25, a system 201 for facilitating purchases is described. The system 201 may be incorporated in the system 300 previously described herein and / or use any of the systems, engines, or methods previously described herein. In some embodiments, the system 201 has a user interface 200, one or more processors 202, and a non-transitory computer-readable memory 203 storing instructions that, when executed by the one or more processors 202, cause the system 201 to execute a method. The method may be any of the methods or steps previously described herein, or the method 350 illustrated in FIG. 26. The system 201 may include a data store 204 one or more logical storage structures implemented in volatile or non-volatile memory, such as memory 203, including databases, tables, files, objects, or combinations thereof, that store data and are accessible to software instructions executed by one or more processors 202.

[0200] With brief reference to FIG. 26, the method 350 may be a method of facilitating purchases and may include receiving 208, via the user interface, a shopping list input from a user in at least one of multiple modalities, the multiple modalities selected from the following: an image containing text, spoken audio, or free-form text.

[0201] The method 350 may include processing 209 the shopping list input with an artificial intelligence engine, wherein the processing the shopping list input includes: determining 210 at least one of: (a) at least a portion of the shopping list input is an image containing text; (b) at least a portion of the shopping list input is spoken audio; or (c) at least a portion of the shopping list input is free-form text.

[0202] The method 350 may include, responsive to the determining, identifying 211 a plurality of desired products, and determining 212 an associated quantity of each of the plurality of desired products.

[0203] The method 350 may include querying 213 a plurality of distinct retailer data sources to obtain product data for each of the plurality of desired products, wherein the querying is performed in parallel via API integrations with each of the plurality of distinct retailer data sources.Atty Docket No. 2523.100.01US

[0204] The method 350 may include aggregating and normalizing 214 the product data retrieved from the plurality of distinct retailer data sources into a unified data set of a plurality of candidate products for the plurality of desired products, the unified data set including at least one of price information, product description, or availability.

[0205] The method 350 may include evaluating 215 the plurality of candidate products using a recommendation algorithm, the recommendation algorithm configured to apply multiple selection criteria, the criteria comprising price, product quality indicator, customer ratings, and at least one user-specific preference or constraint.

[0206] The method 350 may include, responsive to the evaluating, selecting 216 a plurality of recommended products.

[0207] The method 350 may include adding 217 the plurality of recommended products to a virtual shopping cart associated with the user.

[0208] The method 350 may include receiving 218 a checkout request from the user.

[0209] The method 350 may include, responsive to the receiving the checkout request, initiating purchase 219 of the plurality of recommended products, wherein the plurality of recommended products originate from a plurality of retailers, and the initiating purchase includes coordinating orders to the plurality of retailers.

[0210] Returning to FIG. 25, the system 201 may include an image processing and optical character recognition (OCR) system (see e.g. FIG. 4) or be adapted to process image inputs using optical character recognition and may include an associated Al model to interpret handwritten or printed text in the image containing text.

[0211] The system 201 may include a voice input parsing system (see e.g. FIG. 5) or be adapted to process audio inputs by converting spoken language into text.

[0212] The system 201 may have a natural language understanding system (see FIGS. 2, 3, 5) or be adapted to parse text from either the speech recognition system or direct text inputs, the natural language understanding system being implemented using a trained language model to extract item names, quantities, and descriptors from user phrases.Atty Docket No. 2523.100.01US

[0213] The system 201 may have a plurality of API adapter components 205, 206, 207, each API adapter component corresponding to one of the plurality of retailers and configured to translate standardized product queries from the system into a format required by an API of a respective one of the plurality of retailers; and wherein: the search integration module further comprises an orchestrator that invokes multiple API adapter components in parallel and aggregates their responses.

[0214] Each of the various elements disclosed herein may be achieved in a variety of manners. This disclosure should be understood to encompass each such variation, be it a variation of an embodiment of any apparatus embodiment, a method or process embodiment, or even merely a variation of any element of these. Particularly, it should be understood the words for each element may be expressed by equivalent apparatus terms or method terms— even if only the function or result is the same. Such equivalent, broader, or even more generic terms should be considered to be encompassed in the description of each element or action. Such terms can be substituted where desired to make explicit the implicitly broad coverage to which this invention is entitled.

[0215] As but one example, it should be understood that all action may be expressed as a means for taking that action or as an element which causes that action. Similarly, each physical element disclosed should be understood to encompass a disclosure of the action which that physical element facilitates. Regarding this last aspect, the disclosure of a "attachment mechanism" should be understood to encompass disclosure of the act of "attaching" —whether explicitly discussed or not— and, conversely, were there only disclosure of the act of "attaching", such a disclosure should be understood to encompass disclosure of a "attaching mechanism". Such changes and alternative terms are to be understood to be explicitly included in the description.

[0216] Moreover, the claims shall be construed such that a claim that recites "at least one of A, B, or C" shall read on a device that requires " A" only. The claim shall also read on a device that requires " B" only. The claim shall also read on a device that requires " C" only. The claim shall also read on a device that requires " A+B". The claim shall also read on a device that requires " A+B+C", and so forth.Atty Docket No, 2523.100.01US

[0217] Those skilled in the art can readily recognize that numerous variations and substitutions may be made in the invention, its use and its configuration to achieve substantially the same results as achieved by the embodiments described herein.

[0218] Accordingly, there is no intention to limit the invention to the disclosed exemplary forms. Many variations, modifications and alternative constructions fall within the scope and spirit of the invention as expressed in the claims,

Claims

Atty Docket No. 2523.100.01USCLAIMS1. A computer-implemented method for facilitating purchases, the method comprising:receiving, via a user interface, a shopping list input from a user in at least one of multiple modalities, the multiple modalities selected from the following: an image containing text, spoken audio, or free-form text;processing the shopping list input with an artificial intelligence engine, wherein the processing the shopping list input includes:determining at least one of: (a) at least a portion of the shopping list input is an image containing text; (b) at least a portion of the shopping list input is spoken audio; or (c) at least a portion of the shopping list input is free-form text;responsive to the determining, identifying a plurality of desired products; determining an associated quantity of each of the plurality of desired products; querying a plurality of distinct retailer data sources to obtain product data for each of the plurality of desired products, wherein the querying is performed in parallel via API integrations with each of the plurality of distinct retailer data sources;aggregating and normalizing the product data retrieved from the plurality of distinct retailer data sources into a unified data set of a plurality of candidate products for the plurality of desired products, the unified data set including at least one of price information, product description, or availability;evaluating the plurality of candidate products using a recommendation algorithm, the recommendation algorithm configured to apply multiple selection criteria, the criteria comprising price, product quality indicator, customer ratings, and at least one user-specific preference or constraint;responsive to the evaluating, selecting a plurality of recommended products; adding the plurality of recommended products to a virtual shopping cart associated with the user;receiving a checkout request from the user; andAtty Docket No. 2523.100.01USresponsive to the receiving the checkout request, initiating purchase of the plurality of recommended products, wherein the plurality of recommended products originate from a plurality of retailers, and the initiating purchase includes coordinating orders to the plurality of retailers.

2. The method of claim 1, wherein,the shopping list input comprises an image containing text, the image depicting a handwritten list, printed list, or product labels; and whereinthe processing the shopping list further includes:(a) encoding the image into an encoded image;(b) transmitting the encoded image to a vision-based Al model configured to perform optical character recognition and interpret the encoded image; (c) receiving, from the vision-based Al model, text extracted from the encoded image; and(d) using a language model, parsing the extracted text into the plurality of desired products, the parsing including correcting OCR errors and recognizing item names and quantities from a context of the user's input.

3. The method of claim 1, wherein,the shopping list input comprises spoken audio; andthe processing the shopping list input further comprises:(a) transcribing the spoken audio recording to text using a speech-to-text engine;(b) and analyzing the transcribed text with a natural language processing module to identify item keywords, quantities, and descriptors within the transcribed audio recording.Atty Docket No, 2523.100.01US4. The method of claim 1, wherein,the shopping list input comprises free-form text entered by the user; andthe processing the shopping list input further comprises:(a) performing text normalization by lowercasing and removing extraneous characters;(b) tokenizing the free-form text to separate individual items or phrases; and (c) applying a natural language parser or an Al language model to interpret the free-form text to extract at least one of the plurality of desired products and any modifiers or preferences identified in the free-text.

5. The method of claim 1, wherein,the querying the plurality of distinct retailer data sources comprises:(a) sending search queries for each one of the plurality of desired products to at least three different retailer APIs or databases, wherein at least one of the plurality of distinct retailer data sources is a third-party aggregator that provides results from multiple stores via a single interface;(b) authenticating with each one of the plurality of distinct retailer data sources, if required; and(c) maintaining rate limits and query formats that comply with rate limits and query formats of respective ones of the plurality of distinct retailer data sources.

6. The method of claim 1, further comprising:caching product search results, wherein the caching includes storing normalized results keyed by search parameters; andinvalidating or refreshing cached data after a predetermined period or upon detecting data updates.

7. The method of claim 1, wherein,Atty Docket No. 2523.100.01USthe evaluating the plurality of candidate products further comprises, for each one of the plurality of candidate products:(a) analyzing price by comparing absolute prices associated with each one of the plurality of distinct retailer data sources and computing a unit price or value per standardized quantity for each one of the plurality of candidate products; (b) assessing product quality and suitability by checking attributes including brand reputation, presence of certain certifications or labels, and compliance with the user's dietary or ethical preferences;(c) evaluating customer satisfaction indicators by considering average review ratings, number of reviews, and recency of reviews; and(d) assigning a score or preference ranking to each one of the plurality of candidate products based on a weighted combination of the price, product quality, and customer satisfaction of the each one of the plurality of candidate products,8. The method of claim 1, wherein,the at least one user-specific preference or constraint includes one or more of: a dietary requirement, an ingredient exclusion, a budget limit, a preferred brand, a preferred store, or sustainability criteria; and whereinthe method includes:(a) boosting items that match or closely match user-specific preferences; and (b) excluding items that do not meet user-specific constraints and boosting or prioritizing candidates that better match the user's stated preferences.

9. The method of claim 1, further comprising:utilizing a machine learning model or Al agent to perform the evaluating the plurality of candidate products, wherein the machine learning model or Al agent receives as input a representation of the plurality of candidate products and the at least one user-specific preference or constraint and outputs a recommended choice alongAtty Docket No. 2523.100.01USwith an explanation, the explanation identifying key factors that influenced the recommended choice.

10. The method of claim 1, wherein the virtual shopping cart is maintained across user sessions by storing cart data on a server associated with a session identifier for anonymous users and with a user account for logged-in users, the method further comprising:detecting when an anonymous user becomes authenticated during the process; andmerging the contents of the cart associated with the anonymous session with any existing cart associated with the user account by combining item quantities for duplicate items and retaining all unique items, thereby preventing loss of selections made prior to login.

11. The method of claim 1, further comprising presenting the recommended products to the user for approval or modification before checkout, including displaying an indication of why each one of the plurality of recommended products was chosen.Atty Docket No. 2523.100.01US12. A system for facilitating purchases, the system comprising:a user interface;one or more processors; anda non-transitory computer-readable memory storing instructions that, when executed by the one or more processors, cause the system to execute a method, the method including:receiving, via the user interface, a shopping list input from a user in at least one of multiple modalities, the multiple modalities selected from the following: an image containing text, spoken audio, or free-form text;processing the shopping list input with an artificial intelligence engine, wherein the processing the shopping list input includes:determining at least one of: (a) at least a portion of the shopping list input is an image containing text; (b) at least a portion of the shopping list input is spoken audio; or (c) at least a portion of the shopping list input is free-form text;responsive to the determining, identifying a plurality of desired products; determining an associated quantity of each of the plurality of desired products; querying a plurality of distinct retailer data sources to obtain product data for each of the plurality of desired products, wherein the querying is performed in parallel via API integrations with each of the plurality of distinct retailer data sources;aggregating and normalizing the product data retrieved from the plurality of distinct retailer data sources into a unified data set of a plurality of candidate products for the plurality of desired products, the unified data set including at least one of price information, product description, or availability;evaluating the plurality of candidate products using a recommendation algorithm, the recommendation algorithm configured to apply multiple selection criteria, the criteria comprising price, product quality indicator, customer ratings, and at least one user-specific preference or constraint;responsive to the evaluating, selecting a plurality of recommended products;Atty Docket No. 2523.100.01USadding the plurality of recommended products to a virtual shopping cart associated with the user;receiving a checkout request from the user; andresponsive to the receiving the checkout request, initiating purchase of the plurality of recommended products, wherein the plurality of recommended products originate from a plurality of retailers, and the initiating purchase includes coordinating orders to the plurality of retailers.

13. The system of claim 12, wherein the method further comprises:processing image inputs using optical character recognition and an associated Al engine to interpret handwritten or printed text in the image containing text;processing audio inputs by converting spoken language into text;parsing text from either the processed audio inputs or direct text inputs; and using a trained language model to extract item names, quantities, and descriptors from user phrases.

14. The system of claim 12, wherein:the system is configured to engage with a plurality of retailers; andthe system comprises a plurality of API adapter components, each API adapter component corresponding to one of the plurality of retailers and configured to translate standardized product queries from the system into a format required by an API of a respective one of the plurality of retailers; and wherein:the system is configured to query the plurality of retailers parallel and aggregate their responses.

15. The system of claim 12, comprising a recommendation engine having a preference filtering component that excludes or reprioritizes products based on user-specified criteria before final evaluation, and a scoring component that assigns scores to candidate products based on a weighted combination of factors comprising at least cost,Atty Docket No. 2523.100.01USvalue, consumer rating, and product attribute quality, the recommendation engine selecting the product with the best score or otherwise highest rank as the recommendation for each item.

16. The system of claim 12, comprising a cart management and order linking system configured to maintain cart state in a server-side data store associated with a session identifier for unauthenticated users and to associate cart state with a user profile for authenticated users, and wherein the cart management and order linking system includes logic to merge an unauthenticated session's cart with an authenticated user's cart when a user logs in during a shopping session, such that item entries from both carts are combined without duplication except for quantity updates.

17. The system of claim 16, further comprising a nutrition analysis system configured to retrieve or compute nutritional information for the plurality of recommended products and to factor nutritional suitability into the recommendation criteria or to present nutritional feedback to the user alongside the plurality of recommended products.

18. The system of claim 12, further configured to:accept a single payment from the user for the plurality of recommended products in the virtual shopping cart;after the accepting the single payment programmatically executing multiple purchase orders with a plurality of retailers corresponding to the plurality of recommended products; andprovide the user with unified order tracking information.

Images