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