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 (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.
DETAILED ACTION
The following FINAL Office Action is in response to communication filed on 10/20/2025.
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.
The Examiner has noted the Applicants claiming Priority from Foreign Application IN202241071882 filed 12/13/2022.
Status of Claims
Claims 1-8, 10-14, 16-18, 20-23 are currently pending.
Claims 1, 5, 7, 14, 20 are amended.
Claims 9, 15, 19 are cancelled.
Claims 21-23 are new.
Claims 1-8, 10-14, 16-18, 20-23 are currently under examination and have been rejected as follows.
IDS
The information disclosure statements filed on 02/20/2023 and 10/20/2023 comply with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609 and is considered by the Examiner.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Response to Amendment
The previously pending claim objections are withdrawn in view of the amendments.
The previously pending rejections under 35 USC 101, will be maintained. The 101 rejection is updated in view of the amendments.
The previously pending rejections under 35 USC 102 are withdrawn in view of the amendments.
New grounds for rejection 35 USC 103 are applied as necessitated by the amendments.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Response to Arguments
Regarding Applicant’s remarks pertaining to 35 USC 101:
Step 2A Prong 1:
Applicant argues on page 8 of remarks 10/20/2025:
“The present claim, as amended, recites a system for managing state transitions and handling locks within a computing system. In particular, it involves a state engine configured to inject one or more rescue factors, as well as an action identification component that identifies actions associated with the target state based on the rescue factors. These actions include spawning actions that inherit a held lock. The claim recites a specific, technological solution to a technical problem of state management and concurrent lock handling thereby improving the performance and functionality of the system.
Continued on page 9: “…not every claim that involves a computer or computational process is necessarily directed to an abstract idea….
“The injection of rescue factors to trigger actions that depend on the state of the system,
combined with the lock inheritance mechanism, provides a concrete solution that ensures the system behaves as intended during recovery. This involves specific, technical processes that are
distinct from a general idea of state management or lock control.
“Therefore, the claim is not directed to an abstract idea, as it addresses a technological improvement to the functionality of a computing system, particularly with regard to concurrency and state management.”
Examiner respectfully disagrees. Examiner submits that state machines can be designed in an unlimited number of specific, unique configurations. The state machine in the instant application, consistent with state machines generally, receives inputs, then makes associations and evaluations based on inputs and conditions. Though substituted for a human, the computer-implemented state machine makes observations, evaluations, and judgements the same way a human would in a mental process. The claims describe “rescue factors” which Examiner interprets as inputs (see Applicant specification ¶ [0034]) and “lock” inheritance as an “if/then” logical evaluation mechanism for deciding whether to act (see Applicant specification ¶ [0041]). Examiner also points to MPEP2106.04(a)(2) III C finding that computer aided processes such as: 1. Performing a mental process on a generic computer, 2. Performing a mental process in a computer environment, 3. Using a computer as a tool to perform a mental process can still be considered to recite a mental process.
Step 2A Prong 2:
Applicant argues on page 10 of remarks 10/20/2025:
“The claim, as amended… recites technical elements such as a state engine, an action identification component, and the injection of rescue factors, all of which are specialized to solve a technical problem, and which are not mathematical concepts, mental processes nor human activity. The problem it addresses is related to efficiently managing state transitions and locks in a computer system and improving the performance and functionality of the system.
Continued on page 11: “The state engine that injects rescue factors is a specific mechanism configured to assess the system's state and adjust the system's behavior based on dynamic conditions.
“The action identification component analyzes the system state and identifies appropriate recovery actions based on the injected rescue factors… which is a technological solution.
“The spawning of actions that inherit a held lock ensures that recovery actions are executed only when the system is in a locked state, preventing improper transitions. This is a specific feature that adds control and integrity to the system….
“…The claim thus recites an improvement in a technical field.
Continued on page 12: “Amended independent claim 1 recites a specific improvement for the arrangement and operation of a state engine for roadside vehicle rescue purposes. Accordingly, Applicant respectfully submits amended independent claim 1 recites an integration
into a practical application under Prong Two of Step 2A”
Examiner respectfully disagrees. The claims as amended do not appear to recite any new computer-based additional elements besides data (such as injected rescue factors). The functions, as amended, of the original additional computer-based elements include examples such as “receive an input”, “identify whether the transition to the target state is valid”, “perform the transition to the target state”, “inject one or more rescue factors”, “perform one or more actions associated with the event”, and “identify one or more actions associated with the target state based on the one or more rescue factors, wherein the one or more actions include spawning actions that inherit a held lock”. While the functions are inherently technical, little technological explanation of how the functions are executed is included in the claims. Applicant specification ¶ [0042] provides examples of locks and lock releases, in other words, a logical framework for the behavior of the state machine based on input and condition data. However, the claims do not provide technical details of the improvement of a computer itself beyond the implied execution of “if/then”-type scenarios in a programming language. Further, specified actions performed by the additional elements appear to be limited to sending messages (see Applicant specification ¶ [0020, 0059]) as opposed impacting or focusing on the operation or performance of the state machine or the computer itself.
Step 2B:
Applicant argues on page 13 of remarks 10/20/2025:
“By reciting these specific, non-conventional elements the claim adds something significantly more than an abstract idea. The combination of elements in the claim provides a technical solution to a technical problem, namely, improving the management of system states and locks, which are integral to the functioning of modern computing environments.
“The claimed elements of amended independent claim 1, when considered in combination,
amount to significantly more than the alleged judicial exception of an abstract idea… the claimed elements of amended independent claim 1 are not well-understood, routine, or conventional, particularly when taken in context of the claim as a whole, which provides another factor for reciting more than an abstract idea.”
Examiner respectfully disagrees. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because per above, the additional computer-based elements merely apply the already recited abstract idea and link use of abstract idea to a field of use, such as roadside assistance, or technological environment, such as an automobile computer connected to a network (see MPEP 2106.05(f) and/or (h)). Specifically, Examiner follows the guidelines of MPEP 2106.05(d) II 2nd ¶ and caries over the analysis and conclusions reached on the MPEP 2106.05(f), and/or (h) tests to Step 2B, and submits that for the same reasons as articulated above, said computer-based additional elements also do not provide significantly more when considering MPEP 2106.05(f) and/or (h) as sufficient option(s) of evidence, without the need to rely on the well-understood, routine and conventional test, as submitted by Applicant. Assuming, arguendo, further evidence would be required to demonstrate conventionality of the additional, computer-based elements, Examiner would further rely on MPEP 2106.05(d) guidelines to demonstrate that said additional elements are also well-understood, routine, conventional. In such case, Examiner would rely as evidence on Applicant’s own specification at ¶ [0004-0005] describing well known features of a state machine including event input, condition verification, state transition, target states, and action triggers. Therefore, the additional elements recited in the claimed invention individually and in combination fail to provide significantly more (Step 2B).
The previously pending rejections under 35 USC 101, will be maintained. The 101 rejection is updated in view of the amendments.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Regarding Applicant’s remarks pertaining to 35 USC 102/103:
Applicant argues on page 15 of remarks 10/20/2025:
“Beek discusses general automotive service-oriented computing for on-road assistance scenarios, focusing on formal verification methods rather than operational rescue state management. In particular, Beek does not teach or suggest a state engine that injects rescue factors. Beek also does not disclose an action identification component that identifies actions based on rescue factors.
“…The [Beek’s] focus is on design-time verification of correctness properties using formal methods rather than operational management of live rescue systems.
“Beek is also missing any disclosure of rescue factor injection by a state engine, operational rescue intelligence integrated into state machine processing, or dynamic rescue parameter injection during state transitions.”
Examiner considers Applicant’s argument but finds it moot on new grounds. Applicant specification describes examples of “rescue factors” at ¶ [0034]: “The factors may be specific to a type of rescue. For example, suppose the rescue is a towing operation. In that case, the rescue factors may include a type of towing, the initial estimated time of arrival compared to a current estimated time of arrival, or the estimated time of arrival compared to a classification (e.g., importance) of the rescue.” As the independent claims as amended recite the limitation “inject one or more rescue factors”, Examiner presents reference MacGabann US 20190313230 A1, hereinafter MacGabann, which, as an emergency response system incorporating a state machine algorithm (¶ [0225]), teaches the “rescue factor” amended limitations at ¶’s [0005, 0098, 0101, 0106] among others. Assuming, arguendo, Beek lacks specificity in scope of “operational management of live rescue systems”, MacGabann discloses this at ¶ [0124]: “FIG. 3D is a flowchart of an example process 300d for the dispatch operations subroutine of FIG. 2C. The dispatch operations subroutine can be implemented by the rescue management servers 120 in some implementations…. The responder application 135 can receive perpetual (e.g., real-time) location updates and/or status updates relating to the victim, and can also provide perpetual location and/or status updates relating to the emergency responder at block 317.”
Applicant argues on page 16 of remarks 10/20/2025:
“Specifically, Beek lacks disclosure of an action identification component, as Beek focuses on verification of predefined service interactions… rather than components that identify actions based on rescue factors. Beek also lacks disclosure of spawning actions, as Beek teaches static service orchestration verification rather than dynamic action spawning. Additionally, Beek lacks disclosure of lock inheritance for spawned actions, as Beek's context is academic verification methodology rather than operational concurrency control.”
Examiner respectfully disagrees. As presented above, MacGabann teaches the injection of rescue factors. Additionally, MacGabann teaches spawning, or triggering, actions based on rescue factors at end-¶ [0197]: “These codes may be organized as a hierarchy by the disclosed emergency response system 100, such that codes relating to specific injuries and emergency scenarios would be organized under a more general code for a type of emergency. Emergency type (6) may provide a rapid way for a user to request rescue without having to provide further information, and selection of this option may trigger transmission of the request.”
The lock inheritance is taught by Manfredi in ¶’s [0034, 0048] in combination with Beek and MacGabann, curing the deficiency of scope to include operational concurrency control in rescue operations. Furthermore, under Examiner’s broadest reasonable interpretation, an additional example of spawning actions with lock inheritance can be found at MacGabann end-¶ [0098]: “Emergency type (6) may provide a rapid way for a user to request rescue without having to provide further information, and selection of this option may trigger [EN: sp awn] transmission of the request [EN: which is “locked” if the user does not select this option].
Applicant argues on page 16 of remarks 10/20/2025:
“Beek cannot anticipate amended Claim 1 because it fundamentally addresses a different technical problem through a different technical approach. Beek discloses static verification methodology, not state engines that inject rescue factors for operational decision making… Beek provides academic verification of service properties, not operational action spawning mechanisms with concurrency control… Beek addresses design-time verification while amended claims address runtime rescue operations with dynamic intelligence processing.”
Continued on page 17: “Moreover, Applicant submits there would be no motivation to combine the Beek and Manfredi references because they address fundamentally different technical problems in different domains.
“Furthermore, Beek teaches away from the claimed dynamic rescue processing approach
by focusing on static verification of predefined service interactions.”
Examiner respectfully disagrees. Assuming, arguendo, that Beek lacks the operational, real-time, and dynamic scope Applicant submits, the deficiency is cured by MacGabann as detailed above. Notwithstanding, the overall technical approach of Beek as interpreted by Examiner is the application of a state machine to make decisions and initiate transitions and actions based on inputs and conditions for analogous purposes of roadside assistance (see Applicant specification ¶s [0003-0005] and Beek ¶ 1.), and reinforced by the real-time, dynamic, operational environmental characteristics of MacGabann (¶ [0124]).
Accordingly, the previously pending rejections under 35 USC 102 are withdrawn in view of the amendments, and new grounds for rejection 35 USC 103 are applied as necessitated by the amendments.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function. Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitations use a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier.
In this instant case:
Claim 1 is a “system” claim which recites:
“an interface of a state engine configured to receive an input [..];
“a verification component coupled to the interface, the verification component configured to identify whether the transition to the target state is valid [..]; and
“a transition component coupled to the verification component, the transition component configured to perform the transition to the target state [..]”.
Claim 4 is a “system” claim which recites:
“wherein the verification component is further configured to determine whether a current state of the state engine is allowed [..]
“the transition component being configured to perform the transition [..]”.
Claim 5 is a “system” claim which recites:
“further comprising a lock acquirer component configured to lock a state of the state engine [..]”.
Claim 7 is a “system” claim which recites:
“the state engine is configured to identify one or more rescue factors [..]; and
“an action identification component configured to identify one or more actions [..]”, and
“an action component configured to perform the one or more actions”.
Claim 9 is a “system” claim which recites:
“wherein the state engine is configured to determine whether the one or more rescue factors allow for the one or more actions to be performed”.
Claim 10 is a “system” claim which recites:
“wherein the action component is configured to perform the one or more actions by creating a message to be sent [..]”.
Claim 11 is a “system” claim which recites:
“a communication interface configured to receive an indication of an occurrence of an event [..]”.
Claim 12 is a “system” claim which recites:
“the state engine is configured to determine a rescue identifier indicating a type of the rescue operations;
“the state engine is configured to identify one or more rescue factors; [..]
“an action identification component configured to identify one or more actions to be performed [..]; and
“an action component configured to perform the one or more actions”.
Claim 13 is a “system” claim which recites:
“a lock acquirer component configured to lock a state of the state engine;
“an action component configured to perform one or more actions [..]; and
“a lock releaser component configured to unlock the state of the state engine [..]”.
Claim 14 is a “system” claim which recites:
“an interface of a state engine configured to receive an input [..];
“a verification component coupled to the interface, the verification component configured to identify whether the event is allowed [..]; and
“an action component coupled to the verification component, the action component configured to perform one or more actions [..]”.
Claim 15 is a “system” claim which recites:
“the verification component is configured to identify whether a current state of the state engine allowed for the event to occur”.
Claim 16 is a “system” claim which recites:
“[..] the verification component is configured to identify whether the transition to the target state is valid [..]; and
“the system further comprises a transition component coupled to the verification component, the transition component being configured to perform the transition to the target state”.
Claim 19 is a “system” claim which recites:
“the state engine is configured to identify one or more rescue factors associated with the one or more actions; and
“the system further comprising an action identification component configured to identify the one or more actions associated with a current state of the state engine [..]”.
Examiner interprets interface, verification component, transition component, lock acquirer component, state engine, action identification component, action component, communication interface, lock releaser component, and interface as generic placeholders followed by their respective functions of: identify, perform, determine, lock, receive, determine, and unlock and further not modified by sufficient structure. Thus, it appears that independent claims 1, 14 and dependent claims 4-5, 7, 9-13, 15-16, 19 invoke 35 USC 112(f).
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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-8, 10-14, 16-18, 20-23 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-8, 10-14, 16-18, 21-23 are directed to a system or machine which is a statutory category.
Claim 20 is directed to non-transitory computer-readable media or articles of manufacture which is a statutory category.
Step 2A Prong One: The claims recite, describe, or set forth a judicial exception of an abstract idea (see MPEP 2106.04(a)). Specifically, the claims recite, describe or set forth concepts performed in the human mind (including observation, evaluation, or judgement) including: “receive an input indicating a transition to a target state… associated with a vehicle rescue operation” (observation), “identify whether the transition to the target state is valid based on one or more constraints” (evaluation), “perform the transition to the target state based on the identification of whether the transition to the target state is valid” (judgement), “receive an input indicating an occurrence of an event associated with a vehicle rescue operation” (observation), “identify whether the event is allowed based on one or more constraints” (evaluation), and “perform one or more actions associated with the event based on the identification of whether the event is allowed” (judgement). Making observations about the operational state of a vehicle, making decisions about what is needed, and taking steps to rescue the vehicle/driver fall within concepts performed in the human mind (including observation, evaluation, or judgement) under the larger abstract grouping of Mental Processes (MPEP 2106.04(a)(2) III). Examiner also points to MPEP2106.04(a)(2) III C finding that computer aided processes such as: 1. Performing a mental process on a generic computer, 2. Performing a mental process in a computer environment, and 3. Using a computer as a tool to perform a mental process can still be considered to recite a mental process. Accordingly, the claims recite an abstract idea.
Step 2A Prong Two: Independent claims 1, 14, 20 recite the following additional elements: “system”, “interface”, “state engine”, “verification component”, “transition component”, “action component”, “non-transitory computer-readable media”, and “processors”. The functions of these additional computer-based elements include examples such as “receive an input”, “identify whether the transition to the target state is valid”, “perform the transition to the target state”, and “perform one or more actions associated with the event”. The additional elements are recited at a high level of generality (i.e. as a generic computer performing functions of receiving, identifying, communicating and presenting data, etc.) such that they amount to no more than mere instructions to apply the exception using generic computer components. Therefore, these functions can be viewed as not meaningfully different than a business method or mathematical algorithm being applied on a general-purpose computer as tested per MPEP 2106.05(f)(2)(i). The claims are directed to an abstract idea and the judicial exception does not integrate the abstract idea into a practical application.
Step 2B: According to MPEP 2106.05(f)(1), considering whether the claim recites only the idea of a solution or outcome i.e., the claims fail to recite the technological details of how the actual technological solution to the actual technological problem is accomplished. The recitation of claim limitations that attempt to cover an entrepreneurial and thus abstract solution to an entrepreneurial problem with no technological details on how the technological result is accomplished and no description of the mechanism for accomplishing the result do not provide significantly more than the judicial exception.
Dependent claims 5, 13 recite the additional element “lock acquirer component” and dependent claim 13 recites the additional element “lock releaser component”. Dependent claims 7, 12, 19 recite the additional element “action identification component”. Dependent claims 8, 11 recite the additional element “communication interface”. The additional elements are also recited at a high level of generality (i.e. as a generic computer performing functions of receiving, identifying, communicating and presenting data, etc.) such that they amount to no more than mere instructions to apply the exception using generic computer components.
Further, dependent claims 2-4, 6, 9-10, 15-18 merely incorporate the additional elements recited in claims 1, 14, 20 along with further narrowing of the abstract idea of claims 1, 14, 20 along with their execution of the abstract idea. Specifically, the dependent claims narrow the “system”, “interface”, “state engine”, “verification component”, “transition component”, “action component”, “non-transitory computer-readable media”, “processors”, “lock acquirer component”, “lock releaser component”, “action identification component”, and “communication interface” to capabilities such as determine, perform, verify, allow, receive, identify, send, create, lock, and unlock various forms of data such as inputs, states, events, transitions, messages, identifiers, factors, etc. which, when evaluated per MPEP 2106.05(f)(2) represent mere invocation of computers to perform existing processes. Therefore, the additional elements recited in the claimed invention individually and in combination fail to integrate a judicial exception into a practical application (Step 2A prong two) and for the same reasons they also fail to provide significantly more (Step 2B). Thus, claims 1-8, 10-14, 16-18, 20-23 are reasoned to be patent ineligible.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
REJECTIONS BASED ON PRIOR ART
Examiner Note: Some rejections will contain bracketed comments preceded by an “EN” that will denote an examiner note. This will be placed to further explain a rejection.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claim Rejections - 35 USC § 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 22-23 are rejected under 35 U.S.C. 103 as being unpatentable over:
Maurice H. ter Beek et al: "Formal verification of an automotive scenario in service-oriented computing", 30th International Conference on Software Engineering: ICSE 2008; May 10 - 18, 2008, Leipzig, Germany, Curran, Red Hook, NY, 10 May 2008 (2008-05-10), pages 613-622, XP058176262, DOI: 10.1145/1368088.1368173, hereinafter Beek, in view of
MacGabann US 20190313230 A1, hereinafter MacGabann. As per,
Regarding Claim 22:
A system for vehicle rescue, comprising:
an interface of a state engine configured to receive an input indicating a transition to a target state of the state engine, the target state being a state associated with a vehicle rescue operation (Beek Chapter 4.1: [..] Since our goal was to use UMC to verify properties expressed in UCTL, we formally defined the scenario as a set of communicating UML state machines [..]. Figure 2 depicts the UML structure diagram of the set of UML state machines and the subcomponents Bank Communication and Orchestrator are depicted in Figures 3 and 4, resp. Beek Chapter 3.2: In [22], the automotive architecture as defined within Sensoria is described and the requirements model of the on road assistance scenario [EN: vehicle rescue operation] is specified in UML 2.0 using a UML Profile [23]. This scenario consists of the components [..] Orchestrator: composes services to achieve goal [EN: target state] [..]. Since the workflow describing the service orchestration is one of the most interesting aspects of a service-oriented system, we depict it in Figure 1 as a UML 2.0 activity diagram. The orchestrator is triggered [EN: receives input] by an engine failure (in our case due to a low oil level) and consequently contacts the other components to compose the various services to reach its goal (in our case sending the driver a rental car and a tow truck to tow the stranded vehicle to a garage) [..]. The actions match operations of required and provided interfaces of the services, defined as ports of UML 2.0 components. [EN: Also see Figs. 1, 3, 4 and related text]);
a verification component coupled to the interface, the verification component configured to identify whether the transition to the target state is valid based on one or more constraints associated with the state engine (Beek mid-Chapter 2.3: The basic idea underlying UMC is that, given a state of an L2TS, the validity of a UCTL formula on that state can be evaluated by analyzing the transitions allowed in that state [EN: constraints] and the of a certain subformula in only some of the next reachable states, all this in a recursive way. [Also see verification component implied by subcomponents in Figs. 3, 4 and related text]); and
a transition component coupled to the verification component, the transition component configured to perform the transition to the target state based on the identification of whether the transition to the target state is valid (Beek Chapter 2.3: [..] the states of this L2TS are labelled with the observed structural properties of the system configurations (like the active substates of objects, the values of object attributes, etc.), while its transitions are labelled with the observed properties of the system evolutions (like which is the evolving object, which are the executed acions, etc. [Also see transition component implied by subcomponents in Figs. 3, 4 and related text]);
[..]
an action identification component configured to identify one or more actions associated with the target state based on the one or more rescue factors (Beek mid-Chapter 3.1: When the driver makes an appointment with the garage, the results of the in-vehicle diagnosis are automatically sent along [EN: action], allowing the garage to identify the spare parts needed to repair the car [EN: identified actions]. Similarly, when the driver orders a tow truck [EN: rescue factor, see ¶ 0034] of Applicant specification] and a rental car, the vehicle's GPS coordinates are sent along [EN: action]);
a communication interface configured to receive an indication of an occurrence of an event (Beek Chapter 4.2 Service Responsiveness: A service is responsive if it guarantees a response to each received request. An example of service responsiveness is expressed by the UCTL formula [..] which states that each time action requestCardCharge takes place, always at a certain moment action chargeResponseOK or chargeResponseFail takes place. More intuitively: If the Car requests the Bank to charge a credit card, then the Bank will surely reply with a notification [EN: update message] of either a successful or a failed attempt to charge the credit card);
wherein the verification component is configured to determine whether a current state of the state engine allows for the event to occur (Beek mid-Chapter 2.3: The basic idea underlying UMC is that, given a state of an L2TS, the validity of a UCTL formula on that state can be evaluated by analyzing the transitions allowed in that state [EN: constraints] and the of a certain subformula in only some of the next reachable states, all this in a recursive way); and
an action component configured to perform one or more actions associated with the event in response to the determination (Beek mid-Chapter 3.2: The orchestrator is triggered by an engine failure (in our case due to a low oil level) and consequently contacts [EN: action] the other components to compose the various services to reach its goal (in our case sending the driver a rental car and a tow truck to tow the stranded vehicle to a garage). Chapter 4.2 Service Responsiveness: A service is responsive if it guarantees a response to each received request. An example of service responsiveness is expressed by the UCTL formula [..] which states that each time action requestCardCharge takes place, always at a certain moment action chargeResponseOK or chargeResponseFail takes place. More intuitively: If the Car requests the Bank to charge a credit card, then the Bank will surely reply with a notification [EN: update message] of either a successful or a failed attempt to charge the credit card).
Although Beek teaches vehicle rescue operations using a state machine, Beek does not specifically teach injecting rescue factors, spawning actions, or inheriting locks.
However, MacGabann in analogous art of rescue operation systems with state machines teaches or suggests:
wherein the state engine is configured to inject one or more rescue factors (MacGabann end-¶ [0098]: In some embodiments, such a decision is based on many factors including battery life of the device, responder arrival time [EN: rescue factor, see ¶ [0034] of Applicant specification], the direction and velocity of a victim's travel, and the severity of a victim's emergency during the emergency response request. ¶ [0106]: tr is the responder arrival time, which may comprise an amount of time before the responder arrives at a location of the victim. In some embodiments, the responder arrival time is pinged from the server 120 and/or predicted client-side, depending on battery life, determination of the best network, and so forth. Mid-¶ [0124]: The responder application 135 can receive perpetual (e.g., real-time) location updates and/or status updates relating to the victim, and can also provide perpetual location and/or status updates relating to the emergency responder at block 317. ¶ [0225]: The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software that runs on computer hardware, or combinations of both. A processor device can be a microprocessor, but in the alternative, the processor device can be a controller, microcontroller, or state machine, combinations of the same, or the like)
MacGabann and Beek are found as analogous art of rescue operation systems with state machines. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Beek’s automotive scenario state machine system and method to have included MacGabann’s teachings around injecting rescue factors. The benefit of these additional features would have improved automated triaging and dispatch for rescue operations (MacGabann ¶ [0029]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Beek in view of MacGabann (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of rescue operation systems with state machines. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Beek in view of MacGabann above, the to-be combined elements would have fit together like pieces of a puzzle 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 (see MPEP 2143 A).
Regarding Claim 23: Beek / MacGabann teaches all the limitations of claim 22 above.
Although Beek teaches actions such as sending messages, Beek does not specifically teach the creation of the messages based on rescue factors.
However, MacGabann in analogous art of rescue operation systems with state machines teaches or suggests:
wherein the performing the one or more actions includes creating a message by the action component to be sent based on the one or more rescue factors (MacGabann end-¶ [0197]: These codes may be organized as a hierarchy by the disclosed emergency response system 100, such that codes relating to specific injuries and emergency scenarios would be organized under a more general code for a type of emergency. Emergency type (6) may provide a rapid way for a user to request rescue without having to provide further information, and selection of this option may trigger transmission of the request).
MacGabann and Beek are found as analogous art of rescue operation systems with state machines. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Beek’s automotive scenario state machine system and method to have included MacGabann’s teachings around the creation of messages based on rescue factors. The benefit of these additional features would have improved automated triaging and dispatch for rescue operations (MacGabann ¶ [0029]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Beek in view of MacGabann (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of rescue operation systems with state machines. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Beek in view of MacGabann above, the to-be combined elements would have fit together like pieces of a puzzle 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 (see MPEP 2143 A).
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 1-8, 10-14, 16-18, 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over:
Maurice H. ter Beek et al: "Formal verification of an automotive scenario in service-oriented computing", 30th International Conference on Software Engineering: ICSE 2008; May 10 - 18, 2008, Leipzig, Germany, Curran, Red Hook, NY, 10 May 2008 (2008-05-10), pages 613-622, XP058176262, DOI: 10.1145/1368088.1368173, hereinafter Beek, in view of
MacGabann US 20190313230 A1, hereinafter MacGabann. and in further view of
Manfredi et al. US 20070003347 A1, hereinafter Manfredi. As per,
Regarding Claim 1: Beek teaches:
A system for vehicle rescue, comprising:
an interface of a state engine configured to receive an input indicating a transition to a target state of the state engine, the target state being a state associated with a vehicle rescue operation (Beek Chapter 4.1: [..] Since our goal was to use UMC to verify properties expressed in UCTL, we formally defined the scenario as a set of communicating UML state machines [..]. Figure 2 depicts the UML structure diagram of the set of UML state machines and the subcomponents Bank Communication and Orchestrator are depicted in Figures 3 and 4, resp. Beek Chapter 3.2: In [22], the automotive architecture as defined within Sensoria is described and the requirements model of the on road assistance scenario [EN: vehicle rescue operation] is specified in UML 2.0 using a UML Profile [23]. This scenario consists of the components [..] Orchestrator: composes services to achieve goal [EN: target state] [..]. Since the workflow describing the service orchestration is one of the most interesting aspects of a service-oriented system, we depict it in Figure 1 as a UML 2.0 activity diagram. The orchestrator is triggered [EN: receives input] by an engine failure (in our case due to a low oil level) and consequently contacts the other components to compose the various services to reach its goal (in our case sending the driver a rental car and a tow truck to tow the stranded vehicle to a garage) [..]. The actions match operations of required and provided interfaces of the services, defined as ports of UML 2.0 components. [EN: Also see Figs. 1, 3, 4 and related text]);
a verification component coupled to the interface, the verification component configured to identify whether the transition to the target state is valid based on one or more constraints associated with the state engine (Beek mid-Chapter 2.3: The basic idea underlying UMC is that, given a state of an L2TS, the validity of a UCTL formula on that state can be evaluated by analyzing the transitions allowed in that state [EN: constraints] and the of a certain subformula in only some of the next reachable states, all this in a recursive way. [Also see verification component implied by subcomponents in Figs. 3, 4 and related text]);
a transition component coupled to the verification component, the transition component configured to perform the transition to the target state based on the identification of whether the transition to the target state is valid (Beek Chapter 2.3: [..] the states of this L2TS are labelled with the observed structural properties of the system configurations (like the active substates of objects, the values of object attributes, etc.), while its transitions are labelled with the observed properties of the system evolutions (like which is the evolving object, which are the executed acions, etc. [Also see transition component implied by subcomponents in Figs. 3, 4 and related text]);
[..]
an action identification component configured to identify one or more actions associated
with the target state based on the one or more rescue factors (Beek mid-Chapter 3.1: When the driver makes an appointment with the garage, the results of the in-vehicle diagnosis are automatically sent along [EN: action], allowing the garage to identify the spare parts needed to repair the car [EN: identified actions]. Similarly, when the driver orders a tow truck [EN: rescue factor, see ¶ 0034] of Applicant specification] and a rental car, the vehicle's GPS coordinates are sent along [EN: action]),
[..].
Although Beek teaches vehicle rescue operations using a state machine, Beek does not specifically teach injecting rescue factors, spawning actions, or inheriting locks.
However, MacGabann in analogous art of rescue operation systems with state machines teaches or suggests:
wherein the state engine is configured to inject one or more rescue factors (MacGabann end-¶ [0098]: In some embodiments, such a decision is based on many factors including battery life of the device, responder arrival time [EN: rescue factor, see ¶ [0034] of Applicant specification], the direction and velocity of a victim's travel, and the severity of a victim's emergency during the emergency response request. ¶ [0106]: tr is the responder arrival time, which may comprise an amount of time before the responder arrives at a location of the victim. In some embodiments, the responder arrival time is pinged from the server 120 and/or predicted client-side, depending on battery life, determination of the best network, and so forth. Mid-¶ [0124]: The responder application 135 can receive perpetual (e.g., real-time) location updates and/or status updates relating to the victim, and can also provide perpetual location and/or status updates relating to the emergency responder at block 317. ¶ [0225]: The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software that runs on computer hardware, or combinations of both. A processor device can be a microprocessor, but in the alternative, the processor device can be a controller, microcontroller, or state machine, combinations of the same, or the like); and
wherein the one or more actions include spawning actions [..] (MacGabann end-¶ [0098]: Emergency type (6) may provide a rapid way for a user to request rescue without having to provide further information, and selection of this option may trigger [EN: spawn] transmission of the request [EN: which is “locked” if the user does not select this option]).
MacGabann and Beek are found as analogous art of rescue operation systems with state machines. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Beek’s automotive scenario state machine system and method to have included MacGabann’s teachings around rescue factors and spawning actions. The benefit of these additional features would have improved automated triaging and dispatch for rescue operations (MacGabann ¶ [0029]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Beek in view of MacGabann (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of rescue operation systems with state machines. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Beek in view of MacGabann above, the to-be combined elements would have fit together like pieces of a puzzle 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 (see MPEP 2143 A).
Furthermore, Manfredi in analogous art of state machines teaches or suggests:
wherein the one or more actions [..] inherit a held lock (Manfredi ¶ [0034]: Generally, to avoid such consistency problems, critical sections can be defined. When the code is in a critical section, it holds a lock and other threads cannot acquire it until that lock is released. In effect, this guarantees that only one thread will be running the code in the critical section at one point in time. ¶ [0048]: FIG. 4(b) illustrates a process that is carried out each time an event being processed by the state machine controller accesses a state context object. A lock is set in step 450, then a check is made in step 460 whether the event is the latest event received by the state machine controller. If so, then the lock is released and the state context object may be accessed normally. [Also see Fig. 4(a) where lock is started, event is assessed, states in list are detached (performed action) and state is restored (transition performed)])
Manfredi is found as analogous art to the instant application of state machines, and MacGabann and Beek are found as analogous art to the instant application of rescue operation systems with state machines. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Beek / MacGabann’s automotive scenario state machine system and method to have included Manfredi’s teachings around inheriting locks. The benefit of these additional features would have provided additional efficiency and adaptability to the flow of states in the system and avoid concurrency problems (Manfredi [0006]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Beek in view of Manfredi and MacGabann (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of state machines. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Beek in view of Manfredi and MacGabann above, the to- be combined elements would have fit together like pieces of a puzzle 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 (see MPEP 2143 A).
Regarding Claim 14: Beek teaches:
A system for vehicle rescue, comprising:
an interface of a state engine configured to receive an input indicating an occurrence of an event associated with a vehicle rescue operation, [..] (Beek Chapter 4.1: [..] Since our goal was to use UMC to verify properties expressed in UCTL, we formally defined the scenario as a set of communicating UML state machines [..]. Figure 2 depicts the UML structure diagram of the set of UML state machines and the subcomponents Bank Communication and Orchestrator are depicted in Figures 3 and 4, resp. Beek Chapter 3.2: In [22], the automotive architecture as defined within Sensoria is described and the requirements model of the on road assistance scenario [EN: vehicle rescue operation] is specified in UML 2.0 using a UML Profile [23]. This scenario consists of the components [..] Orchestrator: composes services to achieve goal [EN: target state] [..]. Since the workflow describing the service orchestration is one of the most interesting aspects of a service-oriented system, we depict it in Figure 1 as a UML 2.0 activity diagram. The orchestrator is triggered [EN: receives input] by an engine failure [EN: event] (in our case due to a low oil level) and consequently contacts the other components to compose the various services to reach its goal (in our case sending the driver a rental car and a tow truck to tow the stranded vehicle to a garage) [..]. The actions match operations of required and provided interfaces of the services, defined as ports of UML 2.0 components. [EN: Also see Figs. 1, 3, 4 and related text]) ;
a verification component coupled to the interface, the verification component configured to identify whether the event is allowed based on one or more constraints associated with the state engine (Beek mid-Chapter 2.3: The basic idea underlying UMC is that, given a state of an L2TS, the validity of a UCTL formula on that state can be evaluated by analyzing the transitions allowed in that state [EN: constraints] and the of a certain subformula in only some of the next reachable states, all this in a recursive way. [Also see verification component implied by subcomponents in Figs. 3, 4 and related text]);
an action identification component configured to identify one or more actions associated
with the target state based on the one or more rescue factors (Beek mid-Chapter 3.1: When the driver makes an appointment with the garage, the results of the in-vehicle diagnosis are automatically sent along [EN: action], allowing the garage to identify the spare parts needed to repair the car [EN: identified actions]. Similarly, when the driver orders a tow truck [EN: rescue factor, see ¶ 0034] of Applicant specification] and a rental car, the vehicle's GPS coordinates are sent along [EN: action]),
[..]
an action component coupled to the verification component, the action component configured to perform one or more actions associated with the event based on the identification of whether the event is allowed (Beek Chapter 2.3: [..] the states of this L2TS are labelled with the observed structural properties of the system configurations (like the active substates of objects, the values of object attributes, etc.), while its transitions are labelled with the observed properties of the system evolutions (like which is the evolving object, which are the executed acions, etc. [Also see action component implied by subcomponents in Figs. 3, 4 and related text]).
Although Beek teaches vehicle rescue operations using a state machine, Beek does not specifically teach injecting rescue factors, spawning actions, or inheriting locks.
However, MacGabann in analogous art of rescue operation systems with state machines teaches or suggests:
the state engine further configured to introduce one or more rescue factors (MacGabann end-¶ [0098]: In some embodiments, such a decision is based on many factors including battery life of the device, responder arrival time [EN: rescue factor, see ¶ [0034] of Applicant specification], the direction and velocity of a victim's travel, and the severity of a victim's emergency during the emergency response request. ¶ [0106]: tr is the responder arrival time, which may comprise an amount of time before the responder arrives at a location of the victim. In some embodiments, the responder arrival time is pinged from the server 120 and/or predicted client-side, depending on battery life, determination of the best network, and so forth. Mid-¶ [0124]: The responder application 135 can receive perpetual (e.g., real-time) location updates and/or status updates relating to the victim, and can also provide perpetual location and/or status updates relating to the emergency responder at block 317. ¶ [0225]: The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software that runs on computer hardware, or combinations of both. A processor device can be a microprocessor, but in the alternative, the processor device can be a controller, microcontroller, or state machine, combinations of the same, or the like); and
wherein the one or more actions include spawning actions [..] (MacGabann end-¶ [0098]: Emergency type (6) may provide a rapid way for a user to request rescue without having to provide further information, and selection of this option may trigger [EN: spawn] transmission of the request [EN: which is “locked” if the user does not select this option]).
Rationales to have modified / combined Beek / MacGabann are above in claim 1 and reincorporated.
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of rescue operation systems with state machines. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Beek in view of MacGabann above, the to-be combined elements would have fit together like pieces of a puzzle 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 (see MPEP 2143 A).
Furthermore, Manfredi in analogous art of state machines teaches or suggests:
wherein the one or more actions [..] inherit a held lock (Manfredi ¶ [0034]: Generally, to avoid such consistency problems, critical sections can be defined. When the code is in a critical section, it holds a lock and other threads cannot acquire it until that lock is released. In effect, this guarantees that only one thread will be running the code in the critical section at one point in time. ¶ [0048]: FIG. 4(b) illustrates a process that is carried out each time an event being processed by the state machine controller accesses a state context object. A lock is set in step 450, then a check is made in step 460 whether the event is the latest event received by the state machine controller. If so, then the lock is released and the state context object may be accessed normally. [Also see Fig. 4(a) where lock is started, event is assessed, states in list are detached (performed action) and state is restored (transition performed)]).
Rationales to have modified / combined Beek / MacGabann / Manfredi are above in claim 1 and reincorporated.
Regarding Claim 20: Beek teaches:
One or more non-transitory computer-readable media having instructions stored thereon, which when executed by one or more processors, cause the one or more processors to:
receive, via an interface of a state engine, an input indicating a transition to a target state of the state engine, the target state being a state associated with a vehicle rescue operation, [..] (Beek Chapter 4.1: [..] Since our goal was to use UMC to verify properties expressed in UCTL, we formally defined the scenario as a set of communicating UML state machines [..]. Figure 2 depicts the UML structure diagram of the set of UML state machines and the subcomponents Bank Communication and Orchestrator are depicted in Figures 3 and 4, resp. Beek Chapter 3.2: In [22], the automotive architecture as defined within Sensoria is described and the requirements model of the on road assistance scenario [EN: vehicle rescue operation] is specified in UML 2.0 using a UML Profile [23]. This scenario consists of the components [..] Orchestrator: composes services to achieve goal [EN: target state] [..]. Since the workflow describing the service orchestration is one of the most interesting aspects of a service-oriented system, we depict it in Figure 1 as a UML 2.0 activity diagram. The orchestrator is triggered [EN: receives input] by an engine failure (in our case due to a low oil level) and consequently contacts the other components to compose the various services to reach its goal (in our case sending the driver a rental car and a tow truck to tow the stranded vehicle to a garage) [..]. The actions match operations of required and provided interfaces of the services, defined as ports of UML 2.0 components. [EN: Also see Figs. 1, 3, 4 and related text]);
identify, via a verification component coupled to the interface, whether the transition to the target state is valid based on one or more constraints associated with the state engine (Beek mid-Chapter 2.3: The basic idea underlying UMC is that, given a state of an L2TS, the validity of a UCTL formula on that state can be evaluated by analyzing the transitions allowed in that state [EN: constraints] and the of a certain subformula in only some of the next reachable states, all this in a recursive way. [Also see verification component implied by subcomponents in Figs. 3, 4 and related text]); and
perform, via a transition component coupled to the verification component, the transition to the target state based on the identification of whether the transition to the target state is valid (Beek Chapter 2.3: [..] the states of this L2TS are labelled with the observed structural properties of the system configurations (like the active substates of objects, the values of object attributes, etc.), while its transitions are labelled with the observed properties of the system evolutions (like which is the evolving object, which are the executed acions, etc. [Also see transition component implied by subcomponents in Figs. 3, 4 and related text]); and
identify, via an action identification component one or more actions associated with the target state based on the one or more rescue factors (Beek mid-Chapter 3.1: When the driver makes an appointment with the garage, the results of the in-vehicle diagnosis are automatically sent along [EN: action], allowing the garage to identify the spare parts needed to repair the car [EN: identified actions]. Similarly, when the driver orders a tow truck [EN: rescue factor, see ¶ 0034] of Applicant specification] and a rental car, the vehicle's GPS coordinates are sent along [EN: action]),
[..].
Although Beek teaches vehicle rescue operations using a state machine, Beek does not specifically teach injecting rescue factors, spawning actions, or inheriting locks.
However, MacGabann in analogous art of rescue operation systems with state machines teaches or suggests:
wherein the state engine is configured to inject one or more rescue factors (MacGabann end-¶ [0098]: In some embodiments, such a decision is based on many factors including battery life of the device, responder arrival time [EN: rescue factor, see ¶ [0034] of Applicant specification], the direction and velocity of a victim's travel, and the severity of a victim's emergency during the emergency response request. ¶ [0106]: tr is the responder arrival time, which may comprise an amount of time before the responder arrives at a location of the victim. In some embodiments, the responder arrival time is pinged from the server 120 and/or predicted client-side, depending on battery life, determination of the best network, and so forth. Mid-¶ [0124]: The responder application 135 can receive perpetual (e.g., real-time) location updates and/or status updates relating to the victim, and can also provide perpetual location and/or status updates relating to the emergency responder at block 317. ¶ [0225]: The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software that runs on computer hardware, or combinations of both. A processor device can be a microprocessor, but in the alternative, the processor device can be a controller, microcontroller, or state machine, combinations of the same, or the like); and
wherein the one or more actions include spawning actions [..] (MacGabann end-¶ [0098]: Emergency type (6) may provide a rapid way for a user to request rescue without having to provide further information, and selection of this option may trigger [EN: spawn] transmission of the request [EN: which is “locked” if the user does not select this option]).
Rationales to have modified / combined Beek / MacGabann are above in claim 1 and reincorporated.
Furthermore, Manfredi in analogous art of state machines teaches or suggests:
wherein the one or more actions [..] inherit a held lock (Manfredi ¶ [0034]: Generally, to avoid such consistency problems, critical sections can be defined. When the code is in a critical section, it holds a lock and other threads cannot acquire it until that lock is released. In effect, this guarantees that only one thread will be running the code in the critical section at one point in time. ¶ [0048]: FIG. 4(b) illustrates a process that is carried out each time an event being processed by the state machine controller accesses a state context object. A lock is set in step 450, then a check is made in step 460 whether the event is the latest event received by the state machine controller. If so, then the lock is released and the state context object may be accessed normally. [Also see Fig. 4(a) where lock is started, event is assessed, states in list are detached (performed action) and state is restored (transition performed)]).
Rationales to have modified / combined Beek / MacGabann / Manfredi are above in claim 1 and reincorporated.
Regarding Claims 2, 17: Beek / MacGabann / Manfredi teaches all the limitations of claims 1, 14 above.
Beek further teaches:
wherein to identify whether the transition is valid, the verification component is configured to:
determine whether the state engine is associated with a current state (Beek Chapter 3.2: In [22], the automotive architecture as defined within Sensoria is described and the requirements model of the on road assistance scenario is specified in UML 2.0 using a UML Profile [23]. This scenario consists of the components: Engine: causes low oil level alert [..]); and
determine whether the current state allows the transition to the target state based on the one or more constraints (Beek mid-Chapter 2.3: The basic idea underlying UMC is that, given a state of an L2TS, the validity of a UCTL formula on that state can be evaluated by analyzing the transitions allowed in that state [EN: constraints] and the of a certain subformula in only some of the next reachable states, all this in a recursive way).
Regarding Claims 3, 18: Beek / MacGabann / Manfredi teaches all the limitations of claims 1, 14 above.
Although Beek teaches validity of transitions between states in a state machine, Beek does not specifically teach resetting states.
However, Manfredi in analogous art of state machines teaches or suggests:
wherein to identify whether the transition is valid, the verification component is configured to:
determine whether the state engine is associated with a current state (Manfredi mid-¶ [0043]: The current state is stored step 300. It is then determined in step 310 whether the current state lies in the path of the target state in step 310, if not then the leave method is carried out on the current state in step 320 and the state is added to a visited state list—step 330. [Also see Fig. 3 and related text]); and
determine whether the target state is an initial state of the state engine (Manfredi ¶ [0046]: The original [EN: initial] state the state machine was in during the reception of the previous event (denoted state x in FIG. 4) is restored in step 430. [Also see Fig. 4(a) and related text]),
wherein the transition is invalid if the state engine is not associated with the current state and the target state is not the initial state (Manfredi end-¶ [0043]: This process is repeated until a state is reached that does lie in the path of the target state. The enter methods of states in the
target path are then repeatedly called until the target state y is reached and each state visited is added to the visited state list. The target state state y is then set as the current state. [Also see Fig. 3 and related text]).
Manfredi is found as analogous art to the instant application of state machines, and MacGabann and Beek are found as analogous art to the instant application of rescue operation systems with state machines. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Beek / MacGabann’s automotive scenario state machine system and method to have included Manfredi’s teachings around resetting states. The benefit of these additional features would have provided additional efficiency and adaptability to the flow of states in the system and avoid concurrency problems (Manfredi [0006]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Beek in view of Manfredi and MacGabann (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of state machines. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Beek in view of Manfredi and MacGabann above, the to- be combined elements would have fit together like pieces of a puzzle 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 (see MPEP 2143 A).
Regarding Claim 4: Beek / MacGabann / Manfredi teaches all the limitations of claim 1 above.
Beek further teaches:
wherein the verification component is further configured to determine whether a current state of the state engine is allowed based on a prior state of the state engine, the transition component being configured to perform the transition based on the determination by the verification component (Beek Chapter 4.2 Service Coordination: A service is coordinated if its confirmation is always preceded by a request (for this service). An example of service coordination is expressed by the UCTL formula [..] which states that it may never happen that action charge-ResponseOK takes place if action requestCardCharge has not taken place before. More intuitively: The Car cannot receive a notification of the fact that the credit card has been charged, if it did not previously request the Bank to do so).
Regarding Claim 5: Beek / MacGabann / Manfredi teaches all the limitations of claim 1 above.
Although Beek teaches validity of transitions between states in a state machine, Beek does not specifically teach locking and unlocking states.
However, Manfredi in analogous art of state machines teaches or suggests:
further comprising a lock acquirer component configured to lock a state of the state engine until the transition and one or more actions triggered by the transition are performed (Manfredi ¶ [0034]: Generally, to avoid such consistency problems, critical sections can be defined. When the code is in a critical section, it holds a lock and other threads cannot acquire it until that lock is released. In effect, this guarantees that only one thread will be running the code in the critical section at one point in time. ¶ [0048]: FIG. 4(b) illustrates a process that is carried out each time an event being processed by the state machine controller accesses a state context object. A lock is set in step 450, then a check is made in step 460 whether the event is the latest event received by the state machine controller. If so, then the lock is released and the state context object may be accessed normally. [Also see Fig. 4(a) where lock is started, event is assessed, states in list are detached (performed action) and state is restored (transition performed)]); and
a lock releaser component configured to release the lock after the one or more actions are
performed, wherein actions spawned during transition processing inherit the held lock (Manfredi ¶ [0048]: FIG. 4(b) illustrates a process that is carried out each time an event being processed [EN: performed] by the state machine controller accesses a state context object. A lock is set [EN: held] in step 450, then a check is made in step 460 whether the event is the latest event received by the state machine controller. If so, then the lock is released and the state context object may be accessed normally. [Also see Fig. 4(a) where lock is started, event is assessed, states in list are detached and state is restored]).
Manfredi is found as analogous art to the instant application of state machines, and MacGabann and Beek are found as analogous art to the instant application of rescue operation systems with state machines. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Beek / MacGabann’s automotive scenario state machine system and method to have included Manfredi’s teachings around locking and unlocking states. The benefit of these additional features would have provided additional efficiency and adaptability to the flow of states in the system and avoid concurrency problems (Manfredi [0006]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Beek in view of Manfredi and MacGabann (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of state machines. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Beek in view of Manfredi and MacGabann above, the to- be combined elements would have fit together like pieces of a puzzle 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 (see MPEP 2143 A).
Regarding Claim 6: Beek / MacGabann / Manfredi teaches all the limitations of claim 1 above.
Beek further teaches:
wherein the input indicating the transition comprises an input indicating an occurrence of an event that triggers the transition (Beek Chapter 3.1: While a driver is on the road with her/his car, the vehicle's diagnostic system reports a low oil level [EN: event occurrence]. This triggers the in-vehicle diagnostic system to report a problem [EN: input] with the pressure of the cylinder heads, which results in the car being no longer drivable, and to send this diagnostic data as well as the vehicle's GPS coordinates to the repair server).
Regarding Claim 7: Beek / MacGabann / Manfredi teaches all the limitations of claim 1 above.
Beek further teaches:
the state engine is configured to identify one or more rescue factors associated with the state engine (Beek mid-Chapter 3.1: Based on the driver's preferences, the service discovery system identifies and selects an appropriate [EN: based on rescue factors] set of services (garage, tow truck and rental car) in the area); and
the system further comprises:
an action component configured to perform the one or more actions (Beek mid-Chapter 3.2: The orchestrator is triggered by an engine failure (in our case due to a low oil level) and consequently contacts [EN: action] the other components to compose the various services to reach its goal (in our case sending the driver a rental car and a tow truck to tow the stranded vehicle to a garage)).
Regarding Claim 8: Beek / MacGabann / Manfredi teaches all the limitations of claim 1 above.
Beek further teaches:
further comprising a communication interface coupled to the action component, wherein the action component is configured to perform the one or more actions by sending, via the communication interface, a message providing an update regarding the rescue operation to a device (Beek Chapter 4.2 Service Responsiveness: A service is responsive if it guarantees a response to each received request. An example of service responsiveness is expressed by the UCTL formula [..] which states that each time action requestCardCharge takes place, always at a certain moment action chargeResponseOK or chargeResponseFail takes place. More intuitively: If the Car requests the Bank to charge a credit card, then the Bank will surely reply with a notification [EN: update message] of either a successful or a failed attempt to charge the credit card).
Regarding Claim 9: cancelled.
Regarding Claim 10: Beek / MacGabann / Manfredi teaches all the limitations of claim 1 above.
Beek further teaches:
wherein the action component is configured to perform the one or more actions by creating a message to be sent for the rescue operation based on the one or more rescue factors (Beek end-Chapter 2.1: Scopes include stereotyped actions like send, receive, send and receive, compensate and compensate all. The stereotype <<send>> is used to model the sending of messages; <<received>> models the reception of a message blocking until the message is received; <<send and receive>> is a shorthand for a sequential order of a send action and a receive action. Container for data to be send or received are modelled by <<send pin>>s and <<receive pin>>s).
Regarding Claim 11: Beek / MacGabann / Manfredi teaches all the limitations of claim 1 above.
Beek further teaches:
a communication interface configured to receive an indication of an occurrence of an event, wherein the verification component is configured to determine whether a current state of the state engine allows for the event to occur; and
an action component configured to perform one or more actions associated with the event in response to the determination (Beek Chapter 3.1: While a driver is on the road with her/his car, the vehicle's diagnostic system reports a low oil level [EN: event occurrence]. This triggers the in-vehicle diagnostic system to report a problem with the pressure of the cylinder heads, which results in the car being no longer drivable [EN: allowed state engine failure], and to send [EN: perform action] this diagnostic data as well as the vehicle's GPS coordinates to the repair server).
Regarding Claim 12: Beek / MacGabann / Manfredi teaches all the limitations of claim 1 above.
Beek further teaches:
the state engine is configured to determine a rescue identifier indicating a type of the rescue operations (See Beek Figure 4 where the state ServiceSelection transitions to the state OrderServices and the type of rescue operation is identified – garage, tow, and car rental);
the state engine is configured to identify one or more rescue factors (See Beek Figure 4 at EnablingPhase where engine failure and location factors are identified); and
the system further comprises:
an action identification component configured to identify one or more actions to be performed for the rescue operations based on the rescue identifier and the one or more rescue factors; and an action component configured to perform the one or more actions (See Beek Figure 4 identified actions at OrderServices [EN: action component] including self.ordergarage, self.rentC, and self.orderTowTruc [Also see Figure 4 and related text]).
Regarding Claim 13: Beek / MacGabann / Manfredi teaches all the limitations of claim 1 above.
Although Beek teaches validity of transitions between states in a state machine, Beek does not specifically teach locking states.
However, Manfredi in analogous art of state machines teaches or suggests:
a lock acquirer component configured to lock a state of the state engine (Manfredi ¶ [0034]: Generally, to avoid such consistency problems, critical sections can be defined. When the code is in a critical section, it holds a lock and other threads cannot acquire it until that lock is released. In effect, this guarantees that only one thread will be running the code in the critical section at one point in time);
an action component configured to perform one or more actions associated with the rescue operations (Manfredi ¶ [0020]: State machine definition 130 defines the flow and logic of the web application. States represent views and transitions between states represent actions); and
a lock releaser component configured to unlock the state of the state engine after the one or more actions are performed (Manfredi ¶ [0048]: FIG. 4(b) illustrates a process that is carried out each time an event being processed [EN: performed] by the state machine controller accesses a state context object. A lock is set in step 450, then a check is made in step 460 whether the event is the latest event received by the state machine controller. If so, then the lock is released and the state context object may be accessed normally. [Also see Fig. 4(a) where lock is started, event is assessed, states in list are detached and state is restored]).
Rationales to have modified / combined Beek / MacGabann / Manfredi are above in claim 5 and reincorporated.
Regarding Claim 15: cancelled.
Regarding Claim 16: Beek / MacGabann / Manfredi teaches all the limitations of claim 14 above.
Beek further teaches:
the occurrence of the event triggers a transition to a target state of the state engine (Beek Chapter 3.1: While a driver is on the road with her/his car, the vehicle's diagnostic system reports a low oil level [EN: event occurrence]. This triggers the in-vehicle diagnostic system to report a problem with the pressure of the cylinder heads, which results in the car being no longer drivable [EN: target state], and to send this diagnostic data as well as the vehicle's GPS coordinates to the repair server);
the verification component is configured to identify whether the transition to the target state is valid based on the one or more constraints associated with the state engine (Beek mid-Chapter 2.3: The basic idea underlying UMC is that, given a state of an L2TS, the validity of a UCTL formula on that state can be evaluated by analyzing the transitions allowed in that state [EN: constraints] and the of a certain subformula in only some of the next reachable states, all this in a recursive way); and
the system further comprises a transition component coupled to the verification component, the transition component being configured to perform the transition to the target state based on the identification of whether the transition to the target state is valid (Beek Chapter 2.3: [..] the states of this L2TS are labelled with the observed structural properties of the system configurations (like the active substates of objects, the values of object attributes, etc.), while its transitions are labelled with the observed properties of the system evolutions (like which is the evolving object, which are the executed acions, etc. [Also see transition component implied by subcomponents in Figs. 3, 4 and related text]).
Regarding Claim 19: cancelled.
Regarding Claim 21: Beek / MacGabann / Manfredi teaches all the limitations of claim 1 above.
Beek further teaches:
wherein the state engine is configured to determine whether an action associated with an event that has occurred spawns other actions; and further configured to initiate the spawned actions (Beek Chapter 3.1 While a driver is on the road with her/his car, the vehicle's diagnostic system reports a low oil level [EN: event]. This triggers [EN: spawns] the in vehicle diagnostic system to report a problem with the pressure of the cylinder heads, which results in the car being no longer drivable, and to send [EN: action] this diagnostic data as well as the vehicle's GPS coordinates to the repair server. Based on the driver's preferences, the service discovery system identifies [EN: action] and selects [EN: action] an appropriate set of services (garage, tow truck and rental car) in the area).
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Conclusion
The following art is made of record and considered pertinent to Applicant’s disclosure:
Sutherland;
Andrew et al. US 20210406137 A1, Systems and methods for checking safety properties.
Thomason, Graham G. US 20040098240 A1, State machine modelling.
TAGUCHI; Shinya et al. US 20210286630 A1, State chart execution device.
Kraft, Frank Michael US 20050027739 A1, Computer-implemented method and system to support in developing a process specification for a collaborative process.
Burmester; Sven et al. US 20080109475 A1, Method of creating a requirement description for an embedded system.
Phillips; James C. US 7334015 B1, Integration of legacy mainframe systems through data stream objectification into finite state machines.
Alexeev; Sergey et al. US 8707252 B1, Techniques for automatic generation of parsing code.
Beers; Robert et al. US 10120774 B2, Coherence protocol tables.
Schulz; Karsten US 7350188 B2, Aggregation of private and shared workflows.
Liu et al. WO 2022262679 A1, Vehicle control method and related device.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 REED M. BOND whose telephone number is (571) 270-0585. The examiner can normally be reached Monday - Friday 8:00 am - 5: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, Patricia Munson can be reached at (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 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.
/REED M. BOND/Examiner, Art Unit 3624 December 12, 2025
/HAMZEH OBAID/Primary Examiner, Art Unit 3624 December 13, 2025
Prosecution Insights