DETAILED ACTION
This Action is responsive to the amendments filed on 03/26/2026.
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 .
Claim Status
Claims 1-20 are amended. Claims 1-20 are pending and have been examined.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding Claim 1,
Claim 1 recites “the third memory being external to and shared by the first and second computers for cache coherence between the first and second computers … and the third memory operates without a cache coherence protocol” (Emphasis added) in the 5-9th lines. Examiner has reviewed the Specification and cannot find support for the claimed concept of a third external third memory shared by first and second computers providing “cache coherence between” the first and second computers in an embodiment whereby the external memory operates “without a cache coherence protocol”.
Examiner first notes that while the Instant Specification ¶0002 provides a general description of “cache coherence”, no special definition for the aforementioned term is provided in the Specification. Examiner therefore relies on the plain meaning of the term “cache coherence” to establish the BRI of the claim. As disclosed in Specification ¶0002, the concept of cache coherence refers to “consistency and synchronization of data stored in different caches” of a computing system, whereby cache coherence protocols “attempt to ensure that changes/updates” to data made at one cache “are propagated to the shared memory and/or to all other cached copies” of the data. Examiner accordingly considers the BRI of the claimed concept of a third memory providing “cache coherence between” first and second computers as establishing that the third memory acts as a mechanism for consistency and synchronization of data stored in first and second computers.
Examiner has reviewed the specification and cannot identify support for the external third memory providing “cache coherence between” first and second computers “without using a cache coherence protocol”. Examiner notes that the instant Specification ¶0015 teaches that “embodiments disclosed herein use disaggregated memory for communication between processors of computers” without requiring a complex/unscalable cache coherence protocol. As similarly taught in ¶0029, “communication between computers” is achieved “using a shared and non-cache-coherent disaggregated memory.” Examiner considers an external memory being used for communication between computers as distinct from the concept of an external memory being used for cache coherence between computers as recited in Claim 1.
As taught in ¶0025, an external third memory is considered as “non-cache-coherent” when a cache coherence protocol “is not used to provide data consistency” for copies of data stored on different CPUs. As further taught in ¶0025, alternate embodiments operate the external third memory using a cache coherence protocol. Examiner notes that the aforementioned alternate embodiment appears to be an example of an external third memory shared by first and second computers “for cache coherence between the first computer and the second computer” as recited in Claim 1 because a cache coherence protocol is being used. However, such an alternate embodiment is specifically distinct from the embodiment whereby “the third memory operates without using a cache coherence protocol” as additionally recited in Claim 1. Therefore, examiner cannot identify support in the Specification for an embodiment of disclosed invention whereby the third external memory is used both 1) “for cache coherence between the first computer and the second computer”; AND 2) “the third memory operates without using a cache coherence protocol”.
Therefore, Claim 1 is rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. Claims 8 and 16 recite substantially similar language as compared to Claim 1 as are therefore similarly rejected under 35 U.S.C. 112(a) according to the same rationale. Claims 2-7, 9-15, and 17-20 are similarly rejected according to their respective dependencies.
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.
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.
Claims 1-3, 5-10, 12-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Witham (US 20230342297 A1)(hereafter referred to as Witham) further in view of Nortman (US 20220155975 A1)(cited by examiner in previous action)(hereafter referred to as Nortman).
Regarding Claim 1,
Witham discloses the following limitations:
A computing system (Fig. 1), comprising:
a first computer (System 110(1), Fig. 1) that includes a first processor (CPU 510, Fig. 5) and a first memory (Shared Memory 112(1), Fig. 5 // Memory 520, Fig. 5) having a first buffer (“Each system 110 can represent a server device, a processor node, a blade server, or some other node in a system that performs processing operations” [0027] // “memory 520 can operate to cache data locally for processes executed by CPU” [0101] // Figs. 1 + 5 // ¶¶0098-101) – As shown in Fig. 1 + 5, a system 100 is comprised of plural servers 110, each individual server 110 comprising both a CPU 510 (i.e., “a first processor”) and a memory 520 which locally caches data for the CPU (i.e., “a first memory having a first buffer”);
a second computer (System 110(2), Fig. 1) that includes a second processor and a second memory (Shared Memory 112(2), Fig. 1) having a second buffer (“Each system includes a local copy of a shared memory” [0030] // Figs. 1 + 5 // ¶¶0098-101) – As taught in ¶0030 and as shown in Figs. 1 + 5, each server of system 110 (including system 110(2)) includes a respective CPU and a respective shared memory locally caching data for the CPU (i.e., “a second processor and a second memory having a second buffer”); and
a third memory (Shared Memory 112(3), Fig. 1) having a third buffer (Figs. 1 + 5 // ¶¶0030; 0098-101), the third memory being external to and shared by the first and second computers (“Each system includes a local copy of a shared memory … referred to as shared memory 112” [0030]) – As discussed above and as shown in Fig. 1, a third shared memory 112(3) is external to both systems 110(1) and 110(2)--
for cache coherence between the first computer and the second computer, … and the third memory operates without using a cache coherence protocol (“In accordance with system 200, the execution of an application in one node can write to another node’s application memory. As described herein, the shared memory is cache coherent memory without having or needing external management, referring to a dedicated node that manages the shared memory” [0049] // Figs. 1 + 2 + 5 // ¶0040) – As explicitly disclosed in ¶0049, each of shared memories 112(1)-112(N) (i.e., including shared memory 112(3); i.e., including “the third memory”) are “cache coherent memory” (i.e., “for cache coherence between” all systems 110 including systems 110(1) and 110(2); i.e., for cache coherence “between the first and second computer”) without “having or needing external management” (i.e., the shared memory 112 “operates without” requiring a dedicated external management node; i.e., the shared memory operates “without using a cache coherence protocol”) and wherein:
the first processor is configured to write (¶0048, step 3) data into the first buffer in the first memory … the first processor is configured to write (¶0048, step 4) the data from the first buffer in the first memory to the third buffer in the third memory (“An example process that program 220 and node 210 can apply for updating a block of data can be: 1) acquire the locking structure for the desired data … 2) send a message to the remote subscribers … 3) update the local copy of the block of data; and, 4) send the local block to the remote nodes to enable them to update their local copies” [0048]) – As taught in ¶0048, during operation, any node 210 (i.e., including system 110(1); i.e., “the first processor”) updates a local data block (i.e., “write[s] data into the first buffer in the first memory”) during a step 3); and subsequently sends the updated local copy to any remote node containing the data (i.e., “write the data from the first buffer in the first memory” to any remote node; i.e., “to the third buffer in the third memory’); and
…
the second processor is configured to … the data from the third buffer in the third memory to the second buffer in the second memory. (“each device can be a producer to broadcast memory updates, and the other devices can be consumers to receive the memory updates … In response to a successful message receive … the consumers invalidate the cache line that is the subject of the message in a local copy of the shared memory. The devices can update the cache line in the local copy of the shared memory as data is processed as received over the optical communication link” [0020-21]) – As discussed above and as clarified in ¶0020, each server 112 acts as both a producer for and a consumer of data updates to each other server in system 100. As clarified in ¶0021, when acting as a consumer of a data update, a server receives an updated data block (from the local memory of a producer; see above) and then updates the local copy of the data block (i.e., receives “the data from the third buffer in the third memory to the second buffer in the second memory”).
Although Witham ¶¶0020-23 discloses an “ACK/NACK” protocol to effectively establish ownership of data during an update process, Witham does not appear to explicitly disclose a first processor writing data to a third memory but setting ownership to correspond to a second processor. In addition, although Witham ¶0021 discloses that consumers receive updated data blocks from the shared memory of producers, Witham does not disclose a process whereby a consumer actively copies data from the shared memory of a producer as opposed to receiving the data from the consumer. In particular, Witham does not appear to explicitly disclose the following limitations:
wherein the first and second computers are configured to communicate with each other via the third memory, …
the first processor is configured to … set an ownership associated with the data to correspond to the second processor
the second processor is configured to perform a polling process to determine the ownership of the data, and
in response to the polling process having determined that the ownership corresponds to the second processor, the second processor is configured to copy the data from the third buffer in the third memory.
However, Nortman discloses the following limitations:
wherein the first (Publisher 104a, Fig. 1 // Node 602n, Fig. 6) and second computers (Subscriber 108a, Fig. 1 // Node 602b, Fig. 6) are configured to communicate with each other via the third memory (Shared Memory 110, Fig. 1 // Node 601a, Fig. 6)(“each publisher 104a-n .. may be considered a “writer” for accessing data in the shared memory 110, and each subscriber 108a-n … may be considered a “reader” for accessing data in the shared memory 110.” [0029]) – As shown in Nortman Fig. 1 and as taught in ¶0029, a publisher 104a located on a node 602n communicates data updates to a subscriber 108a located on a separate node 602b in a system which includes a shared memory 110, similar to how in the system of Witham Fig. 1, a publisher server 110(1) communicates updates to a subscriber server 110(2) located on a separate node in a system which includes a shared memory 112(3). Examiner accordingly considers publisher 104a, subscriber 108a, and shared memory 110 depicted in Nortman Fig. 1 as analogous to the claimed “first computer”, “second computer”, and “third memory”, respectively. As taught in Nortman, publishers write data to shared memory, and subscriber read data from shared memory (i.e., publishers and subscribers “communicate with each other via the third memory”)--
the first processor is configured to … set an ownership (“the publisher sets the value of the counter to 0” [0049]) associated with the data to correspond to the second processor (“The value of the buffer counter … is odd during a write operation to a buffer and even when no write operation is in progress” [0053] // “In certain embodiments, a buffer ring 120 may also include a global header 124 … the global header 126 may include … a counter in addition to the seqlock … for indicating current write position of a publisher in the buffer ring 120 … The counter is stored as a signed integer and is initialized to have a value of -2 when the buffer ring 120 is empty. When a publisher acquires the seqlock for a first write operation to the buffer ring 120 … it automatically increments the value to -1. Upon completion of the first write operation, the publisher sets the value of the counter to 0 before releasing the seqlock.” [0049] // ¶0051 // ¶¶0037-39; 0049-54) – As taught in Nortman, each message written by a publisher into buffer ring 120 includes a global header including a counter value (¶0049) and is associated with a particular “topic” to enable message delivery between publisher and subscriber (¶0037). As clarified in ¶¶0049-54, publishers modify the counter value at different points during a write operation such that the counter value is odd while a write is in progress, and the counter value is even when no write is in progress, effectively signalling to the subscriber whether or not data is available to be read from the buffer (¶0051). In this context, the message associated with the counter is effectively owned by (i.e., is accessible in the shared buffer to) the publisher while the counter is odd (i.e., while being written by the publisher) and is effectively owned by the subscriber while the counter is even (i.e., while being available for consumption to the subscriber). Examiner accordingly considers a publisher setting the value of a counter in the global header of a message to be even after a completed write operation as the publisher “set[ting] an ownership” of the message to the subscriber (i.e., “to correspond to the second processor”)--; …
the second processor is configured to perform a polling process to determine the ownership of the data (“During a read operation to the buffer, a subscriber begins a read by reading (and storing a local copy of) the value of the buffer counter” [0054]) – As disclosed in ¶0054, before reading data from the shared buffer ring, subscribers first read the counter value associated with the message to be read. Examiner considers a subscriber reading a counter associated with a message in a shared buffer ring as the subscriber “perform[ing] a polling process” to determine whether a write operation is currently in progress and thus to determine whether the subscriber can access the data in the buffer (i.e., “to determine the ownership of the data”)--, and
in response to the polling process having determined that the ownership corresponds to the second processor, the second processor is configured to copy the data from the third buffer in the third memory (“If the value of the buffer counter is odd, the subscriber determines that a write operation is in progress and waits for notification that the write operation is completed … before reading data from the buffer. If the value of the buffer is even, the subscriber proceeds to read the data stored in the buffer” [0054]) – As clarified in ¶0054, after a subscriber determines that the associated counter value is even, the subscriber reads the data from the shared buffer ring.
Witham and Nortman are considered analogous to the claimed invention because they all relate to the same field of establishing publisher and subscriber schemes for data transmission between remote nodes in systems which comprise memory shared between remote nodes. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Witham with the teachings of Nortman and realize a computing system whereby a subscriber performs polling of data ownership prior to reading the data from a memory shared between producers and consumers. Subscribers polling for data ownership prior to reading data from a shared memory reduces network traffic as compared to traditional point-to-point messaging paradigms whereby subscribers continually query shared memory for events as opposed to polling solely for data ownership associated with an event, as disclosed in Nortman ¶0061: “The publish/subscribe scheme is therefore more flexible than other communication paradigms, because publishers and subscribers can be started and stopped asynchronously. Furthermore, the event notification are sent to the subscribes or publishers rather than them querying for updates. This results in a reduction of network traffic.” [0061]
Regarding Claim 2,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 2. The combined teachings of Witham and Nortman disclose the following limitations:
The computing system of claim 1, wherein the first, second, and third buffers are configured as circular buffers (Nortman, “A buffer ring” [0003]) having a plurality of units (Nortman, Fig. 3 // “The LiDAR processing system 311 processes data read from buffer rings 302(a) and 302(b) and publishes it to buffer ring 303” [0045] // “The buffer ring may include a plurality of fixed sized buffers” [0005]) – As shown in Nortman Fig. 3 and taught in ¶0045, buffer ring structures are used by publishers and subscribers to transfer data--, and wherein each unit of the circular buffers has a size to accommodate bytes of the data and a bit value that indicates the ownership. (Nortman, “a plurality of fixed sized buffers configured to store messages, and a global header comprising a counter and a lock” [0005]) – As taught in Norman, ring buffers include a plurality of “fixed-sized buffers” each of which stores both a message (i.e., data) and a global header comprising a counter (i.e., the counter used during polling to determine ownership; see Claim 1 limitation mapping above). In this context, examiner considers the counter stored in the global header stored in a fixed-sized buffer as “a bit value that indicates the ownership”.
Regarding Claim 3,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 3. The combined teachings of Witham and Nortman disclose the following limitations:
The computing system of claim 2, wherein the size of each unit of the circular buffers corresponds to a size of cache lines of the first and second processors (Nortman, “the buffer header may occupy a unique cache line in the shared memory. Additionally or alternatively, each buffer may also include a data region that starts in a cache line of the shared memory immediately following the unique cache line of a corresponding buffer header” [0009]) – As taught in Nortman, each individual buffer of a ring buffer can be sized according to two cache lines of the shared memory (i.e., one cache line for the header and one cache line for the data).
Regarding Claim 5,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 1. The combined teachings of Witham and Nortman disclose the following limitations:
The computing system of claim 1, wherein to write the data from the first buffer in the first memory to the third buffer in the third memory, the first processor is configured to
bypass a cache (Witham, Fig. 2) in the first computer by directly writing as a single unit the data (Witham, “the interface has a direct memory access (DMA) channel, enabling direct access to shared memory 212 from the interface driver to the optical communication link. The DMA access enables the interface to bypass the program hierarchy and send the data from the message directly to the cache controller” [0051]) – As shown in Witham Fig. 2 and taught in ¶0051, DMA enables data to be directly written into shared memory, thereby bypassing memory of the program hierarchy (e.g., stack 224 + heap 226; i.e., “bypass a cache”)--
and a bit value (Nortman, “a header” [0046] // ¶0005) that indicates the ownership, from the first buffer in the first memory to the third buffer in the third memory (Nortman, “each buffer 121 a-n of a buffer ring 120 may include a header 122 and a data portion 123” [0046]) – As taught in both Nortman ¶0046, message data and the corresponding header (e.g., including the buffer counter (see Nortman ¶0005); i.e., including “a bit value” indicating ownership) are both written into the same buffer 121 of ring buffer 120 (i.e., “as a single unit”)
Regarding Claim 6,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 6. The combined teachings of Witham and Nortman disclose the following limitations:
The computing system of claim 1, wherein the first computer is configured to send (Nortman, ¶0061) a message (Nortman, “notifications” [0061]) to the second computer to inform the second processor that the first processor will write to the third buffer in the third memory(Nortman, “a subscriber may register interest in or subscribe to events pertaining to a given topic … Publishers may publish notifications about the occurrence of events on a channel by first marking these notifications with a particular topic … via a memory broker 170” [0060-61] // ¶¶0039; 0065) – As taught in Nortman ¶¶0060-61, subscribers receive “notifications” sent by publishers (via a memory broker 170) to inform subscribers of events (e.g., including a write operation from a publisher; see ¶0065) associated with a given topic (i.e., associated with a given shared buffer ring; see ¶0039), and
wherein in response to receiving the message (Nortman, “a notification of a new write operation” [0065]), the second processor is configured to start the polling process (Nortman, “The wait queue of processes may include subscribers waiting for a notification of a new write operation to a buffer … For example, the futex system call may be used to send a notification to subscribers of a buffer ring when a value of a buffer counter corresponding to a buffer in the buffer ring is even” [0065] // ”During a read operation to the buffer, a subscriber begins a read by reading (and storing a local copy of) the value of the buffer counter” [0054]) – As disclosed in ¶0054, before reading data from the shared buffer ring, subscribers first read the counter value associated with the message to be read. Examiner considers a subscriber reading a counter associated with a message in a shared buffer ring as the subscriber “start[ing] the polling process” –
Regarding Claim 7,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 7. The combined teachings of Witham and Nortman disclose the following limitations:
The computing system of claim 1, wherein the second processor is further configured, after copying the data to the second buffer in the second memory, to:
generate a reply (Nortman, “Multiple publishers may write messages to a buffer ring, and multiple subscribers may read data from a buffer ring” [0045] // Figs. 1 + 6 // ¶¶0038-39; 0122)
As taught in Nortman ¶0045, multiple publishers and multiple subscribers publish and read messages from the same shared buffer ring 120. As previously discussed (see Claim 1 limitation mappings above) and as disclosed in Nortman: Each node (e.g., 602n and 602b) in a network can include both publishers and subscribers (Fig. 6; ¶0122); and Each publisher and subscriber can access a number of topics, with each shared buffer ring corresponding to a particular topic (¶¶0038-39). One of ordinary skill in the art would accordingly understand that two nodes (e.g., 602n and 602b; i.e., associated with “the first processor” and “the second processor”, respectively) could each contain both a publisher and a subscriber which access the same given topic. In such an embodiment, publishers and subscribers operating on both nodes 602n and 602b would be publishing messages to and reading messages from the same shared ring buffer 120 (e.g., located on Node 601a). In such an embodiment, a publisher located on node 602b can write messages into shared buffer ring 120 both before and after reading messages from the shared buffer ring 120, which examiner considers as “the second processor” (i.e., the processor which subscribes to a given topic) “generat[ing] a reply” (i.e., publishing a message to the same buffer where a previous message was read)--
by modifying the data in the second buffer in the second memory (Nortman, Fig. 3 // “The LiDAR processing system 311 processes data read from buffer rings 302(a) and 302(b) and publishes it to buffer ring 303” [0045]) – As shown in Nortman Fig. 3 and taught in ¶0045, publishers publish data specifically to a buffer ring in memory (i.e., “modifying the data in the second buffer in the second memory”)--;
set an ownership associated with the modified data to correspond to the first processor (Nortman, ¶0049) – As previously discussed (see Claim 1 limitation mappings above), publishers modify counters in message headers to effectively communicate ownership of data to subscribers, which read message headers. One of ordinary skill in the art would accordingly understand that a publisher on node 602b (i.e., ‘the second processor”) would set a counter associated with a published message to an even value after a write operation to shared ring buffer 120 is complete to signal to subscribers (i.e., “the first processor”) that data is accessible (i.e., “set[s] an ownership”) in the ring buffer--; and
write the modified data from the second buffer in the second memory to the third buffer in the third memory (Nortman, Fig. 3, ¶0045) – As discussed above, publishers publish data to a buffer ring and subscribers similarly read data from a buffer ring-- and
wherein the first processor is configured to perform another polling process to determine the ownership of the modified data (Nortman, ¶0054) – As previously discussed (see Claim 1 limitation mappings above), a subscriber reads the buffer counter from the header of a message in order to determine whether or not an associated write operation is complete (i.e., a “polling process to determine the ownership”). In this case, examiner considers a subscriber on node 602n reading a buffer counter as “another polling process” (i.e., this time performed by “the first processor”)--, and
in response to the another polling process having determined that the ownership of the modified data corresponds to the first processor, the first processor is configured to copy the modified data from the third buffer in the third memory to the first buffer in the first memory (Nortman, Fig. 3 // ¶¶0045; 0054) – As previously discussed (see Claim 1 limitation mappings above) and as taught in Nortman ¶0054, a subscriber reads data from the shared ring buffer only after determining that the associated buffer counter has an even value.
Regarding Claim 8,
Witham discloses the following limitations:
A method for a first computer (System 110(1), Fig. 1) having a first processor (CPU 510, Fig. 5) and a first memory (Shared Memory 112(1), Fig. 5 // Memory 520, Fig. 5) to communicate with a second computer (System 110(2), Fig. 1) having a second processor and a second memory (Shared Memory 112(2), Fig. 1)(“Each system 110 can represent a server device, a processor node, a blade server, or some other node in a system that performs processing operations” [0027] // “memory 520 can operate to cache data locally for processes executed by CPU” [0101] // Figs. 1 + 5 // ¶¶0098-101) – As shown in Fig. 1 + 5, a system 100 is comprised of plural servers 110, each individual server 110 comprising both a CPU 510 and a memory 520 which locally caches data for the CPU--,
the method comprising:
writing (¶0048, step 3), by the first processor, data into a first buffer (¶0101) in the first memory (“An example process that program 220 and node 210 can apply for updating a block of data can be: 1) acquire the locking structure for the desired data … 2) send a message to the remote subscribers … 3) update the local copy of the block of data;” [0048]) -- As taught in ¶0048, during operation, any node 210 (i.e., including system 110(1); i.e., “the first processor”) updates a local data block (i.e., “write[s] data into … the first memory”) during a step 3). As clarified in ¶0101, memory 520 caches data locally for a CPU. Examiner accordingly considers the memory location (i.e., of memory 520) into which an updated local data block is written as “a first buffer” of memory 520-- …;
sending (¶0048, step 2), by the first computer, a message to the second computer (“node 210 can apply for updating a block of data … 2) send a message to the remote subscribers to invalidate the data in all remote memory copies of the shared memory” [0048] // “each device can be a producer to broadcast memory updates, and the other devices can be consumers to receive the memory updates” [0020]) – As taught in ¶0048, publishers send a message to remote subscribers when updating a data block locally in shared memory. As clarified in ¶0020, each server 112 acts as both a producer for and a consumer of data updates to each other server in system 100. One of ordinary skill in the art would accordingly understand that server 112(2) is a subscriber to data updates for a producer 112(1)-- …
wherein the third memory (Shared Memory 112(3), Fig. 1) is external to and shared by the first and second computers (“Each system includes a local copy of a shared memory … referred to as shared memory 112” [0030]) – As discussed above and as shown in Fig. 1, a third shared memory 112(3) is external to both systems 110(1) and 110(2)--
for cache coherence between the first computer and the second computer, and the third memory operates without using a cache coherence protocol (“In accordance with system 200, the execution of an application in one node can write to another node’s application memory. As described herein, the shared memory is cache coherent memory without having or needing external management, referring to a dedicated node that manages the shared memory” [0049] // Figs. 1 + 2 + 5 // ¶0040) – As explicitly disclosed in ¶0049, each of shared memories 112(1)-112(N) (i.e., including shared memory 112(3); i.e., including “the third memory”) are “cache coherent memory” (i.e., “for cache coherence between” all systems 110 including systems 110(1) and 110(2); i.e., for cache coherence “between the first and second computer”) without “having or needing external management” (i.e., the shared memory 112 “operates without” requiring a dedicated external management node; i.e., the shared memory operates “without using a cache coherence protocol”)--, and
…
writing (¶0048, step 4), by the first processor, the data from the first buffer in the first memory to the third buffer in the third memory (“An example process that program 220 and node 210 can apply for updating a block of data can be: … 3) update the local copy of the block of data; and, 4) send the local block to the remote nodes to enable them to update their local copies” [0048]) – As taught in ¶0048, during a step 4), a producer sends the updated local copy to any remote subscriber which contains a copy of the data (i.e., “write the data from the first buffer in the first memory” to any remote node; i.e., “to the third buffer in the third memory’),
… the second processor is configured to … the data from the third buffer in the third memory to the second buffer in the second memory. (“each device can be a producer to broadcast memory updates, and the other devices can be consumers to receive the memory updates … In response to a successful message receive … the consumers invalidate the cache line that is the subject of the message in a local copy of the shared memory. The devices can update the cache line in the local copy of the shared memory as data is processed as received over the optical communication link” [0020-21]) – As discussed above and as clarified in ¶0020, each server 112 acts as both a producer for and a consumer of data updates to each other server in system 100. As clarified in ¶0021, when acting as a consumer of a data update, a server receives an updated data block (from the local memory of a producer; see above) and then updates the local copy of the data block (i.e., receives “the data from the third buffer in the third memory to the second buffer in the second memory”).
Although Witham ¶¶0020-23 discloses an “ACK/NACK” protocol to effectively establish ownership of data during an update process, Witham does not appear to explicitly disclose a first processor writing data to a third memory but setting ownership to correspond to a second processor. In addition, although Witham ¶0021 discloses that consumers receive updated data blocks from the shared memory of producers, Witham does not disclose a process whereby a consumer actively copies data from the shared memory of a producer as opposed to receiving the data from the producer. In particular, Witham does not appear to explicitly disclose the following limitations:
the first processor … setting an ownership associated with the data to correspond to the second processor
sending, by the first computer, a message to the second computer to inform the second processor that the first processor will write to a third buffer in a third memory
wherein in response to the message, the second processor starts a polling process to determine the ownership
wherein in response to a polling process having determined that the ownership corresponds to the second processor, the second processor is configured to copy the data from the third buffer in the third memory
However, Nortman discloses the following limitations:
the first processor (Publisher 104a, Fig. 1 // Node 602n, Fig. 6)(“each publisher 104a-n .. may be considered a “writer” for accessing data in the shared memory 110, and each subscriber 108a-n … may be considered a “reader” for accessing data in the shared memory 110.” [0029]) – As shown in Nortman Fig. 1 and as taught in ¶0029, a publisher 104a located on a node 602n communicates data updates to a subscriber 108a located on a separate node 602b in a system which includes a shared memory 110, similar to how in the system of Witham Fig. 1, a publisher server 110(1) communicates updates to a subscriber server 110(2) located on a separate node in a system which includes a shared memory 112(3). Examiner accordingly considers publisher 104a, subscriber 108a, and shared memory 110 depicted in Nortman Fig. 1 as analogous to the claimed “first computer”, “second computer”, and “third memory”,--
setting an ownership (“the publisher sets the value of the counter to 0” [0049]) associated with the data to correspond to the second processor (Subscriber 108a, Fig. 1 // Node 602b, Fig. 6) (“The value of the buffer counter … is odd during a write operation to a buffer and even when no write operation is in progress” [0053] // “In certain embodiments, a buffer ring 120 may also include a global header 124 … the global header 126 may include … a counter in addition to the seqlock … for indicating current write position of a publisher in the buffer ring 120 … The counter is stored as a signed integer and is initialized to have a value of -2 when the buffer ring 120 is empty. When a publisher acquires the seqlock for a first write operation to the buffer ring 120 … it automatically increments the value to -1. Upon completion of the first write operation, the publisher sets the value of the counter to 0 before releasing the seqlock.” [0049] // ¶0051 // ¶¶0037-39; 0049-54) – As taught in Nortman, each message written by a publisher into buffer ring 120 includes a global header including a counter value (¶0049) and is associated with a particular “topic” to enable message delivery between publisher and subscriber (¶0037). As clarified in ¶¶0049-54, publishers modify the counter value at different points during a write operation such that the counter value is odd while a write is in progress, and the counter value is even when no write is in progress, effectively signalling to the subscriber whether or not data is available to be read from the buffer (¶0051). In this context, the message associated with the counter is effectively owned by (i.e., is accessible in the shared buffer to) the publisher while the counter is odd (i.e., while being written by the publisher) and is effectively owned by the subscriber while the counter is even (i.e., while being available for consumption to the subscriber). Examiner accordingly considers a publisher setting the value of a counter in the global header of a message to be even after a completed write operation as the publisher “set[ting] an ownership” of the message to the subscriber (i.e., “to correspond to the second processor”)--;
sending (¶0061), by the first computer, a message (“notifications” [0061]) to the second computer to inform the second processor that the first processor will write to a third buffer (Buffer Ring 120a, Fig. 1 // ¶0040) in a third memory (Shared Memory 110, Fig. 1 // Node 601a, Fig. 1)(“a subscriber may register interest in or subscribe to events pertaining to a given topic … Publishers may publish notifications about the occurrence of events on a channel by first marking these notifications with a particular topic … via a memory broker 170” [0060-61] // ¶¶0039; 0065) – As taught in ¶¶0060-61, subscribers receive “notifications” sent by publishers (via a memory broker 170) to inform subscribers of events (e.g., including a write operation from a publisher; see ¶0065) associated with a given topic (i.e., associated with a given shared buffer ring; see ¶0039),
wherein in response to the message (“a notification of a new write operation” [0065]), the second processor starts a polling process to determine the ownership (“The wait queue of processes may include subscribers waiting for a notification of a new write operation to a buffer … For example, the futex system call may be used to send a notification to subscribers of a buffer ring when a value of a buffer counter corresponding to a buffer in the buffer ring is even” [0065] // ”During a read operation to the buffer, a subscriber begins a read by reading (and storing a local copy of) the value of the buffer counter” [0054]) – As disclosed in ¶0054, before reading data from the shared buffer ring, subscribers first read the counter value associated with the message to be read. Examiner considers a subscriber reading a counter associated with a message in a shared buffer ring as the subscriber “start[ing] a polling process” to determine whether a write operation is currently in progress and thus to determine whether the subscriber can access the data in the buffer (i.e., “to determine the ownership of the data”)—
wherein in response to a polling process having determined that the ownership corresponds to the second processor, the second processor is configured to copy the data from the third buffer in the third memory (“If the value of the buffer counter is odd, the subscriber determines that a write operation is in progress and waits for notification that the write operation is completed … before reading data from the buffer. If the value of the buffer is even, the subscriber proceeds to read the data stored in the buffer” [0054]) – As clarified in ¶0054, after a subscriber determines that the associated counter value is even, the subscriber reads the data from the shared buffer ring.
Witham and Nortman are considered analogous to the claimed invention because they all relate to the same field of establishing publisher and subscriber schemes for data transmission between remote nodes in systems which comprise memory shared between remote nodes. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Witham with the teachings of Nortman and realize a computing system whereby a subscriber performs polling of data ownership prior to reading the data from a memory shared between producers and consumers. Subscribers polling for data ownership prior to reading data from a shared memory reduces network traffic as compared to traditional point-to-point messaging paradigms whereby subscribers continually query shared memory for events as opposed to polling solely for data ownership associated with an event, as disclosed in Nortman ¶0061: “The publish/subscribe scheme is therefore more flexible than other communication paradigms, because publishers and subscribers can be started and stopped asynchronously. Furthermore, the event notification are sent to the subscribes or publishers rather than them querying for updates. This results in a reduction of network traffic.” [0061]
Regarding Claim 9,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 9. The combined teachings of Witham and Nortman disclose the following limitations:
The method of claim 8, wherein writing to the third buffer in the third memory comprises writing to a circular buffer(Nortman, “A buffer ring” [0003]) having a plurality of units (Nortman, “The buffer ring may include a plurality of fixed sized buffers” [0005]), in the third memory and wherein each unit of the circular buffer has a size to accommodate bytes of the data and a bit value that indicates the ownership (Nortman, “a plurality of fixed sized buffers configured to store messages, and a global header comprising a counter and a lock” [0005]) – As taught in Norman, ring buffers include a plurality of “fixed-sized buffers” each of which stores both a message (i.e., data) and a global header comprising a counter (i.e., the counter used during polling to determine ownership; see Claim 8 limitation mappings above). In this context, examiner considers the counter stored in the global header stored in a fixed-sized buffer as “a bit value that indicates the ownership”.
Regarding Claim 10,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 10. The combined teachings of Witham and Nortman disclose the following limitations:
The method of claim 9, wherein writing to the circular buffer in the third memory includes writing into a unit of the circular buffer that corresponds to a size of cache lines of the first and second processors (Nortman, “the buffer header may occupy a unique cache line in the shared memory. Additionally or alternatively, each buffer may also include a data region that starts in a cache line of the shared memory immediately following the unique cache line of a corresponding buffer header” [0009]) – As taught in Nortman, each individual buffer of a ring buffer can be sized according to two cache lines of the shared memory (i.e., one cache line for the header and one cache line for the data).
Regarding Claim 12,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 12. The combined teachings of Witham and Nortman disclose the following limitations:
The method of claim 8, wherein writing the data from the first buffer in the first memory to the third buffer in the third memory comprises:
bypassing, by the first processor, a cache (Witham, Fig. 2) in the first computer by directly writing as a single unit, the data (Witham, “the interface has a direct memory access (DMA) channel, enabling direct access to shared memory 212 from the interface driver to the optical communication link. The DMA access enables the interface to bypass the program hierarchy and send the data from the message directly to the cache controller” [0051]) – As shown in Witham Fig. 2 and taught in ¶0051, DMA enables data to be directly written into shared memory, thereby bypassing memory of the program hierarchy (e.g., stack 224 + heap 226; i.e., “bypass a cache”)--
and a bit value (Nortman, “a header” [0046] // ¶0005) that indicates the ownership, from the first buffer in the first memory to the third buffer in the third memory (Nortman, “each buffer 121 a-n of a buffer ring 120 may include a header 122 and a data portion 123” [0046]) – As taught in Nortman ¶0046, message data and the corresponding header (e.g., including the buffer counter (see Nortman ¶0005); i.e., including “a bit value” indicating ownership) are both written into the same buffer 121 of ring buffer 120 (i.e., “as a single unit”)
Regarding Claim 13,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 13. The combined teachings of Witham and Nortman disclose the following limitations:
The method of claim 8, wherein
the second processor generates a reply (Nortman, “Multiple publishers may write messages to a buffer ring, and multiple subscribers may read data from a buffer ring” [0045] // Figs. 1 + 6 // ¶¶0038-39; 0122) -- As taught in Nortman ¶0045, multiple publishers and multiple subscribers publish and read messages from the same shared buffer ring 120. As previously discussed (see Claim 8 limitation mappings above) and as disclosed in Nortman: Each node (e.g., 602n and 602b) in a network can include both publishers and subscribers (Fig. 6; ¶0122); and Each publisher and subscriber can access a number of topics, with each shared buffer ring corresponding to a particular topic (¶¶0038-39). One of ordinary skill in the art would accordingly understand that two nodes (e.g., 602n and 602b; i.e., associated with “the first processor” and “the second processor”, respectively) could each contain both a publisher and a subscriber which access the same given topic. In such an embodiment, publishers and subscribers operating on both nodes 602n and 602b would be publishing messages to and reading messages from the same shared ring buffer 120 (e.g., located on Node 601a). In such an embodiment, a publisher located on node 602b can write messages into shared buffer ring 120 both before and after reading messages from the shared buffer ring 120, which examiner considers as “the second processor” (i.e., the processor which subscribes to a given topic) “generat[ing] a reply” (i.e., publishing a message to the same buffer where a previous message was read)--
by modifying the data in the second buffer in the second memory (Nortman, Fig. 3 // “The LiDAR processing system 311 processes data read from buffer rings 302(a) and 302(b) and publishes it to buffer ring 303” [0045]) – As shown in Nortman Fig. 3 and taught in ¶0045, publishers publish data specifically to a buffer ring in memory (i.e., “modifying the data in the second buffer in the second memory”)--;
and
writes the modified data from the second buffer in the second memory to the third buffer in the third memory (Nortman, Fig. 3, ¶0045) – As discussed above, publishers publish data to a buffer ring and subscribers similarly read data from a buffer ring--
and wherein the method further comprises:
performing, by the first processor, another polling process to determine ownership of the modified data (Nortman, ¶0054) – As previously discussed (see Claim 8 limitation mappings above), a subscriber reads the buffer counter from the header of a message in order to determine whether or not an associated write operation is complete (i.e., a “polling process to determine the ownership”). In this case, examiner considers a subscriber on node 602n reading a buffer counter as “another polling process” (i.e., this time performed by “the first processor”)--;
in response to the another polling process having determined that the ownership of the modified data corresponds to the first processor, copying the modified data from the third buffer in the third memory to the first buffer in the first memory (Nortman, Fig. 3 // ¶¶0045;0054) – As previously discussed (see Claim 8 limitation mappings above) and as taught in Nortman ¶0054, a subscriber reads data from the shared ring buffer only after determining that the associated buffer counter has an even value.
Regarding Claim 14,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 14. The combined teachings of Witham and Nortman disclose the following limitations:
The method of claim 8, further comprising:
sending, by the first computer to the second computer, another message (Nortman, “the publisher sets the value of the counter to 0” [0049]) to inform the second processor that the first processor is finished writing to the third buffer in the third memory (Nortman, “The value of the buffer counter … is odd during a write operation to a buffer and even when no write operation is in progress” [0053]) – As previously discussed (see Claim 8 limitation mappings above), a publisher sets ownership of data in a shared ring buffer by updating the counter value to an even value after completing the write operation. In this case, examiner considers a publisher setting the counter value to an even value once the write operation in complete as the publisher sending “another message” (i.e., different from the notification sent by Memory Broker 170) to the subscriber to inform the subscriber that the write operation is complete-- , and
wherein the second processor ends the polling process in response to the another message (Nortman, “If the value of the buffer is even, the subscriber proceeds to read the data stored in the buffer” [0054]) – As previously discussed (see Claim 8 limitation mappings above), after reading an even counter value, the subscriber reads data stored in the shared ring buffer (i.e., effectively “end[ing]” the wait for a completed write operation)--.
Regarding Claim 15,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 15. The combined teachings of Witham and Nortman disclose the following limitations:
The method of claim 8, wherein sending the message to the second computer comprises sending the message via a network (Nortman, Memory Broker 170, Fig. 1) different from a connection link used to write the data from the first buffer in the first memory to the third buffer in the third memory. (Nortman, “Subscribers receiv notifications in the form of messages from the memory broker 170 for events that conform to topic(s) in which they have registered interest” [0061] // Fig. 1) – As previously discussed (see Claim 8 limitation mappings above), subscribers receive the notification of a new write operation from a Memory Broker 170, as opposed to from the shared buffer ring 120 (i.e., from a “network different from” the “connection link” which writes data from the publisher into the shared buffer ring; i.e., different from shared buffer ring 120). See also Nortman Fig. 1.
Regarding Claim 16,
Witham discloses the following limitations:
In a computing system that includes a first computer (System 110(1), Fig. 1) having a first processor (CPU 510, Fig. 5) and a first memory (Shared Memory 112(1), Fig. 5 // Memory 520, Fig. 5) that has a first buffer (“Each system 110 can represent a server device, a processor node, a blade server, or some other node in a system that performs processing operations” [0027] // “memory 520 can operate to cache data locally for processes executed by CPU” [0101] // Figs. 1 + 5 // ¶¶0098-101) – As shown in Fig. 1 + 5, a system 100 is comprised of plural servers 110, each individual server 110 comprising both a CPU 510 (i.e., “a first processor”) and a memory 520 which locally caches data for the CPU (i.e., “a first memory that has a first buffer”);
and a second computer (System 110(2), Fig. 1) having a second processor and a second memory (Shared Memory 112(2), Fig. 1) that has a second buffer (“Each system includes a local copy of a shared memory” [0030] // Figs. 1 + 5 // ¶¶0098-101) – As taught in ¶0030 and as shown in Figs. 1 + 5, each server of system 110 (including system 110(2)) includes a respective CPU and a respective shared memory locally caching data for the CPU (i.e., “a second processor and a second memory having a second buffer”);
a method (¶0048) for the second computer to communicate with the first computer, the method comprising:
receiving (¶0048, step 2), by the second computer from the first computer, a message to inform the second processor (“node 210 can apply for updating a block of data … 2) send a message to the remote subscribers to invalidate the data in all remote memory copies of the shared memory” [0048] // “each device can be a producer to broadcast memory updates, and the other devices can be consumers to receive the memory updates” [0020]) – As taught in ¶0048, publishers send a message to remote subscribers when updating a data block locally in shared memory. As clarified in ¶0020, each server 112 acts as both a producer for and a consumer of data updates to each other server in system 100. One of ordinary skill in the art would accordingly understand that server 112(2) is a subscriber to data updates for a producer 112(1)-- …
wherein the third memory (Shared Memory 112(3), Fig. 1) is external to and shared by the first and second computers (“Each system includes a local copy of a shared memory … referred to as shared memory 112” [0030]) – As discussed above and as shown in Fig. 1, a third shared memory 112(3) is external to both systems 110(1) and 110(2)--
for cache coherence between the first computer and the second computer, and the third memory operates without using a cache coherence protocol (“In accordance with system 200, the execution of an application in one node can write to another node’s application memory. As described herein, the shared memory is cache coherent memory without having or needing external management, referring to a dedicated node that manages the shared memory” [0049] // Figs. 1 + 2 + 5 // ¶0040) – As explicitly disclosed in ¶0049, each of shared memories 112(1)-112(N) (i.e., including shared memory 112(3); i.e., including “the third memory”) are “cache coherent memory” (i.e., “for cache coherence between” all systems 110 including systems 110(1) and 110(2); i.e., for cache coherence “between the first and second computer”) without “having or needing external management” (i.e., the shared memory 112 “operates without” requiring a dedicated external management node; i.e., the shared memory operates “without using a cache coherence protocol”)--,
…, [receiving] by the second processor, the data from the third buffer in the third memory to the second buffer in the second memory (“each device can be a producer to broadcast memory updates, and the other devices can be consumers to receive the memory updates … In response to a successful message receive … the consumers invalidate the cache line that is the subject of the message in a local copy of the shared memory. The devices can update the cache line in the local copy of the shared memory as data is processed as received over the optical communication link” [0020-21]) – As discussed above and as clarified in ¶0020, each server 112 acts as both a producer for and a consumer of data updates to each other server in system 100. As clarified in ¶0021, when acting as a consumer of a data update, a server receives an updated data block (from the local memory of a producer; see above) and then updates the local copy of the data block (i.e., receives “the data from the third buffer in the third memory to the second buffer in the second memory”).
Although Witham ¶¶0020-23 discloses an “ACK/NACK” protocol to effectively establish ownership of data during an update process, Witham does not appear to explicitly disclose a first processor writing data to a third memory but setting ownership to correspond to a second processor. In addition, although Witham ¶0021 discloses that consumers receive updated data blocks from the shared memory of producers, Witham does not disclose a process whereby a consumer actively copies data from the shared memory of a producer as opposed to receiving the data from the producer. In particular, Witham does not appear to explicitly disclose the following limitations:
receiving, by the second computer from the first computer, a message to inform the second processor that the first processor will write data to a third buffer in a third memory,
in response to the message, performing, by the second processor, a polling process to determine ownership of the data;
in response to the polling process having determined that the ownership corresponds to the second processor, copying, by the second processor, the data from the third buffer in the third memory
However, Nortman discloses the following limitations:
receiving, by the second computer (Subscriber 108a, Fig. 1 // Node 602b, Fig. 6) from the first computer (Publisher 104a, Fig. 1 // Node 602n, Fig. 6), – As shown in Nortman Fig. 1 and as taught in ¶0029, a publisher 104a located on a node 602n communicates data updates to a subscriber 108a located on a separate node 602b in a system which includes a shared memory 110, similar to how in the system of Witham Fig. 1, a publisher server 110(1) communicates updates to a subscriber server 110(2) located on a separate node in a system which includes a shared memory 112(3). Examiner accordingly considers publisher 104a, subscriber 108a, and shared memory 110 depicted in Nortman Fig. 1 as analogous to the claimed “first computer”, “second computer”, and “third memory”,--
a message (“notifications” [0061]) to inform the second processor that the first processor will write data to a third buffer (Buffer Ring 120a, Fig. 1 // ¶0040) in a third memory (Shared Memory 110, Fig. 1 // Node 601a, Fig. 1)(“a subscriber may register interest in or subscribe to events pertaining to a given topic … Publishers may publish notifications about the occurrence of events on a channel by first marking these notifications with a particular topic … via a memory broker 170” [0060-61] // ¶¶0039; 0065) – As taught in ¶¶0060-61, subscribers receive “notifications” sent by publishers (via a memory broker 170) to inform subscribers of events (e.g., including a write operation from a publisher; see ¶0065) associated with a given topic (i.e., associated with a given shared buffer ring; see ¶0039),
in response to the message, performing, by the second processor, a polling process to determine ownership of the data (“The wait queue of processes may include subscribers waiting for a notification of a new write operation to a buffer … For example, the futex system call may be used to send a notification to subscribers of a buffer ring when a value of a buffer counter corresponding to a buffer in the buffer ring is even” [0065] // ”During a read operation to the buffer, a subscriber begins a read by reading (and storing a local copy of) the value of the buffer counter” [0054]) – As disclosed in ¶0054, before reading data from the shared buffer ring, subscribers first read the counter value associated with the message to be read. Examiner considers a subscriber reading a counter associated with a message in a shared buffer ring as the subscriber “start[ing] a polling process” to determine whether a write operation is currently in progress and thus to determine whether the subscriber can access the data in the buffer (i.e., “to determine the ownership of the data”)—;
in response to the polling process having determined that the ownership corresponds to the second processor, copying, by the second processor, the data from the third buffer in the third memory to (“If the value of the buffer counter is odd, the subscriber determines that a write operation is in progress and waits for notification that the write operation is completed … before reading data from the buffer. If the value of the buffer is even, the subscriber proceeds to read the data stored in the buffer” [0054]) – As clarified in ¶0054, after a subscriber determines that the associated counter value is even, the subscriber reads the data from the shared buffer ring.
Witham and Nortman are considered analogous to the claimed invention because they all relate to the same field of establishing publisher and subscriber schemes for data transmission between remote nodes in systems which comprise memory shared between remote nodes. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Witham with the teachings of Nortman and realize a computing system whereby a subscriber performs polling of data ownership prior to reading the data from a memory shared between producers and consumers. Subscribers polling for data ownership prior to reading data from a shared memory reduces network traffic as compared to traditional point-to-point messaging paradigms whereby subscribers continually query shared memory for events as opposed to polling solely for data ownership associated with an event, as disclosed in Nortman ¶0061: “The publish/subscribe scheme is therefore more flexible than other communication paradigms, because publishers and subscribers can be started and stopped asynchronously. Furthermore, the event notification are sent to the subscribes or publishers rather than them querying for updates. This results in a reduction of network traffic.” [0061]
The combined teachings of Witham and Nortman additionally disclose the following limitations:
generating, by the second processor, a reply (Nortman, “Multiple publishers may write messages to a buffer ring, and multiple subscribers may read data from a buffer ring” [0045] // Figs. 1 + 6 // ¶¶0038-39; 0122) -- As taught in Nortman ¶0045, multiple publishers and multiple subscribers publish and read messages from the same shared buffer ring 120. As disclosed in Nortman: Each node (e.g., 602n and 602b) in a network can include both publishers and subscribers (Fig. 6; ¶0122); and Each publisher and subscriber can access a number of topics, with each shared buffer ring corresponding to a particular topic (¶¶0038-39). One of ordinary skill in the art would accordingly understand that two nodes (e.g., 602n and 602b; i.e., associated with “the first processor” and “the second processor”, respectively) could each contain both a publisher and a subscriber which access the same given topic. In such an embodiment, publishers and subscribers operating on both nodes 602n and 602b would be publishing messages to and reading messages from the same shared ring buffer 120 (e.g., located on Node 601a). In such an embodiment, a publisher located on node 602b can write messages into shared buffer ring 120 both before and after reading messages from the shared buffer ring 120, which examiner considers as “the second processor” (i.e., the processor which subscribes to a given topic) “generat[ing] a reply” (i.e., publishing a message to the same buffer where a previous message was read)--
by modifying the data in the second buffer in the second memory (Nortman, Fig. 3 // “The LiDAR processing system 311 processes data read from buffer rings 302(a) and 302(b) and publishes it to buffer ring 303” [0045]) – As shown in Nortman Fig. 3 and taught in ¶0045, publishers publish data specifically to a buffer ring in memory (i.e., “modifying the data in the second buffer in the second memory”)--; and
writing the modified data from the second buffer in the second memory to the third buffer in the third memory (Nortman, Fig. 3, ¶0045) – As discussed above, publishers publish data to a buffer ring and subscribers similarly read data from a buffer ring--,
wherein the first processor performs another polling process to determine ownership of the modified data (Nortman, ¶0054) – As previously discussed (see Claim 8 limitation mappings above), a subscriber reads the buffer counter from the header of a message in order to determine whether or not an associated write operation is complete (i.e., a “polling process to determine the ownership”). In this case, examiner considers a subscriber on node 602n reading a buffer counter as “another polling process” (i.e., this time performed by “the first processor”)--; and
wherein in response to the another polling process having determined that the ownership of the modified data corresponds to the first processor, the first processor copies the modified data from the third buffer in the third memory to the first buffer in the first memory. (Nortman, Fig. 3 // ¶¶0045;0054) – As previously discussed and as taught in Nortman ¶0054, a subscriber reads data from the shared ring buffer only after determining that the associated buffer counter has an even value.
Regarding Claim 18,
The same motivation to combine provided in Claim 16 is equally applicable to Claim 18. The combined teachings of Witham and Nortman disclose the following limitations:
The method of claim 16, wherein receiving the message comprises receiving the message, by the second processor, as an interrupt from hardware (Nortman, Memory Broker 170, Fig. 1 // ¶¶0060-61) of the third memory (Nortman, “the event notification are sent to subscribers or publishers rather than them querying for updates” [0061]) – As previously discussed (see Claim 16 limitation mappings above) and as taught in Nortman, Memory Broker 170 (coupled to shared buffer ring 120a (see Fig. 1); i.e., “hardware of the third memory”) notifies a subscriber of new messages via a new write notification. As clarified in Nortman ¶0061, notifications sent by the memory broker to subscribers are received by the subscriber without requiring a query from the subscriber. Examiner accordingly considers such type of notification as “an interrupt”.
Regarding Claim 19,
The same motivation to combine provided in Claim 16 is equally applicable to Claim 20. The combined teachings of Witham and Nortman disclose the following limitations:
The method of claim 16, wherein writing the modified data from the second buffer in the second memory to the third buffer in the third memory comprises:
bypassing, by the second processor, a cache (Witham, Fig. 2) in the second computer by directly writing as a single unit, the modified data (Witham, “the interface has a direct memory access (DMA) channel, enabling direct access to shared memory 212 from the interface driver to the optical communication link. The DMA access enables the interface to bypass the program hierarchy and send the data from the message directly to the cache controller” [0051]) – As shown in Witham Fig. 2 and taught in ¶0051, DMA enables data to be directly written into shared memory, thereby bypassing memory of the program hierarchy (e.g., stack 224 + heap 226; i.e., “bypass a cache”)--
and a bit value (Nortman, “a header” [0046] // ¶0005) that indicates the ownership of the modified data, from the second buffer in the second memory to the third buffer in the third memory (Nortman, “each buffer 121 a-n of a buffer ring 120 may include a header 122 and a data portion 123” [0046]) – As taught in Nortman ¶0046, message data and the corresponding header (e.g., including the buffer counter (see Nortman ¶0005); i.e., including “a bit value” indicating ownership) are both written into the same buffer 121 of ring buffer 120 (i.e., “as a single unit”)
Regarding Claim 20,
The same motivation to combine provided in Claim 16 is equally applicable to Claim 20. The combined teachings of Witham and Nortman disclose the following limitations:
The method of claim 16, further comprising:
receiving, by the second computer from the first computer, another message (Nortman, “the publisher sets the value of the counter to 0” [0049]) to inform the second processor that the first processor is finished writing to the third buffer in the third memory (Nortman, “The value of the buffer counter … is odd during a write operation to a buffer and even when no write operation is in progress” [0053]) – As previously discussed (see Claim 16 limitation mappings above), a publisher sets ownership of data in a shared ring buffer by updating a counter value to an even value after completing a write operation. In this case, examiner considers a publisher setting the counter value to an even value once the write operation in complete as the publisher sending “another message” (i.e., different from the notification sent by Memory Broker 170) to the subscriber to inform the subscriber that the write operation is complete--; and
ending, by the second processor, the polling process in response to the another message (Nortman, “If the value of the buffer is even, the subscriber proceeds to read the data stored in the buffer” [0054]) – As previously discussed (see Claim 16 limitation mappings above), after reading an even counter value, the subscriber reads data stored in the shared ring buffer (i.e., effectively “ending” the wait for a completed write operation)--.
Claims 4, 11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Witham further in view of Nortman and Ostrovsky et al. (US 20130067160 A1)(hereafter referred to as Ostrovsky).
Regarding Claim 4,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 4. The combined teachings of Witham and Nortman disclose the following limitations:
The computing system of claim 1 (see Claim 1 limitation mappings above), wherein to perform the polling process, the second processor is configured to:
… a location in the third buffer in the third memory where the data is written (Nortman, “local read position” [0051] // ¶0056) – As taught in Nortman ¶¶0051 and 0056, subscribers employ “local read positions” (i.e., “location[s] in the third buffer”) to keep track of when data is accessible--;
read a bit value to determine the ownership (Nortman, “During a read operation to the buffer, a subscriber begins a read by reading (and storing a local copy of) the value of the buffer counter … After the read operation is complete, the subscriber reads the buffer counter at the corresponding synchronization region a second time, and compares the value to the locally stored value of the buffer counter obtained at the start of the read operation.” [0054]) – As previously discussed and taught in Nortman ¶0054, as part of the polling process, a subscriber reads a counter value (i.e., “a bit value”) from the shared memory buffer and subsequently stores the counter value locally for comparison to determine ownership--; and
in response to determination that the ownership corresponds to the first processor, repeat the polling process including … reading the bit value (Nortman, “During a read operation to the buffer, a subscriber begins a read by reading … the value of the buffer counter … If the value of the buffer counter is odd, the subscriber determines that the write operation is in progress and waits for notification that the write operation is completed” [0054] // ¶0061) – As taught in Nortman ¶0054, after determining that the buffer counter is odd (i.e., “ownership corresponds to the first processor”) a subscriber awaits a further notification (e.g., from Memory Broker 170 that a new message is received; see ¶0061) after which the subscriber again reads the value of the buffer counter. Examiner considers this process as “repeat[ing] the polling process” (i.e., until the counter is read as even by the subscriber)--; and
in response to determination that the ownership corresponds to the first processor, end the polling process (Nortman, ¶¶0054; 0061) – Examiner considers the aforementioned process of a subscriber being notified of a new message from a memory broker and reading an odd buffer counter value as both “repeat[ing]” and “end[ing] the polling process” (e.g., ending a first poll and then repeating the polling process by performing a second poll).
Although Nortman ¶0051 discloses that subscribers additionally uses a “local read position” in order to determine when data in the shared memory buffer is available (i.e., during the polling process), and Nortman ¶0056 discloses that each subscriber maintains current read positions for a buffer locally irrespective of other subscribers, the combined teachings of Witham and Nortman do not explicitly disclose the following limitations:
flush a cache line at the second computer that corresponds to a location in the third buffer in the third memory where the data is written;
repeat the polling process including flushing the cache line
However, Ostrovsky discloses the following limitations:
flush a cache line (¶¶0014; 0041) at the second computer (“store a local copy of the tail pointer” [0041]) that corresponds to a location (“a storage location … where a next enqueue operation is to store a new value” [0028]) in the third buffer in the third memory (Circular Queue 200, Fig. 6 // Fig. 2) where the data is written (“One embodiment of piecewise circular queue 200 addresses this problem by having the consumer thread read the tail pointer and then store a local copy of the tail pointer” [0041] // “A tail pointer 208 points at a storage location 204e where a next enqueue operation is to store a new value” [0028] // Fig. 2) – As shown in Ostrovsky Fig. 2, producers and consumers each access the same shared memory queue, similar to how publishers and subscribers of Nortman Fig. 1 each access the same shared buffer ring 120a. Examiner accordingly considers Circular Queue 200 of Ostrovsky Fig. 6 as analogous to shared buffer ring 120a of Nortman Fig. 1 (i.e., “the third buffer in the third memory”). As taught Ostrovsky ¶¶0028 and 0041, each time a consumer accesses circular queue 200, the consumer first reads and stores an associated tail pointer in a local cache, similar to how subscribers of Nortman use local read positions before a shared buffer ring access to determine whether data is accessible (see ¶0051). As clarified in Ostrovsky ¶¶0014 and 0041, tail pointers are stored locally in cache (“a cache miss” [0041]). Examiner accordingly considers the process of reading and storing locally a copy of a tail pointer before a shared memory queue access as “flushing a cache line” (e.g., overwriting a previous tail pointer value in a local cache) associated with a position in circular queue 200--; …
repeat the polling process including flushing the cache line – One of ordinary skill in the art would understand that the aforementioned process of storing tail pointers locally by consumers would take place each time a consumer accesses the third buffer (i.e., for each “polling process”)
Witham, Nortman, and Ostrovsky are all considered analogous to the claimed invention because they all relate to the same field of access control to a shared memory buffer in a publisher/subscriber type of networking environments. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Witham and Nortman with the teachings of Ostrovsky and realize a processor which performs a cache line flush during a polling process to a shared memory buffer. Doing so is an optimized solution to overcome cache misses which result from consumers and producers concurrently accessing the same memory values, improving performance on modern computing devices, as disclosed in Ostrovsky ¶¶0040-41: “The consumer thread read of the tail pointer in the dequeue operation results in a cache miss, because one computational core (i.e., the consumer thread) is reading a memory value that was just modified by another computational core (i.e., the producer thread). Consequently, the computational core reading the value cannot simply obtain the value from its own cache, because the cached version is now invalid. A cache miss results in a significant performance hit on modern computing device architectures. One embodiment of piecewise circular queue 200 addresses this problem by having the consumer thread read the tail pointer and then store a local copy of the tail pointer.” [0040-41]
Regarding Claim 11,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 11. The combined teachings of Witham and Nortman disclose the following limitations:
The method of claim 8 (see Claim 8 limitation mappings above), wherein to perform the polling process, the second processor performs:
… a location in the third buffer in the third memory where the data is written (Nortman, “local read position” [0051] // ¶0056) – As taught in Nortman ¶¶0051 and 0056, subscribers employ “local read positions” (i.e., “location[s] in the third buffer”) to keep track of when data is accessible--;
reading an ownership value to determine the ownership (Nortman, “During a read operation to the buffer, a subscriber begins a read by reading (and storing a local copy of) the value of the buffer counter … After the read operation is complete, the subscriber reads the buffer counter at the corresponding synchronization region a second time, and compares the value to the locally stored value of the buffer counter obtained at the start of the read operation.” [0054]) – As previously discussed and taught in Nortman ¶0054, as part of the polling process, a subscriber reads a counter value (i.e., “an ownership value”) from the shared memory buffer and subsequently stores the counter value locally for comparison to determine ownership--; and
in response to determining that the ownership corresponds to the first processor, repeating the polling process including … reading the ownership value (Nortman, “During a read operation to the buffer, a subscriber begins a read by reading … the value of the buffer counter … If the value of the buffer counter is odd, the subscriber determines that the write operation is in progress and waits for notification that the write operation is completed” [0054] // ¶0061) – As taught in Nortman ¶0054, after determining that the buffer counter is odd (i.e., “ownership corresponds to the first processor”) a subscriber awaits a further notification (e.g., from Memory Broker 170 that a new message is received; see ¶0061) after which the subscriber again reads the value of the buffer counter. Examiner considers this process as “repeating the polling process” (i.e., until the counter is read as even by the subscriber)--; and
in response to determining that the ownership corresponds to the first processor, ending the polling process (Nortman, ¶¶0054; 0061) – Examiner considers the aforementioned process of a subscriber being notified of a new message from a memory broker and reading an odd buffer counter value as both “repeat[ing]” and “end[ing] the polling process” (e.g., ending a first poll and then repeating the polling process by performing a second poll).
Although Nortman ¶0051 discloses that subscribers additionally uses a “local read position” in order to determine when data in the shared memory buffer is available (i.e., during the polling process), and Nortman ¶0056 discloses that each subscriber maintains current read positions for a buffer locally irrespective of other subscribers, the combined teachings of Witham and Nortman do not explicitly disclose the following limitations:
flushing a cache line at the second computer that corresponds to a location in the third buffer in the third memory where the data is written;
repeating the polling process including flushing the cache line
However, Ostrovsky discloses the following limitations:
flushing a cache line (¶¶0014; 0041) at the second computer (“store a local copy of the tail pointer” [0041]) that corresponds to a location (“a storage location … where a next enqueue operation is to store a new value” [0028]) in the third buffer in the third memory (Circular Queue 200, Fig. 6 // Fig. 2) where the data is written (“One embodiment of piecewise circular queue 200 addresses this problem by having the consumer thread read the tail pointer and then store a local copy of the tail pointer” [0041] // “A tail pointer 208 points at a storage location 204e where a next enqueue operation is to store a new value” [0028] // Fig. 2) – As shown in Ostrovsky Fig. 2, producers and consumers each access the same shared memory queue, similar to how publishers and subscribers of Nortman Fig. 1 each access the same shared buffer ring 120a. Examiner accordingly considers Circular Queue 200 of Ostrovsky Fig. 6 as analogous to shared buffer ring 120a of Nortman Fig. 1 (i.e., “the third buffer in the third memory”). As taught Ostrovsky ¶¶0028 and 0041, each time a consumer accesses circular queue 200, the consumer first reads and stores an associated tail pointer in a local cache, similar to how subscribers of Nortman use local read positions before a shared buffer ring access to determine whether data is accessible (see ¶0051). As clarified in Ostrovsky ¶¶0014 and 0041, tail pointers are stored locally in cache (“a cache miss” [0041]). Examiner accordingly considers the process of reading and storing locally a copy of a tail pointer before a shared memory queue access as “flushing a cache line” (e.g., overwriting a previous tail pointer value in a local cache) associated with a position in circular queue 200--;
repeating the polling process including flushing the cache line -- One of ordinary skill in the art would understand that the aforementioned process of storing tail pointers locally by consumers would take place each time a consumer accesses the third buffer (i.e., for each “polling process”)
Witham, Nortman, and Ostrovsky are all considered analogous to the claimed invention because they all relate to the same field of access control to a shared memory buffer in a publisher/subscriber type of networking environments. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Witham and Nortman with the teachings of Ostrovsky and realize a processor which performs a cache line flush during a polling process to a shared memory buffer. Doing so is an optimized solution to overcome cache misses which result from consumers and producers concurrently accessing the same memory values, improving performance on modern computing devices, as disclosed in Ostrovsky ¶¶0040-41: “The consumer thread read of the tail pointer in the dequeue operation results in a cache miss, because one computational core (i.e., the consumer thread) is reading a memory value that was just modified by another computational core (i.e., the producer thread). Consequently, the computational core reading the value cannot simply obtain the value from its own cache, because the cached version is now invalid. A cache miss results in a significant performance hit on modern computing device architectures. One embodiment of piecewise circular queue 200 addresses this problem by having the consumer thread read the tail pointer and then store a local copy of the tail pointer.” [0040-41]
Regarding Claim 17,
The same motivation to combine provided in Claim 16 is equally applicable to Claim 17. The combined teachings of Witham and Nortman disclose the following limitations:
The method of claim 16 (see Claim 16 limitation mappings above), wherein performing the polling process comprises:
… a location in the third buffer in the third memory where the data is written (Nortman, “local read position” [0051] // ¶0056) – As taught in Nortman ¶¶0051 and 0056, subscribers employ “local read positions” (i.e., “location[s] in the third buffer”) to keep track of when data is accessible--;
reading, by the second processor, a bit value to determine the ownership (Nortman, “During a read operation to the buffer, a subscriber begins a read by reading (and storing a local copy of) the value of the buffer counter … After the read operation is complete, the subscriber reads the buffer counter at the corresponding synchronization region a second time, and compares the value to the locally stored value of the buffer counter obtained at the start of the read operation.” [0054]) – As previously discussed and taught in Nortman ¶0054, as part of the polling process, a subscriber reads a counter value (i.e., “a bit value”) from the shared memory buffer and subsequently stores the counter value locally for comparison to determine ownership--; and
in response to determining that the ownership corresponds to the first processor, repeating, by the second processor, the polling process including … reading the bit value (Nortman, “During a read operation to the buffer, a subscriber begins a read by reading … the value of the buffer counter … If the value of the buffer counter is odd, the subscriber determines that the write operation is in progress and waits for notification that the write operation is completed” [0054] // ¶0061) – As taught in Nortman ¶0054, after determining that the buffer counter is odd (i.e., “ownership corresponds to the first processor”) a subscriber awaits a further notification (e.g., from Memory Broker 170 that a new message is received; see ¶0061) after which the subscriber again reads the value of the buffer counter. Examiner considers this process as “repeating the polling process” (i.e., until the counter is read as even by the subscriber)--; and
in response to determining that the ownership corresponds to the first processor, ending, by the second processor, the polling process (Nortman, ¶¶0054; 0061) – Examiner considers the aforementioned process of a subscriber being notified of a new message from a memory broker and reading an odd buffer counter value as both “repeat[ing]” and “end[ing] the polling process” (e.g., ending a first poll and then repeating the polling process by performing a second poll).
Although Nortman ¶0051 discloses that subscribers additionally uses a “local read position” in order to determine when data in the shared memory buffer is available (i.e., during the polling process), and Nortman ¶0056 discloses that each subscriber maintains current read positions for a buffer locally irrespective of other subscribers, the combined teachings of Witham and Nortman do not explicitly disclose the following limitations:
flushing, by the second processor, a cache line at the second computer that corresponds to a location in the third buffer in the third memory where the data is written;
repeating, by the second processor, the polling process including flushing the cache line
However, Ostrovsky discloses the following limitations:
flushing, by the second processor, a cache line (¶¶0014; 0041) at the second computer (“store a local copy of the tail pointer” [0041]) that corresponds to a location (“a storage location … where a next enqueue operation is to store a new value” [0028]) in the third buffer in the third memory (Circular Queue 200, Fig. 6 // Fig. 2) where the data is written (“One embodiment of piecewise circular queue 200 addresses this problem by having the consumer thread read the tail pointer and then store a local copy of the tail pointer” [0041] // “A tail pointer 208 points at a storage location 204e where a next enqueue operation is to store a new value” [0028] // Fig. 2) – As shown in Ostrovsky Fig. 2, producers and consumers each access the same shared memory queue, similar to how publishers and subscribers of Nortman Fig. 1 each access the same shared buffer ring 120a. Examiner accordingly considers Circular Queue 200 of Ostrovsky Fig. 6 as analogous to shared buffer ring 120a of Nortman Fig. 1 (i.e., “the third buffer in the third memory”). As taught Ostrovsky ¶¶0028 and 0041, each time a consumer accesses circular queue 200, the consumer first reads and stores an associated tail pointer in a local cache, similar to how subscribers of Nortman use local read positions before a shared buffer ring access to determine whether data is accessible (see ¶0051). As clarified in Ostrovsky ¶¶0014 and 0041, tail pointers are stored locally in cache (“a cache miss” [0041]). Examiner accordingly considers the process of reading and storing locally a copy of a tail pointer before a shared memory queue access as “flushing a cache line” (e.g., overwriting a previous tail pointer value in a local cache) associated with a position in circular queue 200--; …
repeating, by the second processor, the polling process including flushing the cache line One of ordinary skill in the art would understand that the aforementioned process of storing tail pointers locally by consumers would take place each time a consumer accesses the third buffer (i.e., for each “polling process”)
Witham, Nortman, and Ostrovsky are all considered analogous to the claimed invention because they all relate to the same field of access control to a shared memory buffer in a publisher/subscriber type of networking environments. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Witham and Nortman with the teachings of Ostrovsky and realize a processor which performs a cache line flush during a polling process to a shared memory buffer. Doing so is an optimized solution to overcome cache misses which result from consumers and producers concurrently accessing the same memory values, improving performance on modern computing devices, as disclosed in Ostrovsky ¶¶0040-41: “The consumer thread read of the tail pointer in the dequeue operation results in a cache miss, because one computational core (i.e., the consumer thread) is reading a memory value that was just modified by another computational core (i.e., the producer thread). Consequently, the computational core reading the value cannot simply obtain the value from its own cache, because the cached version is now invalid. A cache miss results in a significant performance hit on modern computing device architectures. One embodiment of piecewise circular queue 200 addresses this problem by having the consumer thread read the tail pointer and then store a local copy of the tail pointer.” [0040-41]
Response to Arguments
The previous Objection to Claim 8 is withdrawn.
The previous 35 U.S.C. 112(b) rejections of Claims 16-20 are withdrawn.
Applicant’s arguments with respect to claims 1-20 have been considered but are moot in view of the newly-identified Witham reference because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, 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 JULIAN SCOTT MENDEL whose telephone number is (703)756-1608. The examiner can normally be reached M-F 10am - 4pm 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, Rocío del Mar Pérez-Vélez can be reached at 571-270-5935. 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.
/J.S.M./Examiner, Art Unit 2133
/ROCIO DEL MAR PEREZ-VELEZ/Supervisory Patent Examiner, Art Unit 2133
Prosecution Insights