DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The Office Action is in response to claims filed 10/22/2025.
Claims 1-20 are pending.
Claim Objections
Claims 17-20 objected to because of the following informalities: Claim 17 recites the limitation "the node" in line 2. There is insufficient antecedent basis for this limitation in the claim. Claim 18-20 are also objected to by virtue of their dependence on claim 17. For the purposes of compact prosecution, Examiner interprets the method to be performed with “a node.” Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 11-16 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, an abstract idea, and it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claims 11-16 are directed to a method and fall within the statutory category of process. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
Step 2A Prong 1:
Claim 11: The limitations “determining that the resource at the node is unlocked” is a mental process. Determining that the resource at the node is unlocked involves observing the resource and node and then forming a judgement as to whether the resource is unlocked or not. It is understood that these limitations are to be performed within a computer environment, however, the limitations can also be performed entirely in the mind.
Therefore, Yes, Claim 11 recite a judicial exception. Step 2A Prong 2 will evaluate whether the claims integrate the judicial exception into a practical application.
Step 2A Prong 2:
Claim 11: The judicial exception is not integrated into a practical application. Claim 11 recites the following additional elements – “receiving a lock request for a resource at a node in a network from an application at a lock manager,” and “issuing the lock to the application from the lock manager.” These limitations are considered insignificant extra-solution activity of data gathering and data transmission (MPEP § 2106.05(g)). Claim 11 additionally recites “storing a lock at the lock manager, the lock associated with the resource at the node and the application, the lock locking the resource” and “setting a status for the lock to active at the lock manager […] wherein an active status for the lock identifies that the application shall actively use the resource that is locked an inactive status for the lock identifies that the application shall not actively use the resource that is locked.” These limitations are insignificant extra-solution activity of data storage (MPEP § 2106.05(g)). These additional elements do not integrate the judicial exception into a practical application.
Therefore, “Do the claims recite additional elements that integrate the judicial exception in a practical application?” No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
After having evaluated the inquiries set forth in Steps 2A Prong 1 and 2, it has been concluded that Claim 11 not only recite a judicial exception but that the claims are directed to the judicial exception as the judicial exception has not been integrated into practical application.
Step 2B:
Claim 11: The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above, the additional elements only amount to insignificant extra solution activity of data gathering, data transmission, and data storage. When reevaluating the claim limitations, alone or in combination, no inventive concept that amounts to significantly more was found. When reevaluating the insignificant extra-solution activities for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well understood, routine, and conventional computer function. MPEP § 2106.05(d)(II) lists that “Storing and retrieving information in memory” is a well understood, routine, and conventional computer function.
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, Claim 11 does not recite eligible subject matter under 35 U.S.C. § 101.
With regard to claim(s) 12, it recites “further comprising sending the lock and the status for the lock from the lock manager to the node.” This limitation is insignificant extra-solution activity of data transmission (MPEP § 2106.05(g)). It does not integrate the judicial exception into a practical application, so the claim(s) fail Step 2A Prong 2. When reevaluating the claim limitations, alone or in combination, no inventive concept that amounts to significantly more was found. When reevaluating the insignificant extra-solution activities for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well understood, routine, and conventional computer function. Therefore, the claim(s) fail Step 2B. Therefore, claim(s) 12 do/does not recite patent eligible subject matter under 35 U.S.C. 101.
With regard to claim(s) 13, it recites “further comprising: receiving a request for the lock from the application at the lock manager” and “updating the status for the lock at the lock manager based at least in part on the request.” These limitations are insignificant extra-solution activities of data gathering and data storage respectively (MPEP § 2106.05(g)). It does not integrate the judicial exception into a practical application, so the claim(s) fail Step 2A Prong 2. When reevaluating the claim limitations, alone or in combination, no inventive concept that amounts to significantly more was found. When reevaluating the insignificant extra-solution activities for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well understood, routine, and conventional computer function. MPEP § 2106.05(d)(II) lists that “Storing and retrieving information in memory” is a well understood, routine, and conventional computer function. Therefore, the claim(s) fail Step 2B. Therefore, claim(s) 13 do/does not recite patent eligible subject matter under 35 U.S.C. 101.
With regard to claim(s) 14, it recites “further comprising sending the status for the lock from the lock manager to the node.” This limitation is insignificant extra-solution activity of data transmission (MPEP § 2106.05(g)). It does not integrate the judicial exception into a practical application, so the claim(s) fail Step 2A Prong 2. When reevaluating the claim limitations, alone or in combination, no inventive concept that amounts to significantly more was found. When reevaluating the insignificant extra-solution activities for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well understood, routine, and conventional computer function. Therefore, the claim(s) fail Step 2B. Therefore, claim(s) 14 do/does not recite patent eligible subject matter under 35 U.S.C. 101.
With regard to claim(s) 15, it recites “further comprising: receiving an activation request for the lock from the application at the lock manager” and “updating the status for the lock to active at the lock manager.” These limitations are insignificant extra-solution activities of data gathering and data storage respectively (MPEP § 2106.05(g)). It does not integrate the judicial exception into a practical application, so the claim(s) fail Step 2A Prong 2. When reevaluating the claim limitations, alone or in combination, no inventive concept that amounts to significantly more was found. When reevaluating the insignificant extra-solution activities for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well understood, routine, and conventional computer function. MPEP § 2106.05(d)(II) lists that “Storing and retrieving information in memory” is a well understood, routine, and conventional computer function. Therefore, the claim(s) fail Step 2B. Therefore, claim(s) 15 do/does not recite patent eligible subject matter under 35 U.S.C. 101.
With regard to claim(s) 16, it recites “further comprising sending the status for the lock from the lock manager to the node.” This limitation is insignificant extra-solution activity of data transmission (MPEP § 2106.05(g)). It does not integrate the judicial exception into a practical application, so the claim(s) fail Step 2A Prong 2. When reevaluating the claim limitations, alone or in combination, no inventive concept that amounts to significantly more was found. When reevaluating the insignificant extra-solution activities for an inventive concept that is significantly more, the claims do not add an inventive concept that is other than what is well understood, routine, and conventional in the field. MPEP § 2106.05(d)(II) lists that “Receiving or transmitting data over a network” is a well understood, routine, and conventional computer function. Therefore, the claim(s) fail Step 2B. Therefore, claim(s) 16 do/does not recite patent eligible subject matter under 35 U.S.C. 101.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-3 is/are rejected under 35 U.S.C. 102 as being unpatentable over Holland Pat. No. US 20030187860 A1 (hereafter Holland).
With regard to claim 1, Holland teaches a system, comprising (¶ [0009] states “the present invention contemplates a method of updating data contained in a file object stored in an object-based distributed data storage system.”):
a node including a resource (¶ [0024] states “An OBSD or OBD 12 is a physical disk drive that stores data files in the network-based system 10.” ¶ [0025] states “The fundamental abstraction exported by an OBD 12 is that of an "object," which may be defined as a variably-sized ordered collection of bits.” ¶ [0027] states “The OBDs, clients, managers, etc., may be considered as "[nodes]" on the network 28.”);
and a lock manager executing on a processor, the lock manager including storage for a data structure for a lock, the lock locking the resource, the data structure including a first identifier for the resource, a second identifier for an application, and a status for the lock (¶ [0044] states “The three software components, as illustrated in FIG. 3, are: the client application program (CAP), the client lock manager (CLM), and the storage manager lock manager (SMLM). In FIG. 3, a client computer 34 (which may be a computer similar to the clients 24, 26 in FIGS. 1 and 2) is shown with three CAPs 36, 38, 40 and a CLM 42 running on it.” ¶ [0046] states “each of the CLM 42 and the SMLM 46 may internally maintain a corresponding lock table to manage lock-related transactions.” ¶ [0046] states “the lock table maintained by the CLM 42 may contain a record of the identity of the CAP (the CAP# column in FIG. 3) that has been granted a lock, the object_ID (the object # column in FIG. 3) of the object being accessed by the CAP, and the byte-range over which the lock has been granted to the CAP. Although not shown in FIG. 3, some additional information in the CLM lock table may include, per entry, an indication whether the corresponding lock is held active or inactive (as discussed below) and whether the lock is for a data read operation or a data write operation.” Examiner’s Note: the object ID is the first identifier for the resource. The identity of the CAP is the second identifier for an application. The indication of whether the lock is held active or inactive is the status of the lock),
wherein an active status for the lock identifies that the application shall actively use the resource that is locked and an inactive status for the lock identifies that the application shall not actively use the resource that is locked (¶ [0049] states “A lock in the CLM's lock table may be held "active," i.e., the lock is currently held by the client 34 and some CAP 36-40 is actively using the lock; or, the lock may be held "inactive," i.e., the lock is currently held by the client 34 but no CAP 36-40 is actively using the lock.”).
With regard to claim 2, Holland teach the system according to claim 1. Holland additionally teaches wherein the status for the lock is active (¶ [0049] states “A lock in the CLM's lock table may be held "active," i.e., the lock is currently held by the client 34 and some CAP 36-40 is actively using the lock; or, the lock may be held "inactive," i.e., the lock is currently held by the client 34 but no CAP 36-40 is actively using the lock.” ¶ [0049] additionally states “if a held-inactive lock "subsumes" the requested lock (i.e., if the requested lock's byte-range falls under the byte-range allocated to the held-inactive lock), then the CLM 42 grants the requested lock and marks the lock as held "active" of the appropriate type (R or W lock).”).
With regard to claim 3, Holland teaches the system according to claim 1. Holland additionally teaches wherein the lock manager is configured to update the status for the lock to an updated status for the lock based on a request from the application (¶ [0049] states “Upon receiving the lock request from a CAP 36-40, the CLM 42 scans its lock table” and “if a held-inactive lock "subsumes" the requested lock (i.e., if the requested lock's byte-range falls under the byte-range allocated to the held-inactive lock), then the CLM 42 grants the requested lock and marks the lock as held "active" of the appropriate type (R or W lock).”).
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.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Holland in view of Jenkins Pat. No. US 20140365549 A1 (hereafter Jenkins).
With regard to claim 4, Holland teaches the system according to claim 3. Holland does not explicitly teach the lock manager including an API.
However, in an analogous art, Jenkins teaches wherein the lock manager includes an Application Programming Interface (API) to receive the request from the application to update the status for the lock (Abstract states “A distributed lock manager (DLM) may be implemented in a distributed computing system… The DLM may expose an API to clients, allowing them to make local calls to a DLM component on the same node to perform various lock management operations. The meanings of the lock values may be established by their use in client applications.” ¶ [0053] states “By making local API calls to invoke various lock management operations (e.g., operations to create a lock, specify one or more properties of a lock, obtain a list of locks, subscribe to a lock, acquire a lock, release a lock or delete a lock), the components of the client application may participate in the locks managed by the DLM.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the API that let clients invoke management operations on locks managed by the DLM of Jenkins with the client lock manager of Holland. As a result, the client lock manager has an API that can be accessed by the client application program. The client application program of Holland is analogous to the client of Jenkins. The lock request of Holland is a management operation that can be exposed via the API of Jenkins. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of “managing large-scale computing resources for many clients with diverse needs, allowing various computing resources to be efficiently and securely shared by multiple clients” (¶ [0002]).
Claim(s) 5-18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Holland in view of Zumach et al. Pat. No. US 9542414 B1 (hereafter Zumach).
With regard to claim 5, Holland teaches the system according to claim 3. Holland additionally teaches wherein the lock manager is configured to send the updated status for the lock to the node (¶ [0049] states “Otherwise, if a held-inactive lock "subsumes" the requested lock (i.e., if the requested lock's byte-range falls under the byte-range allocated to the held-inactive lock), then the CLM 42 grants the requested lock and marks the lock as held "active" of the appropriate type (R or W lock).”).
Holland does not explicitly teach that the lock manager is configured to send the updated status for the lock to the node.
However, in an analogous art, Zumach teaches wherein the lock manager is configured to send the updated status for the lock to the node (Col. 9 Lines 56-60 states “At step 504, the lock manager 301A modifies, adds, or deletes lock state of the lock associated with the data container, at the local memory of node 102A according to the instruction. At step 506, the lock manager 301A determines whether the lock needs to be mirrored.” Col. 10 Lines 8-10 states “If local or partner mirroring is needed, then the necessary lock state information for mirroring is extracted from an original lock data structure at step 510.” Col. 10 Lines 35-37 states “then at step 518, the lock state information (e.g. metadata in fields' 305A-305F) is sent by node 102A to node 102B.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the mirroring of lock information of Zumach with the granting of a lock of Holland. As a result, when the lock manager grants a lock, it can then send a copy of the lock state to the node. The lock status is part of the lock, so sending the lock state includes sending the lock status. In the combination, the node of Zumach and the OBD node of Holland are the same node. A person having ordinary skill in the art would have been motivated to make this combination because “there are times when a cluster needs to reconstruct data structures for locks, based on the mirrored lock data structures stored in a memory of a node” (Col. 9 Lines 31-34). An example is when a first node fails and a second node can service requests involving locks on the first node (Col. 2 Lines 11-16 states “When a first node fails, a second node can takeover storage of the first node and retrieve information of the locks for the storage from the shared memory. Thus, the second node can continue to service data requests for the taken-over storage and maintain access rights of the taken-over storage controlled by the locks.” See also Col. 8 Lines 22-34). By doing so, the cluster can maintain high availability.
With regard to claim 6, Holland teaches the system according to claim 1. Holland does not explicitly teach the lock manager sending the data structure to the node.
However, in an analogous art, Zumach teaches wherein the lock manager is configured to send the data structure to the node (Col. 9 Lines 56-60 states “At step 504, the lock manager 301A modifies, adds, or deletes lock state of the lock associated with the data container, at the local memory of node 102A according to the instruction. At step 506, the lock manager 301A determines whether the lock needs to be mirrored.” Col. 10 Lines 8-10 states “If local or partner mirroring is needed, then the necessary lock state information for mirroring is extracted from an original lock data structure at step 510.” Col. 10 Lines 35-37 states “then at step 518, the lock state information (e.g. metadata in fields' 305A-305F) is sent by node 102A to node 102B.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the mirroring of lock information of Zumach with the granting of a lock of Holland. As a result, when the lock manager grants a lock, it can then send a copy of the lock state to the node. A person having ordinary skill in the art would have been motivated to make this combination because “there are times when a cluster needs to reconstruct data structures for locks, based on the mirrored lock data structures stored in a memory of a node” (Col. 9 Lines 31-34). An example is when a first node fails and a second node can service requests involving locks on the first node (Col. 2 Lines 11-16 states “When a first node fails, a second node can takeover storage of the first node and retrieve information of the locks for the storage from the shared memory. Thus, the second node can continue to service data requests for the taken-over storage and maintain access rights of the taken-over storage controlled by the locks.” See also Col. 8 Lines 22-34). By doing so, the cluster can maintain high availability.
With regard to claim 7, Holland teaches the system according to claim 1. Holland does not explicitly teach a second lock manager configured to request the data structure from the node to rebuild the data structure.
However, in an analogous art, Zumach teaches wherein a second lock manager is configured to request the data structure from the node to rebuild the data structure (Col. 11 Lines 49-52 states “At step 604, node II revives and sends a message to node I indicating that node II wants to resume control of its storage and requesting that node I send lock state information for its storage.” Col. 11 Lines 58-59 states “At step 608, node II reconstructs lock data structures for its storage based on the transferred lock state information.” See FIG. 4A and 6).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the second lock manager on the second node requesting data to rebuild the lock data structure with the lock manager of Holland. A person having ordinary skill in the art would have been motivated to make this combination because “there are times when a cluster needs to reconstruct data structures for locks, based on the mirrored lock data structures stored in a memory of a node” (Col. 9 Lines 31-34). An example is when a first node fails and a second node can service requests involving locks on the first node (Col. 2 Lines 11-16 states “When a first node fails, a second node can takeover storage of the first node and retrieve information of the locks for the storage from the shared memory. Thus, the second node can continue to service data requests for the taken-over storage and maintain access rights of the taken-over storage controlled by the locks.” See also Col. 8 Lines 22-34). By doing so, the cluster can maintain high availability.
With regard to claim 8, Holland and Zumach teach the system according to claim 7. Holland additionally teaches wherein the second lock manager is configured to include the second identifier for the application in the data structure based at least in part on the status for the lock being active (¶ [0046] states “the lock table maintained by the CLM 42 may contain a record of the identity of the CAP (the CAP# column in FIG. 3) that has been granted a lock, the object_ID (the object # column in FIG. 3) of the object being accessed by the CAP, and the byte-range over which the lock has been granted to the CAP. Although not shown in FIG. 3, some additional information in the CLM lock table may include, per entry, an indication whether the corresponding lock is held active or inactive (as discussed below) and whether the lock is for a data read operation or a data write operation.” ¶ [0049] states “A lock in the CLM's lock table may be held "active," i.e., the lock is currently held by the client 34 and some CAP 36-40 is actively using the lock; or, the lock may be held "inactive," i.e., the lock is currently held by the client 34 but no CAP 36-40 is actively using the lock.” Examiner’s Note: lock managers include the identity of the CAP, which is the identifier of the application).
Zumach additionally teaches wherein the second lock manager is configured to include the second identifier for the application in the data structure based at least in part on the status for the lock being active (Col. 8 Line 65 – Col. 9 Line 1 states “A client identifier 305A identifies a client system that has been granted a lock.” Col. 9 Lines 59-62 states “At step 506, the lock manager 301A determines whether the lock needs to be mirrored. In one embodiment, a lock will need to be mirrored if it has a Persistent Open feature.” Col. 7 Lines 27-28 states “The Persistent Open feature provides an exclusive right of a data container.” Col. 7 Lines 31-35 states “If the node becomes unavailable for any reason, the [Persistent Open Lock] stays open for a specified duration and within that duration, the client may use the reconnect key to obtain the lock and access to the data container.).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the lock manager mirroring a lock based on if it has a persistent open feature of Zumach with the lock manager, lock data structure, and lock status of Holland. The persistent open feature of Zumach is analogous to the lock of Holland that is designated as “active.” The first lock manager mirrors a lock if it has the persistent open feature. When the second lock manager rebuilds the lock (which includes the second identifier), it will be based on the lock being active. A person having ordinary skill in the art would have been motivated to make this combination because “by keeping the mirrored lock data structures, the cluster preserves the Persistent Open and the associate lock state when there is failure during such an event” (Col. 11 Lines 2-4). This provides the advantage of the client being able to use the reconnect key, obtain the lock, and access the data container even there is a failure (Col. 7 Lines 31-35 states “If the node becomes unavailable for any reason, the [Persistent Open Lock] stays open for a specified duration and within that duration, the client may use the reconnect key to obtain the lock and access to the data container”).
With regard to claim 9, Holland and Zumach teach the system according to claim 8. Zumach additionally teaches wherein the second lock manager is configured to send a signal to the application based at least in part on the data structure including the second identifier for the application (Col. 12 Lines 10-15 states “If there is an existing flag set on the corresponding lock data structure, the D-module of node II sends an instruction to the N-module to terminate the client connection. Upon receiving the instruction, the N-module sends a request to the client to terminate the connection between the client and the N-module (616).” Col. 8 Line 67 – Col. 9 Line 1 states “A client identifier 305A identifies a client system that has been granted a lock.”).
With regard to claim 10, Holland and Zumach teach the system according to claim 9. Zumach additionally teaches wherein the second lock manager is configured to send the signal to the application based at least in part on the application sending an activation request to the lock manager (Col. 11 Lines 65-67 states “At step 612, the D-module of node II receives a data operation permitted by a lock from a client relayed by an N-module.” Col. 12 Lines 4-8 states “the D-module of node II receives other types of communications associated with the lock at step 612. At step 614, the D-module of node II checks whether there is an existing flag set on the corresponding lock data structure.” Col. 12 Lines 10-13 state “If there is an existing flag set on the corresponding lock data structure, the D-module of node II sends an instruction to the N-module to terminate the client connection.” Examiner’s Note: the data operation permitted by a lock from a client is the activation request).
With regard to claim 11, Holland teaches a method, comprising (¶ [0009] states “the present invention contemplates a method of updating data contained in a file object stored in an object-based distributed data storage system.”):
receiving a lock request for a resource at a node in a network from an application at a lock manager (¶ [0049] states “When a CAP 36-40 wishes to access a data file object to perform a data read or write operation, the CAP contacts its local CLM 42 to request a byte-range-based read (R) or write (W) lock on the object in question.” ¶ [0044] states “The three software components, as illustrated in FIG. 3, are: the client application program (CAP), the client lock manager (CLM), and the storage manager lock manager (SMLM).” ¶ [0024] states “An OBSD or OBD 12 is a physical disk drive that stores data files in the network-based system 10.” ¶ [0025] states “The fundamental abstraction exported by an OBD 12 is that of an "object," which may be defined as a variably-sized ordered collection of bits.” ¶ [0027] states “The OBDs, clients, managers, etc., may be considered as "[nodes]" on the network 28.”);
determining that the resource at the node is unlocked (¶ [0049] states “Upon receiving the lock request from a CAP 36-40, the CLM 42 scans its lock table.” ¶ [0049] additionally states “if a held-active lock subsumes the requested lock, the CLM 42 may delay the lock grant until the held-active lock is locally released.” See ¶ [0049] for additional determining steps);
storing a lock at the lock manager, the lock associated with the resource at the node and the application, the lock locking the resource (¶ [0046] states “the lock table maintained by the CLM 42 may contain a record of the identity of the CAP (the CAP# column in FIG. 3) that has been granted a lock, the object_ID (the object # column in FIG. 3) of the object being accessed by the CAP, and the byte-range over which the lock has been granted to the CAP.” ¶ [0049] states “The CAP simply requests an R lock (for data reading) or a W lock (for data writing) as defined”);
setting a status for the lock to active at the lock manager (¶ [0046] states “some additional information in the CLM lock table may include, per entry, an indication whether the corresponding lock is held active or inactive.” ¶ [0049] states “If the lock request is for an R lock and the CLM 42 believes that the object being locked is in the locally held state (whether held "active" or held "inactive"), the CLM 42 may immediately grant the requested lock and mark the lock as "granted"” and “A lock in the CLM's lock table may be held "active," i.e., the lock is currently held by the client 34 and some CAP 36-40 is actively using the lock.” ¶ [0049] additionally states “if a held-inactive lock "subsumes" the requested lock (i.e., if the requested lock's byte-range falls under the byte-range allocated to the held-inactive lock), then the CLM 42 grants the requested lock and marks the lock as held "active" of the appropriate type (R or W lock).”);
and granting the lock to the application from the lock manager (¶ [0049] states “If the lock request is for an R lock and the CLM 42 believes that the object being locked is in the locally held state (whether held "active" or held "inactive"), the CLM 42 may immediately grant the requested lock and mark the lock as "granted".”),
wherein an active status for the lock identifies that the application shall actively use the resource that is locked and an inactive status for the lock identifies that the application shall not actively use the resource that is locked (¶ [0049] states “A lock in the CLM's lock table may be held "active," i.e., the lock is currently held by the client 34 and some CAP 36-40 is actively using the lock; or, the lock may be held "inactive," i.e., the lock is currently held by the client 34 but no CAP 36-40 is actively using the lock.”).
Although Holland teaches granting a lock (¶ [0049]), Holland does not explicitly teach issuing the lock to the application from the manager.
However, in an analogous art, Zumach teaches and issuing the lock to the application from the lock manager (Col. 9 Lines 56-60 states “At step 504, the lock manager 301A modifies, adds, or deletes lock state of the lock associated with the data container, at the local memory of node 102A according to the instruction. At step 506, the lock manager 301A determines whether the lock needs to be mirrored.” Col. 10 Lines 8-10 states “If local or partner mirroring is needed, then the necessary lock state information for mirroring is extracted from an original lock data structure at step 510.” Col. 10 Lines 35-37 states “then at step 518, the lock state information (e.g. metadata in fields' 305A-305F) is sent by node 102A to node 102B.” Col. 6 Lines 42-44 states “Each node maintains a lock data structure for managing locks that are granted to a client 114 for accessing a piece of data or a data container managed by a node.” Examiner’s Note: “issuing” is interpreted as sending).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the mirroring of a lock of Zumach with the lock manager of Holland. As a result, the lock manager can issue a copy of the lock to the application. A person having ordinary skill in the art would have been motivated to make this combination because “there are times when a cluster needs to reconstruct data structures for locks, based on the mirrored lock data structures stored in a memory of a node” (Col. 9 Lines 31-34). An example is when a first node fails and a second node can service requests involving locks on the first node (Col. 2 Lines 11-16 states “When a first node fails, a second node can takeover storage of the first node and retrieve information of the locks for the storage from the shared memory. Thus, the second node can continue to service data requests for the taken-over storage and maintain access rights of the taken-over storage controlled by the locks.” See also Col. 8 Lines 22-34). By doing so, the cluster can maintain high availability.
With regard to claim 12, Holland and Zumach teach the method according to claim 11. Holland additionally teaches further comprising sending the lock and the status for the lock from the lock manager to the node (¶ [0049] states “Otherwise, if a held-inactive lock "subsumes" the requested lock (i.e., if the requested lock's byte-range falls under the byte-range allocated to the held-inactive lock), then the CLM 42 grants the requested lock and marks the lock as held "active" of the appropriate type (R or W lock).”)
Holland does not explicitly teach sending the lock and the status for the lock to the node.
However, in an analogous art, Zumach teaches further comprising sending the lock and the status for the lock from the lock manager to the node (Col. 9 Lines 56-60 states “At step 504, the lock manager 301A modifies, adds, or deletes lock state of the lock associated with the data container, at the local memory of node 102A according to the instruction. At step 506, the lock manager 301A determines whether the lock needs to be mirrored.” Col. 10 Lines 8-10 states “If local or partner mirroring is needed, then the necessary lock state information for mirroring is extracted from an original lock data structure at step 510.” Col. 10 Lines 35-37 states “then at step 518, the lock state information (e.g. metadata in fields' 305A-305F) is sent by node 102A to node 102B.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the mirroring of lock information of Zumach with the granting of a lock of Holland. As a result, when the lock manager grants a lock, it can then send a copy of the lock state to the node. The lock status is part of the lock, so sending the lock state includes sending the lock status. In the combination, the node of Zumach and the OBD node of Holland are the same node. A person having ordinary skill in the art would have been motivated to make this combination because “there are times when a cluster needs to reconstruct data structures for locks, based on the mirrored lock data structures stored in a memory of a node” (Col. 9 Lines 31-34). An example is when a first node fails and a second node can service requests involving locks on the first node (Col. 2 Lines 11-16 states “When a first node fails, a second node can takeover storage of the first node and retrieve information of the locks for the storage from the shared memory. Thus, the second node can continue to service data requests for the taken-over storage and maintain access rights of the taken-over storage controlled by the locks.” See also Col. 8 Lines 22-34). By doing so, the cluster can maintain high availability.
With regard to claim 13, Holland and Zumach teach the method according to claim 11. Holland additionally teaches further comprising: receiving a request for the lock from the application at the lock manager (¶ [0049] states “When a CAP 36-40 wishes to access a data file object to perform a data read or write operation, the CAP contacts its local CLM 42 to request a byte-range-based read (R) or write (W) lock on the object in question.” ¶ [0044] states “The three software components, as illustrated in FIG. 3, are: the client application program (CAP), the client lock manager (CLM), and the storage manager lock manager (SMLM).” ¶ [0024] states “An OBSD or OBD 12 is a physical disk drive that stores data files in the network-based system 10.” ¶ [0025] states “The fundamental abstraction exported by an OBD 12 is that of an "object," which may be defined as a variably-sized ordered collection of bits.”);
and updating the status for the lock at the lock manager based at least in part on the request (¶ [0049] states “If the lock request is for an R lock and the CLM 42 believes that the object being locked is in the locally held state (whether held "active" or held "inactive"), the CLM 42 may immediately grant the requested lock and mark the lock as "granted"” and “A lock in the CLM's lock table may be held "active," i.e., the lock is currently held by the client 34 and some CAP 36-40 is actively using the lock”).
With regard to claim 14, Holland and Zumach teaches the method according to claim 13. Holland additionally teaches further comprising sending the status for the lock from the lock manager to the node (¶ [0049] states “Otherwise, if a held-inactive lock "subsumes" the requested lock (i.e., if the requested lock's byte-range falls under the byte-range allocated to the held-inactive lock), then the CLM 42 grants the requested lock and marks the lock as held "active" of the appropriate type (R or W lock).”).
Holland does not explicitly teach sending the status for the lock from the lock manager to the node.
However, in an analogous art, Zumach teaches further comprising sending the status for the lock from the lock manager to the node (Col. 9 Lines 56-60 states “At step 504, the lock manager 301A modifies, adds, or deletes lock state of the lock associated with the data container, at the local memory of node 102A according to the instruction. At step 506, the lock manager 301A determines whether the lock needs to be mirrored.” Col. 10 Lines 8-10 states “If local or partner mirroring is needed, then the necessary lock state information for mirroring is extracted from an original lock data structure at step 510.” Col. 10 Lines 35-37 states “then at step 518, the lock state information (e.g. metadata in fields' 305A-305F) is sent by node 102A to node 102B.”)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the mirroring of lock information of Zumach with the granting of a lock of Holland. As a result, when the lock manager grants a lock, it can then send a copy of the lock state to the node. The lock status is part of the lock, so sending the lock state includes sending the lock status. In the combination, the node of Zumach and the OBD node of Holland are the same node. A person having ordinary skill in the art would have been motivated to make this combination because “there are times when a cluster needs to reconstruct data structures for locks, based on the mirrored lock data structures stored in a memory of a node” (Col. 9 Lines 31-34). An example is when a first node fails and a second node can service requests involving locks on the first node (Col. 2 Lines 11-16 states “When a first node fails, a second node can takeover storage of the first node and retrieve information of the locks for the storage from the shared memory. Thus, the second node can continue to service data requests for the taken-over storage and maintain access rights of the taken-over storage controlled by the locks.” See also Col. 8 Lines 22-34). By doing so, the cluster can maintain high availability.
With regard to claim 15, Holland and Zumach teach the method according to claim 13. Holland additionally teaches further comprising: receiving an activation request for the lock from the application at the lock manager (¶ [0049] states “When a CAP 36-40 wishes to access a data file object to perform a data read or write operation, the CAP contacts its local CLM 42 to request a byte-range-based read (R) or write (W) lock on the object in question.”);
and updating the status for the lock to active at the lock manager (¶ [0049] states “A lock in the CLM's lock table may be held "active," i.e., the lock is currently held by the client 34 and some CAP 36-40 is actively using the lock; or, the lock may be held "inactive," i.e., the lock is currently held by the client 34 but no CAP 36-40 is actively using the lock” and “If the lock request is for an R lock and the CLM 42 believes that the object being locked is in the locally held state (whether held "active" or held "inactive"), the CLM 42 may immediately grant the requested lock and mark the lock as "granted". Otherwise, if a held-inactive lock "subsumes" the requested lock (i.e., if the requested lock's byte-range falls under the byte-range allocated to the held-inactive lock), then the CLM 42 grants the requested lock and marks the lock as held "active" of the appropriate type (R or W lock).”).
With regard to claim 16, Holland and Zumach teach the method according to claim 15. Holland additionally teaches further comprising sending the status for the lock from the lock manager to the node (¶ [0049] states “Otherwise, if a held-inactive lock "subsumes" the requested lock (i.e., if the requested lock's byte-range falls under the byte-range allocated to the held-inactive lock), then the CLM 42 grants the requested lock and marks the lock as held "active" of the appropriate type (R or W lock).”).
Holland does not explicitly teach that the lock manager is configured to send the status for the lock to the node.
However, in an analogous art, Zumach teaches further comprising sending the status for the lock from the lock manager to the node (Col. 9 Lines 56-60 states “At step 504, the lock manager 301A modifies, adds, or deletes lock state of the lock associated with the data container, at the local memory of node 102A according to the instruction. At step 506, the lock manager 301A determines whether the lock needs to be mirrored.” Col. 10 Lines 8-10 states “If local or partner mirroring is needed, then the necessary lock state information for mirroring is extracted from an original lock data structure at step 510.” Col. 10 Lines 35-37 states “then at step 518, the lock state information (e.g. metadata in fields' 305A-305F) is sent by node 102A to node 102B.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the mirroring of lock information of Zumach with the granting of a lock of Holland. As a result, when the lock manager grants a lock, it can then send a copy of the lock state to the node. The lock status is part of the lock, so sending the lock state includes sending the lock status. In the combination, the node of Zumach and the OBD node of Holland are the same node. A person having ordinary skill in the art would have been motivated to make this combination because “there are times when a cluster needs to reconstruct data structures for locks, based on the mirrored lock data structures stored in a memory of a node” (Col. 9 Lines 31-34). An example is when a first node fails and a second node can service requests involving locks on the first node (Col. 2 Lines 11-16 states “When a first node fails, a second node can takeover storage of the first node and retrieve information of the locks for the storage from the shared memory. Thus, the second node can continue to service data requests for the taken-over storage and maintain access rights of the taken-over storage controlled by the locks.” See also Col. 8 Lines 22-34). By doing so, the cluster can maintain high availability.
With regard to claim 17, Holland teaches a method, comprising (¶ [0009] states “the present invention contemplates a method of updating data contained in a file object stored in an object-based distributed data storage system.”):
sending a query from a lock manager to the node, the query requesting an information about a lock for a resource at the node, the lock locking the resource (¶ [0024] states “An OBSD or OBD 12 is a physical disk drive that stores data files in the network-based system 10.” ¶ [0025] states “The fundamental abstraction exported by an OBD 12 is that of an "object," which may be defined as a variably-sized ordered collection of bits.” ¶ [0027] states “The OBDs, clients, managers, etc., may be considered as "[nodes]" on the network 28.” ¶ [0046] states “the lock table maintained by the CLM 42 may contain a record of the identity of the CAP (the CAP# column in FIG. 3) that has been granted a lock, the object_ID (the object # column in FIG. 3) of the object being accessed by the CAP, and the byte-range over which the lock has been granted to the CAP.”);
receiving the information about the lock for the resource at the node at the lock manager, the information about the lock including an application holding the lock and a status for the lock (¶ [0046] states “the lock table maintained by the CLM 42 may contain a record of the identity of the CAP (the CAP# column in FIG. 3) that has been granted a lock, the object_ID (the object # column in FIG. 3) of the object being accessed by the CAP, and the byte-range over which the lock has been granted to the CAP.”);
and establishing the lock to the application for the resource at the lock manager (¶ [0049] states “If the lock request is for an R lock and the CLM 42 believes that the object being locked is in the locally held state (whether held "active" or held "inactive"), the CLM 42 may immediately grant the requested lock and mark the lock as "granted".”),
wherein the status for the lock is set to active (¶ [0049] states “A lock in the CLM's lock table may be held "active," i.e., the lock is currently held by the client 34 and some CAP 36-40 is actively using the lock; or, the lock may be held "inactive," i.e., the lock is currently held by the client 34 but no CAP 36-40 is actively using the lock” and “If the lock request is for an R lock and the CLM 42 believes that the object being locked is in the locally held state (whether held "active" or held "inactive"), the CLM 42 may immediately grant the requested lock and mark the lock as "granted". Otherwise, if a held-inactive lock "subsumes" the requested lock (i.e., if the requested lock's byte-range falls under the byte-range allocated to the held-inactive lock), then the CLM 42 grants the requested lock and marks the lock as held "active" of the appropriate type (R or W lock).”),
wherein an active status for the lock identifies that the application shall actively use the resource that is locked and an inactive status for the lock identifies that the application shall not actively use the resource that is locked (¶ [0049] states “A lock in the CLM's lock table may be held "active," i.e., the lock is currently held by the client 34 and some CAP 36-40 is actively using the lock; or, the lock may be held "inactive," i.e., the lock is currently held by the client 34 but no CAP 36-40 is actively using the lock.”).
Holland does not explicitly teach sending a query from a lock manager to a node and receiving information.
However, in an analogous art, Zumach teaches sending a query from a lock manager to the node, the query requesting an information about a lock for a resource at the node, the lock locking the resource (Col. 11 Lines 49-52 states “At step 604, node II revives and sends a message to node I indicating that node II wants to resume control of its storage and requesting that node I send lock state information for its storage.”);
receiving the information about the lock for the resource at the node at the lock manager, the information about the lock including an application holding the lock and a status for the lock (Col. 11 Lines 52-57 states “At step 606, as part of a giveback procedure, node I sends the lock state information related to the locks for the storage to be given back to node II. The lock state information that is sent to node II can include the locks that are owned by node I and the locks that were owned by node II before the rebooting at step 603.”);
and establishing the lock to the application for the resource at the lock manager (Col. 11 Lines 58-59 states “At step 608, node II reconstructs lock data structures for its storage based on the transferred lock state information.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the query for lock information, the receiving of lock information, and the reconstructing of the lock of Zumach with the lock data structure of Holland. As a result, the lock information that is received at node II of Zumach includes the CAP identifier and status of Holland. A person having ordinary skill in the art would have been motivated to make this combination because “there are times when a cluster needs to reconstruct data structures for locks, based on the mirrored lock data structures stored in a memory of a node” (Col. 9 Lines 31-34). An example is when a first node fails and a second node can service requests involving locks on the first node (Col. 2 Lines 11-16 states “When a first node fails, a second node can takeover storage of the first node and retrieve information of the locks for the storage from the shared memory. Thus, the second node can continue to service data requests for the taken-over storage and maintain access rights of the taken-over storage controlled by the locks.” See also Col. 8 Lines 22-34). By doing so, the cluster can maintain high availability.
With regard to claim 18, Holland and Zumach additionally teach the method according to claim 17. Holland additionally teaches further comprising: receiving a request for the lock from the application at the lock manager (¶ [0049] states “Upon receiving the lock request from a CAP 36-40, the CLM 42 scans its lock table.”);
and setting the status for the lock at the lock manager based at least in part on the request (¶ [0049] states “Upon receiving the lock request from a CAP 36-40, the CLM 42 scans its lock table. If the lock request is for an R lock and the CLM 42 believes that the object being locked is in the locally held state (whether held "active" or held "inactive"), the CLM 42 may immediately grant the requested lock and mark the lock as "granted". Otherwise, if a held-inactive lock "subsumes" the requested lock (i.e., if the requested lock's byte-range falls under the byte-range allocated to the held-inactive lock), then the CLM 42 grants the requested lock and marks the lock as held "active" of the appropriate type (R or W lock).”).
With regard to claim 20, Holland and Zumach additionally teach the method according to claim 18. Holland additionally teaches further comprising sending the status for the lock from the lock manager to the node (¶ [0049] states “Otherwise, if a held-inactive lock "subsumes" the requested lock (i.e., if the requested lock's byte-range falls under the byte-range allocated to the held-inactive lock), then the CLM 42 grants the requested lock and marks the lock as held "active" of the appropriate type (R or W lock).”).
Zumach additionally teaches further comprising sending the status for the lock from the lock manager to the node (Col. 9 Lines 56-60 states “At step 504, the lock manager 301A modifies, adds, or deletes lock state of the lock associated with the data container, at the local memory of node 102A according to the instruction. At step 506, the lock manager 301A determines whether the lock needs to be mirrored.” Col. 10 Lines 8-10 states “If local or partner mirroring is needed, then the necessary lock state information for mirroring is extracted from an original lock data structure at step 510.” Col. 10 Lines 35-37 states “then at step 518, the lock state information (e.g. metadata in fields' 305A-305F) is sent by node 102A to node 102B.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the mirroring of lock information of Zumach with the granting of a lock of Holland. As a result, when the lock manager grants a lock, it can then send a copy of the lock state to the node. The lock status is part of the lock, so sending the lock state includes sending the lock status. In the combination, the node of Zumach and the OBD node of Holland are the same node. A person having ordinary skill in the art would have been motivated to make this combination because “there are times when a cluster needs to reconstruct data structures for locks, based on the mirrored lock data structures stored in a memory of a node” (Col. 9 Lines 31-34). An example is when a first node fails and a second node can service requests involving locks on the first node (Col. 2 Lines 11-16 states “When a first node fails, a second node can takeover storage of the first node and retrieve information of the locks for the storage from the shared memory. Thus, the second node can continue to service data requests for the taken-over storage and maintain access rights of the taken-over storage controlled by the locks.” See also Col. 8 Lines 22-34). By doing so, the cluster can maintain high availability.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Holland in view of Zumach and further in view of Jenkins.
With regard to claim 19, Holland and Zumach additionally teach the method according to claim 18. Although Holland teaches receiving a request for the lock (¶ [0049]), Holland and Zumach do not explicitly teach receiving the request at an API of the lock manager.
However, in an analogous art, Jenkins teaches wherein receiving the request for the lock from the application at the lock manager includes receiving the request for the lock from the application at an Application Programming Interface (API) of the lock manager (Abstract states “A distributed lock manager (DLM) may be implemented in a distributed computing system… The DLM may expose an API to clients, allowing them to make local calls to a DLM component on the same node to perform various lock management operations. The meanings of the lock values may be established by their use in client applications.” ¶ [0053] states “By making local API calls to invoke various lock management operations (e.g., operations to create a lock, specify one or more properties of a lock, obtain a list of locks, subscribe to a lock, acquire a lock, release a lock or delete a lock), the components of the client application may participate in the locks managed by the DLM.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the lock manager having an API to receive requests from client applications of Jenkins with the lock managers of Holland and Zumach. As a result, the client lock manager of Holland has an API that can be accessed by the client application program. The client application program of Holland is analogous to the client of Jenkins. The lock request of Holland is a management operation that can be exposed via the API of Jenkins. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of “managing large-scale computing resources for many clients with diverse needs, allowing various computing resources to be efficiently and securely shared by multiple clients” (¶ [0002]).
Response to Arguments
The 35 U.S.C. § 112(f) interpretation of “lock manager” in claims 3, 5-6, and 7-10 has been withdrawn. The subsequent 35 U.S.C. § 112(a) and 112(b) rejections to claims 3 and 5-10 are also withdrawn.
The 35 U.S.C. § 101 rejection of claims 3-5, 8-10, and 18-20 are withdrawn.
Applicant's arguments filed 10/22/2025 have been fully considered but they are not persuasive.
Regarding Step 1 of the 35 U.S.C. § 101 rejection of claim 11, Applicant states that it “is unclear whether claim 11 is even rejected” (Page 12 of Applicant’s remarks) and “the Office Action has not indicated whether claim 11 is considered to recite a statutory category under Step 1” (Page 12 of Applicant’s remarks).
Examiner has clarified that claim 11 is with rejected under 35 U.S.C. § 101 and that claims 11-16 are directed to a method which falls under the statutory class of process. These changes are responsive to Applicant’s amendment which substantially changed the scope of the claims.
Examiner states that claims 11-16 pass Step 1 of the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019.
Regarding Step 2A Prong 1 of the 35 U.S.C. § 101 rejection of claim 11, Applicant argues that "The human mind is not capable of failing in a way that would require the lock information to be rebuilt, and therefore the features of the claim identified by the Office Action are not capable of being practically performed in the human mind” (Page 13 of Applicant’s remarks).
Examiner respectfully disagrees. The claim recites “determining that the resource at the node is unlocked.” As explained in the 35 U.S.C. § 101 rejection of claim 11, this limitation is a mental process of observing and forming a judgement. A human can practically perform this limitation entirely in the mind because a human can observe the state of a lock and determine if it is unlocked. Applicant’s argument about the how the human mind is not capable of failing in a way that would require the lock information to be rebuilt is unpersuasive because that does not cause the determining step to no longer be a mental process.
Examiner maintains that claim 11 does not pass Step 2A Prong 1.
Regarding Step 2A Prong 2 of the 35 U.S.C. § 101 rejection of claim 11, Applicant states that features in the Office Action dated July 22, 2025 “are scattered across claims 1, 11, and 17” (Page 13 of Applicant’s remarks). Applicant additionally argues “to assert that the features of "receiving a lock request for a resource at a node in a network from an application" and "issuing the lock to the application from the lock manager" are "insignificant data gathering, transmission, and storage activity" does not appear to be correct. The lock is more than just data: it is a security that ensures that no other application may use the resource in question. The lock is therefore more than just "data gathering, transmission, and storage activity" (Page 15 of Applicant’s remarks). Next, Applicant argues “the claims do not monopolize any judicial exception, and therefore integrate any judicial exception that might exist into a practical application” (Page 15 of Applicant’s remarks) and “Since the addition of the status for the lock benefits the technical field by expediting rebuilding locks when necessary, the claims integrate any judicial exception into a practical application” (Page 15 of Applicant’s remarks). Lastly, Applicant argues that “The Office Action also fails to consider under Step 2A, Prong Two, whether the claim features, in combination, integrate any judicial exception into a practical application” (Page 15 of Applicant’s remarks).
Examiner has clarified the 35 U.S.C. § 101 rejection of claim 11 to only include limitations found in claim 11. These changes are responsive to Applicant’s amendment which substantially changed the scope of the claims. Examiner respectfully disagrees with Applicant’s arguments. The limitations “receiving a lock request for a resource at a node in a network from an application” and "issuing the lock to the application from the lock manager" are insignificant extra-solution activity of data gathering and transmission because there is data being received and transmitted in a network. Additionally, they are incidental to the judicial exception of determining that the resource at the node is unlocked. Claim 11 also does not integrate the judicial exception into a practical solution or show an improvement to technology because the additional elements only amount of insignificant extra-solution activities (MPEP § 2106.05(g)) and field of use/technological environment (MPEP § 2106.05(h)). In other words, the additional elements do not show an improvement realized by performing the judicial exception. Lastly, whether the additional elements are analyzed individually or in combination, the analysis is that the additional elements do not integrate the judicial exception into a practical application.
Examiner maintains that claim 11 does not pass Step 2A Prong 2.
Regarding Step 2A Prong 2 of the 35 U.S.C. § 101 rejection of claim 11, Applicant argues that the Office Action dated July 22, 2025 makes “a conclusory statement rather than an actual analysis. In addition, this argument conflates the issues under Step 2A, Prong Two, and Step 2B. These analyses may partially overlap, but they are not identical” (Page 16 of Applicant’s remarks). Applicant additionally argues “to simply conclude that the claim does not satisfy Step 2B simply because it does not satisfy Step 2A, Prong Two, does not appear to be a proper analysis” (Page 16 of Applicant’s remarks).
Examiner respectfully disagrees. The statements in the Office Action dated July 22, 2025 and the clarified statements in 35 U.S.C. § 101 rejection of claim 11 are not conclusory statements. Examiner explained that reanalyzing the additional elements, alone or in combination, does not amount to significantly more because the additional elements are only insignificant extra-solution activities and field of use/technological environment. Further, Examiner explained that the insignificant extra-solution activities did not add an inventive concept that is other than what is well understood, routine, and conventional in the field by providing examples of well understood, routine and conventional computer functions as described in MPEP § 2106.05(d)(II).
Examiner maintains that claim 11 does not pass Step 2B and that claim 11 does not recite eligible subject matter under 35 U.S.C. § 101.
Regarding the 35 U.S.C. § 101 rejection of claims 12, 14 and 16, Applicant states that “the Office Action groups the claims together, rejecting them en masse” (Page 21 of Applicant’s remarks). Applicant additionally argues that the analysis was incomplete for claims 12 and 14 (Page 22-23 of Applicant’s remarks).
Examiner respectfully disagrees. Examiner has clarified the rejection of claims 12, 14, and 16 by rewriting the rejection of each claim separately responsive to Applicant’s amendment which substantially changed the scope of the claims. A complete analysis of claims 12, 14, and 16 and how they do not recite eligible subject matter under 35 U.S.C. § 101 is provided in the 35 U.S.C. § 101 rejection. Additionally, see Examiner’s response to arguments against the 35 U.S.C. § 101 rejection of claim 11 as to why the rejection is complete.
Examiner maintains the 35 U.S.C. § 101 rejection of claims 12, 14, and 16.
Regarding the 35 U.S.C. § 101 rejection of claim 13, Applicant argues against “updating the status for the lock” being a mental process (Page 30 of Applicant’s remarks) and against “from the application at the lock manager” being recitation of generic computing components and functions merely being used as a tool to apply the abstract idea” (Page 30 of Applicant’s remarks). Applicant additionally argues that the “analysis is conclusory, without any explanation as to why "receiving a request for the lock from the application" is merely "insignificant data gathering activity”” (Page 30 of Applicant’s remarks). Additionally, Applicant argues that the rejection does consider the claims as a whole, there is an integration into practical solution, and argues against the Step 2A and Step 2B analysis (Page 30-32 of Applicant’s remarks).
Examiner respectfully disagrees. Examiner has clarified that “updating the status for the lock” and “receiving a request for the lock from the application at the lock manager” are insignificant extra-solution activities of data storage and transmission. These changes are responsive to Applicant’s amendment which substantially changed the scope of the claims. Receiving a request for the lock from the application is insignificant extra-solution activity because it shows data gathering across a network and is incidental the judicial exception recite in claim 11. Regarding arguments about the rejection not considering the claim as a whole, integration into practical solution, and the Step 2A and Step 2B analysis, see Examiner’s response to arguments against the 35 U.S.C. § 101 rejection of claim 11 as to why the rejection is complete. Additionally, see 35 U.S.C. § 101 rejection of claim 13 for a complete analysis.
Examiner maintains the 35 U.S.C. § 101 rejection of claims 13.
Regarding the 35 U.S.C. § 101 rejection of claim 15, Applicant argues against “updating the status for the lock” being a mental process (Page 32 of Applicant’s remarks). Applicant additionally argues the analysis about receiving an activation request being well-understood, routine, and conventional “is conclusory, without any explanation as to why the "receiving an activation request for the lock from the application at the lock manager" fails to integrate any judicial exception into a practical application” (Page 32 of Applicant’s remarks). Additionally, Applicant argues that the rejection does consider the claims as a whole, there is an integration into practical solution, and argues against the Step 2A and Step 2B analysis (Page 30-32 of Applicant’s remarks).
Examiner respectfully disagrees. Examiner has clarified that “updating the status for the lock” is insignificant extra-solution activity of data storage. These changes are responsive to Applicant’s amendment which substantially changed the scope of the claims. The analysis that “receiving an activation request being well-understood, routine, and conventional” is not conclusory because an explanation was provided. The Office Action date July 22, 2025 and 35 U.S.C. 35 § 101 rejection of claim 15 provided examples of well understood, routine and conventional computer functions as described in MPEP § 2106.05(d)(II). Regarding arguments about the rejection not considering the claim as a whole, integration into practical solution, and the Step 2A and Step 2B analysis, see Examiner’s response to arguments against the 35 U.S.C. § 101 rejection of claim 11 as to why the rejection is complete. Additionally, see 35 U.S.C. § 101 rejection of claim 15 for a complete analysis.
Examiner maintains the 35 U.S.C. § 101 rejection of claims 15.
Regarding the 35 U.S.C. § 102 rejection of claim 1, Applicant argues “claim 1 is patentable under 35 U.S.C. § 102(a) over Dubey” (Page 41 of Applicant’s remarks).
Examiner respectfully disagrees. Applicant’s arguments with respect to claim(s) 1 have been considered but are moot because the new ground of rejection does not rely on Dubey as applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Rather, it is Holland that anticipates claim 1.
Examiner rejects claim 1 as unpatentable over Holland.
Regarding the 35 U.S.C. § 103 rejection of claim 3, Applicant argues “claim 3 is patentable under 35 U.S.C. § 103 over Dubey in view of Zumach.” (Page 42 of Applicant’s remarks).
Examiner respectfully disagrees. Applicant’s arguments with respect to claim(s) 3 have been considered but are moot because the new ground of rejection does not rely on Dubey or Zumach as applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Rather, it is Holland that anticipates claim 3.
Examiner rejects claim 3 as unpatentable over Holland.
Regarding the 35 U.S.C. § 103 rejection of claim 5, Applicant argues that “claim 5 is patentable under 35 U.S.C. § 103 over Dubey in view of Zumach” (Page 42 of Applicant’s remarks). Although Dubey is not used in the new grounds of rejection, Applicant argues against Zumach and states that “the claims are not concerned with a high availability environment: there is no established relationship between the node and the lock manager except for the fact that the lock manager manages the locks for the nodes of the system” (Page 42 of Applicant’s remarks).
Examiner respectfully disagrees. As explained in the 35 U.S.C. § 103 rejection of claim 5, it is the combination of Holland and Zumach that teaches the relationship between node and lock manager. Holland provides the environment for a client application interacting with a lock manager to receive a lock for accessing an object stored on a OBD node. Holland teaches sending an updated status to the client but does not explicitly teach sending the status to the node. However, Zumach teaches a lock manager sending a lock from a first node to a second node which shows that the lock manager can directly interact with a node. Therefore, the relationship between lock manager and node has been taught. Applicant’s argument that “the claims are not concerned with a high availability environment” is not persuasive because MPEP § 2144(IV) states “The reason or motivation to modify the reference may often suggest what the inventor has done, but for a different purpose or to solve a different problem. It is not necessary that the prior art suggest the combination to achieve the same advantage or result discovered by applicant.”
Examiner rejects claim 5 as being unpatentable over Holland in view of Zumach.
Regarding the 35 U.S.C. § 103 rejection of claim 6, Applicant argues that “the claims are not concerned with a high availability environment: there is no established relationship between the node and the lock manager except for the fact that the lock manager manages the locks for the nodes of the system” (Page 42 of Applicant’s remarks) and “claim 6 is patentable under 35 U.S.C. § 103 over Dubey in view of Zumach” (Page 43 of Applicant’s remarks).
Examiner respectfully disagrees. For the same reasons as explained in Examiner’s Response to Applicants arguments against claim 5, Examiner finds applicant’s arguments unpersuasive.
Examiner rejects claim 6 as being unpatentable over Holland in view of Zumach.
Regarding the 35 U.S.C. § 103 rejection of claim 7, Applicant argues that “the claims are not concerned with a high availability environment: there is no established relationship between the node and the lock manager except for the fact that the lock manager manages the locks for the nodes of the system” (Page 43 of Applicant’s remarks) and “claim 6 is patentable under 35 U.S.C. § 103 over Dubey in view of Zumach” (Page 43 of Applicant’s remarks).
Examiner respectfully disagrees. For the same reasons as explained in Examiner’s Response to Applicants arguments against claim 5, Examiner finds applicant’s arguments unpersuasive.
Examiner rejects claim 7 as being unpatentable over Holland in view of Zumach.
Regarding the 35 U.S.C. § 103 rejection of claim 8-10, Applicant argues “claim 7 is allowable, as are dependent claims 8-10” (Page 43 of Applicant’s remarks).
Examiner respectfully disagrees. For the same reasons as explained in Examiner’s Response to Applicants arguments against claim 5, Examiner finds applicant’s arguments unpersuasive. Since Examiner rejected claim 7 as being unpatentable over Holland in view of Zumach, dependent claims 8-10 are also unpatentable. See also Examiner’s response to arguments regarding claim 8 and claim 10 below.
Examiner rejects claim 8-10 as being unpatentable over Holland in view of Zumach.
Regarding the 35 U.S.C. § 103 rejection of claim 4, Applicant argues “DLM stands for distributed lock manager (see, e.g., Amazon Technologies, Abstract). The claim does not say anything about the lock manager being distributed, and therefore Amazon Technologies is not applicable” (Page 43 of Applicant’s remarks). Applicant additionally argues “In the claim, the lock manager may be located anywhere, and not necessarily on the node with the resource” (Page 43 of Applicant’s remarks). Lastly, Applicant argues “claim 4 is patentable under 35 U.S.C. § 103 over Dubey in view of Zumach and Amazon Technologies” (Page 44 of Applicant’s remarks).
Examiner respectfully disagrees. A distributed lock manager is still a lock manager. Jenkins (the reference “Amazon Technologies” refers to) is analogous to the instant application because “the reference is reasonably pertinent to the problem faced by the inventor” (MPEP § 2141.01(a)(I)). Examiner is unpersuaded by Applicants’ argument that “the lock manager may be located anywhere, and not necessarily on the node with the resource” (Page 43 of Applicant’s remarks) because the node of Jenkins is not necessarily the node presented in Holland. Additionally, the specification merely notes that the lock manager may be located anywhere, not that it must not be located on the node with the resource. Moreover, if Applicant would like to limit the claim to preclude co-location of the lock manager and the node with the resource, amendments could be made to narrow the claim, however, as is, the broad claim language does not support the narrow interpretation that Applicant asserts. Lastly, in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “the lock manager may be located anywhere, and not necessarily on the node with the resource”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Examiner rejects claim 4 as being unpatentable over Holland in view of Jenkins.
Regarding the 35 U.S.C. § 103 rejection of claim 8, Applicant argues “the claims are not concerned with a high availability environment: there is no established relationship between the node and the lock manager except for the fact that the lock manager manages the locks for the nodes of the system” (Page 44 of Applicant’s remarks). Applicant additionally argues that “Vishlitsky … does not teach or suggest a status for the lock” (Page 44 of Applicant’s remarks). Lastly, applicant argues that “claim 8 is patentable under 35 U.S.C. § 103” (Page 44 of Applicant’s remarks).
Examiner respectfully disagrees. For the same reasons as explained in Examiner’s Response to Applicant’s arguments against claim 5, Examiner finds applicant’s arguments against Zumach unpersuasive. The argument against Vishlitsky is considered moot because the new grounds of rejection does not reply on Vishlitsky for any teaching.
Examiner rejects claim 8 as being unpatentable over Holland in view of Zumach.
Regarding the 35 U.S.C. § 103 rejection of claim 10, Applicant argues “the claims are not concerned with a high availability environment: there is no established relationship between the node and the lock manager except for the fact that the lock manager manages the locks for the nodes of the system” (Page 45 of Applicant’s remarks). Applicant additionally argues “Vishlitsky does not appear to teach or suggest the features of the claim” (Page 45 of Applicant’s remarks). Applicant also states “that there appears to be a contradiction between the rejection of claim 10 and the rejection of claim 11” (Page 45 of Applicant’s remarks). Lastly, Applicant argues “claim 10 is patentable under 35 U.S.C. § 103” (Page 46 of Applicant’s remarks).
Examiner respectfully disagrees. For the same reasons as explained in Examiner’s Response to Applicant’s arguments against claim 5, Examiner finds applicant’s arguments against Zumach unpersuasive. The argument against Vishlitsky and related alleged contradiction is considered moot because the new grounds of rejection does not reply on Vishlitsky for any teaching.
Examiner rejects claim 10 as being unpatentable over Holland in view of Zumach.
Regarding the 35 U.S.C. § 103 rejection of claim 11, Applicant argues “claim 11 is patentable under 35 U.S.C. § 103 over Vishlitsky in view of Hallak” (Page 46 of Applicant’s remarks).
Examiner respectfully disagrees. Applicant’s arguments with respect to claim(s) 11 have been considered but are moot because the new ground of rejection does not rely on Vishlitsky or Hallak as applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Examiner rejects claim 11 as being unpatentable over Holland in view of Zumach.
Regarding the 35 U.S.C. § 103 rejection of claim 12, Applicant argues “the lock metadata of Zumach does not appear to include a status for the lock” (Page 46 of Applicant’s remarks). Lastly, Applicant argues “claim 12 is patentable under 35 U.S.C. § 103” (Page 47 of Applicant’s remarks).
Examiner respectfully disagrees. Examiner does not reply upon Zumach to teach a “lock status.” It is the combination of Holland and Zumach that fully teaches the claim. See 35 U.S.C. § 103 rejection of claim 12 for how Holland teaches a lock status.
Examiner rejects claim 12 as being unpatentable over Holland in view of Zumach.
Regarding the 35 U.S.C. § 103 rejection of claim 13, Applicant argues “the lock metadata of Zumach does not appear to include a status for the lock.” Applicant additionally argues “the claim recites updating the status for the lock based on the request. Zumach, like Vishlitsky and Hallak, does not appear to teach or suggest this feature” (Page 47 of Applicant’s remarks). Applicant additionally argues “claim 13 is patentable under 35 U.S.C. § 103” (Page 47 of Applicant’s remarks).
Examiner respectfully disagrees. Examiner does not reply upon Zumach to teach a “lock status.” It is the combination of Holland and Zumach that fully teaches the claim. See 35 U.S.C. § 103 rejection of claim 13 for how Holland teaches a lock status. Further, Applicant’s arguments related to Vishlitsky or Hallak have been considered but are moot because the new ground of rejection does not rely on Vishlitsky or Hallak as applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Examiner rejects claim 13 as being unpatentable over Holland.
Regarding the 35 U.S.C. § 103 rejection of claim 14, Applicant argues “the lock metadata of Zumach does not appear to include a status for the lock” (Page 47 of Applicant’s remarks). Applicant additionally argues “claim 14 is patentable under 35 U.S.C. § 103” (Page 48 of Applicant’s remarks).
Examiner respectfully disagrees. Examiner does not reply upon Zumach to teach a “lock status.” It is the combination of Holland and Zumach that fully teaches the claim. See 35 U.S.C. § 103 rejection of claim 12 for how Holland teaches a lock status.
Examiner rejects claim 14 as being unpatentable over Holland in view of Zumach.
Regarding the 35 U.S.C. § 103 rejection of claim 15, Applicant argues “claim 15 is patentable under 35 U.S.C. § 103 over Vishlitsky in view of Hallak and Zumach” (Page 48 of Applicant’s remarks).
Examiner respectfully disagrees. Applicant’s arguments with respect to claim(s) 15 have been considered but are moot because the new ground of rejection does not rely on Vishlitsky or Hallak as applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Additionally, Applicant’s argument against Zumach are moot because Examiner does not rely upon Zumach for limitations specifically in claim 15.
Examiner rejects claim 15 as being unpatentable over Holland in view of Zumach.
Regarding the 35 U.S.C. § 103 rejection of claim 16, Applicant argues “the lock metadata of Zumach does not appear to include a status for the lock” (Page 48 of Applicant’s remarks). Applicant additionally argues “claim 16 is patentable under 35 U.S.C. § 103” (Page 48 of Applicant’s remarks).
Examiner respectfully disagrees. Examiner does not reply upon Zumach to teach a “lock status.” It is the combination of Holland and Zumach that fully teaches the claim. See 35 U.S.C. § 103 rejection of claim 12 for how Holland teaches a lock status.
Examiner rejects claim 16 as being unpatentable over Holland in view of Zumach.
Regarding the 35 U.S.C. § 103 rejection of claim 17, Applicant argues “Zumach does not appear to teach a status for the lock” (Page 49 of Applicant’s remarks). Applicant also argues that “claim 17 is patentable under 35 U.S.C. § 103 over Zumach in view of Hallak” (Page 49 of Applicant’s remarks).
Examiner respectfully disagrees. Examiner does not reply upon Zumach to teach a “lock status.” It is the combination of Holland and Zumach that fully teaches the claim. See 35 U.S.C. § 103 rejection of claim 12 for how Holland teaches a lock status. Additionally, arguments related to Hallak are moot because Examiner does not rely up on Hallak for any teaching or matter specifically challenged in the argument.
Examiner rejects claim 17 as being unpatentable over Holland in view of Zumach.
Regarding the 35 U.S.C. § 103 rejection of claim 18, Applicant argues “claim 18 is patentable under 35 U.S.C. § 103 over Zumach in view of Hallak and Vishlitsky” (Page 50 of Applicant’s remarks).
Examiner respectfully disagrees. Applicant’s arguments related to Vishlitsky are moot as the new grounds of rejection does not reply on Vishlitsky for any teaching or matter specifically challenged in the argument. Rather, it is the combination of Holland and Zumach that fully teach the claim limitations. See 35 U.S.C. § 103 rejection of claim 18 for how Holland and Zumach teach the claim limitations.
Examiner rejects claim 18 as being unpatentable over Holland in view of Zumach.
Regarding the 35 U.S.C. § 103 rejection of claim 20, Applicant argues “Zumach does not appear to teach a status for the lock” (Page 50 of Applicant’s remarks). Applicant additionally argues “it does not appear proper for the Office Action to suggest that Zumach teaches sending such a status for the lock to a node” (Page 50 of Applicant’s remarks). Applicant also argues that “claim 20 is patentable under 35 U.S.C. § 103 over Zumach in view of Hallak and Vishlitsky” (Page 49 of Applicant’s remarks).
Examiner respectfully disagrees. Examiner does not reply upon Zumach to teach a “lock status” and “sending a status to a node.” It is the combination of Holland and Zumach that fully teaches the claim. See 35 U.S.C. § 103 rejection of claim 20 for how Holland and Zumach teach a lock status and sending a status. Applicant’s arguments related to Hallak or Vishlitsky are moot as the new grounds of rejection does not reply on Hallak or Vishlitsky for any teaching or matter specifically challenged in the argument.
Examiner rejects claim 20 as being unpatentable over Holland in view of Zumach.
Regarding the 35 U.S.C. § 103 rejection of claim 19, Applicant argues “DLM stands for distributed lock manager (see, e.g., Amazon Technologies, Abstract). The claim does not say anything about the lock manager being distributed, and therefore Amazon Technologies is not applicable” (Page 51 of Applicant’s remarks). Applicant additionally argues “In the claim, the lock manager may be located anywhere, and not necessarily on the node with the resource” (Page 51 of Applicant’s remarks). Lastly, Applicant argues “claim 19 is patentable under 35 U.S.C. § 103 over Zumach in view of Hallak, Vishlitsky, and Amazon Technologies” (Page 51 of Applicant’s remarks).
Examiner respectfully disagrees. A distributed lock manager is still a lock manager. Jenkins (the reference “Amazon Technologies” refers to) is analogous to the instant application because “the reference is reasonably pertinent to the problem faced by the inventor” (MPEP § 2141.01(a)(I)). Examiner is unpersuaded by Applicants’ argument that “the lock manager may be located anywhere, and not necessarily on the node with the resource” (Page 43 of Applicant’s remarks) because the node of Jenkins is not necessarily the node presented in Holland. Additionally, the specification merely notes that the lock manager may be located anywhere, not that it must not be located on the node with the resource. Moreover, if Applicant would like to limit the claim to preclude co-location of the lock manager and the node with the resource, amendments could be made to narrow the claim, however, as is, the broad claim language does not support the narrow interpretation that Applicant asserts. Lastly, in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “the lock manager may be located anywhere, and not necessarily on the node with the resource”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Examiner rejects claim 19 as being unpatentable over Holland in view of Zumach and Jenkins.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20150347239 A1
teaches
GLOBAL BACKUP LOCK MANAGER
US 20130174165 A1
teaches
FAULT TOLERANT DISTRIBUTED LOCK MANAGER
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 PETER L YUAN whose telephone number is (571)272-5737. The examiner can normally be reached Mon-Fri 7:30am-5pm.
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, Bradley Teets can be reached at 571-272-3338. 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.
/PETER LI YUAN/Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
