DETAILED ACTION
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 .
Claim status in the amendment received on 4/21/2026:
Claim 1 have been amended.
New claims 2-20 have been added.
Claims 1-20 are pending.
Response to Amendments
Applicant’s amendments have been considered and in response to the amendments:
The previous objection to the title of the invention has been withdrawn.
Response to Arguments
Applicant’s arguments have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-18 of Patent No. 12160338. Although the conflicting claims are not identical, they are not patentably distinct from each other because of following reasons:
Claims 1-18 of Patent No. 12160338 contain(s) every element of claim 1 of the instant application and thus anticipate the claim(s) of the instant application. Claims of the instant application therefore are not patently distinct from the earlier patent claims and as such are unpatentable over obvious-type double patenting. A later patent/application claim is not patentably distinct from an earlier claim if the later claim is anticipated by the earlier claim.
“A later patent claim is not patentably distinct from an earlier patent claim if the later claim is obvious over, or anticipated by, the earlier claim. In re Longi, 759 F.2d at 896, 225 USPQ at 651 (affirming a holding of obviousness-type double patenting because the claims at issue were obvious over claims in four prior art patents); In re Berg, 140 F.3d at 1437, 46 USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding of obviousness-type double patenting where a patent application claim to a genus is anticipated by a patent claim to a species within that genus). “ ELI LILLY AND COMPANY v BARR LABORATORIES, INC., United States Court of Appeals for the Federal Circuit, ON PETITION FOR REHEARING EN BANC (DECIDED: May 30, 2001).
“Claim 12 and Claim 13 are generic to the species of invention covered by claim 3 of the patent. Thus, the generic invention is "anticipated" by the species of the patented invention. Cf., Titanium Metals Corp. v. Banner, 778 F.2d 775, 227 USPQ 773 (Fed. Cir. 1985) (holding that an earlier species disclosure in the prior art defeats any generic claim) 4. This court's predecessor has held that, without a terminal disclaimer, the species claims preclude issuance of the generic application. In re Van Ornum, 686 F.2d 937, 944, 214 USPQ 761, 767 (CCPA 1982). Accordingly, absent a terminal disclaimer, claims 12 and 13 were properly rejected under the doctrine of obviousness-type double patenting.” (In re Goodman (CA FC) 29 USPQ2d 2010 (12/3/1993).
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, 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.
Claim(s) 1-4, 7, 9-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Michaelangelo et al. (Pub. No.: US 20160027019 A1) in view of Chandra et al. (Pub. No.: US 20190268288 A1) and further in view of Toal et al. (Pub. No.: US 20230214312 A1).
As to claim 1, Michaelangelo teaches a computer-implemented method for performing a control task for a real-world communications network, the computer-implemented method comprising: loading a data structure in memory, the data structure including one or more nodes corresponding to one or more steps of a workflow (paragraphs [0102] and [0134], “interactive guide” teaches the data structure, “step” teaches one or more nodes, accessing the interactive guide by the client teaches loading the data structure in memory, and fig. 6D, and fig. 1 teaches real-world communications network); and
executing the workflow, to perform the control task for the real-world communications network, by traversing a subset of the one or more nodes (paragraph [0141]), the traversing comprising, at each node of the subset:
determining a node type of the node (paragraph [0142], “step” teaches a node, question step teaches a determined question node type); and
responsive to determining the node type is not a final node type (paragraph [0144], “receiving a selection of one of the respective responses to the respective question in the initial guidance step (812)”, i.e. question of initial guidance step not a final node and paragraph [0148]):
determining a next node of the subset based on (i) a received data input associated with the node and (ii) one or more response values of the node, the one or more response values associated with the determined node type (paragraph [0144], “identifying a next guidance step that corresponds to the selected response (814) (e.g., guidance step 630-2, FIG. 6D)”, i.e. the selection teaches the received data input, the “YES” or “NO” values teaches the response values of the node); and
moving to the determined next node (paragraph [0144], “…and displaying the next guidance step (814) (e.g., guidance step 630-2, FIG. 6D)…”);
responsive to determining the node type is the final node type, completing the performance of the control task for the real-world communications network ([0148], “For example, while traversing an interactive guide, a user may navigate to a termination node (e.g., resolution 612-15, FIG. 6C), at which point the user is not presented with additional questions and does not select any additional responses.”).
Michaelangelo does not explicitly teach API node type for receiving API results and determining next nodes.
However, in the same field of endeavor (user interaction flows) Chandra teaches wherein for a given node of the subset, the node type is an application programming interface (API) type (paragraph [0011], “…programming interface (API) node for the step…”), and (a) the received data input is an API response received in response to invoking an API associated with the given node (paragraph [0011], “…the response returned from the function called via the API node”) , the API response including (ii) a result (paragraph [0011], “…the response returned from the function called via the API node”), and (b) the determining the next node of the subset comprises identifying a given response value of the one or more response values by comparing at least one of (i) the status and a status field of the given response value, (ii) the result and a result field of the given response value, and (iii) the message and a message field of the given response value (paragraph [0040]).
Based on Michaelangelo in view of Chandra, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate API node type for receiving API results and determining next nodes (taught by Chandra) with the workflow nodes (taught by Michaelangelo) in order to provide a user with dynamic user experience.
Michaelangelo in view of Chandra does not explicitly teach API response including status and a message.
However, in an analogous art (user interaction validation) Toal teaches API response including (i) a status, (ii) a result, and (iii) a message (paragraph [0074], “…API response 174 can include the results of API request 130 outlined within request payload 136, a value indicating whether API request 130 successfully executed, and/or any errors or message warnings …”).
Based on Michaelangelo in view of Chandra and further in view of Toal, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate API response including status and a message (taught by Toal) with API node type for receiving API results and determining next nodes (taught by Chandra) with the workflow nodes (taught by Michaelangelo) in order to provide a user with dynamic user experience and in order to provide more useful details associated with API response.
As to claim 2, Michaelangelo teaches wherein the traversing further includes, at each node of the subset: based on the determined node type, rendering, on a display, a graphical representation of the node (fig. 6D, 634-1 and 634-2).
As to claim 3, Michaelangelo teaches wherein, for at least one node of the subset:
the rendering, on the display, comprises rendering, on the display, the one or more response values (fig. 6D, 634-1 and 634-2);
the data input comprises a user input (paragraph [0144], “receiving a selection of one of the respective responses to the respective question in the initial guidance step (812) (e.g., response 634-1, FIG. 6D)”); and
the determining the next node of the subset based on (i) the received data input and (ii) the one or more response values of the at least one node, comprises: identifying, based on the received user input, one or more given response values of the one or more response values (paragraph [0144], “identifying a next guidance step that corresponds to the selected response (814) (e.g., guidance step 630-2, FIG. 6D)”, i.e. the selection teaches the received data input, the “YES” or “NO” values teaches the response values of the node); and
determining, based on the one or more given response values, the next node (paragraph [0144], “identifying a next guidance step that corresponds to the selected response (814) (e.g., guidance step 630-2, FIG. 6D)”, i.e. the selection teaches the received data input, the “YES” or “NO” values teaches the response values of the node).
As to claim 4, Michaelangelo teaches wherein the node type of the at least one node is at least one of: a radio button type, a checkbox type, and a field input type (fig. 6D, 634-1, 6342 and 635).
As to claim 7, Michaelangelo teaches where for at least one node of the subset, the node type is an escalation type (fig. 6D, 630-2 teaches an escalation type node, escalated from node 630-1), and wherein:
the rendering, on the display, comprises rendering, on the display, a communications interface for a communications channel associated with the at least one node (fig. 6, 630-2, the text field for entering additional information teaches the communication channel);
the data input comprises a user input received in response to rendering the communications interface (fig. 6D, i.e. receiving a selection ); and
the determining the next node of the subset based on (i) the received data input and (ii) the one or more response values of the at least one node, comprises: identifying, based on the received user input, a given response value of the one or more response values (fig. 6D, i.e. determining the “YES” or “NO” value); and
determining, based on the given response value, the next node (for example determining node 630-4 based on the response value).
As to claim 9, Michaelangelo teaches wherein, for at least one node of the subset, the rendering, on the display, comprises: rendering, on the display, an image (fig. 6D, 630-1 teaches an image, elements 634-1 and 634-2 teach an image as well).
As to claim 10, Michaelangelo teaches where for at least one node of the subset, the node type is a conditional type, and wherein:
the data input comprises one or more prior inputs corresponding to one or more nodes of the subset prior to the at least one node in the workflow (paragraph [0104], “(e.g., a response of guidance step 600-1 and a response of guidance step 600-2 both correspond to subsequent guidance step 600-7)”);
the determining the next node of the subset based on (i) the received data input and (ii) the one or more response values of the at least one node, comprises: identifying, based on the one or more prior inputs, a given response value of the one or more response values (paragraph [0104], “(e.g., a response of guidance step 600-1 and a response of guidance step 600-2 both correspond to subsequent guidance step 600-7)”); and
determining, based on the given response value, the next node (paragraph [0104], “In an example, if guidance step 600-1 indicates that a user is unable to adjust the volume of the television using a remote, and if guidance step 600-2 indicates that a user is unable to change a channel using a remote, guidance step 600-7 may include instructions for the user to check the batteries of the remote”).
As to claim 11, Michaelangelo teaches generating the data structure by defining the one or more nodes (paragraph [0101], i.e. defining nodes of graph 620-N).
As to claim 12, Michaelangelo teaches wherein defining the one or more nodes includes, for each node:
creating, in the data structure, based on a user input, a node entry corresponding to the node (paragraph [0050], “an authoring user application 107 for creating, deleting, and/or modifying interactive guides stored in the guide database 120” );
determining, based on the user input, the node type of the node (fig. 6D, 630-1, i.e. question node);
creating and populating, in the data structure, a node type field for the node based on the determined node type (fig. 6D, 630-1);
determining, based on the node type and the user input, one or more edge response values of the node (fig. 6D, 630-1, i.e. “YES” or “NO” values); and
creating, in the data structure, based on the user input, one or more edges of the data structure corresponding to the one or more edge response values, each of the one or more edges defining a connection between the node and an adjacent node of the data structure (fig. 6B, for example edges between node 600-2 and adjacent node 600-7).
As to claim 13, Michaelangelo teaches wherein the control task for the real-world communications network includes a control task for a real-world device, and wherein:
the control task for the real-world device includes at least one of: (i) activating the real-world device, (ii) configuring the real-world device, (iii) verifying one or more operating parameters of the real-world device, (iv) instantiating one or more virtual network functions for the real-world device, and (v) instantiating one or more virtual machines for the real-world device (paragraph [0103], “…a graph 620-N corresponds to one or more entry problems (e.g., TV is not working, premium channels are unavailable, etc.)…” teaches at least activating a real-world device).
As to claim 14, Michaelangelo further teaches a system for performing a control task for a real-world communications network, the system comprising: a processor; and a memory with computer code instructions stored thereon, the processor and the memory, with the computer code instructions (fig. 4). Therefore, the limitations of claim 14 are substantially similar to claim 1. Please refer to claim 1 above.
As to claim 15, Michaelangelo teaches further comprising a display and where, in the traversing, the processor and the memory, with the computer code instructions, are configured to cause the computer-based system to, at each node of the subset: based on the determined node type, render, on the display, a graphical representation of the node (fig. 6D, 634-1 and 634-2).
As to claim 16, the limitations of the claim are substantially similar to claim 3. Please refer to claim 3 above.
As to claims 17-18, the limitations of the claims are substantially similar to claims 11-12, respectively. Please refer to each respective claim above.
As to claim 19, the limitations of the claim are substantially similar to claim 13. Please refer to claim 13 above.
As to claim 20, Michaelangelo further teaches a computer program product for performing a control task for a real-world communications network, the computer program product comprising a non-transitory computer-readable medium with computer code instructions stored thereon, the computer code instructions being configured, when executed by a processor (paragraph [0017]). Therefore, the limitations of claim 20 are substantially similar to claim 1. Please refer to claim 1 above.
Claim(s) 5-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Michaelangelo et al. (Pub. No.: US 20160027019 A1) in view of Chandra et al. (Pub. No.: US 20190268288 A1) and Toal et al. (Pub. No.: US 20230214312 A1) and further in view of Soini et al. (Pub. No.: US 20170286199 A1).
As to claim 5, Michaelangelo in view of Chandra and further in view of Toal does not teach receiving and rendering time interval based on a countdown node type.
However, in the same field of endeavor (user interaction flows) Soini teaches for at least one node of the subset, the node type is a countdown type, and wherein: the data input comprises a time interval associated with the at least one node (fig. 3B, 308 and 313); and
the rendering, on the display, comprises rendering, on the display, the time interval (fig. 3B, 313).
Based on Michaelangelo in view of Chandra and Toal and further in view of Soini, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate receiving and rendering time interval based on a countdown node type (taught by Soini) with incorporating API response including status and a message (taught by Toal) with API node type for receiving API results and determining next nodes (taught by Chandra) with the workflow nodes (taught by Michaelangelo) in order to provide a user with dynamic user experience and in order to provide more useful details associated with API response, and in order to keep the user engaged in the actions performed, thereby resulting in a better user experience as motivated by Soini (paragraph [0063]).
As to claim 6, Soini further teaches suspending the executing the workflow for a duration of the time interval (paragraph [0082], i.e. until the diagnostic step is completed). The limitations of claim 6 are rejected in view of the analysis of claim 5 above, and the rationale to combine, as discussed in claim 5, applies here as well.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Michaelangelo et al. (Pub. No.: US 20160027019 A1) in view of Chandra et al. (Pub. No.: US 20190268288 A1) and Toal et al. (Pub. No.: US 20230214312 A1) and further in view of Lukes et al. (Pub. No.: US 20090276706 A1).
As to claim 8, Michaelangelo in view of Chandra and further in view of Toal does not teach acquiring a device image.
However, in the same field of endeavor (user interaction flows) Lukes teaches user input comprises: an image relating to a real-world device (paragraph [0179], “…technician can take pictures and video of the equipment which can be easily added to the appropriate troubleshooting steps…”).
Based on Michaelangelo in view of Chandra and Toal and further in view of Lukes, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate acquiring a device image (taught by Lukes) with incorporating API response including status and a message (taught by Toal) with API node type for receiving API results and determining next nodes (taught by Chandra) with the workflow nodes (taught by Michaelangelo) in order to provide a user with dynamic user experience and in order to provide more useful details associated with API response, and in order to ensures that the end user won't be confused by almost, but not quite accurate pictures and information. The repair process will be more accurate and quicker as motivated by Lukes (paragraph [0179]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDULKADER M ALRIYASHI whose telephone number is (313)446-6551. The examiner can normally be reached Monday - Friday, 8AM - 5PM Alt, Friday, EST.
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, JOON HWANG can be reached at (571)272-4036. 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.
/Abdulkader M Alriyashi/Primary Examiner, Art Unit 2447 6/22/2026
Prosecution Insights