DETAILED ACTION
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 .
General Remarks
This communication is considered to be fully responsive to Applicant’s Application filed 08/11/2025.
Application filed: 08/11/2025
Applicant’s PgPUB: 2025/0365190
Claims:
Claims 1-20 are pending.
Claims 1, 14 and 20 are independent.
Claim 10 is objected to
IDS:
New IDS:
IDS filed 06/08/2026 has been considered.
Continuity/Priority Data:
This Application claims priority Non-Provisional Application No. 18/407,380 (Patent: 12,388,704) filed 01/08/2024
Non-Provisional Application No. 18/407,380 (Patent: 12,388,704) claims priority to Provisional Application No. 63/615,256 filed 12/27/2023.
Allowable Subject Matter
Claim 10 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Double Patenting
Claims 1-20 of this application is patentably indistinct from claims 1-23 of Application No. 18/407,380 (Patent: 12,388,704). Pursuant to 37 CFR 1.78(f), when two or more applications filed by the same applicant or assignee contain patentably indistinct claims, elimination of such claims from all but one application may be required in the absence of good and sufficient reason for their retention during pendency in more than one application. Applicant is required to either cancel the patentably indistinct claims from all but one application or maintain a clear line of demarcation between the applications. See MPEP § 822.
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-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,388,704. Although the claims at issue are not identical, they are not patentably distinct from each other because the entirety of the current claim set is included in Application No. 18/407,380 (Patent: 12,388,704). The patent is a more detailed version of the current claim set.
Application: 19296064
Claim 1)
A) A method of testing a first Session Initiation Protocol (SIP) call processing entity:
B) generating, by an automated test system, a first test case based on one or more of the following: (i) a first reference call flow record for a first SIP call or (ii) a first trace record for the first SIP call;
C) executing, by the automated test system, the first test case, said executing the first test case including sending one or more SIP messages to the first SIP call processing entity;
D) generating, by the automated test system, a first test case call flow record for a first SIP test call corresponding to the first test case; and
E) determining, by the automated test system, whether or not the first SIP call processing entity failed the first test case based on a comparison of the first test case call flow record and the first reference call flow record.
Patent: 12,388,704
Claim 1)
A) A method of testing a first Session Initiation Protocol (SIP) call processing entity in a lab environment comprising:
B) generating, by an automated test system, a first reference call flow record by: (i) extracting features from a first call detail record and a first trace record, and (ii) storing the extracted features in the first reference call flow record, said first call detail record and said first trace record both corresponding to a first SIP call, said first SIP call having been processed by a second SIP call processing entity operating in a production network;
C) generating, by the automated test system, a first test case based on the first reference call flow record for the first SIP call or the first trace record for the first SIP call;
D) executing, by the automated test system, the first test case, said executing the first test case including sending one or more SIP messages to the first SIP call processing entity;
E) generating, by the automated test system, a first test case call flow record for a first SIP test call corresponding to the first test case; and
F) determining, by the automated test system, whether or not the first SIP call processing entity failed the first test case based on a comparison of the first test case call flow record and the first reference call flow record; and
G) wherein the features extracted from the first call detail record and the first trace record include for each call leg of the first SIP call: (i) a call leg identifier, (ii) a listing of SIP messages received by the second SIP call processing entity for the call leg corresponding to the call leg identifier and an order or sequence in which the SIP messages for the call leg corresponding to the call leg identifier were received, (iii) a listing of SIP header fields included in each of the received SIP messages for the call leg corresponding to the call leg identifier; and (iv) a listing of SIP header field parameters included in each SIP header field of each of the received SIP messages for the call leg corresponding to the call leg identifier.
Reasons:
Same
Similar language
‘704, this language is only here
Similar language. The format is different but the substance is the same.
Same language
Same language
Same language
‘704, this language is only here
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 may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1-9, 12-16 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 11,509,704 B1 to Menon et al. (“Menon”) in view of U.S. Patent Application Publication No. 2004/0160896 A1 to Luna et al. (“Luna”).
As to claim 1, Menon discloses:
a method of testing a first Session Initiation Protocol (SIP) call processing entity:
generating, by an automated test system, a first test case based on one or more of the following: (i) a first reference call flow record for a first SIP call or (ii) a first trace record for the first SIP call (Abstract, col. 2 ll. 60-67, col. 3 ll. 1-12 – Menon teaches using test scripts that define logic flows (i.e., call flows) between two end points; col. 11 ll. 55-65 – Menon teaches uses of SIP);;
executing, by the automated test system, the first test case, said executing the first test case including sending one or more SIP messages to the first SIP call processing entity (Abstract, col. 2 ll. 60-67, col. 3 ll. 1-12 – Menon teaches using test scripts that define logic flows (i.e., call flows) between two end points; col. 11 ll. 55-65 – Menon teaches uses of SIP);
determining, by the automated test system, whether or not the first SIP call processing entity failed the first test case based on a comparison of the first test case call flow record and the first reference call flow record (Abstract, Fig. 1, col. 3 ll. 45-63, col. 10 ll. 4-11 – Menon teaches validating test results and determines a pass/fail based on verifying the end-to-end (E2E) flow).
Luna discloses what Menon does not expressly disclose.
Luna discloses:
generating, by the automated test system, a first test case call flow record for a first SIP test call corresponding to the first test case (¶0006, ¶0008 – Luna teaches that a call signaling analyzer that accepts the signaling packets and creates a call flow record for an active call and use of a test system); and
Menon and Luna are analogous arts because they are from the same field of endeavor with respect to call testing.
Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to incorporate creation of call flow record as discussed in Luna with call testing system as discussed in Menon by adding the functionality of Luna to the system/method of Menon in order to implement the creation of call flow records during the testing process (Luna, ¶0006).
As to claim 2, Menon and Luna discloses:
method of claim 1, and
Menon discloses:
wherein the first reference call flow record is one of a plurality of call flow records learned by the automated test system based on continuous in-production sampling of real network traffic (Abstract, col. 2 ll. 60-67, col. 3 ll. 1-12 – Menon teaches using test scripts that define logic flows (i.e., call flows) between two end points mimicking real-world scenario that a user can experience (i.e., based on in-production real network traffic); col. 11 ll. 55-65 – Menon teaches uses of SIP).
As to claim 3, Menon and Luna discloses:
method of claim 2, and
Menon discloses:
wherein the plurality of learned call flow records is a stochastic traffic model of a production network in terms of call flows processed by a SIP call processing entity of the production network (Abstract, col. 2 ll. 60-67, col. 3 ll. 1-12 – Menon teaches using test scripts that define logic flows (i.e., call flows) between two end points mimicking real-world scenario; col. 11 ll. 55-65 – Menon teaches uses of SIP).
As to claim 4, Menon and Luna discloses:
method of claim 1, and
Menon discloses:
wherein said plurality of call flow records each include a unique set of features extracted from a call detail record and a trace record for the SIP call to which the call flow record corresponds (Abstract, col. 11 ll. 55-67, col. 12 ll. 1-15 – Menon teaches using extracted field values of packets to determine the pass/fail criteria); and
wherein the first test case is one of a plurality of test cases generated from the plurality of call flow records (col. 7 ll. 20-35 – Menon teaches run multiple test cases to test a new product).
Luna discloses what Menon does not expressly disclose.
Luna discloses:
wherein the first reference call flow record is one of a plurality of call flow records generated from a plurality of non-test SIP calls processed by a second SIP call processing entity operating in a production network (¶0006, ¶0008 – Luna teaches that a call signaling analyzer that accepts the signaling packets and creates a call flow record for an active call), said second SIP call processing entity being a commercially released SIP call processing entity, said production network being a non-test customer network (Fig. 1, Fig. 2, ¶0018, ¶0019 – Luna teaches use of VoP network (5) and VoP network under test (102));
The suggestion/motivation and obviousness rejection is the same as to claim 1.
As to claim 5, Menon and Luna discloses:
method of claim 4, and
Menon discloses:
wherein the first SIP call processing entity and the second SIP call processing entity are both a first type of SIP call processing entity, the first type of SIP call processing entity being one of the following:
(i) a Session Border Controller (col. 3 ll. 64-67, col. 4 ll. 1-13 – Menon teaches use of SBCs),
(ii) a SIP Call Routing Engine,
(iii) a SIP Application Server, or
(iv) a Policy and Routing Server.
As to claim 6, Menon and Luna discloses:
method of claim 4, and
Menon discloses:
wherein said determining, by the automated test system, whether or not the first SIP call processing entity failed the first test case based on a comparison of the first test case call flow record and the first reference call flow record includes:
determining that the first SIP call processing entity failed the first test case when the comparison of the first test case call flow record and the first reference call flow record indicates that extracted features included in the first test case call flow record do not match extracted features included in the first reference call flow record (Abstract, col. 11 ll. 55-67, col. 12 ll. 1-15 – Menon teaches using extracted field values of packets to determine the pass/fail criteria)
As to claim 7, Menon and Luna discloses:
method of claim 4, and
Menon discloses:
wherein said first test case is a test script including instructions for exchanging messages with the first SIP call processing entity based on messages captured in the first trace record as being exchanged with the second SIP call processing entity during the first SIP call (Abstract, col. 2 ll. 60-67, col. 3 ll. 1-12 – Menon teaches using test scripts that define logic flows (i.e., call flows) between two end points mimicking real-world scenario that a user can experience (i.e., based on in-production real network traffic); col. 11 ll. 55-65 – Menon teaches uses of SIP).
, and
Luna discloses:
wherein said first test case is generated, by the automated test system, based on information contained in the first trace record for the first SIP call, said first SIP call corresponding to a first SIP call processed by a second SIP call processing entity operating in a production network (¶0006, ¶0008 – Luna teaches that a call signaling analyzer that accepts the signaling packets and creates a call flow record for an active call; Fig. 1, Fig. 2, ¶0018, ¶0019 – Luna teaches use of VoP network (5) and VoP network under test (102));
The suggestion/motivation and obviousness rejection is the same as to claim 1.
As to claim 8, Menon and Luna discloses:
method of claim 7, and
Menon discloses:
wherein the second SIP call processing entity is situated on the control signaling path between a first SIP endpoint device and a second SIP endpoint device, said first SIP call being between said first SIP endpoint device and said second SIP endpoint device, said messages captured in the first trace record including SIP control messages exchanged as part of establishing said first SIP call between said first SIP endpoint device and said second SIP endpoint device (Abstract, col. 2 ll. 60-67, col. 3 ll. 1-12 – Menon teaches using test scripts that define logic flows (i.e., call flows) between two end points mimicking real-world scenario that a user can experience (i.e., based on in-production real network traffic); col. 11 ll. 55-65 – Menon teaches uses of SIP. Examiner Note: control messages are only mentioned in the claims and not further described in specification. However, because Menon teaches use of SIP, message such as INVITE (i.e., control message) would be used and included in the sent messages); and
wherein the method further includes:
emulating, by the automated test system, the first SIP endpoint device and the second SIP endpoint device while executing the first test case, said emulating the first SIP endpoint device and the second SIP endpoint device including exchanging SIP control messages with the first SIP processing entity to establish the first test call (Abstract, col. 2 ll. 60-67, col. 3 ll. 1-12 – Menon teaches using test scripts that define logic flows (i.e., call flows) between two end points mimicking real-world scenario that a user can experience (i.e., based on in-production real network traffic); col. 11 ll. 55-65 – Menon teaches uses of SIP), said SIP control messages being based on said captured SIP control messages, said first test call being between the first SIP emulated endpoint device and the second emulated SIP endpoint device, said one or more SIP messages sent to the first SIP call processing entity, by the automated test system, as part of executing the first test case include said SIP control messages exchanged, by the automated test system, with the first SIP processing entity (Abstract, col. 2 ll. 60-67, col. 3 ll. 1-12 – Menon teaches using test scripts that define logic flows (i.e., call flows) between two end points mimicking real-world scenario that a user can experience (i.e., based on in-production real network traffic); col. 11 ll. 55-65 – Menon teaches uses of SIP. Examiner Note: control messages are only mentioned in the claims and not further described in specification. However, because Menon teaches use of SIP, message such as INVITE (i.e., control message) would be used and included in the sent messages).
As to claim 9, Menon and Luna discloses:
method of claim 1, and
Menon discloses:
further comprising:
generating, by the automated test system, the first reference call flow record by extracting features from a first call detail record and the first trace record, said first call detail record and said first trace record both corresponding to the first SIP call, said first SIP call having been processed by a second SIP call processing entity operating in a production network (Abstract, col. 11 ll. 55-67, col. 12 ll. 1-15 – Menon teaches using extracted field values of packets to determine the pass/fail criteria); and
storing, by the automated test system, the extracted features in the first reference call flow record (Abstract – Menon teaches The system instantiates a network probe that captures packets of the network nodes and extracts actual parameter data, which is compared to expected parameter data to generate test results relative to the pass/fail criteria. The system can present an indication that the new product passed/failed the test case based on the test results.); and
wherein said generating, by the automated test system, a first test case call flow record for the first SIP test call corresponding to the first test case includes:
generating, by the automated test system, the first test case call flow record by extracting features from a first test case call detail record and a first test case trace record (Abstract, col. 11 ll. 55-67, col. 12 ll. 1-15 – Menon teaches using extracted field values of packets to determine the pass/fail criteria), said first test case call detail record and said first test case trace record both corresponding to the first SIP test call processed by the first SIP call processing entity during the execution of the first test case, said first SIP call processing entity operating in a lab environment (Abstract, col. 2 ll. 60-67, col. 3 ll. 1-12 – Menon teaches using test scripts that define logic flows (i.e., call flows) between two end points mimicking real-world scenario that a user can experience (i.e., based on in-production real network traffic); col. 11 ll. 55-65 – Menon teaches uses of SIP); and
storing, by the automated test system, the features extracted from the first test case call detail record and the first test case trace record in the first test case call flow record (Abstract – Menon teaches The system instantiates a network probe that captures packets of the network nodes and extracts actual parameter data, which is compared to expected parameter data to generate test results relative to the pass/fail criteria. The system can present an indication that the new product passed/failed the test case based on the test results.).
As to claim 12, Menon and Luna discloses:
method of claim 1, and
Menon discloses:
wherein said executing, by the automated test system, the first test case further includes: emulating, by the automated test system, one or more devices or entities which communicate with the first SIP call processing entity during the execution of the first test case (Abstract, col. 2 ll. 60-67, col. 3 ll. 1-12 – Menon teaches using test scripts that define logic flows (i.e., call flows) between two end points mimicking real-world scenario that a user can experience (i.e., based on in-production real network traffic); col. 11 ll. 55-65 – Menon teaches uses of SIP); and
wherein said emulating the one or more devices or entities includes one or more of the following:
(i) exchanging, by the automated test system, one or more SIP messages with the first SIP call processing entity as indicated in a test script for the first test case (Abstract, col. 2 ll. 60-67, col. 3 ll. 1-12 – Menon teaches using test scripts that define logic flows (i.e., call flows) between two end points mimicking real-world scenario that a user can experience (i.e., based on in-production real network traffic); col. 11 ll. 55-65 – Menon teaches uses of SIP),
(ii) receiving, by the automated test system, one or more requests from the first SIP call processing entity sent to the one or more emulated devices or entities, and
(iii) responding as indicated in the test script for the first test case to the received requests from the first SIP call processing entity.
As to claim 13, Menon and Luna discloses:
method of claim 12, and
Menon discloses:
wherein said emulating, by the automated test system, one or more devices or entities which communicate with the first SIP call processing entity during the execution of the first test case further includes emulating the following:
a first SIP endpoint device,
a second SIP endpoint device,
a peer SIP call processing entity,
a Domain Namer Server (DNS), and
an Electronic Number Mapping System (ENUM) server.
(Abstract, col. 2 ll. 60-67, col. 3 ll. 1-12 – Menon teaches using test scripts that define logic flows (i.e., call flows) between two end points mimicking real-world scenario that a user can experience (i.e., based on in-production real network traffic); col. 11 ll. 55-65 – Menon teaches uses of SIP; Fig. 3, ¶0067 – Keeley teaches the test IMS CSCF domain name/IP address specifies a test IMS Network controlled by a testing entity. The name of the test IMS CSCF is resolvable by accessing a DNS or cache from a DNS. The test IMS Network is specially adapted to testing and providing control over tests which includes ENUM.)
As to claim 14, similar rejection as to claim 1.
As to claim 15, similar rejection as to claim 2.
As to claim 16, similar rejection as to claim 3.
As to claim 18, similar rejection as to claim 12.
As to claim 19, similar rejection as to claim 13.
As to claim 20, similar rejection as to claim 1.
Claims 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 11,509,704 B1 to Menon et al. (“Menon”) in view of U.S. Patent Application Publication No. 2004/0160896 A1 to Luna et al. (“Luna”) in further view of U.S. Patent Application No. 2024/0147268 A1 to Trivedi et al. (“Trivedi”).
As to claim 11, Menon and Luna discloses:
method of claim 1, and
Trivedi discloses what Menon and Luna do not expressly disclosed:
Trivedi discloses:
wherein said determining, by the automated test system, whether or not the first SIP call processing entity failed the first test case based on a comparison of the first test case call flow record and the first reference call flow record (¶0072 – Trivedi teaches validating a test, by the remote electronic device may include a comparison between log data for the test and a reference log or an analysis of the log data for the test using a machine-learned model) includes:
determining that the first SIP call processing entity failed the first test case when the comparison of the first test case call flow record and the first reference call flow record (¶0005 – Trivedi teaches a test from the one or more tests based on at least one of a comparison between log data for the test and a reference log or an analysis of the log data for the test using a machine-learned model; and based on the test of the performed one or more tests being unsuccessful, transmitting, from the electronic device to the test controller, information indicating the test as unsuccessful.) indicates one or more of the following:
(i) that the number of SIP messages included in the first test case call flow record and the number of SIP messages included in the first reference call record are different ((¶0005 – Trivedi teaches a test from the one or more tests based on at least one of a comparison between log data for the test and a reference log or an analysis of the log data for the test using a machine-learned model; and based on the test of the performed one or more tests being unsuccessful, transmitting, from the electronic device to the test controller, information indicating the test as unsuccessful. Examiner Note: there is nothing to suggest within Trivedi that the messages within the reference log are the same number as that of the test log.)),
(ii) that a list of SIP header fields included in each of the SIP messages included in the first test case call flow record and a list of SIP header fields included in each of the SIP messages included in the first reference call flow record are different, and
(iii) that a list of parameters included in each of the SIP header fields included in each of the SIP messages included in the first test case call flow record and a list of parameters included in each of the SIP header fields included in each of the SIP messages included in the first reference call flow record are different.
Menon, Luna and Trivedi are analogous arts because they are from the same field of endeavor with respect to call testing.
Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to incorporate testing calls with usage of reference logs as discussed in Trivedi with creation of call flow record as discussed in Luna with call testing system as discussed in Menon by adding the functionality of Trivedi to the system/method of Menon and Luna in order to test the components of the telecommunication network (Trivedi, ¶0003).
As to claim 17, similar rejection as to claim 11.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
PgPUB 2017/0373962 A1 to Keeley et al. – Keeley teaches testing a wireless device (DUT), including loading the DUT with a designation of a test APN to access through a cellular or WiFi calling wireless network.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAYLOR A ELFERVIG whose telephone number is (571)270-5687. The examiner can normally be reached Monday (10:00 AM CST) - Friday (4:00 PM CST).
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, Oscar Louie can be reached at (571) 270-1684. 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.
/TAYLOR A ELFERVIG/ Primary Examiner, Art Unit 2445
