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 § 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) 1, 3-10 and 12-15, and 19, is/are rejected under 35 U.S.C. 103 as being unpatentable over Narayanan et al. (US 2023/0029998 A1), in view of Kim et al. (US 2022/0248493 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 (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).
While the disclosure of Narayanan substantially discloses the claimed subject matter, it may not disclose:
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; and
performing transmission in the first transmission manner at a MAC layer
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;
the terminal supports transmission in the second transmission manner;
a network supports transmission in the second 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.
In an analogous art, the disclosure of Kim teaches:
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 (par.[0229] describes the RRC Resume procedure started in the RRC layer of the UE); and
performing transmission in the second 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, wherein the second transmission manner can be either the 2-step RACH or a 4-step RACH)
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 second transmission manner (fig.13a – 13c and elements 1310, 1320, 1330, wherein the network, (e.g. a base station) forwards parameters needed for either type of transmission manner. Wherein a 4-step or a 2-step RACH can be a second transmission manner. Additionally, the RRC_RESUME is sent in either a MSGA or MSG3, thus in order to transmit the RRC_RESUME_REQUEST, the station must support and receive configuration for either of the transmission manners);
a network supports transmission in the second transmission manner (fig.13a – 13c and elements 1310, 1320, 1330, wherein the network, (e.g. a base station) forwards parameters needed for either type of transmission manner. Wherein a 4-step or a 2-step RACH can be a second transmission manner. Additionally, the RRC_RESUME is sent in either a MSGA or MSG3, thus in order to transmit the RRC_RESUME_REQUEST, the station must support and receive configuration for either of the transmission manners. As discussed above, a network can configure the UE for either or both 2-step and 4-step RACH procedures. Thus, when the UE is configured with a particular RACH configuration it now supports the RACH configuration, conversely when the network sends RACH configuration for a particular type of RACH, it is an indication that the network supports that type of RACH);
the terminal has a valid configuration of the first transmission manner (fig.13a -13c and the network sends the PRACH configuration information to the terminal device, 1310, 1320, 1330);
the terminal has a valid timing alignment value (par.[0179] additionally, when the UE needs to perform RRC_RESUME_REQUEST it needs to be synchronized with the network, thus, as discussed in the paragraph, the UE will, if needed, receive a valid Timing-Alignment Command which is used to adjust the transmission timing of the UE. Then, when adjusted, the UE can perform MSG3 or MSGA that allows for RRC_RESUME_REQUEST to be sent);
the terminal has a stored nextHopChainingCount value (par.[0293] which describes the nextHopChainingCount value), and the nextHopChainingCount value is provided by suspendConfig in a latest RRC release message (fig.19 and par.[0229] describes an RRC_RESUME procedure. In order to perform an RRC_RESUME procedure the UE must be in an RRC_INACTIVE state, wherein prior to entering the RRC_INACTIVE state the UE must receive an RRC_CONNECTION_RELEASE with a SuspendConfig. Par.[0293] describes the SuspendConfig as having the Next Hop Chaining Count Value (NCC) as a SuspendConfig parameter); 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 (it is known that in order to perform EDT/SDT the TBS must be equal to or below a threshold data size in order to perform the EDT/SDT without receiving an UL grant, see par.[0336]).
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 when performing a RRC_RESUME along with additional information such as data, and an additional RRC message, the UE is able to reduce signaling overhead by supplying multiple data items in a single message.
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 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.
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])
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 § 103
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 Non-Final Office Action dated 11/14/2025, and in particular alleges that the prior art reference do not disclose:
"the initiation condition of transmission in the second transmission manner".
The office respectfully disagrees with the applicants assertion. For example, the prior art references Narayanan (US 2023/0029998 A1) in view of Kim (US 2022/0248493 A1) describes the RRCResume utilizing at least two different types of transmission modes.
For example, the disclosure of Kim at fig(s).13a – c, depict a 4-step RACH and a 2-step RACH. In the rejection, the office notes that either of the RACH processes may be considered a second transmission mode, as it is not specified in the claims.
Additionally, the RACH process is used for performing RRC_RESUME, such that in order to perform RRC_RESUME, the UE must be configured for either of the RACH types. As shown in the figures 13, the network configures a UE with a RACH configuration as discussed in par.[0172 – 0175] and element 1310, 1320, and 1330. This is, at a bare minimum what is needed to perform RRC_RESUME utilizing a second transmission mode, and taught by Kim, and claimed in the claims below. Additionally, the disclosure of Kim teaches a plurality of other conditions, which are, if needed, necessary in order to perform RRC_RESUME, utilizing the second transmission manner. For example, prior to sending a MSG3 or MSGA which is utilized to send the RRCResumeRequest, the UE must be time aligned with the network node, see claimed valid Timing Alignment Timer (TA). As discussed in the rejection, the network in a Random Access Response (RAR) can provide a Timing Alignment Command, which is used, when needed to allow the UE to have a valid TA. As can be seen, the disclosure of Kim substantially discloses the claimed subject matter, and thus the claims are rejected in view of the above prior art references.
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 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
Prosecution Insights