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 .
DETAILED ACTION
This Office Action is in response to the application 19/098,361 filed on 04/02/2025; claims 1, 12, 13, and 14 are independent claims. Claims 1-14 have been examined and are pending. This Action is made Non-FINAL.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. 24169377.9, filed on Apr. 10, 2024.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/02/2025 and 04/21/2025 is being considered by the examine
Drawing Objections
The drawings (Figures 1-6) are objected to under 37 CFR 1.83(a) because they fail to show the necessary labelling or explanations of figures, parts or steps as described in the specification. For example, Figs. 1-6 do not label any components, and/or do not briefly explain any method steps and/or components. In other words, these drawings lack the necessary structural detail that is essential for a proper understanding of the disclosed invention, which should have been shown in the drawing. MPEP § 608.02(d). Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification Objections
The disclosure is objected to because of the following informalities:
(a) Paragraphs [0012] and [0014] contain an embedded hyperlink and/or other form of browser-executable code (https://www.torproject.org and https://github.com/wangyu-/tinyfecVPN). Applicant is required to delete the embedded hyperlink and/or other form of browser-executable code, or amend the URL so that it is not an active hyperlink.
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Objections
Claim 7 is objected to because of the following informalities:
Regarding claim 7; claim 7 recites the phrases “the requested network service” in line 4. For better clarity and be consistency to claim 1, it is suggested that the claim be further amended as “the requested registered network service”. Appropriate correction is required.
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.
Claims 1, 7-8, and 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Ludwick (“Ludwick,” US 2013/0028257) in view of Fu et al. (“Fu,” US 2023/0327908), further in view of Roelvink, Yannick (“Roelvink,” EP 4346255).
Regarding claim 1, Ludwick teaches a computer-implemented method for transporting data between an end-user device and a server device for providing a network service via a time-varying network, the time-varying network including a plurality of nodes that are interconnected intermittently in time (Ludwick: abstract, pars. 0003-0004, 0022, 0025, 0028, and 0030) , the method comprising:
a) providing a plurality of gateway devices, each gateway device configured to connect to at least one node of the time-varying network (Ludwick: par. [0027]: "tactical application 120 is not directly accessible by gateway 130, so that gateway 130 sends the message to gateway 140... And in instances where there are multiple gateways (not shown) in the DTN network, gateway 140 may be chosen as a closest gateway to tactical application 120."; par. [0030]: "gateway 130 sends packet 300 to gateway 140 over tactical network 150 that runs DTN." [0028]: "gateways 130, 140 may each be connected by an IP network to multiple other tactical applications (not shown). Also, tactical network 150 may include more hops... so that a message may be routed through multiple DTN devices between gateways 130, 140."; par. [0043]: "The gateways 130, 140 of FIG. 1 are systems that include communication ports for receiving messages for a destination application by a first communication protocol and for sending the messages to a network endpoint according to a second communication protocol.");
c) requesting, by an end-user device, a registered network service at one of the gateway devices, said gateway device constituting an ingress gateway device (Ludwick: par. [0025]: "In some instances, tactical application 110 does not know the IP address of tactical application 120, in which case, tactical application 110 addresses the IP datagram with the message to the IP address of gateway 130."; par. [0026]: "Gateway 130 has IP network connectivity with tactical application 110, and gateway 130 receives the message sent by tactical application 110 using TCP/IP or UDP/IP... it includes a 47001C header 204, which has a URN of the second tactical application 120. The URN may include an alpha-numeric string that uniquely identifies the destination application 120"; par. [0023]: "the URN conforms to VMF 6017A rather than to TCP/IP, UDP/IP, or DTN."; par. [0035]: "a first gateway receives the message from the first application via the first communication protocol... the message includes data indicating a second application as a destination.")
d) selecting, by the ingress gateway device and representative for the end-user device, a gateway device having been indicated at least one connected server device for providing the requested registered network service as suitable server device, the selected gateway device constituting an egress gateway device (Ludwick: par. [0027]: "Gateway 130 strips the message of headers 206, 208 and maps the URN into a DTN namespace. In this example, tactical application 110 is unaware of the DTN network and does not include any DTN address data in the message. Furthermore, tactical application 120 is not directly accessible by gateway 130, so that gateway 130 sends the message to gateway 140. When gateway 130 maps the URN to a DTN namespace, it may use a lookup table or other algorithm to generate the DTN address of gateway 140. And in instances where there are multiple gateways (not shown) in the DTN network, gateway 140 may be chosen as a closest gateway to tactical application 120."; par. par. [0036]: "the first gateway generates a DTN endpoint address that happens to be associated with a second gateway that is accessible by the second application (the destination of the message)... One example includes the use of a look-up table that maps destinations to associated gateways."; Claim 1 of Ludwick: "generating a gateway address from the data indicating the destination, a gateway associated with the gateway address being accessible by the destination"; Claim 7 of Ludwick: "generating a gateway address comprises: using a look-up table to access the gateway address from the data indicating a destination.”);
f) transporting data between the end-user device and the corresponding server device (Ludwick: par. [0030]: "gateway 130 sends packet 300 to gateway 140 over tactical network 150 that runs DTN... DTN uses store and forward and Bundling Protocol (BP) to deliver packet 300 to gateway 140." par. [0031]: "When gateway 140 receives packet 300, it removes header 302 and looks at the URN in message 202. Gateway 140 maps the URN to an IP address of tactical application 120... The IP datagram then traverses an IP network to be delivered to tactical application 120." par. [0041]: "the second gateway sends the message to the destination application using the first communication protocol.").
Ludwick does not explicitly disclose b) registering one or more network services at the plurality of gateway devices by indicating, for each network service, to at least one of the gateway devices, respectively, at least one connected server device for providing said network service as suitable server device.
However, in an analogous art, Fu discloses b) registering one or more network services at the plurality of gateway devices by indicating, for each network service, to at least one of the gateway devices, respectively, at least one connected server device for providing said network service as suitable server device (Fu: Abstract: "the software framework includes an application service layer and a basic service layer, the application service layer includes at least one device service registered in advance"; par. [0007]: "the preset software framework is applicable to a gateway device, the preset software framework includes a plurality of device services registered in advance, and each of the device services corresponds to a capability of a device associated with the gateway device in current environment."; Abstract: "the external service includes a device service belonging to a same gateway device as the device service or a different gateway device than the device service."; [0003]: "in each home environment, more than one gateways are usually needed at the same time.");
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Fu and with the method and system of Ludwick to include b) registering one or more network services at the plurality of gateway devices by indicating, for each network service, to at least one of the gateway devices, respectively, at least one connected server device for providing said network service as suitable server device. One would have been motivated to register services in this manner at Ludwick's gateways, so that a gateway can identify which associated device provides a requested capability — extending the name-based look-up Ludwick already performs (Ludwick: pars. [0027], [0031]) — and thereby facilitate "the subsequent expansion of the gateway capability" (Fu: par. [0102]).
Further, the modification amounts to the use of a known technique to improve a similar device in the same way. Ludwick's gateways already maintain a look-up table associating a destination with the gateway through which that destination is accessible (Ludwick: pars. 0027], [0031], [0036]). Applying Fu's advance service registration to that same look-up function would have involved no more than ordinary skill and would have yielded the predictable result of a gateway that identifies a destination by the service it provides rather than by address alone.
Ludwick disclose f) transporting data between the end-user device and the corresponding server device but does not explicitly disclose e) establishing at least one end-to-end encrypted transport connection between the end-user device and a corresponding server device for providing the one or more network services and the requested registered network service via the ingress gateway device, the time-varying network, and the egress gateway device
However, in an analogous art, Roelvink discloses e) establishing at least one end-to-end encrypted transport connection between the end-user device and a corresponding server device for providing the one or more network services and the requested registered network service via the ingress gateway device, the time-varying network, and the egress gateway device (Roelvink: par. [0024]: “the user device 101 is configured to communicate with a destination server 113… the user device 101 is configured to communicate 115 with a secure router 103 which is located between the user device 101 and the first ground station 105.”; par. [0027]: “On receiving the data, the secure router 103 converts the data format to a general-purpose transport layer protocol, such as QUIC, and encrypts that data using an encryption method.”; par. [0046]: “The secure router 103 is configured to establish S401 a QUIC session that provides a data link between the secure router 103 and the secure server 111. The data link can be based on a QUIC transport-layer network protocol.”; par. [0028]: “The encrypted data from the secure router 103 are transmitted 117 to the first ground station 105, then to the satellite 107 and subsequently to the second ground station 109. From the second ground station 109, the encrypted data are transmitted 119 to a secure server 111.”; par. [0026]: “in embodiments where the user device 101 is remote from the secure router 103, data will typically be exchanged in encrypted form. Such encrypted exchange can be accomplished using a VPN.”: par. [0030]: “in embodiments where the destination server 113 is remote from the secure server 111, data will typically be exchanged in encrypted form.”: par. [0065]: “the shared key can remain valid until the communication between the user device 101 and the destination server 113 ceases.” in combination with Ludwick: pars. [0030], [0031], [0041]); and
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Roelvink with the method and system of Ludwick and Fu to include e) establishing at least one end-to-end encrypted transport connection between the end-user device and a corresponding server device for providing the one or more network services and the requested registered network service via the ingress gateway device, the time-varying network, and the egress gateway device; f) transporting data between the end-user device and the corresponding server device by the at least one end-to-end encrypted transport connection. One would have been motivated to encrypt Ludwick’s transport connection in this manner to protect the confidentiality of Ludwick’s tactical messages, which Ludwick transports unencrypted, without the latency penalty that keep satellite providers from encrypting (Roelvink: par. 0004).
Regarding claim 7, the combination of Ludwick, Fu, and Roelvink teaches the method according to claim 1. The combination of Ludwick, Fu, and Roelvonk further teaches the method according to claim 1, wherein step d) further comprises:
dl) querying, by the ingress gateway device and representative for the end-user device, at least one gateway device having been indicated at least one connected server device for providing the requested network service as suitable server device (Fu: [0098]: "the first device service can send a query message for querying the second device service to the data bus when the gateway device starts and/or detects that the current environment meets the condition for invoking the second device service in the preset software framework, and then determine the existence of the second device service when receiving the relevant information of the second device service replied by the data bus. When the relevant information of the second device service replied by the data bus is not received within the set time, it can be determined that the second device service does not exist."; par. [0038]: "the external service... is a device service belonging to a same gateway device as the device service or a different gateway device with the device service."; par. [0040]: "the transmission range of global topics may be different gateway devices, that is, to achieve cross-device transmission.": par. [0042]: "${domain_name} can be used to distinguish the scope of topics, and information such as device ID can be used for cross-device addressing.") ; and
d2) acknowledging, by the ingress gateway device and to the end-user device, a response of a corresponding server device based on the querying (Ludwick: Claim 8, "receiving an acknowledgement message by the second communication protocol from the destination via the gateway; and sending the acknowledgement message to the first application using the first communication protocol."; par. [0017]: "when the destination replies to the source with an acknowledgment message, the same processes are used to transport the acknowledgement message back to the originating application."; par. [0032]: "tactical application 120 may send an acknowledgement message back to tactical application 110, where the acknowledgement message is handled in the same manner as the original message (going from IP to DTN and back to IP)."; Fu: par. [0098]: "determine the existence of the second device service when receiving the relevant information of the second device service replied" to the query; par. [0100]: "the second device service can perform processing based on the received service invocation request information, and generate the service invocation response information based on the obtained processing result.") .
Regarding claim 8, the combination of Ludwick, Fu, and Roelvink teaches the method according to claim 1. The combinatio of Ludwick, Fu, and Roelvonk furthter teaches, wherein step b) further comprises:
bl) by the at least one of the gateway devices having been indicated at least one connected server device for providing the network service as suitable server device, announcing said network service to the plurality of gateway devices via the time-varying network (Fu: par. [0036] "The device service corresponds to a capability of a device associated with the gateway device."; par. [0038]: "The data bus may be used to realize the communication between the device service and an external service, which is a device service belonging to a same gateway device as the device service or a different gateway device with the device service."; par. [0039]: "the data bus may be used to realize invocation of the external service to the device service by subscribing to or publishing a preset topic; par. [0040]: "the topics subscribed or published between various device services may be divided into local topics and global topics... the transmission range of local topics may be within a same gateway device, while the transmission range of global topics may be different gateway devices, that is, to achieve cross-device transmission."; See also, pars. [0041]–[0042]: "the general format of the topic of this embodiment may be: ${domain_name}/${service_name}/${service_defined}/xxx... ${domain_name} can be used to distinguish the scope of topics, and information such as device ID can be used for cross-device addressing.": par. [0043]: "the data bus can also be used to discover other gateway devices around the gateway device and network with the discovered other gateway devices... each device can multicast its own device attribute information profile (that is, some attributes of the device itself, including its own ability, election priority and other information), and listen to the device attribute information profile of other devices at the same time."; Ludwick;; [0030]: "gateway 130 sends packet 300 to gateway 140 over tactical network 150 that runs DTN.": [0028]: "tactical network 150 may include more hops than are shown in FIG. 1, so that a message may be routed through multiple DTN devices between gateways 130, 140).
Regarding claim 12, claim 12 is directed to a network arrangement comprising: means for carrying out the method according to claim 1 (Ludwick: pars. 0022-0030; Figs. 1-3); Claim 12 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Regarding claim 13, claim 13 is directed to a gateway device configured for the network arrangement according to claim 12 (Ludwick: pars. 0022-0030; Figs. 1-3; gateways 130-140). Claim 12 is similar in scope to claim 12, and is therefore rejected under similar rationale.
Regarding claim 14, claim 14 is directed to a non-transitory computer readable medium storing a computer program comprising instructions which, when the computer program is executed by a network arrangement, cause the network arrangement to carry out the method of claim 1; claim 14 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Claims 2-5 are rejected under 35 U.S.C. 103 as being unpatentable over Ludwick (“Ludwick,” US 2013/0028257) in view of Fu et al. (“Fu,” US 2023/0327908), and Roelvink, Yannick (“Roelvink,” EP 4346255), further in view of M. Leech et al. (“Leech,” SOCKS Protocol Version 5, RFC 1928)
Regarding claim 2, the combination of Ludwick, Fu, and Roelvink teaches the method according to claim 1. The combination of Ludwick, Fu, and Roelvink teaches
wherein step f) comprises transporting data as a plurality of data packages between the ingress gateway device and the egress gateway device (Ludwick: par. [0029], "gateway 130 generates packet 300... it includes the original message 202 plus DTN overhead data shown as DTN header 302."; par. [0030]: "gateway 130 sends packet 300 to gateway 140 over tactical network 150 that runs DTN."; par [0033]: "gateways 130, 140 provide for segmentation and reassembly of packets in order to comply with size requirements of IP and efficiency goals of DTN." ) but does not teach data package including a data package ordinal identifier for identifying an order of the data packages.
However, in an analogous art, Leech discloses data package including a data package ordinal identifier for identifying an order of the data packages (Leech: section §7: "Each UDP datagram carries a UDP request header with it:
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |.
o FRAG Current fragment number"
§7: "The FRAG field indicates whether or not this datagram is one of a number of fragments. If implemented, the high-order bit indicates end-of-fragment sequence, while a value of X'00' indicates that this datagram is standalone. Values between 1 and 127 indicate the fragment position within a fragment sequence."
§7: "When a UDP relay server receives a reply datagram from a remote host, it MUST encapsulate that datagram using the above UDP request header.").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Leech with the method and system of Ludwick, Fu, and Roelvink to include data package including a data package ordinal identifier for identifying an order of the data packages. Ludwick states that its gateways "provide for segmentation and reassembly of packets" (Ludwick: par. [0033]) but does not describe how a receiving gateway reassembles the segments. Leech teaches carrying, in each datagram, a fragment number indicating "the fragment position within a fragment sequence" (Leech: §7). One would have been motivated to include such an identifier in Ludwick's segmented packets, so that gateway 140 can reassemble them in the correct order — particularly where, as Ludwick notes, the message "traverses as many hops and experiences as many delays as are necessary" according to network conditions (Ludwick: par. [0030]).
Regarding claim 3, the combination of Ludwick, Fu, Roelvink, and Leech teaches the method according to claim 2. The combination of Ludwick, Fu, Roelvink, and Leech further teaches comprising one or both of the following:
fl) encapsulating, by the ingress gateway device, the egress gateway device, or both, data received from the end-user device or the corresponding server device, respectively, in form of data packages ordered based on said data package ordinal identifier (Ludwick: par. [0026]: "gateway 130 receives the message sent by tactical application 110 using TCP/IP or UDP/IP."; par. [0027]: "Gateway 130 strips the message of headers 206, 208."par. [0029]: "gateway 130 generates packet 300... it includes the original message 202 plus DTN overhead data shown as DTN header 302."; par. [0033]: "gateways 130, 140 provide for segmentation and reassembly of packets."; Leech: §7, "When a UDP relay server receives a reply datagram from a remote host, it MUST encapsulate that datagram using the above UDP request header, and any authentication-method-dependent encapsulation."; "Each UDP datagram carries a UDP request header with it: |RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |... o FRAG Current fragment number"; "Values between 1 and 127 indicate the fragment position within a fragment sequence."); and
f2) forwarding, by the ingress gateway device, the egress gateway device, or both, data received as data packages via the time-varying network, to the end-user device or the corresponding server device, respectively, based on the data package ordinal identifier.
Regarding claim 4, the combination of Ludwick, Fu, and Leech teaches the method according to claim 3. The combination of Ludwick, Fu, and Leech, further teaches comprising:
g) queuing, by the ingress gateway device, the egress gateway device, or both, respectively, one or more data packages, when at least one respective pre-ordered data package misses at the ingress gateway device or the egress gateway device, respectively (Leech: §7 "Each receiver will have a REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with these fragments."; "The FRAG field indicates whether or not this datagram is one of a number of fragments. If implemented, the high-order bit indicates end-of-fragment sequence... Values between 1 and 127 indicate the fragment position within a fragment sequence."; "The reassembly queue must be reinitialized and the associated fragments abandoned whenever the REASSEMBLY TIMER expires, or a new datagram arrives carrying a FRAG field whose value is less than the highest FRAG value processed for this fragment sequence."; Ludwick: par. [0033]: "gateways 130, 140 provide for segmentation and reassembly of packets.").
Regarding claim 5, the combination of Ludwick, Fu, Roelvink, and Leech teaches the method according to claim 4. The combination of Ludwick, Fu, Roelvink, and Leech further teaches, wherein step g) comprises one or both of the following:
gl) queuing for a preset queuing duration (Leech: §7, "Each receiver will have a REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with these fragments. The reassembly queue must be reinitialized and the associated fragments abandoned whenever the REASSEMBLY TIMER expires." "The reassembly timer MUST be no less than 5 seconds."); and
g2) queuing for a preset maximum amount of data, a maximum number of data packages, or both.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Ludwick (“Ludwick,” US 2013/0028257) in view of Fu et al. (“Fu,” US 2023/0327908), and Roelvink, Yannick (“Roelvink,” EP 4346255), and M. Leech et al. (“Leech,” SOCKS Protocol Version 5, RFC 1928), further in view of M. K. Scott et al. (“Scott,” Bundle Protocol Specification, RFC 5050).
Regarding claim 6, the combination of Ludwick and Fu teaches the method according to claim 2, further comprising one or both of the following: g3) recovering data by requesting re-transmission of any data package missed at a gateway device from the respective previous gateway device; and g4) reporting a re-transmission, a data miss event, or both with respect to any data package to the ingress gateway device as connection-related information.
Ludwick and Fu do not teach
g3) recovering data by requesting re-transmission of any data package missed at a gateway device from the respective previous gateway device; and
g4) reporting a re-transmission, a data miss event, or both with respect to any data package to the ingress gateway device as connection-related information.
However, in an analogous art, Scott discloses g4) reporting a re-transmission, a data miss event, or both with respect to any data package to the ingress gateway device as connection-related information (Scott: §6.1.1: "The transmission of 'bundle status reports' under specified conditions is an option that can be invoked when transmission of a bundle is requested. These reports are intended to provide information about how bundles are progressing through the system, including notices of receipt, custody transfer, forwarding, final delivery, and deletion. They are transmitted to the Report-to endpoints of bundles."; §4.5.1: "The Report-to Scheme Offset field contains the offset within the dictionary byte array of the scheme name of the ID of the endpoint to which status reports pertaining to the forwarding and delivery of this bundle are to be transmitted."; §4.2: "The bits in positions 14 through 20 are status report request flags... 14 — Request reporting of bundle reception... 16 — Request reporting of bundle forwarding... 18 — Request reporting of bundle deletion."; §5.13: "A bundle deletion status report citing the reason for deletion must be generated, destined for the bundle's report-to endpoint ID."; §6.1.1, Fig. 12 reason codes: "0x01 Lifetime expired... 0x04 Depleted storage... 0x07 No timely contact with next node on route.".
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Scott with the method and system of Ludwick and Fu to include g4) reporting a re-transmission, a data miss event, or both with respect to any data package to the ingress gateway device as connection-related information. Ludwick states that its network "uses store and forward and Bundling Protocol (BP)" to deliver packet 300 from gateway 130 to gateway 140 (Ludwick: [0030]). RFC 5050 specifies that protocol and provides for status reports informing the bundle's report-to endpoint of forwarding and deletion events, including "no timely contact with next node on route" (Scott: §6.1.1, Fig. 12)., One would have been motivated to request such reports back to gateway 130, so that the originating gateway learns when a packet has not reached its destination on a network where, as Ludwick notes, delivery is subject to "delays and intermittent connectivity" (Ludwick: [0030]).
Claims 9-11 is rejected under 35 U.S.C. 103 as being unpatentable over Ludwick (“Ludwick,” US 2013/0028257) in view of Fu et al. (“Fu,” US 2023/0327908), and Roelvink, Yannick (“Roelvink,” EP 4346255), further in view of M. K. Scott et al. (“Scott,” Bundle Protocol Specification, RFC 5050)
Regarding claim 9, the combination of Ludwick, Fu, and Roelvink teaches the method according to claim 1. Ludwick, Fu, and Roelvink do not explicitly disclose
h) gathering, by the ingress gateway device, connection-related information with respect to data transport over the at least one end-to-end encrypted transport connection.
However, in an analogous art, Scott discloses h) gathering, by the ingress gateway device, connection-related information with respect to data transport over the at least one end-to-end encrypted transport connection (Scott: §6.1.1, "The transmission of 'bundle status reports'... These reports are intended to provide information about how bundles are progressing through the system, including notices of receipt, custody transfer, forwarding, final delivery, and deletion. They are transmitted to the Report-to endpoints of bundles."
§6.1.1 (report fields): "Time of Receipt... Time of Custody Acceptance... Time of Forward... Time of Delivery... Time of Deletion" — each "a DTN time indicating the time at which" the event occurred at the reporting node.
§4.5.1: "the ID of the endpoint to which status reports pertaining to the forwarding and delivery of this bundle are to be transmitted."
§4.4: "when the source and report-to of a bundle are the same endpoint."
Fig. 12 reason codes: "0x01 Lifetime expired... 0x04 Depleted storage... 0x07 No timely contact with next node on route."; Ludwick: par. [0029]: "gateway 130 generates packet 300... it includes the original message 202 plus DTN overhead data shown as DTN header 302."; par. [0030]: "DTN uses store and forward and Bundling Protocol (BP) to deliver packet 300 to gateway 140.").
Regarding claim 10, the combination of Ludwick, Fu, and Scott further teaches the method according to claim 9. The combination of Ludwick, Fu, and Scott further teaches , further comprising one or both of the following:
i) selecting, based on said connection-related information, the egress gateway device in any subsequent data transport (Scott: §6.1.1: "The transmission of 'bundle status reports'... These reports are intended to provide information about how bundles are progressing through the system, including notices of receipt, custody transfer, forwarding, final delivery, and deletion. They are transmitted to the Report-to endpoints of bundles."
§6.1.1 (report fields): "Time of Receipt... Time of Custody Acceptance... Time of Forward... Time of Delivery... Time of Deletion" — each "a DTN time indicating the time at which" the event occurred at the reporting node.
§4.5.1: "the ID of the endpoint to which status reports pertaining to the forwarding and delivery of this bundle are to be transmitted."
§4.4: "when the source and report-to of a bundle are the same endpoint."
Fig. 12 reason codes: "0x01 Lifetime expired... 0x04 Depleted storage... 0x07 No timely contact with next node on route.": Ludwick: par. [0029]: "gateway 130 generates packet 300... it includes the original message 202 plus DTN overhead data shown as DTN header 302."; par. [0030]: "DTN uses store and forward and Bundling Protocol (BP) to deliver packet 300 to gateway 140."); and
j) migrating, based on said connection-related information, the at least one end- to-end encrypted transport connection to another suitable server device.
Regarding claim 11, the combination of Ludwick and Fu teaches the method according to claim 9. The combination of Ludwick and Fu further teaches, wherein the connection-related information is based on a number of reported re-transmissions, an accumulated delay of the data transport, an amount of delayed data, a number of delayed data packages, or any combination thereof (Scott: §6.1.1, "Time of Receipt (if present): ... a DTN time indicating the time at which the bundle was received at the reporting node is included here." Likewise "Time of Forward... a DTN time indicating the time at which the bundle was first forwarded at the reporting node" and "Time of Delivery... the time at which the bundle was delivered at the reporting node."; §6.1.1: "Creation Timestamp of Subject Bundle: A copy of the creation timestamp of the bundle that caused the status report to be generated."; §4.5.1: "Bundle creation time is the time -- expressed in seconds since the start of the year 2000, on the Coordinated Universal Time (UTC) scale -- at which the transmission request was received that resulted in the creation of the bundle."; §4.5.1: "Lifetime: the lifetime field is an SDNV that indicates the time at which the bundle's payload will no longer be useful, encoded as a number of seconds past the creation time."; §5.5: "A bundle expires when the current time is greater than the bundle's creation time plus its lifetime as specified in the primary bundle block."; §6.1.1, Fig. 12: reason code "0x01 Lifetime expired."; Ludwick: par. 0039.).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CANH LE whose telephone number is (571)270-1380. The examiner can normally be reached on Monday to Friday 6:00AM to 3:30PM other Friday off.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham, can be reached at telephone number 571-270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Canh Le/
Examiner, Art Unit 2439
August 4th, 2026
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights