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 April 28, 2026 has been entered. Claims 1 and 3-21 are pending in the application. Claims 1 and 3-21 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-13 of the response, filed April 28, 2026, with respect to the rejection(s) of claim(s) 1 and 3-21 under § 102 have been fully considered and are persuasive. However, upon further consideration for the amendments, a new ground(s) of rejection is made in view of new reference, please see the rejection for details.
Claim Rejections - 35 USC § 112
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 1 and 3-21 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 1 recites the limitation "a device” and “multiple user devices.” It is unclear whether the device can be one of the multiple user devices. Correction is required.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3-12, and 14-21 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Publication No. 2015/0264180 (hereinafter “Wolthuis”) in view of U.S. Publication No. 2005/0117525 (hereinafter “Poustchi”).
Regarding claim 1, Wolthuis teaches: receiving, by a device, a unique identifier for a user of multiple user devices, wherein the unique identifier is associated with the user ([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 ([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 unique identifier with the multiple user devices 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 unique 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, 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.); identifying, by the device, one or more of the multiple user devices based on a ranked list of the multiple user devices ([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.).
Wothuis does not explicitly teach: providing, by the device, the notification to the one or more of the multiple user devices identified based on the ranked list of the multiple user devices.
However, in the same field of endeavor, Poustchi teaches: providing, by the device, the notification to the one or more of the multiple user devices identified based on the ranked list of the multiple user devices (Abstract - The peer receives existence notifications from other peers and may use them to create a list of the peers on the network, which may be sorted by the unique identifiers of each peer. A prospective network address is selected, e.g. based on the ordinal position of the peer within the sorted list. . . . Each peer may periodically notify the other peers of its network address).
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 Wothuis to include the feature of providing a notification based on a ranked list of devices and a combination of Wolthuis with Poustchi 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., providing a notification based on a ranked list of devices).
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 unique 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.) wherein the unique 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]); utilizing an activity service to identify a most recently utilized user device of the multiple user devices ([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 utilize user device ([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 a unique identifier for a user of multiple user devices, wherein the unique identifier is associated with the user ([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 configurations for multiple applications ([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.); associate the unique identifier with the multiple user devices 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, based on the configurations, the multiple applications for utilization of one or more services associated with the unique 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 a notification destined for the unique 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.); identify one or more of the multiple user devices based on a ranked list of the multiple user devices ([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.).
Wothuis does not explicitly teach: providing, by the device, the notification to the one or more of the multiple user devices identified based on the ranked list of the multiple user devices.
However, in the same field of endeavor, Poustchi teaches: providing, by the device, the notification to the one or more of the multiple user devices identified based on the ranked list of the multiple user devices (Abstract - The peer receives existence notifications from other peers and may use them to create a list of the peers on the network, which may be sorted by the unique identifiers of each peer. A prospective network address is selected, e.g. based on the ordinal position of the peer within the sorted list. . . . Each peer may periodically notify the other peers of its network address).
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 Wothuis to include the feature of providing a notification based on a ranked list of devices and a combination of Wolthuis with Poustchi 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., providing a notification based on a ranked list of devices).
Regarding claim 9, Wolthuis teaches: the configurations for the multiple applications are received 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.); 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.); 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.); receive, from a user device of the multiple user devices, 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 user device ([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 unique 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 p provide the call, with the activity information and the unique identifier, to the called party, wherein the unique identifier is a telephone number associated with the user ([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 user device is utilizing an application and the activity information includes information associated with the 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 user device 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 an activity service to retrieve activity information associated with a user device of the multiple user devices, 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, Wolthuis teaches: wherein the user device is a most recently utilize user device of the multiple user devices ([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, Wolthuis teaches: receive a unique identifier for a user of multiple user devices, wherein the unique identifier is associated with the user ([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 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 the unique identifier with the multiple user devices 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, based on the configurations, the multiple applications for utilization of one or more services associated with the unique 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 respective activity times associated with utilizations of the multiple applications by the multiple user devices ([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 a notification destined for the unique 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 an activity service, of the one or more services, to rank the multiple user devices 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 one or more of the multiple user devices 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.).
Wothuis does not explicitly teach: provide the notification to the one or more of the multiple user devices.
However, in the same field of endeavor, Poustchi teaches: provide the notification to the one or more of the multiple user devices (Abstract - The peer receives existence notifications from other peers and may use them to create a list of the peers on the network, which may be sorted by the unique identifiers of each peer. A prospective network address is selected, e.g. based on the ordinal position of the peer within the sorted list. . . . Each peer may periodically notify the other peers of its network address).
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 Wothuis to include the feature of providing a notification based on a ranked list of devices and a combination of Wolthuis with Poustchi 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., providing a notification based on a ranked list of devices).
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: eceive an incoming call destined for the unique identifier, wherein the unique identifier is a telephone number associated with the user ([0026], [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 user device of the multiple user devices ([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 user device ([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 user device of the multiple user devices, 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 user device ([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 user device 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 user device of the multiple user devices ([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.).
Regarding claim 21, Wolthuis teaches: wherein the configurations for the multiple applications are received 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.), and wherein the method further comprises: receiving, by the device, respective activity times associated with utilizations of the multiple applications by the multiple user devices ([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.); and utilizing, by the device, an activity service, of the one or more services, to rank the multiple user devices based on the respective activity times and to generate the 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.).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Wolthuis and Poustchi 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.”). The combination of Wolthuis and Poustchi 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 the combination of Walthuis and Poustchi to include the feature of built in applications that are games or social media and the combination of Walthuis and Poustchi 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
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
Prosecution Insights