DETAILED ACTION
This action is in response to communication filed on 8/3/2026.
Claims 1-26 are pending.
Claims 1, 6, 8, 11, and 17 have been amended.
Claims 26 have been added.
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 directed to the newly amended limitation of claims 1 and 17, that each distributed processing task has a respective task-specific master key generated by an orchestration node and distributed to the nodes by the orchestration node have been considered but are moot in view of the new ground of rejection. That amended limitation, and new claim 26, are now taught by Yang ’981 as mapped below.
Applicant’s remaining arguments directed to Menachem, Yang ’785, and Diamant as applied to the unamended elements are not persuasive.
Yang ’785 remains the reference relied upon for computing task-and-node-specific communication keys from a master key and node-specific data. Yang ’785 [0020] teaches: “Each VPN manager 110 generates a session key as a function of the master key, the GUID of a source network node, and the GUID of a destination network node.” That teaching was not traversed on the merits and is unchanged by the amendment.
Menachem remains the reference relied upon for the NIC-based secure distributed node fabric. Menachem does not need to teach the amended orchestration/task-key language, that language is now supplied by Yang ’981.
Diamant remains the reference relied upon for different IVs / key lifespan. Diamant is not relied upon to teach the amended limitation.
Dependent claims 2–16 and 18–25 are not allowable by dependency because claims 1 and 17 remain rejected. New claim 26 is rejected on the combination set forth below. Claims 7, 11, 20, and 24 remain objected to as containing allowable subject matter if rewritten in independent form including all limitations of the base claim and any intervening claims. Interview comments are not binding. See MPEP 713.04.
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 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 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1-3, 12, 17 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Menachem et al. (US 2019/0190892) in view of Yang et al. (US 2018/0097785) in view of Yang et al. (US 2020/0127981).
Regarding claim 1, Menachem discloses a secure distributed processing system, comprising a plurality of nodes connected over a network, and configured to process a plurality of tasks, each one of the nodes including: a processor to process task-specific data; and a network interface controller (NIC) to:
connect to other ones of the nodes over the network (Menachem discloses a NIC that connects the host nodes (and their VMs) over the packet data network for inter-node communication; [0041] “NIC 32 comprises a host interface, such as a PCIe interface, which connects to bus 33 of host computer 22, and a network interface, comprising one or more ports 62 connected to network 28”); and
securely communicate the processed task-specific data with the ones of the nodes over the network based on the task-and-node-specific communication keys (Menachem disclose the NIC’s cryptographic hardware logic applies IPsec security (encryption/authentication) to the processed data packets using the keys/state context, enabling secure communication between nodes; [0032] “VM 2 in host 22 communicates with VM 3 in host 24 via an IPsec tunnel 46 between the respective NICs 32”, [0042] “Packet processing hardware logic 64 also comprises cryptographic security hardware logic module 44, which is configured, when invoked by IPsec software module 54, to apply IPsec security functions to the data packets transmitted and received by Tx pipe 66 and Rx pipe 68”).
However, the prior art does not explicitly disclose compute task-and-node-specific communication keys for securing communication with ones of the nodes over the network based on task- specific master keys and node-specific data.
Yang ‘785 in the field of the same endeavor discloses techniques of key management for encryption of traffic in a network having a network node. In particular, Yang teaches the following:
compute task-and-node-specific communication keys for securing communication with ones of the nodes over the network based on task- specific master keys and node-specific data (Yang ‘785 discloses a two tier key architecture in which a master key is generated per security group (mapped to a task or set of tasks) and each node locally computes a unique session/communication key as a function of that master key plus the GUIDs of the source and destination node (node specific data); Yang ’785 [0017] “In response to establishing security group 108, VPN group manager 114 requests key management server 106 to generate a master key for security group 108” and [0020] “Each VPN manager 110 generates a session key as a function of the master key, the GUID of a source network node, and the GUID of a destination network node”, [0020] “Each VPN manager 110 generates a session key as a function of the master key, the GUID of a source network node, and the GUID of a destination network node”, [0032] “At step 604, VPN manager 110 generates a session key using a function of the master key, the GUID of the source network node, and the GUID of the destination network node”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the prior art with the teaching of Yang. Yang ‘785 teaches that its approach “obviating the need for a key exchange protocol, such as Internet Key Exchange (IKE)” and enables “unique sessions are established between source and destination network nodes” using only a shared master key plus node GUIDs (see Yang [0020]). One would have been motivated to combine the teachings to achieve scalable, efficient, secure communication in a distributed multi-task environment without per-pair key negotiation. The combination yields predictable results with no unexpected issues.
However the prior art does not explicitly disclose a plurality of nodes connected over a network, and configured to process a plurality of distributed processing tasks, wherein each of the distributed processing tasks has a respective one of a plurality of task-specific master keys generated by an orchestration node and distributed to the nodes by the orchestration node.
Yang ‘981 in the field of the same endeavor discloses techniques or secure communications among tenant virtual machines in a cloud networking environment. In particular Yang ‘981 teaches the following:
a plurality of nodes connected over a network, and configured to process a plurality of distributed processing tasks, wherein each of the distributed processing tasks has a respective one of a plurality of task-specific master keys generated by an orchestration node and distributed to the nodes by the orchestration node (Yang ’981 teaches a controller/key manager that creates a respective encryption key for each tenant and distributes that key to the NIC on each node that processes that tenant’s VMs. Under BRI, a tenant’s processes are a distributed processing task and the controller is an orchestration node, [0034]: “An embodiment includes a key management component corresponding to each tenant of a cloud computing environment. When a new tenant VM is created, the embodiment sends the current key for that tenant, including a key ID and a key value, to the SmartNIC on the host, binds the current key to a VF, and enables IPSec on the VF”, [0035]: “An embodiment need only use one key to encrypt all traffic among VMs of one tenant. In contrast, traditional IPSec in the cloud environment requires one key for each direction of traffic of each VM pair”, [0078]: “Controller 500 includes key manager 510 and network monitor 520. Key manager 510 provides centralized key management, including key updating, expiration, and revocation”, Yang ’981 [0079]: “When a new tenant VM—for example, VM 611 running on host 610—is created, key manager 510 sends the current key for that tenant, including a key ID and a key value, to virtual NIC 631 running on host 610”, Yang ’981 [0083]: “controller 640 (which is the same as controller 500 in FIG. 5) distributes key 650 to network nodes 602 for distribution to any of virtual NICs 631, 632, and 633”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Yang ‘981. One would have bee motivated to provision the master keys of Menachem–Yang ’785 on a per-tenant (or per-tenant-workload) basis using Yang ’981’s controller. Menachem already runs VMs of multiple hosts over NIC IPsec. Yang ’785 already uses a central key server and a respective master key per group. Yang ’981 teaches that in a multi-tenant environment the controller should create and push a respective key per tenant onto the NIC so hosts that concurrently run different tenants isolate tenant traffic without a pair-wise IKE mesh. See Yang ’981 [0078-0079, 0083]. Applying that grouping criterion to Yang ’785’s master keys yields the amended claim 1 system with a predictable result.
Regarding claim 2, Menachem-Yang’785-Yang’981 discloses the system according to claim 1, wherein the NIC is to:
compute task-and-node-pair-specific communication keys based on node-pair specific data (Yang ‘785 [0020] “Each VPN manager 110 generates a session key as a function of the master key, the GUID of a source network node, and the GUID of a destination network node… A key exchange protocol is not necessary, since each end of the tunnel can generate the same session key from the master key, the source GUID, and the destination GUID”, [0032] “At step 604, VPN manager 110 generates a session key using a function of the master key, the GUID of the source network node, and the GUID of the destination network node”); and
securely communicate the processed task-specific data with the ones of the nodes over the network based on the task-and-node-pair-specific communication keys (Yang ‘785 [0033-0034] “the network stack encrypts traffic using the session key and sends the encrypted traffic to the destination node through the point-to-point tunnel… A source network node can repeat method 600 to establish multiple point-to-point tunnels with multiple destination nodes. The source network node uses a unique session key for each established point-to-point tunnel based on the different GUIDs of the destination network nodes”).
Regarding claim 3, Menachem-Yang’785-Yang’981 discloses the system according to claim 2, wherein the node-pair specific data is based on address information of a pair of the nodes (Yang ‘785 [0032] “VPN manager 110 generates a session key using a function of the master key, the GUID of the source network node, and the GUID of the destination network node”).
Regarding claim 12, Menachem-Yang’785-Yang’981 discloses the system according to claim 1, wherein:
the NIC of a sender node of the nodes is to compute the task-and-node-specific communication keys based on the task-specific master keys and based on data that identifies the sender node (Yang ‘785 [0032] “At step 604, VPN manager 110 generates a session key using a function of the master key, the GUID of the source network node, and the GUID of the destination network node”); and
the NIC of a receiver node of the nodes is to:
receive encrypted data from the NIC of the sender node (Menachem [0017] “includes a cryptographic security hardware logic module, which is configured, when invoked by the embedded controller, to apply the cryptographic security protocol to the data packets transmitted and received by one or more of the applications while maintaining a state context of the cryptographic security protocol with respect to each of the one or more of the applications”);
compute a decryption key based on a given one of the task master keys and the data that identifies the sender node (Yang ‘785 [0036] “At step 706, VPN manager 110 generates the session key as a function of the master key, the source GUID, and the destination GUID. Thus, VPN manager 110 in the destination network node generates the same session key as VPN manager 110 in the source network node. At step 708, the network stack receives encrypted traffic from the source network node through the point-to-point tunnel”); and
decrypt the encrypted data based on the decryption key (Yang ‘785 [0036] “At step 710, the network stack decrypts the encrypted traffic using the session key”).
Regarding claim(s) 17, do(es) not teach or further define over the limitation in claim(s) 1 respectively. Therefore claim(s) 17 is/are rejected for the same rationale of rejection as set forth in claim(s) 1 respectively.
Regarding claim 26, Menachem-Yang’785-Yang’981 discloses the system according to claim 1, wherein the nodes are to process data for different tenants, and one of the distributed processing tasks represents processes performed for a respective one of the tenants (Yang ‘981 [0083] “Host 610 includes VM 611, belonging to tenant 1, and VM 621, belonging to tenant 2. Host 620 includes VM 612, belonging to tenant 1, and VM 622, belonging to tenant 2. Host 630 includes VM 613, belonging to tenant 1, and VM 623, belonging to tenant 2).
Claims 4-6, 8-10, 13-16, 18-19, 21-23, 25 are rejected under 35 U.S.C. 103 as being unpatentable over Menachem et al. (US 2019/0190892) in view of Yang et al. (US 2018/0097785) Diamant et al. (US 10,708,246).
Regarding claim 4, Menachem-Yang’785-Yang’981 discloses the invention substantially, however the prior art does not explicitly disclose the system according to claim 1, wherein the NIC is to secure communication of the task-specific data based on at least one of different initialization vectors (IVs) for different packets.
Diamant in the field of the same endeavor discloses techniques for performing encryption of outgoing packets, where the encryption module uses a different initialization vector for each packet. In particular, Diamant teaches the following:
wherein the NIC is to secure communication of the task-specific data based on at least one of different initialization vectors (IVs) for different packets (Diamant col. 3/lines 5-24; detx 16; “FIG. 1 illustrates an IV 100 formed using a source ID 10, a destination ID 12, and a packet sequence number 14. A packet sequence number (PSN) is a number that identifies an order in which a packet is transmitted from a sender to a receiver”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the prior art with the teaching of Diamant. One would have been motivated because Diamant’s teaching of using different initialization vectors (IVs) for different packets in order to ensure identical plaintext yields different ciphertext and thereby prevent an attacker from inferring underlying data patterns in the encrypted communication.
Regarding claim 5, Menachem-Yang’785-Yang’981-Diamant discloses the system according to claim 4, wherein the different IVs are based on values of a counter or a timer (Diamant col. 12/lines 65 – col. 13/lines 13; detx 56; “The encryption module 524 encrypts packets by applying an encryption algorithm, using an initialization vector determined based on the source ID of the sender and the packet sequence number assigned to the packet by the injection module 522” and col. 13/lines 61 – col. 14/lines 6; detx 60; “The PSN register 630 operates as a running counter that stores the current packet sequence number”).
Regarding claim 6, Menachem-Yang’785-Yang’981-Diamant discloses the system according to claim 4, further comprising an orchestration node to trigger use of secondary task-specific master keys by the nodes (Yang [0016] “The top tier is master key management infrastructure that is fully scalable and includes a centralized key manager (orchestration node). The bottom tier is a session key infrastructure that derives session keys from the master key in a manner that is independent of the master key management mechanism”) upon one of the nodes recovering from failure (Menachem [0069] “after VMM 40 has resolved the exception, hardware logic module 44 continues handling subsequent packets in the flow”).
Regarding claim 8, Menachem-Yang’785-Yang’981-Diamant discloses the system according to claim 4, further comprising an orchestration node to trigger use of secondary task-specific master keys by the nodes upon one of the nodes depleting initialization vector space (Diamant col. 3/lines 24-54; detx 17; “To maintain security, a key exchange should take place before the IV space is exhausted. In practice, keys are periodically swapped at a frequency determined based on the expected key lifespan”).
Regarding claim 9, Menachem-Yang’785-Yang’981-Diamant discloses the system according to claim 8, wherein the orchestration node is to designate the secondary task-specific master keys as primary task-specific master keys and provide new secondary task-specific master keys to the nodes (Diamant col. 16/lines 3-10; detx 72; “The network device may also be configured to estimate a lifespan of the encryption key, for example using the earlier described calculation based on network speed and sequence number length, and change to a new key prior to the end of the estimated lifespan. The network device may coordinate with one or more receivers to perform a key swap, for example, when the key is a shared secret”).
Regarding claim 10, Menachem-Yang’785-Yang’981-Diamant discloses the system according to claim 4, wherein the NIC is to compute task-and-node-specific communication keys based on the task-specific master keys (Yang [0014] “The bottom tier provides for generation of session keys locally at each network node and is fully scalable. The network nodes derive the session keys from the master key in a manner that is independent from the master key management technique” and [0020] “VPN managers 110 implement the bottom tier of the two-tier key management architecture. Each VPN manager 110 generates a session key as a function of the master key, the GUID of a source network node, and the GUID of a destination network node”) and a generation indicator (Menachem [0067] “context 70 also includes counters 72, which keep track of packet serial numbers, replay protection windows, and numbers of transmitted bytes and/or packets, as required by the IPsec protocol”).
Regarding claim 13, Menachem-Yang’785-Yang’981-Diamant discloses the system according to claim 12, wherein the data that identifies the sender node includes sender address information (Diamant col. 3/lines 4-23; detx 16; “FIG. 1 illustrates an IV 100 formed using a source ID 10, a destination ID 12, and a packet sequence number 14. A packet sequence number (PSN) is a number that identifies an order in which a packet is transmitted from a sender to a receiver. Generally, packet sequence numbers are formed by incrementing the previous sequence number by a fixed value, for example 1. The IV 100 is a digital value comprising a sequence of binary numbers, formed by concatenating the source ID 10, the destination ID 12, and the packet sequence number 14, in that order”).
Regarding claim 14, Menachem-Yang’785-Yang’981-Diamant discloses the system according to claim 12, wherein the NIC of the sender node is to secure communication of the task-specific data based on at least one of different initialization vectors (IVs) for different packets (Diamant col. 12/lines 56 – col. 13/lines 13; detx 56; “The injection module 522 updates the packet sequence number each time a packet is sent from one of the virtual machines to a device outside the network, and injects the packet sequence number into the packet. The packet sequence number is stored in the memory 526, which may be integrated into the injection module 522 or an external memory communicatively coupled to the injection module 522. The encryption module 524 encrypts packets by applying an encryption algorithm, using an initialization vector determined based on the source ID of the sender and the packet sequence number assigned to the packet by the injection module 522.”).
Regarding claim 15, Menachem-Yang’785-Yang’981-Diamant discloses the system according to claim 14, wherein the NIC of the receiver node is to: receive an initialization vector from the sender node (Diamant col. 15/lines 47 – col. 16/lines 3; detx 71; “The network device then encrypts the incoming packet, using the initialization vector and an existing encryption key as inputs to an encryption algorithm, and transmits the encrypted packet to the receiver device”); and
decrypt the encrypted data based on the decryption key and the received initialization vector (Diamant col. 16/lines 33-40; detx 75; “The network device then encrypts the incoming packet, using the initialization vector and an existing encryption key as inputs to an encryption algorithm, and transmits the encrypted packet to the receiver device”).
Regarding claim 16, Menachem-Yang’785-Yang’981-Diamant discloses the system according to claim 14, wherein the different IVs are based on values of a counter or a timer (Diamant col. 3/lines 5-23; detx 16; “FIG. 1 illustrates an IV 100 formed using a source ID 10, a destination ID 12, and a packet sequence number 14. A packet sequence number (PSN) is a number that identifies an order in which a packet is transmitted from a sender to a receiver. Generally, packet sequence numbers are formed by incrementing the previous sequence number by a fixed value, for example 1. The IV 100 is a digital value comprising a sequence of binary numbers, formed by concatenating the source ID 10, the destination ID 12, and the packet sequence number 14, in that order”).
Regarding claim(s) 18-19, 21-23, and 25, do(es) not teach or further define over the limitation in claim(s) 4, 6, 8-10, 12 respectively. Therefore claim(s) 18-19, 21-23, and 25 is/are rejected for the same rationale of rejection as set forth in claim(s) 4, 6, 8-10, 12 respectively
Allowable Subject Matter
Claims 7, 11, 20 and 24 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.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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.
For the reasons above, claims 1-6, 8-10, 12-19, 21-23, 25-26 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm 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, Chris Parry can be reached at 571-272-8328. 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.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451
Prosecution Insights