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
Claims 1-20 are presented for examination.
Notice for all Patent Application as subject to AIA
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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3-8, and 20 are rejected under AIA 35 U.S.C. 103 as being un-patentable over Wang et al (U.S. Patent Application Publication No. 2014/0169337 A1) in view of Schwebke et al (U.S. Patent Application Publication No. 2014/0196117 A1).
As to claim 1, Wang et al disclose a node, comprising: a communication circuit; a processor operatively connected to the communication circuit; and a memory operatively connected to the processor and configured to store a target application and an access control application (figure 1, pars. 0005 & 0028, figure 3, pars. 0042-0045, user terminal having communication element, processor, and memory including an access control program), wherein the memory stores instructions causing, when executed by the processor, the node to: determine a communication protocol based on whether an access to an operating system transport layer through the access control application is possible; and perform a control data processing request based on an authentication information of the node (pars. 0014-0017, figures 4-5, pars. 0052-0057, selecting a communication protocol to support determined operating system and communication network standard).
However, Wang et al disclose do not teach the steps of: transmit an authentication data packet including first authentication information to an external server based on the determined communication protocol and request authentication;
receive an authentication result of the authentication data packet from the external
server; and set an authentication state of a control data packet based on the received
authentication result and perform a control data processing request for the external server based on the authentication state.
Schwebke et al teach the steps of: transmit an authentication data packet including first authentication information to an external server based on the determined communication protocol and request authentication; receive an authentication result of the authentication data packet from the external server; and set an authentication state of a control data packet based on the received authentication result and perform a control data processing request for the external server based on the authentication state (figure 4, par. 0054, figure 5, par. 0055, a CCD sends authentication data to a CSS and process a request for the CSS based on the received authentication result).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Schwebke et al as stated above with the node of Wang et al for sending authentication data to a server and processing a request for the server based on the received authentication result because it would have provided secure communication between client/terminal and server/network and also improved device and data security.
As to claim 3, Schwebke et al teach that detect a control data packet transmission event through the access control application; identify whether there is a need to authenticate the control data packet; when there is a need to authenticate the control data packet, request the authentication; when there is no need to authenticate the control data packet, insert the first authentication information or second authentication information received from the external server into a header of the control data packet and perform a control-related request by transmitting a control data packet into which the first authentication information or the second authentication information is inserted to the external server; and receive a result of the control-related request from the external server (figure 4, par. 0054, figure 5, par. 0055, a CCD sends authentication data to a CSS and process a request for the CSS based on the received authentication result).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Schwebke et al as stated above with the node of Wang et al for sending authentication data to a server and processing a request for the server based on the received authentication result because it would have provided secure communication between client/terminal and server/network and also improved device and data security.
As to claims 4-6, Schwebke et al teach that the control-related request is a controller access request, receive control flow identification information, the second authentication information, a data flow, and channel generation information from the external server through the access control application (pars. 0047-0048, figure 4, par. 0054); a user authentication request, transmit user input information to the external server, when the control-related request is performed, through the access control application; and receive a result of the user authentication request, control flow identification information, the second authentication information, a data flow, and channel generation information from the external server (pars. 0048-0049, figure 5, par. 0055); and a network access request, transmit control flow identification information, destination network identification information of the target application to the external server, when the control-related request is performed, through the access control application; receive a data flow and channel generation information from the external server; and generate a channel with a network node based on the channel generation information (pars. 0047-0048, figure 4, par. 0054);
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Schwebke et al as stated above with the node of Wang et al because it would have provided secure communication between client/terminal and server/network and also improved device and data security.
As to claim 7, Schwebke et al teach that receive channel generation information from the external server through the access control application, wherein the channel generation information includes channel generation authentication information; transmit a channel generation authentication data packet including the channel generation authentication information to a network node based on the determined communication protocol and request channel generation authentication; receive a channel generation authentication result of the channel generation authentication from the network node;
change an authentication state of a channel data packet based on the received channel
generation authentication result; and generate a channel with the network node based on the channel data packet whose authentication state is changed (pars. 0040-0042 & 0047-0049).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Schwebke et al as stated above with the node of Wang et al because it would have provided secure communication between client/terminal and server/network and also improved device and data security.
As to claim 8, Wang et al teach that transmit the channel data packet whose authentication state is changed, to the network node through the access control application and request channel generation; receive a result of the channel generation request from the network node; and transmit a data packet of the target application to a destination network based on the generated channel (figures 3 & 5, pars, 0045-0050, 0057-0062, & 0066, selecting a communication network for transmitting a data packet based on authentication information and a request).
As to claim 20, it is also rejected for the same reasons set forth to rejecting claim 1 above, since claim 20 is merely method of operations for the apparatus defined in the claim 1, also claim 20 does not teach or define any new limitations than above rejected claim 1.
Claim 2 is rejected under AIA 35 U.S.C. 103 as being un-patentable over Wang et al (U.S. Patent Application Publication No. 2014/0169337 A1) in view of Schwebke et al (U.S. Patent Application Publication No. 2014/0196117 A1), as applied to claim 1 above, and further in view of Javanainen (U.S. Patent Application Publication No. 2005/0076206 A1).
As to claim 2, neither Wang et al nor Schwebke et al teaches that the communication protocol includes a TCP protocol and an UDP protocol.
Javanainen teaches that the communication protocol includes a
TCP protocol and an UDP protocol, wherein the instructions cause the node to:
when the access to the operating system transport layer is possible, transmit the
authentication data packet through the access control application, based on a TCP protocol; and when the access to the operating system transport layer is impossible, transmit the authentication data packet through the access control application, based on a UDP protocol (figure 1, pars. 0026, 0028-0029, figure 3, par. 0034, selecting a proper TCP communication protocol to transmit and receive a data packet).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Javanainen as stated above with the server of Schwebke et al for identifying a communication protocol to transmit and receive a data packet because it would have improved efficiency over network traffic and also improved device and data security.
Claims 9-19 are rejected under AIA 35 U.S.C. 103 as being un-patentable over Schwebke et al (U.S. Patent Application Publication No. 2014/0196117 A1) in view of Javanainen (U.S. Patent Application Publication No. 2005/0076206 A1).
As to claim 9, Schwebke et al disclose a server, comprising: a filter; a communication circuit; a memory configured to store a database; and a processor operatively connected to the filter, the communication circuit, and the memory (figure 2, pars. 0025 & 0039, CSS having servers and data stores), wherein the processor is configured to: receive a control data packet from an access control application of a node; identify whether first authentication information is included in the control data
packet; and based on the communication protocol and whether the first authentication
information is included, forward the control data packet to the processor or drop the control data packet (figure 4, par. 0054, figure 5, par. 0055, a CCD sends authentication data to a CSS and process a request for the CSS based on the received authentication result).
However, Schwebke et al do not teach that identify a communication protocol through which the control data packet is received.
Javanainen teaches that identify a communication protocol through which the control data packet is received (figure 1, pars. 0028-0029, figure 3, par. 0034, selecting a communication protocol to transmit and receive a data packet).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Javanainen as stated above with the server of Schwebke et al for identifying a communication protocol to transmit and receive a data packet because it would have improved efficiency over network traffic and also improved device and data security.
As to claim 10, Javanainen teaches that the received communication protocol is a TCP protocol and the control data packet is a TCP SYN packet and the first authentication information is included in the control data packet, check the first authentication information; when the check result indicates a failure, drop the control data packet; and when the check result indicates a success, forward the control data packet to the controller to generate a TCP session (figure 1, pars. 0026, 0028-0029, figure 3, par. 0034, selecting a proper TCP communication protocol to transmit and receive a data packet).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Javanainen as stated above with the server of Schwebke et al for identifying a communication protocol to transmit and receive a data packet because it would have improved efficiency over network traffic and also improved device and data security.
As to claim 11, Schwebke et al teach that the first authentication information is absent from the control data packet, identify whether identification information of the node is present in the database; when the identification information of the node is present in the database, identify whether a header is present in the control data packet;
when the header is present in the control data packet, check the header of the control data packet; and based on the header verify result, forward the control data packet to the processor to process a control request or drop the control data packet (figure 4, par. 0054, figure 5, par. 0055, a CCD sends authentication data to a CSS and process a request for the CSS based on the received authentication result).
As to claim 12, Javanainen teaches that the received communication protocol is a TCP protocol and the control data packet is not a TCP SYN packet (figure 1, pars. 0026, 0028-0029, figure 3, par. 0034, selecting a proper TCP communication protocol to transmit and receive a data packet); and Schwebke et al teach that identify whether a header is present in the control data packet; when the header is present in the control data packet, check the header of the control data packet; and based on the header check result, forward the control data packet to the processor to process a control request or drop the control data packet (pars. 0048-0049, figure 5, par. 0055).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Javanainen as stated above with the server of Schwebke et al for identifying a communication protocol to transmit and receive a data packet because it would have improved efficiency over network traffic and also improved device and data security.
As to claim 13, Javanainen teaches that the received communication protocol is an UDP protocol and the first authentication information is included in the control data packet, check the first authentication information (figure 1, pars. 0026, 0028-0029, figure 3, par. 0034, selecting a proper TCP communication protocol to transmit and receive a data packet); and Schwebke et al teach that when the check result indicates a failure, drop the control data packet; when the check result indicates a success, forward the control data packet to the controller to complete authentication; and when the first authentication information is included in the control data packet, drop the control data packet (pars. 0048-0049, figure 5, par. 0055).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to incorporate the teaching of Javanainen as stated above with the server of Schwebke et al for identifying a communication protocol to transmit and receive a data packet because it would have improved efficiency over network traffic and also improved device and data security.
As to claim 14, Javanainen teaches that the received communication protocol is not a TCP protocol or an UDP protocol, drop the control data packet (pars. 0028-0029).
As to claim 15, Schwebke et al teach that receive the control data packet forwarded from the filter; when the control data packet is a data packet for a control access request, identify whether the node or the access control application is in a state of being accessible, based on the database; when being in an accessible state, generate a control flow and generate a data flow and channel generation information based on the database; and transfer identification information of the generated control flow, the generated data flow, and the generated channel generation information to the access control application (figure 4, par. 0054, figure 5, par. 0055, a CCD sends authentication data to a CSS and process a request for the CSS based on the received authentication result).
As to claim 16, Schwebke et al teach that identify a drop log of the control data packet; and determine whether to add identification information of the node to a blacklist based on the database and the drop log of the control data packet (pars. 0048-0049, figure 5, par. 0055).
As to claims 17-19, they are also rejected for the same reasons set forth to rejecting claims 9-13 above, since claims 17 -19 do not teach or define any new limitations than above rejected claims 9-13.
Additional References
The examiner as of general interest cites the following references.
Lu et al, U.S. Patent No. 12,248824 B2.
Suzuki, U.S. Patent No. 10,278,045 B2.
Content Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Bharat Barot whose telephone number is (571)272-3979. The examiner can normally be reached on 7:00AM-3:30PM.
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, Kamal B Divecha can be reached on (571)272-5863. The fax phone number for the organization where this application or proceeding is assigned is (571)273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BHARAT BAROT/Primary Examiner, Art Unit 2453January 14, 2026