Prosecution Insights
Last updated: April 19, 2026
Application No. 18/559,519

SYSTEM FOR CONTROLLING NETWORK CONNECTION BASED ON CONTROLLER, AND METHOD FOR SAME

Non-Final OA §103§112
Filed
Nov 07, 2023
Examiner
MACILWINEN, JOHN MOORE JAIN
Art Unit
2454
Tech Center
2400 — Computer Networks
Assignee
Pribit Technology Inc.
OA Round
3 (Non-Final)
68%
Grant Probability
Favorable
3-4
OA Rounds
3y 9m
To Grant
95%
With Interview

Examiner Intelligence

Grants 68% — above average
68%
Career Allow Rate
457 granted / 676 resolved
+9.6% vs TC avg
Strong +28% interview lift
Without
With
+27.6%
Interview Lift
resolved cases with interview
Typical timeline
3y 9m
Avg Prosecution
33 currently pending
Career history
709
Total Applications
across all art units

Statute-Specific Performance

§101
8.7%
-31.3% vs TC avg
§103
53.0%
+13.0% vs TC avg
§102
11.6%
-28.4% vs TC avg
§112
18.8%
-21.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 676 resolved cases

Office Action

§103 §112
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 . DETAILED ACTION Response to Arguments Applicant's arguments filed 1/7/2026 have been fully considered and are partially persuasive. On page 8, Applicant begins by addressing the “server” recited in claims 8 - 10. Applicant’s arguments appear to be that the “processor is configured to” language of claim 8 is sufficiently clear in scope (when considered with the “circuit” and “memory” recited in claim 8). The Examiner agrees and notes that the prior Office Action (the 9/23/2025 Final Rejection) contained no objections or rejections regarding this claim language. Similarly, the present Office Action raises no issues with this language. Applicant continues on pages 9 – 10 to restate arguments related to the KR 102 prior art. These arguments were addressed in the above noted previously mailed Office Action. Continuing through page 11, Applicant addresses the rejections made under 35 USC 103 utilizing the combination of KR102 in view of Todd. On page 11, Applicant argues that KR102 “actually teaches a ‘target application’ that is the opposite of a ‘reception application’ as recited in claim 1”. In response, the Examiner notes that the claims have been treated as such, and if a more precise interpretation is desired for the claimed “target application”, the claims should be amended to positively recite the features or limitations Applicant desires be read into the claim (keeping in mind that any such amendments must be fully supported by the originally filed specification). Applicant’s arguments on pages 12 – 13 continue and are directed to Todd. These arguments appear to apply to Todd being cited to show where “the target application is a reception application”. Applicant argues, e.g., that “Todd also does not provide details regarding how Todd’s networks security device actually process incoming communications . . .”. However, absent corresponding claim limitations that require some particular specific processing occur (and with Todd cited for showing said limitations), said arguments cannot be held as persuasive. The same is true regarding Applicant’s argument that “The Office Action does not establish that any data flow in Todd contains any information about a reception application”; Todd was not relied upon for teaching where a data flow “contains any information about a reception application” and thus arguments reliant on Todd showing such language cannot be held as persuasive. The Examiner notes that claims 1 and 8 have been amended to recite additional details regarding, e.g., the “designated service port” of a request. New rejections have been made responsive to these claim amendments, and they are presented below. 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. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claims 1 – 15 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Regarding claim 1, said claim has been amended to recite “determine whether the reception application is possible”. Whether an “application is possible” is ungrammatical, non-standard English and results in an indefinite claim. Further regarding claim 1, said claim further limits the above indefinite language, reciting to: “determine whether the reception application is possible based on the received reception application information” (emphasis added). The claim lacks antecedent basis for “the received reception application information” and thus it is unclear if this language is meant to further limit some other previously recited feature related to “the reception application” or instead introduce a new limitation. This language thus further exacerbates the indefinite nature of claim 1. Regarding claims 2 – 7, said claims depend on claim 1 and fail to clarify the issues addressed above. Regarding claim 8, said claim recites, on page 5 lines 7 – 9: “generate the data flow . . . when the destination node and the reception application are able to receive” Claim 8 has now been amended to recite, on page 5 lines 12 – 13: “generate the data flow when the reception application is capable of receiving data packets . . .”. The newly amened language on lines 12 - 13 appears to repeat the features recited on lines 7 – 9, and thus it is unclear if another data flow is being generated or instead if the claim is further describing the generation of the data flow previously establish in lines 7 – 9. Regarding claims 9 – 15, said claims depend on claim 1 and fail to clarify the issues addressed above. In order to perform a complete examination, the above language has been interpreted broadly. 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. Claim 1 – 5 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over KR102 (English translation of KR102119257B1. (Year: 2020)) in view of Todd (US-7890612-B2) and Wei (Wei, D. and Chen, G. English translation of CN_102123158_A_I. (Year: 2011)). Regarding claim 1, KR102 shows a source node comprising: a communication circuit (pg.3 lines 35-42 and 54-61, pg. 5 lines 33-36, pg. 6 lines 5-19); a processor operatively connected to the communication circuit (pg.3 lines 35-42 and 54-61, pg. 5 lines 33-36, pg. 6 lines 5-19); and a memory operatively connected to the processor and configured to store a target application and an access control application (pg.3 lines 35-42 and 54-61, pg. 5 lines 33-36, pg. 6 lines 5-19, discussing a “connection control application” operating in conjunction with a “target application” on a “terminal”), and wherein the memory stores instructions that, when executed by the processor, cause the node to: detect an event of a network transmission to a target network through the access control application (pg. 3 lines 37-42, pg. 5 lines 13-20); determine whether a data flow, which corresponds to identification information of the target application, a service port, and the target network (pg. 1 lines 1-5, pg. 7 lines 62-67) and is authorized from an external server exists, through the access control application (pg. 3 lines 37-50); send a data packet using the communication circuit, when the authorized data flow exists and the target application is attempting to send (pg. 3 lines 51-54, pg. 5 lines 20-25); and drop the data packet when the authorized data flow information does not exist or the target application is not attempting to send (pg. 3 lines 51-54, pg. 5 lines 20-25); determine whether the reception application is possible (pg. 5 lines 26-30) based on the received reception application information (pg. 5 lines 26-30 and lines 38-41) and a service port information (pg. 7 lines 65-67) when a request (pg. 5 lines 38-39) from the controller to identify (pg. 5 lines 27-31 and lines 38-41) whether the reception application may receive the data packet is received (pg. 5 lines 16-18, 27-31, and 38-41). KR102 does not show where: the source node is a destination node; the target application is a reception application; the event is a network reception from source network; and where the data packet is sent. Todd shows where: the source node is a destination node (col. 10 lines 2 – 8, col. 14 lines 26-34); the target application is a reception application (col. 10 lines 58-64); the event is a network reception from source network (col. 8 lines 26-37, suggesting data packet control application performed “in both directions” and “no matter where [the data] originates”); and where the data packet is sent (col. 8 lines 26-37, col. 14 lines 26 - 34). It would have been obvious of ordinary skill in the art before the effective filing date of the invention to modify the data authorization and control mechanisms of KR102 (which are applied when sending data) with the data protections provided for both sending and receiving data suggested by Todd (and thus implement the authorization and control techniques of KR102 on both the sending and reception ends of a transmission, as suggested by Todd) in order to better protect endpoints performing network communication, as inbound data, e.g., is a well-known vector for virus transmissions (Todd, col. 4 lines 3 – 31). The above combination does not address request reception through a designated service port. Wei shows request reception through a designated service port (pg. 1 lines 29-42). It would have been obvious of ordinary skill in the art before the effective filing date of the invention to modify the data authorization and control mechanisms of KR102 in view of Todd with the request handling of Wei in order to ensure unified handling of requests with improved efficiency and consistency (Wei, pg. 1 lines 38-42). Regarding claim 2, the above combination further shows wherein the instructions cause the node to: determine whether a reception is possible when a request is received from the external server to identify whether the reception application is receivable (KR102, pg. 3 lines 43-50, pg. 5 lines 27-32, pg. 5 lines 35-58 and Todd, col. 14 lines 26-34); perform a validation inspection of the reception application and transmit a result of the validation inspection to the external server when the reception application is receivable (KR102, pg. 7 lines 7-12). Regarding claim 3, the above combination further shows a display, and wherein the instructions cause the node to: detect an event of a controller access with respect to the external server through the access control application (KR102, pg. 3 lines 36-42, pg. 5 lines 37-41, pg. 6 lines 47-49 and 58-64; Todd, col. 8 lines 26-37, col. 14 lines 26 - 34); request controller access to the external server using the communication circuit in response to the detected event of the controller access (KR102, pg. 3 lines 36-44, pg. 5 lines 37-41, pg. 6 lines 47-49 and 58-64; Todd, col. 8 lines 26-37, col. 14 lines 26 - 34); receive a first response with respect to the request from the external server (KR102, pg. 3 lines 36-42, pg. 5 lines 37-41, pg. 6 lines 47-49 and 58-64); the first response being including identification information of a generated control flow (KR102, pg. 3 lines 50-54, pg. 5 lines 42-45, pg. 7 lines 18-19), and output a user interface screen indicating that access with respect to the external server is completed or indicating that access with respect to the external server is blocked through the display, based on the first response (KR102, pg. 7 lines 20-24; Todd, col. 8 lines 26-37, col. 14 lines 26 - 34). Regarding claim 4, the above combination further shows wherein the instructions cause the node to: receive a first user input requesting a user authentication (KR102, pg. 6 line 64 – pg. 7 line 6, pg. 7 lines 34-38); request a user authentication with respect to a user of the node to the external server (KR102, pg. 6 line 64 – pg. 7 line 6, pg. 7 lines 34-38), and the request of the user authentication being including information corresponding to the first user input (KR102, pg. 7 lines 36-45); receive a second response with respect to the user authentication request from the external server (KR102, pg. 6 line 66 – pg. 7 line 3); and output a user interface screen indicating that the user authentication is completed or indicating that the user authentication fails through the display, based on the second response (pg. 7 lines 42-56). Regarding claim 5, the above combination further shows wherein the instructions cause the node to: receive a second user input requesting a release of a network access (KR102, pg. 9 lines 11-30); and request the external server to release the network access in response to the second user input (KR102, pg. 9 lines 11-30). Regarding claim 7, the above combination further shows wherein the instructions cause the node to: receive information indicating a deletion of the authorized data flow from the external server (KR102, pg. 9 lines 11-30); and update the authorized data flow from the external server based on the deletion information with respect to the authorized data flow (KR102, pg. 9 lines 11-30). Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over KR102 in view of Todd and Wei, further in view of Bhattacharjee (WO-9953718-A1). Regarding claim 6, KR102 in view of Todd and Wei shows to detect an update event of a control flow generated between the node and the external server (KR102, pg. 5 lines 13-20 and lines 53-62) The above combination does not show request an update of the control flow to the external server using the communication circuit in response to the detected event; and receive a third response with respect to the update request of the control flow from the external server, and wherein the third response includes information on the data flow. Bhattacharjee shows request an update of the control flow to the external server using the communication circuit in response to the detected event (pgs. 24-25); and receive a third response with respect to the update request of the control flow from the external server (pgs. 24-25), and wherein the third response includes information on the data flow (pgs. 24-25). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify to modify the network and communication management techniques of the above combination with the flow information tracking of Bhattacharjee in order to ensure network activity data is reliably tracked and maintained, enabling better management decision making and thus a more reliable, well-managed network. Claim 8 – 10 are rejected under 35 U.S.C. 103 as being unpatentable over KR102 in view of Wei. Regarding claim 8, KR102 shows server comprising: a communication circuit (pg.3 lines 35-44 and 54-61, pg. 5 lines 33-36, pg. 6 lines 5-19); a memory storing a database (pg.3 lines 35-44 and 54-61, pg. 5 lines 33-36, pg. 6 lines 5-19); and a processor operatively connected to the communication circuit and the memory (pg.3 lines 35-44 and 54-61, pg. 5 lines 33-36, pg. 6 lines 5-19), and wherein the processor is configured to: receive, from a first access control application of a source node, a first request requesting a network access with respect to a destination node (pg. 3 lines 42-46, pg. 6 lines 46-48 and 58-61, pg. 8 lines 44-46), the first request including identification information of a control flow (pg. 3 lines 36-37), identification information of a target application stored in the source node (pg. 3 lines 45-47, pg. 7 lines 62-67), and identification information of the destination node (pg. 3 line 46, pg. 7 lines 62-67); determine whether the target application is accessible based on the identification information of the control flow and the database (pg. 3 lines 36-44, pg. 5 lines 38-42, pg. 7 lines 62-67); determine whether a data flow including identification information of the source node, the identification information of the destination node, and identification information of a reception application stored in the destination node exists based on the database, when the target application is accessible (pg. 5 line 64 – pg. 6 line 4, pg. 8 lines 25-39 and 46-49); request the destination node to determine whether the reception application and the destination node are able to receive, when the data flow does not exist (pg. 8 lines 28-40 and 51-53); generate the data flow and transfer the data flow generated using the communication circuit to the destination node when the destination node and the reception application are able to receive (pg. 8 lines 6-11, 21-25, and 56-61); and transmit an inaccessible result to the source node using the communication circuit when the destination node or the reception application is unable to receive (pg. 7 lines 20-27 and pg. 8 lines 62-67), and generate the data flow when the reception application is capable of receiving data packets (pg. 8 lines 6-11, 21-25, and 56-61). KR102 does not address request reception through a designated service port. Wei shows request reception through a designated service port (pg. 1 lines 29-42). It would have been obvious of ordinary skill in the art before the effective filing date of the invention to modify the data authorization and control mechanisms of KR102 in view of Todd with the request handling of Wei in order to ensure unified handling of requests with improved efficiency and consistency (Wei, pg. 1 lines 38-42). Regarding claim 9, the above combination further shows wherein the processor is configured to: determine whether an authorized tunnel exists between the target application and a gateway of the destination node, based on the database, the identification information of the target application, and the identification information of the destination node when the data flow exists or the data flow is generated (KR102, pg. 8 lines 1-11); and transmit the determined result to the first access control application using the communication circuit (KR102, pg. 8 lines 12-24). Regarding claim 10, the above combination further shows wherein the processor is configured to: transmit identification information of the authorized tunnel using the communication circuit when the authorized tunnel exists (KR102, pg. 8 lines 6-10); generate information necessary to generate a tunnel, update the data flow, transmit the information necessary to generate the tunnel to the gateway, and transmit the updated data flow to the first access control application, when the authorized tunnel does not exist (KR102, pg. 8 lines 6-32); and transmit information indicating that a network access with respect to the destination node of the target application is impossible when there is no tunnel that satisfies a policy included in the database (KR102, pg. 8 lines 1-20). Claims 11 - 14 are rejected under 35 U.S.C. 103 as being unpatentable over KR102 in view of Wei, further in view of Sengupta (US-20180131675-A1). Regarding claim 11, KR102 in view of Wei shows wherein the processor is configured to: receive a second request requesting a controller access with respect to the server from the access control application of a node, the second request including identification information of at least one of the node, the access control application, or a network to which the node belongs (pg. 7 lines 3-6); determine whether the node is an accessible device based on the identification information included in the second request and the database (pg. 7 lines 7-12); generate the control flow when the node is the accessible device (pg. 7 lines 7-12); and transmit the identification information of the generated control flow to the node using the communication circuit (pg. 7 lines 12-14), and wherein the server includes the source node and the destination node (pg. 7 lines 18-23). The above combination does not show where the access control application includes the first access control application of the source node and a second access control application of the destination node. Sengupta shows where the access control application includes the first access control application of the source node and a second access control application of the destination node (Abstract). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network control techniques of the above combination with those of Sengupta in order to further improve network security and management while enabling more granular decision making (Sengupta, [3]). Regarding claim 12, the above combination further shows wherein the processor is configured to: receive a third request requesting a user authentication with respect to a user of the node from the access control application through the control flow, the third request including user identification information related to the user authentication (KR102, pg. 8 lines 53-61, pg. 6 line 64-pg. 7 line 2, pg. 7 lines 34-41); authenticate the user of the node based on information included in the third request and the database (KR102, pg. pg. 6 lines 64-67); and transmit a result of the user authentication to the access control application through the control flow using the communication circuit (KR102, pg. 7 lines 49-52). Regarding claim 13, the above combination further shows wherein the processor is configured to: receive, from the first access control application, a fourth request requesting a release of the network access (KR102, pg. 9 lines 11-16); remove the control flow in response to the fourth request (KR102, pg. 9 lines 22-30); release and update the data flow dependent on the control flow (KR102, pg. 9 lines 22-30); and request the gateway to remove a tunnel dependent on the control flow and transmit the updated data flow to the destination node, using the communication circuit (KR102, pg. 9 lines 22-30). Regarding claim 14, the above combination further shows wherein the processor is configured to: receive, from the second access control application, a fifth request requesting a release of the network access (KR102, pg. 9 lines 11-30); remove the control flow in response to the fifth request (KR102, pg. 9 lines 11-30); and release the data flow dependent on the control flow (KR102, pg. 9 lines 11-30). Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over KR102 in view of Wei and Sengupta as applied to claim 11 above, further in view of Bhattacharjee. Regarding claim 15, the above combination shows wherein the processor is configured to: receive a sixth request requesting update of the control flow from the node, the sixth request being including identification information of the control flow (KR102, pg. 5 lines 13-20 and lines 53-62); The above combination does not show to: update the control flow based on identification information included in the sixth request and the database; update the data flow information; and transmit the updated information to the node. Bhattacharjee shows to: update the control flow based on identification information included in the sixth request and the database (pgs. 24-25); update the data flow information (pgs. 24-25); and transmit the updated information to the node (pgs. 24-25). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify to modify the network and communication management techniques of the above combination with the flow information tracking of Bhattacharjee in order to ensure network activity data is reliably tracked and maintained, enabling better management decision making and thus a more reliable, well-managed network. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - Friday, 9:00 - 5: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, Glenton B Burgess can be reached at (571) 272 - 3949. 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. JOHN MACILWINEN Primary Examiner Art Unit 2442 /JOHN M MACILWINEN/ Primary Examiner, Art Unit 2454
Read full office action

