Prosecution Insights
Last updated: April 19, 2026
Application No. 18/348,062

SYSTEMS AND METHODS FOR PROVIDING NUMBERS-AS-A-PLATFORM SERVICES

Final Rejection §102§103
Filed
Jul 06, 2023
Examiner
BARRY, JUSTIN ARTHUR
Art Unit
2643
Tech Center
2600 — Communications
Assignee
Verizon Patent and Licensing Inc.
OA Round
2 (Final)
67%
Grant Probability
Favorable
3-4
OA Rounds
3y 3m
To Grant
99%
With Interview

Examiner Intelligence

Grants 67% — above average
67%
Career Allow Rate
8 granted / 12 resolved
+4.7% vs TC avg
Strong +40% interview lift
Without
With
+40.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 3m
Avg Prosecution
52 currently pending
Career history
64
Total Applications
across all art units

Statute-Specific Performance

§101
2.2%
-37.8% vs TC avg
§103
58.7%
+18.7% vs TC avg
§102
22.2%
-17.8% vs TC avg
§112
15.2%
-24.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 12 resolved cases

Office Action

§102 §103
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Response to Amendment The Amendment filed December 17, 2025 has been entered. Claims 1-20 are pending in the application. Applicant has submitted amendments to the claims along with other remarks. Applicant has requested reconsideration of the objection to the term “utilize” because “the term is fully supported by the specification.” Remarks at 10-11. The objection is overcome on this basis. Applicant has submitted new drawings that have overcome the objection. Applicant’s amendments regarding typographical errors have overcome the objection. Claims 1-20 are still rejected by prior art references, refer to the following rejection for details. Response to Arguments Applicant’s arguments and amendments, see pp. 10-14 of the response, filed December 17, 2025, with respect to the rejection(s) of claim(s) 1-20 under § 102 have been fully considered but are not persuasive. Please see the rejection for details. Regarding claim 1, Applicant alleges that Wolthuis does not teach “identifying, by the device, one or more of the multiple clients based on the ranked list. Further, Applicant alleges that Wolthuis does not teach “providing, by the device, the notification to the one or more of the multiple clients” in combination with the “identifying” clause. Lastly, Applicant alleges that [0030] does not disclose any “workers,” which were relied upon to teach the “one or more of the multiple clients.” Wolthuis relates to a “work distribution service” embodied in a “multi-tenant platform [providing] a work distribution service for a plurality of external systems [through] a RESTful work item API call.” Wolthuis, Abstract. Workers are assigned to work items “based on: the priority of the work item, the workflow information, and worker state”. Wolthuis, Abstract. Regarding the clause “identifying, by the device, one or more of the multiple clients based on the ranked list,” the BRI of “one or more multiple clients” includes external system 770, worker endpoints 772, among other elements taught by Wolthuis (e.g., workers, worker API, worker API module). Applicant has not explicitly limited the BRI of “one or more multiple clients” to a scope that would exclude any of these elements. As a non-specific example and at a high level of generality, Wolthuis teaches: “assign[ing] a worker to the first work item based on: the priority of the first work item,” in claim 1. That is, claim 1 of Wolthuis, at a high level of generality, teaches “identifying, by the device, one or more of the multiple clients based on the ranked list.” Further, and more specifically, Wolthuis teaches: [0046] Workers may be similarly prioritized. In one example, a worker can be assigned to two groups for example a sales group and a support group. If the worker specialized in sales, then the worker is prioritized for sales related work requests, but if no sales work items are queued, then the worker can serve support related work requests. Such worker prioritization can improve utilization of worker resources. In one other example, prioritizing work can include prioritizing worker selection based on idle time of a worker, which functions to more evenly distribute work across workers. Workers may be part of external system 770 or work distribution system 700, which may be any type of system that pairs a pool of workers with worker requests ([0063]). These sections at least teach the recited, “identifying, by the device, one or more of the multiple clients based on the ranked list.” Regarding the clause “providing, by the device, the notification to the one or more of the multiple clients,” Wolthuis discloses communication through the external system or a communications platform in [0042]. With regard to these elements, Wolthuis teaches: [0030] The work item associated communication may additionally be incoming communication, established communication, or an outbound communication. [0030] When used in combination with a communication platform (e.g., 107 of FIG. 1), a work item can include a reference to a voice call, a video call, screensharing session, text message, media message, or any suitable type of media. Lastly, Applicant states that [0030] does not disclose any “workers,” which were relied upon to teach the “one or more of the multiple clients.” This narrow lens into one paragraph of Wolthuis is not proper because many of the terms used in [0030] are defined elsewhere in Wolthuis. For example, Wolthuis teaches: [0030] The work item API 150 of the preferred embodiment functions as an interface through which work items can be added to the system. A work item (e.g., the work item 111 of FIG. 1) is preferably a task or a request made on behalf of an account to be enqueued and serviced by a worker. [0030] also references the worker API 160 and the communication platform (e.g., 107), which further reference the “workers” (e.g., [0042] In response to a request, the work item is created and added to a general or specified collection. A work item similar to a worker resource can include a unique identifier. [0043] As mentioned above, the work distribution platform may be implemented in combination with a communication platform (e.g., 107) and/or any suitable type of secondary platform . . . When distributed to a worker, the communication session is preferably transitioned to the worker.) Therefore, the rejection is maintained. Claim Rejections - 35 USC § 102 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claims 1-12, 14-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by U.S. Publication No. 2015/0264180 (hereinafter “Wolthuis”) Regarding claim 1, Wolthuis teaches: receiving, by a device, an identifier for a user of multiple clients ([0027] A worker endpoint 140 can include a worker application endpoint 141 and a media endpoint 142. A worker application endpoint is preferably a client application accessible by the system 100 over an internet protocol channel. [0028] The worker endpoint 140 can additionally include a media endpoint 142 such as a voice endpoint (e.g., a PSTN phone number or SIP address), video endpoint, screen-sharing endpoint, messaging endpoint (e.g., endpoint for SMS, MMS, or IP-based messaging), and/or any suitable type of media endpoint.); receiving, by the device, configurations for multiple applications via an agnostic interface and software development kits ([0026] The worker application programming interface (API) 160 of a preferred embodiment functions to enable a worker endpoint to interface with the system.; [0027] For example, a worker application SDK could be provided to facilitate easier integration with the system.); associating, by the device, the identifier with the multiple clients and the multiple applications ([0027] The worker application endpoint 141 can be a desktop application, a mobile application, an embedded application of a device (e.g., a wearable computer), or any suitable form of an application.); configuring, by the device and based on the configurations, the multiple applications for utilization of one or more services associated with the identifier to generate multiple configured applications ([0027] The worker application endpoint 141 may be configured by an account holder to provide any suitable functionality.; [0033] A workflow instruction document (e.g., 121 of FIG. 1) is preferably a script, an application file/object, set of configurations, or any suitable customizable set of instructions. [0070] An account holder (e.g., an external system having an account, or a user of the external system having a sub-account) configures and manages the work distribution primitives by using at least one of the worker API module 702, the Work Item API Module 704, and the Workflow API Module 707. In the example embodiment, an account holder configures work collections by using the workflow API Module 707. In some embodiments, an account holder configures work collections by using an API for the work collections. [0082] The usage conditions are particular patterns in usage data (e.g., account configuration or API call history). [0089] Configuration and state of each worker is managed by the worker state module 703 in association with a corresponding account or sub-account. In the example embodiment, the external system uses the Worker API to configure worker attributes for each worker. [0122] In the example embodiment, each work collection can be configured to specify operational logic.); receiving, by the device, respective activity times associated with the multiple clients’ utilizations of the multiple applications ([0046] One type of heuristic is distribution prioritization, which may be based on origin of a work item (e.g., who is the work item for), the history of the work item (e.g., how long has the work item been queued, how many times has it been queued), [0082], [0103] The Work Item Age indicates an amount of time the work item has resided in the work collection identified by the Work Collection Identifier [0155] As shown in FIG. 12C, if over five minutes has elapsed, then the priority of the work item is increased by 10, and a check of the work item's wait time is scheduled in another five minutes. [0177] In an implementation, the worker state for each worker indicates an idle time for the worker, and the work distribution module 708 applies the distribution function to available workers based on idle time of each of the workers, such that a worker with a longer idle time is identified as an assignment candidate before other workers with shorter idle times.); receiving, by the device, a notification destined for the identifier ([0030] a work item can include a reference to a voice call, a video call, screensharing session, text message, media message, or any suitable type of media.); utilizing, by the device, an activity service, of the one or more services, to rank the multiple clients based on the respective activity times and to generate a ranked list ([0032] The collection is more preferably ordered in response to prioritization specified by the work distribution processing engine 120. [0033] The work distribution processing engine 120 of the preferred embodiment functions to process queued/added work items in coordination with the worker resources. The work distribution processing engine 120 can be triggered in response to work item activity (e.g., a new work item), worker activity (e.g., change in worker status), or collection status (e.g., volume of work items), and/or any suitable event. [0046] One type of heuristic is distribution prioritization, which may be based on origin of a work item (e.g., who is the work item for), the history of the work item (e.g., how long has the work item been queued, how many times has it been queued), worker properties, or any suitable type of prioritization. In an example of user-prioritization, work items can be prioritized based on the user profiles associated with the work items.); identifying, by the device, one or more of the multiple clients based on the ranked list ([0046] Workers may be similarly prioritized. In one example, a worker can be assigned to two groups for example a sales group and a support group. If the worker specialized in sales, then the worker is prioritized for sales related work requests, but if no sales work items are queued, then the worker can serve support related work requests. Such worker prioritization can improve utilization of worker resources. In one other example, prioritizing work can include prioritizing worker selection based on idle time of a worker, which functions to more evenly distribute work across workers.); and providing, by the device, the notification to the one or more of the multiple clients ([0030] When used in combination with a communication platform (e.g., 107 of FIG. 1), a work item can include a reference to a voice call, a video call, screensharing session, text message, media message, or any suitable type of media.). Regarding claim 2, Wolthuis teaches: wherein the identifier is a telephone number associated with the user ([0028] The worker endpoint 140 can additionally include a media endpoint 142 such as a voice endpoint (e.g., a PSTN phone number or SIP address); [0031]). Regarding claim 3, Wolthuis teaches: wherein the agnostic interface is an agnostic application programming interface capable of communicating with the multiple applications ([0037] Block S100, which includes collecting worker status, functions to monitor and manage workers' capability to fulfill a work item. Block S100 preferably includes receiving worker status update through a worker API (e.g., 160). The worker API is preferably a REST API but may alternatively be SOAP or any suitable type of API.). Regarding claim 4, Wolthuis teaches: wherein the software development kits enable the multiple applications to provide the configurations via the agnostic interface ([0027] In one variation, the worker application endpoint 141 may be provided by the system entity in part or whole. For example, a worker application SDK could be provided to facilitate easier integration with the system.; [0039] In the case of using the method in combination with a communications platform, the worker endpoint can be provided through a client communication SDK. The client communication SDK may be used in enabling voice, video, messaging, and/or other forms of communication through the SDK. The SDK could be extended to provide worker registration and status update functions.). Regarding claim 5, Wolthuis teaches: providing the one or more services for the multiple configured applications ([0034] A method for a work distribution service of a preferred embodiment can include collecting worker status S100, adding work items to a collection S200, prioritizing work items in the collection through developer directives S300, and distributing a work item to a worker according to priority of the work item in the collection S400.). Regarding claim 6, Wolthuis teaches: wherein the one or more services include one or more of: the activity service, an authentication service, a real-time relay service, a contact management service, a push notification service, or a register service ([0037] In one variation, the realtime communication channel is used for pushing work items requests to a worker application endpoint in addition to collecting worker status. Additionally, worker status can be collected through secondary channels. For example, presence information can be obtained from an outside source. Outside sources are preferably associated with a worker through some unique identifier.). Regarding claim 7, Wolthuis teaches: receiving an incoming call destined for the identifier ([0050] For example, an incoming phone call to a customer service center triggers a creation and queuing of a work item, the caller is directed to a wait-state application to handle the call session while waiting for assignment to a worker. When a worker is selected, the work item and related metadata may be delivered to a worker application endpoint 141, and the caller is redirected and connected with a media endpoint 142 of the worker.); utilizing the activity service to identify a most recently utilized client of the multiple clients ([0050] Block S400, which includes distributing a work item to a worker according to priority of the work item in the collection functions to deliver a work item to a worker endpoint. In response to the prioritizing of work items, a pairing of a work item and a worker is preferably selected. The selection is preferably based upon the defined logic of selecting a targeted worker. When a pairing of a work item and worker is established, the work item is delivered to the worker endpoint. As mentioned above, a worker application endpoint (e.g., 141) can have an established realtime communication channel to the work distribution system 100. The work item (e.g., 111) and the associated properties are preferably pushed or otherwise transmitted to the worker application endpoint (e.g., 141). [0047] Expanding targets can be customized to a particular user profile associated with the work item to direct the work item to an individually assigned worker. See also [0073] of Agarwal); and providing the incoming call to the most recently utilized client ([0050] When the work item is delivered to the worker application endpoint 141, a communication can be established with the destination endpoint. Alternatively, both the worker and the destination can be called and merged.). Regarding claim 8, Wolthuis teaches: receive, by a device, an identifier for a user of multiple clients ([0027] A worker endpoint 140 can include a worker application endpoint 141 and a media endpoint 142. A worker application endpoint is preferably a client application accessible by the system 100 over an internet protocol channel. [0028] The worker endpoint 140 can additionally include a media endpoint 142 such as a voice endpoint (e.g., a PSTN phone number or SIP address), video endpoint, screen-sharing endpoint, messaging endpoint (e.g., endpoint for SMS, MMS, or IP-based messaging), and/or any suitable type of media endpoint.); receive, by the device, configurations for multiple applications via an agnostic interface and software development kits ([0026] The worker application programming interface (API) 160 of a preferred embodiment functions to enable a worker endpoint to interface with the system.; [0027] For example, a worker application SDK could be provided to facilitate easier integration with the system.); associating, by the device, the identifier with the multiple clients and the multiple applications ([0027] The worker application endpoint 141 can be a desktop application, a mobile application, an embedded application of a device (e.g., a wearable computer), or any suitable form of an application.); configure, by the device and based on the configurations, the multiple applications for utilization of one or more services associated with the identifier to generate multiple configured applications ([0027] The worker application endpoint 141 may be configured by an account holder to provide any suitable functionality.; [0033] A workflow instruction document (e.g., 121 of FIG. 1) is preferably a script, an application file/object, set of configurations, or any suitable customizable set of instructions. [0070] An account holder (e.g., an external system having an account, or a user of the external system having a sub-account) configures and manages the work distribution primitives by using at least one of the worker API module 702, the Work Item API Module 704, and the Workflow API Module 707. In the example embodiment, an account holder configures work collections by using the workflow API Module 707. In some embodiments, an account holder configures work collections by using an API for the work collections. [0082] The usage conditions are particular patterns in usage data (e.g., account configuration or API call history). [0089] Configuration and state of each worker is managed by the worker state module 703 in association with a corresponding account or sub-account. In the example embodiment, the external system uses the Worker API to configure worker attributes for each worker. [0122] In the example embodiment, each work collection can be configured to specify operational logic.); receive, by the device, respective activity times associated with the multiple clients’ utilizations of the multiple applications ([0046] One type of heuristic is distribution prioritization, which may be based on origin of a work item (e.g., who is the work item for), the history of the work item (e.g., how long has the work item been queued, how many times has it been queued), [0082], [0103] The Work Item Age indicates an amount of time the work item has resided in the work collection identified by the Work Collection Identifier [0155] As shown in FIG. 12C, if over five minutes has elapsed, then the priority of the work item is increased by 10, and a check of the work item's wait time is scheduled in another five minutes. [0177] In an implementation, the worker state for each worker indicates an idle time for the worker, and the work distribution module 708 applies the distribution function to available workers based on idle time of each of the workers, such that a worker with a longer idle time is identified as an assignment candidate before other workers with shorter idle times.); receive, by the device, a notification destined for the identifier ([0030] a work item can include a reference to a voice call, a video call, screensharing session, text message, media message, or any suitable type of media.); utilize, by the device, an activity service, of the one or more services, to rank the multiple clients based on the respective activity times and to generate a ranked list ([0032] The collection is more preferably ordered in response to prioritization specified by the work distribution processing engine 120. [0033] The work distribution processing engine 120 of the preferred embodiment functions to process queued/added work items in coordination with the worker resources. The work distribution processing engine 120 can be triggered in response to work item activity (e.g., a new work item), worker activity (e.g., change in worker status), or collection status (e.g., volume of work items), and/or any suitable event. [0046] One type of heuristic is distribution prioritization, which may be based on origin of a work item (e.g., who is the work item for), the history of the work item (e.g., how long has the work item been queued, how many times has it been queued), worker properties, or any suitable type of prioritization. In an example of user-prioritization, work items can be prioritized based on the user profiles associated with the work items.); identify, by the device, one or more of the multiple clients based on the ranked list ([0046] Workers may be similarly prioritized. In one example, a worker can be assigned to two groups for example a sales group and a support group. If the worker specialized in sales, then the worker is prioritized for sales related work requests, but if no sales work items are queued, then the worker can serve support related work requests. Such worker prioritization can improve utilization of worker resources. In one other example, prioritizing work can include prioritizing worker selection based on idle time of a worker, which functions to more evenly distribute work across workers.); and provide, by the device, the notification to the one or more of the multiple clients ([0030] When used in combination with a communication platform (e.g., 107 of FIG. 1), a work item can include a reference to a voice call, a video call, screensharing session, text message, media message, or any suitable type of media.). Regarding claim 9, Wolthuis teaches: receive, from a client of the multiple clients, a call destined for a called party ([0050] For example, an incoming phone call to a customer service center triggers a creation and queuing of a work item, the caller is directed to a wait-state application to handle the call session while waiting for assignment to a worker. When a worker is selected, the work item and related metadata may be delivered to a worker application endpoint 141, and the caller is redirected and connected with a media endpoint 142 of the worker.); utilize the activity service to retrieve activity information associated with the client ([0043] The properties of the call can be packaged into a work item and added to a collection (e.g., by using the work item API 150). [0046]); include the activity information and the identifier with the call ([0031] In one implementation, a work item (e.g., the work item 111 of FIG. 1) includes a set of attributes. At least some of the attributes may be defined for the particular use-case. The attributes can be characterized in a JSON object, and XML document, or any suitable data object descriptor. For example, work item can include any metadata related to the communication such as an originating phone number or endpoint address. The work item can include a reference to external media such as a current communication session (e.g., phone call or video chat session), an image, user-account profile, or any suitable type of media.); and provide the call, with the activity information and the identifier, to the called party ([0050] When the work item is delivered to the worker application endpoint 141, a communication can be established with the destination endpoint. Alternatively, both the worker and the destination can be called and merged.). Regarding claim 10, Wolthuis teaches: wherein the client is utilizing an application and the activity information includes information associated with the e application ([0033] the work distribution processing engine preferably includes a component to process a workflow instruction document. A workflow instruction document (e.g., 121 of FIG. 1) is preferably a script, an application file/object, set of configurations, or any suitable customizable set of instructions.). Regarding claim 11, Wolthuis teaches: wherein the client is utilizing a video game application or a social media application and the activity information includes information associated with either the video game application or the social media application ([0024] The system and/or a second communication platform may communicate over a variety of different communication protocols and mediums such as voice (e.g., PSTN, SIP, WebRTC, etc.), video, screen sharing, text messaging (e.g., SMS, proprietary IP based messaging, etc.), media messaging (e.g., MMS, proprietary IP based messaging, etc.)). Regarding claim 12, Wolthuis teaches: utilize the activity service to retrieve activity information associated with a client of the multiple clients, wherein the activity information includes information associated with a first application ([0033] the work distribution processing engine preferably includes a component to process a workflow instruction document. A workflow instruction document (e.g., 121 of FIG. 1) is preferably a script, an application file/object, set of configurations, or any suitable customizable set of instructions.); and provide the activity information to a second application for display ([0027] For example, user interfaces may be displayed allowing a worker to login, set status, display information relating to a current or past work item, append meta-data to the work item (to be saved internally or synchronized with the system), stream realtime worker attributes (e.g., geolocation information) or provide any suitable customized functionality.). Regarding claim 14, wherein the client is a most recently utilized client of the multiple clients ([0050] Block S400, which includes distributing a work item to a worker according to priority of the work item in the collection functions to deliver a work item to a worker endpoint. In response to the prioritizing of work items, a pairing of a work item and a worker is preferably selected. The selection is preferably based upon the defined logic of selecting a targeted worker. When a pairing of a work item and worker is established, the work item is delivered to the worker endpoint. As mentioned above, a worker application endpoint (e.g., 141) can have an established realtime communication channel to the work distribution system 100. The work item (e.g., 111) and the associated properties are preferably pushed or otherwise transmitted to the worker application endpoint (e.g., 141). [0047] Expanding targets can be customized to a particular user profile associated with the work item to direct the work item to an individually assigned worker. See also [0073] of Agarwal). Regarding claim 15, receive, by a device, an identifier for a user of multiple clients ([0027] A worker endpoint 140 can include a worker application endpoint 141 and a media endpoint 142. A worker application endpoint is preferably a client application accessible by the system 100 over an internet protocol channel. [0028] The worker endpoint 140 can additionally include a media endpoint 142 such as a voice endpoint (e.g., a PSTN phone number or SIP address), video endpoint, screen-sharing endpoint, messaging endpoint (e.g., endpoint for SMS, MMS, or IP-based messaging), and/or any suitable type of media endpoint.); receive, by the device, configurations for multiple applications via an agnostic interface and software development kits ([0026] The worker application programming interface (API) 160 of a preferred embodiment functions to enable a worker endpoint to interface with the system.; [0027] For example, a worker application SDK could be provided to facilitate easier integration with the system.), wherein the agnostic interface is an agnostic application programming interface capable of communicating with the multiple applications ([0037] Block S100, which includes collecting worker status, functions to monitor and manage workers' capability to fulfill a work item. Block S100 preferably includes receiving worker status update through a worker API (e.g., 160). The worker API is preferably a REST API but may alternatively be SOAP or any suitable type of API.); associate, by the device, the identifier with the multiple clients and the multiple applications ([0027] The worker application endpoint 141 can be a desktop application, a mobile application, an embedded application of a device (e.g., a wearable computer), or any suitable form of an application.); configure, by the device and based on the configurations, the multiple applications for utilization of one or more services associated with the identifier to generate multiple configured applications ([0027] The worker application endpoint 141 may be configured by an account holder to provide any suitable functionality.; [0033] A workflow instruction document (e.g., 121 of FIG. 1) is preferably a script, an application file/object, set of configurations, or any suitable customizable set of instructions. [0070] An account holder (e.g., an external system having an account, or a user of the external system having a sub-account) configures and manages the work distribution primitives by using at least one of the worker API module 702, the Work Item API Module 704, and the Workflow API Module 707. In the example embodiment, an account holder configures work collections by using the workflow API Module 707. In some embodiments, an account holder configures work collections by using an API for the work collections. [0082] The usage conditions are particular patterns in usage data (e.g., account configuration or API call history). [0089] Configuration and state of each worker is managed by the worker state module 703 in association with a corresponding account or sub-account. In the example embodiment, the external system uses the Worker API to configure worker attributes for each worker. [0122] In the example embodiment, each work collection can be configured to specify operational logic.); receive, by the device, respective activity times associated with the multiple clients’ utilizations of the multiple applications ([0046] One type of heuristic is distribution prioritization, which may be based on origin of a work item (e.g., who is the work item for), the history of the work item (e.g., how long has the work item been queued, how many times has it been queued), [0082], [0103] The Work Item Age indicates an amount of time the work item has resided in the work collection identified by the Work Collection Identifier [0155] As shown in FIG. 12C, if over five minutes has elapsed, then the priority of the work item is increased by 10, and a check of the work item's wait time is scheduled in another five minutes. [0177] In an implementation, the worker state for each worker indicates an idle time for the worker, and the work distribution module 708 applies the distribution function to available workers based on idle time of each of the workers, such that a worker with a longer idle time is identified as an assignment candidate before other workers with shorter idle times.); receive, by the device, a notification destined for the identifier ([0030] a work item can include a reference to a voice call, a video call, screensharing session, text message, media message, or any suitable type of media.); utilize, by the device, an activity service, of the one or more services, to rank the multiple clients based on the respective activity times and to generate a ranked list ([0032] The collection is more preferably ordered in response to prioritization specified by the work distribution processing engine 120. [0033] The work distribution processing engine 120 of the preferred embodiment functions to process queued/added work items in coordination with the worker resources. The work distribution processing engine 120 can be triggered in response to work item activity (e.g., a new work item), worker activity (e.g., change in worker status), or collection status (e.g., volume of work items), and/or any suitable event. [0046] One type of heuristic is distribution prioritization, which may be based on origin of a work item (e.g., who is the work item for), the history of the work item (e.g., how long has the work item been queued, how many times has it been queued), worker properties, or any suitable type of prioritization. In an example of user-prioritization, work items can be prioritized based on the user profiles associated with the work items.); identify, by the device, one or more of the multiple clients based on the ranked list ([0046] Workers may be similarly prioritized. In one example, a worker can be assigned to two groups for example a sales group and a support group. If the worker specialized in sales, then the worker is prioritized for sales related work requests, but if no sales work items are queued, then the worker can serve support related work requests. Such worker prioritization can improve utilization of worker resources. In one other example, prioritizing work can include prioritizing worker selection based on idle time of a worker, which functions to more evenly distribute work across workers.); and provide, by the device, the notification to the one or more of the multiple clients ([0030] When used in combination with a communication platform (e.g., 107 of FIG. 1), a work item can include a reference to a voice call, a video call, screensharing session, text message, media message, or any suitable type of media.). Regarding claim 16, Wolthuis teaches: provide the one or more services for the multiple configured applications ([0030] When used in combination with a communication platform (e.g., 107 of FIG. 1), a work item can include a reference to a voice call, a video call, screensharing session, text message, media message, or any suitable type of media.). Regarding claim 17, Wolthuis teaches: receive an incoming call destined for the identifier ([0050] For example, an incoming phone call to a customer service center triggers a creation and queuing of a work item, the caller is directed to a wait-state application to handle the call session while waiting for assignment to a worker. When a worker is selected, the work item and related metadata may be delivered to a worker application endpoint 141, and the caller is redirected and connected with a media endpoint 142 of the worker.); utilize the activity service to identify a most recently utilized client of the multiple clients ([0050] Block S400, which includes distributing a work item to a worker according to priority of the work item in the collection functions to deliver a work item to a worker endpoint. In response to the prioritizing of work items, a pairing of a work item and a worker is preferably selected. The selection is preferably based upon the defined logic of selecting a targeted worker. When a pairing of a work item and worker is established, the work item is delivered to the worker endpoint. As mentioned above, a worker application endpoint (e.g., 141) can have an established realtime communication channel to the work distribution system 100. The work item (e.g., 111) and the associated properties are preferably pushed or otherwise transmitted to the worker application endpoint (e.g., 141). [0047] Expanding targets can be customized to a particular user profile associated with the work item to direct the work item to an individually assigned worker. See also [0073] of Agarwal); and provide the incoming call to the most recently utilized client ([0050] When the work item is delivered to the worker application endpoint 141, a communication can be established with the destination endpoint. Alternatively, both the worker and the destination can be called and merged.). Regarding claim 18, Wolthuis teaches: receive, from a client of the multiple clients, a call destined for a called party ([0050] For example, an incoming phone call to a customer service center triggers a creation and queuing of a work item, the caller is directed to a wait-state application to handle the call session while waiting for assignment to a worker. When a worker is selected, the work item and related metadata may be delivered to a worker application endpoint 141, and the caller is redirected and connected with a media endpoint 142 of the worker.); utilize the activity service to retrieve activity information associated with the client ([0043] The properties of the call can be packaged into a work item and added to a collection (e.g., by using the work item API 150). [0046]); include the activity information and the identifier with the call ([0031] In one implementation, a work item (e.g., the work item 111 of FIG. 1) includes a set of attributes. At least some of the attributes may be defined for the particular use-case. The attributes can be characterized in a JSON object, and XML document, or any suitable data object descriptor. For example, work item can include any metadata related to the communication such as an originating phone number or endpoint address. The work item can include a reference to external media such as a current communication session (e.g., phone call or video chat session), an image, user-account profile, or any suitable type of media.); and provide the call, with the activity information and the identifier, to the called party ([0050] When the work item is delivered to the worker application endpoint 141, a communication can be established with the destination endpoint. Alternatively, both the worker and the destination can be called and merged.). Regarding claim 19, Wolthuis teaches: wherein the client is utilizing a particular application and the activity information includes information associated with the particular application([0033] the work distribution processing engine preferably includes a component to process a workflow instruction document. A workflow instruction document (e.g., 121 of FIG. 1) is preferably a script, an application file/object, set of configurations, or any suitable customizable set of instructions.). Regarding claim 20, Wolthuis teaches: utilize the activity service to retrieve activity information associated with a client of the multiple clients ([0043] The properties of the call can be packaged into a work item and added to a collection (e.g., by using the work item API 150). [0046]), wherein the activity information includes information associated with a first application ([0031] In one implementation, a work item (e.g., the work item 111 of FIG. 1) includes a set of attributes. At least some of the attributes may be defined for the particular use-case. The attributes can be characterized in a JSON object, and XML document, or any suitable data object descriptor. For example, work item can include any metadata related to the communication such as an originating phone number or endpoint address. The work item can include a reference to external media such as a current communication session (e.g., phone call or video chat session), an image, user-account profile, or any suitable type of media.); and provide the activity information to a second application for display ([0050] When the work item is delivered to the worker application endpoint 141, a communication can be established with the destination endpoint. Alternatively, both the worker and the destination can be called and merged.). Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Wolthuis in view of U.S. Publication No. 2022/0150210 (hereinafter “Agarwal”) Regarding claim 13, Wolthuis teaches employing various types of media ([0030-31] “a work item can include a reference to a voice call, a video call, screensharing session, text message, media message, or any suitable type of media . . . The work item can include a reference to external media such as a current communication session (e.g., phone call or video chat session), an image, user-account profile, or any suitable type of media.”). Wolthuis does not explicitly teach: wherein the first application is a video game application and the second application is a social media application. However, in the same field of endeavor, Agarwal teaches: wherein the first application is a video game application and the second application is a social media application ([0133] The applications 916 include built-in applications 938 and/or third-party applications 940. Examples of representative built-in applications 938 may include, but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, and/or a game application [0142]). Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Wolthuis to include the feature of built in applications that are games or social media and a combination of Wolthuis with Agarwal renders the claim prima facie obvious within the described scope of the prior art and any indicated differences within the level of one of ordinary skill in the art (e.g., telecommunications engineer) according to a combination of known prior art elements with known methods to yield predictable results. MPEP 2143(I)(A) (e.g., having different types of software applications for the first and second applications). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. U.S. Publication No. 2021/0344575 (O’Shaughnessy) related to a message routing optimization system U.S. Publication No. 2021/0321004 (Plappert) related to an audio broadcast system with cloud communications platform and related methods U.S. Publication No. 2014/0105372 (Nowack) related to a system and method for routing communications THIS ACTION IS MADE FINAL. 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 JUSTIN BARRY whose telephone number is (571)272-0201. The examiner can normally be reached 8:00am EST to 5:00pm EST. 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, Jinsong HU can be reached at (571) 272-3965. 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. /JAB/ Examiner, Art Unit 2643 /JINSONG HU/ Supervisory Patent Examiner, Art Unit 2643
Read full office action

Prosecution Timeline

Jul 06, 2023
Application Filed
Sep 22, 2025
Non-Final Rejection — §102, §103
Nov 26, 2025
Interview Requested
Dec 10, 2025
Examiner Interview Summary
Dec 10, 2025
Applicant Interview (Telephonic)
Dec 17, 2025
Response Filed
Mar 05, 2026
Final Rejection — §102, §103
Apr 08, 2026
Interview Requested

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12598469
DYNAMIC IDENTIFICATION GENERATION FOR TELECOMMUNICATIONS NETWORK USER EQUIPMENT
2y 5m to grant Granted Apr 07, 2026
Patent 12578947
METHODS AND APPARATUS FOR TRANSPARENT SWITCHING OF SERVICE FUNCTION IDENTIFIERS
2y 5m to grant Granted Mar 17, 2026
Patent 12556942
SYSTEM AND METHOD FOR SCALABLE MACHINE LEARNING MODELING
2y 5m to grant Granted Feb 17, 2026
Patent 12549952
SUBSCRIBER IDENTITY MODULE (SIM) CARD FEATURE-BASED NON-FUNGIBLE TOKEN (NFT)
2y 5m to grant Granted Feb 10, 2026
Patent 12532183
APPLYING SUBSCRIBER-ID BASED SECURITY, EQUIPMENT-ID BASED SECURITY, AND/OR NETWORK SLICE-ID BASED SECURITY WITH USER-ID AND SYSLOG MESSAGES IN MOBILE NETWORKS
2y 5m to grant Granted Jan 20, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
67%
Grant Probability
99%
With Interview (+40.0%)
3y 3m
Median Time to Grant
Moderate
PTA Risk
Based on 12 resolved cases by this examiner. Grant probability derived from career allow 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