DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to the Application filed on 6/6/2023. Claims 1-20 are pending in the case. Claims 1, 8, and 14 are independent claims.
Claim Rejections - 35 U.S.C. § 102
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3, 5, 8-10, 12, 14-17, and 19 are rejected under 35 U.S.C. § 102(a)(1) as being anticipated by Ashrafzadeh et al. (US 2022/0318647 A1, hereinafter Ashrafzadeh).
As to independent claim 1, Ashrafzadeh discloses a computer-implemented method for training and executing machine learning models based on on-demand features, the computer-implemented method comprising:
receiving a command comprising a specification of a set of features for a machine learning model, the set of features comprising at least an on-demand feature (“The process of the streaming manager can be responsive to receiving an initial request for a scoring service or similar machine-learning model prediction. The request can identify the machine-learning model (e.g., a scoring service) as well as the features to utilized in generating the prediction (e.g., a score) (Block 301). Any number and combination of features can be identified tied to any number of entities (e.g., any number and combination of data fields of data structures). The combination of features is specific to the tenant resources available to the tenant application that generates the request,” paragraph 0041 lines 3-13), the specification for the on-demand feature identifying a feature function, wherein the feature function is stored in a data asset service (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11);
executing the command comprising, storing an association between the machine learning model and the set of features (“the streaming manager may only handle streaming requests and does not have to distinguish between the streaming and on-demand requests. If the received request is an on-demand request, then the process can initiate the machine-learning model for the request and prepare the machine-learning model to execute on the identified data (e.g., generate a score based on the identified features) (Block 307),” paragraph 0042 lines 4-10);
generating a trained machine learning model by adjusting parameters of the machine learning model based on results of execution of the machine learning model using samples of a training dataset (“the machine-learning model may be trained or the training updated based on the identified features and/or related information (e.g., for the scoring service) (Block 309),” paragraph 0042 lines 11-14), wherein execution of the machine learning model during training determines values of the on-demand feature by invoking the feature function stored in the data asset service (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – the “feature function” is continuously invoked as long as the subscription is active);
deploying the trained machine learning model in a target system (“the streaming manager may only handle streaming requests and does not have to distinguish between the streaming and on-demand requests. If the received request is an on-demand request, then the process can initiate the machine-learning model for the request and prepare the machine-learning model to execute on the identified data (e.g., generate a score based on the identified features) (Block 307),” paragraph 0042 lines 4-10); and
executing the trained machine learning model in the target system (“The features are then applied or processed by the machine-learning model to generate a prediction (e.g., a score) (Block 311),” paragraph 0043 lines 20-22), wherein executing the trained machine learning model deployed in the target system determines values of the on-demand feature by invoking the feature function stored in the data asset service (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – the “feature function” is continuously invoked as long as the subscription is active).
As to dependent claim 2, Ashrafzadeh further discloses a method wherein determining values of the on-demand feature by invoking the feature function stored in the data asset service ensures that a set of instructions executed for evaluating the on-demand feature during training of the machine learning model matches the set of instructions executed for evaluating the on-demand feature during execution of the trained machine learning model that is deployed in the target system (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – the same “feature function” is continuously invoked and monitoring the same identified features of the request as long as the subscription is active).
As to dependent claim 3, Ashrafzadeh further discloses a method wherein the on-demand feature is associated with an end point of the data asset service, wherein invoking the feature function stored in the data asset service comprises sending a request to an end point of the data asset service (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – the “feature function” is continuously invoked as long as the subscription is active).
As to dependent claim 5, Ashrafzadeh further discloses a method wherein the set of features further comprises one of more batch features, wherein a value of a batch feature is stored in a feature store, wherein determining the value of the batch feature comprises accessing the value of the batch feature from the feature store (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – a “set of records” is a “batch feature”).
As to independent claim 8, Ashrafzadeh discloses a non-transitory computer readable storage medium (“NON-TRANSITORY MACHINE-READABLE STORAGE MEDIA,” figure 5A part 526) comprising stored instructions that when executed by one or more computer processors cause the one or more computer processors to:
receive a command comprising a specification of a set of features for a machine learning model, the set of features comprising at least an on-demand feature (“The process of the streaming manager can be responsive to receiving an initial request for a scoring service or similar machine-learning model prediction. The request can identify the machine-learning model (e.g., a scoring service) as well as the features to utilized in generating the prediction (e.g., a score) (Block 301). Any number and combination of features can be identified tied to any number of entities (e.g., any number and combination of data fields of data structures). The combination of features is specific to the tenant resources available to the tenant application that generates the request,” paragraph 0041 lines 3-13), the specification for the on-demand feature identifying a feature function, wherein the feature function is stored in a data asset service (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11);
execute the command comprising, storing an association between the machine learning model and the set of features (“the streaming manager may only handle streaming requests and does not have to distinguish between the streaming and on-demand requests. If the received request is an on-demand request, then the process can initiate the machine-learning model for the request and prepare the machine-learning model to execute on the identified data (e.g., generate a score based on the identified features) (Block 307),” paragraph 0042 lines 4-10);
generate a trained machine learning model by adjusting parameters of the machine learning model based on results of execution of the machine learning model using samples of a training dataset (“the machine-learning model may be trained or the training updated based on the identified features and/or related information (e.g., for the scoring service) (Block 309),” paragraph 0042 lines 11-14), wherein execution of the machine learning model during training determines values of the on-demand feature by invoking the feature function stored in the data asset service (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – the “feature function” is continuously invoked as long as the subscription is active);
deploy the trained machine learning model in a target system (“the streaming manager may only handle streaming requests and does not have to distinguish between the streaming and on-demand requests. If the received request is an on-demand request, then the process can initiate the machine-learning model for the request and prepare the machine-learning model to execute on the identified data (e.g., generate a score based on the identified features) (Block 307),” paragraph 0042 lines 4-10); and
execute the trained machine learning model in the target system (“The features are then applied or processed by the machine-learning model to generate a prediction (e.g., a score) (Block 311),” paragraph 0043 lines 20-22), wherein executing the trained machine learning model deployed in the target system determines values of the on-demand feature by invoking the feature function stored in the data asset service (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – the “feature function” is continuously invoked as long as the subscription is active).
As to dependent claim 9, Ashrafzadeh further discloses a medium wherein instructions for determining values of the on-demand feature comprise instructions for invoking the feature function stored in the data asset service ensures that a set of instructions executed for evaluating the on-demand feature during training of the machine learning model matches the set of instructions executed for evaluating the on-demand feature during execution of the trained machine learning model that is deployed in the target system (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – the same “feature function” is continuously invoked and monitoring the same identified features of the request as long as the subscription is active).
As to dependent claim 10, Ashrafzadeh further discloses a medium wherein the on-demand feature is associated with an end point of the data asset service, wherein invoking the feature function stored in the data asset service comprises sending a request to an end point of the data asset service (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – the “feature function” is continuously invoked as long as the subscription is active).
As to dependent claim 12, Ashrafzadeh further discloses a medium wherein the set of features further comprises one of more batch features, wherein a value of a batch feature is stored in a feature store, wherein determining the value of the batch feature comprises accessing the value of the batch feature from the feature store (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – a “set of records” is a “batch feature”).
As to independent claim 14, Ashrafzadeh discloses a computer system comprising:
one or more computer processors (“PROCESSOR(S),” figure 5A part 522); and
a non-transitory computer readable storage medium (“NON-TRANSITORY MACHINE-READABLE STORAGE MEDIA,” figure 5A part 526) comprising stored instructions that when executed by the one or more computer processors cause the one or more computer processors to
receive a command comprising a specification of a set of features for a machine learning model, the set of features comprising at least an on-demand feature (“The process of the streaming manager can be responsive to receiving an initial request for a scoring service or similar machine-learning model prediction. The request can identify the machine-learning model (e.g., a scoring service) as well as the features to utilized in generating the prediction (e.g., a score) (Block 301). Any number and combination of features can be identified tied to any number of entities (e.g., any number and combination of data fields of data structures). The combination of features is specific to the tenant resources available to the tenant application that generates the request,” paragraph 0041 lines 3-13), the specification for the on-demand feature identifying a feature function, wherein the feature function is stored in a data asset service (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11);
execute the command comprising, storing an association between the machine learning model and the set of features (“the streaming manager may only handle streaming requests and does not have to distinguish between the streaming and on-demand requests. If the received request is an on-demand request, then the process can initiate the machine-learning model for the request and prepare the machine-learning model to execute on the identified data (e.g., generate a score based on the identified features) (Block 307),” paragraph 0042 lines 4-10);
generate a trained machine learning model by adjusting parameters of the machine learning model based on results of execution of the machine learning model using samples of a training dataset (“the machine-learning model may be trained or the training updated based on the identified features and/or related information (e.g., for the scoring service) (Block 309),” paragraph 0042 lines 11-14), wherein execution of the machine learning model during training determines values of the on-demand feature by invoking the feature function stored in the data asset service (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – the “feature function” is continuously invoked as long as the subscription is active);
deploy the trained machine learning model in a target system (“the streaming manager may only handle streaming requests and does not have to distinguish between the streaming and on-demand requests. If the received request is an on-demand request, then the process can initiate the machine-learning model for the request and prepare the machine-learning model to execute on the identified data (e.g., generate a score based on the identified features) (Block 307),” paragraph 0042 lines 4-10); and
execute the trained machine learning model in the target system (“The features are then applied or processed by the machine-learning model to generate a prediction (e.g., a score) (Block 311),” paragraph 0043 lines 20-22), wherein executing the trained machine learning model deployed in the target system determines values of the on-demand feature by invoking the feature function stored in the data asset service (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – the “feature function” is continuously invoked as long as the subscription is active).
As to dependent claim 15, Ashrafzadeh further discloses a system wherein instructions for determining values of the on-demand feature comprise instructions for invoking the feature function stored in the data asset service ensures that a set of instructions executed for evaluating the on-demand feature during training of the machine learning model matches the set of instructions executed for evaluating the on-demand feature during execution of the trained machine learning model that is deployed in the target system (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – the same “feature function” is continuously invoked and monitoring the same identified features of the request as long as the subscription is active).
As to dependent claim 16, Ashrafzadeh further discloses a system wherein the on-demand feature is associated with an end point of the data asset service (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – the “feature function” is continuously invoked as long as the subscription is active).
As to dependent claim 17, Ashrafzadeh further discloses a system wherein invoking the feature function stored in the data asset service comprises sending a request to an end point of the data asset service (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – the “feature function” is continuously invoked as long as the subscription is active).
As to dependent claim 19, Ashrafzadeh further discloses a system wherein the set of features further comprises one of more batch features, wherein a value of a batch feature is stored in a feature store, wherein determining the value of the batch feature comprises accessing the value of the batch feature from the feature store (“the process subscribes to events for the identified features of the request (Block 305). The subscription can be via any event management system such as an event management system of a multi-tenant system that hosts the tenant application generating the request as well as the tenant data to which the features are associated. For example, if the request identified a set of records in a tenant database as the set of features, then the subscription for events may monitor CRUDs of these features (e.g., changes to records, data fields, data objects, or similar entities),” paragraph 0043 lines 2-11 – a “set of records” is a “batch feature”).
Claim Rejections - 35 U.S.C. § 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.
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 of this title, 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.
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 C.F.R. § 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 4, 11, and 18 are rejected under 35 U.S.C. § 103 as being unpatentable over Ashrafzadeh in view of Roy (“Function Pointers and Callbacks in C – An Odyssey,” 28 February 2012, https://www.opensourceforu.com/2012/02/function-pointers-and-callbacks-in-c-an-odyssey/).
As to dependent claim 4, the rejection of claim 1 is incorporated.
Ashrafzadeh does not appear to expressly teach a method herein the specification of the on-demand feature comprises a name of the feature function, zero or more arguments of the feature function, and an output of the feature function.
Roy teaches a method herein the specification of the on-demand feature comprises a name of the [] function, zero or more arguments of the [] function, and an output of the [] function (“void sig_handler(int signo, siginfo_t *si, void *ucontext)” page 3 example code line 10).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the feature function of Ashrafzadeh to comprise the specification of Roy. (1) The Examiner finds that the prior art included each claim element listed above, although not necessarily in a single prior art reference, with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. (2) The Examiner finds that one of ordinary skill in the art could have combined the elements as claimed by known software development methods, and that in combination, each element merely performs the same function as it does separately. (3) The Examiner finds that one of ordinary skill in the art would have recognized that the results of the combination were predictable, namely registering arbitrary functions for invocation by other modules (“In computer programming, a callback is a reference to executable code, or a piece of executable code, that is passed as an argument to other code. This allows a lower-level software layer to call a subroutine (or function) defined in a higher-level layer,” Roy page 2 section “A simple callback function” lines 2-4). Therefore, the rationale to support a conclusion that the claim would have been obvious is that the combining prior art elements according to known methods to yield predictable results to one of ordinary skill in the art. See MPEP § 2143(I)(A).
As to dependent claim 11, the rejection of claim 8 is incorporated.
Ashrafzadeh does not appear to expressly teach a medium herein the specification of the on-demand feature comprises a name of the feature function, zero or more arguments of the feature function, and an output of the feature function.
Roy teaches a medium herein the specification of the on-demand feature comprises a name of the [] function, zero or more arguments of the [] function, and an output of the [] function (“void sig_handler(int signo, siginfo_t *si, void *ucontext)” page 3 example code line 10).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the feature function of Ashrafzadeh to comprise the specification of Roy. (1) The Examiner finds that the prior art included each claim element listed above, although not necessarily in a single prior art reference, with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. (2) The Examiner finds that one of ordinary skill in the art could have combined the elements as claimed by known software development methods, and that in combination, each element merely performs the same function as it does separately. (3) The Examiner finds that one of ordinary skill in the art would have recognized that the results of the combination were predictable, namely registering arbitrary functions for invocation by other modules (“In computer programming, a callback is a reference to executable code, or a piece of executable code, that is passed as an argument to other code. This allows a lower-level software layer to call a subroutine (or function) defined in a higher-level layer,” Roy page 2 section “A simple callback function” lines 2-4). Therefore, the rationale to support a conclusion that the claim would have been obvious is that the combining prior art elements according to known methods to yield predictable results to one of ordinary skill in the art. See MPEP § 2143(I)(A).
As to dependent claim 18, the rejection of claim 14 is incorporated.
Ashrafzadeh does not appear to expressly teach a system herein the specification of the on-demand feature comprises a name of the feature function, zero or more arguments of the feature function, and an output of the feature function.
Roy teaches a system herein the specification of the on-demand feature comprises a name of the [] function, zero or more arguments of the [] function, and an output of the [] function (“void sig_handler(int signo, siginfo_t *si, void *ucontext)” page 3 example code line 10).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the feature function of Ashrafzadeh to comprise the specification of Roy. (1) The Examiner finds that the prior art included each claim element listed above, although not necessarily in a single prior art reference, with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. (2) The Examiner finds that one of ordinary skill in the art could have combined the elements as claimed by known software development methods, and that in combination, each element merely performs the same function as it does separately. (3) The Examiner finds that one of ordinary skill in the art would have recognized that the results of the combination were predictable, namely registering arbitrary functions for invocation by other modules (“In computer programming, a callback is a reference to executable code, or a piece of executable code, that is passed as an argument to other code. This allows a lower-level software layer to call a subroutine (or function) defined in a higher-level layer,” Roy page 2 section “A simple callback function” lines 2-4). Therefore, the rationale to support a conclusion that the claim would have been obvious is that the combining prior art elements according to known methods to yield predictable results to one of ordinary skill in the art. See MPEP § 2143(I)(A).
Claims 6-7, 13, and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over Ashrafzadeh in view of Sikka et al. (US 9269011 B1, hereinafter Sikka).
As to dependent claim 6, the rejection of claim 5 is incorporated.
Ashrafzadeh does not appear to expressly teach a method wherein the machine learning model is trained to predict a value based on user interactions of a user during a session, wherein the on-demand feature represents a value based on user actions performed during the session and the batch feature represents a value based on a user profile of the user.
Sikka teaches a method wherein the machine learning model is trained to predict a value based on user interactions of a user during a session (“the user may trigger context dependent recognition when upon entering the augmented reality application,” column 7 lines 53-54), wherein the on-demand feature represents a value based on user actions performed during the session (“the machine learning engine 618 can receive context data such as location input from a GPS sensor,” column 7 lines 11-12) and the batch feature represents a value based on a user profile of the user (“Moreover, the machine learning engine 618 can utilize system data 622 as well, such as an internal clock, calendar, apps, reminders, notes, tasks, user activities (e.g., user preferences, messages, user interactions, etc.), and other such input,” column 7 lines 23-27).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the features of Ashrafzadeh to comprise the features of Sikka. (1) The Examiner finds that the prior art included each claim element listed above, although not necessarily in a single prior art reference, with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. (2) The Examiner finds that one of ordinary skill in the art could have combined the elements as claimed by known software development methods, and that in combination, each element merely performs the same function as it does separately. (3) The Examiner finds that one of ordinary skill in the art would have recognized that the results of the combination were predictable, namely predicting based on both dynamic and static data (“the machine learning engine 618 can receive context data such as location input from a GPS sensor to determine that the user is at, or near, a park, for example. The machine learning engine 618 can also use additional context data such as imaging input (e.g., picture, video) from an imaging sensor (e.g., camera, facial recognition software) to determine that the user's context is with his family at the park and pointing the computing device toward downtown. Further, the machine learning engine 618 can use sound data (e.g., music, voice, speech, background noise) from an audio sensor to determine that the context is with friends at a concert. Moreover, the machine learning engine 618 can utilize system data 622 as well, such as an internal clock, calendar, apps, reminders, notes, tasks, user activities (e.g., user preferences, messages, user interactions, etc.), and other such input,” Sikka column 7 lines 11-27). Therefore, the rationale to support a conclusion that the claim would have been obvious is that the combining prior art elements according to known methods to yield predictable results to one of ordinary skill in the art. See MPEP § 2143(I)(A).
As to dependent claim 7, the rejection of claim 1 is incorporated.
Ashrafzadeh does not appear to expressly teach a method wherein the machine learning model is trained to predict a value based on attributes describing a moving object, wherein the on-demand feature represents a value based on a location of the moving object.
Sikka teaches a method wherein the machine learning model is trained to predict a value based on attributes describing a moving object, wherein the on-demand feature represents a value based on a location of the moving object (“the machine learning engine 618 can receive context data such as location input from a GPS sensor,” column 7 lines 11-12).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the feature of Ashrafzadeh to comprise the location of Sikka. (1) The Examiner finds that the prior art included each claim element listed above, although not necessarily in a single prior art reference, with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. (2) The Examiner finds that one of ordinary skill in the art could have combined the elements as claimed by known software development methods, and that in combination, each element merely performs the same function as it does separately. (3) The Examiner finds that one of ordinary skill in the art would have recognized that the results of the combination were predictable, namely predicting based on location (“the machine learning engine 618 can receive context data such as location input from a GPS sensor,” Sikka column 7 lines 11-12). Therefore, the rationale to support a conclusion that the claim would have been obvious is that the combining prior art elements according to known methods to yield predictable results to one of ordinary skill in the art. See MPEP § 2143(I)(A).
As to dependent claim 13, the rejection of claim 12 is incorporated.
Ashrafzadeh does not appear to expressly teach a medium wherein the machine learning model is trained to predict a value based on user interactions of a user during a session, wherein the on-demand feature represents a value based on user actions performed during the session and the batch feature represents a value based on a user profile of the user.
Sikka teaches a medium wherein the machine learning model is trained to predict a value based on user interactions of a user during a session (“the user may trigger context dependent recognition when upon entering the augmented reality application,” column 7 lines 53-54), wherein the on-demand feature represents a value based on user actions performed during the session (“the machine learning engine 618 can receive context data such as location input from a GPS sensor,” column 7 lines 11-12) and the batch feature represents a value based on a user profile of the user (“Moreover, the machine learning engine 618 can utilize system data 622 as well, such as an internal clock, calendar, apps, reminders, notes, tasks, user activities (e.g., user preferences, messages, user interactions, etc.), and other such input,” column 7 lines 23-27).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the features of Ashrafzadeh to comprise the features of Sikka. (1) The Examiner finds that the prior art included each claim element listed above, although not necessarily in a single prior art reference, with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. (2) The Examiner finds that one of ordinary skill in the art could have combined the elements as claimed by known software development methods, and that in combination, each element merely performs the same function as it does separately. (3) The Examiner finds that one of ordinary skill in the art would have recognized that the results of the combination were predictable, namely predicting based on both dynamic and static data (“the machine learning engine 618 can receive context data such as location input from a GPS sensor to determine that the user is at, or near, a park, for example. The machine learning engine 618 can also use additional context data such as imaging input (e.g., picture, video) from an imaging sensor (e.g., camera, facial recognition software) to determine that the user's context is with his family at the park and pointing the computing device toward downtown. Further, the machine learning engine 618 can use sound data (e.g., music, voice, speech, background noise) from an audio sensor to determine that the context is with friends at a concert. Moreover, the machine learning engine 618 can utilize system data 622 as well, such as an internal clock, calendar, apps, reminders, notes, tasks, user activities (e.g., user preferences, messages, user interactions, etc.), and other such input,” Sikka column 7 lines 11-27). Therefore, the rationale to support a conclusion that the claim would have been obvious is that the combining prior art elements according to known methods to yield predictable results to one of ordinary skill in the art. See MPEP § 2143(I)(A).
As to dependent claim 20, the rejection of claim 19 is incorporated.
Ashrafzadeh does not appear to expressly teach a system wherein the machine learning model is trained to predict a value based on user interactions of a user during a session, wherein the on-demand feature represents a value based on user actions performed during the session and the batch feature represents a value based on a user profile of the user.
Sikka teaches a system wherein the machine learning model is trained to predict a value based on user interactions of a user during a session (“the user may trigger context dependent recognition when upon entering the augmented reality application,” column 7 lines 53-54), wherein the on-demand feature represents a value based on user actions performed during the session (“the machine learning engine 618 can receive context data such as location input from a GPS sensor,” column 7 lines 11-12) and the batch feature represents a value based on a user profile of the user (“Moreover, the machine learning engine 618 can utilize system data 622 as well, such as an internal clock, calendar, apps, reminders, notes, tasks, user activities (e.g., user preferences, messages, user interactions, etc.), and other such input,” column 7 lines 23-27).
Accordingly, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the features of Ashrafzadeh to comprise the features of Sikka. (1) The Examiner finds that the prior art included each claim element listed above, although not necessarily in a single prior art reference, with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference. (2) The Examiner finds that one of ordinary skill in the art could have combined the elements as claimed by known software development methods, and that in combination, each element merely performs the same function as it does separately. (3) The Examiner finds that one of ordinary skill in the art would have recognized that the results of the combination were predictable, namely predicting based on both dynamic and static data (“the machine learning engine 618 can receive context data such as location input from a GPS sensor to determine that the user is at, or near, a park, for example. The machine learning engine 618 can also use additional context data such as imaging input (e.g., picture, video) from an imaging sensor (e.g., camera, facial recognition software) to determine that the user's context is with his family at the park and pointing the computing device toward downtown. Further, the machine learning engine 618 can use sound data (e.g., music, voice, speech, background noise) from an audio sensor to determine that the context is with friends at a concert. Moreover, the machine learning engine 618 can utilize system data 622 as well, such as an internal clock, calendar, apps, reminders, notes, tasks, user activities (e.g., user preferences, messages, user interactions, etc.), and other such input,” Sikka column 7 lines 11-27). Therefore, the rationale to support a conclusion that the claim would have been obvious is that the combining prior art elements according to known methods to yield predictable results to one of ordinary skill in the art. See MPEP § 2143(I)(A).
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure:
US 9857177 B1 disclosing location-based prediction
Applicant is required under 37 C.F.R. § 1.111(c) to consider these references fully when responding to this action.
It is noted that any citation to specific pages, columns, lines, or figures in the prior art references and any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. In re Heck, 699 F.2d 1331, 1332-33, 216 U.S.P.Q. 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006, 1009, 158 U.S.P.Q. 275, 277 (C.C.P.A. 1968)).
In the interests of compact prosecution, Applicant is invited to contact the examiner via electronic media pursuant to USPTO policy outlined MPEP § 502.03. All electronic communication must be authorized in writing. Applicant may wish to file an Internet Communications Authorization Form PTO/SB/439. Applicant may wish to request an interview using the Interview Practice website: http://www.uspto.gov/patent/laws-and-regulations/interview-practice.
Applicant is reminded Internet e-mail may not be used for communication for matters under 35 U.S.C. § 132 or which otherwise require a signature. A reply to an Office action may NOT be communicated by Applicant to the USPTO via Internet e-mail. If such a reply is submitted by Applicant via Internet e-mail, a paper copy will be placed in the appropriate patent application file with an indication that the reply is NOT ENTERED. See MPEP § 502.03(II).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ryan Barrett whose telephone number is 571 270 3311. The examiner can normally be reached 9:00am to 5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, Applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Michelle Bechtold can be reached at 571 431 0762. 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.
/Ryan Barrett/
Primary Examiner, Art Unit 2148