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 . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
DETAILED ACTION
The following NON-FINAL Office action is in response to application 18757828 filed 06/28/2024
Status of Claims
Claims 1,3-6,8,10-14,16-20 have been amended with the 11/13/2024 amendment
Claims 1-20 are currently pending and have been rejected as follows.
Amendments to drawings and Specification
Examiner notes the amendment of Fig.12 submitted with the preliminary amendment dated 11/13/2024 and the amendment to Original Specification submitted with the preliminary amendment dated 11/13/2024. Such amendments merely corrects minor topological errors, misspellings or issues of grammar and hence comply with MPEP 714 and entered by Examiner.
Priority
Receipt is acknowledged of papers submitted under 35 U.S.C. 119(a)-(d), which papers have been placed of record in the file.
IDS
The information disclosure statement filed on 09/06/2024 and 09/05/2024 each complies with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 and is considered by the Examiner.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea, here abstract idea) without significantly more. The claim(s) recite(s) describe or set forth the abstract “rule processing” as summarized at the preamble of independent Claim 10 and similarly recite the abstract “event processing applied to filtering of events” as summarized at the preamble of independent Claims 1,16. At most such concepts set forth the abstract execution of cognitive or mental matching or corelative processes for pre-filtering executed in a computer environment as tested per MPEP 2106.04(a)(2) III C #2 and/or the use of a computer as a tool to perform a mental process, as tested per MPEP 2106.04(a)(2) III C #3, each falling within the broad grouping off mental processes, even if computerized as per MPEP 2106.04(a)(2) III #1-#3.
For example, given the breadth of the current claims and the broadest reasonable interpretation of MPEP 2111, the Examiner finds such “rule processing” (independent Claim 10) and “event processing applied to filtering of events” (independent Claims 1,16), are not meaningfully different than parsing and comparing data found abstract in Berkheimer v. HP, Inc 881 F.3d 1360, 125 USPQ2d 1649,1652-1653 (Fed Cir 2018) as cited by MPEP 2106.04(a)(2) III C #3. Similarly, when tested per MPEP 2106.04(A)(2) III C #2, the “rule processing” (independent Claim 10) and “event processing applied to filtering of events” (independent Claims 1,16), would at most correspond to abstract processes of rule-based matching for a to-be-filtered event (Claims 1-20) executed in a computer environment. Yet, in FairWarning IP, LLC v. Iatric Sys., Inc., 839 F.3d 1089, 120 USPQ2d 1293 (Fed Cir. 2016) as cited by MPEP 2106.04(A)(2) III C #2, the Federal Circuit found that storing, accessing, compiling and combining of information from disparate information sources, to generate a full picture of activity, identity, frequency of activity, and the like in such computer environment, still set forth the abstract selecting of information, by content or source, for collection, analysis, and announcement. It then follows that here, the accessing or “obtaining” “keys and key values of the events’ / “event” / “to-be-filter event”, along with the “event filtering rule” as recited throughout Claims 1,2,4,7-10,12,14-17, 19 for compiling or “matching” at Claims 1,2,4-7,9-10,13,15-17,19,20 and combining of information, akin here to “key combination and a key value combination” at dependent Claims 8,12, from disparate information sources would equally set forth the abstract exception in a manner not meaningfully different than FairWarning, as tested per MPEP 2106.04(A)(2) III C #2.
Additionally, or alternatively such “rule processing” (independent Claim 10) and “event processing applied to filtering of events” (independent Claims 1,16), when tested per MPEP 2106.04(a)(2) I A, can also be interpreted to set forth mathematical relationships expressed in words. Indeed, as initially explained by MPEP 2106.04(a)(2) I A iv. organizing information and manipulating information through mathematical correlations by generating first and second data by taking existing information, manipulating the data using mathematical functions, and organizing this information into a new form remains abstract.
Here, when testing independent Claims 1-20 per MPEP 2106.04(a)(2) I A supra, the Examiner finds that such mathematical constructs are expressed in words, as: “one or more first conditions”, “one or more second” and “one or more third conditions”, as well as “key” and “key values” and “matching rule”, “event filtering rule”, and “operation rule” (i.e. via Boolean “AND” operator) as preponderantly recited through Claims 1-20, starting with generating first and second data by taking existing information, manipulating the data using mathematical functions, set forth here by “matching” [as an example of correlation supra] “a to-be-filtered event with an event matching rule” “to obtain an event” [as an example of existing information supra] “that meets one or more first conditions and one or more second conditions” [as examples of first and second data supra] for “sending an instruction to a destination address when the to-be-filtered event meets the event matching rule”. [akin to organizing the information into a new form remains supra] as recited at independent Claims 1,16.
Also here, when similarly testing independent Claim 10, Examiner finds that the organizing information and manipulating information through mathematical correlations by generating first and second data by taking existing information, manipulating the data using mathematical functions, and organizing this information of MPEP 2106.04(a)(2) I A iv., is reflected here by language such as “obtaining an event filtering rule” and “performing filtering using the event filter rule to obtain an event that meets all of one or more third conditions and an event matching rule, the event matching rule is used for performing filtering to obtain an event that meets one or more first conditions and one or more second conditions, and the second condition indicates duration or repeatability of the one or more first conditions” as recited at independent Claim 10.
Similar abstract correlation or “matching” is recited here as: “matching the events in the server with one or more third conditions, to obtain the to-be-filtered event, wherein the to-be-filtered event is an event that meets the one or more third conditions” (dependent Claims 2,17) / “wherein the tree is used for performing filtering to obtain a to-be-filtered event, and the to-be-filtered event is an event that meets the one or more third conditions” (dependent Claim 14), “matching the keys of the events with keys of the one or more third conditions” “when a key of an event meets the keys of the one or more third conditions, matching a key value of the event with key values of the one or more third conditions, wherein the to-be-filtered event is an event that meets the key values of the one or more third conditions” (dependent Claims 4,19), “the one or more first conditions and the one or more second conditions that match each other are used as different child nodes of a same parent node, and a parent node of the one or more first conditions and the one or more second conditions that match each other corresponds to an AND operation rule” (dependent Claims 5,13,20), “wherein the matching of the to-be-filtered event with the event matching rule includes traversing the tree for the to-be-filtered event” (dependent Claim 6), the latter also arguable as corresponding to the abstract manipulating of data using mathematical functions, and organizing this information as enumerated by MPEP 2106.04(a)(2) I A iv.
Here the abstract information used in the aforementioned correlation and manipulation is further narrowed as: “wherein the one or more third conditions comprises a key and a key value” (dependent Claims 3,11,18), “obtaining keys and key values of the events” (dependent Claims 4,19), “obtaining an event filtering rule, wherein the event filtering rule is used for performing filtering to obtain an event that meets all of the one or more third conditions and the event matching rule; and storing the one or more third conditions and the event matching rule” (dependent Claim 7), “obtaining keys of the one or more third conditions, and obtaining key values of the one or more third conditions” (dependent Claims 8,12).
Accordingly, there is a preponderance of legal evidence showing that, given the current claim breadth and the broadest reasonable interpretation, as tested per MPEP 2111, the current claims recite or at a minimum describe or set forth the abstract exception. Step 2A pong one.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This judicial exception is not integrated into a practical application because per Step 2A prong two, the individual or combination of additional, computer-based elements such as: memory stor[ed] instructions executed by the processor as recited at independent Claim 16
are found to merely apply the already identified abstract exception, which when tested per MPEP 2106.05(f), do not integrate the abstract exception into a practical application.
For example, when tested, per MPEP 2106.05(f)(2) ¶1, such additional, computer-based elements represent mere invocation of computer to receive, store, or transmit data, that according to MPEP 2106.05(f)(2) ¶1, does not integrate the abstract idea into a practical application.
- Here such capability to store data is recited as: “storing the one or more third conditions and the event matching rule” at independent Claim 10 and dependent Claim 7, “storing a key combination and a key value combination, wherein the key combination is a combination of the keys of the one or more third conditions, and the key value combination is a combination of the key values of the one or more third conditions” at dependent Claims 8,12, “the event matching rule is stored” at dependent Claim 9, “wherein the event matching rule is stored in a form of a tree” at dependent Claim 13
- Here such capability to transmit data is recited as: “sending an instruction to a destination address when the to-be-filtered event meets the event matching rule” at Claims 1,16
Also, MPEP 2106.05(f)(2) (iii), (i), (v) find that monitoring audit log data executed on a computer, and application of a mathematical algorithm on the computer, represent, along with the use of software to tailor information and provide it on the computer mere invocation of computers components or machinery as a tool to perform an existing process, and hence do not integrate the abstract exception into a practical application. It then follows that here, any purported degree of computerization in monitoring the events attributes and conditions as identified at the prior set, to be mathematically correlated or matched as also identified above, for further tailoring information to be provided, akin to what is claimed here to a “destination address when the to-be-filtered event meets the event matching rule” at independent Claims 1,16, would analogously represent mere invocation of computers components or machinery as a tool, and hence would not integrate the abstract exception into a practical application.
Thus, there is a preponderance of legal evidence showing that any purported automation or computerization above does not integrate the abstract exception into a practical application.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because Examiner follows MPEP 2106.05(d) II guidelines and carries over the above findings at MPEP 2106.05 (f) to submit that as shown above, the additional elements, merely apply the already recited abstract idea. For these same reasons, said computer-based additional elements also do not provide significantly more than the abstract idea itself, in light of MPEP 2106.05(f) as option for evidence. Based on such legal evidence conferred by the MPEP 2106.05(f) test above, the Examiner submits that the additional computer-based elements do not provide significantly more. Yet, assuming arguendo, that further evidence would be required to demonstrate conventionality of the additional, computer-based elements, Examiner would further point to MPEP 2106.05(d) to demonstrate that said additional elements remain well-understood, routine, conventional. In such case, Examiner would rely, among the others, on the Applicant’s own Original Specification as follows:
- Original Specification ¶ [0311] reciting at high level of generality: “Fig.14 shows an electronic device according to an embodiment of this application. The electronic device includes at least one memory 1402, configured to store a program, and at least one processor 1401, configured to execute the program stored in the memory 1402. When the program stored in the memory 1402 is executed, the processor 1401 is configured to perform any event processing method according to the first aspect and any event rule processing method according to the second aspect”.
- Original Specification ¶ [00318] reciting at high level of generality: “When the function is implemented in the form of the software functional unit and sold or used as an independent product, the function may be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of embodiments of this application essentially, or the part contributing to the prior art, or some of the technical solutions may be implemented in a form of a software product. The computer software product is stored in a storage medium, and includes several instructions for instructing a computer device (which may be a personal computer, a server, or an access network device) to perform all or some of the steps of the methods described in embodiments of this application. The storage medium includes any medium that can store program code, such as a USB flash drive, a removable hard disk drive, a read-only memory (Read-Only Memory, ROM), a random access memory (Random Access Memory, RAM), a magnetic disk, or an optical disc”.
- Original Specification ¶ [00319] reciting at high level of generality: “The foregoing descriptions are merely specific implementations of embodiments of this application, but are not intended to limit the protection scope of embodiments of this application. Any variation or replacement readily figured out by a person skilled in the art within the technical scope disclosed in embodiments of this application shall fall within the protection scope of embodiments of this application”.
- Additionally, or alternatively per -
MPEP 2106.05(d)(II) the following computer functions are well‐understood, routine, and conventional functions: receiving/transmitting data over network including use of intermediary computer to forward information1 and gathering statistics2 / electronic recordkeeping3 / storing and retrieving information in memory4 , performing repetitive calculations5 , arranging a hierarchy of groups, sorting information6. It then follows that here even if testing, in the arguendo, the level of computerization for the matching for the event to be filtered, including the use of tree , per the conventionality test of MPEP 2106.05(d)(II), such functionality, given the breath of the claims and the broadest reasonable interpretation test MPEP 2111, would still not provide significantly more.
All of this preponderance of legal and/or factual evidence demonstrate that the additional computer-based elements fail to provide anything significantly more than what was already identified as part of the abstract exception above. Therefore, Claims 1-20, although directed to statutory categories (here methods or processes at Claims 1-9 and 10-15, and “apparatus” or machine at Claims 16-20 ), they still recite, or at least describe or set forth the abstract idea (Step 2A prong one), with their additional, computer-based elements not integrating the abstract idea into a practical application (Step 2A prong two) or providing significantly more than abstract idea (Step 2B). Thus Claims 1-20 are patent ineligible.
Claim Rejections - 35 USC § 102
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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-7, 9-11, 13-20 are rejected under 35 U.S.C. 102(a)(1) based upon a public use or sale or other public availability of the invention as disclosed by:
Vega et al, US 20130205008 A1 hereinafter Vega. As per,
Claims 1, 16
Vega teaches “An event processing method, applied to filtering of events in a server, the method comprising:” / “An apparatus for event processing, the apparatus comprises: a processor, and a memory coupled to the processor and configured to store a plurality of instructions that, when executed by the processor, causes the processor to be configured to” ([0022],[0028] [0090])
- “matching a to-be-filtered event with an event matching rule, wherein the event matching rule is used for performing filtering to obtain an event that meets one or more first conditions and one or more second conditions, and the one or more second conditions indicates duration or repeatability of the one or more first conditions” (Vega ¶ [0066] 3rd-5th sentences: Fig.5 depicts a tree diagram graphically illustrating example rule criteria implemented in the illustrated tree diagram is: For version N or higher of the hosting application, user selected drop ship on a Sales Invoice screen today and has at least 5 purchase orders which occurred 10 times in a month.
Vega ¶ [0069] 1st-3rd sentences: left expression 502a comprises an AND expression 510 having left expression 510a and right expression 510b. Additionally, time constraint 512 is associated with AND expression 510 that requires that the actions specified in expression 510 be performed at least 10 times in a month period, thus implements the, “which occurred 10 times in a month” constraint in the rule criteria above. ¶ [0069] 6th sentence: other time constraints might specify…‘that the action has happened 5 times’ (ever, or since install of the application, for instance), ‘that the action has happened 5 times in the last 2 months’, or ‘that the action which comprises an action having occurred 5 times in an hour has happened 3 times in the last week’, as examples. ¶ [0070] Left expression 510a of expression 510 implements the “has at least 5 purchase orders” constraint in the rule criteria recited above. A “GREATER THAN OR EQUAL TO” expression 514 is evaluated in which a number of purchase orders is queried 516 (for instance via a service specified in the rule itself, or via a remote service referenced by the logical expression, to query the application user data which indicates the number of purchase orders) and compared to a specified constant 518, which is 5 in this example. Expression 514 evaluates to true if the queried number of purchase orders is 5 or more. ¶ [0072] 2nd sentence: multiple time constraints can be placed on differing rule criteria, and the time constraints can be applied to nested expressions (e.g. 528 and 510). ¶ [0073] 1st sentence: there are many valid supported expression terms that can be used in a logical expression of a rule. A logical expression of a rule can include any logical expression term including AND,… etc.) “and”
- “sending an instruction to a destination address when the to-be-filtered event meets the event matching rule” (Vega [0058] 4th,9th-14th sentences: advisor-application information interface 404 listens to events, e.g. from a dispatch loop, for initial pertinent user-behavior related info (for instance opening up screen 402 a having button 402 b and Listbox 402 c). Thus, as user changes value of Listbox 402c, these interactions are observed on advisor-control information interface 406 and the behavior state is built-up over time with each successive user interaction to change the value of Listbox 402 c. The rule is evaluated based on this buildup of behavior state and triggered if the criteria evaluates to true. Assuming the user changes the value of Listbox 402c 5 or more times, services specified by service requests 410 b are looked up in service registry 412 that contains list of service names mapped [or addressed] to executable code…. Each service specified in service requests 410 b, assuming the respective service is found in service registry 412, is executed, using data contained inside the rule or obtained responsive to executing a service specified in the rule to obtain the data. In Fig.4, one service requested is a user message bubble service 414 which executes to display user message 416 having a message specified in service requests 410 b of Rule 1 (410). Rule 1 (410) also requests an SQL query service 418 and other services 420, which are also executed upon triggering of Rule 1 (410). For additional details about the triggering see Fig.3 & ¶ [0044]-¶ [0051] and Fig.4 & ¶ [0058]-¶ [0066]).
PNG
media_image1.png
534
878
media_image1.png
Greyscale
Vega Fig.5 in support of rejection arguments
Claim 10. Vega similarly teaches An event rule processing method comprising:
- “obtaining an event filtering rule” (Vega ¶ [0058] 11th-14th sentences: Assuming that the user changes the value of Listbox 402 c five or more times, services specified by service requests 410 b are looked up in service registry 412 that contains list of service names mapped to executable code…. Each service specified in service requests 410 b, assuming the respective service is found in service registry 412, is executed, optionally using data contained inside the rule or obtained responsive to executing a service specified in the rule to obtain the data. In Fig.4, one service requested is a user message bubble service 414 which executes to display user message 416 having a message specified in service requests 410 b of Rule 1 (410). Rule 1 (410) also requests an SQL query service 418 and other services 420, which are also executed upon triggering of Rule 1 (410). Fig.5 and ¶ [0073] Those having ordinary skill in the art will appreciate that there are many valid supported expression terms that can be used in a logical expression of a rule. A logical expression of a rule can include any logical expression term including AND, OR, NOT, NAND, NOR, XOR, etc. Similarly, usable comparison expressions include EQUAL (=) and GREATER THAN OR EQUAL TO (>=) (as depicted in FIG. 5), as well as NOT EQUAL TO (!=), GREATER THAN (>) and LESS THAN (<), and LESS THAN OR EQUAL TO (<=), among others);
- performing filtering using the event filter rule to obtain an event that meets all of one or more third conditions and an event matching rule, the event matching rule is used for performing filtering to obtain an event that meets one or more first conditions and one or more second conditions, and the second condition indicates duration or repeatability of the one or more first conditions; (Vega ¶ [0066] 3rd-5th sentences: Fig.5 depicts a tree diagram graphically illustrating example rule criteria implemented in the illustrated tree diagram is: For version N or higher of the hosting application, user selected drop ship on a Sales Invoice screen today and has at least 5 purchase orders which occurred 10 times in a month.
Vega ¶ [0069] 1st-3rd sentences: left expression 502a comprises an AND expression 510 having left expression 510a and right expression 510b. Additionally, time constraint 512 is associated with AND expression 510 that requires that the actions specified in expression 510 be performed at least 10 times in a month period, thus implements the, “which occurred 10 times in a month” constraint in the rule criteria above. ¶ [0069] 6th sentence: other time constraints might specify…‘that the action has happened 5 times’ (ever, or since install of the application, for instance), ‘that the action has happened 5 times in the last 2 months’, or ‘that the action which comprises an action having occurred 5 times in an hour has happened 3 times in the last week’, as examples. ¶ [0070] Left expression 510a of expression 510 implements the “has at least 5 purchase orders” constraint in the rule criteria recited above. A “GREATER THAN OR EQUAL TO” expression 514 is evaluated in which a number of purchase orders is queried 516 (for instance via a service specified in the rule itself, or via a remote service referenced by the logical expression, to query the application user data which indicates the number of purchase orders) and compared to a specified constant 518, which is 5 in this example. Expression 514 evaluates to true if the queried number of purchase orders is 5 or more. ¶ [0072] 2nd sentence: multiple time constraints can be placed on differing rule criteria, and the time constraints can be applied to nested expressions (e.g. 528 and 510). ¶ [0073] 1st sentence: there are many valid supported expression terms that can be used in a logical expression of a rule. A logical expression of a rule can include any logical expression term including AND,… etc.) “and”
- “storing the one or more third conditions and the event matching rule”
(Vega ¶ [0059] 2nd sentence: Rules can be based on any combination of user behavior with respect to attributes of the application, system properties and other workstation variables, application configuration information, and application user data stored by the application, etc.
Vega ¶ [0081] noting executable code
<RuleStore>
<Rules>
<Rule>
<Description>Rule #2-a-Customer Management Center PCW+</Description> etc. etc.
Vega ¶ [0083] noting executable code ending with
</Rules>
<Versio>2</Version>
</RuleStore>)
Claims 2,14,17 Vega teaches all the limitations in claims 1,13,16 above. Vega further teaches
- “matching the events in the server with one or more third conditions, to obtain the to-be-filtered event, wherein the to-be-filtered event is an event that meets the one or more third conditions” (Claims 2,17) / “wherein the tree is used for performing filtering to obtain a to-be-filtered event, and the to-be-filtered event is an event that meets the one or more third conditions” (Claim 14)
(Vega Fig.5 above and ¶ [0066]-¶ [0073] for specific example and additional details at
Vega ¶ [0043] where the hosting application, as part of its coding, uses discrete identifiers for identifying attributes of the application, used in building information of an event passed to the dispatch loop. The discrete identifiers include attribute names, and attributes in the software can be identified using an attribute name from this set of identifiers, and include either a customized or conventional name for the application attribute. The identifier can be used in rule specification to accurately identify application attributes in a manner that is consistent with the way the hosting application identifies the application attributes. This enables the advisor program to, for instance, use the identifiers in obtaining data about the application attributes. When a user interacts with the attribute, for instance toggles a dialog control causing an event to be reported, that interaction can be identified based on the attribute name provided in the event. This facilitates identifying the user behavior (e.g. toggling) with respect to the particular attribute (e.g. dialog control) of the application, in that reported events can be examined for the particular discrete identifier of a relevant application attribute. An event which reports that a window was opened might provide as part of the event information the title (name) of the window (attribute), the title being a discrete identifier used by the application. According to aspects of the invention, specification of the rules is made by way of these discrete identifiers, in order for the criteria of the rules to be understandable in the context of the application. When multiple applications host the advisor program, different rule sets can be applied using the respective identifiers of each hosting application. Alternatively, a single rule set can be applied for all hosting applications, or the hosting applications may employ a common set of identifiers.
Vega ¶ 0044] Returning to Fig.3, responsive to the user interacting with a relevant area or application attribute (312), such as one that is deemed relevant by virtue of it being specified in the criteria of one or more rules, the advisor program application interface receives and distributes interaction data (314) to the advisor processing engine of the advisor program. The interaction data includes information provided in the event reporting the interaction, such as the discrete identifier of the attribute that was being interacted with (e.g. “DialogControl1”) and the nature of that interaction (e.g. ‘toggles on’ or ‘toggled off’). The processing engine builds a user behavior state by accumulating this interaction data within the context of the present application session (316). The behavior of the user with respect to the relevant attributes of the application is accumulated over a period of time to form a behavior state based on what is indicated in the rules as being relevant user behavior for monitoring. By way of example, if the triggering criteria of a rule is interested user interaction with a quantity input control in a particular area of the application three or more times without changing the entity on which the user operates (i.e. value in that quantity control), then the user behavior of selecting the control the first time, a second time, and a third time will be accumulated, each time building-up the behavior state with respect to that control based on the repeated interaction. Not only can interaction data be accumulated within the present application session, but additionally, the accumulated interaction data can be stored over multiple prior sessions with the application (318). A session is, in one example, some period of time during which the user interacts with the application and attributes thereof. In one example, a session extends from the time of opening or launching the application or an individual module until that application or module is exited or navigated away-from by the user. A built application state can therefore include data obtained across multiple sessions, and a built user behavior state of the application state can include user interaction data across the multiple sessions. In this manner, the buildup of user behavior state incorporates interaction data from previous and present interactions, enabling triggering of rule criteria based on non-serialized (i.e. out-of-sequence and/or out-of-order) interaction, if so desired.
Vega ¶ [0058] 4th-10th sentences an advisor application information interface 404 listens to events, e.g. from a dispatch loop, for initial pertinent user-behavior related info (for instance opening up screen 402 a having button 402 b and Listbox 402 c). Since Rule 1 (410) is interested in user behavior with respect to Listbox 402 c, advisor-application information interface 404 creates, responsive to an event i.e. opening of screen 402 a, an advisor-control information interface 406 to obtain data about control 402 c, i.e. to directly observe user interaction occurring on control 402 c. The user interaction data on both advisor-application information interface 404 and advisor-control information interface 406 is provided to rule engine 408 which evaluates Rule 1 (410) and other installed rules on the workstation based on buildup of application state (in this example built-up user behavior state). In Fig.4, Rule 1 (410) specifies triggering criteria (behavior expression 410a) of changing the value in Listbox 402 c five or more times. Thus as user changes value of Listbox 402c, these interactions are observed on advisor-control information interface 406 and the behavior state is built-up over time with each successive user interaction to change the value of Listbox 402 c. The rule is evaluated based on this buildup of behavior state and may be triggered if the criteria evaluates to true)
Claims 3,11,18 Vega teaches all the limitations in claims 2,10,17 above. Vega further teaches
- “wherein the one or more third conditions comprises a key and a key value”.
(Vega ¶ [0058] 11th-14th sentences: Assuming that the user changes the value of Listbox 402 c five or more times, services specified by service requests 410 b are looked up in service registry 412 that contains list of service names mapped to executable code…. Each service specified in service requests 410 b, assuming the respective service is found in service registry 412, is executed, optionally using data contained inside the rule or obtained responsive to executing a service specified in the rule to obtain the data. In Fig.4, one service requested is a user message bubble service 414 which executes to display user message 416 having a message specified in service requests 410 b of Rule 1 (410). Rule 1 (410) also requests SQL query service 418 and other services 420, which are also executed upon triggering of Rule 1 (410).
Vega Fig.5 ¶ [0070] Left expression 510 a of expression 510 implements the “has at least 5 purchase orders” constraint in the rule criteria recited above. A “GREATER THAN OR EQUAL TO” expression 514 is evaluated in which a number of purchase orders is queried 516 (for instance via a service specified in the rule itself, or via a remote service referenced by the logical expression, to query the application user data which indicates the number of purchase orders) and compared to a specified constant 518, which is 5 in this example. Expression 514 evaluates to true if the queried number of purchase orders is 5 or more. Also Fig.6 elements 602,610,612)
Claims 4,19 Vega teaches all the limitations in claims 3,18 above. Vega further teaches “wherein the matching of the events in the server with the one or more third conditions comprises”:
- “obtaining keys and key values of the events” (Vega ¶ [0058] 4th-10th sentences an advisor application information interface 404 listens to events, e.g. from a dispatch loop, for initial pertinent user-behavior related info (for instance opening up screen 402 a having button 402 b and Listbox 402 c). Since Rule 1 (410) is interested in user behavior with respect to Listbox 402 c, advisor-application information interface 404 creates, responsive to an event i.e. opening of screen 402 a, an advisor-control information interface 406 to obtain data about control 402 c, i.e. to directly observe user interaction occurring on control 402 c. The user interaction data on both advisor-application information interface 404 and advisor-control information interface 406 is provided to rule engine 408 which evaluates Rule 1 (410) and other installed rules on the workstation based on buildup of application state (in this example built-up user behavior state). In Fig.4, Rule 1 (410) specifies triggering criteria (behavior expression 410a) of changing the value in Listbox 402 c five or more times. Thus as user changes value of Listbox 402c, these interactions are observed on advisor-control information interface 406 and the behavior state is built-up over time with each successive user interaction to change the value of Listbox 402 c. The rule is evaluated based on this buildup of behavior state and may be triggered if the criteria evaluates to true).
- “matching the keys of the events with keys of the one or more third conditions”
(Vega ¶ [0058] 11th-14th sentences: Assuming that the user changes the value of Listbox 402 c five or more times, services specified by service requests 410 b are looked up in service registry 412 that contains list of service names mapped [or addressed] to executable code…. Each service specified in service requests 410 b, assuming the respective service is found in service registry 412, is executed, optionally using data contained inside the rule or obtained responsive to executing a service specified in the rule to obtain the data. In Fig.4, one service requested is a user message bubble service 414 which executes to display user message 416 having a message specified in service requests 410 b of Rule 1 (410). Rule 1 (410) also requests an SQL query service 418 and other services 420, which are also executed upon triggering of Rule 1 (410) ) ; “and”
- “when a key of an event meets the keys of the one or more third conditions, matching a key value of the event with key values of the one or more third conditions, wherein the to-be-filtered event is an event that meets the key values of the one or more third conditions”.
(Vega ¶ [0069]-¶ [0071] noting for example at ¶ [0070] Left expression 510 a of expression 510 implements the “has at least 5 purchase orders” constraint in the rule criteria recited above. A “GREATER THAN OR EQUAL TO” expression 514 is evaluated in which a number of purchase orders is queried 516 (for instance via a service specified in the rule itself, or via a remote service referenced by the logical expression, to query the application user data which indicates number of purchase orders) and compared to a specified constant 518, which is 5. Expression 514 evaluates to true [or match] if the queried number of purchase orders is 5 or more).
Claims 5,13,20 Vega teaches all the limitations in claims 3,10,18 above. Vega further teaches:
- “wherein the event matching rule is expressed / stored in a form of a tree, the tree comprises one or more parent nodes and a plurality of child nodes, the one or more first conditions and the one or more second conditions that match each other are used as different child nodes of a same parent node, and a parent node of the one or more first conditions and the one or more second conditions that match each other corresponds to an AND operation rule”.
(Vega Annotated Fig. 5 below and ¶ [0071]-¶ [0072] noting under parent labeled “AND” 520, the first condition 524 and second condition 526 are equal thus match each other – 522. Similarly under parent labeled “AND” 528, the first condition 534 and second condition 536 equal - 532 and thus match each other)
PNG
media_image2.png
544
894
media_image2.png
Greyscale
Vega Fig.5 in support of rejection arguments
Claim 6 Vega teaches all the limitations in claim 5 above. Vega further teaches:
- “wherein the matching of the to-be-filtered event with the event matching rule includes traversing the tree for the to-be-filtered event” (Vega Fig.5 traversing the tree from root 502 down to the hierarchy to the to child nides using narrowing features, Boolean operators etc.).
Claim 7 Vega teaches all the limitations in claim 2 above. Vega further teaches:
- “obtaining an event filtering rule, wherein the event filtering rule is used for performing filtering to obtain an event that meets all of the one or more third conditions and the event matching rule” (Vega ¶ [0032] 4th-5th sentences, ¶ [0059] The scope of possibilities in the triggering criteria employed and services requested in the deployed rules is virtually infinite. Rules can be based on any combination of user behavior with respect to attributes of the application, system properties and other workstation variables (such as what web browser is installed on the system), application configuration information, and application user data stored by the application, etc.
Vega Fig.5 and ¶ [0073] Those having ordinary skill in the art will appreciate that there are many valid supported expression terms that can be used in a logical expression of a rule. A logical expression of a rule can include any logical expression term including AND, OR, NOT, NAND, NOR, XOR, etc. Similarly, usable comparison expressions include EQUAL (=) and GREATER THAN OR EQUAL TO (>=) (as depicted in FIG. 5), as well as NOT EQUAL TO (!=), GREATER THAN (>) and LESS THAN (<), and LESS THAN OR EQUAL TO (<=), among others); “and”
- “storing the one or more third conditions and the event matching rule”.
(Vega ¶ [0059] 2nd sentence: Rules can be based on any combination of user behavior with respect to attributes of the application, system properties and other workstation variables, application configuration information, and application user data stored by the application, etc.
Vega ¶ [0081] noting executable code
<RuleStore>
<Rules>
<Rule>
<Description>Rule #2-a-Customer Management Center PCW+</Description> etc. etc.
Vega ¶ [0083] similarly noting executable code ending with
</Rules>
<Versio>2</Version>
</RuleStore>)
Claims 9, 15 Vega teaches all the limitations in claims 7, 10 above. Vega further teaches
- wherein when the to-be-filtered event is obtained by matching the events in the server against the one or more third conditions, the event matching rule is stored (Claim 9).
- “wherein the one or more third conditions are used for performing matching on events in a server to obtain the to-be-filtered event, and the to-be-filtered event is the event that meets the one or more third conditions” (Claim 15) .
(Vega ¶ [0018] 1st-2nd sentences: the advisor program ‘listens’ to system activity from an application hosting the advisor program) in the computing environment to determine whether and when to trigger one or more rules. A rule contains a specification of any combination of user behavior/actions, system variables of a computer system on which the application is installed, or application properties, such as application configuration information or user data stored by the application. For example at ¶ [0058] 4th-10th sentences an advisor application information interface 404 listens to events, e.g. from a dispatch loop, for initial pertinent user-behavior related info (for instance opening up screen 402 a having button 402 b and Listbox 402 c). Since Rule 1 (410) is interested in user behavior with respect to Listbox 402 c, advisor-application information interface 404 creates, responsive to an event i.e. opening of screen 402 a, an advisor-control information interface 406 to obtain data about control 402 c, i.e. to directly observe user interaction occurring on control 402 c. The user interaction data on both advisor-application information interface 404 and advisor-control information interface 406 is provided to rule engine 408 which evaluates Rule 1 (410) and other installed rules on the workstation based on buildup of application state (in this example built-up user behavior state). In Fig.4, Rule 1 (410) specifies triggering criteria (behavior expression 410a) of changing the value in Listbox 402 c five or more times. Thus as user changes value of Listbox 402c, these interactions are observed on advisor-control information interface 406 and the behavior state is built-up over time with each successive user interaction to change the value of Listbox 402 c. The rule is evaluated based on this buildup of behavior state and may be triggered if the criteria evaluates to true
Vega Fig.5 above and ¶ [0066] 3rd-4th sentences: one example of a logical expression is described with reference to Fig. 5, which depicts a tree diagram graphically illustrating example rule criteria of a rule, in accordance with one or more aspects of the present invention. The rule criteria implemented in the illustrated tree diagram is: For version N or higher of the hosting application, user selected drop ship on a Sales Invoice screen today and has at least 5 purchase orders which occurred 10 times in a month. Additional matching details at ¶ [0067]-¶[0072] with emphasis on ¶ [0073] noting Those having ordinary skill in the art will appreciate that there are many valid supported expression terms that can be used in a logical expression of a rule. A logical expression of a rule can include any logical expression term including AND, OR, NOT, NAND, NOR, XOR, etc. Similarly, usable comparison expressions include EQUAL (=) and GREATER THAN OR EQUAL TO (>=) (as depicted in FIG. 5), as well as NOT EQUAL TO (!=), GREATER THAN (>) and LESS THAN (<), and LESS THAN OR EQUAL TO (<=), among others).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Rejections under 35 § U.S.C. 103
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 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 factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 8,12 are rejected under 35 U.S.C. 103 as being unpatentable over
Vega as applied to claims 7,10 above, in view of
Kevin Petit US 20190384613 A1 hereinafter Petit. As per,
Claims 8,12 Vega teaches all the limitations in claims 7,10
Vega teaches: wherein the storing of the one or more third conditions comprises:
- “obtaining keys of the one or more third conditions, and obtaining key values of the one or more third conditions”; (Vega ¶ [0058] 4th-10th sentences an advisor application information interface 404 listens to events, e.g. from a dispatch loop, for initial pertinent user-behavior related info (for instance opening up screen 402 a having button 402 b and Listbox 402 c). Since Rule 1 (410) is interested in user behavior with respect to Listbox 402 c, advisor-application information interface 404 creates, responsive to an event i.e. opening of screen 402 a, an advisor-control information interface 406 to obtain data about control 402 c, i.e. to directly observe user interaction occurring on control 402 c. The user interaction data on both advisor-application information interface 404 and advisor-control information interface 406 is provided to rule engine 408 which evaluates Rule 1 (410) and other installed rules on the workstation based on buildup of application state (in this example built-up user behavior state). In Fig.4, Rule 1 (410) specifies triggering criteria (behavior expression 410a) of changing the value in Listbox 402 c five or more times. Thus as user changes value of Listbox 402c, these interactions are observed on advisor-control information interface 406 and the behavior state is built-up over time with each successive user interaction to change the value of Listbox 402 c. The rule is evaluated based on this buildup of behavior state and may be triggered if the criteria evaluates to true). ¶ [0058] 11th-14th sentences: Assuming that the user changes the value of Listbox 402 c five or more times, services specified by service requests 410 b are looked up in service registry 412 that contains list of service names mapped [or addressed] to executable code…. Each service specified in service requests 410 b, assuming the respective service is found in service registry 412, is executed, optionally using data contained inside the rule or obtained responsive to executing a service specified in the rule to obtain the data. In Fig.4, one service requested is a user message bubble service 414 which executes to display user message 416 having a message specified in service requests 410 b of Rule 1 (410). Rule 1 (410) also requests an SQL query service 418 and other services 420, which are also executed upon triggering of Rule 1 (410) ). ¶ [0070] Left expression 510 a of expression 510 implements the “has at least 5 purchase orders” constraint in the rule criteria recited above. A “GREATER THAN OR EQUAL TO” expression 514 is evaluated in which a number of purchase orders is queried 516 (for instance via a service specified in the rule itself, or via a remote service referenced by the logical expression, to query the application user data which indicates the number of purchase orders) and compared to a specified constant 518, which is 5 in this example. Expression 514 evaluates to true [or match] if the queried number of purchase orders is 5 or more)
* However *
Vega does not explicitly recite, to clearly anticipate:
- “storing a key combination and a key value combination, wherein the key combination is a combination of the keys of the one or more third conditions, and the key value combination is a combination of the key values of the one or more third conditions”.
* Nevertheless *
Petit in analogous art of event rule processing using the Boolean operator “AND”, as per
¶ [0237], along a tree as per ¶ [0265] and Fig.6 below provides many examples to teach/suggest:
- “storing a key combination and a key value combination, wherein the key combination is a combination of the keys of the one or more third conditions, and the key value combination is a combination of the key values of the one or more third conditions”.
(Petit ¶ [0127] first combining step combines initial data value for the execution lane for a thread with initial data value for a selected another execution lane of the execution processing circuitry, and stores the combined data value result of the combining operation for the thread. Petit ¶ [0129] in an embodiment, there is second combining step that combines in accordance with the operation defined for the reduction operation, the stored combined data value result of the first combining step for the thread with the combined data value result of the first combining step for a selected another execution lane of the execution processing circuitry that has not yet contributed to the stored combined data value result for the thread, and stores the combined data value result of the second combining step for the thread.
Petit ¶ [0130] there may then be a third combining step that combines in accordance with the operation defined for the reduction operation, the stored combined data value result of the second combining step for the thread with the combined data value result of the second combining step for a selected another execution lane of the execution processing circuitry that has not yet contributed to the stored combined data value result for the thread, and stores the combined data value result of the third combining step for the thread (and so on, if required).
Petit ¶ [0131] In an embodiment, the sequence of instructions is operable so as to progressively combine the data values in the execution lanes in a pairwise manner. Thus it is in an embodiment operable to cause the execution processing circuitry to, in a first step, combine (in accordance with the operation for the reduction operation) the (initial) data values for respective pairs of, in an embodiment adjacent, execution lanes, such that each execution lane in the pair of execution lanes will then store (have associated with it) the result of combining the data values for the two execution lanes in the pair.
Petit ¶ [0140] 2nd sentence: noting another example where the registers associated with the execution lane executing the instruction where the data values to be combined are stored, and/or (and in an embodiment and) a destination register where the result of the operation using the data values is to be stored.
Petit ¶ [0143] In this regard, the sequence of combining steps of the technology described herein will operate to progressively combine, for each thread, data values from other execution lanes, such that at any given time, a respective thread will store the combined data values for a group of plural execution lanes. The number of execution lanes that a thread stores the data values for will depend upon the number and configuration of the combing steps, but in the case where the combining steps combine the execution lanes in a progressive, pairwise, manner, then after the first combining step, a thread will have the combined data value for a pair of execution lanes, after the next combining step the thread will have the combined data value of two pairs of execution lanes (so four execution lanes), and after the third combining step, the thread will have the combined data value for a group of eight execution lanes (and so on, if required. Additional details of the combination at Fig.6 below and ¶ [0237], ¶ [0265]).
PNG
media_image3.png
712
588
media_image3.png
Greyscale
Petit Fig.6 in support of rejection arguments
It would have been obvious to one skilled in the art, before the effective filling date of the claimed invention, to have modified Vega’s methods to have included Petit teachings in order to have provided more efficiency and improvement (Petit ¶ [0011] in view MPEP 2143 G, C and/or D) including improvements to the performing of operations’ reduction (Petit ¶ [0014] in view of MPEP 2143 G, C and/or D). The predictability of such modification would have been corroborated by the broad level of skills of one of ordinary skills in the art as articulated by Vega ¶ [0097] in view of Petit ¶ [0121], ¶ [0185], ¶ [0194], ¶ [0197], ¶ [0202], ¶ [0286]
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of endeavor dealing with event rule processing using. In such combination each element would have merely performed same analytical and storage function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given the existing technical ability to combine the elements as evidenced by Vega in view of Petit, the to be combined elements would have fitted together, like puzzle pieces in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (MPEP 2143 A).
--
Conclusion
Following art is made of record and considered pertinent to Applicant’s disclosure:
- Fu et al, Smart os scheduling for serverless functions, InSC22 International Conference for High Performance Computing, Networking, Storage and Analysis, p1-p16, IEEE, 2022, Nov 13, 2022
- WO-2013119786 A2 teaching Selectively triggering execution of services in a computing environment
- US 20230214267 A1 teaching Optimizing resource utilization based on quota trees in resource scheduling
- US 20230214257 A1 teaching Using multiple quota trees in resource scheduling
- US 20080046873 A1 reciting the following:
¶ [0052] At step 90, the disclosed system determines the intersection of the master command tree and the operative command tree by performing a logical "AND" operation on the master command tree and operative command tree. As a result, an actual command tree is created that includes only those tree nodes and/or vertices that are contained in both the master command tree and the operative command tree. The actual command tree generated at step 90 is then used by the disclosed control system to present device and associated command options to the user, for example audibly and/or through a graphical user interface, and to process commands received from the user.
¶ [0079] Fig.19 shows an example of an operative command tree 230 reflecting user specific command configuration information. For example, the operative command tree 230 may be formed based on the user specific configuration files 58 shown in FIG. 2. FIG. 20 shows an example of an actual command tree 240 formed as a result of performing a logical "AND" operation between the master command tree 220 of FIG. 18 and the operative command tree 230 of FIG. 19. The actual command tree 240 only includes those command tree components that are contained in both the master command tree 220 and the operative command tree 230. Thus the actual command tree 240 reflects the intersection of the master command tree 220 and the operative command tree 230. Moreover, the order and/or arrangement of the command tree components in the actual command tree 240 reflect the order and/or arrangement of the command tree components in the operative command tree 230. Accordingly, since the order in which commands are presented to the user is based on the actual command tree 240, the user is provided with a user interface experience that reflects the user specific operative command tree 230.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to OCTAVIAN ROTARU whose telephone number is (571)270-7950. The examiner can normally be reached on 571.270.7950 from 9AM to 6PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICIA H MUNSON, can be reached at telephone number (571)270-5396. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/OCTAVIAN ROTARU/
Primary Examiner, Art Unit 3624 A
June 24th, 2026
1 Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362
TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016);
OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015);
buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014)
2 OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93;
3 Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014);
Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755;
4 Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015);
OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;
5 Flook, 437 U.S. at 594, 198 USPQ2d at 199); and Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012)
6 Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1331, 115 USPQ2d 1681, 1699 (Fed. Cir. 2015).
Prosecution Insights