DETAILED ACTION
Response to Amendment
This Office Action is in response to Applicants’ Amendment filed on March 24, 2026. Claims 1 and 8 have been amended. Claims 1-14 are still pending and presented for further examination.
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 .
Response to Arguments
Applicant’s amendment, filed on 3/24/26, correcting the status of the Cross-Reference to Related Applications are sufficient to overcome the objection of the specification. Accordingly, the objection to the specification has been withdrawn.
Applicant’s amendment, filed on 3/24/26, the amendments to claims 1 and 8 are sufficient to overcome the statutory double patenting rejection. Accordingly, the statutory double patenting rejection to claims 1-14 has been withdrawn.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-14 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-14 of U.S. Pat. No. 12/047,431. Although the claims at issue are not identical, they are not patentably distinct from each other because the present application is fully disclosed in U.S. Pat. No. 12/047,431 and would be covered by any patent granted since the U.S Pat. No. 12/047,431 and the instant application are claiming common subject matter. The amended portion of the present application “marking at least two of the received messages with a specific key, enabling messages marked with a same key to be delivered in order and messages have different keys to be delivered in parallel” is similar to claim language found in dependent claim 14 of U.S. Pat. No. 12/047,431 and claim 14 of the present application.
Application 18/781,783
1. A method, comprising: spawning a first Hypertext Transfer Protocol (HTTP) connection for a first received message from a first telecom node to a telecom server, sent using a Representational State Transfer (REST) interface over HTTP; opening a second HTTP connection for a second received message from a second telecom node, to ensure the second received message is not delayed due to delay in response from the telecom server in response to the first received message from the first telecom node to the telecom server; receiving a response for the first received message and refraining from closing the first HTTP connection for a predefined idle timeout period;
delivering the response for the first received message to the first telecom node; and when a third message is received before expiration of the predefined idle timeout period, then using the first HTTP connection instead of opening a new connection; and
marking at least two of the received messages with a specific key, enabling messages marked with a same key to be delivered in order and messages have different keys to be delivered in parallel.
2. The method of claim 1, further comprising if there is no idle connection available, then using a message send buffer to queue messages to be sent.
3. The method of claim 1, further comprising using a single process for the first and the second HTTP connection.
4. The method of claim 1, further comprising when there is no idle connection available, then tracking a plurality of messages using a response wait list and a message send buffer.
5. The method of claim 1, wherein the HTTP connection is using the HTTP 1.1 protocol.
6. The method of claim 1, further comprising using a response wait list with telecom node keys to enable blocking of messages between a given telecom node to the telecom server until a response is received from the telecom server to the given telecom node.
7. The method of claim 6, further comprising: marking each message with a specific key which depends on data present in the message, wherein generated data to be delivered in sequence is marked with a same key, and wherein messages having different keys are independent of each other and re delivered parallelly; spawning a connection when a message is received and sending that message over the connection, wherein all messages with different keys are scheduled parallelly on different connections until a maximum connection limit is reached; and storing incoming messages in a buffer once the maximum connection limit is reached.
8. A non-transitory computer-readable medium including instructions which, when executed on a telecom server, cause the telecom server to perform operations comprising: spawning a first Hypertext Transfer Protocol (HTTP) connection for a first received message from a first telecom node to a telecom server, sent using a Representational State Transfer (REST) interface over HTTP;
opening a second HTTP connection for a second received message from a second telecom node, to ensure the second received message is not delayed due to delay in response from the telecom server in response to the first received message from the first telecom node to the telecom server;
receiving a response for the first received message and refraining from closing the first HTTP connection for a predefined idle timeout period; delivering the response for the first received message to the first telecom node;
when a third message is received before expiration of the predefined idle timeout period, then using the first HTTP connection instead of opening a new connection; and
marking at least two of the received messages with a specific key, enabling messages marked with a same key to be delivered in order and messages have different keys to be delivered in parallel.
9. The non-transitory computer-readable medium of claim 8, the instructions further comprising if there is no idle connection available, then using a message send buffer to queue messages to be sent.
10. The non-transitory computer-readable medium of claim 8, the instructions further comprising using a single process for the first and the second HTTP connection.
11. The non-transitory computer-readable medium of claim 8, the instructions further comprising when there is no idle connection available, then tracking a plurality of messages using a response wait list and a message send buffer.
12. The non-transitory computer-readable medium of claim 8, wherein the HTTP connection is using the HTTP 1.1 protocol.
13. The non-transitory computer-readable medium of claim 8, the instructions further comprising using a response wait list with telecom node keys to enable blocking of messages between a given telecom node to the telecom server until a response is received from the telecom server to the given telecom node.
14. The non-transitory computer-readable medium of claim 13, the instructions further comprising: marking each message with a specific key which depends on data present in the message, wherein generated data to be delivered in sequence is marked with a same key, and wherein messages having different keys are independent of each other and re delivered parallelly; spawning a connection when a message is received and sending that message over the connection, wherein all messages with different keys are scheduled parallelly on different connections until a maximum connection limit is reached; and storing incoming messages in a buffer once the maximum connection limit is reached.
U.S. Patent No. 12/047,431
1. A method, comprising: spawning a first Hypertext Transfer Protocol (HTTP) connection for a first received message from a first telecom node to a telecom server, sent using a Representational State Transfer (REST) interface over HTTP; opening a second HTTP connection for a second received message from a second telecom node, to ensure the second received message is not delayed due to delay in response from the telecom server in response to the first received message from the first telecom node to the telecom server; receiving a response for the first received message and refraining from closing the first HTTP connection for a predefined idle timeout period;
delivering the response for the first received message to the first telecom node; and when a third message is received before expiration of the predefined idle timeout period, then using the first HTTP connection instead of opening a new connection.
2. The method of claim 1, further comprising if there is no idle connection available, then using a message send buffer to queue messages to be sent.
3. The method of claim 1, further comprising using a single process for the first and the second HTTP connection.
4. The method of claim 1, further comprising when there is no idle connection available, then tracking a plurality of messages using a response wait list and a message send buffer.
5. The method of claim 1, wherein the HTTP connection is using the HTTP 1.1 protocol.
6. The method of claim 1, further comprising using a response wait list with telecom node keys to enable blocking of messages between a given telecom node to the telecom server until a response is received from the telecom server to the given telecom node.
7. The method of claim 6, further comprising: marking each message with a specific key which depends on data present in the message, wherein generated data to be delivered in sequence is marked with a same key, and wherein messages having different keys are independent of each other and re delivered parallelly; spawning a connection when a message is received and sending that message over the connection, wherein all messages with different keys are scheduled parallelly on different connections until a maximum connection limit is reached; and storing incoming messages in a buffer once the maximum connection limit is reached.
8. A non-transitory computer-readable medium including instructions which, when executed on a telecom server, cause the telecom server to perform operations comprising: spawning a first Hypertext Transfer Protocol (HTTP) connection for a first received message from a first telecom node to a telecom server, sent using a Representational State Transfer (REST) interface over HTTP;
opening a second HTTP connection for a second received message from a second telecom node, to ensure the second received message is not delayed due to delay in response from the telecom server in response to the first received message from the first telecom node to the telecom server;
receiving a response for the first received message and refraining from closing the first HTTP connection for a predefined idle timeout period; delivering the response for the first received message to the first telecom node; and
when a third message is received before expiration of the predefined idle timeout period, then using the first HTTP connection instead of opening a new connection.
9. The non-transitory computer-readable medium of claim 8, the instructions further comprising if there is no idle connection available, then using a message send buffer to queue messages to be sent.
10. The non-transitory computer-readable medium of claim 8, the instructions further comprising using a single process for the first and the second HTTP connection.
11. The non-transitory computer-readable medium of claim 8, the instructions further comprising when there is no idle connection available, then tracking a plurality of messages using a response wait list and a message send buffer.
12. The non-transitory computer-readable medium of claim 8, wherein the HTTP connection is using the HTTP 1.1 protocol.
13. The non-transitory computer-readable medium of claim 8, the instructions further comprising using a response wait list with telecom node keys to enable blocking of messages between a given telecom node to the telecom server until a response is received from the telecom server to the given telecom node.
14. The non-transitory computer-readable medium of claim 13, the instructions further comprising: marking each message with a specific key which depends on data present in the message, wherein generated data to be delivered in sequence is marked with a same key, and wherein messages having different keys are independent of each other and re delivered parallelly; spawning a connection when a message is received and sending that message over the connection, wherein all messages with different keys are scheduled parallelly on different connections until a maximum connection limit is reached; and storing incoming messages in a buffer once the maximum connection limit is reached.
Citation of Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Desai et al (U.S. Pub. No. 2023/0075944) discloses a rest resilient client-server reconciliation for telecom networks which includes determining, by a client system in a Radio Access Network (RAN) connected to a server in the RAN, a need for reconciliation with the server; terminating an HTTP connection; flushing a buffer; creating a current snapshot of the client system; sending the current snapshot to the server with an identifier for a particular server process; buffering a message at the client during reconciliation; sending a reconciliation complete message to the server to indicate that process has been completed and all the data from the client has been delivered to the server; and sending, by the client after the reconciliation is complete, the message that was buffered during the reconciliation to the server. However, Desai et al does not explicitly disclose marking at least two of the received messages with a specific key, enabling messages marked with a same key to be delivered in order and messages have different keys to be delivered in parallel.
Jung et al (U.S. Pub. No. 11,4836,790) discloses generating and registering a HTTP Rest server component for creating a control flow through configuration to handle HTTP request. Upon receipt of the HTTP request the server component issues a command to a network entity through a client component. However, Jung et al does not explicitly disclose marking at least two of the received messages with a specific key, enabling messages marked with a same key to be delivered in order and messages have different keys to be delivered in parallel.
Bethea et al (U.S. Pat. No. 7,937,703) discloses processing a batch request through a web service from a client. The bath request includes a plurality of sub-requests that each specifies an operation being performed on by the web service. Each independent request within the batch request is sequentially and dependently processed by the web service associated with the service. However, Bethea et al does not explicitly disclose marking at least two of the received messages with a specific key, enabling messages marked with a same key to be delivered in order and messages have different keys to be delivered in parallel.
Allowable Subject Matter
The following is a statement of reasons for the indication of allowable subject matter: none of the citation of the pertinent prior art above, teaches the non-obvious features of the present invention: “opening a second HTTP connection for a second received message from a second telecom node, to ensure the second received message is not delayed due to delay in response from the telecom server in response to the first received message from the first telecom node to the telecom server; receiving a response for the first received message and refraining from closing the first HTTP connection for a predefined idle timeout period; delivering the response for the first received message to the first telecom node; [[and]] when a third message is received before expiration of the predefined idle timeout period, then using the first HTTP connection instead of opening a new connection; and marking at least two of the received messages with a specific key, enabling messages marked with a same key to be delivered in order and messages having different keys to be delivered in parallel.
Claims 1-14 would be in condition for allowance if the non-statutory double-patent rejection is overcome.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LASHONDA T JACOBS-BURTON whose telephone number is (571)272-4004. The examiner can normally be reached M-F 8:30 am - 5:00 pm.
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, Ario Etienne can be reached at 571-272-4001. 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.
/LASHONDA JACOBS-BURTON/Primary Examiner, Art Unit 2457
ljb
April 29, 2026
Prosecution Insights