DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1, it is unclear as to what device or component is performing the recited method. To be more specific, the claim recites “receiving, by a base station, latency measurements…” but does not recite what device or component performs the other steps of “determining a latency requirement…”, “measuring a latency…”, and “triggering a mobility event…”
Regarding claims 2-7, the claims are rejected for depending on claim 1.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 5-9, 12-15, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Meshkati et al. (US 2015/0358959 A1), hereinafter referred to as Meshkati, in view of Horn et al. (US 2016/0057585 A1), hereinafter referred to as Horn.
Regarding claim 1, Meshkati teaches a method (Meshkati – Paragraph [0009], note method for managing performance of a wireless network), comprising:
receiving, by a base station, latency measurements associated with multiple neighboring cells or cell sectors having coverage areas within a certain proximity to the base station (Meshkati – Fig. 10; Paragraph [0103], note femto node 1020 may be the serving node of a UE (e.g., UE 1022), information may be received from neighboring nodes (e.g., target nodes) about higher backhaul delay measurements (backhaul latency measurements over X2 interfaces between neighboring femto nodes or between a cell and an actual or a virtual reference point, see Paragraph [0098]) at the target nodes);
measuring a latency associated with a first cell or cell sector, having a coverage area generated by the base station, that is currently serving the UE (Meshkati – Fig. 10; Paragraph [0098], note the backhaul condition may be identified by computing the backhaul latency measurement between neighboring cells or between a cell and an actual or a virtual reference point, femto node 1020 (which serves UE 1022, see Paragraph [0103]) may identify the backhaul condition by computing the backhaul latency measurements over X2 interfaces between neighboring femto nodes (e.g., femto node 1020 and its neighbor) or a between femto node 1020 and a reference point (e.g., server or a gateway)); and
triggering a mobility event for the UE, based on the measured latency of the first cell or cell sector, and the latency measurements associated with the multiple neighboring cells or cell sectors, to a selected one of the multiple neighboring cells or cell sectors (Meshkati – Fig. 10; Paragraph [0102], note femto node 1020 may trigger an action at femto node 1020 to modify (e.g., change, update, revise, etc.) resource management parameters (e.g., a mobility target and/or a mobility event) based on identifying of the backhaul condition (backhaul latency measurements, see Paragraph [0098]); Paragraph [0103], note information may be received from neighboring nodes (e.g., target nodes) about higher backhaul delay measurements at the target nodes, femto node 1020 may trigger an action (e.g., handover) to a neighboring node that has not reported a similar (e.g., higher) backhaul latency measurement or has reported a lower backhaul latency measurement).
Meshkati does not teach determining a latency requirement of a user equipment device (UE); and triggering a mobility event for the UE, based on the UE’s latency requirement.
In an analogous art, Horn teaches determining a latency requirement of a user equipment device (UE) (Horn – Paragraph [0083], note in order to ensure data delivery reliability requirements (e.g., latency requirements, or QoS requirements) are met, a UE may be configured to send the same duplicate packet to both the MeNB and SeNB); and
triggering a mobility event for the UE, based on the UE’s latency requirement (Horn – Paragraph [0078], note UE mobility configuration allows the RAN to configure the UE to set the RF triggers for mobility, the UE may perform measurements on frequencies or other resources to trigger mobility events to RATs or channel resources specific to a certain type of traffic (e.g., a type defined by latency or other QoS aspects)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate the teachings of Horn into Meshkati in order to provide multiple triggers for UE mobility to meet latency and other QoS requirements (Horn – Paragraph [0078]).
Regarding claim 2, Meshkati does not teach wherein the latency associated with the first cell or cell sector comprises a delay in packet delivery from the base station to the UE.
In an analogous art, Horn teaches wherein the latency associated with the first cell or cell sector comprises a delay in packet delivery from the base station to the UE (Horn – Paragraph [0078], note RF conditions on the serving cell, the UE may perform measurements on frequencies or other resources to trigger mobility events to RATs or channel resources specific to a certain type of traffic (e.g., a type defined by latency or other QoS aspects); Paragraph [0083], note in order to help ensure data delivery reliability requirements (e.g., latency requirements or QoS requirements) are met, a UE may be configured to send the same duplicate packet to both the MeNB and SeNB, by sending duplicate packets to both the MeNB and the SeNB, the probability of successful and timely delivery of the packet, to core network servers for example, may be increased).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate the teachings of Horn into Meshkati for the same reason as claim 1 above.
Regarding claim 5, the combination of Meshkati and Horn, specifically Meshkati teaches the method further comprising:
comparing the measured latency associated with the first cell or cell sector with a threshold associated with the latency requirement (Meshkati – Paragraph [0087], note the backhaul condition may be associated with the backhaul latency measurement above a threshold value),
wherein the mobility event for the UE is further triggered based on the comparison of the measured latency with the first cell or cell sector with the threshold (Meshkati – Paragraph [0087], note triggering an action (e.g., a handover) at the femto node in response to identifying that backhaul latency measurement is above the threshold value; the triggered action may be associated with a mobility target and/or a mobility event, see Paragraph [0101]).
Regarding claim 6, the combination of Meshkati and Horn, specifically Meshkati teaches the method further comprising:
determining a maximum latency threshold based on the latency requirement (Meshkati – Paragraph [0042], note femto node can determine RF parameters for communicating in a network upon occurrence of one or more detected events (which may be backhaul latency measurement above a threshold, see Paragraph [0087])),
wherein comparing the measured latency associated with the first cell or cell sector with the threshold comprises:
comparing the measured latency associated with the first cell or cell sector with the maximum latency threshold to determine whether the measured latency exceeds the maximum latency threshold (Meshkati – Paragraph [0087], note identifying that backhaul latency measurement is above the threshold value), and
wherein the mobility event for the UE is further triggered when the measured latency associated with the first cell or cell sector is determined to exceed the maximum latency threshold (Meshkati – Paragraph [0087], note triggering an action (e.g., a handover) at the femto node in response to identifying that backhaul latency measurement is above the threshold value; the triggered action may be associated with a mobility target and/or a mobility event, see Paragraph [0101]).
Regarding claim 7, the combination of Meshkati and Horn, specifically Meshkati teaches the method further comprising:
comparing the latency measurements associated with multiple neighboring cells or cell sectors with the latency requirement (Meshkati – Paragraph [0103], note information may be received from neighboring nodes (e.g., target nodes) about higher backhaul delay measurements at the target nodes),
wherein the mobility event for the UE is further triggered based on the comparison of the latency measurements associated with the multiple neighboring cells or cell sectors with the latency requirement (Meshkati – Paragraph [0103], note femto node 1020 may trigger an action (e.g., handover) to a neighboring node that has not reported a similar (e.g., higher) backhaul latency measurement or has reported a lower backhaul latency measurement).
Regarding claim 8, Meshkati teaches a base station (Meshkati – Paragraph [0026], note low power base stations, such as femto nodes, can configure radio frequency (RF) parameters based on observations of neighboring access points), comprising:
at least one communication interface configured to receive latency measurements associated with multiple neighboring cells or cell sectors having coverage areas within a certain proximity to the base station (Meshkati – Fig. 10; Paragraph [0103], note femto node 1020 may be the serving node of a UE (e.g., UE 1022), information may be received from neighboring nodes (e.g., target nodes) about higher backhaul delay measurements (backhaul latency measurements over X2 interfaces between neighboring femto nodes or between a cell and an actual or a virtual reference point, see Paragraph [0098]) at the target nodes), and
at least one processor (Meshkati – Fig. 6; Paragraph [0062], note base station 610, which can include a femto node, processor 630) configured to:
measure a latency associated with a first cell or cell sector (Meshkati – Fig. 10; Paragraph [0098], note the backhaul condition may be identified by computing the backhaul latency measurement between neighboring cells or between a cell and an actual or a virtual reference point, femto node 1020 (which serves UE 1022, see Paragraph [0103]) may identify the backhaul condition by computing the backhaul latency measurements over X2 interfaces between neighboring femto nodes (e.g., femto node 1020 and its neighbor) or a between femto node 1020 and a reference point (e.g., server or a gateway)), and trigger a mobility event for the UE, based on the measured latency of the first cell or cell sector, and the latency measurements associated with the multiple neighboring cells or cell sectors, to a selected one of the multiple neighboring cells or cell sectors (Meshkati – Fig. 10; Paragraph [0102], note femto node 1020 may trigger an action at femto node 1020 to modify (e.g., change, update, revise, etc.) resource management parameters (e.g., a mobility target and/or a mobility event) based on identifying of the backhaul condition (backhaul latency measurements, see Paragraph [0098]); Paragraph [0103], note information may be received from neighboring nodes (e.g., target nodes) about higher backhaul delay measurements at the target nodes, femto node 1020 may trigger an action (e.g., handover) to a neighboring node that has not reported a similar (e.g., higher) backhaul latency measurement or has reported a lower backhaul latency measurement).
Meshkati does not teach determining a latency requirement of a user equipment device (UE) that is currently served by the base station; and triggering a mobility event for the UE, based on the UE’s latency requirement.
In an analogous art, Horn teaches determining a latency requirement of a user equipment device (UE) that is currently served by the base station (Horn – Paragraph [0083], note in order to ensure data delivery reliability requirements (e.g., latency requirements, or QoS requirements) are met, a UE may be configured to send the same duplicate packet to both the MeNB and SeNB); and
triggering a mobility event for the UE, based on the UE’s latency requirement (Horn – Paragraph [0078], note UE mobility configuration allows the RAN to configure the UE to set the RF triggers for mobility, the UE may perform measurements on frequencies or other resources to trigger mobility events to RATs or channel resources specific to a certain type of traffic (e.g., a type defined by latency or other QoS aspects)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate the teachings of Horn into Meshkati in order to provide multiple triggers for UE mobility to meet latency and other QoS requirements (Horn – Paragraph [0078]).
Regarding claim 9, the claim is interpreted and rejected for the same reason as claim 2 above.
Regarding claim 12, the claim is interpreted and rejected for the same reason as claim 5 above.
Regarding claim 13, the claim is interpreted and rejected for the same reason as claim 6 above.
Regarding claim 14, the claim is interpreted and rejected for the same reason as claim 7 above.
Regarding claim 15, Meshkati teaches a non-transitory storage medium storing instructions executable by a base station (Meshkati – Fig. 4; Paragraph [0056], note system 400 can reside at least partially within a femto node; Paragraph [0058], note system 400 can include a memory 410 that retains instructions for executing functions associated with the electrical components 404, 406, and 408, which can be a computer program product comprising a computer readable medium), wherein execution of the instructions causes the base station to:
receive latency measurements associated with multiple neighboring cells or cell sectors having coverage areas within a certain proximity to the base station (Meshkati – Fig. 10; Paragraph [0103], note femto node 1020 may be the serving node of a UE (e.g., UE 1022), information may be received from neighboring nodes (e.g., target nodes) about higher backhaul delay measurements (backhaul latency measurements over X2 interfaces between neighboring femto nodes or between a cell and an actual or a virtual reference point, see Paragraph [0098]) at the target nodes);
measure a latency associated with a first cell or cell sector, having a coverage area generated by the base station, that is currently serving the UE (Meshkati – Fig. 10; Paragraph [0098], note the backhaul condition may be identified by computing the backhaul latency measurement between neighboring cells or between a cell and an actual or a virtual reference point, femto node 1020 (which serves UE 1022, see Paragraph [0103]) may identify the backhaul condition by computing the backhaul latency measurements over X2 interfaces between neighboring femto nodes (e.g., femto node 1020 and its neighbor) or a between femto node 1020 and a reference point (e.g., server or a gateway)); and
trigger a mobility event for the UE, based on the measured latency of the first cell or cell sector, and the latency measurements associated with the multiple neighboring cells or cell sectors, to a selected one of the multiple neighboring cells or cell sectors (Meshkati – Fig. 10; Paragraph [0102], note femto node 1020 may trigger an action at femto node 1020 to modify (e.g., change, update, revise, etc.) resource management parameters (e.g., a mobility target and/or a mobility event) based on identifying of the backhaul condition (backhaul latency measurements, see Paragraph [0098]); Paragraph [0103], note information may be received from neighboring nodes (e.g., target nodes) about higher backhaul delay measurements at the target nodes, femto node 1020 may trigger an action (e.g., handover) to a neighboring node that has not reported a similar (e.g., higher) backhaul latency measurement or has reported a lower backhaul latency measurement).
Meshkati does not teach determining a latency requirement of a user equipment device (UE); and triggering a mobility event for the UE, based on the UE’s latency requirement.
In an analogous art, Horn teaches determining a latency requirement of a user equipment device (UE) that is currently served by the base station (Horn – Paragraph [0083], note in order to ensure data delivery reliability requirements (e.g., latency requirements, or QoS requirements) are met, a UE may be configured to send the same duplicate packet to both the MeNB and SeNB); and
triggering a mobility event for the UE, based on the UE’s latency requirement (Horn – Paragraph [0078], note UE mobility configuration allows the RAN to configure the UE to set the RF triggers for mobility, the UE may perform measurements on frequencies or other resources to trigger mobility events to RATs or channel resources specific to a certain type of traffic (e.g., a type defined by latency or other QoS aspects)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate the teachings of Horn into Meshkati in order to provide multiple triggers for UE mobility to meet latency and other QoS requirements (Horn – Paragraph [0078]).
Regarding claim 18, the claim is interpreted and rejected for the same reason as claim 5 above.
Regarding claim 19, the claim is interpreted and rejected for the same reason as claim 6 above.
Regarding claim 20, the claim is interpreted and rejected for the same reason as claim 7 above.
Claims 4, 11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Meshkati in view of Horn as applied to claims 1, 8, and 15 above, and further in view of Yang et al. (US 2019/0208438 A1), hereinafter referred to as Yang.
Regarding claim 4, the combination of Meshkati and Horn does not teach wherein the latency requirement comprises a maximum latency required by a network slice to which the UE has been assigned or to which the UE has subscribed.
In an analogous art, Yang teaches wherein the latency requirement comprises a maximum latency required by a network slice to which the UE has been assigned or to which the UE has subscribed (Yang – Paragraph [0059], note network slice classifier may classify UE devices into network slices based on particular UE device attribute categories, such as, for example, categories based on a latency requirement (which may be a low latency requirement, typically having a threshold as known in the art, see Paragraph [0036])).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to incorporate the teachings of Yang into the combination of Meshkati and Horn in order to identify and classify UE traffic based on information indicating latency requirements (Yang – Paragraphs [0070]-[0071]).
Regarding claim 11, the claim is interpreted and rejected for the same reason as claim 4 above.
Regarding claim 17, the claim is interpreted and rejected for the same reason as claim 4 above.
Allowable Subject Matter
Claim 3 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Claims 10 and 16 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
Applicant’s dependent claims recite wherein each of the latency measurements associated with the multiple neighboring cells or cell sectors comprises a delay in packet delivery from a respective base station associated with each one of the multiple neighboring cells and at least one UE traversing the one of the multiple neighboring cells, which is neither taught nor suggested by the prior art.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wang et al. (US 2014/0079022 A1) discloses RRC measurement report including one or more LTE measurements on neighboring cells, and triggering disconnect based on packet latency exceeding a given threshold.
Bogineni et al. (US 2020/0195521 A1) discloses low-latency QoS requirements and detecting a UE mobility event.
Kodaypak et al. (US 2023/0362807 A1) discloses mobility or handover event triggers between a source cell and a target serving cell, and computing latency for active UE application flows.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BAILOR C HSU whose telephone number is (571)272-1729. The examiner can normally be reached Mon-Fri. 9:00 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, Huy Vu can be reached at (571)-272-3155. 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.
/BAILOR C HSU/Primary Examiner, Art Unit 2461