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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 01/03/2023 has been entered.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-2, 16, and 18-20, is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Narayanan et al. (US 2023/0029998 A1).
Regarding claim 1 and 19, Narayanan discloses:
a communication device (fig.1a element 114 depicts a network device), comprising:
a processor (par.[0125] describes a processor); and
a memory (par.[0125] describes a memory) storing a program or instruction that is executable on the processor, wherein the program or instruction (par.[0125] describes the processor configured to execute a computer program which is stored on a memory), when executed by the processor (par.[0218] which discloses a processor configured to execute instructions) causes the communication device to perform:
a message sending method (fig.3 and par.[0096] wherein the UE forwards the MBMS configuration and/or service request to the network via the RRC_RESUME) performed by the user device device (par.[0096] describes the transmission of the request to the network by the user device), comprising:
receiving a target RRC message (par.[0096] the MBMS configuration/service message for MBMS counting or on-demand) from a terminal (fig.1 depicts a terminal in wireless communications with a base station), wherein the target RRC message is an RRC message that requires activated access stratum security (par.[0096] which describes the MBMS counting procedure sent in the RRC_RESUME); and
the target RRC message is sent in a non-RRC connected state (par.[0096] describes the RRC_RESUME, wherein RRC_RESUME is transmitted from the RRC_INACTIVE or RRC_IDLE state) in a case that the terminal is in the non-RRC connected state and has a need to send the target RRC message (par.[0098] describes an on-demand request from the UE to the network. Thus, the terminal has a need and when using the RRC_RESUME is in a non-connected state).
wherein before the sending a target RRC message, the method further comprises:
triggering an RRC connection resume process (par.[0096] describes an MBMS counting procedure and on-demand MBMS request are combined with an RRC message such as RRC_RESUME) to generate either an RRCResumeRequest or an RRCResumeRequest1 message (par.[0096] which describes the RRC Resume message. The office notes that the RRC_RESUME comprises either RRC_RESUME_REQUEST or the RRC_RESUME_REQUEST 1) and submit either the RRCResumeRequest or the RRCResumeRequest1 message to a bottom layer (par.[0096] describes performing the RRC_RESUME which would result the RRC layer forwarding to the bottom layers (i.e. the MAC and PHY layer) the request message for transmission); and
triggering generation of content of the target RRC message, and triggering submission of the target RRC message to the bottom layer (par.[0096] as discussed above, the UE RRC layer would generate the content of the RRC message and transmit it to the lower layers for transmission over the physical medium, such that the network would receive the RRC message).
wherein the sending a target RRC message comprises:
multiplexing the target RRC message and either the RRCResumeRequest or the RRCResumeRequest1 message into a same Media Access Control PROTOCOL DATA UNIT (MAC PDU) and sending the MAC PDU to the network side device (par.[0096] describes multiplexing a MBMS counting procedure and a RRC_RESUME, which comprises either the RRC_RESUME or RRCResumeRequest1. The MAC PDU would comprise the SDU from the upper layer and multiplexed into a MAC PDU for transmission over a physical layer. The office takes official notice that when RRC_RESUME is used for transmitting a MBSM counting, the UE higher layer SDUs are encapsulated in a layer 2 (i.e. MAC layer) PDU which is then submitted to a physical layer for transport over a physical medium)., par.[0096] which recites, in part, “a MBMS counting procedure and on-demand request procedure may be combined into a single procedure. According to embodiments, a WTRU may request (e.g., for) a MBMS configuration and/or a MBMS service in any of an RRC connection request, a RRC connection re-establishment message, and a RRC resume message. According to embodiments, a WTRU may be configured to receive a MBMS configuration in any of system information (e.g., a SIB) or in an RRC response (e.g. a MSG4, or similar).”. par.[0098] any of an MBMS configuration and an MBMS service, for example, in any of an RRC connection request message, a RRC connection re-establishment message, and a RRC resume message.” See Stefania et al. “LTE UMTS Long Term Evolution, From Theory to Practice”, Second Edition, pg.88).
Regarding claims 16 and 20, Narayanan discloses:
a communication device (fig.1a element 114 depicts a network device), comprising:
a processor (par.[0125] describes a processor); and
a memory (par.[0125] describes a memory) storing a program or instruction that is executable on the processor, wherein the program or instruction (par.[0125] describes the processor configured to execute a computer program which is stored on a memory), when executed by the processor (par.[0218] which discloses a processor configured to execute instructions) causes the communication device to perform:
a message receiving method (fig.3 and par.[0096] wherein the UE forwards the MBMS configuration and/or service request to the network via the RRC_RESUME) performed by the network side device (par.[0096] describes the transmission of the request to the network), comprising:
receiving a target RRC message (par.[0096] the MBMS configuration/service message for MBMS counting or on-demand) from a terminal (fig.1 depicts a terminal in wireless communications with a base station), wherein the target RRC message is an RRC message that requires activated access stratum security (par.[0096] which describes the MBMS counting procedure sent in the RRC_RESUME); and
the target RRC message is sent in a non-RRC connected state (par.[0096] describes the RRC_RESUME, wherein RRC_RESUME is transmitted from the RRC_INACTIVE or RRC_IDLE state) in a case that the terminal is in the non-RRC connected state and has a need to send the target RRC message (par.[0098] describes an on-demand request from the UE to the network. Thus, the terminal has a need and when using the RRC_RESUME is in a non-connected state).
wherein before the sending a target RRC message, the method further comprises:
triggering an RRC connection resume process (par.[0096] describes an MBMS counting procedure and on-demand MBMS request are combined with an RRC message such as RRC_RESUME) to generate either an RRCResumeRequest or an RRCResumeRequest1 message (par.[0096] which describes the RRC Resume message. The office notes that the RRC_RESUME comprises either RRC_RESUME_REQUEST or the RRC_RESUME_REQUEST 1) and submit either the RRCResumeRequest or the RRCResumeRequest1 message to a bottom layer (par.[0096] describes performing the RRC_RESUME which would result the RRC layer forwarding to the bottom layers (i.e. the MAC and PHY layer) the request message for transmission); and
triggering generation of content of the target RRC message, and triggering submission of the target RRC message to the bottom layer (par.[0096] as discussed above, the UE RRC layer would generate the content of the RRC message and transmit it to the lower layers for transmission over the physical medium, such that the network would receive the RRC message).
wherein the sending a target RRC message comprises:
multiplexing the target RRC message and either the RRCResumeRequest or the RRCResumeRequest1 message into a same Media Access Control PROTOCOL DATA UNIT (MAC PDU) and sending the MAC PDU to the network side device (par.[0096] describes multiplexing a MBMS counting procedure and a RRC_RESUME, which comprises either the RRC_RESUME or RRCResumeRequest1. The MAC PDU would comprise the SDU from the upper layer and multiplexed into a MAC PDU for transmission over a physical layer. The office takes official notice that when RRC_RESUME is used for transmitting a MBSM counting, the UE higher layer SDUs are encapsulated in a layer 2 (i.e. MAC layer) PDU which is then submitted to a physical layer for transport over a physical medium)., par.[0096] which recites, in part, “a MBMS counting procedure and on-demand request procedure may be combined into a single procedure. According to embodiments, a WTRU may request (e.g., for) a MBMS configuration and/or a MBMS service in any of an RRC connection request, a RRC connection re-establishment message, and a RRC resume message. According to embodiments, a WTRU may be configured to receive a MBMS configuration in any of system information (e.g., a SIB) or in an RRC response (e.g. a MSG4, or similar).”. par.[0098] any of an MBMS configuration and an MBMS service, for example, in any of an RRC connection request message, a RRC connection re-establishment message, and a RRC resume message.” See Stefania et al. “LTE UMTS Long Term Evolution, From Theory to Practice”, Second Edition, pg.88, ).
Regarding claim 18, Narayanan discloses:
wherein in a case that the target RRC message is an RRC message related to a configuration of transmission in a first transmission manner, the method further comprises:
sending indication information indicating that a network supports transmission in the first transmission manner to the terminal, or
wherein in a case that the target RRC message is an RRC message related to MBS counting, the method further comprises at least one of the following:
sending indication information indicating that a network supports an MBS to the terminal (par.[0093] describes an explicit indication from the network, par.[0096] describes MBMS counting); or
sending a control message related to MBS counting to the terminal (par.[0093] describes a change in the configuration for MBMS, fig.2 the configuration information is sent), or
wherein in a case that the target RRC message is an RRC message related to an MBS interest indication, the method further comprises at least one of the following:
sending indication information indicating that a network supports an MBS to the terminal (par.[0074 – 0075] describes the interest in the MBMS, causes the terminal par.[0095 – 0096]); or
sending control information related to the MBS to the terminal (par.[0074 – 0075] describes the interest in the MBMS, causes the terminal par.[0095 – 0096])
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.
Claim(s) 3-10 and 12-15, is/are rejected under 35 U.S.C. 103 as being unpatentable over Narayanan as applied to claims 1 and 2, in view of Kim et al. (US 2022/0248493 A1).
Regarding claim 3, Narayanan discloses:
the RRC connection resume process, but does not disclose:
the method further comprises:
setting a resume cause ResumeCause value, wherein the resumeCause value is at least one of the following:
a multiplexed first ResumeCause value; or
a second ResumeCause value, wherein the second ResumeCause value is not related to the target RRC message, or the second ResumeCause value is related to the target RRC message, or wherein in the RRC connection resume process, the method further comprises at least one of the following:
determining to skip performing unified access control (UAC) check;
performing UAC check by using a set first access category and/or access identity(ies); or
performing UAC check by using a set second access category and/or access identity(ies), wherein the second access category and/or access identity(ies) are(is) not related to the target RRC message, or
the second access category and/or access identity(ies) are(is) related to the target RRC message.
In an analogous art, the disclosure of Kim teaches:
setting a resume cause ResumeCause value (par.[0228] describes the RRC resume request with a cause), wherein the resumeCause value is at least one of the following:
a multiplexed first ResumeCause value (par.[0298] describes a first multiplexed resume cause of a plurality of resume causes. Wherein the cause is multiplexed with the message); or
a second ResumeCause value, wherein the second ResumeCause value is not related to the target RRC message, or the second ResumeCause value is related to the target RRC message (par.[0298] which describes a plurality of resume cause values, thus first and/or second resume causes, which may or may not be related to the target message), or wherein in the RRC connection resume process, the method further comprises at least one of the following:
determining to skip performing unified access control (UAC) check;
performing UAC check by using a set first access category and/or access identity(ies) (par.[0227 – 0228] which describes performing resume with UAC, and par.[0305] describes performing the selection of the access category based on the resume procedure); or
performing UAC check by using a set second access category and/or access identity(ies), wherein the second access category and/or access identity(ies) are(is) not related to the target RRC message, or
the second access category and/or access identity(ies) are(is) related to the target RRC message.
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the instant application to combine the teachings of Narayanan for transmitting an RRC_RESUME message with MBMS request, with the disclosure of Kim which describes RRC_RESUME with the UAC. The motivation/suggestion would have been that UAC provides a mechanism for the network to allow or bar access for a particular user request or access category such that the network may provide improved access control to the particular user.
Regarding claim 4, Kim discloses:
wherein the triggering generation of content of the target RRC message comprises at least one of the following:
immediately triggering generation of the content of the target RRC message in a case that the terminal has the need to send the target RRC message to the network side device (fig.22 depicts a UE with mobile originated data that needs to send the data to the network, thus the UE performs an RRC_RESUME procedure, wherein the UL data is multiplexed with the Resume Request and other information on the uplink); or
triggering generation of the content of the target RRC message in the RRC connection resume process, wherein the triggering generation of the content of the target RRC message in the RRC connection resume process comprises at least one of the following:
triggering generation of the content of the target RRC message in an initiation stage of the RRC connection resume process;
triggering generation of the content of the target RRC message before resumption of a signaling radio bearer (SRB)1 in a process of performing actions related to transmission of either the RRCResumeRequest or the RRCResumeRequest1 message;
immediately triggering generation of the content of the target RRC message after resumption of the SRB1 in the process of performing actions related to transmission of either the RRCResumeRequest or the RRCResumeRequest1 message; or
immediately triggering generation of the content of the target RRC message after submission of either the RRCResumeRequest or the RRCResumeRequest1 message to the bottom layer in the process of performing actions related to transmission of either the RRCResumeRequest or the RRCResumeRequest1 message.
Regarding claim 5, Kim discloses:
wherein the triggering submission of the target RRC message to the bottom layer comprises at least one of the following:
immediately triggering submission of the target RRC message to the bottom layer after resumption of an SRB1 in a process of performing actions related to transmission of either the RRCResumeRequest or the RRCResumeRequest1 message (par.[0242] which recites, in part, “Based on the RRC setup message, the UE-RRC layer may establish SRB1.” Par.[0314] describes the ResumeRequest multiplexed with a cause or request (e.g. the cause or request in the resume message is considered the target RRC message, which is multiplexed with the RRC_Resume). The Office notes that as discussed in fig.2b depicts the 5G protocol stack, the messages are transmitted to lower layers in order to be transmitted over the physical layer, thus, the information multiplexed or any information created in the RRC layer would need to be sent to the PHY layer for transmission over a physical medium, par.[0305 – 0308] which recites, in part, “Based on initiating the transmission of the RRC resume request message, the UE may re-establish PDCP entities for SRB1, resume SRB1 and submit the RRC resume request message to lower layers”); or
immediately triggering submission of the target RRC message to the bottom layer after submission of either the RRCResumeRequest or the RRCResumeRequest1 message to the bottom layer in the process of performing actions related to transmission of either the RRCResumeRequest or the RRCResumeRequest1 message (As discussed above, the ResumeRequest is multiplexed with cause or other control information which is transmitted to the network at the same time as the RRC_RESUME. Additionally, the RRC initiates the resume process, and thus, must transmit the resume message to lower layer PDCP, RLC, MAC, and then PHY so that the message may be transmitted to the base station).
Regarding claim 6, the disclosure of Kim teaches:
after the content in the target RRC message is generated, storing the content in the target RRC message in a first form, or determining to skip storing the content in the target RRC message, wherein the first form comprises at least one of the following:
a variable, an array, or a struct (fig.22 depicts a RRC_RESUME message with a plurality of variables, structures, or arrays, which are configured to convey information additional to the RRC_RESUME).
Regarding claim 7, the disclosure of Kim teaches:
and wherein the MAC PDU comprises at least one of the following:
either the RRCResumeRequest or the RRCResumeRequest1 message is before the target RRC message; or
either the RRCResumeRequest or the RRCResumeRequest1 message is after the target RRC message (the office notes that the transmission of data multiplexed with an RRC Resume may be transmitted to a lower layer before or after the resume request, as the target message information will be multiplexed at the MAC and PHY layers).
Regarding claim 8, Kim discloses:
initiating a random access process at a MAC layer, wherein a trigger event of the random access process is at least one of the following:
a multiplexed first trigger event (fig.22 depicts the transmission of the RRC_RESUME with cause, data, etc. multiplexed therewith); or
a second trigger event, wherein the second trigger event is not related to the target RRC message, or the second trigger event is related to the target RRC message, and
wherein a configuration of resources and parameters in the random access process is at least one of the following:
completely performing configuration in a separate manner (fig.13 element 1310 wherein the RACH resources are configured prior to the RACH procedure);
completely multiplexing the configuration of resource and parameter in the random access process with a first configuration (fig.13b which teaches a 2-step RACH with a MSGA that completely multiplexes); or
partially multiplexing the configuration of resources and parameters in the random access process with first configuration and partially performing configuration in a separate manner (fig.13c depicts a 4 step RACH wherein the Resume may be sent in a first message and the target wherein the preamble which is a resource is sent separately thus partial multiplexing).
Regarding claim 9, Kim discloses:
wherein before the sending a target RRC message, the method further comprises:
requesting resumption of an RRC connection at an RRC layer, and initiating transmission in a first transmission manner (par.[0229] describes the RRC Resume procedure started in the RRC layer of the UE); and
performing transmission in the first transmission manner at a MAC layer (par.[0229] describes the RRC layer can configure lower layer. Par.[0300] describes the resume request being sent to lower layers. The RACH can comprise transmission of preamble and data in MSG A or MSG 3, see fig.13 which would cause the MAC to create a PDU comprising a SDU, CE, etc. as show in fig.4).
Regarding claim 10, Kim discloses:
wherein an initiation condition of transmission in the first transmission manner is at least one of the following:
resumption of the RRC connection is requested at the RRC layer (par.[0227 – 0228] describes the UE-RRC layer initiating the resume procedure);
the terminal supports transmission in the first transmission manner;
a network supports transmission in the first transmission manner;
the terminal has a valid configuration of the first transmission manner; the terminal has a valid timing alignment value;
the terminal has a stored nextHopChainingCount value, and the nextHopChainingCount value is provided by suspendConfig in a latest RRC release message; or
a size of the MAC PDU comprising the target RRC message is less than or equal to a transport block size (TBS) defined in the configuration of the first transmission manner.
Regarding claim 12, Kim discloses:
wherein before the sending a target RRC message, the method further comprises:
requesting resumption of an RRC connection at an RRC layer, and initiating transmission in a second transmission manner (fig.13 each describe a RACH based EDT mechanism, each of the RACH could be considered a different transmission manner, as the RACH process are transmitted differently. Additionally, as discussed above, the RRC layer is responsible for initiating RRC messaging, see e.g. UE-RRC layer initiates the RRC_RESUME as discussed above); and
performing transmission in the second transmission manner at a MAC layer (as discussed above the MAC layer constructs a PDU comprised of CE, SDU, and other elements to be sent to a lower layer, e.g. the PHY layer for transmission over a physical medium. The MAC and PHY layer construct the frame and perform multiplexing of control information and data such that the information may be sent over a physical medium to a receiver as shown in fig(s). 1, 4, 13, 15, and 22).
Regarding claim 13, Kim discloses:
wherein an initiation condition of transmission in the second transmission manner is at least one of the following:
resumption of the RRC connection is requested at the RRC layer (fig(s).18 and 22 depict the initiation of the RRC_RESUME at the UE-RRC layer, see associated disclosure);
the terminal supports transmission in the second transmission manner;
a network supports transmission in the second transmission manner;
the terminal has a stored nextHopChainingCount value, and the nextHopChainingCount value is provided by suspendConfig in a latest RRC release message;
all parameters related to transmission in the second transmission manner are configured in system information acquired by the terminal; or
a size of the MAC PDU comprising the target RRC message is less than or equal to a transport block size (TBS) defined in a configuration of transmission of the second transmission manner.
Regarding claim 14, Kim discloses:
further comprising:
triggering the RRC layer to configure the bottom layer to perform transmission in the second transmission manner (as discussed above the UE-RRC layer sends the lower layer the RRC_RESUME information), which is at least one of the following:
immediately triggering, after an initiation condition of transmission in the second transmission manner is met, the RRC layer to configure the bottom layer to perform transmission in the second transmission manner (fig.18 and fig.22 along with the disclosure teaches that when triggered the RRC layer will configure and then send pertinent RRC Resume information to lower layers, such as PDCP, MAC, and PHY, layers);
triggering, before resumption of an SRB1 in a process of performing actions related to transmission of either the RRCResumeRequest or the RRCResumeRequest1 message, the RRC layer to configure the bottom layer to perform transmission in the second transmission manner;
immediately triggering, after resumption of the SRB1 in the process of performing actions related to transmission of either the RRCResumeRequest or the RRCResumeRequest1 message, the RRC layer to configure the bottom layer to perform transmission in the second transmission manner; or
immediately triggering, after submission of either the RRCResumeRequest or the RRCResumeRequest1 message to the bottom layer in the process of performing actions related to transmission of either the RRCResumeRequest or the RRCResumeRequest1 message, the RRC layer to configure the bottom layer to perform transmission in the second transmission manner.
Regarding claim 15, Kim discloses:
wherein when the target RRC message is an RRC message related to a configuration of a first transmission manner, the terminal has the need to send the target RRC message to the network side device (fig.22 depicts a cause for the RRC resume) in a case that at least one of the following is met:
the terminal supports transmission in the first transmission manner (par.[0298] depicts the cause for transmission of Resume, along target RRC message corresponding to a transmission need at the UE);
a network supports transmission in the first transmission manner;
a size of a MAC PDU comprising the target RRC message is less than or equal to a maximum transport block size (TBS) supported by the terminal that is defined based on a terminal category; or
the terminal meets at least one of the following:
the terminal is interested in the configuration of the first transmission manner, the terminal is no longer interested in the configuration of the first transmission manner, or the terminal needs to update the configuration of the first transmission manner, or wherein when the target RRC message is an RRC message related to multi-cast broadcast service MBS counting,
the terminal has the need to send the target RRC message to the network side device in a case that at least one of the following is met: the terminal has an MBS capability; a network supports an MBS;
a size of a MAC PDU comprising the target RRC message is less than or equal to a maximum TBS supported by the terminal that is defined based on a terminal category;
an RRC layer of the terminal receives a control message related to MBS counting that is sent by the network side device;
or the terminal is receiving or is interested in receiving at least one MBS indicated in the control message related to MBS counting, wherein when the target RRC message is an RRC message related to an MBS interest indication, the terminal has the need to send the target RRC message to the network side device in a case that at least one of the following is met:
the terminal has an MBS capability; a network supports an MBS; a size of a MAC PDU comprising the target RRC message is less than or equal to a maximum TBS supported by the terminal that is defined based on a terminal category;
the terminal receives control information related to the MBS that is sent by the network side device; the terminal enters or leaves a service area;
an MBS session starts or stops;
content of an MBS interest indication message changes; or
a cell or a base station that sends the control information related to the MBS changes.
Allowable Subject Matter
Claim 11 is 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 office notes that the prior art does not disclose forwarding a PUR configuration Request to the network in the RRC_RESUME receiving the configuration and performing the method of claim 11.
Response to Arguments
Claim Rejections - 35 USC § 102
Applicant's arguments filed 01/13/2026 have been fully considered but they are not persuasive.
The applicant alleges a number of deficiencies in the Final Office Action dated 11/14/2025, and in particular alleges that the prior art reference do not disclose:
"an RRCResumeRequest message let alone an RRCResumeRequest1 message".
The office respectfully disagrees with the applicants assertion. For example, the prior art reference Narayanan (US 2023/0029998 A1) describes the RRCResume message which the applicant asserts is not the same as the RRCResumeRequest or RRCResumeRequest1.
With regard to the disclosure of Narayanan the UE has the capability of transmitting an RRCResume message. The message being used to request MBMS configuration and/or a service. The RRCResume message comprises either an RRCResumeRequest or RRCResumeRequest1 as these are RRCResume messages which are sent from the UE side, and well known in the art. See for example, par.[0096] "According to embodiments, a WTRU may request (e.g., for) a MBMS configuration and/or a MBMS service in any of an RRC connection request, a RRC connection re-establishment message, and a RRC resume message." As the RRC Resume message is sent from the UE side it is pertinent and more than reasonable to interpret the RRC Resume message as either of the RRCResumeRequest or ResumeRequest1 as these are the two well-known RRC Resume messages which are initially sent from the UE side to the network side. For example, the disclosure of 3GPP TS 38.331 version 16.0.0 Release 16 dated 2020-04 which predates the applicants disclosure and is being used as example to show the message being sent from the WTRU/UE which is an RRCResume message is a request message, on pgs.252-253, which describe the message sent from the UE to the network to resume or request and update.
It would be unreasonable to consider the RRCResume message as an RRCResumeRequest or ResumeRequest1 if the message was being sent by the network side instead of from the User Equipment (UE), however, as is discussed in Narayanan the WTRU/UE sends the RRCResume message, and thus, the disclosure of Narayanan teaches the transmission of RRCResume Message which must be either of the ResumeRequest or the ResumeRequest1.
Additionally, applicant also acknowledges that the RRCResume message is an RRCResumeRequest, see pg.13, Applicant Remarks:
"Narayanan teaches at paragraph [0096] that a MBMS request is part of an RRC Control message (such as an RRCResumeRequest such as an information element.”
As can be seen the applicant challenges their own assertion that the RRCResume message is not an RRCResumeRequest message. The claims are rejected.
The applicant also alleges that the disclosure of Narayanan does not disclose that the message is transmitted with access stratum security. The office disagrees with this assertion as well.
The office notes that access stratum signaling takes place between the UE and the access network (e.g. the base station) as opposed to non-access stratum signaling between the UE and the core network. The office further notes that signaling which takes place over a signaling radio bearer such as SRB0 or SRB1 automatically comprises access stratum security. By providing access stratum security over signaling messages allows for the UE to encrypt or prevent unauthorized sniffing or snooping on messages which are sent between the UE and the network.
In addition 3GPP discusses when access stratum security is activated, and the associated messages which are well known. That is, the transmission of RRCResume message implicitly comprises activated access stratum security. For example 3GPP 33.501 pg.67-70 details the access stratum security which is established when sending RRCResume message on the Signaling Radio Bearer. The office notes that it is implicit and necessary to establish access stratum security when transmitting a message over a signaling radio bearer which carries pertinent security information. Thus, the disclosure of Narayanan implicitly discloses the transmission of the RRCResume message comprising the access stratum security.
The applicant further alleges that the disclosure of Narayanan does not teach the "target RRC message and the RRCResumeRequest transmitted in parallel".
The office notes that the RRCResume and the target RRCResume are multiplexed. See “multiplexing the target RRC message and either the RRCResumeRequest or the RRCResumeRequest1 into the same Media Access Control Protocol Data Unit (MAC PDU)”. It is believed that the applicant is equating parallel transmission to multiplexing which is taught by the Narayanan disclosure, as discussed below.
Narayanan teaches a MAC PDU comprises two separate messages which are multiplexed together. The office notes that the IE is multiplexed with ResumeMessage. By multiplexing an IE or additional information with RRCResume such as a configuration or some other type of additional information the network may reduce signaling overhead when transmitting the configuration information and the RRC Resume in the MAC PDU over the physical layer. If the applicant is alleging that if the additional information is an Information Element (IE) it is not multiplexed, this is incorrect, and in fact applicants own specification describes the multiplexing of an IE into the RRCResume, par.[0071] which recites, in part, "a multiplexed first ResumeCause value, for example, mo-data, mo-signal, and the like;" par.[0072] "or [0072] a second ResumeCause value." par.[0074] "In another implementation, the second ResumeCause value may be related to the target RRC message, for example, an “XXConfigurationRequest message”, and the ResumeCause value is set to the “XXConfigurationRequest message”. Being related to the target RRC message may be related to the message type or form of the target RRC message, or may be related to the content of the target RRC message.".
Thus it is shown that when the RRCResume message comprising an IE the IE is multiplexed with resume message over a MAC PDU. Therefore, even when the UE transmits an IE including a need for a configuration this is multiplexed with RRCResume message in the MAC PDU which will be sent. Narayanan fig.3 describes the transmission of the RRCResume message multiplexed with MBMS configuration, par.[0098] "transmit a message including and/or indicating a request) for any of an MBMS configuration and an MBMS service, for example, in any of an RRC connection request message, a RRC connection re-establishment message, and a RRC resume message.". As can be seen, the RRCResume must multiplex the MBMS service request into the RRCResume message, which when done, reduces signaling overhead. Thus the claims are rejected for the reasons given above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMAAL HENSON whose telephone number is (571)272-5339. The examiner can normally be reached M-Thu: 7:30 am - 6:30 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, Derrick Ferris can be reached at (571)272-3123. 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.
JAMAAL HENSON
Primary Examiner
Art Unit 2411
/JAMAAL HENSON/Primary Examiner, Art Unit 2411