DETAILED ACTION
Applicant’s Amendment filed on August 3, 2026 has been reviewed.
Claims 7, 8 and 14 were cancelled in the previous amendment.
Claims 1, 9 and 15 are amended in the amendment.
Claims 1-6, 9-13 and 15-16 have been examined.
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on August 3, 2026 has been entered.
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 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 and 3-5, are rejected under 35 U.S.C. 103 as being unpatentable over Moiseenko et al. (US 2017/0373975 A1), hereinafter referred to as Moiseenko, in view of White et al. (US 2018/0131673 A1), hereinafter referred to as White.
With respect to claim 1, Moiseenko teaches A method for sending an internet data packet from at least one sender via a data entry gateway connected to an Information Centric Networking (ICN) infrastructure to at least one receiver via a data exit gateway (TCP/ICN proxies capable of transparently carrying TCP traffic between TCP/IP endpoints over an ICN network, para. 0019; the network element 102a can host forward proxy functionality and the network element 102b can host reverse proxy functionality, para. 0020; the TCP/ICN proxy functionality can be a translation+tunneling proxy at the entry and exit points of the ICN network can facilitate carrying TCP over an ICN infrastructure, para. 0024; figs. 1A, 2 and 3A), wherein the at least one sender is configured as a data host in an end-to-end communication environment (TCP/ICN proxies capable of transparently carrying TCP traffic between TCP/IP endpoints over an ICN network, para. 0019; the network element 102a can host forward proxy functionality and the network element 102b can host reverse proxy functionality, para. 0020; the TCP/ICN proxy functionality can be a translation+tunneling proxy at the entry and exit points of the ICN network can facilitate carrying TCP over an ICN infrastructure, para. 0024; figs. 1A, 2 and 3A), the at least one sender and the at least one receiver following a communication protocol to transmit information across an Internet Protocol (IP) network between the at least one sender and the data entry gateway and the at least one receiver and the data exit gateway (when TCP data transfer is unidirectional, the process of pulling data involves two proxies: one proxy (e.g., a forward running on network node 104) receives TCP segments from the TCP sender and converts them into ICN Data messages, and another proxy (e.g., a reverse proxy running on network node 106) transmits Interest messages retrieving these Data messages, which are translated back to TCP segments sent to the TCP receiver, para. 0025), the method comprising the steps of:
capturing an internet data packet with an ICN entry module of a data entry gateway (when a TCP segment arrives from a TCP sender 204 at a network element running a forward proxy 302a, the forward proxy 302a checks whether the segment is carrying a payload, the information in TCP/IP headers is used to construct the name of a new Interest packet.; the original TCP/IP segment is placed in the payload of a corresponding new Data packet (i.e. encapsulated in an ICN Data packet), para. 0029; fig. 2, step 1);
creating a data name string for a data payload transported in the internet data packet (creating /[forward-proxy-prefix]/[TCP-4-tuple]/[TCP-sequence-number]/[Wraparound-number]; for Data packets carrying TCP segments with payload can be used, The term “forward-proxy-prefix” is the routable name prefix of the proxy 302a that has received TCP segment. The “TCP-4-tuple” name component(s) includes source IP, source port, destination IP and destination port, which are necessary for TCP connection identification by the reverse proxy 302b. The “TCP-sequence-number” name component exactly matches the sequence number of the corresponding TCP segment; para. 0030-0032; fig. 2, step 2);
storing the data name string and an identification sequence for identifying the internet data packet (the reverse proxy transmits a “reflexive” Interest packet with a name that is guaranteed to match the Data packet stored in the cache 208 of the forward proxy, para. 0035 and When a forward proxy receives the reflexive Interest packet, it attempts to find matching Data packet in its Data cache, para. 0036; fig. 2, steps 4-5 and fig. 3A, step 4; storing in the memory 940 TCP-ICN name mapping for routing purposes, para. 0091; fig. 9),
encapsulating the internet data packet in an ICN data packet (the forward proxy 302a checks whether the segment is carrying a payload, the information in TCP/IP headers is used to construct the name of a new Interest packet.; the original TCP/IP segment is placed in the payload of a corresponding new Data packet (i.e. encapsulated in an ICN Data packet), para. 0029; fig. 2, step 1; a forward proxy performs translation functions needed to express TCP semantics to the ICN network and encapsulates TCP/IP segments into ICN protocol Interest and Data packets for tunneling over the ICN network 110, para. 0024);
passing the ICN data packet to a forwarding module in order to be stored in a content storage module of the forwarding module (when TCP data transfer is unidirectional, the process of pulling data involves two proxies: one proxy (e.g., a forward running on network node 104) receives TCP segments from the TCP sender and converts them into ICN Data messages, and another proxy (e.g., a reverse proxy running on network node 106) transmits Interest messages retrieving these Data messages, which are translated back to TCP segments sent to the TCP receiver, para. 0025), and to be forwarded upon receipt of a respective data interest packet by the forwarding module, the data interest packet indicating a data request by the receiver (when TCP data transfer is unidirectional, the process of pulling data involves two proxies: one proxy (e.g., a forward running on network node 104) receives TCP segments from the TCP sender and converts them into ICN Data messages, and another proxy (e.g., a reverse proxy running on network node 106) transmits Interest messages retrieving these Data messages, which are translated back to TCP segments sent to the TCP receiver, para. 0025);
wherein the communication protocol between the at least one sender and the at least one receiver is selected from a group consisting of: a User Datagram Protocol (UDP), a Transmission Control Protocol (TCP) (when TCP data transfer is unidirectional, the process of pulling data involves two proxies: one proxy (e.g., a forward running on network node 104) receives TCP segments from the TCP sender and converts them into ICN Data messages, and another proxy (e.g., a reverse proxy running on network node 106) transmits Interest messages retrieving these Data messages, which are translated back to TCP segments sent to the TCP receiver, para. 0025) in order to allow for the effective exchange of data or information as taught by Moiseenko (para. 0096), a Multicast Protocol, and any combination thereof.
Moiseenko does teach storing in the memory 940 TCP-ICN name mapping for routing purposes (para. 0091; fig. 9) and in ICN, an Interest Message, which requests a piece of content via a hierarchical tokenized name, and a Data Message, which returns the requested named piece of content; names of packet-sized objects are the only identifiers in the protocols; neither source addresses nor destination addresses are employed (para. 0018), but Moiseenko does not explicitly teach
storing an association between the data name string and an identification sequence for identifying the internet data packet in an identification map, wherein the identification sequence uniquely identifies the internet data packet independent of a network address;
However, White teaches
storing an association between the data name string and an identification sequence for identifying the internet data packet in an identification map (the IPoC controller, the sequencer configured to tabulate or otherwise associate the unique names, or more specifically the sequence numbers, with each IP packet so as to facilitate ordering processing of the IP packets, para. 0024; generating the addressing or naming related information for the name field in the manner described above whereby unique representation of the IP client is appended with a sequence number other information uniquely identifying the IP packet, e.g., a combination of IPoC client identification/name plus packet individual IP packet differentiation, para. 0040; fig. 5, block 24; the forwarding process include IPoC client generating a table or other relationship to facilitate matching sequence numbers to corresponding IP flows or sequences of multiple IP packets in the event the IPoC client issues IP packets, para. 0041; fig. 5, block 26; the Client Interest Table (CIT) kept at the IPoC gateway relate the entire naming field included with previously received interest messages, para. 0026), wherein the identification sequence uniquely identifies the internet data packet independent of a network address (implementing the sequencer to facilitate including sequence numbers with the forwarded content object messages in a manner similar to that described above so as to enable the IPoC client to resequence the IP packets encapsulated therein’ the encapsulation the IP packets within the content object message occur in the order of receipt such that the IPoC client infer a matching ordering in the content object message when multiple IP packets are included therein’ the sequencer include additional sequence numbers to facilitate individually sequencing IP packets included in content object messages, para. 0027;[the sequence numbers are what distinguishes the encapsulated IP packets and generated by the sequencer rather than derived from any network address]) in order to facilitate including sequence numbers with the forwarded content object messages to enable the IPoC client to resequence the IP packets encapsulated as taught by White (para. 0027);
Therefore, based on Moiseenko in view of White, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of White to the method of Moiseenko in order to facilitate including sequence numbers with the forwarded content object messages to enable the IPoC client to resequence the IP packets encapsulated as taught by White (para. 0027).
With respect to claim 3, Moiseenko teaches The method according to claim 1, further comprising the step of:
receiving an ICN acknowledgement message with the ICN entry module, the ICN acknowledgement message acknowledging receipt of the ICN data packet by a receiver of the internet data packet (ICN proxy 402 receives an acknowledgement Interest message 404; the Interest message 404 includes a name that has a sequence number and a TCP ACK; the TCP/ICN proxy 402 can send an ACK 406 to the TCP sender; the TCP/ICN proxy 402 can receive an Interest message 414 that acknowledges the receipt of the ICN data message 412, where the ACK identifies the highest sequence number from the data segments encapsulated in the ICN Data message, para. 0060).
With respect to claim 4, Moiseenko teaches The method according to claim 3, further comprising the step of:
communicating an acknowledgement of receipt by sending an internet acknowledgement packet to the at least one sender from the data entry gateway (ICN proxy 402 receives an acknowledgement Interest message 404; the Interest message 404 includes a name that has a sequence number and a TCP ACK; the TCP/ICN proxy 402 can send an ACK 406 to the TCP sender; the TCP/ICN proxy 402 can receive an Interest message 414 that acknowledges the receipt of the ICN data message 412, where the ACK identifies the highest sequence number from the data segments encapsulated in the ICN Data message, para. 0060).
With respect to claim 5, Moiseenko teaches The method according to claim 4, further comprising the step of:
caching the ICN data packet at the data entry gateway (the reverse proxy transmits a “reflexive” Interest packet with a name that is guaranteed to match the Data packet stored in the cache 208 of the forward proxy, para. 0035 and When a forward proxy receives the reflexive Interest packet, it attempts to find matching Data packet in its Data cache, para. 0036; fig. 2, steps 4-5 and fig. 3A, step 4; storing in the memory 940 TCP-ICN name mapping for routing purposes, para. 0091; fig. 9).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Moiseenko et al. (US 2017/0373975 A1), hereinafter referred to as Moiseenko, in view of White et al. (US 2018/0131673 A1), hereinafter referred to as White, and further in view of Muscariello (US 2018/0242218 A1).
With respect to claim 2, Moiseenko in view of White teaches The method according to claim 1 as described above,
Moiseenko in view of White does not explicitly teach further comprising the step of:
deleting the association of the data name string and the identification sequence from the identification map.
However, Muscariello teaches further comprising the step of:
deleting the association of the data name string and the identification sequence from the identification map (data is split into packets, uniquely identified by a content name; a namespace allows content to be referenced by content name using a name-prefix included in Interest and Data packets; a name-prefix is a hierarchical tokenized name for content that contains a sequence of name, para. 0042; the CS can be potentially useful to satisfy future Interest packets that received from downstream ICN node; a PIT is a table that stores the state associated with unsatisfied Interests (e.g., an entry is added into the PIT when a new Interest packet arrives and the entry is removed when it is satisfied by reception of a corresponding Data packet, para. 0050) improve efficiency, better scalability with respect to information as taught by Muscariello (para. 0004).
Therefore, based on Moiseenko in view of White, and further in view of Muscariello, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Muscariello to the method of Moiseenko in view of White in order to improve efficiency, better scalability with respect to information as taught by Muscariello (para. 0004).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Moiseenko et al. (US 2017/0373975 A1), hereinafter referred to as Moiseenko, in view of White et al. (US 2018/0131673 A1), hereinafter referred to as White, and further in view of Trossen (WO 2017/100543 A1).
With respect to claim 6, Moiseenko in view of White teaches The method according to claim 1 as described above,
Moiseenko in view of White does not explicitly teach further comprising the steps of:
receiving at the ICN entry module an interest join packet from the receiver, and
sending from the ICN entry module an IP join multicast packet to the at least one sender.
However, Trossen teaches further comprising the steps of:
receiving at the ICN entry module an interest join packet from the receiver (joining an IP multicast group as a receiver; in order for an IP-enabled WTRU to join a specific IP multicast group as a receiver, the receiving WTRU 407 send 901 an IGMP join request (more specifically, a membership report for the IP multicast address) to its local NAP which acts as the receiving NAP 406 (with the local NAP being its local IP router) upon receiving 902 the IGMP join request, the NAP 406 check 903 its internal DB for an appropriate row for the IP multicast address in the join request, para. 0059 and 0063; fig. 9), and
sending from the ICN entry module an IP join multicast packet to the at least one sender (the NAP 406 then send 907 an appropriate message, such as a publish_isub( ) message, for the CID.sub.C name towards the subscribers (i.e., the IP multicast senders); within such message, the NAP 406 include its own NID information as well as the IP multicast address it intends to join, para. 0063; fig. 9) in order to facilitate communication between devices as taught by Trossen (para. 0044).
Therefore, based on Moiseenko in view of White, and further in view of Trossen, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Trossen to the method of Moiseenko in view of White in order to facilitate communication between devices as taught by Trossen (para. 0044).
Claims 9 and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Moiseenko et al. (US 2017/0373975 A1), hereinafter referred to as Moiseenko, in view of White et al. (US 2018/0131673 A1), hereinafter referred to as White, and further in view of Le Pennec et al. (US 2011/0072129 A1), hereinafter referred to as Le Pennec.
With respect to claim 9, Moiseenko teaches A method for receiving with at least one receiver an internet data packet from at least one sender via a data exit gateway connected to an Information Centric Networking (ICN) infrastructure (TCP/ICN proxies capable of transparently carrying TCP traffic between TCP/IP endpoints over an ICN network, para. 0019; the network element 102a can host forward proxy functionality and the network element 102b can host reverse proxy functionality, para. 0020; the TCP/ICN proxy functionality can be a translation+tunneling proxy at the entry and exit points of the ICN network can facilitate carrying TCP over an ICN infrastructure, para. 0024; figs. 1A, 2 and 3A), wherein the at least one receiver is configured as a data client in an end-to-end communication environment (TCP/ICN proxies capable of transparently carrying TCP traffic between TCP/IP endpoints over an ICN network, para. 0019; the network element 102a can host forward proxy functionality and the network element 102b can host reverse proxy functionality, para. 0020; the TCP/ICN proxy functionality can be a translation+tunneling proxy at the entry and exit points of the ICN network can facilitate carrying TCP over an ICN infrastructure, para. 0024; figs. 1A, 2 and 3A), the at least one sender and the at least one receiver following a communication protocol to transmit information across an Internet Protocol (IP) network between the at least one sender and the data entry gateway and the at least one receiver and the data exit gateway (when TCP data transfer is unidirectional, the process of pulling data involves two proxies: one proxy (e.g., a forward running on network node 104) receives TCP segments from the TCP sender and converts them into ICN Data messages, and another proxy (e.g., a reverse proxy running on network node 106) transmits Interest messages retrieving these Data messages, which are translated back to TCP segments sent to the TCP receiver, para. 0025), the method comprising the steps of:
passing a data interest packet indicating a data request by the at least one receiver to a forwarding module in order to be forwarded to an ICN entry module (when TCP data transfer is unidirectional, the process of pulling data involves two proxies: one proxy (e.g., a forward running on network node 104) receives TCP segments from the TCP sender and converts them into ICN Data messages, and another proxy (e.g., a reverse proxy running on network node 106) transmits Interest messages retrieving these Data messages, which are translated back to TCP segments sent to the TCP receiver, para. 0025);
receiving with an ICN exit module of the data exit gateway an ICN data packet corresponding to the data interest packet and encapsulating an internet data packet (the forward proxy 302a checks whether the segment is carrying a payload, the information in TCP/IP headers is used to construct the name of a new Interest packet.; the original TCP/IP segment is placed in the payload of a corresponding new Data packet (i.e. encapsulated in an ICN Data packet), para. 0029; fig. 2, step 1; a forward proxy performs translation functions needed to express TCP semantics to the ICN network and encapsulates TCP/IP segments into ICN protocol Interest and Data packets for tunneling over the ICN network 110, para. 0024);
consulting the data image of the identification map for finding a name string identifying the data payload and the respective identification sequence of the internet data packet (the reverse proxy transmits a “reflexive” Interest packet with a name that is guaranteed to match the Data packet stored in the cache 208 of the forward proxy, para. 0035 and When a forward proxy receives the reflexive Interest packet, it attempts to find matching Data packet in its Data cache, para. 0036; fig. 2, steps 4-5 and fig. 3A, step 4; storing in the memory 940 TCP-ICN name mapping for routing purposes, para. 0091; fig. 9);
mapping the internet data packet into an IP address based on the identification sequence by reconstructing the IP address of the internet data packet from the identification sequence (the reverse proxy transmits a “reflexive” Interest packet with a name that is guaranteed to match the Data packet stored in the cache 208 of the forward proxy, para. 0035 and When a forward proxy receives the reflexive Interest packet, it attempts to find matching Data packet in its Data cache, para. 0036; fig. 2, steps 4-5 and fig. 3A, step 4; storing in the memory 940 TCP-ICN name mapping for routing purposes, para. 0091; fig. 9);
extracting the internet data packet from the received ICN data packet (when the reverse proxy receives a Data packet, it transmits the decapsulated TCP segment(s) over IP to the TCP receiver 206, para. 0037); and
sending the internet data packet to the at least one receiver having the mapped IP address (creating /[forward-proxy-prefix]/[TCP-4-tuple]/[TCP-sequence-number]/[Wraparound-number]; for Data packets carrying TCP segments with payload can be used, The term “forward-proxy-prefix” is the routable name prefix of the proxy 302a that has received TCP segment. The “TCP-4-tuple” name component(s) includes source IP, source port, destination IP and destination port, which are necessary for TCP connection identification by the reverse proxy 302b. The “TCP-sequence-number” name component exactly matches the sequence number of the corresponding TCP segment; para. 0030-0032; fig. 2, step 2);
wherein the communication protocol between the at least one sender and the at least one receiver is selected from a group consisting of: a User Datagram Protocol (UDP), a Transmission Control Protocol (TCP) (when TCP data transfer is unidirectional, the process of pulling data involves two proxies: one proxy (e.g., a forward running on network node 104) receives TCP segments from the TCP sender and converts them into ICN Data messages, and another proxy (e.g., a reverse proxy running on network node 106) transmits Interest messages retrieving these Data messages, which are translated back to TCP segments sent to the TCP receiver, para. 0025) in order to allow for the effective exchange of data or information as taught by Moiseenko (para. 0096), a Multicast Protocol, and any combination thereof.
Moiseenko does not explicitly teach
creating a data image of at least as part of an identification map containing data name strings for identifying respective data payloads transported in internet data packets potentially requested by the at least one receiver, and containing identification sequences for identifying the internet data packets;
However, White teaches
creating a data image of at least as part of an identification map containing data name strings for identifying respective data payloads transported in internet data packets potentially requested by the at least one receiver (implementing the sequencer to facilitate including sequence numbers with the forwarded content object messages in a manner similar to that described above so as to enable the IPoC client to resequence the IP packets encapsulated therein’ the encapsulation the IP packets within the content object message occur in the order of receipt such that the IPoC client infer a matching ordering in the content object message when multiple IP packets are included therein’ the sequencer include additional sequence numbers to facilitate individually sequencing IP packets included in content object messages, para. 0027), and containing identification sequences for identifying the internet data packets (storing /[forward-proxy-prefix]/[TCP-4-tuple]/[TCP-sequence-number]/[Wraparound-number]; for Data packets carrying TCP segments with payload can be used, The term “forward-proxy-prefix” is the routable name prefix of the proxy 302a that has received TCP segment. The “TCP-4-tuple” name component(s) includes source IP, source port, destination IP and destination port, which are necessary for TCP connection identification by the reverse proxy 302b. The “TCP-sequence-number” name component exactly matches the sequence number of the corresponding TCP segment; para. 0030-0032; fig. 2, step 2) facilitate including sequence numbers with the forwarded object messages to enable the IPoC client to resequence the IP packets encapsulated as taught by White (para. 0027);
Therefore, based on Moiseenko in view of White, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of White to the method of Moiseenko facilitate including sequence numbers with the forwarded content object messages to enable the IPoC client to resequence the IP packets encapsulated as taught by White (para. 0027).
Moiseenko in view of White does not explicitly teach
verifying a reachability of at least one sender of the internet data packets;
However, Le Pennec teaches
verifying a reachability of at least one sender of the internet data packets (the ICMP proxy device 108 transmits an ICMP Echo request to the first server 112 and receives an ICMP Echo Response from the first server 112, at operation 316 ICMP proxy device 108 updates the availability status of the first server 112 in the server protection list, the ICMP proxy device 108 updates the availability status in the server protection list with the availability status in the ICMP Echo Response, para. 0050; fig. 3) in order to facilitate an ICMP Echo Response with the refreshed or updated availability status via a next ICMP Echo request as taught by Le Pennec (para. 0044);
Therefore, based on Moiseenko in view of White, and further in view of Le Pennec, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Le Pennec to the method of Moiseenko in view of White in order to facilitate an ICMP Echo Response with the refreshed or updated availability status via a next ICMP Echo request as taught by Le Pennec (para. 0044).
With respect to claim 11, Moiseenko teaches The method according to claim 9, further comprising the steps of:
receiving at the data exit gateway an internet acknowledgement packet from the at least one receiver (ICN proxy 402 receives an acknowledgement Interest message 404; the Interest message 404 includes a name that has a sequence number and a TCP ACK; the TCP/ICN proxy 402 can send an ACK 406 to the TCP sender; the TCP/ICN proxy 402 can receive an Interest message 414 that acknowledges the receipt of the ICN data message 412, where the ACK identifies the highest sequence number from the data segments encapsulated in the ICN Data message, para. 0060); and
sending an ICN acknowledgement message with the ICN exit module to a data entry gateway, the ICN acknowledgement message acknowledging receipt of the internet data packet by the at least one receiver (ICN proxy 402 receives an acknowledgement Interest message 404; the Interest message 404 includes a name that has a sequence number and a TCP ACK; the TCP/ICN proxy 402 can send an ACK 406 to the TCP sender; the TCP/ICN proxy 402 can receive an Interest message 414 that acknowledges the receipt of the ICN data message 412, where the ACK identifies the highest sequence number from the data segments encapsulated in the ICN Data message, para. 0060).
With respect to claim 12, Moiseenko teaches The method according to claim 9, further comprising the step of:
caching the internet data packet at the data exit gateway (the reverse proxy transmits a “reflexive” Interest packet with a name that is guaranteed to match the Data packet stored in the cache 208 of the forward proxy, para. 0035 and When a forward proxy receives the reflexive Interest packet, it attempts to find matching Data packet in its Data cache, para. 0036; fig. 2, steps 4-5 and fig. 3A, step 4; storing in the memory 940 TCP-ICN name mapping for routing purposes, para. 0091; fig. 9).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Moiseenko et al. (US 2017/0373975 A1), hereinafter referred to as Moiseenko, in view of White et al. (US 2018/0131673 A1), hereinafter referred to as White, further in view of Le Pennec et al. (US 2011/0072129 A1), hereinafter referred to as Le Pennec, and furthermore in view of Muscariello (US 2018/0242218 A1).
With respect to claim 10, Moiseenko in view of White, and further in view of Le Pennec teaches The method according to claim 9 as described above,
Moiseenko in view of White, and further in view of Le Pennec does not explicitly teach further comprising the step of: updating the data image of the identification map to take into account any deletion of a name string associated with the identified data payload from the entry identification map upon receipt of the data interest packet.
However, Muscariello teaches
updating the data image of the identification map to take into account any deletion of a name string associated with the identified data payload from the entry identification map upon receipt of the data interest packet (The process of updating an existing entry in the PIT and discarding an Interest is sometimes referred to as Interest aggregation, para. 0051; data is split into packets, uniquely identified by a content name; a namespace allows content to be referenced by content name using a name-prefix included in Interest and Data packets; a name-prefix is a hierarchical tokenized name for content that contains a sequence of name, para. 0042; the CS can be potentially useful to satisfy future Interest packets that received from downstream ICN node; a PIT is a table that stores the state associated with unsatisfied Interests (e.g., an entry is added into the PIT when a new Interest packet arrives and the entry is removed when it is satisfied by reception of a corresponding Data packet, para. 0050) improve efficiency, better scalability with respect to information as taught by Muscariello (para. 0004).
Therefore, based on Moiseenko in view of White, further in view of Le Pennec, and furthermore in view of Muscariello, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Muscariello to the method of Moiseenko in view of White, and further in view of Le Pennec in order to improve efficiency, better scalability with respect to information as taught by Muscariello (para. 0004).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Moiseenko et al. (US 2017/0373975 A1), hereinafter referred to as Moiseenko, in view of White et al. (US 2018/0131673 A1), hereinafter referred to as White, further in view of Le Pennec et al. (US 2011/0072129 A1), hereinafter referred to as Le Pennec, and furthermore in view of Trossen (WO 2017/100543 A1).
With respect to claim 13, Moiseenko in view of White, and further in view of Le Pennec teaches The method according to claim 9 as described above,
Moiseenko in view of White, and further in view of Le Pennec does not explicitly teaches further comprising the steps of:
receiving at the ICN exit module an IP multicast prune packet from the at least one receiver, and
sending from the ICN exit module a prune interest packet to an ICN entry module.
However, Trossen teaches further comprising the steps of:
receiving at the ICN exit module an IP multicast prune packet from the at least one receiver (joining an IP multicast group as a receiver. In order for an IP-enabled WTRU to join a specific IP multicast group as a receiver, the receiving WTRU 407 may send 901 an IGMP join request (more specifically, a membership report for the IP multicast address) to its local NAP which acts as the receiving NAP 406 (with the local NAP being its local IP router) upon receiving 902 the IGMP join request, the NAP 406 may check 903 its internal DB for an appropriate row for the IP multicast address in the join request, para. 0059 and 0063; fig. 9), and
sending from the ICN exit module a prune interest packet to an ICN entry module (the NAP 406 then send 907 an appropriate message, such as a publish_isub( ) message, for the CID.sub.C name towards the subscribers (i.e., the IP multicast senders); within such message, the NAP 406 may include its own NID information as well as the IP multicast address it intends to join, para. 0063; fig. 9) in order to facilitate communication between devices as taught by Trossen (para. 0044).
Therefore, based on Moiseenko in view of White, further in view of Le Pennec, and furthermore in view of Trossen, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Trossen to the method of Moiseenko in view of White, and further in view of Le Pennec in order to facilitate communication between devices as taught by Trossen (para. 0044).
Claim 15 and16 are rejected under 35 U.S.C. 103 as being unpatentable over Moiseenko et al. (US 2017/0373975 A1), hereinafter referred to as Moiseenko, in view of White et al. (US 2018/0131673 A1), hereinafter referred to as White, further in view of Le Pennec et al. (US 2011/0072129 A1), hereinafter referred to as Le Pennec, and furthermore in view of Tran et al. (US 2022/0255224 A1), hereinafter referred to as Tran.
With respect to claim 15, Tran teaches A network element (network element, para. 0090) comprising:
a processor (processor, para. 0137); and
at least one data exit gateway configured to carry out the steps of the method according to claim 9 (TCP/ICN proxies capable of transparently carrying TCP traffic between TCP/IP endpoints over an ICN network, para. 0019; the network element 102a can host forward proxy functionality and the network element 102b can host reverse proxy functionality, para. 0020; the TCP/ICN proxy functionality can be a translation+tunneling proxy at the entry and exit points of the ICN network can facilitate carrying TCP over an ICN infrastructure, para. 0024; figs. 1A, 2 and 3A).
Moiseenko in view of White, and further in view of Le Pennec does not explicitly teach A vehicle comprising:
a processor; and
at least one data exit gateway configured to carry out the steps of the method according to claim 9.
However, Tran teaches A vehicle (aircraft, para. 0079-0080) comprising:
a processor (processor, para. 0137); and
at least one data exit gateway configured to carry out the steps of the method according to claim 9 (the network device comprise a virtual information-centric networking (ICN) server of an ICN virtual network (VN), and adapted to provide the cached content to a virtual user-specific serving gateway (v-u-SGW) of a served user equipment (UE) upon request, para. 0281; in aircraft communication, para. 0079-0080) in order to improve the receiver performance as taught by Tran (para. 0212).
Therefore, based on Moiseenko in view of White, further in view of Le Pennec, and furthermore in view of Tran, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Tran to the network element of Moiseenko in view of White, and further in view of Le Pennec in order to improve the receiver performance as taught by Tran (para. 0212).
With respect to claim 16, Moiseenko in view of White, further in view of Le Pennec, and furthermore in view of Tran teaches The vehicle of claim 15 as described above,
Further, Tran teaches wherein the vehicle is an aircraft (the network device comprise a virtual information-centric networking (ICN) server of an ICN virtual network (VN), and adapted to provide the cached content to a virtual user-specific serving gateway (v-u-SGW) of a served user equipment (UE) upon request, para. 0281; in aircraft communication, para. 0079-0080) in order to improve the receiver performance as taught by Tran (para. 0212).
Therefore, based on Moiseenko in view of White, further in view of Le Pennec, and furthermore in view of Tran, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Tran to the network element of Moiseenko in view of White, and further in view of Le Pennec in order to improve the receiver performance as taught by Tran (para. 0212).
Response to Arguments
Applicant’s arguments with respect to claims 1-6, 9-13 and 15-16 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAO HONG NGUYEN whose telephone number is (571)272-2666. The examiner can normally be reached on Monday-Friday 8AM-4:30PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Joon H. Hwang can be reached on (571)272-40364036. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/H.H.N/Examiner, Art Unit 2447
October 2, 2026
/JOON H HWANG/Supervisory Patent Examiner, Art Unit 2447
Prosecution Insights