DETAILED ACTION
Status of the Claims
The following is a Final Office Action in response to amendments and remarks filed 17 March 2026.
Claims 1, 13, and 25 have been amended.
Claims 1-7, 9-19, and 21-27 are pending and have been examined.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicants’ arguments have been fully considered but are not persuasive for a plurality of reasons. Firstly, Applicant’s arguments with respect to the interpretations of Shivananda use hindsight reasoning to hypothetically create scenarios within the interpretations that would undermine the reference from reading upon the claims. Secondly, Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. Thirdly, Applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not show how the amendments avoid such references or objections. Applicant’s arguments, again, are only addressing hypothetical scenarios from hindsight interpretations, not the actual claim language. Fourthly, the claims, as amended, require a first and second sub-statecharts be generated, which when broadly interpreted, is accounted for by Shivananda as each FORK node would have at least two (2) branches beyond (otherwise there would not be a fork at all). So even assuming arguendo, Shivananda does in fact read upon the ability to generate however number of sub-statecharts that coincide with how many fork options or branches are leaving the FORK node. And lastly, the Examiner notes that duplication of parts or steps is obvious, (MPEP 2144.04.VI.B). The duplication of parts (or steps) has no patentable significance unless a new and unexpected result is produced. Examiner finds no evidence that performing the processes in claims 1, 13, and 25 for second or additional edge sub-statecharts would produce new and unexpected results as compared to performing the processes in claims 1, 13, and 15 for only a first edge sub-statechart. As such the arguments are not persuasive, and the rejection not overcome.
In response to arguments in reference to any depending claims that have not been individually addressed, all rejections made towards these dependent claims are maintained due to a lack of reply by the Applicants in regards to distinctly and specifically pointing out the supposed errors in the Examiner's prior office action (37 CFR 1.111). The Examiner asserts that the Applicants only argue that the dependent claims should be allowable because the independent claims are unobvious and patentable over the prior art.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis 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.
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 following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 1-3, 6-7, 9-15, 18-19, and 21-27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shivananda et al. (US PG Pub. 2010/0293480) further in view of El-Nakhily et al. (US PG Pub. 2010/0281241).
As per claims 1, 13, and 25, Shivananda discloses a computer-implemented method, computer program product the computer program product comprising a non-transitory computer readable storage medium having program instructions embodied therewith, the program instructions executable by a computer to cause the computer to perform a method comprising:, and computer processing system the system comprising: a memory device including program code stored thereon; a hardware processor, operatively coupled to the memory device, and configured to run the program code stored on the memory device to; for automatically transforming a Business Process Model (BPM) into a hierarchical statechart, the BPM having parallel paths with at least one FORK node and at least one JOIN node, the method comprising (memory, computer system, GUI, Shivananda ¶38-¶41; processor, ¶62; automatically, ¶66);
responsive to identifying each of the at least one FORK node in the BPM in a node analysis (generating the documentation may include analyzing information corresponding to each state of the first diagram and generating user documentation for each state based on the analysis. Similarly, the generation may include analyzing information corresponding to each transition and generating user documentation for each transition based on the analysis. Similar methods may apply to each element of the first diagram, Shivananda ¶6-¶7 and ¶93; graphical program including nodes, ¶42-¶43):
generating a first and second FORK edge sub-statechart having an initial state and a working state for each edge from the at least one FORK node, and visually attaching for user visualization the FORK edge sub-statechart to a hierarchical state for the at least one FORK node (One or more of the state icons may represent a hierarchical state, where a hierarchical state is a state that includes one or more sub-states. For example, a statechart may include a state (a superstate) which includes states (substates). The substates may be AND states (e.g., parallel or concurrently active states) or OR states (e.g., states which are not concurrently active). The statechart may also include pseudostates (e.g., forks, joins, and/or junctions), Shivananda ¶59-¶60; As shown in FIG. 1A, the computer system 82 may include a display device operable to display the statechart as the statechart is created and/or executed. The display device may also be operable to display a graphical user interface (e.g., a data viewer or debugging GUI) of the statechart during execution of the statechart. The graphical user interface may comprise any type of graphical user interface, e.g., depending on the computing platform, ¶67-¶68; In some embodiments, the statechart may include pseudostates (e.g., forks, joins, and/or junctions). In some embodiments, pseudostates (or certain types thereof) may provide conditional branching for transitions in the statechart. For example, a state icon may be wired to a pseudostate in the statechart and multiple other wires may connect the pseudostate to other state icons in the diagram. Each of these wires may represent transitions with associated triggers, guards, and/or actions (as described above). Thus, the pseudostate may allow for conditioned branching of transitions in the statechart. Note that in various embodiments, transitions between states (e.g., single states, superstates, substates, or concurrently active states) and/or pseudostate may be ordered according to configured priorities (e.g., as specified by the user). These priorities may be assigned using explicit specification (e.g., using labels) or implicit specification (e.g., using orientation or directionality of the wires in the statechart), ¶80; see also ¶44-¶45 wherein the wires indicate status and ¶94 discussing documentation and visually represented items); and
generating a synchronizer sub-statechart corresponding to each JOIN node going through the FORK node to receive a synchronization event from each FORK edge sub- statechart, and visually attaching for user visualization the synchronizer sub-statechart to the hierarchical state for the at least one FORK node to form an intermediate version of the hierarchical statechart (One or more of the state icons may represent a hierarchical state, where a hierarchical state is a state that includes one or more sub-states. For example, a statechart may include a state (a superstate) which includes states (substates). The substates may be AND states (e.g., parallel or concurrently active states) or OR states (e.g., states which are not concurrently active). The statechart may also include pseudostates (e.g., forks, joins, and/or junctions), Shivananda ¶59-¶60; As shown in FIG. 1A, the computer system 82 may include a display device operable to display the statechart as the statechart is created and/or executed. The display device may also be operable to display a graphical user interface (e.g., a data viewer or debugging GUI) of the statechart during execution of the statechart. The graphical user interface may comprise any type of graphical user interface, e.g., depending on the computing platform, ¶67-¶68; In some embodiments, the statechart may include pseudostates (e.g., forks, joins, and/or junctions). In some embodiments, pseudostates (or certain types thereof) may provide conditional branching for transitions in the statechart. For example, a state icon may be wired to a pseudostate in the statechart and multiple other wires may connect the pseudostate to other state icons in the diagram. Each of these wires may represent transitions with associated triggers, guards, and/or actions (as described above). Thus, the pseudostate may allow for conditioned branching of transitions in the statechart. Note that in various embodiments, transitions between states (e.g., single states, superstates, substates, or concurrently active states) and/or pseudostate may be ordered according to configured priorities (e.g., as specified by the user). These priorities may be assigned using explicit specification (e.g., using labels) or implicit specification (e.g., using orientation or directionality of the wires in the statechart), ¶80; see also ¶44-¶45 wherein the wires indicate status and ¶94 discussing documentation and visually represented items) and;
automatically generating, by a code generator, a computer program modeling the BPM using the final version of the hierarchical statechart derived from the intermediate version that includes elements representing all originals of the BPM, the computer program executing in parallel multiple sub-statecharts attached to a single state (create and execute statecharts, Shivananda ¶67-¶68; program development environment, ¶37; automatically creating, ¶89-¶91; from the first diagram, the documentation may also include one or more image files specifying the images described above. Additionally, the user documentation may include hyperlinks to relevant related portions of the diagram. For example, containing objects and contained objects may include hyperlinks to visit information regarding those containing or contained objects. Similarly, hyperlinks may be used to view information regarding a transition (e.g., originating and terminating states of the transition), ¶100).
Shivananda discloses as shown above but does not expressly disclose that the processes are a Business Process Model (BPM); being ready to receive events at a same time that corresponding edges from the at least one FORK node start so that communications are always synchronous.
However, El-Nakhily teaches that the analysis and modeling is performed on a Business Process Model (BPM) (business process model or the input process, Requirements of the input in step 102 include: (1) each output branch produces an arbitrary number of data outputs, where the number of data outputs is not necessarily the same in each output branch; (2) each output branch produces output of an arbitrary data type, where the data type is not necessarily the same in each output branch; (3) each output branch has any number of connected nodes which are not necessarily tasks (i.e., each node in an output branch may be any decision, any event such as a stop node, or any transaction or activity such as a process, sub-process, or task), where the number of connected nodes is not necessarily the same in each output branch; and (4) before reaching a next modeling element X, the business process must wait for a completion of all activated paths (i.e., activated output branches) or a determination that there are zero activated paths. The number of activated paths from the inclusive decision is greater than or equal to zero and less than or equal to m., El-Nakhily ¶42-¶43).
Both the Shivananda and El-Nakhily references are analogous in that both are directed towards/concerned with process modeling. At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to use El-Nakhily’s method of business process model analysis in Shivananda’s system to improve the system and method with reasonable expectation that this would result in a business process management system that is able to reduce or minimize issues with errors or exceptions.
The motivation being that there is a need for analyzing and reconstructing a business process model having an inclusive decision, and more particularly to a technique for synchronizing branches of an inclusive decision in a business process model (El-Nakhily ¶1).
In addition, the Examiner asserts that claim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed, or by claim language that does not limit a claim to a particular structure. However, examples of claim language, although not exhaustive, that may raise a question as to the limiting effect of the language in a claim are: (A) "adapted to" or "adapted for" clauses; (B) "wherein" clauses; and (C) "whereby" clauses (See MPEP 2111.04). In the instant case, the recited "... being ready to receive events at a same time that corresponding edges from the at least one FORK node start so that communications are always synchronous ..." is not a positive method step as it do not require any actual positive recited claim steps to be performed; nor does it modify any of the positively claimed method steps. Similarly, the recited wherein clause is not a positive system or product element since it doesn’t structurally limit the system and merely describes the intended use of the system and/or the intended result of the use of the system or product.
Furthermore, one of ordinary skill, before the effective filing date of the claimed invention, would have found it obvious to repeat the processes in claims 1, 13, and 25 for second or additional edge sub-statecharts because duplication is obvious, MPEP 2144.04.VI.B. The duplication of parts (or steps) has no patentable significance unless a new and unexpected result is produced. Examiner finds no evidence that performing the processes in claims 1, 13, and 25 for second or additional edge sub-statecharts would produce new and unexpected results as compared to performing the processes in claims 1, 13, and 15 for only a first edge sub-statechart.
As per claims 2 and 14, Shivananda and El-Nakhily disclose as shown above with respect to claims 1 and 13. El-Nakhily further teaches responsive to identifying each of the at least one JOIN node in the BPM in the node analysis: generating a transition from the working state of the FORK edge sub-statechart to send the synchronization event to the synchronizer sub-statechart; generating a second working state; determining that a number of transitions to send synchronization events and a number of transitions to receive the synchronizations are equal; generating a transition from the hierarchical state for the at least one FORK node to the second working state to form the final version of the hierarchical statechart, responsive to a number of transitions to send synchronization events and a number of transitions to receive the synchronization events being equal; and generating a transition from the synchronizer sub-statechart for the at least one FORK node to the second working state to form the final version of the hierarchical statechart, responsive to the numbers of transitions being unequal (activated paths, for output branches, El-Nakhily ¶43-¶46).
At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to use El-Nakhily’s method of business process model analysis in Shivananda’s system to improve the system and method with reasonable expectation that this would result in a business process management system that is able to reduce or minimize issues with errors or exceptions.
The motivation being that there is a need for analyzing and reconstructing a business process model having an inclusive decision, and more particularly to a technique for synchronizing branches of an inclusive decision in a business process model (El-Nakhily ¶1).
As per claims 3 and 15, Shivananda and El-Nakhily disclose as shown above with respect to claims 2 and 14. Shivananda further discloses wherein the node analysis comprises analyzing each node of the BPM to identify the at least one FORK node and the at least one JOIN node (In some embodiments, the statechart may include pseudostates (e.g., forks, joins, and/or junctions). In some embodiments, pseudostates (or certain types thereof) may provide conditional branching for transitions in the statechart. For example, a state icon may be wired to a pseudostate in the statechart and multiple other wires may connect the pseudostate to other state icons in the diagram. Each of these wires may represent transitions with associated triggers, guards, and/or actions (as described above). Thus, the pseudostate may allow for conditioned branching of transitions in the statechart. Note that in various embodiments, transitions between states (e.g., single states, superstates, substates, or concurrently active states) and/or pseudostate may be ordered according to configured priorities (e.g., as specified by the user). These priorities may be assigned using explicit specification (e.g., using labels) or implicit specification (e.g., using orientation or directionality of the wires in the statechart), ¶80).
As per claims 6 and 18, Shivananda and El-Nakhily disclose as shown above with respect to claims 2 and 14. Shivananda further discloses wherein the second working state represents a current state of the BPM relative to the statechart (For example, a state icon may be wired to a pseudostate in the statechart and multiple other wires may connect the pseudostate to other state icons in the diagram. Each of these wires may represent transitions with associated triggers, guards, and/or actions (as described above). Thus, the pseudostate may allow for conditioned branching of transitions in the statechart. Note that in various embodiments, transitions between states (e.g., single states, superstates, substates, or concurrently active states) and/or pseudostate may be ordered according to configured priorities (e.g., as specified by the user). These priorities may be assigned using explicit specification (e.g., using labels) or implicit specification (e.g., using orientation or directionality of the wires in the statechart), Shivananda ¶80; see also ¶44-¶45 wherein the wires indicate status).
As per claims 7 and 19, Shivananda and El-Nakhily disclose as shown above with respect to claims 2 and 14. Shivananda further discloses wherein the transition from the working state of the FORK edge sub-statechart and the transition from the hierarchical state for the FORK node are unguarded (may have guards or conditions, Shivananda ¶76-¶77).
As per claims 9 and 21, Shivananda and El-Nakhily disclose as shown above with respect to claims 1 and 13. Shivananda further discloses wherein, responsive to identifying each of the at least one FORK node in the BPM in the node analysis, preparing the hierarchical state for the at least one FORK node by generating sub-statecharts for FORK edges and one synchronizer sub-statechart (One or more of the state icons may represent a hierarchical state, where a hierarchical state is a state that includes one or more sub-states. For example, a statechart may include a state (a superstate) which includes states (substates). The substates may be AND states (e.g., parallel or concurrently active states) or OR states (e.g., states which are not concurrently active). The statechart may also include pseudostates (e.g., forks, joins, and/or junctions), Shivananda ¶59-¶60).
As per claims 10-11 and 22-23, while Shivananda and El-Nakhily disclose a system to transform business process models, Shivananda and El-Nakhily do not expressly disclose that the business process models be “structured” or “unstructured.”
However, the Examiner asserts that the type of business process model is simply a label for the components and adds little, if anything, to the claimed acts or steps and thus does not serve to distinguish over the prior art. Any differences related merely to the meaning and information conveyed through labels (i.e., whether or not the models are structured) which does not explicitly alter or impact the steps of the method does not patentably distinguish the claimed invention from the prior art in terms of patentability.
Furthermore, under MPEP 2144.04, any differences related merely to the meaning and information conveyed through labels which does not explicitly alter or impact the functionality of the claimed invention, does not patentably distinguish the claimed invention from the prior art in terms of patentability. Also under MPEP 2144.04, it is obvious to merge/duplicate/replicate/rearrange components or parts as long as the components combined or isolated still perform the same functionality individually or collectively. Whether one big system module is implementing the functions, or whether several individual modules/components within the system are implementing the same functions, it does not explicitly or implicitly alter or impact the functionality of the system.
Therefore, it would have been obvious to a person of ordinary skill in the art at the effective filing date of the invention to modify the data to include “structured” or “unstructured” BPMs since the specific type of component does not functionally alter or relate to the steps of the method and merely labeling the information differently from that in the prior art does not patentably distinguish the claimed invention.
As per claims 12 and 24, Shivananda and El-Nakhily disclose as shown above with respect to claims 1 and 13. Shivananda further discloses responsive to identifying each of the at least one FORK node in the BPM in the node analysis, the method further comprises: assigning an initial state of one of two parallel paths created by the FORK node to a current state responsive to a first visit to the FORK node; and assigning the initial state of another one of the two parallel paths created by the FORK node to the current state responsive to a subsequent visit to the FORK node (For example, a state icon may be wired to a pseudostate in the statechart and multiple other wires may connect the pseudostate to other state icons in the diagram. Each of these wires may represent transitions with associated triggers, guards, and/or actions (as described above). Thus, the pseudostate may allow for conditioned branching of transitions in the statechart. Note that in various embodiments, transitions between states (e.g., single states, superstates, substates, or concurrently active states) and/or pseudostate may be ordered according to configured priorities (e.g., as specified by the user). These priorities may be assigned using explicit specification (e.g., using labels) or implicit specification (e.g., using orientation or directionality of the wires in the statechart), Shivananda ¶80; see also ¶44-¶45 wherein the wires indicate status).
As per claims 26-27, Sadiq and Shivananda disclose as shown above with respect to claim 1. Shivananda further teaches responsive to identifying each of the at least one FORK node in the BPM in a node analysis, generating a transition from the hierarchical state for the at least one FORK node to the working state responsive to a number of transitions to send synchronization events and a number of transitions to receive the synchronization events being equal based on respective counts being compared; responsive to the number of transitions to send synchronization events and a number of transitions to receive the synchronization events being unequal, creating a working state and a transition from the synchronizer to the working state, based on the respective counts being compared (Note further that the statechart performing actions during execution of the statechart may actually refer to actions that are performed by program instructions converted or compiled from the statechart performing the actions. For example, the statechart transitioning from one state to another may refer to corresponding actions being performed during execution of the program instructions created from the statechart. Additionally, where the program instructions are compiled or converted from the statechart, the program instructions may cause the statechart to change its appearance during execution (e.g., indicating current states of execution, transitions, etc.). Thus, execution of the statechart may refer to direct execution or interpretation of program instructions represented by the statechart and/or execution of program instructions compiled or derived from the statechart. The wires connecting the state icons may represent state transitions between the states. For example, a first state (represented as a first state icon in the statechart) may be linked to a second state (represented as a second state icon) via a transition (represented as a wire). The transition may have associated triggers, guards, and/or actions associated with the transition. For example, during execution of the statechart, an event may occur and may be specified as a trigger for the transition. Accordingly, the guards (or conditions associated with the transition) may be evaluated to determine if the transitions action should be performed or executed. If the conditions are met, the action may be performed, e.g., to execute code associated with the transition. Note that the transition (represented by the wire) may have any combination of associated triggers, guards, or actions. For example, in simple cases, the wire may only have associated triggers which result in a transition from, in this example, the first state to the second state, Shivananda ¶76-¶77).
Claims 4 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sadiq (US PG Pub. 2006/0143057) and Shivananda et al. (US Patent No. 9,047,168) El-Nakhily et al. (US PG Pub. 2010/0281241) further in view of Sadiq (US PG Pub. 2006/0143057).
As per claims 4 and 16, As per claims 3 and 14, Shivananda and El-Nakhily disclose as shown above with respect to claims 2 and 14. Shivananda and El-Nakhily do not expressly disclose wherein the BPM relates to inventory control, and the method further comprises automatically restocking an item having a current inventory below a threshold amount, responsive to a state in the final version of the hierarchical statechart relating to the current inventory (for use updating inventory records, Sadiq ¶3; automatically, ¶38) (Examiner interprets the ability to model inventory as the equivalent to the inventory control and the tasks including attributes such as thresholds for reorder).
However, Sadiq teaches wherein the BPM relates to inventory control, and the method further comprises automatically restocking an item having a current inventory below a threshold amount, responsive to a state in the final version of the hierarchical statechart relating to the current inventory (for use updating inventory records, Sadiq ¶3; automatically, ¶38) (Examiner interprets the ability to model inventory as the equivalent to the inventory control and the tasks including attributes such as thresholds for reorder).
The Sadiq, Shivananda, and El-Nakhily references are analogous in that both are directed towards/concerned with process modeling. At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to use Sadiq’s method of associating and integrating business process models in El-Nakhily and Shivananda’s system to improve the system and method with reasonable expectation that this would result in a business process management system that is able to reduce or minimize issues with errors or exceptions.
The motivation being that as a result of these and other difficulties associated with integrating and distributing business process models between or among enterprises, collaborations between or among enterprises may be limited. For example, the enterprises may only be able to interact in relatively simplistic manners, so that interactions between the enterprises are limited in quantity and complexity (Sadiq ¶7).
Furthermore, the limitations "wherein the BPM relates to inventory control, and the method further comprises automatically restocking an item having a current inventory below a threshold amount, responsive to a state in the final version of the hierarchical statechart relating to the current inventory " merely recite the intended use or result of a method step positively claimed and are not considered positive method steps or system elements.
Claims 5 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shivananda et al. (US Patent No. 9,047,168) and El-Nakhily et al. (US PG Pub. 2010/0281241) further in view of Barros (US PG Pub. 2008/0127205).
As per claims 5 and 17, Shivananda and El-Nakhily disclose as shown above with respect to claims 2 and 14. Shivananda and El-Nakhily do not expressly disclose wherein the node analysis, responsive to a non-first visit to the at least one JOIN node, the method further comprises moving backward on a traversal path used in the node analysis.
However, Barros teaches wherein the node analysis, responsive to a non-first visit to the at least one JOIN node, the method further comprises moving backward on a traversal path used in the node analysis (In some cases, within a particular, process model, an exception may be handled, for example, by "rolling back" or undoing the problematic task(s), or by executing a contingency for the problematic task(s). However, such solutions may be of little use if the process model is collaborating with remote process model(s) that, for example, execute based on an expectation of the process model (e.g., where a delivery truck is dispatched in expectation of an order being ready, or where an order is placed based on expectation of payment being received). Consequently, such exceptions should be managed in order to reduce or minimize an effect on associated, collaborating process models, Barros ¶6).
The Barros, Shivananda, and El-Nakhily references are analogous in that both are directed towards/concerned with process modeling. At the time of the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to use Barros’ method of error detection in El-Nakhily and Shivananda’s system to improve the system and method with reasonable expectation that this would result in a business process management system that is able to reduce or minimize issues with errors or exceptions.
The motivation being that there is a need for improved error or exception detection, despite the errors or exceptions not affecting the subsequent aspects (Barros ¶6).
Conclusion
THIS ACTION IS MADE FINAL. 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 extension fee 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 ANDREW B WHITAKER whose telephone number is (571)270-7563. The examiner can normally be reached on M-F, 8am-5pm, EST.
If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Lynda Jasmin can be reached on (571) 272-6782. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-
automated- interview-request-air-form
/ANDREW B WHITAKER/Primary Examiner, Art Unit 3629
Prosecution Insights