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 .
Priority
Examiner acknowledges the instant application’s status as a divisional application relative to parent application 18/194413 and the prosecution history of that application.
Election/Restrictions
Restriction to one of the following inventions is required under 35 U.S.C. 121:
I. Claims 1-7 and 18-20, drawn to a scatter network device, classified in CPC H04L 67/145.
II. Claims 8-17, drawn to a scatter network, classified in CPC H04L 45/245.
The inventions are independent or distinct, each from the other because:
Inventions I and II are related as subcombinations disclosed as usable together in a single combination. The subcombinations are distinct if they do not overlap in scope and are not obvious variants, and if it is shown that at least one subcombination is separately usable. In the instant case, subcombination I has separate utility such as sending a heartbeat packet via a logical communication channel when the logical communication channel has been idle for a predefined period of time and subcombination II has separate utility such as a first scatter network node scattering data packets received from a data messaging source to a counterpart scatter network node and a first scatter network relay receiving a second plurality of data packets from the first scatter network node and scattering the second plurality of data packets to the counterpart scatter network node. See MPEP § 806.05(d).
The examiner has required restriction between subcombinations usable together. Where applicant elects a subcombination and claims thereto are subsequently found allowable, any claim(s) depending from or otherwise requiring all the limitations of the allowable subcombination will be examined for patentability in accordance with 37 CFR 1.104. See MPEP § 821.04(a). Applicant is advised that if any claim presented in a divisional application is anticipated by, or includes all the limitations of, a claim that is allowable in the present application, such claim may be subject to provisional statutory and/or nonstatutory double patenting rejections over the claims of the instant application.
Restriction for examination purposes as indicated is proper because all the inventions listed in this action are independent or distinct for the reasons given above and there would be a serious search and/or examination burden if restriction were not required because one or more of the following reasons apply:
As can be seen, each of the subcombinations are distinct and have separate utility involving the context of a scatter network, its nodes, devices, and relays and methods of secure data usable together that, individually searching the claimed inventions, would create a serious search and examination burden if restriction were not required.
Applicant is advised that the reply to this requirement to be complete must include (i) an election of an invention to be examined even though the requirement may be traversed (37 CFR 1.143) and (ii) identification of the claims encompassing the elected invention.
The election of an invention may be made with or without traverse. To reserve a right to petition, the election must be made with traverse. If the reply does not distinctly and specifically point out supposed errors in the restriction requirement, the election shall be treated as an election without traverse. Traversal must be presented at the time of election in order to be considered timely. Failure to timely traverse the requirement will result in the loss of right to petition under 37 CFR 1.144. If claims are added after the election, applicant must indicate which of these claims are readable upon the elected invention.
Should applicant traverse on the ground that the inventions are not patentably distinct, applicant should submit evidence or identify such evidence now of record showing the inventions to be obvious variants or clearly admit on the record that this is the case. In either instance, if the examiner finds one of the inventions unpatentable over the prior art, the evidence or admission may be used in a rejection under 35 U.S.C. 103 or pre-AIA 35 U.S.C. 103(a) of the other invention.
During a telephone conversation with Elexis Jones (Reg. No. 66,274) on 4 March 2025, a provisional election was made without traverse to prosecute the invention of subcombination II, claims 8-17. Affirmation of this election must be made by applicant in replying to this Office action. Claims 1-7 and 18-20 are withdrawn from further consideration by the examiner, 37 CFR 1.142(b), as being drawn to a non-elected invention.
Applicant is reminded that upon the cancelation of claims to a non-elected invention, the inventorship must be corrected in compliance with 37 CFR 1.48(a) if one or more of the currently named inventors is no longer an inventor of at least one claim remaining in the application. A request to correct inventorship under 37 CFR 1.48(a) must be accompanied by an application data sheet in accordance with 37 CFR 1.76 that identifies each inventor by his or her legal name and by the processing fee required under 37 CFR 1.17(i).
Claim Objections
Claim 17 is objected to because of the following informalities:
Claim 17 does not end with a period. All claims are to end with a period. See MPEP § 608.01(m) ("Each claim begins with a capital letter and ends with a period.").
Appropriate correction is required.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 8-13 and 17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 11178262 B2 to Goel et al. (“Goel”).
Regarding claim 8, Goel taught a scatter network, comprising:
a first scatter network node (“access node”) comprising a first non-transitory memory, at least a first processor, and a scatter network node application stored in the first non-transitory memory that, when executed by the at least the first processor of the first scatter network node,
establishes (by sending a “FCP request packet”) a first plurality of logical communication channels (“multiple”/”M” “parallel data paths”/”paths”), wherein each logical communication channel of the first plurality of logical communication channels associates a source Internet protocol (IP) address and a destination IP address, and scatters (“sprays”) a first plurality of data packets received from a data messaging source (“source” “node”/”server”) across the first plurality of logical communication channels by sending at least some of the first plurality of received data packets via different ones of the first plurality of logical communication channels to a counterpart scatter network node (“destination node”); (consider column 1, lines 44-60, “Example implementations of a new data transmission protocol, referred to generally herein as a fabric control protocol, are described for use within a data center or other computing environment. As one example, the fabric control protocol may provide certain advantages in environments in which a switch fabric provides full mesh interconnectivity such that any of the servers may communicate packet data for a given packet flow to any other of the servers using any of a number of parallel data paths within the data center switch fabric. As further described herein, example implementations of the fabric control protocol enable spraying of individual packets for a given packet flow across some or all of the multiple parallel data paths in the data center switch fabric and, optionally, reordering of the packets for delivery to the destination. In some examples, the fabric control protocol packet structure is carried over an underlying protocol, such as the User Datagram Protocol (UDP).”) (consider further generally Fig. 2 and column 11, line 16-column 12, 24 regarding the “spraying” of “packet of individual packet flows” “across” “all or a subset” of “M paths”, specifically column 11, lines 37-55, “In some example implementations, each access node 17 may, therefore, have multiple parallel data paths for reaching any given other access node 17 and the servers 12 reachable through those access nodes. In some examples, rather than being limited to sending all of the packets of a given flow along a single path in the switch fabric, switch fabric 14 may be configured such that access nodes 17 may, for any given packet flow between servers 12, spray the packets of the packet flow across all or a subset of the M parallel data paths of switch fabric 14 by which a given destination access node 17 for a destination server 12 can be reached. According to the disclosed techniques, access nodes 17 may spray the packets of individual packet flows across the M paths end-to-end forming a virtual tunnel between a source access node and a destination access node. In this way, the number of layers included in switch fabric 14 or the number of hops along the M parallel data paths, may not matter for implementation of the packet spraying techniques described in this disclosure.”) (consider further column 20, line 57-column 21, line 37 regarding the “fabric control protocol”/”FCP” and the use of a “request message” to request “permission before transmitting a packet on the fabric to a destination node”) (consider further column 28, lines 4-10, “An example of how an IP packet entering FCP tunnel 100 at a source end point is transmitted to a destination end point is described here. A source server 12 having an IP address of A0 sends an IP packet for a destination server 12 having an IP address of B0. The source FCP endpoint, e.g., access node 17.sub.1 within first logical rack 60.sub.1, transmits an FCP request packet with source IP address A and destination IP address B.”) and
a first scatter network relay (“intermediate” “TOR device”/”TOR Ethernet switch”) comprising a second non-transitory memory, at least a second processor, and a scatter network relay application stored in the second non-transitory memory that, when executed by the at least the second processor of the first scatter network relay, establishes a second plurality of logical communication channels (“second-stage” “spray” including a “second-level”/”multi-level” network fanout”), wherein each logical communication channel of the second plurality of logical communication channels associates a source Internet protocol (IP) address and a destination IP address, receives a second plurality of data packets from the first scatter network node via one of the first plurality of logical communication channels, wherein the second plurality of data packets is a sub-set of the first plurality of data packets, and scatters the second plurality of data packets across the second plurality of logical communication channels by sending at least some of the second plurality of data packets via different ones of the second plurality of logical communication channels to the counterpart scatter network node. (consider further column 21, lines 27-44, “In some cases, SX component 32 may spray its bandwidth across eight links to four or eight intermediate devices, e.g., TOR Ethernet switches, electrical permutation devices, or optical permutation devices, which in turn forward traffic to the core switches. For non-FCP traffic, SX component 32 is configured to select one of the core switches to which to send packets of the same packet flow. Since the incoming bandwidth to SX component 32 and the outgoing bandwidth from SX component 32 is same (e.g., 200 Gbps), congestion should not occur at the SX stage even for a large number of packet flows. DX component 34 of access node 17 may receive incoming packets from multiple core switches either directly or via one or more intermediate devices, e.g., TOR Ethernet switches, electrical permutation devices, or optical permutation devices. For example, DX component 34 may receive incoming packets from eight core switches, or four or eight intermediate devices.”) (consider column 24, lines 31-40, “Although illustrated in FIG. 8 as occurring directly between the access nodes 17 and the core switches 22, the second-level fanout may be performed through one or more TOR devices, such as top of rack Ethernet switches, optical permutation devices, or electrical permutation devices. The multi-level network fanout enables packets of a traffic flow received at any of the access nodes 17 within the first logical rack 60.sub.1 to reach core switches 22 for further forwarding to any of the access nodes 17 within the second logical rack 602.”) (consider further column 26, lines 11-27, “Although illustrated in FIG. 8 as occurring directly between the core switches 22 and destination access node 17.sub.1 of second logical rack 602, the core switches 22 may forward all the packets for the same traffic flow to an intermediate TOR device that has connectivity to the destination node. In some examples, the intermediate TOR device may forward all the packet for the traffic flow directly to DX component 34A implemented by access node 17.sub.1 of second logical rack 602. In other examples, the intermediate TOR device may be an optical or electrical permutation device configured to provide another fanout over which the packets can be sprayed between input and output ports of the permutation device. In this example, all or some portion of the DX components 34 of access nodes 17 of second logical rack 602 may receive sprayed packets of the same traffic flow.”)
Regarding claim 9, Goel taught the scatter network of claim 8, further comprising a second scatter network relay that establishes a third plurality of logical communication channels, wherein each logical communication channel of the third plurality of logical communication channels associates a source IP address and a destination IP address, and wherein one of the
second plurality of logical communication channels associates its destination IP address
to an IP address designating the second scatter network relay and wherein at least one of
the third plurality of logical communication channel associates its destination IP address
to an IP address designating the counterpart scatter network node. (again, consider further column 21, lines 27-44, “In some cases, SX component 32 may spray its bandwidth across eight links to four or eight intermediate devices, e.g., TOR Ethernet switches, electrical permutation devices, or optical permutation devices, which in turn forward traffic to the core switches. For non-FCP traffic, SX component 32 is configured to select one of the core switches to which to send packets of the same packet flow. Since the incoming bandwidth to SX component 32 and the outgoing bandwidth from SX component 32 is same (e.g., 200 Gbps), congestion should not occur at the SX stage even for a large number of packet flows. DX component 34 of access node 17 may receive incoming packets from multiple core switches either directly or via one or more intermediate devices, e.g., TOR Ethernet switches, electrical permutation devices, or optical permutation devices. For example, DX component 34 may receive incoming packets from eight core switches, or four or eight intermediate devices.”) (consider column 24, lines 31-40, “Although illustrated in FIG. 8 as occurring directly between the access nodes 17 and the core switches 22, the second-level fanout may be performed through one or more TOR devices, such as top of rack Ethernet switches, optical permutation devices, or electrical permutation devices. The multi-level network fanout enables packets of a traffic flow received at any of the access nodes 17 within the first logical rack 60.sub.1 to reach core switches 22 for further forwarding to any of the access nodes 17 within the second logical rack 602.”)
Regarding claim 10, Goel taught the scatter network of claim 8, wherein the first scatter network node is a laptop computer, a smart phone, a desktop computer, a tablet computer, or a notebook computer. (consider column 9, lines 16-39, specifically “Access nodes 17 may also be referred to as data processing units (DPUs), or devices including DPUs…In example implementations, access nodes 17 are configurable to operate in a standalone network appliance having one or more access nodes. For example, access nodes 17 may be arranged into multiple different access node groups 19, each including any number of access nodes up to, for example, x access nodes 17.sub.1-17.sub.x. As such, multiple access nodes 17 may be grouped (e.g., within a single electronic device or network appliance), referred to herein as an access node group 19, for providing services to a group of servers supported by the set of access nodes internal to the device. In one example, an access node group 19 may comprise four access nodes 17, each supporting four servers so as to support a group of sixteen servers.”) (also consider column 8, lines 49-56, “Although not shown, data center 10 may also include, for example, one or more non-edge switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection, and/or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other network devices.”)
Regarding claim 11, Goel taught the scatter network of claim 8, wherein the counterpart scatter network node is a server computer. (consider column 9, lines 16-39, specifically “Access nodes 17 may also be referred to as data processing units (DPUs), or devices including DPUs…In example implementations, access nodes 17 are configurable to operate in a standalone network appliance having one or more access nodes. For example, access nodes 17 may be arranged into multiple different access node groups 19, each including any number of access nodes up to, for example, x access nodes 17.sub.1-17.sub.x. As such, multiple access nodes 17 may be grouped (e.g., within a single electronic device or network appliance), referred to herein as an access node group 19, for providing services to a group of servers supported by the set of access nodes internal to the device. In one example, an access node group 19 may comprise four access nodes 17, each supporting four servers so as to support a group of sixteen servers.”) (also consider column 8, lines 22-31 and 49-56, “In this example, data center 10 includes a set of storage systems and application servers 12 interconnected via a high-speed switch fabric 14. In some examples, servers 12 are arranged into multiple different server groups, each including any number of servers up to, for example, n servers 12.sub.1-12.sub.n. Servers 12 provide computation and storage facilities for applications and data associated with customers 11 and may be physical (bare-metal) servers, virtual machines running on physical servers, virtualized containers running on physical servers, or combinations thereof…Although not shown, data center 10 may also include, for example, one or more non-edge switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection, and/or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other network devices.”)
Regarding claim 12, Goel taught the scatter network of claim 8, wherein the counterpart scatter network node is a virtual server in a cloud computing environment. (consider column 9, lines 16-39, specifically “Access nodes 17 may also be referred to as data processing units (DPUs), or devices including DPUs…In example implementations, access nodes 17 are configurable to operate in a standalone network appliance having one or more access nodes. For example, access nodes 17 may be arranged into multiple different access node groups 19, each including any number of access nodes up to, for example, x access nodes 17.sub.1-17.sub.x. As such, multiple access nodes 17 may be grouped (e.g., within a single electronic device or network appliance), referred to herein as an access node group 19, for providing services to a group of servers supported by the set of access nodes internal to the device. In one example, an access node group 19 may comprise four access nodes 17, each supporting four servers so as to support a group of sixteen servers.”) (also consider column 8, lines 22-31 and 49-56, “In this example, data center 10 includes a set of storage systems and application servers 12 interconnected via a high-speed switch fabric 14. In some examples, servers 12 are arranged into multiple different server groups, each including any number of servers up to, for example, n servers 12.sub.1-12.sub.n. Servers 12 provide computation and storage facilities for applications and data associated with customers 11 and may be physical (bare-metal) servers, virtual machines running on physical servers, virtualized containers running on physical servers, or combinations thereof…Although not shown, data center 10 may also include, for example, one or more non-edge switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection, and/or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other network devices.”)
Regarding claim 13, Goel taught the scatter network of claim 8, wherein the first plurality of data packets comprise scattering application datagrams (“packet flows” from “applications”). (again, consider column 1, lines 44-60, “Example implementations of a new data transmission protocol, referred to generally herein as a fabric control protocol, are described for use within a data center or other computing environment. As one example, the fabric control protocol may provide certain advantages in environments in which a switch fabric provides full mesh interconnectivity such that any of the servers may communicate packet data for a given packet flow to any other of the servers using any of a number of parallel data paths within the data center switch fabric. As further described herein, example implementations of the fabric control protocol enable spraying of individual packets for a given packet flow across some or all of the multiple parallel data paths in the data center switch fabric and, optionally, reordering of the packets for delivery to the destination. In some examples, the fabric control protocol packet structure is carried over an underlying protocol, such as the User Datagram Protocol (UDP).”) (consider also column 49, lines 25-28, “Once the logical tunnel is established, one of the access nodes (referred to as the ‘source access node’ in FIG. 21) may receive outbound packets associated with the same packet flow, e.g., from an application or storage source server 12 (512).”),
wherein a portion of the scattering application datagrams are encrypted. (consider column 46, lines 31-48, “In examples where the FCP control software provides end-to-end encryption and authentication for tunnels, a control protocol may handle the creation and distributions of keys for use by the encryption algorithm. In these examples, the FCP frame format may include four distinct contiguous regions defined by whether the data is encrypted and/or authenticated. For example, the pre-FCP headers (e.g., the Ethernet header, the IP header except source address and destination address in the IP header, and the UDP header) are neither encrypted nor authenticated; the source address and destination address of the IP header, the FCP header, the FCP security header, and some payload (in the case of a data packet) are authenticated but not encrypted; the remaining payload is both encrypted and authenticated; and the ICV is appended to the frame. In this way, the block sequence numbers (e.g., RBN, GBN, DBN, and/or PSN) carried in the FCP header are authenticated but not encrypted.”)
Regarding claim 17, Goel taught the scatter network of claim 13, wherein the scatter application datagrams comprise a message authentication code (MAC) which is not encrypted (consider column 7, lines 45-49, “Thirteenth, in some examples, FCP supports security through encryption and end-to-end authentication. The FCP supports end-to-end privacy through encryption and also supports authentication for FCP packets protecting all the FCP specific protocol handshake.”) (consider further column 46, lines 7-9, “Each of the FCP packets may include an optional UDP header, and option FCP security header, and/or an optional integrity check value (ICV).”)
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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Goel.
Regarding claim 14, Goel taught the scatter network of claim 13, wherein each of the scattering application datagram comprises a header portion and a data portion (consider column 46, lines 3-6, “FIGS. 18-19 illustrate example formats of FCP packets. In these examples, each of the FCP packets includes at least an Ethernet header, an IP header, and an FCP header. The FCP data packet format of FIG. 19 also includes a data payload.”), and
wherein a portion of the header portion of the scattering application datagram is encrypted. (consider column 46, lines 31-48, “In examples where the FCP control software provides end-to-end encryption and authentication for tunnels, a control protocol may handle the creation and distributions of keys for use by the encryption algorithm. In these examples, the FCP frame format may include four distinct contiguous regions defined by whether the data is encrypted and/or authenticated. For example, the pre-FCP headers (e.g., the Ethernet header, the IP header except source address and destination address in the IP header, and the UDP header) are neither encrypted nor authenticated; the source address and destination address of the IP header, the FCP header, the FCP security header, and some payload (in the case of a data packet) are authenticated but not encrypted; the remaining payload is both encrypted and authenticated; and the ICV is appended to the frame. In this way, the block sequence numbers (e.g., RBN, GBN, DBN, and/or PSN) carried in the FCP header are authenticated but not encrypted.”)
Goel may be interpreted as not expressly teaching wherein the data portion of the scattering application datagram is encrypted, however, Goel did teach wherein at least a portion of the scattering application datagram is encrypted and also suggests that the header portion or data portion of may be encrypted or not encrypted. (again, consider column 46, lines 31-48, specifically “In examples where the FCP control software provides end-to-end encryption and authentication for tunnels, a control protocol may handle the creation and distributions of keys for use by the encryption algorithm. In these examples, the FCP frame format may include four distinct contiguous regions defined by whether the data is encrypted and/or authenticated. For example, the pre-FCP headers (e.g., the Ethernet header, the IP header except source address and destination address in the IP header, and the UDP header) are neither encrypted nor authenticated; the source address and destination address of the IP header, the FCP header, the FCP security header, and some payload (in the case of a data packet) are authenticated but not encrypted; the remaining payload is both encrypted and authenticated; and the ICV is appended to the frame. In this way, the block sequence numbers (e.g., RBN, GBN, DBN, and/or PSN) carried in the FCP header are authenticated but not encrypted.”)
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to modify the teachings of Goel wherein the data portion of the scattering application datagram is encrypted such that the modification includes every element as claimed. Goel expressly suggests that either the header or payload portions of the scattering application datagram may be encrypted or not encrypted, therefore, one skilled in the art would have been motivated to modify the teachings of Goel with its express suggestion to do so such that the data portion of the scattering application datagram is encrypted as claimed. Therefore, such a modification of the teachings of Goel given its express suggestion would have yielded nothing more than predictable results to one of ordinary skill in the art.
Regarding claim 15, Goel taught the scatter network of claim 14, wherein the header portion of the scattering application datagram comprises an identity token which is not encrypted. (consider column 27, lines 51-56, “When the source node is communicating with the destination node, the source node encapsulates the packets using an FCP over UDP encapsulation. The FCP header carries fields identifying tunnel IDs, queue IDs, packet sequence numbers (PSNs) for packets, and request, grant, and data block sequence numbers between the two end points.”) (consider column 46, lines 31-48, “In examples where the FCP control software provides end-to-end encryption and authentication for tunnels, a control protocol may handle the creation and distributions of keys for use by the encryption algorithm. In these examples, the FCP frame format may include four distinct contiguous regions defined by whether the data is encrypted and/or authenticated. For example, the pre-FCP headers (e.g., the Ethernet header, the IP header except source address and destination address in the IP header, and the UDP header) are neither encrypted nor authenticated; the source address and destination address of the IP header, the FCP header, the FCP security header, and some payload (in the case of a data packet) are authenticated but not encrypted; the remaining payload is both encrypted and authenticated; and the ICV is appended to the frame. In this way, the block sequence numbers (e.g., RBN, GBN, DBN, and/or PSN) carried in the FCP header are authenticated but not encrypted.”)
Regarding claim 16, Goel taught the scatter network of claim 14, wherein the header portion of the scattering application datagram comprises a message count and a message type. (consider column 27, lines 51-56, “When the source node is communicating with the destination node, the source node encapsulates the packets using an FCP over UDP encapsulation. The FCP header carries fields identifying tunnel IDs, queue IDs, packet sequence numbers (PSNs) for packets, and request, grant, and data block sequence numbers between the two end points.”) (again, consider column 28, lines 4-24, “An example of how an IP packet entering FCP tunnel 100 at a source end point is transmitted to a destination end point is described here. A source server 12 having an IP address of A0 sends an IP packet for a destination server 12 having an IP address of B0. The source FCP endpoint, e.g., access node 17.sub.1 within first logical rack 60.sub.1, transmits an FCP request packet with source IP address A and destination IP address B. The FCP request packet has an FCP header to carry the Request Block Number (RBN) and other fields. The FCP request packet is transmitted over UDP over IP. The destination FCP end point, e.g., access node 17.sub.1 within second logical rack 602, sends an FCP grant packet back to the source FCP end point. The FCP grant packet has an FCP header to carry the Grant Block Number (GBN) and other fields. The FCP grant packet is transmitted over UDP over IP. The source end point transmits the FCP data packet after receiving the FCP grant packet. The source end point appends a new (IP+UDP+FCP) data header on the input data packet. The destination end point removes the appended (IP+UDP+FCP) data header before delivering the packet to the destination host server.”)
Goel may be interpreted as not expressly teaching wherein the header portion of the scattering application datagram is encrypted, however, Goel did teach wherein at least a portion of the scattering application datagram is encrypted and also suggests that the header portion or data portion may be encrypted or not encrypted. (again, consider column 46, lines 31-48, specifically “In examples where the FCP control software provides end-to-end encryption and authentication for tunnels, a control protocol may handle the creation and distributions of keys for use by the encryption algorithm. In these examples, the FCP frame format may include four distinct contiguous regions defined by whether the data is encrypted and/or authenticated. For example, the pre-FCP headers (e.g., the Ethernet header, the IP header except source address and destination address in the IP header, and the UDP header) are neither encrypted nor authenticated; the source address and destination address of the IP header, the FCP header, the FCP security header, and some payload (in the case of a data packet) are authenticated but not encrypted; the remaining payload is both encrypted and authenticated; and the ICV is appended to the frame. In this way, the block sequence numbers (e.g., RBN, GBN, DBN, and/or PSN) carried in the FCP header are authenticated but not encrypted.”)
The motivations regarding the obviousness of claim 14 also apply to claim 16, therefore, claim 16 is rejected under 35 USC § 103 as being unpatentable over the combined teachings of Goel and the same rationale supporting the conclusion of obviousness.
Conclusion
An updated search did not reveal additional prior art that is relevant to the claimed invention or to the broader disclosure than of what is already of record within the prosecution history of the instant application including its parent.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to G. C. Neurauter, Jr. whose telephone number is (571)272-3918. The examiner can normally be reached Monday-Friday 9am-5pm Eastern Time.
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, Tonia Dollinger, can be reached at 571-272-4170. 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.
/G. C. Neurauter, Jr./Primary Examiner, Art Unit 2459