DETAILED ACTION
Notice to Applicant
This Office Action is responsive to amendment filed 16 October 2025.
Claims 1, 2, 11, 12, and 20 are amended.
Claims 1-20 are pending.
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 an abstract idea without significantly more.
Claim 1 recites detecting an event that comprises a state object, a journey identifier, and a timestamp associated with occurrence of the event; mapping the event to a journey based on the journey identifier and the timestamp associated with the occurrence of the event, the mapping of the event including determining that the event satisfies at least one user-defined rule associated with the journey; identifying a state machine associated with the journey; and processing, using the state machine, the event based on the state object in accordance with one or more steps defined for the journey, which is an abstract method of organizing human activity (i.e., commercial interactions, managing personal behavior or interactions between people).
The additional elements unencompassed by the abstract idea include “a software library.” The abstract idea is not integrated into a practical application because the additional elements merely serve as generic computer components on which the abstract idea is implemented. See MPEP 2106.05(f).To the extent that the claimed “state machine” (defined as a “computational model”) arguably implicitly includes some type of computer hardware, the abstract idea is not integrated into a practical application because the additional elements merely serve as generic computer components on which the abstract idea is implemented. See MPEP 2106.05(f).
The claim does not include limitations sufficient, either alone or in combination, to amount to significantly more than the claimed abstract idea because the aforementioned additional elements merely serve as generic computer components on which the abstract idea is implemented. See MPEP 2106.05(f).
Claims 3-9 recite the receipt, evaluation, and output of information and thus further describe the abstract idea. The abstract idea is not integrated into a practical application because the additional elements merely serve as generic computer components on which the abstract idea is implemented. See MPEP 2106.05(f). The claims do not include limitations sufficient, either alone or in combination, to amount to significantly more than the claimed abstract idea because the aforementioned additional elements merely serve as generic computer components on which the abstract idea is implemented. See MPEP 2106.05(f).
Claims 2 and 10 recite substantially the same abstract idea as claim 1. The additional elements unencompassed by the abstract idea include a JSON object. The abstract idea is not integrated into a practical application because the additional elements merely serve as generic computer components utilized in the implementation of the abstract idea. See MPEP 2106.05(f). The claims do not include limitations sufficient, either alone or in combination, to amount to significantly more than the claimed abstract idea because the aforementioned additional elements merely serve as generic computer components utilized in the implementation of the abstract idea. See MPEP 2106.05(f).
Claim 11 recites detecting an event that comprises a state object, a journey identifier, and a timestamp associated with occurrence of the event; mapping the event to a journey based on the journey identifier and the timestamp associated with the occurrence of the event, the mapping of the event including determining that the event satisfies at least one user-defined rule associated with the journey; identifying a state machine associated with the journey; and processing, using the state machine, the event based on the state object in accordance with one or more steps defined for the journey, which is an abstract method of organizing human activity (i.e., commercial interactions, managing personal behavior or interactions between people).
The additional elements unencompassed by the abstract idea include one or more hardware processors, a non-transitory machine-readable medium for storing instructions, and a software library. The abstract idea is not integrated into a practical application because the additional elements merely serve as generic computer components on which the abstract idea is implemented. See MPEP 2106.05(f).
The claims do not include limitations sufficient, either alone or in combination, to amount to significantly more than the claimed abstract idea because the aforementioned additional elements merely serve as generic computer components on which the abstract idea is implemented. See MPEP 2106.05(f).
Claim 12 recites substantially the same abstract idea as claim 11. The additional elements unencompassed by the abstract idea include a JSON object. The abstract idea is not integrated into a practical application because the additional elements merely serve as generic computer components utilized in the implementation of the abstract idea. See MPEP 2106.05(f). The claims do not include limitations sufficient, either alone or in combination, to amount to significantly more than the claimed abstract idea because the aforementioned additional elements merely serve as generic computer components utilized in the implementation of the abstract idea. See MPEP 2106.05(f).
Claims 13-19 recite the receipt, evaluation, and output of information and thus further describe the abstract idea. The abstract idea is not integrated into a practical application because the additional elements merely serve as generic computer components on which the abstract idea is implemented. See MPEP 2106.05(f). The claims do not include limitations sufficient, either alone or in combination, to amount to significantly more than the claimed abstract idea because the aforementioned additional elements merely serve as generic computer components on which the abstract idea is implemented. See MPEP 2106.05(f).
Claim 20 recites detecting an event that comprises a state object, a journey identifier, and a timestamp associated with occurrence of the event; mapping the event to a journey based on the journey identifier and the timestamp associated with the occurrence of the event, the mapping of the event including determining that the event satisfies at least one user-defined rule associated with the journey; identifying a state machine associated with the journey; and processing, using the state machine, the event based on the state object in accordance with one or more steps defined for the journey, which is an abstract method of organizing human activity (i.e., commercial interactions, managing personal behavior or interactions between people).
The additional elements unencompassed by the abstract idea include a non-transitory machine-readable medium for storing instructions. The abstract idea is not integrated into a practical application because the additional elements merely serve as generic computer components on which the abstract idea is implemented. See MPEP 2106.05(f).
The claims do not include limitations sufficient, either alone or in combination, to amount to significantly more than the claimed abstract idea because the aforementioned additional elements merely serve as generic computer components on which the abstract idea is implemented. See MPEP 2106.05(f).
Claim Rejections - 35 USC § 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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 3-9, 11, and 13-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Balakrishnan et al. (US 20240004903 A1).
As per claim 1, Balakrishnan discloses a method comprising:
detecting an event that comprises a state object, a journey identifier, and a timestamp associated with occurrence of the event (Balakrishnan [0020], Fig. 2 and accompanying text, [0022], [0038]. System receives real-time event and determines an attribute of a user profile. Journey identifier equivalent to experience journey identifications, e.g., “planning a vacation, using an amusement park, scheduling an event, opening an account, etc.” Orchestration triggers include event timestamps/dates thus these event timestamps/dates are detected.);
mapping the event to a journey based on the journey identifier and the timestamp associated with the occurrence of the event, the mapping of the event including determining, using a software library that the event satisfies at least one user-defined rule associated with the journey (Balakrishnan [0027], [0038], [0058]-[0061]. User defined orchestration trigger triggers performance of system action upon detection of event. Determining a journey state of the user with respect to the experience journey);
identifying a state machine associated with the journey (Balakrishnan [0058]-[0061] Determining a journey state of the user with respect to the experience journey utilizing journey state machine learning model); and
processing, using the state machine, the event based on the state object in accordance with one or more steps defined for the journey (Balakrishnan Fig. 2, steps 208/210. Determining and implementing system action responsive to event).
As per claim 3, Balakrishnan discloses the method of claim 1, wherein each step in the journey is associated with metadata that is used to reference another step within the journey or a step in another journey, wherein the state machine is used to model a plurality of states associated with an entity (Balakrishnan [0049] Received data indication of event includes metadata corresponding to associated user including, e.g., previous actions taken on journey, i.e., references to other steps during journey).
As per claim 4, Balakrishnan discloses the method of claim 1, wherein the journey comprises one or more steps sequentially arranged in a logical order, the journey allowing a user to trigger an operation associated with a step of the journey once an operation associated with a previous step of the journey has been triggered (Balakrishnan [0062] – [0063]).
As per claim 5, Balakrishnan discloses the method of claim 1, wherein the journey corresponds to a workflow that comprises one or more steps, and wherein the journey is configured by a user via a user interface of a device (Balakrishnan Figs. 5A-5C and corresponding text. Interface(s) controlling orchestration triggers.).
As per claim 6, Balakrishnan discloses the method of claim 1, wherein the event corresponds to a system-generated event (Balakrishnan [0020]. Event may include user interaction or input, third-party system action, and/or an indication of a digital or physical occurrence.).
As per claim 7, Balakrishnan discloses the method of claim 1, wherein the event corresponds to a user-triggered event, and wherein each step of the one or more steps corresponds to an operation, comprising:
determining a current step in the journey that matches the user-triggered event (Balakrishnan [0038] journey state.);
identifying, from the journey, a subsequent step based on the current step (Balakrishnan [0038] subsequent event(s).); and
using the state machine to initiate an operation associated with the subsequent step based on satisfaction of one or more conditions of the current step, the satisfaction of one or more conditions of the current step dictating how an entity progresses from the current step to the subsequent step (Balakrishnan [0038] An orchestration trigger includes a combination of two or more of a data source, real-time event, an attribute, or a journey state that (upon detection) triggers performance of a system action as part of a trigger-action sequence. Upon selection of an orchestration trigger for inclusion within a trigger-action sequence, the data journey system performs (or causes another system to perform) a system action in the form of a subsequent event or multiple subsequent events.).
As per claim 8, Balakrishnan discloses the method of claim 1, wherein the event is a first event, comprising:
detecting a second event associated with an entity (Balakrishnan [0020], Fig. 2 and accompanying text. System receives real-time event and determines an attribute of a user profile.);
determining, based on content of the event, that the second event does not map to any definition of a journey associated with the entity (Balakrishnan [0055] supplementing for insufficient data. Event does not correspond to attribute of user profile due to insufficient data.); and
generating a state machine based on the second event, the state machine handling one or more journeys to be configured by the entity, the state machine modeling each step in a journey to initiate each operation associated with each step based on a current state of the entity (Balakrishnan [0055]-[0057]. The data journey system utilizes the similar user profiles to make one or more assumptions to supplement for insufficient data. Thus, the data journey system can utilize this supplemented data to determine the future action scores for the user profile. The data journey system can utilize potential future action scores and predicted user actions to determine system action.)
As per claim 9, Balakrishnan discloses the method of claim 1, the mapping the event to the journey based on content of the event further comprises: using a software library to match a plurality of rules against the content of the event (Balakrishnan [0035] system action includes implementing particular rules within a computer system.).
As per claim 11, Balakrishnan discloses a system comprising: one or more hardware processors; and a non-transitory machine-readable medium for storing instructions (Balakrishnan [0041] server) that, when executed by the one or more hardware processors, cause the one or more hardware processors to perform operations comprising:
detecting an event that comprises a state object, a journey identifier, and a timestamp associated with occurrence of the event (Balakrishnan [0020], Fig. 2 and accompanying text, [0022], [0038]. System receives real-time event and determines an attribute of a user profile. Journey identifier equivalent to experience journey identifications, e.g., “planning a vacation, using an amusement park, scheduling an event, opening an account, etc.” Orchestration triggers include event timestamps/dates thus these event timestamps/dates are detected.);
mapping the event to a journey based on the journey identifier and the timestamp associated with the occurrence of the event, the mapping of the event including determining, using a software library that the event satisfies at least one user-defined rule associated with the journey (Balakrishnan [0027], [0038], [0058]-[0061]. User defined orchestration trigger triggers performance of system action upon detection of event. Determining a journey state of the user with respect to the experience journey);
identifying a state machine associated with the journey (Balakrishnan [0058]-[0061] Determining a journey state of the user with respect to the experience journey utilizing journey state machine learning model); and
processing, using the state machine, the event based on the state object in accordance with one or more steps defined for the journey (Balakrishnan Fig. 2, steps 208/210. Determining and implementing system action responsive to event).
As per claim 13, Balakrishnan discloses the system of claim 11, wherein each step in the journey is associated with metadata that is used to reference another step within the journey or a step in another journey, wherein the state machine is used to model a plurality of states associated with an entity (Balakrishnan [0049] Received data indication of event includes metadata corresponding to associated user including, e.g., previous actions taken on journey, i.e., references to other steps during journey).
As per claim 14, Balakrishnan discloses the system of claim 11, wherein the journey comprises one or more steps sequentially arranged in a logical order, the journey allowing a user to trigger an operation associated with a step of the journey once an operation associated with a previous step of the journey has been triggered (Balakrishnan [0062] – [0063]).
As per claim 15, Balakrishnan discloses the system of claim 11, wherein the journey corresponds to a workflow that comprises one or more steps, and wherein the journey is configured by a user via a user interface of a device (Balakrishnan Figs. 5A-5C and corresponding text. Interface(s) controlling orchestration triggers.).
As per claim 16, Balakrishnan discloses the system of claim 11, wherein the event corresponds to a system- generated event (Balakrishnan [0020]. Event may include user interaction or input, third-party system action, and/or an indication of a digital or physical occurrence.).
As per claim 17, Balakrishnan discloses the system of claim 11, wherein the event corresponds to a user-triggered event, and wherein each step of the one or more steps corresponds to an operation, and wherein the operations comprise:
determining a current step in the journey that matches the user-triggered event (Balakrishnan [0038] journey state.);
identifying, from the journey, a subsequent step based on the current step (Balakrishnan [0038] subsequent event(s).); and
using the state machine to initiate an operation associated with the subsequent step based on satisfaction of one or more conditions of the current step, the satisfaction of one or more conditions of the current step dictating how an entity progresses from the current step to the subsequent step (Balakrishnan [0038] An orchestration trigger includes a combination of two or more of a data source, real-time event, an attribute, or a journey state that (upon detection) triggers performance of a system action as part of a trigger-action sequence. Upon selection of an orchestration trigger for inclusion within a trigger-action sequence, the data journey system performs (or causes another system to perform) a system action in the form of a subsequent event or multiple subsequent events.).
As per claim 18, Balakrishnan discloses the system of claim 11, wherein the event is a first event, and wherein the operations comprise:
detecting a second event associated with an entity (Balakrishnan [0020], Fig. 2 and accompanying text. System receives real-time event and determines an attribute of a user profile.);
determining, based on content of the event, that the second event does not map to any definition of a journey associated with the entity (Balakrishnan [0055] supplementing for insufficient data. Event does not correspond to attribute of user profile due to insufficient data.); and
generating a state machine based on the second event, the state machine handling one or more journeys to be configured by the entity, the state machine modeling each step in a journey to initiate each operation associated with each step based on a current state of the entity (Balakrishnan [0055]-[0057]. The data journey system utilizes the similar user profiles to make one or more assumptions to supplement for insufficient data. Thus, the data journey system can utilize this supplemented data to determine the future action scores for the user profile. The data journey system can utilize potential future action scores and predicted user actions to determine system action.)
As per claim 19, Balakrishnan discloses the system of claim 11, the mapping the event to the journey based on content of the event further comprises: using a software library to match a plurality of rules against the content of the event (Balakrishnan [0035] system action includes implementing particular rules within a computer system.).
As per claim 20, Balakrishnan discloses a non-transitory machine-readable medium for storing instructions (Balakrishnan [0041] server) that, when executed by one or more hardware processors, cause the one or more hardware processors to perform operations comprising:
detecting an event that comprises a state object, a journey identifier, and a timestamp associated with occurrence of the event (Balakrishnan [0020], Fig. 2 and accompanying text, [0022], [0038]. System receives real-time event and determines an attribute of a user profile. Journey identifier equivalent to experience journey identifications, e.g., “planning a vacation, using an amusement park, scheduling an event, opening an account, etc.” Orchestration triggers include event timestamps/dates thus these event timestamps/dates are detected.);
mapping the event to a journey based on the journey identifier and the timestamp associated with the occurrence of the event, the mapping of the event including determining, using a software library that the event satisfies at least one user-defined rule associated with the journey (Balakrishnan [0027], [0038], [0058]-[0061]. User defined orchestration trigger triggers performance of system action upon detection of event. Determining a journey state of the user with respect to the experience journey);
identifying a state machine associated with the journey (Balakrishnan [0058]-[0061] Determining a journey state of the user with respect to the experience journey utilizing journey state machine learning model); and
processing, using the state machine, the event based on the state object in accordance with one or more steps defined for the journey (Balakrishnan Fig. 2, steps 208/210. Determining and implementing system action responsive to event).
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.
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 2, 10, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over by Balakrishnan et al. (US 20240004903 A1)in view of Popelka et al. (US 20230031718 A1).
As per claim 2, Balakrishnan discloses the limitations of claim 1 as discussed above. Although Balakrishnan discloses the utilization of JAVASCRIPT [0133] and application of entity-defined rules [0035], Balakrishnan does not explicitly mention the phrase “JavaScript Object Notation (JSON) object.” However, Popelka discloses structuring workflow data in JSON format (Popelka [0033]). Both Balakrishnan and Popelka are directed to workflow modeling. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add Popelka’s features to Balakrishnan as the use of a known workflow modeling coding language to improve similar workflow modeling in the same way. Furthermore, all of the claimed elements were known in the prior arts of Balakrishnan and Popelka and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results to one of ordinary skill in the art before the effective filing date of the claimed invention.
As per claim 10, Balakrishnan discloses the limitations of claim 9 as discussed above. Although Balakrishnan discloses the utilization of JAVASCRIPT [0133] and application of entity-defined rules [0035], Balakrishnan does not explicitly mention the phrase “JavaScript Object Notation (JSON) object.” However, Popelka discloses structuring workflow data in JSON format (Popelka [0033]). Both Balakrishnan and Popelka are directed to workflow modeling. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add Popelka’s features to Balakrishnan as the use of a known workflow modeling coding language to improve similar workflow modeling in the same way. Furthermore, all of the claimed elements were known in the prior arts of Balakrishnan and Popelka and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results to one of ordinary skill in the art before the effective filing date of the claimed invention.
As per claim 12, Balakrishnan discloses the limitations of claim 11 as discussed above. Although Balakrishnan discloses the utilization of JAVASCRIPT [0133] and application of entity-defined rules [0035], Balakrishnan does not explicitly mention the phrase “JavaScript Object Notation (JSON) object.” However, Popelka discloses structuring workflow data in JSON format (Popelka [0033]). Both Balakrishnan and Popelka are directed to workflow modeling. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add Popelka’s features to Balakrishnan as the use of a known workflow modeling coding language to improve similar workflow modeling in the same way. Furthermore, all of the claimed elements were known in the prior arts of Balakrishnan and Popelka and one skilled in the art could have combined the elements as claimed by known methods with no change in their respective functions, and the combination would have yielded predictable results to one of ordinary skill in the art before the effective filing date of the claimed invention.
Response to Arguments
The Rejection of Claims Under § 101
Applicant submits that “the claims reflect an improvement to event processing and state machine-based workflow management technology by providing a technical solution for efficiently mapping and processing events based on event metadata rather than static workflow assignment, thereby improving system synchronization, data integrity, and processing efficiency in distributed computing environments.” Applicant attempts to support this conclusion by listing a series of steps to which Examiner responds in turn:
“Detecting an event that includes a state object, a journey identifier, and a timestamp, which enforces a structured metadata schema ensuring accurate temporal and contextual correlation across asynchronous systems.” Observation of an event including three pieces of information describes an abstract idea. Correlating information with other information describes an abstract idea. No “asynchronous systems” are present in the claims. The alleged improvement is not to the functioning of a computer, network, database, or other technical component, but rather to the logic of the abstract event-processing scheme itself—namely, how events are associated with journeys, rules, and state transitions. Improving the way abstract event data is organized, evaluated, and routed is still an improvement in the abstract idea, not an improvement to computer technology. In other words, the claims do not recite a new computer architecture, new data structure at a technical level, or a specific improvement to a computer’s operation. They merely use conventional computing components to carry out the abstract idea of mapping, evaluating, and transitioning events according to rules and state machines.
“Mapping the event to a journey based on the journey identifier and timestamp, ensuring correct temporal ordering of concurrent or overlapping event streams. This is not achievable through conventional rule engines that lack integrated temporal correlation.” Mapping an event to a journey based on metadata is the type of classification, association, and organization of information that are treated as abstract. The claim is still directed to deciding what event belongs where, which is part of the abstract idea. Also, the argument relies on an unsupported assertion that conventional rule engines lack such functionality. Even if true, the claim does not recite a specific technological improvement to a rule engine or event-stream processor. Instead, the claim merely applies rule evaluation and event association at a high level. Mapping information to other information based on rules describes an abstract idea. Even assuming that “conventional rule engines . . . lack integrated temporal correlation,” temporal correlation of information to other information at best describes an improvement to an abstract idea itself. The asserted benefit, i.e., better ordering or less mis-correlation, is an improvement in the abstract processing logic, not in the underlying computer technology.
“Determining, using a software library, that the event satisfies at least one user-defined rule associated with the journey. This uses programmable interfaces and runtime libraries that evaluate rules dynamically without hard-coding logic into application layers, allowing for low-latency, scalable execution.” No “programmable interfaces and runtime libraries that evaluate rules dynamically without hard-coding logic into application layers” and it is unclear from Applicant’s argument how applying a rule to data “allow(s) for low-latency, scalable execution.” The claim does not recite a specific library architecture or technical optimization. For instance, the claims do not specify a particular library structure, a particular API, a particular runtime mechanism, a particular caching strategy, a particular concurrency model, or a particular latency-reduction technique. Without such specifics, the “software library” is just a generic software implementation of the abstract idea of applying rules to data. Additionally, the alleged improvement is to the abstract idea itself. The supposed improvement, i.e., dynamic rule evaluation or low-latency decisioning, describes improved execution of the rule-based abstract logic itself, not a new or improved computer technology.
“Identifying a state machine associated with the journey to provide deterministic control over transitions, reducing processing overhead, and avoiding redundant computations.” It is unclear from Applicant’s argument how identifying a model “provide(s) deterministic control over transitions, reducing processing overhead, and avoiding redundant computations.” A state machine, as claimed here, is being used as a logical framework for organizing event processing, which is part of the abstract idea. The claim does not recite a specific technological improvement to state-machine implementation. It merely says to use a state machine to process events. The alleged advantages—deterministic transitions, reduced overhead, fewer redundant computations—are benefits of the abstract workflow logic. They do not show that the claims improve how a computer operates at a technical level. Instead, they show that the abstract process itself is being made more efficient.
“Processing the event using the state machine in accordance with one or more steps defined for the journey, ensuring consistent state transition management across distributed nodes.” Evaluating information using a model describes an abstract idea. This limitation still recites only abstract orchestration of information and workflow. The claims do not specify any distributed-system protocol, consensus mechanism, replication strategy, fault-tolerance technique, synchronization algorithm, or other concrete distributed-computing improvement.
The phrase “distributed nodes” appears to be invoked at a high level, but the claims do not actually recite the technical machinery necessary to improve distributed computing. Accordingly, this is still an abstract workflow rule, not a technological improvement.
Applicant argues that the event’s state object, journey identifier, and timestamp create a “structured digital object” that standardizes event representation. This is unpersuasive. The claims do not recite a novel data structure in the technical sense. They merely recite that the event includes certain fields. That is a conventional way of representing data. For example, the claims fail to recite any new memory layout, new packet format, new serialization scheme, new database schema, new indexing method, new data compression or integrity mechanism, etc. Accordingly, this is not a technical improvement to data structure design.
Applicant contends that the software library enables “extensible, low-latency evaluation” and improves throughput. This argument does not establish eligibility because the claims do not recite any specific runtime optimization technique. The claims merely use a software library to perform rule evaluation. The alleged advantages are the result of performing the abstract rule-evaluation process more efficiently, not of reciting a particular technological advance in computer operation.
Applicant’s analogy to McRO v. Bandai Namco is unpersuasive. In McRO, the claims recited a specific set of rules that improved how computer animation was generated, replacing a traditionally subjective manual process with a particular automated technique. The court found that the claimed rules were directed to a specific technological improvement in computer animation. Here, by contrast, the claims do not recite a similarly specific technological rule set for improving computer function. They recite generic steps of: detecting information, mapping information, determining that information satisfies a rule, identifying a model, and applying the model to information.
That is not the kind of specific computer-animation rule structure at issue in McRO. The alleged improvement here is simply better event governance or workflow decisioning, which remains an abstract idea.
Applicant argues that mapping based on journey identifier and timestamp improves correlation accuracy and reduces lookup cycles. This is not persuasive because the claim is still directed to using metadata to correlate and organize events. That is an abstract information-processing activity. The asserted reduction in database lookups or improved throughput is not supported by any specific claimed technical mechanism. The claims do not recite, e.g., a particular indexing scheme,
a particular query optimization, a particular cache structure, a particular event-ordering algorithm, or a particular timing synchronization technique. Consequently, the claim remains an abstract process of organizing information.
Applicant argues that embedding metadata, rule evaluation, and state transitions in a single execution flow reduces redundant polling and post-processing. This argument is unpersuasive because the claims do not actually recite the technical means by which polling is reduced or consistency is improved. They merely recite the abstract processing sequence. The purported benefits are the expected results of doing the abstract workflow more efficiently. That is not a technological improvement for purposes of § 101.
For these reasons, Applicant’s arguments are not persuasive.
The Rejection of Claims Under §§ 102 & 103
Applicant submits that Balakrishnan “refers merely to generic user activity data, without identifying any event that comprises a state object, journey identifier, and timestamp.” Examiner respectfully disagrees and submits that Balakrishnan’s orchestration triggers evaluate received events. Such events include “state objects” including user profile attributes as well as user interaction or input. Balakrishnan [0020]. What Applicant refers to as “generic user activity data” nevertheless reads on the Specification definition of “state object,” i.e., “a state of a user and/or a state of an action associated with a user.” Spec. [0017]. The claimed “journey identifier” is equivalent to experience journey identifications, e.g., “planning a vacation, using an amusement park, scheduling an event, opening an account, etc.” Balakrishnan [0020] Orchestration triggers further include event timestamps/dates thus these event timestamps/dates are detected. Balakrishnan [0038]. Consequently, Balakrishnan discloses detection of an “event that comprises a state object, journey identifier, and timestamp.” For these reasons, Applicant’s argument is not persuasive.
Applicant submits that “(n)o portion of Balakrishnan discloses event-level metadata fields, nor a mapping operation that uses a journey identifier and a timestamp as claimed” because the referenced “process focuses on classifying a user’s state within an existing experience journey, rather than mapping an incoming event to a particular journey using explicit identifiers and timestamps.” Examiner respectfully disagrees and submits that Balakrishnan’s user attributes correspond (i.e., “map”) to incoming events which include timestamps/dates. Balakrishnan [0038]. For these reasons, Applicant’s argument is not persuasive.
Applicant submits that Balakrishnan’s “rules are internal orchestration triggers used by the system to select automated responses” and not “user-defined rules executed by a software library to determine whether a detected event should be mapped to a journey.” Examiner respectfully disagrees and submits that Figs. 5A-5C and accompanying text demonstrate user creation of orchestration triggers, i.e., user-defined rules. For this reason, Applicant’s argument is not persuasive.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEFF ZIMMERMAN whose telephone number is (571)272-4602. The examiner can normally be reached Monday - Thursday 6:00 am - 2:00 pm.
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, Jeff Zimmerman can be reached at (571)272-4602. 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.
JEFF ZIMMERMAN
Supervisory Patent Examiner
Art Unit 3628
/JEFF ZIMMERMAN/Supervisory Patent Examiner, Art Unit 3628
Prosecution Insights