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 .
DETAILED ACTION
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-8 and 10-21 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 20 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 20 recites the newly amended limitation "the plurality of vehicle events" in line 2. Claim 20 depends on claim 18, which does not teach the limitation a “plurality of vehicle events”. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Lee, et al. (U.S. Patent Application Pub. No. 2020/0394851) in view of Park (U.S. Patent Application Pub. No. 2016/0096473), and further in view of Zachary (U.S. Patent Application Pub. No. 2019/0385269).
Regarding Claim 1, Lee teaches: A method (Lee, Para. 0006 – “a method”), comprising:
monitoring a vehicle for a triggering event, wherein monitoring the vehicle for a triggering event includes estimating and/or measuring vehicle conditions (Lee, Para. 0058 and 0164 – acquiring measurement data associated with the vehicle by various sensors, including “measurement data from various sensors such as a speed meter…, an accelerometer…, an azimuth meter…, a brake detector…, a position measuring device…, or a road surface condition detector…”, which are information associated with the vehicle; for example, detecting a sinkhole, which satisfies a condition, or triggering event) and wherein the triggering event is selected from a group consisting of a user-initiated vehicle aid request (Lee, Para. 0060 and 0102 – where a processor may receive “an input from a user” to “transmit and receive the communication signal” in a wireless access in vehicular environment scheme that is “included and generated in a basic safety message (BSM)”)
responsive to detection of the triggering event, generating, via a Vehicle-to-Everything (V2X) communication module of the vehicle (Lee, Para. 0132 – where the message is a V2X message), a Basic Safety Message (BSM) in accordance with SAE Surface Vehicle Standard J2735 (Lee, Para. 0007 and 0058-0060 – generating transmission data based on received measurement data by a terminal platform, or communication module; where the transmission data is a “basic safety message (BSM)” defined by “society of automotive engineers (SAE) standard (e.g., document J2735)” which includes a relay message)
wherein the BSM includes location information of the vehicle including vehicle latitude, vehicle longitude, and vehicle elevation (Lee, Para. 0060 – where the BSM includes a latitude, a longitude, and an altitude of the vehicle) stored separately from extension information, wherein the where vehicle location information is stored in the BSM data part 1 field while a relay message is stored within the BSM data part 2 field; such that the location information and extension information are stored separately),
While Lee teaches generating, via a Vehicle-to-Everything (V2X) communication module of the vehicle, a Basic Safety Message (BSM) in accordance with SAE Surface Vehicle Standard J2735, including a relay message, wherein the BSM includes location information of the vehicle… stored separately from extension information, wherein a relay message is stored within the extension information, Lee does not teach the Basic Safety Message (BSM) including a vehicle aid request signature, wherein the vehicle aid request signature is stored within the extension information, and wherein the vehicle aid request signature comprises data indicating that the vehicle requests emergency aid from an external source, the method further including the vehicle receiving aid from the external source. Additionally, while Lee teaches wherein the triggering event is selected from a user-initiated vehicle aid request, Lee does not teach the triggering event is selected from a concurrent occurrence of a plurality of vehicle events.
However, Park teaches the Basic Safety Message (BSM) including a vehicle aid request signature, wherein the vehicle aid request signature is stored within the extension information, and wherein the vehicle aid request signature comprises data indicating that the vehicle requests emergency aid from an external source (Park, Para. 0028, 0046-0048, 0054-0055, 0067 – “a Basic Safety Message (BSM)” including “a Part I message” and an optional “Part II message”, or extension information, the Part II message including “an emergency situation message (SystemFailureSuspectFlag)” and “a release message (SystemFailureRecoveryFlag)” for “request[ing] a rescue from a rescue center”, or external source; where “when the emergency situation message and the release message are received, the vehicle that has transmitted the messages can be identified, and in particular, the rescue center 50 can easily identify the vehicle”), the method further including the vehicle receiving aid from the external source (Park, Para. 0003, 0054, 0090 – “rapidly inform the emergency situation of the vehicle 105 to the rescue center 150 and provide accurate information, thereby performing an efficient rescue”, i.e. “rapidly rescuing the vehicle”; where the “rescue center” is an institution, or external source, such as “a fire station, a police station, etc., which can control an emergency situation of a vehicle”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Lee to include the Basic Safety Message (BSM) including a vehicle aid request signature, wherein the vehicle aid request signature is stored within the extension information, and wherein the vehicle aid request signature comprises data indicating that the vehicle requests emergency aid from an external source, the method further including the vehicle receiving aid from the external source, as taught by Park, in order to more accurately detect an emergency situation of a vehicle and rapidly rescue the vehicle (Park, Para. 0003).
Lee in view of Park does not teach the triggering event is selected from a concurrent occurrence of a plurality of vehicle events.
However, Zachary teaches the triggering event is selected from a concurrent occurrence of a plurality of vehicle events (Zachary, Para. 0083 – “the vehicle 12 can simultaneously detect the occurrence of a plurality of vehicle events”; where the vehicle event is “predefined by one or more conditions pertaining to vehicle states”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have further modified the method including the above limitations of Lee in view of Park to include a concurrent occurrence of a plurality of vehicle events, as taught by Zachary, in order to detect and report multiple vehicle events in a singular message that is transmitted so that the receiving entity can respond accordingly.
In regards to Claim 4, Lee in view of Park and Zachary teaches the method of Claim 1, and Lee in view of Park and Zachary further teaches wherein the vehicle aid request signature is defined by a BSMpartIIExtension content of the BSM (Lee, Para. 0138 – a basic safety message having a “BSM data part 2 field” which includes “information constituting the relay message”; Park, Para. 0028, 0046-0048 – “a Basic Safety Message (BSM)” including “a Part I message” and an optional “Part II message”, or extension information, the Part II message including “an emergency situation message (SystemFailureSuspectFlag)” and “a release message (SystemFailureRecoveryFlag)” for “request[ing] a rescue from a rescue center”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method including the above limitations of Lee in view of Park and Zachary to further include wherein the vehicle aid request signature is defined by a BSMpartIIExtension content of the BSM, as taught by Park, in order to in order to more accurately detect an emergency situation of a vehicle and rapidly rescue the vehicle (Park, Para. 0003).
Claim(s) 2, 3, 10-15, and 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over Lee in view of Park and Zachary, and further in view of Khosla, et al. (U.S. Patent Application Pub. No. 2023/0308849)
In regards to Claim 2, Lee in view of Park and Zachary teaches the method of Claim 1, and Lee teaches wherein estimating and/or measuring vehicle conditions (Lee, Para. 0058 and 0164 – acquiring measurement data associated with the vehicle by various sensors, including “measurement data from various sensors such as a speed meter…, an accelerometer…, an azimuth meter…, a brake detector…, a position measuring device…, or a road surface condition detector…”, which are information associated with the vehicle; for example, detecting a sinkhole, which satisfies a condition, or triggering event), but Lee does not teach wherein estimating and/or measuring vehicle conditions includes determining a condition of one or more airbags of the vehicle, determining a condition of hazard lights of the vehicle, and determining a condition of a power source and/or a fuel level of the vehicle, and wherein a duration between occurrence of the conditions resulting in the desire for aid and provision of aid from the external source is reduced.
Park teaches wherein a duration between occurrence of the conditions resulting in the desire for aid and provision of aid from the external source is reduced (Park, Para. 0063-0064, 0090 – where an emergency situation, or conditions, of a vehicle is identified “more rapidly”, based on a “predetermined period of time”, and a “emergency situation message” is transmitted to a “rescue center”, or external source, in order to “rapidly inform the emergency situation of the vehicle 105 to the rescue center 150… thereby performing an efficient rescue”, such that the duration is reduced).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method including the above limitations of Lee in view of Park and Zachary to further wherein a duration between occurrence of the conditions resulting in the desire for aid and provision of aid from the external source is reduced, as taught by Park, in order to in order to rapidly rescue the vehicle (Park, Para. 0003).
Lee in view of Park does not teach wherein estimating and/or measuring vehicle conditions includes determining a condition of one or more airbags of the vehicle, determining a condition of hazard lights of the vehicle, and determining a condition of a power source and/or a fuel level of the vehicle.
Zachary teaches wherein estimating and/or measuring vehicle conditions includes determining a condition of a power source (Zachary, Para. 0037 – “obtain vehicle sensor information of the vehicle engine”, or power source, “from engine speed sensor 62, engine temperature sensor 64, and engine ignition timing sensor 66”, relating to the condition of the vehicle engine) and/or a fuel level of the vehicle.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method including the above limitations of Lee in view of Park and Zachary to further include wherein estimating and/or measuring vehicle conditions includes determining a condition of a power source, as taught by Zachary, in order to determine a state of a power source, which may be related to an event, such as a collision.
Lee in view of Park and Zachary does not teach herein estimating and/or measuring vehicle conditions includes determining a condition of one or more airbags of the vehicle and determining a condition of hazard lights of the vehicle.
However, Khosla teaches herein estimating and/or measuring vehicle conditions includes determining a condition of one or more airbags of the vehicle (Khosla, Table 1 and Para. 0048 – “a sensor that detects deployment of an air bag”, coded as “eventAirBagDeployment”) and determining a condition of hazard lights of the vehicle (Khosla, Table 1 and Para. 0059 – collecting extension data including event flags such as “eventHazardLights”, where the event flags are information collected by vehicles to send as collision related information).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have further modified the method including the above limitations of Lee in view of Park and Zachary to include wherein estimating and/or measuring vehicle conditions includes determining a condition of one or more airbags of the vehicle and determining a condition of hazard lights of the vehicle, as taught by Khosla, in order to inform the receiving entity that an event which caused an air bag to deploy has occurred or that the hazard lights are active from the sending vehicle so that they may react accordingly.
In regards to Claim 3, Lee in view of Park, Zachary, and Khosla teaches the method of Claim 2, and Lee in view of Park, Zachary, and Khosla further teaches wherein the plurality of vehicle events includes a hazard lights event (Khosla, Table 1 – extension data including event flags such as “eventHazardLights”), a disabled vehicle event (Lee, Para. 0168 – “vehicle failure notification” may “be generated as the relay message and transmitted”), and an air bag deployment event (Khosla, Table 1 and Para. 0048 – “deployment of an air bag”, coded as “eventAirBagDeployment”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method including the above limitations of Lee in view of Park, Zachary, and Khosla to further include the plurality of vehicle events includes a hazard lights event and an air bag deployment event, as taught by Khosla, in order to inform the receiving entity that an event which caused an air bag to deploy has occurred or that the hazard lights are active from the sending vehicle so that they may react accordingly.
Regarding Claim 10, Lee teaches: A method for a vehicle (Lee, Para. 0002, 0006 – “a method of transmitting a message associated with a vehicle”), comprising:
monitoring a vehicle for a triggering event (Lee, Para. 0058 and 0164 – acquiring measurement data associated with the vehicle by various sensors, including “measurement data from various sensors such as a speed meter…, an accelerometer…, an azimuth meter…, a brake detector…, a position measuring device…, or a road surface condition detector…”, which are information associated with the vehicle; for example, detecting a sinkhole, which satisfies a condition, or triggering event), wherein the triggering event is selected from a group consisting of a user-initiated vehicle aid request (Lee, Para. 0060 and 0102 – where a processor may receive “an input from a user” to “transmit and receive the communication signal” in a wireless access in vehicular environment scheme that is “included and generated in a basic safety message (BSM)”)
wherein the plurality of vehicle events includes“vehicle failure notification” may “be generated as the relay message and transmitted”),
responsive to detection of the triggering event, generating a Vehicle-to-Everything (V2X) Basic Safety Message (BSM) in accordance with SAE Surface Vehicle Standard J2735 (Lee, Para. 0007, 0058-0060, 0132 – generating transmission data based on received measurement data by a terminal platform, or communication module; where the transmission data is a “basic safety message (BSM)” defined by “society of automotive engineers (SAE) standard (e.g., document J2735)” which includes a relay message; where the message is a V2X message);
processing the V2X BSM to retrieve a where a processor receives the communication signal and “may process the BSM or PSM included in the received communication signal to manage the information included therein”, including the relay message; a basic safety message having a “BSM data part 2 field” which includes “information constituting the relay message”),
responsive to retrieving the where after processing the BSM, “the processor 120 may display, on the display device 160, a content indicating at least one of the movement and location of another vehicle, which is generated based on at least a portion of information included in the BSM received from the other vehicle”, such that the content is determined; where information contained in the BSM is for example vehicle failure information)
While Lee teaches a relay message stored within a BSMpartIIExtension content, and responsive to retrieving the relay message from the BSM, determining a vehicle that generated and transmitted the BSM’s condition, Lee does not teach a vehicle aid request signature stored within a BSMpartIIExtension content, wherein the vehicle aid request signature includes a DE_VehicleEventFlags data element with each of an eventHazardLights flag, an eventDisabledVehicle flag, and an eventAirBagDeployment flag, and retrieving a vehicle aid request signature and determining that a vehicle that generated and transmitted the BSM is requesting aid from an external source based on the eventHazardLights flag, the eventDisabledVehicle flag, and the eventAirBagDeployment flag, wherein the vehicle aid request signature comprises data indicating that the vehicle requests emergency aid from an external source, the method further including the vehicle receiving aid from the external source. Additionally, Lee does not teach the triggering event is selected from a concurrent occurrence of a plurality of vehicle events, wherein the plurality of vehicle events includes a hazard lights flag and an air bag deployment flag.
However, Park teaches a vehicle aid request signature stored within a BSMpartIIExtension content (Park, Para. 0028, 0046-0048 – “a Basic Safety Message (BSM)” including “a Part I message” and an optional “Part II message”, or extension information, the Part II message including “an emergency situation message (SystemFailureSuspectFlag)” and “a release message (SystemFailureRecoveryFlag)” for “request[ing] a rescue from a rescue center”, or external source), and retrieving a vehicle aid request signature and determining that a vehicle that generated and transmitted the BSM is requesting aid from an external source (Park, Para. 0051-0055, 0067 – where “when the emergency situation message and the release message are received, the vehicle that has transmitted the messages can be identified, and in particular, the rescue center 50 can easily identify the vehicle”, for example, in a case where a “surrounding vehicle” is in an emergency situation, a “controller” of a vehicle can identify an “emergency situation of the surrounding vehicle” and transmit the information to “another surrounding vehicle” or the rescue center), wherein the vehicle aid request signature comprises data indicating that the vehicle requests emergency aid from an external source (Park, Para. 0028, 0046-0048 – “a Basic Safety Message (BSM)” including an optional “Part II message” having “an emergency situation message (SystemFailureSuspectFlag)” and “a release message (SystemFailureRecoveryFlag)” for “request[ing] a rescue from a rescue center”, or external source), the method further including the vehicle receiving aid from the external source (Park, Para. 0003, 0054, 0090 – “rapidly inform the emergency situation of the vehicle 105 to the rescue center 150 and provide accurate information, thereby performing an efficient rescue”, i.e. “rapidly rescuing the vehicle”; where the “rescue center” is an institution, or external source, such as “a fire station, a police station, etc., which can control an emergency situation of a vehicle”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Lee to include a vehicle aid request signature stored within a BSMpartIIExtension content, and retrieving a vehicle aid request signature and determining that a vehicle that generated and transmitted the BSM is requesting aid from an external source, wherein the vehicle aid request signature comprises data indicating that the vehicle requests emergency aid from an external source, the method further including the vehicle receiving aid from the external source, as taught by Park, in order to more accurately detect an emergency situation of a vehicle and rapidly rescue the vehicle (Park, Para. 0003).
Lee in view of Park does not teach wherein the vehicle aid request signature includes a DE_VehicleEventFlags data element with each of an eventHazardLights flag, an eventDisabledVehicle flag, and an eventAirBagDeployment flag, determining that a vehicle that generated and transmitted the BSM is requesting aid from an external source based on the eventHazardLights flag, the eventDisabledVehicle flag, and the eventAirBagDeployment flag, and the triggering event is selected from a concurrent occurrence of a plurality of vehicle events.
However, Zachary teaches the triggering event is selected from a concurrent occurrence of a plurality of vehicle events (Zachary, Para. 0083 – “the vehicle 12 can simultaneously detect the occurrence of a plurality of vehicle events”; where the vehicle event is “predefined by one or more conditions pertaining to vehicle states”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have further modified the method including the above limitations of Lee in view of Park to include a concurrent occurrence of a plurality of vehicle events, as taught by Zachary, in order to detect and report multiple vehicle events in a singular message that is transmitted so that the receiving entity can respond accordingly.
Lee in view of Park and Zachary does not teach wherein the vehicle aid request signature includes a DE_VehicleEventFlags data element with each of an eventHazardLights flag, an eventDisabledVehicle flag, and an eventAirBagDeployment flag, and determining that a vehicle that generated and transmitted the BSM is requesting aid from an external source based on the eventHazardLights flag, the eventDisabledVehicle flag, and the eventAirBagDeployment flag.
However, Khosla teaches wherein the vehicle aid request signature includes a DE_VehicleEventFlags data element with each of an eventHazardLights flag, an eventDisabledVehicle flag, and an eventAirBagDeployment flag (Khosla, Table 1 and Para. 0059 – “VehicleSafetyExtensions” including “VehicleEventFlags” which includes flags such as “eventDisabledVehicle”, “eventAirBagDeployment”, and “eventHazardLights”), and determining that a vehicle that generated and transmitted the BSM is requesting aid from an external source based on the eventHazardLights flag, the eventDisabledVehicle flag, and the eventAirBagDeployment flag (Khosla, Table 1, Para. 0047, 0056, 0059, and 0061 – where a “remote vehicle” or “remote entities” may utilize a “certificate list” to identify the host vehicle’s “certificate” when sent a message such as a “BSM with a special flag, indicating that it has been involved in an accident”, where the remote entities may use the BSM content to “assist other entities, e.g., to avoid the area of collision, or to direct the entities to the area of collision (if the entity is a first responder)”; where the BSM includes “VehicleEventFlags” which includes flags such as “eventDisabledVehicle”, “eventAirBagDeployment”, and “eventHazardLights”).
It would have been obvious to one of ordinary skill before the effective filing date of the claimed invention to have further modified the method including the above limitations of Lee in view of Park and Zachary to include wherein the plurality of vehicle events includes wherein the vehicle aid request signature includes a DE_VehicleEventFlags data element with each of an eventHazardLights flag, an eventDisabledVehicle flag, and an eventAirBagDeployment flag, and determining that a vehicle that generated and transmitted the BSM is requesting aid from an external source based on the eventHazardLights flag, the eventDisabledVehicle flag, and the eventAirBagDeployment flag, as taught by Khosla, in order to notify emergency services using V2X basic safety messages in the case where the vehicle does not have cellular network, and to indicate the vehicle events and current vehicle state within the BSM data to inform receiving entities of the sending vehicle’s current state with regard to a certain set of events.
In regards to Claim 11, Lee in view of Park, Zachary, and Khosla teach the method of Claim 10, and Lee in view of Park, Zachary, and Khosla further teaches further comprising: responsive to retrieving the vehicle aid request signature from the BSM, routing data included by the BSM to an external device over a wireless communication network (Lee, Para. 0051 and Claim 27 – receiving “a basic safety message (BSM)” through communication circuitry and transmitting the relay message “to a second external device, which is external” to the current device; where communication circuitry is done over “wireless communication” networks; Khosla, Para. 0061 – an “additional data structure” within “BSM extension data” which includes “source L2 address and verification certificates” which “change periodically and independently”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method including the above limitations of Lee in view of Park, Zachary, and Khosla to include the vehicle aid request signature, as taught by Khosla, in order to verify the identity of the vehicle and verify the data provided within a basic safety message.
In regards to Claim 12, Lee in view of Park, Zachary, and Khosla teaches the method of Claim 11, and Lee further teaches wherein the data routed to the external device (Lee, Claim 27 – transmitting the relay message “to a second external device, which is external” to the current device) includes vehicle location information including vehicle latitude, vehicle longitude, and vehicle elevation (Lee, Para. 0060 – where the BSM includes a latitude, a longitude, and an altitude of the vehicle).
In regards to Claim 13, Lee in view of Park, Zachary, and Khosla teaches the method of Claim 11, and Lee further teaches wherein the external device is a communication unit of a second vehicle (Lee, Para. 0057 and Claim 27 and 30 – where the second external device is a vehicle; where both the first and second vehicles communicate through vehicle communication modules).
In regards to Claim 14, Lee in view of Park, Zachary, and Khosla teaches the method of Claim 11, and Lee further teaches wherein the wireless communication network is a cellular network (Lee, Para. 0051 – including “a wireless communication module 192 (e.g., a cellular communication module)” for communicating by long-range communication networks such as cellular network).
In regards to Claim 15, Lee in view of Park, Zachary, and Khosla teaches the method of Claim 11, and Lee in view of Park, Zachary, and Khosla further teaches wherein the external device is part of an emergency communications control center infrastructure and wherein the infrastructure comprises a transceiver arranged along and/or proximate to a roadway and is configured to receive V2X wireless signals transmitted by vehicles and/or signals transmitted by mobile devices via the transceiver (Park, Para. 0006-0007, 0027-0028, 0040, 0070 – “an emergency situation detecting device 10, which is installed in the vehicle, detects an emergency situation of the vehicle and generates an emergency situation message” to transmit to “a road-side unit, which receive[s] the emergency situation message”, where the road-side unit “is installed on a road side to communicate with the emergency situation detecting device” of the vehicle by receiving “signals” from a communication unit or “V2X technology”).
It would have been obvious to one of ordinary skill before the effective filing date of the claimed invention to have modified the method including the above limitations of Lee in view of Park, Zachary, and Khosla to further include wherein the external device is part of an emergency communications control center infrastructure, as taught by Park, in order to notify both other vehicles and emergency services in the case where the sending vehicle requires assistance.
Regarding Claim 18, Lee teaches: A system (Lee, Para. 0039 – “an operating system”), comprising:
a transceiver (Lee, Para. 0053 – an antenna module for “transmitting or receiving signals” to or from an outside electronic device for communication, such that it acts as a transceiver);
one or more first processors (Lee, Para. 0037 – “the main processor”); and
a first non-transitory memory including instructions (Lee, Para. 0212 – “instructions stored in a non-transitory machine” which “are executed” by a processor) stored thereon that when executed, cause the one or more first processors to:
monitor a condition of a vehicle for a triggering event (Lee, Para. 0058 and 0164 – acquiring measurement data associated with the vehicle by various sensors; for example, detecting a sinkhole, which satisfies a condition, or triggering event) wherein monitoring a condition of a vehicle for a triggering event includes estimating and/or measuring vehicle conditions (Lee, Para. 0058 and 0164 – acquiring measurement data associated with the vehicle by various sensors, including “measurement data from various sensors such as a speed meter…, an accelerometer…, an azimuth meter…, a brake detector…, a position measuring device…, or a road surface condition detector…”, which are information associated with the vehicle; for example, detecting a sinkhole, which satisfies a condition, or triggering event) including where the display “may display [a] graphical object capable of activating whether to transmit and receive the communication signal” according to input from a user; such that the device monitors if transmission is activated and sends signals if it is); and
responsive to detection of the triggering event: generate a Vehicle-to-Everything (V2X) Basic Safety Message (BSM) (Lee, Para. 0007, 0058-0060, 0132 – generating transmission data based on received measurement data by a terminal platform, or communication module, which includes a relay message; where the transmission data is a “basic safety message (BSM)” that is a V2X message) including a vehicle aid request where vehicle location information is stored in the BSM data part 1 field while a relay message is stored within the BSM data part 2 field; such that the location information and extension information are stored separately),
and wherein monitoring the condition of the vehicle for the triggering event includes monitoring a vehicle hazard lights event flag, a disabled vehicle event flag (Lee, Para. 0168 – “vehicle failure notification” may “be generated as the relay message and transmitted”), and an air bag deployment event flag, and detecting the triggering event includes determining that the each of the vehicle hazard lights event flag, the disabled vehicle event flag, and the air bag deployment event flag is in an ON condition, and wherein the vehicle aid request signature comprises data indicating that the vehicle requests emergency aid from an external source.
While Lee teaches generate a Vehicle-to-Everything (V2X) Basic Safety Message (BSM) including a message, but Lee does not teach a Basic Safety Message (BSM) including a vehicle aid request signature. Additionally, Lee does not teach determining a condition of one or more airbags of the vehicle, determining a condition of hazard lights of the vehicle, and determining a condition of a power source and/or a fuel level of the vehicle, and wherein monitoring the condition of the vehicle for the triggering event includes monitoring a vehicle hazard lights event flag and an air bag deployment event flag, and detecting the triggering event includes determining that the each of the vehicle hazard lights event flag, the disabled vehicle event flag, and the air bag deployment event flag is in an ON condition, and wherein the vehicle aid request signature comprises data indicating that the vehicle requests emergency aid from an external source.
However, Park teaches a Basic Safety Message (BSM) including a vehicle aid request signature, wherein the vehicle aid request signature comprises data indicating that the vehicle requests emergency aid from an external source (Park, Para. 0028, 0046-0048, 0054-0055, 0067 – “a Basic Safety Message (BSM)” including “a Part I message” and an optional “Part II message”, or extension information, the Part II message including “an emergency situation message (SystemFailureSuspectFlag)” and “a release message (SystemFailureRecoveryFlag)” for “request[ing] a rescue from a rescue center”, or external source; where “when the emergency situation message and the release message are received, the vehicle that has transmitted the messages can be identified, and in particular, the rescue center 50 can easily identify the vehicle”, where the “rescue center” is an institution, or external source, such as “a fire station, a police station, etc., which can control an emergency situation of a vehicle”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method of Lee to include a Basic Safety Message (BSM) including a vehicle aid request signature, wherein the vehicle aid request signature comprises data indicating that the vehicle requests emergency aid from an external source, as taught by Park, in order to more accurately detect an emergency situation of a vehicle and rapidly rescue the vehicle (Park, Para. 0003).
Lee in view of Park does not teach determining a condition of one or more airbags of the vehicle, determining a condition of hazard lights of the vehicle, and determining a condition of a power source and/or a fuel level of the vehicle, and wherein monitoring the condition of the vehicle for the triggering event includes monitoring a vehicle hazard lights event flag and an air bag deployment event flag, and detecting the triggering event includes determining that the each of the vehicle hazard lights event flag, the disabled vehicle event flag, and the air bag deployment event flag is in an ON condition.
However, Zachary teaches determining a condition of a power source (Zachary, Para. 0037 – “obtain vehicle sensor information of the vehicle engine”, or power source, “from engine speed sensor 62, engine temperature sensor 64, and engine ignition timing sensor 66”, relating to the condition of the vehicle engine) and/or a fuel level of the vehicle.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have further modified the system including the above limitations of Lee in view of Park to include determining a condition of a power source, as taught by Zachary, in order to determine a state of a power source, which may be related to an event, such as a collision.
Lee in view of Park and Zachary does not teach determining a condition of one or more airbags of the vehicle, determining a condition of hazard lights of the vehicle, and determining a condition of a power source and/or a fuel level of the vehicle, and wherein monitoring the condition of the vehicle for the triggering event includes monitoring a vehicle hazard lights event flag and an air bag deployment event flag, and detecting the triggering event includes determining that the each of the vehicle hazard lights event flag, the disabled vehicle event flag, and the air bag deployment event flag is in an ON condition.
However, Khosla teaches determining a condition of one or more airbags of the vehicle (Khosla, Table 1 and Para. 0048 – “a sensor that detects deployment of an air bag”, coded as “eventAirBagDeployment”), determining a condition of hazard lights of the vehicle (Khosla, Table 1 and Para. 0059 – collecting extension data including event flags such as “eventHazardLights”, where the event flags are information collected by vehicles to send as collision related information), a Basic Safety Message (BSM) including a vehicle aid request signature (Khosla, Para. 0061 – an “additional data structure” within “BSM extension data” which includes “source L2 address and verification certificates” which “change periodically and independently”) and wherein monitoring the condition of the vehicle for the triggering event includes monitoring a vehicle hazard lights event flag and an air bag deployment event flag, and detecting the triggering event includes determining that the each of the vehicle hazard lights event flag, the disabled vehicle event flag, and the air bag deployment event flag is in an ON condition (Khosla, Table 1 and Para. 0059-0061 – extension data including event flags such as “eventHazardLights”, “vehicle failure notification” may “coded as eventDisabledVehicle” and “deployment of an air bag”, coded as “eventAirBagDeployment”; where the relevant flags are included in a BSM if relevant to a vehicle in a collision).
It would have been obvious to one of ordinary skill before the effective filing date of the claimed invention to have further modified the system including the above limitations of Lee in view of Park and Zachary to include determining a condition of one or more airbags of the vehicle and determining a condition of hazard lights of the vehicle, and a Basic Safety Message (BSM) including a vehicle aid request signature and wherein monitoring the condition of the vehicle for the triggering event includes monitoring an air bag deployment event flag, as taught by Khosla, in order to notify emergency services using V2X basic safety messages in the case where the vehicle does not have cellular network in order to indicate and verify the vehicle events and current vehicle state within the BSM data to inform receiving entities of the sending vehicle’s current state with regard to a certain set of events.
Regarding Claim 19, Lee in view of Park, Zachary, and Khosla teaches the system of Claim 18, and Lee in view of Park, Zachary, and Khosla further teaches further comprising:
a receiver (Lee, Para. 0053 – an antenna module for “transmitting or receiving signals” to or from an outside electronic device for communication);
one or more second processors electronically coupled to the receiver (Lee, Para. 0074 and 0084 – a processor for controlling the electronic device containing the antenna module; where there is an auxiliary processor, or second processor); and
a second non-transitory memory including instructions stored thereon that when executed (Lee, Para. 0074 and 0212 – “instructions stored in a non-transitory machine” which “are executed” by a processor; where instructions are executed by the processor in connection w the antenna module), cause the one or more second processors to:
responsive to receiving the BSM via the receiver (Lee, Para. 0078 – where a vehicle, via a communication module and antenna module, “may receive the communication signal including the BSM… from other entities”), process the BSM to retrieve the vehicle aid request signature (Lee, Para. 0007 and 0058-0060 – a BSM including a relay message; Park, Para. 0028, 0046-0048 – “a Basic Safety Message (BSM)” including “an emergency situation message (SystemFailureSuspectFlag)” and “a release message (SystemFailureRecoveryFlag)” for “request[ing] a rescue from a rescue center”) and the vehicle location information via the one or more second processors (Lee, Para. 0078 and 0084-0087 – where the auxiliary processor receives the communication signal and “the auxiliary processor 123 may process the BSM or PSM included in the received communication signal to manage the information included therein”; where the processor carries out operations according to the relay message and location of another vehicle relayed by the BSM).
Regarding Claim 20, Lee in view of Park, Zachary, and Khosla teaches the method of Claim 18, and Lee in view of Park, Zachary, and Khosla further teaches wherein the plurality of vehicle events includes an air bag deployment event (Khosla, Table 1 and Para. 0048 – “deployment of an air bag”, coded as “eventAirBagDeployment”), a hazard lights event (Khosla, Table 1 – extension data including event flags such as “eventHazardLights”), and a disabled vehicle event (Lee, Para. 0168 – “vehicle failure notification” may “be generated as the relay message and transmitted”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system including the above limitations of Lee in view of Park, Zachary, and Khosla to further include the plurality of vehicle events includes an air bag deployment event, and a disabled vehicle event, as taught by Khosla, in order to inform the receiving entity that an event which caused an air bag to deploy has occurred or that the hazard lights are active from the sending vehicle so that they may react accordingly.
Regarding Claim 21, Lee in view of Park and Zachary teaches the method of Claim 1, but Lee in view of Park and Zachary does not teach wherein the vehicle aid request signature includes a DE_VehicleEventFlags data element with each of an eventHazardLights flag, an eventDisabledVehicle flag, and an eventAirBagDeployment flag being set to indicate that the vehicle requests aid.
However, Khosla teaches wherein the vehicle aid request signature includes a DE_VehicleEventFlags data element with each of an eventHazardLights flag, an eventDisabledVehicle flag, and an eventAirBagDeployment flag being set to indicate that the vehicle requests aid (Khosla, Table 1, Para. 0047, 0056, 0059, and 0061 – where a “remote vehicle” or “remote entities” may utilize a “certificate list” to identify the host vehicle’s “certificate” when sent a message such as a “BSM with a special flag, indicating that it has been involved in an accident”, where the remote entities may use the BSM content to “assist other entities, e.g., to avoid the area of collision, or to direct the entities to the area of collision (if the entity is a first responder)”; where the BSM includes “VehicleEventFlags” which includes flags such as “eventDisabledVehicle”, “eventAirBagDeployment”, and “eventHazardLights”).
It would have been obvious to one of ordinary skill before the effective filing date of the claimed invention to have further modified the method including the above limitations of Lee in view of Park and Zachary to include wherein the vehicle aid request signature includes a DE_VehicleEventFlags data element with each of an eventHazardLights flag, an eventDisabledVehicle flag, and an eventAirBagDeployment flag being set to indicate that the vehicle requests aid, as taught by Khosla, in order to inform receiving entities of the sending vehicle’s current state with regard to a certain set of events.
Claims 5-8 are rejected under 35 U.S.C. 103 as being unpatentable over Lee in view of Park and Zachary, and further in view of SAE International ("Surface Vehicle Standard - (R) V2X Communications Message Set Dictionary", SAE International, J2735, Issued 2006, Revised 2020).
In regards to Claim 5, Lee in view of Park and Zachary teaches the method of Claim 4, and Lee in view of Park and Zachary teach the vehicle aid request signature (Park, Para. 0028, 0046-0048 – “a Basic Safety Message (BSM)” including a “Part II message”, or extension information, the Part II message including “an emergency situation message (SystemFailureSuspectFlag)” and “a release message (SystemFailureRecoveryFlag)” for “request[ing] a rescue from a rescue center”) but Lee in view of Park and Zachary do not teach wherein the signature includes a DF_EventDescription data frame with an EXT_ITIS_Codes data element having an ITIS code with a value of 4364.
However SAE International teaches wherein the signature includes a DF_EventDescription data frame with an EXT_ITIS_Codes data element having an ITIS code (SAE International, Page 56-57 and 102 – a data frame DF_EventDescription which provides a short summary of an event or incident, which can be included in a BSM; where the data frame includes ITIS codes which categorize events) having an ITIS code with a value of 4364 (SAE International, Page 56-57 and 240 – where the EventDescription data frame includes ITIS codes to explain the type of alert/danger/hazard involved; where the ITIS codes are an integer between the numbers 0 to 65535 indicating common vehicle events, such that the ITIS code can be 4364 and is listed in SAE J2540).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have further modified the method including the above limitations of Lee in view of Park and Zachary to include wherein the signature includes a DF_EventDescription data frame with an EXT_ITIS_Codes data element having an ITIS code, as taught by SAE International, in order to include the data elements necessary within a basic safety message to inform receiving entities of a specific event or driving action the sending device is taking or is about to take.
In regards to Claim 6, Lee in view of Park, Zachary, and SAE International teaches the method of Claim 5, and Lee in view of Park, Zachary, and SAE International further teaches wherein the DF_EventDescription data frame is part of a DF_SpecialVehicleExtensions data frame (SAE International, Page 102 – a DF_SpecialVehicleExtensions data frame which is part of the BSM Part II data including the EventDescription data frame as part of its sequence).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method including the above limitations of Lee in view of Park, Zachary, and SAE International to further include wherein the DF_EventDescription data frame is part of a DF_SpecialVehicleExtensions data frame, as taught by SAE International, in order to structure the data frame hierarchies within the basic safety message according to the SAE standard to indicate various additional optional information elements within the message in a way that is processable by receiving entities following the same standard.
In regards to Claim 7, Lee in view of Park and Zachary teaches the method of Claim 4, and Lee in view of Park and Zachary teach the vehicle aid request signature (Park, Para. 0028, 0046-0048 – “a Basic Safety Message (BSM)” including a “Part II message”, or extension information, the Part II message including “an emergency situation message (SystemFailureSuspectFlag)” and “a release message (SystemFailureRecoveryFlag)” for “request[ing] a rescue from a rescue center”), but Lee in view of Park and Zachary does not teach wherein the vehicle aid request signature includes a DE_VehicleEventFlags data element with each of an eventHazardLights flag, an eventDisabledVehicle flag, and an eventAirBagDeployment flag being set; and wherein the vehicle aid request signature includes a DF_DisabledVehicle data frame having an ITIS code with a value of between 532 and 541.
However, SAE International teaches wherein the vehicle aid request signature includes a DE_VehicleEventFlags data element with each of an eventHazardLights flag, an eventDisabledVehicle flag, and an eventAirBagDeployment flag being set (SAE International, Page 208-209 – “Data Element: DE_VehicleEventFlags”, where each flag is set “to one if the stated criteria are met”, the flags including “eventHazardLights”, “eventDisabledVehicle”, and “eventAirBagDeployment”); and wherein the vehicle aid request signature includes a DF_DisabledVehicle data frame having an ITIS code with a value of between 532 and 541 (SAE International, Page 55 – where the DF_DisabledVehicle data frame uses a subset of ITIS codes from 532 to 541 as a means for a vehicle to “describe its operational status and gross location”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have further modified the method including the above limitations of Lee in view of Park and Zachary to include wherein the vehicle aid request signature includes a DE_VehicleEventFlags data element with each of an eventHazardLights flag, an eventDisabledVehicle flag, and an eventAirBagDeployment flag being set; and wherein the vehicle aid request signature includes a DF_DisabledVehicle data frame having an ITIS code with a value of between 532 and 541, as taught by SAE International, in order to indicate the vehicle events and current vehicle state within the BSM data to inform receiving entities of the sending vehicle’s current state with regard to a certain set of events.
In regards to Claim 8, Lee in view of Park, Zachary, and SAE International teaches the method of Claim 7, and Lee in view of Park, Zachary, and SAE International further teaches wherein the DE_VehicleEventFlags data element is part of a DF_VehicleSafetyExtensions data frame (SAE International, Page 112 – where the “VehicleEventFlags” element is within the “DF_VehicleSafetyExtensions data frame”); and wherein the DF_DisabledVehicle data frame is part of a DF_SupplementalVehicleExtensions data frame (SAE International, Page 104 – where the “DisabledVehicle” data element is within the data frame of SupplementalVehicleExtensions).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the method including the above limitations of Lee in view of Khosla and SAE International to further include wherein the DE_VehicleEventFlags data element is part of a DF_VehicleSafetyExtensions data frame; and wherein the DF_DisabledVehicle data frame is part of a DF_SupplementalVehicleExtensions data frame, as taught by SAE International, in order to structure the data frame hierarchies within the basic safety message according to the SAE standard to indicate various vehicle events in a way that is processable by receiving entities following the same standard.
Claims 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Lee in view of Park, Zachary, and Khosla, and further in view of SAE International.
In regards to Claim 16, Lee in view of Park, Zachary, and Khosla teaches the method of Claim 10, and Lee in view of Park, Zachary, and Khosla teaches the vehicle aid request signature (Lee, Para. 0007 and 0058-0060 – a BSM including a relay message; Khosla, Para. 0061 – an “additional data structure” within “BSM extension data” which includes “source L2 address and verification certificates” which “change periodically and independently”) but Lee in view of Park, Zachary, and Khosla do not teach wherein the signature includes a DF_EventDescription data frame with an EXT_ITIS_Codes data element having an ITIS code with a value of 4364.
However SAE International teaches wherein the signature includes a DF_EventDescription data frame with an EXT_ITIS_Codes data element having an ITIS code (SAE International, Page 56-57 and 102 – a data frame DF_EventDescription which provides a short summary of an event or incident, which can be included in a BSM; where the data frame includes ITIS codes which categorize events) having an ITIS code with a value of 4364 (SAE International, Page 56-57 and 240 – where the EventDescription data frame includes ITIS codes to explain the type of alert/danger/hazard involved; where the ITIS codes are an integer between the numbers 0 to 65535 indicating common vehicle events, such that the ITIS code can be 4364 and is listed in SAE J2540).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have further modified the method including the above limitations of Lee in view of Park, Zachary, and Khosla to include wherein the signature includes a DF_EventDescription data frame with an EXT_ITIS_Codes data element having an ITIS code, as taught by SAE International, in order to include the data elements necessary within a basic safety message to inform receiving entities of a specific event or driving action the sending device is taking or is about to take.
In regards to Claim 17, Lee in view of Park, Zachary, and Khosla teaches the method of Claim 10, and Lee in view of Park, Zachary, and Khosla teaches wherein the vehicle aid request signature includes a DE_VehicleEventFlags data element with each of an eventHazardLights flag, an eventDisabledVehicle flag, and an eventAirBagDeployment flag being set (Khosla, Table 1 and Para. 0059 – “VehicleSafetyExtensions” including “VehicleEventFlags” which includes flags such as “eventDisabledVehicle”, “eventAirBagDeployment”, and “eventHazardLights”); but Lee in view of Park, Zachary, and Khosla does not teach wherein the vehicle request signature includes a DF_DisabledVehicle data frame having an ITIS code with a value of between 532 and 541.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have further modified the method including the above limitations of Lee in view of Park, Zachary, and Khosla to further include wherein the signature includes a DE_VehicleEventFlags data element with each of an eventHazardLights flag, an eventDisabledVehicle flag, and an eventAirBagDeployment flag being set, as taught by Khosla, in order to indicate the vehicle events and current vehicle state within the BSM data to inform receiving entities of the sending vehicle’s current state with regard to a certain set of events.
However, SAE International teaches wherein the vehicle aid request signature includes a DF_DisabledVehicle data frame having an ITIS code with a value of between 532 and 541 (SAE International, Page 55 – where the DF_DisabledVehicle data frame uses a subset of ITIS codes from 532 to 541 as a means for a vehicle to “describe its operational status and gross location”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have further modified the method including the above limitations of Lee in view of Park, Zachary, and Khosla to further include wherein the vehicle aid request signature includes a DF_DisabledVehicle data frame having an ITIS code with a value of between 532 and 541, as taught by SAE International, in order to indicate the vehicle events and current vehicle state within the BSM data to inform receiving entities of the sending vehicle’s current state with regard to a certain set of events.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Wendt, et al. (U.S. Patent Application Pub. No. 2024/0185717) teaches systems, devices, and methods for analyzing object data to determine one or more safety risks and transmitting one or more alerts or safe routes based on the one or more safety risks.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HELEN LI whose telephone number is (703)756-4719. The examiner can normally be reached Monday through Friday, from 9am to 5pm eastern.
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, Hunter Lonsberry can be reached at (571) 272-7298. 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.
/H.L./Examiner, Art Unit 3665
/HUNTER B LONSBERRY/Supervisory Patent Examiner, Art Unit 3665
Prosecution Insights