DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Election/Restrictions
Claims 6-9 and 22 are withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected invention, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on 4/28/2026.
Applicant’s election without traverse of Claims 1-5, 11, and 13-21 in the reply filed on 4/28/2026 is acknowledged.
Information Disclosure Statement
The information disclosure statement (IDS) filed on 11/25/2024 has been considered by the Examiner.
Priority
Examiner acknowledges that the instant application is a National Stage Application under 35 U.S.C. 371 with relation to PCT Application No. CN2023/095621, filed 05/22/2023, which claims foreign priority under 35 U.S.C. 119 (a)-(d) to Application No. CN202210559808.8, filed 05/23/2022. Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Status of Claims
Applicant’s amendment filed on 4/28/2026 have been considered.
Claims 6-9 and 22 have been withdrawn.
Claims 10 and 12 have been canceled.
Claims 1-9, 11, and 13-22 are currently pending.
Claims 1-5, 11, and 13-21 have been examined.
Claim Interpretation-Claim Terms
The following terms have been interpreted as follows:
Controller: A decision model based on a specific algorithm and obtained through training (see specification [page 11 lines 5-16])
Claim Objections
Claim 16 is objected to because of the following informalities:
Claim 16 recites “…comparing, by the plurality of recommendation models, the plurality of recommendation results of the user feature data”. Claim 16 depends from Claim 1, which does not recite a plurality of recommendation results. For examination purposes, this limitation has been interpreted as “comparing, by the plurality of recommendation models, a plurality of recommendation results of the user feature data”. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 13, 14, 18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 13 recites the limitations “real-time performance” of the cloud-side time-share recommendation model and “real-time performance” of the cloud-side real-time recommendation model in lines 4-6. The metes and bounds of this limitation is unclear inasmuch as one of ordinary skill in the art cannot determine how to avoid infringement of this claim because they are not appraised of the scope of the limitation “real-time performance.” It is unclear what “a real-time performance” encompasses (e.g., runtime, accuracy, recommendation quality, etc.), and therefore in order to ensure that the scope of claim is clear and to demarcate the boundaries of what constitutes infringement of the patent it is required that the claim language to be precise and unambiguous. For purposes of compact prosecution, Examiner will examine the limitation as encompassing a recommendation model’s ability to provide recommendations based on real-time data.
Claim 18 recites substantially similar subject matter to claim 13, and is similarly rendered indefinite for the reasons discussed above.
Claim 14 recites “wherein the recommendation model returns a recommendation result”. Claim 14 depends from Claim 1, which recites “a plurality of recommendation models” and “a matched recommendation model”, but does not explicitly recite “a recommendation model”. Accordingly, there is a lack of antecedent basis for the recommendation model of claim 14, and furthermore it is unclear if the recommendation model of claim 14 refers to one of the plurality of recommendation models, or to the matched recommendation model of claim 1. Accordingly, the claim is rendered indefinite. For examination purposes, the claim has been interpreted as reciting “wherein a recommendation model returns a recommendation result”.
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-5, 11, and 13-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite an abstract idea. The judicial exception is not integrated into a practical application. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
Under Step 1 of the Subject Matter Eligibility Test for Products and Processes, the claims must be directed to one of the four statutory categories. See MPEP 2106.03. Claims 1-5 and 13-17 are directed towards a machine. Claims 11 and 18-21 are directed towards a machine. Therefore, claims 1-5, 11, and 13-21 are directed to one of the four statutory categories (Step 1: YES, regarding claims 1-5, 11, and 13-21).
Under Step 2A of the MPEP, it is determined whether the claims are directed to a judicially recognized exception. See MPEP 2106.04. Step 2A is a two-prong inquiry.
Under Prong 1, it is determined whether the claim recites a judicial exception. In determining whether the claims are directed to a judicial exception, the claims are analyzed to evaluate whether the claims recite a judicial exception.
Taking Claim 11 as representative, claim 11 recites limitations that fall within the certain methods of organizing human activity groupings of abstract ideas, including:
A method for edge-cloud collaborative recommendation, comprising:
obtaining user feature data;
selecting, based on a relative recommendation matching degree between a plurality of recommendation models and the user feature data, a matched recommendation model from the plurality of recommendation models, the plurality of recommendation models comprising the end-side recommendation model and the cloud-side recommendation model, and the relative recommendation matching degree indicating a relative recommendation effect of the plurality of recommendation models on the user feature data; and
performing recommendation based on the matched recommendation model.
Claim 1 recites the same limitations believed to be abstract as recited in claim 11.
Claim 11, as exemplary, recites certain methods of organizing human activity, such as performing commercial interactions. See MPEP 2106.04(a)(2). The MPEP defines the “Certain Methods of Organizing Human Activity” grouping as including fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) (see MPEP § 2106.04(a)(2). The abstract ideas recited in representative claim 11 are certain methods of organizing human activity because collaborative recommendation, obtaining user feature data, selecting, based on a relative recommendation matching degree between a plurality of models and the user feature data, a matched model from the plurality of models, and the relative recommendation matching degree indicating a relative recommendation effect of the plurality of models on the user feature data, and recommending based on the matched model is a commercial or legal interaction because it is an advertising, marketing or sales activity, or business relations. This is further supported by Applicant’s specification ([page 8, paragraph 1]), disclosing that recommendation objects presented to the user include products. Claim 1 recites the same abstract idea as recited in claim 11.
Accordingly, under Prong One of Step 2A of the Alice/Mayo test, claims 1 and 11 recite an abstract idea (Step 2A, Prong One: YES).
Under Step 2A (prong 2), if it is determined that the claims recite a judicial exception, it is then necessary to evaluate whether the claims recite additional elements that integrate the judicial exception into a practical application of that exception (see MPEP 2106.04). As stated in the MPEP, when “an additional element merely recites the words ‘apply it (or an equivalent) with the judicial exception, or merely uses a computer as a tool to perform an abstract idea,” the judicial exception has not been integrated into a practical application. In this case, representative claim 11 includes additional elements such as (additional elements are bolded):
A method for edge-cloud collaborative recommendation, comprising:
obtaining user feature data;
selecting, based on a relative recommendation matching degree between a plurality of recommendation models and the user feature data, a matched recommendation model from the plurality of recommendation models, the plurality of recommendation models comprising the end-side recommendation model deployed in a terminal device and the cloud-side recommendation model deployed in a cloud server, and the relative recommendation matching degree indicating a relative recommendation effect of the plurality of recommendation models on the user feature data; and
performing recommendation based on the matched recommendation model.
Claim 1 additionally discloses additional elements such as (additional elements are bolded):
A system for edge-cloud collaborative recommendation, comprising:
a terminal device and a cloud server, wherein the cloud server is arranged for: obtaining user feature data of the terminal device;
selecting, based on a relative recommendation matching degree between a plurality of recommendation models and the user feature data, a matched recommendation model from the plurality of recommendation models, the plurality of recommendation models comprising an end-side recommendation model deployed in the terminal device and a cloud-side recommendation model deployed in the cloud server, and the relative recommendation matching degree indicating a relative recommendation effect of the plurality of recommendation models on the user feature data; and
recommending to the terminal device based on the matched recommendation model.
These additional elements are described at a high level in Applicant’s specification without any meaningful detail about their structure or configuration. As such, these computer-related limitations are not found to be sufficient to integrate the abstract idea into a practical application. Claims 1 and 11 specifying that the abstract idea is executed in a computer environment merely indicates a field of use in which to apply the abstract idea because this requirement merely limits the claims to the computer field, i.e., to execution on a generic computer. As such, under Prong Two of Step 2A of the Alice/Mayo test, when considered both individually and as a whole, the limitations of claims 1 and 11 are not indicative of integration into a practical application (Step 2A, Prong Two: NO).
Since claims 1 and 11 recite an abstract idea and fail to integrate the abstract idea into a practical application, claims 1 and 11 are “directed to” an abstract idea (Step 2A: YES). Accordingly, the judicial exception is not integrated into a practical application.
Next, under Step 2B, examiners should evaluate additional elements individually and in combination to determine whether they provide an inventive concept (i.e., whether the additional elements amount to significantly more than the exception itself). In this case, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Returning to representative claims 1 and 11, taken individually or as a whole the additional elements of claims 1 and 11 amount to no more than mere instructions to apply the exception using a generic computer and/or no more than a general link to a technological environment. For the same reason these elements are not sufficient to provide an inventive concept. Therefore when considering the additional elements alone, and in combination, there is no inventive concept in the claim, and thus the claim is not patent eligible (Step 2B: NO).
Dependent claims 2-5 and 13-21, when analyzed as a whole, are held to be patent ineligible under 35 U.S.C. 101 because they do not add “significantly more” to the abstract idea. As for dependent claims 3-5, 14-17, and 19, these claims recite limitations that further define the same abstract idea noted in independent claims 1 and 11, and do not recite any additional elements other than what is disclosed in independent claims 1 and 11. Therefore, claims 3-5, 14-17, and 19 are considered patent ineligible for the reasons given above.
As for dependent claims 2 and 20-21, these claims recite limitations that further define the abstract idea noted in independent claims 1 and 11. Additionally, they recite the following additional limitations:
inputting the user feature data into a controller to select the matched recommendation model;
obtaining the user real-time feature data from a controller to perform preference processing to obtain a preference processing result;
The additional elements of a controller and performing preference processing are all recited at a high level of generality such that they amount to no more than instructions to apply the judicial exception in a generic technological environment. Even in combination, these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself. Accordingly, under the Alice/Mayo test, claims 1-5, 11, and 13-21 are ineligible.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3-5, 11, 14, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over U.S Patent Application No. 2023/0040678 A1 to Karlin et al., hereinafter Karlin, in view of U.S Patent Application No. 2023/0036623 A1 to Todasco et al., hereinafter Todasco.
Regarding Claim 1, Karlin discloses A system for edge-cloud collaborative recommendation, comprising ([Fig. 4][0048] server 422 and user terminal 424; see [0041-0042]; [Fig. 6]):
a terminal device and a cloud server, wherein the cloud server is arranged for ([Fig. 4]; [0048] server 422 and user terminal 424… server operations may be performed by cloud components 410):
obtaining user feature data of the terminal device ([Fig. 2][Fig. 5-6]; [0068-0069] receiving a user preference for content recommendations from a user; [0100] participants can input desired criteria (e.g., price, features of the products, specified providers, etc.));
selecting, based on a relative recommendation matching degree (confidence) between a plurality of recommendation models and the user feature data, a matched recommendation model from the plurality of recommendation models, the plurality of recommendation models comprising a first recommendation model and a cloud-side recommendation model deployed in the cloud server, and the relative recommendation matching degree indicating a relative recommendation effect (accuracy) of the plurality of recommendation models on the user feature data ([Figs. 3 and 4][Fig. 6]; [0100] selecting a machine learning model for matching user-supplied criteria… for each determination, the reverse recommendation system may select the machine learning model (e.g., from the plurality of machine learning models) that the system uses to generate a recommendation; [0101-0102] determining an amount of data including a confidence that the model accurately determines the determination, and selecting a machine learning model from a plurality of machine learning models based on the amount of data (e.g., the plurality of machine learning models described in FIG. 3); see [Fig. 3][0044] if information about a user or information used to interpret user-selected criteria is sparse, the system selects to use a machine learning model that provides more accuracy in data-sparse environments; [0046] model 380 determines which of models 304, 306, 310, 330, and 360 is the most accurate based on the amount of data used for a given determination to generate an output, and system 300 generates a recommendation based on the output; [0054-0059] cloud components 410 include a machine learning model trained by the system to determine a recommendation (Note: a confidence of a model (Karlin [0100-0102]) is comparable to a relative recommendation matching degree, and accuracy of a model (Karlin [0100-0102]) is comparable to a relative recommendation effect)); and
recommending to the terminal device based on the matched recommendation model ([Fig. 6]; [0102-0106] determine a criterion for content recommendations for the user by generating a first feature input for a first machine learning model based on the user preference and the user profile and inputting the first feature input into the first machine learning model to receive the criterion… and determining a recommendation based on the output from the machine learning model, such as an output that indicates that a criterion matches a content attribute… the system may generate for display a recommendation to the user; see [0034][Fig. 2]; [0047]);
Karlin discloses wherein the plurality of recommendation models comprises a first recommendation model and a cloud-side recommendation model deployed in the cloud server (Karlin [0044-0046]). However, Karlin does not explicitly teach wherein a first recommendation model is an end-side model deployed in the terminal device.
However, in the field of providing recommendations/predictions based on user activity data using machine learning (see at least Todasco [abstract][0042]), Todasco, on the other hand, teaches wherein a first recommendation model is an end-side model deployed in the terminal device ([Fig. 1]; [0041] Edge compute 130 includes ML models 132, which take user detections 134, location data 136, and/or edge user data 124, and may make a prediction about an interest or contextually relevant data for the user).
The steps of Todasco are applicable to the system of Karlin, as they share characteristics and capabilities, namely, they are directed to machine-learning based recommendation/prediction based on user activity data. It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation/prediction system as taught by Karlin, to include wherein a first recommendation model is an end-side model deployed in the terminal device, as taught by Todasco. One of ordinary skill in the art at the time of filing would have been motivated to expand the recommendation/prediction system of Karlin in order to provide communication with client devices quickly and with low data loading times, latencies, network communications and/or bandwidth usage (Todasco, [0038-0047]).
Regarding Claim 3, Karlin in view of Todasco teaches the system of claim 1.
Karlin further discloses wherein the cloud server is further arranged for: inputting the user feature data into the matched recommendation model to obtain a recommendation result ([Fig. 6]; [0102-0106] determine a criterion for content recommendations for the user by generating a first feature input for a first machine learning model based on the user preference and the user profile and inputting the first feature input into the first machine learning model to receive the criterion… and determining a recommendation based on the output from the machine learning model).
Regarding Claim 4, Karlin in view of Todasco teaches the system of claim 1.
Karlin further discloses wherein the user feature data comprises user real-time feature data and user historical feature data of an application ([0053] cloud components 410 store user data that the system has collected about the user through prior interactions, both actively and passively; [0061] the system receives user data via a microservice comprising a collection of applications that each collect one or more of a plurality of variables… the system receives user data files in real-time or near real-time), and the cloud server is further arranged for:
inputting the user real-time feature data and the user historical feature data to obtain a real-time recommendation result of the application ([Fig. 6]; [0102-0106] determine a criterion for content recommendations for the user by generating a first feature input for a first machine learning model based on the user preference and the user profile and inputting the first feature input into the first machine learning model to receive the criterion… and determining a recommendation based on the output from the machine learning model).
Karlin discloses inputting user real-time feature data and user historical feature data to obtain a real-time recommendation result of the application (see at least Karlin [Fig. 6][0102-0106]). However, Karlin does not explicitly teach inputting into the end-side recommendation model.
Todasco, on the other hand, teaches inputting into the end-side recommendation model ([0041] ML models 132 may take, as input, user detections 134, location data 136, and/or edge user data 124, and may make a prediction about an interest or contextually relevant data for the user).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation/prediction system as taught by Karlin, to include inputting into the end-side recommendation model, as taught by Todasco, for the same reasons discussed above with respect to claim 1.
Regarding Claim 5, Karlin in view of Todasco teaches the system of claim 1.
Karlin further discloses wherein the user feature data comprises user historical feature data of an application ([0053] cloud components 410 store user data that the system has collected about the user through prior interactions, both actively and passively; [0061] the system receives user data via a microservice comprising a collection of applications that each collect one or more of a plurality of variables), and
the cloud server is further arranged for: inputting the user historical feature data into the cloud-side recommendation model to obtain a recommendation result of the application ([Fig. 6]; [0102-0106] determine a criterion for content recommendations for the user by generating a first feature input for a first machine learning model based on the user preference and the user profile and inputting the first feature input into the first machine learning model to receive the criterion… and determining a recommendation based on the output from the machine learning model).
Claim 11 is directed to a method. The claim discloses substantially the same limitations as claim 1, except claim 1 is directed to a machine while claim 11 is directed to a process. The added element of A method for edge-cloud collaborative recommendation is taught by Kumar (Kumar: [0084-0088]). Therefore, claim 11 is rejected for the same rationale over the prior art cited in claim 1.
Regarding Claim 14, Karlin in view of Todasco teaches the system of claim 1.
Karlin further discloses wherein a recommendation model returns a recommendation result containing at least one recommendation object ([Fig. 6]; [0101-0102] selecting a machine learning model from a plurality of machine learning models based on the amount of data (e.g., the plurality of machine learning models described in FIG. 3); see [Fig. 1][0023] user interface for generating a plurality of recommendations; [Fig. 3][0046] model 380 determines which of models 304, 306, 310, 330, and 360 is the most accurate… and system 300 generates a recommendation based on the output; [0047] recommendations for goods and/or services may be displayed (e.g., on a screen of a display device) as media that is consumed by a user).
Regarding Claim 17, Karlin in view of Todasco teaches the system of claim 1.
Karlin further discloses wherein the relative recommendation matching degrees are the plurality of matching degrees of the plurality of recommendation models or relations between the plurality of matching degrees ([Fig. 3][0044] if information about a user or information used to interpret user-selected criteria is sparse, the system selects to use a machine learning model that provides more accuracy in data-sparse environments; [0046] model 380 determines which of models 304, 306, 310, 330, and 360 is the most accurate based on the amount of data used for a given determination to generate an output, and system 300 generates a recommendation based on the output).
Claim(s) 2 is rejected under 35 U.S.C. 103 as being unpatentable over Karlin in view of Todasco, and further in view of U.S Patent Application No. 2020/0159856 A1 to Mital et al., hereinafter Mital.
Regarding Claim 2, Karlin in view of Todasco teaches the system of claim 1.
Karlin further discloses wherein the cloud server is further arranged for: inputting the user feature data into a controller to select the matched recommendation model ([0033] in response to a user input of criteria… the system may transmit a request to a remote source (e.g., cloud component 410); [0044] At model 380, system 300 may receive outputs from one or more of models 304, 306, 310, 330, and 360. Model 380 may determine which of the outputs to use for a determination used to generate a recommendation… if information about a user or information used to interpret user-selected criteria is sparse, the system may select to use a machine learning model that provides more accuracy in data-sparse environments),
Note: A “controller” has been interpreted as a trained model, per Applicant’s specification ([Page 11 Lines 5-29]).
Karlin discloses inputting user feature data into a controller to select the matched recommendation model ([0033][0044]). However, Karlin in view of Todasco does not explicitly teach wherein the controller is determined according to a model selection data set, and the model selection data set is created based on training data of the plurality of recommendation models.
However, in the field of providing recommendations for models based on user interests (see at least Mital [abstract][0031-0036]), Mital, on the other hand, teaches wherein the controller is determined according to a model selection data set, and the model selection data set is created based on training data of the plurality of recommendation models ([0035] the AI model recommender 116 causes the search engine 102 to display an AI recommender interface element 118 displaying various AI models that might be helpful to expand availability of search results to the user; [0037] the AI recommender may be modified itself using AI… by identifying which recommended AI models the user selects and collecting collaborative information across multiple different users… to refine the ability of the AI recommender to recommend AI models that are of interest).
The steps of Mital are applicable to the system of Karlin in view of Todasco, as they share characteristics and capabilities, namely, they are directed to machine learning-based content recommendations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the ML-based recommendation system as taught by Karlin in view of Todasco, to include wherein the controller is determined according to a model selection data set, and the model selection data set is created based on training data of the plurality of recommendation models, as taught by Mital. One of ordinary skill in the art at the time of filing would have been motivated to expand the system of Karlin in view of Todasco in order to identify available Ai models that might be helpful to expand availability of search results to the user by providing contextual recommendations for models (Mital, [0035]).
Claim(s) 13 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Karlin in view of Todasco, and further in view of U.S Patent Application No. 2021/0144233 A1 to Govan et al., hereinafter Govan.
Regarding Claim 13, Karlin in view of Todasco teaches the system of claim 1.
Karlin further discloses wherein the cloud-side recommendation model includes a cloud-side first recommendation model and a cloud-side second recommendation model ([0046] model 380 determines which of models 304, 306, 310, 330, and 360 is the most accurate based on the amount of data used for a given determination to generate an output, and system 300 generates a recommendation based on the output; [0054-0059] cloud components 410 include a machine learning model trained by the system to determine a recommendation; see [0038] the system may include one or more machine learning models).
Todasco, on the other hand, teaches wherein the end-side recommendation model is an end-side real-time recommendation model ([Fig. 1]; [0041] Edge compute 130 includes ML models 132, which take user detections 134, location data 136, and/or edge user data 124, and may make a prediction about an interest or contextually relevant data for the user… User detections 134 may also include one or more monitored activities of the user at or associated with the location).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation/prediction system as taught by Karlin, to include wherein the end-side recommendation model is an end-side real-time recommendation model, as taught by Todasco, for the same reasons discussed above with respect to claim 1.
However, Karlin in view of Todasco does not explicitly teach a cloud-side recommendation model comprising a cloud-side time-share recommendation model and a cloud-side real-time recommendation model, and real-time performance of the cloud-side time-share recommendation model is lower than real-time performance of the cloud-side real-time recommendation model.
However, in the field of real-time personalization of content recommendations (See at least Govan [abstract]), Govan, on the other hand, teaches a cloud-side recommendation model comprising a cloud-side time-share recommendation model and a cloud-side real-time recommendation model, and real-time performance of the cloud-side time-share recommendation model is lower than real-time performance of the cloud-side real-time recommendation model ([0048] models 202 include various specialized recommenders, including time series analysis and real-time mood analysis; [0050] user-to-user similarity models can generate predictive outcomes based on user profile information… time series analysis evaluates time information associated with resource consumption, and real-time mood analysis can evaluate a user's present intention or state of mind based on real-time event data).
Note: A cloud-side time-share recommendation model has been interpreted as a recommendation operating on a cloud server and utilizing historical data, per Applicant’s specification ([page 9 paragraph 1]). Since the user-to-user model of Govan operates on time series (historical) data, and the content similarity model operates on data with respect to what a user is likely to want to see next, performance of the time-share model is with respect to historical data, and accordingly performance with respect to real-time data is lower.
The steps of Govan are applicable to the system of Karlin in view of Todasco, as they share characteristics and capabilities, namely, they are directed to machine learning-based content recommendations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the ML-based recommendation system as taught by Karlin in view of Todasco, to include a cloud-side recommendation model comprising a cloud-side time-share recommendation model and a cloud-side real-time recommendation model, and real-time performance of the cloud-side time-share recommendation model is lower than real-time performance of the cloud-side real-time recommendation model, as taught by Govan. One of ordinary skill in the art at the time of filing would have been motivated to expand the system of Karlin in view of Todasco in order to provide content personalization models allowing for a combination of offline factors and real-time behavior, improving recommendation personalization effects (Govan, [0002-0005]).
Claim 18 recites a method comprising substantially similar limitations as claim 13. All limitations as recited have been analyzed and rejected with respect to claim 13, and do not introduce any additional narrowing of the scopes of the claims as analyzed. Therefore, Claim 18 is rejected for the same rationale over the prior art cited in claim 13.
Regarding Claim 19, Karlin in view of Todasco and Govan teaches the method of claim 18.
Karlin further discloses wherein the user feature data comprise: user historical feature data ([0053] cloud components 410 store user data that the system has collected about the user through prior interactions, both actively and passively),
the method further comprises: for the cloud-side recommendation model, obtaining the user historical feature data of the application from the cloud server to perform preference processing to obtain a preference processing result ([Fig. 4] operations described as being performed by server 422 may be performed by cloud components 410; [0061] the system receives user data via a microservice comprising a collection of applications that each collect one or more of a plurality of variables… the system receives user data files in real-time or near real-time; [Fig. 5]; [0068-0070] using one or more components described in Fig. 4, receiving a user preference for content recommendations and a user profile, and comparing the user preference to the user profile to determine a criterion for content recommendations for the user);
inputting the preference processing result into the cloud-side recommendation model to obtain a recommendation result ([Fig. 6]; [0102-0106] determine a criterion for content recommendations for the user by generating a first feature input for a first machine learning model based on the user preference and the user profile and inputting the first feature input into the first machine learning model to receive the criterion… and determining a recommendation based on the output from the machine learning model).
However, Karlin in view of Todasco does not explicitly teach obtaining data for the cloud-side time-share recommendation model; and inputting into the cloud-side time-share recommendation model to obtain a time-share recommendation result.
Govan, on the other hand, teaches obtaining data for the cloud-side time-share recommendation model ([0027] data from people stream feeds People Repository 320, Resources Repository 322, and Events Repository 324… repositories are then made available as output of data pipeline 200, to be queried by one or more models 202; [0048-0050] time series analysis model); and
inputting into the cloud-side time-share recommendation model to obtain a time-share recommendation result ([0027] repositories are then made available as output of data pipeline 200, to be queried by one or more models 202; [0045-0046] results of models are combined by ranking and optimization component 204 to yield result 206; [0048-0050] time series analysis model).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the ML-based recommendation system as taught by Karlin in view of Todasco, to include obtaining data for the cloud-side time-share recommendation model; and inputting into the cloud-side time-share recommendation model to obtain a time-share recommendation result, as taught by Govan, for the same reasons discussed above with respect to claim 13.
Claim(s) 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Karlin in view of Todasco, and further in view of U.S Patent Application No. 2022/0092446 A1 to Wen et al., hereinafter Wen.
Regarding Claim 15, Karlin in view of Todasco teaches the system of claim 14.
Karlin further discloses wherein the at least one recommendation object is a recommendation object satisfying a recommendation condition ([Fig. 6]; [0100] selecting a machine learning model for matching user-supplied criteria… for each determination, the reverse recommendation system may select the machine learning model (e.g., from the plurality of machine learning models) that the system uses to generate a recommendation; see [Fig. 3][0044-0046]).
Karlin discloses recommendation objects satisfying a recommendation condition (see at least Karlin [Fig. 6][0100][Fig. 3][0044-0046])). However, Karlin in view of Todasco does not explicitly teach a recommendation object cut from a candidate recommendation object list.
However, in the field of providing product recommendations using multiple machine learning models (see at least Wen [abstract][0018][0033-0034]), Wen, on the other hand, teaches a recommendation object cut from a candidate recommendation object list ([0097-0098] performing de-duplication and sorting processing on the at least one first recommendation result, to generate a second recommendation result).
The steps of Wen are applicable to the system of Karlin in view of Todasco, as they share characteristics and capabilities, namely, they are directed to machine learning-based recommendations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the ML-based recommendation system as taught by Karlin in view of Todasco, to include a recommendation object cut from a candidate recommendation object list, as taught by Wen. One of ordinary skill in the art at the time of filing would have been motivated to expand the system of Karlin in view of Todasco in order to allow users to better perceive recommendation logic and strategy, and provide explanations for recommendation results (Wen, [0017]).
Regarding Claim 16, Karlin in view of Todasco teaches the system of claim 1.
Karlin further discloses wherein the relative recommendation effect is obtained based on comparing, by the plurality of recommendation models ([0100-0102] selecting a machine learning model for matching user-supplied criteria… selecting a machine learning model from a plurality of machine learning models based on the amount of data (e.g., the plurality of machine learning models described in FIG. 3); [Fig. 3][0044-0046] model 380 determines which of models 304, 306, 310, 330, and 360 is the most accurate based on the amount of data used for a given determination to generate an output). However Karlin in view of Todasco does not explicitly teach comparing a plurality of recommendation results of the user feature data.
Wen, on the other hand, teaches comparing a plurality of recommendation results of the user feature data ([0045-0046] the first recommendation result information may include the ranking of commodities with different recommendation probabilities calculated according to the recommendation algorithm and corresponding commodity information; [0061-0062] de-duplication and sorting processing information includes the ranking of each commodity or service in the first recommendation results corresponding to different recommendation algorithms).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the ML-based recommendation system as taught by Karlin in view of Todasco, to include comparing a plurality of recommendation results of the user feature data, for the same reasons discussed above with respect to claim 1.
Claim(s) 20 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Karlin in view of Todasco and Govan, and further in view of Mital.
Regarding Claim 20, Karlin in view of Todasco and Govan teaches the method of claim 18.
Karlin further discloses wherein the user feature data comprise: user historical feature data and user real-time feature data ([0053] cloud components 410 store user data that the system has collected about the user through prior interactions, both actively and passively; [0061] the system receives user data via a microservice comprising a collection of applications that each collect one or more of a plurality of variables… the system receives user data files in real-time or near real-time),
the method further comprises: for the cloud-side recommendation model, obtaining the user historical feature data of the application from the cloud server, and obtaining the user real-time feature data to perform preference processing to obtain a preference processing result ([Fig. 4] operations described as being performed by server 422 may be performed by cloud components 410; [0061] the system receives user data via a microservice comprising a collection of applications that each collect one or more of a plurality of variables… the system receives user data files in real-time or near real-time; [Fig. 5]; [0068-0070] using one or more components described in Fig. 4, receiving a user preference for content recommendations and a user profile, and comparing the user preference to the user profile to determine a criterion for content recommendations for the user);
inputting the preference processing result into the cloud-side recommendation model to obtain a recommendation result ([Fig. 6]; [0102-0106] determine a criterion for content recommendations for the user by generating a first feature input for a first machine learning model based on the user preference and the user profile and inputting the first feature input into the first machine learning model to receive the criterion… and determining a recommendation based on the output from the machine learning model).
Govan, on the other hand, teaches obtaining data for the cloud-side real-time recommendation model ([0027] data from people stream feeds People Repository 320, Resources Repository 322, and Events Repository 324… repositories are then made available as output of data pipeline 200, to be queried by one or more models 202; [0048-0050] Real-time mood analysis model); and
inputting into the cloud-side real-time recommendation model to obtain a real-time recommendation result ([0027] repositories are then made available as output of data pipeline 200, to be queried by one or more models 202; [0045-0046] results of models are combined by ranking and optimization component 204 to yield result 206; [0048-0050] Real-time mood analysis model).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the ML-based recommendation system as taught by Karlin in view of Todasco, to include obtaining data for the cloud-side real-time recommendation model; and inputting into the cloud-side real-time recommendation model to obtain a real-time recommendation result, as taught by Govan, for the same reasons discussed above with respect to claim 13.
However, Karlin in view of Todasco and Govan does not explicitly teach obtaining real-time data from a controller.
Mital, on the other hand, teaches obtaining real-time data from a controller ([0035] AI model recommender uses gathered user search information to identify available AI models that might be helpful to expand availability of search results to the user).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the ML-based recommendation system as taught by Karlin in view of Todasco and Govan, to include obtaining real-time data from a controller, as taught by Mital, for the same reasons discussed above with respect to claim 2.
Regarding Claim 21, Karlin in view of Todasco and Govan teaches the method of claim 18.
Karlin further discloses wherein the user feature data comprise: user historical feature data and user real-time feature data ([0053] cloud components 410 store user data that the system has collected about the user through prior interactions, both actively and passively; [0061] the system receives user data via a microservice comprising a collection of applications that each collect one or more of a plurality of variables… the system receives user data files in real-time or near real-time),
the method further comprises: for the first recommendation model, obtaining the user historical feature data of the application from the cloud server, and obtaining the user real-time feature data to perform preference processing to obtain a preference processing result ([Fig. 4] operations described as being performed by server 422 may be performed by cloud components 410; [0061] the system receives user data via a microservice comprising a collection of applications that each collect one or more of a plurality of variables… the system receives user data files in real-time or near real-time; [Fig. 5]; [0068-0070] using one or more components described in Fig. 4, receiving a user preference for content recommendations and a user profile, and comparing the user preference to the user profile to determine a criterion for content recommendations for the user);
inputting the preference processing result into the first recommendation model to obtain a real-time recommendation result ([Fig. 6]; [0102-0106] determine a criterion for content recommendations for the user by generating a first feature input for a first machine learning model based on the user preference and the user profile and inputting the first feature input into the first machine learning model to receive the criterion… and determining a recommendation based on the output from the machine learning model; see [0046] model 380 determines which of models 304, 306, 310, 330, and 360 is the most accurate based on the amount of data used for a given determination to generate an output , and system 300 generates a recommendation based on the output).
Todasco, on the other hand, teaches obtaining feature data for the end-side recommendation model ([Fig. 1]; [0041] Edge compute 130 includes ML models 132, which take user detections 134, location data 136, and/or edge user data 124, and may make a prediction about an interest or contextually relevant data for the user); and
inputting into the end-side recommendation model ([Fig. 1]; [0041] Edge compute 130 includes ML models 132, which take user detections 134, location data 136, and/or edge user data 124, and may make a prediction about an interest or contextually relevant data for the user).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify the recommendation/prediction system as taught by Karlin, to include obtaining feature data for the end-side recommendation model, and inputting into the end-side recommendation model, as taught by Todasco, for the same reasons discussed above with respect to claim 1.
However, Karlin in view of Todasco and Govan does not explicitly teach obtaining real-time data from a controller.
Mital, on the other hand, teaches obtaining real-time data from a controller ([0035] AI model recommender uses gathered user search information to identify available AI models that might be helpful to expand availability of search results to the user).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the ML-based recommendation system as taught by Karlin in view of Todasco and Govan, to include obtaining real-time data from a controller, as taught by Mital, for the same reasons discussed above with respect to claim 2.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S Patent Application No. 2021/0157664 A1 to Panda – A method and system for selecting a recommender model matching user requirements, and generating a recommendation based on the selected recommender model.
NPL Reference U “EdgeRec: Recommender System on Edge in Mobile Taobao” (see Notice of References Cited) teaching a recommender system including a cloud-to-edge framework, where recommendations match real-time changes of user’s preference on the edge device.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZACHARY R DONAHUE whose telephone number is (571)272-5850. The examiner can normally be reached M-F 8a-5p.
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 at (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 published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ZACHARY RYAN DONAHUE/Examiner, Art Unit 3689
/KELLY S. CAMPEN/Primary Examiner, Art Unit 3691
Prosecution Insights