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 .
This Office Action is in response to claims filed on 04/27/2026.
Claims 1-6 and 10-23 are pending.
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 1-6 and 10-23 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as 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 1-6, and 13-21 are directed to a method and fall within the statutory category of processes. Claim 10 is directed to a system and falls within the statutory category of machines. Claim 11 is directed to a computer program product and falls within the statutory category of machines. Claim 12 is directed to a computer-readable medium and falls within the statutory category of machines. Claim 22 is directed to a computer program product and falls within the statutory category of machines. Claim 23 is directed to a computer program product and falls within the statutory category of machines. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claims 1, 10-12, 22, and 23: The limitations of “allocating one or more clocks of the pool of clocks to client containers in the one or more containers or to client virtual machines of the one or more virtual machines, thereby obtaining allocated clocks allocated to the client containers or the client virtual machines;”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally allocate one or more clocks to client containers or client virtual machines, this can be done through mental assignment/mapping of clocks to client containers or client virtual machines. This may also be done with pencil and paper. Further, claims 22 and 23 recite additional abstract idea recitations of “wherein a clock of the pool of clocks is allocated to at least two client containers or to at least two client virtual machines or to at least one client container and at least one client virtual machine”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally allocate a clock to at least two client containers or to at least two client virtual machines or to at least one client container and at least one client virtual machine, this can be done through mental assignment/mapping of the clock to client containers or client virtual machines. This may also be done with pencil and paper. Further, claim 23 the claim recites additional abstract idea recitations of “and wherein the allocation is based on a request to join a time domain requested by a client container or by a client virtual machine or by an application running thereon”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can observe a request to join a time domain, and based on this observation, can mentally allocate one or more clocks to client containers or client virtual machines, this can be done through mental assignment/mapping of clocks to client containers or client virtual machines. This may also be done with pencil and paper.
Therefore, Yes, claims 1, 10-12, 22, and 23 recite a judicial exception.
Step 2A Prong 2:
Claims 1, 10-12, 22, and 23: The judicial exception is not integrated into a practical application. In particular, the claims recite additional element recitations of “A computer program product comprising instructions which, when executed by a computer, cause the computer to carry out”, “A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out”, “the method comprising: creating a pool of clocks;”, “executing one or more containers in an operating system level virtualization or one or more virtual machines running on an executing hardware device;”, “at least one clock;” and “a hardware device configured for executing one or more software applications inside a container of an operating system level virtualization or in a virtual machine;” which are merely recitations of generic computer functions and components used as a tool to apply the abstract idea (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application. Further, the claims recite additional element recitations of “A system for executing software applications running in containers of an operating system level virtualization or in virtual machines, the system comprising:”, “wherein the time signal in a time domain is based on a respective allocated hardware clock or software clock and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine;”, and “wherein the one or more containers or the one or more virtual machines are executed on the hardware device”, which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, the claims recite additional element recitations of “A method for automatically providing a time signal to containers in an operating system level virtualization or to virtual machines,”, “wherein each of the allocated clocks provides a time signal in a time domain to at least one of the client containers or to at least one of the client virtual machines;”, “or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks;”, and “or wherein the time signal in a time domain is provided by intercepting time system calls and handling the time system calls based on an allocated clock”, which are merely recitations of data transmission and retrieval which are insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application.
Therefore, “Do the claims recite additional elements that integrate the judicial exception into 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 claims are directed to an abstract idea.
After having evaluated the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1, 10-12, 22, and 23 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:
Claims 1, 10-12, 22, and 23: 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 with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than generic computing components, field of use/technological environment, and insignificant extra solution activity which do not amount to significantly more than the abstract idea. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)].
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, Claims 1, 10-12, 22, and 23 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 2, the claim recites additional abstract idea recitations of “wherein a clock of the pool of clocks is allocated to at least two client containers or to at least two client virtual machines or to at least one client container and at least one client virtual machine”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally allocate a clock to at least two client containers or to at least two client virtual machines or to at least one client container and at least one client virtual machine, this can be done through mental assignment/mapping of the clock to client containers or client virtual machines. This may also be done with pencil and paper. Further, claim 2 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 2 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 2 does not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 3 and 13, the claims recite additional abstract idea recitations of “wherein the allocation is based on a request to join a time domain requested by a client container or by a client virtual machine or by an application running thereon”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can observe a request to join a time domain, and based on this observation, can mentally allocate one or more clocks to client containers or client virtual machines, this can be done through mental assignment/mapping of clocks to client containers or client virtual machines. This may also be done with pencil and paper. Further, claims 3 and 13 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 3 and 13 also fail both Step 2A prong 2, thus the claim is directed to the judicial exception as it has not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, Claims 3 and 13 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 4 and 14, the claims recite additional element recitations of “wherein the request comprises a request for a time signal in a time domain provided by a clock with a specified clock type;”, “and wherein the request further includes a read or write permission of the time signal in a time domain;”, and “or wherein the request includes a joining request to join a time signal in a time domain provided by an already allocated clock”, which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, claims 4 and 14 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 4 and 14 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, Claims 4 and 14 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 5 and 15-17, the claims recite additional element recitations of “wherein a clock type includes a hardware type or a software type,” and “wherein a software type identifies a clock obtained based on a map applied to a master clock”, which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, claims 5 and 15-17 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 5 and 15-17 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, Claims 5 and 15-17 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 6 and 18-21, the claims recite additional element recitations of “wherein each time signal in a time domain is synchronized to a respective clock and is accessible for reading or writing independent of different time signals in different time domains” and “or wherein each time signal is synchronizable with further time signals in time domains provided by the allocated clocks”, which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, claims 6 and 18-21 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 6 and 18-21 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, Claims 6 and 18-21 do not recite patent eligible subject matter under 35 U.S.C. § 101.
Therefore, Claims 1-6 and 10-23 do not recite patent eligible subject matter under U.S.C. §101.
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.
Claims 1, 2, 5, 6, 10-12, 15, 18, 21, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Hubbe (US 2023/0006807 A1) in view of Ridoux (US 11,853,114 B1).
Regarding Claim 1, Hubbe teaches:
A method for automatically providing a time signal to containers in an operating system level virtualization or to virtual machines, “…using the hardware clock to provide a hardware timestamp value to a virtual machine (VM) running on the host computer or to a process running on the host computer…” [Hubbe ¶ 4]. “A HW clock has a current time value and advances at a rate. The rate can be proportional to a timing signal such as pulses in a clock signal” [Hubbe ¶ 44].
the method comprising: creating a pool of clocks; “The peripheral component card be configured to implement a plurality of hardware clocks, be installed in a host computer, use a network communications protocol to synchronize the hardware clocks within a plurality of clock domains identified by a plurality of clock domain identifiers, associate the clock domain identifiers with a plurality of virtual clock domain identifiers that identify a plurality of virtual clock domains, and provide a hardware timestamp value to a virtual machine running on the host computer based on the one of the virtual clock domains associated with the virtual machine” [Hubbe ¶ 6]. “The method can include maintaining a plurality of clock domains on a plurality of hardware clocks in a plurality of network interface cards (NICs) installed in a plurality of host computers, wherein a plurality of clock domain identifiers identify the plurality of clock domains …” [Hubbe ¶ 5].
executing one or more containers in an operating system level virtualization or one or more virtual machines running on an executing hardware device; “In some implementations of the methods and devices, a plurality of VMs running on a plurality of host computers are associated with a virtual clock domain identifier that identifies a virtual clock domain, a plurality of NICs installed in the host computers synchronize a plurality of hardware clocks in the virtual clock domain, and the VMs obtain a plurality of hardware timestamp values from the plurality of hardware clocks” [Hubbe ¶ 7].
allocating one or more clocks of the pool of clocks to client containers in the one or more containers or to client virtual machines of the one or more virtual machines, “FIG. 2 is a high-level diagram illustrating a mapping between virtual clock domains (vCDs), clock domains (CDs), and hardware clocks according to some aspects” [Hubbe ¶ 13]. “The method can include maintaining a plurality of clock domains on a plurality of hardware clocks in a plurality of network interface cards (NICs) installed in a plurality of host computers … the NICs are configured to associate the clock domain identifiers with a plurality of virtual clock domain identifiers that identify a plurality of virtual clock domains, and a plurality of virtual machines (VMs) running on the host computers obtain hardware timestamp values from the NICs via the virtual clock domain identifiers” [Hubbe ¶ 5]. “In some implementations of the methods and devices, the VM and the clock domain identifier are associated with a virtual clock domain identifier, the virtual clock domain identifier identifies a virtual clock domain of the VM” [Hubbe ¶ 7].
thereby obtaining allocated clocks allocated to the client containers or the client virtual machines; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein each of the allocated clocks provides a time signal in a time domain to at least one of the client containers or to at least one of the client virtual machines; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein the time signal in a time domain is based on a respective allocated hardware clock or software clock “The vCD access point can be configured with a vCD identifier 704 that identifies the vCD associated with the VM. In this manner, the VM can use the vCD to read a HW clock. For example, the VM may be one of a group of VMs implementing a tenant's workload that is synchronized via the vCD” [Hubbe ¶ 67].
…and handling the time system calls based on an allocated clock. “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
Hubbe fails to explicitly teach and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls.
However, Ridoux teaches:
and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; “Additionally or alternatively, the isolated timing hardware 20 may provide access to the hardware clock 24 via a virtualized hardware clock 34 of the instance 116. Similarly to a virtualized network device 32, the virtualized hardware clock 34 can represent software executing on the host computing device 115 that appears, from the point of view of the instance 116, to represent hardware. For example, the virtualized hardware clock 34 may be represented in a Unix-like operating system of the instance 116 as a device (e.g., "/dev/phc")” [Ridoux Col. 14 Lines 11-20].
or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls “Accordingly, network communications from the instance 116 may traverse the isolated timing hardware 20 prior to transmission on the network 104. In the case of queries to the time server 22, the hardware 20 may intercept such transmission and provide a response, thus foregoing transmission on the network 104” [Ridoux Col. 14 Lines 1-6].
Ridoux is considered to be analogous to the claimed invention because it is in the same field of generating or distributing clock signals. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hubbe to incorporate the teachings of Ridoux and include and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls. Doing so would allow for applications to have local clock access. “However, unlike traditional network protocols, the interactions occur locally rather than over a network. In combination with a highly accurate hardware clock 24, these interactions thus facilitate highly accurate synchronization of the system clock 14” [Ridoux Col. 19-20 Lines 65-67, 1-4].
Regarding Claim 2, Hubbe in view of Ridoux teaches the method of claim 1, as referenced above. Hubbe further teaches wherein a clock of the pool of clocks is allocated to at least two client containers or to at least two client virtual machines or to at least one client container and at least one client virtual machine. “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
Regarding Claim 5, Hubbe in view of Ridoux teaches the method of claim 1, as referenced above. Hubbe further teaches:
wherein a clock type includes a hardware type or a software type, “FIG. 7 is a high-level diagram illustrating a virtual machine 701 accessing a hardware clock 708 via a virtual clock domain (vCD) access point 703 according to some aspects. A process running in a VM 701 can attempt to read a time value from a HW (type) clock. The process can use the VM's device driver 702 to access a VF that functions as a vCD access point. From the VM's perspective, the device driver may be providing access to a system's only hardware clock. From the perspective of the PCIe device (e.g., smartNIC 430) the VM can be accessing a vCD access point 703 that is implemented as a PCIe VF. The vCD access point can be configured with a vCD identifier 704 that identifies the vCD associated with the VM. In this manner, the VM can use the vCD to read a HW clock” [Hubbe ¶ 67].
wherein a software type identifies a clock obtained based on a map applied to a master clock. “The VM, attempting to read the system clock, tries to read a time value via a VF implementing a vCD access point. The PCIe device can use the vCD to CD to HW clock mapping table 705 and the vCD identifier 704 to identify a HW clock” [Hubbe ¶ 67]. “From the VM's perspective, the device driver may be providing access to a system's only hardware clock. From the perspective of the PCIe device (e.g., smartNIC 430) the VM can be accessing a vCD access point 703 that is implemented as a PCIe VF” [Hubbe ¶ 67].
Regarding Claim 6, Hubbe in view of Ridoux teaches the method of claim 1, as referenced above. Hubbe further teaches:
wherein each time signal in a time domain is synchronized to a respective clock “For example, the VM may be one of a group of VMs implementing a tenant's workload that is synchronized via the vCD. The VM, attempting to read the system clock, tries to read a time value via a VF implementing a vCD access point. The PCIe device can use the vCD to CD to HW clock mapping table 705 and the vCD identifier 704 to identify a HW clock. The current time 709 of the hardware clock 708 can be provided to the VM's device driver 702” [Hubbe ¶ 67].
and is accessible for reading or writing “A process running in a VM 701 can attempt to read a time value from a HW clock. The process can use the VM's device driver 702 to access a VF that functions as a vCD access point” [Hubbe ¶ 67].
independent of different time signals in different time domains “Hardware clock synchronization executable code 104 is computer code that can be executed to thereby synchronize one or more of the hardware clocks 105 to one or more reference clocks. For example, and as is well known in the art, the reference clock can be the reference clock for a specific CD, PTP packets can be used for synchronization within that CD, and PTP stacks can process the PTP packets to thereby synchronize one or more of the HW clocks 105 to the reference clock 101” [Hubbe ¶ 41].
or wherein each time signal is synchronizable with further time signals in time domains provided by the allocated clocks. “A virtual clock domain (vCD) to clock domain (CD) to hardware (HW) clock mapping table 109 can indicate which HW clock is in which CD such that the hardware clock synchronization executable code 104 can synchronize the HW clocks within the correct CDs” [Hubbe ¶ 40].
Regarding Claim 10, Hubbe teaches:
A system for executing software applications running in containers of an operating system level virtualization or in virtual machines, “In some implementations of the methods and devices, a plurality of VMs running on a plurality of host computers are associated with a virtual clock domain identifier that identifies a virtual clock domain…” [Hubbe ¶ 7].
the system comprising: at least one clock; “The method can include maintaining a plurality of clock domains on a plurality of hardware clocks in a plurality of network interface cards (NICs) installed in a plurality of host computers, wherein a plurality of clock domain identifiers identify the plurality of clock domains …” [Hubbe ¶ 5].
a hardware device configured for executing one or more software applications inside a container of an operating system level virtualization or in a virtual machine; “In some implementations of the methods and devices, a plurality of VMs running on a plurality of host computers are associated with a virtual clock domain identifier that identifies a virtual clock domain…” [Hubbe ¶ 7].
the hardware device further configured to perform a method for automatically providing a time signal to containers in an operating system level virtualization or to virtual machines, “…using the hardware clock to provide a hardware timestamp value to a virtual machine (VM) running on the host computer or to a process running on the host computer…” [Hubbe ¶ 4]. “A HW clock has a current time value and advances at a rate. The rate can be proportional to a timing signal such as pulses in a clock signal” [Hubbe ¶ 44].
the method comprising: creating a pool of clocks; “The peripheral component card be configured to implement a plurality of hardware clocks, be installed in a host computer, use a network communications protocol to synchronize the hardware clocks within a plurality of clock domains identified by a plurality of clock domain identifiers, associate the clock domain identifiers with a plurality of virtual clock domain identifiers that identify a plurality of virtual clock domains, and provide a hardware timestamp value to a virtual machine running on the host computer based on the one of the virtual clock domains associated with the virtual machine” [Hubbe ¶ 6]. “The method can include maintaining a plurality of clock domains on a plurality of hardware clocks in a plurality of network interface cards (NICs) installed in a plurality of host computers, wherein a plurality of clock domain identifiers identify the plurality of clock domains …” [Hubbe ¶ 5].
executing one or more containers in an operating system level virtualization or one or more virtual machines running on an executing hardware device; “In some implementations of the methods and devices, a plurality of VMs running on a plurality of host computers are associated with a virtual clock domain identifier that identifies a virtual clock domain, a plurality of NICs installed in the host computers synchronize a plurality of hardware clocks in the virtual clock domain, and the VMs obtain a plurality of hardware timestamp values from the plurality of hardware clocks” [Hubbe ¶ 7].
allocating one or more clocks of the pool of clocks to client containers in the one or more containers or to client virtual machines of the one or more virtual machines, “FIG. 2 is a high-level diagram illustrating a mapping between virtual clock domains (vCDs), clock domains (CDs), and hardware clocks according to some aspects” [Hubbe ¶ 13]. “The method can include maintaining a plurality of clock domains on a plurality of hardware clocks in a plurality of network interface cards (NICs) installed in a plurality of host computers … the NICs are configured to associate the clock domain identifiers with a plurality of virtual clock domain identifiers that identify a plurality of virtual clock domains, and a plurality of virtual machines (VMs) running on the host computers obtain hardware timestamp values from the NICs via the virtual clock domain identifiers” [Hubbe ¶ 5]. “In some implementations of the methods and devices, the VM and the clock domain identifier are associated with a virtual clock domain identifier, the virtual clock domain identifier identifies a virtual clock domain of the VM” [Hubbe ¶ 7].
thereby obtaining allocated clocks allocated to the client containers or the client virtual machines; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein each of the allocated clocks provides a time signal in a time domain to at least one of the client containers or to at least one of the client virtual machines; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein the time signal in a time domain is based on a respective allocated hardware clock or software clock “The vCD access point can be configured with a vCD identifier 704 that identifies the vCD associated with the VM. In this manner, the VM can use the vCD to read a HW clock. For example, the VM may be one of a group of VMs implementing a tenant's workload that is synchronized via the vCD” [Hubbe ¶ 67].
…and handling the time system calls based on an allocated clock; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein the one or more containers or the one or more virtual machines are executed on the hardware device. “…using the hardware clock to provide a hardware timestamp value to a virtual machine (VM) running on the host computer or to a process running on the host computer…” [Hubbe ¶ 4].
Hubbe fails to explicitly teach and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls.
However, Ridoux teaches:
and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; “Additionally or alternatively, the isolated timing hardware 20 may provide access to the hardware clock 24 via a virtualized hardware clock 34 of the instance 116. Similarly to a virtualized network device 32, the virtualized hardware clock 34 can represent software executing on the host computing device 115 that appears, from the point of view of the instance 116, to represent hardware. For example, the virtualized hardware clock 34 may be represented in a Unix-like operating system of the instance 116 as a device (e.g., "/dev/phc")” [Ridoux Col. 14 Lines 11-20].
or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls “Accordingly, network communications from the instance 116 may traverse the isolated timing hardware 20 prior to transmission on the network 104. In the case of queries to the time server 22, the hardware 20 may intercept such transmission and provide a response, thus foregoing transmission on the network 104” [Ridoux Col. 14 Lines 1-6].
Ridoux is considered to be analogous to the claimed invention because it is in the same field of generating or distributing clock signals. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hubbe to incorporate the teachings of Ridoux and include and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls. Doing so would allow for applications to have local clock access. “However, unlike traditional network protocols, the interactions occur locally rather than over a network. In combination with a highly accurate hardware clock 24, these interactions thus facilitate highly accurate synchronization of the system clock 14” [Ridoux Col. 19-20 Lines 65-67, 1-4].
Regarding Claim 11, Hubbe teaches:
A computer program product comprising instructions which, when executed by a computer, “Aspects described above can be ultimately implemented in a network appliance that includes physical circuits that implement digital data processing, storage, and communications. The network appliance can include processing circuits, ROM, RAM, CAM, and at least one interface (interface(s))” [Hubbe ¶ 82].
cause the computer to carry out a method for automatically providing a time signal to containers in an operating system level virtualization or to virtual machines, “…using the hardware clock to provide a hardware timestamp value to a virtual machine (VM) running on the host computer or to a process running on the host computer…” [Hubbe ¶ 4]. “A HW clock has a current time value and advances at a rate. The rate can be proportional to a timing signal such as pulses in a clock signal” [Hubbe ¶ 44].
the method comprising: creating a pool of clocks; “The peripheral component card be configured to implement a plurality of hardware clocks, be installed in a host computer, use a network communications protocol to synchronize the hardware clocks within a plurality of clock domains identified by a plurality of clock domain identifiers, associate the clock domain identifiers with a plurality of virtual clock domain identifiers that identify a plurality of virtual clock domains, and provide a hardware timestamp value to a virtual machine running on the host computer based on the one of the virtual clock domains associated with the virtual machine” [Hubbe ¶ 6]. “The method can include maintaining a plurality of clock domains on a plurality of hardware clocks in a plurality of network interface cards (NICs) installed in a plurality of host computers, wherein a plurality of clock domain identifiers identify the plurality of clock domains …” [Hubbe ¶ 5].
executing one or more containers in an operating system level virtualization or one or more virtual machines running on an executing hardware device; “In some implementations of the methods and devices, a plurality of VMs running on a plurality of host computers are associated with a virtual clock domain identifier that identifies a virtual clock domain, a plurality of NICs installed in the host computers synchronize a plurality of hardware clocks in the virtual clock domain, and the VMs obtain a plurality of hardware timestamp values from the plurality of hardware clocks” [Hubbe ¶ 7].
allocating one or more clocks of the pool of clocks to client containers in the one or more containers or to client virtual machines of the one or more virtual machines, “FIG. 2 is a high-level diagram illustrating a mapping between virtual clock domains (vCDs), clock domains (CDs), and hardware clocks according to some aspects” [Hubbe ¶ 13]. “The method can include maintaining a plurality of clock domains on a plurality of hardware clocks in a plurality of network interface cards (NICs) installed in a plurality of host computers … the NICs are configured to associate the clock domain identifiers with a plurality of virtual clock domain identifiers that identify a plurality of virtual clock domains, and a plurality of virtual machines (VMs) running on the host computers obtain hardware timestamp values from the NICs via the virtual clock domain identifiers” [Hubbe ¶ 5]. “In some implementations of the methods and devices, the VM and the clock domain identifier are associated with a virtual clock domain identifier, the virtual clock domain identifier identifies a virtual clock domain of the VM” [Hubbe ¶ 7].
thereby obtaining allocated clocks allocated to the client containers or the client virtual machines; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein each of the allocated clocks provides a time signal in a time domain to at least one of the client containers or to at least one of the client virtual machines; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein the time signal in a time domain is based on a respective allocated hardware clock or software clock “The vCD access point can be configured with a vCD identifier 704 that identifies the vCD associated with the VM. In this manner, the VM can use the vCD to read a HW clock. For example, the VM may be one of a group of VMs implementing a tenant's workload that is synchronized via the vCD” [Hubbe ¶ 67].
…and handling the time system calls based on an allocated clock. “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
Hubbe fails to explicitly teach and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls.
However, Ridoux teaches:
and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; “Additionally or alternatively, the isolated timing hardware 20 may provide access to the hardware clock 24 via a virtualized hardware clock 34 of the instance 116. Similarly to a virtualized network device 32, the virtualized hardware clock 34 can represent software executing on the host computing device 115 that appears, from the point of view of the instance 116, to represent hardware. For example, the virtualized hardware clock 34 may be represented in a Unix-like operating system of the instance 116 as a device (e.g., "/dev/phc")” [Ridoux Col. 14 Lines 11-20].
or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls “Accordingly, network communications from the instance 116 may traverse the isolated timing hardware 20 prior to transmission on the network 104. In the case of queries to the time server 22, the hardware 20 may intercept such transmission and provide a response, thus foregoing transmission on the network 104” [Ridoux Col. 14 Lines 1-6].
Ridoux is considered to be analogous to the claimed invention because it is in the same field of generating or distributing clock signals. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hubbe to incorporate the teachings of Ridoux and include and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls. Doing so would allow for applications to have local clock access. “However, unlike traditional network protocols, the interactions occur locally rather than over a network. In combination with a highly accurate hardware clock 24, these interactions thus facilitate highly accurate synchronization of the system clock 14” [Ridoux Col. 19-20 Lines 65-67, 1-4].
Regarding Claim 12, Hubbe teaches:
A computer-readable medium comprising instructions which, when executed by a computer, “It should also be noted that at least some of the operations for the methods described herein may be implemented using software instructions stored on a computer usable storage medium for execution by a computer” [Hubbe ¶ 85].
cause the computer to carry out a method for automatically providing a time signal to containers in an operating system level virtualization or to virtual machines, “…using the hardware clock to provide a hardware timestamp value to a virtual machine (VM) running on the host computer or to a process running on the host computer…” [Hubbe ¶ 4]. “A HW clock has a current time value and advances at a rate. The rate can be proportional to a timing signal such as pulses in a clock signal” [Hubbe ¶ 44].
the method comprising: creating a pool of clocks; “The peripheral component card be configured to implement a plurality of hardware clocks, be installed in a host computer, use a network communications protocol to synchronize the hardware clocks within a plurality of clock domains identified by a plurality of clock domain identifiers, associate the clock domain identifiers with a plurality of virtual clock domain identifiers that identify a plurality of virtual clock domains, and provide a hardware timestamp value to a virtual machine running on the host computer based on the one of the virtual clock domains associated with the virtual machine” [Hubbe ¶ 6]. “The method can include maintaining a plurality of clock domains on a plurality of hardware clocks in a plurality of network interface cards (NICs) installed in a plurality of host computers, wherein a plurality of clock domain identifiers identify the plurality of clock domains …” [Hubbe ¶ 5].
executing one or more containers in an operating system level virtualization or one or more virtual machines running on an executing hardware device; “In some implementations of the methods and devices, a plurality of VMs running on a plurality of host computers are associated with a virtual clock domain identifier that identifies a virtual clock domain, a plurality of NICs installed in the host computers synchronize a plurality of hardware clocks in the virtual clock domain, and the VMs obtain a plurality of hardware timestamp values from the plurality of hardware clocks” [Hubbe ¶ 7].
allocating one or more clocks of the pool of clocks to client containers in the one or more containers or to client virtual machines of the one or more virtual machines, “FIG. 2 is a high-level diagram illustrating a mapping between virtual clock domains (vCDs), clock domains (CDs), and hardware clocks according to some aspects” [Hubbe ¶ 13]. “The method can include maintaining a plurality of clock domains on a plurality of hardware clocks in a plurality of network interface cards (NICs) installed in a plurality of host computers … the NICs are configured to associate the clock domain identifiers with a plurality of virtual clock domain identifiers that identify a plurality of virtual clock domains, and a plurality of virtual machines (VMs) running on the host computers obtain hardware timestamp values from the NICs via the virtual clock domain identifiers” [Hubbe ¶ 5]. “In some implementations of the methods and devices, the VM and the clock domain identifier are associated with a virtual clock domain identifier, the virtual clock domain identifier identifies a virtual clock domain of the VM” [Hubbe ¶ 7].
thereby obtaining allocated clocks allocated to the client containers or the client virtual machines; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein each of the allocated clocks provides a time signal in a time domain to at least one of the client containers or to at least one of the client virtual machines; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein the time signal in a time domain is based on a respective allocated hardware clock or software clock “The vCD access point can be configured with a vCD identifier 704 that identifies the vCD associated with the VM. In this manner, the VM can use the vCD to read a HW clock. For example, the VM may be one of a group of VMs implementing a tenant's workload that is synchronized via the vCD” [Hubbe ¶ 67].
…and handling the time system calls based on an allocated clock. “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
Hubbe fails to explicitly teach and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls.
However, Ridoux teaches:
and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; “Additionally or alternatively, the isolated timing hardware 20 may provide access to the hardware clock 24 via a virtualized hardware clock 34 of the instance 116. Similarly to a virtualized network device 32, the virtualized hardware clock 34 can represent software executing on the host computing device 115 that appears, from the point of view of the instance 116, to represent hardware. For example, the virtualized hardware clock 34 may be represented in a Unix-like operating system of the instance 116 as a device (e.g., "/dev/phc")” [Ridoux Col. 14 Lines 11-20].
or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls “Accordingly, network communications from the instance 116 may traverse the isolated timing hardware 20 prior to transmission on the network 104. In the case of queries to the time server 22, the hardware 20 may intercept such transmission and provide a response, thus foregoing transmission on the network 104” [Ridoux Col. 14 Lines 1-6].
Ridoux is considered to be analogous to the claimed invention because it is in the same field of generating or distributing clock signals. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hubbe to incorporate the teachings of Ridoux and include and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls. Doing so would allow for applications to have local clock access. “However, unlike traditional network protocols, the interactions occur locally rather than over a network. In combination with a highly accurate hardware clock 24, these interactions thus facilitate highly accurate synchronization of the system clock 14” [Ridoux Col. 19-20 Lines 65-67, 1-4].
Regarding Claim 15, Hubbe in view of Ridoux teaches the method of claim 2, as referenced above. Hubbe further teaches:
wherein a clock type includes a hardware type or a software type, “FIG. 7 is a high-level diagram illustrating a virtual machine 701 accessing a hardware clock 708 via a virtual clock domain (vCD) access point 703 according to some aspects. A process running in a VM 701 can attempt to read a time value from a HW (type) clock. The process can use the VM's device driver 702 to access a VF that functions as a vCD access point. From the VM's perspective, the device driver may be providing access to a system's only hardware clock. From the perspective of the PCIe device (e.g., smartNIC 430) the VM can be accessing a vCD access point 703 that is implemented as a PCIe VF. The vCD access point can be configured with a vCD identifier 704 that identifies the vCD associated with the VM. In this manner, the VM can use the vCD to read a HW clock” [Hubbe ¶ 67].
wherein a software type identifies a clock obtained based on a map applied to a master clock. “The VM, attempting to read the system clock, tries to read a time value via a VF implementing a vCD access point. The PCIe device can use the vCD to CD to HW clock mapping table 705 and the vCD identifier 704 to identify a HW clock” [Hubbe ¶ 67]. “From the VM's perspective, the device driver may be providing access to a system's only hardware clock. From the perspective of the PCIe device (e.g., smartNIC 430) the VM can be accessing a vCD access point 703 that is implemented as a PCIe VF” [Hubbe ¶ 67].
Regarding Claim 18, Hubbe in view of Ridoux teaches the method of claim 2, as referenced above. Hubbe further teaches:
wherein each time signal in a time domain is synchronized to a respective clock “For example, the VM may be one of a group of VMs implementing a tenant's workload that is synchronized via the vCD. The VM, attempting to read the system clock, tries to read a time value via a VF implementing a vCD access point. The PCIe device can use the vCD to CD to HW clock mapping table 705 and the vCD identifier 704 to identify a HW clock. The current time 709 of the hardware clock 708 can be provided to the VM's device driver 702” [Hubbe ¶ 67].
and is accessible for reading or writing “A process running in a VM 701 can attempt to read a time value from a HW clock. The process can use the VM's device driver 702 to access a VF that functions as a vCD access point” [Hubbe ¶ 67].
independent of different time signals in different time domains “Hardware clock synchronization executable code 104 is computer code that can be executed to thereby synchronize one or more of the hardware clocks 105 to one or more reference clocks. For example, and as is well known in the art, the reference clock can be the reference clock for a specific CD, PTP packets can be used for synchronization within that CD, and PTP stacks can process the PTP packets to thereby synchronize one or more of the HW clocks 105 to the reference clock 101” [Hubbe ¶ 41].
or wherein each time signal is synchronizable with further time signals in time domains provided by the allocated clocks. “A virtual clock domain (vCD) to clock domain (CD) to hardware (HW) clock mapping table 109 can indicate which HW clock is in which CD such that the hardware clock synchronization executable code 104 can synchronize the HW clocks within the correct CDs” [Hubbe ¶ 40].
Regarding Claim 21, Hubbe in view of Ridoux teaches the method of claim 5, as referenced above. Hubbe further teaches:
wherein each time signal in a time domain is synchronized to a respective clock “For example, the VM may be one of a group of VMs implementing a tenant's workload that is synchronized via the vCD. The VM, attempting to read the system clock, tries to read a time value via a VF implementing a vCD access point. The PCIe device can use the vCD to CD to HW clock mapping table 705 and the vCD identifier 704 to identify a HW clock. The current time 709 of the hardware clock 708 can be provided to the VM's device driver 702” [Hubbe ¶ 67].
and is accessible for reading or writing “A process running in a VM 701 can attempt to read a time value from a HW clock. The process can use the VM's device driver 702 to access a VF that functions as a vCD access point” [Hubbe ¶ 67].
independent of different time signals in different time domains “Hardware clock synchronization executable code 104 is computer code that can be executed to thereby synchronize one or more of the hardware clocks 105 to one or more reference clocks. For example, and as is well known in the art, the reference clock can be the reference clock for a specific CD, PTP packets can be used for synchronization within that CD, and PTP stacks can process the PTP packets to thereby synchronize one or more of the HW clocks 105 to the reference clock 101” [Hubbe ¶ 41].
or wherein each time signal is synchronizable with further time signals in time domains provided by the allocated clocks. “A virtual clock domain (vCD) to clock domain (CD) to hardware (HW) clock mapping table 109 can indicate which HW clock is in which CD such that the hardware clock synchronization executable code 104 can synchronize the HW clocks within the correct CDs” [Hubbe ¶ 40].
Regarding Claim 22, Hubbe teaches:
A computer program product comprising instructions which, when executed by a computer, “It should also be noted that at least some of the operations for the methods described herein may be implemented using software instructions stored on a computer usable storage medium for execution by a computer” [Hubbe ¶ 85].
cause the computer to carry out a method for automatically providing a time signal to containers in an operating system level virtualization or to virtual machines, “…using the hardware clock to provide a hardware timestamp value to a virtual machine (VM) running on the host computer or to a process running on the host computer…” [Hubbe ¶ 4]. “A HW clock has a current time value and advances at a rate. The rate can be proportional to a timing signal such as pulses in a clock signal” [Hubbe ¶ 44].
the method comprising: creating a pool of clocks; “The peripheral component card be configured to implement a plurality of hardware clocks, be installed in a host computer, use a network communications protocol to synchronize the hardware clocks within a plurality of clock domains identified by a plurality of clock domain identifiers, associate the clock domain identifiers with a plurality of virtual clock domain identifiers that identify a plurality of virtual clock domains, and provide a hardware timestamp value to a virtual machine running on the host computer based on the one of the virtual clock domains associated with the virtual machine” [Hubbe ¶ 6]. “The method can include maintaining a plurality of clock domains on a plurality of hardware clocks in a plurality of network interface cards (NICs) installed in a plurality of host computers, wherein a plurality of clock domain identifiers identify the plurality of clock domains …” [Hubbe ¶ 5].
executing one or more containers in an operating system level virtualization or one or more virtual machines running on an executing hardware device; “In some implementations of the methods and devices, a plurality of VMs running on a plurality of host computers are associated with a virtual clock domain identifier that identifies a virtual clock domain, a plurality of NICs installed in the host computers synchronize a plurality of hardware clocks in the virtual clock domain, and the VMs obtain a plurality of hardware timestamp values from the plurality of hardware clocks” [Hubbe ¶ 7].
allocating one or more clocks of the pool of clocks to client containers in the one or more containers or to client virtual machines of the one or more virtual machines, “FIG. 2 is a high-level diagram illustrating a mapping between virtual clock domains (vCDs), clock domains (CDs), and hardware clocks according to some aspects” [Hubbe ¶ 13]. “The method can include maintaining a plurality of clock domains on a plurality of hardware clocks in a plurality of network interface cards (NICs) installed in a plurality of host computers … the NICs are configured to associate the clock domain identifiers with a plurality of virtual clock domain identifiers that identify a plurality of virtual clock domains, and a plurality of virtual machines (VMs) running on the host computers obtain hardware timestamp values from the NICs via the virtual clock domain identifiers” [Hubbe ¶ 5]. “In some implementations of the methods and devices, the VM and the clock domain identifier are associated with a virtual clock domain identifier, the virtual clock domain identifier identifies a virtual clock domain of the VM” [Hubbe ¶ 7].
thereby obtaining allocated clocks allocated to the client containers or the client virtual machines; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein each of the allocated clocks provides a time signal in a time domain to at least one of the client containers or to at least one of the client virtual machines; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein the time signal in a time domain is based on a respective allocated hardware clock or software clock “The vCD access point can be configured with a vCD identifier 704 that identifies the vCD associated with the VM. In this manner, the VM can use the vCD to read a HW clock. For example, the VM may be one of a group of VMs implementing a tenant's workload that is synchronized via the vCD” [Hubbe ¶ 67].
…and handling the time system calls based on an allocated clock; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein a clock of the pool of clocks is allocated to at least two client containers or to at least two client virtual machines or to at least one client container and at least one client virtual machine. “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
Hubbe fails to explicitly teach and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls.
However, Ridoux teaches:
and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; “Additionally or alternatively, the isolated timing hardware 20 may provide access to the hardware clock 24 via a virtualized hardware clock 34 of the instance 116. Similarly to a virtualized network device 32, the virtualized hardware clock 34 can represent software executing on the host computing device 115 that appears, from the point of view of the instance 116, to represent hardware. For example, the virtualized hardware clock 34 may be represented in a Unix-like operating system of the instance 116 as a device (e.g., "/dev/phc")” [Ridoux Col. 14 Lines 11-20].
or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls “Accordingly, network communications from the instance 116 may traverse the isolated timing hardware 20 prior to transmission on the network 104. In the case of queries to the time server 22, the hardware 20 may intercept such transmission and provide a response, thus foregoing transmission on the network 104” [Ridoux Col. 14 Lines 1-6].
Ridoux is considered to be analogous to the claimed invention because it is in the same field of generating or distributing clock signals. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hubbe to incorporate the teachings of Ridoux and include and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls. Doing so would allow for applications to have local clock access. “However, unlike traditional network protocols, the interactions occur locally rather than over a network. In combination with a highly accurate hardware clock 24, these interactions thus facilitate highly accurate synchronization of the system clock 14” [Ridoux Col. 19-20 Lines 65-67, 1-4].
Claims 3, 4, 13, 14, 16, 17, 19, 20 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Hubbe (US 2023/0006807 A1) in view of Ridoux (US 11,853,114 B1) in view of Hu (US 2018/0227067 A1).
Regarding Claim 3, Hubbe in view of Ridoux teaches the method of claim 1, as referenced above. Hubbe in view of Ridoux fails to teach wherein the allocation is based on a request to join a time domain requested by a client container or by a client virtual machine or by an application running thereon.
However, Hu teaches wherein the allocation is based on a request to join a time domain requested by a client container or by a client virtual machine or by an application running thereon. “Another reason for dynamically changing a time domain may be as a result of a set of highly integrated applications (e.g., applications in a single application time domain) requesting a reconfiguration of their application time domain. In some cases, two different application time domains may desire to be synchronized and become a single application time domain. Using the disclosed sync router hardware based solution, a flexible method to allow switching to different time masters selected from multiple possible time masters may be provided (See FIG. 9)” [Hu ¶ 47].
Hu is considered to be analogous to the claimed invention because it is in the same field of generating or distributing clock signals. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hubbe in view of Ridoux to incorporate the teachings of Hu and include wherein the allocation is based on a request to join a time domain requested by a client container or by a client virtual machine or by an application running thereon. Doing so would allow for further flexibility in the allocation of time domains to applications. “Applications working together may desire to utilize a consistent time domain that is controlled by the same master clock. The sync router provides the capability for each consumer of a time event to determine its appropriate master and provide for graceful failover in the event of system or communication failure” [Hu ¶ 51].
Regarding Claim 4, Hubbe in view of Ridoux in view of Hu teaches the method of claim 3, as referenced above. Hubbe further teaches:
wherein the request comprises a request for a time signal in a time domain provided by a clock with a specified clock type; “FIG. 7 is a high-level diagram illustrating a virtual machine 701 accessing a hardware clock 708 via a virtual clock domain (vCD) access point 703 according to some aspects. A process running in a VM 701 can attempt to read a time value from a HW (type) clock. The process can use the VM's device driver 702 to access a VF that functions as a vCD access point. From the VM's perspective, the device driver may be providing access to a system's only hardware clock. From the perspective of the PCIe device (e.g., smartNIC 430) the VM can be accessing a vCD access point 703 that is implemented as a PCIe VF. The vCD access point can be configured with a vCD identifier 704 that identifies the vCD associated with the VM. In this manner, the VM can use the vCD to read a HW clock” [Hubbe ¶ 67].
and wherein the request further includes a read or write permission of the time signal in a time domain; “VMs and, in some cases, host computers may have read only access 706 to the HW clocks via the vCD access points. Read only access prevents conditions such as a VM running a PTP stack and modifying a HW clock while the PCIe device also runs a PTP stack that maintains the same HW clock” [Hubbe ¶ 68].
Hubbe in view of Ridoux fails to explicitly teach or wherein the request includes a joining request to join a time signal in a time domain provided by an already allocated clock.
However, Hu teaches or wherein the request includes a joining request to join a time signal in a time domain provided by an already allocated clock. “In some cases, two different application time domains may desire to be synchronized and become a single application time domain. Using the disclosed sync router hardware based solution, a flexible method to allow switching to different time masters selected from multiple possible time masters may be provided (See FIG. 9)” [Hu ¶ 47]. “Applications working together may desire to utilize a consistent time domain that is controlled by the same master clock. The sync router provides the capability for each consumer of a time event to determine its appropriate master and provide for graceful failover in the event of system or communication failure” [Hu ¶ 51].
Regarding Claim 13, Hubbe in view of Ridoux teaches the method of claim 2, as referenced above. Hubbe in view of Ridoux fails to teach wherein the allocation is based on a request to join a time domain requested by a client container or by a client virtual machine or by an application running thereon.
However, Hu teaches wherein the allocation is based on a request to join a time domain requested by a client container or by a client virtual machine or by an application running thereon. “Another reason for dynamically changing a time domain may be as a result of a set of highly integrated applications (e.g., applications in a single application time domain) requesting a reconfiguration of their application time domain. In some cases, two different application time domains may desire to be synchronized and become a single application time domain. Using the disclosed sync router hardware based solution, a flexible method to allow switching to different time masters selected from multiple possible time masters may be provided (See FIG. 9)” [Hu ¶ 47].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hubbe in view of Ridoux to incorporate the teachings of Hu and include wherein the allocation is based on a request to join a time domain requested by a client container or by a client virtual machine or by an application running thereon. Doing so would allow for further flexibility in the allocation of time domains to applications. “Applications working together may desire to utilize a consistent time domain that is controlled by the same master clock. The sync router provides the capability for each consumer of a time event to determine its appropriate master and provide for graceful failover in the event of system or communication failure” [Hu ¶ 51].
Regarding Claim 14, Hubbe in view of Ridoux in view of Hu teaches the method of claim 13, as referenced above. Hubbe further teaches:
wherein the request comprises a request for a time signal in a time domain provided by a clock with a specified clock type; “FIG. 7 is a high-level diagram illustrating a virtual machine 701 accessing a hardware clock 708 via a virtual clock domain (vCD) access point 703 according to some aspects. A process running in a VM 701 can attempt to read a time value from a HW (type) clock. The process can use the VM's device driver 702 to access a VF that functions as a vCD access point. From the VM's perspective, the device driver may be providing access to a system's only hardware clock. From the perspective of the PCIe device (e.g., smartNIC 430) the VM can be accessing a vCD access point 703 that is implemented as a PCIe VF. The vCD access point can be configured with a vCD identifier 704 that identifies the vCD associated with the VM. In this manner, the VM can use the vCD to read a HW clock” [Hubbe ¶ 67].
and wherein the request further includes a read or write permission of the time signal in a time domain; “VMs and, in some cases, host computers may have read only access 706 to the HW clocks via the vCD access points. Read only access prevents conditions such as a VM running a PTP stack and modifying a HW clock while the PCIe device also runs a PTP stack that maintains the same HW clock” [Hubbe ¶ 68].
Hubbe in view of Ridoux fails to explicitly teach or wherein the request includes a joining request to join a time signal in a time domain provided by an already allocated clock.
However, Hu teaches or wherein the request includes a joining request to join a time signal in a time domain provided by an already allocated clock. “In some cases, two different application time domains may desire to be synchronized and become a single application time domain. Using the disclosed sync router hardware based solution, a flexible method to allow switching to different time masters selected from multiple possible time masters may be provided (See FIG. 9)” [Hu ¶ 47]. “Applications working together may desire to utilize a consistent time domain that is controlled by the same master clock. The sync router provides the capability for each consumer of a time event to determine its appropriate master and provide for graceful failover in the event of system or communication failure” [Hu ¶ 51].
Regarding Claim 16, Hubbe in view of Ridoux in view of Hu teaches the method of claim 3, as referenced above. Hubbe further teaches:
wherein a clock type includes a hardware type or a software type, “FIG. 7 is a high-level diagram illustrating a virtual machine 701 accessing a hardware clock 708 via a virtual clock domain (vCD) access point 703 according to some aspects. A process running in a VM 701 can attempt to read a time value from a HW (type) clock. The process can use the VM's device driver 702 to access a VF that functions as a vCD access point. From the VM's perspective, the device driver may be providing access to a system's only hardware clock. From the perspective of the PCIe device (e.g., smartNIC 430) the VM can be accessing a vCD access point 703 that is implemented as a PCIe VF. The vCD access point can be configured with a vCD identifier 704 that identifies the vCD associated with the VM. In this manner, the VM can use the vCD to read a HW clock” [Hubbe ¶ 67].
wherein a software type identifies a clock obtained based on a map applied to a master clock. “The VM, attempting to read the system clock, tries to read a time value via a VF implementing a vCD access point. The PCIe device can use the vCD to CD to HW clock mapping table 705 and the vCD identifier 704 to identify a HW clock” [Hubbe ¶ 67]. “From the VM's perspective, the device driver may be providing access to a system's only hardware clock. From the perspective of the PCIe device (e.g., smartNIC 430) the VM can be accessing a vCD access point 703 that is implemented as a PCIe VF” [Hubbe ¶ 67].
Regarding Claim 17, Hubbe in view of Ridoux in view of Hu teaches the method of claim 4, as referenced above. Hubbe further teaches:
wherein the clock type includes a hardware type or a software type, “FIG. 7 is a high-level diagram illustrating a virtual machine 701 accessing a hardware clock 708 via a virtual clock domain (vCD) access point 703 according to some aspects. A process running in a VM 701 can attempt to read a time value from a HW (type) clock. The process can use the VM's device driver 702 to access a VF that functions as a vCD access point. From the VM's perspective, the device driver may be providing access to a system's only hardware clock. From the perspective of the PCIe device (e.g., smartNIC 430) the VM can be accessing a vCD access point 703 that is implemented as a PCIe VF. The vCD access point can be configured with a vCD identifier 704 that identifies the vCD associated with the VM. In this manner, the VM can use the vCD to read a HW clock” [Hubbe ¶ 67].
wherein a software type identifies a clock obtained based on a map applied to a master clock. “The VM, attempting to read the system clock, tries to read a time value via a VF implementing a vCD access point. The PCIe device can use the vCD to CD to HW clock mapping table 705 and the vCD identifier 704 to identify a HW clock” [Hubbe ¶ 67]. “From the VM's perspective, the device driver may be providing access to a system's only hardware clock. From the perspective of the PCIe device (e.g., smartNIC 430) the VM can be accessing a vCD access point 703 that is implemented as a PCIe VF” [Hubbe ¶ 67].
Regarding Claim 19, Hubbe in view of Ridoux in view of Hu teaches the method of claim 3, as referenced above. Hubbe further teaches:
wherein each time signal in a time domain is synchronized to a respective clock “For example, the VM may be one of a group of VMs implementing a tenant's workload that is synchronized via the vCD. The VM, attempting to read the system clock, tries to read a time value via a VF implementing a vCD access point. The PCIe device can use the vCD to CD to HW clock mapping table 705 and the vCD identifier 704 to identify a HW clock. The current time 709 of the hardware clock 708 can be provided to the VM's device driver 702” [Hubbe ¶ 67].
and is accessible for reading or writing “A process running in a VM 701 can attempt to read a time value from a HW clock. The process can use the VM's device driver 702 to access a VF that functions as a vCD access point” [Hubbe ¶ 67].
independent of different time signals in different time domains “Hardware clock synchronization executable code 104 is computer code that can be executed to thereby synchronize one or more of the hardware clocks 105 to one or more reference clocks. For example, and as is well known in the art, the reference clock can be the reference clock for a specific CD, PTP packets can be used for synchronization within that CD, and PTP stacks can process the PTP packets to thereby synchronize one or more of the HW clocks 105 to the reference clock 101” [Hubbe ¶ 41].
or wherein each time signal is synchronizable with further time signals in time domains provided by the allocated clocks. “A virtual clock domain (vCD) to clock domain (CD) to hardware (HW) clock mapping table 109 can indicate which HW clock is in which CD such that the hardware clock synchronization executable code 104 can synchronize the HW clocks within the correct CDs” [Hubbe ¶ 40].
Regarding Claim 20, Hubbe in view of Ridoux in view of Hu teaches the method of claim 4, as referenced above. Hubbe further teaches:
wherein each time signal in a time domain is synchronized to a respective clock “For example, the VM may be one of a group of VMs implementing a tenant's workload that is synchronized via the vCD. The VM, attempting to read the system clock, tries to read a time value via a VF implementing a vCD access point. The PCIe device can use the vCD to CD to HW clock mapping table 705 and the vCD identifier 704 to identify a HW clock. The current time 709 of the hardware clock 708 can be provided to the VM's device driver 702” [Hubbe ¶ 67].
and is accessible for reading or writing “A process running in a VM 701 can attempt to read a time value from a HW clock. The process can use the VM's device driver 702 to access a VF that functions as a vCD access point” [Hubbe ¶ 67].
independent of different time signals in different time domains “Hardware clock synchronization executable code 104 is computer code that can be executed to thereby synchronize one or more of the hardware clocks 105 to one or more reference clocks. For example, and as is well known in the art, the reference clock can be the reference clock for a specific CD, PTP packets can be used for synchronization within that CD, and PTP stacks can process the PTP packets to thereby synchronize one or more of the HW clocks 105 to the reference clock 101” [Hubbe ¶ 41].
or wherein each time signal is synchronizable with further time signals in time domains provided by the allocated clocks. “A virtual clock domain (vCD) to clock domain (CD) to hardware (HW) clock mapping table 109 can indicate which HW clock is in which CD such that the hardware clock synchronization executable code 104 can synchronize the HW clocks within the correct CDs” [Hubbe ¶ 40].
Regarding Claim 23, Hubbe teaches:
A computer program product comprising instructions which, when executed by a computer, “It should also be noted that at least some of the operations for the methods described herein may be implemented using software instructions stored on a computer usable storage medium for execution by a computer” [Hubbe ¶ 85].
cause the computer to carry out a method for automatically providing a time signal to containers in an operating system level virtualization or to virtual machines, “…using the hardware clock to provide a hardware timestamp value to a virtual machine (VM) running on the host computer or to a process running on the host computer…” [Hubbe ¶ 4]. “A HW clock has a current time value and advances at a rate. The rate can be proportional to a timing signal such as pulses in a clock signal” [Hubbe ¶ 44].
the method comprising: creating a pool of clocks; “The peripheral component card be configured to implement a plurality of hardware clocks, be installed in a host computer, use a network communications protocol to synchronize the hardware clocks within a plurality of clock domains identified by a plurality of clock domain identifiers, associate the clock domain identifiers with a plurality of virtual clock domain identifiers that identify a plurality of virtual clock domains, and provide a hardware timestamp value to a virtual machine running on the host computer based on the one of the virtual clock domains associated with the virtual machine” [Hubbe ¶ 6]. “The method can include maintaining a plurality of clock domains on a plurality of hardware clocks in a plurality of network interface cards (NICs) installed in a plurality of host computers, wherein a plurality of clock domain identifiers identify the plurality of clock domains …” [Hubbe ¶ 5].
executing one or more containers in an operating system level virtualization or one or more virtual machines running on an executing hardware device; “In some implementations of the methods and devices, a plurality of VMs running on a plurality of host computers are associated with a virtual clock domain identifier that identifies a virtual clock domain, a plurality of NICs installed in the host computers synchronize a plurality of hardware clocks in the virtual clock domain, and the VMs obtain a plurality of hardware timestamp values from the plurality of hardware clocks” [Hubbe ¶ 7].
allocating one or more clocks of the pool of clocks to client containers in the one or more containers or to client virtual machines of the one or more virtual machines, “FIG. 2 is a high-level diagram illustrating a mapping between virtual clock domains (vCDs), clock domains (CDs), and hardware clocks according to some aspects” [Hubbe ¶ 13]. “The method can include maintaining a plurality of clock domains on a plurality of hardware clocks in a plurality of network interface cards (NICs) installed in a plurality of host computers … the NICs are configured to associate the clock domain identifiers with a plurality of virtual clock domain identifiers that identify a plurality of virtual clock domains, and a plurality of virtual machines (VMs) running on the host computers obtain hardware timestamp values from the NICs via the virtual clock domain identifiers” [Hubbe ¶ 5]. “In some implementations of the methods and devices, the VM and the clock domain identifier are associated with a virtual clock domain identifier, the virtual clock domain identifier identifies a virtual clock domain of the VM” [Hubbe ¶ 7].
thereby obtaining allocated clocks allocated to the client containers or the client virtual machines; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein each of the allocated clocks provides a time signal in a time domain to at least one of the client containers or to at least one of the client virtual machines; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein the time signal in a time domain is based on a respective allocated hardware clock or software clock “The vCD access point can be configured with a vCD identifier 704 that identifies the vCD associated with the VM. In this manner, the VM can use the vCD to read a HW clock. For example, the VM may be one of a group of VMs implementing a tenant's workload that is synchronized via the vCD” [Hubbe ¶ 67].
…and handling the time system calls based on an allocated clock; “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
wherein a clock of the pool of clocks is allocated to at least two client containers or to at least two client virtual machines or to at least one client container and at least one client virtual machine. “A tenant's VMs can use a vCD that is dedicated to that particular tenant. The vCDs can map to CDs within a LAN such that VMs on different LANs can access the same vCD and receive time values or timestamps provided by local clocks. The local clocks within a LAN or a server can be assigned to a vCD such that they are synchronized across the data center to other local clocks assigned to the same vCD” [Hubbe ¶ 35].
Hubbe fails to explicitly teach and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls.
However, Ridoux teaches:
and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; “Additionally or alternatively, the isolated timing hardware 20 may provide access to the hardware clock 24 via a virtualized hardware clock 34 of the instance 116. Similarly to a virtualized network device 32, the virtualized hardware clock 34 can represent software executing on the host computing device 115 that appears, from the point of view of the instance 116, to represent hardware. For example, the virtualized hardware clock 34 may be represented in a Unix-like operating system of the instance 116 as a device (e.g., "/dev/phc")” [Ridoux Col. 14 Lines 11-20].
or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls “Accordingly, network communications from the instance 116 may traverse the isolated timing hardware 20 prior to transmission on the network 104. In the case of queries to the time server 22, the hardware 20 may intercept such transmission and provide a response, thus foregoing transmission on the network 104” [Ridoux Col. 14 Lines 1-6].
Ridoux is considered to be analogous to the claimed invention because it is in the same field of generating or distributing clock signals. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hubbe to incorporate the teachings of Ridoux and include and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine; or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls. Doing so would allow for applications to have local clock access. “However, unlike traditional network protocols, the interactions occur locally rather than over a network. In combination with a highly accurate hardware clock 24, these interactions thus facilitate highly accurate synchronization of the system clock 14” [Ridoux Col. 19-20 Lines 65-67, 1-4].
Hubbe in view of Ridoux fails to teach and wherein the allocation is based on a request to join a time domain requested by a client container or by a client virtual machine or by an application running thereon.
However, Hu teaches and wherein the allocation is based on a request to join a time domain requested by a client container or by a client virtual machine or by an application running thereon. “Another reason for dynamically changing a time domain may be as a result of a set of highly integrated applications (e.g., applications in a single application time domain) requesting a reconfiguration of their application time domain. In some cases, two different application time domains may desire to be synchronized and become a single application time domain. Using the disclosed sync router hardware based solution, a flexible method to allow switching to different time masters selected from multiple possible time masters may be provided (See FIG. 9)” [Hu ¶ 47].
Hu is considered to be analogous to the claimed invention because it is in the same field of generating or distributing clock signals. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hubbe in view of Ridoux to incorporate the teachings of Hu and include wherein the allocation is based on a request to join a time domain requested by a client container or by a client virtual machine or by an application running thereon. Doing so would allow for further flexibility in the allocation of time domains to applications. “Applications working together may desire to utilize a consistent time domain that is controlled by the same master clock. The sync router provides the capability for each consumer of a time event to determine its appropriate master and provide for graceful failover in the event of system or communication failure” [Hu ¶ 51].
Response to Arguments
Applicant's arguments filed 04/27/2026 have been fully considered but they are not persuasive. Applicant argues in substance:
I. Step 2A, Prong 1: The Claims Do Not Recite a Mental Process
The Examiner asserts that the limitation "allocating one or more clocks of the pool of clocks to client containers in the one or more containers or to client virtual machines of the one or more virtual machines" is a mental process because "a person can mentally allocate one or more clocks to client containers or client virtual machines." Applicant respectfully disagrees.
The claims do not recite merely "allocating" in the abstract. The claims recite allocating clocks from a pool of clocks to client containers in an operating system level virtualization or to client virtual machines. The pool of clocks comprises hardware clocks (such as clocks on the motherboard, network cards, and extension cards) and software clocks (mathematical maps applied to a system clock with offset and drift parameters), as described in the specification. The client containers and virtual machines are specific computing constructs that exist only within a computing environment. A person cannot mentally allocate a physical hardware clock on a network interface card to a software container running in an operating system level virtualization, because neither the hardware clock nor the software container exists in the human mind. This is not analogous to a person mentally assigning items to categories with pencil and paper.
The Federal Circuit has held that when a claim limitation is "necessarily rooted in computer technology in order to overcome a problem specifically arising in the realm of computer networks," the limitation is not a mental process. See DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1257 (Fed. Cir. 2014). The problem addressed by the present claims, providing independent time domains to individual containers in an operating-system-level virtualization, arises specifically in the realm of containerized computing. As the specification explains, containers on Linux according to the state of the art "can get their own time namespace for the monotonic clock but not for the system's real-time clock," and "[t]he monotonic clock cannot provide full time synchronization capability due to only unidirectional adjustments." This is a problem that does not exist outside of the computing domain and cannot be solved by mental processes.
Examiner respectfully disagrees. The recited allocating is a mental process because a person can mentally allocate one or more clocks of a pool of clocks to client containers or client virtual machines; this can be done through the mental mapping or assignment of clocks. Further, in response to applicant's argument that the claims do not recite a mental process, it is noted that the features upon which applicant relies (i.e., “The pool of clocks comprises hardware clocks (such as clocks on the motherboard, network cards, and extension cards) and software clocks (mathematical maps applied to a system clock with offset and drift parameters)”) 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).
Further, MPEP 2106.04(a)(III)(C) states: “In evaluating whether a claim that requires a computer recites a mental process, examiners should carefully consider the broadest reasonable interpretation of the claim in light of the specification. For instance, examiners should review the specification to determine if the claimed invention is described as a concept that is performed in the human mind and applicant is merely claiming that concept performed 1) on a generic computer, or 2) in a computer environment, or 3) is merely using a computer as a tool to perform the concept. In these situations, the claim is considered to recite a mental process”. While the claims recite computing components, this merely provides a computing environment in which the mental process is to take place, it does not prevent the claims from reciting a mental process. Thus, the claims recite a mental process.
Further, Applicant argues that the claims overcome a problem in the art; however, Applicant states a problem and does not demonstrate how the claims overcome such a problem. Further, MPEP 2106.04(d)(1) states: “Second, if the specification sets forth an improvement in technology, the claim must be evaluated to ensure that the claim itself reflects the disclosed improvement”. Currently, it is not clear that the claims reflect any improvement. The arguments have been considered but are not found to be persuasive.
II. Step 2A, Prong 2: The Claims Integrate Any Alleged Abstract Idea into a Practical Application
Even if the "allocating" limitation were considered a judicial exception, the claims as a whole integrate it into a practical application through specific technical mechanisms that go well beyond generic computer functions.
The Examiner characterized the three alternative time signal provision mechanisms as "insignificant extra-solution activity" consisting of "data transmission and retrieval." Applicant respectfully submits that this characterization does not accurately reflect the claim language.
The three alternative mechanisms recited in the claims are: (i) Providing the allocated clock as a device inside the container or virtual machine (e.g., a /dev/ptpX device node in Linux, as described in the specification with reference to FIG. 4). This involves OS-level virtualization mechanisms such as namespaces to share device files, with the device either emulated or directly routed to an existing hardware clock device. (ii) Using a software library providing an application programming interface for requesting time signals, where the library operates inside the container, replaces system calls in the target application with user space library calls, communicates with the host time service agent, and handles software clock operations locally while delegating hardware clock access to the host service.
(iii) Intercepting time system calls through wrapped execution of the application, where the intercepted calls are handled by the host time service by forwarding them to hardware clocks or updating software clock parameters.
None of these mechanisms constitutes "data transmission and retrieval." Each is a specific, concrete mechanism for making an allocated clock accessible to a containerized application, involving particularized interactions between the application, the operating system, and the clock hardware or software. A claim that recites specific technical mechanisms for implementing clock access inside a container environment imposes meaningful limits on the scope of the claim and constitutes a practical application of any underlying concept of clock allocation.
The Federal Circuit's decision in Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016), is instructive. In Enfish, the court held that claims directed to a specific improvement in the way computers operate, as opposed to a generic process that could be carried out by a human, are not directed to an abstract idea. Similarly, the present claims are directed to a specific improvement in how containers and virtual machines access time signals: through a managed pool of hardware and software clocks with defined mechanisms for making those clocks accessible within the containerized environment. This represents a specific improvement to the functioning of the computer system itself, not a generic computer implementation of an abstract concept.
Examiner respectfully disagrees. In response to applicant's argument that the claims integrate the judicial exception into a practical application, it is noted that the features upon which applicant relies (i.e., “This involves OS-level virtualization mechanisms such as namespaces to share device files, with the device either emulated or directly routed to an existing hardware clock device”, “where the library operates inside the container, replaces system calls in the target application with user space library calls, communicates with the host time service agent, and handles software clock operations locally while delegating hardware clock access to the host service”, and “wrapped execution of the application, where the intercepted calls are handled by the host time service by forwarding them to hardware clocks or updating software clock parameters”) 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).
Further, the limitation as recited in claim 1 of “wherein the time signal in a time domain is based on a respective allocated hardware clock or software clock and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine;” is considered technological environment/field of use, not data transmission or retrieval as detailed in the rejection above. Further, as claimed, the other limitations to which Applicant refers provide further description of providing a time signal to at least one client container or at least one client virtual machine. Claim 1 recites: “wherein each of the allocated clocks provides a time signal in a time domain to at least one of the client containers or to at least one of the client virtual machines; wherein … or wherein the time signal in a time domain is provided by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks; or wherein the time signal in a time domain is provided by intercepting time system calls and handling the time system calls based on an allocated clock”. The claimed providing of a time signal is considered data transmission. As currently claimed these limitations merely provide description to how such a time signal is provided, but fail to implement further steps outside of providing the time signal. Thus, these limitations are data retrieval which is insignificant extra solution activity. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. Thus, these limitations fail to integrate the judicial exception into a practical application.
From Applicants argument it is unclear what specific function of a computer is being improved or how such an improvement is implemented through the claimed invention. Applicant provides an assertion of an improvement, but does not provide the detail necessary to be apparent to a person of ordinary skill in the art. The arguments have been considered but are not found to be persuasive.
III. Step 2B: The Claims Recite Significantly More Than Any Alleged Abstract Idea
Even if the claims were found to be directed to a judicial exception at Step 2A, the claims recite an inventive concept at Step 2B. The specific ordered combination of creating a pool of clocks, allocating clocks from that pool to containers, and providing the time signal through one of three defined technical mechanisms (device provision, software library API, or system call interception) is not well-understood, routine, or conventional. Whether a claim element or combination of elements is well-understood, routine, or conventional is a question of fact. See Berkheimer v. HP Inc., 881 F.3d 1360, 1369 (Fed. Cir. 2018). The Examiner has not provided evidence that the specific combination of elements recited in the claims was well-understood, routine, or conventional at the time of filing.
Examiner respectfully disagrees. MPEP 2106.05(I) states: “Instead, an "inventive concept" is furnished by an element or combination of elements that is recited in the claim in addition to (beyond) the judicial exception, and is sufficient to ensure that the claim as a whole amounts to significantly more than the judicial exception itself”. As detailed in the rejection above, the allocating of clocks is a mental process which is a judicial exception. Further, the claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. The additional elements of the independent claims amount to no more than generic computing components, field of use/technological environment, and insignificant extra solution activity which do not amount to significantly more than the recited judicial exception. The arguments have been considered but are not found to be persuasive.
VI. The Combination of Hubbe and Ridoux Does Not Teach the Claimed Time Signal Provision Mechanisms Independent claim 1 recites, in relevant part, three alternative mechanisms by which a time signal in a time domain is provided to client containers or client virtual machines … The Examiner relies on Ridoux to supply the teachings for all three of these alternatives. Specifically, the Examiner cites Ridoux at Column 14, Lines 1-6 and Column 14, Lines 11-20. Applicant respectfully submits that these citations do not teach the claimed subject matter.
Regarding alternative (ii): software library providing an API. The claim recites that the time signal is provided "by using a software library providing an application programming interface for requesting time signals, the use of the software library involving a communication with the allocated clocks." This is a specific mechanism described in the specification with reference to FIG. 4: a dynamic library provided inside the container that replaces system calls in the target application with user space calls to the library, which in turn communicates with the host time service agent and the allocated clocks. The library handles software clock operations locally and delegates hardware clock access to the host service.
Ridoux does not teach or suggest this mechanism. The passage cited by the Examiner (Col. 14, Lines 1-6) describes that "network communications from the instance 116 may traverse the isolated timing hardware 20 prior to transmission on the network 104. In the case of queries to the time server 22, the hardware 20 may intercept such transmission and provide a response." This passage describes network- layer interception of communications to a time server, not a software library providing an application programming interface inside a container. Ridoux's isolated timing hardware intercepts network packets (TCP/UDP traffic to a time server) at the hardware level before they leave the host. The claimed software library, by contrast, operates entirely in user space within the container, provides an API that applications call directly, and communicates with the allocated clocks from the pool. These are fundamentally different architectures: Ridoux operates at the network layer intercepting outbound packets, while the claimed software library operates at the application layer providing a direct programmatic interface to allocated clocks.
Regarding alternative (iii): intercepting time system calls. The claim recites that the time signal is provided "by intercepting time system calls and handling the time system calls based on an allocated clock." This is another specific mechanism described in the specification with reference to FIG. 4: syscalls related to time (such as gettimeofday, clockgettime, and similar operating-system-level time calls) are intercepted by a wrapped execution of the application, and the intercepted calls are handled by the host time service by forwarding them to the appropriate hardware clock or updating software clock parameters.
Again, Ridoux does not teach this mechanism. The same Ridoux passage (Col. 14, Lines 1-6) describes interception of network communications to a time server, not interception of operating-system-level time system calls. A "time system call" in the context of operating-system-level virtualization refers to a system call made by an application to the kernel to obtain time information, for example gettimeofday() or clock gettime() in a Linux environment. These are fundamentally different from network communications to a remote time server. System calls are internal requests from a process to the kernel of the operating system; network communications are external transmissions over a network protocol. The fact that both involve "interception" does not make them equivalent. Ridoux's interception of network traffic to time servers is not the same as intercepting operating-system-level time system calls within a containerized application.
Regarding alternative (i): clock provided as a device inside a container. The Examiner cites Ridoux at Column 14, Lines 11-20 for the teaching that "the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine." Ridoux teaches that isolated timing hardware may provide access to a hardware clock via a "virtualized hardware clock 34" represented as "/dev/phc" in a Unix-like operating system. While this reference describes a device node inside an instance, it does not teach an allocated clock from a pool of clocks being provided as a device inside a container. Ridoux's virtualized hardware clock is tied to dedicated isolated timing hardware, not to a clock that has been dynamically allocated from a managed pool. The claim requires that the pool of clocks be created, that clocks from the pool be allocated to client containers, and that an allocated clock then be provided as a device inside the container. Ridoux's approach uses dedicated isolated hardware rather than a pool-based allocation model.
Examiner respectfully disagrees. Claim 1 recites three alternative limitations which Applicant denotes as (i), (ii), and (iii). Because the claim recites these as three alternatives, the broadest reasonable interpretation of the claim only requires that one of (i), (ii), or (iii) are taught by the prior art. Further, Examiner relies on Hubbe in view of Ridoux to teach these alternative limitations. Regarding alternative (ii), in the rejection above, Examiner has not provided a prior art teaching but instead has provided teachings for alternatives (i) and (iii).
Regarding Applicants arguments to alternative (i), in response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The pool of clocks and allocating of one or more clocks from the pool which Applicant argues are not taught by Ridoux are taught by Hubbe, as detailed in the rejection above. Further, the claim states “and wherein the allocated hardware or software clock is provided as a device inside a client container or a client virtual machine;” which is taught by Ridoux [Col. 14 Lines 11-20].
Regarding Applicants arguments to alternative (iii), 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., “interception of operating-system-level time system calls. A "time system call" in the context of operating-system-level virtualization refers to a system call made by an application to the kernel to obtain time information, for example gettimeofday() or clock gettime() in a Linux environment” and “intercepting operating-system-level time system calls within a containerized application”) 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). The limitation states: “or wherein the time signal in a time domain is provided by intercepting time system calls” which is taught by Ridoux [Col. 14 Lines 1-6]. The arguments have been considered but are not found to be persuasive.
V. The Examiner Has Not Established a Proper Motivation to Combine Hubbe and Ridoux
Even assuming, arguendo, that the combination of Hubbe and Ridoux could be read to teach all claim elements, the combination itself is improper because Hubbe and Ridoux address different technical problems through incompatible architectures, and the Examiner has not adequately explained how or why a person of ordinary skill would combine them.
Hubbe teaches a system for distributing synchronized time values from hardware clocks on SmartNIC devices (PCle network interface cards) to virtual machines through virtual clock domain (vCD) access points. In Hubbe's architecture, VMs access hardware clocks through device drivers that communicate with PCle virtual functions (VFs) on the SmartNIC. The clock distribution operates at the device driver/PCle layer, with a mapping table (vCD to CD to HW clock) that determines which hardware clock a VM accesses.
Ridoux teaches a fundamentally different architecture: isolated timing hardware that is physically separate from the standard computing hardware of the host, providing access to a dedicated high-precision hardware clock. Ridoux's approach involves intercepting network communications from compute instances before they leave the host, so that timing queries to remote time servers can be answered locally by the isolated timing hardware.
These architectures are incompatible. Hubbe's SmartNIC-based clock distribution provides VMs with direct access to hardware clock values through PCle virtual functions. Ridoux's isolated timing hardware provides instances with time by intercepting their network traffic to time servers. A person of ordinary skill in the art seeking to provide time signals to containers would not look to both of these references simultaneously, because they solve the problem through entirely different means at different layers of the computing stack. The Examiner's stated motivation, that combining Ridoux with Hubbe "would allow for applications to have local clock access," does not explain why a person of ordinary skill already working with Hubbe's SmartNIC- based approach (which already provides local clock access through PCle VFs) would seek out Ridoux's network-interception-based approach to supplement it. Hubbe's architecture already provides local clock access to VMs without any need for network interception.
The combination reflects impermissible hindsight reasoning. As the Supreme Court cautioned in Graham v. John Deere Co., 383 U.S. 1 (1966), "any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning, but so long as it takes into account only the teachings of the prior art, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper." Here, the only reason to extract specific teachings from Ridoux (network interception) and map them onto the claimed system call interception and software library mechanisms is because the Examiner has used Applicant's claims as a roadmap. Without the claims as a guide, a person of ordinary skill starting from Hubbe's SmartNIC architecture would have no reason to consult Ridoux's isolated timing hardware approach, let alone extract and transpose its network interception mechanism into a system call interception mechanism.
Examiner respectfully disagrees. It is unclear which elements of the architecture of Hubbe and Ridoux Applicant alleges are incompatible. As Applicant describes, both Hubbe and Ridoux teach providing virtual machines with clock access. Further, Applicant states “In Hubbe's architecture, VMs access hardware clocks through device drivers that communicate with PCle virtual functions (VFs) on the SmartNIC” and Ridoux teaches “In one embodiment, the card is connected to the resources used by instances 116 via a Peripheral Component Interconnect Express (PCIe) bus of the host computing device 115. Thus, the instances 116, executing on their distinct computing resources, may communicate with the card (or other isolated timing hardware) via local interfaces of the device 115, without traversing a network” [Col. 12 Lines 51-57].
Further, in this case, because the independent claims provide three alternative limitations which Applicant denotes as (i), (ii), and (iii), the motivation to combine Hubbe in view of Ridoux detailed in the rejection above is given in view of alternative (i). As detailed in the rejection above, the motivation to combine comes from the teachings of Ridoux: “However, unlike traditional network protocols, the interactions occur locally rather than over a network. In combination with a highly accurate hardware clock 24, these interactions thus facilitate highly accurate synchronization of the system clock 14” [Ridoux Col. 19-20 Lines 65-67, 1-4]. Further, as detailed in the rejection above, Hubbe does not have an explicit teaching of providing the allocated hardware or software clock as a device inside a client container or a client virtual machine and, thus, Examiner looks to the teachings of Ridoux. However, if Applicant’s argument is that Hubbe already teaches this limitation, then that would be a counterproductive argument because it means that the claim limitation is taught by the cited prior art.
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was ma ide, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
Conclusion
THIS ACTION IS MADE FINAL. 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.
Examiner respectfully requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARI F RIGGINS whose telephone number is (571)272-2772. The examiner can normally be reached Monday-Friday 7:00AM-4:30PM.
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.
/A.F.R./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights