DETAILED ACTION
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/05/2026 has been entered.
Response to Amendment
Applicant’s amendment, filed 03/05/2026, has been entered and fully considered.
In light of Applicant’s amendment, the rejection of claims 1-18, 20 under 35 U.S.C. 112(a) has been withdrawn.
Response to Arguments
Applicant’s further arguments, see pages 8-13 with respect to claim(s) 1-18, 20 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 § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 6, 13-18, 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 6, 13, 15 recites the limitation "the session" in line, 4, 9, respectively. There is insufficient antecedent basis for this limitation in the claim.
Claim 14 recites the limitation "the first messages" in line 1. There is insufficient antecedent basis for this limitation in the claim.
Claim 18 recites the limitation "the at least one session" in line 3. There is insufficient antecedent basis for this limitation in the claim.
Claim 16-18, 20 is rejected under a similar rationale. The dependent claims included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. Therefore, they are rejected based on the same rationale as applied to their parent claims above.
Claim Rejections - 35 USC § 101
Claims 8-18, 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the BRI of one or more processors can encompass non-statutory transitory forms of products that do not have a physical or tangible form such as a computer program per se (often referred to as "software per se") when claimed as a product without any structural recitations. See MPEP 2106.03(I). The Examiner suggests reciting “one or more hardware processors” or “memory with instructions that, when executed by the one or more processors, cause the one or more processors to…”, etc.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-10, 12-18, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sen et al. (USP App Pub 2020/0218684; hereinafter Sen) in view of Bhabbur et al. (USP App Pub 2019/0141041; hereinafter Bhabbur) in further view of Mellanox Technologies (Technologies, M. (2012, September). RDMA Aware Networks Programming user Manual Rev 1.3. RDMA Aware Networks Programming User Manual. https://indico.cern.ch/event/218156/attachments/351725/490089/RDMA_Aware_Programming_user_manual.pdf) in further view of Ravich et al. (USP App Pub 2021/0103548; hereinafter Ravich).
Regarding claim 8, A system (Sen: paragraph [0085], “process 900 for establishing a communication session 830 with target accelerator resource(s)”), comprising:
one or more processors to:
generate a first message associated with establishing a direct data connection to a networked server (Sen: paragraph [0088], “At operation 906, the initiator 822 generates … a connection establishment request message for a primary connection 831 … an RDMA-based protocol is used for the primary connection 831”), the first message including credential information (Sen: paragraph [0088], “the connection establishment request message for the primary connection 831 may also include an identifier (ID) of the initiator 822 (e.g., a suitable fingerprint value or the like)”), an add session request (Sen: paragraph [0088], “The connection establishment request message for the primary connection 831 may include any necessary parameters as required by the particular protocol used for the primary connection 831”; paragraph [0089], “the connection establishment response message for the primary connection 831 includes a session ID” i.e., the particulars of the primary connection establish the session; Application specification: paragraph [0053], “the request 302 is an add session request to establish a new RDMA session”), and an add queue pair (QP) request (Sen: paragraph [0088], “the initiator 822 may encapsulate an RDMA transport packet within an Ethernet/IP/UDP packet (including either IPv4 or IPv6) where…the source UDP port field is populated with a randomly generated number for the QP”), the add session request associated with a new session-based connection (Sen: paragraph [0087], “the initiator 822 initiates a communication session 830 establishment procedure with the target accelerator resource(s)”) between a requestor (Sen: paragraph [0087], “the initiator 822) and the networked server (Sen: paragraph [0080], “the “target accelerator resource(s)” refers to the controller at the accelerator sled 104”; paragraph [0020], “one or more accelerator sleds 104 which are communicatively connected together by an illustrative network 106”);
send, to the networked server along a data path bypassing an operating system kernel (Sen: paragraph [0063], “The computing platform 102 may use any suitable communication protocol, such as … RDMA”), the first message (Sen: paragraph [0088], “the initiator 822 … sends, to the target accelerator resource(s), a connection establishment request message for a primary connection 831”), the first message configured to provide the add session request prior to the add QP request (Sen: paragraph [0088], “the initiator 822 may encapsulate an RDMA transport packet within an Ethernet/IP/UDP packet (including either IPv4 or IPv6)”; paragraph [0088], “the source UDP port field is populated with a randomly generated number for the QP” i.e., packet structure of the encapsulation starts prior to port information. See references cited);
receive a second message from the networked server (Sen: paragraph [0089], “In response to the connection establishment request message for the primary connection 831, at operation 906, the initiator 822 receives a connection establishment response message for the primary connection 831 from the target accelerator resource(s)”), the second message including …, an add session reply (Sen: paragraph [0089], “the connection establishment response message for the primary connection 831 includes a session ID”), and an add QP reply (Sen: paragraph [0089], “the target accelerator resource(s) may encapsulate an RDMA acknowledgement (ACK) packet within an Ethernet/IP/UDP packet (including either IPv4 or IPv6) and including suitable destination and source addresses based on the connection establishment request message” i.e., the QP request corresponds to information provided in the source UDP port field); …
receive, along the direct data connection, data from the networked server (Sen: paragraph [0101], “It should be noted that the act of sending command and/or data signaling over the primary connection 831 is supported after the session 830 has been established without needing a special activation message”);
…
Sen does not teach … a certificate request… send, to the networked server, a third message including a certification verification and a connection request; … send, to the networked server, a fourth message as a combined request including multiple add QP requests, wherein the combined request omits the add session request; and receive a fifth message, from the networked server, the fifth message including individual add QP replies for the multiple add QP requests, wherein the fifth message omits the add session reply.
However, in the same field of endeavor, Bhabbur does teach … a certificate request (Bhabbur: paragraph [0130], “the RDMA authentication management system 20…[may]…receive a user credential …in response to a request for the credential”)…
send, to the networked server, a third message including a certification verification (Bhabbur: paragraph [0130], “the received user credential is received in the form of a value demonstrating possession of a user credential”) and a connection request (Bhabbur: paragraph [0130], “associated with a request to initiate an RDMA session”);
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the RDMA connection system of Sen to incorporate the teachings of Bhabbur to authenticate a connection using user credentials. The motivation for doing so is to verify the identity of the user and to recognize unauthorized users (Bhabbur: paragraph [0130], “may make a binary determination of whether the received credential is valid”; paragraph [0131], “Upon determining that a user is too high of risk or that their credentials are not valid, some embodiments may log a failed access request in the access log”).
However, in the same field of endeavor, Mellanox does teach … send, to the networked server (Mellanox: page 243, “Function: run_client … Description: executes the client side of this example”; page 235, “It can be demonstrated on a simple fabric of two nodes with the server application running on one node and the client application running on the other” i.e., client sends messages to the server), a fourth message (Mellanox: page 244, “for (i = 0; i < ctx->qp_count; i++) { … ret = rdma_create_ep(&ctx->conn_id[i], rai, NULL, &attr); … }”; page 235, “Both the client and server use an SRQ. A number of Queue Pairs (QPs) are created (ctx.qp_count) and each QP uses the SRQ. The connection between the client and server is established using the IP address details passed on the command line.”; page 103, “rdma_create_ep creates an identifier and optional QP used to track communication information. If qp_init_attr is not NULL, then a QP will be allocated”; page 243, “Input … rai: The RDMA address info for the connection”; i.e., on a subsequent iteration, i = 1, QPs are added to the existing connection specified by rai)… wherein the combined request omits the add session request (Mellanox: page 244, “rdma_create_ep(&ctx->conn_id[i], rai, NULL, &attr)” i.e., rai is a pre-existing connection and the function will allocate a new QP in associated with this pre-existing connection. This function call does not include information to create a new connection; page 103, “a QP will be allocated and associated with the rdma_cm_id, id”) …
receive a fifth message, from the networked server (Mellanox: page 243, “Function: run_client … Description: executes the client side of this example”), the fifth message (Mellanox: page 244, “rdma_create_ep(&ctx->conn_id[i]…)”; page 103, “Input parameters: id … A reference where the allocated communication identifier will be returned” i.e., the allocated communication identifier is received by the client via the pointer &ctx->conn_id[i])… wherein the fifth message omits the add session reply (Mellanox: page 103, “Input parameters: id…A reference where the allocated communication identifier will be returned … res…Address information associated with the rdma_cm_id returned from rdma_getaddrinfo” i.e., the function does not return a new session or connection identifier and does not create a new session)…
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the primary connection establishment process of Sen and Bhabbur to incorporate the teachings of Mellanox to add additional QPs on the existing connection, executing the method for i = 0. The client function in Mellanox executes after the primary RDMA connection in Sen is established because the client function requires a context with the connection as a function input. The motivation for doing so is allow users to create multiple QPs on the same connection (Mellanox: page 246, “op = getopt(argc, argv, "sa:p:c:l:q:w:" … ctx.qp_count = atoi(optarg)” i.e., through a command line interface, a user can define the number of QPs desired).
Sen, Bhabbur and Mellanox do not teach … a fourth message as a combined request including multiple add QP requests, … the fifth message including individual add QP replies for the multiple add QP requests,…
However, in the same field of endeavor, Ravich does teach … a fourth message as a combined request including multiple add QP requests (Ravich: paragraph [0046], “device A transmits an RDMA connection request to device B … the RDMA connection request may include the first set of connection parameters … each of the first QP objects may be identified (explicitly or implicitly) in the first set of connection parameters … the RDMA connection request is a request to establish multiple RDMA channels with a single handshake”; paragraph [0020], “FIG. 2A is a diagram of an example of QP object 150A”; FIG. 1B, multiple channels are established using QP objects; paragraph [0039], “Composite connection parameter sets 270 and 280 may be used to establish channels 140a, 140b, and 140c with a single handshake”; paragraph [0040], “composite connection parameter set 270 may include, the value 232a, 236a, 234a, 238a, 238a′, and 238a″, where 238a′ is the second value of connection parameter 218 that is inserted in QP object 150b, and 238a″ is the second value of connection parameter 218 that is inserted in QP object 150c”), …
the fifth message including individual add QP replies for the multiple add QP requests (Ravich: paragraph [0052], “device A receives the second set of connection parameters”; paragraph [0050], “device B generates a second set of connection parameters that is associated with the second QP objects. In some implementations, the second set of connection parameters may be the same or similar to the parameter set 280”; FIG. 2D, connection parameters include replies for 238b, 238b’, 238b”; paragraph [0024], “The value 238b may be an identifier that is accorded to the QP object 160a by device 120. In other words, the values 238a and 238b together identify a pair of objects, that are instantiated on different devices, and which are used to establish an RDMA channel (e.g., the channel 140a in the present case) between the devices”),…
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the iterative process to add additional multiple QPs, for example, for 1 ≤ i ≤ 2, in Sen, Bhabbur and Mellanox to incorporate the teachings of Ravich to establish the additional multiple QPs as RDMA/QP channels over the connection in a combined communication. The motivation for doing so is to “increase the efficiency and/or speed at which multiple RDMA channels are established between the same two devices” (Ravich: paragraph [0027]).
Regarding claim 9, Sen, Bhabbur, Mellanox and Ravich teach the system of claim 8, wherein
the direct connection is a remote direct memory access (RDMA) connection (Sen: paragraph [0088], “At operation 906, the initiator 822 generates … a connection establishment request message for a primary connection 831 … an RDMA-based protocol is used for the primary connection 831”).
Regarding claim 12, Sen, Bhabbur, Mellanox and Ravich teach the system of claim 8, wherein
the credential information includes at least a portion of information for generating a key (Bhabbur: paragraph [0140], “a value based on the authorization token, such as a private cryptographic key”; paragraph [0130], “upon determining that the credentials are valid and the request is sufficiently low risk, some embodiments may engage the authentication token generator 50 to generate an authentication token” i.e., the validity of the credential is a piece of information relating to it and an authentication token is subsequently generated; paragraph [0130], “the received user credential is received in the form of a value demonstrating possession of a user credential, such as a ciphertext signed with a private key of a user”).
The motivation to combine references for claim 12 is the same as the motivation stated in the rejection of claim 8.
Regarding claim 13, Sen, Bhabbur, Mellanox and Ravich teach the system of claim 8, wherein the one or more processing units are further to:
generate a sixth message request (Mellanox: page 244, “for (i = 0; i < ctx->qp_count; i++) { … ret = rdma_create_ep(&ctx->conn_id[i], rai, NULL, &attr); … }” i.e., for i=3, this is a fourth iteration of the loop and therefore executes rdma_create_ep) including a second add QP request (Mellanox: page 103, “rdma_create_ep creates an identifier and optional QP used to track communication information. If qp_init_attr is not NULL, then a QP will be allocated” i.e., each call to rdma_create_ep adds a QP to the pre-existing connection rai); and
send, to the networked server after verification of the session (Sen: paragraph [0089], “the connection establishment response message for the primary connection 831 includes a session ID, which may be included in the header or payload section of the message. The session ID is generated by the target accelerator resource(s)”), the sixth message (Mellanox: page 243, “Function: run_client … Description: executes the client side of this example”; page 235, “It can be demonstrated on a simple fabric of two nodes with the server application running on one node and the client application running on the other” i.e., client sends messages to the server).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the primary connection establishment process of Sen, Bhabbur, Mellanox and Ravich to incorporate the teachings of Mellanox to add additional QPs on the newly established primary connection. The motivation for doing so is allow users to create multiple QPs on the same connection (Mellanox: page 246, “op = getopt(argc, argv, "sa:p:c:l:q:w:" … ctx.qp_count = atoi(optarg)” i.e., through a command line interface, a user can define the number of QPs desired).
Re. claims 15-16, they recite analogous limitations as claims 8, 12, respectively, and therefore are rejected for the same reasons.
Regarding claim 17, Sen, Bhabbur, Mellanox and Ravich teach the system of claim 15,
wherein the single message (Sen: paragraph [0088], “At operation 906, the initiator 822 generates … a connection establishment request message for a primary connection 831 … an RDMA-based protocol is used for the primary connection 831”) includes multiple additional add QP requests (Ravich: paragraph [0046], “device A transmits an RDMA connection request to device B … the RDMA connection request may include the first set of connection parameters … each of the first QP objects may be identified (explicitly or implicitly) in the first set of connection parameters”; paragraph [0032], “Channels 140a, 140b, and 140c may all have a different first value for connection parameter 218 (i.e., destination QP number), and for this reason connection parameter 218 is considered a unique connection parameter”; FIG. 1B, multiple RDMA channels are established over a networked connection) and a reply to the single message (Ravich: paragraph [0052], “device A receives the second set of connection parameters”; FIG. 2D, connection parameters include replies for 238b, 238b’, 238b”) addresses fewer than all of the add QP requests in the single message (Mellanox: page 244, “ret = rdma_create_ep(&ctx->conn_id[i], rai, NULL, &attr); if (ret) { VERB_ERR("rdma_create_ep", ret); return ret; }”; page 103, section 5.2.5 rdma_create_ep , “Return Value: …-1 on error” i.e., failure in the function call when i = 1 returns -1 and does not allocate a second QP, therefore not providing a connection parameter for 238’).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the primary connection of Sen, Bhabbur, Mellanox and Ravich to incorporate the teachings of Ravich to establish multiple QPs over the primary connection during connection establishment. The motivation for doing so is to “increase the efficiency and/or speed at which multiple RDMA channels are established between the same two devices” (Ravich: paragraph [0027]) when “a large number of RDMA channels needs to be established between the same two devices” (Ravich: paragraph [0027]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the primary connection of Sen, Bhabbur, Mellanox and Ravich to incorporate the teachings of Mellanox to omit QP reply connection parameters in the second set of connection parameters when the QP allocation experiences an error. The motivation for doing so is because the QP objects were never allocated so the parameters should be excluded (Ravich: paragraph [0050], “device B generates a second set of connection parameters that is associated with the second QP objects”).
Re. claims 10, 14, they recite analogous limitations as claim 17 and therefore are rejected for the same reasons.
Regarding claim 18, Sen, Bhabbur, Mellanox and Ravich teach the system of claim 15, wherein the one or more processors further:
package the second combined request (Ravich: paragraph [0046], “device A transmits an RDMA connection request to device B … the RDMA connection request may include the first set of connection parameters … each of the first QP objects may be identified (explicitly or implicitly) in the first set of connection parameters … the RDMA connection request is a request to establish multiple RDMA channels with a single handshake”), after the at least one session is established (Sen: paragraph [0089], “the connection establishment response message for the primary connection 831 includes a session ID, which may be included in the header or payload section of the message. The session ID is generated by the target accelerator resource(s)”).
The motivation to combine references for claim 18 is the same as the motivation stated in the rejection of claim 8.
Regarding claim 20, Sen, Bhabbur, Mellanox and Ravich teach the system of claim 15, wherein the system is comprised in at least one of:
a system for performing simulation operations;
a system for performing simulation operations to test or validate autonomous machine applications;
a system for rendering graphical output;
a system for performing deep learning operations; a system implemented using an edge device;
a system for generating or presenting virtual reality (VR) content;
a system for generating or presenting augmented reality (AR) content;
a system for generating or presenting mixed reality (MR) content;
a system incorporating one or more Virtual Machines (VMs); a system implemented at least partially in a data center;
a system for performing hardware testing using simulation;
a system for synthetic data generation;
a collaborative content creation platform for 3D assets; or
a system implemented at least partially using cloud computing resources (Sen: paragraph [0074], “In various embodiments, the arrangement 800 is a cloud computing environment”).
Re. claim 1, it recites analogous limitations as claim 8 and therefore is rejected for the same reasons.
Regarding claim 2, Sen, Bhabbur, Mellanox and Ravich teach the computer-implemented method of claim 1, wherein
the first message (Sen: paragraph [0088], “At operation 906, the initiator 822 generates … a connection establishment request message for a primary connection 831 … an RDMA-based protocol is used for the primary connection 831”) further includes an encryption request (Bhabbur: paragraph [0022], “may encrypt or cryptographically sign RDMA exchanged data using user's private key”; paragraph [0140], “a value based on the authorization token, such as a private cryptographic key” i.e., the private key may be derived from the authorization token; paragraph [0130], “The received user credential may be received with the request”; paragraph [0130], “upon determining that the credentials are valid and the request is sufficiently low risk, some embodiments may engage the authentication token generator 50 to generate an authentication token” i.e., the user credential in the first connection request may result in the encryption of data exchanges in the session. An ‘encryption request’ may be one that results in the encryption of data).
The motivation to combine references for claim 2 is the same as the motivation stated in the rejection of claim 8.
Regarding claim 3, Sen, Bhabbur, Mellanox and Ravich teach the computer-implemented method of claim 2, wherein
the second message (Bhabbur: FIG. 2, block 82 ‘Challenge user to provide OTP/PKI Pin’ is the second message that application 66 receives from RDMA agent 67) further includes an encryption reply (Bhabbur: paragraph [0107], “Client/Peer may receive a PKI challenge”; paragraph [0026], “user signs the challenge with the private key and the server verifies the signed challenged using the user's public key” i.e., a PKI challenge is an encryption reply).
The motivation to combine references for claim 3 is the same as the motivation stated in the rejection of claim 8.
Regarding claim 4, Sen, Bhabbur, Mellanox and Ravich teach the computer-implemented method of claim 3, wherein
the connection is an encrypted connection (Bhabbur: paragraph [0022], “may encrypt or cryptographically sign RDMA exchanged data using user's private key” i.e., the RDMA communication exchange is encrypted).
The motivation to combine references for claim 4 is the same as the motivation stated in the rejection of claim 8.
Regarding claim 5, Sen, Bhabbur, Mellanox and Ravich teach the computer-implemented method of claim 1, wherein the first message is transmitted across an application layer (Sen: paragraph [0063], “The computing platform 102 may use any suitable communication protocol, such as … RDMA”; See References Cited) and includes at least one second add QP request (Ravich: paragraph [0046], “device A transmits an RDMA connection request to device B … the RDMA connection request may include the first set of connection parameters … each of the first QP objects may be identified (explicitly or implicitly) in the first set of connection parameters”; paragraph [0032], “Channels 140a, 140b, and 140c may all have a different first value for connection parameter 218 (i.e., destination QP number), and for this reason connection parameter 218 is considered a unique connection parameter”; FIG. 1B, multiple RDMA channels are established over a networked connection), and wherein the add QP reply (Ravich: paragraph [0052], “device A receives the second set of connection parameters”; FIG. 2D, connection parameters include replies for 238b, 238b’, 238b”) is associated with only the add QP request (Mellanox: page 244, “ret = rdma_create_ep(&ctx->conn_id[i], rai, NULL, &attr); if (ret) { VERB_ERR("rdma_create_ep", ret); return ret; }”; page 103, section 5.2.5 rdma_create_ep , “Return Value: …-1 on error” i.e., failure in the function call when i = 1 returns -1 and does not allocate a second QP, therefore not providing a connection parameter for 238’).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the primary connection of Sen, Bhabbur, Mellanox and Ravich to incorporate the teachings of Ravich to establish multiple QPs over the primary connection during connection establishment. The motivation for doing so is to “increase the efficiency and/or speed at which multiple RDMA channels are established between the same two devices” (Ravich: paragraph [0027]) when “a large number of RDMA channels needs to be established between the same two devices” (Ravich: paragraph [0027]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the primary connection of Sen, Bhabbur, Mellanox and Ravich to incorporate the teachings of Mellanox to omit QP reply connection parameters in the second set of connection parameters when the QP allocation experiences an error. The motivation for doing so is because the QP objects were never allocated so the parameters should be excluded (Ravich: paragraph [0050], “device B generates a second set of connection parameters that is associated with the second QP objects”).
Regarding claim 6, Sen, Bhabbur, Mellanox and Ravich teach the computer-implemented method of claim 1, further comprising:
determining the session is established (Sen: paragraph [0089], “the connection establishment response message for the primary connection 831 includes a session ID, which may be included in the header or payload section of the message. The session ID is generated by the target accelerator resource(s)”).
Re. claim 7, it recites analogous limitations as claim 17 and therefore is rejected for the same reasons.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sen in view of Bhabbur in further view of Mellanox in further view of Ravich in further view of Pan et al. (USP App. Pub. 2020/0213246; hereinafter Pan).
Regarding claim 11, Sen, Bhabbur, Mellanox and Ravich teach the system of claim 8, wherein
the add session request (Sen: paragraph [0088], “The connection establishment request message for the primary connection 831 may include any necessary parameters as required by the particular protocol used for the primary connection 831”; paragraph [0089], “the connection establishment response message for the primary connection 831 includes a session ID” i.e., the particulars of the primary connection establish the session; Application specification: paragraph [0053], “the request 302 is an add session request to establish a new RDMA session”) and the add QP request (Sen: paragraph [0088], “the initiator 822 may encapsulate an RDMA transport packet within an Ethernet/IP/UDP packet (including either IPv4 or IPv6) where…the source UDP port field is populated with a randomly generated number for the QP”) …
Sen, Bhabbur and Mellanox and Ravich do not teach …are transmitted along an encryption channel.
However, in the same field of endeavor, Pan does teach (Pan: paragraph [0017], “to send and receive the control information (e.g., configuration information)…Control-plane channel 101/102 may be established between SDN controller 170 and host 110A/110B using TCP over Secure Sockets Layer (SSL)” i.e., TCP over SSL is an encrypted channel and is used to transmit configuration data; paragraph [0029], “establishing an RDMA-based connection between source host-A 110A and destination host-B 110B”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the communication channel for the connection establishment request message for the primary connection of Sen, Bhabbur and Mellanox and Ravich to incorporate the teachings of Pan to use SSL to secure the control-plane communication channel. The motivation for doing so is to increase the security of the system (Pan: paragraph [0017], “TCP over Secure Sockets Layer (SSL)”).
References Cited
Iizuka et al. (USP App Pub 2016/0028859; hereinafter Iizuka) is cited to show that it is common knowledge and well known in the prior art that an IP packet includes particular structure that begins prior to UDP port header information (Iizuka: FIG. 10B; paragraph [0075], “an IP packet including a User Datagram Protocol (UDP) header as depicted in FIG. 10B”).
Davis et al. (USP App. Pub. 2002/0087720; hereinafter Davis) is cited to show that it is common knowledge and well known in the prior art that an RDMA connection transmits data across an application layer (Davis: paragraph [0022], “the user or application layer 200 may…[use]…an IBA kernel agent 280”; paragraph [0019], “InfiniBand architecture defines interfaces…[to]…send or receive operations, as well as, remote direct memory access (RDMA) read and RDMA write operations”; paragraph [0022], “InfiniBand architecture (IBA)”; paragraph [0022], “bypass the OS file system 230 and channel driver 240”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ADITYA SRIRAM whose telephone number is (703)756-1715. The examiner can normally be reached M-Sa: 9:00 AM - 5:00 PM MST or PST.
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, William Korzuch can be reached at (571) 272-7589. 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.
/A.S./ Examiner, Art Unit 2491
/WILLIAM R KORZUCH/ Supervisory Patent Examiner, Art Unit 2491
Prosecution Insights