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 .
Detailed Action
Office Action is in response to the instant Application 18562,067 filed on 11/17/2023 and Preliminary amendments filed on 11/17/2023. Preliminary Amendments cancelled claims 15, 16 and 18. Claims 1-14 and 17 are pending. This Office Action is Non-Final.
Information Disclosure Statement
The information disclosure statement (IDS), submitted on 11/17/2023, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 11, 13 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ranns et al. (US 2017/0230277) in view of Allan et al. (US 9,461,909).
As per claim 1, Ranns teaches a loop detection method, applied to any target node in a distributed system, wherein the distributed system comprises at least one data dependency path comprising the target node, there is a data dependency relationship between any two adjacent nodes in the data dependency path, the target node maintains a depth value corresponding to the target node, and the depth value represents a path length between a start node in the data dependency path and the target node (Ranns, Paragraph 0031 recites “Detection of redundancy can be performed in various ways. For example, in networks that implement PIM, nodes exchange state information with their neighbors. The state information is included in PIM-Hello messages. The information in the PIM-Hello messages is used by the nodes to discover redundancy. Nodes can also, or in the alternative, use information in Interior Gateway Protocol (IGP) messages (such as IS-IS (Intermediate System to Intermediate System) and OSPF (Open Shortest Path First)) and/or information in Border Gateway Protocol (BGP) messages to detect redundant nodes. Detecting redundancy involves detecting how many connections to a particular network entity, such as a LAN, exist and also, in some cases, which nodes are connected to the particular network entity.”);
and the method comprises: updating the depth value of the target node or a depth value of a downstream node of the target node, so that the depth value of the target node is less than the depth value of the downstream node of the target node (Ranns, Paragraph 0028 recites “Receiver 106 is configured to receive multicast data packets after joining one or more multicast groups. For example, receiver 106 can transmit join information, such as an IGMP report or MLD report, that identifies a multicast group to which receiver 106 wishes to subscribe. In the example of FIG. 1, receiver 106 transmits the join information onto LAN 130. In one embodiment, LAN 130 and the devices connected thereto form a leaf network, and LAN 130 is known as a terminal LAN. A terminal LAN is a LAN that is at the edge of the network, meaning no additional downstream nodes are coupled to the LAN, though a number of hosts can be connected to the LAN. LAN 130 is assigned an IP prefix, and each host coupled the LAN is assigned an IP address that is covered by the IP prefix. Leaf networks couple provider equipment to customer equipment, unlike transit networks, which couple provider equipment to other provider equipment. When LAN 130 is a terminal LAN, nodes 114 and 116 can expect that all packets received from LAN 130 have source IP addresses corresponding to LAN 130.”);
and determining that a loop exists in the data dependency path comprising the target node, in response to that the depth value of the target node is equal to the depth value that is of the upstream node of the target node and that is transferred by the upstream node (Ranns, Paragraph 0040 recites “For example, if node 114 forwards a packet received from core network 150 to LAN 130, in addition to receiver 106 receiving the packet, node 116 can pick up the packet and forward the packet to core network 150. If the nodes in core network 150 forward the packet to node 114, a loop occurs, as shown by the curved arrows in FIG. 3A. However, since node 116 is not configured as the DF, node 114 forwards the traffic onto LAN 130 and node 116 drops the traffic. That is, forwarding information on node 116 is configured such that traffic received on an interface coupled to LAN 130 (interface 2 in this example) by node 116 is dropped. Similarly, node 116 is configured to drop packets received on an interface coupled to core network 150 (interface 1 in this example).”).
But fails to teach receiving a depth value that is of an upstream node of the target node and that is transferred by the upstream node, updating the depth value of the target node to the depth value of the upstream node of the target node in response to that the depth value of the target node is less than the depth value of the upstream node of the target node, and continuing to transfer the updated depth value of the target node to the downstream node of the target node, so that when the downstream node of the target node receives the depth value transferred by the target node, the depth value of the downstream node is updated to the depth value of the target node in response to that the depth value of the downstream node is less than the depth value of the target node.
However, in an analogous Allan teaches receiving a depth value that is of an upstream node of the target node and that is transferred by the upstream node, updating the depth value of the target node to the depth value of the upstream node of the target node in response to that the depth value of the target node is less than the depth value of the upstream node of the target node, and continuing to transfer the updated depth value of the target node to the downstream node of the target node, so that when the downstream node of the target node receives the depth value transferred by the target node, the depth value of the downstream node is updated to the depth value of the target node in response to that the depth value of the downstream node is less than the depth value of the target node (Allan, Col. 12 Lines 28- 56 recites “FIG. 7 is a flow diagram illustrating a method selecting a set of permissible ports at a chosen LFA node according to one embodiment of the invention. Method 700 may be performed at a chosen LFA node such as node 3 in FIG. 3. At reference 702, the node checks a received Ethernet frame and determines its destination MAC address and the incoming port. Then at reference 704, the node had a priori determines if it is closer to the destination of the received frame than the node facing the incoming port on the shortest path tree it is using for frame forwarding. In other words, the node determines whether or not it is downstream of the node it receiving the frame from (may be referring to as a neighboring sending node) with regard to the root (destination node). At reference 706, the node accepts the received frame for frame forwarding if the node is closer to the destination node (thus in downstream of the neighboring sending node), otherwise, the received frame is discarded. That is, the node only accepts a received frame for frame forwarding if the received frame is from a node upstream of the node with respect to the root. The updated set of safe ports then can be used to accept or discard future incoming frames. When a topology change occurs, non PLR nodes for a given ECT compare the PLR position with the previous distance from the root for all upstream nodes it does NOT have database synchronization with, and removes those from the acceptable set that there is a risk that they are now downstream. As database synchronization is re-achieved with these nodes, the set can then again be revised accordingly.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Allan’s Method And System Of Shortest Path Bridging (SPB) Enhanced Resilience With Loop Mitigation with Ranns’ Loop detection and prevention because it offers the advantage of using resilient loop free frame forwarding is essential for efficient data communication.
As per claim 11, Ranns in combination with Allan teaches the method according to claim 1, Ranns further teaches wherein the method further comprises: in response to determining that a loop exists in the data dependency path comprising the target node, triggering the target node to be disabled, to remove the loop (Ranns, Paragraph 0041 recites “FIG. 3B is a simplified block diagram of network 100, in which techniques to detect and prevent routing loops can be implemented. Like numbered elements of FIG. 3B correspond to those of FIG. 1A. In the example of FIG. 3B, node 116 is configured as a DF. Either or both of node 114 and node 116 receive traffic, e.g., multicast data packets addressed to a group that receiver 106 has joined, from core network 150. Both node 114 and node 116 would forward the received traffic onto LAN 130, resulting in duplicate packets being received by receiver 106 and formation of a routing loop. For example, if node 116 forwards a packet received from core network 150 onto LAN 130, in addition to receiver 106 receiving the packet, node 114 can pick up a copy of the packet from LAN 130, and forward the packet to core network 150. If the nodes in core network 150 forward the packet to node 116, a loop occurs, as shown by the curved arrows in FIG. 3B. However, since node 114 is not configured as the DF, node 116 forward the traffic onto LAN 130 and node 114 drops the traffic. That is, forwarding information on node 114 is configured such that traffic received on an interface coupled to LAN 130 (interface 2 in this example) by node 114 is dropped. Similarly, node 114 is configured to drop packets received on an interface coupled to core network 150 (interface 1 in this example.”).
Regarding claims 13 and 17, claims 13 and 17 are directed to a method and a computing device associated with the method of claim 1. Claims 13 and 17 are of similar scope to claim 1, and are therefore rejected under similar rationale.
Claim(s) 8-10 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ranns et al. (US 2017/0230277) and Allan et al. (US 9,461,909) and in further view of Suresh et al. (2020/0195439).
As per claim 8, Ranns in combination with Allan teaches the method according to claim 1, but fails to teach wherein the target node further maintains a private identifier and a public identifier that correspond to the target node, the public identifier is used to be transferred between nodes, the private identifier is used to indicate the node corresponding to the private identifier, and an initial value of the public identifier of the node is the same as an initial value of the private identifier; receiving the depth value that is of the upstream node of the target node and that is transferred by the upstream node comprises: receiving the depth value and a public identifier that are sent by the upstream node of the target node; and the determining that a loop exists in the data dependency path comprising the target node, in response to that the depth value of the target node is equal to the depth value that is of the upstream node of the target node and that is transferred by the upstream node comprises: in response to that the depth value of the target node is equal to the depth value that is of the upstream node of the target node and that is transferred by the upstream node, comparing a size of the private identifier of the target node with a size of the public identifier sent by the upstream node of the target node; in response to that the private identifier of the target node is unequal to the public identifier sent by the upstream node of the target node, further comparing a size of the public identifier of the target node with the size of the public identifier sent by the upstream node of the target node, and if the public identifier of the target node is less than the public identifier sent by the upstream node of the target node, updating the public identifier of the target node to the public identifier sent by the upstream node of the target node, to transfer the larger public identifier of the two nodes; and determining that a loop exists in the data dependency path comprising the target node, in response to that the private identifier of the target node is equal to the public identifier sent by the upstream node of the target node.
However, in an analogous art Suresh teaches wherein the target node further maintains a private identifier and a public identifier that correspond to the target node, the public identifier is used to be transferred between nodes, the private identifier is used to indicate the node corresponding to the private identifier, and an initial value of the public identifier of the node is the same as an initial value of the private identifier; receiving the depth value that is of the upstream node of the target node and that is transferred by the upstream node comprises: receiving the depth value and a public identifier that are sent by the upstream node of the target node; and the determining that a loop exists in the data dependency path comprising the target node, in response to that the depth value of the target node is equal to the depth value that is of the upstream node of the target node and that is transferred by the upstream node comprises: in response to that the depth value of the target node is equal to the depth value that is of the upstream node of the target node and that is transferred by the upstream node, comparing a size of the private identifier of the target node with a size of the public identifier sent by the upstream node of the target node; in response to that the private identifier of the target node is unequal to the public identifier sent by the upstream node of the target node, further comparing a size of the public identifier of the target node with the size of the public identifier sent by the upstream node of the target node, and if the public identifier of the target node is less than the public identifier sent by the upstream node of the target node, updating the public identifier of the target node to the public identifier sent by the upstream node of the target node, to transfer the larger public identifier of the two nodes; and determining that a loop exists in the data dependency path comprising the target node, in response to that the private identifier of the target node is equal to the public identifier sent by the upstream node of the target node (Suresh, Paragraph 0143 recites “Referring now to FIG. 8, depicted is a block diagram of a service node 506, according to an example embodiment. The service node 506 is shown to include a context establisher 800, a cryptographic agent 802, a routing token analyzer 804, and a network traffic router 812. In overview, the context establisher 800 may be configured to negotiate and establish the cryptographic context between the service node 506 and the server 502. The cryptographic agent 802 may be configured to encrypt and/or decrypt traffic according to one or more cryptographic contexts. The routing token analyzer 804 is shown to include a routing token reader 806, a routing token validator 808, and/or a client identifier 810. The routing token reader 806 and routing token validator 808 may be similar in at least some aspects to the routing token reader 702 and/or routing token validator 704 of the network device 508. For instance, the routing token reader 806 may be configured to identify, select or determine information or data contained in the service node routing token. The routing token validator 808 may be configured to validate the service node routing token and/or the server 502 based on the identifier information or data in the service node routing token. In certain embodiments, the routing token validator 808 may communicate and/or interoperate with the controller 602 to validate the service node routing token (e.g., similar to the routing token validator 704 of the network device 508). In some deployments or embodiments, there can pre-exist a secure control channel between the service node 506 and the controller 602, so that the initial connection establishment time can be improved. The client identifier 810 may be configured to identify or determine the client 504 which requested access to the service 510 executing on the server 502. The network traffic router 812 may be configured to route network traffic between the client 504 and server 502.” And Paragraph 0184 recites “In some embodiments, the server may validate the service node during negotiation of the cryptographic context. In some embodiments, the service node may validate the server during negotiation of the cryptographic context. Hence, the server may validate the service node and/or the service node may validate the server. The server and service node may validate one another using the same method or different respective methods. The server and service node may validate one another in a manner similar to validation of the routing tokens described above with reference to operation (915). For instance, the server and/or service node may validate one another based on a public/private key, a pre-shared key, a unique identifier or parameter, etc.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Suresh’s method for securing the rendezvous connection in a cloud service using routing tokens with Ranns’ Loop detection and prevention because it offers the advantage of validate the service node during negotiation of the cryptographic context or data access.
As per claim 9, Ranns in combination with Allan and Suresh teaches the method according to claim 8, Suresh further teaches wherein the method further comprises: further sending, by the target node, a loop detection message to the downstream node of the target node when it is determined that a loop exists in the data dependency path comprising the target node; and determining that a loop exists in the data dependency path comprising the target node, in response to receiving the loop detection message sent by the upstream node of the target node (Suresh, Paragraph 0143 recites “Referring now to FIG. 8, depicted is a block diagram of a service node 506, according to an example embodiment. The service node 506 is shown to include a context establisher 800, a cryptographic agent 802, a routing token analyzer 804, and a network traffic router 812. In overview, the context establisher 800 may be configured to negotiate and establish the cryptographic context between the service node 506 and the server 502. The cryptographic agent 802 may be configured to encrypt and/or decrypt traffic according to one or more cryptographic contexts. The routing token analyzer 804 is shown to include a routing token reader 806, a routing token validator 808, and/or a client identifier 810. The routing token reader 806 and routing token validator 808 may be similar in at least some aspects to the routing token reader 702 and/or routing token validator 704 of the network device 508. For instance, the routing token reader 806 may be configured to identify, select or determine information or data contained in the service node routing token. The routing token validator 808 may be configured to validate the service node routing token and/or the server 502 based on the identifier information or data in the service node routing token. In certain embodiments, the routing token validator 808 may communicate and/or interoperate with the controller 602 to validate the service node routing token (e.g., similar to the routing token validator 704 of the network device 508). In some deployments or embodiments, there can pre-exist a secure control channel between the service node 506 and the controller 602, so that the initial connection establishment time can be improved. The client identifier 810 may be configured to identify or determine the client 504 which requested access to the service 510 executing on the server 502. The network traffic router 812 may be configured to route network traffic between the client 504 and server 502.” And Paragraph 0184 recites “In some embodiments, the server may validate the service node during negotiation of the cryptographic context. In some embodiments, the service node may validate the server during negotiation of the cryptographic context. Hence, the server may validate the service node and/or the service node may validate the server. The server and service node may validate one another using the same method or different respective methods. The server and service node may validate one another in a manner similar to validation of the routing tokens described above with reference to operation (915). For instance, the server and/or service node may validate one another based on a public/private key, a pre-shared key, a unique identifier or parameter, etc.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Suresh’s method for securing the rendezvous connection in a cloud service using routing tokens with Ranns’ Loop detection and prevention because it offers the advantage of validate the service node during negotiation of the cryptographic context or data access.
As per claim 10, Ranns in combination with Allan and Suresh teaches the method according to claim 9, Suresh further teaches wherein the private identifier is a globally unique node identifier indicating a priority of a node; the loop detection message comprises the private identifier of the target node, and when receiving the loop detection message, after determining that a public identifier of the downstream node of the target node is the same as the private identifier of the target node, the downstream node of the target node adds a private identifier of the downstream node to the loop detection message, and then continues to send the loop detection message downstream, and so on, to transfer a private identifier of each node in the data dependency path downstream; and the method further comprises: in response to receiving the loop detection message sent by the upstream node of the target node, obtaining the private identifier that is of each node and that is carried in the loop detection message, and determining that a node that has the highest priority and that is indicated by the private identifier of each node is a loop processing node; and triggering the loop processing node to be disabled, to remove the loop (Suresh, Paragraph 0143 recites “Referring now to FIG. 8, depicted is a block diagram of a service node 506, according to an example embodiment. The service node 506 is shown to include a context establisher 800, a cryptographic agent 802, a routing token analyzer 804, and a network traffic router 812. In overview, the context establisher 800 may be configured to negotiate and establish the cryptographic context between the service node 506 and the server 502. The cryptographic agent 802 may be configured to encrypt and/or decrypt traffic according to one or more cryptographic contexts. The routing token analyzer 804 is shown to include a routing token reader 806, a routing token validator 808, and/or a client identifier 810. The routing token reader 806 and routing token validator 808 may be similar in at least some aspects to the routing token reader 702 and/or routing token validator 704 of the network device 508. For instance, the routing token reader 806 may be configured to identify, select or determine information or data contained in the service node routing token. The routing token validator 808 may be configured to validate the service node routing token and/or the server 502 based on the identifier information or data in the service node routing token. In certain embodiments, the routing token validator 808 may communicate and/or interoperate with the controller 602 to validate the service node routing token (e.g., similar to the routing token validator 704 of the network device 508). In some deployments or embodiments, there can pre-exist a secure control channel between the service node 506 and the controller 602, so that the initial connection establishment time can be improved. The client identifier 810 may be configured to identify or determine the client 504 which requested access to the service 510 executing on the server 502. The network traffic router 812 may be configured to route network traffic between the client 504 and server 502.” And Paragraph 0184 recites “In some embodiments, the server may validate the service node during negotiation of the cryptographic context. In some embodiments, the service node may validate the server during negotiation of the cryptographic context. Hence, the server may validate the service node and/or the service node may validate the server. The server and service node may validate one another using the same method or different respective methods. The server and service node may validate one another in a manner similar to validation of the routing tokens described above with reference to operation (915). For instance, the server and/or service node may validate one another based on a public/private key, a pre-shared key, a unique identifier or parameter, etc.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Suresh’s method for securing the rendezvous connection in a cloud service using routing tokens with Ranns’ Loop detection and prevention because it offers the advantage of validate the service node during negotiation of the cryptographic context or data access.
As per claim 14, Ranns in combination with Allan teaches the method according to claim 13, but fails to teach wherein the target node further maintains a private identifier and a public identifier that correspond to the target node, the public identifier is used to be transferred between nodes, the private identifier is used to indicate the node corresponding to the private identifier, and an initial value of the public identifier of the node is the same as an initial value of the private identifier; the receiving a depth value sent by an upstream node of the target node comprises: receiving the depth value and a public identifier that are sent by the upstream node of the target node; and the determining that a loop exists in the data dependency path comprising the target node, in response to that the depth value of the target node is equal to the depth value that is of the upstream node of the target node and that is transferred by the upstream node comprises: in response to that the depth value of the target node is equal to the depth value sent by the upstream node of the target node, comparing a size of the private identifier of the target node with a size of the public identifier sent by the upstream node of the target node; in response to that the private identifier of the target node is unequal to the public identifier sent by the upstream node of the target node, further comparing a size of the public identifier of the target node with the size of the public identifier sent by the upstream node of the target node, and if the public identifier of the target node is less than the public identifier sent by the upstream node of the target node, updating the public identifier of the target node to the public identifier sent by the upstream node of the target node, to transfer the larger public identifier of the two nodes; and determining that a loop exists in the data dependency path comprising the target node, in response to that the private identifier of the target node is equal to the public identifier sent by the upstream node of the target node.
However, in an analogous art Suresh teaches wherein the target node further maintains a private identifier and a public identifier that correspond to the target node, the public identifier is used to be transferred between nodes, the private identifier is used to indicate the node corresponding to the private identifier, and an initial value of the public identifier of the node is the same as an initial value of the private identifier; the receiving a depth value sent by an upstream node of the target node comprises: receiving the depth value and a public identifier that are sent by the upstream node of the target node; and the determining that a loop exists in the data dependency path comprising the target node, in response to that the depth value of the target node is equal to the depth value that is of the upstream node of the target node and that is transferred by the upstream node comprises: in response to that the depth value of the target node is equal to the depth value sent by the upstream node of the target node, comparing a size of the private identifier of the target node with a size of the public identifier sent by the upstream node of the target node; in response to that the private identifier of the target node is unequal to the public identifier sent by the upstream node of the target node, further comparing a size of the public identifier of the target node with the size of the public identifier sent by the upstream node of the target node, and if the public identifier of the target node is less than the public identifier sent by the upstream node of the target node, updating the public identifier of the target node to the public identifier sent by the upstream node of the target node, to transfer the larger public identifier of the two nodes; and determining that a loop exists in the data dependency path comprising the target node, in response to that the private identifier of the target node is equal to the public identifier sent by the upstream node of the target node (Suresh, Paragraph 0143 recites “Referring now to FIG. 8, depicted is a block diagram of a service node 506, according to an example embodiment. The service node 506 is shown to include a context establisher 800, a cryptographic agent 802, a routing token analyzer 804, and a network traffic router 812. In overview, the context establisher 800 may be configured to negotiate and establish the cryptographic context between the service node 506 and the server 502. The cryptographic agent 802 may be configured to encrypt and/or decrypt traffic according to one or more cryptographic contexts. The routing token analyzer 804 is shown to include a routing token reader 806, a routing token validator 808, and/or a client identifier 810. The routing token reader 806 and routing token validator 808 may be similar in at least some aspects to the routing token reader 702 and/or routing token validator 704 of the network device 508. For instance, the routing token reader 806 may be configured to identify, select or determine information or data contained in the service node routing token. The routing token validator 808 may be configured to validate the service node routing token and/or the server 502 based on the identifier information or data in the service node routing token. In certain embodiments, the routing token validator 808 may communicate and/or interoperate with the controller 602 to validate the service node routing token (e.g., similar to the routing token validator 704 of the network device 508). In some deployments or embodiments, there can pre-exist a secure control channel between the service node 506 and the controller 602, so that the initial connection establishment time can be improved. The client identifier 810 may be configured to identify or determine the client 504 which requested access to the service 510 executing on the server 502. The network traffic router 812 may be configured to route network traffic between the client 504 and server 502.” And Paragraph 0184 recites “In some embodiments, the server may validate the service node during negotiation of the cryptographic context. In some embodiments, the service node may validate the server during negotiation of the cryptographic context. Hence, the server may validate the service node and/or the service node may validate the server. The server and service node may validate one another using the same method or different respective methods. The server and service node may validate one another in a manner similar to validation of the routing tokens described above with reference to operation (915). For instance, the server and/or service node may validate one another based on a public/private key, a pre-shared key, a unique identifier or parameter, etc.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Suresh’s method for securing the rendezvous connection in a cloud service using routing tokens with Ranns’ Loop detection and prevention because it offers the advantage of validate the service node during negotiation of the cryptographic context or data access.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ranns et al. (US 2017/0230277) and Allan et al. (US 9,461,909) and in further view of Aronovich (US 2020/0301757).
As per claim 12, Ranns in combination with Allan teaches the method according to claim 1, but fails to teach wherein the distributed system comprises a distributed database system, the node comprises a transaction process configured to execute a database transaction, and the data dependency path comprises a path in a WPG wait-for graph constructed based on a lock waiting relationship between transaction processes in the distributed database system.
However, in an analogous art Aronovich teaches wherein the distributed system comprises a distributed database system, the node comprises a transaction process configured to execute a database transaction, and the data dependency path comprises a path in a WPG wait-for graph constructed based on a lock waiting relationship between transaction processes in the distributed database system (Aronovich, Paragraph 0016 recites “Prior implementations have been considered in attempt to detect resource deadlocks, however these implementations generally fail to actually resolve the deadlock once it occurs. For example, in path pushing algorithms, distributed deadlocks are detected by maintaining an explicit global Wait-For-Graph (WFG). Each site maintains a local WFG, and when a deadlock computation is performed, a respective site sends its local WFG to all the neighboring sites. Each site that receives a WFG from another site combines the received WFG with its local WFG to build an updated WFG, and passes this updated WFG to other sites. The procedure is repeated until a given site has a sufficiently complete picture of the global state to determine that a deadlock exists or to establish that no deadlocks are present.”).
It would have been obvious to a person of ordinary skill in the art, at the earliest effective filing date to use Aronovich’s deadlock resolution between distributed processes using process and group information with Ranns’ Loop detection and prevention because it offers the advantage of using Wait-For-Graph is a tool in deadlock detection due to its ability to simplify the analysis of resource contention by focusing solely on wait relationships.
Allowable Subject Matter
Claims 3-7 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RODERICK TOLENTINO whose telephone number is (571)272-2661. The examiner can normally be reached Mon- Fri 8am-4pm.
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, Luu Pham can be reached at 571-270-5002. 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.
RODERICK . TOLENTINO
Examiner
Art Unit 2439
/RODERICK TOLENTINO/Primary Examiner, Art Unit 2439