DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis 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.
Claims 11-27 are rejected under 35 U.S.C. 103 as being unpatentable over US 20200029266 A1 (HATA) in view of US 20170374538 A1 (Gellens et al.) (hereinafter Gellens).
In re claims 11 and 19, HATA discloses a method of sending an emergency call from a vehicle (Fig. 6, [0012], “The present disclosure is to provide a radio communication equipment and a control method thereof that can appropriately deal with the case in which a vehicle emergency call system is not normally operated when the radio communication equipment originates to an emergency call center”. [0003], “Nowadays, an emergency call system for vehicles called ERA-GLONASS is implemented in Russia. In Europe, the implementation of an emergency call system for vehicles called eCall is scheduled in future. The vehicle emergency call system is a system that automatically makes a report to a nearest police department or fire department through an emergency call center in an emergency, such as a vehicular accident”), comprising: by a controller of the vehicle comprising: a computer processor configured to execute a process including (Fig. 2:13, [0027], “The controller 13 is mainly configured of a microcomputer formed of a central processing unit (CPU) that executes various programs...The controller 13 executes processes necessary to control the radio communicator 12”), automatically establishing a first connection to a coordination center server, after an accident involving the vehicle (Fig. 3: S2, [0038], “An emergency event may be automatically generated when the sensor installed on the vehicle 20 detects an emergency”. [0005], “A radio communication equipment of the present application is a radio communication equipment installed on a vehicle, which comprises a radio communicator configured to perform radio communication with a network, and a controller configured to perform call origination to a public safety answering point (PSAP) via the network, wherein the controller is configured to perform first call origination to the PSAP upon occurrence of an emergency” (coordination center server may be a PSAP), and sending an emergency call via the first connection to the coordination center server ([0036], “The controller 13 makes emergency call origination as an emergency call process via the network”. [0038], “An emergency is, for example, a traffic accident or an accident or injury to the user of the radio communication module 10, but is not limited to an accident or injury in particular”. [0039], “The controller 13 originates an outgoing call for an emergency to the PSAP 7 (step S2)”); receiving, by the coordination center server, the emergency call and sending a message indicating a failure of the received emergency call to the controller (Fig. 5: S4, [0053], “When there is an abnormality in call upon call origination in step S2, the radio communication module 10 receives a notification of an emergency call failure from the network 8 (step S4)”), if the emergency call is not successfully received by an agent of the coordination center server ([0039], “In general, when an emergency call succeeds, the driver or another person of the vehicle 20 can talk with the operator of the PSAP 7” (implicitly disclosed that emergency call does not succeed is interpreted as not successfully received by the operator of the call center such as bad reception); and receiving, by the controller the message and, after an end of the first connection, automatically establishing a second connection to the coordination center server that is separate from the first connection (Fig. 6:S22, [0044], “The controller 13 then originates an outgoing call to the PSAP by a scheme different from that used for call origination in step S2 (step S13)”. [0046], “When telephone companies respectively provide lines to the PSAP, the radio communication module 10 can switch the lines provided by the telephone companies by using SIM cards for the respective telephone companies”. [0047], “In another example, the radio communicator 12 has two Radio Access Technologies (RATs), for example, GSM (registered trademark) and CDMA or GSM (registered trademark) and LTE. For example, call origination in step S2 is performed by using GSM (registered trademark), and call origination in step S13 is performed by using CDMA or LTE”. [0049], “In still another example, the PSAP to which call origination in step S2 is performed may differ from the PSAP to which call origination in step S13 is performed. For example, call origination in step S2 uses a telephone number different from that used for call origination in step S13” (use a second connection different than the first when first connection fails)).
HATA does not explicitly disclose sending an emergency call via the first connection to the coordination center server; receiving, by the coordination center server, the emergency call and sending a message indicating a failure of the received emergency call to the controller; and receiving, by the controller the message and, after an end of the first connection, automatically establishing a second connection to the coordination center server that is separate from the first connection.
Gellens discloses sending an emergency call via the first connection to the coordination center server (Fig. 17:1705, [0234], “FIG. 17 shows a flowchart illustrating a method 1700 for eCall Over-the-Top in accordance with various aspects of the present disclosure”. [0075], ‘There may be various types of emergency call systems that can support automatic or manually initiated emergency calls from a vehicle”. [0006], “A wireless device, such as an in-vehicle system (IVS), may transmit an emergency call message to a third-party emergency call server (Fig. 1:150) using a communication session” ...The third-party emergency call server (coordination center server) may then relay the emergency call to a public safety answering point (PSAP)”. [0235], “At block 1705, a terminal 110 may initiate a PS connection (first connection) with a third-party emergency call server (e.g., an eCall server 205). When initiating the PS connection, the terminal 110 may transmit a first signaling message (e.g., a SIP INVITE) to the third-party emergency call server” (sending emergency call over a first connection to the coordination center server)); receiving, by the coordination center server, the emergency call and sending a message indicating a failure of the received emergency call to the controller (Fig. 17:1715, [0234], “For example, the operations of method 1700 may be performed by the eCall module 410 as described with reference to FIGS. 4-7”. [0236], “At block 1710, the terminal 110 may receive a second signaling message using the communication session over the PS connection. The second signaling message may include metadata based on a reception status or a content of the set of telematics data transmitted in the first signaling message” (based on the received data, the server sends a second signaling message). [0133], “In some embodiments, the communication session may not be implemented—e.g., may not be agreed by eCall server 205-e at step 334, may not be successfully established for other reasons or may be successfully established but may later fail due to inadequate bandwidth or lack of other resources” (indication of a failure of the received call). [0135], “or that the PS connection has been terminated by the eCall server 205-e (e.g., because the PS connection was initiated without media data, or because the PS connection does not support a threshold quality or bandwidth)” (indication of failure of received call by the server)); and receiving, by the controller the message (Fig. 17:1710, [0236], “At block 1710, the terminal 110 may receive a second signaling message using the communication session over the PS connection. The second signaling message may include metadata based on a reception status or a content of the set of telematics data transmitted in the first signaling message”) and, after an end of the first connection, automatically establishing a second connection to the coordination center server that is separate from the first connection (Fig. 17:1725, [0237], “At block 1715, the terminal 110 may determine that a VoIP call between the terminal 110 and the third party emergency call server cannot be established, that the PS connection has failed, that the PS connection does not support a threshold quality or bandwidth for a VoIP call (e.g., that the PS connection lacks a threshold quality (e.g., QoS, packet loss, latency, or bandwidth)), or that the PS connection has been terminated (e.g., because the PS connection was initiated without media data, or because the PS connection does not support a threshold quality or bandwidth)”. [0239], “At block 1725, and when the telematics data was not received by the third-party emergency call server at block 1705, the terminal 110 may optionally transmit the telematics data to the third-party emergency call server or PSAP using a communication session over the CS connection”. [0233], “In scenarios in which the terminal 110 is unable to establish a prior PS connection with the third-party emergency call server, the CS connection between the terminal 110 and the third-party emergency call server may be initiated by the terminal 110”. [0232], “At block 1605, a terminal 110 may determine that a VoIP call between the terminal 110 and a third party emergency call server (e.g., an eCall server 205) cannot be established, that a PS connection with the third party emergency call server has failed, that the PS connection does not support a threshold quality or bandwidth for a VoIP call (e.g., that the PS connection lacks a threshold quality (e.g., QoS, packet loss, latency, or bandwidth)), or that the PS connection has been terminated (e.g., because the PS connection was initiated without media data, or because the PS connection does not support the threshold quality or bandwidth)”. [0233], “[0233], “At block 1610, the terminal 110 may establish a CS connection between the terminal 110 and the third-party emergency call server or a PSAP. The CS connection may be established for voice or media data, and may be established subsequent to the determination made at block 1605” (establishing a second connection after a first connection failed, switching to circuit switched from packet switched)).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of HATA with Gellens to provide an automatic emergency call system and method for originating emergency communications from a vehicle telematics to a remote coordination call center. The advantage of integrating the intelligent system in the vehicle telematics with information technology can automate various processes associated with using the vehicle such as establishing connection with the first responder units without delay during emergency.
In re claims 12 and 21, the combination discloses the method as claimed in claim 11 and the controller as claimed in claim 19, wherein Gellens discloses the coordination center server sends the message indicating the failure of the emergency call to the controller before ending the first connection or after ending the first connection ([0233], “In scenarios in which the terminal 110 is able to establish a prior PS connection with the third party emergency call server, but a VoIP call cannot be established or maintained between the terminal 110 and the third party emergency call server or lacks sufficient media quality (e.g., due to high loss, latency, etc.), or the PS connection fails, or does not support a threshold quality or bandwidth for a VoIP call, or has been terminated, the CS connection between the terminal 110 and the third party emergency call server may be initiated by a voice call-back from the third party emergency call server” (indication of failure of a first connection that cannot be established or maintained through a voice call back from the server after ending the first connection)).
In re claims 13 and 22, the combination discloses the method as claimed in claim 12 and the controller as claimed in claim 19, wherein Gellens discloses the coordination center server sends the message indicating the failure of the emergency call to the controller as an SMS message (Fig. 3E, 380, [0150], “For one alternative way of transmitting the telematics data, at step 372, the eCall server 205-g may transmit to the terminal 110-g a Short Message Service (SMS) message requesting the telematics data (referred to as MSD in FIG. 3E). At step 374 (in response to the SMS message or proactively), the terminal 110-g may optionally transmit the MSD to the eCall server 205-g, over the CS connection, using SMS”).
In re claims 14 and 23, the combination discloses the method as claimed in claim 11 and the controller as claimed in claim 19, wherein Gellens discloses the first connection is established as a digital VolP connection ([0017], “The radio communication module 10 may be configured to originate an outgoing call or receive an incoming call by using an IP telephone based on Voice over Internet Protocol (VoIP) or the like”), and the coordination center server sends the message indicating the failure of the emergency call to the controller as a VolP reply code before ending the first connection ([0238], “At block 1720, the terminal 110 may receive a voice call-back from the third party emergency call server (or from a PSAP with which the third party emergency call server communicates), for establishing a CS connection with the third party emergency call server (or PSAP)”).
In re claims 15 and 24, the combination discloses the method as claimed in claim 11 and the controller as claimed in claim 19, wherein Gellens discloses the first connection is established as an analog voice connection, and the coordination center server sends the message indicating the failure of the emergency call to the controller as an in-band command before ending the first connection ([0251], “At block 1915, the terminal 110 may receive an in-band eCall request from the third-party emergency call server, over the CS connection, to pull telematics data (e.g., an MSD) from the terminal 110”).
In re claims 16 and 25, the combination discloses the method as claimed in claim 11 and the controller as claimed in claim 19, wherein Gellens discloses the coordination center server forwards the received emergency call to a backend server ([0016], “In some examples the call server is different than the third-party emergency call server”. [0021], “In some examples the third-party emergency call server is configured to relay communication from the wireless device to a public safety answering point (PSAP)”. [0082], “In another example, the IVS may send the call to a SIP Proxy server in a serving wireless network or to a third-party SIP proxy server for onward routing to an OTT eCall server” (here the OTT server could be the backend server)).
In re claims 17 and 26, the combination discloses the method as claimed in Claim 11, and the controller as claimed in claim 19, wherein Gellens discloses the emergency call is simultaneously sent via a data channel of the first connection that differs from a voice channel of the first connection ([0074], “During an emergency call, a single connection between an IVS (in vehicle system) and a PSAP may carry both voice and data related to a crash...The format of the data and contents conveyed by an emergency call may be standardized such that an IVS may place a recognized emergency call and transmit within that call a set of crash related (or other emergency related) data, a location”).
In re claims 18 and 27, the combination discloses the method as claimed in Claim 11 and the controller as claimed in claim 19, wherein Gellens discloses a legal coordination center server or a private coordination center server serves as the coordination center server ([0074], “According to the present disclosure, in some communication environments, the emergency call may be relayed by a third party (e.g., a national automotive club such as the China Automobile Association (CAA) in China), which may act as an intermediary between the IVS (in vehicle system) and the PSAP”. [0092], “Central service 160 may be responsible for answering emergency calls and may also be referred to as an Emergency Center (EC) or a public safety answering point (PSAP)... In some cases, eCall server 150 may be a private service operated by or affiliated with an automobile manufacturer, association, or other organization” (PSAP may be interpreted as a legal coordination center and CAA may be interpreted as a private coordination center)).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over US 20170374538 A1 (Gellens et al.) (hereinafter Gellens) in view of US 20200029266 A1 (HATA).
In re claim 20, Gellens discloses a coordination center server (Fig. 11, [0206], “System 1100 may include eCall server 205-h”), comprising: a computer processor (Fig. 11:1105, [0210], “The eCall server 205-h may include a processor module 1105, memory 1115 (including software (SW) 1120), and transceiver module 1135, which each may be in communication, directly or indirectly, with one another (e.g., over bus system 1145)”) configured to execute a process including, establishing a first connection to a controller of a vehicle, after an accident involving the vehicle; receiving an emergency call via the first connection (Fig. 17:1705, [0234], “FIG. 17 shows a flowchart illustrating a method 1700 for eCall Over-the-Top in accordance with various aspects of the present disclosure”. [0075], ‘There may be various types of emergency call systems that can support automatic or manually initiated emergency calls from a vehicle”. [0006], “A wireless device, such as an in-vehicle system (IVS), may transmit an emergency call message to a third-party emergency call server (Fig. 1:150) using a communication session” ...The third-party emergency call server (coordination center server) may then relay the emergency call to a public safety answering point (PSAP)”. [0235], “At block 1705, a terminal 110 may initiate a PS connection (first connection) with a third-party emergency call server (e.g., an eCall server 205). When initiating the PS connection, the terminal 110 may transmit a first signaling message (e.g., a SIP INVITE) to the third-party emergency call server” (sending emergency call over a first connection to the coordination center server)); sending a message indicating a failure of the emergency call (Fig. 17:1715, [0234], “For example, the operations of method 1700 may be performed by the eCall module 410 as described with reference to FIGS. 4-7”. [0236], “At block 1710, the terminal 110 may receive a second signaling message using the communication session over the PS connection. The second signaling message may include metadata based on a reception status or a content of the set of telematics data transmitted in the first signaling message” (based on the received data, the server sends a second signaling message). [0133], “In some embodiments, the communication session may not be implemented—e.g., may not be agreed by eCall server 205-e at step 334, may not be successfully established for other reasons or may be successfully established but may later fail due to inadequate bandwidth or lack of other resources” (indication of a failure of the received call). [0135], “or that the PS connection has been terminated by the eCall server 205-e (e.g., because the PS connection was initiated without media data, or because the PS connection does not support a threshold quality or bandwidth)” (indication of failure of the emergency call by the server)), if the emergency call is not successfully received by an agent of the coordination center server; and establishing a second connection to the controller that is separate from the first connection (Fig. 17:1725, [0237], “At block 1715, the terminal 110 may determine that a VoIP call between the terminal 110 and the third party emergency call server cannot be established, that the PS connection has failed, that the PS connection does not support a threshold quality or bandwidth for a VoIP call (e.g., that the PS connection lacks a threshold quality (e.g., QoS, packet loss, latency, or bandwidth)), or that the PS connection has been terminated (e.g., because the PS connection was initiated without media data, or because the PS connection does not support a threshold quality or bandwidth)”. [0239], “At block 1725, and when the telematics data was not received by the third-party emergency call server at block 1705, the terminal 110 may optionally transmit the telematics data to the third-party emergency call server or PSAP using a communication session over the CS connection”. [0233], “In scenarios in which the terminal 110 is unable to establish a prior PS connection with the third-party emergency call server, the CS connection between the terminal 110 and the third-party emergency call server may be initiated by the terminal 110”. [0232], “At block 1605, a terminal 110 may determine that a VoIP call between the terminal 110 and a third party emergency call server (e.g., an eCall server 205) cannot be established, that a PS connection with the third party emergency call server has failed, that the PS connection does not support a threshold quality or bandwidth for a VoIP call (e.g., that the PS connection lacks a threshold quality (e.g., QoS, packet loss, latency, or bandwidth)), or that the PS connection has been terminated (e.g., because the PS connection was initiated without media data, or because the PS connection does not support the threshold quality or bandwidth)”. [0233], “[0233], “At block 1610, the terminal 110 may establish a CS connection between the terminal 110 and the third-party emergency call server or a PSAP. The CS connection may be established for voice or media data, and may be established subsequent to the determination made at block 1605” (establishing a second connection different from the first with the controller)).
Gellens does not explicitly disclose establishing a first connection to a controller of a vehicle and if the emergency call is not successfully received by an agent of the coordination center server.
HATA discloses establishing a first connection to a controller of a vehicle (Fig. 3: S2, [0038], “An emergency event may be automatically generated when the sensor installed on the vehicle 20 detects an emergency”. [0005], “A radio communication equipment of the present application is a radio communication equipment installed on a vehicle, which comprises a radio communicator configured to perform radio communication with a network, and a controller configured to perform call origination to a public safety answering point (PSAP) via the network, wherein the controller is configured to perform first call origination to the PSAP upon occurrence of an emergency” (establishing first connection with the controller upon occurrence of emergency) and if the emergency call is not successfully received by an agent of the coordination center server ([0039], “In general, when an emergency call succeeds, the driver or another person of the vehicle 20 can talk with the operator of the PSAP 7” (implicitly disclosed that emergency call does not succeed is interpreted as not successfully received by the operator of the call center such as a bad reception)).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gellens with HATA to provide an automatic emergency call system and method for originating emergency communications from a vehicle telematics to a remote coordination call center. The advantage of integrating the intelligent system in the vehicle telematics with information technology can automate various processes associated with using the vehicle such as establishing connection with the first responder units without delay during emergency.
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SWATI JAIN whose telephone number is (571)270-0699. The examiner can normally be reached Mon - Fri (830 am - 530 pm).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Pan Yuwen can be reached on 571-272-7855. 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.
/SWATI JAIN/Examiner, Art Unit 2649
Prosecution Insights