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 .
Claims 21-40 are pending
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05/13/2025, 07/10/2025, 07/10/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 conflicting claims 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); 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 nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) 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 www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,683,385. Although the claims at issue are not identical, they are not patentably distinct from each other because one of ordinary skill in the art would have known that all of the limitations in the current application are disclosed in patent 11,683,385 which includes extra features in the claim limitation.
The table below shows only a sample of how each of these claims is anticipated by claims such as Claims 1-20 of Patent No. US 11,683,385 B2.
Instant Application 19/206,881
Patent No. US 11,683,385 B2.
A method comprising: performing, by one or more processors, operations including:
initiating, by a first component, an API call through an API gateway connected to a production firewall to initiate a connection to a second component to process saved data;
creating, by the second component using backend automation, a service ticket in a third component using the saved data;
determining, by the third component, based on the saved data and the service ticket, a location to send the saved data, wherein the determining the location to send the saved data includes determining whether the service ticket is associated with one or more of adding, deleting, or reinstating a user; and
using, by a terminal emulator, the saved data from the service ticket to automatically perform a manual operation that changes a component at the determined location.
2. The method of claim 1, wherein the data is saved in an .xml file.
3. The method of claim 1, wherein the API gateway is a Representational state transfer (REST) API used for sending parameters.
4. The method of claim 1, wherein the saved data is provided to the API gateway using a JavaScript Object Notation (JSON) format.
5. The method of claim 1, wherein the saved data defines an operation that a human user would use to perform the manual operation, and contains data that would otherwise be entered manually while performing the manual operation.
6. The method of claim 1, wherein the using the saved data to perform a manual operation includes using an open source 3270 terminal emulator.
7. The method of claim 1, wherein the operations further include: receiving data from a form in a webpage; validating the received data; and saving the validated data as the saved data.
8. The method of claim 1, wherein the manual operation includes logging into an application, navigating through specific screens via one or more of a mouse click or a keystroke, and entering the saved data into an area of functionality of the application.
9. The method of claim 1, wherein the determining the location to send the saved data includes acknowledging the service ticket and determining the determined location as a mainframe.
10. The method of claim 1, wherein the operations further include: sending a notification that the service ticket has been processed, and closing the service ticket.
11. A system comprising: a memory to store instructions; and one or more processors to execute the stored instructions to perform operations including: initiating, by a first component, an API call through an API gateway connected to a production firewall to initiate a connection to a second component to process saved data; creating, by the second component using backend automation, a service ticket in a third component using the saved data; determining, by the third component, based on the saved data and the service ticket, a location to send the saved data, wherein the determining the location to send the saved data includes determining whether the ticket is associated with one or more of adding, deleting, or reinstating a user; and using, by a terminal emulator, the saved data from the service ticket to automatically perform a manual operation that changes a component at the determined location.
12. The system of claim 11, wherein the data is saved in an .xml file.
13. The system of claim 11, wherein the API gateway is a Representational state transfer (REST) API used for sending parameters.
14. The system of claim 11, wherein the saved data is provided to the API gateway using a JavaScript Object Notation (JSON) format.
15. The system of claim 11, wherein the saved data defines an operation that a human user would use to perform the manual operation, and contains data that would otherwise be entered manually while performing the manual operation.
16. The system of claim 11, wherein the using the saved data to perform a manual operation includes using an open source 3270 terminal emulator.
17. The system of claim 11, wherein the operations further include: receiving data from a form in a webpage; validating the received data; and saving the validated data as the saved data.
18. The system of claim 11, wherein the manual operation includes logging into an application, navigating through specific screens via one or more of a mouse click or a keystroke, and entering the saved data into an area of functionality of the application.
19. The system of claim 11, wherein the determining the location to send the saved data includes acknowledging the service ticket and determining the determined location as a mainframe.
20. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, perform operations including: initiating, by a first component, an API call through an API gateway connected to a production firewall to initiate a connection to a second component to process saved data; creating, by the second component using backend automation, a service ticket in a third component using the saved data; determining, by the second component, based on the saved data and the service ticket, a location to send the saved data, wherein the determining the location to send the saved data includes determining whether the ticket is associated with one or more of adding, deleting, or reinstating a user; and using, by a terminal emulator, the saved data from the service ticket to automatically perform a manual operation that changes a component at the determined location.
A method comprising: performing, by a processor, operations including:
receiving data from a form in a webpage;
validating the received data;
saving the validated data;
initiating, by a decisions workflow component, an API call through an API gateway connected to a production firewall to initiate a connection to an automation services component to process the saved data;
creating, by the automation services component using backend automation, a service ticket in a digital workflow component using the saved data;
initiating, by the automation services component using backend automation, an API call in the digital workflow component to retrieve the service ticket;
authenticating, by a python service layer, the retrieved service ticket; determining, by the digital workflow component, based on the saved data and the service ticket, a location to send the saved data;
sending, by the digital workflow component, the saved data from the service ticket to the determined location;
invoking, by the automation services component using backend automation, an API at the determined location with the saved data from the service ticket;
using, by a terminal emulator, the saved data from the service ticket to automatically perform a manual operation that changes a component at the determined location; and
initiating, by the automation services component, an API call in the digital workflow component to close the service ticket.
The method of claim 1, wherein the validated data is saved in an .xml file.
The method of claim 1, wherein the API is a Representational state transfer (REST) API used for sending parameters.
4. The method of claim 1, wherein the saved data is provided to the API using a JavaScript Object Notation (JSON) format.
5. The method of claim 1, wherein the saved data defines an operation that a human user would use to perform the manual operation, and contains data that would otherwise be entered manually while performing the manual operation.
6. The method of claim 1, wherein the using the saved data to perform a manual operation includes using an open source 3270 terminal emulator.
7. The method of claim 1, wherein the receiving data from a form in a webpage includes using open source components written in Selenium Python.
8. The method of claim 1, wherein the manual operation includes logging into an application, navigating through specific screens via one or more of a mouse click or a keystroke, and entering the saved data into an area of functionality of the application.
9. The method of claim 1, wherein the determining the location to send the saved data includes: acknowledging a service ticket raised by a requestor, determining whether the service ticket is associated with user administration including one or more of adding, deleting, or reinstating a user, and determining the determined location as a mainframe.
10. The method of claim 9, further comprising sending a notification to the requestor that the service ticket has been processed, and closing the service ticket.
11. A system comprising: a memory to store instructions; and a processor to execute the stored instructions to perform operations including: receiving data from a form in a webpage; validating the received data; saving the validated data; initiating, by a decisions workflow component, an API call through an API gateway connected to a production firewall to initiate a connection to an automation services component to process the saved data; creating, by the automation services component using backend automation, a service ticket in a digital workflow component using the saved data; initiating, by the automation services component using backend automation, an API call in the digital workflow component to retrieve the service ticket; authenticating, by a python service layer, the retrieved service ticket; determining, by the digital workflow component, based on the saved data and the service ticket, a location to send the saved data; sending, by the digital workflow component, the saved data from the service ticket to the determined location; invoking, by the automation services component using backend automation, an API at the determined location with the saved data from the service ticket; using, by a terminal emulator, the saved data from the service ticket to automatically perform a manual operation that changes a component at the determined location; and initiating, by the automation services component, an API call in the digital workflow component to close the service ticket.
12. The system of claim 11, wherein the validated data is saved in an .xml file.
13. The system of claim 11, wherein the API is a Representational state transfer (REST) API used for sending parameters.
14. The system of claim 11, wherein the saved data is provided to the API using a JavaScript Object Notation (JSON) format.
15. The system of claim 11, wherein the saved data defines an operation that a human user would use to perform the manual operation, and contains data that would otherwise be entered manually while performing the manual operation.
16. The system of claim 11, wherein the using the saved data to perform a manual operation includes using an open source 3270 terminal emulator.
17. The system of claim 11, wherein the receiving data from a form in a webpage includes using open source components written in Selenium Python.
18. The system of claim 11, wherein the manual operation includes logging into an application, navigating through specific screens via one or more of a mouse click or a keystroke, and entering the saved data into an area of functionality of the application.
19. The system of claim 11, wherein the determining the location to send the saved data includes: acknowledging a service ticket raised by a requestor, determining whether the service ticket is associated with user administration including one or more of adding, deleting, or reinstating a user, and determining the determined location as a mainframe.
20. A non-transitory computer-readable medium storing instructions that, when executed by a processor, perform operations including: receiving data from a form in a webpage; validating the received data; saving the validated data; initiating, by a decisions workflow component, an API call through an API gateway connected to a production firewall to initiate a connection to an automation services component to process the saved data; creating, by the automation services component using backend automation, a service ticket in a digital workflow component using the saved data; initiating, by the automation services component using backend automation, an API call in the digital workflow component to retrieve the service ticket; authenticating, by a python service layer, the retrieved service ticket; determining, by the digital workflow component, based on the saved data and the service ticket, a location to send the saved data; sending, by the digital workflow component, the saved data from the service ticket to the determined location; invoking, by the automation services component using backend automation, an API at the determined location with the saved data from the service ticket; using, by a terminal emulator, the saved data from the service ticket to automatically perform a manual operation that changes a component at the determined location; and initiating, by the automation services component, an API call in the digital workflow component to close the service ticket.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,335,346. Although the claims at issue are not identical, they are not patentably distinct from each other because one of ordinary skill in the art would have known that all of the limitations in the current application are disclosed in patent 12,335,346 which includes extra features in the claim limitation.
The table below shows only a sample of how each of these claims is anticipated by claims such as Claims 1-20 of Patent No. US 12,335,346 B2.
Instant Application 19/206,881
Patent No. US 11,683,385 B2.
A method comprising: performing, by one or more processors, operations including:
initiating, by a first component, an API call through an API gateway connected to a production firewall to initiate a connection to a second component to process saved data;
creating, by the second component using backend automation, a service ticket in a third component using the saved data;
determining, by the third component, based on the saved data and the service ticket, a location to send the saved data, wherein the determining the location to send the saved data includes determining whether the service ticket is associated with one or more of adding, deleting, or reinstating a user; and
using, by a terminal emulator, the saved data from the service ticket to automatically perform a manual operation that changes a component at the determined location.
2. The method of claim 1, wherein the data is saved in an .xml file.
3. The method of claim 1, wherein the API gateway is a Representational state transfer (REST) API used for sending parameters.
4. The method of claim 1, wherein the saved data is provided to the API gateway using a JavaScript Object Notation (JSON) format.
5. The method of claim 1, wherein the saved data defines an operation that a human user would use to perform the manual operation, and contains data that would otherwise be entered manually while performing the manual operation.
6. The method of claim 1, wherein the using the saved data to perform a manual operation includes using an open source 3270 terminal emulator.
7. The method of claim 1, wherein the operations further include: receiving data from a form in a webpage; validating the received data; and saving the validated data as the saved data.
8. The method of claim 1, wherein the manual operation includes logging into an application, navigating through specific screens via one or more of a mouse click or a keystroke, and entering the saved data into an area of functionality of the application.
9. The method of claim 1, wherein the determining the location to send the saved data includes acknowledging the service ticket and determining the determined location as a mainframe.10. The method of claim 1, wherein the operations further include: sending a notification that the service ticket has been processed, and closing the service ticket.
11. A system comprising: a memory to store instructions; and one or more processors to execute the stored instructions to perform operations including: initiating, by a first component, an API call through an API gateway connected to a production firewall to initiate a connection to a second component to process saved data; creating, by the second component using backend automation, a service ticket in a third component using the saved data; determining, by the third component, based on the saved data and the service ticket, a location to send the saved data, wherein the determining the location to send the saved data includes determining whether the ticket is associated with one or more of adding, deleting, or reinstating a user; and using, by a terminal emulator, the saved data from the service ticket to automatically perform a manual operation that changes a component at the determined location.
12. The system of claim 11, wherein the data is saved in an .xml file.
13. The system of claim 11, wherein the API gateway is a Representational state transfer (REST) API used for sending parameters.
14. The system of claim 11, wherein the saved data is provided to the API gateway using a JavaScript Object Notation (JSON) format.
15. The system of claim 11, wherein the saved data defines an operation that a human user would use to perform the manual operation, and contains data that would otherwise be entered manually while performing the manual operation.
16. The system of claim 11, wherein the using the saved data to perform a manual operation includes using an open source 3270 terminal emulator.
17. The system of claim 11, wherein the operations further include: receiving data from a form in a webpage; validating the received data; and saving the validated data as the saved data.
18. The system of claim 11, wherein the manual operation includes logging into an application, navigating through specific screens via one or more of a mouse click or a keystroke, and entering the saved data into an area of functionality of the application.
19. The system of claim 11, wherein the determining the location to send the saved data includes acknowledging the service ticket and determining the determined location as a mainframe.
20. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, perform operations including: initiating, by a first component, an API call through an API gateway connected to a production firewall to initiate a connection to a second component to process saved data; creating, by the second component using backend automation, a service ticket in a third component using the saved data; determining, by the second component, based on the saved data and the service ticket, a location to send the saved data, wherein the determining the location to send the saved data includes determining whether the ticket is associated with one or more of adding, deleting, or reinstating a user; and using, by a terminal emulator, the saved data from the service ticket to automatically perform a manual operation that changes a component at the determined location.
1. A method comprising: performing, by one or more processors, operations including: initiating, by a decisions workflow component, an API call through an API gateway connected to a production firewall to initiate a connection to an automation services component to process saved data, wherein the saved data has been validated; validating, by a service layer, the saved data; creating, by the automation services component using backend automation, a service ticket in a digital workflow component using the saved data; authenticating, by a service layer, the service ticket; determining, by the digital workflow component, based on the saved data and the service ticket, a location to send the saved data, wherein the determining the location to send the saved data includes determining whether the service ticket is associated with one or more of adding, deleting, or reinstating a user; sending, by the digital workflow component, the saved data from the service ticket to the determined location; and using, by a terminal emulator, the saved data from the service ticket to automatically perform a manual operation that changes a component at the determined location.
2. The method of claim 1, wherein the data is saved in an .xml file.
3. The method of claim 1, wherein the API is a Representational state transfer (REST) API used for sending parameters.
4. The method of claim 1, wherein the saved data is provided to the API using a JavaScript Object Notation (JSON) format.
5. The method of claim 1, wherein the saved data defines an operation that a human user would use to perform the manual operation, and contains data that would otherwise be entered manually while performing the manual operation.
6. The method of claim 1, wherein the using the saved data to perform a manual operation includes using an open source 3270 terminal emulator.
7. The method of claim 1, wherein the operations further include: receiving data from a form in a webpage; validating the received data; and saving the validated data as the saved data.
8. The method of claim 1, wherein the manual operation includes logging into an application, navigating through specific screens via one or more of a mouse click or a keystroke, and entering the saved data into an area of functionality of the application.
9. The method of claim 1, wherein the determining the location to send the saved data includes acknowledging the service ticket and determining the determined location as a mainframe.
10. The method of claim 1, wherein the operations further include: sending a notification that the service ticket has been processed, and closing the service ticket.
11. A system comprising: a memory to store instructions; and one or more processors to execute the stored instructions to perform operations including: initiating, by a decisions workflow component, an API call through an API gateway connected to a production firewall to initiate a connection to an automation services component to process saved data, wherein the saved data has been validated; validating, by a service layer, the saved data; creating, by the automation services component using backend automation, a service ticket in a digital workflow component using the saved data; authenticating, by a service layer, the service ticket; determining, by the digital workflow component, based on the saved data and the service ticket, a location to send the saved data, wherein the determining the location to send the saved data includes determining whether the ticket is associated with one or more of adding, deleting, or reinstating a user; sending, by the digital workflow component, the saved data from the service ticket to the determined location; and using, by a terminal emulator, the saved data from the service ticket to automatically perform a manual operation that changes a component at the determined location.
12. The system of claim 11, wherein the data is saved in an .xml file.
13. The system of claim 11, wherein the API is a Representational state transfer (REST) API used for sending parameters.
14. The system of claim 11, wherein the saved data is provided to the API using a JavaScript Object Notation (JSON) format.
15. The system of claim 11, wherein the saved data defines an operation that a human user would use to perform the manual operation, and contains data that would otherwise be entered manually while performing the manual operation.
16. The system of claim 11, wherein the using the saved data to perform a manual operation includes using an open source 3270 terminal emulator.
17. The system of claim 11, wherein the operations further include: receiving data from a form in a webpage; validating the received data; and saving the validated data as the saved data.
18. The system of claim 11, wherein the manual operation includes logging into an application, navigating through specific screens via one or more of a mouse click or a keystroke, and entering the saved data into an area of functionality of the application.
19. The system of claim 11, wherein the determining the location to send the saved data includes acknowledging the service ticket and determining the determined location as a mainframe.
20. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, perform operations including: initiating, by a decisions workflow component, an API call through an API gateway connected to a production firewall to initiate a connection to an automation services component to process saved data, wherein the saved data has been validated; validating, by a service layer, the saved data; creating, by the automation services component using backend automation, a service ticket in a digital workflow component using the saved data; authenticating, by a service layer, the service ticket; determining, by the digital workflow component, based on the saved data and the service ticket, a location to send the saved data, wherein the determining the location to send the saved data includes determining whether the ticket is associated with one or more of adding, deleting, or reinstating a user; sending, by the digital workflow component, the saved data from the service ticket to the determined location; and using, by a terminal emulator, the saved data from the service ticket to automatically perform a manual operation that changes a component at the determined location.
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.
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.
Claims 1-5, 7, 9, 11-15, 17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Eigner (US 2017/0277774) and in view of Leavitt (US 2020/0314240).
With regards to claim 1, Eigner further discloses:
A method comprising: performing, by a processor, operations including:
initiating, by a first component, an API call through an API gateway connected to a production firewall to initiate a connection to a second component to process saved data ([0077]-[0078], using a browser extension to obtain a set of information for a user for the form, fields and content to be captured);
creating, by the second component using backend automation, a service ticket in a third component using the saved data ([0078]-[0080], using automatic mapping techniques. browser extension allows the form to have a field name and creates a unique numerical identifier for each field);
determining, by the third component, based on the saved data and the service ticket, a location to send the saved data ([0101], saves the information to a separate data store);
using, by a terminal emulator, the saved data from the service ticket to automatically perform a manual operation that changes a component at the determined location ([0082], if the unique code for the field value has not been previously entered, user will manually enter the field value).
While Eigner discloses storing information into different categories and databases, Eigner does not clearly disclose, however Leavitt discloses wherein the determining the location to send the saved data includes determining whether the service ticket is associated with one or more of adding, deleting, or reinstating a user ([0121], [0130], whenever an account is created with the emergency response application, the account is stored within the user database 868 (location) and populated with information regarding the account..
It would have been obvious for one of ordinary skill in the art before the date the current invention was effectively filed to have modified the teachings of Eigner by the system of Leavitt to collect information and store data in a certain database so it is able to provide security precautions. One of ordinary skill in the art would have been motivated to incorporate the teachings with one another in order to provide a more secure response application through webpages by using user database that are communicatively coupled to a credential management system.
With respect to claim 2, one of ordinary level of skill in the art would have been
compelled to make the proposed modification to Eigner for the same reasons identified in the rejection of claim 1. In addition, Leavitt discloses wherein the data is saved in an .xml file ([0204], suitable databases for storage and retrieval include XML databases. ).
With respect to claim 3, one of ordinary level of skill in the art would have been compelled to make the proposed modification to Eigner for the same reasons identified in the rejection of claim 1. In addition, Leavitt discloses wherein the API gateway is a Representational state transfer (REST) API used for sending parameters ([0074], location retrieval module is a JSON REST API).
With respect to claim 4, one of ordinary level of skill in the art would have been compelled to make the proposed modification to Eigner for the same reasons identified in the rejection of claim 1. In addition, Leavitt discloses wherein the saved data is provided to the API gateway using a JavaScript Object Notation (JSON) format ([0074], location retrieval module is a JSON REST API).
With respect to claim 5, Eigner discloses wherein the saved data defines an operation that a human user would use to perform the manual operation, and contains data that would otherwise be entered manually while performing the manual operation (]0121]-[0122], user is provided with a form completion indicator that would populate based on any form field that would require a manual typing of information).
With respect to claim 7, Eigner discloses receiving data from a form in a webpage ([0078], user completes a form displayed in an internet-browser application);
validating the received data ([0168], remote service verifies the user’s license credentials);
saving the validated data ([0089] storing the information in at least two or three separate data store locations).
With respect to claim 9, Eigner discloses wherein the determining the location to send the saved data includes acknowledging the service ticket and determining the determined location as a mainframe ([0081]-[0082], [0101] unique field names are stored and organized. I.E. the unique billing code field can be classified as a field for the “billing” section”. User’s name, social security number, birthday, employer id, etc. is stored in a separate data store).
With respect to claims 11-15, 17, and 19-20, they are of similar claims as claims 1-5, 7 and 9 and therefore are rejected for the same reasons above.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Eigner and in view of Leavitt and in view of Mathewson (US 6,327,624).
With regards to claims 6 and 16, Eigner and Leavitt does not disclose however Mathewson discloses wherein the using the saved data to perform a manual operation includes using an open source 3270 terminal emulator (col. 2, lines 28-60, HTML gateway and a 3270 emulator to reproduce visual appearance of 3270 screen).
It would have been obvious for one of ordinary skill in the art before the date the current invention was effectively filed to have modified the teachings of Eigner and Leavitt by the system of Mathewson to integrate java and other objects with legacy 3270 applications. One of ordinary skill in the art would have been motivated to incorporate the teachings with one another in order to provide well known architecture that uses 3270 datastream architecture.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Eigner and in view of Leavitt and in view of D’Souza (US 6,625,649).
With regards to claims 8 and 18, Eigner and Leavitt does not disclose however D’souza discloses wherein the manual operation includes logging into an application, navigating through specific screens via one or more of a mouse click or a keystroke, and entering the saved data into an area of functionality of the application (Dsouza ‘649, col. 1, lines 24-45, application generates series of screens after use accesses and request specific selections by user involving keystrokes and movements).
It would have been obvious for one of ordinary skill in the art before the date the current invention was effectively filed to have modified the teachings of Eigner and Leavitt by the system of D’souza to generate series of screens for specific selections by users. One of ordinary skill in the art would have been motivated to incorporate the teachings with one another in order to launching specific application programs.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Eigner and in view of Leavitt and in view of Norris (US 2014/0129611, hereinafter Norris).
With regards to claim 10, Eigner and Leavitt does not disclose however Norris sending a notification that the service ticket has been processed, and closing the service ticket ([0042-[0044]], PA Agent receives request message to perform function on mainframe and provides received information upon receiving code instructions.).
It would have been obvious for one of ordinary skill in the art before the date the current invention was effectively filed to have modified the teachings of Eigner and Leavitt by the system of Norris to record completed functions. One of ordinary skill in the art would have been motivated to incorporate the teachings with one another in order to utilize a process automation system to add automation functions.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HO T SHIU whose telephone number is (571)270-3810. The examiner can normally be reached Mon-Fri (9:00am - 5:00pm).
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, Nicholas Taylor can be reached at 571-272-3089. 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.
/HO T SHIU/Examiner, Art Unit 2443
HO T. SHIU
Examiner
Art Unit 2443
/CHRISTOPHER B ROBINSON/Primary Examiner, Art Unit 2443
Prosecution Insights