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 .
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.
This action is responsive to the Remark filed on 11/14/25.
Claims 1, 10 & 17 are amended. Claim 8-9 is canceled.
Claim(s) 1-7, 10-18 is/are presented for examination.
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 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 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.
Claim(s) 1, 5-6, 10, 14-15, 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen, U.S. Pub/Patent No. 2018/0041922 A1 in view of Yi, US 2005/0270996 A1, and further in view of Vajapeyam, US 20170041767A1.
As to claim 1, Chen teaches a method, comprising:
receiving, by a wireless communication device, multicast radio resource configuration information from a network (Chen, page 5, paragraph 68; page 6, paragraph 69; i.e., [0068] At the receiving end, Step 110 may include restoring the RLC PDU through the MAC layer in accordance with an MAC header indicator in the received data; [0069] For the implementation of configuring the new air-interface protocol stack, more details will be given in the following by taking merely one air-interface protocol layer); and
configuring, by the wireless communication device according to the multicast radio resource configuration information, an air interface protocol stack of the wireless communication device to define communications between the wireless communication device and one or more network nodes (Chen, page 4, paragraph 53 & 57; page 5, paragraph 68; page 6, paragraph 69; page 7, paragraph 98; i.e., [0057] The data transmission method in FIG. 1 may be implemented by a network side device for a communication network such as a cellular network and a WLAN network, e.g., a base station in the cellular network, or an access point in the WLAN network. Correspondingly, the opposite communication end in communication with the network side device may be a terminal. It should be appreciated that, the opposite communication end in communication with the network side device may also be another network side device; [0098] In the case of receiving the air-interface protocol stack, for the implementation mode where the known air interface protocol stack is adopted, different air-interface protocol stacks may be adopted. For example, one air interface protocol stack may merely include the MAC layer, while the other air-interface protocol stack may merely include the PDCP layer and the RLC layer).
But Chen failed to teach the claim limitation wherein including a radio link control (RLC) bearer configuration from a network, wherein the RLC bearer configuration includes at least one of a plurality of RLC bearer types, the plurality of RLC bearer types including;_(i) a RLC bearer of type 1 being of a point-to-point (PTP) type and (ii) a RLC bearer of type 2 being of a point-to-multipoint (PTM) type; wherein: for a multicast radio bearer configured with the RLC bearer of type 1, each PDCP entity corresponding to the multicast radio bearer is associated with an acknowledged mode (AM) RLC entity, or unacknowledged mode (UM) RLC entities for corresponding directions; for a multicast radio bearer configured with the RLC bearer of type 2, each PDCP entity corresponding to the multicast radio bearer is associated with at least one UM DL RLC entity: and for a multicast radio bearer configured with both the RLC bearer of type 1 and the RLC bearer of type 2, each PDCP entity corresponding to the multicast radio bearer is associated with: the AM RLC entity or the UMV RLC entities, and the at least one UM DL RLC entity.
However, Yi teaches the limitation wherein including a radio link control (RLC) bearer configuration from a network, wherein the RLC bearer configuration includes at least one of a plurality of RLC bearer types, the plurality of RLC bearer types including;_(i) a RLC bearer of type 1 being of a point-to- point (PTP) type and (ii) a RLC bearer of type 2 being of a point-to-multipoint (PTM) type (Yi, page 3 paragraph 21-25; i.e., [0025] The UTRAN employs a radio bearer to provide a MEMS bearer service to a terminal. The types of MEMS bearers used by the UTRAN include a point-to-multipoint (p-t-m) radio bearer and a point-to-point (p-t-p) radio bearer; [0023] the type of radio bearer for the particular MEMS service is informed to be a point-to-multipoint type, the terminal receives the MEMS radio bearer information to obtain the point-to-multipoint radio bearer information, and configures a point-to-multipoint radio bearer).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Chen to substitute radio interface protocol from Yi for air interface protocol stack from Chen to providing effective header compression function with respect to each PS service (Yi, page 1, paragraph 7).
However, Vajapeyam teaches the limitation wherein: for a multicast radio bearer configured with the RLC bearer of type 1, each PDCP entity corresponding to the multicast radio bearer is associated with an acknowledged mode (AM) RLC entity, or unacknowledged mode (UM) RLC entities for corresponding directions (Vajapeyam, page 3 paragraph 31-33; page 4, paragraph 44; i.e., [0031] a legacy RLC acknowledged mode), a delay sensitive mode (e.g., replacing a legacy RLC unacknowledged mode with no guaranteed reliability); [0032] the PDCP layer may manage reordering and discard procedures for two types of bearers, which may include a "type 1" radio bearer that may have a relatively high reliability target, and a "type 2" radio bearer that may have a relatively low delay target ( e.g., a low latency target) without guaranteed reliability. In traditional systems, a type 1 radio bearer may be handled at the RLC layer through an acknowledgment mode (AM) operation, and a type 2 radio bearer may be handled at the RLC through an unacknowledged mode (UM) operation; [0044] a legacy RLC acknowledged mode), a delay sensitive mode (e.g., replacing a legacy RLC unacknowledged mode with no guaranteed reliability)); for a multicast radio bearer configured with the RLC bearer of type 2, each PDCP entity corresponding to the multicast radio bearer is associated with at least one UM DL RLC entity (Vajapeyam, page 3 paragraph 31-33; page 4, paragraph 44; i.e., [0031] a legacy RLC acknowledged mode), a delay sensitive mode (e.g., replacing a legacy RLC unacknowledged mode with no guaranteed reliability); [0032] the PDCP layer may manage reordering and discard procedures for two types of bearers, which may include a "type 1" radio bearer that may have a relatively high reliability target, and a "type 2" radio bearer that may have a relatively low delay target ( e.g., a low latency target) without guaranteed reliability. In traditional systems, a type 1 radio bearer may be handled at the RLC layer through an acknowledgment mode (AM) operation, and a type 2 radio bearer may be handled at the RLC through an unacknowledged mode (UM) operation), a delay sensitive mode (e.g., replacing a legacy RLC unacknowledged mode with no guaranteed reliability)): and for a multicast radio bearer configured with both the RLC bearer of type 1 and the RLC bearer of type 2, each PDCP entity corresponding to the multicast radio bearer is associated with: the AM RLC entity or the UMV RLC entities, and the at least one UM DL RLC entity (Vajapeyam, page 3 paragraph 31-33; page 4, paragraph 44; i.e., [0031] a legacy RLC acknowledged mode), a delay sensitive mode (e.g., replacing a legacy RLC unacknowledged mode with no guaranteed reliability); [0032] the PDCP layer may manage reordering and discard procedures for two types of bearers, which may include a "type 1" radio bearer that may have a relatively high reliability target, and a "type 2" radio bearer that may have a relatively low delay target ( e.g., a low latency target) without guaranteed reliability. In traditional systems, a type 1 radio bearer may be handled at the RLC layer through an acknowledgment mode (AM) operation, and a type 2 radio bearer may be handled at the RLC through an unacknowledged mode (UM) operation).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Chen to substitute radio interface protocol from Vajapeyam for air interface protocol stack from Chen to supporting communication with multiple users by sharing the available system resources (Vajapeyam, page 1, paragraph 3).
As to claim 5, Chen-Yi-Vajapeyam teaches the method as recited in claim 1, wherein the multicast radio resource configuration information includes a packet data convergence protocol (PDCP) configuration (Chen, page 7, paragraph 98; i.e., [0098] In the case of receiving the air-interface protocol stack, for the implementation mode where the known air interface protocol stack is adopted, different air-interface protocol stacks may be adopted. For example, one air interface protocol stack may merely include the MAC layer, while the other air-interface protocol stack may merely include the PDCP layer and the RLC layer. At this time, different identification information may be assigned for different air-interface protocol stacks).
As to claim 6, Chen-Yi-Vajapeyam teaches the method as recited in claim 1, wherein the multicast radio resource configuration information includes at least one operation corresponding to a multicast radio bearer configuration a MAC and PHY layer configuration set associated with a multicast service (Chen, page 7, paragraph 98; i.e., [0098] In the case of receiving the air-interface protocol stack, for the implementation mode where the known air interface protocol stack is adopted, different air-interface protocol stacks may be adopted. For example, one air interface protocol stack may merely include the MAC layer, while the other air-interface protocol stack may merely include the PDCP layer and the RLC layer. At this time, different identification information may be assigned for different air-interface protocol stacks).
As to claim 10, Chen-Yi-Vajapeyam teaches the method as recited in claim 8, wherein a peer RLC entity of the network to the RLC entity associated with the RLC bearer of type 1 serves a specific wireless communication device that receives the multicast service, and a peer RLC entity of the network to the RLC entity associated with the RLC bearer of type 2 serves at least one wireless communication device that receives the multicast service (Chen, page 11, paragraph 151; i.e., [0151] The RLC PDUs from a plurality of bearers (which may bear MAC SDUs at the MAC layer) may be cascaded at the MAC layer into an MAC PDU, and an MAC header may be added, and then the resultant MAC PDU may be transmitted to the physical layer. After the corresponding treatment through the physical layer, the MAC PDU).
As to claim 14, Chen-Yi-Vajapeyam teaches the method as recited in claim 5, wherein the RLC bearer configuration and the MAC and PHY layer configuration set are provided through a broadcast channel and broadcast in a cell, or through dedicated signaling to a specific wireless communication device (Chen, page 5, paragraph 68; page 6, paragraph 69; page 7, paragraph 98; i.e., [0069] For the implementation of configuring the new air-interface protocol stack, more details will be given in the following by taking merely one air-interface protocol layer; [0098] In the case of receiving the air-interface protocol stack, for the implementation mode where the known air interface protocol stack is adopted, different air-interface protocol stacks may be adopted. For example, one air interface protocol stack may merely include the MAC layer, while the other air-interface protocol stack may merely include the PDCP layer and the RLC layer. At this time, different identification information may be assigned for different air-interface protocol stacks).
As to claim 15, Chen-Yi-Vajapeyam teaches the method as recited in claim 5, wherein a Step 1 configuration comprises the multicast radio resource configuration information (Chen, page 5, paragraph 68; page 6, paragraph 69; page 7, paragraph 98; i.e., [0098] In the case of receiving the air-interface protocol stack, for the implementation mode where the known air interface protocol stack is adopted, different air-interface protocol stacks may be adopted. For example, one air interface protocol stack may merely include the MAC layer, while the other air-interface protocol stack may merely include the PDCP layer and the RLC layer. At this time, different identification information may be assigned for different air-interface protocol stacks).
Claim(s) 17, 18 is/are directed to a system claims and they do not teach or further define over the limitations recited in claim(s) 1, 5. Therefore, claim(s) 17, 18, is/are also rejected for similar reasons set forth in claim(s) 1, 5.
Claim(s) 2-4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen, U.S. Pub/Patent No. 2018/0041922 A1 in view of Yi, US 2005/0270996 A1, and Vajapeyam, US 20170041767A1, and Abraham, U.S. Patent/Pub. No. 2020/0092923 A1.
As to claim 2, Chen-Yi-Vajapeyam teaches the method as recited in claim 1. But Chen-Yi-Vajapeyam failed to teach the claim limitation wherein sending, by the wireless communication device, a multicast service request to the network, prior to the receiving of the multicast radio resource configuration.
However, Abraham teaches the limitation wherein sending, by the wireless communication device, a multicast service request to the network, prior to the receiving of the multicast radio resource configuration (Abraham, page 3, paragraph 49; i.e., [0049] the network node may be a multicast session management function (M-SMF). The request may identify a multicast service session including at least one multicast quality of service (QoS) flow. The network node may identify that the multicast service session lacks a tunnel from a second network node to the base station to transport multicast packets of the multicast service session).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Chen-Yi-Vajapeyam to substitute wireless access communication system from Abraham for D2D communication from Chen-Yi-Vajapeyam to provide various types of communication content such as voice, video, packet data, messaging and broadcast (Abraham, page 1, paragraph 3).
As to claim 3, Chen-Yi-Vajapeyam-Abraham teaches the method as recited in claim 2. But Chen-Yi-Vajapeyam failed to teach the claim limitation wherein sending, by the wireless communication device, the multicast service request to a multicast session management function or entity of a core network.
However, Abraham teaches the limitation wherein sending, by the wireless communication device, the multicast service request to a multicast session management function or entity of a core network (Abraham, page 8, paragraph 87; i.e., [0087] transport using a fifth generation (5G) core network functions, and provides multimedia broadcast and multicast services using the appropriate 5G core network service based on service requirements).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Chen-Yi-Vajapeyam to substitute wireless access communication system from Abraham for D2D communication from Chen-Yi-Vajapeyam to provide various types of communication content such as voice, video, packet data, messaging and broadcast (Abraham, page 1, paragraph 3).
As to claim 4, Chen-Yi-Vajapeyam-Abraham teaches the method as recited in claim 2. But Chen-Yi-Vajapeyam failed to teach the claim limitation wherein sending, by the wireless communication device, the multicast service request to a radio access network (RAN) node.
However, Abraham teaches the limitation wherein sending, by the wireless communication device, the multicast service request to a radio access network (RAN) node (Abraham, page 12, paragraph 118; i.e., [0118] new radio network
deployment by enabling multicast transport in 5G core network, RAN to UE communications ( e.g., handling reception of multicast service in idle mode, reliability of reception, enabling retransmissions)).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Chen-Yi-Vajapeyam to substitute wireless access communication system from Abraham for D2D communication from Chen-Yi-Vajapeyam to provide various types of communication content such as voice, video, packet data, messaging and broadcast (Abraham, page 1, paragraph 3).
Claim(s) 7, 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen, U.S. Pub/Patent No. 2018/0041922 A1 in view of Yi, US 2005/0270996 A1, and Vajapeyam, US 20170041767A1, and further in view of Tie, U.S. Patent/Pub. No. 2019/0124529 A1.
As to claim 7, Chen-Yi-Vajapeyam teaches the method as recited in claim 5. But Chen-Yi-Vajapeyam failed to teach the claim limitation wherein the multicast radio resource configuration information includes a service data adaptation protocol (SDAP) configuration, wherein the SDAP configuration includes a multicast service session identifier for identifying a session corresponding to the multicast service.
However, Tie teaches the limitation wherein the SDAP configuration includes a multicast service session identifier for identifying a session corresponding to the multicast service (Tie, page 9, paragraph 157; i.e., [0157] a session ID of the current multicast service, a G-RNTI corresponding to the session ID, and detect, on a PDCCH
according to the obtained configuration information of the current multicast service).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Chen-Yi-Vajapeyam to substitute modify configuration information from Tie for identification information from Chen-Yi-Vajapeyam to improve the capability of receiving an SC-MCCH transmitted by the base station (Tie, page 1, paragraph 5).
As to claim 11, Chen-Yi-Vajapeyam teaches the method as recited in claim 5. But Chen-Yi-Vajapeyam failed to teach the claim limitation wherein a multicast medium access control (MAC) and physical (PHY) layer configuration set of the multicast service includes at least one of: a MAC discontinuous reception (DRX) configuration corresponding to the multicast service, a cell identifier list that the multicast service is scheduled to, a bandwidth part (BWP) index associated with the multicast service, or a physical downlink shared data channel (PDSCH) configuration and a physical downlink control channel (PDCCH) configuration.
However, Tie teaches the limitation wherein the SDAP configuration includes a multicast service session identifier for identifying a session corresponding to the multicast service (Tie, page 9, paragraph 157; i.e., [0157] a session ID of the current multicast service, a G-RNTI corresponding to the session ID, and detect, on a PDCCH
according to the obtained configuration information of the current multicast service).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Chen-Yi-Vajapeyam to substitute modify configuration information from Tie for identification information from Chen-Yi-Vajapeyam to improve the capability of receiving an SC-MCCH transmitted by the base station (Tie, page 1, paragraph 5).
As to claim 12, Chen-Yi-Vajapeyam teaches the method as recited in claim 5. But Chen-Yi-Vajapeyam failed to teach the claim limitation wherein there is a mapping relationship between a physical layer identifier of the multicast service and a session identifier, and the mapping relationship is provided through dedicated signaling to a specific wireless communication device.
However, Tie teaches the limitation wherein the SDAP configuration includes a multicast service session identifier for identifying a session corresponding to the multicast service (Tie, page 9, paragraph 157; i.e., [0157] a session ID of the current multicast service, a G-RNTI corresponding to the session ID, and detect, on a PDCCH
according to the obtained configuration information of the current multicast service).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Chen-Yi-Vajapeyam to substitute modify configuration information from Tie for identification information from Chen-Yi-Vajapeyam to improve the capability of receiving an SC-MCCH transmitted by the base station (Tie, page 1, paragraph 5).
Claim(s) 13 & 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chen, U.S. Pub/Patent No. 2018/0041922 A1 in view of Yi, US 2005/0270996 A1, and Vajapeyam, US 20170041767A1, and further in view of Parron, U.S. Patent/Pub. No. 2022/0159760 A1.
As to claim 13, Chen-Yi-Vajapeyam teaches the method as recited in claim 5. But Chen-Yi-Vajapeyam failed to teach the claim limitation wherein a logical channel identifier (LCID) corresponding to an RLC bearer includes at least two LCID values, lcid2-1 and lcid2-2, wherein a MAC entity submits service data in a received MAC PDU to a logical channel identified by lcid2-2, if the corresponding LCID value in a sub-header of the received MAC PDU is lcid2-1.
However, Parron teaches the limitation wherein a logical channel identifier (LCID) corresponding to an RLC bearer includes at least two LCID values, lcid2-1 and lcid2-2, wherein a MAC entity submits service data in a received MAC PDU to a logical channel identified by lcid2-2, if the corresponding LCID value in a sub-header of the received MAC PDU is lcid2-1 (Parron, page 3, paragraph 48, table 1; i.e., [0048] In an embodiment, if a new MAC CE is introduced, the Logical Channel Identifier list (LCID) may be enhanced as shown in Table 1).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Chen-Yi-Vajapeyam to substitute access node from Parron for decision node from Chen-Yi-Vajapeyam to wirelessly communicate data, the UE connects to a node of a radio access network (RAN) and synchronizes with the network (Parron, page 1, paragraph 2).
As to claim 16, Chen-Yi-Vajapeyam teaches the method as recited in claim 1. But Chen-Yi-Vajapeyam failed to teach the claim limitation wherein a Step 1 configuration includes an enabling or disabling operation of the type 1 RLC bearer or the type 2 RLC bearer that serves a multicast bearer associated with the multicast service.
However, Parron teaches the limitation wherein a Step 1 configuration includes an enabling or disabling operation of the type 1 RLC bearer or the type 2 RLC bearer that serves a multicast bearer associated with the multicast service (Parron, page 3, paragraph 42; i.e., [0042] Furthermore, this disclosure describes methods for the UE to provide recommendations to the network to enable PDCP data duplication for an IMS voice bearer ( e.g., based on audio coder performance) or to change a default Radio Link Control (RLC) bearer in scenarios where dual connectivity is enabled).
It would have been obvious to one of ordinary skill in the art before the effective date of the claimed invention to modify Chen-Yi-Vajapeyam to substitute access node from Parron for decision node from Chen-Yi-Vajapeyam to wirelessly communicate data, the UE connects to a node of a radio access network (RAN) and synchronizes with the network (Parron, page 1, paragraph 2).
Response to Arguments
Applicant's arguments with respect to claim(s) 1-7, 10-18 have been considered but are moot in view of the new ground(s) of rejection.
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 extension fee 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 date of this final action.
Listing of Relevant Arts
Wu, U.S. Patent/Pub. No. US 20230036769 A1 discloses Type 1 & 2 of the RLC.
Contact Information
The present application is being examined under the pre-AIA first to invent provisions.
THUONG NGUYEN whose telephone number is (571)272-3864. The examiner can normally be reached on Monday-Friday 9:00-6:00.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Noel Beharry can be reached on 571-270-5630. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/THUONG NGUYEN/Primary Examiner, Art Unit 2416