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 .
Claims 1-28 are pending.
Claim Interpretation
As per claims 7 and 21, with respect to the “at least one of” and “one or more of” limitations, the Examiner is interpreting the broadest reasonable interpretation of the limitations as being disjunctive (analogous to “A, B, and/or C”), as opposed to conjunctive (i.e., “at least one of A” and “at least one of B”).
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 of this title, 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-4, 6-18, and 20-28 are rejected under 35 U.S.C. 103(a) as being unpatentable over Stefanik et al. (US 2019/016650)(“Stefanik”), in view of Kwon et al. (US 2023/0189077)(“Kwon”) (see also priority application KR 10-2022-0031578, with a filing date of 03/14/2022, which share similar paragraphs/figures as that of the US Application).
As per claim 1, Stefanik teaches a … distributed antenna system (DAS) (see Fig. 1, ref. 102) to serve one or more donor base stations (i.e., external devices see Fig. 1, ref. 112, also see ¶0021, “the at least one external device 112 includes a base station”, also see ¶0002, where the base station is a donor base station in the sense that it is the signal source for the DAS), the DAS system comprising:
a plurality of access points (i.e., RUs, see Fig. 1, refs. 104 and/or 120), each of the access points associated with a respective set of coverage antennas (i.e., using at least one antenna, see ¶0017) and each of the access points (i.e., RUs) communicatively coupled to the DAS (see Fig. 1); and
wherein the DAS is configured to:
to perform a plurality of roles including a first role (e.g., a plurality of master/upstream units [roles], see Fig. 1, ref. 108, also see ¶0013, “DAS systems can include active elements such as master units, extension units, and remote units” read as roles).
As per claim 1, Stefanik does not expressly teach the virtualizing the roles of the DAS, or in other words, Stefanik does not expressly teach “a virtualized distributed antenna system (vDAS) to serve one or more donor base stations, the vDAS comprising:
a plurality of physical server computers on which scalable vDAS software is executed to perform a plurality of roles for the vDAS; and
a plurality of access points (APs), each of the APs associated with a respective set of coverage antennas and each of the APs communicatively coupled to at least one of the physical server computers; and
wherein the vDAS is configured to:
determine if there has been a failure in performing a first role included in the plurality of roles performed for the vDAS, the first role performed using a first physical server computer included in the plurality of physical server computers; and
in response to the failure in performing the first role using the first physical server computer, perform the first role using a second physical server computer included in the plurality of physical server computers.
Nevertheless, in the same art of wireless networking, Kwon teaches an example of virtualizing roles (i.e., CU or DU roles) within a radio system, or in other words Kwon teaches:
a plurality of physical server computers on which scalable … software is executed to perform a plurality of roles for the system (i.e., operating CU and DU, read as roles, in a cloud environment, see ¶0005); and
a plurality of RUs (i.e., wireless transmission/reception units, or RUs, see ¶0003), each of the RUs associated with a respective set of coverage antennas (see also ¶0003, where each RU is impliedly associated with respective set of coverage antennas for serving a plurality of UEs) and each of the RUs communicatively coupled to at least one of the physical server computers (see ¶0039, i.e., “at least one DU 231 may be respectively configured to be connected to each of the at least one cell site”, also see ¶0038, “That a dedicated DU is set for one cell site 210 may be interpreted as setting the dedicated DU for one or more RUs 211 constituting one cell site 210”, which anticipates the DU 231 (in the cloud environment, i.e., “at least one of the physical server computers”) being coupled to more than one cell site and/or more than one remote unit (RU) per cell site, respectively);
wherein the system is configured to:
determine if there has been a failure in performing a first role (e.g., DU) included in the plurality of roles performed for the virtual system (i.e., “…if a scaling-out is determined”, see ¶0051, also see ¶0058, e.g., “the ratio of the currently used resource to the overall resource available to the source DU 320a (or the server for driving the source DU 320a) is a threshold ratio or more”, read as a failure of current resources assigned to the DU role failing to meet certain needs or requirements, or failing to stay below a certain threshold ratio), the first role performed using a first physical server computer included in the plurality of physical server computers (i.e., operating in a cloud environment, see ¶0005, see also ¶0068, i.e., “the source DU 320a in the current server”, read as a first physical server computer of the cloud environment/plurality of server computers); and
in response to the failure in performing the first role using the first physical server computer, perform the first role using a second physical server computer included in the plurality of physical server computers (see ¶0051, i.e., “request a cloud platform, e.g., Kubernetes, to create a new target DU 320b create a new target DU”, also see Fig. 5A, ref. 509, “select server for scaling out”, and ¶0068, i.e., “…execute the service of the target DU 320b in another server”, read as a second physical server of the cloud environment/plurality of server computers).
It would have been obvious to a person having ordinary skill in the art, prior to the earliest effective filing date of the claimed invention, to modify the teachings of Stefanik with the teachings of Kwon to similarly virtualize, in a similar cloud environment as taught by Kwon, the various unit/device roles related to the distributed antenna system in Stefanik (e.g., … plurality of master/upstream unit [roles], see Fig. 1, ref. 108, also see ¶0013, “DAS systems can include active elements such as master units, extension units, and remote units” read as roles, and/or see ¶0024 intermediary devices [roles]). The obvious motivation for doing so would have been to achieve similar benefits as shown with virtualization of the CU and DU roles in Kwon, such as saving overall operational costs (see for example, Kwon ¶0035).
As per claim 2, Stefanik teaches the various DAS roles (e.g., a plurality of master/upstream unit [roles], see Fig. 1, ref. 108, also see ¶0013, “DAS systems can include active elements such as master units, extension units, and remote units” read as roles, and/or see ¶0024 intermediary devices [roles]). In addition, although Stefanik does not teach, in the same art as noted above, Kwon further teaches virtualizing the DAS to: in response to the failure in performing the first role using the first physical server computer, adjust how the first role is performed for the vDAS when performed using the second physical server computer (see ¶0069, e.g., “…the RU with the largest throughput may be selected, and the target DU 320b may be executed in the server having the capacity of being capable of processing the peak rate, and the target DU 320b may be allowed to process the corresponding RU”, read as an example of adjusting how the service/DU performs processing on behalf of corresponding RUs).
The same motivation that was utilized for combining the teachings of Stefanik and Kwon for virtualizing the DAS in claim 1, applies equally well to claim 2.
As per claim 3, Stefanik does not teach, however, Kwon further teaches, following virtualization, how the first role is performed for the vDAS when performed using the second physical server computer is adjusted by reducing a load associated with performing the first role for the vDAS using the second physical server computer (see ¶0069, e.g., “…the RU with the largest throughput may be selected, and the target DU 320b may be executed in the server having the capacity of being capable of processing the peak rate, and the target DU 320b may be allowed to process the corresponding RU”, read as adjusting load associated with the DU role using processing resources of the server on which the target DU is created).
The same motivation that was utilized for combining the teachings of Stefanik and Kwon for virtualizing the DAS in claim 1, applies equally well to claim 3.
As per claim 4, Stefanik teaches prior to the failure in performing the first role performing included in the plurality of roles performed for the DAS (e.g., a plurality of master/upstream unit [roles], see Fig. 1, ref. 108, also see ¶0013, “DAS systems can include active elements such as master units, extension units, and remote units” read as roles). Stefanik does not teach, however, in the same art as noted above, Kwon further teaches virtualizing the DAS such that:
in response to the failure in performing the first role using the first physical server computer, adjust how the other role is performed for the vDAS when the first role is performed for the vDAS using the second physical server computer (see ¶0051 and ¶0068, i.e., “…execute the service of the target DU 320b in another server”, also see for example, Fig. 3A, which anticipates, following scaling of the DU to the other server, traffic being routed from the target DU 320b to the CU, in other words the CU is thereafter adjusted to receive traffic from the newly created target DU).
Kwon, however, does not expressly teach the other role, i.e., CU, being implemented using the second physical server computer (i.e., the same server of the target DU 320b). Nevertheless, similar to making integral (see MPEP §2144.04), co-locating the roles (i.e., CU or DU in Kwon, or in the context of DAS, the master, extension, and/or RRU roles, see Stefanik see Fig. 1, ref. 108 and/or 104, also see ¶0013) on the same server, would have been obvious design choice to a person having ordinary skill in the art. The obvious motivation for doing so would have been to improve data (e.g., uplink/downlink data) latency between units/roles.
The same motivation that was utilized for combining the teachings of Stefanik and Kwon for virtualizing the DAS in claim 1, applies equally well to claim 4.
As per claim 6, Stefanik does not teach, however, in the same art as noted above, Kwon further teaches virtualizing the DAS such that: how the other role (e.g., CU) is performed for the vDAS using the second physical server computer when the first role is performed for the vDAS using the second physical server computer is adjusted in order to accommodate performing the first role and the other role using the second physical server computer (see for example, where modifications or adjustment to the F1 splitter 311, which is described as part of the CU, see ¶0049, are made to accommodate the taget DU 320b executing in the second/other server).
The same motivation that was utilized for combining the teachings of Stefanik and Kwon for virtualizing the DAS in claim 1, applies equally well to claim 6.
As per claim 7, Stefanik does not teach, however, in the same art as noted above, Kwon further teaches virtualizing the DAS such that how the first role (e.g., DU) is performed for the vDAS using the second physical server computer is adjusted … by doing one or more of the following: … performing one or more services or features less often, less frequently, or in a less processor intensive manner (see ¶0051 and ¶0068, i.e., “…execute the service of the target DU 320b in another server”, read as a less processor intensive manner compared to performing the DU/first role with a single server).
The same motivation that was utilized for combining the teachings of Stefanik and Kwon for virtualizing the DAS in claim 1, applies equally well to claim 7.
As per claim 8, Stefanik does not teach, however, in the same art as noted above, Kwon further teaches virtualizing the DAS such that prior to the failure in performing the first role using the first physical server computer, communicate first data to the first physical server computer for use in performing the first role (i.e., “existing (source) DU-RU-UE (terminal) data flow” see for example, ¶0008, also see Fig. 3C); in response to determining the failure in performing the first role, causing the first data to be communicated to the second physical server computer for use in performing the first role (see ¶0058, i.e., “the data flow is migrated to the target DU 320b”).
The same motivation that was utilized for combining the teachings of Stefanik and Kwon for virtualizing the DAS in claim 1, applies equally well to claim 8.
As per claim 9, Stefanik teaches a DAS system including a master unit serving one or more of donor base stations (see Fig. 1, ref. 108, also see ¶0049, i.e., an “upstream unit 108 (such as a master unit)”); and
wherein the first data comprises downlink data communicated for the one or more donor base stations (see Fig.1, ref. 110, also see ¶0025, “convert first downlink signals from the external device 112”) served by the master unit (i.e., upstream/master unit, see Fig. 1, 108).
As noted above, Stefanik does not expressly teach virtualizing the master unit, i.e., a virtual MU. Nevertheless, in the same art as noted above, Kown teaches the use and benefit of virtualizing wireless networking functions/roles (i.e., operating CU and DU, read as roles, in a cloud environment, see ¶0005).
The same motivation that was utilized for combining the teachings of Stefanik and Kwon for virtualizing the DAS in claim 1, applies equally well to claim 9.
As per claim 10, Stefanik further teaches wherein the first role comprises a first an intermediate combining node role serving one or more of the access points (i.e., modular component 204-1, see ¶0043, i.e., “the modular component 204-1 aggregates at least one uplink signal received from a radio frequency antenna 120-1 with another uplink signal received from another radio frequency antenna 120”, read as an intermediate combining node role); and
wherein the first data comprises uplink data communicated for the one or more access points served by the ICN role. Id.
As noted above, Stefanik does not expressly teach virtualizing the modular component 204-1, i.e., a virtual ICN. Nevertheless, in the same art as noted above, Kown teaches the use and benefit of virtualizing wireless networking functions/roles (i.e., operating CU and DU, read as roles, in a cloud environment, see ¶0005).
The same motivation that was utilized for combining the teachings of Stefanik and Kwon for virtualizing the DAS in claim 1, applies equally well to claim 10.
As per claim 11, Stefanik further teaches wherein each of the plurality of roles performed for the vDAS comprise a respective set of services (e.g., see ¶0023, i.e., “optical conversion and/or an optical to electrical conversion occurs in at least one of the upstream units 108”, read as services with respect to the master unit; and/or see Fig 5. and/or ¶0051, i.e., “to convert and process signals between the at least one communication interface 302 and the RF amplification section 306”, read as services with respect to the remote unit/role. Also see ¶0064 “the units, devices, processors etc. described herein may include or function with software programs, firmware, or other computer readable instructions for carrying out various methods, process tasks, calculations, and control functions”, which further suggests various services, i.e., methods, process tasks, etc., performed by the various units/devices).
As per claim 12, although Stefanik does not teach wherein the respective set of services for each of the plurality of roles performed for the vDAS comprise a respective one or more mandatory services and one or more optional services. Nevertheless, similar to omitting functions (see §MPEP 2144.04), designating services performed by the various DAS/vDAS roles in Stefanik as mandatory or optional, would have been an obvious design choice to a person having ordinary skill in the art prior to the earliest effective filing date of the claimed invention. The obvious motivation for doing so would have been to support different use cases.
As per claim 13, Stefanik further teaches wherein the plurality of roles performed for the vDAS comprise one or more master unit (MU) roles for the DAS (see Fig. 1, ref. 108, also see ¶0049, i.e., an “upstream unit 108 (such as a master unit)”) and one or more intermediate combining node (ICN) roles for the DAS (i.e., modular component 204-1, see ¶0043, i.e., “the modular component 204-1 aggregates at least one uplink signal received from a radio frequency antenna 120-1 with another uplink signal received from another radio frequency antenna 120”, read as an intermediate combining node).
As noted above, Stefanik does not expressly teach virtualizing the master unit, DAS, and ICN/modular component 204-1, i.e., a virtual MU, virtual DAS, and virtual ICN. Nevertheless, in the same art as noted above, Kown teaches the use and benefit of virtualizing wireless networking functions/roles (i.e., operating CU and DU, read as roles, in a cloud environment, see ¶0005).
The same motivation that was utilized for combining the teachings of Stefanik and Kwon for virtualizing the DAS in claim 1, applies equally well to claim 13.
As per claim 14, Stefanik does not expressly teach wherein each of the plurality of access points and each of the donor base stations are communicatively coupled to a respective at least two of the plurality of physical server computers.
Nevertheless, in the same art as noted above, Kwon further teaches each RU communicatively coupled to a respective at least two of the plurality of physical server computers (see for example, Fig. 3C, and ¶0068, i.e., “the source DU 320a in the current server … the target DU 320b in another server”).
The same motivation that was utilized for combining the teachings of Stefanik and Kwon for virtualizing the DAS using multiple servers in claim 1, applies equally well to claim 14.
Claims 15-18 and 20-28 are rejected under the same rationale as claims 1-4 and 6-14 since they recite substantially identical subject matter. Any differences between the claims do not result in patentably distinct claims and all of the limitations are taught by the above cited art.
Claims 5 and 19 are rejected under 35 U.S.C. 103(a) as being unpatentable over the combination of Stefanik and Kwon, in further view of Mukherjee et al. (US 10,791,507)(“Mukerjee”).
As per claim 5, the combination of Stefanik and Kwon does not expressly teach wherein how the other role is performed for the vDAS using the second physical server computer when the first role is performed for the vDAS using the second physical server computer is adjusted by reducing a load associated with performing the other role for the vDAS using the second physical server computer when the first role is performed for the vDAS using the second physical server computer.
Nevertheless, in the same art of network virtualization, Mukherjee teaches a system that no only adjusted/scales a first role (i.e., DU) in response to demand, but also adjusts a second role (i.e., CU) by reducing a load associated with performing the second role (see col. 6, lines 54-57, i.e, “Scaling may entail instantiating one or more additional virtualized CU (vCUs) and/or virtualized DU (vDU) functions as Virtual Network Functions (VNFs) on an NFV platform”).
Similarly, it would have been obvious to a person having ordinary skill in the art, prior to the earliest effective filing date of the claimed invention, to modify the teachings of Stefanik and Kwon with the teachings of Mukerhjee to adjust, or in other words scale multiple roles using the second physical server computer in the cloud environment, and thus reducing a load for a single instance of the other role (e.g., an MU, extension unit, and/or RU, in DAS, see ¶0013). The obvious motivation for doing so would have been to prevent overloading with respect to any one of multiple DAS functions/roles.
Claim 19 is rejected under the same rationale as claim 5 since they recite substantially identical subject matter. Any differences between the claims do not result in patentably distinct claims and all of the limitations are taught by the above cited art.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (see PTO 892).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brendan Higa whose telephone number is (571)272-5823. The examiner can normally be reached Monday - Friday 8:30 AM - 5:00 PM.
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, James Hwang can be reached at (571) 272-4036. 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.
/BRENDAN Y HIGA/Primary Examiner, Art Unit 2441