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 .
Response to Arguments
Applicant’s arguments with respect to claims 1-36 have been considered but are moot in view of the new ground(s) of rejection set forth.
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.
2. Claims 1-2, 9-10, 17-18, and 25-26 are rejected under 35 U.S.C. 103 as being unpatentable over Cavalcanti et al. US (2018/0295655), in view of Xu et al. US (2018/0192268), further in view of Kotecha et al. US (2013/0215813), further in view of Haynes et al. US (2012/0282915), and further in view of Atarius et al. US (2010/0197305).
Regarding Claim 1, Cavalcanti discloses a method comprising: sending, by a wireless device (see Fig. 3 i.e., V2X UE 202) to a network entity (see Fig. 3 i.e., V2X Pro Se Function 204, Fig. 5 i.e., MME & Para [0118] i.e., wherein the ProSe function resides in a core network (CN) element (i.e., “MME”) that is communicatively coupled via a third interface with a serving gateway (SGW) or a PDN gateway (PGW)), a first message (see Fig. 3 i.e., registration request 206) comprising an indicator of a vehicle-to-everything (V2X) bearer for the wireless device, (see Fig. 3 & Para’s [0004] i.e., V2X communications, [0007] i.e., V2X communications are provided in part by a dedicated short range communications (DSRC) channel, which may be carried by a local and metropolitan area network such as defined in IEEE 802.11p standard and by a cellular network (e.g., LTE, 5G) (i.e., “V2X bearer”) [0023] i.e., WBSS services registration procedure to register UEs for V2X communications, [0033] i.e., communication of V2X services over DSRC/802.11p networks (i.e., “bearer”) & [0034-0043] i.e., a V2X UE that provides services over a WBSS in DSRC/802.11p channels (i.e., “V2X bearer”) sends 206 a registration request to a V2X ProSe function carrying WBSS information (i.e., WBSS information includes one or more indicators). The WBSS information may include BSSID as defined in 802.11p, operating channel: DSRC channel number, which may be a control channel (CCH) or service channel (SCH) (i.e., BSSID and DSRC channel number may be indicators of “V2X bearer”), Security Information, List of service identifiers (i.e., “indicators”): one or more service ids, such as the PSID, [0092] i.e., wherein the WBSS registration request message comprises any combination of the following parameters: SSID, operating channel, security information, and service identifiers or a list of PSIDs & [0101])
receiving, by the wireless device (see Fig. 3 i.e., V2X UE 202) from the network entity (see Fig. 3 i.e., V2X Pro Se Function 204 & Para [0118]), a second message (see Fig. 3 i.e., registration response 210) comprising: one or more indicators of V2X service capabilities, (see Fig. 3 & Para’s [0034-0043] i.e., If the ProSe function decides to authorize the UE, then the V2X ProSe function sends 210 a registration response identifying the WBSS information to be used by the UE to communicate on the network (i.e., the registration response includes the same WBSS information included in the registration request and therefore includes V2X service capabilities such as the list of service identifiers disclosed in Para [0040] which is based on the V2X bearer coverage). The V2X ProSe function may use the same WBSS information in the received request 206. Alternatively, the V2X ProSe function may use the WBSS information in the registration response to change any one or more of the WBSS configuration parameters, such as security keys and the operating channel, [0063], & [0109] i.e., wherein the registration response includes WBSS information to be used by the UE for the WBSS services)
and one or more configuration parameters associated with reception by the wireless device via the V2X bearer; (see Para’s [0022] i.e., transmission and reception of BSMs for V2X, [0034-0042] i.e., UE is ready to receive and transmit announcements such as BSM and other WAVE services…This response provides authorization and information for the UE to receive (i.e., “reception”) and transmit announcements and other WAVE services from RSUs and other members of the WLAN group, [0043] i.e., the V2X ProSe function sends 210 a registration response identifying the WBSS information to be used by the UE to communicate on the network. The V2X ProSe function may use the same WBSS information in the received request 206 (i.e., the registration response includes the same WBSS information included in the registration request and therefore includes configuration parameters such as the DSCRC operating channel (i.e., “V2X bearer”) used for V2X communication), [0060] i.e., communication session over DSRC channel (i.e., “V2X bearer”) includes transmission/reception of data by the UE, [0064], [0095] i.e., wherein the V2X ProSe function sends a WBSS registration response to the V2X UE including WBSS operation parameters that the UE is allowed to use, which include SSID, operating channel (i.e., configuration parameters”), [0110] i.e., registration response includes an operating channel for the direct communications session (i.e., communication session includes reception by the UE via V2X bearer), [0196] i.e., sending a registration response from the ProSe function confirming WBSS information to be used for the services after deciding to authorize the UE, & [0203-0204] i.e., registration response comprises WBSS information)
and receiving, via the V2X bearer, at least one packet, (see Para’s [0004-0005] i.e., BSM messages (i.e., “packets”), [0022] i.e., transmission and reception of BSMs (i.e., “packets”) for V2X, [0034-0042] i.e., Such a registration request identifies the UE to the ProSe function and indicates that the UE is ready to receive and transmit announcements such as BSM and WAVE services, [0031], [0060] i.e., the ProSe logic may provide a direct communication session over a DSRC channel (i.e., “V2X bearer”) when the ProSe function indicates that the UE is authorized to provide the direct communication session, [0064] i.e., WBSS communication services where the UE may communicate with one or more other V2X enables UEs…the UE may provide a direct communication session (i.e., communication session includes communication of packets) over the DSRC channel (i.e., “V2X bearer”) when the registration response indicates that the UE is authorized to provide a direct communications session over the DSRC channel, [0119], & [0210]).
Cavalcanti does not disclose the V2X communications of the wireless device is performed using a V2X multicast bearer between the wireless device and the network entity and receiving, from the network entity via the V2X multicast bearer, at least one packet. However the claim features would be rendered obvious in view of Xu et al. US (2018/0192268).
XU discloses wherein a V2X UE (see Fig. 9 i.e., UE as OBU) performs V2X communications using V2X multicast bearer between the wireless device (see Fig. 9 i.e., UE as OBU) and a network entity (see Fig. 9 i.e., V2X AS, BM-SC, & MBMS- GW may be core network entities for sending V2X data to the UE & Para’s [0017] i.e., core network Evolved packet core (EPC)…interface between the V2X AS and a BM-SC in the EPC to send the V2X service, [0077], [0124] i.e., the OBU requests V2X AS to make a registration, or the OBU requests the V2X AS to obtain the V2X service, [0132] i.e., the V2X AS sends the V2X data to the OBU via the core network, [0133] i.e., The V2X AS may send data to the OBU through the broadcast mode or the unicast mode, and the V2X AS judges whether to send data through the unicast carriers or the broadcast carriers according to network deployment…If a MBMS broadcast carrier (i.e., “V2X multicast bearer coverage”) is deployed on the network…the V2X AS can send data through the broadcast carrier (i.e., “V2X multicast bearer coverage”) & [0159] i.e., where, the V2X AS sends to the OBU via the BM-SC->MBMS-GW->eNB…The data is sent via the MBMS broadcast carrier (i.e., “V2X multicast bearer”)).
Xu discloses receiving, from the network entity (see Fig. 9), via the V2X multicast bearer, at least one packet (see Fig. 9 & Para’s [0017] i.e., core network Evolved packet core (EPC)…interface between the V2X AS and a BM-SC in the EPC to send the V2X service, [0077], [0124] i.e., the OBU requests V2X As to make a registration, or the OBU requests the V2X AS to obtain the V2X service, [0132] i.e., the V2X AS sends the V2X data to the OBU via the core network, [0133] i.e., The V2X AS may send data to the OBU through the broadcast mode or the unicast mode, and the V2X AS judges whether to send data through the unicast carriers or the broadcast carriers according to network deployment…If a MBMS broadcast carrier (i.e., “V2X multicast bearer”) is deployed on the network…the V2X AS can send data through the broadcast carrier (i.e., “V2X multicast bearer”) & [0159] i.e., where, the V2X As sends to the OBU via the BM-SC->MBMS-GW->eNB…The data is sent via the MBMS broadcast carrier (i.e., “V2X multicast bearer”)).
(Xu suggests the OBU (i.e., UE) requests the V2X AS to make a registration in order to properly obtain the V2X service via the V2X multicast bearer, (see Para [0124])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the V2X communications performed by the UE over the V2X bearer as disclosed in Cavalcanti to include V2X communications supporting V2X multicast communications using a V2X multicast bearer between the wireless device and the network entity as disclosed in the teachings of Xu who discloses receiving from the network entity, via the V2X multicast bearer, at least one packet, because the motivation lies in Xu that the OBU (i.e., UE) requests the V2X AS to make a registration in order to properly obtain the V2X service via the V2X multicast bearer.
While the combination of Cavalcanti in view of Xu discloses sending by the wireless device to the network entity, a first message comprising information for updating the V2X multicast bearer (Cavalcanti, see Para’s [0035-0041] i.e., registration request (i.e., “first message”) [0043] i.e., The WBSS service registration procedure may be executed…The same or a similar procedure may also be used by the UEs to update their WBSS configuration & Xu, see Fig, 9 & Para’s [0133] & [0159] i.e., V2X MBMS broadcast carrier), the combination of Cavalcanti in view of Xu does not disclose the first message comprising an indicator of a packet loss associated with the multicast bearer between the wireless device and the network entity. However the claim feature would be rendered obvious in view of Kotecha et al. US (2013/0215813).
Kotecha discloses sending, by a first wireless device (see Fig. 2A i.e., UE 102-1) to a network entity (see Fig. 1 i.e., EPC 106 & Fig. 2A i.e., feedback monitoring module 206 which may be included in a network element in network 100 of Fig. 1 including a core network element & Para [0031] i.e., Feedback monitoring module 206 may be located in a network element in network 100), a first message (see Fig. 2 i.e., status report message 212) comprising an indicator of a packet loss associated with a multicast bearer (see Para’s [0018] i.e., MME 120 is also involved in bearer activation, [0021], [0025] i.e., MBMS bearer, & [0036]) between the wireless device and the core network entity, (see Figures 1-2B, & Para’s [0024-0026] i.e., multicast services (i.e., MBMS), [0030] i.e., UE 102 may receive the broadcast/multicast and periodically provide a status report 212…the status report 212 may include metrics that identify quality of service characteristic for the broadcast/multicast at each base station (e.g., eNB 114), such as…packet loss percentage (i.e., “indicator of a packet loss”) & [0032] i.e., For example, quality of service values 252 may include multiple values for different indicators of radio conditions, such as packet loss and other values that are provided by UE 102 in the status report)
(Kotecha suggests the first message comprising the indicator of the packet loss associated with the multicast bearer is used for updating the multicast bearer configuration such as adjusted MCS values and FEC values that may optimize error correction, provide optimized performance of the multicast services for the UE, and provide a target quality of service based on the radio conditions such as the packet loss, (see Para’s [0010], [0031-0032], & [0035])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the first message comprising an indicator of a packet loss associated with the multicast bearer for updating the multicast bearer configuration as disclosed in Kotecha to be performed for the V2X multicast bearer and included as further information in the first message disclosed in Cavalcanti in view of Xu who discloses sending by the wireless device to the core network entity, a first message comprising information for updating the V2X multicast bearer, because the motivation lies in Kotecha that the first message comprising the indicator of the packet loss associated with the multicast bearer is used for updating the multicast bearer configuration such as adjusted MCS values and FEC values that may optimize error correction, provide optimized performance of the multicast services for the UE, and provide a target quality of service based on the radio conditions such as the packet loss.
While Cavalcanti discloses sending by the wireless device, the first message to the network entity may which may be the MME (see Fig. 3 i.e., V2X Pro Se Function 204, Fig. 5 i.e., MME & Para [0118] i.e., wherein the ProSe function resides in a core network (CN) element that is communicatively coupled via a third interface with a serving gateway (SGW) or a PDN gateway (PGW) suggests the core network element may be the MME & Xu, see Fig. 9 i.e., MME), the combination of Cavalcanti in view of Xu, and further in view of Kotecha does not disclose the network entity is an internet protocol multimedia subsystem (IMS) network entity. However the claim feature would be rendered obvious in view of Haynes et al. US (2012/0282915).
Haynes discloses a network entity such as MME and CSCF server 260 (i.e., “IMS network entity”) may be integrated into a single device (i.e., “IMS network entity”), (see Para [0026] i.e., Further MME 240, HSS server 250, and/or CSCF server 260 may be integrated into a single device).
(Haynes suggests the CSCF server 260 is used to authenticate user device 110 in order to successfully establish the connection 150 and the IMS core may be used to manage authentication and session initiation associated with the user device 110 (see Para’s [0028] & [0057])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the network entity such as the MME as disclosed in Cavalcanti in view of Xu, and further in view of Kotecha to be integrated into the single device (i.e., “IMS network entity”) including the CSCF server 260 and MME 240 as disclosed in the teachings of Haynes, which results in sending the first message and receiving the second message, by the wireless device to/from an IMS network entity, because the motivation lies in Haynes that the CSCF server 260 is used to authenticate user device 110 in order to successfully establish the connection 150 and the IMS core may be used to manage authentication and session initiation associated with the user device 110.
While Cavalcanti discloses receiving the second message such as the registration response, (Cavalcanti, see Fig. 3, 210 & Para’s [0043] & [0095]), the combination of Cavalcanti in view of Xu, further in view of Kotecha, and further in view of Haynes does not disclose the claim feature of sending, by the wireless device to the IMS network entity, a third message confirming the second message. However the claim feature would be rendered obvious in view of Atarius et al. US (2010/0197305).
Atarius discloses sending, by a wireless device (see Fig. 4 i.e., UE 104) to an IMS network entity (see Fig. 4 i.e., P-CSCF 240), a third message (see Fig. 4 i.e., ACK message at step 400) confirming a second message (see Fig. 4 i.e., “200 OK” at step 494) such as a registration response (see Para’s [0057] i.e., The “200 OK” response may indicate to the UE 104 that the registration is accepted or is successful (i.e., “registration response”)…The P-CSCF 240 then forwards the “200 OK” response to the UE 104 as illustrated by message flow path 194 & [0058] i.e., The UE 104 acknowledges the registration to the S-CSCF 244 by transmitting the “Acknowledgement” response to the P-CSCF 240 (i.e., “IMS network entity”) as illustrated by message flow path 400).
(Atarius suggests the acknowledgement response is sent to the P-CSCF for acknowledging the registration to the IMS network entity in order to successfully establish a signaling connection 496 with the P-CSCF for performing a communication session in order to access services and/or applications, (see Para [0058]))
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the wireless device disclosed in Cavalcanti in view of Xu, further in view of Kotecha, and further in view of Haynes to send to the IMS network entity, a third message confirming the second message such as the registration response based on using the acknowledgement message sent from the UE to the IMS network entity as disclosed in the teachings of Atarius who discloses sending, by a UE, to an IMS network entity, an acknowledgement confirming a registration response received from the IMS network entity, because the motivation lies in Atarius that the acknowledgement response is sent to the P-CSCF for acknowledging the registration to the IMS network entity in order to successfully establish a signaling connection 496 with the P-CSCF for performing a communication session in order to access services and/or applications.
Regarding Claim 2, the combination of Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses the method of claim 1, wherein the second message further comprises one or more configuration parameters associated with reception via a V2X broadcast bearer, (Cavalcanti, see Para’s [0006] i.e., broadcast messages communicated to vehicles, [0007] i.e., V2X devices to discover and take advantage of safety and non-safety services, which may be broadcasted over one or more DSCRC channels (i.e., “V2X broadcast bearer”), [0031] i.e., RSU may periodically broadcast safety messages, such as BSMs using a specific BSSID in one of the DSRC/802.11p service channels, [0035-0043] i.e., the V2X ProSe function sends 210 a registration response identifying the WBSS information to be used by the UE to communicate on the network. The V2X ProSe function may use the same WBSS information (i.e., includes configuration parameters such as DSRC channel which may be a V2X broadcast bearer) in the received request 206)
Regarding Claim 9, Cavalcanti discloses a non-transitory computer-readable medium storing instructions (see Para [0138] i.e., non-transitory computer-readable media comprising instructions) that, when executed (see Para [0138]), cause: sending to a network entity (see Fig. 3 i.e., V2X Pro Se Function 204, Fig. 5 i.e., MME & Para [0118] i.e., wherein the ProSe function resides in a core network (CN) element (i.e., “MME”) that is communicatively coupled via a third interface with a serving gateway (SGW) or a PDN gateway (PGW)), a first message (see Fig. 3 i.e., registration request 206) comprising an indicator of a vehicle-to-everything (V2X) bearer for a wireless device, (see Fig. 3 & Para’s [0004] i.e., V2X communications, [0007] i.e., V2X communications are provided in part by a dedicated short range communications (DSRC) channel, which may be carried by a local and metropolitan area network such as defined in IEEE 802.11p standard and by a cellular network (e.g., LTE, 5G) (i.e., “V2X bearer”) [0023] i.e., WBSS services registration procedure to register UEs for V2X communications, [0033] i.e., communication of V2X services over DSRC/802.11p networks (i.e., “bearer”) & [0034-0043] i.e., a V2X UE that provides services over a WBSS in DSRC/802.11p channels (i.e., “V2X bearer”) sends 206 a registration request to a V2X ProSe function carrying WBSS information (i.e., WBSS information includes one or more indicators). The WBSS information may include BSSID as defined in 802.11p, operating channel: DSRC channel number, which may be a control channel (CCH) or service channel (SCH) (i.e., BSSID and DSRC channel number may be indicators of “V2X bearer”), Security Information, List of service identifiers (i.e., “indicators”): one or more service ids, such as the PSID, [0092] i.e., wherein the WBSS registration request message comprises any combination of the following parameters: SSID, operating channel, security information, and service identifiers or a list of PSIDs & [0101])
Receiving from the network entity (see Fig. 3 i.e., V2X Pro Se Function 204 & Para [0118]), a second message (see Fig. 3 i.e., registration response 210) comprising: one or more indicators of V2X service capabilities, (see Fig. 3 & Para’s [0034-0043] i.e., If the ProSe function decides to authorize the UE, then the V2X ProSe function sends 210 a registration response identifying the WBSS information to be used by the UE to communicate on the network (i.e., the registration response includes the same WBSS information included in the registration request and therefore includes V2X service capabilities such as the list of service identifiers disclosed in Para [0040] which is based on the V2X bearer coverage). The V2X ProSe function may use the same WBSS information in the received request 206. Alternatively, the V2X ProSe function may use the WBSS information in the registration response to change any one or more of the WBSS configuration parameters, such as security keys and the operating channel, [0063], & [0109] i.e., wherein the registration response includes WBSS information to be used by the UE for the WBSS services)
and one or more configuration parameters associated with reception by a wireless device via the V2X bearer; (see Para’s [0022] i.e., transmission and reception of BSMs for V2X, [0034-0042] i.e., UE is ready to receive and transmit announcements such as BSM and other WAVE services…This response provides authorization and information for the UE to receive (i.e., “reception”) and transmit announcements and other WAVE services from RSUs and other members of the WLAN group, [0043] i.e., the V2X ProSe function sends 210 a registration response identifying the WBSS information to be used by the UE to communicate on the network. The V2X ProSe function may use the same WBSS information in the received request 206 (i.e., the registration response includes the same WBSS information included in the registration request and therefore includes configuration parameters such as the DSCRC operating channel (i.e., “V2X bearer”) used for V2X communication), [0060] i.e., communication session over DSRC channel (i.e., “V2X bearer”) includes transmission/reception of data by the UE, [0064], [0095] i.e., wherein the V2X ProSe function sends a WBSS registration response to the V2X UE including WBSS operation parameters that the UE is allowed to use, which include SSID, operating channel (i.e., configuration parameters”), [0110] i.e., registration response includes an operating channel for the direct communications session (i.e., communication session includes reception by the UE via V2X bearer), [0196] i.e., sending a registration response from the ProSe function confirming WBSS information to be used for the services after deciding to authorize the UE, & [0203-0204] i.e., registration response comprises WBSS information)
and receiving, via the V2X bearer, at least one packet, (see Para’s [0004-0005] i.e., BSM messages (i.e., “packets”), [0022] i.e., transmission and reception of BSMs (i.e., “packets”) for V2X, [0034-0042] i.e., Such a registration request identifies the UE to the ProSe function and indicates that the UE is ready to receive and transmit announcements such as BSM and WAVE services, [0031], [0060] i.e., the ProSe logic may provide a direct communication session over a DSRC channel (i.e., “V2X bearer”) when the ProSe function indicates that the UE is authorized to provide the direct communication session, [0064] i.e., WBSS communication services where the UE may communicate with one or more other V2X enables UEs…the UE may provide a direct communication session (i.e., communication session includes communication of packets) over the DSRC channel (i.e., “V2X bearer”) when the registration response indicates that the UE is authorized to provide a direct communications session over the DSRC channel, [0119], & [0210]).
Cavalcanti does not disclose the V2X communications of the wireless device is performed using a V2X multicast bearer between the wireless device and the network entity and receiving, from the network entity via the V2X multicast bearer, at least one packet. However the claim features would be rendered obvious in view of Xu et al. US (2018/0192268).
XU discloses wherein a V2X UE (see Fig. 9 i.e., UE as OBU) performs V2X communications using V2X multicast bearer between the wireless device (see Fig. 9 i.e., UE as OBU) and a network entity (see Fig. 9 i.e., V2X AS, BM-SC, & MBMS- GW may be core network entities for sending V2X data to the UE & Para’s [0017] i.e., core network Evolved packet core (EPC)…interface between the V2X AS and a BM-SC in the EPC to send the V2X service, [0077], [0124] i.e., the OBU requests V2X AS to make a registration, or the OBU requests the V2X AS to obtain the V2X service, [0132] i.e., the V2X AS sends the V2X data to the OBU via the core network, [0133] i.e., The V2X AS may send data to the OBU through the broadcast mode or the unicast mode, and the V2X AS judges whether to send data through the unicast carriers or the broadcast carriers according to network deployment…If a MBMS broadcast carrier (i.e., “V2X multicast bearer coverage”) is deployed on the network…the V2X AS can send data through the broadcast carrier (i.e., “V2X multicast bearer coverage”) & [0159] i.e., where, the V2X AS sends to the OBU via the BM-SC->MBMS-GW->eNB…The data is sent via the MBMS broadcast carrier (i.e., “V2X multicast bearer”)).
Xu discloses receiving, from the network entity (see Fig. 9), via the V2X multicast bearer, at least one packet (see Fig. 9 & Para’s [0017] i.e., core network Evolved packet core (EPC)…interface between the V2X AS and a BM-SC in the EPC to send the V2X service, [0077], [0124] i.e., the OBU requests V2X As to make a registration, or the OBU requests the V2X AS to obtain the V2X service, [0132] i.e., the V2X AS sends the V2X data to the OBU via the core network, [0133] i.e., The V2X AS may send data to the OBU through the broadcast mode or the unicast mode, and the V2X AS judges whether to send data through the unicast carriers or the broadcast carriers according to network deployment…If a MBMS broadcast carrier (i.e., “V2X multicast bearer”) is deployed on the network…the V2X AS can send data through the broadcast carrier (i.e., “V2X multicast bearer”) & [0159] i.e., where, the V2X As sends to the OBU via the BM-SC->MBMS-GW->eNB…The data is sent via the MBMS broadcast carrier (i.e., “V2X multicast bearer”)).
(Xu suggests the OBU (i.e., UE) requests the V2X AS to make a registration in order to properly obtain the V2X service via the V2X multicast bearer, (see Para [0124])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the V2X communications performed by the UE over the V2X bearer as disclosed in Cavalcanti to include V2X communications supporting V2X multicast communications using a V2X multicast bearer between the wireless device and the network entity as disclosed in the teachings of Xu who discloses receiving from the network entity, via the V2X multicast bearer, at least one packet, because the motivation lies in Xu that the OBU (i.e., UE) requests the V2X AS to make a registration in order to properly obtain the V2X service via the V2X multicast bearer.
While the combination of Cavalcanti in view of Xu discloses sending by the wireless device to the network entity, a first message comprising information for updating the V2X multicast bearer (Cavalcanti, see Para’s [0035-0041] i.e., registration request (i.e., “first message”) [0043] i.e., The WBSS service registration procedure may be executed…The same or a similar procedure may also be used by the UEs to update their WBSS configuration & Xu, see Fig, 9 & Para’s [0133] & [0159] i.e., V2X MBMS broadcast carrier), the combination of Cavalcanti in view of Xu does not disclose the first message comprising an indicator of a packet loss associated with the multicast bearer between the wireless device and the network entity. However the claim feature would be rendered obvious in view of Kotecha et al. US (2013/0215813).
Kotecha discloses sending, by a first wireless device (see Fig. 2A i.e., UE 102-1) to a network entity (see Fig. 1 i.e., EPC 106 & Fig. 2A i.e., feedback monitoring module 206 which may be included in a network element in network 100 of Fig. 1 including a core network element & Para [0031] i.e., Feedback monitoring module 206 may be located in a network element in network 100), a first message (see Fig. 2 i.e., status report message 212) comprising an indicator of a packet loss associated with a multicast bearer (see Para’s [0018] i.e., MME 120 is also involved in bearer activation, [0021], [0025] i.e., MBMS bearer, & [0036]) between the wireless device and the core network entity, (see Figures 1-2B, & Para’s [0024-0026] i.e., multicast services (i.e., MBMS), [0030] i.e., UE 102 may receive the broadcast/multicast and periodically provide a status report 212…the status report 212 may include metrics that identify quality of service characteristic for the broadcast/multicast at each base station (e.g., eNB 114), such as…packet loss percentage (i.e., “indicator of a packet loss”) & [0032] i.e., For example, quality of service values 252 may include multiple values for different indicators of radio conditions, such as packet loss and other values that are provided by UE 102 in the status report)
(Kotecha suggests the first message comprising the indicator of the packet loss associated with the multicast bearer is used for updating the multicast bearer configuration such as adjusted MCS values and FEC values that may optimize error correction, provide optimized performance of the multicast services for the UE, and provide a target quality of service based on the radio conditions such as the packet loss, (see Para’s [0010], [0031-0032], & [0035])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the first message comprising an indicator of a packet loss associated with the multicast bearer for updating the multicast bearer configuration as disclosed in Kotecha to be performed for the V2X multicast bearer and included as further information in the first message disclosed in Cavalcanti in view of Xu who discloses sending by the wireless device to the core network entity, a first message comprising information for updating the V2X multicast bearer, because the motivation lies in Kotecha that the first message comprising the indicator of the packet loss associated with the multicast bearer is used for updating the multicast bearer configuration such as adjusted MCS values and FEC values that may optimize error correction, provide optimized performance of the multicast services for the UE, and provide a target quality of service based on the radio conditions such as the packet loss.
While Cavalcanti discloses sending by the wireless device, the first message to the network entity may which may be the MME (see Fig. 3 i.e., V2X Pro Se Function 204, Fig. 5 i.e., MME & Para [0118] i.e., wherein the ProSe function resides in a core network (CN) element that is communicatively coupled via a third interface with a serving gateway (SGW) or a PDN gateway (PGW) suggests the core network element may be the MME & Xu, see Fig. 9 i.e., MME), the combination of Cavalcanti in view of Xu, and further in view of Kotecha does not disclose the network entity is an internet protocol multimedia subsystem (IMS) network entity. However the claim feature would be rendered obvious in view of Haynes et al. US (2012/0282915).
Haynes discloses a network entity such as MME and CSCF server 260 (i.e., “IMS network entity”) may be integrated into a single device (i.e., “IMS network entity”), (see Para [0026] i.e., Further MME 240, HSS server 250, and/or CSCF server 260 may be integrated into a single device).
(Haynes suggests the CSCF server 260 is used to authenticate user device 110 in order to successfully establish the connection 150 and the IMS core may be used to manage authentication and session initiation associated with the user device 110 (see Para’s [0028] & [0057])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the network entity such as the MME as disclosed in Cavalcanti in view of Xu, and further in view of Kotecha to be integrated into the single device (i.e., “IMS network entity”) including the CSCF server 260 and MME 240 as disclosed in the teachings of Haynes, which results in sending the first message and receiving the second message, by the wireless device to/from an IMS network entity, because the motivation lies in Haynes that the CSCF server 260 is used to authenticate user device 110 in order to successfully establish the connection 150 and the IMS core may be used to manage authentication and session initiation associated with the user device 110.
While Cavalcanti discloses receiving the second message such as the registration response, (Cavalcanti, see Fig. 3, 210 & Para’s [0043] & [0095]), the combination of Cavalcanti in view of Xu, further in view of Kotecha, and further in view of Haynes does not disclose the claim feature of sending, by the wireless device to the IMS network entity, a third message confirming the second message. However the claim feature would be rendered obvious in view of Atarius et al. US (2010/0197305).
Atarius discloses sending, by a wireless device (see Fig. 4 i.e., UE 104) to an IMS network entity (see Fig. 4 i.e., P-CSCF 240), a third message (see Fig. 4 i.e., ACK message at step 400) confirming a second message (see Fig. 4 i.e., “200 OK” at step 494) such as a registration response (see Para’s [0057] i.e., The “200 OK” response may indicate to the UE 104 that the registration is accepted or is successful (i.e., “registration response”)…The P-CSCF 240 then forwards the “200 OK” response to the UE 104 as illustrated by message flow path 194 & [0058] i.e., The UE 104 acknowledges the registration to the S-CSCF 244 by transmitting the “Acknowledgement” response to the P-CSCF 240 (i.e., “IMS network entity”) as illustrated by message flow path 400).
(Atarius suggests the acknowledgement response is sent to the P-CSCF for acknowledging the registration to the IMS network entity in order to successfully establish a signaling connection 496 with the P-CSCF for performing a communication session in order to access services and/or applications, (see Para [0058]))
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the wireless device disclosed in Cavalcanti in view of Xu, further in view of Kotecha, and further in view of Haynes to send to the IMS network entity, a third message confirming the second message such as the registration response based on using the acknowledgement message sent from the UE to the IMS network entity as disclosed in the teachings of Atarius who discloses sending, by a UE, to an IMS network entity, an acknowledgement confirming a registration response received from the IMS network entity, because the motivation lies in Atarius that the acknowledgement response is sent to the P-CSCF for acknowledging the registration to the IMS network entity in order to successfully establish a signaling connection 496 with the P-CSCF for performing a communication session in order to access services and/or applications.
Regarding Claim 10, the combination of the combination of Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses the non-transitory computer-readable medium of claim 9, wherein the second message further comprises one or more configuration parameters associated with reception via a V2X broadcast bearer, (Cavalcanti, see Para’s [0006] i.e., broadcast messages communicated to vehicles, [0007] i.e., V2X devices to discover and take advantage of safety and non-safety services, which may be broadcasted over one or more DSCRC channels (i.e., “V2X broadcast bearer”), [0031] i.e., RSU may periodically broadcast safety messages, such as BSMs using a specific BSSID in one of the DSRC/802.11p service channels, [0035-0043] i.e., the V2X ProSe function sends 210 a registration response identifying the WBSS information to be used by the UE to communicate on the network. The V2X ProSe function may use the same WBSS information (i.e., includes configuration parameters such as DSRC channel which may be a V2X broadcast bearer) in the received request 206)
Regarding Claim 17, Cavalcanti discloses a system (see Para’s [0026] i.e., system, [0031], & [0072] i.e., embodiments may be implemented into a system) comprising: a wireless device (see Fig.3 i.e., V2X UE); and a network entity (see Fig. 3 i.e., V2X Pro Se Function & Fig. 5 i.e., MME & Para [0118]), wherein the wireless device (see Fig.3 i.e., V2X UE) is configured to: send, to the network entity (see Fig. 3 i.e., V2X Pro Se Function 204, Fig. 5 i.e., MME & Para [0118] i.e., wherein the ProSe function resides in a core network (CN) element (i.e., “MME”) that is communicatively coupled via a third interface with a serving gateway (SGW) or a PDN gateway (PGW)), a first message (see Fig. 3 i.e., registration request 206) comprising an indicator of a vehicle-to-everything (V2X) bearer for the wireless device, (see Fig. 3 & Para’s [0004] i.e., V2X communications, [0007] i.e., V2X communications are provided in part by a dedicated short range communications (DSRC) channel, which may be carried by a local and metropolitan area network such as defined in IEEE 802.11p standard and by a cellular network (e.g., LTE, 5G) (i.e., “V2X bearer”) [0023] i.e., WBSS services registration procedure to register UEs for V2X communications, [0033] i.e., communication of V2X services over DSRC/802.11p networks (i.e., “bearer”) & [0034-0043] i.e., a V2X UE that provides services over a WBSS in DSRC/802.11p channels (i.e., “V2X bearer”) sends 206 a registration request to a V2X ProSe function carrying WBSS information (i.e., WBSS information includes one or more indicators). The WBSS information may include BSSID as defined in 802.11p, operating channel: DSRC channel number, which may be a control channel (CCH) or service channel (SCH) (i.e., BSSID and DSRC channel number may be indicators of “V2X bearer”), Security Information, List of service identifiers (i.e., “indicators”): one or more service ids, such as the PSID, [0092] i.e., wherein the WBSS registration request message comprises any combination of the following parameters: SSID, operating channel, security information, and service identifiers or a list of PSIDs & [0101])
Wherein the network entity (see Fig. 3 i.e., V2X Pro Se Function 204 & Para [0118]) is configured to: send, to the wireless device (see Fig. 3 i.e., V2X UE 202), a second message (see Fig. 3 i.e., registration response 210) comprising: one or more indicators of V2X service capabilities, (see Fig. 3 & Para’s [0034-0043] i.e., If the ProSe function decides to authorize the UE, then the V2X ProSe function sends 210 a registration response identifying the WBSS information to be used by the UE to communicate on the network (i.e., the registration response includes the same WBSS information included in the registration request and therefore includes V2X service capabilities such as the list of service identifiers disclosed in Para [0040] which is based on the V2X bearer coverage). The V2X ProSe function may use the same WBSS information in the received request 206. Alternatively, the V2X ProSe function may use the WBSS information in the registration response to change any one or more of the WBSS configuration parameters, such as security keys and the operating channel, [0063], & [0109] i.e., wherein the registration response includes WBSS information to be used by the UE for the WBSS services)
and one or more configuration parameters associated with reception by the wireless device via the V2X bearer; (see Para’s [0022] i.e., transmission and reception of BSMs for V2X, [0034-0042] i.e., UE is ready to receive and transmit announcements such as BSM and other WAVE services…This response provides authorization and information for the UE to receive (i.e., “reception”) and transmit announcements and other WAVE services from RSUs and other members of the WLAN group, [0043] i.e., the V2X ProSe function sends 210 a registration response identifying the WBSS information to be used by the UE to communicate on the network. The V2X ProSe function may use the same WBSS information in the received request 206 (i.e., the registration response includes the same WBSS information included in the registration request and therefore includes configuration parameters such as the DSCRC operating channel (i.e., “V2X bearer”) used for V2X communication), [0060] i.e., communication session over DSRC channel (i.e., “V2X bearer”) includes transmission/reception of data by the UE, [0064], [0095] i.e., wherein the V2X ProSe function sends a WBSS registration response to the V2X UE including WBSS operation parameters that the UE is allowed to use, which include SSID, operating channel (i.e., configuration parameters”), [0110] i.e., registration response includes an operating channel for the direct communications session (i.e., communication session includes reception by the UE via V2X bearer), [0196] i.e., sending a registration response from the ProSe function confirming WBSS information to be used for the services after deciding to authorize the UE, & [0203-0204] i.e., registration response comprises WBSS information)
and receiving, via the V2X bearer, at least one packet, (see Para’s [0004-0005] i.e., BSM messages (i.e., “packets”), [0022] i.e., transmission and reception of BSMs (i.e., “packets”) for V2X, [0034-0042] i.e., Such a registration request identifies the UE to the ProSe function and indicates that the UE is ready to receive and transmit announcements such as BSM and WAVE services, [0031], [0060] i.e., the ProSe logic may provide a direct communication session over a DSRC channel (i.e., “V2X bearer”) when the ProSe function indicates that the UE is authorized to provide the direct communication session, [0064] i.e., WBSS communication services where the UE may communicate with one or more other V2X enables UEs…the UE may provide a direct communication session (i.e., communication session includes communication of packets) over the DSRC channel (i.e., “V2X bearer”) when the registration response indicates that the UE is authorized to provide a direct communications session over the DSRC channel, [0119], & [0210]).
Cavalcanti does not disclose the V2X communications of the wireless device is performed using a V2X multicast bearer between the wireless device and the network entity and receiving, from the network entity via the V2X multicast bearer, at least one packet. However the claim features would be rendered obvious in view of Xu et al. US (2018/0192268).
XU discloses wherein a V2X UE (see Fig. 9 i.e., UE as OBU) performs V2X communications using V2X multicast bearer between the wireless device (see Fig. 9 i.e., UE as OBU) and a network entity (see Fig. 9 i.e., V2X AS, BM-SC, & MBMS- GW may be core network entities for sending V2X data to the UE & Para’s [0017] i.e., core network Evolved packet core (EPC)…interface between the V2X AS and a BM-SC in the EPC to send the V2X service, [0077], [0124] i.e., the OBU requests V2X AS to make a registration, or the OBU requests the V2X AS to obtain the V2X service, [0132] i.e., the V2X AS sends the V2X data to the OBU via the core network, [0133] i.e., The V2X AS may send data to the OBU through the broadcast mode or the unicast mode, and the V2X AS judges whether to send data through the unicast carriers or the broadcast carriers according to network deployment…If a MBMS broadcast carrier (i.e., “V2X multicast bearer coverage”) is deployed on the network…the V2X AS can send data through the broadcast carrier (i.e., “V2X multicast bearer coverage”) & [0159] i.e., where, the V2X AS sends to the OBU via the BM-SC->MBMS-GW->eNB…The data is sent via the MBMS broadcast carrier (i.e., “V2X multicast bearer”)).
Xu discloses receiving, from the network entity (see Fig. 9), via the V2X multicast bearer, at least one packet (see Fig. 9 & Para’s [0017] i.e., core network Evolved packet core (EPC)…interface between the V2X AS and a BM-SC in the EPC to send the V2X service, [0077], [0124] i.e., the OBU requests V2X As to make a registration, or the OBU requests the V2X AS to obtain the V2X service, [0132] i.e., the V2X AS sends the V2X data to the OBU via the core network, [0133] i.e., The V2X AS may send data to the OBU through the broadcast mode or the unicast mode, and the V2X AS judges whether to send data through the unicast carriers or the broadcast carriers according to network deployment…If a MBMS broadcast carrier (i.e., “V2X multicast bearer”) is deployed on the network…the V2X AS can send data through the broadcast carrier (i.e., “V2X multicast bearer”) & [0159] i.e., where, the V2X As sends to the OBU via the BM-SC->MBMS-GW->eNB…The data is sent via the MBMS broadcast carrier (i.e., “V2X multicast bearer”)).
(Xu suggests the OBU (i.e., UE) requests the V2X AS to make a registration in order to properly obtain the V2X service via the V2X multicast bearer, (see Para [0124])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the V2X communications performed by the UE over the V2X bearer as disclosed in Cavalcanti to include V2X communications supporting V2X multicast communications using a V2X multicast bearer between the wireless device and the network entity as disclosed in the teachings of Xu who discloses receiving from the network entity, via the V2X multicast bearer, at least one packet, because the motivation lies in Xu that the OBU (i.e., UE) requests the V2X AS to make a registration in order to properly obtain the V2X service via the V2X multicast bearer.
While the combination of Cavalcanti in view of Xu discloses sending by the wireless device to the network entity, a first message comprising information for updating the V2X multicast bearer (Cavalcanti, see Para’s [0035-0041] i.e., registration request (i.e., “first message”) [0043] i.e., The WBSS service registration procedure may be executed…The same or a similar procedure may also be used by the UEs to update their WBSS configuration & Xu, see Fig, 9 & Para’s [0133] & [0159] i.e., V2X MBMS broadcast carrier), the combination of Cavalcanti in view of Xu does not disclose the first message comprising an indicator of a packet loss associated with the multicast bearer between the wireless device and the network entity. However the claim feature would be rendered obvious in view of Kotecha et al. US (2013/0215813).
Kotecha discloses sending, by a first wireless device (see Fig. 2A i.e., UE 102-1) to a network entity (see Fig. 1 i.e., EPC 106 & Fig. 2A i.e., feedback monitoring module 206 which may be included in a network element in network 100 of Fig. 1 including a core network element & Para [0031] i.e., Feedback monitoring module 206 may be located in a network element in network 100), a first message (see Fig. 2 i.e., status report message 212) comprising an indicator of a packet loss associated with a multicast bearer (see Para’s [0018] i.e., MME 120 is also involved in bearer activation, [0021], [0025] i.e., MBMS bearer, & [0036]) between the wireless device and the core network entity, (see Figures 1-2B, & Para’s [0024-0026] i.e., multicast services (i.e., MBMS), [0030] i.e., UE 102 may receive the broadcast/multicast and periodically provide a status report 212…the status report 212 may include metrics that identify quality of service characteristic for the broadcast/multicast at each base station (e.g., eNB 114), such as…packet loss percentage (i.e., “indicator of a packet loss”) & [0032] i.e., For example, quality of service values 252 may include multiple values for different indicators of radio conditions, such as packet loss and other values that are provided by UE 102 in the status report)
(Kotecha suggests the first message comprising the indicator of the packet loss associated with the multicast bearer is used for updating the multicast bearer configuration such as adjusted MCS values and FEC values that may optimize error correction, provide optimized performance of the multicast services for the UE, and provide a target quality of service based on the radio conditions such as the packet loss, (see Para’s [0010], [0031-0032], & [0035])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the first message comprising an indicator of a packet loss associated with the multicast bearer for updating the multicast bearer configuration as disclosed in Kotecha to be performed for the V2X multicast bearer and included as further information in the first message disclosed in Cavalcanti in view of Xu who discloses sending by the wireless device to the core network entity, a first message comprising information for updating the V2X multicast bearer, because the motivation lies in Kotecha that the first message comprising the indicator of the packet loss associated with the multicast bearer is used for updating the multicast bearer configuration such as adjusted MCS values and FEC values that may optimize error correction, provide optimized performance of the multicast services for the UE, and provide a target quality of service based on the radio conditions such as the packet loss.
While Cavalcanti discloses sending by the wireless device, the first message to the network entity may which may be the MME (see Fig. 3 i.e., V2X Pro Se Function 204, Fig. 5 i.e., MME & Para [0118] i.e., wherein the ProSe function resides in a core network (CN) element that is communicatively coupled via a third interface with a serving gateway (SGW) or a PDN gateway (PGW) suggests the core network element may be the MME & Xu, see Fig. 9 i.e., MME), the combination of Cavalcanti in view of Xu, and further in view of Kotecha does not disclose the network entity is an internet protocol multimedia subsystem (IMS) network entity. However the claim feature would be rendered obvious in view of Haynes et al. US (2012/0282915).
Haynes discloses a network entity such as MME and CSCF server 260 (i.e., “IMS network entity”) may be integrated into a single device (i.e., “IMS network entity”), (see Para [0026] i.e., Further MME 240, HSS server 250, and/or CSCF server 260 may be integrated into a single device).
(Haynes suggests the CSCF server 260 is used to authenticate user device 110 in order to successfully establish the connection 150 and the IMS core may be used to manage authentication and session initiation associated with the user device 110 (see Para’s [0028] & [0057])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the network entity such as the MME as disclosed in Cavalcanti in view of Xu, and further in view of Kotecha to be integrated into the single device (i.e., “IMS network entity”) including the CSCF server 260 and MME 240 as disclosed in the teachings of Haynes, which results in sending the first message and receiving the second message, by the wireless device to/from an IMS network entity, because the motivation lies in Haynes that the CSCF server 260 is used to authenticate user device 110 in order to successfully establish the connection 150 and the IMS core may be used to manage authentication and session initiation associated with the user device 110.
While Cavalcanti discloses receiving the second message such as the registration response, (Cavalcanti, see Fig. 3, 210 & Para’s [0043] & [0095]), the combination of Cavalcanti in view of Xu, further in view of Kotecha, and further in view of Haynes does not disclose the claim feature of wherein the wireless device is further configured to: send, to the IMS network entity, a third message confirming the second message. However the claim feature would be rendered obvious in view of Atarius et al. US (2010/0197305).
Atarius discloses sending, by a wireless device (see Fig. 4 i.e., UE 104) to an IMS network entity (see Fig. 4 i.e., P-CSCF 240), a third message (see Fig. 4 i.e., ACK message at step 400) confirming a second message (see Fig. 4 i.e., “200 OK” at step 494) such as a registration response (see Para’s [0057] i.e., The “200 OK” response may indicate to the UE 104 that the registration is accepted or is successful (i.e., “registration response”)…The P-CSCF 240 then forwards the “200 OK” response to the UE 104 as illustrated by message flow path 194 & [0058] i.e., The UE 104 acknowledges the registration to the S-CSCF 244 by transmitting the “Acknowledgement” response to the P-CSCF 240 (i.e., “IMS network entity”) as illustrated by message flow path 400).
(Atarius suggests the acknowledgement response is sent to the P-CSCF for acknowledging the registration to the IMS network entity in order to successfully establish a signaling connection 496 with the P-CSCF for performing a communication session in order to access services and/or applications, (see Para [0058]))
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the wireless device disclosed in Cavalcanti in view of Xu, further in view of Kotecha, and further in view of Haynes to be further configured to send to the IMS network entity, a third message confirming the second message such as the registration response based on using the acknowledgement message sent from the UE to the IMS network entity as disclosed in the teachings of Atarius who discloses sending, by a UE, to an IMS network entity, an acknowledgement confirming a registration response received from the IMS network entity, because the motivation lies in Atarius that the acknowledgement response is sent to the P-CSCF for acknowledging the registration to the IMS network entity in order to successfully establish a signaling connection 496 with the P-CSCF for performing a communication session in order to access services and/or applications.
Regarding Claim 18, the combination of Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses the system of claim 17, wherein the second message further comprises one or more configuration parameters associated with reception via a V2X broadcast bearer, (Cavalcanti, see Para’s [0006] i.e., broadcast messages communicated to vehicles, [0007] i.e., V2X devices to discover and take advantage of safety and non-safety services, which may be broadcasted over one or more DSCRC channels (i.e., “V2X broadcast bearer”), [0031] i.e., RSU may periodically broadcast safety messages, such as BSMs using a specific BSSID in one of the DSRC/802.11p service channels, [0035-0043] i.e., the V2X ProSe function sends 210 a registration response identifying the WBSS information to be used by the UE to communicate on the network. The V2X ProSe function may use the same WBSS information (i.e., includes configuration parameters such as DSRC channel which may be a V2X broadcast bearer) in the received request 206)
Regarding Claim 25, Cavalcanti discloses a wireless device (see Fig. 3 i.e., V2X UE 202) comprising: one or more processors (see Fig. 7 i.e., control logic 612 & Para’s [0059-0061]); and memory storing instructions (see Fig. 7 & Para’s [0061] i.e., processor and memory that executes one or more software or firmware programs) that, when executed by the one or more processors (see Fig. 7 & Para’s [0059-0061]), configure the wireless device (see Fig. 3 i.e., V2X UE 202) to: send to a network entity (see Fig. 3 i.e., V2X Pro Se Function 204, Fig. 5 i.e., MME & Para [0118] i.e., wherein the ProSe function resides in a core network (CN) element (i.e., “MME”) that is communicatively coupled via a third interface with a serving gateway (SGW) or a PDN gateway (PGW)), a first message (see Fig. 3 i.e., registration request 206) comprising an indicator of a vehicle-to-everything (V2X) bearer for the wireless device, (see Fig. 3 & Para’s [0004] i.e., V2X communications, [0007] i.e., V2X communications are provided in part by a dedicated short range communications (DSRC) channel, which may be carried by a local and metropolitan area network such as defined in IEEE 802.11p standard and by a cellular network (e.g., LTE, 5G) (i.e., “V2X bearer”) [0023] i.e., WBSS services registration procedure to register UEs for V2X communications, [0033] i.e., communication of V2X services over DSRC/802.11p networks (i.e., “bearer”) & [0034-0043] i.e., a V2X UE that provides services over a WBSS in DSRC/802.11p channels (i.e., “V2X bearer”) sends 206 a registration request to a V2X ProSe function carrying WBSS information (i.e., WBSS information includes one or more indicators). The WBSS information may include BSSID as defined in 802.11p, operating channel: DSRC channel number, which may be a control channel (CCH) or service channel (SCH) (i.e., BSSID and DSRC channel number may be indicators of “V2X bearer”), Security Information, List of service identifiers (i.e., “indicators”): one or more service ids, such as the PSID, [0092] i.e., wherein the WBSS registration request message comprises any combination of the following parameters: SSID, operating channel, security information, and service identifiers or a list of PSIDs & [0101])
Receive, from the network entity (see Fig. 3 i.e., V2X Pro Se Function 204 & Para [0118]), a second message (see Fig. 3 i.e., registration response 210) comprising: one or more indicators of V2X service capabilities, (see Fig. 3 & Para’s [0034-0043] i.e., If the ProSe function decides to authorize the UE, then the V2X ProSe function sends 210 a registration response identifying the WBSS information to be used by the UE to communicate on the network (i.e., the registration response includes the same WBSS information included in the registration request and therefore includes V2X service capabilities such as the list of service identifiers disclosed in Para [0040] which is based on the V2X bearer coverage). The V2X ProSe function may use the same WBSS information in the received request 206. Alternatively, the V2X ProSe function may use the WBSS information in the registration response to change any one or more of the WBSS configuration parameters, such as security keys and the operating channel, [0063], & [0109] i.e., wherein the registration response includes WBSS information to be used by the UE for the WBSS services)
and one or more configuration parameters associated with reception by the wireless device via the V2X bearer; (see Para’s [0022] i.e., transmission and reception of BSMs for V2X, [0034-0042] i.e., UE is ready to receive and transmit announcements such as BSM and other WAVE services…This response provides authorization and information for the UE to receive (i.e., “reception”) and transmit announcements and other WAVE services from RSUs and other members of the WLAN group, [0043] i.e., the V2X ProSe function sends 210 a registration response identifying the WBSS information to be used by the UE to communicate on the network. The V2X ProSe function may use the same WBSS information in the received request 206 (i.e., the registration response includes the same WBSS information included in the registration request and therefore includes configuration parameters such as the DSCRC operating channel (i.e., “V2X bearer”) used for V2X communication), [0060] i.e., communication session over DSRC channel (i.e., “V2X bearer”) includes transmission/reception of data by the UE, [0064], [0095] i.e., wherein the V2X ProSe function sends a WBSS registration response to the V2X UE including WBSS operation parameters that the UE is allowed to use, which include SSID, operating channel (i.e., configuration parameters”), [0110] i.e., registration response includes an operating channel for the direct communications session (i.e., communication session includes reception by the UE via V2X bearer), [0196] i.e., sending a registration response from the ProSe function confirming WBSS information to be used for the services after deciding to authorize the UE, & [0203-0204] i.e., registration response comprises WBSS information)
and receive, via the V2X bearer, at least one packet, (see Para’s [0004-0005] i.e., BSM messages (i.e., “packets”), [0022] i.e., transmission and reception of BSMs (i.e., “packets”) for V2X, [0034-0042] i.e., Such a registration request identifies the UE to the ProSe function and indicates that the UE is ready to receive and transmit announcements such as BSM and WAVE services, [0031], [0060] i.e., the ProSe logic may provide a direct communication session over a DSRC channel (i.e., “V2X bearer”) when the ProSe function indicates that the UE is authorized to provide the direct communication session, [0064] i.e., WBSS communication services where the UE may communicate with one or more other V2X enables UEs…the UE may provide a direct communication session (i.e., communication session includes communication of packets) over the DSRC channel (i.e., “V2X bearer”) when the registration response indicates that the UE is authorized to provide a direct communications session over the DSRC channel, [0119], & [0210]).
Cavalcanti does not disclose the V2X communications of the wireless device is performed using a V2X multicast bearer between the wireless device and the network entity and receiving, from the network entity via the V2X multicast bearer, at least one packet. However the claim features would be rendered obvious in view of Xu et al. US (2018/0192268).
XU discloses wherein a V2X UE (see Fig. 9 i.e., UE as OBU) performs V2X communications using V2X multicast bearer between the wireless device (see Fig. 9 i.e., UE as OBU) and a network entity (see Fig. 9 i.e., V2X AS, BM-SC, & MBMS- GW may be core network entities for sending V2X data to the UE & Para’s [0017] i.e., core network Evolved packet core (EPC)…interface between the V2X AS and a BM-SC in the EPC to send the V2X service, [0077], [0124] i.e., the OBU requests V2X AS to make a registration, or the OBU requests the V2X AS to obtain the V2X service, [0132] i.e., the V2X AS sends the V2X data to the OBU via the core network, [0133] i.e., The V2X AS may send data to the OBU through the broadcast mode or the unicast mode, and the V2X AS judges whether to send data through the unicast carriers or the broadcast carriers according to network deployment…If a MBMS broadcast carrier (i.e., “V2X multicast bearer coverage”) is deployed on the network…the V2X AS can send data through the broadcast carrier (i.e., “V2X multicast bearer coverage”) & [0159] i.e., where, the V2X AS sends to the OBU via the BM-SC->MBMS-GW->eNB…The data is sent via the MBMS broadcast carrier (i.e., “V2X multicast bearer”)).
Xu discloses receiving, from the network entity (see Fig. 9), via the V2X multicast bearer, at least one packet (see Fig. 9 & Para’s [0017] i.e., core network Evolved packet core (EPC)…interface between the V2X AS and a BM-SC in the EPC to send the V2X service, [0077], [0124] i.e., the OBU requests V2X As to make a registration, or the OBU requests the V2X AS to obtain the V2X service, [0132] i.e., the V2X AS sends the V2X data to the OBU via the core network, [0133] i.e., The V2X AS may send data to the OBU through the broadcast mode or the unicast mode, and the V2X AS judges whether to send data through the unicast carriers or the broadcast carriers according to network deployment…If a MBMS broadcast carrier (i.e., “V2X multicast bearer”) is deployed on the network…the V2X AS can send data through the broadcast carrier (i.e., “V2X multicast bearer”) & [0159] i.e., where, the V2X As sends to the OBU via the BM-SC->MBMS-GW->eNB…The data is sent via the MBMS broadcast carrier (i.e., “V2X multicast bearer”)).
(Xu suggests the OBU (i.e., UE) requests the V2X AS to make a registration in order to properly obtain the V2X service via the V2X multicast bearer, (see Para [0124])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the V2X communications performed by the UE over the V2X bearer as disclosed in Cavalcanti to include V2X communications supporting V2X multicast communications using a V2X multicast bearer between the wireless device and the network entity as disclosed in the teachings of Xu who discloses receiving from the network entity, via the V2X multicast bearer, at least one packet, because the motivation lies in Xu that the OBU (i.e., UE) requests the V2X AS to make a registration in order to properly obtain the V2X service via the V2X multicast bearer.
While the combination of Cavalcanti in view of Xu discloses sending by the wireless device to the network entity, a first message comprising information for updating the V2X multicast bearer (Cavalcanti, see Para’s [0035-0041] i.e., registration request (i.e., “first message”) [0043] i.e., The WBSS service registration procedure may be executed…The same or a similar procedure may also be used by the UEs to update their WBSS configuration & Xu, see Fig, 9 & Para’s [0133] & [0159] i.e., V2X MBMS broadcast carrier), the combination of Cavalcanti in view of Xu does not disclose the first message comprising an indicator of a packet loss associated with the multicast bearer between the wireless device and the network entity. However the claim feature would be rendered obvious in view of Kotecha et al. US (2013/0215813).
Kotecha discloses sending, by a first wireless device (see Fig. 2A i.e., UE 102-1) to a network entity (see Fig. 1 i.e., EPC 106 & Fig. 2A i.e., feedback monitoring module 206 which may be included in a network element in network 100 of Fig. 1 including a core network element & Para [0031] i.e., Feedback monitoring module 206 may be located in a network element in network 100), a first message (see Fig. 2 i.e., status report message 212) comprising an indicator of a packet loss associated with a multicast bearer (see Para’s [0018] i.e., MME 120 is also involved in bearer activation, [0021], [0025] i.e., MBMS bearer, & [0036]) between the wireless device and the core network entity, (see Figures 1-2B, & Para’s [0024-0026] i.e., multicast services (i.e., MBMS), [0030] i.e., UE 102 may receive the broadcast/multicast and periodically provide a status report 212…the status report 212 may include metrics that identify quality of service characteristic for the broadcast/multicast at each base station (e.g., eNB 114), such as…packet loss percentage (i.e., “indicator of a packet loss”) & [0032] i.e., For example, quality of service values 252 may include multiple values for different indicators of radio conditions, such as packet loss and other values that are provided by UE 102 in the status report)
(Kotecha suggests the first message comprising the indicator of the packet loss associated with the multicast bearer is used for updating the multicast bearer configuration such as adjusted MCS values and FEC values that may optimize error correction, provide optimized performance of the multicast services for the UE, and provide a target quality of service based on the radio conditions such as the packet loss, (see Para’s [0010], [0031-0032], & [0035])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the first message comprising an indicator of a packet loss associated with the multicast bearer for updating the multicast bearer configuration as disclosed in Kotecha to be performed for the V2X multicast bearer and included as further information in the first message disclosed in Cavalcanti in view of Xu who discloses sending by the wireless device to the core network entity, a first message comprising information for updating the V2X multicast bearer, because the motivation lies in Kotecha that the first message comprising the indicator of the packet loss associated with the multicast bearer is used for updating the multicast bearer configuration such as adjusted MCS values and FEC values that may optimize error correction, provide optimized performance of the multicast services for the UE, and provide a target quality of service based on the radio conditions such as the packet loss.
While Cavalcanti discloses sending by the wireless device, the first message to the network entity may which may be the MME (see Fig. 3 i.e., V2X Pro Se Function 204, Fig. 5 i.e., MME & Para [0118] i.e., wherein the ProSe function resides in a core network (CN) element that is communicatively coupled via a third interface with a serving gateway (SGW) or a PDN gateway (PGW) suggests the core network element may be the MME & Xu, see Fig. 9 i.e., MME), the combination of Cavalcanti in view of Xu, and further in view of Kotecha does not disclose the network entity is an internet protocol multimedia subsystem (IMS) network entity. However the claim feature would be rendered obvious in view of Haynes et al. US (2012/0282915).
Haynes discloses a network entity such as MME and CSCF server 260 (i.e., “IMS network entity”) may be integrated into a single device (i.e., “IMS network entity”), (see Para [0026] i.e., Further MME 240, HSS server 250, and/or CSCF server 260 may be integrated into a single device).
(Haynes suggests the CSCF server 260 is used to authenticate user device 110 in order to successfully establish the connection 150 and the IMS core may be used to manage authentication and session initiation associated with the user device 110 (see Para’s [0028] & [0057])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the network entity such as the MME as disclosed in Cavalcanti in view of Xu, and further in view of Kotecha to be integrated into the single device (i.e., “IMS network entity”) including the CSCF server 260 and MME 240 as disclosed in the teachings of Haynes, which results in sending the first message and receiving the second message, by the wireless device to/from an IMS network entity, because the motivation lies in Haynes that the CSCF server 260 is used to authenticate user device 110 in order to successfully establish the connection 150 and the IMS core may be used to manage authentication and session initiation associated with the user device 110.
While Cavalcanti discloses receiving the second message such as the registration response, (Cavalcanti, see Fig. 3, 210 & Para’s [0043] & [0095]), the combination of Cavalcanti in view of Xu, further in view of Kotecha, and further in view of Haynes does not disclose the claim feature of sending, by the wireless device to the IMS network entity, a third message confirming the second message. However the claim feature would be rendered obvious in view of Atarius et al. US (2010/0197305).
Atarius discloses sending, by a wireless device (see Fig. 4 i.e., UE 104) to an IMS network entity (see Fig. 4 i.e., P-CSCF 240), a third message (see Fig. 4 i.e., ACK message at step 400) confirming a second message (see Fig. 4 i.e., “200 OK” at step 494) such as a registration response (see Para’s [0057] i.e., The “200 OK” response may indicate to the UE 104 that the registration is accepted or is successful (i.e., “registration response”)…The P-CSCF 240 then forwards the “200 OK” response to the UE 104 as illustrated by message flow path 194 & [0058] i.e., The UE 104 acknowledges the registration to the S-CSCF 244 by transmitting the “Acknowledgement” response to the P-CSCF 240 (i.e., “IMS network entity”) as illustrated by message flow path 400).
(Atarius suggests the acknowledgement response is sent to the P-CSCF for acknowledging the registration to the IMS network entity in order to successfully establish a signaling connection 496 with the P-CSCF for performing a communication session in order to access services and/or applications, (see Para [0058]))
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the wireless device disclosed in Cavalcanti in view of Xu, further in view of Kotecha, and further in view of Haynes to send to the IMS network entity, a third message confirming the second message such as the registration response based on using the acknowledgement message sent from the UE to the IMS network entity as disclosed in the teachings of Atarius who discloses sending, by a UE, to an IMS network entity, an acknowledgement confirming a registration response received from the IMS network entity, because the motivation lies in Atarius that the acknowledgement response is sent to the P-CSCF for acknowledging the registration to the IMS network entity in order to successfully establish a signaling connection 496 with the P-CSCF for performing a communication session in order to access services and/or applications.
Regarding Claim 26, the combination of the combination of Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses the wireless device of claim 25, wherein the second message further comprises one or more configuration parameters associated with reception via a V2X broadcast bearer, (Cavalcanti, see Para’s [0006] i.e., broadcast messages communicated to vehicles, [0007] i.e., V2X devices to discover and take advantage of safety and non-safety services, which may be broadcasted over one or more DSCRC channels (i.e., “V2X broadcast bearer”), [0031] i.e., RSU may periodically broadcast safety messages, such as BSMs using a specific BSSID in one of the DSRC/802.11p service channels, [0035-0043] i.e., the V2X ProSe function sends 210 a registration response identifying the WBSS information to be used by the UE to communicate on the network. The V2X ProSe function may use the same WBSS information (i.e., includes configuration parameters such as DSRC channel which may be a V2X broadcast bearer) in the received request 206)
3. Claims 3-4, 7, 11-12, 15, 19-20, 23, 27-28, 31, 33, and 35-36 are rejected under 35 U.S.C. 103 as being unpatentable over Cavalcanti et al. US (2018/0295655), in view of Xu et al. US (2018/0192268), further in view of Kotecha et al. US (2013/0215813), further in view of Haynes et al. US (2012/0282915), and further in view of Atarius et al. US (2010/0197305), as applied to claim 1 above, and further in view of Kim et al. US (2015/0043429).
Regarding Claims 3, 11, 19, and 27 the combination of Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses the method, non-transitory computer-readable medium, system, and device of claims 1, 9, 17, and 25, wherein the first message indicates one or more target device types with which the wireless device supports V2X communications, (Cavalcanti, see Para’s [0004] i.e., communication of BSM messages between vehicles (i.e., V2V communication), between vehicles and infrastructure fixtures (V2I communications), and between vehicles and pedestrians (V2P communications). Collectively V2V, V2I, and V2P communications (i.e., “target device types” which the V2X UE may support) are designated as vehicle to everything (V2X) communications, [0035], & [0040] i.e., The registration request (i.e., “first message”) carrying WBSS information includes a List of service identifiers (i.e., one or more service ids, such as the PSID (i.e., V2X service types indicating target device types))
While Cavalcanti discloses the first message indicating the one or more target device types with which the wireless device supports V2X communications which are capabilities of the wireless device, (Cavalcanti, see Para’s [0004], [0035], & [0040]), the combination of Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius does not disclose wherein the first message further comprises a SIP header field for indicating the capabilities. However the claim feature would be rendered obvious in view of Kim et al. US (2015/0043429).
Kim discloses a UE transmitting a SIP register Request for registration of a UE comprising a first SIP header field comprising one or more indicators for capabilities of the UE (see Para [0125] i.e., IMS registration by an IMS UE, [0126] i.e., information about ProSe capability of a UE includes information about one or more capabilities of the UE & [0127-0129] i.e., When the IMS UE performs IMS registration, the IMS UE may transmit an SIP Register request message to an IMS network by including ProSe capability information. For example, the ProSe capability information may be included in an SIP message using one or more of a header field of the SIP message)
(Kim suggests the IMS UE performs IMS registration by indicating one or more capabilities of the UE using SIP protocol for establishing ProSe communications and SIP can be used to set up, modify, and terminate a multicast session (see Para’s [0004] i.e., The SIP is a signaling protocol for controlling a multimedia service session using an IP, and can be used to set up, modify and terminate a unicast or multicast session, [0016], [0126-0128], & [0132-0134])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the capabilities of the wireless device such as one or more target device types included in the first message which is used for setting up or establishing the V2X multicast communication session as disclosed in Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius to be included in the session initiation protocol (SIP) register request message header disclosed in the teachings of Kim who discloses the SIP message comprises a SIP header field indicating UE capabilities for registration of the UE, because the motivation lies in Kim that the session initiation protocol (SIP) can be used to set up, modify, and terminate a multicast session for the UE.
Regarding Claims 4, 12, 20, and 28 the combination of Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses the method, non-transitory computer-readable medium, system and wireless device of claim 3, 11, 19, and 27 including wherein the one or more target device types are associated with capability to communicate via at least one of: vehicle to pedestrian communications; vehicle to infrastructure communications; vehicle to vehicle communications; or vehicle to network communications, (Cavalcanti, see Para’s [0004] i.e., communication of BSM messages between vehicles (i.e., V2V communication), between vehicles and infrastructure fixtures (V2I communications), and between vehicles and pedestrians (V2P communications). Collectively V2V, V2I, and V2P communications (i.e., “target device types” which the V2X UE may support) are designated as vehicle to everything (V2X) communications, [0035], & [0040] i.e., The registration request (i.e., “first message”) carrying WBSS information includes a List of service identifiers (i.e., one or more service ids, such as the PSID (i.e., V2X service types indicating target device types))
Regarding Claims 7, 15, 23, and 31 the combination Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses the method of claim 1, wherein the first message further comprises a session initiation protocol (SIP) header field indicating at least one of: a PC5 communications V2X capability of the wireless device; or an emergency communication capability of the wireless device, (Cavalcanti, see Para’s [0004-0006], [0022], [0031], i.e., transmission and reception of Basic Safety Messages (BSMs) for V2X where BSMs refer to emergency communications performed by the V2X UE using V2X service capabilities are indicated in the registration request message (i.e., first message) as disclosed in Para’s [0035-0042] i.e., List of service identifiers PSID included in registration request may indicate emergency communication capability of the wireless device such as V2I, V2V, and V2P which may perform BSM services…Such a registration request identifies the UE to the ProSe function and indicates that the UE is ready to receive and transmit announcements such as BSM services (i.e., emergency communication capability of the wireless device such as BSM service capability))
While Cavalcanti discloses the first message indicating an emergency communication capability of the wireless device, (see Para’s [0004-0006], [0022], [0031] & [0035-0042]), the combination of Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius does not disclose wherein the first message further comprises a SIP header field for indicating the capability. However the claim feature would be rendered obvious in view of Kim et al. US (2015/0043429).
Kim discloses a UE transmitting a SIP register Request for registration of a UE comprising a first SIP header field comprising one or more indicators for capabilities of the UE (see Para [0125] i.e., IMS registration by an IMS UE, [0126] i.e., information about ProSe capability of a UE includes information about one or more capabilities of the UE & [0127-0129] i.e., When the IMS UE performs IMS registration, the IMS UE may transmit an SIP Register request message to an IMS network by including ProSe capability information. For example, the ProSe capability information may be included in an SIP message using one or more of a header field of the SIP message)
(Kim suggests the IMS UE performs IMS registration by indicating one or more capabilities of the UE using SIP protocol for establishing ProSe communications and SIP can be used to set up, modify, and terminate a multicast session (see Para’s [0004] i.e., The SIP is a signaling protocol for controlling a multimedia service session using an IP, and can be used to set up, modify and terminate a unicast or multicast session, [0016], [0126-0128], & [0132-0134])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the capability of the wireless device such as the emergency communication capability of the wireless device included in the first message which is used for setting up or establishing the V2X communication session as disclosed in Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius to be included in the session initiation protocol (SIP) register request message header disclosed in the teachings of Kim who discloses the SIP message comprises a SIP header field indicating UE capabilities for registration of the UE, because the motivation lies in Kim that the session initiation protocol (SIP) can be used to set up, modify, and terminate a multicast session for the UE.
Regarding Claim 33, the combination of Cavalcanti in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses the method of claim 1, but does not disclose the claim feature of wherein V2X multicast bearer is between a radio access network and the wireless device. However the claim feature would be rendered obvious in view of Xu et al. US (2018/0192268).
Xu discloses wherein V2X multicast bearer is between a radio access network and the wireless device (see Fig. 9 i.e., Uu interface between E-UTRAN (eNB) and UE as OBU & Para’s [0105] & [0132-0133] i.e., the V2X AS can send data to the OBU through the MBMS broadcast carrier)
(Xu suggests the OBU (i.e., UE) requests the V2X AS to make a registration in order to properly obtain the V2X service via the V2X multicast bearer, (see Para [0124])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the V2X communications performed by the UE over the V2X bearer as disclosed in Cavalcanti in view of Kotecha, further in view of Haynes, and further in view of Atarius to include V2X communications supporting V2X multicast communications using a V2X multicast bearer between the wireless device and the radio access network as disclosed in the teachings of Xu, because the motivation lies in Xu that the OBU (i.e., UE) requests the V2X AS to make a registration in order to properly obtain the V2X service via the V2X multicast bearer.
Regarding Claim 35, the combination of Cavalcanti in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses the method of claim 1, but does not disclose the claim feature of wherein the V2X multicast bearer is a multimedia broadcast multicast service (MBMS) bearer. However the claim feature would be rendered obvious in view of Xu et al. US (2018/0192268).
Xu discloses wherein the V2X multicast bearer is a multimedia broadcast multicast service (MBMS) bearer (see Fig. 9 & Para’s [0132-0133] i.e., the V2X AS can send data to the OBU through the MBMS broadcast carrier)
(Xu suggests the OBU (i.e., UE) requests the V2X AS to make a registration in order to properly obtain the V2X service via the V2X multicast bearer, (see Para [0124])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the V2X communications performed by the UE over the V2X bearer as disclosed in Cavalcanti in view of Kotecha, further in view of Haynes, and further in view of Atarius to include V2X communications supporting V2X multicast communications using a V2X multicast bearer between the wireless device and the radio access network as disclosed in the teachings of Xu, because the motivation lies in Xu that the OBU (i.e., UE) requests the V2X AS to make a registration in order to properly obtain the V2X service via the V2X multicast bearer.
Regarding Claim 36, the combination of Cavalcanti in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses the wireless device of claim 25, but does not disclose the claim features of wherein the sending the first message comprises: sending, by the wireless device via the IMS network entity to a V2X application server, the first message, and wherein the receiving the second message comprises: receiving, by the wireless device via the IMS network entity from the V2X application server, the second message. However the claim feature would be rendered obvious in view of Xu et al. US (2018/0192268).
Xu discloses wherein the sending the first message comprises: sending, by the wireless device via the IMS network entity to a V2X application server, the first message, (see Fig. 9 & Para’s [0124] i.e., OBU requests V2X AS to make a registration via signaling information to the V2X function forwarded to the V2X AS via a PC2 interface (i.e., first message such as a registration request))
and wherein the receiving the second message comprises: receiving, by the wireless device via the IMS network entity from the V2X application server, the second message (see Fig. 9 & Para [0125] i.e., the V2X AS sends a response to the OBU via the V2X function (i.e., second message such as the registration response)).
(Xu suggests the OBU (i.e., UE) requests the V2X AS to make a registration in order to properly obtain the V2X service via the V2X multicast bearer from the V2X AS, (see Para [0124])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the V2X registration based on the first message and second message communicated between the UE and the V2X function for obtaining V2X services as disclosed in Cavalcanti in view of Kotecha, further in view of Haynes, and further in view of Atarius to be communicated via the IMS network entity to a V2X application server as disclosed in the teachings of Xu, because the motivation lies in Xu that the OBU (i.e., UE) requests the V2X AS to make a registration in order to properly obtain the V2X service via the V2X multicast bearer from the V2X AS.
5. Claims 5-6, 13-14, 21-22, and 29-30 are rejected under 35 U.S.C. 103 as being unpatentable over Cavalcanti et al. US (2018/0295655), in view of Xu et al. US (2018/0192268), further in view of Kotecha et al. US (2013/0215813), further in view of Haynes et al. US (2012/0282915), and further in view of Atarius et al. US (2010/0197305) as applied to claim 1 above, and further in view of XU et al. US (2018/0324560).
Regarding Claims 5, 13, 21, and 29 the combination of Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses the method of claim 1 including one or more indicators of V2X multicast service capabilities (Cavalcanti, see Para’s [0035] & [0040]), but does not disclose wherein the one or more indicators of V2X multicast service capabilities comprise at least one of: an IMS communication service identifier (ICSI); or an IMS application reference identifier (IARI). However the claim feature would be rendered obvious in view of XU et al. US (2018/0324560).
XU discloses wherein one or more indicators for V2X multicast service capabilities comprise at least one of: an IMS communication service identifier (ICSI), (In light of the applicants disclosure in (Para’s [0115] & [0117]), ICSIs may indicate different types of V2X UE services such as pedestrian, vehicle, infrastructure, V2V service, V2P service, V2I service, and/or V2N service capabilities of the wireless device. Xu discloses V2X service identifiers which may be interpreted as the claimed “ICSI”, (XU, see Para [0013] i.e., V2X Application Server (AS) classifies and identifies the V2X service, where different types of V2X services have different identifiers (i.e., “ICSI”), [0019] i.e., service identifier (“ICSI”) of the V2X service, [0035] i.e., different types of V2X services have different identifiers (“ICSI”), [0054], [0057], [0063], & [0088] i.e., V2X service includes at least one of the following: V2V, V2I, V2P, and V2N)).
(Xu suggests a Multimedia Broadcast Multicast Service (MBMS) bearing corresponding to the identifier of the V2X service is established for providing the V2X service (see Para’s [0013], [0019-0020] & [0057])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the one or more indicators for V2X multicast service capabilities disclosed in Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses to be assigned an IMS communication service identifier (ICSI) based on the teachings of Xu who discloses a service identifier is assigned to different types of V2X services because the motivation lies in Xu for establishing a Multimedia Broadcast Multicast Service (MBMS) bearing corresponding to the identifier of the V2X service for successfully providing the V2X service according to its classified service type.
Regarding Claim 6, 14, 22, and 30 the combination of Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses the method, non-transitory computer-readable medium, system, and device of claims 1, 9, 17, and 25 wherein the first message is used to establish a bearer for the V2X communication service (Cavalcanti, see Para’s [0035-0043], [0060], & [0064]), but does not disclose wherein the first message comprises at least one of: an internet protocol multimedia subsystem (IMS) communication service identifier (ICSI); or an IMS application reference identifier (IARI). However the claim feature would be rendered obvious in view of XU et al. US (2018/0324560).
XU discloses wherein a first message comprises at least one of: an IMS communication service identifier (ICSI); (see Para’s [0020] i.e., BM-SC receives from V2X AS a request message for activating a MBMS bearing, where the request message carries an identifier (i.e., “ICSI”) of the V2X service classified by the V2X AS, [0054-0057], & [0069])
(Xu suggests the first message is used to establish an MBMS bearer for the V2X communication service, (see Para’s [0020], [0057] i.e., where the request message is used for instructing the BM-SC to establish the MBMS bearing corresponding to the identifier of the V2X service & [0069-0071])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the first message which is used to establish a bearer for the V2X communication service as disclosed in the teachings of Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius to comprise an IMS communication service identifier (ICSI) for establishing the bearer based on the teachings of Xu who discloses wherein a first request message comprises at least one of: an IMS communication service identifier (ICSI), because the motivation lies in Xu that the first request message is used to establish an MBMS bearer for the V2X communication service based on the service identifier of the V2X service for successfully providing the V2X service according to its classified service type.
4. Claims 8, 16, 24, and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Cavalcanti et al. US (2018/0295655), in view of Xu et al. US (2018/0192268), further in view of Kotecha et al. US (2013/0215813), further in view of Haynes et al. US (2012/0282915), and further in view of Atarius et al. US (2010/0197305) as applied to claim 1 above, further in view of Cavalcanti et al. US (2018/0206089), and further in view of Kim et al. US (2015/0043429).
Regarding Claims 8, 16, 24, and 32 the combination of Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses the method, non-transitory computer-readable medium, system, and wireless device of claims 1, 9, 17, and 25 but does not disclose further comprising receiving, by the wireless device from the IMS network entity, a response message comprising a session initiation protocol (SIP) header field confirming registration of one or more target device types with which the wireless device supports V2X communications. However the claim feature would be rendered obvious in view of Cavalcanti et al. US (2018/0206089).
Cavalcanti discloses receiving, by a wireless device from the IMS network entity, a response message confirming registration of one or more target device types with which the wireless device supports V2X communications, (see Para’s [0054] i.e., the V2X host application 214 establishes a connection with the ITS function 106 through the P-GW 224, [0073] i.e., Device 210 sends an RSU authorization request 602 to the ITS function 106. The authorization request 602 requests that the device 210 operate as an RSU (i.e., “target device type”) and host one or more V2X services. Upon determining that the device 210 is authorized to act as an RSU and host one or more V2X services. The ITS function 106 sends an RSU authorization response 604 to the device 210 indicating that the device 210 is authorized to act as an RSU and host one or more V2X services).
(Cavalcanti suggests the device 210 transmits the authorization request 602 requesting that the device 210 operate as an RSU and host one or more V2X services (see Para [0073]).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the wireless device which communicates with the IMS network entity for establishing V2X communications as disclosed in Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius to perform registration of the wireless device as disclosed in the teachings of Cavalcanti who discloses the wireless device receives from a core network entity, a response message confirming registration of one or more target device types with which the wireless device supports V2X communications because the motivation lies in Cavalcanti for registering and authorizing the device 210 to operate as an RSU and host one or more V2X services.
The combination of Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, further in view of Atarius, further in view of Cavalcanti does not disclose the response message comprising a SIP header field confirming registration of the wireless device. However the claim feature would be rendered obvious in view of Kim et al. US (2015/0043429).
Kim discloses a session initiation protocol (SIP) procedure for a wireless device which receives a response message comprising a SIP header field confirming registration of the wireless device (see Para’s [0127-0129] i.e., SIP Register request message & [0142] i.e., This reporting operation may be performed using a response message to the SIP Register Request message transmitted by the IMS UE for IMS registration & [0157]).
(Kim suggests the IMS UE performs IMS registration using the SIP protocol for establishing the communication session and that SIP can be used to set up, modify, and terminate a multicast session, (see Para [0004])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the response message confirming registration of the wireless device as disclosed in Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius, further in view of Cavalcanti, to comprise a SIP header field confirming registration of the wireless device such as the SIP response message as disclosed in Kim because the motivation lies in Kim that the IMS UE performs IMS registration using the SIP protocol for establishing the communication session and that SIP can be used to set up, modify, and terminate a multicast session.
5. Claim 34 is rejected under 35 U.S.C. 103 as being unpatentable over Cavalcanti et al. US (2018/0295655), in view of Xu et al. US (2018/0192268), further in view of Kotecha et al. US (2013/0215813), further in view of Haynes et al. US (2012/0282915), and further in view of Atarius et al. US (2010/0197305) as applied to claim 1 above, and further in view of Kiss US (2015/0282108).
Regarding Claim 34, the combination of Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius discloses the method of claim 1, but does not disclose the claim feature of wherein the first message is a first session initiation protocol (SIP) message, and wherein the second message is a second SIP message. However the claim feature would be rendered obvious in view of Kiss US (2015/0282108).
Kiss discloses wherein a first message (i.e., registration request) is a first session initiation protocol (SIP) message sent from a UE to a ProSe function, (see Fig. 16 i.e., SIP register message 1602 & Para’s [0007], [0125-0126] & [0163])
and wherein the second message is a second SIP message, (see Fig. 16 i.e., 1610 & Para [0133] i.e., ProSe function 328A responds to UE 106A by sending a 200 OK response (step 1610) indicating that the registration was successful)
(Kiss suggests the UE performs the session initiation protocol (SIP) signaling with the ProSe function for registering for proximity services of a cellular network, (see Para’s [0002], [0007], & [0125])).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date for the registration procedure including the first registration request message and second registration request message communicated between the UE and the ProSe function as disclosed in Cavalcanti in view of Xu, further in view of Kotecha, further in view of Haynes, and further in view of Atarius to be performed using session initiation protocol (SIP) by using a SIP register request and SIP response communication between the UE and ProSe function as disclosed in Kiss, because the motivation lies in Kiss that the UE performs the session initiation protocol (SIP) signaling with the ProSe function for registering for proximity services of a cellular network.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ADNAN A BAIG whose telephone number is (571)270-7511. The examiner can normally be reached M-F 9:00am-5: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, Huy Vu can be reached at 571-272-3155. 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.
/ADNAN BAIG/Primary Examiner, Art Unit 2461
Prosecution Insights