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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 11/21/2025 has been entered.
Response to Amendment
The Amendment filed 11/21/2025 has been entered. Claims 1, 3-9, 11-17 and 19-20 remain pending in the present Office Action.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “best-effort publisher-subscriber module” and “lossless publisher-subscriber module” in claims 1, 9 and 17.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claims 1, 9, and 17 recite the best-effort publisher-subscriber module “processes messages with low latency but does not store the messages to a persistence layer” and the lossless publisher-subscriber module “processes the messages with a higher latency but does store the messages to the persistence layer”.
In paragraph [0018]-[0019] of the Specification of the instant application, it is recited that “A publisher-subscriber module is any type of software and/or hardware module that receives messages from publishers (e.g., client devices) and forwards those messages to subscribers (e.g., the same and/or additional client devices). Lossless publisher-subscriber module 112 may generally represent any type of publisher-subscriber module that saves content to a persistence layer. […] Best-effort publisher-subscriber module 114 generally represents any type of publisher-subscriber module that receives data from one or more clients and sends this data to one or more clients without saving the data to a persistence layer and/or requiring confirmation that the data has been received. In some examples, by skipping these data processing steps, a best-effort publisher-subscriber module may have lower latency than a lossless publisher-subscriber module processing the same data.” Accordingly, the “best-effort publisher-subscriber module” is interpreted as any hardware or software which receives and forwards data/messages without saving the data to a persistence layer. The “lossless publisher-subscriber” is interpreted as any hardware or software which receives and forwards data/messages that also saves the data to a persistence layer.
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.
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-6, 8-9, 11-14, 16-17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Karmakar et al. (U.S. Pub. No. 2006/0248145), hereinafter Karmakar, in view of Lebaredian et al. (U.S. Pub. No. 2021/0049827), hereinafter Lebaredian, and Banks et al. (U.S. Pub. No. 2019/0052727), hereinafter Banks.
Regarding claim 1, Karmakar teaches a computer-implemented method comprising:
determining a type of a message from a client device to a server ([0025] – “Applications on the devices 102 communicate and exchange data with each other and the servers 106 via messaging. A sender, either the device 102 or the server 106, transmits the message to a receiver, either the server 106 or the device 102, respectively.”; [0097] – “For each incoming message, the server determines the message reliability mode and queues the message accordingly. The reliability mode is determined by checking the reliability header field.”) […];
determining, based on the type of the message, whether to direct the message to (i) a best-effort publisher-subscriber module that processes messages with low latency but does not store the messages to a persistence layer or (ii) a lossless publisher-subscriber module that processes the messages with a higher latency but does store the messages to the persistence layer ([0091] – “When outgoing messages are delivered to a messaging layer on the device, the operations on the message will be determined according to its predefined reliability mode property”; [0094] – “The messaging layer also handles incoming messages dynamically based on the reliability mode property. Reliable messages are persisted and queued in memory before transmitting an acknowledgement to the server, and they remain in persistent storage until they are processed. Both standard and best-effort messages are queued only in memory.”; [0097] – “Accordingly, best-effort messages are simply placed into the processing queue in the order they arrive. […] Similarly, reliable messages are placed into the queue in accordance with the order assigned by the device. Further, reliable message are stored in a persistent storage at the server.”; [0004] – “However, reliable messaging requires more system resources and slows performance when compared to best-effort messaging.”
For clarity of the record, the Examiner would like to point to paragraphs [0017]-[0019] of the Specification of the instant application which recites “Persistence layer 110 generally represents any type or form of data storage capable of storing snapshots, backups, and/or other information that can be used to reconstruct the state of digital content at a given time. […] A publisher-subscriber module is any type of software and/or hardware module that receives messages from publishers (e.g., client devices) and forwards those messages to subscribers (e.g., the same and/or additional client devices). Lossless publisher- subscriber module 112 may generally represent any type of publisher-subscriber module that saves content to a persistence layer. […] Best-effort publisher-subscriber module 114 generally represents any type of publisher-subscriber module that receives data from one or more clients and sends this data to one or more clients without saving the data to a persistence layer and/or requiring confirmation that the data has been received. In some examples, by skipping these data processing steps, a best-effort publisher-subscriber module may have lower latency than a lossless publisher-subscriber module processing the same data.” Accordingly, the messaging layer of Karmakar is acting as a “publisher-subscriber module” because it is receiving outgoing messages produced by an application on a sender (either a client or a server) and placed in a queue to be delivered, or “forward[ed]”, to a receiver. The messaging layer acts as the “best-effort publisher-subscriber module” by processing the “best-effort messages” without placing them in persistent storage and acts as the “lossless publisher subscriber module” by processing “reliable messages” including placing them in persistent storage.);
directing the message to the best-effort publisher-subscriber module based on the type of the message ([0091] – “When outgoing messages are delivered to a messaging layer on the device, the operations on the message will be determined according to its predefined reliability mode property”; [0094] – “The messaging layer also handles incoming messages dynamically based on the reliability mode property. […] Both standard and best-effort messages are queued only in memory.”; [0097] – “Accordingly, best-effort messages are simply placed into the processing queue in the order they arrive.” The appropriate operations are determined and applied by the messaging layer to the “best-effort message”.);
determining a different type of an additional message from the client device to the server ([0097] – “For each incoming message, the server determines the message reliability mode and queues the message accordingly. The reliability mode is determined by checking the reliability header field. Accordingly, best-effort messages are simply placed into the processing queue in the order they arrive. […] Similarly, reliable messages are placed into the queue in accordance with the order assigned by the device. Further, reliable message are stored in a persistent storage at the server.”; [0094] – “The messaging layer also handles incoming messages dynamically based on the reliability mode property. Reliable messages are persisted and queued in memory before transmitting an acknowledgement to the server, and they remain in persistent storage until they are processed.” “For each” implies there are multiple, i.e., additional messages.) […];
determining that the different type of the additional message is associated with the lossless publisher-subscriber module ([0091] – “When outgoing messages are delivered to a messaging layer on the device, the operations on the message will be determined according to its predefined reliability mode property”; [0094] – “The messaging layer also handles incoming messages dynamically based on the reliability mode property. Reliable messages are persisted and queued in memory before transmitting an acknowledgement to the server, and they remain in persistent storage until they are processed.”; [0097] - "For each incoming message, the server determines the message reliability mode and queues the message accordingly. The reliability mode is determined by checking the reliability header field.” The reliability mode (indicating the “type” of the message) may indicate the type of the message is a “reliable” message, and the operations to be performed on it should include persisting the message in persistent storage (i.e., it indicates the operations to be performed are those of the lossless publisher-subscriber module). Therefore, a “reliable” message type is “associated with the lossless publisher-subscriber module” since it indicates the operations of the lossless publisher-subscriber module should be performed.); and
directing the additional message to the lossless publisher-subscriber module ([0091] – “When outgoing messages are delivered to a messaging layer on the device, the operations on the message will be determined according to its predefined reliability mode property”; [0094] – “The messaging layer also handles incoming messages dynamically based on the reliability mode property. Reliable messages are persisted and queued in memory before transmitting an acknowledgement to the server, and they remain in persistent storage until they are processed.”; [0097] – “Similarly, reliable messages are placed into the queue in accordance with the order assigned by the device. Further, reliable message are stored in a persistent storage at the server.”).
Karmakar fails to teach the message comprising an intended update to content hosted on the server, wherein the intended update comprises a portion of a multi-message update that is expected to span multiple additional messages; and the additional message comprising a new intended update to the content, wherein the new intended update comprises a text update.
However, Lebaredian teaches a message from a client to a server comprising an intended update to content hosted on the server ([0098] – “A client 106 may create, delete, and/or modify content of the 3D virtual environment. Updating a file and/or resource may be done incrementally by the client 106 supplying a delta or difference for the content. […] the content manager 410 at the client 106 may track such edits made to the content (e.g., scene description portion). Examples of changes include adding any element to, deleting any element from, and/or modifying any element of scene description”; [0099] – “The content manager 410 of the client 106 may track all changes that a client 106 makes to a given content item and/or resource. For example, the content manager 410 may track multiple edit operations performed by a user and/or in software using the client 106. Based on the changes, the content manager 410 may construct a message(s) to send to the content management system 104 that includes data representative of the changes. In various examples, the content manager 410 determines differences between a version of the content item(s) received from the content management system 104, and a version of the content item(s) that includes the edits or changes (e.g., a list of the changes with timestamps). Data representative of these differences may be included in the message(s) rather than the entire content item(s).”; [0102] – “the content manager 410 may construct a delta (diff) file for each content item (e.g., layer) that describes any changes made since the corresponding local representation was last synchronized with an external representation […] The content manager 410 may only send messages to the content management server 104 to reflect some of the states of the content-or may send all of the changes. In either case, the messages may be sent periodically or as available, […] content manager 410 of a client 106 may generate, transmit, and apply delta files to and from an external source (e.g., the content management system 104)”; [0103] – “A message from a client 106 to the content management system 104 that edits or modifies a content item (e.g., a layer) may identify as an update command.”; [0033] – “corresponding messages are routed to the appropriate content management system and/or server that hosts the content item”) and an additional message from a client to a server comprising a new intended update to the content, wherein the new intended update comprises a text update ([0098]-[0099], [0102]-[0103], [0033] – as cited above, there may be multiple messages sent from the content manager 410 of a client to a server/content management system 104 that includes data representative of changes to one or more content items hosted at the server. Thus, there may be a first message with data representing a first intended update to a first content item hosted at the server and a second message with data representing a new intended update to a second content item hosted at the server. [0078] – “a subscription to content may refer to a subscription to a portion of scene description that describes the content. Changes, or deltas, of the content may be with respect to that scene description portion. For example, data representative of content that is exchanged within the operating environment 100 may be in the form of scene description-such as via scene description language in a textual form”. Data representing the changes sent in the message(s) may be in a textual form (i.e., a “text update”).), wherein the updates are also forwarded to all other clients subscribed to the updated content using a publisher-subscriber module ([0030] – “a publish/subscribe model may be operated by the content management system in which clients may subscribe to any number of content items”; [0077] – “In embodiments, clients may publish and subscribe to any piece of content (e.g., content item) for which they have suitable permissions.”; [0105] – “When the communications manager 110 of the content management system 104 receives an incremental update for a client 106, it may, using the subscription manager 402, directly forward the update (e.g., the message and/or difference data) to all other client(s) 106 (and in some embodiments the services 412 or renderers 414) subscribed to the corresponding content. Using this approach, update messages do not need to be modified before distribution. This may reduce latency and allow the content management system 104 to support a large numbers of client(s) 106 and with fast update rates.”).
Karmakar and Lebaredian are considered to be analogous art to the claimed invention because they are reasonably pertinent to the problem faced by the inventor of reducing latency in communications between one or more clients and a server without sacrificing reliability. Therefore it would have been obvious to one of ordinary skill in the art to have modified the teachings of Karmakar such that the messages from the client comprise intended updates to content hosted at a server as taught by Lebaredian. The methods of Lebaredian, including hosting the content on a server and sending updates to the content to the server, facilitate multiple users collaboratively working on the hosted content simultaneously (Lebaredian: [0027]-[0028]). Additionally, applying the client-server messaging methods taught by Karmakar to the messages sent by clients to update content hosted on the server of Lebaredian would provide improved performance while also providing reliability (Karmakar: [0004]-[0005]).
The combination of Karmakar in view of Lebaredian fails to expressly teach wherein the intended update comprises a portion of a multi-message update that is expected to span multiple additional messages.
However, Banks teaches wherein the intended update comprises a portion of a multi-message update that is expected to span multiple additional messages ([0002]-[0003] – “These client computers may need to perform updates to a server which are persistent, for example, reliably delivering messages to or from the server. Typically, one thread per client waits for work from the client and when work is received, the server performs a disk force in a transaction specific to the client.” A transaction traditionally corresponds to an update to a server received from a client; Abstract: “A client computer batch message transaction group is defined that corresponds to a set of client computers. A set of separate messages is received from at least some of the client computers in the client computer batch message transaction group. For each given separate message of the set of separate messages, a write is performed to a single message reception queue, and a determination is made regarding whether the given separate message was successfully written to the single message reception queue. Responsive to a determination that all messages of the set of separate messages were successfully written to the single message reception queue, all of the messages of the set of separate messages are written to disk as a single disk write.”; [0031]-[0032] – “The server computer (130) receives multiple messages from a number of different client applications (110). In response to receipt of the multiple messages, the server middleware (135) batches (step 310) the multiple requests under the single Transaction 2. Any client application (110) that produces work shares a transaction with each of the other client applications in its group that have also performed some work. Each client application (110) in the group accepts a single outcome of the transaction.” Defining the batch message transaction group for which a single transaction (“multi-message update”) is shared, where the transaction comprises updates to the server, is analogous to defining or “determining” the message is part of the multi-message update that will span multiple messages from multiple clients. These messages are first placed in a queue, similar to what is disclosed by the “best-effort publisher-subscriber module” of Karmakar, and not written to a disk, which is persistent storage, until all messages of the group have been received.).
Banks is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of reducing latency in communications between one or more clients and a server without sacrificing reliability. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Karmakar in view of Lebaredian such that the intended update comprises a portion of a multi-message update that is expected to span multiple messages as taught by Banks. Updates to content hosted at a server which span multiple messages from one or more clients is similarly suggested by Lebaredian (Lebaredian: [0099], [0106], and [0108]), and can be used to facilitate multiple users collaboratively working on the hosted content simultaneously (Lebaredian: [0027]-[0028]). Additionally, the methods taught by Banks, such as waiting until a batch of multiple messages has been received before using a single write (a “multi-message update”) to store the messages to persistent storage, such as a disk, results in improved efficiency and scalability (Banks: [0036] and [0045]).
Regarding claim 3, the combination of Karmakar in view Lebaredian and Banks teaches the computer-implemented method of claim 1. Banks further teaches the method further comprising sending complete content of the multi-message update to the lossless publisher-subscriber module in response to determining that the best-effort publisher-subscriber module has received the last message of the multi-message update and is not expecting further additional messages with content for the multi-message update (Abstract – “A set of separate messages is received from at least some of the client computers in the client computer batch message transaction group. For each given separate message of the set of separate messages, a write is performed to a single message reception queue, and a determination is made regarding whether the given separate message was successfully written to the single message reception queue. Responsive to a determination that all messages of the set of separate messages were successfully written to the single message reception queue, all of the messages of the set of separate messages are written to disk as a single disk write.” The server determines that all messages of the set of messages have been received in the queue and writes all the messages to a disk (which is persistent storage as known in the art) in a single write. The software and/or hardware which performs this write could reasonably be the “lossless publisher-subscriber module” of Karmakar.).
Lebaredian similarly suggests updates to a content item made by an individual client may span multiple messages (Lebaredian: [0099]), and updates to a particular content item made by multiple clients may be coalesced periodically into a new version which is persistently stored (Lebaredian: [0106] and [0108]). Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Karmakar in view of Lebaredian to determine whether all expected messages for the update have been received as suggested by Banks before sending the complete content to the lossless publisher-subscriber module of Karmakar for storing the messages to the persistence layer. Waiting until an entire batch of messages has been received before using a single write to store the messages to persistent storage, such as a disk, results in improved efficiency and scalability (Banks: [0036] and [0045]).
Regarding claim 4, the combination of Karmakar in view of Lebaredian and Banks teaches the computer-implemented method of claim 1. Karmakar teaches directing the additional message to the lossless publisher-subscriber module based on the different type of the additional message ([0091] – “When outgoing messages are delivered to a messaging layer on the device, the operations on the message will be determined according to its predefined reliability mode property”; [0094] – “The messaging layer also handles incoming messages dynamically based on the reliability mode property. Reliable messages are persisted and queued in memory before transmitting an acknowledgement to the server, and they remain in persistent storage until they are processed.”; [0097] – “Similarly, reliable messages are placed into the queue in accordance with the order assigned by the device. Further, reliable message are stored in a persistent storage at the server.”) but fails to teach wherein directing the additional message to the lossless publisher-subscriber module comprises determining that the new intended update within the additional message comprises a complete update contained in the additional message that is not expected to span any additional messages.
However, Banks teaches determining that the new intended update within the additional message comprises a complete update contained in the additional message that is not expected to span any additional messages ([0048] – “Preferably, in the case where the server computer receives a message from only one client computer in the subset (e.g., in accordance with a pre-configurable time threshold), processing is not held up waiting for a second message. Instead, default processing is reverted to (e.g., wherein the message from the one client computer is processed under a transaction that is associated only with the one client computer).”; [0002]-[0003] – “These client computers may need to perform updates to a server which are persistent, for example, reliably delivering messages to or from the server. Typically, one thread per client waits for work from the client and when work is received, the server performs a disk force in a transaction specific to the client.” When the server is only receiving a single message from a single client, the transaction comprising a disk write (storing data to persistent storage – analogous to an operation of the “lossless publisher-subscriber module” of Karmakar) occurs for the single message.).
It would have been obvious to one of ordinary skill in the art to have modified the teachings of Karmakar in view of Lebaredian to determine the update is not expected to span additional messages as taught by Banks such that the single received message is sent to the lossless publisher-subscriber module of Karmakar for processing and storing to the persistence layer. Determining additional messages are not expected ensures processing of the message is not held-up waiting for another message (Banks: [0048]).
Regarding claim 5, the combination of Karmakar in view of Lebaredian and Banks teaches the computer-implemented method of claim 1. Karmakar further teaches wherein each step of the method is performed by the client device ([0091] – “The operation of the reliable messaging protocol as implemented at the device and server is described as follows. When outgoing messages are delivered to a messaging layer on the device, the operations on the message will be determined according to its predefined reliability mode property as well as the state of the device and destination server. Each of the messages includes a reliability header field indicating the reliability level of the message.” [0092]-[0093] – Outgoing reliable messages are placed in persistent storage at the sending client device as well, whereas best-effort messages are only placed in the queue.).
Regarding claim 6, the combination of Karmakar in view of Lebaredian and Banks teaches the computer-implemented method of claim 1. Karmakar further teaches wherein each step of the method is performed by the server ([0091] – “The operation of the reliable messaging protocol as implemented at the device and server is described as follows.”; [0097] – as cited with respect claim 1, the server determines the reliability mode and performs the appropriate operations for each incoming message.).
Regarding claim 8, the combination of Karmakar in view of Lebaredian and Banks teaches the computer-implemented method of claim 1. Karmakar further teacher the method further comprising sending, by the lossless publisher-subscriber module, the additional message to the persistence layer ([0092] – “Reliable messages are also placed in persistent storage.”; [0094] – “The messaging layer also handles incoming messages dynamically based on the reliability mode property. Reliable messages are persisted and queued in memory”; [0097] – “Further, reliable message are stored in a persistent storage at the server.”).
Claim 9 is directed to a system comprising: at least one physical processor; physical memory comprising computer-executable instructions that, when executed by the physical processor (Karmakar: claim 10, [0008]), cause the physical processor to: perform the method of claim 1. Accordingly, claim 9 is rejected as being unpatentable over Karmakar in view of Lebaredian and Banks for the same reasons presented with respect to claim 1.
Claims 11-14 and 16 recite substantially the same limitations as claims 3-6 and 8, and are therefore rejected as being unpatentable over Karmakar in view of Lebaredian and Banks for the same reasons presented with respect to claims 3-6 and 8.
Claim 17 is directed to a non-transitory computer-readable medium comprising one or more computer-readable instructions that, when executed by at least one processor of a computing device (Karmakar: claim 10, [0008]), cause the computing device to: perform the method of claim 1. Accordingly, claim 17 is rejected as being unpatentable over Karmakar in view of Lebaredian and Banks for the same reasons presented with respect to claim 1.
Claims 19-20 recite substantially the same limitations as claims 3-4, and are therefore rejected as being unpatentable over Karmakar in view of Lebaredian and Banks as applied to claims 17 for the same reasons presented with respect to claims 3-4.
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Karmakar in view of Lebaredian and Banks as applied to claims 1 and 9 above, and further in view of Kropivny (U.S. Patent No. 7,765,266).
Regarding claim 7, the combination of Karmakar in view of Lebaredian and Banks teaches the computer-implemented method of claim 1, but fails to expressly teach wherein the content hosted on the server comprises content of a persistent digital multimedia room.
However, Kropivny teaches wherein the content hosted on the server comprises content of a persistent digital multimedia room (Col. 11, lines 57-63 – “Each multiple party communication hosted by the server 12 has a single associated shared buffer 88. The shared buffer 88 is generally operable to store messages received from the client computers 14, 16, and 18 that have joined a multiple party communication. The shared buffer 88 further acts as a memory buffer for storing output messages to be transmitted to the client computers 14, 16, and 18.”; Col. 19, lines 29-37 – “When a user of one of the client computers 14, 16, or 18 joins a multiple-party communication, either by clicking the "create new communication" button 132 on the web page 130 shown in FIG. 4, or by clicking the "list active communications" button 138 and selecting a multiple-party communication to join from the table 140, the server 12 transmits program codes to the client computer for displaying the user interface 470 (shown in FIG. 11) on the client computer display 15.”; Col. 21, lines 5-11 – “Persistent messages 332 that produce persistent changes to content on the display area 472; Non-persistent messages 334 that do not result in persistent changes to the display area, for example, messages that cause pointers to change position within the display area 472, but do not leave persistent changes on the display area”; Col. 21, lines 43-46 – “The persistent messages 332 are generated in response to user input that causes persistent lines to be drawn, characters to be displayed, and/or images to be displayed on the user interface 470.”; Col. 10, lines 53-63 – “The hard drive 58 further includes a communication page store 104 for saving pages of content created during multiple-party communications […] hard drive 58 may be substituted by another form of persistent memory”. Users may make changes to content displayed in a user interface of a multiple-party communication hosted by the server. The content may be multiple types of digital media (e.g., text, drawings, images). The changes are sent in messages to the server. This content created during a multiple-party communication hosted by the server is persistently stored in the hard drive of the server.).
Kropivny is considered to be analogous art to the claimed invention because it is in the same field of online collaboration and/or digital rooms. Therefore it would have been obvious to one of ordinary skill in the art to have modified the teachings of Karmakar in view of Lebaredian and Banks such that the content hosted on the server is content of a persistent digital multimedia room as taught by Kropivny. The methods of hosting a persistent digital multimedia room as taught by Kropivny facilitates simultaneous user input from all client computers and makes users aware of other the actions of other users (Kropivny, Col. 9, lines 55-62). Additionally, applying the client-server messaging methods taught by Karmakar to the messages updating content of a persistent digital multimedia room of Kropivny would provide improved performance while also providing reliability (Karmakar: [0004]-[0005]).
Claim 15 recites substantially the same limitations as claim 7, and is therefore rejected as being unpatentable over Karmakar in view of Lebaredian and Banks as applied to claim 9, and further in view of Kropivny for the same reasons presented with respect to claim 7.
Response to Arguments
Applicant's arguments filed 11/21/2025 have been fully considered but they are not persuasive.
Applicant argues Banks fails to teach the amended limitations “determining that the different type of the additional message is associated with the lossless publisher-subscriber module; and directing the additional message to the lossless publisher-subscriber module” recited in claim 1.
However, the Examiner has not relied upon Banks to teach the argued limitations. Rather, the Examiner has relied upon Karmakar (U.S. Pub. No. 2006/0248145) to teach the limitations recited in the amendment to the claims filed 11/21/2025. No specific arguments were presented with respect to the use of Karmakar.
Specifically, Karmakar teaches determining that the different type of the additional message is associated with the lossless publisher-subscriber module ([0091] – “When outgoing messages are delivered to a messaging layer on the device, the operations on the message will be determined according to its predefined reliability mode property”; [0094] – “The messaging layer also handles incoming messages dynamically based on the reliability mode property. Reliable messages are persisted and queued in memory before transmitting an acknowledgement to the server, and they remain in persistent storage until they are processed.”; [0097] - "For each incoming message, the server determines the message reliability mode and queues the message accordingly. The reliability mode is determined by checking the reliability header field.” The reliability mode (indicating the “type” of the message) may indicate the type of the message is a “reliable” message, and the operations to be performed on it should include persisting the message in persistent storage (i.e., it indicates the operations to be performed are those of the lossless publisher-subscriber module). Therefore, a “reliable” message type is “associated with the lossless publisher-subscriber module” since it indicates the operations of the lossless publisher-subscriber module should be performed.); and directing the additional message to the lossless publisher-subscriber module ([0091] – “When outgoing messages are delivered to a messaging layer on the device, the operations on the message will be determined according to its predefined reliability mode property”; [0094] – “The messaging layer also handles incoming messages dynamically based on the reliability mode property. Reliable messages are persisted and queued in memory before transmitting an acknowledgement to the server, and they remain in persistent storage until they are processed.”; [0097] – “Similarly, reliable messages are placed into the queue in accordance with the order assigned by the device. Further, reliable message are stored in a persistent storage at the server.”).
Accordingly, claim 1 is rejected as being unpatentable over Karmakar in view of Lebaredian and Banks as presented in the rejection above.
Claims 9 and 16 recite similar limitations as claim 1; accordingly, the Examiner’s response is applicable to claims 9 and 16 as well. There were no additional arguments presented with respect to claims 3-8, 11-15, and 19-20, which depend from claims 1, 9 and 16.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Gale et al. (U.S. Pub. No. 2008/0127209) teaches a message sent by a client to a publish/subscribe message broker may be marked as “persistent” or “non-persistent”, such that messages marked as “persistent” are passed to a persistence manager by a publish/subscribe matching engine, where the persistence manager may store the message persistently (see [0068]).
Ponnuswamy (U.S. Pub. No. 2021/0216380) teaches a message may include flags indicating how the message should be handled, e.g., one flag may indicate a message should be written to persistent storage (see [0019], [0021], and [0042]).
Baptist et al. (U.S. Pub. No. 2018/0241818) teaches a protocol message indicating which type of protocol is to be implemented for a data slice, where the type of the protocol message may be a “best efforts” protocol message, which allows access to the data slice to be provided before the data slice is stored in persistent memory. The type of the protocol message may alternatively be a “strong durability” type, which indicates persistent storage is required (see [0051]).
Laarhuis (EP 2355403 A1) teaches a system for running multi-party multi-media conferencing applications in which a plurality of distribution services, including a best-effort service, reliable service, and/or real-time service, provided by a network, are used to distribute data from a producing node to a consuming node, where the data may comprise one or more fields indicating durability of the data, e.g., whether the data is volatile or persistent (see [0003] and [0009]-[0011]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 9:00 am - 5:00 pm.
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, Kevin Young can be reached at 571-270-3180. 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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194