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 .
Response to Arguments
Applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
1. Claims 1-22 are rejected under 35 U.S.C. 112(b) as being as being incomplete for omitting essential steps, such omission amounting to a gap between the steps. See MPEP § 2172.01. The omitted steps are: the functional relationship and connecting steps between the manager terminal and the user terminal.
Claim 1 recites “transmitting information on the control details to a manager who is different from the user, and transmitting an execution request of the control details to the first legacy system based on a receipt of an approval signal from the manager terminal, the approval signal indicating an approval of control of the first legacy system by the user through the chat bot service.” However, the claims are unclear as to how the steps relate to each other.
Step by step claims recite that (1) transmit control information to the manager terminal, (2) then transmit an execution request based on an approval signal from the manager terminal, (3) finally wherein the approval signal indicates an approval by the user through the chat bot.
However, the claim is unclear as to how the manager terminal and the user/user terminal are related to one another, resulting in a gap between steps. Specifically, the claim does not show how the manager terminal becomes capable of indicating the user has approved control.
The claim do not even provide any structural connection or hierarchical relationship between the two elements, i.e. the claims do not show the terminals are on the same network, nor does the claim establish that the manager terminal “manages” any element of the claims.
Claims 2-22 are rejected for the same reasons as Claim 1.
Claim 2 is indefinite. Claim 2 recites “based on the control target legacy system not satisfying a condition,” while Claim 1 recites “based on the control target legacy system satisfying a condition.” It is unclear how the method steps recited in both Claim 2 and Claim 1 can be executed as the control target legacy system cannot satisfy and not satisfy the condition.
Examiner notes that neither claim recites a step that determines whether the control target legacy system satisfies a condition, and as such the method is not adequately clear on how, and whether or not, the claims actively handle the contingency.
Claims 3-4 are rejected for the same reasons as Claim 2.
Claim 6 recites “the predefined manager forced confirmation.” There is insufficient antecedent basis for the claim element.
Claim 7 recites “determined as satisfying the condition when the user terminal… is connected to an external network.” The claim is unclear clear as to whether “when the user terminal… is connected to an external network” is a timing contingency or whether is how satisfying the condition is determined.
Claim 8 recites “wherein the receiving the control details for the first legacy further includes… determining… skipping….” The claim is unclear as to how “receiving” can include “determining or skipping.” Applicant appears to be using a novel definition of receiving, but has not adequately provided their new definition so as to make the claim clear.
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.
2. Claims 1-7, 10-13, 17, 19-20, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Fawcett et al. (US 20190199657 A1) in view of Waters et al. (US 20230093882 A1).
Claim 1 Fawcett teaches a method for controlling a legacy system based on a chatbot service, performed in a computing system, the method comprising:
receiving legacy system (Examiner interprets a “legacy” system as being any current system, as legacy merely requires development from it) selection information indicating that a first legacy system is selected by a user as a control target legacy system, (Fawcett, FIG. 3A, step 302, ¶0060, receiving a modified message 250, FIG. 2b starting a conversation with the chatbot server 102 FIG. 1, wherein the modified message comprises supplementary component 260; ¶0062, wherein supplementary component selecting the primary system 104 as the control target legacy system, i.e. the system that is being targeted for control; Examiner notes that “information indicating… is selected” can be interpreted functionally, rather than mechanically, i.e., the information does not limited to a selection input, but rather can be information indicating such a selection input occurred) from a user terminal of the user through the chatbot service; (Fawcett, FIG. 6, from mobile device 108 through chatbot 600)
receiving control details for the first legacy system from the user terminal through the chatbot service; (Fawcett, FIG. 3A, ¶0062, wherein the supplementary component comprises control detail for the primary system, i.e. the legacy system)
based on the control target legacy system satisfying a condition, (Examiner interprets being selected by the user as satisfying a condition, which the subsequent transmission step would be based upon) transmitting information on the control details, (Fawcett, FIG. 3A, step 304, ¶0064, transmitting a chat message to the mobile device, wherein the chat message comprises information on the control details) and transmitting an execution result of the control details (Fawcett, FIG. 3B, step 322, ¶0071, transmitting an execution result to the legacy system, i.e. transmitting the result of the chat to the primary system) based on a receipt of an approval signal, the approval signal indicating an approval of control of the first legacy system by the user through the chat bot service; (FIG. 3B, 10071, wherein chat prompt is only transmitted when an appropriate signal is received, i.e. an approval signal, for example, "now") and
receiving an execution result of the control details from the first legacy system, (Fawcett, FIG. 3B, step 338, ¶0074, obtaining the full details of the execution result) and outputting a chatbot message of the execution to the user terminal result through the chatbot service. (Fawcett, FIG. 3B, step 340, ¶0074, outputting the full details of the of the task through the chatbot messaging service)
However, Fawcett does not explicitly teach wherein the control details are transmitted to a manager terminal of a manager who is different from the user, and wherein the approval signal is from the manager terminal.
From a related technology, Waters teaches control details are transmitted to a manager terminal of a manager who is different from the user, (FIG. 5, step 510, ¶0072, receiving an indication of approval from the user, wherein the indication comprises control detail) and wherein the approval signal is transmitted from the manager terminal. (FIG. 5, step 512, ¶0073, wherein an invoked command comprises the approval signal)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Fawcett to incorporate a manager terminal to mediate authorization within the system to more effectively utilize network resources.
Claim 2 Fawcett in view Waters teaches Claim 1, and further teaches wherein the condition is that the first legacy system requires a predefined manager forced conformation; (Waters, ¶0073, wherein the invoked command comprises the predefined manager forced confirmation) and
wherein the method further comprises transmitting, based on the control target legacy system not satisfying the condition, the execution request of the control details to the first legacy system (Fawcett, FIG. 3A, step 304, ¶0064, transmitting a chat message to the mobile device, wherein the chat message comprises information on the control details) without an approval from the manager terminal. (Examiner notes that neither Fawcett nor Waters invoke approval from the manager terminal, rather Waters invokes approval from the user)
Claim 3 Fawcett in view Waters teaches Claim 2, and further teaches wherein the first legacy system is connected to a closed network, (Examiner notes that any device would comprise a “closed” network) the determining whether the first legacy system requires the predefined manager forced confirmation requirement (Fawcett, ¶0064, determine whether the user’s chosen option satisfies a predefined forced confirmation requirement comprising “now”) includes determining that the first legacy system does not requirethe predefined manager forced confirmation requirement when the user terminal is connected to a closed network. (Fawcett, ¶0064, determine whether the user’s chosen option does not satisfy the requirement of “now,” for example whether the option selected was “later” or “office”)
Claim 4 Fawcett in view Waters teaches Claim 2, and further teaches checking an attribute as to checking of a chatbot-based control manager among attributes of the first legacy system from configuration information; (Fawcett, ¶0064, checking the attribute of the chosen option of the legacy system from config info provided) and as a result of checking, when the attribute as to checking of the chatbot-based control manager of the first legacy system has a pre-designated value, (Fawcett, ¶0064, wherein the attribute has a predesignated value of “now”) determining that the first legacy system requires the predefined manager forced confirmation requirement. (Fawcett, ¶0064, determine whether the user’s chosen option satisfies a predefined forced confirmation requirement comprising “now”)
Claim 5 Fawcett in view Waters teaches Claim 1, and further teaches wherein the outputting the chatbot message of the execution result through the chatbot service includes transmitting a message reporting the execution result to a terminal of the manager. (Fawcett, FIG. 3B, step 340, ¶0074, outputting the full details of the of the task through the chatbot messaging service, wherein the results are output to the terminal)
Claim 6 Fawcett in view Waters teaches Claim 1, and further teaches checking whether a user of the user terminal has a control authority for the first legacy system by using user information of the chatbot service; (Fawcett, ¶0060 and ¶0061, checking whether the user has authority using the provided data) and determining whether the first legacy system requires the predefined forced confirmation requirement (Fawcett, ¶0064, determine whether the user’s chosen option satisfies a predefined forced confirmation requirement comprising “now”) the user terminal has the control authority for the first legacy system. (Examiner notes that the limitation is only a condition, but does not require an implementation of a step, and therefore as the user terminal has input command that control the first legacy system, Fawcett, ¶0064, Examiner consider the user terminal as having control authority)
Claim 7 Fawcett in view Waters teaches Claim 1, but does not explicitly teach wherein the first legacy system is connected to a closed network (Examiner notes that any device would comprise a “closed” network) distinguished from an external network, to which the user terminal connected to the chatbot service is connected, by one or more firewall systems. (Fawcett, FIG. 1, ¶0046, wherein the primary system and chatbot server system are connected to a closed network, Examiner notes that network 100 does not connect to the internet and only connect between the app, chatbot, and primary system; Examiner also interprets the chatbot system as being a firewall, i.e. a security wall, between the legacy, i.e. primary system, and the rest of the closed network)
Claim 10 Fawcett in view Waters teaches Claim 1, and further teaches wherein the receiving the control details for the first legacy system includes receiving a selection input for the first legacy system through the chatbot service as a response to display of a list of a plurality of connectable legacy systems through the chatbot service. (Fawcett, FIG. 3A, ¶0062, wherein the supplementary component comprises control detail for the primary system, i.e. the legacy system, wherein the supplementary component comprises the connectable systems)
Claim 11 Fawcett teaches a method for controlling a legacy system based on a chatbot service, performed in a computing system, the method comprising:
providing, to a user terminal, a card generation interface for registering a card type chatbot interface for receiving, from a user through the user terminal, control details for a first legacy system; (Fawcett, FIG. 3A, step 304, ¶0064, transmitting a chat message to the mobile device, the message comprising a card generation interface)
providing the registered card type chatbot interface on the chatbot service in response to a selection by the user of the registered card type chatbot interface; (Fawcett, FIG. 3A, step 304, ¶0064, transmitting a chat message to the mobile device, wherein the chat message comprises information on the details)
transmitting control details description data generated using information input from the user terminal, to the first legacy system through the card type chatbot interface; (Fawcett, FIG. 3A, step 304, ¶0064, transmitting a chat message to the mobile device, wherein the chat message comprises information on the control details) and
receiving an execution result of the control details described in the control details description data from the first legacy system (Fawcett, FIG. 3B, step 338, ¶0074, obtaining the full details of the execution result) and outputting a chatbot message of the execution result through the chatbot service. (Fawcett, FIG. 3B, step 340, ¶0074, outputting the full details of the of the task through the chatbot messaging service)
However, Fawcett does not explicitly teach wherein the card generation interface includes an application programing interface (API) selection area including a selection control that allows the user to select, among one or more APIs pre-registered with respect to the first legacy system, an API to be bound to the card type chatbot interface.
From a related technology Waters teaches an application programing interface (API) selection area (Waters, ¶0111, providing an API interface) including a selection control that allows the user to select, among one or more APIs pre-registered with respect to the first legacy system, an API to be bound to the card type chatbot interface. (Waters, ¶0111, wherein there are many APIs included in the computing system that can be selected)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Fawcett to incorporate a manager terminal to mediate authorization within the system to more effectively utilize network resources.
Claim 12 Fawcett in view Waters teaches Claim 11, and further teaches wherein the card type chatbot interface is an adaptive card type interface represented by JavaScript Object Notation (JSON) and rendered by a client application of the chatbot service. (Fawcett, ¶0053, wherein the structure of the message type is represented and rendered by JSON)
Claim 13 Fawcett in view Waters teaches Claim 11, and further teaches wherein the providing the registered card type chatbot interface on the chatbot service includes providing a card type chatbot interface selected by the user among a plurality of card type chatbot interfaces registered by a user of the user terminal on the chatbot service with the user of the user terminal. (Fawcett, FIG. 3A, step 304, ¶0064, transmitting a chat message to the mobile device, the message comprising a card generation interface, wherein the chat message is one of a type of card type chatbot interfaces)
Claim 17 Fawcett in view Waters teaches Claim 14, and further teaches wherein the outputting the chatbot message of the execution result through the chatbot service includes outputting the chatbot message of the execution result (Fawcett, FIG. 3B, step 340, ¶0074, outputting the full details of the of the task through the chatbot messaging service) including a download button of a download file with respect to the execution result when an API of an execution result download type is selected through the API selection area. (Fawcett, step 340, wherein the selection to output the details comprises a download button for an execution result download type)
Claim 19 is taught by Fawcett in view of Waters as described for Claim 1.
Claim 20 Fawcett in view Waters teaches Claim 19, and further teaches wherein the one or more legacy systems are systems connected to a closed network connected to an external network by one or more firewall systems, and the chatbot service system is a system connected to the closed network. (Fawcett, FIG. 1, ¶0046, wherein the primary system and chatbot server system are connected to a closed network, Examiner notes that network 100 does not connect to the internet and only connect between the app, chatbot, and primary system; Examiner also interprets the chatbot system as being a firewall, i.e. a security wall, between the legacy, i.e. primary system, and the rest of the closed network)
Claim 22 is taught by Fawcett in view of Waters as described for Claim 6.
3. Claims 8-9 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Fawcett et al. (US 20190199657 A1) in view of in view of Waters et al. (US 20230093882 A1) and in further view of Gordon et al. (US 20220311615 A1).
Claim 8 Fawcett in view of Waters teaches Claim 1, and further teaches wherein the first legacy system is a system connected to a closed network, and the receiving the control details for the first legacy system includes:
determining whether the user terminal connected to the chatbot service is connected to an external network distinguished from the closed network by one or more firewall systems. (Fawcett, FIG. 1, ¶0046, wherein the primary system and chatbot server system are connected to a closed network, Examiner notes that network 100 does not connect to the internet and only connect between the app, chatbot, and primary system; Examiner also interprets the chatbot system as being a firewall, i.e. a security wall, between the legacy, i.e. primary system, and the rest of the closed network)
However, Fawcett in view of Waters does not explicitly teach performing 2-factor authentication (2FA) for a user terminal when a user terminal is connected to an external network; and
outputting an error message through a chatbot service when it is determined that the 2FA is failed.
From a related technology, Gordon teaches performing 2-factor authentication (2FA) for a user terminal when a user terminal is connected to an external network; (FIG. 2, IED 20, ¶0044, performing a multi-factor authentication, i.e. at least 2 factor, authentication wen the terminal is connected to an external network) and
outputting an error message through a chatbot service when it is determined that the 2FA is failed. (FIG. 2, ¶0044, sending a notification after a failed attempt)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Fawcett in view of Waters in order to more effectively control system access to desired users and therefore efficiently utilize network resources.
Claim 9 Fawcett in view of Waters teaches Claim 8, and further teaches wherein the performing the 2FA for the user terminal includes skipping the 2FA when the user terminal is connected to the closed network. (FIG. 2, IED 20, ¶0044, performing a multi-factor authentication, i.e. at least 2 factor, authentication wen the terminal is connected to an external network, See 112(b), examiner interprets skipping as skipping any further 2FA)
Claim 21 Fawcett in view of Waters teaches Claim 20, and further teaches wherein the chatbot service system determines whether a user terminal connected to the chatbot service is connected to the closed network. (Fawcett, FIG. 1, ¶0046, wherein the primary system and chatbot server system are connected to a closed network, Examiner notes that network 100 does not connect to the internet and only connect between the app, chatbot, and primary system; Examiner also interprets the chatbot system as being a firewall, i.e. a security wall, between the legacy, i.e. primary system, and the rest of the closed network)
However, Fawcett in view of Waters does not explicitly teach performs 2-factor authentication (2FA) for the user terminal when the user terminal is not connected to the external network.
From a related technology, Gordon teaches performs 2-factor authentication (2FA) for the user terminal (FIG. 2, IED 20, ¶0044, performing a multi-factor authentication, i.e. at least 2 factor) when the user terminal is not connected to the external network. (Examiner notes that the limitation is not trigger, and therefore as Gordon perform 2FA regardless of the terminal’s connection to an external network and even if it is not connected)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Fawcett in view of Waters in order to more effectively control system access to desired users and therefore efficiently utilize network resources.
4. Claim 14-16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Fawcett et al. (US 20190199657 A1) in view of Waters et al. (US 20230093882 A1) and in further view of D'Amico et al. (US 20220335567 A1)
Claim 14 Fawcett in view of Waters teaches Claim 11, and further teaches a system providing the chatbot service is pre-registered as an API call-enabled system. (Fawcett, ¶0048, wherein the chatbot service is pre-registered, i.e., already configured, as an API system)
However, Fawcett in view of Waters does not explicitly teach wherein the card generation interface includes an application programming interface (API) selection area, among one or more APIs pre-registered with respect to the first legacy system, one or more APIs pre-registered with respect to the first legacy system is provided by the first legacy system.
From a related technology, D’Amico teaches a card generation interface includes an application programming interface (API) selection area, among one or more APIs pre-registered with respect to the first legacy system, one or more APIs pre-registered with respect to the first legacy system is provided by the first legacy system.
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Fawcett in view of Waters to incorporate the interfaces taught by D’amico in order to more effective utilize network resources for desired results.
Claim 15 Fawcett in view of Waters teaches Claim 14, and further teaches wherein the providing the card generation interface for registering the card type chatbot interface to the user terminal includes displaying a generation interface of an execution result binding card. (Fawcett, FIG. 3A, step 304, ¶0064, transmitting a chat message to the mobile device, the message comprising a card generation interface)
However, Fawcett in view of Waters does not explicitly teach an interface for registering the card type chatbot interface generated as the chatbot message of the execution result when an API of an execution result binding type is selected through the API selection area.
From a related technology, D.Amico teaches an interface for registering the card type when an API of an execution result binding type is selected through the API selection area. (¶0042, a screen capture engine, i.e. interface for receiving variables of a capture screen for execution results for when that capture type has been selected)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Fawcett in view of Waters to incorporate the interfaces taught by D’amico in order to more effective utilize network resources for desired results.
Claim 16 Fawcett in view of Waters teaches Claim 14, and further teaches wherein the providing the card generation interface for registering the card type chatbot interface to the user terminal includes displaying an interface. (Fawcett, FIG. 3A, step 304, ¶0064, transmitting a chat message to the mobile device, the message comprising a card generation interface)
However, Fawcett in view of Waters does not explicitly teach an interface for receiving one or more variables for defining a capture screen for the execution result when an API of a capture type is selected through the API selection area.
From a related technology, D.Amico teaches an interface for receiving one or more variables for defining a capture screen for the execution result when an API of a capture type is selected through the API selection area. (¶0042, a screen capture engine, i.e. interface for receiving variables of a capture screen for execution results for when that capture type has been selected)
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Fawcett in view of Waters to incorporate the interfaces taught by D’amico in order to more effective utilize network resources for desired results.
Claim 18 Fawcett in view of Waters teaches Claim 14, and further teaches wherein the card generation interface for registering the card type chatbot interface includes an execution result type selection area (Fawcett, FIG. 3A, step 304, ¶0064, transmitting a chat message to the mobile device, the message comprising a card generation interface, wherein the execution result type selection can be either later, now or office) for designating a type indicating the execution result of the API selected through the API selection area. (Fawcett, ¶0064, later, now, or office, comprises a type of execution result)
However, Fawcett does not explicitly teach one of an execution result binding type, a capture type and an execution result download type, the execution result binding type is a type in which an execution result binding card to which a return value of the selected API is bound is generated as the chatbot message of the execution result, the capture type is a type in which a capture screen of an execution result screen of the selected API on the first legacy system is generated as the chatbot message of the execution result, and the execution result download type is a type in which a button capable of downloading a file in which data generated as an execution result of the selected API is written is included in the chatbot message of the execution result.
From a related technology, D’amico teaches one of an execution result binding type, a capture type and an execution result download type, (Examiner notes that only “one of” the “one of..” types needs to be taught to teach the claims) the execution result binding type is a type in which an execution result binding card to which a return value of the selected API is bound is generated as the message of the execution result, the capture type is a type in which a capture screen of an execution result screen of the selected API on the first legacy system is generated as the message of the execution result, (D’amico, ¶0042, wherein the capture type is a screen capture type of execution result that is generated) and the execution result download type is a type in which a button capable of downloading a file in which data generated as an execution result of the selected API is written is included in the message of the execution result.
It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Fawcett in view of Waters to incorporate the interfaces taught by D’amico in order to more effective utilize network resources for desired results.
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 CHRISTOPHER PALACA CADORNA whose telephone number is (571)270-0584. The examiner can normally be reached M-F 10:00-7:00.
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, John Follansbee can be reached at (571) 272-3964. 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.
/CHRISTOPHER P CADORNA/Examiner, Art Unit 2444
/JOHN A FOLLANSBEE/Supervisory Patent Examiner, Art Unit 2444
Prosecution Insights