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-30 are presented for examination.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 9-14, 16-18, and 21-29 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Miller et al., US Pub. No.20200389437.
As to claim 1. Miller discloses an access control method, comprising:
receiving, by a software defined perimeter (SDP) controller (108 fig.7), a first packet sent by a first SDP client device (102 fig.7), a transmission control protocol (TCP) option field of the first packet carrying a device identifier of the first SDP client device (the discovery protocol including TCP communication request may be received as part of receiving the request for establishment of the communications channel between the first computing device and the second computing device, see fig.7, abstract, [0046] to [0047]);
performing, by the SDP controller (108 fig.7), single-packet authentication on the first SDP client device based on the device identifier of the first SDP client device and if the single-packet authentication on the first SDP client device fails, disabling, by the SDP controller, a TCP connection between the first SDP client device to which the first packet belongs and the SDP controller (the first device 102 is authenticated and begins a UDP conversation with the SDP controller 108, see [0048]).
As to claim 9. Miller discloses an access control method, comprising:
sending, by a software defined perimeter (SDP) client device, a first packet to an SDP controller (108 fig.7) , a transmission control protocol (TCP) option field of the first packet carrying a device identifier of the SDP client device (102 fig.7) (the discovery protocol including TCP communication request may be received as part of receiving the request for establishment of the communications channel between the first computing device and the second computing device, see fig.7, abstract, [0046] to [0048].
As to claim 10, Miller discloses receiving, by the SDP client device, a single-packet authentication response sent by the SDP controller, if the single-packet authentication response indicates that single-packet authentication performed by the SDP controller on the SDP client device succeeded, sending, by the SDP client device, a second packet to the SDP controller, a transport layer security (TLS) option field or an application layer packet header of the second packet carrying authentication information, and the
authentication information comprises user information of the SDP client device; and
receiving, by the SDP client device, a resource list returned by the SDP controller, the
resource list comprising an application server identifier of at least one application server, the resource list allowing for access by the SDP client device (establishing a mutually-authenticated Transport Layer Security (TLS) tunnel between the client device and SDP controller, see [0045] to [0046]),
As to claim 11, Miller discloses the first packet and the second packet are in a same TCP connection, or the first packet and the second packet are in different TCP connections (processing TCP connections, see [0041] and [0046]).
As to claim 12, Miller discloses when the first packet and the second packet are packets in different TCP connections, and before the sending, by the SDP client device, the second packet to the SDP controller, the method further comprises: receiving, by the SDP client device, a salt value returned by the SDP controller based on the first packet and the second packet further carries the salt value and the salt value carried in the second packet being used by the SDP controller to determine that the single-packet authentication on the second SDP client device has succeeded (polling and processing the SDP controller 108 to determine whether the SDP controller 108 has data identifying other client applications that may be available for communication with another computing device of the client application, see [0025] to [0028]).
As to claim 13, Miller discloses the first packet is a synchronous (SYN) packet (see [0018]).
As to claim 14, Miller discloses the device identifier carried in the TCP option field is in a ciphertext form, and the method further comprises: obtaining a character string of a specified length based on the device identifier in a plaintext form and encrypting the character string using a sequence number of the SYN packet to obtain the device identifier in the ciphertext form (see [0018] and [0041]).
As to claim 16, Miller discloses after the receiving, by the SDP client device, the resource list returned by the SDP controller, the method further comprises: sending, by the SDP client device, a third packet to a SDP gateway, wherein a TCP option field of the third packet carries a device identifier of the SDP client device and receiving, by the SDP client device, service data returned by the application server, the service data being sent by the application server after the SDP gateway forwards the third packet to the application server after determining, based on the device identifier carried in the TCP option field of the third packet, that the SDP client device is authorized (the discovery protocol including TCP communication request may be received as part of receiving the request for establishment of the communications channel between the first computing device and the second computing device, see [0046] to [0048]).
As to claim 17, Miller discloses the first packet is a synchronous (SYN) packet (see [0018]).
Claims 18, 21-22 are rejected for the same reasons set forth in claims 1, 13 and 14 respectively.
As to claim 23, Miller discloses comparing the character string with a stored character string corresponding to each registered SDP client device, wherein the stored character string corresponding to the each registered SDP client device is generated based on a plainform text registered SDP client device identifier in a plaintext form of the each registered SDP client device and if the character string is the same as a character string corresponding to the each registered SDP client device, determine that the single-packet authentication succeeded (the SDP controller 108 authenticates the first device 102 according to a SDP authentication protocol, see [0033] to [0035]).
As to claim 24, Miller discloses if the user authentication on the second SDP client device succeeded, the instructions when executed by the processor further cause the SDP controller to: send client information to an SDP gateway, the client information indicating that authentication on the second SDP client device succeeded, and the client information comprising the device identifier of the second SDP client device (the SDP controller 108 authenticates the first device 102 according to a SDP authentication protocol, see [0033] to [0035]).
Claims 25-29 are rejected for the same reasons set forth in claims 9-11, 13 and 14 respectively.
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 (i.e., changing from AIA to pre-AIA ) 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(s) 15 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Miller et al., US Pun. No.20200389437 in view of Islam et al., US Pub. No.20200403787.
As to claims 15 and 30, Miller does not specifically disclose character string of the specified length is obtained by performing a hash operation on the device identifier in the plaintext form. However, in a similar network environment, Islam discloses character string of the specified length is obtained by performing a hash operation on the device identifier in the plaintext form (SDP controller 510 may use quantum random numbers, and/or quantum random numbers hashed with locally generated random numbers from local entropy source 530, to generate keys for digital certificates used to establish a secure communication in SDP network, see [0060]). It would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was made to implement Islam’s teachings into the computer system of Miller to control data information because it would have granted permission and establish a secure connection from the SDP client to a particular SDP gateway (see Islam’s [0059].
Allowable Subject Matter
Claims 2-8, 19 and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: None of the cited prior art discloses or teaches an access control method, comprising a combination of: receiving, by the SDP controller, a first packet sent by a second SDP client device, a TCP option field of the first packet sent by the second SDP client device carrying a device identifier of the second SDP client device, performing, by the SDP controller, single-packet authentication on the second SDP client device based on the device identifier of the second SDP client device, if the single-packet authentication on the second SDP client device succeeded, receiving, by the SDP controller, a second packet sent by the second SDP client device, a transport layer security (TLS) option field or an application layer packet header of the second packet carrying authentication information, and the authentication information comprises user information of the second SDP client device, performing, by the SDP controller, user authentication on the second SDP client device based on the device identifier and the user information of the second SDP client device and if the user authentication on the second SDP client device succeeded, sending, by the SDP controller, a resource list to the second SDP client device, the resource list comprising an application server identifier of at least one application server, the resource list allowing for access by the second SDP client device.
Conclusion
8. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Khanh Dinh whose telephone number is (571) 272-3936. The examiner can normally be reached on Monday through Friday from 8:00 A.m. to 5:00 P.m.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Umar Cheema, can be reached on (571) 270-3037. The fax phone number for this group 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).
/KHANH Q DINH/Primary Examiner, Art Unit 2458