DETAILED ACTION
This Office Action is in response to Applicants’ Application filed on July 23, 2024. Claims 1-14 are pending and presented for 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 .
Specification
The disclosure is objected to because of the following informalities: the status of the Cross-Reference to Related Applications in paragraph 0001 needs to be updated.
Appropriate correction is required.
Double Patenting
A rejection based on double patenting of the “same invention” type finds its support in the language of 35 U.S.C. 101 which states that “whoever invents or discovers any new and useful process... may obtain a patent therefor...” (Emphasis added). Thus, the term “same invention,” in this context, means an invention drawn to identical subject matter. See Miller v. Eagle Mfg. Co., 151 U.S. 186 (1894); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Ockert, 245 F.2d 467, 114 USPQ 330 (CCPA 1957).
A statutory type (35 U.S.C. 101) double patenting rejection can be overcome by canceling or amending the claims that are directed to the same invention so they are no longer coextensive in scope. The filing of a terminal disclaimer cannot overcome a double patenting rejection based upon 35 U.S.C. 101.
Claims 1-14 is/are rejected under 35 U.S.C. 101 as claiming the same invention as that of claims 1-14 of prior U.S. Patent No. 12/047431. This is a statutory double patenting rejection.
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.
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.
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.
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
September 22, 2025