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 § 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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 17, 19, and 29 are rejected under 35 U.S.C. 102 as being anticipated over Barclay et al. US 20070036136 A1 (hereinafter Barclay).
Regarding claim 17, Barclay teaches
A first network entity of a first service provider for wireless communication, comprising: a memory; and at least one processor coupled to the memory, wherein the at least one processor is configured to (Barclay paragraph [0013] discloses processor and memory): obtain, from a second network entity (originating router) of a second service provider [originating side network] , an invite message (SIP Invite message) associated with initiation of a call (VoIP call) between a first user equipment (UE) (called party node) associated with the first service provider and a second UE (calling party node)associated with the second service provider, wherein the invite message (SIP Invite message), as obtained from the second network entity, comprises third-party information (Caller ID information) associated with the second UE;
(“The method presumes a calling party node sends a SIP Invite message, as is known in the art, to initiate a VoIP call to a called party node. The SIP Invite message includes a message header with indicia of an IP address ("offered address") of the calling party node, which may or may not correspond to the actual IP address of the calling party node. At step 202, the originating router (i.e., serving the calling party node) receives the SIP Invite message. At step 204, the originating router inspects the SIP Invite message header to detect the offered address of the calling party node. The originating router also determines the actual IP address of the calling party node and uses the actual IP address to set up a VoIP session with the called party node.” [0018] “The originating router sends the modified SIP Invite message to the terminating router at step 216.” [0020] “At step 302, the terminating router (i.e., serving the called party node) receives the SIP Invite message. Depending on the embodiment, the SIP Invite message may comprise a modified SIP Invite message (i.e., with verification bit) or may comprise the SIP Invite message without a verification bit.” [0026] “The SIP Invite message includes a message header with indicia of an IP address ("offered address") of the calling party node, which may or may not correspond to the actual IP address of the calling party node.” [0025] “Caller ID information associated with a calling party node is displayed to a called party node.”[0008])
verify the third-party information (Caller ID information) based on subscription information [verification performed after checking subscriber status] associated with the first UE (called party nodes) that indicates that the first UE is subscribed to a service (Caller ID verification service) to verify the third-party information;
(“At step 304, the terminating router checks whether the called party node is a subscriber to a Caller ID verification service. In one embodiment, this comprises checking a database (e.g., database 108) to see whether the called party directory number or IP address corresponds to a valid account.” [0027] “As shown in FIG. 1, the terminating router is logically connected to a subscriber database 108. The subscriber database 108 may include a list of called party nodes that subscribe to the Caller ID verification feature.” [0016] “if the called party node is not a validated subscriber of the Caller ID verification service, the terminating router at step 312 causes the call to be delivered without verification information.” [0028] “If the called party node is a validated subscriber of the Caller ID verification service (or if Caller ID verification subscription is not required), the terminating router at step 306 checks for the presence of a verification bit in the SIP Invite message. If a verification bit is present, the Caller ID information has already been determined by the originating router to be valid (if the verification bit is TRUE) or not valid (if the verification bit is FALSE).” [0029])
and output, to the first UE (called party node), the invite message (SIP Invite message), wherein the invite message, as output to the first UE, comprises the third-party information (Caller ID information) based on the verification.
(“Typically, in the case where the called party has Caller ID service, the terminating router sends Caller ID information to the called party based on the IP address in the SIP Invite message (i.e., the offered address). Depending on the status of the verification bit, the terminating router can determine whether the Caller ID information provided to the called party is valid. That is, the terminating router knows that the Caller ID information is valid if the verification bit is TRUE or not valid if the verification bit is FALSE.” [0021] “once the terminating router determines the validity of the Caller ID information, it informs the called party node accordingly. In such manner, the called party node knows whether or not it can rely on the Caller ID information to screen, block or provide different call treatment for the incoming call.” [0022] “The terminating router at step 310 causes the call to be delivered with appropriate verification information to the called party node.” [0029] “the called party node could be informed of the actual number or identity of the calling party node.”[0030])
Regarding claim 19 limitations of parent claim 17 have been discussed above. Barclay teaches
wherein the at least one processor is further configured to: obtain the subscription information from a subscriber server (subscriber database 108) of the first service provider (terminating router), wherein the subscription information comprises an indication that the first UE (called party nodes) is subscribed to the service (Caller ID verification service).
(“As shown in FIG. 1, the terminating router is logically connected to a subscriber database 108. The subscriber database 108 may include a list of called party nodes that subscribe to the Caller ID verification feature” [0016] “At step 304, the terminating router checks whether the called party node is a subscriber to a Caller ID verification service. In one embodiment, this comprises checking a database (e.g., database 108) to see whether the called party directory number or IP address corresponds to a valid account.” [0027] “If the called party node is a validated subscriber of the Caller ID verification service (or if Caller ID verification subscription is not required), the terminating router at step 306 checks for the presence of a verification bit in the SIP Invite message.” [0029])
Regarding claim 29, claim 29 reflects a method for implementing the device in claim 17 and is rejected along the same rationale.
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.
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.
Claims 1-2, 5-7, 9-10, 13, 16, 21-22, and 24-27 are rejected under 35 U.S.C. 103 as being unpatentable over Ranalli US 20220086276 A1 in view of Mutikainen et al. US 20090098853 A1 (hereinafter) Mutikainen.
Regarding claim 1, Ranalli teaches
A first network entity of a first service provider (originating service provider 101) for wireless communication, comprising[an originating service provider configured to process an outbound call initiation request and add verified calling party information] wherein the at least one processor is configured to: obtain, from a first user equipment (UE) (enterprise calling party 100) associated with the first service provider, an invite message (SIP INVITE message/ call initiation request) associated with initiation of a call (outbound call) between the first UE (enterprise calling party 100) and a second UE (call recipient device 105) associated with a second service provider, wherein the invite message, as obtained from the UE, comprises an identity associated (calling telephone number) with the first UE and a third-party authorization server (external call signing service);
(“the verified calling party information 102 can be generated, compiled, or transmitted by an originating service provider 101 that is associated with enterprise calling party 100. For example, originating service provider 101 can automatically generate verified calling party information 102 based on one or more inputs provided by enterprise calling party 100.”[0068]” Once verified calling party information 102 is received and/or generated by originating service provider 101, it is included in a transmission 103 that is passed to terminating service provider 104 along with the other components of the call initiation request.”[0069] “According to aspects of the present disclosure, the originating service provider can include verified calling party information in the SIP signaling on behalf of a connected enterprise calling party customer … enterprise calling party 100 comprises a plurality of calling devices 301 connected to an SIP call server 302. The enterprise SIP call server 302 initiates an outbound call by sending a call initiation request to a connected originating service provider 101.”[0083] “STIR (Secure Telephone Identity Revisited) is a set of Internet Engineering Task Force (IETF) standards that define how to pass a verified calling party telephone number within SIP call signaling by including a cryptographically signed PASSporT (Personal Assertion Token) in an SIP INVITE message.”[0005]” FIG. 5 depicts an example structure of an HTTPS/JSON POST API function call 501 to an external call signing service, shown here as being available at the domain rcd-shaken.servicecloud.com, to retrieve a cryptographically signed RCD PASSporT that is encoded and returned in the form of a SIP IDENTITY header 502. An HTTP POST message containing the calling telephone number (orig: 19785551212) and the destination telephone number (dest: 12125551111) 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. N”[0080] “Empowering an enterprise calling party to include a cryptographically signed RCD PASSporT in a SIP INVITE message at the time of call origination adds value to the call establishment process… when an RCD PASSporT is included by the enterprise calling party in a SIP INVITE message, the originating service provider is still responsible for generating and adding its own SHAKEN PASSporT to the SIP signaling before routing the call to the terminating service provider.”[0063]” Terminating service provider 104 initiates the call between enterprise calling party 100 and the call recipient 107 (e.g., via call recipient device 105) according to the call initiation request.”[0070] “whether the enterprise SIP server is provided as a local SIP call server, an external SIP call server, or both, it is contemplated that the including step to combine verified calling party information 102 with the call initiation request can be accomplished by the enterprise SIP server making a RESTful HTTP/JSON API call to an RCD PASSporT signing service located outside the enterprise network and accessible via the public internet.”[0079])
determine, [That based on enterprise vetting and verified authority to use the calling telephone number] , that the first UE is authorized to use the identity;
(“The most common use case calls for each participating enterprise customer to participate in a vetting process administered by an approved vetting agency that follows industry best practices for verifying the existence of the enterprise, verifying the logo or icon used by the enterprise, and verifying the authority of the enterprise to use specific telephone number resources for outbound calls… The result of this upfront enterprise vetting process is a set of verified calling party attributes (e.g., calling party number(s), enterprise name, enterprise logo or icon, enterprise reason(s) for calling). Once the verified information has been captured and stored the information can be made available for including the information in the outbound calling process.”[0074] )
obtain, from the third-party authorization server (external call signing service) based on the determination that the first UE (enterprise calling party 100) is authorized to use the identity, third-party information (verified calling party information 102) associated with the first UE;
(“ FIG. 5 depicts an example structure of an HTTPS/JSON POST API function call 501 to an external call signing service, shown here as being available at the domain rcd-shaken.servicecloud.com, to retrieve a cryptographically signed RCD PASSporT that is encoded and returned in the form of a SIP IDENTITY header 502. An HTTP POST message containing the calling telephone number (orig: 19785551212) and the destination telephone number (dest: 12125551111) 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. N”[0080] “As will be described in greater depth below, 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.”[0067] “Turning next to FIG. 2, shown is an example structure of a decoded RCD PASSporT with three verified (or validated) calling party claims/attributes: nam, logo and crn (it is noted that the terms ‘claim’ and ‘attribute’ are used interchangeably herein with respect to rich call data). The ‘nam’ claim (shown here as ‘Dentist Office’) can be a string value representing the name of the calling party, such as enterprise calling party 100. The ‘logo’ claim (shown here as ‘https://logo.service-provider.com/dentistlogo.jpg’)… The ‘crn’ attribute (shown here as ‘Dentist Appointment Reminder’) can be a string value representing the reason for a call as defined by the enterprise calling party. ”[0073] “once the identity of an enterprise has been vetted and its calling party information has been verified, the information is available for use in the process of originating an outbound call.”[0076])
and output the invite message (SIP INVITE call initiation message) to a second network entity of the second service provider (the terminating service provider), wherein the invite message, as output to the second network entity, comprises the third-party information (enterprise RCD PASSporT).
(“In addition to the including step of combining verified calling party information with the call initiation request, originating service provider 101 can be further responsible for the subsequent passing step in which the verified enterprise calling party information is passed to the terminating service provider during the call establishment process (not shown here, see e.g., FIG. 1). For example, the passing step 103 can be accomplished by 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.”[0085] “including the enterprise RCD PASSporT along with the SHAKEN PASSporT completes the process of passing verified enterprise calling party information to the terminating service provider.”[0086] “the originating service provider can combine the RCD claims (e.g. nam, logo, crn) into the SHAKEN PASSporT to thereby generate a single integrated SHAKEN PASSporT.”[0087])
Ranalli does not expressly disclose a memory and at least one processor coupled to the memory, nor does Ranalli expressly disclose determining , based on subscription information associated with the first UE. However, Mutikainen teaches a network device including a memory and at least one processor coupled to the memory
(“The network device of FIG. 2 may be, for example, a server, computer or other network device configured to execute functions within the network on the basis of hardware and/or software implemented control… The apparatus may include or otherwise be in communication with a processing element 70, a user interface 72, a communication interface 74 and a memory device 76… the memory device 76 could be configured to store instructions for execution by the processing element 70… the processing element 70 may be embodied as a processor ”[0032-0034])
determine, based on subscription information (profile information related to the subscription) associated with the first UE (UE 84) , that the first UE is authorized to use the identity (IMS public user identity (IMPU));
(“At operation 102, the UE 84 may register to IMS for a particular IMS public user identity (IMPU). The UE 84 may subscribe for the registration event package at operation 104, indications of which may be communicated by the P-CSCF 86 to the S-CSCF 88. The S-CSCF 88 may then download, from the HSS 92, profile information related to the subscription at operation 106. The profile information may include ICSI values for supported service for each service profile. Thus, for example, the profile information may indicate that a particular service (e.g., service A) has been provisioned to particular IMPUs (e.g., IMPU-X and IMPU-Y).”[0041] “Once the S-CSCF 88 receives the profile information from the HSS 92, the S-CSCF 88 may generate the group identity information 80, which may be included, for example, as an extension to a registration event document (as described in greater detail below). The group identity information 80 may be provided to both the UE 84 and the AS 90 at operations 108 and 110, respectively. In this regard, the group identity information 80 may comprise a registration event notification including other IMPUs associated with the user and the provisioned ICSI values for each of the respective IMPUs. Thus, for example, among other things, the UE 84 and the AS 90 may be informed that service A has been provisioned for IMPU-X and IMPU-Y.”[0042] “At operation 112, the UE 84 may attempt to initiate an IMS session for a particular service (e.g., service A in the present example). Accordingly, the UE 84, having the group identity information 80, may be enabled to select an IMPU that supports the particular service. Thus, in this example, the UE 84 may be enabled to select from among the available IMPUs, either IMPU-X or IMPU-Y since they both support service A… the UE 84 may add the IMPU-X to the outgoing request as a preferred identity as part of operation 112.”[0043] “The P-CSCF 86 may authorize the identity selected by the UE 84, which may be in a preferred identity header, and may set the selected identity as an asserted identity (e.g., in an asserted identity header) communicated to the S-CSCF 88 at operation 114. The S-CSCF 88 may then execute the services based on the service profile of IMPU-X and authorize that IMPU-X is allowed to use service A.”[0044])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Mutikainen’s subscription profile based selected identity authorization technique and processor/ memory implementation into the verified caller information system of Ranalli so that verified caller information is communicated using an originating identity authorized for the calling user, for the benefit of preventing unauthorized identity use while providing trusted caller information.
Regarding claim 2 limitations of parent claim 1 have been discussed above. Ranalli teaches
The first network entity of claim 1, wherein, to determine that the first UE (enterprise calling party 100) is authorized to use the identity (telephone number), the at least one processor is configured to: [verify, through enterprise vetting, the calling party’s authority to use specific telephone number resources for outbound calls].
(“enterprise calling party 100 comprises a plurality of calling devices 301 connected to an SIP call server 302. The enterprise SIP call server 302 initiates an outbound call by sending a call initiation request to a connected originating service provider 101.”[0083] “The most common use case calls for each participating enterprise customer to participate in a vetting process administered by an approved vetting agency that follows industry best practices for verifying the existence of the enterprise, verifying the logo or icon used by the enterprise, and verifying the authority of the enterprise to use specific telephone number resources for outbound calls… The result of this upfront enterprise vetting process is a set of verified calling party attributes (e.g., calling party number(s), enterprise name, enterprise logo or icon, enterprise reason(s) for calling). Once the verified information has been captured and stored the information can be made available for including the information in the outbound calling process.”[0074])
Ranalli does not expressly teach obtain the subscription information from a subscriber server of the first service provider, wherein the subscription information comprises an indication that the first UE is authorized to use the identity. However Mutikainen teaches obtain the subscription information (subscription-related information (user profiles)) from a subscriber server (HSS 92) of the first service provider, wherein the subscription information comprises an indication that the first UE (UE 84) is authorized to use the identity
(“As shown in FIG. 3, the IMS may include the UE 84, a proxy call session control function (P-CSCF) 86, a serving-CSCF (S-CSCF) 88, an application server (AS) 90 and a home subscriber server (HSS) 92.”[0037]“the HSS 92 may include subscription-related information (user profiles) and corresponding identities for use in authentication and authorization of the user.”[0038] “The S-CSCF 88 may then download, from the HSS 92, profile information related to the subscription at operation 106… the profile information may indicate that a particular service (e.g., service A) has been provisioned to particular IMPUs (e.g., IMPU-X and IMPU-Y). ” [0041] “the UE 84, having the group identity information 80, may be enabled to select an IMPU that supports the particular service… the UE 84 may add the IMPU-X to the outgoing request as a preferred identity as part of operation 112. ”[0043] “The P-CSCF 86 may authorize the identity selected by the UE 84, which may be in a preferred identity header, and may set the selected identity as an asserted identity (e.g., in an asserted identity header) communicated to the S-CSCF 88 at operation 114. The S-CSCF 88 may then execute the services based on the service profile of IMPU-X and authorize that IMPU-X is allowed to use service A”[0044])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Mutikainen’s HSS based subscription profile and selected identity authorization technique into the verified caller information system of Ranalli so that authorization to use a calling identity is determined using subscriber profile information, for the benefit of preventing unauthorized identity use.
Regarding claim 5 limitations of parent claim 1 have been discussed above. Ranalli teaches
The first network entity of claim 1, wherein the at least one processor is further configured to: output (RESTful HTTP/JSON API call), to a signing server (an RCD PASSporT signing service located outside the enterprise network), the third-party information (verified calling party information 102) for encryption (cryptographically signed RCD PASSporT) [based on invocation of an RCD PASSport signing function for the outbound call];
(“trusted calling vendor 602 can fulfill the including step on behalf of the enterprise calling party by invoking an internal RCD PASSporT signing function that is deployed locally by the trusted calling vendor. Additionally, or alternatively, trusted calling vendor 602 can fulfill the including step on behalf of the enterprise calling party by invoking an external RCD PASSporT signing function available, for example, on the internet or another interconnected network.”[0082] “Originating service provider 101 subsequently fulfills the step of including verified calling party information on behalf of the enterprise calling party by invoking an RCD PASSporT signing function 303, either external or internal”[0083] ” whether the enterprise SIP server is provided as a local SIP call server, an external SIP call server, or both, it is contemplated that the including step to combine verified calling party information 102 with the call initiation request can be accomplished by the enterprise SIP server making a RESTful HTTP/JSON API call to an RCD PASSporT signing service located outside the enterprise network and accessible via the public internet.” [0079] “FIG. 5 depicts an example structure of an HTTPS/JSON POST API function call 501 to an external call signing service, shown here as being available at the domain rcd-shaken.servicecloud.com, to retrieve a cryptographically signed RCD PASSporT that is encoded and returned in the form of a SIP IDENTITY header 502.”[0080])
and obtain, from the signing server (external call signing service), the encrypted third-party information (cryptographically signed RCD PASSporT), wherein the invite message (SIP INVITE call initiation message), as output to the second network entity (terminating service provider), comprises the encrypted third-party information.
(“FIG. 5 depicts an example structure of an HTTPS/JSON POST API function call 501 to an external call signing service, shown here as being available at the domain rcd-shaken.servicecloud.com, to retrieve a cryptographically signed RCD PASSporT that is encoded and returned in the form of a SIP IDENTITY header 502 An HTTP POST message containing the calling telephone number (orig: 19785551212) and the destination telephone number (dest: 12125551111) 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. Note that decoding the returned SIP IDENTITY header would reveal an RCD PASSporT such as that shown in FIG. 2.”[0080] “the passing step 103 can be accomplished by 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.”[0085] “the originating service provider can combine the RCD claims (e.g. nam, logo, crn) into the SHAKEN PASSporT to thereby generate a single integrated SHAKEN PASSporT.”[0087])
Ranalli does not expressly teach based on the subscription information comprising an indication that the first UE (UE 84) is subscribed to a service to encrypt the third-party information. However Mutikainen teaches [using] subscription information (profile information related to the subscription) comprising an indication that the first UE is subscribed to a service to e
(“At operation 102, the UE 84 may register to IMS for a particular IMS public user identity (IMPU)…The S-CSCF 88 may then download, from the HSS 92, profile information related to the subscription at operation 106. The profile information may include ICSI values for supported service for each service profile. Thus, for example, the profile information may indicate that a particular service (e.g., service A) has been provisioned to particular IMPUs (e.g., IMPU-X and IMPU-Y)… the UE 84 and the AS 90 may be informed that service A has been provisioned for IMPU-X and IMPU-Y.”[0041-0042] “the UE 84, having the group identity information 80, may be enabled to select an IMPU that supports the particular service”[0043]“The S-CSCF 88 may then execute the services based on the service profile of IMPU-X and authorize that IMPU-X is allowed to use service A. At operation 116, the S-CSCF 88 may contact the AS 90 that implements the service to be initiated (e.g., service A), based on the service profile (e.g., an iFC in the service profile)”[0044])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Mutikainen’s subscription profile based service provisioning technique into RCD signing system of Ranalli so that cryptographic signing of verified caller information is provided when the calling user is provisioned for that service, for the benefit of controlling access to the signing service based on subscriber authorization.
Regarding claim 6 limitations of parent claim 1 have been discussed above. Ranalli teaches
The first network entity (originating service provider) of claim 1, wherein the at least one processor is further configured to: encrypt (cryptographically signed RCD PASSporT) the third-party information (verified (or validated) calling party claims/attributes) [by invoking an internal RCD PASSporT signing function], wherein the invite message (SIP INVITE call initiation message), as output to the second network entity (terminating service provider), comprises the encrypted third-party information.
(“The ATIS working group responsible for defining the SHAKEN standards is currently finalizing the specifications for extending the SHAKEN standards to include optionally passing verified enterprise calling party information in SIP signaling via a cryptographically signed RCD PASSporT. Rich Call Data (“RCD” or “rcd”) is a draft IETF standard that defines how a plurality of calling party attributes are optionally added to a PASSporT. The resulting RCD PASSporT structure supports a plurality of verified enterprise calling party attributes (e.g., enterprise name, enterprise logo, reason for the call, calling party number, called party number, time of the call, etc.) and other optional attributes that can be used to further identify the calling party.”[0062] “Turning next to FIG. 2, shown is an example structure of a decoded RCD PASSporT with three verified (or validated) calling party claims/attributes: nam, logo and crn (it is noted that the terms “claim” and “attribute” are used interchangeably herein with respect to rich call data). The ‘nam’ claim (shown here as ‘Dentist Office’) can be a string value representing the name of the calling party, such as enterprise calling party 100. The ‘logo’ claim (shown here as ‘https://logo.service-provider.com/dentistlogo.jpg’) can be an HTTPS link to a jpeg, other image file, or other pointer corresponding to the logo of the enterprise calling party. The logo attribute can be presented inside a flexible jCard (“jcd”) JSON structure that supports multiple optional calling party attributes. The ‘crn’ attribute (shown here as ‘Dentist Appointment Reminder’) can be a string value representing the reason for a call as defined by the enterprise calling party.”[0073] “Empowering an enterprise calling party to include a cryptographically signed RCD PASSporT in a SIP INVITE message at the time of call origination… the originating service provider generates and cryptographically signs a SHAKEN PASSporT that contains the calling telephone number, the called telephone number, the time of the call, and the attestation level assigned to the call by the originating service provider.”[0063] “the originating service provider 101 can fulfill the including step (of combining verified calling party information with the call initiation request) on behalf of the enterprise calling party 100 by invoking an internal RCD PASSporT signing function that is deployed locally by the originating service provider.”[0084] “the passing step 103 can be accomplished by 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.”[0085] “the originating service provider can combine the RCD claims (e.g. nam, logo, crn) into the SHAKEN PASSporT to thereby generate a single integrated SHAKEN PASSporT. The originating service provider can subsequently complete the passing step by passing the single integrated SHAKEN PASSporT to the terminating service provider”[0087])
Ranalli does not expressly disclose encrypt the third part information based on the subscription information comprising an indication that the first UE (the UE 84) is subscribed to a service. However, Mutikainen teaches based on the subscription information (subscription-related information (user profiles)) comprising an indication that the first UE is subscribed to a service
(“the HSS 92 may include subscription-related information (user profiles) and corresponding identities for use in authentication and authorization of the user.”[0038] “The S-CSCF 88 may then download, from the HSS 92, profile information related to the subscription at operation 106… the profile information may indicate that a particular service (e.g., service A) has been provisioned to particular IMPUs (e.g., IMPU-X and IMPU-Y)… the UE 84 and the AS 90 may be informed that service A has been provisioned for IMPU-X and IMPU-Y.”[0041 - 0042] ” The S-CSCF 88 may then execute the services based on the service profile of IMPU-X and authorize that IMPU-X is allowed to use service A.”[0044])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Mutikainen’s subscription profile based service provisioning technique into RCD signing system of Ranalli so that cryptographic protection of verified caller information is performed when the calling user is provisioned for that service, for the benefit of controlling access to the cryptographic signing service based on subscriber authorization.
Regarding claim 7 limitations of parent claim 1 have been discussed above. Mutikainen teaches
The first network entity of claim 1, wherein the at least one processor is further configured to: output, to the first UE (UE 84) during registration of the first UE with the first service provider, a message (registration event notification) comprising information indicative of the identity based on the subscription information, wherein the invite message (outgoing request), as obtained from the first UE, comprises the identity (IMPUs) based on the output of the message.
(“At operation 102, the UE 84 may register to IMS for a particular IMS public user identity (IMPU)… The S-CSCF 88 may then download, from the HSS 92, profile information related to the subscription at operation 106… the profile information may indicate that a particular service (e.g., service A) has been provisioned to particular IMPUs (e.g., IMPU-X and IMPU-Y). ”[0041] “the S-CSCF 88 may generate the group identity information 80… the group identity information 80 may comprise a registration event notification including other IMPUs associated with the user and the provisioned ICSI values for each of the respective IMPUs… The group identity information 80 may be provided to both the UE 84 and the AS 90 at operations 108 and 110, respectively… the UE 84, having the group identity information 80, may be enabled to select an IMPU that supports the particular service… the UE 84 may add the IMPU-X to the outgoing request as a preferred identity as part of operation 112. ”[0043])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Mutikainen’s registration time delivery of subscription derived identity information into verified caller information system of Ranalli so that the calling UE may select and include an appropriate identity in its outgoing call request, for the benefit of enabling identity selection consistent with the user’s subscribed services.
Regarding claim 9 limitations of parent claim 1 have been discussed above. Ranalli teaches
wherein, to obtain the third-party information, the at least one processor is configured to: obtain a name card (RCD PASSporT/ flexible jCard) that comprises the third-party information, wherein the invite message (SIP INVITE call initiation message), as output the second network entity (terminating service provider), comprises the name card.
(“Turning next to FIG. 2, shown is an example structure of a decoded RCD PASSporT with three verified (or validated) calling party claims/attributes: nam, logo and crn (it is noted that the terms “claim” and “attribute” are used interchangeably herein with respect to rich call data). The ‘nam’ claim (shown here as ‘Dentist Office’) can be a string value representing the name of the calling party, such as enterprise calling party 100. The ‘logo’ claim (shown here as ‘https://logo.service-provider.com/dentistlogo.jpg’) can be an HTTPS link to a jpeg, other image file, or other pointer corresponding to the logo of the enterprise calling party. The logo attribute can be presented inside a flexible jCard (“jcd”) JSON structure that supports multiple optional calling party attributes.”[0073] “FIG. 5 depicts an example structure of an HTTPS/JSON POST API function call 501 to an external call signing service, shown here as being available at the domain rcd-shaken.servicecloud.com, to retrieve a cryptographically signed RCD PASSporT that is encoded and returned in the form of a SIP IDENTITY header 502.”[0080] “the passing step 103 can be accomplished by 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.” [0085])
Regarding claim 10 limitations of parent claim 1 have been discussed above. Mutikainen teaches
wherein the identity (IMPU-X) is a public user identity (particular IMS public user identity (IMPU))
(“At operation 102, the UE 84 may register to IMS for a particular IMS public user identity (IMPU)” [0041] “the UE 84, having the group identity information 80, may be enabled to select an IMPU that supports the particular service… the UE 84 may add the IMPU-X to the outgoing request as a preferred identity as part of operation 112. ”[0043])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Mutikainen’s IMS public user identity technique into verified caller information system of Ranalli so that the calling UE may use public identity associated with its subscription in outgoing call signaling, for the benefit of enabling subscription associated identity use during session initiation.
Regarding claim 13 limitations of parent claim 1 have been discussed above. Ranalli teaches
wherein the third-party information (verified calling party information) is based on a display name (nam/ name of the calling party) included in the invite message (SIP header) as obtained from the first UE.
(“Turning next to FIG. 2, shown is an example structure of a decoded RCD PASSporT with three verified (or validated) calling party claims/attributes: nam, logo and crn (it is noted that the terms “claim” and “attribute” are used interchangeably herein with respect to rich call data). The ‘nam’ claim (shown here as ‘Dentist Office’) can be a string value representing the name of the calling party, such as enterprise calling party 100. The ‘logo’ claim (shown here as ‘https://logo.service-provider.com/dentistlogo.jpg’) can be an HTTPS link to a jpeg, other image file, or other pointer corresponding to the logo of the enterprise calling party. The logo attribute can be presented inside a flexible jCard (“jcd”) JSON structure that supports multiple optional calling party attributes.”[0073] “the phone dialer software on the calling party's device can populate a new parameter within an existing call signaling SIP header or populate a proprietary SIP header with instructions for the RCD PASSporT signing function.”[0091] “It is appreciated that a same or similar concept can be 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.” [0089] “the selection of the appropriate version of verified calling party information to include in the RCD PASSporT can be specific to the calling party telephone number (e.g., the phone number assigned to an individual placing the call on behalf of or for the enterprise calling party) and/or the selection could be based on the passing of an optional parameter in the HTTPS/JSON request to the RCD PASSporT signing function.”[0090])
Regarding claim 16 limitations of parent claim 1 have been discussed above. Ranalli teaches
wherein the at least one processor is further configured to: obtain, from a third UE [another calling device 301 of the plurality] associated with the first service provider (originating service provider 101), a second invite message [another SIP/call initiation message] associated with initiation of a second call [another outbound call initiated by enterprise calling party] between the third UE and a fourth UE (call recipient device 105) associated with the second service provider (Terminating service provider 104), wherein the second invite message, as obtained from the third UE, comprises a second identity (calling party telephone number) associated with the third UE and the third-party authorization server; and output the second invite message to the second network entity, wherein the second invite message, as output to the second network entity, excludes third-party information (RCD PASSporT signing function generates an RCD PASSporT without including the RCD claims) associated with the third UE [when the enterprise calling party does not want its verified calling party information displayed].
(“enterprise calling party 100 comprises a plurality of calling devices 301 connected to an SIP call server 302. The enterprise SIP call server 302 initiates an outbound call by sending a call initiation request to a connected originating service provider 101.” [0083] “Terminating service provider 104 initiates the call between enterprise calling party 100 and the call recipient 107 (e.g., via call recipient device 105) according to the call initiation request.” [0070] “the selection of the appropriate version of verified calling party information to include in the RCD PASSporT can be specific to the calling party telephone number (e.g., the phone number assigned to an individual placing the call on behalf of or for the enterprise calling party) and/or the selection could be based on the passing of an optional parameter in the HTTPS/JSON request to the RCD PASSporT signing function.”[0090] “An HTTP POST message containing the calling telephone number (orig: 19785551212) and the destination telephone number (dest: 12125551111) 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.”[0080] “the passing step 103 can be accomplished by 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.” [0085] “When an enterprise calling party does not want its verified enterprise calling party information to be displayed, the RCD PASSporT signing function generates an RCD PASSporT without including the RCD claims.”[0131] “the RCD PASSporT signing function can populate the nam attribute with a default value (e.g., Enterprise Caller), or with a null/empty value, that does not reveal any verified calling party information that is specific to the enterprise calling party… the RCD PASSporT signing function can generate a base PASSporT instead of an RCD PASSporT… does not include any verified calling party attributes (e.g., nam, logo, crn).” [0132 - 0133])
Ranalli does not expressly disclose determine, based on subscription information associated with the third UE, that the third UE is unauthorized to use the second identity. However Mutikainen teaches
determine, based on subscription information (profile information) associated with the third UE (UE 84), that the third UE is unauthorized to use the second identity (IMPU).
(“the profile information may indicate that a particular service (e.g., service A) has been provisioned to particular IMPUs (e.g., IMPU-X and IMPU-Y)” [0041] “the UE 84, having the group identity information 80, may be enabled to select an IMPU that supports the particular service.”[0043] “The P-CSCF 86 may authorize the identity selected by the UE 84, which may be in a preferred identity header, and may set the selected identity as an asserted identity (e.g., in an asserted identity header) communicated to the S-CSCF 88 at operation 114. The S-CSCF 88 may then execute the services based on the service profile of IMPU-X and authorize that IMPU-X is allowed to use service A.” [0043] “a listing of which services are supported for each identity (e.g., via the group identity information 80) may enable the UE 84 to intelligently select which identity to use in response to an attempt to initiate a particular application.” [0045])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Mutikainen’s subscription profile based identity authorization technique into selective inclusion of verified caller information system of Ranalli so that the third party caller information is excluded when the calling identity is not authorized for the service, for the benefit of preventing unauthorized use of caller information services.
Regarding claim 21, claim 21 reflects a method for implementing the device in claim 1 and is rejected along the same rationale.
Regarding claim 22, Limitations of parent claim 21 have been discussed above. Claim 22 reflects method for implementing device in claim 2 and is rejected along the same rationale.
Regarding claim 24, Limitations of parent claim 21 have been discussed above. Claim 24 reflects method for implementing device in claim 5 and is rejected along the same rationale.
Regarding claim 25, Limitations of parent claim 21 have been discussed above. Claim 25 reflects method for implementing device in claim 7 and is rejected along the same rationale.
Regarding claim 26, Limitations of parent claim 21 have been discussed above. Claim 26 reflects method for implementing device in claim 9 and is rejected along the same rationale.
Regarding claim 27, Limitations of parent claim 21 have been discussed above. Claim 27 reflects method for implementing device in claim 13 and is rejected along the same rationale.
Claims 3, 4, and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Ranalli in view of Mutikainen in further view of Tan et al. US 20200213290 A1 (hereinafter Tan).
Regarding claim 3 limitations of parent claim 1 have been discussed above. Tan teaches
wherein the at least one processor is further configured to: determine an address of the third-party authorization server based on the identity (third-party user identifier);
(“The terminal device is user equipment that can access a network, and may also be referred to as user equipment (UE).”[0085] “The authorization server is a server that can authorize a terminal device to use a network resource, and may be a third-party authorization server, including but not limited to an AF, a DN, or a DN-AAA” [0095] “The third-party user identifier is an identifier allocated by a third party to the terminal device, for example, a network access identifier (NAI). A third party refers to a third-party information service provider other than a user and an operator. If the third-party user identifier is represented by an NAI, the third-party user identifier can indicate a domain name of the authorization server. For example, a format of the NAI is username@server.com, and an address of the authorization server refers to a domain name of the server, for example, server.com. Therefore, the NAI includes the address of the authorization server.”[0101] “Before sending the authorization request message to the NEF, the resource control network element has obtained the address of the authorization server through domain name system (DNS) query.”[0115])
and output, to the third-party authorization server based on the determination of the address, a request to verify whether the first UE (terminal device/ user equipment (UE) ) is authorized [to use a requested network resource/ application based on permission associated with the terminal device], wherein, [determine whether to provide the requested network resource], the at least one processor is configured to: [allocate or refuse the requested network resource based on the authorization result].
(“The terminal device is user equipment that can access a network, and may also be referred to as user equipment (UE).”[0085] “The authorization server is a server that can authorize a terminal device to use a network resource, and may be a third-party authorization server, including but not limited to an AF, a DN, or a DN-AAA” [0095] “Before sending the authorization request message to the NEF, the resource control network element has obtained the address of the authorization server through domain name system (DNS) query.”[0115] “S203: The NEF sends the authorization request message to the authorization server, when determining that the authorization request message meets a preset security requirement.”[0117] “S204: The authorization server queries, based on locally stored authorization information of the terminal device, an authorization result corresponding to the second user identifier.”[0119] “the authorization server checks whether the stored authorization information includes an authorization record corresponding to the second user identifier… the authorization server queries permission corresponding to the SUPI*”[0121] “if the authorization result is that the terminal device is allowed to use a network resource, the resource control network element allocates a requested network resource to the terminal device”[0126])
Tan fails to teach to communicate the third-party information associated with the first UE via the invite message as output to the second network entity … to obtain the third-party information … obtain the third-party information based on an authorization of the first UE to communicate the third-party information However Ranalli teaches [third-party information as verified information associated with the enterprise caller] to communicate the third-party information (the verified calling party information 102) associated with the first UE (enterprise calling party 100) via the invite message (the SIP INVITE call initiation message) as output to the second network entity (terminating service provider) … to obtain the third-party information … obtain the third-party information (the verified calling party information 102) based on an authorization of the first UE to communicate the third-party information
(“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. More generally, verified calling party information 102 can be information that is provided by enterprise calling party 100 and/or is particular to the specific call being placed, where the information is identified as being potentially useful to the intended call recipient (here, call recipient 107) in making a decision as to whether or not to answer the incoming call.”[0067] ” 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.”[0072] “the passing step 103 can be accomplished by 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.”[0085] “the originating service provider 101 can fulfill the including step (of combining verified calling party information with the call initiation request) on behalf of the enterprise calling party 100 by invoking an internal RCD PASSporT signing function that is deployed locally by the originating service provider. Additionally or alternatively, the originating service provider can fulfill the including step on behalf of the enterprise calling party by invoking an external RCD PASSporT signing function available on the internet or another interconnected network.” [0084] “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”[0089] “the selection of the appropriate version of verified calling party information to include in the RCD PASSporT can be specific to the calling party telephone number (e.g., the phone number assigned to an individual placing the call on behalf of or for the enterprise calling party) and/or the selection could be based on the passing of an optional parameter in the HTTPS/JSON request to the RCD PASSporT signing function.”[0090] ” the enterprise calling party could authorize the display of verified calling party information for its outbound voice calls and/or could refuse the display of verified calling party information for its outbound voice calls… the enterprise calling party can specify, or configure at the DCS, a set of different conditions or triggers that, when met, result in a desired set or configuration of verified calling enterprise calling party attributes being transmitted alongside the enterprise's call initiation request.”[0129])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Tan’s identity derived authorization server addressing and UE specific authorization into verified caller information system of Ranalli and Mutikainen so that the caller information is obtained and communicated after authorization associated with the calling identity, for the benefit of controlling access to third party caller information services.
Regarding claim 4 limitations of parent claim 3 have been discussed above. Ranalli teaches
wherein: to output the request (HTTPS/JSON POST API) , the at least one processor is configured to output the request to the third-party authorization server [external RCD PASSporT signing service] [via a RESTful HTTP/JSON API call to an RCD PASSport signing service located outside the network and accessible via the public internet], and to obtain the third-party information, the at least one processor is configured to obtain the third-party information (RCD PASSporT) from the third-party authorization server [via the external call signing service response].
(“the enterprise SIP server is provided as a local SIP call server, an external SIP call server, or both, it is contemplated that the including step to combine verified calling party information 102 with the call initiation request can be accomplished by the enterprise SIP server making a RESTful HTTP/JSON API call to an RCD PASSporT signing service located outside the enterprise network and accessible via the public internet.”[0079] “FIG. 5 depicts an example structure of an HTTPS/JSON POST API function call 501 to an external call signing service, shown here as being available at the domain rcd-shaken.servicecloud.com, to retrieve a cryptographically signed RCD PASSporT that is encoded and returned in the form of a SIP IDENTITY header 502. An HTTP POST message containing the calling telephone number (orig: 19785551212) and the destination telephone number (dest: 12125551111) 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.” [0080])
Ranalli does not expressly disclose an exposure function of the first service provider that is configured to communicate with network entities outside of the first service provider. However Tan teaches via an exposure function (a network exposure function NEF) of the first service provider (SMF) that is configured to communicate with network entities outside of the first service provider. [and] obtain the third-party information [authorization result containing permission and extra data] from the third-party authorization server (authorization server is a DN-AAA) via the exposure function.
(“a network exposure function NEF”[0008]“a subscriber permanent identifier uses an SUPI, a UDM stores a correspondence between the SUPI and a third-party identifier of a terminal device, and an NEF is responsible for conversion of identifiers of the terminal device in internal and external networks.” [0198] “Operation 63: The SMF sends an authorization request message to the NEF, where the authorization request message includes the third-party identifier of the terminal device, the application identifier, and the SUPI.”[0205] “Operation 65a: The NEF forwards the authorization request message not including the SUPI to the DN-AAA. In one embodiment, the authorization request message includes the application identifier.” [0208] “a resource control network element is the SMF, an authorization server is a DN-AAA, a resource usage request is a PDU session setup request, and a subscriber permanent identifier is an SUPI.” [0129] “Operation 65b: The DN-AAA queries, by using the third-party identifier of the terminal device as an index, authorization information corresponding to the third-party authorization request, uses the authorization information as an authorization result, and returns an authorization response message to the NEF, where the authorization response message includes the third-party identifier of the terminal device, the authorization result, and the application identifier.” [0209] “The authorization record is a group of data indexed by the second user identifier, and the group of data includes but is not limited to the second user identifier, a third-party identifier, an application identifier, permission, salt, and extra data… The authorization result includes but is not limited to permission and extra data.” [0121] “Operation 67: The NEF forwards the authorization response message to the SMF, where the authorization response message includes the authorization result, the SUPI, and the application identifier.” [0212])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Tan’s NEF mediated third part authorization signaling technique into verified caller information system of Ranalli and Mutikainen so that requests to and information from an external authorization server are communicated through a network exposure function, for the benefit of providing controlled communication between the service provider network and external network entities.
Regarding claim 23, Limitations of parent claim 21 have been discussed above. Claim 23 reflects method for implementing device in claim 3 and is rejected along the same rationale.
Claims 8 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Ranalli in view of Mutikainen in further view of Przybysz et al. US 20130081123 A1 (hereinafter Przybysz).
Regarding claim 8 limitations of parent claim 7 have been discussed above. Przybysz teaches
wherein the at least one processor is further configured to: obtain, from the third-party authorization server (WSP website), a request to allocate the identity to the first UE (user's terminal), wherein, to output the message comprising the information indicative of the identity, the at least one processor is configured to: output the message comprising the information indicative of the identity [allocated IMS ID provided and then sent to user] based on the request.
(“a WSP user logging on to the WSP website using any required authentication credentials. After successful log-on, user client software installed in the user's terminal requests the WSP website to enable real-time communications. This will allow the user to have real-time communication with other active users of the website. The website responds to the user request and supplies an authentication "token" and an address of the IMS P-CSCF to be used when initiating an IMS call.” [0049]” After successful log-on to the WSP website, the user client software requests the WSP website to enable real-time IMS-based communications. The website now requests the IMS network to provision the algorithmic IMS user ID into the HSS. The IMS network provides the allocated IMS ID to the website. The website responds to the user with the algorithmic IMS ID, and the user client software now registers with the IMS network.”[0062])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Przybysz’s third party requested IMS identity allocation technique into verified caller information system of Ranalli and Mutikainen so that an identity requested for the calling UE is allocated and provided to the UE for subsequent registration and call signaling, for the benefit of dynamically providing an appropriate user identity when needed.
Regarding claim 11 limitations of parent claim 10 have been discussed above. Przybysz teaches
wherein the public user identity is allocated by the third-party authorization server.
(“An example of this approach will now be described. It requires in the first instance that the IMS Operator reserve a set of IMS IDs (from an unused pool of IMS IDs--the IMS Operator ensures that these IDs are not to be allocated either for their own use or for use by other WSPs) for use by the WSP. The IMS Operator provisions new "virtual" WSP users in the HSS for the allocated IMS IDs. Typically, one virtual WSP user is provisioned for each IMPI/IMPU pair. At this stage the WSP is not informed of the allocated IMS user IDs.” [0048] “An alternative to allowing the IMS network to dynamically allocate the temporary IMS user IDs is to implement this dynamic allocation function within the WSP.” [0059] “The website (and back-office systems if necessary) executes an allocation policy for IMS IDs, and allocates a temporary IMS ID to the user from those available in the pool, and stores the mapping between WSP website user ID and temporary IMS ID. The website responds to the user request and supplies the temporary IMS ID, the associated password ("pw"), and the address of the IMS P-CSCF to be used. This redirects the user client software to the IMS network. The user client software now registers with the IMS network, including the temporary IMS ID and the password in the REGISTER message.” [0060] “Consider now a WSP user logging on to the WSP website using any required authentication credentials. After successful log-on, user client software installed in the user's terminal requests the WSP website to enable real-time communications.” [0049])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Przybysz’s third party allocation of IMS public user identities into verified caller information system of Ranalli and Mutikainen so that the third party service may allocate public identity to the calling UE, for the benefit of dynamically assigning identities when needed.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Ranalli in view of Mutikainen in view of Przybysz in further view of Asveren et al. US 20170289261 A1 (hereinafter Asveren).
Regarding claim 12 limitations of parent claim 1 have been discussed above. Przybysz teaches
wherein the identity is a third-party specific user identity (third party (WSP) user IDs) and the invite message [User A client sends IMS INVITE], as obtained from the first UE (User A client), [contains the third party WSP user identity, while an authentication token is used during IMS registration to determine that the user is allowed to use the IMS network]
(“Mapping between third party (WSP) user IDs and IMS user IDs. The mapping needs to be dynamic, so that the usage of the IMS user IDs only occurs when users are active on the WSP web site. The mapping needs to consider invocation of IMS services by third party (WSP) users. IMS communications will act upon IMS user IDs, but communications should appear to end users as acting upon the third party (WSP) user IDs.” [0046] “User A client software initiates an IMS communication (e.g. a voice call) with User B, providing the (temporary) IMS ID of A, and also the WSP user IDs of A and B. The IMS network looks up the temporary IMS ID of B based upon the input WSP user ID of B. The IMS network then completes the IMS communication towards user B.” [0053] “User A obtains User B's temporary IMS ID from the WSP, before sending an INVITE, containing the IMS IDs of both user A and User B, to the IMS network. The INVITE also contains the WSP IDs of both parties.” [0061] “The website responds to the user request and supplies an authentication "token" and an address of the IMS P-CSCF to be used when initiating an IMS call.” [0049] “The user client software now registers with the IMS network. The authentication token and the WSP User ID are included in the REGISTER request, together with a contact address for the user. The IMS network uses the WSP user ID and token to determine that the user is allowed to use the IMS network, and also implements any policy agreed with the WSP such as the maximum number of concurrent users, and then allocates a temporary IMS ID to the user” [0050])
Przybysz does not expressly disclose comprises a token associated with an authorization of the first UE to communicate the third-party information via the invite message as output to the second network entity. However Asveren teaches comprises a token associated with an authorization of the first UE (client device 1602/ browser 1610) to communicate the INVITE)
(“The JavaScript web app 1614 of the client device 1602 generates and sends an INVITE with the received authorization token to the SBC 1606, as indicated by box 1624. The SBC 1606 verifies the received authorization token and sends an accept or reject call signal to the JavaScript web app 1614 of the client device 1602 in response to the result of the verification, as indicted by box 1626. Thus, the Web page server can authorize the SBC to proceed with a call via the authorization token communicated through client device 1602 without the need for the SBC to send signals to the Web page server to seek authorization for a call which might delay call set up. In this manner by the time a SIP related call signal reaches the SBC the call should already have been authorized by the Web server allowing the SBC to process the call signaling without have to contact the Web page server for authorization which could take time and introduce an additional signaling burden or requirement on the SBC which is avoided with the token based authorization approach described herein. ”[0134] “the browser 1610 uses an Authentication header, e.g., of a SIP INVITE message, to send the token to the SBC 1606.” [0137])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Asveren’s SIP INVITE call authorization token technique into the system of Ranalli in view of Mutikainen and Przybysz so that the originating UE includes an authorization token with its third party identity in the outgoing INVITE, for the benefit of verifying authorization before processing the call.
Claim 14 is ejected under 35 U.S.C. 103 as being unpatentable over Ranalli in view of Mutikainen in further view of Rosenberg et al. “SIP: Session Initiation Protocol” Internet Society RFC 3261 (hereinafter Rosenberg).
Regarding claim 14 limitations of parent claim 13 have been discussed above. Rosenberg teaches wherein the display name is included in a source header (From header field) of the invite message as obtained from the first UE.
(“The From header field indicates the logical identity of the initiator of the request, possibly the user’s address-of-record. Like the To header field, it contains a URI and optionally a display name. It is used by SIP elements to determine which processing rules to apply to a request (for example, automatic call rejection). As such, it is very important that the From URI not contain IP addresses or the FQDN of the host on which the UA is running, since these are not logical names” [Page 37] “Since the initial INVITE represents a request outside of a dialog, its construction follows the procedures of Section 8.1.1.” [page 78])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Rosenberg’s technique of including a display name in a form header identifying the initiator of the request into the system of Ranalli in view of Mutikainen so that the display name is included in the source header, for the benefit of identifying the request initiator.
Claims 15 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Ranalli in view of Mutikainen in further view of Shi WO 2007112642 A1.
Regarding claim 15 limitations of parent claim 1 have been discussed above. Shi teaches
wherein the third-party information (a multimedia identifier) is based on one or more parameters included in a call-information header (Call-Info header field) of the invite message (SIP INVITE message) as obtained from the first UE.
(“The calling user initiates a call, sends a SIP INVITE invite message, carries a multimedia identifier in the message, and can still use the Call-Info header field, as follows: Call-Info: <http://www.alice.com/my/photo.jpg>; purpose=icon” [page 10] “The network access node on the calling network side receives the SIP INVITE message, and finds that the message carries an unconfirmed multimedia identifier from the user terminal device, as described above, the multimedia can be deleted at this time. Identifying, or retaining the multimedia identifier, and adding an indication from the untrusted domain, the embodiment retains the multimedia identifier, and may agree to carry the multimedia identifier from the untrusted domain by using the Call-Info header field; or in the header field Add an indication parameter from the untrusted domain, as shown in the following example: Call-Info: <http://www.alice.com/my/photo.jpg>; purpose=icon; Auth=false Setting this parameter to "false" means that the corresponding multimedia identifier is from a non-trusted domain. If set to "true", the corresponding multimedia identifier is from the trusted domain…The auth parameter is set to "false", which means that the corresponding multimedia ID is from a non-trusted domain. When set to "true", it means corresponding The multimedia identity comes from the trust domain ” [page 11] )
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Shi’s call info header multimedia information technique into the system of Ranalli in view of Mutikainen so that the caller information is determined from parameters supplied in the originating UE’s SIP INVITE, for the benefit of identifying and conveying multimedia caller information during call establishment.
Regarding claim 28, Limitations of parent claim 21 have been discussed above. Claim 28 reflects method for implementing device in claim 15 and is rejected along the same rationale.
Claims 18 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Barclay in view of Barakat et al. US 20210409228 A1 (hereinafter Barakat).
Regarding claim 18 limitations of parent claim 17 have been discussed above. Barakat teaches
wherein, to verify the third-party information, the at least one processor is configured to: output (HTTP GET or POST), to a verification server (call security platform perform) of the first service provider (terminating network), a request (HTTP GET or POST) to verify the third-party information [verification of caller identity] ;
(“The SIP INVITE may be received at a terminating network device (e.g., an IMS core network device or non-IMS core network device) associated with the terminating network. In such implementations, 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).” [0028] “the interface may enable the call security platform to receive, from the network device, a request for a signing action for a call (e.g., a SIP INVITE) to be sent, a request for a verification action for a received call, or a request for tagging of a received call.”[0042] “a network element may invoke a signing service of the call security platform by making an HTTP GET or POST request including certain parameters associated with the signing service, as well as call information from the SIP INVITE.” [0046] “FIG. 8A shows an HTTP POST request for verification, including verification service API parameters in a JSON object.” [0049])
and obtain, from the verification server (call security platform) based on the request, an indication (authentication information) that the third-party information (TN-Validation-Passed) is verified.
(“the call security platform may provide an HTTP response message that includes the results of the verification. For example, where the verification activity is successful, the call security platform may provide an HTTP OK response, with the authentication information resulting from the verification activity. FIG. 8C illustrates a successful verification response message, including the resulting authentication information in JSON format (“verstat”: “TN-Validation-Passed”).” [0051] “The authentication information may include, for example, a verification status (e.g., verstat)” [0039] “As further shown in FIG. 1B, the call security platform may add authentication information to the call information. The authentication information may include for example, a verification status (e.g., verstat), as described above in connection with FIG. 1A. As shown in FIG. 1B, and by reference number 130, the call security platform may provide the call information with the authentication information to the terminating network device, and the terminating network device may route the SIP INVITE with the call information including the authentication information to the terminating user device.” [0031])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to incorporate Barakat’s verification service request and verification status response technique into Barclay’s subscription controlled caller information verification system so that received caller information may be verified by a verification service and a verification indication returned to the terminating network, for the benefit of providing authenticated caller information to the called user.
Regarding claim 30, Limitations of parent claim 29 have been discussed above. Claim 30 reflects method for implementing device in claim 18 and is rejected along the same rationale.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Barclay in view of Shi.
Regarding claim 20 limitations of parent claim 17 have been discussed above. Shi teaches
wherein the at least one processor is further configured to: obtain, from the second network entity (multimedia identifier service processing unit), a second invite message (SIP INVITE message) associated with initiation of a second call (initiates a call) between a third UE [called user] associated with the first service provider (called network) and a fourth UE (calling user) associated with the second service provider (calling network), wherein the second invite message, as obtained from the second network entity (multimedia identifier service processing unit), comprises third-party information (multimedia identifier) associated with the fourth UE;
(““the multimedia identifier service processing unit on the calling network side receives the SIP INVITE message, and adds a multimedia identifier to the outgoing SIP INVITE message according to the preset data of the user, and can still use the Call-Info header field… the multimedia identification service processing unit of the called network receives the INVITE message… The calling user initiates a call, sends a SIP INVITE invite message, carries a multimedia identifier in the message, and can still use the Call-Info header field, as follows: Call-Info: <http://www.alice.com/my/photo.jpg>; purpose=icon” [page 10] )
and output, to the third UE, the second invite message (INVITE message), wherein the second invite message, as output to the third UE (called user), excludes the third-party information (multimedia identifier) associated with the fourth UE [calling user]
(“The multimedia identification service processing unit of the called network receives the INVITE message. If the message carries the multimedia identifier, the corresponding processing is performed according to the preset data of the called user, if the called user signs the untrusted domain multimedia. Identification display limit, then in INVITE The multimedia identifier is deleted in the message, and the multimedia identifier added by the network is reserved and sent to the called user.”[page 11] “the multimedia identity service processing unit on the called network side receives the call message. And determining that the called user subscribes to the multimedia identifier display restriction service, deleting the multimedia identifier from the call message, and sending the call message to the called user.” [page 3])
Shi does not expressly disclose determine that the third UE is unsubscribed from a service to verify the third-party information associated with the fourth UE based on second subscription information associated with the third UE. However Barclay teaches determine that the third UE (called party node) is unsubscribed from a service to verify the third-party information (Caller ID verification service) associated with the fourth UE [calling party node] based on second subscription information (database 108) associated with the third UE;
(“At step 304, the terminating router checks whether the called party node is a subscriber to a Caller ID verification service. In one embodiment, this comprises checking a database (e.g., database 108) to see whether the called party directory number or IP address corresponds to a valid account.” [0027] “if the called party node is not a validated subscriber of the Caller ID verification service, the terminating router at step 312 causes the call to be delivered without verification information.” [0028])
based on the determination that the third UE (called party node) is unsubscribed from the service (Caller ID verification service) to verify the third-party information (called party directory number or IP address corresponds) associated with the fourth UE [calling party node].
(“At step 304, the terminating router checks whether the called party node is a subscriber to a Caller ID verification service. In one embodiment, this comprises checking a database (e.g., database 108) to see whether the called party directory number or IP address corresponds to a valid account.” [0027] “if the called party node is not a validated subscriber of the Caller ID verification service, the terminating router at step 312 causes the call to be delivered without verification information.” [0028])
Accordingly, it would have been obvious to a person having of ordinary skill in the art before the effective filling date of the claimed invention to combine Barclay’s terminating side caller ID verification system with Shi’s subscription controlled multimedia information removal technique so that caller information is excluded from the incoming INVITE when the called UE is not subscribed to the verification service, for the benefit of limiting caller information presentation to eligible users.
References Cited But Not Relied Upon
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Albisu et al (US 20150058447 A1 paragraph [0017]) is pertinent to subscriber authentication and authorization.
Lowman et al (US 20150079998 A1 paragraphs [0028] [0046]) is pertinent to subscriber authentication caller identity selection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FAVOUR O MADU whose telephone number is (571)272-9730. The examiner can normally be reached Monday - Friday 8am-5pm.
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, Jeanette Parker can be reached at (571) 270-3647. 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.
/F.O.M./Examiner, Art Unit 2646
/JEANETTE J PARKER/Supervisory Patent Examiner, Art Unit 2646
Prosecution Insights