Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 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, 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.
Claims 1-8,10-20 are rejected under 35 U.S.C. 103 as being unpatentable over Irvin et al (us 2026/0099549) (hereinafter Irvin) in view of Vasal et al (us 2026/0134019) (hereinafter Vasal).
As regarding claim 1, Irvin discloses decoding, at an application server, a monitoring request from a user device to determine a request-type, the monitoring request comprising a targeting condition and one or more metrics indicating whether the targeting condition is satisfied (see Irvin 0004,0018, 0029, user specify in the request query for a report of data, where the user specifies topic of interest, report interval, reporting format, the trigger condition for an update for the report (Irvin 0030); the semantic analyzer of the report generation system which is a server dissect the prompt by using LLM to identify topic of the query, request/prompt parameters specified by the user);
matching, by the application server, the monitoring request to one or more data sources based at least in part on the one or more metrics and the request-type (see Irvin 0034-0035, identify relevant data sources…by determine the similarity between metrics/parameter of the user’s query and the content of the data sources); the one or more data sources associated with the one or more metrics (see Irvin 0041-0042, the report parameters specified by the user include a report interval defining the frequency at which report should be update…monitor a duration of time since a previous report was sent to the user, if the report interval has elapsed, instruct the data query engine queries requesting updated information from the data sources).
storing, by the application server, the request-type and the request in an execution store (see Irvin 0048, store the user’s requested query in the database associated with the user account), wherein the monitoring request is later retrieved from the execution store and executed to determine whether the targeting condition for the one or more metrics is satisfied, wherein a message is provided to the user device when the targeting condition is satisfied (see Irvin 0041-0042, the report parameters specified by the user include a report interval defining the frequency at which report should be update…monitor a duration of time since a previous report was sent to the user, if the report interval has elapsed, instruct the data query engine queries requesting updated information from the data sources…send additional report with updated information to the user, Irvin 0044-0045, further discloses event triggers that define condition that trigger a report from the data sources to the user).
Irvin is silent in regard to the concept of determining, by the application server, that the user device is associated with a user account having access permissions to each of the one or more data sources.
Vasal teaches the concept of determining, by the application server, that the user device is associated with a user account having access permissions to each of the one or more data sources (see Vasal 0061, the system check if the user is allowed to access the content for the query).
It would have been obvious to one with an ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Vasal to Irvin because they're analogous art. A person would have been motivated to modify Irvin with Vasal’s teaching for the purpose of efficiently ensuring the unauthorized user access the data sources.
As regarding claim 2, Irvin-Vasal discloses the monitoring request is formatted in a natural language format (see Vasal 0020,0026, natural language processing). For the purpose of providing accessibility and user friendly to users.
As regarding claim 3, Irvin-Vasal discloses the request-type of the monitoring request corresponds to a notification request (see Irvin 0005, 0029, notify the user of the report or the updated report).
As regarding claim 4, Irvin-Vasal discloses submitting the monitoring request to a large language model at the application server to obtain the request-type, the targeting condition, the one or more metrics, and the one or more data sources, wherein the large language model was previously trained with a mapping of the one or more data sources and deriving metric typing information from the request-type and the one or more metrics (see Irvin 0004,0018, 0029, user specify in the request query for a report of data, where the user specifies topic of interest, report interval, reporting format, the trigger condition for an update for the report (Irvin 0030); the semantic analyzer of the report generation system which is a server dissect the prompt by using LLM to identify topic of the query, request/prompt parameters specified by the user, further see Irvin 0041-0042, the report parameters specified by the user include a report interval defining the frequency at which report should be update…monitor a duration of time since a previous report was sent to the user, if the report interval has elapsed, instruct the data query engine queries requesting updated information from the data sources…send additional report with updated information to the user, Irvin 0044-0045, further discloses event triggers that define condition that trigger a report from the data sources to the user).
As regarding claim 5, Irvin-Vasal discloses the metric typing information corresponds to a first group and a functional space of the first group, wherein the one or more data sources are constrained to data sources related to the first group and the functional space of the first group (see Irvin 0029, 0031, the user specify the query parameters, query type, and the server identifies sources that matches the query type and parameters).
As regarding claim 6, Irvin-Vasal discloses categorizing the monitoring request as being event-based or time-based and storing the categorization of the monitoring request in the execution store (see Irvin 0029,0041-0042, trigger types could be interval or breaking news type of report).
As regarding claim 7, Irvin-Vasal discloses causing a user interface to be provided at the user device to receive the monitoring request at the user device (see Irvin 0028-0029, the user enter query for the report using the user interface); and in response to storing the monitoring request, causing a message to be provided at the user interface confirming that the monitoring request was successfully processed (see Irvin 0040, notify the user that the report is generated).
As regarding claim 8, Irvin-Vasal discloses retrieving the monitoring request from the execution store; submitting the monitoring request to a large language model and an indication of an access mode to the one or more data sources, the large language model obtaining information from the one or more data sources via the access mode, the obtained information corresponding to the one or more metrics, the large language model determining whether the obtained information satisfies the targeting condition(see Irvin 0004,0018, 0029, user specify in the request query for a report of data, where the user specifies topic of interest, report interval, reporting format, the trigger condition for an update for the report (Irvin 0030); the semantic analyzer of the report generation system which is a server dissect the prompt by using LLM to identify topic of the query, request/prompt parameters specified by the user, further see Irvin 0041-0042, the report parameters specified by the user include a report interval defining the frequency at which report should be update…monitor a duration of time since a previous report was sent to the user, if the report interval has elapsed, instruct the data query engine queries requesting updated information from the data sources…send additional report with updated information to the user, Irvin 0044-0045, further discloses event triggers that define condition that trigger a report from the data sources to the user); and when the obtained information satisfies the targeting condition, triggering a notification at the user device indicating that the targeting condition is satisfied (see Irvin 0040, notify the user of the report).
As regarding claim 10, Irvin-Vasal discloses prior to submitting the monitoring request to the large language model (see Irvin 0033-0035 using the LLM to dissects the query), verifying that a user account associated with the monitoring request has permission to access the one or more data sources (see Vasal 0061, the system check if the user is allowed to access the content for the query, it is obvious that the server verify if the user is permitted to access the data source before submit request because it would save the server from processing the unauthorized request that might cause security breach or waste of processing resource). The same motivation was utilized in claim 1 applied equally well to claim 10.
As regarding claim 11, Irvin-Vasal discloses accessing, by an application server, an execution store to retrieve a previously stored request from a plurality of previously stored requests, a request-type associated with the previously stored request, and an indication of one or more data sources corresponding to the previously stored request, the request-type corresponding to a notification request type, the request comprising a condition and one or more metrics associated with the condition (see Irvin 0041-0042, the report parameters specified by the user include a report interval defining the frequency at which report should be update…monitor a duration of time since a previous report was sent to the user, if the report interval has elapsed, instruct the data query engine queries requesting updated information from the data sources…send additional report with updated information to the user, Irvin 0044-0045, further discloses event triggers that define condition that trigger a report from the data sources to the user); determining, by the application server, that a user account associated with the previously stored request has access to the one or more data sources (see Vasal 0061, the system check if the user is allowed to access the content for the query); executing, by the application server, the previously stored request to determine whether the condition associated with the one or more metrics is met and when the condition is met, triggering, by the application server, a notification to be provided to a user device associated with the user account (see Irvin 0044-0045, further discloses event triggers that define condition that trigger a report from the data sources to the user), wherein the notification causes a physical state of the user device to change (see Irvin 0029, audio output on the user device). The same motivation was utilized in claim 1 applied equally well to claim 11.
As regarding claim 12, Irvin-Vasal discloses determining that the user account associated with the previously stored request (see Irvin 0048, the database store user account information with the user’s query) comprises determining that the user account has permission to access the one or more data sources, wherein the user account was determined to previously have permission to access the one or more data sources when the previously stored request was previously stored (see Vasal 0061, the system check if the user is allowed to access the content for the query, also see Irvin 0041-0042, the report parameters specified by the user include a report interval defining the frequency at which report should be update…monitor a duration of time since a previous report was sent to the user, if the report interval has elapsed, instruct the data query engine queries requesting updated information from the data sources, it is obvious that the server verify if the user is permitted to access the content every time the server execute the query for updated report to ensure access security). The same motivation was utilized in claim 1 applied equally well to claim 12.
As regarding claim 13, Irvin-Vasal discloses executing the previously stored request comprises: providing the previously stored request, data from the one or more data sources, and the request-type to a large language model, wherein the large language model parses the previously stored request and the data to determine whether the condition associated with the condition is met by the data (see Irvin 0033-0035 using the LLM to dissects the query; also see Irvin 0041-0042, the report parameters specified by the user include a report interval defining the frequency at which report should be update…monitor a duration of time since a previous report was sent to the user, if the report interval has elapsed, instruct the data query engine queries requesting updated information from the data sources).
As regarding claim 14, Irvin-Vasal discloses enabling a watcher process to access the execution store to retrieve the previously stored request when a predetermined condition has been met (see Irvin 0041-0042, the report parameters specified by the user include a report interval defining the frequency at which report should be update…monitor a duration of time since a previous report was sent to the user, if the report interval has elapsed, instruct the data query engine queries requesting updated information from the data sources).
As regarding claim 15, Irvin-Vasal discloses the predetermined condition corresponds to a timeout period (see Irvin 0041-0042, monitor a duration of time since a previous report was sent to the user, if the report interval has elapsed, instruct the data query engine queries requesting updated information from the data sources).
As regarding claim 16, Irvin-Vasal discloses the notification causes an illumination state to change of one or more light emitting diodes or a physical activation of a vibrating device (see Irvin 0029, phone call or audio output on the user device).
As regarding claim 17, limitations of claim 17 are similar to limitations of rejected claims 1 and 11 above, therefore rejected for the same rationale (see Irvin 0041-0042, the report parameters specified by the user include a report interval defining the frequency at which report should be update…monitor a duration of time since a previous report was sent to the user, if the report interval has elapsed, instruct the data query engine queries requesting updated information from the data sources, Irvin 0048 discloses a database stores user account information and user’s query for the server to execute the user query).
As regarding claim 18, Irvin-Vasal discloses periodically review the execution store and process other previously stored requests (see Irvin 0041-0042, the report parameters specified by the user include a report interval defining the frequency at which report should be update…monitor a duration of time since a previous report was sent to the user, if the report interval has elapsed, instruct the data query engine queries requesting updated information from the data sources, Irvin 0048 discloses a database stores user account information and user’s query for the server to execute the user query).
As regarding claim 19, Irvin-Vasal discloses the previously stored request corresponds to the monitoring request (Irvin 0048 discloses a database stores user account information and user’s query for the server to execute the user query).
As regarding claim 20, Irvin-Vasal discloses executing the monitoring request prior to storing the monitoring request in the execution store to determine whether the targeting condition associated with the one or more metrics is satisfied (see Irvin 0029, the user specify parameters in the user’s request the system then execute that request (Irvin 0040)) and when the targeting condition is not satisfied, storing the monitoring request in the execution store in response to the targeting condition not being satisfied (see Irvin 0041-0042, the report parameters specified by the user include a report interval defining the frequency at which report should be update…monitor a duration of time since a previous report was sent to the user, if the report interval has elapsed, instruct the data query engine queries requesting updated information from the data sources, Irvin 0048 discloses a database stores user account information and user’s query for the server to execute the user query, it is obvious that the query is stored and the system will execute when the time lapsed is trigger to execute the report again to generate the updated report for the user).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Irvin-Vasal as applied to claim 8 above and further in view of Kashiyama et al (us 2024/0346172) (hereinafter Kash).
As regarding claim 9, Irvin-Vasal discloses the invention as discloses in claim 1 above, however Irvin-Vasal is silent in regard to the concept of flagging a record in the execution store corresponding to the monitoring request as being satisfied to disable the monitoring request from executing again.
Kash teaches the concept of flagging a record in the execution store corresponding to the monitoring request as being satisfied to disable the monitoring request from executing again (see Kash 0058, the database stores the queries with indication that the query is not executed because it does not meet the requirement).
It would have been obvious to one with an ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Kash to Irvin-Vasal because they're analogous art. A person would have been motivated to modify Irvin-Vasal with Kash’s teaching for the purpose of efficiently processing the requests from the user and saving processing resources from executing the requests that are not satisfy by indicating that with the requests.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUYEN MY DOAN whose telephone number is (571)272-4226. The examiner can normally be reached (571)272-4226.
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, Tonia Dollinger can be reached at (571)272-4170. 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.
/DUYEN M DOAN/Primary Examiner, Art Unit 2459
Prosecution Insights