Prosecution Insights
Last updated: July 17, 2026
Application No. 19/171,326

METHOD AND SYSTEM FOR PRODUCT RECOMMENDATION BASED ON EXAMPLE PRODUCTS AND TEXT INPUT

Non-Final OA §101§103
Filed
Apr 06, 2025
Priority
Apr 08, 2024 — RE 10-2024-0047357
Examiner
UBALE, GAUTAM
Art Unit
Tech Center
Assignee
LG Management Development Institute Co. Ltd.
OA Round
1 (Non-Final)
54%
Grant Probability
Moderate
1-2
OA Rounds
2y 5m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 54% of resolved cases
54%
Career Allowance Rate
139 granted / 257 resolved
-5.9% vs TC avg
Strong +48% interview lift
Without
With
+47.5%
Interview Lift
resolved cases with interview
Typical timeline
3y 9m
Avg Prosecution
23 currently pending
Career history
278
Total Applications
across all art units

Statute-Specific Performance

§101
19.5%
-20.5% vs TC avg
§103
68.3%
+28.3% vs TC avg
§102
6.9%
-33.1% vs TC avg
§112
2.4%
-37.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 257 resolved cases

Office Action

§101 §103
DETAILED ACTION This action is in response to a filing filed claims on August 6th, 2025. Claims 1-15 is/are have been examined in this application. Priority This application claims priority from and the benefit of Korean Patent Application No. 10-2024-0047357, filed on April 8, 2024, which is hereby incorporated by reference for all purposes as if fully set forth herein. Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. an abstract idea) without significantly more. Step 1: Claims 1-13 is/are drawn to method (i.e., a process), claim 14 is drawn to system (i.e., a manufacture), and Claims 15 is/are drawn to computing device (i.e., a manufacture). As such, claims 24-43 is/are drawn to one of the statutory categories of invention (Step 1: YES). Step 2A - Prong One: In prong one of step 2A, the claim(s) is/are analyzed to evaluate whether it/they recite(s) a judicial exception. Representative Claim 1: A method for product recommendation based on example products and text input configured to be performed with a computing system, the computing system comprising a memory and a processor configured to identify a current intention of a user and provide recommendation product information, the method comprising the steps of: inputting a text about at least one example product and current needs of the user; deriving an intention vector of the user based on the at least one example product; deriving intention information about the text using a Large Language Model (LLM); deriving an average intention vector based on the intention vector and the intention information; deriving one or more sampling intention vectors based on a probability distribution expressing the current intention of the user and the average intention vector, and deriving a product corresponding to the sampling intention vector, the product corresponding to the sampling intention vector comprising a tangible product with value and an intangible product. (Examiner notes: The underlined claim terms above are interpreted as additional elements beyond the abstract idea and are further analyzed under Step 2A - Prong Two) Under their broadest reasonable interpretation, the claim recites the abstract idea of receiving information about at least one example product and text describing current user needs, deriving user-intention information from that information, generating vector representations of the user’s intention, and deriving a product recommendation corresponding to the user’s inferred intention. This is an abstract idea because it amounts to collecting information about a user’s interests or needs, analyzing that information to infer the user’s preference or intent, and selecting/recommending a product based on that inferred preference or intent. Such activity is a commercial interaction and marketing/sales activity, which falls within certain methods of organizing human activity. It also includes mental processes because the steps of evaluating a user’s needs, comparing those needs to product information, and selecting a product recommendation can be performed conceptually by a human, with the claimed computer merely automating that evaluation. Further, the claim 6 recites deriving an intention vector based on the example product, deriving an average intention vector, deriving sampling intention vectors based on a probability distribution, and deriving a product corresponding to the sampling intention vector. These steps amount to analyzing a sample or example product to infer a user’s likely interest and recommending a related product. This is an abstract idea because it is the commercial practice of matching and recommending products based on perceived user preference, implemented using mathematical/vector representations. Additionally, claim 11 recites inputting text about current needs, deriving intention information about the text using a Large Language Model, deriving an average intention vector, deriving sampling intention vectors, and deriving a product recommendation. These steps amount to analyzing natural-language information from a user to infer the user’s intent and recommending a product that matches that inferred intent. The use of an LLM does not change the character of the claim because the LLM is used as a tool to perform the abstract analysis of user text and intent (i.e., recite a process, that, under their broadest reasonable interpretation, covers performance of the limitation(s) in the commercial interactions (including agreements in the form of contracts; advertising, marketing or sales activities or behaviors; business relationship), then it falls within the “certain methods of organizing human activity”. The claim also recites, at a high level of evaluating user needs or preferences and selecting/recommending products. But for the recitation of generic computer components, these steps correspond to concepts that may be performed as observations, evaluations, judgments, or instructions by a person, such as observing that a user interaction. Accordingly, the claim also recites an abstract idea within the “Mental Processes” grouping. Dependent claims 2 and 7 further narrow the abstract idea by reciting that the at least one example product is expressed as an index, that k feature vectors are sampled from a probability distribution regarding features of the example product, that the feature vector is encoded into the intention vector, and that k is an integer greater than or equal to 1. These limitations further describe representing product information in indexed/vector form and using mathematical sampling from a probability distribution to model or infer a user’s product intention. Such limitations continue to fall within the abstract idea because they merely specify mathematical concepts, including vectors, indices, probability distributions, and sampling, used as part of analyzing user/product information to recommend products. Dependent claims 3 and 8 further narrow the abstract idea by reciting that a density of the intention vector is derived using MPMD, defined as Max Probability position of Mixed Distributions, and that the average intention vector is derived based on the density of the intention vector. These limitations further describe using probability-density information and mixed-distribution calculations to determine or refine a mathematical representation of user intention. Such limitations continue to fall within mathematical concepts because they recite probability distributions, density, maximum-probability positions, and averaging of intention vectors. Under the broadest reasonable interpretation, these limitations merely specify a mathematical technique for modeling the user’s inferred preference or intent and do not alter the abstract character of the claimed product-recommendation concept. Dependent claims 3 and 8 further narrow the abstract idea by reciting that a density of the intention vector is derived using MPMD, defined as Max Probability position of Mixed Distributions, and that the average intention vector is derived based on the density of the intention vector. These limitations further describe using probability-density information and mixed-distribution calculations to determine or refine a mathematical representation of user intention. Such limitations continue to fall within mathematical concepts because they recite probability distributions, density, maximum-probability positions, and averaging of intention vectors. Under the broadest reasonable interpretation, these limitations merely specify a mathematical technique for modeling the user’s inferred preference or intent and do not alter the abstract character of the claimed product-recommendation concept. Accordingly, dependent claims 2–5, 7–10, and 12–13 merely add further details to the abstract idea of analyzing user/product information and inferred user intent to recommend a product. Such limitations continue to fall within certain methods of organizing human activity, including commercial interactions, marketing, sales activity, and product recommendation. Independent claim(s) 14-15 recite/describe nearly identical steps (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and this/these claim(s) is/are therefore determined to recite an abstract idea under the same analysis. As such, the Examiner concludes that claim 24 recites an abstract idea (Step 2A – Prong One: YES). Step 2A - Prong Two: In prong two of step 2A, an evaluation is made whether a claim recites any additional element, or combination of additional elements, that integrate the exception into a practical application of that exception. An “addition element” is an element that is recited in the claim in addition to (beyond) the judicial exception (i.e., an element/limitation that sets forth an abstract idea is not an additional element). The phrase “integration into a practical application” is defined as requiring an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that it is more than a drafting effort designed to monopolize the exception. The requirement to execute the claimed steps/functions using computing system, a memory and a processor, a Large Language Model (LLM), etc. (Claims 1, 6, 11, and 14-15) is/are equivalent to adding the words “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer. Similarly, the limitations of applying computing system, a memory and a processor, a Large Language Model (LLM), etc. (Independent Claim(s) 1, 6, 11, and 14-15, and dependent claims 2-5, 7-10, and 12-13) are recited at a high level of generality and amount to no more than mere instructions to apply the exception using generic computer components. This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(f)). Further, the additional limitations beyond the abstract idea identified above, serves merely to generally link the use of the judicial exception to a particular technological environment or field of use. Specifically, it/they serve(s) to limit the application of the abstract idea to computerized environments (e.g., identify, provide, derive, recommend, etc. steps performed by computing system, a memory and a processor, a Large Language Model (LLM), etc.). This reasoning was demonstrated in Intellectual Ventures I LLC v. Capital One Bank (Fed. Cir. 2015), where the court determined "an abstract idea does not become nonabstract by limiting the invention to a particular field of use or technological environment, such as the Internet [or] a computer"). This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application (see MPEP 2106.05(h)). The recited additional element(s) of inputting text about at least one example product and/or current needs of the user, deriving an intention vector, deriving intention information about the text using a Large Language Model (LLM), deriving an average intention vector, deriving one or more sampling intention vectors based on a probability distribution, deriving a product corresponding to the sampling intention vector, and providing recommendation product information (Claim(s) 1, 6, 11, and 14-15), additionally and/or alternatively simply append insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea). The recited additional element(s) do not meaningfully limit the claim because inputting or receiving user/product information constitutes pre-solution data gathering; deriving vectors, intention information, average vectors, probability-based sampling vectors, and recommendation information constitutes intermediate data analysis and mathematical processing; and deriving, providing, displaying, or outputting a recommended product constitutes post-solution presentation of the result of the abstract idea. These limitations are performed before, during, or after the abstract idea of analyzing user needs, user intent, product information, and/or user history to recommend a product, and would be required in any computer implementation of such product-recommendation activity. Further the dependent claim limitations likewise merely append insignificant extra-solution activity. The recited steps of expressing an example product as an index, sampling k feature vectors, encoding feature vectors into an intention vector, deriving density using MPMD, deriving an average intention vector based on density, deriving an associated product vector, filtering the associated product vector, converting a recommendation product vector into a recommendation product index, displaying the product corresponding to the recommendation product index, generating user preference information based on past purchase history, product inquiry history, and search history, and filtering recommendation product information based on the user preference information (claims 2-5, 7-10, and 12-13) merely describe collecting, organizing, converting, filtering, and presenting information used in the product-recommendation process. This/these limitation(s) do/does not impose any meaningful limits on practicing the abstract idea, and therefore do/does not integrate the abstract idea into a practical application. (See MPEP 2106.05(g)). Dependent claim 2-5, 7-10, and 12-13 fail to include any additional elements. In other words, each of the limitations/elements recited in respective dependent claims is/are further part of the abstract idea as identified by the Examiner for each respective dependent claim (i.e. they are part of the abstract idea recited in each respective claim). The Examiner has therefore determined that the additional elements, or combination of additional elements, do not integrate the abstract idea into a practical application. Accordingly, the claim(s) is/are directed to an abstract idea (Step 2A – Prong two: NO). Step 2B: In step 2B, the claims are analyzed to determine whether any additional element, or combination of additional elements, is/are sufficient to ensure that the claims amount to significantly more than the judicial exception. This analysis is also termed a search for an "inventive concept." An "inventive concept" is furnished by an element or combination of elements that is recited in the claim in addition to (beyond) the judicial exception, and is sufficient to ensure that the claim as a whole amounts to significantly more than the judicial exception itself. Alice Corp., 134 S. Ct. at 2355, 110 USPQ2d at 1981 (citing Mayo, 566 U.S. at 72-73, 101 USPQ2d at 1966). As discussed above in “Step 2A – Prong 2”, the identified additional elements in independent claim(s) 1, 6, 11, and 14-15, and dependent claims 2-5, 7-10, and 12-13 are equivalent to adding the words “apply it” on a generic computer, and/or generally link the use of the judicial exception to a particular technological environment or field of use. Therefore, the claims as a whole do not amount to significantly more than the judicial exception itself. The recited additional element(s) of inputting text about at least one example product and/or current needs of the user, deriving an intention vector, deriving intention information about the text using a Large Language Model (LLM), deriving an average intention vector, deriving one or more sampling intention vectors based on a probability distribution, deriving a product corresponding to the sampling intention vector, and providing recommendation product information (Claim(s) 1, 6, 11, and 14-15), additionally and/or alternatively simply append insignificant extra-solution activity to the judicial exception, (e.g., mere pre-solution activity, such as data gathering, in conjunction with an abstract idea) that is similar to “Receiving or transmitting data over a network, e.g., using the Internet to gather data”, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information), “Storing and retrieving information in memory”, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; “Presenting offers to potential customers and gathering statistics generated based on the testing about how potential customers responded to the offers; the statistics are then used to calculate an optimized price”, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93, buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), is a well-understood, routine, and conventional function when it is claimed in a merely generic manner (as it is here) (See MPEP 2106.05(d) (II)). This conclusion is based on a factual determination. Applicant’s own disclosure at paragraph [0073] acknowledges that “model trainer 160 may be implemented as hardware, firmware and/or software, which controls a general-purpose processor. In one implementation, the model trainer 160 contains a program file stored in a storage device, which may be loaded into the memory 152 and executed by one or more processors 151 ...” The applicant’s disclosure [0046], discloses the method for product recommendation based on example products and text input according to an embodiment of the present invention may be locally implemented and provided by the user computing device 110, may be implemented and provided in the form of a web service by the server computing system 130 communicating with the user computing device 110, or may be implemented and provided by the user computing device 110 and the server computing system 130 in conjunction with each other (i.e. conventional nature of receiving and transmitting data/messages over a network). This additional element therefore do not ensure the claim amounts to significantly more than the abstract idea. Viewing the additional limitations in combination also shows that they fail to ensure the claims amount to significantly more than the abstract idea. When considered as an ordered combination, the additional components of the claims add nothing that is not already present when considered separately, and thus simply append the abstract idea with words equivalent to “apply it” on a generic computer and/or mere instructions to implement the abstract idea on a generic computer or/and append the abstract idea with insignificant extra solution activity associated with the implementation of the judicial exception, (e.g., mere data gathering, post-solution activity) and/or simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception. The dependent claims 2-5, 7-10, and 12-13 fail to provide an inventive concept sufficient to transform the abstract idea into patent-eligible subject matter. The dependent claims merely add further details for collecting, representing, mathematically analyzing, filtering, and presenting product-recommendation information based on example products, user intent, and user preference history. Claims 2 and 7 recite expressing the at least one example product as an index, sampling k feature vectors from a probability distribution regarding features of the example product, encoding the feature vector into the intention vector, and specifying that k is an integer greater than or equal to 1. These limitations merely use generic indexing, vectorization, and probability-based sampling to represent product features and user/product intent. The claims do not recite any improved vector-generation technique, improved sampling algorithm, improved probability-distribution model, or improved computer functionality. Claims 3 and 8 recite deriving a density of the intention vector using MPMD, defined as Max Probability position of Mixed Distributions, and deriving the average intention vector based on the density of the intention vector. These limitations merely specify additional mathematical processing used to model or refine a user-intention representation. The claims do not recite any technical improvement to probability modeling, density estimation, mixed-distribution processing, machine learning, or computer operation. Claims 4, 9, and 12 recite deriving an associated product vector corresponding to the sampling intention vector, filtering the associated product vector to derive a recommendation product vector, converting the recommendation product vector into a recommendation product index, and displaying the product corresponding to the recommendation product index. These limitations merely describe organizing candidate product data, matching or filtering product vectors, converting a recommendation result into an index, and presenting the recommended product. Claims 5, 10, and 13 recite generating user preference information based on past product purchase history, product inquiry history, and search history, and deriving the recommendation product vector by filtering the associated product vector based on the user preference information. These limitations merely collect and use conventional user activity information to personalize or filter a product recommendation. None of these dependent-claim limitations, individually or as an ordered combination, meaningfully limit the abstract idea or provide an inventive concept. The additional limitations merely apply generic computer processing, indexing, mathematical vector operations, probability calculations, filtering, and display of recommendation results to the abstract idea of analyzing user/product information and recommending a product. The dependent claims do not solve a specific technical problem or provide a technical improvement to a computer, database, network, display, LLM, machine-learning model, or recommendation system itself. Accordingly, the additional limitations of dependent claims 2-5, 7-10, and 12-13 do not amount to significantly more than the abstract idea and fail to provide an inventive concept under Step 2B. Because these elements do not solve a specific technical problem or offer a technical improvement over existing systems, they are viewed as merely "applying" the abstract idea on a generic computer, thus failing to provide a practical application that would render the claims patent-eligible, and therefore do not add an inventive concept sufficient to transform the abstract idea into patent-eligible subject matter. When viewed as an ordered combination, the additional elements of claims 2-5, 7-10, and 12-13 merely instruct to implement the abstract idea using generic computer components to collect, store, represent, and display information. The claims do not recite any unconventional arrangement of elements, nor do they effect an improvement to computer functionality or another technical field and therefore fail to integrate the abstract concept into a practical application and it is recited at a high level of generality and does not integrate the judicial exception into a practical application. The Examiner has therefore determined that no additional element, or combination of additional claims elements is/are sufficient to ensure the claim(s) amount to significantly more than the abstract idea identified above (Step 2B: NO). Therefore, claims 1-15 are not eligible subject matter under 35 USC 101. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status: The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under pre-AIA 35 U.S.C. 103(a) are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claims 1-5 and 11-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. US20220245709 (“Ma”) in view of U.S. Pub. 20200311798 (“Forsyth”) in view of NPL “LLM4SBR: A Lightweight and Effective Framework for Integrating Large Language Models in Session-Based Recommendation” (“Qiao”). As per claims 1 and 14-15, Ma discloses, method for product recommendation based on example products and text input configured to be performed with a computing system, the computing system comprising a memory and a processor configured to identify a current intention of a user and provide recommendation product information, the method comprising the steps of (Examiner interprets a product recommendation computing system including a recommender system and web server configured to automatically determine complementary item recommendations. Ma’s system includes a complementary recommender system, web server, communication system, machine-learning system, generating system, ranking system, and personalization system, thereby teaching the claimed computing-system architecture for generating recommendation product information) (“FIG. 3 illustrates a block diagram of a system 300 that can be employed for automatically determining complimentary items recommendations, according to an embodiment. System 300 is merely exemplary and embodiments of the system are not limited to the embodiments presented herein. The system can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, certain elements, modules, or systems of system 300 can perform various procedures, processes, and/or activities. In other embodiments, the procedures, processes, and/or activities can be performed by other suitable elements, modules, or systems of system 300 … system 300 can include a complimentary recommender system 310 and/or a web server 320. Complimentary recommender system 310 and/or web server 320 can each be a computer system, such as computer system 100 (FIG. 1), as described above, and can each be a single computer, a single server, or a cluster or collection of computers or servers, or a cloud of computers or servers. In another embodiment, a single computer system can host two or more of, or all of, complimentary recommender system 310 and/or web server 320. Additional details regarding complimentary recommender system 310 and/or web server 320 are described herein.”) (0029-0031, 0039): deriving an intention vector of the user based on the at least one example product (Examiner interprets Ma’s anchor item or query item as corresponding to the claimed example product. Ma teaches receiving a request for personalized complementary item recommendations for an anchor item and a user. Ma further teaches deriving vector/distribution representations for items and users because each item can be modeled by an item-level Gaussian distribution, and a vector representation of a user is stored in user embedding 410. Ma also teaches ranking candidate items using a mean vector of the Gaussian distribution for the anchor item and a mean vector of the Gaussian distribution for each candidate item) (“FIG. 9, method 805 can include an activity 905 of retrieving respective Gaussian distribution representations of each item of an item pair. In some embodiments, two items added to a basket can be treated as a co-purchase by a user u. In various embodiments, each item in a pair of co-purchase items can be modeled by a Gaussian distribution for an item q. In various embodiments, an item-level embedding using Gaussian Distribution for an item q can be stored in item-level embedding 409 (FIG. 4) … a vector representation of a user u can be stored in user embedding 410 (FIG. 4) and can be expressed as: θ.sub.u” and “method 800 additionally can include an activity 830 of ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item. In several embodiments, the respective item-to-item complementarity metric for the each respective item can be generated using a cosine similarity measurement between a mean vector of the item-level embedding Gaussian distribution for the anchor item and a respective mean vector of the respective item-level embedding Gaussian distribution for the each respective item. In various embodiments, ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity”) (0067-0069 and 0106, 0100); deriving an average intention vector based on the intention vector and the intention information (Examiner interprets the claimed “average intention vector” broadly as a user-personalized vector or metric generated by combining user intent/preference information with product-type vector information. Ma computes personalized product types from user embedding 410 and product-type Gaussian mixture distribution 411, and defines a personalized product type as a weighted average of component mean vectors with personalized component weights) (“after the request is received, method 500 can include an activity 502 of computing personalized product-types from user embedding 410 and product-type Gaussian Mixture distribution 411. Activity 502 can be similar or identical to activity 815 (FIG. 8, described below” and “method 800 further can include an activity 815 of generating personalized product-type metrics for the user based at least in part on a user embedding for the user and product-type embedding Gaussian mixture distributions. In several embodiments, generating personalized recommendations can include computing the personalized product-type for user u. The personalized product-type of c.sup.q can be defined as the weighted average of its component's mean vector μ.sub.c.sub.q.sub.,k with personalized component weights p.sub.c.sub.q.sub.,k”) (0051 and 0101); deriving one or more sampling intention vectors based on a probability distribution expressing the current intention of the user and the average intention vector (Examiner interprets the claimed “sampling intention vectors based on a probability distribution” as encompassed or rendered obvious by Ma’s Gaussian/Gaussian-mixture vector representation and personalized probability-weighted component structure. Ma trains item-level embedding Gaussian distributions, user embeddings, and product-type embedding Gaussian mixture distributions, and personalizes Gaussian-mixture component weights based on user embedding) (“FIG. 8, method 800 optionally can include, before an activity 810 (described below), an activity 805 of training a machine-learning model to learn item-level embedding Gaussian distributions for items, the user embedding, and the product-type embedding Gaussian mixture distributions based on co-purchase item pairs in historic activity data of the user and product-type pairs in an item taxonomy. In some embodiments, training the machine-learning model can include a training pipeline that can perform iterations of looping over item pairs, product-type pairs and users and minimize the loss functions until a stop criteria occurs. In several embodiments, co-purchase item pairs can include a product-type embedding represented by a Gaussian mixture distribution. In various embodiments, activity 805 can be performed as shown in FIG. 9 … FIG. 9, method 805 can include an activity 905 of retrieving respective Gaussian distribution representations of each item of an item pair. In some embodiments, two items added to a basket can be treated as a co-purchase by a user u. In various embodiments, each item in a pair of co-purchase items can be modeled by a Gaussian distribution for an item q. In various embodiments, an item-level embedding using Gaussian Distribution for an item q can be stored in item-level embedding 409 (FIG. 4)” and “method 805 additionally can include an activity 935 of determining a personalized product-type complementarity metric at an individual level between each product type of the product-type pair using the probability product kernel with a personalized component weight. For a given pair of co-purchase product-types c.sup.q, c.sup.r and a user u.sub.2, Equation 1, described above, can be reused to compute the interaction between two components from two different Gaussian Mixture. In various embodiments, in order to machine-learn the multi-topic pattern for the individual user u.sub.2, the component weights in each Gaussian Mixture can be personalized. The components of product-types' Gaussian Mixture can be reused and the personalized component weights by the affinity between a user's embedding and the component location can be computed … personalized component weights can be normalized such that their sum is 1. In some embodiments, reusing Equation 8 with personalized component weights (which can be the same components) can include a personalized interaction E.sub.m(c.sup.q, c.sup.r|u) between two co-purchased product-types”) (0065-0067 and 0090-0094, 010-0103), and deriving a product corresponding to the sampling intention vector (Examiner interprets this as deriving a product corresponding to the vector/distribution-based recommendation by ranking candidate items and selecting top items as personalized complementary item recommendations. Ma teaches selecting a set of top items as personalized complementary item recommendations based on ranking) (0107, 0117-0118), the product corresponding to the sampling intention vector comprising a tangible product with value and an intangible product (Examiner interprets deriving a product corresponding to the vector/distribution-based recommendation by ranking candidate items and selecting top items as personalized complementary item recommendations) (“method 800 further can include an activity 835 of selecting a set of top items as the personalized complementary item recommendations based on the ranking. In several embodiments, activity 835 can involve retaining or saving the top-N items ranked in activity 830 as output. In several embodiments, activities 815, 820, 825, 830, and/or 835 can be performed for each request of each user u and query item q” and “The acts can include receiving a request for personalized complementary item recommendations for an anchor item and a user. The acts also can include generating personalized product-type metrics for the user based at least in part on a user embedding for the user and product-type embedding Gaussian mixture distributions. The acts additionally can include determining top product types based at least in part on personalized product-type complementarity metrics generated using the personalized product-type metrics and cosine similarity measurements. The acts further can include generating a set of first items associated with the top product-types. The acts also can include ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item. The acts further can include selecting a set of top items as the personalized complementary item recommendations based on the ranking …”) (0107 and 0117-0118). Ma specifically doesn’t disclose, inputting a text about at least one example product and current needs of the user, however Forsyth discloses, inputting a text about at least one example product and current needs of the user (Examiner interprets a GUI including prompt boxes for text, an upload option for an image, and menus for selecting multimodal searches, including style-based and context-based outfit recommendations. Forsyth further teaches that a multimodal input may include an example product, such as a bag, and a contextual text term, such as “weekend,” and that the system returns recommended products related to both the product and the contextual need) (“the GUI 116A or 116B provided by the web server(s) 114A and 114B may include one or more prompt boxes through which to receive text, an upload option through which to submit an image, and one or more drop down (or other types of) menus with which to select a type of multi-modal search to perform. These types of multi-modal searches may include, for example, style-based and context-based outfit recommendations, capsule wardrobe generation, “the-same-look-for-less” results, and others, as will be discussed below.” and “FIG. 9 is an example search results page containing outfit completion in response to style-based and context-based outfit queries, according to various embodiments. Note that the multi-modal input in the search engine server 120 (such as a bag and the word “weekend”) is the input query, and the search engine server 120 returns a multi-modal output as the search results, e.g., a bottom, a cropped top, a pair of boots, and a belt. Included with the multi-modal output is a structured text explanation of not only why these items go together, but also why they are related to the input term “weekend.” The combination of the images representing the recommended fashion items and the structure text explanation provides contextual compatibility for the outfit within the context it is to be worn. For example, “Paired with leather accessories, this weekend look is incomplete without a cropped blouse and distressed skinny jeans.” FIG. 9 illustrates additional examples such as pairing the bag with “party,” submitting only a skirt, submitting a skirt with the image of the blouse, and so forth, with different related multi-modal search results) (0035, 0108). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the applicant’s invention to deriving an intention vector of the user based on the at least one example product, deriving an average intention vector based on the intention vector and the intention information, deriving one or more sampling intention vectors based on a probability distribution expressing the current intention of the user and the average intention vector, and deriving a product corresponding to the sampling intention vector, the product corresponding to the sampling intention vector comprising a tangible product with value and an intangible product, as disclosed by Ma, inputting a text about at least one example product and current needs of the user, as taught by Forsyth for the purpose so that the users can provide both an example product and contextual text describing current needs, such as a bag and “weekend,” to obtain more contextually relevant product recommendations to receive richer current-intent input rather than relying only on an anchor item and historical user/product-type embeddings. Ma specifically doesn’t disclose, deriving intention information about the text using a Large Language Model (LLM), however Qiao discloses, deriving intention information about the text using a Large Language Model (LLM) (Examiner interprets an LLM integration framework for session-based recommendation where session data is transformed into text and behavior data, LLM inference is performed on session text data, and LLM-derived representations are fused for recommendation. Qiao teaches using an LLM as an inference engine and guiding the LLM with prompts from long-term and short-term perspectives to infer user/session intent. Qiao further teaches prompt-based LLM inference using item-name/item-ID sequences and instructing the LLM to infer an item of interest) (Pgs. 1-5). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the applicant’s invention to deriving an intention vector of the user based on the at least one example product, deriving an average intention vector based on the intention vector and the intention information, deriving one or more sampling intention vectors based on a probability distribution expressing the current intention of the user and the average intention vector, and deriving a product corresponding to the sampling intention vector, the product corresponding to the sampling intention vector comprising a tangible product with value and an intangible product, as disclosed by Ma, deriving intention information about the text using a Large Language Model (LLM), as taught by Qiao for purpose to use an LLM to infer intent from item/session text and then fuse LLM-derived inference embeddings with recommender embeddings and thus using a plug-and-play LLM enhancement framework that stores LLM inference embeddings and fuses them with conventional recommender representations. As per claims 2, Ma discloses, wherein the step of deriving the intention vector comprises the steps of: expressing the at least one example product as an index (Examiner interprets the claimed “index” broadly as an item identifier, item ID, or catalog index. Ma’s anchor item and taxonomy mapping teach indexed catalog items, because Ma receives a request for recommendations for an anchor item and maps items to product types through an item taxonomy) (“FIG. 8, in a number of embodiments, method 800 also can include an activity 810 of receiving a request for personalized complementary item recommendations for an anchor item and a user. For example, a user can select to view an item page for an anchor item, which can generate a request to generate personalized complementary item recommendations for the user based on the anchor item” and “method 800 additionally can include an activity 830 of ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item. In several embodiments, the respective item-to-item complementarity metric for the each respective item can be generated using a cosine similarity measurement between a mean vector of the item-level embedding Gaussian distribution for the anchor item and a respective mean vector of the respective item-level embedding Gaussian distribution for the each respective item. In various embodiments, ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity”) (0100 and 0104-0106, 0067-0069); sampling k feature vectors from a probability distribution regarding features of the atleast one example product (Examiner interprets “sampling k feature vectors” as selecting or generating one or more feature/embedding vectors from a learned probabilistic item representation. Ma teaches that each item in a pair of co-purchased items can be modeled by a Gaussian distribution, that an item-level embedding using a Gaussian distribution for item q is stored in item-level embedding 409, and that item-level Gaussian distributions and product-type Gaussian mixture distributions are learned) (“FIG. 9, method 805 can include an activity 905 of retrieving respective Gaussian distribution representations of each item of an item pair. In some embodiments, two items added to a basket can be treated as a co-purchase by a user u. In various embodiments, each item in a pair of co-purchase items can be modeled by a Gaussian distribution for an item q. In various embodiments, an item-level embedding using Gaussian Distribution for an item q can be stored in item-level embedding 409 (FIG. 4) … a vector representation of a user u can be stored in user embedding 410 (FIG. 4) and can be expressed as: θ.sub.u” and “method 800 additionally can include an activity 830 of ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item … ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity”) (0065-0069 and 0104-0106, 0100); and encoding the feature vector into the intention vector (Examiner interprets the claimed “intention vector” broadly as the item/user-intent representation used to drive recommendation. Ma’s query-item Gaussian mean vector and user embedding correspond to the claimed encoded intention vector) (“FIG. 9, method 805 can include an activity 905 of retrieving respective Gaussian distribution representations of each item of an item pair. In some embodiments, two items added to a basket can be treated as a co-purchase by a user u. In various embodiments, each item in a pair of co-purchase items can be modeled by a Gaussian distribution for an item q. In various embodiments, an item-level embedding using Gaussian Distribution for an item q can be stored in item-level embedding 409 (FIG. 4) … a vector representation of a user u can be stored in user embedding 410 (FIG. 4) and can be expressed as: θ.sub.u” and “method 800 additionally can include an activity 830 of ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item … ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity”) (0067-0069 and 0104-0106, 0100). Ma specifically doesn’t disclose, wherein the k is an integer greater than or equal to 1, however Forsyth discloses, wherein the k is an integer greater than or equal to 1 (Examiner interprets a recitation of k ≥ 1 is a routine parameter selection. Forsyth’s retrieving a set of k items, where k is a predetermined number of items, and sorting/returning the k most compatible items. The recitation that k is greater than or equal to 1 is also a routine parameter selection because a set of k recommended items necessarily includes one or more items when recommendations are returned) (“retrieve a set of k items (e.g., where k is a predetermined number of items) of type t that are compatible with a query item i.sub.q, the search engine server 120 samples a collection of fashion items I of type t and computes the compatibility distance d.sub.i between each sampled item i∈I and the query item i.sub.q in the corresponding type-aware compatibility space. The search engine server 120 may further sort all the distances and return the k items with the smallest d.sub.i as the k most-compatible items. In the case when a user supplies a set of query item(s) I.sub.q, the search engine server 120 computes the distance d.sub.i, which represent how compatible a sampled item i∈I is with the query item(s) I.sub.q as”) (0104-0106). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the applicant’s invention to deriving an intention vector of the user based on the at least one example product, deriving an average intention vector based on the intention vector and the intention information, deriving one or more sampling intention vectors based on a probability distribution expressing the current intention of the user and the average intention vector, and deriving a product corresponding to the sampling intention vector, the product corresponding to the sampling intention vector comprising a tangible product with value and an intangible product, as disclosed by Ma, wherein the k is an integer greater than or equal to 1, as taught by Forsyth in response to rank candidate items and output a selected set of recommended items to control the number of recommendations returned to the user. As per claims 3, Ma discloses, wherein the step of deriving the average intention vector further comprises the steps of: deriving a density of the intention vector using MPMD (Max Probability position of Mixed Distributions) (Examiner interprets MPMD, or “Max Probability position of Mixed Distributions,” as applicant’s name for finding or using a high-probability density position in mixed distributions. Ma teaches Gaussian mixture distributions, probability product kernels, and personalized component weights, which teach deriving probability/density information from mixed Gaussian distributions) (“method 805 also can include an activity 910 of determining an item complementarity metric between each item of the item pair using a probability product kernel. The probability product kernel E(q,r) is expressed in Equations 1 and 2: … where T refers to the transpose of vector and −1 refers to the inverse operation of a matrix” and “where Σ.sub.k w.sub.c.sub.q.sub.,k=1, which can be shared by records of all users, k refers to the index of components of the Gaussian Mixture, and w.sub.c.sub.q.sub.,k is the component weight for the k-th component custom-character(x; μ.sub.c.sub.q.sub.,k, Σ.sub.c.sub.q.sub.,k) of the product-type c.sup.q … in order to machine-learn the multi-topic pattern shared by all the users for stability, the component weights w.sub.k in each Gaussian Mixture can be used for all co-purchase product-type records (non-personalized). In some embodiments, determining a non-personalized product-type complementarity metric can involve computing an interaction between Gaussian Mixtures of two co-purchase Product-types E.sub.m(c.sup.q, c.sup.r) given a pair of co-purchase product-type (c.sup.q, c.sup.r), with each Gaussian Mixture representation, expressed by: …”) (0071-0073 and 0084-0087, 0090-0094); and deriving the average intention vector based on the density of the intention vector (Examiner interprets deriving the average intention vector based on the density of the intention vector. Ma computes personalized product types from user embedding and product-type Gaussian mixture distribution, and defines a personalized product type as a weighted average of Gaussian-mixture component mean vectors with personalized component weights. The Examiner interprets this weighted average of Gaussian-mixture component mean vectors as the claimed average intention vector derived from density/probability information) (“after the request is received, method 500 can include an activity 502 of computing personalized product-types from user embedding 410 and product-type Gaussian Mixture distribution 411. Activity 502 can be similar or identical to activity 815 (FIG. 8, described below)” and “method 800 further can include an activity 815 of generating personalized product-type metrics for the user based at least in part on a user embedding for the user and product-type embedding Gaussian mixture distributions. In several embodiments, generating personalized recommendations can include computing the personalized product-type for user u. The personalized product-type of c.sup.q can be defined as the weighted average of its component's mean vector μ.sub.c.sub.q.sub.,k with personalized component weights p.sub.c.sub.q.sub.,k.”) (0051 and 0101, 0100). As per claims 4 and 12, Ma discloses, wherein the step of deriving the product corresponding to the sampling intention vector comprises the steps of: deriving an associated product vector corresponding to the sampling intention vector (Examiner interprets Ma’s candidate item vectors and Gaussian mean vectors as associated product vectors corresponding to the user’s sampled/current-intent vector. Ma ranks each candidate item using item-level Gaussian distributions for the anchor item and candidate items) (“method 800 additionally can include an activity 830 of ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item … ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity”) (0104-0106); filtering the associated product vector to derive a recommendation product vector (Examiner interprets ranking and retaining top-N candidate vectors and filtering by user/context constraints as deriving a recommendation product vector from associated product vectors. Ma determines top product types based on personalized product-type complementarity metrics and cosine similarity measurements, generates a set of first items associated with the top product types, ranks candidate items, and retains or saves the top-N ranked items as output) (“method 800 also can include an activity 820 of determining top product types based at least in part on personalized product-type complementarity metrics generated using the personalized product-type metrics and cosine similarity measurements. In several embodiments, the set of first items associated with the top product types can be determined using an item taxonomy. In some embodiments, each item can be mapped to a respective product-type. In some embodiments, activity 820 can be performed by using the computed personalized product-types in activity 815 to compute personalized product-type complementarity by the cosine similarity between the personalized product-type mu and the personalized product-types of other product-types. In several embodiments, the top-Z product-types with biggest cosine similarity measurements can be retained. The cosine similarity can measure a degree or level of similarity between two product-types. A larger cosine similarity can indicate that two product-types are more similar than other product-types … method 800 further can include an activity 835 of selecting a set of top items as the personalized complementary item recommendations based on the ranking. In several embodiments, activity 835 can involve retaining or saving the top-N items ranked in activity 830 as output. In several embodiments, activities 815, 820, 825, 830, and/or 835 can be performed for each request of each user u and query item q.”) (0103-0107); converting the recommendation product vector into a recommendation product index (Examiner interprets converting a vector to an index as mapping the selected/recommended vector representation to a catalog item identifier. Ma uses taxonomy information to map product types to sets of items and ranks individual items from that set) (“method 800 further can include an activity 825 of generating a set of first items associated with the top product-types. In various embodiments, activity 825 can involve using the top-Z relevant product-types and taxonomy information, and taking the union of all of the items to form the set of first items, I.sub.R,u, as expressed in Equation 12: … method 800 additionally can include an activity 830 of ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item … ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity”) (0104-0106, 0100). Ma specifically doesn’t disclose, displaying the product corresponding to the sampling intention vector as a product corresponding to the recommendation product index, however Forsyth discloses, and displaying the product corresponding to the sampling intention vector as a product corresponding to the recommendation product index (Examiner interprets the displaying recommended products by returning search results to a browser, including images and structured text explaining why the recommended items are relevant. Forsyth also teaches multimodal output as search results, including recommended fashion items and explanatory text) (“processing device coupled to the communication interface may execute a neural network (NN) regressor model on the first image to identify multiple second items that are one of similar to or compatible with the item depicted in the first image. A set of images may correspond to the plurality of second items. The processing device may further generate structured text that explains, within one of a phrase or a sentence, why the plurality of second items are relevant to the item. The processing device may further return, to the browser of the client device via the communication interface, a set of search results comprising the set of images and the structured text” and “FIG. 9 is an example search results page containing outfit completion in response to style-based and context-based outfit queries, according to various embodiments. Note that the multi-modal input in the search engine server 120 (such as a bag and the word “weekend”) is the input query, and the search engine server 120 returns a multi-modal output as the search results, e.g., a bottom, a cropped top, a pair of boots, and a belt. Included with the multi-modal output is a structured text explanation of not only why these items go together, but also why they are related to the input term “weekend.” The combination of the images representing the recommended fashion items and the structure text explanation provides contextual compatibility for the outfit within the context it is to be worn. For example, “Paired with leather accessories, this weekend look is incomplete without a cropped blouse and distressed skinny jeans.” FIG. 9 illustrates additional examples such as pairing the bag with “party,” submitting only a skirt, submitting a skirt with the image of the blouse, and so forth, with different related multi-modal search results”) (0054 and 0108). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the applicant’s invention to deriving an intention vector of the user based on the at least one example product, deriving an average intention vector based on the intention vector and the intention information, deriving one or more sampling intention vectors based on a probability distribution expressing the current intention of the user and the average intention vector, and deriving a product corresponding to the sampling intention vector, the product corresponding to the sampling intention vector comprising a tangible product with value and an intangible product, as disclosed by Ma, displaying the product corresponding to the sampling intention vector as a product corresponding to the recommendation product index, as taught by Forsyth for purpose of using browser-based search-result display that return recommended items to a user and displaying the selected recommended items with images and explanatory text improves usability and user confidence in the recommendation results. As per claims 5 and 13, Ma discloses, wherein the step of deriving the product corresponding to the sampling intention vector further comprises the steps of: generating user preference information based on a past product purchase history of the user (Examiner interprets generating user preference information from historical purchase/co-purchase/add-to-cart data i.e. user activity data including add-to-cart sequences, click data, co-purchase histories, item pairs, and product-type pairs and also discloses user preference metrics based on historical user transaction records) (“method 400 can include an activity 403 of data processing of receiving co-purchase item pairs and product-type pairs. In a number of embodiments, co-purchase item pairs can be received from user activity data 401, and product-type pairs can be received from item taxonomy 402. In some embodiments, user activity data can include add-to-cart sequences for users, such as users 350-351 (FIG. 3), and/or click data, co-purchase histories, item pairs, product-type pairs, and/or another suitable type of item data. For example, a user might purchase baking soda, flour, and bananas online on a certain day, then purchase baking soda, detergent, and bananas online on another day, and then purchase baking soda, milk, and bananas on yet another day. In this example, the product baking soda can be grouped as an item with product-type topic disambiguation where determining an intent of the user can signal which complementary product-type can or cannot be recommended to a user”) (0043, 0074-0077), product inquiry history of the user (Examiner interprets browse, click, and add-to-cart activity as product inquiry history because those actions reflect user investigation or inquiry into products before purchase. Ma teaches websites that allow users to browse and/or search for items, add items to an electronic shopping cart, and purchase items, and Ma further teaches user activity data including click data) (“web server 320 can be in data communication through Network 330 with one or more user computers, such as user computers 340 and/or 341. Network 330 can be a public network, a private network or a hybrid network. In some embodiments, user computers 340-341 can be used by users, such as users 350 and 351, which also can be referred to as customers, in which case, user computers 340 and 341 can be referred to as customer computers. In many embodiments, web server 320 can host one or more sites (e.g., websites) that allow users to browse and/or search for items (e.g., products), to add items to an electronic shopping cart, and/or to order (e.g., purchase) items, in addition to other suitable activities”) (0032, 0043), and search history of the user (Examiner interprets website allows users to browse and/or search for items) (“web server 320 can be in data communication through Network 330 with one or more user computers, such as user computers 340 and/or 341. Network 330 can be a public network, a private network or a hybrid network. In some embodiments, user computers 340-341 can be used by users, such as users 350 and 351, which also can be referred to as customers, in which case, user computers 340 and 341 can be referred to as customer computers. In many embodiments, web server 320 can host one or more sites (e.g., websites) that allow users to browse and/or search for items (e.g., products), to add items to an electronic shopping cart, and/or to order (e.g., purchase) items, in addition to other suitable activities”) (0032); and deriving the recommendation product vector by performing filtering on the associated product vector based on the user preference information (Examiner interprets Ma’s personalization, ranking, and selection based on user embedding and historical user activity as filtering associated product vectors based on user preference information. Ma generates personalized product-type metrics based on user embedding and product-type Gaussian mixture distributions, determines top product types, ranks items based on item-level Gaussian distributions, and selects top recommendations) (“method 800 further can include an activity 815 of generating personalized product-type metrics for the user based at least in part on a user embedding for the user and product-type embedding Gaussian mixture distributions. In several embodiments, generating personalized recommendations can include computing the personalized product-type for user u. The personalized product-type of c.sup.q can be defined as the weighted average of its component's mean vector … ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity … method 800 further can include an activity 835 of selecting a set of top items as the personalized complementary item recommendations based on the ranking. In several embodiments, activity 835 can involve retaining or saving the top-N items ranked in activity 830 as output. In several embodiments, activities 815, 820, 825, 830, and/or 835 can be performed for each request of each user u and query item q”) (0101-0107). As per claims 11, Ma discloses, method for product recommendation based on example products and text input configured to be performed with a computing system, the computing system comprising a memory and a processor configured to identify a current intention of the user and provide recommendation product information, the method comprising the steps of (Examiner interprets a product recommendation computing system including a recommender system and web server configured to automatically determine complementary item recommendations. Ma’s system includes a complementary recommender system, web server, communication system, machine-learning system, generating system, ranking system, and personalization system, thereby teaching the claimed computing-system architecture for generating recommendation product information) (“FIG. 3 illustrates a block diagram of a system 300 that can be employed for automatically determining complimentary items recommendations, according to an embodiment. System 300 is merely exemplary and embodiments of the system are not limited to the embodiments presented herein. The system can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, certain elements, modules, or systems of system 300 can perform various procedures, processes, and/or activities. In other embodiments, the procedures, processes, and/or activities can be performed by other suitable elements, modules, or systems of system 300 … system 300 can include a complimentary recommender system 310 and/or a web server 320. Complimentary recommender system 310 and/or web server 320 can each be a computer system, such as computer system 100 (FIG. 1), as described above, and can each be a single computer, a single server, or a cluster or collection of computers or servers, or a cloud of computers or servers. In another embodiment, a single computer system can host two or more of, or all of, complimentary recommender system 310 and/or web server 320. Additional details regarding complimentary recommender system 310 and/or web server 320 are described herein.”) (0029-0031, 0039): deriving an average intention vector based on the intention information (Examiner interprets Ma’s anchor item / query item as corresponding to the claimed example product, see para. 0100, Ma teaches deriving vector/distribution representations for items and users because each item can be modeled by an item-level Gaussian distribution, and a vector representation of a user is stored in user embedding 410, see para. 0067-0069. Ma also teaches ranking candidate items using a mean vector of the Gaussian distribution for the anchor item and a mean vector of the Gaussian distribution for each candidate item, see para. 0106) (“FIG. 9, method 805 can include an activity 905 of retrieving respective Gaussian distribution representations of each item of an item pair. In some embodiments, two items added to a basket can be treated as a co-purchase by a user u. In various embodiments, each item in a pair of co-purchase items can be modeled by a Gaussian distribution for an item q. In various embodiments, an item-level embedding using Gaussian Distribution for an item q can be stored in item-level embedding 409 (FIG. 4) … a vector representation of a user u can be stored in user embedding 410 (FIG. 4) and can be expressed as: θ.sub.u” and “method 800 additionally can include an activity 830 of ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item. In several embodiments, the respective item-to-item complementarity metric for the each respective item can be generated using a cosine similarity measurement between a mean vector of the item-level embedding Gaussian distribution for the anchor item and a respective mean vector of the respective item-level embedding Gaussian distribution for the each respective item. In various embodiments, ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity”) (0067-0069 and 0106, 0100); deriving one or more sampling intention vectors based on a probability distribution expressing a current intention of the user and the average intention vector (Examiner interprets the claimed “sampling intention vectors based on a probability distribution” as encompassed or rendered obvious by Ma’s Gaussian / Gaussian-mixture vector representation and personalized probability-weighted component structure i.e. deriving vectors based on probability distributions expressing user current intent because Ma trains item-level embedding Gaussian distributions, user embeddings, and product-type embedding Gaussian mixture distributions, and personalizes Gaussian mixture component weights based on the user embedding) (“FIG. 8, method 800 optionally can include, before an activity 810 (described below), an activity 805 of training a machine-learning model to learn item-level embedding Gaussian distributions for items, the user embedding, and the product-type embedding Gaussian mixture distributions based on co-purchase item pairs in historic activity data of the user and product-type pairs in an item taxonomy. In some embodiments, training the machine-learning model can include a training pipeline that can perform iterations of looping over item pairs, product-type pairs and users and minimize the loss functions until a stop criteria occurs. In several embodiments, co-purchase item pairs can include a product-type embedding represented by a Gaussian mixture distribution. In various embodiments, activity 805 can be performed as shown in FIG. 9 … FIG. 9, method 805 can include an activity 905 of retrieving respective Gaussian distribution representations of each item of an item pair. In some embodiments, two items added to a basket can be treated as a co-purchase by a user u. In various embodiments, each item in a pair of co-purchase items can be modeled by a Gaussian distribution for an item q. In various embodiments, an item-level embedding using Gaussian Distribution for an item q can be stored in item-level embedding 409 (FIG. 4)” and “method 805 additionally can include an activity 935 of determining a personalized product-type complementarity metric at an individual level between each product type of the product-type pair using the probability product kernel with a personalized component weight. For a given pair of co-purchase product-types c.sup.q, c.sup.r and a user u.sub.2, Equation 1, described above, can be reused to compute the interaction between two components from two different Gaussian Mixture. In various embodiments, in order to machine-learn the multi-topic pattern for the individual user u.sub.2, the component weights in each Gaussian Mixture can be personalized. The components of product-types' Gaussian Mixture can be reused and the personalized component weights by the affinity between a user's embedding and the component location can be computed … personalized component weights can be normalized such that their sum is 1. In some embodiments, reusing Equation 8 with personalized component weights (which can be the same components) can include a personalized interaction E.sub.m(c.sup.q, c.sup.r|u) between two co-purchased product-types”) (0065-0067 and 0090-0094, 010-0103), and deriving a product corresponding to the sampling intention vector, wherein the product corresponding to the sampling intention vector comprises a tangible product with value and an intangible product (Examiner interprets deriving a product corresponding to the vector/distribution-based recommendation by ranking candidate items and selecting top items as personalized complementary item recommendations) (“method 800 further can include an activity 835 of selecting a set of top items as the personalized complementary item recommendations based on the ranking. In several embodiments, activity 835 can involve retaining or saving the top-N items ranked in activity 830 as output. In several embodiments, activities 815, 820, 825, 830, and/or 835 can be performed for each request of each user u and query item q” and “The acts can include receiving a request for personalized complementary item recommendations for an anchor item and a user. The acts also can include generating personalized product-type metrics for the user based at least in part on a user embedding for the user and product-type embedding Gaussian mixture distributions. The acts additionally can include determining top product types based at least in part on personalized product-type complementarity metrics generated using the personalized product-type metrics and cosine similarity measurements. The acts further can include generating a set of first items associated with the top product-types. The acts also can include ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item. The acts further can include selecting a set of top items as the personalized complementary item recommendations based on the ranking …”) (0107 and 0117-0118). Ma specifically doesn’t disclose, inputting a text about current needs of the user, however Forsyth discloses, inputting a text about current needs of the user (Examiner interprets a GUI including prompt boxes for text, an upload option for an image, and menus for selecting multimodal searches, including style-based and context-based outfit recommendations and further teaches that a multimodal input may include an example product, such as a bag, and a contextual text term, such as “weekend,” and the system returns recommended products related to both the product and the contextual need) (“the GUI 116A or 116B provided by the web server(s) 114A and 114B may include one or more prompt boxes through which to receive text, an upload option through which to submit an image, and one or more drop down (or other types of) menus with which to select a type of multi-modal search to perform. These types of multi-modal searches may include, for example, style-based and context-based outfit recommendations, capsule wardrobe generation, “the-same-look-for-less” results, and others, as will be discussed below.” and “FIG. 9 is an example search results page containing outfit completion in response to style-based and context-based outfit queries, according to various embodiments. Note that the multi-modal input in the search engine server 120 (such as a bag and the word “weekend”) is the input query, and the search engine server 120 returns a multi-modal output as the search results, e.g., a bottom, a cropped top, a pair of boots, and a belt. Included with the multi-modal output is a structured text explanation of not only why these items go together, but also why they are related to the input term “weekend.” The combination of the images representing the recommended fashion items and the structure text explanation provides contextual compatibility for the outfit within the context it is to be worn. For example, “Paired with leather accessories, this weekend look is incomplete without a cropped blouse and distressed skinny jeans.” FIG. 9 illustrates additional examples such as pairing the bag with “party,” submitting only a skirt, submitting a skirt with the image of the blouse, and so forth, with different related multi-modal search results) (0035, 0108). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the applicant’s invention to deriving an intention vector of the user based on the at least one example product, deriving an average intention vector based on the intention vector and the intention information, deriving one or more sampling intention vectors based on a probability distribution expressing the current intention of the user and the average intention vector, and deriving a product corresponding to the sampling intention vector, the product corresponding to the sampling intention vector comprising a tangible product with value and an intangible product, as disclosed by Ma, inputting a text about current needs of the user, as taught by Forsyth in response to multimodal text/example-product input interface to recommend products based on an anchor item and user to obtain more contextually relevant product recommendations to receive richer current-intent input rather than relying only on an anchor item and historical user/product-type embeddings. Ma specifically doesn’t disclose, deriving intention information about the text using a Large Language Model (LLM), however Qiao discloses, deriving intention information about the text using a Large Language Model (LLM) (Examiner interprets an LLM Integration Framework for session-based recommendation where session data is transformed into text and behavior data, LLM inference is performed on session text data, and the LLM-derived representations are fused for recommendation. See Qiao NPL p.1. Qiao teaches using an LLM as an inference engine and guiding the LLM with prompts from long-term and short-term perspectives to infer user/session intent. See Qiao NPL p.2. Qiao further teaches prompt-based LLM inference using item-name/item-ID sequences and instructing the LLM to infer an item of interest. See Qiao NPL p.4–5) (Pgs. 1-5). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the applicant’s invention to deriving an intention vector of the user based on the at least one example product, deriving an average intention vector based on the intention vector and the intention information, deriving one or more sampling intention vectors based on a probability distribution expressing the current intention of the user and the average intention vector, and deriving a product corresponding to the sampling intention vector, the product corresponding to the sampling intention vector comprising a tangible product with value and an intangible product, as disclosed by Ma, deriving intention information about the text using a Large Language Model (LLM), as taught by Qiao for purpose to use an LLM to infer intent from item/session text and then fuse LLM-derived inference embeddings with recommender embeddings and using a plug-and-play LLM enhancement framework that stores LLM inference embeddings and fuses them with conventional recommender representations. Claims 6-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. US20220245709 (“Ma”) in view of U.S. Pub. 20200311798 (“Forsyth”). As per claims 6, Ma discloses, method for product recommendation based on example products and text input configured to be performed with a computing system, the computing system comprising a memory and a processor configured to identify current intention of a user and provide recommendation product information, the method comprising the steps of (Examiner interprets a product recommendation computing system including a recommender system and web server configured to automatically determine complementary item recommendations. Ma’s system includes a complementary recommender system, web server, communication system, machine-learning system, generating system, ranking system, and personalization system, thereby teaching the claimed computing-system architecture for generating recommendation product information) (“FIG. 3 illustrates a block diagram of a system 300 that can be employed for automatically determining complimentary items recommendations, according to an embodiment. System 300 is merely exemplary and embodiments of the system are not limited to the embodiments presented herein. The system can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, certain elements, modules, or systems of system 300 can perform various procedures, processes, and/or activities. In other embodiments, the procedures, processes, and/or activities can be performed by other suitable elements, modules, or systems of system 300 … system 300 can include a complimentary recommender system 310 and/or a web server 320. Complimentary recommender system 310 and/or web server 320 can each be a computer system, such as computer system 100 (FIG. 1), as described above, and can each be a single computer, a single server, or a cluster or collection of computers or servers, or a cloud of computers or servers. In another embodiment, a single computer system can host two or more of, or all of, complimentary recommender system 310 and/or web server 320. Additional details regarding complimentary recommender system 310 and/or web server 320 are described herein.”) (0029-0031, 0039): deriving an intention vector of the user based on the at least one example product (Examiner interprets Ma’s anchor item or query item as corresponding to the claimed example product. Ma teaches receiving a request for personalized complementary item recommendations for an anchor item and a user, deriving vector/distribution representations for items and users, modeling each item with an item-level Gaussian distribution, storing a vector representation of a user in user embedding 410, and ranking candidate items using a mean vector of the Gaussian distribution for the anchor item and mean vectors of candidate items) (“FIG. 9, method 805 can include an activity 905 of retrieving respective Gaussian distribution representations of each item of an item pair. In some embodiments, two items added to a basket can be treated as a co-purchase by a user u. In various embodiments, each item in a pair of co-purchase items can be modeled by a Gaussian distribution for an item q. In various embodiments, an item-level embedding using Gaussian Distribution for an item q can be stored in item-level embedding 409 (FIG. 4) … a vector representation of a user u can be stored in user embedding 410 (FIG. 4) and can be expressed as: θ.sub.u” and “method 800 additionally can include an activity 830 of ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item. In several embodiments, the respective item-to-item complementarity metric for the each respective item can be generated using a cosine similarity measurement between a mean vector of the item-level embedding Gaussian distribution for the anchor item and a respective mean vector of the respective item-level embedding Gaussian distribution for the each respective item. In various embodiments, ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity”) (0067-0069 and 0106, 0100); deriving an average intention vector based on the intention vector (Examiner interprets the claimed “average intention vector” broadly as a user-personalized vector/metric generated by combining user intent/preference information with product-type vector information i.e. Ma computes personalized product types from user embedding 410 and product-type Gaussian mixture distribution 411, and defines a personalized product type as a weighted average of component mean vectors with personalized component weights) (“after the request is received, method 500 can include an activity 502 of computing personalized product-types from user embedding 410 and product-type Gaussian Mixture distribution 411. Activity 502 can be similar or identical to activity 815 (FIG. 8, described below” and “method 800 further can include an activity 815 of generating personalized product-type metrics for the user based at least in part on a user embedding for the user and product-type embedding Gaussian mixture distributions. In several embodiments, generating personalized recommendations can include computing the personalized product-type for user u. The personalized product-type of c.sup.q can be defined as the weighted average of its component's mean vector μ.sub.c.sub.q.sub.,k with personalized component weights p.sub.c.sub.q.sub.,k”) (0051 and 0101); deriving one or more sampling intention vectors based on a probability distribution expressing the current intention of the user and the average intention vector (Examiner interprets the claimed “sampling intention vectors based on a probability distribution” as encompassed or rendered obvious by Ma’s Gaussian / Gaussian-mixture vector representation and personalized probability-weighted component structure i.e. deriving vectors based on probability distributions expressing user current intent because Ma trains item-level embedding Gaussian distributions, user embeddings, and product-type embedding Gaussian mixture distributions, and personalizes Gaussian mixture component weights based on the user embedding) (“FIG. 8, method 800 optionally can include, before an activity 810 (described below), an activity 805 of training a machine-learning model to learn item-level embedding Gaussian distributions for items, the user embedding, and the product-type embedding Gaussian mixture distributions based on co-purchase item pairs in historic activity data of the user and product-type pairs in an item taxonomy. In some embodiments, training the machine-learning model can include a training pipeline that can perform iterations of looping over item pairs, product-type pairs and users and minimize the loss functions until a stop criteria occurs. In several embodiments, co-purchase item pairs can include a product-type embedding represented by a Gaussian mixture distribution. In various embodiments, activity 805 can be performed as shown in FIG. 9 … FIG. 9, method 805 can include an activity 905 of retrieving respective Gaussian distribution representations of each item of an item pair. In some embodiments, two items added to a basket can be treated as a co-purchase by a user u. In various embodiments, each item in a pair of co-purchase items can be modeled by a Gaussian distribution for an item q. In various embodiments, an item-level embedding using Gaussian Distribution for an item q can be stored in item-level embedding 409 (FIG. 4)” and “method 805 additionally can include an activity 935 of determining a personalized product-type complementarity metric at an individual level between each product type of the product-type pair using the probability product kernel with a personalized component weight. For a given pair of co-purchase product-types c.sup.q, c.sup.r and a user u.sub.2, Equation 1, described above, can be reused to compute the interaction between two components from two different Gaussian Mixture. In various embodiments, in order to machine-learn the multi-topic pattern for the individual user u.sub.2, the component weights in each Gaussian Mixture can be personalized. The components of product-types' Gaussian Mixture can be reused and the personalized component weights by the affinity between a user's embedding and the component location can be computed … personalized component weights can be normalized such that their sum is 1. In some embodiments, reusing Equation 8 with personalized component weights (which can be the same components) can include a personalized interaction E.sub.m(c.sup.q, c.sup.r|u) between two co-purchased product-types”) (0065-0067 and 0090-0094, 010-0103), and deriving a product corresponding to the sampling intention vector, wherein the product corresponding to the sampling intention vector comprises a tangible product with value and an intangible product (Examiner interprets deriving a product corresponding to the vector/distribution-based recommendation by ranking candidate items and selecting top items as personalized complementary item recommendations) (“method 800 further can include an activity 835 of selecting a set of top items as the personalized complementary item recommendations based on the ranking. In several embodiments, activity 835 can involve retaining or saving the top-N items ranked in activity 830 as output. In several embodiments, activities 815, 820, 825, 830, and/or 835 can be performed for each request of each user u and query item q” and “The acts can include receiving a request for personalized complementary item recommendations for an anchor item and a user. The acts also can include generating personalized product-type metrics for the user based at least in part on a user embedding for the user and product-type embedding Gaussian mixture distributions. The acts additionally can include determining top product types based at least in part on personalized product-type complementarity metrics generated using the personalized product-type metrics and cosine similarity measurements. The acts further can include generating a set of first items associated with the top product-types. The acts also can include ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item. The acts further can include selecting a set of top items as the personalized complementary item recommendations based on the ranking …”) (0107 and 0117-0118). Ma specifically doesn’t disclose, inputting at least one example product, however Forsyth discloses, inputting at least one example product (Examiner interprets a GUI including prompt boxes for text, an upload option for an image, and menus for selecting multimodal searches, including style-based and context-based outfit recommendations and further teaches that a multimodal input may include an example product, such as a bag, and a contextual text term, such as “weekend,” and the system returns recommended products related to both the product and the contextual need) (“the GUI 116A or 116B provided by the web server(s) 114A and 114B may include one or more prompt boxes through which to receive text, an upload option through which to submit an image, and one or more drop down (or other types of) menus with which to select a type of multi-modal search to perform. These types of multi-modal searches may include, for example, style-based and context-based outfit recommendations, capsule wardrobe generation, “the-same-look-for-less” results, and others, as will be discussed below.” and “FIG. 9 is an example search results page containing outfit completion in response to style-based and context-based outfit queries, according to various embodiments. Note that the multi-modal input in the search engine server 120 (such as a bag and the word “weekend”) is the input query, and the search engine server 120 returns a multi-modal output as the search results, e.g., a bottom, a cropped top, a pair of boots, and a belt. Included with the multi-modal output is a structured text explanation of not only why these items go together, but also why they are related to the input term “weekend.” The combination of the images representing the recommended fashion items and the structure text explanation provides contextual compatibility for the outfit within the context it is to be worn. For example, “Paired with leather accessories, this weekend look is incomplete without a cropped blouse and distressed skinny jeans.” FIG. 9 illustrates additional examples such as pairing the bag with “party,” submitting only a skirt, submitting a skirt with the image of the blouse, and so forth, with different related multi-modal search results) (0035, 0108). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the applicant’s invention to deriving an intention vector of the user based on the at least one example product, deriving an average intention vector based on the intention vector and the intention information, deriving one or more sampling intention vectors based on a probability distribution expressing the current intention of the user and the average intention vector, and deriving a product corresponding to the sampling intention vector, the product corresponding to the sampling intention vector comprising a tangible product with value and an intangible product, as disclosed by Ma, inputting at least one example product, as taught by Forsyth in response to multimodal text/example-product input interface to recommend products based on an anchor item and user to obtain more contextually relevant product recommendations to receive richer current-intent input rather than relying only on an anchor item and historical user/product-type embeddings. As per claims 7, Ma discloses, wherein the step of deriving the intention vector comprises the steps of: expressing the at least one example product as an index (xaminer interprets “index” broadly as an item identifier, item ID, or catalog index. Ma’s anchor item and taxonomy mapping teach indexed catalog items.) (“FIG. 8, in a number of embodiments, method 800 also can include an activity 810 of receiving a request for personalized complementary item recommendations for an anchor item and a user. For example, a user can select to view an item page for an anchor item, which can generate a request to generate personalized complementary item recommendations for the user based on the anchor item” and “method 800 additionally can include an activity 830 of ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item. In several embodiments, the respective item-to-item complementarity metric for the each respective item can be generated using a cosine similarity measurement between a mean vector of the item-level embedding Gaussian distribution for the anchor item and a respective mean vector of the respective item-level embedding Gaussian distribution for the each respective item. In various embodiments, ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity”) (0100 and 0104-0106, 0067-0069); sampling k feature vectors from a probability distribution regarding features of the atleast one example product (Examiner interprets “sampling k feature vectors” as selecting or generating one or more feature/embedding vectors from a learned probabilistic item representation i.e. that each item in a pair of co-purchased items can be modeled by a Gaussian distribution, and an item-level embedding using a Gaussian distribution for item q is stored in item-level embedding 409. Ma also teaches item-level embedding Gaussian distributions and product-type Gaussian mixture distributions) (“FIG. 9, method 805 can include an activity 905 of retrieving respective Gaussian distribution representations of each item of an item pair. In some embodiments, two items added to a basket can be treated as a co-purchase by a user u. In various embodiments, each item in a pair of co-purchase items can be modeled by a Gaussian distribution for an item q. In various embodiments, an item-level embedding using Gaussian Distribution for an item q can be stored in item-level embedding 409 (FIG. 4) … a vector representation of a user u can be stored in user embedding 410 (FIG. 4) and can be expressed as: θ.sub.u” and “method 800 additionally can include an activity 830 of ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item … ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity”) (0067-0069 and 0104-0106, 0100); and encoding the feature vector into the intention vector (Examiner interprets “intention vector” broadly as the item/user-intent representation used to drive recommendation. Ma’s query-item Gaussian mean vector and user embedding correspond to the claimed encoded intention vector) (“FIG. 9, method 805 can include an activity 905 of retrieving respective Gaussian distribution representations of each item of an item pair. In some embodiments, two items added to a basket can be treated as a co-purchase by a user u. In various embodiments, each item in a pair of co-purchase items can be modeled by a Gaussian distribution for an item q. In various embodiments, an item-level embedding using Gaussian Distribution for an item q can be stored in item-level embedding 409 (FIG. 4) … a vector representation of a user u can be stored in user embedding 410 (FIG. 4) and can be expressed as: θ.sub.u” and “method 800 additionally can include an activity 830 of ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item … ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity”) (0067-0069 and 0104-0106, 0100). Ma specifically doesn’t disclose, wherein the k is an integer greater than or equal to 1, however Forsyth discloses, wherein the k is an integer greater than or equal to 1 (Examiner interprets a recitation of k ≥ 1 is a routine parameter selection. Forsyth’s k-item retrieval supports this numerical limitation i.e. retrieving a set of k items, where k is a predetermined number) (“retrieve a set of k items (e.g., where k is a predetermined number of items) of type t that are compatible with a query item i.sub.q, the search engine server 120 samples a collection of fashion items I of type t and computes the compatibility distance d.sub.i between each sampled item i∈I and the query item i.sub.q in the corresponding type-aware compatibility space. The search engine server 120 may further sort all the distances and return the k items with the smallest d.sub.i as the k most-compatible items. In the case when a user supplies a set of query item(s) I.sub.q, the search engine server 120 computes the distance d.sub.i, which represent how compatible a sampled item i∈I is with the query item(s) I.sub.q as”) (0104-0106). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the applicant’s invention to deriving an intention vector of the user based on the at least one example product, deriving an average intention vector based on the intention vector and the intention information, deriving one or more sampling intention vectors based on a probability distribution expressing the current intention of the user and the average intention vector, and deriving a product corresponding to the sampling intention vector, the product corresponding to the sampling intention vector comprising a tangible product with value and an intangible product, as disclosed by Ma, wherein the k is an integer greater than or equal to 1, as taught by Forsyth in response to multimodal text/example-product input interface to recommend products based on an anchor item and user to obtain more contextually relevant product recommendations to receive richer current-intent input rather than relying only on an anchor item and historical user/product-type embeddings. As per claims 8, Ma discloses, wherein the step of deriving the average intention vector further comprises the steps of: deriving a density of the intention vector using MPMD (Max Probability position of Mixed Distributions) (Examiner interprets MPMD as applicant’s name for finding or using a high-probability density position in mixed distributions. Ma’s Gaussian mixture distributions, probability product kernel, and personalized component weights teach deriving probability/density information from mixed Gaussian distributions.) (“method 805 also can include an activity 910 of determining an item complementarity metric between each item of the item pair using a probability product kernel. The probability product kernel E(q,r) is expressed in Equations 1 and 2: … where T refers to the transpose of vector and −1 refers to the inverse operation of a matrix” and “where Σ.sub.k w.sub.c.sub.q.sub.,k=1, which can be shared by records of all users, k refers to the index of components of the Gaussian Mixture, and w.sub.c.sub.q.sub.,k is the component weight for the k-th component custom-character(x; μ.sub.c.sub.q.sub.,k, Σ.sub.c.sub.q.sub.,k) of the product-type c.sup.q … in order to machine-learn the multi-topic pattern shared by all the users for stability, the component weights w.sub.k in each Gaussian Mixture can be used for all co-purchase product-type records (non-personalized). In some embodiments, determining a non-personalized product-type complementarity metric can involve computing an interaction between Gaussian Mixtures of two co-purchase Product-types E.sub.m(c.sup.q, c.sup.r) given a pair of co-purchase product-type (c.sup.q, c.sup.r), with each Gaussian Mixture representation, expressed by: …”) (0071-0073 and 0084-0087, 0090-0094); and deriving the average intention vector based on the density of the intention vector (Examiner interprets Ma’s weighted average of Gaussian-mixture component mean vectors as the claimed average intention vector derived from density/probability information i.e. computing personalized product-types from user embedding and product-type Gaussian mixture distribution. See para. 0051. Ma further teaches that the personalized product-type can be defined as a weighted average of component mean vectors with personalized component weights. See para. 0101) (“after the request is received, method 500 can include an activity 502 of computing personalized product-types from user embedding 410 and product-type Gaussian Mixture distribution 411. Activity 502 can be similar or identical to activity 815 (FIG. 8, described below)” and “method 800 further can include an activity 815 of generating personalized product-type metrics for the user based at least in part on a user embedding for the user and product-type embedding Gaussian mixture distributions. In several embodiments, generating personalized recommendations can include computing the personalized product-type for user u. The personalized product-type of c.sup.q can be defined as the weighted average of its component's mean vector μ.sub.c.sub.q.sub.,k with personalized component weights p.sub.c.sub.q.sub.,k.”) (0051 and 0101, 0100). As per claims 9, Ma discloses, wherein the step of deriving the product corresponding to the sampling intention vector comprises the steps of: deriving an associated product vector corresponding to the sampling intention vector (Examiner interprets Ma’s candidate item vectors / Gaussian mean vectors as associated product vectors corresponding to the user’s sampled/current-intent vector.) (“method 800 additionally can include an activity 830 of ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item … ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity”) (0104-0106); filtering the associated product vector to derive a recommendation product vector (Examiner interprets ranking/retaining top-N candidate vectors and filtering by user/context constraints as deriving the recommendation product vector from associated product vectors.) (“method 800 also can include an activity 820 of determining top product types based at least in part on personalized product-type complementarity metrics generated using the personalized product-type metrics and cosine similarity measurements. In several embodiments, the set of first items associated with the top product types can be determined using an item taxonomy. In some embodiments, each item can be mapped to a respective product-type. In some embodiments, activity 820 can be performed by using the computed personalized product-types in activity 815 to compute personalized product-type complementarity by the cosine similarity between the personalized product-type mu and the personalized product-types of other product-types. In several embodiments, the top-Z product-types with biggest cosine similarity measurements can be retained. The cosine similarity can measure a degree or level of similarity between two product-types. A larger cosine similarity can indicate that two product-types are more similar than other product-types … method 800 further can include an activity 835 of selecting a set of top items as the personalized complementary item recommendations based on the ranking. In several embodiments, activity 835 can involve retaining or saving the top-N items ranked in activity 830 as output. In several embodiments, activities 815, 820, 825, 830, and/or 835 can be performed for each request of each user u and query item q.”) (0103-0107). converting the recommendation product vector into a recommendation product index (Examiner interprets converting a vector to an index as mapping the selected/recommended vector representation to a catalog item identifier) (“method 800 further can include an activity 825 of generating a set of first items associated with the top product-types. In various embodiments, activity 825 can involve using the top-Z relevant product-types and taxonomy information, and taking the union of all of the items to form the set of first items, I.sub.R,u, as expressed in Equation 12: … method 800 additionally can include an activity 830 of ranking each respective item in the set of first items based on a respective item-to-item complementarity metric for the each respective item generated using an item-level embedding Gaussian distribution for the anchor item and a respective item-level embedding Gaussian distribution for the each respective item … ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity”) (0104-0106, 0100). Ma specifically doesn’t disclose, displaying the product corresponding to the sampling intention vector as a product corresponding to the recommendation product index, however Forsyth discloses, and displaying the product corresponding to the sampling intention vector as a product corresponding to the recommendation product index (Examiner interprets the “displaying” feature by expressly returning/displaying search results in a browser with images and explanatory text.) (“processing device coupled to the communication interface may execute a neural network (NN) regressor model on the first image to identify multiple second items that are one of similar to or compatible with the item depicted in the first image. A set of images may correspond to the plurality of second items. The processing device may further generate structured text that explains, within one of a phrase or a sentence, why the plurality of second items are relevant to the item. The processing device may further return, to the browser of the client device via the communication interface, a set of search results comprising the set of images and the structured text” and “FIG. 9 is an example search results page containing outfit completion in response to style-based and context-based outfit queries, according to various embodiments. Note that the multi-modal input in the search engine server 120 (such as a bag and the word “weekend”) is the input query, and the search engine server 120 returns a multi-modal output as the search results, e.g., a bottom, a cropped top, a pair of boots, and a belt. Included with the multi-modal output is a structured text explanation of not only why these items go together, but also why they are related to the input term “weekend.” The combination of the images representing the recommended fashion items and the structure text explanation provides contextual compatibility for the outfit within the context it is to be worn. For example, “Paired with leather accessories, this weekend look is incomplete without a cropped blouse and distressed skinny jeans.” FIG. 9 illustrates additional examples such as pairing the bag with “party,” submitting only a skirt, submitting a skirt with the image of the blouse, and so forth, with different related multi-modal search results”) (0054 and 0108). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the applicant’s invention to deriving an intention vector of the user based on the at least one example product, deriving an average intention vector based on the intention vector and the intention information, deriving one or more sampling intention vectors based on a probability distribution expressing the current intention of the user and the average intention vector, and deriving a product corresponding to the sampling intention vector, the product corresponding to the sampling intention vector comprising a tangible product with value and an intangible product, as disclosed by Ma, displaying the product corresponding to the sampling intention vector as a product corresponding to the recommendation product index, as taught by Forsyth in response to multimodal text/example-product input interface to recommend products based on an anchor item and user to obtain more contextually relevant product recommendations to receive richer current-intent input rather than relying only on an anchor item and historical user/product-type embeddings. As per claims 10, Ma discloses, wherein the step of deriving the product corresponding to the sampling intention vector further comprises the steps of: generating user preference information based on a past product purchase history of the user (Examiner interprets generating user preference information from historical purchase/co-purchase/add-to-cart data i.e. user activity data including add-to-cart sequences, click data, co-purchase histories, item pairs, and product-type pairs and also discloses user preference metrics based on historical user transaction records) (“method 400 can include an activity 403 of data processing of receiving co-purchase item pairs and product-type pairs. In a number of embodiments, co-purchase item pairs can be received from user activity data 401, and product-type pairs can be received from item taxonomy 402. In some embodiments, user activity data can include add-to-cart sequences for users, such as users 350-351 (FIG. 3), and/or click data, co-purchase histories, item pairs, product-type pairs, and/or another suitable type of item data. For example, a user might purchase baking soda, flour, and bananas online on a certain day, then purchase baking soda, detergent, and bananas online on another day, and then purchase baking soda, milk, and bananas on yet another day. In this example, the product baking soda can be grouped as an item with product-type topic disambiguation where determining an intent of the user can signal which complementary product-type can or cannot be recommended to a user”) (0043, 0074-0077), product inquiry history of the user (Examiner interprets browse/click/add-to-cart activity as product inquiry history because it reflects user investigation or inquiry into products before purchase i.e. web server sites that allow users to browse and/or search for items, add items to an electronic shopping cart, and order/purchase items and user activity data also includes click data) (“method 800 also) (0032, 0043), and search history of the user (Examiner interprets website allows users to browse and/or search for items) (“web server 320 can be in data communication through Network 330 with one or more user computers, such as user computers 340 and/or 341. Network 330 can be a public network, a private network or a hybrid network. In some embodiments, user computers 340-341 can be used by users, such as users 350 and 351, which also can be referred to as customers, in which case, user computers 340 and 341 can be referred to as customer computers. In many embodiments, web server 320 can host one or more sites (e.g., websites) that allow users to browse and/or search for items (e.g., products), to add items to an electronic shopping cart, and/or to order (e.g., purchase) items, in addition to other suitable activities”) (0032); and deriving the recommendation product vector by performing filtering on the associated product vector based on the user preference information (Examiner interprets Ma’s personalization/ranking/selection based on user embedding and historical user activity as filtering associated product vectors based on user preference information i.e. generating personalized product-type metrics based on user embedding and product-type Gaussian mixture distributions, determining top product types, ranking items based on item-level Gaussian distributions, and selecting top recommendations) (“method 800 further can include an activity 815 of generating personalized product-type metrics for the user based at least in part on a user embedding for the user and product-type embedding Gaussian mixture distributions. In several embodiments, generating personalized recommendations can include computing the personalized product-type for user u. The personalized product-type of c.sup.q can be defined as the weighted average of its component's mean vector … ranking the items in the item set by item-item complementarity can include, for each item i in the set of first items generated in activity 825, using the mean vector of its Gaussian representation to compute the complementarity by the cosine similarity between the mean vector of the query item μ.sub.q and each item μ.sub.i in the set of first items generated in activity 825, then, ranking all of the respective items in the item set by each respective cosine similarity … method 800 further can include an activity 835 of selecting a set of top items as the personalized complementary item recommendations based on the ranking. In several embodiments, activity 835 can involve retaining or saving the top-N items ranked in activity 830 as output. In several embodiments, activities 815, 820, 825, 830, and/or 835 can be performed for each request of each user u and query item q”) (0101-0107). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. The following references have been cited to further show the state of the art. U.S. Pub. No. 20240354641 (“Miller”) Miller discloses, system for gathering interaction data from use of one or more interaction functions by a first user, wherein the interaction data includes data in different modalities and generating a multimodal memory for the interaction data by applying the interaction data to a first machine learning model. The system also identifies a prompt for the first user and processes a combination of data associated with the prompt and the multimodal memory using a second machine learning model to generate recommended content for the first user. The system then proceeds to apply the recommended content to a first interaction client of the first user. U.S. Pub. No. 20170236196 (“Isaacson”). Isaacson discloses, receiving an interaction from a user with an object associated with an advertisement for a product, the advertisement being presented via a first site presented within a browser, transitioning the user from the first site to a destination merchant site in a deep link state. The transitioning process includes retrieving data from the browser and using the data from the browser to enable the user to transition from the first site to the destination merchant site in the deep link state. The deep link state enables the user to purchase the product via an interaction with a purchase object without manually entering payment account data or user address data. The deep link state can enable a “one click” purchasing experience after the transition from the first site. Any inquiry concerning this communication or earlier communications from the examiner should be directed to GAUTAM UBALE whose telephone number is (571)272-9861. The examiner can normally be reached on Mon-Fri. 7:00 AM- 6:30 PM PST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Marissa Thein can be reached on (571) 272-6764. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /GAUTAM UBALE/Primary Examiner, Art Unit 3689
Read full office action

Prosecution Timeline

Apr 06, 2025
Application Filed
Jul 01, 2026
Non-Final Rejection mailed — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12675812
MULTI-ITEM SEARCH
1y 9m to grant Granted Jul 07, 2026
Patent 12626288
BOOSTING SCORES FOR RANKING ITEMS MATCHING A SEARCH QUERY
3y 7m to grant Granted May 12, 2026
Patent 12608736
VEHICLE RECOMMENDATIONS BASED ON BROWSER CONTEXT
3y 2m to grant Granted Apr 21, 2026
Patent 12536574
DYNAMIC PRODUCT PRESENTATION OF MEDIA ELEMENTS
4y 3m to grant Granted Jan 27, 2026
Patent 12293375
TECHNOLOGIES FOR USING MACHINE LEARNING TO DETERMINE PRODUCT CERTIFICATION ELIGIBILITY
4y 6m to grant Granted May 06, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
54%
Grant Probability
99%
With Interview (+47.5%)
3y 9m (~2y 5m remaining)
Median Time to Grant
Low
PTA Risk
Based on 257 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month