Prosecution Insights
Last updated: October 25, 2026
Application No. 18/642,676

DETECTING NUISANCE AND RESTRICTED COMMUNICATIONS VIA A COMMUNICATION PRIVILEGE CONTROL SYSTEM

Non-Final OA §103§112
Filed
Apr 22, 2024
Priority
Jun 01, 2018 — provisional 62/679,594 +3 more
Examiner
PATEL, HARESH N
Art Unit
2496
Tech Center
2400 — Computer Networks
Assignee
T-Mobile USA Inc.
OA Round
3 (Non-Final)
78%
Grant Probability
Favorable
3-4
OA Rounds
6m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 78% — above average
78%
Career Allowance Rate
651 granted / 838 resolved
+19.7% vs TC avg
Strong +21% interview lift
Without
With
+21.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 0m
Avg Prosecution
28 currently pending
Career history
874
Total Applications
across all art units

Statute-Specific Performance

§101
16.5%
-23.5% vs TC avg
§103
41.5%
+1.5% vs TC avg
§102
21.4%
-18.6% vs TC avg
§112
11.7%
-28.3% vs TC avg
Black line = Tech Center average estimate • Based on career data from 838 resolved cases

Office Action

§103 §112
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 . 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 . DETAILED ACTION Status of Claims Claims 17-36 are subject to examination. Claims 1-16 are cancelled. Specification Amendment to the specification dated 6/30/26 is acknowledged. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claims 17-36 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 17, recites the limitations, “receive, via a user interface and based on a communication integrity score being less than a predetermined integrity threshold, a message associated with a real-time communication session between a secondary account holder (SAH) device of a client account and third-party device, the message including selectable options to control the real-time communication session, wherein a third-party identifier of the third-party device is listed on one or more of the communication privilege rules, wherein the communication privilege rules comprise a list of permissible contacts, a list of impermissible contacts, or a grey-list of contacts with limited communication conditions, and wherein the communication integrity score quantifies a likelihood that the real-time communication session is a nuisance or restricted communication; transmit, via the user interface, a selection of one of the selectable options to direct the real-time communication session from the SAH device to the PAH device; and receive communication session data indicating whether to include the SAH device in or exclude the SAH device from the real-time communication session between the PAH device and the third-party device. The specification contains, Para 31, the CPC system may generate a communication integrity score that is greater than or equal to the predetermined integrity threshold. In this way, the CPC system is inferring that the real-time communication session is unlikely to be a nuisance or a restricted communication, and in doing so, the CPC system may permit the real-time communication session to continue Para 13, More specifically, a Communication Privilege Control (CPC) system is described that can monitor real time communication sessions that involve a client device associated with the client account, and another, third-party device. The real-time communication sessions may include voice communications, text communications, or a combination of both. Further, in response to detecting a nuisance concern or flagging a restricted real-time communication session, the CPC system may automatically intercept the real-time communication session and selectively terminate or re-direct the real-time communication session to a trusted device. The conditions by which a real-time communication session is automatically intercepted, selectively terminated or re-directed, may be based at least in part on the set of communication privilege rules established by a PAH of the client account or an administrator of the CPC system. In addition, the CPC system may generate notification data to alert a trusted device. The notification data may comprise an audio or text alert that describes the nuisance concern or restricted communication. Para 74 Moreover, the first predetermined integrity threshold described earlier may correspond to a threshold communication integrity score of 7, high, or red Para 75 Further, the second predetermined integrity threshold described earlier may correspond to a medium communication integrity score of 6, medium, or yellow. [0076] Para 77 For example, the CPC system 104 may receive via the user interface 314 or the input module 316, a first predetermined integrity threshold, a second predetermined integrity threshold, and a third predetermined integrity threshold, whereby the first predetermined integrity threshold is less than the second predetermined integrity threshold, and the second predetermined integrity threshold is less than the third predetermined integrity threshold. Any number of predetermined integrity thresholds are possible. Para 71: The similarity score may be alpha-numeric (i.e. 0 to 10, or A to F), descriptive (i.e. low, medium, or high), based on color, (i.e. red, yellow, or green), or any other suitable rating scale. A high similarity score (i.e. 7 to 10, high, or red) may indicate that a biometric sample likely matches a registered biometric template. Similarly, a low similarity score (i.e. 0 to 3, low, green) may indicate that a biometric sample is unlikely to match the registered biometric template. The specification does not define “predetermined integrity threshold’. As seen above, threshold communication integrity score can be 7, high, or red. However, as claimed, at the same time the “predetermined integrity threshold’ can be anything, x, y, z, etc. However, The specification does not contain session data that indicates “whether to include the SAH device in or exclude the SAH device” The amended limitations are performed by the CPC system and not the claimed PAH device. The claimed PAH receive the message, after the CPC system did it’s monitoring, and the specification does not implement that the PAH again checking of the amended limitations for the receive of the message. Claims 25 and 33 claim similar limitations as of claim 17 and hence subject to the same rejections. Claims 18-24 depend upon claim 17, claims 26-32 depend upon claim 25, claims 34-36 depend upon claim 33, and hence claims 17-36 are subject to same rejections. The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. Claims 17-36 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 17, recites the limitations, “receive, via a user interface and based on a communication integrity score being less than a predetermined integrity threshold, a message associated with a real-time communication session between a secondary account holder (SAH) device of a client account and third-party device, the message including selectable options to control the real-time communication session, wherein a third-party identifier of the third-party device is listed on one or more of the communication privilege rules, wherein the communication privilege rules comprise a list of permissible contacts, a list of impermissible contacts, or a grey-list of contacts with limited communication conditions, and wherein the communication integrity score quantifies a likelihood that the real-time communication session is a nuisance or restricted communication; transmit, via the user interface, a selection of one of the selectable options to direct the real-time communication session from the SAH device to the PAH device; and receive communication session data indicating whether to include the SAH device in or exclude the SAH device from the real-time communication session between the PAH device and the third-party device. The specification contains, Para 31, the CPC system may generate a communication integrity score that is greater than or equal to the predetermined integrity threshold. In this way, the CPC system is inferring that the real-time communication session is unlikely to be a nuisance or a restricted communication, and in doing so, the CPC system may permit the real-time communication session to continue Para 13, More specifically, a Communication Privilege Control (CPC) system is described that can monitor real time communication sessions that involve a client device associated with the client account, and another, third-party device. The real-time communication sessions may include voice communications, text communications, or a combination of both. Further, in response to detecting a nuisance concern or flagging a restricted real-time communication session, the CPC system may automatically intercept the real-time communication session and selectively terminate or re-direct the real-time communication session to a trusted device. The conditions by which a real-time communication session is automatically intercepted, selectively terminated or re-directed, may be based at least in part on the set of communication privilege rules established by a PAH of the client account or an administrator of the CPC system. In addition, the CPC system may generate notification data to alert a trusted device. The notification data may comprise an audio or text alert that describes the nuisance concern or restricted communication. Para 74 Moreover, the first predetermined integrity threshold described earlier may correspond to a threshold communication integrity score of 7, high, or red Para 75 Further, the second predetermined integrity threshold described earlier may correspond to a medium communication integrity score of 6, medium, or yellow. [0076] Para 77 For example, the CPC system 104 may receive via the user interface 314 or the input module 316, a first predetermined integrity threshold, a second predetermined integrity threshold, and a third predetermined integrity threshold, whereby the first predetermined integrity threshold is less than the second predetermined integrity threshold, and the second predetermined integrity threshold is less than the third predetermined integrity threshold. Any number of predetermined integrity thresholds are possible. Para 71: The similarity score may be alpha-numeric (i.e. 0 to 10, or A to F), descriptive (i.e. low, medium, or high), based on color, (i.e. red, yellow, or green), or any other suitable rating scale. A high similarity score (i.e. 7 to 10, high, or red) may indicate that a biometric sample likely matches a registered biometric template. Similarly, a low similarity score (i.e. 0 to 3, low, green) may indicate that a biometric sample is unlikely to match the registered biometric template. The boundaries of the functional language are unclear because the claim does not provide a discernable boundary on what performs the function, i.e. based on a communication integrity score being less than a predetermined integrity threshold. The recited function does not follow from the structure recited in the claim, so it is unclear whether the function requires some other structure or is simply a result of operating the device in a certain manner. Thus, one of ordinary skill in the art would not be able to draw a clear boundary between what is and is not covered by the claim. See MPEP 2173.05(g) for more information. Further, the predetermined integrity threshold is subject to always greater as compared to the integrity score. Even though “predetermined integrity threshold” is predetermined it does not have any predetermined value. Regardless of the communication integrity score, the predetermined integrity threshold is subject to x, y, z, or anything. The boundaries of the functional language are unclear because the claim does not provide a discernable boundary on what performs the function, i.e. whether to include or exclude the device. The recited function does not follow from the structure recited in the claim, so it is unclear whether the function requires some other structure or is simply a result of operating the device in a certain manner. Thus, one of ordinary skill in the art would not be able to draw a clear boundary between what is and is not covered by the claim. See MPEP 2173.05(g) for more information. The boundaries of the functional language are unclear because the claim does not provide a discernable boundary on what performs the function, i.e. quantifies a likelihood that the real-time communication session is a nuisance or restricted communication. The recited function does not follow from the structure recited in the claim, so it is unclear whether the function requires some other structure or is simply a result of operating the device in a certain manner. Thus, one of ordinary skill in the art would not be able to draw a clear boundary between what is and is not covered by the claim. See MPEP 2173.05(g) for more information. Claims 25 and 33 claim similar limitations as of claim 17 and hence subject to the same rejections. Claims 18-24 depend upon claim 17, claims 26-32 depend upon claim 25, claims 34-36 depend upon claim 33, and hence claims 17-36 are subject to same rejections. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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. Claim(s) 17-36 are is/are rejected under 35 U.S.C. 103 as being unpatentable over SHARPE et al., WO 2016073304 A1 in view of Ricci, US 20130023254 A1. Referring to claim 17, SHARPE discloses a primary account holder (PAH) device, A computer-implemented method comprising: one or more processors; and memory coupled to the one or more processors, the memory including one or more modules that are executable by the one or more processors to: receive, via a user interface, and based on a communication integrity score being less than a predetermined integrity threshold, wherein the communication integrity score quantifies a likelihood that the real-time communication session is a nuisance or restricted communication (note: since the message is received regardless of what the threshold is. Also, there is no step that indeed quantifies a likelihood that the real-time communication session is a nuisance or restricted communication) a message associated with a real-time communication session between a secondary account holder (SAH) device of a client account and third-party device, [101] Each workflow stage corresponds to one of the agents in the list and each workflow stage includes a condition or criteria, which when satisfied, the current workflow stage is advanced to a next workflow stage. For example, the support processing flow starts with a first workflow stage and a first communication session is established between a user device and a first agent device. During the first communication session, if a first criteria corresponding to the first workflow stage is satisfied, for example, a failure signal received from either the user device or the agent device, or a response from the user via a survey, the process advances to a second workflow stage. A second communication session is established between the user device and a second agent device of a second agent corresponding to the second workflow stage, and so on, until the user is satisfied. [0075] Based on the static user information, dynamic user information, and the user interactions at the point in time, matching engine 122 evaluates via an algorithm these user information with agent information obtained from agent profiles of the agents in the pool to derive a list of one or more agents or agent candidates. By using the dynamic user information obtained at the point in time, agents with better matched personality can be identified. In one embodiment, the interaction context object may be used to store the static and dynamic user information. The interaction context object may be passed from agent connect system 115. Matching engine 122 performs the matching based on the user information stored in the interaction context object using a set of agent matching rules and/or algorithms 124 that is specifically associated with the client. Note that agent matching system 120 may provide personalization or matching services to a variety of clients as a multi-tenant system. Each of the clients may have a different agent matching rules/algorithms describing how their customers are matched with their associated agents. The agent matching rules/algorithms of a client may be configured by an administrator of the client via a configuration interface (e.g. , graphical user interface or GUI or API maintained by agent matching 120 or server 104). The agent matching rules/algorithms of a client may be stored in a client database or client account associated with the respective client. the message including selectable options to control the real-time communication session; [0076] forward the list of agent candidates to user device 101 to be presented to the user via mobile application 111. Alternatively, agent matching system 120 may directly send the list of agent candidates to user device 101 for user selection. In response to a user selection of one of the agent candidates, agent connect system 115 communicates with routing system 118 to invoke routing system 118 to connect user device 101 with an agent device of the selected agent, in this example, agent device 102. A communication session is established between the user and the selected agent using a communication channel that the user and the selected agent both agree upon. Note: The options provided to the user is done by forwarding/message that includes selectable candidates, etc., which user can select (among the candidates) and hence the user can control which candidate the session needs to be established. transmit, via the user interface, a selection of one of the selectable options to direct the real-time communication session from the SAH device to the PAH device [00122] Agents can determine that they cannot provide service set the criterion to "fail" allowing the interaction to move to a special treatment type. When the interaction concludes, then the associated agent, user, and interaction data will be recorded as a part of interaction history. [170] At block 2305, processing logic determines a treatment type, also referred to as a treatment identifier, based on the user type using a treatment classification rule associated with the client. Based on the treatment type, a treatment profile is identified, where a treatment profile includes one or more agent attributes and their respective conditions to be satisfied. At block 2306, processing logic identifies a list of one or more agents by matching agent attributes specified in the treatment profile with corresponding ones of agent profiles of a pool of agents. These user and treatment classification rules/algorithms may be configured by an administrator of the client and stored in a client database associated with the client. ; and receive communication session data indicating whether to include the SAH device in or exclude the SAH device from the real-time communication session between the PAH device and the third-party device. [245] Thus, when the visitor activates the live connect button, the underlying code is executed and a data message is transmitted to the live connect server, which in turn routes the information to the selected specialist. That is, a specialist has to be selected before the live content is displayed. That matters in two ways: (1) in order to display a map of specialists the specific and unique geographic information for each specialist must be ascertained; (2) chat or call information must be determined and embedded in part of the live content code. [00246] In this situation, the live connect server can automatically routes the request to the selected specialist. The selected specialist can then respond to the connection request at the point in time. Alternatively, according to another embodiment, the visitor can initiate a contact request by activating the live connect button, as a general live connect button to connect with the live content owner, to communicate with a dispatcher or manager associated with that particular live content, which in turn selects and routes the contact request to a specialist who is available. In this situation, a dedicated person, such as an administrator, a manager, or a dispatch person has to be available to receive the request and determine to which of the available specialists the request should be routed. If a specialist becomes unavailable or is unwilling to accept the request, the request may be rerouted to the dedicated person, such as a dispatcher, manager, or a dedicated overflow specialist. primary agent ID identifying a primary agent and a secondary agent ID identifying a secondary agent, SHARPE does not specifically mention about, which is well-known in the art, which Ricci discloses, wherein a third-party identifier of the third-party device satisfies communication privilege rules, and wherein the communication privilege rules comprise a list of permissible contacts, a list of impermissible contacts, or a grey-list of contacts with limited communication conditions; [0055] Embodiments of software modules that may be executed by the processor 208 and stored in memory 210 are shown in FIG. 3. The different software modules may include a registration module 302, a redirection module 304, a consolidation module 306, and a user information database 308. A registration module 302 can register one or more communication devices 112, 114, and/or 116 with the home communication center 110. Thus, the registration module 302 may interface with the different communication devices 112, 114, and/or 116 to receive information about the devices and/or the users that are associated with those devices. The registration module 302 may also determine contact addresses, such as phone numbers, information about how the devices communicate, user names, passwords, and/or other information needed to conduct communications with the devices 112, 114, and/or 116. In embodiments, the registration module 302 may also mine data sources, such as social media (e.g., LinkedIn, Twitter, Facebook, etc.), to determine further information about the users. The registration module 302 may also integrate these communication or social media accounts within the home communication center 110. Registration module 302 can store this information in the database 308. Further, a user(s) may communicate with the registration module 302 to provide information through a user interface; the information may be associated with devices and/or accounts to be or that are registered with the home communication center 110. [0057] An example rule used by the redirection module 304 may be that every cellular call is sent to the DECT phones 116. Thus, any person, having a cell phone 114 and registered with the registration module 302, may have all their cellular phones redirected to the home phone 116. This redirection enables the users to use the home phone 116, which may be more comfortable than the cellular phone 114, for answering cellular telephone calls while they are at home. Further, the redirection module 304 may have more complex rules, such as, determining the time of day and whether home telephone calls should be routed to cellular telephones, which may not be at the residence or location of the home communication center 110 at the present time. [0084] In embodiments, using the provided information, the redirection module 304 can associate the rule with one or more of the device(s), user(s), and/or account(s), in step 808. The association ensures that when a communication is received for the device(s), user(s), and/or account(s) the rule will be followed. To associate a rule, a database structure may be created that stores a pointer to the rule with the identifiers for the device(s), user(s), and/or account(s). After the association is made and the rule stored in database 308, the redirection module 304 may then engage the rule, in step 810. Engaging the rule means the rule is activated and will be followed when the redirection rule applies to a communication(s) or a call(s). 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 invention disclosed by SHARPE to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing communication privilege rules. The rules would enable deciding and forwarding calls to desired entities, para 84 Referring to claims 25, the method claim is rejected for the same reasons as the claim 17 device claim. Referring to claims 18, 26, SHARPE discloses the claimed limitations as rejected above. SHARPE also discloses, transmit a client input of trust parameters for selection of a trusted device from a plurality of trusted devices, and devices, wherein, the wherein the selectable options include one selectable option to re-direct the real-time communication from the SAH device to a trusted device of the plurality of trusted device, based at least in part on the trust parameters. [0076] Agent connect system 115 may forward the list of agent candidates to user device 101 to be presented to the user via mobile application 111. Alternatively, agent matching system 120 may directly send the list of agent candidates to user device 101 for user selection. In response to a user selection of one of the agent candidates, agent connect system 115 communicates with routing system 118 to invoke routing system 118 to connect user device 101 with an agent device of the selected agent, in this example, agent device 102. A communication session is established between the user and the selected agent using a communication channel that the user and the selected agent both agree upon [170] At block 2305, processing logic determines a treatment type, also referred to as a treatment identifier, based on the user type using a treatment classification rule associated with the client. Based on the treatment type, a treatment profile is identified, where a treatment profile includes one or more agent attributes and their respective conditions to be satisfied. At block 2306, processing logic identifies a list of one or more agents by matching agent attributes specified in the treatment profile with corresponding ones of agent profiles of a pool of agents. These user and treatment classification rules/algorithms may be configured by an administrator of the client and stored in a client database associated with the client. Referring to claims 19, 27, 20, 28, SHARPE discloses the claimed limitations as rejected above. SHARPE also discloses wherein the trust parameters include one or more of a first geolocation of the SAH device, a second geolocation of the trusted device, a time of day, a day of week, or the third-party identifier. [0076] Agent connect system 115 may forward the list of agent candidates to user device 101 to be presented to the user via mobile application 111. Alternatively, agent matching system 120 may directly send the list of agent candidates to user device 101 for user selection. In response to a user selection of one of the agent candidates, agent connect system 115 communicates with routing system 118 to invoke routing system 118 to connect user device 101 with an agent device of the selected agent, in this example, agent device 102. A communication session is established between the user and the selected agent using a communication channel that the user and the selected agent both agree upon wherein to receive receiving the message associated with the real-time communication session is based at least in part on a first geolocation of the SAH device being within a predetermined distance of a second geolocation of the PAH device. [170] At block 2305, processing logic determines a treatment type, also referred to as a treatment identifier, based on the user type using a treatment classification rule associated with the client. Based on the treatment type, a treatment profile is identified, where a treatment profile includes one or more agent attributes and their respective conditions to be satisfied. At block 2306, processing logic identifies a list of one or more agents by matching agent attributes specified in the treatment profile with corresponding ones of agent profiles of a pool of agents. These user and treatment classification rules/algorithms may be configured by an administrator of the client and stored in a client database associated with the client. ; and receive communication session data that automatically initiates the real-time communication session between the PAH device and the third-party device. [245] Thus, when the visitor activates the live connect button, the underlying code is executed and a data message is transmitted to the live connect server, which in turn routes the information to the selected specialist. That is, a specialist has to be selected before the live content is displayed. That matters in two ways: (1) in order to display a map of specialists the specific and unique geographic information for each specialist must be ascertained; (2) chat or call information must be determined and embedded in part of the live content code. [00246] In this situation, the live connect server can automatically routes the request to the selected specialist. The selected specialist can then respond to the connection request at the point in time. Alternatively, according to another embodiment, the visitor can initiate a contact request by activating the live connect button, as a general live connect button to connect with the live content owner, to communicate with a dispatcher or manager associated with that particular live content, which in turn selects and routes the contact request to a specialist who is available. In this situation, a dedicated person, such as an administrator, a manager, or a dispatch person has to be available to receive the request and determine to which of the available specialists the request should be routed. If a specialist becomes unavailable or is unwilling to accept the request, the request may be rerouted to the dedicated person, such as a dispatcher, manager, or a dedicated overflow specialist. Referring to claims 21, 29, SHARPE discloses, a first option to permit the real-time communication session to continue, a second option to terminate, the real-time communication session, a third option to direct the real-time communication session from the SAH device to a trusted device, and a fourth option to direct the real-time communication session from the SAH device to the PAH device. [00225] At transaction 3804, the message with link or control is transmitted to user device 101. The link is a part of a click-to-chat or click-to-call functionality, which when activated, causes user device 101 to access a predetermined URL of a Web page. The user can then request to connect with an agent for chat or voice call. Assuming the user of user device 101 interacts with the link, a request to connect with an agent is received by agent connect system 115 via transaction 3805. At block 3806, a device ID of user device 101 is determined based on the request and a lookup operation is performed in the message store. As described above, the link or control may encode information that can be utilized to identify certain metadata associated with a prior communication session between the user and the agent, such as a device ID of user device 101 and/or an agent ID identifying the agent. If there is a message entry matching the information extracted from the request is found, at transaction 3807, the agent is identified as a preferred agent and a communication session is established between the user and the same agent as of the prior session. 00232] an agent device of the agent to extend the session. Meanwhile, message state 3904 of the message entry is updated from a "sent" state to a "response received" state and optionally, received timestamp 3908 is also updated to reflect the time the response was received. [170] At block 2305, processing logic determines a treatment type, also referred to as a treatment identifier, based on the user type using a treatment classification rule associated with the client. Based on the treatment type, a treatment profile is identified, where a treatment profile includes one or more agent attributes and their respective conditions to be satisfied. At block 2306, processing logic identifies a list of one or more agents by matching agent attributes specified in the treatment profile with corresponding ones of agent profiles of a pool of agents. These user and treatment classification rules/algorithms may be configured by an administrator of the client and stored in a client database associated with the client. ; and receive communication session data that automatically initiates the real-time communication session between the PAH device and the third-party device. [245] Thus, when the visitor activates the live connect button, the underlying code is executed and a data message is transmitted to the live connect server, which in turn routes the information to the selected specialist. That is, a specialist has to be selected before the live content is displayed. That matters in two ways: (1) in order to display a map of specialists the specific and unique geographic information for each specialist must be ascertained; (2) chat or call information must be determined and embedded in part of the live content code. [00246] In this situation, the live connect server can automatically routes the request to the selected specialist. The selected specialist can then respond to the connection request at the point in time. Alternatively, according to another embodiment, the visitor can initiate a contact request by activating the live connect button, as a general live connect button to connect with the live content owner, to communicate with a dispatcher or manager associated with that particular live content, which in turn selects and routes the contact request to a specialist who is available. In this situation, a dedicated person, such as an administrator, a manager, or a dispatch person has to be available to receive the request and determine to which of the available specialists the request should be routed. If a specialist becomes unavailable or is unwilling to accept the request, the request may be rerouted to the dedicated person, such as a dispatcher, manager, or a dedicated overflow specialist. Referring to claims 22, 30, SHARPE discloses, receiving the message associated with the communication session between the SAH device and the third-party device is based on characteristics of the real-time communication session between the SAH device and the third-party device. [00225] At transaction 3804, the message with link or control is transmitted to user device 101. The link is a part of a click-to-chat or click-to-call functionality, which when activated, causes user device 101 to access a predetermined URL of a Web page. The user can then request to connect with an agent for chat or voice call. Assuming the user of user device 101 interacts with the link, a request to connect with an agent is received by agent connect system 115 via transaction 3805. At block 3806, a device ID of user device 101 is determined based on the request and a lookup operation is performed in the message store. As described above, the link or control may encode information that can be utilized to identify certain metadata associated with a prior communication session between the user and the agent, such as a device ID of user device 101 and/or an agent ID identifying the agent. If there is a message entry matching the information extracted from the request is found, at transaction 3807, the agent is identified as a preferred agent and a communication session is established between the user and the same agent as of the prior session. Note: A new session after prior session includes ending/terminating of the prior session. Referring to claims 23, 31, SHARPE discloses, receiving the message associated with the communication session between the SAH device and the third-party device is based on the communication privilege rules, and wherein the communication privilege rules are for the SAH device. [0075] Based on the static user information, dynamic user information, and the user interactions at the point in time, matching engine 122 evaluates via an algorithm these user information with agent information obtained from agent profiles of the agents in the pool to derive a list of one or more agents or agent candidates. By using the dynamic user information obtained at the point in time, agents with better matched personality can be identified. In one embodiment, the interaction context object may be used to store the static and dynamic user information. The interaction context object may be passed from agent connect system 115. Matching engine 122 performs the matching based on the user information stored in the interaction context object using a set of agent matching rules and/or algorithms 124 that is specifically associated with the client. Note that agent matching system 120 may provide personalization or matching services to a variety of clients as a multi-tenant system. Each of the clients may have a different agent matching rules/algorithms describing how their customers are matched with their associated agents. The agent matching rules/algorithms of a client may be configured by an administrator of the client via a configuration interface (e.g. , graphical user interface or GUI or API maintained by agent matching 120 or server 104). The agent matching rules/algorithms of a client may be stored in a client database or client account associated with the respective client. [00225] At transaction 3804, the message with link or control is transmitted to user device 101. The link is a part of a click-to-chat or click-to-call functionality, which when activated, causes user device 101 to access a predetermined URL of a Web page. The user can then request to connect with an agent for chat or voice call. Assuming the user of user device 101 interacts with the link, a request to connect with an agent is received by agent connect system 115 via transaction 3805. At block 3806, a device ID of user device 101 is determined based on the request and a lookup operation is performed in the message store. As described above, the link or control may encode information that can be utilized to identify certain metadata associated with a prior communication session between the user and the agent, such as a device ID of user device 101 and/or an agent ID identifying the agent. If there is a message entry matching the information extracted from the request is found, at transaction 3807, the agent is identified as a preferred agent and a communication session is established between the user and the same agent as of the prior session. Referring to claims 24, 32, SHARPE discloses, receiving the message associated with the communication session between the SAH device and the third-party device is based on data received from an application that is installed on the SAH device and that is configured to monitor communication sessions between the SAH device and other devices. [236] The message includes a link having information encoded therein certain metadata about a prior communication session between the agent and the user concerning a product or service provided by a product/service provider as a corporate client. At block 4002, processing logic creates a message entry in a message store for the received message. The message store includes message entries, each message entry corresponding to an outgoing message sent to a user device of a user. At block 4003, processing logic stores the message and its metadata in the newly created message entry. The metadata of the message may include information identifying a user device of a recipient and an agent who initiated the message. [00235] The predetermined time period may be specifically associated with the message or message entry. In one embodiment, some types of messages (e.g., messages of different clients) may be associated with different time periods, which may be specified in an additional field in message store 3702 (and/or specified by a corresponding agent). Alternatively, the period of time may be configured in a client database of a corresponding client. For example, some of the enterprise clients may prefer a longer or shorter period of time to allow their customers to reach the same agents. [00227] Message store 3702 includes message entries, where each message entry corresponds to a message that has been initiated by an agent and sent to a user device of a user. A message may be sent via a variety of messaging channels, such as text, SMS, email, or social media. As described above a message may further include a link that can be activated by a user. Such a link, which when activated, may cause a request to be sent back to agent connect system 115 for the purpose of reaching the same agent who initiated the message. For example, a link may include functionality of click-to-chat, click-to-call, or click-to- video, etc. [00228] When agent connect system 115 receives an outgoing message from an agent, a new message entry is created in message store 3702. The message and certain metadata of the message extracted and stored in the newly created message entry. Each message entry includes various fields to store various information of the message. Field 3901 is to store a message ID uniquely identifying the message. Field 3902 is to store a destination ID or user device ID that identifies a user device that will receive the message. The message itself may be cached in field 3903, where a message can be as simple as "thank you." State field 3904 is to store the state of the message, including amongst others, a "pending" state, a "sent" state, and a "response received" state. A "pending" state indicates that a corresponding message has been queued in message store 3702, but has not been sent. [00229] Field 3905 is to store a timestamp representing the time when the corresponding message is sent to a user device. Field 3906 is store an agent ID identifying an agent who initiated the message. Field 3907 is to store a user ID or user profile information of a user associated who had a prior communication session with the agent. Optional field 3908 is to store a timestamp representing the time a response to the message is received. [00230] When a message is received to be sent to a user device, according to one embodiment, the metadata of the message and the link embedded therein may be analyzed and certain information may be extracted and stored in a new message entry of message store 3702. For example, a link may include information encoded therein at least some of message ID 3901, user device ID 3902, message content 3903, agent ID 3906, or user ID 3907. Message state 3904 is set to a "pending" state. In one embodiment, a message processing thread or communication interface module 3701 is to periodically parse message entries of message store 3702 to identify any pending messages having a "pending" state. The message processing thread then sends the pending messages to proper destinations accordingly. The message processing thread further updates sent timestamp 3905 to store the time the message is sent and update message state from a "pending" state to a "sent" state. [00231] When a response to message is received from a user device in response to an activation of a link embedded therein, the response may include the information that has been encoded in the link. In one embodiment, communication interface module 3701 analyzes and extracts the information from the response. Based on the extracted information, agent connect module 201 performs a lookup operation in message store 3702 to identify or locate a message entry corresponding to the message. For example, agent connect module 201 may search in message store 3702 based on one or more of user device ID 3902, message content 3903, agent ID 3906, or user ID 3907. Referring to claim 33, SHARPE discloses a communication privilege control system, comprising: one or more processors; and memory coupled to the one or more processors, the memory including one or more modules that are executable by the one or more processors to: generate, based on a communication integrity score being less than a predetermined integrity threshold, wherein the communication integrity score quantifies a likelihood that the real-time communication session is a nuisance or restricted communication (note: since the message is received regardless of what the threshold is. Also, there is no step that indeed quantifies a likelihood that the real-time communication session is a nuisance or restricted communication) associated with a real-time communication session between a secondary account holder (SAH) device of a client account and third-party device, [101] Each workflow stage corresponds to one of the agents in the list and each workflow stage includes a condition or criteria, which when satisfied, the current workflow stage is advanced to a next workflow stage. For example, the support processing flow starts with a first workflow stage and a first communication session is established between a user device and a first agent device. During the first communication session, if a first criteria corresponding to the first workflow stage is satisfied, for example, a failure signal received from either the user device or the agent device, or a response from the user via a survey, the process advances to a second workflow stage. A second communication session is established between the user device and a second agent device of a second agent corresponding to the second workflow stage, and so on, until the user is satisfied. [0075] Based on the static user information, dynamic user information, and the user interactions at the point in time, matching engine 122 evaluates via an algorithm these user information with agent information obtained from agent profiles of the agents in the pool to derive a list of one or more agents or agent candidates. By using the dynamic user information obtained at the point in time, agents with better matched personality can be identified. In one embodiment, the interaction context object may be used to store the static and dynamic user information. The interaction context object may be passed from agent connect system 115. Matching engine 122 performs the matching based on the user information stored in the interaction context object using a set of agent matching rules and/or algorithms 124 that is specifically associated with the client. Note that agent matching system 120 may provide personalization or matching services to a variety of clients as a multi-tenant system. Each of the clients may have a different agent matching rules/algorithms describing how their customers are matched with their associated agents. The agent matching rules/algorithms of a client may be configured by an administrator of the client via a configuration interface (e.g. , graphical user interface or GUI or API maintained by agent matching 120 or server 104). The agent matching rules/algorithms of a client may be stored in a client database or client account associated with the respective client. [0076] Agent connect system 115 may forward the list of agent candidates to user device 101 to be presented to the user via mobile application 111. Alternatively, agent matching system 120 may directly send the list of agent candidates to user device 101 for user selection. In response to a user selection of one of the agent candidates, agent connect system 115 communicates with routing system 118 to invoke routing system 118 to connect user device 101 with an agent device of the selected agent, in this example, agent device 102. A communication session is established between the user and the selected agent using a communication channel that the user and the selected agent both agree upon. the message including selectable options to control the real-time communication session; receive a selection of one of the selectable options to re-direct the real-time communication session from the SAH device to a primary account holder (PAH) device [00122] Agents can determine that they cannot provide service set the criterion to "fail" allowing the interaction to move to a special treatment type. When the interaction concludes, then the associated agent, user, and interaction data will be recorded as a part of interaction history. [170] At block 2305, processing logic determines a treatment type, also referred to as a treatment identifier, based on the user type using a treatment classification rule associated with the client. Based on the treatment type, a treatment profile is identified, where a treatment profile includes one or more agent attributes and their respective conditions to be satisfied. At block 2306, processing logic identifies a list of one or more agents by matching agent attributes specified in the treatment profile with corresponding ones of agent profiles of a pool of agents. These user and treatment classification rules/algorithms may be configured by an administrator of the client and stored in a client database associated with the client. ; and generate communication session data that automatically initiates the real- time communication session between the PAH device and the third-party device. [245] Thus, when the visitor activates the live connect button, the underlying code is executed and a data message is transmitted to the live connect server, which in turn routes the information to the selected specialist. That is, a specialist has to be selected before the live content is displayed. That matters in two ways: (1) in order to display a map of specialists the specific and unique geographic information for each specialist must be ascertained; (2) chat or call information must be determined and embedded in part of the live content code. [00246] In this situation, the live connect server can automatically routes the request to the selected specialist. The selected specialist can then respond to the connection request at the point in time. Alternatively, according to another embodiment, the visitor can initiate a contact request by activating the live connect button, as a general live connect button to connect with the live content owner, to communicate with a dispatcher or manager associated with that particular live content, which in turn selects and routes the contact request to a specialist who is available. In this situation, a dedicated person, such as an administrator, a manager, or a dispatch person has to be available to receive the request and determine to which of the available specialists the request should be routed. If a specialist becomes unavailable or is unwilling to accept the request, the request may be rerouted to the dedicated person, such as a dispatcher, manager, or a dedicated overflow specialist. primary agent ID identifying a primary agent and a secondary agent ID identifying a secondary agent, SHARPE does not specifically mention about, which is well-known in the art, which Ricci discloses, wherein a third-party identifier of the third-party device is listed on the communication privilege rule, and wherein the communication privilege rules comprise a list of permissible contacts, a list of impermissible contacts, or a grey-list of contacts with limited communication conditions; [0055] Embodiments of software modules that may be executed by the processor 208 and stored in memory 210 are shown in FIG. 3. The different software modules may include a registration module 302, a redirection module 304, a consolidation module 306, and a user information database 308. A registration module 302 can register one or more communication devices 112, 114, and/or 116 with the home communication center 110. Thus, the registration module 302 may interface with the different communication devices 112, 114, and/or 116 to receive information about the devices and/or the users that are associated with those devices. The registration module 302 may also determine contact addresses, such as phone numbers, information about how the devices communicate, user names, passwords, and/or other information needed to conduct communications with the devices 112, 114, and/or 116. In embodiments, the registration module 302 may also mine data sources, such as social media (e.g., LinkedIn, Twitter, Facebook, etc.), to determine further information about the users. The registration module 302 may also integrate these communication or social media accounts within the home communication center 110. Registration module 302 can store this information in the database 308. Further, a user(s) may communicate with the registration module 302 to provide information through a user interface; the information may be associated with devices and/or accounts to be or that are registered with the home communication center 110. [0057] An example rule used by the redirection module 304 may be that every cellular call is sent to the DECT phones 116. Thus, any person, having a cell phone 114 and registered with the registration module 302, may have all their cellular phones redirected to the home phone 116. This redirection enables the users to use the home phone 116, which may be more comfortable than the cellular phone 114, for answering cellular telephone calls while they are at home. Further, the redirection module 304 may have more complex rules, such as, determining the time of day and whether home telephone calls should be routed to cellular telephones, which may not be at the residence or location of the home communication center 110 at the present time. [0084] In embodiments, using the provided information, the redirection module 304 can associate the rule with one or more of the device(s), user(s), and/or account(s), in step 808. The association ensures that when a communication is received for the device(s), user(s), and/or account(s) the rule will be followed. To associate a rule, a database structure may be created that stores a pointer to the rule with the identifiers for the device(s), user(s), and/or account(s). After the association is made and the rule stored in database 308, the redirection module 304 may then engage the rule, in step 810. Engaging the rule means the rule is activated and will be followed when the redirection rule applies to a communication(s) or a call(s). 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 invention disclosed by SHARPE to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing communication privilege rules. The rules would enable deciding and forwarding calls to desired entities, para 84 Referring to claims 34, SHARPE discloses the claimed limitations as rejected above. SHARPE also discloses, wherein the one or more modules are further executable by the one or more processors to: receive, from the PAH device, trust parameters for selection of a trusted device from a plurality of trusted devices, wherein the selectable options include one selectable option to re-direct the real- time communication from the SAH device to a trusted device of the plurality of trusted device, based at least in part on the trust parameters. [0076] Agent connect system 115 may forward the list of agent candidates to user device 101 to be presented to the user via mobile application 111. Alternatively, agent matching system 120 may directly send the list of agent candidates to user device 101 for user selection. In response to a user selection of one of the agent candidates, agent connect system 115 communicates with routing system 118 to invoke routing system 118 to connect user device 101 with an agent device of the selected agent, in this example, agent device 102. A communication session is established between the user and the selected agent using a communication channel that the user and the selected agent both agree upon [170] At block 2305, processing logic determines a treatment type, also referred to as a treatment identifier, based on the user type using a treatment classification rule associated with the client. Based on the treatment type, a treatment profile is identified, where a treatment profile includes one or more agent attributes and their respective conditions to be satisfied. At block 2306, processing logic identifies a list of one or more agents by matching agent attributes specified in the treatment profile with corresponding ones of agent profiles of a pool of agents. These user and treatment classification rules/algorithms may be configured by an administrator of the client and stored in a client database associated with the client. Referring to claim 35, SHARPE discloses the claimed limitations as rejected above. SHARPE also discloses, wherein the one or more modules are further executable by the one or more processors to: determine that a first geolocation of the SAH device is within a predetermined distance of a second geolocation of the PAH device ( [0076] Agent connect system 115 may forward the list of agent candidates to user device 101 to be presented to the user via mobile application 111. Alternatively, agent matching system 120 may directly send the list of agent candidates to user device 101 for user selection. In response to a user selection of one of the agent candidates, agent connect system 115 communicates with routing system 118 to invoke routing system 118 to connect user device 101 with an agent device of the selected agent, in this example, agent device 102. A communication session is established between the user and the selected agent using a communication channel that the user and the selected agent both agree upon wherein to receive receiving the message associated with the real-time communication session is based wherein generating the message associated with the real-time communication session is based at least in part on the first geolocation of the SAH device being within the predetermined distance of a second geolocation of the PAH device ( [170] At block 2305, processing logic determines a treatment type, also referred to as a treatment identifier, based on the user type using a treatment classification rule associated with the client. Based on the treatment type, a treatment profile is identified, where a treatment profile includes one or more agent attributes and their respective conditions to be satisfied. At block 2306, processing logic identifies a list of one or more agents by matching agent attributes specified in the treatment profile with corresponding ones of agent profiles of a pool of agents. These user and treatment classification rules/algorithms may be configured by an administrator of the client and stored in a client database associated with the client. [245] Thus, when the visitor activates the live connect button, the underlying code is executed and a data message is transmitted to the live connect server, which in turn routes the information to the selected specialist. That is, a specialist has to be selected before the live content is displayed. That matters in two ways: (1) in order to display a map of specialists the specific and unique geographic information for each specialist must be ascertained; (2) chat or call information must be determined and embedded in part of the live content code. [00246] In this situation, the live connect server can automatically routes the request to the selected specialist. The selected specialist can then respond to the connection request at the point in time. Alternatively, according to another embodiment, the visitor can initiate a contact request by activating the live connect button, as a general live connect button to connect with the live content owner, to communicate with a dispatcher or manager associated with that particular live content, which in turn selects and routes the contact request to a specialist who is available. In this situation, a dedicated person, such as an administrator, a manager, or a dispatch person has to be available to receive the request and determine to which of the available specialists the request should be routed. If a specialist becomes unavailable or is unwilling to accept the request, the request may be rerouted to the dedicated person, such as a dispatcher, manager, or a dedicated overflow specialist. Referring to claim 36, SHARPE discloses, wherein the selectable options to control the real-time communication session comprise a first option to permit the real-time communication session to continue, a second option to terminate the real-time communication session, a third option to re-direct the real-time communication session from the SAH device to a trusted device, and a fourth option to re-direct the real- time communication session from the SAH device to the PAH device. [00225] At transaction 3804, the message with link or control is transmitted to user device 101. The link is a part of a click-to-chat or click-to-call functionality, which when activated, causes user device 101 to access a predetermined URL of a Web page. The user can then request to connect with an agent for chat or voice call. Assuming the user of user device 101 interacts with the link, a request to connect with an agent is received by agent connect system 115 via transaction 3805. At block 3806, a device ID of user device 101 is determined based on the request and a lookup operation is performed in the message store. As described above, the link or control may encode information that can be utilized to identify certain metadata associated with a prior communication session between the user and the agent, such as a device ID of user device 101 and/or an agent ID identifying the agent. If there is a message entry matching the information extracted from the request is found, at transaction 3807, the agent is identified as a preferred agent and a communication session is established between the user and the same agent as of the prior session. 00232] an agent device of the agent to extend the session. Meanwhile, message state 3904 of the message entry is updated from a "sent" state to a "response received" state and optionally, received timestamp 3908 is also updated to reflect the time the response was received. [170] At block 2305, processing logic determines a treatment type, also referred to as a treatment identifier, based on the user type using a treatment classification rule associated with the client. Based on the treatment type, a treatment profile is identified, where a treatment profile includes one or more agent attributes and their respective conditions to be satisfied. At block 2306, processing logic identifies a list of one or more agents by matching agent attributes specified in the treatment profile with corresponding ones of agent profiles of a pool of agents. These user and treatment classification rules/algorithms may be configured by an administrator of the client and stored in a client database associated with the client. ; and receive communication session data that automatically initiates the real-time communication session between the PAH device and the third-party device. [245] Thus, when the visitor activates the live connect button, the underlying code is executed and a data message is transmitted to the live connect server, which in turn routes the information to the selected specialist. That is, a specialist has to be selected before the live content is displayed. That matters in two ways: (1) in order to display a map of specialists the specific and unique geographic information for each specialist must be ascertained; (2) chat or call information must be determined and embedded in part of the live content code. [00246] In this situation, the live connect server can automatically routes the request to the selected specialist. The selected specialist can then respond to the connection request at the point in time. Alternatively, according to another embodiment, the visitor can initiate a contact request by activating the live connect button, as a general live connect button to connect with the live content owner, to communicate with a dispatcher or manager associated with that particular live content, which in turn selects and routes the contact request to a specialist who is available. In this situation, a dedicated person, such as an administrator, a manager, or a dispatch person has to be available to receive the request and determine to which of the available specialists the request should be routed. If a specialist becomes unavailable or is unwilling to accept the request, the request may be rerouted to the dedicated person, such as a dispatcher, manager, or a dedicated overflow specialist. Response to Arguments Remarks/Arguments filed 6/30/26, pages 10-15 have been fully considered but they are not persuasive. Therefore, rejection of claims 12-17 is maintained. Regarding the remarks, Sharpe's scoring framework calculates the commercial value of a customer and does not describe a communication integrity score; the claimed score is not limited to any particular value. However, the message is received regardless of what the score value or the threshold. As claimed, the message is received and the score cannot do anything different. Even if it does, the claimed score is subject to a lower value. There is no verification step for verifying that the score is less. Regarding the limitations, wherein the communication integrity score quantifies a likelihood that the real-time communication session is a nuisance or restricted communication., no where in the claim, “quantifies a likelihood that the real-time communication session is a nuisance or restricted communication” ever happens. Applicant is suggested to amend the claims such that “quantifies a likelihood that the real-time communication session is a nuisance or restricted communication”, would indeed happen. Conclusion Pertinent prior art: Pachouri et al., US 20170186008 A1 [0021] In some embodiments, the primary account holder-defined monetary restriction (and/or other transaction parameters) for each secondary account can be determined from or is otherwise associated with a password (referred to herein as a secondary password), such as a one-time password (OTP). In particular, restriction specification and/or secondary password generation can be initiated by the primary account holder via a network node that is outside of the secure payments network, using a client application or web portal executing on a consumer electronic device, prior to initiation of a transaction with a merchant terminal by the secondary account holder. For example, the primary account holder may specify transaction restrictions including a monetary amount, particular location(s), particular merchant(s), particular number of uses, duration/times of use, and/or other transaction restrictions for each secondary account via the client application or web portal, and the account issuer (or associated third-party server) may generate a secondary password that is associated with those specific transaction details that were defined by the primary account holder. The secondary password may be transmitted to the device associated with the primary account holder and/or to a device associated with a secondary account holder via the client application or web portal or e-mail, thereby avoiding network-based delivery costs (e.g., SMS messaging charges). Upon subsequent receipt of the secondary password from a merchant terminal, the issuer/associated third-party server may recognize the secondary account identifier as being associated with the primary account, and may authorize the transaction with the merchant terminal for an amount that does not exceed the monetary restriction (and/or other transaction restrictions) associated with the secondary password. In some embodiments, a third-party server may perform operations for distinguishing between the primary and secondary account(s) such that the usage and/or existence of the secondary account(s) may be transparent to the issuer. [0044] FIG. 4B is a flowchart illustrating operations that may be performed by a consumer device (such as the primary account device 101 and/or the secondary account payments device 105 of FIG. 1A) to initiate association of one or more transaction restrictions with a secondary account according to some embodiments. Referring now to FIG. 4B, a monetary restriction for a secondary account is received via a user interface of the consumer device at block 400. In some embodiments, a user of the consumer device (for example, a primary account holder) may login to a web portal linked to the issuer using an identifier and password corresponding to the primary account, may select the secondary account by providing an account identification number or other account identifier corresponding to the secondary account, and may enter a desired monetary restriction to which transactions initiated by the secondary account/secondary account holder are to be limited. In other embodiments, the user of the consumer device may download a client application (or “app”) that is configured for communication with the issuer and is associated with the primary account, and may select the secondary account and the desired monetary restriction via the app. In some embodiments, the user may also specify additional transaction restrictions (for example, particular geographic locations, particular merchants, particular number of uses, and/or particular durations/times of use) via the user interface of the consumer device. Any inquiry concerning this communication or earlier communications from the examiner should be directed to HARESH PATEL whose telephone number is (571)272-3973. The examiner can normally be reached on M-F 9-5:30. 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, Jorge L. Ortiz-Criado, can be reached at (571) 272-7624. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /HARESH N PATEL/Primary Examiner, Art Unit 2496
Read full office action

Prosecution Timeline

Show 6 earlier events
Mar 31, 2026
Final Rejection mailed — §103, §112
May 22, 2026
Interview Requested
Jun 04, 2026
Applicant Interview (Telephonic)
Jun 09, 2026
Examiner Interview Summary
Jun 30, 2026
Response after Non-Final Action
Aug 24, 2026
Request for Continued Examination
Aug 29, 2026
Response after Non-Final Action
Oct 01, 2026
Non-Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12756564
Reputation Tokens based on User Activities in Virtual Worlds
3y 9m to grant Granted Oct 06, 2026
Patent 12739244
LIGHTWEIGHT AUTHENTICATION PROTOCOL USING DEVICE TOKENS
3y 8m to grant Granted Sep 15, 2026
Patent 12732813
COMMUNICATION METHOD, APPARATUS, AND SYSTEM
2y 6m to grant Granted Sep 08, 2026
Patent 12724867
Cross-Device Authentication Using Target Authentication Manner Method and Electronic Device
3y 0m to grant Granted Sep 01, 2026
Patent 12726818
INFORMATION PROCESSING APPARATUS, METHOD OF CONTROLLING INFORMATION PROCESSING APPARATUS, AND STORAGE MEDIUM
2y 11m to grant Granted Sep 01, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
78%
Grant Probability
99%
With Interview (+21.2%)
3y 0m (~6m remaining)
Median Time to Grant
High
PTA Risk
Based on 838 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month