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
Claims 1-20 have been examined.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1,3-10,12-14,16-17,20 of U.S. Patent No. 12,179,695 Although the claims at issue are not identical, they are not patentably distinct from each other because the claims 1,3-10,12-14,16-17,20 of U.S. Patent No. 12,179,695 would encompass the broader claims 1-20 of the current application.
Current application
U.S. 11,634,103
1
1,3
2
4
3
5
4
1,6
5
7
6
8
7
9
8
3
9
10,12
10
13
11
14
12
10,12,1,6
13
16
14
12
15
17,1,3
16
17,1,4
17
17,1,5
18
17,1,6
19
20
20
17,1,3
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract without significantly more.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to collecting, analyzing, and communicating information without significantly more. The claim(s) recite(s) generating telematics data by a mobile device located inside a vehicle; transmitting the telematics data to one or more processors; analyzing the telematics data to determine that an accident involving the vehicle has occurred; analyzing the telematics data to determine a likelihood of injury due to the accident; generating a question based upon the telematics data and likelihood of injury in response to determining that the accident has occurred; transmitting the question to the mobile device; and presenting the question on the mobile device. This judicial exception is not integrated into a practical application because all steps recite conventional information collection, analysis, and communication, and no claim limitation improves the functioning of the mobile device, processors, or network. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the mobile device, processors, and memory are recited at a high level of generality and perform only routine, generic functions.
Claims 2–8 depend from claim 1 and recite additional limitations such as determining injury likelihood based on accelerometer data, determining accident severity, customizing communications based on user preferences, and recommending third-party emergency services. These claims recite additional data-specific or conventional automation steps, which do not provide significantly more than the abstract idea. Accordingly, claims 2–8 are also directed to an abstract idea and are not patent eligible under 35 U.S.C. 101.
Claim 9 is rejected under 35 U.S.C. 101 because the claimed invention is directed to collecting, analyzing, and communicating information without significantly more. The claim(s) recite(s) a system comprising a mobile device located inside a vehicle, one or more processors, and memory storing instructions that, when executed, cause the processors to receive telematics data from the mobile device; analyze the data to determine an accident and likelihood of injury; generate a question based on the data; transmit the question to the mobile device; and present the question on the mobile device. This judicial exception is not integrated into a practical application because the claimed system merely performs the abstract idea using generic components without any technical improvement. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the processors and memory are recited at a high level of generality and perform routine, conventional functions.
Claims 10–14 depend from claim 9 and recite further limitations such as using accelerometer data, assessing accident severity, automatic emergency notifications, and ambulance/police selection. These limitations are conventional data processing or automation steps, which do not provide significantly more than the abstract idea. Accordingly, claims 10–14 are also directed to an abstract idea and are not patent eligible under 35 U.S.C. 101.
Claim 15 is rejected under 35 U.S.C. 101 because the claimed invention is directed to collecting, analyzing, and communicating information without significantly more. The claim(s) recite(s) a tangible, non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the computer system to receive telematics data from a mobile device, determine an accident and likelihood of injury, generate a question based on the data, transmit the question to the mobile device, and present the question on the mobile device. This judicial exception is not integrated into a practical application because the claim merely recites performing the abstract idea using a generic computer system. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the computer system components are generic and perform routine instructions.
Claims 16–20 depend from claim 15 and recite further limitations such as determining accident severity, recommending third-party emergency services, automatic notification transmission, and asking about ambulance/police needs. These limitations are conventional information processing steps and do not provide significantly more than the abstract idea. Accordingly, claims 16–20 are also directed to an abstract idea and are not patent eligible under 35 U.S.C. 101.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 1,2,3,7,9-11,15,16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Doughty et al. (US 2015/0127570) in view of McKown et al. (US 2013/0331055), further in view of Velusamy et al. (US 2012/0164968) and McKown et al. (US 2013/0328671) hereafter (“671”)
Claim 1 recites:
“A computer-implemented method of vehicle accident response, the computer-implemented method comprising:
generating, by a mobile device located inside a vehicle, telematics data associated with operation of the vehicle;
transmitting, from the mobile device to one or more processors via wireless communication, the telematics data;
analyzing, by the one or more processors, the telematics data to determine that an accident involving the vehicle has occurred;
analyzing, by the one or more processors, the telematics data to determine a likelihood of injury due to the accident;
generating, by the one or more processors, a question (i) based upon the telematics data and the likelihood of injury and (ii) in response to determining that the accident has occurred, wherein the question asks if: (i) a driver needs an ambulance and/or (ii) the driver needs police;
transmitting, by the one or more processors, the question to the mobile device located inside the vehicle; and
presenting, by the one or more processors, on the mobile device located inside the vehicle, the question.”
Doughty et al. (US 2015/0127570) teaches:
a. Generating, by a mobile device located inside a vehicle, telematics data associated with operation of the vehicle (Para. 15, 31–26).
b. Transmitting, from the mobile device to one or more processors via wireless communication, the telematics data (Fig. 1, 4; Para. 14–17, 19).
c. Analyzing, by the one or more processors, the telematics data to determine that an accident involving the vehicle has occurred (Fig. 1, 4; Para. 40, 46–47).
d. Generating, by the one or more processors, a communication based upon the telematics data in response to determining that the accident has occurred (Para. 57–61; Fig. 14–7), wherein the communication comprises a question relating to an injury (Fig. 4, 7c; Para. 65, 97–99).
e. Transmitting, by the one or more processors, the communication to the mobile device located inside the vehicle (Para. 57–61; Fig. 14–7).
However, Doughty does not explicitly teach:
Analyzing, by the one or more processors, the telematics data to determine a likelihood of injury due to the accident;
Generating a question specifically asking if the driver needs an ambulance and/or police.
McKown et al. (US 2013/0331055) teaches:
Analyzing, by the one or more processors, the telematics data to determine a likelihood of injury due to the accident (Para. 35–38, 55).
Velusamy et al. (US 2012/0164968) teaches:
Generating a communication based upon telematics data, wherein the communication comprises a question regarding emergency assistance, and transmitting it to the mobile device (Fig. 4, 5A; Para. 13, 16–19, 62–63, 67–68, 74).
McKown (“671”) teaches:
Prompting a driver with a question regarding police assistance (Para. 15), corresponding to the claimed “question… if the driver needs police.”
It would have been obvious at the time the invention before the effective filing date of the claim invention was made to modify Doughty to include the analysis of telematics data to determine the likelihood of injury as suggested by McKown (‘055’), and to generate a question regarding emergency assistance specifically asking if the driver needs an ambulance and/or police as suggested by Velusamy and McKown (“671”), because it would improve accident response decision-making and provide additional status information to emergency responders. This constitutes an implementation of applying a known technique to a known device ready for improvement to yield predictable results.
Similarly :
As per claim 1, Doughty teaches a computer-implemented method of vehicle accident response, the method comprising:
generating, by a mobile device (210) located inside a vehicle, telematics data associated with operation of the vehicle (Para. 15,31-26);
transmitting, from the mobile device to one or more processors via wireless communication, the telematics data (2303 via wireless communication, the telematics data (Fig. 1, 4; vehicle information is transmitted to telematics server device; Para. 1417-19; the server can be one or more processors);
analyzing, by the one or more processors, the telematics data to determine that an accident involving the vehicle has occurred (Fig. 1 and 4: Para. 40,46,47; telematics server device 230 may determine that the vehicle has been in the accident based on the vehicle information gathered by telematics device 210);
generating, by the one or more processors, a communication (i) based upon the telematics data and (ii) in response to determining that the accident has occurred (Para. 57-61; Fig. 14-7; report), wherein the communication comprises a question relating to an injury (Fig. 4 and 7c; Para 65, 97-99); and
transmitting, by the one or more processors, the communication to the mobile device located inside the vehicle (Para. 57-61; Fig. 14-7; report).
The invention of Doughty does not explicitly mention analyzing, by the one or more processors, the telematics data to determine a likelihood of injury due to the accident; generating, by the one or more processors, a communication (i) based upon the likelihood of injury and wherein the communication comprises a question regarding emergency assistance; transmitting, by the one or more processors, the communication (“a question regarding emergency assistance”) to the mobile device located inside the vehicle.
In the analogous art, McKown teaches the system is configured to: analyzing, by the one or more processors, the telematics data to determine a likelihood of injury due to the accident; generating, by the one or more processors, a communication (i) based upon the likelihood of injury (Para 35-38,55).
Therefore, it would have been obvious at the time the invention before the effective filing date of the claim invention was made to include processor wherein the analyzing the telematics data to determine a likelihood of injury due to the accident as suggest by McKown to the system/server because it would improve the crash detection decision based on the likelihood of injury, thereby increasing the effectiveness of the invention. It would be an implementation of applying a known technique to a known device ready for improvement to yield predictable results.
Velusamy shows a method of generating, by the one or more processors, a communication (i) based upon the telematics data; and the communication comprises a question regarding emergency assistance; transmitting, by the one or more processors, the communication (“a question regarding emergency assistance”) to the mobile device located inside the vehicle (Fig. 4, 5A; Para 13,16-19,62-63,67-68,74; the communication is shown by emergency notification, for example, the message indicates that an emergency condition was detected and the user has the option of interact with the communication/emergency notification via the question of whether connecting with emergency contact [the claimed “question regarding emergency assistance”]).
Therefore, it would have been obvious at the time the invention before the effective filing date of the claim invention was made to include the communication comprises a question regarding emergency assistance associated with telematics data as suggest by Velusamy to the combined one or more processors as shown by Doughty in view of McKown that is operating with the association of likelihood of injury and telematics data, because it would provide additional status information to the emergency responder and connect with such emergency responder in order to provide proper responding service, thereby increasing the effectiveness of the invention. It would be an implementation of applying a known technique is a known device ready for improvement to yield predictable results.
Further, the combined invention meets the limitation of claim, and the combination view of Velusamy shows the question comprises the question regarding emergency assistance (Fig. 5A; Para 17,64,74) and would have been obviously further shows the question asks: if a driver needs an ambulance; and/or if the driver needs the police (“connecting with emergency contact in “X sec” plus the option to cancel the call which is indirectly questioning the driver if driver needs to connect the police, in other words if the driver needs the police).
McKown (“671”) shows prompting a communication to specific, a driver, if the driver want/need police (Para 15).
Therefore, it would have been obvious at the time the invention before the effective filing date of the claim invention was made to include the communication as shown by Velusamy as well as the prompting to the driver as shown by McKown (“671”) to the communication including questions as shown Doughty because it would provide additional status information to the emergency responder and connect with such emergency responder to further determine the severity of the accident and provide proper responding service, thereby increasing the effectiveness of the invention. It would be an implementation of applying a known technique is a known device ready for improvement to yield predictable results.
As per claim 2, the combined invention meets the limitation of claim and McKown further shows determining the likelihood of injury includes: determining the likelihood of injury based upon accelerometer data included in the telematics data (Para. 28,29,33,37).
As per claim 3, the combined invention meets the limitation of claim and McKown further shows determining the likelihood of injury includes: determining a likely severity of the accident (Para. 60).
As per claim 7, the combined invention meets the limitation of claim and Doughty further shows receiving, at the one or more processors, user preferences selected using a mobile device application of the mobile device, the user preferences relating to preferred content of the communication; and wherein generating the communication includes generating a customized communication including the preferred content based upon the user preferences (Para. 45,47,60,64,65,82,89,108; user input and authorization of information release; Para. 106 show customization on user device).
As per claims 9,10,11,15,16 they correspond to claims 1,2,3,7; they are therefore rejected for the similar reasons set forth. Doughty further shows a tangible, non-transitory computer-readable medium storing executable instructions for vehicle accident response that, when executed by one or more processors of a computer system (Para. 26,27).
Claim 4-6, 12, 13, 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Doughty et al. (US 2015/0127570) in view of McKown et al. (US 2013/0331055), further in view of Velusamy et al. (US 2012/0164968), and Terlep (US 2011/0087505) and Briggs et al. (US 9,053,588).
As per claim 4, the combined invention meets the limitation of claim but does not generating the communication includes: determining a third-party emergency service to recommend to a driver of the vehicle; and including an indication of the third-party emergency service in the communication.
In the analogous art, Terlep shows an electronic device for use by vehicle operator or owner that can be mobile phone or in-vehicle system (Para. 55 and 20} which is communicated with the system (Fig. 3-4) and method of vehicle accident response (Fig. 1: step 110; Para. 25) comprising: determining, by the one or more remote database and network (Para. Fig, 3A and AB; Para. 63,66,67, wherein the database can be a server as stated in Para. 31), a third-party emergency service (repair entity, emergency service, police station, etc. see Para. 30) to recommend to the driver based on the telematics data and in response to determining that the accident has occurred (Para. 61-67); transmitting, by the one or more remote database and network, to the mobile device, a communication in response to determining that the accident has occurred; and displaying, by a mobile device application of the mobile device, the communication, wherein the communication includes a list of next steps that the driver should take alter the accident (Fig. 4; “what to do when you are in Car Accident” as well as the list of option such as accident report, find a body shop, find towing company, contact a rental, etc.) and a recommendation of the third-party emergency service (Para. 33,37,63,66,67,74). Although Fig. 4 and Para. 72 states the electronic device determines that an accident has occurred based on a user presses the push button, however, Para, 36 and 25 states the occurrence of the accident ray be determined based on both user input or by sensors (telematics data). Therefore, it would have been obvious at the time the invention was made the initial communication established between the mobile device and the database/server can be based on telernatics data rather than help button 410 being pressed, because it would be an alternative and known techniques to improve similar devices (automation) in the same way.
In the analogous art, Briges explicitly mention a server is configured to identify a list of appropriate service vehicle to assist the customer based on the telematics data and in response to determine that the accident has occurred (Fig. 3-4; col 9, line 49 —col 11, line 45; col. 13, lines 45-60}.
Therefore, it would have been obvious at the time the invention was made to include the server as shown by Briggs to the database and network structure as shown Terlep in order to allow the remote server to perform the analyzing of telematics data, determining the third-party emergency service and communication transmission function. It would be an implementation of applying a known technique is a known device ready for improvement to yield predictable results.
Further, it would have been obvious at the tune the invention was made to include the server and display and accident reporting function as shown by the combination in view of Terlep and Briggs to the accident reporting device as shown by Doughty, such that the invention of Doughty would provide additional communication and display function at the mobile device to provide the list of next steps and recommendation of the third party emergency service to the driver, thereby increasing the flexibility of the invention. Such modification would allow the server of Terlep in view of Briggs to be combined with the server of Doughty. It would be an implementation of user of known techniques to improve similar device in the same way.
As per claim 5, the combined invention meets the limitation of claim and Terlep and Briggs further shows receiving, by the one or more processors, a selection of the third-party emergency service from the mobile device; and transmitting, by the one or more processors, a notification to emergency services to request the third-party emergency service (T: Para. 32-33,37,74-75 ; B: col. 7, line 40 – col. 8, line 68; Fig. 4-8).
As per claim 6, the combined invention meets the limitation of claim and Terlep and Briggs further shows automatically transmitting, by the one or more processors, a notification to emergency services to request the third-party emergency service (T: Para 50,52,53,61,63,64; B: col. 7, line 40 – col. 8, line 68)
As per claims 12, 13, 17-19, they correspond to claims 4-6; they are therefore rejected for the similar reasons set forth. Doughty further shows a tangible, non-transitory computer-readable medium storing executable instructions for vehicle accident response that, when executed by one or more processors of a computer system (Para. 26,27).
Claim 8, 14 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Doughty et al. (US 2015/0127570) in view of McKown et al. (US 2013/0331055), further in view of Velusamy et al. (US 2012/0164968) and McKown et al. (US 2013/0328671) hereafter (“671”) and Ricci (US 2016/0196745).
Claim 8, 14 and 20 recites:
“8. The computer-implemented method of claim 1, wherein the question asks both: (i) if the driver needs the ambulance and (i) if the driver needs the police.”
“14. The system of claim 10, wherein the question asks both: (i) if the driver needs the ambulance and (i) if the driver needs the police.”
“20. The computer-readable medium of claim 15, wherein the question asks both: (i) if the driver needs the ambulance and (i) if the driver needs the police.”
As shown in claim 1, 9 and 15:
Doughty: Teaches generating a communication including a question relating to an accident/injury.
McKown 2013/0331055: Teaches determining likelihood of injury.
Velusamy: Teaches presenting a question regarding emergency assistance. Teaches a question regarding emergency assistance (generalized), but does not explicitly disclose both ambulance and police together in a single question.
McKown “671”: Teaches prompting a driver regarding police assistance. Teaches prompting regarding police assistance, but does not explicitly disclose ambulance inquiry in the same prompt.
Ricci teaches:
Contacting emergency services including:
Police and/or
ambulance
roadside assistance (Para 322)
Presenting or recommending actions to the vehicle occupant, including contacting such services.
This corresponds to identifying multiple emergency response options (ambulance and police) as selectable or actionable items.
It would have been obvious at the time the invention before the effective filing date of the claim invention was made to modify the combined system to include a question that asks about both ambulance and police needs in a single interaction, as suggested by Ricci, because:
Ricci explicitly teaches that both ambulance and police are standard emergency response options considered together in vehicle-related emergency handling.
Combining multiple emergency options into a single prompt/question is a predictable variation that improves usability and efficiency by reducing user interaction steps.
A person of ordinary skill in the art would recognize that consolidating related emergency inquiries into one question is a design choice that enhances user experience and system responsiveness.
It would have been obvious at the time the invention before the effective filing date of the claim invention was made to modify the combined teachings of the combined invention in view of Ricci to include a question asking both whether the driver needs an ambulance and whether the driver needs police, in order to streamline emergency response interaction and improve efficiency of user input collection, because integrating multiple known emergency options into a single prompt is a predictable variation of prior art systems. It would be an implementation of choosing from a finite number of identified, predictable solutions.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HOI C LAU whose telephone number is (571)272-8547. The examiner can normally be reached on Monday-Friday, 8:30am-5:00Pm EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Davetta Goins can be reached on (571)272-2957. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HOI C LAU/Primary Examiner, Art Unit 2689
Prosecution Insights