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 .
Response to Arguments
Applicant's arguments filed on October 23, 2025 have been fully considered but they are not persuasive , because no argument against the rejection has been provided. The applicant held the rejection in abeyance.
The indicated allowability of claim 7 is withdrawn in view of the newly discovered reference(s) to Pismenny et al. (US 20230034545 A1--hereinafter--"Pismenny”) rejections based on the newly cited reference(s) follow.
Newley added claims 21 and 22 are rejected under 35 U.S.C. 103 in view to Pismenny et al. (US 20230034545 A1--hereinafter--"Pismenny”).
Claims 15-20 are cancelled.
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.
Claims 1-6, 8-10 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Admitted Prior arts of record on the applicant’s specification (Hereinafter referred to as APAR) in view of Ludin et al. (US 20220078165 --Hereinafter--“Ludin”).
As per claim 1, APAR discloses Information Handling System (IHS) (Figure 8: 810, Host, , comprising:
a processor; and a memory coupled to the processor, wherein the memory comprises program instructions store thereon that, upon execution by the processor (Figure 8: 810 Host, Figure 9: 910; Figure 10: Host, Figure 11: 1110), cause the IHS to:
derive a shared session key during a first Transmission Control Protocol (TCP) connection ([0105] First, to recap, in order to establish the TCP transport layer, a TCP handshake 1131 takes place ; [0106] The TLS layer 1140 can be established by a TLS handshake 1141 when both sides already possess a generated PSK) with a second HIS (Figure 8: 820 subsystem, Figure 9: 920; Figure 10: Controller Figure 11: 1120) and
APAR does not explicitly disclose disconnection of the first TCP connection. Ludin, in analogous art however, discloses disconnection of the first TCP connection ([0025] The proxy server will terminate the transport layer (TCP in this example), but not TLS. The proxy server provides two layers of security checks for the origin: a TCP layer firewall and a TLS layer firewall. Each may have its own set of security checks, configured as appropriate and customized for the target digital property). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by APAR to include disconnection of the first TCP connection. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to increase the efficiency and speed with which an internet site protection layer, comprised of network non-terminating TLS proxies, can process traffic before proxying it to an origin server as suggested by Ludin ([0007]).
after disconnection of the first TCP connection,
APAR discloses perform a Transport Layer Security (TLS) negotiation with the second IHS via a second TCP connection using the shared session key ([0105] Then to establish the NVMe/TCP transport layer, an NVMe/TCP ICReq PDU 1152 and an NVMe/TCP ICResp PDU 1154 are communicated. Then for the NVMe-oF layer, an NVMe-oF Connect command 1162. and an NVMe-oF Connect response 1164 are communicated).
As per claim 2, APAR discloses the IHS of claim 1, wherein the TLS negotiation for the second TCP connection is performed to establish an administration queue ([0088]: The generated PSK (540, 560) is used to perform a TLS handshake, which secures the administration queue (530)).
As per claim 3, APAR discloses the IHS of claim 2, wherein the program instructions, upon execution by the processor, further cause the IHS to:
perform a second TLS negotiation with the second IHS via a third TCP connection using the shared session key ([0088] The generated PSK (540, 560) is then used directly for all of the I/O queues (532, 534, 538)); and
establish a first I/O queue based, at least in part, on the second TLS negotiation ([0088] To set up I/O queue #1 (532) the host performs steps 552 while the controller performs steps 572. A TCP handshake is performed. Then a TLS handshake is performed using (553, 573) the generated PSK (540, 560))
As per claim 4, APAR discloses the IHS of claim 3, wherein the program instructions, upon execution by the processor, further cause the IHS to:
perform a third TLS negotiation with the second IHS via a fourth TCP connection using the shared session key To set up I/O queue #2 (534) the host performs steps 554 while the controller performs steps 574. A TCP handshake is performed. Then a TLS handshake is performed using (555, 575) the generated PSK (540, 560); and
establish a second I/O queue based, at least in part, on the third TLS negotiation To set up I/O queue #2 (534) the host performs steps 554 while the controller performs steps 574. A TCP handshake is performed. Then a TLS handshake is performed using (555, 575) the generated PSK (540, 560).
As per claim 5 APAR discloses the IHS of claim 1, wherein the first TCP connection is a Non-Volatile Memory Express (NVMe) TCP connection, and wherein the second TCP connection is an NVMe TCP connection using TLS) ([0099] The second layer between the host 910 and the controller 920 is the NVMe/TCP transport layer 950. To establish the NVMe/TCP transport layer 950, an NVMe/TCP ICReq PDU 952 and an NVMe/TCP ICResp PDU 954 are communicated).
As per claim 6, APAR discloses the IHS of claim 1, wherein the shared session key with the second IHS is derived by a first authentication transaction, and wherein the first authentication transaction uses a Diffie-Hellman (DH) hash-based message authentication code (HMAC) Challenge-Handshake Authentication Protocol (CHAP) ([0103] Moving over to the righthand side of FIG. 10, a DH-HMAC-CHAP Protocol is executed, in order to perform authentication and generate a PSK. First an AUTH_NEGOTIATE message 1070 is sent that consists of an Authorization Send command 1072 from the host to the controller, and an authorization response 1074 from the controller to the host. Then the host sends the controller an Authorization Receive command 1076, and in response the controller sends the DH-HMAC-CHAP Challenge message 1080 to the host. The host sends a DH-HMAC-CHAP_Reply message 1085, which consists of an Authorization Send command 1086 from the host to the controller and an authorization response 1087 from the controller to the host).
As pr claim 8, APAR discloses the IHS of claim 1, wherein the shared session key with the second IHS is derived by a first authentication transaction, and wherein the first authentication transaction comprises a secure channel concatenation value usable on an administration queue over a TCP channel without TLS to generate a new shared session key ([0076] Ephemeral shared session key can by computed by a Diffie-Hellman (DH) hash-based message authentication code (HMAC) Challenge-Handshake Authentication Protocol (CHAP), or DH-HMAC-CHAP for short. This DH-HMAC-CHAP can be the other authentication protocol that generates the ephemeral shared session key. The TLS negotiation can then be performed using a PSK derived from that ephemeral shared session key. This reduces TLS PSK provisioning to a per-entity DH-HMAC-CHAP secret provisioning. This reduces the problem scope to an O(n) problem. A fabric with N hosts and M subsystem requires N+M secrets. TLS concatenation can be used by the NVMe-oF authentication protocol. Technical proposal (TP) 8006 and TP 8011 defined TLS concatenation as a way to deploy secure channels with TLS for NVMe/TCP).
As per claim 9, APAR discloses the IHS of claim 1, wherein the TLS negotiation for the second TCP connection is performed to establish an administration queue, and wherein the program instructions, upon execution by the processor, further cause the IHS to:
perform an authentication transaction on the administration queue comprising a secure channel concatenation value usable on an administration queue over a TLS secure channel to generate a second shared session key, wherein the second shared session key replaces the shared session key for future TLS negotiations([0091- 0092] Between a host 710 and a controller 720, NVMe/TCP establishes an admin queue 730, where all the administration commands are sent, and one or more I/O queues (732, 734, 738) where data input and output occurs. A third way to set up the administration queue (730) and the one or more I/O queues is detailed in FIG. 7. At steps 750 and 770 the host and the controller, respectively, each perform a TCP handshake, a Connect command and response to setup up the NVMe queue and associate the host to the controller, a DH-HMAC-CHAP authentication transaction to generate a PSK (740, 760), and then the generated PSK (740, 760) is used to perform a TLS handshake, which secures the administration queue (730). The generated PSK (740, 760) is then used directly for I/O queues #1 and #N (732, 738). For I/O queue #2 (734) the same process as the administration queue occurs).
As per claim 10, APAR discloses the IHS of claim 1, wherein the TLS negotiation for the second TCP connection is performed by a second authentication transaction comprising a secure channel concatenation value that indicates no secure channel concatenation ([0092] To set up I/O queue #2 (734) the host performs steps 754 while the controller performs steps 774. First, a TCP handshake is performed. Then a Connect command and response occurs to set up the NVMe queue and associate the host to the controller. Then a DH-HMAC-CHAP authentication transaction to generate a PSK (755, 775)).
As per claim 13, APAR discloses the IHS of claim 1, wherein the program instructions, upon execution by the processor, further cause the IHS to:
establish a secure channel with the second IHS based, at least in part, on the TLS negotiation ([0104] FIG. 11 is a third flow diagram detailing procedures for setting up a secure channel and NVMe queue between a host and a controller using an NVMe/TCP transport session that incorporates TLS concatenation. After the three protocol layers, the TCP transport layer 1130, the NVMe/TCP transport layer, 1140 and the NVMe-oF layer 1160, are all established (in the clear), and after a DH-HMAC-CHAP Protocol is in order to generate a PSK (not shown in FIG. 11), then a TLS handshake 1141 occurs to establish a TLS layer between a host 1110 and a controller 1120. The TLS protocol, while established last, effectively inserts a TLS layer 1140 between the TCP transport layer 1130 and the NVMe/TCP transport layer 1140).
As per claim 14, APAR discloses the IHS of claim 1, wherein to derive the shared session key with the second IHS, the program instructions, upon execution by the processor, further cause the IHS to:
perform a Non-Volatile Memory Express over Fabrics (NVMe-oF) authentication exchange with the second HIS ( [0100] The third layer between the host 910 and the controller 920 is the NVMe-oF layer 960. For the NVMe-OF layer 960, an NVMe-OF Connect command 962, and an NVMe-oF Connect response 964 are communicated, [0104] After the three protocol layers, the TCP transport layer 1130, the NVMe/TCP transport layer, 1140 and the NVMe-oF layer 1160, are all established (in the clear), and after a DH-HMAC-CHAP Protocol is in order to generate a PSK (not shown in FIG. 11), then a TLS handshake 1141 occurs to establish a TLS layer between a host 1110 and a controller 1120).
Claims 7 and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Admitted Prior arts of record on the applicant’s specification (Hereinafter referred to as APAR) in view of Ludin et al. (US 20220078165 --Hereinafter--“Ludin”) in further view of Pismenny et al. (US 20230034545 A1--hereinafter--"Pismenny”).
As per claim 7:
APAR and Ludin do not explicitly disclose wherein the second TCP connection uses a different TCP source port than the first TCP connection, and wherein unexpected non-TLS traffic of the first TCP connection is stranded by the disconnect of the first TCP connection. Pismenny, in analogous art however, discloses, wherein the second TCP connection uses a different TCP source port than the first TCP connection ([0042] In the pictured embodiment, accelerator 42 is implemented as a part of packet processing circuitry 40 and handles encoding and parsing functions in accordance with the NVMe/TCP protocol, in response to instructions conveyed by driver software 46 running on CPU 28. For this purpose, accelerator 42 maintains context data 44 in a memory for each TCP flow that it has been instructed to handle. Context data 44 may be held in a memory within NIC 34 and/or on a separate, dedicated memory chip and/or in a partition of host memory 30 that is assigned for this purpose. [0043] Context data 44 for each such flow include: [0044] The TCP packet context, including the 5-tuple of fields in the IP packet header (IP source and destination addresses, IP source and destination ports, and the protocol) and the next expected TCP packet serial number (PSN). [0045] The NVMe context of each storage transaction that is in progress. Read and write operations in NVMe enclose request and response messages (including data written to or read from storage) in PDUs, whose header contains metadata including a PDU type, data offset, data length, and capsule identifier (CID) of the command that initiated the operation); and wherein unexpected non-TLS traffic of the first TCP connection is stranded by the disconnect of the first TCP connection (0084] FIG. 6 is a state diagram that schematically illustrates a state machine maintained by accelerator 42 for processing of packets received from network 24, in accordance with an embodiment of the invention. The state machine ensures that the operation of accelerator 42 is properly synchronized with the TCP packet flow and NVMe PDU flow, as long as packets are received in order, and enables recovery of synchronization and reconstruction of context data 44 when a packet is received out of order. [0085] Operation of accelerator 42 on a given TCP flow begins in an offload state, after driver software 46 has initialized the context for an NVMe/TCP transaction. The accelerator remains in this state as long as successive TCP headers are received in order. When a packet is received with an out-of-order TCP sequence number (as at step 108 in FIG. 4), however, accelerator 42 enters a search state 122, where it remains until a new NVMe header is found. (Alternatively, the state machine may be configured so that even when a packet is received with its TCP sequence number out of order, the accelerator may remain in the offload state as long as the PDU headers in the packet payloads are received in order.) In this state, accelerator 42 passes packets to the appropriate ring buffer 48 in memory 30 without parsing, while waiting for the results of resynchronization).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the information handling system disclosed by APAR and Ludin to include wherein the second TCP connection uses a different TCP source port than the first TCP connection, and wherein unexpected non-TLS traffic of the first TCP connection is stranded by the disconnect of the first TCP connection. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to implement NVMe/TCP specifications to define the mapping of NVMe queues, capsules and data delivery over Internet Protocol (IP) networks using the ubiquitous Layer-4 Transmission Control Protocol (TCP) NVMe commands and responses are encapsulated into a message-based system by using “capsules” that contain one or more NVMe commands or responses as suggested by Pismenny ([0005]).
As per claims 21-22: Claims 21-22 are directed to corresponding limitation features of claim 7 and therefore, claims 21-22 are rejected with the same rationale given above to reject corresponding limitations of claim 7.
Allowable Subject Matter
Claims 11 and 12 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:
As per claim 11, The IHS of claim 1, wherein the program instructions, upon execution by the processor, further cause the IHS to:
attempt to perform a second TLS negotiation with the second IHS for a third TCP connection using the shared session key;
determine that the shared session key is not available on the second IHS;
perform an authentication transaction via the second TCP connection comprising a secure channel concatenation value usable on an administration queue over a TLS secure channel to generate a second shared session key, wherein the second shared session key replaces the shared session key for subsequent TLS negotiations; and
perform the second TLS negotiation with the second IHS for the third TCP connection using the second shared session key.
As per claim 12, The IHS of claim 1, wherein the program instructions, upon execution by the processor, further cause the IHS to:
determine that the shared session key is not available on the second IHS;
close the TLS negotiation with the second IHS;
perform an authentication transaction via the second TCP connection, wherein the second TCP connection is unsecured, comprising a secure channel concatenation value usable on an administration queue over a TCP channel without TLS to generate a second shared session key;
disconnect the second TCP connection;
establish a third TCP connection with the second IHS; and
perform a second TLS negotiation with the second IHS via the third TCP connection using the second shared session key derived during the second TCP connection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior art.
SHIVANNA et al US 20220210220 A1 discuses in [0057] Those practiced in protocols such as NVMe/TCP and iSCSI realize that NVMe and iSCSI data packets also have well defined and standardized formats. As such, NVMe/TCP packets, PDUs, and packet headers can be easily created and processed by a programmable data plane such as the data plane of a P4 programmable NIC. Similarly, iSCSI packets, PDUs, and packet headers can be easily created and processed by a programmable data plane such as the data plane of a P4 programmable NIC. Specifically, the parser can parse NVMe and iSCSI packets and PDUs, the match-action pipeline can process NVMe and iSCSI packets and PDUs, the deparser can assemble NVMe and iSCSI packets and PDUs, the demux/queue can assemble NVMe and iSCSI packets and PDUs, and the network appliance or NIC can send and receive NVMe and iSCSI packets and PDUs.
SHIVANNA further discuses in [0079] A layer 4 packet can have a layer 4 header 513 and a layer 4 payload 514. The layer 4 header 513 can include a source port 515, destination port 516, layer 4 flags 517, and other layer 4 header data 518. The source port and the destination port can be integer values used by host computers to deliver packets to application programs configured to listen to and send on those ports. The layer 4 flags 517 can indicate a status of or action for a network traffic flow. For example, TCP has the RST, FIN, and ACK flags. RST indicates a TCP connection is to be immediately shut down and all packets discarded. A TCP FIN flag can indicate the final transmission on a TCP connection, packets transmitted before the FIN packet may be processed. ACK acknowledges received packets. A recipient of a FIN packet can ACK a FIN packet before shutting down its side of a TCP connection. A traffic flow can be terminated by a flow termination dialog. Examples of flow termination dialogs include: a TCP RST packet (with or without an ACK); and a TCP FIN packet flowed by a TCP ACK packet responsive to the TCP FIN packet. Other protocols also have well known flow termination dialogs. A layer 4 payload 514 can contain a layer 7 packet. [0086] FIGS. 10-11 illustrate the TCP payloads of NVME/TCP packets that can be used for NVMe-oF. FIG. 10 illustrates a single TCP/IP packet 1001 having a TCP payload 1002 that includes multiple NVMe/TCP PDUs according to some aspects. TCP/IP payload 1002 includes NVMe/TCP PDU 1 1003 and NVMe/TCP PDU 2 1004. FIG. 11 illustrates a single NVMe/TCP PDU 1101 carried by multiple TCP packets according to some aspects. Multiple TCP payloads 1102 of multiple TCP packets carry the NVMe/TCP PDU 1101.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6: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, LINGLAN EDWARDS can be reached at (571) 270-5440. 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.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408