DETAILED ACTION
Response to Amendment
Applicant's response with amendments filed on [insert date] has been received and entered. Applicant has amended claims 1, 7-11 and 14-16, and canceled claims 4-6, 12-13 and 19-20. Claims 1-3, 7-11 and 14-18 have been examined on the merits.
Response to Arguments
Claim objection for claim 10 has been withdrawn in view of the amendments.
Applicant's arguments filed on 06/04/2026, pages 8-10, regarding claims 1, 10 and 16, have been fully considered but they are not persuasive.
Regarding cited reference Martin as applied to prior claim 4, applicant argues:
While Martin also may describe that an application can be "downloaded onto mobile device 105 over network 108,"5 Martin fails to tie the originating caller (i.e., the computing system in claim 1) to the publisher of the application. For example, in amended claim 1, the computing system placing the call leverages the trusted publisher to seed the user's device with call verification logic. Amended claim 1 specifies how this is performed at the user device, reciting that "a caller identifier and a validation token [is sent] to the user device over a network," and the user device "associate[s] the phone call with the application based on the caller identifier." Tiku, Gray, and Martin all fail to teach this specific three-party chain of trust (e.g., computing system -> trusted publisher -> user device) that enables a call from the computing system to be verifiably identified at the user device. Although the Office indicates that in Martin, the "financial institution 101 is trusted because the caller has an existing association with it (e.g., financial account)", this misses the specific requirement of amended claim 1 that the trusted application publisher be a "third-party publisher" distinct from the user and the operator of the computing system (i.e., financial institution).
Martin discloses systems and methods for using a mobile device to securely and automatically authenticate a caller's identity. In [0019-0021], Martin discloses, inter alia, that the financial institution 101 may be, for example, a bank (e.g., a retail bank, direct bank, and/or commercial bank), other type of financial institution, including a credit card and/or debit card provider, brokerage services provider, for example, and/or any other entity that offers accounts to customers; and, that mobile device 105 may include one or more software applications, such as caller authentication application 110 which may be downloaded onto mobile device 105 over network 108 or may be pre-installed on the mobile device.
In [0037], Martin discloses that the caller authentication application 110 may be a stand-alone application on the mobile device that provides the functionality or the functionality of the caller authentication application 110 may be included as part of a larger mobile application for mobile banking, such as a mobile banking application provided by financial institution 101 and/or a third party. Generally, the term “and/or” is interpreted as covering (1) embodiments having only any one of the listed items and (2) embodiments including two or more of the listed items. For example, "I and/or II" is interpreted to cover an embodiment having only I, an embodiment having only II, and an embodiment having both I and II. In this instance, the mobile banking application including the functionality of the caller authentication application may be provided by the financial institution and a third party. To support this interpretation, in [0041] for instance, the caller may register identifying information directly to financial institution 101 using one or more websites provided by, for example, financial institution 101 and/or a third party associated with financial institution 101. In other words, the financial institution and the third party are partnered or tied in some manner, and thus are associated for the purposes of registration and/or application service provision.
As discussed in the prior Office Action, the financial institution 101 is trusted because the caller has an existing association with it (e.g., financial account) as disclosed in [0019] and the third party associated with the financial institution is also trusted by way of their association and the fact that registration and/or application services are provided by the financial institution and/or associated third party, as disclosed in [0041]. Therefore, given the broadest reasonable interpretation, Martin teaches that the trusted application publisher be a "trusted third-party application publisher" distinct from the user and the operator of the computing system (i.e., financial institution).
The limitation reciting "requesting, by the computing system, initiation of a phone call from the computing system to the user device, wherein requesting the initiation includes sending a caller identifier and a validation token to the user device over a network, and enabling the user device to associate the phone call with the application based on the caller identifier" in amended claim 1, has been amended, at least in part, by incorporating elements of prior claim 6. Neither Tiku, nor Gray nor Martin were cited to teach “enabling the user device to determine, based on the caller identification number, that the requested communication with the user device is associated with the application” as recited in prior claim 6. Instead, Hamilton was cited to teach this limitation.
Applicant also argues:
Further, Martin also only describes a call that operates in the opposite direction of the call being placed in amended claim 1. In other words, Martin describes a user phone call from a user device to a call center (e.g., operated by a financial institution), whereas claim 1 recites "initiation of a phone call… to the user device"7 from another system (e.g., where that other system may be operated by a financial institution).
Martin is not being cited to teach the direction of the call nor the intricacies of the phone call interaction between the computing system and the user device. For this particular matters, examiner cited Tiku and Gray.
Therefore, given the broadest reasonable interpretation, Tiku, Gray, Martin and Hamilton teach all the elements of amended claim 1 as discussed below under section “Claim Rejections - 35 USC § 103”. Likewise, Trim, Abad and Martin disclose all the elements of amended claim 10, as discussed below.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 8-9 and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Tiku et al. (US 10149156 B1), hereinafter Tiku, in view of Gray et al. (US 20210044696 A1), hereinafter Gray, Martin (US 20150094026 A1) and Hamilton et al. (US 11330098 B1), hereinafter Hamilton.
Regarding claim 1, Tiku discloses a method (see FIGs. 5 and 7) comprising:
requesting, by the computing system (“first communication device 104” and “trusted caller ID authority 112”), initiation of a phone call from the computing system to the user device, wherein requesting initiation includes sending a caller identifier and a validation token (“authentication object (AO) 118”) to the user device (“second communication device 108”) over a network (the first communication device 104 initiates a call 716 to second communication device 108 and provides the second communication device 108 an authentication object 118 associated with first communication device 104 – see col. 24, lines 30-44; the AO 118 may comprise a signed caller ID certificate or a caller ID token, also referred to as a trusted token – see col. 7, line16 - col. 8, line 3; a trusted token may include one or more of a username, a personal identification number, hardware identification number, or a secret shared between the first communication device and the server – see col. 4, lines 18-24),
after sending the validation token to the user device, receiving, by the computing system and from the application executing on the user device over the network, a verification request (a trusted caller ID application executing on the communication devices used to register with the server, provide registration data, manage authentication objects, validate the authentication objects, and so forth - see col. 3, lines 8-16; to request validation of the first communication device 104 from trusted caller ID authority 112 using the authentication object 118 of first communication device 104, the second communication device 108 may contact the trusted caller ID authority 112 over a network 124, such as a data network, or via SMS messaging see col. 8, line51 – col. 9, line 3; the second communication device 108 sends a request for validation 718 of the first communication device 104 to trusted caller ID authority 112 using the authentication object 118 of first communication device 104 – see col. 24, lines 30-44);
determining, by the computing system, whether the verification request includes information derived from the validation token (the trusted caller ID authority 112 processes the validation request 720 using the authentication object 118 and determines the registration and authentication status of the first communication device 108 – see col. 24, lines 30-44);
outputting, by the computing system and to the user device over the network, an indication of whether the verification request includes information derived from the validation token (the trusted caller ID authority 112 sends 722 validation information to the second communication device 108 – see col. 24, lines 30-44); and
Tiku discloses that the trusted caller ID authority 112 may be a central server or may be a plurality of servers provided by a plurality of trusted caller ID authorities 112 and that the first communication device 104 registers 110 with the trusted caller ID authority 112 (see col. 6, line 42-col. 7, line 15). There is an association between the trusted caller ID authority 112 and the first communication device 104. However, both the trusted caller ID authority 112 and the first communication device 104 are presented as separate components and not necessarily regarded as one system. Therefore:
Tiku does not explicitly disclose a computing system.
Tiku discloses providing the user device (“second communication device 108”) with an indication of validity (i.e., validation information including the authentication status of the first communication device 108), see col. 24, lines 30-44.
Tiku does not explicitly disclose enabling, by the computing system, the user device to determine, based on the indication, whether to establish the phone call between the user device and the computing system. Enabling and/or allowing a call is implicit after validation as it is the purpose of the invention.
However, Gray discloses a method for authenticating a call from a call originator to a call recipient wherein the call originator is a computing system (the caller 10 and server 15 are associated with an organization such as a business – see [0025]; the server 15 is connected to the organization's outgoing call paths (be they PSTN, ISDN or SIP/VoIP circuits or trunks) – see [0026]); and, enabling, by the computing system, the user device to determine, based on the indication, whether to establish the phone call between the user device and the computing system (once the customer 13 is satisfied that the agent 10 is genuine, he may speak to the agent 10 over the first (voice) link 16 – see [0056]).
Furthermore, Tiku discloses a trusted caller ID application executing on the communication devices used to register with the server, provide registration data, manage authentication objects, validate the authentication objects, and so forth (see col. 3, lines 8-16).
Gray discloses preprogramming an application on the user device 14 with the CLI of the connection 16 connected to the user's terminal 12, or it may be entered by the user when opening the application so that when requesting a PIN via the app/web page (2) the user in the message also sends the CLI that the original call 1 was received (see [0054]).
Tiku and Gray fail to disclose the method, further comprising: publishing, by a computing system and with a trusted third-party application publisher, an application; and, fail to explicitly disclose enabling, by the computing system, a user device to install the application from the trusted third-party application publisher for execution on the user device.
However, Martin discloses systems and methods for automatically authenticating a caller (see abstract) including publishing, by a computing system and with a trusted third-party application publisher, an application; enabling, by the computing system, a user device to install the application from the trusted third-party application publisher for execution on the user device (mobile device 105 may include one or more software applications, such as Caller authentication application 110; caller authentication application 110 may be downloaded onto mobile device 105 over network 108 – see [0021]; Caller authentication application 110 may be a stand-alone application on the mobile device that provides the functionality; the functionality of the caller authentication application 110 may be included as part of a larger mobile application for mobile banking, such as a mobile banking application provided by financial institution 101 and/or a third party - see [0037-39]; Caller 107 also may register the identifying information directly to financial institution 101 using one or more websites provided by, for example, financial institution 101 and/or a third party associated with financial institution 101 – see [0041]; examiner’s note: the caller authentication application 110 may be included as part of a larger mobile application for mobile banking, such as a mobile banking application provided by financial institution 101 and/or a third party; financial institution 101 is trusted because the caller has an existing association with it (e.g., financial account) and the third party is associated to the financial institution, as discussed in [0019] and [0041]).
Tiku, Gray and Martin do not disclose enabling the user device to associate the phone call with the application based on the caller identifier.
However, Hamilton discloses a system and method of verifying a caller identification utilizing a server that communicates with a computing device capable of monitoring communication networks for specific communications from an enterprise voice network (see abstract) including enabling the user device to associate the phone call with the application based on the caller identifier (an enterprise application or app installed on the user's phone receives a list of phone numbers, in some examples a spoof prevention list or contact list, from which the enterprise is capable of initiating calls; each phone number or contact in this list is added to the contacts of the user device and the contact name is set to “Unverified call” or other similar text, name, or image that would suggest to a user that the call is not coming from a known enterprise phone number; when the enterprise intends to make a phone call to the customer, a pre-call notification or alert can be sent by the portal or a server to the user device – see col. 4, line 64 – col. 5, line 29)
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 the method in Tiku to include a computing system and to enable, by the computing system, the user device to determine, based on the indication, whether to establish communication between the user device and the computing system, as taught by Gray; to include publishing, by a computing system and with a trusted third-party application publisher, an application; enabling, by the computing system, a user device to install the application from the trusted third-party application publisher for execution on the user device, as taught by Martin; and, to enable the user device to associate the phone call with the application based on the caller identifier, as taught by Hamilton. One would have been motivated to provide the called party with the assurance that it is the right caller (e.g., business) calling them, as recognized by Gray (see [0056]); to allow a customer computing device to perform a variety of tasks including storing and interacting with sensitive data, as recognized by Martin (see [0051-52]); and, because for spoofed calls to the customer, for which the caller is pretending to be the enterprise, the customer is warned that the call is an unverified call, allowing the customer to take appropriate action, as recognized by Hamilton (see col. 4, lines 51-63).
Regarding claim 2, Tiku, Gray, Martin and Hamilton disclose all the claimed subject matter recited in claim 1 above.
Furthermore, Tiku discloses the method, wherein determining whether the verification request includes information derived from the validation token includes: determining whether the verification request includes the validation token (the trusted caller ID authority 112 processes the validation request 720 using the authentication object 118 and determines the registration and authentication status of the first communication device 108 – see col. 24, lines 30-44).
Regarding claim 3, Tiku, Gray, Martin and Hamilton disclose all the claimed subject matter recited in claim 1 above.
Tiku does not explicitly disclose the method, further comprising: communicating, by the computing system and based on the determination made by the user device, with the user device.
However, Gray discloses communicating, by the computing system and based on the determination made by the user device, with the user device (once the customer 13 is satisfied that the agent 10 is genuine, he may speak to the agent 10 over the first (voice) link 16 – see [0056]).
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 the method in Tiku to communicat[e], by the computing system and based on the determination made by the user device, with the user device, as taught by Gray. One would have been motivated to provide the called party with the assurance that it is the right caller (e.g., business) calling them, as recognized by Gray (see [0056]).
Regarding claim 8, Tiku, Gray, Martin and Hamilton disclose all the claimed subject matter recited in claim 1 above.
Furthermore, Tiku discloses a trusted caller ID application executing on the communication devices used to register with the server, provide registration data, manage authentication objects, validate the authentication objects, and so forth (see col. 3, lines 8-16); the first communication device 104 initiates a call 716 to second communication device 108 and provides the second communication device 108 an authentication object 118 associated with first communication device 104 (see col. 24, lines 30-44); and the trusted caller ID authority 112 sends 722 validation information to the second communication device 108 – see col. 24, lines 30-44. Thus, it is the trusted caller ID application executing in the communication devices engaging in authentication/validation processes.
Gray teaches once the customer is satisfied that the agent is genuine, he may speak to the agent over the first (voice) link 16 – see [0056].
Tiku and Gray do not explicitly disclose enabling the application executing on the user device to determine whether to establish communication between the user device and the computing system. Enabling and/or allowing communication is implicit after validation as it is the purpose of the invention.
However, Martin discloses the method, wherein enabling the user device to determine whether to establish the phone call between the user device and the computing system includes: enabling the application executing on the user device to determine whether to establish the phone call between the user device and the computing system (the one or more network-enabled computer systems may also include one or more software applications to enable the creation and provisioning of account services to mobile device 105, such as Caller authentication application 110; in various embodiments, caller authentication application may be associated with and/or integrated into, for example, a mobile application of a financial institution – see [0012]; caller authentication application 110 may be a software application that enables mobile device 105 to transmit information to authentication processor 103, such as data transfer 106b; system 400 may enable a user of a client device to use a caller authentication application on a client device to authenticate the caller with the financial institution – see [0021-22]; Caller authentication application 110 may include a user interface module 201, a profile module 202, a telephony module 203, and a services module 204 – see [0038]; telephony module 203 may be configured to recognize when caller 107 dials the number associated with financial institution 101 and/or call center 109 from mobile phone 105, even if caller 107 has not opened the Caller authentication application 110; if telephony module 203 detects that caller 107 has dialed the number for financial institution 101, telephony module 203 may generate an alert to caller 107 on mobile device 105 and ask them to confirm the call; if caller 107 confirms, such as by entering a username, password, biometric information, or other identifying information, telephony module 203 may signal profile module 202 to transmit the identifying information to authentication processor 103 – see [0043])
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 the method in Tiku to include enabling the application executing on the user device to determine whether to establish communication between the user device and the computing system, as taught by Martin. One would have been motivated to make such a combination to provide a fast and convenient way by allowing a customer computing device to perform a variety of tasks including interacting with sensitive data, as recognized by Martin (see [0003], [0051-52]).
Regarding claim 9, Tiku, Gray, Martin and Hamilton disclose all the claimed subject matter recited in claim 1 above.
Furthermore, Tiku discloses the method, wherein the user device is a mobile phone, and wherein requesting initiation of the phone call includes: initiating a phone call to the mobile phone (first communication device 104 and second communication device 108 may be a wired communication device or a wireless communication device; wireless communication devices may include mobile phones, tablets computing devices, laptop computers (also referred to as notebook computers or simply as notebooks), handheld computer (or simply handheld), wearable computers, and the like – see col. 6, lines 2-12; the first communication device 104 initiates a call 716 to second communication device 108 and provides the second communication device 108 an authentication object 118 associated with first communication device 104 – see col. 24, lines 30-44).
Regarding claim 16, all limitations correspond to the non-transitory computer-readable media comprising instructions that, when executed, cause processing circuitry of a computing system to performing the method of claim 1. Therefore, claim 16 is being rejected on the same basis as claim 1.
Furthermore, Tiku discloses the non-transitory computer-readable media comprising instructions that, when executed, cause processing circuitry of a computing system to perform the method of claim 1 (the processes discussed herein may be implemented in hardware, software, or a combination thereof; in the context of software, the described operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations – see col. 24, lines 45-50).
Regarding claim 17, all limitations correspond to the non-transitory computer-readable media comprising instructions that, when executed, cause processing circuitry of a computing system to performing the method of claim 2. Therefore, claim 17 is being rejected on the same basis as claim 2.
Regarding claim 18, all limitations correspond to the non-transitory computer-readable media comprising instructions that, when executed, cause processing circuitry of a computing system to performing the method of claim 3. Therefore, claim 18 is being rejected on the same basis as claim 3.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Tiku et al. (US 10149156 B1), Gray et al. (US 20210044696 A1), Martin (US 20150094026 A1) and Hamilton et al. (US 11330098 B1), as applied to claim 1 above, and further in view of Shaffer et al. (US 20200259845 A1), hereinafter Shaffer.
Regarding claim 7, Tiku, Gray, Martin and Hamilton disclose all the claimed subject matter recited in claim 1 above.
Furthermore, Martin discloses the one or more network-enabled computer systems may also include one or more software applications to enable the creation and provisioning of account services to mobile device 105, such as Caller authentication application 110; in various embodiments, caller authentication application may be associated with and/or integrated into, for example, a mobile application of a financial institution (see [0012]); the caller authentication application 110 may be a software application that enables mobile device 105 to transmit information to authentication processor 103, such as data transfer 106b (see [0021-22]).
Tiku, Gray, Martin and Hamilton do not explicitly disclose the computing system is controlled by an organization, wherein the application has been developed by the organization, and wherein enabling the user device to determine that the requested communication is associated with the application includes: enabling the user device to determine that the requested communication originated from organization.
However, Shaffer discloses providing access control and identity verification for communications when receiving a communication from an entity to be verified (see abstract) including the computing system is controlled by an organization, wherein the application has been developed by the organization, and wherein enabling the user device to determine that the requested phone call is associated with the application includes: enabling the user device to determine that the requested phone call originated from organization (the AVS app/client 525, which may be downloaded/obtained (582, as shown) from the enterprise 530 – see [0098]; whether the AVS client was running on the mobile device or is invoked based on the request from the AVS Server, the AVS client exchanges messages with the AVS server, verifies that the contact was initiated by the enterprise, e.g., the bank, and provides the called party with assurance that the incoming contact is not from a hacker who spoofed the caller ID of the enterprise, e.g., the bank - see [0153-0163], FIGs. 13-14).
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 the method in Tiku to include the computing system is controlled by an organization, wherein the application has been developed by the organization, and wherein enabling the user device to determine that the requested communication is associated with the application includes: enabling the user device to determine that the requested communication originated from organization, as taught by Shaffer. One would have been motivated to make such a combination because authenticating the to-be-verified party (called party or calling party) without involving agent results in improved efficiency/productivity of the enterprise/call center, as recognized by Shaffer (see [0164]).
Claims 10, 11, 14 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Trim et al. (US 20200389552 A1), hereinafter Trim, in view of Abad et al. (US 20210067343 A1), hereinafter Abad, and Martin (US 20150094026 A1).
Regarding claim 10, Trim (FIGs. 2-3, [0042-0058]) discloses a user device (“caller device 62”, see FIG. 2) comprising processing circuitry and a storage device, wherein the processing circuitry has access to the storage device and is configured to:
;
output, by (“network 55”, see FIG. 2) to a token services system (“authorization module 70”, “contacts module 71” and “trust store 72”, see FIG. 2) accessible to the computing system (“call recipient device 60”, see FIG. 2), a request for a token (at step 300, the caller device 62 of a caller sends a registration message to the recipient device 60 of an intended call recipient with a caller ID identifier - see step 300, Fig. 3, [0047]; examiner’s note: call recipient device 60 includes an authorization module 70 configured to perform one or more of the authorization/authentication steps, a contacts module 71 configured to maintain a list of contacts and associated contact information for the call recipient including authorized callers, and trust store configured to store authentication information for use in authentication steps, as shown in FIG. 2, [0042-45]; the registration message is a request for a toke as discussed in step 301 below);
receive, (at step 301, the recipient device 60 automatically posts a reply to the registration message of step 300 with an authentication token, wherein the reply is sent to a telephone number (e.g., 976-555-1212) identified in the caller ID identifier; the term authentication token as used herein refers to data that may be utilizing to verify the caller's identity, such as a key in a public key infrastructure (PKI) process or other similar user verification data – see step 301, FIG. 3, [0048]);
send, over the network (at step 302, the caller device 62 sends the recipient device 60 a call request message bearing a source of their phone number (e.g., 976-555-1212) with the authentication token appended (e.g., “stapled”) to the call request message and the caller's choice of an identifier (e.g., 12345678) – see step 302, FIG. 3, [0050]);
enable the computing system to determine, by interacting with the token services system, that the request includes information derived from the validation token and is legitimately from the user device (at step 303, the recipient device 60 processes the call request message of step 302 by authenticating the source of the call request message, and extracting the identifier (e.g., 12345678) within the call request message – see [0051]; at step 304, the recipient device 60 inserts the validated identifier (e.g., 12345678) of step 303 into an authorized caller list (e.g., whitelist) in the trust store 72 – see [0052]; at step 305, the recipient device 60 optionally associates the caller with a matching contact in a contact list of the recipient device 60, wherein the contact list links the contact with the validated identifier (e.g., for the predetermined time period) of the caller based on the authentication of the source of the call at step 303; the recipient device 60 stores the authentication token received in the call request message in the contact list of the recipient device 60, along with the caller's bona fide telephone number(s) (e.g., 976-555-1212) and other contact information – see [0053]; see steps 303-305, FIG. 3; examiner’s note: processing the received message, by the recipient device, involves authentication of the source by matching the source phone number to the pre-shared authentication token, as discussed in [0016]); and
after enabling the computing system to determine that request includes information derived from the validation token and is legitimately from the user device, establish the phone call from the user device to the computing system (at step 306, the recipient device 60 optionally responds to the call request message of step 302 with an acknowledge message (e.g., SMS or MMS) to the caller device 62 – see [0054]; at step 307, the caller device 62 initiates a call to the recipient device 60 after a threshold event occurs, wherein the caller ID identifier of the caller device 62 is configured by the caller to match the identifier (e.g., 12345678) from the call request message of step 302 – see [0055]; at step 308, the recipient device 60 attempts to verify the caller ID identifier of the caller device 62 in response to receiving the call of step 307 – see [0056]; at step 309, if the recipient device 60 cannot verify the caller ID identifier at step 308, (e.g., the caller ID identifier does not match data for a pre-authorized caller in the authorized caller list and/or contact list) the recipient device 60 blocks the call of step 307 from completing (e.g., ringing), or allows the call to occur without validation – see [0057]; at step 310, if the recipient device 60 does verify the caller ID identifier at step 308 (e.g., the caller ID identifier does match data for a pre-authorized caller in the authorized caller list and/or contact list), the recipient device 60 completes the call of step 307 (e.g., lets the call ring through to the call recipient) – see [0058]).
Trim does not disclose the computing device, wherein the processing circuitry is further configured to install the application for execution on the computing device.
Trim does not explicitly disclose detecting an indication of input requesting initiation of a phone call from the user device to a computing system, or performing the steps of outputting (a request for a token), receiving (a token) and sending (a request to initiate a call) by a particular application executing in the user device.
However, Abad discloses a system and method to validate a communication session by exchanging a token between a customer system and a host enterprise system (see abstract), including the processing circuitry configured to: install the application for execution on the user device;
detect an indication of input requesting initiation of a phone call from the user device to a computing system; outputting token requests, receiving tokens, and sending a request to initiate a call by the application in the user device (in step 305, an application associated with an enterprise may be installed on a customer communication device; for example, a banking application may be installed to allow a customer computing device to perform a variety of banking related tasks; the application may allow the customer to retrieve or interact with sensitive data stored in an enterprise network device – see [0035]; in step 320, the application may determine the initiation of a communication session; the communication session may be initiated from inside the application; the application may be configured to send a request for a communication session to a network device – see [0038]; in step 325, the application may request and receive a session identifier, which may include a token – see [0039]; an application may request and/or receive a session token, or a session identifier, which may be received from an enterprise network device associated with the application; the application may request and/or receive a token or other session identifier based on an action detected by the customer computing device, such as an application sign on with a username and password or application access based on a confirmation of biometric security authentication – see step 405, FIG. 4, [0043]; in step 415, the application may send a request for a communication session to an enterprise network device; the request may be a request for a phone call to a particular contact that is associated with an enterprise network – see [0045]).
Thus, Trim and Abad each disclose a software component (i.e., authorization module 74 in Trim, and enterprise-associated application in Abad) to perform the tasks of requesting a token, receiving a token and sending a request to initiate a call. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the application of Abad could have been substituted for the authorization module of Trim because both the application and the authorization module serve the purpose of providing the software needed to perform the tasks above. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution. Finally, the substitution achieves the predictable result of allowing the computing devices/systems (i.e., caller and recipient) to establish and authenticate a call.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the application of Abad for the authorization module of Trim according to known methods to yield the predictable result of providing the software needed to perform the tasks above and effectively enabling communication session validation using a secure application that is associated with an enterprise, while also allowing customers to perform enterprise-related tasks and interact using sensitive information. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution.
Trim and Abad do not explicitly disclose the computing device, wherein the processing circuitry is further configured to: download, from a trusted third-party application publisher, an application.
However, Martin discloses systems and methods for automatically authenticating a caller (see abstract) including the processing circuitry is further configured to: download, from a trusted third-party application publisher, an application (mobile device 105 may include one or more software applications, such as Caller authentication application 110; caller authentication application 110 may be downloaded onto mobile device 105 over network 108 – see [0021]; Caller authentication application 110 may be a stand-alone application on the mobile device that provides the functionality; the functionality of the caller authentication application 110 may be included as part of a larger mobile application for mobile banking, such as a mobile banking application provided by financial institution 101 and/or a third party - see [0037-39]; Caller 107 also may register the identifying information directly to financial institution 101 using one or more websites provided by, for example, financial institution 101 and/or a third party associated with financial institution 101 – see [0041]; examiner’s note: the caller authentication application 110 may be included as part of a larger mobile application for mobile banking, such as a mobile banking application provided by financial institution 101 and/or a third party; financial institution 101 is trusted because the caller has an existing association with it (e.g., financial account) and the third party is associated to the financial institution, as discussed in [0019] and [0041]).
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 the method in Trim to include the processing circuitry configured to: install the application for execution on the user device; and detect an indication of input requesting initiation of a phone call from the user device to a computing system, as taught by Abad; and, the processing circuitry is further configured to: download, from a trusted third-party application publisher, an application, as taught by Martin. One would have been motivated to make such a combination to allow a customer computing device to perform a variety of tasks (e.g., banking), and to retrieve or interact with sensitive data and determine if the customer computing device is attempting to initiate a communication session with the enterprise network contact within the enterprise associated with the application, as recognized by Abad (see [0035] and [0038]); and to allow a customer computing device to perform a variety of tasks including storing and interacting with sensitive data including to contact a financial institution to request new credentials, as recognized by Martin (see [0051-52]).
Regarding claim 11, Trim, Abad and Martin disclose all the claimed subject matter recited in claim 10 above.
Furthermore, Trim discloses the user device, wherein to send a request to communicate with the computing system, the processing circuitry is further configured to: send the validation token with the request (at step 302, the caller device 62 sends the recipient device 60 a call request message bearing a source of their phone number (e.g., 976-555-1212) with the authentication token appended (e.g., “stapled”) to the call request message and the caller's choice of an identifier (e.g., 12345678) – see step 302, FIG. 3, [0050]).
Regarding claim 14, Trim, Abad and Martin disclose all the claimed subject matter recited in claim 10 above.
Trim discloses the authorization module 74 sending the validation token with the request (at step 302, the caller device 62 sends the recipient device 60 a call request message bearing a source of their phone number (e.g., 976-555-1212) with the authentication token appended (e.g., “stapled”) to the call request message and the caller's choice of an identifier (e.g., 12345678); the authorization module 74 of the caller device 62 implements step 302 – see step 302, FIG. 3, [0050]).
Trim does not disclose the computing device, wherein to send the request to communicate with the computing system, the computing device is further configured to: enable the application [to send the validation token with the request]. Examiner’s note: limitations in [italics] are considered as being taught by Trim but are included here for context.
However, Abad discloses the user device, wherein to send the request to communicate with the computing system, the user device is further configured to: enable the application [to send the validation token with the request] (the application may be configured to send a request for a communication session to a network device – see [0038]; in step 330, the application may sign the session identifier with the received authenticator and transmit the signed authenticator; for example, the application may sign a session token with a private key; based on a signed session key, the application, or another application associated with the user of the application, may receive communication session authorization data or validation data – see [0040]).
Thus, Trim and Abad each disclose a software component (i.e., authorization module 74 in Trim, and enterprise-associated application in Abad) to perform the tasks of sending a token and a request for communication. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the application of Abad could have been substituted for the authorization module of Trim because both the application and the authorization module serve the purpose of providing the software needed to perform the tasks above. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution. Finally, the substitution achieves the predictable result of allowing the computing devices/systems (i.e., caller and recipient) to establish and authenticate a communication session (e.g., a call).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the application of Abad for the authorization module of Trim according to known methods to yield the predictable result of providing the software needed to perform the tasks above and effectively enabling communication session validation using a secure application that is associated with an enterprise, while also allowing customers to perform enterprise-related tasks and interact using sensitive information. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution.
Regarding claim 15, Trim, Abad and Martin disclose all the claimed subject matter recited in claim 10 above.
Furthermore, Trim discloses the user device, wherein the user device is a mobile phone; and wherein the computing system includes another mobile phone (the recipient device 60 and the caller device 62 may be any caller ID enabled telecommunications device, such as a telephone, smartphone, tablet, personal computer, desktop computer, etc. – see [0042], FIG. 2).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DORIANNE ALVARADO DAVID whose telephone number is (571)272-4228. The examiner can normally be reached 9:00am-5:00pm 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, Philip Chea can be reached at (571) 272-3951. 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.
/DORIANNE ALVARADO DAVID/Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights