DETAILED ACTION
1. This office action is in response to applicant’s communication filed on 08/03/2026 in response to PTO Office Action mailed on 05/06/2026. The Applicant’s remarks and amendments to the claims and/or the specification were considered with the results as follows.
2. In response to the last Office Action, claim 16 is amended. Claim 1 is canceled. As a result, claims 2-21 are pending in this office action.
3. The 35 USC 101 rejections have been withdrawn due to amendment filed on 08/03/2026.
Response to Arguments
4. Applicant’s arguments with respect to art-based rejection have been considered but are not persuasive and the details are as follow:
Applicant’s argument with respect to prior-art rejection with respect to claims 2, 9 and 16 stated as “Acharya discloses no message queue, no ordered subscription, and no key-value No SQL system of record…The claimed cloud based key-value NoSQL database that serves as a system of record is neither disclosed nor suggested by the cited art and in fact the Office Action identifies only the VPBX database of Vendrow as the alleged key-value NoSQL store…”.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The Acharya reference is relied upon for teaching the presence-management and publish-notification framework and publish-notification framework. In particular, the Acharya reference discloses an event publish-notification infrastructure that collects and disseminates presence information including status updates (See Acharya, para. [0029] and para. [0033]. The Acharya reference further discloses that agents 102a, 102b and 102c are capable of publishing their status, such as “busy” or “free”, to presence server 158 (See Acharya, para. [0038]) and that the presence servers maintain and provide agent availability information for routing decisions (See Acharya, para. [0040]-para. [0045] and Figures 2 and 3). The Vendrow reference is relied upon in combination with Acharya for the queue and stored agent-status teachings. Vendrow discloses a queue that may be implemented as first-in, first out [FIFO] data structure and further discloses maintaining queue-agent availability information for determining the availability of agents (See Vendrow, para. [0042]-para. [0044] and Figure 4). Thus, the Vendrow reference expressly teaches ordered queue processing in the same contact-center environment in which agent availability information is maintained and used to route communications. Applicant’s characterization of Vendrow as disclosing only a relational database is not consistent with Vendrow’ s disclosure. The Vendrow reference does not require the vPBX database to be implemented as an RDMS. Rather, the Vendrow reference states that the vPBX database can be implemented as a relational database management system, an object-oriented database or a plain-file system (See Vendrow, para. [0055]). Accordingly, the disclosure of an RDBMS represents one disclosed implementation and does not limit the Vendrow reference to relational storage or teach away from alternative database implementations. Moreover, the Vendrow reference discloses storing queue-agent availability information associated with the respective agent/device. Table 1 defines corresponding availability-status value, including a value of “0” when the device is not a queue agent, a value of “1” when the queue agent is offline, and a value of “2” when the queue agent is offline (See Vendrow, Table 1). Thus, the Vendrow reference stores an association between an identified agent/device and a corresponding available-status value for subsequent retrieval and use in determining agent availability. The Vendrow reference further discloses updating stored agent-status information when an agent’s status changes and sending a status-update message to devices associated with queue-agent extensions (See Vendrow, para. [0076]). The Status-update message associates the identity of the device whose status has changed with its corresponding new queue-availability value, as further illustrated by the status-message fields disclosed in Table 2. Accordingly, the Vendrow’s disclosure is not merely directed to storing inbound calls in a relational database, as asserted by Applicant, but also teaches maintaining and update the agent/device status information represented by and identifier and its associated availability-status value [e.g., key-value]. The Examiner further notes that Applicant’s argument appears to rely on implementation requirements that are not recited in the claims. Although the claims recited a “key-value NoSQL database,” the claim language does not further specify a particular internal data structure, schema, storage format, or implementation for that database. The Vendrow reference discloses maintaining stored agent/device status information in which an identified agent/device is associated with a corresponding availability-status value and further discloses updating and retrieving such status information for use by the system.
Therefore, the combination of the cited references Acharya and Vendrow discloses the claimed invention as recited in claims 2, 9 and 16.
Applicant further argues “The rejection is independent deficient as to the limitation of receiving at a user service subscribed to the queue, the presence message in order of publication. The queue of Vendrow is a first-in, first-out queue that governs the order in which inbound calls wait to be answered; it is not the publication-order delivery of presence events to be subscribed consumer as recited in the independent claims”.
In response to Applicant’s argument, the Examiner respectfully disagrees. Applicant’s argument considers Vendrow’s FIFO queue in isolation and does not address the rejection based on the combined teachings of Acharya and Vendrow. As set forth in the rejection, the Acharya reference teaches an event publish-notification infrastructure in which agent presence/status information is published to and received by presence services/clients (See Achayra, para. [0029], para. [0033], para. [0038], para.[0040]-para. [0045]). The Vendrow reference is relied upon for its teaching of queue-based FIFO queue ordering (See Vendrow, para. [0042]-para. [0044]). Thus, the rejection does not reply upon the Vendow reference as independently teaching publication and subscription of presence messages. Rather, Vendow’s FIFO ordering is applied to Acarya’s presence-message publication and receipt mechanism. Accordingly, when Vendrow’s FIFO ordering is incorporating into Acharya’s presence -message mechanism, presence messages are received in the same order in which they are placed into the queue, thereby teaching receiving, at a user service subscribed to the queue, the presence message in order of publication”, as recited in claim 2.
Applicant further argues that “The asserted reason to combine is conclusory and does not supply the articulated reasoning with rational underpinning that 35 USC 103 requires…. The proposed combination is supportable only through impermissible hindsight reconstruction using the claims as a template”.
In response to applicant’s argument that the asserted reason to combine is conclusory and lacks articulated reasoning with rational underpinning. The Examiner respectfully disagrees. The Examiner provided an articulated reason with rational underpinning for combining the teachings of Acharya and Vendrow. Specifically, as set forth in the rejection, it would been obvious to modify Acharya’s presence-message system to incorporate Vendrow’s FIFO ordering because it would provide an orderly mechanism for receiving and processing successive agent-status updates, reduce the risk that stale or out-of-order status information would control routing decisions, and enable the presence service to maintain current agent-availability information for use by other contact-center services. Thus, the rationale is not based merely on Vendrow’s disclosure that a relatively small group of agents may handle a relatively large number of user requests, nor is it based on impermissible hindsight. Rather the combination is based on the recognized benefit of maintaining the proper sequence and currency of agent-status information used for routing decisions. Accordingly, the proposed combination is supported by an articulated reason with rational underpinning that arises from the teachings and functions of the cited references, rather than from Applicant’s disclosure.
Double Patenting
5. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
6. Claims 2-21 are rejected on the ground of nonstatutory obvious double patenting over claims 1-18 of Patent No.: US 12,287,778 B1. The subject matter claimed in the instant application is disclosed in the Patent No.: US 12,287,778 B1. For example:
Patent No.: US 12,287,778 B1
Instant Application: 19/169,580
1. A system for monitoring network connectivity status of a user through a presence service, the system comprising: a processor; and a memory storage device storing instructions thereon, which, when executed by the processor, cause the system to perform operations
comprising: receiving over a network a first heartbeat message from a client application executing on a client device of a user, the first heartbeat message received as an HTTP Post request and including a user ID of the user;
determining if a hash for the user ID of the user is present in a memory cache; and if the hash for the user ID of the user is determined to not be present in the memory cache:
writing to the memory cache a hash for the user ID, the hash for the user ID having a key structured as a key-value pair and a first entry structured as a field-value pair, wherein the value of the key is the user ID and the value of the first entry is data indicating a session ID associated with the first heartbeat message and a timestamp associated with the first heartbeat message; and
updating a database to include a data record indicating that the user is online; and
writing to the memory cache a member in a first sorted set of a plurality of sorted sets, the member comprising a score derived from the timestamp associated with the first heartbeat message and a value comprising the hash for the user ID and session ID, wherein the first sorted set is selected from the plurality of sorted sets using an index derived from the first heartbeat message; wherein the plurality of sorted sets enable parallel processing to identify expired agent sessions based on the scores of the members.
9. A computer-implemented method for monitoring network connectivity status of a user through a presence service, the method comprising: receiving over a network a first heartbeat message from a client application executing on a client device of an user, the first heartbeat message received as an HTTP Post request and including a user ID of the user; determining if a hash for the user ID of the user is present in a memory cache; and if the hash for the user ID of the user is determined to not be present in the memory cache: writing to the memory cache a hash for the user ID, the hash for the user ID having a key structured as a key-value pair and a first entry structured as a key-value pair, wherein the value of the key is the user ID and the value of the first entry is data indicating a session ID associated with the first heartbeat message and a timestamp associated with the first heartbeat message; and updating a database to include a data record indicating that the user is online; and writing to the memory cache a member in a first sorted set of a plurality of sorted sets, the member comprising a score derived from the timestamp associated with the first heartbeat message and a value comprising the hash for the user ID and session ID, wherein the first sorted set is selected from the plurality of sorted sets using an index derived from the first heartbeat message; wherein the plurality of sorted sets enable parallel processing to identify expired agent sessions based on the scores of the members.
17. A system for monitoring network connectivity status of a user through a presence service, the system comprising: means for receiving over a network a first heartbeat message from a client application executing on a client device of an user, the first heartbeat message received as an HTTP Post request and including a user ID of the user; means for determining if a hash for the user ID of the user is present in a memory cache; and if the hash for the user ID of the user is determined to not be present in the memory cache: means for writing to the memory cache a hash for the user ID, the hash for the user ID having a key structured as a key-value pair and a first entry structured as a field-value pair, wherein the value of the key is the user ID and the value of the first entry is data indicating a session ID associated with the first heartbeat message and a timestamp associated with the first heartbeat message; and means for updating a database to include a data record indicating that the user is online; and means for writing to the memory cache a member in a first sorted set of a plurality of sorted sets, the member comprising a score derived from the timestamp associated with the first heartbeat message and a value comprising the hash for the user ID and session ID, wherein the first sorted set is selected from the plurality of sorted sets using an index derived from the first heartbeat message; wherein the plurality of sorted sets enable parallel processing to identify expired agent sessions based on the scores of the members.
9. A system for maintaining agent presence status in a cloud-based contact center platform, the system comprising:
at least one processor; at least one memory storage device storing instructions thereon, which, when executed by the at least one processor, caused the system to perform operations
comprising: receiving, at a presence service, a heartbeat message indicating a change in agent connectivity
status; publishing, by the presence service, a presence message to a queue of a streaming message distribution service, the presence message including at least a user ID of an agent;
receiving, at a user service subscribed to the queue, the presence message in order of publication;
processing, by the user service, the received presence message by:
accessing a cloud-based key-value NoSQL database that serves as a system of record,
updating a presence record in the database to reflect a current online/offline status of the agent; and making the updated presence record available to other services of the contact center platform for
routing decisions.
2. A method for maintaining agent presence status in a cloud-based contact center platform, comprising: receiving, at a presence service, a heartbeat message indicating a change in agent connectivity status; publishing, by the presence service, a presence message to a queue of a streaming message distribution service, the presence message including at least a user ID of an agent; receiving, at a user service subscribed to the queue, the presence message in order of publication; processing, by the user service, the received presence message by: accessing a cloud-based key-value NoSQL database that serves as a system of record,
updating a presence record in the database to reflect a current online/offline status of the agent; and making the updated presence record available to other services of the contact center platform for routing decisions.
16. A computer-readable medium storing instructions thereon, which, when executed by one or more processors, cause the one or more processors to perform operations for maintaining agent presence status in a cloud-based contact center platform, the operations comprising:
receiving, at a presence service, a heartbeat message indicating a change in agent connectivity status;
publishing, by the presence service, a presence message to a queue of a streaming message distribution service, the presence message including at least a user ID of an agent; receiving, at a user service subscribed to the queue, the presence message in order of publication;
processing, by the user service, the received presence message by:
accessing a cloud-based key-value NoSQL database that serves as a system of record,
updating a presence record in the database to reflect a current online/offline status of the agent; and
making the updated presence record available to other services of the contact center platform for routing decisions.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2, 3, 9, 10, 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Acharya (US 2012/0219144 A1) and in view of Vendrow (US 2010/0128867 A1).
Referring to claim 2, Acharya discloses a method for maintaining agent presence status in a cloud-based contact center platform (See para. [0015], para. [0029], a method for managing agent presence status in contact centers via a cloud network),
comprising: receiving, at a presence service, a heartbeat message indicating a change in agent connectivity status (See para. [0033], para. [0041] and para. [0042] and Figure 3, receiving a status message via an event publish-notification infrastructure of a presence server, the status message indicates updates of status from “free” to “busy” or vice-verse);
publishing, by the presence service, a presence message to a queue of a streaming message distribution service, the presence message including at least a user ID of an agent (See para. [0029], para. [0033] and para. [0038], the event publish-notification infrastructure collects presence information included but is not limited to a status update and/or location update of an object, note in para. [0038], each agent 102a, 102b, 102c have a capability to push their status, e.g., “busy” or “free” to presence server 158 of contact center(s) of 150, for example the presence message includes “USER A is away”);
receiving, at a user service subscribed [to the queue, the presence message] (See para. [0040] and para. [0044], receiving, at a presence client linked to presence servers in contact centers)
processing, by the user service, the received presence message by: accessing a cloud-based [system] that serves as a system of record, updating a presence record in the [system] to reflect a current online/offline status of the agent; and making the updated presence record available to other services of the contact center platform for routing decisions (See para. [0040]-para. [0045] and Figures 2 and 3, upon receipt of a call/web-chat agent [e.g., agent 152a] published an updated status to both of the presence servers 108/158, the presence server 108/158 will contain a status of agent 152a as unavailable [e.g., “busy”], thereby obviating any possibility of agent 152a receiving another incoming call/web-chat during such time, the updates of status from “free” to “busy” or vice-versa, also note in para. [0049] and Figure 4, the incoming communication is routed from a first agent of a first contact center to a second agent when a free status of the second agent is ascertained).
Acharya does not explicitly disclose receiving, at the user service, subscribed to the queue, the presence message in order of publication.
Vendrow receiving the presence message in order of publication at a user service subscribed to the queue (See para. [0042]-para.[0044] and Figure 4, maintain queue-agent available information in a queue, wherein the queue may be implemented as a first-in, first-out (FIFO) data structure and the availability/status of queue agents is maintained for determining agent availability) and processing the received presence message by accessing a cloud-based key-value NoSQL database that serves as a system of record (See para. [0050] and para. [0076] and Tables 1-2, the stored queue-agent availability information associated with respective agent/devices. Table 1 defines corresponding availability-status values, including a value of “0” when the device is not a queue agent, a value of “1” when the queue agent is offline, and a value “2” for the disclosed queue-agent status, updating the stored agent information when an agent’s status changes and transmitting a status-update message associating the identity of the device whose status changed with the corresponding new queue-availability value).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Acharya ‘s system to incorporate Vendrow’s queue-based, FIFO handing of agent-status information and its stored association between an agent/ device identifier and availability value. This would have provided an orderly mechanism for receiving and processing successive status updates, reduced the risk that stale, or out-of-order status information would control routing, and enabled the presence service to maintain a current record of each agent’s availability for use by other contact-center services. (See Vendrow’s para. [0020]). Both of the references (Vendrow and Acharya) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as maintaining agent presence status. This close relation between both references highly suggests an expectation of success.
As to claims 3, 10 and 17, Acharya discloses publishing the message to a first queue when the heartbeat message indicates the agent is busy; and publishing the message to a second queue when the heartbeat message indicates the agent is free (See para. [0029], para. [0033] and para. [0038], the event publish-notification infrastructure collects presence information included but is not limited to a status update and/or location update of an object, note in para. [0038], each agent 102a, 102b, 102c have a capability to push their status, e.g., “busy” or “free” to presence server 158 of contact center(s) of 150).
Acharya does not explicitly publish the message to a first queue indicates the agent is online and publishing the message to a second queue indicates the agent is offline.
Vendrom discloses publishing the message to a first queue indicates the agent is online and publishing the message to a second queue indicates the agent is offline (See para. [0076] and table 1).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Acharya ‘s system to include agent queues to publish and receive presence message, as taught by Vendrow. Skilled artisan would have been motivated to utilize queues to service user requests in order to facilitate a relatively small group of people to handle a relatively large number of user requests (See para. [0020]). Both of the references (Vendrow and Acharya) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as maintaining agent presence status. This close relation between both references highly suggests an expectation of success.
Referring to claims 9 and 16, Acharya discloses a system for maintaining agent presence status in a cloud-based contact center platform, the system comprising:
at least one processor (See para. [0018] and Figure 1, a computer system comprises one or more processors or processing units 16);
at least one memory storage device storing instructions there on, which, when executed by the at least one processor (See para. [0018]-para. [0021] and Figure 1, a system memory 28 caused the system to perform operations) comprising:
receiving, at a presence service, a heartbeat message indicating a change in agent connectivity status (See para. [0033], para. [0041] and para. [0042] and Figure 3, receiving a status message via an event publish-notification infrastructure of a presence server, the status message indicates updates of status from “free” to “busy” or vice-verse);
publishing, by the presence service, a presence message to a queue of a streaming message distribution service, the presence message including at least a user ID of an agent (See para. [0029], para. [0033] and para. [0038], the event publish-notification infrastructure collects presence information included but is not limited to a status update and/or location update of an object, note in para. [0038], each agent 102a, 102b, 102c have a capability to push their status, e.g., “busy” or “free” to presence server 158 of contact center(s) of 150, for example the presence message includes “USER A is away”);
receiving, at a user service subscribed […] (See para. [0040] and para. [0044], receiving, at a presence client linked to presence servers in contact centers);
processing, by the user service, the received presence message by:
accessing a cloud-based [system] that serves as a system of record, updating a presence record in the [system] to reflect current online/offline status of the agent; and making the updated presence record available to other services of the contact center platform for routing decisions (See para. [0040]-para. [0045] and Figures 2 and 3, upon receipt of a call/web-chat agent [e.g., agent 152a] published an updated status to both of the presence servers 108/158, the presence server 108/158 will contain a status of agent 152a as unavailable [e.g., “busy”], thereby obviating any possibility of agent 152a receiving another incoming call/web-chat during such time, the updates of status from “free” to “busy” or vice-versa, also note in para. [0049] and Figure 4, the incoming communication is routed from a first agent of a first contact center to a second agent when a free status of the second agent is ascertained).
Acharya does not explicitly disclose receiving, at the user service, subscribed to the queue, the presence message in order of publication.
Vendrow receiving the presence message in order of publication at a user service subscribed to the queue (See para. [0042]-para.[0044] and Figure 4, maintain queue-agent available information in a queue, wherein the queue may be implemented as a first-in, first-out (FIFO) data structure and the availability/status of queue agents is maintained for determining agent availability) and processing the received presence message by accessing a cloud-based key-value NoSQL database that serves as a system of record (See para. [0050] and para. [0076] and Tables 1-2, the stored queue-agent availability information associated with respective agent/devices. Table 1 defines corresponding availability-status values, including a value of “0” when the device is not a queue agent, a value of “1” when the queue agent is offline, and a value “2” for the disclosed queue-agent status, updating the stored agent information when an agent’s status changes and transmitting a status-update message associating the identity of the device whose status changed with the corresponding new queue-availability value).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Acharya ‘s system to incorporate Vendrow’s queue-based, FIFO handing of agent-status information and its stored association between an agent/ device identifier and availability value. This would have provided an orderly mechanism for receiving and processing successive status updates, reduced the risk that stale, or out-of-order status information would control routing, and enabled the presence service to maintain a current record of each agent’s availability for use by other contact-center services. (See Vendrow’s para. [0020]). Both of the references (Vendrow and Acharya) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as maintaining agent presence status. This close relation between both references highly suggests an expectation of success.
Claims 4, 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Acharya (US 2012/0219144 A1) and in view of Vendrow (US 2010/0128867 A1) and further in view of Solodovnik (US 2023/0005060 A1).
As to claims 4, 11 and 18, Acharya does not explicitly disclose maintain message ordering by: assigning a sequence number to each published message; and processing messages at the user service in order of the sequence numbers.
Solodovnik discloses maintains message ordering by:
assigning a sequence number to each published message; and processing messages at the user service in order of the sequence numbers (See para. [0074] a queue manager 24 may receive the event on the event multicast address, and responsive to receiving the event, add the event to the queue 36 in an order according to the global sequence number of the event. The events received at the sequencer 26 may be arranged in chronological order in the queue 36 according to their global sequence numbers, so that the events may be processed in sequence according to global sequence number by an interface processor of the host server 12).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Acharya ‘s system to assign a sequence number to each published message, as taught by Solodovnik. Skilled artisans would have been motivated to use an improved architecture to minimize processing latencies (See Solodovnik, para. [0005]). All of the references (Solodovnik, Vendrow and Acharya) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as maintaining events in a queue. This close relation between all references highly suggests an expectation of success.
Claims 5, 7, 12, 14, 19 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Acharya (US 2012/0219144 A1) and in view of Vendrow (US 2010/0128867 A1) and further in view of Wei (US 2019/0121888 A1).
As to claims 5, 12 and 19, Acharya does not explicitly disclose determining if a hash for the user ID exists in a memory cache; if the hash exists, updating a timestamp value in the hash; and if the hash does not exist, creating a new hash entry with the user ID and timestamp.
Wei discloses determining if a hash for the user ID exists in a memory cache; if the hash exists, updating a timestamp value in the hash; and if the hash does not exist, creating a new hash entry with the user ID and timestamp (See para. [0048], para. [0101] and Claim 13, identifying an identifier of an target data object to determine one or more entries in a data objects table that contain the target data object, the identifier is a hash value computed using one or more name associated with the target data object; and if a target data object is not already in the data object table, creates a new entry and for each target data object in the data object table, the system updates its last-modified time field with the value of the latest time).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Acharya ‘s system to include a hash value for an identifier of a target object or an event, as taught by Wei. Skilled artisan would have been motivated to use a hash value of a database object or an event since storing a hash value can be much more compact than a lengthy textual identifier of a data object or an event (See Wei, para. [0048]). All of the references (Wei, Vendrow and Acharya) teach features that are directed to analogous art, and they are directed to the same field of endeavor, such as maintaining object state or status in a distributed system. This close relation between both references highly suggests an expectation of success.
As to claims 7, 14 and 21, Acharya in view of Vendrow discloses wherein the cloud-based key-value NoSQL database comprises: a distributed database that maintains presence records across multiple database instances (See Vendrow, para. [0050] and para. [0076] and Tables 1-2, the stored queue-agent availability information associated with respective agent/devices. Table 1 defines corresponding availability-status values, including a value of “0” when the device is not a queue agent, a value of “1” when the queue agent is offline, and a value “2” for the disclosed queue-agent status, updating the stored agent information when an agent’s status changes and transmitting a status-update message associating the identity of the device whose status changed with the corresponding new queue-availability value).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Acharya ‘s system to include agent queues to publish and receive presence message, as taught by Vendrow. Skilled artisan would have been motivated to utilize queue data structure to service users to facilitate a relatively small group of people to handle a relatively large number of user requests (See para. [0020]). Both of the references (Vendrow and Acharya) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as maintaining agent presence status. This close relation between both references highly suggests an expectation of success.
Acharya in view of Vendrow does not disclose each presence record includes at least the user ID and a timestamp of the most recent status update.
Wei discloses each presence record includes at least the user ID and a timestamp of the most recent status update (See para. [0048], para. [0101] and Claim 13, creates a new entry and for each target data object in the data object table, the system updates its last-modified time field with the value of the latest time).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Acharya ‘s system to include each presence record comprises at least a user ID and a timestamp of the most recent status in order to maintain the data state of an object at a given point in time efficiently (See Wei, para. [0020]). All of the references (Wei, Vendrow and Acharya) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as maintaining object state or status in a distributed system. This close relation between both references highly suggests an expectation of success.
Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Acharya (US 2012/0219144 A1) and in view of Vendrow (US 2010/0128867 A1) and further in view of Kadakia (US 2021/0185173 A1).
As to claim 6, Acharya discloses wherein making the updated presence record available comprises query to obtain the current busy/available status of the agent; and providing the presence record (See para. [0040]-para. [0045] and Figures 2 and 3, upon receipt of a call/web-chat agent [e.g., agent 152a] published an updated status to both of the presence servers 108/158, the presence server 108/158 will contain a status of agent 152a as unavailable [e.g., “busy”], thereby obviating any possibility of agent 152a receiving another incoming call/web-chat during such time, the updates of status from “free” to “busy” or vice-versa).
Acharya does not explicitly disclose exposing an API endpoint that other services can query to obtain the status of an object; and providing the record in response to API calls from a routing service.
Kadakia discloses exposing an API endpoint that other services can query to obtain the status of an object; and providing the record in response to API calls from a routing service (See para. [0035]-para. [0037], a conductor 320 includes a service layer that exposes API endpoints 334 consumed by both web application 332 and agent 314, the conductor 320 obtains a transaction from a queue, setting a status of the transaction and sending/receiving notifications from both web application 332 and agent 314).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Acharya ‘s system to expose an API endpoint that other services can query to obtain the status of an object, as taught by Kadakia. Skilled artisan would have been motivated to provide high quality, efficient and timely service in a contact center since today’s contact center operations, which can take form of various models, providing numerous different services (See Kadakia, para. [0003]). All of the references (Kadakia, Vendrow and Acharya) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as maintaining object state or status in a distributed system. This close relation between both references highly suggests an expectation of success.
Claims 8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Acharya (US 2012/0219144 A1) and in view of Vendrow (US 2010/0128867 A1) and further in view of Le (US 20160239437 A1).
As to claim 8, Acharya discloses receiving multiple presence messages for the same agent from different client devices and maintaining separate session records in the memory cache for each client device (See para. [0049] and Figure 4, the incoming communication is routed from a first agent of a first contact center to a second agent when a free status of the second agent is ascertained).
Acharya does not explicitly disclose updating the presence record to indicate the agent is offline only when all sessions are terminated.
Le discloses updating the presence record to indicate the agent is offline only when all sessions are terminated (See para. [0119], node A or agent A is indicated offline when it is no longer perform client data access sessions, whereby all network ports of serviced network elements are closed).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to modify the system of Acharya ‘s system to update each presence record to indicate the agent is offline only when all sessions are terminated since this is a less disruptive way of servicing access request (See Le, para. [0010]). All of the references (Le, Vendrow and Acharya) teach features that are directed to analogous art and they are directed to the same field of endeavor, such as maintaining object state or status in a distributed system. This close relation between both references highly suggests an expectation of success.
Conclusion
THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YUK TING CHOI whose telephone number is (571)270-1637. The examiner can normally be reached Monday-Friday 9am-6pm.
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, AMY NG can be reached at 5712701698. 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.
/YUK TING CHOI/Primary Examiner, Art Unit 2164
Prosecution Insights