DETAILED ACTION
This Action is in response to Application Number 18915285 received on 10/14/2024.
Claims 1-20 are presented for examination.
This application claims foreign priority to 202341072606, filed 10/25/2023.
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 .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 6-7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 6 recites the limitations, “transmit one or multiple signing requests to the signing server, in response to there being multiple avatars within the session initiation protocol invite request, wherein a signing request of the multiple signing requests comprises information related to an avatar; and
forward, to the network entity, the session initiation protocol invite request with one or multiple identity headers, wherein an identity header of the multiple identity headers comprises the signed token and information related to the avatar, in response to there being multiple avatars within the session initiation protocol invite request.”
These limitations are found indefinite for the following:
It is not clear by the language whether the limitation, "in response to there being multiple avatars within the session initiation protocol invite request" corresponds to the entirety of the preceding portion of the limitation, or if it only corresponds to transmitting "multiple signing requests to the signing server".
The next limitation, "wherein a signing request of the multiple signing requests comprises information related to an avatar" is found indefinite as the limitation appears to refer to the preceding limitation to which there are "multiple avatars". However, the limitation refers to "an avatar". Therefore, there is insufficient antecedent basis for this limitation in the claim.
The “forward” limitation additionally recites the limitation, “the avatar”. As there are multiple references to “multiple avatars” in the claim, there is insufficient antecedent basis for this limitation in the claim.
Claim 7 recites the limitation, “wherein the at least one signing request is dedicated to the information related to the at least one avatar, and differs from a calling party identifier signing request”, which is found indefinite because the limitation relies on the term “differs” without defining how the at least one signing request actually differs, and thereby fails to provide sufficient structure or boundaries.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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, 5-9, 11-13, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ranalli (US 20250392663) in view of Barakat et al. (US 20200336314).
Regarding claim 1, Ranalli disclosed an apparatus (Fig. 1B, Originating Service Provider 101) to:
receive, from a first user equipment, a session initiation protocol invite request destined for a second user equipment (Ranalli, Fig 1A and 1B, [0072], Ranalli disclosed an Enterprise Calling Party 100 making a call initiation request toa Call Recipient 107, which is received by an Originating Service provider 101; [0077], “SIP call initiation signaling”),
wherein the session initiation protocol invite request comprises information related to at least one avatar (Ranalli, [0012], “The set of verified calling party attributes includes one or more of a calling party name, a calling party logo, a calling party image, and a call reason indicating a purpose of the call initiation request.”; [0072], “When initiating or otherwise placing a call, enterprise calling party 100 generates or includes verified calling party information 102 in a call initiation request”, “the verified calling party information 102 can include, but is not limited to, an enterprise name (e.g., the name of the enterprise calling party 100), an enterprise logo, a reason for the call, etc.”)”; [0104]. Ranalli also disclosed including avatar information such as “a picture of the individual doctor placing or associated with the call”);
transmit at least one signing request to a signing server, the at least one signing request comprising the information related to the at least one avatar as part of a signing process (Ranalli, [0078], “FIG. 1B further depicts an RCD PASSporT signing function 120”, “The RCD PASSporT signing function 120 is shown as being optionally communicatively coupled to enterprise calling party 102, originating service provider 101, or both”; Ranalli therefore provides a first embodiment where the signing function is only communicatively coupled to the Originating service provider 101; [0079], “In some embodiments, RCD PASSporT signing function 120 receives a request from enterprise calling party 100 or originating service provider 101 to provide verified calling party information.”; [0106] “an enterprise calling party can dynamically pass one or more calling party attributes to an RCD PASSporT signing function at the time of call initiation”; With respect to above indicated first embodiment, such would involve the calling party to dynamically pass the call initiation request with the dynamic attributes to the Originating Service Provider 101, and as noted above in [0079], the originating service provider sends a request to the signing function to provide verified calling party information; In a separate embodiment, at [0089] Ranalli disclosed, “the enterprise SIP call server can fulfill the including step (i.e., including verified calling party information 102 in the call initiation request) by invoking an RCD PASSporT signing function located inside an enterprise network associated with the enterprise calling party 100, e.g., as seen in FIG. 3.”);
receive, from the signing server, a response to the at least one signing request, wherein the response to the at least one signing request comprises a signed token or other relevant information created during the signing process in relation with the at least one avatar (Ranalli, [0079], “The verified calling party information is returned to the requesting party (e.g., the enterprise calling party or the originating service provider) by RCD PASSporT signing function 120 and can be provided in the form of a cryptographically signed RCD PASSporT that includes the verified calling party information.” [0065], “The signed SHAKEN PASSporT is included in the SIP call signaling as a SIP IDENTITY header.”); and
forward, to a network entity, the session initiation protocol invite request with an identity header, wherein the identity header comprises the signed token or the other relevant information created during the signing process in relation with the at least one avatar (Ranalli, [0079], “The signed RCD PASSporT returned by RCD PASSporT signing function 120 is then propagated downstream as part of the call flow and display confirmation service disclosed herein.”; With respect to Figure 1B, the downstream call flow is to Call Recipient 107; See [0074]-[0075] once verified, the call is initiated to call recipient 107 to which the received verified calling party information 102 is included; [0094] “returns a cryptographically signed RCD PASSporT that has been base64url encoded and presented in the form of an SIP IDENTITY header as per the ATIS STIR/SHAKEN standards”; Propagating the RCD PassporT involves Propogating the SIP Identity header).
While Ranalli disclosed an Originating Service Provider performing the functionality, as shown above, Ranalli did not explicitly disclose the Originating Service Provider 101 to comprise at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to perform such functionality.
However, it would have been within the level of one of ordinary skill in the art at the time the invention was filed that the Service Provider of Ranalli amounts to computing hardware comprising general computing elements, including processor and memory, in order to realize the teachings of Ranalli.
Regardless, in an analogous art, Barakat disclosed a system of validating and securing caller identification involving service provider devices that include both processor and memory as claimed (Barakat, [0082]-[0083]).
One of ordinary skill in the art would have been motivated to combine the teachings of Ranalli and Barakat as they both relate to validating caller information, and as such they are within similar environments.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the service provider devices comprising processor/memory of Barakat within the teachings of Ranalli, as doing so amounts to applying a known technique to a known device ready for such an improvement, and the results of realizing the techniques of Ranalli across networking systems would have been predictable to one of ordinary skill in the art.
Regarding claim 2, Ranalli and Barakat disclosed the apparatus of claim 1, wherein the at least one signing request is based on at least one or more of: a secure telephone identity revisited standard, or a signature based handling of asserted information using tokens standard (Ranalli, [0033], “[0033] In one embodiment, the originating service provider signature is used to sign a SHAKEN (Signature-based Handling of Asserted Information using toKENs) PASSporT containing the set of verified calling party attributes or the subset of verified calling party attributes.”; Barakat, [0020]-[0022], Call security platform receives SIP Invite and verifies it; “The authentication information may include, for example, a verification status (e.g., verstat)”; verstat is a parameter used with STIR/SHAKEN framework to indicate the results of a signed, authenticated call).
Regarding claim 3, Ranalli and Barakat disclosed the apparatus of claim 1, wherein the information related to the at least one avatar within the at least one signing request comprises at least one or more of: an avatar identifier, or an avatar uniform resource identifier, or avatar content (Ranalli, [0012], “The set of verified calling party attributes includes one or more of a calling party name, a calling party logo, a calling party image, and a call reason indicating a purpose of the call initiation request.”; [0072], “When initiating or otherwise placing a call, enterprise calling party 100 generates or includes verified calling party information 102 in a call initiation request”, “the verified calling party information 102 can include, but is not limited to, an enterprise name (e.g., the name of the enterprise calling party 100), an enterprise logo, a reason for the call, etc.”)”; [0104]. Ranalli also disclosed including avatar information such as “a picture of the individual doctor placing or associated with the call”).
Regarding claim 5, Ranalli and Barakat disclosed the apparatus of claim 1, wherein the information related to the at least one avatar within the session initiation protocol invite request is trusted or retrieved from a trusted entity or stored and retrieved from a trusted network function (Ranalli, [0106]).
Regarding claim 6, Ranalli and Barakat disclosed the apparatus of claim 1, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to:
transmit one or multiple signing requests to the signing server, in response to there being multiple avatars within the session initiation protocol invite request, wherein a signing request of the multiple signing requests comprises information related to an avatar (Ranalli, [0078], “FIG. 1B further depicts an RCD PASSporT signing function 120”, “The RCD PASSporT signing function 120 is shown as being optionally communicatively coupled to enterprise calling party 102, originating service provider 101, or both”; Ranalli therefore provides a first embodiment where the signing function is only communicatively coupled to the Originating service provider 101; [0079], “In some embodiments, RCD PASSporT signing function 120 receives a request from enterprise calling party 100 or originating service provider 101 to provide verified calling party information.”; [0106] “an enterprise calling party can dynamically pass one or more calling party attributes to an RCD PASSporT signing function at the time of call initiation”; With respect to above indicated first embodiment, such would involve the calling party to dynamically pass the call initiation request with the dynamic attributes to the Originating Service Provider 101, and as noted above in [0079], the originating service provider sends a request to the signing function to provide verified calling party information); and
forward, to the network entity, the session initiation protocol invite request with one or multiple identity headers, wherein an identity header of the multiple identity headers comprises the signed token and information related to the avatar, in response to there being multiple avatars within the session initiation protocol invite request (Ranalli, [0079], “The signed RCD PASSporT returned by RCD PASSporT signing function 120 is then propagated downstream as part of the call flow and display confirmation service disclosed herein.”; With respect to Figure 1B, the downstream call flow is to Call Recipient 107; See [0074]-[0075] once verified, the call is initiated to call recipient 107 to which the received verified calling party information 102 is included; [0094] “returns a cryptographically signed RCD PASSporT that has been base64url encoded and presented in the form of an SIP IDENTITY header as per the ATIS STIR/SHAKEN standards”; Propagating the RCD PassporT involves Propogating the SIP Identity header).
Regarding claim 7, Ranalli and Barakat disclosed the apparatus of claim 1, wherein the at least one signing request is dedicated to the information related to the at least one avatar, and differs from a calling party identifier signing request (Ranalli, [0106], In the above embodiment, Ranalli disclosed the signing request specifically for cryptographically signing the attributes).
Regarding claim 8, Ranalli and Barakat disclosed the apparatus of claim 1, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: transmit, to the second user equipment, the identity header related to a verified avatar associated with the session initiation protocol invite request (Ranalli, [0079], “The signed RCD PASSporT returned by RCD PASSporT signing function 120 is then propagated downstream as part of the call flow and display confirmation service disclosed herein.”; With respect to Figure 1B, the downstream call flow is to Call Recipient 107; See [0074]-[0075] once verified, the call is initiated to call recipient 107 to which the received verified calling party information 102 is included; [0094] “returns a cryptographically signed RCD PASSporT that has been base64url encoded and presented in the form of an SIP IDENTITY header as per the ATIS STIR/SHAKEN standards”; Propagating the RCD PassporT involves Propogating the SIP Identity header)
Regarding claim 9, Ranalli and Barakat disclosed the apparatus of claim 1, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: transmit, to the second user equipment, the signed token or the other relevant information created during the signing process (Ranalli, [0079], “The signed RCD PASSporT returned by RCD PASSporT signing function 120 is then propagated downstream as part of the call flow and display confirmation service disclosed herein.”; With respect to Figure 1B, the downstream call flow is to Call Recipient 107; See [0074]-[0075] once verified, the call is initiated to call recipient 107 to which the received verified calling party information 102 is included; [0094] “returns a cryptographically signed RCD PASSporT that has been base64url encoded and presented in the form of an SIP IDENTITY header as per the ATIS STIR/SHAKEN standards”; Propagating the RCD PassporT involves Propogating the SIP Identity header).
Regarding claim 11, Ranalli disclosed an apparatus (Fig. 1B, Originating Service Provider 101) to:
receive, from a network entity, a session initiation protocol invite request with an identity header, wherein the identity header comprises a signed token or other relevant information created during a signing process (Ranalli, Fig 1A and 1B, [0072], Ranalli disclosed an Enterprise Calling Party 100 making a call initiation request toa Call Recipient 107, which is received by an Originating Service provider 101; [0077], “SIP call initiation signaling”; [0013] “the set of verified calling party attributes is received in an IDENTITY header of an SIP (Session Initiation Protocol) INVITE call establishment message”),
wherein the session initiation protocol invite request comprises information related to at least one avatar and is associated with a first user equipment (Ranalli, [0012], “The set of verified calling party attributes includes one or more of a calling party name, a calling party logo, a calling party image, and a call reason indicating a purpose of the call initiation request.”; [0072], “When initiating or otherwise placing a call, enterprise calling party 100 generates or includes verified calling party information 102 in a call initiation request”, “the verified calling party information 102 can include, but is not limited to, an enterprise name (e.g., the name of the enterprise calling party 100), an enterprise logo, a reason for the call, etc.”)”; [0104]. Ranalli also disclosed including avatar information such as “a picture of the individual doctor placing or associated with the call”);
transmit, to a verification server, a verification request to verify the information related to the at least one avatar, wherein the verification request comprises the identity header comprising the signed token or other relevant information created during the signing process, the session initiation protocol invite request associated with the first user equipment, and the information related to the at least one avatar (Ranalli, [0078], “FIG. 1B further depicts an RCD PASSporT signing function 120”, “The RCD PASSporT signing function 120 is shown as being optionally communicatively coupled to enterprise calling party 102, originating service provider 101, or both”; Ranalli therefore provides a first embodiment where the signing function is only communicatively coupled to the Originating service provider 101; [0079], “In some embodiments, RCD PASSporT signing function 120 receives a request from enterprise calling party 100 or originating service provider 101 to provide verified calling party information.”; [0106] “an enterprise calling party can dynamically pass one or more calling party attributes to an RCD PASSporT signing function at the time of call initiation”; With respect to above indicated first embodiment, such would involve the calling party to dynamically pass the call initiation request with the dynamic attributes to the Originating Service Provider 101, and as noted above in [0079], the originating service provider sends a request to the signing function to provide verified calling party information);
receive, from the verification server, an indication of whether the information related to the at least one avatar is verified (Ranalli, [0079], “The verified calling party information is returned to the requesting party (e.g., the enterprise calling party or the originating service provider) by RCD PASSporT signing function 120 and can be provided in the form of a cryptographically signed RCD PASSporT that includes the verified calling party information.” [0065], “The signed SHAKEN PASSporT is included in the SIP call signaling as a SIP IDENTITY header.”); and
forward, to a second user equipment, the session initiation protocol invite request and the information related to the at least one avatar, in response to receiving an indication from the verification server that the information related to the at least one avatar is verified (Ranalli, [0079], “The signed RCD PASSporT returned by RCD PASSporT signing function 120 is then propagated downstream as part of the call flow and display confirmation service disclosed herein.”; With respect to Figure 1B, the downstream call flow is to Call Recipient 107; See [0074]-[0075] once verified, the call is initiated to call recipient 107 to which the received verified calling party information 102 is included; [0094] “returns a cryptographically signed RCD PASSporT that has been base64url encoded and presented in the form of an SIP IDENTITY header as per the ATIS STIR/SHAKEN standards”; Propagating the RCD PassporT involves Propogating the SIP Identity header).
While Ranalli disclosed an Originating Service Provider performing the functionality, as shown above, Ranalli did not explicitly disclose the Originating Service Provider 101 to comprise at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to perform such functionality.
However, it would have been within the level of one of ordinary skill in the art at the time the invention was filed that the Service Provider of Ranalli amounts to computing hardware comprising general computing elements, including processor and memory, in order to realize the teachings of Ranalli.
Regardless, in an analogous art, Barakat disclosed a system of validating and securing caller identification involving service provider devices that include both processor and memory as claimed (Barakat, [0082]-[0083]).
One of ordinary skill in the art would have been motivated to combine the teachings of Ranalli and Barakat as they both relate to validating caller information, and as such they are within similar environments.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the service provider devices comprising processor/memory of Barakat within the teachings of Ranalli, as doing so amounts to applying a known technique to a known device ready for such an improvement, and the results of realizing the techniques of Ranalli across networking systems would have been predictable to one of ordinary skill in the art.
Regarding claim 12, Ranalli and Barakat disclosed the apparatus of claim 11, including, in some embodiments, the utilization of capturing and storing verified calling party information prior to call establishment (Ranalli, [0087]).
Ranalli did not explicitly disclose wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: receive, from the verification server, an indication that the information related to the at least one avatar is not verified.
Barakat disclosed wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: receive, from the verification server, an indication that the information related to the at least one avatar is not verified (Barakat, [0022], Verification status may include “that the calling party identity failed validation and authentication (e.g., TN-validation-failed),”).
As Ranalli disclosed, in some embodiments, using captured and storing verified calling party information prior to call establishment, one of ordinary skill would have been motivated to apply other mechanisms for verifying the calling party, such as the techniques applied by Barakat, especially in the instances where the teachings of Ranalli are unable to vet calling parties.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate Barakat’s validation process within the validation process of Ranalli such that Ranalli’s RCD PASSporT signing function can validate all information related to the avatar, including the calling user identity, in order to cover instances where calling parties are not predetermined to be verified, while also preventing identity spoofing, thereby enabling users to desirably avoid unwanted calls.
Regarding claim 13, Ranalli and Barakat disclosed the apparatus of claim 12, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine to not forward the session initiation protocol invite request to the second user equipment, in response to receiving from the verification server the indication that the information related to the at least one avatar is not verified (Barakat, [0027], “the terminating network device may request that the call security platform perform a verification action (e.g., by providing the call information with the identity header to the call security platform) before providing the call to the terminating user device (reference number 127)”). See motivation to combine above.
Regarding claim 18, Ranalli disclosed an apparatus to:
transmit, from a first user equipment to a network entity, a session initiation protocol invite request to a second user equipment (Ranalli, Fig 1A and 1B, [0072], Ranalli disclosed an Enterprise Calling Party 100 making a call initiation request toa Call Recipient 107; [0077], “SIP call initiation signaling”),
wherein the session initiation protocol invite request comprises information related to at least one avatar as part of a signing process
(Ranalli, [0012], “The set of verified calling party attributes includes one or more of a calling party name, a calling party logo, a calling party image, and a call reason indicating a purpose of the call initiation request.”; [0072], “When initiating or otherwise placing a call, enterprise calling party 100 generates or includes verified calling party information 102 in a call initiation request”, “the verified calling party information 102 can include, but is not limited to, an enterprise name (e.g., the name of the enterprise calling party 100), an enterprise logo, a reason for the call, etc.”)”; [0104]. Ranalli also disclosed including avatar information such as “a picture of the individual doctor placing or associated with the call”; [0079], “In some embodiments, RCD PASSporT signing function 120 receives a request from enterprise calling party 100 or originating service provider 101 to provide verified calling party information.”; [0106] “an enterprise calling party can dynamically pass one or more calling party attributes to an RCD PASSporT signing function at the time of call initiation”;), and
wherein the apparatus comprises the first user equipment (Ranalli, [0090] “Ranalli disclosed calling devices);
receive, from the network entity, an identity header related to the at least one avatar, the at least one avatar being verified (Ranalli, [0079], “The verified calling party information is returned to the requesting party (e.g., the enterprise calling party or the originating service provider) by RCD PASSporT signing function 120 and can be provided in the form of a cryptographically signed RCD PASSporT that includes the verified calling party information.” [0065], “The signed SHAKEN PASSporT is included in the SIP call signaling as a SIP IDENTITY header.”); and
store the identity header related to the verified at least one avatar for at least one other session initiation protocol invite request (Ranalli, [0102], the RCD PASSporTs can be stored in a database controlled by the calling party).
While Ranalli disclosed an calling devices performing the functionality, as shown above, Ranalli did not explicitly disclose the calling devices to comprise at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to perform such functionality.
However, it would have been within the level of one of ordinary skill in the art at the time the invention was filed that the calling devices of Ranalli amounts to computing hardware comprising general computing elements, including processor and memory, in order to realize the teachings of Ranalli.
Regardless, in an analogous art, Barakat disclosed a system of validating and securing caller identification involving calling devices that include both processor and memory as claimed (Barakat, [0082]-[0083]).
One of ordinary skill in the art would have been motivated to combine the teachings of Ranalli and Barakat as they both relate to validating caller information, and as such they are within similar environments.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the calling devices comprising processor/memory of Barakat within the teachings of Ranalli, as doing so amounts to applying a known technique to a known device ready for such an improvement, and the results of realizing the techniques of Ranalli across networking systems would have been predictable to one of ordinary skill in the art.
Regarding claim 19, Ranalli and Barakat disclosed the apparatus of claim 18, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: transmit, to the network entity, the at least one other session initiation protocol invite request with the identity header (Ranalli, [0067], Ranalli disclosed “Empowering an enterprise calling party to include a cryptographically signed RCD PASSporT in a SIP INVITE message at the time of call origination“; [0077], “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 “; [0102], the RCD PASSporTs can be stored in a database controlled by the calling party).
Regarding claim 20, Ranalli and Barakat disclosed the apparatus of claim 18, wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: receive a signed token or other relevant information created during the signing process associated with the at least one avatar; and store the signed token or other relevant information created during the signing process associated with the at least one avatar; and transmit, to the network entity, the at least one other session initiation protocol invite request with the signed token and other relevant information created during the signing process (Ranalli, [0067], Ranalli disclosed “Empowering an enterprise calling party to include a cryptographically signed RCD PASSporT in a SIP INVITE message at the time of call origination“; [0077], “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 “; [0102], the RCD PASSporTs can be stored in a database controlled by the calling party; [0012], “The set of verified calling party attributes includes one or more of a calling party name, a calling party logo, a calling party image, and a call reason indicating a purpose of the call initiation request.”; [0072], “When initiating or otherwise placing a call, enterprise calling party 100 generates or includes verified calling party information 102 in a call initiation request”, “the verified calling party information 102 can include, but is not limited to, an enterprise name (e.g., the name of the enterprise calling party 100), an enterprise logo, a reason for the call, etc.”)”; [0104]. Ranalli also disclosed including avatar information such as “a picture of the individual doctor placing or associated with the call”).
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ranalli (US 20250392663) in view of Barakat et al. (US 20200336314) and further in view of Zhao (US 20070201635).
Regarding claim 4, Ranalli and Barakat disclosed the apparatus of claim 1, but did not explicitly disclose wherein the information related to the at least one avatar within the session initiation protocol invite request is transmitted in a call-info header.
In an analogous art, Zhao disclosed wherein the information related to the at least one avatar within the session initiation protocol invite request is transmitted in a call-info header (Zhao, [0053], [0071], Zhao disclosed the ability to include the URL address of multimedia resources within either the Call-Info header or the Alert-Info header).
One of ordinary skill in the art would have been motivated to combine the teachings of Zhao with Ranalli and Barakat as they all disclose implementations involving multimedia calling, and as such, they are within similar environments.
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the utilization of the Call-Info header, as disclosed by Zhao, to transport the avatar information of the combined teachings of Ranalli and Barakat, as doing so amounts to the substitution of one well-known manner for transferring the multimedia information, with another well-known manner to achieve predictable results, of transmitting the multimedia information, thereby providing flexibility in programming.
Claim(s) 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Ranalli (US 20250392663) in view of Barakat et al. (US 20200336314) and further in view of Filart et al. (US 12506793).
Regarding claim 10, Ranalli and Barakat disclosed the apparatus of claim 1. The combination additionally disclosed the ability to validate the avatar information and provide such to the terminating user, to which the call recipient accepts the communication session (Ranalli, [0039]) but did not explicitly disclose wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: receive, from the second user equipment or terminating network, an indication that the second user equipment or terminating network was able to verify at least one avatar.
In an analogous art, Filart disclosed wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: receive, from the second user equipment or terminating network, an indication that the second user equipment or terminating network was able to verify at least one avatar (Filart, col. 10, line 25 through col. 11, line 2, and Figure 9, Filart disclosed, “The invited user of UE 402 accepts the invite based on the user information and returns a SIP OK (SIP3) to CSCF 430 over communication network 405. CSCF 430 indicates the SIP OK to TAS 431. TAS 431 initiates a bearer request for the video chat to CSCF 430 which forwards the request for the video chat bearer for UE 401 to PCF 425. PCF 425 forwards the request for the video chat bearer for UE 401 to AMF 421, and although not shown, the operation proceeds in a standard manner to complete the video chat.”).
One of ordinary skill in the art would have been motivated to combine the teachings of Filart and Ranalli and Barakat as they all disclose implementations involving multimedia calling, and as such, they are within similar environments.
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the SIP OK messages of Filart within the teachings of Ranalli and Barakat in order to provide indication that the user accepted the call, thereby providing indication that verification was successful, in order to facilitate establishment of the SIP call to proceed in a standard manner to complete the call (Filart, col. 10, line 60 through col. 11, line 3), thereby increasing customer desirability of use.
Regarding claim 17, Ranalli and Barakat disclosed the apparatus of 11. The combination additionally disclosed the ability to validate the avatar information and provide such to the terminating user, to which the call recipient accepts the communication session (Ranalli, [0039]) but did not explicitly disclose wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: receive, from the second user equipment or terminating network, an indication that the second user equipment or terminating network was able to verify at least one avatar.
In an analogous art, Filart disclosed wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: receive, from the second user equipment or terminating network, an indication that the second user equipment or terminating network was able to verify at least one avatar (Filart, col. 10, line 25 through col. 11, line 2, and Figure 9, Filart disclosed, “The invited user of UE 402 accepts the invite based on the user information and returns a SIP OK (SIP3) to CSCF 430 over communication network 405. CSCF 430 indicates the SIP OK to TAS 431. TAS 431 initiates a bearer request for the video chat to CSCF 430 which forwards the request for the video chat bearer for UE 401 to PCF 425. PCF 425 forwards the request for the video chat bearer for UE 401 to AMF 421, and although not shown, the operation proceeds in a standard manner to complete the video chat.”).
One of ordinary skill in the art would have been motivated to combine the teachings of Filart and Ranalli and Barakat as they all disclose implementations involving multimedia calling, and as such, they are within similar environments.
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the SIP OK messages of Filart within the teachings of Ranalli and Barakat in order to provide indication that the user accepted the call, thereby providing indication that verification was successful, in order to facilitate establishment of the SIP call to proceed in a standard manner to complete the call (Filart, col. 10, line 60 through col. 11, line 3), thereby increasing customer desirability of use.
Allowable Subject Matter
Claims 14-16 are 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.
The following is a statement of reasons for the indication of allowable subject matter:
Regarding claim 14, Ranalli and Barakat disclosed the apparatus of claim 12, but did not explicitly disclose wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine whether an identity of an originating party associated with the first user equipment is verified; determine to forward the session initiation protocol invite request to the second user equipment without an avatar, in response to receiving from the verification server the indication that the information related to the at least one avatar is not verified, and in response to determining that the identity of the originating party associated with the first user equipment is verified.
Regarding claim 15, Ranalli and Barakat disclosed the apparatus of claim 12, but did not explicitly disclose wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: determine to forward the session initiation protocol invite request to the second user equipment with an unverified avatar, in response to receiving from the verification server the indication that the information related to the at least one avatar is not verified; and transmit, to the second user equipment, an indication that the transmitted avatar is unverified.
Regarding claim 16, Ranalli and Barakat disclosed the apparatus of claim 11, but did not explicitly disclose wherein the instructions, when executed by the at least one processor, cause the apparatus at least to: download the verified avatar from a uniform resource locator, in response to receiving the indication from the verification server that the information related to the at least one avatar is verified.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JERRY B DENNISON whose telephone number is (571)272-3910. The examiner can normally be reached M-F 8:30-5:50.
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, Hadi Armouche can be reached on 571-270-3618. 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.
/JERRY B DENNISON/Primary Examiner, Art Unit 2409