DETAILED ACTION
The amendment to Application Ser. No. 18/670,023 filed on February 5, 2026, has been entered. Claims 1, 2-4, 6, 10, 15 and 20 are currently amended. Claims 1-20 are pending and are examined.
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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Drawings
Replacement drawings were received on February 5, 2026. These drawings are accepted.
Response to Arguments
The filing of the replacement sheet for Figure 10C has overcome the objection to the drawings set forth in the Non-Final Office Action mailed November 5, 2025. The objection to the drawings is hereby withdrawn.
The amendment to Claims 1, 4, 10, 12, 15 and 20 has overcome the objection to the claims for minor informalities set forth in the Non-Final Office Action mailed November 5, 2025. The objection to the claims for minor informalities is hereby withdrawn.
The amendment to Claims 10, 12 and 20 has overcome the rejection of Claims 10, 12 and 20 under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or joint inventor regards as the invention set forth in the Non-Final Office Action mailed November 5, 2025. The rejection of Claims 10, 12 and 20 under 35 U.S.C. 112(b) is hereby withdrawn.
The arguments with respect to the rejection of Claims 1-20 under 35 U.S.C. 103 have been fully considered by the Examiner but are not persuasive.
Specifically, on page 10 of the response filed March 13, 2019, Applicant argues, “Cook describes that the device merely requests the image using an HTTPS GET and the CDN ‘sends’ the resulting delivery confirmation message. Cook, ¶¶ [0049]-[0050]. As such, Cook does not disclose or suggest ‘causing the recipient device to indicate access,’ as claimed in claim 1.”
The Examiner respectfully disagrees. Applicant is arguing that Cook does not disclose sending of the delivery confirmation by the [wireless] device and therefore doesn’t teach the limitation in question. This is a narrow interpretation of the limitation that is not supported by the specification. Paragraph [0037] of the specification states, in part:
“The terminating receiver 409 may process the call invite. If the terminating receiver 409 is configured to access the RCD media file, it may resolve the unique RCD media file link and issue a fetch request to the RCD system 403c to receive the RCD media file (emphasis added).”
Continuing, paragraph [0038] of the specification states, in part:
“At 509, the RCD system 403c may record metrics relating to the terminating receiver 409 and its access of the RCD MEDIA. The metrics may include whether the terminating receiver 409 accessed the unique link, and when it accessed the unique link (emphasis added).”
Similar disclosure is presented in paragraphs [0041]-[0042], [0045]-[0047], [0054]-[0056], [0061]-[0063] and [0073]-[0074] of the specification. In each case, when the terminating receiver has the capability to support and output the RCD media file, the terminating receiver resolves the unique link and issues a fetch request to the RCD system to receive the RCD media file, and the RCD system records this access by updating an RCD access record associated with the link. Therefore, under broadest reasonable interpretation in view of the specification, fetching RCD content using a link included in the call invite is “causing, based on the unique link, the recipient device to indicate access of the one or more RCD media files”. Cook discloses that the wireless device, which corresponds to the recipient device of the claim, sends an HTTP GET request to retrieve the graphical object, i.e., RCD media, using the modified URL provided in the SIP invite, wherein the retrieval of the graphical object is considered as indicating the graphical object was delivered to the wireless device (see Figure 3 and paragraphs 48-50), and therefore teaches the limitation in question.
Applicant’s arguments concerning the teachings of Ranalli are moot in view of the limitation in question being taught by Cook. The rejection of Claims 1-20 under 35 U.S.C. 103 are maintained.
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.
Claims 1-3, 7, 8, 10, 11, 13, 14, 16-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Cook et al., Pub. No. US 2024/0171619 A1, hereby “Cook”, in view of Ranalli, Pub. No. US 2022/0086276 A1.
Regarding Claim 1, Cook discloses “A method (Cook fig. 3 and paragraph 37: a process for verifying the delivery of RCD to a device on a terminating end of a voice call) comprising:
receiving a call invite from an originating source (Cook figs. 2 and 3 and paragraphs 32 and 38: RCD verification subsystem 202 receives a SIP request message, i.e., a call invite, to connect a voice call from an originating source);
determining that the call invite is associated with Rich Call Data (RCD) (Cook figs. 2 and 3 and paragraphs 32, 38 and 41: RCD verification subsystem 202 modifies a URL of a Rich Call Data (RCD) extension included in the SIP request message to include a unique identifier for the voice call – while not explicitly stated, it is readily understood by one of ordinary skill that the RCD verification subsystem must necessarily determine the SIP request is associated with an RCD extension in order to modify the URL);
sending the call invite to a recipient device (Cook figs. 2 and 3 and paragraphs 35 and 48: RCD verification subsystem 202 sends the SIP request message to wireless device 204), wherein the call invite comprises:”
“an RCD header comprising a unique link encoding a location of one or more RCD media files associated with the originating source (Cook paragraphs 30, 38-40 and 48: the SIP request message includes the Rich Call Data (RCD) extension that includes the modified URL to a graphical object indicating the identity of the originating caller stored at CDN 206, i.e., an RCD media file stored on a server); and
causing, based on the unique link, the recipient device to indicate access of the one or more RCD media files (Cook figs. 2 and 3 and paragraphs 33-35, 42 and 48-50: wireless device 204 retrieves the graphical object corresponding to the modified URL included in the RCD extension from CDN 206, causing CDN 206 to indicate to RCD delivery confirmation subsystem 208 that the graphical object was delivered to wireless device 204).”
However, while Cook discloses that the SIP request message can include headers text that can identify the call originator (Cook paragraph 38), Cook does not explicitly disclose wherein the SIP request message comprises “an identity header”.
In the same field of endeavor, Ranalli discloses including a SIP IDENTITY header comprising verified calling party attribute information in a SIP INVITE call establishment message (Ranalli figs. 1 and 7 and paragraphs 12, 67-68 and 83-85: originating service provider 101 includes a SIP IDENTITY header comprising verified calling party attribute information within a SIP INVITE call establishment message).
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Cook to include a SIP IDENTITY header comprising verified calling party attribute information in the SIP request message as taught by Ranalli. One of ordinary skill in the art would have been motivated to combine including a SIP IDENTITY header comprising verified calling party attribute information in the SIP request message to enable a terminating service provider to display a validated calling party telephone number to a call recipient at the time of call establishment (Ranalli paragraph 8).
Regarding Claim 2, the combination of Cook and Ranalli discloses all of the limitations of Claim 1.
Additionally, Ranalli discloses “recording metrics relating to the recipient device, wherein the recording metrics comprise (Ranalli paragraphs 37 and 106-111: DCS 109 receives call telemetry data and call handling information relating to the outcome or end result of the call initiation request, i.e., metrics relating to the recipient device), wherein the recording metrics comprise:
an ID of the recipient device (Ranalli paragraphs 106-108 and 125: call telemetry data may include the called party number);
a first indication associated with a non-ring event (Ranalli paragraphs 37 and 110: the call handling outcome can indicate failure to establish a connection, i.e., a non-ring event); and
a second indication associated with an accepted call invite (Ranalli paragraphs 22, 37 and 110: the call handling outcome can indicate the call was answered).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Cook to collect call telemetry data and call handling information of the call associated with the display of verified calling party attributes as taught by Ranalli. One of ordinary skill in the art would have been motivated to combine collecting call telemetry data and call handling data of the call associated with the display of the verified calling party attributes to assess the value of providing the verified calling party attributes (Ranalli paragraphs 109 and 126).
Regarding Claim 3, the combination of Cook and Ranalli discloses all of the limitations of Claim 1.
Additionally, Cook discloses “receiving an indication that the recipient device received the call invite (Cook figs. 2 and 3 and paragraphs 33 and 50: RCE delivery confirmation subsystem 208 receives a delivery confirmation message indicating that the graphical object associated with the link provided by the RCD extension in the SIP request message was delivered to wireless device 204); and
determining if the recipient device is configured to access RCD (Cook figs. 2 and 3 and paragraphs 32-33 and 51: RCD delivery confirmations subsystem 208 verifies whether the graphical object linked by the RCD extension in the SIP request message, i.e., determines whether the graphical object is accessed by wireless device 204) by:
identifying an ID of the recipient device (Cook figs. 2 and 3 and paragraphs 33-34, 41 and 50: RCD delivery confirmation subsystem 208 receives delivery confirmation from CDN 206 indicating that the graphical object was provided to wireless device 204, the delivery confirmation message including a copy of the unique identifier, which may be a phone number of the wireless device);
identifying the unique link contained in the call invite (Cook figs. 2 and 3 and paragraphs 32-33 and 47: RCD delivery confirmation subsystem 208 receives and stores information regarding the SIP request message including the modified URL including the unique identifier); and
determining that the unique link contained in the call invite was accessed (Cook figs. 2 and 3 and paragraphs 33 and 50-51: RCD delivery confirmation subsystem 208 verifies the delivery of the graphical object linked by the RCD extension when the unique identifier included with the delivery confirmation message received from CDN 206 matches the unique identifier stored previously).”
Regarding Claim 7, the combination of Cook and Ranalli discloses all of the limitations of Claim 1.
Additionally, Cook discloses “wherein the one or more RCD media files comprises at least one of an interactive media file, a brand logo, or an icon (Cook paragraphs 38-40: the graphical object linked by the RCD extension may comprise a logo or icon).”
Regarding Claim 8, the combination of Cook and Ranalli discloses all of the limitations of Claim 2.
Additionally, Ranalli discloses “wherein the non-ring event is caused by the recipient device being in a non-ring state (Ranalli paragraphs 22 and 110: the call handling outcome indicating failure to establish a connection can result from the call recipient device being disconnected from the destination service provider network at the time the call was placed, i.e., being in a non-ring state).”
Regarding Claim 10, the combination of Cook and Ranalli discloses all of the limitations of Claim 1.
Additionally, Ranalli discloses “recording metrics relating to the one or more RCD media files, the recording metrics comprising one or more of delivery success rates, access data, usage data, call completion data, and revenue share data (Ranalli paragraphs 22 and 110: the call telemetry data includes a duration of the call, i.e., usage data).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Cook to collect call telemetry data and call handling information of the call associated with the display of verified calling party attributes as taught by Ranalli for the reasons set forth in the rejection of Claim 2.
Regarding Claim 11, the combination of Cook and Ranalli discloses all of the limitations of Claim 1.
Additionally, Ranalli discloses “wherein the one or more RCD media files further comprises an indication stating a reason for the call invite (Ranalli paragraphs 11-12, 67 and 73: verified calling party attributes may comprise Rich Call Data (RCD) claims that include a call reason indicating a purpose of the call initiation request).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Cook to include a call reason as the graphical object linked by the RCD extension as suggested by Ranalli because doing so constitutes a simple substitution of one known element (a logo or icon) for another (a reason for a call) to obtain predictable and desirable results (display of a reason for the call to the called party). See KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007).
Regarding Claim 13, Cook discloses “A method (Cook fig. 3 and paragraph 37: a process for verifying the delivery of RCD to a device on a terminating end of a voice call) comprising:
receiving, by a recipient device, a call invite associated with Rich Call Data (RCD), (Cook figs. 2 and 3 and paragraphs 35 and 48: wireless device 204 receives a SIP request message from RCD verification subsystem 202), the call invite comprising:”
“an RCD header comprising a unique link to a server comprising one or more RCD media files associated with the originating source (Cook paragraphs 38-40 and 48: the SIP request message includes the Rich Call Data (RCD) extension that includes the modified URL to a graphical object stored at CDN 206, the graphical object being indicative of the originating source of the SIP request message); and
sending a notification, based on the unique link, wherein the notification indicates that the RCD header has been accessed (Cook figs. 2 and 3 and paragraphs 33-35 and 48-50: wireless device 204 retrieves the graphical object corresponding to the modified URL included in the RCD extension from CDN 206, causing CDN 206 to indicate to RCD delivery confirmation subsystem 208 that the graphical object was delivered to wireless device 204).”
However, while Cook discloses that the SIP request message can include headers text that can identify the call originator (Cook paragraph 38), Cook does not explicitly disclose wherein the SIP request message comprises “an identity header”.
In the same field of endeavor, Ranalli discloses including a SIP IDENTITY header comprising verified calling party attribute information in a SIP INVITE call establishment message (Ranalli figs. 1 and 7 and paragraphs 12, 67-68 and 83-85: originating service provider 101 includes a SIP IDENTITY header comprising verified calling party attribute information within a SIP INVITE call establishment message).
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Cook to include a SIP IDENTITY header comprising verified calling party attribute information in the SIP request message as taught by Ranalli. One of ordinary skill in the art would have been motivated to combine including a SIP IDENTITY header comprising verified calling party attribute information in the SIP request message to enable a terminating service provider to display a validated calling party telephone number to a call recipient at the time of call establishment (Ranalli paragraph 8).
Insofar as it recites similar claim elements, Claim 14 is rejected for substantially the same reasons presented above with respect to Claim 7.
Regarding Claim 16, Cook discloses “A method (Cook fig. 3 and paragraph 37: a process for verifying the delivery of RCD to a device on a terminating end of a voice call) comprising:
receiving, by a recipient device, a call invite associated with Rich Call Data (RCD), (Cook figs. 2 and 3 and paragraphs 35 and 48: wireless device 204 receives a SIP request message from RCD verification subsystem 202), the call invite comprising:”
“an RCD header comprising a unique link to a server comprising one or more RCD media files associated with the originating source (Cook paragraphs 38-40 and 48: the SIP request message includes the Rich Call Data (RCD) extension that includes the modified URL to a graphical object stored at CDN 206, the graphical object being indicative of the originating source of the SIP request message); and
tracking access, via the recipient device, of the RCD header (Cook figs. 2 and 3 and paragraphs 33-35 and 48-50: wireless device 204 retrieves the graphical object corresponding to the modified URL included in the RCD extension from CDN 206, causing CDN 206 to indicate to RCD delivery confirmation subsystem 208 that the graphical object was delivered to wireless device 204).”
However, while Cook discloses that the SIP request message can include headers text that can identify the call originator (Cook paragraph 38), and further discloses verifying delivery of the graphical object to the wireless device (Cook paragraphs 30, 33 and 50-51) Cook does not explicitly disclose wherein the SIP request message comprises “an identity header” and “correlating the access to a time of call.”
In the same field of endeavor, Ranalli discloses including a SIP IDENTITY header comprising verified calling party attribute information in a SIP INVITE call establishment message (Ranalli figs. 1 and 7 and paragraphs 12, 67-68 and 83-85: originating service provider 101 includes a SIP IDENTITY header comprising verified calling party attribute information within a SIP INVITE call establishment message) and further discloses storing display acknowledgements of verified calling party attributes along with a time of call, i.e., correlating display of RCD claims with the time of call (Ranalli paragraphs 22, 36 and 106-108: terminating service provider stores information for the call including calling party number, called party number, time of call, and call result as well as display acknowledgements of verified calling party attributes that were displayed at the time of call establishment in a Call Detail Record associated with the call).
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Cook to include a SIP IDENTITY header comprising verified calling party attribute information in the SIP request message as taught by Ranalli. One of ordinary skill in the art would have been motivated to combine including a SIP IDENTITY header comprising verified calling party attribute information in the SIP request message to enable a terminating service provider to display a validated calling party telephone number to a call recipient at the time of call establishment (Ranalli paragraph 8).
Insofar as it recites similar claim elements, Claim 17 is rejected for substantially the same reasons presented above with respect to Claim 7.
Insofar as it recites similar claim elements, Claim 18 is rejected for substantially the same reasons presented above with respect to Claim 11.
Insofar as it recites similar claim elements, Claim 20 is rejected for substantially the same reasons presented above with respect to Claim 3.
Claims 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Cook and Ranalli in view of Filart, Pub. No. US 2024/0275825 A1.
Regarding Claim 4, the combination of Cook and Ranalli discloses all of the limitations of Claim 1.
However, while Ranalli discloses that the RCD claims can include a call reason indicating a purpose of the call initiation request (Ranalli paragraphs 11-12, 67 and 73), the combination of Cook and Ranalli does not explicitly disclose “wherein the one or more RCD media files associated with the originating source are customizable to the recipient device.”
In the same field of endeavor, Filart discloses “wherein the one or more RCD media files associated with the originating source are customizable to the recipient device (Filart paragraphs 42-44 and 47: originating application telephony server (O-TAS) 310 modifies the outgoing SIP invite to include a subset of branding information associated with mobile originating device (MO) 302 as RCD claims in the header of the SIP invite, wherein the subset of branding information fields can be dependent on features belonging to the terminating endpoint device designated to receive the call, e.g., software version of the terminating endpoint device).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Cook as modified by Ranalli, to select a subset of branding information to include within the RCD extension based on features of the wireless device receiving the ISP request as taught by Filart because doing so constitutes applying a known technique (including a subset of branding features as RCD claims in a SIP invite based on features or the terminating endpoint device) to known devices and/or methods (a process for verifying the delivery of RCD to a device on a terminating end of a voice call) ready for improvement to yield predictable and desirable results (inclusion of a subset of branding information as RCD claims based on features of the recipient device, e.g., software version). See KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007).
Regarding Claim 12, the combination of Cook, Ranalli and Filart discloses all of the limitations of Claim 4.
Additionally, Cook discloses “sending a notification... indicating that the recipient device accessed the unique link (Cook paragraphs 33 and 51-52: RCD delivery confirmation subsystem 208 sends a delivery confirmation message indicating the graphical object was delivered to wireless device 204); and
receiving a response to a request for the one or more RCD media files encoded by the unique link (Cook figs. 2 and 3 and paragraphs 34 and 49: wireless device 204 receives the graphical object from CDN 206 in response to sending an HTTP GET request using the URL included in the RCD extension of the SIP request message).”
However, while Cook discloses sending a delivery confirmation message indicating that the graphical object was delivered to the wireless device (Cook paragraphs 33 and 51-52), Cook does not explicitly disclose “sending a notification to the originating source indicating that the recipient device accessed the unique link (emphasis added)”.
In the same field of endeavor, Ranalli suggests providing the enterprise calling party with confirmation that verified calling party information included with the call initiation signaling was presented to the call recipient at the time of call origination (Ranalli paragraphs 65 and 117-118: “Regardless of the specific technique used to pass verified enterprise calling party information from the originating service provider to the terminating service provider, it can be beneficial for the enterprise calling party (and/or the originating service provider) to know if the verified calling party information included with the call initiation signaling was presented to the call recipient at time of call origination.”).
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Cook to send the delivery confirmation message indicating that the graphical object was delivered to the wireless device to the originating caller as suggested by Ranalli. One of ordinary skill in the art would have been motivated to combine sending the delivery confirmation message indicating the graphical object was delivered to the wireless device to the originating caller so that the originating caller can verify if a higher percentage of its outbound calls are being answered when verified calling party information is displayed to the call recipient (Ranalli paragraph 126).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over the combination of Cook and Ranalli in view of Nayak, Pub. No. WO 2025/150914 A1.
Regarding Claim 5, the combination of Cook and Ranalli discloses all of the limitations of Claim 1.
However, while Cook discloses including an RCD PASSporT indication in the RCD extension that can be used to verify and authenticate caller identification (Cook paragraphs 38 and 55), the combination of Cook and Ranalli does not explicitly disclose “determining authenticity of the originating source.”
In the same field of endeavor, Nayak discloses “determining authenticity of the originating source (Nayak fig. 7 and paragraphs 117-118: “At step A9, the IMS terminating network apparatus (201) may invoke a request with AS for verification (609) of the signed RCD information or the signed RCD URL.”).
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Cook, as modified by Ranalli, to verify, by the terminating service provider, the RCD PASSporT included in the RCD extension of the SIP request as taught by Nayak. One of ordinary skill in the art would have been motivated to combine, verifying, by the terminating service provider network, the RCD PASSporT included in the RCD extension of the SIP request to confirm the integrity and authenticity of RCD information, i.e., the graphical object (Nayak paragraphs 117-118).
Claims 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Cook and Ranalli in view of Ngo et al., Pub. No. US 2023/0353565 A1, hereby “Ngo”.
Regarding Claim 6, the combination of Cook and Ranalli discloses all of the limitations of Claim 1.
However, while Cook discloses sending the SIP request including the RCD extension to the wireless device (Cook paragraphs 35 and 48), the combination of Cook and Ranalli does not explicitly disclose “receiving an indication that the recipient device has performed one or more human ID authentication steps, wherein the one or more RCD media files is altered.”
In the same field of endeavor, Ngo discloses “receiving an indication that the recipient device has performed one or more human ID authentication steps, wherein the one or more RCD media files is altered (Ngo figs. 3 and 8, TABLE 1, and paragraphs 78-81, 115, 131-132 and 136-137: callee device 330 transmits a SIP response message to caller device 310, wherein the SIP response indicates the user of the callee device has successfully authenticated by providing a fingerprint or pattern input to a user experience (UX) screen, an RCD media file, that is changed when the provided input matches the stored fingerprint or pattern).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Cook as modified by Ranalli, to provide a SIP response including an indication that the user of the mobile device has authenticated to the calling party as taught by Ngo. One of ordinary skill in the art would have been motivated to combine providing a SIP response including an indication that the user of the mobile device has authenticated to the calling party to enable establishment of a security call between the calling party and the user of the mobile device (Ngo paragraphs 61 and 115).
Insofar as it recites similar claim elements, Claim 15 is rejected for substantially the same reasons presented above with respect to Claim 6.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over the combination of Cook and Ranalli in view of Garcia Fernandez et al., Pub. No. US 2024/0314237 A1, hereby “Garcia Fernandez”.
Regarding Claim 9, the combination of Cook and Ranalli discloses all of the limitations of Claim 2.
However, while Ranalli discloses receiving call handling information relating to the outcome or end result of the call initiation request (Ranalli paragraphs 37 and 106-111), wherein the call handing outcome may indicate failure to establish a connection, i.e., a non-ring event (Ranalli paragraphs 37 and 110), the combination of Cook and Ranalli does not explicitly disclose “wherein the non-ring event is caused by an analytics engine.”
In the same field of endeavor, Garcia Fernandez discloses “wherein the non-ring event is caused by an analytics engine (Garcia Fernandez paragraphs 11-12, 23, 25, and 43-44: call log data received by communication server 106 can indicate the phone call was blocked by a spam filter, i.e., a non-ring event caused by an analytics engine).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Cook, as modified by Ranalli, to record call handling information indicating the SIP request was blocked by a spam filter as taught by Garcia Fernandez. One of ordinary skill in the art would have been motivated to combine recording call handling information indicating the SIP request was blocked by a spam filter to enable identification of caller identifiers, e.g., phone numbers, that are being blocked or flagged as spam, perhaps incorrectly (Garcia Fernandez paragraph 12).
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over the combination of Cook and Ranalli in view of Charlson, Pub. No. US 2023/0224402 A1.
Regarding Claim 19, the combination of Cook and Ranalli discloses all of the limitations of Claim 16.
However, while Cook discloses that wireless device retrieves the graphical object corresponding to the URL included in the RCD extension of the SIP request (Cook paragraphs 33, 35 and 48-49), the combination of Cook and Ranalli does not explicitly disclose “wherein the one or more RCD media files remain accessible to the recipient device after the recipient device has accepted the call invite.”
In the same field of endeavor, Charlson discloses “wherein the one or more RCD media files remain accessible to the recipient device after the recipient device has accepted the call invite (Charlson fig. 1 and paragraphs 49, 73, 81 and 85: RCD information such as logo, name and reason for call provided with an incoming call is stored by user device 100 in a Call History database, i.e., the RCD information remains accessible after the user device has accepted a call).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the method of Cook, as modified by Ranalli, to store, by the wireless device in a Call History database, the graphical object retrieved using the link included in the RCD extension of the SIP request message as taught by Charlson. One of ordinary skill in the art would have been motivated to combine storing the graphical object retrieved using the link included in the RCD extension of the SIP request message to create a set of historical communications information for calls to and from organizations including the logo, name and reason for call in the call history of the wireless device (Charlson paragraph 85).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM C MCBETH whose telephone number is (571)270-0495. The examiner can normally be reached on Monday - Friday, 8:00AM - 4:30PM ET.
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, Vivek Srivastava can be reached on 571-272-7304. 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.
/WILLIAM C MCBETH/Examiner, Art Unit 2449
/VIVEK SRIVASTAVA/Supervisory Patent Examiner, Art Unit 2449