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
The instant application having Application No. 18/615,765 is presented for examination by the examiner. Claims 1 and 13 are amended. Claims 1-24 are pending.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 and 13 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 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.
Claim(s) 1-24 are rejected under 35 U.S.C. 103 as being unpatentable over USP Application Publication 2020/0193017 to Bannister et al., hereinafter Bannister in view of NPL “eCapture: capture plaintext from TLS/SSL traffic using eBPF”, hereinafter eCapture. This particular file is in the Github repository for eCapture as the README.MD file. The rejection will make reference to one of the files which shows some of the actual code referenced in the README.MD file. That file, openssl.h, is cited on the 892 and will be used as ancillary evidence to show how eCapture works.
As per claims 1 and 13, Bannister teaches a method performed by at least one computer processor executing computer program instructions stored on at least one non-transitory computer-readable medium, the method comprising:
(A) intercepting a first call to a function in an encryption library, for creating a network entity according to a network protocol [at the time of creating a connection; 41-43 and 0065];
(B) extracting unencrypted data from the first call (0044 and 0045);
(C) correlating the extracted unencrypted data from the first call with information about a socket associated with the created network entity [the function and encryption library are correlated together along with the key that decrypts the encrypted data of that socketed session; 0042, 0043, and 0053-0055].
Bannister is silent in explicitly teaching correlating the unencrypted data with stored socket information comprising a socket file descriptor and at least one of an IP address or a port extracted from a network system call. Bannister uses a EBPF program to grab unencrypted keys used for SSL communications. eCapture uses EBPF function to hook TLS/SSL reads and writes to capture unencrypted data (see first figure and section on uprobe HOOK). By using the function SSL_write eCapture obtains the socket file descriptor from ssl->wbio->num, obtains the plaintext buffer pointer from the second argument to SSL_write, stores both in a mapping keyed by thread id, and on return retrieves that stored fd/buffer. The emitted TLS event then links the fd to the plaintext that was in the SSL_write buffer. The details of SSL_write are shown in the source code for that function.
Furthermore, in the source code for eCapture, probe_connect hook captures a connect(fd, sockaddr, len) call to read the fd and sockaddr which establishes an association with the socket file descriptor and the socket address. These two functions establish a correlation between the file descriptor with the plaintext and the file descriptor with the socket address. Thus, the extracted unencrypted data is correlated with stored socket information. This makes sense in terms of monitoring a connection so in the case of Bannister where the unencrypted data is the SSL key, the system needs to be able to recognize communications that use that key. Each prior art uses an EBPF program to grab unencrypted data. Correlating the key with the SSL traffic needs to be identifiable since only one given connection will use that key. The system can obviously use the socket file description and socket address as a way to identify the key used to encrypt those messages. The claim is obvious because one of ordinary skill in the art can combine methods known before the effective filing date which produce predictable results. Bannister needs to track keys to packets and eCapture provides one way of doing so.
As per claims 2 and 14, Bannister teaches the network entity comprises a context (0044 and 0065).
As per claims 3 and 15, Bannister teaches the network entity comprises a session (0065).
As per claims 4 and 16, Bannister teaches the network entity comprises a connection (0042 and 0065).
As per claims 5 and 17, Bannister teaches (B) comprises extracting the unencrypted data from the first call before the encrypted data is encrypted to generate encrypted data (before; 0045).
As per claims 6 and 18, Bannister teaches (B) comprises extracting the unencrypted data from the first call after encrypted data has been decrypted to generate the encrypted data [after encryption the key is used to decrypt the traffic; 0042 and 0045].
As per claims 7 and 19, Bannister teaches the network protocol comprises SSL/TLS (0057 and 0065).
As per claims 8 and 20, Bannister teaches intercepting the first call comprises intercepting the first call using an extended Berkeley packet filter (eBPF) subsystem (0042).
As per claims 9 and 21, Bannister teaches extracting the unencrypted data from the first call comprises extracting the unencrypted data from the first call using an extended Berkeley packet filter (eBPF) subsystem (0042).
As per claims 10 and 22, Bannister teaches (D) intercepting a second call to a function other than a function in the encryption library that does not create a network entity [subsequent call; 0043]; and (E) extracting unencrypted data from the second call (0057); (F) correlating the extracted unencrypted data from the second call with information about the socket associated with the created network entity [all types of functions after the creation of the network entity can be intercepted. These are referred to as subsequent calls made after the first call established a communication; 0043 and 0057].
As per claims 11 and 23, Bannister teaches intercepting the second call comprises intercepting the second call using an extended Berkeley packet filter (eBPF) subsystem (0042).
As per claims 12 and 24, Bannister teaches extracting the unencrypted data from the second call comprises extracting the unencrypted data from the second call using an extended Berkeley packet filter (eBPF) subsystem (0042).
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL R. VAUGHAN whose telephone number is (571)270-7316. The examiner can normally be reached on Monday - Thursday, 7:30am - 5:00pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. 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.
/MICHAEL R VAUGHAN/
Primary Examiner, Art Unit 2431
Prosecution Insights