Prosecution Insights
Last updated: July 17, 2026
Application No. 18/800,373

DATA SENDING METHOD, ENTRY GATEWAY AND COMMUNICATION STATION, AS WELL AS DATA RECEIVING METHOD, EXIT GATEWAY AND VEHICLE COMPRISING SAME

Non-Final OA §101§103
Filed
Aug 12, 2024
Priority
Aug 14, 2023 — EU 23191259.3
Examiner
NGUYEN, HAO HONG
Art Unit
2447
Tech Center
2400 — Computer Networks
Assignee
Airbus SAS
OA Round
2 (Non-Final)
68%
Grant Probability
Favorable
2-3
OA Rounds
1y 0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 68% — above average
68%
Career Allowance Rate
208 granted / 308 resolved
+9.5% vs TC avg
Strong +38% interview lift
Without
With
+38.3%
Interview Lift
resolved cases with interview
Typical timeline
2y 11m
Avg Prosecution
14 currently pending
Career history
337
Total Applications
across all art units

Statute-Specific Performance

§101
1.2%
-38.8% vs TC avg
§103
92.1%
+52.1% vs TC avg
§102
4.6%
-35.4% vs TC avg
§112
0.4%
-39.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 308 resolved cases

Office Action

§101 §103
DETAILED ACTION Applicant’s Amendment filed on January 2, 2026 has been reviewed. Claims 7, 8 and 14 are cancelled in the amendment. Claims 1, 9, 10 and 15 are amended in the amendment. Claims 1-6, 9-13 and 15-16 have been examined. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 15 and 16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims 15 lacks the necessary physical articles or objects to constitute a machine or a manufacture within the meaning of 35 U.S.C. 101. They are clearly not a series of steps or acts to be a process nor are they a combination of chemical compounds to be a composition of matter. As such, they fail to fall within a statutory category. At least one data exit gateway in claim 15 configured to carry out the steps of the method according to claim 1; since the specification does not define that the data exit gateway as hardware or software, the data exit gateway in claim 15 is interpreted as software. Thus, the claim 15 does not meet the definition of a machine and thereby does not fall under any of the patent eligible statutory categories. Claim 16 is likewise rejected. 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, 3-5, 9, 11-12 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Tran et al. (US 2022/0255224 A1), hereinafter referred to as Tran, in view of Moiseenko et al. (US 2017/0373975 A1), hereinafter referred to as Moiseenko. With respect to claim 1, Tran 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 (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), wherein the at least one sender is configured as a data host in an end-to-end communication environment (the hosts form a network of independent providers where devices send and receive data to the Internet, para. 0154), the method comprising the steps of: capturing an internet data packet with an ICN entry module of a data entry gateway (content cached in network devices of wireless network or radio access network (RAN) in anticipation that a mobile device or user will want to access the content in the future, para. 0281); creating a data name string for a data payload transported in the internet data packet (the content cache table associate a name of the content with a network address of the network device or the virtual IVN server included in the network device, para. 0281); storing an association between the data name string and an identification sequence for identifying the internet data packet in an identification map (the content cache table associate a name of the content with a network address of the network device or the virtual IVN server included in the network device, para. 0281); encapsulating the internet data packet in an ICN data packet (the cached content is stored by the network device in an information-centric networking (ICN) format, para. 0281); passing the ICN data packet to a forwarding module in order to be stored in a content storage module of the forwarding module (the cached content is stored by the network device in an information-centric networking (ICN) format, para. 0281), 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 (the v-u-SGW may translate the cached content from the ICN format to a user-specific format upon receiving the cached content pursuant to a content request, para. 0281). Tran does not explicitly teach 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, 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), a Multicast Protocol, . However, Moiseenko teaches 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), 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, . Therefore, based on Tran in view of Moiseenko, 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 Moiseenko to the method of Tran in order to allow for the effective exchange of data or information as taught by Moiseenko (para. 0096). With respect to claim 3, Tran in view of Moiseenko teaches The method according to claim 1 as described above, Further, Moiseenko teaches 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) in order to allow for the effective exchange of data or information as taught by Moiseenko (para. 0096). Therefore, based on Tran in view of Moiseenko, 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 Moiseenko to the method of Tran in order to allow for the effective exchange of data or information as taught by Moiseenko (para. 0096). With respect to claim 4, Tran in view of Moiseenko teaches The method according to claim 3 as described above, Furthermore, Moiseenko teaches 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) in order to allow for the effective exchange of data or information as taught by Moiseenko (para. 0096). Therefore, based on Tran in view of Moiseenko, 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 Moiseenko to the method of Tran in order to allow for the effective exchange of data or information as taught by Moiseenko (para. 0096). With respect to claim 5, Tran teaches The method according to claim 4, further comprising the step of: caching the ICN data packet at the data entry gateway (the cached content is stored by the network device in an information-centric networking (ICN) format, and the v-u-SGW translate the cached content from the ICN format to a user-specific format upon receiving the cached content pursuant to a content request, para. 0281; also see para. 0283). With respect to claim 9, Tran 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 (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), wherein the at least one receiver is configured as a data client in an end-to-end communication environment (the hosts form a network of independent providers where devices send and receive data to the Internet, para. 0154), the method comprising the steps of 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 (the content cache table associate a name of the content with a network address of the network device or the virtual IVN server included in the network device; content cached in network devices of wireless network or radio access network (RAN) in anticipation that a mobile device or user will want to access the content in the future, para. 0281), and containing identification sequences for identifying the internet data packets (the content cache table associate a name of the content with a network address of the network device or the virtual IVN server included in the network device, para. 0281); verifying a reachability of at least one sender of the internet data packets (an instability analyzer reports base station stability and reachability to avoid getting stuck in a suboptimal network, para. 0276); 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 (the cached content is stored by the network device in an information-centric networking (ICN) format, para. 0281); 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 cached content is stored by the network device in an information-centric networking (ICN) format, and the v-u-SGW translate the cached content from the ICN format to a user-specific format upon receiving the cached content pursuant to a content request; the v-u-SGW then relay the cached content having the user-specific format to a served UE; after the content is pushed to the network device, the content forwarding service manager (CFM) update a content cache table to indicate that the content has been cached at the network device, para. 0281); 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 content cache table associate a name of the content with a network address of the network device or the virtual IVN server included in the network device, para. 0281); mapping the internet data packet into an IP address of the at least one receiver based on the identification sequence (the cached content is stored by the network device in an information-centric networking (ICN) format, and the v-u-SGW translate the cached content from the ICN format to a user-specific format upon receiving the cached content pursuant to a content request; the v-u-SGW then relay the cached content having the user-specific format to a served UE; after the content is pushed to the network device, the content forwarding service manager (CFM) update a content cache table to indicate that the content has been cached at the network device, para. 0281); extracting the internet data packet from the received ICN data packet (the cached content is stored by the network device in an information-centric networking (ICN) format, and the v-u-SGW translate the cached content from the ICN format to a user-specific format upon receiving the cached content pursuant to a content request; the v-u-SGW then relay the cached content having the user-specific format to a served UE; after the content is pushed to the network device, the content forwarding service manager (CFM) update a content cache table to indicate that the content has been cached at the network device, para. 0281); and sending the internet data packet to the at least one receiver having the mapped IP address (the v-u-SGW translate the cached content from the ICN format to a user-specific format upon receiving the cached content pursuant to a content request, para. 0281). Tran does not explicitly teach 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, 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), a Multicast Protocol, . However, Moiseenko teaches 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), 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, . Therefore, based on Tran in view of Moiseenko, 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 Moiseenko to the method of Tran in order to allow for the effective exchange of data or information as taught by Moiseenko (para. 0096). With respect to claim 11, Tran teaches The method according to claim 9 as described above, Tran does not explicitly teach further comprising the steps of: receiving at the data exit gateway an internet acknowledgement packet from the at least one receiver; 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. However, Moiseenko teaches 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) in order to allow for the effective exchange of data or information as taught by Moiseenko (para. 0096). Therefore, based on Tran in view of Moiseenko, 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 Moiseenko to the method of Tran in order to allow for the effective exchange of data or information as taught by Moiseenko (para. 0096). With respect to claim 12, Tran teaches The method according to claim 9, further comprising the step of: caching the internet data packet at the data exit gateway (the cached content is stored by the network device in an information-centric networking (ICN) format, and the v-u-SGW translate the cached content from the ICN format to a user-specific format upon receiving the cached content pursuant to a content request, para. 0281; also see para. 0283). With respect to claim 15, Tran teaches A vehicle comprising 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). With respect to claim 16, Tran teaches The vehicle of claim 15, 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). Claims 2 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Tran et al. (US 2022/0255224 A1), hereinafter referred to as Tran, in view of Moiseenko et al. (US 2017/0373975 A1), hereinafter referred to as Moiseenko, and further in view of Muscariello (US 2018/0242218 A1). With respect to claim 2, Tran in view of Moiseenko teaches The method according to claim 1 as described above, Tran in view of Moiseenko 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 Tran in view of Moiseenko, 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 Tran in view of Moiseenko in order to improve efficiency, better scalability with respect to information as taught by Muscariello (para. 0004). With respect to claim 10, Tran teaches The method according to claim 9, further comprising the step of: updating the data image of the identification map upon receipt of the data interest packet by a data entry gateway (the cached content is stored by the network device in an information-centric networking (ICN) format, and the v-u-SGW translate the cached content from the ICN format to a user-specific format upon receiving the cached content pursuant to a content request; the v-u-SGW then relay the cached content having the user-specific format to a served UE; after the content is pushed to the network device, the content forwarding service manager (CFM) update a content cache table to indicate that the content has been cached at the network device, para. 0281). Tran in view of Moiseenko does not explicitly teach 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 Tran in view of Moiseenko, 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 Tran in view of Moiseenko in order to improve efficiency, better scalability with respect to information as taught by Muscariello (para. 0004). Claims 6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Tran et al. (US 2022/0255224 A1), hereinafter referred to as Tran, in view of Moiseenko et al. (US 2017/0373975 A1), hereinafter referred to as Moiseenko, and further in view of Trossen (WO 2017/100543 A1). With respect to claim 6, Tran in view of Moiseenko teaches The method according to claim 1 as described above, Tran in view of Moiseenko 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 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 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 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 Tran in view of Moiseenko, 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 Tran in view of Moiseenko in order to facilitate communication between devices as taught by Trossen (para. 0044). With respect to claim 13, Tran in view of Moiseenko teaches The method according to claim 9 as described above, Tran in view of Moiseenko 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 Tran in view of Moiseenko, 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 Tran in view of Moiseenko in order to facilitate communication between devices as taught by Trossen (para. 0044). Response to Arguments Applicant’s arguments filed on January 2, 2026 have been fully considered but they are not persuasive for the following reasons: Regarding Applicant’s arguments in 35 U.S.C. § 101 Rejections section, “at least one data exit gateway” in claim 15 configured to carry out the steps of the method according to claim 1; since the specification does not define that the data exit gateway as hardware or software, “the data exit gateway” in claim 15 is interpreted as software. Thus, the claim 15 does not meet the definition of a machine and thereby does not fall under any of the patent eligible statutory categories. Therefore, the § 101 Rejections is maintained and repeated in this office action. Regarding to 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 alternative rejection. Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action. 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-4036. 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 April 29, 2026 /JOON H HWANG/Supervisory Patent Examiner, Art Unit 2447
Read full office action

Prosecution Timeline

Aug 12, 2024
Application Filed
Oct 03, 2025
Non-Final Rejection mailed — §101, §103
Jan 02, 2026
Response Filed
May 01, 2026
Final Rejection mailed — §101, §103
Jun 17, 2026
Response after Non-Final Action

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12671629
Network Energy Savings Using Bandwidth Scaling
2y 11m to grant Granted Jun 30, 2026
Patent 12659371
CAMERA NETWORK FOR ENHANCING INDUSTRIAL MONITORING AND SECURITY
3y 1m to grant Granted Jun 16, 2026
Patent 12634254
RETENTION MODEL MANAGEMENT FOR CHAT CONVERSATIONS
2y 0m to grant Granted May 19, 2026
Patent 12627560
SOFTWARE-DEFINED TRAFFIC ROUTING MESH NETWORK MODIFICATIONS
2y 9m to grant Granted May 12, 2026
Patent 12615213
Method and Device for Controlling Power Internet of Things Flow, and Computer Program Product
1y 8m to grant Granted Apr 28, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

2-3
Expected OA Rounds
68%
Grant Probability
99%
With Interview (+38.3%)
2y 11m (~1y 0m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 308 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month