Prosecution Insights
Last updated: October 02, 2026
Application No. 17/906,746

COMMUNICATION SYSTEM AND COMMUNICATION CONTROL METHOD

Non-Final OA §103
Filed
Sep 19, 2022
Priority
May 31, 2021 — nonprovisional of PCT/JP2021/020675 +1 more
Examiner
SIDDIQUEE, INTEKHAAB AALAM
Art Unit
2462
Tech Center
2400 — Computer Networks
Assignee
Rakuten Mobile Inc.
OA Round
4 (Non-Final)
82%
Grant Probability
Favorable
4-5
OA Rounds
0m
Est. Remaining
84%
With Interview

Examiner Intelligence

Grants 82% — above average
82%
Career Allowance Rate
255 granted / 313 resolved
+23.5% vs TC avg
Minimal +2% lift
Without
With
+2.3%
Interview Lift
resolved cases with interview
Typical timeline
2y 6m
Avg Prosecution
22 currently pending
Career history
335
Total Applications
across all art units

Statute-Specific Performance

§101
2.0%
-38.0% vs TC avg
§103
75.6%
+35.6% vs TC avg
§102
9.3%
-30.7% vs TC avg
§112
6.5%
-33.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 313 resolved cases

Office Action

§103
DETAILED ACTION This second non-final office action is submitted in response to applicant’s response filed on 6/21/2026, because of introduction of new prior art not used in the previous non-final office action and more relevant to the claims of the application. 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 . Claim status Claims 9-12 are newly added Claims 1-12 are pending for examination Response to arguments Regarding 35 U.S.C. 103 rejection Applicant’s response has been fully considered. Most of the arguments are moot in view of introduction of new prior art. Response to arguments which are related to the prior arts used in earlier office action, is provided in the respective portions of the next section. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claims 1-8 are rejected under 35 U.S.C. 103 as being unpatentable over Thomas et al.( US 11,750,441 B1), hereinafter “Thomas”, in view of Addepalli et al. (US 9,258,234 B1), hereinafter, “Addepalli”. Claims 1 and 7: Regarding claim 1, Thomas teaches a communication system, comprising: at least one processor; and at least one memory device (Thomas: Fig.2) storing instructions which, when executed by the at least one processor, cause the at least one processor to perform operations comprising: executing a first bidirectional forwarding detection daemon (bfdd) which transmits and receives BFD packets to and from a second bfdd which is a bfdd included in a communication partner of the communication system (Thomas: Col.7, lines 1-5, a packet management (PPM) daemon executing on an SCC 122 of multi-chassis router 4 may generate a periodic packet using a link-level keep-alive protocol and send the packet to neighboring devices and/or nodes at a periodic interval … Examples of link level keep-alive protocols may include a system heartbeat, the Trivial Network Protocol (TNP) developed by Juniper Networks of Sunnyvale, Calif., Bidirectional Forward Detection (BFD) protocol, etc.; and lines 22-28, “connectivity between two nodes ( e.g., SCC 122A and LCC 128A) may go down; that is, one or 30 more links 136 may become unavailable. A link level keep-alive protocol, such as BFD, may be used to detect a connectivity failure between two adjacent nodes, including interfaces and data links. For example, in BFD operation, nodes exchange hello packets at a specified time interval and detect a neighbor failure if no reply is received within the specified time interval.). Thomas teaches about communication partners in Col.7, lines 1-5, “a packet management (PPM) daemon executing on an SCC 122 of multi-chassis router 4 may generate a periodic packet using a link-level keep-alive protocol and send the packet to neighboring devices and/or nodes at a periodic interval,”, where the neighboring devices may be considered as communication partners, and IP address of a bfdd in Col. 13, lines 16-25, “error modules 324 may be configured to communicate with BFD daemons 318. This is just one example, error modules 324 may be configured to communicate with any type of link level keep-alive protocol. In one example, BFD 318A may detect an error on a link 370 20 between SCC 122A and LCC 128A. Error module 324A may be configured to read this error and determine the source IP address (e.g., the IP address of SCC 122A) and the destination IP address (e.g., the IP address of LCC 128A) affected by the detected link failure.”. Thomas however fails to expressly teach, restricting, in response to detection of no transmission of BFD packets from the second bfdd, transmission of the bidirectional forwarding detection (BFD) packets to the second bfdd by the first bfdd. Addepalli teaches the claim, implied by the following disclosures: Col.3, ll.25-33 “In cases of network congestion over the link, the router increases the BFD detection timer, thereby allowing for congestion-based delays in receiving BFD packets before identifying a link failure and terminating the BFD session. By avoiding terminating the BFD session due to false alarms, the router may conserve computing time and resources that it would otherwise expend in updating its routing information base (RIB) and corresponding forwarding information base (FIB).”; and Col.7, ll. 29-37“router 12A, implements the techniques of this disclosure to dynamically adjust the session detection time defined by respective adjacency timer based on current congestion conditions over service provider network 20. More specifically, in accordance with the techniques, router 12A is configured to increase the session detection time defined by the adjacency timer during certain greater congestion conditions, and to reduce the session detection time during lesser congestion conditions.”. Determining a congestion means some packets not received in negotiated time. Dynamically adjusting session detection time implies restriction as claimed. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine disclosure by Addepalli with that of Thomas and come up with the claimed invention motivated by avoiding false alarm, as disclosed by Addepalli, “inflexibility of a static BFD detection timer may cause a router to either trigger false alarms in terms of link failure, or to detect a link failure after a time delay. More specifically, false alarms occur in cases where the router 10 detects a link failure due to a congestion-based delay of an arriving BFD packet”. (Col. 3, ll. 7-12). The claim, releasing the restriction for transmission of the BFD packets in response to the first bfdd receiving address information for a third bfdd which is a bfdd included in the communication partner, is implied by combination of disclosures in Thomas and in Addepalli. Thomas discloses communication with bfdd different from the first bfdd by creation of a new TCP socket (Col. 14, ll. 1-3, “a link failure to LCC 128A, protocol stack 322A may create new TCP sockets 320A to another of LCCs 128 (e.g., LCC 128B).”). Addepalli discloses IP addresses associated with BFD daemons (Col.7, ll. 62-65, “IP packet header, wherein the source and destination addresses of the received IP packet match the IP addresses of the BFD session endpoints.”; and disclosure in Addepalli regarding switching of BFD timer based on presence or absence of congestion, as disclosed in “binary adjustment of the BFD detection timer, i.e., a switch between two possible values based on a presence or absence of congestion” (Col.7, ll. 57-59); The switch to the third bfdd is a new session and restriction is not to be considered at the start of the session.” Regarding the claim, wherein the IP address of the third bfdd is different from an IP address of the second bfdd, it is obvious that when a session is created with a different node, the IP address of the BFD daemon would also be different, that is the third bfdd, the new one, will have IP address different from the second one, the one released. would also be different. Thomas does not teach but the claim, the address information indicates that the third bfdd was recovered in response to a node failure in the communication partner, but is implied by disclosure in Addepalli, Col. 7, ll. 60-65, “router 12A may toggle the value of the failure threshold between a high and low multiple of the BFD interval based on an ECN field, of any received. IP packet header, wherein the source and destination addresses of the received IP packet match the IP addresses of the BFD session endpoints.”. When communication with the third bfdd is started, initially the ECN field will be low multiple of BFD interval, which will imply the bfdd was recovered after a node failure (the ECN field must have been high before the failure). It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine disclosure by Addepalli with that of Thomas and come up with the claimed invention motivated by starting a new bfdd daemon and freshly starting negotiation of bfd interval. Regarding claim 7, it is change in category with respect to claim 1. Claim elements are discussed above in claim 1. Claim is rejected based on rejection of claim 1. Regarding claim 2, combination of Thomas and Addepalli teaches the communication system according to claim 1 (discussed above), wherein the restricting comprises lengthening, in response to the detection, an interval of the transmission of the BFD packets to the second bfdd by the first bfdd (discussed above in Clm.1). Regarding claim 3, combination of Thomas and Addepalli teaches the communication system according to claim 1 (discussed above), wherein the restricting comprises stopping, in response to the detection, the transmission of the BFD packets to the second bfdd by the first bfdd (implied by disclosure in Addepalli, “in response to a failure to receive a BFD packet within the session detection time defined by the timer, detect a failure of the link.“; detection of link failure will stop transmission of BFD packets.). Regarding claim 4, combination of Thomas and Addepalli teaches the communication system according to claim 1 (discussed above), operations further comprise: outputting, in response to the releasing the restriction, an instruction to change a pairing from the second bfdd to the third bfdd (implied based on the disclosures discussed above in claim 1, and disclosure by Thomas, “The backup node may restart and/or maintain the process executed by the local node over a different TCP socket.” (Col.11, lines 16-18)”. Regarding claim 5, combination of Thomas and Addepalli teaches the communication system according to claim 4 (discussed above), wherein the releasing comprises releasing the restriction on the transmission of the BFD packets to the third bfdd from the first bfdd (implied by disclosure in Addepalli regarding switching of BFD timer based on presence or absence of congestion, as disclosed in “binary adjustment of the BFD detection timer, i.e., a switch between two possible values based on a presence or absence of congestion” (Col.7, ll. 57-59); The switch to the third bfdd is a new session and restriction is not to be considered at the start of the session.) Regarding claim 6, combination of Thomas and Addepalli teaches the communication system according to claim 4 (discussed above), wherein the operations further comprise accessing a storage which stores address data indicating an address of the bfdd included in the communication partner to acquire the address data, wherein the releasing comprises releasing the restriction on the transmission of the BFD packets in response to detection of a change in the address indicated by the address data (implied by discussion in Clm.1 and disclosure in Thomas in Col.7, lines 22-28, “if node SCC 122A detects a failure of node LCC128A, a routing table may be updated, and traffic may be routed to other ones of LCCs 128 ( e.g., LCC 128B, LCC 128C, etc.). In addition, if a failure of SCC 122A is detected, multi-chassis router may be configured to perform a failover process so that a backup SCC (e.g., SCC 122B) may take over the control responsibilities of SCC 122A.”. When a backup SCC takes over, the address is changed, and the BFD process should be back to normal, and restriction released. Claim 8 is regarding, a communication system, comprising: at least one processor; and at least one memory device storing instructions which, when executed by the at least one processor, cause the at least one processor to perform operations comprising: executing a first bidirectional forwarding detection daemon (bfdd) which transmits and receives bidirectional forwarding detection (BFD) packets to and from a second bfdd which is a bfdd included in a communication partner of the communication system, wherein the BFD packets have a first interval of transmission ; and restricting, in response to detection of no transmission of BFD packets from the second bfdd, transmission of the BFD packets to the second bfdd by the first bfdd (discussed above in claim 1 where the first interval of transmission is the periodic interval discussed above in claim 1), wherein the restricting comprises lengthening, in response to the detection, an interval of the transmission of the BFD packets to the second bfdd by the first bfdd to a second interval (discussed above in claim 2) of 20 seconds to 60 seconds, and the second interval is longer than the first interval (as discussed above in claim 2, the lengthening of interval implies that second interval is longer than the first interval; exactly how much the interval would be is implementation dependent and level of congestion, as per discussion in Addepalli, Col.15, ll. 9-15, “The attributes determined from the BFD packet may include data pertaining to congestion over the network, such as granular congestion data. More specifically, the granular congestion data may indicate levels of congestion, such as high-, mid-, and low levels of congestion, or a specific value to denote the severity of the congestion.”). Claims 9 and 11: Regarding claim 9, combination of Thomas and Addepalli teaches the communication system according to claim 1 (discussed above), wherein the operations further comprise: outputting, in response to the releasing the restriction, an instruction to establish a BFD session with the third bfdd, wherein BFD packets are transmitted at intervals of several milliseconds in the BFD session with the third bfdd (implied by discussions about connecting to third bfdd after failure of first bfdd as discussed in claim 1 and disclosure in Addepalli, “For example, a router may send periodic packets to a peer router 40 every 50 milliseconds (ms) to indicate that the router is still operational”). Regarding claim 11, claim elements are discussed above in claim 9. Claims 10 and 12: Regarding claim 10, combination of Thomas and Addepalli teaches the communication system according to claim 1 (discussed above), wherein the operations further comprise: updating address data registered in a data store unit of the communication system to address data indicating an IP address of the third bfdd in response to the releasing the restriction (implied by disclosures in Thomas: Col.6, ll. 20-24, “Master routing engine 126 periodically updates the routing information to accurately reflect the current network topology. Master routing engine 126 also uses the routing information to derive forwarding information bases (FIBs ).”; Col.7 “if node SCC 122A detects a failure of node LCC 128A, a routing table may be updated, and traffic may be routed to other ones of LCCs 128 ( e.g., LCC 128B, LCC 128C, etc.). In addition, if a failure of SCC 122A is detected, multi-chassis router may be configured to perform a failover process so that a backup SCC (e.g., SCC 122B) may take over the control responsibilities of SCC 122A.”). Regarding claim 12, claim elements are discussed above in claim 10. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to INTEKHAAB AALAM SIDDIQUEE whose telephone number is (571)272-0895. The examiner can normally be reached Monday to Friday 9AM-5PM EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yemane Mesfin can be reached at 571-272-3927. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /INTEKHAAB A SIDDIQUEE/Primary Examiner, Art Unit 2462
Read full office action

Prosecution Timeline

Show 6 earlier events
Feb 05, 2026
Interview Requested
Feb 11, 2026
Examiner Interview Summary
Feb 11, 2026
Applicant Interview (Telephonic)
Mar 05, 2026
Request for Continued Examination
Mar 17, 2026
Response after Non-Final Action
Mar 23, 2026
Non-Final Rejection mailed — §103
Jun 21, 2026
Response Filed
Sep 10, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12739934
Methods, Node, UE and Computer Readable Media for Aligning Partial Sensing Configuration with DRX Configuration
2y 12m to grant Granted Sep 15, 2026
Patent 12732825
METHODS AND APPARATUSES FOR TRANSFERRING OF SHARED RADIO FREQUENCY BAND ACCESS INDICATIONS
3y 3m to grant Granted Sep 08, 2026
Patent 12726240
SIGNAL PROCESSING METHOD AND APPARATUS, NODE, STORAGE MEDIUM AND SYSTEM
2y 9m to grant Granted Sep 01, 2026
Patent 12719636
COMMUNICATION METHOD AND APPARATUS
3y 11m to grant Granted Aug 25, 2026
Patent 12706687
COMMUNICATION METHOD AND APPARATUS
2y 4m to grant Granted Aug 11, 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

4-5
Expected OA Rounds
82%
Grant Probability
84%
With Interview (+2.3%)
2y 6m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 313 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