Robin Systems, Inc.

Patent Trials and Appeals Board

Mar 15, 2022

2021001928 (P.T.A.B. Mar. 15, 2022)

UNITED STATES PATENT AND TRADEMARK OFFICE UNITED STATES DEPARTMENT OF COMMERCE United States Patent and Trademark Office Address: COMMISSIONER FOR PATENTS P.O. Box 1450 Alexandria, Virginia 22313-1450 www.uspto.gov APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO. 15/868,818 01/11/2018 Dhanashankar Venkatesan ROBN-01902 3639 34051 7590 03/15/2022 Stevens Law Group 1754 Technology Dr. Ste 226 San Jose, CA 95110 EXAMINER CARDWELL, ERIC ART UNIT PAPER NUMBER 2139 NOTIFICATION DATE DELIVERY MODE 03/15/2022 ELECTRONIC Please find below and/or attached an Office communication concerning this application or proceeding. The time period for reply, if any, is set in the attached communication. Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the following e-mail address(es): uspto@stevenslawgroup.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte DHANASHANKAR VENKATESAN and MANJUNATH MAGESWARAN Appeal 2021-001928 Application 15/868,818 Technology Center 3600 Before CAROLYN THOMAS, HUNG BUI, and NABEEL U. KHAN, Administrative Patent Judges. KHAN, Administrative Patent Judge. DECISION ON APPEAL STATEMENT OF THE CASE Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the Examiner’s decision to reject claims 1, 4-11, and 14-20. We have jurisdiction under 35 U.S.C. § 6(b). We AFFIRM. 1 “Appellant” refers to “applicant” as defined in 37 C.F.R. § 1.42(a). Appellant identifies the real party in interest as Robin Systems, Inc. Appeal Br. 3. Appeal 2021-001928 Application 15/868,818 2 CLAIMED SUBJECT MATTER Appellant identifies paragraphs 228-232 of the Specification and Figures 28A-28C as providing support for subject matter of claim 1. Appeal Br. 3-4. Figures 28A and 28B are reproduced below: Figures 28A and 28B above illustrate an implementation of containers and storage volumes in a storage area network (SAN) in accordance with an embodiment of the invention. Spec. ¶ 33. The SAN is comprised of storage devices such as hard drives and solid state drives (2802a-2802c) which are coupled to logical units (LUNs 2806a-2806c) by a network fabric 2804. Spec. ¶ 228. Multiple storage nodes 106a-106c may mount to the LUNs and may act as interfaces for containers 1320a-1320b to the SAN system. Spec. ¶ 229. Containers 1320a-1320b may then submit input/output operations to the SAN by way of storage nodes 106a-106c. Spec. ¶ 229. Orchestration layer 1300 maintains data regarding the SAN system including the status of storage nodes. Spec. ¶ 230. If a storage node reports a problem Appeal 2021-001928 Application 15/868,818 3 or fails to check in, the status data may be updated to indicate the failure of the storage node. Spec. ¶ 230. Figure 28B depicts a failure of storage node 106a. In the event of failure of storage node 106a, the orchestration layer 1300 directs another storage node 106b to connect LUN 2806a and mount the LUN. Spec. ¶ 231. Containers 1320a that previously accessed the SAN through failed storage node 106a may then be directed to connect to storage node 106b. Spec. ¶ 231. The Specification explains that this transition from storage node 106a to storage node 106b requires minimal transfer of data and is therefore seamless. Spec. ¶ 232. Claim 1, reproduced below with annotations indicating the disputed limitations, illustrates the claimed subject matter: 1. A method, comprising: providing a plurality of computing resources in a distributed computing system; executing a plurality of containers on the plurality of computing resources, each container controlling execution of an application instance; associating an interface to a cloud storage system to each container of the plurality of containers; for each interface, provisioning a storage volume in the cloud storage system; and accessing, by each container of the plurality of containers, the storage volume provisioned for the interface to the cloud storage system associated to the each container; wherein the plurality of computing resources comprises a plurality of compute nodes and a plurality of storage nodes, the plurality of compute nodes and the plurality of storage nodes being external to the cloud storage system, the method further comprising: Appeal 2021-001928 Application 15/868,818 4 providing the plurality of storage nodes such that each storage node of the plurality of storage nodes mounts the interface to the cloud storage system for at least one container of the plurality of containers; accessing, by each container of the plurality of containers, through one of the plurality of storage nodes, the storage volume provisioned for the interface to the cloud storage system associated to the each container; detecting failure of a first storage node of the plurality of storage nodes having a first interface to the cloud storage system mounted thereto, the first interface being associated to a first container of the plurality of containers; and in response to detecting failure of the first storage node: associating the first interface with a second storage node of the plurality of storage nodes; and instructing the first container to access the first interface through the second storage node. Appeal Br. 15-16 (Claims App.). REFERENCES The prior art relied upon by the Examiner is: Name Reference Date Coatney US 2014/0047263 A1 Feb. 13, 2014 Rangasamy US 2017/0244787 A1 Aug. 24, 2017 Rao US 2018/0285353 A1 Oct. 4, 2018 REJECTIONS 1. Claims 1, 4, 8-11, 14, and 18-20 stand rejected under 35 U.S.C. § 103 as unpatentable over Rangasamy and Coatney. Final Act. 3-9. 2. Claims 5-7 and 15-17 stand rejected under 35 U.S.C. § 103 as unpatentable over Rangasamy, Coatney, and Rao. Final Act. 9-11. Appeal 2021-001928 Application 15/868,818 5 OPINION Claim 1 recites: detecting failure of a first storage node of the plurality of storage nodes having a first interface to the cloud storage system mounted thereto, the first interface being associated to a first container of the plurality of containers; and in response to detecting failure of the first storage node: associating the first interface with a second storage node of the plurality of storage nodes; and instructing the first container to access the first interface through the second storage node. Appeal Br. 15 (Claims App.) The Examiner finds that Rangasamy teaches most of the limitations of claim 1, including the storage nodes, interface, cloud storage system, containers, and interface. Final Act. 3-7 (citing Rangsamy ¶¶ 26, 27, 29, 38, 67, and 121). The Examiner acknowledges that Rangasamy does not explicitly teach, but relies upon Coatney for detecting failure of the first storage node and the claimed response to the detection of the failure. Final Act. 5-7. Specifically, the Examiner finds Coatney teaches that in the event of a failure of a local cluster node, the failed node is replaced with another cluster node and the IP address for the Vserver (the recited “first container”) is mapped to the IP address of the replacement cluster node. Final Act. 6-7 (citing Coatney ¶¶ 76-77). The Examiner further finds that Coatney’s interface modules 421A through 421n are configured to receive cluster switchover and/or switchback requests and that in the event of a local railure, the HA partner of the failed node takes over responsibility for the failed node. Final Act. 7 (citing Coatney ¶¶ 77, 82, 85, Figs. 13, 15). Appeal 2021-001928 Application 15/868,818 6 Appellant argues the nodes that fail in Coatney “are the fabric storage system rather than defining interfaces to an external cloud storage system.” Appeal Br. 7; see also id. at 6 (“However, each node in the HA configuration is part of the storage fabric and stores the actual data, as opposed to being an interface to a cloud storage system that stores the actual data.”); id. at 8 (“This IP address is not described as being an interface to an external cloud storage system: the nodes are the storage fabric and therefore this is not an interface to an external cloud storage system”); id. at 10 (“Coatney discloses that failure of a storage node results in fail over to a different storage node. However, the storage nodes store the data. The storage nodes do not provide an interface through which an external cloud storage network is accessed”). Similarly, Appellant argues Coatney’s “V servers are the storage devices that store the data and provide replication for one another” and that “it cannot be that the Vservers are containers accessing a cloud storage system through an interface on a storage node when the V servers are the storage devices making up the cloud storage system itself.” Appeal Br. 11 (citing Coatney ¶ 74). Appellant further argues that in Coatney “the interfaces 421A, 421n are not transferred from one Node Al, An to another. In particular, the interfaces 421A, 421n are describes as receiving switchover requests in the event of failure and therefore there is no basis for an interface 421A, 421n to be transferred in the event of a failure.” Appeal Br. 11 (citing Coatney ¶ 77). We are unpersuaded by Appellant’s arguments. As the Examiner explains in the Answer, Coatney’s cluster nodes, such as Nodes A1 and B1 Appeal 2021-001928 Application 15/868,818 7 depicted in Figure 4C of Coatney, have access to disk 412a1 and if Node A1 fails, Node B1 continues to have access to disk 412a1. Thus, the Examiner finds that Nodes A1 and B1 cannot be the storage fabric which stores the actual data (as alleged by Appellant) since even if one of them fails, the other still has access to the stored data. Ans. 8. The Examiner finds that Coatney describes the cluster nodes as writing data “out to one or more disks in the shared storage fabric” (Coatney ¶ 85) which the Examiner finds supports the conclusion that the cluster nodes do not store the data and are not the shared storage fabric. Ans. 8. For the same reasons we are unpersuaded of Appellant’s argument that Coatney’s Vservers are not containers accessing a cloud storage system because the Vservers are the storage devices. Appeal Br. 11. As explained by Coatney the data is stored in disks (such as disk 412a1) in the shared storage fabric. Coatney ¶ 85. We are also unpersuaded by Appellant’s argument that Coatney’s IP address or interfaces 421A, 421n are not an interfaces to the cloud storage system. See Appeal Br. 8, 11; Reply Br. 4 (the “IP address is only described as being used to route traffic by the Vserver to the original and remote cluster nodes and is not described as being used to route traffic between the cluster nodes and the share storage fabric.”); Reply Br. 5 (“the interface modules 421A, 421n are simply interfaces to the cluster node 416 of which they are a part and their function is to process switchover and/or switchback requests.”). Instead we agree with the Examiner that the main purpose of the IP address is to be used to interface with the cluster node and to the storage network. Ans. 9. The Examiner finds that the IP address is used for reading and writing commands and is used to navigate through numerous storage devices. Ans. 9. The Examiner finds that Coatney teaches that when a node Appeal 2021-001928 Application 15/868,818 8 fails the first interface (IP address) is mapped to the IP address of the replacement cluster node. Similarly, the Examiner finds that “the interface modules 421a and 421n are configured to receive cluster switchover and/or switchback requests.” Ans. 5 (quoting Coatney ¶ 77). These disclosures, according to the Examiner are analogous to the description of the node failover procedure outlined in Appellant’s Specification. Ans. 10 (citing Spec. ¶ 231). We agree with the Examiner. Coatney teaches that: when a cluster node is replaced with another cluster node during failover, the LIF (e.g., IP address) for the V server is not changed, but mapped to the IP address of the replacement cluster node by the cluster management module 412. Thus, in the case of cluster failover, the LIF may be mapped to a remote cluster node (i.e., the remote DR partner) which is located in another cluster. Coatney ¶ 76. Similarly, Coatney teaches that “[i]n one embodiment, the interface modules 421A and 421n are configured to receive cluster switchover and/or switchback requests.” These disclosures show that in the case of node failure, a transition from a failed node to a replacement node occurs in the same way described by the Specification of transitioning from the failed storage node to the second storage node. Spec. ¶ 231 (“In the event that a storage node 106a fails, or otherwise becomes unable to operate as an interface to a LUN 2806a, the orchestration layer 1300 may direct another storage node 106b to connect to that LUN 2806a and mount the LUN 2806a as a storage device of that storage node 106b.”) Appellant argues the claims together as a group. See Appeal Br. 13. Accordingly, we sustain the Examiner’s rejection of claims 1, 4-11, 14-20. CONCLUSION The Examiner’s rejections are affirmed. Appeal 2021-001928 Application 15/868,818 9 DECISION SUMMARY In summary: Claim(s) Rejected 35 U.S.C. § Reference(s)/Basis Affirmed Reversed 1, 4, 8-11, 14, 18-20 103 Rangasamy, Coatney 1, 4, 8-11, 14, 18-20 5-7, 15-17 103 Rangasamy, Coatney, Rao 5-7, 15-17 Overall Outcome 1, 4-11, 14- 20 TIME PERIOD FOR RESPONSE No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a)(1). See 37 C.F.R. § 1.136(a)(1)(iv) (2019). AFFIRMED