DETAILED ACTION
Response to Remark
This communication is considered fully responsive to the amendment filed on 05/22/26.
a. No claims have been amended.
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 of this title, 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.
Claims 1-8 and 10-22 are rejected under 35 U.S.C. 103 as being unpatentable over Ali (US 2006/041938, “Ali”) in view of Masputra et al. (US 2019/0306282, “Masputra”).
Regarding claim 1, Ali discloses a device comprising:
- a memory; and a processor configured to (See Fig.19, a memory and CPU):
- maintain a plurality of communication sessions (See Fig.10 and ¶.226, a set of sessions between TLS remote client application and TLS server handshake module);
- cause the memory to allocate a first portion of the memory to store received packets associated with a plurality of records of the plurality of communication sessions (See Fig.4 and ¶.87, the TLS Server Handshake Module requests an allocation or deallocation of a RAM buffer to manage that RAM buffer allocation or deallocation; See ¶.133-135, Fig.10 shows all handshake messages and a new digest context structure is allocated and initialized. This allocation is in the form of a memory buffer from the RAM heap; See ¶.151-152, the resulting record is encrypted using the session keys and algorithms established during the TLS handshake as described in conjunction with FIG. 10. the encrypted records are shown as 1305 and 1306 in FIG. 13. As a final step, a TLS record header is then attached to each record; Examiner’s Note: Masputra further explicitly discloses “the first pool of memory is dedicated to a first application comprising hardware driver, the hardware driver receiving data for a user space networking stack”); and
- cause the memory to allocate a second portion of the memory to store incoming packets associated with the plurality of records responsive to a trigger (See 1507 Fig.15, check ‘record size <=200 ?’ and then ‘yes’ or ‘no’ for data available 1500), wherein the trigger is based on a record size of a first record of the plurality of records (See ¶.161, if the remaining number of the record size is greater than the size of the TLS I/O buffer, the data I/O module reads as many bytes as would fit in the TLS I/O buffer (e.g., 200 bytes). The record flag value is then marked as PARTIAL, and the most recently read data is passed on to the application; See ¶.170, the record size is greater than the size of the TLS I/O buffer, the data I/O module successively reads as many bytes as will fit into the TLS I/O buffer and writes that data to a dedicated buffer that has been allocated in the NVM heap).
Ali discloses the method of allocating a dedicated buffer based on the TLS record size (See ¶.170), but does not explicitly explain the method of allocating a first portion of the memory for communication sessions and allocating a second portion of the memory to store incoming packets.
However, Masputra discloses the method of storing the data in the pool of dedicated memory resources (Masputra, See ¶.82; a first pool of dedicated memory resources for the application; a second pool of dedicated memory resources for a kernel space hardware driver; See ¶.87, the first pool of memory is dedicated to a first application comprising hardware driver, the hardware driver receiving data for a user space networking stack).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply the method of “storing processing data into the pool of dedicated memory resources” as taught by Masputra into the system of Ali, so that it provides a way of improving device operation by implementing stringent memory limitations and relying on user space memory management techniques for memory resource optimization (Masputra, See ¶.249).
Regarding claim 2, Ali discloses “responsive to all packets associated with the first record being received, cause a release of all portions of the memory storing the first record (See ¶.149, memory buffer can be released).”
Regarding claim 3, Ali does not explicitly disclose what Masputra discloses “identify the first record as a priority record based on the trigger; and responsive to identifying the first record as a priority record, prevent allocation of memory to a second record of the plurality of records (Masputra, See ¶.82; a first pool of dedicated memory resources for the application; a second pool of dedicated memory resources for a kernel space hardware driver; See ¶.87, the first pool of memory is dedicated to a first application comprising hardware driver, the hardware driver receiving data for a user space networking stack; See ¶.115, user space applications are treated at lower priority than kernel tasks; See ¶.251, the user space memory allocation and deallocation process inherently prevents persistent fragments of memory allocation).” Therefore, this claim is rejected with the similar reasons and motivation set forth in the rejection of claim 1.
Regarding claim 4, Ali does not explicitly disclose what Masputra discloses “identify the first record as a priority record based on the trigger; and responsive to identifying the first record as a priority record, delay an acknowledge message for a second record of the plurality of records (Masputra, See ¶.87, the first pool of memory is dedicated to a first application comprising hardware driver, the hardware driver receiving data for a user space networking stack; See ¶.115, user space applications are treated at lower priority than kernel tasks).” Therefore, this claim is rejected with the similar reasons and motivation set forth in the rejection of claim 1.
Regarding claim 5, Ali discloses “the trigger is based on the first record being received to within a threshold amount (See 1507 Fig.15, the decision procedure according to record size; See ¶.154, the data buffer used by the data I/O module can be as small as only 200 bytes).”
Regarding claim 6, Ali does not explicitly disclose what Masputra discloses “the trigger is based on a time-out value for the first record (Masputra, ¶.120, TLS timeout).” Therefore, this claim is rejected with the similar reasons and motivation set forth in the rejection of claim 1.
Regarding claim 7, Ali discloses “the plurality of communication sessions are secure communication sessions (See ¶.7, enable secure communications).”
Regarding claim 8, Ali discloses “the first record comprises data indicative of the record size (See 1507 Fig.15, record size).”
Regarding claim 10, Ali discloses “the first record comprises a first plurality of segments of a data connection (See ¶.151, data segments).”
Regarding claim 11, Ali and Masputra disclose “the data connection is associated with a window size, and wherein the processor is configured to: identify the first record as a priority record based on the trigger; and responsive to identifying the first record as a priority record (Masputra, See ¶.115, different processing priority according the applications and system configuration tasks such as communication sessions), increase the window size (Ali, See ¶.3, expanding the size of buffers (window) to accommodate the size of TLS record).” Therefore, this claim is rejected with the similar reasons and motivation set forth in the rejection of claim 1.
Regarding claim 12, Ali and Masputra disclose “a second record comprises a further plurality of segments of a further data connection that is associated with a second window size, and wherein the processor is configured to: identify the first record as a priority record based on the trigger; and responsive to identifying the first record as a priority record, decrease the second window size (Ali, See 1507 Fig.15 and ¶.160, less bytes; Masputra discloses the priority method as rejected in claims 1 & 4).” Therefore, this claim is rejected with the similar reasons and motivation set forth in the rejection of claim 1.
Regarding claim 13, Ali discloses “the processor is configured to control allocation of the memory based on a window size associated with the data connection (See Fig.15, check TLS record size).”
Regarding claim 14, Ali and Masputra disclose “the trigger is based on the first record being received to within a threshold amount (Ali, See 1503 Fig.15), and wherein the processor is configured to: identify the first record as a priority record based on the trigger (See ¶.161 and ¶.170 as rejected in claim 1 and Masputra’s disclosure in claim 1); and responsive to identifying the first record as a priority record, allocate at least portion of the second portion to packets of the first record before allocating any of the second portion to packets of other records of the plurality of records (Masputra, See ¶.84-87, the kernel space logic is configured to read data from the first pool of dedicated memory resources in word segments. In one such variant, the kernel space logic is configured to calculate the checksum from the word segments. [0085] In another variant, the kernel space logic is prioritized over user space logic; [0087] the first pool of memory is dedicated to a first application comprising hardware driver, the hardware driver receiving data for a user space networking stack; See ¶.115, generally, user space applications are treated at lower priority than kernel tasks). Therefore, this claim is rejected with the similar reasons and motivation set forth in the rejection of claim 1.
Regarding claim 15, it is a method claim corresponding to the device claim 1 and is therefore rejected for the similar reasons set forth in the rejection of the claim.
Regarding claims 16-20, they are claims corresponding to claims 2, 4, 11, 12, & 14, respectively and are therefore rejected for the similar reasons set forth in the rejection of the claims.
Regarding claim 21, Ali does not explicitly disclose what Masputra discloses “the device comprises a Wi-Fi application (Masputra, See ¶.28, Wi-Fi chips).” Therefore, this claim is rejected with the similar reasons and motivation set forth in the rejection of claim 1.
Regarding claim 22, Ali discloses “the device comprises an internet application (See ¶.2, internet).”
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Ali in view of Masputra and further in view of Naeimi et al. (US 2021/0211467, “Naeimi”).
Regarding claim 9, Ali and Masputra do not explicitly disclose what Naeimi discloses “the record size is 16 KB or less (Naeimi, See ¶.4, TLS encrypting up to 16 KB).”
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to apply “the record size is 16 KB or less” as taught by Naeimi into the system of Ali and Masputra, so that it provides a way of performing on individual relatively small-sized records (Naeimi, See ¶.5).
Response to Arguments
Applicant's arguments filed have been fully considered but they are not persuasive.
At pages 6-7, with respect to claim 1, applicant argues that any combination of Ali and Masputra fail to disclose “a processor configured to: ... cause the memory to allocate a second portion of the memory to store incoming packets associated with the plurality of records responsive to a trigger, wherein the trigger is based on a record size of a first record of the plurality of records" recited features of claim 1 by asserting that:
“The Office identifies Ali's step 1507 in FIG. 15 as corresponding to the claimed "allocate a second portion of the memory to store incoming packets associated with the plurality of records responsive to a trigger". In pertinent part, Ali discloses at step 1507 a method that includes determining whether "the record size ... is greater than the size of the TLS I/O buffer." Ali [0161]. However, determining whether a record size is greater than a size of the TLS I/O buffer does not disclose or suggest allocating a portion of a memory to store incoming packets associated with a plurality of records in response to a trigger based on a record size of a first record of the plurality of records. Instead, the cited portions disclose if "the record size ... is greater than the size of the TLS I/O buffer 1402 ... the data I/O module 205 reads as many bytes as would fit in the TLS I/O buffer ... the data is then decrypted" (see step 1509). Ali [0161]. And, if "the record size ... is not greater than the size of the TLS I/O buffer 1402, the entire record is read, step 1511, or the remaining data is read, step 1513 ... the data is decrypted and the MAC is updated." Ali [0162]. That is, the cited portions disclose reading and decrypting either a portion or all of a record data responsive to a comparison of the size of the current record data being processed. However, Ali does not disclose or suggest "a processor configured to: ... cause the memory to allocate a second portion of the memory to store incoming packets associated with the plurality of records responsive to a trigger, wherein the trigger is based on a record size of a first record of the plurality of records," as recited by claim 1. The other cited references fail to cure all of these deficiencies. Therefore, Applicant respectfully submits that claim 1 is in condition for allowance at least the foregoing reasons. [applicant’s emphasis].
In reply, the limitations “the trigger is based on a record size of a first record of the plurality of records” explicitly read on:
[Fig.15, Items 1505 & 1507] of Ali shows below;
[AltContent: ][AltContent: ]
PNG
media_image1.png
319
562
media_image1.png
Greyscale
¶.[0161] of Ali discloses “Either way, if the remaining number of bytes (step 1505) or the record size (step 1507) is greater than the size of the TLS I/O buffer (in one embodiment of this invention the size of the TLS I/O buffer is set to 200 bytes), the data I/O module 205 reads as many bytes as would fit in the TLS I/O buffer 1402 (e.g., 200 bytes). The data is then decrypted and the rolling MAC is updated. If using DES in CBC mode, the initialization vectors are also updated. This is shown as step 1509. The Record Flag value is then marked as PARTIAL, and the most recently read data is passed on to the application, step 1510.”
¶.[0162] of Ali discloses “On the other hand, if the remaining number of bytes (step 1505) or the record size (step 1507) is not greater than the size of the TLS I/O buffer 1402, the entire record is read, step 1511, or the remaining data is read, step 1513. In both these steps (1511 and 1513) the data is decrypted and MAC is updated. Since the entire TLS record has now been read, the data I/O module 205 can verify the MAC integrity. This check is shown in steps 1517 and 1515.”
¶.[0169] of Ali discloses “If the record size (check 1607) is not greater than the size of the TLS I/O buffer 1402, the entire record is read, step 1609. In the same step, the record data is decrypted and the MAC is both updated and finalized. Since the entire TLS record has been read, the data I/O module 205 can verify the MAC integrity. This check is shown in step 1615. If the MAC verification fails, an error is flagged, step 1620. If, however, the MAC verification succeeds, the current Record Flag is marked as COMPLETE and the data is passed on to the application, step 1619. The next read from the underlying communication layer 101 will now yield a new TLS record.
Further, the method claim limitations “allocate a second portion of the memory to store incoming packets associated with the plurality of records responsive to a trigger” explicitly read on:
¶.[0003] of Ali discloses “For example, it automatically expands the size of read/write buffers to accommodate the size of TLS records, using as much as 32K RAM for the buffers alone.” [emphasis added].
¶.[0012] of Ali discloses “FIG. 4(a) is a schematic illustration of an example of free and allocated blocks in the contiguous area of memory reserved for a RAM heap located on the RAM.” [emphasis added].
¶.[0014] of Ali discloses “FIG. 5(a) is a schematic illustration of the state of the RAM heap a new block has been allocated.”
¶.[0043] of Ali discloses “A Heap Manager 201 is responsible for allocation, de-allocation, and compaction of memory blocks in the contiguous area of RAM heap 302, as well as NVM heap 311. Other sub-components can request the Heap Manager 201 to allocate a new memory block of required size, or to free a previously allocated block of memory. The Heap Manager 201 is a critical tool in the optimization of limited memory resources in a resource-constrained device.”
¶.[0085] of Ali discloses “the design of SSL/TLS module 103 uses a very small stack area 301. This is achieved by removing all possible local variables, reducing the call stack depth, and cutting down the amount of data that is passed between function calls. Instead of using local variables, most variables are allocated on the RAM heap 302. This allows a much more fine-grained control over management of buffers at runtime. Buffers are allocated as needed by an application, and once used, can be freed for use by some other application. In addition, a separate NVM heap 311 is used when swapping bulk data. This swapping technique, described in section 3 below, further optimizes the utilization of limited RAM.”
¶.[0087] of Ali discloses “FIG. 4(a) is a schematic illustration of an example of free and allocated blocks in the contiguous area of memory reserved for a RAM heap located on the RAM. The allocation and de-allocation of buffers from RAM heap 302 is done through the heap manager module 201, which is a sub-component of the SSL/TLS module 103. Thus, whenever a module, e.g., the TLS Server Handshake Module 202, the SSL Sever Handshake Module 203, the TLS Client Handshake Module 207, or the SSL Client Handshake Module 208 requests an allocation or deallocation of a RAM buffer, such module 202, 203, 207, or 208 calls upon the Heap Manager 201 to manage that RAM buffer allocation or deallocation.” [emphasis added].
¶.[0092] of Ali discloses “the heap manager 201 receives a request to allocate a new memory buffer of size N bytes from the RAM heap 302.”
¶.[0111] of Ali discloses “During the TLS handshake phase, a pre-master secret and a master secret are stored in a single common buffer. Although both values are critical during the TLS handshake, they are not used at the same time. Once the master secret value has been computed from the pre-master secret value, the latter can be discarded. This property allows a single RAM buffer to be allocated for both the pre-master secret and the master secret.”
¶.[0170] of Ali discloses “If, however, the record size (check 1607) is greater than the size of the TLS I/O buffer 1402, the data I/O Module 205 successively reads as many bytes as will fit into the TLS I/O buffer 1402, and writes that data to a dedicated buffer that has been allocated in the NVM heap 311. This process is repeated until the entire TLS record has been written to the NVM heap, step 1611. The data written to NVM heap is then read in blocks that will fit in the TLS I/O buffer 1402 (e.g. 200 bytes) and decrypted using the currently selected cipher suite and session keys. This data is then written back to the NVM heap 311, step 1622. The data I/O module 205 now updates the data MAC and then calls finalize on the digest context, step 1623.” [emphasis added].
[Claim 6] of Ali discloses “maintaining a startpointer indicating the location of a next free memory buffer; in response to a request to allocate a memory buffer of size n, searching the RAM heap beginning at the startpointer for a memory buffer of size n, by: examining the size of the memory buffer pointed to by the startpointer, if the memory buffer pointed to by the startpointer smaller than n, moving the startpointer to the next free RAM heap block and continue searching, otherwise, allocate a memory buffer of size n located at the end of the RAM block pointed to by the startpointer.”
[Claim 9] of Ali discloses “the step of reusing an allocated buffer comprises storing a pre-master secret and a master secret in a common buffer during TLS handshake phase.”
In other words, for exchanging of messages between a client and a server during a typical TLS handshake phase, a pre-master secret and a master secret are stored in the allocated buffer. Further if the record size is greater than the size of the TLS I/O buffer, the data I/O Module successively reads as many bytes as will fit into the TLS I/O buffer and writes that data to a dedicated buffer that has been allocated in the NVM heap. Therefore, the examiner respectfully disagrees.
At page 8, with respect to claim 15, applicant argues that any combination of Ali and Masputra fail to disclose “maintaining, by a device, a plurality of communication sessions; allocating a first portion of a memory of the device to store received packets associated with a plurality of records of the plurality of communication sessions; and allocating a second portion of the memory to store incoming packets associated with the plurality of records responsive to a trigger, wherein the trigger is based on a record size of a first record of the plurality of records." Accordingly, independent claim 15 is in condition for allowance for at least some reasons similar to those discussed above with respect to claim 1.” In reply, this argument is similar to the argument of claim 1 and therefore, the similar reasons set forth as a response.
Conclusion
THIS ACTION IS MADE FINAL. 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 mailing date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jung H Park whose telephone number is 571-272-8565. The examiner can normally be reached M-F: 7:00 AM-3:00 PM.
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, Derrick Ferris can be reached on 571-272-3123. 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.
/JUNG H PARK/
Primary Examiner, Art Unit 2411
Prosecution Insights