Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
Response to Arguments
Applicant’s arguments with respect to claims 21-40 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/forms/. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 21-40 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 4-5, 7-8, 11, 14-15 and 18-19 of U.S. Patent No. 11,310,288. Although the claims at issue are not identical, they are not patentably distinct from each other because claims 21-41 are either anticipated by or obvious variants of patent claims 1, 4-5, 7-8, 11, 14-15 and 18-19. For example, patent claim 1 includes all limitations of independent claim 21. The remaining dependent claims are either anticipated by or obvious variants of patent claims 1, 4-5, 7-8, 11, 14-15 and 18-19. In particular, the following table shows the corresponding limitations between claims 21-40 and patent claims 1, 4-5, 7-8, 11, 14-15 and 18-19.
Present Application Claims (17/715,183)
Patent Claims (US 11,310,288)
21. (currently amended) A method, comprising: receiving, at a base station from a user equipment (UE) configured to generate an attach request having an attach type a first request comprising an indicator that indicates a type of the first request, a request message including a Radio Resource Control (RRC) establishment cause for setting up an RRC connection, the RRC establishment cause being based upon a value of the attach type of the first attach request; and when the RRC establishment cause indicates that the RRC connection is for an emergency call via a Packet Switched (PS) network, providing, at the base station, radio resources in support of an Internet protocol (IP) multimedia subsystem (IMS) emergency call to the UE wherein the first request is one of an ATTACH REQUEST or a request for a connection with a packet data network.
22. (previously presented) The method of claim 21, wherein the base station includes an evolved universal terrestrial radio access network (EUTRAN) node B (eNB).
23. (previously presented) The method of claim 21, wherein the RRC connection is a signaling connection.
24. (previously presented) The method of claim 21, wherein the emergency call via the PS network comprises at least one of evolved packet system (EPS) emergency call or session, PS emergency, or IMS emergency call or session.
25. (currently amended) A base station, comprising: at least one hardware processor; and a non-transitory computer-readable storage medium coupled to the at least one hardware processor and storing programming instructions for execution by the at least one hardware processor, wherein the programming instructions, when executed, cause the base station to perform operations comprising: receiving, from a user equipment (UE) configured to generate an attach request having an attach type a first request comprising an indicator that indicates a type of the first request, a request message including a Radio Resource Control (RRC) establishment cause for setting up an RRC connection, the RRC establishment cause being based upon a value of the attach type of the attach first request; and when the RRC establishment cause indicates that the RRC connection is for an emergency call via a Packet Switched (PS) network, providing radio resources in support of an Internet protocol (IP) multimedia subsystem (IMS) emergency call to the UE, wherein the first request is one of an ATTACH REQUEST or a request for a connection with a packet data network.
26. (previously presented) The base station of claim 25, wherein the base station includes an evolved universal terrestrial radio access network (EUTRAN) node B (eNB).
27. (previously presented) The base station of claim 25, wherein the RRC connection is a signaling connection.
28. (previously presented) The base station of claim 25, wherein the emergency call via the PS network comprises at least one of evolved packet system (EPS) emergency call or session, PS emergency, or IMS emergency call or session.
29. (currently amended) One or more non-transitory computer-readable media storing computer instructions, that when executed by one or more processors, cause a computing device to perform operations comprising: receiving, at a base station from a user equipment (UE) configured to generate an attach request having an attach type a first request comprising an indicator that indicates a type of the first request, a request message including a Radio Resource Control (RRC) establishment cause for setting up an RRC connection, the RRC establishment cause being based upon a value of the attach type of the first attach request; and when the RRC establishment cause indicates that the RRC connection is for an emergency call via a Packet Switched (PS) network, providing radio resources in support of an Internet protocol (IP) multimedia subsystem (IMS) emergency call to the UE, wherein the first request is one of an ATTACH REQUEST or a request for a connection with a packet data network.
30. (previously presented) The one or more non-transitory computer-readable media of claim 29, wherein the base station includes an evolved universal terrestrial radio access network (EUTRAN) node B (eNB).
31. (previously presented) The one or more non-transitory computer-readable media of claim 29, wherein the RRC connection is a signaling connection.
32. (previously presented) The one or more non-transitory computer-readable media of claim 29, wherein the emergency call via the PS network comprises at least one of evolved packet system (EPS) emergency call or session, PS emergency, or IMS emergency call or session.
33. (currently amended) The method of claim 21, wherein the value of the attach type of the first request is set to evolved packet system (EPS) emergency attach.
34. (currently amended) The base station of claim 25, wherein the value of the attach type of the first request is set to evolved packet system (EPS) emergency attach.
35. (currently amended) The one or more non-transitory computer-readable media of claim 29, wherein the value of the attach type of the first request is set to evolved packet system (EPS) emergency attach.
36. (new) A user equipment (UE), comprising: at least one hardware processor; and a non-transitory computer-readable storage medium coupled to the at least one hardware processor and storing programming instructions for execution by the at least one hardware processor, wherein the programming instructions, when executed, cause the UE station to perform operations comprising: generating, at the UE, a first request comprising an indicator that indicates a type of the first request; generating, at the UE, a request message including a Radio Resource Control (RRC) establishment cause for setting up an RRC connection, the RRC establishment cause being based upon a value of the type of the first request; and when the RRC establishment cause indicates that the RRC connection is for an emergency call via a Packet Switched (PS) network, receiving radio resources in support of an Internet protocol (IP) multimedia subsystem (IMS) emergency call from a base station; wherein the first request is one of an ATTACH REQUEST or a request for a connection with a packet data network.
37. (new) The user equipment of claim 36, wherein the user equipment is a wireless device.
38. (new) The user equipment of claim 36, wherein the RRC connection is a signaling connection.
39. (new) The user equipment of claim 36, wherein the emergency call via the PS network comprises at least one of evolved packet system (EPS) emergency call or session, PS emergency, or IMS emergency call or session.
40. (new) The user equipment of claim 36, wherein the value of the type of the first request is set to evolved packet system (EPS) emergency attach.
1. A method for initiating a Packet Switched (PS) emergency call using a user equipment (UE), the UE including a plurality of protocol layers, the plurality of protocol layers including an Internet Protocol (IP) Multimedia Subsystem (IMS) sublayer, a non-access stratum (NAS) layer and an access stratum (AS) layer, the method comprising: generating, at the UE, a first request comprising an indicator that indicates a request type; determining, at the UE, a Radio Resource Control (RRC) establishment cause based on the request type, wherein the RRC establishment cause indicates that the UE is requesting an establishment of an RRC connection for an emergency call via a PS network; generating, at the UE, a request message for setting up the RRC connection, wherein the request message for setting up the RRC connection includes the RRC establishment cause; and transmitting the request message for setting up the RRC connection to a base station.
Claim 1.
4. The method of claim 1, wherein the RRC connection is a signaling connection.
7. The method of claim 1, wherein the emergency call via the PS network comprises at least one of evolved packet system (EPS) emergency call or session, PS emergency, or IMS emergency call or session.
Claim 1.
Claim 1.
Claim 4.
Claim 5.
15. A non-transitory computer-readable medium storing instructions which, when executed, cause a computing device to perform operations comprising: generating, at a user equipment (UE), a first request comprising an indicator that indicates a request type; determining, at the UE, a Radio Resource Control (RRC) establishment cause based on the request type, wherein the RRC establishment cause indicates that the UE is requesting an establishment of an RRC connection for an emergency call via a Packet Switched (PS) network; generating, at the UE, a request message for setting up the RRC connection, wherein the request message for setting up the RRC connection includes the RRC establishment cause; and transmitting the request message for setting up the RRC connection to a base station.
Claim 15.
18. The non-transitory computer-readable medium of claim 15, wherein the RRC connection is a signaling connection.
19. The non-transitory computer-readable medium of claim 15, wherein the request type comprises a type associated with establishing the PS emergency call via a PS network.
Claim 7.
Claim 7.
Claim 7.
8. A user equipment (UE), comprising: at least one hardware processor; and a non-transitory computer-readable storage medium coupled to the at least one hardware processor and storing programming instructions for execution by the at least one hardware processor, wherein the programming instructions, when executed, cause the at least one hardware processor to perform operations comprising: generating, at the UE, a first request comprising an indicator that indicates a request type; determining, at the UE, a Radio Resource Control (RRC) establishment cause based on the request type, wherein the RRC establishment cause indicates that the UE is requesting an establishment of an RRC connection for an emergency call via a Packet Switched (PS) network; generating, at the UE, a request message for setting up the RRC connection, wherein the request message for setting up the RRC connection includes the RRC establishment cause; and transmitting the request message for setting up the RRC connection to a base station.
Claim 8
11. The UE of claim 8, wherein the RRC connection is a signaling connection.
14. The UE of claim 8, wherein the emergency call via the PS network comprises at least one of evolved packet system (EPS) emergency call or session, PS emergency, or Internet Protocol (IP) Multimedia Subsystem (IMS) emergency call or session.
Claim 7.
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 21-40 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Haapapuro et al (US 2008/0153454) (hereinafter Haapapuro) in view of Watfa et al (US 2010/0297979) (hereinafter Watfa).
Regarding claim 21, Haapapuro discloses a method, comprising:
receiving, at a base station (e.g., eNB) from a user equipment (UE) configured to generate a first request comprising an indicator that indicates a type of the first request (see Haapapuro, Fig. 1, S101, p. [0044], e.g., the user equipment UE, at an initial access to the network, sends an attachment/registration request message to the network);
a request message including an establishment cause for setting up a connection (see Haapapuro, p.[0044], e.g., S102: attachment request (PS emergency service supported)), the establishment cause being based upon a value of the type of the first request (see Haapapuro, p.[0046-0047], e.g., the attachment request message may contain an indication whether or not the user equipment supports packet-switched (PS) emergency services (and wants to have a dedicated bearer for emergency services)); and when the establishment cause indicates that the connection is for an emergency call via a Packet Switched (PS) network (see Haapapuro, p. [0055]), providing, at the base station, radio resources in support of an Internet protocol (IP) multimedia subsystem (IMS) emergency call to the UE (see Haapapuro, Fig. 1, p. [0050], e.g., The eNB adds the previously configured radio bearer parameters to the acceptance message, and forwards it in step S106 to the requesting user equipment UE. In this message, configuration parameters of the bearers are transmitted, i.e. LCIDs for the default service/bearer, LCIDs for the emergency service/bearer, and the TFT for the emergency service/bearer).
Haapapuro discloses the specifics and details concerning connection establishment between user equipment and network are omitted herein as they are not essential for the present invention. Therefore, the user equipment has been described as a single entity without addressing its internal structure in terms of different layer functions such as for example packet data convergence protocol PDCP, mobility management MM and/or radio resource control RRC (see Haapapuro, p. [0100]).
Haapapuro does not expressly disclose a request message including a Radio Resource Control (RRC) establishment cause for setting up an RRC connection; wherein the first request is one of a message effectuating registration of the UE operating in a limited service state or a non-access stratum (NAS) request for an emergency connection with a packet data network. Watfa discloses the above recited limitations (see Watfa, p. [0034], e.g., When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", and p. [0035], e.g., The WTRU may indicate its emergency call capabilities by transmitting a random access preamble to the E-UTRAN prior to sending an actual RRC connection request message, and p. [0037], and p. [0047], e.g., If the WTRU is not registered to the network and attempts to place an emergency call, the WTRU may send a new registration message, (e.g., "emergency attach") that may be piggybacked with any of the RRC messages, (e.g., RRC connection complete, or as a standalone non-access stratum (NAS) message after RRC connection establishment. This new message may be used as an indication to speed up the registration procedure).
It would have been obvious to a person of ordinary skilled in the art before the effective filing date of the claimed invention to incorporate Watfa’s teachings into Haapapuro. The suggestion/motivation would have been to speed up the registration procedure in order to minimize the number of messages (handshake) sent back and forth between the WTRU and the network as suggested by Watfa.
Regarding claim 22, the combined teaching of Haapapuro and Watfa disclose the method of claim 21, wherein the base station includes an evolved universal terrestrial radio access network (EUTRAN) node B (eNB) (see Haapapuro, Fig. 1, p. [0042], e.g., eNB).
Regarding claim 23, the combined teaching of Haapapuro and Watfa disclose the method of claim 21, wherein the RRC connection is a signaling connection between the UE and the base station (see Watfa, p. [0066], e.g., the procedures are finalized by an "accept" message (attach/TAU accept) sent from the network to the WTRU).
Regarding claim 24, the combined teaching of Haapapuro and Watfa disclose the method of claim 21, wherein the emergency call via the PS network comprises at least one of evolved packet system (EPS) emergency call or session, PS emergency (see Haapapuro, p. [0046], e.g., PS emergency services), or IMS emergency call or session .
Regarding claim 25, Haapapuro discloses a base station (see Haapapuro, Fig. 1, e.g., eNB), comprising: at least one hardware processor; and a non-transitory computer-readable storage medium coupled to the at least one hardware processor and storing programming instructions for execution by the at least one hardware processor, wherein the programming instructions, when executed, cause the base station to perform operations comprising:
receiving, from a user equipment (UE) configured to generate a first request comprising an indicator that indicates a type of the first request (see Haapapuro, Fig. 1, S101, p. [0044], e.g., the user equipment UE, at an initial access to the network, sends an attachment/registration request message to the network);
a request message including an establishment cause for setting up a connection (see Haapapuro, p.[0044], e.g., S102: attachment request (PS emergency service supported)), the RRC establishment cause being based upon a value of the type of the first request (see Haapapuro, p.[0046-0047], e.g., the attachment request message may contain an indication whether or not the user equipment supports packet-switched (PS) emergency services (and wants to have a dedicated bearer for emergency services)); and when the establishment cause indicates that the connection is for an emergency call via a Packet Switched (PS) network (see Haapapuro, p. [0055]), providing radio resources in support of an Internet protocol (IP) multimedia subsystem (IMS) emergency call to the UE (see Haapapuro, Fig. 1, p. [0050], e.g., The eNB adds the previously configured radio bearer parameters to the acceptance message, and forwards it in step S106 to the requesting user equipment UE. In this message, configuration parameters of the bearers are transmitted, i.e. LCIDs for the default service/bearer, LCIDs for the emergency service/bearer, and the TFT for the emergency service/bearer), wherein the first request is one of an ATTACH REQUEST (see Haapapuro, p. [0044]) or a request for a connection with a packet data network.
Haapapuro discloses the specifics and details concerning connection establishment between user equipment and network are omitted herein as they are not essential for the present invention. Therefore, the user equipment has been described as a single entity without addressing its internal structure in terms of different layer functions such as for example packet data convergence protocol PDCP, mobility management MM and/or radio resource control RRC (see Haapapuro, p. [0100]).
Haapapuro does not expressly disclose a request message including a Radio Resource Control (RRC) establishment cause for setting up an RRC connection; wherein the first request is one of a message effectuating registration of the UE operating in a limited service state or a non-access stratum (NAS) request for an emergency connection with a packet data network. Watfa discloses the above recited limitations (see Watfa, p. [0034], e.g., When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", and p. [0035], e.g., The WTRU may indicate its emergency call capabilities by transmitting a random access preamble to the E-UTRAN prior to sending an actual RRC connection request message, and p. [0037], and p. [0047], e.g., If the WTRU is not registered to the network and attempts to place an emergency call, the WTRU may send a new registration message, (e.g., "emergency attach") that may be piggybacked with any of the RRC messages, (e.g., RRC connection complete, or as a standalone non-access stratum (NAS) message after RRC connection establishment. This new message may be used as an indication to speed up the registration procedure).
It would have been obvious to a person of ordinary skilled in the art before the effective filing date of the claimed invention to incorporate Watfa’s teachings into Haapapuro. The suggestion/motivation would have been to speed up the registration procedure in order to minimize the number of messages (handshake) sent back and forth between the WTRU and the network as suggested by Watfa.
Regarding claim 26, the combined teaching of Haapapuro and Watfa disclose the base station of claim 25, wherein the base station includes an evolved universal terrestrial radio access network (EUTRAN) node B (eNB) (see Haapapuro, Fig. 1, p. [0042], e.g., eNB).
Regarding claim 27, the combined teaching of Haapapuro and Watfa disclose the base station of claim 25, wherein the RRC connection is a signaling connection between the UE and the base station (see Watfa, p. [0066], e.g., the procedures are finalized by an "accept" message (attach/TAU accept) sent from the network to the WTRU).
Regarding claim 28, the combined teaching of Haapapuro and Watfa disclose the base station of claim 25, wherein the emergency call via the PS network comprises at least one of evolved packet system (EPS) emergency call (see Haapapuro, p. [0046], e.g., PS emergency services) or session, PS emergency , or IMS emergency call or session.
Regarding claim 29, Haapapuro discloses one or more non-transitory computer-readable media storing computer instructions, that when executed by one or more processors, cause a computing device to perform operations comprising:
receiving, at a base station (e.g., eNB) from a user equipment (UE) configured to generate a first request comprising an indicator that indicates a type of the first request (see Haapapuro, Fig. 1, S101, p. [0044], e.g., the user equipment UE, at an initial access to the network, sends an attachment/registration request message to the network);
a request message including an establishment cause for setting up a connection (see Haapapuro, p.[0044], e.g., S102: attachment request (PS emergency service supported)), the RRC establishment cause being based upon a value of the type of the first request (see Haapapuro, p.[0046-0047], e.g., the attachment request message may contain an indication whether or not the user equipment supports packet-switched (PS) emergency services (and wants to have a dedicated bearer for emergency services)); and when the establishment cause indicates that the connection is for an emergency call via a Packet Switched (PS) network (see Haapapuro, p. [0055]), providing radio resources in support of an Internet protocol (IP) multimedia subsystem (IMS) emergency call to the UE (see Haapapuro, Fig. 1, p. [0050], e.g., The eNB adds the previously configured radio bearer parameters to the acceptance message, and forwards it in step S106 to the requesting user equipment UE. In this message, configuration parameters of the bearers are transmitted, i.e. LCIDs for the default service/bearer, LCIDs for the emergency service/bearer, and the TFT for the emergency service/bearer).
Haapapuro discloses the specifics and details concerning connection establishment between user equipment and network are omitted herein as they are not essential for the present invention. Therefore, the user equipment has been described as a single entity without addressing its internal structure in terms of different layer functions such as for example packet data convergence protocol PDCP, mobility management MM and/or radio resource control RRC (see Haapapuro, p. [0100]).
Haapapuro does not expressly disclose a request message including a Radio Resource Control (RRC) establishment cause for setting up an RRC connection; wherein the first request is one of a message effectuating registration of the UE operating in a limited service state or a non-access stratum (NAS) request for an emergency connection with a packet data network. Watfa discloses the above recited limitations (see Watfa, p. [0034], e.g., When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", and p. [0035], e.g., The WTRU may indicate its emergency call capabilities by transmitting a random access preamble to the E-UTRAN prior to sending an actual RRC connection request message, and p. [0037], and p. [0047], e.g., If the WTRU is not registered to the network and attempts to place an emergency call, the WTRU may send a new registration message, (e.g., "emergency attach") that may be piggybacked with any of the RRC messages, (e.g., RRC connection complete, or as a standalone non-access stratum (NAS) message after RRC connection establishment. This new message may be used as an indication to speed up the registration procedure).
It would have been obvious to a person of ordinary skilled in the art before the effective filing date of the claimed invention to incorporate Watfa’s teachings into Haapapuro. The suggestion/motivation would have been to speed up the registration procedure in order to minimize the number of messages (handshake) sent back and forth between the WTRU and the network as suggested by Watfa.
Regarding claim 30, the combined teaching of Haapapuro and Watfa disclose the one or more non-transitory computer-readable media of claim 29, wherein the base station includes an evolved universal terrestrial radio access network (EUTRAN) node B (eNB) (see Haapapuro, Fig. 1, p. [0042], e.g., eNB).
Regarding claim 31, the combined teaching of Haapapuro and Watfa disclose the one or more non-transitory computer-readable media of claim 29, wherein the RRC connection is a signaling connection between the UE and the base station (see Watfa, p. [0066], e.g., the procedures are finalized by an "accept" message (attach/TAU accept) sent from the network to the WTRU).
Regarding claim 32, the combined teaching of Haapapuro and Watfa disclose the one or more non-transitory computer-readable media of claim 29, wherein the emergency call via the PS network comprises at least one of evolved packet system (EPS) emergency call (see Haapapuro, p. [0046], e.g., PS emergency services) or session, PS emergency, or IMS emergency call or session.
Regarding claim 33, the combined teaching of Haapapuro and Watfa disclose the method of claim 21, wherein the value of the type of the first request is set to evolved packet system (EPS) emergency attach (see Haapapuro, Fig. 1, S101, p. [0044], e.g., the user equipment UE, at an initial access to the network, sends an attachment/registration request message exemplarily denoted by ATTACH REQUEST to the network).
Regarding claim 34, the combined teaching of Haapapuro and Watfa disclose the base station of claim 25, wherein the value of the
Regarding claim 35, the combined teaching of Haapapuro and Watfa disclose the one or more non-transitory computer-readable media of claim 29, wherein the value of the
Regarding claim 36, Haapapuro discloses a user equipment (UE) (see Haapapuro, Fig. 1, e.g., UE), comprising: at least one hardware processor; and a non-transitory computer-readable storage medium coupled to the at least one hardware processor and storing programming instructions for execution by the at least one hardware processor, wherein the programming instructions, when executed, cause the UE station to perform operations comprising:
generating, at the UE, a first request comprising an indicator that indicates a type of the first request (see Haapapuro, Fig. 1, S101, p. [0044], e.g., the user equipment UE, at an initial access to the network, sends an attachment/registration request message to the network);
generating, at the UE, a request message including an establishment cause for setting up a connection (see Haapapuro, p.[0044], e.g., S102: attachment request (PS emergency service supported)), the establishment cause being based upon a value of the type of the first request (see Haapapuro, p.[0046-0047], e.g., the attachment request message may contain an indication whether or not the user equipment supports packet-switched (PS) emergency services (and wants to have a dedicated bearer for emergency services)); and when the establishment cause indicates that the connection is for an emergency call via a Packet Switched (PS) network (see Haapapuro, p. [0055]), receiving radio resources in support of an Internet protocol (IP) multimedia subsystem (IMS) emergency call from a base station (see Haapapuro, Fig. 1, p. [0050], e.g., The eNB adds the previously configured radio bearer parameters to the acceptance message, and forwards it in step S106 to the requesting user equipment UE. In this message, configuration parameters of the bearers are transmitted, i.e. LCIDs for the default service/bearer, LCIDs for the emergency service/bearer, and the TFT for the emergency service/bearer).
Haapapuro discloses the specifics and details concerning connection establishment between user equipment and network are omitted herein as they are not essential for the present invention. Therefore, the user equipment has been described as a single entity without addressing its internal structure in terms of different layer functions such as for example packet data convergence protocol PDCP, mobility management MM and/or radio resource control RRC (see Haapapuro, p. [0100]).
Haapapuro does not expressly disclose a request message including a Radio Resource Control (RRC) establishment cause for setting up an RRC connection; wherein the first request is one of a message effectuating registration of the UE operating in a limited service state or a non-access stratum (NAS) request for an emergency connection with a packet data network. Watfa discloses the above recited limitations (see Watfa, p. [0034], e.g., When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", and p.[0035], e.g., The WTRU may indicate its emergency call capabilities by transmitting a random access preamble to the E-UTRAN prior to sending an actual RRC connection request message, and p. [0037], and p. [0047], e.g., If the WTRU is not registered to the network and attempts to place an emergency call, the WTRU may send a new registration message, (e.g., "emergency attach") that may be piggybacked with any of the RRC messages, (e.g., RRC connection complete, or as a standalone non-access stratum (NAS) message after RRC connection establishment. This new message may be used as an indication to speed up the registration procedure).
It would have been obvious to a person of ordinary skilled in the art before the effective filing date of the claimed invention to incorporate Watfa’s teachings into Haapapuro. The suggestion/motivation would have been to speed up the registration procedure in order to minimize the number of messages (handshake) sent back and forth between the WTRU and the network as suggested by Watfa.
Regarding claim 37, the combined teaching of Haapapuro and Watfa disclose the user equipment of claim 36, wherein the user equipment is a wireless device (see Haapapuro, Fig. 1, e.g., UE).
Regarding claim 38, the combined teaching of Haapapuro and Watfa disclose the user equipment of claim 36, wherein the RRC connection is a signaling connection between the UE and the base station (see Watfa, p. [0066], e.g., the procedures are finalized by an "accept" message (attach/TAU accept) sent from the network to the WTRU).
Regarding claim 39, the combined teaching of Haapapuro and Watfa disclose the user equipment of claim 36, wherein the emergency call via the PS network comprises at least one of evolved packet system (EPS) emergency call (see Haapapuro, p. [0046], e.g., PS emergency services) or session, PS emergency, or IMS emergency call or session.
Regarding claim 40, the combined teaching of Haapapuro and Watfa disclose the user equipment of claim 36, wherein the value of the type of the first request is set to evolved packet system (EPS) emergency attach (see Haapapuro, Fig. 1, S101, p. [0044], e.g., the user equipment UE, at an initial access to the network, sends an attachment/registration request message exemplarily denoted by ATTACH REQUEST to the network).
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 MINH TRANG T NGUYEN whose telephone number is (571)270-5248. The examiner can normally be reached M-F 8:30am-6:00pm.
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, Chirag C Shah can be reached at 571-272-3144. 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.
/MINH TRANG T NGUYEN/Primary Examiner, Art Unit 2477
Prosecution Insights