DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The amendment to the claims filed on 27 October 2025 and included in the RCE filed 24 November 2025 does not comply with the requirements of 37 CFR 1.121(c) because claim 1 includes underlined text and claim 11 includes text with a strike-through that was already indicated in the amended claim set filed on 25 March 2025. In addition, claim 11 has a claim status of “(Previously presented)” but also includes claim language indicated as amended. Amendments to the claims filed on or after July 30, 2003 must comply with 37 CFR 1.121(c) which states:
(c) Claims. Amendments to a claim must be made by rewriting the entire claim with all changes (e.g., additions and deletions) as indicated in this subsection, except when the claim is being canceled. Each amendment document that includes a change to an existing claim, cancellation of an existing claim or addition of a new claim, must include a complete listing of all claims ever presented, including the text of all pending and withdrawn claims, in the application. The claim listing, including the text of the claims, in the amendment document will serve to replace all prior versions of the claims, in the application. In the claim listing, the status of every claim must be indicated after its claim number by using one of the following identifiers in a parenthetical expression: (Original), (Currently amended), (Canceled), (Withdrawn), (Previously presented), (New), and (Not entered).
(1) Claim listing. All of the claims presented in a claim listing shall be presented in ascending numerical order. Consecutive claims having the same status of “canceled” or “not entered” may be aggregated into one statement (e.g., Claims 1–5 (canceled)). The claim listing shall commence on a separate sheet of the amendment document and the sheet(s) that contain the text of any part of the claims shall not contain any other part of the amendment.
(2) When claim text with markings is required. All claims being currently amended in an amendment paper shall be presented in the claim listing, indicate a status of “currently amended,” and be submitted with markings to indicate the changes that have been made relative to the immediate prior version of the claims. The text of any added subject matter must be shown by underlining the added text. The text of any deleted matter must be shown by strike-through except that double brackets placed before and after the deleted characters may be used to show deletion of five or fewer consecutive characters. The text of any deleted subject matter must be shown by being placed within double brackets if strike-through cannot be easily perceived. Only claims having the status of “currently amended,” or “withdrawn” if also being amended, shall include markings. If a withdrawn claim is currently amended, its status in the claim listing may be identified as “withdrawn—currently amended.”
(3) When claim text in clean version is required. The text of all pending claims not being currently amended shall be presented in the claim listing in clean version, i.e., without any markings in the presentation of text. The presentation of a clean version of any claim having the status of “original,” “withdrawn” or “previously presented” will constitute an assertion that it has not been changed relative to the immediate prior version, except to omit markings that may have been present in the immediate prior version of the claims of the status of “withdrawn” or “previously presented.” Any claim added by amendment must be indicated with the status of “new” and presented in clean version, i.e., without any underlining.
(4) When claim text shall not be presented; canceling a claim.
(i) No claim text shall be presented for any claim in the claim listing with the status of “canceled” or “not entered.”
(ii) Cancellation of a claim shall be effected by an instruction to cancel a particular claim number. Identifying the status of a claim in the claim listing as “canceled” will constitute an instruction to cancel the claim.
(5) Reinstatement of previously canceled claim. A claim which was previously canceled may be reinstated only by adding the claim as a “new” claim with a new claim number.
Since the reply filed on 24 November 2025 appears to be bona fide and in the interest of compact prosecution, the examiner has attempted to determine the correct claim statuses and claim language.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 24 November 2025 has been entered.
Response to Arguments
Applicant's arguments filed 27 October 2025 have been fully considered but they are not persuasive.
In response to applicant’s arguments that “Schlesinger, van Rensburg, Moliner, and the other cited references do not teach or suggest ‘generating a communications identifier including a relationship identifier in dependence upon third party relationship data, the third party relationship data including identity information about at least one third party organization having a pre-existing relationship with a user associated with the user device’”, stated on page 8, the examiner respectfully disagrees.
Schlesinger discloses upon receiving a request to establish a relationship 204 between a user 102 and a service 108, generating a token 208 identifying the relationship 204 with the user 102, and sending the token 208 to the service 108 (Para. 23). The services 108 may include informational services; commercial services; social services, such as social networks; and data services, such as file transfer (Para. 34). The relationships 204 may include commercial, academic, and/or professional relationships; membership of the user 102 in a group or organization; and a service-oriented relationship where the user 102 simply invokes the services of the service 108 (Para. 34).
Van Rensburg discloses the caller verification system 110 registers the intended communication session by using the data received to generate a key, wherein the key is a hash of the caller's phone number, callee's phone number, and the call time window identifier (Para. 174).
Van Rensburg further discloses the caller data may include one or more fields of data identifying and describing aspects of the caller, such as the caller's phone number, full name, the organization to which the caller belongs or is representing for the scope of the call, a title, level, position, role, or function of the caller in the context of the organization to which the caller belongs or is representing, and so forth, wherein a caller may be an individual who works for a bank's fraud department who calls a customer of the bank to warn about potentially fraudulent charges, wherein the caller data, in this example, may include the caller's phone number, full name, the bank name, the caller's title at the bank, and so forth (Para. 108).
It should be noted that the independent claims do not indicate how the relationship identifier relates to the communications identifier. For example, the communications identifier and the relationship identifier could be the same identifier or the relationship identifier could be a portion of the communications identifier. The examiner suggests clarifying the relationship in accordance with the original disclosure.
It should be further noted that the independent claims do not indicate how the relationship identifier relates to the third party relationship data. For example, claim 1 indicates that the relationship identifier is “in dependence upon” the third party relationship data. Therefore, the relationship identifier could be generated from the third party relationship data or could be at least a portion of the third party relationship data. The examiner suggests clarifying the relationship in accordance with the original disclosure.
Therefore, the aforementioned limitation is taught by the combination of the cited prior art.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-5, 7, 10-12, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Schlesinger et al. (US 2014/0282984 A1) in view of van Rensburg et al. (US 2021/0099573 A1) and further in view of Moliner et al. (US 2011/0281567 A1).
Regarding claim 1, Schlesinger teaches a method of authenticating, at an authentication server, e.g., communication manager 202/514/302 (Fig. 2, el. 202; Fig. 5, el. 514; Fig. 7, el. 302), a communications session between a user device, e.g., mobile phone 106 (Figs. 1, 2, 7, el. 106); client device 502 (Fig. 5, el. 502), and a third party device, e.g., service 108 (Figs. 1, 2, 5, 7, el. 108); when a service 108 wishes to contact the user 102, the service 108 may send the message 112 or a request to initiate communication with the user 102 to the communication manager 202, along with the token 208 identifying the relationship 204 with the user 102, wherein the communication manager 202 may compare the token 208 with the relationship 204 to the service 108 defined by the user 102, and may permit or deny the communication based on this comparison (Figs. 2, 5, el. 204, 208; Para. 20), the method comprising:
receiving a connection notification from the third party device, the connection notification indicating an intention of the third party device to initiate the communications session with the user device, e.g., when a service 108 wishes to contact the user 102, the service 108 may send the message 112 or a request to initiate communication with the user 102 to the communication manager 202, along with the token 208 identifying the relationship 204 with the user 102 (Para. 20); receiving a request 206 from the service 108 to communicate with the user 102 through a particular communication channel (Para. 47),
the connection notification comprising a user identifier and identification of a communications channel that will be used for the communications session, e.g., the token 208 represents the relationship 204, e.g., indicating the permission granted by the user 102 to send messages 112 or other communication to the user 102 (Para. 20); receiving a request 206 from the service 108 to communicate with the user 102 through a particular communication channel, wherein the user 102 may specify criteria regarding such communication channels that may be included in the evaluation of a request 206 and the user 102 may specify particular per-server, per-communication-channel permissions, e.g., authorizing respective services 108 to use one or more of the communication channels, and may prohibit the same service 108 from using one or more other communication channels, wherein the communication manager 202 may receive such selections from the user 102, and may store such authorizations in the stored relationship 204 and/or user profile 110 of the user 102, and/or may encode such authorizations in the token 208 sent to the service 108, (Para. 47);
retrieving a user profile in dependence on the received user identifier, the user profile comprising a user device identifier, e.g., the storage of a user profile 110 may be advantageous for comparing a token 208 received with a request 206 to the stored relationship 204 represented by the token 208 (Para. 38); the communication manager 202 may alleviate the task of updating user profiles 110 if the information of the user 102 changes, e.g., if the user 102 switches to a different mobile phone 106 having a different phone number, the user 102 may simply notify the communication manager 202, which may thenceforth direct calls to the new mobile phone 106 and/or automatically update the services 108 with the new phone number (Para. 21); the user 102 may specify criteria regarding such communication channels that may be included in the evaluation of a request 206 and the user 102 may specify particular per-server, per-communication-channel permissions, e.g., authorizing respective services 108 to use one or more of the communication channels, and may prohibit the same service 108 from using one or more other communication channels, wherein the communication manager 202 may receive such selections from the user 102, and may store such authorizations in the stored relationship 204 and/or user profile 110 of the user 102, and/or may encode such authorizations in the token 208 sent to the service 108, (Para. 47);
generating a…identifier including a relationship identifier in dependence upon third party relationship data, e.g., upon receiving 206 a request 206 to establish a relationship 204 between a user 102 and a service 108, generate 308 a token 208 identifying the relationship 204 with the user 102, and send 310 the token 208 to the service 108 (Fig. 3, el. 308; Para. 23),
the third party relationship data including identity information about at least one third party organization having a pre-existing relationship with a user associated with the user device, e.g., upon receiving 206 a request 206 to establish a relationship 204 between a user 102 and a service 108, generate 308 a token 208 identifying the relationship 204 with the user 102, and send 310 the token 208 to the service 108 (Fig. 3, el. 308; Para. 23);
the techniques provided herein may establish many types of services 108 and relationships 204 between users 102 and services 108, wherein the services 108 may include informational services; commercial services; social services, such as social networks; and data services, such as file transfer, wherein the relationships 204 may include commercial, academic, and/or professional relationships; membership of the user 102 in a group or organization; and a service-oriented relationship where the user 102 simply invokes the services of the service 108 (Para. 34); and
sending, to the user device, a communications notification, the communications notification comprising data relating to the communications channel that the third party device will use to connect to the user device, third party identification data…, e.g., when a service 108 requests to initiate direct contact with the user 102, the communication manager 514 may determine whether such contact is authorized, and may directly advise the user 102 of whether or not to accept the communication (e.g., "this caller is among your blocked services list"), and the client device 502 may present the advice of the communication manager 514 to the user 102 (Para. 46); and
sending, to the third party device, the…identifier such that the third party device can include the…identifier including the relationship identifier in dependence upon the third party relationship data when initiating the communications session with the user device in order to indicate that the communications session is genuine, e.g., upon receiving 206 a request 206 to establish a relationship 204 between a user 102 and a service 108, generate 308 a token 208 identifying the relationship 204 with the user 102, and send 310 the token 208 to the service 108, upon receiving 312 from a service 108 a token 308 and a request from the service 108 to communicate with the user 102, verify 314 that the relationship 204 represented by the token 308 permits communication between the service 108 and the user 102; and after verifying the token 208 and the relationship 204, permit 316 the service 108 to communicate with the user 102 (Fig. 3, el. 308, 310, 312, 314; Para. 23).
Schlesinger does not explicitly teach generating a communications identifier including a relationship identifier in dependence upon third party relationship data;
sending, to the user device, a communications notification, the communications notification comprising data relating to the communications channel that the third party device will use to connect to the user device, third party identification data and the communications identifier including the relationship identifier in dependence upon the third party relationship data; and
sending, to the third party device, the communications identifier such that the third party device can include the communications identifier including the relationship identifier in dependence upon the third party relationship data when initiating the communications session with the user device in order to indicate that the communications session is genuine.
Van Rensburg teaches generating a communications identifier including a relationship identifier in dependence upon third party relationship data, e.g., at step 214, the caller verification system 110 registers the intended communication session by using the data received to generate a key, wherein the key is a hash of the caller's phone number, callee's phone number, and the call time window identifier (Fig. 1, el. 110; Fig. 2A, el. 214; Para. 174),
the third party relationship data including identity information about at least one third party organization having a pre-existing relationship with a user associated with the user device, e.g., the caller data may include one or more fields of data identifying and describing aspects of the caller, such as the caller's phone number, full name, the organization to which the caller belongs or is representing for the scope of the call, a title, level, position, role, or function of the caller in the context of the organization to which the caller belongs or is representing, and so forth, wherein a caller may be an individual who works for a bank's fraud department who calls a customer of the bank to warn about potentially fraudulent charges, wherein the caller data, in this example, may include the caller's phone number, full name, the bank name, the caller's title at the bank, and so forth (Para. 108).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger to include generating a communications identifier including a relationship identifier in dependence upon third party relationship data, the third party relationship data including identity information about at least one third party organization having a pre-existing relationship with a user associated with the user device, using the known method of generating, by the caller verification system, a key, wherein the key is a hash of the caller's phone number, callee's phone number, and the call time window identifier, as taught by van Rensburg, in combination with the system of validating the permission of a service to contact a user device of Schlesinger, for the purpose of confirming caller identities by verifying a specific registered communication session between callers and callees (van Rensburg-Para. 55).
Schlesinger in view of van Rensburg does not explicitly teach sending, to the user device, a communications notification, the communications notification comprising data relating to the communications channel that the third party device will use to connect to the user device, third party identification data and the communications identifier including the relationship identifier in dependence upon the third party relationship data; and
sending, to the third party device, the communications identifier such that the third party device can include the communications identifier including the relationship identifier in dependence upon the third party relationship data when initiating the communications session with the user device in order to indicate that the communications session is genuine.
Moliner teaches generating a communications identifier…, e.g., session server 114 may receive request 702 for a new session and assign a new session ID for the new session (block 603), wherein the session ID may uniquely identify the session created by session server 114 for application 402-1 running in user device 102-1 (Figs. 1A, 1B, el. 102-1; Fig. 1B, el. 114; Fig. 4A, el. 402-1; Fig. 6A, el. 603; Fig. 7A, el. 702; Para. 73), wherein Figure 6A, element 603 states “RECEIVE REQUEST, GENERATE NEW SESSION ID);
sending, to the user device, e.g., user device 102-2 (Figs. 1A, 1B, el. 102-2), a communications notification, the communications notification comprising data relating to the communications channel that the third party device, e.g., user device 102-1 (Figs. 1A, 1B, el. 102-1), will use to connect to the user device,…and the communications identifier…, e.g., if there is an open session for the telephone number, then session server 114 may transmit a message 742 to application 402-2 in user device 102-2, and Message 742 may include any session IDs found in session table 424 that correspond to the telephone number (block 668) (Fig. 4A, el. 402-2; Fig. 4B, el. 424; Fig. 6C, el. 668; Fig. 7C, el. 742; Para. 86); and
sending, to the third party device, the communications identifier such that the third party device can include the communications identifier…when initiating the communications session with the user device in order to indicate that the communications session is genuine, e.g., session server 114 may transmit a message 704 including the session ID to application 402-1 in user device 102-1 (block 604) (Fig. 6A, el. 604; Fig. 7A, el. 704; Para. 73); user device 102-1, as instructed by application 402-1, may transmit an SMS message 706 to user device 102-2 requesting that user device 102-2 join the new session (block 606) (Fig. 6A, el. 606; Fig. 7A, el. 706; Para. 74), wherein the SMS message 706 may also include the session ID received by application 402-1 in user device 102-1 in message 704 (Para. 75).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger in view of van Rensburg to include sending, to the user device, a communications notification, the communications notification comprising data relating to the communications channel that the third party device will use to connect to the user device, third party identification data and the communications identifier including the relationship identifier in dependence upon the third party relationship data; and sending, to the third party device, the communications identifier such that the third party device can include the communications identifier including the relationship identifier in dependence upon the third party relationship data when initiating the communications session with the user device in order to indicate that the communications session is genuine, using the known method of generating, by the session server, a new session ID and transmitting, by the session server, a message to the second user device, wherein the message may include any session IDs found in the session table that correspond to the telephone number, as taught by Moliner, in combination with the system of validating the permission of a service to contact a user device of Schlesinger in view of van Rensburg, for the purpose of enabling the user device or the application executed on the user device to utilize the verified session ID to provide a validated communication session.
Regarding claim 2, Schlesinger in view of van Rensburg in view of Moliner teaches a method as claimed in Claim 1, wherein, following receipt of the connection notification from the third party device the method further comprises checking that the third party device is registered with the authentication server, e.g., upon receiving 312 from a service 108 a token 308 and a request from the service 108 to communicate with the user 102, verify 314 that the relationship 204 represented by the token 308 permits communication between the service 108 and the user 102 (Schlesinger-Para. 23).
Regarding claim 3, Schlesinger in view of van Rensburg in view of Moliner teaches a method as claimed in claim 1.
Schlesinger does not clearly teach wherein, prior to receiving the connection notification from the third party device, the method further comprises receiving, verification data relating to the third party device and, on the basis of the verification data, registering the third party device with the authentication server.
Van Rensburg teaches wherein, prior to receiving the connection notification from the third party device, e.g., client devices 102/104, caller device 202 (Fig. 1, el. 102, 104; Fig. 2A, 2B, el. 202); at step 210, a caller device 202 initiates a call, via VoIP, PSTN, or any other system that supports telephony communication, and the call is processed by the caller telephony service system 204, which, at step 212 registers the intended communication and provides the caller data, callee data, and communication information to a caller verification system 110 (Fig. 1, 2A, el. 110; Fig. 2A, el. 204, 210, 212; Para. 173),
the method further comprises receiving, verification data relating to the third party device and, on the basis of the verification data, registering the third party device with the authentication server, e.g., caller verification system 110 (Fig. 1, 2A, el. 110); the pre-registration module 120 of the caller verification system 110 is configured to perform this pre-registration process, wherein at step 402, a set of caller information is pre-registered, wherein the set of caller information comprises at least a caller phone number, wherein when an organization or individual subscribes to the caller verification service through their telephony service provider, the phone number(s) associated with the organization or individual are pre-registered to indicate participation in the verification service (Fig. 1, el. 120; Fig. 4, el. 400, 402; Para. 188, 189).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger to include wherein, prior to receiving the connection notification from the third party device, the method further comprises receiving, verification data relating to the third party device and, on the basis of the verification data, registering the third party device with the authentication server, using the known method of pre-registering, by the caller verification system, the caller device, as taught by van Rensburg, in combination with the system of validating the permission of a service to contact a user device of Schlesinger, using the same motivation as in claim 1.
Regarding claim 4, Schlesinger in view of van Rensburg in view of Moliner teaches a method as claimed in claim 1, wherein prior to receiving the connection notification, the method comprises receiving user data and, on the basis of the received user data, registering the user device with the authentication server, e.g., the user 102 of an email account 104 and a mobile phone 106 establishes a user profile 110 with the communication manager that indicates the communication channels 704 through which the user 102 is reachable (Schlesinger-Fig. 7, el. 704; Para. 49).
Regarding claim 5, Schlesinger in view of van Rensburg in view of Moliner teaches a method as claimed in claim 4, wherein the received user data comprises user contact data and the third party relationship data, e.g., the user 102 of an email account 104 and a mobile phone 106 establishes a user profile 110 with the communication manager that indicates the communication channels 704 through which the user 102 is reachable (Schlesinger-Fig. 7, el. 704; Para. 49); the user 102 may first create a user profile 110 with the communication manager 514, e.g., indicating the available set of communication channels of the user 102, wherein the communication manager 514 may therefore store in the user profile 110 the relationships 204 created between the user 102 and the services 108, and/or may associate tokens 208 generated for various services 108 with the relationships 204 represented in the user profile 110 (Schlesinger-Para. 38).
Regarding claim 7, Schlesinger in view of van Rensburg in view of Moliner teaches a method as claimed in claim 5, wherein the user identifier contained within the connection notification comprises the relationship identifier, e.g., the token 208 represents the relationship 204, e.g., indicating the permission granted by the user 102 to send messages 112 or other communication to the user 102 (Schlesinger-Para. 20); receiving a request 206 from the service 108 to communicate with the user 102 through a particular communication channel, wherein the user 102 may specify criteria regarding such communication channels that may be included in the evaluation of a request 206 and the user 102 may specify particular per-server, per-communication-channel permissions, e.g., authorizing respective services 108 to use one or more of the communication channels, and may prohibit the same service 108 from using one or more other communication channels, wherein the communication manager 202 may receive such selections from the user 102, and may store such authorizations in the stored relationship 204 and/or user profile 110 of the user 102, and/or may encode such authorizations in the token 208 sent to the service 108 (Schlesinger-Para. 47).
Regarding claim 10, Schlesinger in view of van Rensburg in view of Moliner teaches a method as claimed in claim 1.
Schlesinger further teaches checking the user profile to determine if the user device has an existing relationship with the third party device…, e.g., the communication manager 202 may compare the token 208 with the relationship 204 to the service 108 defined by the user 102, and may permit or deny the communication based on this comparison (Para. 20).
Schlesinger does not clearly teach checking the user profile to determine if the user device has an existing relationship with the third party device and, in the event that such a relationship is absent, sending a connection request to the user device in order to check that the user device wishes to accept the communications session from the third party device.
Van Rensburg teaches checking the database to determine if the user device, e.g., client devices 102/104, caller device 308 (Fig. 1, el. 102, 104; Fig. 3A, 3B, el. 308), has an existing relationship with the third party device, e.g., client devices 102/104, caller device 302 (Fig. 1, el. 102, 104; Fig. 3A, 3B, el. 302), and, in the event that such a relationship is absent, sending a connection request to the user device in order to check that the user device wishes to accept the communications session from the third party device, e.g., at step 318, the caller verification system 110, verifies that the intended communication is not registered, and the results are sent to the callee telephony service system 306, wherein the verification module 124 will combine the caller phone number, callee phone number, and the call time window identifier and then apply a hash algorithm to generate a comparison key, and the verification module 124 will then compare the comparison key with the keys stored in database 130 (Fig. 3A, el. 318; Para. 184); at step 320, the callee telephony service system 306 relays the results of the unsuccessful caller verification to the callee device 308, and at step 322, in response to receiving the results of the unsuccessful caller verification, the call is rejected using the callee device 308 (Fig. 3A, el. 320, 322; Para. 185).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger to include checking the user profile to determine if the user device has an existing relationship with the third party device and, in the event that such a relationship is absent, sending a connection request to the user device in order to check that the user device wishes to accept a communications session from the third party device, using the known method of verifying, by the caller verification system, that the intended communication is not registered, and sending the results of the unsuccessful caller verification to the callee device where the call is rejected, as taught by van Rensburg, in combination with the system of validating the permission of a service to contact a user device of, for the purpose of confirming caller identities by verifying a specific registered communication session between callers and callees (van Rensburg-Para. 55).
Regarding claim 11, Schlesinger in view of van Rensburg in view of Moliner teaches a method as claimed in claim 1.
Schlesinger in view of van Rensburg does not clearly teach further comprising sending the communications identifier to multiple recipients associated with the user device.
Moliner further teaches sending the communications identifier to multiple recipients associated with the user device, e.g., if there is an open session for the telephone number, then session server 114 may transmit a message 742 to application 402-2 in user device 102-2, and Message 742 may include any session IDs found in session table 424 that correspond to the telephone number (block 668) (Fig. 4A, el. 402-2; Fig. 4B, el. 424; Fig. 6C, el. 668; Fig. 7C, el. 742; Para. 86); if Magus and Pierre invite a third friend to join BattleZ game, the third friend may join the same session identified in session ID field 502 (Para. 59); participating parties field 504 ("parties field 504") may identify the parties that may connect to the corresponding session, wherein one or more parties may be identified as an "invited" party if that party has been invited by another party (Para. 60).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger in view of van Rensburg to include sending the communications identifier sent to multiple recipients associated with the user device, using the known method of generating, by the session server, a new session ID and transmitting, by the session server, a message to the second user device, wherein a third friend may also be invited to join the same session, as taught by Moliner, in combination with the system of validating the permission of a service to contact a user device of Schlesinger in view of van Rensburg, using the same motivation as in claim 1.
Regarding claim 12, Schlesinger in view of van Rensburg in view of Moliner teaches a method as claimed in claim 1.
Schlesinger in view of van Rensburg does not clearly teach further comprising sending the communications identifier to a communications application installed on the user device, the communications application configured to communicate over the communications channel identified by the third party device in the connection notification.
Moliner further teaches sending the communications identifier to a communications application installed on the user device, the communications application configured to communicate over the communications channel identified by the third party device in the connection notification, e.g., if there is an open session for the telephone number, then session server 114 may transmit a message 742 to application 402-2 in user device 102-2, and Message 742 may include any session IDs found in session table 424 that correspond to the telephone number (block 668) (Fig. 4A, el. 402-2; Fig. 4B, el. 424; Fig. 6C, el. 668; Fig. 7C, el. 742; Para. 86).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger in view of van Rensburg to include sending the communications identifier to a communications application installed on the user device, the communications application configured to communicate over the communications channel identified by the third party device in the connection notification, using the known method of generating, by the session server, a new session ID and transmitting, by the session server, a message to an application on the second user device, as taught by Moliner, in combination with the system of validating the permission of a service to contact a user device of Schlesinger in view of van Rensburg, using the same motivation as in claim 1.
Regarding claim 15, Schlesinger teaches a method of initiating a communications session from a third party device, e.g., service 108 (Figs. 1, 2, 5, 7, el. 108), to a user device, e.g., mobile phone 106 (Figs. 1, 2, 7, el. 106); client device 502 (Fig. 5, el. 502); when a service 108 wishes to contact the user 102, the service 108 may send the message 112 or a request to initiate communication with the user 102 to the communication manager 202, along with the token 208 identifying the relationship 204 with the user 102, wherein the communication manager 202 may compare the token 208 with the relationship 204 to the service 108 defined by the user 102, and may permit or deny the communication based on this comparison (Figs. 2, 5, el. 204, 208; Para. 20), comprising:
sending, a connection notification from the third party device to an authentication server, e.g., communication manager 202/514/302 (Fig. 2, el. 202; Fig. 5, el. 514; Fig. 7, el. 302), the connection notification indicating an intention of the third party device to initiate the communications session with the user device, e.g., when a service 108 wishes to contact the user 102, the service 108 may send the message 112 or a request to initiate communication with the user 102 to the communication manager 202, along with the token 208 identifying the relationship 204 with the user 102 (Para. 20); receiving a request 206 from the service 108 to communicate with the user 102 through a particular communication channel (Para. 47),
the connection notification comprising a user identifier and identification of a communications channel that will be used for the communications session, e.g., the token 208 represents the relationship 204, e.g., indicating the permission granted by the user 102 to send messages 112 or other communication to the user 102 (Para. 20); receiving a request 206 from the service 108 to communicate with the user 102 through a particular communication channel, wherein the user 102 may specify criteria regarding such communication channels that may be included in the evaluation of a request 206 and the user 102 may specify particular per-server, per-communication-channel permissions, e.g., authorizing respective services 108 to use one or more of the communication channels, and may prohibit the same service 108 from using one or more other communication channels, wherein the communication manager 202 may receive such selections from the user 102, and may store such authorizations in the stored relationship 204 and/or user profile 110 of the user 102, and/or may encode such authorizations in the token 208 sent to the service 108 (Para. 47);
…a…identifier…including a relationship identifier in dependence upon third party relationship data with the user device, e.g., upon receiving 206 a request 206 to establish a relationship 204 between a user 102 and a service 108, generate 308 a token 208 identifying the relationship 204 with the user 102, and send 310 the token 208 to the service 108 (Fig. 3, el. 308; Para. 23),
the third party relationship data including identity information about at least one third party organization having a pre-existing relationship with a user associated with the user device, e.g., upon receiving 206 a request 206 to establish a relationship 204 between a user 102 and a service 108, generate 308 a token 208 identifying the relationship 204 with the user 102, and send 310 the token 208 to the service 108 (Fig. 3, el. 308; Para. 23);
the techniques provided herein may establish many types of services 108 and relationships 204 between users 102 and services 108, wherein the services 108 may include informational services; commercial services; social services, such as social networks; and data services, such as file transfer, wherein the relationships 204 may include commercial, academic, and/or professional relationships; membership of the user 102 in a group or organization; and a service-oriented relationship where the user 102 simply invokes the services of the service 108 (Para. 34); and
initiating the communications session with the user device over the communications channel comprising sending a session request…to the user device in order to indicate that the communications session is genuine, e.g., upon receiving a communication from the service 108, verify with the communication manager 514 that the relationship 204 between the service 108 and the user 102 permits the communication, and after verifying the relationship 204 with the communication manager 514, present the communication from the service 108 to the user 102 (Figs. 2, 5, el. 204; Para. 25).
Schlesinger does not clearly teach receiving, at the third party device, a communications identifier from the authentication server including a relationship identifier in dependence upon third party relationship data with the user device; and
initiating the communications session with the user device over the communications channel comprising sending a session request comprising the communications identifier including the relationship identifier in dependence upon the third party relationship data with the user device to the user device in order to indicate that the communications session is genuine.
Van Rensburg teaches …a communications identifier…including a relationship identifier in dependence upon third party relationship data with the user device, e.g., at step 214, the caller verification system 110 registers the intended communication session by using the data received to generate a key, wherein the key is a hash of the caller's phone number, callee's phone number, and the call time window identifier (Fig. 1, el. 110; Fig. 2A, el. 214; Para. 174),
the third party relationship data including identity information about at least one third party organization having a pre-existing relationship with a user associated with the user device, e.g., the caller data may include one or more fields of data identifying and describing aspects of the caller, such as the caller's phone number, full name, the organization to which the caller belongs or is representing for the scope of the call, a title, level, position, role, or function of the caller in the context of the organization to which the caller belongs or is representing, and so forth, wherein a caller may be an individual who works for a bank's fraud department who calls a customer of the bank to warn about potentially fraudulent charges, wherein the caller data, in this example, may include the caller's phone number, full name, the bank name, the caller's title at the bank, and so forth (Para. 108).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger to include a communications identifier including a relationship identifier in dependence upon third party relationship data with the user device, the third party relationship data including identity information about at least one third party organization having a pre-existing relationship with a user associated with the user device, using the known method of generating, by the caller verification system, a key, wherein the key is a hash of the caller's phone number, callee's phone number, and the call time window identifier, as taught by van Rensburg, in combination with the system of validating the permission of a service to contact a user device of Schlesinger, for the purpose of confirming caller identities by verifying a specific registered communication session between callers and callees (van Rensburg-Para. 55).
Schlesinger van Rensburg does not clearly teach receiving, at the third party device, a communications identifier from the authentication server including a relationship identifier in dependence upon third party relationship data with the user device; and
initiating the communications session with the user device over the communications channel comprising sending a session request comprising the communications identifier including the relationship identifier in dependence upon the third party relationship data with the user device to the user device in order to indicate that the communications session is genuine.
Moliner teaches receiving, at the third party device, e.g., user device 102-1 (Figs. 1A, 1B, el. 102-1), a communications identifier from the authentication server…, e.g., session server 114 (Fig. 1B, el. 114); session server 114 may transmit a message 704 including the session ID to application 402-1 in user device 102-1 (block 604) (Fig. 6A, el. 604; Fig. 7A, el. 704; Para. 73); user device 102-1, as instructed by application 402-1, may transmit an SMS message 706 to user device 102-2 requesting that user device 102-2 join the new session (block 606) (Fig. 6A, el. 606; Fig. 7A, el. 706; Para. 74), wherein the SMS message 706 may also include the session ID received by application 402-1 in user device 102-1 in message 704 (Para. 75); and
initiating the communications session with the user device over the communications channel comprising sending a session request comprising the communications identifier…to the user device in order to indicate that the communications session is genuine, e.g., user device 102-1, as instructed by application 402-1, may transmit an SMS message 706 to user device 102-2 requesting that user device 102-2 join the new session (block 606) (Fig. 6A, el. 606; Fig. 7A, el. 706; Para. 74), wherein the SMS message 706 may also include the session ID received by application 402-1 in user device 102-1 in message 704 (Para. 75).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger to include receiving, at the third party device, a communications identifier from the authentication server including a relationship identifier in dependence upon third party relationship data with the user device; and initiating the communications session with the user device over the communications channel comprising sending a session request comprising the communications identifier including the relationship identifier in dependence upon the third party relationship data with the user device to the user device in order to indicate that the communications session is genuine, using the known method of generating, by the session server, a new session ID and transmitting, by the session server, a message to the second user device, wherein the message may include any session IDs found in the session table that correspond to the telephone number, as taught by Moliner, in combination with the system of validating the permission of a service to contact a user device of Schlesinger, for the purpose of enabling the user device or the application executed on the user device to utilize the verified session ID to provide a validated communication session.
Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Schlesinger in view of van Rensburg in view of Moliner and further in view of Ross et al. (US 10,298,759 B1).
Regarding claim 8, Schlesinger in view of van Rensburg in view of Moliner teaches a method as claimed in claim 1.
Schlesinger further teaches further comprising checking for the presence of the relationship identifier…within the connection notification received from the third party device and, in the event that the relationship identifier is present, proceeding…, e.g., when a service 108 wishes to contact the user 102, the service 108 may send the message 112 or a request to initiate communication with the user 102 to the communication manager 202, along with the token 208 identifying the relationship 204 with the user 102, wherein the communication manager 202 may compare the token 208 with the relationship 204 to the service 108 defined by the user 102 (Para. 20); receiving a request 206 from the service 108 to communicate with the user 102 through a particular communication channel (Para. 47).
Schlesinger in view of van Rensburg does not clearly teach checking for the presence of the relationship identifier that has previously been sent by the authentication server to the user device within the connection notification received from the third party device and, in the event that the relationship identifier is present, proceeding to generating the communications identifier.
Moliner further teaches checking for the presence of the relationship identifier…within the connection notification received from the third party device and, in the event that the relationship identifier is present, proceeding to generating the communications identifier, e.g., session server 114 may receive request 702 for a new session and assign a new session ID for the new session (block 603), wherein the session ID may uniquely identify the session created by session server 114 for application 402-1 running in user device 102-1 (Para. 73), wherein Figure 6A, element 603 states “RECEIVE REQUEST, GENERATE NEW SESSION ID, wherein session server 114 may store the session ID in session table 424, and session server 114 may create a record 516 in session table 424 (see FIG. 5A) corresponding to the new session requested by user device 402-1, wherein the session request 702 may include the telephone number of the user device invited to the new session and the telephone number of the inviting user device (Para. 72); participating parties field 504 ("parties field 504") may identify the parties that may connect to the corresponding session, wherein parties may be identified by one or more of the following: telephone number, username, an application registration number, and/or a connection identifier (Fig. 5A, el. 504; Para. 60).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger in view of van Rensburg to include checking for the presence of the relationship identifier that has previously been sent by the authentication server to the user device within the connection notification received from the third party device and, in the event that the relationship identifier is present, proceeding to generating the communications identifier, using the known method of receiving, by the session server, a request for a new session and assign a new session ID for the new session, wherein the session request may include the telephone number of the user device invited to the new session and the telephone number of the inviting user device, and generating, by the session server, a new session ID, as taught by Moliner, in combination with the system of validating the permission of a service to contact a user device of Schlesinger, using the same motivation as in claim 1.
Schlesinger in view of van Rensburg in view of Moliner does not clearly teach checking for the presence of the relationship identifier that has previously been sent by the authentication server to the user device within the connection notification received from the third party device and, in the event that the relationship identifier is present, proceeding to generating the communications identifier.
Ross teaches checking for the presence of a relationship identifier that has previously been sent by the authentication server to the user device within the request received from the third party device, e.g., at step 426, the customer may consent to share some of their PayService data with the merchant (Fig. 4, el. 426; Col. 16, lines 65-67); at step 428, upon successful authentication of the customer, PayService's authentication server 152 sends an authorization code ABCDEF to the user's browser 146, alternatively a separate data sharing token may be issued by the authentication server 152 and sent to the user's browser 146 (Fig. 1, el. 146, 150; Fig. 4, el. 428; Col. 17, lines 1-10); at step 430, the data server 126 may send the data sharing token to PayService's User Profile Service 152, to request the user data (Fig. 4, el. 430; Col. 17, lines 10-13); an authentication server 150 may return a data sharing token to the customer's mobile device 144 (Fig. 1, el. 144, 150; Col. 13, lines 51-52).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger in view of van Rensburg in view of Moliner to include checking for the presence of a relationship identifier that has previously been sent by the authentication server to the user device within the connection notification received from the third party device and, in the event that the relationship identifier is present, proceeding to generating the communications identifier, using the known method of returning, by an authentication server, a data sharing token to the customer's mobile device, as taught by Ross, in combination with the system of validating the permission of a service to contact a user device of Schlesinger in view of van Rensburg in view of Moliner, for the purpose of enabling the user device or the application executed on the user device to utilize the token to validate the relationship with the third party, thereby at least providing backup storage of the token.
Regarding claim 9, the claim is analyzed with respect to claim 8. Examiner Note: Claim 9 includes a contingent limitation such that the “sending a connection request to the user device in order to check that the user device wishes to accept a communications session from the third party device” is contingent on “the relationship identifier is absent from the connection notification”. The limitation would not be performed if the relationship identifier was present in the connection notification as claimed in claim 8. See MPEP 2111.04 (II).
Claims 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Schlesinger in view of van Rensburg in view of Moliner and further in view of Takechi et al. (US 2007/0255784 A1).
Regarding claim 13, Schlesinger in view of van Rensburg in view of Moliner teaches a method as claimed in claim 1.
Schlesinger in view of van Rensburg in view of Moliner does not clearly teach wherein the communications identifier comprises a validity period and the method comprises sending the validity period to the user device along with the communications identifier.
Van Rensburg further teaches wherein the communications identifier comprises a validity period…, e.g., at step 214, the caller verification system 110 registers the intended communication session by using the data received to generate a key, wherein the key is a hash of the caller's phone number, callee's phone number, and the call time window identifier (Fig. 1, el. 110; Fig. 2A, el. 214; Para. 174).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger to include wherein the communications identifier comprises a validity period, using the known method of generating, by the caller verification system, a key, wherein the key is a hash of the caller's phone number, callee's phone number, and the call time window identifier, as taught by van Rensburg, in combination with the system of validating the permission of a service to contact a user device of Schlesinger, using the same motivation as in claim 1.
Schlesinger in view of van Rensburg in view of Moliner does not clearly teach wherein the communications identifier comprises a validity period and the method comprises sending the validity period to the user device along with the communications identifier.
Takechi teaches wherein the communications identifier comprises a validity period and the method comprises sending the validity period to the user device along with the communications identifier, e.g., the server apparatus 103 that has received the connection response packet 210a generates a session identifier SID2 at step S49, wherein the session identifier SID2 is issued to certify that the server apparatus 103 successfully authenticates both the communication equipments 101 and 102 and that the server apparatus 103 permits establishment of a peer-to-peer connection between the communication equipments 101 and 102, wherein the session identifier SID2 further includes an expiration date before the peer-to-peer connection permitted by the server apparatus 103 is started (Fig. 20, el. S49; Para. 527); after generating the session identifier SID2, the server apparatus 103 then notifies the communication equipment 101 of the session identifier SID2, and the server apparatus 103 transmits a connection response transfer packet 290 including the encrypted session identifier SID2 to the communication equipment 102 (Fig. 20, el. 289, 290; Para. 529).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger in view of van Rensburg in view of Moliner to include sending the validity period to the user device along with the communications identifier, using the known method of transmitting a session identifier to both first and second communication equipments, wherein the session identifier includes an expiration date, as taught by Takechi, in combination with the system of validating the permission of a service to contact a user device of Schlesinger in view of van Rensburg in view of Moliner, for the purpose of eliminating a possible connection by an illegal communication equipment if the expiration date is passed (Takechi-Para. 533).
Regarding claim 14, Schlesinger teaches a method of operating a user device, e.g., mobile phone 106 (Figs. 1, 2, 7, el. 106); client device 502 (Fig. 5, el. 502), configured to communicate with an authentication server, e.g., communication manager 202/514/302 (Fig. 2, el. 202; Fig. 5, el. 514; Fig. 7, el. 302), and to accept a communications session from a third party device, e.g., service 108 (Figs. 1, 2, 5, 7, el. 108); when a service 108 wishes to contact the user 102, the service 108 may send the message 112 or a request to initiate communication with the user 102 to the communication manager 202, along with the token 208 identifying the relationship 204 with the user 102, wherein the communication manager 202 may compare the token 208 with the relationship 204 to the service 108 defined by the user 102, and may permit or deny the communication based on this comparison (Figs. 2, 5, el. 204, 208; Para. 20), the method comprising:
receiving…from the authentication server along with third party identification data and data relating to a communications channel that the third party device will use to connect to the user device in the communications session, e.g., when a service 108 requests to initiate direct contact with the user 102, the communication manager 514 may determine whether such contact is authorized, and may directly advise the user 102 of whether or not to accept the communication (e.g., "this caller is among your blocked services list"), and the client device 502 may present the advice of the communication manager 514 to the user 102 (Para. 46),
the…identifier including a relationship identifier in dependence upon third party relationship data, e.g., upon receiving 206 a request 206 to establish a relationship 204 between a user 102 and a service 108, generate 308 a token 208 identifying the relationship 204 with the user 102, and send 310 the token 208 to the service 108 (Fig. 3, el. 308; Para. 23),
the third party relationship data including identity information about at least one third party organization having a pre-existing relationship with a user associated with the user device, e.g., upon receiving 206 a request 206 to establish a relationship 204 between a user 102 and a service 108, generate 308 a token 208 identifying the relationship 204 with the user 102, and send 310 the token 208 to the service 108 (Fig. 3, el. 308; Para. 23);
the techniques provided herein may establish many types of services 108 and relationships 204 between users 102 and services 108, wherein the services 108 may include informational services; commercial services; social services, such as social networks; and data services, such as file transfer, wherein the relationships 204 may include commercial, academic, and/or professional relationships; membership of the user 102 in a group or organization; and a service-oriented relationship where the user 102 simply invokes the services of the service 108 (Para. 34);
receiving a session request from the third party device to initiate the communications session…, e.g., upon receiving a communication from the service 108, verify with the communication manager 514 that the relationship 204 between the service 108 and the user 102 permits the communication, and after verifying the relationship 204 with the communication manager 514, present the communication from the service 108 to the user 102 (Figs. 2, 5, el. 204; Para. 25); and
…accepting the session request from the third party device…, e.g., upon receiving a communication from the service 108, verify with the communication manager 514 that the relationship 204 between the service 108 and the user 102 permits the communication, and after verifying the relationship 204 with the communication manager 514, present the communication from the service 108 to the user 102 (Figs. 2, 5, el. 204; Para. 25).
Schlesinger does not clearly teach receiving a communications identifier from an authentication server along with third party identification data and data relating to a communications channel that the third party device will use to connect to the user in the communications session, the communications identifier including a relationship identifier in dependence upon third party relationship data;
receiving a session request from the third party device to initiate a communications session, the session request comprising a third party provided communications identifier including the relationship identifier; and
determining if the communications identifier received from the authentication server matches the third party provided communications identifier and accepting the session request from the third party device in the event that there is a match.
Van Rensburg teaches the communications identifier including a relationship identifier in dependence upon third party relationship data, e.g., at step 214, the caller verification system 110 registers the intended communication session by using the data received to generate a key, wherein the key is a hash of the caller's phone number, callee's phone number, and the call time window identifier (Fig. 1, el. 110; Fig. 2A, el. 214; Para. 174),
the third party relationship data including identity information about at least one third party organization having a pre-existing relationship with a user associated with the user device, e.g., the caller data may include one or more fields of data identifying and describing aspects of the caller, such as the caller's phone number, full name, the organization to which the caller belongs or is representing for the scope of the call, a title, level, position, role, or function of the caller in the context of the organization to which the caller belongs or is representing, and so forth, wherein a caller may be an individual who works for a bank's fraud department who calls a customer of the bank to warn about potentially fraudulent charges, wherein the caller data, in this example, may include the caller's phone number, full name, the bank name, the caller's title at the bank, and so forth (Para. 108).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger to include the communications identifier including a relationship identifier in dependence upon third party relationship data, the third party relationship data including identity information about at least one third party organization having a pre-existing relationship with a user associated with the user device, using the known method of generating, by the caller verification system, a key, wherein the key is a hash of the caller's phone number, callee's phone number, and the call time window identifier, as taught by van Rensburg, in combination with the system of validating the permission of a service to contact a user device of Schlesinger, for the purpose of confirming caller identities by verifying a specific registered communication session between callers and callees (van Rensburg-Para. 55).
Schlesinger in view of van Rensburg does not clearly teach receiving a communications identifier from an authentication server along with third party identification data and data relating to a communications channel that the third party device will use to connect to the user in the communications session, the communications identifier including a relationship identifier in dependence upon third party relationship data;
receiving a session request from the third party device to initiate a communications session, the session request comprising a third party provided communications identifier including the relationship identifier; and
determining if the communications identifier received from the authentication server matches the third party provided communications identifier and accepting the session request from the third party device in the event that there is a match.
Moliner teaches receiving a communications identifier from an authentication server, e.g., session server 114 (Fig. 1B, el. 114), along with…data relating to a communications channel that the third party device, e.g., user device 102-1 (Figs. 1A, 1B, el. 102-1), will use to connect to the user in the communications session…, e.g., if there is an open session for the telephone number, then session server 114 may transmit a message 742 to application 402-2 in user device 102-2, and Message 742 may include any session IDs found in session table 424 that correspond to the telephone number (block 668) (Fig. 4A, el. 402-2; Fig. 4B, el. 424; Fig. 6C, el. 668; Fig. 7C, el. 742; Para. 86);
receiving a session request from the third party device to initiate the communications session, the session request comprising a third party provided communications identifier…, e.g., session server 114 may transmit a message 704 including the session ID to application 402-1 in user device 102-1 (block 604) (Fig. 6A, el. 604; Fig. 7A, el. 704; Para. 73); user device 102-1, as instructed by application 402-1, may transmit an SMS message 706 to user device 102-2 requesting that user device 102-2 join the new session (block 606) (Fig. 6A, el. 606; Fig. 7A, el. 706; Para. 74), wherein the SMS message 706 may also include the session ID received by application 402-1 in user device 102-1 in message 704 (Para. 75); and
….
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger in view of van Rensburg to include receiving a communications identifier from an authentication server along with third party identification data and data relating to a communications channel that the third party device will use to connect to the user in the communications session, the communications identifier including a relationship identifier in dependence upon third party relationship data; and receiving a session request from the third party device to initiate a communications session, the session request comprising a third party provided communications identifier including the relationship identifier, using the known method of generating, by the session server, a new session ID and transmitting, by the session server, a message to the second user device, wherein the message may include any session IDs found in the session table that correspond to the telephone number, as taught by Moliner, in combination with the system of validating the permission of a service to contact a user device of Schlesinger in view of van Rensburg, for the purpose of enabling the user device or the application executed on the user device to utilize the verified session ID to provide a validated communication session.
Schlesinger in view of van Rensburg in view of Moliner does not clearly teach determining if the communications identifier received from the authentication server matches the third party provided communications identifier and accepting the session request from the third party device in the event that there is a match.
Takechi teaches receiving a session request from the third party device, e.g., communication equipment 102 (Figs. 1, 20, el. 102), to initiate the communications session, the session request comprising a third party provided communications identifier…, e.g., the communication equipment 102 transmits a peer-to-peer communication start request packet 293 to the communication equipment 101, and during the transmission, the session identifier SID2 stored in the internal memory of the communication equipment 102 is encrypted by the encryption key K3, and the encrypted session identifier SID2 is added to the peer-to-peer communication start request packet 293 (Fig. 20, el. 101, 293; Para. 533); and
determining if the communications identifier received from the authentication server, e.g., server apparatus 103 (Figs. 1, 20, el. 103), matches the third party provided communications identifier and accepting the session request from the third party device in the event that there is a match, e.g., after generating the session identifier SID2, the server apparatus 103 then notifies the communication equipment 101 of the session identifier SID2, and the server apparatus 103 transmits a connection response transfer packet 290 including the encrypted session identifier SID2 to the communication equipment 102 (Fig. 20, el. 289, 290; Para. 529); the communication equipment 101 compares the session identifier SID2 received from the communication equipment 102 with the session identifier SID2 stored in the internal memory of the communication equipment 101, and if these session identifiers SID2 coincide with each other, the communication equipment 101 judges that the peer-to-peer connection established between the communication equipments 101 and 102 is permitted by the server apparatus 103 (Para. 533).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Schlesinger in view of van Rensburg in view of Moliner to include determining if the communications identifier received from the authentication server matches the third party provided communications identifier and accepting the session request from the third party device in the event that there is a match, using the known method of transmitting a session identifier to both first and second communication equipments, and comparing the session identifier received from the second communication equipment with the session identifier stored in the internal memory of the first communication equipment, and if these session identifiers coincide with each other, the first communication equipment judges that the peer-to-peer connection established between the first and second communication equipments is permitted by the server apparatus, as taught by Takechi, in combination with the system of validating the permission of a service to contact a user device of Schlesinger in view of van Rensburg in view of Moliner, for the purpose of eliminating a possible connection by an illegal communication equipment (Takechi-Para. 533).
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Gadwale (US 2021/0084034 A1)—Gadwale discloses at step 502, the call center 520 further initiates a second communication to the client device 550, for example by instructing a trusted application service to PUSH a notification of the impending call issued at step 501 to the client device 550 (Para. 48).
Levergood et al. (US 7,272,639 B1)—Levergood discloses the session identifier includes an expiration time for the session (Claim 3).
Adibi et al. (US 2021/0136209 A1)—Adibi discloses a virtual agent that may answer calls to detect whether the call is spam, a fraud call, or a bot in a totally automated manner (Para. 73).
Jiron et al. (US 2019/0394333 A1)—Jiron discloses a call screening computing system is described that is configured to perform voice captcha and real-time monitoring of calls into a contact center of an organization (Abstract).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMY DUFFIELD whose telephone number is (571)270-1643. The examiner can normally be reached Monday - Friday, 7:00 AM - 3:00 PM (ET).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yin-Chen Shaw can be reached at (571) 272-8878. 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.
07 January 2026
/Jeremy S Duffield/Primary Examiner, Art Unit 2498