Prosecution Timeline

Nov 07, 2023
Application Filed
May 27, 2025
Non-Final Rejection — §103, §112
Aug 29, 2025
Response Filed
Sep 19, 2025
Final Rejection — §103, §112
Dec 23, 2025
Response after Non-Final Action
Jan 07, 2026
Request for Continued Examination
Jan 25, 2026
Response after Non-Final Action
Feb 02, 2026
Non-Final Rejection — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12603840
Secure Virtual Private Mobile and IP Network in Cloud
2y 5m to grant Granted Apr 14, 2026
Patent 12598183
CREATING GRAPHICAL MODELS OF NETWORK SECURITY POLICIES AND DISPLAYING ON A NETWORK TOPOLOGY GRAPH
2y 5m to grant Granted Apr 07, 2026
Patent 12596851
INFORMATION PROCESSING DEVICE
2y 5m to grant Granted Apr 07, 2026
Patent 12587578
SYSTEMS AND METHODS FOR PROVIDING REAL-TIME STREAMING DATA PROCESSING AT EDGE SERVERS
2y 5m to grant Granted Mar 24, 2026
Patent 12580882
ELECTRONIC MESSAGING COMMUNICATION DELIVERY METHOD
2y 5m to grant Granted Mar 17, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
68%
Grant Probability
95%
With Interview (+27.6%)
3y 9m
Median Time to Grant
High
PTA Risk
Based on 676 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month