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 5/4/2026 have been fully considered, along with the extensive claim amendments made to the independent claims. These claim amendments have required review of both these amended claims, along with a review of their dependents. The presented claims are replete with grammatical issues and clarity issues, as discussed below. These have necessitated a combination of updated and newly presented rejections made under 35 USC 112.
Regarding the response to the previously presented prior art rejections, Applicant’s arguments have been considered. However, the features they rely on (e.g., the claimed “validation inspection”, argued on page 10 of the response and recited in both pending independent claims) are claimed in a manner that prevents the formulation of a clear and definite interpretation of the claims and their intended scope.
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, lines 4 – 7 of page 2 of said claim recite:
“a memory operatively connected to the processor and configured to store a reception application which is able to receive a data packet using the communication circuit through a designated service port, and an access control
application, and wherein the memory stores instructions that, when executed by the processor, cause the node to:”.
It is unclear what relationship is intended to be specified by the recitation of “and an access control application” given Applicant’s choice of punctuation, line spacing, and grammatical choices. For example, it is unclear if the claimed “memory” stores each of the “reception application”, the “access control application” and additional distinct “instructions [that] cause the node to”, or whether the memory stores a “reception application” that is recited as “able to receive a data packet” through both a “service port” and “an access control application”, or potentially whether the “access control application” is intended to further limit or otherwise specify a different arrangement, such as further limiting what the “processor” of line 3 on page 2 is “operatively connected to”. These clarity issues render the resultant language unclear and indefinite, and thus the claim as a whole unclear and indefinite. Claim 1 additionally recites on lines 10 – 13:
“whether a data flow, which corresponds to identification information of the reception application, a requested service port, and the source network and is authorized from an external server, exists in the event of network reception”. It is unclear what the concluding language “exists in the event of network reception” is intended to further specify. The choices include:
the data flow,
the reception application,
a requested service port,
the source network,
an external server, and
the event of network reception.The Examiner notes that additional interpretations are also possible.
The open-ended, ambiguous, and ungrammatical nature of the claim language renders it unclear and indefinite. Claim 1 also recites on line 11 “a requested service port”. No antecedent basis has been established for a “requested service port” or a “request”. The Examiner notes that a “network reception” is recited in line 8, e.g., but the fact that “network reception” event occurs does not require a request be received as part of the reception; a “reception” event can occur that is not part of a request. Thus it is unclear how this “service port” and the implicit request further limits claim 1, and to what parts of claim 1 the implicit “request” is applicable. Claim 1 recites “an external server” on line 12. That this server is “external” requires a clear specification as to what the server is “external” to. However, claim 1 provides no clear association or recitation that enables determining such an association or correspondence. Claim 1 continues on pages 14 – 16 to recite: “determine, through the access control application, whether the reception
application may receive the data packet using the communication circuit and the requested service port by determining whether the requested service port is the designated service port;”
It is unclear if the “by determining” language is intended to further specify steps performed by the “access control application” or whether the “by determining” language is performed by the “reception application”. In addition, the above language recites a determination regarding “whether the reception application may receive the data packet”. However, lines 4 – 5 on page 2 recite “a reception application which is able to receive a data packet”. Thus antecedent basis is previously provided for a reception application that is “able to” receive a packet. This recitation then further specifies a determination as to whether the application “may receive the data packet”. The intended scope of these two clauses is rendered unclear and indefinite to the ambiguous relationship between an application that is “able to” perform an action and an application that “may” perform an action. One of ordinary skill in the art would view the scope of an application that is “able to” perform an action and an application that “may” perform an action as two recitations that are redundant and overlap. That is, if an application “may” do an action it is implicitly “able” to do that action, and vice-a-versa. Thus it is unclear what Applicant intends to further specify with this recitation in lines 14 – 15, and how the “determine” step could actually have any useful outcome given the requirement regarding what the application is “able to” established on lines 4 – 5. Claim 1 additionally recites on lines 18 – 20: “a validation inspection policy, the validation inspection including at least one of an inspection of whether the reception application is forged or altered, a code signing inspection, and a fingerprint inspection”. The overall scope of this recited language is unclear and indefinite. The “validation inspection” appears to be claimed as potentially including an “inspection of” a “code signing inspection” and an “fingerprint inspection”, which implies inspections of inspections. Given all of the “inspections” are claimed as being performed by a singular application, it is unclear how inspecting an inspection further specifies an inspection policy given the repetitive and redundant nature of the suggested behavior (an application inspecting its own inspection of an whether an inspection policy is met via inspection of other inspections . . . ?). The language is unclear and indefinite.
Claim 1 has been amended to recite on lines 8, 10, 14, and 17, each on page 2, various “detect”, “determine”, and “receive” steps that are noting as being performed or accomplished “through the access control application”. The scope of what a step performed or accomplished “through” an application is unclear and indefinite, as the degree or involvement of the claimed application with a step such that the step is performed “through” the application is unclear and indefinite. Is the application required to perform the step itself, or would the application providing authorization for performing the step be sufficient for the step to be performed “through” the application? Or, could the application relay or forward an instruction to another device, and then be within the scope of the step being performed “through” the application? The phrasing and claim structure chosen by Applicant has resulted in an unclear and indefinite recitation and claim. Claim 1 concludes on page 2 with a reference to “the authorized data flow”. There is a lack of antecedent basis for this language, rendering the recitation unclear and indefinite. Further regarding claim 1, line 3 on page 3 recites a “drop” operation performed when “the authorized data flow information does not exist”. There is no antecedent basis for “the authorized data flow information”, rending this recitation indefinite. Regarding claim 2, said claim further references “the authorized data flow”. As noted in the comments made above addressing claim 1, there is no antecedent basis for this language, and thus its additional recitation inherits the issues noted above. Further regarding claim 2, said claim further references “the external server” of claim 1; this recitation fails to clarify the issues with this language noted above in the examination of claim 1, and thus inherits those deficiencies. In addition, claim 2 further references “the validation inspection” of claim 1; this recitation fails to clarify the issues with this language noted above in the examination of claim 1, and thus inherits those deficiencies. Furthermore, claim 2 recites where this inspection “indicates that the reception application is valid”. Claim 1 recites that this inspection policy determines whether the application “satisfies the inspection policy”, which is not the same thing as “indicates that the reception application is valid”. What this language is intended to further limit thus is unclear and indefinite. Further regarding claim 2, the preamble on line 4 concludes with “cause the node to” and then the claim continues to recite “to the external server an indication”. Cause the node to to the external server” is ungrammatical, unclear, and indefinite language.
Regarding claim 3, said claim begins with the recitation of “a controller access”. There is no antecedent basis for “a controller”, and thus what the “access” is related to how this recitation otherwise limits the claim is rendered unclear and indefinite.
Further regarding claim 3, said claim further references “the external server” of claim 1; this recitation fails to clarify the issues with this language noted above in the examination of claim 1, and thus inherits those deficiencies. Claim 3 additionally concludes by reciting “access” to an external server is “block through the display”. The plain English language meaning of this recitation is that a display (e.g., a computer monitor or screen) is preventing access to an external server, which is not a logical or otherwise decipherable description of how one of ordinary skill would interpret the functionality of a computer display. This recitation is unclear and indefinite. Claim 3 concludes on page 3 by further limiting “the request from the external server”. Claim 3 and parent claim 1 each lack antecedent basis for a “request from the external server”. Continuing on page 3, said claim recites “being including”; unclear language which appears to be a typographical error.
Regarding claims 4 – 7, said claims contain numerous references to language noted as deficient in claim 1. These claims fail to clarify these issues, and thus inherit the decencies of their parent claim. Regarding claim 8, said claim recites on lines 6 – 9 of page 5:
“receive, from a first access control application of a source node, a first request
requesting a network access with respect to a destination node, the first request including identification information of a control flow, identification information of a target application stored in the source node, and identification information of the destination node;” As an initial matter, it is unclear what “a” in “a network access” (on line 7) is intended to specify. It appears to be an unnecessary, as a standard English language recitation would normally correspond to “request network access”. Additionally, the recitation of “the first request including . . . identification information of a target application stored in the source node”. It is unclear if this language is intended to specify that the “identification information” is “stored in the source node”, the “target application” is “stored in the source node”, or both of the identification information and the application are “stored in the source node”. Claim 8 continues on line 12 to recite “when the target application is accessible and based on the database,”. It is unclear whether this language is in tended to specify a determination regarding both the target application’s accessibility and the target application’s nature or existence being somehow “based the database”, or alternatively a determination of whether the target application is accessible, and then performing a subsequent step “based on the database”. The Examiner notes that the ungrammatical language may have additional intended interpretations. Regardless, the phrasing and sentence structure chosen by the Applicant has rendered the resultant language (along with the claim as a whole) unclear and indefinite. Claim 8 next recites on lines 12 – 17:
“when the target application is accessible and based on the database, determine
whether there exists a data flow including identification information of the source node, the identification information of the destination node, identification information of a reception application stored in the destination node and able to receive a data packet using the communication circuit through a designated service port, and a requested service port for transmitting the data packet to the reception application”
The recitation on line 13 discussing a determination of “whether there exists” is unclear and indefinite. For example, it is unclear whether the “there exists” determination is checking for “a data flow”, particular “identification information of the destination node”, “identification information of a reception application”, etc., or whether the “there exists” language is checking for the “a data flow” that includes “identification of the source node” and that also includes “identification of a reception application”, etc. The Examiner further notes that ungrammatical, ambiguous nature of the recitation suggests other potential interpretations being possible. The recitation on lines 15 – 16 of: “stored in the destination node and able to receive a data packet using the
communication circuit through a designated service port”
is also unclear and indefinite. It is unclear if the “and able to” language descriptive material describing an intended use or result of operation of the, e.g., “destination node” or whether this “and able to” is discussing the characteristics of the “application stored”, or some other interpretation such as a further note regarding the intended use or functionality of the “target application” of line 12. Claim 8 continues on lines 16 – 17 to recite “and a requested service port for transmitting the data packet to the reception application”. This disconnected, ungrammatical recitation has no clear connection to the preceding claim language. It could potentially be an attempt to further limit a characteristic of the accessibility determination of line 12, or potentially a further limitation specifying the reception of a data packet discussed on line 15. It could also potentially be further limiting the “server” to which claim 8 is directed, and thus be a recitation that the server has the “service port for transmitting”. The lack of clarity and the ungrammatical nature of the language chosen in claim 8 is unclear and indefinite. Claim 8 next further limits the “a data flow” introduced on line 13. This recitation fails to clarify the issues regarding this “a data flow” noted above, and thus inherits the issues noted above. Further regarding claim 8, on page 5 said claim recites on: line 6 “receive, from a first access”, line 10 “determine whether”,
line 12 “when the target application”, and line 19 “when the data flow”. Page 6 of claim 8 continues to recite on:
line 1 “to perform”, line 3 “wherein, when”,
line 12 “when the destination node”, and
line 16 “transmit an inaccessible result”. Each of these lines are indented in a manner that indicates they are further limiting the recitation of on page 5, line 5 “wherein the processor is configured to:” This results in the effective recitations on page 6 of “wherein the processor is configured to to perform” and “wherein the processor is configured to, wherein, when . . .”. These recitations are unclear, ungrammatical English and as a result render the recited language unclear and indefinite.
Claim 8 additional recites claim language on page 6 analogous to the language addressed in the above analysis of claim 1 (e.g., the discussion of the “validation” at the start of page 6). These recitations in claim 8 thus contain the same issues present in the analogous recitations in claim 1. The recitations in claim 8 and unclear and indefinite for the reasons given when addressing the language in claim 1. Claim 8 additional recites behavior of a “destination node” on lines 5 – 12 on page 6. It is unclear and indefinite how this behavior of the “destination node” is intended to further limit the ”server” to which claim 8 is directed.
Regarding claims 9 – 15, said claims contain numerous references to language noted as deficient in claim 8. These claims fail to clarify these issues, and thus inherit the decencies of their parent claim.
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 (which is able to receive a data packet using the communication circuit through a designated service port; this language is interpreted as non-functional descriptive material corresponding to an intended use/result, and thus not accorded patentable weight) 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, through the access control application, an event of a network transmission to a target network (pg. 3 lines 37-42, pg. 5 lines 13-20); determine, through the access control application, whether a data flow, which corresponds to identification information of the target application, a requested service port, and the target network (pg. 1 lines 1-5, pg. 7 lines 62-67) and is authorized from an external server exists in the event of network communication (pg. 3 lines 37-50); determine, through the access control application, whether the target application may send the data packet using the communication circuit and the requested service port by determining whether the requested service port is the designated service port (pg. 3 lines 32-60, pg. 5 lines 13-32); perform, through the access control application, a validation inspection of the target application to determine whether the target application satisfies a validation inspection policy, the validation inspection including at least one of an inspection of whether the reception application is forged or altered, a code signing inspection, and a fingerprint inspection (pg. 8 lines 34-40) send a data packet using the communication circuit and the requested service port when the authorized data flow exists and the target application is attempting to send the data packet, the requested service port is the designated service port (pg. 3 lines 51-54, pg. 5 lines 20-25), and the target application satisfies the validation inspection policy (pg. 2 lines 3 – 10, pg. 8 lines 34-40); and drop the data packet when the authorized data flow information does not exist, the target application is not attempting to send, or the requested service port is not the designated service port (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, when the authorized data flow exists, the reception application is attempting to receive the data packet, the requested service port is the designated service port, and the validation inspection indicates that the reception application is valid, the instructions cause the node to: transmit to the external server an indication that the reception application is able to receive the data packet (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); when the target application is accessible and based on the database, determine whether there exists a data flow including identification information of the source node, the identification information of the destination node, identification information of a reception application stored in the destination node and able to receive a data packet using the communication circuit through a designated service port, and a requested service port for transmitting the data packet to the reception application (pg. 5 line 64 – pg. 6 line 4, pg. 8 lines 25-39 and 46-49); when the data flow does not exist, request the destination node to determine whether the reception application and the destination node are able to receive the data (pg. 8 lines 28-40 and 51-53), and
perform a validation inspection of the reception application to determine whether the reception application satisfies a validation inspection policy, the validation inspection including at least one of an inspection of whether the reception application is forged or altered, a code signing inspection, and a fingerprint inspection (pg. 8 lines 34-40), wherein, when the requested service port is the designated service port for the reception application and the reception application satisfies the validation inspection policy, the destination node determines that the reception application and destination node are able to receive, and wherein when the requested service port is not the designated service port for the reception application or the reception application does not satisfy the validation inspection policy, the destination node determines that the reception application and destination node are unable to receive (pg. 2 lines 3-10, pg. 3 lines 51-54, pg. 5 lines 20-25)
when the destination node and the reception application are able to receive, generate the data flow and transfer the data flow including the data packet generated using the communication circuit to the destination node through the designated service port (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). 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
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 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
Prosecution Insights