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 .
Response to Arguments
Rejections under 35 USC 102
Applicant’s Argument: Applicant has amended claim 1 to include “resource location information of the multicast service,” arguing that Park fails to teach this being transferred through the core network.
Examiner’s Response: Applicant’s arguments with respect to claim(s) 1 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Applicant has amended the claim to specify resource location which has changed the scope of the invention. An updated search was conducted and a new grounds of rejection is presented.
Examiner notes that Park ¶0223 does teach indicating resource parameter information in a message via the MME (core network) to the second network device, the resource parameter information including subframe allocation information for MBMS. It is known in the art that this would pertain to the specific subframes for MBMS or multicast, thus corresponding to a location of resources. A secondary reference is applied that specifically teaches subframe allocation information indicating location of multicast resources and it would have been obvious to specify this location information in Park.
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.
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.
Claim(s) 1-3, 5, 11-13, 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Park et al. (“Park”) (US 20180160342 A1) in view of Zhai et al. (“Zhai”) (US 20120134311 A1).
Regarding claim 1, Park teaches:
A method for obtaining a multicast resource, performed by a first access network device [Figure 12 eNB2], the method comprising: receiving first information sent by a core network device [Figure 12, ¶0215-220, Handover request and TMGI (corresponding to first information) sent by MME (corresponding to core network device)]; wherein the first information comprises multicast service information of a target multicast service [Figure 12, TMGI included (corresponding to multicast service information) ¶0216-219]; obtaining, according to the first information, a multicast resource of the target multicast service [¶0220, eNB2 obtains MBMS configuration ¶0223 including MBMS resources]; and sending second information to a second access network device through the core network device [¶0223 eNB2 send MBMS configuration to eNB1 (corresponding to second access network device) via MME using Handover Request Acknowledge and Handover command messages each carrying MBMS configuration]; wherein the second information comprises information of the multicast resource [¶0223, second message being Handover Request Acknowledge message including MBMS configuration and resources “In an example, the container may comprise one or more configuration parameters for the UE, e.g. G-RNTI parameter, MBMS (MBMS, SC-PTM, and/or V2X) resource parameter” see earlier “the handover request acknowledge message from the target eNB to the target MME, the forward relocation response message from the target MME to the source MME, and/or the handover command message from the source MME to the source eNB may include a transparent container to be sent to the UE as an RRC message to perform the handover”], and the information of the multicast resource comprises resource allocation information of the multicast service [¶0223, subframe allocation information included in MBMS resource parameter sent via core network to eNB, wherein MBSFN subframes only carry the multicast information, see further MSFN subframes reserved for MBSFN];
wherein the obtaining, according to the first information, the multicast resource of the target multicast service comprises at least one of the following:
reserving the multicast resource for the target multicast service in a case that a radio resource of the first access network device is enough to be allocated to a radio resource required by the target multicast service [¶0217, Figure 12, eNB2 receives handover request message, ¶0219, eNB2 being first access network device schedules MBMS resources (Corresponding to reserving the multicast resource […] in a case that a radio resource […] is enough as Examiner notes it is not defined the criteria for a radio resource being “enough,” thus if a multicast resource is used for the service, it includes a radio resource that is “enough”), followed by acknowledge in ¶0223, thus multicast resource/radio resource is enough to be allocated to radio resource required by multicast service as the service is supported using the allocated resources, see further ¶0147 MBMS resources are radio resources]; or
reserving the multicast resource for the target multicast service, in a case that the target multicast service is a service supported by the first access network device and that the radio resource of the first access network device is enough to be allocated to the radio resource required by the target multicast service.
Park teaches subframe allocation information but does not specify resource location for multicast however it is known in the art that the subframe allocation information for MBMS service would specify the location of subframes i.e. resources for multicast as in Zhai who teaches subframe allocation information including information of the multicast resource comprises resource location information of the multicast service [¶0011, “The physical resource occupied by the MCH, i.e., the number and locations of the occupied multicast subframes” described in a subframe allocation indication].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify the subframe allocation indicating location. It is clear in Park that the subframe allocation would indicate subframes for MBMS, corresponding to a resource location as an indication of subframes for multicast would indicate a location. It would have been obvious to specify the location as in Zhai who teaches location information of subframes for multicast is included in subframe allocation in order that the UE may corrected receive MBMS services in an improved manner as in ¶0010.
Regarding claim 2, Park-Zhai teaches:
The method according to claim 1, wherein after the receiving first information sent by the core network device, the method further comprises: sending third information to the core network device [Park Figure 12, eNB2 sends request acknowledge message comprising multiple parameters considered to include third information after TMGI is received]; wherein the third information comprises resource information for receiving the target multicast service [Park ¶0223 Figure 12 request acknowledge includes MBMS parameters including “In an example, the MBMS (MBMS, SC-PTM, and/or V2X) resource parameter may comprise TMGI, MBMS session ID, SC-MTCH neighbour cell (neighbor cells that provide this MBMS service on SC-MTCH), radioframe allocation period, radioframe allocation offset, subframe allocation information, and/or SC-MTCH scheduling information associated with an MBMS (MBMS, SC-PTM, and/or V2X) service” considered resources for receiving as part of third information].
Regarding claim 3, Park-Zhai teaches:
The method according to claim 1, wherein the multicast service information comprises a multicast service identifier of the target multicast service [Park Figure 12, TMGI included in multicast service information from MME to eNB2 (corresponding to service identifier)].
Regarding claim 5, Park-Zhai teaches:
The method according to claim 1, wherein the obtaining, according to the first information, the multicast resource of the target multicast service comprises at least one of following:
reserving the multicast resource for the target multicast service in a case that the target multicast service is a service supported by the first access network device [Park ¶0217, Figure 12, eNB2 receives handover request message, ¶0219, eNB2 being first access network device schedules MBMS resources using resources, based on information received and send acknowledge in ¶0223, corresponding to reserving and is supported by the device as it schedules the resources to provide the service]; or obtaining the multicast resource of the target multicast service in a case that the first access network device has provided a radio resource of the target multicast service.
Regarding claim 11, Park teaches:
An access network device, comprising a processor, a memory, and a program or an instruction stored on the memory and executable on the processor, wherein the program or the instruction, when executed by the processor, causes the access network device [Figure 12 eNB2] to perform: receiving first information sent by a core network device [[Figure 12, ¶0215-220, Handover request and TMGI (corresponding to first information) sent by MME (corresponding to core network device)]]; wherein the first information comprises multicast service information of a target multicast service [Figure 12, TMGI included (corresponding to multicast service information)]; obtaining, according to the first information, a multicast resource of the target multicast service [¶0220, eNB2 obtains MBMS configuration ¶0223 including MBMS resources]; and sending second information to a second access network device through the core network device [¶0223 send MBMS configuration to eNB1 (corresponding top second access network device) via MME using Handover Request Acknowledge an Handover command messages]; wherein the second information comprises information of the multicast resource [¶0223, second message being Handover Request Acknowledge message including MBMS configuration and resources “In an example, the container may comprise one or more configuration parameters for the UE, e.g. G-RNTI parameter, MBMS (MBMS, SC-PTM, and/or V2X) resource parameter” see earlier “the handover request acknowledge message from the target eNB to the target MME, the forward relocation response message from the target MME to the source MME, and/or the handover command message from the source MME to the source eNB may include a transparent container to be sent to the UE as an RRC message to perform the handover”], and the information of the multicast resource comprises resource allocation information of the multicast service [¶0223, subframe allocation information included in MBMS resource parameter sent via core network to eNB, wherein MBSFN subframes only carry the multicast information, see further MSFN subframes reserved for MBSFN];
wherein the obtaining, according to the first information, the multicast resource of the target multicast service comprises at least one of the following:
reserving the multicast resource for the target multicast service in a case that a radio resource of the first access network device is enough to be allocated to a radio resource required by the target multicast service reserving the multicast resource for the target multicast service in a case that a radio resource of the first access network device is enough to be allocated to a radio resource required by the target multicast service [¶0217, Figure 12, eNB2 receives handover request message, ¶0219, eNB2 being first access network device schedules MBMS resources (Corresponding to reserving the multicast resource […] in a case that a radio resource […] is enough as Examiner notes it is not defined the criteria for a radio resource being enough, thus if a multicast resource is used for the service, it includes a radio resource that is “enough”), followed by acknowledge in ¶0223, thus multicast resource/radio resource is enough to be allocated to radio resource required by multicast service as the service is supported using the allocated resources, see further ¶0147 MBMS resources are radio resources]; or
reserving the multicast resource for the target multicast service, in a case that the target multicast service is a service supported by the first access network device and that the radio resource of the first access network device is enough to be allocated to the radio resource required by the target multicast service.
Park teaches subframe allocation information but does not specify resource location for multicast however it is known in the art that the subframe allocation information for MBMS service would specify the location of subframes i.e. resources for multicast as in Zhai who teaches subframe allocation information including information of the multicast resource comprises resource location information of the multicast service [¶0011, “The physical resource occupied by the MCH, i.e., the number and locations of the occupied multicast subframes” described in a subframe allocation indication].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify the subframe allocation indicating location. It is clear in Park that the subframe allocation would indicate subframes for MBMS, corresponding to a resource location as an indication of subframes for multicast would indicate a location. It would have been obvious to specify the location as in Zhai who teaches location information of subframes for multicast is included in subframe allocation in order that the UE may corrected receive MBMS services in an improved manner as in ¶0010.
Regarding claim 12, Park-Zhai teaches:
The access network device according to claim 11, wherein the program or the instruction, when executed by the processor, causes the access network device to further perform: sending third information to the core network device [Park Figure 12, eNB2 sends request acknowledge message comprising multiple parameters considered to include third information after TMGI is received]; wherein the third information comprises resource information for receiving the target multicast service [Park ¶0223 Figure 12 request acknowledge includes MBMS parameters including “In an example, the MBMS (MBMS, SC-PTM, and/or V2X) resource parameter may comprise TMGI, MBMS session ID, SC-MTCH neighbour cell (neighbor cells that provide this MBMS service on SC-MTCH), radioframe allocation period, radioframe allocation offset, subframe allocation information, and/or SC-MTCH scheduling information associated with an MBMS (MBMS, SC-PTM, and/or V2X) service” considered resources for receiving].
Regarding claim 13, Park-Zhai teaches:
The access network device according to claim 11, wherein the multicast service information comprises a multicast service identifier of the target multicast service [Park Figure 12, TMGI included in multicast service information from MME to eNB2 (corresponding to service identifier)].
Regarding claim 15, Park-Zhai teaches:
The access network device according to claim 11, wherein the program or the instruction, when executed by the processor, causes the access network device to perform at least one of following: reserving the multicast resource for the target multicast service in a case that the target multicast service is a service supported by the first access network device [Park ¶0217, Figure 12, eNB2 receives handover request message, ¶0219, eNB2 being first access network device schedules MBMS resources using resources, based on information received and send acknowledge in ¶0223, corresponding to reserving and is supported by the device as it schedules the resources to provide the service]; or obtaining the multicast resource of the target multicast service in a case that the first access network device has provided a radio resource of the target multicast service.
Claim(s) 4, 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Park et al. (“Park”) (US 20180160342 A1) in view of Zhai et al. (“Zhai”) (US 20120134311 A1) and KR 20150048618 A (hereinafter ‘618).
Regarding claim 4, Park-Zhai teaches:
The method according to claim 3. Park teaches sending multicast information but not QoS however ‘618 teaches wherein the multicast service information further comprises quality of service (QoS) requirement information of the target multicast service [¶0091-97, step 280, MME forward information to target eNB, including QoS parameter].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify sending QoS parameter as in ‘618. Park teaches sending multicast information and it would have been obvious to further include QoS parameter information as ¶0091-97 shows these are known elements in multicast contexts thus it would have been an obvious combination of prior art elements according to known techniques for providing group communication serves while efficiently using resources see page 7-8.
Regarding claim 14, Park-Zhai teaches: The access network device according to claim 13.
Park teaches sending multicast information but not QoS however ‘618 teaches wherein the multicast service information further comprises quality of service (QoS) requirement information of the target multicast service [¶0091-97, step 280, MME forward information to target eNB, including QoS parameter].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to specify sending QoS parameter as in ‘618. Park teaches sending multicast information and it would have been obvious to further include QoS parameter information as ¶0091-97 shows these are known elements in multicast contexts thus it would have been an obvious combination of prior art elements according to known techniques for providing group communication serves while efficiently using resources see page 7-8.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAY L. VOGEL whose telephone number is (303)297-4322. The examiner can normally be reached Monday-Friday 8AM-4:30 PM MT.
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, Joseph Avellino can be reached on 571-272-3905. 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.
/JAY L VOGEL/ Primary Examiner, Art Unit 2478