DETAILED ACTION
This action is response to application number 18/813,895, dated on 08/23/2024.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1-5, 9-12 and 14-20 are rejected under 35 U.S.C. 102(a)(2) as anticipated by or, in the alternative, under 35 U.S.C. 103 as obvious over Zou et al. (US 2023/0309037 A1).
Claim 1, Zou discloses a wireless communication method (wireless networks are utilized to deliver highly accurate timing information; ¶1), comprising:
receiving, by a centralized unit control plane of a base station (gNB-CU-CP) (source/target gNB-CU; Fig. 11), information of one or more time source candidates from a first network node (source/target gNB-DU; Fig. 11) (the CU receiving the DU reporting 5GSC time; NG-RAN nodes, such as gNBs, can include a central (or centralized) unit (CU or gNB—CU) and one or more distributed (or decentralized) units (DU or gNB-DU). CUs are logical nodes that host higher-layer protocols and perform various gNB functions such controlling the operation of DUs. Each DU is a logical node that hosts lower-layer protocols and can include, depending on the functional split, various subsets of the gNB functions. In the context of providing reference time to UEs, the SIB and RRC unicast messages are generated by a CU and, preferably, the reference event is referenced on the radio interface provided by the DU. Thus, a DU can overwrite SIB9 for broadcast delivery. For unicast delivery, a DU reports 5GSC time at reference event (e.g., SFN) to CU, which generates the unicast RRC message that includes the reported timing relationship; ¶103; Upon receiving any of the above-mentioned information from the source gNB, the target gNB prepares for providing the next reference time refresh (or update) to the UE. In case of the split CU-DU architecture, this can include the gNB—CU requesting time reference reporting from a gNB-DU serving the target cell, or adjusting an existing time reference reporting period in the target cell to accommodate the UE. If the periodicity is sent by the source gNB, the target gNB can use this information in either of these operations. Once the refreshed reference time information has been prepared, the target gNB then sends it to the UE at the first possible RRC unicast message, e.g., in DLInformationTransfer; ¶135);
determining, by the gNB-CU-CP (source/target gNB-CU; Fig. 11), primary or suggested time source information (5G GM/GPS timing or local clock timing information) of the first network node (source/target gNB-DU; Fig. 11) according to the one or more time source candidates (determining to use primary 5G GM/GPS timing as shown in Fig. 5, or using the local clock time; Local clock. This can facilitate synchronization of the target gNB and the source gNB. If no information is indicated, then GPS time can be assumed. If a source gNB local clock is indicated, then the target gNB shall also transmit this local clock via a transparent container that includes the origin and current (or original) value of the local clock. In this manner, the relationship between local locks can be maintained; ¶131; In general, all gNBs in the NG-RAN - including the source and target gNBs for the UE handover - should be synchronized to the same 5G GM clock (e.g., in FIG. 5), which is ultimately derived from the GPS master clock. On the other hand, a target gNB synchronized to 5G GM can assume that the source gNB is also synchronized to 5G GM if the timeInfoType field of ReferenceTimeInfo IE shown in FIG. 7 is not present; ¶139); and
transmitting, by the gNB-CU-CP (source/target gNB-CU; Fig. 11), the primary or suggested time source information, indicating one or more primary or suggested time sources, to the first network node (sending/receiving messages between the CU and the DUs regarding primary or suggested time sources (synchronization source (5G GM/GPS timing or local timing)); Local clock. This can facilitate synchronization of the target gNB and the source gNB. If no information is indicated, then GPS time can be assumed. If a source gNB local clock is indicated, then the target gNB shall also transmit this local clock via a transparent container that includes the origin and current (or original) value of the local clock. In this manner, the relationship between local locks can be maintained; ¶131; FIG. 11 shows a signal flow diagram that illustrates these embodiments. In particular, FIG. 11 shows operations by, and signaling between, a source gNB and a target gNB that comprises a gNB—CU and a gNB-DU. Initially, the source gNB sends an XnAP: RRCTransfer message that includes any of the reference time related information provided by the UE (e.g., in UEAssistanceInformation) or configured/delivered by the source gNB, as discussed above. Subsequently, the target gNB—CU performs operations toward the target gNB-DU serving the target cell for the UE handover. This can include sending/receiving messages over the F1AP interface between the CU and the DU. After communicating with the target gNB-DU in this manner, the target gNB—CU can prepare with reference time information to be sent to the UE after handover is completed; ¶136).
Claim 2, Zou discloses wherein the first network node is a distributed unit (gNB-DU) of the base station or a centralized unit user plane of a base station (gNB-CU-UP) (the first network node is a distributed unit gNB-DU; NG-RAN nodes, such as gNBs, can include a central (or centralized) unit (CU or gNB—CU) and one or more distributed (or decentralized) units (DU or gNB-DU). CUs are logical nodes that host higher-layer protocols and perform various gNB functions such controlling the operation of DUs. Each DU is a logical node that hosts lower-layer protocols and can include, depending on the functional split, various subsets of the gNB functions. In the context of providing reference time to UEs, the SIB and RRC unicast messages are generated by a CU and, preferably, the reference event is referenced on the radio interface provided by the DU. Thus, a DU can overwrite SIB9 for broadcast delivery. For unicast delivery, a DU reports 5GSC time at reference event (e.g., SFN) to CU, which generates the unicast RRC message that includes the reported timing relationship; ¶103; Upon receiving any of the above-mentioned information from the source gNB, the target gNB prepares for providing the next reference time refresh (or update) to the UE. In case of the split CU-DU architecture, this can include the gNB—CU requesting time reference reporting from a gNB-DU serving the target cell, or adjusting an existing time reference reporting period in the target cell to accommodate the UE. If the periodicity is sent by the source gNB, the target gNB can use this information in either of these operations. Once the refreshed reference time information has been prepared, the target gNB then sends it to the UE at the first possible RRC unicast message, e.g., in DLInformationTransfer; ¶135; FIG. 11 shows a signal flow diagram that illustrates these embodiments. In particular, FIG. 11 shows operations by, and signaling between, a source gNB and a target gNB that comprises a gNB—CU and a gNB-DU. Initially, the source gNB sends an XnAP: RRCTransfer message that includes any of the reference time related information provided by the UE (e.g., in UEAssistanceInformation) or configured/delivered by the source gNB, as discussed above. Subsequently, the target gNB—CU performs operations toward the target gNB-DU serving the target cell for the UE handover. This can include sending/receiving messages over the F1AP interface between the CU and the DU. After communicating with the target gNB-DU in this manner, the target gNB—CU can prepare with reference time information to be sent to the UE after handover is completed; ¶136).
Claim 3, Zou discloses further comprising using the primary or suggested time source information for time synchronization (using the 5GSC/5G GM/GPS timing or local timing information for time synchronization; At a high level, the time synchronization solution defined in 3GPP TS 23.501 only requires NG-RAN nodes (e.g., gNBs) to be synchronized to the 5G network reference time (i.e., based on 5GSC) while TSN GM timing is delivered to UEs and endpoints transparently through the 5G network using higher-layer generalized precision time protocol (gPTP) signaling. For 5GSC synchronization, a UE relies on its serving gNB providing reference time periodically, either via broadcast or unicast signaling; ¶20; In general, all gNBs in the NG-RAN - including the source and target gNBs for the UE handover - should be synchronized to the same 5G GM clock (e.g., in FIG. 5), which is ultimately derived from the GPS master clock. On the other hand, a target gNB synchronized to 5G GM can assume that the source gNB is also synchronized to 5G GM if the timeInfoType field of ReferenceTimeInfo IE shown in FIG. 7 is not present; ¶139).
Claim 4, Zou discloses wherein the primary time source is designated as a preferred time source for the first network node (5G GM clock is designated as a preferred time source for the source and target gNB DUs; If the timeInfoType is not included in the IE, the time field indicates the GPS time and the origin of the time field is 00:00:00 on Gregorian calendar date 6 Jan. 1980 (i.e., start of GPS time). If timeInfoType is set to localClock, the origin of the time is unspecified; ¶105; In general, all gNBs in the NG-RAN - including the source and target gNBs for the UE handover - should be synchronized to the same 5G GM clock (e.g., in FIG. 5), which is ultimately derived from the GPS master clock. On the other hand, a target gNB synchronized to 5G GM can assume that the source gNB is also synchronized to 5G GM if the timeInfoType field of ReferenceTimeInfo IE shown in FIG. 7 is not present; ¶139).
Claim 5, Zou discloses further comprising transmitting the same primary or suggested time source information of the first network node (source/target gNB-DU; Fig. 11) to a second network node (source/target gNB-DU; Fig. 11) to synchronize time of the first network node (source/target gNB-DU; Fig. 11) and the second network node (source/target gNB-DU; Fig. 11)(CU transmitting the primary or suggested time source information to the DUs of the same NG-RAN or a target NG-RAN DUs to synchronize time of the source/target NG-RAN DUs; NG-RAN nodes, such as gNBs, can include a central (or centralized) unit (CU or gNB—CU) and one or more distributed (or decentralized) units (DU or gNB-DU). CUs are logical nodes that host higher-layer protocols and perform various gNB functions such controlling the operation of DUs. Each DU is a logical node that hosts lower-layer protocols and can include, depending on the functional split, various subsets of the gNB functions. In the context of providing reference time to UEs, the SIB and RRC unicast messages are generated by a CU and, preferably, the reference event is referenced on the radio interface provided by the DU. Thus, a DU can overwrite SIB9 for broadcast delivery. For unicast delivery, a DU reports 5GSC time at reference event (e.g., SFN) to CU, which generates the unicast RRC message that includes the reported timing relationship; ¶103; FIG. 11 shows a signal flow diagram that illustrates these embodiments. In particular, FIG. 11 shows operations by, and signaling between, a source gNB and a target gNB that comprises a gNB—CU and a gNB-DU. Initially, the source gNB sends an XnAP: RRCTransfer message that includes any of the reference time related information provided by the UE (e.g., in UEAssistanceInformation) or configured/delivered by the source gNB, as discussed above. Subsequently, the target gNB—CU performs operations toward the target gNB-DU serving the target cell for the UE handover. This can include sending/receiving messages over the F1AP interface between the CU and the DU. After communicating with the target gNB-DU in this manner, the target gNB—CU can prepare with reference time information to be sent to the UE after handover is completed; ¶136).
Claim 9, Zou discloses further comprising sending a time synchronization status reporting control message to configure transmission of a time synchronization status (sending/receiving messages between the CU and the DU regarding the time synchronization; Local clock. This can facilitate synchronization of the target gNB and the source gNB. If no information is indicated, then GPS time can be assumed. If a source gNB local clock is indicated, then the target gNB shall also transmit this local clock via a transparent container that includes the origin and current (or original) value of the local clock. In this manner, the relationship between local locks can be maintained; ¶131; FIG. 11 shows a signal flow diagram that illustrates these embodiments. In particular, FIG. 11 shows operations by, and signaling between, a source gNB and a target gNB that comprises a gNB—CU and a gNB-DU. Initially, the source gNB sends an XnAP: RRCTransfer message that includes any of the reference time related information provided by the UE (e.g., in UEAssistanceInformation) or configured/delivered by the source gNB, as discussed above. Subsequently, the target gNB—CU performs operations toward the target gNB-DU serving the target cell for the UE handover. This can include sending/receiving messages over the F1AP interface between the CU and the DU. After communicating with the target gNB-DU in this manner, the target gNB—CU can prepare with reference time information to be sent to the UE after handover is completed; ¶136).
Claim 10, Zou discloses wherein the time synchronization status is organized as a time synchronization status report (sending/receiving messages between the CU and the DU regarding the time synchronization organized as a time synchronization status report; Local clock. This can facilitate synchronization of the target gNB and the source gNB. If no information is indicated, then GPS time can be assumed. If a source gNB local clock is indicated, then the target gNB shall also transmit this local clock via a transparent container that includes the origin and current (or original) value of the local clock. In this manner, the relationship between local locks can be maintained; ¶131; FIG. 11 shows a signal flow diagram that illustrates these embodiments. In particular, FIG. 11 shows operations by, and signaling between, a source gNB and a target gNB that comprises a gNB—CU and a gNB-DU. Initially, the source gNB sends an XnAP: RRCTransfer message that includes any of the reference time related information provided by the UE (e.g., in UEAssistanceInformation) or configured/delivered by the source gNB, as discussed above. Subsequently, the target gNB—CU performs operations toward the target gNB-DU serving the target cell for the UE handover. This can include sending/receiving messages over the F1AP interface between the CU and the DU. After communicating with the target gNB-DU in this manner, the target gNB—CU can prepare with reference time information to be sent to the UE after handover is completed; ¶136).
Claim 11, Zou discloses further comprising receiving a message from the first network node, the message including information on whether a time source indicated by the primary or suggested time source information is adopted by the first network node (sending/receiving messages between the CU and the DUs to implement and successfully complete the time synchronization; Local clock. This can facilitate synchronization of the target gNB and the source gNB. If no information is indicated, then GPS time can be assumed. If a source gNB local clock is indicated, then the target gNB shall also transmit this local clock via a transparent container that includes the origin and current (or original) value of the local clock. In this manner, the relationship between local locks can be maintained; ¶131; FIG. 11 shows a signal flow diagram that illustrates these embodiments. In particular, FIG. 11 shows operations by, and signaling between, a source gNB and a target gNB that comprises a gNB—CU and a gNB-DU. Initially, the source gNB sends an XnAP: RRCTransfer message that includes any of the reference time related information provided by the UE (e.g., in UEAssistanceInformation) or configured/delivered by the source gNB, as discussed above. Subsequently, the target gNB—CU performs operations toward the target gNB-DU serving the target cell for the UE handover. This can include sending/receiving messages over the F1AP interface between the CU and the DU. After communicating with the target gNB-DU in this manner, the target gNB—CU can prepare with reference time information to be sent to the UE after handover is completed; ¶136).
Claim 12, Zou discloses further comprising: receiving new time information in a time synchronization status, indicating a new time source adopted by the first network node, from the first network node (the CU receiving the DU 5GSC time report indicating a (new) time source adopted by the DU; NG-RAN nodes, such as gNBs, can include a central (or centralized) unit (CU or gNB—CU) and one or more distributed (or decentralized) units (DU or gNB-DU). CUs are logical nodes that host higher-layer protocols and perform various gNB functions such controlling the operation of DUs. Each DU is a logical node that hosts lower-layer protocols and can include, depending on the functional split, various subsets of the gNB functions. In the context of providing reference time to UEs, the SIB and RRC unicast messages are generated by a CU and, preferably, the reference event is referenced on the radio interface provided by the DU. Thus, a DU can overwrite SIB9 for broadcast delivery. For unicast delivery, a DU reports 5GSC time at reference event (e.g., SFN) to CU, which generates the unicast RRC message that includes the reported timing relationship; ¶103; Upon receiving any of the above-mentioned information from the source gNB, the target gNB prepares for providing the next reference time refresh (or update) to the UE. In case of the split CU-DU architecture, this can include the gNB—CU requesting time reference reporting from a gNB-DU serving the target cell, or adjusting an existing time reference reporting period in the target cell to accommodate the UE. If the periodicity is sent by the source gNB, the target gNB can use this information in either of these operations. Once the refreshed reference time information has been prepared, the target gNB then sends it to the UE at the first possible RRC unicast message, e.g., in DLInformationTransfer; ¶135); and
transmitting a message with the new time information to a second network node to synchronize the time of first network node and the second network node (CU transmitting the primary or suggested time source information to the DUs of the same NG-RAN or a target NG-RAN DUs to synchronize time of the source/target NG-RAN DUs; NG-RAN nodes, such as gNBs, can include a central (or centralized) unit (CU or gNB—CU) and one or more distributed (or decentralized) units (DU or gNB-DU). CUs are logical nodes that host higher-layer protocols and perform various gNB functions such controlling the operation of DUs. Each DU is a logical node that hosts lower-layer protocols and can include, depending on the functional split, various subsets of the gNB functions. In the context of providing reference time to UEs, the SIB and RRC unicast messages are generated by a CU and, preferably, the reference event is referenced on the radio interface provided by the DU. Thus, a DU can overwrite SIB9 for broadcast delivery. For unicast delivery, a DU reports 5GSC time at reference event (e.g., SFN) to CU, which generates the unicast RRC message that includes the reported timing relationship; ¶103; FIG. 11 shows a signal flow diagram that illustrates these embodiments. In particular, FIG. 11 shows operations by, and signaling between, a source gNB and a target gNB that comprises a gNB—CU and a gNB-DU. Initially, the source gNB sends an XnAP: RRCTransfer message that includes any of the reference time related information provided by the UE (e.g., in UEAssistanceInformation) or configured/delivered by the source gNB, as discussed above. Subsequently, the target gNB—CU performs operations toward the target gNB-DU serving the target cell for the UE handover. This can include sending/receiving messages over the F1AP interface between the CU and the DU. After communicating with the target gNB-DU in this manner, the target gNB—CU can prepare with reference time information to be sent to the UE after handover is completed; ¶136).
Claim 14, Zou discloses wherein the second network node is a distributed unit (gNB-DU) of the base station or a centralized unit user plane of the base station gNB-CU-UP (the DUs of the source NG-RAN or a target NG-RAN DUs; NG-RAN nodes, such as gNBs, can include a central (or centralized) unit (CU or gNB—CU) and one or more distributed (or decentralized) units (DU or gNB-DU). CUs are logical nodes that host higher-layer protocols and perform various gNB functions such controlling the operation of DUs. Each DU is a logical node that hosts lower-layer protocols and can include, depending on the functional split, various subsets of the gNB functions. In the context of providing reference time to UEs, the SIB and RRC unicast messages are generated by a CU and, preferably, the reference event is referenced on the radio interface provided by the DU. Thus, a DU can overwrite SIB9 for broadcast delivery. For unicast delivery, a DU reports 5GSC time at reference event (e.g., SFN) to CU, which generates the unicast RRC message that includes the reported timing relationship; ¶103; FIG. 11 shows a signal flow diagram that illustrates these embodiments. In particular, FIG. 11 shows operations by, and signaling between, a source gNB and a target gNB that comprises a gNB—CU and a gNB-DU. Initially, the source gNB sends an XnAP: RRCTransfer message that includes any of the reference time related information provided by the UE (e.g., in UEAssistanceInformation) or configured/delivered by the source gNB, as discussed above. Subsequently, the target gNB—CU performs operations toward the target gNB-DU serving the target cell for the UE handover. This can include sending/receiving messages over the F1AP interface between the CU and the DU. After communicating with the target gNB-DU in this manner, the target gNB—CU can prepare with reference time information to be sent to the UE after handover is completed; ¶136).
Claim 15, Zou discloses wherein the information of one or more time source candidates is received in an interface setup request or a configuration update request and the primary or suggested time source information is transmitted in an interface set up response or configuration update acknowledgement (sending/receiving messages between the CU and the DUs to implement and successfully complete the time synchronization; Local clock. This can facilitate synchronization of the target gNB and the source gNB. If no information is indicated, then GPS time can be assumed. If a source gNB local clock is indicated, then the target gNB shall also transmit this local clock via a transparent container that includes the origin and current (or original) value of the local clock. In this manner, the relationship between local locks can be maintained; ¶131; FIG. 11 shows a signal flow diagram that illustrates these embodiments. In particular, FIG. 11 shows operations by, and signaling between, a source gNB and a target gNB that comprises a gNB—CU and a gNB-DU. Initially, the source gNB sends an XnAP: RRCTransfer message that includes any of the reference time related information provided by the UE (e.g., in UEAssistanceInformation) or configured/delivered by the source gNB, as discussed above. Subsequently, the target gNB—CU performs operations toward the target gNB-DU serving the target cell for the UE handover. This can include sending/receiving messages over the F1AP interface between the CU and the DU. After communicating with the target gNB-DU in this manner, the target gNB—CU can prepare with reference time information to be sent to the UE after handover is completed; ¶136).
Claim 16, Zou discloses wherein the primary or suggested time source information is transmitted in an interface set up response or configuration update request (sending/receiving messages between the CU and the DUs to implement and successfully complete the time synchronization; Local clock. This can facilitate synchronization of the target gNB and the source gNB. If no information is indicated, then GPS time can be assumed. If a source gNB local clock is indicated, then the target gNB shall also transmit this local clock via a transparent container that includes the origin and current (or original) value of the local clock. In this manner, the relationship between local locks can be maintained; ¶131; FIG. 11 shows a signal flow diagram that illustrates these embodiments. In particular, FIG. 11 shows operations by, and signaling between, a source gNB and a target gNB that comprises a gNB—CU and a gNB-DU. Initially, the source gNB sends an XnAP: RRCTransfer message that includes any of the reference time related information provided by the UE (e.g., in UEAssistanceInformation) or configured/delivered by the source gNB, as discussed above. Subsequently, the target gNB—CU performs operations toward the target gNB-DU serving the target cell for the UE handover. This can include sending/receiving messages over the F1AP interface between the CU and the DU. After communicating with the target gNB-DU in this manner, the target gNB—CU can prepare with reference time information to be sent to the UE after handover is completed; ¶136).
Claim 17, Zou discloses wherein the primary time sources are time sources of a highest priority (the 5G GM clock as a preferred time source and having the highest priority of the time sources for the source/target gNB DUs; If the timeInfoType is not included in the IE, the time field indicates the GPS time and the origin of the time field is 00:00:00 on Gregorian calendar date 6 Jan. 1980 (i.e., start of GPS time). If timeInfoType is set to localClock, the origin of the time is unspecified; ¶105; In general, all gNBs in the NG-RAN - including the source and target gNBs for the UE handover - should be synchronized to the same 5G GM clock (e.g., in FIG. 5), which is ultimately derived from the GPS master clock. On the other hand, a target gNB synchronized to 5G GM can assume that the source gNB is also synchronized to 5G GM if the timeInfoType field of ReferenceTimeInfo IE shown in FIG. 7 is not present; ¶139).
Claim 18, Zou discloses wherein determining the primary or suggested time source information of the first network node according to the one or more time source candidates includes selecting one or more primary or suggested time sources from the one or more time source candidates (selecting to use primary 5G GM/GPS timing as shown in Fig. 5, or using the local time; Local clock. This can facilitate synchronization of the target gNB and the source gNB. If no information is indicated, then GPS time can be assumed. If a source gNB local clock is indicated, then the target gNB shall also transmit this local clock via a transparent container that includes the origin and current (or original) value of the local clock. In this manner, the relationship between local locks can be maintained; ¶131; In general, all gNBs in the NG-RAN - including the source and target gNBs for the UE handover - should be synchronized to the same 5G GM clock (e.g., in FIG. 5), which is ultimately derived from the GPS master clock. On the other hand, a target gNB synchronized to 5G GM can assume that the source gNB is also synchronized to 5G GM if the timeInfoType field of ReferenceTimeInfo IE shown in FIG. 7 is not present; ¶139).
Claim 19, Zou discloses a wireless communication apparatus (source/target gNB-CU; Fig. 11), comprising a memory (memory, non-transitory storage; Fig. 17, els. 1790-1, 1790-2) storing one or more programs (program and instructions; Fig. 17, els. 1795, 1795 instr.) and one or more processors (Fig. 17, el. 1760) electrically coupled to the memory (Fig. 17) and configured to execute the one or more programs to perform the method of claim 1 (Each hardware device can comprise memory 1790-1 which can be non-persistent memory for temporarily storing instructions 1795 or software executed by processing circuitry 1760. For example, instructions 1795 can include program instructions (also referred to as a computer program product) that, when executed by processing circuitry 1760, can configure hardware node 1720 to perform operations corresponding to various exemplary methods (e.g., procedures) described herein. Such operations can also be attributed to virtual node(s) 1720 that is/are hosted by hardware node 1730; ¶258).
Claim 20, Zou discloses a non-transitory computer-readable storage medium (memory, non-transitory storage; Fig. 17, els. 1790-1, 1790-2), storing one or more programs (storing program and instructions; Fig. 17, els. 1795, 1795 instr.), the one or more program being configured to, when executed by a processor, cause to perform the method of claim 1 (Each hardware device can also include non-transitory, persistent, machine-readable storage media 1790-2 having stored therein software 1795 and/or instructions executable by processing circuitry 1760. Software 1795 can include any type of software including software for instantiating one or more virtualization layers 1750 (also referred to as hypervisors), software to execute virtual machines 1740 as well as software allowing it to execute functions, features and/or benefits described in relation with some embodiments described herein; ¶259).
Allowable Subject Matter
Claims 6-8 and 13 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KOUROUSH MOHEBBI whose telephone number is (571)270-7908. The examiner can normally be reached 7:30AM-5:00PM.
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, Sujoy Kundu can be reached at 571-272-8586. 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.
/KOUROUSH MOHEBBI/ Primary Examiner, Art Unit 2471
Prosecution Insights