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 .
Priority
Examiner acknowledges the following data:
Parent data
18896833 filed 09/25/2024 is a Continuation of PCT/CN2023/084053, filed 03/27/2023 claims foreign priority to 202210313494.3, filed 03/28/2022
Information Disclosure statements
The information disclosure statements (IDS) were submitted and filed on 09/25/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Watfa et al (US 2010/0297979) in view of Schuller et al (US 2015/0140950).
Regarding claim 1, Watfa et al discloses method (fi. 2, method) for service processing (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3), comprising:
obtaining, by a first network side device, first information, wherein the first information is used to indicate at least one of the following: a relay on which a relay terminal performs an emergency service, or a relay on which a relay terminal performs an emergency service for a first remote terminal (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3); and
Watfa et al does not specifically disclose concept of sending, by the first network side device based on the first information, second information to a second network side device, wherein the second information is used to indicate at least one of the following: a relay on which a relay terminal performs an emergency service, or a relay on which a relay terminal performs an emergency service for a first remote terminal.
However, Schuller et al specifically teaches concept of sending, by the first network side device based on the first information, second information to a second network side device, wherein the second information is used to indicate at least one of the following: a relay on which a relay terminal performs an emergency service, or a relay on which a relay terminal performs an emergency service for a first remote terminal (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4).
At the time the invention was filed, it would have been obvious for one of ordinary skill in the art to have modified system of Watfa et al with concept of sending, by the first network side device based on the first information, second information to a second network side device, wherein the second information is used to indicate at least one of the following: a relay on which a relay terminal performs an emergency service, or a relay on which a relay terminal performs an emergency service for a first remote terminal of Schuller et al. One of ordinary skill in the art would have been motivated to make this modification in order to securely accessing a data-capture device during an incident for the purpose of obtaining data-capture information (Schuller et al, [0001], lines 1-2)
Regarding claim 2, Watfa et al discloses method (fi. 2, method), wherein the first information is used to indicate a relay on which a relay terminal performs an emergency service, (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3); or
the first information is used to indicate a relay on which a relay terminal performs an emergency service, (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3); or
the first information is used to indicate a relay on which a relay terminal performs an emergency service for a first remote terminal, (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3).
Watfa et al does not specifically disclose concept of second information is used to indicate a relay on which a relay terminal performs an emergency service for a first remote terminal;
second information is used to indicate a relay on which a relay terminal performs an emergency service;
However, Schuller et al specifically teaches concept of second information is used to indicate a relay on which a relay terminal performs an emergency service for a first remote terminal (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4);
second information is used to indicate a relay on which a relay terminal performs an emergency service (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4);
At the time the invention was filed, it would have been obvious for one of ordinary skill in the art to have modified system of Watfa et al with concept of second information is used to indicate a relay on which a relay terminal performs an emergency service for a first remote terminal; second information is used to indicate a relay on which a relay terminal performs an emergency service of Schuller et al. One of ordinary skill in the art would have been motivated to make this modification in order to securely accessing a data-capture device during an incident for the purpose of obtaining data-capture information (Schuller et al, [0001], lines 1-2).
Regarding claim 3, Watfa et al discloses method (fi. 2, method), wherein:
the first information comprises at least one of the following (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3):
an identifier of the relay terminal or an identifier of the first remote terminal (IMEI is used in the network to identify the WTRU, [0012], lines 3-4); or
Watfa et al does not specifically disclose concept of second information comprises at least one of the following:
an identifier of the relay terminal or an identifier of the first remote terminal.
However, Schuller et al specifically teaches concept of second information comprises at least one of the following (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4).:
an identifier of the relay terminal or an identifier of the first remote terminal (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4).
At the time the invention was filed, it would have been obvious for one of ordinary skill in the art to have modified system of Watfa et al with concept of second information comprises at least one of the following: an identifier of the relay terminal or an identifier of the first remote terminal of Schuller et al. One of ordinary skill in the art would have been motivated to make this modification in order to securely accessing a data-capture device during an incident for the purpose of obtaining data-capture information (Schuller et al, [0001], lines 1-2)
Regarding claim 4, Watfa et al discloses method (fi. 2, method), wherein the obtaining first information comprises (The third option provides emergency bearer service only to WTRUs that have an IMSI and, optionally, WTRUs that are authenticated. If authentication fails, the WTRU is granted access and the unauthenticated IMSI retained in the network for recording purposes. The international mobile equipment identity (IMEI) is used in the network as the WTRU identifier. IMEI-only WTRUs will be rejected (e.g., UICC-less WTRUs), [0011], lines 1-4):
obtaining, by the first network side device, the first information when at least one of the following is satisfied (The third option provides emergency bearer service only to WTRUs that have an IMSI and, optionally, WTRUs that are authenticated. If authentication fails, the WTRU is granted access and the unauthenticated IMSI retained in the network for recording purposes. The international mobile equipment identity (IMEI) is used in the network as the WTRU identifier. IMEI-only WTRUs will be rejected (e.g., UICC-less WTRUs), [0011], lines 1-4):
a relay service code of a service performed by the relay terminal is associated with an emergency type (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
a service type performed by the relay terminal is an emergency type (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
the relay terminal receives a relay indication of an emergency service from a remote terminal (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
the relay terminal performs a relay indication of an emergency service (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
the relay terminal performs a relay indication of an emergency service for the first remote terminal (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
a registration type of the relay terminal is an emergency type (When a user powers up a WTRU in order to make an emergency call, the user may or may not be allowed to obtain normal services. The user may not even have a valid subscriber identity module (SIM) or universal SIM (USIM), or the WTRU may have attempted registration with the network but the registration failed due to network rejection, (e.g., PLMN not allowed, tracking area not allowed), [0029], lines 1-4);
a service request type of the relay terminal is an emergency type (WTRU may immediately notify the network of its own various capabilities for supporting emergency calls. The WTRU may start the communication with the E-UTRAN by sending a radio resource control (RRC) connection request message. Therefore, a new bitmap may be specified where the WTRU may notify the E-UTRAN what versions of emergency calls it supports. When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", [0034], lines 1-5); or
a Packet Data Unit (PDU) session request type of the relay terminal is an emergency type (WTRU may immediately notify the network of its own various capabilities for supporting emergency calls. The WTRU may start the communication with the E-UTRAN by sending a radio resource control (RRC) connection request message. Therefore, a new bitmap may be specified where the WTRU may notify the E-UTRAN what versions of emergency calls it supports. When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", [0034], lines 1-5).
Regarding claim 5, Watfa et al discloses method (fi. 2, method), wherein the obtaining first information comprises (The third option provides emergency bearer service only to WTRUs that have an IMSI and, optionally, WTRUs that are authenticated. If authentication fails, the WTRU is granted access and the unauthenticated IMSI retained in the network for recording purposes. The international mobile equipment identity (IMEI) is used in the network as the WTRU identifier. IMEI-only WTRUs will be rejected (e.g., UICC-less WTRUs), [0011], lines 1-4):
receiving, by the first network side device, the first information from a third network side device or a relay terminal (The third option provides emergency bearer service only to WTRUs that have an IMSI and, optionally, WTRUs that are authenticated. If authentication fails, the WTRU is granted access and the unauthenticated IMSI retained in the network for recording purposes. The international mobile equipment identity (IMEI) is used in the network as the WTRU identifier. IMEI-only WTRUs will be rejected (e.g., UICC-less WTRUs), [0011], lines 1-4).
Regarding claim 6, Watfa et al discloses method (fi. 2, method), wherein the first information is sent by the third network side device when at least one of the following is satisfied (The third option provides emergency bearer service only to WTRUs that have an IMSI and, optionally, WTRUs that are authenticated. If authentication fails, the WTRU is granted access and the unauthenticated IMSI retained in the network for recording purposes. The international mobile equipment identity (IMEI) is used in the network as the WTRU identifier. IMEI-only WTRUs will be rejected (e.g., UICC-less WTRUs), [0011], lines 1-4):
a relay service code of a service performed by the relay terminal is associated with an emergency type (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
a service type performed by the relay terminal is an emergency type (WTRU may immediately notify the network of its own various capabilities for supporting emergency calls. The WTRU may start the communication with the E-UTRAN by sending a radio resource control (RRC) connection request message. Therefore, a new bitmap may be specified where the WTRU may notify the E-UTRAN what versions of emergency calls it supports. When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", [0034], lines 1-5);
the relay terminal receives a relay indication of an emergency service from a remote terminal (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
the relay terminal performs a relay indication of an emergency service (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
the relay terminal performs a relay indication of an emergency service for the first remote terminal (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
data or signaling of the first remote terminal is detected;
a registration type of the relay terminal is an emergency type (When a user powers up a WTRU in order to make an emergency call, the user may or may not be allowed to obtain normal services. The user may not even have a valid subscriber identity module (SIM) or universal SIM (USIM), or the WTRU may have attempted registration with the network but the registration failed due to network rejection, (e.g., PLMN not allowed, tracking area not allowed), [0029], lines 1-4);
a service request type of the relay terminal is an emergency type (WTRU may immediately notify the network of its own various capabilities for supporting emergency calls. The WTRU may start the communication with the E-UTRAN by sending a radio resource control (RRC) connection request message. Therefore, a new bitmap may be specified where the WTRU may notify the E-UTRAN what versions of emergency calls it supports. When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", [0034], lines 1-5); or
a Packet Data Unit (PDU) session request type of the relay terminal is an emergency type (WTRU may immediately notify the network of its own various capabilities for supporting emergency calls. The WTRU may start the communication with the E-UTRAN by sending a radio resource control (RRC) connection request message. Therefore, a new bitmap may be specified where the WTRU may notify the E-UTRAN what versions of emergency calls it supports. When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", [0034], lines 1-5).
Regarding claim 7, Watfa et al discloses method (fi. 2, method),
Watfa et al does not specifically disclose concept of wherein the sending second information to a second network side device comprises:
sending, by the first network side device, the second information to the second network side device when the data or the signaling of the first remote terminal is received.
However, Schuller et al specifically teaches concept of wherein the sending second information to a second network side device comprises (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4):
sending, by the first network side device, the second information to the second network side device when the data or the signaling of the first remote terminal is received (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4).
At the time the invention was filed, it would have been obvious for one of ordinary skill in the art to have modified system of Watfa et al with concept of wherein the sending second information to a second network side device comprises: sending, by the first network side device, the second information to the second network side device when the data or the signaling of the first remote terminal is received of Schuller et al. One of ordinary skill in the art would have been motivated to make this modification in order to securely accessing a data-capture device during an incident for the purpose of obtaining data-capture information (Schuller et al, [0001], lines 1-2).
Regarding claim 8, Watfa et al discloses method (fi. 2, method) for service processing (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3), comprising:
Watfa et al does not specifically disclose concept of receiving, by a second network side device, second information, wherein the second information is used to indicate at least one of the following: a relay on which a relay terminal performs an emergency service, or a relay on which a relay terminal performs an emergency service for a first remote terminal; and
performing, by the second network side device based on the second information, the emergency service of the first remote terminal, or refusing a non-emergency service of the first remote terminal.
However, Schuller et al specifically teaches concept of receiving, by a second network side device, second information, wherein the second information is used to indicate at least one of the following: a relay on which a relay terminal performs an emergency service, or a relay on which a relay terminal performs an emergency service for a first remote terminal (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4); and
performing, by the second network side device based on the second information, the emergency service of the first remote terminal, or refusing a non-emergency service of the first remote terminal (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4).
At the time the invention was filed, it would have been obvious for one of ordinary skill in the art to have modified system of Watfa et al with concept of receiving, by a second network side device, second information, wherein the second information is used to indicate at least one of the following: a relay on which a relay terminal performs an emergency service, or a relay on which a relay terminal performs an emergency service for a first remote terminal; and performing, by the second network side device based on the second information, the emergency service of the first remote terminal, or refusing a non-emergency service of the first remote terminal of Schuller et al. One of ordinary skill in the art would have been motivated to make this modification in order to securely accessing a data-capture device during an incident for the purpose of obtaining data-capture information (Schuller et al, [0001], lines 1-2).
Regarding claim 9, Watfa et al discloses method (fi. 2, method),
Watfa et al does not specifically disclose concept of wherein the second information comprises at least one of the following:
an identifier of the relay terminal or an identifier of the first remote terminal.
However, Schuller et al specifically teaches concept of wherein the second information comprises at least one of the following (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4):
an identifier of the relay terminal or an identifier of the first remote terminal (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4).
At the time the invention was filed, it would have been obvious for one of ordinary skill in the art to have modified system of Watfa et al with concept of wherein the second information comprises at least one of the following: an identifier of the relay terminal or an identifier of the first remote terminal of Schuller et al. One of ordinary skill in the art would have been motivated to make this modification in order to securely accessing a data-capture device during an incident for the purpose of obtaining data-capture information (Schuller et al, [0001], lines 1-2).
Regarding claim 10, Watfa et al discloses method (fi. 2, method),
Watfa et al does not specifically disclose concept of wherein before the performing, by the second network side device based on the second information, the emergency service of the first remote terminal, or refusing a non-emergency service of the first remote terminal, the method further comprises:
receiving, by the second network side device, data or a request message sent by the first remote terminal.
However, Schuller et al specifically teaches concept of wherein before the performing, by the second network side device based on the second information, the emergency service of the first remote terminal, or refusing a non-emergency service of the first remote terminal, the method further comprises (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4):
receiving, by the second network side device, data or a request message sent by the first remote terminal (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4).
At the time the invention was filed, it would have been obvious for one of ordinary skill in the art to have modified system of Watfa et al with concept of wherein before the performing, by the second network side device based on the second information, the emergency service of the first remote terminal, or refusing a non-emergency service of the first remote terminal, the method further comprises: receiving, by the second network side device, data or a request message sent by the first remote terminal of Schuller et al. One of ordinary skill in the art would have been motivated to make this modification in order to securely accessing a data-capture device during an incident for the purpose of obtaining data-capture information (Schuller et al, [0001], lines 1-2)
Regarding claim 11, Watfa et al discloses method (fi. 2, method),
Watfa et al does not specifically disclose concept of wherein the performing, based on the second information, the emergency service of the first remote terminal, or refusing a non-emergency service of the first remote terminal comprises at least one of the following:
sending, by the second network side device based on the second information, the data of the first remote terminal when it is determined that a type of the data of the first remote terminal is an emergency type; or refusing to send, by the second network side device based on the second information, the data of the first remote terminal when it is determined that a type of the data of the first remote terminal is not an emergency type; or
responding, by the second network side device based on the second information, to the request message of the first remote terminal when it is determined that a type of the request message of the first remote terminal is an emergency type; or refusing, by the second network side device based on the second information, the request message of the first remote terminal when it is determined that a type of the request message of the first remote terminal is not an emergency type.
However, Schuller et al specifically teaches concept of wherein the performing, based on the second information, the emergency service of the first remote terminal, or refusing a non-emergency service of the first remote terminal comprises at least one of the following (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4):
sending, by the second network side device based on the second information, the data of the first remote terminal when it is determined that a type of the data of the first remote terminal is an emergency type; or refusing to send, by the second network side device based on the second information, the data of the first remote terminal when it is determined that a type of the data of the first remote terminal is not an emergency type (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4).; or
responding, by the second network side device based on the second information, to the request message of the first remote terminal when it is determined that a type of the request message of the first remote terminal is an emergency type; or refusing, by the second network side device based on the second information, the request message of the first remote terminal when it is determined that a type of the request message of the first remote terminal is not an emergency type (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4).
At the time the invention was filed, it would have been obvious for one of ordinary skill in the art to have modified system of Watfa et al with concept of wherein the performing, based on the second information, the emergency service of the first remote terminal, or refusing a non-emergency service of the first remote terminal comprises at least one of the following: sending, by the second network side device based on the second information, the data of the first remote terminal when it is determined that a type of the data of the first remote terminal is an emergency type; or refusing to send, by the second network side device based on the second information, the data of the first remote terminal when it is determined that a type of the data of the first remote terminal is not an emergency type; or responding, by the second network side device based on the second information, to the request message of the first remote terminal when it is determined that a type of the request message of the first remote terminal is an emergency type; or refusing, by the second network side device based on the second information, the request message of the first remote terminal when it is determined that a type of the request message of the first remote terminal is not an emergency type of Schuller et al. One of ordinary skill in the art would have been motivated to make this modification in order to securely accessing a data-capture device during an incident for the purpose of obtaining data-capture information (Schuller et al, [0001], lines 1-2).
Regarding claim 12, Watfa et al discloses method (fi. 2, method), further comprising at least one of the following (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3):
Watfa et al does not specifically disclose concept of determining, by the second network side device based on a type indication in the data of the first remote terminal, the type of the data of the first remote terminal is or is not an emergency type; or
determining, by the second network side device based on a type indication in the request message of the first remote terminal, the type of the request message of the first remote terminal is or is not an emergency type.
However, Schuller et al specifically teaches concept of determining, by the second network side device based on a type indication in the data of the first remote terminal, the type of the data of the first remote terminal is or is not an emergency type (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4); or
determining, by the second network side device based on a type indication in the request message of the first remote terminal, the type of the request message of the first remote terminal is or is not an emergency type (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4).
At the time the invention was filed, it would have been obvious for one of ordinary skill in the art to have modified system of Watfa et al with concept of determining, by the second network side device based on a type indication in the data of the first remote terminal, the type of the data of the first remote terminal is or is not an emergency type; or determining, by the second network side device based on a type indication in the request message of the first remote terminal, the type of the request message of the first remote terminal is or is not an emergency type of Schuller et al. One of ordinary skill in the art would have been motivated to make this modification in order to securely accessing a data-capture device during an incident for the purpose of obtaining data-capture information (Schuller et al, [0001], lines 1-2).
Regarding claim 13, Watfa et al discloses method (fi. 2, method) for service processing (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3), comprising:
obtaining, by a terminal, first information, wherein the first information is used to indicate at least one of the following: a relay on which a relay terminal performs an emergency service, or a relay on which a relay terminal performs an emergency service for a first remote terminal (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3); and
Watfa et al does not specifically disclose concept of sending, by the terminal, the first information.
However, Schuller et al specifically teaches concept of sending, by the terminal, the first information (At 214, the CAD sends to a PS `Authentication and Authorization Server` (PSAA): (i) the incident ID (first information); and (ii) identification details of NPSDs that the CAD has detected in the vicinity of the incident location. At 216, the PSAA server (first network side device) then sends (relay) on authentication requests to an `ID Management Server` (IDMS) (second network side device). The authentication request may comprise some or all of the incident ID (first information), information about the jurisdiction of the PS response team (second information), an identifier of the jurisdiction of the public safety wireless communication system, a geo-location of the incident, a geo-fence boundary and/or the jurisdiction in which the incident is occurring (second information), [0033], lines 1-5, [0034], lines 1-4).
At the time the invention was filed, it would have been obvious for one of ordinary skill in the art to have modified system of Watfa et al with concept of sending, by the terminal, the first information of Schuller et al. One of ordinary skill in the art would have been motivated to make this modification in order to securely accessing a data-capture device during an incident for the purpose of obtaining data-capture information (Schuller et al, [0001], lines 1-2).
Regarding claim 14, Watfa et al discloses method (fi. 2, method), wherein the first information comprises at least one of the following (The third option provides emergency bearer service only to WTRUs that have an IMSI and, optionally, WTRUs that are authenticated. If authentication fails, the WTRU is granted access and the unauthenticated IMSI retained in the network for recording purposes. The international mobile equipment identity (IMEI) is used in the network as the WTRU identifier. IMEI-only WTRUs will be rejected (e.g., UICC-less WTRUs), [0011], lines 1-4):
an identifier of the relay terminal or an identifier of the first remote terminal (The third option provides emergency bearer service only to WTRUs that have an IMSI and, optionally, WTRUs that are authenticated. If authentication fails, the WTRU is granted access and the unauthenticated IMSI retained in the network for recording purposes. The international mobile equipment identity (IMEI) is used in the network as the WTRU identifier. IMEI-only WTRUs will be rejected (e.g., UICC-less WTRUs), [0011], lines 1-4).
Regarding claim 15, Watfa et al discloses method (fi. 2, method), wherein the obtaining first information comprises (The third option provides emergency bearer service only to WTRUs that have an IMSI and, optionally, WTRUs that are authenticated. If authentication fails, the WTRU is granted access and the unauthenticated IMSI retained in the network for recording purposes. The international mobile equipment identity (IMEI) is used in the network as the WTRU identifier. IMEI-only WTRUs will be rejected (e.g., UICC-less WTRUs), [0011], lines 1-4):
obtaining, by the terminal, the first information when at least one of the following is satisfied (The third option provides emergency bearer service only to WTRUs that have an IMSI and, optionally, WTRUs that are authenticated. If authentication fails, the WTRU is granted access and the unauthenticated IMSI retained in the network for recording purposes. The international mobile equipment identity (IMEI) is used in the network as the WTRU identifier. IMEI-only WTRUs will be rejected (e.g., UICC-less WTRUs), [0011], lines 1-4):
a relay service code of a service performed by the relay terminal is associated with an emergency type (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
a service type performed by the relay terminal is an emergency type (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
the relay terminal receives a relay indication of an emergency service from a remote terminal (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
the relay terminal performs a relay indication of an emergency service (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
the relay terminal performs a relay indication of an emergency service for the first remote terminal (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
a registration type of the relay terminal is an emergency type (When a user powers up a WTRU in order to make an emergency call, the user may or may not be allowed to obtain normal services. The user may not even have a valid subscriber identity module (SIM) or universal SIM (USIM), or the WTRU may have attempted registration with the network but the registration failed due to network rejection, (e.g., PLMN not allowed, tracking area not allowed), [0029], lines 1-4);
a service request type of the relay terminal is an emergency type (WTRU may immediately notify the network of its own various capabilities for supporting emergency calls. The WTRU may start the communication with the E-UTRAN by sending a radio resource control (RRC) connection request message. Therefore, a new bitmap may be specified where the WTRU may notify the E-UTRAN what versions of emergency calls it supports. When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", [0034], lines 1-5); or
a Packet Data Unit (PDU) session request type of the relay terminal is an emergency type (WTRU may immediately notify the network of its own various capabilities for supporting emergency calls. The WTRU may start the communication with the E-UTRAN by sending a radio resource control (RRC) connection request message. Therefore, a new bitmap may be specified where the WTRU may notify the E-UTRAN what versions of emergency calls it supports. When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", [0034], lines 1-5).
Regarding claim 16, Watfa et al discloses method (fi. 2, method), wherein the terminal is the relay terminal, and the method further comprises (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3):
after a relay path of the emergency service is established, the relay terminal forwards data or a request message to the first remote terminal, wherein the data or the request message comprises a type indication, and the type indication is used to indicate whether a service type of the data or the request message is an emergency type (WTRU may immediately notify the network of its own various capabilities for supporting emergency calls. The WTRU may start the communication with the E-UTRAN by sending a radio resource control (RRC) connection request message. Therefore, a new bitmap may be specified where the WTRU may notify the E-UTRAN what versions of emergency calls it supports. When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", [0034], lines 1-5).
Regarding claim 17, Watfa et al discloses terminal (fig. 1, item 100, WTRU), comprising:
a memory storing a computer program (methods or flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable storage medium for execution by a general purpose computer or a processor. Examples of computer-readable storage mediums include a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs), [0162], lines 3-7); and
a processor coupled to the memory and configured to execute the computer program to perform the method for service processing (methods or flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable storage medium for execution by a general purpose computer or a processor. Examples of computer-readable storage mediums include a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs), [0162], lines 3-7).
Regarding claim 18, Watfa et al discloses terminal (fig. 1, item 100, WTRU), wherein the first information comprises at least one of the following (The third option provides emergency bearer service only to WTRUs that have an IMSI and, optionally, WTRUs that are authenticated. If authentication fails, the WTRU is granted access and the unauthenticated IMSI retained in the network for recording purposes. The international mobile equipment identity (IMEI) is used in the network as the WTRU identifier. IMEI-only WTRUs will be rejected (e.g., UICC-less WTRUs), [0011], lines 1-4):
an identifier of the relay terminal or an identifier of the first remote terminal (The third option provides emergency bearer service only to WTRUs that have an IMSI and, optionally, WTRUs that are authenticated. If authentication fails, the WTRU is granted access and the unauthenticated IMSI retained in the network for recording purposes. The international mobile equipment identity (IMEI) is used in the network as the WTRU identifier. IMEI-only WTRUs will be rejected (e.g., UICC-less WTRUs), [0011], lines 1-4).
Regarding claim 19, Watfa et al discloses terminal (fig. 1, item 100, WTRU), wherein the obtaining first information comprises (The third option provides emergency bearer service only to WTRUs that have an IMSI and, optionally, WTRUs that are authenticated. If authentication fails, the WTRU is granted access and the unauthenticated IMSI retained in the network for recording purposes. The international mobile equipment identity (IMEI) is used in the network as the WTRU identifier. IMEI-only WTRUs will be rejected (e.g., UICC-less WTRUs), [0011], lines 1-4):
obtaining, by the terminal, the first information when at least one of the following is satisfied (The third option provides emergency bearer service only to WTRUs that have an IMSI and, optionally, WTRUs that are authenticated. If authentication fails, the WTRU is granted access and the unauthenticated IMSI retained in the network for recording purposes. The international mobile equipment identity (IMEI) is used in the network as the WTRU identifier. IMEI-only WTRUs will be rejected (e.g., UICC-less WTRUs), [0011], lines 1-4):
a relay service code of a service performed by the relay terminal is associated with an emergency type (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
a service type performed by the relay terminal is an emergency type (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
the relay terminal receives a relay indication of an emergency service from a remote terminal (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
the relay terminal performs a relay indication of an emergency service (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
the relay terminal performs a relay indication of an emergency service for the first remote terminal (network provides emergency services support information (first information) to WTRUs (first network side device) using a new IE (relay terminal) which may be utilized to convey (relay) the various emergency call support (emergency service) levels, [0032], lines 1-3);
a registration type of the relay terminal is an emergency type (When a user powers up a WTRU in order to make an emergency call, the user may or may not be allowed to obtain normal services. The user may not even have a valid subscriber identity module (SIM) or universal SIM (USIM), or the WTRU may have attempted registration with the network but the registration failed due to network rejection, (e.g., PLMN not allowed, tracking area not allowed), [0029], lines 1-4);
a service request type of the relay terminal is an emergency type (WTRU may immediately notify the network of its own various capabilities for supporting emergency calls. The WTRU may start the communication with the E-UTRAN by sending a radio resource control (RRC) connection request message. Therefore, a new bitmap may be specified where the WTRU may notify the E-UTRAN what versions of emergency calls it supports. When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", [0034], lines 1-5); or
a Packet Data Unit (PDU) session request type of the relay terminal is an emergency type (WTRU may immediately notify the network of its own various capabilities for supporting emergency calls. The WTRU may start the communication with the E-UTRAN by sending a radio resource control (RRC) connection request message. Therefore, a new bitmap may be specified where the WTRU may notify the E-UTRAN what versions of emergency calls it supports. When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", [0034], lines 1-5).
Regarding claim 20, Watfa et al discloses terminal (fig. 1, item 100, WTRU), wherein the terminal is the relay terminal, and performing the method for service processing further comprises:
after a relay path of the emergency service is established, the relay terminal forwards data or a request message to the first remote terminal, wherein the data or the request message comprises a type indication, and the type indication is used to indicate whether a service type of the data or the request message is an emergency type (WTRU may immediately notify the network of its own various capabilities for supporting emergency calls. The WTRU may start the communication with the E-UTRAN by sending a radio resource control (RRC) connection request message. Therefore, a new bitmap may be specified where the WTRU may notify the E-UTRAN what versions of emergency calls it supports. When the WTRU sends this message, it is mandatory to indicate that the "establishment cause", for the connection request, is an "emergency call", [0034], lines 1-5).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANTZ BATAILLE whose telephone number is (571)270-7286. The examiner can normally be reached Monday-Friday 9:00 AM-5:00 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, Akwasi Sarpong can be reached on 571-270-3438. 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.
/FRANTZ BATAILLE/ Primary Examiner, Art Unit 2681
Prosecution Insights