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 .
Drawings
Figures 4, 5 and 8 are objected to because the texts within the figures are illegible/blurred. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
---------- ---------- ----------
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 6th February 2026 and 25th June 2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
========== ========== ==========
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1 – 7, 9, 10 – 18 5, 17, 18 – 23 and 25 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Ranalli (US 2023/0362299 A1).
Claim 1. Ranalli shows a method (abstract) comprising: receiving, by a computing device (figs. 1A/1B: terminating service provide 104), a call initiation message (figs. 1A/1B and [0070]: when initiating or otherwise placing a call, enterprise calling party 100 generates or includes verified calling party information 102 in a call initiation request); determining the call initiation message comprises rich call data (RCD) ([0075]: the enterprise calling party 100 can include verified calling party information 102 with an outbound call by including a cryptographically signed RCD PASSporT in the SIP call initiation signaling); determining a recipient user device is not configured to process the RCD ([0071]: originating service provider 101 can receive a portion of verified calling party information 102 from the enterprise calling party 100 (e.g. the reason for the particular call that is the subject of the call initiation request) and subsequently generate the verified calling party information 102 by augmenting the received portion of calling party information with the remaining or missing portion(s) of calling party information; [0076]: an RCD PASSporT signing function 120 and a call placement service (CPS) database 130, which can be utilized to provide an out-of-band mechanism that allows terminating service provider 104 to obtain or retrieve missing RCD and/or SHAKEN PASSporTs associated with a specific call); repackaging the RCD ([0064]: a plurality of calling party attributes are optionally added to a PASSporT; [0076]: an RCD PASSporT signing function 120 and a call placement service (CPS) database 130, which can be utilized to provide an out-of-band mechanism that allows terminating service provider 104 to obtain or retrieve missing RCD and/or SHAKEN PASSporTs associated with a specific call); and sending the repackaged RCD to the recipient user device ([0083]: configuring the RCD PASSporT signing function 120 to populate its RCD PASSporTs into a CPS database 130 that is available to terminating service providers can provide a useful backup mechanism for recovering lost PASSporT information; [0100]: an enterprise calling party might choose to populate multiple versions of its verified calling party information for use by one or more RCD PASSporT signing functions… the enterprise calling party indicates to an RCD PASSporT signing function which version of its verified calling party information (or certain attributes of its verified calling party information) should be used for a particular call).
Claim 2. Ranalli shows the method of claim 1, wherein the computing device comprises one or more of: a switch device (fig. 7: the server may be a “switch”), a STIR/SHAKEN device ([0061]: the DCS and other aspects of the present disclosure can be configured to be implemented within the STIR/SHAKEN framework), or an RCD device ([0069]: the system further includes an RCD PASSporT signing function).
Claim 3. Ranalli shows the method of claim 1, wherein determining the recipient user device is not configured to process the RCD comprises determining one or more user device identifiers associated with the recipient user device ([0099]: the stored verified calling party information can be provided by one or more enterprise vetting services that authenticate one or more attributes such as the identity of an enterprise and/or the enterprise’s calling party information (e.g. calling TNs, calling party name, logo/icon, call reason)).
Claim 4. Ranalli shows the method of claim 1, wherein repackaging the RCD comprises converting one or more RCD claims to a display name in an SIP invite ([0096]: the originating service provider 101 including both an enterprise signed RCD PASSporT and a service provider signed SHAKEN PASSporT in the SIP INVITE call initiation message that is passed to the terminating service provider; [0102]: the instructions passed by the calling party device can comprise an optional parameter in the SIP FROM header (e.g. display=professional, display=personal)).
Claim 5. Ranalli shows the method of claim 1, wherein repackaging the RCD comprises determining one or more packet headers ([0091]: retrieve a cryptographically signed RCD PASSporT that is encoded and returned in the form of a SIP IDENTITY header).
Claim 6. Ranalli shows the method of claim 1, wherein repackaging the RCD comprises determining one or more display attributes associated with the recipient user device ([0102]: the SIP server responsible for making an API call to the RCD PASSporT signing function would then look for the optional display parameter in the FROM header and in response, populate the correct optional parameter in the HTTPS/JSON call signing request that the SIP server submits to the RCD PASSporT signing function).
Claim 7. Ranalli shows the method of claim 1, further comprising causing the recipient user device to output the repackaged RCD ([0083]: configuring the RCD PASSporT signing function 120 to populate its RCD PASSporTs into a CPS database 130 that is available to terminating service providers can provide a useful backup mechanism for recovering lost PASSporT information; [0100]: an enterprise calling party might choose to populate multiple versions of its verified calling party information for use by one or more RCD PASSporT signing functions… the enterprise calling party indicates to an RCD PASSporT signing function which version of its verified calling party information (or certain attributes of its verified calling party information) should be used for a particular call).
Claim 9. Ranalli shows the method of claim 1, further comprising sending the RCD to a database ([0064]: a plurality of calling party attributes are optionally added to a PASSporT; [0076]: an RCD PASSporT signing function 120 and a call placement service (CPS) database 130, which can be utilized to provide an out-of-band mechanism that allows terminating service provider 104 to obtain or retrieve missing RCD and/or SHAKEN PASSporTs associated with a specific call; [0083]: configuring the RCD PASSporT signing function 120 to populate its RCD PASSporTs into a CPS database 130 that is available to terminating service providers can provide a useful backup mechanism for recovering lost PASSporT information).
---------- ---------- ----------
Claim 10. Ranalli shows a method (abstract) comprising: receiving, by a first computing device (figs. 1A/1B: terminating service provide 104), a call initiation message comprising rich call data (RCD) and one or more user device identifiers associated with a user device (figs. 1A/1B and [0070]: when initiating or otherwise placing a call, enterprise calling party 100 generates or includes verified calling party information 102 in a call initiation request); determining, based on the one or more user device identifiers, the user device is not configured to process the RCD ([0071]: originating service provider 101 can receive a portion of verified calling party information 102 from the enterprise calling party 100 (e.g. the reason for the particular call that is the subject of the call initiation request) and subsequently generate the verified calling party information 102 by augmenting the received portion of calling party information with the remaining or missing portion(s) of calling party information; [0076]: an RCD PASSporT signing function 120 and a call placement service (CPS) database 130, which can be utilized to provide an out-of-band mechanism that allows terminating service provider 104 to obtain or retrieve missing RCD and/or SHAKEN PASSporTs associated with a specific call); sending, to a second computing device, the RCD ([0075]: the enterprise calling party 100 can include verified calling party information 102 with an outbound call by including a cryptographically signed RCD PASSporT in the SIP call initiation signaling); receiving, from the second computing device, repackaged RCD ([0064]: a plurality of calling party attributes are optionally added to a PASSporT; [0076]: an RCD PASSporT signing function 120 and a call placement service (CPS) database 130, which can be utilized to provide an out-of-band mechanism that allows terminating service provider 104 to obtain or retrieve missing RCD and/or SHAKEN PASSporTs associated with a specific call); and sending, to the user device, the repackaged RCD ([0083]: configuring the RCD PASSporT signing function 120 to populate its RCD PASSporTs into a CPS database 130 that is available to terminating service providers can provide a useful backup mechanism for recovering lost PASSporT information; [0100]: an enterprise calling party might choose to populate multiple versions of its verified calling party information for use by one or more RCD PASSporT signing functions… the enterprise calling party indicates to an RCD PASSporT signing function which version of its verified calling party information (or certain attributes of its verified calling party information) should be used for a particular call).
Claim 11. Ranalli shows the method of claim 10, wherein the first computing device comprises a switch (fig. 7: the server may be a “switch”) and wherein the second computing device comprises a STIR/SHAKEN server ([0061]: the DCS and other aspects of the present disclosure can be configured to be implemented within the STIR/SHAKEN framework).
Claim 12. Ranalli shows the method of claim 10, wherein the user device is configured to process session initiation protocol (SIP) invites ([0096]: the originating service provider 101 including both an enterprise signed RCD PASSporT and a service provider signed SHAKEN PASSporT in the SIP INVITE call initiation message that is passed to the terminating service provider; [0102]: the instructions passed by the calling party device can comprise an optional parameter in the SIP FROM header (e.g. display=professional, display=personal)).
Claim 13. Ranalli shows the method of claim 10, wherein the repackaged RCD comprises one or more display names associated with the RCD ([0100]: indication of the desired call reason can come in the form of an optional parameter passed in an HTTPS/JSON request to the RCD PASSporT signing function… applied to selection of a specific verified enterprise name (e.g. “Home Depot”, “Home Depot Delivery”, “Home Depot Finance”), enterprise logo or other verified enterprise calling party attribute(s) that are stored).
Claim 14. Ranalli shows the method of claim 10, wherein determining the user device is not configured to process the RCD comprises determining one or more output capabilities associated with the user device ([0039]: the subset of verified calling party attributes received by the call recipient communication device is generated based at least in part on one or more display capabilities of the call recipient communication device, such that a given verified calling party attribute is excluded from the subset in response to a determination that the given verified calling party attribute is incompatible with the display capability properties of the call recipient communication device).
Claim 15. Ranalli shows the method of claim 10, further comprising causing the user device to output the repackaged RCD ([0083]: configuring the RCD PASSporT signing function 120 to populate its RCD PASSporTs into a CPS database 130 that is available to terminating service providers can provide a useful backup mechanism for recovering lost PASSporT information; [0100]: an enterprise calling party might choose to populate multiple versions of its verified calling party information for use by one or more RCD PASSporT signing functions… the enterprise calling party indicates to an RCD PASSporT signing function which version of its verified calling party information (or certain attributes of its verified calling party information) should be used for a particular call).
Claim 17. Ranalli shows the method of claim 10, further comprising determining, based on the one or more user device identifiers, a verification status associated with the user device ([0099]: the stored verified calling party information can be provided by one or more enterprise vetting services that authenticate one or more attributes such as the identity of an enterprise and/or the enterprise’s calling party information (e.g. calling TNs, calling party name, logo/icon, call reason)).
---------- ---------- ----------
Claim 18. Ranalli shows a method (abstract) comprising: sending, to a user device (figs. 1A/1B: call recipient (device) 105/107), by a computing device (figs. 1A/1B: enterprise calling party 102), based on a determination that the user device is not configured to process rich call data (RCD), repackaged RCD (figs. 1A/1B and [0070]: when initiating or otherwise placing a call, enterprise calling party 100 generates or includes verified calling party information 102 in a call initiation request; [0071]: originating service provider 101 can receive a portion of verified calling party information 102 from the enterprise calling party 100 (e.g. the reason for the particular call that is the subject of the call initiation request) and subsequently generate the verified calling party information 102 by augmenting the received portion of calling party information with the remaining or missing portion(s) of calling party information; [0076]: an RCD PASSporT signing function 120 and a call placement service (CPS) database 130, which can be utilized to provide an out-of-band mechanism that allows terminating service provider 104 to obtain or retrieve missing RCD and/or SHAKEN PASSporTs associated with a specific call); causing the user device to output the repackaged RCD ([0064]: a plurality of calling party attributes are optionally added to a PASSporT; [0076]: an RCD PASSporT signing function 120 and a call placement service (CPS) database 130, which can be utilized to provide an out-of-band mechanism that allows terminating service provider 104 to obtain or retrieve missing RCD and/or SHAKEN PASSporTs associated with a specific call); updating, based on a session renegotiation, the repackaged RCD data ([0104]: the use of distributed ledger technology (“DLT”) for exchanging verified calling party information between calling and called parties and their selected service providers; [0105]: the call recipient device can fulfill the displaying step by first verify the signature contained in the RCD PASSporT to confirm that the PASSporT was signed by an approved SHAKEN entity, and to confirm that the verified calling party information contained in the PASSporT was not manipulated in transit, before presenting all or part of the verified calling party information to the call recipient); and sending, to the user device, the updated repackaged RCD data ([0083]: configuring the RCD PASSporT signing function 120 to populate its RCD PASSporTs into a CPS database 130 that is available to terminating service providers can provide a useful backup mechanism for recovering lost PASSporT information; [0100]: an enterprise calling party might choose to populate multiple versions of its verified calling party information for use by one or more RCD PASSporT signing functions… the enterprise calling party indicates to an RCD PASSporT signing function which version of its verified calling party information (or certain attributes of its verified calling party information) should be used for a particular call).
Claim 19. Ranalli shows the method of claim 18, wherein the computing device comprises a switch (fig. 7: the server may be a “switch”).
Claim 20. Ranalli shows the method of claim 18, wherein the user device comprises a device configured to process session initiation protocol (SIP) data ([0096]: the originating service provider 101 including both an enterprise signed RCD PASSporT and a service provider signed SHAKEN PASSporT in the SIP INVITE call initiation message that is passed to the terminating service provider; [0102]: the instructions passed by the calling party device can comprise an optional parameter in the SIP FROM header (e.g. display=professional, display=personal)).
Claim 21. Ranalli shows the method of claim 18, wherein the RCD comprises one or more user identifiers ([0099]: the stored verified calling party information can be provided by one or more enterprise vetting services that authenticate one or more attributes such as the identity of an enterprise and/or the enterprise’s calling party information (e.g. calling TNs, calling party name, logo/icon, call reason)).
Claim 22. Ranalli shows the method of claim 18, wherein the RCD comprises one or more claims and wherein the computing device is configured to determine the repackaged RCD by parsing the one or more claims ([0083]: configuring the RCD PASSporT signing function 120 to populate its RCD PASSporTs into a CPS database 130 that is available to terminating service providers can provide a useful backup mechanism for recovering lost PASSporT information; [0100]: an enterprise calling party might choose to populate multiple versions of its verified calling party information for use by one or more RCD PASSporT signing functions… the enterprise calling party indicates to an RCD PASSporT signing function which version of its verified calling party information (or certain attributes of its verified calling party information) should be used for a particular call).
Claim 23. Ranalli shows the method of claim 18, wherein the computing device is configured to determine the repackaged RCD by parsing one or more packet headers associated with a call initiation message ([0091]: retrieve a cryptographically signed RCD PASSporT that is encoded and returned in the form of a SIP IDENTITY header).
Claim 25. Ranalli shows the method of claim 18, further comprising causing the user device to output the updated repackaged RCD ([0064]: a plurality of calling party attributes are optionally added to a PASSporT; [0076]: an RCD PASSporT signing function 120 and a call placement service (CPS) database 130, which can be utilized to provide an out-of-band mechanism that allows terminating service provider 104 to obtain or retrieve missing RCD and/or SHAKEN PASSporTs associated with a specific call; [0083]: configuring the RCD PASSporT signing function 120 to populate its RCD PASSporTs into a CPS database 130 that is available to terminating service providers can provide a useful backup mechanism for recovering lost PASSporT information; [0100]: an enterprise calling party might choose to populate multiple versions of its verified calling party information for use by one or more RCD PASSporT signing functions… the enterprise calling party indicates to an RCD PASSporT signing function which version of its verified calling party information (or certain attributes of its verified calling party information) should be used for a particular call).
----------- ---------- ----------
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, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 8, 16 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Ranalli in view of Cook et al (US 2024/0171619 A1).
Claim 8. Ranalli shows the method of claim 1; Ranalli does not expressly describe the method further comprising converting one or more RCD claims to audio data.Cook teaches feature of converting one or more RCD claims to audio data ([0039]: the RCD extension can include a URL to text, video, or audio content to be retrieved from the CDN).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the audio feature as taught by Cook in the method of Ranalli to facilitate a better user experience.
Claim 16. Ranalli shows the method of claim 15; Ranalli does not expressly describe wherein causing the user device to output the repackaged RCD comprises: causing the user device to convert the repackaged RCD into audio data; and causing the user device to output the audio data.Cook teaches features of: causing a user device to convert the repackaged RCD into audio data ([0039] and [0040]: the RCD extension can include a URL to text, video, or audio content to be retrieved from the CDN); and causing the user device to output the audio data ([0039] and [0040]: the user of the device receives an alert indicating of an incoming voice call (e.g. an alert sound and/or vibration), the device concurrently displays the graphical object on its display).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the audio feature as taught by Cook in the method of Ranalli to facilitate a better user experience.
Claim 26. Ranalli shows the method of claim 25; Ranalli does not expressly describe wherein causing the user device to output the updated repackaged RCD comprises: causing the user device to convert the updated repackaged RCD to audio data; and causing the user device to output the audio data.Cook teaches features of: causing a user device to convert the updated repackaged RCD to audio data ([0039]: the RCD extension can include a URL to text, video, or audio content to be retrieved from the CDN); and causing the user device to output the audio data ([0039] and [0040]: the user of the device receives an alert indicating of an incoming voice call (e.g. an alert sound and/or vibration), the device concurrently displays the graphical object on its display).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the audio feature as taught by Cook in the method of Ranalli to facilitate a better user experience.
----------- ----------- -----------
Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over Ranalli in view of Murthy et al (US 2022/0329690 A1).
Claim 24. Ranalli shows the method of claim 18; Ranalli does not expressly describe wherein the updated repackaged RCD data comprises one or more advertisements.Murthy teaches feature of an updated RCD data comprising an advertisement ([0038] – [0039]: call content management of content in associations with calls to and from mobile device users wherein enterprise entities (e.g. government, corporate, etc.) may desire to have their services readily identified to mobile device users when providing appointments, services, advertising, etc. … a process to directly inject rich call data (RCD) metadata via a data object, such as a JAVASCRIPT object notation (JSON) object, directly into the call information header using specific in-network and call enhancement (ECI) tools and procedures).It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the advertisements as taught in Murthy in the repackaged RCD data of Ranalli to increase answer rates, avoid spam blocks and builds immediate brand recognition before a user phone is even picked up.
========== ========== ==========
Conclusion
The prior art made of record is considered pertinent to applicant’s disclosure.
Castellanos Zamora et al, US 2026/0181026 A1: a method for handling a call from a calling device which includes receiving a call initiation message (e.g. SIP INVITE message) for setting up a call between the calling device (e.g.,
PBX or SIP UA) and a callee device, the call initiation message comprising a user identity (e.g. an IMPU) and the method also includes, after receiving the call initiation message, determining whether user information associated with the user identity indicates that use of a third-party, 3P, identifier, ID, is authorized.
2. Jaffer et al, US 2026/0025459 A1: a system can receives communication associated with a caller requesting to make a telephone call to a recipient, where the communication includes a recipient identifier associated with the recipient.
3. Ranalli, US 2022/0086276 A1: a system for display confirmation of verified calling party attributes at the time of call establishment.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Xavier Szewai Wong whose telephone number is 571.270.1780. The examiner can normally be reached on 11:30 am - 8:30 pm Mon to Fri.
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, Jeffrey Rutkowski can be reached on 571.270.1215. 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.
/XAVIER S WONG/Primary Examiner, Art Unit 2415 6th August 2026
Prosecution Insights